Prosecution Insights
Last updated: October 02, 2026
Application No. 18/753,919

APPARATUS FOR VERIFYING SECURITY GOAL FOR VEHICLE CYBERSECURITY AND A METHOD FOR THE SAME

Final Rejection §101§103§112
Filed
Jun 25, 2024
Priority
Nov 30, 2023 — RE 10-2023-0171460
Examiner
VU, TAYLOR P
Art Unit
2437
Tech Center
2400 — Computer Networks
Assignee
Kia Corporation
OA Round
2 (Final)
69%
Grant Probability
Favorable
3-4
OA Rounds
1y 1m
Est. Remaining
78%
With Interview

Examiner Intelligence

Grants 69% — above average
69%
Career Allowance Rate
25 granted / 36 resolved
+11.4% vs TC avg
Moderate +8% lift
Without
With
+8.4%
Interview Lift
resolved cases with interview
Typical timeline
3y 4m
Avg Prosecution
25 currently pending
Career history
66
Total Applications
across all art units

Statute-Specific Performance

§101
11.8%
-28.2% vs TC avg
§103
71.5%
+31.5% vs TC avg
§102
1.5%
-38.5% vs TC avg
§112
15.0%
-25.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 36 resolved cases

Office Action

§101 §103 §112
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 The present office action is responsive to communication filed on 04/02/2026. Claims 1 and 11 have been amended. Claims 1-19 are currently pending. Applicant arguments filed on 04/02/2026 have been fully considered but they are not fully persuasive. On pages 7-8 , of the Remarks, Applicant contends: “Applicants have amended claim 1 to clarify that the processor is configured to "derive a security goal linked to threat mitigation information by performing Threat Analysis Risk Assessment (TARA)," "store the derived security goal as assumption information in a TARA re- execution mode (TARA ReCAL)," map the assumption information to threat mitigation information corresponding to each threat, among one or more threats, for each attack path among one or more attack paths," and "re-calculate an Attack Feasibility Rating for each threat, among the one or more threats, based on i) assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating to verify completeness of the security goal by determining whether a risk treatment scheme is risk acceptable." Support for the amendments may be found at least pars. [0047], [0050], [0064], [0066-0067], and [0077] of the original specification. No new matter is added. Although different in scope, independent claim 11 has been amended in a similar manner. Applicants respectfully submit that the specification clearly describes that a security goal is derived as a result of performing Threat Analysis Risk Assessment (TARA) and is linked to threat mitigation information. The specification further explains that, upon entering a TARA re- execution mode (TARA ReCAL), the derived security goal is stored as assumption information and reused during re-execution. Thus, the security goal is not an abstract or undefined concept, but a technical output generated through a structured TARA procedure.” Examiner respectfully disagrees. The applicant contends the amended claims are directed to an apparatus and method in which a security goal is derived as a result of performing Threat Analysis Risk Assessment (TARA) and is linked to threat mitigation information, and thus, the security goal is not an abstract or undefined concept. Although, the applicant cite text that identifies data inputs, such as threat mitigation information, and expected results, derived security goal, but specifications omits the operative structure or algorithm that shows how the threat mitigation information is used by the Threat Analysis Risk Assessment to derive a security goal. This approach effectively treats the Threat Analysis Risk Assessment as inscrutable ‘black box’, providing no feature extraction techniques or additional algorithmic techniques, as to how Threat Analysis Risk Assessment uses the input of threat mitigation information to produce a security goal. Modern precedent – Ariad Pharmaceuticals et al. v. Eli Lilly and Company, 598 F.3d 1336 (Fed. Cir. 2010); Univ. of Rochester V. G.D. Searle, 358 F.3d 916 (Fed. Cir. 2004); Regents V. Eli Lilly, 119 F.3d 1559 (Fed. Cir. 1997)-confirms that functional claiming without commensurate structural or algorithmic disclosure fails written description. The 35 USC 112(a) written description rejection therefore remains proper. Further on pages 7-8, of the Remarks, Applicant contends: “Further, Applicants respectfully submit that the specification additionally describes the process of entering the TARA re-execution mode, storing the security goal as assumption information during the Item Definition stage, mapping the assumption information to threats for each attack path, re-calculating an Attack Feasibility Rating based on the mapped assumption information and determining a risk treatment scheme and evaluating whether it is "risk acceptable." These processes are described step-by-step in the detailed description, for example in paragraphs [0047], [0050], [0064], [0066-0067], and [0077] of the specification. Furthermore, the specification clearly explains that "assumption information" is information stored based on the derived security goal, "attack path" is defined based on vehicle ECU and communication structures and "threat mitigation information" is stored in a Threat Taxonomy Database and linked to each threat. See e.g., instant specification at par. [0047].” Examiner respectfully disagrees. Examiner asserts that verifying completeness of the security goal is still an indefinite term because of the now amended term ‘risk acceptable’ is also an indefinite term. It is not clear what ‘risk acceptable’ what the metes and bounds of the introduced terms should mean to the person having ordinary skill in the art. Further the specifications does not discuss what metes and bounds does risk acceptable means and essential steps of how the risk treatment schemes is determined to be risk acceptable. The 35 USC 112(a) written description rejection therefore remains proper. On pages 9-11, of the Remarks, Applicant contends: The Office action alleged that the recitation "verifying a security goal" in claims 1 and 11 is unclear. In particular, the Office action alleges that it is unclear what the recited "security goal" refers to. Applicants respectfully disagree. As discussed above, "security goal" is a technical result derived from TARA and linked to threat mitigation information. See e.g., the original specification at par. [0049]. Accordingly, Applicants respectfully submit that "security goal" as recited in claims 1 and 11 is clear at least in light of the description at par. [0049] of the instant specification. Further, the Office action alleged that the recitation "based on assumption information" in claims 1 and 11 is unclear. In particular, the Office action alleged that it is unclear what constitutes assumption information. Applicants respectfully disagree. Applicants respectfully submit that, as discussed above, assumption information" is explicitly defined in the specification as stored information that is based on the security goal during TARA ReCAL. See e.g., the original specification at pars. [0060] and [0077]. Accordingly, Applicants respectfully submit that "assumption information" as recited in claims 1 and 11 is clear at least in light of the description at pars. [0060] and [0077] of the instant specification. Further still, the Office action alleged that "Threat Analysis Risk Assessment to verify completeness of the security goal" as recited in claims 1 and 11 is unclear. In particular, the Office action alleged that it is unclear how the completeness of the security goal may be verified. As noted above, each of claims 1 and 11 has been amended to clarify that completeness of the security goal is verified "by determining whether a risk treatment scheme is risk acceptable." Accordingly, in light of the amendment, Applicants respectfully submit that "Threat Analysis Risk Assessment to verify completeness of the security goal by determining whether a risk treatment scheme is risk acceptable," as now recited in each of claims 1 and 11, is clear. … Further, the Office action alleged that the recitation "scheme of Risk Acceptable" in claims 7, 8, 17, and 18 is unclear. In particular, the Office action alleged that it is unclear how "Risk Acceptable" is derived, or from what inputs it is calculated. Applicants respectfully disagree. Applicants restfully submit that, as explained, for example, in par. [0068] of the original specification, "Risk Acceptable" may be determined based on a risk value that is determined based on the re-calculated Attack Feasibility Rating. For example, as also explained in pars. [0068] of the original specification, the processor may classify the Attack Feasibility Rating into "Very Low", "Low", "Medium", or "High", and may re-determine a risk level by considering the Attack Feasibility Rating and the impact rating of damage scenario. Further, as explained in par. [0069] of the original specification, for risk value being risk value 1, the risk treatment scheme resulting from the threat may be determined as "Risk Acceptable". In this case, "Risk Acceptable" may signify that a present threat is maintained, without additional risk reduction treatment. Accordingly, Applicants respectfully submit that "Risk Acceptable" as recited in claims 7, 8, 17, and 18 is clear at least in light of the description in in pars. [0068] - [0069] of the instant specification. Further still, the Office action alleged that the recitation "treatment mitigation information linked to the security goal" in claims 3, 4, 13, and 14 is unclear. In particular, the Office action alleged that it is unclear what constitutes treatment mitigation information or how it is derived, or from what inputs it is calculated. Applicants respectfully disagree. Applicants respectfully submit that, as explained for example in pars. [0015] and [0025] of the original specification, "treatment mitigation information" is mitigation information that is linked to threat mitigation information, derived with respect to each threat for each attack path depending on a threat scenario in a pre-stored database. As such, Applicants respectfully submit that treatment mitigation information is clearly defined as stored mitigation information that may be obtained from a database. Accordingly, Applicants respectfully submit that "treatment mitigation information linked to the security goal" in claims 3, 4, 13, and 14 is clear at least in light of the description in in pars. [0015] and [0025] of the instant specification.” Examiner respectfully disagrees. The applicant contends "security goal" is a technical result derived from TARA and linked to threat mitigation information. See e.g., the original specification at par. [0049]. Paragraph 49 recites , “ The processor 140 may derive a security goal linked to the threat mitigation information (Mitigation) by performing Threat Analysis Risk Assessment (TARA).”. The cited paragraph only discloses that the security goal is linked to threat mitigation information by performing Threat Analysis Risk Assessment, and not the definition of a security goal. The term of a security goal is an indefinite term because one of the ordinary skill in the art would not know what constitutes as a security goal or how it is derived/linked from the risk assessment using the threat mitigation information. Further, the term risk acceptable is indefinite because the claims provides no objective boundaries or metrics by which person having ordinary skill in the art can determine “risk acceptable” within context of the risk mitigation scheme. Nor the claims does not specify what constitutes as an “acceptable” of how acceptable information obtained. The 35 USC 112(b) rejection therefore remains proper. On pages 11-13, of the Remarks, Applicant contends: “A. Prong One of Step 2A: At Least One Limitation each of the Independent Claims 1 and 17 Does Not Recite Judicial Exception and Should be Considered as an Additional Limitation. The Office action asserts that some limitations recited in the independent claims 1 and 11 amount to an abstract idea that "falls in the categories of a mental process, for example evaluation, judgements, and opinion and mathematical concepts." See the Office action, pages 3 and 5. To expedite the examination but without acquiescing to the assertion in the Office action, claim 1 is amended to now recite that the processor is configured to "derive a security goal linked to threat mitigation information by performing Threat Analysis Risk Assessment (TARA)," "store the derived security goal as assumption information in a TARA re-execution mode (TARA ReCAL)," "map the assumption information to threat mitigation information corresponding to each threat, among one or more threats, for each attack path among one or more attack paths," and "re-calculate an Attack Feasibility Rating for each threat, among the one or more threats, based on i) assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating, to verify completeness of the security goal by determining whether a risk treatment scheme is risk acceptable." Although different in scope, claim 11 is amended in a similar manner. As noted above, support for the amendments may be found at least pars. [0047], [0050], [0064], [0066-0067], and [0077] of the original specification. No new matter is added. Applicants respectfully submit that the amended claims 1 and 11 do not merely recite performing a risk evaluation or making a judgment at a high level of generality. Rather, each of the amended claims 1 and 11 recites a specific sequence of machine-implemented operations including: deriving a security goal linked to threat mitigation information through a structured TARA process; storing the derived security goal as assumption information in a TARA re- execution mode (TARA ReCAL); mapping the assumption information to threat mitigation information corresponding to each threat for each attack path; and re-calculating an Attack Feasibility Rating for each threat based on the mapped assumption information. Applicants respectfully submit that these limitations as recited in each of claims 1 and 11 require structured electronic processing of stored database information, including stored threat mitigation information, and mapping such information per threat and per attack path within a vehicle cybersecurity framework. Such processing cannot practically be performed as a mere mental process. The claimed subject matter operates within a specific vehicle cybersecurity control architecture involving database-stored mitigation information, attack path modeling, re- calculation of attack feasibility ratings, re-determination of risk values, and determination of risk acceptability. Such operations are not mere observations, evaluations, judgments, or opinions, and are not the type of acts that can practically be performed in the human mind. At least, but not limited to, these steps are not a mental process that can be practically performed in the human mind. Therefore, the claimed subject matter is not directed to mental processes concepts performed in the human mind or by a human using a pen and paper. Therefore, the claimed subject matter is patent-eligible under 35 U.S.C. §101. B. Prong Two of Step 2A: Independent Claims 1 and 17 Integrate the Judicial Exception into a Practical Application. The Office action asserts that the additional limitations do not integrate the abstract idea into a practical application. See the Office action, pages 3 and 5. Applicants respectfully traverse this allegation. Applicants respectfully submit that each of the amended independent claims 1 and 11 is directed to a practical application. In particular, the subject matter of the independent claims 1 and 11 pertains to a technical improvement in the security goal verification technology in Threat Analysis Risk Assessment (TARA) in vehicles. Specifically, the subject matter of the independent claims 1 and 11 may apply assumption information to each threat, among one or more threats, for each attack path among one or more attack paths, depending on a threat scenario, during re-execution of TARA (ReCAL). By such thereat-scenario specific application of stored assumption information, the subject matter of claims 1 and 11 may reduce the time it takes to verify the security goal because the assumption information is not individually input for each threat depending on the threat scenario whenever TARA is re-executed. See e.g., pars. [0009] and [0094] of the original specification. Independent claims 1 and 11 reflect how to achieve the mentioned technical improvement in the functioning of the TARA security goal verification technology. Specifically, the amended claim 1 (an similarly independent claim 11) recites a processor configured to: derive a security goal linked to threat mitigation information by performing Threat Analysis Risk Assessment (TARA); store the derived security goal as assumption information in a TARA re-execution mode (TARA ReCAL); map the assumption information to threat mitigation information corresponding to each threat, among one or more threats, for each attack path among one or more attack paths; and re-calculate an Attack Feasibility Rating for each threat, among the one or more threats, based on i) assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating, to verify completeness of the security goal by determining whether a risk treatment scheme is risk acceptable. As discussed above, the subject matter of independent claim 1 (and similarly the independent claim 11) may thus reduce the time it takes to verify the security goal because the assumption information is not individually input for each threat depending on the threat scenario whenever TARA is re-executed.” Examiner respectfully disagrees. Applicant’s contention that the amended independent claims are no longer directed to a judicial exception is not because the practical application, provides a technical solution to a technical problem, and as such is not merely using generic element to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of judicial exception to a particular technological environment or field of use. The claims still recite nothing more than collecting, analyzing, and generating data according to a Threat Analysis Risk Assessment to verify a security goal, which is an abstract idea. The added limitations relating to “store the derived security goal as assumption information”, “map assumption information to threat mitigation information corresponding to each threat, among one or more threats, for each attack path among one or more attack paths”, and “determining whether a risk treatment scheme is risk acceptable” still full squarely with abstract idea groupings (mental processes and data analysis) identified in the 2019 Revised Patent Eligibility Guidance MPEP 2106, even though they are implemented technically such a computer. Applicant’s argument under Step 2a, Prong One that claimed steps of processing cannot practically be performed as a mere mental process because the claimed subject matter operates within a specific vehicle cybersecurity control architecture involving database-stored mitigation information, attack path modeling, re- calculation of attack feasibility ratings, re-determination of risk values, and determination of risk acceptability. The eligibility inquiry turns on the character of the claimed operations, not whether a human would realistically perform them at scale. Here, the operations include receiving a security goal, applying mitigation information to an assessment (e.g., Threat Analysis Risk Assessment/ data analysis/could be done with pen and paper/mental process) , re-conducting the assessment using past previously Threat Analysis Risk Assessment results and mitigation information (e.g., data analysis/could be done with pen and paper/mental process), and using attack path modeling (e.g., could be done with pen and paper/mental process/data analysis), and verifying the completeness of the security goal (e.g., data analysis) based on results performed by the Threat Analysis Risk Assessment and mapping, are all forms of information analysis and evaluation. The limitations are carried out in a vehicle cybersecurity control architecture and the implementation of a database does not change the fact that the claims are directed to an abstract data-analysis concept akin to those found ineligible in cases such as Electric Power Group and Recentive. Nor is applicant’s Step 2A, Prong two position is persuasive. The applicant contends that the subject matter of the independent claims 1 and 11 pertains to a technical improvement in the security goal verification technology in Threat Analysis Risk Assessment (TARA) in vehicles. The recited limitations of applying assumption information to each threat, among one or more threats, for each attack path among one or more attack paths, depending on a threat scenario, during re-execution of TARA (ReCAL). These are typical operations security tools, and applicant has not pointed to any recited claim element or combination that effects a technological change in how the vehicle cybersecurity control architecture, as opposed to using a computer as a tool to perform security analysis. The assertion that the claimed method improves in security goal verification are not tied to any specific technical mechanism in the claim and therefore amount to no more than generic benefit of automating an abstract process on a computer, which 2019 guidance and MPEP 2106.05 make clear is insufficient to supply an inventive concept. In the absence of concrete, non-generic implementation details in claim that change the way the computer performs these operations at technical level, the additional elements, and individually and in combination, are well-understood, routine, and conventional activities in the field. Accordingly, the amended claims remain directed to an abstract idea under Step 2A and do not recite additional elements that amount to significantly more under Step 2B, and the rejection under 35 U.S.C 101 is reasserted. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 1-19 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Regarding claims 1 and 11: “…verifying a security goal…” is recited in claims 1 and 11, but the specification does not describe what constitutes what a “security goal” is or what a security goal represents. There is no definition, no rule, and no algorithm disclosed for a security goal is classified or how it determined based on threat mitigation information and threat analysis risk assessment. The claim further recites: “…based on assumption information…” “…to verify completeness of security goal by determining whether a risk treatment scheme is a risk acceptable…” The application provides no structural support, algorithmic detail, or any sample implementation for how a security goal is derived from the threat mitigation information and the assessment , or any other forms of input. It is not clear what the ‘security goal’ represents to a person having ordinary skill in the art and what the metes and bounds of the introduced terms should mean to a person having ordinary skill in the art. This contrasts with well-established terms like “security requirements” which are mathematically well defined an do not need additional guidance from the inventor. On a similar note, the specification does not describe “assumption information” and “completeness of the security goal” are likewise undefined and unsupported and there is no disclosure or how these values are selected or quantified. Regarding claims 7, 8, 17, and 18 : Claims 7-8 and 17-18 recites “...scheme of Risk Acceptable…”. The specification does not reasonable convey to those skilled in the art the inventors were in possession of the full score of this limitation at the time of the filing. Claims 2-10 and 12-19 do not overcome the rejections of their respective base claims that have been rejected above, and therefore rejected under the same grounds provided to claims 1 and 11 . 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. Claims 1-19 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. Regarding claims 1 and 11: “…based on assumption information…” Indefinite because the claim does not specify what constitutes as an “assumption” nor how assumption information is obtained or what constitutes as assumption information. It is unclear whether assumption information refers to an inference, scenario, or related to attack paths. “…to verify the completeness of security goal by determining whether a risk treatment scheme is risk acceptable…” Indefinite because the claim provides no objective boundaries or metrics by which person having ordinary skill in the art can determine “completeness” of a security goal, nor it is clear whether refers to a rating, percentage, or a score. Additionally, because the claim does not provide no objective boundaries or metrics by which person having ordinary skill in the art can determine “risk acceptable” of a risk treatment scheme. Regarding claims 7, 8, 17, and 18 : “...scheme of Risk Acceptable…” Indefinite because the claim does not specify what constitutes as “Risk Acceptable” nor how it is derived, or from what inputs it is calculated. Functional limitations much be supported by structure in the specification, but the application fails to disclose any algorithms, flowcharts, pseudo-code etc. that offer structural support for this limitation. Regarding claims 3, 4, 13, and 14: “…treatment mitigation information linked to the security goal…” Indefinite because the claim does not specify what constitutes as treatment mitigation information nor how it is derived, or from what inputs it is calculated. It is not clear what the ‘treatment mitigation information’ represents to a person having ordinary skill in the art and what the metes and bounds of the introduced terms should mean to a person having ordinary skill in the art. Functional limitations much be supported by structure in the specification, but the application fails to disclose any algorithms, flowcharts, pseudo-code etc. that offer structural support for this limitation. Claims 2-10 and 12-19 do not overcome the rejections of their respective base claims that have been rejected above, and therefore rejected under the same grounds provided to claims 1 and 11 . 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-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 1 recites an apparatus which appears to be a ‘machine’ and one of the four statutory subject matter categories of invention (Step 1 of the Subject Matter Eligibility Test). However, the claim appears to not qualify for a streamlined analysis thus a full eligibility and thus a full eligibility analysis is necessary (Step 2A and Step 2B of the Subject Matter Eligibility Test). In Step 2A, Prong One, examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. The claim recites the steps of: “…receive an input of a user…” (data gathering) “…derive a security goal linked to threat mitigation information by performing Threat Analysis Risk Assessment (TARA)...” (mental process) “…store the derived security goal as assumption information…” (data gathering) “…map the assumption information to threat mitigation information corresponding to each threat…” (mental process) “… re-calculate an Attack Feasibility Rating, for each threat, among the one or more threats… to verify completeness of security goal…” (mental process) The steps performing amount to an abstract idea which falls under a judicial exception (Step 2A Prong 1, of Subject Matter Eligibility). Abstract ideas fall in the category. The abstract idea falls in the categories of a mental process, for example evaluation, judgements, and opinion and mathematical concepts (MPEP 2106.04(a)(2) & MPEP 2106.06) such as executing a Threat Analysis Risk Assessment (calculation) to verify completeness of a security goal. For example, the courts found that a claim “generating a life insurance policy including a stable value protected investment with an initial value based on a value of underlying securities, calculating surrender value protected investment credits for the life insurance policy; determining an investment value and a value of the underlying securities for the current day;” where attempt to patent the use of the abstract idea of [managing a stable value protected life insurance policy] and then instruct the use of well-known [calculations] to help establish some of the inputs into the equation, Bancorp Services., L.L.C. v. Sun Life Assurance Co. of Canada (U.S.), 687 F.3d 1266, 103 USPQ2d 1425 (Fed. Cir. 2012). In Step 2A, Prong Two, examiner determine whether the claim as a whole integrates the judicial exception into a practical application to disqualify abstract as a judicial exception. However, the judicial exception in claim 1 Is not integrated into practical application because the generically recited computer elements: “...input device…” “…a processor…” do not add meaningful limitation to an abstract idea because they do not add a meaningful limitation to an abstract idea because they amount to simply implementing the abstract idea on a computer. The implementation of using a confidence level results enabling human decision making without using the user actions in any meaningful to improve the functioning of a computer or another technology without reference to what is well-understood, routine, and conventional activity. The claim do not include additional elements that are sufficient to amount to significantly more than the judicial exception because simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer function that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984. Thus, the analysis concludes is ineligible under 35 U.S.C. § 101 as it is directed to a judicial exception. Regarding to claims 2-10: Claims 2-10 do not add any additional elements than those already disclosed in claim 1, and merely adds further abstract ideas. Furthermore, none of the claims integrate the judicial exception into a practical application. Claim 11 recites a method which appears to be a ‘process’ and one of the four statutory subject matter categories of invention (Step 1 of the Subject Matter Eligibility Test). However, the claim appears to not qualify for a streamlined analysis thus a full eligibility and thus a full eligibility analysis is necessary (Step 2A and Step 2B of the Subject Matter Eligibility Test). In Step 2A, Prong One, examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. The claim recites the steps of: “…deriving a security goal linked to threat mitigation information by performing Threat Analysis Risk Assessment (TARA)…” (data gathering) “… storing the derived security goal as assumption information…” (data gathering) “…mapping the assumption information to threat mitigation information corresponding to each threat…” (mental process) “…re-calculating an Attack Feasibility Rating, for each threat, among the one or more threats....to verify completeness...” (mental process) The steps performing amount to an abstract idea which falls under a judicial exception (Step 2A Prong 1, of Subject Matter Eligibility). Abstract ideas fall in the category. The abstract idea falls in the categories of a mental process, for example evaluation, judgements, and opinion and mathematical concepts (MPEP 2106.04(a)(2) & MPEP 2106.06) such as executing a Threat Analysis Risk Assessment (calculation) to verify completeness of a security goal. For example, the courts found that a claim “generating a life insurance policy including a stable value protected investment with an initial value based on a value of underlying securities, calculating surrender value protected investment credits for the life insurance policy; determining an investment value and a value of the underlying securities for the current day;” where attempt to patent the use of the abstract idea of [managing a stable value protected life insurance policy] and then instruct the use of well-known [calculations] to help establish some of the inputs into the equation, Bancorp Services., L.L.C. v. Sun Life Assurance Co. of Canada (U.S.), 687 F.3d 1266, 103 USPQ2d 1425 (Fed. Cir. 2012). In Step 2A, Prong Two, examiner determine whether the claim integrates the judicial exception into a practical application to disqualify abstract as a judicial exception. However, the judicial exception in claim 11 is not integrated into practical application because the generically recited computer elements do not add meaningful limitation to an abstract idea because they do not add a meaningful limitation to an abstract idea because they amount to simply implementing the abstract idea on a computer. The implementation of using a cost function and performing symbolic execution results enabling human decision making without using the user actions in any meaningful to improve the functioning of a computer or another technology without reference to what is well-understood, routine, and conventional activity. The claim do not include additional elements that are sufficient to amount to significantly more than the judicial exception because simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer function that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984. Thus, the analysis concludes is ineligible under 35 U.S.C. § 101 as it is directed to a judicial exception. Regarding claims 12-19 Claims 12-19 do not add any additional elements than those already disclosed in claim 11, and merely adds further abstract ideas. Furthermore, none of the claims integrate the judicial exception into a practical application. Applicant’s argument filed on 04/02/2026, with respect to the rejections of claims 1-19 under 35 USC 103, as seen on pages 14-15 of the Remarks, over Kang et al (US PGPub No. 20230222247-A1 ) in view of Davidovich et al. (US PGPub No. 20250013754-A1) , and Salehie et al. (US PGPub No. 20140090071-A1), with amended limitations have been fully considered and are persuasive. Therefore, the rejection have been withdrawn. However upon further consideration, a new grounds of rejection is made in additional view of Bhalla et al. (US PGPub No. 20190114435-A1), Choi et al. (US PGPub No. 20150058993-A1), and Coull et al. (US Pat No. 11201890-B1 ) Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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 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, 2, 5-9, 11, 12, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Kang et al (US PGPub No. 20230222247-A1 ) in view of Davidovich et al. (US PGPub No. 20250013754-A1) , Bhalla et al. (US PGPub No. 20190114435-A1), Choi et al. (US PGPub No. 20150058993-A1), Salehie et al. (US PGPub No. 20140090071-A1), and Coull et al. (US Pat No. 11201890-B1). With respect to claim 1, Kang teaches an apparatus for verifying a security goal for (¶0026: In other examples, known structures and apparatuses are illustrated in block diagram form in order to facilitate description. ) vehicle cybersecurity, (¶0081-0087: As seen in Figure 3, the mapping results of the security-by-design methodology stored in the database unit 130 of the server 100 may include at least one security step, at least one security step, at least one security activity, and a product. A first step may be a step for security training. Meanwhile, a second step may be a step for initiation and plan. Specifically the security activity of the second step may include at least one of security activities such as security schedule planning and management, security goal setting, and verification of consistency and completeness of a goal (verifying security goal). ); the apparatus comprising: an input device configured to receive an input of a user; and (¶0123-0125: As seen in Figure 5, the level extraction unit 140 of the server 100 may recognize characteristics of the enterprise and a current status of the security-by-design methodology of the enterprise (S210). As example, the level extraction unit 140 may determine the characteristic and the current status of the enterprise based on information received from the enterprise through a user input unit (not illustrated) and a communication unit (not illustrated). ); Kang does not disclose: a processor configured to derive a security goal linked to threat mitigation information by performing Threat Analysis Risk Assessment (TARA), However, Davidovich teaches a processor configured to derive a security goal linked to threat mitigation information by performing Threat Analysis Risk Assessment (TARA), and (¶0071: In some examples, as illustrated in Figure 1D, system 10 receives risk analysis information 90 directly from input subsystem 120. Threat Analysis and Risk Assessment (“TARA”) information 190 directly using the subsystem input 120. In some examples, a user can perform TARA work using the graphical user interface of management subsystem 11 of system 10. Further in ¶0143: Figure 5B, illustrates ah high-level flow of a process of security control optimization subsystem 60 for further optimizing the security control (as defined in ¶0084: The term “security control”, as used herein, means methods that are used to reduce feasibility of the attack step.) implementation list of stage 1650. In some examples, in stage 1700, a risk goal for the item is set. In some examples, the risk goal is at least partially based on data in risk analysis information 190 (as seen in ¶0054 in some examples, risk analysis information 190 contains a description of results of an analysis of the risk of predetermined security threats associated with one or more functionalities. In some examples, risk analysis information comprises Threat Analysis and Risk Assessment (TARA) information, such as defined in ISO/SAE)).). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Davidovich with regards to deriving a security goal linked to threat mitigation information by performing Threat Analysis Risk Assessment to the method of Kang in order to analyze the risk and impact of cyberattacks on a given component and its functionality (Davidovich ¶0003). Kang in view of Davidovich does not disclose: store the derived security goal as assumption information in a TARA re-execution mode (TARA ReCAL), However, Bhalla teaches store the derived security goal (¶0075-0076: Requirements and their status can also be exported into requirements and risk tracking systems so that analysts can centrally store and track their security requirements.) as assumption information in a TARA re-execution mode (TARA ReCAL), (¶0079: Figure 2 is a block diagram illustrating a system 200 for identifying security requirements and addressing software application vulnerabilities. The system provides for security risk identification in a software application and throughout a software lifecycle such that security requirements can be identified and updated according to risk assessment. Without being bound by theory, that one strength of the presently described knowledge database is that changes to security regulations, occurrence of malware, and security element updates can be rapidly updated by updating the security elements in the knowledge database and these can be pushed to the security requirements task list for appropriate software application management along with a security risk assessment (re-executing the risk assessment).); It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Bhalla with regards to storing a security goal as assumption information in a TARA re-execution mode (TARA ReCAL) to the method of Kang in view of Davidovich in order to keep up to update security risks, weakness, and vulnerabilities in an ever evolving technological environment (Bhalla ¶0003). Kang in view of Davidovich and Bhalla does not disclose: map the assumption information to threat mitigation information corresponding to each threat, among one or more threats, for each attack path among one or more attack paths, and However, Choi teaches map the assumption information to threat mitigation information corresponding to each threat, among one or more threats, for each attack path among one or more attack paths, and (¶0048: Figure 4 is a diagram of another workflow for discovering network attack paths. Figure 4 also includes heading entitled CVSS/Bayesian based score 416. Node 414 has a CVSS/Bayesian based score 416 of 0.6/0.5. As noted, CVSS stands for Common Vulnerability Scoring System, an example of a scoring system that may produce scoring results 122 of system 100 and depicted in Figure 1 . FIG. 4 also includes STRIDE.RTM. 418 which is provided as an example of a system for classifying computer and network security threats. STRIDE.RTM. 416 processes risk attributes 420. Of risk attributes 420, "BI" stands for business impact, "CI" stands for certification impact in the case of aircraft, "ADM" stands for as designed mitigation, and "MM" stands for mandatory mitigation. (assumption information to threat mitigation information)); It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Choi with regards to attack paths to the method of Kang in view of Davidovich and Bhalla in order to identify changes and to achieve the most favorable security impact (Choi ¶0004-0011). Kang in view of Davidovich, Bhalla, and Choi does not disclose: re-calculate an Attack Feasibility Rating for each threat, among the one or more threats, based on i)assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating, to verify completeness of the security goal by determining whether a risk treatment scheme is risk acceptable. However, Salehie teaches re-calculate an Attack Feasibility Rating for each threat, among the one or more threats, [based on i)assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating,] (¶0074: Security concerns may change dynamically. For example, the value of asset application variables can be changed, and new vulnerabilities can be introduced by context modifications. These modifications are propagated onto the causal network by updating the value of its nodes 181 and/or its structure 180. Analysis is triggered after a change takes place (¶0094 The proposed approach uses the artifacts generated by security requirements engineering and risk assessment methods by adding an asset model which implies along with the re-calculation of the asset model the risk assessment is also re-executed), in order to re-calculate new utility values for all applicable configurations of security controls . The most appropriate set of security controls, exhibiting the highest utility, is selected and applied onto the running system. ) to verify completeness of the security goal by determining whether a risk treatment scheme is risk acceptable. (¶0099: between a security control and a vulnerability (security control-vulnerability relationship) to indicate the impact that a security control has on mitigating that vulnerability; between a security control and a security requirement (security control-requirement relationship) to indicate the impact that a security control has on satisfying that security requirement; between a security requirement and a security goal (security requirement-security goal relationship) to indicate the impact that the satisfaction level of a security requirement has on the achievement of the corresponding security goal (security goal being verified); It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Salehie with regards to re-execution of an assessment to the method of Kang in view of Davidovich, Bhalla, and Choi in order to mitigate risks of future attacks in real time as assets, their values and/or the security context change (Salehie ¶0014). Kang in view of Davidovich, Bhalla, Choi, and Salehie does not disclose: re-calculate an Attack Feasibility Rating for each threat, among the one or more threats, based on i) assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating, It is noted that Salehie does disclose re-execution of an assessment to verify the completeness of a security goal, but Salehie does not disclose re-calculate an Attack Feasibility Rating for each threat, among the one or more threats, based on i) assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating. However, Coull teaches re-calculate an Attack Feasibility Rating for each threat, among the one or more threats, based on i) assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating, (¶0023-0026: Once the threat scores are calculated at 326, each threat score associated with a given object/node (i.e., initial/starting threat scores) is “propagated” to each of the other objects/nodes of the semantic graph through the calculation, at 328, of modified threat scores. The modified threat scores are normalized (e.g., to a sum of 1) at 330, and a subgraph of the semantic graph is identified, at 332,based on plurality of normalized threat scores. In some embodiments, a sub-graph is further analyzed by the processor (e.g., cyber-threat analyzer 200 of Figure 2) based on a pattern of communication identified as a “malicious lateral movement,” and a set of relevant mitigations may be associated with the subgraph, such that the subgraph and the associated mitigations are then presented to an analyst for action. ); It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Coull with regards to recalculating a rating being based on a previous rating and mitigation information to the method of Kang in view of Davidovich, Bhalla, Choi, and Salehie in order to detect cyber security threats and identify high-risk or anomalous activity (Coull ¶0003-0004). With respect to claim 2, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull teaches the apparatus of claim 1 (see rejection of claim 1 above), wherein the processor is configured to add the security goal as the assumption information, when defining an item after entering into the mode TARA (ReCAL) of re-executing the Threat Analysis Risk Assessment, and in response to receiving, from the user, the security goal serving as the assumption information. (Davidovich ¶0141-0146: As seen in Figure 5A, in stage 1650, security control optimization subsystem 60 generates a list of identified security control implementations, associated with the respective attack steps of the attack tree (or one or more attack paths) of the respective threat, that can be implemented on the respective item. In Figure 5B illustrates a high-level flow of a process of security control optimization subsystem 60 for further optimizing the security control implementation list of stage 1650. In some examples, in stage 1700, a risk goal for the item is set. In some examples, the risk goal is at least partially based on data in risk analysis information. 190. ). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Davidovich with regards to adding the security goal as the assumption information, when defining an item to the method of Kang in view of Bhalla, Choi, Salehie, and Coull in order to analyze the risk and impact of cyberattacks on a given component and its functionality (Davidovich ¶0003). With respect to claim 5, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull teaches apparatus of claim 1 (see rejection of claim 1 above) wherein the processor is configured to, when the Attack Feasibility Rating is re-calculated, (Davidovich ¶0193: In some examples, security control optimization subsystem 60 outputs information regarding one or more security controls associated with the respective asset such that the risk level of the asset can be reduced to a level that will allow the permissions. In some examples, security control optimization subsystem 60 updates security control list 80 accordingly (implying the rating is being re-calculated because the security control is being updated by an updated risk level). ) re-determine a risk value based on the re-calculated Attack Feasibility Rating. (Davidovich ¶0168-0169 & ¶0213: In some examples, in stage 2220, attack step implementation mapping subsystem 40 updates the asset risk level according to the task status of the data structure. In some examples, the term “risk level”, as used herein, is defined as a predetermined function of the respective feasibility rating and the respective impact value. In some examples, the impact value is a numerical indication of the impact that a particular threat will have on the respective asset (or on the item itself) if the respective threat is realized. In some examples, impact values are assigned numerical values, as known to those skilled in the art.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Davidovich with regards to a risk value based on the Attack Feasibility Rating to the method of Kang in view of Bhalla, Choi, Salehie, and Coull in order to analyze the risk and impact of cyberattacks on a given component and its functionality (Davidovich ¶0003). With respect to claim 6, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull teaches the apparatus of claim 5 (see rejection of claim 5 above) wherein the processor is configured to determine a risk treatment scheme based on the re-determined risk value. (Salehie ¶0087-0097: . The FCN 180 is also augmented with the total risk node 1001 and utility node 1003. The total risk node 1001 aggregates all partial risks 1001, whereas the utility node 1003 aggregates a set of costs and benefits. Although the causal network 180 is designed to be used in a fully automatic adaptive mechanism, it may also be employed in a recommender system. Such a system analyzes impacts of asset changes and only recommends potential adjustments in security controls with their costs and benefits.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Salehie with regards to risk value to the method of Kang in view of Davidovich, Bhalla, Choi, and Coull in order to better configure security controls and parameters in a system in real time while decreasing risk of harm to the system (Salehie ¶0014-0015). With respect to claim 7, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull teaches the apparatus of claim 6 (see rejection of claim 6 above) wherein the processor is configured to determine whether the risk treatment scheme is a scheme of Risk Acceptable. (Salehie ¶0106: The adaptive security manager applies the security controls that reflect the risk and the value of the assets to be protected, because the causal network computes the utility by taking into account the impact of the satisfaction of the security goals and the risk (Risk Acceptable) . An increase in the asset value can increase both the risk and the criticality of the security goals, however the configuration of security controls with the highest utility is selected as the value of the assets increases, thus more effective countermeasure are selected to guarantee the satisfaction of more critical security goals, and reduce a higher risk.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Salehie with regards to risk value to the method of Kang in view of Davidovich, Bhalla, Choi, and Coull in order to better configure security controls and parameters in a system in real time while decreasing risk of harm to the system (Salehie ¶0014-0015). With respect to claim 8, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull teaches the apparatus of claim 7 (see rejection of claim 7 above) wherein the processor is configured to, when the risk treatment scheme is determined as Risk Acceptable, determine completeness of the security goal as being verified. (Salehie ¶0099: between a security control and a vulnerability (security control-vulnerability relationship) to indicate the impact that a security control has on mitigating that vulnerability; between a security control and a security requirement (security control-requirement relationship) to indicate the impact that a security control has on satisfying that security requirement; between a security requirement and a security goal (security requirement-security goal relationship) to indicate the impact that the satisfaction level of a security requirement has on the achievement of the corresponding security goal (security goal being verified);). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Salehie with regards to risk value to the method of Kang in view of Davidovich in order to better configure security controls and parameters in a system in real time while decreasing risk of harm to the system (Salehie ¶0014-0015). With respect to claim 9, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull teaches the apparatus of claim 8 (see rejection of claim 8 above) wherein the processor is configured to: generate a result of verification completed, when the completeness of the security goal is determined as being verified, and output the result of the verification completed ( Kang: ¶0063: Meanwhile, in the present disclosure, when the level extraction unit 140 maps only one attribute of the functional correctness, the safety integrity, and the security assurance, the level extraction unit 140 may calculate the level of the corresponding attribute. Alternatively, when two or more attributes are mapped, the level extraction unit 140 may coordinate the level through a security activity execution status. The level produced through such a process may be derived for each security activity. In addition, the result is output in the graph form to determine the security-by-design methodology level at a glance. However, the present disclosure is not limited thereto. Meanwhile, the information generation unit 160 may provide second information for at least one required security activity related to the appropriate security-by-design methodology level of the level desired by the enterprise among at least one security activity included in the mapping result.) through an output device. ( Kang: ¶0181: A monitor 1144 or other types of display devices are also connected to the system bus 1108 through interfaces such as a video adapter 1146, and the like. In addition to the monitor 1144, the computer generally includes other peripheral output devices (not illustrated) such as a speaker, a printer, others.). With respect to claim 11, Kang teaches a method (¶0009: An exemplary embodiment of the present disclosure provides a method for embodying a security-by-design methodology using a processor of a computing device, which may include: mapping the security-by-design methodology and an evidence-based security methodology ;) for verifying a security goal for vehicle cybersecurity, (¶0081-0087: As seen in Figure 3, the mapping results of the security-by-design methodology stored in the database unit 130 of the server 100 may include at least one security step, at least one security step, at least one security activity, and a product. A first step may be a step for security training. Meanwhile, a second step may be a step for initiation and plan. Specifically the security activity of the second step may include at least one of security activities such as security schedule planning and management, security goal setting, and verification of consistency and completeness of a goal (verifying security goal).). Kang does not disclose: the method comprising: deriving a security goal linked to threat mitigation information by performing Threat Analysis Risk Assessment (TARA); and However, Davidovich teaches the method comprising: deriving a security goal linked to threat mitigation information by performing Threat Analysis Risk Assessment (TARA); and (¶0071: In some examples, as illustrated in Figure 1D, system 10 receives risk analysis information 90 directly from input subsystem 120. Threat Analysis and Risk Assessment (“TARA”) information 190 directly using the subsystem input 120. In some examples, a user can perform TARA work using the graphical user interface of management subsystem 11 of system 10. Further in ¶0143: Figure 5B, illustrates ah high-level flow of a process of security control optimization subsystem 60 for further optimizing the security control (as defined in ¶0084: The term “security control”, as used herein, means methods that are used to reduce feasibility of the attack step.) implementation list of stage 1650. In some examples, in stage 1700, a risk goal for the item is set. In some examples, the risk goal is at least partially based on data in risk analysis information 190 (as seen in ¶0054 in some examples, risk analysis information 190 contains a description of results of an analysis of the risk of predetermined security threats associated with one or more functionalities. In some examples, risk analysis information comprises Threat Analysis and Risk Assessment (TARA) information, such as defined in ISO/SAE)).). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Davidovich with regards to deriving a security goal linked to threat mitigation information by performing Threat Analysis Risk Assessment to the method of Kang in order to analyze the risk and impact of cyberattacks on a given component and its functionality (Davidovich ¶0003). Kang in view of Davidovich does not disclose: storing the derived security goal as assumption information in a TARA re-execution mode (TARA ReCAL); However, Bhalla teaches storing the derived security goal (¶0075-0076: Requirements and their status can also be exported into requirements and risk tracking systems so that analysts can centrally store and track their security requirements.) as assumption information in a TARA re-execution mode (TARA ReCAL); (¶0079: Figure 2 is a block diagram illustrating a system 200 for identifying security requirements and addressing software application vulnerabilities. The system provides for security risk identification in a software application and throughout a software lifecycle such that security requirements can be identified and updated according to risk assessment. Without being bound by theory, that one strength of the presently described knowledge database is that changes to security regulations, occurrence of malware, and security element updates can be rapidly updated by updating the security elements in the knowledge database and these can be pushed to the security requirements task list for appropriate software application management along with a security risk assessment (re-executing the risk assessment).); It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Bhalla with regards to storing a security goal as assumption information in a TARA re-execution mode (TARA ReCAL) to the method of Kang in view of Davidovich in order to keep up to update security risks, weakness, and vulnerabilities in an ever evolving technological environment (Bhalla ¶0003). Kang in view of Davidovich and Bhalla does not disclose: mapping the assumption information to threat mitigation information corresponding to each threat, among one or more threats, for each attack path among one or more attack paths; and However, Choi teaches mapping the assumption information to threat mitigation information corresponding to each threat, among one or more threats, for each attack path among one or more attack paths; and (¶0048: Figure 4 is a diagram of another workflow for discovering network attack paths. Figure 4 also includes heading entitled CVSS/Bayesian based score 416. Node 414 has a CVSS/Bayesian based score 416 of 0.6/0.5. As noted, CVSS stands for Common Vulnerability Scoring System, an example of a scoring system that may produce scoring results 122 of system 100 and depicted in Figure 1 . FIG. 4 also includes STRIDE.RTM. 418 which is provided as an example of a system for classifying computer and network security threats. STRIDE.RTM. 416 processes risk attributes 420. Of risk attributes 420, "BI" stands for business impact, "CI" stands for certification impact in the case of aircraft, "ADM" stands for as designed mitigation, and "MM" stands for mandatory mitigation. (assumption information to threat mitigation information)); It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Choi with regards to attack paths to the method of Kang in view of Davidovich and Bhalla in order to identify changes and to achieve the most favorable security impact (Choi ¶0004-0011). Kang in view of Davidovich, Bhalla, and Choi does not disclose: re-calculating an Attack Feasibility Rating for each threat, among the one or more threats, based on i)assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating, corresponding to the security goal linked to the threat mitigation information, when entering into a mode TARA (ReCAL) of re-executing the Threat Analysis Risk Assessment to verify completeness of the security goal by determining whether a risk treatment scheme is risk acceptable. However, Salehie teaches re-calculating an Attack Feasibility Rating for each threat, among the one or more threats,[ based on i)assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating, corresponding to the security goal linked to the threat mitigation information,] (¶0074: Security concerns may change dynamically. For example, the value of asset application variables can be changed, and new vulnerabilities can be introduced by context modifications. These modifications are propagated onto the causal network by updating the value of its nodes 181 and/or its structure 180. Analysis is triggered after a change takes place (¶0094 The proposed approach uses the artifacts generated by security requirements engineering and risk assessment methods by adding an asset model which implies along with the re-calculation of the asset model the risk assessment is also re-executed), in order to re-calculate new utility values for all applicable configurations of security controls . The most appropriate set of security controls, exhibiting the highest utility, is selected and applied onto the running system. ) when entering into a mode TARA (ReCAL) of re-executing the Threat Analysis Risk Assessment to verify completeness of the security goal by determining whether a risk treatment scheme is risk acceptable. (¶0099: between a security control and a vulnerability (security control-vulnerability relationship) to indicate the impact that a security control has on mitigating that vulnerability; between a security control and a security requirement (security control-requirement relationship) to indicate the impact that a security control has on satisfying that security requirement; between a security requirement and a security goal (security requirement-security goal relationship) to indicate the impact that the satisfaction level of a security requirement has on the achievement of the corresponding security goal (security goal being verified); It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Salehie with regards to re-execution of an assessment to the method of Kang in view of Davidovich, Bhalla, and Choi in order to mitigate risks of future attacks in real time as assets, their values and/or the security context change (Salehie ¶0014). Kang in view of Davidovich, Bhalla, Choi, and Salehie does not disclose: re-calculating an Attack Feasibility Rating for each threat, among the one or more threats, based on i)assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating, corresponding to the security goal linked to the threat mitigation information, It is noted that Salehie does disclose re-execution of an assessment to verify the completeness of a security goal, but Salehie does not disclose re-calculate an Attack Feasibility Rating for each threat, among the one or more threats, based on i) assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating. However, Coull teaches re-calculating an Attack Feasibility Rating for each threat, among the one or more threats, based on i)assumption information mapped to the threat mitigation information and ii) a previously calculated Attack Feasibility Rating, corresponding to the security goal linked to the threat mitigation information, (¶0023-0026: Once the threat scores are calculated at 326, each threat score associated with a given object/node (i.e., initial/starting threat scores) is “propagated” to each of the other objects/nodes of the semantic graph through the calculation, at 328, of modified threat scores. The modified threat scores are normalized (e.g., to a sum of 1) at 330, and a subgraph of the semantic graph is identified, at 332,based on plurality of normalized threat scores. In some embodiments, a sub-graph is further analyzed by the processor (e.g., cyber-threat analyzer 200 of Figure 2) based on a pattern of communication identified as a “malicious lateral movement,” and a set of relevant mitigations may be associated with the subgraph, such that the subgraph and the associated mitigations are then presented to an analyst for action. ); It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Coull with regards to recalculating a rating being based on a previous rating and mitigation information to the method of Kang in view of Davidovich, Bhalla, Choi, and Salehie in order to detect cyber security threats and identify high-risk or anomalous activity (Coull ¶0003-0004). With respect to claim 12, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull teaches the method of claim 11 (see rejection of claim 11 above) a further comprising adding the security goal as the assumption information, when defining an item after entering into the mode (TARA (ReCAL) of re-executing the Threat Analysis Risk Assessment, and in response to receiving, from a user, the security goal serving as the assumption information. (Davidovich ¶0141-0146: As seen in Figure 5A, in stage 1650, security control optimization subsystem 60 generates a list of identified security control implementations, associated with the respective attack steps of the attack tree (or one or more attack paths) of the respective threat, that can be implemented on the respective item. In Figure 5B illustrates a high-level flow of a process of security control optimization subsystem 60 for further optimizing the security control implementation list of stage 1650. In some examples, in stage 1700, a risk goal for the item is set. In some examples, the risk goal is at least partially based on data in risk analysis information. 190. ). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Davidovich with regards to adding the security goal as the assumption information, when defining an item to the method of Kang in view of Bhalla, Choi, Salehie, and Coull in order to analyze the risk and impact of cyberattacks on a given component and its functionality (Davidovich ¶0003). With respect to claim 15, the combination of Kang in view of Davidovich and Salehie teaches the method of claim 11 (see rejection of claim 11 above) further comprising, when the Attack Feasibility Rating is re-calculated, (Davidovich ¶0193: In some examples, security control optimization subsystem 60 outputs information regarding one or more security controls associated with the respective asset such that the risk level of the asset can be reduced to a level that will allow the permissions. In some examples, security control optimization subsystem 60 updates security control list 80 accordingly (implying the rating is being re-calculated because the security control is being updated by an updated risk level). ) re-determining a risk value based on the re-calculated Attack Feasibility Rating. (Davidovich ¶0169 & ¶0213: In some examples, the term “risk level”, as used herein, is defined as a predetermined function of the respective feasibility rating and the respective impact value. In some examples, the impact value is a numerical indication of the impact that a particular threat will have on the respective asset (or on the item itself) if the respective threat is realized. In some examples, impact values are assigned numerical values, as known to those skilled in the art.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Davidovich with regards to a risk value based on the Attack Feasibility Rating to the method of Kang in view of Bhalla, Choi, Salehie, and Coull in order to analyze the risk and impact of cyberattacks on a given component and its functionality (Davidovich ¶0003). With respect to claim 16, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull teaches the method of claim 15 (see rejection of claim 15 above) further comprising determining a risk treatment scheme based on the re-determined risk value. (Salehie ¶0087-0097: . The FCN 180 is also augmented with the total risk node 1001 and utility node 1003. The total risk node 1001 aggregates all partial risks 1001, whereas the utility node 1003 aggregates a set of costs and benefits. Although the causal network 180 is designed to be used in a fully automatic adaptive mechanism, it may also be employed in a recommender system. Such a system analyzes impacts of asset changes and only recommends potential adjustments in security controls with their costs and benefits.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Salehie with regards to risk value to the method of Kang in view of Davidovich, Bhalla, Choi, and Coull in order to better configure security controls and parameters in a system in real time while decreasing risk of harm to the system (Salehie ¶0014-0015). With respect to claim 17, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull teaches the method of claim 16 (see rejection of claim 16 above) further comprising determining whether the risk treatment scheme is a scheme of Risk Acceptable. (Salehie ¶0106: The adaptive security manager applies the security controls that reflect the risk and the value of the assets to be protected, because the causal network computes the utility by taking into account the impact of the satisfaction of the security goals and the risk (Risk Acceptable) . An increase in the asset value can increase both the risk and the criticality of the security goals, however the configuration of security controls with the highest utility is selected as the value of the assets increases, thus more effective countermeasure are selected to guarantee the satisfaction of more critical security goals, and reduce a higher risk.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Salehie with regards to risk value to the method of Kang in view of Davidovich in order to better configure security controls and parameters in a system in real time while decreasing risk of harm to the system (Salehie ¶0014-0015). With respect to claim 18, the combination of Kang in view of Davidovich and Salehie teaches the method of claim 17 (see rejection of claim 17 above) further comprising, when the risk treatment scheme is determined as Risk Acceptable, determining completeness of the security goal as being verified. (Salehie ¶0099: between a security control and a vulnerability (security control-vulnerability relationship) to indicate the impact that a security control has on mitigating that vulnerability; between a security control and a security requirement (security control-requirement relationship) to indicate the impact that a security control has on satisfying that security requirement; between a security requirement and a security goal (security requirement-security goal relationship) to indicate the impact that the satisfaction level of a security requirement has on the achievement of the corresponding security goal (security goal being verified);). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Salehie with regards to risk value to the method of Kang in view of Davidovich, Bhalla, Choi, and Coull in order to better configure security controls and parameters in a system in real time while decreasing risk of harm to the system (Salehie ¶0014-0015). With respect to claim 19, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull teaches the method of claim 18 (see rejection of claim 18 above) but does not disclose further comprising: generating a result of verification completed, when the completeness of the security goal is determined as being verified, and outputting the result of the verification completed ( Kang: ¶0063: Meanwhile, in the present disclosure, when the level extraction unit 140 maps only one attribute of the functional correctness, the safety integrity, and the security assurance, the level extraction unit 140 may calculate the level of the corresponding attribute. Alternatively, when two or more attributes are mapped, the level extraction unit 140 may coordinate the level through a security activity execution status. The level produced through such a process may be derived for each security activity. In addition, the result is output in the graph form to determine the security-by-design methodology level at a glance. However, the present disclosure is not limited thereto. Meanwhile, the information generation unit 160 may provide second information for at least one required security activity related to the appropriate security-by-design methodology level of the level desired by the enterprise among at least one security activity included in the mapping result.) through an output device. ( Kang: ¶0181: A monitor 1144 or other types of display devices are also connected to the system bus 1108 through interfaces such as a video adapter 1146, and the like. In addition to the monitor 1144, the computer generally includes other peripheral output devices (not illustrated) such as a speaker, a printer, others.). Claims 3, 4, 13, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Kang et al (US PGPub No. 20230222247-A1 ) in view of Davidovich et al. (US PGPub No. 20250013754-A1) , Bhalla et al. (US PGPub No. 20190114435-A1), Choi et al. (US PGPub No. 20150058993-A1), Salehie et al. (US PGPub No. 20140090071-A1), Coull et al. (US Pat No. 11201890-B1), and Chen et al. (US PGPub No. 20090077666-A1 ) . With respect to claim 3, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull teaches the apparatus of claim 1 (see rejection of claim 1 above) but does not disclose, wherein the processor is configured to generate mapping information by mapping, based on a pre-stored database, i) threat mitigation information, derived with respect to each threat, among one or more threats, for each attack path, among one or more attack paths, based on a threat scenario to ii) treatment mitigation information linked to the security goal. However, Chen teaches wherein the processor is configured to generate mapping information by mapping, based on a pre-stored database, (¶0078-0081: T-MAP tool automates T-MAP to reduce the necessary human effort involved in security assessment. T-MAP tool can enumerate the possible attack scenarios for IT systems based on a vulnerability database that includes the information of more than 27,400 known software vulnerabilities. Each attack scenario can be specified with the following information: (1) the organizational value affected; (2) the vulnerable computer; (3) the vulnerable software; (4) the CVE name of the vulnerability; (5) the impact type of the vulnerability in terms of confidentiality, integrity, and/or availability; and (6) the patch availability of the vulnerability. A comprehensive COTS security vulnerability database is established 190 across current authority resources such as NIST, CERT, Microsoft, Symantec, and FrSIRT. Further, an automated tool is developed 195 to scrawl Internet resources across authority organizations such as NIST National Vulnerability Database (NVD), ISS, Microsoft, SANS, CERT, Symantec/BugTraq and FrSIRT to collect and update the vulnerability database continuously.) i) threat mitigation information, derived with respect to each threat, among one or more threats, for each attack path, among one or more attack paths, based on a threat scenario to (¶0086: As seen in Figure 3, T-MAP targets computer systems such as a IT infrastructure that may involve multiple host computers. A set of security evaluation criteria is established 320 based on stakeholder value propositions. Attack paths are enumerated and analyzed 330 based on a comprehensive COTS vulnerability database containing numerous vulnerability information or the holes. For example, 27,400 vulnerability information were used in one implementation. The severity of each scenario is evaluated 340 in terms of numeric ratings against the established evaluation criteria, which represent the size of the holes. The security threat of each vulnerability is quantified 350 with the total severity ratings of all attack paths that are relevant to this vulnerability. System total threat is quantified 360 with the total severity ratings of all attack paths. The cost-effectiveness of security protections are analyzed in 370 (threat mitigation information) based on what type of attack path are suppressed by the security protection) ii) treatment mitigation information linked to the security goal. (¶0076: As seen in Figure 1, shows an example process 100 for providing key components of a T-MAP analysis. A systematic framework is devised 110 to capture the stakeholder value priorities through Analytical Hierarchy Process (AHP) analysis and inject the value propositions into COTS vulnerability ranking. Empirical data points/case studies are provided 120 where the value-driven method (i.e., T-MAP) significantly outperforms the value-neutral methods in COTS security vulnerability prioritization. The technical details of thousands of software vulnerabilities are distilled 130 into executive-friendly language at a high-level. The traceability and consistency are systematically established 140 from organizational-level value propositions (security goal) to technical-level COTS security vulnerabilities and corresponding mitigation strategies.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Chen with regards to mapping to the method of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull in order to assure security, threats should be effectively to optimize resource allocation. (Chen ¶0068). With respect to claim 4, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, Coull, and Chen teaches the apparatus of claim 3 (see rejection of claim 3 above) wherein the processor is configured to: extract the threat mitigation information mapped to the threat mitigation information derived with respect to each threat, among the one or more threats, based on the mapping information and linked to the security goal; and ( Chen ¶0083: The T-MAP framework can be generated based upon the observations of: (1) the more security holes left open for an IT system, the less secure it is; (2) different IT servers might have different levels of importance in terms of supporting the business's core values; (3) the more vulnerabilities are exposed to motivated attackers, the more risk is involved. As a value driven approach, T-MAP uses the Attack Path concept to characterize possible scenarios wherein an attacker can jeopardize organizational values. T-MAP calculates the severity weight of each Attack Path (attack scenario) based on not only the technical severity of the relevant system vulnerability, but also its value impacts. T-MAP then quantifies the IT system threat with the total weight of all possible Attack Paths. Further is Figure 2, shows an example scenario of how a successful attack can affect organizational values (linking to the security goal). The core with a caption of "Org. Values" represents the key values that are important to an organization, for example, reputation and productivity;); apply the assumption information corresponding to the security goal linked to the extracted threat mitigation information to the treatment mitigation information derived with respect to each threat among the one or more threats. (Chen ¶0272-0274: Compared to value-neutral approaches, T-MAP systematically establishes the traceability and consistency from organizational-level value propositions to technical-level security threats and corresponding mitigation strategies. Compared to traditional risk management approaches, T-MAP does not require accurate values of probabilities, frequencies, and size of loss which are very difficult to estimate in practice. In all the three case studies conducted on real-life systems, T-MAP well captured the stakeholder value priorities through AHP pair-wise comparisons and injected the value priorities in attack path evaluation. The vulnerability rankings generated by T-MAP demonstrated strong correlations with the rankings generated by security professionals manually, with the R square values vary from 0.82 to 0.86. Based on the reasonably sound COTS vulnerability prioritization, T-MAP can be used to help to compare security practice alternative plans based on economic analyses in the ITS Server X case study (linking to security goals to mitigation information with respect to each threat) , wherein T-MAP demonstrated significant strength in estimating the effectiveness of security practices: the recommendation generated by T-MAP is consistent with the security manager's experience.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Chen with regards to mapping to the method of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull in order to assure security, threats should be effectively to optimize resource allocation. (Chen ¶0068). With respect to claim 13, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull teaches the method of claim 11 (see rejection of claim 11 above) but does not disclose further comprising generating mapping information by mapping, based on a pre-stored database, i) threat mitigation information, derived with respect to each threat, among one or more threats, for each attack path, among one or more attack paths, depending on a threat scenario to ii) treatment mitigation information linked to the security goal. However, Chen teaches further comprising generating mapping information by mapping, based on a pre-stored database, (¶0078-0081: T-MAP tool automates T-MAP to reduce the necessary human effort involved in security assessment. T-MAP tool can enumerate the possible attack scenarios for IT systems based on a vulnerability database that includes the information of more than 27,400 known software vulnerabilities. Each attack scenario can be specified with the following information: (1) the organizational value affected; (2) the vulnerable computer; (3) the vulnerable software; (4) the CVE name of the vulnerability; (5) the impact type of the vulnerability in terms of confidentiality, integrity, and/or availability; and (6) the patch availability of the vulnerability. A comprehensive COTS security vulnerability database is established 190 across current authority resources such as NIST, CERT, Microsoft, Symantec, and FrSIRT. Further, an automated tool is developed 195 to scrawl Internet resources across authority organizations such as NIST National Vulnerability Database (NVD), ISS, Microsoft, SANS, CERT, Symantec/BugTraq and FrSIRT to collect and update the vulnerability database continuously.) i) threat mitigation information, derived with respect to each threat, among one or more threats, for each attack path, among one or more attack paths, depending on a threat scenario to (¶0086: As seen in Figure 3, T-MAP targets computer systems such as a IT infrastructure that may involve multiple host computers. A set of security evaluation criteria is established 320 based on stakeholder value propositions. Attack paths are enumerated and analyzed 330 based on a comprehensive COTS vulnerability database containing numerous vulnerability information or the holes. For example, 27,400 vulnerability information were used in one implementation. The severity of each scenario is evaluated 340 in terms of numeric ratings against the established evaluation criteria, which represent the size of the holes. The security threat of each vulnerability is quantified 350 with the total severity ratings of all attack paths that are relevant to this vulnerability. System total threat is quantified 360 with the total severity ratings of all attack paths. The cost-effectiveness of security protections are analyzed in 370 (threat mitigation information) based on what type of attack path are suppressed by the security protection) ii) treatment mitigation information linked to the security goal. (¶0076: As seen in Figure 1, shows an example process 100 for providing key components of a T-MAP analysis. A systematic framework is devised 110 to capture the stakeholder value priorities through Analytical Hierarchy Process (AHP) analysis and inject the value propositions into COTS vulnerability ranking. Empirical data points/case studies are provided 120 where the value-driven method (i.e., T-MAP) significantly outperforms the value-neutral methods in COTS security vulnerability prioritization. The technical details of thousands of software vulnerabilities are distilled 130 into executive-friendly language at a high-level. The traceability and consistency are systematically established 140 from organizational-level value propositions (security goal) to technical-level COTS security vulnerabilities and corresponding mitigation strategies.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Chen with regards to mapping to the method of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull in order to assure security, threats should be effectively to optimize resource allocation. (Chen ¶0068). With respect to claim 14, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, Coull, and Chen teaches the method of claim 13 (see rejection of claim 13 above) further comprising: extracting the threat mitigation information mapped to the threat mitigation information derived with respect to each threat, among the one or more threats, based on the mapping information and linked to the security goal; (Chen ¶0083: The T-MAP framework can be generated based upon the observations of: (1) the more security holes left open for an IT system, the less secure it is; (2) different IT servers might have different levels of importance in terms of supporting the business's core values; (3) the more vulnerabilities are exposed to motivated attackers, the more risk is involved. As a value driven approach, T-MAP uses the Attack Path concept to characterize possible scenarios wherein an attacker can jeopardize organizational values. T-MAP calculates the severity weight of each Attack Path (attack scenario) based on not only the technical severity of the relevant system vulnerability, but also its value impacts. T-MAP then quantifies the IT system threat with the total weight of all possible Attack Paths. Further is Figure 2, shows an example scenario of how a successful attack can affect organizational values (linking to the security goal). The core with a caption of "Org. Values" represents the key values that are important to an organization, for example, reputation and productivity;); and applying the assumption information corresponding to the security goal linked to the extracted threat mitigation information to the treatment mitigation information derived with respect to each threat among the one or more threats. (Chen ¶0272-0274: Compared to value-neutral approaches, T-MAP systematically establishes the traceability and consistency from organizational-level value propositions to technical-level security threats and corresponding mitigation strategies. Compared to traditional risk management approaches, T-MAP does not require accurate values of probabilities, frequencies, and size of loss which are very difficult to estimate in practice. In all the three case studies conducted on real-life systems, T-MAP well captured the stakeholder value priorities through AHP pair-wise comparisons and injected the value priorities in attack path evaluation. The vulnerability rankings generated by T-MAP demonstrated strong correlations with the rankings generated by security professionals manually, with the R square values vary from 0.82 to 0.86. Based on the reasonably sound COTS vulnerability prioritization, T-MAP can be used to help to compare security practice alternative plans based on economic analyses in the ITS Server X case study (linking to security goals to mitigation information with respect to each threat) , wherein T-MAP demonstrated significant strength in estimating the effectiveness of security practices: the recommendation generated by T-MAP is consistent with the security manager's experience.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Chen with regards to mapping to the method of Kang in view of Davidovich, Bhalla, Choi, Salehie, and Coull in order to assure security, threats should be effectively to optimize resource allocation. (Chen ¶0068). Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Kang et al (US PGPub No. 20230222247-A1 ) in view of Davidovich et al. (US PGPub No. 20250013754-A1) , Bhalla et al. (US PGPub No. 20190114435-A1), Choi et al. (US PGPub No. 20150058993-A1), Salehie et al. (US PGPub No. 20140090071-A1), Coull et al. (US Pat No. 11201890-B1), Chen et al. (US PGPub No. 20090077666-A1), and Rogers et al. (US PGPub No. 20210352099-A1) . With respect to claim 10, the combination of Kang in view of Davidovich, Bhalla, Choi, Salehie, Coull, and Chen teaches the apparatus of claim 3 (see rejection of claim 3 above), but does not disclose further comprising a memory including the pre-stored database. However, Rogers teaches further comprising a memory ( ¶0094: The server system 118 also comprises one or more data stores 164 for persistently storing and managing collections of data, including databases such as a graph database 140, in one or more memory components 54, 56, 58 (for example).) including the pre-stored database. ( ¶0295: In operation, the risk objects as well as the sub-objects for risk scenarios and mitigation controls are stored in the graph database 140 like any other type in the system. So just like there are machines, vulnerabilities, storage and software entities with relationships between them, there are also risk objects, risk scenarios and mitigation control objects with relationships between them.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Rogers with regards to a memory including the pre-stored database to the method of Kang in view of Davidovich, Bhalla, Choi, Salehie, Coull, and Chen in order to effectively accurate list assets and help identify patterns which are indicative of anomalies that might be due to nefarious actions or comprised security (Rogers ¶0009-0017). Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAYLOR P VU whose telephone number is (703)756-1218. The examiner can normally be reached MON - FRI (7:30 - 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, Alexander Lagor can be reached at (571) 270-5143. 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. /T.P.V./ Examiner, Art Unit 2437 /MENG LI/ Primary Examiner, Art Unit 2437
Read full office action

Prosecution Timeline

Jun 25, 2024
Application Filed
Dec 02, 2025
Non-Final Rejection mailed — §101, §103, §112
Apr 02, 2026
Response Filed
Jun 27, 2026
Final Rejection (signed) — §101, §103, §112
Jul 29, 2026
Final Rejection mailed — §101, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12726815
SECURE MOBILE TRANSACTION APPARATUS AND METHOD
4y 3m to grant Granted Sep 01, 2026
Patent 12717917
PERSISTENT SECURITY CONFIGURATION MONITORING
4y 3m to grant Granted Aug 25, 2026
Patent 12717903
DETECTING UPLOADS OF MALICIOUS FILES TO CLOUD STORAGE
3y 8m to grant Granted Aug 25, 2026
Patent 12717960
METHOD AND DATA PROCESSING SYSTEM FOR EXECUTING AN OBFUSCATED COMPUTER PROGRAM
3y 3m to grant Granted Aug 25, 2026
Patent 12712713
GENERATING SHARED PRIVATE KEYS
3y 7m to grant Granted Aug 18, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
69%
Grant Probability
78%
With Interview (+8.4%)
3y 4m (~1y 1m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 36 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month