JP2022058529A - 大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造 - Google Patents

Abstract

【課題】大規模データセットの高速検索またはフィルタリングのためのシステム、方法及びデータ構造を提供する。【解決手段】インラインツリーデータ構造と１以上の補助データ構造が、データセットの複数のデータレコードをエンコードする。データセットのデータフィールドはツリー階層を定義する。インラインツリーは、各データレコードについて１のバイナリ文字列を含み、これはすべて同じ長さであり、ツリー階層に対応する順序付けられたシーケンスで配列され、直ぐ隣のデータレコードに対して各データレコードのツリー階層内の位置を示すインジケータ文字列を含む。検索プログラムは、データフィールド値の不要な問い合わせを減らすために、インラインツリーデータ構造内の各インジケータ文字列を問い合わせることによって、データセットを通してガイドされる。【選択図】図５

Description

［０００１］優先権主張
この出願は、発明者Ｒｏｙ．Ｗ．Ｗａｒｄの名で２０１６年８月１０日に提出された「大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造」と題する米国特許出願第１５／２３３，０４７号の優先権を主張する。この特許出願は、本明細書に全体が記載されているかのように参照により本明細書に組み入れられる。

［０００２］発明の分野
本発明の分野は、電子データの格納、検索、フィルタリング、一覧表示、列挙、または回復に関する。特に、大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造が本明細書に開示されている。

［０００３］この出願は、（ｉ）Ｒｏｙ Ｗ．Ｗａｒｄによる米国特許出願第１３／３２６，３２６号（現在は米国特許第９，００２，８５９号）、（ｉｉ）２０１２年１月１０日にＲｏｙ Ｗ．ＷａｒｄとＤａｖｉｄ Ｓ．Ａｌａｖｉにより出願された米国特許出願番号１３／３４７，６４６号（現在、Ｗａｒｄに発行された米国特許第８，９７７，６５６号）、（ｉｉｉ）２０１３年１月４日にＲｏｙ Ｗ．Ｗａｒｄにより出願された米国特許出願第１３／７３３，８９０号（現在は米国特許第９，１７１，０５４号）に開示された主題に関する。これらの出願および特許はそれぞれ、本明細書に完全に記載されているかのように参照により本明細書に組み込まれ、これらの出願および特許は以後「インラインツリー特許」と総称される。

［０００４］非常に大量のデータ（例えば、それぞれが一握り、数十、または百以上のデータフィールドを含む１０^４、１０^６、１０^８、またはそれ以上のデータレコード）が生成または収集される多くの状況が存在する。データセット内のデータが実用的であるためには、データセットを表す索引（indicia）が、データセット内の情報を検索、フィルタリング、一覧表示、列挙、配置、または取得できるように構成されたデータ構造に従って格納される。デジタル以前の時代には、そのようなデータ構造は往々にして適切な媒体に印刷された英数字の索引（しばしば付随する印刷された索引を含む）を含み、データの検索および取得は人間による手作業であった。前世紀の半ばごろに電子データの保存および検索機能が導入されたことで、大規模なデータセットを保存したり、保存したデータセット内の情報を検索、フィルタリング、一覧表示、列挙、特定、または取得できるようになった。

［０００５］今日、データセットを表す英数字の索引は、通常、電子スプレッドシートまたは電子リレーショナルデータベースなどのデジタルの電子データ構造に従って格納されている。スプレッドシート（フラットファイルデータベースとも呼ばれる）は、行と列を有し、各行が特定のデータレコードに対応し、各列がそのデータレコードの特定のデータフィールドに対応する、単一のテーブルと考えることができる。簡単な例（本明細書内で繰り返し使用されるもの）では、各データレコードは、特定の州（例えばオレゴン州）の全登録有権者のデータセットにおける１人の登録有権者に対応し得る。各データレコードのデータフィールドは、例えば、姓、名、ミドルネームまたはイニシャル、年齢、性別、婚姻状態、人種、民族、宗教、他の人口統計学的情報、住所（番地、ストリート名など複数のデータフィールドに分割される場合もある）、市、州、郵便番号、所属団体、投票履歴、郡、米国の住宅地区、州議会または住宅地区、学区、その他の行政区などを含み得る。

［０００６］リレーショナルデータベースは典型的には複数のテーブルを含み、各テーブルは複数のフィールドを有する複数のレコードと、異なるテーブルの様々なフィールド間に定義された関係とを含む。上記の登録有権者の例では、「有権者」テーブルが、対応するフィールドに名前と人口統計情報を含む有権者レコードを含み、「住所」テーブルが、対応するフィールドに住所と地区情報を含む住所レコードを含むことができる。有権者テーブル内の１のフィールドに、アドレステーブル内の対応するアドレスへのポインタを含むことができ、これが各アドレスと１またはそれ以上の対応する有権者との間の一対多の関係を定義する。他のテーブルや関係も定義することができる（多対多の関係とそれらを定義するためのいわゆるピボットテーブルを含む）。

［０００７］電子スプレッドシートおよび電子リレーショナルデータベースは、デジタルデータセットを保存するための標準的な方法になっている。これらはデータ整理、データ更新、新しいデータの追加、およびデータの並べ替え、検索、フィルタリング、または取得に、ほぼ無限の柔軟性を呈する。しかしながら、非常に大規模なデータセット（例えば、１０^６以上のレコード数、あるいは１０^４や１０^５以上のレコードのように少ない場合でも）について、スプレッドシートやデータベースは保存、アクセス、検索特に扱いにくくなる傾向があることが観察されている。特に、そのような大きな電子データセットからの情報の検索および取得は非常に遅くなり、特定のデータ検索アプリケーションにとって本質的に役に立たなくなることがある。

［０００８］上記で引用したインラインツリー特許は、大規模データセットの高速検索およびフィルタリングのための代替のシステムおよび方法を開示している。これらの特許に開示されているように、そして従来のスプレッドシートやリレーショナルデータベースとは対照的に、このデータセットは専用の、特別に適合された変換プログラムを使用して、従来のデータ構造から生成される特殊で高度に圧縮されたバイナリデータ構造として格納される。このバイナリデータ構造が、専用の、特別に適合された検索およびフィルタプログラムを使用して検索およびフィルタリングされる。インラインツリーデータ構造は、通常、デジタル記憶媒体の１レコード毎の１フィールド当たり約１～２バイト未満を占めるバイナリファイルに格納することができる（例えば、それぞれ１００フィールドを有する１００万レコードのデータセットは、約１００～２００ＭＢ未満に格納することができる）。スプレッドシートやリレーショナルデータベースに比べてサイズが大幅に縮小されると（多くの場合１０倍以上縮小される）、データセット全体を検索やフィルタリングのためにランダムアクセスメモリにロードできるため、操作速度が大幅に向上する。インラインツリーデータ構造の小さいサイズおよび連続した配置はまた、検索およびフィルタ処理を高速化し、その結果、大規模データセット（例えば、それぞれ１００を超えるデータフィールドを含む１０^６、１０^８、またはより多くのデータレコード）を、１プロセッサコアあたり１レコードあたり約１５０～５００ナノ秒未満で検索およびフィルタ処理することができる。

［０００９］（第２および第３のインラインツリー出願に開示されている）さらなる変形例では、いわゆるクランプヘッダテーブルを使用して、多数のデータフィールド値（任意の組み合わせで表示することができない国、市、議会地区、学区など）を共有するデータレコード群を示し、インラインデータ構造のうち、クランプされたデータフィールドの値が検索またはフィルタ条件と一致する部分のみを検索およびフィルタプログラムにかけることができる。（第３のインラインツリーアプリケーションに開示される）さらなる変形例では、追加のまたは置換データフィールド値を格納するために、補助の並列データ構造をインラインツリーデータ構造とともに使用することができる。検索およびフィルタプログラムが、インラインツリーデータ構造および補助データ構造を並行して調べるように適合させることができる。補助データ構造により、インラインツリーデータ構造全体を再生成することなく特定のデータフィールド値への変更が可能となり、インラインツリーデータ構造の様々なユーザがライセンス、購入、またはその他の目的のために特定のデータレコード収集を実現すべく自身の追加のデータフィールドを追加することを可能にする。

［００１０］上述のように、インラインツリー特許のインラインツリーデータ構造は、専用の特別に適合された変換プログラムによって生成されなければならず、専用の特別に適合された検索およびフィルタプログラムによって検索およびフィルタリングされなければならないという、非常に特殊な構造を有する。スプレッドシートやリレーショナルデータベースとは異なり、インラインツリーデータ構造は、新しいデータや更新されたデータを含めるように変更するのは面倒である。新規または置換データを既存のデータフィールドに挿入する場合、あるいはデータセットに新しいレコード全体を追加する場合は、往々にして変換プログラムを実行してまったく新しいインラインツリー構造が生成される。新しいデータフィールドをデータセットに追加するには、新しいインラインツリー構造を生成する前に変換プログラムをそれらの新しいフィールドに対応するように適合させ、検索およびフィルタプログラムを新しいインラインツリーデータ構造に対応するように適合させる必要がある。インラインツリー特許に記載のように、この柔軟性と更新可能性のロスは、インラインツリーデータ構造の小さいサイズと迅速な検索を得るために支払われる代償である。

［００１１］データセットの電子索引は、インラインツリーデータ構造と１またはそれ以上の補助データ構造とを含む。データセットには多数のデータレコードが含まれ、各データレコードは、複数の対応する定義済みデータフィールドのためのフィールド値文字列を含む。定義済みデータフィールドは、末端ノードデータフィールドおよび第１レベルのブランチノードデータフィールドを含み、さらに１またはそれ以上のレベルの上位レベルのブランチノードデータフィールドを含むことができる。ブランチノードデータフィールドは、ブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリー関係を定義し、ここでサブレンジはデータセットのデータレコードの１以上のレベルの複数ブランチノードサブセットのサブセットに対応する。

［００１２］インラインツリーデータ構造は、末端ノードのバイナリ文字列のみの順序付けられたシーケンスを含む。末端ノードのバイナリ文字列とデータセットのデータレコードの間には一対一の対応関係があり、末端ノードのバイナリ文字列は互いに同じ長さを有する。各末端ノードバイナリ文字列は標識文字列を含み、各末端ノードバイナリ文字列について、標識文字列は（ｉ）順序付けられたシーケンス内の末端ノードバイナリ文字列およびすぐ隣の末端ノードバイナリ文字列が、ともに同じ第１レベルのブランチノードサブセット内にあるそれぞれのデータレコードに対応すること、（ｉｉ）それぞれのデータレコードが互いに異なる第１レベルのブランチノードサブセットにあること、または（ｉｉｉ）末端ノードバイナリ文字列が最後の末端ノードサブセットにあることを示す。いくつかの例では、最初のものを除くすべての末端ノードバイナリ文字列について、隣接する末端ノードバイナリ文字列は直前の末端ノードバイナリ文字列である。いくつかの他の例では、最後のものを除くすべての末端ノードバイナリ文字列について、隣接する末端ノードバイナリ文字列はすぐ後の末端ノードバイナリ文字列である。

［００１３］第１レベルのブランチノードサブセットごとに、対応する末端ノードバイナリ文字列が、インラインツリーデータ構造内で単一の連続した文字列シーケンスを形成する。上位レベルのブランチノードサブセット（存在する場合）ごとに、対応する末端ノードバイナリ文字列が、インラインツリーデータ構造内で単一の連続した文字列シーケンスを形成する。１またはそれ以上の補助データ構造は、インラインツリーデータ構造内の末端ノードバイナリ文字列の順序付けられたシーケンスと同じ順序で配置され、索引付けられ、またはその他の方法でアクセス可能なデータセットのデータレコードのフィールド値文字列の電子索引を含む。

［００１４］コンピュータ実施方法は、（Ａ）データセットの第１の電子索引をコンピュータシステムで受信するか、１またはそれ以上のコンピュータ可読記憶媒体から読み取るステップと、（Ｂ）そのためにプログラムされ、１またはそれ以上の記憶媒体に動作可能に結合されたコンピュータシステムの１またはそれ以上の電子プロセッサを使用して、データセットの第２の電子索引を生成するステップであって、この第２の電子索引はインラインツリーデータ構造および１またはそれ以上の補助データ構造を含むステップと、（Ｃ）コンピュータシステムの１またはそれ以上の電子プロセッサに動作可能に結合された１またはそれ以上のコンピュータ可読記憶媒体に前記インラインツリーデータ構造および１またはそれ以上の補助データ構造を保存するステップとを含む。

