DETAILED ACTION
Remarks
This Office action is in response to the communication filed 15 January 2026, which was filed in response to the 2 October 2025 non-final Office action (the “Previous Action”).
Claims 1, 6, 9, 14 and 17 are amended, as well as the title of the invention
Claims 1-20 are pending. Claims 1, 9 and 17 are the independent claims.
Any unpersuasive arguments are addressed in the “Response to Arguments” section below.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
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.
Response to Arguments/Amendments
Applicant’s arguments are moot in view of the new ground(s) of rejection below, necessitated by Applicant’s amendments.
Specification
The Previous Action’s objection to the title is withdrawn in view of Applicant’s amended title.
Claim Rejections - 35 USC § 112
The Previous Action’s § 112 rejections are withdrawn in view of Applicant’s claim amendments.
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.
Claims 1-5, 9-13 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Buy et al., “Automated Testing of Classes” (art of record – hereinafter Buy) in view of Chandra et al. (US 2006/0161833) (art made of record – hereinafter Chandra).
As to claim 1, Buy discloses: a code testing method, comprising:
determining, for an object under test of a plurality of objects under test, member variables corresponding to the object under test (e.g., Buy, p. 39 Abstract: testing of classes; p. 42 right col. par. 1: data flow analysis is applied to the instance variables of a class) and a variable calling statement corresponding to each member variable of the member variables; (e.g., Buy, p. 40 right col. sec. 2 par. 3: this phase defines so-called du-pairs. These are ordered pairs of statements in which the first statement defines and the second statement uses the same instance variables. The statements may belong to different methods)
constructing an initial test case corresponding to the object under test based on the variable calling statements; (e.g., Buy, p. 40 col. Sec. 2 par. 1: we identify pairs of methods that define and use the same instance variable. We try to select a complete sequence of method invocations that contains the two methods in the correct order; p. 40 right col. sec. 2 par. 1: the sequences represent the test cases for the target class; p. 40 right col. sec. 2 par. 5: such sequences are incrementally built; p. 44 right col. par. 1: we generate a sequence starting from the method mu. If there is a method mk whose postconditions imply PCU, then the method is prepended to the front of the sequence. If no such method is found, we look for a method whose post-conditions do not contradict PCU, and we prepend such a method to the sequence)
determining a target test case based on a plurality of initial test cases corresponding to the plurality of objects under test; (e.g., Buy, p. 45 left col. par. 4: to illustrate our technique for tree construction, we show the process for automatically building the sequence of invocations; p. 45 right col. pars. 1 and 3: we start with the invocation of method Vend. The method returnQtrs is added to the tree; p. 46 left col. par. 4: we can add to the tree a node that corresponds to invocation of the constructor. The resulting method sequence is [so each time a method invocation is added to the sequence a new initial sequence (test case) is formed and the final sequence is the target test case]) and
testing to-be-tested code by using the target test case (e.g., Buy, p. 40 left col. par. 3: we assume that our generated method sequences will be executed by a testing system; p. 40 right col. sec. 2 par. 1: to test for such failures, our technique generates sequences that bring the object under test to states in which a given method is then exercised).
Buy does not explicitly disclose separately from determining the member variables, constructing an operation calling statement sequence based on a calling order corresponding to operations under test included in the object under test; and constructing an initial test case based on the operation calling statement sequence.
However, in an analogous art, Chandra discloses:
separately from determining the member variables, constructing an operation calling statement sequence based on a calling order corresponding to operations under test included in the object under test; (e.g., Chandra, par. [0022]: a driver that calls methods of a module [object] under test; par. [0014]: par. [0036]: Table 4 is one possible way in which method invocation orders may be specified; par. [0034]: Table 4 presents a grammar for these protocols; par. [0035]: Table 5 presents some example protocols based on this grammar [see code, the method order is specified without regard to any member variables]; par. [0052]: for generating drivers, a method invocation order is passed to the processor. A FSM is created for each invocation order. The intersection of these FSMs is determined. A search is made for method sequences of a specific length. A selected method sequence passes to a driver generator) and
constructing a[] test case corresponding to the object under test based on the operation calling statement sequence (e.g., Chandra, par. [0052]: for generating drivers, a method invocation order is passed to the processor. A FSM is created for each invocation order. A search is made for method sequences [test cases] of a specific length. A selected method sequence passes to a driver generator; par. [0022]: a driver that calls methods of a module [object] under test)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the construction of an initial test case based on variable calling statements of Buy to include constructing an operation calling statement sequence, separately from determining the member variables, based on a calling order corresponding to operations under test included in the object under test and constructing the test case based on the operation calling statement sequence, as taught by Chandra, as Chandra would provide the advantage of a means of ensuring the methods are otherwise invoked in a legal order (see Chandra, par. [0044]) in addition to the ordering taught by Buy.
As to claim 2, Buy/Chandra discloses the method according to claim 1 (see rejection of claim 1 above), Buy further discloses: wherein the determining, for the object under test, all the member variables corresponding to the object under test and the variable calling statements corresponding to the member variables includes:
determining all the member variables corresponding to the object under test (e.g., Buy, p. 39 Abstract: testing of classes; p. 42 right col. par. 1: data flow analysis is applied to the instance variables of a class) and a variable injection statement corresponding to each member variable; (e.g., Buy, p. 42 left col. sec. 4 par. 4: data flow analysis identifies du-pairs for instance variables. A du-pair for an instance variable v consists of two nodes sd and su [variable injection statement], such that sd and su, are both contained in a class C, sd modifies (writes) the value of v, su uses (reads) the value of v)
determining a variable initialization statement corresponding to each member variable based on an initial value and a value range corresponding to the member variable; (e.g., Buy, p. 42 left col. sec. 4 par. 4: data flow analysis identifies du-pairs for instance variables. A du-pair for an instance variable v consists of two nodes sd [variable initialization statement], and su, such that sd modifies (writes) the value of v [i.e., with an initial value] and there is a def-clear path from sd to su. A def-clear path for a du pair is a path from sd to su such that does not contain additional definitions of v [i.e., the value range for the variable]) and
combining the variable initialization statement and the variable injection statement to construct the variable calling statement corresponding to each member variable (e.g., Buy, p. 40 right col. Sec. 2 par. 3: du-pairs [variable calling statement]. In brief, these are pairs of statements in which the first statement defines and the second statement uses the same instance variable).
As to claim 3, Buy/Chandra discloses the method according to claim 1 (see rejection of claim 1 above), Buy further discloses wherein the determining the target test case based on the plurality of initial test cases includes:
reconstructing a test case based on each initial test case of the plurality of test cases to obtain a candidate test case; (e.g., Buy, p. 40 right col. sec. 2 par. 1: the sequences represent the test cases for the target class; p. 40 right col. sec. 2 par. 5: such sequences are incrementally built; p. 44 right col. par. 1: we generate a sequence starting from the method mu. If there is a method mk whose postconditions imply PCU, then the method is prepended to the front of the sequence [each time a method is prepended to an existing sequence, the existing sequence is an initial test case and adding a new method constructs it again (reconstructs it) and the resulting sequence is a candidate test sequence]) and
determining the target test case based on each candidate test case (e.g., Buy, p. 45 left col. par. 4: to illustrate our technique for tree construction, we show the process for automatically building the sequence of invocations; p. 45 right col. pars. 1 and 3: we start with the invocation of method Vend. The method returnQtrs is added to the tree; p. 46 left col. par. 4: we can add to the tree a node that corresponds to invocation of the constructor. The resulting method sequence is [so each time a method invocation is added to the sequence a new candidate sequence (test case) is formed and the final sequence is the target test case])
As to claim 4, Buy/Chandra discloses the method according to claim 3 (see rejection of claim 3 above), Buy further discloses wherein the reconstructing the test case based on each initial test case to obtain the candidate test case includes:
processing an operation parameter corresponding to an operation called in each initial test case and a member variable parameter corresponding to a called member variable to obtain a processed operation parameter and a processed member variable parameter; (e.g., Buy, p. 44 right col. par. 2: each tree node corresponds to a pair consisting of a method and a condition, that is a predicate on the instance variables of the class [called member variables] and the parameters of the method [operation parameters. The parameters and variables are processed in the sense that they are included in the tree]) and
reconstructing the test case based on the processed operation parameter, the processed member variable parameter, and an operation calling statement and a variable calling statement that are included in each initial test case, to obtain the candidate test case (e.g., Buy, p. 46 left col. pars. 3-4: these three nodes [comprising processed operation parameters and member variable parameters] are explored next. We can add to the tree a node that corresponds to invocation of the constructor [reconstructing a test case to obtain the candidate test case, which is based on operation calling statement and variable calling statements, see above])
As to claim 5, Buy/Chnadra discloses the method according to claim 3 (see rejection of claim 3 above), Buy further discloses wherein the reconstructing the test case based on each initial test case to obtain the candidate test case includes:
for each initial test case, if an object under test corresponding to the initial test case does not include a determined to-be-inserted operation under test, reconstructing the test case based on an operation calling statement corresponding to the determined to-be-inserted operation under test and based on an operation calling statement and a variable calling statement that are included in the initial test case, to obtain the candidate test case (e.g., Buy, p. 45 left col. par. 4: to illustrate our technique for tree construction, we show the process for automatically building the sequence of invocations; p. 45 right col. pars. 1 and 3: we start with the invocation of method Vend. The method returnQtrs is added to the tree; p. 46 left col. par. 5 the resulting method sequence is CoinBox(), addQtr(), addQtr(), returnQtrs(), vend() [so returnQtrs is not initially included in the sequence (initial test case) then it is added to it (reconstructing the test case). Adding it is adding an operation calling statement to the sequence, as shown by the final sequence. And as noted above with respect to claim 1, the methods in the sequence are added based on operation calling statements and variable calling statements, so the initial sequence before additional methods are added to it is based on operation and variable calling statements]).
As to claim 9, it is a system claim having limitations substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons. Further limitations, not explicitly disclosed by Buy but disclosed by Chandra, include:
a computing system comprising one or processors and one or more memory devices, the one or more memory devices having computer executable instructions stored thereon, which when executed by the one or more processors, enable the one or more processors to implement acts (e.g. Chandra, par. [0061]: software programs for generating stubs and rivers as described herein. Computer software programs may be thought of as a collection of software instructions for implementing particular steps; par. [0066]: the software instructions of the computer software program are loaded into memory 350 for execution by the processor 340) including (see rejection of claim 1 above).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Hicks to include a computing system comprising one or processors and one or more memory devices, the one or more memory devices having computer executable instructions stored thereon, which when executed by the one or more processors, enable the one or more processors to implement the method, as taught by Chandra, as Chandra would provide the advantage of a means of performing the method on a computer (see Chandra, Fig 2 and par. [0061]) as suggested by Buy’s references to “automatically” generating method sequences. (See Buy, p. 40 left col. par. 3).
As to claim 10, it is a system claim having limitations substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
As to claim 11, it is a system claim having limitations substantially the same as those of claim 3. Accordingly, it is rejected for substantially the same reasons.
As to claim 12, it is a system claim having limitations substantially the same as those of claim 4. Accordingly, it is rejected for substantially the same reasons.
As to claim 13, it is a system claim having limitations substantially the same as those of claim 5. Accordingly, it is rejected for substantially the same reasons.
As to claim 17, it is a system claim having limitations substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons. Further limitations, not explicitly disclosed by Buy but disclosed by Chandra, include:
a non-transitory storage medium having computer executable instruction stored thereon, the executable instructions when executed by a processor enabling the processor to implement acts (e.g. Chandra, par. [0061]: software programs for generating stubs and rivers as described herein. Computer software programs may be thought of as a collection of software instructions for implementing particular steps; par. [0063]: the memory 350 includes RAM; par. [0066]: the software instructions of the computer software program are loaded into memory 350 for execution by the processor 340) comprising: (see rejection of claim 1 above).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Hicks to include a non-transitory storage medium having computer executable instruction stored thereon, the executable instructions when executed by a processor enabling the processor to implement acts of the method, as taught by Hicks, as Hicks would provide the advantage of a means of performing the method on a computer (see Chandra, Fig 2 and par. [0061]) as suggested by Buy’s references to “automatically” generating method sequences. (See Buy, p. 40 left col. par. 3).
As to claim 18, it is a medium claim having limitations substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
As to claim 19, it is a medium claim having limitations substantially the same as those of claim 3. Accordingly, it is rejected for substantially the same reasons.
As to claim 20, it is a medium claim having limitations substantially the same as those of claim 4. Accordingly, it is rejected for substantially the same reasons.
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Buy (“Automated Testing of Classes”) in view of Chandra (US 2006/0161833) in further view of Stamm et al. (US 6,622,298) (art of record – hereinafter Stamm).
As to claim 6, Buy/Chandra discloses the method according to claim 3 (see rejection of claim 3 above), and further discloses calling statement(s) (see rejection of claim 1 above) but Buy does not explicitly disclose wherein the determining the target test case based on each candidate test case includes: determining, for each candidate test case, another operation calling statement from the candidate test case different from an operation calling statement included in the corresponding initial test case as a target calling statement; and deleting, based on a determined probability, at least part of target calling statements included in the candidate test case, to determine a target test case based on the candidate test case from which the at least part of target calling statements are deleted.
However, in an analogous art, Stamm discloses: wherein the determining the target test case based on each candidate test case includes:
determining, for each candidate test case, another operation statement from the candidate test case different from an operation statement included in the corresponding initial test case as a target statement; (e.g., Stamm, col. 3 ll. 30-35: each entry in the log file includes the action; col. 3 l. 66 – col. 4 l. 1-5: the process for evolving a test sequence. The process generally entails using test actions from a previously generated log file [initial candidate test case] and discarding some of the actions. A new log file is created to document the evolved test sequence. col. 4 ll. 5-8: an entry is read from the previously created log file) and
deleting, based on a determined probability, at least part of target statements included in the candidate test case, to determine a target test cases based on the candidate test case from which the at least part of target statements are deleted (e.g., Stamm, col. 3 l. 66 – col. 4 l. 1-15: the process for evolving a test sequence. The process generally entails using test actions from a previously generated log file [initial test case] and discarding some of the actions. A new log file [target test case] is created to document the evolved test sequence. An entry [statement] is read from the previously created log file. Decision step 164 determines whether this entry should be discarded. Probabilities are used for determining whether the entry should be discarded).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the determining target test cases from candidate test cases and operation calling statements taught by Buy such that the determining comprises determining, for each candidate test case, another operation statement from the candidate test case different from an operation statement included in the corresponding initial test case as a target statement; and deleting, based on a determined probability, at least part of target statements included in the candidate test case, to determine the target test cases based on the candidate test case from which the at least part of target statements are deleted, as taught by Stamm, as Stamm would provide the advantage of a means of evolving the test sequences to cover more logic of the application. (See Stamm, col. 3 ll. 55-56).
As to claim 14, it is a system claim having limitations substantially the same as those of claim 6. Accordingly, it is rejected for substantially the same reasons.
Claims 7 and 15 rejected under 35 U.S.C. 103 as being unpatentable over Buy (“Automated Testing of Classes”) in view of Chandra (US 2006/0161833) in further view of Hicks et al. (US 2020/0242011) (art of record – hereinafter Hicks) and Yuan et al. (US 2021/0232491) (art of record – hereinafter Yuan).
As to claim 7, Buy/Chandra discloses the method according to claim 3 (see rejection of claim 3 above),but does not explicitly disclose wherein the determining the target test case based on each candidate test case includes: for each candidate test case, if a comprehensive coverage rate corresponding to the candidate test case is greater than a threshold, and a coverage target determined after code testing is performed by using the candidate test case is not completely same as a coverage target determined after code testing is performed by using the determined target test case, using the candidate test case as the target test case.
However, in an analogous art, Hicks discloses wherein the determining the target test case based on each candidate test case includes:
for each candidate test case, if a comprehensive coverage rate corresponding to the candidate test case is greater than a threshold, using the candidate test case as the target test case (e.g., Hicks, par. [0040]: a threshold amount of cumulative coverage may be desired. A subset of test cases may be selected [using a candidate test case as the target] that provides a cumulative code coverage that is at least as great as the desired cumulative code coverage).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the use of candidate test cases as targets of Buy such that a candidate is used as a target if a comprehensive coverage rate corresponding to the candidate test case is greater than a threshold, as taught by Hicks, as Hicks would provide the advantage of a means of ensuring a desired coverage. (See Hicks, par. [0040]).
Further, in an analogous art, Yuan discloses:
for each candidate test case, if a coverage target determined after code testing is performed by using the candidate test case is not completely same as a coverage target determined after code testing is performed by using the determined target test case, using the candidate test case as the target test case (e.g., Yuan, par. [0019]: test cases may be run on the code modules [performing code testing using the test cases]. In response, code coverage may be identified and mapped with the respective test case that was run; par. [0051]: see code, “best_testcase = testcase” when “len(covered) > len (methods_covered)” [i.e., the testcase is used as the best_testcase (target) if its coverage is greater than (not completely the same as) the coverage of the previous testcase considered by the loop]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the use of candidate test cases as targets of Buy such that a candidate is used as a target if a coverage target determined after code testing is performed by using the candidate test case is not completely same as a coverage target determined after code testing is performed by using the determined target test case, as taught by Yuan, as Yuan would provide the advantage of a means of maximizing coverage. (See Yuan, pars. [0050-0051]).
As to claim 15, it is a system claim having limitations substantially the same as those of claim 7. Accordingly, it is rejected for substantially the same reasons.
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Buy (“Automated Testing of Classes”) in view of Chandra (US 2006/0161833) in further view of Ortega et al. (US 2022/0129371) (art of record – hereinafter Ortega).
As to claim 8, Buy/Chandra discloses the method according to claim 1 (see rejection of claim 1 above), but does not explicitly disclose further comprising: traversing each line of code in the target test case to identify exception code included in the target test case; and if it is determined that a variation of a comprehensive coverage rate obtained after code testing is performed based on another code different from the exception code in the target test case is less than a determined variation, deleting the exception code.
However, in an analogous art, Ortega discloses further comprising:
traversing each line of code in the target test case to identify exception code included in the target test case; (e.g., Ortega, par. [0142]: each program instruction may be considered in an order by traversal of program instructions within execution log; par. [0172]: generating a unit test based on a sequence from a log; par. [0082]: Fig. 4A shows code section 400; par. [0083]: if an exception is thrown then exit point 408-2 is executed raising an exception) and
if it is determined that a variation of a comprehensive coverage rate obtained after code testing is performed based on another code different from the exception code in the target test case is less than a determined variation, deleting the exception code (e.g., Ortega, par. [0139]: iteratively removing a program instruction from the sequence of program instructions and attempting to execute the remaining program instructions [another code different from the code in the target test case]; par. [0141]: if resulting coverage is the same as the base coverage [less than a determined variation], then the removed instruction has not affected coverage. Thus, the removed instruction is not deemed necessary and the removed program instruction is not included in filtered subsequence of program instructions [i.e., deleted from the original sequence]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the target test case of Buy to include traversing each line of code in the target test case to identity exception code included in the target test case; and if it is determined that a variation of a comprehensive coverage rate obtained after code testing is performed based on another code different from the exception code in the target test case is less than a determined variation, deleting the exception code, as taught by Ortega. Ortega would provide the advantage of a means of improved efficiency because unnecessary code would not be included in the test. (See Ortega, par. [0141]).
As to claim 16, it is a system claim having limitations substantially the same as those of claim 8. Accordingly, it is rejected for substantially the same reasons.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TODD AGUILERA whose telephone number is (571)270-5186. The examiner can normally be reached M-F 11AM - 7:30PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S Sough can be reached at (571)272-6799. 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.
/TODD AGUILERA/Primary Examiner, Art Unit 2192
Prosecution Insights