Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This is the initial office action based on the application filed on April 05th, 2024, which claims 1-20 are presented for examination.
Status of Claims
3. Claims 1-20 are pending, of which claims, of which claim 1, 8 and 15 are in independent form.
Priority
4. No priority has been considered for this application.
Information Disclosure Statement
5. Information disclosure statement filed on 06/17/2025, has been reviewed and considered by Examiner.
The Office's Note:
6. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner.
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.
7. Claims 1-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 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, claim 8 and claim 15 recite “identify a plurality of pull requests (PRs) associated with bug fixes; label files of the plurality of PRs for training, the files of the plurality of PRs including PR summaries; assign risk of introducing a bug (RIB) scores to the labeled files of the plurality of PRs; and train a PR risk predictor, using the RIB scores and the labeled files of the plurality of PRs, to assign an aggregate risk score to a first PR.” as drafted, are functions that, under its 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 additional elements ““memory”, and “processor” are 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, and “train a PR risk predictor, using the RIB scores and the labeled files of the plurality of PRs, to assign an aggregate risk score to a first PR” do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering, displaying, updating, transmitting and storing data/information. 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. See MPEP 2106.05(g).
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 ““memory,” and “processor” are 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, and “train a PR risk predictor, using the RIB scores and the labeled files of the plurality of PRs, to assign an aggregate risk score to a first PR”, the courts have identified merely gathering, displaying, updating, transmitting and storing data/information on a display is well-understood, routine and conventional activity. See MPEP 2106.05(d). The recitation of generic computer instruction and computer components to apply the judicial exception, and merely displaying data do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
In conclusion, 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 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.
8. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Azad (US 20230153225 – hereinafter Azad – IDS of records) and further in view of Masis (US 20220164175– hereinafter Masis).
Claim 1 rejected, Azad teaches a system comprising: a processor; and a computer-readable medium storing instructions that are operative upon execution by the processor to:
identify a plurality of pull requests (PRs) associated with bug fixes(Azad, US 20230153225, fig. 2 and para [0026-0027], pull request risk prediction program 106 retrieves historic pull requests (step 202). In an embodiment, pull request risk prediction program 106 retrieves one or more historic pull requests from pull request database 114. Para [0028-0030], Pull request risk prediction program 106 generates a file risk dataset (step 206). Based on the determined unique file linking, i.e., the unique list of linked files, pull request risk prediction program 106 generates a file risk dataset. The file risk dataset is the set of files from each of the historic pull requests that pull request risk prediction program 106 identified by the unique file linking. In an embodiment, the files in the file risk dataset include both bug-fixing data and bug-introducing data.);
label files of the plurality of PRs for training, the files of the plurality of PRs including PR summaries(Azad, fig. 2 and para [0032-0033], Pull request risk prediction program 106 labels each file with an associated risk (step 212). In an embodiment, based on the chronological partitioning and the collaborative file association, pull request risk prediction program 106 labels each file in the file risk dataset with a pre-defined risk. Para [0034-0035], pull request risk prediction program 106 extracts and/or computes file features, such as a number of commits that include the file, a churn value, e.g., a number of lines added and/or subtracted, and a number of changesets, from each of the files included in the labelled file risk inducing ground truth dataset. In an embodiment, pull request risk prediction program 106 instructs file risk prediction model 108 to extract the file features from the labelled file risk inducing ground truth dataset.);
assign risk of introducing a bug (RIB) scores to the labeled files of the plurality of PRs(Azad, para [0032-0035], the pre-defined risk levels are a binary set, such as 1 and 0, yes and no, or risky and not risky. In another embodiment, the pre-defined risk levels are a numerical value. For example, pull request risk prediction program 106 may assign a risk value of a number between 1 and 10. In another embodiment, the pre-defined risk levels are text in natural language. For example, pull request risk prediction program 106 may assign a risk value of risky, very risky, or extremely risky.); and
train a PR risk predictor, using the RIB scores and the labeled files of the plurality of PRs, to assign an aggregate risk score to a first PR(Azad, para [0039-0040], Pull request risk prediction program 106 combines the file risk assessment with the extracted pull request features (step 228). In an embodiment, pull request risk prediction program 106 combines the file risk assessment, as discussed with respect to step 222 and the extracted pull request features, as discussed with respect to step 226, to generate a labelled training set and train pull request risk prediction model 110. Para [0041], Pull request risk prediction program 106 stores resulting pull request risk prediction model 110 (step 230). In an embodiment, pull request risk prediction program 106 stores pull request risk prediction model 110 as a file such that pull request risk prediction program 106 can apply the model to new pull requests as they are received. In the embodiment depicted in FIG. 1, pull request risk prediction program 106 stores pull request risk prediction model 110 in pull request database 114.).
The Office would like to use prior art Masis to back up Azad to further teach limitation
assign risk of introducing a bug (RIB) scores to the labeled files of the plurality of PRs (Masis, US 20220164175, para [0023], The update-evaluation module 124 can additionally or alternatively determine the risk score 126 based on a bug report 150 from a third party. The update-evaluation module 124 can retrieve the bug report 150 from a location at which the bug report 150 is stored, such as the developer system 136. The bug report 150 may indicate a bug associated with a feature 106a used by the end user 138. The bug report 150 may also indicate the severity of the bug according to a predefined scale. The update-evaluation module 124 can analyze the bug report 150 and generate the risk score 126 based on this analysis. For example, if the bug is of higher severity, the update-evaluation module 124 may generate a correspondingly higher risk-score. And if the bug is of lower severity, the update-evaluation module 124 may generate a correspondingly lower risk-score. Para [0039-0040].)
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Masis into Azad to receive usage information describing how an end user used an existing version of a software application on a computing device of the end user. The processor generates a risk score for an update based on a code change in response to determining that a source code includes the code change to a particular feature used by the user, and generates a graphical user interface indicating the score for the user with respect to installing the update to the version of the application based on generating the score as suggested by Masis (See abstract and conclusion).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Azad and Masis teach the system of claim 1, wherein labeling the files of the plurality of PRs for training comprises labeling the files with code clone and code smell labels(Azad, fig. 2 and para [0032-0033], Pull request risk prediction program 106 labels each file with an associated risk (step 212). In an embodiment, based on the chronological partitioning and the collaborative file association, pull request risk prediction program 106 labels each file in the file risk dataset with a pre-defined risk. Para [0019], File risk prediction model 108 extracts file features from one or more files included in a commit that are labelled as risky and applies a statistical model to the extracted features to output a file risk assessment. File features may include, but are not limited to, a number of commits that include the file, a churn value, e.g., a number of lines added and/or subtracted, a number of changesets, and a togetherness score.).
Claim 3 is rejected for the reasons set forth hereinabove for claim 1, Azad and Masis teach the system of claim 1, wherein the PR risk predictor comprises a code clone risk prediction model (CCPM) and a code smell risk prediction model (CSPM), and wherein the aggregate risk score comprises an aggregation of a CCPM RIB score and a CSPM RIB score(Azad, para [0017-0020], n. Pull request risk prediction program 106 inputs the file risk inducing ground truth dataset to a file risk prediction model that extracts file features from the file risk inducing ground truth dataset and computes file togetherness score features. Para [0036-0037], Pull request risk prediction program 106 computes file togetherness score features (step 220). In an embodiment, pull request risk prediction program 106 computes a togetherness score feature for each file included in the labelled file risk inducing ground truth dataset. The togetherness score captures the probability that files in the dataset are committed together. For example, if file 1 and file 3 occur together in all the commits, then the file association between them is 1. In another example, if file 1 and file 2 occur together in 1 of 3 commits, then the file association between them is 0.34. In addition, the togetherness score is dynamic, as it depends on the set of files included in a commit. In an embodiment, pull request risk prediction program 106 uses the mined pairs, i.e., itemsets, identified during collaborative file association, as discussed with respect to step 210, to compute the togetherness score value. In an embodiment, pull request risk prediction program 106 instructs file risk prediction model 108 to compute file togetherness score features.).
Claim 4 is rejected for the reasons set forth hereinabove for claim 3, Azad and Masis teach the system of claim 3, wherein training the PR risk predictor comprises:
partitioning the labeled files of the plurality of PRs into a training set and a test set (Azad, para [0029], Pull request risk prediction program 106 performs chronological partitioning on the file risk dataset to determine bug-introducing changes (step 208). Typically, a bug-introducing change occurs chronologically prior to a bug-fixing change. Often, the same set of files are associated with the bug-fixing change and the bug-introducing change. Chronological partitioning isolates the set of changes over a file before the bug-fixing change occurred, therefore, the subset contains only those candidate commits that include bug-introducing changes. Pull request risk prediction program 106 performs this chronological partitioning to construct a dataset, i.e., a corpus, for use in training pull request risk prediction model 110. In an embodiment, pull request risk prediction program 106 analyzes the files within the file risk dataset to determine which of the files are associated with commits that were bug-fixing commits, i.e., commits that were introduced to fix a detected bug in the software. Pull request risk prediction program 106 then identifies the commits introduced just prior to the bug-fixing commits as bug-introducing commits and identifies the files associated with the bug-introducing commits. Azad, para [0042-0052], FIG. 3 is a flowchart depicting operational steps of pull request risk prediction program 106, on server computer 104 within distributed data processing environment 100 of FIG. 1, for using pull request risk prediction model 110, in accordance with an embodiment of the present invention.);
training the CCPM and the CSPM, using the training set, to predict RIB scores (Azad, para [0040], Pull request risk prediction program 106 combines the file risk assessment with the extracted pull request features (step 228). In an embodiment, pull request risk prediction program 106 combines the file risk assessment, as discussed with respect to step 222 and the extracted pull request features, as discussed with respect to step 226, to generate a labelled training set and train pull request risk prediction model 110.); and
revaluating performance of the CCPM and the CSPM using the test set (Azar, para [0042-0052], FIG. 3 is a flowchart depicting operational steps of pull request risk prediction program 106, on server computer 104 within distributed data processing environment 100 of FIG. 1, for using pull request risk prediction model 110, in accordance with an embodiment of the present invention.).
Claim 5 is rejected for the reasons set forth hereinabove for claim 1, Azad and Masis teach the system of claim 1, wherein the instructions are further operative to: train a PR finder, using the plurality of PRs, to identify a set of candidate PRs in a PR database, having a potential association with a reported bug( Azad, para [0029], Pull request risk prediction program 106 performs chronological partitioning on the file risk dataset to determine bug-introducing changes (step 208). Typically, a bug-introducing change occurs chronologically prior to a bug-fixing change. Often, the same set of files are associated with the bug-fixing change and the bug-introducing change. Chronological partitioning isolates the set of changes over a file before the bug-fixing change occurred, therefore, the subset contains only those candidate commits that include bug-introducing changes. Pull request risk prediction program 106 performs this chronological partitioning to construct a dataset, i.e., a corpus, for use in training pull request risk prediction model 110. In an embodiment, pull request risk prediction program 106 analyzes the files within the file risk dataset to determine which of the files are associated with commits that were bug-fixing commits, i.e., commits that were introduced to fix a detected bug in the software. Pull request risk prediction program 106 then identifies the commits introduced just prior to the bug-fixing commits as bug-introducing commits and identifies the files associated with the bug-introducing commits. Azad, para [0040], Pull request risk prediction program 106 combines the file risk assessment with the extracted pull request features (step 228). In an embodiment, pull request risk prediction program 106 combines the file risk assessment, as discussed with respect to step 222 and the extracted pull request features, as discussed with respect to step 226, to generate a labelled training set and train pull request risk prediction model 110.).
Claim 6 is rejected for the reasons set forth hereinabove for claim 5, Azad and Masis teach the system of claim 5, wherein training the PR finder comprises training the PR finder to use at least a classification of a reported bug in a bug report to identify the set of candidate PRs(Azad, para [0037], Pull request risk prediction program 106 applies a model to the extracted and computed features (step 222). In an embodiment, pull request risk prediction program 106 applies a statistical model to the extracted and computed file features to generate a file risk assessment. For example, pull request risk prediction program 106 may apply a logistic regression model to predict a risk score. In another example, pull request risk prediction program 106 may use a classification model. In another embodiment, pull request risk prediction program 106 applies a machine learning model to the extracted and computed file features to generate the file risk assessment. In an embodiment, pull request risk prediction program 106 instructs file risk prediction model 108 to generate a file risk assessment based on the extracted and computed features.).
Claim 7 is rejected for the reasons set forth hereinabove for claim 1, Azad and Masis teach the system of claim 1, wherein the instructions are further operative to:
receive a bug report for a reported bug(Azad, para [0029], Pull request risk prediction program 106 performs chronological partitioning on the file risk dataset to determine bug-introducing changes (step 208). Typically, a bug-introducing change occurs chronologically prior to a bug-fixing change. Often, the same set of files are associated with the bug-fixing change and the bug-introducing change. Chronological partitioning isolates the set of changes over a file before the bug-fixing change occurred, therefore, the subset contains only those candidate commits that include bug-introducing changes);
determine, from at least the bug report, a classification for the reported bug(Azad, para [0029-0030], In an embodiment, pull request risk prediction program 106 analyzes the files within the file risk dataset to determine which of the files are associated with commits that were bug-fixing commits, i.e., commits that were introduced to fix a detected bug in the software. Pull request risk prediction program 106 then identifies the commits introduced just prior to the bug-fixing commits as bug-introducing commits and identifies the files associated with the bug-introducing commits.);
query a PR database to identify a set of candidate PRs, having a potential association with the reported bug, based on at least the classification of the reported bug(Azad, para [0035], Pull request risk prediction program 106 extracts file features from the labelled file risk inducing ground truth dataset (step 218). In an embodiment, pull request risk prediction program 106 extracts and/or computes file features, such as a number of commits that include the file, a churn value, e.g., a number of lines added and/or subtracted, and a number of changesets, from each of the files included in the labelled file risk inducing ground truth dataset. In an embodiment, pull request risk prediction program 106 instructs file risk prediction model 108 to extract the file features from the labelled file risk inducing ground truth dataset.);
rank the set of candidate PRs according to a likelihood of each PR of the set of candidate PRs having caused the reported bug(Azad, para [0036-0037], Pull request risk prediction program 106 computes file togetherness score features (step 220). In an embodiment, pull request risk prediction program 106 computes a togetherness score feature for each file included in the labelled file risk inducing ground truth dataset. The togetherness score captures the probability that files in the dataset are committed together. For example, if file 1 and file 3 occur together in all the commits, then the file association between them is 1. In another example, if file 1 and file 2 occur together in 1 of 3 commits, then the file association between them is 0.34. In addition, the togetherness score is dynamic, as it depends on the set of files included in a commit. In an embodiment, pull request risk prediction program 106 uses the mined pairs, i.e., itemsets, identified during collaborative file association, as discussed with respect to step 210, to compute the togetherness score value. In an embodiment, pull request risk prediction program 106 instructs file risk prediction model 108 to compute file togetherness score features.);
generate a bug remediation task report for the reported bug, the bug remediation task report including the set of candidate PRs and the ranking of the set of candidate PRs(Azad, para [0037-0040], pull request risk prediction program 106 applies a model to the extracted and computed features (step 222). In an embodiment, pull request risk prediction program 106 applies a statistical model to the extracted and computed file features to generate a file risk assessment. For example, pull request risk prediction program 106 may apply a logistic regression model to predict a risk score. In another example, pull request risk prediction program 106 may use a classification model. In another embodiment, pull request risk prediction program 106 applies a machine learning model to the extracted and computed file features to generate the file risk assessment. In an embodiment, pull request risk prediction program 106 instructs file risk prediction model 108 to generate a file risk assessment based on the extracted and computed features. Para [0041], Pull request risk prediction program 106 stores resulting pull request risk prediction model 110 (step 230). In an embodiment, pull request risk prediction program 106 stores pull request risk prediction model 110 as a file such that pull request risk prediction program 106 can apply the model to new pull requests as they are received. In the embodiment depicted in FIG. 1, pull request risk prediction program 106 stores pull request risk prediction model 110 in pull request database 114.); and
transmit the bug remediation task report to a remediation entity(Azad, para [0039], Pull request risk prediction program 106 extracts pull request features from historic pull requests (step 226). In an embodiment, pull request risk prediction program 106 extracts features of historic pull requests stored in pull request database 114. Pull request features, as would be recognized by a person of skill in the art, may include, but are not limited to, a pull request description, a pull request short description, a number of participants in the pull request, a notation of whether one or more reviewers are assigned, a percentage of reviewers that approved, a number of conversations, a duration of the pull request (i.e., a time between creation and closure of the pull request), a number of problematic bug-introducing commits as a fraction or percentage of the total commits, a number of additions, a number of deletions, a unit test score, an integration test score, a code coverage score, a yapf score, and a lynting score. In an embodiment, pull request risk prediction program 106 uses one or more natural language processing (NLP) techniques to extract the features.).
As per claim 8, this is the method claim to system claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 9, this is the method claim to system claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 10, this is the method claim to system claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 11, this is the method claim to system claim 4. Therefore, it is rejected for the same reasons as above.
As per claim12, this is the method claim to system claim 5. Therefore, it is rejected for the same reasons as above.
As per claim 13, this is the method claim to system claim 6. Therefore, it is rejected for the same reasons as above.
As per claim 14, this is the method claim to system claim 7. Therefore, it is rejected for the same reasons as above.
As per claim 15, this is the medium claim to system claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 16, this is the medium claim to system claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 17, this is the medium claim to system claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 18, this is the medium claim to system claim 4. Therefore, it is rejected for the same reasons as above.
As per claim 19, this is the medium claim to system claim 5 and claim 6. Therefore, it is rejected for the same reasons as above.
As per claim 20, this is the medium claim to system claim 7. Therefore, it is rejected for the same reasons as above.
Inquiry
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199
Prosecution Insights