［００１５］コンピュータ実施方法は、（Ａ）データセットの定義済みデータフィールドのうちの１またはそれ以上の選択された照会データフィールドのそれぞれについて、対応する照会フィールド値のサブレンジに該当する対応するフィールド値を含む、データセットのデータレコードに対する検索クエリをコンピュータシステムで受信するステップと；（Ｂ）自動的に、そのためにプログラムされたコンピュータプロセッサを用いて、インラインツリーデータ構造の末端ノードバイナリ文字列の順序付けられたシーケンスを順番に問い合わせて、対応する標識文字列を同定するステップと；（Ｃ）そのためにプログラムされたコンピュータプロセッサで自動的に、パート（Ｂ）で問い合わせた各末端ノードバイナリ文字列と同様に、１またはそれ以上の補助データ構造における、対応するデータレコードの選択された照会データフィールドのみについてフィールド値文字列を問い合わせ、パート（Ａ）の検索クエリを満たすデータレコードを同定するステップであって、各データレコードについてパート（Ｃ）で問い合わせられるフィールド値文字列は、パート（Ｂ）で同定された対応する標識文字列によって部分的に特定される、ステップと；（Ｄ）パート（Ａ）の検索クエリを満たさない第１レベルのブランチノードフィールド値のぞれぞれについて、データレコードの対応する第１レベルのブランチノードサブセットのパート（Ｃ）の末端ノードデータフィールドの問い合わせから除外するステップと；（Ｅ）パート（Ａ）の検索クエリを満たさない上位レベルのブランチノードフィールド値（存在する場合）のそれぞれについて、データレコードの対応する上位レベルのブランチノードサブセットのパート（Ｃ）の第１レベルおよび末端ノードデータフィールドの問い合わせから除外するステップと；（Ｆ）そのためにプログラムされたコンピュータプロセッサで、パート（Ａ）で受信された検索クエリを満たすものとしてパート（Ｃ）で同定されたデータレコードのリストまたは列挙を自動的に生成するステップとを含む。

［００１６］電子的なデータ検索、フィルタリング、または取得に関する目的および利点は、図示され、以下の明細書または添付の特許請求の範囲に開示された例示的な実施形態を参照すると明らかになるであろう。この概要は、詳細な説明において以下にさらに説明される概念の選択を単純化された形で紹介するために提供される。この概要は、請求される主題の主要な特徴または本質的な特徴を識別することを意図するものではなく、特許請求される主題の範囲を決定する際の補助として使用されることも意図するものでもない。

［００１７］この概要は、詳細な説明において以下でさらに説明される概念の選択を単純化された形で紹介するために提供される。この概要は、特許請求される主題の主要な特徴または本質的な特徴を識別することを意図するものではなく、特許請求される主題の範囲を決定する際の補助として使用されることも意図するものでもない。

［００１８］図１は、一般的な例のデータセットの３レベルの階層配置を概略的に示す。 ［００１９］図２は、従来のフラットファイルデータベースの一例に配置された図１の例示的なデータセットに対応する索引（indicia）の一例を概略的に示す。 ［００２０］図３は、従来のリレーショナルデータベースの一例に配置された図１の例示的なデータセットに対応する索引の一例を概略的に示す図である。 ［００２１］図４は、インラインツリー特許のインラインツリーデータ構造の一例に配置された図１の例示的なデータセットに対応する索引の一例を概略的に示す図である。 ［００２２］図５は、図１の例示的なデータセットのための本発明のストレージ構成のストリップドインラインツリーデータ構造の例を概略的に示す。 ［００２３］図６Ａ～６Ｃは、図１の例示的なデータセットのための本発明のストレージ構成の補助データ構造の例を概略的に示す図である。 ［００２４］図７は、図５、６Ａ、６Ｂ、および６Ｃの例示的な本発明の構成に従って格納されたデータセットを照会するための例示的な方法のフロー図である。 ［００２５］図８は、図５、６Ｂ、および６Ｃの例示的な本発明の構成に従って格納されたデータセットを照会するための例示的な方法のフロー図であるを。

［００２６］図示された実施形態は概略的にのみ示されている。すべての特徴は完全な詳細または適切な比率で示されているとは限らず、明確さのために特定の特徴または構造が他に対して誇張されている。図示された実施形態は例にすぎず、それらは本開示または添付の特許請求の範囲を限定するものとして解釈されるべきではない。

［００２７］電子データセットの多くの例では、データは多数の英数字データレコードを含み、それらの各データレコードは複数のデータフィールドの各々に、対応する英数字のフィールド値文字列（すなわちフィールド値）を含んでいる。多くの場合、データセットは階層的なマルチレベルツリー構造に従って編成することができる。ツリー構造の最下位レベルには、データセットの個々のデータレコードに対応する、いわゆる末端ノード（ツリーに倣い、「リーフ」ノードとも呼ばれる）が含まれる。これらの末端ノードに関連付けられたデータフィールドは、末端ノードデータフィールドと呼ばれる。末端ノードから階層を上がると、第１レベルのブランチノードがあり、そして第２レベルまたはさらに高レベルのブランチノードがある。第１レベルのブランチノードに関連付けられているデータフィールドは第１レベルのブランチノードデータフィールドと呼ばれ、第２レベルのブランチノードに関連付けられているもの（第２レベルのブランチノードがある場合）は第２レベルブランチノードデータフィールドと呼ばれ、より上位レベルのブランチノード（存在する場合）も同様である。

［００２８］そのようなツリー構造の第１レベルのブランチノードの各々は、典型的に、（ｉ）１またはそれ以上の第１レベルのブランチノードデータフィールドのそれぞれの値の単一のサブレンジと、（ｉｉ）対応するデータレコードが、対応するサブレンジ内に含まれる第１レベルのブランチノードデータフィールドについてのフィールド値を含む１またはそれ以上の末端ノードと、の間の一対多の関係を表す。これらの末端ノードに対応するデータレコードは、データレコードの第１レベルのブランチノードのサブセットを形成し、それらはすべて、対応するサブレンジ内の第１レベルのブランチノードデータフィールドに値を有する。各データレコードは、マルチレベルツリー階層の配置と一致して、１つの第１レベルのブランチノードサブセットにのみ属する。したがって、各末端ノードは、１つの第１レベルのブランチノードにのみ「属する」と言える。同様に、第２レベルのブランチノードがある場合、ツリー構造の第２レベルブランチノードはそれぞれ、典型的に、（ｉ）１またはそれ以上の第２レベルのブランチノードデータフィールドのそれぞれにおける値の単一のサブレンジと、（ｉｉ）対応するデータレコードが、対応するサブレンジ内に含まれる第２レベルのブランチノードデータフィールドについての値を含む１またはそれ以上の末端ノードと、の間の一対多の関係を表す。これらの末端ノードに対応するデータレコードは、データレコードの第２レベルのブランチノードサブセットを形成し、それらはすべて、対応するサブレンジ内の第２レベルのブランチノードデータフィールドに値を有する。第１レベルのブランチノードサブセットの各々は、マルチレベルツリー階層の配置と一致する、１つの第２レベルのブランチノードサブセットのみのサブセットである。したがって、各第１レベルのブランチノードは、１つの第２レベルのブランチノードのみに「属する」と言える。さらなる上位レベルが階層内に存在する場合、上位レベルのブランチノードデータフィールドおよび上位レベルのブランチノードサブセットも同様に定義することができる。

［００２９］オレゴン州のすべての登録有権者のデータレコードのデータセットが、本開示の実施例として繰り返し使用されることになる。しかしながら、本明細書に開示されクレームにあるシステムおよび方法は、そのデータセットまたはその一般的な種類のデータセットに限定されず、データが本明細書に例示されるデータ構造に従って構成され得る任意のデータセットに適用することができる。オレゴン州の登録有権者のデータセットは、（第１レベルのブランチノードとしての）約１．０×１０^６の個別の住所における（末端ノードとしての）約１．９×１０^６人の個人有権者に関するデータレコードを含んでいる。図１は、データを３つのレベルの階層（図１においてＡ、Ｂ、およびＣで示すレベルであって、「Ａ」レベルのノードは第２レベルのブランチノードであり、「Ｂ」レベルのノードは第１レベルのブランチノードであり、「Ｃ」レベルのノードは末端ノードである）に編成するための一般的なツリー構造の一例を概略的に示す。投票者ごとに数十の可能なデータフィールド（すなわち、末端ノードデータフィールド）と、住所ごとに約１００の可能なデータフィールド（すなわち、第１レベルおよび第２レベルのブランチノードデータフィールド）がある。オレゴン州の登録有権者データセットを含む従来のスプレッドシートまたはフラットファイルデータベースは、コンピュータのハードディスクに格納された場合に、サイズが約２ＧＢ（ギガバイト）である。

［００３０］本明細書に開示されているすべてのシステムおよび方法は３レベルの実施例に関して説明されているが、これらの開示されたシステムおよび方法は、任意の必要な、望ましい、または適切な数の２またはそれ以上のレベルを含む階層ツリー構造に従って編成されたデータに一般化できることを意図する。特定数のレベルに明確に限定しない限り、クレームは様々な数のレベルを包含するものとする。

［００３１］登録有権者の実施例についての３レベルのデータ階層の一例は、第２レベルのブランチノードとしてのストリートＡ［ｘ］と、第１レベルのブランチノードとしての番地Ｂ［ｘｙ］と、末端ノードとしての有権者Ｃ［ｘｙｚ］とを含み得る。この例では、データセット全体を網羅するストリートＡ［１］、Ａ［２］、・・・Ａ［ｘ］などがある。各ストリートＡ［ｘ］には、当該ストリートを取り囲む番地Ｂ［ｘ１］、Ｂ［ｘ２］、・・・Ｂ［ｘｙ］などがある。各番地Ｂ［ｘｙ］には、有権者Ｃ［ｘｙ１］、Ｃ［ｘｙ２］、・・・Ｃ［ｘｙｚ］などがある。各データレコードは、末端ノードを指定し、その関連属性（すなわち、ＦＣ１、ＦＣ２、ＦＣ３などとラベル付けされた末端ノードデータフィールド内のフィールド値）を示す、対応するデータフィールド内の英数字フィールド値文字列を含み、また、（ｉ）対応する末端ノードが接続されている第１レベルのブランチノード、および存在する場合は第２レベルまたはそれ以上のレベルのブランチノードを指定し、（ｉｉ）これらの上位レベルのノードに関連する属性（すなわち、ＦＢ１、ＦＢ２、ＦＢ３などとラベル付けされた第１レベルのブランチノードデータフィールド内のフィールド値；ＦＡ１、ＦＡ２、ＦＡ３などのラベル付けされた第２レベルのブランチノードデータフィールド（存在する場合）のフィールド値；および上位レベルのブランチノードデータフィールド（存在する場合）のフィールド値）を示す、対応するデータフィールド内のフィールド値文字列を含む。所与のデータレコードの特定のフィールド値は、例えば、ＦＡ２（ｉ）、ＦＢ４（ｉ，ｊ）、ＦＣ７（ｉ，ｊ，ｋ）などで指定される。

［００３２］図１の３レベルの階層的な例のデータでは、データフィールドＦＡ１、ＦＡ２などは、第２レベルのブランチノードデータフィールドと呼ぶことができる。第２レベルのブランチノードＡ［ｘ］の各々は、各データフィールドＦＡｎについて、１またはそれ以上のデータレコード内のそのフィールドに現れるフィールド値文字列（等価的にはデータ値）のサブレンジを指定することによって定義できる。所与のサブレンジは、単一の文字列、またはヌル文字列（すなわち、フィールドに格納されている文字列がない）を含み得ることに留意されたい。したがって、各ノードＡ［ｘ］は、データセット内のデータレコードの第２レベルのブランチノードサブセットに対応し、ここで第２レベルのブランチノードサブセットは、第２レベルのデータフィールドＦＡｎのフィールド値が対応するサブレンジ内に入っているデータレコードのみを含む。同様に、データフィールドＦＢ１、ＦＢ２等は、第１レベルのブランチノードデータフィールドと呼ぶことができる。各ノードＢ［ｘｙ］は、各フィールドＦＢｍについて、１またはそれ以上のデータレコード内に現れるフィールド値文字列（等価にはデータ値）のサブレンジを指定することによって定義することができる（この場合も、所与のサブレンジは単一の文字列またはＮＵＬＬ文字列を含み得る）。したがって、各ノードＢ［ｘｙ］は、対応する第２レベルのサブセット内のデータレコードの第１レベルのブランチノードサブセットに対応し、ここで第１レベルのサブセットは、各第１レベルのフィールドＦＢｍのフィールド値文字列が対応するサブレンジ内に入るこれらのデータレコードのみを含む。階層ツリー構造の性質と一貫して、各データレコードは１つの第１レベルのブランチノードサブセットのみに含まれ、各第１レベルのブランチノードサブセットは単一の第２レベルのブランチノードサブセットのみのサブセットである（すなわち、所与の第１レベルのブランチノードサブセットのすべてのデータレコードは、同じ第２レベルのブランチノードサブセットに属する）。前述の説明は、第３、第４、またはさらに上位レベルのブランチノード、データフィールド、およびデータレコードサブセットに一般化することができる。

