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 .
Response to Amendment
Applicant’s Remarks, filed June 25th, 2026, has been fully considered and entered. Accordingly, claims 1-12 are pending in the case. Claims 1 and 6 were amended. Claims 11 and 12 were added. Claims 1 and 6 are the independent claims.
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, and 6-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), further in view of Mukkamala et al. (US 2017/0192414 A1).
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:
for each of the assets in the industrial asset model, creating an artificial OPC UA object and filling the artificial OPC UA object with information (see Bakakeu, Page 54, II. A. OPC UA – Information modeling in Industry 4.0, “Each OPC UA server includes an information model that allows users to organize data and their knowledge in a structured manner. The information model which constitutes the address spaces of an OPC UA server supports object-oriented model paradigms. Features like classes and entities (Object Types and Objects), properties (mandatory or optional), attributes and methods can be modeled in OPC UA. OPC UA also supports composition and inheritance mechanisms. In addition, the OPC UA information model also foresees references, which identify how nodes are related to each other and generally describe a relationship between two nodes,” Page 55, III. Semantic Expressiveness of OPC UA, “As presented in Section II-A, the OPC UA address space can be considered as a directed graph where the nodes (OPC UA nodes) are for example objects or data points and the edges (OPC UA references) are for relations between the nodes.” [The OPC UA server supports object-oriented model paradigms, and considers nodes as objects.]);
However, the combination of Bakakeu, and Dean do not explicitly teach:
for each of the assets in the industrial asset model, creating an artificial OPC UA object and filling the artificial OPC UA object with information;
Mukkamala teaches:
for each of the assets in the industrial asset model, creating an artificial OPC UA object and filling the artificial OPC UA object with information (see Mukkamala, Paragraphs [0063], [0065], “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. … Each piece of physical equipment, or asset, may then be represented by an asset instance.” [Each asset may be represented as an asset instance.]);
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 creates an OPC UA object for each asset in the industrial asset model. 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:
converting the artificial OPC UA objects 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,” Page 55, III. Semantic Expressiveness of OPC UA, “As presented in Section II-A, the OPC UA address space can be considered as a directed graph where the nodes (OPC UA nodes) are for example objects or data points and the edges (OPC UA references) are for relations between the nodes.” [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 2, Bakakeu in view of Dean, further in view of Mukkamala 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.] Also, 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.]).
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 claim 4, Bakakeu in view of Dean, further in view of Mukkamala 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-9, Bakakeu in view of Dean, further in view of Mukkamala teaches all of the elements of claims 1-4 in method form. Bakakeu also discloses a system [Page 58, Figure 5]. Therefore, the supporting rationale of the rejection to claims 1-4 applies equally as well to those elements of claims 6-9.
Claims 5, and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Bakakeu in view of Dean in view of Mukkamala, further in view of Angele et al. (GraphSPARQL: a GraphQL interface for linked Data).
Regarding claim 5, Bakakeu in view of Dean, further in view of Mukkamala teaches all the limitations of claim 1. However, the combination of Bakakeu, Dean, and Mukkamala 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) in view of Mukkamala (teaching systems and methods for managing industrial assets), 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, Mukkamala, 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 in view of Mukkamala, further in view of Angele teaches all of the elements of claim 5 in method form. Bakakeu also discloses a system [Page 58, Figure 5]. Therefore, the supporting rationale of the rejection to claim 5 applies equally as well to those elements of claim 10.
Claims 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Bakakeu in view of Dean in view of Mukkamala, further in view of Meyerzon et al. (US 2011/0145218 A1).
Regarding claim 5, Bakakeu in view of Dean, further in view of Mukkamala teaches all the limitations of claim 1. Bakakeu further teaches:
receiving a user-set configuration for a schema generator, and causing the schema generator to crawl the RDF knowledge graph stored in the database according to the user-set configuration, wherein the user-set configuration controls a crawl depth used by the schema generator when crawling the RDF knowledge graph (see Bakakeu, Page 55, II. B. Semantic technologies, “SPARQL [19] for example is an RDF query language that can be used to query any RDF-based data (i.e., including statements involving RDFS and OWL).” 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. Therefore, the presented model transformer constitutes a tool for automated reasoning and knowledge inference on OPC UA information models.” [The SPARQL queries may be used to search for RDF based data.]).
However, the combination of Bakakeu, Dean, and Mukkamala do not explicitly teach:
receiving a user-set configuration for a schema generator, and causing the schema generator to crawl the RDF knowledge graph stored in the database according to the user-set configuration, wherein the user-set configuration controls a crawl depth used by the schema generator when crawling the RDF knowledge graph.
Meyerzon teaches:
receiving a user-set configuration for a schema generator, and causing the schema generator to crawl the RDF knowledge graph stored in the database according to the user-set configuration, wherein the user-set configuration controls a crawl depth used by the schema generator when crawling the RDF knowledge graph (see Meyerzon, Paragraph [0020], “ enabling a client to configure, and thus control, the crawling function of a search service application server having crawl functionality.” [A user may configure a crawl depth.]).
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) in view of Mukkamala (teaching systems and methods for managing industrial assets), further in view of Meyerzon (teaching search service administration web service protocol), and arrived at a method that controls crawl depth. One of ordinary skill in the art would have been motivated to make such a combination for the purposes of restricting the boundaries of the crawl (see Angele, Paragraph [0020]). In addition, the references (Bakakeu, Dean, Mukkamala, and Meyerzon) 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 11, Bakakeu in view of Dean in view of Mukkamala, further in view of Meyerzon teaches all the elements of claims 1 in method form. Bakakeu also discloses a system [0026]. Therefore, the supporting rationale of the rejection to claim 11 applies equally as well to those elements of claim 12.
Response to Arguments
Applicant’s Arguments, filed June 25th, 2026 have been fully considered, but are not persuasive.
Applicant argues on page 8 of Applicant's Remarks that the cited references do not teach or suggest “for each of the assets in the industrial asset model, creating an artificial OPC UA object and filling the artificial OPC UA object with information,” and “converting the artificial OPC UA objects to a resource description format (RDF) knowledge graph.” The Examiner respectfully disagrees.
Bakakeu discloses on page 54, section II. A. OPC UA – Information modeling in Industry 4.0, “Each OPC UA server includes an information model that allows users to organize data and their knowledge in a structured manner. The information model which constitutes the address spaces of an OPC UA server supports object-oriented model paradigms. Features like classes and entities (Object Types and Objects), properties (mandatory or optional), attributes and methods can be modeled in OPC UA. OPC UA also supports composition and inheritance mechanisms. In addition, the OPC UA information model also foresees references, which identify how nodes are related to each other and generally describe a relationship between two nodes,” and on page 55, section III. Semantic Expressiveness of OPC UA, “As presented in Section II-A, the OPC UA address space can be considered as a directed graph where the nodes (OPC UA nodes) are for example objects or data points and the edges (OPC UA references) are for relations between the nodes.” As shown, the OPC UA server supports object-oriented paradigms, and the OPC UA address can be considered as a directed graph where the nodes are objects. Therefore, an OPC UA object may be created and filled with information.
Mukkamala discloses in paragraphs [0063] and [0065], “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. … Each piece of physical equipment, or asset, may then be represented by an asset instance.” As shown, an asset model may include a digital representation of the asset’s structure, in which each piece of asset may be represented by an asset instance.
Accordingly, Bakakeu discloses on 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,” Page 55, III. Semantic Expressiveness of OPC UA, “As presented in Section II-A, the OPC UA address space can be considered as a directed graph where the nodes (OPC UA nodes) are for example objects or data points and the edges (OPC UA references) are for relations between the nodes.” As shown, the OPC UA information may be transformed (i.e., converting the assets) into an RDF-Graph. Therefore, it is believed that Bakakeu teaches Applications amended limitations as claimed.
For the above reasons, it is believed that the rejections should be sustained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
1.) Dasari (US 2023/0124333 A1), which discloses a method for building and publishing schemas based on data patterns and data formats.
2.) Bradley et al. (US 2023/0161946 A1), which discloses a method for manually and programmatically remediating websites
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 extension fee 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 date of this final action.
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
Prosecution Insights