DETAILED ACTION
This action is responsive to the amendment and remarks filed on September 23, 2026 in reply to the Non-Final Office Action dated June 23, 2026, and to the Applicant-Initiated Interview conducted on August 19, 2026.
Claims 1, 2, 4-9, 11 and 13-19 have been amended. Claim 20 has been canceled. Claim 21 has been added. Claims 1-19 and 21 are pending and presented for examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Amendment
In view of the amendments to claims 1, 4-9 and 13-19, the objections to those claims are withdrawn, with the exception noted below with respect to claim 1. The objection to claim 10, which was objected to solely as depending from claim 9, is withdrawn. The objection to claim 20 is moot in view of the cancellation of that claim.
Upon reconsideration, the objection to claim 1 requiring that a corresponding segment be changed to "the corresponding segment" is withdrawn. Claim 1 recites, for each portion, a corresponding segment, which properly introduces the segment corresponding to that portion.
The objection to claim 11 is not overcome. The previous Office action required that "the plurality of portions" be changed to "the plurality of segments." Claim 11, as amended, continues to recite wherein the splitting the computer code within the computer code repository into the plurality of portions comprises. That limitation is now the subject of the rejection under 35 U.S.C. 112(b) set forth below, and the objection is withdrawn in favor of that rejection.
New objections to claims 2-12 and 21 are set forth below. The objection to claim 2 arises from the amendment of that claim.
The rejection of claims 1-20 under 35 U.S.C. 101 is maintained as to claims 1-19 and is applied to new claim 21, for the reasons set forth in the Claim Rejections - 35 USC § 101 section below and in the Response to Arguments below.
Response to Arguments
Applicant’s arguments filed on 09/23/2026 with respect to the rejection of the claims under 35 U.S.C. 101 have been fully considered but they are not persuasive.
Step 2A, Prong 1. Applicant argues that the claims are directed to specific technological solutions for training and executing machine learning models and that the operations are impractical to perform in the human mind because generating segment data based on repository-wide code update parameters involves scanning code segments across an entire computer code repository (Remarks, page 13). The argument is not commensurate with the scope of the claims. None of claims 1, 2 or 13 recites scanning an entire computer code repository. Claim 2 recites identifying, within the computer code repository, a segment of a plurality of segments corresponding to the updated computer code, i.e., locating the one segment that the updated code changes, and generating, based on the updated computer code, segment data, wherein the segment data comprises one or more code update parameters, which the specification describes as counting variables, commits and lines of code (specification, paragraphs [0031]-[0034]). A developer can compare a changed function with the functions listed in a code base, find the one being changed, and count the variables, prior commits and changed lines with pen and paper. That the steps may be carried out on a large body of code, or faster, by a computer does not remove them from the mental process grouping. See MPEP 2106.04(a)(2), III.C, and MPEP 2106.05(f)(2).
Applicant further argues that deploying computer code to be executed by processors is inherently a computer-implemented operation that cannot be performed in the human mind (Remarks, pages 13-14). The deploying step appears only in claim 21 and is not relied upon as part of the abstract idea. It is treated as an additional element under Step 2A, Prong 2 and Step 2B. The phrase prior to deploying the updated computer code in claims 2 and 13 does not require that any deploying be performed. It specifies only when the action identifiers are generated for display.
Step 2A, Prong 2. Applicant argues that the claims integrate any abstract idea into a practical application because they recite an ordered combination that identifies potential code update defects before deployment, and relies on paragraphs [0001] and [0036] of the specification (Remarks, page 14). The argument is not persuasive. Paragraphs [0001] and [0036] describe the result sought, namely a prediction that other functions, code segments, procedures or APIs may be broken if the updated code is deployed. They do not describe any improvement in the functioning of a computer or of the machine learning model itself. The claims recite a machine learning model only generically, as a tool that receives the segment data and returns a condition, and the specification confirms that the model may be any of a neural network, a factorization machine model, a Bayesian model or a self-supervised learning model (paragraphs [0044]-[0046] and [0049]). Applying a generic machine learning model to a new data environment, here code update history, is mere instruction to apply the exception on a computer. See MPEP 2106.05(f); Recentive Analytics, Inc. v. Fox Corp., No. 2023-2437 (Fed. Cir. Apr. 18, 2025). The additional limitation prior to deploying the updated computer code merely sets the temporal context in which the result of the mental process is displayed and generally links the exception to the field of software deployment. See MPEP 2106.05(h). Generating the action identifiers for display is insignificant post-solution activity. See MPEP 2106.05(g).
New claim 21 recites deploying the updated computer code to be executed by one or more computer processors. The deploying is not conditioned on, and does not otherwise depend on, the condition received from the machine learning model. The updated code is deployed regardless of the prediction, so the judicial exception has no effect on the deployment. The deploying step is therefore nominal post-solution activity and does not integrate the judicial exception into a practical application. See MPEP 2106.05(g).
For these reasons, and for the reasons set forth in the Claim Rejections - 35 USC § 101 section below, the rejection under 35 U.S.C. 101 is maintained.
Applicant’s statement regarding the substance of the interview of August 19, 2026 is noted. As recorded in the Interview Summary mailed August 21, 2026, the examiner stated that claim 2 remained rejected under 35 U.S.C. 101, and no agreement was reached as to eligibility or allowability.
Applicant’s remarks regarding the new claim (Remarks, page 15) have been considered. New claim 21 is rejected as set forth below.
Drawings
The drawings filed on July 10, 2024 are objected to because of the informalities set forth below.
FIG. 3 is objected to because the entry in the second row of the column designated “Commit Parameters” (field 309) reads “<Paramters>”. The same entry in the columns for fields 306 and 312 reads “<Parameters>”. The word "Paramters" is misspelled and should read "Parameters."
FIG. 5 is objected to under 37 CFR 1.84(l), which requires that every line, number, and letter be durable, clean, black, sufficiently dense and dark, and uniformly thick and well-defined. The outlines of interface 500, area 503, button 506, area 509 and the unnumbered “Output” element, and the lettering within them, are reproduced as broken, stippled lines of non-uniform thickness with ragged edges, and the lettering is pixelated. The figure does not have satisfactory reproduction characteristics.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to this Office action. Any amended replacement drawing sheet must include all figures appearing on the immediate prior version of the sheet, even if only one figure is amended, and must be labeled "Replacement Sheet" in the page header. Failure to take corrective action will result in ABANDONMENT of the application.
Examiner notes that FIGS. 1, 2, 4, 6 and 7 have been reviewed. Each reference character appearing in the drawings is described in the specification, and each reference character recited in the specification appears in the drawings. The broken-line arrow of FIG. 4 depicts the feedback of output 406 to machine learning model 402 described at paragraph [0043] and is not objected to.
Specification
The disclosure is objected to because of the following informalities:
Paragraph [0001] recites “it is possible that he updates may cause failures or other issues”. "he updates" should read "the updates."
Paragraph [0008] recites “the computer code data may include previous computer code updates”. The term introduced in the preceding sentence is “computer code update data”. "the computer code data" should read "the computer code update data."
Paragraph [0030] recites “Machine learning subsystem 114 may then determine, based on output from the machine learning model, that a first code segment of the plurality of segments matches the updated computer code”. The output described in the paragraph is the output of the similarity model. "the machine learning model" should read "the similarity model," consistent with amended claims 5 and 16.
Paragraph [0031] recites “Variable updated parameters may indicate a number and type of variable changes”. The term used throughout the disclosure is "variable update parameters." "Variable updated parameters" should read "Variable update parameters."
Paragraph [0037] recites “Training subsystem 116 may include software components, hardware components, or a combination of both. For example, machine learning subsystem 114 may include software components (e.g., API calls) that train one or more machine learning models.” The example is given for training subsystem 116. "machine learning subsystem 114" in the second sentence should read "training subsystem 116."
Enumerated embodiment 6 of paragraph [0064] recites “Any of the proceeding embodiments”. "proceeding" should read "preceding."
Appropriate correction is required.
Claim Objections
Claims 2-12 and 21 are objected to because of the informalities set forth below.
Claim 2 recites A method for determining whether updated computer code causes issues comprising:. A comma should be inserted after "issues."
Claim 2, as amended, recites that have been updated during a predetermined time period; and at the end of the identifying step, followed by three further steps. The conjunction "and" should be deleted from the end of the identifying step and appear only before the final step of the claim.
Claim 9 recites comparing, for each computer code segment within the computer code update data, header data with stored heading data and based on the header data matching the stored heading data. The claim uses two different terms, "header data" and "heading data," for the same kind of information, and the specification uses only the term "heading data" (paragraph [0039]). The claim terms should be consistent with each other and with the specification. See 37 CFR 1.75(d)(1). "header data" should read "heading data."
Claims 3-12 and 21 are objected to as depending, directly or indirectly, from claim 2. Claim 10 is further objected to as depending from claim 9.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 8-11 and 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 8 recites wherein the training the machine learning model using the time series data comprises. Claim 2, from which claim 8 depends, recites no step of training. It recites only that the machine learning model has been trained using time series data. There is insufficient antecedent basis for the training in the claim. For purposes of examination, the limitation is interpreted as "wherein the machine learning model has been trained using the time series data by."
Claim 8 further recites splitting the computer code within the computer code repository into the plurality of portions. Claim 2 recites both a plurality of computer code portions that have been updated during a predetermined time period and a plurality of portions of the computer code. It cannot be determined to which of the two pluralities the plurality of portions refers. Moreover, claim 2 recites that the computer code has been split into the plurality of segments, whereas claim 8 recites splitting the computer code into portions, so it is unclear whether the portions of claim 8 are the segments of claim 2 or a different division of the code. For purposes of examination, the plurality of portions in claim 8 is interpreted as a plurality of portions of the computer code to which the code updates used to train the machine learning model were made.
Claim 8 further recites based on the corresponding segment. The claim previously recites only a given segment of the plurality of computer code segments, and neither claim 8 nor claim 2 recites a corresponding segment. There is insufficient antecedent basis for this limitation. For purposes of examination, the corresponding segment is interpreted as the given segment to which the respective portion corresponds.
Claims 9 and 10 are rejected as depending from claim 8 and failing to cure its indefiniteness. Claim 9 depends from claim 8, and claim 10 depends from claim 9.
Claim 11 recites wherein the splitting the computer code within the computer code repository into the plurality of portions comprises. Claim 2, from which claim 11 depends, recites no step of splitting. It recites only that the computer code has been split into the plurality of segments. There is insufficient antecedent basis for the splitting in the claim. Further, for the reasons set forth above with respect to claim 8, it cannot be determined whether the plurality of portions refers to a plurality of computer code portions that have been updated during a predetermined time period, to a plurality of portions of the computer code, or to the plurality of segments into which claim 2 recites the code has been split. For purposes of examination, the limitation is interpreted as "wherein the computer code within the computer code repository has been split into the plurality of segments by."
Claim 19 recites wherein the instructions for splitting the computer code within the computer code repository into the plurality of segments further cause the one or more processors to perform operations comprising. Claim 13, from which claim 19 depends, recites no instructions or operation for splitting. It recites only that the computer code has been split into the plurality of segments. There is insufficient antecedent basis for the instructions for splitting in the claim. For purposes of examination, the limitation is interpreted as "wherein the computer code within the computer code repository has been split into the plurality of segments by operations comprising." The claims are examined on the merits below as best understood in view of the indefiniteness set forth above. See MPEP 2173.06(II).
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-19 and 21 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into a practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claim 1 is directed to a system comprising one or more processors and a non-transitory computer-readable storage medium and falls within the statutory category of machines. Claims 2-12 and 21 are directed to a method and fall within the statutory category of processes. Claims 13-19 are directed to one or more non-transitory computer-readable storage media and fall within the statutory category of manufactures. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry, the claim limitations are set forth below and each is evaluated against the enumerated groupings of abstract ideas.
Step 2A Prong 1: Claim 2 (and similarly claim 13) recites the following limitations:
a) “identifying, within the computer code repository, a segment of a plurality of segments corresponding to the updated computer code, wherein the computer code within the computer code repository has been split into the plurality of segments based on a plurality of computer code portions that have been updated during a predetermined time period” – Mental Process, See MPEP 2106.04(a)(2), III. For example, a person may read a proposed change to a function, look through a list of the functions of a code base that have been changed during a given period, and pick out the function that the proposed change modifies. This limitation, under its broadest reasonable interpretation, covers an act of observation and evaluation that could reasonably be performed in the mind, including with the aid of pen and paper.
b) “generating, based on the updated computer code, segment data, wherein the segment data comprises one or more code update parameters” – Mental Process, See MPEP 2106.04(a)(2), III. For example, a person may compare the proposed change with the existing function and write down how many variables differ, how many times the function has previously been changed and how many lines differ. This limitation could reasonably be performed in the mind, including with the aid of pen and paper.
c) “to obtain a condition associated with the updated computer code” – Mental Process, See MPEP 2106.04(a)(2), III. For example, a person may review the recorded counts and judge whether the proposed change is likely to break other code. The condition, which claim 12 and the specification at paragraph [0036] describe as a determination of whether the updated code is predicted to cause issues, is an evaluation and judgment that could reasonably be performed in the mind, including with the aid of pen and paper.
d) “based on the condition received from the machine learning model, generating for display one or more action identifiers for a user to perform” – Mental Process, See MPEP 2106.04(a)(2), III. For example, having judged that a proposed change will cause a problem, a person may decide what the developer should do about it, such as removing an unsupported variable (specification, paragraph [0006]), and write that action down. Selecting an action based on a judgment is an evaluation that could reasonably be performed in the mind, including with the aid of pen and paper.
Claim 1 recites the following limitations:
e) “split computer code within the computer code repository into a plurality of portions based on the plurality of computer code segments within the computer code update data, wherein each portion of the plurality of portions corresponds to a segment of the plurality of computer code segments” – Mental Process, See MPEP 2106.04(a)(2), III. For example, a person may review a history of past changes and mark off in a code listing each function to which a past change was made. This limitation could reasonably be performed in the mind, including with the aid of pen and paper.
f) “determine, for each portion of the plurality of portions based on a corresponding segment, corresponding segment data, wherein each segment data comprises one or more code update parameters, the one or more code update parameters comprising variable update parameters, commit parameters, or lines of code parameters” – Mental Process, See MPEP 2106.04(a)(2), III. For example, a person may count, for each marked function, the variables changed, the number of commits made to it and the number of lines changed, and write those counts down. This limitation could reasonably be performed in the mind, including with the aid of pen and paper.
g) “generate, for the plurality of portions, a time series dataset comprising combined segment data arranged chronologically” – Mental Process, See MPEP 2106.04(a)(2), III. For example, a person may copy the recorded counts for all of the functions into a single table ordered by the date of each change. This limitation could reasonably be performed in the mind, including with the aid of pen and paper.
Therefore, Yes, claims 1, 2 and 13 recite a judicial exception.
Step 2A Prong 2: This judicial exception is not integrated into a practical application. In addition to the limitations identified above, the claims recite the following additional elements:
Additional element 1 – “one or more processors” and “a non-transitory computer-readable storage medium storing instructions, which when executed by the one or more processors, cause the one or more processors to” (claim 1), “One or more non-transitory computer-readable storage media storing instructions that, when executed by one or more processors, cause operations comprising” (claim 13), and “a computer code repository” (claims 1, 2 and 13). These are generic computer components recited at a high level of generality and amount to no more than instructions to apply the exception using a computer. See MPEP 2106.05(f).
Additional element 2 – “receive computer code update data, wherein the computer code update data comprises a plurality of computer code segments that were used as updates to a computer code repository over a period of time” (claim 1) and “receiving the updated computer code, wherein the updated computer code comprises a computer code update to computer code within a computer code repository” (claims 2 and 13). Receiving the data on which the abstract idea operates is mere data gathering, which is insignificant extra-solution activity. See MPEP 2106.05(g).
Additional element 3 – “inputting, into a machine learning model, the segment data” and “wherein the machine learning model has been trained using time series data generated based on code updates to a plurality of portions of the computer code” (claims 2 and 13). The machine learning model is recited generically, without any particular architecture, training procedure or structure, and is invoked merely as a tool by which the evaluation is carried out. See MPEP 2106.05(f).
Additional element 4 – “train a machine learning model using the time series dataset and the plurality of portions of code to output a condition associated with a candidate code portion when the candidate code portion is input into the machine learning model” (claim 1). The training is recited at a high level of generality, specifying only the data used and the output desired, and amounts to no more than instructions to apply the exception using a generic machine learning model. See MPEP 2106.05(f).
Additional element 5 – “for display” and “prior to deploying the updated computer code” (claims 2 and 13). Displaying the result of the evaluation is insignificant post-solution activity. See MPEP 2106.05(g). Specifying that the result is displayed before the updated code is deployed does not require any deploying to be performed and only generally links the use of the judicial exception to the field of software deployment. See MPEP 2106.05(h).
Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea, thus failing to integrate the abstract idea into a practical application.
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application?” No, the claims do not recite additional elements that integrate the judicial exception into a practical application.
After having evaluated the inquiries set forth in Steps 2A Prong 1 and 2, the claims are directed to an abstract idea.
Step 2B: The claims do not recite additional elements that amount to significantly more than the judicial exception. The additional elements identified above, considered individually and as an ordered combination, are generic processors, a generic storage medium, a generic code repository, the receipt of data, a generically recited and generically trained machine learning model, and the display of a result. Performing repetitive calculations, receiving or transmitting data over a network, and storing and retrieving information in memory are well-understood, routine, and conventional activity previously known to the industry, see MPEP 2106.05(d)(II). The specification itself confirms as much: paragraph [0021] states that code analysis system 102 may be a physical server, a virtual server or a user device such as a laptop computer, smartphone or desktop computer; paragraphs [0044]-[0046] state that the machine learning model may be an artificial neural network, a factorization machine model or a Bayesian model; and paragraph [0051] states that a processor may be any suitable processor capable of executing instructions.
Accordingly, the additional elements recited in the claims cannot provide an inventive concept. The claimed invention doesn’t improve any function of a computer or to any other technology or technical field. Thus, the claims are not patent eligible.
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception?” No, the claims do not recite additional elements that amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, claims 1, 2 and 13 do not recite patent eligible subject matter under 35 U.S.C. 101.
Claim 3 (and similar for claim 14) adds the limitation that “the one or more code update parameters comprise variable update parameters, commit parameters, or lines of code parameters” – Mental Process, See MPEP 2106.04(a)(2), III. The limitation only specifies which counts are observed and recorded, which could reasonably be performed in the mind, including with the aid of pen and paper.
Claim 4 (and similar for claim 15) adds the limitation of “comparing execution commands for each code segment of the plurality of segments with corresponding execution commands for the updated computer code” and “determining, based on the comparing, that a first code segment of the plurality of segments matches the updated computer code” – Mental Process, See MPEP 2106.04(a)(2), III. Reading the commands of two pieces of code side by side and concluding that they match is an act of observation and evaluation that could reasonably be performed in the mind, including with the aid of pen and paper.
Claim 5 (and similar for claim 16) adds the limitation of “inputting each code segment of the plurality of segments and the updated computer code into a similarity model, wherein the similarity model determines a degree of similarity between two sets of textual data” and “determining, based on output from the similarity model, that a first code segment of the plurality of segments matches the updated computer code.” The similarity model is recited generically and is invoked merely as a tool to perform the comparison, which amounts to no more than instructions to apply the exception. See MPEP 2106.05(f). Determining that a segment matches based on the degree of similarity is a Mental Process, See MPEP 2106.04(a)(2), III, that could reasonably be performed in the mind, including with the aid of pen and paper.
Claim 6 (and similar for claim 17) adds the limitation of determining a first number and a second number of variables, “generating a variable difference for the updated computer code”, “determining a number of code updates associated with the updated computer code”, “generating a commit parameter based on the number of code updates”, determining first and second sets of line code parameters, “generating a line code parameter difference for the updated computer code” and “adding the variable difference, the commit parameter, and the line code parameter difference to the segment data” – Mental Process, See MPEP 2106.04(a)(2), III. Counting variables, prior changes and lines in two pieces of code, subtracting the counts and writing the results down could reasonably be performed in the mind, including with the aid of pen and paper.
Claim 7 (and similar for claim 18) adds the limitation of “comparing the condition with a plurality of predetermined conditions” – Mental Process, See MPEP 2106.04(a)(2), III, which could reasonably be performed in the mind, including with the aid of pen and paper; “retrieving a plurality of functions associated with the plurality of predetermined conditions”, which is mere data gathering and insignificant extra-solution activity, See MPEP 2106.05(g); and “generating for display a plurality of selectable function identifiers”, which is insignificant post-solution activity, See MPEP 2106.05(g).
Claim 8 adds the limitation of “receiving computer code update data, wherein the computer code update data comprises a plurality of computer code segments that were used as updates to the computer code over a period of time”, which is mere data gathering and insignificant extra-solution activity, See MPEP 2106.05(g); and of splitting the computer code into the plurality of portions, determining corresponding segment data for each portion and “generating, for the plurality of portions, a time series dataset comprising combined segment data arranged chronologically” – Mental Process, See MPEP 2106.04(a)(2), III, for the reasons given above with respect to items e) through g) of claim 1.
Claim 9 adds the limitation of “comparing, for each computer code segment within the computer code update data, header data with stored heading data associated with the computer code within the computer code repository” and “matching a first code segment with a first portion of the computer code within the computer code repository based on the header data matching the stored heading data” – Mental Process, See MPEP 2106.04(a)(2), III. Comparing the name and variables of a changed function with the names and variables of the functions in a code listing and pairing those that match could reasonably be performed in the mind, including with the aid of pen and paper.
Claim 10 adds the limitation of “generating a code map for the computer code repository with the first portion of the computer code having an entry within the code map” – Mental Process, See MPEP 2106.04(a)(2), III. Writing a table that lists each matched function and where it is located could reasonably be performed with the aid of pen and paper.
Claim 11 (and similar for claim 19) adds the limitation of “identifying, for each segment of a plurality of computer code segments, a corresponding portion within the computer code repository”, “for each pair of a matching segment and the corresponding portion, generating an entry identifying each pair” and “discarding one or more portions of the computer code within the computer code repository without a corresponding pair” – Mental Process, See MPEP 2106.04(a)(2), III. Pairing past changes with the functions they changed, listing the pairs and striking from the list the functions that were never changed could reasonably be performed in the mind, including with the aid of pen and paper.
Claim 12 adds the limitation that “the condition comprises a determination of whether the updated computer code is predicted to cause one or more issues within the computer code repository” – Mental Process, See MPEP 2106.04(a)(2), III. Predicting whether a change will cause problems is a judgment that could reasonably be performed in the mind, including with the aid of pen and paper.
Claim 21 adds the limitation of “deploying the updated computer code to be executed by one or more computer processors.” The deploying is not conditioned on the condition received from the machine learning model and is performed regardless of the result of the abstract idea. It is insignificant post-solution activity, See MPEP 2106.05(g), and the recited computer processors are generic computer components that amount to no more than instructions to apply the exception, See MPEP 2106.05(f).
Therefore, Claims 1-19 and 21 do not recite patent eligible subject matter under 35 U.S.C. 101.
Claim Rejections - 35 USC § 102
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.
Claim 1 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Cheng et al. (US Pub. No. 2020/0073784, hereinafter “Cheng”).
With respect to claim 1 (Currently Amended), Cheng teaches A system for building an artificial intelligence model that predicts computer code, the system comprising: (Cheng, ¶[0017], ¶[0022] and ¶[0023], the subject matter disclosed “generates a classification-type machine learning model to predict the likelihood that a file will have a software bug”, training phase 102 “builds a machine learning model 124 for a particular code base”; the machine learning model is an artificial intelligence model built to make predictions about computer code).
one or more processors; (Cheng, ¶[0071] and ¶[0074], “A system is disclosed that contains one or more processors, a memory and one or more modules.”).
a non-transitory computer-readable storage medium storing instructions, which when executed by the one or more processors, cause the one or more processors to: (Cheng, ¶[0072]-[0074], “The memory 710 may be any non-transitory computer-readable storage media that may store executable procedures, applications, and data”, the modules being “configured to be executed by the one or more processors to perform actions”).
receive computer code update data, wherein the computer code update data comprises a plurality of computer code segments that were used as updates to a computer code repository over a period of time; (Cheng, ¶[0025], ¶[0027], ¶[0041] and ¶[0048], data mining engine 110 “searches for pull requests of a particular code base in order to obtain the commit histories 112 of the files identified within each pull request that have had changes made”; each commit “checks in the modified version of the source code file back into the shared source code repository”; the commit history “includes n commits that have been recorded over a particular time period”; the commit histories are the computer code update data, and the committed code changes are the computer code segments used as updates to shared source code repository 106 over a period of time).
split computer code within the computer code repository into a plurality of portions based on the plurality of computer code segments within the computer code update data, wherein each portion of the plurality of portions corresponds to a segment of the plurality of computer code segments; (Cheng, ¶[0023], ¶[0027], ¶[0040] and ¶[0057], “A code base is a collection of source code files”; the code base is divided into the individual source code files “identified within each pull request that have had changes made”, and each such file is processed on its own: “For each file identified, either in a pull request or as the target source code file to analyze (block 302), features are extracted from each commit record in the file’s commit history”; each source code file is a portion of the code in the repository that is selected because of, and corresponds to, the committed changes made to it; the specification describes the split as dividing the code into functions, procedures “or other suitable portions” based on prior updates (specification, ¶[0003] and ¶[0009]), and a source code file is such a portion).
determine, for each portion of the plurality of portions based on a corresponding segment, corresponding segment data, wherein each segment data comprises one or more code update parameters, the one or more code update parameters comprising variable update parameters, commit parameters, or lines of code parameters; (Cheng, ¶[0018] and ¶[0041]-[0046], for each file Cheng determines from each commit a bug density, and “The overall bug density is then computed as the sum of the bug densities for each commit in the commit history for a file”, a commit parameter; Cheng further determines addition and deletion factors that “represent the magnitude of the changes made to fix a software bug by the number of lines of code added and/or deleted”, lines of code parameters; each commit “may list the modified files, the number of files that were changed, and how many lines were added and/or deleted”). The claim recites the code update parameters in the alternative and the prior art need teach only one alternative.
generate, for the plurality of portions, a time series dataset comprising combined segment data arranged chronologically; (Cheng, ¶[0047]-[0054] and ¶[0059], FIG. 4, the per-commit values for each file are “weighted based on when the corresponding changes were made”; “The commits are ordered in increasing chronological order with commit 1 being the oldest and commit n being the latest and most current commit record”; the per-commit values BD1 through BDn, ADD1 through ADDn and DEL1 through DELn are combined into overall time-weighted values (FIG. 4, blocks 408-412), which are assembled into feature vector 900 for each file containing “the time-weighted bug density 904, the time-weighted addition factor 906, the time-weighted deletion factor 908”; the chronologically ordered sequence of per-commit segment data, combined for every file, is a time series dataset of combined segment data arranged chronologically).
train a machine learning model using the time series dataset and the plurality of portions of code to output a condition associated with a candidate code portion when the candidate code portion is input into the machine learning model. (Cheng, ¶[0028], ¶[0055]-[0056], ¶[0059] and ¶[0062]-[0063], “The feature vectors 118 are then used to train and test a model to predict the likelihood or probability that a particular file will have a software bug”; the training vectors also include complexity features “extracted from each source code file in the pull request” by parsing the file itself, so that the model is trained using both the time-weighted dataset and the portions of code; at execution, “The machine learning model generates a risk score for each file represented by a feature vector”; the risk score is the condition, and the target source code file is the candidate code portion input into the machine learning model).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 2-3, 8, 12-14 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Cheng et al. (US Pub. No. 2020/0073784, hereinafter “Cheng”) in view of Negussie et al. (US Pub. No. 2023/0088784, hereinafter “Negussie”).
With respect to claim 2 (Currently Amended), Cheng teaches A method for determining whether updated computer code causes issues comprising: (Cheng, ¶[0004] and ¶[0030], “The execution phase 104 uses the machine learning model 124 on source code changes that have been made to one or more target files in the code base”, and “The risk score represents a probability that a particular source code from the code base is likely to contain a software bug in the future.”).
receiving the updated computer code, wherein the updated computer code comprises a computer code update to computer code within a computer code repository; (Cheng, ¶[0030] and ¶[0062], “The data mining engine 110 extracts changes made to the target files from a shared source code repository 106 by mining pull requests 126 associated with the files.” The changed target file received from the pull request is the updated computer code, and the change is an update to code within repository 106).
identifying, within the computer code repository, a segment of a plurality of segments corresponding to the updated computer code, wherein the computer code within the computer code repository has been split into the plurality of segments based on a plurality of computer code portions that have been updated during a predetermined time period; (Cheng, ¶[0023], ¶[0027], ¶[0030], ¶[0048], ¶[0050] and ¶[0062], “A target code base is selected from which one or more files are chosen for analysis”, and the data mining engine “extracts the commit histories and source code files for each target file included in a pull request”, thereby identifying, within the repository, the file (segment) corresponding to the updated code; the code base is “a collection of source code files” divided into the files “identified within each pull request that have had changes made”, those changes being commits “recorded over a particular time period”, each commit time being “a normalized value between [0,1]” over that period; a period fixed in advance so that commit times can be normalized across it is a predetermined time period).
generating, based on the updated computer code, segment data, wherein the segment data comprises one or more code update parameters; (Cheng, ¶[0061] and ¶[0063], “FIG. 9B illustrates an exemplary feature vector 902 that is input to the machine learning model to compute a risk score for a file.” The feature extraction engine obtains features “to generate feature vectors containing the weighted bug density features, weighted addition features, weighted deletion features”, which are commit and lines of code update parameters).
inputting, into a machine learning model, the segment data to obtain a condition associated with the updated computer code, wherein the machine learning model has been trained using time series data generated based on code updates to a plurality of portions of the computer code; and (Cheng, ¶[0047]-[0048], ¶[0059] and ¶[0063], “The feature vectors are used by the machine learning model to predict the likelihood that each file represented by the feature vectors is likely to have a software bug in the future”; the risk score is the condition; the model was trained on vectors of “the time-weighted bug density 904, the time-weighted addition factor 906, the time-weighted deletion factor 908” derived from commits that “are ordered in increasing chronological order” across the files of the code base, i.e., time series data generated from code updates to a plurality of portions of the computer code).
Cheng is silent to disclose prior to deploying the updated computer code and based on the condition received from the machine learning model, generating for display one or more action identifiers for a user to perform; however, in an analogous art, Negussie teaches:
prior to deploying the updated computer code and based on the condition received from the machine learning model, generating for display one or more action identifiers for a user to perform. (Negussie, ¶[0019], ¶[0029]-[0030] and ¶[0056], the regression prediction platform uses a machine learning model to predict “whether the impending code change is likely to cause code breakage, functionality breakage, and/or support issues prior to deploying the impending code change to a live production environment”; “the one or more machine learning models may output a risk associated with deploying the impending code change”, and “based on the probability or risk of the impending code change causing breakage and/or support issues, the regression prediction platform may trigger or recommend one or more appropriate actions”, for example it “may recommend that the impending code change not be deployed and/or may recommend additional review, testing, and/or approval prior to deployment”; the recommendations are presented through output component 450, which “enables device 400 to provide output, such as via a display”; the recommended actions are action identifiers for a user to perform, generated for display before deployment based on the output of the machine learning model).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Cheng’s risk-score output so that, prior to deploying the changed code and based on the risk score, recommended actions are generated for display to the user, as taught by Negussie, because doing so allows the system to “detect and/or predict potential problems with an impending code change before the problems actually occur in a testing and/or production environment” (Negussie, ¶[0012]). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP 2143(I)(G).
With respect to claim 3 (Original), Cheng teaches wherein the one or more code update parameters comprise variable update parameters, commit parameters, or lines of code parameters. (Cheng, ¶[0018], ¶[0041]-[0046] and ¶[0061], “An addition factor and the deletion factor represent the magnitude of the changes made to fix a software bug by the number of lines of code added and/or deleted”, lines of code parameters, and “The overall bug density is then computed as the sum of the bug densities for each commit in the commit history for a file”, a commit parameter, both of which are carried in input feature vector 902). The claim recites the code update parameters in the alternative and the prior art need teach only one alternative.
With respect to claim 8 (Currently Amended), Cheng teaches wherein the training the machine learning model using the time series data comprises: (Cheng, ¶[0028] and ¶[0035], “Turning to FIG. 2, there is shown an exemplary method 200 for training the machine learning model.” Claim 8 is examined as best understood in view of the rejection under 35 U.S.C. 112(b) set forth above).
receiving computer code update data, wherein the computer code update data comprises a plurality of computer code segments that were used as updates to the computer code over a period of time; (Cheng, ¶[0025], ¶[0027] and ¶[0048], data mining engine 110 “searches for pull requests of a particular code base in order to obtain the commit histories 112 of the files identified within each pull request that have had changes made”; each commit “checks in the modified version of the source code file back into the shared source code repository”; the commit history “includes n commits that have been recorded over a particular time period”).
splitting the computer code within the computer code repository into the plurality of portions based on the plurality of computer code segments within the computer code update data, wherein each portion of the plurality of portions corresponds to a given segment of the plurality of computer code segments; (Cheng, ¶[0023], ¶[0027] and ¶[0040], “A code base is a collection of source code files”; the code base is divided into the source code files “identified within each pull request that have had changes made”, and “For each file identified, either in a pull request or as the target source code file to analyze (block 302), features are extracted from each commit record in the file’s commit history”; each file is a portion corresponding to the committed changes made to it).
determining, for each portion of the plurality of portions based on the corresponding segment, corresponding segment data, wherein each segment data comprises the one or more code update parameters, the one or more code update parameters comprising variable update parameters, commit parameters, or lines of code parameters; (Cheng, ¶[0041]-[0046], for each file Cheng computes a per-commit bug density, and “The overall bug density is then computed as the sum of the bug densities for each commit in the commit history for a file”, a commit parameter, and computes addition and deletion factors from “how many lines were added and/or deleted” in each commit, lines of code parameters). The claim recites the code update parameters in the alternative and the prior art need teach only one alternative.
generating, for the plurality of portions, a time series dataset comprising combined segment data arranged chronologically. (Cheng, ¶[0047]-[0054] and ¶[0059], FIG. 4, “The commits are ordered in increasing chronological order with commit 1 being the oldest and commit n being the latest and most current commit record”; the per-commit values are combined into overall values “weighted based on when the corresponding changes were made” and assembled into feature vector 900 for each file).
With respect to claim 12 (Original), Cheng teaches wherein the condition comprises a determination of whether the updated computer code is predicted to cause one or more issues within the computer code repository. (Cheng, ¶[0004], ¶[0024] and ¶[0063], “The risk score represents a probability that a particular source code from the code base is likely to contain a software bug in the future.” The code base resides in shared source code repository 106, which “stores large amounts of artifacts, such as source code files and the code base”).
With respect to claim 13 (Currently Amended), claim 13 recites limitations similar to claim 2 and is rejected for the same reasons set forth for claim 2 (Cheng, ¶[0004], ¶[0023]-[0030], ¶[0047]-[0063]; Negussie, ¶[0012], ¶[0019], ¶[0029]-[0030], ¶[0056]). Claim 13 differs only in reciting One or more non-transitory computer-readable storage media storing instructions that, when executed by one or more processors, cause operations comprising:, which Cheng teaches (Cheng, ¶[0072]-[0074], “The memory 710 may be any non-transitory computer-readable storage media that may store executable procedures, applications, and data”, with modules “configured to be executed by the one or more processors to perform actions”).
With respect to claim 14 (Currently Amended), claim 14 recites limitations similar to claim 3 and is rejected for the same reasons set forth for claim 3 (Cheng, ¶[0018], ¶[0041]-[0046], ¶[0061]).
With respect to claim 21 (New), Cheng is silent to disclose deploying the updated computer code to be executed by one or more computer processors; however, in an analogous art, Negussie teaches:
deploying the updated computer code to be executed by one or more computer processors. (Negussie, ¶[0014], ¶[0044], ¶[0054] and ¶[0057], the impending code change is one “scheduled or otherwise ready to be deployed to a live production environment”, and the platform may perform “triggering deployment of the impending code change”; the deployed code runs on computing hardware whose processor “includes a central processing unit” that executes instructions).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Cheng in view of Negussie to deploy the changed code for execution by processors after the risk assessment, as taught by Negussie, because the code change is one “intended to repair bugs and/or security vulnerabilities in the code base or otherwise improve the functionality” of the software (Negussie, ¶[0014]), a benefit realized only once the change is deployed and executed. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP 2143(I)(G).
Claims 5, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Cheng et al. (US Pub. No. 2020/0073784, hereinafter “Cheng”) in view of Negussie et al. (US Pub. No. 2023/0088784, hereinafter “Negussie”) and further in view of Felix Grund et al., “CodeShovel: Constructing Method-Level Source Code Histories”, hereinafter “Grund”).
With respect to claim 5 (Currently Amended), Cheng in view of Negussie is silent to disclose wherein the identifying, within the computer code repository, the segment of the plurality of segments corresponding to the updated computer code comprises: inputting each code segment of the plurality of segments and the updated computer code into a similarity model, wherein the similarity model determines a degree of similarity between two sets of textual data; and determining, based on output from the similarity model, that a first code segment of the plurality of segments matches the updated computer code; however, in an analogous art, Grund teaches:
inputting each code segment of the plurality of segments and the updated computer code into a similarity model, wherein the similarity model determines a degree of similarity between two sets of textual data; (Grund, Section IV.A and Fig. 2, “CodeShovel measures similarity between two methods by comparing their body similarity and signature similarity”, and “When calculating text-based similarities (e.g., body and signature), CodeShovel uses the Jaro-Winkler distance algorithm”; the changed method is compared against every candidate method: “It does this by examining all of the method bodies within path.” Likewise, “CodeShovel ranks all methods within all files modified by a change by their body similarity.” The claim defines the similarity model by its function, determining a degree of similarity between two sets of textual data, and the specification states only that the similarity model may be a trained model (specification, ¶[0030]); Grund’s Jaro-Winkler similarity computation takes each method, a code segment, and the changed method, the updated code, and outputs a degree of textual similarity).
determining, based on output from the similarity model, that a first code segment of the plurality of segments matches the updated computer code. (Grund, Section IV.A and Fig. 2, lines 16-18, “If a method is found with at least a 75% similar body, the inputs are updated for subsequent searches”; the method whose similarity output meets the threshold is determined to be the match, and Fig. 2 returns it as the “method found in file”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Cheng in view of Negussie so that the repository segment corresponding to the updated code is identified by inputting each candidate segment and the updated code into a textual similarity model and selecting the segment whose similarity output indicates a match, as taught by Grund, because Grund’s approach is “robust in the face of common filesystem and source code transformations that occur during software development” (Grund, Section I), so that the correct segment is found even after the updated code has been edited or moved. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP 2143(I)(G).
With respect to claim 9 (Currently Amended), Cheng in view of Negussie is silent to disclose wherein the splitting the computer code within the computer code repository into the plurality of portions based on the plurality of computer code segments within the computer code update data comprises: comparing, for each computer code segment within the computer code update data, header data with stored heading data associated with the computer code within the computer code repository; and matching a first code segment with a first portion of the computer code within the computer code repository based on the header data matching the stored heading data; however, in an analogous art, Grund teaches:
comparing, for each computer code segment within the computer code update data, header data with stored heading data associated with the computer code within the computer code repository; and (Grund, Sections IV.A-IV.B and Fig. 2, lines 20-26, “For a given commit, CodeShovel stores the current file path (path), line number (num), method signature (sig), and method body (body) for the specified method.” CodeShovel “iteratively steps back through past commits in the version control repository to find other commits that also modified the method”, and for each “CodeShovel examines the signature ASTs for all other files modified in the commit.” The signature is header data; a signature change occurs “when the method is renamed (Rename), or its parameters (ParamChange), return type (ReturnChange)” change, which corresponds to the heading data of the specification, namely the name, input variables and output variables (specification, ¶[0039]); each changed method in each commit is a computer code segment within the update data, and the stored sig is the stored heading data).
matching a first code segment with a first portion of the computer code within the computer code repository based on the header data matching the stored heading data. (Grund, Section IV.A and Fig. 2, lines 22-26, CodeShovel matches by “searching all files for a method that has the same sig and a body that is at least 50% similar. If such a method is found, the inputs are updated and the change is added to the method’s history for the next iteration”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the splitting of Cheng in view of Negussie so that each update segment is matched to its repository portion by comparing method signatures with stored signatures, as taught by Grund, because doing so produces portions at method granularity, and Grund explains “the need for method-level source code histories to balance between being too coarse (e.g., file-level) and too fine (e.g., line-level) granularity” (Grund, Section I). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP 2143(I)(G).
With respect to claim 16 (Currently Amended), claim 16 recites limitations similar to claim 5 and is rejected for the same reasons set forth for claim 5 (Grund, Section I, Section IV.A, Fig. 2).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Cheng et al. (US Pub. No. 2020/0073784, hereinafter “Cheng”) in view of Negussie et al. (US Pub. No. 2023/0088784, hereinafter “Negussie”) in view of Felix Grund et al., “CodeShovel: Constructing Method-Level Source Code Histories”, hereinafter “Grund”) and further in view of Webb (US Pub. No. 2020/0278862, hereinafter “Webb”).
With respect to claim 10 (Original), Cheng in view of Negussie and Grund is silent to disclose generating a code map for the computer code repository with the first portion of the computer code having an entry within the code map; however, in an analogous art, Webb teaches:
generating a code map for the computer code repository with the first portion of the computer code having an entry within the code map. (Webb, ¶[0003], ¶[0027]-[0029], ¶[0032], ¶[0033], ¶[0043] and ¶[0051], Webb is directed to “computer code parsing and indexing”; the code parser reads the code and assigns each operation, which “may be, for example, a function”, a node ID, and “The code parser may recursively walk the computer code to capture all instances where an operation appears in the source code file. The code parser may store all the generated metadata in a metadata file.” Each node is an entry of the metadata file, which records for it a line number (Table 1), and “The code parser may in addition to recording line number in the metadata file also record the lineage of the node. Lineage may be information about which file the particular node is contained in.” The parser covers the whole body of code: “the code parser may recursively walk a file directory searching for files that are readable by the code parser”, so that “the metadata file may become increasingly large, eventually containing each operation the software program performs”, and the code so indexed is maintained in a source code repository, the visualizer showing “changes to the code between two source code repository check-ins”. From the metadata file “a map is produced showing the relative connection of each function. A user may then visually navigate the map and see all the functions rather than reading the functions in the original source code.” Selecting a node “may link to the source code itself”. The metadata file, recording for every function of the repository an entry with a pointer to its location, namely its line number and the file containing it, and the map produced from it, is a code map for the computer code repository as the specification describes the code map, namely names of code segments and corresponding pointers to code locations (specification, ¶[0040]); in the combination, the first portion matched as set forth above with respect to claim 9 is a function of the repository and has its own entry).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Cheng in view of Negussie and Grund to generate, for the computer code repository, a code map in which each matched portion, including the first portion, has an entry recording its location in the repository, as taught by Webb, because such a map provides “improved visualization of software code that enables a programmer to quickly understand the logic and flow of a program and determine if there are software bugs” (Webb, ¶[0006]), which serves the same objective of Cheng in view of Negussie of identifying code likely to cause issues. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP 2143(I)(G).
Allowable Subject Matter
Claims 4, 6-7, 11, 15 and 17-19 would be allowable if rewritten to overcome the rejection under 35 U.S.C. 101 set forth in this Office action, and, as to claims 11 and 19, the rejection under 35 U.S.C. 112(b) set forth in this Office action, and to include all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter. The prior art of record, alone or in combination, does not teach or suggest, in combination with the limitations of the respective base and intervening claims: comparing execution commands for each code segment of the plurality of segments with corresponding execution commands for the updated computer code to determine the matching segment (claims 4 and 15); determining a first number of variables within the updated computer code and a second number of variables within a matching code segment and generating a variable difference, together with the commit parameter and the line code parameter difference added to the segment data (claims 6 and 17); comparing the condition with a plurality of predetermined conditions, retrieving a plurality of functions associated with the predetermined conditions and generating for display a plurality of selectable function identifiers (claims 7 and 18); or generating an entry for each pair of a matching segment and a corresponding portion and discarding portions of the computer code within the repository without a corresponding pair (claims 11 and 19).
Cheng counts the number of variables in a source code file as a complexity feature (¶[0055]) but does not determine a difference between the number of variables of updated code and of a matching segment. Negussie keys recommendations to labels, thresholds or clusters (¶[0045]) but does not display selectable function identifiers retrieved for predetermined conditions. Grund matches methods by signature and body similarity (Section IV.A), not by execution commands, and treats an unmatched method as the method’s introducing commit rather than discarding it.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Azad et al. (US Pat. No. 11,645,188) discloses pull request risk prediction for bug-introducing changes, including chronological partitioning of a file risk dataset, file features such as a number of commits and churn lines, and a risk notification presented to the user through user interface 118. It does not disclose matching update segments to repository portions by execution commands, a variable-difference parameter, or discarding repository portions without a pair.
Emanuel Giger et al., (“Method-Level Bug Prediction”) discloses predicting bug-prone methods with machine learning classifiers from method-level change metrics, including the number of times a method was changed and the number of statements added and deleted, and code metrics, including the number of local variables in a method. It does not disclose determining a difference between the number of variables of updated code and of a matching segment.
Kelapure et al. (US Pub. No. 2015/0268939) discloses applying static and dynamic analysis rules to an expanded code base and its change history to identify code segments of interest and code segment pairs of interest. It does not disclose comparing execution commands, predicting an issue with a machine learning model, or discarding repository portions lacking a pair.
Sharma et al. (US Pub. No. 2022/0391312) discloses classifying automated-test error messages with a machine learning model, correlating a fatal error with known defective characteristics to extract an associated workaround code update, and displaying selectable “right” and “wrong” feedback options. It does not disclose displaying selectable identifiers of functions retrieved for a plurality of predetermined conditions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S Sough can be reached at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
