DETAILED ACTION
Claims 1-20 are pending.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/29/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim 11 objected to because of the following informalities: “One or more non-transitor storage media” should be amended to read “One or more non-transitory storage media”. Appropriate correction is required.
Claim Rejections - 35 USC § 102
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.
Claims 1-5, 7, 10-15, 17, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Interface Refactoring Catalog, “Introduce Version Mediator” October 3, 2023, hereinafter “IVM”.
IVM was cited in IDS.
Regarding claim 1, IVM teaches a method comprising:
detecting a breaking change between a first version of an application programming interface (API) and a second version of the API (Page 2, par 2, “One or more breaking change of the API have happened”; Page 3, Instructions, Find fields that change their type);
generating one or more mapper functions associated with the first version of the API and the second version of the API (Page 3, Instructions, Find fields that change their type, and define a mapping rule to implement the type change; Page 4, Target Solution Sketch, A rule-based Compatibility Mediator implements the compatibility mappings, either as plain code or declarative, and acts as a gateway between “old” clients and the “new” provider; See Figure 2 below).
PNG
media_image1.png
332
696
media_image1.png
Greyscale
receiving a first version request from a client computing device, wherein the first version request is compatible with the first version of the API (See Fig. 2 above, Client Application is shown communicating with API provider Endpoint v1);
converting, via the one or more mapper functions, the first version request to a second version request, wherein the second version request is compatible with the second version of the API (Page 1 “As an API client, I want to continue to call a deprecated API for some time, and I expect the provider to support me with a temporary solution for doing so. The behavior of this solution should be identical to those of the API that I have been using so far”; Page 3, Instructions, “Add a new endpoint to the API for the “new” API version. Derive its contract from the “old” one and adjust the “old” endpoint to mediate “old” operations and their representation elements to “new” ones with mapping rules”; See Fig. 2, Compatibility Mediator shown in between API v1 and API v2; Page 6 “API gateway Version1ToVersion2Mediator”);
providing the second version request to an endpoint of the API (See Fig. 2, solid line provided by the Compatibility Mediator to Endpoint v2);
receiving a second version response from the endpoint of the API, wherein the second version response is compatible with the second version of the API (See Fig. 2, dotted line from right to left from Endpoint v2 to Compatibility Mediator);
converting, via the one or more mapper functions, the second version response to a first version response, wherein the first version response is compatible with the first version of the API (See Fig. 2, dotted line from right to left from Compatibility Mediator to Endpoint v1); and
providing the first version response to the client computing device, wherein the method is performed by one or more computing devices (See Fig. 2, dotted line from right to left from Endpoint v1 to API client).
Regarding claim 2, IVM teaches wherein the breaking change comprises a modification to the API that causes the second version of the API to be incompatible with the first version of the API (Page 1, An API runs in production. One of its supported versions will be retired soon, but existing clients still use it. One or more breaking changes have been introduced in subsequent, active versions; Page 2, par 2, “One or more breaking change of the API have happened”; Page 3, Instructions, Find fields that change their type).
Regarding claim 3, IVM teaches wherein the modification comprises:
a parameter or an object in the first version of the API being renamed in the second version (Page 6, element “zipString to ZipCode”);
a data type of the parameter or the object in the first version of the API being changed in the second version of the API;
a size of a field in the first version of the API being decreased in the second version of the API;
an endpoint in the first version of the API being removed in the second version of the API (Page 1, “One of its supported versions will be retired soon…deprecated API”; Fig. 2 Endpoint v1 will eventually be deprecated and replaced by Endpoint v2);
the parameter in the first version of the API being designated as required in the second version of the API;
a required parameter being added to the second version of the API;
a default value of the parameter in the first version of the API being change in the second version of the API;
a check constraint being added to the second version of the API; or
an input method in the first version of the API being changed in the second version of the API.
Regarding claim 4, IVM teaches wherein the modification to the API comprises a modification to the endpoint of the API (Page 1, API runs in production, supported versions will be retired soon.; Fig. 2, Endpoint v1 replaced by Endpoint v2).
Regarding claim 5, IVM teaches wherein the one or more mapper functions comprise a request mapper function and a response mapper function, and wherein: the first version request is converted to the second version request via the request mapper function, and the second version response is converted to the first version response via the response mapper function (Fig. 2, shows the Compatibility Mediator performing conversions in both directions, request and response from Endpoint v2 to Endpoint V1; Page 6 “Compatibility Mediator…request/response”).
Regarding claim 7, IVM teaches wherein the one or more mapper functions are generated based at least in part on an extension in an API specification associated with the first version of the API, the extension defining the breaking change (Page 6, API gateway Version1ToVersion2Mediator).
PNG
media_image2.png
193
385
media_image2.png
Greyscale
Regarding claim 10, IVM teaches wherein: the first version request is incompatible with the second version of the API, the second version request is incompatible with the first version of the API, the second version response is incompatible with the first version of the API, and the first version response is incompatible with the second version of the API (Compatibility Mediator shown on Fig. 2 addresses incompatibilities between Endpoint v1 and Endpoint v2).
Regarding claim 11, it is a media/product type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 12, it is a media/product type claim having similar limitations as claim 2 above. Therefore, it is rejected under the same rationale above.
Regarding claim 13, it is a media/product type claim having similar limitations as claim 3 above. Therefore, it is rejected under the same rationale above.
Regarding claim 14, it is a media/product type claim having similar limitations as claim 4 above. Therefore, it is rejected under the same rationale above.
Regarding claim 15, it is a media/product type claim having similar limitations as claim 5 above. Therefore, it is rejected under the same rationale above.
Regarding claim 17, it is a media/product type claim having similar limitations as claim 7 above. Therefore, it is rejected under the same rationale above.
Regarding claim 20, it is a media/product type claim having similar limitations as claim 10 above. Therefore, it is rejected under the same rationale above.
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 6, 8, 9, 16, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Interface Refactoring Catalog, “Introduce Version Mediator” October 3, 2023, hereinafter “IVM”, in further view of Kumar et al. (US 2024/0220338 A1).
IVM was cited in IDS.
Regarding claim 6, IVM teaches the main concept of introducing a Compatibility Mediator between two different versions of an API to translate/map requests across versions and detecting a breaking change between the second version of the API and a third version of the API (Page 2, par 2, “One or more breaking change of the API have happened”; Page 3, Instructions, Find fields that change their type). IVM does not expressly teach but Kumar does teach wherein the one or more mapper functions comprise one or more first mapping functions, the method further comprising:
generating one or more second mapper functions associated with the second version of the API and the third version of the API ([0005] transforming, by the second step-up request transformer, the second API request into a third API request, the third API request being compatible with a third version of the API and being an input to a handler);
receiving another first version request from the client computing device, wherein the other first version request is compatible with the first version of the API ([0005] receiving, by a computer system, a first API request compatible with a first version of an AP);
converting, via the one or more first mapper functions, the other first version request to another second version request, wherein the other second version request is compatible with the second version of the API ([0005] transforming, by a first step-up request transformer of the computer system, the first API request into a second API request, the second API request being compatible with a second version of the API and being an input to a second step-up request transformer of the computer system);
converting, via the one or more second mapper functions, the other second version request to a third version request, wherein the third version request is compatible with the third version of the API ([0005] transforming, by the second step-up request transformer, the second API request into a third API request, the third API request being compatible with a third version of the API and being an input to a handler);
providing the third version request to the endpoint of the API ([0031] The third API request may have a format that is compatible with a format of a third API version and may be an input to a handler (e.g., one of handlers 120).);
receiving a third version response from the endpoint of the API, wherein the third version response is compatible with the third version of the API ([0031] In some examples, the handler may retrieve data requested by the first API request from database 140.);
converting, via the one or more second mapper functions, the third version response to another second version response, wherein the other second version response is compatible with the second version of the API ([0031] In some examples, the handler sends the data in a payload of a first API response to a first step-down response transformer, the first API response having a format compatible with a format of a third version of the API.; [0032] In some examples, the first step-down response transformer transforms the first API response into a second API response, the second API response being compatible with the second version of the API and an input format of a second step-down response transformer.);
converting, via the one or more first mapper functions, the other second version response to another first version response, wherein the other first version response is compatible with the first version of the API ([0033] The second step-down transformer may transform the second API response into a third API response, the third API response being compatible with the first version of the API.); and
providing the other first version response to the client computing device ([0033] In some examples, an API module (e.g., API module 122) associated with the first version of the API may output the third API response to first consumer system 102A)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kumar with the teachings of IVM to apply the mediator concept with multiple API versions. The modification would have been motivated by the desire of ensuring legacy applications can access services regardless of API updates.
Regarding claim 8, Kumar teaches wherein generating the one or more mapper functions further comprises automatically generating source code comprising a definition of the one or more mapper functions, and source code comprising an implementation of the one or more mapper functions is received from a user ([0002] Each backend handler and respective backend source code would handle the interfacing between one API version and the commonly shared database or information repository.; [0003]).
Regarding claim 9, Kumar teaches wherein generating the one or more mapper functions further comprises: automatically generating source code comprising a definition of the one or more mapper functions, and automatically generating source code comprising an implementation of the one or more mapper functions ([0002] Each backend handler and respective backend source code would handle the interfacing between one API version and the commonly shared database or information repository.; [0003]).
Regarding claim 16, it is a media/product type claim having similar limitations as claim 6 above. Therefore, it is rejected under the same rationale above.
Regarding claim 18, it is a media/product type claim having similar limitations as claim 8 above. Therefore, it is rejected under the same rationale above.
Regarding claim 19, it is a media/product type claim having similar limitations as claim 9 above. Therefore, it is rejected under the same rationale above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rojas Fonseca et al. (US 2023/0081395) teaches in [0046] If the indicated version is a prior version of the REST API which does not correspond to the current version of the schema used by the database (decision 604) (i.e., the versions do not match or are nonmatching versions), the system dispatches the request to a translation proxy (operation 608). The system applies, by the translation proxy, rules which convert the request to indicate an updated REST API version corresponding to the current version of the schema (operation 610). The system receives, from the translation proxy, the converted request which indicates the updated REST API version corresponding to the current version of the schema (operation 612). The system obtains results from the database based on the converted request and the applied rules (operation 614). The system can perform, by the translation proxy based on the rules, a reverse translation on the obtained results to a format associated with the request, and can return the reverse translated results as the results (not shown). The system returns the results (or the reverse translated results, as described above in relation to FIG. 1), wherein the prior version of the REST API comprises an old version and wherein the current version of the schema comprises a new version, which enables functionality from the new version to work with the old version (operation 616). The operation returns. While flowchart 600 and prior diagrams refer to a database which uses a current (or latest) schema version and a REST API request which indicates an old schema version, the described aspects may also apply to any two different schema versions between the database and the REST API request (e.g., the database schema version may be an older version which is not the current version, and the REST API request may indicate any version which is not the same as the database schema version).
Rahill-Marier et al. (US 2022/0236965 A1) see [0248-252].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
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, Aimee J Li can be reached at (571)272-4169. 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.
/JORGE A CHU JOY-DAVILA/ Primary Examiner, Art Unit 2195
Prosecution Insights