［００３３］階層データツリーは、必要なまたは望むだけ多くのレベルを含むことができ（場合によってはツリーのブランチによって変わる）、任意の所与のレベルで必要なまたは望むだけ多くのノードを含むことができる。さらなる例では、図１の階層データ構造全体がそれ自体で、より大きなツリー構造の末端ノードを構成することができる。登録有権者の例に加えて、階層ツリーに従って有利に編成することができるデータの他の特定の実施例には：例えば州（Ａ）、郡（Ｂ）、住宅団地（Ｃ）、人口調査ブロック（Ｄ）、およびレコード（Ｅ）で構成される人口調査データ；例えば顧客（Ａ）、注文（Ｂ）、および支払い（Ｃ）で構成される売上データ；大陸（Ａ）、国（Ｂ）、州または地方（Ｃ）、および市（Ｄ）で構成される地政学的データ；緯度および経度の度（Ａ）、分（Ｂ）、および秒（Ｃ）で構成される地理空間データ。年（Ａ）、月（Ｂ）、日（Ｃ）、時（Ｄ）、および分（Ｅ）で構成される時系列データ；および、例えば異なる地理的位置にある装置によって生成される時系列データなどの、異なる階層の組み合わせが含まれる。これらおよび他の適切な実施例は、本開示または添付の特許請求の範囲内に含まれるものとする。

［００３４］本明細書および特許請求の範囲における説明の便宜上、格納された電子索引およびそれらが表すデータは互換的に参照されることがある。データ自体は抽象概念であり、代表的な索引は電子的に格納され、取り扱われ、データ構造に配置され、検索され、取得され、またはその他に本書に開示されるか特許請求された方法およびシステムで操作されるオブジェクトであることに留意されたい。本開示における用語「データ」、「フィールド値」などの使用は、与えられた文脈において適切であれば、代表的な索引を示すと理解される。

［００３５］上述のように、図１に表されたデータを格納するために採用することができる１つの従来の電子データ構造は、データを表す電子索引が行と列に編成された電子スプレッドシート（「行」と「列」が通常の方法で定義されたフラットファイルデータベース）である。そのようなスプレッドシートのいくつかの行が図２に概略的に示されている。スプレッドシートの各行はデータセットの１つのデータレコードに対応し、したがって図１のツリーの「リーフノード」の１つに対応する（例えば、Ｃ［ｘｙｚ］）。スプレッドシートの列はデータフィールドに対応し、データレコードＣ［ｘｙｚ］についてフィールド値ＦＣ１（ｘ，ｙ，ｚ）、ＦＣ２（ｘ，ｙ，ｚ）などを含み、ノードＢ［ｘ，ｙ］（階層内の対応する第１レベルのブランチノード）についてはＢＦ１（ｘ，ｙ）、ＢＦ２（ｘ，ｙ）などを含み、ノードＡ［ｘ］（階層内の対応する第２レベルのブランチノード）についてはフィールド値ＡＦ１（ｘ）、ＡＦ２（ｘ）などを含む。もしあれば、さらなる上位レベルのブランチノードのためにさらなるフィールドを含むことができる。与えられたデータレコードがそのフィールドにデータを有するか否かに拘わらず、すべてのデータレコードのすべての可能なデータフィールドのためにスプレッドシートにスペースが確保されていることに注意されたい。また、ブランチノードデータフィールドのデータは、対応するブランチノードに接続された末端ノードに対応する各データレコードで繰り返される。

［００３６］図１に表されるデータを格納するために採用できる別の従来の電子データ構造は、図３に概略的に示されるように、データを表す電子索引がテーブルに編成される電子リレーショナルデータベースである。「Ｃ」テーブルの各テーブルレコードは、対応する「リーフノード」Ｃ［ｘｙｚ］を表し、識別子フィールド値ＩＤ－Ｃ（ｘ，ｙ，ｚ）と、対応するデータフィールド値ＦＣ１（ｘ，ｙ，ｚ）、ＦＣ２（ｘ，ｙ，ｚ）等と、対応する第１レベルのブランチノードＢ［ｘｙ］の識別子フィールド値ＩＤ－Ｂ（ｘ，ｙ）とを含む。「Ｂ」テーブル内の各テーブルレコードは、対応する第１レベルのブランチノードＢ［ｘｙ］を表し、識別子フィールド値ＩＤ－Ｂ（ｘ，ｙ）と、対応するデータフィールド値ＦＢ１（ｘ，ｙ）、ＦＢ２（ｘ，ｙ）等と、対応する第２レベルのブランチノードＡ［ｘ］の識別子フィールド値ＩＤ－Ａ（ｘ）とを含む。「Ａ」テーブルの各テーブルレコードは、対応する第２レベルのブランチノードＡ［ｘ］を表し、識別子フィールド値ＩＤ－Ａ（ｘ）と、対応するデータフィールド値ＦＡ１（ｘ）、ＦＡ２（ｘ）等とを含む。図３の各テーブルの図は、データベース管理の当業者には理解されるように、図示された種類および内容の複数の異なるテーブルレコードを表すと理解される。異なるテーブルの特定のフィールドを結ぶ点線は、リレーショナルデータベース構造内で確立された一対多の関係を表す（例えば、１つの第２レベルのブランチノードＡ［ｘ］から１またはそれ以上の第１レベルのブランチノードＢ［ｘｙ］へ；１つの第１レベルのブランチノードＢ［ｘｙ］から１またはそれ以上の末端ノードＣ［ｘｙｚ］へ）。図２のスプレッドシートデータ構造と同様に、あらゆるデータレコードのあらゆる可能なフィールドに対してスペースが確保されていることに留意されたい。しかしながら、図１のスプレッドシートの実施例とは異なり、複数のデータレコードに共通のデータフィールドは、すべてのリーフノードに対して繰り返し格納される必要はない。例えば、「Ｂ」テーブルと「Ｃ」テーブルのＩＤ－Ｂフィールド間の関係により、「Ｂ」テーブルにＦＢｍ（ｘ，ｙ）の各フィールド値を一度だけ格納することができる。図３の例は、一対多の関係のみを含むリレーショナルデータベース構造の比較的単純な例であり、より複雑な実施例は、いわゆる「ピボットテーブル」を必要とする、多くのテーブルや多対多の関係などがある。

［００３７］上記のように、例えばスプレッドシートやデータベースなどの従来の電子データ構造は、データレコードを追加、削除、または修正し、異なるレコードにおけるデータフィールド間の関係を確立し、そして多種多様なソート、検索、フィルタリング、またはデータセットの照会を可能にする点で大きな柔軟性を提供する。しかし、そのような柔軟性を提供するために、データセット内のレコード数が増えるに従って、一部はデータ構造を定義するのに必要なデータのために（すなわち「オーバーヘッド」）、一部は空のデータフィールド用に確保するスペースのために、データ構造が非常に大きく益々非効率的となる。速度を上げるために、リレーショナルデータベースにはしばしば検索インデックスが含まれるが、これがデータ構造全体のサイズをさらに大きくする。大きなサイズのデータ構造がその構造をソートまたは検索できる速度に与える影響の大部分は、インラインツリー特許に説明されており本書で繰り返さないが、大きなデータ構造がコンピュータまたはサーバーによって処理される方法から生じる。

［００３８］１またはそれ以上のインラインツリー特許に従って構成されたインラインツリーデータ構造の一例を図４に概略的に示す。図４のデータ構造の目的は、（ｉ）格納されたデータ構造の全体サイズを劇的に縮小することを可能にし（他の理由の中でも、たとえ数千万、あるいは数億またはそれ以上のレコードを含んでいても全体をＲＡＭに格納できるようにする）、（ｉｉ）データの所与のセグメントがＲＡＭからプロセッサキャッシュまたはレジスタに検索される回数を減らす（好ましくはデータセグメントごとに１回の検索に減らす）ことである。それぞれ１００フィールドの１００万レコードを有するデータセットについては、従来のデータ構造の同じデータセットと比較して、約５から１０分の１またはそれ以上のサイズ縮小が達成され観察されている。そのデータセットに対する単純な検索、ソート、またはフィルタ操作の場合、従来のデータ構造内の同じデータセットに対して実行される同様の操作と比較して、約５から１００倍以上のスピード向上が達成され観察されている。

［００３９］図４のデータ構造は、「インラインツリー」データ構造と呼ぶことができ、図１のツリーの枝と葉が分離され順番に配置されている。スプレッドシートのような行／列の配置も、リレーショナルデータベースのような表の配置もない。図４のデータ構造は、単一の長く連続したバイナリ文字列のシーケンス（すなわち、バイナリ数字の単一行）とみなすことができる。順序付けられたシーケンス内の各バイナリ文字列は、元になるデータセットのデータフィールド内の対応する英数字文字列を、サイズを小さくした方法で表している。バイナリ文字列はまた、（ｉ）１つのデータセグメントが処理のためにプロセッサキャッシュに取り込まれる際に、処理される次のセグメントが一緒に取り込まれ、（ｉｉ）そのセグメント内の全フィールドが、最初にプロセッサキャッシュに取り込まれた後に処理され、したがってプロセッサキャッシュに再度取り込まれる必要がなくなる、可能性を増大させる。

［００４０］インラインツリー出願に開示されているインラインツリーデータ構造の一般的な構成が、図４に概略的に示されている（ただし、これらの特許と本開示との間で用語がいくつか変えられている）。図中の各ブロックは、実質的に連続したバイナリ文字列のセットに対応し、各セットは、元となるデータレコードの１またはそれ以上のブランチノードデータフィールド値または末端ノードデータフィールド値を表す。例えば、Ｃ［ｘｙｚ］（すなわち、Ｃ［１１１］、Ｃ［１１２］等）とラベル付けされた末端ノードバイナリ文字列のセットは、対応する各データレコードについて（すなわち、対応する各末端ノードについて）、１またはそれ以上のデータフィールドＦＣ１（ｘ，ｙ，ｚ）、ＦＣ２（ｘ，ｙ，ｚ）等の値を表すバイナリ文字列を含む。同様に、Ｂ［ｘｙ］（すなわち、Ｂ［２１］、Ｂ［２２］等）とラベル付けされた第１レベルのブランチノードバイナリ文字列のセットは、データレコードの対応する第１レベルのブランチノードサブセットについて、１つ以上のデータフィールドＦＢ１（ｘ，ｙ）、ＦＢ２（ｘ，ｙ）等の値を表すバイナリ文字列を含む。Ａ［ｘ］（すなわちＡ［１］、Ａ［２］等）とラベル付けされた第２レベルのブランチノードバイナリ文字列のセットは、データレコードの対応する第２レベルサブセットについて、１またはそれ以上の第２レベルのデータフィールドＦＡ１データフィールド等に、値ＦＡ１（ｘ）、ＦＡ２（ｘ）等を表すバイナリ文字列を含む。

［００４１］図４の例では、バイナリ文字列のセットＡ［ｘ］、Ｂ［ｘｙ］、およびＣ［ｘｙｚ］はインラインツリーに配置することができ、これにより、データレコードの各第２レベルのブランチノードサブセットが、対応する実質的に隣接する第２レベルのブランチノードバイナリ文字列シーケンスを含むバイナリ索引によって表される。例えば、バイナリ文字列のセットＡ［１］、Ｂ［１ｙ］、およびＣ［１ｙｚ］のすべてが一緒になって、データレコードの第１の対応する第２レベルのブランチノードサブセットを表す第１の実質的に隣接する第２レベルのブランチノードバイナリ文字列シーケンスを形成する。バイナリ文字列のセットＡ［２］、Ｂ［２ｙ］、およびＣ［２ｙｚ］のすべてが一緒になって、データレコードの異なる第２の対応する第２レベルのブランチノードサブセットを表す第２の対応する、実質的に隣接した第２レベルのブランチノードバイナリ文字列シーケンスを形成し、これが同様に続く。各第２レベルのブランチノードバイナリ文字列のセットＡ［ｘ］は、それに対応する実質的に隣接する第２レベルのブランチノードバイナリ文字列シーケンス用のヘッダとして機能し得る。

［００４２］図４の例における各第２レベルのブランチノードバイナリ文字列シーケンス内では、バイナリ文字列のセットＢ［ｘｙ］およびＣ［ｘｙｚ］がインラインツリーに配置されており、したがって、データレコードの各第１レベルのブランチノードデータサブセットが、対応する実質的に隣接する第１レベルのバイナリ文字列シーケンスを含むバイナリ索引によって表される。例えば、バイナリ文字列のセットＢ［１１］およびＣ［１１ｚ］のすべてが一緒になって、対応する第１レベルのサブセットデータレコードを表す、対応する実質的に隣接する第１レベルのバイナリ文字列シーケンスを形成する。バイナリ文字列のセットＢ［２３］およびＣ［２３ｚ］のすべてが一緒になって、データレコードの異なる対応する第１レベルのサブセットを表す、異なる実質的に隣接する第２レベルのバイナリ文字列シーケンスを形成し、これが同様に続く。各第１レベルのブランチノードバイナリ文字列のセットＢ［ｘｙ］は、それに対応する実質的に隣接した第１レベルのバイナリ文字列シーケンス用のヘッダとして機能し得る。バイナリ文字列シーケンスの隣接配置の効果のいくつかが、インラインツリー特許においてさらに述べられており、ここで繰り返される必要はない。データセットのデータレコードを検索またはフィルタ処理するために、検索プログラムまたはフィルタプログラムが、インラインツリーの一部または全部をトラバースし、選択された検索条件またはフィルタ条件に対して各選択フィールドのバイナリ文字列を照会する。詳細がインラインツリー出願に開示されており、ここで繰り返す必要はない。

