DETAILED ACTION
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 .
This action is responsive to communication filed on 30 March 2026. Claims 1-10 are pending in the case. Claims 1, 2, 5, 6, 7, and 10 were amended. Claims 1, and 6 are the independent claims. This action is non-final.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 30th, 2026 has been entered.
Claim Rejections - 35 USC § 103
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 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.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
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, 4, 6, and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Bakakeu et al. (Automated Reasoning and Knowledge Inference on OPC UA Information Models) in view of Dean et al. (US 10,503,784 B1).
Regarding claim 1, Bakakeu teaches a computer-implemented method, the method comprising:
based on user selections, generating an industrial asset model comprising assets from a plurality of different sources, the assets defined in accordance with an Open Platforms Communication United Architecture (OPC UA) (see Bakakeu, Page 54, I. Introduction, “presenting a solution to infer knowledge directly from OPC UA information models.” [Knowledge is inferred directly from different OPC UA information models (i.e., plurality of different sources).] Page 57, B. The Prototype, “An OPC UA client that establishes a connection to an OPC UA server, browses the information model and builds an internal graph representation of the server address space.” [An OPC UA client (i.e., user) builds an internal graph representation (i.e., generating an industrial asset model).]);
However, Bakakeu does not explicitly teach:
creating a separate asset hierarchy that captures variables from multiple hierarchies of an OPC UA tree, wherein the variables reside in different parts of the OPC UA tree, into a single asset to define a user-specific view;
Dean teaches:
creating a separate asset hierarchy that captures variables from multiple hierarchies of an OPC UA tree, wherein the variables reside in different parts of the OPC UA tree, into a single asset to define a user-specific view (see Dean, [Column 26, Lines 1-19], [Column 52, Lines 13-27], [Column 27, Lines 62-65], [Columns 36-38, Lines 60-67, 1-67, 1-30], “intermediary data system 2114 may be, for example, and OPC/UA server using standard protocols to collect asset information which it may later provide to DIQ 2120. … FIG. 14 illustrates a method for constructing an asset tree representation in control storage. … At block 2512, the AMRS receives an indication of search criteria which may be provided by user interaction with the user interface. … At block 2514, the indications of search criteria received at block 2512 are utilized by the AMRS to construct, as necessary, a search query to locate useful asset-related information, and to execute a search to locate such useful asset-related information in accordance with the indicated search criteria. … At block 2520, the AMRS makes a determination of an asset tree structure by processing the result of the search query produced at block 2514, or a related search, in view and consideration of the asset and parent indications received at block 2518. A related search, in an embodiment, may be a search that is derived from the original search but is somehow modified, perhaps by restricting the fields returned in the search result set, or perhaps by expanding the scope of the data searched, or perhaps by other variations. The processing of block 2520, in an embodiment, may determine all of the unique identifiers that may be found within the designated asset identifier field of the search result set and create an asset hierarchy node for each, determine a respective parent for each unique asset using information found within the designated asset parent identifier field of the search result set, and cross reference asset identifiers and asset parent identifiers to determine the hierarchical relationships for the asset nodes and create a representation of those associations between the created asset nodes. … At block 2522, in an embodiment, processing is performed to receive and process user indications of data items, elements, fields, constants, or the like that should be included in, directly or indirectly, the definitional information of nodes in the asset hierarchy tree. … The processing of block 2524, in an embodiment, may conclude with a representation in the computer storage that reflects an asset hierarchy structure with augmented information.” [An asset tree representation (i.e., separate asset hierarchy) may be constructed by searching an OPC/UA server for asset information (i.e., captures variables from multiple hierarchies of an OPC UA tree, wherein the variables reside in different parts of the OPC UA tree), and processes asset identifier information in order to create a representation in the computer storage that reflects an asset hierarchy structure with augmented information (i.e., into a single asset to define a user-specific view).]);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Bakakeu (teaching automated reasoning and knowledge inference on OPC UA information models) in view of Dean (teaching control interface for asset tree monitoring), and arrived at a method that incorporates a separate asset hierarchy. One of ordinary skill in the art would have been motivated to make such a combination for the purposes of optimizing query and information classifications (see Dean, [Column 26, Lines 20-41]). In addition, both the references (Bakakeu and Dean) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as information systems. The close relation between both the references highly suggests an expectation of success.
The combination of Bakakeu, and Dean further teaches:
converting the assets from the OPC UA to a resource description format (RDF) knowledge graph (see Bakakeu, Page 54, I. Introduction, “we first analyzed the semantic expressiveness of the OPC UA address model and compared it with standard semantic knowledge representation formalisms such as RDFS and OWL. We proved that an OPC UA information model can always be transformed in an ontology. We then derived and implemented a solution to transform an arbitrary OPC UA information model into an RDF-Graph expressing an OWL Ontology.” [The OPC UA information model may be transformed (i.e., converting the assets) into an RDF-Graph.]);
storing the RDF knowledge graph in a database (see Bakakeu, Page 58, B. The Prototype, “In order to store the generated triples, the Jena Tuple DataBase TDB2 [30] is used. This triple-store holds all the semantic graphs generated from the OPC UA information model.” [The generated triples are stored in the Jena Tuple Database (i.e., storing the RDF knowledge graph in database).]);
receiving a query for industrial data (see Bakakeu, Page 58, B. The Prototype, “Fig. 6 shows the example of an OPC UA information model (a) transformed into OWL DL (b) and a SPARQL query verifying that all objects of type “BoilerType” have a temperature sensor.” [A SPARQL query may be received (i.e., receiving a query for industrial data).]);
and responsive to the query for industrial data, extracting, from the database, at least two of the assets from the plurality of sources, the at least two assets representative of the industrial data (see Bakakeu, Page 58, B. The Prototype, “With the presented architecture, complex queries, reasoning, and knowledge inference requests in form of SPARQL queries can be directly executed on the transformed information model. Since the resulting OWL ontology only formalizes the knowledge modeled by the address space of an OPC UA server, the results of these queries will only express the knowledge exposed by the OPC UA server.” [Results may be returned in response to the SPARQL queries, which implies multiple assets from the sources may be extracted from the database.]).
Regarding claim 4, Bakakeu in view of Dean teaches all the limitations of claim 1. Bakakeu further teaches:
wherein the asset model defines an asset variable that subscribes to a respective OPC source of the asset variable, the method further comprising: based on subscribing to the OPC source, identifying a change to the OPC source; and updating the asset variable responsive to identifying the change to the OPC source (see Bakakeu, Page 54, I. Introduction, “presenting a solution to infer knowledge directly from OPC UA information models.” Page 58, B. The Prototype, “The client, which is implemented using eclipse Milo [28], also synchronizes the internal graph representation with the information model of the OPC UA Server. If new events are generated or a value of a data variable changes, the client updates the internal graph so that it remains aligned with the server address space.” [The internal graph is synchronized with the OPC UA information models (i.e., sources), which implies that an asset variable may be updated when a change to OPC UA information models occurs.]).
Regarding claims 6 and 9, Bakakeu in view of Dean teaches all of the elements of claims 1, and 4 in method form. Bakakeu also discloses a system [Page 58, Figure 5]. Therefore, the supporting rationale of the rejection to claims 1, and 4 applies equally as well to those elements of claims 6 and 9.
Claims 2, 3, 7, and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Bakakeu in view of Dean further in view of Mukkamala et al. (US 2017/0192414 A1).
Regarding claim 2, Bakakeu in view of Dean teaches all the limitations of claim 1. Bakakeu further teaches:
receiving, via a Restful interface, a request associated with a change to the asset model; responsive to the request, adjusting an asset of the asset model in accordance with the change, so as to define an adjusted asset (see Bakakeu, Page 58, B. The Prototype, “The client, which is implemented using eclipse Milo [28], also synchronizes the internal graph representation with the information model of the OPC UA Server. If new events are generated or a value of a data variable changes, the client updates the internal graph so that it remains aligned with the server address space.” [A client may update the internal graph (i.e., asset model) using eclipse Milo.]).
However, the combination of Bakakeu, and Dean do not explicitly teach:
receiving, via a Restful interface, a request associated with a change to the asset model; responsive to the request, adjusting an asset of the asset model in accordance with the change, so as to define an adjusted asset. [i.e., via a Restful interface]
Mukkamala teaches:
receiving, via a Restful interface, a request associated with a change to the asset model; responsive to the request, adjusting an asset of the asset model in accordance with the change, so as to define an adjusted asset (see Mukkamala, Paragraph [0063], “an asset model provides a centerpiece of one or more Industrial Internet applications. While assets are the physical manifestations of various asset types (i.e., types of industrial equipment, such as turbines), an asset model can include a digital representation of the asset's structure. In an example embodiment, an asset service provides Application Program Interfaces (APIs), such as Representational State Transfer (REST) APIs that enable application developers to create and store asset models that define asset properties, as well as relationships between assets and other modeled elements.” [A Restful interface may be incorporated.]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Bakakeu (teaching automated reasoning and knowledge inference on OPC UA information models) in view of Dean (teaching control interface for asset tree monitoring), further in view of Mukkamala (teaching systems and methods for managing industrial assets), and arrived at a method that incorporates a restful interface. One of ordinary skill in the art would have been motivated to make such a combination for the purposes of improving effectiveness of asset maintenance (see Mukkamala, Paragraph [0030]). In addition, the references (Bakakeu, Dean, and Mukkamala) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as information systems. The close relation between the references highly suggests an expectation of success.
The combination of Bakakeu, Dean, and Mukkamala further teaches:
and invoking an OPC to RDF library, such that the RDF knowledge graph related to the adjusted asset is updated, wherein the OPC to RDF library converts an OPC UA model into an RDF graph that then is loaded into the database so as to replace an older asset by the RDF graph (see Bakakeu, Pages 57-58, B. The prototype, “In order to demonstrate the feasibility and the usability of our solution for knowledge inference and reasoning on OPC UA information model, we implemented a model transformer as a software solution that uses an OPC UA client to browse the complete address space of an OPC UA server, applies our transformation rules to convert the extracted information model into an OWL DL ontology and then exposes the transformed knowledge via a SPARQL endpoint. … An OPC UA client that establishes a connection to an OPC UA server, browses the information model and builds an internal graph representation of the server address space. The client, which is implemented using eclipse Milo [28], also synchronizes the internal graph representation with the information model of the OPC UA Server. If new events are generated or a value of a data variable changes, the client updates the internal graph so that it remains aligned with the server address space. … A Triple-Store Adapter contains the transformation rules defined in Section IV-A and applies them on the internal graph to generate OWL DL compliant triples that encode the knowledge exposed by the OPC UA server. The Triple- Store Adapter is implemented using the frame work Jena [29], [30]. In order to store the generated triples, the Jena Tuple DataBase TDB2 [30] is used. This triple-store holds all the semantic graphs generated from the OPC UA information model.” [An OPC UA model may be converted into an RDF graph in order to replace an older asset by the RDF graph.]).
Regarding claim 3, Bakakeu in view of Dean, further in view of Mukkamala teaches all the limitations of claim 2. Bakakeu further teaches:
updating the RDF graph in accordance with the adjusted asset (see Bakakeu, Page 54, I. Introduction, “we first analyzed the semantic expressiveness of the OPC UA address model and compared it with standard semantic knowledge representation formalisms such as RDFS and OWL. We proved that an OPC UA information model can always be transformed in an ontology. We then derived and implemented a solution to transform an arbitrary OPC UA information model into an RDF-Graph expressing an OWL Ontology.” Pages57-58, B. The Prototype, “The client, which is implemented using eclipse Milo [28], also synchronizes the internal graph representation with the information model of the OPC UA Server. If new events are generated or a value of a data variable changes, the client updates the internal graph so that it remains aligned with the server address space.” [A client may update the internal graph (i.e., asset model), and the RDF graph is updated accordingly.]).
Regarding claims 7 and 8, Bakakeu in view of Dean, further in view of Mukkamala teaches all of the elements of claims 2, and 3 in method form. Bakakeu also discloses a system [Page 58, Figure 5]. Therefore, the supporting rationale of the rejection to claims 2, and 3 applies equally as well to those elements of claims 7 and 8.
Claims 5, and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Bakakeu in view of Dean, further in view of Angele et al. (GraphSPARQL: a GraphQL interface for linked Data).
Regarding claim 5, Bakakeu in view of Dean teaches all the limitations of claim 1. However, the combination of Bakakeu, and Dean do not explicitly teach:
receiving, at a generic GraphQL server or generic resolver, the query compliant with a GraphQL API, so to define a GraphQL query; converting, using GraphQL Schema and Meta-Info, the GraphQL query to a query compliant with SPARQL, so as to define a SPARQL query, wherein the converting is activated during a resolving stage when an “isAsset” flag is true for a current GraphQL type being processed to apply a special processing algorithm for assets; and formatting the at least two assets representative of the industrial data in a format selected by a user.
Angele teaches:
receiving, at a generic GraphQL server or generic resolver, the query compliant with a GraphQL API, so to define a GraphQL query; converting, using GraphQL Schema and Meta-Info, the GraphQL query to a query compliant with SPARQL, so as to define a SPARQL query, wherein the converting is activated during a resolving stage when an “isAsset” flag is true for a current GraphQL type being processed to apply a special processing algorithm for assets; and formatting the at least two assets representative of the industrial data in a format selected by a user (see Angele, Pages 782, 783, 4.1 GraphSPARQL Architecture, 4.2 Enriched GraphQL Schema, 5.1 Setup, “With the endpoint and schema configuration available, the user can send their GraphQL queries (see Figure 3a for a close-up) to the Parser, optionally using the GraphiQL interface in the process. Utilizing the GraphQL .Net library as well as C#-objects generated from the specified schema, the Parser translates and collects queries which are then given in batches to the Query Processor, which in turn uses the dotNetRDF library to send SPARQL queries to the connected RDF databases. Considering the returned results (see Figure 3b), the Query Processor receives SPARQL results from the queried RDF databases. The dotNetRDF library is used to lift all the different return formats. These results are then fed back to the generated C# schema objects that either use the formatting capabilities provided by the GraphQL.Net library or our custom scalar formatters to produce the JSON results. Finally, the JSON data is then again optionally displayed by the GraphiQL interface. … a standard GraphQL schema is not enough to provide sufficient information on how to map GraphQL types and fields to RDF classes and properties. Furthermore, as we want to support advanced filtering, mandatory fields, and other query flags that match SPARQL behavior, we have to store additional meta-data within the schema … We installed Star dog on a test server 27 directly, without using docker containers.” [A GraphQL query is received, and converted into a SPARQL in order to retrieve results. A GraphQL Schema and meta-data (i.e., using a GraphQL Schema and Meta-Info) is used to define a SPARQL query. The query flags (i.e., wherein the converting is activated during a resolving stage when an “isAsset” flag is true for a current GraphQL type being processed to apply a special processing algorithm for assets) may be used in order to identify assets. A test server (i.e., at a generic GraphQL server or generic resolver) is used in order to handle the queries.]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Bakakeu (teaching automated reasoning and knowledge inference on OPC UA information models) in view of Dean (teaching control interface for asset tree monitoring), further in view of Angele (teaching GraphSPARQL: A GraphQL Interface for Linked Data), and arrived at a method that converts GraphQL queries into SPARQL queries, and obtains results. One of ordinary skill in the art would have been motivated to make such a combination for the purposes of improving storing and managing knowledge graphs (see Angele, Abstract). In addition, the references (Bakakeu, Dean, and Angele) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as information systems. The close relation between the references highly suggests an expectation of success.
Regarding claim 10, Bakakeu in view of Dean, further in view of Angele teaches all of the elements of claims 5 in method form. Bakakeu also discloses a system [Page 58, Figure 5]. Therefore, the supporting rationale of the rejection to claims 5 applies equally as well to those elements of claims 10.
Response to Arguments
Applicant’s Arguments, filed March 30th, 2026 have been fully considered, but are not persuasive.
Applicant argues on pages 6-7 of Applicant's Remarks that the cited references do not teach or suggest “creating a separate asset hierarchy that captures variables from multiple hierarchies of an OPC UA tree, including variables that reside in different parts of the OPC UA tree, into a single asset to define a user-specific view,” and “The rejection also lack a sufficient motivation to combine for the specific claimed modification.” The Examiner respectfully disagrees.
Dean discloses in [Column 27, Lines 62-65], [Columns 36-38, Lines 60-67, 1-67, 1-30], “intermediary data system 2114 may be, for example, and OPC/UA server using standard protocols to collect asset information which it may later provide to DIQ 2120. … FIG. 14 illustrates a method for constructing an asset tree representation in control storage. … At block 2512, the AMRS receives an indication of search criteria which may be provided by user interaction with the user interface. … At block 2514, the indications of search criteria received at block 2512 are utilized by the AMRS to construct, as necessary, a search query to locate useful asset-related information, and to execute a search to locate such useful asset-related information in accordance with the indicated search criteria. … At block 2520, the AMRS makes a determination of an asset tree structure by processing the result of the search query produced at block 2514, or a related search, in view and consideration of the asset and parent indications received at block 2518. A related search, in an embodiment, may be a search that is derived from the original search but is somehow modified, perhaps by restricting the fields returned in the search result set, or perhaps by expanding the scope of the data searched, or perhaps by other variations. The processing of block 2520, in an embodiment, may determine all of the unique identifiers that may be found within the designated asset identifier field of the search result set and create an asset hierarchy node for each, determine a respective parent for each unique asset using information found within the designated asset parent identifier field of the search result set, and cross reference asset identifiers and asset parent identifiers to determine the hierarchical relationships for the asset nodes and create a representation of those associations between the created asset nodes. … At block 2522, in an embodiment, processing is performed to receive and process user indications of data items, elements, fields, constants, or the like that should be included in, directly or indirectly, the definitional information of nodes in the asset hierarchy tree. … The processing of block 2524, in an embodiment, may conclude with a representation in the computer storage that reflects an asset hierarchy structure with augmented information.”
As shown, Dean discloses a method for constructing an asset tree representation by searching asset-related information from an OPC UA Server, determining unique identifiers, creating an asset hierarchy node for the identifiers, determining parents for the nodes, and cross referencing asset identifiers and asset parent identifiers in order to determine the hierarchical relationships, processing the information including variables in order to conclude with a representation in the computer storage that reflects an asset hierarchy structure with information that is augmented. Therefore, Dean teaches an asset tree representation (i.e., separate asset hierarchy) may be constructed by searching an OPC/UA server for asset information (i.e., captures variables from multiple hierarchies of an OPC UA tree, wherein the variables reside in different parts of the OPC UA tree), and processes asset identifier information in order to create a representation in the computer storage that reflects an asset hierarchy structure with augmented information (i.e., into a single asset to define a user-specific view).
Thererfore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Dean into Bakakeu for the purposes of optimizing query and information classifications (see Dean, [Column 26, Lines 20-41]). In addition, both the references (Bakakeu and Dean) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as information systems. The close relation between both the references highly suggests an expectation of success.
Applicant argues on pages 7-8 of Applicant's Remarks that the cited references do not teach or suggest “and invoking an OPC to RDF library, such that the RDF knowledge graph related to the adjusted asset is updated, wherein the OPC to RDF library converts an OPC UA model into an RDF graph that then is loaded into the database so as to replace an older asset by the RDF graph.” The Examiner respectfully disagrees.
Bakakeu discloses on Pages 57-58, B. The prototype, “In order to demonstrate the feasibility and the usability of our solution for knowledge inference and reasoning on OPC UA information model, we implemented a model transformer as a software solution that uses an OPC UA client to browse the complete address space of an OPC UA server, applies our transformation rules to convert the extracted information model into an OWL DL ontology and then exposes the transformed knowledge via a SPARQL endpoint. … An OPC UA client that establishes a connection to an OPC UA server, browses the information model and builds an internal graph representation of the server address space. The client, which is implemented using eclipse Milo [28], also synchronizes the internal graph representation with the information model of the OPC UA Server. If new events are generated or a value of a data variable changes, the client updates the internal graph so that it remains aligned with the server address space. … A Triple-Store Adapter contains the transformation rules defined in Section IV-A and applies them on the internal graph to generate OWL DL compliant triples that encode the knowledge exposed by the OPC UA server. The Triple- Store Adapter is implemented using the frame work Jena [29], [30]. In order to store the generated triples, the Jena Tuple DataBase TDB2 [30] is used. This triple-store holds all the semantic graphs generated from the OPC UA information model.” As shown, a transformation of the OPC UA information model into an OWL DL ontology using Jena Triple-Store Adapter and Jena database is demonstrated.
Applicant argues on pages 8-9 of Applicant's Remarks that the cited references do not teach or suggest “receiving, at a generic GraphQL server or generic resolver, the query compliant with a GraphQL API, so to define a GraphQL query; converting, using GraphQL Schema and Meta-Info, the GraphQL query to a query compliant with SPARQL, so as to define a SPARQL query, wherein the converting is activated during a resolving stage when an “isAsset” flag is true for a current GraphQL type being processed to apply a special processing algorithm for assets.” The Examiner respectfully disagrees.
Angele discloses on pages 781-782, a process for translating GraphQL queries into SPARQL queries. Accordingly, Angele discloses on page 782, 4.2 Enriched GraphQL Schema, “a standard GraphQL schema is not enough to provide sufficient information on how to map GraphQL types and fields to RDF classes and properties. Furthermore, as we want to support advanced filtering, mandatory fields, and other query flags that match SPARQL behavior, we have to store additional meta-data within the schema.” As shown, a schema and metadata information as well as query flags are necessary in order to translate the queries. Therefore, a GraphQL query is received, and converted into a SPARQL in order to retrieve results. A GraphQL Schema and meta-data (i.e., using a GraphQL Schema and Meta-Info) is used to define a SPARQL query. The query flags (i.e., wherein the converting is activated during a resolving stage when an “isAsset” flag is true for a current GraphQL type being processed to apply a special processing algorithm for assets) may be used in order to identify assets.
Also, Angele discloses on page 783, section 5.1 Setup, that a test server is used in order to handle the queries. Therefore, Angele teaches “a generic GraphQL server or generic resolver.”
For the above reasons, it is believed that the rejections should be sustained.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUSAM TURKI SAMARA whose telephone number is (571)272-6803. The examiner can normally be reached on Monday - Thursday, Alternate Fridays.
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, Apu Mofiz can be reached on (571)-272-4080. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HUSAM TURKI SAMARA/
Examiner, Art Unit 2161
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161