CTNF 18/733,416 CTNF 83062 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This action is responsive to the application filed June 04, 2024 and preliminary amendment filed June 07, 2024, which claims 11, 14, and 20 have been amended. Thus, claims 1-20 are pending and are presenting for examination. Examiner Notes Examiner cites particular columns 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 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. 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 5. 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. 6. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Independent Claims 1,11, and 20 recite: A method for selecting test cases, comprising: [a] acquiring a pull request for a code change ; [b] generating one or more change representations of the code change based on the pull request of the code change, wherein the change representation at least comprises a file name, a function name, and a code line which are associated with the code change; and [c] selecting one or more test cases for testing the code change from a test case library based on the one or more change representations of the code change. The claims 1,11, and 20 recite the limitation of: [b] generating one or more change representations of the code change based on the pull request of the code change, wherein the change representation at least comprises a file name, a function name, and a code line which are associated with the code change; and [c] selecting one or more test cases for testing the code change from a test case library based on the one or more change representations of the code change. These limitations of steps [b] and [c] as draft, 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. Step 2A – Prong 2: Under Prong 2, this judicial exception is not integrated into a practical application. The claims recite the following additional elements: “ An electronic device, comprising: a processor; and a memory coupled to the processor processing unit and having instructions stored therein that, when executed by the processor, cause the processor to perform following actions”, and “ A non-volatile computer-readable medium having machine- executable instructions stored therein, which when executed by a processor, cause the processor to perform the following actions ” merely recite instructions to implement an abstract idea on a generic computer, or merely use a generic computer or computer components as a tool to perform the abstract idea, thus is not a practical application under Prong 2. See MPEP 2106.05(f). Furthermore, the additional limitation of step [a] “acquiring a pull request for a code change ” do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering data. 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). Step 2B: 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 “ An electronic device, comprising: a processor; and a memory coupled to the processor processing unit and having instructions stored therein that, when executed by the processor, cause the processor to perform following actions”, and “ A non-volatile computer-readable medium having machine- executable instructions stored therein, which when executed by a processor, cause the processor to perform the following actions ” amount to no more than mere instructions, or generic computer/computer components to carry out the exception, for the limitations and for the limitation of step [a] “acquiring a pull request for a code change ” , the courts have identified mere data gathering, transmitting, and displaying are well-understood, routine and conventional activity. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 USC 101. Regarding to per claims 2 and 12, the limitation, “wherein selecting the one or more test cases from the test case library comprises: generating one or more query statements based on the one or more change representations; and selecting the one or more test cases from the test case library based on the one or more query statements” recites further mental process. Accordingly, the claims are not patent eligible under 35 USC 101. Regarding to per claims 3 and 13, the limitation, “further comprising: generating a code analysis report for each test case in a test case set; generating a test case representation for each test case in the test case set based on the code analysis report, wherein the code analysis report comprises a file name, a function name, and a code line which are associated with the test case; and constructing the test case library that stores the test case set based on the test case representation” recites further mental process. Accordingly, the claims are not patent eligible under 35 USC 101. Regarding to per claims 4 and 14, the limitation, “further comprising: generating test case categories for the one or more test cases; determining a file number corresponding to the code change based on the test case categories; and determining a change level for indicating the size of the code change based on the file number and a predetermined threshold” recites further mental process. Accordingly, the claims are not patent eligible under 35 USC 101. Regarding to per claims 5 and 15, the limitation, “wherein generating the test case categories for the one or more test cases comprises: generating the test case categories for the one or more test cases based on the one or more file names” recites further mental process and the additional element of “ acquiring one or more file names corresponding to the one or more test cases ”, which is nothing more than insignificant extra solution activity of gathering data which is not a practical application under prong 2. Under step 2B, the courts have identified mere data gathering, transmitting, and displaying are well-understood, routine and conventional activity. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 USC 101. Regarding to per claims 6 and 16, the limitation, “wherein generating the one or more change representations of the code change comprises: determining the change type of the code change; and determining the change representation of the code change based on the change type” recites further mental process. Accordingly, the claims are not patent eligible under 35 USC 101. Regarding to per claims 7 and 17, the limitation, “wherein determining the change representation of the code change comprises: determining, in response to the change type being a line addition type, the change representation based on the line before and the line after the newly added line; determining, in response to the change type being a segment deletion type, the change representation based on the plurality of code lines corresponding to the deleted code segment; and determining, in response to the change type being a segment modification type, the change representation based on the plurality of code lines corresponding to the modified code segment” recites further mental process. Accordingly, the claims are not patent eligible under 35 USC 101. Regarding to per claims 8 and 18, the limitation, “wherein determining the change representation of the code change further comprises: determining, in response to the change type being a function addition type, the change representation based on the file name corresponding to the newly added function; determining, in response to the change type being a function deletion type, the change representation based on the function name of the deleted function; and determining, in response to the change type being a file deletion type, the change representation based on the file name of the deleted file” recites further mental process. Accordingly, the claims are not patent eligible under 35 USC 101. Regarding to per claims 9 and 19, the limitation, “further comprising: constructing a testing environment for running a test case list based on a change version of the code change, wherein the test case list comprises the selected one or more test cases” recites further mental process and the additional element of “running each test case in the test case list” does not require any particular application of the recited evaluation and is at best the equivalent of merely “apply it” to the judicial exception. Mere instructions to apply an exception cannot provide an inventive concept. Therefore, this additional element does not integrate the judicial exception into a practical application. See MPEP 2106.05(f). Accordingly, the claims are not patent eligible under 35 USC 101. Regarding to claim 10, the limitation, “further comprising: generating a running log for each test case and determining the test result of the code change by analyzing the running log” recites further mental process and the additional element of “ by running each test case in the test case list ” does not require any particular application of the recited evaluation and is at best the equivalent of merely “apply it” to the judicial exception. Mere instructions to apply an exception cannot provide an inventive concept. Therefore, this additional element does not integrate the judicial exception into a practical application. See MPEP 2106.05(f). Accordingly, the claim is not patent eligible under 35 USC 101. Claim Rejections - 35 USC § 102 07-07-aia AIA 07-07 7. 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 – 07-12-aia AIA (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. 07-15 AIA 8. Claim s 1, 2, 9, 11, 12, 19, and 20 are rejected under 35 U.S.C. 102( 2 ) as being anticipated by Jain et al. (US 20240020219 A1, hereinafter Jain) . As per claims 1, 11, and 20, Jain discloses a method for selecting test cases, comprising: acquiring a pull request for a code change – (e.g., “ code change determiner 340 receives (via path 121) an input data indicating the set of files/components changed in the software application from a user (such as a developer, tester, administrator, etc.) using one of end-user systems 110”– see at least 0053, “the software application code forming the software application (or components thereof) deployed in server systems 160 may be changed/modified . Such changes/modifications typically require the software application to be re-tested ” – see at least 0031, “Test case identifier 350 identifies a set of test cases that cause execution of the (changed) components …testing server 170, which in turn runs the identified set of test cases and perform the re-testing of the software application” see at least 0054, Fig. 1-6D and associated text); generating one or more change representations of the code change based on the pull request of the code change, wherein the change representation at least comprises a file name, a function name, and a code line which are associated with the code change – (e.g., In step 611, code change determiner 340 reads the changes to the software application code specified in a transaction received (as input data) from a user. The transaction may be received from one of end-user systems 110. An example transaction that may be received from the user is shown in FIG. 6B. In step 612, code change determiner 340 parses the transaction (and the software application code) to find the Java class and the corresponding changed Java method (the changed component) as shown in FIG. 6C, and forwards the details of the changed component to test case identifier 340…The scenario w hen an input data indicating other changed components of the software application is received from a user is shown in 480 . The input of 480 indicates that in addition to ApplicationClass2.Method3 (the input of 450), the component ApplicationClass4.Method1 has also been change d. – see at least 0064, 0080-0081, Figs. 6A-6B, and associated text) ; and selecting one or more test cases for testing the code change from a test case library based on the one or more change representations of the code change – (e.g., In step 613, test case identifier 340 queries the DB (database) relation table storin g the dependency data (of FIG. 5F) with the Java class and the corresponding changed method . The query is directed to DB 52 5, the database storing the dependency data of FIG. 5F. In step 614, based on the query, test case identifier 340 identifies the result list with all the test cases which need to be run for the transaction chang e. Thus, test case identifier 340 performs a reverse look-up of the changed component against the dependency data stored in dependent data store 330. An output of the reverse look-up for the changed component of FIG. 6C is shown in FIG. 6D. From the output, it may be appreciated that test case “Bug21251801TestCase” has to be run for re-testing the software application in view of the change made to the “SnpMapping” class of the software application – see at least 0083, 0041, 0054, Fig. 6A-6B, and associated text). Further regarding to claim 11, Jain discloses an electronic device (e.g., Digital processing system 700 – see at least 0087-0094, Fig. 7, and associated text) , comprising: a p rocessor; and a memory coupled to the processor and having instructions stored therein that, when executed by the processor, cause the processor to perform method steps as of claim 1 above. Further regarding to claim 20, Jain discloses a non-volatile computer-readable medium (e.g., removable storage unit 740 – see at least 0093, Fig. 7 and associated text) having machine executable instructions stored therein, which when executed by a processor, cause the processor to perform method steps as of claim 1 above. As per claims 2 and 12 , Jain discloses wherein selecting the one or more test cases from the test case library comprises: generating one or more query statements based on the one or more change representations; and selecting the one or more test cases from the test case library based on the one or more query statements -- (e.g., In step 613, test case identifier 340 queries the DB (database) relation table storin g the dependency data (of FIG. 5F) with the Java class and the corresponding changed method . The query is directed to DB 52 5, the database storing the dependency data of FIG. 5F. In step 614, based on the query, test case identifier 340 identifies the result list with all the test cases which need to be run for the transaction chang e. Thus, test case identifier 340 performs a reverse look-up of the changed component against the dependency data stored in dependent data store 330. An output of the reverse look-up for the changed component of FIG. 6C is shown in FIG. 6D. From the output, it may be appreciated that test case “Bug21251801TestCase” has to be run for re-testing the software application in view of the change made to the “SnpMapping” class of the software application – see at least 0083, 0041, 0054, Fig. 6A-6B, and associated text). As per claims 9 and 19 , Jain discloses further comprising: constructing a testing environment for running a test case list based on a change version of the code change, wherein the test case list comprises the selected one or more test cases; and running each test case in the test case list– (e.g., In step 613, test case identifier 340 queries the DB (database) relation table storin g the dependency data (of FIG. 5F) with the Java class and the corresponding changed method . The query is directed to DB 52 5, the database storing the dependency data of FIG. 5F. In step 614, based on the query, test case identifier 340 identifies the result list with all the test cases which need to be run for the transaction chang e. Thus, test case identifier 340 performs a reverse look-up of the changed component against the dependency data stored in dependent data store 330. An output of the reverse look-up for the changed component of FIG. 6C is shown in FIG. 6D. From the output, it may be appreciated that test case “Bug21251801TestCase” has to be run for re-testing the software application in view of the change made to the “SnpMapping” class of the software application – see at least 0083, 0041, 0054, Fig. 6A-6B, and associated text) . Claim Rejections - 35 USC § 103 07-20-aia AIA 9. 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. 07-21-aia AIA 10. Claims 3-8, 10, and 1 3-18 are rejected u nder 35 U.S.C. 103 as being unpatentable over Jain in vie w of Pearson et al. (US 12072790 B1, hereinafter Pearson). As per clai ms 3 and 13 , it is to note that while Jain discloses further comprising: generating report for each test case in a test case set – (E.g., An input and output of TCF 150 is shown in 450. .., while the output of 450 indicates t he set of test cases identified by test case iden tifier 350 by performing a reverse look-up of the changed component against the dependency data of data portion 440…, the output of 450 is shown containing the set {TestCase-1-3, TestCase-2-1}. The output of 450 may then be included in the test cases to be run for re-testing software application 41 0. – see Jain, at least 0065, Fig. 4B, and associated text); but does not explicitly disclose; however, Pearson, in an analogous art, discloses generating a code analysis report for each test case in a test case set – (e.g., the test results analyzer 124 may instruct the test selector 112 to i ncrease the size of the subset and/or use other techniques or criteria to determine a different subset of tests associated with the code integration request 108 . In other instances, a relatively poor-quality test subset may be a function of the quality (e.g., test coverage) of the test suite as a whole, in which case the test results analyzer 124 may output errors and/or recommendations to the development and/or test team to revise the test suite to kill a higher percentage of mutated applications, and thereby detect a wider range of errors or other issues associated with the application … the test results analyzer 124 m ay receive and aggregate the results of the mutation testing from the mutation test engine 106, and may determine which test ca ses associate … with the particular portion of the source code mutated in operation 502. The mutation test system 104 may determine a subset of the application test suite associated with the source code changes—see at least col. 10: 18-44, col. 16: 24-35, Fig. 1, Fig. 5, step 608 of Fig. 6 and associated text); generating a test case representation for each test case in the test case set based on the code analysis report, wherein the code analysis report comprises a file name, a function name, and a code line which are associated with the test case – (e.g., the test selector 112 may use a mapping component 114 in some instances, t o determine a set of test cases associated with the modified and/or affected source cod e . The mapping component 114 may store and maintain a set of mappings between subsets of tests and corresponding portions of the application source code . The associations between subsets of tests and portions of source code may mapped to various different levels of granularity, including the class level, function level, or source code line leve l. The mapping component 114 may use one or combination of various techniques to determine associations between the portions of the source code and test subsets – see at least col. 7: 26-49); and constructing the test case library that stores the test case set based on the test case representation -- (e.g., T he test suite data store 122 may store the tests themselves, including automated unit tests and/or integration tests designed to test one or more functionalities of the application. E ach test in the test suite data store 122 may be a test function, test file, and/or data embodying a particular test case designed by the application development or t esting team. In some instances, the test suite data store 122 may store associations between individual tests and classes, functions, and/or other portions of the source code, such as code coverage data associated with the test. – see at least col.8: 36-35). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Pearson’s teaching into Jain’s teaching for further optimizing and maintaining the continuing of integration of modified code; accordingly, promoting efficiencies and avoiding delaying in testing modified codes for application development process as seen in Pearson (e.g., col. 2: 52-67). As per claims 4 and 14 , modified Jain with Pearson discloses further comprising: generating test case categories for the one or more test cases -- (e.g., T he test suite data store 122 may store the tests themselves, including automated unit tests and/or integration tests designed to test one or more functionalities of the application. E ach test in the test suite data store 122 may be a test function, test file, and/or data embodying a particular test case designed by the application development or t esting team. In some instances, the test suite data store 122 may store associations between individual tests and classes, functions, and/or other portions of the source code, such as code coverage data associated with the test. – see Pearson, at least col.8: 36-35 ; determining a file number corresponding to the code change based on the test case categories – (e.g., in some cases, the mutation rules 118 may be a predetermined and common set of mutation rules associated with the mutation test system 104 and/or mutation test engine 106. In other examples, the mutation rules 118 may include different mutation rules associated with different applications, developers, CI/CD systems, and/or different attributes of the source code changes (e.g., the number of changes , types of changes, etc. —see Pearson, at least col. 11: 24-35,) ; and determining a change level for indicating the size of the code change based on the file number and a predetermined threshold – (e.g., The test selector 112 may be configured to determine a subset (or multiple subsets) of the application test suites to be executed during the mutation testing, based on the portions of source code associated with the source code integration request 108 …the test selector 112 may use a mapping component 114 in some instances, to determine a set of test cases associated with the modified and/or affected source code. The mapping component 114 may store and maintain a set of mappings between subsets of tests and corresponding portions of the application source code. The associations between subsets of tests and portions of source code may mapped to various different levels of granularity, including the class level, function level, or source code line le vel… the evaluation of the mutation test results in operation 614 may involve evaluating multiple mutated applications and/or multiple result s from individual test cases, after which the determination in operation 614 may be performed usi ng one or more thresholds . when the mutation test system 104 determines that the mutation test coverage for the requested source code change is sufficient – see Pearson, at least col. 7: 26-42, Fig. 6, and associated text). As per claims 5 and 15 , modified Jain with Pearson discloses wherein generating the test case categories for the one or more test cases comprises: acquiring one or more file names corresponding to the one or more test cases; and generating the test case categories for the one or more test cases based on the one or more file names -- (e.g., the test selector 112 may use a mapping component 114 in some instances, t o determine a set of test cases associated with the modified and/or affected source cod e . The mapping component 114 may store and maintain a set of mappings between subsets of tests and corresponding portions of the application source code . The associations between subsets of tests and portions of source code may mapped to various different levels of granularity, including the class level, function level, or source code line leve l. The mapping component 114 may use one or combination of various techniques to determine associations between the portions of the source code and test subsets – see Pearson, at least col. 7: 26-49) . As per claims 6 and 16 , it is to note that while Jain discloses generating one or more change representations of the code change based on the pull request of the code change, wherein the change representation at least comprises a file name, a function name, and a code line which are associated with the code change – (e.g., In step 611, code change determiner 340 reads the changes to the software application code specified in a transaction received (as input data) from a user. The transaction may be received from one of end-user systems 110. An example transaction that may be received from the user is shown in FIG. 6B. In step 612, code change determiner 340 parses the transaction (and the software application code) to find the Java class and the corresponding changed Java method (the changed component) as shown in FIG. 6C, and forwards the details of the changed component to test case identifier 340…The scenario w hen an input data indicating other changed components of the software application is received from a user is shown in 480 . The input of 480 indicates that in addition to ApplicationClass2.Method3 (the input of 450), the component ApplicationClass4.Method1 has also been change d. – see Jain, at least 0064, 0080-0081, Figs. 6A-6B, and associated text) but does not explicitly disclose; however, Pearson, in an analogous art, discloses wherein generating the one or more change representations of the code change comprises: determining the change type of the code change; and determining the change representation of the code change based on the change type— (e.g., a mutation test system 104 may create and use association tables, such as table 300, which maintain mappings between portions of the application source code and test subsets. In this example, table 300 supports mappings between application classes, functions, and/or lines of source code, and corresponding subsets of test cases…in some cases, the mutation rules 118 may be a predetermined and common set of mutation rules associated with the mutation test system 104 and/o r mutation test engine 10 6. In other examples, the mutation rules 118 may include different mutation rules associated with different applications, developers, CI/CD systems, and/or different attributes of the source code changes (e.g., the number of changes , types of changes, etc. —see Pearson, at least col. 5: 55-66 , col. 11: 24-35, Fig. 1, and associated text) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Pearson’s teaching into Jain’s teaching for further optimizing and maintaining the continuing of integration of modified code; accordingly, promoting efficiencies and avoiding delaying in testing modified codes for application development process as seen in Pearson (e.g., col. 2: 52-67). As per claims 7 and 17 , modified Jain with Pearson discloses wherein determining the change representation of the code change comprises: determining, in response to the change type being a line addition type, the change representation based on the line before and the line after the newly added line; determining, in response to the change type being a segment deletion type, the change representation based on the plurality of code lines corresponding to the deleted code segment; and determining, in response to the change type being a segment modification type, the change representation based on the plurality of code lines corresponding to the modified code segment —(e.g., a mutation test system 104 may create and use association tables, such as table 300, which maintain mappings between portions of the application source code and test subsets. In this example, table 300 supports mappings between application classes, functions, and/or lines of source code, and corresponding subsets of test cases…in some cases, the mutation rules 118 may be a predetermined and common set of mutation rules associated with the mutation test system 104 and/o r mutation test engine 10 6. In other examples, the mutation rules 118 may include different mutation rules associated with different applications, developers, CI/CD systems, and/or different attributes of the source code changes (e.g., the number of changes , types of changes, etc. various different techniques may be used for mutating a fragment of source code associated with (e.g., directly modified or otherwise affected by) a source code change from a developer. In various examples, the mutation test system 104 may mutate source code by replacing an operator with a different operator within a program statement, inserting a new operator into a program statement, replacing an operand (e.g., variable or constant value) with a different operand in a program statement. In other examples, the mutation test system 10 4 may modify, add, or remove portions of a program statement in order to mutate a source code fragmen t —see Pearson, at least col. 5: 55-66 , col. 11: 12-35, Fig. 1, and associated text) . As per claims 8 and 18 , modified Jain with Pearson discloses wherein determining the change representation of the code change further comprises: determining, in response to the change type being a function addition type, the change representation based on the file name corresponding to the newly added function; determining, in response to the change type being a function deletion type, the change representation based on the function name of the deleted function; and determining, in response to the change type being a file deletion type, the change representation based on the file name of the deleted file —(e.g., a mutation test system 104 may create and use association tables, such as table 300, which maintain mappings between portions of the application source code and test subsets. In this example, table 300 supports mappings between application classes, functions, and/or lines of source code, and corresponding subsets of test cases…in some cases, the mutation rules 118 may be a predetermined and common set of mutation rules associated with the mutation test system 104 and/o r mutation test engine 10 6. In other examples, the mutation rules 118 may include different mutation rules associated with different applications, developers, CI/CD systems, and/or different attributes of the source code changes (e.g., the number of changes , types of changes, etc. various different techniques may be used for mutating a fragment of source code associated with (e.g., directly modified or otherwise affected by) a source code change from a developer. In various examples, the mutation test system 104 may mutate source code by replacing an operator with a different operator within a program statement, inserting a new operator into a program statement, replacing an operand (e.g., variable or constant value) with a different operand in a program statement. In other examples, the mutation test system 10 4 may modify, add, or remove portions of a program statement in order to mutate a source code fragmen t —see Pearson, at least col. 5: 55-66 , col. 11: 12-35, Fig. 1, and associated text) . As to claim 10 , it is to note that Jain does not explicitly disclose, but Pearson, in an analogous art, discloses further comprising: generating a running log for each test case by running each test case in the test case list; and determining the test result of the code change by analyzing the running log – (e.g., the test resul ts analyzer 124 may receive and aggregate the results of the mutation testing performed by the mutation test engine 106 . For example, for a single mutated application the test results analyzer 124 may determine a number and/or a percentage of the tests within the determined test subset that cause t he mutated application to be killed. When multiple mutated applications are generated and tested, the test results analyzer 124 may determine the number or percentage of the mutated applications that were killed by running the subset of tests. As noted above, larger numbers or percentages of the mutated applications that are killed may indicate that the subset of tests used in the mutation killing is of a relatively higher quality, while smaller numbers or percentages of the mutated applications that are killed may indicate that the subset of tests is of a relatively lower quality—see Pearson, at least col. 10: 26- 44, Fig. 1, and associated text). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Pearson’s teaching into Jain’s teaching for further optimizing and maintaining the continuing of integration of modified code; accordingly, promoting efficiencies and avoiding delaying in testing modified codes for application development process as seen in Pearson (e.g., col. 2: 52-67). Conclusion 11. The prior art made of record and not relied upon (cited on 892 form) is considered pertinent to application disclosure. Dutta et al. (US-11734159-B2) disclosed ranking test cases related to changes in a software code base. Michelsen (US-8146057-B1) disclosed testing software via instrumentation. 12. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARINA LEE whose telephone number is (571)270-1648. The examiner can normally be reached Monday to Friday (8 am to 4: 30 pm ET). 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 on (571)-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /MARINA LEE/Primary Examiner, Art Unit 2192 Application/Control Number: 18/733,416 Page 2 Art Unit: 2192 Application/Control Number: 18/733,416 Page 3 Art Unit: 2192 Application/Control Number: 18/733,416 Page 4 Art Unit: 2192 Application/Control Number: 18/733,416 Page 5 Art Unit: 2192 Application/Control Number: 18/733,416 Page 6 Art Unit: 2192 Application/Control Number: 18/733,416 Page 7 Art Unit: 2192 Application/Control Number: 18/733,416 Page 8 Art Unit: 2192 Application/Control Number: 18/733,416 Page 9 Art Unit: 2192 Application/Control Number: 18/733,416 Page 10 Art Unit: 2192 Application/Control Number: 18/733,416 Page 11 Art Unit: 2192 Application/Control Number: 18/733,416 Page 12 Art Unit: 2192 Application/Control Number: 18/733,416 Page 13 Art Unit: 2192 Application/Control Number: 18/733,416 Page 14 Art Unit: 2192 Application/Control Number: 18/733,416 Page 15 Art Unit: 2192 Application/Control Number: 18/733,416 Page 16 Art Unit: 2192 Application/Control Number: 18/733,416 Page 17 Art Unit: 2192 Application/Control Number: 18/733,416 Page 18 Art Unit: 2192 Application/Control Number: 18/733,416 Page 19 Art Unit: 2192 Application/Control Number: 18/733,416 Page 20 Art Unit: 2192 Application/Control Number: 18/733,416 Page 21 Art Unit: 2192 Application/Control Number: 18/733,416 Page 22 Art Unit: 2192
Prosecution Insights