［００４３］図４の例では、インラインツリーは、複数のフィールドのフィールド値をエンコードするバイナリ文字列を含むことができる。いくつかの例では、すべてのフィールドのフィールド値がこのようにしてエンコードされ、他の例では、そのデータセットに対してフィルタリングできるように選択された特定のフィールドのみについて値がバイナリ文字列でエンコードされる。前述のように、大規模データセットは、各データレコードに数十から数百（またはそれ以上）のフィールドを含めることができる。いくつかの例では、例えば、所与の検索クエリまたはフィルタクエリに多数のフィールドが含まれる場合、図４の構成が、大規模データセットの高速な検索およびフィルタリングを実現するための最適な構成となり得る。しかしながら、データレコードを検索またはフィルタリングするために図４のインラインツリーを照会するステップには、インラインツリー内の各バイナリ文字列について、それが適切に解釈されるか（対応するフィールドがクエリの一部である場合）、あるいは適切にスキップされるか（対応するフィールドがクエリの一部ではない場合）のために、（それが表すフィールドに基づいて）そのバイナリ文字列のサイズを特定することが含まれる。場合によっては（例えば、所与の検索クエリまたはフィルタクエリに１つか２つか少数のフィールドしか含まれていない場合）、必要な文字列ごとのサイズ特定は、費やされる計算時間のかなりの部分を消費する。言い換えれば、クエリにほんの少しのフィールドしか含まれていない場合、検索またはフィルタプログラムは、その特定のクエリとは無関係なフィールドの値をエンコードする図４のバイナリ文字列をどのようにスキップするかを決定するためにその計算時間の多くを（おそらく大部分を）費やす傾向がある。データセット内の数十または数百のフィールドのうち、ほんの一握りのフィールドしか含まれていない検索またはフィルタクエリについて、（例えばインラインツリー特許の方法によって達成されるものを超える）さらなる速度向上を達成することが望ましい。本明細書に開示される本発明のデータ構造は、このような状況において速度向上を達成するものである。

［００４４］図５は、明細書では「ストリップドインラインツリー」と呼ぶが、請求項では「インラインツリーデータ構造」と規定される、その「ストリップ」された（取り除かれた）性質を定義するさらなる限定を有する本発明のデータ構造を概略的に示す。簡単に言うと、本発明のインラインツリーデータ構造は、（ｉ）ブランチノードデータフィールド値の符号化も表現も含まず、ブランチノードバイナリ文字列を含まない、かつ（ｉｉ）その最も基本的な形（すなわち最も「ストリップ」された形式）では、任意の末端ノードデータフィールド値を表すかエンコードした末端ノードバイナリ文字列を含まないことから、「ストリップド」と称される。

［００４５］ストリップドインラインツリーは、階層ツリーの末端ノードを表す、すなわちデータセットのデータレコードを表す、末端ノードバイナリ文字列Ｃ［ｘｙｚ］の順序付けられたシーケンスを含む。しかしながら、図４のインラインツリーとは異なり、図５のストリップドインラインツリーは、第１レベル、第２レベル、またはより高いレベルのブランチノードに対応するバイナリ文字列を含まず、ブランチノードデータフィールド値を符号化または表現しない。それにも拘わらず、末端ノードバイナリ文字列Ｃ［ｘｙｚ］は、図４のインラインツリーと同じ順序で、図５のストリップドインラインツリーに配置されている。より具体的には、図５の例では、末端ノードバイナリ文字列Ｃ［ｘｙｚ］がストリップドインラインツリーに配置されており、これによりデータレコードの第２レベルのブランチノードサブセットの各々が、ストリップドインラインツリー内の対応する単一の実質的に隣接する第２レベルのブランチノードバイナリ文字列シーケンスを含むバイナリ索引によって表される。例えば末端ノードバイナリ文字列Ｃ［１ｙｚ］のすべてが一緒になって、データレコードの第１の対応する第２レベルのブランチノードサブセットを表す第１の実質的に隣接した第２レベルのブランチノードバイナリ文字列シーケンスを形成し、末端ノードのバイナリ文字列Ｃ［２ｙｚ］のすべてが一緒になって、データレコードの異なる第２の対応する第２レベルのブランチノードサブセットを表す第２の対応する実質的に隣接する第２レベルのブランチノードバイナリ文字列シーケンスを形成し、これが同様に続く。図５の例における各第２レベルのブランチノードバイナリ文字列シーケンス内では、末端ノードバイナリ文字列Ｃ［ｘｙｚ］がストリップインラインツリーに配置され、これにより、データレコードの各第１レベルのブランチノードサブセットが対応する実質的に隣接する第１レベルのバイナリ文字列シーケンスを含むバイナリ索引によって表される。例えば末端ノードのバイナリ文字列Ｃ［１１ｚ］のすべてが一緒になって、データレコードの対応する第１レベルのサブセットを表す、対応する実質的に隣接する第１レベルのバイナリ文字列シーケンスを形成し、末端ノードバイナリ文字列Ｃ［５４ｚ］のすべてが一緒になって、データレコードの異なる対応する第１レベルのサブセットを表す、異なる実質的に隣接した第２レベルのバイナリ文字列シーケンスを形成し、これが同様に続く。

［００４６］ブランチノードデータフィールド値を表すブランチノードバイナリ文字列を省略することは、図５の本発明のストリップインラインツリーと図４のインラインツリーとの間の１つの区別点である。もう１つの違いは、バイナリ文字列が末端ノードのデータフィールドの値をエンコードまたは表現する必要がないことである。ストリップドインラインツリーの主な目的は、データを符号化または表現することではなく、データのツリー構造にわたるガイドとして機能することである。ストリップドインラインツリーは、データセットの階層ツリー構造の「トポロジ」をエンコードするものと考えることができる（もちろん、「トポロジ」の用語は大まかに使用されている）。各所与の末端ノードバイナリ文字列Ｃ［ｘｙｚ］は、（ｉ）順序付けされたシーケンス内の、末端ノードバイナリ文字列とすぐ隣の末端ノードバイナリ文字列とが、両方とも同じ第１レベルのブランチノードサブセットにあるデータレコードにそれぞれ対応すること、（ｉｉ）それぞれのデータレコードが、互いに異なる第１レベルのブランチノードサブセットにあること、あるいは（ｉｉｉ）末端ノードバイナリ文字列が、インラインツリーデータ構造の最後の末端ノードのバイナリ文字列であること、のいずれかを示す索引バイナリ文字列（「センチネル」文字列と呼ばれることもある）を含む。より高いレベルのデータフィールドが存在する場合、インジケータ文字列はさらに、（ｉｉ’）それぞれのデータレコードが互いに異なる第１レベルのブランチノードサブセットにあるが異なる高いレベルのブランチノードサブセットにはないこと、あるいは（ｉｉ”）第１のレベルよりも高い、ブランチノードサブセットの中の最高レベルの、それぞれのデータレコードもまた互いに異なる上位レベルのブランチノードサブセットにあること、を示すことができる。いくつかの例では、最初のものを除くすべての末端ノードバイナリ文字列について、隣接する末端ノードバイナリ文字列は、直前の末端ノードバイナリ文字列である。他の例では、最後のものを除くすべての末端ノードバイナリ文字列について、隣接する末端ノードバイナリ文字列は、すぐ後に続く末端ノードバイナリ文字列である。前者の例（すなわち、各末端ノードバイナリ文字列が先行文字列を示す場合）では、典型的には、それが最後の文字列であることを示す末端ノードバイナリ文字列はなく、検索プログラムには、検索の終了を判断するためにデータセット内のデータレコードの総数が提供される。後者の例（すなわち、各末端ノードバイナリ文字列が次の文字列を示す場合）では、「最後の文字列」の文字列が検索の終了を判断するための指標として機能することができる。そのような例を以下に論じるが、本開示および添付の特許請求の範囲は、一方または他方へと明示的に限定されない限り、両方の場合を包含すると解釈されるべきである。

［００４７］検索プログラムまたはフィルタプログラムの一部は、ストリップドインラインツリーの末端ノードバイナリ文字列Ｃ［ｘｙｚ］の順序付けられたシーケンスをトラバースするステップと、各段階で、インジケータ文字列に基づいて、現在の末端ノードバイナリ文字列によって表されたデータレコードが階層データセットのどこにあるかを特定するステップとを含む。すべての末端ノードバイナリ文字列Ｃ［ｘｙｚ］は同じ長さであるため、検索プログラムまたはフィルタプログラムは、ストリップドインラインツリーの次のバイナリ文字列のサイズを特定する必要がない。末端ノードバイナリ文字列間のサイズが一定であるため、図４のインラインツリーのトラバースと比較して、図５のストリップドインラインツリーのトラバースから著しく計算負荷が取り除かれる。１つの検索クエリで多数の中からごく僅かなデータフィールドのみが照会される検索またはフィルタ操作の場合、格納されているフィールド総数と比較した照会フィールド数に応じて、計算時間の短縮は２倍または３倍、さらには１０倍または２０倍以上になる。

［００４８］インラインツリー特許および図４のデータ構造とは対照的に、本発明のデータ構造では、データレコードの実際のフィールド値は、１またはそれ以上（多くの場合さらに多く）の補助データ構造、通常はフラットファイル、スプレッドシート、または英数字またはバイナリのアレイ（３レベル階層は図６Ａ～６Ｃ、または２レベル階層は図６Ｂと６Ｃのみのような）に格納またはエンコードされる。本明細書で使用される「アレイ」または「補助アレイ」という用語は、データセットのデータレコードのフィールド値を格納、表現、またはエンコードするために列挙されたものを含む任意の適切な補助データ構造を包含する。ほんの一握りのデータフィールドのみが任意の１つのクエリに含まれる場合には、各データフィールド、またはほんの少数のデータフィールドのセット用のフィールド値を、対応する別々のフラットファイルまたはアレイに格納することが有利となる。多数のそのようなアレイを使用して、多数の定義済みデータフィールドのフィールド値を格納することができる。各クエリに対し、照会フィールドに対応するそれらのアレイだけがメモリにロードされて調査されることを要する。クエリに関係のないフィールド値をスキップするために、プロセッサ時間や計算リソースは必要なく、クエリに関係のないフィールド値によってコンピュータメモリ（ＲＡＭまたはプロセッサキャッシュ）が占有されることもない。これらは両方とも、所与のデータセットの検索を提供するための大幅な速度向上または要求ハードウェアの軽減をもたらす。

［００４９］末端ノードデータフィールドのフィールド値は、１またはそれ以上の末端ノード補助アレイのセットに格納またはエンコードされ（図６Ｃ）、これは対応する末端ノードバイナリ文字列が図５のストリップドツリーに順序付けされているのと同じ順序で配列され、インデックスされ、またはその他の方法でアクセス可能である。第１レベルのブランチノードデータフィールドのフィールド値は、１またはそれ以上の第１レベルのブランチノード補助アレイのセット（図６Ｂ）に格納またはエンコードされ、これは対応する隣接する第１レベルのブランチノードバイナリ文字列シーケンスが図５のストリップドツリーに順序付けられているのと同じ順序で配列され、インデックスされ、またはアクセス可能である。第２レベル以上のブランチノードデータフィールドが存在する場合、対応するフィールド値は、１またはそれ以上の第２レベル以上のブランチノード補助アレイ（図６Ａ）の対応するセットに格納またはエンコードされ、これは対応する隣接する第２レベルまたはそれ以上のレベルのブランチノードバイナリ文字列シーケンスが図５のストリップされたツリーにおいて順序付けられるのと同じ順序で配列され、インデックスされ、またはアクセス可能である。各アレイは、単一のデータフィールドのみ、あるいは複数のデータフィールドのセットに対して値を格納することができる。複数のデータフィールドのフィールド値が単一のアレイにまとめて格納されている場合、それらは適切な方法、望ましい方法、または必要な方法でグループ化することができる。いくつかの例では、頻繁に一緒に検索されるフィールド（例えば、緯度と経度、年齢、性別、および配偶者の有無）を同じアレイにまとめて格納することができる。いくつかの例では、やや恣意的なデータフィールドのグループ化を用いて、アレイ要素ごとの整数バイトにアレイエントリを「埋め込む」ことができる（例えば、互いに論理的に関連していてもいなくてもよい８つの１ビットフィールド値を一緒に格納して、各アレイ要素が１バイトからなるようにする）。そのような構成により、典型的に、アレイの保存、アレイのメモリ（例えば、ＲＡＭまたはプロセッサキャッシュ）へのロード、または検索時のアレイへの照会、の速度や効率が向上する。

［００５０］いずれにせよ、フィールド値を多数のアレイに分割することで、特定の検索クエリに必要なアレイのみを選択的にメモリにロードすることができる。検索クエリに応じて、大幅な速度の向上、およびハードウェア要件の削減が、選択的な読み込みと、特定の検索クエリに対してデータセット「全体」をメモリにロードするために必要なメモリ要件（ＲＡＭまたはプロセッサキャッシュ）の削減からもたらされる（すべてのデータレコードのフィールド値をロードするが、指定された検索クエリに含まれるこれらのフィールドを含む、限られたフィールドのセットのみ）。例えば、ある年齢範囲（オレゴン州の有権者の例における末端ノードのデータフィールド）で、特定の議会地区（第１レベルのブランチノードデータフィールド）で、かつ特定の政治団体に所属する（別の末端ノードデータフィールド）有権者の検索が行われたとすると、検索を実行するためにこれら３つのデータフィールドをエンコードしたアレイのみをメモリにロードすればよい。他の数十（または数百）のフィールドはロードする必要がない。

［００５１］データフィールド値は、任意の適切な、望ましい、または必要なフォーマットまたはプロトコルに従って格納またはエンコードすることができる。これらのフォーマットやプロトコルはすべてのアレイで同じでも、複数のアレイで異なっていてもよい。いくつかの例では、データフィールド値の生の英数字表現、またはＡＳＣＩＩといったそのエンコードをアレイに格納することができる。他の例では、文字列インデックスまたは文字列インターニングなどの標準的な技術を用いて、英数字データフィールド値を二進数インデックスとしてエンコードすることができる。典型的に、アレイに格納されている文字列インデックスとそれらが表すデータフィールド値を関連付けるために、ある種のマスター文字列テーブルが使用される。他の例では、比較的制約のある複数のデータフィールド（例えば、市、議会地区、学区など、有権者の実施例における複数の住所関連のデータフィールド、任意の組み合わせでは表示できない）からのフィールド値を、いわゆるクランプインデックスに置き換えると、格納に必要なスペースが大幅に削減される。通常、アレイに格納されたクランプインデックスを対応するフィールド値のセットに関連付けるために、ある種のクランプインデックステーブルが使用される。これら両方の技術（文字列インデックスおよびデータクランピング）は、インラインツリー特許に広く記載されており、それらの説明はここで繰り返される必要はない。

［００５２］そのためにプログラムされたコンピュータプロセッサを用いて、本発明のデータ構造に対して実行される検索またはフィルタ操作は、次のように動作する。（ｉ）選択された照会データフィールドのセットが受信され、（ｉｉ）１またはそれ以上の検索条件のセットが受け取られ（すなわち、選択された照会データフィールドの各々について対応する照会フィールドサブレンジが選択される）、（ｉｉｉ）ストリップドインラインツリーの末端ノードバイナリ文字列が順番に照会され、そして並行して、選択された照会データフィールドに対応する補助データ構造の１またはそれ以上が同じ順番で照会され、（ｉｖ）１またはそれ以上の補助データ構造の照会に基づいて、検索条件を充足する、合致する、または一致するデータレコードが同定される。

［００５３］検索方法の一例を、図７のフローチャートに示す。この例では、データセットは、第２レベルおよび第１レベルのブランチノード（すなわち、それぞれＡレベルとＢレベルのブランチノード）と、末端ノード（すなわち、個々のデータレコードに対応するＣレベルのブランチノード）とを含む３レベルのツリー構造に編成されている。図７の検索方法は、必要に応じて、任意の数の２以上のレベルを有する階層ツリーデータセットへと修正または一般化することができる（例えば、２レベルの例が図８のフローチャートに示され、図７の以下の説明も適宜図８に当てはまる）。３レベルのデータセットに図７に示す方法を実行する実施例では、検索クエリは、階層の３つすべてのレベルで選択された照会データフィールドを含むことができる。言い換えれば、最も一般的な検索クエリは、以下を特定する：（ｉ）１またはそれ以上の選択された第２レベルの照会データフィールド（すなわち、Ａレベルのデータフィールド）と、選択された第２レベルの照会データフィールドの各々に対応するフィールド値の照会サブレンジ、（ｉｉ）１またはそれ以上の選択された第１レベルの照会データフィールド（すなわち、Ｂレベルのデータフィールド）と、選択された第１レベルの照会データフィールドの各々に対応するフィールド値の照会サブレンジ、（ｉｉｉ）１またはそれ以上の選択された末端ノードの照会データフィールド（すなわち、Ｃレベルデータフィールド）と、選択された末端ノード照会データフィールドの各々に対応するフィールド値の照会サブレンジ。検索クエリに応答して、選択された照会データフィールドに対応する末端ノード、第１レベル、および第２レベルのアレイがメモリにロードされる。他の例示的な方法では、検索クエリは、階層のすべてのレベルで照会データフィールドを含まなくてもよい。検索クエリの例の中には、末端ノード照会データフィールドのみ、第１レベルのブランチノード照会データフィールドのみ、上位レベルのブランチノード照会データフィールドのみ、階層の２つのレベルのみの照会データフィールド等を含めることができる。

［００５４］クエリを受信すると、そのためにプログラムされたコンピュータプロセッサを使用して、インラインツリーデータ構造の末端ノードバイナリ文字列の順序付けられたシーケンスが自動的に問い合わせられ（例えば、図７のフローチャートの１１５、１２５、および１３５、あるいは図８のフローチャートの１２５、および１３５）対応するインジケータ文字列が特定される。この例では、インジケータ文字列は以下を示す：（ｉ）次のデータレコードが同じ第１レベルのブランチノードサブセットにあるか（例えば、図７の１１５／１２５／１３５または図８の１２５／１３５の分岐「Ｃ」）、（ｉｉ）次のデータレコードが、異なる第１レベルのブランチノードサブセットにあるが、異なるより高いレベルのブランチノードサブセットにはないこと（より高いレベルのサブセットがない場合を含む。例えば、図７の１１５／１２５／１３５または図８の１２５／１３５の分岐「Ｂ」）、または（ｉｉｉ）次のデータレコードが異なるより高いレベルのブランチノードサブセットの中の最高レベル（例えば、図７の１１５／１２５／１３５の分岐「Ａ」。図８には該当しない）。

［００５５］インラインツリーの問い合わせと並行して、そのためにプログラムされたコンピュータプロセッサを使用して自動的に、対応する順序で、選択された照会データフィールドのフィールド値文字列を含む１またはそれ以上の補助データ構造の中でのみ、フィールド値文字列が問い合わせられる（例えば、図７のフローチャートの１１０、１２０、または１３０、あるいは図８のフローチャートの１２０または１３０）。検索クエリを満たす（すなわち、満たす、合致する、または一致する）データレコードが、１またはそれ以上の補助データ構造の問い合わせによって同定され、１４０で検索結果に追加される（すなわち、検索クエリを満たすデータレコードのリストまたは列挙に追加される）。検索クエリに関連するデータフィールド値を含むこれらの補助データ構造のみを調べることによって、使用されるメモリ（例えば、ＲＡＭまたはプロセッサキャッシュ）または必要な検索時間を大幅に削減することができる。全部ではないにしても、それらのフィールド値のうちどれが各データレコードについて質問されるかは、部分的にはインラインツリー構造から読み取られたインジケータ文字列によって決定される。例えば、図７の１３５において、インラインツリーデータ構造からのインジケータ文字列により、次のデータレコードにおいてどのフィールドが質問されるかが決定される。すなわち、分岐「Ａ」は、質問されるＡレベルの照会フィールド値へとつながり、分岐「Ｂ」は、質問されるＢレベルの照会フィールド値へとつながり、分岐「Ｃ」は、質問されるＣレベルの照会フィールド値へとつながる。

［００５６］与えられた検索クエリが階層の所与のレベルで照会データフィールドを含まない場合、すべてのデータレコードがその階層のそのレベルで照会されたフィールドと合致するとみなされ、そして対応するフィールド値を「質問する」（interrogate）との用語には、その階層のそのレベルに照会データフィールドがないと特定することが含まれる。いくつかの例では、Ａレベルの照会データフィールドを含まない検索クエリは、常に、図７の１１０で分岐「ＹＥＳ」に進む。いくつかの例では、Ｂレベルの照会データフィールドを含まない検索クエリは、常に、図７または図８の１２０で分岐「ＹＥＳ」に進む。いくつかの例では、Ｃレベルの照会データフィールドを含まない検索クエリは、常に、図７または図８の１３０で分岐「ＹＥＳ」に進む。これらの例のうちの最初の２つにおいて、所与の検索クエリに応答して対応する動的プログラムコードがオンデマンドで生成される場合、対応する決定地点１１５または１２５のうちの１またはそれ以上を生成プログラムコードから完全に省くことができる。

［００５７］必要な検索時間をさらに短縮することができる。検索クエリを満たさない各第１レベルのブランチノードフィールド値（すなわち、図７または図８の１２０から分岐「ＮＯ」へ）について、データレコードの対応する第１レベルのブランチノードサブセットの末端ノードデータフィールド（Ｃフィールド）を、問い合わせから省略することができる（図７または図８の１２５から分岐「Ｃ」）。検索プログラムは、異なる第１レベルのブランチノードサブセットを示すインジケータ文字列に達するまで、フィールド値を問い合わせることなく１２５をループする（図７または図８の１２５から分岐「Ｂ」へ）。検索プログラムは、１２０において次のＢレベルの照会データフィールドを調べることによって進む。同様に、検索クエリを満たさないより高いレベルの各ブランチノードフィールド値について（すなわち、図７の１１０から分岐「ＮＯ」；図８には当てはまらない）、データレコードの対応する第２レベルのブランチノードサブセットの第１レベルおよび末端ノードのデータフィールド（ＢフィールドとＣフィールド）を問い合わせから省略することができる（図７の１１５から分岐「Ｂ」、「Ｃ」）。検索プログラムは、インラインツリー内で異なる第２レベルのブランチノードサブセットを示すインジケータ文字列に達するまで、フィールド値を調べることなく１１５をループする（図７の１１５から分岐「Ａ」へ）。検索プログラムは、１１０で次のＡレベルの照会データフィールドを問い合わせることによって進む。これらの問い合わせを省略することにより、かなりの計算時間が節約される。検索クエリのいわゆるインタイムコンパイルが用いられるいくつかの例では、図７または図８のフローチャートの対応する部分は、階層の対応するレベルに照会すべく選択されたデータフィールドがない場合には完全に省略することができる。

［００５８］上述のように、インラインツリーデータ構造のインジケータ文字列は、データレコードの階層構造を通して適切にナビゲートし、データフィールド値の不要な問い合わせを減らすために、検索プログラムによって使用される（図７の１１５、１２５、および１３５、図８の１２５、および１３５で）。１５５／１２５／１１５のいずれかにおいて、「ＬＡＳＴ」のインジケータ文字列に遭遇した場合、検索は完了である（すなわち、データセット全体が検索された）ことに留意されたい。検索プログラムは、そのためにプログラムされたコンピュータプロセッサを用いて、上記の様々な問い合わせの過程で、検索クエリを満たす、合致する、または一致するとして同定されたデータレコードのリストまたは列挙を自動的に生成する。このリストまたは列挙は、検索結果を構成する。

［００５９］検索プログラムの進行は、例えば、補助データ構造において１つのアレイ要素から次のものへ、またはインラインツリーデータ構造において１つのバイナリ文字列から次のものへと移動することによって制御することができる。代替的または付加的に、任意の適切な１またはそれ以上のカウンタ、インジケータ、インデックス、またはポインタを任意の適切な方法で使用することができ、それらは検索プログラムがインラインツリーと補助データ構造を通って処理するにつれて増加または移動される。

［００６０］検索（時にはフィルタリングとも呼ばれる）プロセスは、通常、１またはそれ以上のプロセッサを含み、様々な適切な種類の１またはそれ以上のコンピュータ可読媒体を含むかこれに機能的に結合された、１またはそれ以上のコンピュータ、コンピュータシステム、またはサーバ上で動作するコンピュータプログラムとして具現化される。検索またはフィルタリング機能を実行するコンピュータ、システム、またはサーバは、元のデータセットからインラインツリー構造や補助データ構造を生成したデータ変換プロセスを実行したものと同じである必要はなく、多くの場合は同じではない。どちらの場合も（変換と検索／フィルタ処理）、コンピュータ、サーバー、またはシステムは、スタンドアロンのコンピュータであってもよいし、ローカルエリアネットワークまたはワイドエリアネットワーク（ＬＡＮまたはＷＡＮ）あるいはインターネットで接続された１台または複数台の装置であってもよい。検索またはフィルタリングに、任意の適切なハードウェアまたはハードウェアプラスソフトウェアの実装形態を採用することができる。

［００６１］元のデータセットの変換のために、そのデータフィールドが、データ構造のための適切な階層構成を決定するために調べられる。いくつかの例では、例えば元のデータセットが（図３のように）一連の一対多の関係で配置された一連のデータテーブルに配置されている場合、適切な選択が容易に明らかになるだろう。他の例では、適切な階層のためのいくつかの選択が可能であり、その１つは実行される検索の性質に基づいて選択され得る（例えば、有権者データの例における最高レベルのノードとしてストリート名を選択すると、地理的な検索またはフィルタリングができる）。例示的な販売データセットでは、顧客名を最上位ノードとしてデータセットを編成すると、顧客関連データフィールドに基づく検索やフィルタリングが容易となり、一方で商品を最高レベルのノードとしてデータセットを編成すると、製品に関するデータフィールドに基づく検索やフィルタリングが容易となる。階層が選択され定義されると、データフィールドを、任意の適切な、望ましい、または必要な保存形式または符号化方式（文字列インターニング、データクランピングなど）を使用して、１またはそれ以上の補助データ構造の間で任意の適切な、望ましいまたは必要な方法で分配することができる。インラインツリー特許のデータセットを越える本開示によるデータセット格納構成の利点は、データセットへの新しいデータレコード、または追加のデータフィールドをデータセットの既存のレコードに追加することがより簡単に追加できることである。ストリップドインラインツリーのすべてのバイナリ文字列は同じ長さであるため、新たなデータレコードの挿入位置を容易に確認することができる。同様に、新しいデータレコードのフィールド値を挿入する補助アレイ内の位置を容易に確認することができる。別の補助データ構造を追加するだけで、新たなデータフィールドを既存のデータレコードに追加することができる。

［００６２］最も「ストリップド（取り除かれた）」の形式では、インラインツリーデータ構造の各末端ノードバイナリ文字列は、インジケータ文字列のみを含む。しかし、いくつかの例では、各末端ノードバイナリ文字列は、インジケータ文字列とともに、対応するデータレコードの１またはそれ以上のデータフィールド値をエンコードするデータ文字列を含むことができる。ストリップドインラインツリーによって提供される速度上の利点を維持するために、すべてのデータレコードに対して同じデータフィールドをデータ文字列でエンコードする必要があり、対応するフィールド値は、得られたデータ文字列（末端ノードのバイナリ文字列も）が互いに同じ長さになるようにエンコードする必要がある。言い換えれば、ストリップドインラインツリーにエンコードされた追加のデータフィールド値は、文字列ごとの長さの特定や、各文字列の内容に関する決定を必要としない。ストリップドインラインツリーにエンコードされたデータフィールド値は、データセットの検索においてほとんど常に現れるデータフィールド、例えば空間的にリンクされたデータの空間座標、または時系列データの時系列インデックスにとって有利であり得る。

［００６３］検索またはフィルタリングの準備として、所与の検索クエリに関連すると判断されたストリップドインラインツリーデータ構造および１またはそれ以上の補助データ構造を、例えば、コンピュータやサーバーのＲＡＭ、プロセッサキャッシュなどのコンピュータプロセッサに直接アクセス可能な１またはそれ以上のコンピュータ可読媒体にロードすることができる。任意の適切な種類または構成のコンピュータシステムを、前述の方法のうちのいずれかを実行するように構成および接続することができる。有形媒体を含む物品は、コンピュータ可読命令をエンコードすることができ、これがコンピュータシステムに適用されると、コンピュータシステムに前述の方法のうちのいずれかを実行するように指示する。１またはそれ以上の有形のコンピュータ可読媒体を含む物品は、前述の方法のいずれかによって生成されたインラインツリーデータ構造および１またはそれ以上の補助データ構造を格納するようにエンコードすることができる。有形のコンピュータ可読媒体を含む物品は、前述の方法のうちのいずれかによって生成されたリストまたは列挙の電子索引を格納するようにエンコードすることができる。

［００６４］本明細書に開示されるシステムおよび方法は、ソフトウェアを介してプログラムされた汎用または特殊用途のコンピュータまたはサーバまたは他のプログラム可能なハードウェアデバイスとして、あるいはハードワイヤリングを介して「プログラム」されたハードウェアまたは機器、あるいはその２つの組み合わせとして実装することができる。「コンピュータ」または「サーバ」は、単一の装置であってもよいし、（単一の場所または複数の遠隔地に配置された）複数の対話型装置を含んでもよい。使用される場合、コンピュータプログラムまたは他のソフトウェアコードは、マイクロコード、マシンコード、ネットワークベースまたはウェブベースまたは一緒に動作する分散型ソフトウェアモジュール、ＲＡＭ、ＲＯＭ、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＣＤ－Ｒ／Ｗ、ＤＶＤ－ＲＯＭ、ＤＶＤ±Ｒ、ＤＶＤ±Ｒ／Ｗ、ハードドライブ、サムドライブ、フラッシュメモリ、光メディア、磁気メディア、半導体メディア、または任意の他の１またはそれ以上の適切な、現在存在するか将来開発される、有形の、非一時的な記憶媒体、におけるプログラミングを含むことによって、一時的または恒久的な記憶装置または可換型媒体に実装することができる。インラインツリーデータ構造または１またはそれ以上の補助データ構造を具体化する１またはそれ以上のバイナリデータファイルも、任意の１またはそれ以上の適切な現在のまたは将来開発される有形の非一時的なコンピュータ可読記憶媒体に格納することができる。

［００６５］上記に加えて、以下の実施例は本開示または添付の特許請求の範囲内に含まれる。

［００６６］例１．
データセットの電子索引を格納するようにエンコードされた１またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含む物品であって、前記電子索引は、インラインツリーデータ構造および１またはそれ以上の補助データ構造を含み、
（ａ）前記データセットは複数のデータレコードを有し、各データレコードは複数の対応する定義済みデータフィールドについてのフィールド値文字列を含み、
（ｂ）前記定義済みデータフィールドは、末端ノードデータフィールドと第１レベルのブランチノードデータフィールドとを含み、前記第１レベルのブランチノードデータフィールドは、前記第１レベルのブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリーの関係を定義し、これらのサブレンジは前記データセットのデータレコードの複数の第１レベルのブランチノードサブセットに対応し、
（ｃ）各第１レベルのブランチノードサブセットは、第１レベルのブランチノードデータフィールドのフィールド値文字列が対応するサブレンジ内に入るデータレコードを含み、
（ｄ）前記インラインツリーデータ構造は、末端ノードバイナリ文字列のみの順序付けられたシーケンスを含み、
（１）前記末端ノードバイナリ文字列と前記データセットのデータレコードとの間には一対一の対応関係があり、
（２）前記末端ノードバイナリ文字列は互いに同じ長さを有し、
（３）各末端ノードバイナリ文字列は、各末端ノードバイナリ文字列について、
（ｉ）前記順序付けされたシーケンス内の前記末端ノードバイナリ文字列およびすぐ隣の末端ノードバイナリ文字列が、ともに同じ第１レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
（ｉｉ）それぞれのデータレコードが互いに異なる第１レベルのブランチノードサブセットにあること、または
（ｉｉｉ）前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、を示すインジケータ文字列を含み、
（ｅ）第１レベルのブランチノードサブセットごとに、対応する末端ノードバイナリ文字列が、前記インラインツリーデータ構造内で単一の連続した文字列シーケンスを形成し、
（ｆ）前記１またはそれ以上の補助データ構造が、前記インラインツリーデータ構造内の末端ノードバイナリ文字列の順序付けられたシーケンスと同じ順序で配置、索引付け、またはアクセス可能なデータセットのデータレコードのフィールド値文字列の電子索引を含む、
ことを特徴とする物品。

［００６７］例２．
例１の物品において、各末端ノードバイナリ文字列について、前記インジケータ文字列は、
（ｉ）前記順序付けられたシーケンス内の前記末端ノードバイナリ文字列および直後の末端ノードバイナリ文字列が、ともに同じ第１レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
（ｉｉ）それぞれのデータレコードが互いに異なる第１レベルのブランチノードサブセットにあること、または
（ｉｉｉ）前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、を示すことを特徴とする物品。

［００６８］例３．
例１において、各末端ノードバイナリ文字列について、前記インジケータ文字列は、
（ｉ）前記順序付けられたシーケンス内の前記末端ノードバイナリ文字列および直前の末端ノードバイナリ文字列が、ともに同じ第１レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、または
（ｉｉ）それぞれのデータレコードは、互いに異なる第１レベルのブランチノードサブセットにあるが、異なる上位レベルのブランチノードサブセットにはないこと、を示すことを特徴とする物品。

［００６９］例４．
例１乃至３のいずれかの物品において、前記インラインツリーデータ構造の各末端ノードバイナリ文字列は、対応するインジケータ文字列のみを含み、対応するデータレコードのフィールド値をエンコードするいかなるデータ文字列も含まないことを特徴とする物品。

［００７０］例５．
例１乃至３のいずれかの物品において、前記インラインツリーデータ構造の各末端ノードバイナリ文字列は、対応するデータレコードの１またはそれ以上のフィールド値をエンコードするデータ文字列を含むことを特徴とする物品。

［００７１］例６．
例５の物品において、各データ文字列が、文字列インターニングによってエンコードされた１またはそれ以上のデータフィールド値を含むことを特徴とする物品。

［００７２］例７．
例１乃至６のいずれかの物品において、前記補助データ構造のうちの１またはそれ以上が、文字列インターニングによってエンコードされた１またはそれ以上のデータフィールド値を含むことを特徴とする物品。

［００７３］例８．
例１乃至７のいずれかの物品において、１またはそれ以上の補助データ構造が、１組の複数のクランプされたデータフィールド値をエンコードする１またはそれ以上のクランプデータフィールド値を含むことを特徴とする物品。

［００７４］例９．
例１乃至８のいずれかの物品において、前記インラインツリーデータ構造が、コンピュータランダムアクセスメモリまたはプロセッサキャッシュメモリに格納されていることを特徴とする物品。

［００７５］例１０．
例１乃至９のいずれかの物品を生成するためのコンピュータ実施方法であって、
（Ａ）データセットの第１の電子索引を、コンピュータシステムで受信するか、１またはそれ以上のコンピュータ可読記憶媒体から読み取るステップと、
（Ｂ）そのためにプログラムされ、１またはそれ以上の記憶媒体に機能的に結合されたコンピュータシステムの１またはそれ以上の電子プロセッサを使用して、データセットの第２の電子索引を生成するステップであって、前記第２の電子索引は、（１）インラインツリーデータ構造と、（２）１またはそれ以上の補助データ構造とを含む、ステップと、
（Ｃ）コンピュータシステムの１またはそれ以上の電子プロセッサに機能的に結合された１またはそれ以上の有形の非一時的コンピュータ可読記憶媒体に、前記インラインツリーデータ構造および前記１またはそれ以上の補助データ構造を格納するステップと、を含むことを特徴とする方法。

［００７６］例１１．
例１０の方法を実行するように構築、接続、およびプログラムされたコンピュータシステム。

［００７７］例１２．
コンピュータ可読命令をエンコードする１またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含む物品であって、コンピュータシステムに適用されると、例１０の方法を実行するようにコンピュータに命令することを特徴とする物品。

［００７８］例１３．
例１乃至９のいずれかの物品にエンコードされたインラインツリーデータ構造および１またはそれ以上の補助データ構造を問い合わせるためのコンピュータ実施方法であって、当該方法が、
（Ａ）コンピュータシステムにおいて、データセットの定義済みデータフィールドのうちの１またはそれ以上の選択された照会データフィールドのそれぞれについて、対応する照会フィールド値サブレンジに入る対応するフィールド値を含むデータセットのデータレコードに対する検索クエリを受け取るステップと、
（Ｂ）自動的に、そのためにプログラムされたコンピュータプロセッサで、前記インラインツリーデータ構造の末端ノードバイナリ文字列の順序付けられたシーケンスを順番に問い合わせて、対応するインジケータ文字列を同定するステップと、
（Ｃ）パート（Ｂ）で問い合わせられた各末端ノードバイナリ文字列として、自動的に、そのためにプログラムされたコンピュータプロセッサで、１またはそれ以上の補助データ構造において、対応するデータレコードの選択された照会データフィールドの中でのみフィールド値文字列を問い合わせ、パート（Ａ）の検索クエリを満たすデータレコードを同定するステップであって、パート（Ｃ）で各データレコードについて問い合わせられるフィールド値文字列は、パート（Ｂ）で同定された対応するインジケータ文字列によって部分的に決定される、ステップと、
（Ｄ）パート（Ａ）の検索クエリを満たさない各第１レベルのブランチノードフィールド値について、パート（Ｃ）の問い合わせから、データレコードの対応する第１レベルのブランチノードサブセットの末端ノードデータフィールドを除外するステップと、
（Ｅ）そのためにプログラムされたコンピュータプロセッサで、パート（Ａ）で受け取られた検索クエリを満たすものとして、パート（Ｃ）で同定されたデータレコードのリストまたは列挙を自動的に生成するステップとを含むことを特徴とする方法。

［００７９］例１４．
例１３の方法を実行するように構築、接続、およびプログラムされたコンピューターシステム。

［００８０］例１５．
コンピュータ可読命令をエンコードする１またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含む物品であって、コンピュータシステムに適用されると、例１３の方法を実行するようにコンピュータに命令することを特徴とする物品。

