JP2008516347A - インタロックツリーデータストアの保存および復元 - Google Patents

Abstract

生成され、かつ／またはアクセスされ得る相互接続されたツリーの森を含むツリーベースのデータストアは、すべてのリンクが、それが完全に復元されるかまたは部分的に復元されるかに関わらず、正しく維持されることを確実にするために、特別な保存および復元プロセスを必要とし得る。以前のプロセスはツリーベースのデータストアの公知の機能上に作用し、メタデータのファイルを生成し、構造の各ノードをパケット化し、慎重にリンクおよびリンクのリストをその原因となる古いメモリアドレスを用いて保存した。これはその代わりに、リンクを復元する新しい復元プロセスを用いて、すべてのリンクを保存することなくいかに保存ファイルを構築するかを開示する。

Description

関連出願
この出願は、２００４年１月１６日に出願された特許出願番号第１０／７５９，４６６号（代理人管理番号ＴＮ３２０）の実質的な開示を共有し、この特許出願と同じ発明者を共有する。

発明の分野
本発明は、インタロックツリーデータストアの操作の分野に関し、特にインタロックツリーデータストアの保存および検索を可能にすること、さらに特定的には、特定的なインタロックツリーデータストアの保存および検索をもたらすための改良に関する。

発明の背景
インタロックツリーデータストアである知識ストアまたはＫＳｔｏｒｅを保存し、復元することは、このようなデータストアの商業化において重要な特徴であり得る。実験的な試みにおいて、我々は本願明細書で教示する原理を適用して、ＫＳｔｏｒｅを保存し復元するのに必要な時間および必要なメモリサイズを桁違いに減じてきた。

インタロックツリーデータストアを生成し使用するためのさまざまな方法およびシステムを開発してきた。特に、これらの構造および方法は、同時継続出願である、発明者マザガティ（Mazzagatti）による米国連続番号第１０／３８５，４２１号および第１０／６６６，３８２号の特許出願において説明されている。さらに、このようなインタロックツリーデータストアがより効率的に用いられ得るシステムについて、米国特許連続番号第１０／８７９，３２９号において説明した。この特許において我々が説明するシステムおよび方法は、特にこの発明者マザカティが上記に参照される特許（出願）で説明した特定のインタロックツリーデータストアに関係し、本願明細書で説明されたシステムおよび方法は類似の構造にも適用可能である。

もちろん保存されたインタロックツリーデータストアのための他の使用が存在する。部分的保存、またはインタロックツリーデータストア全体の「区分」の使用によれば、より多くの使用があり得る。したがって、１つの例のみを挙げても、類似するが分散されている、または独立した同時使用のために、１つの機械に組込まれたインタロックツリーデータストアを複数の計算機械に保存するなど（または部分的なインタロックツリーデータストアを保存するなど）するために、保存および復元プロセスを用いることができる。ここで現実的な視点から見ると、知識で満たされたインタロックツリーデータストアが中央のマシンから保存され、店頭販売時点の在庫についてのクエリを扱う全国規模の企業のレジ全体にわたって、中央リポジトリによらずに復元されることが理解できる。学生向けの使用または修正として、教科書または知識ベースのサンプルをその個人コンピュータに保存することが理解できる。このような使用のいずれについても、そのようなニーズに応答する、ここで説明される保存および復元プロセスは、インタロックツリーデータストアおよびその部分的保存を、あらゆるメモリからあらゆる他のメモリへと動かすように用いることができる。

元々は同時係属特許出願米国連続番号第１０／３８５，４２１号に記載されたシステムによって生成されたインタロックツリーデータストア構造がさまざまな方法でそれ自体にデータを関連させ、また結果を得るための特別な構造を生成する必要なしにさまざまな照会に対して結果を生成するために、多くの有用な特性を与える一方で、従来その有用性に
は根本的な限界があった。限界の１つは、コンピュータにおけるメモリのデータ構造が、定位置にある間は働くが、動くことまたは保存することおよびその後の復元には適していなかったことである。以前は、インタロックツリーデータストアを動かす必要がある度に、またはインタロックツリーデータストアがあるコンピュータシステムをシャットダウンする必要がある度に、教え直す、すなわちインタロックツリーデータストアの新しいコピーまたはインスタンス化全体を作り直す（またはより正確にはこの発明のシステムに作り直させる）必要があった。このように、コンピュータシステムの故障にもかかわらずインタロックツリーデータストアの可搬性と長寿とを保つことを享受するのは、インタロックツリーデータストアについては本開発以前には手が届かないことであった。

本開発以前には我々が生成したデータ構造はコンピュータシステムに存在しなかったことから、先行の設計方法においては我々のニーズに適合するシステムのための発見はほとんどなかった。したがって、この構造を形作る関連性を失うことなく復元され得るようにこの構造を保存する特定の方法を自身で設計せざるを得なかった。すなわち、ポインタ構造は、それが運ばれていく新しいシステムにおいて、それがコンピュータシステムから保存されたのと同じそのコンピュータシステムにおいて、またはそれが復元されるべきコンピュータシステムにおいて、アドレススペースが変更されていたとしても、正確に復元される必要があった。要素的根ノードはそのデータが保持される必要があり、その構造体に対するポインタへのアクセスが復元される必要があった。たとえノードがすべて後に異なるアドレスに復元されるとしても、すべてのノードはそのポインタに対して同じアクセスを有する必要があり、かつ、インタロックツリーデータストアがいかなるコンピュータ環境の中でも用いられ得るように、ＯＳ独立かつ機械独立の方法でこれを達成する必要があった。

一般に、相互接続ツリーデータストア（interconnecting trees datastore）の森は、前の特許文献で以前に記述した態様で生成され、かつ／またはアクセスされる。ツリーベースのデータストアは、第１の根ノードに従属し、複数の分岐を含み得る、第１のツリーを含む。第１のツリーの分岐の各々は葉ノードに終わる。各葉ノードは最終製品（end product）またはサブコンポーネントノードを表わしてもよい。同じツリーベースのデータストアの第２の根は、最終製品を表わす各葉ノードにリンクされる。最後に、ツリーベースのデータストアは複数のツリーを含み、これらのツリーの各々の根ノードが要素的ノードとして記述され得る。これらのツリーの各々の根ノードは、第１のツリーの１つ以上の分岐における１つ以上のノードにリンクされてもよい。ツリーベースのデータストアのノードは、ツリーベースのデータストアの他のノードへのポインタのみを包含し、また付加的なフィールドを包含していてもよく、その１つはカウントフィールドでもよい。さらに、１つ以上の規定された焦点内の所望のコンテキストによって特定されるように、特定のノードに関連する変数の一致の可能性を得るための手段が記述される。さらに、そのような変数に関するクエリへの論理演算子の適用が示される。

同時係属出願の連続番号第１０／７５９，４６６号に説明した保存および復元システムを研究した後、保存および復元をさらに著しく効率的に操作し得ることを発見した。したがって、その出願の元の開示に加えて、この発見について本願明細書に記載する。

発明の概要
１つ以上のレベルの相互接続されたツリーの森を含むツリーベースのデータストア、すなわち、米国特許出願連続番号第１０／３８５，４２１号で我々が説明したものと類似または同一の固有の学習プロセスによって好ましくは生成され、かつ／またはアクセスされたものを保存し、復元ができるためには、支持構造、ノードの組織、および特定の要素的
データを保存する必要がある。

前述されたような保存（ＳＡＶＥ）／復元（ＲＥＳＴＯＲＥ）プロセスは、大きなＫデータストアについては非常に遅かった。多くの場合、オリジナルデータからＫを作り直した方が速い。

新しい方法では、asCaseリストおよびasResultリストを保存しない。これらのリストは、個々のノードの各々のＲＥＳＴＯＲＥを用いて再構築することができる。すなわち、ノードが復元されて新しいノードアドレスがCaseポインタ（Case pointer）のasCaseリストおよびResultポインタ（Result pointer）のasResultリストに記憶される。

新しい方法の別の重要な局面は、元の方法である連続番号第１０／７５９，４６６号では２つのパスを必要とするが、その代わりに復元位相におけるデータを通して単に１つのパスしか必要としないことである。好ましいインタロックツリーデータストアについて以前の特許に記載されたように、ツリーベースのデータストアの各レベルは、第１の根ノードに従属し、複数の分岐を含み得る第１のツリーを含む。第１の根は、これに限定されないがレベル開始インジケータなどの概念を表わしてもよい。第１のツリーの分岐の各々は、葉ノードまたは最終製品ノードに終わる。ツリーベースのデータストアの同じレベルの第２の根は、最終製品を表わす第１のツリーの各葉ノードにリンクされる。したがって第２の根は、必然的に第１のツリーまたは第１のツリーのサブセットの逆転した順序への根であるが、第１のツリーは複写されない。第２の根はこれに限定されないがレベル終了インジケータなどの概念を表わしてもよい。最後に、ツリーベースのデータストアは複数のツリーを含み、そこでこれらのツリーの各々の根ノードは、データセット要素またはデータセット要素表現などのデータを含み得る。このタイプの根ノードは本願明細書では要素的根ノードと呼ばれる。これらのツリーの各々の要素的根ノードは、複写されない第１のツリーの１つ以上の分岐における１つ以上のノードにリンクされてもよい。ツリーベースのデータストアの非根ノードは、ツリーベースのデータストアの他のノードへのポインタのみを必然的に包含し、また付加的なフィールドを包含していてもよく、そのような付加的なフィールドの１つはカウントフィールドであってもよい。ツリーベースのデータストアの各レベルを含むツリーの森のツリーの根もポインタで構成されるが、要素的根ノードは、さらに情報を表わすデータを包含（すなわち、データセット要素などのデータまたはレベル開始インジケータもしくはレベル終了インジケータなどの概念であるデータ、またはこれを表わすデータを包含）してもよく、ツリーベースのデータストアの他のすべてのノードは単に他のノードを指すのみであって、必然的にデータを包含していない。１つの実施例では、データは、文字と関連付けられた整数、ピクセル表現、開始インジケータ、終了インジケータ、フィールドインジケータの開始などの条件であるが、インタロックツリーデータストアはこれに限定されない。複数のレベルの上述のツリーベースのデータストアが生成され、アクセスされ得る。より下位レベルの最終製品が次のレベルの要素的根ノードになる。この保存および復元の発明において、ここで詳細に記述されるようなプロセスを案内するためにレベルが用いられる。

ノード自体の構造体は、ノードごとのデータフィールドの限定的な集合を通して一般に維持される。Case、Result、asCaseリストポインタ、asResultリストポインタ、および構造体のほとんどの形式においては少なくとも１つのカウントフィールドを含む付加的なフィールド、ならびに各要素的根ノードのための値フィールドがある。

上述された、また上記に挙げた、それぞれの全体が引用によって本願明細書に援用される同時係属特許出願にさらに詳述された構造を保存するためには、支持構造が保存されるべきであるが、いかなる種類の復元が計画されているかに依存しており、そのうちいくつ
かは損傷なく失われるかもしれない。支持構造は、保存しているインタロックツリーデータストアの形式、およびいかにしてそれを復元するつもりか、に依存して当然異なる。

次いで、インタロックツリーデータストア構造それ自体の全体が保存エンジンによって横断され、保存エンジンは各ノードにアクセスし、各ノードにおける情報から保存用のノードパケットを生成する。好ましい実施例では、ノードパケットは、好ましくはたとえばノード用のパケットの長さを含む、保存エンジンにより生成されたメタデータを包含する。次いでエンジンは、それが形成された機械においてか、または他の機械もしくはメモリシステムかにかかわらず、永久メモリ、または我々がインタロックツリーデータストアを保存するメモリであればいかなるメモリにも、ノードパケットを保存する。このようなメモリは比較的永久的な種類であることができ、前記１つのメモリを収容する機械にローカルなメモリ、ネットワークを通じてアクセス可能なシステムにおける離れたメモリ、区分された機械の区分メモリ、前記１つのメモリの別の部分であり得る。結局、ほとんどの場合、それが元の機械にあるか、機能性を与えることができるように他の何らかの機械にあるかにかかわらず、インタロックツリーデータストアを（またはそのいかなる保存された部分を）アクティブメモリに復元することが予想される。メタデータをパケット自体にではなく別の方法でいかに記憶することができるかは後に議論される。さらに、大きなパケット内のノードパケットとしてパケットの記憶装置をいかに好ましい形式で組織するかも説明される。

いずれの支持構造が保存されるべきかを決定するための元の概念においては、いくつかの選択として以下が含まれる。（保存用の）作成日を包含するファイルヘッダ、ファイルＩＤ、「センサ」を呼びたいが一般には要素的根ノードまたはその値を指すアドレスとして説明するものについての値のリスト、構造の最終製品ノードを表わすストリングのリスト（それがインタロックツリーデータストアの森の中のノードのすべての「考察」またはストリングを表わすので）、基礎をなすＯＳまたはそれが存在するコンピュータシステムのデータ構造を記述することができるすべての必要なメタデータ、もしあればパスワード保護、ポインタのリストがノード内でいかに順序付けられるか、および、構造を復元するかまたは保存されている構造における情報のアドレスを決定することが必要であればその性質についてのあらゆる情報、である。さらにヘッダは、Ｋ状態変数（いくつの付加的なフィールドがノードで支持されるか、いかなる種類のクエリが進行しているか、asCaseリストおよびasResultリストがいかに構造化されるか、データソース、スイッチ、およびデータストリームなど）、および／または、どのデータソースがクエリを受取り、かつ／またはそこから情報を得るかなどを特定するフックなどのデータソース記述子を、保存してもよい。これらのすべての項目についてのデータが単一のヘッダにあることも、または、そのうちすべてもしくはいくらかが各パケットの小さなヘッダにあり、もしくは特定の項目を用いるパケットのヘッダにあるか、またはこの情報のいずれも全く保存する必要がない場合もある。プログラミング技術の当業者は、システムが公知の環境などに基づいて仮定され得、それによりある状況においてはこのようなデータを保持することが無意味になり得ることを理解する。換言すれば、このメタデータの多くは、保存されたＫおよび復元されたＫの環境が同一または相当類似している場合に冗長になり得る。（「データストリーム」は、静的か動的かにかかわらず、データセットおよびその関連する入力ソースを示す用語である）。

