Abstract:
A method for transmitting information in a KStore system having a KStore, an application programming interface and an application layer wherein the information is transmitted between the KStore and the application layer includes transmitting the information between the KStore and the application layer by way of the application programming interface. The KStore is constrained by way of the application programming interface with at least one constraint to provide at least one selected K path. The KStore is focused to provide a further selected K path. At least one KStore parameter is determined in accordance with the selected K path to provide at least one determined K parameter. The constraining of the KStore includes traversing the at least one selected K path.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     1. Field of Invention  
         [0002]     The invention generally relates to application programming interfaces (APIs). More particularly, the invention relates to an API set for use with data contained in an interlocking trees datastore.  
         [0003]     2. Description of Related Art  
         [0004]     Practically, an API (application programming interface) is any interface that enables one program to use facilities provided by another, whether by calling that program, or by being called by it. At a higher level still, an API is a set of functionality delivered by a programming system, and as such the mix of APIs in a particular system tells you what that system can do. APIs are known in the art. For example, U.S. Pat. No. 6,760,911B1, entitled “Messaging API Framework,” teaches methods for allowing C++ applications to communicate through an MQ Series gateway with CORBA-based applications. While producing satisfactory results, the methods used are not useful for KStore technology.  
         [0005]     The KStore technology addresses. the problems associated with traditional relational databases. As described in U.S. patent application Ser. Nos. 10/385,421, entitled “System and method for storing and accessing data in an interlocking trees datastore” and 10/666,382, entitled “System and method for storing and accessing data in an interlocking treees datastore” the KStore data structure can eliminate the distinction between transactional data and stored (relational) data.  
         [0006]     With the development of the KStore technology, there is a need for application programming interfaces to connect applications, data sources, and GUIs with the interlocking trees datastore.  
         [0007]     All references cited herein are incorporated herein by reference in their entireties.  
       BRIEF SUMMARY OF THE INVENTION  
       [0008]     A method for transmitting information in a KStore system having a KStore with at least one K path, an application programming interface and an application layer wherein the information is transmitted between the KStore and the application layer includes transmitting the information between the KStore and the application layer by way of the application programming interface. The KStore includes a plurality of K paths and may be constrained by way of the application programming interface with at least one constraint to provide at least one selected K path of the plurality of K paths. The constraining provides a set of selected K paths and the KStore is focused to provide a further set of selected K paths in accordance with the set of selected K paths. At least one KStore parameter is determined in accordance with the selected K path to provide at least one determined K parameter. The constraining of the KStore includes traversing the at least one selected K path.  
         [0009]     This invention extends the flexibility and ease of use of interlocking trees datastore, particularly of the type described in U.S. patent application Ser. Nos. 20040181547, 20050076011, 20050165749 and 20050165772 entitled “System and method for storing and accessing data in an interlocking trees datastore” and has particular applicability to the use of systems incorporating such KStore data structures as is found in U.S. patent application Ser. No. 10/879,329 entitled “Functional operations for accessing and/or building interlocking trees datastores to enable their use with applications software.” These patent documents are incorporated in their respective entireties by this reference thereto.  
         [0010]     While the prior patent documents describe both a KStore structure and a system for enabling use of a KStore with various applications for learning and querying, the system still requires an API to allow for the development and execution of multiple application programs without the possibility of any of the different applications corrupting the interlocking trees datastore and without the need for the application developers to have detailed understanding of the processes required to traverse and return address locations within the interlocking trees datastore.  
         [0011]     This API will service calls to the interlocking trees datastore engine from applications, to construct, query and maintain the interlocking trees datastore, without ever returning addresses that would allow direct access to the interlocking trees datastore.  
         [0012]     The invention can also provide security functions such as validating the KStore identity and that the calling routine has access. The inventors herein have determined that a number of processes ought to be created to facilitate use of KStore and queries of them. These functional objects that make queries of particular kinds can be called individually out of a set of such objects as needed, if they are put together into a system. We call them “functional categories.” We have previously described a system for supporting a KStore and suggest using it or something like it to support this set of functional categories.  
         [0013]     Accordingly, a set of such functional categories appropriate to specific kinds of queries have been created and new sets of them can be created using the ones described in detail herein. Because these functional categories can be defined in various ways for particular needs, we also describe with some particularity preferred embodiment routines, and subcomponents of such routines in some detail.  
         [0014]     As those of ordinary skill in these arts will appreciate, these functional categories in current technology paradigms are best implemented as software routines, but as those of skill in these arts will also appreciate such objects can easily be translated into hardware implementations without experimentation as to how to build them once such objects are described as set forth within. 
     
    
     BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS  
       [0015]     The invention will be described in conjunction with the following drawings in which like reference numerals designate like elements and wherein:  
         [0016]      FIGS. 1 and 2  are block diagrams illustrating the interaction of the main components that can be used in preferred embodiments of this invention.  
         [0017]      FIG. 3  is a block diagram of a message in instruction-word format.  
         [0018]      FIG. 4  is a flow chart of an application query handling process of an API Utility in accord with a preferred embodiment of the invention.  
         [0019]      FIG. 5  is a block diagram of a preferred embodiment API Utility component.  
         [0020]      FIG. 6  is a flow chart of system administration steps for K in accord with preferred embodiments of the invention.  
         [0021]      FIG. 7  is a flow chart showing an exemplary flow diagram of the StartEngine method in accord with preferred embodiments of the invention.  
         [0022]      FIG. 8  is a flow chart showing an exemplary flow diagram of the StartEvent method in accord with preferred embodiments of the invention.  
         [0023]      FIG. 9  is a flow chart showing how a KStore user interacts with the K in accord with preferred embodiments of the invention.  
         [0024]      FIG. 10  is a flow chart showing an exemplary flow diagram of the “Connect” procedure in accord with preferred embodiments of the invention.  
         [0025]      FIG. 11  is a flow chart showing an exemplary flow diagram of the “PredictSingleVariable” procedure in accord with preferred embodiments of the invention. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0026]     The organization of this patent is divided into sections as follows. The first section details a preferred embodiment KStore system for which the inventive functional objects will be operable, as sets or groups or individually, depending on the particulars of any given instance of such a system. Nearly all of this first section description is already found in U.S. patent application Ser. No. 10/879,329, entitled “Functional operations for accessing and/or building interlocking trees datastores to enable their use with applications software.” This section also defines how we use the term “Functional Categories,” as well as some other terms of interest for describing the invention.  
         [0027]     The second section is broken into parts. There are four parts, each describing a functional category and in each there are specific exemplary routines described that implement this functional category. Particular preferred embodiments may use just one of these types or even only one of the ones of these one types, although it will likely be found that combinations of functions needed to produce smoothly functioning efficient query response systems will have many of these and perhaps other yet to be defined ones of some or all of these types.  
         [0028]     Part 1 —Description of KStore System for Use with This Invention  
         [0029]     It should be understood that there are other possible system configurations for use of this invention, however, in preferred embodiments it can be used with the system described herein.  
         [0030]     Refer first to  FIG. 1  which illustrates a KStore system having a KStore  14   a  in a preferred embodiment environment in which a K Engine  11   a  provides the only connection of the K  14   a  to the rest of the world. It should also be noted that there can be more than one K Engine, similar to the one K Engine  11   a  in the illustration, providing access to the KStore  14   a . In tum, the K Engine  11   a  can be addressable by entities such as API Utilities  5  and Learn Engines  6  which manage and handle threads in cooperation with the resources of a computer system (not shown) in which they operate. In the preferred embodiments of the invention learn functions for permitting learning by the K  14   a  can be performed in the learn engine  6 , in a learn utility or other areas of the KStore system. The API Utilities  5  and Learn Engines  6  can be within the API  4 , which can be disposed between the K  14   a  and the application space for transmitting information between the API Utilities  5  and the Learn Engines  6 . The application space can include any applications such as data sources  8  or query application  7 . Typically, the computer system will be a server although a single personal computer can be used in some implementations of K.  
         [0031]     The outside world, in our preferred arrangements has access to the K structure only through these API Utilities and Learn Engines. The API Utilities and Learn Engines therefore can validate whether a person using an application should have access to the K  14   a  or to a specific portion of the K  14   a  in order to prevent unauthorized querying, updating, or management of the K  14   a . Additionally, the API Utilities can validate data sources  8 .  
         [0032]     The API Utilities and Learn Engines are accessed by the outside world through an applications layer. In order to maintain the integrity of the information in the K 14   a , the API  4  does not pass any internal K information to the application layer that would permit the applications to traverse or alter the K 14   a . For example, no pointers or node locations are passed to the applications layer. In addition, no information about the structure of the nodes or how the connecting structures are organized are passed to the applications layer. Note that the U.S. patent application Ser. No. 10/879,329 describes how the API Utilities and the Learn Engine operate and are accessed, while this patent covers the APIs in more detail.  
         [0033]     Applications such as GUls, databases, and any other type of program or interface which could provide data or request information can be hosted in this applications layer.  FIG. 1  illustrates this structure but is drawn to avoid the explicit delineation of threads and layers, to indicate to the reader that the hosting environment is inherently flexible in its nature.  
         [0034]     Specifically, in  FIG. 2  we have illustrated a KStore K  14 , as a cloud, situate in a computer memory system (not shown). This K  14  is accessible by a K Engine  11 . There could be multiple K Engines. An applications layer  15  may contain various forms of GUI (Graphic User Interface) interfaces  15   c  for users to send and receive data such as queries and replies. This layer  15  may also contain data sources  15   a , or programs (which can be in or associated with the data sources) of cloud  15   a , which can provide data to build KStore K  14 . Also this layer  15  can contain application programs  15   b  which applications programs may make queries or provide data to be transmitted to K. Additionally, it should be noted that maintenance and administrative functions can also be performed, for example, through applications or GUI&#39;s. The components of a layer  15  can be spread across the internet, with parts of GUIs and applications hosted among various computer systems and networks if desired, or it can all be local to the same computer system server which hosts K and the K Engine, as well as the API Utilities.  
         [0035]     Any time data is provided to K or any time a search is done of K, we often say we are calling or sending a message to the K Engine. It should be noted that some of the features of the API utilities may be encompassed by the K Engine, depending on how the system is built. In its most easy to understand form the K Engine is kept in as simple a condition as possible. For example, the K Engine may pass only particles into a K and return pointer addresses to whence the particle went. It is important to note that K pointer addresses are never passed through APIs to layer  15 . In given implementations, the K Engine can assume some of the functions of the API Utilities if desired and/or efficient.  
         [0036]     In  FIG. 2 , layer  16  can contain at least one instance of API Utilities  21   b . We can simply call an API utility an interface object. This interface object contains (or is) the set of programs (or potentially hardware or some other as yet unidentified medium) that enable calls for information, maintenance, or data input  18 , to obtain information from the K regardless of the form the queries are in. This layer  16  may handle multiple threads, contain multiple instances of the Learn Engine, and multiple instances of the API Utility and is explained in detail in U.S. Pat. No. 10/879,329.  
         [0037]     The utility procedures of the API utility can produce calls to the K Engine or internal utility procedures. Calls themselves, that is, the requests from the API Utility objects can be very simple statements or even instruction words. The quickest way to see this is to illustrate it as an instruction word or message  34  of  FIG. 3 . We use the concept of the instruction word for purposes of a teahing illustration. As such, the instruction word could have an instruction type (Call)  35 , but in most embodiments this is not needed because the K Engine can return a current location pointer regardless of the purpose of the call.  
         [0038]     Thus, the basic components of a functioning system for supporting uses of a KStore are described, and from these, numerous things can be accomplished.  
         [0039]     API  
         [0040]     Refer first to  FIG. 4  in which the generalized process  350  for handling queries is illustrated as a flow chart. The application  351  (or a GUI being accessed by a user) provides a query Q formulated to seek a result. This query Q could be in SQL format or any other format that can be parsed, such as for example natural language. An example might be “Was anything sold by Bill in PA?” The query assumes that the requested information exists in the K that is loaded at this moment.  
         [0041]     If the query Q is not understood or otherwise erroneous, a feedback mechanism may be provided to ask the application or the user to reformulate the query.  
         [0042]     Thus, the next step in this preferred embodiment is to have the applications layer interpret  352  of  FIG. 4 , and provide feedback or error message if required. The error processing can indude, for example, locating invalid characters, such as letters in a field to be added. Once the query is established, the components of the query need to be established. For the question just asked, “Was anything sold by Bill in PA?” we need to find all the records in the K that have Bill in them, and focus on ones that have sold in them as well as having PA in them. If there are any such records, a positive reply is in order; otherwise, a negative reply is in order.  
         [0043]     This comprises the breaking down of the query into component positioning and retrieval calls  353 . At the base level the query is broken down into calls to  356  the K Store Engine, which finds its way into the K via the current location pointers. This information is returned to the API utility, which organizes the information and makes additional queries until the query Q is satisfied. The API Utility may go directly to addresses in the computer system memory to retrieve information consisting of other addresses or root node data in process  355 . The API Utility applies the result to a table structure  357  that it creates  354  to handle the information retrieved. When the response is completed, it is formatted  358  to send as a reply which can be in the query language used. However, until it is complete, the API Utility can continue to make calls to the K Store Engine. When the query is completed, the formatted, response can be sent  359  back to the application  351 .  
         [0044]     In some preferred embodiments, we have two types of API Utility components to the KStore system. One, an administrative API Utility component, is for maintenance, initiation, and change function support, which enables the user or a program to modify the various system components such as, by setting switches, state variables, designating data sources, modifying metadata or doing other things of an administrative nature. The other API Utility type, of interest here, is used for queries.  
         [0045]      FIG. 5  illustrates the access to the API Utility object for handling queries, updates and the like. Again, nearly every item  361   a  in the applications layer may be configured by a system designer at will, so long as they communicate through a set of hooks or addresses provided by an API, here API  372   a . The user or application will use such components in the applications layer to process a query through a GUI or other interface as shown in  361   a . An Interpreter, also in  361   a , can advantageously be provided to interpret the queries and may send feedback (not shown) if required to understand or comprehend the query. A parser within  361   a  can be used to determine the nature of the query relative to the algorithms this instance of API Utility has for handling queries. It will select which one(s) of API Utilities it will use.  
         [0046]     The query can be broken down into its component parts, perhaps by a query part formulator. These query parts can call the relevant API Utility component routines in  372   a , which can call the K Engine  368   a  via the send/receive subcomponent  367   a  to locate a position in the K structure, access the K structure directly or update appropriate memory within the API Utility space. The K Engine can look to its own associated memory  376   a  to determine if what is sent is on the sensor list, how to respond to it, and the like.  
         [0047]     Other routines can operate to coordinate memory in area  366  of the API Utility  372   a  and to stand ready to analyze location information returned responsive to each query part. These other routines are designated subcomponent memory coordinator/analyst  366 , and operate to store and retrieve associated data in a memory for handling a query thread in thread memory  369 . The API Utility  372   a  may keep records of previous positional information generated by earlier calls (i.e., current location counters returned by the K Engine in  368   a  in response to calls), it can go back with a new call using previous positional information to process current calls it needs to make to find higher levels of information such as the count of a subject variable within a context. The memory coordinator/analyst  366  can also coordinate information previously retrieved from the previous calls that it may have stored in its thread memory  369  and may produce the final result needed by the Response Configurator  377  to generate the answer to the query.  
         [0048]     Part 2—Functional Groups  
         [0049]     The API set of the present embodiment of the invention can be divided into at least four functional categories of APIs:  
         [0050]     1. Support Functions  
         [0051]     2. Analytic Calculation Functions  
         [0052]     3. Monitoring Functions  
         [0053]     4. Administration Functions  
         [0054]     The following is an example of API procedures within each functional category that can be used to access a KStore interlocking trees data store. Following this list is an explanation of representative API procedures.  
         [0055]     Functional Category 1—Support Functions  
         [0056]     The following procedures are ways to access a KStore such as the KStores  14 ,  14   a.    
         [0057]     Maintaining the client interface 
        Connect     QuerylnterfaceByName        
 
         [0060]     Retrieving values and information from the K 
        Columns     Fields     Variables     GetFieldsWithCount 13  XML     GetFieldsXML     GetCollectionWeight     GetCount     GetLongCount     GetDistinctCountList     GetDistinctCountListXML        
 
         [0071]     Setting Constraints 
        AddANDGroup     AddNOTGroup     AddORGroup     AddConstraint     UpdateConstraint        
 
         [0077]     Setting a Focus 
        Focus     UpdateFocus     FocusColumn     UpdateDistinctCount        
 
         [0082]     Returning Data Format 
        K Data Structures 
            FieldName     FieldValue     Result     IsAlphanumeric     Type     Text     Compare     IsMask     Init     IKData:Initialize    
            K Collection Structure 
            Item     NewEnum     Count     Init     Add     Remove     Clear    
               
 
         [0102]     Functional Group 2—Analytic Calculation Functions  
         [0103]     The following procedures are different ways to retrieve analytics from the KStore interlocking trees data store.  
         [0104]     DecisionTree  
         [0105]     DecisionTree_XML  
         [0106]     Rules  
         [0107]     Rules_XML  
         [0108]     PredictSingleVariable  
         [0109]     PredictSingleVariable_XML  
         [0110]     Classify  
         [0111]     Classify_XML  
         [0112]     BayesClassify  
         [0113]     BayesClassify_XML  
         [0114]     RecordExplorer — 3  
         [0115]     RecordExplorer_XML  
         [0116]     RecordExplorer_XML — 2  
         [0117]     RecordExplorer_XML — 3  
         [0118]     ResultListCount  
         [0119]     ResultListCount 2  
         [0120]     SumColumnLong  
         [0121]     SumColumn_XML  
         [0122]     QuestionK  
         [0123]     QuestionK_XML  
         [0124]     DistinctRecordCount  
         [0125]     RecordCount  
         [0126]     KCmd_XML  
         [0127]     Functional Group 3—Monitoring Functions  
         [0128]     The following procedures are ways to monitor the KStore data store.  
         [0129]     Event  
         [0130]     GetEvent  
         [0131]     SaveEvent  
         [0132]     DeleteEvent  
         [0133]     ListEvents  
         [0134]     StartEvent  
         [0135]     StopEvent  
         [0136]     SuspendEvent  
         [0137]     ResumeEvent  
         [0138]     Initialize  
         [0139]     Stop  
         [0140]     Status  
         [0141]     Register  
         [0142]     Unregister  
         [0143]     IsRegistered  
         [0144]     Trigger  
         [0145]     XML  
         [0146]     GetAdviseCookie  
         [0147]     GetMemory  
         [0148]     SetMemory  
         [0149]     RunQuery  
         [0150]     QueryStats  
         [0151]     GetQuery  
         [0152]     SaveQuery  
         [0153]     DeleteQuery  
         [0154]     ListQueries  
         [0155]     Broadcast  
         [0156]     Probability  
         [0157]     Functional Group 4—Administration Functions  
         [0158]     The following procedures are listed within functional categories and are different administration functions.  
         [0159]     Miscellaneous APIs for Initializing and managing the structure and determining the specific features for the K. 
        StartEngine     StopEngine     RenameEngine     KeepEngineRunning     Save     Load     Reset     Name     Initialize     QuerylnterfaceByName     setSwitches     Persistence     SaveK     RestoreK     DeleteK        
 
         [0175]     APIs for reading and processing new information to be added to the structure: 
        Learn     Append     Update        
 
         [0179]     Maintaining MetaData 
        AddColumn     AddVariable        
 
         [0182]     To illustrate the present invention, two figures are used to show a method to administer and to use a KStore structure. As the figures are explained, one representative API procedure within each functional group is explained in detail.  
         [0183]     Refer to  FIG. 6 .  FIG. 6  is a flow chart of system administration method  100  showing steps for K in accord with preferred embodiments of the invention. In this figure, a KStore administrator starts the KEngine  101 . The API procedure for this step can be from the Administration Functions functional category and can be called “StartEngine” procedure.  
         [0184]     To illustrate the present invention,  FIG. 7  shows an exemplary flow diagram  110  of a StartEngine method. The StartEngine method initializes a specified instance of a K with a default set of sensors.  
         [0185]     HRESULT StartEngine ( BSTR name);  
         [0186]     Parameters  
         [0187]     Name [in] BSTR specifying the name of the K instance to initialize. Example: “Unisys Marketing Model”.  
         [0188]     Return Values  
                                                   Value   Meaning                           S_OK   The method was successful.           E_FAIL   An unspecified error occurred.                      
 
         [0189]     After the KEngine is started as shown in  FIG. 7 , the user can use certain procedures to set up what K should look like and then initialize the structure  102 . In this example “Initialize” and “setSwitches” and “AddColumn” procedures can be used. Since these procedures are also in Administration Functions functional category, no procedures will be discussed in detail.  
         [0190]     The next step is to setup data sources and initiate learning by the KStore as shown in  103 . To setup data sources the user uses “AddDataSource” procedure. To initiate learning, the user can use the “Learn” procedure. Again, since these procedures are in Administration Functions, no procedures will be discussed in detail.  
         [0191]     Then queries and events used to monitor the K structure are set up  104 . “StartEvent” procedure from Monitoring Functions functional category can be used.  
         [0192]     To illustrate the present invention,  FIG. 8  shows an exemplary flow diagram  120  of the StartEvent method.  
         [0193]     The StartEvent method starts monitoring the specified event.  
         [0194]     HRESULT StartEvent(  
         [0195]     BSTR name  
         [0196]     );  
         [0197]     Parameters  
         [0198]     name [in] Specifies the name of event to start monitoring.  
         [0199]     Return Values  
                                                   Value   Meaning                           S_OK   The method was successful.           S_FALSE   The specified event was not stopped.           E_FAIL   An unspecified error occurred.                      
 
         [0200]     Requirements: A KStore Engine has been started.  
         [0201]     The final step in the administrative process shown in  FIG. 6  is to save the data and stop the engine  105 . Again, since these procedures are in Administration Functions functional category, none will be discussed in detail.  
         [0202]     Refer to  FIG. 9 .  FIG. 9  is a flow chart  130  of how a KStore user interacts with the K in accord with preferred embodiments of the invention. In this figure, a KStore user can connect to the KServer  131 . The API procedure for this step can be from Support Functions functional category and can be called “Connect” procedure.  
         [0203]     To illustrate the present invention,  FIG. 10  shows an exemplary flow diagram  140  of the “Connect” procedure.  
         [0204]     Connect  
         [0205]     The Connect method establishes a communication path with the KStore Engine.  
         [0206]     HRESULT Connect(  
         [0207]     BSTR engineName;  
         [0208]     );  
         [0209]     Parameters  
         [0210]     engineName [in] This is the name of the engine to connect to.  
         [0211]     Return Values  
                                                   Value   Meaning                           S_OK   The method was successful.           E_FAIL   Fails to connect.                      
 
         [0212]     Requirements: The Engine object has been created and started up.  
         [0213]     Next in the client flow shown in  FIG. 9  field information is requested  132  followed by setting constraints  133 , and setting focus  134 . Since theses procedures are in Support Functions functional category, they will not be discussed in detail.  
         [0214]     Next in the client flow shown in  FIG. 9 , the KStore analytics are called  135 . The example API procedure for this step can be from Analytic Calculation Functions functional category and can be called “PredictSingleVariable” procedure.  
         [0215]     To illustrate the present invention,  FIG. 11  shows an exemplary flow diagram  150  of the “PredictSingleVariable procedure.  
         [0216]     PredictSingleVariable  
         [0217]     The PredictSingleVariable method calculates the probability for the specified focus and retrieves the result in a KCollection.  
         [0218]     HRESULT PredictSingleVariable(  
         [0219]     IKCollection **ppVars  
         [0220]     );  
         [0221]     Parameters  
         [0222]     ppVars  
         [0223]     [out, retVal] KCollection used to return results.  
         [0224]     Return Values  
                                                   Value   Meaning                           S_OK   The method was successful.           E_INVALIDARG   Validation of client failed.           E_POINTER   An invalid IKCollection pointer was used.                      
 
         [0225]     Requirements: The focus field is set, and constraints, if any, have been previously processed.  
         [0226]     In this example as shown in  FIG. 9 , the final step is to process the data that has been returned to the user  136 . Since these structures can be from the Support Functions functional category, they will not be discussed in detail.  
         [0227]     While the invention has been described in detail and with reference to specific examples thereof, it will be apparent to one skilled in the art that various changes and modifications can be made therein without departing from the spirit and scope thereof.