DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. 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 Amendment
2. This Office Action is responsive to the Applicant’s amendment filed on May 28, 2025.
3. Claims 1-2, 4-6, 8-11,13-17 and 19-20 are pending, of which claims 1, 10, and 16 are in independent form.
4. claims 1, 9-10, and 16 are amended.5. Claims 3, 7, 12, and 18 are cancelled by the applicant.
Response to Arguments
6. Applicant's arguments filed on May 28, 2025 have been fully considered but they are not persuasive.
7. Argument 1: Applicant argue: “Kramer does not teach or suggest ‘receiving, via a user interface of a federation management service, one or more user inputs selecting a plurality of data sources as inputs for generating a federated application programming interface (API),’”
Response: Examiner has carefully considered the argument and respectfully disagrees with the argument. Applicant contends that Kramer does not teach or suggest “receiving, via a user interface of a federation management service, one or more user inputs selecting a plurality of data sources as inputs for generating a federated application programming interface (API).” The Examiner respectfully disagrees.
Kramer explicitly describes a user interface through which a user provides commands and interacts with data for federated search operations. Specifically, Kramer discloses that (Kramer [col. 6, lines 9-13] e.g., “client computer 100 may comprise a user interface, such as a graphical user interface, through which a user may enter commands and/or interact with data. The user may send, through client computer 100 and/or the user interface, a search query to federated search computer 102” (emphasis added).
Furthermore, Kramer explains that a “particular search application programming interface (API) may be used to execute the search query across a plurality of heterogeneous data sources 104A–Z” (Kramer,[col. 6, lines 24-34]) and that “the particular search API may transform the search query into a format that is compatible with one or more data sources”.
Taken together, these disclosures demonstrate that Kramer’s system receives user input (via a user interface) that determines or selects the data sources to be queried by the federated API, and that the federated search computer uses this information to generate and execute a federated API operation across multiple data sources. Thus, Kramer reasonably teaches or suggests the limitation of “receiving, via a user interface of a federation management service, one or more user inputs selecting a plurality of data sources as inputs for generating a federated API,” as claimed.
8. Argument 2: “Fox does not teach or suggest ‘processing the annotations to generate at least one target query in a database declarative language that maps to an element of the API schema,’”
Response: Examiner has carefully considered the argument and respectfully disagrees with the argument. Contrary to the applicant’s argument, Fox explicitly teaches processing semantic mappings to generate queries corresponding to database structures. Fox states that “ontology model 140 preferably encapsulates substantially all of the constructs from schemas 110, 120 and 130, including… database tables and their fields and their interrelationships… as well as business rules that relate table fields to one another and XML elements to one another” (Fox, [col. 4, lines 37–43). Fox further explains that queries formulated by the user in a common business language are converted into executable queries: “A user of the portal formulates queries and generates views using the common business language, which are automatically converted to appropriate information integrator 450 names and executed within information integrator 450” (Fox, [col. 6, lines 1–12]). These teachings disclose processing annotations (semantic mappings) to generate at least one target query that corresponds to elements of the underlying database schemas, satisfying the claimed limitation.
9. Argument 3: “Fox does not teach or suggest ‘the annotations include a first annotation that maps a type to a table of the database and a second annotation that maps a field of the type to a column of the table of the database,’ much less ‘wherein the query is associated with the type,’”
Response: Examiner has carefully considered the argument and respectfully disagrees with the argument. Contrary to the applicant’s argument, Fox explicitly teaches the claimed mapping of types to tables and fields to columns. Fox states that “ontology model 140 preferably encapsulates substantially all of the constructs from schemas 110, 120 and 130, including… database tables and their fields and their interrelationships” (Fox, [col. 4, lines 37–43]). Fox further teaches that “semantic mappings 480 obviate the need for the user to learn the intricacies of the data naming conventions for the individual data sources 420 and the inter-dependencies among their data” (Fox, [col. 6, lines 16–19]), demonstrating that the ontology properties (types) are associated with the underlying tables and columns of the database. This explicitly teaches that annotations (semantic mappings) include mappings of types to tables and fields to columns, satisfying the claimed limitation and associating queries with the corresponding types.
Claim Rejections - 35 USC § 103
10. 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.
11. 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.
12. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
13. Claims 1-2, 4-11,13-17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kramer et al. US 10,545,982 B1 (hereinafter Kramer) in view of Fox et al. US 8,412,746 B2 (hereinafter Fox).
Regarding claim 1, Kramer discloses a method for data processing, comprising: receiving, via a user interface of a federation management service, a user input selecting a plurality of data sources as inputs for generating a federated application programming interface (API) Kramer [col. 6, lines 9-13] e.g., “client computer 100 may comprise a user interface, such as a graphical user interface, through which a user may enter commands and/or interact with data. The user may send, through client computer 100 and/or the user interface, a search query to federated search computer 102” (emphasis added), see also [col. 6, lines 9-13] e.g., “client computer 100 may comprise a user interface, such as a graphical user interface, through which a user may enter commands and/or interact with data. The user may send, through client computer 100 and/or the user interface, a search query to federated search computer 102” (emphasis added). See also [col. 6, lines 24-34]) and that “the particular search API may transform the search query into a format that is compatible with one or more data sources”. Taken together, these disclosures demonstrate that Kramer’s system receives user input (via a user interface) that determines or selects the data sources to be queried by the federated API, and that the federated search computer uses this information to generate and execute a federated API operation across multiple data sources.); [and wherein the annotations include a first annotation that maps a type to a table of the database and a second annotation that maps a field of the type to a column of the table of the database;] receiving, at the federated API, an API request corresponding to the element of the one or more elements (Kramer [col. 6, lines 24-27] e.g., “A particular search application programming interface (API) may be used to execute the search query across a plurality of heterogeneous data sources 104A-Z (e.g., multiple data sources with different data models)”); returning, in response to the API request, a response that includes the feature of the database (Kramer [col. 6, lines 53-57] e.g., “A particular search application programming interface (API) may be used to execute the search query across a plurality of heterogeneous data sources 104A-Z (e.g., multiple data sources with different data models)”, see also [col. 6, lines 61-65] e.g., “Federated search computer 102 may execute the search query across the plurality of heterogeneous data sources 104A-Z. A particular data source API may be used to execute the search query across the plurality of heterogeneous data sources 104A-Z”).
Kramer discuss but does not explicitly disclose wherein a data source of the plurality of data sources is a database that is associated with a API schema that includes annotations that map one or more elements of the API schema to features of the database; and wherein the annotations include a first annotation that maps a type to a table of the database and a second annotation that maps a field of the type to a column of the table of the database; generating the federated API from the plurality of data sources, wherein the federated API includes the one or more elements of the API schema; processing the annotations to generate at least one target query that maps to an element of the API schema, wherein the at least one target query is included in a federated API schema of the federated API; generating, using the at least one target query included in the federated API schema that maps to the element of the API schema to fetch a feature of the database corresponding to the element of the one or more elements, the correspondence in accordance with an annotation of the annotations included in the API schema, a query for the feature of the database. Fox discloses wherein a data source of the plurality of data sources is a database that is associated with a API schema that includes annotations that map one or more elements of the API schema to features of the database (Fox [col. 4, lines 37-43] e.g., “Ontology model 140 preferably encapsulates substantially all of the constructs from schemas 110, 120 and 130, including inter alia database tables and their fields and their interrelationships through foreign keys, and XML complex types and their elements and the type inter-relationships, as well as business rules that relate table fields to one another and XML elements to one another”); and wherein the annotations include a first annotation that maps a type to a table of the database and a second annotation that maps a field of the type to a column of the table of the database (Fox states that “ontology model 140 preferably encapsulates substantially all of the constructs from schemas 110, 120 and 130, including… database tables and their fields and their interrelationships” (Fox, [col. 4, lines 37–43]). Fox further teaches that “semantic mappings 480 obviate the need for the user to learn the intricacies of the data naming conventions for the individual data sources 420 and the inter-dependencies among their data” (Fox, [col. 6, lines 16–19]), demonstrating that the ontology properties (types) are associated with the underlying tables and columns of the database. This explicitly teaches that annotations (semantic mappings) include mappings of types to tables and fields to columns); generating the federated API from the plurality of data sources, wherein the federated API includes the one or more elements of the API schema (Fox [col. 3, lines 12-20] e.g., “Generating a federated schema that describes structures of the plurality of inter-related data sources and inter-relationships of the plurality of inter-related data sources”. The federated schema functions as the API schema, integrating multiple sources under a common model); processing the annotations to generate at least one target query in a database declarative language that maps to an element of the API schema to the table of the database, wherein the at least one target query is included in a federated API schema of the federated API (Fox [col. 4, lines 14-20] e.g., "In a preferred embodiment of the present invention, semantics are provided to enterprise data through (i) a common ontology model, referred to also as an information model; and (ii) mappings of enterprise asset metadata into the ontology model.". The ontology mappings serve as annotations that connect API schema elements to database features); generating, using the at least one target query included in the federated API schema that maps to the element of the API schema to fetch a feature of the database corresponding to the element of the one or more elements (Fox [col.5, lines 42-45] e.g., “Query engine 360 generates and processes queries expressed generically in terms of ontology model 140 and, using the translation layer provided by federated schema 150, activates federated database 350 to query across the three databases”. The federated API schema serves as the translation layer, mapping API elements to database structures), the correspondence in accordance with an annotation of the annotations included in the API schema, a query for the feature of the database (Fox [col.5, lines 42-45] e.g., “After ontology model 140 is generated, an ontology-to-schema generator 220 creates federated schema 150. Preferably, ontology-to-schema generator 220 creates relational database tables and fields, or XML complex types and elements, which correspond respectively to the classes of ontology model 140 and their properties”. These annotations ensure that API schema elements correctly correspond to database queries); and It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include method and system for federated querying of data sources, taught by Fox, in federated search of multiple sources with conflict resolution taught by Kramer, as it yields the predictable results for generating a federated schema that describes the structures of the plurality of data sources and their inter-relationships, and for modifying the federated schema over time as the plurality of data sources undergo changes, and a query generator communicating with the schema generator, for generating a query for the federated schema (Fox [col. 3, lines 5-10]).
Regarding claim 2, the rejection of claim 1 hereby incorporated by reference, Kramer and Fox discloses a method, wherein generating the federated API comprises: generating the federated API that includes one or more API elements from a data source API of the plurality of data sources and the element of the one or more elements of the API schema that is mapped to a database query for the database (Fox [col. 4, lines 47-51] e.g., “Ontology model 140 can be inverted, and used to map ontology model 140 into a single federated schema 150. Federated schema 150 effectively combines the three individual schemas 110, 120, and 130” The federated API schema inherits common semantics from the ontology model and enables API queries to interact with multiple databases seamlessly).
3. (Canceled)
Regarding claim 4, the rejection of claim 1 hereby incorporated by reference, Kramer and Fox discloses a method, further comprising: transmitting, to an API gateway, an indication of the federated API schema that includes the at least one target query (Kramer [col. 6, lines 24-27] e.g., "A particular search API may be used to execute the search query across a plurality of heterogeneous data sources 104A-Z (e.g., multiple data sources with different data models)." The search API acts as a federated API gateway, transmitting queries and processing responses.).
Regarding claim 5, the rejection of claim 1 hereby incorporated by reference, Kramer and Fox discloses a method, wherein the annotations include the annotation that maps the element of the one or more elements to a first table and a second table of the database (Fox [col. 4, lines 37-40] e.g., “Ontology model 140 preferably encapsulates substantially all of the constructs from schemas 110, 120, and 130, including inter alia database tables and their fields and their inter-relationships through foreign keys”). .
Regarding claim 6, the rejection of claim 5 hereby incorporated by reference, Kramer and Fox discloses a method, wherein the annotation comprises a join command that specifies the first table and the second table (Fox [col. 6, lines 33-37] e.g., “The property SumsUnderManagement is determined by summing the properties branch.savingAccounts.balance and branch.checkingAccounts.balance”).
Regarding claim 7, the rejection of claim 1 hereby incorporated by reference, Kramer and Fox discloses a method, wherein the annotations include a first annotation that maps a type to a table of the database and a second annotation that maps a field of the type to a column of the table of the database (Fox [col. 4, lines 37-43] e.g., “Ontology model 140 preferably encapsulates substantially all of the constructs from schemas 110, 120 and 130, including inter alia database tables and their fields and their interrelationships through foreign keys, and XML complex types and their elements and the type inter-relationships, as well as business rules that relate table fields to one another and XML elements to one another”).
Regarding claim 8, the rejection of claim 1 hereby incorporated by reference, Kramer and Fox discloses a method, further comprising: determining an absence of the annotation for the element of the API schema that maps the element to the feature of the database (Fox [col. 4, lines 22-25] e.g., “Mappings of asset metadata into the ontology model serve as dictionaries through which constructs of the asset metadata can be semantically understood”. This explains that when an API schema element is mapped to a database feature, it gains semantic meaning through an ontology model. If an annotation (or mapping) is absent, the API schema element lacks a clear reference to its corresponding database feature); and generating, based at least in part on determining the absence, the federated API that includes a mapping of the element to a table with a table name corresponding to an element name of the element (Fox [col. 5, lines 10-14] e.g., “Ontology-to-schema generator 220 creates relational database tables and fields, or XML complex types and elements, which correspond respectively to the classes of ontology model 140 and their properties”).
Regarding claim 9, the rejection of claim 1 hereby incorporated by reference, Kramer and Fox discloses a method, wherein receiving the one or more user input comprises: receiving the one or more user input that select the API schema that includes the annotations, wherein the federated API is generated based at least in part on receiving the one or more user input (Fox [col. 5, lines 59-61] e.g., “Design environment 450 provides a user workflow for generating an ontology model 460 and for mapping one or more data schemas 470 into ontology model 460 using semantic mappings 480”).
Regarding claim 10, Kramer discloses an apparatus for data processing, comprising: a processor (Kramer [Figure 11, element 1104] e.g., “PROCESSOR”); memory coupled with the processor (Figure 11, element 1106] e.g., “MAIN MEMORY”); and instructions stored in the memory and executable by the processor (Kramer [col. 25, lines 39-42] e.g., “Main memory 1106 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 1104.”) to cause the apparatus to: receive, via a user interface of a federation management service, one or more user inputs selecting a plurality of data sources as inputs for generating a federated application programming interface (API) (Kramer [col. 6, lines 9-13] e.g., “Client computer 100 may comprise a user interface, such as a graphical user interface, through which a user may enter commands and/or interact with data. The user may send, through client computer 100 and/or the user interface, a search query to federated search computer 102”, see also [col. 3, lines 59-63] e.g., “receiving a selection by a user of a graph comprising a plurality of graph nodes connected by one or more graph edges. A graph node may represent a data object type or a data object property that is described in at least one data ontology of the set of data ontologies”. This describes that a user input is received via a UI to specify multiple data sources, which are then used in a federated API query), [wherein a data source of the plurality of data sources is a database that is associated with a API schema that includes annotations that map one or more elements of the API schema to features of the database;] [and wherein the annotation include a first annotation that maps a type to a table of the database and a second annotation that maps a field of the type to a column of the table of the database;] receive, at the federated API, an API request corresponding to the element of the one or more elements (Kramer [col. 6, lines 24-27] e.g., “A particular search application programming interface (API) may be used to execute the search query across a plurality of heterogeneous data sources 104A-Z (e.g., multiple data sources with different data models)” “The user may send, through client computer 100 and/or the user interface, a search query to federated search computer 102.”); and return, in response to the API request, a response that includes the feature of the database (Kramer [col. 6, lines 53-57] e.g., “A particular search application programming interface (API) may be used to execute the search query across a plurality of heterogeneous data sources 104A-Z (e.g., multiple data sources with different data models)”, see also [col. 6, lines 61-65] e.g., “Federated search computer 102 may execute the search query across the plurality of heterogeneous data sources 104A-Z. A particular data source API may be used to execute the search query across the plurality of heterogeneous data sources 104A-Z”)..
Kramer discuss but does not explicitly disclose wherein a data source of the plurality of data sources is a database that is associated with a API schema that includes annotations that map one or more elements of the API schema to features of the database; and wherein the annotations include a first annotation that maps a type to a table of the database and a second annotation that maps a field of the type to a column of the table of the database; generate the federated API from the plurality of data sources, wherein the federated API includes the one or more elements of the API schema; process the annotations to generate at least one target query that maps to an element of the API schema, wherein the at least one target query is included in a federated API schema of the federated API; generate, using the at least one target query included in the federated API schema that maps to the element of the API schema to fetch a feature of the database corresponding to the element of the one or more elements, the correspondence in accordance with an annotation of the annotations included in the API schema, a query for the feature of the database. Fox discloses wherein a data source of the plurality of data sources is a database that is associated with a API schema that includes annotations that map one or more elements of the API schema to features of the database (Fox [col. 4, lines 37-43] e.g., “Ontology model 140 preferably encapsulates substantially all of the constructs from schemas 110, 120 and 130, including inter alia database tables and their fields and their interrelationships through foreign keys, and XML complex types and their elements and the type inter-relationships, as well as business rules that relate table fields to one another and XML elements to one another”); and wherein the annotations include a first annotation that maps a type to a table of the database and a second annotation that maps a field of the type to a column of the table of the database (Fox states that “ontology model 140 preferably encapsulates substantially all of the constructs from schemas 110, 120 and 130, including… database tables and their fields and their interrelationships” (Fox, [col. 4, lines 37–43]). Fox further teaches that “semantic mappings 480 obviate the need for the user to learn the intricacies of the data naming conventions for the individual data sources 420 and the inter-dependencies among their data” (Fox, [col. 6, lines 16–19]), demonstrating that the ontology properties (types) are associated with the underlying tables and columns of the database. This explicitly teaches that annotations (semantic mappings) include mappings of types to tables and fields to columns); generate the federated API from the plurality of data sources, wherein the federated API includes the one or more elements of the API schema (Fox [col. 3, lines 12-20] e.g., “Generating a federated schema that describes structures of the plurality of inter-related data sources and inter-relationships of the plurality of inter-related data sources”. The federated schema functions as the API schema, integrating multiple sources under a common model); process the annotations to generate at least one target query that maps to an element of the API schema, wherein the at least one target query is included in a federated API schema of the federated API (Fox [col. 4, lines 14-20] e.g., "In a preferred embodiment of the present invention, semantics are provided to enterprise data through (i) a common ontology model, referred to also as an information model; and (ii) mappings of enterprise asset metadata into the ontology model.". The ontology mappings serve as annotations that connect API schema elements to database features); generate, using the at least one target query included in the federated API schema that maps to the element of the API schema to fetch a feature of the database corresponding to the element of the one or more elements (Fox [col.5, lines 42-45] e.g., “Query engine 360 generates and processes queries expressed generically in terms of ontology model 140 and, using the translation layer provided by federated schema 150, activates federated database 350 to query across the three databases”. The federated API schema serves as the translation layer, mapping API elements to database structures), the correspondence in accordance with an annotation of the annotations included in the API schema, a query for the feature of the database (Fox [col.5, lines 42-45] e.g., “After ontology model 140 is generated, an ontology-to-schema generator 220 creates federated schema 150. Preferably, ontology-to-schema generator 220 creates relational database tables and fields, or XML complex types and elements, which correspond respectively to the classes of ontology model 140 and their properties”. These annotations ensure that API schema elements correctly correspond to database queries); and It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include method and system for federated querying of data sources, taught by Fox, in federated search of multiple sources with conflict resolution taught by Kramer, as it yields the predictable results for generating a federated schema that describes the structures of the plurality of data sources and their inter-relationships, and for modifying the federated schema over time as the plurality of data sources undergo changes, and a query generator communicating with the schema generator, for generating a query for the federated schema (Fox [col. 3, lines 5-10]).
Regarding claim 11, the rejection of claim 10 hereby incorporated by reference, Kramer and Fox discloses an apparatus, wherein the instructions to generate the federated API are executable by the processor to cause the apparatus to: generate the federated API that includes one or more API elements from a data source API of the plurality of data sources and the element of the one or more elements of the API schema that is mapped to a database query for the database (Fox [col. 4, lines 47-51] e.g., “Ontology model 140 can be inverted, and used to map ontology model 140 into a single federated schema 150. Federated schema 150 effectively combines the three individual schemas 110, 120, and 130” The federated API schema inherits common semantics from the ontology model and enables API queries to interact with multiple databases seamlessly).
12. (Canceled)
Regarding claim 13, the rejection of claim 10 hereby incorporated by reference, Kramer and Fox discloses an apparatus, wherein the instructions are further executable by the processor to cause the apparatus to: transmit, to an API gateway, an indication of the federated API schema that includes the at least one target query (Kramer [col. 6, lines 24-27] e.g., "A particular search API may be used to execute the search query across a plurality of heterogeneous data sources 104A-Z (e.g., multiple data sources with different data models)." The search API acts as a federated API gateway, transmitting queries and processing responses.).
Regarding claim 14, the rejection of claim 10 hereby incorporated by reference, Kramer and Fox discloses an apparatus, wherein the annotations include the annotation that maps the element of the one or more elements to a first table and a second table of the database (Fox [col. 4, lines 37-40] e.g., “Ontology model 140 preferably encapsulates substantially all of the constructs from schemas 110, 120, and 130, including inter alia database tables and their fields and their inter-relationships through foreign keys”).
Regarding claim 15, the rejection of claim 14 hereby incorporated by reference, Kramer and Fox discloses an apparatus, wherein the annotation comprises a join command that specifies the first table and the second table (Fox [col. 6, lines 33-37] e.g., “The property SumsUnderManagement is determined by summing the properties branch.savingAccounts.balance and branch.checkingAccounts.balance”).
Regarding claim 16, Kramer discloses a non-transitory computer-readable medium storing code for data processing, the code comprising instructions executable by a processor (Kramer [col. 24, lines 63-65] e.g., “Such instructions, when stored in non-transitory storage media accessible to processor 1104”) to: receive, via a user interface of a federation management service, one or more user input selecting a plurality of data sources as inputs for generating a federated application programming interface (API) (Kramer [col. 6, lines 9-13] e.g., “Client computer 100 may comprise a user interface, such as a graphical user interface, through which a user may enter commands and/or interact with data. The user may send, through client computer 100 and/or the user interface, a search query to federated search computer 102”, see also [col. 3, lines 59-63] e.g., “receiving a selection by a user of a graph comprising a plurality of graph nodes connected by one or more graph edges. A graph node may represent a data object type or a data object property that is described in at least one data ontology of the set of data ontologies”. This describes that a user input is received via a UI to specify multiple data sources, which are then used in a federated API query), [wherein a data source of the plurality of data sources is a database that is associated with a API schema that includes annotations that map one or more elements of the API schema to features of the database;] and wherein the annotations include a first annotation that maps a type to a table of the database and a second annotation that maps a field of the type to a column of the table of the database;] receive, at the federated API, an API request corresponding to the element of the one or more elements (Kramer [col. 6, lines 24-27] e.g., “A particular search application programming interface (API) may be used to execute the search query across a plurality of heterogeneous data sources 104A-Z (e.g., multiple data sources with different data models)”); and return, in response to the API request, a response that includes the feature of the database (Kramer [col. 6, lines 53-57] e.g., “A particular search application programming interface (API) may be used to execute the search query across a plurality of heterogeneous data sources 104A-Z (e.g., multiple data sources with different data models)”, see also [col. 6, lines 61-65] e.g., “Federated search computer 102 may execute the search query across the plurality of heterogeneous data sources 104A-Z. A particular data source API may be used to execute the search query across the plurality of heterogeneous data sources 104A-Z”)..
Kramer discuss but does not explicitly disclose wherein a data source of the plurality of data sources is a database that is associated with a API schema that includes annotations that map one or more elements of the API schema to features of the database; and wherein the annotations include a first annotation that maps a type to a table of the database and a second annotation that maps a field of the type to a column of the table of the database; generate the federated API from the plurality of data sources, wherein the federated API includes the one or more elements of the API schema; process the annotations to generate at least one target query that maps to an element of the API schema, wherein the at least one target query is included in a federated API schema of the federated API; generate, using the at least one target query included in the federated API schema that maps to the element of the API schema to fetch a feature of the database corresponding to the element of the one or more elements, the correspondence in accordance with an annotation of the annotations included in the API schema, a query for the feature of the database. Fox discloses wherein a data source of the plurality of data sources is a database that is associated with a API schema that includes annotations that map one or more elements of the API schema to features of the database (Fox [col. 4, lines 37-43] e.g., “Ontology model 140 preferably encapsulates substantially all of the constructs from schemas 110, 120 and 130, including inter alia database tables and their fields and their interrelationships through foreign keys, and XML complex types and their elements and the type inter-relationships, as well as business rules that relate table fields to one another and XML elements to one another”); and wherein the annotations include a first annotation that maps a type to a table of the database and a second annotation that maps a field of the type to a column of the table of the database (Fox states that “ontology model 140 preferably encapsulates substantially all of the constructs from schemas 110, 120 and 130, including… database tables and their fields and their interrelationships” (Fox, [col. 4, lines 37–43]). Fox further teaches that “semantic mappings 480 obviate the need for the user to learn the intricacies of the data naming conventions for the individual data sources 420 and the inter-dependencies among their data” (Fox, [col. 6, lines 16–19]), demonstrating that the ontology properties (types) are associated with the underlying tables and columns of the database. This explicitly teaches that annotations (semantic mappings) include mappings of types to tables and fields to columns); generate the federated API from the plurality of data sources, wherein the federated API includes the one or more elements of the API schema (Fox [col. 3, lines 12-20] e.g., “Generating a federated schema that describes structures of the plurality of inter-related data sources and inter-relationships of the plurality of inter-related data sources”. The federated schema functions as the API schema, integrating multiple sources under a common model); process the annotations to generate at least one target query that maps to an element of the API schema, wherein the at least one target query is included in a federated API schema of the federated API (Fox [col. 4, lines 14-20] e.g., "In a preferred embodiment of the present invention, semantics are provided to enterprise data through (i) a common ontology model, referred to also as an information model; and (ii) mappings of enterprise asset metadata into the ontology model.". The ontology mappings serve as annotations that connect API schema elements to database features); generate, using the at least one target query included in the federated API schema that maps to the element of the API schema to fetch a feature of the database corresponding to the element of the one or more elements (Fox [col.5, lines 42-45] e.g., “Query engine 360 generates and processes queries expressed generically in terms of ontology model 140 and, using the translation layer provided by federated schema 150, activates federated database 350 to query across the three databases”. The federated API schema serves as the translation layer, mapping API elements to database structures), the correspondence in accordance with an annotation of the annotations included in the API schema, a query for the feature of the database (Fox [col.5, lines 42-45] e.g., “After ontology model 140 is generated, an ontology-to-schema generator 220 creates federated schema 150. Preferably, ontology-to-schema generator 220 creates relational database tables and fields, or XML complex types and elements, which correspond respectively to the classes of ontology model 140 and their properties”. These annotations ensure that API schema elements correctly correspond to database queries); and It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include method and system for federated querying of data sources, taught by Fox, in federated search of multiple sources with conflict resolution taught by Kramer, as it yields the predictable results for generating a federated schema that describes the structures of the plurality of data sources and their inter-relationships, and for modifying the federated schema over time as the plurality of data sources undergo changes, and a query generator communicating with the schema generator, for generating a query for the federated schema (Fox [col. 3, lines 5-10]).
Regarding claim 17, the rejection of claim 16 hereby incorporated by reference, Kramer and Fox discloses a non-transitory computer-readable medium, wherein the instructions to generate the federated API are executable by the processor to: generate the federated API that includes one or more API elements from a data source API of the plurality of data sources and the element of the one or more elements of the API schema that is mapped to a database query for the database (Fox [col. 4, lines 47-51] e.g., “Ontology model 140 can be inverted, and used to map ontology model 140 into a single federated schema 150. Federated schema 150 effectively combines the three individual schemas 110, 120, and 130” The federated API schema inherits common semantics from the ontology model and enables API queries to interact with multiple databases seamlessly).
18. (Canceled)
Regarding claim 19, the rejection of claim 16 hereby incorporated by reference, Kramer and Fox discloses a non-transitory computer-readable medium, wherein the instructions are further executable by the processor to: transmit, to an API gateway, an indication of the federated API schema that includes the at least one target query (Kramer [col. 6, lines 24-27] e.g., "A particular search API may be used to execute the search query across a plurality of heterogeneous data sources 104A-Z (e.g., multiple data sources with different data models)." The search API acts as a federated API gateway, transmitting queries and processing responses.).
Regarding claim 20, the rejection of claim 16 hereby incorporated by reference, Kramer and Fox discloses a non-transitory computer-readable medium, wherein the annotations include the annotation that maps the element of the one or more elements to a first table and a second table of the database (Fox [col. 4, lines 37-40] e.g., “Ontology model 140 preferably encapsulates substantially all of the constructs from schemas 110, 120, and 130, including inter alia database tables and their fields and their inter-relationships through foreign keys”).
Conclusion
14. 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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. 15. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BERHANU MITIKU whose telephone number is (571)270-1983. The examiner can normally be reached Flex.
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, Ajay Bhatia can be reached at 571-272-3906. 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.
/BERHANU MITIKU/Examiner, Art Unit 2156
/AJAY M BHATIA/Supervisory Patent Examiner, Art Unit 2156