プロセスをより効率的にするよう試みる際、（リスト上にポインタの数を保存することは復元をより効率的にするのを助け得るが）asCaseリストおよびasResultリストのためにポインタを保存する必要はないことが発見された。しかしながら、この改善は一般に、正しいシーケンスで、すなわち、asCaseリストおよびasResultリストを有するノードが、それが指すノードの前に処理されるようにノードを保存した場合にのみ、現在の技術を用いて円滑に作動する。我々は単純に、インタロックツリー構造の最低レベルから始めて最低
レベルのすべてのノードを保存した後に続く（より高い）レベルに移り、asCaseポインタ（ＢＯＴおよびサブコンポーネントノード）およびasResultポインタ（根ノード）を有するノードから始めて、次に同じ種類のノードを備えたこのようなレベルから始めて続く（より高い）レベルに移る。

この改良された保存および復元システムのための３つの新しい種類のノードパケットを用いる方法について説明するが、この特許においてはこれらをパケットタイプ１、２および３と呼ぶ。好ましい実施例では、インタロックツリーデータストア構造とともに保存されている支持構造におけるノードパケットのタイプが示唆される。代替的には、ノードパケットタイプのための識別子がノードの付加的なフィールドに記憶されてもよい。「タイプ」とは何かについて、用語に関して何らかの混乱があり得るが、詳細な説明において、いつノードおよびパケットのタイプについて説明しているのか、またノードの「フィールド」またはパケット組織に何があるのかに分類が依存するか否か、を明確にするための鍵が与えられる。

タイプ１ノードパケットは現在のまたは古いノードアドレス、CaseポインタおよびResultポインタ、任意の「付加的なフィールド」、asCaseリストポインタのカウントおよびasResultリストポインタのカウントを包含する。タイプ１パケットはさらにパケットサイズの情報およびノードパケットタイプの表示をも有し得る。リストカウントが望まれ得る理由は、保存されたＫが復元されているとき、復元されたＫを保持するターゲットマシンのメモリにリストのための十分なスペースを割付ける必要があり、ポインタの数（各々が何らかのアドレスの表示を必要とする）がこのサイズ要件に著しく影響するからである。ノードの絶対数はサイズの割付け要件に寄与する別の大きな要因になるが、個々のノードにメモリ領域を割付る必要があれば、その要件はほとんどがポインタリストサイズとなる。

タイプ２パケットは、CaseポインタおよびResultポインタ、任意の付加的なフィールド、現在のまたは古いノードアドレスを包含し、さらにパケットサイズおよびパケットタイプについての情報をも有することができ、したがってasCaseリストポインタおよびasResultリストポインタのカウントを省略する。ノードパケットタイプ１およびタイプ２は、下記に説明されるようなさまざまな状況で用いられ得るが、ユーザのニーズまたは好みに基づいて選択し得ることが理解されなければならない。

第３のタイプ、タイプ３は、ノードがこのインタロックツリーデータストアにおいてasCaseリストまたはasResultリストのみを有し、両方は有しないことを認識する。したがって、それは現在のまたは古いノードアドレス、CaseポインタおよびResultポインタ、任意の「付加的なフィールド」、および１つのポインタリストカウントフィールドを包含しており、それにより、asCaseおよびasResultポインタリストフィールドを両方有するためにそうでなければ必要となったであろうメモリスペースを節約している。タイプ３パケットは、さらにパケットサイズおよびパケットタイプについての情報をも包含し得る。パケットタイプ情報は、asCaseまたはasResultのいずれのポインタリストがパケットに含まれているかの表示を含み得る。パケットがいずれのタイプのポインタリストがパケットにあるかについての情報を包含していなければ、ポインタリストはasReferenceタイプと考えられ、復元および／または他のＫＳｔｏｒｅプロセスがそれを決定する。

ノードパケットタイプ１、タイプ２、およびタイプ３はさまざまな状況で用いられ得る。実際、タイプ１が１種類のノードに用いられ、タイプ２が別の種類に用いられる限り、それらは単一の「保存／復元」動作の中で一緒に用いることができる。単一の保存されたＫで３つのタイプを一緒に用いることは考えにくい。なぜならばそれは２つのタイプのいずれが所与のノードであるかを決定するためにノードパケットを生成するアルゴリズムの付加的なステップでのプログラミングを必要とし、これが処理を遅らせてこの時期に知覚
することができる利益がほとんどまたは全くないからである。しかしながら、復元ルーチンが、たとえばパケットタイプ１を備えた保存されたＫｌ、およびタイプ２のノードパケットを備えた保存されたＫ２など異なるノードパケットタイプから構成される保存されたＫをとることができ、それを単一の新しいＫに復元することができることに注意されるべきである。

以前の我々の保存および復元の特許出願と同じく、パケットサイズは、新しいパケットが記憶用に準備されるかまたは記憶されるたびに、好ましくはパケットを確立するために用いられる何らかの機構によって好ましくはちょうど決定される。正常なプログラミング制約および実行が与えられると、そのメモリ長さの合計はヘッダに配置され、またはそうでなければインタロックツリーデータストアメモリ領域全体に保存される。いくつかの実施例では、このステップを回避するためにすべてが同じ長さを与えられ、いかなる余分のスペースもそのような実施例の保存では無視される。さらにこの特許における保存をよりよく体系づけるため、パケット内のパケットの使用も開示される。

すべてのノードにアクセスするために構造を横断することがさまざまな方法で行われ得る。一次根ノードから開始してasCase経路に沿って、または最終製品ノードから開始してすべての一次根ノードが見つかるまで後向きにCaseリンクを辿り、または根ノードの各々から開始してそれぞれからasResultリンクを辿ることができる。上述のように、保存動作中にノード情報を記憶するためにタイプ１パケットまたはタイプ３パケットを用いる場合、asCaseリストを備えたノード、ここではＢＯＴノードから開始することが好ましい。

さらに、最低レベルの根ノードの各々から開始してすべてのasResultポインタを辿ることにより、Ｋ構造を横断することもできる。タイプ１およびタイプ３について上記で言及したのと同様の考察が適用される。

適切に保存することによって、部分的なインタロックツリーデータストアの復元も可能になり、それにより特定のアプリケーション用のバルクなしに構造全体の知識の有用性を保持することができる。一般に、完全に発展したインタロックツリーデータストアを制約したければ、興味の制約内の部分のみを横断することによりそれを保存し、保存されたものすべての復元を行うことができる。したがって、たとえばこのプロセスを通じて、継続した興味のない最終製品ノードを有するデータをすべてなくすことができる。他の種類の部分的保存は現在のところ推奨されない。しかしながら我々は、将来的にこれ以外の適切な部分的保存技術を開発するであろう。さらに、ヌル（null）値、小さい値、負の値さえ有するカウンタを備えたノードを保存しなければ、保存するノードの数を減じることができる。

構造を復元することは、復元に必要とされるメモリを割付け、保存された支持構造を読取ることを必要とする。アドレス変換表を構築している間に各ノードパケットが読取られ、メモリが割付けられなければならない。アドレス変換表は、各ノードについて古いメモリアドレスを新しいメモリアドレスに変換するために用いられる。次いで、各ノードはその規定するCaseポインタおよびResultポインタによって再構築され、他の関連データならびにCaseノードおよびResultノードのasCaseポインタリストおよびasResultポインタリストは、現在のノードの新しいメモリアドレスで再び占められる。するとＫ構造が復元されている。代替的には、相対アドレスを記憶し、基礎相対アドレスのみを用いて復元することができる。

ＫＳｔｏｒｅ構造の１レベルの最終製品ノードは、次のレベルのサブコンポーネントノードを生成するために組合わせられる根ノードであってもよい。このプロセスは何回も繰り返すことができ、asCaseツリーのいかなる数のレベルを生成する。さらに、あるレベル
のノードは、その関連するさらに下位レベルノードおよび根を見るためにResultポインタを通じて横断されてもよい。１つのレベルの最終製品ノードは、そのasResultツリー、すなわち下位レベル終了インジケータ（ＥＯＴ）を表わす根ノードを有するより下位レベルのasResultツリーを通して、次のより高いレベルの根ノードになる。

各レベルからの最終製品ノードはそれが生成される間に特定される場合もあるであろう。これが生成するメタデータは、たとえば、より高いレベルのみの部分的保存を行いたい場合に保存することができた、インタロックツリーデータストア構造のメタデータの一部である。

前述の要約は、本発明の実施例の以下の詳細な説明と同様、添付の図面に関連して読むと一層よく理解される。本発明を図示する目的で、発明の例示的な構造が図面に示される。しかしながら、本発明は開示された特定の方法および手段に限定されるものではない。

例示的な実施例の詳細な説明
概観
前に言及された特許出願において、ここでＫＳｔｏｒｅと呼ばれるインタロックツリーデータストアを生成するためのシステムおよび方法について説明したが、本発明が既存の技術として当然としてはいるがコンピュータデータ技術において他では見られないと思われる概念を読者に理解してもらうため、その説明のいくらかを繰返すことが必要であろう。ＫＳｔｏｒｅは一般に、相互接続されたツリーの森の少なくとも１レベルを含む。データストアの相互接続されたツリーの森の各レベルの構成は、要素的データセットからの要素のシーケンスを表わす新しいノードを生成することにより、データストリームについての情報を捉える。データストリームで各要素に遭遇すると、新しいサブコンポーネントのノードコンポーネントが、前のサブコンポーネントのノードへの参照および要素的根ノードへの参照を用いて構築される。新しいシーケンスが構築されている場合、（要素ノードの組に含まれていた）考察インジケータの始めのレベルおよび要素的根に参照がなされる。シーケンスの終わりに遭遇していれば、サブコンポーネントノードおよび考察インジケータの終わりのレベルを表わすノードに参照がなされる。この反復的なプロセスの結果、asCaseツリー分岐によってリンクされるノードから構成される単一のasCaseツリーおよび複数のasResultツリーを生成する。asCase分岐のノードは第１の根に従属する。たとえば図１１を参照して、ノード１０５０、１００２、１００４、１０２４、１０２６、１０２７および１０３０は、第１の開始インジケータ根に従属する例示的なasCaseツリーである。ノード１００５から始まる他の分岐もこのasCaseツリーの一部と考えられ、１０２８、１０２９、１０４０、１０３１および１０６０を含むがこれらに限定されない。asResultツリーの例は以下のツリーを含む。ノード１０５１、１００２（１つのasResultツリー）、ノード１０５３、１００３および１００５（asResultツリーの第２の例）、ノード１０５７、１０３３、１０３１、および１０２７（asResultツリーの第３の例）であって、これらはこの図の他の多くの中で見つけることができる。根（ノード１０６１）が終了インジケータを表わすので、右側のasResultツリーはasResultツリーの特別なインスタンスである。

構造を最も基礎的な形式で見るために、インタロックツリーデータストア構造の最も小さな単位が、リンク９６−９９によって接続されるノード９１−９５を有して描かれる、図１０を参照されたい。基礎構造は、リンク９６を通じてサブコンポーネントノード９４に接続される一次根（第１の根、ノード９１）を有する。第３の根（要素的根）ノード９２もリンク９７によってサブコンポーネントノード９４に接続される。（したがってノード９４はデータに表示されるものすべての表現であり、すなわち、ノード９４は、要素的ノード９２が後に続く、要素的ノード９１のデータのインスタンスを表わす）。ノード９
５はリンク９９によってノード９４に接続され、経路９１−９６−９４−９９−９５は、一次根から始まり、最終製品ノード９５で終わる経路と呼ばれ得る。（経路はリンクとノードとの接続されたいかなる線でもあり得る）。最終製品ノードも第２の根ノード（考察ノードの終わり）９３のインスタンスであり、リンク９８によって経路に接続される。

所与のレベルのasCaseツリーの各分岐は、レベル開始インジケータを表わすノードと根ノードを表わすノードとのサブコンポーネントノードへの組合わせから開始する。サブコンポーネントノードは、反復して根ノードと組合わされて別のサブコンポーネントノードになってもよい。サブコンポーネントは、レベル終了インジケータを表わすノードと組合わされて最終製品ノードを生成してもよい。このプロセスは繰返すことができ、結果として第１の根に従属する複数のasCaseツリー分岐を形成し得る。

たとえば、特定のインタロックツリー構造の分割不可能な要素的根ノードまたはセンサが英数字である場合、サブコンポーネントノードは単語でない文字の組合わせを表してもよく、最終製品ノードは単語を表わしてもよい。代替的には、サブコンポーネントノードは一部の在庫の番号（partial stock number）または注文番号（order number）を含む英数字の組合わせを表わしてもよく、最終製品ノードは全体の在庫（complete stock）または注文番号を表わしてもよい。これは、本発明に適用される入力の英数字の母集団の多くの用途のうち２つの可能な用途のみに言及したものである。

１レベルの最終製品ノードは次のレベルの根ノードであってもよい。最終製品ノードは、次のレベルのサブコンポーネントを生成するために、より下位レベルのデータセット要素がより下位レベルのサブコンポーネントノードおよび最終製品ノードを生成するために用いられるのと同じ方法で用いられてもよい。たとえば、上述の特定のインタロックツリー構造では、１レベルの最終製品ノード（単語を表わす）は根ノードであり得、そこからより高いレベルの最終製品ノード（文を表わす）が生成されてもよい。このプロセスは何度も繰返すことができ、データストアのインタロックツリーのレベルを任意の数だけ生成する。

図１０の根ノード９１、９２および９３ならびに図１１の根ノード１０５０―１０５９および１０６１などの根ノードは、本願明細書で要素的根ノードと呼ばれる。なぜならばこれらのノードはデータセット要素を表わし、分割不可能な単位を含み、そこから分割可能な単位（サブコンポーネントノードおよび最終製品ノード）が構成されるからである。９４、１００４、１０２４、１０３３などのノードは本願明細書でサブコンポーネントノードと呼ばれる。なぜならばこれらのノードは、開始インジケータなどの概念インジケータを表わす根ノードとデータセット要素を表わす根ノードとの組合わせ、サブコンポーネントノードと最終製品を含まないデータセット要素を表わす根ノードとの組合わせ、またはサブコンポーネントノードと最終製品ノードを含む終了インジケータを表わすノードとの組合わせを表わすからである。ノード１０３０または９５などのノードは最終製品ノードを表わす。引用された例において、要素的根ノードは文字であり、サブコンポーネントノードは単語を含まない文字の組合わせを表わし、最終製品ノードは単語を表わす。要素的根ノードの組が、この例において単語、考察またはストリングの初めを意味する「ＢＯＴ」、および単語、考察またはノードのストリングの終わりを意味する「ＥＯＴ」を含むことに注意される。「ＢＯＴ」および「ＥＯＴ」が開始インジケータおよび終了インジケータを表わし、本発明がこれに限定されないことが認識される。そのようなインジケータの片方または両方の欠如が考えられるとともに、他のこのようなインジケータの使用も考えられる。本発明の１つの実施例では、最終製品ノードは、特定のノードからＥＯＴ概念を表わす根ノードへのリンクに起因してサブコンポーネントノードから区別可能である。

要素的根ノードがＫＳｔｏｒｅ構造の第１のレベルで文字を表わす場合、ＫＳｔｏｒｅ
構造におけるレベル根ノードとして単語、文字のシーケンスを用いるより高いレベルは、文を含んでもよい。同様に、１レベルにおける要素的根ノードとしてのピクセルは、次のより高いレベルにおいて写真の領域を、およびさらにより高いレベルにおいて写真全体を含むことができる。文は段落（単語よりさらに高いレベル）を生成するために組合わされ、などと続くことができる。さらに、より高いレベルの根ノードはインタロックツリーデータストアのより下位レベルに向かって横断されてもよい。本発明の１つの実施例では、次のレベルの根ノードを規定するためにレベル終了インジケータから始まるasResultツリーが用いられる。終了インジケータは、本発明の１つの実施例におけるasCaseツリーによって規定されるように、インタロックツリーデータストアの逆転した順序での第２の根である。

ノードが生成される間、新しいノードと新しいノードが表わす２つのノードとの間に双方向リンクが生成される。Caseリンクは、２つのノードから新しいノードが生成される、その２つのノードの最初のノードへのリンクを表わす。新しいノードへの他方のポインタはCaseノードのasCaseリストに記憶される。入力が処理される間にasCaseツリーのasCase分岐がasCaseリンクの生成によって生成され得ることが認識される。各レベルのasCase分岐は、そのレベルのサブコンポーネントノードおよび最終製品ノードがそれぞれいかに生成されたかについて直接の記録を与える。したがって、asCase分岐は、サブコンポーネントノードおよび最終製品ノードがいかに生成されるか知ることが有用であるようなあらゆる目的に用いることができる。たとえば、インタロックツリージェネレータへの入力が正確に綴られた単語の母集団を含む場合、結果として生じる生成されたインタロックツリーのasCaseリンクはスペリングチェッカとして用いることができる。これはデータストアの多くのあり得る効用のうちの単に一例を挙げたにすぎない。

Resultリンクは、２つのノードから新しいノードが生成される、その２つのノードの第２のノードへのリンクを表わす。asResultリンクの生成は一連のインタロックツリーを生成し、そこでasResultツリーの各々は根ノードを含む根に従属する。これは、データストアにおいて根ノードとasCaseツリーとの関係を記録する結果となる。すなわち、asCaseツリーとasResultツリーとの組合わせは、インタロックツリーのノードのあり得るすべてのコンテキストを捉える。asCaseツリーとasResultツリーとの組合わせは、根ノード間のコンテキストまたは関係を知ることが有用であるようなすべての目的のために用いることができる。たとえば、インタロックツリーデータストアジェネレータへの入力が、セールスマンの名前、曜日、品目の数および州を含む販売データの母集団を含む場合、結果として生じた生成されたインタロックツリーデータストアのasCaseリンクおよびasResultリンクを用いて、「特定の州でどのセールスマンが売るのか」「月曜にはいくつの品目が売られたか」「セールスマンであるボブ（Ｂｏｂ）は月曜と火曜とでいくつの品目を売ったか」といった情報を、データストアのコピーを複数生成することなくすべて同じインタロックツリーデータストアから抽出することができる。

上述の関係の情報は、ツリーのサブコンポーネントおよび最終製品ノードに明示的に記憶されるのではなく、構築されるインタロックツリーデータストアの構造内に実際に記憶されることが認識される。インタロックツリーデータストアの要素的根ノードだけがデータを含むことができるので、CaseリンクおよびResultリンクを辿って根ノードまで戻り、データストリームからオリジナルデータを決定し、または再構築することができる。

例示的な計算環境
図１は、本発明の局面が実現され得る例示的なコンピュータシステム１００のブロック図である。コンピュータシステム１００は、メインフレーム、ミニコンピュータ、ＩＢＭ互換のパーソナルコンピュータ、Ｕｎｉｘ（登録商標）ワークステーションまたはネットワークコンピュータなどのいかなる適切なシステムでもよいが、これらに限定されない。
当業者は本発明の装置が、マルチユーザコンピュータシステムまたはシングルユーザコンピュータを含むがこれらに限定されないいかなるコンピュータシステムにも適用され得ることを認識する。図１に示されるように、コンピュータシステム１００は、メインメモリ１０４、補助記憶インターフェース１０６、端末インターフェース１０８、およびネットワークインターフェース１１０に接続された中央処理装置（ＣＰＵ）１０２を含む。これらのシステムコンポーネントはシステムバス１６０を介して接続される。補助記憶インターフェース１０６は、ディスク１９５などであるがこれに限定されないディスク上にデータを記憶するＤＡＳＤ装置１９０などであるがこれに限定されない記憶装置を、コンピュータシステム１００に接続するために用いられる。

コンピュータシステム１００の仮想メモリ全体を包含するメインメモリ１０４は、オペレーティングシステム１２２およびアプリケーション１２４を含み、インタロックツリーデータストア１２６をさらに含んでもよい。インタロックツリーデータストア１２６は、データの複製を必要とせずに複数のコンテキストモードにおいてデータを求めて素早く探索することができるデータ構造を与えるために用いられてもよい。コンピュータシステム１００は、コンピュータシステム１００のプログラムが、メインメモリ１０４およびＤＡＳＤ装置１９０などの複数のより小さな記憶エンティティへのアクセスではなく大きな単一の記憶エンティティにアクセスを有するかのように振舞うことを可能にする、周知の仮想アドレス機構を用いてもよい。したがって、オペレーティングシステム１２２、アプリケーション１２４、およびインタロックツリーデータストア１２６がメインメモリ１０４に存在するように示されるが、当業者はこれらの要素がメインメモリ１０４内にすべて完全に同時に位置していなければならないわけではないことを認識する。

コンピュータシステム１００が単一のＣＰＵおよびシステムバスのみを含むように示されているが、当業者は本発明が複数のＣＰＵおよび／またはバスを含むシステムを用いて実現され得ることを理解する。１つ以上の端末をコンピュータシステム１００に接続するために端末インターフェース１０８が用いられてもよい。参照される端末はダム端末または完全にプログラム可能なワークステーションであってもよく、システム管理者およびユーザがコンピュータシステム１００と通信することを可能にするために採用することができる。

コンピュータシステム１００に他のコンピュータシステムおよび／またはワークステーションを接続するためにネットワークインターフェース１１０が用いられてもよい。インターフェース１１０がインターフェースするネットワークは、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、インターネット（internet）、エキストラネットもしくはインターネット（Internet）、または他の適切なネットワークであってもよい。オペレーティングシステム１２２は、ＯＳ／２、ＷＩＮＤＯＷＳ（登録商標）、ＡＩＸ（登録商標）、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）または他の適切なオペレーティングシステムなどのオペレーティングシステムであってもよい。

アプリケーションプログラム１２４は、インタロックツリーデータストア１２６に記憶されたデータにアクセスする任意の種類のアプリケーションプログラムであり得る。したがって、このアプリケーションは、本発明はこれらに限定されないがいくつかの例を示すために挙げると、データ解析アプリケーション、データウェアハウジングアプリケーション、侵入探知システムなどを含む。

インタロックツリーデータストア１２６は、ユーザが任意のコンテキストに関連付けられた情報を得るために同じデータストアにアクセスすることができるようにするデータ記憶構造を与える。本願明細書に用いられるように、データという用語は、数、テキスト、グラフィック、定式、表、オーディオ、ビデオ、マルチメディアまたはそれのあらゆる組
合わせなどであるがこれらに限定されない、いかなる種類のコンピュータに記憶された情報をも含むことができる。インタロックツリーデータストア１２６は、アプリケーション１２４の一部として、オペレーティングシステム１２２の一部として、または種々様々のアプリケーションにデータ記憶を与えるために適合され得る個別のデータストアプロダクトとして、実現することができる。

本発明は、完全に機能的なコンピュータシステムのコンテキストで説明されているが、当業者は、本発明がさまざまな形式のプログラムプロダクトとして流通されることができ、本発明がこの流通を実現する特定の種類の信号運搬媒体に拘らず等しく適用できることを認識する。このような信号を運搬する媒体の例は、フロッピー（登録商標）ディスク、ハードドライブ、ＣＤ ＲＯＭ、電気的、光学的、無線通信または他の適切な媒体上のデジタルおよびアナログ通信リンクを含むがこれらに限定されない。さらに必要となれば、ここで説明している種類のインタロックツリーデータストアをコンピュータシステムにわたって分散することが可能である。

図２は、保存されているＫＳｔｏｒｅを表わすブロックを包含していること以外は、図１と類似する。他は、繰返されている図２の要素は単にその識別番号の後ろに「ａ」が付加されただけである。Ｋｓｔｏｒｅ（データストア１２６ａ）は、ここではコンピュータシステムのアクティブメモリ１０４ａにある保存ルーチン１２８によって動いている。保存プロセスが完成した後それを復元するために、さらに復元ルーチン１２９があり、便宜のために同じくアクティブメインメモリ１０４ａに示されるが、必要なときまたは所望に応じてそれらを入れ替えることができる。そのプロセスは、ヘッダスペース１２７ｒ、およびプロセスが進行するにつれてＫＳｔｏｒｅ構造のノードを表わすパケットを生成し、好ましくは、領域１２７ｓとしてのアクティブメモリ中に保存されるように構造上で作用する。便利に参照するために、メモリにおけるこの作業スペースを領域１２７と呼ぶ。代替的には、スペース１２７は非常に小さくてよく、保存ルーチン１２８によって生成されている現在進行中のノードパケットか、代替的にはＫＳｔｏｒｅが復元されている場合は復元ルーチン１２９によって復元されているノードパケットのみを有する。ＫＳｔｏｒｅが復元されている場合、スペース１２７は必要でないかもしれないが、ＫＳｔｏｒｅが横断され、ノードが復元プロセス中に加えられている場合には、テストスペースまたは作業スペースとして望ましいかもしれない。ノードがパケットに変えられ、それが形成される間ファイルとしてメモリに流された場合、それは永久記録装置へのストリームファイルとして直ちに流される速度で生成されてもよい。少なくともそのような場合は、ストリームファイルのセットアップによってＯＳおよびデータ記憶システムがこれを自動的に扱うようにされるので、記憶装置のパケットにメモリを割当てることは必要なステップではない。

上記に挙げられたテキストの例（「ＢＯＴ−Ｃ−Ａ−Ｔ−ＥＯＴ」および「ＢＯＴ−Ｔ−Ａ−Ｂ−ＥＯＴ」）においては、入力の母集団が、単語がそこから派生し
得る英数字文字の集合であることが認識されるが、ＫＳｔｏｒｅデータストア構造はそれに限定されない。たとえば、入力の母集団は、（単語がそこから派生し得る）文字または（句または文がそこから派生し得る）単語などのテキストであってもよい。さらに、ＫＳｔｏｒｅの母集団は、代替的には、そこからゲノムが派生し得るアミノ酸、プロセスにおいて用いられる限定的なリソース、概念、ピクセル集合、画像、音、数、アナログ測定もしくは値、または最終製品を生成するためにデジタル化され（またはそうでなければ情報記憶フォーマット、たとえば量子的状態の表現などに入力され）連続して組合わせることができる要素的単位から構成される、他の適切な母集団からできていてもよい。

上記ノードに加えて、インタロックツリーデータストアは、（たとえば図１０を用いて）たとえばリンク９６、９７、９９および９８などの、ノード間のいくつかの接続または
リンクをも含むことができる。本発明の１つの実施例におけるリンクは双方向である。リンク９６および９９は本願明細書でasCaseリンクと呼ばれる。９７および９８のようなリンクは本願明細書でasResultリンクと呼ばれる。本発明の好ましい実施例においては、開始インジケータがサブコンポーネントの第２の部分にならないので、開始インジケータ概念または条件を表わす根ノードはヌルのasResultリストを有し、データセット要素がサブコンポーネントの第１の部分にならないので、データセット要素を表わす根ノードはヌルのasCaseリストを有し、かつ終了インジケータがサブコンポーネントの第１の部分にならないので、終了インジケータ概念または条件を表わす根ノードはヌルのasCaseリストを有することが認識され得る。最後に、最終製品が次のレベルのデータセット要素の役割をするので、最終製品根ノードはヌルのasCaseリストを有する。

インタロックツリーデータストアのノードはすべて、前記ノードに関連付けられた情報を表わす付加的なフィールドをも含み得る。これは図９を用いて示され得る。しかしながら、ほぼすべての好ましい実施例において、データが根ノードのみに記憶されることに注意されたい。付加的なフィールドを有しても、ほとんどの実施例におけるほとんどのノードはストリングデータを有し得ない。所望であれば、通常、（もしあれば）付加的なフィールドは、カウントまたは恐らくノードタイプのインジケータを記憶するために用いられてもよい。

例示的なノード３０が図９に示される。このノード３０は、付加的なフィールドとしてストリングフィールドを含んでもよく、それはこのノードによって表わされる要素的根ノードのすべてを示すシーケンスを包含する。この要素のシーケンスを含むストリングフィールドを付加することは、デバッグにおいて有用である。そのような付加的なフィールドについては多くの用途があり得、ノード３０などのノードは１つの付加的なフィールドに限定される必要はない。しかしながら、典型的には、付加的なフィールドはストリングではなくカウントを包含し、１つを越える付加的なフィールドがあり得る。これらのフィールドの数および性質は、構築しているＫＳｔｏｒｅの所与の性質によって異なる。

例示的なノード３０は、フィールド３１としてカウントフィールドをも含み得る。カウントフィールドは示強変数によって初期化されてインクリメントされ、その値はカウントフィールドが参照されるときの条件に応じて異なる（示強変数は少なくとも１つの不変の値を保持する数学的なエンティティとして規定される）。この用語を非常に広くすることによって、示強変数に占められたカウントフィールドは、この発明のインタロックツリー構造のアプリケーションと、誤った記録されたデータを忘れることに対処し、どのエンティティが照会を行っているかを記録し、かつ用いられている照会の種類を記録するプロセスと、データを用いるときに派生し得る他の興味のあるプロセスとに用いることができる。示強変数の簡単な例示的形式は、単一の順序のフィールド値であって、ノードがアクセスされたり横断されたりした回数を記録するためのカウントフィールドをインクリメントしたりデクリメントしたりするために用いられる「１」などである。

さらに、asCaseリストフィールド３３へのポインタが最終製品ノードについてヌルになり、asResultリストフィールド３４へのポインタはすべてのサブコンポーネントノードについてヌルになり、２つ（すなわちasCaseリストへのポインタまたはasResultリストへのポインタ）のうちの１つが要素的ノードについてヌルになることが認識される。この認識により、２つのフィールドのうちの１つがすべての場合においてヌルになることがわかっており、ノードパケットにおいて１つのフィールドしか必要としないので、本願明細書に別記されるように、保存動作中にタイプ３のノードパケットの生成が可能になる。このリストカウントは、ノードの経験した頻度および強度の記録を維持するカウンタフィールドと区別される。

さらに、示強変数はこれらのさまざまな機能のために異なる速さで、および異なる方向に変わり得る。異なる強度の簡単な例として、クエリがノードを横切るたびに値＋１が加算されること、また特定のノード（またはノードの特定のシーケンス）を包含している経路が（この説明には重要ではない何らかの重要な理由で）誤りであると考えられる場合、たとえば、使用後にシーケンスがミススペルだったことが発覚した場合、センサが危険な化学薬品を包含する領域を見つけた場合、または人間の子供のシミュレータがシミュレーションにおいて熱いストーブに「触れ」、「火傷をした」場合などには、−１００という値が加算されること、が挙げられる。示強変数の代替としては、各種類のノード横断に対して新しい値を保持するために個別のノードを用いることがあり、したがってノードがタイプ１、タイプ２、経験１、経験２、および無限などのクエリの間にアクセスされるような状況でクラスタを生成する。この構造の実世界での適用に関して考察すると、カウントフィールドの示強変数は、この問題について最も簡単な、したがって現在での最良の手法をもたらすが、この代案または他の代案は、情報処理システムの性質と見なされ、再考されるべきである。この代案が考慮される場合、個別のノード、恐らくは要素的ノードまたは根ノードさえも用いてノードに関連する各タイプの横断回数のカウントを記録する手法が、この手法を実現する１つの方法であろう。

このように、１つの使用では、新しいデータがインタロックツリーデータストアに組込まれているときにカウントフィールドはインクリメントされ得るが、インタロックツリーデータストアがクエリされて新しいデータに対するより大きな値を生じ、照会については変化がないときは、カウントフィールドをインクリメントすることは省略され得る。したがって、この示強変数はＫＳｔｏｒｅが対処している問題に適合するので、動的に選択され得る。

カウントフィールドはインタロックツリー構造によってインスタンス化された知識ストアの使用を容易にするために付加され、特に頻度および確率などの統計が求められるときに有用である。

さらに、カウントフィールドがノードに存在し、ノードの経験した頻度および強度に対応する場合、所望であれば、ノードがカウントフィールド内にゼロ値を有しているならそれらのノードのいずれかを保存から消去することができることが認識されるべきである。ヌル値のノードのこのような消去は、検査において、任意の復元され得るＫｓｔｏｒｅが用いられる用途に要素的根ノードが必要でない場合、ゼロ値のカウントフィールドを備えた要素的根ノードにさえも用いることができる。（このように、所望であれば値の小さいカウントであっても消去ができる。ゼロ値と等価である必要はない）。ＫＳｔｏｒｅの開発者がいくつかのパーティクルを保存しており、自分のデータのほとんどを集めてみるとそれが有用でないことがわかった場合にもこれは起こり得る。その場合開発者は確信をもってこれらの要素的根ノードを消去することができる。さらに、カウントフィールドの値に引き算があり得るような状況では、このようなノードも、誤りやミススペルなどを表わし得るので保存から消去することができる。当然ながら、生成されたいかなるノードも消去したくない状況もあり、そのような状況では、履歴を維持するために、ヌル値を備えたノードさえもカウントフィールドに保存される。

図９のノード３０は、値フィールド３２を有する要素的ノード３０Ａまたは（値フィールド３２が欠落している）サブコンポーネントノードもしくは最終製品ノード３０Ｂであり得るが、いずれのインスタンスにも付加的なフィールドまたはフィールド３１を有し得る。

付加的なフィールドの特定のインスタンスが図９に示される。ノード３０（（値フィールド３２を備えた）要素的ノード３０Ａまたはサブコンポーネントもしくは最終製品ノー
ド３０Ｂのいずれか）などのノードの両方が付加的なフィールド３１を有する。この付加的なフィールド（好みであれば複数のフィールド）は、所望のいかなる情報も包含することができる。たとえば、これが特定の種類のノード（センサ、最終製品または他の種類のノードなどのノードタイプ）であること、またはそれがＥＯＴまたはＢＯＴからのノードカウントによって特定の日付または距離で生成されたこと、またはそれを用いて行いたいことであれば何であっても知りたいと思うであろう。

さらに、所望であれば、保存の組織化を支援するためにパケット内にパケットを保存することが有用である。図１３では、より大きなパケット１４０内に１組のノードパケット０…ｎ、１４１、１４２、１４３、…１４４、を有している。好ましくはパケット０…ｎの第１のパケット、パケット１４１はヘッダパケットであり、より大きなパケット１４０におけるすべての続くパケットに何が共通であるかについての情報を包含している。このヘッダパケットはほとんどの好ましい実施例においてはノードに再構成されないが、復元プロセスに役立つ情報を包含している。このパケット内パケットの構造を用いることは、各タイプの中に異なるフィールドを有するので、他のノードと別個に、それぞれ固有のパケット内で、要素的根ノード、ＢＯＴノードならびにＥＯＴノードおよび最終製品ノードを記憶することを容易にする。たとえば、根ノードはasResultポインタで満たされたasResultリストを有するが、サブコンポーネントノードはそのようなリストを有しない。さらに、下位層と次に続く上位層との復元を容易に行うため、ここでも復元処理を容易にするよう、ノードの層も一緒に記憶することができる。

タイプの分類は明確にされなければならない。上述の３つの新しいパケットタイプがある。これらのパケットタイプは、本来のノードが有していたasResultリンクまたはasCaseリンクの数を追跡する１つまたは２つの付加的なカウントフィールドを有すること、または有していないことによって識別可能である。これらのタイプは、所望であれば、asResultもasCaseリンクも有しないノードを記憶するために便宜的に用いられてもよいが、これらのリンクを有しないノードがある。そのようなノードは、典型的には、それがメンバであるasResultリスト、およびそれがメンバであるasCaseリストを備えたノードへのポインタと、Caseポインタ、Resultポインタおよびカウントフィールドとを有するサブコンポーネントノードである。したがって、これを異なるタイプのノードと呼ぶことができるかもしれない。しかしながら、この特許については、パケットにいかなる種類の情報を保存し、そこからこのＫＳｔｏｒｅの（いくらかまたはすべての）ノードが保存中に保存されるかを指定するために、１、２、または３のタイプ指定を用いる。タイプ１、２および３のノードの完全な定義については上述される。ノードのパケット（パケット内のパケット）にサブコンポーネントノードを保存していれば、asCaseリストおよびasResultリストのいずれも有しないので、ノードタイプを指定する必要がない。

ＫＳｔｏｒｅの層の概念をここでかなり詳細に説明し、復元がいかにこの階層化を利用することができるかについても詳細に議論することが有用である。先行する出願である米国連続番号第１０／８７９，３２９号に層の使用について記述したが、その出願の中で用いられたものに類似した図を図１２として加えた。最下位の層が、文字である要素的根ノード９０２を有するパーティクルレベルから単語を構築することに注意されたい。ＢＯＴ９０１およびＥＯＴ９０３も要素的根ノードだがそれらの特別な場合である。次の上位の層の単語はすべて最終製品ノード９０８、９０６および９０４である。最上位の層の最終製品ノード９０２は文ノード、ＣＡＴＳ ＡＲＥ ＦＵＲＲＹである。さらに、ＢＯＳ９０４ノードおよびＥＯＳ９０５ノードは、単語ノード９０４、９０６および９０８とともに、この層の根ノードである。したがって、根ノードはその上の層にasResultポインタを有する。

このように、順番に保存し復元すれば、ＢＯＴノード９０１から始めてグラフの下部か
ら上へ動く。これは、このレベルにおいてこのＫＳｔｏｒｅの３つの単語の各々についてＢＯＴ Ｃ、ＢＯＴ Ａ（９５１）、ＢＯＴ Ｆのケースノードを指し、ノード９０４、９０６および９０８でそれぞれ終わる。これを行うために、パケットを用いて、ＢＯＴをまず見つけ、復元された（復元されている）メモリにおいてこのノードに割当てられた新しいアドレスとともに単にＢＯＴのための古いアドレスをアドレス変換表に入れ、要素的根ノードに移り、それらの古いアドレスおよび新しいアドレスに対して同じことを行う。要素的根ノードパケットのリストは、Ｃ、Ａ、Ｔ、Ｓ、Ｒ、Ｅ、Ｆ、ＵおよびＹ、（９０２）、特別なケースの要素的根ノードＥＯＴ９０３である。先ほど述べたように、アドレス変換表にその古いメモリ位置と新しいメモリ位置とを採用する。これらの要素的ノードのResultであるノードを復元する間、アドレス変換表においてこれらの根ノードのためのアドレスが既に確立されているので、そのポインタのためにノードに記憶する新しいアドレスがわかっている。サブコンポーネントノードパケットもそのasCaseポインタを有するであろう。なぜならば、Case分岐におけるその先行者が（ここではＢＯＴ、次にＣ、次にＡなど）まず復元され、既にアドレス変換表の中に新しいアドレスを有しているからである。次のレベルに移り、次に文のためのノードＢＯＳ９０４を復元する。サブコンポーネントノードは根ノード９０４、９０６および９０８を有し、それらはＫＳｔｏｒｅのレベル１部分の最終製品ノードであることがわかっている。最終製品ノードはこのレベルについてはノード９０２になり、さらにそれはＥＯＳノード９０５を有し、それはＢＯＳノード９０４の後にパケットから復元されることが好ましい。この第２のレベルのパケットから復元されたノードの各々は自身の新しいメモリアドレスを有し、今説明したこの１つの経路プロセスに復元されれば、そのポインタはすべて下位レベルのノードまたはＢＯＳノードおよびＥＯＳノードを指す。この単一パスプロセスを用いずにＫＳｔｏｒｅを復元することは可能であるが、すると第１の経路上で何らかの種類のプレースホールダを用いて、第１の経路の後にポインタ用の新しいアドレス変換に対し欠落した古いアドレスを埋めるために戻らなければならない。そのような反復的な処理は必然的により遅く、不必要に複雑である。

実現は極めて柔軟に行われる。たとえば、ＫＳｔｏｒｅでは、リンクされたリストとしてasCaseリストおよびasResultリストを実現してもよい。別の実施例では、asCaseリストおよびasResultリストは構成可能なサイズの隣接するメモリ位置のブロックとして、これに限定されないがアレイなどに割付けることができる。復元を開始する際にこの情報を知っていることは非常に重要である。そのようなリストがある組織の種類の表示は、デフォルトとして、またはパケットヘッダ、もしくはノードパケットが組織される大きなパケットのヘッダもしくはリードパケットに置かれた何らかの種類のメタデータインジケータとして、扱うことができる。いかなる場合も、いかなるasCaseリストにもasCaseリストの開始位置にセットされるポインタがあり得、いかなるasResultリストへのポインタもあり得る。このメタデータを扱う適切なアルゴリズムプロセスは、好ましい実施例においてメタデータ自体によってトリガされる。ＫＳｔｏｒｅはノードの中にasCaseリストとasResultリストと保持するように組織され、または好ましくは、（いかに組織されていても）そのようなリストは、それらへのポインタのみをＫＳｔｏｒｅ構造において記憶する。ノードパケットに記憶されたポインタリストのカウントは、適切なサイズのポインタリストを用いてパケットをノードとして復元するための適切な量のメモリを割当てることを可能にする。復元がＫを復元するために順序づけられた態様で用いられ得るので、復元順序に注意する限り、asCaseリストまたはasResultリストを記憶する必要は全くない。復元が復元プロセス中にこれらのリストを生成するからである。そのためには適切なサイズのメモリがぜひとも欲しいが、それがポインタリスト上にポインタカウントを保存する理由である。

（米国連続番号第１０／７５９，４６６号に記載された）この保存および復元システムの旧バージョンの発明の１つの実施例では、新しいノードから、そこから新しいノードが派生するノードまでリンクを再生することに加えて、新しいノードの位置へのポインタが
、そこから新しいノードが派生するノードの、リンクされたリスト、asCaseリストおよびasResultリストに加えられる。ポインタはリストの終わり、リストの始めに加えられても、またはリスト内のどこかに挿入されてもよい。さらに、いくつかの順序付けられたリストが維持されてもよい。たとえば、ノードのasCaseリストは連続するリストを含んでいてもよく、そこではポインタは、順序づけられたリストに加えてリンクされたリストの終わりにも加えられ、そこでポインタは最も頻繁にアクセスされる順に維持される。所与の例は１つの順序付けられたリストおよび１つの連続するリストを引用するが、本発明はそれに限定されないことが理解され、本発明の範囲内でいかなる組合わせおよびリストの数も考慮される。順序づけられたリストは、最後の更新時順、最後のアクセス順、もしくは更新もしくはアクセスの頻度順に、または他の適切な順序付けの規則によって順序付けられる。この構造に関する情報は、メタデータとして同様に保存される必要があり得、さらに、それはＫＳｔｏｒｅ状態の変数情報とも考えられる。本願明細書に記述された新しい発明では、この説明の残りの部分で説明されるように、そのようなリストを維持する必要は全くないが、与えられた状況において望ましい場合には特定の場合のためにそうするよう決定してもよい。しかしながら、順序付けられたリストの順序を維持しないときは順序を失うので、順序を維持し、本発明の代わりに古い方法を用いたい状況があるかもしれない。代替的には、頻度に基づいたリストなど何らかの基礎に基づいてリストの順序を復元することができる。

ＫＳｔｏｒｅデータ構造のほとんどの好ましい実施例では、より高いレベルの根ノードを表わすノードは、データもしくはデータ表現または概念を包含していない。すなわち、より高位レベルの根ノードはより下位レベルのノードへのポインタしか包含していない。異なるレベルの根ノードについての情報は保存され得るメタデータの別の局面となる。

いかなる適切な数のレベルも生成され得る。たとえば、テキストの世界では、レベルは、文字、単語、文、段落、章、本、図書館などを表わし得る。例示的な図面ではインタロックツリーデータストアは２つのレベルを有するが、ＫＳｔｏｒｅの発明はそのように限定されないことが理解される。インタロックツリーデータストアのいかなる数のレベルも構築することができる。この例の母集団が、テキスト、すなわち単語からの文字の組合わせ（１レベルの最終製品）であるので、本発明のこの実施例における単語の組合わせの結果は、句または文（別のレベルの最終製品）である。文は段落を形成するために組合わせられ、段落は章または部を形成するために組合わせられ、などと続き得る。

ＫＳｔｏｒｅを適切に復元するためには、要素的根ノード（センサ）および要素的根ノードに関連付けられた一定の値を記憶する必要がある。センサ値が、ＫＳｔｏｒｅ構造を生成する通常の過程でノードと無関係に保存される場合、これらの値のファイルおよび要素的根ノードへ戻るポインタは（ポインタアドレスに関して一般に記述されるようなポインタに必要とされ得るアドレス変更のために適応して）単にそのまま保存することができる。センサ値がノードに実際に記憶されるようなＫＳｔｏｒｅの場合には、ノードが保存動作中に保存されるとき、値は他の要素的根ノード情報とともに保存される。このように、保存プロセスが保存されているＫＳｔｏｒｅに適合されることが明らかである。

最終製品ノードは、入力母集団に依存して、単語、句、文など以外のエンティティを表わし得ることがさらに理解される。多くの例のうち１つとしては、入力が染色体を含むアミノ酸配列である場合、１つの最終製品は遺伝子または対立遺伝子を表わし得る。別の例において、ピクセルシーケンスは、線、円または他の形状の品目である最終製品を有し得る。

ＫＳｔｏｒｅ構造の探索は比較的単純であり、以前の特許出願にも記載され、それをいかに行うかについて完全に理解することは、ＫＳｔｏｒｅと呼ばれるデータストアをイン
タロックツリーに保存し復元する方法を知るためには必要ではない。しかしながら、便利に参照するために簡潔な説明が含まれている。

ここで図１１のための入力が下記のようなデータレコードを含むことが考慮される：
ビル（Ｂｉｌｌ） 火曜 ４０ 販売 ペンシルバニア州（ＰＡ）
ビル（Ｂｉｌｌ） 月曜 １０３ 販売 ニュージャージー州（ＮＪ）
ビル（Ｂｉｌｌ） 月曜 １００ 試行 ペンシルバニア州（ＰＡ）
トム（Ｔｏｍ） 月曜 ８０ 試行 ペンシルバニア州（ＰＡ）
トム（Ｔｏｍ） 月曜 １３ 試行 ニュージャージー州（ＮＪ）
本発明の１つの実施例では、データセット要素は、これに限定されないが空白文字などのデリミッタによって分離された情報のフィールドから構成される。１つの実施例では、上述のように本発明がそのように限定されないことは理解されるが、データセット要素は入力から派生する。入力データでこれまでに遭遇した変数は、セールスマン名（ビルおよびトム）、曜日（月曜、火曜）、品目の個数（４０、１０３、１００、８０、１３）の数、状態（販売、試行）および州（ペンシルバニア州、ニュージャージー州）である。本発明の１つの実施例では、図１１のインタロックツリーデータストア１０００はこの入力から結果を生じる。図１１では、スペース上の理由でノードの第１の部分は示されない。たとえば、ノード１００２は「ビル」とラベル付けされるが、ノード１００２は実際には「ＢＯＴ−ビル」を表わす。ノード１００４は「火曜」とラベル付けされるが、ノード１００４は実際には「ＢＯＴ−ビル−火曜」を表わす、などと続く。

たとえば、本発明の１つの実施例では、所望のシーケンスを含む経路のサブコンポーネントノードおよび最終製品ノードは、所望のシーケンスを表わす特定の根ノードのasResultリストに包含されるポインタを辿ることにより決定することができる。根ノードのasResultリストがアクセスされ、その根ノードに関連付けられたサブコンポーネントノードまでリストのポインタが辿られる。最終製品が所望の場合、asCase分岐ツリーが分岐の葉ノードまで辿られる。

本発明の１つの実施例では、情報に対するリクエストは制約を指定する形式である（考え方によって「コンテキスト」または「焦点」のいずれかと見なすことができる）。たとえば、情報に対するリクエストは制約リストの形式でもよい。制約リストは入れ子にされても独立していてもよい。本発明の１つの実施例では、リストに記載された各制約の最終製品ノードのasResultリストが見つかり、各制約の各asResultリスト内の各ノードについての経路が見つかり、その経路が最終製品まで辿られて、各制約の各asResultリスト内の各経路についての最終製品の交差が選択される。入れ子にされた制約は、まずデータストアを制約してあるデータの集合を検索し、次にそれがさらに制約されるデータの集合として用いられ、などと続くことにより見つかる。

特定するノードを捜していると言った場合、ＡＮＤはすべての人、場所および物事の集合、すなわち、「人」「場所」および「物事」と呼ばれる要素または根ノードによって特定可能なすべてのノードを連結するものを特定する論理演算子である。「物事」である（別の論理演算子）（ＡＲＥ）すべての「人」および（ＡＮＤ）「場所」は何か、というクエリを与えられたインタロックツリー構造は、回答するため、品目「物事」がどのように特定されようとそれによって制約される。構造を構築する際に物事が全く場所を指さない場合は、クエリでは他のすべての「物事」は見つからないが、インタロックツリー構造において知られているすべての場所は見つかる。構造に組込まれた場合に人が物事として考えられたならば、それもクエリにおいて見つかるであろう。

論理演算子は、ＡＮＤ、ＯＲ、ＮＯＴ、ＧｒｅａｔｅｒＴｈａｎ、ＸＮＯＲ、ＥｑｕａｌＴｏなどの多くの形式をとることができ、組合わせられてもよい。そのようなすべての
論理演算子および組合わせが本発明において使用可能である。比較を示す数式もコンテキストに当然依存して、使用可能である。１００台を越える自動車を販売したセールスマンをすべて見つけることは、たとえば数式が、セールスマンの自動車の販売数＞１００になるような、比較を示す数式に依存するクエリであり得る。

本発明の１つの実施例では、保存される情報を決定するために焦点が用いられてもよい。たとえば、センサが文字である２レベルのデータストアの場合には（図１２のＣＡＴＳ−ＡＲＥ−Ｆｕｒｒｙの図が参照され得る）、レベル１の最終製品は単語を含み、レベル２の最終製品は文を含む。中に文字Ａを有する文だけを保存したければ、Ｋを「Ａ」の根ノードへの接続を備えたノードに制約することになる。次いで、最終製品の単語ノードを見つけるために、ＡからのCaseリンクを通ってこれらの単語を横断しなければならず、そのような各単語があるかについてasResultリストをこれらからチェックする必要がある。次いで、中に文字Ａを有する文を見つけるために、指された文からCaseリンクを横断し、それがあるかもしれない文の最終製品ノードを見つける。Ａのための図１２では、それらの単語９０６および９０８の終わりまでそのCaseリンクをそれぞれ辿って、ノード９５１および９５２に進む。これらのノード９０６および９０８は、ノード９５３および９１６に対してasResultポインタをそれぞれ有する。これらのいずれかのノードからそのCaseリンクを辿るとＥＯＳノード９０２に導かれる。したがって、この例についてはノードをすべて図１２に保存するが、他の文字があるのに中にＡを備えた単語がなければ、それは明らかにこのような部分的保存の中で失われるであろう。

１つの実施例では、その根としてレベル開始インジケータを有するツリーを辿ることによって、制約で始まるすべての最終製品を見つけることができる（たとえば、特定の文字で始まるすべての単語を見つけることができる）。同様に、特定の制約を備えたすべての最終製品、または特定の位置にある特定の制約（たとえば、その中に特定の文字を有するすべての単語、または特定の列の中に特定の文字を有するすべての単語）を見つけることができる。同様に、根としてレベル終了インジケータを有するツリーを辿ることによって、特定の制約で終了するすべての最終製品（たとえば特定の文字で終わるすべての単語）を見つけることができる。複数の制約および／または焦点が特定されてもよい。

部分的保存については、部分的保存の限界を表示するために任意の制約が保存される必要があり得る。したがって、これを図１０のＫＳｔｏｒｅに関連させ、「月曜のすべての情報」をヘッダに入力することは、保存されたＫＳｔｏｒｅが月曜の情報のみを包含することを示す。

ここで図１１を参照して、火曜に販売された装置の総数がいくつかという質問に対する回答が所望されていると仮定する。本発明の１つの実施例では、この情報の検索が、データストア全体のすべてのノードを横断するのではなく、根ノード１０５４および１０５５のasResultリストの検索しか必要としないことが当業者には明らかであろう。火曜１０５４を表わす根ノードがノード１００４を指すので最終製品ノードｌ０３０への経路５が横断され、販売１０５５を表わす根ノードがノード１０２８を指すので最終製品ノード１０４０への経路４が横断される。販売根ノード１０５５がノード１０２６も指すので、経路５も横断される。経路１ １０８０、経路２ １０７０、および経路３ １０６０を横断する必要はない。根ノード１０５４および１０５５が指す経路を辿ることから戻る最終製品の集合の交差は、ビル火曜４０販売ペンシルバニア州を表わすノード１０３０を含む。

入れ子にされた制約は、まずデータストアを制約してデータの集合を検索し、次いでそれがさらに制約されるデータの集合として用いられ、などと続くことによって見つかる。入れ子にされた探索を行うためには、根ノード１０６５から、制約のうち１つ、たとえばＳＯＬＤで始める。２つの特定された最終製品ノード１０３０および１０４０から戻りな
がら追跡するとそのうち１つのみに至るが、それは１０３０のCase経路からの、ノードＴＵＥＳＤＡＹを有する１００４である。このように、この代替的手順でも同じ結果を得る。

ここで図３を参照すると、本発明の実施例と一致する、ノードからの情報を記憶するために必要とされるフィールドを包含しているノードパケットが記述される。タイプ２のノードパケット２２０の第１のフィールドはパケット長フィールド２１１である。このフィールドは絶対に必要というわけではないが、パケットをノードに復元する際通り抜けて行かねばならないために有用であり、次のパケットがどこで開始するかを表示する。ほとんどの場合、パケットサイズはパケットの各フィールドのメモリアドレスに固定されるが、すべてのタイプのパケットにこのフィールドが示される。次のフィールドはケースポインタフィールド２１２であって、当然ながら、図９の説明のノード３０であるCaseノードへのポインタに関連する。次のフィールドはResultポインタ２１３であって、図９のノードの、Resultノードへのポインタを包含している。付加的なフィールド２１４は簡潔さのためにここでは簡略化され、図９のノード３０の値フィールドと同様に任意の付加的なフィールドを含んでいてもよい。フィールド２１５は古いノードアドレスを包含する。

タイプ１のノードパケット２００は図４に示される。これはパケット長２０１、Caseポインタ２０２、Resultポインタ２０３、付加的なフィールド２０４および古いノードアドレス２０７、に対応するフィールドを有する。さらにこれはasCaseポインタリストカウントおよびasResultポインタリストカウント２０５および２０６のためのフィールドを有する。これらのカウントは、復元を行うときに割当てが必要なメモリのサイズ合計を決定することを助けるよう用いることができる。上述されたように、ＢＯＴノードおよびサブコンポーネントノードはasCaseポインタリストを有し、根ノードだけがasResultリストを有するので、フィールド２０５および２０６のためには１つのカウントしか実際には必要ではない。しかしながら、このタイプ１のノードを用いる場合、ノードをパケットに処理するためのアルゴリズムがより簡単である。根ノードは、要素的根ノード（しかし一種の要素的根ノードであるＢＯＴではない）または最終製品ノードのいずれかとして規定されることが明らかである。

しかしながら、タイプ１のノードパケットを用いることができるいかなる状況においてもタイプ３のノードパケットを代わりに用いることができ、それはasResultリストポインタまたはasCaseリストポインタのいずれかのカウントを保持するために単一のフィールド「ポインタリストカウント」リストカウントを有する。したがって図５では、任意のノードから作られたパケットは、パケット長フィールド２３１、Caseポインタフィールド２３２、Resultポインタフィールド２３３、付加的なフィールド２３４、ポインタリストカウント２３５および古いノードアドレスフィールド２３７を有するパケット２３０のようであり得る。

特許出願番号第１０／３８５，４２１号および第１０／６６６，３８２号のインタロックツリーデータストアの好ましい実施例の説明からわかるように、asCaseポインタリストは、asResultポインタリストと同様、それ自体ノードに直接記憶されたのではなく、ノードにおけるポインタがリストが記憶された領域を表示したのである。しかしながら、米国特許出願番号第１０／７５９，４６６号に記載された最初の「保存および復元」の発明においては、そのアドレスを有するノードとともにasCaseポインタリストを保存することが好ましかった。インタロックツリーデータストア構造を復元することができるように各ノードを保存するための好ましい実施例を用いる際に、この発明ではasCaseリストおよびAsResultリストは保存されない。そうではなく、復元プロセスの好ましい実施例では、asCaseポインタおよびasResultポインタの保存されたリストに依存する必要なく復元が行われる。

現在の発明はさらに３つの異なるタイプのノードパケットを利用することもできる。第１のタイプ、タイプ１のノードパケットは、asCaseリストポインタカウントおよびasResultリストポインタカウントの両方を包含する。タイプ３と呼ばれるタイプ１の変形は、２つのポインタリストカウントの代わりに１つのポインタリストカウントを包含する（１つはヌル値になるからである）。最後のタイプ、タイプ２はいかなるポインタリストカウントも全く有しない。したがって、タイプ１および３のパケットを形成するノードはasCaseおよび／またはasResultリストを有し、タイプ２を形成するノードは有さない。これらのカウントを得るためには、ポインタリストが記憶されているところがどこであってもそこへ行かねばならず、リンクされたリスト内である場合、リンクを辿ることによって、またはリンクされたリストにおける何らかのヘッダ情報によって、このリストのポインタのカウントを得る。したがって、それが１つのステップおよび一層の処理の両方を減じるので、一般にこれらのポインタリストのいかなる使用も必要としないタイプ２パケットを用いることが好まれる。ここでも、タイプ１のノードパケットが構築されていればasCaseポインタリストまたはasResultポインタリストのためのカウンタのいずれかを有するが、両方ではない。したがって、タイプ３ノードパケットの使用も可能になり、いずれのタイプであったとしても、それはポインタリストカウントと呼ばれるフィールドに非ヌルのカウントを入れる。ここでも、いずれのノードパケットタイプも交換可能に利用され得ることが認識され得るが、asCaseリストおよびasResultリストのタイプおよびサイズは、あるノードパケットタイプの１つの実現例が他のノードパケットタイプより効率的であるような状況を生成し得る。asCaseポインタリストおよびasResultポインタリストが、アレイを用いて実現されるか、経験によって決定されるように比較的大きいか、または静的なデータベースから構築される場合、パケット長、任意の付加的なフィールド、Caseポインタ、Resultポインタ、および、ポインタリストカウントもしくはasCaseポインタリストカウントおよびasResultポインタリストカウントのいずれか、ならびにノードの古いアドレスを包含するタイプ１もしくはタイプ３のノードパケットが用いられるべきである。asCaseポインタリストおよびasResultポインタリストが短いリンクされたリストを用いて実現される場合、経験によって決定されるように比較的小さい場合、または動的なデータベースから構築される場合は、パケット長、任意の付加的なフィールド、Resultポインタ、Caseポインタ、およびノードの古いアドレスを包含するタイプ２のノードパケットが用いられてもよい。

当然ながら、ノードのタイプ（および、したがって、ポインタリストカウントがasCaseかまたはasResultか）は、それが何にリンクされるか、およびそれに何がリンクされるかによって決定され得ることに注意されるべきである。

復元されたＫに必要とされるメモリを割付けるとき、最初にＫを生成したときに用いたものと同じプロセスを用いる。リンクされたリストについては、必要に応じて、新しいリンクのためにメモリを割付ける。アレイについては、最初のサイズから始めて必要に応じて漸増的にサイズ変更する。

さらに、２つのタイプのパケット、タイプ１およびタイプ２、またはタイプ３およびタイプ２を生成する保存ルーチンを有し、そこでタイプ２をサブコンポーネントノードのために、タイプ１もしくは３をasCaseリストポインタもしくはasResultリストポインタを備えたノードのために、用いることも可能である。ノードの読取りに基づいていずれのタイプのパケットが最適かを確かめるためにパケットチェックを設定するアルゴリズムを単に用いることもできる。組合わせを用うことを望むかもしれないいかなる場合でもタイプ１のパケットとタイプ３のパケットとの使用の組合わせは好ましくなのは明らかであるが、前に説明した理由で、単一の保存されたＫにおいて２つのタイプのノードパケットを組合わせるのが好ましくないことに注意するべきである。サブコンポーネントノードはasCase
リストを有するが、これらは要素的ノードまたは最終製品ノード用のものより小さなリストになると思われる。したがって、タイプ２は最もあり得る状況ではそれらのノードについてより適しているであろう。

保存される装置の基礎的な構造が理解されたので、ここで保存を行うプロセスの説明を続ける。

ここで図６を参照して、フロー図７０が本発明の保存部分の好ましい実施例を示す。ユーザまたはシステムがステップ７１で保存を開始することを決定すると、始まる。クエリ７３において部分的保存または完全な保存が予想されることが決定され、ままた示される。ＫＳｔｏｒｅの構築において、考慮中の特定のＫＳｔｏｒｅインスタンスを記述する１組のメタデータ７２が生成される。部分的保存が選択されていると仮定すると、所望のサイズ、根ノードの詳細、および保存に必要なＫＳｔｏｒｅの部分の他の局面に関するユーザ入力７４（自動システムから来る場合はユーザ入力と考えることもできる）が、このプロセスについて利用可能になる。

ステップ７５において、Ｋｓｔｏｒｅデータ構造の保存を可能にするための３つの方法論のうちの少なくとも１つが選択される。それが部分的保存でない場合、方法論のこの選択は、ＫＳｔｏｒｅデータ構造上の制約に関するユーザ入力なしで生じるであろう。ユーザが選択できるか、またはＫＳｔｏｒｅの公知のパラメータに基づいてユーザのために選択されることができる。たとえば、非常に大きいasCaseリストを備えたＫであることがわかっている場合、好ましい保存の方法は、復元の際これらが再建されることを可能にし、その結果、すべてのノードについてタイプ２のノードパケットの選択がされるようにして、これらのリストを追跡する必要性をなくすことであろう。ユーザは、各ノードがasCaseリストポインタまたはasResultポインタについて非ヌル値を備えているか否かを確かめる、より複雑な保存アルゴリズムを選択してもよく、その値が非ヌルである場合は、タイプ１またはタイプ３のノードパケットを構築するが、値がヌルである場合は、これらのノードについてタイプ２のノードパケットを構築してもよい。または、方法は、単にタイプ１またはタイプ３のノードパケットを用いることを選択し、検査中のノードにasCaseリストポインタもしくはasResultリストポインタがない場合は、ヌル値を記憶してもよい。方法論の選択の別の主な局面は、パケットに形成されるノードの各々を見つけるためにＫを横断する順序を決定することである。

本発明の好ましい形式では、メタデータのさまざまな局面を含む支持構造は、後（ステップ８４またはその近くなど）で行うことも可能ではあるが、ステップ７６でまず保存されなければならない。このステップでは、図１３に関して上述されたパケット内パケットのフォーマットで情報を保存してもよく、または当業者が便利であると考える別の方法によってそのような情報を保存することができる。パケット内パケットの技術を用いれば、またはこれも上述したように層で保存するか、もしくはその両方をした場合
、各層について次のステップに従い、次にステップ７６に戻って次の層の保存を開始することができる。次の層を保存する際、ステップ７７およびこの次の層の中のすべてのノード（またはパケットに属する種類の少なくともすべてのノード、次にこの層から構築され得る他のパケットにおけるノード）を保存する反復的なプロセスに再び移る前に、この次の層の中のすべてのノードについてのいかなる情報をもここでも保存する。ステップ７７において、ノードおよびＫＳｔｏｒｅデータ構造の大部分が保存される。現在において好ましくない方法論がＫＳｔｏｒｅ構造の保存のために選択される場合、シングルステップでステップ７７を完了することが可能である。メモリ画像をすべての完全なメモリアドレスとともに保存することができ、同じ位置に復元することができる場合、ステップ７７はシングルステップとして達成され得る。しかしながら、これは部分的保存の場合には可能ではないと思われ、あるコンピュータから別のコンピュータへＫＳｔｏｒｅ構造が移動さ
れるか、または、保存構造がメインメモリ内で復元され得る正確な位置について制御ができないような状況でも、可能ではない。ステップ７７において、第１のステップは、ステップ７８において、選択された方法論によって提示された第１のノードから始めることであり、ステップ７９において、古いアドレスを見つけてそのノードのメインメモリから保存し、かつ利用されるノードパケットのタイプに依存して、このノードの特定のフィールドとともに保存することである。タイプ１のノードパケットが用いられる場合、Caseポインタ、Resultポインタ、付加的なフィールド、asCaseポインタリストカウント、asResultポインタリストカウントおよび古いアドレスがタイプ１パケットに保存され得る。タイプ２のノードパケットを用いる場合、Caseポインタ、Resultポインタ、付加的なフィールドおよび古いノードアドレスが保存され得る。好ましい実施例では、asCaseリストおよびasResultリストは保存されないが、下記に記述される好ましい復元プロセスに説明されるように再構築される。タイプ３のノードパケットが用いられる場合、Caseポインタ、Resultポインタ、付加的なフィールド、ポインタリストカウントポインタリストカウントおよび古いアドレスが保存され得る。記憶されたデータ構造の究極的なサイズが、メタデータリソースを備えたヘッダおよび連続的な態様でその後ろに続くデータパケットまたは他の同様の構造から構成されるように、このノードのために保存されているパケットのサイズがこの時点で決定されるのが好ましい。こうして、パケットの各々についてステップ８１が達成され、パケットのすべてのサイズの合計を、それが準備されている間にパケットの各々のサイズを単純に合計することにより直ちに知ることができる。

ＫＳｔｏｒｅがコンピュータシステムを用いる唯一のアプリケーションである状況にあれば、いかなる中間のＩＯ機能も発生しないことを知ってアトミックな態様で保存を達成することが可能である。しかしながら、今日のコンピュータシステム環境においては通常はこのような状況ではない。したがって、図３から図５は、ＫＳｔｏｒｅパケットの中間データ構造を示し、タイプ１から３のヘッダは、タイプ２のパケットのＫｓｔｏｒｅパケットの中間データ構造を示し、ヘッダはディスクドライブまたは他の永久データ記憶装置にアトミックな方法（一度に１つのパケット）で保存する準備ができている。

ステップ７９および８１において、ノードパケットを準備し、ノードパケットのサイズを決定した後に、選択された方法論に一致したこのＫＳｔｏｒｅ内に、および／またはステップ７４で選択された制約内に、保存するべき他のノードがあるか否かという疑問に答えなければならない。回答が「はい」であると仮定すると、ステップ８２は、保存アルゴリズムの方法論にしたがって次のノードに移る。これらの方法論は後述される。

保存するノードがこれ以上ない場合、復元される必要のあるＫＳｔｏｒｅ構造のサイズの合計はステップ８４で決定され得、それに続いてＫＳｔｏｒｅ構造が保存される準備がされ、保存され得る。カウンタが用いられる場合、ノードパケットが生成されるごとにこのステップが部分的な態様で起こり得る。その場合には、このステップは、単純にカウンタにおける合計を読取ってもよい。プログラミングを容易にするために、すべての根ノードならびにＥＯＴノードおよびＢＯＴノードに索引またはラベルを付けてもよく、その結果、復元プロセスにおいてこれらを最初に見つけることができ、asCaseリストおよびasResultリストを備えたノードからの復元を最初にすることが可能になるので、復元プロセスが単純化される。

ステップ７５に関して簡潔に上述されたように、保存プロセスを導くいくつかの方法があり得る。選ばれた方法が適宜選択され得る。メモリ全体交換プロセスではなく正常な保存を用いていると仮定すると、そのプロセスは、永久記憶装置にノードパケットまたはパケットのグループを書込む前に少なくとも３つのステップを有する。自動またはユーザ支援されたプロセスであり得る、支持構造を保存するステップである。また横断するステップがなければならず、そこでプロセスは個々の関連するノードにアクセスする（いくつか
のノードは部分的保存において排除され得るが、そうでなければ、本質的にすべてのノードがアクセスされる）。次いで、各ノードからの情報が保存用のパケットに変換されなければならない。次に保存プロセスを行うことができ、この構造が実行されているハードウェアおよびソフトウェアによる必要に応じて採用される、任意のハウスキーピングシステムを利用する。

１つのレベルから開始して次のより高いレベルに移ることにより保存する場合、復元プロセスは単一パスで実行できるが、その一方、その方法で保存を行わない（この特許に記述されるすべてである）asCaseノードおよびasResultノードへの実際のポインタを保存しない任意のノードパケットタイプを用いる場合、反復的な処理を行うことなくポインタを組立て直すことが依然困難であることに注意されたい。

支持構造の保存は、いずれの情報の構造がインタロックツリーデータストアで保存されるかを決定することをまず必要とする。これは以下のような構造を含み得るがこれらに限定されない。作成日、ＫＳｔｏｒｅファイルＩＤなどを包含しているファイルヘッダ、要素的根ノード（またはセンサ）のリスト、ＢＯＴ−ＥＯＴモナド（monads）を表わすストリングのリスト、または恐らくインタロックツリーデータ構造に包含された考察終了ノード（モナド）のリストのみ、それが存在する基礎をなすＯＳまたはコンピュータシステムのデータ構造について記述し得るものなどのメタデータ、もしあればパスワード保護、ポインタのリストがいかにノード内で順序付けられるか、および、構造を復元するかまたは保存されている構造における情報のアドレスを決定するために必要ならばそのような性質のあらゆる情報、である。さらに、ヘッダは、Ｋ状態変数（いくつの付加的なフィールドがノード内でサポートされるか、いかなる種類のクエリが起こっているか、asCaseリストおよびasResultリストがいかに構造化されるか、データソース、スイッチ、およびデータストリームなど）、および／または、どのソースがクエリを受取るべきか、かつ／またはそこから情報を得るべきかを識別するフックなどのデータソース記述子を保存する。当然ながらこのデータはすべて、用いられているコンピュータシステムのＯＳおよび他の機能の必要に応じて、書込みおよび検索のためにフォーマットされるべきである。また、ＫＳｔｏｒｅがＸＭＬフォーマットまたはアクセスを有する場合、ＫＳｔｏｒｅ自体が（恐らく）それ自身についてのその情報を知らないので、その種の情報もまた記憶されるべきである。

こうして、ヘッダで見つけられると考えられる項目をリストにすると、ヘッダ記録は以下を包含し得る：
作成日
保存ファイルを作成した保存プログラムのバージョン／サイクル
ハードウェア構成（ＣＰＵ型など）
ＯＳ−オペレーションシステム
基礎をなす構造情報（フィールドのサイズ）
サイン構造情報、「その他」構造の下に保存されない場合は、情報センサ
レベルおよび関連付けられたデリミッタ
メタデータ−フィールドタイプ（ユーザ規定タイプを含む）、コラム記述、許可など
ｋＳｔａｔｅ変数−スイッチ、データストリーム、サイン構造情報（たとえばasCaseリストについての特別な順序付け）
データソース（タイプ、位置、関連するデータストリーム）−新しい知識セキュリティ（管理者およびユーザパスワード、許可、保存されたクエリ位置、トリガ）の学習のため。

ここで、ＫＳｔｏｒｅインタロックツリーデータストア構造を保存するための代替的横断方法について説明する。

各一次根ノードのasCase経路に沿った連続するツリー横断を用いて、一次根から開始する各ノードにアクセスするためにインタロックツリーデータストアを横断する。たとえば、図１１の一次根ノードＢＯＴ１０５０から始めれば、まずビルまで行き、ＥＯＴノード１０３０、１０４０および１０６０へのビルのすべての経路を得、次に、ＥＯＴノード１０６１へのすべてのリンクに到達するまでトムおよびトムのＥＯＴノードまで行く。この時点で、要素的根ノードを除いてすべてのノードがアクセスされている。要素的根ノード値およびポインタのファイルがあり、それはこのようにアクセスすることができることを思い出されたい。よりよい例は図１２に見ることができる。この図を用いた好ましい実施例では、第１の９１０レベルから始め、センサ（要素的根ノード）をまず保存し、次に第１のレベル（単語）、そして次のレベル（文）、などと続く。ＢＯＴ９０１およびＥＯＴ９０３とともにセンサＣ、Ａ、Ｔ、Ｓ、Ｒ、Ｅ、Ｆ、Ｕ、Ｙを保存する。これらはすべてのasCaseポインタおよびasResultポインタを有するので、保存中にこれが構築される場合、ＫＳｔｏｒｅのためのすべての古いアドレスはその古いアドレスリストに入力される。次に、すべてのサブコンポーネントノードを含む、単語ＣＡＴＳ、ＡＲＥおよびＦＵＲＲＹのノードを保存する。次いで、第２のレベル９１２からＢＯＳ根ノードおよびＥＯＳ根ノードを保存する。ここで、９０４と９０５との間の新しいノード、および最後に文の層９１２のための最終製品ノード、ノード９０２を保存する。

最終製品ノードから各ノードにアクセスするためにインタロックツリーデータストアを横断することが第２の方法である。それらはすべてＥＯＴノード１０６１を通してアクセス可能である。したがって、部分的保存は、最終製品ノードの所望の制約リストを通してＫＳｔｏｒｅを横断することによって実行することができる。

根ノードから各ノードにアクセスするためにインタロックツリーデータストアを横断することが、インタロックツリーデータストア構造を横断する第３の方法である。したがって、部分的保存は、根ノードの所望の制約リストを通してＫＳｔｏｒｅを横断し、所望の制約リストの根ノードの各々からすべてのasCaseリンクを辿ることによって、実行することができる
復元プロセスの流れ。

図７は、プロセスが完了するまでの、復元プロセス３２０の好ましい実施例を示す。所望であれば、他のいくつかのプロセスについて鳩尾型（dove-tailed）となってもよい。復元プロセスの好ましい実施例では、３２１でインタロックツリーデータストア（ここではＫと略する）が回復される前に必要とされる支持構造がまず読取られる。これはいかなるパーティクルがこのＫ（しばしば要素的根ノードまたはセンサまたはセンサリストと称される）に知られているか、このＫについてメモリにいかなるサイズの割当てが必要か、このＫをアドレスするＫＥｎｇｉｎｅによって扱われ得る内部トリガおよび他の機能があるか否かなどの情報を含んでいてもよい。ユーザが常に同じ支持構造を同じ種類のＫＳｔｏｒｅに復元するような状況であれば、このステップは、それが毎度同じ支持構造で復元されると仮定される点で、余分かもしれない。ＫＳｔｏｒｅｓが現在広い使用法を有しないとすれば、プロセス３２１が無益でない限り、また無益となる状況になるまでは、標準としてプロセス３２１を用いることが好ましい。インタロックツリーデータストアを復元するためにはノードパケットをすべて復元しなければならず、それらが次々に記憶されるので、復元の最も容易な形式は、それらが保存上に生成されたのと同じ順序で連続して復元することであろう。復元中に、ポインタの以前のアドレスから古いメモリ位置へ、新しいメモリ位置への変更を反復的に検索することを回避して復元プロセスを促進するために、既に復元されたノードを参照するasCaseリストまたはasResultリストを有するノードから始めることが好ましい。プログラミング技術の当業者は、この説明が、特に次のいくつかの段落とともに読まれた場合、これらの方法を実行するために必要なコードを生成する
ための必要以上の実験に頼らずに、この復元動作を行ういくつかの方法について説明していることを理解するだろう。

したがって、まず第１のノードパケットを３２２で読取り、用いているコンピュータのオペレーティングシステムを用いてステップ３２３においてこの新しいノードにメモリを割当てる。３２３でノードにメモリを割当てた後、ノードパケットとともに記憶された古いメモリアドレスおよびオペレーティングシステムまたはコンピュータシステムが今しがたこのノードに割当てた新しいメモリアドレスを用いて、このノードのための変換表および変換表エントリを３２４で作成するか、または作成し始める（図７を参照）。

ところで、メモリのブロック全体を透明に確実に動かすことができる機械およびオペレーティングシステムについて、単一のユニットとしての考慮中のデータストアのサイズが同じメモリアドレスに割当てられ、このようなシステムではここで記述したような詳細な保存および復元プロセスの必要がないが、部分的保存のため、また、このようなブロック全体の保存にわたって必要とされる記憶装置のサイズを減じるために役立つかもしれないことが認識されるべきである。しかしながら、現在のところ、説明されたが完全には実現されていないいくつかのメモリファイルタイプがあり、そのため、より複雑な保存に依存して、本発明に記述されるような復元機構が必要となる。

一旦ノードの古いアドレスおよび新しいアドレスを包含しているノード表エントリが生成されて変換表に３２４で入力されると、次にステップ３２５に移り、そこでCaseポインタおよびResultポインタを変換し、任意の付加的なフィールドとともに、変換されたCaseポインタおよびResultポインタを新しいノードに記憶する。この復元のバージョンについては、CaseポインタおよびResultポインタのために古いアドレスを直ちに調べる。それらは、それが必要となる前に変換アドレスレスリストに現われるような順に意図的に保存されている。

上述のように、本発明の好ましい実施例はasCaseリストまたはasResultリストを保存しないが、その代わり、それらに関連するものは何も保存しないか、または代替的には、ポインタのカウントをリストに保存する。asCaseリストおよびasResultリストとそれぞれのポインタとを再構築するために、復元プロセスはステップ３２６に進む。ステップ３２６において、復元プロセスは、CaseノードのasCaseリストの中に新しいノードアドレスを記憶し、復元されているノードのResultノードのasResultリストの中に新しいノードアドレスを記憶する。復元される第１のノードの新しいアドレス、すなわちＥＯＴノードおよび他のタイプの要素的根ノードは、好ましくはステップ３２１の一部として確立され、その結果、新しいノードがノードパケットから確立されるとき、それらは第２の反復的プロセスなしに、これらのＥＯＴノードおよび要素的根ノードのための新しいアドレスに直接指されることができるが、そのような処理は本発明の範囲外にあるわけではない。ただ好ましくないだけである。

一旦、新しいノードアドレスがそれぞれのasCaseリストまたはasResultリストに記憶されれば、好ましい復元方法はステップ３２７に進み、そこで問題のノードパケットが復元される最後のノードパケットであるか否かが決定される。ノードパケットが復元される最後のノードパケットでない場合、プロセスはステップ３２２に続き、新しいノードパケットが処理される。最後のノードパケットが処理されている場合、ステップ３２７の質問を越えて進むことができる。これは、最後の質問３２７でノードパケットに到達するまで継続する、反復的なプロセスである。この時点で、インタロックツリーデータ構造は、新しいメモリに復元されていなければならない。

アドレス変換表４０が図８に示される。そこでは、たとえば古いメモリアドレス１（４
１ａ）が新しいメモリアドレス１（４２ａ）に対応する、といったように、古いメモリアドレスリスト４１が新しいメモリアドレスリスト４２に対応して示される。このように、古いメモリアドレスが用いられる度に、すなわち復元される度に、復元されているノード／パケットがロードされる新しいアドレスがメモリアドレス変換表４０において維持され、古いメモリアドレスにリンクされる。好ましくはこの表がステップ３２８で完成した後、このアドレス変換表への参照を必要とし得る任意の追加的支持構造が設定される。この時点で復元されたＫがあり、このプロセス３２９から出ることができる。

さらに、ＫＳｔｏｒｅの再構築において、すなわちそれを復元すると、要素的根ノードからのデータをまず復元することができ、したがって、要素的根ノードの確立がリンクの大きいネットワークを素早く確立するので、復元を実行するプロセスがより迅速になる。

上述の方法およびシステムは、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ハードディスクドライブ、または、利用可能になる光学的およびナノテクノロジーの記憶装置などを含むあらゆる他の機械可読の記憶媒体などのコンピュータ読取可能な媒体に記憶されたプログラムコード（すなわち命令）の形式で具体化されてもよい。なぜならば媒体は本願明細書に記述されたような構造も動作も方法も変更しないに違いないからである。すべてのこのようなデータ記憶装置において、プログラムコードがコンピュータなどの機械にロードされ、それによって実行されるとき、機械はこの発明の方法を実行するための装置となり、本願明細書に記述されるような発明のシステムの形式を与える。本発明も、インターネットまたはイントラネットを含むネットワークを通して、または任意の他の伝送形式を介して、ＲＦまたは電線もしくはケーブルなどを通し、光ファイバを通して、もしくは明瞭な光学において何らかの伝送媒体を通して送信されるプログラムコードの形式で具体化されてもよく、そこで、プログラムコードがコンピュータなどの機械に受取られ、ロードされ、それによって実行されるとき、機械は、発明の方法を実行するための装置となり、本願明細書に記述される発明のシステムの形式を与える。汎用プロセッサ上で実現されると、プログラムコードはプロセッサと組合わさって特定の論理回路に類似して作動する一意の装置を与え、それ自体が発明に使用することができる。プログラムコードは、たとえばＣ、Ｃ＋＋またはＪａｖａ（登録商標）などの高レベルプログラミング言語で実現されてもよい。代替的には、プログラムコードはアセンブリまたは機械言語で実現されてもよい。いかなる場合も、言語はコンパイルされ、または解釈された言語であり得る。

前述の例が単に説明の目的で与えられており、本発明を限定するものとして解釈されてはならないことに注意されたい。たとえば、ＫＳｔｏｒｅインタロックツリーデータストアは、オブジェクト指向の技術、手続的技術、それらの複合、または他の適切な方法論を用いて実現することができる。さらに、示されたこれらの例はコンピュータシステムのメモリに記憶されたデータセット要素を示すが、当業者は、さまざまな方法でこの機能を実現することができ、汎用コンピュータシステムであっても特定目的用の装置であっても用いることができることを理解するであろう。考慮されたさまざまな実施例については、本発明では、遠隔に位置する複数の機械に記憶される多くの異なる母集団のデータセット要素の多くの異なる集合の使用が考慮される。

