CTNF 18/665,514 CTNF 79545 DETAILED ACTION This action is responsive to the Application filed 5/15/2024. Accordingly, claims 1-20 are submitted for prosecution on merits. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 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. Claim 8 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 8 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the following 2-step analysis. Step I. Claim 8 is directed to a method/process category. Step IIA. Prong One: The method claim includes steps of “identifying logical changes”, “determining a aggregate risk score”, “generating a report”, and these limitations fall into the Functional mental processes and Mathematical Concepts grouping of Abstract Ideas. For instance, “determining a PR aggregate score” is a mathematical calculation, manipulation of data to reach a numerical value – MPEP 2106.04(a)(2)(I) – and the limitations of “identifying”, “determining” and “explaining factors” are mental processes, i.e. acts that can be practically performed in the human mind or with aid of pen/paper, whereas reviewing code changes, explaining factors to assess risk is a long-standing activity performed by SW engineers manually. MPEP 2106.04(a)(2)(III) Prong Two: The limitation recited as “transmit” information (to a computer or a reviewer) is considered instructions to apply an exception expressing thereby a nominal field of use limitation, Plotnik discloses “computer network” and “risk score”, “risk reduction actions” are recited in a highly level of generality in association with generic functions of “identifying” and “transmitting” – MPEP 2106.04(d)(2)(I) - and as such, in a whole, the claim cannot signify an improvement in any technical field as these elements merely relate to automation of administrative/managerial task in risk assessment; hence the Abstract Idea cannot be integrated into a Practical Application. Step IIB. The additional elements in terms of generating “explanations” for factors (affecting risk and risk reduction) and “transmitting” are well-understood, routine or conventional activities in the field of development and data processing – MPEP 2106.05(d) – whereas to compute a risk score entails use of a tool to perform data analysis, thus does not improve computer functionality in a very particular and technical way – MPEP 2106.05(a) The claim when construed in the active order of elements, simply describe a standard workflow of code review process (look at changes, assess risk, and tell a reviewer) translated into generic computer environment; thus, does not transform the Abstract Idea into a patent-eligible application; nor do the above-mentioned elements add significantly more to the Exception. Claim 8 is deemed non-eligible under the 35 USC § 101 statute. Claims 1 and 18 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 1 and 18 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the following 2-step analysis A. Claim 1 eligibility Step I: claim 1 is directed to a system/apparatus category Step IIA Prong One: Claim 1 includes steps of “identifying logical changes”, “determining a aggregate risk score”, “generating a report”, and these are activities that can be performed by a human mind or via use of pen/paper, and/or using Mathematical Concepts being part of grouping of Abstract Ideas - MPEP 2106.04(a)(2)(I) Prong Two: The “computer network” and “risk score”, “risk reduction actions” are elements recited in a highly level of generality in association with generic functions of “identifying” and “transmitting” – MPEP 2106.04(d)(2)(I) – whereas the step of “transmitting” (report to a reviewer) ” is considered instructions to apply an exception expressing thereby a nominal field of use limitation or a extra-solution activity that makes use of result from a mental process, such that, as a whole the above elements cannot define an improvement in any technical field as they merely relate to automation of administrative/managerial task in risk assessment; hence the Abstract Idea cannot be integrated into a Practical Application Step IIB The additional elements in terms of generating “explanations” for factors (affecting risk and risk reduction) and “transmitting” are well-understood, routine or conventional activities in the field of development and data processing – MPEP 2106.05(d) – whereas the risk score element entails use of a tool to perform data analysis, thus does not improve computer functionality in a very particular and technical way – MPEP 2106.05(a); thus the additional elements fail to add significantly more to the Abstract Idea. Claim 1 is deemed non-eligible under the 35 USC § 101 statute B. Claim 18 eligibility Step I: this claim is directed to a product/device category. Step IIA Prong One: The recited steps of “identifying logical changes”, “determining a aggregate risk score”, “generating a report”, “identifying” change noise and “removing” change noise (from the changes) can be viewed as activities that can be performed in a human mind (identifying changes or noise) or via use of pen/paper (generate a report, removing noise) or using a mathematical tool (determine a score) all being grouped as mental processes or Mathematical concepts belonging to an Abstract Idea. MPEP 2106.04(a)(2)(I) Prong Two: The step of “transmitting” (report to a reviewer) ” is considered instructions to apply an exception expressing thereby a nominal field of use limitation or a extra-solution activity that makes use of result from a mental process; whereas the elements recited as “computer network” and “risk score”, “risk reduction actions” expressed in a highly generic form merely relates to a computer field of use, but cannot particularly delimit the mental process identified in step IIA. The elements recited as altering code and merging code are construed as extra-solution activities that rely on information derived from an Abstract idea, hence cannot integrate the Abstract Idea into a practical technique that particularly transforms a computer field issue into a non-conventional application, since these elements merely relate to automation of administrative/managerial task in risk assessment; hence the Abstract Idea cannot be integrated into a Practical Application Step IIB The additional elements in terms of generating “explanations” for factors (affecting risk and risk reduction) and “transmitting” are well-understood, routine or conventional activities in the field of development and data processing – MPEP 2106.05(d) – whereas the elements recited as altering code and merging code are construed as extra-solution activities that rely on information derived from an Abstract idea, thus these post-activities do not improve computer functionality in the field of reducing risk in a very particular and technical way – MPEP 2106.05(a); thus the additional elements fail to add significantly more to the Abstract Idea. Claim 18 is deemed non-eligible under the 35 USC § 101 statute. Step IIB analysis for the dependent claims. Claims 2 and 9 recite post, extra-solution activities of altering code of a PR and merging that code based on information obtained from a Abstract Idea, hence cannot significantly add more to the Abstract Idea Claims 3 and 10-11 recite identifying of noise and removing the noise from the code changes including task of reformatting, renaming, refactoring and whitespace detection, all being well-understood administrative tasks using information from a mental process; hence, claims 3 and 10-11 do not amount to significantly more than the Abstract Idea. Claims 4 and 12 depicts selection of a difference algorithms hence provision of a tool to assist identification of changes constitutes well-understood routines that fails to render the abstract Idea significantly more than itself. Claims 5 and 13 recite determining of a risk score of a given type and aggregate risk component into aggregate score; hence use of mathematical tool to generate a aggregate numerical value cannot significantly transform the Abstract Idea into technical improvement to the field of risk assessing or prevention. Claims 6, 14 and 20 recite aggregating risk score components for each PR into a PR aggregate score; hence use of mathematical tool to generate an aggregate numerical value cannot significantly transform the Abstract Idea into technical improvement to the field of risk assessing or prevention Claims 7 and 16 recite ranking risk actions according to a priority and indicate test case for each risk report; these extra-solution and post-activities do not significantly transform the Abstract idea beyond the well-known administrative opinion forming or observation by a mental processes. Claim 15 recites selecting a subset of reviewers based on aggregate risk score for each PR file; but selection being a assistive tool used for a mental process from step IIA cannot significantly add more to the Exception thereof; nor can it improve the risk assessing field with a particular inventive significance. Claim 17 recites receiving feedback from reviewers and using training to differentiate between logical or non-logical changes, which is similar to applying a tool to support a Judicial exception, hence fails to significant add more to the mental process associated with risk and identification of changes. Claim 19 recites the limitations of claims 2-5 hence these generic administrative activities fail to provide technical improvement to the field of risk reduction as set forth above. In all, claims 1-20 are deemed un-eligible under the 35 USC § 101 statute. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim s 1, 7-8, 15-16 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Plotnik et al, USPubN: 2020/0379879 (herein Plotnik) in view of Cross et al, USPN: 12,015,630 (herein Cross) As per claim 1 , Plotnik discloses a system comprising: a processor; and a computer-readable medium storing instructions that are operative upon execution by the processor to: identify, within software code of a pull request (PR – para 0070), a set of logical changes (para 0015, 0019, 0022; code change via a pull request – para 0082; software changes – para 0053); determine a PR aggregate risk score (aggregate the results … unified risk score - para 0017) for the set of logical changes (para 0015-0016); generate a risk reduction report (analysis summary - para 0079; notification engine, engine 142 – para 0050; Spacetime Graph – para 0045-0047; para 0018) indicating natural language explanation (para 0057, 0059) for factors ( Technical risk factors – para 0054; Behavioral risk factors – para 0055; Process related risk factors – para 0056) affecting the aggregate risk ( Note1 : risk assessment system providing a unified score on basis of analyzers performing scanning historic commits, tracking, and finding of time-related commits and relevant issues, material changes – para 0019 - whose risks include technical, behavioral and process-related factors – para 0020 - ending in a spacetime graph – Fig. 4 - provided for consultation, editing and revising reads on assessment resulting in a high-level NL explanations of risk factors – para 0054-0056 - affecting the unified score being determined by the risk assess system), and risk reduction actions (Developer actions 439, Prioritize 426 – Fig.4; proper fixes … for remediating the detected issues – para 0050). Plotnik does not explicitly disclose (i) risk reduction report for also indicating the PR aggregate risk score; and (ii) transmit the risk reduction report across a computer network to at least a portion of a set of PR reviewers As for (i) Plotnik discloses a Workflow engine resulting from adaptive governance rule and including a ticket created for issue-tracking system (para 0022-0023) and for suggesting code change in the source control system, the issue tracking system comprising a Spacetime Graph (para 0018) depicting historical states, patterns, commonalities and similarities of the repository code as result from code commits, contextual security and compliance controls, behavior profiles of the developers, “material” change dimensions that might affect the application (para 0024-0026), the workflow engine issuing governance rules that dictate which detected changes are material changes and what risk is attributed to them (para 0030; para 0085-0091), where the insights provided by the Spacetime graph include Material changes that might affect the infrastructure, and that factors affecting risk of each material changes can relate to Technical risk factors (para 0054), Behavioral risk factors (para 0055) and Process related risk factors (para 0056) Hence, report generated by a issue tracking system to the effect of explaining factors affecting the risk criticality by which prioritizing changes (para 0046-0047) thereto is recommended entails reporting effect of an aggregate risk measure, using natural language for architect and developers (architect 102, developer 104 – Fig. 4) to understand, review and implement actions. As for (ii) Plotnik discloses a flaw detector module traversing the Spacetime graph from the issue tracking system, to detect flaws in conjunction with a prioritization engine to communicate a simple digest for passing most prioritized areas to a Security architect or a developer for the latter to perform security review (para 0047; Spacegraph 300 [Wingdings font/0xE0] detect security controls 420[Wingdings font/0xE0]prioritize 426[Wingdings font/0xE0]: security Architect 102 – Fig. 4), the communication enabling a prioritization engine to question a software developer (developer 104 – Fig .4) via intermediary inquiry by the security architect (para 0077) on basis of the Spacetime graph, the question/answer interaction enabling delivery of summary to users or code change suggestion to be used by the Developers (para 0079-0080), where the code change suggestion and prioritization of changes are based on governance rules and weight given (“material”) to a risk or flaws (para 0081; para 0090-0091). Hence, communication of actions and prioritized recommendation to a architect and developer is recognized. As for (i) and (ii) Cross discloses security model of a NW computing environment (Fig. 2-3; col. 6 li. 41-47) in terms of a multi-channel remediation system generating a trend summary identifying patterns associated to an entity in terms of historical data risk scores or cybersecurity risk scores (col. 29 li. 56-66) based on detected vulnerabilities or issues under progress of a remediation (col. 30 li. 53-65), the vulnerability information provided history vault describing source severity and references and instructions to remediation executables (col. 61 li. 35-55) acquired from downloaded files; e.g. into a vulnerability summary displayed on a visual dashboard to be editable or manipulable (or sometimes non-editable) to authorized users (col. 69 li. 50 to col. 70 li. 17), the risk scores from analyzing the entities aggregated into a multi-dimensional score (col. 4 li. 49-56) according to arrangements with users (per username and permission/credentials) of the cybersecurity assurance system for them to have access to operations and information review via a configuration dashboard or UI (col. 20 li. 52- 67) by which to the system communicates remediation recommendations enabling the users to perform activities such as review and operations recommended by the system; e.g. using LAN, WAN network communication under the multi-channel cybersecurity assurance system (col. 9 li. 53 to col. 10 , li. 21) Hence, risk reduction report for also indicating the PR aggregate risk score, with explanation of factors contributing the severity of the risk, and communicating the risk reduction report/summary across a computer network to at least a portion of a set of reviewers is recognized. Therefore, as a summary type of explanations is provided by analyzers (para 0068) in high-level of NL (e.g. Spacetime graph – para 0095) for developers and architects to understand and implement actions (prioritization) recommended per effect of Plotnik’s risk assessment and remediation platform on basis of tracking and identifying risk factors underlying recognized “Material changes”, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the generated summary or report from the analyzers in Plotnik’s risk remediation system so that summarizing of analyzed data is consolidated 1) in risk action report indicating the PR aggregate risk score – as set forth in Cross ; and 2) transmit the risk reduction report across a computer network – as in Cross- to at least a portion of a set of reviewers or PR reviewers – as in Cross and Plotnik; because communicating of a analytic summary or report implemented in understandable NL to describe factors that contribute to the severity of a risk (a given score value) relevant to detected issues associated code changes identification (from PR instances) would enable recipient of such analysis to assess on effect by various type factors behind each risk so that decision can be rendered as what action to take or prioritize to address/remedy to the severity/impact caused by the level of that risk or risk score as derived from the risk factors communicated in analytic summary or NL explanation of the risk factors as set forth above, and by providing a communication scheme by which actions to recommend issue-mitigating actions associated with said risk report would enable architects, developers as well as SW reviewers to exchange information with the risk remediation system, so that an augmented understanding by the remediation system in regard to the combined cause-and-risk impact relationship can be otherwise adapted toward suggesting or proffering recipient developers with a more appropriate corrective actions that would provide the most efficient solution to address or reduce the severity of a code related issue. As per claim 7 , Plotnik does not explicitly disclose system of claim 1, wherein the instructions are further operative to: rank, within the risk reduction report, the risk reduction actions according to priority (prioritize them for the DevSecOps/security architect – para 0064; effects a Prioritize operation, proposed actions in a priority based order to the Security Architect – para 0076; claim 4, pg. 6; para 0021); and indicate, within the risk reduction report, test cases (para 0063-0064; initiate automatic Penetration, Testing event – para 0082; para 0067, 0092) for the software code of the PR. As per claim 8 , Plotnik discloses a computer-implemented method comprising: identifying, within software code of a pull request (PR), a set of logical changes; determining a PR aggregate risk score for the set of logical changes; generating a risk reduction report indicating the PR aggregate risk score, natural language explanations for factors affecting the PR aggregate risk score, and risk reduction actions; and transmitting the risk reduction report across a computer network to at least a portion of a set of PR reviewers. (all of which having been addressed in claim 1) As per claim 15 , Plotnik does not explicitly disclose method of claim 14, further comprising: selecting, for each file of the PR having a logical change, a subset of the set of PR reviewers, based on at least the file aggregate risk score and an identification of file-specific reviewers. But identification of behavioral Risk factors is shown in Plotnik as based on a number of developers, number of reviewers, the level of experience by each developer and the number of commit achieved in association with Material changes (para 0055); thus a PR instance and PR file specific to each developer and reviewers associated with a PR or review instance is recognized; where the hours of work and number of identified developers/reviewers in light of code commit and associated comments can serve as configuration of a AI/ML associated with the code change/commit activities (para 0063). Based on the type of risk factors being defined as technical type, behavioral type or Process-related type (para 0054-0056) a subset of work that implicate one such type of risk entails that a specific work by a given developer or reviewer can be responsible to cause a given type of risk to occur. Therefore, mapping a subset of the set of PR reviewers from all reviewers to correspond to a given type of risk factor would have been obvious (referred herein as (*)), the type being technical, behavioral or Process-related as set forth above. Thus, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement identification of risk factors and mapping of reviewer case in correspondence with a respective PR file so that the mapping includes selecting, for each file of the PR having a logical change, a subset of the set of PR reviewers, based on at least the file aggregate risk score and an identification of file-specific reviewers – as set forth above in (*); because comments and interactive input collected from each reviewer in association with risk score driven from a PR-related set of code changes can be captured and restructured into input of a training model that can classify or differentiate between code changes that are genuine to and those that are insignificant to the quality of SW development such as code forming or code ingesting; and by selecting a subset from a variety of users, developers, reviewers in order to map the work done by this specific subset with the amount of code changes in relevance to risk factor types as defined above would enable the very specific code-related information and input obtained from the specifically mapped subject of reviewers to be collected in order to configure them as input into a classification model that use artificial intelligence to further differentiate between logical changes identified with a given set of PR; i.e. based on which proper recommendation of risk-solving action can be generated as one or more solution to consider. As per claim 16 , refer to rejection of claim 7 . 07-21-aia AIA Claim s 2 ,9, 18 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Plotnik et al, USPubN: 2020/0379879 (herein Plotnik) in view of Cross et al, USPN: 12,015,630 (herein Cross) and further of Dubey et al, USPubN: 2022/0391807 (herein Dubey) As per claim 2 , Plotnik does not explicitly disclose system of claim 1, wherein the instructions are further operative to: alter the software code of the PR in accordance with the risk reduction actions identified within the risk reduction report ; and based on at least altering the software code of the PR in accordance with the risk reduction actions, merge the software code of the PR into a software code project . The Remediation system in Plotnik operates with risk analysis and governance rules in identifying material changes where code fix recommended (para 0050) to developers represent an improvement over a CI/CD pipeline (para 0005, 0006) where using a Spacetime graph (para 0043-0046) and analysis therefrom, output from developers in charge of the remediation can be integrated in system database (para 0052); e.g. new code under a change authorization being written to a DB (para 0053). Hence, developers responsible of creating new actions and ingesting code changes based on recommended actions from analytics made over a Spacetime Graph entails risk reduction actions associated with altering the software code identified per a PR in accordance to a developers in charge of implemented recommended actions based on a risk explanation report . Dubey discloses a predictive maintenance system operating with analytic tool and risk index and probability of failure are generated from machine learning (see Abstract, para 0005, 0007) included with the risk assessment platform, based of comparing various risk assessment factors (para 0024; claim 1 pg. 8), using a CI/CD pipeline (para 0043) in which code changes can be incremental and automated to support delivery of code by developers and/or allow code to be merged into the main code of project (para 0044) based on risk assessment factors. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement delivery of code changes and ingestion of change into code database in the risk assessment platform by Plotnik so that risk action report or descriptive summary can provide recommendation by developers including actions to alter the software code - as per Dubey developers - of the PR in accordance with the risk reduction actions - as per Plotnik’s analyzer of graph - identified within the report; and based on at least altering the software code of the PR in accordance with the risk reduction actions, merge the software code of the PR into a software code project – as set forth in Dubey; because investigation of improper practices and techniques from developer’s code changes under a PR access entails identification of risks and vulnerability associated with code editing faults or software committing defects as well as determining a measure of such risk and likely factors contributive to those risks for a given type of operation by a developers, and implementing a risk reducing analysis or action report to summarize descriptive relationship between code change risks and type of actions, events, and expose factors responsible for the degree risk or risk score would enable criticality weight to be assessed in regard to which risk or code change patterns to address first on basis of a recommendation module included with Plotnik’s risk remediation environment, where the recommendation can be passed or made available to SW developers or project architect/design personnel on basis of whom, corrective actions can be dispatched in accordance to discretion or prioritization effect of the developers or code change architect, including actions such as timely update/merge of corrected code into a knowledgebase repository or a current project. As per claim 9 , refer to rejection of claim 2. As per claim 18 , Plotnik discloses a computer storage device having computer-executable instructions stored thereon, which, on execution by a computer, cause the computer to perform operations comprising: identifying, within software code of a pull request (PR), a set of logical changes; identifying, within the set of logical changes, code change noise; removing, from the set of logical changes, the code change noise; determining a PR aggregate risk score for the set of logical changes; generating a risk reduction report indicating the PR aggregate risk score, natural language explanations for factors affecting the PR aggregate risk score, and risk reduction actions; transmitting the risk reduction report across a computer network to at least a portion of a set of PR reviewers; ((all of which having been addressed in claim 1) altering the software code of the PR in accordance with the risk reduction actions identified within the risk reduction report; and based on at least altering the software code of the PR in accordance with the risk reduction actions, merging the software code of the PR into a software code project. (refer to rationale of claim 2) 07-21-aia AIA Claim s 3, 10-11 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Plotnik et al, USPubN: 2020/0379879 (herein Plotnik) in view of Cross et al, USPN: 12,015,630 (herein Cross) and further of Xu et al, CN 107977798 (translation) 09-12-2023, 8 pgs (herein Xu) As per claim 3 , Plotnik does not explicitly disclose system of claim 1, wherein the instructions are further operative to: identify, within the set of logical changes, code change noise, wherein identifying the code change noise comprises performing a noise detection task selected from the set of tasks consisting of: reformatting detection, renaming detection, refactoring detection, comment detection, and whitespace detection; and remove, from the set of logical changes, the code change noise. Xu discloses performing a task associated with comment/noise detection (pg. 3) associated with word dominance processing that also includes characters modification/replacement and deleting blank (pg. 5) in regard to cleaning text representing a product under a risk evaluation method so to generate a quality risk evaluation of a multi-dimensional data via a fusion function and calculate a final score for the product under evaluation and risk level of the product according to the score (see Abstract; claim 1, pg. 7), where the comment detection is part of a noise capture and removal of superfluous comments or dirty text (pg. 3) Hence, identifying noise and unclean text per a noise detect and remove task included with text cleaning and characters refactoring/replacement is recognized. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement processing of code under risk evaluation under investigation initiated by a PR in Plotnik so that pre-processing within the set of code changes would identify, within the set of logical changes, code change noise, which comprises performing a noise detection task selected from characters reformatting or refactoring detection, comment detection, and whitespace detection as shown in Xu from above; so to remove, from the set of logical changes, the code change noise; because improper or superfluous text data consider irrelevant “noise”, including whitespaces and syntax considered worth deleting or substituted by better one when purged or removed systematically on the onset of a risk evaluation process can expunge insignificant information from the target text space as input into a risk assessing computer-based environment, as this target space when properly filtered and reduced into more compact and relevant content can be normalized into buckets or structured format deemed more compatible to specific computer-based processing models whereby the structured input can be easily parsed and understood by the model so that more context-specific derivation can be obtained for further in-depth analysis or recommendation(s) to be outputted in regard to actionable measures capable of significantly reducing the level of risk. As per claims 10-11 , Plotnik discloses method of claim 8, further comprising: identifying, within the set of logical changes, code change noise; and removing, from the set of logical changes, the code change noise. wherein identifying the code change noise comprises performing a noise detection task selected from the set of tasks consisting of: reformatting detection, renaming detection, refactoring detection, comment detection, and whitespace detection. (All of which having been addressed in claim 3) 07-21-aia AIA Claim s 4, 12 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Plotnik et al, USPubN: 2020/0379879 (herein Plotnik) in view of Cross et al, USPN: 12,015,630 (herein Cross) and further of Yoshimura et al, JP 2014059743(translation), 04-03-2014, 18 pgs (herein Yoshimura) and Golchha et al, USPubN: 2025/0036898(herein Golchha) and Khare et al, USPubN: 2023/0176856 (herein Khare) As per claim 4 , Plotnik does not explicitly disclose system of claim 1, wherein identifying the set of logical changes comprises performing a differences (diff) algorithm selected from the set of algorithms consisting of: a line-based diff, a token-based diff, a syntax-based diff, a semantic-based diff, and a logical change extraction. Yoshimura discloses evaluation of difference in group of source codes as part of an evaluation service associated with software maintenance and development product analysis (pg. 3-4) where comparison of source code includes logical line extraction that calculates the logical line number of the difference between source codes (bottom pg. 9, top pg. 10) to extract logical changes between the source codes where similarity evaluated therefrom is to satisfy a max value (pg. 10) as a scheme to reduce maintenance cost required for large-scale SW maintenance, using comparison such as diff algorithm known to comparing syntax between two source codes (pg. 2); hence diff algorithm directed for syntax comparing and logical line extraction is recognized. Golchha discloses determination of similarity accuracy and confidence score via ML model (para 0005) from scanning historical assets in function of metadata thereof, where the comparing applies a comparison algorithm to evaluate difference between extracted features (e.g. scanned labels) using token-based similarity measure (para 0043) Khare discloses assessment of vulnerability data via use of textual difference algorithm to compare two baselines to indicate differences in respective lines of tow text files, the line-based algorithm applicable to comparing text lines as well as byte groups in the two files (line-based, GNU diff - para 0035), the byte-for-byte diff producing number of differences that are semantically meaningful differences (para 0080; para 0020); hence line-based algorithm affording distinguish textual and semantic differences between two baselines is recognized. Thus, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement detection of conflict between source code elements associated with a PR instance as part of establishing risk aggregating or quantization in Plotnik so that identifying the set of logical changes comprises performing a differences (diff) algorithm – as set forth in Yoshimura and Khare - selected from the set of algorithms consisting of: a line-based diff (as per Khare), a token-based diff (as per Golchha), a syntax-based diff (as per Yoshimura, Golchha and Khare), a semantic-based diff (as per Khare), and a logical change extraction (as per Yoshimura); because line-based difference can establish a line-by-line files comparison that can be better presented for visual assessment, token-based difference can proffer a lower level of differentiation within the core syntax being compared, a typical syntax comparison utilizes less sophisticated resources for identifying visible differences between two texts, a semantic-based algorithm can eliminate irrelevant data and consolidate a difference that captures only semantically similar or different elements among two sets, and logical extraction algorithm exhibits difference or similarity on basis of the logical order of a text or lexical element such as it occurs within a line. As per claim 12 , refer to rejection of claim 4 . 07-21-aia AIA Claim s 5-6, 13-14 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Plotnik et al, USPubN: 2020/0379879 (herein Plotnik) in view of Cross et al, USPN: 12,015,630 (herein Cross) and further in view of Wang, Shu-qing, CN 113032435 (translation) 06-25-2021, 8 pgs (herein Wang), Masis, USPubN: 2022/0164175 (herein Masis) and Golan et al, USPubN: 2022/0405397 (herein Golan) As per claim 5 , Plotnik discloses system of claim 1 comprising instructions to aggregate the determined risk score components into the PR aggregate risk score (aggregate the results … unified risk score - para 0017) from the set of logical changes (para 0015-0016) associated with a PR. Plotnik does not explicitly disclose wherein determining the PR aggregate risk score comprises determining two or more risk score components from the set of risk score components consisting of: a bug data risk score, a code feature risk score, a test coverage risk score, a static code risk score, and a PR comment risk score. Risk scores can be determined from various risk-prone or risk-susceptible components such as bug and comment as per the risk assessment shown in Masis mitigating of SW risks (risk score based on bug report , risk score based on third party comment associated with code change – claim 13-14, pg. 7; para 0023); where code feature susceptible of risk is shown in Wang traversing of code database to derive risk score (pg. 2), where risk score associated with static code and test coverage on security risk is shown in Golan identification of SW security threats (risk score generated by the static code analysis – para 0034; Fig. 5; overall risk scores, one or more static risk scores, tests are applied to … overall risk scores determined at block 522 – para 0093; para 0081; static code analyzer, security threats, static code threshold tests – para 0070) Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement determination of aggregate risk score in Plotnik so that at least two risk components are based in the determining of the score, the components selected from a group of a bug data risk score (as in Masis), a code feature risk score (as in Wang), a test coverage risk score (as in Golan), a static code risk score (as in Golan), and a PR comment risk score (as in Masis); because bug data and comment can be considered information that are not directly relevant to the quality of code forming by the developers while they can distort or bias the objective assessment of the code change quality from a given PR instance; and static code and code features can include syntax and semantic that further add to the complexity of a risk detection or measurement process, and test coverage for a aspect of a code can introduce additional/hidden information and unsee constraints that need to be ironed out before a proper risk measurement or score determination can be finalized. As per claim 6 , Plotnik does not explicitly disclose system of claim 5, wherein the instructions are further operative to: for each file of the PR having a logical change, generate two or more risk score components from the set of risk score components; and aggregate, for each file, the determined risk score components into a file aggregate risk score; and aggregate the file aggregate risk scores into the PR aggregate risk score. As each PR in Plotnik entails a package initiated by a administrator or a developer seeking information over code changes (e.g. “Material changes”) or code committing (Plotnik: para 0018-0019, 0024-0026), a PR file in which a set of logical changes are identified when assessing risk entails a collection formed by a PR reviewer instance in which identification of factors (para 0020, 0028, 0054-0056) contributive to the measured risk or score targeted by the PR; e.g. in calculating an overall risk score upon the set of code changes included with the PR file instance. As risk score components can include at least two or more components as set forth in rationale of claim 5, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement aggregating contributive risk factors into a unified or overall risk score by Plotnik per effect of arranging steps to generate two or more risk score components from the set of risk score components, for each file of the PR having a logical change; and aggregate , for each file, the determined risk score components into a file aggregate risk score; and aggregate the file aggregate risk scores into the PR aggregate risk score; because the aggregating of risk based on granular change identified per each PR might relate to the very context of each risk type, and the very useful effect of aggregating individual score of any singular risk type into a more unified score is to assign a weight to each risk type corresponding to respective risk components in order to calculating a weighted summation of these individual scores, which entails selecting at least more than two individual scores obtained from contributing risk factors as set forth in rationale 5 from above, such that, a result from aggregating risk scores into overall file or PR aggregate risk score would generate a more meaningful and properly weighted number representing a unified risk score, which in turn, can be allocated to the very specific user or developer PR instance in relation to the amount of code changes identified and recorded with the instance. As per claim 13 , refer to rejection of claim 5. As per claim 14, refer to rejection of claim 6 . 07-21-aia AIA Claim s 17 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Plotnik et al, USPubN: 2020/0379879 (herein Plotnik) in view of Cross et al, USPN: 12,015,630 (herein Cross) further in view of O’Reilly et al, USPubN: 2023/0052116 (herein OReilly) and Broudou et al, USPubN: 2016/0321582 (herein Broudou) As per claim 17 , Plotnik does not explicitly disclose method of claim 8, further comprising: receiving, from at least a portion of the set of PR reviewers, feedback relating to the risk reduction report; and further training a logical change identifier to differentiate between logical changes and non-logical changes in software code and/or a risk assessor to determine risk score components using the feedback. Collecting number of developers and reviewers (para 0055) as well as factors contributive to risks such code commit and comments by the users is shown as part identifying risk factors and profiling users in accordance with developing testing and behavior analysis to calculate risk associated with each material SW change (para 0063-0064) in order to prioritize Development actions directed to the security architect, the material changes identified by AI training via effect of behavioral profiling (para 0024, 0027, 0032) Use of user feedback into a training is shown in Broudou ’s risk mitigation platform (para 0024; Fig. 2) thereby new governance rules can be generated to compute or refactor a potential risk value (para 0037-0039), the feedback acquired via an interface allowing the system to correct a incorrect assessment on risk by a ML stage and manipulating final value of the risk by a classifier (para 0102) OReilly risk mitigating system discloses improved ML for risk analysis (para 0013), where rules are adapted for suggesting real-time modifications using ML (para 0131) in that comments from users can be passed or posted (para 0149) as input into the system which categorizes input data destined to provide recommendation by the system (para 0129), the comment used provide guidance to generating better rules to refine conditions for detecting compliancy or non-compliancy of text (para 0169, 0171) targeted by the risk assessment framework, where training based thereon enable the system to identify non-compliance based on expert user input (para 0184-0185) Therefore, based on Plotnik’s use of artificial intelligence to manipulate rules in coordination with collecting reviewers data or comments as part of reviewer/developer profiling, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the risk assessment and generate recommendation on basis of collected profile data and risk factors into a Spacetime graph by Plotnik from above, so that the risk reduction system is configured with capabilities of receiving, from at least a portion of the set of PR reviewers, feedback – as per Broudou and OReilly - relating to the risk reduction report; and further training a logical change identifier to differentiate between logical changes and non-logical changes in software code and/or a risk assessor to determine risk score components using the feedback – similar to use of feedback to categorize compliant and non-compliant text per OReilly’s classifier approach; because consolidating a input space destined for intelligent analysis and artificial categorization by way of ML-based training in Plotnik risk remediation system so to derive useful and actionable recommendations to address PR corresponding code changes and resolve impact caused by risk score associated therewith in Plotnik stems from identification of code commits, behavior factors or definition of various risk factors, and as behavior of developers and reviewers constitutes one type of risk factors to consider for training by the AI/ML based recommendation system, acquiring user feedback or comments to form the user aspect of the training data would not only enlarge the scope of context or intent to train by the model, but insights gathered from expert and non-expert users as well as from non-experienced users and experienced developers via their feedback and comments would also enable filtering effect by the AI training to properly distinguish which input can be assessed or considered on basis of experience and expertise, and which input is to be construed only from a non-expert standpoint thereby to assign more weight to one and less weight to the other, the distinction enabling thereby the ML with possibility to derive a more accurate estimation of a risk or infer a more valid nature of a risk factor, the distinctive output based thereon enabling the risk remediation system in Plotnik to generate more appropriate risk mitigation recommendations; e.g. in response to code change defects raised by user initiating the PR instance . 07-21-aia AIA Claim s 19-20 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Plotnik et al, USPubN: 2020/0379879 (herein Plotnik) in view of Cross et al, USPN: 12,015,630 (herein Cross) further in view of Xu et al, CN 107977798 (translation) 09-12-2023, 8 pgs (herein Xu) and further of Yoshimura et al, JP 2014059743(translation), 04-03-2014 (herein Yoshimura), Golchha et al, USPubN: 2025/0036898(herein Golchha) and Khare et al, USPubN: 2023/0176856 (herein Khare); and further in view of Wang, Shu-qing, CN 113032435 (translation) 06-25-2021, 8 pgs (herein Wang), Masis, USPubN: 2022/0164175 (herein Masis) and Golan et al, USPubN: 2022/0405397 (herein Golan) As per claim 19 , Plotnik discloses computer storage device of claim 18, wherein identifying the code change noise comprises performing a noise detection task selected from the set of tasks consisting of: reformatting detection, renaming detection, refactoring detection, comment detection, and whitespace detection, (refer to rationale of claim 3) wherein identifying the set of logical changes comprises performing a differences (diff) algorithm selected from the set of algorithms consisting of: a line-based diff, a token-based diff, a syntax-based diff, a semantic-based diff, and a logical change extraction, (refer to rationale of claim 4) wherein determining the PR aggregate risk score comprises determining two or more risk score components from the set of risk score components consisting of: a bug data risk score, a code feature risk score, a test coverage risk score, a static code risk score, and a PR comment risk score; and wherein the operations further comprise: aggregating the determined risk score components into the PR aggregate risk score. (refer to rationale of claim 5) As per claim 20 , Plotnik discloses computer storage device of claim 19, wherein the operations further comprise: for each file of the PR having a logical change, determining two or more risk score components from the set of risk score components; and aggregating, for each file, the determined risk score components into a file aggregate risk score; and aggregating the file aggregate risk scores into the PR aggregate risk score. (refer to rationale of claim 6) Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609. Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100. /Tuan A Vu/ Primary Examiner, Art Unit 2193 April 30, 2026 Application/Control Number: 18/665,514 Page 2 Art Unit: 2193 Application/Control Number: 18/665,514 Page 3 Art Unit: 2193 Application/Control Number: 18/665,514 Page 4 Art Unit: 2193 Application/Control Number: 18/665,514 Page 5 Art Unit: 2193 Application/Control Number: 18/665,514 Page 6 Art Unit: 2193 Application/Control Number: 18/665,514 Page 7 Art Unit: 2193 Application/Control Number: 18/665,514 Page 8 Art Unit: 2193 Application/Control Number: 18/665,514 Page 9 Art Unit: 2193 Application/Control Number: 18/665,514 Page 10 Art Unit: 2193 Application/Control Number: 18/665,514 Page 11 Art Unit: 2193 Application/Control Number: 18/665,514 Page 12 Art Unit: 2193 Application/Control Number: 18/665,514 Page 13 Art Unit: 2193 Application/Control Number: 18/665,514 Page 14 Art Unit: 2193 Application/Control Number: 18/665,514 Page 15 Art Unit: 2193 Application/Control Number: 18/665,514 Page 16 Art Unit: 2193 Application/Control Number: 18/665,514 Page 17 Art Unit: 2193 Application/Control Number: 18/665,514 Page 18 Art Unit: 2193 Application/Control Number: 18/665,514 Page 19 Art Unit: 2193 Application/Control Number: 18/665,514 Page 20 Art Unit: 2193 Application/Control Number: 18/665,514 Page 21 Art Unit: 2193 Application/Control Number: 18/665,514 Page 22 Art Unit: 2193 Application/Control Number: 18/665,514 Page 23 Art Unit: 2193 Application/Control Number: 18/665,514 Page 24 Art Unit: 2193 Application/Control Number: 18/665,514 Page 25 Art Unit: 2193 Application/Control Number: 18/665,514 Page 26 Art Unit: 2193 Application/Control Number: 18/665,514 Page 27 Art Unit: 2193 Application/Control Number: 18/665,514 Page 28 Art Unit: 2193
Prosecution Insights