DETAILED ACTION
Claims 1-21 are cancelled. Claims 22-41 are new. Claims 22-41 are pending in the application.
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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). 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(s) fully consider the references in their 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.
Specification
The disclosure is objected to because of the following informalities:
The instant application is a continuation of U.S. Patent Application No. 17/654,496 which is now issued as U.S. Patent No. 12,073,267 B2 on August 27, 2024. Both this patent number and the issue date must be disclosed in the first paragraph of the specification and/or with the Application Data Sheet.
Appropriate corrections are required. Applicant is advised to review the entire disclosure for further needed corrections.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 22-32 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 22 recites “one or more processors coupled with memory to” in lines 2-3 and then lists functional steps processor is to perform. This limitation identifies an intended use for the claimed one or more processors. That is, it is not clear if the one or more processors actually perform the recited functional steps therewith or if they are merely intended to perform the functional steps.
For the following analysis, the Examiner will consider the one or more processors actually performing the claimed functional steps.
Claims 23-32 inherit the features of claim 22 and are rejected accordingly.
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 22-41 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-3 and 8-15 of U.S. Patent No. 12,073,267 B2 (hereinafter “reference patent”).
Instant Application
U.S. Patent No. 12,073,267 B2
Claim
Limitation
Claim
Limitation
22
A system, comprising: one or more processors of a data processing system, the one or more processors coupled with memory to: identify a first request of a service for data of the data processing system according to a first schema of the service; identify an endpoint configuration of the data processing system for a domain that provides access to the data; correlate, using an object map for the domain, the data between the first schema of the service and a second schema of the data processing system; generate, based on the correlating the data and using the endpoint configuration that includes metadata for the data identified using the object map, a second request in a structured query language and according to the second schema; retrieve, responsive to the second request, the data from the domain according to the second schema; and transmit, to the service, the retrieved data responsive to the first request of the service.
8
A computer system comprising: one or more hardware processors; and memory storing program code, the program code when executed by the one or more hardware processors, instruct the one or more hardware processors to: receive, from a requesting service, a request to access data contained in one or more data sets organized into a set of domains, wherein the request is received according to a target schema of the requesting service; identify an endpoint configuration for a domain that provides access to the data that was requested, wherein the endpoint configuration is generated from an API description describing the target schema that is published by the domain; decorate, using an object map for the domain that correlates data between the target schema and a common schema, the endpoint configuration with additional information identified from metadata documents corresponding to the one or more data sets; translate the request into the common schema based on the endpoint configuration decorated with the additional information using the object map; generate, based on the translated request, a computer instruction comprising a request in the common schema; and retrieve, responsive to the computer instruction, the data from the domain according to the common schema
23
The system of claim 22, wherein the one or more processors further: receive, from the service, the first request for the data according to the first schema of the service; and identify, using the object map for the domain, the metadata of the data to include with the endpoint configuration to generate the second request.
8
receive, from a requesting service, a request to access data contained in one or more data sets organized into a set of domains, wherein the request is received according to a target schema of the requesting service;
decorate, using an object map for the domain that correlates data between the target schema and a common schema, the endpoint configuration with additional information identified from metadata documents corresponding to the one or more data sets;
24
The system of claim 23, wherein the data is included in one or more data sets organized into a set of domains and wherein the one or more processors further generate the endpoint configuration from an application programming interface description of the first schema that is published by the domain.
8
a request to access data contained in one or more data sets organized into a set of domains, wherein the request is received according to a target schema of the requesting service; identify an endpoint configuration for a domain that provides access to the data that was requested, wherein the endpoint configuration is generated from an API description describing the target schema that is published by the domain
25
The system of claim 22, wherein the one or more processors further: decorate, using the object map for the domain, the endpoint configuration with the metadata identified from a document of one or more data sets corresponding to a set of domains comprising the domain; and translate the request from the first schema to the second schema based on the correlation of the data.
8
decorate, using an object map for the domain that correlates data between the target schema and a common schema, the endpoint configuration with additional information identified from metadata documents corresponding to the one or more data sets; translate the request into the common schema based on the endpoint configuration decorated with the additional information using the object map; generate, based on the translated request, a computer instruction comprising a request in the common schema;
26
The system of claim 22, wherein the one or more processors further: translate, in response to retrieving the data, the data from the second schema to the first schema; and send, responsive to the request, a response to the service comprising the data translated into the first schema.
9
The computer system of claim 8, wherein the one or more hardware processors are configured to: in response to retrieving the data, translate the data from the common schema to the target schema; and send a response to the requesting service, wherein the response includes the data that was translated into the target schema
27
The system of claim 22, wherein the one or more processors further: identify an information from a header of the request of the service; and identify, based on the information from the header, the endpoint configuration to use for the request.
10
The computer system of claim 8, wherein to identify the endpoint configuration, the one or more hardware processors are configured to: identify a header in the request; and match the header to the endpoint configuration according to a reduce function that matches the header to an OpenAPI document.
28
The system of claim 27, wherein the endpoint configuration is identified based on a function that matches the information of the header with an OpenAPI document.
10
The computer system of claim 8, wherein to identify the endpoint configuration, the one or more hardware processors are configured to: identify a header in the request; and match the header to the endpoint configuration according to a reduce function that matches the header to an OpenAPI document.
29
The system of claim 22, wherein the one or more processors further: identify the object map for the domain, wherein the object map correlates the data between the first schema and the second schema; identify a query set for the domain; and generate the second request based on the endpoint configuration, the object map, and the query set.
11
The computer system of claim 8, wherein to generate the computer instructions, the one or more hardware processors are configured to: identify a query set for the domain; and a generate a SQL request based on the endpoint configuration, the object map, and the query set.
30
The system of claim 29, wherein the one or more processors further: forward the second request to a data application programming interface; and retrieve the data from the data application programming interface according to the second request.
12
The computer system of claim 11, wherein to retrieve the data, the one or more hardware processors are configured to: forward the SQL request to a data API; and retrieve the data from the data API according to the SQL request.
31
The system of claim 22, wherein the one or more processors further: identify an application programming interface description published by the domain describing the first schema; and generate a controller instance for the domain from a controller template and the application programming interface description.
13
The computer system of claim 8, wherein the one or more hardware processors are configured to: generate a controller instance for the domain, including to: identify the API description published by the domain describing the target schema; and generate the controller instance from a controller template and the API description.
32
The system of claim 31, wherein the application programming interface description corresponds to an OpenAPI document that specifies one or more data sets that are available in the domain and one or more RESTful operations to be called on the one or more data sets.
14
The computer system of claim 8, wherein the API description is an OpenAPI document that specifies the one or more data sets that are available in the domain and RESTful operations that can be called on the one or more data sets.
33
A method, comprising: identifying, by one or more processors of a data processing system, a first request of a service for data of the data processing system according to a first schema of the service; identifying, by the one or more processors, an endpoint configuration of the data processing system for a domain that provides access to the data; correlating, by the one or more processors, using an object map for the domain, the data between the first schema of the service and a second schema of the data processing system; generating, by the one or more processors, based on the correlating the data and using the endpoint configuration that includes metadata for the data identified using the object map, a second request in a structured query language and according to the second schema; and retrieving, by the one or more processors, responsive to the second request, the data from the domain according to the second schema.
1
A method for accessing data using a dynamic application programming interface (“API”), the method comprising: receiving, by a computer system, from a requesting service, a request to access data contained in one or more data sets organized into a set of domains, wherein the request is received according to a target schema of the requesting service; identifying, by the computer system, an endpoint configuration for a domain that provides access to the data that was requested, wherein the endpoint configuration is generated from an API description describing the target schema that is published by the domain; decorating, by the computer system using an object map for the domain that correlates data between the target schema and a common schema, the endpoint configuration with additional information identified from metadata documents corresponding to the one or more data sets; translating, by the computer system, the request into the common schema based on the endpoint configuration decorated with the additional information using the object map; generating, by the computer system, based on the translated request, a SQL request in the common schema; and retrieving, by the computer system responsive to the SQL request, the data from the domain according to the common schema.
34
The method of claim 33, comprising: receiving, by the one or more processors, from the service, the first request for the data according to the first schema of the service; and identifying, by the one or more processors, using the object map for the domain, the metadata of the data to include with the endpoint configuration to generate the second request.
1
receiving, by a computer system, from a requesting service, a request to access data contained in one or more data sets organized into a set of domains, wherein the request is received according to a target schema of the requesting service; decorating, by the computer system using an object map for the domain that correlates data between the target schema and a common schema, the endpoint configuration with additional information identified from metadata documents corresponding to the one or more data sets; generating, by the computer system, based on the translated request, a SQL request in the common schema;
35
The method of claim 34, wherein the data is included in one or more data sets organized into a set of domains, and the method comprises: generating, by the one or more processors, the endpoint configuration from an application programming interface description of the first schema that is published by the domain.
1
receiving, by a computer system, from a requesting service, a request to access data contained in one or more data sets organized into a set of domains, wherein the request is received according to a target schema of the requesting service; identifying, by the computer system, an endpoint configuration for a domain that provides access to the data that was requested, wherein the endpoint configuration is generated from an API description describing the target schema that is published by the domain.
36
The method of claim 33, comprising: decorating, by the one or more processors, using the object map for the domain, the endpoint configuration with the metadata identified from a document of one or more data sets corresponding to a set of domains comprising the domain; and translating, by the one or more processors, the request from the first schema to the second schema based on the correlation of the data.
1
decorating, by the computer system using an object map for the domain that correlates data between the target schema and a common schema, the endpoint configuration with additional information identified from metadata documents corresponding to the one or more data sets; translating, by the computer system, the request into the common schema based on the endpoint configuration decorated with the additional information using the object map;
37
The method of claim 33, comprising: translating, by the one or more processors, in response to retrieving the data, the data from the second schema to the first schema; and sending, by the one or more processors, responsive to the request, a response to the service comprising the data translated into the first schema.
2
The method of claim 1, further comprising: in response to retrieving the data, translating the data from the common schema to the target schema; and sending a response to the requesting service, wherein the response includes the data that was translated into the target schema.
38
The method of claim 33, comprising: identifying, by the one or more processors, an information from a header of the request of the service; and identifying, by the one or more processors, based on the information from the header, the endpoint configuration to use for the request.
3
The method of claim 1, wherein identifying the endpoint configuration further comprises: identifying a header in the request; and matching the header to the endpoint configuration according to a reduce function that matches the header to an OpenAPI document.
39
The method of claim 38, wherein the endpoint configuration is identified based on a function that matches the information of the header with an OpenAPI document.
3
The method of claim 1, wherein identifying the endpoint configuration further comprises: identifying a header in the request; and matching the header to the endpoint configuration according to a reduce function that matches the header to an OpenAPI document.
40
A non-transitory computer-readable media comprising instructions that, when executed by one or more processors, cause the one or more processors to: identify a first request of a service for data of a data processing system according to a first schema of the service; identify an endpoint configuration of the data processing system for a domain that provides access to the data; correlate, using an object map for the domain, the data between the first schema of the service and a second schema of the data processing system; generate, based on the correlating the data and using the endpoint configuration that includes metadata for the data identified using the object map, a second request in a structured query language and according to the second schema; and retrieve, responsive to the second request, the data from the domain according to the second schema.
15
A computer program product comprising: a computer readable storage media; and program code, stored on the computer readable storage media, for accessing data using a dynamic application programming interface (“API”), the program code when executed, instruct a computer system to perform a method of: receiving, from a requesting service, a request to access data contained in one or more data sets organized into a set of domains, wherein the request is received according to a target schema of the requesting service; identifying an endpoint configuration for a domain that provides access to the data that was requested, wherein the endpoint configuration is generated from an API description describing the target schema that is published by the domain; decorating, using an object map for the domain that correlates data between the target schema and a common schema, the endpoint configuration with additional information identified from metadata documents corresponding to the one or more data sets; translating the request into the common schema based on the endpoint configuration decorated with the additional information using the object map; generating, based on the translated request, a SQL request in the common schema; and retrieving, responsive to the SQL request, the data from the domain according to the common schema.
41
The non-transitory computer-readable media of claim 40, wherein the instructions, when executed by the one or more processors, cause the one or more processors to: receive, from the service, the first request for the data according to the first schema of the service; and identify, using the object map for the domain, the metadata of the data to include with the endpoint configuration to generate the second request.
15
receiving, from a requesting service, a request to access data contained in one or more data sets organized into a set of domains, wherein the request is received according to a target schema of the requesting service;
decorating, using an object map for the domain that correlates data between the target schema and a common schema, the endpoint configuration with additional information identified from metadata documents corresponding to the one or more data sets; translating the request into the common schema based on the endpoint configuration decorated with the additional information using the object map; generating, based on the translated request, a SQL request in the common schema;
With respect to claims 22-41: Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-3 and 8-15 of the reference patent anticipates the limitations recited in claims 22-41 as identified 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 22, 23, 26, 27, 29, 30, 33, 34, 37, 38, 40, and 41 are rejected under 35 U.S.C. 103 as being unpatentable over Warmack (US 2021/0224145 A1; from IDS filed on 08/30/2024) in view of Kabra et al. (US 2022/0222265 A1; from IDS filed on 08/30/2024; hereinafter “Kabra”).
With respect to claim 22, Warmack teaches: A system (see e.g. Warmack, Fig. 1), comprising:
one or more processors (see e.g. Warmack, Fig. 1: “CPU 102”) of a data processing system (see e.g. Warmack, paragraph 34: “computing device 100 includes a central processing unit 102”), the one or more processors coupled with memory (see e.g. Warmack, Fig. 1: “Memory 104”; and paragraph 36: “central processing unit 102 communicates with the main memory unit 104 via a system bus 128”) to (see e.g. Warmack, paragraph 34):
identify a first request (see e.g. Warmack, Fig. 2: “API Request 204a-204n”) of a service (see e.g. Warmack, Fig. 2: “System 202a-202n”) for data of the data processing system (see e.g. Warmack, paragraph 52: “API requests 204a-204n to obtain information from a system 214 (e.g., a server providing and maintaining webpages)”) according to a first schema (see e.g. Warmack, paragraph 52: “varying formats based on the APIs that the respective ones of the system 202a-202n use… XML format… JSON format… BSON format”; and paragraph 55: “An API format may be the format in which data in the body and/or the header of an API request is positioned and any words, symbols, or phrases that are used to make such API requests. Each API format may differ in its structure, wording, or syntax. Examples of API formats include, but are not limited to, JSON, BSON, YAML, XML, and so on”) of the service (see e.g. Warmack, paragraph 52: “Systems 202a-202n may send API requests 204a-204n in varying formats based on the APIs that the respective ones of the system 202a-202n use to generate the request”);
identify an endpoint configuration of the data processing system for a domain that provides access to the data (see e.g. Warmack, paragraph 56: “identify a configuration file corresponding to the API format, and apply the API request to the configuration file to generate a new request (e.g., one of the requests 212a-212n) that is readable by the API to which the API request is directed (e.g., to the API of the endpoint of the request)”);
generate, …using the endpoint configuration (see e.g. Warmack, paragraph 75: “generate a new request with a data structure that the API of the endpoint may handle”) that includes metadata for the data identified (see e.g. Warmack, paragraph 68: “an indication of the correct region”; paragraph 70: “an indication of whether the new API request will require paging”; and paragraph 73: “name/value pairs”)…, a second request (see e.g. Warmack, Fig. 2: “New API Request 212a-212n”; paragraph 68: “determine the region to make the request by calling the endpoint and receiving an indication of the correct region to make any calls for the variable”; paragraph 70: “generate an indication of whether the new API request will require paging. This indication can be placed in the body, the header, the query string, or any other part of the new request”; and paragraph 73: “convert the format of the requested parameter by generating a new request including a request for the same parameter but using name/value pairs (which are common in the JSON format) that are delineated by various symbols such as “{”, “}”, “[”, “]”, and “:” in the JSON format”) in a structured query language (see e.g. Warmack, paragraph 66: “configuration file database 308 can be a graph database, MySQL, Oracle, Microsoft SQL, PostgreSql, DB2, document store, search engine, key-value store, etc.”; and paragraph 68: “identify parameters from the query string”) and according to the second schema (see e.g. Warmack, paragraph 33: “convert API requests originating from different APIs into a uniform API format for a client system to consume”; paragraph 52: “API conversion platform 126 may receive the API requests 204a-204n and generate new API requests 212a-212n in a common (same) format such as but not limited to, YAML, to transmit to the system 214”; paragraph 68: “identify any parameters that an API request is requesting”; and paragraph 83: “convert API requests into a common API format”);
retrieve, responsive to the second request, the data from the domain (see e.g. Warmack, paragraph 60: “response generator 211 may include programmed instructions to obtain the requested information from the endpoint”) according to the second schema (see e.g. Warmack, paragraph 58: “converted into an API request to which an API of the system 214 may read and respond”); and
transmit, to the service, the retrieved data responsive to the first request of the service (see e.g. Warmack, paragraph 60: “Once the response generator 211 generates the response, the response generator 211 may transmit the response to the requesting API”).
Warmack does not but Kabra teaches:
correlate, using an object map for the domain (see e.g. Kabra, paragraph 77: “mapping the data source. The mapping can include identifying how tables and/or columns within the data source are linked”; and paragraph 3: “mapping each data schema to a common domain schema”), the data between the first schema of the service and a second schema of the data processing system (see e.g. Kabra, paragraph 3: “mapping each data schema to a common domain schema”);
based on the correlating the data and … using the object map (see e.g. Kabra, paragraph 3: “linking, based on the mapping and on the set of attributes for each data source, common features across each data source”)
Warmack and Kabra are analogous art because they are in the same field of endeavor: mapping a target data model to a common data model. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Warmack with the teachings of Kabra. The motivation/suggestion would be to increase compatibility with different domains (see e.g. Kabra, paragraphs 3-4); thus improving the overall robustness of the system.
With respect to claim 23, Warmack as modified teaches: The system of claim 22, wherein the one or more processors further:
receive, from the service, the first request for the data according to the first schema of the service (see e.g. Warmack, paragraph 52: “systems 202a-202n making corresponding API requests 204a-204n to obtain information from a system 214 (e.g., a server providing and maintaining webpages). Systems 202a-202n may send API requests 204a-204n in varying formats based on the APIs that the respective ones of the system 202a-202n use to generate the request”); and
identify, … the metadata of the data to include with the endpoint configuration to generate the second request (see e.g. Warmack, paragraph 68: “API may instead include a variable in the request to be filled in based on the region in which the data is stored… determine the region to make the request by calling the endpoint and receiving an indication of the correct region to make any calls for the variable”; paragraph 70: “generate an indication of whether the new API request will require paging. This indication can be placed in the body, the header, the query string, or any other part of the new request”; paragraph 74: “generating a new request including a request for the same parameter but using name/value pairs (which are common in the JSON format) that are delineated by various symbols such as “{”, “}”, “[”, “]”, and “:”in the JSON format”; and paragraph 75: “structure generator 322 may identify any converted parameters, endpoints, variables, and any other type of data that were identified or converted by the parameter identifier 314, the endpoint identifier 316, and/or the parameter converter 318 and generate a new request with a data structure that the API of the endpoint may handle”).
Warmack does not but Kabra teaches:
using an object map for the domain (see e.g. Kabra, paragraph 77: “mapping the data source. The mapping can include identifying how tables and/or columns within the data source are linked”; and paragraph 3: “mapping each data schema to a common domain schema”),
Warmack and Kabra are analogous art because they are in the same field of endeavor: mapping a target data model to a common data model. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Warmack with the teachings of Kabra. The motivation/suggestion would be to increase compatibility with different domains (see e.g. Kabra, paragraphs 3-4); thus improving the overall robustness of the system.
With respect to claim 26, Warmack as modified teaches: The system of claim 22, wherein the one or more processors further:
translate, in response to retrieving the data, the data from the second schema to the first schema (see e.g. Warmack, paragraph 60: “The response generator 211 may include programmed instructions to obtain the requested information from the endpoint and generate a response in a format that the requesting API can understand. In some arrangements, the response generator 211 may format the response in a format that the requesting API requested”); and
send, responsive to the request, a response to the service comprising the data translated into the first schema (see e.g. Warmack, paragraph 60: “Once the response generator 211 generates the response, the response generator 211 may transmit the response to the requesting API”).
With respect to claim 27, Warmack as modified teaches: The system of claim 22, wherein the one or more processors further:
identify an information from a header of the request of the service (see e.g. Warmack, paragraph 58: “identify the format of the API requests from their headers”); and
identify, based on the information from the header, the endpoint configuration to use for the request (see e.g. Warmack, paragraph 58: “identify the format of the API requests from their headers… comparing the identified format of the API request to configuration files stored in the API conversion platform 126. If the file identifier 208 can identify a configuration file corresponding to the format of an API request, the file identifier 208 may apply the API request to the corresponding configuration file”).
With respect to claim 29, Warmack as modified teaches: The system of claim 22, wherein the one or more processors further:
identify a query set for the domain (see e.g. Warmack, paragraph 68: “parameter identifier 314 may identify parameters from the query string”); and
generate the second request based on the endpoint configuration (see e.g. Warmack, paragraph 75: “generate a new request with a data structure that the API of the endpoint may handle”), … and the query set (see e.g. Warmack, paragraph 70: “new API request will require paging. This indication can be placed in the body, the header, the query string, or any other part of the new request”).
However, Kabra teaches:
identify the object map for the domain, wherein the object map correlates the data between the first schema and the second schema (see e.g. Kabra, paragraph 77: “mapping the data source. The mapping can include identifying how tables and/or columns within the data source are linked”; and paragraph 3: “mapping each data schema to a common domain schema”);
the object map (see e.g. Kabra, paragraph 77: “mapping the data source. The mapping can include identifying how tables and/or columns within the data source are linked”; and paragraph 3: “mapping each data schema to a common domain schema”),
Warmack and Kabra are analogous art because they are in the same field of endeavor: mapping a target data model to a common data model. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Warmack with the teachings of Kabra. The motivation/suggestion would be to increase compatibility with different domains (see e.g. Kabra, paragraphs 3-4); thus improving the overall robustness of the system.
With respect to claim 30, Warmack as modified teaches: The system of claim 29, wherein the one or more processors further:
forward the second request to a data application programming interface (see e.g. Warmack, paragraph 52: “generate new API requests 212a-212n in a common (same) format”; and Fig. 2); and
retrieve the data from the data application programming interface according to the second request (see e.g. Warmack, paragraph 60: “Once the response generator 211 generates the response, the response generator 211 may transmit the response to the requesting API”).
With respect to claims 33, 34, 37, and 38: Claims 33, 34, 37, and 38 are directed to a method corresponding to the active functions implemented by the system disclosed in claims 22, 23, 26, and 27, respectively; please see the rejections directed to claims 22, 23, 26, and 27 above which also cover the limitations recited in claims 33, 34, 37, and 38.
With respect to claims 40 and 41: Claims 40 and 41 are directed to a non-transitory computer-readable media comprising instructions to cause a processor to implement active functions corresponding to the active functions implemented by the system disclosed in claims 22 and 23, respectively; please see the rejections directed to claims 22 and 23 above which also cover the limitations recited in claims 40 and 41. Note that, Warmack also discloses a computer-readable storage medium storing program instructions to implement active functions corresponding to the active functions implemented by the system disclosed in claims 22 and 23 (see e.g. Warmack, paragraphs 143-145).
Claims 24 and 35 are rejected under 35 U.S.C. 103 as being unpatentable over Warmack in view of Kabra as applied to claims 23 ad 34 above, and further in view of Flaxer et al. (US 2004/0162741 A1; from IDS filed on 08/30/2024; hereinafter “Flaxer”).
With respect to claim 24, Warmack as modified teaches: The system of claim 23, wherein the data is included in one or more data sets (see e.g. Warmack, paragraph 52: “API requests 204a-204n to obtain information from a system 214 (e.g., a server providing and maintaining webpages)”)… and wherein the one or more processors further generate the endpoint configuration from an application programming interface description of the first schema (see e.g. Warmack, paragraph 59: “The configuration file 209 may include programmed instructions and represent an example configuration file that can receive API requests in one format and generate arrays requesting the same parameters as the API requests but in a new format that the API of the system 214 may read. The configuration file 209 may generate the arrays in the new format by identifying the requested parameters in the original API request”; paragraph 88: “request parser 312 of the configuration file 310a may parse the API request that was applied to the configuration file 310a to identify a first one or more parameters in a first format. The request parser 312 may parse through the API request and identify each parameter that is being requested in the request”; and paragraph 89: “For example, a configuration file that is specific to requests that are received in the YAML format may be configured with a base key identifying how the JSON parameters would be formatted if they were formatted correctly in the request. The request parser 312 may compare the words and/or phrases of the API request to this format and identify any words or phrases that follow the same format”)
Warmack does not but Flaxer teaches:
organized into a set of domains (see e.g. Flaxer, paragraph 82: “hierarchy of functional domains in the system… In each domain, there is a service ontology 120 and a set of service composition schemas 130 that model business processes (i.e. composite services) in the domain”))
that is published by the domain (see e.g. Flaxer, paragraph 298: “For each service supported by a service provider 1820, the provider publishes a service composition schema”).
Warmack and Flaxer are analogous art because they are in the same field of endeavor: managing data access for multiple data access requesting systems from various service providers over a network. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Warmack with the teachings of Flaxer. The motivation/suggestion would be to improve the network management by implementing a better network organization.
With respect to claim 35: Claim 35 is directed to a method corresponding to the active functions implemented by the system disclosed in claim 24; please see the rejection directed to claim 24 above which also covers the limitations recited in claim 35.
Claims 28 and 39 are rejected under 35 U.S.C. 103 as being unpatentable over Warmack in view of Kabra as applied to claims 27 and 38 above, and further in view of Bucchi et al. (US 2019/0196890 A1; from IDS filed on 08/30/2024; hereinafter “Bucchi”).
With respect to claim 28, Warmack as modified teaches: The system of claim 27, wherein the endpoint configuration is identified based on a function (see e.g. Warmack, paragraph 58: “comparing the identified format of the API request to configuration files… identify a configuration file corresponding to the format of an API request”) that matches the information of the header (see e.g. Warmack, paragraph 58: “identify the format of the API requests from their headers… comparing the identified format of the API request to configuration files stored in the API conversion platform 126. If the file identifier 208 can identify a configuration file corresponding to the format of an API request, the file identifier 208 may apply the API request to the corresponding configuration file”)
Warmack does not but Bucchi teaches:
with an OpenAPI document (see e.g. Bucchi, paragraph 243: “For mapping between a GraphQL data model and RESTful APIs, such as specified in API specifications RAML/OpenAPI data model, formalization of API specifications may be used”).
Warmack and Bucchi are analogous art because they are in the same field of endeavor: managing data access for multiple data access requesting systems from various service providers over a network. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Warmack with the teachings of Bucchi. The motivation/suggestion would be to provide extension mechanisms for software developers (see e.g. Bucchi, paragraph 163); thus, improving the overall software development efficiency.
With respect to claim 39: Claim 39 is directed to a method corresponding to the active functions implemented by the system disclosed in claim 28; please see the rejection directed to claim 28 above which also covers the limitations recited in claim 39.
Claim 31 is rejected under 35 U.S.C. 103 as being unpatentable over Warmack in view of Kabra as applied to claim 22 above, and further in view of Peterkofsky et al. (US 2021/0073006 A1; from IDS filed on 08/30/2024; hereinafter “Peterkofsky”).
With respect to claim 31, Warmack as modified teaches: The system of claim 22, wherein the one or more processors further:
identify an application programming interface description published by the domain describing the first schema (see e.g. Warmack, paragraph 59: “The configuration file 209 may include programmed instructions and represent an example configuration file that can receive API requests in one format and generate arrays requesting the same parameters as the API requests but in a new format that the API of the system 214 may read. The configuration file 209 may generate the arrays in the new format by identifying the requested parameters in the original API request”; paragraph 88: “request parser 312 of the configuration file 310a may parse the API request that was applied to the configuration file 310a to identify a first one or more parameters in a first format. The request parser 312 may parse through the API request and identify each parameter that is being requested in the request”; and paragraph 89: “For example, a configuration file that is specific to requests that are received in the YAML format may be configured with a base key identifying how the JSON parameters would be formatted if they were formatted correctly in the request. The request parser 312 may compare the words and/or phrases of the API request to this format and identify any words or phrases that follow the same format”); and
Warmack does not but Peterkofsky teaches:
generate a controller instance (see e.g. Peterkofsky, Fig. 1C: “Control Plane 330”) for the domain from a controller template (see e.g. Peterkofsky, Fig. 1C: “Instance Template 364”)) and the application programming interface description (see e.g. Peterkofsky, paragraph 24: “generating the executable script, of the control plane 330… the consumer API 390 may present alternative consumer-selectable parameters 362 and/or instance templates 364 for inclusion in the script of the control plane 330”).
Warmack and Peterkofsky are analogous art because they are in the same field of endeavor: managing data access for multiple data access requesting systems from various service providers over a network. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Warmack with the teachings of Peterkofsky. The motivation/suggestion would be to improve networking management.
Claim 32 is rejected under 35 U.S.C. 103 as being unpatentable over Warmack in view of Kabra and Peterkofsky as applied to claim 31 above, and further in view of Bucchi.
With respect to claim 32, Warmack as modified teaches: The system of claim 31,
Warmack does not but Bucchi teaches:
wherein the application programming interface description corresponds to an OpenAPI document that specifies one or more data sets that are available in the domain and one or more RESTful operations to be called on the one or more data sets (see e.g. Bucchi, paragraph 243: “For mapping between a GraphQL data model and RESTful APIs, such as specified in API specifications RAML/OpenAPI data model, formalization of API specifications may be used”).
Warmack and Bucchi are analogous art because they are in the same field of endeavor: managing data access for multiple data access requesting systems from various service providers over a network. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Warmack with the teachings of Bucchi. The motivation/suggestion would be to provide extension mechanisms for software developers (see e.g. Bucchi, paragraph 163); thus, improving the overall software development efficiency.
Allowable Subject Matter
Claims 25 and 36 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, and the double patenting rejection(s) set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
The prior art references do not explicitly disclose decorating and translating features, in combination with the other limitations recited in claims 22 and 33, as recited in claims 25 and 36.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Vaschillo et al. (US 2005/0050068 A1) discloses a mapping system that enables data models to perform CRUD operations in their domain using their respective query languages or APIs, which are transformed to operations in a relational domain using a corresponding query language (e.g., SQL) (see paragraph 37).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
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, Kevin L Young can be reached at (571) 270-3180. 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.
/UMUT ONAT/Primary Examiner, Art Unit 2194
Prosecution Insights