DETAILED ACTION
Claims 1, 3, 5, 6 and 13, 14 and 16-18 are pending.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This non-final office action is in response to the applicant’s response received on 07/06/2026, for the non-final office action mailed on 05/14/2026.
Examiner’s Notes
Examiner has cited particular columns and line numbers, paragraph numbers, or figures 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 from the applicant, in preparing the 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 passage as taught by the prior art or disclosed by the examiner.
Response to Arguments
Applicant's arguments filed 07/06/2026 regarding rejection made under 35 U.S.C. § 103 have been fully considered but are not persuasive.
Applicant argues Sarar doesn’t teach the recited one-hot vector testing resource matrix, see applicant’s remarks pp. 7-8. Examiner respectfully disagrees as new art is cited teaches one-hot vector matrix. Regarding Sarar, the prior art teaches smooth labeling which is a regularization of one-hot encoding that can produce better outcomes than absolute 1 or 0.
Applicant further argues Rauenzahn does not teach physical shared testing resources, see applicant’s remarks pp. 8-9. Examiner respectfully disagrees as Rauenzahn teaches the testbeds being independent computer (i.e., physical resource), see Rauenzahn paragraph [0015], “In some embodiments, the test scheduler 120 may control the build engine 125 and the test engine 140 to perform automated testing of the software application. Based on the test scheduler 120's instruction, the test engine 140 may configure multiple testbeds (e.g., Testbed 151, Testbed 153, and Testbed 155) for testing the different revisions of the software application in parallel. A “testbed” (or “test bed”) may be an independent or isolated platform/environment for executing and repeating a test case against a particular revision of the software application. For example, a testbed may be an independent computer (or a sub-directory under a computer) having necessary hardware/software configurations for building and executing the software application. In a specific testbed, the test scheduler 120 may schedule a specific test case to be executed on a specific revision of the software application. The test scheduler 120 may simultaneously schedule multiple different test cases in these testbeds, or schedule the same test case to be executed in-parallel in these testbeds against different revisions of the software application.”
Applicant also argues neither Sarar nor Rauenzahn teaches “greater coverage time interval than the full set,” see applicant’s remarks pp. 9. Examiner respectfully disagrees as both Sarar and Rauenzahn optimizes the testing being done in which results in achieving greater coverage for the testing being conducted.
Applicant argues the combination of Sarar and Rauenzahn lacks the requisite articulated reasoning, see applicant’s remarks pp. 9-10. Examiner respectfully disagrees Sarar’s teaching of testing integrated circuit designs by generating a coverage matrix associated with a plurality of test cases with Rauenzahn’s teaching of optimization for regression tracking and triaging in software testing to incorporate selection of tests in order to minimize testing time, see Rauenzahn paragraph [0002], “Optimizations to methods and systems to provide regression tracking and triaging are described. An automated system for regression tracking and triaging may rely on the use of binary searches to identify a revision that causes a regression. The depth of binary searches can be minimized by using equidistant revisions in the tracking process. In case of multiple parallel tracking processes, optimizing the selection of builds across the multiple equidistant revision ranges involved for re-use will yield significant savings in the number of builds required. In case of complex software applications with long build times, the pre-fetching of builds during a binary search process may significantly reduce the time of the process to complete.”
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3, 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Sarar (US-PGPUB-NO: 2024/0320408 A1), in further view of Rauenzahn et al. (US-PGPUB-NO: 2017/0351598 A1) hereinafter Rauenzahn and Hermanns et al. (US-PGPUB-NO: 2023/0267073 A1) hereinafter Hermanns.
As per claim 1, Sarar teaches a method for testing information handling system software, the method comprising: identifying, by a processor, trace points, test cases, and test resources for testing the software (see Sarar paragraph [0023], “Testing system 120 generally executes the test cases 110 to verify the performance and functionality of the integrated circuit design under test. In some aspects, testing system 120 can monitor and generate information such as the coverage points which are tested (or “hit”) during execution of each test case in the universe of test cases 110 defined for the design of the integrated circuit”); performing a full test of the software to obtain test coverage information (see Sarar paragraph [0021], “For a given integrated circuit design, the plurality of test cases 110 can be defined (e.g., generated or at least designed by a test engineer). These test cases 110 may include test cases to test the functionality of an integrated circuit against a defined specification, which may define the correctness of outputs, timing constraints within the integrated circuit, and other functional and/or performance characteristics of the integrated circuit. These test cases may also include functional test cases to determine whether an integrated circuit accurately performs a given operation, process-voltage-temperature (PVT) test cases for the integrated circuit design, and the like.”), and test duration information for each test case-test (TCTR) tuple, (see Sarar paragraph [0021], “In some aspects, the functional test cases may further include timing-related criteria, such as a target elapsed time for performing the test (plus or minus a threshold amount of time)”), wherein performing the full test includes: (see Sarar paragraph [0021], “If the integrated circuit (or portion thereof) performs the test on the correct side of the threshold amount of the target elapsed time, then the integrated circuit may be deemed to have passed the test; otherwise, the integrated circuit may have performed the test more slowly or more quickly than expected and may thus be deemed to have failed the test”); defining a test coverage matrix indicating whether each test run reached each trace point (see Sarar paragraph [0027], A represents a coverage matrix (e.g., matrix 210 illustrated in FIG. 2 and described in further detail below) illustrating the probabilities of each coverage point being hit by executing a given test case, defined as a binomial distribution, and w.sub.i is the test seed count (e.g., a number of times a test is executed using test inputs with values generated from a random source created using different seed values) for the i.sup.th test case of the N test cases 110”); calculating a coverage score for each TCTR tuple based on the testing resource matric and test coverage matrix (see Sarar paragraph [0042], “Generally, larger weight values for a given test case j correspond to a higher likelihood that the test case will be selected for inclusion in the selected test case list (e.g., because the test case hits a large number of coverage points at a low computational expense), while smaller weight values correspond to a lower likelihood that the test case will be selected for inclusion in the selected test case list (e.g., because the test case hits a small number of coverage points at a high computational expense). An expected coverage matrix may be generated based on the expected coverage 330 calculated for each coverage point given the test cases identified based on the weights 320 associated with the test cases in the selected set of test cases”); determining optimized TCTR tuples by selecting TCTR tuples that maximize test coverage for a specified maximum test duration or minimize test duration for a specified minimum test coverage (see Sarar paragraph [0034], “Test case list 220 represents the optimized (or reduced) test case list that is to be generated based on the weights assigned to each test case in a machine learning model, as discussed above. Generally, the test list may include, for each test case, a seed count associated with a weight assigned to each test. In this example, a test may have a seed count of 1, indicating that the test will be included in the optimized (or reduced) test case list for use in testing the integrated circuit design (e.g., in an EDA tool), or a seed count of 0, indicating that the test will not be included in the optimized (or reduced) test case list and will thus not be executed on the integrated circuit design (e.g., because the test would test coverage points already covered by executing other tests)”, showing how the reduced test will have greater coverage as some test would have tested coverage points that have been covered already by other tests that will be executed).
Sarar does not explicitly teach wherein the test resources comprise a plurality of testbeds and at least one shared testing resource communicatively coupled to at least two of the plurality of testbeds; periodically performing a selective regression test using the optimized TCTR tuples, wherein the selective regression test achieves greater coverage per time interval than the full test. However, Rauenzahn teaches wherein the test resources comprise a plurality of testbeds and at least one shared testing resource communicatively coupled to at least two of the plurality of testbeds (see Rauenzahn paragraph [0026], “In other words, a build created for a revision with number that is dividable by a common factor of 12 may be shared by the first testing task in Testbed 1 and the second testing task in Testbed 2. While the build engine 125 may pipeline builds to reduce wait time and the test engine 140 may perform parallel testing to increase speed, sharing the builds when possible may further enhance the utilization the resources of the automated testing environment 110”); periodically (see Rauenzahn paragraph [0001], “In automated software testing, identifying software regressions typically involves the running of one or more test cases periodically against a set of builds created from the “Top-of-Tree” (ToT) revisions in a source code repository”) performing a selective regression test using the optimized TCTR tuples (see Rauenzahn paragraph [0052], “During a subsequent iteration of binary search, the triaging engine may select one of the two builds for usage, depending on whether the testing indicates a regression situation or a pass situation”), wherein the selective regression test achieves greater coverage per time interval than the full test (see Rauenzahn paragraph [0068], “In some embodiments, the test engine may identify a tuple of candidate revisions corresponding to the scheduled revision from the first list of equidistant revisions for having equidistances that are below the predetermined threshold. In other words, each candidate revision in the tuple of candidate revisions may have a corresponding equidistance from the scheduled revisions that is below the predetermined threshold. Afterward, the test engine may select the list of optimal revisions from the tuple of candidate revisions and the second list of equidistant revisions. Specifically, the test engine may construct a Cartesian product having multiple permutations based on the tuples of candidate revisions and the second list of equidistant revisions. The test engine may then select the list of optimal revisions from the multiple permutations for having the least variance from the equidistance associated with the second list of equidistant revisions”).
Sarar and Rauenzahn are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Sarar’s teaching of testing integrated circuit designs by generating a coverage matrix associated with a plurality of test cases with Rauenzahn’s teaching of optimization for regression tracking and triaging in software testing to incorporate selection of tests in order to minimize testing time, see Ruaenzhan paragraph [0002], “Optimizations to methods and systems to provide regression tracking and triaging are described. An automated system for regression tracking and triaging may rely on the use of binary searches to identify a revision that causes a regression. The depth of binary searches can be minimized by using equidistant revisions in the tracking process. In case of multiple parallel tracking processes, optimizing the selection of builds across the multiple equidistant revision ranges involved for re-use will yield significant savings in the number of builds required. In case of complex software applications with long build times, the pre-fetching of builds during a binary search process may significantly reduce the time of the process to complete.”
Sarar modified with Rauenzahn do not explicitly teach defining a test resource matrix wherein each test resource is represented as a one hot vector. However Hermanns teaches defining a test resource matrix wherein each test resource is represented as a one hot vector (see Hermanns paragraph [0085], “The model is trained in a supervised manner such that it yields one output vector V.sub.O per training vector V.sub.T. FIG. 5 illustrates an example of a set of three output vectors V.sub.O for the three training vectors V.sub.T of FIG. 6. In FIG. 6, the three output vectors V.sub.O are arranged in the form of a matrix 600 representing three one hot vectors denoted (1; 0; 0) for T.sub.1, (0; 1; 0) for T.sub.2 and (0; 0; 1) for T.sub.3. The dimension of each output vector V.sub.O thus corresponds to the number of test cases T.sub.i (here: 3)”).
Sarar, Rauenzahn and Hermanns are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Sarar’s teaching of testing integrated circuit designs by generating a coverage matrix associated with a plurality of test cases and Rauenzahn’s teaching of optimization for regression tracking and triaging in software testing with Hermanns’ teaching of machine-learning based software testing techniques to incorporate a matrix representing a dimension of one hot vectors to provide test cases with values of potential for the software modules, see Hermanns paragraph [0097], “In a further step 426, one or more test cases for testing the new software module release are determined based on the trained model and the input vector V.sub.I as determined in step 424. The result of the correlation in step 426, i.e., has the dimension of the one hot vectors illustrated in FIG. 6 and provides for each test case T.sub.i a numerical value, or weight, indicative of the test case's potential to yield a meaningful response to the specific software module modifications in the new release (i.e., to detect a failure upon test case execution). In some variants, each numerical value ranges between 0 and 1, see the matrix 800 of FIG. 10. The closer the numerical value is to 1, the more suitable the associated test case T.sub.i is for software testing.”
As per claim 3, Sarar modified with Rauenzahn and Hermanns teaches wherein determining the optimized TCTR tuples includes: defining matrix representations of the testing resources, the test coverage, and the test duration (see Sarar paragraph [0033], “As illustrated, coverage matrix 210 is a two-dimensional matrix in which each row represents a coverage bin and each column represents a test case from a universe of test cases (e.g., test cases 110 illustrated in FIG. 1). For each combination of test case and coverage bin, a probability that the test will hit (or test) a particular coverage point may be calculated based on historical test case execution data”).
As per claims 13 and 14, these are the non-transitory computer readable medium claims to method claims 1 and 3, respectively. Therefore, they are rejected for the same reasons as above.
Claim(s) 5 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Sarar (US-PGPUB-NO: 2024/0320408 A1), Rauenzahn (US-PGPUB-NO: 2017/0351598 A1) and Hermanns (US-PGPUB-NO: 2023/0267073 A1), in further view of Bassin et al. (US-PGPUB-NO: 2016/0154728 A1) hereinafter Bassin.
As per claim 5, Sarar modified with Rauenzahn do not explicitly teach wherein determining the optimized TCTR tuples includes determining TCTR tuples that produce the highest coverage score for a specified maximum duration. However, Bassin teaches wherein determining the optimized TCTR tuples includes determining TCTR tuples that produce the highest coverage score for a specified maximum duration (see Bassin paragraph [0090], “In accordance with further aspects of the invention, a test case is represented by “t” and may be a triple in which t=(av, et, trigger, ev, esd, status), where “av” indicates an attributes vector (e.g., knowledge required, test language required, etc.), “et” indicates an estimated time duration for testing this test case, “trigger” is the trigger type, “ev” indicates the environment required, “esd” (estimated defect) represents the estimated defect number of the test by leveraging best practices and/or an applicable reference project (as described above), and “status” is a vector, e.g., (start time, end time, tester/workload, defects revealed, and execution status), indicating the testing status of the test case”).
Sarar, Rauenzahn, Hermanns and Bassin are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Sarar’s teaching of testing integrated circuit designs by generating a coverage matrix associated with a plurality of test cases, Rauenzahn’s teaching of optimization for regression tracking and triaging in software testing and Hermanns’ teaching of machine-learning based software testing techniques with Bassin’s teaching of resource modeling and simulation for test planning to incorporate leveraging best practices to achieve best testing.
As per claim 16, this is the non-transitory computer readable medium claim to method claim 5. Therefore, it is rejected for the same reasons as above.
Claim(s) 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Sarar (US-PGPUB-NO: 2024/0320408 A1), Rauenzahn (US-PGPUB-NO: 2017/0351598 A1) and Hermanns (US-PGPUB-NO: 2023/0267073 A1), in further view of Bhide et al. (US-PGPUB-NO: 2013/0041613 A1) hereinafter Bhide.
As per claim 6, Sarar modified with Rauenzahn and Hermanns do not explicitly teach wherein determining the optimized TCTR tuples include determining TCTR tuples producing the lowest test duration for specified minimum test coverage. However, Bhide teaches wherein determining the optimized TCTR tuples include determining TCTR tuples producing the lowest test duration for specified minimum test coverage (see Bhide paragraph [0060], “The selection module 505 receives a maximum time for executing a plurality of test cases 105. The selection module 505 further selects a first test case 105a of the plurality of test cases 105 with a specified priority 205 selected iteratively from a highest priority to a lowest priority as a selected test case if combined expected time durations 215 for all previously selected test cases and a minimum expected time duration of the first test case 105a is less than the maximum time”).
Sarar, Rauenzahn, Hermanns and Bhide are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Sarar’s teaching of testing integrated circuit designs by generating a coverage matrix associated with a plurality of test cases, Rauenzahn’s teaching of optimization for regression tracking and triaging in software testing and Hermanns’ teaching of machine-learning based software testing techniques with Bhide’s teaching of generating test suites using maximum time to execute test cases to incorporate determining based on time and testing optimized test cases to use for testing resources.
As per claim 17, this is the non-transitory computer readable medium claim to method claim 6. Therefore, it is rejected for the same reasons as above.
Claim(s) 18 is rejected under 35 U.S.C. 103 as being unpatentable over Sarar (US-PGPUB-NO: 2024/0320408 A1), Rauenzahn (US-PGPUB-NO: 2017/0351598 A1) and Hermanns (US-PGPUB-NO: 2023/0267073 A1), in further view of Dzoba et al. (US-PGPUB-NO: 2002/0004933 A1) hereinafter Dzoba.
As per claim 18, Sarar teaches a method for testing information handling system software, the method comprising: identifying, by a processor, trace points, test cases, and test resources for testing the software (see Sarar paragraph [0023], “Testing system 120 generally executes the test cases 110 to verify the performance and functionality of the integrated circuit design under test. In some aspects, testing system 120 can monitor and generate information such as the coverage points which are tested (or “hit”) during execution of each test case in the universe of test cases 110 defined for the design of the integrated circuit”); performing a full test of the software to obtain test information including test coverage information indicative of trace points reached by each test case (see Sarar paragraph [0021], “For a given integrated circuit design, the plurality of test cases 110 can be defined (e.g., generated or at least designed by a test engineer). These test cases 110 may include test cases to test the functionality of an integrated circuit against a defined specification, which may define the correctness of outputs, timing constraints within the integrated circuit, and other functional and/or performance characteristics of the integrated circuit. These test cases may also include functional test cases to determine whether an integrated circuit accurately performs a given operation, process-voltage-temperature (PVT) test cases for the integrated circuit design, and the like.”), and test duration information indicative of time required to perform each test case, wherein the full test includes performing each test case on each test resource (see Sarar paragraph [0021], “In some aspects, the functional test cases may further include timing-related criteria, such as a target elapsed time for performing the test (plus or minus a threshold amount of time)”), wherein performing the full test includes determining a coverage score and a test duration for each test case-test resource (TCTR) tuple by: (see Sarar paragraph [0021], “If the integrated circuit (or portion thereof) performs the test on the correct side of the threshold amount of the target elapsed time, then the integrated circuit may be deemed to have passed the test; otherwise, the integrated circuit may have performed the test more slowly or more quickly than expected and may thus be deemed to have failed the test”); defining a test resource matrix wherein each test resource is represented as a one hot vector indicating whether a particular testing resource was used during a particular run (see Sarar paragraph [0030], “In some aspects, the cost vector can be regularized based on the computation expense of the most expensive test case to execute on the integrated circuit. A regularized cost vector may thus include a value of 1 for the cost of the most expensive test case and values less than 1 for the cost of each of the other test cases, with the value a for each test case being scaled relative to the cost of the most expensive test case. For example, if a given test case has a runtime that is one-fourth that of the most expensive test case, then the value of a for the given test case in the cost vector may be 0.25”); defining a test coverage matrix indicating whether each element indicates whether a particular test run reached a particular trace point (see Sarar paragraph [0027], A represents a coverage matrix (e.g., matrix 210 illustrated in FIG. 2 and described in further detail below) illustrating the probabilities of each coverage point being hit by executing a given test case, defined as a binomial distribution, and w.sub.i is the test seed count (e.g., a number of times a test is executed using test inputs with values generated from a random source created using different seed values) for the i.sup.th test case of the N test cases 110”); calculating, based on the testing resource matrix and the test coverage matrix, a coverage score for each TCTR tuple according to a test coverage equation (see Sarar paragraph [0042], “Generally, larger weight values for a given test case j correspond to a higher likelihood that the test case will be selected for inclusion in the selected test case list (e.g., because the test case hits a large number of coverage points at a low computational expense), while smaller weight values correspond to a lower likelihood that the test case will be selected for inclusion in the selected test case list (e.g., because the test case hits a small number of coverage points at a high computational expense). An expected coverage matrix may be generated based on the expected coverage 330 calculated for each coverage point given the test cases identified based on the weights 320 associated with the test cases in the selected set of test cases”); determining, based on the test information including the coverage scores and test duration, optimized TCTR tuples for efficiently testing the software by selecting TCTR tuples that maximize test coverage for a specified maximum test duration or minimize test duration for a specified minimum test coverage (see Sarar paragraph [0034], “Test case list 220 represents the optimized (or reduced) test case list that is to be generated based on the weights assigned to each test case in a machine learning model, as discussed above. Generally, the test list may include, for each test case, a seed count associated with a weight assigned to each test. In this example, a test may have a seed count of 1, indicating that the test will be included in the optimized (or reduced) test case list for use in testing the integrated circuit design (e.g., in an EDA tool), or a seed count of 0, indicating that the test will not be included in the optimized (or reduced) test case list and will thus not be executed on the integrated circuit design (e.g., because the test would test coverage points already covered by executing other tests)”, showing how the reduced test will have greater coverage as some test would have tested coverage points that have been covered already by other tests that will be executed).
Sarar does not explicitly teach wherein the test resources comprise a plurality of testbeds and at least one shared testing resource communicatively coupled to at least two of the plurality of testbeds; wherein the selective regression test achieves greater coverage per time interval than the full test; periodically performing a selective regression test using the optimized TCTR tuples. However, Rauenzahn teaches wherein the test resources comprise a plurality of testbeds and at least one shared testing resource communicatively coupled to at least two of the plurality of testbeds (see Rauenzahn paragraph [0026], “In other words, a build created for a revision with number that is dividable by a common factor of 12 may be shared by the first testing task in Testbed 1 and the second testing task in Testbed 2. While the build engine 125 may pipeline builds to reduce wait time and the test engine 140 may perform parallel testing to increase speed, sharing the builds when possible may further enhance the utilization the resources of the automated testing environment 110”); wherein the selective regression test achieves greater coverage per time interval than the full test (see Rauenzahn paragraph [0068], “In some embodiments, the test engine may identify a tuple of candidate revisions corresponding to the scheduled revision from the first list of equidistant revisions for having equidistances that are below the predetermined threshold. In other words, each candidate revision in the tuple of candidate revisions may have a corresponding equidistance from the scheduled revisions that is below the predetermined threshold. Afterward, the test engine may select the list of optimal revisions from the tuple of candidate revisions and the second list of equidistant revisions. Specifically, the test engine may construct a Cartesian product having multiple permutations based on the tuples of candidate revisions and the second list of equidistant revisions. The test engine may then select the list of optimal revisions from the multiple permutations for having the least variance from the equidistance associated with the second list of equidistant revisions”); periodically (see Rauenzahn paragraph [0001], “In automated software testing, identifying software regressions typically involves the running of one or more test cases periodically against a set of builds created from the “Top-of-Tree” (ToT) revisions in a source code repository”) performing a selective regression test using the optimized TCTR tuples, wherein the selective regression test includes test case and test resource combinations in accordance with the optimized TCTR tuples (see Rauenzahn paragraph [0052], “During a subsequent iteration of binary search, the triaging engine may select one of the two builds for usage, depending on whether the testing indicates a regression situation or a pass situation”).
Sarar and Rauenzahn are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Sarar’s teaching of testing integrated circuit designs by generating a coverage matrix associated with a plurality of test cases with Rauenzahn’s teaching of optimization for regression tracking and triaging in software testing to incorporate selection of tests in order to minimize testing time, see Rauenzahn paragraph [0002], “Optimizations to methods and systems to provide regression tracking and triaging are described. An automated system for regression tracking and triaging may rely on the use of binary searches to identify a revision that causes a regression. The depth of binary searches can be minimized by using equidistant revisions in the tracking process. In case of multiple parallel tracking processes, optimizing the selection of builds across the multiple equidistant revision ranges involved for re-use will yield significant savings in the number of builds required. In case of complex software applications with long build times, the pre-fetching of builds during a binary search process may significantly reduce the time of the process to complete.”
Sarar modified with Rauenzahn do not explicitly teach defining a test resource matrix wherein each test resource is represented as a one hot vector. However Hermanns teaches defining a test resource matrix wherein each test resource is represented as a one hot vector (see Hermanns paragraph [0085], “The model is trained in a supervised manner such that it yields one output vector V.sub.O per training vector V.sub.T. FIG. 5 illustrates an example of a set of three output vectors V.sub.O for the three training vectors V.sub.T of FIG. 6. In FIG. 6, the three output vectors V.sub.O are arranged in the form of a matrix 600 representing three one hot vectors denoted (1; 0; 0) for T.sub.1, (0; 1; 0) for T.sub.2 and (0; 0; 1) for T.sub.3. The dimension of each output vector V.sub.O thus corresponds to the number of test cases T.sub.i (here: 3)”).
Sarar, Rauenzahn and Hermanns are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Sarar’s teaching of testing integrated circuit designs by generating a coverage matrix associated with a plurality of test cases and Rauenzahn’s teaching of optimization for regression tracking and triaging in software testing with Hermanns’ teaching of machine-learning based software testing techniques to incorporate a matrix representing a dimension of one hot vectors to provide test cases with values of potential for the software modules, see Hermanns paragraph [0097], “In a further step 426, one or more test cases for testing the new software module release are determined based on the trained model and the input vector V.sub.I as determined in step 424. The result of the correlation in step 426, i.e., has the dimension of the one hot vectors illustrated in FIG. 6 and provides for each test case T.sub.i a numerical value, or weight, indicative of the test case's potential to yield a meaningful response to the specific software module modifications in the new release (i.e., to detect a failure upon test case execution). In some variants, each numerical value ranges between 0 and 1, see the matrix 800 of FIG. 10. The closer the numerical value is to 1, the more suitable the associated test case T.sub.i is for software testing.”
Sarar modified with Rauenzahn and Hermanns do not explicitly teach the at least one shared testing resource comprising at least one of a preboot execution environment (PXE) server, an Intel debug toolkit (IDT), an oscilloscope, or a test chamber. However, Dzoba teaches the at least one shared testing resource comprising at least one of a preboot execution environment (PXE) server, an Intel debug toolkit (IDT), an oscilloscope, or a test chamber (see Dzoba paragraph [0130], “For example, other operating capabilities of various hardware resources of a test bed system can be included in a debug component database and used by the software to configure the test bed system. These hardware resources can be logic analyzers, signal generators, oscilloscopes, etc., for example”).
Sarar, Rauenzahn, Hermanns and Dzoba are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Sarar’s teaching of testing integrated circuit designs by generating a coverage matrix associated with a plurality of test cases, Rauenzahn’s teaching of optimization for regression tracking and triaging in software testing and Hermanns’ teaching of machine-learning based software testing techniques with Dzoba’s teaching of configurable debug system with dynamic menus to incorporate selection of resources to use for testing in order to properly test the functions needed for the relevant resource.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ryszka et al. (US-PGPUB-NO: 2024/0256432 A1) teaches generating tests of a machine learning engine, determining a feature space of the set of configuration parameters of at least part of initial test cases of the ML engine.
Sharma et al. (US-PGPUB-NO: 2023/0251960 A1) teaches machine learning techniques for automated software testing configuration management.
Zhang et al. (“A Test Design and Coverage Measurement Method for Equipment Software System Testing”, 2022) teaches system testing for testing different software quality characteristics.
Lui et al. (US-PGPUB-NO: 2017/0046245 A1) teaches recommending regression tests.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LENIN PAULINO whose telephone number is (571)270-1734. The examiner can normally be reached Week 1: Mon-Thu 7:30am - 5:00pm Week 2: Mon-Thu 7:30am - 5:00pm and Fri 7:30am - 4:00pm EST.
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 on (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.
/LENIN PAULINO/Examiner, Art Unit 2197
Prosecution Insights