Patent Application
20070288496
The invention will be described in conjunction with the following drawings in which like reference numerals designate like elements and wherein:
Referring now to
The KEngine
The K Engine 11 receives a particle from somewhere outside the K engine 11 and creates or accesses the K structure 14. The K structure 14 contains elemental nodes that represent recognized particles of data.
Also represented within the K structure are the relationships that exist between the nodes. Each node in the K structure that is constructed may be assigned an address in memory. Additionally, each node may contain two pointers, a Case pointer and a Result pointer. The case pointer and the Result pointer of a node point to the two nodes from which it is formed. Also contained in a K node may be pointers to two pointer arrays, the asCase and the asResult array. The asCase array may contain pointers to the nodes whose Case pointers point to the K node. The asResult array, which contains pointers to the nodes whose Result pointers point to the K node. How the individual K nodes within a structure are constructed and accessed is the subject of numerous references by Mazzagatti, including U.S. Pat. No. 6,961,733.
Data Particles
As mentioned above, data passed from the learn engine 6, the utilities 4 or the API utilities 5 to the K Engine 11 are particlized. For example, each word in a sentence may be treated as an individual particle of data, or each letter in a word may be treated as an individual particle of data. For example, in a textual data stream containing the words CATS ARE FURRY, the individual word CATS may be a particle, which may be sensed by a word particle sensor. Additionally, the word ARE and the word FURRY are particles which may be sensed by word particle sensors.
Each character or letter in a word, such as CAT, may be considered to be a particle which may be sensed by a sensor, in this case a character particle sensor (i.e., C is a particle of CAT as is A and T). Each of these may be a particle of data in a field/record textual universe of data. By textual it is meant that data are made up of alphanumeric characters (e.g. the letters A through Z), special characters (e.g. punctuation) and numeric data (e.g. numbers). The term field/record is a carry over from traditional database terminology, wherein a field represents the title of a column in a table and a record represents the rows within the table and contains the actual data.
However, textual data is not the only type of data that may be streamed by the learn engine 6, utility 4 or API utility 5 into the K Engine 11. Those skilled in the art will understand that any kind of data that may be digitized may be particlized and streamed into K. For example, if the data universe is image data, the particles that may be digitized may be pixels. If the data universe is auditory data, the particles may be digitized sound waves. If the data universe is pressure data, particles may be digitized pressure values. If the data universe is olfactory data, particles may be digitized chemical molecules representing odors.
In many of the explanations that follow, the examples use data from the field/record universe. This means that in the examples, it is assumed that the data which is learned or accessed within K may come from traditional tabular databases or other traditional data structures in the form of text, numbers and special characters arranged in fields within records. But, it should be remembered that any type of data from any source that may be digitized may be learned and accessed within a K and therefore could have been used in the examples that follow. Also, the K structure may contain more than two levels of structure. As well, in the following, a KStore node diagram, as shown in
Generating an Interlocking Trees Datastore (K) from Particlized Data
As taught in U.S. Pat. No. 6,961,733 and illustrated in
Praxis Procedure
A procedure that may recognize particles of sensor data, delimiters or unidentified particles according to the system and method of the invention may be the praxis procedure.
Sensor Data, Delimiters, and Unidentified Particles
Before teaching in detail how sensor data, delimiters and unidentified particles are processed, it is necessary to explain what each of the three types of particles includes.
Sensor Data
A sensor may be any digitized data. A sensor is maintained within the K structure as an elemental root node. The elemental root nodes representing sensors may contain or point to values that match the digitized value of the sensor. In a field/record data universe, sensor data may include, but is not limited to, alphanumeric characters. The alphanumeric characters may include the letters in the alphabet, numbers and special characters such as punctuation and other special characters. Depending on how a system is configured a particle of sensor data may include only single letters, numbers, or characters, or they may be whole words, phrases, sentences, paragraphs, chapters, or even entire books, etc. Furthermore, particles may include pixel values forming images of single letters or images of any other type. Thus, as mentioned above, data particles are not limited to textual data and may consist of any other forms of digitized data (e.g. pixels forming other images, sound waves, etc.).
Delimiters
Delimiters are particles that are used to identify an ending of a set of sensors. Furthermore, delimiters may be used to group sensor sets into hierarchies. For instance in a field/record universe, sets of letters may be grouped into words by delimiters. The words may then be grouped into field names or field values by delimiters. The field names or field values may be further grouped into fields and then into records.
Delimiters may be equivalent to individual sensors or sets of sensors. Or they may contain different values altogether. In the current embodiment, delimiters may include alphanumeric characters such as the letters of the alphabet, special characters such as, but not limited to, commas (,), semicolons (;), periods (.), and blanks ( ). Numbers in any base systems may also be used as delimiters. For example, in the current embodiment hexadecimal (base 16) numbers may be used as delimiters. However, as mentioned above, because particles are not limited to characters in the textual field/record universe, delimiters may also be any different type of digitized particle. For example, in a universe of digitized pixels, a single pixel or group of pixels may be used as a delimiter.
Unidentified Particles
Unidentified particles are any particles other than the ones that a current set of particle sensors and delimiter sensors recognizes. Unidentified particles, often called noise, may be, for example, particles of data from a different data character set (e.g. an Arabic or Chinese character). They may be particles from a different data universe, or they may just be an unprintable character that is not in the current set of sensors or delimiters.
Determining Particle Types
Refer back to
Comparing Particles to Delimiter List
In the praxis procedure 300 a particle of incoming data may be compared to a currently defined list of delimiters as shown in block 304. If the input particle matches an entry in the currently defined list of delimiters a process delimiter procedure is performed as shown in block 301. A process delimiter procedure that may be performed when a particle is determined to be a delimiter according to block 301 is taught below as the process delimiter procedure 500 in
Comparing Particles to Sensor List
If the input particle does not match any of the current delimiters as determined according to the comparison of block 304 the praxis procedure 300 may continue to block 305. At block 305 the praxis procedure 300 may compare the incoming particle to a currently defined list of sensors.
The example in the following discussion uses the letter C as an exemplary particle of data from a textual field/record universe. Assume that in the example the letter C does not match any delimiter in the current set of delimiters and execution of the praxis procedure 300 proceeds to block 305. The praxis procedure 300 may then attempt to match the particle C with a list of current sensors in block 305. As taught in the above mentioned patents, in the current embodiment sensors may be maintained in the K structure as elemental root nodes. Lists of these elemental root nodes may be stored in arrays, hash tables, within the K 14 or a separate K structure or in any other manner understood in those skilled in the art.
For example, refer back to the exemplary structure shown in
It should be mentioned here that if the particle does not match anything in the sensor list, the ignore sensor process may be performed as shown in block 302 of
Processing Sensor Data
Refer to
As shown in block 401 of the process sensor data procedure 400, the current K node on the current level of the K structure is determined, wherein terms such as “current K node,” “current K location” and “current K pointer” is understood to refer to the location of the last experience on a selected level. When block 401 is executed the incoming particle has just been matched with the root node corresponding to the incoming particle according to block 305 of the praxis procedure 300. Therefore, the current level is known to be the level above the elemental root nodes. Accordingly, the current K node of the level above the root nodes is determined in block 401.
In a preferred embodiment of the invention, a list or any other kind of structure, may be maintained to store state variables indicating the current K location corresponding to each level. For example, in the case of a multilevel K structure an array setting forth the correspondence between each level of the K structure and a variable indicating the current node of the level may be provided. The current K locations, or the current K node state data, of the levels of the K are known and stored according to the last event experienced on each level. The array or other data structure storing the current K node state data may be referred to as a state array or state table.
In one preferred embodiment each K location pointer may be used to identify both the current K level and the position on the current K level where the last event was experienced. Additionally, the foregoing structure for storing the correspondence between each level of the K structure and its current K node location pointer may store a list of the current set of delimiters, wherein the delimiters are described above with respect to block 304 of the praxis procedure 300 and in further detail below. However, the delimiter level data may be stored in any manner known to those skilled in the art. The structure may also contain a set of sensors appropriate for that particular level. The array of other data structure storing the current K state may be referred to as the state array or state table.
Furthermore, a correspondence between the defined delimiters and the levels of the K structure may be stored. Storage of this information permits the system to determine a relationship between an input delimiter and a level of the K structure that is being ended by the delimiter. It will be understood that the current K node state data and the delimiter level information do not need to be stored in the same data structure. It will also be understood that multiple delimiters may be appropriate for a single level.
As shown in block 402, the process sensor data procedure 400 may then determine the adjacent nodes of the current K node that was determined in block 401. As well known to those skilled in the art, the adjacent nodes of the current K node are determined by accessing an asCase list pointed to by an asCase pointer of the current K node. The asCase list contains pointers to each of the asCase nodes to be located in block 402. It will be understood by those skilled in the art that the asCase nodes located in this manner contain pointers to their Result nodes.
As shown in block 403, the Result nodes of the asCase nodes found in block 402 are determined according to their Result pointers. As shown in block 404, the Result nodes located in block 403 are then compared with the root node representing the received particle. If a match is found in decision 405 between a Result node of an asCase node found in block 402 and an elemental root node representing an input particle, the matched asCase node becomes the current K node. Therefore, the first level K pointer is advanced to point to the matched asCase node as shown in block 407.
For example, assume that the current K node determined in block 401 is the beginning of thought (BOT) node 200 in
It will also be understood that each asCase node 205, 210, 215 and 220 includes a Result pointer pointing to its Result node. Thus, in block 403 the process sensor data procedure 400 may determine the Result node of each node 205, 210, 215 and 220 on the asCase list of the current K node by following its respective Result pointer to its respective root node. The Result nodes determined in this manner in block 403 may be compared with the elemental root node of the sensor corresponding to the received particle as shown in block 404. A determination may thus be made whether the Result node of any of the nodes 205, 210, 215 and 220 on the asCase list of the current K node match the elemental root node for the sensor of an input particle in block 404 of the process sensor procedure 400. The determination whether there is a match with the elemental root node for the sensor of the input particle may be made in decision 405.
Further to the foregoing example, the input particle in
However, the asCase node 205 does contain a Result pointer pointing to the C elemental root node 225. Decision 405 of the process sensor data procedure 400 may therefore find that the Result node of the subcomponent node 205 is a match with the input particle. The current K location pointer may be set to the node +C 205, which has become the current K location of the level as shown in block 407. (For exemplary purposes in the diagrams, when the prefix notation “+” is placed before a value in a node in the figure, it indicates that the prefixed node has a valence, which will be understood to stand in for the entire thought up to but not including the prefixed node.) It will be understood that the asCase nodes of the current K node may be compared in any order and that once a match is found no more comparisons are needed.
In a different example, the current K location could be the subcomponent node 205 and the input particle could be the letter particle A. Pursuant to block 402 the asCase node of the node 205 is determined to be the subcomponent node 206. Since the Result node of the node 206 is the elemental root node representing the letter particle A, a match is found in decision 405. Thus, in block 407 the current K node is incremented to the subcomponent node 206.
Creating New Nodes
In some cases it may turn out that none of the nodes on the asCase list determined in block 402 has a Result pointer pointing to the root node of the input particle. Under these circumstances a match is not found in decision 405. Thus, it may be necessary to create new K structure as shown at block 408. The process of creating a new node is disclosed in several of the references incorporate herein, such as U.S. Pat. No. 6,961,733 and U.S. patent Ser. No. 11/185,620, entitled “Method for Processing New Sequences Being Recorded Into an Interlocking Trees Datastore” for detailed explanation of how new nodes are created. Regardless of whether execution of the process sensor data procedure 400 proceeds by way of block 407 or by way of block 408 the intensity count may be incremented as shown in block 409.
Processing Delimiters
Refer back to
As previously described, after comparing an input particle of data to the current list of delimiters in block 304 of the praxis procedure 300 a decision is made in decision 308 whether there is a match. If the input particle is found to match a currently defined delimiter in decision 308 the procedure of block 301 is initiated in order process the received delimiter. The procedure initiated by block 301 is the process delimiter procedure 500 of
In the preferred embodiment of the invention delimiters are used to indicate the end of a set of particle sequences of data as they are streamed into the K Engine 11. For example, as mentioned above, in the field/record universe, data may come from traditional databases in the format of fields and records.
Refer to
The first field in the exemplary particle stream 600 is the Last Name field 601 and is shown with the data sequence Cummings. The second field is the First Name field 602 and is shown with the data sequence William. The third field is the Telephone Number field 603 and is shown with the data sequence 7547860. At the end of the fields 601, 602 there is shown an end of field (EOF) delimiter 1D 604.
The hexadecimal character 1D 604 is thus used as an end of field delimiter for ending the first two fields 601, 602. However, the hexadecimal character 1E 605 is used as both an end of field delimiter for ending the last field 603, and an end of record delimiter for ending the exemplary record 600. As such, it is a single delimiter that ends both the field 603 and exemplary particle stream 600, and, in general, in particle streams such as the exemplary particle stream 600 a delimiter is not required for closing each level of the KStore.
Thus, significantly, the hexadecimal character 1E 605 may be used to simultaneously end both: (i) its own level in the K structure (the record level), and (ii) a lower level of the K structure (the field level). Accordingly, in the embodiment of the invention represented by the exemplary particle stream 600, each level of a particle stream is not required to have its own separate closing delimiter. Furthermore, a higher level delimiter such as the delimiter 1E may complete any number of incomplete sequences, and thereby close any number of lower levels, in the manner that the field level of the exemplary particle stream 600 is closed.
Since textual data is not the only data that can be particlized and streamed into the K Engine 11, a more generalized explanation of delimiters may be helpful. In general, particles coming into the K Engine 11 may be thought of as incomplete sequences which can operate cooperatively to form complete sequences. Each incomplete sequence can represent an individual particle, set of particles of data, or the absence of particles. Individual incomplete sequences may be streamed into the K Engine 11 to form complete sequences. This is analogous to individual fields (incomplete sequences) such as the fields 601, 602, 603 forming a complete record (complete sequence) such as the complete record 600.
Although the hexadecimal characters 1D and 1E are used as delimiters 607,608 in the illustrative examples, it will be understood that any other particle may be defined to serve as delimiters 607, 608. For example, a comma, another numerical character including characters that are not hexadecimal characters or a specific group of pixels. Thus, delimiters may be any particle that is defined as such for the praxis procedure 300 when the processing of the delimiter particles begins.
It should be noted that incomplete sequences are not limited to single particles of data. An incomplete sequence may be any sequence of data that is experienced before an EOT delimiter is experienced. An incomplete sequence may also include the absence of particles indicating a null value, terminated by an EOT delimiter.
Again referring back to the praxis procedure 300 in
Refer now to
As previously described, it is possible for the praxis procedure 300 to receive a higher level delimiter for completing its own level of the K structure while lower levels of K structure are still incomplete. Under these circumstances, the higher level delimiter may complete as many incomplete lower levels as necessary prior to completing its own level.
For example, refer above to the exemplary particle stream 600 shown in
Thus, at the time the delimiter character 605 is received: (i) the field 603 represents an incomplete sequence on an incomplete lower level, and (ii) the delimiter character 605 is a delimiter for a higher level of K structure than the current level of field 603. Accordingly, the system and method of the present invention may determine both: (i) that the level of the field 603 must be completed, and (ii) that the level of the record 600 must be completed. Additionally, the system and method of the present invention may perform the operations necessary for completing both the field 603 and the record 600.
Furthermore, those skilled in the art will understand that a received delimiter may indicate the end of any number of lower levels in the manner that the delimiter character 605 indicates the end of only a single lower level. Accordingly, the system and method of the invention may perform the operations necessary for completing as many lower levels as required in addition to completing the level of the received delimiter.
Therefore, the process delimiter procedure 500 of
As previously described in the current embodiment, sets of particle sequences, such as the sets of sequences forming the incomplete sequences 606 in
Level 0 (230) of the K shown in
Level 1 (235) may represent the subcomponent nodes and end product nodes of the paths 240, 245 and 250. The Result pointers of the nodes in level 1 point to the elemental root nodes in level 0.
For example, the path 240 includes the nodes 200, 205, 206, 207, 208 and 260. Assume that a delimiter for end of field, such as the delimiter 1D 265 similar to the delimiter 1D 604 in
Level 2 (255) represents the subcomponent nodes whose Result pointers point to the complete sequences of level 1 in
Referring back to
The process delimiter procedure 500 may next determine which, if any, levels lower than Input Delimiter Level are incomplete at the time the input delimiter is received. This determination may be made with reference to the list of the current K nodes in the K structure. As previously described, this list may contain the current K pointers for each level of the K structure. In one embodiment the K location pointer for each level may indicate the node in that level where the last event for that level was experienced, and the K location pointer for completed levels can point to any location designated as a sequence beginning location. In one preferred embodiment the sequence beginning location can be the BOT node 200. The process for ending the incomplete sequences located in this manner may begin with the lowest such level as shown in block 502. The lowest such level, in general, can be any level of the KStore. Execution of the process delimiter procedure 500 may then proceed to block 503 where the process complete level procedure 550 of
For example, in
Refer to
In block 504 of
Refer to
In a further example of the case in which execution of the process complete level procedure 550 proceeds from decision 505 and builds a new node, assume that the current K pointer is pointing to the subcomponent node 274 of
However, when an end product asCase node of a current K node has already been experienced and built, execution of the process complete level procedure 550 may proceed from decision 505 to block 507. For example, if the field represented by the path 250 has previously been experienced by the K structure at least once, the asCase list of the node 274 is not empty. Thus, a comparison between the Result node of the asCase node 275 and the elemental root node for the delimiter may be positive. In the current example, such a match is found because the asCase node (the node 275) of the current K node (274) does, in fact, have a Result pointer pointing to the ID delimiter sensor 265.
Thus, in this example, execution of the process complete level procedure 550 may proceed to block 507. In block 507 the previously existing node 275 may become the current K node and the count of the nodes may be incremented.
Whether execution of the process complete level procedure 550 proceeds byway of block 506 to create a new node and advance the current K pointer, or by way of block 507 to merely advance the current K pointer to a preexisting node, the count of the node is incremented and a determination is made whether there are potentially any higher levels above the current level as shown in decision 508. The determination whether there are higher levels is made by accessing the list of defined delimiters as previously described and determining where the determined delimiter is located in the defined hierarchy.
If there are no levels higher than the current K level, the K location pointer is set to the BOT node 200 to indicate that the current K level is complete as shown in block 509. The system may then wait for the next input particle. Processing by the process complete level procedure 550 is then complete. Processing may then return to the process delimiter procedure 500 in
Refer to
The upper level subcomponent procedure 590 may begin with blocks 514a-d. The operations of blocks 514a-d of the process upper level subcomponent procedure 590 are substantially similar to the operations of blocks 401-404 of the process sensor data procedure 400 described above.
As shown in block 514a, the current K node on the upper level may be determined. For example, referring back to
In decision 515 a decision is made whether any of the asCase nodes of the current K location for the current level have a Result node that matches the root node or end product node for the previous level. If there is a match the upper level K location pointer is set to the matched node as shown in block 516. However, if the end product node has not been experienced before at this level then no matches are found by decision 515 and processing continues to block 517. In block 517 a new subcomponent node may be created in the higher level and the current K location pointer for the higher level may be set to the new node.
For example, refer to
Further to
The elemental root node 205 thus does not match the end product node pointed to by the K location pointer for level 1, the +EOT node 260. Now refer to
The foregoing descriptions disclose how delimiters may signal the end of complete sequences at lower levels (e.g. field levels in a field/record data universe). The following discussion discloses how delimiters are used to signal the end of complete sequences at upper levels (e.g. record levels in a field/record data universe). In this part of the explanation, assume that portions of an upper level have already been established.
It will be understood that to some extent the procedures for completing upper levels are similar to those for completing the lower levels as they were previously described. Therefore, where the following procedures are similar to those that have previously been taught above, the explanation may refer back to the earlier explanations. Also, the following discussion is taught using the exemplary delimiters from the field/record universe. And, before continuing, some assumptions may be made before explaining in detail how the upper level delimiters are processed.
Process Upper Level When Lower Levels are Complete
Assume in the following discussion that a K structure such as K 14 shown in
As mentioned above, the following discussion uses the K structure shown in
Level 0 (230)—Contains all of the elemental root nodes of the K Store 14.
Level 1 (235)—The paths 240, 245, and 250 are complete. The K location pointer for level 1 points to the BOT node 200.
Level 2 (255)—The sequences that can be represented by the subcomponent nodes 220, 280, and 281 have been processed and the K location pointer for the level 2 points to the node 281.
As the following discussion begins, the next particle that is experienced is the delimiter 1E, wherein the delimiter 1E closes its own level (level 2) as shown in the exemplary particle string 610 of
As explained above, the praxis process 300 shown in
Refer back to the process delimiter procedure 500 in
Again, as explained above in detail, the process complete level procedure 550 shown in
From block 509, the process complete level procedure 550 returns to the calling block 510 in
Process Upper Level When Lower Levels are not Complete
Assume in the following discussion that a K structure such as K 14 shown in
As mentioned above, the following discussion uses the K structure shown in
Level 0 (230)—Contains all of the elemental root nodes of the KStore 14.
Level 1 (235)—The paths 240 and 245 are complete. Within the path 250, the sequences that may be represented by the nodes 215, 216, 272, 273 and 274 have been experienced, and the K location pointer for level 1 points to the node 274.
Level 2 (255)—The sequences that may be represented by the subcomponent nodes 220 and 280 have been processed and the K location pointer for the level 2 points to the node 280.
As the following discussion begins, the next particle that is experienced is the delimiter 1E, wherein the delimiter 1E closes both its own level (level 2) and the level below it (level 1) as shown in the exemplary particle string 600 of
As explained above, the praxis process 300 shown in
Refer back to the process delimiter procedure 500 in
As explained above, the process delimiter procedure 500 may proceed by way of block 503 to initiate the process complete level procedure 550 of
If the +EOT node 275 has not already been created, there is no end product node and no match in decision 505. The process complete level procedure 550 may then proceed to block 506 where the +EOT node 275 may be created. Since the new node is to be located on level 1(235) the Result node of the new +EOT node 275 is set to EOT 1D 265.
The procedure 550 may increment the count and proceed to decision 508 where a determination may be made whether there are any higher levels. Because there is a level above level 1 (235), namely level 2 (255), the process upper level subcomponent procedure 590 of
As the process upper level subcomponent procedure 590 of
The current level is then set to the next highest level in block 511 of the process delimiter procedure 500. In the current example the next highest level is delimiter level 2 (255). This is the record level in the field/record universe of data of the current example. As shown in block 512 of the process delimiter procedure 500 the new level is compared to the variable Input Delimiter Level of block 501. In the example, the input delimiter is 1E, which represents level 2 (235), and the current K level is also level 2 (235). In the decision block 513 a determination is made whether the current K level is greater than the variable Input Delimiter Level. Since both level numbers are 2 in the current example the answer to decision 513 is NO. The process delimiter procedure 500 may therefore proceed from the decision 513 by way of the process complete level block 503 to the process complete level procedure 550 of
Again, as explained above in detail, the process complete level procedure 550 shown in
From block 509, the process complete level procedure 550 returns to the calling block 510 in
Count Fields
While count fields within interlocking trees datastores have been discussed in 10/666,382, the following disclosure teaches some preferred uses. As has been previously taught, the K nodes of an interlocking trees data store may include additional fields representing any type of information associated with the nodes. This may be illustrated using
An intensity variable can be defined as a mathematical entity holding at least one value. A simple example of an intensity variable can be a single ordinal field value, such as 1, to be used to increment or decrement count fields 702 to record the number of times that a node is accessed or traversed within a K Store. By making this term so broad a intensity variable populated count field 702 can be used for applications of the inventive interlocking trees structure dealing with learning, forgetting, erroneous recorded data, recording which entity is doing an inquiry, recording the type of inquiry being used and other processes of interest which may be occurring when using the data.
The count field 702 is added to a node 700/701 in order facilitate the use of the knowledge store represented by the interlocking trees structure and is particularly useful when statistics, such as frequency and probability, are sought.
Count Fields 702 and the Praxis Procedure 300
Refer back to
Incrementing Count
Typically, the count is incremented for learning functions and not incremented for query functions. As an example of this in a field/record universe, the count field 702 for each K node traversed can be incremented by 1 as new transaction records are recorded into the K. Newly created K nodes can be initialized to 1. An example of a case in which a count field 702 is not incremented within a K Store is a dictionary spell checker in which a user is not concerned about the number of times a word is misspelled.
Counts are shown in
As shown in
The second exemplary fictional record of the record set 800 experienced in the building of the K Store represented by the node diagram 900 can be Bill_Monday_Sold_NJ. Since Bill was already experienced, a new node for Bill is not created in the praxis procedure 300, as explained earlier. However, because the particle Bill is experienced a second time, the count for the subcomponent node 902 as well as the Bill root node, are incremented to 2. Since this is the first time Monday is experienced, a new node 906 is established to represent Monday. The counter is of the new node 906 set to 1. The root node for Monday is incremented to 1 also. The remaining nodes in path 904 for Sold and NJ are established in the same way in order to represent the second record. After all records 800 have been experienced, the counts reflect the number of times each of the particle sequences has been experienced. In the node diagram 900 representing the set of records 800, for example, Trial was experienced three times. Therefore, there is a count of 3 in the Trial elemental root node NJ was experienced only once. Therefore, the NJ elemental root node has a count of 1.
In a preferred embodiment of the invention, the foregoing process occurs as events are learned into a K structure. When queries are performed on a K structure that contains the transaction records, count fields 902 can remain unchanged. It should be noted however that querying may update the count fields for some alternate embodiments.
Variable Intensity Values
The increment value however is not always 1. If a situation requires it, the increment may be any value. As previously, described, the routines used by the praxis procedure 300 may update the count when they are called. The called routines can then use the increment value, or intensity value, when incrementing the count field. For example, see block 409 of
Referring back to
Furthermore, the intensity variable may change to different values and in different directions for various functions. A simple example of different intensities might be the addition of a value +1 each time a query traverses a node, and the addition of a value of −100 if a path containing a certain node (or certain sequence of nodes) is deemed (for some overarching reason not of importance to this explanation) to be a mistake. For example, a sequence can be determined to be a misspelling. Additionally, a sensor may determine that an area contains a dangerous chemical. A human child simulator may touch and burn itself on a hot stove in a simulation.
In an alternate embodiment a separate node can hold a new intensity value for each kind of node traversal, thus creating a cluster in situations where a node is accessed during queries of type one, type two, experience one, experience two, etc. ad infinitum. In an alternate preferred embodiment, intensity variables in a count field can provide a simple approach to this problem. If this alternative is considered, an approach of using a separate node, possibly even an elemental node, or root node, to record a count for the number of traversals of each type related to the node is one way to implement this approach. The praxis procedure 300 can then handle the updating of this node as shown in
Thus, in one embodiment, a count field 702 of a K node can be incremented when new data is incorporated in an interlocking trees data store, while incrementing the count field may be omitted when the interlocking trees data store is being queried. This approach yields a bigger value for new data and no change for inquiries. Accordingly, the intensity variable must be chosen for its suitability to the problem being addressed by the invention.
Negative Intensity Values
As shown above, the intensity value need not always be positive. Records or paths may be deleted from the K by subtracting an intensity value from their counts. In a field/record universe if a situation requires it, the count may be decremented to delete a record from the structure. The record to be removed can be presented as particles to the praxis procedure 300 in the same manner as a new record or a query, except that a negative intensity value can be provided.
An alternate node diagram can differ differs from the node diagram 900 of
In some preferred embodiments of the invention the count can be decremented to 0 but the nodes can remain in the K structure to indicate a history. In other embodiments, if the count is decremented to 0 the nodes can be entirely deleted from the K structure. The praxis procedure 300 can determines whether to delete the nodes having a count of 0 within block 409 of
Using the Count for Determining a Most Probable K Location
The concept of a most probable node location refers to the possibility of using count fields 702 to determine the most probable or the least probable path from a current K location to a next K location. The ability to determine a most probable or least probable next location can be used when learning is inhibited and a current input particle does not match any Result node of an asCase node of the current input particle.
Refer back to
In order to determine the most probable next node, the asCase list of the current K node can be accessed. For each of the asCase nodes on the asCase list the count field 702 can be accessed. A determination can be made which asCase node has the highest count. The current K location can thus be set to the node having the highest count. Since the asCase node with the highest count has been experienced the most times after the current node has been experienced, it therefore has the highest probability of being the next current K location. In a preferred embodiment, a message or log file may be written to indicate that an aberration from normal processing has occurred, wherein a most probable location was used instead of a known K location. This same process can apply to all levels of the K structure, as seen in
Referring again to
The asCase list for the Monday node 906 is found to contain two entries: the Trial node 907 and the Sold node 910. The count fields for the nodes 907, 910 are accessed. The count field for the Trial node 907 is found to contain 3 while the count field for the Sold node 910 contains 1. Therefore, the K location pointer for the level is set to the Trial node 907 and the trial node 907 is incremented since it has the highest count, and is therefore assumed to be the most probable next node.
It should be noted that the requirement for determining the most probable node may involve checking more than a single node. It may also involve, but is not limited to checking node sequences, elemental values, asCase/asResult lists, or additional node fields of information. As well, various other count field values may be checked. For example, in some instances, the lowest value may be used to indicate most probable.
Referring to
In the determine most probable node procedure 1010 the current K node is determined in block 1014. The asCase nodes of the current K node are located in block 1018. In block 1026 the counter MaxCnt is initialized and the Result nodes of the asCase nodes are compared with an input particle as follows.
The next asCase node in the asCase list is assigned to the variable Node as shown in block 1030. If the variable Node is not null as determined in decision 1036 a determination can be made in decision 1038 whether its Result node matches the input particle. If there is a match the correct node for the input particle is found and the current K pointer can be set to the matched node as shown in block 1048.
If the Result node of the variable Node does not match the input particle, as determined in decision 1038, a determination can be made in decision 1040 whether the count of the current asCase node is greater than the highest count encountered so far by the determine most probable node procedure 1010. If the count of the current asCase node is greater than MaxCnt, it can replace the current value of MaxCnt as shown in block 1044. Additionally, the variable MaxNode is assigned the value of Node. In this manner the determine most probable node procedure 1010 can find the asCase node having the highest count as it searches for a match with the input particle. Execution of the procedure 1010 can then return to block 1030 where the next asCase node is examined.
If none of the Result nodes of the asCase nodes of the current K location match the input particle, a null is eventually found in decision 1036. Accordingly, it can be assumed that the input particle in invalid. Under these circumstances the most probable next node can be used. As shown in block 1052 MaxNode, asCase the node having the count equal to MaxCnt, is determined to be the most probable node and the K location pointer is set to the most probable node as shown in block 1060.
It will be understood that small modifications of the determine most probable node procedure 1010 depicted in
In a real time environment, many unique situations can occur as a K structure is created. For example, as records are recorded into a K in a field/record universe, the K may be queried by multiple applications at the same time. Therefore queries from one application may encounter partially recorded events that were started by a different application. For some processes related to the queries, it may be important to only process complete records within the K.
In other cases, some of the partially recorded events may be determined to be in error during the learn process and therefore should be ignored. For example, a field in a field/record universe may have a fixed set of values, such as YES and NO. If a value of FALSE is received in the field, it can be recognized as an error condition. It is desirable to have a method for handling such an error condition. When an error such as this occurs, the partial event may be backed out of the K structure in one preferred embodiment. In another preferred embodiment the error nodes may be left within the K structure, so that a history of errors may be maintained. In this embodiment the partial event could be maintained in the K structure indefinitely. A method for identifying and ignoring the partial events during an active query is therefore useful.
Earlier U.S. patent application Ser. No. 11/185,627, entitled “Method For Reducing the Scope of the K Node Construction Lock” taught an improvement over prior art methods for preventing queries from processing partial events. The prior art taught locking the entire structure during a learn operation until the recording of an entire event was completed. Thus, in this prior art method queries could only be performed when the K structure was in a complete state. This method however may result in inefficiencies, especially when there is a large number of events to be recorded. The improvement taught in application Ser. No. 11/185,627 is a method wherein only a single node under construction is locked out, leaving the rest of the K available for accessing during the process of building the K.
Processing Partial Events
As described above and in the earlier referenced patents, additional fields within the nodes 700/701 as shown in
Processing Count After Sequence is Complete or Delimiter is Encountered
In one embodiment, a count field 702 may be updated during a learn process as nodes are either created or traversed within the Praxis procedure. For example, referring to
However, in another preferred embodiment of the invention the count fields 702 for the K nodes need not be incremented at the time they are traversed or created. Rather, the count fields 702 may be incremented as a set once the building or traversing of the K path 101 is complete. In this way, the count fields 702 for the existing K nodes may remain unchanged and the count fields 702 for any new structure may remain at 0 until the entire path is completed. This method permits identification of partial paths and complete paths.
The internal K utilities, learn and API utilities can thus access the count fields 702 of K nodes during any query processing and ignore any nodes 700/701 having a zero count. Thus, existing nodes can correctly indicate the number of completed paths that they were experienced by thereby maintaining the accuracy of any analytic calculations.
In another embodiment of the invention a method may be provided for updating an additional field 703 of a node 700/701, such as the count field 702, to indicate a complete path. The path may be traversed in any manner. A preferred traversal may include traversing the path from the end product node to the BOT node, and then traversing back across the path back to the end product node. The count field 702 associated with each node may be incremented as each node is encountered in the traversal back to the end product node. To prompt the system that a path or structure is ready to be updated, the K engine may determine when a path has been completed.
In one preferred embodiment, the K engine may initiate the traversal when it experiences a specific end product node or delimiter. As previously described with respect to the praxis procedure 300 the updating of the count fields 702 may be triggered by encountering a delimiter such as the exemplary hexadecimal delimiter 1E 282 in a field/record universe or any other delimiter that may be used to indicate an end of sequence in an input particle stream.
Referring back to
Refer now to
When an end of sequence delimiter is experienced the process update count procedure 1200 of
In either case a determination is made whether there are potentially any higher levels as shown in decision 1225. If there were any higher levels in the KStore, execution would proceed to the process upper level subcomponent node procedure 600 of
Note that the method for box 1235 may be processed within the Praxis procedure or may be performed as a separate method which may be referred to as TraverseAddOne or TraverseAddIntensity. This separate method may be called from box 1235 to perform the same functionality as box 1235.
Updating Counts from Outside Praxis Procedure
In one embodiment of the invention a method for updating an additional field, such as a count field, to indicate a complete path, involves initiating the update process from the external calling procedure which is called the Praxis procedure 300. The external calling procedure may be a procedure such as a learn procedure, internal K utilities or API utilities.
After it is determined that the last particle processed resulted in an end product node in this method of the Praxis procedure, a determination is made whether there are potentially any higher levels to be processed. Box 1235 in
Identifying Partial Sequences Using the Additional Fields 703
One preferred embodiment of the present invention provides another method for permitting a completed sequence indicator to indicate a partially recorded event to permit the partially recorded event to be ignored by an active query. In this alternate embodiment of the invention the completed sequence indicator may be obtained by adding an additional field 703 to the nodes in addition to the count field 702 (such as the fields shown in the nodes 700/701 of
Sensors
As taught earlier, the praxis procedure 300 may recognize sensor data, delimiters and unidentified particles. As taught in U.S. Pat. No. 6,961,733 and Application Numbers 2005/0076011 and 2005/0165749, sensor data may be represented within a K structure by a node called an elemental root node, from which all other K nodes may be constructed. While sensors and elemental root nodes within interlocking trees datastores have been discussed in the above mentioned patents, the following teaches some preferred methods of processing the sensor K nodes.
A sensor K node is a type of elemental node that contains or points to values for the smallest data component, a particle, that may be incorporated into an interlocking trees data store. As taught above, sensor data may be a particle of digitized data of any type. In the case of field/record or text data, the particles may include characters such as alphanumeric characters, special characters and some control elements.
As taught above, the KEngine or Praxis procedure may use lists to keep track of the sensor K nodes. However, it will be understood that any type of data structure known to those skilled in the art may be used to keep track of the locations of the sensor K nodes as taught herein. It should also be noted that delimiter K nodes may also be maintained as part of this list.
In a previously described embodiment, whenever data is learned into a K or sent to a K, for example as a component of a user query, only individual data particles are sent to the KEngine or Praxis procedure. For example, in a field/record universe, if a sequence such as CAT is to be sent to a K, only the individual particles are sent to the Praxis process, for instance the first particle C is sent, followed by A and then T. To find the corresponding sensor K node for the particle, the Praxis procedure may search a list of sensor K nodes to find the sensor K node associated with the particle. The value of the particle may be compared to the value associated with each sensor K node. The search of the list may end when a match is found or all sensor K nodes have been searched. Because this method potentially entails searching all of the sensor K nodes which might be used in the structure, the number of sensor K nodes to search may be prohibitively large.
As noted above, there are various particle formats (pixels, text, sounds, etc.) which may be input into K. In order to use a sensor index table, an indexing scheme must first be established for the particle formats which will be received by the Praxis procedure. In the field/record universe, for example, the indexing scheme may be determined by the association of characters to the ASCII character set. Each character in the ASCII character set is associated with a unique numeric value. This value may be used as the index into the sensor index table. If the characters were from another character set, perhaps Chinese, then the Unicode character set may be used to determine the unique numeric values. If the particles were pixels, then an indexing scheme to assign unique numeric values to the various pixel combinations that may be used would be determined. Any indexing scheme which assigns a distinct unique value to a specific particle may be used.
Potentially, some of the particles received by the Praxis procedure may either be known or unknown. Earlier, in the explanation of the praxis procedure 300, it was taught that in one preferred embodiment while processing particles, known particles could be processed while unknown particles could be ignored. However just because a particle is unknown does not mean it may not be made available for processing in a K. For example, the set of possible pixel values is extremely large. It is therefore undesirable to predefine all possible pixel sensors. Therefore, if an image is scanned and digitized some of the pixels may be unknown. In another preferred embodiment, the system may be able to recognize previously unknown particles which match the format of the particles currently being processed by adding new sensor K nodes. The following teaches both embodiments with known and unknown particles.
Known Particles—Creating and Searching the Sensor Index Table
A number of different methods for learning particles of data into a K and building K nodes corresponding to the particles were taught in earlier patents. At the instantiation of a K, predefined particles are used to create a set of sensor K nodes for use in the structure. A structure, which may be called a sensor index table, may contain pointers to these sensor K nodes. Therefore, whenever the location of a sensor K node is needed, the array, or as those skilled in the art will understand, a table, or hash table or some other structure, may be accessed to find the pointer to the required sensor K node.
In a preferred embodiment, an indexing scheme is determined based upon the value of a data particle or its corresponding sensor K node. A unique numerical value based on the representation of a data particle is determined. These unique numerical values may then be used as an index into a sensor index table. The pointer to the associated sensor K node may then be located at the entry for that index. For instance, in a field/record universe, the characters used as input may be encoded using the predefined ASCII character set. This character set associates each character with a specific numeric value. For instance, the numerical value for the capital letter C in the ASCII set is hexadecimal 43. The numerical value for a question mark is hexadecimal 3F. Using this correspondence, it is then possible to use the numerical value of the particular particle as an index into a sensor index table. The numerical value of the particle C, expressed in hexadecimal is 43. Therefore the location of the entry in the sensor index table which may contain a pointer to the sensor K node for the particle C is located at entry hexadecimal 43.
Refer to
The next sensor particle value is received from a list of predefined sensor values as shown in block 1402. Note that the sensor values that are provided to initialize the table may be presented to the procedure in any manner convenient. In some embodiments this may be in the form of an array of particles. A determination may then be made whether a particle was received in box 1402 indicating that there is another particle to process in decision 1403.
If a particle was received as determined in decision 1403, a sensor K node may be created to represent the particle as shown in block 1404. If a determination is made in decision 1405 that the value of a particle is not within the current size of the array, the sensor table may be reallocated to a larger size as shown in block 1406. The new entries in the reallocated sensor index table are set to null as shown in block 1407. A pointer to the location of the newly created sensor K node is entered into the empty element that is indexed by the particle value.
However, if the particle value received in block 1402 is determined to be within the range of the table entries in decision 1405, the particle value may be used as an index into the array as shown in block 1408 without reallocating the sensor table to a larger size. In this case, a pointer to the newly created sensor K node is entered into the empty element of the sensor index table whose index corresponds to the particle value of block 1402.
Procedure 1400A proceeds back to box 1402 to attain the next particle to be added. The process continues until it is determined in box 1403 that there are no further particles.
During the praxis procedure 300, when a particle is received and processed a determination may be made whether the particle has a corresponding sensor K node using the sensor index table created by the sensor table creation procedure 1400A. Instead of searching through a list of sensor K nodes looking for a match between the input particle and a sensor K node, the unique numerical index of the input particle as determined by the selected indexing scheme may be used to determine whether the particle occurs in the sensor index table.
Refer to
If the particle value is not in range as determined in decision 1410, the particle may be ignored. This may be indicated by returning a null value to the Praxis procedure box 305, although other means may be known to those skilled in the art. If the particle is within the range of the sensor table size, the index number (e.g. the unique numeric value representing the input particle) is used as an index into the sensor index table as shown in block 1411. If the index entry contains a null table entry, the particle may be ignored as shown in block 1412 in one embodiment of the invention. If however, the index into the table points to an entry that contains a pointer, then a corresponding sensor K node exists.
The table entry located in this manner may be used to locate the specific sensor K node corresponding to the input particle and the input particle may be returned for processing as shown in block 1413 to the Praxis procedure. Examples of the manner in which the K node may be processed are taught herein above. For example, the processing of a K node may include performing a traversal of paths within the KStore making use of sensors which are the Result nodes of the K nodes in the traversed paths, as understood by those skilled in the art.
For example, referring back to
Unknown Particles—Creating and Searching the Sensor Index Table
Refer now to
Within the sensor table processing procedure 1500, a particle may be received from the Praxis procedure box 303. The particle value is looked up in the sensor index table as shown in block 1501. If the particle is found in the sensor index table, for example as set forth in the sensor table lookup procedure 1400B, the sensor node which corresponds to the particle is returned to the praxis procedure 300
If the particle is not found and the particle meets the criteria for adding new sensor K nodes, a new sensor K node may be created for the particle as shown in block 1505. The newly created sensor K node may contain additional fields indicating, for instance, the date the sensor was added, or any other information about the sensor that may be deemed appropriate. A pointer to the new sensor K node is entered into the table at the index location corresponding to the particle value as shown in block 1506. The location of the newly created sensor K node is then returned to the praxis procedure 300.
As explained earlier, a count field may be provided in relation to K nodes to facilitate use of the interlocking trees structure. This is particularly useful when statistics, such as frequency and probability are sought. As also explained, the count stored in the count field may be incremented or decremented during the processes of creating, deleting, or traversing the K structure. Prior art methods of updating the count fields associated with common K nodes taught earlier do not address what may happen if learn streams are being processed in a multithreaded, multiprocessor environment. Methods to address issues in multithreaded, multiprocessor environments are therefore needed.
Multiprocessor Environments
What is meant by a multiprocessor environment can be seen in
In the current embodiment, instead of the process for each record or sequence waiting to update the count fields, the process used to update the count field may be split into separate multiple threads. Some K node count fields may be updated immediately and other K node count fields may be updated later by this new thread or threads, created for that purpose. In programming terms, “threads” are a way for a program to split itself into two or more simultaneously running tasks. Updating the K node count using multiple threads and at different times reduces the possibility that there will be a conflict updating any individual K node count field from multiple sources at the same time. Reducing these conflicts results in more efficient processing times.
The following examples explain data in terms of the “field/record” universe. By “field/record” universe we mean data from traditional databases, whereby a “field” represents the title of a column in a table and a record represents the rows within the table that contain the actual data. However, “field/record” data is not the only type of data that may be particalized into K. Those skilled in the art will understand that as long as data can be digitized, it can be particalized and streamed into a K. For example, if the data universe contains graphic images, particles may be pixels or if the data universe is auditory data, particles may be digitized sound waves.
For example, in a field/record universe, if two records with common fields and common field values are sent to the K Engine, the counts of the common nodes may be updated in a single, separate counting thread to prevent simultaneous updates. K nodes that are less likely to be common may have their counts updated immediately by the Learn thread.
It should be noted that threading is not limited to a process that occurs at an “end of field” or “end of record;” in the preferred embodiment, it may occur wherever there is a particle delimiter (e.g. the end of a letter, word, sentence, or paragraph in the field/record universe, or any digitized particle representing a delimiter in other data universes). In some cases it may be desirable to providing threading on an individual node basis. Nodes could then be added to a queue for later processing within the original Praxis process. For instance, elemental root nodes could be added from box 409 in
As explained in the above mentioned patents and as may be seen in
Note that prior to starting this process, a queue level may be provided. This queue level may determine at what level in the K hierarchy node count fields are placed on the queue to be updated at a later time. This level may be determined by the data to be used as input to the K (for instance how much common data the input contains and at what level this information is common). In the field/record universe, it may be determined that the most efficient queue level is at the elemental root nodes. However, if there are many fixed field values, then the queue level may be set at the field level. The determination may also be made based on the type of environment the process will be run in. Note that for the following examples, numeric hierarchical K levels are used with a higher level number indicating a “higher” level in the K. This is not required and any means of indicating a level and a hierarchy may be used.
For the following discussion, refer to the flowchart depicted in
Queuing
For this discussion, the process of updating the count fields by queuing begins with decision 1705 in
Refer back to
If, however, the queue level is less than the current K node level, then the process continues to block 1709 at which time the TraverseAddAndQueue process in
Refer to
Block 1752 determines if the Result pointer of the current node is null. If it is, indicating that an elemental root node has been encountered, the process continues to block 1758 to queue the current node. Otherwise, the process continues to block 1753 to determine if the level of the Result pointer of the current node is less than or equal to the queue level. If the level of the Result node pointer of the current node is less than or equal to the queue level, then the process adds the Result pointer the queue in box 1759. If the Result node is at a level higher than the queue level, processing continues to box 1754 at which time the TraverseAddAndQueue procedure is called again, passing the Result node as the starting current K node.
Box 1755 updates the count field of the current K node following the processing of the Result node. The current K node is then updated to point to the Case node of the current K node. The process continues at box 1751 with this new current K node until there are no more nodes to process.
Using
The address of the current K Node is now 1802. Since the current node is not null, the process continues to block 1752. At box 1752 the value of the current K Node's Result pointer is determined. Since the level of the Result node 1804 is not null, the process continues to block 1753 where the level of node 1804 is compared to the queue level. Since the queue level is equal to the node level, the current K Node Result pointer 1804 is placed onto the queue. Box 1755 updates the count for node 1802 and the current K node is set to the Case node 1803 in box 1756. The process continues in a similar fashion for node 1803 until the current K node is set in 1756 to the case node of node 1803 which is the BOT node 1820.
Node 1820 is tested in box 1751 and is determined to be not null. The process continues to box 1752. Since the current K Node has no Result pointer (i.e. its Result pointer is not pointing to any nodes below it) it is considered null. Therefore, the process continues to box 1758, where the node 1820 is added to the queue. Processing continues at box 1756, where the current K node is set to the case node of node 1820. Since the case pointer of node 1820 is null, the current K node is set to null. Box 1751 determines that the current K node is null and returns processing to the calling procedure.
Using the same data from
In the new instance of the TraverseAddAndQueue procedure, the current node 1804 is not null and the Result pointer of the current K Node is not null (i.e. it points to Result node 1812). Since the level of the Result node 1812 is equal to the queue level, the current K Node Result pointer 1812 and its corresponding intensity or count are queued as shown in box 1759. Next the process continues to 1755 where the count field for the current K Node 1804 is updated. The process then continues to block 1756 where the Case node 1805 of the current K Node 1804 is stored as the current K Node. The process reiterates back to decision 1751. In the same way as was just explained, the intensity variable is added to the counter of each of the nodes in Level 1 back to node 1810. In addition, the count for each of the remaining nodes in Level 0 which are pointed to by the Result pointers of nodes 1804-1810 in Level 1 are queued.
After completing the above and when node 1810 is the current K node, its Case pointer, node 1820, is stored as the current Node in box 1756. Then, when the process iterates back to decision 1751, the address of the current Node, is not null and processing continues to block 1752. Block 1752 determines if the Node Result pointer is null. Since the current Node is the BOT node, the Result pointer is null, and therefore, the BOT node is queued is block 1758. The process then continues to block 1756, at which time the current Node field is updated to the Case pointer of the current Node. In this case, the Case pointer is null. When control is passed to block 1751, the current Node is null and this iteration of the process is complete. Control is passed back to the previous iteration with the current node 1802 at box 1755. This process continues until all the record level and field level nodes have been updated and the related elemental root nodes have been queued.
De-Queuing
A further feature of this invention is an apparatus which in a preferred embodiment runs in a separate thread (or threads), to update the nodes that are retrieved from a queue. This may include whatever process is needed to schedule and execute multiple threads possibly in parallel. The process of updating node count fields that are retrieved from the queue may be called “thread de-queuing.” Note that although in the preferred embodiment, the address of the K nodes are placed into the queue, in some embodiments only the locations of the node's count fields may be queued.
The process of de-queuing as shown in
