DETAILED ACTION
This communication responsive to the Application No. 18/462,817 filed on 02/26/2026. Claims 1-20 are pending and are directed towards software security management
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
Rejection of claims under 35 U.S.C. 101
Applicants’ arguments and amendments regarding claims 1-20 being rejected under 35 U.S.C 101 have been fully considered and are not persuasive. The amendments do not overcome the 101 rejection. Even considering the claim limitations as a whole, the claims remain directed to an abstract idea in the form of a mental process i.e., evaluating security-related information, determining a remediation recommendation, presenting the recommendation, receiving a selection, and updating a score based on that selection. The claims reciting concepts performed in the human mind, including observations, evaluations, judgments and opinions, fall within the mental process grouping and a claim may still recite a mental process even when nominally performed on computer. The additional recitations of “automatically determining”, “displaying” on a user interface, “receiving” a selected option and “updating” the displayed score do not change the character of the claim, because merely implementing the abstract idea on a computer, adding insignificant extra solution activity or generally linking the idea to a technological environment does not integrate the exception into a practical application. The components of WAF, IDS, IPS are invoked only as types of selectable security controls used within claimed decisions-making framework and does not recite any specific technological manner of implementing or configuring these. Hence, the rejection is maintained.
Rejections under 35 U.S.C 103:
Applicants' arguments regarding amended claims 1-20 being rejected under 35 U.S.C. § 103 over Roytman in view of Sturtevant in view of Kuppa have been fully considered and are moot because the new ground of rejection does not rely on the reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. A new reference Jeschke et al. (US 20110162073 A1) has been introduced to disclose the amended limitations. Roytman, Sturtevant, Jeschke disclose the claimed invention because together, they teach a security/risk scoring framework that evaluates software processes and associated vulnerabilities, presents the resulting risk information to a user through GUI, provides selectable remediation options in the form of the technology controls, including firewall, IPS, IDS controls and recalculates and presents updated risk indexes after the selected control is applied, including across enterprise business units and groups of devices.
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 therefore, subject to the
conditions and requirements of this title.
Claims 1,15 and 19 are rejected under 35 U.S.C. 101 because the claimed
invention is directed to non-statutory subject matter.
Independent claim
Step 1:
Claims 1, 15,19 are drawn to a method, therefore falls under one of four
categories of statutory subject matter (process/method, machines/products/apparatus
manufactures, and compositions of matter).
Step 2A, Prong 1:
Nonetheless, claims 1,15,19 is directed to a judicially recognized exception of an abstract idea without significantly more. Claim 1,15,19 recites a method of "identifying a security risk assessment', "determining, using a model, a security debt score", "comparing the security debt score”, “displaying” on a user interface, “receiving” selected option and “updating” the displayed score, enumerates a mental concept. human can evaluate data and make decisions. These are steps that are carried out using basic mental processes and mathematical evaluation which can be performed in the human mind or using pen and paper. As such, the steps of identifying, determining and comparing are nothing more than an abstract mental concept (MPEP 2106.04(a)(2)(III})).
Step 2A, Prong 2:
Claims 1,15 and 19 recites additional step of "determining, for a particular time
period, a minimum remediation for the at least one security defect" and "reducing the
security debt score based on detection of implementation of a compensating security
control including at least one of a web application firewall an intrusion detection system,
or an intrusion prevention system", "outputting an indication of the reduced security debt
score" that fails to integrate the abstract idea into a practical application. Determining a
remediation is a post- solution activity taken after the abstract idea is performed. This
additional step, to determine a remediation action constitutes as basic planning or
scheduling function and detection of implementation of a compensating control and
outputting the score are functional and outcome-based. These reflect the collection,
evaluation and presentation of security-related information and do not recite any
technical steps for deploying, enforcing or modifying the operation of a web application
firewall, IDS/IPS and hence is a form of insignificant extra solution activity where
updating a score based on detection is necessary for all uses of the judicial exception.
The additional step fails to integrate the abstract idea into a practical application
because it does not impose any meaningful limits on practicing the abstract idea (MPEP
2106.05(g)) (MPEP 2106.05(g)).
Step 2B:
The additional step that is a form of insignificant extra-solution activity, does not
amount to significantly more than an abstract idea because the courts have recognized
that this additional step to be well-understood, routine, and conventional when claimed
in a merely generic manner for comparison and determination (See MPEP
2106.05(d)(IN)(i)). As such claims 1,15 and 19 is not patent eligible.
Dependent claims
Dependent claims 2-14, 16-18, 20 are ineligible for the same reasons given with
respect to claims 1, 15, 19.
Step 1:
Claims 2-14, 16-18, 20 are drawn to a method, therefore falls under one of four
categories of statutory subject matter (process/method, machines/products/apparatus,
manufactures, and compositions of matter).
Step 2A-2B:
Dependent claims 2-14, 16-18, 20 recites additional steps of "identifying a largest
cause of the security debt score" and others that fails to integrate the abstract idea into
a practical application. These steps involve observation, evaluation, judgment and
opinion of a method that can be performed in a human mind. The steps performed in
the dependent claims are either of longstanding economic principles (interest) or routine
data processing steps that lack inventive concepts and amount to a mental or
mathematical process.
These additional steps that is a form of insignificant extra-solution activity, does
not amount to significantly more than an abstract idea because the courts have
recognized that this additional step to be well-understood, routine, and conventional
when claimed in a merely generic manner for identifying and determining a remediation
(See MPEP 2106.05(d)(II)(i)). As such dependent claims 2-14, 16-18, 20 are not patent
eligible.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Roytman et al. (US 20210336984 A1), hereinafter referred to as Roytman in view of Sturtevant et al. (US 20210406005 A1), hereinafter referred to as Sturtevant in further view of Jeschke et al. (US 20110162073 A1), hereinafter referred to as Jeschke.
As per claim 1, Roytman discloses a method for security debt management comprising:
identifying a security risk assessment including at least one security defect of an application; (Computing a time to remediate for asset vulnerabilities, computing a third time to remediate for the first category, Roytman, para [0010], claim 10. The asset vulnerabilities are processed to identify vulnerabilities in assets/ applications and categorizing them)
determining, using a model, a security debt score for the application based on the security risk assessment; (Causing displaying a remediation grid, identifying a number of asset vulnerabilities to be remediated within the first time, the second time, the third time and the fourth time, Roytman, claim 10, para [0025]).
However, Roytman does not explicitly disclose the limitations:
determining whether the security debt score is below a security debt threshold for the application by comparing the security debt score to [[a]] the security debt threshold for the application;
Sturtevant discloses:
determining whether the security debt score is below a security debt threshold for the application by comparing the security debt score to [[a]] the security debt threshold for the application; (Measured against the complete Zoo, Sturtevant, para [0136]. Output metrics are compared to benchmarks or "a Zoo" of reference values, functioning like comparing a score to a threshold).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman with Sturtevant by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sturtevant with Roytman in order to effectively determining output score to reduce risks (See Sturtevant, para [0136]).
However, Roytman in view of Sturtevant does not explicitly disclose:
in response to determining the security debt score is below the security debt threshold, automatically determining, for a particular time period, one or more remediation options a minimum remediation for the at least one security defect of the application to reduce the security debt score, the one or more remediation options including a [[the]] minimum remediation based on a minimum remediation due during the particular time period, the minimum remediation based on the at least one security defect and the security debt score;
displaying, on a user interface, the security debt score and a selectable menu including the one or more remediation options;
receiving a user selected remediation option from the one or more remediation options;
reducing the security debt score based on detection of implementation of the user selected remediation option, the user selected remediation option a compensating security control including at least one of a web application firewall, an intrusion detection system, or an intrusion prevention system; and
o updating, on the user interface, the displayed security debt score.
Jeschke discloses:
in response to determining the security debt score is below the security debt threshold, automatically determining, for a particular time period, one or more remediation options a minimum remediation for the at least one security defect of the application to reduce the security debt score, the one or more remediation options including a [[the]] minimum remediation based on a minimum remediation due during the particular time period, the minimum remediation based on the at least one security defect and the security debt score; (The risk index may be normalized so that it is within a predetermined range, such as zero to one hundred for a percent probability. The TRM application 124 then normalizes the risk index to lie within an accepted range, such as 10% and 90%. If there is a technology control to be processed (808), the process 800 applies (810) the technology control to the one or more software characteristics associated with one or more of the processes. Receiving a user input identifying a technology control to be applied to one or more of the software processes. Determining a set of risk indexes, at least one for each software process, wherein a modifier is applied to one or more software characteristic values associated with one or more software processes, the modifier depending at least in part on an extent to which the identified technology control or the administrative control increases or decreases a risk index associated with the software characteristic. The firewall technology control 128a reduces the software characteristic values for network usage and auditing by 5 and 2, respectively. That is, the firewall reduces the risk due to those characteristics, Jeschke, para [0029], [0031], [0045], [0046], claim 18. Here, the security debt score is interpreted to be the risk index/ CIAA risk index. The threshold is the predetermined or accepted range for the risk index)
displaying, on a user interface, the security debt score and a selectable menu including the one or more remediation options; (FIG. 4 is an example of a graphical user interface (GUI) 400 where a user may input the technology control information 128a. The GUI 400 includes a technology control list area 402 and a technology control details area 404. The details area 404 presents information about a technology control that is selected in the list area 402. The details area 404 presents the properties of the firewall technology control 128a and allows a user to input changes to the properties of the firewall technology control 128a. The process 800 presents (820) the risk model to a user, Jeschke, para [0027],[0049])
receiving a user selected remediation option from the one or more remediation options; (Receiving a user input identifying a technology control to be applied to one or more of the software processes. A user may make changes to the properties by making an input directly into the lists 408 and 410. Alternatively, the user may make an input using another method, such as by dragging and dropping compute devices from another location onto the firewall technology control, Jeschke, para [0028])
reducing the security debt score based on detection of implementation of the user selected remediation option, the user selected remediation option a compensating security control including at least one of a web application firewall, an intrusion detection system, or an intrusion prevention system; and (The firewall technology control 128a reduces the software characteristic values for network usage and auditing by 5 and 2, respectively. That is, the firewall reduces the risk due to those characteristics. The TRM application 124 calculates CIAA risk indexes for each of the processes 106a-c, 108a-c, 110a-c, and 112a-c based on their associated software characteristics information 126a-c as modified by the technology control information, Jeschke, para [0030])
updating, on the user interface, the displayed security debt score. (Calculating a first group of one or more risk indexes for the first scenario; identifying a second scenario, calculating a second group of one or more risk indexes for the second scenario, Jeschke, claim 19. Here, updating a displayed score is analogous to recalculating and presenting updated current versus simulated risk indexes/risk models on the UI).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman and Sturtevant with Jeschke by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores with assessing network risks of Jeschke. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Roytman and Sturtevant with Jeschke in order to effectively make remediation decisions more systematic and actionable (See Jeschke, para [0030])
As per claim 2, Roytman, Sturtevant and Jeschke discloses the method of claim 1, wherein
Furthermore, Sturtevant discloses:
the minimum remediation is determined based on the security debt score traversing the security debt threshold (Output metrics are mentioned all against benchmarks in a Zoo, Sturtevant, para [0033] and with refactoring scenarios forecast when metrics exceeds threshold, Sturtevant, Fig 14)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman with Sturtevant by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sturtevant with Roytman in order to effectively determining output score to reduce risks (See Sturtevant, para [0136]).
As per claim 3, Roytman, Sturtevant and Jeschke disclose the method of claim 1, wherein
Furthermore, Jeschke discloses:
the minimum remediation is based on a default minimum remediation for the particular time period when the security debt score does not traverse the security debt threshold (The risk index may be normalized so that it is within a predetermined range, Jeschke, para [0031]. Here, a score or range framework and a control application workflow is described which is analogous to a framework for applying controls depending on whether the score is within or outside an accepted range. The system’s default or available control application path when operating within the accepted range is the default minimum remediation).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman and Sturtevant with Jeschke by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores with assessing network risks of Jeschke. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Roytman and Sturtevant with Jeschke in order to effectively make remediation decisions more systematic and actionable (See Jeschke, para [0030])
As per claim 4, Roytman, Sturtevant and Jeschke disclose the method of claim 1, wherein
Furthermore, Roytman discloses:
the security risk assessment includes metadata corresponding to the at least one security defect, the metadata including at least one of type, severity, or age of the at least one security defect (Generating a remediation grid including asset vulnerabilities with attributes such as severity, vulnerability type and time since discovery, Roytman, para [0036])
As per claim 5, Roytman, Sturtevant and Jeschke discloses the method of claim 1, wherein
Furthermore, Sturtevant discloses:
the security risk assessment corresponds to a set of applications, and wherein the minimum remediation applies to at least one of the set of applications (Models may be applied across multiple applications of the same organization with forecasts produced for subsets which can be used for benchmarking and comparison, Sturtevant, para [0199], Fig 27, Fig 28).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman with Sturtevant by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sturtevant with Roytman in order to effectively determining output score to reduce risks (See Sturtevant, para [0136]).
As per claim 6, Roytman, Sturtevant and Jeschke discloses the method of claim 1, wherein
Furthermore, Jeschke discloses:
the security risk assessment corresponds to an enterprise, and wherein the minimum remediation applies to a common security defect among a plurality of applications of the enterprise (The business units 132a-c may be, for example, an accounting department, a human resources department, and a sales department, respectively, within an enterprise or business. A user may assign a group of computer devices to a technology control, such as a subnet of the network or a user defined functional area of the system 100. The aggregation may include weighting of process risk indexes relative to one another based on one or more variables such as security or threat trends, perceived likelihood of particular attacks, ubiquity of vulnerability in a business unit or organization, Jeschke, para [0048]. Here, risk assessment is equivalent to an enterprise and the security defect among a plurality of application is interpreted as a common vulnerability or software characteristic or risk condition that is aggregated across multiple processes/devices)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman and Sturtevant with Jeschke by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores with assessing network risks of Jeschke. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Roytman and Sturtevant with Jeschke in order to effectively make remediation decisions more systematic and actionable (See Jeschke, para [0030])
As per claim 7, Roytman, Sturtevant and Jeschke discloses the method of claim 1, wherein
Furthermore, Jeschke discloses:
the security risk assessment includes at least one compensating control for the application (The technology controls may include controls, such as software/firmware/hardware patch management, data storage re-imaging control, network/computer intrusion detection, intrusion prevention (e.g., a firewall). The TRM application 124 may further modify CIAA risk indexes using administrative control information 130a-c. Administrative controls are business processes or methods performed by users of the system 100 that effect technology risk. Determining a set of risk indexes, at least one for each software process, wherein a modifier is applied to one or more software characteristic values associated with one or more software processes, the modifier depending at least in part on an extent to which the identified technology control or the administrative control increases or decreases a risk index, Jeschke, para [0026], [0032]. Compensating control is interpreted as a technology control or administrative control that modifies the assessed risk rather than eliminating the underlying defect. Firewall and intrusion detection are compensating controls for the application)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman and Sturtevant with Jeschke by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores with assessing network risks of Jeschke. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Roytman and Sturtevant with Jeschke in order to effectively make remediation decisions more systematic and actionable (See Jeschke, para [0030])
As per claim 8, Roytman, Sturtevant and Jeschke discloses the method of claim 1, wherein
Furthermore, Roytman discloses:
the security debt score is based on an amount, a type, a severity, or an age of an unmet security requirement of the application (Vulnerabilities with attributes such as severity of the vulnerability are factored into remediation timeframe calculations, Roytman, para [0007]).
As per claim 9, Roytman, Sturtevant and Jeschke discloses the method of claim 1, wherein
Furthermore, Sturtevant discloses:
interest is accrued on the security debt score, and wherein the minimum remediation is increased for a subsequent time period based on the interest (If not paid will accrue interest over time as software quality continues to degrade. The total amount spent per year on the project is considered an interest payment on the system's technical debt. Using yearly interest payments and user-specified assumptions about the appropriate interest rate for capitalization, a tool can compute "principal" on the "loan." This value is the Technical Debt within the existing system, Sturtevant, para [0220]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman with Sturtevant by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sturtevant with Roytman in order to effectively determining output score to reduce risks (See Sturtevant, para [0136]).
As per claim 10, Roytman, Sturtevant and Jeschke discloses the method of claim 1, wherein
Furthermore, Roytman discloses:
the minimum remediation is increased at an end of a subsequent time period when the minimum remediation is not addressed during the subsequent time period (A time to remediate may be computed for only a subset of the first vulnerability data where the resolution of the vulnerability was remediation. A time to remediate may be computed for only a subset of the first vulnerability data where the resolution of the vulnerability was the use of the vulnerability in an attack. Multiple times to remediate may be computed using the subsets of the first vulnerability data, Roytman, para [0046]).
As per claim 11, Roytman, Sturtevant and Jeschke discloses the method of claim 1, further comprising
Furthermore, Sturtevant discloses:
displaying a carried debt balance, the minimum remediation, an interest accrued if the carried debt balance is not paid, and a penalty due if the minimum remediation is not addressed (Calculation and forecasting technical debt, and interest accrued is done, Sturtevant, para [0004]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman with Sturtevant by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sturtevant with Roytman in order to effectively determining output score to reduce risks (See Sturtevant, para [0136]).
As per claim 12, Roytman, Sturtevant and Jeschke discloses the method of claim 1, further comprising
Furthermore, Roytman discloses:
determining, for a subsequent time period, a future minimum remediation, before the subsequent time period, for the at least one security defect of the application to prevent a penalty based on the security debt score (The server computer is then able to categorize asset vulnerabilities in second vulnerability data corresponding to a particular networked environment and assign the computed time to remediate for each category to each asset vulnerability in said category, Roytman, para [0019]).
As per claim 13, Roytman, Sturtevant and Jeschke discloses the method of claim 1, further comprising
Furthermore, Sturtevant discloses:
identifying a largest cause of the security debt score including at least one of a programming language, a host, a deployment, or a framework of the application, and displaying the largest cause (Factors such as software source code attributes (such as code quality, design quality, test quality, and complexity metrics) and software economics/business outcome metrics (such as maintainability, agility, and cost) experienced by development and maintenance organizations are used in estimating technical debt, Sturtevant, para [0002]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman with Sturtevant by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sturtevant with Roytman in order to effectively determining output score to reduce risks (See Sturtevant, para [0136]).
As per claim 14, Roytman, Sturtevant and Jeschke discloses the method of claim 1, wherein
Furthermore, Sturtevant discloses:
the minimum remediation is based on a total technical debt score, the total technical debt score including the security debt score and at least one other technical debt score based on a bug or a missing feature of the application (Aggregating total technical debt score based on removing and fixing bugs. Software economic (SE) outcomes (or business outcomes) experienced by the productivity of developers when adding functionality or removing bugs, the fraction of time wasted fixing bugs, the cost and risk of quality or security problems, Sturtevant, para [0047])
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman with Sturtevant by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sturtevant with Roytman in order to effectively determining output score to reduce risks (See Sturtevant, para [0136]).
As per claim 15, Roytman discloses at least one non-transitory machine-readable medium including instructions for security debt management, which when executed by processing circuitry, cause the processing circuitry to:
identify a security risk assessment including at least one security defect of an application; (Computing a time to remediate for asset vulnerabilities, computing a third time to remediate for the first category, Roytman, para [0010], claim 10. The asset vulnerabilities are processed to identify vulnerabilities in assets/ applications and categorizing them)
determine, using a model, a security debt score for the application based on the security risk assessment; (Causing displaying a remediation grid, identifying a number of asset vulnerabilities to be remediated within the first time, the second time, the third time and the fourth time, Roytman, claim 10, para [0025]).
However, Roytman does not explicitly disclose the limitations:
determine whether the security debt score is below a security debt threshold for the application by comparison of
Sturtevant discloses:
determine whether the security debt score is below a security debt threshold for the application by comparison of (Measured against the complete Zoo, Sturtevant, para [0136]. Output metrics are compared to benchmarks or "a Zoo" of reference values, functioning like comparing a score to a threshold).
However, Roytman in view of Sturtevant does not explicitly disclose the limitations:
in response to determining the security debt score is below the security debt threshold, automatically determine, for a particular time period, one or more remediation options to reduce the security debt score, the one or more remediation options including a [[the]] minimum remediation period, the minimum remediation based on the at least one security defect and the security debt score;
display, on a user interface, the security debt score and a selectable menu including the one or more remediation options;
receive a user selected remediation option from the one or more remediation options;
reduce the security debt score based on detection of implementation of the user selected remediation option, the user selected remediation option
update, on the user interface, the displayed security debt score.
Jeschke discloses:
in response to determining the security debt score is below the security debt threshold, automatically determine, for a particular time period, one or more remediation options to reduce the security debt score, the one or more remediation options including a [[the]] minimum remediation period, the minimum remediation based on the at least one security defect and the security debt score; (The risk index may be normalized so that it is within a predetermined range, such as zero to one hundred for a percent probability. The TRM application 124 then normalizes the risk index to lie within an accepted range, such as 10% and 90%. If there is a technology control to be processed (808), the process 800 applies (810) the technology control to the one or more software characteristics associated with one or more of the processes. Receiving a user input identifying a technology control to be applied to one or more of the software processes. Determining a set of risk indexes, at least one for each software process, wherein a modifier is applied to one or more software characteristic values associated with one or more software processes, the modifier depending at least in part on an extent to which the identified technology control or the administrative control increases or decreases a risk index associated with the software characteristic. The firewall technology control 128a reduces the software characteristic values for network usage and auditing by 5 and 2, respectively. That is, the firewall reduces the risk due to those characteristics, Jeschke, para [0029], [0031], [0045], [0046], claim 18. Here, the security debt score is interpreted to be the risk index/ CIAA risk index. The threshold is the predetermined or accepted range for the risk index)
display, on a user interface, the security debt score and a selectable menu including the one or more remediation options; (FIG. 4 is an example of a graphical user interface (GUI) 400 where a user may input the technology control information 128a. The GUI 400 includes a technology control list area 402 and a technology control details area 404. The details area 404 presents information about a technology control that is selected in the list area 402. The details area 404 presents the properties of the firewall technology control 128a and allows a user to input changes to the properties of the firewall technology control 128a. The process 800 presents (820) the risk model to a user, Jeschke, para [0027], [0049])
receive a user selected remediation option from the one or more remediation options; (Receiving a user input identifying a technology control to be applied to one or more of the software processes. A user may make changes to the properties by making an input directly into the lists 408 and 410. Alternatively, the user may make an input using another method, such as by dragging and dropping compute devices from another location onto the firewall technology control, Jeschke, para [0028])
reduce the security debt score based on detection of implementation of the user selected remediation option, the user selected remediation option (The firewall technology control 128a reduces the software characteristic values for network usage and auditing by 5 and 2, respectively. That is, the firewall reduces the risk due to those characteristics. The TRM application 124 calculates CIAA risk indexes for each of the processes 106a-c, 108a-c, 110a-c, and 112a-c based on their associated software characteristics information 126a-c as modified by the technology control information, Jeschke, para [0030])
update, on the user interface, the displayed security debt score. (Calculating a first group of one or more risk indexes for the first scenario; identifying a second scenario, calculating a second group of one or more risk indexes for the second scenario, Jeschke, claim 19. Here, updating a displayed score is analogous to recalculating and presenting updated current versus simulated risk indexes/risk models on the UI)
As per claim 16, Roytman, Sturtevant and Jeschke disclose the at least one machine-readable medium of claim 15, wherein
Furthermore, Sturtevant discloses:
the minimum remediation is determined based on whether the security debt score traverses the security debt threshold, and when the security debt score does not traverse the security debt threshold, applying a default minimum remediation for the particular time period (Output metrics are mentioned all against benchmarks in a Zoo, Sturtevant, para [0033] and with refactoring scenarios forecast when metrics exceeds threshold, Sturtevant, Fig 14)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman with Sturtevant by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sturtevant with Roytman in order to effectively determining output score to reduce risks (See Sturtevant, para [0136]).
As per claim 17, Roytman, Sturtevant and Jeschke disclose the at least one machine-readable medium of claim 15, wherein
Furthermore, Roytman discloses:
the security risk assessment includes at least one compensating control for the application and metadata corresponding to the at least one security defect, the metadata including at least one of type, severity, or age of the at least one security defect (Generating a remediation grid including asset vulnerabilities with attributes such as severity, vulnerability type and time since discovery, Roytman, para [0036])
As per claim 18, Roytman, Sturtevant and Jeschke disclose the at least one machine-readable medium of claim 15, wherein
Furthermore, Sturtevant discloses:
the minimum remediation is based on a total technical debt score, the total technical debt score including the security debt score and at least one other technical debt score based on a bug or a missing feature of the application (Aggregating total technical debt score based on removing and fixing bugs. Software economic (SE) outcomes (or business outcomes) experienced by the productivity of developers when adding functionality or removing bugs, the fraction of time wasted fixing bugs, the cost and risk of quality or security problems, Sturtevant, para [0047])
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman with Sturtevant by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sturtevant with Roytman in order to effectively determining output score to reduce risks (See Sturtevant, para [0136]).
As per claim 19, Roytman discloses a system for security debt management comprising:
processing circuitry; (A processor, Roytman, para [0029])
a display device; (A display on a computing device, Roytman, para [0032])
memory, including instructions, which when executed by the processing circuitry, cause the processing circuitry to perform operations to: (Main memory, Roytman, para [0029]).
identify a security risk assessment including at least one security defect of an application; (Computing a time to remediate for asset vulnerabilities, computing a third time to remediate for the first category, Roytman, para [0010], claim 10. The asset vulnerabilities are processed to identify vulnerabilities in assets/ applications and categorizing them)
determine, using a model, a security debt score for the application based on the security risk assessment; (Causing displaying a remediation grid, identifying a number of asset vulnerabilities to be remediated within the first time, the second time, the third time and the fourth time, Roytman, claim 10, para [0025])
However, Roytman does not explicitly disclose the limitations:
determine whether the security debt score is below a security debt threshold for the application by comparison of
cause the display device to display a carried debt balance, the minimum remediation, an interest accrued if the carried debt balance is not paid, and a penalty due if the minimum remediation is not addressed;
Sturtevant discloses:
determine whether the security debt score is below a security debt threshold for the application by comparison of (Measured against the complete Zoo, Sturtevant, para [0136]. Output metrics are compared to benchmarks or "a Zoo" of reference values, functioning like comparing a score to a threshold).
cause the display device to display a carried debt balance, the minimum remediation, an interest accrued if the carried debt balance is not paid, and a penalty due if the minimum remediation is not addressed; (Calculation and forecasting technical debt, and interest accrued is done, Sturtevant, para [0004]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman with Sturtevant by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sturtevant with Roytman in order to effectively determining output score to reduce risks (See Sturtevant, para [0136]).
Roytman in view of Sturtevant does not explicitly disclose the limitations:
in response to determining the security debt score is below the security debt threshold, automatically determine, for a particular time period, one or more remediation options to reduce the security debt score, the one or more remediation options including a[[the]] minimum remediation period, the minimum remediation based on the at least one security defect and the security debt score;
cause the display device to display the security debt score and a selectable menu including the one or more remediation options;
receive a user selected remediation option from the one or more remediation options;
reduce the security debt score based on detection of implementation of the user selected remediation option, the user selected remediation option
cause the display device to update the displayed security debt score
Jeschke discloses:
in response to determining the security debt score is below the security debt threshold, automatically determine, for a particular time period, one or more remediation options to reduce the security debt score, the one or more remediation options including a[[the]] minimum remediation period, the minimum remediation based on the at least one security defect and the security debt score; (The risk index may be normalized so that it is within a predetermined range, such as zero to one hundred for a percent probability. The TRM application 124 then normalizes the risk index to lie within an accepted range, such as 10% and 90%. If there is a technology control to be processed (808), the process 800 applies (810) the technology control to the one or more software characteristics associated with one or more of the processes. Receiving a user input identifying a technology control to be applied to one or more of the software processes. Determining a set of risk indexes, at least one for each software process, wherein a modifier is applied to one or more software characteristic values associated with one or more software processes, the modifier depending at least in part on an extent to which the identified technology control or the administrative control increases or decreases a risk index associated with the software characteristic. The firewall technology control 128a reduces the software characteristic values for network usage and auditing by 5 and 2, respectively. That is, the firewall reduces the risk due to those characteristics, Jeschke, para [0029], [0031], [0045], [0046], claim 18. Here, the security debt score is interpreted to be the risk index/ CIAA risk index. The threshold is the predetermined or accepted range for the risk index)
cause the display device to display the security debt score and a selectable menu including the one or more remediation options; (FIG. 4 is an example of a graphical user interface (GUI) 400 where a user may input the technology control information 128a. The GUI 400 includes a technology control list area 402 and a technology control details area 404. The details area 404 presents information about a technology control that is selected in the list area 402. The details area 404 presents the properties of the firewall technology control 128a and allows a user to input changes to the properties of the firewall technology control 128a. The process 800 presents (820) the risk model to a user, Jeschke, para [0027],[0049]).
receive a user selected remediation option from the one or more remediation options; (Receiving a user input identifying a technology control to be applied to one or more of the software processes. A user may make changes to the properties by making an input directly into the lists 408 and 410. Alternatively, the user may make an input using another method, such as by dragging and dropping compute devices from another location onto the firewall technology control, Jeschke, para [0028])
reduce the security debt score based on detection of implementation of the user selected remediation option, the user selected remediation option (The firewall technology control 128a reduces the software characteristic values for network usage and auditing by 5 and 2, respectively. That is, the firewall reduces the risk due to those characteristics. The TRM application 124 calculates CIAA risk indexes for each of the processes 106a-c, 108a-c, 110a-c, and 112a-c based on their associated software characteristics information 126a-c as modified by the technology control information, Jeschke, para [0030])
cause the display device to update the displayed security debt score (Calculating a first group of one or more risk indexes for the first scenario; identifying a second scenario, calculating a second group of one or more risk indexes for the second scenario, Jeschke, claim 19. Here, updating a displayed score is analogous to recalculating and presenting updated current versus simulated risk indexes/risk models on the UI)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman and Sturtevant with Jeschke by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores with assessing network risks of Jeschke. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Roytman and Sturtevant with Jeschke in order to effectively make remediation decisions more systematic and actionable (See Jeschke, para [0030])
As per claim 20, Roytman, Sturtevant and Jeschke disclose the system of claim 19, wherein the instructions, when executed, further cause the processing circuitry to identify a largest cause of the security debt score including at least one of a programming language, a host, a deployment, or a framework of the application; and wherein the display device is further caused to display the largest cause (Factors such as software source code attributes (such as code quality, design quality, test quality, and complexity metrics) and software economics/business outcome metrics (such as maintainability, agility, and cost) experienced by development and maintenance organizations are used in estimating technical debt, Sturtevant, para [0002]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Roytman with Sturtevant by incorporating the method of computing times to remediate for asset vulnerabilities of Roytman in the system of Sturtevant to compute security scores. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sturtevant with Roytman in order to effectively determining output score to reduce risks (See Sturtevant, para [0136]).
Conclusion
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, RUPAL DHARIA can be reached on (571) 272-3880. 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.
Respectfully Submitted
/RAGHAVENDER NMN CHOLLETI/Examiner, Art Unit 2492
/RUPAL DHARIA/ Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights