Patent Application
20200012745
The present invention relates generally to the field of computer science and information technology, more specifically to natural language processing (understanding), database technology, encryption, and document management.
Natural language interfaces that utilize either voice recognition or any other form of text input are becoming commonplace and are being applied in many different domain areas. The most common products available today include virtual assistants such as AMAZON ALEXA™, APPLE SIRI™, and GOOGLE ASSISTANT™, but the underlying technology is also pervasive in voice driven chat bots commonly used in customer service web sites.
The literature historically has used the term “natural language processing” to mean any processing that occurs on input text that could be sourced from a speech recognition system or any text input device such as a keyboard. In this application, the term “natural language understanding” is used to more clearly mean more than mere processing, but added semantic processing that adds meaning and context to the input words. Further, a “natural language interface” is any interface that accepts any form of linguistic textual input where natural language is a primary (or only) input source.
There are two key problems with the state of the art technology in natural language interfaces coupled to database queries and transactions that the present invention addresses:
First, implementing a natural language interface in a new domain can be time and resource intensive because the system must have deep contextual knowledge about the subject matter in order to carry on a natural “conversation” with the user. When people speak to other people, we commonly do not use the same words in exactly the same way, and yet we understand each other because we are able to dynamically map new words or new meaning for known words onto known words with known meanings. These computer-based systems have to build that knowledge before such mappings can take place. Also, the knowledge, when built this way, tends to be fragile where mistakes are common.
The present invention provides a way to build language context independent of the application domain, such that it can be used to quickly develop context awareness in a new domain. Because this context is persistent and cross-domain, it also tends to be far more robust than current solutions to this problem.
Second, most of these systems rely on access to databases in order to respond to the user's natural language queries. A common problem with such databases is securing their contents. Modern database security consists of mechanisms for securing the entire database structure usually by securing access to the database itself. Even if the contents of a database are encrypted, if access to the database is breached, that person or system will usually have access to the unencrypted data stored therein. This fundamental flaw in modern database technology has been the root cause of untold damage due to data breaches.
The present invention solves this critical problem by moving the encryption layer to the field level within a table and separating functions (also at the field level) of data storage and access. This solution fundamentally changes the way the database is structured and where the data can be stored.
There are many different methods and approaches to enable a computer to recognize speech, including:
There are pros and cons to all the known methods, and while they are all able to perform reasonably well within their specific implemented problem domain, on their own, they are rarely able to do a complete job. The Natural Language Understanding (NLU) engine in the present invention takes a hybrid approach using a selection of methods and combining them into a single process. This methodology enables the NLU to be accurate, have faster implementation times, and requires a much less time-consuming learning curve than other more static approaches.
Databases have a long and useful history, dating back to millennia past when humans first started to place lists onto stone tablets. Modern databases of the computer age started to come to light in the late 1960s with the Navigational Database (see https://en.wikipedia.org/wiki/Navigational_database). These began with the rise of magnetic media for storage. In the early 1970s the first Relational Databases (RDMS) (see https://en.wikipedia.org/wiki/Relational_database) started to come into use, and today these are still the predominant database structure in use in the marketplace. Moving into the late 1970s and early 1980s, a method to query a database took hold (Structured Query Language, or SQL) (see https://en.wikipedia.org/wiki/SQL) and simple standard querying of data was now possible. In the 1990s came Object Databases (see https://en.wikipedia.org/wiki/Object_database) and in the 2000s In Memory Databases (see https://en.wikipedia.org/wiki/In-memory_database).
Despite the impact that technical evolution has had on database technology, the use for any database has not fundamentally changed—its purpose is still to store data for subsequent retrieval. However, in the early 2000s something important happened to that data. Primarily due to inexpensive mass storage, the quantity of data stored in databases exploded. The amount of data that was being collected, stored, queried and analyzed is now on a massive scale that is orders of magnitude larger than envisioned when early concepts of databases were developed. Also, this data itself now has intrinsic monetary value. So much value in fact, that the data itself is being stolen to be sold to the highest bidder, as evidenced every time there is a major data breach.
The current dated systems of databases are not able to keep up with this trend. While the majority of them are able to encrypt the data stored, this encryption is carried out in such a way that anyone (human or machine) that has access to the system at any administration level generally also has access to the plain unencrypted data. There is essentially a single point of failure at the door to the database. This design flaw has allowed many millions of dollars to be stolen in the last few years from many different and diverse organizations.
Database security and how data held within a database is secured is under increasing scrutiny. As such, a new approach to data storage is required. The approach must enable the same easy access that has proven to work well over the past two decades with SQL. It must also be able to integrate and migrate data to and from other databases, but also should re-think how data should be stored, what access privileges should be granted and how they should be granted, and how to enable data migration without data compromise.
The In-Memory Secure Database disclosed herein is the solution to this problem. By taking the encryption layer and placing it into the database field and splitting the field into separate items to manage not just the data, but also its metadata and the structure, the system maintains access to the rules which enable modern applications to run.
The present invention addresses security problems pertaining to transactions with databases and also the problem of people interacting with applications and databases using natural language.
The present invention solves the database security problem by shifting security concerns to the field level. An external application transmits a signed and encrypted query to the communication layer of the system using a dynamically allocated port that is created by the communication layer especially for this query transaction. On arrival at the communication layer, the query is checked for signature and it is passed to the SQL engine where it is parsed to form a valid SQL query. The SQL engine then requests another dynamically allocated port to the database structure which it uses to send the query to the database structure where it is verified. The database structure then uses the table structure to determine the relevant tables needed for this query. The table layer retrieves the necessary fields. The fields themselves actually determine whether or not access to their data will be allowed. They contain access control of their own access key and an encryption engine for encrypting and decrypting their data which is pointed to via a data pointer. The data need not be stored within the database itself.
The natural language problem is solved using a natural language understanding system that processes input linguistic text similarly to the way humans process natural language. The process begins by determining whether the input is a valid question or command. If the system does not recognize the input type, then it will ask the user to re-phrase their query. The system contains a context recognizer that can disambiguate input text streams when imprecise words are used intended to mean a specific thing. The system then determines if the entities in the input stream are valid subjects of a query that can be formed and send to a database for processing. If they are not, the system will again ask the user to re-phrase their query and it will learn what new words map to known words in its entity type table. This table can be stored in a persistent store to facilitate fast transition to new topic domains for new application areas. Finally, the system accesses the database with the query and reforms the response into natural language in a format expected by the user.
The secure database is a preferred solution for several reasons. The dynamically allocated ports greatly reduce the possibility of unauthorized access. The database requires far less memory and processing and less management of the database itself because management has been pushed down to the field level. Data migration is far easier because fields can be handled independently of the table in which they reside.
The natural language system is a preferred solution because it can immediately differentiate between commands and questions coming from the user. The ability to determine context allows users to talk more naturally where the system is able to figure out what objects and relationships they are referring to by using past contextual statements. The system also allows users to use different words to mean the same things, as people normally do, by maintaining and learning matches between known words and incoming new words.
Securing access to databases has been a problem for as long as there have been databases. The advent of web-based applications and more recently, voice (natural language) interfaces as a means to access those databases raises unique problems.
A standard database requires a number of things to take place if it is to access encrypted data:
However, a key feature of the present invention is that it only requires either:
As shown in
This means that the database service requires less memory and processing power, less management of resources for the database itself, and controls field level access of data down to an individual or device. The power of this is that there can be multiple IoT (Internet of Things) devices accessing a single database and table, yet each may only access a single field managed by that database regardless of the SQL query that has been sent.
This provides a more secure and granulated result set to be used within IoT and Artificial Intelligence applications. In addition, the present invention uses dynamically allocated ports (104), further reducing the likelihood of successful attacks.
Communications Layer (103): This layer manages how a query accesses the database. It manages the flow process. It does not manage access to the data held or to any pointer to data (115), but only to the physical service. It is itself a Containerized Memory Block, which when called as a service, will open a TCP port to enable a single, one-time connection from the calling application (101). It will only accept digitally signed requests and can block all access to the underlying database structures and data.
SQL Engine (106): This is a standard SQL engine that recognizes a number of SQL 92 compliant commands, including commands to query, create and modify tables and data. The SQL engine is the only access available to the database structure (107).
Database Structure (107): Each database that the server creates has a structure block. Like the Communications Layer, this is a Containerized Memory Block, which also shares the ability to manage dynamic port access. However, unlike the Communications Layer, the Database Structure will only allow access from the SQL Engine. This means that any attempt to bypass the SQL Engine to read the data directly will fail.
Table Structure (108): A database is made up of one or more tables. The Table Structure is the housing for each table within a database. It manages the database fields and makes sure that all database integrity requirements are maintained. Tables are an essential component of the database and are a key mechanism by which SQL queries identify which fields fit the limitations of the query. Note that while table structure is essential to data access via an SQL query, no data is held at the table level nor is access controlled at the table level.
Field (109): The Field is where the data access and control takes place. It is not necessarily where the data is stored, but is more like a door with its own lock to allow access to the data. While it is preferable to store the data external to the field via the data pointer (115), the data may be contained in the field. Each field is held within its own memory block while being an object within a parent table. Each field contains the following set of elements:
The following describes the data flow of the invention starting with a call from an external application requesting access to data held within the secure database and ending with either denial of access or the execution of the access request if allowable (see
The present invention brings a new approach to database storage having several unique benefits:
Most implementations of natural language processing (NLP) rely on the implementer and user to input questions and/or a mass of documentation to enable the system to digest, learn and create a library of syntax and understanding prior to implementation. While these systems may have some capacity for learning, the majority of the knowledge and context for the application is created during implementation. Additionally, post implementation (at runtime), the system has to learn and continue to digest information for an extended period of time to be able to understand what it is the user is looking for, with the desired end goal being a natural language dialog with the user that always responds correctly.
The present invention is different in that it creates a database which houses only basic information that enables the NLP engine to have an almost instant understanding of context. This is referred to as the “Memory Cortex.” Its role is to speed up the task of processing the text that comes from the user, and subsequently enabling the process of rapidly determining what it is that the user wants.
The Memory Cortex: This is an In-Memory database that manages the process—both the learning Artificial Intelligence (AI) and the Natural Language Processing (NLP). It consists of a number of tables, which include:
Key Word Question: Used to tell the system what input words indicate that a question is being asked. Examples of these words in the English language include:
What
Where
Who
When
How
Why
Tell Me
Key Word Command: Used to tell the system what words correspond with specific commands. Examples of these words in the English language include:
Update
Set
Can you
Create
Context Awareness: Used to let the system know if a context requirement is needed. A context requirement is one that may require a follow-on task without the initial question or command being repeated. This occurs very frequently in natural language where context is required to disambiguate meaning. As a non-limiting example:
1) User Input: “Can you tell me what the current situation is with invoice number 2144?” [Here, the system initiates a query into the database to request status on invoice 2144.]
3) User Input: “What date was payment made?”
[Note that the user did not state the invoice again, thus it is ambiguous and must be determined using context awareness. Context awareness is able to replace the ambiguous target invoice with “2144” using the previous query, which is then used to initiate a new query as to the date of payment for invoice 2144.]
The present system handles context awareness in a number of ways, which include the Context Awareness Table to temporarily hold certain non-traceable events if needed in subsequent events.
It can also be seen in the example above that there could be a conflict between the Key Word Question and the Key Word Command inputs where the “hints” provided by the associated tables (503 and 504) do not agree. The system will take this into account and look at other data points, such as entity placement within the input, to resolve which is being called for.
Entity Types: This table is used to map key words to a back-end database or system that holds the data required. These types can be saved in a persistent data store for use in other applications which also serves to speed up learning time in those new applications. In the example above, the entities could have been:
Invoice
Payment
Entity Types Learnt: This is a table that holds new entities that map to entities within the Entity Types table (or the persistent store as mentioned above). It is populated when a request comes in that is not recognized. The system then asks the user to restate the query in a different way. If it finds an entity that maps to the new entity, it will map the original to it, and any subsequent use of the new entity will now be understood. As a non-limiting example:
Post Processing: Used to enable the system to do post processing on a response to make the response more human readable or conversational in nature. As a non-limiting example:
If a response came from a database and the field held a height, the system may convert the height from inches to feet if that is what the user would expect. In this instance, the post processing table would hold three items of information:
Table and field details that it will post-process: Height
Post Processing type: Math Translation
Post Processing Math Type: Divide
Post Processing Math sum: 12
The result is that the system will divide the data in the field by 12 to yield the response in feet and will return that result for presentation to the user.
Prefix: This table holds any prefix needed for a specific response, also for the purpose of making the response more human readable or conversational in nature. As a non-limiting example:
As in the example above, the system may add the word “Feet” to the answer to improve the presentation to the user. In this instance, the Prefix table would hold the following data:
Table and field details to which it will apply the prefix: Height
Prefix data: Feet.
The following describes the process flow of the natural language understanding component starting with the input from a user through to the response by the system. (see
The present invention melds NLP together with AI to form Natural Language Understanding (NLU). The problem of accepting linguistic input and responding in a natural and correct way is not new. The approach in the present invention is new in a number of ways, including:
The request first enters the secure gateway (603) that immediately separates the request from the originator by terminating the connection by which the request was made. This is done to secure the system from subsequent actions by the requestor. As noted above, the system utilized container encrypted memory sessions.
Next, the request is passed to the AI engine (604) that performs any threat analysis on the incoming data as well as performs any payload reshuffling which allows for this system to be scalable for any size application.
Next, the request is passed to the AI connector (605) which is where the NLU system described above resides. The request is processed to determine its meaning and the intention (expectation) of the user. If any other assets are needed for this application (such as external or third-party databases), those transactions are brokered here.
Finally, the data transaction is performed via the secure database described above. The result of the request is then passed back through all three segments of the system (605, 604, 603), and finally back to the requestor.
The present invention has two key components each of which has industrial application. The secure database is useful in any data intensive industry requiring secure data transactions or where data transactions need to be lightweight requiring less processing power and memory. The natural language understanding component is useful in any industrial application where users will interact with a data system with natural language, spoken or non-spoken.
