The claims define the scope of the protection conferred by the Configurable Ontology to Data Model, CODT, patent. CODT is the technology that created the FIBO Data Model.
The United States Patent and Trademark Office (USPTO) has exacting rules regarding patent claims’ structure and legal wording, which can be difficult for Data Architects to understand.
This document explains the US12038939 patent claims and links to the definitions of the terms and supporting sections in the user-friendly version of the patent’s detailed specification.
Introduction
The USPTO’s website provides a glossary defining terms in patent law and concepts, examination, and registration. This introduction quotes term definitions and explains them in the context of software patents and CODT.
Quotes from the specification and external sources are in Italics. To the right of the patent claims are linked to the specification: F indicates a patent drawing (Figure), T is a table, and P is a specification paragraph.
Invention
Any art or process (way of doing or making things), machine, manufacture, design, or composition of matter, or any new and useful improvement thereof, or any variety of plant, which is or may be patentable under the patent laws of the United States.
In other words, the invention is a novel idea; in the case of CODT, it is a new and improved way of transforming ontologies into data models. Software patents are process patents.
Embodiments
A manner in which an invention can be made, used, practiced, or expressed.
A mere idea cannot be patented – the specification must describe at least one practical implementation of the software. Patents often disclose a main (or preferred) embodiment and other (alternative) embodiments. The patent’s detailed specification states: The CODT Working Product or prototype implements the first embodiment as a Microsoft Excel Application on Windows 10. P6 T1
The Excel Application is a possible implementation but by no means the only or preferred embodiment. However, the best way to encode CODT is to build the Excel Application first, and then migrate to other embodiments as needed.P7
Table 19 lists different ways to implement CODT, broken down by categories Ontology Source, Transformation System, and target Data Model, each category having three sub-categories. T19
| TABLE 19 – Implementation Embodiments | ||||||||
| Ontology Source | Transformation System | Data Model | ||||||
| Type | Subtype | Extraction | OS | Application type | User Interface | Data Model Type | Modeling Tool | Tool Interface |
| Ontology platform | Development Platform | SPARQL | MS Windows | MS-Excel | White Box | Conceptual | Power Designer | Import |
| RDF Store, Semantic Endpoint | Logical | Sparx EA | ||||||
| RDF/OWL files | Local | Parser | Unix | ETL | Guided | Physical | Other | API |
| World Wide Web | Program | Object | ||||||
For example, the first embodiment, in green, is an Excel white box that uses SPARQL to extract the ontology and creates Conceptual Data Model import files for SAP PowerDesigner.
Novelty
An invention must be a useful and new or improved process to qualify for a patent.
The Background section of the CODT Specification acknowledges existing rudimentary ontology to data model transformations:
Some modeling tools like Sparx EA and IBM IDA provide an import of RDF/OWL files and subsequent Transformation. P1
And point out their shortcomings:
However, these data modeling tool imports don’t enable the user to change the mapping and transformation rules. In particular, the Transformation does not enable the user to apply a naming standard to generated entity names. P1
Per default, ontology object properties transform into data model relationships. This Transformation loses Metadata for object properties with particular design patterns. (see, J. Ziemer “Ontology Object Properties are Data Model Associative Entities – not Relationships.”) P2
Traditional transformations parse ontology files. They encounter elements of the ontology and create elements of the data model as they process the source files. The parsing approach reaches its limits with very large ontologies like the FIBO. P3
The Summary section states that CODT archives the result with a radically different approach. P4
Rather than parsing source files, CODT uses RDF Query Language (SPARQL) to extract ontology metadata from an ontology platform. CODT transforms ontology metadata into standardized Metadata Sets (MDS), which provide a holistic view of the ontology rather than individual elements of the ontology file. CODT works in set operations rather than procedural algorithms. P5
Metadata Sets require the user to configure settings for transformation rules and overrides.
System, Storage Medium, and Method
Most Software patents are process patents with the Method claims at the center. The computer System Claim merely implements the method, restating the method claims, and the Storage Medium holds the computer code. This specification teaches differently.
The CODT System of Independent Claim 1 has four components, four Excel workbooks in the first embodiment. The Storage Medium of Independent Claim 5 holds the Metadata Sets central to the innovative transformation approach.
| TABLE 18 – Alignment | ||
| System Component | Storage Medium | Method |
| Component | Metadata Set | Subprocess |
| Extraction | Ontology | Extract Ontology metadata |
| Transformation | Entity-Relationship | Transform Metadata |
| Load | Data Modeling Tool-specific | Load into Modeling Tool |
The Method of Independent Claim 14 discloses the ETL (Extract, Transform, and Load) process and transformation algorithms.
The Claims
A heading with the patent claim number and a descriptive keyword precedes the text. To the right of the claim, links point to the supporting Paragraphs, Figures, and Tables in the specification.
1. System
| A system, comprising: | F2 | ||
| a non-transitory storage medium that stores computer-executable components and a processor that executes the computer-executable components stored on the non-transitory storage medium, wherein the computer-executable components comprise: | |||
| a configuration component that enables a user to configure settings for a transformation of elements of an ontology into elements of a data model; | P12 | ||
| an extraction component that retrieves ontology metadata and converts ontology metadata into ontology metadata sets; | P10 | ||
| a transformation component that transforms the ontology metadata sets into entity-relationship metadata sets and the entity-relationship metadata sets into modeling tool-specific metadata sets.; and | P10 | ||
| whereby said system transforms ontology metadata into modeling tool-specific metadata according to configuration settings. | F1 | ||
Note that the claim explicitly mentions a configuration component and settings. Indeed, a hard-coded transformation without means for a user to adjust the outcome does not infringe on the patent.
In an analogy, Data Architects and Modelers transform a Logical Data Model (LDM) into a Physical Data Model (PDM) and generate database tables from the PDM. They must be able to configure how logical names transform to table and column names and whether supertype/subtypes entities are rolled up or down or both transformed onto tables. Likewise, the CODT specification teaches configuration settings for the naming standard, resolution of duplicate names, and how to transform ontology object properties. For example, entity names must be unique per the default configuration setting. The Analytics Component highlights duplicate names so the user may manually override names or specify a transformation rule to make the names unique. P13
2. SPARQL
| The system of claim 1, wherein the extraction component can retrieve the ontology metadata from an ontology platform executing SPARQL metadata queries. | P8 P18 |
The SPARQL metadata queries disclosed in the specification are the central innovation – the means by which the invention produces its results.
3. Parsing
| The system of claim 1, wherein the extraction component can retrieve ontology metadata by parsing ontology files. | T19 P29 |
The conventional way of parsing RDF/OWL files is also possible but unsuitable for large ontologies like the FIBO.
4. Load
| The system of claim 1, further comprising: | P11 | |
| a load component that can connect to a modeling tool and populate a data model with data model elements from the modeling tool-specific metadata set. | ||
In other embodiments, the task may directly connect to the Data Modeling Tool or Repository API and create the data model. P9
5. Storage Medium
| A non-transitory storage medium storing ontology metadata sets, entity-relationship metadata sets, and data modeling tool-specific metadata sets coupled with machine-readable instructions that cause one or more processors to: | F3 F13 | |
| enable a user to configure settings for a transformation of elements of an ontology into elements of a data model; | F19 | |
| populate ontology metadata sets with extracted ontology metadata; | F6 F14 T2 | |
| populate entity-relationship metadata sets by transforming metadata from the ontology metadata sets; | F9 F15 T12 | |
| populate data modeling tool-specific metadata sets by transforming metadata from a generic entity-relationship metadata set; and | F11 F17 | |
| whereby a coupling of a metadata sets and instructions makes the metadata sets self-populating, reducing the complexity of machine-readable instructions. | F7 F8 | |
CODT transforms ontology metadata into standardized Metadata Sets (MDS), which provide a holistic view of the ontology rather than individual elements of the ontology file. CODT works in set operations rather than procedural algorithms. P5
6. SPARQL
| The non-transitory storage medium of claim 5, wherein the instructions populate the ontology metadata sets with extracted ontology metadata further comprise instructions that cause the one or more processors to: | F20 P15 P26 | |
| retrieve ontology metadata from an ontology platform by executing SPARQL metadata queries. | F5 | |
Corresponding to System Claim 2 and Method Claim 12.
7. Parse
| The non-transitory storage medium of claim 5, wherein the instructions populate the ontology metadata sets with extracted ontology metadata further comprise instructions that cause the one or more processors to: | P29 | |
| parse ontology files to retrieve ontology metadata. | ||
Corresponding to System Claim 3.
8. Modeling Tool
| The non-transitory storage medium of claim 5, wherein the instructions populate the ontology metadata sets with extracted ontology metadata further comprise instructions that cause the one or more processors to: | F22 | |
| connect to a data modeling tool; | P28 | |
| create or open a data model specified in the configuration settings; and | P28 | |
| create elements in the data model. | P28 | |
Corresponding to System Claim 4 and Method Claim 14.
9. Transformation*
| The non-transitory storage medium of claim 5, wherein the instructions populate the ontology metadata sets with extracted ontology metadata further comprise instructions that cause the one or more processors to: | ||
| select, preview and modify transformation rules; | P12 | |
| specify a scope of source ontology metadata; | P24 | |
| review the metadata; and | F10 | |
| correct and override metadata. | P13 | |
Corresponding to Method Claim 15.
10. Reverse mode
| The non-transitory storage medium of claim 5, wherein the instructions populate the ontology metadata sets with extracted ontology metadata further comprise instructions that cause the one or more processors to: | F23 P30 | |
| enable a user to configure settings for a transformation of elements of a data model into elements of an ontology; | P32 | |
| populate the modeling tool-specific metadata sets with extracted data model metadata; | P32 | |
| populate the entity-relationship metadata sets by transforming metadata from the modeling tool-specific metadata sets; and | P33 | |
| populate the ontology metadata sets by transforming metadata from the entity-relationship metadata sets; and | P33 | |
| generating SPARQL construct statements to create an ontology schema; and | P34 | |
| whereby a coupling of metadata sets and computer instructions makes said metadata sets self-populating in a reverse direction, transforming data model metadata into ontology metadata. | P19 | |
The specification teaches about the Reverse Mode:
The Reverse Mode is a specific embodiment, enabling a user to transform a data model into an ontology. The use case for ontologies reverse-engineered from data models is twofold: First, to enhance an enterprise ontology with content from an enterprise or subject area data model, and second, to create an ontological representation of an operational system for knowledge graphs. P17
By design, the metadata sets are by-directional. That means the MDS columns for Ontology and Data Modeling Tool are the same, regardless of whether a Load or Extraction component utilizes the MDS. The columns of the generic Entity-Relationship MDS do not change if the set populates from a Tool-Specific MDS instead of the Ontology MDS. Only the population queries and formulas must change to enable a reverse direction. P31
11. Method
| A computer-implemented method, comprising: | F4 P14 | |
| enabling a user to configure settings for a transformation of elements of an ontology into elements of a data model; | F18 F19 F21 | |
| extracting ontology metadata and convert the ontology metadata into ontology metadata sets; | F20 P15 P25 | |
| transforming the ontology metadata sets into entity-relationship metadata sets; and | F21 P16 | |
| transforming the entity-relationship metadata sets into modeling tool-specific metadata sets; | F22 P25 | |
| whereby a user can transform an ontology into a data model. | F1 | |
While the Metadata Sets of the Storage Medium Claim 5 define the structure and design, the method teaches coupled computer processes to populate them.
12. Connect to an Ontology Platform
| The computer-implemented method of claim 11, wherein extracting ontology metadata and converting the ontology metadata into ontology metadata sets further comprises: | F20 | |
| connecting to an ontology platform; | P26 | |
| opening a source ontology specified in the configuration settings; | P26 | |
| executing SPARQL metadata queries; and | P18 | |
| retrieving query ontology metadata. | F5 | |
Corresponding to System Claim 2 and Storage Medium Claim 6.
13. Parsing Ontology files
| The computer-implemented method of claim 11, wherein extracting ontology metadata and converting the ontology metadata into ontology metadata sets further comprises: | T19 | |
| opening an ontology file or Namespace URI; | P29 | |
| parsing the ontology to extract ontology metadata; and | P29 | |
| analyzing parsed ontology structure and populate the ontology metadata sets. | P29 | |
Corresponding to System Claim 3 and Storage Medium Claim 7.
14. Connect to a Data Modeling Tool
| The computer-implemented method of claim 11, wherein extracting ontology metadata and converting the ontology metadata into ontology metadata sets further comprises: | F22 P12 | |
| connecting to a data modeling tool; | P28 | |
| creating or opening the data model specified in the configuration settings; and | P28 | |
| loading tool-specific metadata sets into the data modeling tool, creating elements in the data model. | P28 | |
Corresponding to System Claim 4 and Medium Claim 8.
15. Modify Transformation Rules
| The computer-implemented method of claim 11, wherein extracting ontology metadata and converting the ontology metadata into ontology metadata sets further comprises: | F10 | |
| selecting, previewing and modifying transformation rules; | P12 | |
| specifying a scope of source ontology elements; | P24 | |
| reviewing metadata; and | F10 | |
| correcting and overriding the metadata. | P13 | |
Corresponding to Storage Medium Claim 9.
16. Reverse mode
| The computer-implemented method of claim 11, wherein extracting ontology metadata and converting the ontology metadata into ontology metadata sets further comprises: | F23 | |
| enabling a user to configure settings for a transformation of elements of a data model into elements of an ontology; | P32 | |
| generating a list report in a data modeling tool to populate the modeling tool-specific metadata sets; | P32 | |
| transforming the modeling tool-specific metadata sets into entity-relationship metadata sets; | P33 | |
| transforming the entity-relationship metadata sets into ontology metadata sets; | P33 | |
| executing SPARQL construct statements on an ontology platform to create the ontology; and | P34 | |
| whereby a user can utilize metadata sets in a reverse direction and transform a data model into an ontology. | P30 | |
Corresponding to Medium Claim 10.
USPTO Certificate of Correction
The patent published on the USPTO website and Google Patents erroneously states that claim 9 depends on claim 7.
On 8 October 2024, the patent office issued a Certificate of Correction to correctly state that the dependency is on the independent medium clam 5 as on this page.