CTNF 18/677,999 CTNF 86397 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claims 1-20 are pending and examined in this office action. Claim 9 recites the term “ the CIT pipeline ”. It should be “ the duplicate CIT pipeline ”. Correction is requested. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-20 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, mathematical relationship or an abstract idea ) without significantly more. Statutory Category: Claim 1 recites a data processing system comprising: a processor; and a memory in communication with the processor, the memory comprising executable instructions that, when executed by the processor alone or in combination with other processors, cause the data processing system to perform functions of: detecting failure of a main Continuous Integration Testing (CIT) pipeline that is testing artifacts of a build pipeline; determining a known-good artifact tested by the main CIT pipeline previously; retesting the known-good artifact with a duplicate CIT pipeline; and in response to failure of the duplicate CIT pipeline, enhancing an incident ticket with notice that the failure of the main CIT pipeline is due to an external dependency failure. Step 2A – Prong 1: Claim 1 recites: detecting failure of a main Continuous Integration Testing (CIT) pipeline that is testing artifacts of a build pipeline (a user can see, thus detect an error in pipeline execution); determining a known-good artifact tested by the main CIT pipeline previously (a mental step of determining); in response to failure of the duplicate CIT pipeline, enhancing an incident ticket with notice that the failure of the main CIT pipeline is due to an external dependency failure (a user can manually create and modify a ticket). That is, nothing in the claim elements precludes the steps from practically being performed mentally or using pen and paper . If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the mental process grouping of abstract idea. Accordingly, the claim recites an abstract idea under step 2A prong 1. This judicial exception is not integrated into a practical application. In particular, the claim 1 recites additional elements such as retesting the known-good artifact with a duplicate CIT pipeline , which is an extra solution activity of re-executing a pipeline, that is a Well-Understood, Routine, Conventional (WURC) Activity, as evidenced in Vergara ( Fig. 9; column 21, line 55-67; running pipeline includes instructions for running tests for testing the deployed software artifact, evaluate the test result, if the test result is below a threshold (i.e. a failure); executing a retry strategy, which includes re-execute the pipeline with a revised software artifact (a known-good artifact), the revised software artifact includes fixes to the defects ). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Prong II step 2B. This judicial exception is not integrated into a practical application. In particular, the claim 1 recites additional elements such as a processor; and a memory in communication with the processor, the memory comprising executable instructions . The additional elements in the claim amounts to no more than generic hardware component with instructions to apply the exception, which cannot integrate a judicial exception into a practical application or provide an inventive concept. Thus, the claim is directed to an abstract idea under Prong II step 2A and 2B. Dependent claims 2-11 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the dependent claims 2-11 recite more steps of a mental process (such as detecting, determining ) which can be performed mentally or using pen and paper. The additional element of dependent claims 2-11 recite more extra-solution activities ( receiving user input, preventing code into a repository, querying logs ), which do not impose any meaningful limits on practicing the mental process (insignificant additional element) . Therefore, these claims are not patent eligible. Statutory Category: Claim 12 recites a diagnostic tool for a Continuous Integration/Continuous Deployment (CI/CD) system having a codebase repository and build and release pipelines, the diagnostic tool to identify failure in an external dependency as a cause of a failure in Continuous Integration Testing (CIT), the diagnostic tool comprising a processor; and a memory in communication with the processor, the memory comprising executable instructions that, when executed by the processor alone or in combination with other processors, cause the processor to implement an agentless task to perform functions of: detecting and responding to a testing failure of a main Continuous Integration Testing (CIT) pipeline that is testing artifacts of the build pipeline; determining a known-good artifact tested by the main CIT pipeline previous to the failure; instantiating a duplicate CIT pipeline; rerunning CIT based on the known-good artifact with the duplicate CIT pipeline; determining a testing failure of the duplicate CIT pipeline; and enhancing an incident ticket for the testing failure in the main CIT pipeline with notice that the testing failure of the main CIT pipeline is due to an external dependency outage.. Step 2A – Prong 1: Claim 12 recites: to identify failure in an external dependency as a cause of a failure in Continuous Integration Testing (CIT) (a mental step of identifying); detecting and responding to a testing failure of a main Continuous Integration Testing (CIT) pipeline that is testing artifacts of the build pipeline; (a user can see, thus detect an error in pipeline execution and then respond); determining a known-good artifact tested by the main CIT pipeline previous to the failure (a mental step of determining); determining a testing failure of the duplicate CIT pipeline (a mental step of determining); enhancing an incident ticket for the testing failure in the main CIT pipeline with notice that the testing failure of the main CIT pipeline is due to an external dependency outage (a user can manually create and modify a ticket). That is, nothing in the claim elements precludes the steps from practically being performed mentally or using pen and paper . If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the mental process grouping of abstract idea. Accordingly, the claim recites an abstract idea under step 2A prong 1. This judicial exception is not integrated into a practical application. In particular, the claim 12 recites additional elements such as instantiating a duplicate CIT pipeline; rerunning CIT based on the known-good artifact with the duplicate CIT pipeline; , which is an extra solution activity of re-executing a pipeline, that is a Well-Understood, Routine, Conventional (WURC) Activity, as evidenced in Vergara ( Fig. 9; column 21, line 55-67; running pipeline includes instructions for running tests for testing the deployed software artifact, evaluate the test result, if the test result is below a threshold (i.e. a failure); executing a retry strategy, which includes re-execute the pipeline with a revised software artifact (a known-good artifact), the revised software artifact includes fixes to the defects ). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Prong II step 2B. This judicial exception is not integrated into a practical application. In particular, the claim 12 recites additional elements such as a codebase repository and build and release pipelines , a processor; and a memory in communication with the processor, the memory comprising executable instructions . The additional elements in the claim amounts to no more than generic hardware component with instructions to apply the exception, which cannot integrate a judicial exception into a practical application or provide an inventive concept. Thus, the claim is directed to an abstract idea under Prong II step 2A and 2B. Dependent claims 13-17 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the dependent claims 13-17 recite more steps of a mental process (such as determining ) which can be performed mentally or using pen and paper. The additional element of dependent claims 13-17 recite more extra-solution activities ( rerunning a test, preventing code into a repository, retesting ), which do not impose any meaningful limits on practicing the mental process (insignificant additional element) . Therefore, these claims are not patent eligible. Independent claim 18 (a method claim that recites similar limitations as claim 12) with dependent claims 19-20 are rejected under the similar rationales as claims 12-13 and 16. Claim Rejections - 35 USC § 103 07-20-aia AIA The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1-6, 8-9, 12-15, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable Vergara et al. (US patent 11356508) hereinafter Vergara, in view of Bregman et al. (US PGPUB 2023/0409305) hereinafter Bregman. Per claim 1, Vergara discloses a data processing system comprising: a processor; and a memory in communication with the processor, the memory comprising executable instructions that, when executed by the processor alone or in combination with other processors, cause the data processing system to perform functions of: (Fig. 20; a computer system); detecting failure of a main Continuous Integration Testing (CIT) pipeline that is testing artifacts of a build pipeline (Fig. 18A; column 31, line 25-40; column 3, line 40-50; executing a pipeline of many stages, encountering a failure, then execute a retry strategy; the pipeline comprises a sequence of stages for deployment of a software artifact, including a test stage); determining a known-good artifact tested by the main CIT pipeline previously; retesting the known-good artifact with a duplicate CIT pipeline (Fig. 9; column 21, line 55-67; running pipeline includes instructions for running tests for testing the deployed software artifact, evaluate the test result, if the test result is below a threshold (i.e. a failure); executing a retry strategy, which includes re-execute the pipeline (a duplicate pipeline) with a revised software artifact (a known-good artifact), the revised software artifact includes fixes to the defects; column 9, line 24-30; the software release management module may also perform a rollback to a previous version if an issue is encountered in a current version of software (i.e. rollback to a known good version)). Vergara does not explicitly teach in response to failure of the duplicate CIT pipeline, enhancing an incident ticket with notice that the failure of the main CIT pipeline is due to an external dependency failure . However, Vergara suggests (column 21, line 55-67; column 33, line 45-55; executing a retry strategy, which includes re-execute the pipeline (a duplicate pipeline) with a revised software artifact (a known-good artifact); if an execution of a pipeline encounters an error, executing a retry strategy, which includes sending an alert to users, and a system administrator to take actions to diagnose and fix errors (i.e. sending an alert ticket describing the failure)). Bregman further suggests (paragraph [0028]; issuing a report ( an incident ticket ) describing a pipeline error; paragraph [0012]; execution of a build pipeline may fail because an external dependency is unavailable ). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Vergara and Bregman to issue an incident ticket describing cause of the build pipeline failure is due to an external dependency (when the build pipeline is executed with a known good artifact); this information would help a developer to diagnose and fix the execution error. Per claim 2, Bregman further suggests wherein determining a known-good artifact tested by the main CIT pipeline previously and retesting the known-good artifact with a duplicate CIT pipeline are conducted regularly during operation of the build pipeline in anticipation of detecting a failure of the main CIT pipeline (paragraphs [0010][0033]; Continuous integration (CI) generally refers to an automation process for user groups, successful CI means new code changes can be regularly built, tested, and merged to a shared repository; action commands may include a re-execute command (e.g., to re-execute components identified as pipelines), a revert command (e.g., to revert updates to components)). Per claim 3, Vergara further suggests wherein determining a known-good artifact tested by the main CIT pipeline previously and retesting the known-good artifact with a duplicate CIT pipeline are triggered by detecting the failure of the main CIT pipeline ( Fig. 9; column 21, line 55-67; running pipeline includes instructions for running tests for testing the deployed software artifact, evaluate the test result, if the test result is below a threshold (i.e. a failure); executing a retry strategy, which includes re-execute the pipeline (a duplicate pipeline) with a revised software artifact (a known-good artifact), the revised software artifact includes fixes to the defects; column 9, line 24-30; the software release management module may also perform a rollback to a previous version if an issue is encountered in a current version of software (i.e. rollback to a known good version) ). Per claim 4, Vergara in view of Bregman further suggests comprising receiving user input to invoke determining a known-good artifact tested by the main CIT pipeline previously and retesting the known-good artifact with a duplicate CIT pipeline ( Vergara; Fig. 9; column 21, line 55-67; running pipeline includes instructions for running tests for testing the deployed software artifact; if evaluate the test result, if the test result is below a threshold (i.e. a failure); executing a retry strategy, which includes re-execute the pipeline (a duplicate pipeline) with a revised software artifact (a known-good artifact), the revised software artifact includes fixes to the defects; column 9, line 24-30; the software release management module may also perform a rollback to a previous version if an issue is encountered in a current version of software (i.e. rollback to a known good version); Bregman, paragraphs [0010][0033]; user action commands may include a re-execute command (e.g., to re-execute components identified as pipelines), a revert command (e.g., to revert updates to components); i.e. receiving user input). Per claim 5, Vergara further suggests wherein the known-good artifact retested with the duplicate CIT pipeline is a release artifact from a release pipeline in a Continuous Integration/Continuous Deployment (CI/CD) system with the build pipeline ( Fig. 9; column 21, line 55-67; running pipeline includes instructions for running tests for testing the deployed software artifact; evaluate the test result, if the test result is below a threshold (i.e. a failure); executing a retry strategy, which includes re-execute the pipeline (a duplicate pipeline) with a revised software artifact (a known-good artifact), the revised software artifact includes fixes to the defects; column 9, line 24-30; the software release management module may also perform a rollback to a previous version if an issue is encountered in a current version of software (i.e. rollback to a known good version, a previously released version) ). Per claim 6, Vergara further suggests wherein the duplicate CIT pipeline contains only a subset of stages contained in the main CIT pipeline ( column 9, line 45-60; the retry module implements idempotency in execution of the pipeline such that if a pipeline is executed a subsequent time after a previous failure, the stages that previously executed successfully are skipped and only the stages that did not complete execution successfully in the previous runs are executed in a subsequent run). Per claim 8, Vergara further suggests retesting the known-good artifact with the duplicate CIT pipeline multiple times to allow a transient issue in an external dependency to resolve before determining failure of the duplicate CIT pipeline and issuing the incident ticket ( column 4, line 11-22; the system allows a failed stage to be retried multiple times based on a retry strategy; column 33, line 45-55; if an execution of a pipeline encounters an error, the execution of the pipeline is paused for a specified amount of delay, the system may optionally send an alert to one or more users, the execution of the pipeline is paused to allow a remedial action to be performed). Per claim 9, Vergara further suggests determining that a number of same releases stages are failing in the main and duplicate CIT pipeline before determining failure of the CIT pipeline and enhancing the incident ticket ( column 4, line 32-49; if the system determines that the status of the stage for the context indicates a successful execution of the stage, the system skips execution of the stage for the subsequent pipeline execution. If the system determines that the status of the stage for the context fails to indicate a successful execution of the stage, the system marks the stage as a candidate stage for subsequent pipeline execution. The system executes the stage if the stage is selected as a candidate stage for the subsequent execution). Per claim 12, Vergara discloses a diagnostic tool for a Continuous Integration/Continuous Deployment (CI/CD) system having a codebase repository and build and release pipelines, the diagnostic tool to identify failure as a cause of a failure in Continuous Integration Testing (CIT) (column 22, line 38-47; a master pipeline may be driven by pull requests that occur a version control system for software receives a request for considering changes committed to an external repository for inclusion in a project's main repository . Accordingly, the master pipeline is automatically triggered when a pull request is received and deploys a software artifact based on the latest software version for which the pull request is received. The master pipeline performs continuous delivery of software artifacts based on pull requests; column 33, line 45-54; the system may optionally send an alert to one or more users to allow users to take actions to diagnose and fix errors); the diagnostic tool comprising a processor; and a memory in communication with the processor, the memory comprising executable instructions that, when executed by the processor alone or in combination with other processors, cause the processor to implement an agentless task to perform functions: (Fig. 20; a computer system); detecting and responding to a testing failure of a main Continuous Integration Testing (CIT) pipeline that is testing artifacts of the build pipeline (Fig. 18A; column 31, line 25-40; column 3, line 40-50; executing a pipeline of many stages, encountering a failure, then execute a retry strategy; the pipeline comprises a sequence of stages for deployment of a software artifact, including a test stage); determining a known-good artifact tested by the main CIT pipeline previous to the failure; instantiating a duplicate CIT pipeline; rerunning CIT based on the known-good artifact with the duplicate CIT pipeline; (Fig. 9; column 21, line 55-67; running pipeline includes instructions for running tests for testing the deployed software artifact; evaluate the test result, if the test result is below a threshold (i.e. a failure); executing a retry strategy, which includes re-execute the pipeline (instantiating a duplicate pipeline) with a revised software artifact (a known-good artifact), the revised software artifact includes fixes to the defects; column 9, line 24-30; the software release management module may also perform a rollback to a previous version if an issue is encountered in a current version of software (i.e. rollback to a known good version)). Vergara does not explicitly teach determining a testing failure of the duplicate CIT pipeline; and enhancing an incident ticket for the testing failure in the main CIT pipeline with notice that the testing failure of the main CIT pipeline is due to an external dependency outage . However, Vergara suggests (column 21, line 55-67; column 33, line 45-55; executing a retry strategy, which includes re-execute the pipeline (a duplicate pipeline) with a revised software artifact (a known-good artifact) multiple times; if an execution of a pipeline encounters an error, executing a retry strategy, which includes sending an alert to users, and a system administrator to take actions to diagnose and fix errors (i.e. sending an alert ticket describing the failure)). Bregman further suggests (paragraph [0028]; issuing a report ( an incident ticket ) describing a pipeline error; paragraph [0012]; execution of a build pipeline may fail because an external dependency is unavailable ). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Vergara and Bregman to issue an incident ticket describing cause of the build pipeline failure is due to an external dependency (when the build pipeline is executed with a known good artifact); this information would help a developer to diagnose and fix the execution error. Claims 13, 15 and 17 are rejected under similar rationales as claims 2, 6 and 8. Per claim 14, Vergara further suggests wherein operation of the duplicate CIT pipeline is in cadence with operation of the main CIT pipeline ( column 9, line 45-60; the retry module implements idempotency in execution of the pipeline such that if a pipeline is executed a subsequent time after a previous failure, the stages that previously executed successfully are skipped and only the stages that did not complete execution successfully in the previous runs are executed in a subsequent run; i.e. the re-execution of the pipeline includes stages correspond to the stages that have not been successful in the first execution). Claim 18 is rejected under similar rationales as claim 12. Claim 19 is rejected under similar rationales as claim 2. Claims 7, 16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable Vergara, in view of Bregman, in view of Bregman et al. (US PGPUB 2023/0168996) hereinafter Bregman1. Per claim 7, Vergara does not explicitly teach wherein the duplicate CIT pipelines contains only stages that, if unsuccessful, prevent additional code from being checked in to a codebase repository . However, Bregman1 suggests the above (paragraphs [0009][0010]; executing a CI/CD pipeline which includes a testing stage; testing of the job containing changes to the repository , a pull request containing the changes made to the repository is submitted, the pull request refers to a request to notify that changes will be made to a repository, upon approval of the pull request, the changes made to the repository are merged; i.e. only after passing a test, the codes can be approved for merger into the codebase repository, codes that failed the test is not approved). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Vergara, Bregman and Bregman1 to prevent additional code from being checked into a codebase repository when the build pipeline encounters failure in execution, it would enhance the quality of software code stored in the repository. Claims 16 and 20 are rejected under similar rationales as claim 7. Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable Vergara, in view of Bregman, in view of Wang (US PGPUB 2023/0129123). Per claim 10, Vergara does not explicitly teach if the incident ticket remains active, on a regular basis querying logs of the duplicate CIT pipeline for failures and updating the incident ticket accordingly . However, Wang suggests (paragraphs [0036][0037][0055][0056]; during an on-line session when investigating and resolving an active trouble ticket, log files are continuously queried and analyzed; and the on-line session may be monitored and documented by session event generator for generating session events which can be linked or otherwise associated with a specific trouble ticket; the session event aggregation steps described below may be performed during the trouble ticket resolution process periodically , or at any other time desired by the IT vendor towards developing a trouble ticket modelling system). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Vergara, Bregman and Wang to continuously query logs when investigating and resolving an active trouble ticket, and to update the trouble ticket based on the queried logs; as the queried logs may provide important information to developers to resolve the failure linked to the trouble ticket. Per claim 11, Wang further suggests wherein the regular basis is hourly ( paragraphs [0036][0037][0055][0056]; during an on-line session when investigating and resolving an active trouble ticket, log files are continuously queried and analyzed; the session event aggregation steps described below may be performed during the trouble ticket resolution process periodically , or at any other time desired by the IT vendor towards developing a trouble ticket modelling system; hourly is a common used period ). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANG PAN whose telephone number is (571)270-7667. The examiner can normally be reached 9 AM to 5 PM. 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. /HANG PAN/Primary Examiner, Art Unit 2193 Application/Control Number: 18/677,999 Page 2 Art Unit: 2193 Application/Control Number: 18/677,999 Page 3 Art Unit: 2193 Application/Control Number: 18/677,999 Page 4 Art Unit: 2193 Application/Control Number: 18/677,999 Page 5 Art Unit: 2193 Application/Control Number: 18/677,999 Page 6 Art Unit: 2193 Application/Control Number: 18/677,999 Page 7 Art Unit: 2193 Application/Control Number: 18/677,999 Page 8 Art Unit: 2193 Application/Control Number: 18/677,999 Page 9 Art Unit: 2193 Application/Control Number: 18/677,999 Page 10 Art Unit: 2193 Application/Control Number: 18/677,999 Page 11 Art Unit: 2193 Application/Control Number: 18/677,999 Page 12 Art Unit: 2193 Application/Control Number: 18/677,999 Page 13 Art Unit: 2193 Application/Control Number: 18/677,999 Page 14 Art Unit: 2193 Application/Control Number: 18/677,999 Page 15 Art Unit: 2193
Prosecution Insights