DETAILED ACTION
This action is written in response to the remarks and amendments filed 4/8/26. This action is made final. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
The Applicants argue that the previous art of record does not anticipate or render obvious the claims as currently amended. The Examiner provides updated prior art rejections below necessitated by the current amendments.
§103 – The Applicant argues “In relying on Jha, the Office alleges that Jha starting at Col. 4, lines 61 discloses the claimed tenancy. However, Jha is silent with respect to a "tenancy," and merely describes that an "API service platform 102 provides its services using one or more API edge servers and/or one or more test servers that each handles requests" and that the "plurality of API edge servers may assist fault tolerance, load balancing, and geographical distribution." Jha, Col. 4, lines 61-67. That is, Jha merely describes shared platform infrastructure, including edge servers and test servers that serve the entire platform. These servers are not tenancies created for individual simulated APIs, much less tenancies created based on the API type defining a statefulness of the API.”
The Examiner is not persuaded. The Applicant argues against the Examiner’s claim construction without providing any alternative definition for this term. The term ‘tenancy’ is not defined by the Applicant in the specification, nor does it appear to have a widely-used definition. The term is only loosely described by the Applicant in the specification. Accordingly, the examiner interprets this term according to its broadest reasonable interpretation in view of its plain dictionary meaning1 as encompassing any deployment or hosting of a simulated API. By analogy, the API holds a ‘tenancy’ by residing and operating from a particular server.
§103 – The Applicant argues “Even assuming for the sake of argument that Jha's servers disclose a tenancy (which Applicant does not concede), the servers are not created based on the API type defining a statefulness of the API as claimed. Rather, Jha merely describes using the test servers based on whether simulation mode is enabled, not based on any property of the API itself. Jha, Col. 5, lines 5-9.”
The Examiner is not persuaded. The cited portion of Jha discloses creating and hosting a simulated API according to the API’s definition, ie its code. See col. 10, lines 17 et seq. Although Jha does not explicitly discuss API statefulness, ie whether the API is stateful/dynamic or stateless/static, a statefulness property is an inherent property of any API. There are only two ‘types’ of statefulness: stateful (also called dynamic) and stateless (also called static). In either case, the type of API can be determined directly from its code. At the time of filing, it would have been obvious to a person of ordinary skill to deploy and host either or both types of API, depending on the desired functionality. The techniques for Jha for deploying and hosting simulated APIs apply equally to both types.
For the foregoing reasons, the Examiner maintains all outstanding prior art rejections, which are reproduced infra, and have been updated as necessitated by the Applicant’s amendments.
Subject Matter Eligibility
In determining whether the claims are subject matter eligible, the examiner has considered and applied guidance from MPEP § 2106. The examiner finds that the independent claims are directed to the practical application of simulating an Application Programming Interface (API) on a computer.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
The following are the references relied upon in the rejections below:
Jha (US 10,705,942 B1)
Koker (US 2018/0307529 A1)
Muttik (US 2018/0097829 A1)
Claims 1-6, 9-14, 17-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jha.
Regarding claims 1, 10 and 18, Jha discloses a computer-implemented method comprising:
receiving, by a simulator generator, an application programming interface (API) specification defining one or more parameters of an API;
Col. 10, lines 17 et seq., “At 202, a design of an API is received. In some embodiments, receiving the design includes receiving an API definition. Examples of the API definition include a specification (e.g., Swagger specification), a schema, and other identification of one or more properties and/or capabilities of an API.”
automatically generating, by the simulator generator, simulated data based on the API specification;
Col. 10, “At 204, the API is tested. In some embodiments, testing the API includes verifying whether the API will function as desired, e.g., provide expected responses when an API call is made. In some embodiments, testing the API includes modeling the API definition of the API and simulating the API without requiring a developer to provide server implementation code of the API. For example, a simulated response to a call to an operation defined in the API definition is provided to a developer to allow the developer to test and verify the design of the operation.” (Emphasis added.)
determining, by a simulator manager, an API type based on the API specification and the simulated data, the API type defining a statefulness of the API;
Col. 10, lines 17 et seq., “In some embodiments, receiving the design includes receiving an API definition. The API definition defines how an underlying resource can be accessed. Examples of the API definition include a specification (e.g., Swagger specification), a schema, and other identification of one or more properties and/or capabilities of an API. The API definition may expose content and/or services (e.g., API resources) to internal or external audiences. The design of the API definition may be performed by a developer in a development environment. For example, using the development interface shown in FIG. 3, a developer creates, imports, and/or edits the API definition. In some embodiments, the received API definition is validated automatically and API documentation is automatically generated.” (Emphasis added.)
Col. 18, line 18 et seq., “At 506, a simulation state is stored. For example, a simulated response to the simulated execution is stored in 20 storage 106 shown in FIG. 1A. By storing the simulation state, the simulation/testing state can referenced later. Additionally, multiple developers may access the simulation state, and the stored simulation state allows the developers to collaborate to develop the API. For example, a link such 25 as a universal resource identifier (URI) linked to a simulated state/response of the API development environment enables a developer to access the API in the associated state. That is, a link to the development environment in a saved state is accessible by users with knowledge of the URI, allowing for 30 easy collaboration.” (Emphasis added.)
automatically generating, by the simulator generator, a simulation of the API based on the API specification and the simulated data;
Col. 10, lines 32 et seq., “At 204, the API is tested. In some embodiments, testing the API includes verifying whether the API will function as desired, e.g., provide expected responses when an API call is made. In some embodiments, testing the API includes modeling the API definition of the API and simulating the API without requiring a developer to provide server implementation code of the API. For example, a simulated response to a call to an operation defined in the API definition is provided to a developer to allow the developer to test and verify the design of the operation.” (Emphasis added.)
creating, based on the determined API type, a tenancy for the simulated API,
The Applicant provides no definition for ‘tenancy’ in the specification. Accordingly, the Examiner interprets this term according to its broadest reasonable interpretation as encompassing any deployment of a simulated API.
Col. 10, lines 41 et seq., “In some embodiments, a test server is automatically created to host a simulated version of the API that returns simulated/mock responses to a call to the API. Not only does this simplify testing of the design of the API definition, it allows parallel development of user applications that will be utilizing the API before the implementation code of the API has been fully developed.” (Emphasis added.)
Col. 4, lines 61 et seq. “API service platform 102 provides its services using one or more API edge servers and/or one or more test servers that each handles requests. In some embodiments, the API service platform includes a plurality of edge servers. A plurality of API edge servers may assist fault tolerance, load balancing, and geographical distribution.”
deploying, by a simulator engine and the created tenancy, the simulated API based on the determined API type to facilitate access to the simulated API by an external agent.
Col. 10, lines 41 et seq., “In some embodiments, a test server is automatically created to host a simulated version of the API that returns simulated/mock responses to a call to the API. Not only does this simplify testing of the design of the API definition, it allows parallel development of user applications that will be utilizing the API before the implementation code of the API has been fully developed.” (Emphasis added.)
Although Jha clearly discloses the ability so simulate stateful/dynamic APIs (see excerpt from col. 18 supra), Jha does not clearly describe simulating stateless/static APIs, or clearly describe explicitly determining an API statefulness, ie whether the API is stateful/dynamic or stateless/static. However, a statefulness property is an inherent property of any API. There are only two ‘types’ of statefulness: stateful/dynamic and stateless/static. In either case, the type of API can be determined directly from its code. At the time of filing, it would have been obvious to a person of ordinary skill to deploy and host either or both types of API, depending on the desired functionality. For examples, static APIs are simpler in the sense that they do not require a stored state. Whether static or dynamic is preferable depends on the intended use. The techniques for Jha for deploying and hosting simulated APIs apply equally to both types. See also Response to Arguments section supra.
Regarding independent claim 10, Jha also discloses its further limitations comprising “one or more processors” and “a memory storing instructions” (see col. 2, lines 25 et seq.).
Regarding independent claim 18, Jha discloses its further limitation comprising: …
generate, by the simulator engine using the simulated API and based on an API request received from the external computing device, an API response; and
Col. 1, lines 60 et seq., “FIG. 6D is an example of a GUI for an API development environment including a simulation function with an example response.”(cont.) “FIG. 6E is an example of a GUI for an API development environment including a simulation function with an example response.”
provide, by the simulator engine, the API response to the external computing device.
Id.
Regarding claims 2 and 11, Jha discloses the further limitation wherein the tenancy comprises one or more dedicated resources for the simulated API.
Col. 4, lines 61 et seq. “API service platform 102 provides its services using one or more API edge servers and/or one or more test servers that each handles requests. In some embodiments, the API service platform includes a plurality of edge servers. A plurality 65 of API edge servers may assist fault tolerance, load balancing, and geographical distribution.”
Regarding claims 3 and 12, Jha discloses the further limitation wherein the tenancy is a dynamic tenancy configured to support a stateful API simulation.
Col. 18, line 18 et seq., “At 506, a simulation state is stored. For example, a simulated response to the simulated execution is stored in 20 storage 106 shown in FIG. 1A. By storing the simulation state, the simulation/testing state can referenced later. Additionally, multiple developers may access the simulation state, and the stored simulation state allows the developers to collaborate to develop the API. For example, a link such 25 as a universal resource identifier (URI) linked to a simulated state/response of the API development environment enables a developer to access the API in the associated state. That is, a link to the development environment in a saved state is accessible by users with knowledge of the URI, allowing for 30 easy collaboration.” (Emphasis added.)
Col. 4, lines 61 et seq. “API service platform 102 provides its services using one or more API edge servers and/or one or more test servers that each handles requests. In some embodiments, the API service platform includes a plurality of edge servers. A plurality 65 of API edge servers may assist fault tolerance, load balancing, and geographical distribution.”
Regarding claims 4 and 13, Jha discloses the further limitation comprising:
receiving, by the simulator engine, an API request from an external agent; and
Figs. 6A and 6B.
Col. 4, line 61 et seq., “API service platform 102 provides its services using one or more API edge servers and/or one or more test servers that each handles requests. In some embodiments, the API service platform includes a plurality of edge servers. A plurality 65 of API edge servers may assist fault tolerance, load balancing, and geographical distribution.“
providing, based on the API type, a stateful API response corresponding to the received API request using a state manager engine.
Col. 18, line 18 et seq., “At 506, a simulation state is stored. For example, a simulated response to the simulated execution is stored in 20 storage 106 shown in FIG. 1A. By storing the simulation state, the simulation/testing state can referenced later. Additionally, multiple developers may access the simulation state, and the stored simulation state allows the developers to collaborate to develop the API. For example, a link such 25 as a universal resource identifier (URI) linked to a simulated state/response of the API development environment enables a developer to access the API in the associated state. That is, a link to the development environment in a saved state is accessible by users with knowledge of the URI, allowing for 30 easy collaboration.” (Emphasis added.)
See also col. 5, line 10 et seq. discussing API responses.
Regarding claim 5, Jha discloses the further limitation comprising retrieving the stateful API response from a datastore using the state manager engine.
Col. 18, line 18 et seq., “At 506, a simulation state is stored. For example, a simulated response to the simulated execution is stored in 20 storage 106 shown in FIG. 1A. By storing the simulation state, the simulation/testing state can referenced later. Additionally, multiple developers may access the simulation state, and the stored simulation state allows the developers to collaborate to develop the API. For example, a link such 25 as a universal resource identifier (URI) linked to a simulated state/response of the API development environment enables a developer to access the API in the associated state. That is, a link to the development environment in a saved state is accessible by users with knowledge of the URI, allowing for 30 easy collaboration.” (Emphasis added.)
Col. 8, “For example, processor 152 can also directly and very rapidly retrieve and store frequently needed data in a cache memory included in memory 160.”.
Regarding claims 6, 14 and 20, Jha discloses the further limitation comprising generating, based on the API specification and the simulated data, a simulated frontend interface, configured for the simulated API.
Fig. 6A, reproduced below.
PNG
media_image1.png
582
594
media_image1.png
Greyscale
See also figs. 6-10.
Regarding claims 9 and 17, Jha discloses the further limitation wherein generating the simulated data is based on at least one of:
one or more data parameters defining one or more data requirements, or one or more data-field parameters defining field constraints of a corresponding frontend interface.
Col. 10, lines 17 et seq., “At 202, a design of an API is received. In some embodiments, receiving the design includes receiving an API definition. Examples of the API definition include a specification (e.g., Swagger specification), a schema, and other identification of one or more properties and/or capabilities of an API.”
Claims 7-8 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Jha and Muttik.
Regarding claim 7 and 15, Muttik discloses the further limitation which Jha does not disclose wherein generating the simulated data comprises anonymizing a dataset by removing non-public information from the dataset.
[0082] “Data aggregator 410 aggregates the data provided by data collector 408. This may include categorizing, compressing, packaging, sorting, organizing, or otherwise processing data to make it suitable for export to and consumption by a third party. Note that data aggregator 410 may also have the task of masking, obfuscating, or rejecting certain portions of the data collected by data collector 408. For example, if the data include emails, data aggregator 410 may redact specific email addresses and other personally identifying information. Other types of data that may be obfuscated or redacted include names, addresses, phone number, social security numbers, account numbers, credit card data, billing data, personal preferences, locations, or any other sensitive data. This enables secured enterprise 100 to export certain documents that contain sensitive data without compromising those sensitive data.” (Emphasis added.)
At the time of filing, it would have been obvious to a person of ordinary skill to apply the redaction techniques of Muttik to the API simulation system of Jha because this would protect confidential, private or sensitive data from public disclosure. In some cases, this may be required by law. Both disclosures pertain to APIs.
Regarding claim 8 and 16, Muttik discloses the further limitation which Jha does not disclose wherein generating the simulated data comprises generating a dummy dataset free of non-public information.
[0082] “Data aggregator 410 aggregates the data provided by data collector 408. This may include categorizing, compressing, packaging, sorting, organizing, or otherwise processing data to make it suitable for export to and consumption by a third party. Note that data aggregator 410 may also have the task of masking, obfuscating, or rejecting certain portions of the data collected by data collector 408. For example, if the data include emails, data aggregator 410 may redact specific email addresses and other personally identifying information. Other types of data that may be obfuscated or redacted include names, addresses, phone number, social security numbers, account numbers, credit card data, billing data, personal preferences, locations, or any other sensitive data. This enables secured enterprise 100 to export certain documents that contain sensitive data without compromising those sensitive data.” (Emphasis added.)
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Jha and Koker.
Regarding claim 21, Koker discloses the further limitation wherein the created tenancy is configured to isolate the simulated API by limiting access to a host of the tenancy to the one or more dedicated resources.
[0144] “Stated differently, barriers are an architectural feature that is exposed to application programming interface (API), where existing GPUs have dedicated hardware resources for implementing barriers.”
At the time of filing, it would have been obvious to a person of ordinary skill to create limited access (ie sandboxed) simulated APIs (as taught by Koker) in combination with the Jha system. APIs—and indeed all computer programs—are often tested extensively before they are deployed in order to detect and correct bugs. By limiting resources access, system engineers can avoid wasting computing resources, as well as protect access to confidential or sensitive data, until all responsible parties are confident that the API is ready for deployment.
Additional Relevant Prior Art
The following references were identified by the Examiner as being relevant to the disclosed invention, but are not relied upon in any particular prior art rejection:
Sarid discloses an API notebook tool, facilitating the creation, testing and documentation of APIs. (US 10,216,554 B2)
Sethi discloses a REST API architecture with a statefulness attribute. See [0045]. (US 2024/0202165 A1)
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee 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 Vincent Gonzales whose telephone number is (571) 270-3837. The examiner can normally be reached on Monday-Friday 7 a.m. to 4 p.m. MT. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Miranda Huang, can be reached at (571) 270-7092.
Information regarding the status of an application may be obtained from the USPTO Patent Center.
/Vincent Gonzales/Primary Examiner, Art Unit 2124
1 The following definition from The American Heritage Dictionary is illustrative: “tenancy, 1. Possession or occupancy of lands, buildings, or other property by title, under a lease, or on payment of rent. 2. The period of a tenant's occupancy or possession. 3. A habitation held or occupied by a tenant.” From: https://www.ahdictionary.com/word/search.html?q=tenancy, accessed 28 May 2026.
Prosecution Insights