Researchers Submit Patent Application, “Entity Centric Database”, for Approval (USPTO 20210303644): Patent Application

2021 OCT 19 (NewsRx) -- By a News Reporter-Staff News Editor at Insurance Daily News -- From Washington, D.C., NewsRx journalists report that a patent application by the inventor Shear, Timothy A. (Novi, MI, US), filed on March 28, 2020, was made available online on September 30, 2021.

No assignee for this patent application has been made.

News editors obtained the following quote from the background information supplied by the inventors: “

“Field of the Invention

“The invention relates generally to data storage and processing by a digital computer, particularly to database systems on a shared cloud platform, and more particularly to methods of ensuring data security without compromising efficiency.

“Description of Related Art

“Many efforts have been made to defend against hacking and security breaches of computer databases without sacrificing convenience and functionality. Efforts have focused on enhancing security measures to defeat hackers, such as robust credential verification and data encryption, but databases remain vulnerable to persistent and prolonged efforts to obtain data behind the security barriers. The approach of the prior art is analogous to erecting taller, thicker walls around the castle to defeat attempted breaches.

“The problem takes on a new dimension as technology moves to the Cloud platform model, which offers services through a network platform exposing access and service through the network to outside or external endpoints. Typical services supported by Cloud platforms are Database-as-a-Service (DaaS), Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and many other ‘as-a-Service’ offerings. As access points to the platform proliferate, defending against attacks such as hacking and ransomware becomes more difficult, and layering additional security layers can result in inconvenience and inefficiency.

“Meanwhile, the majority of databases are structured as “relational” databases which require schema, e.g. “last name” “birthdate” “blood type” to be arranged in tables of rows and columns. The query/retrieval language SQL (Structured Query Language) forms the basis of all relational database access. Such design and access restrictions can constrain the ability of real world entities to store data optimally. An example of one such database is U.S. Pat. No. 8,793,768 “Relationship-Based Authorization” (Beck). Beck uses rows and columns in a table to store relationships (e.g. ‘768 FIG. 4), and consults those relationships as part of a “front end” to control access to documents stored in an otherwise conventional database.

“Newer database designs include nonrelational databases, increasingly known as “NoSQL” (Not only SQL) such as MongoDB, Couchbase, CouchDB, Marklogic, AWS DynamoDB, Microsoft Azure DB and other Key/Value database products wherein data components are not organized as tables, but as “keys” associated with “values.” (Sometimes referred to as “tags” associated with “values.”). Such database models are more conducive to the hierarchical mode of organizing familiar to humans, such as domain/class/entity/collection, e.g., FairviewHospital/patients/JohnSmith/testresults. However, databases such as MongoDB and CouchDB have their own shortcomings. For example, to speed up queries these databases require a priori definition of fields to index. This requires stored data to conform to the indexing parameters. Documents that do not have the field in the index specification will not be included in indexed queries. In other words, databases built using MongoDB and CouchDB are schema-specific.

“There is a need for a database that provides a reduced attack surface and accessibility of the cloud, impregnable security, flexible and schema-agnostic access, and entity control over its data.”

As a supplement to the background information on this patent application, NewsRx correspondents also obtained the inventor’s summary information for this patent application: “Disclosed is an entity-centric, domain-partitionable, custodian-controlled database platform. Posting, query and retrieval of a data is bound to unique, unidirectional (one-way) “relationship identifiers” that identify the relationship access privileges between, for example, an entity requesting access to a document pertaining to a targeted entity. For example, if entity1 is a doctor and entity2 is a patient, the platform assigns a unique Relationship Distributed Identifier (RDID) the doctor would use when he posts a document pertaining to entity2’s lab test result. Each component of information from every document ingested into the platform retains the RDID and entity information provided at the time the information was ingested. Therefore, the database presents as entity-centric, i.e., structured around entities and their relationships.

“Access to the platform is generally through a network such as the internet or intranet preferably using hierarchical HTTP Uniform Resource Identifiers (URI). This allows domain-driven design for consistent and yet flexible data modeling of the enterprise’s data. For example, the platform may be accessed by a standard REST Resource-oriented Application Program Interface (API) using familiar HTTP (or HTTPS) verbs GET and POST. Data queries can thus be a simple “path” definition in the API call. This allows expression of the RDID directly in the hierarchical path, e.g., domain/class/RDID/collection. Collections of like data elements are organized as “aspects” within the data hierarchy of the entity, including features such as demographics, events, readings, etc. As every field is addressable, the invention allows fast ad hoc queries because there is no need to specify indexing parameters.

“The database is overseen by a trusted Data Custodian Platform. The Data Custodian Platform may be a local, entity-owned service, or a contracted service provided by a cloud provider. The Data Custodian Platform administers entity data, access and updating. The Data Custodian Platform accepts privacy rules from an entity which the platform uses in any access/update operation. These privacy rules may also be used to insulate sensitive data from queries submitted to the database, including queries submitted to the data platform’s entity data store(s) (hereinafter “data store set” or simply “data store”) and may further depend on the role of the requestor. This ensures transparency to the entity data while respecting the privacy context desired by the entity.

“Data pertaining to an entity comprises resources or addressable values that are arranged in a hierarchical structure rooted at entity domain, many of which the entity may belong, preferably consistent with the real-world entity that is being represented. These resources are further arraigned into groupings or sets of related resources called ‘aspects’ or collections. Additionally, aspects may be ‘virtual’ and/or ‘compositional’ where multiple physical or virtual aspects are combined into a named virtual aspect. A sample aspect could be ‘demographics’, i.e., the identifying characteristics of the entity. Again, FairviewHospital/patients/JohnSmith/testresults is an example. An example from the realm of devices and the Internet of Things might be companyx/temperature-sensors/thermo26/reading s.

