DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-2, 4-10, 12-16, and 18-19 are rejected under 35 U.S.C. 112(b) as being indefinite. Claims 1, 15, and 18 recite in the last limitation: “in response to detecting the event, automatically terminating and triggering re-execution…”. This is indefinite as it keeps re-executing in the loop once it detects at least one event resulting in a never-ending execution. Claim 3, 17, and 20 cure this deficiency by adjusting the artifacts involved in the static code check allowing for a possibility of the execution loop to end. Claim 11 cures this deficiency by setting a predetermined amount of re-executions before pausing further executions.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 7-8, and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210026760 A1 (Hereinafter referred to as Huth), US 20150160974 A1 (Hereinafter referred to as Kishore), and US 20200125448 A1 (Hereinafter referred to as von Trapp).
Regarding claim 1, Huth teaches:
A system comprising: at least one memory that stores instructions; and one or more processors configured by the instructions to perform operations comprising: accessing job structure metadata for an automated static code check, the job structure metadata defining a plurality of jobs of the automated static code check, (Para. [29], Huth shows "FIG. 1 shows a schematic of an exemplary execution tree structure, or tree 1, of a computer program representing different execution paths of the computer program. The tree structure 1 shown has nodes 10 to 19 as well as edges which connect the nodes along the execution paths. In this instance, node 10 is a root node, nodes 11, 12 and 13 are inner nodes and nodes 14 to 19 are leaf nodes. Also shown is a sub-tree 100 which includes inner node 11 and the leaf nodes or leaves 14 and 15. Each path in the execution tree structure from the root node 10 to one of the leaf nodes 14 to 19 corresponds to an execution path of the executed computer program. An example of an execution path can be provided by successive nodes 10, 11, and 15." Para. [33], Huth shows "in a computer-implemented static analysis an examination is carried out for the identified or selected sub-tree to see if an error can occur in the execution of a computer program execution path which is contained or represented in said sub-tree. The analysis may preferably supply three different results: “no error can occur”, “an error can occur”, or “unknown”, where “unknown” results if the testing system cannot decide, based on the analysis, whether an error can or cannot occur." Examiner notes the above citation shows a tree representing the paths that need to be analyzed and each execution path along the sub tree can be considered a different job. The tree itself can be considered the job structure. Although the job dependency is not explicitly stated the tree form implies a dependency on following earlier subtree in the root before going to the leaf node sub trees.)
commencing execution of the automated static code check (Para. [33], Huth shows "computer-implemented static analysis an examination is carried out for the identified or selected sub-tree to see if an error can occur in the execution of a computer program execution path");
while the automated static code check is in progress: automatically generating a plurality of snapshots of the automated static code check (Para. [46], Huth shows "information about sub-trees which have already been analyzed is stored and taken into account for the further analysis in order to avoid repeatedly analyzing the same sub-trees" Examiner notes the above citation shows recording information from the static analysis of the sub trees between executions of subtrees. Each sub tree is an execution path that can be considered a separate job for the static code analysis. Recording information from analyzed sub trees can be considered generating a snapshot of the static code analysis on that execution path for that job and that the job was completed.),
and detecting, based on the job structure metadata and a particular snapshot of the plurality of snapshots (Para. [29], Huth shows "Each path in the execution tree structure from the root node 10 to one of the leaf nodes 14 to 19 corresponds to an execution path of the executed computer program. An example of an execution path can be provided by successive nodes 10, 11, and 15." Para. [33], Huth shows "in a computer-implemented static analysis an examination is carried out for the identified or selected sub-tree to see if an error can occur in the execution of a computer program execution path which is contained or represented in said sub-tree. The analysis may preferably supply three different results: “no error can occur”, “an error can occur”, or “unknown”, where “unknown” results if the testing system cannot decide, based on the analysis, whether an error can or cannot occur." Examiner notes the above citation shows a tree representing the paths that need to be analyzed and each execution path along the sub tree can be considered a different job. The tree itself can be considered the job structure. Para. [22] Huth shows "the errors for which the system is examined in the static and/or the dynamic analysis include at least a runtime exception, a violated assertion, an assumption of an inadmissible system state, a system termination, an erroneous memory access, an erroneous resource access or a program lock-up, in particular a state in which a computer program ceases to run. By checking for these possible critical system errors, the security and seamless functioning of the system can be established. Also, in an especially preferred embodiment, determined errors, in particular the error types described, may be automatically fixed, in particular depending on the results of the dynamic analysis." Examiner notes the above citations above shows detecting errors based on static analyses. Errors occurring or being discovered during analysis can be considered an event),
Huth does not disclose:
the plurality of jobs being scheduled according to the job structure metadata such that execution of at least a first subset of the plurality of jobs is dependent on successful completion of at least a second subset of the plurality of jobs;
each of the plurality of snapshots indicating which of the plurality of jobs have been triggered and are still running at a respective point in time;
an event comprising at least one of a job failure within the automated static code check or the automated static code check exceeding a predetermined runtime threshold
and in response to detecting the event, automatically terminating and triggering re-execution of one or more of the plurality of jobs of the automated static code check
However, in the analogous art of job processing, Kishore teaches:
the plurality of jobs being scheduled according to the job structure metadata such that execution of at least a first subset of the plurality of jobs is dependent on successful completion of at least a second subset of the plurality of jobs (Para. [56], Kishore shows "workflow manager 302 can schedule jobs for execution by task runner 312. In scheduling jobs, workflow manager 302 can infer dependencies between jobs and a corresponding execution order for dependent jobs based on the analyst's specifications of data objects produced and consumed by various jobs." Examiner notes the above citation shows jobs being scheduled based on their dependency on another being completed);
In addition, in the analogous art of failure prediction in workflow, von Trapp teaches:
each of the plurality of snapshots indicating which of the plurality of jobs have been triggered and are still running at a respective point in time (Para. [32], Von Trapp shows 'Work processes (e.g., 205) are server processes implemented within the automation engine to perform the actual server work in various automations, such as activating, generating, and executing tasks within a given automation job, together with monitoring the status of the tasks and collecting information (and generating report data) relating to the completion of these tasks. Work processes 205 may retrieve tasks from a queue, with the tasks including logic executable by the work process to cause the work process to perform a particular type of task. When the work process 205 accesses a next task from the queue, it may retrieve corresponding logic and perform the next task, which may be the same or a different type of task than the task previously performed by the work process." Examiner notes the above citation shows monitoring tasks (jobs) and their work and completion status. Which can be combined with the previous reference to show monitoring tasks and generating report data (snapshot) for static code analysis);
an event comprising at least one of a job failure within the automated static code check or the automated static code check exceeding a predetermined runtime threshold (Para, [42], Von Trapp shows "Runtime predictor 229 may then generate a predicted runtime of the job based on a time series analysis of the runtimes of the selected data sets.. Failure predictor 231 may determine a likelihood of failure of a particular job based on a monitored runtime of the job and a time series analysis of previous executions of the job. These components and their functions will be described in greater detail below." Para. [60], Von Trapp shows 'The recorded runtimes for a particular job, in conjunction with values of features (e.g., date/time, whether completed, etc.) associated with the runtimes, may be utilized in order to predict future runtimes as well as generate failure predictions as will be described in detail below." Examiner notes the citation above shows using metadata related to the job to determine a predetermined runtime and if execution time goes above it generating a failure prediction event.);
and in response to detecting the event, automatically terminating and triggering re-execution of one or more of the plurality of jobs of the automated static code check (Para. [140], Von Trapp shows "Any suitable actions may be triggered in response to an updated failure prediction. For example, an action may be a communication of the failure prediction to an entity (e.g., customer) associated with the workflow being run (so as to allow the entity to take desired action with respect to the job without waiting for it to fail). As another example, an action may be a remedial action, such as skipping the job, stopping the job, modifying one or more parameters associated with the job, and/or restarting the job or entire workflow. In some embodiments, the action may automatically be performed by automation engine system 105 in response to the trigger.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kishore into the teachings of Huth to implement “the plurality of jobs being scheduled according to the job structure metadata such that execution of at least a first subset of the plurality of jobs is dependent on successful completion of at least a second subset of the plurality of jobs”. The modification would have been obvious as one of ordinary skill in the art would be motivated to simplify the process of scheduling jobs if tasks are dependent on each other (Kishore, Para. [7]).
Additionally, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of von Trapp into the teachings of Huth to implement “each of the plurality of snapshots indicating which of the plurality of jobs have been triggered and are still running at a respective point in time; an event comprising at least one of a job failure within the automated static code check or the automated static code check exceeding a predetermined runtime threshold; and in response to detecting the event, automatically terminating and triggering re-execution of one or more of the plurality of jobs of the automated static code check”. The modification would have been obvious as one of ordinary skill in the art would be motivated to allow users to intervene and remediate tasks being run with as little delay as possible (von Trapp, Para. [141]).
Regarding claim 2, Huth as modified teaches claim 1 as cited above, but does not disclose:
wherein automatically terminating the one or more of the plurality of jobs of the comprises terminating the automated static code check in its entirety, and triggering the re-execution of the one or more of the plurality of jobs of the automated static code check comprises triggering the re-execution of the automated static code check in its entirety
However, in the analogous art of failure prediction in workflow, von Trapp teaches:
wherein automatically terminating the one or more of the plurality of jobs of the comprises terminating the automated static code check in its entirety, and triggering the re-execution of the one or more of the plurality of jobs of the automated static code check comprises triggering the re-execution of the automated static code check in its entirety (Para. [140], von Trapp shows "Any suitable actions may be triggered in response to an updated failure prediction. For example, an action may be a communication of the failure prediction to an entity (e.g., customer) associated with the workflow being run (so as to allow the entity to take desired action with respect to the job without waiting for it to fail). As another example, an action may be a remedial action, such as skipping the job, stopping the job, modifying one or more parameters associated with the job, and/or restarting the job or entire workflow. In some embodiments, the action may automatically be performed by automation engine system 105 in response to the trigger." Examiner notes in the above citation shows stopping a job automatically or restarting the workflow in response to an event. Restarting requires termination of the processes before re-execution.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of von Trapp into the teachings of Huth as modified to implement “wherein automatically terminating the one or more of the plurality of jobs comprises terminating the automated static code check in its entirety. The modification would have been obvious as one of ordinary skill in the art would be motivated to allow users to intervene with as little delay as possible to remediate (von Trapp, Para. [141]).
Regarding, claim 7, Huth as modified in claim 1 teaches:
wherein the job failure comprises stalling of a particular job of the plurality of jobs (Para. [22], Huth shows "the errors for which the system is examined in the static and/or the dynamic analysis include at least a runtime exception, a violated assertion, an assumption of an inadmissible system state, a system termination, an erroneous memory access, an erroneous resource access or a program lock-up" Examiner notes that a program lock-up is a program stalling).
Regarding claim 8, Huth as modified teaches claim 7 as cited above, but does not disclose:
wherein the predetermined runtime threshold is an overall runtime threshold for the automated static code check, the job structure metadata defines the overall runtime threshold and an individual runtime threshold for the particular job, and the job failure is detected based on the individual runtime threshold being exceeded for the particular job.
However, in the analogous art of failure prediction in workflow, von Trapp teaches:
wherein the predetermined runtime threshold is an overall runtime threshold for the automated static code check, the job structure metadata defines the overall runtime threshold and an individual runtime threshold for the particular job, and the job failure is detected based on the individual runtime threshold being exceeded for the particular job (Para. [42], von Trapp shows "Runtime predictor 229 may utilize the output of the feature ranker 227 to select a plurality of data sets having feature values that match the feature values expected for a future execution of the job, wherein the feature values used to select the data sets are feature values of features determined by the feature ranker 227 to have predictive value for the runtime. Runtime predictor 229 may then generate a predicted runtime of the job based on a time series analysis of the runtimes of the selected data sets. Runtime predictor 229 may perform similar functions for multiple jobs of a workflow and estimate a runtime for the entire workflow based on a critical path through the workflow. Failure predictor 231 may determine a likelihood of failure of a particular job based on a monitored runtime of the job and a time series analysis of previous executions of the job. These components and their functions will be described in greater detail below." Examiner notes the above citation shows an overall runtime estimate given for a workflow (static code analysis) and jobs can be flagged or predicted for failure based on running over the predicted runtime of the individual job).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of von into the teachings of Huth as modified to implement ”wherein the predetermined runtime threshold is an overall runtime threshold for the automated static code check, the job structure metadata defines the overall runtime threshold and an individual runtime threshold for the particular job, and the job failure is detected based on the individual runtime threshold being exceeded for the particular job”. The modification would have been obvious as one of ordinary skill in the art would be motivated to allow users to intervene and perform remediate actions to ensure a timely execution of a workflow, or with as little delay as possible (von Trapp, Para. [141]).
Regarding claim 13, Huth as modified teaches claim 1 as cited above, but does not disclose:
the operations further comprising: in response to detecting the event, automatically transmitting a failure message to a user device associated with an administrator.
However, in the analogous art of failure prediction in workflow, von teaches:
further operations comprising: in response to detecting the event, automatically transmitting a failure message to a user device associated with an administrator (Para. [141], Von Trapp shows "Following notification of a possible failure, operators associated with the workflow may have the option to restart, or edit workflows or individual jobs within workflows." Examiner notes the above citation shows transmitting a possible failure message to operators (administrator)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of von Trapp into the teachings of Huth as modified to implement “the operations further comprising: in response to detecting the event, automatically transmitting a failure message to a user device associated with an administrator”. The modification would have been obvious as one of ordinary skill in the art would be motivated to allow users to intervene and perform remediate actions to ensure a timely execution of a workflow, or with as little delay as possible (von Trapp, Para. [141])
With regards to claim 15, it is a method claim having similar limitations as cited in claim 1 above. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of claim 1 above.
With regards to claim 18, it is a computer readable medium claim having similar limitations as cited in claim 1 above. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of claim 1 above.
With regards to claim 16, it is a method claim having similar limitations as cited in claim 2 above. Thus, claim 16 is also rejected under the same rationale as cited in the rejection of claim 2 above.
With regards to claim 19, it is a computer readable medium claim having similar limitations as cited in claim 2 above. Thus, claim 19 is also rejected under the same rationale as cited in the rejection of claim 2 above.
Claim(s) 3, 17, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210026760 A1 (Hereinafter referred to as Huth), US 20150160974 A1 (Hereinafter referred to as Kishore), and US 20200125448 A1 (Hereinafter referred to as von Trapp) in view of US 20250094598 A1 (Hereinafter referred to as Wang).
Regarding claim 3, Huth as modified teach claim 2 as cited above, but does not disclose:
wherein the automated static code check is performed for a batch of development artifacts, and wherein the re-execution of the automated static code check comprises: adjusting the batch of development artifacts to account for one or more updates that occurred between the commencing of the execution of the automated static code check and the detecting of the event;
However, in the analogous art of managing application code scanning processes, Wang teaches:
wherein the automated static code check is performed for a batch of development artifacts, and wherein the re-execution of the automated static code check comprises: adjusting the batch of development artifacts to account for one or more updates that occurred between the commencing of the execution of the automated static code check and the detecting of the event (Para. [37], Wang shows "the code scanners 131 include a source code quality scanner, a static code analysis tool, or a static code analyzer. The source code quality scanner analyzes the source code without executing it to identify various types of issues, including coding errors, potential vulnerabilities, coding style violations, and maintainability problems." Para. [78], Wang shows "if the artifact 342 fails to pass a scan from an updated code scanner, a user may modify the source code 315 associated with the artifact 342. The user may cause the application development platform 310 to re-compile the modified source code 315 to generate an updated software artifact 317. " Examiner notes the above citation shows an artifact failing an updated code scan, which includes a static code analyzer. After this event a user modifies and adjusts the artifact before rescanning);
and commencing the re-execution of the automated static code check for the adjusted batch of development artifacts (Para. [78], Wang shows "The code scanner management platform 320 may re-run the updated code scanner on the executable software artifact 317. Based on determining the artifact 317 passes the scan by the updated code scanner, the platform 320 stores the updated artifact 317 in the scanned artifact repository 350 as a scanned executable application artifact 342." The above shows re scanning the artifact, where the code scanner does static code analysis on the updated artifact. a Batch can be seen in that multiple artifacts are stored in the repository implying a plurality of artifacts scanned.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wang into the teachings of Huth as modified to implement ". The modification would have been obvious as one of ordinary skill in the art would be motivated to detect vulnerabilities apparent in the code and report them (Wang, Para. [29-32]).
With regards to claim 17, it is a method claim having similar limitations as cited in claim 3 above. Thus, claim 17 is also rejected under the same rationale as cited in the rejection of claim 3 above.
With regard to claim 20, it is a computer readable medium claim having similar limitations as cited in claim 3 above. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of claim 3 above.
Claim(s) 4 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210026760 A1 (Hereinafter referred to as Huth), US 20150160974 A1 (Hereinafter referred to as Kishore), and US 20200125448 A1 (Hereinafter referred to as von Trapp) in view of US 20260037409 A1 (Hereinafter referred to as Attar)
Regarding claim 4, Huth as modified teaches claim 1 as cited above, but does not disclose:
wherein the automated static code check is performed for a batch of development artifacts prior to integration of the batch of development artifacts into a production environment,
and integration of the batch of development artifacts into the production environment is disabled while the automated static code check is in progress, the operations further comprising:
detecting that the automated static code check was successfully completed and that the automated static code check did not flag any issues;
and in response to detecting that the automated static code check was successfully completed and that the automated static code check did not flag any issues, adjusting a status of the batch of development artifacts to enable the integration of the batch of development artifacts into the production environment.
However, in the analogous art of diagnosing failures in code pipeline, Attar teaches:
wherein the automated static code check is performed for a batch of development artifacts prior to integration of the batch of development artifacts into a production environment (Para. [13], Attar shows "during the code phase 120, automated tools may perform a static code analysis to verify that the code follows specific rules (e.g., that the code is written in a certain language, is well-documented, and/or is covered by tests, among other examples) that are defined to help identify potential issues in the code early in the code pipeline." Para. [28-29], Attar shows "build system may communicate with the testing system to perform automated tests to ensure that the code moving through the code pipeline satisfies applicable requirements prior to delivering or deploying new software artifacts to a production environment. The build system may store artifacts corresponding to software components that were successfully built and passed all appropriate testing in the artifact repository. For example, the artifact repository may be configured to store software artifacts for subsequent and/or repeated retrieval. In this way, the artifact repository may enable the build system and the deploy system to operate at separate times and/or on separate infrastructure, as the build system stores software artifacts in the artifact repository and the deploy system obtains the software artifacts from the artifact repository independently from the build."),
and integration of the batch of development artifacts into the production environment is disabled while the automated static code check is in progress, the operations further comprising (Para. [28], Attar shows "build system may communicate with the testing system to perform automated tests to ensure that the code moving through the code pipeline satisfies applicable requirements prior to delivering or deploying new software artifacts to a production environment." Examiner notes the above citation shows requiring all testing to be performed and satisfied to be deployed into production, this includes static code analysis):
detecting that the automated static code check was successfully completed and that the automated static code check did not flag any issues (Para. [13], Attar shows "during the code phase 120, automated tools may perform a static code analysis to verify that the code follows specific rules (e.g., that the code is written in a certain language, is well-documented, and/or is covered by tests, among other examples) that are defined to help identify potential issues in the code early in the code pipeline." Para. [29], Attar shows "the build system may store artifacts corresponding to software components that were successfully built and passed all appropriate testing in the artifact repository." Examiner notes the above citation shows storing after all appropriate testing has been passed, including static code analysis, and this implies detecting that the testing has been concluded and no issues were raised.);
and in response to detecting that the automated static code check was successfully completed and that the automated static code check did not flag any issues, adjusting a status of the batch of development artifacts to enable the integration of the batch of development artifacts into the production environment (Para. [13], Attar shows "during the code phase 120, automated tools may perform a static code analysis to verify that the code follows specific rules (e.g., that the code is written in a certain language, is well-documented, and/or is covered by tests, among other examples) that are defined to help identify potential issues in the code early in the code pipeline." Para. [28-29], Attar shows "build system may communicate with the testing system to perform automated tests to ensure that the code moving through the code pipeline satisfies applicable requirements prior to delivering or deploying new software artifacts to a production environment. The build system may store artifacts corresponding to software components that were successfully built and passed all appropriate testing in the artifact repository." Examiner notes the above citation shows storing artifacts in a repository if they have passed appropriate testing, including static code analysis, storing in the repository where only approved artifacts can go can be considered adjusting the status of the artifact for future deployment into a production environment).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Attar into the teachings of Huth as modified to implement “wherein the automated static code check is performed for a batch of development artifacts prior to integration of the batch of development artifacts into a production environment, and integration of the batch of development artifacts into the production environment is disabled while the automated static code check is in progress, the operations further comprising: detecting that the automated static code check was successfully completed and that the automated static code check did not flag any issues; and in response to detecting that the automated static code check was successfully completed and that the automated static code check did not flag any issues, adjusting a status of the batch of development artifacts to enable the integration of the batch of development artifacts into the production environment”. The modification would have been obvious as one of ordinary skill in the art would be motivated to ensure that all artifacts satisfy requirements before deployment into a production environment (Attar, Para. [28]).
Regarding claim 14, Huth as modified teaches claim 1 as cited above, but does not disclose:
wherein the automated static code check is performed for a batch of development artifacts, the batch of development artifacts comprises a plurality of development artifacts within a checking pipeline, and the operations further comprising: aggregating, based on a predetermined set of rules, the batch of development artifacts into the checking pipeline to cause the batch of development artifacts to undergo the automated static code check.
However, in the analogous art of diagnosing failures in code pipeline, Attar teaches:
wherein the automated static code check is performed for a batch of development artifacts, the batch of development artifacts comprises a plurality of development artifacts within a checking pipeline, and the operations further comprising (Para. [13-14], Attar shows "the code pipeline may include a code phase 120. In the code phase 120, software developers use software development toolkits, plug-ins installed in desktop environments, and/or other tools or utilities to aid in the software development process, enforce consistent coding styles, and avoid common security flaws and code anti-patterns. In the code phase 120, the software development team maintains source code in a centralized code repository, which is typically implemented as a version control system (e.g., GitHub, Bitbucket, GitLab, or AWS CodeCommit), which provides tools that help developers to coordinate, collaborate, and track the tasks that each team member is performing. The code phase 120 further enables collaboration between different development teams, who check source code into the code repository, perform code reviews, and/or approve the code for further processing in the code pipeline. In some cases, during the code phase 120, automated tools may perform a static code analysis to verify that the code follows specific rules (e.g., that the code is written in a certain language, is well-documented, and/or is covered by tests, among other examples) that are defined to help identify potential issues in the code early in the code pipeline. the code pipeline may include a build phase 130, which may be triggered when developers push or “commit” code to a code repository or version control system. In cases where the build fails, or any of the tests fails, the request to merge the new code or the code changes fails and the developer is notified to resolve the issue(s). In this way, continuously checking code changes into a shared code repository and running builds and tests can minimize integration issues that may arise when developers work on a shared codebase and may enable identification and resolution of bugs early in the development lifecycle. The code pipeline may include a testing phase 140 that may be triggered when a build succeeds. For example, when a build succeeds for new code or code changes that have been committed or otherwise saved to a shared code repository, the code may be automatically sent to a testing environment for more in-depth, out-of-band testing. For example, the testing environment may be an existing hosting service, or the testing environment may be a new environment provisioned as part of the deployment process (e.g., in a cloud environment) in a practice known as Infrastructure-as-Code (IaC) that is often used in a code pipeline. After the application has been deployed to the testing environment, various manual and/or automated tests may be performed. For example, manual testing may include user acceptance testing (UAT), where testers interact with the application in the same way that end users are expected to interact with the application to identify any issues or refinements that may need to be addressed before the application is deployed into a production environment. Furthermore, in some cases, automated tests may be executed to perform security scanning against the application, check for changes to an infrastructure, check for compliance with security and stability best practices, test the performance of the application, and/or run load testing, among other examples. The testing performed during the testing phase 140 may be organization-specific and/or variable depending on what is relevant to the application."):
aggregating, based on a predetermined set of rules, the batch of development artifacts into the checking pipeline to cause the batch of development artifacts to undergo the automated static code check (Para. [27-29], Attar shows "Accordingly, the build system may generally transform human-readable code into executable or deployable artifacts that can then be tested and deployed to a production environment. Furthermore, in some implementations, the build system may perform a build verification test after a build is created to verify that all modules are correctly integrated and that critical functionalities are working. the build system may communicate with the testing system to perform automated tests to ensure that the code moving through the code pipeline satisfies applicable requirements prior to delivering or deploying new software artifacts to a production environment. For example, in some implementations, the testing system may perform unit testing to validate individual components or units of code in isolation against expected behavior of the individual components or units of code. the build system may store artifacts corresponding to software components that were successfully built and passed all appropriate testing in the artifact repository. For example, the artifact repository may be configured to store software artifacts for subsequent and/or repeated retrieval." Examiner notes the above citations show a pipeline for receiving code changes and building software (creating artifacts) and requiring them to undergo and pass testing (including static code analysis) before being stored in a repository with the other deployable artifacts in a batch.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Attar into the teachings of Huth as modified to implement “wherein the automated static code check is performed for a batch of development artifacts, the batch of development artifacts comprises a plurality of development artifacts within a checking pipeline, and the operations further comprising: aggregating, based on a predetermined set of rules, the batch of development artifacts into the checking pipeline to cause the batch of development artifacts to undergo the automated static code check”. The modification would have been obvious as one of ordinary skill in the art would be motivated to ensure that all artifacts satisfy requirements before deployment into a production environment (Attar, Para. [28]).
Claim(s) 5 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210026760 A1 (Hereinafter referred to as Huth), US 20150160974 A1 (Hereinafter referred to as Kishore), and US 20200125448 A1 (Hereinafter referred to as von Trapp) in view of US 12253932 B1 (Schumacher).
Regarding claim 5, Huth as modified teaches claim 1 as cited above, but does not disclose:
wherein the job structure metadata defines the predetermined runtime threshold, and the particular snapshot indicates that the automated static code check has exceeded the predetermined runtime threshold.
However, in the analogous art of multi-stage code generation, Schumacher teaches:
wherein the job structure metadata defines the predetermined runtime threshold, and the particular snapshot indicates that the automated static code check has exceeded the predetermined runtime threshold (Col. [31] lines [4-13], Schumacher shows "Code evaluator 270 can perform static and dynamic code analysis to identify issues such as bugs, inefficiencies, and security vulnerabilities. Code evaluator 270 can use a variety of tools and techniques, including linting, code review, and automated testing, to evaluate code quality. Code evaluator 270 can integrate with the solution execution environment and code recorder to access and analyze code artifacts. Code evaluator 270 can generate reports that provide insights into code quality and suggest improvements." Col. [58] lines [17-24], Schumacher shows "In some cases, the test manager 230 can continue to serve each test stage 236 sequentially until either the client candidate runs out of allotted time for the assessment (e.g., in which case the assessment automatically completes), or the client candidate passes all stages, in which case the client can receive an additional message alerting them that they've reached the end of the problem and can submit their assessment. In some implementations, the computer code from prior stages 236 can be not editable in subsequent test stages 236." Examiner notes the above citation shows a code evaluator capable of running both static and dynamic analysis of code. Also shown are tests having an allotted time to run until the process is completed.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Schumacher into the teachings of Huth as modified to implement “wherein the job structure metadata defines the predetermined runtime threshold, and the particular snapshot indicates that the automated static code check has exceeded the predetermined runtime threshold”. The modification would have been obvious as one of ordinary skill in the art would be motivated to determine the performance of the tests run based on runtime (Schumacher, Col. [5] lines [27-33]).
Regarding claim 12, Huth as modified :
wherein the automated static code check is performed for a batch of development artifacts, the operations further comprising: detecting that the automated static code check was successfully completed; and in response to detecting that the automated static code check was successfully completed, automatically transmitting a completion message to at least one user device associated with the batch of development artifacts.
However, in the analogous art of multi-stage code generation, Schumacher teaches:
wherein the automated static code check is performed for a batch of development artifacts, the operations further comprising: detecting that the automated static code check was successfully completed; and in response to detecting that the automated static code check was successfully completed, automatically transmitting a completion message to at least one user device associated with the batch of development artifacts (Col. [31] lines [4-13], Schumacher shows "Code evaluator 270 can perform static and dynamic code analysis to identify issues such as bugs, inefficiencies, and security vulnerabilities. Code evaluator 270 can use a variety of tools and techniques, including linting, code review, and automated testing, to evaluate code quality. Code evaluator 270 can integrate with the solution execution environment and code recorder to access and analyze code artifacts. Code evaluator 270 can generate reports that provide insights into code quality and suggest improvements." Col. [58] lines [18-24], Schumacher shows "the test manager 230 can continue to serve each test stage 236 sequentially until either the client candidate runs out of allotted time for the assessment (e.g., in which case the assessment automatically completes), or the client candidate passes all stages, in which case the client can receive an additional message alerting them that they've reached the end of the problem and can submit their assessment" Examiner notes the above citation shows a code evaluator capable of analyzing both static and dynamic code artifacts and after tests are done running a completion message is sent to a user).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Schumacher into the teachings of Huth as modified to implement “wherein the automated static code check is performed for a batch of development artifacts, the operations further comprising: detecting that the automated static code check was successfully completed; and in response to detecting that the automated static code check was successfully completed, automatically transmitting a completion message to at least one user device associated with the batch of development artifacts”. The modification would have been obvious as one of ordinary skill in the art would be motivated to notify the user of the results of the static code assessment (Schumacher, Col. [58] lines [17-24]).
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210026760 A1 (Hereinafter referred to as Huth), US 20150160974 A1 (Hereinafter referred to as Kishore), and US 20200125448 A1 (Hereinafter referred to as von Trapp) in view of US 20210319108 A1 (Hereinafter referred to as Segal).
Regarding claim 6, Huth as modified teaches claim 1 as cited above, but does not disclose:
wherein the detecting of the event comprises: generating, based on the job structure metadata, an expected state of the automated static code check;
and comparing the expected state of the automated static code check with the particular snapshot.
However, in the analogous art of software package analysis, Segal teaches:
wherein the detecting of the event comprises: generating, based on the job structure metadata, an expected state of the automated static code check (Para. [12], Segal shows "A generic application into which a software package of interest has been included is analyzed, where the analysis of the generic software application includes a static analysis and/or a dynamic analysis performed based on executing the generic application in a controlled environment (e.g., a sandbox). Analysis results which are attributable to the software package can be recognized because functionality of the generic application and therefore the expected analysis results are known prior to integration of the software package." Examiner notes the above citation shows the expected outcomes from running a static code analysis);
In addition, in the analogous art of failure prediction in workflow, von Trapp teaches:
and comparing the expected state of the automated static code check with the particular snapshot (Para. [42], von Trapp shows "Feature ranker 227 may execute a feature weighting analysis utilizing runtime data sets 242 associated with a particular job to rank features with respect to their predictive value on the runtime of that job. Runtime predictor 229 may utilize the output of the feature ranker 227 to select a plurality of data sets having feature values that match the feature values expected for a future execution of the job, wherein the feature values used to select the data sets are feature values of features determined by the feature ranker 227 to have predictive value for the runtime. Runtime predictor 229 may then generate a predicted runtime of the job based on a time series analysis of the runtimes of the selected data sets. Runtime predictor 229 may perform similar functions for multiple jobs of a workflow and estimate a runtime for the entire workflow based on a critical path through the workflow. Failure predictor 231 may determine a likelihood of failure of a particular job based on a monitored runtime of the job and a time series analysis of previous executions of the job. These components and their functions will be described in greater detail below." Examiner notes the above citation shows comparing predicted values with the actual outcome results of job performance (snapshot)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Segal into the teachings of Huth as modified to implement “wherein the detecting of the event comprises: generating, based on the job structure metadata, an expected state of the automated static code check;”. The modification would have been obvious as one of ordinary skill in the art would be motivated to identify potentially malicious properties (Segal, Para. [12]).
Additionally, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of von Trapp into the teachings of Huth as modified to implement “comparing the expected state of the automated static code check with the particular snapshot”. The modification would have been obvious as one of ordinary skill in the art would be motivated to allow users to intervene and perform remediate actions to ensure a timely execution of a workflow, or with as little delay as possible (von Trapp, Para. [141]).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210026760 A1 (Hereinafter referred to as Huth), US 20150160974 A1 (Hereinafter referred to as Kishore), and US 20200125448 A1 (Hereinafter referred to as von Trapp) in view of US 20240036969 A1 (Hereinafter referred to as Feng).
Regarding claim 9, Huth as modified teaches claim 1 as cited above, but does not disclose:
the operations further comprising performing, by a watchdog process and for each of the plurality of snapshots, an automated assessment according to a predetermined order comprising: a first assessment by the watchdog process to check for any job failures within the automated static code check;
and a second assessment by the watchdog process to check for exceeding of the predetermined runtime threshold, the second assessment being performed only in response to a detection, by the watchdog process, that no job failures were identified in the first assessment.
However, in the analogous art of detecting application freezing, Feng teaches:
the operations further comprising performing, by a watchdog process and for each of the plurality of snapshots, an automated assessment according to a predetermined order comprising: a first assessment by the watchdog process to check for any job failures within the automated static code check (Para .[51], Feng shows "When it is monitored that the time consumption for executing the task by the Runloop exceeds a preset threshold, the execution state of the Runloop after the task time consumption reaches the preset threshold is monitored. When the application is closed, if the execution state of the Runloop remains the first execution state when the task time consumption reaches the preset threshold and does not enter a second execution state, it is determined that the application occurs the freezing problem, thereby realizing the identification and monitoring of the application freezing problem. Only when the application is closed and Runloop still fails to enter the second execution state after the first execution state, it is determined that the application has a freezing problem, which can prevent the application from mistaking the lagging problem as the freezing problem, thereby improving the accuracy of monitoring the freezing problem. In addition, in the process from the application startup to shutdown, the freezing problem can only occur once, but the lagging problem can occur multiple times. If the execution state of the Runloop after the task time consumption reaches the preset threshold is not monitored, it would easily mistake the lagging problem as the freezing problem, and thus too many problems may be reported to the remote server. As a result, the remote server could not focus on the freezing problem that has a greater impact on the user experience." Examiner notes the above citation shows performing monitoring on an application where the application can freeze detecting a job failure causing the application to freeze);
and a second assessment by the watchdog process to check for exceeding of the predetermined runtime threshold, the second assessment being performed only in response to a detection, by the watchdog process, that no job failures were identified in the first assessment (Para. [51], Feng shows " In the embodiments of the present disclosure, when it is monitored that the time consumption for executing the task by the Runloop exceeds the preset threshold, the call stack of the first thread is written into the preset file, and the preset file is sent to the remote server only when the freezing application is monitored. In this way, it can reduce the number of reported problems, so that the remote server can focus on the analysis and processing of the application freezing problem and improve the efficiency of analyzing and solving the freezing problem." Examiner notes that freezing of the application indicating job failure is detected first and reported then lagging and runtime threshold issues are flagged).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Feng into the teachings of Huth as modified to implement “the operations further comprising performing, by a watchdog process and for each of the plurality of snapshots, an automated assessment according to a predetermined order comprising: a first assessment by the watchdog process to check for any job failures within the automated static code check; and a second assessment by the watchdog process to check for exceeding of the predetermined runtime threshold, the second assessment being performed only in response to a detection, by the watchdog process, that no job failures were identified in the first assessment.”. The modification would have been obvious as one of ordinary skill in the art would be motivated to reduce the number of reported problems (Feng, Para. [51]).
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210026760 A1 (Hereinafter referred to as Huth), US 20150160974 A1 (Hereinafter referred to as Kishore), and US 20200125448 A1 (Hereinafter referred to as von Trapp) in view of US 20240193056 A1 (Hereinafter referred to as Melton).
Regarding claim 10, Huth as modified teaches claim 1 as cited above, :
wherein a watchdog process is periodically executed to generate the plurality of snapshots while the automated static code check is in progress (Para. [33], Huth shows ' in a computer-implemented static analysis an examination is carried out for the identified or selected sub-tree to see if an error can occur in the execution of a computer program execution path which is contained or represented in said sub-tree." Para. [46], Huth shows "information about sub-trees which have already been analyzed is stored and taken into account for the further analysis in order to avoid repeatedly analyzing the same sub-trees" Examiner notes the above citation shows recording information from analyzed sub trees can be considered generating a snapshot of the static code analysis on that execution path for that job and that the job was completed.),
Huth as modified does not disclose:
the watchdog process being executed according to a predetermined interval of between one minute and twenty minutes.
However, in the analogous art of end of interval rollover with fault tolerance, Melton teaches:
the watchdog process being executed according to a predetermined interval of between one minute and twenty minutes (Para. [49], Melton shows "the interval for which each snapshot is created, may be daily or other interval, such as every five minutes, every hour, every week, and so forth." Examiner notes the above citation shows taking a snapshot within 5-minute intervals).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Melton into the teachings of Huth as modified to implement “the watchdog process being executed according to a predetermined interval of between one minute and twenty minutes.”. The modification would have been obvious as one of ordinary skill in the art would be motivated to use snapshots for reporting and recovery purposes (Melton, Para. [21]).
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20210026760 A1 (Hereinafter referred to as Huth), US 20150160974 A1 (Hereinafter referred to as Kishore), and US 20200125448 A1 (Hereinafter referred to as von Trapp) in view of US 20170351599 A1 (Hereinafter referred to as Elimeleh).
Regarding claim 11, Huth as modified teaches claim 1 as cited above, but does not disclose:
the operations further comprising: detecting that the automated static code check has been re-executed a predetermined number of times without successful completion;
and in response to detecting that the automated static code check has been re-executed the predetermined number of times without successful completion,
automatically performing at least one of: pausing further execution of the automated static code check; or transmitting a failure message to a user device associated with an administrator.
However, in the analogous art of automatic rerunning of test execution, Elimeleh teaches:
the operations further comprising: detecting that the automated static code check has been re-executed a predetermined number of times without successful completion (Para. [22], Elimeleh shows "rerun execution instructions 246 may cause processor 220 to transmit instructions to client device 120 to execute the automatic rerun executions of the failed test up to the number of times and/or until a rerun execution passes");
and in response to detecting that the automated static code check has been re-executed the predetermined number of times without successful completion (Para. [21-23], Elimeleh shows " Rerun number determination instructions 244 may function to dynamically determine, for a failed execution of a test, a number of reruns to execute based on the captured data. For example, when rerun number determination instructions 244 are executed by processor 220, rerun number determination instructions 244 may cause processor 220 to dynamically determine the number of reruns by analyzing the captured data to determine whether the execution of the test failed due to a real application failure (e.g., the test is executed multiple times with the same failing result and thus the failure is likely due to an issue with the application code). Rerun execution instructions 246 may cause processor 220 to transmit instructions to client device 120 to execute the automatic rerun executions of the failed test up to the number of times and/or until a rerun execution passes. Rerun execution instructions 246 may also function to cause the generation of an alert"),
In addition, in the analogous art of failure prediction in workflow, von Trapp teaches:
automatically performing at least one of: pausing further execution of the automated static code check; or transmitting a failure message to a user device associated with an administrator.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Elimeleh into the teachings of Huth as modified to implement “detecting that the automated static code check has been re-executed a predetermined number of times without successful completion”. The modification would have been obvious as one of ordinary skill in the art would be motivated to prevent waste of computing resources (Elimeleh, Para. [21-23]).
Additionally, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of von Trapp into the teachings of Huth as modified to implement “automatically performing at least one of: pausing further execution of the automated static code check; or transmitting a failure message to a user device associated with an administrator.”. The modification would have been obvious as one of ordinary skill in the art would be motivated to allow users to intervene and perform remediate actions to ensure a timely execution of a workflow, or with as little delay as possible (von Trapp, Para. [141]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20230032686 A1 – this prior art teaches monitoring static code analysis
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZEERICK A MALIK whose telephone number is (571)272-8110. The examiner can normally be reached Mon-Thurs, 7-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do can be reached at (571) 272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Z.A.M./Examiner, Art Unit 2193 /Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights