DETAILED ACTION
Claims 1, 3, 5, 6 and 13, 14 and 16-18 are pending. Claims 1, 3, 5, 6, 13, 14 and 16 have been amended. Claims 4 and 15 have been cancelled. Claim 18 is new.
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 02/10/2026, for the final office action mailed on 08/20/2025.
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 02/10/2026 regarding rejection made under 35 U.S.C. § 101 have been fully considered and examiner respectfully withdraws rejections made in view of applicant’s amendments and remarks.
Applicant's arguments filed 02/10/2026 regarding rejection made under 35 U.S.C. § 103 have been fully considered but are not persuasive.
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.
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 resource matrix wherein each test resource is represented as a one hot vector (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 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 Rauenzhan 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 Rauenzhan 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 Rauenzhan 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 Rauenzhan 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 Rauenzhan’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.”
As per claim 3, Sarar modified with Ruaenzhan 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) and Rauenzahn (US-PGPUB-NO: 2017/0351598 A1), in further view of Bassin et al. (US-PGPUB-NO: 2016/0154728 A1) hereinafter Bassin.
As per claim 5, Sarar modified with Rauenzhan 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, Rauenzhan 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 and Rauenzhan’s teaching of optimization for regression tracking and triaging in software testing 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) and Rauenzahn (US-PGPUB-NO: 2017/0351598 A1), in further view of Bhide et al. (US-PGPUB-NO: 2013/0041613 A1) hereinafter Bhide.
As per claim 6, Sarar modified with Rauenzhan 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, Rauenzhan 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 and Rauenzhan’s teaching of optimization for regression tracking and triaging in software testing 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) and Rauenzahn (US-PGPUB-NO: 2017/0351598 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 Rauenzhan 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 Rauenzhan 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 Rauenzhan 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 Rauenzhan 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 Rauenzhan’s teaching of optimization for regression tracking and triaging in software testing to incorporate selection of tests in order to minimize testing time, see Rauenzhan 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 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, Rauenzhan 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 and 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