IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ムーンシャドウ モバイル,インコーポレイテッドの特許一覧

特許7257068大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造
<>
  • 特許-大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造 図1
  • 特許-大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造 図2
  • 特許-大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造 図3
  • 特許-大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造 図4
  • 特許-大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造 図5
  • 特許-大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造 図6-1
  • 特許-大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造 図6-2
  • 特許-大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造 図7
  • 特許-大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-04-05
(45)【発行日】2023-04-13
(54)【発明の名称】大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造
(51)【国際特許分類】
   G06F 16/22 20190101AFI20230406BHJP
【FI】
G06F16/22
【請求項の数】 12
【外国語出願】
(21)【出願番号】P 2022001450
(22)【出願日】2022-01-07
(62)【分割の表示】P 2019506695の分割
【原出願日】2017-07-18
(65)【公開番号】P2022058529
(43)【公開日】2022-04-12
【審査請求日】2022-02-04
(31)【優先権主張番号】15/233,047
(32)【優先日】2016-08-10
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】518281649
【氏名又は名称】ムーンシャドウ モバイル,インコーポレイテッド
【氏名又は名称原語表記】Moonshadow Mobile,Inc.
(74)【代理人】
【識別番号】110001302
【氏名又は名称】弁理士法人北青山インターナショナル
(72)【発明者】
【氏名】ワード,ロイ,ダブリュ.
【審査官】原 秀人
(56)【参考文献】
【文献】米国特許第09171054(US,B1)
【文献】特開2009-169902(JP,A)
【文献】国際公開第2014/109109(WO,A1)
【文献】特表2003-516661(JP,A)
【文献】国際公開第2015/017361(WO,A1)
【文献】特開平08-235221(JP,A)
【文献】米国特許出願公開第2012/0117067(US,A1)
【文献】特開2014-130492(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 16/00-16/958
(57)【特許請求の範囲】
【請求項1】
コンピュータ実施方法において、
(a)データセットの第1の電子索引を、コンピュータシステムで受信するか、1またはそれ以上のコンピュータ可読記憶媒体から読み取るステップであって、前記データセットは複数のデータレコードを有し、各データレコードは複数の対応する定義済みデータフィールドについてのフィールド値文字列を含み、(i)前記定義済みデータフィールドは、末端ノードデータフィールドと第1レベルのブランチノードデータフィールドとを含み、(ii)前記第1レベルのブランチノードデータフィールドは、前記第1レベルのブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリーの関係を定義し、これらのサブレンジは前記データセットのデータレコードの複数の第1レベルのブランチノードサブセットに対応し、(iii)各第1レベルのブランチノードサブセットは、第1レベルのブランチノードデータフィールドのフィールド値文字列が対応するサブレンジ内に入るデータレコードを含むものである、ステップと、
(b)プログラムされ、1またはそれ以上の記憶媒体に機能的に結合されたコンピュータシステムの1またはそれ以上の電子プロセッサを使用して、データセットの第2の電子索引を生成するステップであって、前記第2の電子索引は、(i)インラインツリーデータ構造と、(ii)1またはそれ以上の補助データ構造とを含むものである、ステップと、
(c)コンピュータシステムの1またはそれ以上の電子プロセッサに機能的に結合された1またはそれ以上の有形の非一時的コンピュータ可読記憶媒体に、前記インラインツリーデータ構造および前記1またはそれ以上の補助データ構造を格納するステップと、を含み、
d)前記インラインツリーデータ構造は、末端ノードバイナリ文字列のみの順序付けられたシーケンスを含み、
(i)前記末端ノードバイナリ文字列と前記データセットのデータレコードとの間には一対一の対応関係があり、
(ii)前記末端ノードバイナリ文字列は互いに同じ長さを有し、
(iii)各末端ノードバイナリ文字列は、各末端ノードバイナリ文字列について、
(1)前記順序付けされたシーケンス内の前記末端ノードバイナリ文字列およびすぐ隣の末端ノードバイナリ文字列が、ともに同じ第1レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
(2)それぞれのデータレコードが互いに異なる第1レベルのブランチノードサブセットにあること、または
(3)前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、のうちの1つの条件に適合することを示すインジケータ文字列を含み、
(e)第1レベルのブランチノードサブセットごとに、対応する末端ノードバイナリ文字列が、前記インラインツリーデータ構造内で単一の連続した文字列シーケンスを形成し、
(f)前記1またはそれ以上の補助データ構造が、前記インラインツリーデータ構造内の末端ノードバイナリ文字列の順序付けられたシーケンスと同じ順序で配置、索引付け、またはアクセス可能なデータセットのデータレコードのフィールド値文字列の電子索引を含む、ことを特徴とする方法。
【請求項2】
請求項1に記載の方法において、
(a’)(i)前記定義済みデータフィールドがさらに、1またはそれ以上のレベルの上位レベルのブランチノードデータフィールドを含み、(ii)前記第1レベルおよび上位レベルのブランチノードデータフィールドは、ブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリー関係を定義し、これらのサブレンジは、前記データセットのデータレコードの、複数の第1レベルのブランチノードサブセット、および1またはそれ以上のレベルの上位レベルのブランチノードサブセットに対応しており、(iii)上位レベルのブランチノードデータフィールドの各レベルについて、各上位レベルのブランチノードサブセットは、そのレベルの前記上位レベルのブランチノードデータフィールドのフィールド値文字列が、対応するサブレンジに入るデータレコードを含み、
(d’)各末端ノードバイナリ文字列について、前記インジケータ文字列は、
(1)前記順序付けられたシーケンスにおける前記末端ノードバイナリ文字列およびすぐ隣の末端ノードバイナリ文字列が、両方とも同じ第1レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
(2)それぞれのデータレコードは、互いに異なる第1レベルのブランチノードサブセットにあるが、異なるより高いレベルのブランチノードサブセットにはないこと、
(3)それぞれのデータレコードが互いに異なる第1レベルのブランチノードサブセットにあり、それぞれのデータレコードでのブランチノードサブセットの中の最高レベルも、互いに異なる上位レベルのブランチノードサブセットにあること、または
(4)前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、のうちの1つの条件に適合することを示し、
(e’)各上位レベルのブランチノードサブセットについて、対応する末端ノードバイナリ文字列は、前記インラインツリーデータ構造内で単一の隣接する文字列シーケンスを形成することを特徴とする方法。
【請求項3】
コンピュータ実施方法において、
(A)コンピュータシステムにおいて、データセットの定義済みデータフィールドのうちの1またはそれ以上の選択された照会データフィールドのそれぞれについて、対応する照会フィールド値サブレンジに入る対応するフィールド値を含む、データセットのデータレコードに対する検索クエリを受信するステップと、
(B)自動的に、プログラムされたコンピュータプロセッサで、インラインツリーデータ構造の末端ノードバイナリ文字列の順序付けられたシーケンスを順番に問い合わせて、対応するインジケータ文字列を同定するステップと、
(C)パート(B)で問い合わせられた各末端ノードバイナリ文字列と同様に、プログラムされたコンピュータプロセッサで自動的に、1またはそれ以上の補助データ構造において、対応するデータレコードの選択された照会データフィールドのみについてフィールド値文字列を問い合わせ、パート(A)の検索クエリを満たすデータレコードを同定するステップであって、パート(C)で各データレコードについて問い合わせられるフィールド値文字列は、パート(B)で同定された対応するインジケータ文字列によって部分的に決定される、ステップと、
(D)パート(A)の検索クエリを満たさない各第1レベルのブランチノードフィールド値について、パート(C)の問い合わせから、データレコードの対応する第1レベルのブランチノードサブセットの末端ノードデータフィールドを除外するステップと、
(E)プログラムされたコンピュータプロセッサで、パート(A)で受信された検索クエリを満たすものとして、パート(C)で同定されたデータレコードのリストまたは列挙を自動的に生成するステップと、を含み、
(a)前記データセットは複数のデータレコードを有し、各データレコードは複数の対応する定義済みデータフィールドについてのフィールド値文字列を含み、(i)前記定義済みデータフィールドは、末端ノードデータフィールドと第1レベルのブランチノードデータフィールドとを含み、(ii)前記第1レベルのブランチノードデータフィールドは、前記第1レベルのブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリーの関係を定義し、これらのサブレンジは前記データセットのデータレコードの複数の第1レベルのブランチノードサブセットに対応し、(iii)各第1レベルのブランチノードサブセットは、第1レベルのブランチノードデータフィールドのフィールド値文字列が対応するサブレンジ内に入るデータレコードを含み、
(b)前記インラインツリーデータ構造は、末端ノードバイナリ文字列のみの順序付けられたシーケンスを含み、
(i)前記末端ノードバイナリ文字列と前記データセットのデータレコードとの間には一対一の対応関係があり、
(ii)前記末端ノードバイナリ文字列は互いに同じ長さを有し、
(iii)各末端ノードバイナリ文字列は、各末端ノードバイナリ文字列について、
(1)前記順序付けされたシーケンス内の前記末端ノードバイナリ文字列およびすぐ隣の末端ノードバイナリ文字列が、ともに同じ第1レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
(2)それぞれのデータレコードが互いに異なる第1レベルのブランチノードサブセットにあること、または
(3)前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、のうちの1つの条件に適合することを示すインジケータ文字列を含み、
(c)第1レベルのブランチノードサブセットごとに、対応する末端ノードバイナリ文字列が、前記インラインツリーデータ構造内で単一の連続した文字列シーケンスを形成し、
(d)前記1またはそれ以上の補助データ構造が、前記インラインツリーデータ構造内の末端ノードバイナリ文字列の順序付けられたシーケンスと同じ順序で配置、索引付け、またはアクセス可能なデータセットのデータレコードのフィールド値文字列の電子索引を含む、ことを特徴とする方法。
【請求項4】
コンピュータ実施方法において、
(A)コンピュータシステムにおいて、データセットの定義済みデータフィールドのうちの1またはそれ以上の選択された照会データフィールドのそれぞれについて、対応する照会フィールド値サブレンジに入る対応するフィールド値を含む、データセットのデータレコードに対する検索クエリを受信するステップと
(B)自動的に、プログラムされたコンピュータプロセッサで、インラインツリーデータ構造の末端ノードバイナリ文字列の順序付けられたシーケンスを順番に問い合わせて、対応するインジケータ文字列を同定するステップと、
(C)パート(B)で問い合わせられた各末端ノードバイナリ文字列と同様に、プログラムされたコンピュータプロセッサで自動的に、1またはそれ以上の補助データ構造において、対応するデータレコードの選択された照会データフィールドのみについてフィールド値文字列を問い合わせ、パート(A)の検索クエリを満たすデータレコードを同定するステップであって、パート(C)で各データレコードについて問い合わせられるフィールド値文字列は、パート(B)で同定された対応するインジケータ文字列によって部分的に決定される、ステップと、
(D)パート(A)の検索クエリを満たさない各第1レベルのブランチノードフィールド値について、パート(C)の問い合わせから、データレコードの対応する第1レベルのブランチノードサブセットの末端ノードデータフィールドを除外するステップと、
(E)パート(A)の検索クエリを満たさない各上位レベルのブランチノードフィールド値について、パート(C)の問い合わせから、データレコードの対応する上位レベルのブランチノードサブセットの第1レベルノードデータフィールドおよび末端ノードデータフィールドを除外するステップと、
(F)プログラムされたコンピュータプロセッサで、パート(A)で受信された検索クエリを満たすものとして、パート(C)で同定されたデータレコードのリストまたは列挙を自動的に生成するステップと、を含み、
(a)前記データセットは複数のデータレコードを有し、各データレコードは複数の対応する定義済みデータフィールドについてのフィールド値文字列を含み、(i)前記定義済みデータフィールドは、末端ノードデータフィールドと、第1レベルのブランチノードデータフィールドと、1またはそれ以上のレベルの上位レベルのブランチノードデータフィールドとを含み、(ii)前記第1レベルのブランチノードデータフィールドは、前記第1レベルのブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリーの関係を定義し、これらのサブレンジは前記データセットのデータレコードの複数の第1レベルのブランチノードサブセットに対応し、(iii)各第1レベルのブランチノードサブセットは、第1レベルのブランチノードデータフィールドのフィールド値文字列が対応するサブレンジ内に入るデータレコードを含み、(iv)前記第1レベルおよび上位レベルのブランチノードデータフィールドは、ブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリー関係を定義し、これらのサブレンジは、前記データセットのデータレコードの、複数の第1レベルのブランチノードサブセット、および1またはそれ以上のレベルの上位レベルのブランチノードサブセットに対応しており、(v)上位レベルのブランチノードデータフィールドの各レベルについて、各上位レベルのブランチノードサブセットは、そのレベルの前記上位レベルのブランチノードデータフィールドのフィールド値文字列が、対応するサブレンジに入るデータレコードを含み、
(b)前記インラインツリーデータ構造は、末端ノードバイナリ文字列のみの順序付けられたシーケンスを含み、
(i)前記末端ノードバイナリ文字列と前記データセットのデータレコードとの間には一対一の対応関係があり、
(ii)前記末端ノードバイナリ文字列は互いに同じ長さを有し、
(iii)各末端ノードバイナリ文字列は、各末端ノードバイナリ文字列について、
(1)前記順序付けられたシーケンスにおける前記末端ノードバイナリ文字列およびすぐ隣の末端ノードバイナリ文字列が、両方とも同じ第1レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
(2)それぞれのデータレコードは、互いに異なる第1レベルのブランチノードサブセットにあるが、異なるより高いレベルのブランチノードサブセットにはないこと、
(3)それぞれのデータレコードが互いに異なる第1レベルのブランチノードサブセットにあり、それぞれのデータレコードでのブランチノードサブセットの中の最高レベルも、互いに異なる上位レベルのブランチノードサブセットにあること、または
(4)前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、のうちの1つの条件に適合することを示すインジケータ文字列を含み、
(c)第1レベルのブランチノードサブセットごとに、対応する末端ノードバイナリ文字列が、前記インラインツリーデータ構造内で単一の連続した文字列シーケンスを形成し、各上位レベルのブランチノードサブセットごとに、対応する末端ノードバイナリ文字列は、前記インラインツリーデータ構造内で単一の隣接する文字列シーケンスを形成し、
(d)前記1またはそれ以上の補助データ構造が、前記インラインツリーデータ構造内の末端ノードバイナリ文字列の順序付けられたシーケンスと同じ順序で配置、索引付け、またはアクセス可能なデータセットのデータレコードのフィールド値文字列の電子索引を含む、ことを特徴とする方法。
【請求項5】
請求項1または3に記載の方法において、
(i)第1レベルのブランチノードデータフィールドに対応する各フィールド値文字列が、前記1またはそれ以上の補助データ構造内の少なくとも1つの第1レベルのブランチノード補助アレイに含まれ、
(ii)末端ノードデータフィールドに対応する各フィールド値文字列が、前記1またはそれ以上の補助データ構造内の少なくとも1つの末端モード補助アレイに含まれる、ことを特徴とする方法。
【請求項6】
請求項2または4に記載の方法において、
(i)上位レベルのブランチノードデータフィールドに対応する各フィールド値文字列が、前記1またはそれ以上の補助データ構造内の少なくとも1つの上位レベルのブランチノード補助アレイに含まれ、
(ii)第1レベルのブランチノードデータフィールドに対応する各フィールド値文字列が、前記1またはそれ以上の補助データ構造内の少なくとも1つの第1レベルのブランチノード補助アレイに含まれ、
(iii)末端ノードデータフィールドに対応する各フィールド値文字列が、前記1またはそれ以上の補助データ構造内の少なくとも1つの末端モード補助アレイに含まれる、ことを特徴とする方法。
【請求項7】
請求項1乃至6のいずれか1項に記載の方法において、
前記インラインツリーデータ構造の各末端ノードバイナリ文字列は、対応するインジケータ文字列のみを含み、対応するデータレコードのフィールド値をエンコードするデータ文字列を含まないことを特徴とする方法。
【請求項8】
請求項1乃至6のいずれか1項に記載の方法において、
前記インラインツリーデータ構造の各末端ノードバイナリ文字列は、対応するデータレコードの1またはそれ以上のフィールド値をエンコードするデータ文字列を含むことを特徴とする方法。
【請求項9】
請求項8に記載の方法において、
前記インラインデータツリー構造に含まれる各データ文字列が、文字列インターニングによってエンコードされた1またはそれ以上のデータフィールド値を含むことを特徴とする方法。
【請求項10】
請求項1乃至9のいずれか1項に記載の方法において、
前記補助データ構造のうちの1またはそれ以上が、文字列インターニングによってエンコードされた1またはそれ以上のデータフィールド値を含むことを特徴とする方法。
【請求項11】
請求項1乃至10のいずれか1項に記載の方法において、
前記補助データ構造のうちの1またはそれ以上が、1組の複数のクランプされたデータフィールド値をエンコードする1またはそれ以上のクランプデータフィールド値を含むことを特徴とする方法。
【請求項12】
請求項1乃至11のいずれか1項に記載の方法において、
前記インラインツリーデータ構造が、コンピュータランダムアクセスメモリまたはプロセッサキャッシュメモリに格納されていることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【0001】
[0001]優先権主張
この出願は、発明者Roy.W.Wardの名で2016年8月10日に提出された「大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造」と題する米国特許出願第15/233,047号の優先権を主張する。この特許出願は、本明細書に全体が記載されているかのように参照により本明細書に組み入れられる。
【0002】
[0002]発明の分野
本発明の分野は、電子データの格納、検索、フィルタリング、一覧表示、列挙、または回復に関する。特に、大規模データセットの高速検索またはフィルタリングのためのシステム、方法、およびデータ構造が本明細書に開示されている。
【背景技術】
【0003】
[0003]この出願は、(i)Roy W.Wardによる米国特許出願第13/326,326号(現在は米国特許第9,002,859号)、(ii)2012年1月10日にRoy W.WardとDavid S.Alaviにより出願された米国特許出願番号13/347,646号(現在、Wardに発行された米国特許第8,977,656号)、(iii)2013年1月4日にRoy W.Wardにより出願された米国特許出願第13/733,890号(現在は米国特許第9,171,054号)に開示された主題に関する。これらの出願および特許はそれぞれ、本明細書に完全に記載されているかのように参照により本明細書に組み込まれ、これらの出願および特許は以後「インラインツリー特許」と総称される。
【0004】
[0004]非常に大量のデータ(例えば、それぞれが一握り、数十、または百以上のデータフィールドを含む10、10、10、またはそれ以上のデータレコード)が生成または収集される多くの状況が存在する。データセット内のデータが実用的であるためには、データセットを表す索引(indicia)が、データセット内の情報を検索、フィルタリング、一覧表示、列挙、配置、または取得できるように構成されたデータ構造に従って格納される。デジタル以前の時代には、そのようなデータ構造は往々にして適切な媒体に印刷された英数字の索引(しばしば付随する印刷された索引を含む)を含み、データの検索および取得は人間による手作業であった。前世紀の半ばごろに電子データの保存および検索機能が導入されたことで、大規模なデータセットを保存したり、保存したデータセット内の情報を検索、フィルタリング、一覧表示、列挙、特定、または取得できるようになった。
【0005】
[0005]今日、データセットを表す英数字の索引は、通常、電子スプレッドシートまたは電子リレーショナルデータベースなどのデジタルの電子データ構造に従って格納されている。スプレッドシート(フラットファイルデータベースとも呼ばれる)は、行と列を有し、各行が特定のデータレコードに対応し、各列がそのデータレコードの特定のデータフィールドに対応する、単一のテーブルと考えることができる。簡単な例(本明細書内で繰り返し使用されるもの)では、各データレコードは、特定の州(例えばオレゴン州)の全登録有権者のデータセットにおける1人の登録有権者に対応し得る。各データレコードのデータフィールドは、例えば、姓、名、ミドルネームまたはイニシャル、年齢、性別、婚姻状態、人種、民族、宗教、他の人口統計学的情報、住所(番地、ストリート名など複数のデータフィールドに分割される場合もある)、市、州、郵便番号、所属団体、投票履歴、郡、米国の住宅地区、州議会または住宅地区、学区、その他の行政区などを含み得る。
【0006】
[0006]リレーショナルデータベースは典型的には複数のテーブルを含み、各テーブルは複数のフィールドを有する複数のレコードと、異なるテーブルの様々なフィールド間に定義された関係とを含む。上記の登録有権者の例では、「有権者」テーブルが、対応するフィールドに名前と人口統計情報を含む有権者レコードを含み、「住所」テーブルが、対応するフィールドに住所と地区情報を含む住所レコードを含むことができる。有権者テーブル内の1のフィールドに、アドレステーブル内の対応するアドレスへのポインタを含むことができ、これが各アドレスと1またはそれ以上の対応する有権者との間の一対多の関係を定義する。他のテーブルや関係も定義することができる(多対多の関係とそれらを定義するためのいわゆるピボットテーブルを含む)。
【0007】
[0007]電子スプレッドシートおよび電子リレーショナルデータベースは、デジタルデータセットを保存するための標準的な方法になっている。これらはデータ整理、データ更新、新しいデータの追加、およびデータの並べ替え、検索、フィルタリング、または取得に、ほぼ無限の柔軟性を呈する。しかしながら、非常に大規模なデータセット(例えば、10以上のレコード数、あるいは10や10以上のレコードのように少ない場合でも)について、スプレッドシートやデータベースは保存、アクセス、検索特に扱いにくくなる傾向があることが観察されている。特に、そのような大きな電子データセットからの情報の検索および取得は非常に遅くなり、特定のデータ検索アプリケーションにとって本質的に役に立たなくなることがある。
【0008】
[0008]上記で引用したインラインツリー特許は、大規模データセットの高速検索およびフィルタリングのための代替のシステムおよび方法を開示している。これらの特許に開示されているように、そして従来のスプレッドシートやリレーショナルデータベースとは対照的に、このデータセットは専用の、特別に適合された変換プログラムを使用して、従来のデータ構造から生成される特殊で高度に圧縮されたバイナリデータ構造として格納される。このバイナリデータ構造が、専用の、特別に適合された検索およびフィルタプログラムを使用して検索およびフィルタリングされる。インラインツリーデータ構造は、通常、デジタル記憶媒体の1レコード毎の1フィールド当たり約1~2バイト未満を占めるバイナリファイルに格納することができる(例えば、それぞれ100フィールドを有する100万レコードのデータセットは、約100~200MB未満に格納することができる)。スプレッドシートやリレーショナルデータベースに比べてサイズが大幅に縮小されると(多くの場合10倍以上縮小される)、データセット全体を検索やフィルタリングのためにランダムアクセスメモリにロードできるため、操作速度が大幅に向上する。インラインツリーデータ構造の小さいサイズおよび連続した配置はまた、検索およびフィルタ処理を高速化し、その結果、大規模データセット(例えば、それぞれ100を超えるデータフィールドを含む10、10、またはより多くのデータレコード)を、1プロセッサコアあたり1レコードあたり約150~500ナノ秒未満で検索およびフィルタ処理することができる。
【0009】
[0009](第2および第3のインラインツリー出願に開示されている)さらなる変形例では、いわゆるクランプヘッダテーブルを使用して、多数のデータフィールド値(任意の組み合わせで表示することができない国、市、議会地区、学区など)を共有するデータレコード群を示し、インラインデータ構造のうち、クランプされたデータフィールドの値が検索またはフィルタ条件と一致する部分のみを検索およびフィルタプログラムにかけることができる。(第3のインラインツリーアプリケーションに開示される)さらなる変形例では、追加のまたは置換データフィールド値を格納するために、補助の並列データ構造をインラインツリーデータ構造とともに使用することができる。検索およびフィルタプログラムが、インラインツリーデータ構造および補助データ構造を並行して調べるように適合させることができる。補助データ構造により、インラインツリーデータ構造全体を再生成することなく特定のデータフィールド値への変更が可能となり、インラインツリーデータ構造の様々なユーザがライセンス、購入、またはその他の目的のために特定のデータレコード収集を実現すべく自身の追加のデータフィールドを追加することを可能にする。
【0010】
[0010]上述のように、インラインツリー特許のインラインツリーデータ構造は、専用の特別に適合された変換プログラムによって生成されなければならず、専用の特別に適合された検索およびフィルタプログラムによって検索およびフィルタリングされなければならないという、非常に特殊な構造を有する。スプレッドシートやリレーショナルデータベースとは異なり、インラインツリーデータ構造は、新しいデータや更新されたデータを含めるように変更するのは面倒である。新規または置換データを既存のデータフィールドに挿入する場合、あるいはデータセットに新しいレコード全体を追加する場合は、往々にして変換プログラムを実行してまったく新しいインラインツリー構造が生成される。新しいデータフィールドをデータセットに追加するには、新しいインラインツリー構造を生成する前に変換プログラムをそれらの新しいフィールドに対応するように適合させ、検索およびフィルタプログラムを新しいインラインツリーデータ構造に対応するように適合させる必要がある。インラインツリー特許に記載のように、この柔軟性と更新可能性のロスは、インラインツリーデータ構造の小さいサイズと迅速な検索を得るために支払われる代償である。
【発明の概要】
【0011】
[0011]データセットの電子索引は、インラインツリーデータ構造と1またはそれ以上の補助データ構造とを含む。データセットには多数のデータレコードが含まれ、各データレコードは、複数の対応する定義済みデータフィールドのためのフィールド値文字列を含む。定義済みデータフィールドは、末端ノードデータフィールドおよび第1レベルのブランチノードデータフィールドを含み、さらに1またはそれ以上のレベルの上位レベルのブランチノードデータフィールドを含むことができる。ブランチノードデータフィールドは、ブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリー関係を定義し、ここでサブレンジはデータセットのデータレコードの1以上のレベルの複数ブランチノードサブセットのサブセットに対応する。
【0012】
[0012]インラインツリーデータ構造は、末端ノードのバイナリ文字列のみの順序付けられたシーケンスを含む。末端ノードのバイナリ文字列とデータセットのデータレコードの間には一対一の対応関係があり、末端ノードのバイナリ文字列は互いに同じ長さを有する。各末端ノードバイナリ文字列は標識文字列を含み、各末端ノードバイナリ文字列について、標識文字列は(i)順序付けられたシーケンス内の末端ノードバイナリ文字列およびすぐ隣の末端ノードバイナリ文字列が、ともに同じ第1レベルのブランチノードサブセット内にあるそれぞれのデータレコードに対応すること、(ii)それぞれのデータレコードが互いに異なる第1レベルのブランチノードサブセットにあること、または(iii)末端ノードバイナリ文字列が最後の末端ノードサブセットにあることを示す。いくつかの例では、最初のものを除くすべての末端ノードバイナリ文字列について、隣接する末端ノードバイナリ文字列は直前の末端ノードバイナリ文字列である。いくつかの他の例では、最後のものを除くすべての末端ノードバイナリ文字列について、隣接する末端ノードバイナリ文字列はすぐ後の末端ノードバイナリ文字列である。
【0013】
[0013]第1レベルのブランチノードサブセットごとに、対応する末端ノードバイナリ文字列が、インラインツリーデータ構造内で単一の連続した文字列シーケンスを形成する。上位レベルのブランチノードサブセット(存在する場合)ごとに、対応する末端ノードバイナリ文字列が、インラインツリーデータ構造内で単一の連続した文字列シーケンスを形成する。1またはそれ以上の補助データ構造は、インラインツリーデータ構造内の末端ノードバイナリ文字列の順序付けられたシーケンスと同じ順序で配置され、索引付けられ、またはその他の方法でアクセス可能なデータセットのデータレコードのフィールド値文字列の電子索引を含む。
【0014】
[0014]コンピュータ実施方法は、(A)データセットの第1の電子索引をコンピュータシステムで受信するか、1またはそれ以上のコンピュータ可読記憶媒体から読み取るステップと、(B)そのためにプログラムされ、1またはそれ以上の記憶媒体に動作可能に結合されたコンピュータシステムの1またはそれ以上の電子プロセッサを使用して、データセットの第2の電子索引を生成するステップであって、この第2の電子索引はインラインツリーデータ構造および1またはそれ以上の補助データ構造を含むステップと、(C)コンピュータシステムの1またはそれ以上の電子プロセッサに動作可能に結合された1またはそれ以上のコンピュータ可読記憶媒体に前記インラインツリーデータ構造および1またはそれ以上の補助データ構造を保存するステップとを含む。
【0015】
[0015]コンピュータ実施方法は、(A)データセットの定義済みデータフィールドのうちの1またはそれ以上の選択された照会データフィールドのそれぞれについて、対応する照会フィールド値のサブレンジに該当する対応するフィールド値を含む、データセットのデータレコードに対する検索クエリをコンピュータシステムで受信するステップと;(B)自動的に、そのためにプログラムされたコンピュータプロセッサを用いて、インラインツリーデータ構造の末端ノードバイナリ文字列の順序付けられたシーケンスを順番に問い合わせて、対応する標識文字列を同定するステップと;(C)そのためにプログラムされたコンピュータプロセッサで自動的に、パート(B)で問い合わせた各末端ノードバイナリ文字列と同様に、1またはそれ以上の補助データ構造における、対応するデータレコードの選択された照会データフィールドのみについてフィールド値文字列を問い合わせ、パート(A)の検索クエリを満たすデータレコードを同定するステップであって、各データレコードについてパート(C)で問い合わせられるフィールド値文字列は、パート(B)で同定された対応する標識文字列によって部分的に特定される、ステップと;(D)パート(A)の検索クエリを満たさない第1レベルのブランチノードフィールド値のぞれぞれについて、データレコードの対応する第1レベルのブランチノードサブセットのパート(C)の末端ノードデータフィールドの問い合わせから除外するステップと;(E)パート(A)の検索クエリを満たさない上位レベルのブランチノードフィールド値(存在する場合)のそれぞれについて、データレコードの対応する上位レベルのブランチノードサブセットのパート(C)の第1レベルおよび末端ノードデータフィールドの問い合わせから除外するステップと;(F)そのためにプログラムされたコンピュータプロセッサで、パート(A)で受信された検索クエリを満たすものとしてパート(C)で同定されたデータレコードのリストまたは列挙を自動的に生成するステップとを含む。
【0016】
[0016]電子的なデータ検索、フィルタリング、または取得に関する目的および利点は、図示され、以下の明細書または添付の特許請求の範囲に開示された例示的な実施形態を参照すると明らかになるであろう。この概要は、詳細な説明において以下にさらに説明される概念の選択を単純化された形で紹介するために提供される。この概要は、請求される主題の主要な特徴または本質的な特徴を識別することを意図するものではなく、特許請求される主題の範囲を決定する際の補助として使用されることも意図するものでもない。
【0017】
[0017]この概要は、詳細な説明において以下でさらに説明される概念の選択を単純化された形で紹介するために提供される。この概要は、特許請求される主題の主要な特徴または本質的な特徴を識別することを意図するものではなく、特許請求される主題の範囲を決定する際の補助として使用されることも意図するものでもない。
【図面の簡単な説明】
【0018】
図1】[0018]図1は、一般的な例のデータセットの3レベルの階層配置を概略的に示す。
図2】[0019]図2は、従来のフラットファイルデータベースの一例に配置された図1の例示的なデータセットに対応する索引(indicia)の一例を概略的に示す。
図3】[0020]図3は、従来のリレーショナルデータベースの一例に配置された図1の例示的なデータセットに対応する索引の一例を概略的に示す図である。
図4】[0021]図4は、インラインツリー特許のインラインツリーデータ構造の一例に配置された図1の例示的なデータセットに対応する索引の一例を概略的に示す図である。
図5】[0022]図5は、図1の例示的なデータセットのための本発明のストレージ構成のストリップドインラインツリーデータ構造の例を概略的に示す。
図6】[0023]図6A~6Cは、図1の例示的なデータセットのための本発明のストレージ構成の補助データ構造の例を概略的に示す図である。
図7】[0024]図7は、図5、6A、6B、および6Cの例示的な本発明の構成に従って格納されたデータセットを照会するための例示的な方法のフロー図である。
図8】[0025]図8は、図5、6B、および6Cの例示的な本発明の構成に従って格納されたデータセットを照会するための例示的な方法のフロー図であるを。
【0019】
[0026]図示された実施形態は概略的にのみ示されている。すべての特徴は完全な詳細または適切な比率で示されているとは限らず、明確さのために特定の特徴または構造が他に対して誇張されている。図示された実施形態は例にすぎず、それらは本開示または添付の特許請求の範囲を限定するものとして解釈されるべきではない。
【発明を実施するための形態】
【0020】
[0027]電子データセットの多くの例では、データは多数の英数字データレコードを含み、それらの各データレコードは複数のデータフィールドの各々に、対応する英数字のフィールド値文字列(すなわちフィールド値)を含んでいる。多くの場合、データセットは階層的なマルチレベルツリー構造に従って編成することができる。ツリー構造の最下位レベルには、データセットの個々のデータレコードに対応する、いわゆる末端ノード(ツリーに倣い、「リーフ」ノードとも呼ばれる)が含まれる。これらの末端ノードに関連付けられたデータフィールドは、末端ノードデータフィールドと呼ばれる。末端ノードから階層を上がると、第1レベルのブランチノードがあり、そして第2レベルまたはさらに高レベルのブランチノードがある。第1レベルのブランチノードに関連付けられているデータフィールドは第1レベルのブランチノードデータフィールドと呼ばれ、第2レベルのブランチノードに関連付けられているもの(第2レベルのブランチノードがある場合)は第2レベルブランチノードデータフィールドと呼ばれ、より上位レベルのブランチノード(存在する場合)も同様である。
【0021】
[0028]そのようなツリー構造の第1レベルのブランチノードの各々は、典型的に、(i)1またはそれ以上の第1レベルのブランチノードデータフィールドのそれぞれの値の単一のサブレンジと、(ii)対応するデータレコードが、対応するサブレンジ内に含まれる第1レベルのブランチノードデータフィールドについてのフィールド値を含む1またはそれ以上の末端ノードと、の間の一対多の関係を表す。これらの末端ノードに対応するデータレコードは、データレコードの第1レベルのブランチノードのサブセットを形成し、それらはすべて、対応するサブレンジ内の第1レベルのブランチノードデータフィールドに値を有する。各データレコードは、マルチレベルツリー階層の配置と一致して、1つの第1レベルのブランチノードサブセットにのみ属する。したがって、各末端ノードは、1つの第1レベルのブランチノードにのみ「属する」と言える。同様に、第2レベルのブランチノードがある場合、ツリー構造の第2レベルブランチノードはそれぞれ、典型的に、(i)1またはそれ以上の第2レベルのブランチノードデータフィールドのそれぞれにおける値の単一のサブレンジと、(ii)対応するデータレコードが、対応するサブレンジ内に含まれる第2レベルのブランチノードデータフィールドについての値を含む1またはそれ以上の末端ノードと、の間の一対多の関係を表す。これらの末端ノードに対応するデータレコードは、データレコードの第2レベルのブランチノードサブセットを形成し、それらはすべて、対応するサブレンジ内の第2レベルのブランチノードデータフィールドに値を有する。第1レベルのブランチノードサブセットの各々は、マルチレベルツリー階層の配置と一致する、1つの第2レベルのブランチノードサブセットのみのサブセットである。したがって、各第1レベルのブランチノードは、1つの第2レベルのブランチノードのみに「属する」と言える。さらなる上位レベルが階層内に存在する場合、上位レベルのブランチノードデータフィールドおよび上位レベルのブランチノードサブセットも同様に定義することができる。
【0022】
[0029]オレゴン州のすべての登録有権者のデータレコードのデータセットが、本開示の実施例として繰り返し使用されることになる。しかしながら、本明細書に開示されクレームにあるシステムおよび方法は、そのデータセットまたはその一般的な種類のデータセットに限定されず、データが本明細書に例示されるデータ構造に従って構成され得る任意のデータセットに適用することができる。オレゴン州の登録有権者のデータセットは、(第1レベルのブランチノードとしての)約1.0×10の個別の住所における(末端ノードとしての)約1.9×10人の個人有権者に関するデータレコードを含んでいる。図1は、データを3つのレベルの階層(図1においてA、B、およびCで示すレベルであって、「A」レベルのノードは第2レベルのブランチノードであり、「B」レベルのノードは第1レベルのブランチノードであり、「C」レベルのノードは末端ノードである)に編成するための一般的なツリー構造の一例を概略的に示す。投票者ごとに数十の可能なデータフィールド(すなわち、末端ノードデータフィールド)と、住所ごとに約100の可能なデータフィールド(すなわち、第1レベルおよび第2レベルのブランチノードデータフィールド)がある。オレゴン州の登録有権者データセットを含む従来のスプレッドシートまたはフラットファイルデータベースは、コンピュータのハードディスクに格納された場合に、サイズが約2GB(ギガバイト)である。
【0023】
[0030]本明細書に開示されているすべてのシステムおよび方法は3レベルの実施例に関して説明されているが、これらの開示されたシステムおよび方法は、任意の必要な、望ましい、または適切な数の2またはそれ以上のレベルを含む階層ツリー構造に従って編成されたデータに一般化できることを意図する。特定数のレベルに明確に限定しない限り、クレームは様々な数のレベルを包含するものとする。
【0024】
[0031]登録有権者の実施例についての3レベルのデータ階層の一例は、第2レベルのブランチノードとしてのストリートA[x]と、第1レベルのブランチノードとしての番地B[xy]と、末端ノードとしての有権者C[xyz]とを含み得る。この例では、データセット全体を網羅するストリートA[1]、A[2]、・・・A[x]などがある。各ストリートA[x]には、当該ストリートを取り囲む番地B[x1]、B[x2]、・・・B[xy]などがある。各番地B[xy]には、有権者C[xy1]、C[xy2]、・・・C[xyz]などがある。各データレコードは、末端ノードを指定し、その関連属性(すなわち、FC1、FC2、FC3などとラベル付けされた末端ノードデータフィールド内のフィールド値)を示す、対応するデータフィールド内の英数字フィールド値文字列を含み、また、(i)対応する末端ノードが接続されている第1レベルのブランチノード、および存在する場合は第2レベルまたはそれ以上のレベルのブランチノードを指定し、(ii)これらの上位レベルのノードに関連する属性(すなわち、FB1、FB2、FB3などとラベル付けされた第1レベルのブランチノードデータフィールド内のフィールド値;FA1、FA2、FA3などのラベル付けされた第2レベルのブランチノードデータフィールド(存在する場合)のフィールド値;および上位レベルのブランチノードデータフィールド(存在する場合)のフィールド値)を示す、対応するデータフィールド内のフィールド値文字列を含む。所与のデータレコードの特定のフィールド値は、例えば、FA2(i)、FB4(i,j)、FC7(i,j,k)などで指定される。
【0025】
[0032]図1の3レベルの階層的な例のデータでは、データフィールドFA1、FA2などは、第2レベルのブランチノードデータフィールドと呼ぶことができる。第2レベルのブランチノードA[x]の各々は、各データフィールドFAnについて、1またはそれ以上のデータレコード内のそのフィールドに現れるフィールド値文字列(等価的にはデータ値)のサブレンジを指定することによって定義できる。所与のサブレンジは、単一の文字列、またはヌル文字列(すなわち、フィールドに格納されている文字列がない)を含み得ることに留意されたい。したがって、各ノードA[x]は、データセット内のデータレコードの第2レベルのブランチノードサブセットに対応し、ここで第2レベルのブランチノードサブセットは、第2レベルのデータフィールドFAnのフィールド値が対応するサブレンジ内に入っているデータレコードのみを含む。同様に、データフィールドFB1、FB2等は、第1レベルのブランチノードデータフィールドと呼ぶことができる。各ノードB[xy]は、各フィールドFBmについて、1またはそれ以上のデータレコード内に現れるフィールド値文字列(等価にはデータ値)のサブレンジを指定することによって定義することができる(この場合も、所与のサブレンジは単一の文字列またはNULL文字列を含み得る)。したがって、各ノードB[xy]は、対応する第2レベルのサブセット内のデータレコードの第1レベルのブランチノードサブセットに対応し、ここで第1レベルのサブセットは、各第1レベルのフィールドFBmのフィールド値文字列が対応するサブレンジ内に入るこれらのデータレコードのみを含む。階層ツリー構造の性質と一貫して、各データレコードは1つの第1レベルのブランチノードサブセットのみに含まれ、各第1レベルのブランチノードサブセットは単一の第2レベルのブランチノードサブセットのみのサブセットである(すなわち、所与の第1レベルのブランチノードサブセットのすべてのデータレコードは、同じ第2レベルのブランチノードサブセットに属する)。前述の説明は、第3、第4、またはさらに上位レベルのブランチノード、データフィールド、およびデータレコードサブセットに一般化することができる。
【0026】
[0033]階層データツリーは、必要なまたは望むだけ多くのレベルを含むことができ(場合によってはツリーのブランチによって変わる)、任意の所与のレベルで必要なまたは望むだけ多くのノードを含むことができる。さらなる例では、図1の階層データ構造全体がそれ自体で、より大きなツリー構造の末端ノードを構成することができる。登録有権者の例に加えて、階層ツリーに従って有利に編成することができるデータの他の特定の実施例には:例えば州(A)、郡(B)、住宅団地(C)、人口調査ブロック(D)、およびレコード(E)で構成される人口調査データ;例えば顧客(A)、注文(B)、および支払い(C)で構成される売上データ;大陸(A)、国(B)、州または地方(C)、および市(D)で構成される地政学的データ;緯度および経度の度(A)、分(B)、および秒(C)で構成される地理空間データ。年(A)、月(B)、日(C)、時(D)、および分(E)で構成される時系列データ;および、例えば異なる地理的位置にある装置によって生成される時系列データなどの、異なる階層の組み合わせが含まれる。これらおよび他の適切な実施例は、本開示または添付の特許請求の範囲内に含まれるものとする。
【0027】
[0034]本明細書および特許請求の範囲における説明の便宜上、格納された電子索引およびそれらが表すデータは互換的に参照されることがある。データ自体は抽象概念であり、代表的な索引は電子的に格納され、取り扱われ、データ構造に配置され、検索され、取得され、またはその他に本書に開示されるか特許請求された方法およびシステムで操作されるオブジェクトであることに留意されたい。本開示における用語「データ」、「フィールド値」などの使用は、与えられた文脈において適切であれば、代表的な索引を示すと理解される。
【0028】
[0035]上述のように、図1に表されたデータを格納するために採用することができる1つの従来の電子データ構造は、データを表す電子索引が行と列に編成された電子スプレッドシート(「行」と「列」が通常の方法で定義されたフラットファイルデータベース)である。そのようなスプレッドシートのいくつかの行が図2に概略的に示されている。スプレッドシートの各行はデータセットの1つのデータレコードに対応し、したがって図1のツリーの「リーフノード」の1つに対応する(例えば、C[xyz])。スプレッドシートの列はデータフィールドに対応し、データレコードC[xyz]についてフィールド値FC1(x,y,z)、FC2(x,y,z)などを含み、ノードB[x,y](階層内の対応する第1レベルのブランチノード)についてはBF1(x,y)、BF2(x,y)などを含み、ノードA[x](階層内の対応する第2レベルのブランチノード)についてはフィールド値AF1(x)、AF2(x)などを含む。もしあれば、さらなる上位レベルのブランチノードのためにさらなるフィールドを含むことができる。与えられたデータレコードがそのフィールドにデータを有するか否かに拘わらず、すべてのデータレコードのすべての可能なデータフィールドのためにスプレッドシートにスペースが確保されていることに注意されたい。また、ブランチノードデータフィールドのデータは、対応するブランチノードに接続された末端ノードに対応する各データレコードで繰り返される。
【0029】
[0036]図1に表されるデータを格納するために採用できる別の従来の電子データ構造は、図3に概略的に示されるように、データを表す電子索引がテーブルに編成される電子リレーショナルデータベースである。「C」テーブルの各テーブルレコードは、対応する「リーフノード」C[xyz]を表し、識別子フィールド値ID-C(x,y,z)と、対応するデータフィールド値FC1(x,y,z)、FC2(x,y,z)等と、対応する第1レベルのブランチノードB[xy]の識別子フィールド値ID-B(x,y)とを含む。「B」テーブル内の各テーブルレコードは、対応する第1レベルのブランチノードB[xy]を表し、識別子フィールド値ID-B(x,y)と、対応するデータフィールド値FB1(x,y)、FB2(x,y)等と、対応する第2レベルのブランチノードA[x]の識別子フィールド値ID-A(x)とを含む。「A」テーブルの各テーブルレコードは、対応する第2レベルのブランチノードA[x]を表し、識別子フィールド値ID-A(x)と、対応するデータフィールド値FA1(x)、FA2(x)等とを含む。図3の各テーブルの図は、データベース管理の当業者には理解されるように、図示された種類および内容の複数の異なるテーブルレコードを表すと理解される。異なるテーブルの特定のフィールドを結ぶ点線は、リレーショナルデータベース構造内で確立された一対多の関係を表す(例えば、1つの第2レベルのブランチノードA[x]から1またはそれ以上の第1レベルのブランチノードB[xy]へ;1つの第1レベルのブランチノードB[xy]から1またはそれ以上の末端ノードC[xyz]へ)。図2のスプレッドシートデータ構造と同様に、あらゆるデータレコードのあらゆる可能なフィールドに対してスペースが確保されていることに留意されたい。しかしながら、図1のスプレッドシートの実施例とは異なり、複数のデータレコードに共通のデータフィールドは、すべてのリーフノードに対して繰り返し格納される必要はない。例えば、「B」テーブルと「C」テーブルのID-Bフィールド間の関係により、「B」テーブルにFBm(x,y)の各フィールド値を一度だけ格納することができる。図3の例は、一対多の関係のみを含むリレーショナルデータベース構造の比較的単純な例であり、より複雑な実施例は、いわゆる「ピボットテーブル」を必要とする、多くのテーブルや多対多の関係などがある。
【0030】
[0037]上記のように、例えばスプレッドシートやデータベースなどの従来の電子データ構造は、データレコードを追加、削除、または修正し、異なるレコードにおけるデータフィールド間の関係を確立し、そして多種多様なソート、検索、フィルタリング、またはデータセットの照会を可能にする点で大きな柔軟性を提供する。しかし、そのような柔軟性を提供するために、データセット内のレコード数が増えるに従って、一部はデータ構造を定義するのに必要なデータのために(すなわち「オーバーヘッド」)、一部は空のデータフィールド用に確保するスペースのために、データ構造が非常に大きく益々非効率的となる。速度を上げるために、リレーショナルデータベースにはしばしば検索インデックスが含まれるが、これがデータ構造全体のサイズをさらに大きくする。大きなサイズのデータ構造がその構造をソートまたは検索できる速度に与える影響の大部分は、インラインツリー特許に説明されており本書で繰り返さないが、大きなデータ構造がコンピュータまたはサーバーによって処理される方法から生じる。
【0031】
[0038]1またはそれ以上のインラインツリー特許に従って構成されたインラインツリーデータ構造の一例を図4に概略的に示す。図4のデータ構造の目的は、(i)格納されたデータ構造の全体サイズを劇的に縮小することを可能にし(他の理由の中でも、たとえ数千万、あるいは数億またはそれ以上のレコードを含んでいても全体をRAMに格納できるようにする)、(ii)データの所与のセグメントがRAMからプロセッサキャッシュまたはレジスタに検索される回数を減らす(好ましくはデータセグメントごとに1回の検索に減らす)ことである。それぞれ100フィールドの100万レコードを有するデータセットについては、従来のデータ構造の同じデータセットと比較して、約5から10分の1またはそれ以上のサイズ縮小が達成され観察されている。そのデータセットに対する単純な検索、ソート、またはフィルタ操作の場合、従来のデータ構造内の同じデータセットに対して実行される同様の操作と比較して、約5から100倍以上のスピード向上が達成され観察されている。
【0032】
[0039]図4のデータ構造は、「インラインツリー」データ構造と呼ぶことができ、図1のツリーの枝と葉が分離され順番に配置されている。スプレッドシートのような行/列の配置も、リレーショナルデータベースのような表の配置もない。図4のデータ構造は、単一の長く連続したバイナリ文字列のシーケンス(すなわち、バイナリ数字の単一行)とみなすことができる。順序付けられたシーケンス内の各バイナリ文字列は、元になるデータセットのデータフィールド内の対応する英数字文字列を、サイズを小さくした方法で表している。バイナリ文字列はまた、(i)1つのデータセグメントが処理のためにプロセッサキャッシュに取り込まれる際に、処理される次のセグメントが一緒に取り込まれ、(ii)そのセグメント内の全フィールドが、最初にプロセッサキャッシュに取り込まれた後に処理され、したがってプロセッサキャッシュに再度取り込まれる必要がなくなる、可能性を増大させる。
【0033】
[0040]インラインツリー出願に開示されているインラインツリーデータ構造の一般的な構成が、図4に概略的に示されている(ただし、これらの特許と本開示との間で用語がいくつか変えられている)。図中の各ブロックは、実質的に連続したバイナリ文字列のセットに対応し、各セットは、元となるデータレコードの1またはそれ以上のブランチノードデータフィールド値または末端ノードデータフィールド値を表す。例えば、C[xyz](すなわち、C[111]、C[112]等)とラベル付けされた末端ノードバイナリ文字列のセットは、対応する各データレコードについて(すなわち、対応する各末端ノードについて)、1またはそれ以上のデータフィールドFC1(x,y,z)、FC2(x,y,z)等の値を表すバイナリ文字列を含む。同様に、B[xy](すなわち、B[21]、B[22]等)とラベル付けされた第1レベルのブランチノードバイナリ文字列のセットは、データレコードの対応する第1レベルのブランチノードサブセットについて、1つ以上のデータフィールドFB1(x,y)、FB2(x,y)等の値を表すバイナリ文字列を含む。A[x](すなわちA[1]、A[2]等)とラベル付けされた第2レベルのブランチノードバイナリ文字列のセットは、データレコードの対応する第2レベルサブセットについて、1またはそれ以上の第2レベルのデータフィールドFA1データフィールド等に、値FA1(x)、FA2(x)等を表すバイナリ文字列を含む。
【0034】
[0041]図4の例では、バイナリ文字列のセットA[x]、B[xy]、およびC[xyz]はインラインツリーに配置することができ、これにより、データレコードの各第2レベルのブランチノードサブセットが、対応する実質的に隣接する第2レベルのブランチノードバイナリ文字列シーケンスを含むバイナリ索引によって表される。例えば、バイナリ文字列のセットA[1]、B[1y]、およびC[1yz]のすべてが一緒になって、データレコードの第1の対応する第2レベルのブランチノードサブセットを表す第1の実質的に隣接する第2レベルのブランチノードバイナリ文字列シーケンスを形成する。バイナリ文字列のセットA[2]、B[2y]、およびC[2yz]のすべてが一緒になって、データレコードの異なる第2の対応する第2レベルのブランチノードサブセットを表す第2の対応する、実質的に隣接した第2レベルのブランチノードバイナリ文字列シーケンスを形成し、これが同様に続く。各第2レベルのブランチノードバイナリ文字列のセットA[x]は、それに対応する実質的に隣接する第2レベルのブランチノードバイナリ文字列シーケンス用のヘッダとして機能し得る。
【0035】
[0042]図4の例における各第2レベルのブランチノードバイナリ文字列シーケンス内では、バイナリ文字列のセットB[xy]およびC[xyz]がインラインツリーに配置されており、したがって、データレコードの各第1レベルのブランチノードデータサブセットが、対応する実質的に隣接する第1レベルのバイナリ文字列シーケンスを含むバイナリ索引によって表される。例えば、バイナリ文字列のセットB[11]およびC[11z]のすべてが一緒になって、対応する第1レベルのサブセットデータレコードを表す、対応する実質的に隣接する第1レベルのバイナリ文字列シーケンスを形成する。バイナリ文字列のセットB[23]およびC[23z]のすべてが一緒になって、データレコードの異なる対応する第1レベルのサブセットを表す、異なる実質的に隣接する第2レベルのバイナリ文字列シーケンスを形成し、これが同様に続く。各第1レベルのブランチノードバイナリ文字列のセットB[xy]は、それに対応する実質的に隣接した第1レベルのバイナリ文字列シーケンス用のヘッダとして機能し得る。バイナリ文字列シーケンスの隣接配置の効果のいくつかが、インラインツリー特許においてさらに述べられており、ここで繰り返される必要はない。データセットのデータレコードを検索またはフィルタ処理するために、検索プログラムまたはフィルタプログラムが、インラインツリーの一部または全部をトラバースし、選択された検索条件またはフィルタ条件に対して各選択フィールドのバイナリ文字列を照会する。詳細がインラインツリー出願に開示されており、ここで繰り返す必要はない。
【0036】
[0043]図4の例では、インラインツリーは、複数のフィールドのフィールド値をエンコードするバイナリ文字列を含むことができる。いくつかの例では、すべてのフィールドのフィールド値がこのようにしてエンコードされ、他の例では、そのデータセットに対してフィルタリングできるように選択された特定のフィールドのみについて値がバイナリ文字列でエンコードされる。前述のように、大規模データセットは、各データレコードに数十から数百(またはそれ以上)のフィールドを含めることができる。いくつかの例では、例えば、所与の検索クエリまたはフィルタクエリに多数のフィールドが含まれる場合、図4の構成が、大規模データセットの高速な検索およびフィルタリングを実現するための最適な構成となり得る。しかしながら、データレコードを検索またはフィルタリングするために図4のインラインツリーを照会するステップには、インラインツリー内の各バイナリ文字列について、それが適切に解釈されるか(対応するフィールドがクエリの一部である場合)、あるいは適切にスキップされるか(対応するフィールドがクエリの一部ではない場合)のために、(それが表すフィールドに基づいて)そのバイナリ文字列のサイズを特定することが含まれる。場合によっては(例えば、所与の検索クエリまたはフィルタクエリに1つか2つか少数のフィールドしか含まれていない場合)、必要な文字列ごとのサイズ特定は、費やされる計算時間のかなりの部分を消費する。言い換えれば、クエリにほんの少しのフィールドしか含まれていない場合、検索またはフィルタプログラムは、その特定のクエリとは無関係なフィールドの値をエンコードする図4のバイナリ文字列をどのようにスキップするかを決定するためにその計算時間の多くを(おそらく大部分を)費やす傾向がある。データセット内の数十または数百のフィールドのうち、ほんの一握りのフィールドしか含まれていない検索またはフィルタクエリについて、(例えばインラインツリー特許の方法によって達成されるものを超える)さらなる速度向上を達成することが望ましい。本明細書に開示される本発明のデータ構造は、このような状況において速度向上を達成するものである。
【0037】
[0044]図5は、明細書では「ストリップドインラインツリー」と呼ぶが、請求項では「インラインツリーデータ構造」と規定される、その「ストリップ」された(取り除かれた)性質を定義するさらなる限定を有する本発明のデータ構造を概略的に示す。簡単に言うと、本発明のインラインツリーデータ構造は、(i)ブランチノードデータフィールド値の符号化も表現も含まず、ブランチノードバイナリ文字列を含まない、かつ(ii)その最も基本的な形(すなわち最も「ストリップ」された形式)では、任意の末端ノードデータフィールド値を表すかエンコードした末端ノードバイナリ文字列を含まないことから、「ストリップド」と称される。
【0038】
[0045]ストリップドインラインツリーは、階層ツリーの末端ノードを表す、すなわちデータセットのデータレコードを表す、末端ノードバイナリ文字列C[xyz]の順序付けられたシーケンスを含む。しかしながら、図4のインラインツリーとは異なり、図5のストリップドインラインツリーは、第1レベル、第2レベル、またはより高いレベルのブランチノードに対応するバイナリ文字列を含まず、ブランチノードデータフィールド値を符号化または表現しない。それにも拘わらず、末端ノードバイナリ文字列C[xyz]は、図4のインラインツリーと同じ順序で、図5のストリップドインラインツリーに配置されている。より具体的には、図5の例では、末端ノードバイナリ文字列C[xyz]がストリップドインラインツリーに配置されており、これによりデータレコードの第2レベルのブランチノードサブセットの各々が、ストリップドインラインツリー内の対応する単一の実質的に隣接する第2レベルのブランチノードバイナリ文字列シーケンスを含むバイナリ索引によって表される。例えば末端ノードバイナリ文字列C[1yz]のすべてが一緒になって、データレコードの第1の対応する第2レベルのブランチノードサブセットを表す第1の実質的に隣接した第2レベルのブランチノードバイナリ文字列シーケンスを形成し、末端ノードのバイナリ文字列C[2yz]のすべてが一緒になって、データレコードの異なる第2の対応する第2レベルのブランチノードサブセットを表す第2の対応する実質的に隣接する第2レベルのブランチノードバイナリ文字列シーケンスを形成し、これが同様に続く。図5の例における各第2レベルのブランチノードバイナリ文字列シーケンス内では、末端ノードバイナリ文字列C[xyz]がストリップインラインツリーに配置され、これにより、データレコードの各第1レベルのブランチノードサブセットが対応する実質的に隣接する第1レベルのバイナリ文字列シーケンスを含むバイナリ索引によって表される。例えば末端ノードのバイナリ文字列C[11z]のすべてが一緒になって、データレコードの対応する第1レベルのサブセットを表す、対応する実質的に隣接する第1レベルのバイナリ文字列シーケンスを形成し、末端ノードバイナリ文字列C[54z]のすべてが一緒になって、データレコードの異なる対応する第1レベルのサブセットを表す、異なる実質的に隣接した第2レベルのバイナリ文字列シーケンスを形成し、これが同様に続く。
【0039】
[0046]ブランチノードデータフィールド値を表すブランチノードバイナリ文字列を省略することは、図5の本発明のストリップインラインツリーと図4のインラインツリーとの間の1つの区別点である。もう1つの違いは、バイナリ文字列が末端ノードのデータフィールドの値をエンコードまたは表現する必要がないことである。ストリップドインラインツリーの主な目的は、データを符号化または表現することではなく、データのツリー構造にわたるガイドとして機能することである。ストリップドインラインツリーは、データセットの階層ツリー構造の「トポロジ」をエンコードするものと考えることができる(もちろん、「トポロジ」の用語は大まかに使用されている)。各所与の末端ノードバイナリ文字列C[xyz]は、(i)順序付けされたシーケンス内の、末端ノードバイナリ文字列とすぐ隣の末端ノードバイナリ文字列とが、両方とも同じ第1レベルのブランチノードサブセットにあるデータレコードにそれぞれ対応すること、(ii)それぞれのデータレコードが、互いに異なる第1レベルのブランチノードサブセットにあること、あるいは(iii)末端ノードバイナリ文字列が、インラインツリーデータ構造の最後の末端ノードのバイナリ文字列であること、のいずれかを示す索引バイナリ文字列(「センチネル」文字列と呼ばれることもある)を含む。より高いレベルのデータフィールドが存在する場合、インジケータ文字列はさらに、(ii’)それぞれのデータレコードが互いに異なる第1レベルのブランチノードサブセットにあるが異なる高いレベルのブランチノードサブセットにはないこと、あるいは(ii”)第1のレベルよりも高い、ブランチノードサブセットの中の最高レベルの、それぞれのデータレコードもまた互いに異なる上位レベルのブランチノードサブセットにあること、を示すことができる。いくつかの例では、最初のものを除くすべての末端ノードバイナリ文字列について、隣接する末端ノードバイナリ文字列は、直前の末端ノードバイナリ文字列である。他の例では、最後のものを除くすべての末端ノードバイナリ文字列について、隣接する末端ノードバイナリ文字列は、すぐ後に続く末端ノードバイナリ文字列である。前者の例(すなわち、各末端ノードバイナリ文字列が先行文字列を示す場合)では、典型的には、それが最後の文字列であることを示す末端ノードバイナリ文字列はなく、検索プログラムには、検索の終了を判断するためにデータセット内のデータレコードの総数が提供される。後者の例(すなわち、各末端ノードバイナリ文字列が次の文字列を示す場合)では、「最後の文字列」の文字列が検索の終了を判断するための指標として機能することができる。そのような例を以下に論じるが、本開示および添付の特許請求の範囲は、一方または他方へと明示的に限定されない限り、両方の場合を包含すると解釈されるべきである。
【0040】
[0047]検索プログラムまたはフィルタプログラムの一部は、ストリップドインラインツリーの末端ノードバイナリ文字列C[xyz]の順序付けられたシーケンスをトラバースするステップと、各段階で、インジケータ文字列に基づいて、現在の末端ノードバイナリ文字列によって表されたデータレコードが階層データセットのどこにあるかを特定するステップとを含む。すべての末端ノードバイナリ文字列C[xyz]は同じ長さであるため、検索プログラムまたはフィルタプログラムは、ストリップドインラインツリーの次のバイナリ文字列のサイズを特定する必要がない。末端ノードバイナリ文字列間のサイズが一定であるため、図4のインラインツリーのトラバースと比較して、図5のストリップドインラインツリーのトラバースから著しく計算負荷が取り除かれる。1つの検索クエリで多数の中からごく僅かなデータフィールドのみが照会される検索またはフィルタ操作の場合、格納されているフィールド総数と比較した照会フィールド数に応じて、計算時間の短縮は2倍または3倍、さらには10倍または20倍以上になる。
【0041】
[0048]インラインツリー特許および図4のデータ構造とは対照的に、本発明のデータ構造では、データレコードの実際のフィールド値は、1またはそれ以上(多くの場合さらに多く)の補助データ構造、通常はフラットファイル、スプレッドシート、または英数字またはバイナリのアレイ(3レベル階層は図6A~6C、または2レベル階層は図6Bと6Cのみのような)に格納またはエンコードされる。本明細書で使用される「アレイ」または「補助アレイ」という用語は、データセットのデータレコードのフィールド値を格納、表現、またはエンコードするために列挙されたものを含む任意の適切な補助データ構造を包含する。ほんの一握りのデータフィールドのみが任意の1つのクエリに含まれる場合には、各データフィールド、またはほんの少数のデータフィールドのセット用のフィールド値を、対応する別々のフラットファイルまたはアレイに格納することが有利となる。多数のそのようなアレイを使用して、多数の定義済みデータフィールドのフィールド値を格納することができる。各クエリに対し、照会フィールドに対応するそれらのアレイだけがメモリにロードされて調査されることを要する。クエリに関係のないフィールド値をスキップするために、プロセッサ時間や計算リソースは必要なく、クエリに関係のないフィールド値によってコンピュータメモリ(RAMまたはプロセッサキャッシュ)が占有されることもない。これらは両方とも、所与のデータセットの検索を提供するための大幅な速度向上または要求ハードウェアの軽減をもたらす。
【0042】
[0049]末端ノードデータフィールドのフィールド値は、1またはそれ以上の末端ノード補助アレイのセットに格納またはエンコードされ(図6C)、これは対応する末端ノードバイナリ文字列が図5のストリップドツリーに順序付けされているのと同じ順序で配列され、インデックスされ、またはその他の方法でアクセス可能である。第1レベルのブランチノードデータフィールドのフィールド値は、1またはそれ以上の第1レベルのブランチノード補助アレイのセット(図6B)に格納またはエンコードされ、これは対応する隣接する第1レベルのブランチノードバイナリ文字列シーケンスが図5のストリップドツリーに順序付けられているのと同じ順序で配列され、インデックスされ、またはアクセス可能である。第2レベル以上のブランチノードデータフィールドが存在する場合、対応するフィールド値は、1またはそれ以上の第2レベル以上のブランチノード補助アレイ(図6A)の対応するセットに格納またはエンコードされ、これは対応する隣接する第2レベルまたはそれ以上のレベルのブランチノードバイナリ文字列シーケンスが図5のストリップされたツリーにおいて順序付けられるのと同じ順序で配列され、インデックスされ、またはアクセス可能である。各アレイは、単一のデータフィールドのみ、あるいは複数のデータフィールドのセットに対して値を格納することができる。複数のデータフィールドのフィールド値が単一のアレイにまとめて格納されている場合、それらは適切な方法、望ましい方法、または必要な方法でグループ化することができる。いくつかの例では、頻繁に一緒に検索されるフィールド(例えば、緯度と経度、年齢、性別、および配偶者の有無)を同じアレイにまとめて格納することができる。いくつかの例では、やや恣意的なデータフィールドのグループ化を用いて、アレイ要素ごとの整数バイトにアレイエントリを「埋め込む」ことができる(例えば、互いに論理的に関連していてもいなくてもよい8つの1ビットフィールド値を一緒に格納して、各アレイ要素が1バイトからなるようにする)。そのような構成により、典型的に、アレイの保存、アレイのメモリ(例えば、RAMまたはプロセッサキャッシュ)へのロード、または検索時のアレイへの照会、の速度や効率が向上する。
【0043】
[0050]いずれにせよ、フィールド値を多数のアレイに分割することで、特定の検索クエリに必要なアレイのみを選択的にメモリにロードすることができる。検索クエリに応じて、大幅な速度の向上、およびハードウェア要件の削減が、選択的な読み込みと、特定の検索クエリに対してデータセット「全体」をメモリにロードするために必要なメモリ要件(RAMまたはプロセッサキャッシュ)の削減からもたらされる(すべてのデータレコードのフィールド値をロードするが、指定された検索クエリに含まれるこれらのフィールドを含む、限られたフィールドのセットのみ)。例えば、ある年齢範囲(オレゴン州の有権者の例における末端ノードのデータフィールド)で、特定の議会地区(第1レベルのブランチノードデータフィールド)で、かつ特定の政治団体に所属する(別の末端ノードデータフィールド)有権者の検索が行われたとすると、検索を実行するためにこれら3つのデータフィールドをエンコードしたアレイのみをメモリにロードすればよい。他の数十(または数百)のフィールドはロードする必要がない。
【0044】
[0051]データフィールド値は、任意の適切な、望ましい、または必要なフォーマットまたはプロトコルに従って格納またはエンコードすることができる。これらのフォーマットやプロトコルはすべてのアレイで同じでも、複数のアレイで異なっていてもよい。いくつかの例では、データフィールド値の生の英数字表現、またはASCIIといったそのエンコードをアレイに格納することができる。他の例では、文字列インデックスまたは文字列インターニングなどの標準的な技術を用いて、英数字データフィールド値を二進数インデックスとしてエンコードすることができる。典型的に、アレイに格納されている文字列インデックスとそれらが表すデータフィールド値を関連付けるために、ある種のマスター文字列テーブルが使用される。他の例では、比較的制約のある複数のデータフィールド(例えば、市、議会地区、学区など、有権者の実施例における複数の住所関連のデータフィールド、任意の組み合わせでは表示できない)からのフィールド値を、いわゆるクランプインデックスに置き換えると、格納に必要なスペースが大幅に削減される。通常、アレイに格納されたクランプインデックスを対応するフィールド値のセットに関連付けるために、ある種のクランプインデックステーブルが使用される。これら両方の技術(文字列インデックスおよびデータクランピング)は、インラインツリー特許に広く記載されており、それらの説明はここで繰り返される必要はない。
【0045】
[0052]そのためにプログラムされたコンピュータプロセッサを用いて、本発明のデータ構造に対して実行される検索またはフィルタ操作は、次のように動作する。(i)選択された照会データフィールドのセットが受信され、(ii)1またはそれ以上の検索条件のセットが受け取られ(すなわち、選択された照会データフィールドの各々について対応する照会フィールドサブレンジが選択される)、(iii)ストリップドインラインツリーの末端ノードバイナリ文字列が順番に照会され、そして並行して、選択された照会データフィールドに対応する補助データ構造の1またはそれ以上が同じ順番で照会され、(iv)1またはそれ以上の補助データ構造の照会に基づいて、検索条件を充足する、合致する、または一致するデータレコードが同定される。
【0046】
[0053]検索方法の一例を、図7のフローチャートに示す。この例では、データセットは、第2レベルおよび第1レベルのブランチノード(すなわち、それぞれAレベルとBレベルのブランチノード)と、末端ノード(すなわち、個々のデータレコードに対応するCレベルのブランチノード)とを含む3レベルのツリー構造に編成されている。図7の検索方法は、必要に応じて、任意の数の2以上のレベルを有する階層ツリーデータセットへと修正または一般化することができる(例えば、2レベルの例が図8のフローチャートに示され、図7の以下の説明も適宜図8に当てはまる)。3レベルのデータセットに図7に示す方法を実行する実施例では、検索クエリは、階層の3つすべてのレベルで選択された照会データフィールドを含むことができる。言い換えれば、最も一般的な検索クエリは、以下を特定する:(i)1またはそれ以上の選択された第2レベルの照会データフィールド(すなわち、Aレベルのデータフィールド)と、選択された第2レベルの照会データフィールドの各々に対応するフィールド値の照会サブレンジ、(ii)1またはそれ以上の選択された第1レベルの照会データフィールド(すなわち、Bレベルのデータフィールド)と、選択された第1レベルの照会データフィールドの各々に対応するフィールド値の照会サブレンジ、(iii)1またはそれ以上の選択された末端ノードの照会データフィールド(すなわち、Cレベルデータフィールド)と、選択された末端ノード照会データフィールドの各々に対応するフィールド値の照会サブレンジ。検索クエリに応答して、選択された照会データフィールドに対応する末端ノード、第1レベル、および第2レベルのアレイがメモリにロードされる。他の例示的な方法では、検索クエリは、階層のすべてのレベルで照会データフィールドを含まなくてもよい。検索クエリの例の中には、末端ノード照会データフィールドのみ、第1レベルのブランチノード照会データフィールドのみ、上位レベルのブランチノード照会データフィールドのみ、階層の2つのレベルのみの照会データフィールド等を含めることができる。
【0047】
[0054]クエリを受信すると、そのためにプログラムされたコンピュータプロセッサを使用して、インラインツリーデータ構造の末端ノードバイナリ文字列の順序付けられたシーケンスが自動的に問い合わせられ(例えば、図7のフローチャートの115、125、および135、あるいは図8のフローチャートの125、および135)対応するインジケータ文字列が特定される。この例では、インジケータ文字列は以下を示す:(i)次のデータレコードが同じ第1レベルのブランチノードサブセットにあるか(例えば、図7の115/125/135または図8の125/135の分岐「C」)、(ii)次のデータレコードが、異なる第1レベルのブランチノードサブセットにあるが、異なるより高いレベルのブランチノードサブセットにはないこと(より高いレベルのサブセットがない場合を含む。例えば、図7の115/125/135または図8の125/135の分岐「B」)、または(iii)次のデータレコードが異なるより高いレベルのブランチノードサブセットの中の最高レベル(例えば、図7の115/125/135の分岐「A」。図8には該当しない)。
【0048】
[0055]インラインツリーの問い合わせと並行して、そのためにプログラムされたコンピュータプロセッサを使用して自動的に、対応する順序で、選択された照会データフィールドのフィールド値文字列を含む1またはそれ以上の補助データ構造の中でのみ、フィールド値文字列が問い合わせられる(例えば、図7のフローチャートの110、120、または130、あるいは図8のフローチャートの120または130)。検索クエリを満たす(すなわち、満たす、合致する、または一致する)データレコードが、1またはそれ以上の補助データ構造の問い合わせによって同定され、140で検索結果に追加される(すなわち、検索クエリを満たすデータレコードのリストまたは列挙に追加される)。検索クエリに関連するデータフィールド値を含むこれらの補助データ構造のみを調べることによって、使用されるメモリ(例えば、RAMまたはプロセッサキャッシュ)または必要な検索時間を大幅に削減することができる。全部ではないにしても、それらのフィールド値のうちどれが各データレコードについて質問されるかは、部分的にはインラインツリー構造から読み取られたインジケータ文字列によって決定される。例えば、図7の135において、インラインツリーデータ構造からのインジケータ文字列により、次のデータレコードにおいてどのフィールドが質問されるかが決定される。すなわち、分岐「A」は、質問されるAレベルの照会フィールド値へとつながり、分岐「B」は、質問されるBレベルの照会フィールド値へとつながり、分岐「C」は、質問されるCレベルの照会フィールド値へとつながる。
【0049】
[0056]与えられた検索クエリが階層の所与のレベルで照会データフィールドを含まない場合、すべてのデータレコードがその階層のそのレベルで照会されたフィールドと合致するとみなされ、そして対応するフィールド値を「質問する」(interrogate)との用語には、その階層のそのレベルに照会データフィールドがないと特定することが含まれる。いくつかの例では、Aレベルの照会データフィールドを含まない検索クエリは、常に、図7の110で分岐「YES」に進む。いくつかの例では、Bレベルの照会データフィールドを含まない検索クエリは、常に、図7または図8の120で分岐「YES」に進む。いくつかの例では、Cレベルの照会データフィールドを含まない検索クエリは、常に、図7または図8の130で分岐「YES」に進む。これらの例のうちの最初の2つにおいて、所与の検索クエリに応答して対応する動的プログラムコードがオンデマンドで生成される場合、対応する決定地点115または125のうちの1またはそれ以上を生成プログラムコードから完全に省くことができる。
【0050】
[0057]必要な検索時間をさらに短縮することができる。検索クエリを満たさない各第1レベルのブランチノードフィールド値(すなわち、図7または図8の120から分岐「NO」へ)について、データレコードの対応する第1レベルのブランチノードサブセットの末端ノードデータフィールド(Cフィールド)を、問い合わせから省略することができる(図7または図8の125から分岐「C」)。検索プログラムは、異なる第1レベルのブランチノードサブセットを示すインジケータ文字列に達するまで、フィールド値を問い合わせることなく125をループする(図7または図8の125から分岐「B」へ)。検索プログラムは、120において次のBレベルの照会データフィールドを調べることによって進む。同様に、検索クエリを満たさないより高いレベルの各ブランチノードフィールド値について(すなわち、図7の110から分岐「NO」;図8には当てはまらない)、データレコードの対応する第2レベルのブランチノードサブセットの第1レベルおよび末端ノードのデータフィールド(BフィールドとCフィールド)を問い合わせから省略することができる(図7の115から分岐「B」、「C」)。検索プログラムは、インラインツリー内で異なる第2レベルのブランチノードサブセットを示すインジケータ文字列に達するまで、フィールド値を調べることなく115をループする(図7の115から分岐「A」へ)。検索プログラムは、110で次のAレベルの照会データフィールドを問い合わせることによって進む。これらの問い合わせを省略することにより、かなりの計算時間が節約される。検索クエリのいわゆるインタイムコンパイルが用いられるいくつかの例では、図7または図8のフローチャートの対応する部分は、階層の対応するレベルに照会すべく選択されたデータフィールドがない場合には完全に省略することができる。
【0051】
[0058]上述のように、インラインツリーデータ構造のインジケータ文字列は、データレコードの階層構造を通して適切にナビゲートし、データフィールド値の不要な問い合わせを減らすために、検索プログラムによって使用される(図7の115、125、および135、図8の125、および135で)。155/125/115のいずれかにおいて、「LAST」のインジケータ文字列に遭遇した場合、検索は完了である(すなわち、データセット全体が検索された)ことに留意されたい。検索プログラムは、そのためにプログラムされたコンピュータプロセッサを用いて、上記の様々な問い合わせの過程で、検索クエリを満たす、合致する、または一致するとして同定されたデータレコードのリストまたは列挙を自動的に生成する。このリストまたは列挙は、検索結果を構成する。
【0052】
[0059]検索プログラムの進行は、例えば、補助データ構造において1つのアレイ要素から次のものへ、またはインラインツリーデータ構造において1つのバイナリ文字列から次のものへと移動することによって制御することができる。代替的または付加的に、任意の適切な1またはそれ以上のカウンタ、インジケータ、インデックス、またはポインタを任意の適切な方法で使用することができ、それらは検索プログラムがインラインツリーと補助データ構造を通って処理するにつれて増加または移動される。
【0053】
[0060]検索(時にはフィルタリングとも呼ばれる)プロセスは、通常、1またはそれ以上のプロセッサを含み、様々な適切な種類の1またはそれ以上のコンピュータ可読媒体を含むかこれに機能的に結合された、1またはそれ以上のコンピュータ、コンピュータシステム、またはサーバ上で動作するコンピュータプログラムとして具現化される。検索またはフィルタリング機能を実行するコンピュータ、システム、またはサーバは、元のデータセットからインラインツリー構造や補助データ構造を生成したデータ変換プロセスを実行したものと同じである必要はなく、多くの場合は同じではない。どちらの場合も(変換と検索/フィルタ処理)、コンピュータ、サーバー、またはシステムは、スタンドアロンのコンピュータであってもよいし、ローカルエリアネットワークまたはワイドエリアネットワーク(LANまたはWAN)あるいはインターネットで接続された1台または複数台の装置であってもよい。検索またはフィルタリングに、任意の適切なハードウェアまたはハードウェアプラスソフトウェアの実装形態を採用することができる。
【0054】
[0061]元のデータセットの変換のために、そのデータフィールドが、データ構造のための適切な階層構成を決定するために調べられる。いくつかの例では、例えば元のデータセットが(図3のように)一連の一対多の関係で配置された一連のデータテーブルに配置されている場合、適切な選択が容易に明らかになるだろう。他の例では、適切な階層のためのいくつかの選択が可能であり、その1つは実行される検索の性質に基づいて選択され得る(例えば、有権者データの例における最高レベルのノードとしてストリート名を選択すると、地理的な検索またはフィルタリングができる)。例示的な販売データセットでは、顧客名を最上位ノードとしてデータセットを編成すると、顧客関連データフィールドに基づく検索やフィルタリングが容易となり、一方で商品を最高レベルのノードとしてデータセットを編成すると、製品に関するデータフィールドに基づく検索やフィルタリングが容易となる。階層が選択され定義されると、データフィールドを、任意の適切な、望ましい、または必要な保存形式または符号化方式(文字列インターニング、データクランピングなど)を使用して、1またはそれ以上の補助データ構造の間で任意の適切な、望ましいまたは必要な方法で分配することができる。インラインツリー特許のデータセットを越える本開示によるデータセット格納構成の利点は、データセットへの新しいデータレコード、または追加のデータフィールドをデータセットの既存のレコードに追加することがより簡単に追加できることである。ストリップドインラインツリーのすべてのバイナリ文字列は同じ長さであるため、新たなデータレコードの挿入位置を容易に確認することができる。同様に、新しいデータレコードのフィールド値を挿入する補助アレイ内の位置を容易に確認することができる。別の補助データ構造を追加するだけで、新たなデータフィールドを既存のデータレコードに追加することができる。
【0055】
[0062]最も「ストリップド(取り除かれた)」の形式では、インラインツリーデータ構造の各末端ノードバイナリ文字列は、インジケータ文字列のみを含む。しかし、いくつかの例では、各末端ノードバイナリ文字列は、インジケータ文字列とともに、対応するデータレコードの1またはそれ以上のデータフィールド値をエンコードするデータ文字列を含むことができる。ストリップドインラインツリーによって提供される速度上の利点を維持するために、すべてのデータレコードに対して同じデータフィールドをデータ文字列でエンコードする必要があり、対応するフィールド値は、得られたデータ文字列(末端ノードのバイナリ文字列も)が互いに同じ長さになるようにエンコードする必要がある。言い換えれば、ストリップドインラインツリーにエンコードされた追加のデータフィールド値は、文字列ごとの長さの特定や、各文字列の内容に関する決定を必要としない。ストリップドインラインツリーにエンコードされたデータフィールド値は、データセットの検索においてほとんど常に現れるデータフィールド、例えば空間的にリンクされたデータの空間座標、または時系列データの時系列インデックスにとって有利であり得る。
【0056】
[0063]検索またはフィルタリングの準備として、所与の検索クエリに関連すると判断されたストリップドインラインツリーデータ構造および1またはそれ以上の補助データ構造を、例えば、コンピュータやサーバーのRAM、プロセッサキャッシュなどのコンピュータプロセッサに直接アクセス可能な1またはそれ以上のコンピュータ可読媒体にロードすることができる。任意の適切な種類または構成のコンピュータシステムを、前述の方法のうちのいずれかを実行するように構成および接続することができる。有形媒体を含む物品は、コンピュータ可読命令をエンコードすることができ、これがコンピュータシステムに適用されると、コンピュータシステムに前述の方法のうちのいずれかを実行するように指示する。1またはそれ以上の有形のコンピュータ可読媒体を含む物品は、前述の方法のいずれかによって生成されたインラインツリーデータ構造および1またはそれ以上の補助データ構造を格納するようにエンコードすることができる。有形のコンピュータ可読媒体を含む物品は、前述の方法のうちのいずれかによって生成されたリストまたは列挙の電子索引を格納するようにエンコードすることができる。
【0057】
[0064]本明細書に開示されるシステムおよび方法は、ソフトウェアを介してプログラムされた汎用または特殊用途のコンピュータまたはサーバまたは他のプログラム可能なハードウェアデバイスとして、あるいはハードワイヤリングを介して「プログラム」されたハードウェアまたは機器、あるいはその2つの組み合わせとして実装することができる。「コンピュータ」または「サーバ」は、単一の装置であってもよいし、(単一の場所または複数の遠隔地に配置された)複数の対話型装置を含んでもよい。使用される場合、コンピュータプログラムまたは他のソフトウェアコードは、マイクロコード、マシンコード、ネットワークベースまたはウェブベースまたは一緒に動作する分散型ソフトウェアモジュール、RAM、ROM、CD-ROM、CD-R、CD-R/W、DVD-ROM、DVD±R、DVD±R/W、ハードドライブ、サムドライブ、フラッシュメモリ、光メディア、磁気メディア、半導体メディア、または任意の他の1またはそれ以上の適切な、現在存在するか将来開発される、有形の、非一時的な記憶媒体、におけるプログラミングを含むことによって、一時的または恒久的な記憶装置または可換型媒体に実装することができる。インラインツリーデータ構造または1またはそれ以上の補助データ構造を具体化する1またはそれ以上のバイナリデータファイルも、任意の1またはそれ以上の適切な現在のまたは将来開発される有形の非一時的なコンピュータ可読記憶媒体に格納することができる。
【0058】
[0065]上記に加えて、以下の実施例は本開示または添付の特許請求の範囲内に含まれる。
【0059】
[0066]例1.
データセットの電子索引を格納するようにエンコードされた1またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含む物品であって、前記電子索引は、インラインツリーデータ構造および1またはそれ以上の補助データ構造を含み、
(a)前記データセットは複数のデータレコードを有し、各データレコードは複数の対応する定義済みデータフィールドについてのフィールド値文字列を含み、
(b)前記定義済みデータフィールドは、末端ノードデータフィールドと第1レベルのブランチノードデータフィールドとを含み、前記第1レベルのブランチノードデータフィールドは、前記第1レベルのブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリーの関係を定義し、これらのサブレンジは前記データセットのデータレコードの複数の第1レベルのブランチノードサブセットに対応し、
(c)各第1レベルのブランチノードサブセットは、第1レベルのブランチノードデータフィールドのフィールド値文字列が対応するサブレンジ内に入るデータレコードを含み、
(d)前記インラインツリーデータ構造は、末端ノードバイナリ文字列のみの順序付けられたシーケンスを含み、
(1)前記末端ノードバイナリ文字列と前記データセットのデータレコードとの間には一対一の対応関係があり、
(2)前記末端ノードバイナリ文字列は互いに同じ長さを有し、
(3)各末端ノードバイナリ文字列は、各末端ノードバイナリ文字列について、
(i)前記順序付けされたシーケンス内の前記末端ノードバイナリ文字列およびすぐ隣の末端ノードバイナリ文字列が、ともに同じ第1レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
(ii)それぞれのデータレコードが互いに異なる第1レベルのブランチノードサブセットにあること、または
(iii)前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、を示すインジケータ文字列を含み、
(e)第1レベルのブランチノードサブセットごとに、対応する末端ノードバイナリ文字列が、前記インラインツリーデータ構造内で単一の連続した文字列シーケンスを形成し、
(f)前記1またはそれ以上の補助データ構造が、前記インラインツリーデータ構造内の末端ノードバイナリ文字列の順序付けられたシーケンスと同じ順序で配置、索引付け、またはアクセス可能なデータセットのデータレコードのフィールド値文字列の電子索引を含む、
ことを特徴とする物品。
【0060】
[0067]例2.
例1の物品において、各末端ノードバイナリ文字列について、前記インジケータ文字列は、
(i)前記順序付けられたシーケンス内の前記末端ノードバイナリ文字列および直後の末端ノードバイナリ文字列が、ともに同じ第1レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
(ii)それぞれのデータレコードが互いに異なる第1レベルのブランチノードサブセットにあること、または
(iii)前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、を示すことを特徴とする物品。
【0061】
[0068]例3.
例1において、各末端ノードバイナリ文字列について、前記インジケータ文字列は、
(i)前記順序付けられたシーケンス内の前記末端ノードバイナリ文字列および直前の末端ノードバイナリ文字列が、ともに同じ第1レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、または
(ii)それぞれのデータレコードは、互いに異なる第1レベルのブランチノードサブセットにあるが、異なる上位レベルのブランチノードサブセットにはないこと、を示すことを特徴とする物品。
【0062】
[0069]例4.
例1乃至3のいずれかの物品において、前記インラインツリーデータ構造の各末端ノードバイナリ文字列は、対応するインジケータ文字列のみを含み、対応するデータレコードのフィールド値をエンコードするいかなるデータ文字列も含まないことを特徴とする物品。
【0063】
[0070]例5.
例1乃至3のいずれかの物品において、前記インラインツリーデータ構造の各末端ノードバイナリ文字列は、対応するデータレコードの1またはそれ以上のフィールド値をエンコードするデータ文字列を含むことを特徴とする物品。
【0064】
[0071]例6.
例5の物品において、各データ文字列が、文字列インターニングによってエンコードされた1またはそれ以上のデータフィールド値を含むことを特徴とする物品。
【0065】
[0072]例7.
例1乃至6のいずれかの物品において、前記補助データ構造のうちの1またはそれ以上が、文字列インターニングによってエンコードされた1またはそれ以上のデータフィールド値を含むことを特徴とする物品。
【0066】
[0073]例8.
例1乃至7のいずれかの物品において、1またはそれ以上の補助データ構造が、1組の複数のクランプされたデータフィールド値をエンコードする1またはそれ以上のクランプデータフィールド値を含むことを特徴とする物品。
【0067】
[0074]例9.
例1乃至8のいずれかの物品において、前記インラインツリーデータ構造が、コンピュータランダムアクセスメモリまたはプロセッサキャッシュメモリに格納されていることを特徴とする物品。
【0068】
[0075]例10.
例1乃至9のいずれかの物品を生成するためのコンピュータ実施方法であって、
(A)データセットの第1の電子索引を、コンピュータシステムで受信するか、1またはそれ以上のコンピュータ可読記憶媒体から読み取るステップと、
(B)そのためにプログラムされ、1またはそれ以上の記憶媒体に機能的に結合されたコンピュータシステムの1またはそれ以上の電子プロセッサを使用して、データセットの第2の電子索引を生成するステップであって、前記第2の電子索引は、(1)インラインツリーデータ構造と、(2)1またはそれ以上の補助データ構造とを含む、ステップと、
(C)コンピュータシステムの1またはそれ以上の電子プロセッサに機能的に結合された1またはそれ以上の有形の非一時的コンピュータ可読記憶媒体に、前記インラインツリーデータ構造および前記1またはそれ以上の補助データ構造を格納するステップと、を含むことを特徴とする方法。
【0069】
[0076]例11.
例10の方法を実行するように構築、接続、およびプログラムされたコンピュータシステム。
【0070】
[0077]例12.
コンピュータ可読命令をエンコードする1またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含む物品であって、コンピュータシステムに適用されると、例10の方法を実行するようにコンピュータに命令することを特徴とする物品。
【0071】
[0078]例13.
例1乃至9のいずれかの物品にエンコードされたインラインツリーデータ構造および1またはそれ以上の補助データ構造を問い合わせるためのコンピュータ実施方法であって、当該方法が、
(A)コンピュータシステムにおいて、データセットの定義済みデータフィールドのうちの1またはそれ以上の選択された照会データフィールドのそれぞれについて、対応する照会フィールド値サブレンジに入る対応するフィールド値を含むデータセットのデータレコードに対する検索クエリを受け取るステップと、
(B)自動的に、そのためにプログラムされたコンピュータプロセッサで、前記インラインツリーデータ構造の末端ノードバイナリ文字列の順序付けられたシーケンスを順番に問い合わせて、対応するインジケータ文字列を同定するステップと、
(C)パート(B)で問い合わせられた各末端ノードバイナリ文字列として、自動的に、そのためにプログラムされたコンピュータプロセッサで、1またはそれ以上の補助データ構造において、対応するデータレコードの選択された照会データフィールドの中でのみフィールド値文字列を問い合わせ、パート(A)の検索クエリを満たすデータレコードを同定するステップであって、パート(C)で各データレコードについて問い合わせられるフィールド値文字列は、パート(B)で同定された対応するインジケータ文字列によって部分的に決定される、ステップと、
(D)パート(A)の検索クエリを満たさない各第1レベルのブランチノードフィールド値について、パート(C)の問い合わせから、データレコードの対応する第1レベルのブランチノードサブセットの末端ノードデータフィールドを除外するステップと、
(E)そのためにプログラムされたコンピュータプロセッサで、パート(A)で受け取られた検索クエリを満たすものとして、パート(C)で同定されたデータレコードのリストまたは列挙を自動的に生成するステップとを含むことを特徴とする方法。
【0072】
[0079]例14.
例13の方法を実行するように構築、接続、およびプログラムされたコンピューターシステム。
【0073】
[0080]例15.
コンピュータ可読命令をエンコードする1またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含む物品であって、コンピュータシステムに適用されると、例13の方法を実行するようにコンピュータに命令することを特徴とする物品。
【0074】
[0081]例16.
例1から9のいずれか1つの物品において、
(b’)前記定義済みデータフィールドがさらに、1またはそれ以上のレベルの上位レベルのブランチノードデータフィールドを含み、前記第1レベルおよび上位レベルのブランチノードデータフィールドは、ブランチノードデータフィールドのフィールド値文字列のサブレンジ間の階層ツリー関係を定義し、これらのサブレンジは、前記データせっとんデータレコードの、複数の第1レベルのブランチノードサブセット、および1またはそれ以上のレベルの上位レベルのブランチノードサブセットに対応しており、
(c’)上位レベルのブランチノードデータフィールドの各レベルについて、各上位レベルのブランチノードサブセットは、そのレベルの前記上位レベルのブランチノードデータフィールドのフィールド値文字列が、対応するサブレンジに入るデータレコードを含み、
(d’)各末端ノードバイナリ文字列について、前記インジケータ文字列は、
(i)前記順序付けられたシーケンスにおける前記末端ノードバイナリ文字列およびすぐ隣の末端ノードバイナリ文字列が、両方とも同じ第1レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
(ii)それぞれのデータレコードは、互いに異なる第1レベルのブランチノードサブセットにあるが、異なるより高いレベルのブランチノードサブセットにはないこと、
(iii)それぞれのデータレコードが互いに異なる第1レベルのブランチノードサブセットにあり、それぞれのデータレコードでのブランチノードサブセットの中の最高レベルも、互いに異なる上位レベルのブランチノードサブセットにあること、または
(iv)前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、を示し、
(e’)各上位レベルのブランチノードサブセットについて、対応する末端ノードバイナリ文字列は、前記インラインツリーデータ構造内で単一の隣接する文字列シーケンスを形成することを特徴とする物品。
【0075】
[0082]例17.
例16の物品において、各末端ノードバイナリ文字列について、前記インジケータ文字列は、
(i)順序付けられたシーケンス内の前記末端ノードバイナリ文字列および直後に続く末端ノードバイナリ文字列が、両方とも同じ第1レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
(ii)それぞれのデータレコードは互いに異なる第1レベルのブランチノードサブセットにあるが、異なるより高いレベルのブランチノードサブセットにはないこと、
(iii)それぞれのデータレコードは、互いに異なる第1レベルのブランチノードサブセットにあり、それぞれのデータレコードでのブランチノードサブセットの中の最高レベルも、互いに異なる上位レベルのブランチノードサブセットにあること、または、
(iv)前記末端ノードバイナリ文字列が、前記インラインツリーデータ構造の最後の末端ノードバイナリ文字列であること、を示すことを特徴とする物品。
【0076】
[0083]例18.
例16の物品において、各末端ノードバイナリ文字列について、前記インジケータ文字列は、
(i)前記順序付けされたシーケンスにおける末端ノードバイナリ文字列および直前の末端ノードバイナリ文字列が、両方とも同じ第1レベルのブランチノードサブセットにあるそれぞれのデータレコードに対応すること、
(ii)それぞれのデータレコードは、互いに異なる第1レベルのブランチノードサブセットにあるが、異なる上位レベルのブランチノードサブセットにはないこと、または
(iii)それぞれのデータレコードは、互いに異なる第1レベルのブランチノードサブセットにあり、それぞれのデータレコードでのブランチノードサブセットの中の最高レベルも、互いに異なる上位レベルのブランチノードサブセットにあること、を示すことを特徴とする物品。
【0077】
[0084]例19.
例16乃至18のいずれかの物品を生成するためのコンピュータ実施方法であって、
(A)データセットの第1の電子索引を、コンピュータシステムで受信するか、1またはそれ以上のコンピュータ可読記憶媒体から読み取るステップと、
(B)そのためにプログラムされ、1またはそれ以上の記憶媒体に機能的に結合されたコンピュータシステムの1またはそれ以上の電子プロセッサを使用して、前記データセットの第2の電子索引を生成するステップであって、当該第2の電子索引が、(1)インラインツリーデータ構造と、(2)1またはそれ以上の補助データ構造とを含むステップと、
(C)コンピュータシステムの1またはそれ以上の電子プロセッサに機能的に結合された1またはそれ以上の有形の非一時的コンピュータ可読記憶媒体に、前記インラインツリーデータ構造および1またはそれ以上の補助データ構造を格納するステップとを含むことを特徴とする方法。
【0078】
[0085]例20.
例19の方法を実行するように構築、接続、およびプログラムされたコンピューターシステム。
【0079】
[0086]例21.
コンピュータ可読命令をエンコードする1またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含む物品であって、コンピュータシステムに適用されると、例19の方法を実行するようにコンピュータに命令することを特徴とする物品。
【0080】
[0087]例22.
例16乃至18のいずれかの物品にエンコードされたインラインツリーデータ構造および1またはそれ以上の補助データ構造を問い合わせるためのコンピュータ実施方法であって、当該方法が、
(A)コンピュータシステムにおいて、データセットの定義済みデータフィールドのうちの1またはそれ以上の選択された照会データフィールドのそれぞれについて、対応する照会フィールド値サブレンジに入る対応するフィールド値を含むデータセットのデータレコードに対する検索クエリを受け取るステップと、
(B)自動的に、そのためにプログラムされたコンピュータプロセッサで、前記インラインツリーデータ構造の末端ノードバイナリ文字列の順序付けられたシーケンスを順番に問い合わせて、対応するインジケータ文字列を同定するステップと、
(C)パート(B)で問い合わせられた各末端ノードバイナリ文字列として、自動的に、そのためにプログラムされたコンピュータプロセッサで、1またはそれ以上の補助データ構造において、対応するデータレコードの選択された照会データフィールドの中でのみフィールド値文字列を問い合わせ、パート(A)の検索クエリを満たすデータレコードを同定するステップであって、パート(C)で各データレコードについて問い合わせられるフィールド値文字列は、パート(B)で同定された対応するインジケータ文字列によって部分的に決定される、ステップと、
(D)パート(A)の検索クエリを満たさない各第1レベルのブランチノードフィールド値について、パート(C)の問い合わせから、データレコードの対応する第1レベルのブランチノードサブセットの末端ノードデータフィールドを除外するステップと、
(E)パート(A)の検索クエリを満たさない各上位レベルのブランチノードフィールド値について、パート(C)の問い合わせから、データレコードの対応する上位レベルのブランチノードサブセットの第1レベルノードデータフィールドおよび末端ノードデータフィールドを除外するステップと、
(F)そのためにプログラムされたコンピュータプロセッサで、パート(A)で受信された検索クエリを満たすものとして、パート(C)で同定されたデータレコードのリストまたは列挙を自動的に生成するステップとを含むことを特徴とする方法。
【0081】
[0088]例23.
例22の方法を実行するように構築、接続、およびプログラムされたコンピューターシステム。
【0082】
[0089]例24.
コンピュータ可読命令をエンコードする1またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含む物品であって、コンピュータシステムに適用されると、例22の方法を実行するようにコンピュータに命令することを特徴とする物品。
【0083】
[0090]例25.
例13または22のいずれかの方法によって生成されたリストまたは列挙の電子索引を格納するようにエンコードされた1またはそれ以上の有形の非一時的コンピュータ可読記憶媒体を含むことを特徴とする物品。
【0084】
[0091]開示された例示的な実施形態および方法の均等物は、本開示または添付の特許請求の範囲の範囲内にあるものとする。開示された例示的な実施形態および方法、ならびにそれらの均等物は、本開示または添付の特許請求の範囲内に留まりながら変更され得ることが意図されている。
【0085】
[0092]上記の発明の詳細な説明では、開示を簡素化する目的で様々な特徴をいくつかの例示的実施形態にまとめられている。この開示方法は、クレームされた実施形態が、対応する請求項に明示的に列挙されたもの以上の特徴を必要とするという意図を反映していると解釈されるべきではない。むしろ、添付の特許請求の範囲が反映するように、発明の主題は、単一の開示された例示的実施形態のすべての特徴より少ない特徴にあり得る。したがって、添付の特許請求の範囲は、詳細な説明に組み込まれ、各特許請求の範囲は、別個の開示された実施形態としてそれ自体成立する。しかしながら、本開示はまた、本開示または添付の特許請求の範囲に見られる任意の適切な組の1またはそれ以上の開示またはクレームされた特徴(すなわち、不適合でも相互排他的でもない一組の特徴)であって、本明細書に明示的に開示されていない組を含む実施形態を暗黙的に開示するものとして解釈される。さらに、開示の目的のために、添付の従属請求項のそれぞれは、マルチディペンド形式で書かれ、矛盾しないすべての先行請求項に従属するように解釈されるべきである。添付の特許請求の範囲は、本明細書に開示されている主題の全部を必ずしも包含するものではないことにさらに留意されたい。
【0086】
[0093]本開示および添付の特許請求の範囲の目的のために、接続詞「または」は包括的に解釈されるべきである(例えば、「犬または猫」は「犬または猫またはその両方」として解釈されるである。例えば、「犬、猫、またはネズミ」は、「犬、または猫、またはマウス、または任意の2つ、または3つすべて」と解釈される)。ただし、(i)例えば、「・・・または・・・のどちらか」、「・・・のうちの1つ」、または類似の言葉を使用した場合、(ii)列挙された選択肢のうちの2つ以上が特定の文脈内で相互排他的である場合、「または」は、相互に排他的ではない選択肢を含む組み合わせのみを包含する。本開示および添付の特許請求の範囲について、用語「具える」、「含む」、「有する」、およびそれらの変形は、それらが現れる場合はいつでも、オープンエンド用語として解釈されるべきであり、他に明示的に述べられていない限り、各例の後に「少なくとも」という言葉が付されているのと同じ意味である。本開示または添付の特許請求の範囲の目的のために、数量に関して「およそ等しい」、「実質的に等しい」、「約~より大きい」、「約~未満」などの用語が使用される場合、異なる解釈が明示的に述べられていない限り、測定精度および有効数字に関する標準的な慣習が適用されるものとする。「実質的にない」、「実質的に存在しない」、「実質的に排除された」、「ほぼゼロに等しい」、「無視できる」などのフレーズによって記載されるヌル量については、そのようなフレーズは、それぞれ問題となる量が開示または特許請求の範囲に記載された装置または方法の意図された動作または使用の文脈における実際的な目的のために、装置または方法の全体的な振る舞いまたは性能が、実際に完全に取り除かれた、正確にゼロに等しい、またはその他の正確に無であるヌル量の場合と変わらない程度に低減または減少されたことを意味する。
【0087】
[0094]添付の特許請求の範囲において、請求項の要素、ステップ、限定、または他の部分の任意の表示(例えば、第1、第2、第3など、(a)、(b)、(c)など、または(i)、(ii)、(iii)など)は、明確にする目的のためだけであり、そのように表示された請求項部分の何らかの順序付けまたは優先順位を暗示するものとして解釈されるべきではない。そのような順序付けや優先順位が意図されている場合、それは請求項に明示的に列挙されるか、場合によっては、請求項の特定の内容に基づいて暗黙的または内在的なものとなる。添付の特許請求の範囲において、米国特許法第112条(f)の規定を装置クレームに適用する場合、「手段」という単語がその装置クレームに現れる。それらの規定が方法クレームに適用される場合、「ステップ」という単語がその方法クレームに現れる。逆に、「手段」または「ステップ」という言葉がクレームに現れない場合、その場合は、35USC§112(f)の規定は、そのクレームに対する適用を意図しない。
【0088】
[0095]1またはそれ以上の開示が参照により本明細書に組み込まれ、そのような組み込まれた開示が本開示と部分的または全体的に矛盾するか、またはそれらと範囲が異なる場合、矛盾する範囲、より広い開示、またはより広い用語の定義に限り、本開示が支配する。そのような組み込まれた開示が互いに部分的または全体的に矛盾する場合は、矛盾する範囲において、後の開示が支配する。
【0089】
[0096]要約は、特許文献の中で特定の主題を探している人々への援助として必要に応じて提供される。しかしながら、要約は、その中に列挙されているいかなる要素、特徴、または限定も、いかなる特定の請求項によっても必然的に包含されることを意味することを意図するものではない。各請求項に含まれる主題の範囲は、その請求項のみの列挙によって決定されるものとする。
図1
図2
図3
図4
図5
図6-1】
図6-2】
図7
図8