(57)【要約】  １セットの機構は、知識ストアおよびそのＫエンジンとの通信を取り扱う。知識ストア（Ｋストア）は、それをサポートするためにインデックスまたはテーブルを必要としないが、その代りに、連動ツリーのノードにおけるポインタの連動ツリーを構築することによって形成される。Ｋエンジンは、パーティクル化イベントを学習するためにＫエンジンと一緒にソフトウェア・オブジェクトを使用するスレッドを使用することによってＫストアにクエリを行なうように構築および使用され、それによってＫストアを構築し、また、これらあるいは他のソフトウェア・オブジェクトは、クエリを行ない、Ｋエンジンの助けを通常借りてＫストアから答えを得るのに使用することができる。或る状況においては、情報は、Ｋストアから直接的に得ることができるが、Ｋエンジンの作動を通じてのみ一般に利用可能である。機構は、Ｋストアを構築および／またはＫストアにクエリを行なうためにユーザおよびアプリケーション・ソフトウェアに通信経路を提供する。これらの処理の両方は、同時に、そして複数の事例において進められることができる。本質的に同時にＫストア上で動作する複数のエンジンが存在することができる。さらに、トリガを提供する機構は、ユーザおよびアプリケーションのイベント、条件および発生を自動報告することを許容する。【特許請求の範囲】
【請求項１】
連動ツリー・データストア・システムにおいて連動ツリー・データストアにアクセスするシステム・コンポーネントであって、前記システム・コンポーネントは、他のシステム・コンポーネントからのコールを受信するセグメントを有し、前記他のシステム・コンポーネントは、学習エンジンあるいはＡＰＩユーティリィティのうちの少なくとも１つを含み、前記コールを受信するセグメントは、前記コールのうちの少なくとも１つに関連するパーティクルのための前記連動ツリー・データストア内の位置を見つけるように構成されているシステム・コンポーネント。
【請求項２】
前記システム・コンポーネントは、Ｋエンジンと呼ばれ、前記連動ツリー・データストアは、Ｋストアである、請求項１記載のシステム・コンポーネント。
【請求項３】
前記システム・コンポーネントは、学習スイッチが学習状態であるときにのみ前記連動ツリー・データストアを構築し、前記構築は、前記システム・コンポーネントによって前記連動ツリー・データストアにおけるイベントとして前記パーティクルを記録することによって達成される、請求項１記載のシステム・コンポーネント。
【請求項４】
前記システム・コンポーネントは、前記コールにおける前記他のシステム・コンポーネントから前記パーティクルに関連することが可能である任意のポインタを受信するように構成され、前記ポインタは、前記連動ツリー・データストア・システムの連動ツリー・データストアにおける現在の位置を示す、請求項１記載のシステム・コンポーネント。
【請求項５】
前記システム・コンポーネントは、前記リストからのセンサを前記パーティクルと比較するためのセンサ・リストを維持する手段を有し、前記リスト上の前記センサの各々は、前記連動ツリー・データストアにおける要素ルートノードに関連する、請求項１記載のシステム・コンポーネント。
【請求項６】
前記パーティクルに関連する前記ポインタは、前記連動ツリー・データストア内の少なくとも最後の位置を識別し、前記システム・コンポーネントは、前記最後の位置が次の副コンポーネント・ノードを通じて前記要素ルートノードの１つに接続されているかを判定する接続判定手段を有しており、そのような場合に、前記接続判定手段は、前記連動ツリー・データストアにおける新しい現在の位置として、前記パーティクルの前記要素ルートノードに接続された前記次の副コンポーネント・ノードの既存の位置を確立する、請求項５記載のシステム。
【請求項７】
前記要素ルートノードのうちの１つへの接続は、前記センサ・リスト上の前記パーティクルに一致するセンサに関連している、請求項６記載のシステム。
【請求項８】
前記接続判定手段は、前記最後の位置から前記パーティクルの前記要素ルートノードへの前記接続が間接的であるかをさらに判定し、前記間接とは、前記パーティクルが前記連動ツリー・データストアにおける前記次の副コンポーネント・ノード以外の副コンポーネント・ノードを通じて接続されていることの判定である、請求項６記載のシステム。
【請求項９】
前記最後の位置が副コンポーネント・ノードを通じて要素ルートノードに接続されていると前記接続判定手段が判定した場合に、前記次の副コンポーネント・ノードの位置は、新しい現在の位置として確立され、前記パーティクルの前記要素ルートノードにおけるカウンタは、前記接続判定手段によってインクリメントされる、請求項６記載のシステム。
【請求項１０】
前記パーティクルに関連する前記ポインタは、前記連動ツリー・データストア内の少な
くとも最後の位置を識別し、前記最後の位置が前記パーティクルの次の副コンポーネント・ノードを通じて要素ルートノードに接続されていないと前記接続判定手段によって判定された場合に、前記システム・コンポーネントは、前記連動ツリー・データストアの前記パーティクルのための新しい副コンポーネント・ノードの形成を生じる、請求項６記載のシステム。
【請求項１１】
パーティクルが思考の終了であると前記接続判定手段が判定した場合に、前記システム・コンポーネントは、前記連動ツリー・データストアにおける最終生成ノードの形成を生じるために最終生成ノード・ルーチンの形成をアクティブにする、請求項８記載のシステム。
【請求項１２】
パーティクルが思考の終了であることの前記判定は、デリミッタを見つけることに依存する、請求項１１記載のシステム。
【請求項１３】
前記デリミッタがより高いレベルのデリミッタである場合に、現在のレベルと前記より高いレベルとの間の各レベルに対して思考の終了ノードを追加する請求項１２記載のシステム。
【請求項１４】
前記デリミッタが前記より高いレベルであり、最も高い既存のレベルである場合に、前記最も高いレベルの上に副コンポーネント・ノードを追加する、請求項１３記載のシステム。
【請求項１５】
前記システム・コンポーネントに前記パーティクルを伝えるメッセージ中のデリミッタは、前記パーティクルが思考の終了であることを前記接続判定手段に識別させることがある、請求項１１記載のシステム。
【請求項１６】
前記センサ・リストは、センサとして少なくとも１つのデリミッタを含む、請求項１２記載のシステム。
【請求項１７】
前記パーティクルが思考の終了であると分かった場合に、前記システム・コンポーネントは、モナド・リストに前記最終生成ノードに関する情報をモナド（ｍｏｎａｄ）として追加する、請求項１１記載のシステム。
【請求項１８】
前記システム・コンポーネントは、メッセージ中のパーティクルを送信する他のシステム・コンポーネントにフィードバックを供給し、前記フィードバックは、前記パーティクルの１つが前記システム・コンポーネントに提出された後で位置ポインタ・データを返すことによって達成され、前記返された位置ポインタ・データは、前記システム・コンポーネントがそれを通じて前記パーティクルへの接続を確立することがある前記副コンポーネント・ノードの位置が前記連動ツリー・データストアにあることを識別する、請求項４記載のシステム・コンポーネント。
【請求項１９】
前記パーティクルは、前記ＡＰＩユーティリィティ・システム・コンポーネントによって、または、前記学習エンジン・システム・コンポーネントから供給されていることが可能である、請求項１５記載のシステム・コンポーネント。
【請求項２０】
前記システム・コンポーネントは、スイッチとして識別可能な記憶状態変数のためのメモリ・セグメントに結合され、前記状態変数は、前記システム・コンポーネントの任意の動作に適用可能であり、前記状態変数は、前記システム・コンポーネントが前記他のシステム・コンポーネントからのコールにどのように応答するかを判定する、請求項４記載のシステム・コンポーネント。
【請求項２１】
前記システム・コンポーネントは、前記システム・コンポーネントの任意の動作に適用可能な状態変数を記憶するメモリ・セグメントを備えており、前記状態変数の設定は、前記システム・コンポーネントが前記他のシステム・コンポーネントからのコールにどのように応答するかを判定する請求項４記載のシステム・コンポーネント。
【請求項２２】
前記メモリ・セグメントに記憶された前記状態変数は、学習（ＹまたはＮ）、列番号（ＹまたはＮ）、列番号の代わりに使用されるメタデータ・フィールド名（ＹまたはＮ）、ＥＯＴレベル（数および名前）、  ＥＯＴＣＯＬ（列名）、ＥＯＴＶＡＲ（変数）、ＥＯＴＦＬＤ（フィールド・エントリ）、ＥＯＴＲＣＤ（レコード）  を含む、スイッチのリストのうちの少なくとも１つのスイッチを含んでいる、請求項１７記載のシステム・コンポーネント。
【請求項２３】
前記メモリ・セグメントに記憶された前記付加的な情報は、トリガ・イベントまたは条件が発生したときに、前記システム・コンポーネントからの通知信号を開始するためのトリガを有効および無効にし、それによって前記システム・コンポーネントに前記通知信号を送信させる少なくとも１つのスイッチ設定を含んでいる、請求項１７記載のシステム・コンポーネント。
【請求項２４】
前記メモリ・セグメントに記憶されたトリガを有効および無効にする前記スイッチは、新しい変数、新しいレコード、欠落変数およびログを埋めるもの、または選択されたフィールドを確認するものを含む前記トリガのリストのうちの少なくとも１つのトリガを含んでいる、請求項１７記載のシステム・コンポーネント。
【請求項２５】
前記システム・コンポーネントのメモリ・センサ・リストは、前記システム・コンポーネントのセンサ・リスト・マネージャによって管理され、前記センサ・リスト・マネージャは、動作する構成を判定するのための状態によって設定された構成で動作し、前記センサ・リスト・マネージャが前記センサ・リスト上にないパーティクルを受信した場合に、前記状態が前記センサ・リスト上にない前記パーティクルを管理するための前記構成を設定するように、前記状態は、少なくとも１つのスイッチによって構成可能である、請求項１７記載のシステム・コンポーネント。
【請求項２６】
前記構成可能なセンサ・リスト・マネージャの状態は、前記センサ・リスト上にないパーティクルを受信することが発生した際に、何も動作をしない状態を含む、請求項２５記載のセンサ・リスト・マネージャ。
【請求項２７】
前記構成可能なセンサ・リスト・マネージャの状態は、前記センサ・リスト上にない前記パーティクルを受信することが発生した際に、エラーが送信される状態を含む、請求項２５記載のセンサ・リスト・マネージャ。
【請求項２８】
前記構成可能なセンサ・リスト・マネージャの状態は、前記センサ・リスト上にない前記パーティクルの発生の際に、新しいセンサが前記センサ・リストに追加される状態を含む、請求項２５記載のセンサ・リスト・マネージャ。
【請求項２９】
前記構成可能なセンサ・リスト・マネージャの状態は、前記センサ・リスト上にない任意の前記パーティクルの前記受信を記録するためにログが維持される状態を含む、請求項２５記載のセンサ・リスト・マネージャ。
【請求項３０】
前記センサ・リスト・マネージャの状態のそれぞれは、前記状態が同時に共存することができるように、個別のスイッチによって設定される、請求項２５記載のセンサ・リスト
・マネージャ。
【請求項３１】
連動ツリー・データストア・システムにおける連動ツリー・データストアにアクセスする方法であって、
前記連動ツリー・データストアへのパーティクルの追加と、前記連動ツリー・データストアからのポインタ・データの取出しとを要求する、Ｋエンジンへのコールを生成すること、
リターン・メッセージへ前記取り出されたポインタ・データを含めた応答を、前記Ｋエンジンにおいて処理すること、
前記リターン・メッセージを返すこと
を含む方法。
【請求項３２】
次のコールを生成するステップをさらに含み、前記次のコールは、新しいパーティクルを有し、前記取り出されたポインタ・データを含む、請求項３１記載の方法。
【請求項３３】
学習スイッチが学習に設定されている場合に、前記連動ツリー・データストアにおけるイベントとして前記パーティクルも記録することをさらに含む、請求項３１記載の方法。
【請求項３４】
前記連動ツリー・データストア・ノードが、カウンタを有し、前記スイッチが、学習に設定され、前記パーティクルが、前に記録されたパーティクル・イベントと等しい場合に、前記取り出されたポインタ・データに関連する要素ルートノードにおけるカウンタをインクリメントすることによって新しいそのようなパーティクルを記録する、請求項３３記載の方法。
【請求項３５】
連動ツリー・データストア・システムにおける連動ツリー・データストアにアクセスする方法であって、
Ｋエンジンへパーティクルを送信するためのメッセージを準備することを含み、該準備においては、前記Ｋエンジンに前記メッセージを介したコールとして送信するために準備される一連の思考における次のパーティクルが枝パーティクル・イベントであるか否かを判定し、枝である場合に、前記メッセージ中の最後の副コンポーネント・ノードに前の現在の位置データを送信する、方法。
【請求項３６】
連動ツリー・データストア・システムにおける連動ツリー・データストアにアクセスするためのシステム・コンポーネントによる使用のための方法であって、前記システム・コンポーネントは、他のシステム・コンポーネントからのコールを受信するセグメントを有しており、前記他のシステム・コンポーネントは、学習エンジンまたはＡＰＩユーティリィティのうちの少なくとも１つを含んでおり、コールを受信する前記セグメントは、前記コールの１つに関連するパーティクルのための前記連動ツリー・データストア内の位置を見つけるように構成されており、前記システム・コンポーネントは、学習スイッチが学習状態にある条件のときにだけ前記連動ツリー・データストアを構築し、前記方法によって達成される前記構築は、
前記システム・コンポーネントが前記連動ツリー・データストアにおけるイベントとして前記パーティクルを記録することを含む、方法。
【請求項３７】
イベントとして新しいパーティクルを記録するのに先立って、前記システム・コンポーネントは、前記コールにおける前記他のシステム・コンポーネントのうちの１つから前記パーティクルを受信すると同時に受信し、任意のポインタは、前記新しいパーティクルに関連することがある現在の位置を示す、請求項３６記載の方法。
【請求項３８】
前記現在のポインタは、ｎｕｌｌポインタ、前記システム・コンポーネントが前記パー
ティクルと共に返したであろう最後に受信した現在の位置ポインタ、または、前に返された位置ポインタが前記新しいパーティクルに関する前記他のシステム・コンポーネントに関与する場合には、前記前に返された現在の位置ポインタを含む一組のポインタから取り出される、請求項３７記載の方法。
【請求項３９】
前記リストからのセンサを前記パーティクルと比較するためのセンサ・リストを維持することをさらに含み、（前記リスト上の前記センサの各々は、前記連動ツリー・データストアにおける要素ルートノードに関連し）、さらに前記方法は、前記パーティクルが前記センサ・リスト上の前記センサのうちのいずれかと一致するか否かを判定するために、前記パーティクルのそれぞれを前記センサ・リスト上のセンサと比較することを含む、請求項３６記載の方法。
【請求項４０】
前記連動ツリー・データストア内の少なくとも最後の位置を識別するために前記パーティクルに関連する前記ポインタを使用すること、
前記最後の位置が次の副コンポーネント・ノードを介して要素ルートノードに接続されているか否かを判定すること、その後、
新しい現在の位置として前記連動ツリー・データストアにおける副コンポーネント・ノードの既存の位置を確立すること、
をさらに含む、請求項３８記載の方法。
【請求項４１】
前記最後の位置から前記パーティクルの前記ルートノードへの前記接続が間接であるか否かを判定することをさらに含み、前記間接とは、前記パーティクルが前記連動ツリー・データストアにおける次の副コンポーネント・ノード以外の副コンポーネント・ノードを通じて接続されることを判定することである、請求項３９記載の方法。
【請求項４２】
前記最後の位置が前記次の副コンポーネント・ノードを通じて前記パーティクルの要素ルートノードに接続されたと前記判定するステップが判定した場合に、新しい現在の位置として前記次の副コンポーネント・ノードの位置を確立し、前記パーティクルの前記ルートノードにおけるカウンタをインクリメントする、請求項３９記載の方法。
【請求項４３】
前記パーティクルに関連する前記ポインタが前記連動ツリー・データストア内の少なくとも最後の位置を識別し、前記最後の位置が前記パーティクルの要素ルートノードに接続されていないと判定された場合に、前記連動ツリー・データストアにおける前記パーティクルのための新しい副コンポーネント・ノードの形成をもたらすことをさらに含む、請求項３６記載の方法。
【請求項４４】
パーティクルが思考の終了であるか否かを判定することをさらに含み、前記パーティクルが思考の終了であると分かった場合に、前記連動ツリー・データストアにおける最終生成ノードを形成することをさらに含む、請求項３９記載の方法。
【請求項４５】
前記パーティクルが思考の終了であると分かった場合に、モナド（ｍｏｎａｄ）として前記最終生成ノードに関する情報をモナド・リストに追加する、請求項４４記載の方法。
【請求項４６】
前記パーティクルが前記センサ・リスト上にないと分かった場合に、センサとして前記最終生成ノードに関する情報を前記センサ・リストに追加する、請求項３９記載の方法。
【請求項４７】
パーティクルが前記センサ・リスト上にないことを判定した後のステップは、
前記システム・コンポーネントの状態に応じて前記センサ・リスト上にないパーティクルに関する適切な動作を行なうこと、
を含む、請求項４３記載の方法。
【請求項４８】
前記適切な動作は、
前記センサ・リスト上にない前記パーティクルの発信元にエラー・メッセージを送信すること、
パーティクルが前記センサ・リスト上にないという判定を記録すること、
パーティクルが前記センサ・リスト上にないという前記判定に対して何も動作を行なわないこと、
新しいセンサとして前記センサ・リスト上にないと判定された前記パーティクルを確立すること、および／または、
別のシステム・コンポーネントにメッセージを送信するか、または、パーティクルが前記センサ・リスト上にないと分かったことを示す前記システムの外部にメッセージに送信するために、トリガに応答の信号を送ること、
のうちの一または複数のステップを含んでいる、請求項４７記載の方法。
【請求項４９】
前記適切な動作を行なうことに先立って、前記一または複数のステップのうちのどれが行なわれるかを判定するであろう前記状態を判定するために、前記システム・コンポーネントに関連するスイッチ設定をチェックする、請求項４８記載の方法。
【請求項５０】
連動ツリー・データストア・システムにおいて使用する学習エンジン・システム・コンポーネントであって、前記学習エンジンは、データ・ソースからデータを受信し、前記データを各データの単一のパーティクルを含んでいる一連のコールに変換し、前記連動ツリー・データ記憶構造へのインタフェースを提供するＫエンジン・コンポーネントに前記コールを送信し、前記学習エンジンは、
前記データ・ソースからのデータ・ストリームから直接的または間接的に受信したデータをパーティクル化するパーティクル化副コンポーネントと、
前記パーティクル化コンポーネントから受信したパーティクルを含むコールを構築および送信する送信副コンポーネントと、
を備える学習エンジン・システム・コンポーネント。
【請求項５１】
前記パーティクル化副コンポーネントおよび前記送信副コンポーネントは、アプリケーション層から前記学習エンジンへのコールによって確立されたスレッドに応答し、前記コールは、前記入力データのソースに関する情報をその中に有している、請求項５０記載の学習エンジン・システム・コンポーネント。
【請求項５２】
前記学習エンジンは、前記データ・ソースからのデータ・ストリーム出力と一致する通信プロトコルを確立するための通信副コンポーネントを確立するプロトコルをさらに備える、請求項５０記載の学習エンジン・システム・コンポーネント。
【請求項５３】
前記学習エンジン・システム・コンポーネントは、コンピュータ・システムにロードされるときに、前記学習エンジン・システム・コンポーネントとして動作するように前記コンピュータ・システムを構成する１セットのソフトウェア信号および符号化された指示から構築される、請求項５０記載の学習エンジン・システム・コンポーネント。
【請求項５４】
１つのフォーマットでデータ・ソースからデータを受信し、前記受信データが前記連動ツリー・データ記憶構造のために望ましい所定のフォーマットであることを保証するのに必要な任意のステップを行なうフォーマット・ルール化副コンポーネントをさらに備える、請求項５０記載の学習エンジン。
【請求項５５】
データ・ソースから出力されたデータを受信し、前記パーティクル化副コンポーネントにメタデータ・ルール化コンポーネントによって送信される前に、前記受信データ中の任
意のメタデータが前記連動ツリー・データ記憶構造のために望ましい所定のフォーマットを有していることを保証するのに必要な任意のステップを行なうメタデータ・ルール化コンポーネントをさらに備える、請求項５０記載の学習エンジン。
【請求項５６】
前記学習エンジンは、動的リアルタイム・センサ・データ、静的データベース・データ、動的リアルタイムトランザクション・データベース・データ、シミュレータ占有データベース・データ、動的に生成されたシミュレータ生成データを含むデータ・ソースの種類のリストのうち１種類のデータ・ソースのデータ・ソースからデータを受信するように構成および配置される、請求項５０記載の学習エンジン。
【請求項５７】
前記学習エンジンに条件をチェックさせるトリガ手段をさらに備える、請求項５０記載の学習エンジン。
【請求項５８】
前記学習エンジンは、前記トリガに応答するメッセージを送信する信号生成副コンポーネントを備え、前記条件がデータに残存する場合に、それは前記連動ツリー・データストアにおけるレコードの提出を受信する、請求項５７記載の学習エンジン。
【請求項５９】
前記トリガの前記条件は、タイマまたはカウンタのいずれかが所定値に達するのに依存して、周期的に満足される、請求項５７記載の学習エンジン。
【請求項６０】
前記トリガの条件が満足されていることを示すデータのために前記学習エンジンに関連する記憶領域を前記学習エンジンにチェックさせるトリガ手段をさらに備え、前記学習エンジンによって満たされる前記クエリは、連動ツリー・データストア内の条件をチェックする、請求項５０記載の学習エンジン。
【請求項６１】
入力データ・ストリームがフィールド／レコード全体からのデータであるときに、連動ツリー・データストア・システムにおける連動ツリー・データストアに送信する準備をする際に、入力データ・ストリームをパーティクル化する方法であって、
前記入力データ・ストリームからの外部のフォーマットをストリップすること、
前記パーティクルが学習エンジンによって送信されるであろうＫエンジンの所定のフィールド名メタデータに応じるためにフィールド名を追加および／または変換すること、
所定のセンサ情報に応じるために前記ストリップおよび追加および／または変換ステップの後で、前記データ・サイズが前記所定のセンサ情報に一致するように、前記入力データ・ストリームのデータのサイズを低減すること、
を含む方法。
【請求項６２】
コンピュータによってアクセスされるときに請求項６１記載のステップを前記コンピュータに行なわせるように構成されたメモリ内にエンコードされた１セットのソフトウェア信号。
【請求項６３】
連動ツリー・データストア・システムにおいて使用されるＡＰＩユーティリィティ・システム・コンポーネントであって、
前記連動ツリー・データストアから情報を得る複数のエントリ・ポイント・ルーチンを備え、前記複数のエントリ・ポイントは、アプリケーション層からのクエリ部分形成手段によってコール可能であるＡＰＩユーティリィティ・システム・コンポーネント。
【請求項６４】
前記コールの取り扱いを調整するためにスレッド記憶領域を使用および取り扱い、前記通信に対する応答の形成および構成を調整するコーディネータ／アナリスト手段と、
応答コンフィギュレータ手段と、
をさらに備える、請求項６３記載のＡＰＩユーティリィティ・システム・コンポーネン
ト。
【請求項６５】
前記応答コンフィギュレータ手段は、前記ソースに返す前記通信に対する応答を形成および構成および送信するために前記コーディネータ／アナリスト手段を使用するものである、請求項６４記載のＡＰＩユーティリィティ・システム・コンポーネント。
【請求項６６】
コンピュータによってアクセスされるときに、請求項６０記載の要素を提供するように前記コンピュータを構成するメモリ内にエンコードされた１セットのソフトウェア信号。
【請求項６７】
前記ソースからの前記通信は、状態変数を設定するコマンドである、請求項６３記載のＡＰＩユーティリィティ・システム・コンポーネント。
【請求項６８】
前記ソースからの前記通信は、他のシステム・コンポーネントおよび／またはアプリケーションのインスタンスを確立するためのコマンドである、請求項６３記載のＡＰＩユーティリィティ・システム・コンポーネント。
【請求項６９】
前記ソースからの前記通信は、トリガを設定するためのコマンドであり、前記状態変数は、トリガの挙動を構成する、請求項６３記載のＡＰＩユーティリィティ・システム・コンポーネント。
【請求項７０】
前記トリガは、内部または外部のトリガのいずれかである、請求項６９記載のＡＰＩユーティリィティ・システム・コンポーネント。
【請求項７１】
コンピュータによってアクセスされるときに、請求項６３記載の要素を提供するように前記コンピュータを構成するメモリ内にエンコードされた１セットのソフトウェア信号。
【請求項７２】
連動ツリー・データストアにアクセスすることを含む、請求項７１記載のＡＰＩユーティリィティを操作する方法。
【請求項７３】
Ｋエンジンにアクセスすることを含む、請求項７１記載のＡＰＩユーティリィティを操作する方法。
【請求項７４】
前記コンポーネントの状態を設定するように前記連動ツリー・データストア・システム内の連動ツリー・データストア・システムの別のコンポーネントに関連するメモリを修正することを含む、請求項７１記載のＡＰＩユーティリィティを操作する方法。
【請求項７５】
前記連動ツリー・データストア・システムにおいて使用されるシステム・コンポーネントおよび／またはアプリケーションを確立することを含む、請求項７１記載のＡＰＩユーティリィティを操作する方法。
【請求項７６】
コンピュータ・システムにおいてスレッドを取り扱うシステム・コンポーネントの調整された１セットのインスタンスを含む連動ツリー・データストア・システムであって、前記システム・コンポーネントのインスタンスは、少なくとも：
Ｋエンジン・システム・コンポーネントのインスタンスと、
学習エンジン・システム・コンポーネントのインスタンスと、
連動ツリー・データストア・システム・コンポーネントのインスタンスと、
を含む連動ツリー・データストア・システム。
【請求項７７】
ＡＰＩユーティリィティ・システム・コンポーネントのインスタンスをさらに含む、請求項７６記載の連動ツリー・データストア・システム。
【請求項７８】
前記ＡＰＩユーティリィティ・システム・コンポーネントのインスタンスは、管理ＡＰＩユーティリィティ・システム・コンポーネントである、請求項７７記載の連動ツリー・データストア・システム。
【請求項７９】
それぞれの前記システム・コンポーネントの各インスタンスは、関連するメモリを有している、請求項７６記載の連動ツリー・データストア・システム。
【請求項８０】
前記システム・コンポーネントの前記インスタンスのすべては、単一のコンピュータ・システム内に存在し、前記学習エンジンおよび前記ＡＰＩユーティリィティの前記インスタンスへの通信は、前記単一のコンピュータ・システムとの通信を通じて容易化される、請求項７７記載の連動ツリー・データストア・システム。
【請求項８１】
前記容易にされた通信は、ＧＵＩを通じた直接ユーザ通信に対して有効にされる、請求項８０記載の連動ツリー・データストア・システム。
【請求項８２】
前記容易化された通信は、インタフェースを通じたアプリケーション通信に対して有効にされる、請求項８０記載の連動ツリー・データストア・システム。
【請求項８３】
コンピュータ・システムにおけるスレッドを取り扱うシステム・コンポーネントの調整された１セットのインスタンスを含む連動ツリー・データストア・システムであって、前記システム・コンポーネントのインスタンスは、少なくとも：
Ｋエンジン・システム・コンポーネントのインスタンスと、
ＡＰＩユーティリィティ・システム・コンポーネントのインスタンスと、
連動ツリー・データストア・システム・コンポーネントのインスタンスと、
を含む連動ツリー・データストア・システム。
【請求項８４】
学習エンジン・システム・コンポーネントのインスタンスをさらに含む、請求項８３記載の連動ツリー・データストア・システム。
【請求項８５】
前記ＡＰＩユーティリィティ・システム・コンポーネントのインスタンスは、管理ＡＰＩユーティリィティ・システム・コンポーネントである、請求項８３記載の連動ツリー・データストア・システム。
【請求項８６】
それぞれの前記システム・コンポーネントの各インスタンスは、関連するメモリを有している、請求項８３記載の連動ツリー・データストア・システム。
【請求項８７】
前記システム・コンポーネントの前記インスタンスのすべては、単一のコンピュータ・システム内に存在し、前記ＡＰＩユーティリィティの前記インスタンスへの通信は、前記単一のコンピュータ・システムとの通信を通じて容易化される、請求項８３記載の連動ツリー・データストア・システム。
【請求項８８】
前記容易化された通信は、ＧＵＩを通じた直接ユーザ通信に対して有効にされる、請求項８７記載の連動ツリー・データストア・システム。
【請求項８９】
前記容易化された通信は、インタフェースを通じたアプリケーション通信に対して有効にされる、請求項８７記載の連動ツリー・データストア・システム。
【発明の詳細な説明】
【背景技術】
【０００１】
背景
構築あるいは使用するためにインデックスを付けることやテーブルを必要としない我々の連動ツリー・データストアのための基本モデルの機能が我々の先の特許出願において記述されている一方で、それに追加することができる価値のある付加的な構造および処理が存在する。我々は、多くの場合、我々の連動ツリー・データストアをＫストア（あるいは、我々はいくつかの記述ではそれをＫストア構造とも称するが、場合によっては単にＫ）と称する。米国における出願で既にＫストアを記述している先の特許出願、出願番号第１０／３８５，４２１号、第１０／６６６，３８２号、および第１０／７５９，４６６号によって特定可能であり、そのすべてを我々はこの参照によってそれらのそれぞれの全体を援用する。我々は、Ｋストア構造の市場性をより高め、Ｋストア構造をより使い易くするために、いくつかの革新が重要になってきたことを見つけた。我々は、アプリケーション・ソフトウェアおよびユーザと共に前記構造の相互操作を容易にするために、また、一般に使用することを容易にするためにこれらについて記述する。そうする際に、Ｋストア、あるいは複数のＫストアは、ほぼ任意の所望の使用のためのデータの取り扱いに容易なシステムへ統合されるようになる。
【０００２】
共通のソフトウェア・インタフェースを使用するＫストア構造にデータを引き込み、また、Ｋストア構造から知識を取り出すことが可能であることは、この構造を必需品としてより価値があり、且つ、大衆にとってより有用なものにするであろう。なぜならば、それらを彼らが既に有しているか、あるいは使用しているツールでそれにアクセスできるようにさせるであろう。前記構造内のデータに対するＫストア構造の使用を容易にするために必要とされるコンポーネントのデモンストレーションと共に、Ｋストアとのその相互作用のためにそれらのコンポーネントをほぼ任意の種類のアプリケーションに適用する方法が当業者にとっては明白になるであろう。
【０００３】
今まで、Ｋストアは、専用設計のソフトウェアを備えたそのエンジンによってアクセスされた。全く新規であるため、それは、そのようなソフトウェアを構築する能力を備えるものにとって有用であった。したがって、任意のアプリケーションについて、アクセスには再設計とさらに専用設計を必要とした。絶えず再使用されるＫエンジンのそれらの処理のための専用設計を回避する方法は、Ｋストアをより商業的な実現性を見出す必要があった。それを見出せれば、この専用設計および再構築は、すべてのアプリケーションではないにしても、Ｋストアを構築すること、もしくはそれへのクエリアクセスを提供することが必要であった、ほぼすべてのアプリケーションについて回避することができるであろう。同様に、これは、それからクエリ応答を得るために単に必要とするそれらのアプリケーションにとって、Ｋストアの使用を容易にすることができるであろう。我々は、１セットの中間ソフトウェアの存在およびこれを達成する単純な方法のステップを提供することを選択した。これらの中間プロセスあるいはオブジェクトは、Ｋストアへのアクセスを必要とするアプリケーションの複数且つ異種の入力データ・ソース、ならびにクエリの種類およびフォーマットを含む、多様性および複雑さに関連する問題を扱う必要がある。
【０００４】
たとえば、データ・ソースがＯＲＡＣＬＥデータベース構造を使用し、コネクションを処理するために単に直接中継して構築される任意の方法でＫストアに直接結合されている場合に、あるいは、データがインターネットにを介してトランザクションＲＤＢＭＳシステムを通じて提供され、ＨＴＭＬまたはＸＭＬで覆われる場合に、あるいは、データがリアルタイム・センサ・アレイから提供される場合に、あるいは、データが取るどのような
フォーマットであっても、Ｋストアの根本的な構造は、そのような入力形式に適応するために変える必要はない。
【０００５】
したがって、我々は、一般的な使用を獲得し、多くが任意の目的でＫストアの固有の価値を利用することを可能にする中間物がＫストアを商業的な実現性のためには必須であろうと思う。
【０００６】
したがって、我々は、Ｋストア・アプリケーション・エンジンあるいはＫストア構造を理解する必要なしに、プログラミング技術の当業者がＫストアへアクセスすることができる処理を創作した。我々は、そのようなプログラマが任意の目的でＫストアを構築および／またはＫストアにアクセスすることができるであろうシステムを創り出した。
【０００７】
さらに、我々は、単にＫストアにアクセスするクエリ、および学習を可能にし、それによってＫストアの構造を追加するクエリとの間の状態を切り替えることを可能にする必要がある。Ｋストアとそのユーザとの間のインタフェースに知能を入れるために多くの他の革新がここに記述され、クレーム化されている。
【発明の開示】
【課題を解決するための手段】
【０００８】
発明の要旨
Ｋエンジンで作業することを容易にするために、我々は、どのような種類のアプリケーションおよびインタフェースであっても、Ｋストアのアドレス指定、構築および使用が可能となるように、学習のためのサービスおよびクエリ・スレッドを提供するオブジェクト（あるいはシステム・コンポーネント）の新しいセットを創作した。我々が称するオブジェクトは、ａ）学習エンジン、および、ｂ）ＡＰＩ（アプリケーション・プログラミング・インタフェース）ユーティリィティ・エンジンである。学習エンジン・オブジェクトは、様々なソースから様々な形態でデータを受け取り、あるいは取得し、また、それをＫエンジンが使用することができるパーティクルに変える能力を提供する。ＡＰＩユーティリィティ・オブジェクトは、どのような種類のアプリケーション・ソフトによって受信した問合せであっても適切な処理を提供する。それらの両方は、Ｋから情報を取得し、および／または、Ｋへ情報を入れるスレッドを有効にするのと非常に似た方法で作用する。コンピュータ技術における当業者には、オブジェクトの属性を有効にするような方法で実行するコンピュータ・システムを構成するソフトウェアにオブジェクトを構築することができることが理解されるであろう。それらの機能のスピードを上げるようにソフトウェアと同様にハードウェアにもオブジェクトを生成することができることが理解されるであろう。
【０００９】
実行コンテクストあるいは軽量処理と場合によっては呼ばれるスレッドは、プログラム内の制御の単一の連続するフローである。各スレッドは、一般に、同一プログラム内の制御の連続するフローである。これについての背景に対して、スレッドおよびそれらの履歴に関する議論についてはｈｔｔｐ：／／ｗｗｗ．ｓｅｒｐｅｎｔｉｎｅ．ｅｏｍ／〜ｂｏｓ／ｏｓ−ｆａｑ／ＦＡＱ−１．ｈｔｍｌ＃Ｔｈｒｅａｄｓを参照のこと。スレッドは、軽量処理として定義される。それらは、ＣＰＵスケジューリングおよび処理内の連続する実行フローの基本単位と見なすことができる。処理の共通の定義は、それらがコード、データ、スタック、ファイルＩ／Ｏおよび信号テーブルの５つの基本部分を有しているということである。これは、切り替えるときに、かなりの量のオーバーヘッドを生じる。スレッドは、基本部分を共有することによってオーバーヘッドを低減する。共有することによって、実行を１つのスレッドから別のスレッドに切り替えることは、非常に頻繁に且つ効率的に発生する場合がある。
【００１０】
スレッドは、任意のオペレーティング・システムの不可欠な部分である。しかしながら
、産業会のリーダーの３社はすべて、スレッドを実行する方法について異なる概念を有している。このアプリケーションでは、我々は、学習機能あるいはクエリのいずれかをその開始から終了まで取り扱うソフトウェア処理を示すために「スレッド」という用語を使用する。
【００１１】
上記の援用された特許引用文献により詳細に見出すことができるが、参照の便宜のために、我々は、ここではＫストア・データ・モデル構造の概略について記述する。連動ツリー・データストアは、それ自身一般に、第１のルートノードに依存し、複数の枝を含むことが可能である第１のツリーを含んでいる。第１のツリーの枝のそれぞれは、ここでは我々が最終生成ノードと称する葉ノードにおいて終わる。同じツリーベースのデータストアの第２の根は、最終生成物を表わす各葉ノードに接続される。最後に、ツリーベースのデータストアは、それぞれのルートノードが要素ノードとして記述することができる複数のツリーを含んでいる。これらのツリーのそれぞれのルートノードは、第１のツリーの一または複数の枝における一または複数のノードに接続されることが可能である。ツリーベースのデータストアのノードは、好ましくは、データそれ自体ではなくツリーベースのデータストアにおける他のノードへのポインタだけを含んでおり、１つのそのような付加的なフィールドがカウント・フィールドであることが可能である付加的フィールドも含んでいる。さらに、一または複数の定義されたフォーカス（ｆｏｃｕｓ）内の所望のコンテクストによって識別されるような特定のノードに関連する変数の一致の確率を得る手段は公知である。さらに、そのような変数に関するクエリへの論理演算子のアプリケーションは、参照するドキュメントに記述されるように達成することができる。
【００１２】
まさに記述された連動ツリー構造は、Ｋデータ構造を初期化および構築するＫエンジンを使用して構築される。構築されたときのＫストアは、データ・セットのモデルである。データ・セットは、静的あるいは動的なデータの任意の入力ストリームであることができるであろう。ここに記述されたような、それにクエリを行ない構築するためのオブジェクトを備えたＫエンジンを使用することによって、ほぼどのようなアプリケーションも連動ツリー・データストアおよび構造にアクセスし、構築および使用することができると思われる。
【００１３】
Ｋストアを構築するためのルールは、単純である。データの各パーティクルについて、現在のロケーションポインタ（つまり、位置ポインタ）から連続して続くこのパーティクルのイベントが既に構造内のノードであるか否かを見るためにチェックし、もしそうであるならば、そのノードおよびその結果ノードにおけるカウンタを加算することによってイベントの強さを増大し、そして、現在の位置ポインタを新しい位置にリセットする。そうでなければ、イベントを記録するための新しいノードを生成し、現在のポインタを新しいノードにリセットする。シーケンスは、ＢＯＴのイベントから始まり、ＥＯＴのイベントによって完成される（それは、ピリオドのような文の終了、スペースパーティクルのような単語の終了、いくつかのデータベースにおけるセミコロンのようなレコードの終了、を示す境界を定める要素によって引き起こされるかあるいは示すことができる）。
【００１４】
パーティクルからのシーケンスの生成により、構造の他のレベルは、モデル化される領域に依存して生成されることが可能である。フィールド／レコード領域については、たとえば、パーティクルの第１のシーケンスは、フィールドにおけるシーケンスの変数として認識される。完成されたフィールド変数シーケンスは、パーティクルがフィールド変数シーケンスを生成するために使用されるのと同じ方法で、レコード・シーケンスを形成するために使用される。
【００１５】
データを見つけるためのルールも同様である。データの各パーティクルについては、現在の位置ポインタから連続して続くこのパーティクルのイベントが既に構造におけるノー
ドか否かをチェックし、もしそうであるならば、現在の位置ポインタを新しい位置にリセットする。（現在の位置ポインタを新しい（次の）位置にリセットするというこの動作は、このノードのアドレスを返すために利用可能にするであろう）。そうでなければ、完全な一致が見つからなかったことの表示、あるいは場合によっては現在の位置ポインタを「次善の」結果の位置にリセットすることのいずれかを処理する。
【００１６】
たとえば、もしあなたがレコード１４４９Ｂ２におけるすべてのＡのリストを望む場合には、その要求は、人がそのレコードを構築するすべてのノードのリストをそれから得るであろうレコード１４４９Ｂ２に対する要素ルートノードのコールと、要素のＡが結果であるノードへのポインタのリストを得るコールとを含むであろう。その後、リスト間の一致したアドレスに対して比較がなされるであろう。一致したアドレスの数は、レコード１４４９Ｂ２およびそのレコード内にどれだけのＡがあるか、およびそれらの位置を示すであろう。
【００１７】
このように、Ｋエンジンは、コールによって開始されるスレッドを取り扱い、そして、検索、学習を伴う検索、異なる方法での検索、および学習といった様々なジョブを行なうスレッドを容易にすることが可能であるとともそれが必要であるときにコール・イニシエータにエラー・メッセージを返信する能力を有するべきである。
【００１８】
一般に、その後、我々は、Ｋストアにクエリを行ない、Ｋストアを構築することを可能にする外部のアプリケーションによる接続のための方法を構築してきた。
【００１９】
一般に、コンポーネントは、学習エンジンおよび１セットのＡＰＩユーティリィティを備えている。学習エンジンは、多くの種類の入力データ・ソースからのデータの受信を可能にし、ユーザによって構築されるＫストアが管理下に置いているタスクに適した方法でデータをパーティクル化するように構成することができる。パーティクルに関するメタデータは、構築されるＫストアのためのユーザの意図と一致する方法で学習エンジンによって取り扱われる。たとえば、画像知識ベースが構築されており、ユーザが様々なフォーマットにおけるイメージ・データを得ることができることを望む場合には、パーティクル化され、Ｋストアに入れられるために読まれ、処理されるイメージのフォーマットに関するデータは、パーティクルあるいは複数のパーティクルとしてイメージ・データと共に維持され、渡されることが可能である。Ｋストアに送信されるデータがフィールド／レコード形式のデータベースからの情報である場合には、特定のフィールド名は、ユーザが生成しようとしているＫストアの全体的な設計に依存して、維持、変更、あるいは破棄されるであろう。必要に応じてデータをパーティクル化した後で、その後、学習エンジンは、Ｋエンジンに適切なコールを行ない、パーティクルの形態のデータを、ＫエンジンがそれをＫストア構造の中に入れることを可能にする方法で渡す。
【００２０】
ＡＰＩユーティリィティは、Ｋストアの問合せを容易にする。それらは、問合せを受信して、Ｋエンジンへのコールにそれらを分解するか、Ｋに直接アクセスするか、あるいは関連するメモリを更新することが可能でなければならない。クエリは、Ｋストアがその構造に記録するためのイベントではないことが好ましい場合がある。そのような場合には、学習スイッチは、クエリによってイベントあるいは複数のイベントが記録されることを防ぐために、オフにされるべきである。（フィールド／レコード・データ領域にとって、これは一般にそうではあるが、人工知能アプリケーションにとっては、学習スイッチがクエリのために「オン」であることが好ましい状況を逆にすることは意味があるであろうが、場合によっては学習／トレーニングのためにだけ「オン」になってもよいことを注記しておく。スイッチそれ自身が、Ｋストアに関する学習アクティビティと非学習アクティビティとの間の変更を提供する最良の方法ではないことがあることも注記しておく）。異なる種類のスレッド・アクティビティに応答するＫエンジンの個別のインスタンスを設定する
こと、つまり、異なる設定のための各テストによって、これを行なうことができるであろう。したがって、これらの手順のうちの１つは、学習エンジンを使用したスレッドに応答して学習するであろうし、また、別のものは、学習したクエリ・スレッドからのものであってもよいし、さらに別のものは、学習を行わなかったクエリ・スレッドからのものであることができるであろう。
【００２１】
ＡＰＩユーティリィティは、場合によっては、Ｋが構築されるときに（パーティクル化し、Ｋエンジンを呼び出すのではなく）セットアップされる、あらかじめ定義されたポインタを使用してＫから情報を得る。たとえば、レコードＥＯＴセンサ、フィールドＥＯＴセンサ、および列ＥＯＴセンサのほか、ＢＯＴセンサを示すフィールドが存在する。このフィールドは、Ｋエンジンに関連し、それがこのポインタ情報を追跡することをＡＰＩユーティリィティに要求することなしにそのポインタを使用してＫを自在に移動することを可能にするであろう。（ＢＯＴｈｏｕｇｈｔまたはＥＯＴｈｏｕｇｈｔにおけるような「思考（ｔｈｏｕｇｈｔ）」は、一連の記録されたイベント・ノードである。したがって、それは、開始（ＢＯＴ）および終了（ＥＯＴ）を備えた思考のような一連のイベントである。通信例に対して最も単純なものを使用するために、センサを介して一連の知覚としての思考を使用して、ここでは、これらの知覚がＣ−Ａ−Ｔ−Ｓ−＜スペース＞−Ａ−Ｒ−Ｅ−＜スペース＞−Ｆ−Ｕ−Ｒ−Ｒ−Ｙ−＜ピリオド＞と綴り、我々が思考間のデリミッタとして複数の＜スペース＞を使用する場合、我々は、いくつかのＥＯＴに対する可能性を有している（ＣＡＴＳ、ＡＲＥおよびＦＵＲＲＹの単語の終了、あるいは各単語＞の後のスペースのいずれかにＥＯＴを設定し、および、文全体を「思考」とするために１つのＥＯＴを終了（＜ピリオド＞）に設定する。したがって、この例において、我々は、文字Ｃ，Ａ，Ｔ，Ｓ，Ｆ，Ｕ，Ｒ，Ｙ，＜スペース＞および＜ピリオド＞のためのセンサを有することが可能である。ＢＯＴノードは、一連の知覚を開始する。Ｃ，Ａ，Ｔ，Ｓ，Ｒ，Ｅ，Ｆ，Ｕ，Ｙのためのルートノードはすべて、この思考になされた接続を有しており、そのノードのための１つの接続は、Ｃセンサによって表わされ、そのノードのための２つの接続は、Ａセンサ、３つはＲ、１つはＥ、１つはＦ、１つはＵ、および１つはＹによって表わされる。ブランク、バー、印刷不可能な文字、セミコロンなどの（同様に、ＥＯＴノードのような生成されたセンサでありうるもの）のようなデリミッタ。（図９において、これらは、最終生成ノードと呼ぶこともできるノード９０４，９０６，および９０８であることができるであろう）。ピリオドは、典型的なＫストアにおけるそのためのセンサを、場合によっては有するべきであるが、「文」の終了をむしろ示すことが可能であり、したがって、ＥＯＳ（文の終了）ノード（ノード９０２のような）の生成を生じさせる。しかしながら、ピリオドが文の終了以外でのものとして現われるときには、次のセンサは、たとえそれが文の終了ではなくても、入力パーティクルが新しいＢＯＴ接続を開始するであろうと検知し、Ｋストアは、ピリオド・パーティクルが単に検知されるよりも文を終了するように設定されている場合に、これをすべて分類するのにかなり大きくならなければならないであろう。）この議論は、ＢＯＴ／ＥＯＴを我々がこのアプリケーションのどこか他のところに有しているよりも少し良く定義するために含められた。図９において、我々は、定義された第２のレベル（文の開始（ＢＯＳ）および文の終了（ＥＯＳ）ノードを使用する文）をさらに有している。単語ノードのそれぞれは、ノード９０６およびノード９０８であるように前のレベルにおけるそれらのＥＯＴノードに接続される。ここでは、いま議論した構造が提示されているが、ノード構造においてスペースあるいはピリオドのデリミッタは備えていない。Ｋストアはセットアップされるとき、望まれるように、ノードとしての、あるいはそうでなくてもデリミッタでセットアップすることができ、この特許におけるどこか別の箇所に記述されるような管理ＡＰＩユーティリィティを介して課された（たとえば、状態変数を使用する）制御に従うようにセットアップされる。
【００２２】
さらに、この図９を参照して、直接接続と間接接続との間の違いを注記しておく。現在の実施形態のＫエンジンは、それに提出されたパーティクルのための位置を見つけるとき
に直接接続を捜すであろう。メッセージ（図２のメッセージのような）は、Ｋストア内の少なくとも最後の位置を識別するパーティクルに関連するポインタを有するであろう。Ｋエンジンは、最後の位置が要素ルートノードの１つに次の副コンポーネント・ノードを通じて接続されるか否かを判定するコードを有し、（最後の位置ノードのａｓＣａｓｅリストへの参照を通じて分かるように）もしそうであるならば、これは直接接続と考えられる。次の副コンポーネント・ノードが思考の次のものであることができるであろうから、これらの技術における当業者は、この命名法をよく理解するであろう。これを理解するために、図９における単語の思考ＣＡＴＳは、パーティクルＢＯＴ−Ｃから始まり、パーティクルＢＯＴ−Ｃ−Ａ−Ｔ−Ｓ−ＥＯＴで終わり、このＫストアにおいてノード９０８になった。もし最後のパーティクルがＢＯＴ−Ｃであり、そして提出される次のものがＢＯＴ−Ｃ−Ａであれば、そのような場合、Ｋエンジンの接続判定部分は、ＢＯＴ−Ｃ−Ａが要素ルートノードＡに接続されていることに注目し、したがって、Ｋストアにおけるこのパーティクルのイベントのための場所を見つけ、連動ツリー・データストアにおける新しい現在の位置としてこのパーティクルの要素ルートノードに接続された前記の次の副コンポーネント・ノードの既存の位置を確立し、そして、パーティクルのソースにこの位置を返すであろう。パーティクルのソースは、学習するためにそれが送信されることがある次のパーティクルのための次のメッセージ・データを追加するか、あるいは、それが製作過程であることがあるクエリに対する答えの一部として使用するためにこの現在の位置を使用するであろう。要素ルートノードはすべて、もちろん、特定のＫストアにアドレスすることがあるＫエンジンのうちのいずれかによって維持されるセンサ・リスト上の対応するエントリを有するであろう。
【００２３】
我々が間接接続を捜す状況がある。関与する間接の範囲は、ユーザが行ないたいものに依存するであろう。そのような状況では、前記最後の位置から前記パーティクルの要素ルートノードへの接続が間接的であろうと判定した場合、つまり、パーティクルが前記連動ツリー・データストアにおける前記次の副コンポーネント・ノード以外の副コンポーネント・ノードを通じて接続される場合である。間接接続があるか否かを判定するために、我々は、たとえば、次の副コンポーネント・ノードの向こうの他のノードをａａＣａｓｅリスト上に期待するアルゴリズムを使用する。他の処理が、予想したすべてのノードのａｓＣａｓｅリストに関与し、すべてのａｓＲｅｓｕｌｔリストを通じた反復処理、あるいは関連する根あるいは思考の終了ノードからのすべてのポインタを含み、ユーザがそのような判定をなす際に何が必要あるいは望むかに依存して使用されることもできる。
【００２４】
それが直接接続を通じたものであるか、あるいは間接接続を通じたものであっても（どちらの状況であっても、ユーザは、Ｋエンジンの関連する状態変数を通じて設定する）、パーティクルが接続されているか否かをＫエンジンのコードの区間が判定することが、考慮中のこの特定のパーティクルのルートノードに最後の位置が接続されることを判定する場合に、パーティクルの要素ルートノードの位置が新しい現在の位置として確立される。好適な実施形態においては、我々は、副コンポーネント・ノードにおいてカウンタを有しているほか、要素ルートノードおよびインクリメントされるパーティクルの副コンポーネント・ノードにおいてカウンタを有している。
【００２５】
さらに、最後の位置が、次の副コンポーネントを通じて要素ルートノードに接続されないＫエンジンにおけるコードによって判定される（ａｓＣａｓｅリストへの参照によって判定されるような）場合に、Ｋエンジンは、Ｋストアにおけるパーティクルのための新しい副コンポーネント・ノードの形成をもたらすであろう。さらに、Ｋエンジンが受信するパーティクルが終了するというある表示がある場合に、「思考」は、最終生成ノードを生成するルーチンをアクティブにするであろう。文の終了のピリオド、単語間のスペース、コンマ、セミコロン、およびレコードにおけるフィールド間の同様のもの、イメージ中の色間の黒空間（ｂｌａｃｋ  ｓｐａｃｅ）などのような共通のデリミッタは、いくつかの
用意された例であり、それらの任意のものは、デリミッタとして作用することができ、そのような場合にはそれらが内部センサに「翻訳」されるので、それらが現われるときには最終生成ノードの生成を開始する。したがって、パーティクルが思考の終了あるいはＥＯＴノードであることを判定する処理の場合、この処理は、Ｋストアにおける最終生成ノードの形成を好ましくは作動させるであろう。
【００２６】
さらに、パーティクルが思考の終了であるという判定は、このＫエンジン／Ｋストアの組み合わせのための状態変数がそのように設定される場合に、デリミッタを見つけることに依存するように構築することができる。そうであるならば、また、パーティクルに見つかったデリミッタがより高いレベルのデリミッタであるならば、我々の好適な実施形態におけるこの処理は、現在のレベルよりも下の各レベルに対して思考の終了ノードを追加し、上記のレベルに新しい副コンポーネント・ノードを追加するであろう。したがって、Ｋストアが単語、文および段落から作られており、ＥＯＳに到達した場合に、ＥＯＷ（単語の終了）およびＥＯＳ（文の終了）が処理され、文の最終生成ノードは、段落レベルで次の副コンポーネント・ノードを生成するために使用される。
【００２７】
それは、この時点では、センサが好適な実施形態においてどのように維持されるかを簡潔に議論するために有用である。典型的には個別のコードとしては生じないが、センサ・リスト・マネージャは、我々のＫエンジンにおいて見つけられる。図１Ｂを参照のこと。センサ・リスト・マネージャ（別々に示されていないが、Ｋエンジン１１の一部）は、それ自身入って来るパーティクルを比較するためのリスト中のセンサのそれぞれを維持するために記憶領域２８ａを利用する。したがって、センサ・リスト・マネージャのルーチンは、この入力されるパーティクルが既知のセンサであるか否かを判定するためにセンサのリストに対して個々の入力されるパーティクルを調査するであろう。入力されるパーティクルがセンサ・リスト上のセンサであることをそれが見つけた場合、それは、ａｓＣａｓｅリストをチェックすることによって次の副コンポーネント・ノードが前記センサに接続されていることを見つけ、そして次に、それは、現在の位置をＢＯＴ／ＥＯＴ連鎖における次の副コンポーネント・ノードに単に調節することができる。有効なセンサが見つかっていない場合には、選択肢が提示される。
【００２８】
この時点では、我々は、この選択に対する少なくとも３つのオプションを有しており、それらは、様々な方法で組み合わせることもできる。第１に、我々は、Ｋエンジンにパーティクルを無視させ、それが雑音であると仮定して次のものを待たせることができる。第２に、Ｋエンジンは、そのパーティクルに対応する新しいセンサを生成し、センサ・リスト上にその新しいセンサを記憶することができるであろう。第３に、Ｋエンジンは、残存するセンサがないパーティクルのリストを開始し、エラー信号を送信することができる。これらの３つの選択肢のうちのいずれかについても、我々は、エラー信号を送信することもあるいは送信しないこともでき、および／または、我々は、そのような発生のログを維持することもできる。我々は、任意の新しいセンサに対して、新しく生成されたあるいはエラーを通じて生成されたものとして印を付け、あるいはその発生を示すために任意の数の同様のことを行なう。これらの選択肢のうちのいずれについても、我々は、特定のルーチンにこのパーティクル、この種類の、あるいはこれらの種類の複数の任意の構成の発生を管理あるいは監視させる異なる種類の信号を送信することもできる。我々がＫエンジンの外部の或るルーチンの開始あるいは継続をそのようにもたらすかまたは引き起こすためにＫエンジンをセットアップしている場合に、我々は、それが内部の発生に応答するものであるので、この種類の設定を「内部」トリガであると見なす。この命名法は、特定の条件あるいは発生の存在のためにＫストアを周期的にチェックするＡＰＩユーティリィティ・インタフェースを通じてセットアップすることができる「外部」トリガとの相違を示している。
【００２９】
さらに、モナド（ｍｏｎａｄ）・リストは、パーティクルのレベルよりも上のレベルでの信号について追跡し続けるために、Ｋエンジンによって維持されることが可能である。（モナドは、最終生成ノードとも呼ばれる）。言い換えれば、好ましくは、Ｋエンジンは、その関連するメモリ、モナドのリストに維持することができる。そのようなリストは、ユーザあるいはプログラムがどのモナドが存在するかについてのリストを望む場合に一般的に使用されるであろうが、そのリストは、Ｋストアのクエリによって生成することができ、したがって、それはそのようなリストを維持するためには必要ではない。（さらに、いくつかの実施形態においては、モナドおよび／またはセンサなどに関するデータにアクセスさせるために、ＡＰＩユーティリィティ・コンポーネントを、あるいは学習エンジン・コンポーネントでさえも許容することは有利あるいは効率的である場合があり得る。クエリを送信するＡＰＩユーティリィティ、あるいはＫストアに取り込むためのパーティクルを送信する学習エンジンは、誤ったデータの種類を送信しないようにするために、モナド・リストあるいはセンサ・リスト、あるいはそのようなリストに関するメタデータへのそのようなアクセスを使用することが可能である）。上記のＣＡＴＳ  ＡＲＥ  ＦＵＲＲＹの例において、「ＣＡＴＳ」および「ＡＲＥ」および「ＦＵＲＲＹ」は、モナドであるであろうが、好適な実施形態におけるセンサ・リスト上にはない。好適な実施形態は、モナド・リストを全く必要としないが、それらは、１つが望まれる場合にモナド・リストを印刷するようないくつかの状況において有益であることができる。その意味は、Ｋエンジンがその単語（再びこの例において）ではなくこの例における文字のようなパーティクルに対してセンサ・リストをチェックするということである。別の意味は、モナドについての情報（このＫストアに関連するデータを使用して取り出すことができる単語のリストあるいはテーブルのような）がそのモナド・リスト情報を維持するコンポーネントに関連するメモリから取り出すことができるということである。したがって、そのコンポーネント（つまり、ＡＰＩユーティリィティあるいは学習エンジン・コンポーネント）を使用するどのようなスレッドも、Ｋストアにおいてそれらを捜す必要なしにモナド上のそのようなデータにアクセスするであろう。コンポーネントがＫエンジンのインスタンスであると仮定して、ＫストアにアクセスするためにそのＫエンジンを使用するどのスレッドもそのようなデータにアクセスするであろう。コンポーネントがＡＰＩユーティリィティのインスタンスであると仮定して、ＫストアにアクセスするためにそのＫエンジンを使用するどのスレッドも、様々なモナドあるいは複数のモナドと特定のクエリに関与することが可能である他のノードとの間のより複雑な構造あるいは関係を捜す前に、関与する特定のモナドを最初に見つけなければならないよりも、より速くＫストアにおける、場合によってはより複雑な構造を見つけるためにそのようなデータにアクセスするであろう。
【００３０】
別のことは、最終生成ノードあるいは思考の終了ノードを取り扱う、場合によっては別の好適な実施形態について記述されるべきである。これらの最終生成ノードは、連動ツリー・データストア（Ｋストア）構造における次のレベルのためのルートノードと見なすことができる。したがって、それらが発生するときに、それらは、センサ・リストに追加することができ、より大きなパーティクルは、Ｋエンジンを通じてＫストアに供給することができる。これは、容易に図９において理解することができ、そこでは、その単語は、文字の代わりにセンサになることができ、また、与えられたコンテクストにおいて、望ましい場合には、センサ・リストは、より大きな（文字サイズの代わりに単語サイズ）パーティクルの受入れのための道を（この例の特徴を使用して）開くことができる。大規模なセンサ・リストを有していることは、パーティクルがセンサに相当するか否かを判定することに長い検索時間を課すが、したがって、この実施形態が動作するシステムの物理的な範囲は、このアプローチを採用する前に考慮されなければならない。
【００３１】
ＡＰＩユーティリィティがＫエンジンに行なうリターン・コールがすべて、適切に取り扱われ、クエリへの応答として返信するのに有用な結果に適切にコンパイルされるように、クエリは、ＡＰＩユーティリィティにアクセスする必要があるであろう。Ｋエンジンか
らのリターン・コールのこの取り扱いを達成するには多くの方法があり、それらは、クエリの性質に応じて変わる。或る場合においては、リストがコンパイルおよび／または比較され、或る場合においては、リストからのアイテムが見つけられるであろう。Ｋエンジンは、現在の位置ポインタのみを返し、ＡＰＩユーティリィティは、Ｋストア自体へのその読み出し専用のアクセスを使用して、Ｋストアにアクセスするためのリターン副コンポーネント・ノードあるいは最終生成ノード・ポインタを使用するであろう。これらの返された現在の位置ポインタは、他のノード（つまり、ａｓＣａｓｅリストのほか、ａｓＲｅｓｕｌｔリスト）へのポインタを含む副コンポーネント・ノードを指し示すであろう。リターン位置ポインタは、実際の値を含むことが可能である要素ルートノードを指し示さない。
【００３２】
好適な実施形態において、これは、複数のＡＰＩユーティリィティ・オブジェクトを有していることを通じてなされ、それぞれが、Ｋに対する一または複数の機能に関連している。Ｋに対するこれらの機能は、アルゴリズム処理を提供するように動作する装置であり、それは、「制約」および「フォーカス」を設定するようなクエリあるいはクエリの部分の解を見つけるのに使用される。これらの機能は、アプリケーションから、あるいはユーザによって直接コールすることができる。いくつかの好適な実施形態においては、実際のＧＵＩあるいはメニュー・スクリーンは、Ｋに対する特定の機能の使用を容易にするように生成される。
【００３３】
Ｋ、ＡＰＩユーティリィティおよびＧＵＩなどに対するこれらの機能の使用によって、我々は、リアルタイムに複数のソースからのデータを追加する能力をアプリケーション・プログラムおよびユーザに提供するためにＫストアを使用することを比較的簡単にさせ、さらにデータを検索、分析、あるいは他の使用に直ちに利用可能にさせる。
【００３４】
我々がここで記述する処理は、標準ファイルからの静的なデータのほか、より動的でリアルタイムの入力を処理することができる。標準入力フォーマットは、“．ｔｘｔ”あるいはＸＭＬあるいは任意の他のフォーマットにフォーマットされたファイルのようなものであることができるであろう。これは、あらかじめ構成された変換コンポーネントと共に使用されるであろう。その処理は、さらにカスタム・フォーマットされた静的および／またはリアルタイムのデータ供給を受け入れることができるであろう。データが、入力データ・フォーマットが既知であり、構築中の特定のＫに普遍的に使用されるものに変換することができる場合に、どのようなフォーマットであるかは重要であるべきではない。Ｋの異なる事例は、異なる入力フォーマットを使用することができるであろう、また、もし望むのであれば、単一のＫは、異なる入力フォーマットからデータをそれ自体で受信することができるであろう。さらに、入力データ・ストリームをフォーマットすることなしに単にパーティクル化することを単に可能にすることが可能であり、Ｋストアは、何が何であったかいずれ分類するが、現時点ではそのようなアプローチは非実用的であろう。データから構築される知識ベースは、好適な実施形態においてＫストアにアクセスしているソフトウェア・アプリケーションを管理している一または複数のＧＵＩ（音響、触覚あるいは任意の形式のインタフェースを含むことができるであろうグラフィック・ユーザ・インタフェース）インタフェースを通じて好ましくは可視化される。さらに、それは、入力データがデジタル形式のデータに限定される必要がないことは記述する価値がある。アナログ入力（様々な種々の特性を含んでいるが、信号の高さ、信号の持続、信号の強さに限定されない）は、アナログ・センサ・データが入力データ・ストリームの一部であり、マイクロホンが音を拾うために使用され、また、出力がデジタル化されておらず、アナログ信号の様々な他の潜在的なソースが利用されているときなどに、同様に使用することができる。このデジタル時代に、そのような入力を使用することができると認めることは重要であるように思える。人が入力の性質および構築されたＫストアの予期された使用を与えられることが適切であるように思えるときに、人は、アナログ信号をパーティクルにセグメン
ト化することを選択することができる。
【００３５】
一般に、データ・ソースは、リアルタイムに学習エンジンを通じてＫストアにデータを送信することができ、あるいは、もし望まれるのであれば、学習エンジンは、Ｋストアに静的なデータを受け入れさせ、データ倉庫として作用させることができる。言い換えれば、使用されるデータ・セットは、永続性のデータ記憶システム（たとえば、ディスク）から読むことができるか、１つ、あるいは複数のソースから連続的なストリームとしてリアルタイムに読まれることができる。
【００３６】
リアルタイムの好適な実施形態においては、ソフトウェア・アプリケーションは、ほぼ確実にサーバ上で動作しており、様々なＫのビュー（ＧＵＩ）は、ウェブ・ベースであり、データ・ストリームは、それがリアルタイムに生成されるときにインターネット（あるいは、もし望まれるのであればローカル・ネットワーク）を亘って到来し、Ｋストアは、動的である。我々は、自身のソフトウェア・アプリケーション製品を作成してきたが、システムの要素の位置が、異なるコンピュータ・システム上で、および異なる接続で、容易にホストとして作動することができることは認識されるべきである。
【００３７】
したがって、データが読まれるときに、「Ｋストア」あるいは知識ストア・データ構造は、コンピュータのメモリ・システムに好ましくは構築される。その構造の性質によって生成されるＫストア・データ構造は、データ・セットにおける変数間の関係をモデル化する。このＫストアは、データ・セットにおける変数間の関係を調査するために、分析ＧＵＩあるいはバッチ・アプリケーションなどを使用してクエリを行なうことができる（つまり、データ・マイニング・アクティビティを実行する）。Ｋストアは、データが読まれ、Ｋストアが構築される間、クエリを行なうこともできる。
【００３８】
我々がＫストアを外部の世界に接続することを例示することができる１つの方法は、学習エンジンの使用を通じたものである。学習エンジンは、Ｋストア内へ知識の移動においてその機能を有効にするためにスレッドをサポートするそのタスクを達成するためにＫエンジンにコールする。スレッドは、データ・ソースとの通信の確立によって開始される。これは、ＧＵＩあるいはアプリケーション・ソフトウェアを介して行なうことができる。学習エンジンへの各コールについては、受け取り通知の後で、あるいは他のプロトコル手段で、学習エンジンは、処理のためにＫエンジンに単一の「キャラクタ」を送信する。このように、Ｋエンジンは、イベントのシーケンスを記録するようにＫを構築する。どのように「注意のポイント」あるいは「位置ポインタ」でのこのポジショニング、また、その後、それが新しい場合にどのように構造を追加するかについての議論は、米国特許出願第１０／３８５，４２１号においてまず手に入る。これは、現在の位置ポインタから連続して続くこの「キャラクタ」のイベントが構造における既存のノードであるか否かを見るためにチェックすることから一般的になり、そして、そうであるならば、ノードにおいてカウンタを追加することによってイベントの強さを高め、また、そうでなければ、イベントを記録するために新しいノードを生成する。さらに、新しいノードがイベントを記録するために生成され、この新しいノードが１レベル以上の新しいノードである場合に、付加的なノードは、それを示すために追加される必要がある場合がある。たとえば、文ノードの終了は、単語を終了することも可能であり、したがって、文ノードの新しい終了および単語ノードの終了が追加されることが可能である。
【００３９】
１つのアプリケーション・ソフトウェアにＫストアを接続することによって我々が何を意味するか示すために、我々は、特定の種類の分析的な単一変数予測および、上で参照された特許出願第１０／７５９，４６６号において我々が記述した処理を使用して、クエリがどのように取り扱われるか記述し、それによって、Ｋストアに情報を配置するために、Ｋエンジンが注意のポイントに位置するであろう。これは、コンテクスト（制約とも呼ば
れる）およびフォーカスを決定すること、ならびにそれをＡＰＩユーティリィティを通じてＫエンジンに通信すること、また、結果を受信することを要求する。したがって、我々は、基礎的なＧＵＩも提供し、それによってユーザがこのクエリを実行することができ、また、コンポーネント処理および要素について記述し、それによってＫストアの領域においてこれが生じることができる。Ｋにおける情報を見つけるための好ましい方法のさらなる説明に関しては、単一変数予測についての下記の議論を参照のこと。Ｋエンジンが要求されたデータに対する正確な一致を見つけることができない場合、２つの可能性のある応答があることを注記しておく。現在、我々は、これをエラーと考えて、位置ポインタおよび、場合によっては結果として生じる「エラー」コードを変更しない。しかしながら、或る時点では、我々が正確な一致を得られなかったが、次の「最も近い」結果あるいは可能性のある結果のリストを返すことを示すことが可能である。例えば、要求された単語を見つけることはできないが、あなたに可能性のある別の答えを与えるスペル・チェッカである。
【００４０】
Ｋストア・データ構造に適切な２つの処理が基本的に存在するので、我々は、２つの付加的なエンジンを作成した。１つは、Ｋストアを構築させ（つまり、学習する）、２つ目は、Ｋストアに知識へのアクセスを提供させる。第１の付加的なエンジンを我々は学習エンジンと呼び、第２のエンジンを我々はＡＰＩユーティリィティと呼ぶ。ＡＰＩユーティリィティがさらに構築および学習を生じさせることも可能であり、その構築および学習はＫストアからなるクエリについてのものであり、人が何かについての考えを思い出す方法と同様である。類推的に言い換えれば、ちょうどＫストアが想起するように要求されたことを「思い出す」ことができるように、人が以前考えたアイテムを人が思い出すことができることを注記しておく。この機能についての詳細は、この特許の残りを読んだ後により明らかになるであろう。それにも拘わらず、ＡＰＩユーティリィティは、アプリケーション・プログラムがＫストアから答えを求めるクエリに一般的に使用される。
【００４１】
ＡＰＩユーティリィティは、さらにスレッドのためのサポート・プログラムから一般的に構成されている。スレッドは、クエリがそれを通じて提示されるＧＵＩあるいはアプリケーション・ソフトからの通信によって開始される。クエリによって開始されたスレッドをサポートするための１つのプログラムは、Ｋストア内の注意のポイントの位置を判定するＫエンジン・ルーチンにコールするためのアクティブ化可能な処理である。ＫエンジンへのコールがＫストアを全く見つけない（あるいは選択された注意のポイントでの位置が全くない）場合、Ｋエンジンは、この場合、エラー信号を返すであろう（あるいはエラーを示す「無効」コール返答）。そうでなければ、構築されたＫストアを仮定して、それは、Ｋエンジンの位置のアクティビティによって示される情報（つまり、求められたノードあるいは複数のノードのアドレス）を返す。注意のポイントの位置を判定することについての詳細は、「連動ツリー・データストアにおいてデータを記憶し、データにアクセスするシステムおよび方法（ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＳＴＯＲＩＮＧ
ＡＮＤ  ＡＣＣＥＳＳＩＮＧ  ＤＡＴＡ  ＩＮ  ＡＮ  ＩＮＴＥＲＬＯＣＫＩＮＧ  ＴＲＥＥＳ  ＤＡＴＡＢＡＳＥ）」とタイトルを付けられた米国特許出願第１０／６６６，３８２号に記述されており、上記の参照によって記述および援用される。この‘３８２出願は、さらにコンテクストおよびフォーカスを判定することによってＫストアにおけるデータを評価する方法について、言い換えれば、Ｋストアのノードによって表わされるデータに関する確率について構築されたクエリに応答する方法についても記述している。そこに記述された評価処理は、Ｋエンジンの単に繰り返される実行であり、毎回、コンテクストおよびフォーカスを見つけるのに使用される評価処理に応じて構築されたクエリに応答する注意のポイント（ノード）を見つける。
【００４２】
好適な実施形態においては、ＡＰＩユーティリィティの一部であることが可能であるインタープリタは、それらがアプリケーション・プログラムあるいはユーザ・インタフェー
スによって尋ねられる形式でクエリに答えるように制約およびフォーカスを使用する。
【００４３】
「キャラクタ」によって、我々は、Ｋエンジンが構築している特定のＫストアのセンサあるいは要素ルートノードと認められるものである任意の「パーティクル−化」（以下、パーティクル化）形式を意味する。たとえば、このＫストアが認識する最小レベルの情報がＡＳＣＩＩキャラクタである場合、パーティクルは実際にはキャラクタである。Ｋストアは、単語、あるいは他の文字列のレコードを構築し、いずれは、文、段落、本などを構築することが可能である。あるいは、それは、フィールド／レコード領域の文字列変数のレコードを構築することができるであろう。特定の変数だけが見つかるであろうと我々が確信するフィールド／レコード領域においては、我々は、変数あるいは要素ルートノードとしてこれらの変数（単語あるいは他の文字列変数のような）を使用することができる。そのような状況においては、Ｋエンジンは、シーケンスあるいは同様の入力を含むパーティクルとしてどのようなデータも受け入れる。
【００４４】
最小レベルの情報が画素である場合、別の例として、イメージ内の位置、色、および明るさは、パーティクル画素の属性であることが可能であり、また、要素ルートノードは、それらの特性としてそのような属性を有し、個々の付加的な画素は、すべてそのような属性を有する（これ以上属性がない）ＫエンジンによってＫストアに提供され、各画素は、構造に一旦配置されたＫストアにおけるノードを識別するであろう（あるいはノードを有すると識別される）であろう。この例において、画素のための「センサ」は、イメージの位置、色および明るさを含み、学習エンジンは、個々のそのような属性のためのユニットあるいはセンサとしてＫエンジンに情報のパーティクルを供給しなければならないであろう。属性を他の属性と一緒にユニットにすること、および「より大型の」パーティクルを有することによってこれを構築する他の方法があるが、それは、この議論を超えており、好ましくない。我々が構築しているシステムが「属性」をそれら自身、好適な実施形態のＫ構造における他の「センサ」に接続された「センサ」と考えた場合、これらは、実際に「或る属性を備えた画素」である最終生成ノードを生成するであろう。（より一般的な原理がこの議論に関係しているが、学習しているＫのためのセンサとパーティクルが一致しなければ、そのパーティクルは無視される（つまり、Ｋ構造においてレコードを生成しない）であろうということを実現することは重要である。したがって、そのＫのためのＡＳＣＩＩキャラクタ・セット・センサだけが存在する場合、ＡＳＣＩＩキャラクタのためのビット長よりも長い１および０の文字列は、無視されるであろう。或る実施形態において、ある条件が優勢である場合、我々が余分なパーティクルを維持し、それらをプールあるいはそれらを見直し、そして新しいセンサを追加することが可能であることを注記しておく。たとえば、同一形式の多数のパーティクルが送信される場合、ルーチンは、Ｋストアにおいてこれらを取り込むために新しい、予め定められていないセンサを確立することができるであろう。）
したがって、パーティクル化することは、データを所定のセンサ・セットに分解する試みである。学習エンジンは、それがデータ・ソースから受信するものを１セットのセンサに分解するように機能しており、Ｋエンジンに次々とそのパーティクルのセットを供給している。センサは、Ｋによって検知することができるデータの中で最も小さい単位と見なされることがある。各Ｋは、もし望まれるのであれば、それ自身の固有のセンサのセットと共に設計することができるが、そうする際には、人がＫを適応させるために生成するデータに注意するべきである。ＡＳＣＩＩキャラクタ・セットは、データベースがＫストアの使用のための、場合によっては第一の目標市場であるときに実質的な商業用途を有するであろう共通のセットである。Ｋストアがロボットに使用される場合には、アクチュエータを通じて利用可能なタッチ信号、およびそれらのアクチュエータの動作を示す信号は、より有用なセンサであってよい。精油所内のアクティビティを自動化あるいは追跡するために使用される場合には、Ｋストアは、パイプを通じた流れ、タンク・レベル、様々な位置における温度などを示す信号を拾うかあるいは注目するセンサを好ましくは有するであ
ろう。
【００４５】
さらに、我々が学習することおよびクエリを行なうことの両方を記述しているので、処理を学習（構築）モードに入れるか、あるいはそれをクエリ・モードに維持する「スイッチ」をオフあるいはオンにするための機構が必要であることを述べておく。クエリ・モード中での場合、学習モード・スイッチをオンにしたまま、各クエリは、付加的なノード、あるいはＫエンジンが既存のノードにアドレスするときに、Ｋストアにおける既存のノードに付加的なカウントを追加することが可能である。好ましくは、この機構は、学習エンジンにあるが、他の手段を通じても同様にアドレスすることができるであろう。学習エンジンおよびＡＰＩユーティリィティは、スイッチ状の機能の動作を達成するために異なる手順のコールを有することができるか、あるいは他の手段が使用されることもできるであろう。
【００４６】
さらに、いくつかの実施形態においては、我々は、トリガが条件またはイベントに応答し、Ｋストア・システムの外側での動作を達成するためにＫストアからの出力を生成することを許容する。これらは、それぞれ、Ｋストア自体内のアクティビティに応答し、あるいは、条件またはイベントに関する周期的なクエリに応答する内部または外部トリガであることができる。内部トリガは、好適な実施形態において、それらのためのスイッチの設定によって有効および無効にされる。これらのトリガ・スイッチのための設定は、メモリに関連するＫエンジンに好ましくは記憶されるが、当業者は、そのような記憶装置のための他の位置を見つけることができる。
【発明を実施するための最良の形態】
【００４７】
好適な実施形態の詳細な説明
図１Ａは、Ｋエンジンがその他の世界へのＫ  １４ａのただ１つの接続を提供する好適な実施形態の環境においてＫストア１４ａを図示している。（図示においてはＫエンジン１１ａと同様に、Ｋストア１４ａへのアクセスを提供する複数のＫエンジンが存在することがあることをさらに注記しておくほか、我々は、その範囲内でより詳細に議論するであろう）。今度は、Ｋエンジン１１ａは、それらが動作するコンピュータ・システム（図示せず）のリソースと協働するスレッドを管理及び取り扱うＡＰＩユーティリィティ５および学習エンジン６のようなソフトウェア要素によってアドレス可能である。（我々はＫのいくつかの実施において単一のパーソナル・コンピュータを使用したが、典型的には、コンピュータ・システムは、サーバであるであろう。）
外部の世界は、我々の好ましい配置においては、これらのＡＰＩユーティリィティおよび学習エンジンのみを通じたＫ構造へのアクセスを有している。ＡＰＩユーティリィティおよび学習エンジンは、アプリケーション層を通じて外部の世界からアクセスされる。ＧＵＩ、データベース、およびデータあるいは要求情報を提供することができるであろう任意の他の種類のプログラムあるいはインタフェースのようなソフトウェア・アプリケーションは、このアプリケーション層においてホストすることができる。図１Ａは、この同じ構造を図示しているが、ホスティング環境がその性質において本質的に柔軟性があることを読み手に示すために、スレッドおよび層の明示的な描写を回避するように描かれている。
【００４８】
具体的には、図１Ｂにおいて、我々は、コンピュータ・メモリ・システム（図示せず）に配置された雲としてＫストア「Ｋ」１４を図示している。この「Ｋ」１４は、Ｋエンジン１１によってアクセス可能である。（複数のＫエンジンが存在してもよいであろう。これは、或るさらなる詳細において記述される）。アプリケーション・ソフトウェア層１５は、ユーザがクエリおよび返答のようなデータを送信および受信するための様々な形式のＧＵＩ（グラフィック・ユーザ・インタフェース）インタフェース１５ｃを含むことが可能である。この層１５は、さらに、Ｋストア  Ｋ  １４を構築するためにデータを提供す
るデータ・ソース１５ａ、あるいは雲のプログラム１５ａ（それらはデータ・ソース中にあるか、あるいはデータ・ソース関連している）を含むことが可能である。さらに、この層１５は、そのアプリケーション・プログラムがクエリを作り、Ｋに関するデータを提供することが可能であるアプリケーション・プログラム１５ｂを含むことができる。これらの層１５構造のどれも、好ましい形態におけるこの発明の主な特徴を単に識別するこの図中では示されていない。さらに、保守および管理機能がアプリケーションあるいはＧＵＩのいずれかを通じて実行されることもできることを注記しておく。これらの管理および保守機能（後述）は、Ｋストアおよび／または学習エンジン、およびＡＰＩユーティリィティを構成するために使用することができる。層１５のコンポーネントは、もし望まれるのであれば様々なコンピュータ・システムおよびネットワーク中のホストされたＧＵＩおよびアプリケーションの部分と共に、インターネットに亘って広げられることができるか、あるいは、それはすべて、ＫおよびＫエンジンをホストするほか、コンポーネント学習エンジンおよび／またはＡＰＩユーティリィティをホストする同じコンピュータ・システム・サーバに対してローカルであることができる。別の関連する例示は、より詳細に下に議論される図７にある。
【００４９】
図１Ｂにおいては、層１６は、ＡＰＩユーティリィティおよび／または学習エンジン２１ｂ／２１ａのうちの少なくとも１つの事例を含んでいる層である。この図中に示される特徴については、それが両方の種類のインタフェース・オブジェクトに対して同様に機能するので、我々は単にインタフェース・オブジェクトにコールすることができる。このオブジェクトは、それらの形式に拘わらずＫにアドレスするために、情報またはデータ入力１９，１８のためのコールを有効にするプログラムのセットを含むか、あるいはそのセットである。このオブジェクト学習エンジン２１ｂあるいはＡＰＩユーティリィティ２１ａへのコールは、スレッド、複数のスレッド１９ａあるいはスレッド１８ａをそれぞれ開始させる。このスレッドは、学習エンジンに連続あるいは不連続のデータのストリームを供給するか、あるいはＡＰＩユーティリィティのためのクエリのパラメータを含むことが可能である。ソフトウェア・オブジェクト２１におけるプログラムは、それぞれスレッド１９ａ，１８ａの処理必要性に応じるためにメモリ（好ましくはサーバ上、したがって層１６内）内のデータ記憶領域２６，２７をセットアップする。スレッドは、それらが記憶領域にアクセスすることを可能にする「クッキー」あるいはキーＣ１、およびＣ２をそれぞれ与えられる。スレッドに制御される記憶領域のそのようなアクセスは、それぞれルーチン１９ｄ、および１８ｄを有しているソフトウェア・オブジェクト２１ａ／２１ｂの再入コードを使用して達成される。これらのルーチンは、アドレス、ポインタあるいはパーティクルに関連する他のデータを、スレッドが実行するときにデータ記憶領域２６および２７から出し入れして、スレッドに渡すことを可能にするであろう。したがって、学習エンジンの場合、シーケンスにおいて位置ポインタがこのスレッドのために現在どこにあるかを示すポインタ・アドレス、関連するノードのすべてのセットへのポインタのリスト、およびその性質の情報は、記憶され、必要が発生するときに記憶領域２６あるいは２７からアクセスされる。このように、記憶領域２６および２７内のデータは、それらは新しいイベントを配置するための、あるいはＫ内の既存のイベントを見つけるための動作をＫエンジンが構築するのを助けるという点で、Ｋエンジン１１のアクティビティを駆動するために使用される。Ｋエンジンのアクティビティの結果に基づいて、ＡＰＩユーティリティ・ルーチンは、（データ記憶領域２６内のデータ２９を更新するか、あるいはデータ記憶領域２７内に既にある或るデータを変更するために再入コード１９ｅを使用して（データ２８の変更で再入コード１８ｅを使用して））データを追加することが可能である。言い換えれば、我々は、データ記憶領域のアドレスを順に回しており、したがって、我々は、データを直接更新することができる。その単独のジョブが記憶領域を管理することであるそのようなデータ転送／修正に関連する個別のコードをある人が有することができないであろうと言っているわけではない。
【００５０】
一般に、その後、スレッドは、学習エンジンあるいは結果を問い合わせるクエリにそのような要求を取り扱うＡＰＩユーティリィティから送信される新しいデータの出現によって生成される。学習エンジン２１ａの場合、このスレッドの生成の管理は、スレッドがこれらの確立されたメモリ・リソースへのアクセスを有するように、メモリ・リソース２６ａおよびキーあるいはクッキーＣ１の割付けあるいは確立を要求する。ＡＰＩユーティリィティ２１ｂの場合、さらに、クエリ・スレッドを管理するために、およびＫ構造１４とＫエンジン１１との間のその操作を案内するために、メモリ・リソース２７ａおよびキーあるいはクッキーＣ２を確立するであろう。Ｋエンジンは、現在の位置ポインタを生成して、Ｋストアをくまなく調べ、関連するクエリあるいはスレッドが作業中のクエリの部分に答えるためにＡＰＩユーティリィティによって使用することができる、Ｋ  １４の領域におけるイベントを取り扱うであろう。プログラミング技術における当業者は、スレッドの概念、およびプログラム生成される信号および／またはデータ列などに応答して、コンピュータ・システム内に様々なオブジェクトを生成させる方法に精通しており、したがって、スレッドを使用してこれを達成する方法についてのさらなる議論は必要ではない。同様に、プログラミング技術における当業者にとっては、そのような処理のセットがなんら困難なくほぼ任意の現代のプログラミング言語で生成することができ、そうするための多数の方法が存在することが容易に理解されるであろう。
【００５１】
スレッド１９ａおよび１８ａにそれぞれ割り付けられたこれらのメモリ・リソース２６ａおよび２７ａは、学習エンジンおよびＡＰＩユーティリィティが中間の処理をバッファおよび管理することができる場所を提供する。そのような中間の処理は、スレッドのアクティビティをサポートする際に、学習エンジンおよびＡＰＩユーティリィティの機能を満たすために必要である場合がある。学習エンジンにおいては、記憶領域２６ａは、学習エンジンが要求に応じて個々のパーティクルを分離および管理するように機能する一方で、パーティクル化されているデータを保持するためにバッファとして使用されるであろう。記憶領域は、さらに、どのパーティクルがＫエンジンに現在送信されているかを判定するためのポインタ・リスト、およびデータ・ソースから入力されるデータ・ストリームに対するこのイベントの構造的な関係を維持するためのスペースを提供するであろう。線１９ｂおよび１９ｃは、スレッドの再入コード・セグメント１９ｄと、パーティクルおよび記憶領域へ入って来るデータ・ストリームの任意の他の必要とされる部分（もしあれば）を割り付けるパーティクル化処理を制御する記憶領域２６ａとの間の経路を示している。線２９は、スレッド１９ａによってＫエンジンに運ばれたメッセージの一部としての学習エンジンのパーティクル・データのエントリを容易にし、区間１９ｅで、ここでは、Ｋエンジン１１は、Ｋ  １４におけるイベントのレコードを処理し、現在の位置ポインタを学習エンジンに返す。（したがって、図面においては、下に述べられた或る状況においてスレッド１９ａは、スレッド１８ａと異なり、Ｋエンジンを通過することなく、Ｋ自体へ続かないことがある）。
【００５２】
ユーティリィティに関係するＡＰＩスレッド１８ａは、ＡＰＩユーティリィティ２１ｂのリソースを使用して、クエリを行なう際にスレッド１８ａのアクティビティをサポートして、同様の方法で同じ種類の機能を可能にするためにその記憶領域２７ａを使用するであろう。再び、キーまたはクッキー（Ｃ２）は、スレッドが記憶領域２７ａへのそのアクセスを管理するために好ましくは提供されるであろう。再び、ポインタ・データおよびスレッドのアクティビティに関係するデータ、この場合はＫの問い合わせは、スレッドの処理が展開している間、領域２７ａに記憶される。ここでは、データは、ＡＰＩユーティリティ・ルーチンが共に動作する１つの再入コード１８ｅから線２８に沿って記憶位置ポインタあるいはアドレスの形式で返される。複雑なクエリのためにかなり複雑であることができる記憶領域の管理は、再入コード１８ｄおよび通信経路あるいはメッセージ１８ｂおよび１８ｃを通じて取り扱われる。
【００５３】
好適な実施形態においては、付加的な記憶領域は、Ｋエンジン（領域２８ａ）のために、およびＫストア（Ｋ  １４）自体（領域２８ｂ）のために割り付けられることもを注記しておく。そのような記憶領域の使用は、ＡＰＩユーティリティ・ルーチンがクエリあるいは付加的なデータ入力にどのように応答するか、学習するべきか学習しないべきかを判定するときにＫエンジンおよびＫ構造自体のための、そしてプログラム制御されることが可能である様々な特徴のために、様々な状態および条件を判定するスイッチのような機能をサポートすることが好ましい。一例として、我々が２つのＫエンジン（両方とも単一のＫにアクセスする）を有している場合には、記憶領域２８ｂは、それが新しいイベントを学習することができるであろうように、Ｋをロックするために使用されるであろう。Ｋがロックされるとき、それへのアクセスを有しているＫエンジンだけ（あるいはロックされることが可能であるその部分）が、そのＫ（あるいはＫのその領域）を変更することができるであろう。記憶領域２８ａは、それを使用する特定のＫエンジンの能力あるいは構成に関する情報を記憶するために必要であろう。読み手がＫおよびＫエンジンの使用に精通するときに、そのような記憶領域のための付加的な特定の使用は自明であろう、要するに、各Ｋの状態および使用中である場合がある任意の普遍的なプロパティ・スイッチの状態を記憶するための専用の記憶領域、ならびに各Ｋエンジンの状態およびスレッドの任意のセットによって使用されるであろう任意のプロパティの状態のための専用の記憶領域を有することは最も有用である。
【００５４】
一般に、スレッドは、学習またはクエリを達成するために、ＡＰＩユーティリィティおよび学習エンジンからＫエンジンへのコールを生成するであろう。Ｋエンジンは、「パーティクル」を処理し、呼出し側にＫの位置ポインタの現在の位置を返す。送信された「パーティクル」がセンサとして認識された場合、Ｋエンジンは、Ｋポインタの現在の位置からこのイベントを以前に記録したＫ上の位置へ移動することによってイベントを記録しようとするであろう。これと等価なイベントの過去のレコードがない場合には、新しいＫ構造は、新しいイベントを記録するために生成されるであろう。送信された「パーティクル」がセンサと一致しない場合には、現在のＫポインタは同じものに留まる。好適な実施形態においては、Ｋエンジンは、「ノイズ」としてイベントを無視し、コーリング・ルーチンは、このイベントを処理する方法を判定しなければならないであろう。しかしながら、或るポイントでは、Ｋエンジンは、エラー・メッセージを送信するか、あるいは新しいセンサを生成するか、あるいは或る他のタスクを実行するスイッチの設定に基づいて、それが別のコンポーネントへの通信であるか、電子メールを送信しているか、あるいはＫに対するそのアクティビティを修正しているか否かを「判定する」ことが可能である。スイッチあるいは修正されたＫエンジンは、これらの技術の当業者が容易に想到することができるように、そのようなアクティビティを無限に有効にすることができる。
【００５５】
スイッチがＫエンジンの性能に強く影響することができ、その構成に対する制御を可能にすることができることを注記しておく。我々が使用した特定のスイッチは、学習（ＹまたはＮ）、列番号（ＹまたはＮ）、列番号の代わりに使用されたメタデータのフィールド名（ＹまたはＮ）、ＥＯＴレベル（数および名前）、ＥＯＴＣＯＬ（列名）、ＥＯＴＶＡＲ（変数）、ＥＯＴＦＬＤ（フィールド・エントリ）、ＥＯＴＲＣＤ（レコード）のうちの少なくとも１つを含んでいる。これらの技術の当業者は、このリストが全く完全ではなく、異なるスイッチがＫストアのための異なる用途のために生成されるであろうことを認識するであろう。たとえば、多数のスイッチが、画素情報に関して、イメージを記憶するＫストアのためにセットアップされることが可能である。
【００５６】
コールそれら自身、すなわち、学習エンジンおよびＡＰＩユーティリィティ・オブジェクトからの要求は、非常に単純なステートメントあるいは命令語であることが可能である。これを理解する最も迅速な方法は、図２の命令語あるいはメッセージ３４としてそれを図示することである。そういうものとして（我々は、教示の図示の目的で命令語の概念を
使用する）、命令語は、命令のタイプ（コール）３５を有することができるであろうが、ほとんどの実施形態においては、これは、Ｋエンジンがコールの目的に拘わらず現在の位置ポインタを返すので、必要ではない。メッセージは、スイッチ・コンポーネント３６を好ましくは有するであろうが、多くの実施形態においては、スイッチは、Ｋエンジンのために他のところに設定することができる。メッセージは、Ｋストア内の関係に持ち込まれるのに適したデータ・パーティクル３７を要求する。この適性によって、パーティクルが、特定のＫストアが認識することができるものであるに違いないことを我々は意味している。言い換えれば、ＫストアがＡＳＣＩＩテキスト・パーティクルを単に理解することができ、一例のデータの単語３４のデータ・パーティクル区間３７中の情報がＡＳＣＩＩキャラクタでない場合には、そのタスクを達成するこのパーティクルを学習するために発生されたコール・ハンドラの事例の部分での不能が存在し、コール・ハンドラは、そのような事例において学習エンジンに返すエラー信号を生成するべきである。同様に、ＡＰＩユーティリィティがＡＳＣＩＩではない前記ＡＳＣＩＩベースのＫストアにおけるパーティクルを見つける要求を送信する場合、「見つからなかった」というようなことを示すエラーがそのような要求に応答して好ましくは発行されるであろう。（パーティクルのさらなる議論として、パーティクル、キャラクタ、画素、あるいは他のサインが、このドキュメント内のどこか他のところに見つかる）。依然として命令語の類推を使用して、Ｋエンジンへのメッセージは、さらに、要求のソースを示すリターン・アドレス区間３８を有しているべきである。これは、好ましくは、受け取り通知あるいはエラー信号がそれに返されるべきであることを示すために（或る種類のトレースと共に、したがってそれがパーティクル・ストリームにおけるどのパーティクルがエラーを引き起こしたかを知る）、学習エンジンによって生成されるであろう。コールがＡＰＩユーティリィティから来た場合には、リターン・アドレス区間は、ＡＰＩユーティリィティがどこからそのクエリを得たか（つまり、このコールは、どのスレッドから、そして、その部分の中のどこから、このスレッドへ来たのか）、そして、このコールが解の一部であるところまで追跡するために使用されるであろう。（部分によっては、我々は、それがクエリを解くために一緒に使用されるフォーカスパーティクルあるいは制約パーティクルであるか、あるいはいくつかの制約あるいはフォーカスを必要とする或るより大きなクエリの一部であるかもしれないことを意味する。）最後に、我々は、命令語３４に含まれたポインタ３９を有するべきである。このポインタ３９は、Ｋストアにおける現在の位置と通信する。任意の新しいＫストアにおける最初のパーティクルは、ｎｕｌｌポインタを有するであろう。このｎｕｌｌポインタは、初期化、つまり、ＢＯＴノードに反する現在の位置を設定するためのコールとしてＫエンジンによって解釈されるであろう。
【００５７】
さらに、このパーティクルが新しいイベントである場合に、あるいは、パーティクルがちょうどＫにおける或る情報を「調べる」場合に、それが新しいノードを生成することができるか否かをＫエンジンに知らせるために、メッセージにおけるスイッチ領域を含んだオプションを有していることは有用である。学習をオンおよびオフすることを取り扱うには多くの方法があるが、これは、１つの有益な方法である。人は、常に学習するＫストア構造を有することができるほか、もし望まれるのであれば、あらかじめ構築され、学習することなしにクエリに単に応答するＫストア構造を有することができる。
【００５８】
さらに、これらのスレッド１８ａおよび１９ａ（図１Ｂにおいて図示された）のアクティビティを取り扱うことのために付加的なメモリ・リソースを割り付けることが必要である場合があることを注記しておく。
【００５９】
したがって、Ｋストアの使用をサポートするために機能するシステムの基本構成要素が記述され、これらから、多くのことを達成することができる。しかしながら、ＡＰＩユーティリィティをより有用にする詳細のほか、学習エンジンの詳細は、さらなる記述を必要とする。
【００６０】
学習エンジン。
学習エンジンは、Ｋエンジンが学習するためにパーティクル化データを受信することを可能にするインタフェースおよび変換およびパーティクル化機能を基本的に提供する。したがって、それらがＸＭＬ、Ｏｒａｃｌｅ、ＤＢＭＳでも何でも、それらが静的あるいはストリーミング・ソースあるいは外部のイベントが発生させるリアルタイムのセンサ・ソースであっても、それは、予期されたデータ・ソースからの入力を受信する適切なプロトコル、トランスポート、および変換能力を処理することができるに違いない。もちろん、特定の実施形態は、そのような入力の任意の部分集合に適応することが可能である。それは、さらに、そのようなソースからデータを、Ｋストアをフォーマットする予期されたデータ・パーティクルに適合するために容易にパーティクル化することができる適切なサイズのユニットのデータに変換することができる必要があり、Ｋエンジンにそのようなパーティクルを送信するためのパーティクライザを有しているべきであり、また、適切な任意のバッファリングが追加されることも可能である。
【００６１】
さて図３を参照して、そこでは、学習エンジン３００の好適な実施形態がデータ・ソース３０１からのデータ３０２のストリームを取り扱うことが図示されている。データ・ストリームは、関連するプロトコルを備えたトランスポート機構を通じて、ほとんどの場合、場合によっては外部ソースのコンピュータ・システム（図示せず）から、インターネットあるいはローカル・ネットワークのような通信媒体（図示せず）を亘ってコンピュータ・システム（これも図示せず）に受信され、そこでは、学習エンジン３００およびＫエンジン３１０のほか、Ｋストア・データ構造（図示せず）が機能している。
【００６２】
コンポーネント３０６においては、学習エンジンは、まず、どのような外部のフォーマットおよびプロトコル加工物、およびデータ・ストリーム３０２からデータと共に構築されるＫストアに関連しないどのようなタグ、デリミッタ、およびフィールド名も削除するであろう。
【００６３】
続いて、入って来るデータは、コンポーネント３０７において、ストリーム内に存在するそれについてのすべてのメタデータの調査対象となるであろう。好適な実施形態のフィールド・レコード・データ・ストリームの場合、ユーザが識別し続けたいと望むフィールドは、ユーザがこのＫストアに対して期待するあるいは望むようになったそれらのうちのデータに対する位置関係におけるそれらの関連するメタデータを維持するであろう。Ｋストアにおいてこの新しいデータ・ストリームに関連した先行するデータ・ストリームからのフィールド名が、異なるフィールド名を備えた異なるデータベースから来た場合、その名前は、このコンポーネント３０７においてこの段階で変更されることが可能である。同様に、異なる種類のデータベースが先行するデータ・ストリームを使用してＫストアの生成において使用された場合、たとえば、フィールド名は、他のデータベースにおけるデータの前にではなく、むしろ後に来ることが可能であり、したがって、この配置は、データをルール化するためにこのコンポーネントで模倣されるべきである。違いを無視することによって同じＫストア内の関連する構造を生成することのような代案があるが、それは、この時点では、データ・ストリームをルール化する、あるいは、言い換えれば、データをクリーンにするのに効果的に思える。このデータ・クリーニングまたはルール化に対する制御は、ＧＵＩ  ３０４を通じて好ましくは得られ、そこでは、所望の設計的特徴３０５は、コンポーネント３０７に伝えられるであろう。
【００６４】
次に、コールの形態のＫエンジン３１０に必要な学習エンジンにおける最終コンポーネント３０８は、他のメッセージの特徴（つまり、現在の位置ポインタ）と共に、データをそれがどのような種類のパーティクルであるかを示す適切なポインタでパーティクルに単に分解し、このパーティクル自体を渡す必要がある。
【００６５】
この時点で明らかなはずであるように、また、これらの分野の試みにおいて読み手によって良く理解されるはずであるように、これらの機能およびコンポーネントのそれぞれは、ユーザが構築することが可能である特定のアプリケーションのための最も有用な形態を達成するのに、あるいはＫストアが置かれるであろうものに使用するのに望ましいようにコンピュータ・システムおよびネットワークに亘って分散することができる。
【００６６】
図４を参照して、学習エンジンが機能する一般化された処理３４０は、フローチャートの形態で図示されている。まず、データ・ソースは、学習エンジンに同期される３４１である。トランスポート機構を確立する様々なプロトコル機能、セキュリティの特徴などは、この段階で取り扱われる。プログラミング技術における当業者によって良く理解されるはずであるように、学習エンジンとデータ・ソースとの間の通信が滑らかに生じることを可能にするためにデータ・ソースと学習エンジンとの間の通信のためのプロトコルを確立する機構を有することが好ましいであろう。そのような副コンポーネントは、好ましくは中断なしにデータがデータ・ソースから学習エンジンに流れ込むことができるであろうように確立される信号機能を有するであろう。一旦、通信の同期のためのプロトコルが確立されたならば、データは、データ・ストリーム３４２において送信することができる。この時点では、データは、確立されたトランスポート機構を通じて受信することができる  ３４３。この時点で、Ｋエンジンのための適切なデータ列を確立することに関係のある学習エンジンの機能がステップ３４４で生じる。この段階３４４においては、データは、Ｋがそれを学習するフォーマットに編成され  ３４５、メタデータのほか、デリミッタおよび他のプロトコルあるいは特徴が必要に応じて調節されるであろう  ３４６。この時点では、データ・ストリームは、パーティクル化の準備ができている  ３４７。同様に、データ・ストリームのフィールド／レコード領域に対して、フィールド・ヘッダあるいはレコード数の指標のようなデリミッタおよび他のメタデータが通常はパーティクル化されるであろうことを注記しておく。これは、オリジナル・データの構造についての知識がそのデータと共に学習されることを可能にする。この形態におけるそのようなパーティクル化は、好ましいが、必要ではない。一般に、それが学習エンジンによってパーティクル化のために取り扱われ、および／または再編成されるときに、サーバ・システムのデータ記憶装置が、入って来るデータ・ストリームを保持するために使用されるであろうことが理解されるであろう。
【００６７】
新しいパーティクルを効率的に処理するために、特に特定のノードからの枝があるテーブルを確立するために、学習エンジンは、それが次のパーティクルを備えたコールのための次のメッセージを生成しているときに最後の位置として、最後の位置に対して前の位置ポインタを提出することが可能であることを注記しておく。これを理解するために図８を参照のこと。「ビル  月曜日」とラベルを付けられたノードでは、「ビル  月曜日」をＣａｓｅ定義として使用して、それに続く２つの副コンポーネント・ノードがある。それらは、１０３あるいは１００のノードのいずれかを追加する。これは、枝と呼ばれる。それがそのような枝を有すると学習エンジンが知る場合、それは「ビル  月曜」ノードに位置ポインタを保存することが可能であり、また、それがノード１０３あるいは１００の２番目を供給しているときにそれを再供給する。
【００６８】
パーティクル化に関して明らかにするために、図９を参照する。このＫにおいては、それは、文字のレベルから開始し、単語の第２のレベルを示すことを注記しておく。文字がすべて「センサ」である場合、すなわち、それらがＫの継続した成長を可能にする各々の新しい文字を追加するパーティクルとして認識することができる。「ＣＡＴＳ」「ＡＲＥ」「ＦＵＲＲＹ」の順番の３つの単語のデータ・ソースによる提出。このＫは、文字をパーティクルとして受け入れる。したがって、そのための学習エンジンに接続するＡＰＩユーティリィティは、パーティクルとして文字を作り出さなければならない。最初のパーテ
ィクル（あるいはパーティクルのための「ノード」）は、それが「思考の始め」の最初のパーティクルであることを述べるポインタによって位置を判定された「Ｃ」である（つまり、これは、ＢＯＴと呼ばれるノードで初期の新しい考えとして開始し、その最初のパーティクルは、Ｃである（それがＢＯＴパーティクルあるいはノードで開始されたものと仮定して）。次のパーティクルは、Ａであり、それは、先行するＣへのポインタを伴うであろう。（そのようなパーティクルは、それらがノードから構成された連動ツリー・データストアであるＫストアにおいて「完全な思考」「ＣＡＴ」の副コンポーネントであるときに「副コンポーネント・ノード」と呼ばれることもできる）。Ｋエンジンは、ａｓＣａｓｅリストを検討し、そして、ａｓＣａｓｅリスト上の副コンポーネント・ノードのそれぞれについて、および、各ノードについて、それは、それが一致するか否かを見るために、および、現在の、位置ポインタをリセットするためにそれの副コンポーネントを使用するために結果ノードを見るであろう。この場合、それは、一致を見つけておらず、したがって、Ｋエンジンは、ＢＯＴ  Ｃ−Ａ、新しい副コンポーネント・ノードとしてこのイベントを記録し、オリジナルの位置カウンタのａｓＣａｓｅリスト上にこの新しい副コンポーネント・ノードを置くであろう。その後、新しい副コンポーネントのアドレスは、新しい現在の位置として設定されるであろう。より正確には、Ｋエンジンは、現在の構造においてＣに続くＡの発生がなく、新しいノードがＢＯＴ  Ｃ−Ａとしてこのパーティクル・イベントを記録することを要求されるであろうことを理解するであろう。次のパーティクルは、Ｔになり、レコードは、ＢＯＴ  Ｃ−Ａ−Ｔになるであろう。したがって、この特定のＫについては、パーティクルが文字になるであろうことは明らかであるべきである。
【００６９】
我々の好適な実施形態の学習エンジンにおいては、我々は、所定のセンサ情報に応じるためにストリップし、加算および／または変換した後で、入力データ・ストリームのデータのサイズを一般に低減し、それは初期のセットアップ処理を通じて学習エンジンに利用可能であろう。学習エンジンは、その関連する記憶領域において維持され、Ｋストアおよびそれが一緒に動作するＫエンジンと共に学習エンジンの機能をセットアップするユーザあるいはプログラマにアクセス可能である１セットのスイッチで確立されるべきである。これらのスイッチは、それが一緒に動作するデータ・ソースから予期されるデータ・サイズに関するデータを有するであろう。これは、プロトコルを確立するステップで取り扱われることもできる。どのような場合であっても、そのようなアクティビティの目的は、Ｋエンジンおよびそれと一緒に動作するＫストアが受け入れるであろうという前記所定のセンサ情報に一致したパーティクルのサイズで終わるということである。
【００７０】
ＡＰＩユーティリィティ
ＡＰＩユーティリィティの機能は、学習エンジンの機能よりも少し複雑である。クエリを取り扱う一般化された処理３５０がフローチャートとして図示された図５をまず参照する。アプリケーション３５１（あるいはユーザによってアクセスされているＧＵＩ）は、結果を求めるように形成されたクエリＱを提供する。このクエリＱは、ＳＱＬフォーマット、あるいはたとえば自然言語のように分析することができる任意の他のフォーマットであることができるであろう。例は「何かＰＡにおいてビルによって販売されたか？」であることが可能である。（クエリは、我々が尋ねているＫにおけるこの瞬間の時点においてそれが尋ねていると仮定する。）
このクエリが尋ねられることができるであろう小さなＫ構造についての図に関しては図８を参照のこと。ここで、我々は、「販売」要素ルートノード１００８が要素ルートノード「ビル」１０２０（つまり、ノード１００２）によっても指し示されるレコードにあり、ＰＡ１０３５のための要素ルートノードによっても指し示されるノード１０３６と同じレコードにあるノード１０２６を指し示すことを理解するであろう。したがって、クエリの要素をすべて見つけて、我々は、そのようなクエリに対して「Ｙｅｓ」を返すことができるであろう。
【００７１】
クエリＱが理解されないか、あるいはそうでなければ誤っている場合、フィードバック機構が、アプリケーションあるいはユーザにクエリを改めて明確に述べるように依頼するために設けられることが可能である。
【００７２】
したがって、我々が好適な実施形態において取る次のステップは、図５のアプリケーション層ソフトウェアインタプレタ３５２を有すること、およびもし要求されればフィードバックまたはエラー信号を提供することであろう。一旦、クエリが確立されれば、クエリのコンポーネントを確立する必要がある。その質問に対して「何かＰＡにおいてビルによって販売されたか？」と単に尋ねる。我々は、それらにビルを有する図８のＫにおけるレコードをすべて見つけ、それらにおいて販売したもののほか、それらの中にＰＡを有するものをフォーカスにする必要がある。何らかのそのようなレコードがある場合に、肯定的な返答が整えられ、そうでなければ否定的な返答が整えられる。図８においては、ビルを備えた３つのレコードがある。１つが月曜日、２つが火曜日である。したがって、クエリの最初の部分は、ビル１０２０のための要素ルートノードからのポインタからアドレスを得て、ＡＰＩユーティリィティのメモリにおいてそれらを確立して、それらにおいてビルを備えたレコードをすべて求め、次に、ビルのためのレコードへのポインタをすべて得ることによって、コンテクストを完成するであろう。クエリの次の部分は、要素ルートノード「ビル」によって指し示されたレコードへのすべてのポインタのために集められたポインタによっても指し示される、要素ルートノード「販売」からのポインタをチェックするであろう。これらのうち、要素ルートノード「ＰＡ」へのポインタは、前のステップにおいて既に限定されたレコードへそれらのうちのいずれかが指し示されたか否かを確かめるためにチェックされるであろう。この結果、そうでなければ、ｎｕｌｌ集合は、肯定的な返答を示すであろう。
【００７３】
上記のこれらの手順は、クエリのコンポーネントの位置特定および取り出しコール３５３への分解を含んでいる。基準レベルでは、クエリは、現在の位置ポインタを介したＫへの経路を見つけ、あるいは、それがｎｕｌｌの場合に、ＢＯＴに設定されるＫストア・エンジンへのコール３５６に分解される。求められたノードが副コンポーネント・ノード、最終生成物（あるいはレコードの終了）ノード、あるいはＢＯＴノードである場合に、ポインタのリストを含むことが可能であるアドレスへの任意のポインタと共に、それらが存在するか否かを見つけて、それは、情報を整理し、クエリＱが満たされるまで付加的なクエリを行なうＡＰＩユーティリィティへのこの情報を返す。ＡＰＩユーティリィティは、処理３５５における他のアドレスあるいはルートノード・データから構成される情報を取り出すために、コンピュータ・システム・メモリにおけるアドレスへ直接行くことが可能である。ＡＰＩユーティリィティは、テーブル構造３５７にその結果（取り出された情報をそれが取り扱うために生成すること３５４）を適用する。応答が完了したとき、それは、使用されたクエリ言語の返答として送信するためにフォーマットされる３５８が、それが完了するまで、ＡＰＩユーティリィティは、Ｋストア・エンジンにコールをし続ける。クエリが完了したとき、フォーマットされた応答は、アプリケーションに送信することができる３５９。
【００７４】
クエリ。
利用可能なクエリには無限の範囲があるが、我々は、例の目的のためにいくつかの基礎的なものの記述から始め、そして、例示および理解の容易さのために、データがテーブル化されたＫを使用する。データ・セットは、５個のフィールドから構成される１５個のレコードからなる。この例示においては、各フィールドは、２個の考えられ得る値を有している。これらのレコードの例は次のとおりである：
ビル  火曜  １００個  販売        ＰＡ
ビル  火曜  １００個  販売        ＰＡ
ビル  火曜  １００個  販売        ＰＡ
ビル  火曜  １００個  販売        ＰＡ
ビル  火曜  １００個  販売        ＰＡ
ビル  火曜  １００個  販売        ＰＡ
ビル  月曜  １０３個  販売        ＮＪ
ビル  月曜  １００個  トライアル  ＰＡ
ビル  月曜  １００個  トライアル  ＰＡ
ビル  月曜  １００個  トライアル  ＰＡ
トム  月曜  １００個  販売        ＰＡ
トム  月曜  １００個  販売        ＰＡ
トム  月曜  １０３個  トライアル  ＮＪ
トム  月曜  １０３個  トライアル  ＮＪ
トム  月曜  １０３個  トライアル  ＮＪ
したがって、最初のフィールドに対する２個の変数は、トム、ビルであり、２番目に対しては、火曜、月曜、などである。上記のデータは、学習エンジンを通じてパーティクル化され、Ｋストアを構築するために使用される場合、図１１におけるものと同様のＫストアを生成し、ＡＰＩユーティリィティは、その処理を許容するであろう。
【００７５】
単純なクエリは、データ・セットにおけるフォーカスの変数の確率を見つけるか、あるいは演算することであり、対象変数の発生数および次にレコードの総数をまず返すためにＡＰＩユーティリィティにコールするアプリケーションによって達成されるであろう。クエリは、バックグラウンド・アプリケーションあるいはＧＵＩアプリケーションによって処理することができるであろう。（この処理がＧＵＩに組み込まれることになっている場合には、もちろん、ドロップ・ダウン・ボックスは、単一のドロップ・ダウン・ボックスからの制約変数およびフォーカスの変数の選択のために供給することができるであろう。ドロップ・ダウン・ボックスは、アイテムのリストのディスプレイ・スクリーン上の表示を記述する共通の用語である。選択されたアイテムだけが、図に示されている）。クエリは、バックグラウンド・アプリケーションあるいはＧＵＩアプリケーションによって処理することができるであろう。
【００７６】
この操作は、上記の図表におけるレコードをＫストアを表わす図にインポートする図１１において容易に見ることができる。（実際のＫストアは、コンピュータ・システムのメモリ内にあり、その接続はすべて、ポインタであり、そのノードは、何らデータまたはストリングを含まず、そのストリングは、読み手にＫストアを知覚可能にするためにノード上に示されている。）ここで、カウンタ・データは、各ノード楕円内に示されている。したがって、我々が、ビルが販売した月曜のビルのレコードの数を見つけることに制約されている場合、その答えは、ビル−月曜レコード上の「販売」ノードにある、つまり、そのようなレコードは、１個だけしかない。我々がすべてのレコードに対するそのイベントの確率を知りたい場合、我々は、月曜日のビルに対するこの１個の販売レコードがこのＫストアにおいて１５分の１の確率を有していることを見つけるために、ＥＯＴ要素ルートノードにおけるカウンタを見つける（あるいは、個々のＥＯＴノードすべてにおけるカウンタを加算する）であろう。これが、いかなるテーブルへの参照なしに、データの特徴づけ、あるいは再編成する必要なしに、およびこれらの種類の答えを得るためにどのようなデータあるいはそのどのような部分集合も再コンパイルする必要なしに、なされることを再び注記しておく。この１５個のレコードのフィールド／レコード領域のＫストアのような単純なＫストアにおいては、その達成は、些細なもののように見える。例外を見つける他のクエリ（つまり、一度だけしか生じないレコード）、あるいは現在のイベントが固有なものであることを知ることも、些細なもののように見えるであろう。しかしながら、今日のビジネスおよび政府および医療の業務において共通のずっと大きなデータ・セットのコンテクストに入れられるときには、時間の節約およびリソースの使用の効率のための結果は、現時点では計り知れないものになると考えられる。
【００７７】
上記のデータ・セットの１５個のレコードにおける変数「販売」には、９回の発生がある。アプリケーションが対象変数として変数「販売」を指定し、変数「販売」の事例の数を返すためにＡＰＩユーティリィティにコールした場合、ＡＰＩユーティリィティは、Ｋストア構造における「販売」のためのノードの位置を特定し、「販売」のための最終生成ノードから９のカウンタ値を返すであろう。（この図１１は、このフィールド／レコード領域のための変数のための最終生成ノードよりも下には何も示していない）。次に、アプリケーションは、レコードの総数のためにＡＰＩユーティリィティにコールし、ＥＯＴノードから１５のカウンタ値を返すであろう。その後、そのアプリケーションは、すべてのレコードにおいて、フォーカスの変数「販売」の確率を９／１５＝０．６＝６０％と演算するであろう。
【００７８】
それは、これがどのよう機能するかについてのこの非常に限定された例から十分に明らかであるが、そのデータのための構造がＫストアに組み込まれるときに、システムにおいて内在する能力を見るのはより容易である。（このレベルに対して）の場合、ビル、トム、月曜、火曜、および販売（同様に、上の図表におけるセットの他の変数のそれぞれに対する１つ）のための最終生成ノードは、この構造から構築されるＫストアに存在している。ほとんどの好適な実施形態においては、そのような最終生成ノードのそれぞれは、その最終生成ノードのためのカウンタにおいて残存する、ビルのイベント数、あるいはトムのイベント数などを有するであろう。したがって、クエリに答えるために、人は、合計を得るために１５個のレコードに対して１５を有するであろうレコード（ＥＯＴ）カウンタの数を見ることが必要なだけであり、次に、上で尋ねられた質問に内在するクエリに答えるために必要な値を得るためにフォーカス「販売」最終生成ノードを捜すであろう。
【００７９】
ＧＵＩディスプレイ２０００がコンテクスト選択領域２００１およびフォーカス選択領域２００４を有しているとき、基本的なＧＵＩがどのようなものであるかを見るためには図１０を参照する。この例において、列変数は、コンテクストあるいは制約であり、ユーザは、ドロップ・ダウン・リスト２００２における「ビル」、およびドロップ・ダウン・リスト２００３における「火曜」の２個を選択している。出力変数２００４におけるドロップ・ダウン選択からユーザによって選択されたフォーカスは、「販売」である。答えは、領域２００５において示され、選択された変数についての付加的な詳細は、領域２００６にある。実行ボタン２０１０がクリックあるいは作動されたとき、ＧＵＩアプリケーションは、制約を処理するためにＡＰＩユーティリィティにコールするであろう。ＡＰＩユーティリィティは、「ビル」および「火曜」の両方を含むそれらのレコードだけのリストを生成するためにＫをくまなく調べ、カウントを返すであろう。次に、ＧＵＩアプリケーションは、そのフォーカスを処理するためにＡＰＩユーティリィティにコールするであろう。変数「ビル」および「火曜」の両方を含むリストあるいはレコードが確立されているので、ＡＰＩユーティリィティは、「販売」レコードのカウントを判定するためにＫにおけるこのレコードのセットだけをくまなく調べるであろう。
【００８０】
トレンド分析は、制約として月のような時間を使用する一連の単一変数予測である。したがって、我々が例のデータを月フィールドの１日を含むように拡張し、ひと月をまるごと含むデータ・セットを有している場合には、我々は、その月の日に亘る販売数を報告し、その結果の傾向を報告することができるであろう。そのような場合には、トレンド分析を行なうスレッドのためのアプリケーション・メモリは、中間結果を保持し、その分析のために選択された時間的制約内の全体の結果からのトレンドを生成するための処理を有するであろう。中間結果は、たとえば、上述したようなアプリケーションにおける単一変数予測機能によって得られるであろう。トレンド分析機能をサポートしたこのアプリケーション全体は、時間的制約のためのドロップ・ダウン・リストのほか、単一変数予測のために上述した他のドロップ・ダウン・リストを有したＧＵＩを通じて選択することができる
であろう。
【００８１】
好適な実施形態においては、我々は、典型的なＫストア・システムに対する２種類のＡＰＩユーティリィティ・コンポーネントを有している。１つは、管理ＡＰＩユーティリィティ・コンポーネントであり、スイッチ、状態変数を設定すること、データ・ソースを指定すること、メタデータを修正すること、あるいは管理上の性質についての他のことを行なうことによって、ユーザあるいはプログラムに様々なシステム・コンポーネントを修正することを可能にする保守、開始、および変更機能サポートである。これらの設定は、たとえば、そのセンサ・リスト上にあることが可能であるパーティクルに応答するＫエンジンの機能を制御することが可能である。そのような１つの例は、Ｋエンジンがデータのフィールド／レコード領域に応答することが予期される場合に、デリミッタとして或るパーティクルを指定することであろう。それらは、ユーザがシステム内の単一のあるいは複数のＫストアにアクセスする第２のＫエンジンを起動することを可能にするであろう。このように取り扱われることが可能である別の機能は、形態の確立であり、特定のクエリ・ソースからの入力データ・ストリームあるいは１セットのクエリにおけるメタデータを意味することである。この管理ＡＰＩユーティリィティの種類は、特定のＫストアに名前を付けるために、それらを長期記憶装置に保存するために、それらをアクティブなシステム・メモリに返すために、要するに、システムのコール操作あるいはクエリの解を渡すパーティクル・メッセージによる実際のパーティクル以外のいかなる機能も達成するために使用されることが可能である。この管理ＡＰＩユーティリィティの好適な実施形態の例示は、図６Ｂにおいて描写されている。他のＡＰＩユーティリィティの種類は、クエリに使用され、図６Ａにおいて図示されている。
【００８２】
図６Ｂにおいて、Ｋストア・システムにおいて処理を調節あるいは開始する必要のあるユーザまたはアプリケーションは、インタフェース３６１Ｂを通じて、関与する状態変数にアクセスするであろう。実際、我々がここで記述するＫストア・システムの構築者あるいはユーザは、彼が望むアプリケーション層におけるほぼどのような種類のインタフェース構造も構築することが可能である。アプリケーション層１６における唯一の重大な要求は、それがＫエンジン、Ｋ構造および関連する記憶領域にアクセスするために複数のルーチンを提供するＡＰＩ  ３７２Ｂのようなインタフェースを通じて通信するということである。人は、アプリケーション層コンポーネントの配置が、考慮中のシステムのためのそれらを適切に解釈して、必要に応じてこれらの要求を処理するであろうスイッチ・ハンドラを含むであろうと期待するであろう。たとえば、システムが、与えられたセットのスレッドのためのＫエンジンあるいはＫエンジンとＫストアとの組み合わせの事例に設定されるいくつかの数の異なるデフォルト設定で確立される場合に、ＧＵＩあるいは他のインタフェースを通じた単一のコマンドは、ユーザのあるいはアプリケーションのニーズに最も適切なデフォルトを選択するために使用されることが可能である。したがって、アプリケーションは、ＡＰＩユーティリィティ・セグメント３７２Ｂへのこの状態変数のセットの通信を取り扱うであろう。それは、Ｋエンジン・メモリ３７６ＢあるいはＫにおいて（および／またはＫの関連する状態メモリ（図示せず）において）状態変数などに適切な変更を加えるであろう。
【００８３】
さらに、図６ＢのＡＰＩユーティリィティの管理ルーチンもまた（好ましくは）、Ｋエンジンをインスタンス化し、一または複数のＫストアにおいて使用される基本パラメータをセットアップする際にコールされるであろうこと、および、このＫエンジンのインスタンス化が、Ｋ構造を構築および／またはアクセスする際にコールされるであろうことを注記しておく。送信／受信副コンポーネントと一緒にユーティリィティ・セグメントは、Ｋエンジンインスタンス化オブジェクト（ここでは、システム・コンポーネント・ジェネレータ３８９として図示されている）とコンタクトを取るために必要とされるアドレスおよび他の情報を有するであろう。このインスタンス化処理においては、パーティクルにおけ
る何のデータがデリミッタとして定義されて動作するか、学習スイッチがオンあるいはオフであるか、およびすべての関連する構成変数のようなメタデータが確立されるであろう。これを行なう莫大な数の方法があるように、Ｋストア・システムについての理解がここに伝えられた後、プログラミング技術の当業者の読み手は、過度の実験なしに、また、比較的少ないプログラミングの努力あるいは思考で、そのような方法を実施することができるであろう。
【００８４】
図６Ａは、クエリなどを取り扱うＡＰＩユーティリティー・ソフトウェア・オブジェクトへのアクセスを図示している。再び、アプリケーション層におけるほぼすべてのアイテム３６１Ａは、それらがＡＰＩ（ここでは、ＡＰＩ  ３７２Ａ）によって提供される１セットの接続あるいはアドレスを通じて通信する限り、システム設計者によって自由自在に構成されることが可能である。ユーザまたはアプリケーションは、ＧＵＩあるいは他のインタフェースを通じてクエリを処理するためにアプリケーション層におけるそのようなコンポーネントを使用するであろう。インタープリタは、クエリを解釈するために有利に提供され、クエリを理解あるいは把握するために必要とされる場合にはフィードバック（図示せず）を送信することが可能である。構文解析ツールは、ＡＰＩユーティリィティのこの事例がクエリを取り扱うために有しているアルゴリズムに関するクエリの性質を判定するために使用することができる。それは、それが使用するであろうＡＰＩユーティリィティ（つまり、図７の複数のＵ）がいずれかであるかを選択するであろう。クエリは、場合によってはクエリ部分フォーミュレータによってその構成部品に分解されるべきである。これらのクエリ部分は、Ｋ構造における位置を特定するか、Ｋ構造に直接アクセスするか、あるいはＡＰＩユーティリィティ空間内の適切なメモリを更新するために、送信／受信副コンポーネント３６７Ａを介してＫエンジン３６８Ａにコールするであろう、３７２Ａにおける関連するＡＰＩユーティリィティ・コンポーネント・ルーチンにコールするであろう。Ｋエンジンは、送信されるものがセンサ・リスト上にあるか、それに応答する方法などを判定するために、それ自身の関連するメモリ３７６Ａを見るであろう。他のルーチンは、ＡＰＩユーティリィティの領域３６６におけるメモリを調整するように、また、各クエリ部分に応答する返された位置情報を分析する準備ができた状態で動作する。これらの他のルーチンは、指定された副コンポーネント・メモリ・コーディネータ／アナリスト３６６であり、クエリ・スレッドを取り扱うメモリ、スレッド・メモリ３６９における関連するデータを記憶および取り出すように動作する。ＡＰＩユーティリィティは、先のコール（つまり、コールに応答してＫエンジンによって返される現在位置カウンタ）によって生成された前の位置情報のレコードを維持することが可能であり、それは、それがコンテクスト内の対象変数のカウントのようなより高いレベルの情報を見つけさせる必要がある現在のコールを処理するための前の位置情報を使用して新しいコールに戻ることができる。コーディネータ・アナリスト３６６は、それがそのスレッド・メモリに記憶しているころが可能であり、また、クエリへの答えを生成するために応答コンフィギュレータ  ３７７によって必要とされる最終結果を生成することが可能である前のコールから前に取り出された情報を調整することもできる。
【００８５】
図１０に関する議論、単一変数予測クエリをセットアップするためのＧＵＩの例示と共に、たとえば上記の単一変数予測の議論を参照のこと。図６Ａのクエリの部分の形成および生成に関連して、テーブルが生成される必要がある場合があり、クエリＱによって開始されたスレッドを使用可能にすることを特定用途とするスペース、したがって、メモリ・コーディネータ／アナリスト３６６における処理によるスレッド・メモリへのアクセスが供給される。応答は、クエリが最初に理解されるときに使用されたクエリについての既知の情報に基づいて構成される。ＡＰＩユーティリィティの副コンポーネント３７７は、システム・メモリから取り出され、テーブル・ハンドラによって操作されたＫストア・ポインタおよび／またはデータへの参照によるシステム・メモリから直接取り出された情報に基づいて応答の構成を準備するであろう。送信／受信区間３６７Ｂは、Ｋエンジンと通信
する。
【００８６】
Ｋストア・システムのＡＰＩユーティリィティ・コンポーネントが学習エンジンの環境を管理することを注記しておく。したがって、好適な実施形態においては、我々は、ＫストアおよびＫエンジンの性能特性、状態、関連するトリガなどを修正するために特別な構成（図６Ｂの議論において詳述されたような）においてＡＰＩユーティリィティを使用する。これを行なう最も一般的なアプローチは、ＫストアあるいはＫエンジン、あるいは関与する任意の特定のものに関係するスイッチの状態を修正することである。ＧＵＩモードにおいて、それは、プルダウン・メニュー、アイコンあるいは同様のインタフェース要素と共に動作することができるかも知れず、それらのうちの多くは、周知であり、それらのうちのいずれかは、そのタスクに良く適していることがある。Ｋエンジンの状態の或る変化を自動的にセットアップする必要があるアプリケーション・プログラムは、さらに、伝統的なソフトウェア技術を通じてＡＰＩユーティリィティ・コンポーネントにコールすることによっても、そのようにすることができるであろう。
【００８７】
さて図７を参照して、そこでは、詳細なブロック図は、Ｋストアがこの発明の好適な実施形態に応じて使用および構築することができる多くの潜在的な方法を描いている。Ｋストア７１は、サーバ・コンピュータ・システム７３内にある。サーバは、任意の種類の多目的コンピューティング・システムであることができ、我々が使用したものは、複数のパーティションを可能にするマルチプロセッサ・システムである。データストア７４は、容易なアクセスのためにそれに好ましくは緊密に接続された任意の種類のデータ記憶システム、あるいはコンピュータ・システム（あるいはサーバ）７３の一部であることできる。それは、Ｋストアの特定の使用に必要とされることがあるようなバックアップ、アクティビティのログあるいは他の機能を維持するために使用することができ、あるいは、それは、コンピュータ・システム７３の他の機能をサポートすることができる。Ｋエンジン７２は、上に詳述されたようなＫストアへの必要とされるアクセスを提供する。上述したように、Ｋエンジン自体へのアクセスは、学習エンジンを通じた、あるいはＡＰＩユーティリィティを通じたものである。この例においては、我々は、部分に分解されたＡＰＩユーティリィティを有しているが、学習エンジン９９は、分解されていない。一般に、各データ・ソースのための単一学習エンジンが存在するであろうが、各学習エンジンは、Ｋストアにソースからデータをもたらすための単一のリアルタイム・アクセス設備として作用し、同時に、Ｋストアは、ユーティリィティ９８によってクエリを行なうことができるであろう。
【００８８】
ここでは、我々は、いくつかの異なるデータ・ソースの種類を図示しており、それらのいずれかは、Ｋストアを構築するために使用することができる。どのような速度が望まれてもパーティクルにおいてそれを生成することができ、フォーマットが必要ではないので、最小限の変更はテストのためのデータを生成するシミュレータ７５に必要である。（それがパーティクルを生成する場合、それは、学習エンジンの特徴の少なくともほとんどを組み込むであろう。それにデータを生成させ、データをパーティクル化するために学習エンジンにデータを送信させるほうが簡単である。）データベース７６は、データ・ソースであることもできる。クエリ８７のようなデータベースのクエリなどを通じてデータを取り出す様々な方法が使用されることが可能である。ＸＭＬあるいは他の出力書式８８が、データ・ストリームを学習エンジン９９に転送するプッシュ・エンジン８９に在来のクエリ・フォーマットからデータを転送するために使用されることが可能である。別のデータ・ソースは、転送エージェント（スレッド）８６を通じて学習エンジン９９にそのデータを提供するフラット・ファイル７７であることができるであろう。コンピュータ入力端末７８は、エージェント（あるいはスレッド）８５からの入力を可能にする。さらに、センサからの直接入力は、学習エンジン９９にデータ・ソースを提供することができるであろう。
【００８９】
クエリ側は、少し複雑である。ＡＰＩユーティリィティは、Ｋエンジンへのコールを取り扱い、クエリを満足するために個別のコールを編成するために必要であることがあるアドレスのリストを追跡するデータストアへのインタフェースを提供するユーティリィティ部分９８（Ｕ１−Ｕｎ）である。Ａセグメント９７は、特定の（特有のあるいはあらかじめ準備された）クエリ９３によって選択されるように提供される１セットの分析アプリケーションであることができる。これらのクエリは、解に特化したスクリーン９２を通じて、あるいはアクセスの任意の手段を通じて直接的に、ユーザによって選択あるいは構築される。ＡＰＩユーティリィティにおいては２種類のＵ部分がある。Ｕ２およびＵ３がＫ７１に直接接続することを注記しておく。これは、ＡＰＩユーティリィティがＫに直接アクセスすることが可能である機能性に注意を促すように引き出される。パーティクルおよび現在の位置ポイントを含んでいるＫエンジンへのＡＰＩユーティリィティのコールは、最小のレベル（つまり、「ビル」）でのシーケンスのための最終生成ノードを見つけるために使用される。一旦、「ビル」の最終生成物のための位置カウンタが見つけられると、他のＡＰＩユーティリティ・ルーチンは、直接Ｋ構造をくまなく調べ、クエリ（つまり、現在の位置ポインタのａｓＲｅｓｕｌｔリストにおけるノード・ポインタのセットである、「ビル」を含むすべてのレコードのリスト）を処理するために必要な他の情報の位置を特定するためにそれを使用するであろう。
【００９０】
管理サービス９５は、センサ・セット、デリミッタおよびレベルなどを判定することを含むＫをセットアップする方法を提供する。管理サービス９５は、ＧＵＩの形態、設定トリガ、メタデータ、フィールドおよび列名、要するに、Ｋストアの使用を管理およびセットアップするために必要とされるものすべてをセットアップするために、他のスイッチを制御する方法を提供することもできる。特定のトリガ９４は、特定のイベントの発生に際して、イベントが発生したそのトリガの所有者に通知するために電子メール８３を送信するような特定の動作を行なうであろうユーザあるいはアプリケーションの所定のお決まりのクエリを参照する。（これらのイベントは、トリガに生成された信号で行なうことができるものでの読み手の想像によってのみ制約される任意のイベント、信号、あるいはアクチュエータの動作などであることができるであろう。）外部トリガは、指定された時間間隔で特定のクエリを開始するために個別のスレッドをセットアップすることによって好ましくは機能する。その後、これらのクエリの結果は、前に定義された境界に対して比較することができる。境界に到達する（あるいは新しいイベントが発生するか、あるいは或る種類のイベントが発生する）場合に、特定の動作が発生する。トリガは、クエリ・アプリケーションとして符号化され、管理サービスを使用してスイッチによってオンあるいはオフに設定することができる。ウェブ・サービスは、この層においてこれらの設備のうちのいずれかを使用するためにアプリケーション層８１にユーザ８４がそれを通じてアドレスすることが可能であるインターネット８２へのアクセスを提供する。
【００９１】
注記すべきは柔軟性および制御を提供する保守コンポーネントが存在することができることである。そのような保守コンポーネントは、ＡＰＩユーティリィティの１つの事例（あるいは複数）のようなソフトウェア・オブジェクトの形態であるであろう。図７においては、それは、管理機能およびそれとＫエンジンとの間の任意の介在する部分の形態を取る。Ｋストアの性質を定義するために含まれてもよい様々なスイッチは、それらが他のＡＰＩユーティリィティを通じて利用可能とすることができるであろうが、この保守コンポーネントのようなＡＰＩユーティリィティを通じてアクセスされると予想することができるが、そのような場合、この特定のＫストアへのアクセスを有する学習エンジンおよび他のＡＰＩユーティリィティを調整することに注意するべきである。図１Ｂの図示において、我々は、これらのスイッチが記憶領域２８ａおよび２８ｂに関連するＫエンジンあるいはＫストアに関連していることを教示するであろう。（「スイッチ」は、学習（ＹｅｓまたはＮｏ）、列番号（ＹｅｓまたはＮｏ）、列番号の代わりに使用されるメタデータ・フ
ィールド名（ＹｅｓまたはＮｏ）、ＥＯＴレベル（数および名前の）、ＥＯＴＣＯＬ（列名）、ＥＯＴＶＡＲ（変数）、ＥＯＴＦＬＤ（フィールド・エントリ）、ＥＯＴＲＣＤ（レコード）  のようなアイテム用であるであろう）。
【００９２】
トリガは、付加的な機能性を提供し、それらの設定の制御は、スイッチと同様の方法で取り扱われることが可能である。トリガは、いつその内部のデータが或る所望のポイントに達したか、あるいは、いつ特定の種類のデータが閾値などを超えたかを識別するためにＫストアを使用する強力な方法を提供することができる。多くのリアルタイムの分析アプリケーションは、いつ特定の条件がユーザまたはアプリケーションに判定あるいは提案をする際に一連の動作を開始するための知識ベースにおいて発生するかを監視する必要性を有している。我々の発明システムは、アプリケーションあるいはユーザがトリガ・イベントの発生に応答することができるように監視処理を容易にするイベント・トリガ機能を提供する。「イベント」として動作することができるいくつかの条件は、単に単純なパターン・マッチあるいは閾値チェックである。他のものは、結論を作成するために小さいプログラミング努力を要求する複雑な条件である。
【００９３】
我々の好適な実施形態におけるイベント・トリガ機能は、次の段落に記述された特性を特徴とする。
【００９４】
イベント（条件または発生を含むことができる）は、Ｋストア・スイッチ設定によって定義することができる。スイッチ設定（つまり状態変数）は、ちょうど上に記述したような保守ＡＰＩユーティリィティあるいは同様の容易化構造へのアクセスを有するユーザあるいはアプリケーションによって設定された構成設定に応答して、Ｋエンジンにハードコードすることができる。アプリケーションあるいはユーザは、通知を受信するように登録することができるか、あるいは、この登録されたユーザあるいはアプリケーションは、関与するイベントまたは条件を定義するスイッチを設定するものとは異なることができる。たとえば、変数の新しい値を受信し、変数（特定の変数あるいは任意の変数）の新しい値を受信する条件がこのＫエンジンのための設定トリガであるときには、Ｋエンジンは、登録されたアプリケーションあるいはユーザに通知するためにイベント通知を送信する。イベントは、特定のアプリケーションの登録であることが可能であるように、ユーザによって好ましくは定義される。基本イベント操作は、登録および通知である。アプリケーションあるいはユーザは、１セットの条件に基づいたイベントを受信することについてのそれらの関与を要求するために登録操作を使用することができる。登録処理は、さらに、それらがもはや必要でないときに、アプリケーションが要求を取り消す（あるいはそれらの登録を取り消す）ことを可能にする。迅速なイベント通知機構は、人が様々なプログラミング言語でシームレスに統合したい場合に有用である。言い換えれば、イベント通知機構は、アプリケーションにそのアプリケーションのネイティブ言語で取り扱うカスタム・イベントを追加する方法を好ましくは提供する。同様に、ユーザ・フレンドリなＧＵＩは、必要とされるスイッチ設定を容易にすることによってイベントおよび条件に専念するユーザの能力を増強するために使用されることが可能である。
【００９５】
このように、トリガがＫのためのグローバルな条件に適用される場合には、トリガ（および関連するスイッチ設定）は、図１Ｂにおける領域２８ａ、および場合によっては領域２８ｂのようなＫエンジンのための記憶領域に記憶されるであろう。好適な実施形態においては、Ｋエンジンは、イベントが「トリガされた」（発生した）ことを示すために新しいスレッドを開始する。通知は、この付加的なスレッド（それ自身の構成によって、その記憶領域２７ａにおけるデータの追加あるいは変更が可能であるＡＰＩユーティリィティ１９ａからのスレッドと見なされる、および／またはこの特定のスレッドを例示することに関連しているアプリケーションあるいはユーザに単に通知することができるであろう）を介して送信されるであろう。
【００９６】
トリガは、内部および外部の２つの形態でセットアップすることができる。内部トリガは、Ｋエンジンのスイッチ設定に依存し、それが生じるときにＫストアに発生するアクティビティに応答するスレッドを生成する。たとえば、パーティクルがセンサ・リスト上で見つからない場合、そのような条件では、与えられた正しいスイッチ設定は、恐らく監視アプリケーションへの通知を開始するトリガであるであろう。外部トリガは、（通常は）周期的あるいは一時的な時間でＫストアにクエリを行なうことによって動作するものである。周期的あるいは一時的は、トリガを確立するＡＰＩユーティリィティにおいて管理され、それは、Ｋエンジンにこのクエリを行ない、その結果をチェックする条件あるいはイベントがＫストア内に発生したか否かを判定するクエリを再度開始する。その結果に基づいて、それは、ＡＰＩユーティリィティにおいてトリガの条件が満足され、したがって作動するか否かを判定する。
【００９７】
内部トリガ・スイッチの部分的なリストは、新しい変数、新しいレコード、欠落変数およびログを埋めるもの、あるいは選択されたフィールドを確認するものであることが可能であるが、Ｋストアにおいて発生するイベントに基づいた多数の内部トリガは、読み手に対して発生するであろう。
【００９８】
この発明の無数の使い道を見つけることが可能であり、この発明の操作の形態および方法における著しい可変性が、記述され、これらの技術における当業者に生じるであろう一方で、本発明は、次の請求項において述べられるようなものよりもさらに制限されない。
【図面の簡単な説明】
【００９９】
【図１Ａ】この発明の好適な実施形態において使用される主コンポーネントの相互作用を図示するブロック図である。
【図１Ｂ】この発明の好適な実施形態において使用される主コンポーネントの相互作用を図示するブロック図である。
【図２】命令語フォーマットのメッセージのブロック図である。
【図３】好適な実施形態にかかる学習エンジンのブロック図である。
【図４】好適な実施形態の学習エンジンがデータをＫエンジンへ渡す準備をするために動作する典型的な処理のフローチャートである。
【図５】本発明の好適な実施形態にかかるＡＰＩユーティリィティのアプリケーション・クエリ取り扱い処理のフローチャートである。
【図６Ａ】好適な実施形態のＡＰＩユーティリィティ・コンポーネントのブロック図であって、ユーザおよびアプリケーションによる保守、初期化、および修正のための好適な実施形態に役立つ、より特殊なＡＰＩユーティリィティ・コンポーネントである。
【図６Ｂ】好適な実施形態のＡＰＩユーティリィティ・コンポーネントのブロック図であって、ユーザおよびアプリケーションによる保守、初期化、および修正のための好適な実施形態に役立つ、より特殊なＡＰＩユーティリィティ・コンポーネントである。
【図７】この発明の好適な実施形態にかかるワーキング・システムにおけるＫストア・データ構造のブロック図である。
【図８】図示例の目的に役立つ、連動ツリー・データストア（Ｋストア）におけるノードのブロック図である。
【図９】連動ツリー・データストアにおけるノードの別のブロック図である。
【図１０】本発明の好適な実施形態の一部を備えたあるいはその一部として使用するための単一変数予測ＧＵＩのディスプレイ・スクリーン・イメージである。
【図１１】連動ツリー・データストアにおけるノードの別のブロック図である。
【図１Ａ】
2008505390.tif 000002
【図１Ｂ】
2008505390.tif 000003
【図２】
2008505390.tif 000004
【図３】
2008505390.tif 000005
【図４】
2008505390.tif 000006
【図５】
2008505390.tif 000007
【図６Ａ】
2008505390.tif 000008
【図６Ｂ】
2008505390.tif 000009
【図７】
2008505390.tif 000010
【図８】
2008505390.tif 000011
【図９】
2008505390.tif 000012
【図１０】
2008505390.tif 000013
【図１１】
2008505390.tif 000014