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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited 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.
Response to Amendment
The Amendment filed 9/15/2025 has been entered. Claims 1, 3-14, 16-18 and 20 remain pending in the present Office Action.
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 1, 3-6, 9-14, 16-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Zionts et al. (U.S. Pub. No. 2023/0359667), hereinafter Zionts, in view of Liensberger et al. (U.S. Pub. No. 2013/0282748), hereinafter Liensberger, and Apollo GraphQL Docs (NPL Document: “Unions and interfaces”).
Regarding claim 1, Zionts teaches a method for data processing, comprising:
[…] a plurality of data sources comprising one or more tags corresponding to one or more elements of the plurality of data sources ([0062] – “schemas may be defined for three subgraphs in a basic example e-commerce application. Individual subgraphs may be implemented as a separate GraphQL API”; [0094] – “@tag directives ( e.g., all of the @tag directives) specified in the subgraphs”; [0074]-[0075] – “schema element definitions, for example, may be filtered from a source graph schema based, at least in part, on a "@tag" directive that may be added to the source graph schema. […] For the current example, the @tag "internal" may signify that any schema elements marked with the @tag directive "internal" may be treated in some way in generating a particular subset representation of the source graph.” ; [0097] – “@tag directives may be supported for schema elements including, but not limited to, object types, object fields, interface types, interface fields and/or union types”. The recited “subgraphs” are analogous to the claimed “data sources”.);
generating a federated application programming interface (API) using the plurality of data sources via the federation management service, wherein the federated API includes elements of the plurality of data sources ([0050] – “a federated approach may be utilized to divide a graph implementation across multiple back-end services. An example architecture utilizing a federated approach may include, for example, a collection of subgraphs (e.g., usually represented by different back-end services) that may individually define particular GraphQL schema and/or a gateway that may utilize a supergraph schema (e.g., composed from subgraph schemas) to execute queries across multiple subgraphs.”; [0060] – “A supergraph schema may combine all of the types and/or fields from subgraph schemas plus some federation-specific directives that may instruct a gateway as to which subgraphs may be responsible for resolving particular fields, in implementations.”; [0090] – “As indicated at block 1010, a unified graph, such as a GraphQL supergraph, may be generated and/or otherwise obtained. As discussed previously, a supergraph may be composed from one or more subgraphs, for example.”; [0092] – “In implementations, a @tag directive may be added to particular schema elements of a supergraph, for example, to indicate whether to include or exclude the particular schema elements from subset representations of the supergraph.”; [0094] – “a supergraph schema generated from one or more subgraphs may retain the @tag directives ( e.g., all of the @tag directives) specified in the subgraphs.” The “supergraph”, or “unified graph”, is analogous to the claimed “federated API”.);
receiving, via the user interface of the federation management service (FIG. 11), a second user input selecting a set of tags of the one or more tags for inclusion or exclusion of corresponding elements in a subgraph of the federated API ([0099]-[0100] – “a subset representation may be generated, as indicated at block 1040. […] a user interface (e.g., command line interface, graphical user interface, etc.) may be provided on a computing device and/or the like to obtain such inputs from one or more users. As also indicated at block 1040, one or more filters may be specified. FIG. 11 depicts an example user interface 1100. For the example of FIG. 11, user interface 1100 may comprise a graphical user interface. […] In an implementation, "Excluded tags" and "Included tags" fields of user interface 1100 may comprise drop-down lists, although subject matter is not limited in scope in these respects. In an implementation, system 900, for example, may detect tag names (e.g., all tag names) that are used in the source supergraph schema (e.g., originating in one or more subgraphs) and/or may populate the dropdown lists with those names, as appropriate. User interface 1100 may also allow a user to specify one or more "excluded" tags and/or one or more "included" tags and/or to remove one or more tags.” The “subset representation”, described as a filtered subset of a supergraph or unified graph in [0070]-[0071], is analogous to the claimed “subgraph of the federated API”.);
determining that a first element of a first API of the plurality of data sources is dependent on a second element of a second API of the plurality of data sources that is associated with a first tag that is not selected for inclusion in the subgraph ([0064] – “A supergraph may include types and/or fields (e.g., all, most, etc. of the types and/or fields) defined by the subgraphs”; [0090] – “a supergraph may be composed from one or more subgraphs”; [0095] – “@tag directives (and/or other similar specified directives) may be applied to fields of types and/or may be applied to definitions of types […] whenever an type definition is tagged, fields that return that type may also be tagged”; [0096] – “if a subset representation excludes an object that implements an interface or is included in a union, then the subset representation may not exclude schema fields that return that interface or union, for example. However, if a subgraph resolves one of these fields by returning the excluded object, a runtime error may occur in the gateway and the operation may fail”; [0097] – “@tag directives may be supported for schema elements including, but not limited to, object types, object fields, interface types, interface fields and/or union types” [0098] – “for each schema element that may be marked @inaccessible: look at its tags and if any tags are excluded, then mark the element as @inaccessible. Also, if no tags are included and there's at least one included filter, then mark the element @inaccessible […] an "emptyUnionMasking" transform, if all of a union's members are @inaccessible, then mark the union @inaccessible.” A supergraph comprises schema elements of multiple different subgraphs (“a first API of the plurality of data sources” and “a second API of the plurality of data sources”). A union type schema element in the supergraph (a “first element” of a first API of the plurality of data sources) may have a member which is an object type schema element in the supergraph (a “second element” of a second API of the plurality of data sources) which has a tag (“a first tag”) that is excluded (“not selected for inclusion”) from a subset representation of the supergraph. When all object types included in the union type have been excluded (including the exemplary object type field, i.e., the second element), then the union type will be excluded as well. The determination that the union type field is dependent on the tagged and excluded member object type field(s) is implicitly taught in order to exclude the union from the subset representation. Additionally, since the supergraph is taught as comprising schema elements of multiple different subgraphs (multiples APIs of the plurality of data sources), it would have been obvious to one of ordinary skill in the art that a particular union type schema element could be defined in a first subgraph of the supergraph and one of the object type elements included in the union type could be defined in a second subgraph of the supergraph.), […];
generating the subgraph from the federated API based at least in part on the second user input, wherein the subgraph includes a subset of the one or more elements of the plurality of data sources corresponding to the set of tags selected for inclusion in the subgraph ([0101] – “system 900, for example, may filter schema elements from the source supergraph to generate one or more subset representations according to example rules. For example, for circumstances in which the "Included tags" list is empty, system 900, for example, may include each type and/or field in a subset representation unless it is tagged with an "excluded" tag. Also, in an implementation, for circumstances in which the "Included tags" list is not empty, system 900, for example, may exclude each schema element from the subset representation unless its tagged with an "included" tag.”), the subset excluding the first element based at least in part on determining that the first element is dependent on the second element associated with the first tag ([0093]-[0098] – schema fields, such as unions whose members have all been excluded/not selected for inclusion, are also excluded from the subset representation to avoid runtime errors or generating an invalid subset representation); and
deploying the subgraph of the federated API to a host environment ([0105] – “as indicated at block 1060, subsequent to completion of the various checks, the generated subset representation may be launched (e.g., intended audience may gain access to subset representation). As mentioned, subset representations may comprise documentation-type subset representations and/or may comprise deployed subset representations, in implementations.”).
Zionts fails to expressly teach receiving, via a user interface of a federation management service, a first user input indicating a plurality of data sources and wherein the first element is an operation and is dependent on the second element in accordance with the second element being an input into the operation.
However, Liensberger teaches receiving, via a user interface of a federation management service, a first user input indicating a plurality of data sources (FIG. 5; [0003] – “The API development system disclosed herein enables both casual API creators, such as information workers and entry-level developers, and professional software developers to take existing APIs that are exposed on the Internet or on any other network and compose them through a composition user interface. These composed APIs can then be exposed as a new API and shared with others.”; [0023] – “FIG. 2 is a block diagram of a composite API 201 that allows users to access multiple APIs according to another embodiment. API 201 allows users to access datasets 203 and 205 and one or more of datasets 204-206 using a single query. API 207 is used to access dataset 202, and API 208 is used to access dataset 203.”; [0052] – “FIG. 5 illustrates configuration data 501 that a developer and/or user may select for a composite API according to one embodiment. The developer and/or user may select one or more query fields in section 502. These query fields are supported by the composite application. The query fields may be unique to the composite API or may correspond to query fields supported by APIs that are embedded in the composite API.”; [0054] – “Section 503 allows the developer and/or user to select the datasets to be used with the composite APIs.”; [0055] – “In step 602, API creators combine two or more selected APIs into a composite API that allows users to access multiple datasets using a single query.”).
Zionts and Liensberger are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor of providing access to a plurality of data sources using a single federated API generated from multiple existing APIs. Zionts teaches a user interface through which user input can be obtained (Zionts: [0099]). Zionts further teaches a supergraph (analogous to a “federated API”) may be generated or otherwise obtained from one or more subgraphs (analogous to the “plurality of data sources”) to enable a user to access the services and/or content specified by the plurality of subgraphs using a single query (Zionts: [0066] and [0090]). Liensberger similarly teaches generating a composite API from one or more selected existing APIs that allows users to access the datasets backing the selected APIs using a single query (Liensberger: [0055]). Therefore, it would have been obvious one of ordinary skill in the art to have modified the teachings of Zionts to receive a user input, via the user interface, indicating a plurality of data sources from which a federated API is generated as taught by Liensberger. Doing so would provide a flexible and simple way to enable users with any level of experience to select the plurality of data sources they want to combine and access using a federated API (Liensberger: [0003], [0005], [0015], and [0027]).
The combination of Zionts in view of Liensberger fails to expressly teach wherein the first element is an operation and is dependent on the second element in accordance with the second element being an input into the operation.
However, Apollo GraphQL Docs teaches wherein the first element [a union type] is an operation and is dependent on the second element [object types included in the union] in accordance with the second element being an input into the operation (Page 1 – “Unions and interfaces are abstract GraphQL types that enable a schema field to return one of multiple object types. […] When you define a union type, you declare which object types are included in the union […] A field can have a union (or a list of that union) as its return type. In this case, it can return any object type that's included in the union”. The GraphQL union type schema element performs a unification operation which combines multiple distinct object types, i.e., its members, included in the union into a set and returns any of the object types as a result. Thus, these members or included object types can be considered “inputs” for the union operation.).
Apollo GraphQL Docs is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of determining dependencies between API elements. Zionts teaches excluding a union type schema element from a subset representation of a supergraph (“subgraph of a federated API”) based on its members, or object types included in the union, having tags that have been excluded from (“not selected for inclusion in”) the subset representation to avoid returning an excluded object (see Zionts: [0096]-[0098]). Apollo GraphQL Docs defines a GraphQL union type implicitly comprises a unification operation which combines the distinct object type members of the union into a set and returns any of the member object types included in the union (see Apollo GraphQL Docs: Pages 1-4). Thus, one of ordinary skill in the art would recognize that Zionts implicitly teaches the union type (“the first element”) is an operation and the members, i.e., included object types, of the union type (one of which may be “the second element”) are inputs to the union operation performed by the union type as evidenced by Apollo GraphQL Docs. One of ordinary skill in the art would have been motivated to interpret the teachings of Zionts in view of the teachings of Apollo GraphQL Docs since Zionts teaches the schema elements, including the union type elements, may be GraphQL schema elements (Zionts: [0037], [0062] and [0090]). In this manner, it would have been obvious to one of ordinary skill in the art to combine the teachings of Zionts in view of Liensberger and Apollo GraphQL Docs to achieve the invention as recited in claim 1.
Regarding claim 3, the combination of Zionts in view of Liensberger and Apollo GraphQL Docs teaches the method of claim 1. Zionts teaches the method further comprising:
detecting an update to one or more of the plurality of data sources (FIG. 9; [0085] – “independent backend service teams, such as a Users team, a Products team and/or an Inventor team, for example, may publish subgraph schema updates. For example, referring to example system 900, the Users team, the Products team and/or the Inventor team may update their respective subgraphs (e.g., Users subgraph 911, Products subgraph 912 and/or Inventor subgraph 913, respectively) and/or may store the updated subgraphs in a schema repository 910 […] In an implementation, the various backend service teams, including, for example, the Users team, the Products team and/or the Inventor team, may update their respective subgraph schemas to include tags that may be utilized to specify particular subset representations.”; [0086] – “As indicated at block 921, build and/or operation checks may be performed on the updated subgraphs”);
generating an update to the federated API based at least in part on the update to the one or more of the plurality of data sources ([0086] – “such checks may determine whether the subgraphs are composable into a supergraph and/or whether any particular operations performed by client computing devices in accessing a previous version of a supergraph, or a subset representation thereof, may be broken as a result of the updates to the various subgraphs”; [0087] – “subgraph schemas, such as Users subgraph 911, Products subgraph 912 and/or Inventor subgraph 913, may be composed together into a supergraph schema which may subsequently be utilized to power a gateway and/or router, as indicated at block 922. In an implementation, a composed supergraph may be stored in schema repository 910, for example.”); and
generating a second version of the subgraph of the federated API based at least in part on the update to the federated API ([0088] – “Additionally, in implementations, based at least in part on included tags and/or other specified directives, filters may be run on the unified supergraph schema to derive (e.g., automatically derive) the various filtered subsets (e.g., subset representations). For example, as indicated at block 923, one or more filters may be applied to the generated supergraph to yield one or more subset representations.”; [0084] – “a particular advantage of the example subset representation approaches discussed herein may be that subset representations may automatically remain up-to-date with very little or no additional manual work when combined with the federated approaches discussed herein.” [0100] – “a user may add tag names that are not yet present in the source supergraph schema. If tags with those names are later added (e.g., to one or more subgraphs), system 900 may remember the user-specified tag names and may honor them in generating subsequent subset representations”).
Regarding claim 4, the combination of Zionts in view of Liensberger and Apollo GraphQL Docs teaches the method of claim 1. Zionts further teaches wherein generating the subgraph comprises:
generating an API specification for the subgraph that exposes a third element corresponding to a second tag of the set of tags that is selected for inclusion in the subgraph (FIG. 5 and [0070] – each subset representation (analogous to a claimed “subgraph”) is a subset of the supergraph schema, making each subset representation a schema itself. [0101] – “system 900, for example, may filter schema elements from the source supergraph to generate one or more subset representations according to example rules. […] for circumstances in which the "Included tags" list is not empty, system 900, for example, may exclude each schema element from the subset representation unless its tagged with an "included" tag.”; [0105] – “Further, as indicated at block 1060, subsequent to completion of the various checks, the generated subset representation may be launched (e.g., intended audience may gain access to subset representation). As mentioned, subset representations may comprise documentation-type subset representations and/or may comprise deployed subset representations, in implementations.”; [0080]-[0082] – “deployed-type subset representations may be utilized for circumstances in which it may be advantageous and/or desirable to restrict not only what appears in the documentation, but also what can actually be queried by a particular audience. To accomplish this, dedicated gateways and/or routers may run the various subset representations as separate endpoints. For example, developers accessing a deployed subset representation endpoint may only be able to query parts of the graph that are included in the particular subset representation and/or may encounter an error if the developers try to query fields that are not included in the particular subset representation. […] a second audience, such as mobile developers 821, for example, may only have visibility into a particular subset representation (e.g., mobile subset representation 820) of the source graph. Additionally, in contrast with the documentation-type mobile devices 822 may only run queries against mobile subset representation 820 via a particular gateway (e.g., "mobile" gateway) and may not have access to the entire unified source graph 810”. Generating the subset representation in step 1040 can be considered to include “generating an API specification”, or a schema, that includes the elements of the supergraph schema with tags selected for inclusion in the subset representation. The elements of the supergraph included in a subset representation are exposed/accessible to an audience (group of users, partners, developers, devices, etc.) via a particular gateway or endpoint for the subset representation.
Additionally, and/or alternatively, [0061] – “An API schema may expose a gateway to a GraphQL API's consumers who may not need to know any internal implementation details about a particular graph”; [0065] – “a gateway, such as gateway 340, may utilize a supergraph schema, such as supergraph schema 420, to generate a GraphQL API schema, such as API schema 430.” Thus, the gateway dedicated to the deployed subset representation described in [0080]-[0082] may be exposed via an API schema generated from the subset representation of the supergraph schema.).
Regarding claim 5, the combination of Zionts in view of Liensberger and Apollo GraphQL Docs teaches the method of claim 4. Zionts further teaches wherein the second element corresponding to the first tag of the set of tags that is selected for exclusion in the subgraph is not exposed via the API specification for the subgraph but is exposed in the federated API ([0101] –“system 900, for example, may filter schema elements from the source supergraph to generate one or more subset representations according to example rules. For example, for circumstances in which the "Included tags" list is empty, system 900, for example, may include each type and/or field in a subset representation unless it is tagged with an "excluded" tag.”; [0080]-[0082] – “deployed-type subset representations may be utilized for circumstances in which it may be advantageous and/or desirable to restrict not only what appears in the documentation, but also what can actually be queried by a particular audience. To accomplish this, dedicated gateways and/or routers may run the various subset representations as separate endpoints. For example, developers accessing a deployed subset representation endpoint may only be able to query parts of the graph that are included in the particular subset representation and/or may encounter an error if the developers try to query fields that are not included in the particular subset representation. […] a first audience 811 may access the entirety of unified source graph 810 via a schema explorer-type application and/or via a changelog, for example. A first set of devices 812 may query the entirety of unified source graph 810 via a unified gateway 840, in an implementation. Similar in at least some respects to the example discussed above in connection with FIG. 7, a second audience, such as mobile developers 821, for example, may only have visibility into a particular subset representation (e.g., mobile subset representation 820) of the source graph. Additionally, in contrast with the documentation-type mobile devices 822 may only run queries against mobile subset representation 820 via a particular gateway (e.g., "mobile" gateway) and may not have access to the entire unified source graph 810”. Supergraph schema elements associated with a tag selected for exclusion are excluded from the generated subset representation. An audience accessing a deployed subset representation endpoint or gateway, can only access the elements included in the subset representation (i.e., the excluded second element would not be exposed). However, the entire supergraph, including the elements excluded from a subset representation, is exposed via a unified gateway for the supergraph.).
Regarding claim 6, the combination of Zionts in view of Liensberger and Apollo GraphQL Docs teaches the method of claim 1. Zionts teaches the method further comprising:
determining, in response to receiving the second user input, a first quantity of elements that are included in the federated API and a second quantity of elements that are included in the subgraph, wherein the first quantity of elements is based at least in part on the plurality of data sources and the second quantity of elements is based at least in part on the second user input; and displaying at the user interface, an indication of the first quantity and the second quantity (FIG. 11, [0102] – “In implementations, user interface 1100 may include "types" and "fields" fields under "source schema" and "proposed subset schema" headings. In an implementation, these example fields may provide a "before" and "after" look at the numbers of types and fields elements that may be impacted from changes to the "included" and/or "excluded" tag lists. For example, the "types" and "fields" entries below the "source schema" heading in user interface 1100 may indicate a number of types and/or a number of fields that may be included in a source graph schema. Also, for example, the "types" and "fields" entries below the "proposed subset schema" heading in user interface 1100 may indicate a number of types and/or a number of fields that may be included in a resulting subset representation based on the filters listed in the "included" and/or "excluded" tag lists. In this manner, a user may have some indication of at least some of the impact that various changes to the tag lists may have in substantially and/or nearly real-time (e.g., as, or shortly after, the user adjusts the tag lists).” The entries below the source schema heading correspond to the “first quantity of elements” since the supergraph schema generated from the subgraphs (“plurality of data sources”) is selected as the source schema as stated in [0099]. The claimed “second user input” specifies the included and excluded tag lists for the subset representation (“subgraph”) as stated in [0100]-[0101], so the entries below the proposed subset schema heading correspond to the “second quantity of elements”.).
Regarding claim 9, the combination of Zionts in view of Liensberger and Apollo GraphQL Docs teaches the method of claim 1. Zionts teaches the method further comprising:
identifying, in response to receiving the first user input, the one or more tags and corresponding elements that are included in a plurality of API specifications of the plurality of data sources ([0060] – “A supergraph schema, such as supergraph schema 420, may comprise the result of performing composition, such as composition operation 410, on a collection of subgraph schemas, such as subgraph schemas A, B, and/or C. A supergraph schema may combine all of the types and/or fields from subgraph schemas plus some federation-specific directives that may instruct a gateway as to which subgraphs may be responsible for resolving particular fields”; [0062] – “schemas may be defined for three subgraphs in a basic example e-commerce application. Individual subgraphs may be implemented as a separate GraphQL API”; [0094] – “a supergraph schema generated from one or more subgraphs may retain the @tag directives (e.g., all of the @tag directives) specified in the subgraphs.” The elements of the subgraph schemas (“API specifications of the plurality of data sources”) are combined into a supergraph schema which contains the elements of the subgraphs and any specified @tag directives. Identification of the tags and elements is implicit in order to include them in the composed supergraph schema. [0099]-[0100] – “A user may also indicate a source (e.g., supergraph schema) to be utilized to generate the one or more subset representations. […] system 900, for example, may detect tag names (e.g., all tag names) that are used in the source supergraph schema (e.g., originating in one or more subgraphs)”. Tags in the supergraph schema, originating from the plurality of subgraph schema, may also be identified in response to a user input selecting a particular supergraph.).
Regarding claim 10, the combination of Zionts in view of Liensberger and Apollo GraphQL Docs teaches the method of claim 1. Zionts teaches the method further comprising:
activating, for selection at the user interface in response to receiving the first user input, the one or more tags, wherein the second user input is received in response to activating the one or more tags at the user interface ([0100] – “"Excluded tags" and "Included tags" fields of user interface 1100 may comprise drop-down lists, although subject matter is not limited in scope in these respects. In an implementation, system 900, for example, may detect tag names (e.g., all tag names) that are used in the source supergraph schema (e.g., originating in one or more subgraphs) and/or may populate the dropdown lists with those names, as appropriate. User interface 1100 may also allow a user to specify one or more "excluded" tags and/or one or more "included" tags and/or to remove one or more tags.”).
Regarding claim 11, the combination of Zionts in view of Liensberger and Apollo GraphQL Docs teaches the method of claim 1. Zionts teaches the method further comprising:
storing an API specification for the subgraph in a datastore associated with the federation management service (FIG. 5 and [0070] – each subset representation (analogous to a claimed “subgraph”) is a subset of the supergraph schema 500, making each subset representation a schema, i.e., an “API specification”, as well. Thus, generating a subset representation, see step 1040 and [0099]-[0102], is generating “an API specification for the subgraph”.
FIG. 9, annotated and reproduced below, in view of paragraphs [0085]-[0088], shows storing the subset representations in schema registry 910 (also referred to as “schema repository 910”) associated with the system 900 (“database associated with the federation management service”).
[AltContent: oval]
PNG
media_image1.png
654
1058
media_image1.png
Greyscale
Annotated FIG. 9
Although storing the generated subset representations mobile representation 931, partner representation 932, and experimental representation 932 in schema registry 910 is not explicitly recited in paragraph [0088], storing the subset representations is indicated in FIG. 9 by the arrows in the circled area above which point from the subset representations into the schema registry 910.
Paragraph [0085] explicitly recites the Users subgraph 911, Products subgraph 912 and Inventory subgraph 913 may be stored in Schema repository 910, which is indicated in FIG. 9 by arrows pointing from subgraphs 911-913 into schema registry 910. Additionally, paragraph [0087] explicitly recites the supergraph composed at block 922 may be stored in schema repository 910, which is also indicated in FIG. 9 by an arrow pointing from block 922 into schema registry 910. It would have been obvious to one of ordinary skill in the art, based on these explicit recitations of storing the subgraphs 911-913 and the supergraph generated at block 922 in the schema registry 910 and corresponding arrows drawn in FIG. 9, that the arrows in the circled area above correspond to storing the subset representations 931, 932, and 932 in schema registry 910.).
Regarding claim 12, the combination of Zionts in view of Liensberger and Apollo GraphQL Docs teaches the method of claim 1. Zionts further teaches wherein the one or more elements comprise an operation, a field, an object, or a combination thereof ([0073] – “subset representations of a graph may be realized by way of a relatively simple, but potentially powerful, directive that may be applied to various schema elements including, but not limited to, fields, interfaces, objects, types, and/or unions”; [0097] – “@tag directives may be supported for schema elements including, but not limited to, object types, object fields, interface types, interface fields and/or union types”. The example subgraph schemas in [0062] and [0093] also include query (“operation”) fields.).
Regarding claim 13, the combination of Zionts in view of Liensberger and Apollo GraphQL Docs teaches the method of claim 1. Zionts teaches the method further comprising:
receiving, at the federation management service, a third user input indicating an additional tag that is to be associated with an element of the federated API, wherein the subgraph of the federated API is generated based at least in part on whether the additional tag is selected for inclusion or exclusion of the element into the subgraph (FIGS. 10 and 11, block 1030 – tags may be added to the generated supergraph; [0092] – “a @tag directive may be added to particular schema elements of a supergraph, for example, to indicate whether to include or exclude the particular schema elements from subset representations of the supergraph.”; [0099] – “A user may also indicate a source (e.g., supergraph schema) to be utilized to generate the one or more subset representations. In implementations, a user interface (e.g., command line interface, graphical user interface, etc.) may be provided on a computing device and/or the like to obtain such inputs from one or more users.”; [0100] – “User interface 1100 may also allow a user to specify one or more "excluded" tags and/or one or more "included" tags and/or to remove one or more tags. In an implementation, a user may add tag names that are not yet present in the source supergraph schema. If tags with those names are later added (e.g., to one or more subgraphs), system 900 may remember the user-specified tag names and may honor them in generating subsequent subset representations, for example.”; [0106] – “Although the example discussed above describes generating a subset representation, subset representations may be modified in much a similar manner. For example, a user may edit lists of "included" and/or "excluded" tags, in an implementation.”).
Claims 14 and 16-17 are directed to an apparatus for data processing (Zionts: FIG. 14, [0154]-[0155], second device 1404, claim 11), comprising:
a processor (Zionts: FIG. 14, processor 1420 and claim 11);
memory coupled with the processor (Zionts: FIG. 14, memory 1422); and
instructions stored in the memory and executable by the processor (Zionts: [0161]) to cause the apparatus to: perform the method of claims 1 and 3-4, respectively. Accordingly, claims 14 and 16-17 are rejected as being unpatentable over Zionts in view of Liensberger and Apollo GraphQL Docs for the same reasons presented with respect to claims 1 and 3-4 above.
Claims 18 and 20 are directed to a non-transitory computer-readable medium storing code for data processing, the code comprising instructions executable by a processor (Zionts: [0160]-[0161] and claim 19) to: perform the method of claims 1 and 3, respectively. Accordingly, claims 18 and 20 are rejected as being unpatentable over Zionts in view of Liensberger and Apollo GraphQL Docs for the same reasons presented with respect to claims 1 and 3 above.
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Zionts in view of Liensberger and Apollo GraphQL Docs as applied to claim 1 above, and further in view of Raheja et al. (U.S. Pub. No. 2022/0035689), hereinafter Raheja.
Regarding claim 7, the combination of Zionts in view of Liensberger and Apollo GraphQL Docs teaches the method of claim 1. Zionts teaches the method further comprising:
([0099] – “a user interface (e.g., command line interface, graphical user interface, etc.) may be provided on a computing device and/or the like to obtain such inputs from one or more users.”), ([0071] – “"Subset representation" and/or the like in this context refers to a subset of a unified graph specified by one or more particular parameters of the graph.”; [0072] – “subset representations of a particular source graph, such as source graph 610 (e.g., supergraph), may enable delivery of different subsets of the source graph to different consumers.”); and
deploying the subgraph of the federated API to the ([0105] – “Further, as indicated at block 1060, subsequent to completion of the various checks, the generated subset representation may be launched (e.g., intended audience may gain access to subset representation) . As mentioned, subset representations may comprise documentation-type subset representations and/or may comprise deployed subset representations, in implementations.”; [0080] – “deployed-type subset representations may be utilized for circumstances in which it may be advantageous and/or desirable to restrict not only what appears in the documentation, but also what can actually be queried by a particular audience. To accomplish this, dedicated gateways and/or routers may run the various subset representations as separate endpoints.”).
The combination of Zionts in view of Liensberger and Apollo GraphQL Docs fails to teach receiving […] a third user input indicating the host environment for hosting the subgraph.
However, Raheja teaches receiving […] a third user input indicating the host environment for hosting an API ([0065] – “the API product manager 310 transmitting a selection of a particular gateway type with an API policy enforcement platform within the API development module 320 of the API lifecycle management system 330. The API product manager 310 may indicate the type of gateway where the API will be deployed, following development, via GUI interfaces with the API build tool 322. […] It is contemplated the API lifecycle management system 330 may allow a user to select any currently known or future developed type of gateway that receives configuration files for deployment of APIs or microservices. In some embodiments, the API product manager 310 may select multiple types of gateways”; [0103] – “At block 502, user-specified high-level gateway operation policies and a user-selected gateway type may be received by the API lifecycle management system in an embodiment. […] the API product manager 210 may set gateway operation policies describing high-level functionality requirements for the API. The high-level gateway operation policies may be set by an API product manager 210 via a GUI or other interface at an API management tool of an API development module.”).
Raheja is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of configuring and deploying an API. Zionts teaches running the different subset representations (“subgraphs”) at dedicated gateways (“host environments”) (see Zionts: [0080]). Therefore, it would have been obvious to one of ordinary skill in the art to have modified the user interface of Zionts to receive a user input indicating a host environment, or gateway, for hosting as taught by Raheja. Deploying each subset representation to a particular gateway enables restriction of what can be queried in the unified graph by a particular audience (Zionts: [0080]-[0082]). Further the API lifecycle management system of Raheja involving a GUI through which a user can select one or more gateway types to which an API should be deployed enables developers to easily and flexibly deploy an API across multiple gateways, which also allows developers to test, in real-time, which gateways handle traffic for the API best (Raheja: [0023]).
Regarding claim 8, the combination of Zionts in view of Liensberger and Apollo GraphQL Docs teaches the method of claim 1. Zionts teaches the method further comprising:
([0099] – “a user interface (e.g., command line interface, graphical user interface, etc.) may be provided on a computing device and/or the like to obtain such inputs from one or more users.”), ([0071] – “"Subset representation" and/or the like in this context refers to a subset of a unified graph specified by one or more particular parameters of the graph.”; [0072] – “subset representations of a particular source graph, such as source graph 610 (e.g., supergraph), may enable delivery of different subsets of the source graph to different consumers.”); and
deploying ([0105] – “Further, as indicated at block 1060, subsequent to completion of the various checks, the generated subset representation may be launched (e.g., intended audience may gain access to subset representation) . As mentioned, subset representations may comprise documentation-type subset representations and/or may comprise deployed subset representations, in implementations.”; [0080] – “deployed-type subset representations may be utilized for circumstances in which it may be advantageous and/or desirable to restrict not only what appears in the documentation, but also what can actually be queried by a particular audience. To accomplish this, dedicated gateways and/or routers may run the various subset representations as separate endpoints.”).
The combination of Zionts in view of Liensberger and Apollo GraphQL Docs fails to teach receiving […] a third user input indicating a quantity of worker nodes and deploying the quantity of worker nodes for hosting the subgraph.
However, Raheja teaches receiving […] a third user input indicating a quantity of worker nodes ([0065] – “GUI interfaces with the API build tool 322 […] the API lifecycle management system 330 may allow a user to select any currently known or future developed type of gateway that receives configuration files for deployment of APIs or microservices. In some embodiments, the API product manager 310 may select multiple types of gateways”; [0086] – “The SLA setting submitted by the API product manager 410 via the API development module 420 API build tool 422 and stored at the metadata repository 424 in an embodiment may further provide one or more spending caps in another embodiment. Spending cap SLA settings may dictate the amount of money the enterprise is willing to spend acquiring the cloud computing resources or processing power necessary to execute their APIs or microservices. For example, the SLA may set an overall cap (e.g., $1,000/hour, other budget limit, a maximum number of nodes or pods, maximum number of users per application, or similar) to acquire cloud computing resources at all gateways at which instances of an API are being executed.” The user may select multiple types of gateways at which the API is executed, which could be considered a user inputting “a quantity of worker nodes”. Alternatively, the user inputs an SLA setting indicating a maximum number of nodes for each gateway at which the API is executed, which can also be considered a user inputting “a quantity of worker nodes”.) and deploying the quantity of worker nodes for hosting the subgraph ([0095] – “it may effectively manage the deployment of a given API or microservice across any number of gateways, or any number of types.”; [0047] – “The API in an embodiment may be provisioned at any one of these gateways 261, 262, 263, 271, or 281, across multiple of these gateways simultaneously, or partially provisioned across multiple of these gateways. […] portions of the API, referred to herein as microservices, may be deployed separately from other portions. These separate deployments may be separated by time, or may be deployed to separate locations (e.g., two different nodes within the same gateway, or to two separate gateways), via API service control plane 235.”; [0113]-[0114] – “the API lifecycle management system 330 may deploy or provision the API directly to one of the gateways (e.g., 361, 362, 363, 371, or 381) of the user-specified gateway type. At block 514, a gateway of the user-specified gateway type may enforce one or more of the user-specified high-level gateway operation policies, based on a most recently received gateway configuration file.”; FIG. 5, block 514 – the gateway “enforces user-specified SLA requirements” including the node availability and maximum number of nodes; Claim 11 provides an example of increasing the number of nodes for processing the API at a gateway to meet the user-specified requirements. The API is deployed to the multiple gateway types (“quantity of worker nodes”) selected by the user. Alternatively, the gateways at which the API is deployed control the number of nodes to enforce the user-inputted SLA requirements, including the maximum number of nodes (“quantity of worker nodes”) executing the API deployed to each gateway.).
Raheja is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of configuring and deploying an API. Zionts teaches running the different subset representations (“subgraphs”) at dedicated gateways (see Zionts: [0080]). Therefore, it would have been obvious to one of ordinary skill in the art to have modified the user interface of Zionts to receive a user input indicating a quantity of worker nodes, such as a number of gateway types or a number of nodes used by each gateway, and deploying the quantity of worker nodes for hosting as taught by Raheja. Deploying an API across a plurality of gateways, each with a plurality of worker nodes, distributes the workload performed by the API and ensures availability and cost requirements of a user are met (Raheja: [0018], [0084] and [0086]).
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 14, and 18 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Specifically, Applicant argues Zionts fails to teach or suggest "the first element is an operation and is dependent on the second element in accordance with the second element being an input into the operation" as recited in the amendment to independent claims 1, 14, and 18.
Regarding the argued limitation, Examiner has relied upon the combination of Zionts in view of new reference Apollo GraphQL Docs, which defines the GraphQL union type schema element disclosed by Zionts. Specifically, Zionts teaches excluding a union type schema element from a subset representation of a supergraph (“subgraph of a federated API”) based on its members, or object types included in the union, having tags that have been excluded from (“not selected for inclusion in”) the subset representation to avoid returning an excluded object (see Zionts: [0096]-[0098]). Apollo GraphQL Docs defines a GraphQL union type implicitly comprises a unification operation which combines the distinct object type members of the union into a set and returns any of the member object types included in the union (see Apollo GraphQL Docs: Pages 1-4). Thus, one of ordinary skill in the art would recognize that Zionts implicitly teaches the union type (“the first element”) is an operation and the members, i.e., included object types, of the union type (one of which may be “the second element”)