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 objections
Claim 6 is objected to because of the following informalities:
Claim 6, line 3, “generation” should have been --generating--.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims 1-9 are directed to computer implemented methods and fall within the statutory category of processes; Claims 10-14 are directed to systems and fall within the statutory category of machines; Claims 15-20 are directed to a non-transitory computer-readable medium and falls within the statutory category of articles of manufacture. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon, or an abstract idea (see MPEP §2106.04).
With respect to claim 1:
Step 2A Prong 1:
Claim 1 recites:
identifying a source branch, of source code for a software development project, for which auto-propagation is enabled for code modifications to the source branch;
evaluating the software development project to identify a destination branch to which the code modifications are to be propagated; and
in response to identifying a trigger associated with the auto-propagation for the source branch:
identifying a code modification made to the source branch;
automatically generating a merge request to merge the code modification from the source branch to the destination branch; and
executing the merge request to merge the code modification from the source branch to the destination branch.
Steps (a) – (e) recite “Mental Processes” (i.e., observation, evaluation, judgement, and/or opinion) that can be performed in the human mind, or by a human using pen and paper.
Step 2A Prong 2:
Claim 1 recites additional elements, i.e., “auto-propagation” and step (f). However, “auto-propagation” is recited at a high-level of generality such that it amounts no more than using generic computer, and/or mere computer components as a tool to perform the abstract idea. Further, step (f) is insignificant extra-solution activity.
Therefore, "Do the claims recite additional elements that integrate the judicial exception into a practical application?" No, even when viewed in combination, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all of the additional elements recite a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components and merely recite generic computer and computer components, and merely apply the abstract idea, which is well-understood, routine, and conventional (see MPEP §2106.05(d)(II) Elements that the courts have recognized as well-understood, routine, conventional activity in particular fields.). The additional elements, taken individually and in combination, do not amount to significantly more than the judicial exception. The claim is not eligible under 35 U.S.C. 101.
With respect to claim 2:
Step 2A Prong 1:
Claim 2 recites:
the source branch is a feature branch and the destination branch is a release version branch,
wherein the auto-propagation is implemented as a forward merge to merge the code modification from the feature branch forward into the release version branch.
They merely define the branches recited in claim 1 and no additional elements were presented. See corresponding analysis of Claim 1.
With respect to claim 3:
Step 2A Prong 1:
Claim 3 recites:
the source branch is a master branch and the destination branch is a release version branch
wherein the auto-propagation is implemented as a reverse merge to merge the code modification from the master branch into the release version branch
They merely define the branches recited in claim 1 and no additional elements were presented. See corresponding analysis of Claim 1.
With respect to claim 4:
Step 2A Prong 1:
Claim 4 recites “the source branch or the destination branch comprises at least one of a release version branch, a feature branch, a master branch, a developer branch, or a staging branch”. They merely provides examples of the branches recited in claim 1 and no additional elements were presented. See corresponding analysis of Claim 1.
With respect to claim 5:
Step 2A Prong 1:
See corresponding analysis of Claim 1.
Step 2A Prong 2:
The claim limitation additionally recites, “in response to a notification flag being set for the auto-propagation, generating and transmitting a notification to a developer regarding an outcome of executing the merge request;” which is merely an insignificant extra-solution activity such as gathering, displaying, updating, transmitting, and storing data, which does not integrate the judicial exception into a practical application (see MPEP §2106.05(g)), and will be analyzed further below in Step 2B as being well-understood, routine, and conventional.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all of the additional elements merely recite generic computer and computer components, and merely apply the abstract idea, which is well-understood, routine, and conventional (see MPEP §2106.05(d)(II) Elements that the courts have recognized as well-understood, routine, conventional activity in particular fields.). The additional elements, taken individually and in combination, do not amount to significantly more than the judicial exception. The claim is not eligible 35 U.S.C. 101.
With respect to claim 6:
Step 2A Prong 1:
“in response to determining that the outcome indicate that a code issue occurred from executing the merge request,” is mental process of evaluation or judgement.
Step 2A Prong 2:
The claim limitation additionally recites, “generation the notification to link to a portion of code affected by code issue” which is merely an insignificant extra-solution activity solution.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all of the additional elements merely recite generic computer and computer components, and merely apply the abstract idea, which is well-understood, routine, and conventional (see MPEP §2106.05(d)(II) Elements that the courts have recognized as well-understood, routine, conventional activity in particular fields.). The additional elements, taken individually and in combination, do not amount to significantly more than the judicial exception. The claim is not eligible 35 U.S.C. 101.
With respect to claim 7:
Step 2A Prong 1:
Claim 7 recites “defining the trigger as a determination as to whether a pipeline job is to be executed”, which is mental process of opinion, evaluation, or judgement.
Step 2A Prong 2:
There are no additional elements to integrate the “Mental Process.”
With respect to claim 8:
Claim 8 recites:
during automated execution of the merge request, performing conflict resolution based upon a determination that a code conflict exists from merging the code modification into the destination branch
Step 2A Prong 2:
Step (a) merely recites instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. (see MPEP §2106.05(f)).
Therefore, "Do the claims recite additional elements that integrate the judicial exception into a practical application?" No, even when viewed in combination, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim will be analyzed further below in Step 2B as being well-understood, routine, and conventional.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all of the additional elements merely recite generic computer and computer components, and merely apply the abstract idea, which is well-understood, routine, and conventional (see MPEP §2106.05(d)(II) Elements that the courts have recognized as well-understood, routine, conventional activity in particular fields.). The additional elements, taken individually and in combination, do not amount to significantly more than the judicial exception. The claim is not eligible under 35 U.S.C. 101.
With respect to claim 9:
Step 2A Prong 1:
See corresponding analysis of Claim 1.
Step 2A Prong 2:
The claim limitation additionally recites “triggering auto-propagation for the code modifications to maintain code consistency across branches of the software development project” which is merely an insignificant extra-solution activity which does not integrate the judicial exception into a practical application (see MPEP §2106.05(g)), and will be analyzed further below in Step 2B as being well-understood, routine, and conventional.
Therefore, "Do the claims recite additional elements that integrate the judicial exception into a practical application?" No, even when viewed in combination, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim will be analyzed further below in Step 2B as being well-understood, routine, and conventional.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all of the additional elements merely recite generic computer and computer components, and merely apply the abstract idea, which is well-understood, routine, and conventional (see MPEP §2106.05(d)(II) Elements that the courts have recognized as well-understood, routine, conventional activity in particular fields.). The additional elements, taken individually and in combination, do not amount to significantly more than the judicial exception. The claim is not eligible under 35 U.S.C. 101.
With respect to claim 10:
Step 2A Prong 1:
Claim 10 recites substantially the same steps as claim 1 and see corresponding analysis of Claim 1.
Step 2A Prong 2:
Claim 1 recites additional elements, i.e., “one or more processors”, “auto-propagation”, and step of executing . However, “one or more processors” and “auto-propagation” are recited at a high-level of generality such that it amounts no more than using generic computer, and/or mere computer components as a tool to perform the abstract idea. Further, the executing step is insignificant extra-solution activity.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all of the additional elements recite a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components and merely recite generic computer and computer components, and merely apply the abstract idea, which is well-understood, routine, and conventional (see MPEP §2106.05(d)(II) Elements that the courts have recognized as well-understood, routine, conventional activity in particular fields.). The additional elements, taken individually and in combination, do not amount to significantly more than the judicial exception. The claim is not eligible under 35 U.S.C. 101.
With respect to claim 11:
Step 2A Prong 1:
Claim 11 recites:
the destination branch is a first release version branch, and
wherein the operations further comprise: auto-propagating the code modification to a plurality of destination branches that include the first release version branch and a second release version branch.
Wherein, (a) merely provides an example of the branch recited in claim 10. See corresponding analysis of Claim 10.
Step 2A Prong 2:
Step (b) merely recites instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. (see MPEP §2106.05(f)).
Therefore, "Do the claims recite additional elements that integrate the judicial exception into a practical application?" No, even when viewed in combination, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim will be analyzed further below in Step 2B as being well-understood, routine, and conventional.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all of the additional elements merely recite generic computer and computer components, and merely apply the abstract idea, which is well-understood, routine, and conventional (see MPEP §2106.05(d)(II) Elements that the courts have recognized as well-understood, routine, conventional activity in particular fields.). The additional elements, taken individually and in combination, do not amount to significantly more than the judicial exception. The claim is not eligible under 35 U.S.C. 101.
With respect to claim 12:
Step 2A Prong 1:
See corresponding analysis of Claim 10.
Step 2A Prong 2:
The claim limitation additionally recites “generating and executing a plurality of merge requests in parallel on different branches within the software development project;” which merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. (see MPEP §2106.05(f)).
Therefore, "Do the claims recite additional elements that integrate the judicial exception into a practical application?" No, even when viewed in combination, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim will be analyzed further below in Step 2B as being well-understood, routine, and conventional.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all of the additional elements merely recite generic computer and computer components, and merely apply the abstract idea, which is well-understood, routine, and conventional (see MPEP §2106.05(d)(II) Elements that the courts have recognized as well-understood, routine, conventional activity in particular fields.). The additional elements, taken individually and in combination, do not amount to significantly more than the judicial exception. The claim is not eligible under 35 U.S.C. 101.
With respect to claim 13:
Step 2A Prong 1:
See corresponding analysis of Claim 10.
Step 2A Prong 2:
The claim limitation additionally recites “generating and executing a plurality of merge requests in parallel on different branches within the software development project, wherein the different branches corresponds to different feature branches being modified;” which merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. (see MPEP §2106.05(f)).
Therefore, "Do the claims recite additional elements that integrate the judicial exception into a practical application?" No, even when viewed in combination, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim will be analyzed further below in Step 2B as being well-understood, routine, and conventional.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all of the additional elements merely recite generic computer and computer components, and merely apply the abstract idea, which is well-understood, routine, and conventional (see MPEP §2106.05(d)(II) Elements that the courts have recognized as well-understood, routine, conventional activity in particular fields.). The additional elements, taken individually and in combination, do not amount to significantly more than the judicial exception. The claim is not eligible under 35 U.S.C. 101.
With respect to claim 14:
Step 2A Prong 1:
See corresponding analysis of Claim 10.
Step 2A Prong 2:
The claim limitation additionally recites “integrating an auto-propagation add-on into a software development platform to provide auto-propagation functionality not natively supported by the software development platform, wherein the auto-propagation add-on includes a script comprising auto-propagation logic, a job execution machine that will execute the script as a job, and a markup language file used to define the trigger;” which merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. (see MPEP §2106.05(f)).
Therefore, "Do the claims recite additional elements that integrate the judicial exception into a practical application?" No, even when viewed in combination, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim will be analyzed further below in Step 2B as being well-understood, routine, and conventional.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all of the additional elements merely recite generic computer and computer components, and merely apply the abstract idea, which is well-understood, routine, and conventional (see MPEP §2106.05(d)(II) Elements that the courts have recognized as well-understood, routine, conventional activity in particular fields.). The additional elements, taken individually and in combination, do not amount to significantly more than the judicial exception. The claim is not eligible under 35 U.S.C. 101.
With respect to claim 15:
Step 2A Prong 1:
See corresponding analysis of Claim 10.
Step 2A Prong 2:
The claim limitation additionally recites “A non-transitory computer-readable medium storing instructions that when executed facilitate performance of operations comprising;”, which merely recites instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. (see MPEP §2106.05(f)). Further, the executing step is insignificant extra-solution activity.
Therefore, "Do the claims recite additional elements that integrate the judicial exception into a practical application?" No, even when viewed in combination, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim will be analyzed further below in Step 2B as being well-understood, routine, and conventional.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all of the additional elements merely recite generic computer and computer components, and merely apply the abstract idea, which is well-understood, routine, and conventional (see MPEP §2106.05(d)(II) Elements that the courts have recognized as well-understood, routine, conventional activity in particular fields.). The additional elements, taken individually and in combination, do not amount to significantly more than the judicial exception. The claim is not eligible under 35 U.S.C. 101.
With respect to claim 16:
Step 2A Prong 1:
See corresponding analysis of Claims 15.
Step 2A Prong 2:
The claim limitation additionally recites “executing the auto-propagation to push code modifications made to a master branch to future release version branches; which merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea. (see MPEP §2106.05(f)).
Therefore, "Do the claims recite additional elements that integrate the judicial exception into a practical application?" No, even when viewed in combination, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim will be analyzed further below in Step 2B as being well-understood, routine, and conventional.
Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract ideas into a practical application, all of the additional elements merely recite generic computer and computer components, and merely apply the abstract idea, which is well-understood, routine, and conventional (see MPEP §2106.05(d)(II) Elements that the courts have recognized as well-understood, routine, conventional activity in particular fields.). The additional elements, taken individually and in combination, do not amount to significantly more than the judicial exception. The claim is not eligible under 35 U.S.C. 101.
With respect to claim 17:
Step 2A Prong 1:
Claim 17 recites “defining a new trigger as a merge being performed on a first branch that is to be auto-propagated to a second branch”, which is mental process of opinion, evaluation, or judgement. See corresponding analysis of Claim 15.
Step 2A Prong 2:
There are no additional elements to integrate the “Mental Process.”
With respect to claim 18:
Step 2A Prong 1:
See corresponding analysis of Claims 15 and 5.
Step 2A Prong 2:
See corresponding analysis of Claim 5.
Step 2B:
See corresponding analysis of Claim 5.
With respect to claim 19:
Step 2A Prong 1:
See corresponding analysis of Claims 15 and 2.
Step 2A Prong 2:
See corresponding analysis of Claim 2.
Step 2B:
See corresponding analysis of Claim 2.
With respect to claim 20:
Step 2A Prong 1:
See corresponding analysis of Claims 15 and 3.
Step 2A Prong 2:
See corresponding analysis of Claim 3.
Step 2B:
See corresponding analysis of Claim 3.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 4, 10-11, 15, and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Cote et al. (US 7603393 B1, hereinafter Cote).
With respect to claim 1:
Cote teaches A method comprising:
identifying a source branch (e.g., FIG. 1, one of “a number of branches 104”), of source code for a software development project (e.g., col. 2, lines 29-30 “Aspects of the invention relate to a software development tool”), for which auto-propagation is enabled for code modifications to the source branch (e.g., col. 3, lines 36-43, “As described in detail below, a software merge utility may enable automatic merging of software changes across any number of branches and sub-branches without requiring manual entry of either file or branch locations or find merge command attributes. In implementing the merge utility, data representative of each potential merge represented by graphical merge arrows 106 may be stored in a database available to the software merge utility.”);
evaluating the software development project to identify a destination branch to which the code modifications are to be propagated (e.g., col. 1, lines 44-46 “A file check-in request is identified. A merge candidate associated with the file is automatically identified. A view associated with the identified merge candidate is automatically identified.” Further, see col. 6, lines 47-52 );
in response to identifying a trigger (e.g., col. 6, lines 47-63, “findmerge command”); associated with the auto-propagation for the source branch: (e.g., col. 6, lines 54-58, “The generated command would specifically identify each merged-from and merged-to file and would receive in response results indicating any merger candidates identified within the ClearCase application”);
identifying a code modification made to the source branch (e.g., col. 3, lines 1-4, “As is known, once modifications to any line have been finalized, it may be desirable to incorporate the changes into a number of branches 104. This process is generally referred to as ‘merging’”).
automatically generating a merge request to merge the code modification from the source branch to the destination branch (e.g., col. 1, lines 52-54, "merge utility configured to automatically initiate merging of a first version of a file with a second version of the file in a versioning system". ); and
executing the merge request to merge the code modification from the source branch to the destination branch (e.g., col. 7, lines 7-9, "In another implementation, building of merged files may be performed automatically.");
With respect to claim 2:
Cote teaches “The method of claim 1, wherein the source branch is a feature branch and the destination branch is a release version branch, and wherein the auto-propagation is implemented as a forward merge to merge the code modification from the feature branch forward into the release version branch” (e.g., fig. 1 and col. 3, lines 24-40, “As shown in FIG. 1, potential merges between branches 104 and mainline 102 may be graphically represented by a number of merge arrows 106. Each merge arrow 106 represents at least one element of shared software code between the starting point location and the ending point location. For example, patch release 7.0.4 at the end of branch 104d may merge to the initial 7.1_bugfix branch 104c, thereby implying that changes resulting from the development of branch 104d may be applied to the development of each element of branch 104c. Furthermore, modifications from a sub-branch 108 of branch 104d may also be applied to the elements of sub-branch 110 of branch 104c. As described in detail below, a software merge utility may enable automatic merging of software changes across any number of branches and sub-branches without requiring manual entry of either file or branch locations or findmerge command attributes.”).
With respect to claim 4:
Cote teaches The method of claim 1, wherein the source branch or the destination branch comprises at least one of ” (e.g., col. 3, lines 28-35, “… , thereby implying that changes resulting from the development of branch 104d.”).
With respect to claim 10:
Cote teaches “A system (“computing device 300”) comprising: one or more processors configured for executing instructions to perform operations comprising” (e.g., col. 4, lines 29-39, “Processor 320 may include any type of processor, microprocessor, or processing logic that interprets and executes instructions.”);
identifying a source branch (e.g., FIG. 1, one of “a number of branches 104”), of a software development project (e.g., col. 2, lines 29-30 “Aspects of the invention relate to a software development tool”), for which auto-propagation is enabled for code modifications to the source branch (e.g., col. 3, lines 36-43, “As described in detail below, a software merge utility may enable automatic merging of software changes across any number of branches and sub-branches without requiring manual entry of either file or branch locations or find merge command attributes. In implementing the merge utility, data representative of each potential merge represented by graphical merge arrows 106 may be stored in a database available to the software merge utility.”) ;
evaluating the software development project to identify a destination branch to which the code modifications are to be propagated (e.g., col. 1, lines 44-46 “A file check-in request is identified. A merge candidate associated with the file is automatically identified. A view associated with the identified merge candidate is automatically identified.” Further, see col. 6, lines 47-52 );
in response to identifying a trigger (e.g., col. 6, lines 47-63, “findmerge command”); associated with the auto-propagation for the source branch: (e.g., col. 6, lines 54-58, “The generated command would specifically identify each merged-from and merged-to file and would receive in response results indicating any merger candidates identified within the ClearCase application”);
identifying a code modification made to the source branch (e.g., col. 3, lines 1-4, “As is known, once modifications to any line have been finalized, it may be desirable to incorporate the changes into a number of branches 104. This process is generally referred to as ‘merging’”).
automatically generating a merge request to merge the code modification from the source branch to the destination branch (e.g., col. 1, lines 52-54, "merge utility configured to automatically initiate merging of a first version of a file with a second version of the file in a versioning system". ); and
executing the merge request to merge the code modification from the source branch to the destination branch (e.g., col. 7, lines 7-9, "In another implementation, building of merged files may be performed automatically.");
With respect to claim 11:
Cote teaches The system of claim 10, wherein the destination branch is a first release version branch, and wherein the operations further comprise: auto-propagating the code modification to a plurality of destination branches that include the first release version branch and a second release version branch (e.g., fig. 4 and col. 3, lines 26-33, “Each merge arrow 106 represents at least one element of shared software code between the starting point location and the ending point location. For example, patch release 7.0.4 at the end of branch 104d may merge to the initial 7 .l_bugfix branch 104c, thereby implying that changes resulting from the development of branch 104d may be applied to the development of each element of branch 104c.”).
With respect to claim 15:
Cote teaches Non-transitory computer-readable medium (“ROM 340”) storing instructions that when executed facilitate performance of operations comprising” (e.g., col. 4, lines 29-44, “… static information and instructions for use by processor 320.”);
identifying a source branch (e.g., FIG. 1, one of “a number of branches 104”), of a software development project (e.g., col. 2, lines 29-30 “Aspects of the invention relate to a software development tool”), for which auto-propagation is enabled for code modifications to the source branch (e.g., col. 3, lines 36-43, “As described in detail below, a software merge utility may enable automatic merging of software changes across any number of branches and sub-branches without requiring manual entry of either file or branch locations or find merge command attributes. In implementing the merge utility, data representative of each potential merge represented by graphical merge arrows 106 may be stored in a database available to the software merge utility.”) ;
evaluating the software development project to identify a destination branch to which the code modifications are to be propagated (e.g., col. 1, lines 44-46 “A file check-in request is identified. A merge candidate associated with the file is automatically identified. A view associated with the identified merge candidate is automatically identified.” Further, see col. 6, lines 47-52 );
in response to identifying a trigger (e.g., col. 6, lines 47-63, “findmerge command”); associated with the auto-propagation for the source branch: (e.g., col. 6, lines 54-58, “The generated command would specifically identify each merged-from and merged-to file and would receive in response results indicating any merger candidates identified within the ClearCase application”);
identifying a code modification made to the source branch (e.g., col. 3, lines 1-4, “As is known, once modifications to any line have been finalized, it may be desirable to incorporate the changes into a number of branches 104. This process is generally referred to as ‘merging’”).
automatically generating a merge request to merge the code modification from the source branch to the destination branch (e.g., col. 1, lines 52-54, "merge utility configured to automatically initiate merging of a first version of a file with a second version of the file in a versioning system". ); and
executing the merge request to merge the code modification from the source branch to the destination branch (e.g., col. 7, lines 7-9, "In another implementation, building of merged files may be performed automatically.");
With respect to claim 19:
Cote teaches “wherein the source branch is a feature branch and the destination branch is a release version branch, and wherein the auto-propagation is implemented as a forward merge to merge the code modification from the feature branch forward into the release version branch” (e.g., fig. 1 and col. 3, lines 24-40, “As shown in FIG. 1, potential merges between branches 104 and mainline 102 may be graphically represented by a number of merge arrows 106. Each merge arrow 106 represents at least one element of shared software code between the starting point location and the ending point location. For example, patch release 7.0.4 at the end of branch 104d may merge to the initial 7.1_bugfix branch 104c, thereby implying that changes resulting from the development of branch 104d may be applied to the development of each element of branch 104c. Furthermore, modifications from a sub-branch 108 of branch 104d may also be applied to the elements of sub-branch 110 of branch 104c. As described in detail below, a software merge utility may enable automatic merging of software changes across any number of branches and sub-branches without requiring manual entry of either file or branch locations or findmerge command attributes.”).
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 3 is rejected under 35 U.S.C. 103 as being unpatentable over Cote in view of Kolesnik et al. (US 20200257597 A1, hereinafter Kolesnik).
With respect to claim 3:
Cote does not teach however Kolesnik teaches, wherein the source branch is a master branch and the destination branch is a release version branch, and wherein (e.g., [0032], “Additionally, a developer may decide to implement a portion of source code or a commit (e.g., target commit 230) from the master branch 210A in the release branch 220A.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Kolesnik to improve software development efficiency by reducing manual synchronization efforts and ensure code modifications are consistently propagated across branches.
Claims 5 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Cote in view of Walker et al. (US 10671373 B1, hereinafter Walker).
With respect to claim 5:
Cote does not teach however Walker teaches in response to a notification flag being set for the auto-propagation, generating and transmitting a notification (“notify”) to a developer regarding an outcome of executing the merge request” (e.g., col. 10, lines 20-24, “When, it is determined, however, at 330, that the change was not incorporated successfully into all the identified branches, method 300 may proceed to notify the developer and/or any other individual responsible for the task entry created for the change, at 335”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Walker to provide the predictable benefit of improving software development management of automated-propagation while reducing manual efforts of checking propagation results.
With respect to claim 6:
Cote does not teach however Walker teaches “The method of claim 5, comprising: in response to determining that the outcome indicates that a code issue occurred from executing the merge request, generation the notification (“notify”) to link to a portion of code affected by the code issue” (e.g., col. 10, lines 30-33, “In one implementation, the notification may also include information about the issue that prevented successful incorporation of the change into all identified branches, information on which branches successfully received the change and which ones did not, and/or any other available information that may provide helpful to a person responsible for ensuring the change is incorporate”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Walker to further improve efficiency of software development management of automated-propagation while reducing manual efforts of locating code issues.
Claims 7-9 are rejected under 35 U.S.C. 103 as being unpatentable over Cote in view of Cimadamore et al. (US 20190163478 A1, hereinafter Cimadamore).
With respect to claim 7:
Cote does not teach however Cimadamore teaches “The method of claim 1, comprising: defining the trigger as a determination as to whether a pipeline job is to be executed” (e.g., [0046]-[0047], “includes a poll job 112, a sync job 114, and/or a test job 116. The poll job is configured to detect changes in any repository 132a-b associated with a set of code. If a change is detected, then the sync job 114 is executed … The sync job 114 is configured to propagate changes through the set of branches 134a-d.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Cimadamore because polling provides a known technique for monitoring conditions and triggers execution of pipeline jobs when the required condition is satisfied.
With respect to claim 8:
Cote does not teach however Cimadamore teaches “The method of claim 1, comprising: during automated execution of the merge request, performing conflict resolution based upon a determination that a code conflict exists from merging the code modification into the destination branch” (e.g., [0044], “In one or more embodiments, conflict resolution rules 120 are rules for resolving conflicts detected during an attempt to merge two branches.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Cimadamore to further improve efficiency of software development management of automated-propagation and the success rate of branch synchronization.
With respect to claim 9:
Cote does not teach however Cimadamore teaches triggering auto-propagation for the code modifications to maintain code consistency across branches of the software development project (e.g., [0029], “Further, a system-triggered synchronization process traverses parent branches prior to child branches to ensure that changes are propagated through all branches.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Cimadamore to further improve efficiency of software development management of automated-propagation and reduce efforts of manual intervention.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Cote in view of Owen et al. (US 20220236974 A1, hereinafter Owen).
With respect to claim 12:
Cote does not teach however Owen teaches “The system of claim 10, wherein the operations further comprise: generating and executing a plurality of merge requests in parallel on different branches within the software development project” (e.g., fig. 3 and [0037]-[0038], “In block 306, the safe revert module 120 performs a merge of the trunk with the branch using the copy of the first merge based on the patch branch … In some embodiments, various operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Owen to increase efficiency of software development by enabling developers to work on different branches in parallel.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Cote in view of Owen et al. (US 20220236974 A1, hereinafter Owen) and Cimadamore.
With respect to claim 13:
Cote does not teach however Owen teaches “The system of claim 10, wherein the operations further comprise: generating and executing a plurality of merge requests in parallel on different branches within the software development project” (e.g., fig. 3 and [0037]-[0038], “In block 306, the safe revert module 120 performs a merge of the trunk with the branch using the copy of the first merge based on the patch branch … In some embodiments, various operations may be performed in parallel with other operations, either in a synchronous or asynchronous manner.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Owen to increase efficiency of software development by enabling developers to work on different branches in parallel.
Cote modified by Owen does not teach however Cimadamore teaches “” (e.g., [0003], “Each code branch ( also referred to herein as a "branch") is associated with the development of a different feature, bug fix, and/or aspect of a software application.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Owen and Cimadamore to further increase efficiency of software development by enabling developers to work on different branches in parallel.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Cote in view of Sagal et al. (US 20210382708 A1, hereinafter Sagal) and Liu et al. (US 10528367 B1, hereinafter Liu)
With respect to claim 14:
Cote does not teach however Sagal teaches “The system of claim 10, wherein the operations further comprise: integrating an auto-propagation add-on into a software development platform to provide auto-propagation functionality not natively supported by the software development platform, wherein the auto-propagation add-on ” (e.g., [0208], “This integration may be achieved via plug-ins for third party change management, version control, and build automation tools.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Sagal to allow developers to selectively enable auto-propagation based on certain developer-defined conditions, which will increase flexibility and adaptability across different software development workflows without modifying the core system.
Sagal does not teach however Liu teaches “” (e.g., col. 7, lines 28-33 and col. 25, lines 44-47, “As referred to herein, a “policy” template is used to specify automatically triggered workflows. Common “triggers” as referred to herein may include time based triggers, for example triggers based on cron, and triggers based on commits, pull requests, and/or merges to repositories … A workflow is a source object (414) based on a high-level programming language such as YAML that may be run by the execution platform (228).”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Liu to allow developers to selectively enable auto-propagation based on certain developer-defined conditions, which will increase flexibility and adaptability across different software development workflows without modifying the core system.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Cote in view of Kolesnik.
With respect to claim 16:
Cote does not teach however Kolesnik teaches “” (e.g., [0032], “Additionally, a developer may decide to implement a portion of source code or a commit (e.g., target commit 230) from the master branch 210A in the release branch 220A.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Kolesnik to improve software development efficiency by reducing manual synchronization efforts and ensure code modifications are consistently propagated across branches.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Cote in view of Cimadamore.
With respect to claim 17:
Cotes does not teach however Cimadamore teaches wherein the operations further comprise: defining a new trigger as a merge being performed on a first branch that is to be auto-propagated to a second branch (e.g., [0021], “As an example, after a change has occurred on the first branch, both the second branch and the third branch are out of sync. Synchronizing the set of code branches includes updating the second branch by incorporating the updated state of the first branch to generate an updated state of the second branch.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Cimadamore to improve efficiency of the software development project and reduce efforts of manual intervention.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Cote in view of Walker.
With respect to claim 18:
Cote does not teach however Walker teaches wherein the operations further comprise: in response to a notification flag being set for the auto-propagation, generating and transmitting a notification (“notifying”) to a developer regarding an outcome of executing the merge request (e.g., col. 10, lines 20-24, “When, it is determined, however, at 330, that the change was not incorporated successfully into all the identified branches, method 300 may proceed to notify the developer and/or any other individual responsible for the task entry created for the change, at 335”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cote with the invention of Walker to provide the predictable benefit of improving software development management of automated-propagation while reducing manual efforts of checking propagation results.
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cote in view of Kolesnik.
With respect to claim 20:
Cote does not teach however Kolesnik teaches, “” (e.g., [0032], “Additionally, a developer may decide to implement a portion of source code or a commit (e.g., target commit 230) from the master branch 210A in the release branch 220A.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Cimadamore with the invention of Kolesnik to improve software development efficiency by reducing manual synchronization efforts and ensure code modifications are consistently propagated across branches.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHELLE XUE HAN whose telephone number is (571)270-3362. The examiner can normally be reached Mon-Fri (7:30-5), Every 2nd Fri off.
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, Hyung Sough can be reached at (571) 272-6799. 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.
/MICHELLE XUE HAN/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights