(57)【要約】  ＫＳｔｏｒｅシステム内の情報送信方法であって、少なくとも一つのＫパスを有するＫＳｔｏｒｅと、アプリケーション・プログラミング・インターフェースと、アプリケーション・レイヤーとを備え、前記ＫＳｔｏｒｅおよび前記アプリケーション・レイヤー間の前記情報を送信し、前記アプリケーション・プログラミング・インターフェースを介して前記ＫＳｔｏｒｅおよび前記アプリケーション・レイヤー間の前記情報を送信することを含む、ＫＳｔｏｒｅシステム内の情報送信方法。ＫＳｔｏｒｅは、少なくとも一つの選択Ｋパスを提供するよう、少なくとも一つの制約を有するアプリケーション・プログラミング・インターフェースを経由して制約される。ＫＳｔｏｒｅは、さらなる選択Ｋパスを提供するためにフォーカスが当てられる。少なくとも一つのＫＳｔｏｒｅパラメータは、少なくとも一つの決定されたＫパラメータを提供するよう、選択Ｋパスに従って決定される。ＫＳｔｏｒｅを制約するステップは、少なくとも一つの選択Ｋパスを横断するステップを含む。【特許請求の範囲】
【請求項１】
ＫＳｔｏｒｅシステム内の情報送信方法であって、少なくとも一つのＫパスを有するＫＳｔｏｒｅと、アプリケーション・プログラミング・インターフェースと、アプリケーション・レイヤーとを備え前記ＫＳｔｏｒｅおよび前記アプリケーション・レイヤー間の前記情報を送信し、前記アプリケーション・プログラミング・インターフェースを介し前記ＫＳｔｏｒｅおよび前記アプリケーション・レイヤー間の前記情報を送信することを含む、ＫＳｔｏｒｅシステム内の情報送信方法。
【請求項２】
ＫＳｔｏｒｅが、複数のＫパスのうち少なくとも一つの選択Ｋパスを提供するために少なくとも一つの制約を持つ前記アプリケーション・プログラミング・インターフェースを経由して、前記ＫＳｔｏｒｅを制約するステップをさらに備える前記複数のＫパスを含む、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項３】
前記制約するステップが、一連の選択Ｋパスに従って、さらなる一連の選択Ｋパスを提供するために前記ＫＳｔｏｒｅにフォーカスを当てるステップをさらに備える一連の選択Ｋパスを提供する、請求項２に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項４】
少なくとも一つの決定されたＫパラメータを提供するために、前記選択Ｋパスに従って少なくとも一つのＫＳｔｏｒｅパラメータを決定するステップをさらに備える、請求項２に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項５】
前記ＫＳｔｏｒｅの前記制約するステップが前記少なくとも一つの選択Ｋパスを横断するステップをさらに備える、請求項２に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項６】
前記アプリケーション・プログラミング・インターフェースは学習エンジンをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項７】
前記アプリケーション・プログラミング・インターフェースは学習ユーティリティーをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項８】
前記アプリケーション・プログラミング・インターフェースを経由して、前記アプリケーション・レイヤーからの情報を要求するステップをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項９】
前記情報に従って、前記ＫＳｔｏｒｅに問い合わせるステップをさらに備える、請求項８に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項１０】
前記アプリケーション・プログラミング・インターフェースによるクエリーを受け取るステップをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項１１】
前記クエリーをクエリーコンポーネントに分割するステップをさらに備える、請求項１０に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項１２】
アプリケーション・プログラミング・インターフェースは、管理アプリケーション・プログラミング・インターフェースコンポーネントをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項１３】
前記ＫＳｔｏｒｅが、前記管理アプリケーション・プログラミング・インターフェース・ユーティリティー・コンポーネントによって前記ＫＥｎｇｉｎｅを開始させるステップ
をさらに備えるＫＥｎｇｉｎｅを含む、請求項１２に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項１４】
前記アプリケーション・プログラミング・インターフェースは、解析計算アプリケーション・プログラミング・インターフェース・コンポーネントをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項１５】
前記解析計算アプリケーション・プログラミング・インターフェース・コンポーネントによってＳｕｍＣｏｌｕｍｎプロセスを実行するステップをさらに備える、請求項１４に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項１６】
前記解析計算アプリケーション・プログラミング・インターフェース・コンポーネントによってＤｅｃｉｓｉｏｎＴｒｅｅプロセスを実行するステップをさらに備える、請求項１４に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項１７】
前記解析計算アプリケーション・プログラミング・インターフェース・コンポーネントによってＢａｙｅｓ分類プロセスを実行するステップをさらに備える、請求項１４に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項１８】
前記アプリケーション・プログラミング・インターフェースは、前記アプリケーション・プログラミング・インターフェース内のメモリ調整によって、メモリ調整されるステップをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項１９】
前記アプリケーション・レイヤーは、グラフィック・ユーザーインターフェースをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項２０】
前記アプリケーション・レイヤーは、情報源をさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項２１】
前記アプリケーション・レイヤー・アプリケーションによって前記アプリケーション・プログラミング・インターフェースを要求するステップと、
前記アプリケーション・レイヤーの前記要求に従い、前記アプリケーション・プログラミング・インターフェースによって要求処理スレッドを生成するステップと、をさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項２２】
前記要求処理スレッドによる使用のための前記アプリケーション・プログラミング・インターフェースによって情報記憶領域を割り当てるステップをさらに備える、請求項２１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項２３】
前記情報記憶領域を介して粒子関連情報の送信を制御するステップをさらに備える、請求項２２に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項２４】
内部ＫＳｔｏｒｅ情報が前記ＫＳｔｏｒｅから前記アプリケーション・レイヤーまで送信されないように防ぐステップをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項２５】
前記内部ＫＳｔｏｒｅ情報はポインタ情報を備える、請求項２４に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項２６】
前記内部ＫＳｔｏｒｅ情報はノード位置を備える、請求項２４に記載のＫＳｔｏｒｅシ
ステム内の情報送信方法。
【請求項２７】
エラー情報を処理するステップをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項２８】
アプリケーションのための前記ＫＳｔｏｒｅへのアクセスを認証するステップをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項２９】
前記アプリケーションのための前記ＫＳｔｏｒｅの一部へのアクセスを認証するステップをさらに備える、請求項２８に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項３０】
クエリー要求を認証するステップをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項３１】
データソース定義を認証するステップをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項３２】
前記ＫＳｔｏｒｅは、スタティックＫＳｔｏｒｅをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項３３】
前記ＫＳｔｏｒｅはダイナミックＫＳｔｏｒｅをさらに備える、請求項１に記載のＫＳｔｏｒｅシステム内の情報送信方法。
【請求項３４】
アプリケーション・レイヤーと、
前記ＫＳｔｏｒｅおよび前記アプリケーション・レイヤーに連結したアプリケーション・プログラミング・インターフェースであって、情報が、前記アプリケーション・プログラミング・インターフェースを経由して、前記ＫＳｔｏｒｅおよび前記アプリケーション・レイヤー間で送信される、アプリケーション・プログラミング・インターフェースと、を含む少なくとも一つのＫパスを備えたＫＳｔｏｒｅを有するＫＳｔｏｒｅシステム。
【請求項３５】
前記アプリケーション・プログラミング・インターフェースは学習エンジンをさらに備える、請求項３４に記載のＫＳｔｏｒｅシステム。
【請求項３６】
前記アプリケーション・プログラミング・インターフェースは学習ユーティリティーをさらに備える、請求項３５に記載のＫＳｔｏｒｅシステム。
【請求項３７】
前記アプリケーション・プログラミング・インターフェースは管理アプリケーション・プログラミング・インターフェース・コンポーネントをさらに備える、請求項３４に記載のＫＳｔｏｒｅシステム。
【請求項３８】
前記アプリケーション・プログラミング・インターフェースは解析計算アプリケーション・プログラミング・インターフェース・コンポーネントをさらに備える、請求項３４に記載のＫＳｔｏｒｅシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の背景
発明の分野
本発明は、一般に、アプリケーション・プログラミング・インターフェース（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅs：  ＡＰＩs）に関する。より具体的には、本発明はインターロッキングツリーズデータストアに含まれるデータ用に設定されるＡＰＩに関する。
【背景技術】
【０００２】
関連技術の説明
実質的に、ＡＰＩ（アプリケーション・プログラミング・インターフェース）は、そのプログラムを呼び出すことによるものであろうと、それによって呼び出されることによるものであろうと、別のプログラムによって提供された設備を一つのプログラムが使用することを可能にする一切のインターフェースのことである。高レベルにおいては、依然として、ＡＰＩはプログラミングシステムによって配信された一連の機能であり、そのようなものとして特定のシステムにおけるＡＰＩとの組み合わせは、そのシステムに何ができるかということを伝えてくれる。ＡＰＩは当技術分野で周知である。例えば、「メッセージングＡＰＩフレームワーク」という名称の米国特許第６，７６０，９１１Ｂ１号は、ＣＯＲＢＡベースのアプリケーションを備えたＭＱ  Ｓｅｒｉｅｓゲートウェイを介して、Ｃ＋＋アプリケーションが通信できるようにするための方法を開示する。充分な結果を生み出してはいるものの、使用されている方法はＫＳｔｏｒｅ技術には実用的ではない。
【０００３】
ＫＳｔｏｒｅ技術は、従来の関連データベースに付随する問題に対応している。「システムおよびインターロッキングツリーズデータストアにデータを保管およびアクセスするための方法」という名称の米国特許出願第１０／３８５，４２１号および「システムおよびインターロッキングツリーズデータストアにデータを保管およびアクセスするための方法」という名称の１０／６６６，３８２号に記載されているように、ＫＳｔｏｒｅデータ構造は、トランザクションのデータおよび保管（関連）データ間の差異を取り除くことができる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ＫＳｔｏｒｅ技術の開発に伴い、アプリケーション、データソースおよびＧＵＩをインターロッキングツリーズデータストアに接続するために、アプリケーション・プログラミング・インターフェースが必要となる。
【０００５】
ここに引用されるすべての参考文献は、参照することにより本書に全体が組み込まれる。
【課題を解決するための手段】
【０００６】
発明の簡単な概要
ＫＳｔｏｒｅシステム内の情報送信方法であって、少なくとも一つのＫパスを有するＫＳｔｏｒｅと、アプリケーション・プログラミング・インターフェースと、アプリケーション・レイヤーとを備えＫＳｔｏｒｅおよびアプリケーション・レイヤー間の情報を送信することを特徴とする、アプリケーション・プログラミング・インターフェースを介しアプリケーション・レイヤーおよびアプリケーション・レイヤー間の情報を送信する事を含むＫＳｔｏｒｅシステム内の情報送信方法。ＫＳｔｏｒｅは複数のＫパスを含み、複数の
Ｋパスの中の少なくとも一つの選択Ｋパスを提供するために少なくとも一つの制約を備えたアプリケーション・プログラミング・インターフェースを介して、制約されてもよい。制約は、一連の選択Ｋパスを提供し、ＫＳｔｏｒｅは、一連の選択Ｋパスに従って、さらなる一連の選択Ｋパスを提供することを目的とする。少なくとも一つのＫＳｔｏｒｅパラメータは、選択Ｋパスに従って、少なくとも一つの一定Ｋパラメータを提供するために決定される。ＫＳｔｏｒｅの制約は、少なくとも一つの選択Ｋパスの全探索を含む。
【０００７】
本発明は、特に「システムおよびインターロッキングツリーズデータストアにデータを保管およびアクセスするための方法」という名称の米国特許出願第２００４０１８１５４７号、２００５００７６０１１号、２００５０１６５７４９号および２００５０１６５７７２号に記載される種類におけるインターロッキングツリーズデータストアの柔軟性および使いやすさを拡張し、「アプリケーションソフトウェアとの併用を可能にするインターロッキングツリーズデータストア内にアクセスおよび／または構築するための機能操作」という名称の米国特許出願第１０／８７９，３２９号に見られる当該ＫＳｔｏｒｅデータ構造に組み込まれるシステム使用において特に適用性がある。これらの特許文献は、それぞれ全体で参照として本発明に組み込まれる。
【０００８】
先の特許文献は、学習およびクエリーのための様々なアプリケーションを備えたＫＳｔｏｒｅの使用を可能にするためのＫＳｔｏｒｅ構造およびシステムの両方を説明しているが、システムは、インターロッキングツリーズデータストアを崩すいずれかの異なるアプリケーションなしに、そしてインターロッキングツリーズデータストアの範囲内にアドレスロケーションを横断および返却する必要のあるプロセスの詳細な理解を有するためのアプリケーション開発者の必要なしに複数のアプリケーションプログラムの開発および実行を可能にさせるため、依然としてＡＰＩを必要とする。
【０００９】
このＡＰＩは、インターロッキングツリーズデータストアを構成、クエリーおよび維持するために、インターロッキングツリーズデータストアへの直接のアクセスを可能にするこれまでの復帰アドレスなしに、アプリケーションからインターロッキングツリーズデータストアエンジンへの要求を使用可能にする。
【００１０】
本発明はまた、ＫＳｔｏｒｅＩＤの認証や呼び出しルーチンがアクセスできるといった保護機能を提供することができる。本発明の発明者は、ＫＳｔｏｒｅおよびそれらのクエリーの使用を促進するために多数のプロセスが作成されるべきであると判断している。特殊な種類のクエリーを作成するこれらの機能オブジェクトは、システムにまとめられていた場合、必要に応じて一連の当該オブジェクトの中から個々に呼ばれる。我々はそれらを「機能カテゴリ」と呼んでいる。我々は以前にＫＳｔｏｒｅをサポートするためのシステムを説明し、この一連の機能カテゴリをサポートするためにそれ、もしくはその類のものを使用することを推奨する。
【００１１】
従って、特定の種類のクエリーに適した一連の当該機能カテゴリが作成され、新たな一連のものが、本発明において詳細に説明されるものを使用して作成される。これらの機能カテゴリが、特定の必要性のために様々な方法で定義されているため、我々もまたいくつかの特殊性をもって、好適な実施例ルーチン、および当該ルーチンのサブコンポーネントを少し詳しく説明する。
【００１２】
当業者が理解するように、最新技術パラダイムにおけるこれらの機能カテゴリは、ソフトウェアルーチンとして最良に実施されているが、当業者はまた、一旦当該オブジェクトが範囲内に記載のように説明されると、どのようにそれらが構築されるのかということに関する実験をせずに、当該オブジェクトが容易にハードウェア実行に変えられることを理解されたい。
【発明を実施するための最良の形態】
【００１３】
本発明は、類似の参照番号が類似の要素を示す以下の図と併せて説明される：
発明の詳細な説明
本特許の組織は以下の通りに分割される。最初のセクションは、そのようなシステムの所定インスタンスの詳細に応じて、発明の機能オブジェクトがセット、グループとしてまたは個々に実施可能となるための、好適な実施例ＫＳｔｏｒｅシステムを詳述している。この最初のセクションのほぼすべての説明は「アプリケーションソフトウェアとの併用を可能にするインターロッキングツリーズデータストアをアクセスおよび／または構築するための機能操作」という名称の米国特許出願第１０／８７９，３２９号においてすでに見られる。この項目はまた、我々が「機能カテゴリ」という用語および本発明を説明するための重要な他の用語をどのように使用するかを定義している。
【００１４】
第二項目は細分化される。四つの部分があり、それぞれ機能カテゴリを表し、それぞれにはこの機能カテゴリを実行すると説明された特殊な典型的ルーチンが存在する。特定の好適な実施例は、スムーズに機能する効率のよいクエリー応答システムを形成するために必要とされる機能の組み合わせが、これらの多くを、そしておそらくこれらの種類のいくつかもしくはすべてのうち未だ定義されていないものを有することが発見される見込みがあるにもかかわらず、これらの種類のうちの一つだけ、もしくはこれら一種類のうちの一つのみを使用することもある。
【００１５】
第一部―本発明に使用されるＫＳｔｏｒｅシステムの説明
本発明に使用される他の実行可能なシステム設定があるということは理解されなければならないが、好適な実施例において、ここに説明されたシステムが使用されていてもよい。
【００１６】
Ｋ  Ｅｎｇｉｎｅ  １１ａがＫ  １４ａの唯一の他との接続を提供する好適な実施例環境において、ＫＳｔｏｒｅ  １４ａを有するＫＳｔｏｒｅシステムを描いた図１を初めに参照する。ＫＳｔｏｒｅ  １４ａへのアクセスを提供する図示のＫ  Ｅｎｇｉｎｅ  １１ａと類似している、２つ以上のＫ  Ｅｎｇｉｎｅが存在する可能性があることもまた注記されなければならない。逆に、Ｋ  Ｅｎｇｉｎｅ  １１ａは、ＡＰＩユーティリティー５や、操作しているコンピューターシステム（図示せず）のリソースと相まってスレッドを管理および取り扱うＬｅａｒｎ  Ｅｎｇｉｎｅｓ  ６のようなエンティティによって対応可能である場合がある。本発明の好適な実施例において、Ｋ  １４ａによる学習を可能にするための学習機能は、学習エンジン６、学習ユーティリティーまたは他のＫＳｔｏｒｅシステムの領域において実行できる状態にある。ＡＰＩユーティリティー５およびＬｅａｒｎ  Ｅｎｇｉｎｅｓ  ６はＡＰＩ４の中にあり，それはＫ  １４ａおよびＡＰＩユーティリティー  ５およびＬｅａｒｎ  Ｅｎｇｉｎｅｓ  ６の間に情報を送信するためのアプリケーションスペース間で処理される。アプリケーションスペースは、データソース８またはクエリーアプリケーション７など、いずれのアプリケーションを含んでいてもよい。一つのパソコンがＫの実行の中で使用されることはあるが、通常、コンピューターシステムはサーバーとなる。
【００１７】
好適な配置において、外部のＫ構造へのアクセス、これらのＡＰＩユーティリティーおよびＬｅａｒｎ  Ｅｎｇｉｎｅを介してのみである。ＡＰＩユーティリティーおよびＬｅａｒｎ  Ｅｎｇｉｎｅは、従って、未承認のＫ  １４ａのクエリー、更新もしくは管理を防ぐために、アプリケーションを使用した者はＫ  １４ａもしくはＫ  １４ａの特定部分へのアクセスを有するべきかどうかを認証することができる。さらに、ＡＰＩユーティリティーはデータソース８を認証することができる。
【００１８】
ＡＰＩユーティリティーおよびＬｅａｒｎ  Ｅｎｇｉｎｅは、アプリケーション・レイヤーを通して外部からアクセスされる。Ｋ１４ａ内の情報のインテグリティを維持するため、ＡＰＩ４は一切の内部Ｋ情報を、アプリケーションがＫ１４ａを横断もしくは変更することを可能にするアプリケーション・レイヤーに渡すことはない。例えば、ポインタまたはノードの位置がアプリケーション・レイヤーに渡されることはない。さらに、ノードの構造もしくはどのように接続構造が組織されているかという情報がアプリケーション・レイヤーに渡されることはない。注目すべきは、本特許がＡＰＩのさらなる詳細をカバーしている一方で、どのようにＡＰＩユーティリティーおよびＬｅａｒｎ  Ｅｎｇｉｎｅが機能し、アクセスされるかが米国特許出願第１０／８７９，３２９号に説明されていることである。
【００１９】
データを提供したり情報を要求したりすることがあるデータベースおよびその他の種類のプログラムまたはインターフェースなどのアプリケーションは、このアプリケーション・レイヤーのホストとなることがある。図１はこの構造を説明しているが、ホスティング環境が本質的に柔軟であるリーダーに対して指示するため、スレッドおよびレイヤーの明確な描写を避けて描かれている。
【００２０】
具体的に、図２において、我々はＫＳｔｏｒｅ  Ｋ  １４をクラウドとして描いており、コンピューターメモリシステム（図示せず）の中に位置付ける。このＫ  １４は、Ｋ  Ｅｎｇｉｎｅ  １１によってアクセス可能である。複数のＫ  Ｅｎｇｉｎｅがある可能性がある。アプリケーション・レイヤー１５は、クエリーやリプライといったデータの送受信をするため、様々な形のＧＵＩ（グラフィックユーザーインターフェース）インターフェース１５ｃを含んでいてもよい。このレイヤー１５はまたデータソース１５ａ、もしくはクラウド１５ａのプログラム（データソースと関連する可能性がある）を含んでいてもよく、それらはＫＳｔｏｒｅ  Ｋ  １４を構築するためにデータを提供することができる。また、このレイヤー１５はアプリケーションプログラム１５ｂを含んでいることがあり、このアプリケーションプログラムはクエリーを作成したり、Ｋに送信されるデータを提供したりする。さらに、例えば、注目すべきは、アプリケーションもしくはＧＵＩを介してメンテナンスおよび管理機能もまた実行できる状態にあるということである。レイヤー１５のコンポーネントは、必要に応じて様々なコンピューターシステムおよびネットワーク間でホストされるＧＵＩおよびアプリケーションのパーツを伴って、インターネットを通じて広がり、またはすべてが同様のコンピューターシステムサーバーのローカルとなることができ、ＫおよびＫ  Ｅｎｇｉｎｅ、さらにはＡＰＩユーティリティーをホストする。
【００２１】
データがＫに提供される時、またはＫで検索がなされた時はいつでも、我々は暫しＫ  Ｅｎｇｉｎｅにメッセージを要求もしくは送信していると言っている。注目すべきは、ＡＰＩユーティリティーの機能の中には、どのようにシステムが構築されたかに応じて、Ｋ
Ｅｎｇｉｎｅで囲まれていてもよいということである。最も理解し易い形において、Ｋ
Ｅｎｇｉｎｅはできるだけシンプルな状態に保たれている。例えばＫ  Ｅｎｇｉｎｅは粒子のみを通過してＫに入り、粒子が向かったところからポインタアドレスを戻してもよい。Ｋポインタアドレスが、ＡＰＩを通ってレイヤー１５へと渡されることは決してないということに注目することは重要である。所定の実行において、Ｋ  Ｅｎｇｉｎｅは必要に応じておよび／または効率が良ければ、ＡＰＩユーティリティーのいくつかの機能を担うことができる。
【００２２】
図２において、レイヤー１６はＡＰＩユーティリティー２１ｂの少なくとも一つのインスタンスを含むことができる。我々は簡単にＡＰＩユーティリティーをインターフェースオブジェクトと呼ぶことができる。このインターフェースオブジェクトは、情報、メンテナンスもしくはデータ入力１８の要求が、クエリーが中にいる形に関係なく、Ｋからの情
報を取得することができるようにする一連のプログラム（また場合によってはハードウェアもしくはその他未確認の媒体）を含む。このレイヤー１６は、複数のスレッドを処理してもよく、Ｌｅａｒｎ  Ｅｎｇｉｎｅの複数のインスタンスおよびＡＰＩユーティリティーの複数のインスタンスを含んでいてもよく、米国特許第１０／８７９，３２９号に詳しく説明されている。
【００２３】
ＡＰＩユーティリティーのユーティリティー手順は、Ｋ  Ｅｎｇｉｎｅもしくは内部ユーティリティー手順への要求を作成することができる。呼び出しそのものは、つまり、ＡＰＩユーティリティーオブジェクトからの要求が非常にシンプルな記述もしくは命令語であることさえある。これを見るための最も迅速な方法は、命令語または図３のメッセージ
３４としてそれを描くことである。我々は命令語のコンセプトを、図解を教えることを目的として使用する。そのようなものとして、命令語は命令タイプ（要求）３５を備えていることがあるが、要求の目的に関係なくＫ  Ｅｎｇｉｎｅが現在のロケーションポインタを戻すことができるため、多くの実施例においてこれは必要ではない。
【００２４】
従って、ＫＳｔｏｒｅの使用をサポートするための機能システムの基本コンポーネントが説明され、これらから、多数の事項が遂行される。
【００２５】
ＡＰＩ
図４クエリーを処理するための一般プロセス３５０がフローチャートとして描かれている図４を初めに参照する。アプリケーション３５１（またはユーザーによってアクセスされているＧＵＩ）は、結果を追求するために公式かされたクエリーＱを提供する。このクエリーＱは、ＳＱＬフォーマットまたはその他、例えば、自然言語のような解析された可能性のあるフォーマットの中にある場合がある。一例は「ＰＡ内でＢｉｌｌによって何か売買されたか？」であってもよい。クエリーは、要求された情報が現在ロードされているＫに存在していることを前提とする。
【００２６】
クエリーＱが理解されていない、あるいはその反対で誤りがある場合、フィードバックメカニズムは、アプリケーションまたはユーザーにクエリーを再公式化するよう要請するために提供されてもよい。
【００２７】
従って、この好適な実施例における次の手順は、図４のアプリケーションレイヤー解釈３５２を備えることと、必要に応じてフィードバックまたはエラーメッセージを提供することである。エラー処理は、追加されるフィールドの文字列といった無効な文字列を検索することなどを含む。一旦クエリーが確立されると、クエリーのコンポーネントも確立される必要がある。たった今聞かれた質問「ＰＡ内でＢｉｌｌによって何か売買されたか？」に関して、我々はＢｉｌｌをその中に有するＫのすべてのレコードを検索し、その中で売買されたと同時にＰＡを有するものにフォーカスをあてる必要がある。そのような該当するレコードがある場合、ポジティブなリプライが適切である；そうでなければ、ネガティブなリプライが適切である。
【００２８】
これは、検索要求３５３を位置付けするコンポーネントへのクエリーの分割を構成する。基本レベルにおいて、クエリーは３５６  Ｋ  Ｓｔｏｒｅ  Ｅｎｇｉｎｅへの要求に分類され、最新のロケーションポインタを経由したＫへの進路を検索する。この情報はＡＰＩユーティリティーに戻り、そこではクエリーＱが満たされるまで情報をまとめ、追加クエリーを作成する。ＡＰＩユーティリティーは、プロセス３５５の他のアドレスまたはルートノードデータを構成する情報を検索するために、直接コンピューターシステムメモリのアドレスへ行く。ＡＰＩユーティリティーは、検索された情報を処理するために３５４を作成するテーブル構造３５７の結果に適用される。応答が完了すると、３５８がフォーマット化され、使用されているクエリー言語内にある可能性があるリプライとして送信さ
れる。しかしながら、完了するまで、ＡＰＩユーティリティーはＫ  Ｓｔｏｒｅ  Ｅｎｇｉｎｅに対して要求を作成し続けることができる。クエリーが完了すると、フォーマット化された応答は、アプリケーション３５１に戻って３５９に送信される。
【００２９】
いくつかの好適な実施例において、我々はＫＳｔｏｒｅシステムに対する二種類のＡＰＩユーティリティーコンポーネントを有している。一つは管理ＡＰＩユーティリティーコンポーネントであり、機能サポートのメンテナンス、開始および変更を行い、それによってユーザーもしくはプログラムが、スイッチ、状態変数の設定、データソースの特定、メタデータの変更、または管理本質に関する他の事項を行うことによって、様々なシステムコンポーネントを変更することができるようになる。もう一方のＡＰＩユーティリティータイプは、ここで重要なクエリーに使用される。
【００３０】
図５は、クエリー、更新などの処理のためのＡＰＩユーティリティーオブジェクトへのアクセスを説明している。同様に、アプリケーション・レイヤーのほぼすべての項目３６１ａは、彼らがＡＰＩ、ここではＡＰＩ  ３７２ａによって提供されている一連のフックまたはアドレスを通して通信する限り、システム設計者によって随意に設定されている。ユーザーまたはアプリケーションは、ＧＵＩまたは３６１ａに示されるような他のインターフェースを通して、クエリーを処理するために、アプリケーション・レイヤーの当該コンポーネントを使用する。インタープリタは、３６１ａにおいても、好ましくはクエリーを解釈するために提供され、クエリーを理解し認識するために必要に応じてフィードバック（図示せず）を送信してもよい。３６１ａ内のパーサーは、このＡＰＩユーティリティーのインスタンスがクエリーを処理するために有しているアルゴリズムに関連するクエリーの本質を決定するために使用されることがある。使用されるＡＰＩユーティリティーのうちの一つを選択する。
【００３１】
クエリーは、おそらくクエリーパートフォーミュレーターによってコンポーネントパートに分類される。これらのクエリーパートは、３７２ａにある関連ＡＰＩユーティリティー・コンポーネント・ルーチンを要求することができ、それはＫ構造内にポジションを検索し、Ｋ構造に直接アクセスし、もしくはＡＰＩユーティリティースペース内の適切なメモリを更新するために、送受信サブコンポーネント  ３６７ａを経由してＫ  Ｅｎｇｉｎｅ  ３６８ａを要求することができるものである。Ｋ  Ｅｎｇｉｎｅ、センサーリスト上に何が送信されたか、どのように反応するか、といったようなことを決定するために、自身の関連メモリ３７６ａに目を向ける。
【００３２】
他のルーチンは、ユーティリティー３７２ａの領域３６６内のメモリを調整し、各クエリーパートに応答して戻ってくるロケーション情報を分析するために待機する働きをする。これらの他のルーチンはサブコンポーネントメモリコーディネータ／アナリスト３６６が特定され、スレッドメモリ３６９の中のクエリースレッドを処理するためのメモリ内の関連データを保管および検索する働きをする。ＡＰＩユーティリティー３７２ａは、以前の要求によって生成された以前の位置情報のレコード（例：要求に応えて３６８ａのＫ  Ｅｎｇｉｎｅによって戻された最新のロケーションカウンター）を保ち、コンテクスト内で変わりやすいサブジェクトの計算といったような高レベルの情報を検索するために作成する必要のある最新要求を処理するために、以前の位置情報を使用して新規要求とともに戻ることができる。メモリコーディネータ／アナリスト３６６は、スレッドメモリ３６９に保管されており、クエリーに対する回答を生成するために、Ｒｅｓｐｏｎｓｅ  Ｃｏｎｆｉｇｕｒａｔｏｒ  ３７７によって必要とされる最終結果を生成する可能性のある以前の要求から以前に検索された情報もまた調整することができる。
【００３３】
第２項―機能グループ
本発明の実施例におけるＡＰＩセットは、少なくともＡＰＩの４つの機能カテゴリに分
けられる：
１．サポート機能
２．解析計算機能
３．監視機能
４．管理機能
以下は、ＫＳｔｏｒｅインターロッキングツリーズデータストアにアクセスするために使用される各機能カテゴリ内のＡＰＩ手順の一例である。以下のこのリストは、代表的なＡＰＩ手順の説明である。
機能カテゴリ１―サポート機能
以下の手順は、ＫＳｔｏｒｅｓ１４、１４ａといったＫＳｔｏｒｅへのアクセス方法である。
クライアントインターフェースを維持する
接続する
ＱｕｅｒｙｌｎｔｅｒｆａｃｅＢｙＮａｍｅ
Ｋから値および情報を検索する
カラム
フィールド
変数
ＧｅｔＦｉｅｌｄｓＷｉｔｈＣｏｕｎｔ１３ＸＭＬ
ＧｅｔＦｉｅｌｄｓＸＭＬ
ＧｅｔＣｏｌｌｅｃｔｉｏｎＷｅｉｇｈｔ
ＧｅｔＣｏｕｎｔ
ＧｅｔＬｏｎｇＣｏｕｎｔ
ＧｅｔＤｉｓｔｉｎｃｔＣｏｕｎｔＬｉｓｔ
ＧｅｔＤｉｓｔｉｎｃｔＣｏｕｎｔＬｉｓｔＸＭＬ
制約を設定する
ＡｄｄＡＮＤＧｒｏｕｐ
ＡｄｄＮＯＴＧｒｏｕｐ
ＡｄｄＯＲＧｒｏｕｐ
ＡｄｄＣｏｎｓｔｒａｉｎｔ
ＵｐｄａｔｅＣｏｎｓｔｒａｉｎｔ
フォーカスを設定する
フォーカス
ＵｐｄａｔｅＦｏｃｕｓ
ＦｏｃｕｓＣｏｌｕｍｎ
ＵｐｄａｔｅＤｉｓｔｉｎｃｔＣｏｕｎｔ
データフォーマットを元に戻す
Ｋデータ構造
ＦｉｅｌｄＮａｍｅ
ＦｉｅｌｄＶａｌｕｅ
結果
ＩｓＡｌｐｈａｎｕｍｅｒｉｃ
タイプ
テキスト
比較する
ＩｓＭａｓｋ
Ｉｎｉｔ
ＩＫＤａｔａ：Ｉｎｉｔｉａｌｉｚｅ
Ｋ収集構造
項目
ＮｅｗＥｎｕｍ
計算する
Ｉｎｉｔ
追加する
削除する
消去する
機能グループ２−解析計算機能
以下の手順は、ＫＳｔｏｒｅインターロッキングツリーズデータストアからの分析性を検索するための異なる方法である。
ＤｅｃｉｓｉｏｎＴｒｅｅ
ＤｅｃｉｓｉｏｎＴｒｅｅ＿ＸＭＬ
規則
Ｒｕｌｅｓ＿ＸＭＬ
ＰｒｅｄｉｃｔＳｉｎｇｌｅＶａｒｉａｂｌｅ
ＰｒｅｄｉｃｔＳｉｎｇｌｅＶａｒｉａｂｌｅ＿ＸＭＬ
分類する
Ｃｌａｓｓｉｆｙ＿ＸＭＬ
ＢａｙｅｓＣｌａｓｓｉｆｙ
ＢａｙｅｓＣｌａｓｓｉｆｙ＿ＸＭＬ
ＲｅｃｏｒｄＥｘｐｌｏｒｅｒ−３
ＲｅｃｏｒｄＥｘｐｌｏｒｅｒ＿ＸＭＬ
ＲｅｃｏｒｄＥｘｐｌｏｒｅｒ＿ＸＭＬ−２
ＲｅｃｏｒｄＥｘｐｌｏｒｅｒ＿ＸＭＬ−３
ＲｅｓｕｌｔＬｉｓｔＣｏｕｎｔ
ＲｅｓｕｌｔＬｉｓｔＣｏｕｎｔ２
ＳｕｍＣｏｌｕｍｎＬｏｎｇ
ＳｕｍＣｏｌｕｍｎ＿ＸＭＬ
ＱｕｅｓｔｉｏｎＫ
ＱｕｅｓｔｉｏｎＫ＿ＸＭＬ
ＤｉｓｔｉｎｃｔＲｅｃｏｒｄＣｏｕｎｔ
ＲｅｃｏｒｄＣｏｕｎｔ
ＫＣｍｄ＿ＸＭＬ
機能グループ３―監視機能
以下の手順は、ＫＳｔｏｒｅデータストアを監視する方法である。
イベント
ＧｅｔＥｖｅｎｔ
ＳａｖｅＥｖｅｎｔ
ＤｅｌｅｔｅＥｖｅｎｔ
ＬｉｓｔＥｖｅｎｔｓ
ＳｔａｒｔＥｖｅｎｔ
ＳｔｏｐＥｖｅｎｔ
ＳｕｓｐｅｎｄＥｖｅｎｔ
ＲｅｓｕｍｅＥｖｅｎｔ
初期化する
停止する
状態
登録する
Ｕｎｒｅｇｉｓｔｅｒ
ＩｓＲｅｇｉｓｔｅｒｅｄ
トリガー
ＸＭＬ
ＧｅｔＡｄｖｉｓｅＣｏｏｋｉｅ
メモリ取得
メモリ設定
ＲｕｎＱｕｅｒｙ
ＱｕｅｒｙＳｔａｔｓ
ＧｅｔＱｕｅｒｙ
ＳａｖｅＱｕｅｒｙ
ＤｅｌｅｔｅＱｕｅｒｙ
クエリーを一覧にする
送信する
確率
機能グループ４―管理機能
以下の手順は、機能カテゴリに記載されている別の管理機能である。
構造を初期化および管理し、Ｋの特定機能を決定するための多岐にわたるＡＰＩ
ＳｔａｒｔＥｎｇｉｎｅ
ＳｔｏｐＥｎｇｉｎｅ
ＲｅｎａｍｅＥｎｇｉｎｅ
ＫｅｅｐＥｎｇｉｎｅＲｕｎｎｉｎｇ
保存する
ロードする
リセットする
名前を付ける
初期化する
ＱｕｅｒｙｌｎｔｅｒｆａｃｅＢｙＮａｍｅ
ｓｅｔＳｗｉｔｃｈｅｓ
持続
ＳａｖｅＫ
ＲｅｓｔｏｒｅＫ
ＤｅｌｅｔｅＫ
構造に追加された新規情報を読み込み、処理するためのＡＰＩ：  
学習する
加える
更新する
ＭｅｔａＤａｔａを維持する
ＡｄｄＣｏｌｕｍｎ
ＡｄｄＶａｒｉａｂｌｅ
本発明を説明するために、二つの図はＫＳｔｏｒｅ構造を管理および使用する方法を示すために使用される。図で説明されるように、各機能グループ内の一つの代表的なＡＰＩ手順が詳細に説明されている。
【００３４】
図６を参照すると、図６は、本発明の好適な実施例に沿ったＫのためのステップを示すシステム管理メソッド１００のフローチャートである。この図において、ＫＳｔｏｒｅ管理者はＫＥｎｇｉｎｅ  １０１を開始する。このステップに対するＡＰＩ手順は、管理機能機能カテゴリからはじまり、「ＳｔａｒｔＥｎｇｉｎｅ」手順と呼ばれる。
【００３５】
本発明を説明するために、図７はＳｔａｒｔＥｎｇｉｎｅメソッドの典型的なフローダイヤグラム１１０を示している。ＳｔａｒｔＥｎｇｉｎｅメソッドは、デフォルトセンサー一式を備えたＫの特定インスタンスを初期化する。
【００３６】
ＨＲＥＳＵＬＴ  ＳｔａｒｔＥｎｇｉｎｅ（ＢＳＴＲ名）；
パラメータ
初期化のためにＫインスタンスの名前を特定するＮａｍｅ［ｉｎ］ＢＳＴＲ。例：「Ｕｎｉｓｙｓ  Ｍａｒｋｅｔｉｎｇ  Ｍｏｄｅｌ」。
戻り値
【００３７】
【表１】
2009515240.tif 000002
【００３８】
図７に示されているようにＫＥｎｇｉｎｅが開始された後、Ｋがどのように見えるべきかを設定し、構造１０２を初期化するためにユーザーは一定の手順を使用することができる。この例において、「初期化」および「ｓｅｔＳｗｉｔｃｈｅｓ」および「ＡｄｄＣｏｌｕｍｎ」手順が使用される場合がある。これらの手順もまた管理機能機能カテゴリにあるため、どの手順も詳細が論じられることはない。
【００３９】
次のステップは、１０３に示されるように、データソースを設定し、ＫＳｔｏｒｅによる学習を初期化することである。データソースを設定するため、ユーザーは「ＡｄｄＤａｔａｓｏｕｒｃｅ」手順を使用する。学習を初期化するため、ユーザーは「Ｌｅａｒｎ」手順を使用することができる。さらに、これらの手順が管理機能にあるため、どの手順も詳細が論じられることはない。
【００４０】
ここでＫ構造を監視するために使用されるクエリーおよびイベントが設定される１０４。監視機能機能カテゴリからの「ＳｔａｒｔＥｖｅｎｔ」手順が使用される。
【００４１】
本発明を説明するために、図８はＳｔａｒｔＥｖｅｎｔメソッドの典型的なフローダイヤグラム１２０を示している。
ＳｔａｒｔＥｖｅｎｔメソッドは、特定イベントの監視を開始する。
ＨＲＥＳＵＬＴ  ＳｔａｒｔＥｖｅｎｔ（ＢＳＴＲ名）；
パラメータ
ｎａｍｅ［ｉｎ］監視を開始するため、イベントの名前を特定する。
戻り値
【００４２】
【表２】
2009515240.tif 000003
【００４３】
要件：ＫＳｔｏｒｅ  Ｅｎｇｉｎｅが開始しました。
図６に示される管理プロセスにおける最終ステップは、データを保存しエンジン１０５を停止する。さらに、これらの手順が管理機能機能カテゴリにあるため、どの手順も詳細が論じられることはない。
【００４４】
図９を参照すると、図９はＫＳｔｏｒユーザーが、本発明の好適な実施例に沿って、ど
のようにＫと相互作用しているかというフローチャート１３０である。この図において、ＫＳｔｏｒｅユーザーはＫサーバーに接続される１３１。このステップに対するＡＰＩ手順は、サポート機能機能カテゴリからのものであり、「接続」手順と呼ばれる。
【００４５】
本発明を説明するために、図１０は「接続」手順の典型的なフローダイヤグラム１４０を示している。
【００４６】
接続する
接続メソッドは、ＫＳｔｏｒｅ  Ｅｎｇｉｎｅを備えた通信パスを確立する。
ＨＲＥＳＵＬＴ  接続（ＢＳＴＲ  ｅｎｇｉｎｅＮａｍｅ；）；
パラメータ
ｅｎｇｉｎｅＮａｍｅ［ｉｎ］これは接続先のエンジン名である。
戻り値
【００４７】
【表３】
2009515240.tif 000004
【００４８】
要件：Ｅｎｇｉｎｅオブジェクトが作成され、開始されました。
次に、図９に示されるクライアントフローにおいて、フィールド情報が要求され１３２、続いて制約の設定１３３およびフォーカスの設定１３４がある。これらの手順がサポート機能機能カテゴリにあるため、どの手順も詳細が論じられることはない。
【００４９】
次に、図９に示されるクライアントフローにおいて、ＫＳｔｏｒｅ分析性が要求される１３５。このステップに対するＡＰＩ手順の例、解析計算機能機能カテゴリからのものであり、「ＰｒｅｄｉｃｔＳｉｎｇｌｅＶａｒｉａｂｌｅ」手順と呼ばれる。
【００５０】
本発明を説明するために、図１１は「ＰｒｅｄｉｃｔＳｉｎｇｌｅＶａｒｉａｂｌｅ」手順の典型的なフローダイヤグラム１５０を示している。
ＰｒｅｄｉｃｔＳｉｎｇｌｅＶａｒｉａｂｌｅ
ＰｒｅｄｉｃｔＳｉｎｇｌｅＶａｒｉａｂｌｅメソッドは、特定フォーカスに対する確率を計算し、ＫＣｏｌｌｅｃｔｉｏｎの中の結果を検索する。
ＨＲＥＳＵＬＴ  ＰｒｅｄｉｃｔＳｉｎｇｌｅＶａｒｉａｂｌｅ（ＩＫＣｏｌｌｅｃｔｉｏｎ  ＊＊ｐｐＶａｒｓ）；
パラメータ
ｐｐＶａｒｓ
［ｏｕｔ，  ｒｅｔＶａｌ］結果を戻すために使用されたＫＣｏｌｌｅｃｔｉｏｎ。
戻り値
【００５１】
【表４】
2009515240.tif 000005
【００５２】
要件：フォーカスフィールドが設定され、制約がある場合は前もって処理されている。
図９に示されように、この例において、最終ステップはユーザーに戻されたデータを処理するものである１３６。これらの構造がサポート機能機能カテゴリにあるため、それらの詳細が論じられることはない。
【００５３】
本発明の詳細が説明され、その特定の例を参照してはいるが、その精神と範囲から逸脱することなく、そこに様々な変化および変更がされる可能性があるということは当業者にとって明白なことである。
【図面の簡単な説明】
【００５４】
【図１】図１および２は、本発明の好適な実施例に使用される主要コンポーネントの相互作用を描いている構成図である。
【図２】図１および２は、本発明の好適な実施例に使用される主要コンポーネントの相互作用を描いている構成図である。
【図３】図３は、命令後フォーマット内のメッセージの構成図である。
【図４】図４は、本発明の好適な実施例に沿った、ＡＰＩユーティリティーのプロセスを処理するアプリケーションクエリーのフローチャートである。
【図５】図５は、好適な実施例ＡＰＩユーティリティー・コンポーネントの構成図である。
【図６】図６は、本発明の好適な実施例に沿った、Ｋに対するシステム管理手順のフローチャートである。
【図７】図７は、本発明の好適な実施例に沿った、ＳｔａｒｔＥｎｇｉｎｅ方法の典型的なフローダイヤグラムを示したフローチャートである。
【図８】図８は、本発明の好適な実施例に沿った、ＳｔａｒｔＥｖｅｎｔ方法の典型的なフローダイヤグラムを示したフローチャートである。
【図９】図９は、本発明の好適な実施例に沿った、ＫＳｔｏｒｅユーザーがＫとどのように相互作用するのかを示したフローチャートである。
【図１０】図１０は、本発明の好適な実施例に沿った、「接続」手順の典型的なフローダイヤグラムを示したフローチャートである。
【図１１】図１１は、本発明の好適な実施例に沿った、「ＰｒｅｄｉｃｔＳｉｎｇｌｅＶａｒｉａｂｌｅ」手順の典型的なフローダイヤグラムを示したフローチャートである。
【図１】
2009515240.tif 000006
【図３】
2009515240.tif 000007
【図５】
2009515240.tif 000008
【図７】
2009515240.tif 000009
【図８】
2009515240.tif 000010
【図９】
2009515240.tif 000011
【図２】
2009515240.tif 000012
【図４】
2009515240.tif 000013
【図６】
2009515240.tif 000014
【図１０】
2009515240.tif 000015
【図１１】
2009515240.tif 000016