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 .
DETAILED ACTION
This communication is responsive to Amendment filed 9/09/2026.
In Amendment, no claims are cancelled and no claims are added. Thus, claims 1-20 are pending in this application. This Office Action is made final.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Park (US 10,133,650) in view of Dolinina (US 20140075242) in further view of Kothamasu (US 20140181306).
As per claim 1, Park discloses a computing system comprising:
a processor; and
a non-transitory computer-readable storage device storing computer-executable instructions, the instructions operable to cause the processor to perform operations comprising:
parsing a request definition for an application programming interface (API) request, the request definition comprising a connector configuration and one or more API parameters (Abstract “A method for automated application programming interface (API) validation includes extracting API information from an API repository. The API information is used to generate a test case for the automated API validation. The API information may include a parameter placeholder, parameter information related to a parameter of an API endpoint, an API endpoint of the API, an endpoint description, a description of the API, a description of the parameter, response information, an authentication requirement information, and an API name. The method includes resolving the parameter of the API endpoint. The method includes communicating to a native API system a request using the sample parameter value for the parameter. The method includes comparing a response from the native API system with the response information to validate the API. The method includes verifying integrity of a software application implementing the API endpoint for use with a native software application.”);
extracting the one or more API parameters from the request definition (Column 7, line 63 – column 8, line 8 “An example machine-readable API specification 203 is depicted in FIG. 6. Referring to FIG. 6, the machine-readable API specification 203 includes a JSON file. In other embodiments, the API specification 203 may include a text file, a database record, an XML file, or another suitable file that includes API information. The machine-readable API specification 203 may include API information that may include an endpoint 604, a base-path 618, an authentication requirement 622, a host 620, an http method 608, an API endpoint description 606, parameters 625, parameter descriptions 612 and 614, parameter information 602, and response information 610. Some or all of the API information may be extracted.”);
resolving the extracted one or more API parameters (Column 8, lines 32-39 “The validation plan generator 220 may be configured to generate a validation plan 226. For example, the validation plan generator 220 may be configured to aggregate information from the API information extractor 214, the parameter resolver 216, the authentication generator 218, or some combination thereof. Based on an aggregation, the validation plan generator 220 may create a list of fully resolved list of endpoints to be validated by the API validator 222.”).
Park does not expressly discloses but Dolinina discloses
generating a request header based on the connector configuration (Paragraph 15 “Described herein is a system, a method and apparatus for a generic automated testing tool which allows testing of multiple different products via their respective REST APIs. The example generic automated testing tool can accept input in multiple formats, such as XML, a Python script, structured text, or a spreadsheet in a format such as OpenDocument Spreadsheet (ODS) format. The automated testing tool can parse and import data from these various input types to determine which tests to run for a particular target test product. Then, the automated testing tool can execute the tests for the desired target test products, and validate responses from the target test product. The automated testing tool can also generate XML and JUnit test results. The automated testing tool can perform simultaneous parallel testing of multiple target test products or of multiple aspects of a single target test product. Further, the automated testing tool can incorporate plug-ins, via a plug-in management subsystem, for providing additional functionality, such as importing different input file types, or executing tests on different platforms via their respective REST APIs. Besides providing the ability to import and export to different platforms, plug-ins can also provide other functionality for the automated testing tool, such as cleanup after running a test, interfacing with a bug tracker, logging events occurring while running tests, and so forth.”);
posting the request header (Paragraph 17 “FIG. 2 illustrates an example test scenario represented as a spreadsheet 200 representing input test file 106. The spreadsheet 200 defines column headers such as test_name, test_action, parameters, positive, run, report, and so forth. Individual column headers can be mandatory or optional for specific test types. The column headers define different test attributes, and rows in the spreadsheet represent individual tests. For example, the spreadsheet 200 illustrates a set of actions that are executed in a particular order as part of a test on the target system. In this example, row 3 indicates an action and parameters for adding a data center to be tested, and row 8 indicates an action and parameters for logging in to the data center with a particular set of credentials. A data center to be tested may include clusters of computing devices where each cluster can be a group of computing devices which are connected via one or more networks, and which can cooperate to perform computing tasks. A user can access all or part of a cluster as a single entity without accessing individual computing devices that make up the cluster. Clusters can be administered or controlled via a master computing node, or can include computing devices which are peers without such a master computing node. Each computing device may be a host machine running one or more virtual machines. The data center may also include multiple storage domains. A storage domain is a set of storage devices available to a specific cluster. The storage domain can include local disks of various computing devices, as well as a dedicated storage device, such as a network attached storage (NAS) device.”);
constructing the API request based on the connector configuration (Paragraph 21 “The configuration file 104 can include multiple sections, such as a [RUN] section, a [REST_CONNECTION] section, a [PARAMETERS] section, and a [REPORT] section. The [RUN] section provides configuration data for how to execute tests. An example [RUN] section of a simple configuration file 104 is provided below:
TABLE-US-00001 [RUN] engine = rest tests_file = /tmp/rest.xml data_struct_mod = data_struct.data_structures api_xsd = /data_struct/api.xsd debug = yes media_type = application/xml”); and
executing the API request (Paragraph 28 “A test_name attribute in the input file indicates the name of the test which will appear in reports. A test_action attribute in the input file indicates an action which will run to implement the test. Each action can be mapped to a function defined in the configuration file 104, for example. Parameters attributes read from the input test file 106 are used to construct or execute the test. Parameter names should correspond to the names of test function parameters. The user can use parameter names from the configuration file as place holders. For example, if the user puts the parameter name in { } brackets in the configuration file, the test runner 108 will replace the parameter name with the relevant value at run time. If the user desires product constants from the configuration file, the user can enter the string e{param_name}. When the test runner 108 encounters a list, such as a comma separated list, in the configuration file, the test runner can fetch the corresponding value via array indexing, such as {name_of_param[param_index]}. The test runner 108 can obtain the list as a string by using [name_of_param], such as when a user requests to view all or part of the list. When using a loop in the `run` column, see below, the user can concatenate the loop iteration index to any of the parameters.”).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Park to include the teachings of Dolinina because it automates the parsing, parameter resolution and execution of API requests using a well known API configuration and execution techniques.
Park as modified does not expressly disclose but Kothamasu discloses the constructed API request comprising the generated request header (Abstract “Design-time wizards help create runtime artifacts and, during runtime, the connector service helps serve as an intermediary between the on-premises application and the cloud service, thereby hiding the complexity of the specific cloud providers.” See also, paragraph 13 “a client device is configured to transparently access one or more cloud-based applications managed by one or more respective cloud providers. The client device comprises at least one processor, and an interface to connector services administered by a computer system. The computer system is configured to coordinate at least the elements indicated in the preceding paragraph and/or elsewhere herein (e.g., the plurality of metadata handlers, the exporter module, and the plurality of connection factory instances). The connector services may be generated by the computer system based on input from the connection factory instances and matching connector descriptors.”); and
the executing comprising transmitting the request header with the API request to a downstream external resource identified by a uniform resource locator specified in the connector configuration (Paragraph 55 “The Connector Development Kit (CDK) shown in FIG. 2 is an abstract layer for interacting with all SaaS applications in a uniform way. The Connector Descriptor Kit may be thought of as being a set of libraries and an API for describing a SaaS provider's services and operations. Key aspects of all supported SaaS providers may be defined in terms of the interfaces found in this kit, e.g., so that the service operations may be accessed in a consistent manner.” See also, paragraph 57 “For example, a WSDL-based handler implementation may have a data element in its model to describe a WSDL URL; however, a REST handler may have no need for this information.”).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Park as modified to include the teachings of Kothamasu it allows disparate programs to communicate with each other through a published API in order to increase interoperability.
As per claim 2, Park discloses the computing system of claim 1, wherein resolving the extracted one or more API parameters comprises:
resolving the extracted one or more API parameters in a recursive fashion; and
substituting each extracted value based on the connector configuration (Column 3, lines 39-52 “FIG. 1 illustrates a block diagram of an example operating environment 100 arranged in accordance with at least one embodiment described herein. The operating environment 100 may include an automated API validation system 110 that is configured to implement machine-generated API parameter resolution and API validation. The machine-generated API parameter resolution enables automated resolution of parameters of one or more APIs, which generates sample parameter values for the parameters of the APIs. The machine-implemented API validation further enables automated validation of the APIs using the sample parameter values for resolved parameters. The validation ensures that the APIs are current, functional, and return correct information.”).
As per claim 3, Park discloses wherein the operations further comprise validating the extracted one or more API parameters (Column 4, lines 1-18 “A benefit of the automated API validation may include efficient and reliable building of software applications, verification of API endpoints used in a software application prior to use or deployment, updating of software applications that employ at least one API, or some combination thereof. For example, some software applications may interact with native software applications and databases on a native API system by employing at least one API. Validation of the APIs may verify that the software application properly interfaces with the native software application or may help ensure that a currently used software applications are properly operating. Moreover, failure to validate APIs or API endpoints may indicate a problem with the software application and/or the native software application or may indicate why the native software application is not properly working. Accordingly, the validation of the APIs described herein may be used to verify, develop, or modify the process of using APIs with the native software applications.”).
As per claim 4, Park discloses wherein resolving the extracted one or more API parameters comprises identifying an API type associated with the API request from the request definition (Column 5, lines 39-46 “The automated API validation system 110 may be configured to access or receive the machine-readable API specifications from the API repository 128. The machine-readable API specifications may include API information, which may be used to resolve parameters and validate the APIs. For example, the API information may be used to generate a test case or a text case validation record for the automated API validation.”).
As per claim 5, Dolinina discloses wherein constructing the API request comprises constructing the API request with the identified API type (Paragraph 58 “The user can insert a START_GROUP cell 702 and an END_GROUP cell 704 that define the boundaries of the group, so that the test runner 108 treats tests between the START_GROUP cell 702 and the END_GROUP cell 704 as a group. The test runner 108 executes or causes to be executed test actions 112 on the target test platform via a REST based engine, such as an API, a command line interface (CLI), or a software development kit (SDK). The test runner 108 can send all types of REST API requests, such as GET, PUT, POST, DELETE, TRACE, or CONNECT. The test runner 108 can receive feedback regarding the progress, success, failure, or other status of tests, which a results reporter 110 can output to a user. The results reporter 110 can report results via active messages, such as a pop-up in a graphical user interface, via email or text message, via an entry in a log, and so forth. The results reporter 110 can generate nested reports containing results of sub-tests. The results reporter 110 can also generate a single report summarizing the results of the test actions 112 for a particular product, product category, feature, test suite, unit test, and so forth. The test runner 108 can simultaneously execute multiple sets of test actions 112, which can be for the same API engine 114 or a set of different test interfaces.”).
As per claim 6, Dolinina discloses wherein identifying the API type associated with the API request comprises identifying a representational state transfer (REST) type or a GraphQL type (Paragraph 58)
As per claim 7, Park discloses wherein executing the API request comprises executing the API request with one or more Spring web clients (Column 12, lines 48-56 “Additionally, in some embodiments, resolution of the parameter may include crawling a third party website to find a matching endpoint example to extract the sample parameter value for the parameter in the API. In these and other embodiments, the parameter solver 316 may be configured to perform a secondary query to find sample parameter values. For instance, in response to a query result not being found, the parameter solver 316 may perform the secondary search.”).
As per claim 8, Park discloses wherein the operations further comprise returning a final response from the API request to a user device (Column 12, lines 11-30 “Word vectors may be computed for the classes 808, 806, 804, 812, 814, 816, and 820 and the categories 802 and 822. For example, for the first result 801, a first word vector may be computed for the classes 804, 806, and 808 and the category 802. For the second result 803, a second word vector may be computed for the classes 812, 814, 816, and 820 and the category 822. The parameter classifier 314 may also generate a third word vector for the keyword (here, state) and noun phrases. The parameter classifier 314 may perform a first cosine similarity between the first word vector and the third word vector and a second cosine similarity between the second word vector and the third word vector. In response to the first cosine similarity being greater than the second cosine similarity, the parameter classifier 314 may detect that the first result 801 is the query result with the highest match and forward the first result 801 to the parameter solver 316. For example, the parameter classifier 314 may communicate “http://dbpedia.org/resource/New_York” for “state” parameter to the parameter solver 316.”).
As per claim 9, Park discloses wherein parsing the request definition for the API request comprises identifying a customized retry handler (Column 4, lines 1-18 “A benefit of the automated API validation may include efficient and reliable building of software applications, verification of API endpoints used in a software application prior to use or deployment, updating of software applications that employ at least one API, or some combination thereof. For example, some software applications may interact with native software applications and databases on a native API system by employing at least one API. Validation of the APIs may verify that the software application properly interfaces with the native software application or may help ensure that a currently used software applications are properly operating. Moreover, failure to validate APIs or API endpoints may indicate a problem with the software application and/or the native software application or may indicate why the native software application is not properly working. Accordingly, the validation of the APIs described herein may be used to verify, develop, or modify the process of using APIs with the native software applications.”).
As per claim 10, Park discloses wherein the operations further comprise executing a retry execution based on the customized retry handler (Column 4, lines 1-18).
As per claims 11-20, they are method claims having similar limitations as cited in claims 1-10 and are rejected under the same rationale.
Response to Arguments
Applicant's arguments with respect to claims 1-20 have been considered but are moot in view of the new ground(s) of rejection necessitated by Amendment.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIMOTHY A MUDRICK whose telephone number is (571)270-3374. The examiner can normally be reached 9am-5pm Central 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, Pierre Vital can be reached at (571)272-4215. 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.
/TIMOTHY A MUDRICK/Primary Examiner, Art Unit 2198 10/07/2026
