DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Request for Continued Examination filed on February 6, 2026.
Claims 1, 3-7, 9-10, 12-15, 17 and 19-20 are pending.
Claims 1, 10 and 17 have been amended.
Claims 8 and 16 have been canceled.
Response to Amendment
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.
Claims 1, 6-7, 10, 14-15, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Majithia et al. (US 2023/0055527) in view of Aloraini et al. (US 2024/0427900).
With respect to Claim 1, Majithia et al. disclose:
automatically self-tuning regression testing of executing merged code within a development and operational (DevOps) computing environment, the automatically self-tuning regression testing of executing merged code comprising: (see Figure 1 (DevOps computing environment); The autobuild system (DevOps environment) compiling the updated source code may then trigger a testing system (DevOps environment) executing a plurality of tests against the compiled executable code for the application platform (regression testing) to generate a corresponding log file including data associated with the performance of the code with respect to the respective tests. Assigning one or more risk scores to each change of the update and selecting the highest risk change from among the changes. Thereafter, the testing system 110 is triggered (by the autobuild system or the fault detection system 112) to re-execute one or more automated tests 114 (self-tuning regression testing) associated with the test run for the log file 116 under analysis against the compiled modified executable code for the application platform to generate a corresponding test result data associated with the performance of the source code of the selected change with respect to the respective tests, Paragraphs 31-34)
executing the merged code using a suite of test cases to regression test the merged code, the merged code comprising multiple code changes; (multiple test cases are executed against a version of the computer-executable code that includes multiple different changes or updates (merged code), Paragraph 10, lines 4-6)
obtaining, based on the executing of the merged code using the suite of test cases, a test case failure; (when execution of one or more tests against the updated compilation of the executable code for the application platform result in a failure, Paragraph 11, lines 1-3)
determining, using an artificial intelligence engine comprising a trained machine learning model, (using a trained risk prediction model (trained machine learning model) to calculate a numerical value corresponding to a probability of a change to the source code resulting in a test failure as a function of input change characteristic variables associated with a particular change based on historical relationships between the change characteristics associated with historical changes and the corresponding test results, Paragraph 25) a likely faulty code change of the multiple code changes resulting in the test case failure by generating faulty code change scores for the multiple code changes based on relevance to the test case failure (the fault detection system 112 may utilize machine learning or other artificial intelligence techniques to determine which change characteristics are more highly correlated with or predictive of the failure of a particular test or test run, and then determine a corresponding equation, function, or model for calculating a probability of test failure based on that set of input change characteristics. Thus, the resultant model is capable of characterizing or mapping the identified change characteristics (e.g., task 206) associated with a source code file for a change to an output value representative of the probability or likelihood of a test failure, which may alternatively be referred to herein as a risk score or risk metric for the change (faulty code change scores, Paragraph 25, lines 17-30) and ranking the multiple code changes based on the faulty code change scores, (the fault detection system initially identifies and selects the highest risk change (ranking the multiple code changes based on the faulty code change scores) from among the changes associated with the update that has the highest value for the risk score (or the highest aggregate or combined value across different constituent risk score) relative to the risk scores associated with the remaining changes associated with the update, Paragraph 34, lines 1-11) wherein a faulty code change score comprises a [merged score] obtained from a current faulty code change score for a respective code change, (risk score for a change can be an aggregate or combined (merged score) value across different constituent risk scores (current faulty code change score), Paragraph 34) obtained from scoring the multiple code changes for relevance to a plurality of test case failures; (the fault detection system initially identifies and selects the highest risk change from among the changes associated with the update that has the highest value for the risk score (or the highest aggregate or combined value across different constituent risk score) relative to the risk scores associated with the remaining changes associated with the update (scoring the multiple code changes for relevance to a plurality of test case failures), Paragraph 34, lines 1-11; root case of one or more test case failures, Paragraph 31)
automatically customizing, based on the likely faulty code change, the suite of test cases by removing one or more test cases from the suite of test cases irrelevant to further testing the likely faulty code change to generate a tailored test case set that facilitates verifying that the likely faulty code change is the faulty code change by reducing regression testing time while maintaining verification accuracy; (the testing system 110 is triggered (by the autobuild system or the fault detection system 112) (automatically) to re-execute one or more automated tests 114 associated with the test run for the log file 116 under analysis against the compiled modified executable code for the application platform to generate a corresponding test result data associated with the performance of the source code of the selected change with respect to the respective tests. In this regard, in some implementations, the testing systems 110 may be configurable to only execute the subset of automated tests 114 (tailored test case set) associated with the test run for the log file 116 for which the previous test resulted in failure (removing one or more test cases from the suite of test cases irrelevant to testing the likely faulty code change) when executed against the updated autobuild code 140 including all of the changes in the change list 142 (verifying that the faulty code change is the faulty code change), Paragraph 34)
and continuing executing the merged code within the development and operational (DevOps) computing environment using the tailored test case set to continue regression testing of the executing merged code to facilitate verifying that the likely faulty code change is the faulty code change. (re-execute one or more previously-failed tests (tailored test case set) against the compiled version of the modified update to verify or otherwise confirm that the highest risk change caused the failure of the test(s) (continuing regression testing/verifying that the likely faulty code is the faulty code change), Paragraph 11, lines 23-27)
Majithia et al. do not disclose:
[a merged score] is obtained from merging a current faulty code change score for a respective code change and a historical-based faulty code change score for the respective code change obtained using historical code change tests and historical fault code change data;
However, Aloraini et al. disclose:
[a merged score] is obtained from merging a current faulty code change score for a respective code change, obtained from scoring the multiple code changes for relevance to a plurality of test case failures, and a historical-based faulty code change score for the respective code change obtained using historical code change tests and historical fault code change data; (risk score aggregator 220 is configured to obtain tokenization score 212 and historical score 214, and aggregate (merge) the obtained scores to generate risk score (merged score), Paragraph 69; tokenization score 212 indicates that the changeset comprises code that has the possibility of resulting a privacy leak (current faulty code change score)., Paragraph 40; historical score is determined based on a set of computer code stored in a repository by extracting a feature based on the code changeset (respective code change) and then determining the historical score based on the feature (historical-based faulty code change score), Paragraph 140)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Aloraini et al. into the teaching of Majithia et al. to include [a merged score] obtained from merging a current faulty code change score for a respective code change, obtained from scoring the multiple code changes for relevance to a plurality of test case failures, and a historical-based faulty code change score for the respective code change obtained using historical code change tests and historical fault code change data in order to help determine the likelihood that a code changeset would cause or caused a bug, flaw or anomaly. (Aloraini et al., Paragraph 52-54)
With respect to Claim 6, all the limitations of Claim 1 have been addressed above; and Majithia et al. further disclose:
wherein determining, by the artificial intelligence engine comprising the trained machine learning model, the likely faulty code change comprises at least in part, from scoring the multiple code changes for relevance to a plurality of test case failures obtained from executing the merged code using the suite of test cases, (calculating a numerical value (faulty code change score) corresponding to a probability of a change to the source code resulting in a test failure as a function of input change characteristic variables associated with a particular change based on historical relationships between the change characteristics associated with historical changes and the corresponding test results (relevance), Paragraph 25, lines 9-17) the test case failure being one test case failure of the plurality of test case failures. (a test run resulting in one or more test failures (plurality of test case failures) to identify a change associated with an update to executable code that is likely to be a root cause of the test failures (plurality of test case failures), Paragraph 31, lines 1-7)
With respect to Claim 7, all the limitations of Claim 6 have been addressed above; and Majithia et al. further disclose:
further comprising training a machine learning model to generate the trained machine learning model to determine scoring of the multiple code changes for relevance to the plurality of the test case failures, (risk prediction model (machine learning model) is trained to convert a set of input change characteristics associated with a source code file into an output value (determine scoring), Paragraph 26, lines 1-5; using a trained risk prediction model to calculate a numerical value corresponding to a probability of a change to the source code resulting in a test failure as a function of input change characteristic variables associated with a particular change based on historical relationships between the change characteristics associated with historical changes and the corresponding test results, Paragraph 25; a test run resulting in one or more test failures to identify a change associated with an update to executable code that is likely to be a root cause of the test failures (multiple code changes/multiple test case failures), Paragraph 31, lines 1-7) the training of the machine learning model using, at least in part, current change code data for the merged code and the plurality of test case failures obtained from testing the merged code using the suite of test cases. (the risk modeling process 200 may be periodically repeated to adaptively and dynamically update (train) the risk prediction model(s) 132 based on the performance of the fault detection process 300 (current change code data) to improve the performance of the risk prediction model(s) 132 at assigning risk scores to source code changes, Paragraph 36, lines 9-19)
Claims 10 and 14-15 are computer system claims corresponding to the method claims above (Claims 1 and 6-7) and, therefore, are rejected for the same reasons set forth in the rejections of Claims 1 and 6-7.
Claims 17 and 20 are computer program product claims corresponding to the method claims above (Claims 1 and 6) and, therefore, are rejected for the same reasons set forth in the rejections of Claims 1 and 6.
Claims 3-5, 12-13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Majithia et al. (US 2023/0055527) in view of Aloraini et al. (US 2024/0427900) and in further view of Cmielowski et al. (US 2021/0287109).
With respect to Claim 3, all the limitations of Claim 1 have been addressed above; and Majithia et al. and Aloraini et al. further disclose:
wherein the test case failure is one test case failure of a plurality of test case failures obtained from executing the merged code using the suite of test cases, (Majithia et al., a test run (executing the merged code) resulting in one or more test failures to identify a change associated with an update to executable code (merged code) that is likely to be a root cause of the test failures (plurality of test case failures), Paragraph 31, lines 1-7)
Majithia et al. and Aloraini et al. do not disclose:
and wherein the method further comprises classifying the plurality of test case failures into different test case failure classes, the determining including using the test case failure classes to facilitate determining the likely faulty code change.
However, Cmielowski et al. disclose:
and wherein the method further comprises classifying the plurality of test case failures into different test case failure classes, (groups a set of test failures within the test results into one or more sets of test failure groups (test case failure classes) according to a set of failure attributes, Paragraph 74, lines 1-4; determines the failure type (e.g., bug failure, test failure) (different test case failure classes) for each failed test in the one or more sets of test failure groups (classifying) using the first machine learning model, Paragraph 85) the determining including using the test case failure classes to facilitate determining the likely faulty code change. (A root cause failure (likely faulty code change) for each cluster is identified based on the set of clusters and the set of failure attributes (test case failure classes), Paragraphs 17 and 89, lines 27-29 and 1-6 respectively)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Cmielowski et al. into the teaching of Majithia et al. and Aloraini et al. to include wherein the method further comprises classifying the plurality of test case failures into different test case failure classes, the determining including using the test case failure classes to facilitate determining the likely faulty code change in order to help determine the cause of failed test cases more efficiently and accurately. (Cmielowski et al., Paragraph 17, lines 39-41)
With respect to Claim 4, all the limitations of Claim 3 have been addressed above; and Majithia et al. and Aloraini et al. do not disclose:
wherein classifying the plurality of test case failures comprises generating test case failure symptom groups based on data-analyzing the plurality of test case failures, and based on analyzing historical test case failure data, the test case failure symptom groups comprising groups of test cases exhibiting similar symptoms, wherein the test case failure symptom groups are the test case failure classes.
However, Cmielowski et al. disclose:
wherein classifying the plurality of test case failures comprises generating test case failure symptom groups based on data-analyzing the plurality of test case failures, (a set of test failures (within the test results) is grouped into one or more sets of test failure groups (test case failure symptom groups) according to a set of failure attributes (data-analyzing the plurality of test case failures), Paragraph 17, lines 1-12) and based on analyzing historical test case failure data, the test case failure symptom groups comprising groups of test cases exhibiting similar symptoms, (A “failure group,” as used herein, refers to a group of failures with similar failure attributes. “Failure attributes,” as used herein, refer to the attributes or features of test reports and the reported historical issues that are linked to historical test reports, Paragraph 17, lines 1-12) wherein the test case failure symptom groups are the test case failure classes. (a set of test failures (within the test results) is grouped into one or more sets of test failure groups according to a set of failure attributes (test case failure symptom groups), Paragraph 17, lines 1-12)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Cmielowski et al. into the teaching of Majithia et al. and Aloraini et al. to include wherein classifying the plurality of test case failures comprises generating test case failure symptom groups based on data-analyzing the plurality of test case failures, and based on analyzing historical test case failure data, the test case failure symptom groups comprising groups of test cases exhibiting similar symptoms, wherein the test case failure symptom groups are the test case failure classes in order to help determine the cause of failed test cases more efficiently and accurately. (Cmielowski et al., Paragraph 17, lines 39-41)
With respect to Claim 5, all the limitations of Claim 4 have been addressed above; and Majithia et al. and Aloraini et al. do not disclose:
further comprising using a decision tree to train an artificial intelligence classify model based on the historical test case failure data to facilitate generating the test case failure symptom groups.
However, Cmielowski et al. disclose:
further comprising using a decision tree to train an artificial intelligence classify model based on the historical test case failure data to facilitate generating the test case failure symptom groups. (A machine learning model is a mathematical model built by a machine learning algorithm based on sample data, known as “training data,” (decision tree) in order to make predictions or decisions without being explicitly programmed to perform the task. In one embodiment, the training data consists of failure attributes and historical failures, Paragraph 40; the first machine learning model corresponds to a classification model trained to predict the issue type (e.g., bug failure, test failure) (test case failure symptom groups) for the failed test cases. In one embodiment, such a machine learning model is trained based on failure attributes and historical failures, such as test case information, test suite execution summary, test case name, environment name, execution data and time, execution duration, test suite name, test case description, test case execution log, test case execution error message, and test case execution stack trace, Paragraph 40; root cause analysis using machine learning classification and clustering algorithms wherein such algorithms include linear classifiers, nearest neighbor, support vector machines, decision trees, boosted trees, random forest, neural networks, K-means clustering algorithms, Fuzzy c-means clustering algorithms, Gaussian clustering algorithms, centroid-based clustering algorithms, density-based clustering algorithms, distribution-based clustering algorithms, hierarchical clustering algorithms, etc., Paragraph 56)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Cmielowski et al. into the teaching of Majithia et al. and Aloraini et al. to include using a decision tree to train an artificial intelligence classify model based on the historical test case failure data to facilitate generating the test case failure symptom groups in order to help determine the cause of failed test cases more efficiently and accurately. (Cmielowski et al., Paragraph 17, lines 39-41)
Claims 12 and 13 are computer system claims corresponding to the method claims above (Claims 3 and 4) and, therefore, are rejected for the same reasons set forth in the rejections of Claims 3 and 4.
Claim 19 is a computer program product claim corresponding to the method claim above (Claim 3) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 3.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Majithia et al. (US 2023/0055527) i in view of Aloraini et al. (US 2024/0427900) and in further view of Thakkar et al. (US 2009/0222697).
With respect to Claim 9, all the limitations of Claim 1 have been addressed above; and Majithia et al. and Aloraini et al. do not disclose:
further comprising using association rules to mine functional relationships and shared test suites between different code modules of the multiple code changes, and wherein the automatically customizing the suite of test cases to generate the tailored test case set is further based, at least in part, on the functional relationships and shared test suites between the different code modules of the multiple code changes of the merged code.
However, Thakkar et al. disclose:
further comprising using association rules to mine functional relationships and shared test suites between different code modules of the multiple code changes, (information such as a shared object map (association rules) is mined to extract the functional relationship between test cases (shared test suites) to generate a Failure Dependency Graph, Paragraphs 28-29; see Figure 2; shared object map contains objects (different code modules of the one or more code changes) that are shared between all the scripts, Paragraph 29) and wherein the automatically customizing the suite of test cases to generate the tailored test case set is further based, at least in part, on the functional relationships and shared test suites between the different code modules of the multiple code changes of the merged code. (If a test case fails, then based on the failure dependency graph, (based on the functional relationships and shared test suites) the dependency graph is traversed and all the related test cases are executed. (customized suites of test cases) This way, failures of test cases lead to dynamic coverage of additional cases (customized suites of test cases) that are related based on functional and failure dependency, Paragraph 19)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Thakkar et al. into the teaching of Majithia et al. and Aloraini et al. to include using association rules to mine functional relationships and shared test suites between different code modules of the multiple code changes, and wherein the automatically customizing the suite of test cases to generate the tailored test case set is further based, at least in part, on the functional relationships and shared test suites between the different code modules of the multiple code changes of the merged code in order improve early detection of defects based on a dynamic coverage mechanism. (Thakkar et al., Paragraph 31, lines 7-9)
Response to Arguments
Applicant's arguments filed January 7, 2026 have been fully considered but they are not persuasive.
In the Remarks, Applicant argues:
As noted, by this paper, certain allowable subject matter of dependent claims 8 & 16 is incorporated into independent claims 1, 10 & 17. In particular, the independent claims are amended to further recite that "determining, using an artificial intelligence engine comprising a trained machine learning model, a likely faulty code change of the multiple code changes resulting in the test case failure by generating faulty code change scores for the multiple code changes based on relevance to the test case failure and ranking the multiple code changes based on the faulty code change scores" further includes "wherein a faulty code change score comprises a merged score obtained from merging a current faulty code change score for a respective code change, obtained from scoring the multiple code changes for relevance to a plurality of test case failures, and a historical-based faulty code change score for the respective code change obtained using historical code change tests and historical fault code change data." This recitation is believed to capture the patentable subject matter of now canceled claims 8 & 16. As such, the independent claims presented herewith are believed to be in condition for allowance, and such action is respectfully requested.
Examiner’s Response:
Applicant’s arguments above with respect to claim(s) 1, 10 and 17 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In the Remarks, Applicant argues:
Numerous further aspects of Applicant's amended claim 1 are also believed to patentably distinguish over Majithia. For instance, amended claim 1 specifically recites "automatically self-tuning regression testing of executing merged code within a development and operational (DevOps) computing environment" and "automatically customizing, based on the likely faulty code change, the suite of test cases by removing one or more test cases from the suite of test cases irrelevant to further testing the likely faulty code change to generate a tailored test case set that facilitates verifying that the likely faulty code change is the faulty code change by reducing regression testing time while maintaining verification accuracy." No similar teaching is believed to be disclosed by Majithia.
For instance, Majithia fails to uncover any discussion of "automatically customizing, based on the likely faulty code change, the suite of test cases by removing one or more test cases from the suite of test cases irrelevant to further testing the likely faulty code change to generate a tailored test case set that facilitates verifying that the likely faulty code change is the faulty code change by reducing regression testing time while maintaining verification accuracy", as Applicant recites. Applicant respectfully submits that the process described by Majithia is fundamentally different. For instance, Majithia "... creates a modified update to the executable code that includes only the selected change by excluding remaining changes from the change list and then initiates a test run against the modified update." (See paragraph [0034] of Majithia). Applicant respectfully submits that this different from "automatically customizing...the suite of test cases by removing one or more test cases from the suite of test cases irrelevant to further testing the likely faulty code change" as Applicant recites. Also, Majithia's re-execution of previously failed tests is not the same as intelligently removing irrelevant test cases based on analysis of the likely faulty code change. Majithia simply reruns tests that previously failed, which is a reactive approach based on prior test outcomes, not a proactive customization based on relevance to the identified faulty code change, as Applicant recites.
In addition, Applicant's amended claim 1 recites, in part "automatically customizing, based on the likely faulty code change, the suite of test cases by removing one or more test cases from the suite of test cases irrelevant to further testing the likely faulty code change..." where the "removing one or more test cases" is "...to generate a tailored test case set that facilitates verifying that the likely faulty code change is the faulty code change by reducing regression testing time while maintaining verification accuracy." Majithia does not disclose this aspect and specific technical benefit of Applicant's recited invention. Rather, Majithia's goal is to "more quickly arrive at the change that is the root cause of a test failure" by "progressively analyzing changes in a risk descending order" (see paragraph [0036] of Majithia). This is different from reducing regression testing time through intelligent test case selection while maintaining accuracy, as Applicant recites.
Examiner’s Response:
The Examiner respectfully disagrees. As can be seen in the updated §103 rejection to claim 1, it is the Examiner’s position that Majithia discloses the Applicant’s claim language of "automatically self-tuning regression testing of executing merged code within a development and operational (DevOps) computing environment" and "automatically customizing, based on the likely faulty code change, the suite of test cases by removing one or more test cases from the suite of test cases irrelevant to further testing the likely faulty code change to generate a tailored test case set that facilitates verifying that the likely faulty code change is the faulty code change by reducing regression testing time while maintaining verification accuracy." Specifically, Majithia discloses an autobuild system that compiles an updated source code which then triggers a testing system (DevOps computing environment) that executes a plurality of tests against the compiled executable code for the application platform. A corresponding log file is generated that includes data associated with the performance of the code with respect to the respective tests. Assigning one or more risk scores to each change of the update and selecting the highest risk change from among the changes. Thereafter, the testing system is triggered (by the autobuild system or the fault detection system) to re-execute one or more automated tests (self-tuning regression testing) associated with the test run for the log file under analysis against the compiled modified executable code for the application platform to generate a corresponding test result data associated with the performance of the source code of the selected change with respect to the respective tests (see Paragraphs 31-34). This disclosure can be reasonably interpreted as the Applicant’s “automatically self-tuning regression testing of executing merged code within a development and operational (DevOps) computing environment”.
Further, Majithia discloses that the testing system is triggered (by the autobuild system or the fault detection system) to re-execute one or more automated tests associated with the test run for the log file under analysis against the compiled modified executable code for the application platform to generate a corresponding test result data associated with the performance of the source code of the selected change with respect to the respective tests. In this regard, the testing systems may be configurable to only execute the subset of automated tests (tailored test case set) associated with the test run for the log file for which the previous test resulted in failure when executed against the updated autobuild code including all of the changes in the change list (see Paragraph 34). The disclosure can be reasonably interpreted as the Applicant’s claim language of “automatically customizing, based on the likely faulty code change, the suite of test cases by removing one or more test cases from the suite of test cases irrelevant to further testing the likely faulty code change to generate a tailored test case set that facilitates verifying that the likely faulty code change is the faulty code change by reducing regression testing time while maintaining verification accuracy." The execution of a subset of automated tests that previously resulted in a failure (i.e. tests cases that passed are removed from subsequent execution) in a subsequent test run to identify a root cause for a failure as disclosed in Majithia can be reasonably interpreted as customizing a suite of test cases by removing one or more test cases to generating a tailored test case set.
Applicant argues that “Majithia simply reruns tests that previously failed, which is a reactive approach based on prior test outcomes, not a proactive customization based on relevance to the identified faulty code change.” However, the current claim language do not preclude the interpretation of a “reactive approach” and necessarily require a “proactive customization”. Omitting/not including a test case can be reasonably interpreted as removing one or more test cases.
Applicant appears to argue that Majithia does not disclose “reducing regression testing time through intelligent test case selection while maintaining accuracy”. The Examiner disagrees. Majithia discloses that by using risk-based stratification and analysis of changes, the amount of time and resources required to identify the root cause can be reduced, thereby increasing testing velocity, shortening development cycles, and improving product quality and performance (see Paragraph 12). This disclosure teaches “reducing regression testing time through intelligent test case selection while maintaining accuracy”.
In the Remarks, Applicant argues:
Further, Applicant's amended claim 1 recites, in part "...generating faulty code change scores for the multiple code changes based on relevance to the test case failure", the Office Action maps this aspect of Applicant's invention to Majithia's risk scores. However, Majithia risk prediction model calculates "a numerical value corresponding to a probability of a change to the source code resulting in a test failure as a function of input change characteristic variables associated with a particular change based on historical relationships with the change characteristics associated with historical changes in the corresponding test results." (See paragraph [0025] of Majithia.) Majithia's risk scores are based on change characteristics (e.g., code complexity metrics, lines of code, nested loops, etc.) and historical correlations - not on relevance to a specific current test case failure as Applicant recites. Applicant's recited invention is a fundamentally different approach that generates faulty code change scores for the multiple code changes based on relevance to the test case failure.
Examiner’s Response:
The Examiner respectfully disagrees. Majithia discloses that “a risk score is assigned to each change associated with the update, which, in turn, may be utilized to identify which change is the most likely root cause of the failure of a particular test.” (see Paragraph 11) This disclosure can be reasonably interpreted as the Applicant’s claim language of “generating faulty code change scores for the multiple code changes based on relevance to the test case failure”. The risk score is used to identify which change is the most likely root cause of a failure which can be reasonably interpreted as “relevance to the test case failure”. The higher the risk score, the more “relevant” it is to the identified failure.
In the Remarks, Applicant argues:
Further, Applicant respectfully submits that a careful reading of Cmielowski and Thakkar fails to uncover any teaching or suggestion of the above-noted deficiencies of Majithia when applied against the claims presented herewith. As such, Applicant respectfully submits that claim 1 presented herewith is patentable. Independent claims 10 & 17 recite similar features to those discussed above in connection with claim 1, and as such, are believed allowable for at least the reasons noted above as well.
The dependent claims are believed allowable for same reasons as the respective independent claims, as well as for their own additional characterizations.
Examiner’s Response:
Please see response to arguments above with respect to claim 1.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LANNY N UNG whose telephone number is (571)270-7708. The examiner can normally be reached Mon-Thurs 6am-4pm.
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, Bradley Teets can be reached at 571-272-3338. 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.
/LANNY N UNG/Examiner, Art Unit 2197
Prosecution Insights