“In summary, the invention presents a trusted platform or service which is domain partitionable, entity-bound, entity-relationship-centric, self-sovereign identity, order-preserving, immutable, schema-agnostic, and resource-oriented, and which can be used on cloud services, and which is readily adapted to data concerning people, groups, businesses, devices, and/or microservices. There is a largely unmet need for an infrastructure to manage data and privacy/security from an entity-centered platform. Industries that would benefit from such an infrastructure include the healthcare domain, customer management and relations (CRM), personal finance and banking, DLT (Distributed Ledger Technology) ledgers, military and defense, and governmental agencies such as Medicare/Medicaid.”

The claims supplied by the inventors are:

“1. A method of storing documents in a database platform configured to send and receive data over a network, comprising: connecting a first entity to the platform via the network; receiving, at a server connected to the network, a request from the first entity to establish a relationship with a second entity; assigning a unique and unidirectional Relationship Distributed Identifier (RDID) for the relationship; and requiring the first entity to include the RDID in a Uniform Resource Indicator (URI) path in order to post a document on the platform pertaining to the second entity.

“2. The method of claim 1, wherein the database platform receives the URI from the first entity via a third-party computer application.

“3. The method of claim 1, further comprising ingesting a posted document at the server, wherein the ingesting comprises immutably associating data from the ingested document with the first entity and with the second entity.

“4. The method of claim 3 wherein the database platform uses a cloud-based service connected to the network to perform one or more of the ingesting steps.

“5. The method of claim 1, further comprising ingesting a posted document at the server, wherein the ingesting comprises parsing the posted document into a plurality of data components having a Common Hierarchical Format (CHF), the plurality of data components comprising CHF data; generating a meta header based on the CHF data, wherein the meta header comprises Key-Value (KV) information regarding the URI path and a document ID (DocID) that uniquely identifies the posted document; and storing the CHF data as a CHF document at one or more data stores connected to the network.

“6. The method of claim 5, comprising the further step of sharding the CHF document, and the storing step further comprising storing the sharded CHF document at two or more data stores.

“7. The method of claim 5, wherein the URI path is hierarchical and comprises a domain and at least one sublevel component, and wherein the platform immutably associates the CHF data with the RDID, with the domain, and with the at least one sublevel component.

“8. The method of claim 1, further comprising generating the RDID by hashing a combination of inputs comprising: first entity identity information and second entity identity information.

“9. The method of claim 8, wherein the combination of inputs further comprises a secret system value known only to the platform.

“10. The method of claim 8, wherein the hashing comprises using transform algebra operating on a plurality of inputs to generate the RDID as an icon.

“11. A non-transitory computer-readable medium having stored instructions that cause one or more servers in communication with a database platform to perform the following operations: connecting a first entity to the platform via the network; receiving from the first entity a request to establish a relationship with a second entity; assigning a unique and unidirectional Relationship Distributed Identifier (RDID) for the relationship; requiring the first entity to include the RDID in a Uniform Resource Indicator (URI) path in order to post a document on the platform pertaining to the second entity; parsing a posted document, with a format-determined parser, into a plurality of data components having a Common Hierarchical Format (CHF), the plurality of data components comprising a CHF document; storing, at a first data storage location connected to the network, Key-Value (KV) information regarding the path and a document ID (DocID) that uniquely identifies the CHF document; and storing the CHF document at a second data storage location comprising one or more data stores connected to the network.

“12. The computer device of claim 11 further comprising a step of hashing at least a portion of the posted document.

“13. The computer device of claim 12, wherein the CHF Document comprises: hashes of the natural keys resulting in hashed CHF key data, and hashes of the natural values resulting in hashed CHF value data.

“14. The computer device of claim 13 wherein the posted document comprises natural keys and associated natural values, and wherein the CHF document comprises the KV information regarding the path and the DocID and further comprises a dictionary that associates the natural keys to their hashed CHF key data, and that associates the natural values to their hashed CHF value data.

“15. The computer device of claim 11 wherein the CHF document is encrypted prior to storing.

“16. The computer device of claim 11 wherein the database platform is a nonrelational database.

“17. A method for securely storing and retrieving document data in a database platform configured to send and receive data over a network, comprising: ingesting a document, in response to a first URI received from a first entity, wherein the document comprises natural keys and natural values and wherein the first URI comprises a first RDID that uniquely and unidirectionally defines a relationship between the first entity and a second entity; parsing the document into CHF data components; hashing the natural data components to produce hashed CHF data components; storing the hashed CHF data components in a data store connected to the platform via the network.

“18. The method of claim 17 comprising a step, after the storing step, of receiving a query from the first entity comprising a second URI, the second URI comprising the RDID, to get some or all of the natural keys and natural values in the ingested document; and searching the stored hashed CHF data to derive, from the hashed CHF data, results that satisfy the query.

“19. The method of claim 18 wherein the searching step ignores the document and any natural copies of the document.

“20. The method of claim 17 comprising a step, after the storing step, of receiving a query from the first entity comprising a second URI to get some or all of the natural keys and natural values in the ingested document wherein: the second URI does not comprise an RDID but does comprise a hierarchical path comprising at least a domain and a class; and searching the stored hashed CHF data to derive, from the hashed CHF data, results that satisfy the query.”

For additional information on this patent application, see: Shear, Timothy A. Entity Centric Database. Filed March 28, 2020 and posted September 30, 2021. Patent URL: https://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220210303644%22.PGNR.&OS=DN/20210303644&RS=DN/20210303644

(Our reports deliver fact-based news of research and discoveries from around the world.)