EP3563261B1 - Bitsequenzbasiertes datenklassifikationssystem - Google Patents

Bitsequenzbasiertes datenklassifikationssystem Download PDF

Info

Publication number
EP3563261B1
EP3563261B1 EP17826526.0A EP17826526A EP3563261B1 EP 3563261 B1 EP3563261 B1 EP 3563261B1 EP 17826526 A EP17826526 A EP 17826526A EP 3563261 B1 EP3563261 B1 EP 3563261B1
Authority
EP
European Patent Office
Prior art keywords
data
tokens
index
field
bit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP17826526.0A
Other languages
English (en)
French (fr)
Other versions
EP3563261A1 (de
Inventor
Ilya Komarov
Manfred Paeschke
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bundesdruckerei GmbH
Original Assignee
Bundesdruckerei GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bundesdruckerei GmbH filed Critical Bundesdruckerei GmbH
Priority to EP21153224.7A priority Critical patent/EP3889806A1/de
Publication of EP3563261A1 publication Critical patent/EP3563261A1/de
Application granted granted Critical
Publication of EP3563261B1 publication Critical patent/EP3563261B1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/906—Clustering; Classification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
    • G06F16/51—Indexing; Data structures therefor; Storage structures

Definitions

  • the present descriptions relate to IT systems and in particular classification methods in the context of database management systems.
  • documents or data sets can be classified based on the words they contain.
  • the individual words within a document are automatically recognized using a text analysis algorithm.
  • co-occurrence-based methods the documents are classified into classes of similar documents depending on the type and/or number of words they contain together.
  • digital image data is first analyzed in a complex manner in order to identify certain structures (cell membranes, nuclei, organelles) and to use these features to identify and classify larger structures (e.g. cancer cells, vessels, nerve cells, etc.).
  • the preparation of the data for the classification algorithm and the classification itself is often very computationally complex and requires the programmer to have extensive background knowledge with regard to the object classes to be expected.
  • US patent application US 2010/185629 A1 describes tools and techniques for indexing and querying data stores using concatenated terms. These tools can receive prompt questions that contain at least two search terms.
  • the search terms are each correlated with fields contained in records within a data store, and those fields are populated with corresponding field values.
  • the search terms are ordered by an indexing priority by which the fields are ordered within an indexing table associated with the data store.
  • the tools then associate the search terms as ordered by indexing priority.
  • the tools in turn search the index table for all entries that correspond to the linked search terms.
  • Patent application US 2014/314313 A1 describes a search for a search image in an image database and discloses a classification of images based on their visual similarity.
  • the invention relates to a computer-implemented method for data classification.
  • the method includes providing a token set that includes tokens generated from multiple field values of multiple records through tokenization.
  • the tokens were generated from field values of at least two different field types and are stored in the form of a bit sequence.
  • the method further includes analyzing one or more features of the tokens at the bit sequence level to identify subsets of feature-like tokens.
  • the characteristics include the bit sequence of the tokens and/or the length of the bit sequence.
  • the method further includes storing a copy of each of the subsets of feature-like tokens in subset-separated form. Each subset copy represents a class of feature-like data.
  • Classification methods known in the state of the art are often significantly more computationally complex. the texts are e.g.
  • the method can be used for a large number of different data types (text, image, video, audio) or data or file formats (.jpg, .png, .tif, etc.) without a specialized Parser would have to be created and laboriously integrated into the tokenization process.
  • the same tokenizer can be applied to a variety of different data types and data formats, or to field values stored in a field with a generic data type. This can greatly improve the maintainability, flexibility, and extensibility of the classification system.
  • a large number of different data types can therefore be stored in a given field.
  • a user or an application program that wants to store data records in the database therefore does not have to worry about the consistency and matching of data types.
  • field types that are not restricted to a specific data type (such as integer, boolean, varchar, etc.), or that are assigned a very generic data type, prevents an unauthorized third party gaining access to the index, can draw conclusions about the content of the attributes of the original data records based on the indexed data types.
  • the features that are analyzed for the similarity analysis of the tokens are free of information regarding byte sequences or other patterns in higher levels of the data representation. It is therefore not necessary to analyze the token using a data type-specific parser, or a complex representation of the data contained in the bit sequence of a token at a higher structural level is avoided.
  • the method further includes creating a sub-index from each of the subsets of feature-like tokens and providing an index selection program.
  • the index selection program is configured to automatically identify that sub-indices whose token is most similar to the data value in terms of bit sequence and/or bit sequence length.
  • the token set is stored as a searchable index.
  • the token set is used to create a searchable index.
  • the method may include receiving a search query that includes a search value.
  • the search value is analyzed by an index selection program and that part of the index whose token is most similar to the search value in terms of bit sequence and/or bit sequence length is identified.
  • the identified partial index is then searched for the search value instead of the (overall) index.
  • the partial indices are preferably generated fully automatically from the overall index. It is particularly advantageous that manual creation of the partial indices or manual specification of the criteria as to when a token is to be stored in which partial index or which partial index is to be used when searching for a specific search value is no longer necessary.
  • the method includes identifying an indexed token within the identified sub-index that is identical to the search value and analyzing record pointers stored in the sub-index associated with the identified token to identify one or more of the records containing one or more field values from which the indexed token was generated, the records being stored in a database are. Furthermore, the one or more identified data sets or a reference to the one or more identified data sets are returned as a response to the search query.
  • Each of the partial indices can thus be used to quickly identify the data record or data records that contained one or more field values from which the identified token was generated.
  • the partial indices obtained can be used in the context of classic database applications to accelerate them.
  • the method includes receiving a write request, the write request including a data value (e.g., a field value - e.g., DR8.F6).
  • a data value e.g., a field value - e.g., DR8.F6
  • the received data value is automatically parsed into multiple new tokens by the tokenization logic used to tokenize the records.
  • Each new token is stored as a bit sequence in a volatile or non-volatile storage medium.
  • each of the new tokens is analyzed by an index selection program. The index selection program identifies that part of the indices whose token is most similar to the new token in terms of bit sequence and/or bit sequence length.
  • the new token is stored in the identified partial index in addition to or instead of storing the new token in an overall index of tokens.
  • the index selection program can work based on rules, for example.
  • the rules can be specified automatically based on the results of the classification (number and type of token subsets formed) or manually.
  • the manual specification can be performed by a user who translates the results of the classification into explicit rules (e.g., a user can use a graphical user interface (GUI) to analyze the automatically identified subsets of tokens and find that the tokens have been divided into tokens based on their image size a first token subset whose tokens are less than 500 bits, a further token subset whose tokens are between 501 and 1000 bits and a further token subset whose tokens are over 1001 bits
  • GUI graphical user interface
  • bit sequence patterns and/or bit sequence lengths as classification criteria can be advantageous since these features can already be recognized at the lowest "structural" level, the level of the bit sequence itself. So there is no instantiation and representation of tokens on higher structural levels required to get to these features.
  • the classification based on the token bit sequence length can be advantageous since this form of classification or the automatic creation of partial indices can be used in a large number of application scenarios, in particular in the context of portals and platforms that are used to manage images.
  • the classification software can be used to create and manage an image archive in which there are images of a variety of (previously unknown) image sizes.
  • the classifier can e.g. be a nonsupervised classifier that automatically recognizes itself whether the images should be divided into two, three or even more subsets of similar size based on their size.
  • the classifier can be used to manage images of a home page portal in which there were hundreds of small images (thumbnail images) and large images (originals).
  • the tokenization logic uses certain bit patterns to recognize the beginning and end of an image in a bit sequence, e.g. the beginning and end of a .jpg image, and uses these boundaries to generate a token that encodes a corresponding image.
  • the classification logic analyzes the bit sequence of the individual tokens in order to automatically generate corresponding subsets of the images that have a similar size and are stored in separate memory areas, e.g. for archiving purposes.
  • the method is used for automatic image classification.
  • the tokens are bit sequences that each encode an image, with the bit sequence length representing the image size.
  • the subsets of tokens include at least a "small screen subset” and a “large screen subset”.
  • the "small picture subset” selectively contains tokens whose bit sequence length is below a first threshold value.
  • Selectively included in the "big screen subset” are tokens whose bit sequence length exceeds a second threshold.
  • the number of subsets is unknown at the beginning of the analysis. Rather, the number of token subsets formed is determined dynamically as part of the result of the analysis of the characteristics of the tokens.
  • the analysis to identify the subsets of feature-like tokens is performed by an unsupervised machine learning algorithm.
  • a human or program logic can analyze the token subsets and manually or automatically define rules for an index selector.
  • the index selector is a program logic that applies these rules to an input value (e.g. a search value) to select a sub-index/sub-token set (e.g. image size-dependent image archive directory) to store new image in appropriate sub-index/sub-archive directory.
  • the data records are stored in encrypted form in a database.
  • Providing the set of tokens involves an application a tokenization logic on the encrypted field values of the records at the bit sequence level to generate the tokens.
  • the analysis of the characteristics of the tokens is carried out at the level of the bit sequence of the tokens.
  • the subsets of feature-similar tokens each include tokens that are similar in terms of their bit sequence and/or the length of their bit sequence.
  • the method further comprises using the subsets of feature-like tokens, each as an input of a decoding algorithm, wherein the subsets each represent a candidate for a natural language word or another code that can be interpreted by a human, and the decoding algorithm is designed to, by analyzing the tokens, subset to identify the natural language word or other code interpretable by a human.
  • the method includes providing a DBMS configured to store the records each as a set of multiple field values.
  • the field values are each stored in a field.
  • Generating the set of tokens may include generating first and second tokens.
  • the first tokens are generated from first field values of a plurality of data sets, the first field values being stored in first ones of the fields, the first fields belonging to a first field type.
  • the second tokens are generated from second field values of the multiple records.
  • the second field values are stored in second ones of the fields.
  • the second fields belong to a second field type.
  • an index is generated for the content of a specific table column.
  • a table column often represents a specific attribute of data objects that are stored in the respective table. Ie, classically For example, for an Employees table, you can have an index on the First Name column, another index on the Last Name column, another index on the Position column, another index on the Year of birth column, another index on the Year of Birth column be created for the "ID" column, etc. Should all these index structures for the "Employees" table fall into the wrong hands, it is easy for unauthorized third parties to reconstruct the complete data records stored in the table using the index structures. Because the fields are individually indexed, the index name, or at least the content, usually gives a clear indication of what kind of attributes a data value stored in an index represents.
  • the set of tokens or the index/partial indices that are created according to embodiments of the invention include significantly increased protection of the data stored in them. This is because the field values of at least some of the fields in the records are tokenized.
  • a (partial) index that is based on these tokens and that stores the tokens in the index structure, regardless of the type of field from which they originate, does not allow any conclusions to be drawn as to whether a specific token represents the entire field value or only part of it, and also does not allow any conclusions to be drawn about which field type it originates from.
  • a certain indexed numerical value in the index can also be the birthday of the employee, a publication date of an article reporting on the employee, an ID of the employee, an ID of a press article reporting on the employee, an identification of an identity card , an automobile, an employee gift certificate, or any other attribute that is more or less closely semantically related to a particular object/employee.
  • Embodiments of the invention thus provide a "chaotic" or "obfused" search index which, even if it unintentionally reaches unauthorized third parties, often does not allow any conclusions to be drawn about the content of the data records indexed in it.
  • Sensitive data records only become semantically transparent if the actual data records are stolen in addition to the index.
  • Each data record or at least the majority of all data records preferably contains a large number of fields, many of which fields in turn contain a data value which can each be broken down into a large number of different tokens. This ensures that the meaning of the individual data records cannot be reconstructed purely based on the index, even though all tokens generated from the field values of a data record and stored in the index refer to the data record from which they originate.
  • embodiments of the invention can provide a search index that offers "security by obscurity" for the data indexed in it.
  • the data records can be made available to a database, eg a company's employee database, and stored in the database in such a way that the data values are each stored in different fields.
  • the different fields can be, for example, fields such as "first name”, “last name”, “function in the company”, “portrait photo”, “date of birth”, “employee number”, “credit card number” and "product portfolio responsible”.
  • the fields of the database can therefore be assigned to specific semantic categories, but not all fields are set to a specific data type.
  • the "responsible product portfolio” field can, for most employees, be a compilation of image data for the respective products, text data that describes the products, and possibly audiovisual data on the products or on the employee.
  • one or more or even all of the fields in the database are not limited to a specific data type.
  • some fields e.g. "Birthday” will only store date values
  • the "Credit card” field only numeric values
  • at least some fields e.g. "Responsible product portfolio” contain a mixture of data values of different types, and also the fields based on the program logic, the that writes data values into the respective fields only contain data of a certain type can be fields that are not restricted to a data type by the DBMS that manages the database.
  • the program logic which provides the data records for storage in the fields of the database, is preferably configured in such a way that they use predefined bit patterns as a prefix and/or suffix for data belonging to a specific type (e.g. image data, image data of a specific file format, image elements, text data , text elements, e.g. individual words or sentences, numerical values, dates, audio data, video data, etc.) or which have a certain predefined size (0-100 bits, 101-1000 bits, > 1001 bits, etc.) so that a tokenizer , which creates an overall index and/or partial indexes of the database, tokenizes the data stored in the fields where these predefined bit patterns have been inserted.
  • a specific type e.g. image data, image data of a specific file format, image elements, text data , text elements, e.g. individual words or sentences, numerical values, dates, audio data, video data, etc.
  • a tokenizer which creates an overall index and/or partial indexes of the database, token
  • bit pattern 10011010101010011 could specify the start of a date and the bit pattern 10011010101010010 could specify the end of a date.
  • bit pattern 1001111110101010011 could specify the start of a jpg image file and the bit pattern 1001111110101010010 could specify the end of a jpg image file.
  • the "Birthday” field for a specific employee M1 can consist of the bit sequence 10011010101010011 ⁇ BITSEQUENZ-DES-BIRTHDAY-10011010101010010, where BITSEQUENZ-DES-BIRTHDAY depends on the respective birthday and the type and Way in which dates are represented in the respective DBMS in bit format.
  • the field "responsible product portfolio” typically consists of a mixture of text information, date information (eg when a certain product was launched), numerical information (eg product price, product dimensions). The program logic for storing the data records would therefore provide date values, numerical information, etc.
  • bit patterns introduced as a prefix and/or suffix into the user data during storage Used by the tokenizer as a delimiter during token generation.
  • the tokenizer would break down the bit sequence stored in the "responsible product portfolio" field into several tokens (e.g. dates of market launch of the products, figures for prices and dimensions, etc.) based on the predefined bit pattern, which would then be broken down based on their similarity with regard to their bit sequence (e.g.
  • the tokenizer preferably uses the same bit patterns for tokenization that were introduced by the logic for storing the data as a prefix and/or suffix in the useful data to be stored.
  • the explicit insertion of predefined bit patterns as a prefix and/or suffix in components of the data values of the data records is only one possible implementation.
  • Data of a certain type or file format, as stored by the DBMS in the form of a bit sequence often already contain bit sequences that enable automatic recognition of numerical values in contrast to image data or the like.
  • An explicit supplementation of predefined bit patterns when storing the data sets is therefore not necessary here.
  • Classification can also be based purely on the token size (length of the bit sequence of the individual tokens).
  • the tokenizer can preferably also be used to process a search term provided by the user, so that, according to embodiments, the processed search term has the same bit pattern as a prefix and/or suffix or is converted into a search token at these as the data values stored in the partial indices.
  • the data sets are pseudonymous data sets that do not contain any real names of people.
  • the same generic tokenization logic is applied to the first and second fields.
  • the generation of the tokens can include using further field values in their entirety as further tokens.
  • the first and second fields can contain bit sequences that encode continuous text with one or more images, with partial sequences that encode images (and optionally possibly also individual words or word sequences) being recognized as tokens in the course of tokenization and added as tokens to the token set will.
  • the token set also contains tokens from fields of field types to which no tokenization is applied or whose content simply cannot be divided into individual tokens by the tokenizer used.
  • the records are stored in a database managed by a DBMS.
  • the data records contain different numbers of fields.
  • all field values in all fields of a record are tokenized using the same tokenization logic. This can be advantageous since generating too many small sub-indices can be avoided, which can happen, for example, if separate sub-indices are generated for each field. In this way, a broad database that is robust against structural changes can be created for token classification, particularly in the case of databases with variable fields and field types or unknown meanings of the individual fields.
  • the fields of each record share a common, generic data format.
  • the generic data format allows field values to be stored that contain both text data and at least image data, audio data and/or video data. Further data fields can thus easily be supplemented without an adjustment of the tokenization and/or classification method being necessary for this.
  • the tokenization logic is designed to analyze the bit sequence of a data field value at the bit level and to tokenize the bit sequence into the individual tokens as a function of bit sequence patterns detected therein.
  • the method includes storing the data sets in a database managed by a database management system (DBMS), the DBMS being a NoSQL DBMS.
  • DBMS database management system
  • NoSQL databases can be advantageous, as this form of DBMS is particularly flexible in terms of adding and managing fields and is therefore particularly suitable for managing heterogeneous data sets.
  • the tokenization logic is a generic tokenizer configured to tokenize field values of fields of different field types.
  • the application of the generic tokenization logic to a field value includes recognizing data of different data types within the field value, the data of different data types comprising text data as well as image data and/or audio data and/or video data.
  • the set of tokens is in the form of a searchable index.
  • the token set can also be stored as such, eg as a bit sequence list, and used to generate the searchable index.
  • the location of the storage of the tokens in the structure of the index is independent of which of the field types the tokens come from.
  • Generating a single index (“overall index") from the tokens of multiple fields has the advantage that it can be used to quickly process database queries.
  • this index is also significantly smaller than would be the case if an index were created separately for each field type, at least when some tokens occur in fields of different types.
  • a separate sub-index is preferably created from each of the token subsets and a suitable sub-index for answering a database query is dynamically recognized and used instead of the overall index.
  • the location of the storage of the tokens in the structure of each of the sub-indices is also independent of which of the field types the tokens originate from.
  • the index (overall index) and/or each of the sub-indices has the structure of a tree, in particular a B+ tree. This structure can significantly speed up the time needed to identify a particular indexed token that is identical to a search value.
  • the (overall) index stores all tokens generated from the field values of the records of a database in such a way that the index contains each token only once.
  • Each token contains pointers to one or more of the records from whose field values it was created.
  • Each of the sub-indexes is also a set of tokens that occur only once in this sub-index.
  • the tokens stored in the index and/or each of the sub-indexes are free of references to fields or field types used to store field values used to generate the tokens.
  • the methods described herein for various embodiments may be implemented in software, firmware, and/or hardware. Preferably, they are implemented as one or more software programs or modules running on a monolithic or distributed computer system.
  • the tokenization step can be performed by a tokenization program and the classification step can be performed by a classification program.
  • tokenization and classification it is also possible for tokenization and classification to be performed by the same software program.
  • the method includes receiving a search query that includes a search value.
  • an overall index or, preferably, only a partial index is searched for the search value and an indexed token in the searched index that is identical to the search value is identified.
  • the method includes analyzing record pointers stored in the searched aggregate index or partial index associated with the identified token to identify one or more of the records containing one or more field values from which the indexed token was generated.
  • the identified one or more records, or a reference to the identified one or more records are returned to the requesting client in response to the search query.
  • the data records are stored in encrypted form in the database.
  • the records are additionally individually encrypted and stored in individually encrypted form, e.g. on a client computer that contains or has access to the database.
  • the data records are encrypted in such a way that a server computer system on which the encrypted data is later stored cannot decrypt them.
  • the unencrypted records each consisting of one or more field values, are tokenized, classified, and stored in sub-tokensets and sub-indexes as described. Tokenization, classification and partial index generation can also be done on the client computer system.
  • the partial indices are now encrypted with a public key of a server computer system and transmitted to the server computer system together with the encrypted data records to the server computer system.
  • the server computer system decrypts the partial indices with its private key, which forms an asymmetric cryptographic key pair together with the server computer system's public key.
  • the server computer system receives and stores the data sets in encrypted form without being able to decrypt them.
  • the server computer system may be a distributed computer system of a cloud storage service.
  • the server computer system can now receive a search query from this or another client computer system that contains a search value, identify one of the sub-indexes that is expected to contain the search value, and search through the identified index.
  • the server computer system then returns one or more encrypted data records, which were determined in the partial index search, to the client from which the search request originated.
  • This can be advantageous because it makes it possible to also store sensitive data on a cloud storage service (server computer system) that is not trusted, with the data being searchable in an index without this sensitive data being known to the cloud storage service:
  • the index does not contain any information about the field from which the individual tokens originate and it is therefore not known whether a specific token is, for example, a number, an ID number, a certificate, a date or a measured value.
  • the tokens refer to the data sets, however, these are encrypted so that the cloud storage service cannot access the content of the data records.
  • the data records are individually encrypted by a client computer system in such a way that the client computer system can decrypt them again, but not a server computer system that is intended to receive the encrypted data records.
  • the server computer system provides an interface to allow the client computer system or other computer systems to access the decrypted partial index.
  • the interface may include index selection ("selector") functionality.
  • the interface determines that sub-index whose tokens are most similar to the search value in terms of bit sequence and/or bit sequence length, and searches the determined unencrypted sub-index for the search value.
  • the server computer system returns one or more encrypted data sets identified from the index search over a network, e.g., the Internet, to the computer system from which the request originated.
  • the computer system that receives the encrypted data sets preferably has a suitable key to decrypt these data sets again.
  • the invention relates to a computer system for data classification.
  • the computer system includes one or more processors, a data storage medium (which may also be embodied in the form of multiple operatively connected storage media), and a DBMS configured to store data sets, each as a set of multiple field values, in the one or more data storage media.
  • the field values are each stored in a field.
  • the fields of each of the records belong to at least two different field types.
  • the computer system also includes program logic configured to create a token set.
  • the token set includes tokens generated from multiple field values of multiple of the records through tokenization.
  • the tokens come from field values of at least two different field types and are stored in the storage medium in the form of a bit sequence.
  • the computer system includes classification logic configured to analyze one or more features of the tokens at the bit sequence level in order to identify subsets of tokens with similar features.
  • the characteristics include the bit sequence of the tokens and/or the length of the bit sequence of the tokens.
  • the classification logic is further configured to store a copy of each of the subsets of feature-like tokens in the data storage medium in a form separated by subsets, with each subset copy representing a respective class of feature-like data.
  • a “ database management system” or " DBMS” is understood in the following as an electronic system for storing and retrieving data.
  • the data is preferably stored in the DBMS consistently and permanently and made available efficiently to various application programs and users in a form that meets their needs.
  • a DBMS can typically contain one or more databases and manage the data sets contained therein.
  • the DBMS is preferably a field-oriented DBMS, that is to say a DBMS which is configured to store parts of individual data records, so-called "field values", in a number of different fields.
  • a “data record ” is understood to mean a quantity of data that is coherent in terms of content and managed jointly by a database management system.
  • a data record typically represents the smallest structural unit of the data stock of a specific database.
  • a single data record can represent a specific physical object, eg a natural person.
  • the person can be an employee, a patient, a customer, etc., for example.
  • the corresponding data record can contain a predefined set of attribute values of this person (eg name or pseudonym, age, height, weight, date of birth, ID card numbers, security certificates, authentication codes, biometric data and others).
  • a data record can represent a group of data fields that are related in terms of content (belonging to an object), e.g. B. Article number, article size, article color, article name or similar.
  • the field types 'Name', 'Address' and 'Date of Birth' could represent the logical structure of a record for the object type "person”.
  • Data records correspond to a logical structure that was defined during development of the database and, in some embodiments, can also be changed at runtime of the database, for example by adding, removing or renaming fields.
  • data processing data is combined into data sets and stored in databases, they are processed by computer programs and are generated, read, changed and deleted by them.
  • a " field" refers to an area on a logical or physical data carrier that is managed by a DBMS, that is assigned to a predefined field type and that is created and intended for storing a field value of a data record.
  • a "field” is thus an element for storing a field value of a record as defined above. Fields of a data record are jointly managed by a DBMS. The field can be created, deleted or renamed by the DBMS using predefined commands and, if necessary, also included in the access rights management of the DBMS.
  • a “ field type " is a category or type to which a particular field belongs.
  • a field type can represent a specific attribute of a physical object.
  • a DBMS may use field types such as "Name”, “Pseudonym”, “ID Number”; Use “Access Certificate for Room R”, “Access Certificate for Device G”, “Access Certificate for Building GB”, “Age”.
  • Each field is accurate assigned to a field type.
  • each record may contain a maximum of only one field for each field type predefined in the DBMS.
  • a “field value” is a data value that is part of a record and is intended to be stored in a field of a particular field type.
  • a field value of the record for a particular employee "John Doe” may have a first field value "John Doe” for the field type "Name”, another field value "13425298833” for the field type "ID card number”, another field value "237971113” for the field type "Access Certificate for Room R” include.
  • a field value may consist of a single word, a single number, or a combination of multiple words and/or numbers and/or other data formats, with different embodiments of the invention allowing varying degrees of flexibility as to the nature and combinability of data types within the same include field value.
  • a field type would therefore correspond to a column in a table, e.g. a column for "age” in an "employees” table.
  • Each row in the employee table would correspond to a record containing attribute values for a particular employee.
  • Each "cell" of this row corresponds to a field and is used to store a field value (i.e. a simple or composite attribute value of the employee).
  • a field therefore corresponds to the memory area in which a specific data value/field value of a data record is stored.
  • a “ database ” is understood to be a (typically large) amount of data that is managed in a computer system by a DBMS according to specific criteria. The data is organized in a large number of data sets.
  • NoSQL DBMS (English for Not only SQL) DBMS is a DBMS that follows a non-relational approach to data storage and does not require any fixed table schemas.
  • NoSQL DBMSs include document-oriented DBMSs such as Apache Jackrabbit, BaseX, CouchDB, IBM Notes, MongoDB, graph databases such as Neo4j, OrientDB, InfoGrid, HyperGraphDB, Core Data, DEX, AllegroGraph, and 4store, distributed ACID DBMSs such as MySQL Cluster, Key -Value databases like Chordless, Google BigTable, GT.M, InterSystems Caché, Membase, Redis, sorted key-value stores, multivalue databases, object databases like Db4o, ZODB, columnar databases and temporal databases like Cortex DB.
  • a "certificate” is understood to mean a digital certificate.
  • a certificate is a digital record that confirms certain properties of users or other objects and whose authenticity and integrity can be checked using cryptographic methods.
  • the digital certificate either contains the data required for its verification itself or is stored linked to certificate-related metadata, so that the data required for its verification can be obtained from the metadata.
  • the certificate is preferably issued by an official certification body, the Certification Authority (CA).
  • CA Certification Authority
  • the certificate can be in the form of a numerical value to which metadata are assigned. The use of numerical values can be advantageous because they can be easily indexed and remain unchanged if the metadata needs to be modified (e.g. extension of validity), i.e. their position within the index can also be retained.
  • the certificates are preferably in the form of numerical values which do not contain a public key but are stored linked to metadata or a public-key certificate, with the metadata specifying the scope or period of validity of the certificate in more detail.
  • a certificate can also be designed according to the X.509 standard, ie it can contain a public key and confirm the identity of the owner and other properties of a public cryptographic key of the certificate.
  • a certificate can, but does not necessarily have to refer to a cryptographic key, but generally contains data for checking an electronic signature or is stored linked to this.
  • a “ tokenizer” is program logic that takes data, for example a field value, as input, analyzes the data, e.g. to detect delimiters or other decomposition criteria and patterns, and then breaks the data into one or more tokens as a result of the analysis and the returns tokens. It is also possible that not all tokens could be returned. For example, a full-text indexer Recognize and filter out semantically meaningless stop words so that they are not indexed.
  • To "tokenize" a data value therefore means to divide the data value into several components according to a certain scheme. The components represent the tokens. For example, natural language texts can be divided at predefined separators, such as spaces, periods or commas, and the components (words) generated in this way are used as tokens.
  • the search value is preferably processed in the same way by the client computer system or the server computer system in order to ensure that the search values of the search requests correspond to the tokens contained in the index.
  • the delimiters can be predefined bit patterns.
  • index is a data structure that speeds up the search for specific data values by a database management system.
  • An index consists of a collection of pointers (references) that define an ordering relation to several (stored in the index - "indexed" - data values. For example, B+ trees are used for this.
  • Each indexed data value is linked to further pointers, which point to data sets reference, in which the found indexed data value is contained and which represented the data basis for the creation of the index.
  • Database management systems use indices to quickly identify the desired data records in response to a search query by first searching the index along the pointers for a data value which is identical to a reference value contained in the search query Without an index, the data values of a field managed by the DBMS would have to be searched sequentially, while a search using the index, eg a B+ tree, often only has logarithmic complexity.
  • a " decoding algorithm” is a program logic for cryptanalysis, i.e. a data analysis process that obtains information from encrypted data, whereby the encryption algorithm and/or the encryption key are initially unknown and are only determined by the process or the encryption mechanisms are otherwise circumvented ("broken").
  • a “classifier " or “classification logic” is program logic for automatically combining objects into classes (groups, sets) whose elements are more similar to one another with regard to one or more characteristics than the objects of other classes.
  • ordinal numbers such as first, second, third, etc. is used here solely to distinguish between elements and/or persons with otherwise the same designation and is not intended to imply any particular order. Furthermore, elements and/or persons whose designation differs only by an ordinal number can be identical or different elements or persons, unless something else clearly results from the specific context.
  • Figure 1a Figure 12 shows a block diagram of an embodiment of a data classification system according to the invention.
  • a database management system for example a noSQL DBMS 160, is instantiated on a computer system 156.
  • the DBMS 160 manages one or more databases.
  • the database 102 shown here includes a large number of data records DR1, DR2, ..., DR7, ..., each of which contains one or more field values.
  • Each of a record's field values is stored in a corresponding field, a type of data container.
  • Each field is assigned to a specific field type F1, F2, F3, F4, F5, F6, F7.
  • the first field of data record DR1 is assigned to field type F1, the second field of data record DR1 to field type F2, etc.
  • the first field of data record DR6 is assigned to field type F1
  • the second field of data record DR6 to field type F6, etc.
  • the composition of the field values of the individual data records can differ with regard to their field types, as can be seen from the data records in the database 102 . It is also possible that individual data records do not contain a field value of a certain field type at all.
  • mandatory field types can also be defined, i.e. each record contains a field for each mandatory field type and optionally contains one or more further fields for optional field types.
  • tokenizer “tokenization logic”
  • classification application “classifier”, “classification logic”
  • the tokenizer breaks down the data values of multiple fields from multiple data sets into a common total token set 162, which can optionally be further processed, e.g. can be converted into a non-redundant token set 153.
  • the program logic for generating the index includes one or more tokenizers 158 configured to tokenize the field values of one or more fields.
  • field values of one or more fields can also be read out as a whole and used as a token without being broken down.
  • the classifier 432 can be embodied, for example, as a "supervised" classifier, in which the number of classes to be expected is specified.
  • the classifier can be a rule-based classifier that matches a set of predefined binary patterns to the tokens, or a k-means classification algorithm.
  • the classifier can also be a “nonsupervised” classifier.
  • neural networks and similar algorithms can be used.
  • the tokenizer 158 or additional program logic is designed to generate an overall index 154 from the token 153 . Additionally or alternatively, the tokenizer or the indexer is configured to generate a partial index 426, 428, 430 from each of the token subsets 420, 422, 422. The position of the token within the index or within the sub-indices preferably does not depend on the field type from which the token originates.
  • the program logic for tokenization and/or for generating the index or partial indices and/or for classifying the tokens is provided in the form of a plug-in or add-on of the DBMS.
  • This can be advantageous, since existing types of DBMSs can be functionally expanded with the help of an additional software module for tokenization and token classification, so that a migration of the data to another DBMS for the purpose of token generation and classification is not necessary.
  • tokenization, index generation and token classification can each be implemented in the form of an independent application program.
  • All or at least most of the field values of all data records in a database 102 are preferably tokenized, so that a large number of tokens 153 are produced.
  • tokens 153 may include a mixture of numbers, letter words, images or image segments, audio files or audio elements, or other data structures.
  • Each of the generated tokens is stored associated with a pointer, the pointer pointing to the record from which the token originated, but not refers to a single field or field type in which the field value from which the token was derived was stored.
  • the token set 153 is preferably a non-redundant, "unique" token set in which each of the tokens occurs only once. Ie, even if a token with the value "3467475675" occurs several times in the database 102 and thus also in an initially formed token set, only a single token with the value "3467475675" in the non-redundant token set 153 and in the Index 154 saved. However, the storage in the index 154 or each of the sub-indices takes place in such a way that an indexed token refers to all data records DR1-DR7 in which it is contained at least once in at least one data value.
  • all tokens of the non-redundant set of tokens are stored in the index or sub-indices in such a way that the tokens are sorted according to a sorting criterion and are stored in sorted form in the index structure.
  • the sorting can be done, for example, using the alphabet for alphanumeric data or other sorting criteria adapted to the data. Since the tokens in the index are preferably stored in sorted form, and further preferably are stored in a tree structure, it is possible very quickly to identify a particular token within the index and then use that identified token's references to one or more records to very quickly identify those records that contain a specific token you are looking for. It is therefore not necessary to search through the data records of the database 102 sequentially.
  • the number and composition of the field types of individual data records can vary.
  • the partial indices 426, 428, 430 are not derived from different table columns or field types, but from token subsets 420, 422, 424, each of which contains tokens that have a similar bit sequence length and/or that have one or more similar bit sequence patterns .
  • "Similar bit sequence patterns" can be, for example, identical sequences of "0"s and "1"s that occur in the bit sequences of a number of tokens and are only shifted by a few positions relative to the first position of the bit sequence of the respective token.
  • the grouping of the tokens of the token set 153 into subsets of similar tokens is performed by the classifier 432, which is used to classify the tokens works exclusively on the level of the bit sequence.
  • the tokenizer 158 also operates solely at the bit sequence level of the field values to break them down into tokens 162 . This means that the tokenizer analyzes the individual bits of the field values stored as a bit sequence in order to recognize patterns of known bit sequences which, for example, mark the transition from a text section to an image section or vice versa, or which mark the end of an image and the beginning of another image, the is stored as part of the field value.
  • the set of tokens 162 can thus be created and classified in a highly efficient manner and, if appropriate, corresponding partial indices can also be created without having to create data objects on a higher structural level and/or having to instantiate runtime environments for processing such more highly organized objects.
  • the token subsets or the sub-indices can be used for a large number of application scenarios.
  • index selector 434 program logic referred to as "index selector" 434 is provided. This can be done manually, semi-manually or automatically.
  • the index selector is designed to select one of the sub-indices 426, 428, 430 as a response to the receipt of a specific data value, according to the same selection logic that the classifier 432 uses to select individual tokens on the basis of their bit sequence length or other bit-sequence-related characteristics of individual token subsets (from which the respective sub-indices were formed). That is, a data value that would be assigned to subset 422 by classifier 432 because of its bit sequence will cause index selector 434 to choose the subindex 428 that emerged from subset 422 . A data value that would be assigned to subset 424 by classifier 432 because of its bit sequence will cause index selector 434 to select the subindex 430 that emerged from subset 424 . And so forth.
  • the index selector ensures that, in response to the receipt of a "write request" to the database 102, the data value to be written is not only stored in the database but also in one of the sub-indices, which the index selector dynamically identifies using bit sequence characteristics of the data value to be written. For example, according to Fig. 1b a new record DR8 stored in the database. Its field values DR8.F1, DR8.F2, DR8.F3 and DR8.F6 are tokenized and stored with the help of the index selector in that part of the indices which already contains tokens that are similar to this new token in terms of bit sequence characteristics.
  • the index selector ensures that, in response to the receipt of a "read request" to the database 102, one of the sub-indices, which the index selector dynamically identifies based on bit sequence characteristics of the data value to be read, is searched for the search word in order to efficiently find the Identify records containing the search term and return those records.
  • An overall index 154 which contains all of the tokens in the data records, is therefore accessed neither when reading nor when writing. Rather, the working memory consumption can be reduced by accessing partial indices whose size and/or content preferably depends on the type of data.
  • figure 2 shows an example of the field values stored in different fields of two data sets and the intermediate token sets generated from them.
  • field type F1 can be used to store CVs. Naturally spoken texts with image data and optionally also audio data are thus often stored in fields of field type F1.
  • Field type F2 may be designed to store a credential for a particular building, for example in the form of a numeric data value serving as a certificate. It is possible that the data for field type F2 also contain image data, eg a picture of the person attached to an ID card.
  • Field types F3 and F4 can be designed to store numeric data values, each serving as authorization credentials for another building (F3) or a specific room (F4).
  • Field type F5 can be used to store biometric data.
  • the biometric data can be stored in the fields of field type F5 in the form of text, images (for example fingerprints, iris images, etc.) and/or video data (movement patterns, etc.).
  • the fields of the various field types have a generic data format, which in principle allows all data forms (text, numbers, images, video, audio and/or other files) occurring in the database to be stored. It is possible, for example, that an application logic that creates the data stores all data of a certain semantic concept (e.g. "age”, "birthday”, "access authorization for building XY”) in a specially specified field, even if the field would also support the storage of other data formats.
  • the tokenizer is a single, generic tokenizer that applies to all fields of different field types to be tokenized.
  • the tokenizer 158 generates a set of first tokens 250 from the field value stored in the first field of record DR1 and from the field value stored in the first field of record DR7, as well as from the field values of all fields of the other records associated with field type F1
  • Tokenizer 158 also generates sets of second tokens 252 from the field value stored in the second field of record DR1 and from the field value stored in the second field of record DR7, as well as from the field values of all fields of the other records associated with field type F2. This is performed on the field values of all field types F1-F7, preferably using the same generic tokenizer for all field types. All of the tokens 250 , 252 , . . . , 254 generated for all field types form the token set 162 .
  • predefined bit patterns can be introduced into the data values by the program logic storing the data (e.g. an application program or the DBMS that manages the database) in such a way that, based on these bit patterns, data of different types (text data , individual words, dates, numerical values, audio data) can be easily distinguished from one another by a tokenizer.
  • the program logic used for this can be as complex as desired and, for example, be downstream of an image analysis step in order to then store individual objects recognized in an image in such a way that they can be distinguished from other user data by a clear, object-type-specific bit sequence.
  • bit pattern delimiters there is no explicit introduction of bit pattern delimiters in the course of storing the data records in the database.
  • some data types when provided by the DBMS as part More complex, composite data entries (text, images, numbers and/or sound) already contain recurring bit patterns on the bit level, which allow some or all of the values stored in a field to be tokenized into one, two or more tokens.
  • machine-learning approaches that use different, randomly chosen delimiters for tokenization as a test and then retain those delimiters and use them as a basis for tokenization when creating the sub-indices that lead to a desired degree of tokenization of the data values stored in the database possible.
  • FIG. 12 shows a flow chart for generating an overall index 154 from the entirety of the token set 153 according to one embodiment.
  • a DBMS 160 is provided 170, for example the DBMS is instantiated on a computer system 156.
  • the DBMS 156 is configured to store data records DR1-DR7 in a structured manner as a set of a plurality of field values. Each of the field values is stored in its own field. The fields of each of the records belong to at least two different field types F1-F7.
  • first tokens 250 are generated from first field values of a number of data records. As in figure 2 shown by way of example, the first field values are stored in first fields. The first fields belong to a first field type F1.
  • second tokens 252 are generated from second field values of a plurality of data records.
  • the second field values are stored in second fields.
  • the second fields belong to a second field type F2.
  • step 172 or 174 is repeated for the fields or field values of other field types F3, . . . , F7.
  • tokenization logic e.g., a generic tokenizer 158
  • step 176 tokenization logic (e.g., a generic tokenizer 158) generates a searchable index 154 from at least the first tokens 250 and the second tokens 252, and optionally the additional tokens 254 generated for other data types.
  • the location of storage of the first and second and the possibly further token 254 in the structure of the index takes place independently of which of the fields the tokens originate from.
  • a partial index can also be generated in an analogous manner from each of the token subsets 420, 422, 424.
  • figure 4 shows an overview of a distributed system that includes a server computer system 322 and several client computer systems 156, 157, 159.
  • the computer systems 322, 156, 157, 159 are connected to one another via a network 155, for example the Internet.
  • the client computer system 156 may include a client application program that sends a search query 330 to the server computer system 322 over the network.
  • the search query contains a search value 328, for example a user pseudonym in the form of a numerical value "3463744".
  • the server computer system 322 can be embodied as a cloud computer system, which itself consists of a large number of resources that are networked and operatively coupled to one another, in particular a number of data storage devices and processors.
  • the server computer system provides data records from a database for a large number of authorized client computer systems 156, 157, 159 via the network.
  • the provision includes making available one or more sub-indices 426', 428', 430' via an index selector 434.
  • Each of the sub-indices is formed from sub-token sets of tokens that are similar in terms of their bit sequence characteristics and have been grouped into sub-token sets as is for embodiments is described here.
  • Each of the sub-indexes allows the client computer systems to search the contents of the database 326 and identify and return hits [[DR3]] even though the database 326 is encrypted.
  • the use of partial indexes instead of an overall index 154' reduces the resource consumption on the server side, in particular with regard to the consumption of main memory.
  • Embodiments of the invention thus enable the outsourcing and storage of sensitive data on cloud services in such a way that they can be searched via an index and made available to multiple authorized client computer systems without compromising the confidentiality of the cloud storage service stored data (records and index) is at risk.
  • FIG. 12 shows further details of the server computer system 322 and one 156 of the client computer systems, according to another embodiment of the invention.
  • the server computer system is assigned an asymmetric cryptographic key pair, which includes a public cryptographic key PubKS and a private cryptographic key privKS.
  • PubKS public cryptographic key
  • a copy of PubKS' of the public key is made available to the client computer system. This can be done directly, for example, ie in that the client computer system receives the key directly from the server computer system.
  • the key can also be transmitted indirectly, for example by the server computer system storing its public key in a publicly accessible database and the client computer system downloading the public key PubKS′ from this database.
  • the private key PrivKS is used to decrypt data encrypted with the public key PubKS.
  • the private key PrivKS is preferably stored in a protected manner and is only accessible to the server computer system, but not to one of the client computer systems.
  • the client computer system also has a private key privKC, which is stored in a protected manner, so that the private key PrivKC can only be read and used by the client computer system 156 (and optionally by other, authorized client computer systems 157, 159). however, from the server computer system.
  • a private key privKC which is stored in a protected manner, so that the private key PrivKC can only be read and used by the client computer system 156 (and optionally by other, authorized client computer systems 157, 159). however, from the server computer system.
  • the client computer system includes a tokenization logic 158, a classifier 432 for generating the partial token sets, an indexer for generation of partial indices from the partial token sets, and a DBMS with a database 102 according to one of the embodiments already described here.
  • the field values of the data records in the database 102 are tokenized by the client computer system.
  • the tokens of tokenset 162 (or 153) are classified by the classifier and divided into sub-tokensets, which are used by an indexer to generate a corresponding sub-index, such as in figures 1 , 2 and 3 was described.
  • the partial indices generated and the data records of the database 102 are encrypted. Different cryptographic keys are used to encrypt the data sets and the sub-indices.
  • the processing of the partial index 428 is described in more detail below. All other partial indices are preferably processed in the same way, ie encrypted, transmitted to the server and used there for rapid identification of data records sought, as described below.
  • the data records are preferably encrypted individually. This has the advantage that these can also be returned individually in encrypted form.
  • the individual data records are encrypted in such a way that the client computer system can decrypt them again, but not the server computer system 322, which is intended to store the encrypted data records and possibly keep them available for a large number of clients.
  • the key PrivKV can be a private, symmetric cryptographic key that can be used for both encryption and decryption of data.
  • the client computer system can have another asymmetric cryptographic key pair, both keys of this pair being known only to the client computer system 156 (and possibly other authorized client computer systems), but not to the server computer system.
  • the data record DR1 thus becomes the encrypted data record [[DR1]].
  • the encrypted data record [[DR3]] thus becomes the data record DR3.
  • the client computer system 156 encrypts the partial index 428 with the public key PubKS of the server computer.
  • the encrypted data records 326 and the encrypted partial index 324 are transmitted from the client computer system to the server computer system. This can be done, for example, directly via the network 155, for example the Internet. According to embodiments, the encryption and transmission of the data records takes place completely or incrementally at regular time intervals, with the index being newly formed, newly encrypted and newly transmitted in each case.
  • the transmitted encrypted sub-index 324' is decrypted by the server computer system using the server computer's private key PrivKS and stored as an unencrypted copy 154' of the sub-index 428 on one or more storage media 344 managed by the server computer system.
  • the received and encrypted data records 326 are also stored on the storage media 344, but without being decrypted since the server computer system does not have the keys that are necessary to decrypt the data records.
  • the server computer system provides an interface 336 that allows the client computer system 156, which provided the index and records, to access the subindex 428'.
  • the interface preferably also enables other client computer systems to access the index 428′, with the other client computer systems only being able to evaluate the encrypted data records provided by the server computer system if they also have a suitable decryption key PrivKC.
  • the second phase describes the process of a sample search query using an example.
  • a client application 334 on which client computer system 156 is instantiated, sends a search query 330 via interface 336 to the server computer system.
  • the search query contains a search value of 328, for example "2654645".
  • the index selector 434 analyzes the search value at the bit sequence level.
  • the index selector determines that of all transmitted and decrypted sub-indexes 426', 428', 430', the sub-index 428' contains tokens that are most similar to the search value in terms of bit sequence length and/or in terms of the occurrence of certain bit patterns .
  • the index selector selects subindex 128'.
  • the server computer system searches the selected unencrypted index 428' for a token that exactly matches the search value "2654645". For example, searching for this search value can identify a particular token within index 428' that references record DR3.
  • the data set DR3 is only available in encrypted form [[DR3]] on the server computer system.
  • the server computer system In response to the search query 330, the server computer system returns the identified, encrypted data record [[DR3]] in a response message 332 to the client computer system.
  • a decryption logic 340 of the client computer system which has access to the decryption key PrivKC, decrypts the data record and supplies the decrypted data record DR3 to the client application logic 334 as the result of the search query 330.
  • the illustration shows that for phase two, the original database 102 or the unencrypted data records DR1-DR7 do not need to be present on the client computer system. It is therefore possible that only one specific client computer system 156 is used to generate and encrypt the index or the encryption of the data records, while a large number of other client computer systems 157, 159 exclusively implement program logic that is used to carry out what is listed here in phase two steps is required. These other client computer systems therefore do not need a public key of the server PubKS and no tokenization logic to create the index, but they need a client application 334, a decryption logic 340 and the corresponding decryption key PrivKC for decrypting the records.
  • FIG 6 shows a flow chart of a method for classification of data according to an embodiment of the invention.
  • a tokenization logic 158 generates a set of tokens 153 ready.
  • a redundant set 162 of tokens can first be generated by tokenizing multiple field values of multiple data sets DR1-DR8, the tokens being generated from field values of at least two different field types F1-F8, the tokens being stored in the form of a bit sequence. This can then be converted into a non-redundant token set 153 by removing duplications.
  • a classification logic performs an analysis of the tokens of the token set at the bit sequence level, e.g.
  • subsets 420, 422, 424 of feature-like tokens are identified.
  • the classification logic 432 stores a copy of each of the subsets of feature-like tokens in subset-separated form.
  • the token subsets can be stored in different files or different directories.
  • Each of the subsets is stored in the form of a subindex 426,428,430.
  • Each subindex thus contains the tokens of the subset from which it is derived, with the position of the tokens within a subindex being independent of the type of field from which the token is derived.
  • Each subset copy represents a class of feature-like data.
  • the classes of feature-like data can each be interpreted and further processed in a cryptanalysis as candidates for a specific word or other semantic concept.

Description

    Technisches Gebiet
  • Die vorliegenden Darstellungen betreffen IT-Systeme und insbesondere Klassifizierungsverfahren im Kontext von Datenbankmanagementsystemen.
    • Stand der Technik
  • Aus dem Stand der Technik sind verschiedene Ansätze zur Datenklassifikation bekannt.
  • Beispielsweise können Dokumente oder Datensätze anhand der in diesen vorkommenden Wörtern klassifiziert werden. Die einzelnen Wörter innerhalb eines Dokuments werden automatisch mittels eines Textanalyse-Algorithmus erkannt. Bei sog. Co-occurrence-basierten Verfahren werden die Dokumente in Abhängigkeit von Art und/oder Anzahl der gemeinsam beinhalteten Wörter in Klassen ähnlicher Dokumente klassifiziert. Auch im Kontext der Bildanalyse werden digitale Bilddaten zunächst aufwändig analysiert um bestimmte Strukturen (Zellmembranen, Kerne, Organelle) zu identifizieren und anhand dieser Merkmale größere Strukturen zu identifizieren und zu klassifizieren (z.B. Krebszellen, Gefäße, Nervenzellen, u.a.). Die Aufbereitung der Daten für den Klassifizierungsalgorithmus sowie die Klassifikation selbst ist rechnerisch oftmals sehr aufwändig und erfordert umfangreiches Hintergrundwissen des Programmierers im Hinblick auf die zu erwartenden Objektklassen.
  • US Patentanmeldung US 2010/185629 A1 beschreibt Tools und Techniken zur Indexierung und Abfrage von Datenspeichern unter Verwendung von konkatenierten Begriffen. Diese Tools können Eingabefragen empfangen, die mindestens zwei Suchbegriffe enthalten. Die Suchbegriffe werden jeweils mit Feldern korreliert, die in Datensätzen innerhalb einem Datenspeicher enthalten sind, wobei diese Felder mit entsprechenden Feldwerten gefüllt werden. Die Suchbegriffe sind nach einer Indizierungspriorität angeordnet, nach der die Felder innerhalb einer Indizierungstabelle, die dem Datenspeicher zugeordnet ist, geordnet sind. Die Tools verknüpfen dann die Suchbegriffe wie nach der Indizierungspriorität angeordnet. Die Tools wiederum durchsuchen die Index-Tabelle nach allen Einträgen, die zu den verketteten Suchbegriffen korrespondieren.
  • Die Publikation "Partitioned Indexes" von Darl Kuhn et al. in "Expert Indexing in Oracle Database 11g: Maximum Performance for Your Database" vom 23. Dezember 2011 (Apress, Berkeley, CA, XP05545151 0, ISBN: 978-1-4302-3735-8 Seiten 115-140, 001: 10.1007/978-1-4302-3736-5) beschreibt partitionierte Indexstrukturen und ihre Verwendung. Normalerweise geht die Verwendung partitionierter Tabellen und Indizes Hand in Hand, auch wenn das nicht unbedingt notwendig ist. Es ist möglich, partitionierte Tabellen ohne partitionierte Indizes zu haben, und es ist möglich, eine nicht-partitionierte Tabelle mit partitionierten Indizes zu erstellen.
  • Patentanmeldung US 2014/314313 A1 beschreibt eine Suche nach einem Suchbild in einer Bilddatenbank und offenbart eine Klassifikation von Bildern auf Basis von deren visueller Ähnlichkeit.
    • Technisches Problem und grundlegende Lösungen
  • Mit den bekannten Klassifizierungsverfahren ist es oftmals nicht möglich, eine Klassifikation großer Mengen von Objekten auf schnelle, ressourcenschonende Weise (z.B. in Echtzeit auf einem Standardcomputersystem) durchzuführen. Bei der Klassifikation geschehen Fehler, da unvollständiges Wissen oder falsche Vorstellungen über die zu erwartenden Klassen zur Implementierung einer Klassifikationslogik herangezogen wurden. Außerdem sind relevante Klassifikationsmerkmale oft gar nicht zugänglich, z.B. wenn die Daten in verschlüsselter Form vorliegen. Vor diesem Hintergrund besteht ein Bedarf, ein verbessertes Verfahren zur Klassifikation von Daten und ein entsprechendes Datenklassifikationssystem bereitzustellen, welche die vorangehend erwähnten Nachteile zumindest teilweise vermeiden.
  • Die der Erfindung zugrundeliegenden Aufgaben werden jeweils mit den Merkmalen der unabhängigen Patentansprüche gelöst, und die Erfindung wird durch die unabhängigen Ansprüche definiert. Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen angegeben. Die im Folgenden aufgeführten Ausführungsformen sind frei miteinander kombinierbar, sofern sie sich nicht gegenseitig ausschließen.
  • In einem Aspekt betrifft die Erfindung ein computerimplementiertes Verfahren zur Datenklassifikation. Das Verfahren umfasst ein Bereitstellen einer Tokenmenge, die Token beinhaltet, die aus mehreren Feldwerten mehrerer Datensätze durch Tokenisierung erzeugt wurden. Die Token wurden aus Feldwerten von mindestens zwei unterschiedlichen Feldtypen erzeugt und sind in Form einer Bitsequenz gespeichert. Das Verfahren umfasst ferner die Analyse von einem oder mehreren Merkmalen der Token auf der Ebene der Bitsequenz, um Teilmengen merkmalsähnlicher Token zu identifizieren. Die Merkmale umfassen die Bitsequenz der Token und/oder die Länge der Bitsequenz. Das Verfahren umfasst ferner das Speichern einer Kopie jeder der Teilmengen merkmalsähnlicher Token in nach Teilmengen getrennter Form. Jede Teilmengenkopie repräsentiert jeweils eine Klasse merkmalsähnlicher Daten.
  • Dies kann vorteilhaft sein, da dieses Klassifizierungsverfahren sehr schnell mit vergleichsweise geringem Rechenaufwand durchgeführt werden muss: es ist nicht notwendig, zunächst die Daten in höheren Ebenen der Repräsentation zu initialisieren und zu analysieren, etwa auf der Ebene von Bytes und ASCII Charakteren oder gar auf der Ebene noch komplexerer Datenobjekte, etwa als Java-Objekte, deren Analyse die Instanziierung einer entsprechenden Laufzeitumgebung erfordert. Es entfällt also ein aufwändiges Initialisieren und ggf. Parsen von Datenobjekten höherer Ordnung und die Instanziierung einer hierfür notwendigen Laufzeitumgebung. Im Stand der Technik bekannte Klassifikationsverfahren sind dagegen rechnerisch oft deutlich aufwändiger. die Texte werden z.B. mittels syntaktischer Analyse und anderer komplexer Textmining-Algorithmen (Reduktion auf den Wortstamm, Entfernung von Stopwörtern, ggf. auch "part-of-speech" (POS) Tagging, u.a.). Außerdem werden müssen basierend auf der Ebene von ASCII Charakteren analysiert.
  • Es ist außerdem möglich, die Daten zu klassifizieren, auch wenn über den Inhalt der Daten keine oder nur wenige Informationen vorliegen. Dies kann z.B. der Fall sein wenn die Daten in verschlüsselter Form gespeichert sind. Es wird auch vermieden, dass fehlerhafte Vorstellungen des Programmierers über die semantische Bedeutung der Feldwerte und der daraus generierten Token Einfluss auf die Klassifizierung haben, denn die Ebene erfolgt auf der Ebene von Bitsequenzmustern, also nicht auf der Ebene der ASCII Charaktere oder anderer Datenmodelle höherer Ordnung, die bereits eine gewisse Kenntnis der Struktur der Daten bzw. des Bedeutungsgehalts der Token voraussetzen. Somit kann ein weitgehend "bedeutungsagnostisches" Klassifizierungsverfahren bereitgestellt werden, da auch auf Feldwerte bzw. Token unbekannten Inhalts angewendet werden, also z.B. auf verschlüsselte Feldwerte oder auf Datenfelder, bei welchem aus Effizienzgründen, z.B. im Kontext einer Echtzeitumgebung, ein inhaltliches Parsing der Daten nicht möglich ist.
  • In einem weiteren vorteilhaften Aspekt kann das Verfahren für eine Vielzahl unterschiedlicher Datentypen (Text, Bild, Video, Audio) bzw. Daten- bzw. Dateiformaten (.jpg, .png, .tif, etc.) verwendet werden, ohne dass hierfür ein spezialisierter Parser erstellt und in den Tokenisierungsprozess aufwändig eingebunden werden müsste. Vielmehr kann derselbe Tokenisierer auf eine Vielzahl unterschiedlicher Datentypen und Datenformaten angewendet werden oder auf Feldwerten, die in einem Feld mit einem generischen Datentyp gespeichert sind. Dies kann die Wartbarkeit, Flexibilität und Erweiterbarkeit des Klassifizierungssystems erheblich verbessern. In einem bestimmten Feld können also eine große Anzahl an unterschiedlichen Datentypen gespeichert werden. Ein Nutzer bzw. ein Applikationsprogramm, welches Datensätze in der Datenbank speichern will, muss sich also nicht um die Konsistenz und Passung von Datentypen kümmern. Außerdem verhindert die Verwendung von Feldtypen, die nicht auf einen bestimmten Datentyp (wie zum Beispiel Integer, Boolean, Varchar, etc.), beschränkt sind, bzw. denen ein sehr generischer Datentyp zugewiesen ist, dass ein unberechtigter Dritter, der sich Zugriff auf den Index verschafft hat, anhand der indizierten Datentypen Rückschlüsse auf den Inhalt der Attribute der ursprünglichen Datensätze ziehen kann.
  • Nach Ausführungsformen sind die Merkmale, die für die Ähnlichkeitsanalyse der Token analysiert werden, frei von Informationen bezüglich Bytesequenzen oder sonstiger Muster in höheren Ebenen der Datenrepräsentation. Es ist also nicht notwendig, die Token mittels datentypspezifischer Parser zu analysieren bzw. es wird eine aufwändige Repräsentation der in der Bitsequenz eines Tokens enthaltenen Daten auf einer höheren strukturellen Ebene vermieden.
  • Das Verfahren umfasst ferner eine Erzeugung eines Teilindex aus jeder der Teilmengen merkmalsähnlicher Token und eine Bereitstellung eines Indexauswahlprogramms. Das Indexauswahlprogramm ist dazu konfiguriert, automatisch denjenigen der Teilindices zu identifizieren, dessen Token dem Datenwert bezüglich Bitsequenz und/oder Bitsequenzlänge am ähnlichsten ist.
  • Nach Ausführungsformen wird die Tokenmenge als durchsuchbarer Index gespeichert. Die Tokenmenge wird zur Erstellung eines durchsuchbaren Index verwendet.
  • Das Verfahren kann den Empfang einer Suchanfrage, die einen Suchwert beinhaltet, umfassen. Als Antwort auf den Erhalt der Suchanfrage erfolgt eine Analyse des Suchwerts durch ein Indexauswahlprogramm und eine Identifikation desjenigen der Teilindices, dessen Token dem Suchwert bezüglich Bitsequenz und/oder Bitsequenzlänge am ähnlichsten ist. Sodann erfolgt ein Durchsuchen des identifizierten Teilindex anstatt des (Gesamt-)Index nach dem Suchwert.
  • Dies kann vorteilhaft sein, da der Arbeitsspeicherbedarf beim Indexzugriff reduziert wird: es muss nicht mehr der Gesamte Index in den Arbeitsspeicher geladen und durchsucht werden, sondern nur noch ein Teilindex. Es werden also weniger Rechenoperationen beim Durchsuchen des Index benötigt, das Laden des Index in den Arbeitsspeicher ist schneller und es wird nur ein geringerer Teil des Arbeitsspeichers belegt.
  • Vorzugsweise erfolgt die Generierung der Teilindices aus dem Gesamtindex vollautomatisch. Es ist dabei besonders vorteilhaft dass eine manuelle Erstellung der Teilindices bzw. eine manuelle Spezifikation der Kriterien, wann ein Token in welchen Teilindex zu speichern ist bzw. welcher Teilindex bei der Suche nach einem bestimmten Suchwert verwendet werden soll nicht mehr notwendig ist.
  • Nach Ausführungsformen umfasst das Verfahren eine Identifizierung eines indizierten Tokens innerhalb des identifizierten Teilindex, welcher identisch ist zu dem Suchwert und eine Analyse von Datensatz-Zeigern, die in dem Teilindex mit dem identifizierten Token verknüpft gespeichert sind, um ein oder mehrere der Datensätze zu identifizieren, welche ein oder mehrere Feldwerte beinhalten, aus welchen das indizierte Token erzeugt wurde, wobei die Datensätze in einer Datenbank gespeichert sind. Ferner erfolgt eine Zurückgabe der ein oder mehreren identifizierten Datensätze oder einer Referenz auf die ein oder mehreren identifizierten Datensätze als Antwort auf die Suchanfrage. Jeder der Teilindices kann somit zur raschen Identifikation desjenigen Datensatzes bzw. derjenigen Datensätze verwendet werden, der einen oder mehrere Feldwerte beinhaltete, aus welchen das identifizierte Token erzeugt wurde. Somit können die gewonnenen Teilindices im Kontext klassischer Datenbankapplikationen verwendet werden um diese zu beschleunigen.
  • Nach Ausführungsformen umfasst das Verfahren einen Empfang einer Schreibanfrage, wobei die Schreibanfrage einen Datenwert (z.B. einen Feldwert - z.B. DR8.F6) beinhaltet. Als Antwort auf den Empfang der Schreibanfrage erfolgt eine automatische Zerlegung des empfangenen Datenwerts durch die Tokenisierungslogik, die zur Tokenisierung der Datensätze verwendet wurde, in mehrere neue Token. Jedes neue Token wird als Bitsequenz in einem flüchtigen oder nicht-flüchtigen Speichermedium gespeichert. Zudem erfolgt eine Analyse jedes der neuen Token durch ein Indexauswahlprogramm. Das Indexauswahlprogramm identifiziert denjenigen der Teilindices, dessen Token dem neuen Token bezüglich Bitsequenz und/oder Bitsequenzlänge am ähnlichsten ist. Schließlich erfolgt ein Speichern des neuen Token in dem identifizierten Teilindex zusätzlich zu oder anstelle von Speicherung des neuen Token in einem Gesamtindex der Token.
  • Somit kann der Aufbau eines großen Index bzw. das stetige Wachsen des bestehenden Gesamtindex vermieden werden. Vielmehr können neue Token direkt in die jeweiligen Teilindices geschrieben werden. Beispielsweise kann das Indexauswahlprogramm z.B. regelbasiert arbeiten. Die Regeln können automatisch anhand der Ergebnisse der Klassifizierung (Anzahl und Art der gebildeten Token-Teilmengen) oder manuell vorgegeben werden. Die manuelle Vorgabe kann von einem Nutzer vorgenommen werden, der die Ergebnisse der Klassifizierung in explizite Regeln übersetzt (z.B. kann ein Nutzer mittels einer graphischen Benutzeroberfläche (GUI) die automatisch identifizierten Teilmengen der Token analysieren und feststellen, dass die Token anhand ihrer Bildgröße aufgeteilt wurden in eine erste Token-Teilmenge, deren Token weniger als 500 Bits umfasst, eine weitere Token-Teilmenge, deren Token zwischen 501 und 1000 Bits umfasst und eine weitere Token-Teilmenge, deren Token über 1001 Bits umfassen. Der Nutzer kann nun Regeln mittels der GUI spezifizieren, die vorgeben, dass neu erstellte Token in Abhängigkeit ihrer Bitsequenzlänge in eine der drei genannten Token-Teilmengen gespeichert wird.
  • Die Verwendung von Bitsequenzmustern und/oder Bitsequenzlängen als Klassifizierungskriterien kann vorteilhaft sein, da diese Merkmale bereits auf der untersten "strukturellen" Ebene, der Ebene der Bitsequenz selbst, erkannt werden können. Es ist also keine Instanziierung und Repräsentanz von Token auf höheren strukturellen Ebenen erforderlich um an diese Merkmale zu gelangen.
  • Die Klassifizierung anhand der Token-Bitsequenzlänge kann vorteilhaft sein, da diese Form der Klassifizierung bzw. der automatischen Erstellung von Teilindices in einer Vielzahl von Anwendungsszenarien verwendet werden kann, insbesondere im Kontext von Portalen und Plattformen, die der Verwaltung von Bildern dienen. Beispielsweise kann die Klassifikationssoftware zur Erstellung und Verwaltung eines Bildarchivs verwendet werden, in welchem es Bilder einer Vielzahl (vorher unbekannter) Bildgrößen gibt. Der Klassifizierer kann z.B. ein nichtüberwachter (nonsuperwised) Klassifizierer sein, der automatisch selbst erkennt ob die Bilder anhand ihrer Größe in zwei, drei oder noch mehr Teilmengen ähnlicher Größe aufgeteilt werden sollten. Beispielsweise kann der Klassifizierer zur Verwaltung von Bildern eines Homepageportals verwendet werden, in welchem es hunderte von kleinen Bildern (Thumbnail Bilder) und großen Bildern (Originale) gab. Die Tokenisierungslogik erkennt z.B. anhand bestimmter Bitmuster den Beginn und das Ende eines Bildes in einer Bitsequenz, z.B. Beginn und Ende eines .jpg Bildes, und verwendet diese Grenzen um ein Token zu erzeugen, das ein entsprechendes Bild codiert. Die Klassifizierungslogik analysiert die Bitsequenz der einzelnen Token um entsprechende Teilmengen der Bilder automatisch zu generieren, die eine ähnliche Größe haben und, z.B. zu archivierungszwecken, in getrennten Speicherbereichen gespeichert werden.
  • Nach Ausführungsformen wird das Verfahren zur automatischen Bildklassifizierung verwendet. Bei den Token handelt es sich um Bitsequenzen, die jeweils ein Bild kodieren, wobei die Bitsequenzlänge die Bildgröße repräsentiert. Die Teilmengen der Token beinhalten zumindest eine "Kleinbild-Teilmenge" und eine "Großbild-Teilmenge". In der "Kleinbild-Teilmenge" sind selektiv Token enthalten, deren Bitsequenzlänge unterhalb eines ersten Schwellenwerts liegt. In der "Großbild-Teilmenge" sind selektiv Token enthalten, deren Bitsequenzlänge einen zweiten Schwellenwert überschreitet.
  • Somit kann eine automatische Klassifizierung von Bildern anhand deren Auflösung bzw. Qualität vorgenommen werden.
  • Nach Ausführungsformen ist die Anzahl der Teilmengen unbekannt bei Analysebeginn. Vielmehr wird die Anzahl der gebildeten Token-Teilmengen dynamisch als Teil des Ergebnisses der Analyse der Merkmale der Token ermittelt. Die Analyse zur Identifikation der Teilmengen merkmalsähnlicher Token wird von einem nichtüberwachten Machinelearning Algorithmus durchgeführt.
  • Dies kann vorteilhaft sein, da die Anzahl der Token-Teilmengen bzw. der aus diesen gebildeten Teilindices "data-driven", also in Abhängigkeit der analysierten Token, dynamisch ermittelt wird. Dadurch wird vermieden, dass durch falsche (Vor)annahmen des Programmierers bezüglich der zu erwartenden Klassen eine unnötige "Zersplitterung" ähnlicher Token in viele unterschiedliche Teilmengen oder Teilindices oder eine Zusammenfassung zu vieler unähnlicher Token in einen (zu großen) Teilindex erfolgt. Beides kann die Performance reduzieren: ein zu großer Teilindex belegt unnötig viel Arbeitsspeicher, zu viele zu kleine Teilindices verursachen zusätzliche Kosten was den Aufwand der Initialisierung und Verwaltung der Teilindices angeht.
  • Nach der automatischen Erstellung der Token-Teilmengen kann ein Mensch oder eine Programmlogik (Software, Firmware oder Hardware) die Token-Teilmengen analysieren und von Hand oder automatisch Regeln für einen Index-Selektor zu definieren. Der Index-Selektor ist eine Programmlogik, die diese Regeln auf einen Eingangswert (z.B. ein Suchwert) anwendet, um einen Teilindex auszuwählen/eine Teiltokenmenge (z.B. bildgrößenabhängiges Bilderarchiv-Directory) auszuwählen, um neues Bild in passendem Teilindex/Teilarchiv-Directory zu speichern.
  • Nach Ausführungsformen sind die Datensätze in verschlüsselter Form in einer Datenbank gespeichert. Das Bereitstellen der Tokenmenge umfasst eine Anwendung einer Tokenisierungslogik auf die verschlüsselten Feldwerte der Datensätze auf der Bitsequenzebene der um die Token zu generieren. Die Analyse der Merkmale der Token erfolgt auf der Ebene der Bitsequenz der Token. Die Teilmengen merkmalsähnlicher Token umfassen jeweils Token, die sich im Hinblick auf ihre Bitsequenz und/oder die Länge ihrer Bitsequenz ähneln.
  • Nach Ausführungsformen umfasst das Verfahren ferner eine Verwendung der Teilmengen merkmalsähnlicher Token jeweils als Input eines Dekodieralgorithmus, wobei die Teilmengen jeweils einen Kandidaten für ein natürlichsprachliches Wort oder einen anderen von einem Menschen interpretierbaren Code repräsentieren und wobei der Dekodieralgorithmus dazu ausgebildet ist, durch Analyse der Token einer Teilmenge das natürlichsprachliche Wort oder den anderen von einem Menschen interpretierbaren Code zu identifizieren.
  • Nach Ausführungsformen umfasst das Verfahren ein Bereitstellen eines DBMS, das dazu konfiguriert ist, die Datensätze jeweils als eine Menge aus mehreren Feldwerten zu speichern. Die Feldwerte werden dabei jeweils in einem Feld gespeichert.
  • Die Erzeugung der Tokenmenge kann ein Erzeugen von ersten und zweiten Token umfassen. Die ersten Token werden aus ersten Feldwerten mehrerer Datensätze erzeugt, wobei die ersten Feldwerte in ersten der Felder gespeichert sind, wobei die ersten Felder einem ersten Feldtyp angehören. Die zweiten Token werden aus zweiten Feldwerten der mehreren Datensätze erzeugt. Die zweiten Feldwerte sind in zweiten der Felder gespeichert. Die zweiten Felder gehören einem zweiten Feldtyp an.
  • Dies kann vorteilhaft sein, da die auf diese weite generierte Tokenmenge bzw. der auf diese Weise generierte Gesamtindex oder die Teilindices, sollten diese z.B. durch Datendiebstahl in die Hände unberechtigter Dritter gelangen, deutlich weniger an potentiell sensible Informationen preisgeben als dies bei herkömmlichen Datenbankindices der Fall ist.
  • Klassischerweise wird je ein Index für den Inhalt einer bestimmten Tabellenspalte generiert. Eine Tabellenspalte repräsentiert dabei oftmals ein bestimmtes Attribut von Datenobjekten, die in der jeweiligen Tabelle gespeichert sind. D.h., klassischerweise kann für eine Tabelle "Angestellte" beispielsweise ein Index für die Spalte "Vorname", ein weiterer Index für die Spalte "Nachname", ein weiterer Index für die Spalte "Position", ein weiterer Index für die Spalte "Geburtsjahr", ein weiterer Index für die Spalte "Personalausweis-ID" usw. erstellt werden. Sollten all diese Indexstrukturen für die Tabelle "Angestellte" in falsche Hände geraten, so ist es für unberechtigte Dritte ein leichtes, anhand der Indexstrukturen die vollständigen Datensätze, die in der Tabelle gespeichert sind, zu rekonstruieren. Da die Felder einzelnen indexiert sind, ist anhand des Indexnamens oder zumindest anhand des Inhalts in der Regel klar ersichtlich, für welche Art von Attributen ein in einem Index gespeicherter Datenwert steht. Sogar für den Fall dass die Tabelle "Angestellte" keine Klarnamen, sondern stattdessen numerische Pseudonyme enthält, wird anhand der Indexstruktur deutlich, dass ein numerischer Wert, der in der Spalte "Name" bzw. "Pseudonym" gespeichert ist, die Funktion eines Identifikators des entsprechenden Datensatzes und nicht einfach ein beliebiges Attribut des Objekts repräsentiert.
  • Demgegenüber beinhaltet die Tokenmenge bzw. der Index/die Teilindizes, die gemäß Ausführungsformen der Erfindung erstellt werden, einen deutlich erhöhten Schutz der in ihm gespeicherten Daten. Dies liegt daran, dass die Feldwerte zumindest einiger der Felder der Datensätze tokenisiert werden. Ein (Teil)-Index, der auf diesen Token aufbaut, und der die Token unabhängig von dem Typ des Feldes, von welchen diese stammen, in der Indexstruktur speichert, lässt also keine Rückschlüsse darauf zu, ob ein bestimmtes Token den gesamten Feldwerte repräsentiert oder nur einen Teil davon, und lässt auch keinen Rückschluss darauf zu von welchem Feldtyp es abstammt. Ein bestimmter indizierter Zahlenwert in dem Index kann also gleichermaßen den Geburtstag des Angestellten, ein Erscheinungsdatum eines Artikels, in welchem über den Angestellten berichtet wird, eine ID des Angestellten, eine ID eines Presseartikels, in welchem über den Angestellten berichtet wird, eine Kennung eines Personalausweises, eines Kraftfahrzeugs, eines Geschenk-Gutscheins des Angestellten oder sonst eines beliebigen Attributes sein, welches mit einem bestimmten Objekt/Angestellten in mehr oder weniger enger semantische Beziehung steht.
  • Ausführungsformen der Erfindung stellen somit einen "chaotischen" bzw. "obfuszierten" Suchindex bereit, der sogar dann, falls er unbeabsichtigterweise an unberechtigte Dritte gelangt, oftmals keinen Rückschluss auf den Inhalt der in diesem indizierten Datensätze zulässt. Sensible Datensätze werden also erst dann semantisch transparent, wenn zusätzlich zu dem Index auch die eigentlichen Datensätze gestohlen werden. Vorzugsweise beinhaltet jeder Datensatz oder zumindest die Mehrzahl aller Datensätze eine Vielzahl von Feldern, von welchen wiederum viele Felder einen Datenwert beinhalten, der sich jeweils in eine Vielzahl unterschiedlicher Token zerlegen lässt. Dadurch kann sichergestellt werden, dass der Sinngehalt der einzelnen Datensätze rein anhand des Index nicht rekonstruiert werden kann, obwohl sämtliche Token, die aus den Feldwerten eines Datensatzes generiert und in dem Index gespeichert wurden, auf den Datensatz, von welchem sie stammen, referenzieren. Somit können Ausführungsformen der Erfindung einen Suchindex bereitstellen, welcher "security by obscurity" für die in ihm indizierten Daten bietet.
  • Beispielsweise können die Datensätze, die jeweils ein bis mehrere Datenwerte beinhalten, an eine Datenbank, z.B. eine Mitarbeiterdatenbank einer Firma, bereitgestellt werden und in der Datenbank so gespeichert werden, dass die Datenwerte je in unterschiedliche Felder gespeichert werden. Bei den unterschiedlichen Feldern kann es sich beispielsweise um Felder wie "Vorname", "Nachname", "Funktion in der Firma", "Portraitfoto", "Geburtsdatum", "Personalnummer", "Kreditkartennummer", und "verantwortetes Produktportfolio" handeln. Die Felder der Datenbank können also bestimmten semantischen Kategorien zugeordnet sein, ohne dass jedoch alle Felder auf einen bestimmten Datentyp festgelegt sind. Beispielsweise kann das Feld "verantwortetes Produktportfolio" eine bei den meisten Mitarbeitern eine Zusammenstellung aus Bilddaten der jeweiligen Produkte, Textdaten die die Produkte beschreiben, sowie ggf. audiovisuelle Daten zu den Produkten oder zu dem Mitarbeiter. Es ist also möglich, dass ein oder mehrere oder auch alle Felder der Datenbank nicht auf einen bestimmten Datentyp beschränkt sind. Typischerweise werden in manchen Feldern, z.B. "Geburtstag", nur Datumswerte gespeichert sein, im Feld "Kreditkarte" nur Zahlenwerte, aber zumindest manche Felder, wie z.B. "verantwortetes Produktportfolio" enthalten eine Mischung von Datenwerten unterschiedlichen Typs, und auch die Felder, die aufgrund der Programmlogik, die die Datenwerte in die jeweiligen Felder schreibt, nur Daten eines bestimmten Typs enthalten, können Felder sein, die vom DBMS, das die Datenbank verwaltet, nicht auf einen Datentyp beschränkt sind.
  • Vorzugsweise ist die Programmlogik, die die Datensätze zur Speicherung in den Feldern der Datenbank bereitstellt, so konfiguriert, dass sie vordefinierte Bitmuster als Prefix und/oder Suffix von Daten, die einem bestimmten Typ angehören (z.B. Bilddaten, Bilddaten eines bestimmten Dateiformats, Bildelementen, Textdaten, Textelementen, z.B. einzelnen Wörtern oder Sätzen, Zahlenwerten, Datumsangaben, Audiodaten, Videodaten, etc.) oder die eine bestimmte vordefinierte Größe haben (0-100 bit, 101-1000 bit, > 1001 bit, etc) so einfügt, dass ein Tokenisierer, der einen Gesamtindex und/oder Teilindices der Datenbank erstellt, eine Tokenisierung der in den Feldern gespeicherten Daten dort vornimmt, wo diese vordefinierten Bitmuster eingefügt wurden. So könnte beispielweise das Bitmuster 1001101010101010011 den Beginn einer Datumsangabe spezifizieren und das Bitmuster 1001101010101010010 das Ende einer Datumsangabe spezifizieren. So könnte beispielweise das Bitmuster 1001111110101010011 den Beginn einer jpg-Bilddatei spezifizieren und das Bitmuster 1001111110101010010 das Ende einer jpg-Bilddatei spezifizieren. Beim Befüllen der Felder der Datenbank mit Datenwerten kann also beispielsweise das Feld "Geburtstag" für einen bestimmten Mitarbeiter M1 aus der Bitsequenz 1001101010101010011<BITSEQUENZ-DES-GEBURTSTAGS-1001101010101010010 bestehen, wobei BITSEQUENZ-DES-GEBURTSTAGS abhängig ist vom jeweiligen Geburtstag und der Art und Weise, wie Datumsangaben im jeweiligen DBMS im Bitformat repräsentiert werden. Das Feld "verantwortetes Produktportfolio" besteht typischerweise aus einer Mischung von Textangaben, Datumsangaben (z.B. wann ein bestimmtes Produkt auf den Markt gebracht wurde), Zahlenangaben (z.B. Produktpreis, Produktabmessungen). Die Programmlogik zur Speicherung der Datensätze würde also Datumswerte, Zahlenangaben, etc. mit entsprechenden Bitmustern als Prefix und/oder Suffix versehen, sodass die in diesem Feld gespeicherte Bitsequenz eine lange Sequenz verschiedenster Nutzdaten, eingefasst bzw. abgegrenzt von anderen Nutzdaten durch die vordefinierten Bitmuster, darstellt. Die als Prefix und/oder Suffix in die Nutzdaten bei der Speicherung eingeführten Bitmuster werden nach Ausführungsformen von dem Tokenisierer als Delimiter bei der Tokengenerierung verwendet. Der Tokenisierer würde also in dem hier beschriebenen Beispiel die in dem Feld "verantwortetes Produktportfolio" gespeicherte Bitsequenz anhand der vordefinierten Bitmuster in mehrere Token (z.B. Datumsangaben zur Markteinführung der Produkte, Zahlenangaben zu den Preisen und Abmessungen, etc) zerlegen, die dann anhand ihrer Ähnlichkeit im Hinblick auf deren Bitsequenz (z.B. gleicher Prefix und/oder gleicher Suffix) und/oder im Hinblick auf die Ähnlichkeit der Bitsequenzlänge der Token (Token, die Datumsangaben repräsentieren, haben ähnliche oder identische Länge, die sich von den Token von Bilddaten zumeist unterscheidet) klassifiziert werden und/oder zur Generierung der Teilindizes verwendet werden. Das bedeutet, dass Zahlenangaben, unabhängig davon, ob sie eine Kreditkartennummer oder die Länge oder Höhe eines verantworteten Produkts darstellen, im gleichen Teil-Index gespeichert werden. Dieser Teilindex enthält also eine Mischung aus potentiell sensiblen Daten (Kreditkartennummer) und unproblematischen Daten (Abmessungen eines Produkts) und lässt keine Rückschlüsse darauf zu, welche Bedeutung ein bestimmter Zahlenwert hat. Vorzugsweise verwendet der Tokenisierer die gleichen Bitmuster, die von der Logik zur Speicherung der Daten als Prefix und/oder Suffix in die zu speichernden Nutzdaten eingebracht wurden, zur Tokenisierung. Die explizite Einfügung von vordefinierten Bitmustern als Prefix und/oder Suffix in Bestandteile der Datenwerte der Datensätze ist jedoch nur eine mögliche Implementierung. Oftmals enthalten Daten eines bestimmten Typs oder Dateiformats, wie sie vom DBMS in Form einer Bitsequenz gespeichert werden, ohnehin bereits Bitsequenzen, die eine automatische Erkennung von Zahlenwerten in Abgrenzung etwa von Bilddaten oder ähnlichem ermöglichen. Eine explizite Ergänzung vordefinierter Bitmuster bei der Speicherung der Datensätze ist hier also nicht erforderlich. Auch kann eine Klassifizierung rein anhand der Tokengröße (Länge der Bitsequenz der einzelnen Token) erfolgen. Der Tokenisierer kann vorzugsweise auch zur Verarbeitung einer vom Nutzer bereitgestellten Suchbegriffs verwendet werden, sodass nach Ausführungsformen der verarbeitete Suchbegriff die gleichen Bitmuster als Prefix und/oder Suffix hat bzw. an diesen in ein Suchtoken verwandelt wird wie die in den Teilindizes gespeicherten Datenwerte.
  • Nach Ausführungsformen handelt es sich bei den Datensätzen um pseudonyme Datensätze, die keine Klarnamen von Personen enthalten.
  • Nach Ausführungsformen wird auf die ersten und zweiten Felder die gleiche, generische Tokenisierungslogik angewandt.
  • Dies kann in Kombination mit der Analyse auf der Bitsequenzebene vorteilhaft sein, da somit das gleiche Tokenisierungsverfahren auf eine Vielzahl von Feldern oder sogar auf alle Felder der in einer Datenbank gespeicherten Daten angewandt werden kann. Es ist also keine komplexe Tokenisierungslogik notwendig, die in Abhängigkeit unterschiedlicher Datenformate unterschiedlicher Tabellenspalten jeweils unterschiedliche Tokenisierungsalgorithmen auf "höherstrukturierten" Datenobjekten anwendet bzw. für die Tokenisierung Datenobjekte auf einer höheren strukturellen Ebene instanziiert. Somit kann die Datenbank leicht um weitere Felder erweitert werden und es können sogar unterschiedliche Datentypen in verschiedenen Feldern verwendet werden oder enthalten sein, ohne dass zwingend wesentliche Änderungen an der Tokenisierungslogik vorgenommen werden müssen. Die Kombination aus dem generischen Tokenisierer mit dem bitsequenzbasierten Klassifizierer wird somit auch bei einer Erweiterung von Datensätzen um weitere Felder im Wesentlichen das gleiche Klassifikationsergebnis der daraus generierten Token liefern. Somit wird ein Datenklassifikationsverfahren im Kontext einer Datenbank bereitgestellt, welches weitgehend robust ist gegen strukturelle Änderungen in der Datenbank, also beispielsweise dem Hinzufügen oder Entfernen von Datenfeldern bzw. "Spalten".
  • Optional kann die Erzeugung der Token eine Verwendung weiterer Feldwerte in ihrer Gesamtheit als weitere Token umfassen. Beispielsweise können die ersten und zweiten Felder Bitsequenzen enthalten, die einen Fließtext mit ein oder mehreren Bildern kodieren, wobei Teilsequenzen, die Bilder (und optional möglicherweise auch einzelne Wörter oder Wortsequenzen) codieren, im Zuge der Tokenisierung als Token erkannt und als Token der Tokenmenge hinzugefügt werden.
  • Es kann aber auch zumindest ein drittes Feld geben, in welchem nur Bilder gespeichert sind (auch wenn das Datenformat an sich nicht auf ein Bildformat beschränkt ist, z.B. weil dem dritten Feld ein generisches Datenformat oder kein Datenformat zugewiesen ist). Somit ist es durchaus möglich, dass die Tokenmenge auch Token aus Feldern von Feldtypen beinhaltet, auf die keine Tokenisierung angewandt wird oder deren Inhalt sich schlichtweg nicht von dem verwendeten Tokenisierer in einzelne Token aufteilen lässt.
  • Nach Ausführungsformen sind die Datensätze in einer Datenbank gespeichert, die von einem DBMS verwaltet wird. Die Datensätze umfassen unterschiedlich viele Felder. Vorzugsweise werden alle Feldwerte in allen Feldern eines Datensatzes mit derselben Tokenisierungslogik tokenisiert. Dies kann vorteilhaft sein, da eine Erzeugung zu vieler kleiner Teilindices vermieden werden kann, was z.B. dann geschehen kann, wenn für jedes Feld eigene Teilindices generiert würden. Somit kann insbesondere bei Datenbanken mit variablen Feldern und Feldtypen bzw. unbekannter Bedeutung der einzelnen Felder eine breite und gegenüber strukturellen Änderungen robuste Datenbasis für die Tokenklassifizierung geschaffen werden.
  • Dies kann zudem vorteilhaft sein, da ein sehr hoher Grad an Flexibilität bezüglich der Struktur und des Umfangs der Datensätze, die von dem erfindungsgemäßen DBMS verwaltet und gespeichert werden können, geboten wird.
  • Nach Ausführungsformen besitzen mehrere der Felder eines jeden Datensatzes ein gemeinsames, generisches Datenformat. Das generische Datenformat erlaubt die Speicherung von Feldwerten, die sowohl Textdaten als auch zumindest Bilddaten, Audiodaten und/oder Videodaten beinhalten. Somit können leicht weitere Datenfelder ergänzt werden, ohne dass hierfür eine Anpassung des Tokenisierungs- und/oder Klassifizierungsverfahrens notwendig ist.
  • Nach Ausführungsformen ist die Tokenisierungslogik dazu ausgebildet, die Bitsequenz eines Datenfeldwertes auf der Bitebene zu analysieren und in Abhängigkeit von darin erkannten Bitsequenzmustern die Bitsequenz in die einzelnen Token zu tokenisieren.
  • Dies kann vorteilhaft sein, da nicht nur die Klassifizierung, sondern schon bereits die Tokenisierung auf der Bitebene erfolgt und somit die oben genannten, Ressourcenkonsumierenden Schritte zur Instanziierung von Datenobjekten höherer struktureller Ordnung und ggf. auch eine Instanziierung einer entsprechenden Laufzeitumgebung bzw. Programmlogik zum Analysieren solcher Datenobjekte vermieden werden kann.
  • Nach Ausführungsformen umfasst das Verfahren die Speicherung der Datensätze in einer Datenbank, die durch ein Datenbankmanagementsystem (DBMS) verwaltet wird, wobei es sich bei dem DBMS um ein NoSQL-DBMS handelt.
  • Die Verwendung von NoSQL Datenbanken kann vorteilhaft sein, da diese Form des DBMS bezüglich der Hinzufügung und Verwaltung von Feldern besonders flexibel ist und somit zur Verwaltung heterogener Datensätze besonders geeignet ist.
  • Nach Ausführungsformen ist die Tokenisierungslogik ein generischer Tokenisierer, der zur Tokenisierung von Feldwerten von Feldern unterschiedlicher Feldtypen ausgebildet ist. Die Anwendung der generischen Tokenisierungslogik auf einen Feldwert umfasst ein Erkennen von Daten unterschiedlichen Datentyps innerhalb des Feldwertes, wobei die Daten unterschiedlichen Datentyps Textdaten sowie Bilddaten und/oder Audiodaten und/oder Videodaten umfassen.
  • Nach Ausführungsformen ist die Tokenmenge als durchsuchbarer Index ausgebildet. Alternativ dazu kann die Tokenmenge auch als solches gespeichert sein, z.B. als Bitsequenzliste, und zur Erzeugung des durchsuchbaren Index verwendet werden. Der Ort der Speicherung der Token in der Struktur des Index erfolgt dabei unabhängig davon, von welchem der Feldtypen die Token stammen. Die Generierung eines einzigen Index ("Gesamtindex") aus den Token mehrerer Felder hat den Vorteil, dass dieser zur schnellen Bearbeitung von Datenbankabfragen verwendet werden kann. In einem weiteren vorteilhaften Aspekt ist dieser Index auch deutlich kleiner als dies der Fall wäre, würde man einen Index für jeden Feldtyp separat anlegen, zumindest dann wenn einige Token in Feldern unterschiedlichen Typs vorkommen. Vorzugsweise wird jedoch aus jeder der Token-Teilmengen ein eigener Teilindex erstellt und ein geeigneter Teilindex zur Beantwortung einer Datenbankabfrage dynamisch erkannt und anstatt des Gesamtindex verwendet. Der Ort der Speicherung der Token in der Struktur jedes der Teilindizes erfolgt ebenfalls unabhängig davon, von welchem der Feldtypen die Token stammen.
  • Nach Ausführungsformen hat der Index (Gesamtindex) und/oder jeder der Teilindizes die Struktur eines Baums, insbesondere eines B+ Baums. Diese Struktur kann die notwendige Zeit zur Identifikation eines bestimmten indizierten Token, das identisch zu einem Suchwert ist, erheblich beschleunigen.
  • Nach Ausführungsformen speichert der (Gesamt)Index sämtliche aus den Feldwerten der Datensätze einer Datenbank erzeugten Token so, dass der Index jedes Token nur einmal enthält. Jedes Token beinhaltet Zeiger auf ein oder mehrere der Datensätze, aus deren Feldwerten es erzeugt wurde. Auch jeder der Teilindizes ist eine Menge an nur einmal in diesem Teilindex vorkommenden Token.
  • Nach Ausführungsformen sind die in dem Index und/oder jedem der Teilindizes gespeicherten Token frei von Referenzen auf Felder oder Feldtypen, die zur Speicherung von Feldwerten verwendet wurden, die zur Erzeugung der Token dienten.
  • Die hier für verschiedene Ausführungsformen beschriebenen Verfahren können z.B. als Software, Firmware und/oder Hardware implementiert sein. Vorzugsweise sind sie in Form von ein oder mehreren Softwareprogrammen oder Modulen implementiert, die auf einem monolithischen oder verteilten Computersystem ausgeführt werden. Beispielsweise kann der Tokenisierungsschritt von einem Tokenisierungsprogramm und der Klassifizierungsschritt von einem Klassifikationsprogramm durchgeführt werden. Es ist jedoch auch möglich, dass Tokenisierung und Klassifizierung durch dasselbe Softwareprogramm durchgeführt werden.
  • Nach Ausführungsformen umfasst das Verfahren den Empfang einer Suchanfrage, die einen Suchwert enthält. Als Antwort auf die Suchanfrage wird ein Gesamtindex oder, vorzugsweise nur ein Teilindex nach dem Suchwert durchsucht und ein indiziertes Token in dem durchsuchten Index identifiziert, das identisch ist zu dem Suchwert. Das Verfahren umfasst eine Analyse von Datensatz-Zeigern, die in dem durchsuchten Gesamtindex bzw. Teilindex mit dem identifizierten Token verknüpft gespeichert sind, um ein oder mehrere der Datensätze zu identifizieren, welche ein oder mehrere Feldwerte beinhalten, aus welchen das indizierte Token erzeugt wurde. Die ein oder mehreren identifizierten Datensätze oder einer Referenz auf die ein oder mehreren identifizierten Datensätze werden als Antwort auf die Suchanfrage an den anfragenden Client zurückgegeben.
  • Nach Ausführungsformen sind die Datensätze in verschlüsselter Form in der Datenbank gespeichert. Die Datensätze werden aber zusätzlich einzeln verschlüsselt und in einzeln verschlüsselter Form gespeichert, z.B. auf einem Client-Computer, der die Datenbank beinhaltet oder Zugriff auf diese hat. Die Datensätze sind so verschlüsselt, dass ein Server-Computersystem, auf dem die verschlüsselten Daten später gespeichert werden, diese nicht entschlüsseln kann. Die unverschlüsselten Datensätze, die jeweils aus ein oder mehreren Feldwerten bestehen, werden wie beschrieben tokenisiert, klassifiziert und in Teil-Tokenmengen und Teilindices gespeichert. Tokenisierung, Klassifizierung und Teilindex-Generierung kann ebenfalls auf dem Client-Computersystem erfolgen. Die Teilindices werden nun mit einem öffentlichen Schlüssel eines Server-Computersystems verschlüsselt und an das Servercomputersystem zusammen mit den verschlüsselten Datensätzen an das Server-Computersystem übertragen. Das Server-Computersystem entschlüsselt die Teil-Indizes mit seinem privaten Schlüssel, der zusammen mit dem öffentlichen Schlüssel des Server-Computersystems ein asymmetrisches kryptographisches Schlüsselpaar bildet. Das Server-Computersystem empfängt und speichert die Datensätze in verschlüsselter Form ohne diese entschlüsseln zu können. Das Server-Computersystem kann z.B. ein verteiltes Computersystem eines Cloudspeicherdienstes sein.
  • Das Server-Computersystem kann nun eine Suchanfrage dieses oder eines anderen Client-Computersystems, die einen Suchwert beinhaltet, empfangen, einen der Teil-Indizes identifizieren, der den Suchwert voraussichtlich enthält, und den identifizierten Index durchsuchen. Das Server-Computersystem gibt sodann ein oder mehrere verschlüsselte Datensätze, die in der Teilindex-Suche ermittelt wurden, an den Client zurück, von welchem die Suchanfrage stammt. Dies kann vorteilhaft sein, da es somit möglich ist, auch sensible Daten auf einem Cloudspeicherdienst (Server-Computersystem) zu speichern, dem nicht vertraut wird, wobei die Daten in einem Index durchsuchbar sind, ohne dass diese sensiblen Daten dem Cloudspeicherdienst bekannt werden können: in dem Index ist keine Information darüber enthalten, von welchem Feld die einzelnen Token stammen und es ist somit nicht bekannt, ob ein bestimmtes Token, z.B. eine Zahl, eine Ausweisnummer, ein Zertifikat, ein Datum oder ein Messwert ist. Zwar referenzieren die Token auf die Datensätze, diese liegen jedoch verschlüsselt vor sodass der Cloudspeicherdienst nicht auf den Inhalt der Datensätze zugreifen kann.
  • Nach Ausführungsformen werden die Datensätze durch ein Client-Computersystem jeweils einzeln so verschlüsselt, dass das Client- Computersystem diese wieder entschlüsselt kann, nicht jedoch ein Server- Computersystem, das zum Empfang der verschlüsselten Datensätze bestimmt ist.
  • Nach Ausführungsformen stellt das Server-Computersystem eine Schnittstelle bereit um das Client- Computersystem oder anderen Computersystemen einen Zugriff auf den entschlüsselten Teilindex zu ermöglichen. Die Schnittstelle kann eine Index-Auswahl ("Selektor")-Funktionalität beinhalten. Als Antwort auf den Empfang der Suchanfrage ermittelt die Schnittstelle denjenigen der Teilindexes, dessen Token im Hinblick auf Bitsequenz und/oder Bitsequenzlänge dem Suchwert am ähnlichsten sind, und durchsucht den ermittelten unverschlüsselten Teilindex nach dem Suchwert. Schließlich gibt das Server-Computersystem ein oder mehrere anhand der Indexsuche identifizierte, verschlüsselte Datensätze über ein Netzwerk, z.B. das Internet, an das Computersystem, von welchem die Anfrage stammt, zurück. Das Computersystem, das die verschlüsselten Datensätze empfängt, hat vorzugsweise einen geeigneten Schlüssel, um diese Datensätze wieder zu entschlüsseln.
  • In einem weiteren Aspekt betrifft die Erfindung ein Computersystem zur Datenklassifikation. Das Computersystem umfasst ein oder mehrere Prozessoren, ein Datenspeichermedium (das auch in Form mehrerer operativ verbundener Speichermedien ausgebildet sein kann) und ein DBMS, das dazu konfiguriert ist, Datensätze jeweils als eine Menge aus mehreren Feldwerten in den ein oder mehreren Datenspeichermedien zu speichern. Die Feldwerte werden jeweils in einem Feld gespeichert. Die Felder jedes der Datensätze gehören mindestens zwei unterschiedlichen Feldtypen an. Außerdem umfasst das Computersystem eine Programmlogik, die zur Erstellung einer Tokenmenge konfiguriert ist. Die Tokenmenge beinhaltet Token, die aus mehreren Feldwerten mehrerer der Datensätze durch Tokenisierung erzeugt wurden. Die Token entstammen Feldwerten von mindestens zwei unterschiedlichen Feldtypen und sind in Form einer Bitsequenz in dem Speichermedium gespeichert.
  • Außerdem umfasst das Computersystem eine Klassifikationslogik, die zur Analyse von einem oder mehreren Merkmalen der Token auf der Ebene der Bitsequenz ausgebildet ist, um Teilmengen merkmalsähnlicher Token zu identifizieren. Die Merkmale umfassen die Bitsequenz der Token und/oder die Länge der Bitsequenz der Token. Die Klassifizierungslogik ist ferner dazu ausgebildet, eine Kopie jeder der Teilmengen merkmalsähnlicher Token in nach Teilmengen getrennter Form in dem Datenspeichermedium zu speichern, wobei jede Teilmengenkopie jeweils eine Klasse merkmalsähnlicher Daten repräsentiert.
  • Unter einem "Datenbankmanagementsystem" oder "DBMS" wird im Folgenden ein elektronisches System zur Speicherung und Wiedergewinnung von Daten verstanden. Vorzugsweise werden die Daten in dem DBMS widerspruchsfrei und dauerhaft gespeichert und verschieden Anwendungsprogrammen und Nutzern in bedarfsgerechter Form effizient zur Verfügung gestellt. Ein DBMS kann typischerweise ein oder mehrere Datenbanken beinhalten und die darin enthaltenen Datensätze verwalten. Bei dem DBMS handelt es sich vorzugsweise um ein feldorientiertes DBMS, also um ein DBMS, das dazu konfiguriert ist, Teile einzelner Datensätze, sogenannte "Feldwerte", in mehrere unterschiedliche Felder zu speichern.
  • Unter einem "Datensatz" wird im Folgenden eine inhaltlich zusammenhängende und gemeinsam von einem Datenbankmanagementsystem verwaltete Menge an Daten verstanden. Ein Datensatz stellt typischerweise die kleinste strukturelle Einheit des Datenbestandes einer bestimmten Datenbank dar. Beispielsweise kann ein einzelner Datensatz ein bestimmtes physisches Objekt, z.B. eine natürliche Person, repräsentieren. Bei der Person kann es sich z.B. um einen Angestellten, einen Patienten, einen Kunden, etc. handeln. Der entsprechende Datensatz kann eine vordefinierte Menge von Attributwerten dieser Person beinhalten (z.B. Name oder Pseudonym, Alter, Größe, Gewicht, Geburtsdatum, Ausweisnummern, Sicherheitszertifikate, Authentifizierungscodes, biometrische Daten und andere).
  • Beispielsweise kann ein Datensatz eine Gruppe von inhaltlich zusammenhängenden (zu einem Objekt gehörenden) Datenfeldern repräsentieren, z. B. Artikelnummer, Artikelgröße, Artikelfarbe, Artikelname oder ähnliches. Die Feldtypen ,Name', 'Adresse' und ,Geburtsdatum' könnten z.B. die logische Struktur eines Datensatzes zum Objekttyp "Person" bilden. Datensätze entsprechen einer logischen Struktur, die bei der Entwicklung der Datenbank festgelegt wurde und in manchen Ausführungsformen auch noch zur Laufzeit der Datenbank verändert werden kann, z.B. durch Hinzufügen, Entfernen oder Umbenennen von Feldern. In der Datenverarbeitung werden Daten zu Datensätzen zusammengefasst und in Datenbanken gespeichert, sie sind Gegenstand der Verarbeitung von Computerprogrammen und werden von diesen erzeugt, gelesen, verändert und gelöscht.
  • Obwohl Daten eigentlich immer als Aneinanderreihung mehrerer Datenelemente auftreten, sollen hier nicht alle Erscheinungsformen von Daten einen 'Datensatz' darstellen, sondern nur Datengruppierungen, die zu einem bestimmten Objekt gehören und in Feldern organisiert sind, welche von einem DBMS gemeinsam verwaltet werden, wobei das DBMS dazu ausgebildet ist, die Datenfelder mittels vordefinierter Befehle anzulegen, zu löschen und/oder umzubenennen und ggf. auch in das Zugriffsrechtsmanagement des DBMS einzubinden. Nicht als Datensätze in diesem Sinn gelten demnach zum Beispiel: Fließtexte, Drucker- oder Video-Datenströme, Inhalte von ausführbaren Dateien, Fotodaten oder die Daten von Grafiksoftware u. a. Diese Daten können aber in einem Feld eines Datensatzes gespeichert sein.
  • Unter einem "Feld" wird im Folgenden ein Bereich auf einem logischen oder physikalischem Datenträger bezeichnet, der von einem DBMS verwaltet wird, der einem vordefinierten Feldtyp zugeordnet ist und der zur Speicherung eines Feldwertes eines Datensatzes angelegt und bestimmt ist. Eine "Feld" ist also ein Element zur Speicherung eines Feldwertes eines Datensatzes gemäß obiger Definition. Felder eines Datensatzes werden von einem DBMS gemeinsam verwaltet. Das Feld kann von dem DBMS mittels vordefinierter Befehle angelegt, gelöscht oder umbenannt und ggf. auch in das Zugriffsrechtsmanagement des DBMS einbezogen werden.
  • Ein "Feldtyp" ist eine Kategorie bzw. ein Typ, dem ein bestimmtes Feld angehört. Beispielsweise kann ein Feldtyp ein bestimmtes Attribut eines physischen Objektes repräsentieren. Beispielsweise kann ein DBMS zur Speicherung von Datensätzen, die Attribute von Angestellten enthalten, Feldtypen wie "Name", "Pseudonym", "Ausweisnummer"; "Zugriffszertifikat für Raum R", "Zugriffszertifikat für Gerät G", "Zugriffszertifikat für Gebäude GB", "Alter" verwenden. Jedes Feld ist dabei genau einem Feldtyp zugeordnet. Vorzugsweise darf jeder Datensatz maximal nur ein Feld für jeden im DBMS vordefinierten Feldtyp enthalten.
  • Ein "Feldwert" ist ein Datenwert, der Bestandteil eines Datensatzes ist und der zur Speicherung in einem Feld eines bestimmten Feldtyps bestimmt ist. Beispielsweise kann ein Feldwert des Datensatzes für einen bestimmten Angestellten "Max Mustermann" einen ersten Feldwert "Max Mustermann" für den Feldtyp "Name", einen weiteren Feldwert "13425298833" für den Feldtyp "Ausweisnummer", einen weiteren Feldwert "237971113" für den Feldtyp "Zugriffszertifikat für Raum R" beinhalten. Ein Feldwert kann aus einem einzigen Wort, einer einzigen Zahl, oder einer Kombination aus mehreren Wörtern und/oder Zahlen und/oder anderen Datenformaten bestehen, wobei verschiedene Ausführungsformen der Erfindung verschiedene Grade an Flexibilität im Hinblick auf die Art und Kombinierbarkeit von Datentypen innerhalb des gleichen Feldwertes umfassen.
  • Im Falle einer klassischen SQL-basierten Datenbank würde ein Feldtyp also einer Spalte einer Tabelle entsprechen, z.B. einer Spalte für "Alter" in einer "Angestelltentabelle". Jede Zeile in der Angestelltentabelle würde einem Datensatz entsprechen, welcher Attributwerte eines bestimmten Angestellten beinhaltet. Jede "Zelle" dieser Zeile entspricht einem Feld und dient der Speicherung eines Feldwertes (also eines einfachen oder zusammengesetzten Attributwerts des Angestellten). Ein Feld entspricht also dem Speicherbereich, in welchem ein bestimmter Datenwert/Feldwert eines Datensatzes gespeichert wird.
  • Unter einer "Datenbank" wird im Folgenden eine (typischerweise große) Menge von Daten verstanden, die in einem Computersystem von einem DBMS nach bestimmten Kriterien verwaltet wird. Die Daten sind dabei in einer Vielzahl von Datensätzen organisiert.
  • Ein "NoSQL" (englisch für Not only SQL) DBMS ist ein DBMS, das einem nichtrelationalen Ansatz der Datenspeicherung folgt und keine festgelegten Tabellenschemata benötigt. Zu den NoSQL DBMSs gehören insbesondere dokumentenorientierte DBMSs wie Apache Jackrabbit, BaseX, CouchDB, IBM Notes, MongoDB, Graphdatenbanken wie Neo4j, OrientDB, InfoGrid, HyperGraphDB, Core Data, DEX, AllegroGraph, und 4store, verteilte ACID- DBMSs wie MySQL Cluster, Key-Value-Datenbanken wie Chordless, Google BigTable, GT.M, InterSystems Caché, Membase, Redis, Sortierte Key-Value-Speicher, Multivalue-Datenbanken, Objektdatenbanken wie Db4o, ZODB, spaltenorientierte Datenbanken und temporale Datenbanken wie Cortex DB.
  • Unter einem "Zertifikat" wird hier im Folgenden ein digitales Zertifikat verstanden. Ein Zertifikat ist ein digitaler Datensatz, der bestimmte Eigenschaften von Nutzern oder anderen Objekten bestätigt und dessen Authentizität und Integrität durch kryptografische Verfahren geprüft werden kann. Das digitale Zertifikat enthält die zu seiner Prüfung erforderlichen Daten entweder selbst oder ist mit zertifikatsbezogenen Metadaten verknüpft gespeichert, sodass die zu seiner Prüfung erforderlichen Daten aus den Metadaten bezogen werden können. Die Ausstellung des Zertifikats erfolgt vorzugsweise durch eine offizielle Zertifizierungsstelle, die Certification Authority (CA). Beispielsweise kann das Zertifikat als Zahlenwert ausgebildet sein, welchem Metadaten zugeordnet sind. Die Verwendung von Zahlwerten kann vorteilhaft sein, da diese sich gut indexieren lassen sich und im Falle einer notwendigen Modifikation der Metadaten (z.B. Verlängerung der Validität) unverändert bleiben, also auch ihre Position innerhalb des Index beibehalten können. Vorzugsweise sind die Zertifikate also als Zahlwerte ausgebildet die keinen öffentlichen Schlüssel beinhalten, sondern mit Metadaten oder einem Public-Key-Zertifikat verknüpft gespeichert sind, wobei die Metadaten den Geltungsbereich bzw. Gültigkeitsdauer des Zertifikats näher festlegen. Alternativ dazu kann ein Zertifikat auch nach dem Standard X.509 ausgebildet sein, also einen öffentlichen Schlüssel beinhalten und die Identität des Inhabers und weitere Eigenschaften eines öffentlichen kryptographischen Schlüssels des Zertifikats bestätigen. Ein Zertifikat kann sich, muss sich aber nicht notwendigerweise auf einen kryptographischen Schlüssel beziehen, sondern allgemein Daten zur Prüfung einer elektronischen Signatur enthalten oder mit diesen verknüpft gespeichert sein.
  • Ein "Tokenisierer" ist eine Programlogik, die Daten, zum Beispiel einen Feldwert, als Input erhält, die Daten analysiert, z.B. um Delimiter oder andere Zerlegungskriterien und Muster zu erkennen und die Daten dann in ein oder mehrere Token als Ergebnis der Analyse zerlegt und die Token zurückgibt. Es ist auch möglich das nicht alle Token zurückgegeben werden konnte. Beispielsweise kann ein Volltextindizierer semantisch unbedeutende Stoppwörter erkennen und herausfiltern, sodass diese nicht indiziert werden. Einen Datenwert zu "tokenisieren" bedeutet also, den Datenwert nach einem bestimmten Schema in mehrere Bestandteile zu zerteilen. Die Bestandteile stellen die Token dar. So können z.B. natürlichsprachliche Texte an vordefinierten Trennzeichen, z.B. Leerzeichen, Punkten oder Kommata, aufgeteilt werden, die so generierten Bestandteile (Wörter) werden als Token verwendet. Es ist möglich dass manche Token nicht für die Indizierung verwendet werden (z.B. Stopwörter) oder die Token vor der Indizierung zusätzlich verarbeitet werden (z.B. Reduzierung von Wörtern auf den Wortstamm). In diesem Fall erfolgt vorzugsweise eine gleichartige Verarbeitung des Suchwerts durch das Client-Computersystem oder das Server-Computersystem um sicherzustellen, dass die Suchwerte der Suchanfragen den in dem Index enthaltenen Token entsprechen. Beispielsweise kann es sich bei den Delimitern um vordefinierte Bitmuster handeln.
  • Ein "Index" ist eine Datenstruktur, die die Suche nach bestimmten Datenwerten durch ein Datenbankmanagementsystem beschleunigt. Ein Index besteht aus einer Ansammlung von Zeigern (Verweisen), die eine Ordnungsrelation auf mehrere (in dem Index gespeicherte - "indizierte" - Datenwerte definieren. Beispielsweise werden hierfür B+-Bäume verwendet. Jeder indizierte Datenwert ist mit weiteren Zeigern verknüpft, die auf Datensätze verweisen, in welchen der gefundene indizierte Datenwert enthalten ist und die die Datenbasis für die Erstellung des Index darstellten. Datenbankmanagementsysteme verwenden Indices um als Antwort auf eine Suchanfrage die gewünschten Datensätze schnell zu identifizieren, indem zunächst der Index entlang der Zeiger nach einem Datenwert durchsucht wird welcher identisch zu einem in der Suchanfrage enthaltenen Referenzwert ist. Ohne Index müssten die von dem DBMS verwalteten Datenwerte eines Feldes sequenziell durchsucht werden, während eine Suche mit Hilfe des Index, z.B. eines B+ Baums, oft nur logarithmische Komplexität hat.
  • Ein "Dekodieralgorithmus" ist eine Programmlogik zur Kryptoanalyse, also eines Datenanalyseverfahrens, welches Informationen aus verschlüsselten Daten gewinnt, wobei der Verschlüsselungsalgorithmus und/oder der Verschlüsselungsschlüssel zunächst unbekannt sind und erst durch das Verfahren ermittelt oder die Verschlüsselungsmechanismen anderweitig umgangen ("gebrochen") werden.
  • Ein "Klassifizierer" oder eine "Klassifikationslogik" ist eine Programmlogik zum automatischen Zusammenfassen von Objekten zu Klassen (Gruppen, Mengen), deren Elemente untereinander im Hinblick auf ein oder mehrere Merkmale sich ähnlicher sind als den Objekten anderer Klassen.
  • Die Verwendung von Ordinalzahlen wie erstes, zweites, drittes etc. dient hier allein der Unterscheidung von Elementen und/oder Personen mit ansonsten gleicher Bezeichnung und soll keine bestimmte Reihenfolge implizieren. Ferner kann es sich bei Elemente und/oder Personen, deren Bezeichnung sich allein durch eine Ordinalzahl unterscheidet, soweit sich aus dem konkreten Zusammenhang nicht eindeutig etwas anderes ergibt, um identische oder voneinander verschiedene Elemente bzw. Personen handeln.
    • Kurzbeschreibung der Figuren
  • Ein exemplarisches Verfahren zur Erstellung eines Index sowie ein entsprechendes System sind in den anhängenden Zeichnungen 1 bis 5 veranschaulicht. Darin zeigen:
    • Figur 1
    ein Blockdiagramm einer Ausführungsform eines erfindungsgemäßen Computersystems.
    Figur 2
    die in verschiedenen Feldern zweier Datensätze gespeicherten Feldwerte sowie die aus diesen erzeugte Tokenmenge.
    Figur 3
    ein Flussdiagramm zur Erzeugung eines Gesamtindex aus allen Token.
    Figur 4
    ein verteiltes Computersystem, das ein Server-Computersystem und mehrere Client-Computersysteme umfasst.
    Figur 5
    weitere Details des Server-Computersystems und eines der Client-Computersysteme.
    Figur 6
    ein Flussdiagramm eines Verfahrens zur Datenklassifikation gemäß einer Ausführungsform.
    Ausführliche Beschreibung
  • Figur 1a zeigt ein Blockdiagramm einer Ausführungsform eines erfindungsgemäßen Systems zur Klassifizierung von Daten.
  • Ein Datenbankmanagementsystem, zum Beispiel ein noSQL DBMS 160, wird auf einem Computersystem 156 instanziiert. Das DBMS 160 verwaltet eine oder mehrere Datenbanken. Die hier abgebildete Datenbank 102 umfasst eine Vielzahl von Datensätzen DR1, DR2, ..., DR7, ..., welche jeweils ein oder mehrere Feldwerte beinhalten. Jeder der Feldwerte eines Datensatzes ist in einem entsprechenden Feld, einer Art Datencontainer, gespeichert. Jedes Feld ist dabei einem bestimmten Feldtyp F1, F2, F3, F4, F5, F6, F7 zugewiesen. Beispielsweise ist das erste Feld von Datensatz DR1 dem Feldtyp F1 zugewiesen, das zweite Feld von Datensatz DR1 dem Feldtyp F2 usw. In analoger Weise ist das erste Feld von Datensatz DR6 dem Feldtyp F1 zugewiesen, das zweite Feld von Datensatz DR6 dem Feldtyp F6 usw. Die Zusammensetzung der Feldwerte der einzelnen Datensätze kann sich dabei im Hinblick auf deren Feldtypen unterscheiden, wie anhand der Datensätze in der Datenbank 102 ersichtlich ist. Es ist auch möglich, dass einzelne Datensätze gar keinen Feldwert eines bestimmten Feldtyps beinhalten. In anderen Ausführungsformen (hier nicht gezeigt) können auch mandatorische Feldtypen definiert sein, d.h., dass jeder Datensatz ein Feld für jeden mandatorischen Feldtyp beinhaltet und optional ein oder mehrere weitere Felder für optionale Feldtypen beinhaltet.
  • Zudem ist auf dem Computersystem 156 eine Tokenisierungsapplikation ("Tokenisierer", "Tokenisierungslogik") 158 und eine Klassifizierungsapplikation ("Klassifizierer", "Klassifizierungslogik") 432 instanziiert. Der Tokenisierer zerlegt die Datenwerte mehrerer Felder von mehreren Datensätzen zu einer gemeinsamen Gesamt-Tokenmenge 162, die optional noch weiterverarbeitet werden kann, z.B. in eine nicht-redundante Tokenmenge 153 umgewandelt werden kann.
  • Die Programmlogik zur Generierung des Index umfasst einen oder mehrere Tokenisierer 158, die dazu ausgebildet sind, die Feldwerte von ein oder mehreren Feldern zu tokenisieren. Optional können auch Feldwerte ein oder mehrerer Felder zusätzlich als Ganzes ausgelesen und ohne eine Zerlegung als Token verwendet werden. Der Klassifizierer 432 kann z.B. als "supervised" Klassifizierer ausgebildet sein, bei welchem die Anzahl der zu erwartenden Klassen vorgegeben ist. Beispielsweise kann der Klassifizierer ein regelbasierter Klassifizierer sein, der einen Satz vordefinierter binärer Muster mit den Token abgleicht, oder ein k-means Klassifikationsalgorithmus. Alternativ dazu kann es sich bei dem Klassifizierer auch um einen "nonsupervised" Klassifizierer handeln. Beispielsweise können neuronale Netze und ähnliche Algorithmen verwendet werden.
  • Der Tokenisierer 158 oder eine zusätzliche Programmlogik ("Indexierer") ist dazu ausgebildet, einen Gesamtindex 154 aus den Token 153 zu erzeugen. Zusätzlich oder alternativ dazu ist der Tokenisierer oder der Indexierer dazu ausgebildet, einen Teilindex 426, 428, 430 aus jeder der Token-Teilmengen 420, 422, 422 zu erzeugen. Vorzugsweise hängt die Position der Token innerhalb des Index bzw. innerhalb der Teilindixes nicht von dem Feldtyp ab von dem das Token stammt.
  • Nach alternativen Ausführungsformen wird die Programmlogik zur Tokenisierung und/oder zur Generierung des Index bzw. der Teilindizes und/oder zur Klassifikation der Token in Form eines Plug-ins oder Add-ons des DBMS bereitgestellt. Dies kann vorteilhaft sein, da mithilfe eines zusätzlichen Softwaremoduls zur Tokenisierung und Tokenklassifikation bestehende Typen von DBMSs funktional erweitert werden können, sodass eine Migration der Daten zu einem anderen DBMS zum Zwecke der Tokengenerierung und Klassifikation nicht notwendig ist. Nach einer weiteren, hier nicht dargestellten alternativen Ausführungsform können Tokenisierung, Indexerzeugung und Tokenklassifikation je in Forme eines eigenständigen Applikationsprogramms implementiert sein.
  • Vorzugsweise werden sämtliche oder zumindest die meisten Feldwerte sämtlicher Datensätze einer Datenbank 102 tokenisiert, sodass eine große Menge an Token 153 entsteht. In Abhängigkeit von der Art der Daten in den einzelnen Feldwerten können die Token 153 eine Mischung aus Zahlen, Buchstabenwörtern, Bildern oder Bildsegmenten, Audiodateien oder Audioelementen oder sonstigen Datenstrukturen beinhalten. Jedes der erzeugten Token ist mit einem Zeiger verknüpft gespeichert, wobei der Zeiger auf den Datensatz verweist, ihm das Token entstammt, nicht jedoch auf ein einzelnes Feld bzw. einen Feldtyp verweist, in welchem der Feldwert gespeichert wurde aus welchem der Token abgeleitet wurde.
  • Vorzugsweise handelt es sich bei der Tokenmenge 153 um eine nicht-redundante, "unique" Token-Menge, in welcher jedes der Token nur ein einziges Mal vorkommt. D.h., auch wenn ein Token mit dem Wert "3467475675" mehrfach in der Datenbank 102 und damit auch in einer zunächst gebildeten Tokenmenge vorkommt, wird nur ein einziges Token mit dem Wert "3467475675" in der nicht-redundanten Token-Menge 153 und in dem Index 154 gespeichert. Allerdings erfolgt die Speicherung in dem Index 154 bzw. jedem der Teilindizes so, dass ein indiziertes Token auf sämtliche Datensätze DR1-DR7 verweist, in welchem es in zumindest einem Datenwert zumindest einmal enthalten ist. Vorzugsweise erfolgt die Speicherung aller Token der nicht-redundanten Tokenmenge in dem Index bzw. den Teilindizes so, dass die Token nach einem Sortierkriterium sortiert werden und in sortierter Form in der Indexstruktur gespeichert werden. Die Sortierung kann beispielsweise anhand des Alphabets für alphanumerische Daten oder sonstiger, an die Daten angepasste Sortierkriterien erfolgen. Da die Token in dem Index vorzugsweise in sortierter Form gespeichert sind, und weiterhin vorzugsweise in einer Baumstruktur gespeichert sind, ist es sehr schnell möglich, ein bestimmtes Token innerhalb des Index zu identifizieren und dann die Verweise dieses identifizierten Tokens auf ein oder mehrere Datensätze zu verwenden, um sehr schnell diejenigen Datensätze zu identifizieren, die ein bestimmtes, gesuchtes Token enthalten. Es ist also nicht erforderlich, die Datensätze der Datenbank 102 sequenziell zu durchsuchen.
  • Die Zahl und Zusammensetzung der Feldtypen einzelner Datensätze kann unterschiedlich sein. Die Teilindizes 426, 428, 430 leiten sich jeweils nicht von unterschiedlichen Tabellenspalten bzw. Feldtypen ab, sondern von Token-Teilmengen 420, 422, 424, die jeweils Token beinhalten, die eine ähnliche Bitsequenzlänge haben und/oder die ein oder mehrere ähnliche Bitsequenzmuster aufweisen. "Ähnliche Bitseqzuenzmuster" können z.B. identische Folgen von "0"en und "1"en sein, die in den Bitsequenzen mehrerer Token vorkommt und lediglich um einige Positionen relativ zur ersten Position der Bitsequenz des jeweiligen Token verschoben sind. Die Eingruppierung der Token der Tokenmenge 153 in Teilmengen ähnlicher Token wird von dem Klassifizierer 432 vorgenommen, der zur Klassifizierung der Token ausschließlich auf der Ebene der Bitsequenz arbeitet. Vorzugsweise arbeitet auch der Tokenisierer 158 ausschließlich auf der Bitsequenzebene der Feldwerte, um diese in Token 162 zu zerlegen. Das heißt, der Tokenisierer analysiert die einzelnen Bits der als Bitsequenz gespeicherten Feldwerte um darin Muster bekannter Bitfolgen zu erkennen, die z.B. den Übergang von einem Textabschnitt zu einem Bildabschnitt oder umgekehrt markieren, oder die das Ende eines Bildes und den Beginn eines weiteren Bildes, das als Teil des Feldwerts gespeichert ist, markieren. Somit kann auf höchst effiziente Weise die Tokenmenge 162 erstellt und klassifiziert und ggf. auch entsprechende Teilindices erzeugt werden, ohne Datenobjekte auf einer höheren strukturellen Ebene erzeugen und/oder Laufzeitumgebungen zur Verarbeitung derartiger höher organisierter Objekte instanziieren zu müssen. Die Token-Teilmengen bzw. die Teilindizes können für eine Vielzahl von Anwendungsszenarien verwendet werden.
  • In einem Szenario, das in Fig. 1b gezeigt wird, wird eine als "Indexselektor" 434 bezeichnete Programmlogik bereitgestellt. Dies kann manuell, semi-manuell oder automatisch erfolgen. Der Indexselektor ist dazu ausgebildet, als Antwort auf den Empfang eines bestimmten Datenwertes einen der Teilindizes 426, 428, 430 auszuwählen nach der gleichen Auswahllogik, nach welcher auch der Klassifizierer 432 einzelne Token anhand ihrer Bitsequenzlänge oder anderer Bitsequenzbezogener Merkmale Token einzelnen Token-Teilmengen (aus denen die jeweiligen Teilindizes gebildet wurden) zuwies. Das heißt, ein Datenwert, der aufgrund seiner Bitsequenz von dem Klassifizierer 432 der Teilmenge 422 zugewiesen würde, wird den Indexselektor 434 dazu veranlassen, den Teilindex 428 zu wählen, der aus der Teilmenge 422 hervorging. Ein Datenwert, der aufgrund seiner Bitsequenz von dem Klassifizierer 432 der Teilmenge 424 zugewiesen würde, wird den Indexselektor 434 dazu veranlassen, den Teilindex 430 zu wählen, der aus der Teilmenge 424 hervorging. Und so weiter.
  • Der Indexselektor sorgt dafür, dass als Antwort auf den Empfang einer "Schreibanfrage" an die Datenbank 102 der zu schreibende Datenwert nicht nur in der Datenbank gespeichert wird sondern auch in einem der Teilindizes, welche der Indexselektor anhand von Bitsequenzmerkmalen des zu schreibenden Datenwerts dynamisch identifiziert. Beispielsweise wurde gemäß Fig. 1b ein neuer Datensatz DR8 in der Datenbank gespeichert. Dessen Feldwerte DR8.F1, DR8.F2, DR8.F3 und DR8.F6 werden tokenisiert und mit Hilfe des Index-Selektors jeweils in demjenigen der Teilindizes gespeichert, welcher bereits Token enthält, die diesem neuen Token im Hinblick auf Bitsequenzmerkmale ähnlich sind.
  • In entsprechender Weise sorgt der Indexselektor dafür, dass als Antwort auf den Empfang einer "Leseanfrage" an die Datenbank 102 einer der Teilindizes, welche der Indexselektor anhand von Bitsequenzmerkmalen des zu lesenden Datenwerts dynamisch identifiziert, nach dem Suchwort durchsucht wird, um in effizienter Weise die Datensätze zu identifizieren, die das Suchwort beinhalten und diese Datensätze zurückzugeben. Weder beim Lesen noch beim Schreiben wird also auf einen Gesamtindex 154 zugegriffen, der die Gesamtheit aller Token der Datensätze enthält. Vielmehr kann dadurch, dass auf Teilindizes zurückgegriffen wird, deren Größe und/oder Inhalt vorzugsweise von der Art der Daten abhängt, der Arbeitsspeicherverbrauch reduziert werden.
  • Figur 2 zeigt beispielhaft die in verschiedenen Feldern zweier Datensätze gespeicherten Feldwerte sowie die aus diesen erzeugten intermediären Tokenmengen. So kann beispielsweise der Feldtyp F1 zur Speicherung von Lebensläufen dienen. In Feldern des Feldtyps F1 werden somit häufig natürlich sprachliche Texte mit Bilddaten und optional auch Audiodaten gespeichert. Feldtyp F2 kann zur Speicherung eines Berechtigungsnachweises für ein bestimmtes Gebäude, zum Beispiel in Form eines numerischen Datenwerts, der als Zertifikat dient, ausgebildet sein. Es ist möglich dass auch die Daten für den Feldtyp F2 Bilddaten enthalten, z.B. ein Bild der Person das auf einem Ausweis angebracht ist. Die Feldtypen F3 und F4 können zur Speicherung numerischer Datenwerte, die je als Berechtigungsausweise für ein weiteres Gebäude (F3) oder einen bestimmten Raum (F4) dienen, ausgebildet sein. Der Feldtyp F5 kann der Speicherung biometrischer Daten dienen. Die biometrischen Daten können in Form von Texten, Bildern (zum Beispiel Fingerabdrücke, Irisbilder, etc.), und/oder Videodaten (Bewegungsmuster, etc.) in den Feldern des Feldtyps F5 gespeichert sein. Vorzugsweise haben die Felder der verschiedenen Feldtypen ein generisches Datenformat, das im Prinzip die Speicherung sämtlicher in der Datenbank vorkommender Datenformen (Text, Zahlen, Bilder, Video-, Audio und/oder sonstiger Dateien) zulässt. Es ist möglich, dass beispielsweise eine Applikationslogik, die die Daten erstellt, alle Daten eines bestimmten semantischen Konzepts (z.B. "Alter", "Geburtstag", "Zugangsberechtigung für Gebäude XY") in einem speziell hierfür spezifizierten Feld speichert, auch wenn das Feld auch die Speicherung anderer Datenformate unterstützen würde.
  • Vorzugsweise handelt es sich bei dem Tokenisierer um einen einzigen, generischen Tokenisierer, der auf sämtliche zu tokenisierenden Felder verschiedener Feldtypen angewandt wird. Der Tokenisierer 158 generiert aus dem im ersten Feld des Datensatzes DR1 gespeicherten Feldwert und aus dem im ersten Feld des Datensatzes DR7 gespeicherten Feldwert sowie aus den Feldwerten aller Felder der anderen Datensätze, die dem Feldtyp F1 zugeordnet sind, eine Mengen an ersten Token 250. Der Tokenisierer 158 generiert zudem aus dem im zweiten Feld des Datensatzes DR1 gespeicherten Feldwert und aus dem im zweiten Feld des Datensatzes DR7 gespeicherten Feldwert sowie aus den Feldwerten aller Feldern der anderen Datensätze, die dem Feldtyp F2 zugeordnet sind, eine Mengen an zweiten Token 252. Dies wird für die Feldwerte sämtlicher Feldtypen F1-F7 durchgeführt, wobei vorzugsweise der gleiche generische Tokenisierer für alle Feldtypen verwendet wird. Die Gesamtheit der für alle Feldtypen generierten Token 250, 252, ..., 254 bildet die Tokenmenge 162. Vorzugsweise wir die Tokenmenge 162 als nicht-redundante Tokenmenge 153 gespeichert.
  • Beispielsweise können schon im Zuge der Speicherung von Datenwerten in den Einzelnen Feldern von der die Daten speichernden Programmlogik (z.B. ein Applikationsprogramm oder das DBMS, das die Datenbank verwaltet) vordefinierte Bitmuster so in die Datenwerte eingeführt werden, dass anhand dieser Bitmuster Daten unterschiedlichen Typs (Textdaten, einzelne Wörter, Datumsangaben, Zahlenwerte, Audiodaten) voneinander durch einen Tokenisierer leicht voneinander abgrenzbar sind. Die hierfür verwendete Programmlogik kann je nach Anwendungsgebiet beliebig komplex sein und z.B. einem Bildanalyseschritt nachgeschaltet sein um dann einzelne in einem Bild erkannte Objekte so zu speichern, dass sie von einer eindeutigen, objekttypspezifischen Bitsequenz von anderen Nutzdaten abgrenzbar sind. Nach anderen Ausführungsformen erfolgt jedoch keine explizite Einführung von Bitmuster-Delimitern im Zuge der Speicherung der Datensätze in der Datenbank. Beispielsweise können manche Datentypen, wenn sie vom DBMS als Bestandteil komplexerer, zusammengesetzter Dateneinträge (Text, Bilder, Zahlen und/oder Ton) bereits auf der Bitebene wiederkehrende Bitmuster enthalten, die eine Tokenisierung einiger oder aller in einem Feld gespeicherten Werte in ein, zwei, oder mehrere Token erlauben. Auch machine-learning Ansätze, die testweise verschiedene, zufällig gewählte Delimiter zur Tokenisierung anwenden und dann diejenigen Delimiter beibehalten und als Grundlage bei der Tokenisierung bei der Erstellung der Teilindizes verwenden, die zu einem gewünschten Grad an Tokenisierung der in der Datenbank gespeicherten Datenwerte führen, ist möglich.
  • Figur 3 zeigt ein Flussdiagramm zur Erzeugung eines Gesamtindex 154 aus der Gesamtheit der Tokenmenge 153 gemäß einer Ausführungsform. Zunächst erfolgt eine Bereitstellung 170 eines DBMS 160, zum Beispiel eine Instanziierung des DBMS auf einem Computersystem 156. Das DBMS 156 ist dazu konfiguriert, Datensätze DR1-DR7 jeweils als eine Menge aus mehreren Feldwerten strukturiert zu speichern. Dabei wird jeder der Feldwerte jeweils in einem eigenen Feld gespeichert. Die Felder jedes der Datensätze gehören mindestens zwei unterschiedlichen Feldtypen F1-F7 an. In Schritt 172 erfolgt die Erzeugung von ersten Token 250 aus ersten Feldwerten mehrerer Datensätze. Wie in Figur 2 beispielhaft gezeigt, sind die ersten Feldwerte in ersten Feldern gespeichert. Die ersten Felder gehören einem ersten Feldtyp F1 an. In Schritt 174 erfolgt die Erzeugung von zweiten Token 252 aus zweiten Feldwerten mehrerer Datensätze. Wie in Figur 2 beispielhaft gezeigt, sind die zweiten Feldwerte in zweiten Feldern gespeichert. Die zweiten Felder gehören einem zweiten Feldtyp F2 an. In analoger Weise wird Schritt 172 bzw. 174 wiederholt für die Felder bzw. Feldwerte weiterer Feldtypen F3, ..., F7. Schließlich erzeugt eine Tokenisierungslogik (zum Beispiel ein generische Tokenisierer 158) in Schritt 176 einen durchsuchbaren Index 154 aus zumindest den ersten Token 250 und den zweiten Token 252 und gegebenenfalls den weiteren für andere Datentypen erzeugten Token 254. Der Ort der Speicherung der ersten und zweiten und der gegebenenfalls weiteren Token 254 in der Struktur des Index erfolgt unabhängig davon, von welchem der Felder die Token stammen. Anstatt oder zusätzlich zu dem Gesamtindex 154 kann aus jeder der Token-Teilmengen 420, 422, 424 auch ein Teilindex in analoger Weise erzeugt werden.
  • Figur 4 zeigt übersichtsartig ein verteiltes System, das ein Server-Computersystem 322 und mehrere Client-Computersysteme 156, 157, 159 umfasst. Die Computersysteme 322, 156, 157, 159 sind über ein Netzwerk 155, z.B. das Internet, miteinander verbunden.
  • Das Client-Computersystem 156 kann beispielsweise ein Client-Applikationsprogramm beinhalten, welches eine Suchanfrage 330 über das Netzwerk an das Server-Computersystem 322 sendet. Die Suchanfrage beinhaltet einen Suchwert 328, zum Beispiel ein Nutzer-Pseudonym in Form eines Zahlenwertes "3463744".
  • Das Server-Computersystem 322 kann als ein Cloud-Computersystem ausgebildet sein, welches selbst aus einer Vielzahl miteinander vernetzten und operativ aneinander gekoppelten Ressourcen, insbesondere mehreren Datenspeichergeräten und Prozessoren, besteht. Das Server-Computersystem stellt Datensätze einer Datenbank für eine Vielzahl von berechtigten Client-Computersystemen 156, 157, 159 über das Netzwerk bereit. Die Bereitstellung umfasst das Verfügbarmachen eines oder mehrerer Teilindizes 426', 428', 430' mittels eines Indexselektors 434. Jeder der Teilindizes ist aus Teiltokenmengen von Token gebildet, die sich im Hinblick auf Merkmale ihrer Bitsequenz ähneln und in Teiltokenmengen gruppiert wurden wie dies für Ausführungsformen hier beschrieben ist. Jeder der Teilindizes ermöglicht es den Client-Computersystemen, den Inhalt der Datenbank 326 zu durchsuchen sowie Treffer [[DR3]] zu identifizieren und zurückzugeben, obwohl die Datenbank 326 verschlüsselt ist. Die Verwendung von Teilindizes anstatt eines Gesamtindex 154' reduziert den Ressourcenverbrauch auf Seiten des Servers, insbesondere was den Verbrauch von Arbeitsspeicher angeht.
  • Die Speicherung von großen Datenbanken und die Bereitstellung eines entsprechenden Suchindex für eine Vielzahl von Client-Computersystemen stellen oftmals eine erhebliche Anforderung im Hinblick auf die Systemsicherheit, Ausfallsicherheit und Leistungsfähigkeit der Prozessoren und Speicherkomponenten dar. Eine Auslagerung dieser Dienste auf spezialisierte Cloud-Computersysteme ist daher gerade für viele mittelständische Unternehmen von hohem ökonomischen Interesse. Allerdings befinden sich die Daten, die auf Cloud-Rechnern gespeichert sind, oftmals im Ausland und/oder unter der Kontrolle eines Cloud-Dienstanbieters, dem nicht vollständig vertraut wird. Ausführungsformen der Erfindung ermöglichen also die Auslagerung und Speicherung von sensiblen Daten auf Cloud-Dienste in einer Weise, dass diese über einen Index durchsuchbar sind und an mehrere berechtigte Client-Computersysteme zur Verfügung gestellt werden können, ohne dass die Vertraulichkeit der in dem Cloud-Speicherdienst gespeicherten Daten (Datensätze und Index) gefährdet ist.
  • Figur 5 zeigt weitere Details des Server-Computersystems 322 und eines 156 der Client-Computersysteme, gemäß einer weiteren Ausführungsform der Erfindung.
  • Dem Server-Computersystem ist ein asymmetrisches kryptographisches Schlüsselpaar zugeordnet, welches einen öffentlichen kryptographischen Schlüssel PubKS und einen privaten kryptographischen Schlüssel privKS beinhaltet. Der öffentliche Schlüssel wird in Kopie PubKS' dem Client-Computersystem zur Verfügung gestellt. Dies kann beispielsweise direkt erfolgen, also in dem das Client-Computersystem den Schlüssel direkt von dem Server-Computersystem empfängt. Die Schlüsselübertragung kann aber auch indirekt erfolgen, indem beispielsweise das Server-Computersystem seinen öffentlichen Schlüssel in einer öffentlich einsehbaren Datenbank hinterlegt und das Client-Computersystem den öffentlichen Schlüssel PubKS' von dieser Datenbank herunterlädt. Der private Schlüssel PrivKS dient der Entschlüsselung von Daten, die mit dem öffentlichen Schlüssel PubKS verschlüsselt wurden. Der private Schlüssel PrivKS ist vorzugsweise geschützt gespeichert und nur dem Server-Computersystem, nicht aber einem der Client-Computersysteme zugänglich.
  • Auch das Client-Computersystem verfügt über einen privaten Schlüssel privKC, der geschützt gespeichert ist, sodass der private Schlüssel PrivKC nur von dem Client-Computersystem 156 (und optional von weiteren, berechtigten Client-Computersystemen 157, 159) gelesen und verwendet werden kann, nicht jedoch vom Server-Computersystem.
  • Das Client Computersystem beinhaltet eine Tokenisierungslogik 158, einen Klassifizierer 432 zur Erzeugung der Teil-Tokenmengen, einen Indizierer zur Generierung von Teilindizes aus den Teil-Tokenmengen, und ein DBMS mit einer Datenbank 102 gemäß einer der hier bereits beschriebenen Ausführungsformen.
    • Phase I
  • In einer ersten Phase wird von dem Client-Computersystem eine Tokenisierung der Feldwerte der Datensätze der Datenbank 102 vorgenommen. Die Token der Tokenmenge 162 (oder 153) werden von dem Klassifizierer klassifiziert und in Teil-Tokenmengen aufgeteilt, welche von einem Indexierer zur Erzeugung eines entsprechenden Teilindex verwendet werden wie z.B. in Figuren 1, 2 und 3 beschrieben wurde. Die generierten Teil-Indizes sowie die Datensätze der Datenbank 102 werden verschlüsselt. Bei der Verschlüsselung der Datensätze und der Teilindizes werden unterschiedliche kryptografische Schlüssel verwendet. Im Folgenden wird die Verarbeitung des Teilindex 428 näher beschrieben. Vorzugsweise werden sämtliche anderen Teilindizes in gleicher Weise verarbeitet, also verschlüsselt, an den Server übertragen und dort zur schnellen Identifikation gesuchter Datensätze verwendet wie im Folgenden beschrieben ist.
  • Vorzugsweise werden die Datensätze einzelnen verschlüsselt. Dies hat den Vorteil, dass diese auch einzeln in verschlüsselter Form zurückgegeben werden können. Die einzelnen Datensätze werden so verschlüsselt, dass das Client- Computersystem diese wieder entschlüsselt kann, nicht jedoch das Server- Computersystem 322, das die verschlüsselten Datensätze speichern und für ggf. eine Vielzahl an Clients vorhalten soll. Beispielsweise kann der Schlüssel PrivKV ein privater, symmetrischer kryptographische Schlüssel sein, der sowohl zur Verschlüsselung als auch zur Entschlüsselung von Daten verwendet werden kann. Alternativ dazu kann das Client-Computersystem über ein weiteres asymmetrisches kryptographisches Schlüsselpaar verfügen, wobei beide Schlüssel dieses Paares nur dem Client-Computersystem 156 (und gegebenenfalls noch weiteren berechtigten Client-Computersystemen), nicht jedoch dem Server-Computersystem bekannt sind. Ein Schlüssel dieses Paares dient zur Verschlüsselung der Datensätze, der andere Schlüssel des Paares zur Entschlüsselung der verschlüsselten Datensätze 326. Aus dem Datensatz DR1 etwa wird also der verschlüsselte Datensatz [[DR1]]. Aus dem Datensatz DR3 wird also der verschlüsselte Datensatz [[DR3]].
  • Den Teilindex 428 verschlüsselt das Client-Computersystem 156 dagegen mit dem öffentlichen Schlüssel PubKS des Server-Computers.
  • Die verschlüsselten Datensätze 326 und der verschlüsselte Teilindex 324 werden von dem Client- Computersystem an das Server- Computersystem übertragen. Dies kann beispielsweise direkt über das Netzwerk 155, zum Beispiel das Internet, erfolgen. Nach Ausführungsformen erfolgt die Verschlüsselung und Übertragung der Datensätze in regelmäßigen zeitlichen Abständen komplett oder inkrementell, wobei jeweils der Index neu gebildet, neu verschlüsselt und neu übertragen wird.
  • Der übertragene verschlüsselte Teilindex 324' wird vom Server-Computersystem mittels des privaten Schlüssels PrivKS des Server-Computers entschlüsselt und als eine unverschlüsselte Kopie 154' des Teilindex 428 auf ein oder mehreren Speichermedien 344, die von dem Server-Computersystem verwaltet werden, gespeichert.
  • Auch die empfangenen und verschlüsselten Datensätze 326 werden auf den Speichermedien 344 gespeichert, ohne diese jedoch zu entschlüsseln, da das Server-Computersystem nicht über die Schlüssel verfügt, die notwendig sind, um die Datensätze zu entschlüsseln.
  • Das Server-Computersystem stellt eine Schnittstelle 336 bereit, welche es dem Client-Computersystem 156, das den Index und die Datensätze bereitgestellt hat, ermöglicht, auf den Teilindex 428' zuzugreifen. Vorzugsweise ermöglicht die Schnittstelle auch weiteren Client-Computersystemen einen entsprechenden Zugriff auf den Index 428', wobei die weiteren Client-Computersysteme die gegebenenfalls vom Server-Computersystem bereitgestellten verschlüsselten Datensätze nur dann auswerten können, wenn sie ebenfalls über einen geeigneten Entschlüsselungsschlüssel PrivKC verfügen.
  • Während in der ersten Phase die Generierung Verschlüsselung und Verteilung von Index und Datensätzen beschrieben ist, wird in der zweiten Phase der Ablauf einer beispielhaften Suchanfrage anhand eines Beispiels beschrieben.
    • Phase II
  • Im abgebildeten Beispiel sendet eine Client-Applikation 334, auf dem Client-Computersystem 156 instanziiert ist, eine Suchanfrage 330 über die Schnittstelle 336 an das Server-Computersystem. Die Suchanfrage beinhaltet einen Suchwert 328, zum Beispiel "2654645".
  • Als Antwort auf den Empfang der Suchanfrage analysiert der Index-Selektor 434 den Suchwert auf der Bitsequenzebene. Der Index-Selektor stellt fest, dass von allen übertragenen und entschlüsselten Teilindizes 426', 428', 430', der Teilindex 428' Token enthält, die dem Suchwert im Hinblick auf Bitsequenzlänge und/oder im Hinblick auf das Vorkommen bestimmter Bitmuster am ähnlichsten ist. Daraufhin wählt der Index-Selektor den Teilindex 128' aus. Das Server-Computersystem durchsucht den ausgewählten, unverschlüsselten Index 428' nach einem Token, das exakt dem Suchwert "2654645" entspricht. Beispielsweise kann der Suchlauf nach diesem Suchwert ein bestimmtes Token innerhalb des Index 428' identifizieren, welches den Datensatz DR3 referenziert. Der Datensatz DR3 liegt auf dem Server-Computersystem nur in verschlüsselter Form [[DR3]] vor. Als Antwort auf die Suchanfrage 330 gibt das Server-Computersystem also den identifizierten, verschlüsselten Datensatz [[DR3]] in einer Antwort-Nachricht 332 an das Client-Computersystem zurück. Eine Entschlüsselungslogik 340 des Client-Computersystems, die Zugriff auf den Entschlüsselung-Schlüssel PrivKC besitzt, entschlüsselt den Datensatz und liefert den entschlüsselten Datensatz DR3 an die Client-Applikationslogik 334 als das Ergebnis der Suchanfrage 330.
  • Anhand der Abbildung ist ersichtlich, dass für die Phase zwei ein Vorhandensein der Original-Datenbank 102 bzw. ein Vorhandensein der unverschlüsselten Datensätze DR1-DR7 auf dem Client-Computersystem nicht erforderlich ist. Es ist also möglich, dass nur ein bestimmtes Client-Computersystem 156 der Generierung und Verschlüsselung des Index bzw. der Verschlüsselung der Datensätze dient, während eine Vielzahl weiterer Client-Computersysteme 157, 159 ausschließlich Programlogik implementieren, die zur Durchführung der hier in Phase zwei aufgeführten Schritte erforderlich ist. Diese weiteren Client-Computersysteme benötigen also keinen öffentlichen Schlüssel des Servers PubKS und keine Tokenisierungslogik zur Erstellung des Index, benötigen aber eine Client-Applikation 334, eine Entschlüsselungslogik 340 und den entsprechenden Entschlüsselungsschlüssel PrivKC zur Entschlüsselung der Datensätze.
  • Figur 6 zeigt ein Flussdiagramm eines Verfahrens zur Klassifikation von Daten gemäß einer Ausführungsform der Erfindung. In einem ersten Schritt 402 generiert eine Tokenisierungslogik 158 eine Tokenmenge 153 bereit. Beispielsweise kann zunächst eine redundante Menge 162 von Token durch Tokenisierung mehrerer Feldwerte mehrerer Datensätze DR1-DR8 erzeugt wurden, wobei die Token aus Feldwerten von mindestens zwei unterschiedlichen Feldtypen F1-F8 erzeugt wurden, wobei die Token in Form einer Bitsequenz gespeichert sind. Diese kann sodann in eine nicht-redundante Tokenmenge 153 überführt werden, indem Duplikationen entfernt werden. Im nächsten Schritt 404 führt eine Klassifikationslogik eine Analyse der Token der Tokenmenge auf der Bitsequenzebene durch, z.B. indem Bitsequenzlängen bestimmt und verglichen werden und/oder indem Bitmuster in verschiedenen Token gesucht, erkannt und mit den erkannten Bitmustern und deren Position innerhalb anderer Token verglichen werden. Als Ergebnis dieser Analyse werden Teilmengen 420, 422, 424 merkmalsähnlicher Token identifiziert. Die Klassifikationslogik 432 speichert in Schritt 406 eine Kopie jeder der Teilmengen merkmalsähnlicher Token in nach Teilmengen getrennter Form. Beispielsweise können die Token-Teilmengen in unterschiedlichen Dateien oder unterschiedlichen Verzeichnissen gespeichert werden. Jede der Teilmengen wird in Form eines Teilindex 426, 428, 430 gespeichert. Jeder Teilindex enthält also die Token der Teilmenge, von welcher er abgeleitet ist, wobei die Position der Token innerhalb eines Teilindex unabhängig ist von dem Type des Feldes, von welchem sich das Token ableitet. Jede Teilmengenkopie repräsentiert jeweils eine Klasse merkmalsähnlicher Daten. Beispielsweise können die Klassen merkmalsähnlicher Daten in einer Kryptoanalyse jeweils als Kandidaten für ein bestimmtes Wort oder anderes semantisches Konzept interpretiert und weiterverarbeitet werden.
    • Bezugszeichenliste
    • DR1-DR7
    Datensätze
    F1-F7
    Typen von Datenfeldern
    102
    Datenbank
    153
    Tokenmenge
    154
    Index
    154'
    Kopie von Index 154
    155
    Netzwerk
    156
    (Client-) Computersystem
    157
    Client-Computersystem
    158
    Tokenisierungslogik
    159
    Client-Computersystem
    160
    DBMS
    162
    Tokenmenge
    170-176
    Schritte
    250
    Menge an ersten Token
    252
    Menge an zweiten Token
    254
    Menge an fünften Token
    322
    Server-Computersystem
    324
    verschlüsselter Index
    324'
    Kopie des verschlüsselten Index
    326
    verschlüsselte Datenbank
    328
    Suchwert
    330
    Suchanfrage
    332
    Antwort auf Suchanfrage
    334
    Client-Applikation
    336
    Schnittstelle
    338
    Entschlüsselungslogik des Server-Computersystems
    340
    Entschlüsselungslogik des Client-Computersystems
    342
    Speichermedien
    344
    Speichermedien
    346
    Prozessor(en)
    348
    Prozessor(en)
    PubKS
    öffentlicher Schlüssel des Server-Computersystems
    PrivKS
    privater Schlüssel des Server-Computersystems
    PrivCS
    privater Schlüssel des Client-Systems
    402-412
    Schritte
    420
    Teilmenge der Tokenmenge
    422
    Teilmenge der Tokenmenge
    424
    Teilmenge der Tokenmenge
    426
    Teilindex
    428
    Teilindex
    430
    Teilindex
    432
    Klassifikationslogik
    434
    Indexselektor
    438
    Arbeitsspeicher

Claims (16)

  1. Computerimplementiertes Verfahren zur Datenklassifikation, umfassend:
    - Bereitstellen (402) einer Tokenmenge (153), die Token beinhaltet, die aus mehreren Feldwerten mehrerer Datensätze (DR1-DR8) durch Tokenisierung erzeugt wurden, wobei die Token aus Feldwerten von mindestens zwei unterschiedlichen Feldtypen (F1-F7) erzeugt wurden, wobei die Token in Form einer Bitsequenz gespeichert sind;
    - Analyse (404) von einem oder mehreren Merkmalen der Token auf der Ebene der Bitsequenz, um Teilmengen (420, 422, 424) merkmalsähnlicher Token zu identifizieren, wobei die Merkmale die Bitsequenz der Token und/oder die Länge der Bitsequenz umfassen;
    - Speichern (406) einer Kopie jeder der Teilmengen merkmalsähnlicher Token in nach Teilmengen getrennter Form (426, 428, 430), wobei jede Teilmengenkopie jeweils eine Klasse merkmalsähnlicher Daten repräsentiert; und
    - Erzeugung (408) eines Teilindex (426, 428, 430) aus jeder der Teilmengen (420, 422, 424) merkmalsähnlicher Token, wobei der Ort der Speicherung der Token in der Struktur jedes der Teilindizes unabhängig davon erfolgt, von welchem der Feldtypen die Token stammen;
    - Bereitstellung eines Indexauswahlprogramms (434) welches dazu konfiguriert ist, automatisch denjenigen der Teilindices dynamisch zur Beantwortung einer Datenbankabfrage zu identifizieren, dessen Token einem Datenwert bezüglich Bitsequenz und/oder Bitsequenzlänge am ähnlichsten ist.
  2. Das computerimplementierte Verfahren nach Anspruch 1, wobei die Token-menge als durchsuchbarer Index (154) gespeichert ist oder zur Erstellung eines durchsuchbaren Index verwendet wird, ferner umfassend:
    - Empfang einer Suchanfrage (330), wobei die Suchanfrage einen Suchwert (328) beinhaltet;
    - Analyse des Suchwerts durch das Indexauswahlprogramm (434) und Identifikation desjenigen der Teilindices (426, 428, 430), dessen Token dem Suchwert bezüglich Bitsequenz und/oder Bitsequenzlänge am ähnlichsten ist;
    - Durchsuchen des identifizierten Teilindex anstatt des Index (154) nach dem Suchwert.
  3. Das computerimplementierte Verfahren nach Anspruch 2, ferner umfassend:
    - Identifizierung eines indizierten Tokens innerhalb des identifizierten Teilindex, welcher identisch ist zu dem Suchwert;
    - Analyse von Datensatz-Zeigern, die in dem Teilindex mit dem identifizierten Token verknüpft gespeichert sind, um ein oder mehrere der Datensätze zu identifizieren, welche ein oder mehrere Feldwerte beinhalten, aus welchen das indizierte Token erzeugt wurde, wobei die Datensätze in einer Datenbank (102) gespeichert sind,
    - Zurückgabe der ein oder mehreren identifizierten Datensätze oder einer Referenz auf die ein oder mehreren identifizierten Datensätze als Antwort auf die Suchanfrage.
  4. Das computerimplementierte Verfahren nach einem der vorigen Ansprüche, ferner umfassend:
    - Empfang einer Schreibanfrage, wobei die Schreibanfrage einen Datenwert (DR8.F6) beinhaltet;
    - Als Antwort auf den Empfang der Schreibanfrage, automatische Zerlegung des empfangenen Datenwerts durch die Tokenisierungslogik (158), die zur Tokenisierung der Datensätze verwendet wurde, in mehrere neue Token (162'), wobei jedes neue Token als Bitsequenz in einem flüchtigen oder nicht-flüchtigen Speichermedium gespeichert ist;
    - Analyse jedes der neuen Token durch ein Indexauswahlprogramm (434) und Identifikation desjenigen der Teilindices (426, 428, 430), dessen Token dem neuen Token bezüglich Bitsequenz und/oder Bitsequenzlänge am ähnlichsten ist;
    - Speichern des neuen Token in dem identifizierten Teilindex zusätzlich zu oder anstelle von Speicherung des neuen Token in einem Gesamtindex (154) der Token
  5. Das computerimplementierte Verfahren nach einem der vorigen Ansprüche, wobei das Verfahren zur automatischen Bildklassifizierung verwendet wird,
    - wobei es sich bei den Token um Bitsequenzen handelt, die jeweils ein Bild kodieren, wobei die Bitsequenzlänge die Bildgröße repräsentiert,
    - wobei die Teilmengen der Token zumindest eine Kleinbild-Teilmenge und eine Großbild-Teilmenge beinhaltet,
    - wobei in der Kleinbild-Teilmenge selektiv Token enthalten sind, deren Bitsequenzlänge unterhalb eines ersten Schwellenwerts liegt, und
    - wobei in der Großbild-Teilmenge selektiv Token enthalten sind, deren Bitsequenzlänge einen zweiten Schwellenwert überschreitet.
  6. Das computerimplementierte Verfahren nach einem der vorigen Ansprüche,
    - wobei die Anzahl der Teilmengen nicht vorgegeben, sondern dynamisch als Teil des Ergebnisses der Analyse der Merkmale der Token ermittelt, und
    - wobei die Analyse zur Identifikation der Teilmengen (420, 422, 424) merkmalsähnlicher Token von einem nichtüberwachten Machinelearning Algorithmus durchgeführt wird.
  7. Das computerimplementierte Verfahren nach einem der vorigen Ansprüche, wobei die Datensätze in verschlüsselter Form in einer Datenbank gespeichert sind,
    - wobei das Bereitstellen (402) der Tokenmenge (153) umfasst eine Anwendung einer Tokenisierungslogik auf die verschlüsselten Feldwerte der Datensätze auf der Bitsequenzebene, um die Token zu generieren;
    - wobei die Analyse (404) der Merkmale der Token auf der Ebene der Bitsequenz der Token erfolgt; und
    - wobei die Teilmengen (420, 422, 424) merkmalsähnlicher Token jeweils Token umfassen, die sich im Hinblick auf ihre Bitsequenz und/oder die Länge ihrer Bitsequenz ähneln.
  8. Das computerimplementierte Verfahren nach einem der vorigen Ansprüche, ferner umfassend:
    - Verwendung der Teilmengen merkmalsähnlicher Token jeweils als Input eines Dekodieralgorithmus, wobei die Teilmengen jeweils einen Kandidaten für ein natürlichsprachliches Wort oder einen anderen von einem Menschen interpretierbaren Code repräsentieren und wobei der Dekodieralgorithmus dazu ausgebildet ist, durch Analyse der Token einer Teilmenge das natürlichsprachliche Wort oder den anderen von einem Menschen interpretierbaren Code zu identifizieren.
  9. Das computerimplementierte Verfahren nach einem der vorigen Ansprüche, wobei die Erzeugung der Tokenmenge (153) umfasst:
    - Erzeugen (172) von ersten Token (250) aus ersten Feldwerten mehrerer Datensätze, wobei die ersten Feldwerte in ersten der Felder gespeichert sind, wobei die ersten Felder einem ersten Feldtyp (F1) angehören;
    - Erzeugen (174) von zweiten Token (252, 254) aus zweiten Feldwerten der mehreren Datensätze, wobei die zweiten Feldwerte in zweiten der Felder gespeichert sind, wobei die zweiten Felder einem zweiten Feldtyp (F2, F5) angehören,
    wobei auf die ersten und zweiten Felder vorzugsweise die gleiche, generische Tokenisierungslogik (158) angewandt wird.
  10. Das computerimplementierte Verfahren nach einem der vorigen Ansprüche, wobei die Datensätze in einer Datenbank gespeichert sind, die von einem DBMS (160) verwaltet wird, wobei die Datensätze unterschiedlich viele Felder umfassen.
  11. Das computerimplementierte Verfahren nach einem der vorigen Ansprüche, wobei mehrere der Felder eines jeden Datensatzes ein gemeinsames, generisches Datenformat besitzen, wobei das generische Datenformat die Speicherung von Feldwerten erlaubt, die sowohl Textdaten als auch zumindest Bilddaten, Audiodaten und/oder Videodaten beinhalten.
  12. Das computerimplementierte Verfahren nach einem der vorigen Ansprüche, wobei die Tokenisierungslogik dazu ausgebildet ist, die Bitsequenz eines Datenfeldwertes auf der Bitebene zu analysieren und in Abhängigkeit von darin erkannten Bitsequenzmustern zu tokenisieren.
  13. Das computerimplementierte Verfahren nach einem der vorigen Ansprüche, wobei die Tokenisierungslogik ein generischer Tokenisierer ist, der zur Tokenisierung von Feldwerten von Feldern von unterschiedlichen Feldtypen ausgebildet ist, wobei die Anwendung der generischen Tokenisierungslogik auf einen Feldwert umfasst:
    - Erkennen von Daten unterschiedlichen Datentyps innerhalb des Feldwertes, wobei die Daten unterschiedlichen Datentyps Textdaten sowie Bilddaten und einen oder mehrere weitere Datentypen umfassen, wobei die ein oder mehreren weiteren Datentypen Audiodaten und/oder Videodaten umfassen.
  14. Das computerimplementierte Verfahren nach einem der vorigen Ansprüche, wobei die Tokenmenge (153) als durchsuchbarer Index ausgebildet ist oder zur Erzeugung des durchsuchbaren Index (154) verwendet wird, wobei der Ort der Speicherung der Token in der Struktur des Index unabhängig davon erfolgt von welchem der Feldtypen die Token stammen.
  15. Das computerimplementierte Verfahren nach Anspruch 14, wobei die in dem Index (154) gespeicherten Token frei sind von Referenzen auf Felder oder Feldtypen, die zur Speicherung von Feldwerten verwendet wurden, die zur Erzeugung der Token dienten.
  16. Computersystem zur Datenklassifikation, umfassend:
    - ein oder mehrere Prozessoren (346);
    - ein Datenspeichermedium (342),
    - ein DBMS (160), das dazu konfiguriert ist, Datensätze (DR1-DR8) jeweils als eine Menge aus mehreren Feldwerten in den ein oder mehreren Datenspeichermedien zu speichern, wobei die Feldwerte jeweils in einem Feld gespeichert werden, wobei die Felder jedes der Datensätze mindestens zwei unterschiedlichen Feldtypen (F1-F8) angehören,
    - Programmlogik (158), die zur Erstellung einer Tokenmenge (153) konfiguriert ist, wobei die Tokenmenge Token beinhaltet, die aus mehreren Feldwerten mehrerer der Datensätze (DR1-DR8) durch Tokenisierung erzeugt wurden, wobei die Token aus Feldwerten von mindestens zwei unterschiedlichen Feldtypen erzeugt wurden, wobei die Token in Form einer Bitsequenz gespeichert sind;
    - eine Klassifikationslogik (324) die zur Analyse (404) von einem oder mehreren Merkmalen der Token auf der Ebene der Bitsequenz ausgebildet ist, um Teilmengen (420, 422, 424) merkmalsähnlicher Token zu identifizieren, wobei die Merkmale die Bitsequenz der Token und/oder die Länge der Bitsequenz umfassen, und welche dazu ausgebildet ist, eine Kopie jeder der Teilmengen merkmalsähnlicher Token in nach Teilmengen getrennter Form (426, 428, 430) in dem Datenspeichermedium zu speichern, wobei jede Teilmengenkopie jeweils eine Klasse merkmalsähnlicher Daten repräsentiert;
    - wobei ein Plugin des DBMS, die Programmlogik zur Erstellung der Tokenmenge oder die Klassifikationslogik dazu ausgebildet sind, einen Teilindex (426, 428, 430) aus jeder der Teilmengen (420, 422, 424) merkmalsähnlicher Token zu erzeugen, wobei der Ort der Speicherung der Token in der Struktur jedes der Teilindizes unabhängig davon erfolgt, von welchem der Feldtypen die Token stamen;
    - ein Indexauswahlprogramm (434), welches dazu konfiguriert ist, automatisch denjenigen der Teilindices dynamisch zur Beantwortung einer Datenbankabfrage zu identifizieren, dessen Token einem Datenwert bezüglich Bitsequenz und/oder Bitsequenzlänge am ähnlichsten ist.
EP17826526.0A 2016-12-30 2017-12-27 Bitsequenzbasiertes datenklassifikationssystem Active EP3563261B1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP21153224.7A EP3889806A1 (de) 2016-12-30 2017-12-27 Bitsequenzbasiertes datenklassifikationssystem

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102016226338.2A DE102016226338A1 (de) 2016-12-30 2016-12-30 Bitsequenzbasiertes Datenklassifikationssystem
PCT/EP2017/084654 WO2018122269A1 (de) 2016-12-30 2017-12-27 Bitsequenzbasiertes datenklassifikationssystem

Related Child Applications (2)

Application Number Title Priority Date Filing Date
EP21153224.7A Division-Into EP3889806A1 (de) 2016-12-30 2017-12-27 Bitsequenzbasiertes datenklassifikationssystem
EP21153224.7A Division EP3889806A1 (de) 2016-12-30 2017-12-27 Bitsequenzbasiertes datenklassifikationssystem

Publications (2)

Publication Number Publication Date
EP3563261A1 EP3563261A1 (de) 2019-11-06
EP3563261B1 true EP3563261B1 (de) 2022-07-20

Family

ID=60953853

Family Applications (2)

Application Number Title Priority Date Filing Date
EP17826526.0A Active EP3563261B1 (de) 2016-12-30 2017-12-27 Bitsequenzbasiertes datenklassifikationssystem
EP21153224.7A Pending EP3889806A1 (de) 2016-12-30 2017-12-27 Bitsequenzbasiertes datenklassifikationssystem

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP21153224.7A Pending EP3889806A1 (de) 2016-12-30 2017-12-27 Bitsequenzbasiertes datenklassifikationssystem

Country Status (3)

Country Link
EP (2) EP3563261B1 (de)
DE (1) DE102016226338A1 (de)
WO (1) WO2018122269A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102019108856A1 (de) * 2019-04-04 2020-10-08 Bundesdruckerei Gmbh Datenbankübergreifender Index auf einem verteilten Datenbanksystem
DE102019108858A1 (de) * 2019-04-04 2020-10-08 Bundesdruckerei Gmbh Maschinelles Lernen auf Basis von Trigger-Definitionen
DE102019108857A1 (de) * 2019-04-04 2020-10-08 Bundesdruckerei Gmbh Automatisiertes maschinelles Lernen auf Basis gespeicherten Daten
US11645279B2 (en) 2020-08-20 2023-05-09 International Business Machines Corporation Index selection for database query

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140314313A1 (en) * 2013-04-17 2014-10-23 Yahoo! Inc. Visual clothing retrieval

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8438173B2 (en) * 2009-01-09 2013-05-07 Microsoft Corporation Indexing and querying data stores using concatenated terms

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140314313A1 (en) * 2013-04-17 2014-10-23 Yahoo! Inc. Visual clothing retrieval

Also Published As

Publication number Publication date
DE102016226338A1 (de) 2018-07-05
EP3563261A1 (de) 2019-11-06
WO2018122269A1 (de) 2018-07-05
EP3889806A1 (de) 2021-10-06

Similar Documents

Publication Publication Date Title
EP3563261B1 (de) Bitsequenzbasiertes datenklassifikationssystem
DE112020002600T5 (de) Entdecken einer semantischen bedeutung von datenfeldern anhand von profildaten der datenfelder
EP2843585B1 (de) Verfahren und System zum Bereitstellen von anonymisierten Daten aus einer Datenbank
DE10255128A1 (de) Computer-implementierte PDF-Dokumentenverwaltung
DE202015009875U1 (de) Transparente Entdeckung eines semistrukturierten Datenschemas
DE102010043265A1 (de) Systeme und Verfahren zum Verarbeiten und Verwalten von objektbezogenen Daten zur Verwendung durch mehrere Anwendungen
DE202010018481U1 (de) Asynchroner verteilter Objekt-Upload für replizierte Assoziativspeichercluster
DE102007037646B4 (de) Computerspeichersystem und Verfahren zum Indizieren, Durchsuchen und zur Datenwiedergewinnung von Datenbanken
DE112018002047T5 (de) Dokumentenanalyse mit mehreren faktoren
DE102013222384A1 (de) Sicherheits-Screening auf Kontextgrundlage für Zugriff auf Daten
WO2009149926A2 (de) System und verfahren zur rechnerbasierten analyse grosser datenmengen
DE202022002899U1 (de) Metadaten-Klassifizierung
EP3552141B1 (de) Server-computersystem zur bereitstellung von datensätzen
DE102018200100A1 (de) Persönliche Dokumentenblockchain-Struktur
WO2020201247A1 (de) Automatisiertes maschinelles lernen auf basis gespeicherten daten
DE102021128519A1 (de) Dokumentzugangskontrolle auf grundlage von dokumentkomponenten-layouts
EP3552140B1 (de) Datenbankindex aus mehreren feldern
CH712988A1 (de) Verfahren zum Durchsuchen von Daten zur Verhinderung von Datenverlust.
DE112020002892T5 (de) Aktives lernen für den datenabgleich
DE112019005879T5 (de) Indizes für nicht materialisierte ansichten
WO2022101156A1 (de) Listenbasierte datenspeicherung zur datensuche
WO2021190715A1 (de) Computerimplementiertes verfahren und verteiltes speichersystem zum bereitstellen vertrauenswürdiger datenobjekte
EP3948576A1 (de) Datenbankübergreifender index auf einem verteilten datenbanksystem
DE112020002967T5 (de) Digest-nachweise in einer journalisierten datenbank
EP4080376A1 (de) Listenbasierte datensuche mit append-only-datenstruktur

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20190730

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20200818

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 16/51 20190101ALN20210909BHEP

Ipc: G06F 16/906 20190101ALI20210909BHEP

Ipc: G06F 16/901 20190101AFI20210909BHEP

INTG Intention to grant announced

Effective date: 20211008

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 16/51 20190101ALN20210929BHEP

Ipc: G06F 16/906 20190101ALI20210929BHEP

Ipc: G06F 16/901 20190101AFI20210929BHEP

GRAJ Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted

Free format text: ORIGINAL CODE: EPIDOSDIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 502017013511

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: G06F0017300000

Ipc: G06F0016901000

INTC Intention to grant announced (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 16/51 20190101ALN20220123BHEP

Ipc: G06F 16/906 20190101ALI20220123BHEP

Ipc: G06F 16/901 20190101AFI20220123BHEP

INTG Intention to grant announced

Effective date: 20220215

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502017013511

Country of ref document: DE

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1505990

Country of ref document: AT

Kind code of ref document: T

Effective date: 20220815

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20220720

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221121

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221020

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221120

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221021

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 502017013511

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

26N No opposition filed

Effective date: 20230421

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230526

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20221231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20221227

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20221231

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20221227

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20221231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20221231

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20231220

Year of fee payment: 7

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20231220

Year of fee payment: 7

Ref country code: DE

Payment date: 20231214

Year of fee payment: 7

REG Reference to a national code

Ref country code: AT

Ref legal event code: MM01

Ref document number: 1505990

Country of ref document: AT

Kind code of ref document: T

Effective date: 20221227

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20171227