Detailed Action
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Applicants have filed a formal response dated April 17th, 2026 in response to the February 4th, 2026 Office Action provided in the rejection of claims 1-14, 17-21 and 25.
Status of Claims
2. Claims 1-27 are pending in the application, of which claims 1 and 17 are in independent form and these claims (1-14, 17-21 and 25) are subject to following rejection(s) and/or objection(s) set forth in the following Office Action below.
Response to the Amendments
3. (A). Regarding subject matter eligibility rejection: Due to Applicant's amendment to the initially pending claims previously applied rejection to the claim 25 under 35 U.S.C. § 101 has been withdrawn.
(B). Regarding art rejection: In regards to claims 1-20 Applicants arguments are not persuasive; further, Applicants' amendment necessitated same grounds; however, modified version of rejections presented in the following art rejection.
(C). Finality: Applicant's arguments filed April 17th, 2026 have been fully considered but they are not persuasive. THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Claim Rejections – 35 USC §103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
4. Claims 1-8, 14, 17-19 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Knaack et al. (US Patent Application Publication No. 2020/0285570 A1 -herein after Knaack) in view of Meng Li (US Patent Application Publication No. 2008/0295043 A1 herein after Li).
Per claim 1:
Knaack discloses:
An apparatus for generating a test specification for testing software code of a function under test (At least see ¶[0011] - a test automation system (“TAS”) for validation of software-under-test (“SUT”) using machine-generated programmatic tests), the apparatus comprising interface circuitry and processing circuitry to:
extract a plurality of symbols from the software code of the function under test (At least see ¶[0013] -self-description 130 may include function names, function arguments, arguments types (function symbol), and/or other data related to the declaration of SUT 110 functions …source code [emphasis added]);
generate a plurality of test vectors with corresponding sets of expected results for the function under test based on the plurality of symbols (At least see ¶[0056] -TAS 120 may convert test cases 540 into executable code that is used to call the particular function with a different input combination specified for each test case 540. Results 550 may include the output of each test case 540 and/or status of each test case 540. A successful or unsuccessful status may be derived from comparing the output from each function call to the expected output for the return argument; also refer back ¶[0013]); and
generate a test specification based on the plurality of test vectors and the corresponding sets of expected results (At least see ¶[0011] -generating the different sets of test cases … convert the test cases into executable code that can be used to call the SUT functions with different inputs, and may determine results for each test case based on the outputs of the SUT functions).
Knaack sufficiently discloses the apparatus as set forth above, but Knaack does not explicitly disclose: determine a test coverage based on the plurality of test vectors, identify a coverage gap in the test coverage, and provide information for addressing the coverage gap.
However, Li discloses:
determine a test coverage based on the plurality of test vectors (At least see ¶[0029] - identify a test vector that may execute the specific section of the model. In one or more embodiments, test cases generated with test case module 107 may be applied to the design model 108, and analyzed for structural coverage with the structural coverage analysis model), identify a coverage gap in the test coverage (At least see ¶[0029] - identify gaps in test coverage of the requirements based test cases executed on the design mode), and provide information for addressing the coverage gap (At least see ¶[0029] in the case of derived requirements … test cases may be automatically generated with the model coverage test case module 110 to satisfy structural coverage [emphasis added]).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Li into Knaack’s invention because to guide the test generation process by selecting appropriate test methods/modules best-suited for the model, so that the tests are generated more effectively and efficiently; as such, selecting the best-suited test module/method based on the identity of the model is that there may be no need to include a time consuming trial and error process, and the analysis of the model may only be performed once, which may also save time (please see ¶[0022]).
Per claim 2:
Knaack discloses:
identify one or more branch symbols and one or more condition symbols among the plurality of symbols, and to generate the plurality of test vectors based on branching outcomes of the one or more branch symbols and/or based on condition outcomes of the one or more condition symbols (At least see ¶[0063] -conditional statement as part of expected output 230 for a function entry. The conditional statement may be specified as an “if-then-else” condition with expected output 230 specified for the conditional statement).
Per claim 3:
Knaack discloses:
plurality of symbols are extracted from an output of a compiler for compiling the software code of the function under test (At least see ¶[0077] - Code generator 680 may execute the converted code in order to call one or more of the SUT 110 functions with the different input combinations specified by the test cases. Code generator 680 may compile the outputs from each function call).
Per claim 4:
Knaack discloses:
wherein each set of expected results comprises one or more of an expected invocation of one or more functions, an expected memory layout, an expected return value of the function under test, and an expected impact of the function under test on global memory or an external resource (At least see ¶[0059] - data may alternatively be the result of an operation that is executed by SUT 110 in response to a function call. SUT 110 may retain the operation result in memory or other storage [emphasis added]).
Per claim 5:
Knaack discloses:
include one or more of information on one or more dummy functions representing the one or more functions, information on the expected memory layout, information on the expected return value of the function under test, and information on the expected impact of the function under test on the global memory or the external resource in the test specification (At least see ¶[0020] Each function declaration 210 may contain the definition of a different SUT 110 function. For instance, each function declaration 210 may include one or more of the name and/or interface for calling a function, and/or the function parameters. The function parameters may include the arguments (e.g., the names of each function input), the type of each function argument, and/or other data. The argument type may correspond to predefined types (e.g., integer, floating point value, Boolean, string, etc.) of an underlying programming language used in writing SUT 110, and/or custom types that are unique to SUT 110 and that may be user-defined).
Per claim 6:
Knaack discloses:
expected memory layout is based on one or more local variables and/or memory structures included in the software code (At least see ¶[0023] - programming language used to code SUT 110 may predefine the valid ranges, strings, values, regular expressions, enumerations, and/or other data (thus, SUT instruction contain local variable within the memory structure of the SUT instruction) for a particular argument or argument type [emphasis added]).
Per claim 7:
Knaack discloses:
each set of expected results comprises an expected invocation of one or more functions, wherein the processing circuitry is to generate information on one or more dummy functions representing the one or more functions, the information on the one or more dummy functions comprising information on a return value and an expected impact on global memory or an external resource of the respective one or more dummy functions and, if more than one dummy function is generated, information on a sequence of invocation of the dummy functions, and to include the information on the one or more dummy functions in the test specification (At least see ¶[0047] - AS 120 may use a crawler to periodically or continuously monitor SUT 110 for new function declarations and/or changes to existing function declarations. In response to detecting a new function declaration, TAS 120, by operation of the crawler, may extract the arguments and argument types from the function declaration. Additionally, TAS 120, by operation of the crawler, may identify test inputs for each argument and/or argument type based on predefined inputs for predefined and/or user-defined argument types. TAS 120 may also obtain self-description 130 via a self-description interface that allows a developer and/or tester to manually enter the SUT 110 functions for testing (dummy function). In some embodiments, TAS 120 may automatically populate self-description 130 with the functions, function arguments, and argument types of SUT 110, and a user, via the self-description interface, may provide test inputs and/or expected outputs for each function [emphasis added]; also see ¶[0059]).
Per claim 8:
Knaack discloses:
test specification comprises a specification of a plurality of unit tests that are based on the plurality of test vectors and the plurality of expected results (At least see ¶[0044] TAS 120 may issue API calls and/or execute the test case code in order to test different functions of SUT 110 with different inputs. TAS 120 may capture output of each test case, and may compare the captured output against expected output).
Per claim 14:
Knaack discloses:
execute unit tests corresponding to the plurality of test vectors based on the test specification (At least see ¶[0048] - SUT 110 may transition from a unit test phase, to an integration test phase, to a regression test phase, to an acceptance test phase, and different test methodologies may be used during one or more of these different test phases).
Per claim 17:
Knaack discloses:
A method for generating a test specification for testing software code of a function under test (At least see Knaack claim 15. A method comprising: scanning a software-under-test (“SUT”); detecting one or more functions of the SUT in response to the scanning; generating a self-description based on a declaration of each of the one or more functions of the SUT), the method comprising:
extracting a plurality of symbols from the software code of the function under test (At least see ¶[0013] -self-description 130 may include function names, function arguments, arguments types (function symbol), and/or other data related to the declaration of SUT 110 functions …source code [emphasis added]);
generating a plurality of test vectors with corresponding sets of expected results for the function under test based on the plurality of symbols (At least see ¶[0056] -TAS 120 may convert test cases 540 into executable code that is used to call the particular function with a different input combination specified for each test case 540. Results 550 may include the output of each test case 540 and/or status of each test case 540. A successful or unsuccessful status may be derived from comparing the output from each function call to the expected output for the return argument; also refer back ¶[0013]); and
generating a test specification based on the plurality of test vectors and the corresponding sets of expected results (At least see ¶[0011] -generating the different sets of test cases … convert the test cases into executable code that can be used to call the SUT functions with different inputs, and may determine results for each test case based on the outputs of the SUT functions).
Knaack sufficiently discloses the method as set forth above, but Knaack does not explicitly disclose: determine a test coverage based on the plurality of test vectors, identify a coverage gap in the test coverage, and provide information for addressing the coverage gap.
However, Li discloses:
determine a test coverage based on the plurality of test vectors (At least see ¶[0029] - identify a test vector that may execute the specific section of the model. In one or more embodiments, test cases generated with test case module 107 may be applied to the design model 108, and analyzed for structural coverage with the structural coverage analysis model), identify a coverage gap in the test coverage (At least see ¶[0029] - identify gaps in test coverage of the requirements based test cases executed on the design mode), and provide information for addressing the coverage gap (At least see ¶[0029] in the case of derived requirements … test cases may be automatically generated with the model coverage test case module 110 to satisfy structural coverage [emphasis added]).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Li into Knaack’s invention because to guide the test generation process by selecting appropriate test methods/modules best-suited for the model, so that the tests are generated more effectively and efficiently; as such, selecting the best-suited test module/method based on the identity of the model is that there may be no need to include a time consuming trial and error process, and the analysis of the model may only be performed once, which may also save time (please see ¶[0022]).
Per claim 18:
Knaack discloses:
identifying one or more branch symbols and one or more condition symbols among the plurality of symbols, and to generate the plurality of test vectors based on branching outcomes of the one or more branch symbols and/or based on condition outcomes of the one or more condition symbols (At least see ¶[0063] -conditional statement as part of expected output 230 for a function entry. The conditional statement may be specified as an “if-then-else” condition with expected output 230 specified for the conditional statement).
Per claim 19:
Knaack discloses:
each set of expected results comprises an expected invocation of one or more functions, wherein the processing circuitry is to generate information on one or more dummy functions representing the one or more functions, the information on the one or more dummy functions comprising information on a return value and an expected impact on global memory or an external resource of the respective one or more dummy functions and, if more than one dummy function is generated, information on a sequence of invocation of the dummy functions, and to include the information on the one or more dummy functions in the test specification (At least see ¶[0047] - AS 120 may use a crawler to periodically or continuously monitor SUT 110 for new function declarations and/or changes to existing function declarations. In response to detecting a new function declaration, TAS 120, by operation of the crawler, may extract the arguments and argument types from the function declaration. Additionally, TAS 120, by operation of the crawler, may identify test inputs for each argument and/or argument type based on predefined inputs for predefined and/or user-defined argument types. TAS 120 may also obtain self-description 130 via a self-description interface that allows a developer and/or tester to manually enter the SUT 110 functions for testing (dummy function). In some embodiments, TAS 120 may automatically populate self-description 130 with the functions, function arguments, and argument types of SUT 110, and a user, via the self-description interface, may provide test inputs and/or expected outputs for each function [emphasis added]; also see ¶[0059]).
Per claim 25:
Knaack discloses:
A machine-readable storage medium including program code, when executed, to cause a machine to perform the method of claim 17 (At least see ¶[0083] - Device 700 may perform these operations in response to processor 720 executing software instructions stored in a computer-readable medium, such as memory 730. A computer-readable medium may be defined as a non-transitory memory device).
5. Claims 9 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Knaack et al. (US Patent Application Publication No. 2020/0285570 A1 -herein after Knaack) in view of Meng Li (US Patent Application Publication No. 2008/0295043 A1 herein after Li), and further in view of Chang et al. (US Patent Application Publication No. 2008/0295043 A1 herein after Chang).
Per claim 9:
Knaack modified by Li sufficiently discloses the system as set forth above, but Knaack modified by Li does not explicitly disclose: recursively traverse the symbols of the plurality of symbols to generate the plurality of test vectors.
However, Chang discloses:
recursively traverse the symbols of the plurality of symbols to generate the plurality of test vectors (At least see ¶[0056] - algorithm shown in FIG. 5, a symbol is initially created for each select variable (line 1). During the simulation, a new symbol is created for each free variable in every cycle, and test vectors are applied to primary inputs).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Chang into Knaack modified by Li’s invention because reason for creating only one symbol for each select variable is that a conditional assignment should be either activated or inactivated throughout the entire simulation, while each free variable requires a new symbol at every cycle because the value of the variable may change; whereas, symbols for the select variables are assigned outside the simulation loop, while the symbols for the free variables are assigned in the loop, and the values of the free variables can be used as the alternative signal source to produce the correct behavior of the circuit; and moreover, after simulating one cycle, a Boolean expression for all of the primary outputs are created and saved, and after the simulation completes, the generated Boolean expressions for all the primary outputs are constrained by their respective correct output values (please see ¶[0056]).
Per claim 20:
Knaack modified by Li sufficiently discloses the system as set forth above, but Knaack modified by Li does not explicitly disclose: recursively traverse the symbols of the plurality of symbols to generate the plurality of test vectors.
However, Chang discloses:
recursively traverse the symbols of the plurality of symbols to generate the plurality of test vectors (At least see ¶[0056] - algorithm shown in FIG. 5, a symbol is initially created for each select variable (line 1). During the simulation, a new symbol is created for each free variable in every cycle, and test vectors are applied to primary inputs).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Chang into Knaack modified by Li’s invention because reason for creating only one symbol for each select variable is that a conditional assignment should be either activated or inactivated throughout the entire simulation, while each free variable requires a new symbol at every cycle because the value of the variable may change; whereas, symbols for the select variables are assigned outside the simulation loop, while the symbols for the free variables are assigned in the loop, and the values of the free variables can be used as the alternative signal source to produce the correct behavior of the circuit; and moreover, after simulating one cycle, a Boolean expression for all of the primary outputs are created and saved, and after the simulation completes, the generated Boolean expressions for all the primary outputs are constrained by their respective correct output values (please see ¶[0056]).
6. Claims 10-13 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Knaack et al. in view of Meng Li, and Chang et al., further in view of Hicks et al. (US Patent Application Publication No. 2020/0242013 A1 herein after Hicks).
Per claim 10:
Knaack modified by Chang and Li discloses the system depicted claim 9 above, but Knaack modified by Chang and Li does not explicitly disclose: determine the test coverage of the plurality of test vectors while traversing the symbols, and to identify the coverage gap in the test coverage.
However, Hicks discloses:
determine the test coverage of the plurality of test vectors while traversing the symbols, and to identify the coverage gap in the test coverage (At least see ¶[0004] - operations include modeling inputs to the SUT as a plurality of attributes, where each attribute is eligible to take on a respective one or more attribute values and generating multiple sets of test vectors, where each set of test vectors provides a desired amount of coverage of a test space that includes all possible combinations of attribute values).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Hicks into Knaack modified by Chang and Li’s invention because technical solutions to which are described, which would provide a testing methodology that seeks to increase test space coverage for a System Under Test (SUT) through the use of automated algorithms to identify input patterns that are most likely to locate problems in the SUT, thereby reducing the amount of time required for a tester to build test cases and an automation framework. CTD is well-adapted for projects that require numerous variations on static input vectors to properly test various system states and logic pathways, which would otherwise be extremely cumbersome for a human tester (please see ¶[0002]).
Per claim 11:
Knaack discloses:
generate code for addressing the coverage gap of the test coverage and to integrate the code for addressing the gap of the test coverage gap in the software code (At least see ¶[0014] - selected test methodology may define the coverage and/or scope for each set of test cases 140. More specifically, the selected test methodology determines the input combinations that will be used to test a particular function).
Per claim 12:
Knaack discloses:
provide information for addressing the coverage gap of the test coverage in the software code or for customizing the coverage (At least ¶[0011] - TAS may modify the test coverage by generating the different sets of test cases according to one or more test methodologies (e.g., non-combinatorial, combinatorial, pairwise, and/or other testing of the SUT). The TAS may convert the test cases into executable code that can be used to call the SUT functions with different inputs, and may determine results for each test case based on the outputs of the SUT functions).
Per claim 13:
Knaack discloses:
provide the information for addressing the coverage gap of the test coverage as part of a code advisor for guiding a user on how to address the coverage gap of the test coverage (At least see ¶[0013] - TAS 120 may provide a self-description interface that allows a user (e.g., developer or tester) to manually define and/or modify self-description).
Per claim 21:
Knaack modified by Chang and Li discloses the system depicted claim 9 above, but Knaack modified by Chang and Li does not explicitly disclose: determining a test coverage of the plurality of test vectors while traversing the symbols, and to identifying a coverage gap in the test coverage.
However, Hicks discloses:
determining the test coverage of the plurality of test vectors while traversing the symbols, and to identifying the coverage gap in the test coverage (At least see ¶[0004] - operations include modeling inputs to the SUT as a plurality of attributes, where each attribute is eligible to take on a respective one or more attribute values and generating multiple sets of test vectors, where each set of test vectors provides a desired amount of coverage of a test space that includes all possible combinations of attribute values).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Hicks into Knaack modified by Chang and Li’s invention because technical solutions to which are described, which would provide a testing methodology that seeks to increase test space coverage for a System Under Test (SUT) through the use of automated algorithms to identify input patterns that are most likely to locate problems in the SUT, thereby reducing the amount of time required for a tester to build test cases and an automation framework. CTD is well-adapted for projects that require numerous variations on static input vectors to properly test various system states and logic pathways, which would otherwise be extremely cumbersome for a human tester (please see ¶[0002]).
CONCLUSION
7. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZIAUL A. CHOWDHURY whose telephone number is (571)270-7750. The examiner can normally be reached on 9:30PM 6:30PM Monday -Friday.
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.
Status information for published applications may be obtained from Patent Public Search tool (for all users) – A link to the Patent Public Search Tool is available at www. Uspto.gov/PatentPublicSearch. To find a U.S. patent or U.S. patent application publication, open the Patent Public Search tool by selecting “Start search”. Type the U.S. patent or U.S. patent application publication number in the “Search” panel without any punctuation and followed by an”.pn.”.
Should you have questions on access to the system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ZIAUL A CHOWDHURY/ Primary Examiner, Art Unit 2192
06/16/2026
Prosecution Insights