DETAILED ACTION
This action is in response to the claims filed August 31, 2024. Claims 1-20 are pending. Claims 1, 8, and 15 are independent claims.
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 .
Claim Objections
Claims 7, 14, and 20 objected to because of the following informalities:
- Claims 7, 14, and 20 recite “fourth-computer-based test”. This should likely read “fourth computer-based test”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112(b)
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 8-20 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 8 recites the limitation "the computer platform" in lines 5, 7, 9, and 11. There is insufficient antecedent basis for this limitation in the claim. For the purposes of examination, “the computer platform” is interpreted to read “a computer platform”. Claims 9-14 are rejected in view of their dependency on claim 8. Analogous claim 15 is rejected for the same reason as claim 8. Claims 16-20 are rejected in view of their dependency on claim 15.
Claim 8 recites the limitation "the plurality of computer-based tests" in lines 6, 8, 10, and 12. There is insufficient antecedent basis for this limitation in the claim. For the purposes of examination, “the plurality of computer based tests” is interpreted to read “a computer platform”. Claims 9-14 are rejected in view of their dependency on claim 8. Analogous claim 15 is rejected for the same reason as claim 8. Claims 16-20 are rejected in view of their dependency on claim 15.
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 8-14 are rejected under 35 U.S.C. 101 because the claimed subject matter is directed to non-statutory subject matter.
Claim 8 is directed to “a computer readable storage medium”. However, it is noted that the specification does not provide an explicit definition of what constitutes a “computer readable storage medium”. The broadest reasonable interpretation of a claim drawn to a “computer readable storage medium” typically covers forms of non-transitory tangible media and transitory propagating signals per se in view of the ordinary and customary meaning of “a computer readable storage medium”, particularly when the specification is silent. See MPEP § 2111.01. When the broadest reasonable interpretation of a claim covers a signal per se, the claim must be rejected under 35 US.C. § 101 as covering non-statutory subject matter. See In re Nuijten, 500 F.3d 1346, 1356-57 (Fed. Cir. 2007) (transitory embodiments are not directed to statutory subject matter) and Interim Examination Instructions for Evaluating Subject Matter Eligibility Under 35 U.S.C. § 101, Aug. 24, 2009; p. 2. Therefore, the claimed “computer readable storage medium” is ineligible subject matter under § 101. Applicant is advised to amend the claim to recite “A non-transitory computer-readable storage medium” in order to overcome the 35 U.S.C. § 101 rejection.
Claims 9-14 depend on Claim 8 and do not cure the deficiency of Claim 8. Therefore, Claims 9-14 are rejected for the same reason set forth in the rejection of Claim 8.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 8 and 15 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by US 20150039941 A1 (hereinafter “Kalyanasundram”).
Regarding claim 8, Kalyanasundram discloses:
A computer program product residing on a computer readable storage medium having a plurality of instructions stored thereon which, when executed across one or more processors, causes at least a portion of the one or more processors to perform operations comprising (Figure 1):
- configuring, from the computer platform, a first computer-based test among the plurality of computer-based tests for execution with a first software application (Figure 2; Paragraph [0045], “For example, the memory 214 may hold instructions that, when executed by the processor 212, cause the testing coordinator 210 to identify a test case 251 stored in the central repository 240, initiate, via the network 360, testing of the first component application 232, 330 by the first test tool 320 using the test data set 265 and the first set of scripts 275”; Paragraph [0033], “To test the ACH transaction process, the testing coordinator 210 may be configured to coordinate the operation of the component applications 232, 234, 236, as discussed above. For example, the testing coordinator 210 may be configured to process shell scripts and/or file system objects provided by one or more test tools associated with the component applications 232, 234, 236. To begin testing the ACH transaction process, the testing coordinator 210 may provide test data 260 and/or test scripts 270 associated with a test case 251 for testing the ACH transaction process. For example, test tools associated with the first component application 232 may process at least a portion of the test data 260 using a portion of the test scripts 270 to cause the first component application 232 to generate a transaction file based on the data. The testing coordinator 210 may monitor the testing of the first component application 232 for an indication of success or failure of the component application test”) [Examiner’s remarks: A first test is run for a first component (application) out of a plurality of tests. While Kalyanasundram uses ACH transaction processes as a specific example, the first component may be any component.];
- configuring, from the computer platform, a second computer-based test among the plurality of computer-based tests for execution with a second software application (Figure 2; Paragraph [0045], “The testing coordinator 210 may then initiate, via the network, upon completion of testing of the first component application 232, 330, testing of the second component application 234 by a second test tool 320 using the test data set 265 and the second set of scripts 275”; Paragraph [0034], “The testing coordinator 210 may initiate a test the second component application 234 by the test tools associated with the second component application 234 and using the updated test data set 260 and at least a portion of the test scripts 270. For example, the second component application 234 may process the transaction files into a format required by a particular financial institution, as may be defined in the test case and/or may process information representative that the transaction files were received at the financial institution. The test tools and/or the testing coordinator 210 may determine whether the second component application completed successfully”) [Examiner’s remarks: A second test is run for a second component (application) out of a plurality of tests. While Kalyanasundram uses processing transaction files as a specific example, the second component may be any component.];
- configuring, from the computer platform, a third computer-based test among the plurality of computer-based tests for execution with a third software application (Figure 2; Paragraph [0036], “The testing coordinator 210 may initiate a test of the third component application 236 by the test tools associated with the third component application 236 using the updated test data set 260 and at least a portion of the test scripts 270. The third component application 236 may be tested to simulate receiving communications from the second financial institution about the success and/or failure of the transaction. The testing coordinator 210 may monitor the testing of the third component application 236 for an indication of success or failure of the component application test”) [Examiner’s remarks: A third test is run for a third component (application) out of a plurality of tests. While Kalyanasundram uses receiving communications as a specific example, the third component may be any component.];
- configuring, from the computer platform, a fourth computer-based test among the plurality of computer-based tests for execution with a fourth software application (Figure 2; Paragraph [0045], “After initiating a test of a final component application 238, the testing coordinator 210 may provide an indication of whether the test of the multi-step process 220 completed successfully using results obtained from the test tools associated with each of the component applications 230, such as the first test tool 320 and the second test tool 320”; Paragraph [0035], “The testing coordinator 210 may initiate the test of the fourth component application 235 concurrently to the initiation of test of the second component application 234 or during the test of the second component application 234. The test tools and/or the testing coordinator 210 may determine whether the fourth component application completed successfully. For example, the testing coordinator 210 may monitor the testing of the fourth component application 235 for an indication of success or failure of the component application test”]) [Examiner’s remarks: A fourth test is run for a fourth component (application) out of a plurality of tests.]; and
- executing each of the first computer-based test, the second computer-based test, the third computer-based test, and the fourth computer-based test from the computer platform (Paragraph [0045], “After initiating a test of a final component application 238, the testing coordinator 210 may provide an indication of whether the test of the multi-step process 220 completed successfully using results obtained from the test tools associated with each of the component applications 230, such as the first test tool 320 and the second test tool 320”; Paragraph [0033], “The testing coordinator 210 may monitor the testing of the first component application 232 for an indication of success or failure of the component application test”; Paragraph [0034], “The testing coordinator 210 may initiate a test the second component application 234 by the test tools associated with the second component application 234 and using the updated test data set 260 and at least a portion of the test scripts 270…The test tools and/or the testing coordinator 210 may determine whether the second component application completed successfully”; Paragraph [0036], “The testing coordinator 210 may initiate a test of the third component application 236 by the test tools associated with the third component application 236 using the updated test data set 260 and at least a portion of the test scripts 270… The testing coordinator 210 may monitor the testing of the third component application 236 for an indication of success or failure of the component application test”; Paragraph [0035], “The testing coordinator 210 may initiate the test of the fourth component application 235 concurrently to the initiation of test of the second component application 234 or during the test of the second component application 234. The test tools and/or the testing coordinator 210 may determine whether the fourth component application completed successfully”]) [Examiner’s remarks: The first, second, third, and fourth tests for the first, second, third, and fourth application are run and the results are monitored.].
Regarding claim 15, Kalyanasundram discloses:
A computing system including one or more processors and one or more memories configured to perform operations comprising (Figure 1):
- configuring, from the computer platform, a first computer-based test among the plurality of computer-based tests for execution with a first software application (Figure 2; Paragraph [0045], “For example, the memory 214 may hold instructions that, when executed by the processor 212, cause the testing coordinator 210 to identify a test case 251 stored in the central repository 240, initiate, via the network 360, testing of the first component application 232, 330 by the first test tool 320 using the test data set 265 and the first set of scripts 275”; Paragraph [0033], “To test the ACH transaction process, the testing coordinator 210 may be configured to coordinate the operation of the component applications 232, 234, 236, as discussed above. For example, the testing coordinator 210 may be configured to process shell scripts and/or file system objects provided by one or more test tools associated with the component applications 232, 234, 236. To begin testing the ACH transaction process, the testing coordinator 210 may provide test data 260 and/or test scripts 270 associated with a test case 251 for testing the ACH transaction process. For example, test tools associated with the first component application 232 may process at least a portion of the test data 260 using a portion of the test scripts 270 to cause the first component application 232 to generate a transaction file based on the data. The testing coordinator 210 may monitor the testing of the first component application 232 for an indication of success or failure of the component application test”) [Examiner’s remarks: A first test is run for a first component (application) out of a plurality of tests. While Kalyanasundram uses ACH transaction processes as a specific example, the first component may be any component.];
- configuring, from the computer platform, a second computer-based test among the plurality of computer-based tests for execution with a second software application (Figure 2; Paragraph [0045], “The testing coordinator 210 may then initiate, via the network, upon completion of testing of the first component application 232, 330, testing of the second component application 234 by a second test tool 320 using the test data set 265 and the second set of scripts 275”; Paragraph [0034], “The testing coordinator 210 may initiate a test the second component application 234 by the test tools associated with the second component application 234 and using the updated test data set 260 and at least a portion of the test scripts 270. For example, the second component application 234 may process the transaction files into a format required by a particular financial institution, as may be defined in the test case and/or may process information representative that the transaction files were received at the financial institution. The test tools and/or the testing coordinator 210 may determine whether the second component application completed successfully”) [Examiner’s remarks: A second test is run for a second component (application) out of a plurality of tests. While Kalyanasundram uses processing transaction files as a specific example, the second component may be any component.];
- configuring, from the computer platform, a third computer-based test among the plurality of computer-based tests for execution with a third software application (Figure 2; Paragraph [0036], “The testing coordinator 210 may initiate a test of the third component application 236 by the test tools associated with the third component application 236 using the updated test data set 260 and at least a portion of the test scripts 270. The third component application 236 may be tested to simulate receiving communications from the second financial institution about the success and/or failure of the transaction. The testing coordinator 210 may monitor the testing of the third component application 236 for an indication of success or failure of the component application test”) [Examiner’s remarks: A third test is run for a third component (application) out of a plurality of tests. While Kalyanasundram uses receiving communications as a specific example, the third component may be any component.];
- configuring, from the computer platform, a fourth computer-based test among the plurality of computer-based tests for execution with a fourth software application (Figure 2; Paragraph [0045], “After initiating a test of a final component application 238, the testing coordinator 210 may provide an indication of whether the test of the multi-step process 220 completed successfully using results obtained from the test tools associated with each of the component applications 230, such as the first test tool 320 and the second test tool 320”; Paragraph [0035], “The testing coordinator 210 may initiate the test of the fourth component application 235 concurrently to the initiation of test of the second component application 234 or during the test of the second component application 234. The test tools and/or the testing coordinator 210 may determine whether the fourth component application completed successfully. For example, the testing coordinator 210 may monitor the testing of the fourth component application 235 for an indication of success or failure of the component application test”]) [Examiner’s remarks: A fourth test is run for a fourth component (application) out of a plurality of tests.]; and
- executing each of the first computer-based test, the second computer-based test, the third computer-based test, and the fourth computer-based test from the computer platform (Paragraph [0045], “After initiating a test of a final component application 238, the testing coordinator 210 may provide an indication of whether the test of the multi-step process 220 completed successfully using results obtained from the test tools associated with each of the component applications 230, such as the first test tool 320 and the second test tool 320”; Paragraph [0033], “The testing coordinator 210 may monitor the testing of the first component application 232 for an indication of success or failure of the component application test”; Paragraph [0034], “The testing coordinator 210 may initiate a test the second component application 234 by the test tools associated with the second component application 234 and using the updated test data set 260 and at least a portion of the test scripts 270…The test tools and/or the testing coordinator 210 may determine whether the second component application completed successfully”; Paragraph [0036], “The testing coordinator 210 may initiate a test of the third component application 236 by the test tools associated with the third component application 236 using the updated test data set 260 and at least a portion of the test scripts 270… The testing coordinator 210 may monitor the testing of the third component application 236 for an indication of success or failure of the component application test”; Paragraph [0035], “The testing coordinator 210 may initiate the test of the fourth component application 235 concurrently to the initiation of test of the second component application 234 or during the test of the second component application 234. The test tools and/or the testing coordinator 210 may determine whether the fourth component application completed successfully”]) [Examiner’s remarks: The first, second, third, and fourth tests for the first, second, third, and fourth application are run and the results are monitored.].
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over US 20150039941 A1 (hereinafter “Kalyanasundram”), in view of “Combining Test Case Generation for Component and Integration Testing” by Sebastian Benz (hereinafter “Benz”).
Regarding claim 1, Kalyanasundram discloses:
A computer-implemented method, comprising:
…
- configuring, from the computer platform by the computing device, a first computer-based test among the plurality of computer-based tests for execution with a first software application (Figure 2; Paragraph [0045], “For example, the memory 214 may hold instructions that, when executed by the processor 212, cause the testing coordinator 210 to identify a test case 251 stored in the central repository 240, initiate, via the network 360, testing of the first component application 232, 330 by the first test tool 320 using the test data set 265 and the first set of scripts 275”; Paragraph [0033], “To test the ACH transaction process, the testing coordinator 210 may be configured to coordinate the operation of the component applications 232, 234, 236, as discussed above. For example, the testing coordinator 210 may be configured to process shell scripts and/or file system objects provided by one or more test tools associated with the component applications 232, 234, 236. To begin testing the ACH transaction process, the testing coordinator 210 may provide test data 260 and/or test scripts 270 associated with a test case 251 for testing the ACH transaction process. For example, test tools associated with the first component application 232 may process at least a portion of the test data 260 using a portion of the test scripts 270 to cause the first component application 232 to generate a transaction file based on the data. The testing coordinator 210 may monitor the testing of the first component application 232 for an indication of success or failure of the component application test”) [Examiner’s remarks: A first test is run for a first component (application) out of a plurality of tests. While Kalyanasundram uses ACH transaction processes as a specific example, the first component may be any component.];
- configuring, from the computer platform by the computing device, a second computer-based test among the plurality of computer-based tests for execution with a second software application (Figure 2; Paragraph [0045], “The testing coordinator 210 may then initiate, via the network, upon completion of testing of the first component application 232, 330, testing of the second component application 234 by a second test tool 320 using the test data set 265 and the second set of scripts 275”; Paragraph [0034], “The testing coordinator 210 may initiate a test the second component application 234 by the test tools associated with the second component application 234 and using the updated test data set 260 and at least a portion of the test scripts 270. For example, the second component application 234 may process the transaction files into a format required by a particular financial institution, as may be defined in the test case and/or may process information representative that the transaction files were received at the financial institution. The test tools and/or the testing coordinator 210 may determine whether the second component application completed successfully”) [Examiner’s remarks: A second test is run for a second component (application) out of a plurality of tests. While Kalyanasundram uses processing transaction files as a specific example, the second component may be any component.];
- configuring, from the computer platform by the computing device, a third computer-based test among the plurality of computer-based tests for execution with a third software application (Figure 2; Paragraph [0036], “The testing coordinator 210 may initiate a test of the third component application 236 by the test tools associated with the third component application 236 using the updated test data set 260 and at least a portion of the test scripts 270. The third component application 236 may be tested to simulate receiving communications from the second financial institution about the success and/or failure of the transaction. The testing coordinator 210 may monitor the testing of the third component application 236 for an indication of success or failure of the component application test”) [Examiner’s remarks: A third test is run for a third component (application) out of a plurality of tests. While Kalyanasundram uses receiving communications as a specific example, the third component may be any component.];
- configuring, from the computer platform by the computing device, a fourth computer-based test among the plurality of computer-based tests for execution with a fourth software application (Figure 2; Paragraph [0045], “After initiating a test of a final component application 238, the testing coordinator 210 may provide an indication of whether the test of the multi-step process 220 completed successfully using results obtained from the test tools associated with each of the component applications 230, such as the first test tool 320 and the second test tool 320”; Paragraph [0035], “The testing coordinator 210 may initiate the test of the fourth component application 235 concurrently to the initiation of test of the second component application 234 or during the test of the second component application 234. The test tools and/or the testing coordinator 210 may determine whether the fourth component application completed successfully. For example, the testing coordinator 210 may monitor the testing of the fourth component application 235 for an indication of success or failure of the component application test”]) [Examiner’s remarks: A fourth test is run for a fourth component (application) out of a plurality of tests.]; and
- executing, by the computing device, each of the first computer-based test, the second computer-based test, the third computer-based test, and the fourth computer-based test from the computer platform (Paragraph [0045], “After initiating a test of a final component application 238, the testing coordinator 210 may provide an indication of whether the test of the multi-step process 220 completed successfully using results obtained from the test tools associated with each of the component applications 230, such as the first test tool 320 and the second test tool 320”; Paragraph [0033], “The testing coordinator 210 may monitor the testing of the first component application 232 for an indication of success or failure of the component application test”; Paragraph [0034], “The testing coordinator 210 may initiate a test the second component application 234 by the test tools associated with the second component application 234 and using the updated test data set 260 and at least a portion of the test scripts 270…The test tools and/or the testing coordinator 210 may determine whether the second component application completed successfully”; Paragraph [0036], “The testing coordinator 210 may initiate a test of the third component application 236 by the test tools associated with the third component application 236 using the updated test data set 260 and at least a portion of the test scripts 270… The testing coordinator 210 may monitor the testing of the third component application 236 for an indication of success or failure of the component application test”; Paragraph [0035], “The testing coordinator 210 may initiate the test of the fourth component application 235 concurrently to the initiation of test of the second component application 234 or during the test of the second component application 234. The test tools and/or the testing coordinator 210 may determine whether the fourth component application completed successfully”]) [Examiner’s remarks: The first, second, third, and fourth tests for the first, second, third, and fourth application are run and the results are monitored.].
Kalyanasundram does not explicitly disclose:
- generating, by a computing device, a plurality of computer-based tests to be executed from a computer platform;
However, Benz discloses:
- generating, by a computing device, a plurality of computer-based tests to be executed from a computer platform (Page 24, “Each development step is accompanied by testing. Therefore the generation of test cases for each of the three phases of testing (component, integration, and system testing) is desirable. During component testing the focus lies on the interface-behavior and internal-behavior of a component”; Page 26, “With the application of task models, new task based test selection criteria are possible. These selection criteria focus on usage scenarios and provide a new possibility to measure the tested aspects of a system. Based on this coverage criteria task sequences are generated. Each of them represents a possible test case. The problem is, that such generated test cases are too abstract for execution, because of the test’s missing input and output behavior. To solve this problem each task will be mapped onto the existing component models. The mapping is performed by describing each task’s preconditions and postconditions by constraints on the underlying component models. With the information from the mapping it is possible to derive a task’s input behavior and expected output behavior from the component models and therefore enables the transformation of a task sequence to an executable test case”) [Examiner’s remarks: A computer is used to automatically generate a plurality of tests for component or integration testing.];
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Benz into the teachings of Kalyanasundram to include “generating, by a computing device, a plurality of computer-based tests to be executed from a computer platform”. As stated in Benz, “Model based test case generation is a promising approach to reduce the e ort of test case creation and enables the systematic selection of test cases. Furthermore in combination with an automated execution of test cases the automatic generation of test cases allows a continuous testing process during the development of a system” (Page 1). Automatic, computer-based test generation reduces the amount of time programmers must spend manually testing software, and instead, allows the process to be performed automatically. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with automated generation of test cases.
Claims 2, 4, and 6 are rejected under 35 U.S.C. 103 as being unpatentable over US 20150039941 A1 (hereinafter “Kalyanasundram”), in view of “Combining Test Case Generation for Component and Integration Testing” by Sebastian Benz (hereinafter “Benz”), further in view of “Serialization and Deserialization in Rest Assured API Testing” by Subashini Meganathan (hereinafter “Meganathan”), and further in view of “Generating Meaningful Test Databases” by Carsten Binnig (hereinafter “Binnig”).
Regarding claim 2, the rejection of claim 1 is incorporated; and Kalyanasundram further discloses:
- the first software application is a web-based software application (Paragraph [0030], “For example, testing of web-based component applications may be tested while a mainframe (e.g., server-based) application is being tested to better utilize testing resources (e.g., test machines)”),
The combination of Kalyanasundram and Benz does not explicitly disclose:
- the second application is an application programming interface (API) application, and
- the third application is a datastore application.
However, Meganathan discloses:
- the second application is an application programming interface (API) application (Title, “Serialization and Deserialization in Rest Assured API Testing”; Page 12, “Here, We will mock our LMS service sample response to use in our Rest Assured test”; Example test on Page 13) [Examiner’s remarks: Kalyanasundram discloses testing a second component. Meganathan discloses testing APIs. One of ordinary skill in the art understands that APIs are a component which may be testing in place of the second component.], and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Meganathan into the combined teachings of Kalyanasundram and Benz to include “the second application is an application programming interface (API) application”. Meganathan discloses testing of APIs. API testing is important to ensure that communication between different tests and components are happening as expected and that data is being transferred correctly. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with API testing.
The combination of Kalyanasundram, Benz, and Meganathan does not explicitly disclose:
- the third application is a datastore application.
However, Binnig discloses:
- the third application is a datastore application (Page 11-Page 12, “AutoDBT takes a specification of the user navigation (as a finite state machine), a data specification which defines constraints on the database for each transition in the user navigation, as well as an initial database state as input and generates test cases that can be executed on the given database state. Using the data specification, AutoDBT can track the database changes of each test case (i.e., AutoDBT can calculate a set of pre- and postconditions on the database state). Consequently, AutoDBT can decide whether the precondition of a test case holds (i.e., if the test case can be executed on the current database state) and whether the postcondition is satisfied when the test case was executed (i.e., if the database is in the expected state). For example, for a test case which deletes a given book of an E-Shop, AutoDBT will check (1) if the book exists before the test case is executed and (2) if the book was deleted successfully after the test case was executed”) [Examiner’s remarks: Binnig discloses testing of a datastore application (database) using AutoDBT.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Binnig into the combined teachings of Kalyanasundram, Benz, and Meganathan to include “the third application is a datastore application”. As stated in Binnig, “Consequently, AutoDBT can decide whether the precondition of a test case holds (i.e., if the test case can be executed on the current database state) and whether the postcondition is satisfied when the test case was executed (i.e., if the database is in the expected state)” (Page 12). Ensuring correctness of database states means that data being retrieved and saved is being completed correctly, thereby ensuring the accuracy of any transactions with the database. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with database testing.
Regarding claim 4, the rejection of claim 2 is incorporated; and Kalyanasundram discloses:
wherein configuring the second computer-based test among the plurality of computer-based tests for execution with the second application includes (Figure 2; Paragraph [0045], “The testing coordinator 210 may then initiate, via the network, upon completion of testing of the first component application 232, 330, testing of the second component application 234 by a second test tool 320 using the test data set 265 and the second set of scripts 275”; Paragraph [0034], “The testing coordinator 210 may initiate a test the second component application 234 by the test tools associated with the second component application 234 and using the updated test data set 260 and at least a portion of the test scripts 270. For example, the second component application 234 may process the transaction files into a format required by a particular financial institution, as may be defined in the test case and/or may process information representative that the transaction files were received at the financial institution. The test tools and/or the testing coordinator 210 may determine whether the second component application completed successfully”):
The combination of Kalyanasundram and Benz does not explicitly disclose:
- adding a plurality of dependencies for the second computer-based test;
- generating API test cases for the second computer-based test;
- serializing data associated with the API test cases
- deserializing the data associated with the API test cases; and
- validating the second computer-based test based upon, at least in part, the API test cases.
However, Meganathan discloses:
- adding a plurality of dependencies for the second computer-based test (Code on page 13 includes import of at least 4 dependencies and a package; Pages 1-2; “The following should be installed in the system:-Java, IDE(I have used Eclipse), Maven
Relevant POM libraries-latest versionsRest Assured 4.4.0json Schema validator 4.3.3jackson databind 2.12.5jackson core 2.12.5jackson annotations 2.12.5gson 2.8.6TestNG 7.3
and now your project is ready to support serialization and deserialization”);
- generating API test cases for the second computer-based test (Code on page 13 shows a generated mock API test; Page 12, “A variation — In real time, we might mock the data for API testing.
Here, We will mock our LMS service sample response to use in our Rest Assured test.
Use Postman or swagger to make a get call to the LMS service and copy as many responses you want to use for mocking”);
- serializing data associated with the API test cases (Page 5, “In the following Test class, we will create a Rest Assured Test to complete the serialization process by passing the above pojo class to the API”; Page 8, “All these process of converting the java object(using POJO classes)into request payload is Serialization”);
- deserializing the data associated with the API test cases (Code on page 13 includes “//Deserialization using sample mock”; Page 8, “Deserialization in Rest Assured is converting Responsebody back to java object with the support of pojo classes. If the response is wrapped as java object, then it is easy to parse and extract response using getters methods”); and
- validating the second computer-based test based upon, at least in part, the API test cases (Page 13, “Execute and check your results”) [Examiner’s remarks: The test (with mock URL) is run in order to test the API and the result relies on the API test case.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Meganathan into the combined teachings of Kalyanasundram and Benz to include “adding a plurality of dependencies for the second computer-based test”, “generating API test cases for the second computer-based test”, “serializing data associated with the API test cases”, “deserializing the data associated with the API test cases”, and “validating the second computer-based test based upon, at least in part, the API test cases.”. Meganathan discloses testing of APIs. API testing is important to ensure that communication between different tests and components are happening as expected and that data is being transferred correctly. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with API testing.
Regarding claim 6, the rejection of claim 2 is incorporated; and Kalyanasundram further discloses:
- wherein the fourth application is a mainframe application (Paragraph [0030], “For example, testing of web-based component applications may be tested while a mainframe (e.g., server-based) application is being tested to better utilize testing resources (e.g., test machines)”).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over US 20150039941 A1 (hereinafter “Kalyanasundram”), in view of “Combining Test Case Generation for Component and Integration Testing” by Sebastian Benz (hereinafter “Benz”), further in view of “Serialization and Deserialization in Rest Assured API Testing” by Subashini Meganathan (hereinafter “Meganathan”), and further in view of “Generating Meaningful Test Databases” by Carsten Binnig (hereinafter “Binnig”), and further in view of US 20190213116 A1 (hereinafter “Kulkarni”).
Regarding claim 3, the rejection of claim 2 is incorporated; and Kalyanasundram further discloses:
wherein configuring the first computer-based test among the plurality of computer-based tests for execution with the first application includes (Paragraph [0045], “For example, the memory 214 may hold instructions that, when executed by the processor 212, cause the testing coordinator 210 to identify a test case 251 stored in the central repository 240, initiate, via the network 360, testing of the first component application 232, 330 by the first test tool 320 using the test data set 265 and the first set of scripts 275”):
- adding a plurality of dependencies for the first computer-based test (Paragraph [0037], “In some cases, the testing coordinator 210 may determine the dependencies, if any, between the different component applications 232, 234, and 236 based on the output of the preceding component applications 232, 234. For example, the second component application may use different test data 260 and/or test scripts 270 based on the output of the first component application 232 and/or the third component application 236 may use different test data 260 and/or test scripts 270 based on the output of the second component application 234”) [Examiner’s remarks: Kalyanasundram discloses adding a plurality of dependent components for a component that has dependencies. While Kalyanasundram specifically uses the second component as an example, one of ordinary skill in the art understands that the first component test case involving a web application may be one of any component in the listed components and have dependencies which must be added and tested.];
…
- validating the first computer-based test based upon, at least in part, the plurality of dependencies (Paragraph [0037], “In some cases, the testing coordinator 210 may determine the dependencies, if any, between the different component applications 232, 234, and 236 based on the output of the preceding component applications 232, 234. For example, the second component application may use different test data 260 and/or test scripts 270 based on the output of the first component application 232 and/or the third component application 236 may use different test data 260 and/or test scripts 270 based on the output of the second component application 234”) [Examiner’s remarks: The result of the component test is based at least in part on the result of the dependencies on which it is based.]…
The combination of Kalyanasundram, Benz, Meganathan, and Binnig does not explicitly disclose:
- creating a plurality of test classes for the first computer-based test; and
- … and the plurality of test classes
However, Kulkarni discloses:
- creating a plurality of test classes for the first computer-based test (Paragraph [0004], “receiving a context file, a test scenario, and a selected automation tool selected through a user interface, the context file including an object map comprising objects that correlate to respective components of a display page for an application, the test scenario describing a test case for the application involving an intended interaction with at least one of the components on the display page; correlating the intended interaction with the at least one component with the corresponding object in the object map; processing the intended interaction and the corresponding object through an Artificial Intelligence (AI) model, the AI model trained using training data comprising a plurality of processes and respective process steps supported by the components of the display page; determining a script template based on the processing and the selected automation tool; applying, based on the processing, the script template to the intended interaction and the correlated object to generate an automated testing script for the selected automating tool”) [Examiner’s remarks: A plurality of test classes (different automation tools) are available and can be used to create multiple different test scripts based on the selected tool.]; and
- … and the plurality of test classes (Paragraph [0004], “…and executing the automated testing script to test one or more functions of the display page supporting the test scenario”) [Examiner’s remarks: The result of the test is based at least in part on the result of running the automated test script for a class (automation tool).].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kulkarni into the combined teachings of Kalyanasundram, Benz, Meganathan, and Binnig to include “creating a plurality of test classes for the first computer-based test” and “…and the plurality of test classes”. As stated in Kulkarni, “Once automated, these test cases can be executed repeatedly and frequently, which adds to the amount of testing coverage for the respective application. However, to automate these manual test cases, a tester must record the test scenario or create a script specific to a designated automation tool, which is both time consuming and effort intensive” (Paragraph [0002]). Automatic, computer-based test generation reduces the amount of time programmers must spend manually testing software, and instead, allows the process to be performed automatically. Using test classes allows for specification of testing templates which eases automation and the testing process. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with automated generation of test classes.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over US 20150039941 A1 (hereinafter “Kalyanasundram”), in view of “Combining Test Case Generation for Component and Integration Testing” by Sebastian Benz (hereinafter “Benz”), further in view of “Serialization and Deserialization in Rest Assured API Testing” by Subashini Meganathan (hereinafter “Meganathan”), and further in view of “Generating Meaningful Test Databases” by Carsten Binnig (hereinafter “Binnig”), and further in view of US 20190235998 A1 (hereinafter “Fisher”).
Regarding claim 5, the rejection of claim 2 is incorporated; and Kalyanasundram further discloses:
wherein configuring the third computer-based test among the plurality of computer-based tests for execution with the third application includes (Figure 2; Paragraph [0036], “The testing coordinator 210 may initiate a test of the third component application 236 by the test tools associated with the third component application 236 using the updated test data set 260 and at least a portion of the test scripts 270. The third component application 236 may be tested to simulate receiving communications from the second financial institution about the success and/or failure of the transaction. The testing coordinator 210 may monitor the testing of the third component application 236 for an indication of success or failure of the component application test”):
The combination of Kalyanasundram, Benz, and Meganathan does not explicitly disclose:
- initializing a webdriver for browser automation;
- performing simulated user interface (UI) actions on the web application; and
- validating UI data for the third computer-based test by comparing the UI data with results from the datastore application.
However, Binnig discloses:
…
- validating UI data for the third computer-based test by comparing the UI data with results from the datastore application (Page 11-Page 12, “AutoDBT takes a specification of the user navigation (as a finite state machine), a data specification which defines constraints on the database for each transition in the user navigation, as well as an initial database state as input and generates test cases that can be executed on the given database state. Using the data specification, AutoDBT can track the database changes of each test case (i.e., AutoDBT can calculate a set of pre- and postconditions on the database state). Consequently, AutoDBT can decide whether the precondition of a test case holds (i.e., if the test case can be executed on the current database state) and whether the postcondition is satisfied when the test case was executed (i.e., if the database is in the expected state). For example, for a test case which deletes a given book of an E-Shop, AutoDBT will check (1) if the book exists before the test case is executed and (2) if the book was deleted successfully after the test case was executed”) [Examiner’s remarks: The UI is validated by comparing the result of the user navigation with the result of the database state.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Binnig into the combined teachings of Kalyanasundram, Benz, and Meganathan to include “validating UI data for the third computer-based test by comparing the UI data with results from the datastore application”. As stated in Binnig, “Consequently, AutoDBT can decide whether the precondition of a test case holds (i.e., if the test case can be executed on the current database state) and whether the postcondition is satisfied when the test case was executed (i.e., if the database is in the expected state)” (Page 12). Ensuring correctness of database states and UI means that data being retrieved and saved is being completed correctly during user navigation of a site, thereby ensuring the accuracy of any transactions with the database. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with database and UI testing.
The combination of Kalyanasundram, Benz, Meganathan, and Binnig does not explicitly disclose:
- initializing a webdriver for browser automation;
- performing simulated user interface (UI) actions on the web application; and
However, Fisher discloses:
- initializing a webdriver for browser automation (Paragraph [0022], “At 146, various parameters related to the testing methodology can be initialized. By way of illustration, WebDriver 148 can be instantiated to provide an interface for programmatically controlling a particular web browser for simulating user behavior.”);
- performing simulated user interface (UI) actions on the web application (Paragraph [0016], “Some implementations of the disclosed systems, apparatus, methods and computer program products are configured for end-to-end testing of a UI platform”; Paragraph [0022], “At 146, various parameters related to the testing methodology can be initialized. By way of illustration, WebDriver 148 can be instantiated to provide an interface for programmatically controlling a particular web browser for simulating user behavior.”) [Examiner’s remarks: A webdriver is used to simulate actions on a web browser, which in this case, is an UI application.]; and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Fisher into the combined teachings of Kalyanasundram, Benz, Meganathan, and Binnig to include “initializing a webdriver for browser automation” and “performing simulated user interface (UI) actions on the web application”. As stated in Fisher, “It should be appreciated that by using, for example, the WebDriver automation platform, the presently disclosed testing techniques for user interface components can simulate user interactions, and can thus be characterized as end-to-end testing” (Paragraph [0040]). Using a webdriver to simulate browser interactions allows for testing of a browser for expected results without requiring that a human run test manually. Manually running tests, especially UI tests may be time consuming, and introduce human error. Using a simulation ensures that proper testing may occur without taking up excess man hours. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with automated UI testing.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over US 20150039941 A1 (hereinafter “Kalyanasundram”), in view of “Combining Test Case Generation for Component and Integration Testing” by Sebastian Benz (hereinafter “Benz”), further in view of “Serialization and Deserialization in Rest Assured API Testing” by Subashini Meganathan (hereinafter “Meganathan”), and further in view of “Generating Meaningful Test Databases” by Carsten Binnig (hereinafter “Binnig”), and further in view of US 5045994 (hereinafter “Belfer”).
Regarding claim 7, the rejection of claim 6 is incorporated; and Kalyanasundram further discloses:
wherein configuring the fourth computer-based test among the plurality of computer-based tests for execution with the fourth application includes (Figure 2; Paragraph [0045], “After initiating a test of a final component application 238, the testing coordinator 210 may provide an indication of whether the test of the multi-step process 220 completed successfully using results obtained from the test tools associated with each of the component applications 230, such as the first test tool 320 and the second test tool 320”; Paragraph [0035], “The testing coordinator 210 may initiate the test of the fourth component application 235 concurrently to the initiation of test of the second component application 234 or during the test of the second component application 234. The test tools and/or the testing coordinator 210 may determine whether the fourth component application completed successfully. For example, the testing coordinator 210 may monitor the testing of the fourth component application 235 for an indication of success or failure of the component application test”]):
Kalyanasundram discloses running component test on a mainframe. The combination of Kalyanasundram, Benz, Meganathan, and Binnig does not explicitly disclose:
- configuring a terminal emulator to be executed with the fourth computer-based test; and
- executing one or more scripts to navigate through mainframe screens, input data, and verify outputs.
However, Belfer discloses:
- configuring a terminal emulator to be executed with the fourth computer-based test (Abstract, “The emulation environment allows the user to call into view sequences of standard input-output (I/O) screen format pairs normally used to submit information to and receive information from the application system. In the emulation mode, these screens are prepared off-line and stored until the user desires to exercise the application system. Each input format is filled with information that will serve as actual input to the application system when it is exercised. Each output format is filled with information that comprises expected results when the application system is actually exercised. The expected results are compared to actual results after execution of each I/O pair and further application system processing is controlled by the comparison results. The stand-alone emulation environment provides editing and control routines and library functions to aid the user in defining and modifying the I/O sequences”; Column 5, line 65- Column 6, line 2, “Moreover, anyone familiar with the application system formats may now formulate automated tests. Also, the off-line storage of the input/output filled-in screen replicas provide for repeatable exercising of the application system and the storage contents constitute self-documentation”) [Examiner’s remarks: Belfer discloses an emulation environment (terminal emulator) to execute computer-based tests. One of ordinary skill in the art understands that the emulation environment may be extended to mainframes.]; and
- executing one or more scripts to navigate through mainframe screens, input data, and verify outputs (Abstract, “The emulation environment allows the user to call into view sequences of standard input-output (I/O) screen format pairs normally used to submit information to and receive information from the application system. In the emulation mode, these screens are prepared off-line and stored until the user desires to exercise the application system. Each input format is filled with information that will serve as actual input to the application system when it is exercised. Each output format is filled with information that comprises expected results when the application system is actually exercised. The expected results are compared to actual results after execution of each I/O pair and further application system processing is controlled by the comparison results. The stand-alone emulation environment provides editing and control routines and library functions to aid the user in defining and modifying the I/O sequences”) [Examiner’s remarks: Scripts may be used to navigate through screens, input data, and verify outputs (results).].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Belfer into the combined teachings of Kalyanasundram, Benz, Meganathan, and Binnig to include “configuring a terminal emulator to be executed with the fourth computer-based test” and “executing one or more scripts to navigate through mainframe screens, input data, and verify outputs”. As stated in Belfer, “The emulation environment allows the user to call into view sequences of standard input-output (I/O) screen format pairs normally used to submit information to and receive information from the application system. …The expected results are compared to actual results after execution of each I/O pair and further application system processing is controlled by the comparison results. The stand-alone emulation environment provides editing and control routines and library functions to aid the user in defining and modifying the I/O sequences” (Abstract). Testing within an emulator allows for testing within a controlled environment. Testing the mainframe is necessary to ensure that it is running correctly and integrated properly with the larger application. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with mainframe testing on an emulator.
Claims 9, 11, 13, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US 20150039941 A1 (hereinafter “Kalyanasundram”), in view of “Serialization and Deserialization in Rest Assured API Testing” by Subashini Meganathan (hereinafter “Meganathan”), and further in view of “Generating Meaningful Test Databases” by Carsten Binnig (hereinafter “Binnig”).
Regarding claim 9, the rejection of claim 8 is incorporated; and Kalyanasundram further discloses:
- the first software application is a web-based software application (Paragraph [0030], “For example, testing of web-based component applications may be tested while a mainframe (e.g., server-based) application is being tested to better utilize testing resources (e.g., test machines)”),
Kalyanasundram does not explicitly disclose:
- the second application is an application programming interface (API) application, and
- the third application is a datastore application.
However, Meganathan discloses:
- the second application is an application programming interface (API) application (Title, “Serialization and Deserialization in Rest Assured API Testing”; Page 12, “Here, We will mock our LMS service sample response to use in our Rest Assured test”; Example test on Page 13) [Examiner’s remarks: Kalyanasundram discloses testing a second component. Meganathan discloses testing APIs. One of ordinary skill in the art understands that APIs are a component which may be testing in place of the second component.], and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Meganathan into the teachings of Kalyanasundram to include “the second application is an application programming interface (API) application”. Meganathan discloses testing of APIs. API testing is important to ensure that communication between different tests and components are happening as expected and that data is being transferred correctly. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with API testing.
The combination of Kalyanasundram and Meganathan does not explicitly disclose:
- the third application is a datastore application.
However, Binnig discloses:
- the third application is a datastore application (Page 11-Page 12, “AutoDBT takes a specification of the user navigation (as a finite state machine), a data specification which defines constraints on the database for each transition in the user navigation, as well as an initial database state as input and generates test cases that can be executed on the given database state. Using the data specification, AutoDBT can track the database changes of each test case (i.e., AutoDBT can calculate a set of pre- and postconditions on the database state). Consequently, AutoDBT can decide whether the precondition of a test case holds (i.e., if the test case can be executed on the current database state) and whether the postcondition is satisfied when the test case was executed (i.e., if the database is in the expected state). For example, for a test case which deletes a given book of an E-Shop, AutoDBT will check (1) if the book exists before the test case is executed and (2) if the book was deleted successfully after the test case was executed”) [Examiner’s remarks: Binnig discloses testing of a datastore application (database) using AutoDBT.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Binnig into the combined teachings of Kalyanasundram and Meganathan to include “the third application is a datastore application”. As stated in Binnig, “Consequently, AutoDBT can decide whether the precondition of a test case holds (i.e., if the test case can be executed on the current database state) and whether the postcondition is satisfied when the test case was executed (i.e., if the database is in the expected state)” (Page 12). Ensuring correctness of database states means that data being retrieved and saved is being completed correctly, thereby ensuring the accuracy of any transactions with the database. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with database testing.
Regarding claim 11, the rejection of claim 9 is incorporated; and Kalyanasundram further discloses:
wherein configuring the second computer-based test among the plurality of computer-based tests for execution with the second application includes (Figure 2; Paragraph [0045], “The testing coordinator 210 may then initiate, via the network, upon completion of testing of the first component application 232, 330, testing of the second component application 234 by a second test tool 320 using the test data set 265 and the second set of scripts 275”; Paragraph [0034], “The testing coordinator 210 may initiate a test the second component application 234 by the test tools associated with the second component application 234 and using the updated test data set 260 and at least a portion of the test scripts 270. For example, the second component application 234 may process the transaction files into a format required by a particular financial institution, as may be defined in the test case and/or may process information representative that the transaction files were received at the financial institution. The test tools and/or the testing coordinator 210 may determine whether the second component application completed successfully”):
Kalyanasundram does not explicitly disclose:
- adding a plurality of dependencies for the second computer-based test;
- generating API test cases for the second computer-based test;
- serializing data associated with the API test cases;
- deserializing the data associated with the API test cases; and
- validating the second computer-based test based upon, at least in part, the API test cases.
However, Meganathan discloses:
- adding a plurality of dependencies for the second computer-based test (Code on page 13 includes import of at least 4 dependencies and a package; Pages 1-2; “The following should be installed in the system:-Java, IDE(I have used Eclipse), Maven
Relevant POM libraries-latest versionsRest Assured 4.4.0json Schema validator 4.3.3jackson databind 2.12.5jackson core 2.12.5jackson annotations 2.12.5gson 2.8.6TestNG 7.3
and now your project is ready to support serialization and deserialization”);
- generating API test cases for the second computer-based test (Code on page 13 shows a generated mock API test; Page 12, “A variation — In real time, we might mock the data for API testing.
Here, We will mock our LMS service sample response to use in our Rest Assured test.
Use Postman or swagger to make a get call to the LMS service and copy as many responses you want to use for mocking”);
- serializing data associated with the API test cases (Page 5, “In the following Test class, we will create a Rest Assured Test to complete the serialization process by passing the above pojo class to the API”; Page 8, “All these process of converting the java object(using POJO classes)into request payload is Serialization”);
- deserializing the data associated with the API test cases (Code on page 13 includes “//Deserialization using sample mock”; Page 8, “Deserialization in Rest Assured is converting Responsebody back to java object with the support of pojo classes. If the response is wrapped as java object, then it is easy to parse and extract response using getters methods”); and
- validating the second computer-based test based upon, at least in part, the API test cases (Page 13, “Execute and check your results”) [Examiner’s remarks: The test (with mock URL) is run in order to test the API and the result relies on the API test case.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Meganathan into the teachings of Kalyanasundram to include “adding a plurality of dependencies for the second computer-based test”, “generating API test cases for the second computer-based test”, “serializing data associated with the API test cases”, “deserializing the data associated with the API test cases”, and “validating the second computer-based test based upon, at least in part, the API test cases.”. Meganathan discloses testing of APIs. API testing is important to ensure that communication between different tests and components are happening as expected and that data is being transferred correctly. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with API testing.
Regarding claim 13, the rejection of claim 9 is incorporated; and Kalyanasundram further discloses:
- wherein the fourth application is a mainframe application (Paragraph [0030], “For example, testing of web-based component applications may be tested while a mainframe (e.g., server-based) application is being tested to better utilize testing resources (e.g., test machines)”).
Regarding claim 16, the rejection of claim 15 is incorporated; and Kalyanasundram further discloses:
- the first software application is a web-based software application (Paragraph [0030], “For example, testing of web-based component applications may be tested while a mainframe (e.g., server-based) application is being tested to better utilize testing resources (e.g., test machines)”),
…
- the fourth application is a mainframe application (Paragraph [0030], “For example, testing of web-based component applications may be tested while a mainframe (e.g., server-based) application is being tested to better utilize testing resources (e.g., test machines)”).
Kalyanasundram does not explicitly disclose:
- the second application is an application programming interface (API) application,
- the third application is a datastore application, and
However, Meganathan discloses:
- the second application is an application programming interface (API) application (Title, “Serialization and Deserialization in Rest Assured API Testing”; Page 12, “Here, We will mock our LMS service sample response to use in our Rest Assured test”; Example test on Page 13) [Examiner’s remarks: Kalyanasundram discloses testing a second component. Meganathan discloses testing APIs. One of ordinary skill in the art understands that APIs are a component which may be testing in place of the second component.],
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Meganathan into the teachings of Kalyanasundram to include “the second application is an application programming interface (API) application”. Meganathan discloses testing of APIs. API testing is important to ensure that communication between different tests and components are happening as expected and that data is being transferred correctly. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with API testing.
The combination of Kalyanasundram and Meganathan does not explicitly disclose:
- the third application is a datastore application, and
However, Binnig discloses:
- the third application is a datastore application (Page 11-Page 12, “AutoDBT takes a specification of the user navigation (as a finite state machine), a data specification which defines constraints on the database for each transition in the user navigation, as well as an initial database state as input and generates test cases that can be executed on the given database state. Using the data specification, AutoDBT can track the database changes of each test case (i.e., AutoDBT can calculate a set of pre- and postconditions on the database state). Consequently, AutoDBT can decide whether the precondition of a test case holds (i.e., if the test case can be executed on the current database state) and whether the postcondition is satisfied when the test case was executed (i.e., if the database is in the expected state). For example, for a test case which deletes a given book of an E-Shop, AutoDBT will check (1) if the book exists before the test case is executed and (2) if the book was deleted successfully after the test case was executed”) [Examiner’s remarks: Binnig discloses testing of a datastore application (database) using AutoDBT.], and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Binnig into the combined teachings of Kalyanasundram and Meganathan to include “the third application is a datastore application”. As stated in Binnig, “Consequently, AutoDBT can decide whether the precondition of a test case holds (i.e., if the test case can be executed on the current database state) and whether the postcondition is satisfied when the test case was executed (i.e., if the database is in the expected state)” (Page 12). Ensuring correctness of database states means that data being retrieved and saved is being completed correctly, thereby ensuring the accuracy of any transactions with the database. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with database testing.
Regarding claim 18, the rejection of claim 16 is incorporated; and Kalyanasundram further discloses:
wherein configuring the second computer-based test among the plurality of computer-based tests for execution with the second application includes (Figure 2; Paragraph [0045], “The testing coordinator 210 may then initiate, via the network, upon completion of testing of the first component application 232, 330, testing of the second component application 234 by a second test tool 320 using the test data set 265 and the second set of scripts 275”; Paragraph [0034], “The testing coordinator 210 may initiate a test the second component application 234 by the test tools associated with the second component application 234 and using the updated test data set 260 and at least a portion of the test scripts 270. For example, the second component application 234 may process the transaction files into a format required by a particular financial institution, as may be defined in the test case and/or may process information representative that the transaction files were received at the financial institution. The test tools and/or the testing coordinator 210 may determine whether the second component application completed successfully”):
Kalyanasundram does not explicitly disclose:
- adding a plurality of dependencies for the second computer-based test;
- generating API test cases for the second computer-based test;
- serializing data associated with the API test cases;
- deserializing the data associated with the API test cases; and
- validating the second computer-based test based upon, at least in part, the API test cases.
However, Meganathan discloses:
- adding a plurality of dependencies for the second computer-based test (Code on page 13 includes import of at least 4 dependencies and a package; Pages 1-2; “The following should be installed in the system:-Java, IDE(I have used Eclipse), Maven
Relevant POM libraries-latest versionsRest Assured 4.4.0json Schema validator 4.3.3jackson databind 2.12.5jackson core 2.12.5jackson annotations 2.12.5gson 2.8.6TestNG 7.3
and now your project is ready to support serialization and deserialization”);
- generating API test cases for the second computer-based test (Code on page 13 shows a generated mock API test; Page 12, “A variation — In real time, we might mock the data for API testing.
Here, We will mock our LMS service sample response to use in our Rest Assured test.
Use Postman or swagger to make a get call to the LMS service and copy as many responses you want to use for mocking”);
- serializing data associated with the API test cases (Page 5, “In the following Test class, we will create a Rest Assured Test to complete the serialization process by passing the above pojo class to the API”; Page 8, “All these process of converting the java object(using POJO classes)into request payload is Serialization”);
- deserializing the data associated with the API test cases (Code on page 13 includes “//Deserialization using sample mock”; Page 8, “Deserialization in Rest Assured is converting Responsebody back to java object with the support of pojo classes. If the response is wrapped as java object, then it is easy to parse and extract response using getters methods”); and
- validating the second computer-based test based upon, at least in part, the API test cases (Page 13, “Execute and check your results”) [Examiner’s remarks: The test (with mock URL) is run in order to test the API and the result relies on the API test case.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Meganathan into the teachings of Kalyanasundram to include “adding a plurality of dependencies for the second computer-based test”, “generating API test cases for the second computer-based test”, “serializing data associated with the API test cases”, “deserializing the data associated with the API test cases”, and “validating the second computer-based test based upon, at least in part, the API test cases.”. Meganathan discloses testing of APIs. API testing is important to ensure that communication between different tests and components are happening as expected and that data is being transferred correctly. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with API testing.
Claims 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over US 20150039941 A1 (hereinafter “Kalyanasundram”), in view of “Serialization and Deserialization in Rest Assured API Testing” by Subashini Meganathan (hereinafter “Meganathan”), and further in view of “Generating Meaningful Test Databases” by Carsten Binnig (hereinafter “Binnig”), and further in view of US 20190213116 A1 (hereinafter “Kulkarni”).
Regarding claim 10, the rejection of claim 9 is incorporated; and Kalyanasundram further discloses:
wherein configuring the first computer-based test among the plurality of computer-based tests for execution with the first application includes (Paragraph [0045], “For example, the memory 214 may hold instructions that, when executed by the processor 212, cause the testing coordinator 210 to identify a test case 251 stored in the central repository 240, initiate, via the network 360, testing of the first component application 232, 330 by the first test tool 320 using the test data set 265 and the first set of scripts 275”):
- adding a plurality of dependencies for the first computer-based test (Paragraph [0037], “In some cases, the testing coordinator 210 may determine the dependencies, if any, between the different component applications 232, 234, and 236 based on the output of the preceding component applications 232, 234. For example, the second component application may use different test data 260 and/or test scripts 270 based on the output of the first component application 232 and/or the third component application 236 may use different test data 260 and/or test scripts 270 based on the output of the second component application 234”) [Examiner’s remarks: Kalyanasundram discloses adding a plurality of dependent components for a component that has dependencies. While Kalyanasundram specifically uses the second component as an example, one of ordinary skill in the art understands that the first component test case involving a web application may be one of any component in the listed components and have dependencies which must be added and tested.];
…
- validating the first computer-based test based upon, at least in part, the plurality of dependencies (Paragraph [0037], “In some cases, the testing coordinator 210 may determine the dependencies, if any, between the different component applications 232, 234, and 236 based on the output of the preceding component applications 232, 234. For example, the second component application may use different test data 260 and/or test scripts 270 based on the output of the first component application 232 and/or the third component application 236 may use different test data 260 and/or test scripts 270 based on the output of the second component application 234”) [Examiner’s remarks: The result of the component test is based at least in part on the result of the dependencies on which it is based.]…
The combination of Kalyanasundram, Meganathan, and Binnig does not explicitly disclose:
- creating a plurality of test classes for the first computer-based test; and
- … and the plurality of test classes
However, Kulkarni discloses:
- creating a plurality of test classes for the first computer-based test (Paragraph [0004], “receiving a context file, a test scenario, and a selected automation tool selected through a user interface, the context file including an object map comprising objects that correlate to respective components of a display page for an application, the test scenario describing a test case for the application involving an intended interaction with at least one of the components on the display page; correlating the intended interaction with the at least one component with the corresponding object in the object map; processing the intended interaction and the corresponding object through an Artificial Intelligence (AI) model, the AI model trained using training data comprising a plurality of processes and respective process steps supported by the components of the display page; determining a script template based on the processing and the selected automation tool; applying, based on the processing, the script template to the intended interaction and the correlated object to generate an automated testing script for the selected automating tool”) [Examiner’s remarks: A plurality of test classes (different automation tools) are available and can be used to create multiple different test scripts based on the selected tool.]; and
- … and the plurality of test classes (Paragraph [0004], “…and executing the automated testing script to test one or more functions of the display page supporting the test scenario”) [Examiner’s remarks: The result of the test is based at least in part on the result of running the automated test script for a class (automation tool).].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kulkarni into the combined teachings of Kalyanasundram, Meganathan, and Binnig to include “creating a plurality of test classes for the first computer-based test” and “…and the plurality of test classes”. As stated in Kulkarni, “Once automated, these test cases can be executed repeatedly and frequently, which adds to the amount of testing coverage for the respective application. However, to automate these manual test cases, a tester must record the test scenario or create a script specific to a designated automation tool, which is both time consuming and effort intensive” (Paragraph [0002]). Automatic, computer-based test generation reduces the amount of time programmers must spend manually testing software, and instead, allows the process to be performed automatically. Using test classes allows for specification of testing templates which eases automation and the testing process. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with automated generation of test classes.
Regarding claim 17, the rejection of claim 16 is incorporated; and Kalyanasundram further discloses:
wherein configuring the first computer-based test among the plurality of computer-based tests for execution with the first application includes (Paragraph [0045], “For example, the memory 214 may hold instructions that, when executed by the processor 212, cause the testing coordinator 210 to identify a test case 251 stored in the central repository 240, initiate, via the network 360, testing of the first component application 232, 330 by the first test tool 320 using the test data set 265 and the first set of scripts 275”):
- adding a plurality of dependencies for the first computer-based test (Paragraph [0037], “In some cases, the testing coordinator 210 may determine the dependencies, if any, between the different component applications 232, 234, and 236 based on the output of the preceding component applications 232, 234. For example, the second component application may use different test data 260 and/or test scripts 270 based on the output of the first component application 232 and/or the third component application 236 may use different test data 260 and/or test scripts 270 based on the output of the second component application 234”) [Examiner’s remarks: Kalyanasundram discloses adding a plurality of dependent components for a component that has dependencies. While Kalyanasundram specifically uses the second component as an example, one of ordinary skill in the art understands that the first component test case involving a web application may be one of any component in the listed components and have dependencies which must be added and tested.];
…
- validating the first computer-based test based upon, at least in part, the plurality of dependencies (Paragraph [0037], “In some cases, the testing coordinator 210 may determine the dependencies, if any, between the different component applications 232, 234, and 236 based on the output of the preceding component applications 232, 234. For example, the second component application may use different test data 260 and/or test scripts 270 based on the output of the first component application 232 and/or the third component application 236 may use different test data 260 and/or test scripts 270 based on the output of the second component application 234”) [Examiner’s remarks: The result of the component test is based at least in part on the result of the dependencies on which it is based.]…
The combination of Kalyanasundram, Meganathan, and Binnig does not explicitly disclose:
- creating a plurality of test classes for the first computer-based test; and
- … and the plurality of test classes
However, Kulkarni discloses:
- creating a plurality of test classes for the first computer-based test (Paragraph [0004], “receiving a context file, a test scenario, and a selected automation tool selected through a user interface, the context file including an object map comprising objects that correlate to respective components of a display page for an application, the test scenario describing a test case for the application involving an intended interaction with at least one of the components on the display page; correlating the intended interaction with the at least one component with the corresponding object in the object map; processing the intended interaction and the corresponding object through an Artificial Intelligence (AI) model, the AI model trained using training data comprising a plurality of processes and respective process steps supported by the components of the display page; determining a script template based on the processing and the selected automation tool; applying, based on the processing, the script template to the intended interaction and the correlated object to generate an automated testing script for the selected automating tool”) [Examiner’s remarks: A plurality of test classes (different automation tools) are available and can be used to create multiple different test scripts based on the selected tool.]; and
- … and the plurality of test classes (Paragraph [0004], “…and executing the automated testing script to test one or more functions of the display page supporting the test scenario”) [Examiner’s remarks: The result of the test is based at least in part on the result of running the automated test script for a class (automation tool).].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kulkarni into the combined teachings of Kalyanasundram, Meganathan, and Binnig to include “creating a plurality of test classes for the first computer-based test” and “…and the plurality of test classes”. As stated in Kulkarni, “Once automated, these test cases can be executed repeatedly and frequently, which adds to the amount of testing coverage for the respective application. However, to automate these manual test cases, a tester must record the test scenario or create a script specific to a designated automation tool, which is both time consuming and effort intensive” (Paragraph [0002]). Automatic, computer-based test generation reduces the amount of time programmers must spend manually testing software, and instead, allows the process to be performed automatically. Using test classes allows for specification of testing templates which eases automation and the testing process. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with automated generation of test classes.
Claims 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US 20150039941 A1 (hereinafter “Kalyanasundram”), in view of “Combining Test Case Generation for Component and Integration Testing” by Sebastian Benz (hereinafter “Benz”), further in view of “Serialization and Deserialization in Rest Assured API Testing” by Subashini Meganathan (hereinafter “Meganathan”), and further in view of “Generating Meaningful Test Databases” by Carsten Binnig (hereinafter “Binnig”), and further in view of US 20190235998 A1 (hereinafter “Fisher”).
Regarding claim 12, the rejection of claim 9 is incorporated; and Kalyansundram further discloses:
wherein configuring the third computer-based test among the plurality of computer-based tests for execution with the third application includes (Figure 2; Paragraph [0036], “The testing coordinator 210 may initiate a test of the third component application 236 by the test tools associated with the third component application 236 using the updated test data set 260 and at least a portion of the test scripts 270. The third component application 236 may be tested to simulate receiving communications from the second financial institution about the success and/or failure of the transaction. The testing coordinator 210 may monitor the testing of the third component application 236 for an indication of success or failure of the component application test”):
The combination of Kalyanasundram and Meganathan does not explicitly disclose:
- initializing a webdriver for browser automation;
- performing simulated user interface (UI) actions on the web application; and
- validating UI data for the third computer-based test by comparing the UI data with results from the datastore application.
However, Binnig discloses:
…
- validating UI data for the third computer-based test by comparing the UI data with results from the datastore application (Page 11-Page 12, “AutoDBT takes a specification of the user navigation (as a finite state machine), a data specification which defines constraints on the database for each transition in the user navigation, as well as an initial database state as input and generates test cases that can be executed on the given database state. Using the data specification, AutoDBT can track the database changes of each test case (i.e., AutoDBT can calculate a set of pre- and postconditions on the database state). Consequently, AutoDBT can decide whether the precondition of a test case holds (i.e., if the test case can be executed on the current database state) and whether the postcondition is satisfied when the test case was executed (i.e., if the database is in the expected state). For example, for a test case which deletes a given book of an E-Shop, AutoDBT will check (1) if the book exists before the test case is executed and (2) if the book was deleted successfully after the test case was executed”) [Examiner’s remarks: The UI is validated by comparing the result of the user navigation with the result of the database state.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Binnig into the combined teachings of Kalyanasundram and Meganathan to include “validating UI data for the third computer-based test by comparing the UI data with results from the datastore application”. As stated in Binnig, “Consequently, AutoDBT can decide whether the precondition of a test case holds (i.e., if the test case can be executed on the current database state) and whether the postcondition is satisfied when the test case was executed (i.e., if the database is in the expected state)” (Page 12). Ensuring correctness of database states and UI means that data being retrieved and saved is being completed correctly during user navigation of a site, thereby ensuring the accuracy of any transactions with the database. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with database and UI testing.
The combination of Kalyanasundram, Meganathan, and Binnig does not explicitly disclose:
- initializing a webdriver for browser automation;
- performing simulated user interface (UI) actions on the web application; and
However, Fisher discloses:
- initializing a webdriver for browser automation (Paragraph [0022], “At 146, various parameters related to the testing methodology can be initialized. By way of illustration, WebDriver 148 can be instantiated to provide an interface for programmatically controlling a particular web browser for simulating user behavior.”);
- performing simulated user interface (UI) actions on the web application (Paragraph [0016], “Some implementations of the disclosed systems, apparatus, methods and computer program products are configured for end-to-end testing of a UI platform”; Paragraph [0022], “At 146, various parameters related to the testing methodology can be initialized. By way of illustration, WebDriver 148 can be instantiated to provide an interface for programmatically controlling a particular web browser for simulating user behavior.”) [Examiner’s remarks: A webdriver is used to simulate actions on a web browser, which in this case, is an UI application.]; and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Fisher into the combined teachings of Kalyanasundram, Meganathan, and Binnig to include “initializing a webdriver for browser automation” and “performing simulated user interface (UI) actions on the web application”. As stated in Fisher, “It should be appreciated that by using, for example, the WebDriver automation platform, the presently disclosed testing techniques for user interface components can simulate user interactions, and can thus be characterized as end-to-end testing” (Paragraph [0040]). Using a webdriver to simulate browser interactions allows for testing of a browser for expected results without requiring that a human run test manually. Manually running tests, especially UI tests may be time consuming, and introduce human error. Using a simulation ensures that proper testing may occur without taking up excess man hours. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with automated UI testing.
Regarding claim 19, the rejection of claim 16 is incorporated; and Kalyanasundram further discloses:
wherein configuring the third computer-based test among the plurality of computer-based tests for execution with the third application includes (Figure 2; Paragraph [0036], “The testing coordinator 210 may initiate a test of the third component application 236 by the test tools associated with the third component application 236 using the updated test data set 260 and at least a portion of the test scripts 270. The third component application 236 may be tested to simulate receiving communications from the second financial institution about the success and/or failure of the transaction. The testing coordinator 210 may monitor the testing of the third component application 236 for an indication of success or failure of the component application test”):
The combination of Kalyanasundram and Meganathan does not explicitly disclose:
- initializing a webdriver for browser automation;
- performing simulated user interface (UI) actions on the web application; and
- validating UI data for the third computer-based test by comparing the UI data with results from the datastore application.
However, Binnig discloses:
…
- validating UI data for the third computer-based test by comparing the UI data with results from the datastore application (Page 11-Page 12, “AutoDBT takes a specification of the user navigation (as a finite state machine), a data specification which defines constraints on the database for each transition in the user navigation, as well as an initial database state as input and generates test cases that can be executed on the given database state. Using the data specification, AutoDBT can track the database changes of each test case (i.e., AutoDBT can calculate a set of pre- and postconditions on the database state). Consequently, AutoDBT can decide whether the precondition of a test case holds (i.e., if the test case can be executed on the current database state) and whether the postcondition is satisfied when the test case was executed (i.e., if the database is in the expected state). For example, for a test case which deletes a given book of an E-Shop, AutoDBT will check (1) if the book exists before the test case is executed and (2) if the book was deleted successfully after the test case was executed”) [Examiner’s remarks: The UI is validated by comparing the result of the user navigation with the result of the database state.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Binnig into the combined teachings of Kalyanasundram and Meganathan to include “validating UI data for the third computer-based test by comparing the UI data with results from the datastore application”. As stated in Binnig, “Consequently, AutoDBT can decide whether the precondition of a test case holds (i.e., if the test case can be executed on the current database state) and whether the postcondition is satisfied when the test case was executed (i.e., if the database is in the expected state)” (Page 12). Ensuring correctness of database states and UI means that data being retrieved and saved is being completed correctly during user navigation of a site, thereby ensuring the accuracy of any transactions with the database. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with database and UI testing.
The combination of Kalyanasundram, Meganathan, and Binnig does not explicitly disclose:
- initializing a webdriver for browser automation;
- performing simulated user interface (UI) actions on the web application; and
However, Fisher discloses:
- initializing a webdriver for browser automation (Paragraph [0022], “At 146, various parameters related to the testing methodology can be initialized. By way of illustration, WebDriver 148 can be instantiated to provide an interface for programmatically controlling a particular web browser for simulating user behavior.”);
- performing simulated user interface (UI) actions on the web application (Paragraph [0016], “Some implementations of the disclosed systems, apparatus, methods and computer program products are configured for end-to-end testing of a UI platform”; Paragraph [0022], “At 146, various parameters related to the testing methodology can be initialized. By way of illustration, WebDriver 148 can be instantiated to provide an interface for programmatically controlling a particular web browser for simulating user behavior.”) [Examiner’s remarks: A webdriver is used to simulate actions on a web browser, which in this case, is an UI application.]; and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Fisher into the combined teachings of Kalyanasundram, Meganathan, and Binnig to include “initializing a webdriver for browser automation” and “performing simulated user interface (UI) actions on the web application”. As stated in Fisher, “It should be appreciated that by using, for example, the WebDriver automation platform, the presently disclosed testing techniques for user interface components can simulate user interactions, and can thus be characterized as end-to-end testing” (Paragraph [0040]). Using a webdriver to simulate browser interactions allows for testing of a browser for expected results without requiring that a human run test manually. Manually running tests, especially UI tests may be time consuming, and introduce human error. Using a simulation ensures that proper testing may occur without taking up excess man hours. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with automated UI testing.
Claims 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20150039941 A1 (hereinafter “Kalyanasundram”), in view of “Serialization and Deserialization in Rest Assured API Testing” by Subashini Meganathan (hereinafter “Meganathan”), and further in view of “Generating Meaningful Test Databases” by Carsten Binnig (hereinafter “Binnig”), and further in view of US 5045994 (hereinafter “Belfer”).
Regarding claim 14, the rejection of claim 13 is incorporated; and Kalyanasundram further discloses:
wherein configuring the fourth computer-based test among the plurality of computer-based tests for execution with the fourth application includes (Figure 2; Paragraph [0045], “After initiating a test of a final component application 238, the testing coordinator 210 may provide an indication of whether the test of the multi-step process 220 completed successfully using results obtained from the test tools associated with each of the component applications 230, such as the first test tool 320 and the second test tool 320”; Paragraph [0035], “The testing coordinator 210 may initiate the test of the fourth component application 235 concurrently to the initiation of test of the second component application 234 or during the test of the second component application 234. The test tools and/or the testing coordinator 210 may determine whether the fourth component application completed successfully. For example, the testing coordinator 210 may monitor the testing of the fourth component application 235 for an indication of success or failure of the component application test”]):
Kalyanasundram discloses running the component tests on a mainframe. The combination of Kalyanasundram, Meganathan, and Binnig does not explicitly disclose:
- configuring a terminal emulator to be executed with the fourth-computer-based test; and
- executing one or more scripts to navigate through mainframe screens, input data, and verify outputs.
However, Belfer discloses:
- configuring a terminal emulator to be executed with the fourth computer-based test (Abstract, “The emulation environment allows the user to call into view sequences of standard input-output (I/O) screen format pairs normally used to submit information to and receive information from the application system. In the emulation mode, these screens are prepared off-line and stored until the user desires to exercise the application system. Each input format is filled with information that will serve as actual input to the application system when it is exercised. Each output format is filled with information that comprises expected results when the application system is actually exercised. The expected results are compared to actual results after execution of each I/O pair and further application system processing is controlled by the comparison results. The stand-alone emulation environment provides editing and control routines and library functions to aid the user in defining and modifying the I/O sequences”; Column 5, line 65- Column 6, line 2, “Moreover, anyone familiar with the application system formats may now formulate automated tests. Also, the off-line storage of the input/output filled-in screen replicas provide for repeatable exercising of the application system and the storage contents constitute self-documentation”) [Examiner’s remarks: Belfer discloses an emulation environment (terminal emulator) to execute computer-based tests. One of ordinary skill in the art understands that the emulation environment may be extended to mainframes.]; and
- executing one or more scripts to navigate through mainframe screens, input data, and verify outputs (Abstract, “The emulation environment allows the user to call into view sequences of standard input-output (I/O) screen format pairs normally used to submit information to and receive information from the application system. In the emulation mode, these screens are prepared off-line and stored until the user desires to exercise the application system. Each input format is filled with information that will serve as actual input to the application system when it is exercised. Each output format is filled with information that comprises expected results when the application system is actually exercised. The expected results are compared to actual results after execution of each I/O pair and further application system processing is controlled by the comparison results. The stand-alone emulation environment provides editing and control routines and library functions to aid the user in defining and modifying the I/O sequences”) [Examiner’s remarks: Scripts may be used to navigate through screens, input data, and verify outputs (results).].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Belfer into the combined teachings of Kalyanasundram, Meganathan, and Binnig to include “configuring a terminal emulator to be executed with the fourth computer-based test” and “executing one or more scripts to navigate through mainframe screens, input data, and verify outputs”. As stated in Belfer, “The emulation environment allows the user to call into view sequences of standard input-output (I/O) screen format pairs normally used to submit information to and receive information from the application system. …The expected results are compared to actual results after execution of each I/O pair and further application system processing is controlled by the comparison results. The stand-alone emulation environment provides editing and control routines and library functions to aid the user in defining and modifying the I/O sequences” (Abstract). Testing within an emulator allows for testing within a controlled environment. Testing the mainframe is necessary to ensure that it is running correctly and integrated properly with the larger application. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with mainframe testing on an emulator.
Regarding claim 20, the rejection of claim 16 is incorporated; and Kalyanasundram further discloses:
wherein configuring the fourth computer-based test among the plurality of computer-based tests for execution with the fourth application includes (Figure 2; Paragraph [0045], “After initiating a test of a final component application 238, the testing coordinator 210 may provide an indication of whether the test of the multi-step process 220 completed successfully using results obtained from the test tools associated with each of the component applications 230, such as the first test tool 320 and the second test tool 320”; Paragraph [0035], “The testing coordinator 210 may initiate the test of the fourth component application 235 concurrently to the initiation of test of the second component application 234 or during the test of the second component application 234. The test tools and/or the testing coordinator 210 may determine whether the fourth component application completed successfully. For example, the testing coordinator 210 may monitor the testing of the fourth component application 235 for an indication of success or failure of the component application test”]):
Kalyanasundram discloses running the component tests on a mainframe. The combination of Kalyanasundram, Meganathan, and Binnig does not explicitly disclose:
- configuring a terminal emulator to be executed with the fourth-computer-based test; and
- executing one or more scripts to navigate through mainframe screens, input data, and verify outputs.
However, Belfer discloses:
- configuring a terminal emulator to be executed with the fourth computer-based test (Abstract, “The emulation environment allows the user to call into view sequences of standard input-output (I/O) screen format pairs normally used to submit information to and receive information from the application system. In the emulation mode, these screens are prepared off-line and stored until the user desires to exercise the application system. Each input format is filled with information that will serve as actual input to the application system when it is exercised. Each output format is filled with information that comprises expected results when the application system is actually exercised. The expected results are compared to actual results after execution of each I/O pair and further application system processing is controlled by the comparison results. The stand-alone emulation environment provides editing and control routines and library functions to aid the user in defining and modifying the I/O sequences”; Column 5, line 65- Column 6, line 2, “Moreover, anyone familiar with the application system formats may now formulate automated tests. Also, the off-line storage of the input/output filled-in screen replicas provide for repeatable exercising of the application system and the storage contents constitute self-documentation”) [Examiner’s remarks: Belfer discloses an emulation environment (terminal emulator) to execute computer-based tests. One of ordinary skill in the art understands that the emulation environment may be extended to mainframes.]; and
- executing one or more scripts to navigate through mainframe screens, input data, and verify outputs (Abstract, “The emulation environment allows the user to call into view sequences of standard input-output (I/O) screen format pairs normally used to submit information to and receive information from the application system. In the emulation mode, these screens are prepared off-line and stored until the user desires to exercise the application system. Each input format is filled with information that will serve as actual input to the application system when it is exercised. Each output format is filled with information that comprises expected results when the application system is actually exercised. The expected results are compared to actual results after execution of each I/O pair and further application system processing is controlled by the comparison results. The stand-alone emulation environment provides editing and control routines and library functions to aid the user in defining and modifying the I/O sequences”) [Examiner’s remarks: Scripts may be used to navigate through screens, input data, and verify outputs (results).].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Belfer into the combined teachings of Kalyanasundram, Meganathan, and Binnig to include “configuring a terminal emulator to be executed with the fourth computer-based test” and “executing one or more scripts to navigate through mainframe screens, input data, and verify outputs”. As stated in Belfer, “The emulation environment allows the user to call into view sequences of standard input-output (I/O) screen format pairs normally used to submit information to and receive information from the application system. …The expected results are compared to actual results after execution of each I/O pair and further application system processing is controlled by the comparison results. The stand-alone emulation environment provides editing and control routines and library functions to aid the user in defining and modifying the I/O sequences” (Abstract). Testing within an emulator allows for testing within a controlled environment. Testing the mainframe is necessary to ensure that it is running correctly and integrated properly with the larger application. Therefore, it would be obvious to one of ordinary skill in the art to combine software testing with mainframe testing on an emulator.
Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. - US 20070277154 A1 discloses a method for testing multiple components within a system.
- US 20210089437 A1 discloses a method for automating the process of mainframe testing in a virtual environment.
- US 6601018 B1 discloses a framework for automated software component testing.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIVIAN WEIJIA DUAN whose telephone number is (703)756-5442. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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, Wei Y Mui can be reached at (571) 272-3708. 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.
/V.W.D./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights