DETAILED ACTION
This action is responsive to the application filed on January 22, 2024.
The preliminary amendments filed on April 07, 2024 has been acknowledged and considered.
Claims 1-15 have been canceled.
Claims 16-30 are pending and are 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.
Drawings
The drawings are objected to because the unlabeled rectangular, circular, and triangular boxes shown in figures 1-3 should be provided with descriptive text labels. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because contains phrase as “disclosed is” and includes numeric references (e.g., 302, 204, 310, 308, 312) that need to be removed from it. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Claim Objections
Claims 24-30 are objected to because of the following informalities:
Claim 24, line 6, before “determining” should “and” be --for--?.
Claims 25-30 depend on the objected claims and inherit the same issue.
Appropriate correction is required.
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 16-20 and 23-28 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Chopra et al. (US Pat. No. 10,146,668 – hereinafter Chopra).
With respect to claim 16 (new), Chopra teaches a method for creating a synthesized test data having a predefined test case coverage (see abstract), the method comprising: processing a query for extracting a plurality of test cases and for determining a data storage location of input test data corresponding to the plurality of test cases (see abstract, “A code coverage tool applies predefined rules applicable to user input to determine a test scenario from predefined test cases to best achieve a code coverage goal. For example, the code coverage goal may specify a target percentage of code coverage for areas, functions, conditions, or statement of interest to the user. The user input may select built-in rules or user supplied rules, and the user input may specify areas or functions that are mapped to the test cases. The built-in rules prioritize selected test cases for execution at run time to provide code coverage maximization with minimum utilization of resources. The user input may also specify a type of coverage, a test case priority, and a test case type.”). See column 3 lines 53-60, “The database engine 42 stores rules 45 and code coverage details 46 for each test case. The rules 45 include built-in rules that prioritize selected ones of the test cases for execution at run time to provide code coverage maximization with minimum utilization of computer resources. The rules 45 may also include user-defined rules that specify how the user prefers the code coverage testing of the computer software to be run.”. See column 4 lines 5-14, “During use of the intelligent code coverage tool 33, the database engine 42 takes user input from the user interface 41, and stores the user input or uses the user input to update the rules 45, code coverage details 46, or mapping 47. When the user input request a code coverage run to be performed, the database engine 42 feeds the applicable user input, rules, code coverage details, and mapping information to the execution engine 43, and the database engine 42 requests the execution engine 43 to determine an appropriate test case scenario.”. See column 4 lines 15-23 and figure 2 (and related text), “The execution engine 43 includes a query engine 48 and a decision making module 49. When the execution engine 43 receives data and a request for a code coverage run, the query engine 48 formulates a query based on the data, and sends the query to the decision making module 49. The decision making module 49 finds a best possible way to run one or more of the test cases to get a percentage of code coverage specified by the user or else specified by a default value from the code coverage details 46.”. See column 5 lines 28-40 and figure 3 (and related text), “FIG. 3 shows a display screen 61 that the user interface presents to the user. The display screen 61 provides respective fill-in fields for the user to enter a path name for a directory containing the application code base, a path name for a directory containing the test cases, a coverage type (specifying area, function, conditions and/or statements), a specified percentage of code coverage, a test case priority (specifying high, medium or low), and a test case type (specifying either unique or repetitive). The display screen 61 also provides drop-down menus to create, view, and edit customized rules, or view built-in rules, or set or map test cases with areas or functions. The display screen 61 also provides a button to start or run code coverage tests.”. Furthermore, see figures 4-5 (and related text), getting location for the code base and for the test case repository, get type of coverage, % of coverage, test case priority and test case type).
PNG
media_image1.png
268
301
media_image1.png
Greyscale
extracting the input test data from a data repository and executing the plurality of test cases on the input test data for determining individual test case coverage percentages of the input test data (see abstract, “A code coverage tool applies predefined rules applicable to user input to determine a test scenario from predefined test cases to best achieve a code coverage goal. For example, the code coverage goal may specify a target percentage of code coverage for areas, functions, conditions, or statement of interest to the user. The user input may select built-in rules or user supplied rules, and the user input may specify areas or functions that are mapped to the test cases. The built-in rules prioritize selected test cases for execution at run time to provide code coverage maximization with minimum utilization of resources. The user input may also specify a type of coverage, a test case priority, and a test case type.”). See column 3 lines 53-60, “The database engine 42 stores rules 45 and code coverage details 46 for each test case. The rules 45 include built-in rules that prioritize selected ones of the test cases for execution at run time to provide code coverage maximization with minimum utilization of computer resources. The rules 45 may also include user-defined rules that specify how the user prefers the code coverage testing of the computer software to be run.”. See column 4 lines 5-14, “During use of the intelligent code coverage tool 33, the database engine 42 takes user input from the user interface 41, and stores the user input or uses the user input to update the rules 45, code coverage details 46, or mapping 47. When the user input request a code coverage run to be performed, the database engine 42 feeds the applicable user input, rules, code coverage details, and mapping information to the execution engine 43, and the database engine 42 requests the execution engine 43 to determine an appropriate test case scenario.”. See column 4 lines 15-23 and figure 2 (and related text), “The execution engine 43 includes a query engine 48 and a decision making module 49. When the execution engine 43 receives data and a request for a code coverage run, the query engine 48 formulates a query based on the data, and sends the query to the decision making module 49. The decision making module 49 finds a best possible way to run one or more of the test cases to get a percentage of code coverage specified by the user or else specified by a default value from the code coverage details 46.”. See column 5 lines 28-40 and figure 3 (and related text), “FIG. 3 shows a display screen 61 that the user interface presents to the user. The display screen 61 provides respective fill-in fields for the user to enter a path name for a directory containing the application code base, a path name for a directory containing the test cases, a coverage type (specifying area, function, conditions and/or statements), a specified percentage of code coverage, a test case priority (specifying high, medium or low), and a test case type (specifying either unique or repetitive). The display screen 61 also provides drop-down menus to create, view, and edit customized rules, or view built-in rules, or set or map test cases with areas or functions. The display screen 61 also provides a button to start or run code coverage tests.”. Furthermore, see figures 4-5 (and related text), getting location for the code base and for the test case repository, get type of coverage, % of coverage, test case priority and test case type). determining an overall test case coverage of the input test data, based on the individual test case coverage percentages of the input test data (see figure 6 (and related text) and column 6 line 58 – column 8 line 55, “As shown in FIG. 6, the expected result of each test case in each of the six test scenarios is that the test case should be successful. However, there could be test cases for which it would be normal and expected for a test case to result in an unsuccessful operation. For example, it would be normal and expected for a password-protected storage device to deny access when presented with a randomly-generated password. In one implementation, the decision making module first selects a particular one of multiple pre-defined goal-directing rules based on user input, and then applies other applicable rules to select or construct a series of the test cases that best meets the objective of the particular goal-directing rule. For example, the multiple goal-directing rules may include the following:
1. Run minimum number of test-cases that can give greater than 70% of code coverage. 2. Run minimum number of test-cases that can cover an area (example: backup, recover) up to 80-90%. of code coverage. 3. Run minimum number of test-cases that can give maximum code coverage for high priority test-cases. 4. Run minimum number of test-cases which can cover a specified maximum percentage (provide by user or else a default value of 80%) of functions in a given area.
For example, assume that the user interface receives the following inputs from the user: a. Code Base Path b. Test-cases Path. c. Coverage Type is Area. d. Coverage % is 70. e. Test-Case Priority is high. f. Test-Case Type is Unique. g. A user-defined rule to pick the minimum number of test-cases that can cover “x” percentage provided as user input, and the user specifies 70%. In response to this user input, the database engine sends the applicable data to the query engine, and the query module formulates and sends an appropriate query to the decision making module. In response to the query, the decision making module applies the applicable rules (either user-defined or predefined). In this example, the query is the goal of the user defined rule (i.e., get the minimum number of test-cases that can cover up to 70% of the code having all high priority test-cases and unique ones).”). when the overall test case coverage of the input test data is less than the predefined test case coverage, identifying one or more test cases amongst the plurality of test cases for which individual test case coverage percentage of the input test data is less than a predefined value (see column 3 lines 15-23, “For any particular code coverage run, the user may specify target percentages (e.g., 70%) of code coverage for functions, conditions, or statements, and the run terminates once the run achieves the specified target percentages. During any code coverage run, a coverage bitmap 38 is maintained in the random access memory 27. The code coverage run sets a respective bit in the coverage bitmap 38 to record that a function, condition, or statement of interest has been executed or achieved during the code coverage run.”. See column 3 lines 24-46, “If a percentage of code coverage is of interest for the functions, conditions, or statements of interest, then one or more coverage counters 39 may be maintained in the random access memory 27. For example, a coverage counter for the functions of interest is initially set to zero at the very beginning of a code coverage run, and this coverage counter for the functions is incremented by one for each function of interest that has been executed during the run. At the end of the run, the percentage of code coverage is computed by dividing the code coverage count for the functions by the total number of the functions, and multiplying the quotient by one-hundred. The coverage counter can be incremented either dynamically during the run whenever a function of interest is executed for the first time during the run, or the coverage counter can be incremented at the end of the run (or when the run is temporarily suspended) while scanning the bits in the coverage bitmap 36 for the functions of interest. For example, so long as there is no desire to terminate the run as soon as a coverage percentage has been reached, the coverage counter is incremented at the end of the run while scanning the bits in the coverage bitmap 36 to count the number of bits that have been set for the functions of interest.”). analyzing a distribution of the input test data, with respect to conditions in the one or more test cases (see abstract, “A code coverage tool applies predefined rules applicable to user input to determine a test scenario from predefined test cases to best achieve a code coverage goal. For example, the code coverage goal may specify a target percentage of code coverage for areas, functions, conditions, or statement of interest to the user. The user input may select built-in rules or user supplied rules, and the user input may specify areas or functions that are mapped to the test cases. The built-in rules prioritize selected test cases for execution at run time to provide code coverage maximization with minimum utilization of resources. The user input may also specify a type of coverage, a test case priority, and a test case type.”). See column 3 lines 53-60, “The database engine 42 stores rules 45 and code coverage details 46 for each test case. The rules 45 include built-in rules that prioritize selected ones of the test cases for execution at run time to provide code coverage maximization with minimum utilization of computer resources. The rules 45 may also include user-defined rules that specify how the user prefers the code coverage testing of the computer software to be run.”. See column 4 lines 5-14, “During use of the intelligent code coverage tool 33, the database engine 42 takes user input from the user interface 41, and stores the user input or uses the user input to update the rules 45, code coverage details 46, or mapping 47. When the user input request a code coverage run to be performed, the database engine 42 feeds the applicable user input, rules, code coverage details, and mapping information to the execution engine 43, and the database engine 42 requests the execution engine 43 to determine an appropriate test case scenario.”. See column 4 lines 15-23 and figure 2 (and related text), “The execution engine 43 includes a query engine 48 and a decision making module 49. When the execution engine 43 receives data and a request for a code coverage run, the query engine 48 formulates a query based on the data, and sends the query to the decision making module 49. The decision making module 49 finds a best possible way to run one or more of the test cases to get a percentage of code coverage specified by the user or else specified by a default value from the code coverage details 46.”. See column 5 lines 28-40 and figure 3 (and related text), “FIG. 3 shows a display screen 61 that the user interface presents to the user. The display screen 61 provides respective fill-in fields for the user to enter a path name for a directory containing the application code base, a path name for a directory containing the test cases, a coverage type (specifying area, function, conditions and/or statements), a specified percentage of code coverage, a test case priority (specifying high, medium or low), and a test case type (specifying either unique or repetitive). The display screen 61 also provides drop-down menus to create, view, and edit customized rules, or view built-in rules, or set or map test cases with areas or functions. The display screen 61 also provides a button to start or run code coverage tests.”. Furthermore, see figures 4-5 (and related text), getting location for the code base and for the test case repository, get type of coverage, % of coverage, test case priority and test case type) and rebalancing the input test data based on the distribution of the input test data, for producing the synthesized test data, wherein the input test data is rebalanced for covering the conditions in the one or more test cases in a manner that an overall test case coverage of the synthesized test data would be equal to or greater than the predefined test case coverage (see abstract and column 2 line 37 - column 3 line 46, “For code coverage testing of programs in the application code base 31, the code coverage tool 33 has intelligence for determining an appropriate test case scenario from predefined test cases in order to maximize the coverage while minimizing processing time and resources. For example, the test case scenario is a selected test case or a selected sequence of the test cases, which may be modified by changing default parameters of the test cases. The intelligence is encoded in predefined rules, and the test case scenario is determined by applying the predefined rules that are applicable to input data from a user. The code coverage tool 33 can prioritize test case runs at runtime, based on configuration parameters. The code coverage tool 33 may also customize options for reducing user intervention while also providing user flexibility in adapting the code coverage tool 33 to different programming environments and application domains.”. See figure 6 (and related text) and column 6 line 58 – column 8 line 55, “As shown in FIG. 6, the expected result of each test case in each of the six test scenarios is that the test case should be successful. However, there could be test cases for which it would be normal and expected for a test case to result in an unsuccessful operation. For example, it would be normal and expected for a password-protected storage device to deny access when presented with a randomly-generated password. In one implementation, the decision making module first selects a particular one of multiple pre-defined goal-directing rules based on user input, and then applies other applicable rules to select or construct a series of the test cases that best meets the objective of the particular goal-directing rule. For example, the multiple goal-directing rules may include the following:
1. Run minimum number of test-cases that can give greater than 70% of code coverage. 2. Run minimum number of test-cases that can cover an area (example: backup, recover) up to 80-90%. of code coverage. 3. Run minimum number of test-cases that can give maximum code coverage for high priority test-cases. 4. Run minimum number of test-cases which can cover a specified maximum percentage (provide by user or else a default value of 80%) of functions in a given area.
For example, assume that the user interface receives the following inputs from the user: a. Code Base Path b. Test-cases Path. c. Coverage Type is Area. d. Coverage % is 70. e. Test-Case Priority is high. f. Test-Case Type is Unique. g. A user-defined rule to pick the minimum number of test-cases that can cover “x” percentage provided as user input, and the user specifies 70%. In response to this user input, the database engine sends the applicable data to the query engine, and the query module formulates and sends an appropriate query to the decision making module. In response to the query, the decision making module applies the applicable rules (either user-defined or predefined). In this example, the query is the goal of the user defined rule (i.e., get the minimum number of test-cases that can cover up to 70% of the code having all high priority test-cases and unique ones).”). With respect to claim 17 (new), Chopra teaches wherein the predefined test case coverage lies in a range of 80 percent to 99.9 percent, and wherein the predefined value lies in a range of 60 percent to 99.9 percent (see figure 6 (and related text) and column 6 line 58 – column 8 line 55, “As shown in FIG. 6, the expected result of each test case in each of the six test scenarios is that the test case should be successful. However, there could be test cases for which it would be normal and expected for a test case to result in an unsuccessful operation. For example, it would be normal and expected for a password-protected storage device to deny access when presented with a randomly-generated password. In one implementation, the decision making module first selects a particular one of multiple pre-defined goal-directing rules based on user input, and then applies other applicable rules to select or construct a series of the test cases that best meets the objective of the particular goal-directing rule. For example, the multiple goal-directing rules may include the following:
1. Run minimum number of test-cases that can give greater than 70% of code coverage. 2. Run minimum number of test-cases that can cover an area (example: backup, recover) up to 80-90%. of code coverage. 3. Run minimum number of test-cases that can give maximum code coverage for high priority test-cases. 4. Run minimum number of test-cases which can cover a specified maximum percentage (provide by user or else a default value of 80%) of functions in a given area.
For example, assume that the user interface receives the following inputs from the user: a. Code Base Path b. Test-cases Path. c. Coverage Type is Area. d. Coverage % is 70. e. Test-Case Priority is high. f. Test-Case Type is Unique. g. A user-defined rule to pick the minimum number of test-cases that can cover “x” percentage provided as user input, and the user specifies 70%. In response to this user input, the database engine sends the applicable data to the query engine, and the query module formulates and sends an appropriate query to the decision making module. In response to the query, the decision making module applies the applicable rules (either user-defined or predefined). In this example, the query is the goal of the user defined rule (i.e., get the minimum number of test-cases that can cover up to 70% of the code having all high priority test-cases and unique ones).”). With respect to claim 18 (new), Chopra teaches wherein the step of rebalancing the input test data comprises at least one of: altering a portion of the input test data; adding new test data to the input test data; adjusting the distribution of the input test data across different conditions in the plurality of test cases; validating the input test data; and removing redundancy in the input test data (see column 2 lines 37-53, “For code coverage testing of programs in the application code base 31, the code coverage tool 33 has intelligence for determining an appropriate test case scenario from predefined test cases in order to maximize the coverage while minimizing processing time and resources. For example, the test case scenario is a selected test case or a selected sequence of the test cases, which may be modified by changing default parameters of the test cases. The intelligence is encoded in predefined rules, and the test case scenario is determined by applying the predefined rules that are applicable to input data from a user. The code coverage tool 33 can prioritize test case runs at runtime, based on configuration parameters. The code coverage tool 33 may also customize options for reducing user intervention while also providing user flexibility in adapting the code coverage tool 33 to different programming environments and application domains.”. See column 3 lines 15-23, “For code coverage testing of programs in the application code base 31, the code coverage tool 33 has intelligence for determining an appropriate test case scenario from predefined test cases in order to maximize the coverage while minimizing processing time and resources. For example, the test case scenario is a selected test case or a selected sequence of the test cases, which may be modified by changing default parameters of the test cases. The intelligence is encoded in predefined rules, and the test case scenario is determined by applying the predefined rules that are applicable to input data from a user. The code coverage tool 33 can prioritize test case runs at runtime, based on configuration parameters. The code coverage tool 33 may also customize options for reducing user intervention while also providing user flexibility in adapting the code coverage tool 33 to different programming environments and application domains.”. See column 3 lines 53-60, “The database engine 42 stores rules 45 and code coverage details 46 for each test case. The rules 45 include built-in rules that prioritize selected ones of the test cases for execution at run time to provide code coverage maximization with minimum utilization of computer resources. The rules 45 may also include user-defined rules that specify how the user prefers the code coverage testing of the computer software to be run.”. Furthermore, see column 5 lines 6-27, “The rules 45 may include rules for test cases that specifically involve various types of operating systems, and prioritize test cases for a run with a WINDOWS operating system or a run with a UNIX operating system. As internally most UNIX operating systems will have similar implementations and control flows, the test cases are prioritized in this way in order to minimize the number of test cases. The rules 45 may include rules to keep test cases involving repetitive runs on multiple machines based on test cases, low on priority. Although they contribute towards testing scalability and parallelism, they do not contribute much towards code coverage. The rules 45 may include rules for test cases that contain operations that spawn similar processes internally, and these test cases should be kept low on priority to maximize code coverage. The rules 45 may include rules for test cases that deal with operations that have a minimum number of inputs. These test cases can be done so that the access of the same piece of code can be avoided. For example, test cases that involve a single device/volume/clone/saveset may be run without branching into more complex scenarios.”). With respect to claim 19 (new), Chopra teaches further comprising at least one of: creating the plurality of test cases; and accessing a record of pre-created test cases that is stored at the data repository (see abstract and figure 3 (and related text), “A code coverage tool applies predefined rules applicable to user input to determine a test scenario from predefined test cases to best achieve a code coverage goal.”. See column 2 lines 37-53, “For code coverage testing of programs in the application code base 31, the code coverage tool 33 has intelligence for determining an appropriate test case scenario from predefined test cases in order to maximize the coverage while minimizing processing time and resources. For example, the test case scenario is a selected test case or a selected sequence of the test cases, which may be modified by changing default parameters of the test cases. The intelligence is encoded in predefined rules, and the test case scenario is determined by applying the predefined rules that are applicable to input data from a user. The code coverage tool 33 can prioritize test case runs at runtime, based on configuration parameters. The code coverage tool 33 may also customize options for reducing user intervention while also providing user flexibility in adapting the code coverage tool 33 to different programming environments and application domains.”. See column 3 lines 53-60, “The database engine 42 stores rules 45 and code coverage details 46 for each test case. The rules 45 include built-in rules that prioritize selected ones of the test cases for execution at run time to provide code coverage maximization with minimum utilization of computer resources. The rules 45 may also include user-defined rules that specify how the user prefers the code coverage testing of the computer software to be run.”). With respect to claim 20 (new), Chopra teaches further comprising generating a test case coverage report indicative of at least one of: the individual test case coverage percentages, the overall test case coverage, the one or more test cases a portion of the input test data which covers a given test case, a portion of the query which indicates a given test case, a coverage status of each condition of a given test case (see column 4 lines 15-35, “The execution engine 43 includes a query engine 48 and a decision making module 49. When the execution engine 43 receives data and a request for a code coverage run, the query engine 48 formulates a query based on the data, and sends the query to the decision making module 49. The decision making module 49 finds a best possible way to run one or more of the test cases to get a percentage of code coverage specified by the user or else specified by a default value from the code coverage details 46. The decision making module 49 considers different combinations of the test cases and applies built-in or user-defined rules, along with the mappings of the test cases to areas or functions of interest to the user. For example, the decision making module 49 employs goal-directed backward chaining of the rules, as described in Erman et al. U.S. Pat. No. 4,658,370 issued Apr. 14, 1987, incorporated herein by reference in its entirety, and Hardy et al, U.S. Pat. No. 4,648,044 issued Mar. 3, 1987, incorporated herein by reference in its entirety. The decision making module 49 then executes the test case scenario with the best possible sequence of test case execution to achieve the desired percentage of code execution.”. Furthermore, see figure 5 (and related text), failure message/report). With respect to claim 23 (new), Chopra teaches further comprising storing the synthesized test data at the data repository (see column 3 line 53 – column 4 line 4, “The database engine 42 stores rules 45 and code coverage details 46 for each test case. The rules 45 include built-in rules that prioritize selected ones of the test cases for execution at run time to provide code coverage maximization with minimum utilization of computer resources. The rules 45 may also include user-defined rules that specify how the user prefers the code coverage testing of the computer software to be run. The database engine 43 also stores the mapping 47 of test cases to areas and functions. For example, the areas and functions are specified by file names and the names of functions, methods, or subroutines in the files. The areas or functions may also be specified in more general terms as understood by a user, in which case the mapping 47 maps these general terms to the names of particular application files or the names of functions within the particular application files. For example, for subject matter relating to data storage systems, the general terms may include backup, recovery, replication, and de-duplication.”. See column 5 lines 54-59, “The operation sequence also continues from block 74 to block 76 if the user does not select the option to add customized rules. In block 76, the rules and code coverage tool related data or information is stored in the data base of the data base engine. Execution continues form block 76 to block 77 of FIG. 5.”).
With respect to claims 24-28, the claims are directed to a system that corresponds to the method recited in claims 16-20, respectively (see the rejection of claims 16-20 above; wherein Chopra also teaches such system in figures 1-2).
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 21-22 and 29-30 are rejected under 35 U.S.C. 103 as being unpatentable over Chopra et al. (US Pat. No. 10,146,668) in view of Dundigalla et al. (US Pub. No. 2022/0035730 – hereinafter Dundigalla). With respect to claim 21 (new), Chopra is silent to disclose, however in an analogous art, Dundigalla teaches wherein the input test data has same schema, data type and statistical properties as a production data and is one of: the production data, an obfuscated subset of the production data, mock data (see figures 1-2 (and related text) and paragraphs [0035], [0043], [0046]-[0047], [0076]). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the Chopra’s teaching, which uses a code coverage tool applies predefined rules applicable to user input to determine a test scenario from predefined test cases to best achieve a code coverage goal, by utilizing schema, data type and statistical properties as a production data and is one of: the production data, an obfuscated subset of the production data, mock data as suggested by Dundigalla, as Dundigalla would provide an efficient way to generate testcases and testing data for application development. With respect to claim 22 (new), Chopra is silent to disclose, however in an analogous art, Dundigalla teaches further comprising removing sensitive data from the input test data (see paragraphs [0035], [0043], [0046], [0076], “The system may then begin collecting testing data along the identified paths from the flow graph. The testing data may be, for instance, the types of data that may be processed by the developing application once it is deployed in the production environment. Accordingly, the testing data may include data information as a user name, contact information, account information, account history, and the like, that may be processed by the application for each path identified within the flow graph. In scenarios in which the testing data contains potentially sensitive information (e.g., PII), the testing data may be sanitized by the system to remove all sensitive information from the testing data before being introduced into the testing environment. Once the testing data has been collected, the testing data, along with the various network navigation paths identified using the flow graph, may be used by developers in the testing process (e.g., for regression testing).”.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the Chopra’s teaching, which uses a code coverage tool applies predefined rules applicable to user input to determine a test scenario from predefined test cases to best achieve a code coverage goal, by comprising removing sensitive data from the input test data as suggested by Dundigalla, as Dundigalla would provide an efficient way to generate testcases and testing data for application development. With respect to claims 29-30, the claims are directed to a system that corresponds to the method recited in claims 21-22, respectively (see the rejection of claims 21-22 above).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Hicks et al. (US Pub. No. 2025/0156304) discloses method and apparatus for system testing. A code base is accessed. A first section of the code base that is explicitly covered by a first test case is identified. A second section of the code base is modified, where the second section is not explicitly covered by the first test case. The first test case is executed on the code base with the modification of the second section of the code base. Based on determining that the execution of the first test case fails, the second section of the code base is determined to be implicitly covered by the first test case. (see abstract).
Hu et al. (US Pub. No. 2025/0036556) discloses methods, system, and non-transitory processor-readable storage medium for a test selection system. An example method includes selecting a regression test case from a plurality of regression test cases in a software testing lifecycle system. A test selection system calculates a score for the regression test case using an Analytic Hierarchy Process (AHP) assigned weight. Using the score, the test selection system visualizes a relationship between the regression test case and goals associated with a regression testing effort. The test selection system selects the regression test case for use in the regression testing effort based on the visualized relationship, and executes the regression test case on a system. (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