CODT is the technology that created the Financial Industry Business Data Model (FIB-DM) from the industry-standard ontology, FIBO. The United States Patent & Trademark Office (USPTO) has issued patent #12038939 for CODT. Due to their exacting structure and format, patents are difficult for engineers to read and understand. This practical CODT Patent overview is for data architects and ontologists. We discuss USPTO requirements and CODT patent claims. The video shows a user-friendly version of the patent specification with embedded color drawings on this website.
The Presentation below has static pages with screenshots instead of the live website browse.
You can download a PDF version of the PowerPoint presentation.
Transcript
Welcome back. This is Jurgen with his patent, the Configurable Ontology to Data Model Transformation (CODT).
With CODT, we transform industry-standard ontologies like the FIBO and in-house ontologies into
data models. And we can reverse-engineer our existing enterprise models into RDF/OWL.
We have an overview of the CODT patent with its resources and requirements.
The FIBO is the authoritative model of Financial Industry concepts, their definitions, and relations.
The EDM Council is the global association of more than 100 financial institutions. It teaches Data
Management best practices and develops data standards. One of these standards is FIBO.
EDMC members, in other words, banks developed the Financial Industry Business Ontology, FIBO, as
a business conceptual model. Its latest version has more than 2,300 classes detailing financial products, services, business entities, and processes.
The Financial Industry Business Data Model, FIB-DM, is derived from the FIBO, and more than 3,500 users have downloaded the open-source version of the data model. The Configurable Ontology to Data model Transformation is the technology that created the FIBO Data Model, and the United States Patent and Trademark Office, the USPTO, has issued a patent for CODT.
During patent search and examination, I had to study half a dozen patents, and I found it very challenging to understand them. That is due to the very exacting nature of drawings and the specification text.
This practical patent overview is or ontologists and data architects. We look at the patent’s purpose, and
structure, the distracting USPTO format, and the user-friendly CODT patent resources. Also, we discuss how CODT exceeds the USPTO requirements, which makes it a very strong patent.
Patentability: So, as per the United States code, a US patent grants the owner the Exclusive Right to prevent others from making, using, selling, or importing the invention. If the invention is a process, these rights also extend to products made using that process. In other words, it extends to FIB-DM.
And to be issued a patent, according to USPTO, it must meet four conditions:
• Utility must be practical, not just a mere idea or theory.
• It must be non-obvious, a true invention, and not just a tweaking or improving of something that already exists.
• Be a novel, meaning not described before. Here, the examiner searches for so-called “prior art” in Patents, academic papers, and other publications.
• Finally, its description must be clear, following the exact USPTO requirements.
A patent is structured in three parts: the Claims, Drawings, and the Specification.
The “exclusive rights” only pertain to the claims. If it’s not claimed, it’s not protected. Software inventions typically claim a computer System, a storage Medium, and a method.
The drawings illustrate the claims. For example, here’s Figure 2, a UML system diagram showing the Key Claim Terms, configuration, extraction, transformation, and load as components.
The specification explains the drawings. So, a section in the detailed specification explains the diagram objects and their connectors and how they work together.
When the USPTO says “clear description,” it means a very exacting format. Here we are on the USPTO website with the detailed description. As we can see every paragraph has to start with a number.
And then we have all these numerals within the text. They actually refer to the same label in the drawing.
If we look at Google Patents, which has a slightly better rendition, we can see the drawings. First, they are all in black and white, then again, they have these numerals and some are upside down and so on.
It is necessary certainly for an unequivocal communication between Examiner and patent Applicant, as well as in patent litigation. However, it makes it really hard for a computer engineer to read a patent.
So, the patent resources are meant to supplement the official publication on USPTO and Google Patents. At the bottom of the page, you find links to the specification claims and drawings.
If we look at the patent specification, you will see that, first of all, it doesn’t have the numerals in the text. You can see here, Actually, the figures are embedded like we would in a design document.
The next link here, if we look at the drawings, there’s a gallery of all the drawings, that you can print. If you click on a drawing (here is a screenshot of a Metadata Set), you get it in high resolution and in color.
The latest here would be if we look at the claims. So, here is the claims page with an introduction. Let’s look at the system claim here. What you see here, right to the paragraph in the claim, is a link.
F stands for figure. If we click on this, it takes us right into the patent specification.
Likewise, if we click on the paragraph, it takes us over there.
Finally, if we click on the T, T stands for table. It will take us to the table in the patent specification.
Yeah, so let’s go over the patentability requirements.
First was utility: it has to be practical and useful. Well, here I guess 3,500 users who downloaded FIB-DM attest to that. They find an ontology-derived data model that preserves the complete RDF/OWL semantics and annotation properties useful. The success of FIB-DM is due to its quality compared to a rudimentary ontology to data model transformations. What I asked myself at the time was, how would I as a data architect design a perfect data model based on the industry standard? And the answer is like in the FIB-DM diagrams. Like this: I would do entity names based on the naming standard, associative entities,
not mere relationships derived from object properties, and resolving the very complex RDF/OWL semantics.
Like class restrictions and inverse properties.
Yeah, so utility, the background section in the specification. And here, the Manual of Patent Examination and Procedure says that It should first describe the field of the invention and then provide a description of “Related Art.” So the CODT background explains model-driven engineering,
data modeling tools, and the importance of data model transformation, giving an example that
we all know: We transform LDMs to Physical Data Models.
The specification acknowledges that some data modeling tools like Sparx EA or IBM IDA provide an import of RDF/OWL files and subsequent transformation, and it also points out their shortcomings. In other words,
These are our requirements for FIB-DM and CODT. So, they don’t enable the users to change the mapping and transformation rules. In particular, we cannot apply a naming standard. In other words, it’s a press one button, and no configuration. And per default in these tools, object properties transform into data model relationships, and this is wrong. Because it loses metadata for particular design patterns, like hierarchies of object properties.
If you want to look at this closely, you can see my article “Ontology Object Properties are data model
Associative Entities – not relationships.”
Traditional transformations parse ontology files. They encounter elements of the ontology and create elements in the data modeling tools, as they process the source files. The parsing approach reaches its limit with very large ontologies like the FIBO. Now, the FIBO has 250 RDF/OWL files. Frankly, when I tried it, some of the tools just crashed on me.
So, the invention must be non-obvious and novel. Here, basically, the parsing approach has reached its limits. I think it cannot be tweaked or improved to produce anything like the FIBO Data Model.
Now, the solution to that problem is a radically different approach: CODT uses SPARQL to extract ontology metadata from an ontology platform, in other words, an RDF store. It transforms ontology metadata into standardized Metadata Sets. That gives us a holistic view of the ontology. In other words, I have one Metadata Set that shows me all the classes, all the object properties. And then I can deal with challenges
like duplicate names or inverse properties.
CODT works in “set operations” rather than procedural algorithms. In other words, it’s a 4GL language, an ETL language. That, of course, is much clearer and descriptive than procedural coding.
Metadata Sets require that we configure settings for our transformation rules and provide overrides.
In reverse, a fully configurable transformation needs Metadata Sets. It does not work with file-by-file parsing.
Yeah, um, claim structure: In most software patents, the Method is the central important claim makes sense intuitively. The Method that’s the process or the algorithm. And then the other claim types, like the System, merely “implements the method,” and the “medium stores the computer code.”
Now, in CODT, the Metadata Sets are the central innovation. Hence, the Medium claims are most important. Because the CODT approach is basically ETL, extract, transform, and load. That reflects here as
Table 1 of the specification shows the components. We have different components, different Excel workbooks for extraction, transformation, and load. The Metadata Sets for Ontology, generic E/R, and specific data modeling tools, implemented in the first embodiment as separate Excel workbooks.
Well, summary and conclusion:
We looked at the FIBO Data Model, the transformation technology, the United States Patent and Trademark Office requirements, and we looked at the FIB-DM patent resources, which make it easier to read and understand the patent. Finally we took a look at the CODT claims for System, Method
and Medium. Of course, if you like to read more details, look at codt.net/patent.
And then, of course, consider licensing the patent rights and the CODT application.
Thanks for watching