DETAILED ACTION
This action is responsive to the Applicant’s response filed 8/11/26.
As indicated in Applicant’s response, claims 1-5, 8-9, 11-19 have been amended and claim 10 cancelled. Claims 1-9,11-20 remain and are pending prosecution by the following office action.
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.
Claim 8 is 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 the following 2-step analysis.
Step 1:
Claim 8 is directed to a process category
Step 2A
Prong one:
The elements recited as “identifying … set of logical changes”, “identifying … code change noise”, “refining … set of logical changes by iteratively removing … code change noise …until a level … is below a threshold”, “determining a set of risk score components …” and “aggregating the set of risk score component into a PR aggregate risk score” describe concepts performed in the human mind or capable of being performed mentally/with pen and paper. Evaluating code for noise, scoring risk, and filtering extraneous information are logical operations and evaluation/judgment functions that represent mental processes. MPEP 2106.04(a)
The combination of receiving code, parsing an AST to extract data, analyzing/refining the data, determining risk scores, and transmitting a report represents the abstract idea of collecting data, analyzing data, and displaying/transmitting the results of that analysis (see Electric Power Group, LLC v. Alstom SA, 830 F.3d 1350 (Fed. Cir. 2016); SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161 (Fed. Cir. 2018)).
Claim 8 therefore is seen as reciting limitations that fall within enumerated groupings of abstract Ideas, such as mathematical concepts and Mental processes. MPEP 2106.04(a)
Prong Two:
The recitations expressed generically as "computer method," “pull request”, "parsing an abstract syntax tree (AST)”, “logical changes”, "computer network," and “a risk report to PR reviewers" simply entail applying the abstract process on generic, conventional computer components and standard software engineering tools (AST parsing and PR review systems) or CI/CD pipeline performing their routine functions (see Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208 (2014)). MPEP 2106.04(d)(1)
The step of “receiving software code per a pull request” ( comprising changed files of software) and “transmitting a report” amount to a pre-activity and post-activity of no significance to effect of upconverting the Abstract Idea into a practical application; nor can this extra-solution activity bring forth improvement to the technical aspect of the computer components associated with the Abstract Idea. MPEP 2106.05(g)
The downstream steps of “altering the software code in accordance to … set of risk reduction actions” and “"creating a software application based at least on the altered software code" represent instances of high-level, generic post-solution activity. The claim does not specify how the computer specifically alters the code or how the application is built beyond conventional software compilation and execution techniques. Broadly reciting a desired outcome ("alter code" and "create application") without claiming specific technical improvements to the underlying computer/software system fails to integrate the abstract idea into a practical application. MPEP 2106.04(d)(2)
Accordingly, claim 8 does not recite limitations that can integrate the Abstract Idea into a practical application.
Step 2B
The additional element such as “receiving” PRs and software code is pre-activity to the Abstract idea as well as a well-understood, routine, and conventional activity in automated SW development environments. The additional element recited as “parsing an AST” is a well-known, standard technique used by conventional compilers and static analysis tools; thus fails to convey presence of a particular machine of transformation of significance to render the abstract idea clearly more than it already is. MPEP 2106.05.(a), (c) (e ) (f) (h). As additional element, the “transmitting” of reports across a computer network to “reviewers” is also viewed as generic data transmission, otherwise understood as extra-solution activity of little significance toward converting the Abstract idea into a patentable subject matter. MPEP 2106.05(g )
The additional elements recited as “altering code” and “creating an application” are standard steps in continuous integration/continuous development pipelines, which are also viewed as post-solution activities.
The ordered combination of these elements simply amounts to: receiving software code → parsing it via conventional means → performing abstract mathematical/mental data filtering and risk calculations → generating/transmitting a report → executing generic code updates based on the report.
This sequence merely reflects the natural, conventional workflow of automated code review and build systems. It does not improve the operational functioning of the computer system itself, nor does it provide a specific technical solution to a technical problem in computer architecture (see Digitech Image Techs., L.N.G. v. Electronics for Imaging, Inc., 758 F.3d 1344 (Fed. Cir. 2014)).
Therefore, the claim 8 fails to recite "significantly more" than the abstract idea itself, rendering claim ineligible under 35 U.S.C. 101.
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) 8 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 the following 2-step analysis.
A. Eligibility of claim 1
Step 1
The claim is directed to a system/apparatus category
Step 2A
Prong one:
The action steps recited as “identify… set of logical changes”, “identify … code change noise”, “refine … set of logical changes by iteratively removing … code change noise …until a level … is below a threshold”, “determine a set of risk score components …” and “aggregate the set of risk score component into a PR aggregate risk score” describe concepts performed in the human mind or capable of being performed mentally/with pen and paper. Evaluating code for noise, scoring risk, and filtering extraneous information are logical operations and evaluation/judgment functions that represent mental processes. MPEP 2106.04(a)
The combination of parsing an AST to extract data, analyzing/refining the data, determining risk scores, and transmitting a report represents the abstract idea of collecting data, analyzing data, and displaying/transmitting the results of that analysis (see Electric Power Group, LLC v. Alstom SA, 830 F.3d 1350 (Fed. Cir. 2016); SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161 (Fed. Cir. 2018)).
Prong Two
The recitations expressed generically as "processor," “pull request”, "parsing an abstract syntax tree (AST)”, “logical changes”, "computer network," and “a risk report” to "PR reviewers" simply entail applying the abstract process on generic, conventional computer components and standard software engineering tools (AST parsing and PR review systems) or CI/CD pipelines performing their routine functions (see Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208 (2014)). MPEP 2106.04(d)(1)
The step of “receive software code” per a “pull request” (comprising changed files of software) and “transmit a risk report” amount to a pre-activity and post-activity of no significance toward upconverting the Abstract Idea into a practical application; nor can this extra-solution activity bring forth improvement to the technical aspect of the computer components associated with the Abstract Idea. MPEP 2106.05(g)
The downstream steps of “alter the software code in accordance to … set of risk reduction actions” and “"create a software application based at least on the altered software code" represent instances of high-level, generic post-solution activity. The claim does not specify how the computer specifically alters the code or how the application is built beyond conventional software compilation and execution techniques. Broadly reciting a desired outcome ("alter code" and "create application") without claiming specific technical improvements to the underlying computer/software system fails to integrate the abstract idea into a practical application. MPEP 2106.04(d)(2)
Accordingly, claim 1 as recited fails to integrate the abstract Idea into a practical application.
Step 2B
The additional element such as “receive … PR and … software code” is extra-solution activity as well as a well-understood, routine, and conventional activity in automated SW development environments or extra-solution activity. The additional element recited as “parsing an AST” is a well-known, standard technique used by conventional compilers and static analysis tools; thus fails to convey presence of a particular machine transformation of significance to render the abstract idea substantially more than it already is. MPEP 2106.05.(a), (c) (e ) (f) (h). Also as additional element, the “transmit” of a report across a computer network to “reviewers” is a generic data transmission, otherwise understood as extra-solution activity that fails to add significantly more to the Abstract Idea. MPEP 2106.05(g )
The additional element recited as “alter code” and “create a software application” are standard steps in continuous integration/continuous development pipelines. Further, these activities rely on result of the determining, thus amounts to insignificant post-activity to the Abstract Idea. MPEP 2106.05(g)
The ordered combination of these elements simply amounts to: receiving software code → parsing it via conventional means → performing abstract mathematical/mental data filtering and risk calculations → generating/transmitting a report → executing generic code updates based on the report.
This sequence merely reflects the natural, conventional workflow of automated code review and build systems. It does not improve the operational functioning of the computer system itself, nor does it provide a specific technical solution to a technical problem in computer architecture (see Digitech Image Techs., L.N.G. v. Electronics for Imaging, Inc., 758 F.3d 1344 (Fed. Cir. 2014)).
Accordingly, claim 1 is directed to an abstract idea under step 2A
B. Eligibility of claim 18
Step 1
Claim 18 is directed to medium/product category.
Step 2A
Prong one:
The elements recited as “identifying … set of logical changes”, “identifying … code change noise”, “refining … set of logical changes by iteratively removing … code change noise …until a level … is below a threshold”, “determining a set of risk score components …” and “aggregating the set of risk score component into a PR aggregate risk score” describe concepts performed in the human mind or capable of being performed mentally/with pen and paper. Evaluating code for noise, scoring risk, and filtering extraneous information are logical operations and evaluation/judgment functions that represent mental processes. MPEP 2106.04(a)
The combination of parsing an AST to extract data, analyzing/refining the data, determining risk scores, and transmitting a report represents the abstract idea of collecting data, analyzing data, and displaying/transmitting the results of that analysis (see Electric Power Group, LLC v. Alstom SA, 830 F.3d 1350 (Fed. Cir. 2016); SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161 (Fed. Cir. 2018)).
Claim 18 is directed to an Abstract Idea subgroup of the Judicial Exception.
Prong Two
The recitations expressed generically as "computer", “pull request”, "parsing an abstract syntax tree (AST)”, “logical changes”, "computer network," and “a risk report to PR reviewers" simply entail applying the abstract process on generic, conventional computer components and standard software engineering tools (AST parsing and PR review systems) or CI/CD environment for performing their routine functions (see Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208 (2014)). MPEP 2106.04(d)(1)
The step of “receiving software code per a pull request” ( comprising changed files of software) and “transmitting … a report” amount to a pre-activity or post-activity of no significance to effect of upconverting the Abstract Idea into a practical application; nor can this extra-solution activity bring forth improvement to the technical aspect of the computer components associated with the Abstract Idea. MPEP 2106.05(g)
The downstream steps of “altering the software code in accordance to … set of risk reduction actions” and “"creating a software application based at least on the altered software code" represent instances of high-level, generic post-solution activity. The claim does not specify how the computer specifically alters the code or how the application is built beyond conventional software compilation and execution techniques. Broadly reciting a desired outcome ("alter code" and "create application") without claiming specific technical improvements to the underlying computer/software system fails to integrate the abstract idea into a practical application. MPEP 2106.04(d)(2)
Accordingly, claim 18 does not recite limitation that can integrate the Abstract Idea into a practical application.
Step 2B
The additional element such as “receive … PR and … software code” is extra-solution activity as well as a well-understood, routine, and conventional activity in automated SW development environments or extra-solution activity. The additional element recited as “parsing an AST” is a well-known, standard technique used by conventional compilers and static analysis tools; thus fails to convey presence of a particular machine of transformation of significance to render the abstract idea clearly more than it already is. MPEP 2106.05.(a), (c) (e ) (f) (h). The additional element of “transmit” of a report across a computer network to “reviewers” is a generic data transmission, otherwise understood as extra-solution activity that fails to add significantly more to the Abstract Idea. MPEP 2106.05(g )
Claim 18 is deemed non-eligible according to the 35 USC § 101 statute.
Step 2B analysis of 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 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 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-9, 11-20 are deemed un-eligible under the 35 USC § 101 statute.
Claim Rejections - 35 USC § 103
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, 3, 7-8, 11, 15-16, 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 Xu et al, CN 107977798 (translation) 09-12-2023, 8 pgs (herein Xu), and Seri et al, USPubN: 2025/0063061 (herein Seri) further in view of Cross et al, USPN: 12,015,630(herein Cross) and Hecht et al, USPubN: 2015/0007261 (herein Hecht)
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:
receive software code and a pull request (PR - para 0070), the PR comprising a plurality of files of the software code that are changed with the PR;
identify, within the plurality of files (risk factors … relevant code files – para 0054-0055), a set of logical changes (para 0015, 0019, 0022; code change via a pull request - para 0082; software changes - para 0053; code change 410 – Fig. 4),
wherein identifying the set of logical changes comprises parsing an abstract syntax tree (Analyzers 122 perform AnalyzeCode function … syntax tree, analysis of all code changes – para 0070) of the plurality of files (see above) to identify structural changes, the AST comprising nodes representing syntactic elements (para 0070 - Note1: syntax tree of software code reads on tree nodes representing syntactic elements of a code) of the software code;
aggregate the set of risk score components into a PR aggregate risk score (aggregate all results … and provide a unified risk score for all applications – para 0017);
determine a set of risk score components (risk factors - para 0054-0056) and a set of risk reduction actions (Developer actions 439, Prioritize 426 - Fig.4; proper fixes for remediating the detected issues - para 0050) based on the refined set of logical changes;
generate a risk reduction report (summary - para 0079; notification engine, engine 142 - para 0050; Spacetime Graph - para 0045-0047; para 0018; developer actions … which are also updated to the Spacetime Graph – para 0069- Note2: API provided from a risk workflow module to allow a spacetime graph to be presented with latest state of developers integration or actions – para 0052, 0055 - and understanding of current state of the application, security flaws – para 0047 - and factors or contexts related to risk factors and code changes – para 0053-0054 – for review of changes or assessment of risks – para 0085-0091 and updates made to the Graph – see para 0069, 0071 – reads on report summarizing state of developers integration and exposing various factors on the graph indicating of behavioral/process changes, risk factors and their assessment) indicating of risk factors (process-related risk factors - para 0055-0056 – see Note2), and natural language explanations (para 0057, 0059) for these factors (risk factors - para 0054; Behavioral risk factors - para 0055; Process related risk factors - para 0056) indicative of risk score (Note3: 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; para 0094-0095 - provided for consultation, editing and revising reads on assessment resulting in a high-level NL explanations of risk levels or factors - para 0054-0056 - affecting the unified score - risk score for all applications – para 0017 - being determined by the risk assess system in association with a PR) and risk reduction actions (e.g. Developer actions 439, Prioritize 426 - Fig.4; proper fixes for remediating the detected issues - para 0050)
alter the software code (developer 103 producer of the material changes and in charge of Remediation – para 0041; material software changes include … major functionality addition, new programming, new API, new library, new Lambda – para 0053) in accordance with the set of risk reduction actions (see above; Developer actions 439, Prioritize 426 - Fig. 4); and create a software application (track bugs, related to impact, risk acceptance etc. … coordinate development of software – par 0065-0066) based at least on the altered software code.
Plotnik does not explicitly disclose processor configured to
identify, within the set of logical changes, code change noise;
refine the set of logical changes by iteratively removing a portion of the code change noise from the set of logical changes until a level of the code change noise is below a threshold.
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” reduction (pg. 5) or removal of superfluous comments or dirty text (text contains a large amount of “noise” - 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.
Seri discloses determining scores based on vulnerability risks and averaging applicable score in function of the urgency of the vulnerable states of software components, such that the vulnerable states having score below a threshold may be filtered out as part of reducing noise in the prioritization of data associated with iterative mitigation activities (para 0071-0072; iteration of mitigation – para 0079) associated with security controls to reduce noise due to their irrelevancy to paths of activity of affected SW components (para 0105); hence states of components considered affected with a given level noise respective to a threshold as part of consideration to remove noisy SW components entails reference to threshold minimal to algorithmically carry out a filtering process as to whether a noise removing should be performed or not; i.e. based on which, a mitigation activity of filtering noise will proceed iteratively until a level of the code change by the denoising reaches a minimal endpoint of the filtering.
Therefore, based on iterative approach by Plotnik for risk assessment, penetrating test, security review and threat modeling geared for prioritizing SW change per a DevSecOps/security architecture, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement this iterative approach so that code changes are subjected to a prioritized determination as to which SW portions are significant to security screening and derivation of mitigation activities to address risk affecting those portions, the prioritized screening including detection is part of a noise capture and removal thereof as in Xu, according to which the set of logical changes can be refined via iteratively removing a portion of the code noise (from the initial set of logical changes) until a level of the code change noise is below a threshold – as per the threshold-based denoising in Seri – because
effect of a filtering algorithm, within the set of logical changes, by risk analysis to systematically identify and detect code change noise as redundant, unnecessary or detrimental to an efficient process of cleaning SW text associated with set of logical changes by way of iteratively removing a portion of the code change noise until a level of filtering reaches a satisfactory threshold of denoising using a threshold as reference endpoint, or stop-point as set forth above would render the set of code changes more syntactically and semantically cleaner, less cluttered so to efficiently aid the risk analysis over the PR code under processing by a remediation engine, the efficiency in code content filtering by the risk analytic thereby facilitating evaluation of risks per their magnitude of criticality, and a remediation decision to put emphasis/priority on certain vulnerability types affecting the software component or level of risk these vulnerability type represent, in that a set of corrective or risk-countering actions can be promptly determined (prioritized) to address a risk perceived per a given score or critical magnitude, so to enable timely dispatch of risk reduction actions to SW developer or architect entities responsible for the software changes request and pertinent risks exposed under a remediation engine associated with the PR.
B) Nor does Plotnik explicitly disclose processor configured to
(i) determine a set of risk score components and a set of risk reduction actions based on the refined set of logical changes;
(ii) generate a risk report indicating the PR aggregate risk score;
(iii) transmit the risk reduction report across a computer network to at least a portion of a set of PR reviewers
As for (i)
Refining code by way of denoising the code to progressively eliminate as much as possible redundant and unnecessary code portions so that the denoised result enable a more efficient vulnerability risk determination is shown with the filtering by Xu and Seri (see rationale A from above)
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) including updating the Spacetime Graph (para 0068; para 0087-0088), 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); thus determining set of risk score components is recognized.
Refining the set of logical changes is shown in Plotnik as various stages of developers actions, updating inputs and reassessing of risk based on information and patterns observed from per a multi-perspective view of nodes and edges in their time dimension on a SpaceTime Graph in conjunction with historical states of the application and the infrastructure, to identify risk and correlate the understanding with development context in order to prioritize corrective changes based the risk being assessed (para 0059; Fig. 3) via a Risk-based Workflow engine API (para 0052) where factor related to risk can be organized as Technical, Behavioral and Process-related risk factors or risk score components and a set of actions to remediate to the risk thus assessed include material changes by a developer in charge of Remediation (para 0041) or fixes (proper fixes for remediating the detected issues - para 0050), and material changes made (material software changes include … major functionality addition, new programming, new API, new library, new Lambda – para 0053) are depending of continual re-assessment of the states of changes observed on the Spacetime graph resulting from multiple instances of developer-based updates (para 0069, 0071)
Thus, refined state of code changes via updates on a graph being basis for determining set of risk score factors or components and a set of risk reduction actions is recognized – the latter referred to as (*)
As for (iii)
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 detect security controls 420[Wingdings font/0xE0]prioritize 426:
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 therewith 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 recommendations to an architect and developer is recognized.
Hence, report generated by a issue tracking system to the effect of explaining factors affecting the risk criticality by which to prioritize changes (para 0046-0047; 0073-0074) thereto or make modification to a reporting Graph can be viewed as effect of an aggregating risk measure onto a graph report, based on manipulation of a graph by the developers and architects (architect 102, developer 104 - Fig. 4) to understand, review and implement modification or remediation actions on basis of refining or updating the graph in response to security controls or detected changes (para 0069, 0070-0074).
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 contributive to 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
As for (ii) and (iii)
Presenting a report by a risk analysis platform where a plurality of risk types are aggregated on the report presentation is shown in Hecht’s Data Protection framework equipped with DP database; where DP risk scores are calculated via aggregating function over the identified DP resources, each aggregate score defining the severity gap to the given resource (Fig. 4-5; para 0165-0169) as well as risk impact (para 0186-0187), the aggregate risk score presented by a analytic tool of a Business entity (e.g. online banking) as function of a past score and a predefined threshold to support reviewing and detection of new changes to the cause-analysis investigation UI (para 0236; Fig. 7); i.e. the report presenting via a UI (para 0245) the aggregated risk score assessed for that business entity and changes thereto as result for reported changes to the identified severity gaps (para 0243), for enabling investigative review of the changes (para 0236) made to the risks as reported
Hence, presenting via a report of aggregated risk score by a DP protection module is recognized, and transmission of the report to reviewers for change to take effect 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 with actions configured to
1) determine a set of risk score components and a set of risk reduction actions based on the refined set of logical changes – as set forth per (*) from above
2) generate a risk report indicating the PR aggregate risk score - as per Hecht DP to enable investigative reviews as set forth above;
3) transmit the risk reduction report across a computer network to at least a portion of a set of PR reviewers – as forth in Cross and Hecht from above; 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 a investigation on the totality of risk factors, via a analytic report, expressed as a computed level of aggregated risk score ( as set forth above) would facilitate determination of a large scale impact so that more holistic case of criticality can be raised and a more appropriate mitigation 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 3, Plotnik does not explicitly disclose system of claim 1, wherein identifying the code change noise comprises performing a noise detection task selected from a set of tasks consisting of:
reformatting detection, renaming detection, refactoring detection, comment detection, and whitespace detection.
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) as part of 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 “dirty” text per a noise detect and removing 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 claim 7, Plotnik discloses 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:
receiving software code and a pull request (PR), the PR comprising a plurality of files of
the software code that are changed with the PR;
identifying, within the plurality of files software code of a pull request (PR), a set of logical changes, wherein identifying the set of logical changes comprises parsing an abstract syntax tree (AST) of the plurality of files to identify structural changes, the AST comprising nodes representing syntactic elements of the software code;
identifying, within the set of logical changes, code change noise;
refining the set of logical changes by iteratively removing a portion of the code change noise from the set of logical changes until a level of the code change noise is below a threshold;
determining a set of risk score components and a set of risk reduction actions PR aggregate risk score for based on the refined set of logical changes;
aggregating the set of risk score components into a PR aggregate risk score;
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;
altering the software code in accordance with the set of risk reduction actions; and creating a software application based at least on the altered software code.
( All of which having been addressed in claim 1)
As per claim 11, refer to rejection of claim 3.
As per claim 15, Plotnik does not explicitly disclose computer-implemented 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 – i.e. 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.
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:
receiving software code and a pull request (PR), the PR comprising a plurality of files of the software code that are changed with the PR;
identifying, within the plurality of files software code of a pull request (PR), a set of logical changes, wherein identifying the set of logical changes comprises parsing an abstract syntax tree (AST) of the plurality of files to identify structural changes, the AST comprising nodes representing syntactic elements of the software code;
identifying, within the set of logical changes, code change noise;
refining the set of logical changes by iteratively removing a portion of the code change noise from the set of logical changes until a level of the code change noise is below a threshold;
determining a set of risk score components and a set of risk reduction actions PR aggregate risk score for based on the refined set of logical changes;
aggregating the set of risk score components into a PR aggregate risk score;
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;
altering the software code in accordance with the set of risk reduction actions; and creating a software application based at least on the altered software code.
( All of which having been addressed in claim 1)
Claims 2, 9 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Plotnik et al, USPubN: 2020/0379879 (herein Plotnik) in view of Xu et al, CN 107977798 (translation) 09-12-2023, 8 pgs (herein Xu), and Seri et al, USPubN: 2025/0063061 (herein Seri) further in view of Cross et al, USPN: 12,015,630(herein Cross) and Hecht et al, USPubN: 2015/0007261 (herein Hecht) 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 creating the software application comprises merging the altered software code of the PR into a software code project.
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, which is 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 the changed 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 developer, 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 as to which risk or code change patterns to address first on basis of a recommendation module included with Plotnik's risk remediation environment, in that 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 and merge of corrected code into a knowledgebase repository or a current project, to reconcile existing code with additive changes thereof in a common knowledge base for long term usage or reuse toward new SW development.
As per claim 9, refer to rejection of claim 2.
Claim 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 Xu et al, CN 107977798 (translation) 09-12-2023, 8 pgs (herein Xu), and Seri et al, USPubN: 2025/0063061 (herein Seri) further in view of Cross et al, USPN: 12,015,630(herein Cross) and Hecht et al, USPubN: 2015/0007261 (herein Hecht) 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 a 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.
Claim 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 Xu et al, CN 107977798 (translation) 09-12-2023, 8 pgs (herein Xu), and Seri et al, USPubN: 2025/0063061 (herein Seri) further in view of Cross et al, USPN: 12,015,630(herein Cross) and Hecht et al, USPubN: 2015/0007261 (herein Hecht) and further 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 mitigation 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;
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 calculate 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.
Claim 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 Xu et al, CN 107977798 (translation) 09-12-2023, 8 pgs (herein Xu), and Seri et al, USPubN: 2025/0063061 (herein Seri)further in view of Cross et al, USPN: 12,015,630(herein Cross) and Hecht et al, USPubN: 2015/0007261 (herein Hecht) and further 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 computer-implemented 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 in Plotnik 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 model 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.
further of
Claim 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 Xu et al, CN 107977798 (translation) 09-12-2023, 8 pgs (herein Xu), and Seri et al, USPubN: 2025/0063061 (herein Seri) further in view of Cross et al, USPN: 12,015,630(herein Cross) and Hecht et al, USPubN: 2015/0007261 (herein Hecht), Yoshimura et al, JP 2014059743(translation) 04-03-2014 (herein Yoshimura), and Golchha et al, USPubN: 2025/0036898(herein Golchha), and further of Khare et al, USPubN: 2023/0176856 (herein Khare); 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 a 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 a 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 set of risk score components and the set of risk reduction actions 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)
Response to Arguments
Applicant's arguments filed 8/11/26 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
(A) The Applicant has submitted that as amended, the claim features include machine-generated AST which a human mind cannot generate; nor does the claim recite any mathematical concepts or calculations (Applicant's Remarks pg. 13), and that reviewing as described in the inventor Specifications include formatting, refactoring, noise removal, not conventional tooling (Applicant's Remarks pg. 14), notably when use of AST produces syntax-based diff output that shows edited nodes, all indicative of techniques of deriving logical changes and iteratively refining them against a noise threshold, consistent with the eligibility by English (Applicant's Remarks pg. 15) where when combined these techniques are not generic processes but implement change refining at a granular level, not well-understood or conventional processes.
At close analysis of each element thus mentioned, some elements are newly introduced features (preview with text-based diff, AST traversal, and iteratively filtering to a threshold of noise) and raise of eligibility merits for newly introduced limitations cannot be deemed proper as an initial Office action has to be provided first with detail in accordance to a prima facie case before the Applicant can respond.
(B) The Applicant has submitted that for the obviousness rejection to claims 1, 7-8, 15-16, as per the amendment, the features as claimed now include “parsing an AST” and “iteratively removing code change noise … until a level of code change noise is below a threshold”, and accordingly, the combination of Plotnik and Cross fails to teach and suggest the above features (Applicant's Remarks pg. 17).
The newly added features have triggered a change to the grounds of rejection therefore the above allegation would be deemed largely misplaced.
( C) The Applicant has submitted that for the obviousness rejection to claims 2,9, 18, as per the amendment, the features in claim 1 now include “parsing an AST” and “iteratively removing code change noise … until a level of code change noise is below a threshold”, and this is rendering the combination of Plotnik and Cross and Duhey well short of teaching these features (Applicant's Remarks pg. 18)
The newly added features have triggered a change to the grounds of rejection therefore the above allegation would be deemed largely misplaced.
(D) The Applicant has submitted that for the obviousness rejection to claims 3,11; or 4, and 12 as per the amendment, the features in claim 1 now include “parsing an AST” and “iteratively removing code change noise … until a level of code change noise is below a threshold”, and this is rendering the combination as employed in the office action (e.g. Xu, Plotnik, Cross, Yoshimura, Golchha, Khare) ) well short of teaching these features(Applicant's Remarks pg. 19-20)
Reliance to merits of newly introduced features would be deemed a improper or premature case of rebut.
(E) The Applicant has submitted that for the obviousness rejection to claims 5-6, and 17, as per the amendment, the features in claim 1 newly include “parsing an AST” and “iteratively removing code change noise … until a level of code change noise is below a threshold”, and this is rendering the combination of references cited (Plotnik, Cross, Wang, Masis, Golan, Oreilly, Broudou) well short of teaching these features(Applicant's Remarks pg. 21)
Reliance to merits of newly introduced features would be deemed an improper or premature case of rebut.
(F ) The Applicant has submitted that for the obviousness rejection to claims 19-20, the combination of references cited (Plotnik, Cross, WXu, Yoshimura, Golchha, Khare, Masis, Golan) fall well short of teaching the features now recited as “parsing an AST” and “iteratively removing code change noise … until a level of code change noise is below a threshold” (Applicant's Remarks pg. 22-23)
The newly added features have triggered a change to the grounds of rejection therefore the above allegation would be deemed largely misplaced.
In all, the claims as amended stand rejected as set forth above.
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee 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 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
Septembre 25, 2026
