Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This is the initial office action based on the application filed on December 19th, 2023, which claim 1-14, 17-21 and 25 have been presented for examination.
Status of Claims
Claims 1-14, 17-21 and 25 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.
Examiner Notes
(A). Information Disclosure Statement (IDS): The information disclosure statements filed on 12/19/2023 comply with the provisions of 37 CFR 1.97, 1.98. They have been placed in the application file and the information referred to therein has been considered as to the merits.
(B). Priority: Effective filing date considered for the following office action is 10/15/2021.
Claim Rejections – 35 USC §101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 25 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter. Claim 25 is directed to “machine-readable storage medium”. However, the specification does not exclude signals/electromagnetic waves from the machine-readable storage medium. Therefore, based on the broadest reasonable interpretation, the claimed machine-readable medium includes signals/electromagnetic waves which are not patent eligible subject matters.
Claim Rejections – 35 USC §102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-8, 14, 17-19 and 25 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Knaack et al. (US Patent Application Publication No. 2020/0285570 A1 -herein after Knaack).
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).
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).
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).
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.
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 Chang et al. (US Patent Application Publication No. 2008/0295043 A1 herein after Chang).
Per claim 9:
Knaack sufficiently discloses the system as set forth above, but Knaack 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’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 sufficiently discloses the system as set forth above, but Knaack 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’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]).
Claims 10-13 and 21 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 Chang et al. (US Patent Application Publication No. 2008/0295043 A1 herein after Chang), 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 discloses the system depicted claim 9 above, but Knaack modified by Chang does not explicitly disclose: determine a test coverage of the plurality of test vectors while traversing the symbols, and to identify a coverage gap in the test coverage.
However, Hicks discloses:
determine a test coverage of the plurality of test vectors while traversing the symbols, and to identify a 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’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 gap of the test coverage and to integrate the code for addressing the gap of the test coverage 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 gap of the test coverage in the software code or by 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 gap of the test coverage as part of a code advisor for guiding a user on how to address the 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 discloses the system depicted claim 9 above, but Knaack modified by Chang 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 a test coverage of the plurality of test vectors while traversing the symbols, and to identifying a 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’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
The prior art made of record and have yet relied upon is considered pertinent to applicant's disclosure, and will be frequently referred as to support the responses to the Applicant’s arguments, See MPEP § 707.05 For Examples:
I. Scott Thomson (US 20180373620 A1) discloses “identify one or more elements of input data. The input data can comprise test data that can comprise respective identifications of an input variable, an output variable, a test vector comprising an initial value of a test input, and an expected output variable against which test results can be compared”(please see ¶[0008]).
II. Kita et al. (US 6038378 A) discloses “generating validation tests for implementations of a program specification for an operating system, software application or a machine, where the program specification is expressed at least in part in terms of data structures and relationships … Each validation test includes a call to the implementation of the program specification, and presents that implementation with a test vector representing a given path through the model. Failure and success responses are produced, indicating whether the implementation behaved as expected. Multiple validation tests may be linked or combined in a variety of ways to form a superstructure (architecture) of validation tests for testing of many routines in conjunction with one another, such as for testing all the routines specified for an operating system at the same time”(please see Specification). Kita also discloses “compiler doing the parsing uses the BNF listing for the language in which the program specification was written (here, applicant's ISL), along with annotations and other definitions that the compiler needs, including definitions of objects which are to be referenced, definitions of symbols which are used, input/output functions”(please see Col. 10:7-13), and “Appended after this are the statements specified in Section IV.B.5, so that the end of the path file reads:
f ! (result == 0)
test.sub.-- result = 1
verify.sub.-- failure ("result == 0");
Since the expected result is zero (in the path 1), if the result does not equal zero, then the test failure flag "test.sub.-- result" is set to 1” (please see Col. 36:45-56).
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
01/31/2026