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
The instant application having Application No. 18/435,975 filed on 2/07/2024 is presented for examination.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Drawings
The applicant’s drawings submitted are acceptable for examination purposes.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submissions of the Information Disclosure Statement dated 12/19/2024 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
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).
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.
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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Farquhar (US 11,507,730) discloses executing a documentation application displaying a graphical user interface having an editable field configured to receive textual input. The system receives a first portion of a textual input in the editable field, which includes a command character designating the first portion of the textual input as a link insertion command. The system receives a second portion of textual input in the editable field and, before entry of the textual input is complete, the system analyzes the second portion of the textual input to identify an external platform service. The system then accesses, using an application programming interface, first hosted data hosted by the external platform service. The first hosted data may be displayed in line with the textual input and used to generate a complete link path. Once complete, the link path is replaced with a selectable graphical object that is operable, when selected, to redirect the user to the external platform service.
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 6/04/2026
Prosecution Insights