DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to response filed on 3/19/2026. This action is FINAL.
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. Claim 1 recites, “determining… a source branch and a target branch…” and “performing code merging on the first coming code….in the target branch”. The limitations of “determining” and “performing code merging” as drafted are functions that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the function through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, this judicial exception is not integrated into a practical application. The claim recites the following additional element, “displaying… the first commit code and the second commit code…”. The additional element of “displaying”, is recited at a high level of generality and thus is an insignificant extra-solution activity. See MPEP 2106.05(g). Further, the limitation “computing device” is recited at 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, MPEP 2106.05(f). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception.
Under Step 2B, the claims 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 additional elements of “computing device” amounts to no more than mere instructions, or generic computer/computer components to carry out the exception, for the limitation of “displaying…the first commit code and the and the at least a second commit code…” is identified as a well-understood, routine, conventional activity (2106.05(d)). Also see MPEP 2106.05(f). The recitation of generic computer instruction and computer components to apply the judicial exception, and the well-understood, routine, conventional activities do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, claim 1 is not patent eligible under 35 USC 101.
Claim 2, claims “determining the first commit code…” and “determining the second commit code..”. These steps of “determining” are additional limitations of the abstract idea “Mental Process”. Nothing in the claimed limitations prevents this limitation from being performed in the mind. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 3, “presenting to the user a commit code…”. The step of “presenting” is identified as a well-understood, routine, conventional activity (2106.05(d)). Also see MPEP 2106.05(f). The step of “performing code merging on the first commit code…” is an additional limitation of the abstract idea “Mental Process”. Nothing in the claimed limitation prevents this limitation from being performed in the mind. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 4, claims “presenting an association relationship between the first commit code and the second commit code to the user…”. The step of “presenting” is identified as a well-understood, routine, conventional activity (2106.05(d)). Also see MPEP 2106.05(f). The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 5, claims “analyzing a used variable and a called function…” and “searching a record file…”. The steps of “analyzing” and “searching” are additional limitations of the abstract idea “Mental Process”. Nothing in the claimed limitations prevents this limitation from being performed in the mind. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 6, claims “skipping a conflicting commit code”. The step of “skipping” is an additional limitation of the abstract idea “Mental Process”. Nothing in the claimed limitation prevents this limitation from being performed in the mind. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 7, claims “moving a conflicting code to an end of a commit code sequence…”. The step of “moving” is an additional limitation of the abstract idea “Mental Process”. Nothing in the claimed limitation prevents this limitation from being performed in the mind. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 8, claims “prompting the user to skip a conflicting commit code…”. The step of “prompting” is identified as a well-understood, routine, conventional activity (2106.05(d)). Also see MPEP 2106.05(f). The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 9, claims “receiving a pick policy…”. Regarding the step of “receiving”, the courts have identified mere data gathering is also well-understood, routine and conventional activity. Se MPEP 2106.05(d) and MPEP 2106.05(f). The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 10, The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claims 11-20, contain similar limitations to claim 1-10 and are therefore rejected for the same reason.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-6, 9-10-16 and 19-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Rajput et al. (US 10,146,530 B1).
As per claim 1 (Amended), Rajput et al. teaches the invention as claimed including “A code processing method performed by a computing device, comprising:
determining, by the computing device, a source branch and a target branch of a software development project, ing a plurality of commit codes, ing a first commit code and at least one [[a]] second commit code associated with the first commit code;”
Rajput et al. teaches a user may indicate that a source branch should be merged with a target branch (column 6, lines 8-24). The system may choose one of the branches as the target branch, for example, the original or main software code, or the user may indicate the target branch. A difference list (plurality of commits) may then be generated from the perspective of the target branch (Column 7, lines 4-12). The branches may be different versions, where a version includes changes (commit codes) different from another branch or the original software code (column 5, lines 13-25). The system may generate a difference list that includes a listing of added code snippets, deleted code snippets, and changed code snippets (plurality of commit codes). The code snippets may be clustered in the difference list by difference chunks. The difference chunks may include clusters of connected components or code snippets (column 5, lines 26-35). The examiner states that the firs and second commit are associated with each other since they are both part of the same branch.
“displaying, by the computing device to a user, at least a second commit code
They system generates or builds a relationship graph to represent the relationships between difference chunks, including difference chunks in the same file and difference chunks across files. The relationship graph is a visual representation of the relationship between the difference chunks. At least a portion of each difference chunk may be represented by a node within the relationship graph. Each edge includes a cost vector or weight which represents a dependency and similarity between two corresponding nodes. Using a relationship graph a user can identify the relationship between different sub-sets of the two or more code branches. The user can select nodes on the relationship graph to be added to the merge, filter unusable or unwanted nodes, or edit code before the branches are merged (column 5,lines 32- 54). Also see column 5, lines 61- column 6, lines 1-3. And column 6, lines 53-column 7,lines 1-2. The difference list may then be generated from the perspective of the target branch (Column 7, lines 4-12). Also see column 7, lines 41-45 and Column 8, lines 34-55.
“performing code merging on the first commit code, some or all of second commit codes, and a commit code in the target branch.”
Once the relationship graph has been created, the user may select difference chunks to be added to the merge. Selecting the difference chunks may include a user actually selecting the node on the graph to be added. If the user did not add or select a sub-set, entire file, or branch to merge, the system may take no further action. However, if the user did add or select a sub-set, the system performs the merge with the accepted difference chunk (Column 8, lines 34-55). Also see, column 9, lines 15-26.
As per claim 2, Rajput et al. further teaches, “The method according to claim 1, further comprising:
determining the first commit code picked by the user; and
determining the second commit code associated with the first commit code.”
Rajput et al. teaches a user may indicate that a source branch should be merged with a target branch (column 6, lines 8-24). The system may choose one of the branches as the target branch, for example, the original or main software code, or the user may indicate the target branch. A difference list may then be generated from the perspective of the target branch (Column 7, lines 4-12). The branches may be different versions, where a version includes changes (commit codes) different from another branch or the original software code (column 5, lines 13-25). The system may generate a difference list that includes a listing of added code snippets, deleted code snippets, and changed code snippets. The code snippets may be clustered in the difference list by difference chunks. The difference chunks may include clusters of connected components or code snippets (column 5, lines 26-35). The system generates or builds a relationship graph to represent the relationships between difference chunks, including difference chunks in the same file and difference chunks across files. The relationship graph is a visual representation of the relationship between the difference chunks. At least a portion of each difference chunk may be represented by a node within the relationship graph. Each edge includes a cost vector or weight which represents a dependency and similarity between two corresponding nodes. Using a relationship graph a user can identify the relationship between different sub-sets of the two or more code branches. The user can select nodes on the relationship graph to be added to the merge, filter unusable or unwanted nodes, or edit code before the branches are merged (column 5, lines 32- 54). Also see column 5, lines 61- column 6, lines 1-3. And column 6, lines 53-column 7, lines 1-2. The difference list may then be generated from the perspective of the target branch (Column 7, lines 4-12). Also see column 7, lines 41-45 and Column 8, lines 34-55. The system builds a relationship graph, which is a visual representation of the “diff” and the relationships between difference chunks included in the “diff”. The relationship graph includes a plurality of nodes. Each edge may include a cost vector or weight, for example, which represents a dependency and similarity between the two nodes connected by the edge. The cost vectors or weights included in the edges include a subscript denoting the file of the source node and the destination node. The cost vectors also include a dependency identifier and a similarity identifier (column 7, lines 41-45).
Once the relationship graph has been created, the user may select difference chunks to be added to the merge. Selecting the difference chunks may include a user actually selecting the node on the graph to be added. If the user did not add or select a sub-set, entire file, or branch to merge, the system may take no further action. However, if the user did add or select a sub-set, the system performs the merge with the accepted difference chunk (Column 8, lines 34-55).
As per claim 3, Rajput et al. further teaches, “The method according to claim 1, further comprising:
presenting to the user a commit code picked from the second commit code, wherein the step of performing code merging comprises:
performing code merging on the first commit code, the commit code picked from the second commit code, and the commit code in the target branch.”
The system may choose one of the branches as the target branch, for example, the original or main software code, or the user may indicate the target branch. The difference list may then be generated from the perspective of the target branch (Column 7, lines 4-12). The system builds a relationship graph, which is a visual representation of the “diff” and the relationships between difference chunks included in the “diff”. The relationship graph includes a plurality of nodes. Each edge may include a cost vector or weight, for example, which represents a dependency and similarity between the two nodes connected by the edge. The cost vectors or weights included in the edges include a subscript denoting the file of the source node and the destination node. The cost vectors also include a dependency identifier and a similarity identifier (column 7, lines 41-45). Once the relationship graph has been created, the user may select difference chunks to be added to the merge. Selecting the difference chunks may include a user actually selecting the node on the graph to be added. If the user did not add or select a sub-set, entire file, or branch to merge, the system may take no further action. However, if the user did add or select a sub-set, the system performs the merge with the accepted difference chunk (Column 8, lines 34-55).
As per claim 4, Rajput et al. further teaches, “The method according to claim 1, further comprising:
presenting an association relationship between the first commit code and the second commit code to the user, wherein the association relationship comprises a relationship between a definition and use of a variable or a relationship between a definition and calling of a function.”
The system generates or builds a relationship graph to represent the relationships between difference chunks, including difference chunks in the same file and difference chunks across files. The relationship graph is a visual representation of the relationship between the difference chunks. At least a portion of each difference chunk may be represented by a node within the relationship graph. Each edge includes a cost vector or weight which represents a dependency and similarity between two corresponding nodes. Using a relationship graph a user can identify the relationship between different sub-sets of the two or more code branches. The user can select nodes on the relationship graph to be added to the merge, filter unusable or unwanted nodes, or edit code before the branches are merged (column 5, lines 32- 54). Also see column 5, lines 61- column 6, lines 1-3. And column 6, lines 53-column 7, lines 1-2. The difference list may then be generated from the perspective of the target branch (Column 7, lines 4-12). Also see column 7, lines 41-45 and Column 8, lines 34-55.
The system tracks dependencies within a single file or across multiple files. For example, the system may identify a variable, code snippet, or code segments that is dependent on another variable, code snippet, or code segment. In order to track the dependencies, the system performs a dependency analysis within the tile or branch, and/or across multiple files, or branches (column 6, lines 30 – 52).
As per claim 5, Rajput et al. further teaches, “The method according to claim 1, wherein the step of determining the second commit code associated with the first commit code comprises:
analyzing a used variable and a called function in a changed code file corresponding to the first commit code; and
searching a record file, based on the used variable and the called function in the changed code file corresponding to the first commit code, to obtain the second commit code associated with the first commit code, wherein the record file records a variable and a function defined in a commit code committed before the first commit code and an association relationship between commit codes committed before the first commit code.”
The system generates or builds a relationship graph to represent the relationships between difference chunks, including difference chunks in the same file and difference chunks across files. The relationship graph is a visual representation of the relationship between the difference chunks. At least a portion of each difference chunk may be represented by a node within the relationship graph. Each edge includes a cost vector or weight which represents a dependency and similarity between two corresponding nodes. Using a relationship graph a user can identify the relationship between different sub-sets of the two or more code branches. The user can select nodes on the relationship graph to be added to the merge, filter unusable or unwanted nodes, or edit code before the branches are merged (column 5,lines 32- 54). Also see column 5, lines 61- column 6, lines 1-3. And column 6, lines 53-column 7,lines 1-2. The difference list may then be generated from the perspective of the target branch (Column 7, lines 4-12). Also see column 7, lines 41-45 and Column 8, lines 34-55.
The system tracks dependencies within a single file or across multiple files. For example, the system may identify a variable, code snippet, or code segments that is dependent on another variable, code snippet, or code segment. In order to track the dependencies, the system performs a dependency analysis within the file or branch, and/or across multiple files, or branches (column 6, lines 30 – 52).
As per claim 6, Rajput et al. further teaches, “The method according to claim 1, further comprising:
skipping a conflicting commit code when the user picks the conflicting commit code.”
Once the relationship graph has been created, the user may select difference chunks to be added to the merge. Selecting the difference chunks may include a user actually selecting the node on the graph to be added. If the user did not add or select a sub-set, entire file, or branch to merge, the system may take no further action. However, if the user did add or select a sub-set, the system performs the merge with the accepted difference chunk (Column 8, lines 34-55). Different versions or difference chunks may have errors, for example, conflicts, syntax errors, or the like, or a version may not be relevant to a user. These violations can be filtered out either using pre-analysis filtering or post-analysis filtering (column 8, lines 55 – column 9, lines 1-14).
As per claim 9, Rajput et al. further teaches, “The method according to claim 1, further comprising:
receiving a pick policy configured by the user, wherein the pick policy comprises a fast pick policy, a non-conflict priority policy, or a user priority policy.”
A user may choose to filter difference chunks. Different versions or difference chunks may have errors, for example, conflicts, syntax errors, or the like, or a version may not be relevant to a user. These violations can be filtered out either using pre-analysis filtering or post-analysis filtering (pick policy) (column 8, lines 55 – column 9, lines 1-14).
As per claim 10, Rajput et al. further teaches, “The method according to claim 1, wherein the target branch comprises a master branch or a develop branch.”
The system may choose one of the branches as the target branch, for example, the original or main software code, or the user may indicate the target branch. The difference list may then be generated from the perspective of the target branch (Column 7, lines 4-12).
As per claims 11-16 and 19-20, the contain similar limitations to claims 1-6 and 9-10. Therefore, they are rejected for similar reason.
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.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Rajput et al. (US 10,146,530 B1) as applied to claims 1 and 11 above, and further in view of Antao (US 11,232,097 B1)
As per claim 7, Rajput et al. further teaches, “The method according to claim 1, further comprising:
moving a conflicting commit code to an end of a commit code sequence when the user picks the conflicting commit code using the commit code sequence.”
Rajput et al. teaches, once the relationship graph has been created, the user may select difference chunks to be added to the merge. Selecting the difference chunks may include a user actually selecting the node on the graph to be added. If the user did not add or select a sub-set, entire file, or branch to merge, the system may take no further action. However, if the user did add or select a sub-set, the system performs the merge with the accepted difference chunk (Column 8, lines 34-55). Different versions or difference chunks may have errors, for example, conflicts, syntax errors, or the like, or a version may not be relevant to a user. These violations can be filtered out either using pre-analysis filtering or post-analysis filtering (column 8, lines 55 – column 9, lines 1-14).
However, Rajput et al. does not explicitly appear to teach, “moving a conflicting commit code to an end of a commit code sequence when the user picks the conflicting commit code using the commit code sequence.”
Antao teaches, a conflict may arise during the merge process, even when applying the commits based on a time ordered sequence. The commit merge application may identify these conflicts and resolve them at a later commit (column 5, lines 60-67).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Rajput et al. with Antao because both teach the merging of code branches and determining conflicts. Rajput et al. teaches a user can select difference chunks (commits) to be merged to the target branch. Antao teaches multiple commits (difference chunks) can be applied in a time order and if a conflict is identifier, it will be resolve at a later commit. Therefore, the later commit would now be at the end of the time ordered sequence. This would allow Rajput to solve the selected difference chunk (commit) at a later time and have it merged then when the conflict is solved and therefore would have been obvious to try.
As per claim 17, the contain similar limitations to claim 7. Therefore, they are rejected for similar reason.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Rajput et al. (US 10,146,530 B1) as applied to claims 1 and 11 above, and further in view of Moore et al. (US 2015/0025925 A1).
As per claims 8, Rajput et al. further teaches, “The method according to claim 1, further comprising:
prompting the user to skip a conflicting commit code or move the conflicting commit code to an end of a commit code sequence when the user picks the conflicting commit code.
Once the relationship graph has been created, the user may select difference chunks to be added to the merge. Selecting the difference chunks may include a user actually selecting the node on the graph to be added. If the user did not add or select a sub-set, entire file, or branch to merge, the system may take no further action. However, if the user did add or select a sub-set, the system performs the merge with the accepted difference chunk (Column 8, lines 34-55). Different versions or difference chunks may have errors, for example, conflicts, syntax errors, or the like, or a version may not be relevant to a user. These violations can be filtered out either using pre-analysis filtering or post-analysis filtering (column 8, lines 55 – column 9, lines 1-14).
However, Rajput et al. does not explicitly appear to teach, “prompting the user to skip a conflicting commit code.”
Moore et al. teaches when a conflict is indicated, it is presented to the user, who may now provide additional alterations, delete the alteration or ignore the conflict (0188). The examiner states that deleting the alteration is the same as skipping the conflicting commit because both remove the conflict from the merge.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Rajput et al. with Moore et al. because both teach merging branches and the identification of conflicts. Rajput et al. teaches filtering out conflicts but does not teach prompting to a user the conflict. Moore et al. teaches presenting a conflict to a user and allowing the user to delete/skip the alteration that caused the conflict. Deleting a conflict or filtering out a conflict are similar since both are removing the conflict from the merge producing similar results and therefore would have been obvious to try.
As per claim 18, the contain similar limitations to claim 8. Therefore, they are rejected for similar reason.
Response to Arguments
Applicant's arguments filed 5/30/2026 have been fully considered but they are not persuasive.
Rejection under 35 U.S.C 101
Applicant argues:
“Applicant disagrees with the assertion that the claims are directed to an abstract idea.
The computing device determine and displays the first commit code and the at least second commit code to a user.
The computing device displays the first commit code and the at least a second commit code, and performs code merging on the first commit code, some or all of second commit code, and a commit code in the target branch.
As a result, the computing device performs code merging on the software development project.”
The examiner disagrees. Applicants’ argument seems to be nothing more than a general allegation. As stated in the above rejection, claim 1 recites an abstract idea. The steps of “determining, by the computing device, a source branch and a target branch…” and “performing code merging on the first commit code….”, are steps that a human can carry out in the mind with the aid of pen and paper or general purpose computing apparatus. Nothing in the claimed limitation prevents these steps form being performed in the mind. See MPEP 2106.04(a)(2) III Mental Process.
Applicant argues:
“Claims 1-20 disclose significantly more than an abstract idea and more than a judicial exception.
Independent claims 1 and 11 disclose determining, by the computing device, a source branch and a target branch of a software development project, the source branch comprising a plurality of commit codes.
The patent application as originally filed discloses that the source branch (of the software) includes a plurality of commit codes (see paragraph [0055]). A commit code may be generated by performing a commit operation on a local repository, a remote repository, or on a cloud development platform. The plurality of commit codes include a first commit code and a second commit code. The first commit code and the second commit code (where the second commit code is associated with the first commit code) are presented to the user.
A commit code describes a difference between a code file before a change and a code file after the change (see paragraph [0064]).
It should be understood that a user will be able to see the commit codes (see paragraphs [0063]-[0064]). As a result, a user can comprehend the merge process and can control the merge process (see paragraph [0069]-[00]72).
Code merging is performed on the first commit code, some or all of the second commit codes, and a commit code in the target branch.
Therefore, the computing device and the process performed by the computing device provide subject matter eligibility in the independent claims. Applicant respectfully requests that the rejection under 1-20 be removed and claims 1-20 be allowed.”
The examiner respectfully disagrees. In the above argument, the applicant just lists elements of the claim but does not state how they are significantly more. Applicant then sites parts of the specification adding information that is not claimed. For instance, applicant states that a user will be able to see the commit code and comprehend the merge process and control the merge process. First the examiner states, nothing in the claimed limitations state that the user is controlling the merge process and the displaying of the code commits are identified as a well-understood, routine, conventional activity (2106.05(d)). The commits are just generically displayed, there is no improvement to the display and the display is not used in any way. For the reasons above the current rejection stands.
Rejection under 35 U.S.C 102
Applicant argues:
“The Office Action asserts that Rajput discloses determining a source branch and a target branch of a software development project, wherein the source branch comprises a plurality of commit codes, and the plurality of commit codes comprise a first commit code and a second commit code (citing col. 6, lines 8-24; col. 7, lines 4-12; col. 5, lines 13-25; and col. 5, lines 26-35).
Applicant respectfully disagrees. Rajput does not disclose commit codes.
The cited text of Rajput at col. 6, lines 8-24, discloses determining a source branch and a target branch that are to be merged. Each code branch may contain different changes from the other code branches. The cited text of Rajput at col. 7, lines 4- 12, discloses that the system or a user may choose source and target branches. The cited text of Rajput at col. 5, lines 13-25, discloses simulating and evaluating branch code merges before performing an actual merge. The cited text of Rajput at col. 5, lines 26-35, discloses simulating a merge may include identifying the differences between the selected code branches.”
The examiner disagrees. As claimed “a source branch and a target branch of a software development project, the source branch comprising a plurality of commit code, the plurality of commit code comprising a first commit and at least one second commit code associated with the first commit code;”. The examiner interprets a branch to be a version of a program that is changed from another version. As claimed the source branch contains a first commit and a second commit, however the claim never states the actual step of commiting code. The examiner interprets a commit to be a code change. Rajput et al. teaches the branches may be different versions, where a version includes changes (commit codes) different from another branch or the original software code (column 5, lines 13-25). The system may generate a difference list that includes a listing of added code snippets, deleted code snippets, and changed code snippets (plurality of commit codes). Therefore, a branch in Rajput can have many changes and therefore a plurality of commits and meets the current claimed limitations.
Applicant argues:
“The cited text of Rajput at col. 6, lines 8-24, discloses determining a source branch and a target branch that are to be merged. Each code branch may contain different changes from the other code branches. The cited text of Rajput at col. 7, lines 4- 12, discloses that the system or a user may choose source and target branches. The cited text of Rajput at col. 5, lines 13-25, discloses simulating and evaluating branch code merges before performing an actual merge. The cited text of Rajput at col. 5, lines 26-35, discloses simulating a merge may include identifying the differences between the selected code branches.
The Office Action asserts that Rajput discloses presenting the first commit code and the second commit code associated with the first commit code to a user (citing col. 5, lines 32-54; col. 5, line 61 to col. 6, line 3; col. 6, line 53 to col. 7, line 2; col. 7, lines 4- 12; col. 7, lines 41-45; and col. 8, lines 34-55).
Applicant respectfully disagrees. Rajput does not disclose commit codes. Rajput does not disclose displaying to a user the first commit code and the second commit code associated with the first commit code.
The text of Rajput at col. 5, lines 32-54, discloses determining a source branch and a target branch that are to be merged. Each code branch may contain different changes from the other code branches. The cited text further discloses building a relationship graph that represents relationships between difference chunks. Each code segment may be represented by a node within the relationship graph and the graph can be used to identify relationships between different sub-sets of the two or more code branches. A user can select nodes on the relationship graph that are to be added to the merge. The text of Rajput at col. 5, line 61, to col. 6, line 3, discloses tracking code dependencies and similarities, which allows the identification of potential errors. Further, the user can select sub-sets of the branches to merge, and not necessarily select an entire branch. The text of Rajput at col. 6, line 53 to col. 7, line 2, discloses identifying the differences between the two or more branches selected for merging by comparing each branch to the other branches and designating the differences. The system may generate a difference list including all of the identified differences. The cited text of Rajput at col. 7, lines 4-12, discloses that the system or a user may choose source and target branches. The text of Rajput at col. 7, lines 41-45, discloses cost vectors for the edges in the relationship graph. The text of Rajput at col. 8, lines 34-55, discloses the user can select difference chunks from the relationship graph to be added to the merge.”
Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
As stated above Rajput et al. does teach commit codes (code changes).
For the reasons above the current rejection stands.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6:00pm.
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, Lewis Bullock can be reached at 571-272-3759. 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.
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
MARK A. GOORAY
Examiner
Art Unit 2199
Prosecution Insights