DETAILED ACTION
This action is responsive to the application filed on June 27, 2024.
Claims 1-20 are pending and presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their 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.
Foreign Priority
The foreign priority date considered for this application is March 26, 2024.
Drawings
The drawings filed on June 27, 2024 are acceptable for examination purposes.
Specification
The disclosure is objected to because of the following informalities: The specification does not contain the CROSS-REFERENCE TO RELATED APPLICATIONS area. Appropriate correction is required.
Claim Objections
Claims 1-20 are objected to because of the following informalities: Claim 1 (and similar for claims 19-20) recites the limitation “generating, by the command coverage assessment system, a command coverage report using a command tree map, based on the at least one test case log, wherein the method is implemented by at least one processing device comprising a processor coupled to a memory.” in lines 5-7. Claim 3 (and similar for claims 5 and 13) recites “the at least one test log.”. It should have been “the at least one test case log”. Claim 3 recites “wherein parsing, by the covered commands pool module, comprises: obtaining, by the covered commands pool module, a plurality of covered commands and a covered command count associated with each of the respective plurality of covered commands, wherein the covered command count indicates a total occurrence of each of the respective plurality of covered commands in the at least one test log.”. Appropriate correction is required. Please amend the claim language as suggested in bold. Claim 12 recites “wherein the child node comprises a hit ratio associated with a command executed during the execution of the at least one test case.”.
Dependent claims 2, 4-11 and 13-18 do not overcome the deficiency of the base claim and, therefore, are objected for the same reasons as the base claim.
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.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 1-18 are directed to methods and fall within the statutory category of processes; Claim 19 is directed to a system and fall within the statutory category of machines; and Claim 20 is directed to a medium and fall withing the statutory category of manufactures. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claims 1 and 19-20 as drafted, recite a process that, under its broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitations: a) “obtaining, ” – Mental processes (see MPEP 2106.04(a)(2), III), this limitation can be performed by a human using pen and paper, for example, a tester could write down which commands they ran during testing.
b) “generating” – Mental processes (see MPEP 2106.04(a)(2), III), this limitation can be performed by a human mind or using pen and paper, for example, a person can generate a report from other data (e.g., a command tree map and a log). There is not recitation how the tree ma is built, traversed, structured in memory, queried or transformed. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, (i.e., “obtaining”, “generating”) can be performed in the human mind though observation, evaluation, judgment, opinion with the aid of pen and paper. Thus, these limitations fall within the “Mental Processes” grouping of abstract ideas.
Therefore, Yes, claims 1 and 19-20 recite judicial exceptions.
The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception.
Step 2A Prong 2:
This judicial exception is not integrated into a practical application. The claims recite the following additional elements: “a command coverage assessment system”, “a processing device comprising a processor coupled to a memory”, “a system”, and “a non-transitory processor-readable storage medium”. The additional elements are merely instructions to implement an abstract idea on a computer, or merely using a generic computer or computer components as a tool to perform the abstract idea (see MPEP 2106.05(f)). Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea, thus failing to integrate the abstract idea into a practical application. These are additional elements recited in the claim:
a) “executing at least one test case on a system;” – Mere instructions to apply an exception (See MPEP 2106.05(f)). The additional elements amount to more than a recitation of the words "apply it" (or an equivalent) or are more than mere instructions to implement an abstract idea or other exception on a computer.
b) “obtaining, ” – Insignificant extra-solution activity – mere data gathering (See MPEP 2106.05(g)).
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
After having evaluating the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1 and 19-20 not only recites a judicial exception but that the claim is directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
As discussed above with respect to integration of the abstract idea into a practical application, the additional elements “a command coverage assessment system”, “a processing device comprising a processor coupled to a memory”, “a system”, and “a non-transitory processor-readable storage medium” are generic computer components used as tools to perform the abstract idea. Accordingly, the additional elements recited in the claims cannot provide an inventive concept. In addition, after further evaluation the claim as a whole doesn’t improve any function of a computer or to any other technology or technical field. Thus, the claims are not patent eligible. These are additional elements recited in the claim: a) “a test case log” and “command tree map” – these are well understood, routine, conventional data structures. See Gopalakrishman [0038], [0049] and Lee-Smith [0021].
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claims 1 and 19-20 do not recite patent eligible subject matter under 35 U.S.C. § 101. With regards to claim 2 it recites “parsing, by a covered commands pool module, the at least one test case log, to obtain commands transmitted to the system during the execution of the at least one test case, wherein the command coverage assessment system comprises the covered commands pool module.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. For example, a person can read and analyze data. Further, is also considered an insignificant extra-solution activity of mere data gathering. Moreover, claim 2 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 2 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 2 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 3, it recites “obtaining, by the covered commands pool module, a plurality of covered commands and a covered command count associated with each of the respective plurality of covered commands, wherein the covered command count indicates a total occurrence of the each of the respective plurality of covered commands in the at least one test log.” as drafted, is a process that, but for the recitation of generic computing components, addresses an insignificant extra-solution activity of mere data gathering Moreover, claim 3 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 3 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 3 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 4 it recites “updating the command tree map associated with a covered command with the respective covered command count, wherein the plurality of covered commands comprises the covered command.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 4 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 4 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 4 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 5, it recites “outputting, by a commands coverage report module, an analysis report indicating whether target commands in a target commands namespace are covered in a covered commands pool associated with a covered commands pool module, wherein the covered commands pool comprises covered commands in the at least one test log, wherein the command coverage assessment system comprises the commands coverage report module and the covered commands pool module.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 5 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 5 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 5 does not recite patent eligible subject matter under 35 U.S.C. § 101. With regards to claim 6, it recites “wherein the analysis report further comprises a coverage level associated with the covered commands and a coverage level requirement threshold.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 6 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 6 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 6 does not recite patent eligible subject matter under 35 U.S.C. § 101. With regards to claim 7, it recites “evaluating, by the command coverage assessment system, the at least one test case log to identify usage of at least one command used during the execution of the at least one test case.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 7 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 7 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 7 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 8, it recites “generating a data structure for command coverage analysis.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 8 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 8 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 8 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 9, it recites “instantiating at least one command tree map comprising at least one primary node and at least one child node.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 9 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 9 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 9 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 10, it recites “generating, by an adjustable target commands namespace module, a target commands namespace comprising at least one target command, wherein the at least one test case comprises testing the at least one target command, and wherein the command coverage assessment system comprises the adjustable target commands namespace module.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 10 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 10 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 10 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 11, it recites “obtaining from a target commands namespace, target command coverage information; assigning a weight to the target command coverage information; and storing the weight in a child node of the command tree map.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 11 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 11 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 11 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 12, it recites “wherein the child node comprises a hit ratio associated with a command executed during the execution of the test case.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 12 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 12 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 12 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 13, it recites “wherein the hit ratio is a normalized covered command count, wherein the covered command count indicates a total occurrence of a covered command in the at least one test log.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 13 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 13 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 13 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 14, it recites “storing a sum of a plurality of weights in a primary node, wherein the plurality of weights is associated with a respective plurality of child nodes associated with the primary node, wherein the plurality of child nodes comprises the child node.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 14 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 14 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 14 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 15 it recites “creating the command tree map for each target command in the target commands namespace, wherein each respective command tree map comprises full usage combinations of the target command, wherein each respective command tree map comprises a respective primary node and at least one respective child node.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 15 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 15 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 15 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 16, it recites “updating the weight in the child node of the command tree map based on information associated with the full usage combination of the command.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 16 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 16 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 16 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 17, it recites “querying the command tree map associated with a command to determine whether a covered commands pool associated with a covered commands pool module comprises the command, wherein a target commands namespace associated with an adjustable target commands namespace module comprises the command, wherein the command coverage assessment system comprises the adjustable target commands namespace module and the covered commands pool module.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 17 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 17 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 17 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 18, it recites “determining whether a coverage level associated with the command meets a requirement threshold.” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or using pen and paper. Moreover, claim 18 does not recite any other additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 18 also fails both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more Therefore, Claim 18 does not recite patent eligible subject matter under 35 U.S.C. § 101. Therefore, Claims 1-20 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 15-16 and 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 15 recites “creating the command tree map for each target command in the target commands namespace, wherein each respective command tree map comprises full usage combinations of the target command, wherein each respective command tree map comprises a respective primary node and at least one respective child node.”. “The command tree map” implies the single tree map from claim 1, but “for each target command” + “each respective command tree map” implies multiple tree maps. A single tree map cannot be “for each target command” if there are multiple target commands. Please introduce a plurality of tree maps with “a respective command tree map for each target command” to make it clear. In addition, claim 15 refers to “each target command” without prior introduction of the plurality. Lacks antecedent basis. Claim 15 depends on claim 12, which depends on claim 11, which depends on claim 1. For example, claim 1 does not introduce “target commands”, claim 11 introduces “a target commands namespace” and “target command coverage information”, but not “target commands” plural. Claim 12 adds nothing. Claim 16 recites “updating the weight in the child node of the command tree map based on information associated with the full usage combination of the command.”. Lacks antecedent basis. Claim 15 introduces “full usage combinations” in plural. Further, is unclear what command is referring to as limited in the claim “the command “. Lastly, it is unclear whether “the child node” is doing reference to “at least one respective child node.” in claim 15 or “a child node” in claim 11. Claim 19 recites in multiple times “a system” and “a command coverage assessment system”. A skilled reader cannot reliably tell which “system” is which.
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-10 and 17-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Gopalakrishnan et al. (US Pub. No. 2015/0363295 – hereinafter Gopalakrishnan).
With respect to claim 1, Gopalakrishnan teaches a method comprising: executing at least one test case on a system (Gopalakrishnan discloses applying a test suite to a software product under test on a computer system. See Gopalakrishnan paragraph [0027], ("the sequence of tests as defined by the Test Plan is applied to the code (Block 130)"). See paragraph [0035], ("After the line and function coverage are achieved, CCA is run to get the command coverage (Block 450)"). See paragraphs [0044]-[0045], ("the release engineering team runs the test suite on the software product code base"). See paragraph [0046], ("the tested set of configurations… from the test suite"). Gopalakrishnan's execution of the test suite on the software product reads on "executing at least one test case on a system."). obtaining, by a command coverage assessment system, at least one test case log resulting from the execution of the at least one test case (Gopalakrishnan discloses a Command Coverage Analyzer (CCA) — which reads on the claimed "command coverage assessment system". See Gopalakrishnan paragraph [0022], "The conditional command coverage analyzer (CCA) is a tool with an associated system and method that provide… a conditional coverage metric for software quality". See paragraph [0049], "CCA process 600") — that obtains a log of test case results from the executed test suite. Specifically, Gopalakrishnan paragraph [0049] discloses that the CCA stores a "golden log" of results from test cases: "a LUT or other storage mechanism may store a 'golden log' of results from test cases that have been [confirmed] to be correct, wrong, or other status of interest." Gopalakrishnan paragraph [0050] further discloses that this log is updated with information extracted from the executed test suite: "configurations extracted from each test file in test suite database 610 are used to update (Block 630) the file… In one embodiment, the file updated is a golden log.". Gopalakrishnan paragraph [0051] further discloses processing of test case results from the executed test suite: "a current set of results for a test suite applied to the software product under test are compared to a 'golden' set of results.". Gopalakrishnan's golden log of test case results, obtained by the CCA from the executed test suite, reads on "at least one test case log resulting from the execution of the at least one test case.") and generating, by the command coverage assessment system a command coverage report using a command tree map, based on the at least one test case log (Gopalakrishnan's CCA engine generates a command coverage report based on the test case log/coverage database. See Gopalakrishnan paragraph [0046], ("The CCA engine 570… generates a command coverage database 580"). See paragraph [0048], ("From command coverage database 580, command coverage reports 590 are generated"). See paragraph [0056], ("a report 760 is generated to identify the testing gaps based on the set of configurations"). Gopalakrishnan further discloses in paragraph [0038] that the underlying coverage data structure is implemented as a tree representing the commands and their hierarchy of options, arguments, and values: "configuration extractor 520 forms the keys to a hash table data structure, which is created to keep track of occurrences of the software product configurations. In another embodiment, a tree structure is used, or a different type of data structure". Gopalakrishnan paragraph [0049], "a look up table (LUT) (Block 615) is created from this information, including the commands, options, arguments, and values that may be present in the software product under test. Other embodiments may use other mechanisms to store and interrelate this information, such as a graph, hash table, or tree". Gopalakrishnan's command coverage report, generated from the tree-structured command coverage database, reads on "generating… a command coverage report using a command tree map, based on the at least one test case log."), wherein the method is implemented by at least one processing device comprising a processor coupled to a memory (See Gopalakrishnan paragraph [0066], ("The data processing system illustrated in FIG. 9 includes a bus or other internal communication means 940 for communicating information, and a processing unit 910 coupled to the bus 940 for processing information"). See paragraph [0067], ("a random access memory (RAM) or other volatile storage device 920 (referred to as memory), coupled to bus 940 for storing information and instructions to be executed by processor 910")). With respect to claim 2, Gopalakrishnan teaches parsing, by a covered commands pool module, the at least one test case log, to obtain commands transmitted to the system during the execution of the at least one test case, wherein the command coverage assessment system comprises the covered commands pool module (Gopalakrishnan discloses a file list extractor (which reads on the claimed "covered commands pool module") that parses the executed test suite to obtain the commands tested during execution. See Gopalakrishnan paragraph [0044], ("file list extractor 550, in one embodiment, uses a Tcl Parser to parse through the existing test suite… The results of this parse are stored in file list database 560, representing the configuration combinations that are present in each test case within the test suite". See paragraph [0045], ("file list extractor 550 is provided the test suites as input and, using the parser algorithm, uses data mining on the test suite to identify each permutation and combination of configurations tested"). Gopalakrishnan paragraph [0048] further discloses parsing the resulting coverage database: "a sequential scan of the coverage database… provides the command coverage statistics of the software product under test." Gopalakrishnan's file list extractor 550 is part of the CCA system (Gopalakrishnan FIG. 5), and Gopalakrishnan paragraph [0021] establishes that commands are among the configurations identified ("a set of one or more of commands, options, arguments, inputs, operations, values… may be referred to as 'configurations'")). With respect to claim 3, Gopalakrishnan teaches obtaining, by the covered commands pool module, a plurality of covered commands and a covered command count associated with each of the respective plurality of covered commands, wherein the covered command count indicates a total occurrence of the each of the respective plurality of covered commands in the at least one test log (Gopalakrishnan's coverage data structure tracks the count of occurrences of each command-related configuration. See Gopalakrishnan paragraph [0038], ("configuration extractor 520 forms the keys to a hash table data structure, which is created to keep track of occurrences of the software product configurations"). See paragraph [0048], ("a sequential scan of the coverage database, in one example a hash table, provides the command coverage statistics of the software product under test"). Tracking "occurrences" of each configuration inherently requires recording a count of those occurrences for each configuration, reading on "a covered command count… [indicating] a total occurrence of the each of the respective plurality of covered commands in the at least one test log."). With respect to claim 4, Gopalakrishnan teaches updating the command tree map associated with a covered command with the respective covered command count, wherein the plurality of covered commands comprises the covered command (Gopalakrishnan discloses updating the coverage data structure (which Gopalakrishnan expressly contemplates as a tree per paragraph [0038] and paragraph [0049]) with information extracted from the executed test suite. See Gopalakrishnan paragraph [0050], ("configurations extracted from each test file in test suite database 610 are used to update (Block 630) the file, e.g. a LUT, created in Block 615"). Further, Gopalakrishnan paragraph [0038] expressly recites that the data structure is created "to keep track of occurrences of the software product configurations" — keeping track of occurrences inherently requires updating the data structure with the count of each occurrence as configurations are encountered. Gopalakrishnan's update of the tree-structured coverage data with occurrence-count information for each configuration reads on "updating the command tree map associated with a covered command with the respective covered command count."). With respect to claim 5, Gopalakrishnan teaches outputting, by a commands coverage report module, an analysis report indicating whether target commands in a target commands namespace are covered in a covered commands pool associated with a covered commands pool module, wherein the covered commands pool comprises covered commands in the at least one test log (Gopalakrishnan outputs a coverage report indicating whether target commands (commands in the software product specification meta-data) are covered in the tested configurations (covered commands pool). See Gopalakrishnan paragraph [0055], ("specification meta-data file 725 representing the configurations available or possible in software product under test 720" — target commands namespace, "file list meta-data file 735 representing the various permutations and combinations of configurations that are presently represented by existing test suite 730" — covered commands pool). See paragraph [0056], ("a report 760 is generated to identify the testing gaps based on the set of configurations. In one embodiment, configurations in first region 762 are uncovered commands, second region 764 are partially covered commands, and third region 766 are fully covered commands"). See paragraph [0057], ("summary region 810… gives a count for each of the number of uncovered commands… partially covered commands… and fully covered commands"). Gopalakrishnan's report identifying which target commands are uncovered, partially covered, or fully covered relative to the tested configurations reads on the claim limitation), wherein the command coverage assessment system comprises the commands coverage report module and the covered commands pool module (Gopalakrishnan further discloses that the CCA system comprises both the commands coverage report module and the covered commands pool module. Gopalakrishnan figure 5 and figure 7 each depict the CCA system as comprising the report-generation component (which generates report 760/590, paragraphs [0046]-[0048], [0056]) and the file list extractor 550 / file list meta-data component 735 (which collects and stores the covered commands pool, paragraphs [0044]-[0045], 0055]). Gopalakrishnan paragraph [0055], expressly recites both components within the CCA: “CCA 710…extracts information from an existing test suite 730…and stores the extracted information as a file list meta-data file 735” and “a report 760 is generated”. Gopalakrishnan’s CCA system comprising both the report-generation component and the file list (covered commands pool) component reads on “the command coverage assessment system comprises the commands coverage report module and the covered command pool module”). With respect to claim 6, Gopalakrishnan teaches wherein the analysis report further comprises a coverage level associated with the covered commands and a coverage level requirement threshold (Gopalakrishnan's report identifies coverage levels for the covered commands. See Gopalakrishnan paragraph [0056], ("first region 762 are uncovered commands, second region 764 are partially covered commands, and third region 766 are fully covered commands") — the classification into uncovered, partially covered, and fully covered regions is the coverage level associated with the covered commands. The classification of commands into these three levels is necessarily and inherently based on a coverage threshold: a command must satisfy a particular coverage threshold to be classified as "fully covered" rather than "partially covered" or "uncovered.". See Gopalakrishnan paragraph [0035] expressly discloses the threshold values used ("command coverage is considered adequate when it is 100%… In another embodiment 90% coverage may be considered sufficient… In another embodiment, a particular subset of configurations with a different coverage percentage may be considered sufficient"). Gopalakrishnan's report classification by coverage level inherently reflects the underlying coverage threshold and accordingly reads on the limitation that the analysis report comprises a coverage level and a coverage level requirement threshold.). With respect to claim 7, Gopalakrishnan teaches evaluating, by the command coverage assessment system, the at least one test case log to identify usage of at least one command used during the execution of the at least one test case (Gopalakrishnan's CCA engine evaluates the parsed test suite results to identify which commands and configurations were tested. See Gopalakrishnan paragraph [0044], ("file list extractor 550… uses a Tcl Parser to parse through the existing test suite" to identify configurations tested). See paragraph [0046], (CCA engine "analyzes the overlap between the available permutations and combinations of configurations… and the tested set of configurations… from the test suite"). See paragraphs [0049]–[0050], (parsing test suite to extract "a full set of tested configurations commands, options, arguments, and values list")). With respect to claim 8, Gopalakrishnan teaches generating a data structure for command coverage analysis (Gopalakrishnan expressly discloses generating a data structure for command coverage analysis. See Gopalakrishnan paragraph [0038], ("configuration extractor 520 forms the keys to a hash table data structure… In another embodiment, a tree structure is used, or a different type of data structure"). See paragraph [0049], ("a look up table (LUT) (Block 615) is created… Other embodiments may use other mechanisms to store and interrelate this information, such as a graph, hash table, or tree")). With respect to claim 9, Gopalakrishnan teaches instantiating at least one command tree map comprising at least one primary node and at least one child node (Gopalakrishnan expressly discloses instantiating a tree as the data structure used for command coverage. See Gopalakrishnan paragraph [0038], ("a tree structure is used"). See paragraph [0049], ("such as a graph, hash table, or tree"). Gopalakrishnan [0021] further establishes that the data represented in the tree has an inherent multi-level hierarchical organization ("a set of one or more of commands, options, arguments, inputs, operations, values… may be referred to as 'configurations'"). A tree structure representing such multi-level hierarchical data necessarily and inherently comprises at least one primary (parent) node and at least one child node — that is the definitional structure of a tree representing more than a single level of hierarchy. Gopalakrishnan's instantiation of a tree structure containing the multi-level configuration hierarchy therefore inherently reads on "at least one command tree map comprising at least one primary node and at least one child node."). With respect to claim 10, Gopalakrishnan teaches generating, by an adjustable target commands namespace module, a target commands namespace comprising at least one target command, wherein the at least one test case comprises testing the at least one target command, and wherein the command coverage assessment system comprises the adjustable target commands namespace module (Gopalakrishnan discloses generating a target commands namespace via a configuration extractor that produces a specification meta-data file storing the available commands, options, arguments, and values for the software product. The configuration extractor reads on the "adjustable target commands namespace module." See Gopalakrishnan paragraph [0043], ("Configuration extractor 520 provides an output, configurations extracted from the software product under test, which is stored in a database 530"). See paragraph [0055], ("specification meta-data file 725 representing the configurations available or possible in software product under test 720"). Gopalakrishnan further discloses that the namespace is adjustable: "additional configurations may be added into specification meta-data file 725… within CCA 710. In one embodiment, additional meta-data files are included within CCA 710. In one embodiment, additional meta-data includes information to include or exclude when reporting. In one embodiment, the information comprises a set of commands to exclude" (Gopalakrishnan paragraph [0055]). Gopalakrishnan further discloses that the configuration extractor (the adjustable target commands namespace module) is part of the CCA system. Gopalakrishnan figure 5 depicts the configuration extractor 520 as a component of the CCA flow, and Gopalakrishnan paragraph [0055] expressly states that “CCA 710…extracts configurations, such as commands, options, arguments, and values from software product under test 720” and that the resulting specification meta-data file 725 is maintained “within CCA 710”. Gopalakrishnan CCA system comprising the configuration extractor reads on “the command coverage assessment system comprises the adjustable target commands namespace module”). With respect to claim 17, Gopalakrishnan teaches querying the command tree map associated with a command to determine whether a covered commands pool associated with a covered commands pool module comprises the command, wherein a target commands namespace associated with an adjustable target commands namespace module comprises the command, wherein the command coverage assessment system comprises the adjustable target commands namespace module and the covered commands pool module (Gopalakrishnan's CCA engine queries the coverage data structure (which Gopalakrishnan expressly contemplates as a tree per [0038] and [0049]) to determine the overlap between the target commands namespace (specification meta-data file 725) and the covered commands pool (file list meta-data file 735). See Gopalakrishnan paragraph [0046], ("The CCA engine 570 takes these two inputs, and analyzes the overlap between the available permutations and combinations of configurations… and the tested set of configurations… from the test suite"). See paragraph [0048], ("a sequential scan of the coverage database… provides the command coverage statistics"). See paragraph [0056], (the resulting report identifies which target commands are present in the covered commands pool — fully covered or partially covered — and which are not — uncovered). Gopalakrishnan further discloses that the CCA system comprises both the adjustable target commands namespace module and the covered commands pool module. Gopalakrishnan figure 7 depicts the CCA 710 as comprising the configuration extractor / specification meta-data file 725 (the target commands namespace module) and the file list extractor / file list meta-data file 735 (the covered commands pool module). Gopalakrishnan paragraph [0055] expressly recites that both components are within the CCA: "CCA 710 takes as inputs a software product under test 720 and any existing test suites 730. CCA 710 extracts configurations… from software product under test 720… extracted information is stored as a specification meta-data file 725… CCA 710 extracts information from an existing test suite 730… and stores the extracted information as a file list meta-data file 735." Gopalakrishnan's CCA system comprising both the specification meta-data component and the file list (covered commands pool) component reads on "the command coverage assessment system comprises the adjustable target commands namespace module and the covered commands pool module."). With respect to claim 18, Gopalakrishnan teaches determining whether a coverage level associated with the command meets a requirement threshold (See Gopalakrishnan paragraph [0035], ("the process determines whether the command coverage is adequate (Block 455). In one embodiment, command coverage is considered adequate when it is 100%… In another embodiment 90% coverage may be considered sufficient to ship the product. In another embodiment, a particular subset of configurations with a different coverage percentage may be considered sufficient"). See figure 4 Block 455, ("Determine whether the command coverage is adequate")). With respect to claim 19, Gopalakrishnan teaches a system comprising at least one processing device with a processor coupled to a memory configured to perform the same operational steps recited in claim 1. Gopalakrishnan expressly discloses the corresponding hardware. See Gopalakrishnan paragraph [0066], ("a bus or other internal communication means 940 for communicating information, and a processing unit 910 coupled to the bus 940 for processing information"). See paragraph [0067], ("a random access memory (RAM) or other volatile storage device 920 (referred to as memory), coupled to bus 940 for storing information and instructions to be executed by processor 910"). See paragraph [0073], ("The control logic or software implementing the present invention can be stored in main memory 920, mass storage device 930, or other storage medium"). Claim 19 is therefore anticipated for the same reasons set forth in connection with claim 1). With respect to claim 20, Gopalakrishnan teaches a computer program product comprising a non-transitory processor-readable storage medium storing program code that, when executed, causes a processing device to perform the same operational steps recited in claim 1. Gopalakrishnan expressly discloses non-transitory computer-readable storage media storing the program code. See Gopalakrishnan paragraph [0074], ("This control logic or software may also be resident on an article of manufacture comprising a computer readable medium having computer readable program code embodied therein and being readable by the mass storage device 930 and for causing the processor 910 to operate in accordance with the methods and teachings herein"). See paragraph [0078], ("A machine-readable medium includes any mechanism for storing information in a form readable by a machine"). Claim 20 is therefore anticipated for the same reasons set forth in connection with claim 1).
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, 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 11-16 are rejected under 35 U.S.C. 103 as being unpatentable over Gopalakrishnan et al. (US Pub. No. 2015/0363295) in view of Lee-Smith (US Pub. No. 2020/0104243). With respect to claim 11, Gopalakrishnan teaches obtaining from a target commands namespace, target command coverage information (Claim 11 is directed to the concept of associating a numerical or weighted indicator with each target command's coverage information and storing that indicator at the node level of the tree, such that the tree itself carries per-node coverage indicators. See Gopalakrishnan paragraph [0046], ("The CCA engine 570… analyzes the overlap between the available permutations and combinations of configurations… and the tested set of configurations… from the test suite" — yielding per-command coverage information). See paragraph [0055], ("specification meta-data file 725 representing the configurations available or possible in software product under test 720" — the target commands namespace). See paragraph [0056], (per-command coverage classification: uncovered, partially covered, fully covered). Gopalakrishnan is silent to disclose, however, Lee-Smith teaches assigning a weight to the target command coverage information; and storing the weight in a child node of the command tree map (Gopalakrishnan's per-command coverage classifications are reported at the report-region level (commands grouped into uncovered/partial/full regions of the output report, paragraphs [0056]–[0057]) or as aggregate database statistics (paragraph [0048]), while Gopalakrishnan paragraph [0038] discloses tracking occurrences in a hash table, Gopalakrishnan does not expressly disclose assigning a weight to the target command coverage information, nor does Gopalakrishnan expressly disclose storing such a weight in a child node of the tree-structured embodiment of the data structure. Lee-Smith expressly teaches storing, on each node of the tree, a numerical value reflecting the coverage of that node. See Lee-Smith paragraph [0034] ("count 418 can be included. Count refers to the number of times the particular functionality has been tested with those environmental parameters… the system can track a count of a number of times a particular test environment for a particular piece of functionality is represented in the tree during a test period"). See paragraphs [0036]–[0038], (per-branch completion percentage stored on each branch node of the tree: "all of the branches can have some visual indicator as to the completion percentage—the percentage of accepted tests for which a completed test exists with respect to the total number of accepted tests—within the branch"). Under the broadest reasonable interpretation of "weight," which encompasses any numerical value indicative of importance, magnitude, or coverage status associated with the target command coverage information, Lee-Smith's per-node count and per-branch completion percentage read on "a weight" stored in a node of the tree).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Lee-Smith's per-node value-storage technique to Gopalakrishnan's tree-structured command coverage data. Gopalakrishnan teaches the per-command coverage information; Lee-Smith teaches the more granular technique of storing the coverage indicator directly on the corresponding tree node. Lee-Smith expressly articulates the benefits of per-node value storage: enabling per-node visual appraisal of coverage thoroughness (Lee-Smith paragraph [0036]: heatmap for "a quick appraisal of the thoroughness of the test cases") and enabling feedback into test scheduling (Lee-Smith paragraph [0034]: "the count can be fed back to the test triggering/scheduling system so that the optimum collection of tests can be run to achieve the same functionality coverage outcome"). The combination yields a tree where each command node carries its own coverage indicator — a predictable improvement over Gopalakrishnan's report-region grouping. With respect to claim 12, Gopalakrishnan is silent to disclose, however, Lee-Smith teaches wherein the child node comprises a hit ratio associated with a command executed during the execution of the test case (Claim 12 is directed to the concept that the per-node coverage indicator (introduced in claim 11) takes the specific form of a ratio reflecting how thoroughly the corresponding command was hit during test execution. Gopalakrishnan teaches that command coverage is measured as a percentage at the aggregate level (paragraph [0035]: 100%, 90% adequacy thresholds) and that occurrences of configurations are tracked in the data structure (paragraph [0038]). Gopalakrishnan's percentages are aggregate-level (overall coverage of the test suite), not a hit ratio comprised within a child node of the tree associated with an executed command.
Lee-Smith expressly teaches a per-node completion percentage computed as a ratio: completed tests divided by total accepted tests. See Lee-Smith paragraph [0036], ("all of the branches can have some visual indicator as to the completion percentage—the percentage of accepted tests for which a completed test exists with respect to the total number of accepted tests—within the branch"). See paragraph [0038], ("divide the number of completed tests by the number of total accepted tests to find completion percentage"). Under the broadest reasonable interpretation of "hit ratio," which encompasses any ratio derived from the number of times a command-related functionality is hit during execution, Lee-Smith's per-node completion percentage reads on "a hit ratio associated with a command executed during the execution of the test case.").
The rationale to combine is the same articulated for claim 11: once per-node values are introduced into the tree (Lee-Smith's contribution), expressing those values as a ratio is the conventional and predictable form already taught by Lee-Smith paragraph [0038], and is consistent with Gopalakrishnan's broader analytical framework that already uses percentages at the aggregate level (paragraph [0035]). With respect to claim 13, Gopalakrishnan is silent to disclose, however, Lee-Smith teaches wherein the hit ratio is a normalized covered command count, wherein the covered command count indicates a total occurrence of a covered command in the at least one test log (Gopalakrishnan teaches tracking occurrences of configurations in the coverage data structure (paragraph [0038]: hash table "created to keep track of occurrences of the software product configurations") and computing coverage statistics from those occurrences (paragraph [0048]). While Gopalakrishnan paragraph [0038] tracks occurrences of configurations (which corresponds to the claimed "total occurrence of a covered command in the at least one test log"), Gopalakrishnan does not expressly disclose a hit ratio that is a normalized form of that covered command count.
Lee-Smith expressly teaches dividing the count of completed tests by the total accepted tests to produce a normalized ratio. See Lee-Smith paragraph [0034], (per-node count of test occurrences). See paragraph [0038], ("the system can simply divide the number of completed tests by the number of total accepted tests to find completion percentage"). Lee-Smith's division of completed tests by total accepted tests produces a normalized count expressed as a ratio, reading on "a normalized covered command count.").
The rationale to combine is that Gopalakrishnan provides the count, Lee-Smith provides the normalization, and combining them is a routine mathematical operation in coverage measurement that produces predictable results. With respect to claim 14, Gopalakrishnan is silent to disclose, however, Lee-Smith teaches storing a sum of a plurality of weights in a primary node, wherein the plurality of weights is associated with a respective plurality of child nodes associated with the primary node, wherein the plurality of child nodes comprises the child node (Gopalakrishnan teaches aggregate coverage statistics computed across the entire test suite. See Gopalakrishnan paragraph [0048], ("a sequential scan of the coverage database… provides the command coverage statistics of the software product under test"). See paragraph [0057], (summary region with aggregate counts of uncovered, partially covered, and fully covered commands). Gopalakrishnan's aggregations are at a single overall level (the entire coverage database), not stored as a sum at an intermediate primary node where the summed values originate from a plurality of associated child nodes within a tree hierarchy.
Lee-Smith expressly teaches computing branch-level (primary node) aggregate values by summing the values of constituent child nodes. See Lee-Smith paragraphs [0036]–[0038] ("all of the branches can have some visual indicator as to the completion percentage—the percentage of accepted tests for which a completed test exists with respect to the total number of accepted tests—within the branch… By adding the number of incomplete accepted tests and completed tests, the system can find the number of total accepted tests within the branch"). Lee-Smith's branch-level summation of constituent child counts reads on "storing a sum of a plurality of weights in a primary node, wherein the plurality of weights is associated with a respective plurality of child nodes."
The rationale to combine builds on the rationale for claim 11. Once per-node values are stored on the tree, hierarchical aggregation at parent-node levels is the predictable structural extension already disclosed by Lee-Smith. The benefit identified by Lee-Smith paragraphs [0036]–[0037] is at-a-glance assessment of coverage at varying granularities of the tree hierarchy. With respect to claim 15, Gopalakrishnan is silent to disclose, however, Lee-Smith teaches creating the command tree map for each target command in the target commands namespace, wherein each respective command tree map comprises full usage combinations of the target command, wherein each respective command tree map comprises a respective primary node and at least one respective child node (Gopalakrishnan teaches generating, for each target command, the full set of usage combinations (permutations and combinations) of that command. See Gopalakrishnan paragraph [0021], ("a set of one or more of commands, options, arguments, inputs, operations, values… may be referred to as 'configurations'" — establishing the per-command hierarchy). See paragraph [0022], ("The CCA may additionally extract configurations of a software product, produces permutations and combinations of these configurations"). See paragraph [0042], ("By testing numerous permutations and combinations configurations, such as various commands, options, arguments, and values"). See paragraph [0046], ("the available permutations and combinations of configurations… and the tested set of configurations"). While Gopalakrishnan teaches the per-command full usage combination data (the "full usage combinations of the target command" recited in the claim) through its disclosure of permutations and combinations of configurations, Gopalakrishnan does not expressly disclose creating a respective tree map for each target command, nor does it expressly disclose each per-command tree map comprising a respective primary node and at least one respective child node.
Lee-Smith expressly teaches organizing each represented feature as a sub-tree of the overall coverage tree, with primary branches representing fundamental aspects and child branches representing more specific aspects. See Lee-Smith paragraph [0021], ("the primary branches 214, which can represent the most fundamental aspects of the program or protocol… The tree can contain many children branches within the primary branches"). See paragraph [0024], ("branch node 262 is a parent node of leaf node 272 and nodes 274, 276").
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Lee-Smith's per-feature tree architecture to Gopalakrishnan's per-command usage combination data. Gopalakrishnan provides the per-command full usage combination data. Lee-Smith provides a known tree-with-primary-and-child architecture for organizing such hierarchical per-feature data. The combination is the predictable use of a known organizational technique. With respect to claim 16, Gopalakrishnan is silent to disclose, however, Lee-Smith teaches updating the weight in the child node of the command tree map based on information associated with the full usage combination of the command (Gopalakrishnan teaches updating the coverage data structure as configurations are extracted from the executed test suite. See Gopalakrishnan paragraph [0050] ("configurations extracted from each test file in test suite database 610 are used to update (Block 630) the file, e.g. a LUT, created in Block 615"). While Gopalakrishnan paragraph [0050] discloses updating the coverage data structure as a whole using configurations extracted from each test file, Gopalakrishnan does not expressly disclose updating the weight in a child node of the command tree map based on information associated with the full usage combination of the command — that is, Gopalakrishnan's update is to the coverage data store collectively, not to a child node corresponding to the specific full usage combination.
Lee-Smith expressly teaches that tests, at runtime, append code that adds or updates specific nodes of the tree with environment-tagged information identifying the specific functionality and environment combination being exercised. See Lee-Smith paragraph [0017], ("The tests themselves are appended with code that adds nodes to a tree (the coverage tree) as the tests are run… coverage server 100 receives the test information (e.g., a node name (NodeName), a parent node name (Parent), and environment information (Environment)) from the various tests"). See paragraph [0034] (count tracked per (functionality + environment-tag) combination on each node). See paragraph [0041], ("The tests can generate updates/add nodes to the tree at runtime")).
The rationale to combine builds on the rationale for claims 11 and 15. Once per-node weight values are stored on a per-command tree (claims 11 and 15), per-node update at runtime tied to specific full-combination execution events is the predictable runtime maintenance technique already disclosed by Lee-Smith for that exact tree organization.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Joshi et al. (US Pub. No. 2024/0104007) describes a code analysis method includling converting an expression indicated by a source code to Boolean expression, the expression including n conditions; generating binary expression tree including a plurality of nodes based on the Boolean expression; initializing a flip limit and the number of flips of each node by analyzing whether each node is a leaf node or a parent node; generating a first test case by initialization Boolean values of each of the plurality of parent nodes each of which a name is an operator among the plurality of nodes and two child nodes of the plurality of parent nodes to one of a plurality of valid cases; and generating n test cases by performing a flip on all node having flip feasibility on a path from a root node to a leaf node based on the first test case, and storing the first test and the n test cases. (see abstract).
Shani et al. (US Pat. No. 10,509,719) relates to automatically identifying regressions. Some implementations may include a data capture engine to capture data points during test executions of the application under test. The data points may include, for example, test action data and application action data. Additionally, some implementations may include a data correlation engine to correlate each of the data points with a particular test execution of the test executions, and each of the data points may be correlated based on a sequence of events that occurred during the particular test execution. Furthermore, some implementations may also include a regression identification engine to automatically identify, based on the correlated data points, a regression between a first version of the application under test and a second version of the application under test. (see abstract).
Kabanov et al. (US Pat. No. 8,539,282) discloses a method for managing quality testing. Quality tests are mapped to characteristics of a product under test. Based on the mapping and a result of a previously executed quality test, a respective relevance level is determined for each of the quality tests. Based on the relevance levels, a priority is determined among the quality tests. (see abstract).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 PM.
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 at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights