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 .
Claims 1-20 are presented for examination.
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.
Claim 1-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding Claims 1, 2, 8, 9, 15 and 16, Claims 1, 8 and 15 each recite “store a resulting state produced by each execution of the CI/CD pipeline” and thereafter recite “based on the stored resulting state.” Because a separate resulting state is stored for each of the multiple executions of the pipeline, the singular recitation “the stored resulting state” lacks sufficient antecedent basis and it is unclear which one of the plurality of stored resulting states is being referenced. Claims 2, 9 and 16 recite “store the resulting state” and are indefinite for the same reason. Suggested corrective amendment: amend to recite “store a respective resulting state produced by each execution of the CI/CD pipeline” and “based on the stored respective resulting states.”
Regarding Claim 15, Claim 15 recites “program code that is executable by a processing device for causing a processing device to.” The second recitation of “a processing device” is indefinite because it is unclear whether it refers to the same processing device previously recited or to an additional, different processing device. Suggested corrective amendment: amend the second occurrence to recite “the processing device.”
Regarding Claims 3 and 10, Claims 3 and 10 recite “the metadata for the particular task indicates an intervention requirement for the test failure.” Parent claims 2 and 9 recite only “metadata indicating a status of each task of the plurality of tasks,” and do not recite metadata that is specific to the particular task. The recitation “the metadata for the particular task” therefore lacks sufficient antecedent basis. Suggested corrective amendment: amend claims 2 and 9 to recite “storing, for each task of the plurality of tasks, respective metadata indicating a status of the task,” and amend claims 3 and 10 to recite “the respective metadata for the particular task.”
Claims 2-7, 9-14 and 16-20 are also rejected under 35 U.S.C. 112(b) as being indefinite for failing to cure the deficiencies of their independent claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 2, 4, 5, 7, 8, 9, 11, 12, 14, 15, 16, 17, 18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eizenman (US 2019/0171550 A1) in view of Sanders (US 2023/0153233 A1).
Regarding Claim 1, Eizenman (US 2019/0171550 A1) teaches
A system comprising: a processing device; and a non-transitory memory device comprising instructions that are executable by the processing device for causing the processing device to:
execute a continuous integration and continuous deployment (CI/CD) pipeline comprising a plurality of tasks applied to a software project; (Eizenman, Para.[0060]: “for each build, optionally and preferably the following process is performed: analyze build, build quality analytics, select tests, run them, analyze results, determine build quality according to rules, and decide if the build can go to production”; Para.[0002]: “Termed “CI/CD” for “continuous integration and continuous delivery”, these systems enable new features to be rolled out rapidly for consumption by users”) Examiner Comments: Eizenman expressly identifies its environment as a CI/CD system, and the ordered sequence of operations that Eizenman performs for each build, namely analyzing the build, selecting tests, running the tests, analyzing the results and deciding whether the build can be promoted, is the claimed CI/CD pipeline comprising a plurality of tasks, and the build of the software application to which those operations are applied is the claimed software project.;
store a resulting state produced by each execution of the CI/CD pipeline; (Eizenman, Para.[0101]: “In Stage (10), the footprint listener collects test run time data. In Stage (11), the test run time data is reported and stored in the cloud application”; Para.[0122]: “These queues receive information about tests that have been performed and changes to code as well as footprints of the tests on the applications under test, and in turn preferably connect to a core calculations service 1010. Core calculations service 1010 receives build changes (methods/branches and lines added/modifies/deleted), the results and identity of tests, and also the footprints”) Examiner Comments: Eizenman persists, for every run of the pipeline, the run time data, the results and identity of the tests and the associated footprints, which is the claimed resulting state produced by each execution of the pipeline, because that stored record is precisely the outcome that each pipeline run produced and it is retained so that later runs can be evaluated against it.;
modify a subsequent execution of the CI/CD pipeline based on the repeated status of the particular task. (Eizenman, Para.[0059]: “Next, test selection is performed in step 2, optionally including test coverage calculation. Such a selection is preferably performed according to the build content, including any differences from previous builds, and also according to tests that have been previously run and optionally also those that are scheduled to run”) Examiner Comments: Eizenman changes what the next run of the pipeline will do by selecting which tests that run will execute on the basis of the stored record of tests that have previously been run and the differences from previous builds, which is the claimed modification of a subsequent execution of the pipeline on the basis of the stored outcome of the earlier executions.
Eizenman did not specifically teach
determine, for a particular task of the plurality of tasks and based on the stored resulting state, a repeated status over a plurality of prior executions of the CI/CD pipeline.
However, Sanders (US 2023/0153233 A1) teaches
determine, for a particular task of the plurality of tasks and based on the stored resulting state, a repeated status over a plurality of prior executions of the CI/CD pipeline; (Sanders, Para.[0031]: “if the EOT file set 112 contains the three most recent EOT files, and the three EOT files each indicate that four particular tests 104 failed, the failed test detector 110 can determine that those four particular tests 104 consistently failed the last three times the tests 104 were executed against versions of the software application 106”) and (Sanders, Para.[0027]: “The EOT repository 122 can accordingly store the EOT file 120 generated by the test system 108 based on tests 104 executed against a current or recent version of the software application 106, as well as other EOT files previously generated by the test system 108 when the tests 104 were executed against previous versions of the software application 106”) Examiner Comments: Sanders inspects the stored per run result files for several earlier runs and concludes that an individual test carried the identical failing outcome across all of those earlier runs, which is the claimed determination, for a particular task and based on the stored resulting state, of a repeated status over a plurality of prior executions..
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sanders’ teaching of determining that a particular test carried a repeated status across a plurality of prior stored execution records into Eizenman’s CI/CD pipeline in order to relieve development teams of the time-intensive and laborious burden of manually evaluating each new set of test results to determine if or when individual tests have begun failing consistently, as Sanders expressly identifies at Para.[0004], and thereby to direct pipeline resources and developer attention only where they are actually needed.
Regarding Claim 2, Eizenman and Sanders teach
The system of Claim 1.
Eizenman did not teach
store the resulting state by, for each execution of the CI/CD pipeline, storing metadata indicating a status of each task of the plurality of tasks applied to the software project
and determine the repeated status over the plurality of prior executions of the CI/CD pipeline by determining that the status of the particular task has remained unchanged for more than a threshold number of executions.
Sanders further teaches
store the resulting state by, for each execution of the CI/CD pipeline, storing metadata indicating a status of each task of the plurality of tasks applied to the software project; (Sanders, Para.[0026]: “The EOT file 120 can include data about each of the tests 104 that were executed against the version of the software application 106. For example, for a particular test, the EOT file 120 can identify a title of the test, a source code file associated with the test, an indication of whether the test passed or failed, an execution time of the test, and/or other information about the test and/or execution of the test”) Examiner Comments: Sanders writes, for every run, a descriptive record that names each test and records whether that test passed or failed, which is the claimed metadata indicating a status of each task of the plurality of tasks applied to the software project.;
and determine the repeated status over the plurality of prior executions of the CI/CD pipeline by determining that the status of the particular task has remained unchanged for more than a threshold number of executions. (Sanders, Para.[0028]: “The EOT file set 112 can include two EOT files, three EOT files, four EOT files, or any other number of EOT files. As a non-limiting example, the EOT file set 112 can include the three most recent EOT files that correspond to the same set of tests 104 executed against versions of the software application 106. In some examples, the number of EOT files retrieved by the failed test detector 110 in the EOT file set 112 can be configurable”) Examiner Comments: Sanders fixes, and permits an operator to configure, the number of consecutive prior run records that must all carry the identical outcome before the test is treated as consistently failing, and that configurable count is the claimed threshold number of executions over which the status of the particular task must have remained unchanged.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sanders’ teaching of recording a pass or fail status for each test in each run and of applying a configurable threshold count of runs into Eizenman’s CI/CD pipeline in order to avoid acting on an isolated or transient failure and to ensure that the pipeline responds only to outcomes that have genuinely persisted, which Sanders describes at Para.[0028] as a configurable and therefore tunable determination.
Regarding Claim 4, Eizenman and Sanders teach
The system of Claim 2.
Eizenman did not teach
wherein the status of each task comprises a code testing output or a software artifact produced by applying the corresponding task to the software project.
Sanders further teaches
wherein the status of each task comprises a code testing output or a software artifact produced by applying the corresponding task to the software project. (Sanders, Para.[0026]: “for a particular test, the EOT file 120 can identify a title of the test, a source code file associated with the test, an indication of whether the test passed or failed, an execution time of the test, and/or other information about the test and/or execution of the test. In some examples, if a particular test failed, the EOT file 120 can include an error code and/or other context data associated with failure of the test”) Examiner Comments: The pass or fail indication, execution time and error code that Sanders records for each test are outputs produced by running that test against the software application, and therefore read on the claimed code testing output produced by applying the corresponding task to the software project.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sanders’ teaching of capturing the pass or fail indication and associated error context as the recorded status into Eizenman’s CI/CD pipeline in order to preserve enough diagnostic context that a developer can later determine why a task carried the status it did, which is the express purpose Sanders identifies at Para.[0003].
Regarding Claim 5, Eizenman and Sanders teach
The system of Claim 1.
Eizenman further teaches
modify the subsequent execution of the CI/CD pipeline by: skipping the particular task in the subsequent execution of the CI/CD pipeline. (Eizenman, Para.[0073]: “It is also possible to skip a test, which may then optionally be noted separately, to show how many tests were skipped in general in terms of the coverage, and/or in comparison to what was checked in the previous build”) Examiner Comments: Eizenman omits a selected test from the run and records the omission relative to what was checked in the previous build, which is the claimed modification of the subsequent execution of the pipeline by skipping the particular task in that subsequent execution.
Regarding Claim 7, Eizenman and Sanders teach
The system of Claim 6.
Eizenman further teaches
comparing a first hash of a current iteration of the software project to a second hash of a previous iteration of the software project; and determining, based on the comparison between the first hash and the second hash, that a portion of the software project corresponding to the particular task has remained unchanged. (Eizenman, Para.[0088]: “The test footprint includes information in regard to methods tested, hashes of the functions, and locations (for example within the build) to determine what was tested, which aspects of the code were tested and hence coverage, and also which tests were run in terms of test events. Hashes of the functions may optionally and preferably be used to map between the tests performed and the functions of the code, for example to determine whether certain parts of the code were tested. Hashes may optionally be used to determine whether a method has changed even if the method does not have a name”) and (Eizenman, Para.[0058]: “the build content is analyzed to determine what changes have made from the last build, optionally and preferably ignoring comments. A stream of builds is actually preferably received through the server which is creating them, and as each build is received, it is analyzed for differences from the previous builds”) Examiner Comments: Eizenman computes hashes of the functions of the current build and compares them against the corresponding hashes retained for the previous build in order to decide whether a method has changed, so the hash of the current build is the claimed first hash of a current iteration, the retained hash of the previous build is the claimed second hash of a previous iteration, and a hash match establishes that the portion of the code exercised by the task has remained unchanged.
Regarding Claim 8, is a method claim corresponding to the system claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of claim 1.
Regarding Claim 9, is a method claim corresponding to the system claim above (Claim 2) and, therefore, is rejected for the same reasons set forth in the rejection of claim 2.
Regarding Claim 11, is a method claim corresponding to the system claim above (Claim 4) and, therefore, is rejected for the same reasons set forth in the rejection of claim 4.
Regarding Claim 12, is a method claim corresponding to the system claim above (Claim 5) and, therefore, is rejected for the same reasons set forth in the rejection of claim 5.
Regarding Claim 14, is a method claim corresponding to the system claim above (Claim 7) and, therefore, is rejected for the same reasons set forth in the rejection of claim 7.
Regarding Claim 15, is a non-transitory computer-readable medium claim corresponding to the system claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of claim 1.
Regarding Claim 16, is a non-transitory computer-readable medium claim corresponding to the system claim above (Claim 2) and, therefore, is rejected for the same reasons set forth in the rejection of claim 2.
Regarding Claim 17, is a non-transitory computer-readable medium claim corresponding to the system claim above (Claim 4) and, therefore, is rejected for the same reasons set forth in the rejection of claim 4.
Regarding Claim 18, is a non-transitory computer-readable medium claim corresponding to the system claim above (Claim 5) and, therefore, is rejected for the same reasons set forth in the rejection of claim 5.
Regarding Claim 20, is a non-transitory computer-readable medium claim corresponding to the system claim above (Claim 7) and, therefore, is rejected for the same reasons set forth in the rejection of claim 7.
Claim(s) 3, 6, 10, 13 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eizenman (US 2019/0171550 A1) in view of Sanders (US 2023/0153233 A1) and further in view of Nadar (US 2015/0100945 A1).
Regarding Claim 3, Eizenman and Sanders teach
The system of Claim 2.
Eizenman did not teach
wherein the repeated status is a test failure, wherein the metadata for the particular task indicates an intervention requirement for the test failure;
detecting that a portion of the software project corresponding to the particular task with the metadata indicating the intervention requirement has not been modified; and preventing the subsequent execution of the CI/CD pipeline based on detecting that the portion of the software project corresponding to the particular task has not been modified.
Sanders further teaches
wherein the repeated status is a test failure, wherein the metadata for the particular task indicates an intervention requirement for the test failure; (Sanders, Para.[0003]: “if a particular test consistently fails during testing of the software application, a task associated with the particular test can be created in the software development management platform. The task can be assigned to a software developer, such that the software developer can investigate why the test is consistently failing, and/or attempt to resolve issues that are preventing the test from passing”) Examiner Comments: The repeated status in Sanders is a persistent test failure, and the task record that Sanders creates and assigns to a developer so that the developer will investigate and resolve the failure is metadata that marks the failing test as one requiring human intervention, which is the claimed intervention requirement for the test failure.;
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sanders’ teaching of determining that a particular test carried a repeated status across a plurality of prior stored execution records into Eizenman’s CI/CD pipeline in order to relieve development teams of the time-intensive and laborious burden of manually evaluating each new set of test results to determine if or when individual tests have begun failing consistently, as Sanders expressly identifies at Para.[0004], and thereby to direct pipeline resources and developer attention only where they are actually needed.
Eizenman and Sanders did not specifically teach
detecting that a portion of the software project corresponding to the particular task with the metadata indicating the intervention requirement has not been modified; and preventing the subsequent execution of the CI/CD pipeline based on detecting that the portion of the software project corresponding to the particular task has not been modified.
However, Nadar (US 2015/0100945 A1) teaches
detecting that a portion of the software project corresponding to the particular task with the metadata indicating the intervention requirement has not been modified; and preventing the subsequent execution of the CI/CD pipeline based on detecting that the portion of the software project corresponding to the particular task has not been modified. (Nadar, Para.[0028]: “Resume logic module 150 polls version control system 120 to determine if a source code file has been checked-in. If a check-in is not detected (decision step 208, “NO” branch), resume logic module 150 continues to poll version control system 120”) and (Nadar, Para.[0027]: “The build of a software project is initiated via build agent 140 according to build plan 130 (step 200). The build can be initiated by a build administrator or a software developer. In various embodiments, the build can be initiated by a continuous integration server on a predetermined schedule. Subsequent to a build process failure, the project build is suspended (step 202)”) Examiner Comments: Nadar holds the failed build of the software project in a suspended state and repeatedly polls the version control system, and it releases the build to proceed only once it detects that the developer has checked in a corrected source code file, so for as long as Nadar detects that the responsible portion of the software project has not been modified it withholds the next run of the build, which is the claimed detection that the portion corresponding to the failing task has not been modified and the claimed prevention of the subsequent execution on that basis..
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Nadar’s teaching of suspending the build of a software project until the responsible source code has been checked in with the corrected content into Eizenman and Sanders’ CI/CD pipeline in order to stop the pipeline from consuming computing resources on runs that cannot succeed because the underlying defect has not yet been addressed, which is the same efficiency concern Nadar addresses at Para.[0025] when it preserves the object code produced up to the point of the failure rather than discarding and repeating that work.
Regarding Claim 6, Eizenman and Sanders teach
The system of Claim 1.
Eizenman did not teach
outputting the repeated status of the particular task in the subsequent execution of the CI/CD pipeline;
preventing execution of the particular task in the subsequent execution of the CI/CD pipeline.
Sanders further teaches
outputting the repeated status of the particular task in the subsequent execution of the CI/CD pipeline; (Sanders, Para.[0033]: “The failed test list 118 can include titles and/or other identifiers of any tests 104 that the failed test detector 110 determines have been consistently failing, based on information in the EOT file set 112. In some examples, the failed test list 118 can indicate other information about the identified consistently-failing tests”) Examiner Comments: Sanders emits a list that names each task determined to have carried the identical failing outcome across the prior runs and passes that list on to the downstream updater, which is the claimed outputting of the repeated status of the particular task.;
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sanders’ teaching of determining that a particular test carried a repeated status across a plurality of prior stored execution records into Eizenman’s CI/CD pipeline in order to relieve development teams of the time-intensive and laborious burden of manually evaluating each new set of test results to determine if or when individual tests have begun failing consistently, as Sanders expressly identifies at Para.[0004], and thereby to direct pipeline resources and developer attention only where they are actually needed.
Eizenman and Sanders did not specifically teach
preventing execution of the particular task in the subsequent execution of the CI/CD pipeline.
However, Nadar teaches
preventing execution of the particular task in the subsequent execution of the CI/CD pipeline. (Nadar, Para.[0025]: “Based on the check-in of the source code file, resume logic module 150 updates the copy of build plan 130 to create an interim build plan that includes the affected module and any modules not built due to the build fail. Further, resume logic module 150 updates the saved object code files to include the object code up to, but not including the affected module. Resume logic module 150 then resumes the build process using the interim build plan”) Examiner Comments: Nadar constructs the next run of the build from an interim plan that contains only the affected module and the modules that were never reached, and it supplies the previously saved object code for everything ahead of the affected module, so the tasks that produced that saved object code are deliberately excluded from the next run, which is the claimed prevention of execution of the particular task in the subsequent execution of the pipeline..
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Nadar’s teaching of suspending the build of a software project until the responsible source code has been checked in with the corrected content into Eizenman and Sanders’ CI/CD pipeline in order to stop the pipeline from consuming computing resources on runs that cannot succeed because the underlying defect has not yet been addressed, which is the same efficiency concern Nadar addresses at Para.[0025] when it preserves the object code produced up to the point of the failure rather than discarding and repeating that work.
Regarding Claim 10, is a method claim corresponding to the system claim above (Claim 3) and, therefore, is rejected for the same reasons set forth in the rejection of claim 3.
Regarding Claim 13, is a method claim corresponding to the system claim above (Claim 6) and, therefore, is rejected for the same reasons set forth in the rejection of claim 6.
Regarding Claim 19, is a non-transitory computer-readable medium claim corresponding to the system claim above (Claim 6) and, therefore, is rejected for the same reasons set forth in the rejection of claim 6.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui can be reached at (571) 272-3708. 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.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