本発明の局面が実現され得る例示的な計算環境の位相を示すブロック図である。 本発明の局面が実現され得る例示的な計算環境の位相を示すブロック図である。 本発明のさまざまな好ましい実施例によるノードパケットのブロック図である。 本発明のさまざまな好ましい実施例によるノードパケットのブロック図である。 本発明のさまざまな好ましい実施例によるノードパケットのブロック図である。 本発明による保存プロセスの好ましい形態を示すフロー図である。 本発明による復元プロセスの好ましい形態を示すフロー図である。 本発明において用いるための「アドレス変換表」の好ましい形態を示すブロック図である。 本発明の実施例によるインタロックツリーデータストアからの典型的なノードのデータ構造を示すブロック図である。 本発明の実施例による、ＫＳｔｏｒｅと呼ばれるインタロックツリーデータストアの最小限の構造を示すブロック図である。 本発明の実施例による小さなＫＳｔｏｒｅインタロックツリーデータストアを示すブロック図である。 複数のレベルの説明のための支援図として有用なＫＳｔｏｒｅのブロック図である。 パケット内パケットの概念を示すブロック図である。

Claims (40)

1. インタロックツリーデータストアをメモリから保存する方法であって、前記インタロックツリーデータストアは、少なくとも１つのＢＯＴノードと、少なくとも１つのサブコンポーネントノードと、少なくとも複数の根ノードとを含み、前記ＢＯＴノードは、サブコンポーネントノードへのasCaseポインタのリストを有し、前記サブコンポーネントノードは他のサブコンポーネントノードへのasCaseポインタのリストを有し、前記根ノードは、前記ＢＯＴノードに従属した、サブコンポーネントノードへのasResultポインタのリストを有し、前記方法は、
   各ノードにアクセスするために前記インタロックツリーデータストアを横断するステップと、
   各ノードのためにノードパケットを生成するステップとを含み、前記ノードパケット生成プロセスは、各ノードについてcaseポインタおよびresultポインタを少なくとも捉えるステップを含むが、前記asCaseリストからのポインタを捉えず、前記asResultリストからのポインタも捉えず、別のメモリに前記ノードパケットを書込むステップを含む、方法。
2. １つのメモリから別のメモリに書込む前記ステップは、前記１つのメモリとして主要メモリを用いて達成される、請求項１に記載の方法。
3. 前記書込むステップは、相対に永久かつコンピュータによって検索可能であるタイプのメモリと、前記１つのメモリを収容する機械にローカルであるメモリと、ネットワークを通じてアクセス可能なシステムにおける離れたメモリと、区分された機械における区分メモリと、前記１つのメモリの別の部分と、を含むメモリのタイプのうち少なくとも１つに行なわれる、請求項１に記載の方法。
4. 前記ノードパケットをアクティブメモリに復元するステップをさらに含む、請求項１に記載の方法。
5. 前記ノードのパケットの少なくともいくつかはより大きなパケットに保存され、前記より大きなパケットは別のメモリに書込まれ、前記より大きなパケットは前記ノードについてのメタデータを用いて書込まれる、請求項１に記載の方法。
6. ノードパケットプロセスを生成する前記ステップは、asCaseポインタリストおよびasResultポインタリストのポインタのカウントを、それらを有するあらゆるノードから捉えるステップをさらに含む、請求項１に記載の方法。
7. 前記捉えるステップは、カウントを決定するためにリスト上でポインタをカウントするステップを含む、請求項６に記載の方法。
8. ノードパケットタイプを選択するステップをさらに含み、そこへ、ノードパケットプロセスを生成する前記ステップにおいて前記ノードからの情報が記憶される、請求項１に記載の方法。
9. 前記選択プロセスは、そこから選択するために最大３つのタイプのノードパケットを与え、前記３つのタイプは、asCaseポインタリストについてもasResultポインタリストについても情報を有さない第２のタイプと、asCaseポインタリストのポインタのカウントを保持するためのフィールドおよびasResultポインタリストのポインタのカウントを保持するためのフィールドを有する第１のタイプと、asCaseポインタリストのポインタまたはasResultポインタリストのポインタのいずれかのカウントを保持するが両方は保持しないフィールドを有する第３のタイプとを含む、請求項８に記載の方法。
10. 前記第３のタイプのノードパケットは、前記保持されるポインタリストカウントをポインタリストカウントと呼ばれるフィールドに記憶する、請求項９に記載の方法。
11. 選択のための少なくとも１つのタイプは、asCaseポインタリストについての情報もaSResultポインタリストについての情報を有さないノードパケットである、請求項９に記載の方法。
12. 選択のための少なくとも１つのタイプは、asCaseポインタリストのポインタのカウントを保持するためのフィールドおよびasResultポインタリストのポインタのカウントを保持するためのフィールドを有するパケットである、請求項９に記載の方法。
13. 選択のための少なくとも１つのタイプは、asCaseポインタリストのポインタのカウントを保持するフィールドまたはasResultポインタリストのポインタのカウントを保持するフィールドのいずれかを有するが両方の値は有さないパケットである、請求項９に記載の方法。
14. 支持構造を保存するステップをさらに含む、請求項１に記載の方法。
15. 前記支持構造を保存する前記ステップは、復元プロセス中にアドレス変換表が構築される前に復元され得るあらゆる支持構造を保存する第１のステップと、残りのすべてのノードパケットが復元されてアドレス変換表が完成された後に用いられ得るあらゆる支持構造を保存する第２のステップとの、２つのステップにおいて行なわれる、請求項１４に記載の方法。
16. さらに保存される前記支持構造は、
    ファイルタイプおよび作成日を包含するファイルヘッダと、
    ファイルＩＤと、
    要素的根ノードの値またはその値を指すそれらのアドレスのリストと、
    インタロックツリーデータストアの最終製品ノードを表わすストリングのリストと、
    それが存在する基礎となるＯＳまたはコンピュータシステムのデータ構造を記述するメタデータと、
    ファイル自体に対するパスワード保護と、
    ポインタのリストがノード内でいかに順序付けられるかを特定するコードと、
    特定の環境において構造を復元するために必要となり得るその性質の情報と、
    保存されている構造における情報のアドレスの決定を可能にする性質の情報と、
    保存ファイルを生成した保存プログラムのバージョンおよびサイクルと、
    用いられた情報のフィールドの少なくともサイズを含むＯＳ基礎構造情報と、
    基本根ノード値またはその値へのポインタおよびあらゆる関連するデリミタと、
    ユーザ定義タイプ、コラム記述子および許可などのフィールドタイプを含むメタデータと、
    スイッチ、データストリーム、ノード構造を含むＫＳｔａｔｅ変数と、
    タイプの位置および関連するデータストリームのＩＤ情報を含むデータソース、管理パスワード、許可、保存されたクエリ場所およびトリガを含むセキュリティ機能と、
    ＸＭＬ関連メタデータと、
    の支持構造うちの少なくとも１つを含む、請求項１４に記載の方法。
17. 少なくとも、
    resultポインタと、
    caseポインタと、
    任意の付加的なフィールドデータと、
    古いメモリアドレスと、
    任意のカウントフィールドデータと、
    の情報が、ノードパケットプロセスの前記生成において各ノードパケットに含まれる、請求項１に記載の方法。
18. パケットサイズに関連する値もノードパケットプロセスの前記生成における前記ノードパケットに保存される、請求項１７に記載の方法。
19. 支持構造プロセスを書込む前記ステップは、前記方法によって生成された保存されたインタロックツリーデータストアデータファイルのためのヘッダファイルに前記支持構造を保存する、請求項１４に記載の方法。
20. 前記ノードパケットは、１組の前記ノードパケットを包含するより大きなパケットに保存される、請求項１７に記載の方法。
21. 前記より大きなパケットに保存された、前記１組のノードパケットのノードパケットの各々は、少なくとも１つの特性を共有し、前記特性の表示は前記大きなパケットのヘッダ領域に記憶される、請求項２０に記載の方法。
22. 複数の大きなパケットを保存するステップをさらに含み、それぞれは、他の大きなパケットのノードパケットとは少なくとも１つの特性において異なる１組のノードパケットを有する、請求項２１に記載の方法。
23. インタロックツリーデータストアをメモリから別のメモリへ保存する前記ステップは、支持構造を前記別のメモリに保存するステップをさらに含む、請求項１に記載の方法。
24. 請求項１に記載のプロセスで生成された１組のノードパケットを有するデータファイルを包含する、機械可読信号媒体。
25. 前記媒体は磁気ディスクである、請求項２４に記載の機械可読信号媒体。
26. コンピュータにロードされ実行が許されると前記コンピュータに請求項１の方法を実行させる１組の命令を含む、機械可読データ媒体。
27. 復元される各ノードについて少なくとも１つのパケットを有する保存されたインタロックツリーデータストアデータファイルからインタロックツリーデータストアを復元する方法であって、前記インタロックツリーデータストアは、前記方法に続いて復元された後、少なくとも１つのＢＯＴノードと、少なくとも１つのサブコンポーネントノードと、少なくとも複数の根ノードとを含み、前記ＢＯＴノードはサブコンポーネントノードへのasCaseポインタのリストを有し、前記サブコンポーネントノードは他のサブコンポーネントノードへのasCaseポインタのリストを有し、前記根ノードは前記ＢＯＴノードに従属したサブコンポーネントノードへのasResultポインタのリストを有し、前記復元する方法は、
    前記保存されたインタロックツリーデータストアデータファイルから支持情報を検索し、前記支持情報の少なくともいくつかを基礎としてメモリに領域を確立するステップと、
    すべてのノードパケットが読取られるまで前記データファイルからノードパケットを反復的に読取るステップとを含み、読取られた各ノードパケットについて、
    メモリを割当て、コンピュータシステムのメインメモリ記憶の前記読取られたノードパケットから生成された新しいノードに指定される新しいメモリアドレスを有するステップと、
    各読取られたノードパケットにアドレス変換表を生成し、前記読取られたノードパケットの少なくとも１つの古いメモリアドレスを含む情報を前記変換表に追加するステップとを含み、前記表は、前記割当てるステップからの各ノードパケットの前記新しいメモリアドレスと前記読取られたノードパケットの前記古いメモリアドレスとの間に対応関係を有する、方法。
28. 以前に読取られた前記読取られたノードパケットのいずれかから生成されているノードのための新しいメモリアドレスを見つけるために古いメモリアドレスの前記アドレス変換表を用いるステップをさらに含む、請求項２７に記載の方法。
29. 反復的にノードパケットを読取る前記ステップは、サブコンポーネントノードまたは最終製品ノード上で実行されるより前に、ＢＯＴノードおよび要素的根ノード上でまず実行される、請求項２７に記載の方法。
30. 前記データファイルからの最後のノードパケットが読取られた後に前記データファイルから最終の支持構造情報を読取るステップをさらに含み、前記最終の支持構造情報はノードアドレスを以前に構築したことに依存する性質を有する、請求項２７に記載の方法。
31. 前記データファイルの前記ノードパケットは、前記方法の先例の保存動作中に、ヘッダ情報を包含するようなやり方で配置され、前記ヘッダ情報は前記データファイルについてのメタデータを含み、前記メタデータは、前記データファイルのすべてのパケットについてノードパケット読取りの順序を決定するために、前記読取るステップがまず前記特定する情報を読取るよう、前記読取るステップを容易にするために特定する情報を与える、請求項２７に記載の方法。
32. 前記データファイルの前記ノードパケットは、前記方法の先例の保存動作中、大きなパケットに配置され、前記大きなパケットはヘッダ情報を包含し、前記ヘッダ情報は前記大きなパケットのすべてのノードパケットのための前記ノードパケットについてのメタデータを含む、請求項２７に記載の方法。
33. データファイルに存在するいくつかの大きなパケットは、最低レベルのＢＯＴノードパケットを包含する大きなパケットがまず読取られるような順序で読取られ、前記大きなパケットの各々の中でＢＯＴノードパケットおよび要素的根ノードパケットがまず読取られ、次に、他のノードパケットを包含する大きなパケットが、次の大きなパケットのノードパケットを読取る前に読取られ、１つのレベルにおけるすべての大きなパケットが、前記１つのレベルより上のあるレベルにノードパケットを有する任意の大きなパケットを読取る前に読取られる、請求項３２に記載の方法。
34. 前記読取りステップの前に、いかなるタイプのノードパケットが読取られているかについて決定がなされ、前記決定はノードパケットについての支持情報を読取ることに基づいて行われる、請求項３２に記載の方法。
35. 前記読取るステップの前に、いかなるタイプのノードパケットが読取られているかについて決定され、前記決定は、大きなパケットから第１のパケットを検査することに基づいて行なわれ、前記第１のパケットは前記大きなパケットのすべてのノードパケットについてのメタデータを包含する、請求項２７に記載の方法。
36. コンピュータにロードされて前記コンピュータでアクティブにされると前記コンピュータに請求項２７の方法を実行させる、エンコードされた１組のコンピュータ命令。
37. コンピュータ命令のためのコンピュータ可読媒体および請求項３６に記載のエンコードされたコンピュータ命令の組を包含するデータ。
38. 請求項２７の方法を実行するためのエンコードされた命令の組を実行する、コンピュータシステム。
39. インタロックツリーデータストアをメモリから保存する方法であって、前記インタロックツリーデータストアは、少なくとも１つのＢＯＴノードと、少なくとも１つのサブコンポーネントノードと、少なくとも複数の根ノードとを含み、前記ＢＯＴノードはサブコンポーネントノードへのasCaseポインタのリストを有し、前記サブコンポーネントノードは他のサブコンポーネントノードへのasCaseポインタのリストを有し、前記根ノードは前記ＢＯＴノードに従属したサブコンポーネントノードへのasResultポインタのリストを有し、前記方法は、
    各ノードにアクセスするために前記インタロックツリーデータストアを横断するステップと、
    各ノードについてノードパケットを生成するステップとを含み、前記ノードパケット生成プロセスは、各ノードについてcaseポインタおよびresultポインタを少なくとも捉えるステップを含むが、前記asCaseリストからのポインタも前記asResultリストからのポインタも捉えず、さらに
    前記メモリに前記ノードパケットを書込むステップを含む、方法。
40. 付加的なフィールドは、ポインタリストカウントのカウントによって表わされるポインタリストのタイプを差別化するためにノードパケットに追加される、請求項１３に記載の方法。

Images