DETAILED ACTION
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on May 30, 2025 has been entered.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 6-7, 9-10, 12, 15-16 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Godefroid et al. (US PGPUB 2019/0370152; hereinafter “Godefroid”) in view of Lin et al. (US PGPUB 2025/0245131; hereinafter “Lin”), Coker (US Patent 8,745,641; hereinafter “Coker”) and Gauthier et al. (US PGPUB 2021/0141904; hereinafter “Gauthier”).
Claim 1: (Currently Amended)
Godefroid teaches a method, comprising
determining, by a specification analyzer, features of an application programming interface (API), wherein the features include operations of the API, one or more resources used by each of the operations, and resource-based dependencies between the operations ([0016] “an automatic testing tool for testing a service… generates intelligent tests for systematically testing the service based on analysis of a computer-readable specification that describes a programming interface of the service… the testing tool may determine what specific requests are supported by the service, and what responses may be expected from the service, and may generate dependency information for determining dependencies among the specific requests supported by the specification… the testing tool may infer that infer that a request B should not be executed before a request A because the request B takes, as an input, a variable (e.g., a resource id) returned in response to execution of the request A.” [0018] “The specification analyzer 106 may receive, as an input, a specification 110 that may describe the programming interface (e.g., REST API) of the service 104.”);
generating, by a sequence generator, a resource-specific group of operations from the operations, wherein the operations within the resource-specific group operate on a resource selected from the one or more resources ([0018] “The set of operation descriptions 112 may also include information for determining dependencies among the requests supported by the service 104. For example, for each request supported by the service 104, the specification analyzer 106 may indicate any parameters (e.g., dynamic objects such as resource identifiers) that are required as inputs for generating the request, and any parameters (e.g., dynamic objects such as resource identifiers) that are returned by a response to the request. Based on such dependency information in the set of operation descriptions 112, the testing tool 102 may infer dependencies among the requests supported by the service 104. For example, the testing tool 102 may infer that a request B should not be executed before a request A because the request B takes, as an input, a variable (e.g., a resource id) returned in response to execution of the request A.”); and
generating, by the sequence generator, a sequence of operations by ordering the operations within the resource-specific group, wherein the ordering is based on the resource-based dependencies between the operations within the resource-specific group ([0019] “The testing engine 108 may use the set of operation descriptions 112 to generate and execute test request sequences 114 to test the service 104…To perform intelligent testing, without executing test sequences that encompass all possible request combinations, the testing engine 108 may execute only those test sequences that are determined to be valid, by automatically eliminating test request sequences that are determined to be invalid. For example, the testing engine 108 may determine that a test request sequence is invalid if the test request sequence does not satisfy one or more dependencies that may be inferred from the set of operation descriptions 112.”).
With further regard to Claim 1, Godefroid does not teach the following, however, Lin teaches:
the determining of the resource-based dependencies includes performing parameter matching ([0005] “a test tool may analyze an API dependency relationship by matching a request (request) parameter name and a response (response) parameter name in an application programming interface (API) definition of the cloud service, and generate an API dependency graph.”), and
parameters, associated with the parameter matching, include one or more parameter names, one or more parameter data types, and one or more resource names ([0089] “the API dependency analysis subsystem 104 may extract an API name, an API parameter name, and an API structure from the API document… and a UUID of a resource object pointed to by the API parameter,” wherein the “UUID of a resource object” is the “one or more resource names”. [0097] “FIG. 4 is a diagram of some parameter specifications. When a value of an API parameter is a type, a specification may include Int, Float, String, DateTime, Array, and Object.”);
outputting, by a test execution engine, a functional test case of the API based on the sequence of operations ([0071] “The generation module 1062 is configured to generate the test case based on the API dependency relationship. For example, the generation module 1062 generates the API execution sequence based on the API dependency relationship, and mutates the API execution sequence with reference to a mutation strategy, including mutating one or more of an API execution sequence, an API parameter, and an API structure (oracle) in the API execution sequence, to obtain a plurality of test cases.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Godefroid with the test case output and parameter matching as taught by Lin for purposes of “improving a test case generation effect, including reducing execution time and improving a vulnerability discovery effect” (Lin [0024]).
With further regard to Claim 1, Godefroid in view of Lin does not teach the following, however, Coker teaches:
identifying, by the specification analyzer, an anomaly associated with an operation from the operations, wherein the operation is associated with a first operation type, and the anomaly is identified in a case where the API uses the operation to perform a second operation type different from the first operation type (Col. 11 Ln. 18-22: “In an example, an anomaly in the API is detected when a data field is defined as an integer (e.g., 0) in a first request and the same data field is returned as a string (e.g., ‘0’) in response to a subsequent request.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Godefroid in view of Lin with the anomaly identifying as taught by Coker in order “to detect implementation errors and contribute to testing, such as, end-to-end or integration testing” (Coker Col. 3 Ln. 14-15).
With further regard to Claim 1, Godefroid in view of Lin and Coker does not teach the following, however, Gauthier teaches:
determining, based on the identified anomaly, a subtype for the operation, wherein the subtype indicates the first operation type and the second operation type ([0034] “API specification assign different types to the parameter, where one of the types is a subtype of the other type, then the merged API specification may assign the more general type to the parameter.”); and
generating, based on the subtype, the resource-specific group of operations from the operations ([0037] “In Step 208, a vulnerability is detected in the application by executing the application using the type of the parameter. In one or more embodiments, the fuzzer generates values for the parameter using the type included in the merged API specification described in Step 206 above. Using the inferred type of the parameter to generate parameter values during vulnerability 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 have modified the method as disclosed by Godefroid in view of Lin and Coker with the subtype determining as taught by Gauthier since “Using the inferred type of the parameter to generate parameter values during vulnerability testing may result in more useful parameter values than generating parameter values at random or solely based on dynamically observed requests” (Gauthier [0014]).
Claim 3: (Currently Amended)
Godefroid in view of Lin, Coker and Gauthier teaches the method of claim 1 and Godefroid further teaches wherein the resource-based dependencies correspond to producer-consumer relations between the operations of the resource-specific group ([0016] “Based on the dependency information, the testing tool may infer that certain request combinations are not valid or are unsupported. As an example, the testing tool may infer that infer that a request B should not be executed before a request A because the request B takes, as an input, a variable (e.g., a resource id) returned in response to execution of the request A,” wherein, this case, “request A” is the “producer” and “request B” is the “consumer”.).
Claim 6: (Currently Amended)
Godefroid in view of Lin, Coker and Gauthier teaches the method of claim 1 and Godefroid further teaches further comprising:
executing the functional test case on a system under test ([0016] “Based on analyzing the specification, the testing tool may generate, execute and process responses of test request sequences for testing the service.”); and
performing a response check with respect to each of the operations of the resource-specific group ([0019] “the testing engine may determine that a test request sequence is invalid by analyzing a response received in response to executing the test request sequence, for example if the response does not indicate successful completion of the test request sequence”).
Claim 7: (Currently Amended)
Godefroid in view of Lin, Coker and Gauthier teaches the method of claim 1 and Godefroid teaches further comprising:
generating additional functional test cases of the operations of the resource-specific group arranged based on the sequence of operations using different combinations of parameter values for the operations of the resource-specific group ([0026] “The process 400 may utilize the set of operation descriptions 112 to generate, execute and process responses of test request sequences for testing the service 104. In an embodiment, the process 400 may perform one or more iterations of generating, executing and analyzing responses of test request sequences of increasing lengths, until a maximum length n is reached.” [0028] “the testing engine 108 may replace any fuzzable parameters in the last, newly appended, request in the test request sequence with concrete values of corresponding object types. The concrete values for replacing the fuzzable parameters may be obtained from dictionaries of predetermined values of the corresponding object types. The dictionaries may be user-defined, for example. The testing engine 108 may generate multiple concretized test request sequences based on a particular valid test request sequence to include all possible combinations of all of fuzzable object values provided in the dictionaries of the corresponding object types.”).
Claim 9:
Godefroid in view of Lin, Coker and Gauthier teaches the method of claim 1 and Godefroid further teaches wherein the sequence of operations is an operation-based sequence ([0036] “At block 706, a set of test request sequences is generated. In an embodiment, the set of test request sequences may be generated based on the set of operation descriptions obtained at block 702”).
Claims 10, 12, 15-16 and 18:
With regard to Claims 10, 12, 15-16 and 18, these claims are equivalent in scope to Claims 1, 3, 6-7 and 9 rejected above, merely having a different independent claim type, and as such Claims 10 ,12, 15-16 and 18 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1, 3, 6-7 and 9.
With further regard to Claim 10, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Godefroid reference also anticipates these additional elements of Claim 10, for example, wherein the system comprises:
one or more processors configured to execute operations ([0038] “FIG. 8 is a block diagram of a computing system 800 suitable for implementing one or more embodiments of the present disclosure. In its most basic configuration, the computing system 800 may include at least one processor 802 and at least one memory 804.”).
Claim 19:
With regard to Claim 19, this claim is equivalent in scope to Claim 1 rejected above, merely having a different independent claim type, and as such Claim 19 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1.
With further regard to Claim 19, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Godefroid reference also anticipates these additional elements of Claim 19, for example, wherein Godefroid teaches:
A computer program product comprising: one or more computer readable storage media having program instructions embodied therewith, wherein the program instructions are executable by one or more processors to cause the one or more processors to execute operations ([0038] “FIG. 8 is a block diagram of a computing system 800 suitable for implementing one or more embodiments of the present disclosure. In its most basic configuration, the computing system 800 may include at least one processor 802 and at least one memory 804.” [0040] “Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to the at least one processor 802 for execution. Such a medium may take many forms, including but not limited to, non-transitory media”).
Claims 5 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Godefroid in view of Lin, Coker and Gauthier as applied to Claims 1 and 10 above, and further in view of Ramaswamy et al. (US Patent 6,622,119; hereinafter “Ramaswamy”).
Claim 5: (Currently Amended)
Godefroid in view of Lin, Coker and Gauthier teaches all the limitations of claim 1 as described above. Godefroid in view of Lin, Coker and Gauthier does not teach the following, however, Ramaswamy teaches wherein the generating of the sequence of operations includes:
determining, using a transformer language model, probabilities of multiple permutations of orderings of the operations within the resource-specific group, wherein the operations within the resource-specific group are permutated based on recognized verbs of the operations (Col. 6 Ln. 48: “the prediction model 204 is constructed using methods similar to the construction of trigram language models.” Col. 5 Ln. 9: “The probability calculator 206 uses the command history 202, the current access method, and a prediction model 204 to calculate the conditional probability for each formal command, given the history and current access method.”); and
generating the sequence based on a permutation of the multiple permutations having a greatest probability (Col. 5 Ln. 22: “The conditional probability of equation (1) is calculated for all formal commands in system 100, and the formal commands are ranked according to their corresponding conditional probability, with the most probable formal command appearing at the top of a list 208. The list 208 including the ranked formal commands and their associated probabilities is presented to the NLU engine 110, and to the dialog manager 112.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Godefroid in view of Lin, Coker and Gauthier with the sequence determination using a language model as taught by Ramaswamy in order “to improve the accuracy and speed of the natural understanding system and permit the system to take initiative to prompt the user with one or more predicted commands” (Ramaswamy Col. 3 Ln. 19).
Claim 14:
With regard to Claim 14, this claim is equivalent in scope to Claim 5 rejected above, merely having a different independent claim type, and as such Claim 14 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 5.
Claims 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Godefroid in view of Lin, Coker and Gauthier as applied to Claims 1 and 10 above, and further in view of Roques et al. (US Patent 7,707,553; hereinafter “Roques”).
Claim 8: (Currently Amended)
Godefroid in view of Lin, Coker and Gauthier teaches all the limitations of claim 1 as described above. Godefroid in view of Lin, Coker and Gauthier does not teach the following, however, Roques teaches
wherein the sequence of operations is a lifecycle-based sequence corresponding to a lifecycle of the selected resource (Col. 5 Ln. 8: “the Test Generator (103) of the preferred embodiment generates tests having a scenario that checks the life-cycle of the objects of the application,” wherein the “object” is the “resource”. Col. 5 ln. 59: “a set of tests covering the object life-cycle as recommended in the specifications: the creation of objects, the persistence of objects and the deletion of objects.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Godefroid in view of Lin, Coker and Gauthier with the life-cycle testing as taught by Roques since “there is a need for a method to create test generators which can be used to test an application independently from its particular semantic but with a test scenario which is close to the logic of the programming of the application” (Roques Col. 2 Ln. 1).
Claim 17:
With regard to Claim 17, this claim is equivalent in scope to Claim 8 rejected above, merely having a different independent claim type, and as such Claim 17 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 8.
Response to Arguments
Applicant’s arguments, see Pages 10-18 of the Remarks filed May 30, 2025, with respect to the 35 U.S.C. 101 rejections have been fully considered and are persuasive. The 35 U.S.C. 101 rejections of Claims 1, 3, 5-10, 12 and 14-19 have been withdrawn.
Applicant's further arguments, see Pages 18-23 of the Remarks, with respect to the rejections under 35 U.S.C. 103 of Claims 1, 10 and 19 have been fully considered but they are not persuasive. With respect to the Applicant’s argument that the newly amended language of Claims 1, 10 and 19 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Lin et al. (US PGPUB 2025/0245131), Coker (US Patent 8,745,641) and Gauthier et al. (US PGPUB 2021/0141904) references as discussed above in the respective rejections.
With respect to the Applicant’s further arguments, see Pages 23-24 of the Remarks, that the features of the remaining claims are not taught by the cited prior art, the Office respectfully disagrees. These arguments rely upon the arguments as presented in relation to claims discussed above, and as such the Office directs the Applicant to the responses above regarding these arguments.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Battiato et al. (US PGPUB 2023/0089336) discloses a system and method for providing the ability to automate the process of generating load tests used for benchmarking APIs, wherein load tests are automatically generated based on analyzing a provided API specification.
Banias et al. (“Automated Specification-Based Testing of REST APIs,” 2021) discusses a solution that automates the generation of test cases for REST APIs based on their specifications, including an option for a user to influence the test generation process.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/JOANNE G MACASIANO/Examiner, Art Unit 2197