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 .
Status of Claims
This communication is a Final Office Action in response to Applicant’s amendment for application number 18/952,523 received on 04/17/2026.
In accordance with Applicant’s amendment, claims 1-20 are amended, currently pending, and have been examined.
Response to Amendment
Applicant’s amendment necessitated the new ground(s) of rejection set forth in this Office Action.
Upon review of amendment, the §102 rejections previously applied to the claims are withdrawn. Claims 1-20 remain rejected under 35 U.S.C. 103 as necessitated by the amendments. See §103 rejections below for details.
Response to Arguments
Response to §101 arguments – Applicant’s arguments with respect to the §101 rejections previously applied to the claims have been considered and are unpersuasive.
Applicant argues (Remarks at pg. 9): “Further, as stated by the Memo on Reminders on Evaluating Subject Matter Eligibility of Claims under 35 U.S.C. 101 (hereinafter "the Memo"), "Examiners are cautioned not to oversimplify claim limitations and expand the application of the 'apply it' consideration. Moreover, examiners are reminded that the 'apply it' consideration often overlaps with the improvements consideration." The Memo, p. 4. Moreover, "When evaluating these two considerations, examiners may consider ... Whether the claim recites only the idea of a solution or outcome ... or the claim covers a particular solution to a problem or a particular way to achieve a desired outcome." Id.”. In response, Examiner reminds Applicant that the same memorandum states the following: “This memorandum is not intended to announce any new USPTO practice or procedure and is meant to be consistent with the existing USPTO guidance.” Therefore, the analysis and considerations of the office action mailed previously mailed are consistent with the August 4, 2025 memorandum (Reminders on evaluating subject matter eligibility of claims under 35 U.S.C. 101).
Applicant argues (Remarks at pg. 9): “Moreover, Applicant respectfully contends that claims 1-20 integrate any alleged abstract idea into a practical application and are therefore not directed to a judicial exception. In particular, claims 1-20 recite specific steps that accomplish a result that realizes an improvement in a technology or technical field, namely technical debt management technologies.”. In response, Examiner respectfully disagrees and notes that the additional elements do not integrate the abstract idea into a practical application because they amount to using generic computing elements (based on Examiner’s interpretation set forth in Claim Interpretation section above) or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or equivalent), which merely serves to link the use of the judicial exception to a particular technological environment (generic computing environment), or they provide nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f), or they are recited at a high level of generality, all of which fail to provide a technical improvement or otherwise integrate the abstract idea into a practical application.
Applicant argues (Remarks at pgs. 10-11): “Moreover, Applicant respectfully contends that amended claim 1 recites a specific improvement in computer functionality. MPEP § 2106.0S(a) states that "an examiner should evaluate whether a claim contains an improvement to the functioning of a computer or to any other technology or technical field at Step 2A Prong Two." As stated by the Memorandum for Advance notice of change to the MPEP in light of Ex Parte Desjardins (hereinafter "Ex Parte Desjardins Memo"), "the second paragraph of MPEP § 2106.0S(a), subsection I is revised to add new examples ... that may show an improvement in computer functionality." Specifically, as stated by page 4 of the Ex Parte Desjardins memo, MPEP § 2106.0S(a) now includes example xiv, which recites that "[i]mprovements to computer component or system performance based upon adjustments to parameters of a machine learning model associated with tasks or workstreams" may show an improvement in computer functionality. Ex Parte Desjardins memo, p. 4 (emphasis added).”. In response, Examiner respectfully disagrees and notes that the present claims do not provide an analogous improvement to the machine learning model (e.g. reinforcement learning model). Examiner respectfully asserts that the claims are unlike the Desjardins decision because the claims are directed to an abstract idea versus being directed to an improvement to computer functionality. The present claims do not provide an analogous technical solution to that of Desjardins because the claims do not “address challenges in continual learning and model efficiency by reducing storage requirements and preserving task performance across sequential training.” The fir one or more neural networks, the generative artificial intelligence models, and the reinforcement learning with human feedback of the present claims are merely a tool to perform the abstract process (i.e., process the input data). An improvement to the presented derived fulfillment service options would be an improvement to the abstract limitations for consideration under Step 2A, Prong 1 and not to the machine learning. MPEP 2106.05(a): “It is important to note, the judicial exception alone cannot provide the improvement. The improvement can be provided by one or more additional elements...” Additionally, as discussed in 2106.05(a)(II) improvements to technology or technical fields, “an improvement in the abstract idea itself … is not an improvement in technology”.
Accordingly, the §101 rejections previously applied to the claims are maintained and updated to address the amendments. See §101 rejections below for details.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-patentable subject matter. The claims are directed to an abstract idea without significantly more. The judicial exception is not integrated into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception as further set forth in MPEP 2106.
Step 1: The claimed invention is analyzed to determine if it falls outside one of the four statutory categories of invention. See MPEP 2106.03
Claim(s) 1-9 is/are directed to a system (i.e., Machine), claim(s) 10-18 is/are directed to a method (i.e., Process), and claim(s) 19-20 is/are directed to a non-transitory computer-readable medium (i.e., Manufacture). Therefore, the claims are directed to patent eligible categories of invention. Accordingly, the claims satisfy Step 1 of the eligibility inquiry.
As drafted, the limitations recited by the claims fall under the “Mental Processes” abstract idea group by setting forth activities that could be performed mentally by a human (including an observation, evaluation, judgment, opinion) (see MPEP § 2106.04(a)(2), subsection III).
Independent claim 1 recites a computing system for detecting, classifying, and predicting risk severity and/or likelihood from technical debt within an organization comprising a processor and a memory with the following abstract limitations: “obtain input data including internal organization information, third-party tool information, operational risk management information, previous technical debt assessments, previous asset rationalizations, and business capability information; process the input data; generate the risk severity and/or likelihood from technical debt based on the processing; predict a potential incident from the technical debt based upon the risk severity and/or likelihood; and generate an output of risk information associated with the risk severity, the potential incident, and/or likelihood from technical debt.”. But for the additional elements recited in this claim limitations, the steps in the limitations could be accomplished mentally, such as by human observation, evaluation, judgement, opinion, or with the help of pen and paper.
Independent claims 10 and 19 recite a method and a non-transitory computer-readable medium with limitations that are substantially similar to the limitations of claim 1, therefore, the same analysis applies.
Dependent claims 2, 3, 5, 11, 12, 14, and 20 further narrow the abstract idea and introduce further additional elements for consideration.
Dependent claims 4, 6-9, 13, and 15-18 further narrow the abstract idea and do not introduce further additional elements for consideration.
Step 2A, Prong 2: An evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the judicial exception into a practical application of the exception. See MPEP 2106.04(d).
Regarding the computing additional elements, namely a processor from claims 1/10/19, a memory from claim 1, and a non-transitory computer-readable medium from claim 19, these additional elements have been evaluated but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements (based on Examiner’s interpretation set forth in Claim Interpretation section above) or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or equivalent), which merely serves to link the use of the judicial exception to a particular technological environment (generic computing environment). See MPEP 2106.05(f) and 2106.05(h).
With respect to the limitations for “process the input data using a combination of one or more neural networks, generative artificial intelligence models, and reinforcement learning with human feedback”, “adjust, based on one or more evaluation metrics associated with the predicted potential incident, one or more weights of the one or more neural networks-”, and “predict, using the one or more neural networks, a potential incident from the technical debt based upon the risk severity and/or likelihood” from claims 1/10/19, these limitations fail to integrate the abstract idea into a practical application because they provide nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception.
With respect to the electronic dashboard from claims 2/11, the electronic dashboard has been considered under Step 2A Prong Two, however the electronic dashboard is recited at a high level of generality and fails to provide a technical improvement or otherwise integrate the abstract idea into a practical application.
With respect to the limitations for “a chatbot for interactive queries related to the risk severity and/or likelihood from technical debt” from claims 3/12, and “determine, via a first neural network, a risk from technical debt; classify, via a second model, a risk by category; or predict, via a third model, a potential risk from technical debt” from claims 5/14/20, these limitations fail to integrate the abstract idea into a practical application because they provide nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception.
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception.
Step 2B: The claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception. This analysis is also termed a search for "inventive concept." See MPEP 2106.05.
Regarding the computing additional elements, namely a processor from claims 1/10/19, a memory from claim 1, and a non-transitory computer-readable medium from claim 19, these additional elements have been evaluated, but fail to add significantly more to the claims because they amount to using generic computing elements (computer hardware) or instructions/software to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment (network computing environment) and does not amount to significantly more than the abstract idea itself. Therefore, the computing additional elements merely describe generic computing elements or computer-executable instructions (software) merely serve to tie the abstract idea to a particular operating environment, which does not add significantly more to the abstract idea. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976; Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
With respect to the limitations for “process the input data using a combination of one or more neural networks, generative artificial intelligence models, and reinforcement learning with human feedback”, “adjust, based on one or more evaluation metrics associated with the predicted potential incident, one or more weights of the one or more neural networks-”, and “predict, using the one or more neural networks, a potential incident from the technical debt based upon the risk severity and/or likelihood” from claims 1/10/19, these limitations fail to add significantly more to the abstract idea because the provide nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. Therefore, the additional elements merely describe generic computing elements or computer-executable instructions (software) merely serve to tie the abstract idea to a particular operating environment, which does not add significantly more to the abstract idea. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976; Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
With respect to the electronic dashboard from claims 2/11, the electronic dashboard has been considered under Step 2B, however the electronic dashboard is recited at a high level of generality and fails to provide a technical improvement or otherwise add significantly more to the claims.
With respect to the limitations for “a chatbot for interactive queries related to the risk severity and/or likelihood from technical debt” from claims 3/12, and “determine, via a first neural network, a risk from technical debt; classify, via a second model, a risk by category; or predict, via a third model, a potential risk from technical debt” from claims 5/14/20, these limitations fail to add significantly more to the abstract idea because the provide nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. Therefore, the additional elements merely describe generic computing elements or computer-executable instructions (software) merely serve to tie the abstract idea to a particular operating environment, which does not add significantly more to the abstract idea. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976; Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. Their collective functions merely provide generic computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to amount to significantly more than the abstract idea itself. The ordered combination of elements in the claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide generic computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to significantly more than the abstract idea itself.
Dependent claims 4, 6-9, 13, and 15-18 recite the same abstract ideas (“Mental Processes”) as the independent claims along with further steps/details falling under the scope of the abstract idea itself, along with the same or substantially same additional elements addressed above, which does not add significantly more to the judicial exception.
Accordingly, claims 1-20 are rejected under 35 U.S.C. 101.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 Sarkar (US 20230259860 A1, hereinafter “Sarkar”), in view of L. Aversano, M. L. Bernardi, M. Cimitile and M. Iammarino, "Technical Debt predictive model through Temporal Convolutional Network," 2021 International Joint Conference on Neural Networks (IJCNN), Shenzhen, China, 2021, pp. 1-8 (hereinafter “Aversano”).
Regarding claims 1/10/19: Sarkar discloses a system for detecting, classifying, and predicting risk severity and/or likelihood from technical debt within an organization comprising a processor and a memory having stored thereon computer-executable instructions ([0204] computing system 3500 may include, for example, a processor, memory, storage, and I/O devices (e.g., monitor, keyboard, disk drive, Internet connection, etc.). However, computing system 3500 may include circuitry or other specialized hardware for carrying out some or all aspects of the processes. In some operational settings, computing system 3500 may be configured as a system that includes one or more units, each of which is configured to carry out some aspects of the processes either in software, hardware, or some combination thereof.), a method ([0045] Disclosed are a system, method, and article of an advanced common controls framework (ACCF) for all risk domains of cyber security as prescribed in each framework.), and a non-transitory computer-readable medium having stored thereon instructions ([0205] The media drive unit 3518 can read/write a computer-readable medium 3520, which can contain programs 3522 and/or databases.), with limitations to:
obtain input data including internal organization information, third-party tool information, operational risk management information, previous technical debt assessments, previous asset rationalizations, and business capability information; ([0101] A risk identification, quantification, and mitigation engine can obtain data and analyze multiple complex risk problems. The risk identification, quantification, and mitigation engine can analyze, inter alia: global organization(s) data (e.g. multiple jurisdictions data, local business environment data, geo political data, culturally diverse data, etc.); multiple stakeholders data (e.g. business line data, functions data, levels of experience data, third party data, contractor data, etc.); multiple risk category data (e.g. operational data, regulatory data, compliance data, privacy data, cybersecurity data, financial data, etc.); complex IT structure data (e.g. system data, application data, classification data, firewall data, vendor data, license data, etc.); etc. The risk identification, quantification, and mitigation engine can utilize data that is aggregated and analyzed to create real-time, collective, and predictive custom reports for different CXOs. The risk identification, quantification, and mitigation engine can generate risk board reports. The risk board reports include, inter alia: a custom, risk mitigation decision-making roadmap. In this regard, the risk identification, quantification, and mitigation engine can function as an ERM program, performing real-time, on demand enterprise-wide risk assessments. For example, the risk identification, quantification, and mitigation engine can be integrated across, inter alia: technical Infrastructure (e.g. cloud-computing providers); application systems (e.g. enterprise applications focused on customer service and marketing, analytics, and application development); company processes (e.g. audits, assessments, etc.); business performance tools (e.g. management, etc.), etc. Examples of risk identification, quantification, and mitigation Engine methods, use cases and systems are now discussed.; [0150] This can include identifying and quantifying, inter alia: impact, likelihood of exposure in terms of cost, remediation cost, etc.);
process the input data using a combination of one or more neural networks, generative artificial intelligence models, and reinforcement learning with human feedback; ([0102] FIG. 1 illustrates an example process 100 for implementing risk identification, quantification, and mitigation engine delivery, according to some embodiments. Process 100 can enable an understanding of an enterprise's risk profile by providing a cross-organization risk assessment of current programs, risks, and resources. Process 100 can be used for risk mitigation. Process 100 can enable an enterprise to utilize AI and machine learning to understand their big data in real-time, thereby supporting the organization's business operations and objectives. Process 100 automation can be used to provide visibility into an enterprise's vertical businesses in real time (assuming for example, network and processing latencies). Additionally, enterprise stakeholders at all levels of an organization can use process 100 to identify important risk information specific to their individual roles and responsibilities in order to understand and optimize their risk profile. As noted, process 100 can utilize various data science algorithms and analytics, combined with AI and Machine Learning.; [0128] In step 506, process 500 can detect anomalies in risk values. The risk values are calculated according to the assessments-results for a given period. Process 500 can then make comparisons with the same week of a previous month and/or same month/quarter of a previous year. While doing the comparisons, the seasonality of risk can be considered along with its patterns as the risk may be just following a pattern even if it has varied widely from the last period of assessment. A machine learning algorithm (e.g. a Recurrent Neural Network (RNN), etc.) can be trained to detect these patterns and predict the approximate risk value that the user is expected to obtain during the upcoming assessments, according to the existing patterns in the data. The RNN can be trained on different types of patterns like sawtooth, impulse, trapezoid wave form and step sawtooth. Visualizations can display predicted versus actual values/scores and alert the users of anomalies.; [0069] Natural-language generation (NLG) can be a software process that transforms structured data into natural language. NLG can be used to produce long form content for organizations to automate custom reports. NLG can produce custom content for a web or mobile application. NLG can be used to generate short blurbs of text in interactive conversations (e.g. with a chatbot-type system, etc.) which can be read out by a text-to-speech system.; [0186] This is achieved by using artificial intelligence-based NLG techniques hardware risk information system 1200 can use the insights, and the templates and generate a human readable report.; [0068] Example machine learning techniques that can be used herein include, inter alia: decision tree learning, association rule learning, artificial neural networks, inductive logic programming, support vector machines, clustering, Bayesian networks, reinforcement learning, representation learning, similarity, and metric learning, and/or sparse dictionary learning.; [0139] Risk identification, quantification, and mitigation engine delivery platform 200 has the ability to suppress risk based on user feedback.);
generate the risk severity and/or likelihood from technical debt based on the processing; ([0108] Furthermore, specified templates can include compliance templates. Compliance templates are created to calculate a risk value of the effectiveness of the controls established in a specified organization. The established controls are checked against the results of assessments performed by clients. Based on the client's inputs, the AI engine calculates the risk value by comparing the prior control effectiveness (impact and probability) to current control effectiveness. It is noted that the risk value of any control can be the decision indicator based on the risk severity. Risk severity can be provided at various levels. For example, risk severity levels can be defined as, inter alia: critical, high, medium, low, or very low.; [0083] Risk likelihood is the chance of a risk happening—used to refer to the chance of something happening, whether defined, measured or determined objectively or subjectively, qualitatively, or quantitatively, and described using general terms or mathematically (e.g. such as a probability or a frequency over a given time period).; [0125] The collective impacts and likelihoods of the parts of the compliance assessments that are not selected can determine an upper level of the risk value. This can be based on pre-learned machine learning algorithms.; [0150] FIG. 10 illustrates an example process 1000 for enterprise risk analysis, according to some embodiments. In step 1002, process 1000 can implement risk and control identification. Risks and controls can be categorized by, inter alia: risk type, function, location, segment, etc. Owners and stakeholders can be identified. This can include identifying relevant COSO standards. This can include identifying and quantifying, inter alia: impact, likelihood of exposure in terms of cost, remediation cost, etc.; [0173] More specifically, in step 1602, process 1600 explores the various metrics of specified industries, regulations and systems and selects the right set of AI/ML modules that would be relevant. In step 1604, process 1600 derives the impact, likelihood, and risk value of the metrics along with anomalies.);
and generate an output of risk information associated with the risk severity from technical debt. ([0123] Risk values can be calculated and displayed in a customizable format and with a frequency that meets a specific client's needs.).
Sarkar doesn’t explicitly teach:
predict, using the one or more neural networks, a potential incident from the technical debt based upon the risk severity and/or likelihood;
adjust, based on one or more evaluation metrics associated with the predicted potential incident, one or more weights of the one or more neural networks;
Aversano teaches:
predict, using the one or more neural networks, a potential incident from the technical debt based upon the risk severity and/or likelihood; ([Abstract] this work aims to explore a deep learning approach to predict the rise of technical debt in software code by leveraging the knowledge of changing quality metrics.; [Page 3; C. TCN Predictive Model] Our predictive approach is based on a TCN network; [Fig. 1] Data extraction process and Classifier architecture; [Page 2; A. Background] Temporal convolutional networks, or simply TCNs [1] [4], are a variation of convolutional neural networks that relies on the use of random convolutions and dilations to fit sequential data with their temporality and wide reception fields.; [Page 2; B. Technical Debt] The existing tool that allows you to measure it is Sonar Qube. It is based on the SQALE method (Software Quality Assessment Based on Lifecycle Expectations), first introduced by J.Letouzey [20]. It is a generic method independent of language and tools. SCALE aims to (i) identify the elements that create debt, (ii) evaluate the possible impacts on the qualitative characteristics of the software (eg on the main tenance capacity), (iii) quantify the costs of correcting the factors that make up the debt. Therefore, this method is capable of doing all this said thanks to a quality model in which the different characteristics of the software are ordered according to the phases of the code development life cycle.);
adjust, based on one or more evaluation metrics associated with the predicted potential incident, one or more weights of the one or more neural networks; ([Abstract] For validation of the approach, a large dataset was built, related to four known Java software projects, with the collection of numerous class-level code quality metrics.; [Page 2] More specifically, the training of a DL network includes two main phases, the first, called forward, in which there is the propagation of the activation signals of the nodes, usually triggered by non-linear functions in DL, from the input level to that of output; the second, called backward, in which weights and biases are modified to improve the overall performance of the network.; [Page 5] Training phase: in which labeled traces, defined in (iv), is sent as input to the classifier while executing a super vised learning algorithm. The optimization of the hyper parameters is also performed to understand the best ones.;
It would have been obvious to one of ordinary skill in the art at the time of Applicant’s invention to combine Sarkar with Aversano’s features listed above. One would’ve been motivated to do so in order to predict the trend of the TD of source code components (i.e., classes), classifying it as: i) stable, ii) increased, and iii) decreased (Aversano; [Page 6; A. Experiment setting]). By incorporating the teachings of Aversano, one would’ve been able to successfully use a trained neural network to predict technical debt, based on severity and/or likelihood of the technical debt.
Regarding claims 2/11: Sarkar discloses:
wherein the risk information is output at an electronic dashboard that includes one or more of an impact of risk from technical debt, or the risk severity of the risk from technical debt. ([0110] Risk identification, quantification, and mitigation engine delivery platform 200 can include BI and visualization module 206. BI and visualization module 206 can provide a dashboard and/or other interactive modules/GUIs. BI and visualization module 206 can present the user with an easy to navigate risk management profile. The risk management profile can include the following examples, among others. BI and visualization module 206 can present a bird's eye view of the risks, based on the role of the user. BI and visualization module 206 can present the ability to drill into the factors contributing to the risk profile. BI and visualization module 206 can provide the ability to configure and visualize the risk as a risk value number using specified calculations. BI and visualization module 206 can provide the ability to adjust the weights for the various risks, with a view to perform what-if analysis. The BI and visualization module 206 can present a rich collection of data visualization elements for representing the risk state.).
Regarding claims 3/12: Sarkar discloses:
further comprising a chatbot for interactive queries related to the risk severity and/or likelihood from technical debt. ([0069] Natural-language generation (NLG) can be a software process that transforms structured data into natural language. NLG can be used to produce long form content for organizations to automate custom reports. NLG can produce custom content for a web or mobile application. NLG can be used to generate short blurbs of text in interactive conversations (e.g. with a chatbot-type system, etc.) which can be read out by a text-to-speech system.; [0074] Predictive Analytics includes the finding of patterns from data using mathematical models that predict future outcomes. Predictive Analytics encompasses a variety of statistical techniques from data mining, predictive modeling, and machine learning, that analyze current and historical facts to make predictions about future or otherwise unknown events. In business, predictive models exploit patterns found in historical and transactional data to identify risks and opportunities. Models can capture relationships among many factors to allow assessment of risk or potential risk associated with a particular set of conditions, guiding decision-making for candidate transactions.).
Regarding claims 4/13: Sarkar discloses:
further comprising instructions that, when executed, cause the computing system to: generate one or more notifications and/or one or more tasks associated with the risk severity and/or likelihood from technical debt; and provide the one or more notifications and/or the one or more tasks to one or more cross functional teams. ([0145] Notification Framework 910 generates notifications and other communications for the customer. Notification Framework 910 can create questionnaires automatically based on missing data. Notification Framework 910 can create risk reports automatically using Natural Language Generation (NLG). The output of Notification Framework 910 can be provided to visualization module 902 for inclusion in a dashboard view as well.); [0096] Persona is the aspect of a role or character that is adopted for presentment of information defined via neuroscience studies of fifteen (15) prospective users of the information provided both graphically, dynamically and/or via static visual presentment. Three separate personas are defined as Operational, Management and Executive for the embodiments reflective herein.; [0110] BI and visualization module 206 can present a bird's eye view of the risks, based on the role of the user.).
Regarding claims 5/14/20: Sarkar discloses:
wherein to generate the risk severity and/or likelihood from technical debt further comprises instructions that, when executed, cause the computing system to one or more of: determine, via a first neural network, a risk from technical debt; classify, via a second model, a risk by category; or predict, via a third model, a potential risk from technical debt. ([0068] Example machine learning techniques that can be used herein include, inter alia: decision tree learning, association rule learning, artificial neural networks, inductive logic programming, support vector machines, clustering, Bayesian networks, reinforcement learning, representation learning, similarity, and metric learning, and/or sparse dictionary learning.; [0108] Compliance templates are created to calculate a risk value of the effectiveness of the controls established in a specified organization. The established controls are checked against the results of assessments performed by clients. Based on the client's inputs, the AI engine calculates the risk value by comparing the prior control effectiveness (impact and probability) to current control effectiveness. It is noted that the risk value of any control can be the decision indicator based on the risk severity. Risk severity can be provided at various levels. For example, risk severity levels can be defined as, inter alia: critical, high, medium, low, or very low.; [0123] In step 502, process 400 can use process 600 to implement step 502. FIG. 6 illustrates an example of automatic risk value calculation process 600, according to some embodiments. Process 600 can calculate risk values. The risk values can determine the severity of the risk levels for an organization. Risk values can be calculated and displayed in a customizable format and with a frequency that meets a specific client's needs.).
Regarding claims 6/15: Sarkar discloses:
wherein the internal organization information includes one or more of code repositories, asset details, asset diagrams, or asset documents. ([0115] system administrators can define and manage all the Risk Models, Users, Configuration Settings, Automation etc. Additional documentation can be provided as part of implementing the system.).
Regarding claims 7/16: Sarkar discloses:
wherein the third-party tool information includes one or more of third-party asset documents, integration patterns, release and patch strategies, or data, compliance, and governance strategies. ([0101] Accordingly, examples of a risk identification, quantification, and mitigation engine are provided. A risk identification, quantification, and mitigation engine can obtain data and analyze multiple complex risk problems. The risk identification, quantification, and mitigation engine can analyze, inter alia: global organization(s) data (e.g. multiple jurisdictions data, local business environment data, geo political data, culturally diverse data, etc.); multiple stakeholders data (e.g. business line data, functions data, levels of experience data, third party data, contractor data, etc.); multiple risk category data (e.g. operational data, regulatory data, compliance data, privacy data, cybersecurity data, financial data, etc.); complex IT structure data (e.g. system data, application data, classification data, firewall data, vendor data, license data, etc.); etc. The risk identification, quantification, and mitigation engine can utilize data that is aggregated and analyzed to create real-time, collective, and predictive custom reports for different CXOs. The risk identification, quantification, and mitigation engine can generate risk board reports. The risk board reports include, inter alia: a custom, risk mitigation decision-making roadmap. In this regard, the risk identification, quantification, and mitigation engine can function as an ERM program, performing real-time, on demand enterprise-wide risk assessments. For example, the risk identification, quantification, and mitigation engine can be integrated across, inter alia: technical Infrastructure (e.g. cloud-computing providers); application systems (e.g. enterprise applications focused on customer service and marketing, analytics, and application development); company processes (e.g. audits, assessments, etc.); business performance tools (e.g. management, etc.), etc. Examples of risk identification, quantification, and mitigation Engine methods, use cases and systems are now discussed.).
Regarding claims 8/17: Sarkar discloses:
wherein operational risk management information includes one or more of operational risk categories, risk management documents, industry risk incident data and information, strategy and insights, or operational risk management reports. ([0101] Accordingly, examples of a risk identification, quantification, and mitigation engine are provided. A risk identification, quantification, and mitigation engine can obtain data and analyze multiple complex risk problems. The risk identification, quantification, and mitigation engine can analyze, inter alia: global organization(s) data (e.g. multiple jurisdictions data, local business environment data, geo political data, culturally diverse data, etc.); multiple stakeholders data (e.g. business line data, functions data, levels of experience data, third party data, contractor data, etc.); multiple risk category data (e.g. operational data, regulatory data, compliance data, privacy data, cybersecurity data, financial data, etc.); complex IT structure data (e.g. system data, application data, classification data, firewall data, vendor data, license data, etc.); etc. The risk identification, quantification, and mitigation engine can utilize data that is aggregated and analyzed to create real-time, collective, and predictive custom reports for different CXOs. The risk identification, quantification, and mitigation engine can generate risk board reports. The risk board reports include, inter alia: a custom, risk mitigation decision-making roadmap. In this regard, the risk identification, quantification, and mitigation engine can function as an ERM program, performing real-time, on demand enterprise-wide risk assessments. For example, the risk identification, quantification, and mitigation engine can be integrated across, inter alia: technical Infrastructure (e.g. cloud-computing providers); application systems (e.g. enterprise applications focused on customer service and marketing, analytics, and application development); company processes (e.g. audits, assessments, etc.); business performance tools (e.g. management, etc.), etc. Examples of risk identification, quantification, and mitigation Engine methods, use cases and systems are now discussed.).
Regarding claims 9/18: Sarkar discloses:
wherein the business capability information is based upon one or more business process diagrams, business documents, business strategies, or business capability reports. ([0063] Enterprise risk management (ERM) in business includes the methods and processes used by organizations to identify, assess, manage, and mitigate risks and identify opportunities to support the achievement of business objectives.; [0076] Risk Program, and Portfolio Management (RPPM). Risk management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific risk goals and meet specific success criteria at the specified time. Program management is the process of managing several related risks, often with the intention of improving an organization's overall risk performance. Portfolio management is the selection, prioritization and control of an organization's risks and programs in line with its strategic objectives and capacity to deliver.; [0090] Risk tolerance is the organization's or stakeholder's readiness to bear the risk after risk treatment in order to achieve its objectives.; [0095] Risk mitigation is the process of planning for disasters (e.g. threats) and having a way to lessen negative impacts. It refers to the process of planning and developing methods and options to reduce threats/risks to business, project, or operational objectives.).
Accordingly, claims 1-20 are rejected under 35 U.S.C. 103.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure:
Kosgi et al. (US 12197313 B1), which discloses various systems and methods for generating at least a portion of a technical debt management machine, at least a portion of a data management machine, or both.
Pandurangarao (US 11971804 B1), which discloses an intelligent technical debt helper bot system for receiving a level of technical debt associated with a technical debt of a computer program code and determine whether the level of technical debt is greater than a technical debt threshold.
Sarkissian (WO 2019183371 A1), which discloses a system for diagnosing risks, including risks that are any, or any combination, of: technical or non-technical, local or network-mediated, or internal or external to an organization.
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 GABRIEL J TORRES CHANZA whose telephone number is (571)272-3701. The examiner can normally be reached Monday thru Friday 8am - 5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Brian Epstein can be reached on (571)270-5389. 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.
/G.J.T./Examiner, Art Unit 3625
/SARA GRACE BROWN/Primary Examiner, Art Unit 3625
Prosecution Insights