［００８１］例１６．
例１から９のいずれか１つの物品において、
（ｂ’）前記定義済みデータフィールドがさらに、１またはそれ以上のレベルの上位レベルのブランチノードデータフィールドを含み、前記第１レベルおよび上位レベルのブランチノードデータフィールドは、ブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリー関係を定義し、これらのサブレンジは、前記データせっとんデータレコードの、複数の第１レベルのブランチノードサブセット、および１またはそれ以上のレベルの上位レベルのブランチノードサブセットに対応しており、
（ｃ’）上位レベルのブランチノードデータフィールドの各レベルについて、各上位レベルのブランチノードサブセットは、そのレベルの前記上位レベルのブランチノードデータフィールドのフィールド値文字列が、対応するサブレンジに入るデータレコードを含み、
（ｄ’）各末端ノードバイナリ文字列について、前記インジケータ文字列は、
（ｉ）前記順序付けられたシーケンスにおける前記末端ノードバイナリ文字列およびすぐ隣の末端ノードバイナリ文字列が、両方とも同じ第１レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
（ｉｉ）それぞれのデータレコードは、互いに異なる第１レベルのブランチノードサブセットにあるが、異なるより高いレベルのブランチノードサブセットにはないこと、
（ｉｉｉ）それぞれのデータレコードが互いに異なる第１レベルのブランチノードサブセットにあり、それぞれのデータレコードでのブランチノードサブセットの中の最高レベルも、互いに異なる上位レベルのブランチノードサブセットにあること、または
（ｉｖ）前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、を示し、
（ｅ’）各上位レベルのブランチノードサブセットについて、対応する末端ノードバイナリ文字列は、前記インラインツリーデータ構造内で単一の隣接する文字列シーケンスを形成することを特徴とする物品。

［００８２］例１７．
例１６の物品において、各末端ノードバイナリ文字列について、前記インジケータ文字列は、
（ｉ）順序付けられたシーケンス内の前記末端ノードバイナリ文字列および直後に続く末端ノードバイナリ文字列が、両方とも同じ第１レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
（ｉｉ）それぞれのデータレコードは互いに異なる第１レベルのブランチノードサブセットにあるが、異なるより高いレベルのブランチノードサブセットにはないこと、
（ｉｉｉ）それぞれのデータレコードは、互いに異なる第１レベルのブランチノードサブセットにあり、それぞれのデータレコードでのブランチノードサブセットの中の最高レベルも、互いに異なる上位レベルのブランチノードサブセットにあること、または、
（ｉｖ）前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、を示すことを特徴とする物品。

［００８３］例１８．
例１６の物品において、各末端ノードバイナリ文字列について、前記インジケータ文字列は、
（ｉ）前記順序付けされたシーケンスにおける末端ノードバイナリ文字列および直前の末端ノードバイナリ文字列が、両方とも同じ第１レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
（ｉｉ）それぞれのデータレコードは、互いに異なる第１レベルのブランチノードサブセットにあるが、異なる上位レベルのブランチノードサブセットにはないこと、または
（ｉｉｉ）それぞれのデータレコードは、互いに異なる第１レベルのブランチノードサブセットにあり、それぞれのデータレコードでのブランチノードサブセットの中の最高レベルも、互いに異なる上位レベルのブランチノードサブセットにあること、を示すことを特徴とする物品。

［００８４］例１９．
例１６乃至１８のいずれかの物品を生成するためのコンピュータ実施方法であって、
（Ａ）データセットの第１の電子索引を、コンピュータシステムで受信するか、１またはそれ以上のコンピュータ可読記憶媒体から読み取るステップと、
（Ｂ）そのためにプログラムされ、１またはそれ以上の記憶媒体に機能的に結合されたコンピュータシステムの１またはそれ以上の電子プロセッサを使用して、前記データセットの第２の電子索引を生成するステップであって、当該第２の電子索引が、（１）インラインツリーデータ構造と、（２）１またはそれ以上の補助データ構造とを含むステップと、
（Ｃ）コンピュータシステムの１またはそれ以上の電子プロセッサに機能的に結合された１またはそれ以上の有形の非一時的コンピュータ可読記憶媒体に、前記インラインツリーデータ構造および１またはそれ以上の補助データ構造を格納するステップとを含むことを特徴とする方法。

［００８５］例２０．
例１９の方法を実行するように構築、接続、およびプログラムされたコンピューターシステム。

［００８６］例２１．
コンピュータ可読命令をエンコードする１またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含む物品であって、コンピュータシステムに適用されると、例１９の方法を実行するようにコンピュータに命令することを特徴とする物品。

［００８７］例２２．
例１６乃至１８のいずれかの物品にエンコードされたインラインツリーデータ構造および１またはそれ以上の補助データ構造を問い合わせるためのコンピュータ実施方法であって、当該方法が、
（Ａ）コンピュータシステムにおいて、データセットの定義済みデータフィールドのうちの１またはそれ以上の選択された照会データフィールドのそれぞれについて、対応する照会フィールド値サブレンジに入る対応するフィールド値を含むデータセットのデータレコードに対する検索クエリを受け取るステップと、
（Ｂ）自動的に、そのためにプログラムされたコンピュータプロセッサで、前記インラインツリーデータ構造の末端ノードバイナリ文字列の順序付けられたシーケンスを順番に問い合わせて、対応するインジケータ文字列を同定するステップと、
（Ｃ）パート（Ｂ）で問い合わせられた各末端ノードバイナリ文字列として、自動的に、そのためにプログラムされたコンピュータプロセッサで、１またはそれ以上の補助データ構造において、対応するデータレコードの選択された照会データフィールドの中でのみフィールド値文字列を問い合わせ、パート（Ａ）の検索クエリを満たすデータレコードを同定するステップであって、パート（Ｃ）で各データレコードについて問い合わせられるフィールド値文字列は、パート（Ｂ）で同定された対応するインジケータ文字列によって部分的に決定される、ステップと、
（Ｄ）パート（Ａ）の検索クエリを満たさない各第１レベルのブランチノードフィールド値について、パート（Ｃ）の問い合わせから、データレコードの対応する第１レベルのブランチノードサブセットの末端ノードデータフィールドを除外するステップと、
（Ｅ）パート（Ａ）の検索クエリを満たさない各上位レベルのブランチノードフィールド値について、パート（Ｃ）の問い合わせから、データレコードの対応する上位レベルのブランチノードサブセットの第１レベルノードデータフィールドおよび末端ノードデータフィールドを除外するステップと、
（Ｆ）そのためにプログラムされたコンピュータプロセッサで、パート（Ａ）で受信された検索クエリを満たすものとして、パート（Ｃ）で同定されたデータレコードのリストまたは列挙を自動的に生成するステップとを含むことを特徴とする方法。

［００８８］例２３．
例２２の方法を実行するように構築、接続、およびプログラムされたコンピューターシステム。

［００８９］例２４．
コンピュータ可読命令をエンコードする１またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含む物品であって、コンピュータシステムに適用されると、例２２の方法を実行するようにコンピュータに命令することを特徴とする物品。

［００９０］例２５．
例１３または２２のいずれかの方法によって生成されたリストまたは列挙の電子索引を格納するようにエンコードされた１またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含むことを特徴とする物品。

［００９１］開示された例示的な実施形態および方法の均等物は、本開示または添付の特許請求の範囲の範囲内にあるものとする。開示された例示的な実施形態および方法、ならびにそれらの均等物は、本開示または添付の特許請求の範囲内に留まりながら変更され得ることが意図されている。

［００９２］上記の発明の詳細な説明では、開示を簡素化する目的で様々な特徴をいくつかの例示的実施形態にまとめられている。この開示方法は、クレームされた実施形態が、対応する請求項に明示的に列挙されたもの以上の特徴を必要とするという意図を反映していると解釈されるべきではない。むしろ、添付の特許請求の範囲が反映するように、発明の主題は、単一の開示された例示的実施形態のすべての特徴より少ない特徴にあり得る。したがって、添付の特許請求の範囲は、詳細な説明に組み込まれ、各特許請求の範囲は、別個の開示された実施形態としてそれ自体成立する。しかしながら、本開示はまた、本開示または添付の特許請求の範囲に見られる任意の適切な組の１またはそれ以上の開示またはクレームされた特徴（すなわち、不適合でも相互排他的でもない一組の特徴）であって、本明細書に明示的に開示されていない組を含む実施形態を暗黙的に開示するものとして解釈される。さらに、開示の目的のために、添付の従属請求項のそれぞれは、マルチディペンド形式で書かれ、矛盾しないすべての先行請求項に従属するように解釈されるべきである。添付の特許請求の範囲は、本明細書に開示されている主題の全部を必ずしも包含するものではないことにさらに留意されたい。

［００９３］本開示および添付の特許請求の範囲の目的のために、接続詞「または」は包括的に解釈されるべきである（例えば、「犬または猫」は「犬または猫またはその両方」として解釈されるである。例えば、「犬、猫、またはネズミ」は、「犬、または猫、またはマウス、または任意の２つ、または３つすべて」と解釈される）。ただし、（ｉ）例えば、「・・・または・・・のどちらか」、「・・・のうちの１つ」、または類似の言葉を使用した場合、（ｉｉ）列挙された選択肢のうちの２つ以上が特定の文脈内で相互排他的である場合、「または」は、相互に排他的ではない選択肢を含む組み合わせのみを包含する。本開示および添付の特許請求の範囲について、用語「具える」、「含む」、「有する」、およびそれらの変形は、それらが現れる場合はいつでも、オープンエンド用語として解釈されるべきであり、他に明示的に述べられていない限り、各例の後に「少なくとも」という言葉が付されているのと同じ意味である。本開示または添付の特許請求の範囲の目的のために、数量に関して「およそ等しい」、「実質的に等しい」、「約～より大きい」、「約～未満」などの用語が使用される場合、異なる解釈が明示的に述べられていない限り、測定精度および有効数字に関する標準的な慣習が適用されるものとする。「実質的にない」、「実質的に存在しない」、「実質的に排除された」、「ほぼゼロに等しい」、「無視できる」などのフレーズによって記載されるヌル量については、そのようなフレーズは、それぞれ問題となる量が開示または特許請求の範囲に記載された装置または方法の意図された動作または使用の文脈における実際的な目的のために、装置または方法の全体的な振る舞いまたは性能が、実際に完全に取り除かれた、正確にゼロに等しい、またはその他の正確に無であるヌル量の場合と変わらない程度に低減または減少されたことを意味する。

［００９４］添付の特許請求の範囲において、請求項の要素、ステップ、限定、または他の部分の任意の表示（例えば、第１、第２、第３など、（ａ）、（ｂ）、（ｃ）など、または（ｉ）、（ｉｉ）、（ｉｉｉ）など）は、明確にする目的のためだけであり、そのように表示された請求項部分の何らかの順序付けまたは優先順位を暗示するものとして解釈されるべきではない。そのような順序付けや優先順位が意図されている場合、それは請求項に明示的に列挙されるか、場合によっては、請求項の特定の内容に基づいて暗黙的または内在的なものとなる。添付の特許請求の範囲において、米国特許法第１１２条（ｆ）の規定を装置クレームに適用する場合、「手段」という単語がその装置クレームに現れる。それらの規定が方法クレームに適用される場合、「ステップ」という単語がその方法クレームに現れる。逆に、「手段」または「ステップ」という言葉がクレームに現れない場合、その場合は、３５ＵＳＣ§１１２（ｆ）の規定は、そのクレームに対する適用を意図しない。

［００９５］１またはそれ以上の開示が参照により本明細書に組み込まれ、そのような組み込まれた開示が本開示と部分的または全体的に矛盾するか、またはそれらと範囲が異なる場合、矛盾する範囲、より広い開示、またはより広い用語の定義に限り、本開示が支配する。そのような組み込まれた開示が互いに部分的または全体的に矛盾する場合は、矛盾する範囲において、後の開示が支配する。

［００９６］要約は、特許文献の中で特定の主題を探している人々への援助として必要に応じて提供される。しかしながら、要約は、その中に列挙されているいかなる要素、特徴、または限定も、いかなる特定の請求項によっても必然的に包含されることを意味することを意図するものではない。各請求項に含まれる主題の範囲は、その請求項のみの列挙によって決定されるものとする。

Claims (22)

1. データセットの電子索引を格納するようにエンコードされた１またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含む物品であって、前記電子索引は、インラインツリーデータ構造および１またはそれ以上の補助データ構造を含み、
   （ａ）前記データセットは複数のデータレコードを有し、各データレコードは複数の対応する定義済みデータフィールドについてのフィールド値文字列を含み、
   （ｂ）前記定義済みデータフィールドは、末端ノードデータフィールドと第１レベルのブランチノードデータフィールドとを含み、前記第１レベルのブランチノードデータフィールドは、前記第１レベルのブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリーの関係を定義し、これらのサブレンジは前記データセットのデータレコードの複数の第１レベルのブランチノードサブセットに対応し、
   （ｃ）各第１レベルのブランチノードサブセットは、第１レベルのブランチノードデータフィールドのフィールド値文字列が対応するサブレンジ内に入るデータレコードを含み、
   （ｄ）前記インラインツリーデータ構造は、末端ノードバイナリ文字列のみの順序付けられたシーケンスを含み、
   （１）前記末端ノードバイナリ文字列と前記データセットのデータレコードとの間には一対一の対応関係があり、
   （２）前記末端ノードバイナリ文字列は互いに同じ長さを有し、
   （３）各末端ノードバイナリ文字列は、各末端ノードバイナリ文字列について、
   （ｉ）前記順序付けされたシーケンス内の前記末端ノードバイナリ文字列およびすぐ隣の末端ノードバイナリ文字列が、ともに同じ第１レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
   （ｉｉ）それぞれのデータレコードが互いに異なる第１レベルのブランチノードサブセットにあること、または
   （ｉｉｉ）前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、を示すインジケータ文字列を含み、
   （ｅ）第１レベルのブランチノードサブセットごとに、対応する末端ノードバイナリ文字列が、前記インラインツリーデータ構造内で単一の連続した文字列シーケンスを形成し、
   （ｆ）前記１またはそれ以上の補助データ構造が、前記インラインツリーデータ構造内の末端ノードバイナリ文字列の順序付けられたシーケンスと同じ順序で配置、索引付け、またはアクセス可能なデータセットのデータレコードのフィールド値文字列の電子索引を含む、ことを特徴とする物品。
2. 請求項１の物品を生成するためのコンピュータ実施方法であって、
   （Ａ）データセットの第１の電子索引を、コンピュータシステムで受信するか、１またはそれ以上のコンピュータ可読記憶媒体から読み取るステップと、
   （Ｂ）そのためにプログラムされ、１またはそれ以上の記憶媒体に機能的に結合されたコンピュータシステムの１またはそれ以上の電子プロセッサを使用して、データセットの第２の電子索引を生成するステップであって、前記第２の電子索引は、（１）インラインツリーデータ構造と、（２）１またはそれ以上の補助データ構造とを含む、ステップと、
   （Ｃ）コンピュータシステムの１またはそれ以上の電子プロセッサに機能的に結合された１またはそれ以上の有形の非一時的コンピュータ可読記憶媒体に、前記インラインツリーデータ構造および前記１またはそれ以上の補助データ構造を格納するステップと、を含むことを特徴とする方法。
3. 請求項１の物品にエンコードされたインラインツリーデータ構造および１またはそれ以上の補助データ構造を問い合わせるためのコンピュータ実施方法であって、当該方法が、
   （Ａ）コンピュータシステムにおいて、データセットの定義済みデータフィールドのうちの１またはそれ以上の選択された照会データフィールドのそれぞれについて、対応する照会フィールド値サブレンジに入る対応するフィールド値を含む、データセットのデータレコードに対する検索クエリを受信するステップと、
   （Ｂ）自動的に、そのためにプログラムされたコンピュータプロセッサで、前記インラインツリーデータ構造の末端ノードバイナリ文字列の順序付けられたシーケンスを順番に問い合わせて、対応するインジケータ文字列を同定するステップと、
   （Ｃ）パート（Ｂ）で問い合わせた各末端ノードバイナリ文字列と同様に、そのためにプログラムされたコンピュータプロセッサで自動的に、１またはそれ以上の補助データ構造において、対応するデータレコードの選択された照会データフィールドのみについてフィールド値文字列を問い合わせ、パート（Ａ）の検索クエリを満たすデータレコードを同定するステップであって、パート（Ｃ）で各データレコードについて問い合わせられるフィールド値文字列は、パート（Ｂ）で同定された対応するインジケータ文字列によって部分的に決定される、ステップと、
   （Ｄ）パート（Ａ）の検索クエリを満たさない各第１レベルのブランチノードフィールド値について、パート（Ｃ）の問い合わせから、データレコードの対応する第１レベルのブランチノードサブセットの末端ノードデータフィールドを除外するステップと、
   （Ｅ）そのためにプログラムされたコンピュータプロセッサで、パート（Ａ）で受信した検索クエリを満たすものとして、パート（Ｃ）で同定されたデータレコードのリストまたは列挙を自動的に生成するステップとを含むことを特徴とする方法。
4. 請求項１の物品において、各末端ノードバイナリ文字列について、前記インジケータ文字列は、
   （ｉ）前記順序付けられたシーケンスにおける前記末端ノードバイナリ文字列および直後の末端ノードバイナリ文字列が、ともに同じ第１レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
   （ｉｉ）それぞれのデータレコードが互いに異なる第１レベルのブランチノードサブセットにあること、または
   （ｉｉｉ）前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、を示すことを特徴とする物品。
5. 請求項１の物品において、各末端ノードバイナリ文字列について、前記インジケータ文字列は、
   （ｉ）前記順序付けられたシーケンスにおける前記末端ノードバイナリ文字列および直前の末端ノードバイナリ文字列が、ともに同じ第１レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、または
   （ｉｉ）それぞれのデータレコードは、互いに異なる第１レベルのブランチノードサブセットにあるが、異なる上位レベルのブランチノードサブセットにはないこと、を示すことを特徴とする物品。
6. 請求項１の物品において、前記インラインツリーデータ構造の各末端ノードバイナリ文字列は、対応するインジケータ文字列のみを含み、対応するデータレコードのフィールド値をエンコードするデータ文字列を含まないことを特徴とする物品。
7. 請求項１の物品において、前記インラインツリーデータ構造の各末端ノードバイナリ文字列は、対応するデータレコードの１またはそれ以上のフィールド値をエンコードするデータ文字列を含むことを特徴とする物品。
8. 請求項７の物品において、各データ文字列が、文字列インターニングによってエンコードされた１またはそれ以上のデータフィールド値を含むことを特徴とする物品。
9. 請求項１の物品において、前記補助データ構造のうちの１またはそれ以上が、文字列インターニングによってエンコードされた１またはそれ以上のデータフィールド値を含むことを特徴とする物品。
10. 請求項１の物品において、前記補助データ構造のうちの１またはそれ以上が、１組の複数のクランプされたデータフィールド値をエンコードする１またはそれ以上のクランプデータフィールド値を含むことを特徴とする物品。
11. 請求項１の物品において、前記インラインツリーデータ構造が、コンピュータランダムアクセスメモリまたはプロセッサキャッシュメモリに格納されていることを特徴とする物品。
12. 請求項１の物品において、
    （ｂ’）前記定義済みデータフィールドがさらに、１またはそれ以上のレベルの上位レベルのブランチノードデータフィールドを含み、前記第１レベルおよび上位レベルのブランチノードデータフィールドは、ブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリー関係を定義し、これらのサブレンジは、前記データセットのデータレコードの、複数の第１レベルのブランチノードサブセット、および１またはそれ以上のレベルの上位レベルのブランチノードサブセットに対応しており、
    （ｃ’）上位レベルのブランチノードデータフィールドの各レベルについて、各上位レベルのブランチノードサブセットは、そのレベルの前記上位レベルのブランチノードデータフィールドのフィールド値文字列が、対応するサブレンジに入るデータレコードを含み、
    （ｄ’）各末端ノードバイナリ文字列について、前記インジケータ文字列は、
    （ｉ）前記順序付けられたシーケンスにおける前記末端ノードバイナリ文字列およびすぐ隣の末端ノードバイナリ文字列が、両方とも同じ第１レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
    （ｉｉ）それぞれのデータレコードは、互いに異なる第１レベルのブランチノードサブセットにあるが、異なるより高いレベルのブランチノードサブセットにはないこと、
    （ｉｉｉ）それぞれのデータレコードが互いに異なる第１レベルのブランチノードサブセットにあり、それぞれのデータレコードでのブランチノードサブセットの中の最高レベルも、互いに異なる上位レベルのブランチノードサブセットにあること、または
    （ｉｖ）前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、を示し、
    （ｅ’）各上位レベルのブランチノードサブセットについて、対応する末端ノードバイナリ文字列は、前記インラインツリーデータ構造内で単一の隣接する文字列シーケンスを形成することを特徴とする物品。
13. 請求項１２の物品を生成するためのコンピュータ実施方法であって、
    （Ａ）データセットの第１の電子索引を、コンピュータシステムで受信するか、１またはそれ以上のコンピュータ可読記憶媒体から読み取るステップと、
    （Ｂ）そのためにプログラムされ、１またはそれ以上の記憶媒体に機能的に結合されたコンピュータシステムの１またはそれ以上の電子プロセッサを使用して、前記データセットの第２の電子索引を生成するステップであって、当該第２の電子索引が、（１）インラインツリーデータ構造と、（２）１またはそれ以上の補助データ構造とを含むステップと、
    （Ｃ）コンピュータシステムの１またはそれ以上の電子プロセッサに機能的に結合された１またはそれ以上の有形の非一時的コンピュータ可読記憶媒体に、前記インラインツリーデータ構造および１またはそれ以上の補助データ構造を格納するステップとを含むことを特徴とする方法。
14. 請求項１２の物品にエンコードされたインラインツリーデータ構造および１またはそれ以上の補助データ構造を問い合わせるためのコンピュータ実施方法であって、当該方法が、
    （Ａ）コンピュータシステムにおいて、データセットの定義済みデータフィールドのうちの１またはそれ以上の選択された照会データフィールドのそれぞれについて、対応する照会フィールド値サブレンジに入る対応するフィールド値を含む、データセットのデータレコードに対する検索クエリを受信するステップと、
    （Ｂ）自動的に、そのためにプログラムされたコンピュータプロセッサで、前記インラインツリーデータ構造の末端ノードバイナリ文字列の順序付けられたシーケンスを順番に問い合わせて、対応するインジケータ文字列を同定するステップと、
    （Ｃ）パート（Ｂ）で問い合わせられた各末端ノードバイナリ文字列と同様に、そのためにプログラムされたコンピュータプロセッサで自動的に、１またはそれ以上の補助データ構造において、対応するデータレコードの選択された照会データフィールドのみについてフィールド値文字列を問い合わせ、パート（Ａ）の検索クエリを満たすデータレコードを同定するステップであって、パート（Ｃ）で各データレコードについて問い合わせられるフィールド値文字列は、パート（Ｂ）で同定された対応するインジケータ文字列によって部分的に決定される、ステップと、
    （Ｄ）パート（Ａ）の検索クエリを満たさない各第１レベルのブランチノードフィールド値について、パート（Ｃ）の問い合わせから、データレコードの対応する第１レベルのブランチノードサブセットの末端ノードデータフィールドを除外するステップと、
    （Ｅ）パート（Ａ）の検索クエリを満たさない各上位レベルのブランチノードフィールド値について、パート（Ｃ）の問い合わせから、データレコードの対応する上位レベルのブランチノードサブセットの第１レベルノードデータフィールドおよび末端ノードデータフィールドを除外するステップと、
    （Ｆ）そのためにプログラムされたコンピュータプロセッサで、パート（Ａ）で受信された検索クエリを満たすものとして、パート（Ｃ）で同定されたデータレコードのリストまたは列挙を自動的に生成するステップとを含むことを特徴とする方法。
15. 請求項１２の物品において、各末端ノードバイナリ文字列について、前記インジケータ文字列は、
    （ｉ）順序付けられたシーケンス内の前記末端ノードバイナリ文字列および直後に続く末端ノードバイナリ文字列が、両方とも同じ第１レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
    （ｉｉ）それぞれのデータレコードは互いに異なる第１レベルのブランチノードサブセットにあるが、異なるより高いレベルのブランチノードサブセットにはないこと、
    （ｉｉｉ）それぞれのデータレコードは、互いに異なる第１レベルのブランチノードサブセットにあり、それぞれのデータレコードでのブランチノードサブセットの中の最高レベルも、互いに異なる上位レベルのブランチノードサブセットにあること、または、
    （ｉｖ）前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、を示すことを特徴とする物品。
16. 請求項１２の物品において、各末端ノードバイナリ文字列について、前記インジケータ文字列は、
    （ｉ）前記順序付けされたシーケンスにおける末端ノードバイナリ文字列および直前の末端ノードバイナリ文字列が、両方とも同じ第１レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
    （ｉｉ）それぞれのデータレコードは、互いに異なる第１レベルのブランチノードサブセットにあるが、異なる上位レベルのブランチノードサブセットにはないこと、または
    （ｉｉｉ）それぞれのデータレコードは、互いに異なる第１レベルのブランチノードサブセットにあり、それぞれのデータレコードでのブランチノードサブセットの中の最高レベルも、互いに異なる上位レベルのブランチノードサブセットにあること、を示すことを特徴とする物品。
17. 請求項１２の物品において、前記インラインツリーデータ構造の各末端ノードバイナリ文字列は、対応するインジケータ文字列のみを含み、対応するデータレコードのフィールド値をエンコードするデータ文字列を含まないことを特徴とする物品。
18. 請求項１２の物品において、前記インラインツリーデータ構造の各末端ノードバイナリ文字列は、対応するデータレコードの１またはそれ以上のフィールド値をエンコードするデータ文字列を含むことを特徴とする物品。
19. 請求項１８の物品において、各データ文字列が、文字列インターニングによってエンコードされた１またはそれ以上のデータフィールド値を含むことを特徴とする物品。
20. 請求項１２の物品において、前記補助データ構造のうちの１またはそれ以上が、文字列インターニングによってエンコードされた１またはそれ以上のデータフィールド値を含むことを特徴とする物品。
21. 請求項１２の物品において、前記補助データ構造のうちの１またはそれ以上が、１組の複数のクランプされたデータフィールド値をエンコードする１またはそれ以上のクランプデータフィールド値を含むことを特徴とする物品。
22. 請求項１２の物品において、前記インラインツリーデータ構造が、コンピュータランダムアクセスメモリまたはプロセッサキャッシュメモリに格納されていることを特徴とする物品。
    

Images