JP2002528821A - 共用ファイル環境用の改良された情報格納および検索システムを有する物理格納アーキテクチャのための方法および装置 - Google Patents

Abstract

(57)【要約】 分散型格納システムは、必ずしも互いに接続され得ない複数の物理的格納デバイスを通じてデータアイテムの格納、検索、およびデータ共有を行う装置および方法を提供する。本発明は、別個の格納デバイス上に１つ以上の「パーティション」を含み、各パーティションは、関連付けられたデータファイルのグループを含む。多様な種類のパーティションがあり得、多様なクライアントのパーティションが、統合ファイルまたは別のパーティション中に常駐するファイルに様々な時期に結合され得る。本システムは、２つ以上のクライアント間のコンフリクトを解消して、更新情報が少しでもあれば、どの更新情報をライブラリパーティション中に格納するのか判定する。本発明のこの柔軟かつ自己参照型の表は、あらゆる種類の（構造化および非構造化の両方の）データを格納し得、他のアプリケーションプログラムへのインターフェースを提供し得る。

Description

【発明の詳細な説明】

【０００１】 （発明の背景） １．発明の分野 本発明は、概して様々な種類のデータを格納し、検索し、そして配信する方法
および装置に関する。より詳細には、本発明は、共有ファイル環境用の物理格納
アーキテクチャおよびこのようなアーキテクチャを用いる方法に関する。

【０００２】 ２．技術背景 ここ３０年にわたって、情報を格納し、管理する際に、コンピュータはますま
す重要となってきている。このことによりコンピュータネットワークを介した電
子メールおよびドキュメントのようなデータの広範な共有および通信に至る。デ
ータの共有を支援するために、ユーザがサーバ上でファイルにアクセスすること
を可能にするクライアント−サーバアーキテクチャが、ますます当たり前となり
つつある。特に、複数のユーザが１つのサーバまたは複数のサーバに存在する同
じデータベースにアクセスできるようにすることが当たり前となりつつある。

【０００３】 多くの現在のデータベースアーキテクチャは、１つのデータファイルのセット
への連続的なアクセス用に設計されている。１つのファイルのセットは、クライ
アント−サーバネットワークにおけるように直接的にまたは間接的に共有され得
る。複数の物理的サイトにいるユーザが異なるクライアントコンピュータにおい
て同じデータに同時アクセスすることを必要とする場合、このアプローチではい
くつかの困難に遭遇する。

【０００４】 同時アクセスに関する問題に対する３つの共通したアプローチがある。第１の
アプローチによれば、すべてのユーザが、１つのサイト（典型的にはコンピュー
タメインフレーム）にアクセスしなければならない。第２のアプローチによれば
、各サイトは他のサイトにおいてデータの正確なコピーを有しており、すべての
データのコピーは、２段階コミットのようなアルゴリズムを用いてリアルタイム
で同期化された状態となる。第３の方法によれば、各サイトが他のサイトにおい
てデータのコピーを有し、コピーは必ずしも同じである必要はなく、コピーの同
期化はある一定間隔で行わなければならないことになっている。このことは、同
期複製として公知である。

【０００５】 現在のデータベースアーキテクチャは、すべてのデータファイルへの連続アク
セス用に設計されており、従って、メインフレームおよび２段階コミットアプロ
ーチとともにうまく機能する。しかし連続アクセスが保証されない状況の場合、
これらのアプローチに従うシステムオペレーティングは、適切に機能しない。

【０００６】 デスクトップの情報管理用に設計されたクライアント−サーバシステムおよび
ローカルエリアネットワークは、上述した最初の２つのアプローチのうち１つを
一様に用いる。これらのアプローチは、サーバにアンバランスな負荷をもたらし
、典型的にはリモートサーバ上で共有ファイルのロックを必要とする傾向がある
。このことがパフォーマンスのさらなる妨げとなる。さらに、サーバ上に存在す
るファイルは、典型的にはクライアントへの接続を必要とし、従ってこのような
接続なしでは更新は起こり得ない。最初の２つのアプローチはまた、更新がリア
ルタイムに同期化されなければならないので、更新に対して比較的遅くなりがち
である。

【０００７】 本発明は、同期複製の利点と中央データへの直接アクセスの必要性とを組合せ
た柔軟な、効率的な、および高速物理格納システムを提供することによって、従
来技術による制限を克服する。ユーザがハードドライブ、ＣＤ−ＲＯＭ、および
ＷＯＲＭドライブ等の異なる格納媒体を介して、ネットワーク上でファイルを共
有することを可能とするファイルシステムとして用いられるように設計されてい
る。

【０００８】 現在の物理格納システムは、上述したように同期化の問題以外の制限を受けて
いる。物理格納システムは、アプリケーションがこのようなデータへのアクセス
を必要とするときまで、データベースレコード等のデータアイテムを不揮発性メ
モリに格納しなければならない。このプロセスは典型的には、データアイテムの
コンテンツの「フラット化」工程、およびフラット化したコンテンツを格納媒体
に書き込む工程とを含む。格納媒体は概して固定サイズブロックに分割され、そ
の固定サイズブロックの各々が１つの位置を有する。

【０００９】 従来技術による格納システムによれば、このようなシステムの設計を容易にし
得る２つの制限がある。第１の制限は、各データアイテムが固定長であるという
ことである。第２の制限は、各データアイテムの最新のバージョンのみが格納さ
れる必要があるということである。従来技術の格納システムは、一般にこれらの
制限のうちの一方または両方により作動する。典型的な格納システムでは、デー
タアイテムを保存するに十分な大きさのメモリブロックを見つけ、次いでそのブ
ロックに書き込む。アイテムが消去されると、そのブロック内の他のアイテムが
再編成され、スペースの最大容量を解放し、他のデータアイテムが使用可能な状
態にする。新しいデータアイテム用の十分なスペースを有するブロックが存在し
ない場合にのみ、新しいブロックが生成される。

【００１０】 従来技術によるアプローチは多くの欠点を有する。従来技術によるシステムで
は、可変長のデータを容易には支援せず、前のバージョンのデータアイテムは利
用できないため、ユーザは「アンドゥ」機能を利用できない。さらに、従来技術
による方法では、追記型（ＷＯＲＭ）ディスク等の追加オンリ媒体と共に用いる
ことができない。

【００１１】 記載されるように、本発明は、より古いバージョンのデータアイテムを消去す
ることなく、比較的最小のディスクスペースを占めつつ可変長のデータアイテム
を容易に支援するシステムによって、従来技術による格納システムの制限を克服
する。

【００１２】 多くのデータベースは、ユーザが情報を格納し、且つ操作して、所望の情報を
サーチすることを可能にするように開発されてきた。情報産業の留まることのな
い成長により、より強力なデータベースに対する要求を生み出す。

【００１３】 データベースプロダクトは、長い間にわたって発展してきた。最初にデータベ
ースは、インデックスに関連付けられた簡単な「フラットファイル」を含んでい
た。データベースプログラム自身とは対照的なアプリケーションプログラムは、
これらのファイル間の関連性を管理し、ユーザは典型的には、アプリケーション
プログラムレベルでクエリを完全に実行していた。リレーショナルデータベース
システムの導入によりアプリケーションプログラムからデータベースプログラム
へと多くのタスクがシフトした。現在既存のデータベース管理システムは、２つ
の主な種類（これらはリレーショナルモデルに従い、オブジェクト指向モデルに
従う）を含む。

【００１４】 リレーショナルモデルでは、データの規格化等のデータアイテムを編成するい
くつかのルールおよびガイドラインを設定する。リレーショナルデータベース管
理システム（ＲＤＢＭＳ）は、これらのルールに従うシステムである。ＲＤＢＭ
Ｓデータベースは、各データアイテムが「リレーション」の特定のインスタンス
として独自に分類されることを必要とする。リレーションの各セットが、別々の
「テーブル」を表す。テーブルの各ロウは、特定のデータアイテムを表し、各カ
ラムはそのテーブルのすべてのデータアイテムにわたって共有される属性を表す
。

【００１５】 純粋なリレーショナルモデルは、データアイテムについていくつかの制限を設
ける。例えば、各データアイテムは、テーブルに関して記載したこれらのカラム
以外の属性を有することはできない。さらに、アイテムは、直接他のアイテムに
対応できない。その代わりに、「一次キー」（独自の識別子）を用いて、他のア
イテムを参照しなければならない。典型的に、これらの制限によりＲＤＢＭＳデ
ータベースは、サーチするために比較的膨大な時間を必要とする多くのテーブル
を含むようになる。さらに、テーブル数によって大部分のコンピュータメモリが
占められる。

【００１６】 オブジェクト指向プログラミングモデルから得られるオブジェクト指向データ
ベースモデルは、リレーショナルモデルの代替となる。リレーショナルモデルの
ように、各データアイテムは、データアイテムの属性を規定する１つのクラスに
属するように独自に分類されなければならない。オブジェクト指向モデルのキー
の特徴は以下である：１）各アイテムが正確な検索に用いられ得る独自のシステ
ム発生オブジェクト識別子番号を有する、２）異なるタイプのデータアイテムが
共に格納され得る、そして３）予め規定された機能または挙動がデータアイテム
と共に作られ、格納され得る。

【００１７】 上述した制限のほかに、リレーショナルモデルおよびオブジェクト指向モデル
の両方は、データ構造およびサーチに関して重要な制限を共有している。両方の
モデルは、規定されたフィールド構造に従って入力されるデータを必要とし、従
って全テキストデータエントリを完全には支持しない。いくつかのデータベース
は、レコードがテキストフィールドを含むことを可能にするが、このようなテキ
ストフィールドのサーチは容易でない。現在のデータベースの構造要件は、構造
を予め規定するためにプログラマーを必要とし、その次のデータエントリがその
構造に一致しなければならない。データベースに入力されるデータの構造を決定
することが難しい場合には、このことは役に立たない。

【００１８】 逆に、構造化されていないデータエントリを可能にするワードプロセッサおよ
びイメージプロセッサは、効率的なデータ検索メカニズムを提供せず、データを
検索するために別個のテキスト検索またはデータ管理ツールを必要とする。従っ
て、現在の情報管理システムは、全テキストまたはグラフィックスデータエント
リをデータベースのサーチメカニズムと統合する能力を提供しない。

【００１９】 ワードプロセッサのような他のプログラムからのデータベースの分離により、
現在のデータベースと統合することができない多くのテキストおよび他のファイ
ルを作り出す。様々なデータベース、表計算、画像、ワードプロセッシング、電
子メール、および他のタイプのファイルは、この情報のすべてを含む１つのデー
タベース内では現在アクセスすることができない。様々なプログラムは、表計算
、ワードプロセッシング、およびデータベースプログラム間に統合を提供するが
、上述したように現在のデータベースは、構造化されていないファイル内の効果
的なサーチを支援しない。

【００２０】 本発明は、増大した柔軟性、高速サーチ回数、およびより少ないメモリ要件を
有するデータベースを提供することによって、リレーショナルデータベースモデ
ルおよびオブジェクト指向データベースモデルの両方の制限を克服し、テキスト
の属性を支援する。さらに、本発明のデータベースでは、ユーザがデータエント
リを適合させなければならない構造を予め構成するためのプログラマーを必要と
しない。多くのアルゴリズムおよび技術が、これらの種類の情報を処理するアプ
リケーションによって必要とされる。本発明は、以下に記載するように１つのデ
ータベースエンジンへと統合し、これらの技術を支援する。そしてアプリケーシ
ョンからデータベースへとプログラミングをシフトさせる。本発明はまた、他の
データベース、表計算、ワードプロセッシングプログラム等の様々なタイプのア
プリケーションプログラム下で開発された既存のソースファイルの１つのデータ
ベースへの統合を提供する。さらに、本発明によりユーザは、集中データの保管
場所のセキュリティの必要性を犠牲にすることなく、それらに関連するデータの
すべてを制御することができる。

【００２１】 （発明の要旨） 本発明の分散型格納システムは、必ずしも互いに接続される必要のない複数の
物理格納デバイスを介してデータアイテムを格納し、検索し、そして共有する方
法および装置を提供する。

【００２２】 本発明の分散型格納システムは、異なる格納デバイス上に１つ以上の「パーテ
ィション」を含み、各パーティションは、データアイテムの集合を順に含む関連
付けられたデータファイルの群を含み、データファイルの各々が個々にアクセス
され得る。パーティションには様々なタイプがあり得る。ジャーナルパーティシ
ョンは、ユーザが書き込むことが可能であり、共有されたデータアイテムへのユ
ーザの更新を含む。好適な実施形態において、ジャーナルパーティションは、ク
ライアント−サーバアーキテクチャにおいてクライアントコンピュータに関連付
けられた格納デバイスに存在する。他のタイプのパーティション、ライブラリパ
ーティション、およびアーカイブパーティションは、クライアント−サーバアー
キテクチャにおいてサーバコンピュータに関連付けられた格納デバイスに存在し
得る。

【００２３】 様々なクライアントのジャーナルパーティション上のデータアイテムは、様々
な時に、新しく統合されたパーティション内に存在するデータアイテムへ結合さ
れ得る。２つ以上のクライアントが同じデータアイテムに関連するデータを更新
または変更しようとする場合、システムはクライアント間でコンフリクトを解決
し、更新があったとしても、どの更新が統合されたパーティションに格納される
べきかを判定する。結合オペレーションは、様々な時間間隔で生じ得るか、また
はイベント駆動型であり得る。他の様々な時に、統合されたパーティションは、
任意にライブラリパーティションへ結合され得、ライブラリパーティションは、
共有されたバージョンのデータアイテムを保存する。アーカイブパーティション
は、ライブラリパーティションからより古いバージョンのデータアイテムを格納
する。

【００２４】 複数のジャーナルパーティションは、同じライブラリパーティションおよびア
ーカイブパーティションを共有することができ、このことは、ジャーナルパーテ
ィション内のデータアイテムが、他のジャーナル内のデータアイテムまたは共有
されたデータアイテムに関係のないローカルバージョンのデータアイテムを有す
ることを可能にしつつ、共有されているライブラリパーティションおよびアーカ
イブパーティション内のデータアイテムを提供する手段を提供する。

【００２５】 好適な実施形態において、本発明のジャーナルパーティションは、物理メモリ
に連続して書き込まれる一連のオブジェクトを含む。ジャーナルパーティション
は、ユーザが変更されたデータを検索できるようにより古いバージョンのオブジ
ェクトを格納する。そのオブジェクトは、データベースまたはテキストファイル
内のレコードのようなデータアイテムに対応する。ジャーナルパーティション内
のオブジェクトの位置を追跡するために、テーブルが格納される。

【００２６】 本発明は、データを格納するための柔軟かつ自己指示型テーブルを使用するこ
とによって、従来技術による情報サーチおよび検索システムを改良する。本発明
のテーブルは、構造化したデータおよび構造化されていないデータの両方の任意
のタイプのデータを格納することができ、他のアプリケーションプログラム（例
えばワードプロセッサ）へのインターフェースを提供し、このようなアプリケー
ションプログラムに関するすべてのデータの１つのデータベースへの統合を可能
にする。本発明はまた、ハイパーテキストを含むほかの様々な特徴を支援する。

【００２７】 本発明のテーブルは、複数のロウおよびカラムを含む。各ロウは、オブジェク
ト識別番号（ＯＩＤ）を有し、各カラムもまたＯＩＤを有する。ロウはレコード
に対応し、カラムは属性に対応し、それによりロウとカラムとの交差する点が、
特定の属性に関連する特定のレコードについてのデータを含み得るセルを含むこ
とになる。セルはまた、他のレコードに対応し得る。サーチの機能を高め、カラ
ム間の同期化を提供するために、カラムの定義がテーブル内のロウとして入力さ
れ、カラムに対応するレコードが、カラムに関する様々な情報を含む。これによ
り自己指示型テーブルが与えられ、本明細書中で記載されるように多くの利点を
提供する。

【００２８】 本発明は、高速サーチを可能にするインデックス構造を含む。各セルからのテ
キストがキーワードインデックス内に格納され、キーワードインデックスそれ自
身がテーブル内に格納される。テキストセルは、キーワードインデックス内のエ
ントリへのポインタを含み、キーワードインデックスはセルへのポインタを含む
。この２方向の関連性により拡張されたクエリが提供される。本発明はさらに、
このような拡張されたクエリについて重要度およびフィルタを含む。

【００２９】 本発明は、インデックス付けされたサーチの機能を高めるシソーラスおよび知
識ベースを含む。シソーラスはテーブル内に格納され、ユーザがシノニムおよび
概念を検索することを可能にし、また検索されたレコードの関連性をランク付け
する重み付けメカニズムを提供する。

【００３０】 アプリケーション支援レイヤーは、ワードプロセッサ、パスワードシステム、
ハイパーテキスト、および他の機能を含む。本発明の新規なワードプロセッサは
、セルがワードプロセッサを用いて編集可能となるように、本発明のテーブルと
統合される。さらに、テーブルは外部ドキュメントとインターフェースをとるこ
とができ、これによりユーザは、本発明の機能強化した検索システムに従って外
部ドキュメントからデータを検索できる。

【００３１】 本発明のこれらおよび他の特徴ならびに利点は、次に続く詳細な説明および添
付の図面からさらに明らかとなる。図面および説明において、数字は本発明の様
々な特徴を示す。図面および説明の双方にわたって同様の数字は同様の特徴を指
す。

【００３２】 （表記法および専門用語） 以下の詳細な説明は、主としてコンピュータメモリ内のデータビット上の動作
のアルゴリズムおよび記号表現に関して示される。これらの説明および表現は、
データ処理分野の当業者によって用いられる手段であって、これにより彼らの仕
事の実質を他の当業者に最も効率的に伝える。

【００３３】 ここでアルゴリズムは概して、所望の結果を導く首尾一貫した連続工程である
と考えられる。これらの工程は、物理量の物理的操作を必要とする。通常、必ず
しも必要ではないが、これらの物理量は、格納、転送、結合、比較、その他操作
可能な電気的信号または磁気的信号の形になる。これらの信号をビット、値、要
素、記号、文字、ターム、数字等と呼ぶことは、主に共通の用法であるため時に
都合がよいと分かる。しかし、これらすべておよび同様の用語は、適切な物理量
に関連付けられ、これらの物理量に付けられた単なる便利なラベルにすぎないこ
とを心に留めておくべきである。

【００３４】 さらに、行われる操作は、通常人間のオペレータが行う精神的操作（ｍｅｎｔ
ａｌ ｏｐｅｒａｔｉｏｎ）に関連付けられた例えば追加または比較を明確に指
す場合がある。人間のオペレータのこのような能力は必ずしも必要ではなく、ま
たは多くの場合にはこのことが好ましくもあり、本明細書中に記載される本発明
の一部をなす動作のいずれにおいても、その動作は機械操作である。本発明の動
作を行う有効な機械には、多目的デジタルコンピュータまたは他の同様のデジタ
ルデバイスがある。すべての場合において、コンピュータを動作させる際の動作
方法と計算そのものを行う方法との間の違いを心に留めておくべきである。本発
明は、電気的信号または他の（例えば機械的、化学的）物理的信号を処理して、
他の所望の物理的信号を生成する際のコンピュータを動作する方法の工程に関す
る。

【００３５】 本発明はまた、これらの動作を行う装置に関する。この装置は、特に必要とさ
れる目的に対して構成され得るか、またはコンピュータに格納されたコンピュー
タプログラムによって、選択的に起動または再構成するような多目的コンピュー
タを含み得る。本明細書中で示されるアルゴリズムは、本来特定のコンピュータ
または他の装置には関連しない。特に、様々な多目的機械は、本明細書中の教示
内容に従って書かれたプログラムとともに用いられ得るか、または必要な方法工
程を行うためにより特化された装置を構成することがより都合がよいと分かり得
る。これらの様々な機械に関して必要な構造は、以下の説明より明らかとなる。

【００３６】 本明細書中で参照されるデータアイテムは、ユーザがアクセスを望み得る個別
のデータ要素に対応する。例えば、データアイテムは、データベースの特定のレ
コードまたはデータベースのレコード内の特定のフィールドを含み得る。データ
アイテムは、ワードプロセッシングファイルまたは任意の他のタイプのファイル
を含み得る。本明細書中で参照されるデータオブジェクトは、データアイテムの
バージョンを格納する。同じデータアイテムの異なるバージョンが、異なるデー
タオブジェクトに格納され得る。例えば、テキストファイルの元のバージョンお
よび更新されたバージョンが、２つの異なるデータオブジェクトに格納され、こ
れら２つの異なるデータオブジェクトの各々が、同じデータアイテム、すなわち
実際のテキストファイルに対応する。

【００３７】 ドメインは、特定のデータアイテムのタイプについて記載し、「Ｍｅｔｈｏｄ
ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｉｍｐｒｏｖｅｄ Ｉｎｆｏｒｍａｔ
ｉｏｎ Ｓｔｏｒａｇｅ ａｎｄ Ｒｅｔｒｉｅｖａｌ Ｓｙｓｔｅｍ」と称さ
れる１９９５年２月３日に出願された第０８／３８３，７５２号の同時係属出願
において、用語法とともに一貫して用いられる。従って、例えば特定のデータア
イテムは、テキスト、数字またはブーリアンドメイン、あるいはユーザ定義のド
メインであり得る。

【００３８】 （発明の詳細な説明） 本発明は、データを格納、操作、および検索する方法および装置を開示する。
本発明は、特定のブロック図およびテーブルエントリ等を参照して記載されるが
、当業者であれば、本明細書のより徹底的な理解を提供するために、このような
詳細が簡単に開示されていることを理解する。従って、当業者にとって本発明は
、これらの特定の詳細を用いることなく実行可能であることが明らかである。

【００３９】 さらに、「分かる（ｋｎｏｗ）」、「確認する（ｖｅｒｉｆｙ）」、「格納す
る（ｓｔｏｒｅ）」、「見つける（ｆｉｎｄ）」、「置き換える（ｒｅｐｌａｃ
ｅ）」、「調べる（ｅｘａｍｉｎｅ）」、「判定する（ｄｅｔｅｒｍｉｎｅ）」
等の特定の用語が本明細書中で使用され得、これらは当該分野の用語であるとみ
なされる。一時的な読者にとってコンピュータまたは電子システムの擬人化と思
われ得るこれらの用語の使用は、簡単にするために人間のような属性を有するよ
うなシステムの機能を指す。例えば、本明細書中で何かを「判定する」電子シス
テムまたはコンピュータプログラムを参照することは、電子システムがプログラ
ムされるかまたはそうでない場合には本明細書の教示内容に従って改変されると
いうことを記述する単なる簡略化した（ｓｈｏｒｔｈａｎｄ）方法である。読者
は、日常の人間の属性について記述される機能を混同しないように注意を受ける
。これらの機能は、すべての意味において機械の機能である。

【００４０】 （ローカルシステムハードウェア） 図１を参照して、本発明のハードウェアコンフィギュレーションを概念的に示
す。図１は、本発明の教示内容に従って構成された情報格納および検索システム
を示す。示されるように、情報格納および検索システムは、４つの主なコンポー
ネントを備えるコンピュータ２３を含む。これらのコンポーネントのうち第１は
、入力／出力（Ｉ／Ｏ）回路２２であり、この入力／出力（Ｉ／Ｏ）回路２２を
用いてコンピュータ２３の他の部分へおよび他の部分から情報を適切に構造化さ
れた形式で通信する。さらに、コンピュータ２３は、Ｉ／Ｏ回路２２およびメモ
リ２６に接続された中央演算処理装置（ＣＰＵ）２４を含む。これらの要素は、
典型的にたいていのコンピュータ内で見つけられ、実際コンピュータ２３はデー
タ処理デバイスの広いカテゴリを表すように意図されている。

【００４１】 また図１にはＩ／Ｏ回路２２を介してコンピュータ２３へデータおよびコマン
ドを入力する周知のキーボード３０が示されている。同様に、図１に示されるシ
ステムにさらなるプログラミング能力を設けるように、ＣＤ ＲＯＭ３４がＩ／
Ｏ回路２２に接続される。磁気テープドライブ、バッファメモリデバイス等のデ
ータ格納をするためのさらなるデバイスがコンピュータ２３に接続され得ること
が理解される。デバイスコントロール３６は、メモリ２６およびＩ／Ｏ回路２２
の両方に接続され、コンピュータ２３がマルチメディアシステムリソースと通信
することを可能にする。デバイスコントロール３６は、マルチメディアリソース
の動作を制御して、マルチメディアリソースとコンピュータ２３とのインターフ
ェースをとる。

【００４２】 ディスプレイモニタ４３は、Ｉ／Ｏ回路２２を介してコンピュータ２０に接続
される。カーソルコントロールデバイス４５は、本発明の教示内容に従ってＣＰ
Ｕ２４のための信号によるスイッチ４７および４９を含む。カーソルコントロー
ルデバイス４５（通常「マウス」と呼ばれる）は、ユーザが様々なコマンドモー
ドを選択し、グラフィックデータを改変し、スイッチ４７および４９を用いて他
のデータを入力することを可能にする。より詳細には、カーソルコントロールデ
バイス４５は、ユーザがディスプレイ４３の表示画面３７上の任意の所望の位置
にカーソル３９を選択的に位置付けることを可能にする。カーソルコントロール
デバイス４５およびキーボード３０は、本発明の教示内容に従って利用され得る
様々な入力デバイスの例であることが理解される。他の入力デバイス（例えば、
トラックボール、タッチスクリーン、データグローブ、または他の仮想現実デバ
イスを含む）もまた、本明細書中で開示されるように本発明とともに用いられ得
る。

【００４３】 （システム構造） 本発明は２つのメインコンポーネントを含む。第１のコンポーネントは、二人
以上のユーザが共通のファイルへのアクセスを可能にする分散型ファイルアーキ
テクチャである。第２のコンポーネントは、可変長のデータアイテムを支援し、
前のバージョンのデータアイテムを維持するローカルコンピュータ２３内の物理
格納システムである。本明細書では次にこれらのコンポーネントについて述べる
。

【００４４】 （分散型アーキテクチャ） 図２は本発明の物理格納アーキテクチャの概観を示す。示されるように、一般
にクライアントとして公知のコンピュータ２３は、一般にサーバとして公知のリ
モートコンピュータ５６と通信する。リモートコンピュータ５６は、コンピュー
タ２３および他のコンピュータがアクセス可能なデータベースファイルおよび他
のファイルを含む。

【００４５】 注意：物理的位置間のデータアイテムの伝送は、ＴＣＰ／ＩＰ、Ｎｏｖｅｌｌ
ＩＰＸ、およびＮｅｔＢＥＵＩ等を含む（ただしこれらに限定されないが）任
意のネットワーク通信システムを介して生じ得る。データアイテムの伝送に使用
されるパッケージングプロトコルは、ＦＴＰのようなファイル転送プロトコル、
ＺＭＯＤＥＭのようなモデム転送プロトコル、ＳＭＴＰのようなＥメールプロト
コル、ハイパーテキストトランスポートプロトコル等を含む（ただしこれらに限
定されないが）データを伝送する任意の標準方式であり得る。

【００４６】 （物理格納システムの設計） 二人のユーザがサーバ５６に存在する同じファイルを同時に更新しようとする
場合に、困難が生じる。

【００４７】 同時アクセスに典型的に関連する困難を避けるために、本発明は、物理格納シ
ステムをパーティションに分ける。この場合物理的デバイスの各々が少なくとも
１つのパーティションを含む。各パーティションは、１つ以上の関連付けされた
データファイルを含む。図２に示されるように、クライアントコンピュータ２３
は、ディスク３２に格納されるジャーナルパーティション５８を含み、一方サー
バ５６はサーバ５６内の同じまたは異なる格納デバイスに存在するライブラリパ
ーティション６０およびアーカイブパーティション６２を含む。

【００４８】 容易に理解されるように、図２は、本発明の教示内容に従って構造化された１
つのタイプのアーキテクチャを示す。例えば、他の可能な組合せには以下が挙げ
られるが、これらに限定されない：ａ）ライブラリパーティション６０がＣＤ−
ＲＯＭに存在し、ジャーナルパーティションがクライアントコンピュータ２３に
存在し得る、ｂ）３つのパーティション全てがクライアントコンピュータ２３に
存在し得る、ｃ）ジャーナルパーティションがネットワークサーバ上にあり、１
つのライブラリパーティションが１つの同じサーバにあり、そして第２のライブ
ラリパーティションがインターネットを介してリモート的に接続される。

【００４９】 リンクされたパーティションの特定のリストを「パーティションチェイン」と
呼び、図２においてパーティション５８、６０、および６２で示される。特定の
チェインは、任意の数（１つを含む）のパーティションを含むことができる。好
適な実施形態において、ユーザに最も近いパーティション５８を「更新パーティ
ション」と呼び、それはジャーナルパーティションでなければなく、直接更新さ
れ得るチェイン内のパーティションだけである。他のパーティション６０および
６２は、「リモートパーティション」であり、直接読み出すことはできるが、直
接書き込むことができないリードオンリパーティションである。

【００５０】 パーティションは、パーティションの機能による様々なタイプに従って分類さ
れ得る。パーティション５８のようなジャーナルパーティションは、以下により
十分に記載するように少なくとも１つの追加オンリジャーナルファイルを含む。
パーティション６０のようなライブラリパーティションは、「パック化」された
バージョンのジャーナルパーティションを格納し、各データアイテムの１つのバ
ージョンのみを含む。パーティション６２のようなアーカイブパーティションは
、複数の履歴バージョンのデータを格納する。他のタイプのパーティションが可
能である。概して、ジャーナルパーティション、ライブラリパーティション、ア
ーカイブパーティションは、図２に示されるように共にリンクされる。

【００５１】 データベースおよびワードプロセッシングファイル等のファイルへの更新は、
ライブラリパーティション６０へ直接書き込まれない。その代わり、更新は、ジ
ャーナルパーティション５８に直ちに格納され、次いでサーバ５６に提供され、
後でライブラリパーティション６０に結合される。

【００５２】 図３は、ジャーナルパーティション５８、ライブラリパーティション６０、お
よびアーカイブパーティション６２間のリンケージを示す。ジャーナルパーティ
ション５８内に存在するジャーナルファイル７０は、様々なデータオブジェクト
（例えば、データベースレコード）を含み、そのファイルはまた、未使用メモリ
を含み得る。後に、ジャーナルファイル７０はパックされ、新しい統合ファイル
７０に統合される。その統合ファイル７０は、現在空のジャーナルファイルとラ
イブラリファイルとの間のパーティションチェイン内に挿入され得る。統合され
たジャーナルファイルは任意にパックされ得、次いでライブラリパーティション
６０内に格納されるライブラリファイル７２に格納され得る。次いで、サーバ５
２は、ライブラリファイル７２をアーカイブパーティション６２内に格納される
アーカイブファイル７４に書き込むことができる。アーカイブファイル７４は、
複数のバージョンの同じデータオブジェクトを含む。

【００５３】 （追加可能データアイテム） 多くのアプリケーションにおいて、ライブラリは、オブジェクトに対する１０
，０００のポインタのリストまたは大きなテキスト文書を格納するアイテムのよ
うな大きなデータアイテムを備え得る。これらの場合、データアイテムの値を更
新することで、データの不必要な複製が生じる。

【００５４】 本発明の物理的格納システムは、「追加可能な」データアイテムを支援し、こ
のアイテムは、複数のパーティションにわたってそれらの内容の格納を分散させ
る。追加可能データアイテムは、オリジナルデータへの変更を追跡し、かつオリ
ジナルデータへの変更のみをジャーナル中に格納する。

【００５５】 追加可能データアイテムの内部構造は、２つの部分（オリジナルデータが格納
される「リモート」セクション、および変更が保持される「ローカル」セクショ
ン）を備える。図４Ａおよび４Ｂは、それぞれリストおよびテキストデータ用の
２つの追加可能なアイテムの実施を示す。図４Ａは、リストデータアイテムを示
し、このアイテムは、リモートパーティションに格納されたオリジナルリスト、
追加物、およびローカルパーティションに格納されたリストからの除去物を含む
。このオリジナルリストはリードオンリーリストであり、そして任意の更新は更
新リストに書き込まれなければならない。変更は識別ナンバーとして格納されて
オリジナルリストに追加され得、そして識別ナンバーとして格納されてオリジナ
ルリストから除去され得る。

【００５６】 同様に、図４Ｂは、追加可能リスト８２として格納されるテキストデータアイ
テムを図示する。このアイテムは、リモートパーティションに格納されたオリジ
ナルテキスト、追加物、およびローカルパーティションに格納されたテキストか
らの削除物を含む。このオリジナルテキストはリードオンリーテキストであるよ
うに格納され、そして任意の更新はローカルパーティションに書き込まれなけれ
ばならない。変更は挿入、削除およびフォーマット動作のような一連の編集動作
として格納され得る。

【００５７】 追加可能データアイテムの使用は、有利である。これらのアイテムは、更新に
必要とされる格納が最小化されることを可能にし、これは、オリジナル情報がロ
ーカルパーティションに格納される必要がないからである。さらに、これらのア
イテムは、同期の問題を低減し、これは、ローカルパーティションがオリジナル
データ自身ではなく、オリジナルデータへの変更のみを格納するからである。最
終的に、追加可能データアイテムの使用は、ＣＤ−ＲＯＭおよび一方向電子出版
サービスのようなリードオンリー媒体が注記されることを可能にする。

【００５８】 （共有データアイテム対個人データアイテム） 複数のパーティションのチェインは、同一ライブラリおよびアーカイブパーテ
ィションのいくつかまたはすべてを共有することができる。これにより、ライブ
ラリおよびアーカイブパーティション中のデータアイテムを共有したままで提供
するための手段を提供し、一方でジャーナルパーティションのデータアイテムが
ローカルバージョンを有することを可能にする手段を提供し、これは、他のジャ
ーナルのデータアイテムまたは共有されたデータアイテムから独立している。

【００５９】 統合（ｃｏｎｓｏｌｉｄａｔｉｏｎ）の間、種々のジャーナルファイルが、統
合から特定のデータアイテムを除外することにより、種々の程度にまで統合され
得る。さらに、統合ファイルはそれ自身で、以前のライブラリパーティションへ
結合されることなく、新たなパーティションとして作用し得る。

【００６０】 このようにして、データアイテムの「レイヤー」が構築され得、各レイヤーは
先のレイヤーの部分の外部をマスキングする。

【００６１】 例えば、以下の状況を想定する：ユーザＸのためのパーティションチェインは
、ジャーナルファイル中のデータアイテムＡ１を含む；ユーザＹのためのパーテ
ィションチェインは、ジャーナルファイル中のデータアイテムＢ１を含む、そし
て両方のチェインは、データアイテムＣ１を有するライブラリパーティション、
およびデータアイテムＡ１の古いほうのバージョン（Ａ２と呼ぶ）を含む。

【００６２】 この状況において、ユーザＸは、データアイテムＡ１およびＣ１を確認するが
、Ｂ１はユーザＸから確認できない。ユーザＹは、データアイテムＢ１およびＣ
１を確認し、そしてＡ１の古いほうのバージョンＡ２（これは、パーティション
Ｃに残る）を確認する。

【００６３】 このように、レイヤーを提供する格納システムを使用することで、この格納シ
ステムのユーザは特定のデータアイテムの個人のバージョンを維持し得るが、他
のデータアイテムを共有するという利点をなお有する。さらに、種々のレイヤー
は、種々の目的に役立つことができ、例えば４つのレイヤーシステムが存在し得
、これらは以下に規定するレイヤーである：第１レイヤーは、一人のユーザのた
めに専用化され得る。次のレイヤーは、作業グループ用の共有情報を含み得る。
引き続くレイヤーは、社内情報システム用の共有情報を含み得る。最後のレイヤ
ーは、公的共有情報を含み得る。

【００６４】 （新規レイヤーの挿入） 本発明は、ユーザが、レイヤー法を使用することにより、互いにデータアイテ
ムのサブセットを交換する有利な能力を提供する。

【００６５】 ユーザＸは、ユーザＸのデータのサブセットに基づいた新規パーティション（
Ａという）を作成し得、そしてそれを別のユーザＹに転送し、これは上記のよう
な任意の標準的なデータ転送システムを使用する。次いで、ユーザＹは、パーテ
ィションＡをユーザＹのパーティションチェインに挿入し得、その結果、特定の
データアイテムが「高い」レイヤーによってマスクされない限り、パーティショ
ンＡ中のすべてのデータアイテムは、直ちにかつ明白にユーザＹのデータセット
の一部であるように見える。

【００６６】 この能力は、以下のような要求に有利に適用され得る：集中したシステムを共
有していないユーザを同期させること、ＣＤ−ＲＯＭのようなリードオンリー出
版媒体に更新および注釈を送信すること、別個のソースから情報を収集し、統合
すること。

【００６７】 （結合） 先に記載されたように、このシステムは、クロック間隔または事象の発生に従
って、ライブラリパーティション６０に対してジャーナルパーティション５８の
統合された内容を提供する。システムのユーザは、例えば、ジャーナルパーティ
ション５８が特定の量のデータを含む場合、または特定の量のトランザクション
が一番最近の結合操作以来に起こる場合、このような結合操作を引き起こすこれ
らの状況を規定し得る。

【００６８】 更新がライブラリパーティション６０へ結合されると、ライブラリパーティシ
ョン６０由来の古いバージョンは、アーカイブパーティション６２へ再配置され
る。図６は、結合操作を示し、ここでは、ジャーナルパーティション５８内で異
なる位置にある複数のデータアイテム１２０、１２２および１２４がコピーされ
、そしてこのコピーは、ライブラリパーティション６０に提供され、ここでコピ
ーは、ライブラリパーティション６０中の他のデータと統合および結合される。
ジャーナルパーティション５８からライブラリパーティション６０への転送時間
を減少させるために、データアイテムはデータ圧縮アルゴリズムに従って圧縮さ
れ得る。

【００６９】 図７は、結合操作に関するフローチャートである。ブロック１４０および１４
２において、データがジャーナルパーティション５８中のファイルに書き込まれ
る。ブロック１４４では、このシステムは、ライブラリパーティション６０が存
在するデバイス上に書き込まれ得るかどうかを決定する。デバイスがＣＤ−ＲＯ
Ｍのようなリードオンリーデバイスである場合、結合プロセスは起こり得ず、ル
ーチンはブロック１４６で停止する。そうでなければ、このシステムは、データ
がジャーナルパーティション５８からライブラリパーティション６０に対して提
供されるブロック１４８へ分岐する。ブロック１５０において、このシステムは
、他のジャーナルファイルが結合される必要があるかどうかを決定する。もしそ
うであれば、このシステムは、ブロック１４８へ戻るように分岐する。そうでな
ければ、このシステムはブロック１５２に示されるように、ジャーナルパーティ
ション６０から一つの統合ファイルへと複数のデータアイテムを統合し、そして
このファイルはライブラリファイルへと結合される。続いて、ブロック１５４に
示されるようにルーチンは終了する。

【００７０】 ２人以上のユーザが同一のファイルの変更をしようとすると、コンフリクトが
結合操作間で発生する。システムは両方の更新が認められ得るかどうか、そして
そうでない場合、２つの更新のうちのどちらかに決めるとすれば、どちらが格納
されるべきか、を決定しなければならない。先に記載したような統合手順は、こ
れらのコンフリクトを解決しなければならない。

【００７１】 図８は、統合手順に関するフローチャートである。ブロック１６０では、ルー
チンが初期化され、新しい「統合された」ファイルが作成される。このファイル
は、最終的にジャーナルファイルからのすべてのデータを含む。次に、各ジャー
ナルファイルに関して、そして各ジャーナルファイル中の各データアイテムに関
して、ルーチンはデータアイテムを統合ファイル加えようとする。

【００７２】 ブロック１６２では、ルーチンは、別のソース（通常は、異なるユーザと関連
したデバイス）由来の別のバージョンのデータアイテムが、既に統合ファイル中
に存在するかどうかを決定する。そうでなければ、新しいデータがブロック１８
４で統合ファイルに加えられ、そしてルーチンはブロック１８６で終了する。別
のソースから別のバージョンのデータアイテムが既に統合ファイル内に存在する
場合、ブロック１６２はブロック１６４へと分岐し、そしてバージョン間のコン
フリクトは、ユーザにより特定されるか、またはデータオブジェクトのタイプに
より特定されるルールを適用することにより、解決される。特定の場合において
、コンフリクトは結合操作により解決され得る。例えば、テキスト文書への重複
しない２つの変化が結合され得る。ブロック１６４で、ルーチンがコンフリクト
を解決すると、ブロック１６６はブロック１７４へと分岐し、ここで新しいデー
タは、ユーザまたはオブジェクトタイプ（ドメイン）により規定される方法を使
用して別のソースからのデータと結合する。次いで、このシステムは、ブロック
１８２で次のアイテムを取り出す。

【００７３】 ブロック１６４でルーチンがコンフリクトを解決しなかった場合、ブロック１
６６はブロック１６８へと分岐し、ここでシステムは、新しいアイテムまたは別
のソースからのアイテムが格納されるかどうかを決定する。新しいアイテムがコ
ンフリクトに勝り、従って格納されると、ブロック１６８はブロック１７６へと
分岐し、ここで別のソースからのアイテムは統合ファイルから除去され、別のソ
ース由来のアイテムを作成したメッセージがユーザに提供され、ユーザにこのデ
ータアイテムが格納されないことを知らせる。続いて、ルーチンはブロック１８
２へと分岐する。コンフリクトの勝者は、アイテムが一番最近のタイムスタンプ
またはより高い値を有したルールの数により決定され得るが、これに限定されな
い。あるいは、ルーチンは、より高度なジャーナルファイルを有するユーザまた
は情報を入力するユーザを優先し得る。

【００７４】 ブロック１６８で、新しいアイテムがコンフリクトに勝らない場合、ブロック
１６８はブロック１７０へと分岐し、ここでシステムは、別のソース由来のアイ
テムがコンフリクトに勝るかどうかを決定する。そうであれば、ブロック１７０
はブロック１７８へと分岐し、新しいデータアイテムは統合ファイルから除去さ
れ、メッセージが新しいデータアイテムを作成したユーザに提供され、そしてル
ーチンはブロック１８２へと分岐する。最後に、新しいアイテムまたは別のソー
ス由来のアイテムのいずれもがコンフリクトに勝らない場合、両方のデータアイ
テムは統合ファイルから除去され、メッセージが両方のアイテムのユーザに提供
される。続いて、ルーチンはブロック１８２へと分岐する。

【００７５】 この時点にて、古いジャーナルファイルがクリアされ得、再度更新される準備
が整う。ライブラリファイルが変更されないままでなければならない場合、ルー
チンは停止し、統合ファイルは新しいライブラリパーティションとしてパーティ
ションチェインに挿入され得、上記のような新しい「レイヤー」を作成する。さ
もなければ、次に統合ファイルはライブラリファイルと結合され得る。

【００７６】 図９は、統合ファイルをライブラリファイルと結合するためのフローチャート
である。ブロック１９０では、ルーチンは、古いほうのバージョンのデータアイ
テムが既にライブラリファイル中に存在するかどうかを決定し、そして存在しな
い場合、ルーチンはブロック１９４へと分岐する。さもなければ、ブロック１９
２は、古いほうのバージョンが保存されるべきかどうかを決定する。そうである
場合、古いほうのバージョンは、ブロック１９６に示されるようにアーカイブフ
ァイルへと転送される。古いほうのバージョンが保存されるべきでない場合、そ
れは削除され、そしてブロック１９２はブロック１９４へと分岐する。

【００７７】 ブロック１９４では、システムは、新しいアイテムがその親と共に格納されな
ければならない追加可能レコードを含むかどうかを決定する。そうである場合、
新しいデータアイテムは、ドメインにより規定される結合方法を使用して既存の
古いほうのバージョンと結合し、そしてルーチンはブロック２０２で終了する。
本発明に従って、複数のソースからのデータが結合され、そのいずれもが、ライ
ブラリパーティションが存在するデバイスに接続される必要はない。新しいアイ
テムが追加可能レコードでない場合、ブロック１９４はブロック１９８へと分岐
し、そして新しいデータアイテムがライブラリファイルに追加され、任意の古い
ほうのバージョンを上書きする。ブロック１９８では、オプションとして古いほ
うのバージョンがアーカイブされ得る。続いて、ルーチンはブロック２０２で終
了する。

【００７８】 （読み込みおよび書き込みデータアイテム） 追加可能データアイテムは、異なるパーティション内部に存在するデータを含
むので、読み込みおよび書き込み追加可能データアイテムは、システムが関連の
パーティションにアクセスすることを要求する。ユーザが、キーボード３０から
メモリ２６への入力により追加可能データアイテムを変更する場合、もとの内容
が変更とは別にメモリ２６中に格納され、そして「追加フラグ」がアイテムのた
めに設定される。データアイテムが永久記憶装置（例えば、メモリ３２内部のパ
ーティション５８）に書き込まれると、システムは、「追加フラグ」が設定され
ているかどうかを決定し、そしてそうである場合、追加可能アイテムの変更した
部分のみが書き込まれる。異なるパーティションに既に存在するオリジナルデー
タは、それがオリジナルリードオンリーパーティションから再構築され得るので
、書き込まれない。しかし、システムの完全性を保証するために、オリジナルデ
ータを表す独自の識別ナンバーがまた格納され、その結果システムは、オリジナ
ルデータが消失するかまたは変更されるかどうかを検出する。

【００７９】 データアイテムを読み込んでいる時、システムは、アイテムの「追加」フラグ
が設定されているかどうかを決定する。そうである場合、システムはオリジナル
データをそのオリジナルデータを含むパーティションから読み込もうとし、そし
てオリジナルデータを変更と結合しようとする。図５は、本発明の教示に従うデ
ータを読み込むためのフローチャートである。ブロック９０では、システムはま
ず、任意のローカルジャーナルパーティションを検索し、次いで読み込み中のデ
ータアイテムの識別ナンバーを有するデータアイテムを見つけるために、順にリ
モートパーティションを検索する（例えば、ライブラリパーティション次いでア
ーカイブパーティション）。システムがデータアイテムをなんら見つけられない
場合、ブロック９２はブロック９４へと分岐し、そして「ゼロ」または初期設定
値を返す。

【００８０】 逆に、システムがデータアイテムを見つけると、ブロック９２はブロック９６
へと分岐し、そしてシステムは、データアイテムが「墓石」であるかどうか、す
なわち特定のデータアイテムが削除されたかどうかを決定する。そうであれば、
システムはブロック９４へと分岐する。さもなければ、ブロック９８で、システ
ムはアイテムの追加フラグが設定されているかどうかを決定し、そうでない場合
、このシステムはブロック１００に示されるようにデータアイテムを返す。追加
可能アイテムを示している追加フラグが設定されていると、ブロック１０２で、
システムは、同じ識別ナンバーを有する他のデータアイテムを見つけるために他
のパーティションを検索する。親データアイテムが見つからない場合、システム
はブロック１０４からブロック１０６へと分岐し、ここでシステムは、追加フラ
グが、親データアイテムが存在することを示すためエラーを示す。

【００８１】 システムが親データアイテムを見つけると、システムは親データアイテムの追
加フラグが設定されているかどうかをブロック１０８で決定し、これは親がそれ
ぞれの親を有するかどうかを示す。そうである場合、ルーチンは分岐して１０２
へと戻り、ここで次のパーティションが順に検索される。ルーチンがすべての関
連したデータアイテムを見つけると、ブロック１１０に示されるように、それら
は１つのアイテムに結合され、そして返される。

【００８２】 （消失パーティション） 本発明の１つの利点は、読み込みおよび書き込みデータアイテムは、すべての
時点においてすべてのパーティションが存在していることを要求するわけではな
いということである。データが主にジャーナルパーティションから読み込まれる
（および常にジャーナルパーティションへ書き込まれる）場合、いくつかまたは
任意のライブラリおよびアーカイブパーティションがなくても悪い影響はない。

【００８３】 特に、本発明は、信頼できないまたは完全に切断されたパーティションチェイ
ンにかかるデータを処理する方法を提供する。

【００８４】 例えば、ユーザは、ラップトップコンピュータ上にジャーナルパーティション
および小さなローカルライブラリパーティションを有し得る。特定の時間におい
て、ユーザは、ずっと大きなマスターライブラリパーティションおよびアーカイ
ブパーティションにアクセスするためにネットワークに接続することが可能であ
るがネットワークから切断してもなおデータアイテムを首尾よく入力および取り
出すことが可能である。

【００８５】 ユーザネットワークに接続されている間、ジャーナルファイルの統合が起こり
得、所望であれば、その後新しいジャーナルおよびライブラリファイルが以前の
バージョンと置き換わり得る。

【００８６】 さらに、この同一のアプローチが他の切断可能なパーティションに適用され得
、これには、取外し可能ディスク、ＣＤ−ＲＯＭ、インターネットサーバなどに
格納されるパーティションが挙げられるが、これらに限定されない。

【００８７】 （ジャーナルファイル） この章では、ジャーナルパーティション５８の好ましい実施形態を説明する。
ジャーナルパーティション５８は、以前のバージョンのこれらの同一のアイテム
を保持することができるように、格納媒体上に種々の長さのデータアイテム（例
えば、フリーテキストデータベースレコード）を格納し得る。

【００８８】 図１０は、ジャーナルパーティション５８の構造を示す。ジャーナルパーティ
ションは、図１の大容量メモリ３２に存在し得る。図１０に示されるように、ジ
ャーナルパーティション５８を含むメモリは、物理格納デバイスブロック２５０
、２５２および２５４へと分割されている。データオブジェクト（データオブジ
ェクト２５６、２５８および２６２を含む）は、ブロック２５０、２５２および
２５４内部に格納される。

【００８９】 図１０に示されるように、ジャーナルパーティション５８に格納されるべきデ
ータオブジェクトは、メモリに連続的に追加され、そしてブロック２５０、２５
２および２５４は、上書きされない。従って、ジャーナルパーティション５８は
、同じデータオブジェクトの古いほうのバージョンを含み得る。例えば、データ
オブジェクト２５６は、会社従業員に関する情報を含むデータベースセルを含み
得、そしてデータオブジェクト２５８は、ユーザがそれを更新した後にはそのセ
ルを示し得る。このシステムは、必要とされるときに新しいブロックを作成し、
そしてこのシステムは、オブジェクトをそれらの各ブロックに関連付けるテーブ
ル２６０を格納する。テーブル２６０は、オブジェクトがブロックに書き込まれ
るそれぞれの時間に更新される。

【００９０】 図１１は、オブジェクト２６２のコンテンツを示す。好適な実施形態において
、オブジェクト２６２は、５つのフィールド、すなわちステータスフィールド２
６４、識別子フィールド２６６、データフィールド２６８、ポインタフィールド
２７０、およびタイムスタンプフィールド２７２を含む。オブジェクト２６２は
、ステータスフィールド２６４を除けば他のフィールド全てを必ずしも含む必要
はなく、ステータスフィールド２６４は、オブジェクトが含んでいるフィールド
を示すフラグを含む。データフィールド２６８は、オブジェクト２６２に対応す
るテキストおよび数字等のデータを格納し、ポインタフィールド２７０は、旧バ
ージョンのオブジェクト２６２を示すポインタを含む。タイムスタンプフィール
ド２７２は、オブジェクト２６２が生成された時間を示し、識別子フィールド２
６６は、表２６０に用いられるオブジェクト２６２を識別する数を含む。

【００９１】 旧バージョンのデータアイテムは削除不可能なので、データアイテムの削除は
特別に処理する必要がある。データアイテムを削除する際、データアイテムが削
除されたことを意味する「墓石」と呼ばれる特別な印がジャーナルパーティショ
ンに書き込まれる。この墓石は、値を持たないデータフィールドを有するオブジ
ェクトを含み、そのアイテムが墓石であることを示す特別なステータスフラグが
設定される。この墓石オブジェクトは、削除されるデータアイテムの最新バージ
ョンを含むオブジェクトを示すポインタを格納する。

【００９２】 データアイテムを読み出す際、表２６０中から適切なブロックをルックアップ
することにより、最新のバージョンのデータアイテムが検索される。該当アイテ
ムに関連する最新オブジェクトを検索することにより最新バージョンのデータア
イテムが検索され終えると、検索されたオブジェクト中に格納されているポイン
タを用いることにより旧バージョンのデータアイテムが検索可能となる。

【００９３】 その結果、ユーザは、旧バージョンのデータアイテムを廃棄したいと考え得る
。これは、所望のデータアイテム（通常は最新のデータアイテム）を別のファイ
ルにコピーしてオリジナルのファイルを廃棄することにより行われる。

【００９４】 図１２は、ジャーナルパーティション５８にアイテムを挿入する工程、ジャー
ナルパーティション５８中のアイテムを更新する工程、およびジャーナルパーテ
ィション５８からデータアイテムを削除する工程のフローチャートである。図１
２に示すルーチンによれば、挿入工程、更新工程、および削除工程は同様の方法
で行われ、ステータスフラグはこれらのアクション間の相違点を示す。

【００９５】 これらの３つの動作は全て、新しいオブジェクトをジャーナルパーティション
５８に書き込む工程を含む。既存のデータアイテムを更新する場合、新しいオブ
ジェクトは、上述したように、更新されたデータと旧バージョンのデータアイテ
ムを示すポイントとを含む。データアイテムを削除する場合、上述したように、
削除されたデータアイテムを示すジャーナルパーティション５８に墓石オブジェ
クトが書き込まれる。

【００９６】 ブロック２８０において、挿入動作が開始し、ブロック２８２へと分岐する。
アイテムを挿入することはポインタの対象となる旧アドレスが無くなることを意
味するため、ブロック２８２において、旧アドレスフラグがＦＡＬＳＥに設定さ
れる。逆にいえば、ブロック３００に示すように既存のデータアイテムを更新す
る際、本システムは、更新対象のアイテムを含むオブジェクトのアドレスを格納
し、ブロック３０２に示すようにそのオブジェクトの旧アドレスフラグをＴＲＵ
Ｅに設定する。ブロック３１４に示すようにデータアイテムを削除する際、ルー
チンは「墓石」フラグをＴＲＵＥに設定し、「データ値」フラグをＦＡＬＳＥに
設定して、書き込み中のオブジェクト中にデータが存在せず、ブロック３１６に
示すように書き込み中のオブジェクトがデータアイテムの削除を意味することを
知らせる。

【００９７】 次いで、本システムは、新しいオブジェクトをジャーナルパーティション５８
に書き込む。書き込みを行う前に、本ルーチンは、新規オブジェクトを様々なオ
プションに従って処理し得る。例えば、ブロック２８４において、本ルーチンは
、オブジェクト識別子フィールドにオブジェクト識別子を格納するかどうかを判
定する。識別子の格納は検索には不必要であるが、ファイルが破損した場合にデ
ータを回復するのに利用することができる。識別子の格納を行わない場合、ブロ
ック２８４はブロック３０４へと分岐し、識別子フラグはＯＦＦ設定となる。ブ
ロック３０４はブロック２８６へと分岐し、ジャーナルパーティション５８にス
テータスフラグが書き込まれる。

【００９８】 ブロック２８８において、本ルーチンは、識別子フラグがＴＲＵＥかどうかを
判定する。識別子がＴＲＵＥである場合、本システムはブロック３０６へと分岐
し、ジャーナルパーティション５８に識別子が書き込まれる。本システムは次い
で、ブロック２９０へと分岐し、数値フラグがＴＲＵＥかどうかを判定する。数
値フラグがＴＲＵＥである場合、本システムは、該当データ値をジャーナルパー
ティション５８に書き込む。同様に、ブロック２９２において、本ルーチンは旧
アドレスフラグがＴＲＵＥかどうかを判定する。旧アドレスがＴＲＵＥである場
合、本システムはブロック３１０に分岐し、ジャーナルパーティション５８内に
生成された新しいデータオブジェクト中のポインタフィールドに旧アドレスが書
き込まれる。本システムは次いでブロック２９４に分岐し、タイムスタンプフラ
グがＴＲＵＥかどうかを判定する。タイムスタンプフラグがＴＲＵＥである場合
、本システムは、ジャーナルパーティション５８内に生成された新オブジェクト
のタイムスタンプフィールドにタイムスタンプを書き込む。

【００９９】 最後に、表２６０が更新され、表２６０は、ジャーナルパーティション５８に
書き込まれた新オブジェクトに対応するデータアイテムのデスク上での新しい配
置を反映する。

【０１００】 このアプローチでは様々なオプションが可能である。例えば、全データアイテ
ムに関して、識別子の格納はオプションである。識別子、タイムスタンプ、およ
び旧ポインタを格納しない場合、データアイテムの必要格納サイズは最小となる
。

【０１０１】 （データ回復） 好適な実施形態において、表２６０の構造は、標準的な延長可能なハッシュ表
データ構造である。上述したように、表２６２は、新オブジェクトがジャーナル
パーティション５８に書き込まれるたびに更新される。表２６０は極めて大量に
なり得るので、表を保存するのではなく、表２６０を不揮発性メモリに書き込む
ことにより、更新が行われるたびに、チェックポイントアプローチを用いてユー
ザが規定する特定の間隔をあけて表２６０を保存する。例えば、ユーザは、５０
回更新を行う毎に表を保存すると規定し得る。

【０１０２】 表２６２が保存された後、「センチネル」がジャーナルパーティション５８に
書き込まれる。図１３は、「センチネル」データオブジェクトを示す。「センチ
ネル」オブジェクト３５０および３５２はそれぞれ、表３５４および３５６にそ
れぞれ対応するタイムスタンプおよびポインタを含む。表３５４および３５６は
、表２６０のバージョンを含み、「センチネル」オブジェクトがジャーナルパー
ティション５８に書き込まれるときに不揮発性メモリ中に格納される。

【０１０３】 クラッシュが発生した場合、実際のデータは既にジャーナルパーティション５
８に書き込まれているため、本システムでは表２６０を復元するだけでよい。表
２６０の復元は、ファイルの開始部分からではなく最終部分にある有効センチネ
ルから開始できるため、復元速度が飛躍的に速くなる。表２６０を復元するルー
チンの好適な実施形態に従って、ジャーナルの最終部分から逆方向に読み出しを
行うことにより、最新の「センチネル」オブジェクトが配置される。この配置場
所が表２６０を有効にする最終ポイントとなる。センチネルは、表２６２を格納
するディスクファイルに対応するポインタを含み、次いで、この表２６２は、こ
のファイルからロードされ得る。表２６２が見つからなかったりまたは損傷を受
けている場合、ルーチンは、ジャーナルファイルの前にある「センチネル」オブ
ジェクトチェックポイントを探そうとする。このプロセスは、有効「センチネル
」オブジェクトが見つかるかまたはジャーナルファイルの開始部分に到達するま
で継続する。

【０１０４】 次いで、有効な表に対応するポイントを指す「センチネル」が（少しでもあれ
ば）配置された後に、ジャーナルパーティション５８に書き込まれた次のオブジ
ェクト部分から、ジャーナルパーティション５８の読み出しが開始する。その後
、ジャーナルパーティション５８にオブジェクトが書き込まれるたびに表２６０
が更新される。最後に、「センチネル」が新しく生成され、表２６０が新たに保
存される。

【０１０５】 （最適化） 本格納システムのオブジェクトオリエンテーションは、多様な操作の効率化を
促進する。例えば、１９９５年 に出願された出願番号 の、
「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｉｍｐｒｏｖｅｄ Ｉ
ｎｆｏｒｍａｔｉｏｎ Ｓｔｏｒａｇｅ ａｎｄ Ｒｅｔｒｉｅｖａｌ Ｓｙｓ
ｔｅｍ」という名称の本出願と同時係属中の出願に、行および列の表を含むデー
タベースについての開示がある。行はレコードに対応し、列はフィールドに対応
する。行および列の交差部分は、本発明のデータアイテムに対応するセルを含む
。従って、セルは、本発明の教示内容に従ったデータオブジェクトとして格納さ
れる。本発明の教示内容による同時係属中の出願のデータベースを格納すること
により、以下のような特定のデータベース操作が改良される： Ｉ．分散ネットワークまたは切断ネットワーク中の共有データを利用すること
。

【０１０６】 ＩＩ．データをセルレベルで複製、同期化、および結合し、インデックスを結
合すること。

【０１０７】 ＩＩＩ．損傷を受けたデータまたは見つからないデータを回復すること。

【０１０８】 ＩＶ．セルを行単位ではなく列単位でサーチすること。

【０１０９】 さらに、セルの格納媒体への物理的配置は、自在に行うことができ、各要件に
応じて調整可能である。例えば、特定の列（または列のセット）を定期的にサー
チする場合、その列を含むセルを互いに隣接させた状態でパーティション内に保
存することができる。あるいは、主格納ファイルからセルを分離して、「ストリ
ップ」と呼ばれる別のファイルに格納することもできる。

【０１１０】 データアイテムの中には、冗長な情報を含むものもあり、上述したように、親
データアイテムに相当する「オリジナルの」情報から冗長情報を復元することが
できる。例えば、１９９５年２月３日に出願された、「Ｍｅｔｈｏｄ ａｎｄ
Ａｐｐａｒａｔｕｓ ｆｏｒ Ｉｍｐｒｏｖｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓ
ｔｏｒａｇｅ ａｎｄ Ｒｅｔｒｉｅｖａｌ Ｓｙｓｔｅｍ」という名称の本出
願と同時係属中の特許出願第０８／３８３，７５２号を参照すると、データアイ
テムの「親フォルダ」属性全てを収集することにより、レコードのグループに対
応するレコードであるフォルダのコンテンツを復元することが可能である。同様
に、インデックスおよび他のナビゲーション構造も多くの場合復元可能である。

【０１１１】 これらの種類の復元可能なデータアイテムには、特殊な格納技術を用いること
が可能である。データアイテムのコンテンツは、ジャーナルパーティションとは
別の特別な場所に格納される。この場所は、復元可能なデータアイテムが書き込
まれるたびに再利用され得、そのためメモリ容量および時間が節約できる。その
結果、ジャーナルは、実際のデータそのものの代わりとして、この外部の場所に
対するポインタを含む。何らかの理由により外部の格納場所が見つからないかま
たは損傷を受けている場合、データアイテムは適切な方法を用いて復元すること
ができる。

【０１１２】 （システムアーキテクチャ） 図１４は、本発明の情報格納および検索システムのブロック図である。図中に
示すように、本発明は、レコード用データベース４０１およびフリーテキストデ
ータベース４０２をさらに含む内部データベース４００を含む。データベース４
００は、ワープロ文書４０４、表計算４０５、およびデータベースファイル４０
６を含むデータを複数の外部ソース４０３から受信し得る。以下により詳細に説
明するように、本発明は、外部ソース４０３をデータベース４００とインターフ
ェースするアプリケーションサポートシステムを含む。

【０１１３】 データベース４００中に格納されている情報を効率良く検索するために、複数
のインデックス４０６（キーワードインデックス４０７および他の種類のインデ
ックス（例えば、他の言語を特殊な音声順に選別したインデックス、化学、法律
、医学などの分野特有のインデックス）等を含む）は、データベース４００によ
り提供される選別情報を格納する。インデックス４０６中の情報を整理するため
に、知識システム４０８は、インデックス４０６内にある情報を互いにリンクさ
せる。

【０１１４】 図１４に示す構成は概念を説明するためのものであり、実際には、以下により
詳細に説明するように、データベース４００、インデックス４０６および知識シ
ステム４０８は、同じ表中に格納される。本明細書では、データベース４００の
構造および機能についてまず始めに説明し、次いで、インデックス４０６および
データベース４００をサーチするためのインデックス４０６のインプリメンテー
ションについて説明する。次いで本明細書では、シノニムおよび他の構成要素を
提供することによりインデックス４０６をさらに改良する知識システム４０８に
ついて説明し、最後に、外部アプリケーションプログラム４０３とデータベース
４００との間のインターフェースについて、新規な構造のワードプロセッサおよ
び新規なパスワードスキームを含めて詳細を説明する。

【０１１５】 図１５は、本発明の格納および検索の構造を示す。本発明の格納および検索構
造は、表４０９を含む。表４０９の構造は、論理的構造であり、必ずしも物理的
構造ではない。従って、本発明の教示内容にしたがって設定されるメモリ２６お
よび３２は、表４０９を連続的に格納する必要はない。

【０１１６】 表４０９は、複数の行４１０および複数の列４２０をさらに含む。行はレコー
ドに対応し、列はレコードの属性に対応し、列の規定する特性は、行４１１に格
納される。行および列の交差部分は、特定のセルを含む。

【０１１７】 各行には、列４２０に格納される独自のオブジェクト識別番号（ＯＩＤ）が割
り当てられ、各列にも独自のＯＩＤが割り当てられ、括弧中に表示され、行４１
１中に格納される。例えば、行４１０は１１００と等しいＯＩＤを有し、列４２
２は１０１と等しいＯＩＤを有する。以下により詳細に説明するように、行およ
び列のＯＩＤはどちらともポインタとして用いられ得、セル４１２はＯＩＤを格
納し得る。さらに、ＯＩＤを割り当てる方法について以下に説明する。

【０１１８】 図１５に示すように、レコードに対応する各行は、各列中に情報を含み得るが
、行は、データを各列中に有する必要はなく、また有していないことが多い。例
えば、行４１０は、セル４１３に示すように社名に対応する。社名がないのでセ
ル４１４は未使用となっている。

【０１１９】 列と関連する種類の情報は、「ドメイン」として公知である。ほとんどのデー
タベースシステムでサポートされる標準的ドメインは、テキスト、数、日付、お
よびブーリアン（Ｂｏｏｌｅａｎ）を含む。本発明は、行または列を指すＯＩＤ
ドメインのような他の種類のドメインを有する。本発明はさらに「ユーザが規定
する」ドメインをサポートし、これにより、ドメインの全挙動をユーザまたはプ
ログラマによって決定することができる。例えば、ユーザは、ドメインを格納媒
体への書き込みおよび格納媒体からの読み出しならびに同等試験および比較など
の処理操作を含むように設定し得る。

【０１２０】 本発明によれば、個々のセルは、セルの行および列のＯＩＤに従ってアクセス
することができる。すなわち、従来技術では標準的なレコード（または行）では
なく、セル（または行と列との交差部分）が格納および管理単位となる。セルを
格納単位として用いると、従来はオブジェクト全体またはレコード全体を必要と
した多くの標準的なデータ管理操作が改良される。このような操作としては、バ
ージョン変更、セキュリティ、階層型格納管理、リモートパーティションへの追
加、印刷、および他の操作がある。

【０１２１】 （列の定義） 各列は、関連する列の定義を含み、この定義は、列の特性（例えば、列のドメ
イン、列の名称、列の要／不要、および列に関連し得る他の特性等）を決定する
。表４０９は、構造化されていないフリーテキストデータを含む列をサポートす
る。

【０１２２】 列の定義は、図１５の表４０９にレコードとして格納される。例えば、「雇用
主」列４１５は、対応する行４１６を有する。列に対応する行を追加すると、表
４０９は自己参照型になる。新しい列は、列の定義レコードを新たに生成するこ
とにより、表４０９に容易に付加され得、既存のレコード使用にすぐに利用可能
となる。

【０１２３】 （日付） 日付は、数字としてもテキストとしても規定可能である。数字で表した日付の
例としては「１１／６／６７」があり、テキストとして表した日付の例としては
「Ｎｏｖｅｍｂｅｒ ６， １９６７」がある。テキスト入力は、標準的なアル
ゴリズムおよびルックアップテーブルを用いて日付に変換される。日付数値とし
て、オリジナルのテキストおよびテキストを変換した日の日付の両方を格納する
ことができるため、日付を最初に入力したときの形式で日付数値を表示すること
ができる。

【０１２４】 （数） 数値は、自然数（整数）としてまたは分数として分類される。好適な実施形態
において、整数は可変長構造として格納されるため、任意の大きさの数として表
すことができる。全てのデータ構造およびインデックスはこの形式を用いるため
、本システムには限界が無い。

【０１２５】 分数は、可変長の整数を組み合せて＜分子／分母＞とすることにより表される
。日付の場合と同様に、数値としてオリジナルのテキスト（「４ １／２ ｉｎ
ｃｈｅｓ」）およびそれに関連する数（４．５）両方を格納できるため、数値を
最初に入力したときの形式で数値を再表示することができる。

【０１２６】 （タイプの定義） レコードは、「レコードタイプ」と関連付けられ得る。レコードタイプは、単
にカテゴリとして使用するだけではなく、レコードの挙動を決定するためにも用
いることができる。例えば、レコードタイプは、あるタイプのレコード全てに必
要な特定の列を規定し得、列の場合と同様に、タイプ定義もレコードとして表４
０９に格納される。図１５において、列４２２は各レコードについてのタイプ定
義を含む。列４２２は、特定のタイプの列を定義する行に対応するポインタを格
納する。例えば、列４１６は、「フィールド」タイプの列であり、セル４１７に
おいて、「フィールド」タイプの列を定義する行４１８に対応するポインタを含
む。行４１８のこの「タイプ列」４２２は、行４１９に規定された「タイプ」と
呼ばれるタイプに対応する。「タイプ」は、「タイプ」自身に対応するタイプ列
を有する。

【０１２７】 レコードタイプは、対応する行により規定されるように、そのタイプのレコー
ドが含み得る数値を制限し得る。例えば、レコードタイプの「Ｐｅｒｓｏｎ」は
、「人物」のタイプのレコードが、「名前」列、「電話」列、および他の任意の
列内に有効値を有することを必要とし得る。レコードのタイプは、レコードの属
性であるため、いつでも変更され得る。

【０１２８】 （テンプレートの定義） テンプレートは、フィールドの詳細およびリストを含む特別なレコードである
。例えば、連絡（ｃｏｎｔａｃｔ）テンプレートは、「名前」、「苗字」、「電
話」などのフィールドからなり得る。テンプレートは、フィールドのグループを
簡便に標識化するために用いられる。テンプレートは、様々な目的（例えば、レ
コードの編集、レコードの印刷、レコードのサーチ、またはレコードのエクスポ
ート等をするときに用いるフィールドの決定）に用いることができる。より高度
なテンプレートは、レコードを編集または印刷するときに用いられるレイアウト
情報を含むことができる。

【０１２９】 あらゆるレコードはあらゆるフィールドを含むことができるため、レコードの
タイプに対して、あるフィールドが「不適切」であっても、あらゆるテンプレー
トをあらゆるレコードに適用できる。例えば、レコードのコレクション（ｃｏｌ
ｌｅｃｔｉｏｎ）を印刷するとき、レコードの種類が互いに異なっていても、コ
レクション中の全てのレコードに同じテンプレートが適用され得る。

【０１３０】 レコードは、特定の「デフォルトテンプレート」と関連付けることができる。
このテンプレートは、レコードの編集、印刷、およびエクスポートの際にデフォ
ルトとして用いられる。

【０１３１】 （独自のＯＩＤの生成） 上述したように、列および行を形成する際、本システムでは独自のＯＩＤを生
成する必要がある。図１６は、ＯＩＤを割り当てる方法のフローチャートである
。

【０１３２】 図１６のブロック４３０において、メモリ２６中に格納されているデータベー
スプログラムを動作させるＣＰＵ２４は、オペレーティングシステムからのタイ
ムスタンプをリクエストする。ブロック４３２において、本システムは、受信し
たタイムスタンプが以前のタイムスタンプと同一かどうか判定する。タイムスタ
ンプが同一である場合、ブロック４３２はブロック４３４に分岐し、同一のタイ
ムスタンプ間のコンフリクトを解消するためにタイブレーカを増加させる。ブロ
ック４３６において、本システムは、タイブレーカが限度に達したかどうかを判
定し、限度に達している場合、本システムはブロック４３０に分岐し、新しいタ
イムスタンプを検索する。限度に達していない場合、本システムはブロック４４
０に分岐し、ユーザセッションに対して独自のセッション識別をリクエストする
。

【０１３３】 好適な実施形態において、セッション識別は、ユーザマシンにインストールさ
れたアプリケーションの独自の通し番号から得られる。あらゆる特定のマシンか
ら独立した特定のＯＩＤの場合、セッション識別は、オブジェクトの種類を判定
するために用いられ得る。例えば、日付はあらゆる特定のマシンから独立するた
め、日付のＯＩＤは一定のセッション識別を有し得る。

【０１３４】 ブロック４３２を参照して、タイムスタンプが同一でない場合、制御はブロッ
ク４３８へと進み、タイブレーカはゼロに設定され、次いで制御はブロック４４
０に進む。上述したように、ブロック４４０において、本システムは、ユーザセ
ッションに対して独自のセッション識別を要求する。次いで、制御はブロック４
４２へと進み、セッション識別、タイムスタンプ、およびタイブレーカを組み合
わせてビットアレーとし、このビットアレーをＯＩＤとする。ＯＩＤは可変長構
造であるので、必要な精度、オペレーティングシステムクロックの分解能、およ
びユーザ数に応じて任意の数のビットが用いられ得る。好適な実施形態において
、ＯＩＤは長さが６４ビットであり、タイムスタンプは第１の３２ビットを含み
、タイブレーカは次の１０ビットを含み、セッション識別は２２ビットを含む。

【０１３５】 特定の種類のＯＩＤおよびその長さは、単一のデータベースでは一定であるが
、データベース間において変化し得る。使用されるＯＩＤの種類を示すフラグは
、各データベースのヘッダ中に埋めこまれ得る。

【０１３６】 （ＯＩＤドメイン） ＯＩＤドメインは、他のレコードへのポインタとして、ＯＩＤを格納するのに
用いられる。列をサーチするよりも、これらのＯＩＤを用いて他のレコードを直
接サーチした方が効率的に問い合せを行うことができる。

【０１３７】 ユーザが列を検索して列内の特定のアイテムを有するレコード（単数または複
数）を見つけようとして、そのアイテムのＯＩＤを知らない場合、本発明は、テ
キストの詳細からＯＩＤを判定する新規な技術を含む。ユーザがレコードに情報
を入力しているとき、テキストからＯＩＤへの変換を行うことも必要となり得る
。例えば、図１５において、ユーザは、「雇用主」列４１５に情報を入力してい
る最中であり得、テキスト「ＤＥＸＩＳ」を規定してＯＩＤ＃１１００へ変換し
ようとする。この目的のため、サーチおよび変換を実行する方法を規定する特別
な列が必要となる。

【０１３８】 図１８は、図１７に示す構造に従って構成された表４０９をサーチするフロー
チャートである。ブロック４５０において、ユーザは、サーチしたい特定の列に
関するテキストを、キーボード３０またはマウス４５を通じて入力する。ブロッ
ク４５２において、本システムは、図１７に示すような列４５１に格納されてい
る情報から、サーチ対象となる列のサーチ経路を検索する。上記の実施例から引
き続いて、行４１６内のセル４５３は、図１５の「雇用主」列４１５に関するサ
ーチ経路情報を含む。「雇用主」フィールドに関するサーチ経路情報は、「ＤＥ
ＸＩＳ」のラベル（ｌａｂｅｌ）を有する会社について、「＼ｃｏｎｔａｃｔｓ
」および「＼ｄｅｐａｒｔｍｅｎｔｓ」と呼ばれるフォルダをサーチするべき旨
を示す。

【０１３９】 図１７に戻って、本システムは、検索したサーチ経路情報に従って表４０９を
サーチする。サーチ経路内に規定された各フォルダについて、本ルーチンは、図
１５の列４２２に示すようなサーチ対象のテキストと同一でかつ同じ種類の図１
５のラベル列４２３での入力を有するレコードをサーチする。フォルダについて
以下により詳細に説明する。

【０１４０】 ブロック４５６において、本システムは、ユーザがサーチしているテキストに
マッチングするアイテムが見つかったかどうか判定する。アイテムが見つからな
い場合、ブロック４５８において、本システムは、ユーザに表示画面３７上に新
しいレコードを生成するよう促す。ユーザが新しいレコードを生成したい場合、
制御はブロック４６２に進み、本システムは新しいレコードを生成する。ブロッ
ク４６４において、新しいレコードのＯＩＤが戻される。ユーザが新しいレコー
ドを生成したくない場合、ブロック４６０に示すように、「ＮＩＬ」ストリング
が戻される。

【０１４１】 システムが、少なくとも１つのアイテムを見つける場合、システムは、ブロッ
ク４６６に示すように、１つ以上のアイテムが見つかったかどうか判定する。ア
イテムが１つだけ見つかった場合、ブロック４６８においてそのＯＩＤが返却さ
れる。１つ以上のアイテムが見つかった場合、ブロック４７０において、システ
ムはアイテムのリストをユーザに表示し、ユーザはそのリストからレコードを選
択する。ブロック４７２において、選択されたレコードのＯＩＤ（上記の例では
、会社「ＤＥＸＩＳ」のレコードのＯＩＤである＃１１００）が返却される。

【０１４２】 図１８を参照しながら説明したように、別の実施形態において、このサーチメ
カニズムに様々な機能（例えば、サーチにさらなる制限を追加すること、厳密な
マッチングの代わりに予め固定したマッチングまたはあいまいなマッチングを可
能にすることによりサーチを関連付ること、および後述するような「連想サーチ
（ａｓｓｏｃｉａｔｉｖｅ ｓｅａｒｃｈ）」技術を用いることによりサーチを
広範に行うこと等）が追加され得る。

【０１４３】 （双方向同期化リンク） レコードは相互関係を有し得、相互関連するレコード間の整合性を維持するこ
とが望ましい場合が多い。例えば、図１５の行４１０に示すように、会社につい
てのデータを含むレコードは、その会社の従業員に関する情報を含み得る。同様
に、その会社で働いている従業員は、図１５の行４２１で示されるように、雇用
主をポインタで示すレコードを有し得る。従って、会社の従業員列は、雇用主列
がその会社に対応している従業員に対応するべきである。本発明は、相関レコー
ドが追加または削除されるたびに列間の相関関係を適切に更新することを確実に
する同期化技術を含む。

【０１４４】 本システムは、図１７に示すような「同期化先」列４５５を表４０９に追加す
ることにより、相関レコードを同期化する。列中の数値はレコード間の関連性を
定義しているので、列に対応する行４１６および４５７は、「同期化先」列４５
５中に、どの他の列が行４１６および４５７に対応する列と同期化されるかを示
す情報を含む。図１７を参照して、「雇用主」列４１５は、行４５７に表示され
ている「従業員」列に対する「同期化先」列４５５中のＯＩＤポインタにより、
「従業員」列と同期化される。同様に、「従業員」列は、行４１６で示されるよ
うに、「雇用主」列４１５に対する「同期化先」列４５５中のポインタにより、
「雇用主」列４１５と同期化される。従って、従業員が会社を変わるたびに、そ
の従業員の「雇用主」列が変更され、前の雇用主の「従業員」列が更新されて、
元従業員に対するポインタが削除され、その結果「雇用主」フィールドに新しい
雇用主の従業員が追加される。別の列へに対する関連（ｒｅｆｅｒｅｎｃｅ）が
追加または除去されても、もしくはレコード全体が表４０９に付加または表４０
９から削除されても、いずれの場合においても、列が変更されるたびに同期化を
行う必要があり得る。

【０１４５】 図１８Ａは、ユーザがレコードを追加または削除するときにレコードを同期化
するためのフローチャートである。ブロック４６１において、システムは、他の
行への関連（すなわち、簡単に言うと他の行のＯＩＤ）に関するオリジナルのリ
ストのバックアップを作成して、システムが、追加または削除されたのはどのＯ
ＩＤかを後で判定することができるようにする。同期化する必要があるのは、追
加または削除の２つの変更のみである。ブロック４６３において、システムは、
規定されたＯＩＤを追加または削除することにより、関連の新しいリストを生成
する。ブロック４６５において、システムは、関連する列が別の列と同期化して
いるかどうか判定する。関連する列が別の列と同期化していない場合、システム
はブロック４６７へと分岐し、更新が終了する。列が他の列と同期化している場
合、システムは、その列が既に同期化ルーチンに入っているかどうか判定する。
その列がまだ同期化ルーチンに入っていない場合、ルーチンは、無限に続く反復
ループに入る。システムがすでに同期化ルーチンに入っている場合、システムは
ブロック４７１へと分岐し、更新が終了する。

【０１４６】 そうでない場合、システムは、実際に同期化を行う。ブロック４７３において
、システムは、変更されているレコード（Ｒ１）の列（Ｃ１）に追加されたＯＩ
Ｄまたはそこから除去されたＯＩＤを見つける。ブロック４７４において、シス
テムは、追加または除去されたＯＩＤに対応するレコード（Ｒ２）を検索する。
システムは、ブロック４７５において列（Ｃ１）の同期化列（Ｃ２）を決定し、
そのフィールドを追加または除去されたＯＩＤに配置する。例えば、雇用主が解
雇されて雇用主の「雇用主」フィールドがそれに応じて変更されると、システム
は、図１７に示すようなセル４５９に含まれる「従業員」列についての「同期化
先」列４５５の数値をルックアップする。セル４５９は「雇用主」フィールドに
対応しているので、システムは、解雇された従業員のレコードの「雇用主」フィ
ールドを配置する。図１８Ａのブロック４７６において、ＯＩＤを追加または除
去することにより、配置されたセル（Ｒ２：Ｃ２）が更新される。上記の実施例
から引き続いて、雇用主のＯＩＤを「雇用主」フィールドから削除するだけで、
従業員の「雇用主」フィールドは、元従業員に対応しなくなるように変更される
。システムはブロック４７３に戻って分岐し、他の任意のＯＩＤの追加および除
去を更新する。システムがＯＩＤ全てを処理すると、ブロック４７７および４７
８に示すようにルーチンが終了する。

【０１４７】 図１８Ｂは、「雇用主」フィールドと「従業員」フィールドとを列について同
期化させた結果を示す。図示のように、これらの２つの列のレコード中のポイン
タは、互いに一致している。

【０１４８】 （列中の列） 列は、自身の中に、同じレコード中にある他の列への関連を含み得る。例えば
、「姓名」列は、「名前」列および「苗字」列の両方への関連を含み得る。そう
することで、「姓名」列の数値を、他の２つの列の数値から復元することができ
る。図１９Ａおよび１９Ｂは、同一レコード中の１つ以上の列から数値を復元す
るための２つの可能なインプリメンテーションを示す。

【０１４９】 図１９Ａは、「名前」列４８２、「苗字」列４８４、および「姓名」列４８６
を含む表４８０を示す。「Ｊｏｈｎ Ｓｍｉｔｈ」のレコード２２６は、「名前
」列４８２中に名前「Ｊｏｈｎ」を有し、列４８４中に苗字「Ｓｍｉｔｈ」を有
する。姓名フィールド４８６Ａは、列４８６に示すような＜ｆｉｅｌｄＲｅｆ
ｆｉｅｌｄ ＝ 'Ｃｏｌｕｍｎ Ｎａｍｅ'＞の形式に従った括弧中のフィール
ドを参照することにより、「姓名はＪｏｈｎ Ｓｍｉｔｈ」というテキストを返
す。

【０１５０】 図１９Ｂは、図１９Ａに示す参照スキームを改変したものである。図１９Ｂは
、「名前」列４８３、「苗字」列４８５、および「姓名」列４８７を含む表４８
１を示す。「Ｊｏｈｎ Ｓｍｉｔｈ」のレコード４８９は、「名前」列４８３中
に名前「Ｊｏｈｎ」を有し、列４８５中に苗字「Ｓｍｉｔｈ」を有する。姓名フ
ィールド４８７Ａは、列４８７に示すような変数「ｆｎ」および「ｌｎ」により
定義されたフィールドを参照することにより、「姓名はＪｏｈｎ Ｓｍｉｔｈ」
というテキストを返す。これらの変数は、変数：＝ｆｉｅｌｄＡｔ（パラメータ
、「列名」）の形式に従って定義され、列４８７に示すような返答ステートメン
トにおいて参照され得る。

【０１５１】 （レコードコンテンツ） 上述したように、所与の行は、あらゆる列の数値を含み得る。しかし、レコー
ドにより用いられ得る列全てを判定する際、あらゆる可能な列を入念に調べる必
要がある。この問題を避けるため、好適な実施形態において、図１５に示す表４
０９は、その列中の特定のレコードに格納値が含まれていることを示す「レコー
ドコンテンツ」列を含む。

【０１５２】 図２０は、特定のレコードの数値を含む列に対応するポインタを含む「レコー
ドコンテンツ」列４２７を有する表４０９を示す。例えば、行４１０の「レコー
ドコンテンツ」４２７は、列４２３および列４２５に対応するポインタを有する
が、行４１０は列４１５の数値を持たないため、列４１５に対応するポインタを
有さない。上述したように、各列はその列を定義する対応行を有するため、「レ
コードコンテンツ」列４２７は、定義行４２８を有する。あらゆるセルと同様に
、レコードコンテンツを含むセルは、バージョン変更でき、レコードのバージョ
ン変更を行う能力を提供する。

【０１５３】 （フォルダ） 情報管理をより効率化するために、表４０９は、フォルダとして定義された種
類のデータを含み得る。図２１は、「親フォルダ」列４９０および「子フォルダ
」列４９２を含むフォルダの構造を示す。フォルダは、対応するレコードを有す
る。例えば、図１０に示すように、「連絡」という名称のフォルダは、対応する
行４９４を有する。「連絡」フォルダの「子フォルダ」列４９２は、そのフォル
ダに属するレコードに対応するポインタを含む。同様に、フォルダに属するレコ
ードは、そのフォルダに対応するポインタを「親フォルダ」列４９０に含む。

【０１５４】 特定のレコードは、あらゆる数のフォルダに属することができる。

【０１５５】 図２１に示すフォルダ構造は、サーチを容易にする。上述したように、列の定
義中に規定されているフォルダに従って、列をサーチできる。フォルダをサーチ
する際、システムは、そのフォルダに対応するレコードにアクセスし、そのフォ
ルダに対応するレコード全てをサーチする。

【０１５６】 さらに、上述した同期化機能は、フォルダ中にアイテムのリストを生成するの
にも用いられ得る。例えば、図２１において、「親フォルダ」および「子フォル
ダ」列が同期化され得る。レコード４２１の「親フォルダ」フィールド４９０Ａ
が行４９４により示される「連絡」フォルダと関連するように設定されている場
合、「連絡」フォルダ（「子フォルダ」）中のアイテムのリストが自動的に更新
され、そのＯＩＤ１１０１を「子フォルダ」列４９２に含むことにより、行４２
１により表されるレコードへの相互関連が格納される。

【０１５７】 （自動フォルダ） フォルダのコンテンツを自動的に定義するよう、特定のフォルダを定義する。
このフォルダは、定義の種類に応じて「インデックス」フォルダまたは「クエリ
」フォルダという。インデックスフォルダは、特定のフィールド中に有効な数値
を含むレコード全てを含む。

【０１５８】 例えば、「人」フォルダは、「Ｐｅｒｓｏｎ」の種類のレコード全てを自動的
に含むように定義され得る。

【０１５９】 さらに、これらの定義をより複雑な定義（照会と呼ばれる）として組み合せる
ことができる。このようなフォルダの例としては、ａ）「Ｐｅｒｓｏｎ」の種類
のレコード全てを自動的に含み、ｂ）「Ｃａｌｉｆｏｒｎｉａ」という単語を含
むフォルダがある。

【０１６０】 このような自動フォルダは、ユーザからの明示的アクションを要することなく
目的となるレコードを自動的に補充および分類することにより、システムの利用
を容易にする。

【０１６１】 （テキストインデックス化システム） 本発明は、表４０９中のあらゆるセルに含まれるテキストを高速にサーチする
インデックス化システムを含む。各キーフレーズがセルから抽出され、所定の階
層に従ってリスト形式で格納される。例えば、リストはアルファベット順であり
得、特定の姓名を非常に高速でサーチする。

【０１６２】 図２２は、表４０９からリスト４９５へのテキスト抽出を示す。分かり易くす
るためにリスト４９５を表４０９と別個に示しているが、本発明のこの好適な実
施形態において、リスト４９５は表４０９の一部を為す。リスト４９５は、セル
識別番号（例えば、リスト中の各単語に対するセル識別番号４９５Ａ）を格納し
、セル識別番号は＜ｒｅｃｏｒｄ ＯＩＤ、ｃｏｌｕｍｎ ＯＩＤ＞の形式であ
り得る。例えば、「Ｖｅｎｔｕｒａ」という単語が、異なる行および異なる列に
該当するセル４９６、４９７および４９８に発生している。リスト４９５中の「
Ｖｅｎｔｕｒａ」という単語は、セル４９６、４９７、および４９８に対してポ
インタまたはセル識別番号を含む。

【０１６３】 同様に、各セルは、アンカーを用いて、キーフレーズに対する関連をセル内部
に格納する。図２３に示すように、アンカーは、場所（例えば、テキストの開始
部分および終了部分のオフセット）および識別番号を含む。テキストおよびアン
カーの両方がセル４９６に格納される。他の種類のドメインもアンカーをサポー
トする。例えば、グラフィカル画像は、アンカーがグラフィカル画像上のポイン
ト上に位置決めされている「ｈｏｔ ｓｐｏｔ」の概念をサポートする。

【０１６４】 上述したように、各キーフレーズは、レコードとしてデータベースに格納され
、レコードのＯＩＤは図２３を参照して述べた識別番号と等しい。列の中には、
キーフレーズとして姓名を格納するものあれば、キーフレーズを含むセル識別番
号のリストを格納するものもある。キーフレーズは、やはりインデックス化が可
能な独自のコメントを有し得る。

【０１６５】 図２２に示すように選別されたリスト４９５は、図２４に示すようにフォルダ
として格納される。セル識別フィールド４９１は、該当レコードに対応する用語
を含むセルを維持する。リスト４９５上の各用語に対する「親フォルダ」列４９
０は、その親フォルダが「Ｎａｔｕｒａｌ」というタイトルを有するインデック
スであることを示す。「Ｎａｔｕｒａｌ」フォルダは、リスト４９５中の用語全
てに対応するポインタを「子フォルダ」列４９２中に有する行４９９を有する。

【０１６６】 この「Ｎａｔｕｒａｌ」フォルダは、特定の種類のアルゴリズムにより選別さ
れたインデックスに対応する。コンピュータプログラムは一般的には、標準的な
照合シーケンス（例えば、ＡＳＣＩＩ）を用いて選別を行う。本発明は、この種
類の選別を改善し、改善された選別技術が「Ｎａｔｕｒａｌ」フォルダに対応す
る。「Ｎａｔｕｒａｌ」フォルダ中のレコードは、以下の規則に従って選別され
る： １）リスト中、１つ以上のポイントでキーフレーズが発生し得、特に、 １ａ）各順列において、キーフレーズが並び替えまたは格納され得る。例え
ば、「Ｊｏｈｎ Ｓｍｉｔｈ」は、「Ｊｏｈｎ」に基づいてあるいは「Ｓｍｉｔ
ｈ」に基づいて格納できる。順列中の「ａ」および「ｔｈｅ」のようなノイズ的
単語は無視される。

【０１６７】 １ｂ）数値または日付に関するキーフレーズは、各可能な場所に格納され得
る。例えば、「１９８４」は、ディジット「１９８４」に基づいて、「Ｏｎｅ
ｔｈｏｕｓａｎｄ， ｎｉｎｅ ｈｕｎｄｒｅｄ…」に基づいて、あるいは「ｎ
ｉｎｅｔｅｅｎ ｅｉｇｈｔｙ ｆｏｕｒ」に基づいて格納できる。

【０１６８】 ２）数字を自然に選別する。例えば、「２０」は、「３」の後にきて、「１０
０」の前にくる。

【０１６９】 ３）キーフレーズ中の接頭辞は無視する。例えば、「Ｔｈｅ Ｂｉｇ Ｏａｋ
」は「Ｂｉｇ」に基づいて選別される。

【０１７０】 ４）キーフレーズを語幹化して、「Ｃｏｍｐｕｔｅｒｓ」および「Ｃｏｍｐｕ
ｔｉｎｇ」を同一のキーフレーズレコードにマッピングする。

【０１７１】 以下は、キーフレーズを「Ｎａｔｕｒａｌ」フォルダに入力する場所を生成す
るためのルーチンの好適な実施形態である： １）場合によって感度が変わる問題を回避するため、キーフレーズを大文字に
する。例えば、「Ｊｏｈｎ Ｓｍｉｔｈ ｔｈｅ １ｓｔ」は「ＪＯＨＮ ＳＭ
ＩＴＨ ＴＨＥ １ＳＴ」となる。

【０１７２】 ２）キーフレーズ中の各単語を標準的な技術を用いて語幹化する。例えば、「
ＣＯＭＰＵＴＥＲＳ」は「ＣＯＭＰＵＴ」となる。

【０１７３】 ３）キーフレーズを並び替えて、オリジナルのキーフレーズに基づいた複数の
キーフレーズを新しく１組作成する。例えば、「ＪＯＨＮ ＳＭＩＴＨ ＴＨＥ
１ＳＴ」から、｛「ＪＯＨＮ ＳＭＩＴＨ ＴＨＥ １ＳＴ」、「ＳＭＩＴＨ
ＴＨＥ １ＳＴ ＪＯＨＮ」、「ＴＨＥ １ＳＴ ＪＯＨＮ ＳＭＩＴＨ」、
「１ＳＴ ＪＨＯＮ ＳＭＩＴＨ ＴＨＥ」｝からなる組ができる。

【０１７４】 ４）ノイズとなる接頭辞を除去する。上記の例の場合、第３のエントリ「ＴＨ
Ｅ １ＳＴ ＪＯＨＮ ＳＭＩＴＨ」を除去する。除去した後にフレーズが残っ
ていない場合、オリジナルのフレーズを用いる。例えば、「ＴＯ ＢＥ ＯＲ
ＮＯＴ ＴＯ ＢＥ」のエントリは、ノイズ的単語を全て除去した後でも保存さ
れる。

【０１７５】 ５）各結果について、数字および日付を全ての可能なテキスト表示に拡張し、
テキスト表示を数値に変換する。例えば、｛「１ＳＴ ＪＯＨＮ ＳＭＩＴＨ
ＴＨＥ」から、「１ＳＴ ＪＯＨＮ ＳＭＩＴＨ ＴＨＥ」および「ＦＩＲＳＴ
ＪＯＨＮ ＳＭＩＴＨ ＴＨＥ」｝の組ができる。

【０１７６】 ６）最後に、各変更されたキーフレーズを用いて主要キーフレーズレコードに
対する関連位置を決定し、その結果に従ってフォルダ中にエントリを作成する。
例えば、「１ＳＴ ＪＯＨＮ ＳＭＩＴＨ ＴＨＥ」は、「１」と「２」との間
に格納され、「ＦＩＲＳＴ ＪＯＨＮ ＳＭＩＴＨ ＴＨＥ」は、「ＦＩＲ」の
後かつ「ＦＩＳ」の前に格納される。

【０１７７】 図３３Ａは、従来技術による選別アルゴリズムの結果を示し、図３３Ｂは、本
発明による選別アルゴリズムの結果を示す。

【０１７８】 （キーフレーズの抽出） 本システムでは、選別したリストを生成するために、適合するセルからキーフ
レーズまたは単語を先ず抽出する必要がある。キーフレーズ抽出では多様な組み
合せを用いることができる。

【０１７９】 テキストを完全に抽出する場合、各単語をインデックス化し、これは、標準的
なテキスト検索システムの場合には典型的である。列について抽出する場合、標
準的なデータベースシステムに対応する列の全コンテンツをインデックス化する
。第３の種類の抽出方法である自動解析に従って、フレーズのマッチング、意味
的コンテキスト、および他の要素に基づいてテキストのコンテンツを解析し、キ
ーフレーズを抽出する。最後に、手作業による選択抽出において、ユーザまたは
アプリケーションは、キーフレーズに明示的に印を付けてインデックス化する。

【０１８０】 自動解析を用いると、セル中のテキストが変更される度に、「キーフレーズ」
アンカーが自動的に更新されるため、データが変わるたびに手作業でセルをリン
クさせる必要がなくなり、有利である。

【０１８１】 （フィールドを用いたテキストのインデックス化のサポート） 各フィールドは、それぞれ独自のフィールド定義を有するため、フィールドの
テキストをどのようにインデックス化するかを定義することができる。例えば、
「苗字」フィールドを解析して全コンテンツを重要と見なしてインデックス化す
る一方、「電話」フィールドを解析して全コンテンツを重要ではないと見なして
インデックス化を行わなくすることができる。

【０１８２】 構造化した情報とテキストとを組み合せると、レコード中の各セルに対して様
々な組み合せのキーフレーズの抽出を様々に用いることができ、、ユーザは最適
な組み合せを選択することができる。特に、キーフレーズに基づいて、特定フィ
ールド中のデータに対するリンクをユーザの干渉なく自動的に生成することがで
きるよう、フィールドを定義することができる。

【０１８３】 （リンクをデータベースに格納する利点） データベースのマテリアル（ｄａｔａｂａｓｅ ｍａｔｅｒｉａｌ）を発行す
るには、データアイテム間にリンクを設ける必要がある場合が多い。従来からリ
ンクはデータとは別に保管されてきたため、マテリアルを発行する準備をするた
びにデータアイテム間を再度リンクさせる必要がある。本発明は、リンクをデー
タと一緒に格納して、リンクを自動更新することにより、２つの手順を不要とす
る。これは、リンクをサポートするが維持が困難な形式（例えば、ハイパーテキ
ストマークアップランゲージ、ＨＴＭＬ）で発行する場合に特に有用である。さ
らに、このデータベースシステムは、リンクを用いた多様な種類のデータ形式を
生成する１つのレポジトリ用に用いることができる。

【０１８４】 （日付インデックス化システム） 日付インデックス化スキームは、上述したテキストインデックス化スキームに
非常によく似ている。重要日付がテキストから抽出され、「重要日付」リストに
追加される。各重要データは、「重要日付」レコードにより表示される。「重要
日付」レコードは、日付別に選別される「重要日付」フォルダに格納される。

【０１８５】 重要日付は、テキストから抽出される。本システムは、数値的日付（例えば、
「４／５／９４」）または日付に関するテキスト（例えば、「Ｔｏｍｏｒｒｏｗ
」、「ｎｅｘｔ Ｔｕｅｓｄａｙ」または「Ｃｈｒｉｓｔｍａｓ」）をサーチし
得る。図３４は、図１５の表のセルと選別された日付インデックスとの間の対応
を示す。

【０１８６】 ＯＩＤはあらゆるシステムにおいて常に同一の識別性を有するため、重要日付
レコードに所定の特別なＯＩＤが割り当てられる。所定のＯＩＤを日付に割り当
てると、重要日付をシステム間で共有することが可能となる。所定のＯＩＤは、
重要日付を示すＯＩＤであることを意味する特殊なセッション識別番号を用いる
ことにより生成される。その場合、タイムスタンプは、重要日付が生成された時
間ではなく重要日付そのものの値を表す。

【０１８７】 （関連クエリ） 上述したように、選別されたキーワードリストは、テキストからセルおよびテ
キストセルにレコードが対応するフォルダ中に格納されたリストとして生成され
る。テキストを含むセルはキーワードに対応するため、テキストを有するレコー
ドのリストとキーフレーズのリストとの間の関連は双方向の関係である。図２５
は、この双方向の対応を示す。各レコードは複数のキーフレーズに対応でき、各
キーフレーズは複数のレコードに対応できる。

【０１８８】 図２６は、レコードとキーワードリストとの間の双方向関連を図にしたもので
ある。各レコード（例えば、複数のレコード５００中のレコード５０１）は、１
つ以上の重要単語エントリ（例えば、単語エントリ５１０）に対応し得る。同様
に、各重要単語エントリは、１つ以上のレコードに対応し得る。１つのレベルの
サーチは、（グラフのどちらかの）１つのノード（例えば、ノード５０２）から
開始し、リンク（例えば、リンク５０４）へと進み、反対側のノード（例えば、
ノード５１２）へと進む。例えば、ユーザが「Ｓｈａｓｔａ」という単語を含む
レコードを見つけたいと考え得、先ず重要単語インデックスにアクセスして、「
Ｓｈａｓｔａ」という単語を見つけ、この単語に対応するレコードを検索する。
矢印５０４および５１３は、このサーチ方法を示し、単語「Ｓｈａｓｔａ」はノ
ード５１２に対応する。同様に、ユーザは、リンク５０４および５０６に示すよ
うに、特定のレコード中に含まれる重要単語全てを配置したいと考え得る。

【０１８９】 サーチは、所望のレベルに到達するまでリンクを前後に繰り返したどることに
より、拡張可能である。図２７Ａは、この概念を示す。一例として、あるレコー
ドでは「Ｓｈａｓｔａ」がＤｏｇとして記載されており、別のレコードでは「Ｓ
ｈａｓｔａ」がＧｅｎｉｕｓとして記載されているため、「Ｓｈａｓｔａ」とい
う用語がずば抜けた頭脳を有するＤｏｇに対応する場合があり得る。ユーザが「
Ｓｈａｓｔａ」と関連する単語を見つけたい場合、システムは、セル５０８すな
わち「Ｓｈａｓｔａ」を「Ｓｈａｓｔａ」という単語を含むレコード（例えば、
レコード５０５および５０７）に対応する「重要単語」フォルダ５０３に配置す
る。すると、「重要単語」に対応するポインタを含むレコード５０５および５０
７は、各インデックス単語をレコードにリスト化する。「Ｓｈａｓｔａ」はレコ
ード中で「Ｄｏｇ」および「Ｇｅｎｉｕｓ」という単語と共に現れるので、これ
らの単語がシステムにより検索される。

【０１９０】 この種類のサーチは、無限に拡張され得る。図２７Ｂは、さらなる程度のサー
チを示す。上記の実施例から引き続いて、「Ｇｅｎｉｕｓ」という単語は、Ｄｉ
ｒａｃと「Ｃｈｅｃｋｅｒｓ」に関連する「Ｄｏｇ」という単語とを参照するレ
コード中に発生し得るため、図２７Ｂに示す複数のレベルのサーチに「Ｓｈａｓ
ｔａ」という単語を与えると、「Ｄｉｒａｃ」および「Ｃｈｅｃｋｅｒｓ」が検
索される。

【０１９１】 各リンクおよびキーワードの種類に関連する重要度に基づいて、相関度ランキ
ングを生成することができ、レコードを相関度の高い順から表示することができ
る。好適な実施形態において、開始ポイントとして２つ以上のノードを用いる場
合、相関度は全ノードからの距離に基づく。このようにして、全ての最初のノー
ドに近いノードのみが高い相関度を有することになる。距離を用いない別の多く
の相関度ランキングも用いられ得る。

【０１９２】 サーチを高精度にするため、追従するリンクを制限するためにフィルタを用い
ることができる。例えば、サーチは、「Ｐｅｒｓｏｎ」の種類のみがリストされ
るようにフィルタリングされ得るため、上記の実施例ではＳｈａｓｔａはＣｈｅ
ｃｋｅｒｓではなくＤｉｒａｃと関連付けられる。

【０１９３】 （知識ベースおよびシソーラス） 本発明の好適な実施形態は、サーチ能力をさらに増強する知識ベースおよびシ
ソーラスを含む。

【０１９４】 シソーラス中に含まれる各重要単語レコード（用語）は、「概念」レコードに
対応するポインタを含む。各概念レコードは、別の概念レコードと各概念の境界
内に含まれる用語とに対応するポインタを含む。図２８は、シソーラスの構造を
示す。表４０９は、「親概念」列５２２、「概念名」列５２４、「シノニム」列
５２６、「より詳細な用語」列５２８、「より一般的な用語」列５３０および「
参照」列５３２を含む。概念レコード５２０は「ＩＢＭ」という概念を定義し、
シノニム列５２６は、ＩＢＭと同義のレコードと、「ＩＢＭ」という値の付いた
ラベルフィールドを有するレコード５２１と、「Ｉｎｔｅｒｎａｔｉｏｎａｌ
Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ」という値の付いたラベルフィールドを有
するレコード５２３とに対応する。レコード５２１および５２３は、「親概念」
フィールド中に親概念レコード５２０に対応するポインタを有する。

【０１９５】 図２８に示すシソーラス構造は、正確なシノニムよりもさらに高い柔軟性を提
供する。重要度のパーセンテージが最初の用語「ＩＢＭ」と関連用語「ＩＢＭ
ＰＣ」との間の類似性を反映する場合に１００％の重要度を割り当てると、「Ｉ
ＢＭ」と関連する概念レコード５２０の「より詳細な用語」列５２８は、ＩＢＭ
と関連する概念レコード５２５に対応する。同様に、６０％の重要度を割り当て
ると、「ＩＢＭ」と関連する概念レコード５２０の「より一般的な用語」列５３
０は、コンピュータ会社と関連する概念レコード５２７に対応する。重要度のパ
ーセンテージが最初の用語「ＩＢＭ」と関連用語「ＩＢＭ ＰＣ」との間の類似
性を反映する場合に７０％の重要度を割り当てると、「参照」列５３２は、「Ｍ
ｉｃｒｏｓｏｆｔ」という概念と関連するレコード５２９に対応する。

【０１９６】 図２８に示すシソーラスは、図２５〜２７Ｂを参照して前述したサーチメカニ
ズムを増強する。本システムでは、先ずキーワードに関連するレコードを見つけ
、そのキーワードに対応する親概念レコードを見つけ、次いで列５２６、５２８
、５３０、および５３２中のポインタのいくつかまたは全てをたどり、「概念名
」列５２４中に格納されているＯＩＤを戻す。

【０１９７】 本システムではキーフレーズおよび概念をレコードとして格納するため、シス
テム中に格納する知識および情報を拡張するために他のあらゆる列が用いられ得
る。特に、ＯＩＤの使用を通じて、本システムは、類義語的関係以外の関係を含
む、キーフレーズ、概念、および他のレコード間のあらゆる種類の関係を格納す
ることができる。

【０１９８】 （アプリケーションサポート） 本発明のデータベースについて、本発明を主要格納および検索システムとして
用い得るアプリケーションとのインターフェースについて言及することなく説明
をしてきた。図１４を参照して前述したように、本発明のデータベースは、アプ
リケーションプログラムをサポートするインターフェースを含む。アプリケーシ
ョンサポートシステム中の構成要素としては、外部文書サポート、ハイパーテキ
スト、文書管理およびワークフロー、カレンダー機能およびスケジューリング、
セキュリティおよび他の機能がある。

【０１９９】 さらに、本発明は、本発明のデータベース構造へのフルアクセスを提供するよ
う開発されてきた様々なユーザインターフェース構成要素を含む。特に、新しい
種類の構造化されたワードプロセッサが提示される。本明細書は、アプリケーシ
ョンサポートシステムの各構成要素について別々に説明する。

【０２００】 （外部文書） 本発明は、外部文書のインデックス化をサポートする。ファイルのコンテンツ
がデータベース中に直接格納されていない場合、表４０９は文書（例えば、ワー
ドプロセッサ文書等）のファイル名を格納する。ファイルの内容はデータベース
に直接格納されない。文書名は、専用の「外部文書」ドメインを有する列中に格
納され得る。外部文書は、デバイス制御３６を通じてシステムとインターフェー
スをとる大容量メモリ３２またはマルチソース中に存在し得る。

【０２０１】 表４０９の外部にある文書をインデックス化する際、外部文書を処理前に単純
なテキスト形式に変換する。次いで、前述したようにキーフレーズを抽出する。
特に、テキスト中のフィールドを決定してデータベース中のフィールドにマッピ
ングすることができる。例えば、「Ｍｅｍｏ」文書は、「Ｔｏ： Ｊｏｈｎ Ｓ
ｍｉｔｈ． Ｆｒｏｍ： Ｍａｒｙ Ｄｏｅ」といったテキストを含み得る。こ
のテキストは、「ｔｏ」および「ｆｒｏｍ」と呼ばれるフィールドにマッピング
でき、マッピングに応じてこれらのフィールドの値を設定することができる。こ
のようなテキスト解析は、異なる種類の外部文書（例えば、メモ、法律文書、表
計算、コンピュータソースコード、および他のあらゆる種類の文書）用に変更す
ることができる。抽出されたキーフレーズの各々について、テキスト中の開始ポ
イントおよび終了ポイントが決定される。前述した形式のアンカーのリスト（開
始、終了、キーフレーズ）がパーサーにより生成され、外部文書ドメイン下の表
４０９中に格納される。

【０２０２】 （外部文書の閲覧） ユーザが外部文書を表示画面３７上で閲覧する場合、格納されているアンカー
が文書上にオーバーレイされ、これにより外部文書は、ハイパーテキストで印を
付けられているように見える。ユーザが外部文書表示の一部分上をマウス５０の
スイッチ４５または４７でクリックすると、様々な開始座標および終了座標から
対応するアンカーが決定される。アンカーに対応するキーフレーズのＯＩＤは、
アンカー中に格納され、キーフレーズレコードを検索したり、または前述したよ
うにクエリを開始したりするのに使用することができる。

【０２０３】 （ダイナミックハイパーテキスト） 本発明は、従来のハイパーテキストをサポートする。従来のハイパーテキスト
システムは典型的には、図２９に示すように、テキスト領域と別のレコードに対
応するポインタとを関連付ける。これにより、ソースとターゲットとの間に「ハ
ードコードされた」リンクが生成される。ユーザがソース領域をクリックすると
、ターゲットレコードがロードされ、表示される。ターゲットレコードが無い場
合、ハイパーテキストジャンプは行われず、深刻な結果となり得る。

【０２０４】 本発明のシステムは、レコード間のダイナミックな関連に基づいた新しいアプ
ローチを用いる。好適な実施形態において、各ハイパーテキスト領域（例えば、
領域５４０）は、通常のレコードではなくキーフレーズと関連付けられる。ユー
ザがソース領域５４１上をマウス５０のスイッチ４５または４７でクリックする
と、キーフレーズに関連するレコード５４２全てが検索され、前述した関連のサ
ーチ技術のうち任意のサーチ技術を用いてランク付けされる。次いで、図３０に
示すように、アプリケーションは、表示画面３７上に最高ランクのアイテム（例
えば、アイテム５４３）かまたは検索されたアイテム全てのいずれかを表示する
ことができ、ユーザがアクセスしたいアイテムを選択することを可能にする。

【０２０５】 特定のアプリケーションにおいて、ユーザは、１つの「デフォルト」アイテム
（例えば、アイテム５４３）にアクセスしたいと考え得る。このアイテムは、ダ
イナミックに生成されたリストの最上位のアイテムを選択することにより自動的
に決定するか、またはユーザがそのアイテムを明示的に選択してその選択をアン
カー自体に保存することにより手動で決定することができる。

【０２０６】 （注釈） 本発明のデータベースは、既存のレコードに「注釈」フィールドを追加するか
またはオリジナルのレコードに対応する「注釈」レコードを新しく生成すること
により、あらゆるレコードに注釈およびコメントを付け加える能力を含む。従来
技術の注釈付けメカニズムとは異なり、本発明の注釈付けメカニズムは、データ
ベース中に完全に統合され、インデックス化、ハイパーテキストの適用、フォル
ダへの配置等の用途に利用可能である。

【０２０７】 （一般的なワードプロセッサ） 本発明のデータベースは、表４０９と共に用いられ得る新規な構造のワードプ
ロセッサを含む。

【０２０８】 本発明のこの構造化されたワードプロセッサは、Ｄｏｎａｌｄ Ｋｎｕｔｈに
よりＴＥＸに導入された「ボックスおよびグルー（ｂｏｘｅｓ ａｎｄ ｇｌｕ
ｅ）」パラダイムを用いる。このパラダイムによれば、テキストのページは、個
々の文字から開始して文字を連結して「ボックス」と呼ばれるより大きな単位を
形成し、これらのボックスをさらに大きなボックスに組み合せることにより生成
される。図３１Ａは、単語ボックス５５０を形成するように連結された３つの文
字ボックス５５１、５５３、および５５５を示す。図３１Ｂは、水平ラインボッ
クス５５７を形成するように結合された４つの単語ボックス５５２、５５４、５
５６、および５５０を示す。水平ボックスは、別のボックス内部で水平方向に間
隔をおいて配置された単語または他のテキストトークン（例えば、ライン（また
は列幅））用に用いられる。図３１Ｃは、水平ラインボックス５５７と別の水平
ラインボックス５５９とを組み合せて垂直ボックス５５８を形成したものを示す
。垂直ボックスは、別のボックス中に垂直に間隔をおいて配置されるパラグラフ
または他のオブジェクト（例えば、ページ高さ）用に用いられる。

【０２０９】 ボックスは、「グルー」を用いて他のボックスにアタッチされ得る。グルーは
、必要に応じて延伸または収縮可能である。例えば、位置揃えされた文章におい
て、単語間の余白が延伸され、これにより単語は列の適切な端部に整列するよう
になる。グルーは、（水平方向の）文字間間隔、タブマークに「付着する」「タ
ブ」グルーを含む（水平方向の）単語間間隔用に使用可能である。グルーはまた
、（垂直方向の）行間間隔および（垂直方向の）パラグラフ間間隔用にも使用可
能である。

【０２１０】 表４０９のレコードが編集される際、各単語およびフィールド定義は、ボック
スに変換される。図３２に示すように、本システムは、これらのボックスを木構
造のラインボックスおよびパラグラフボックスに編成する。図示しているのは、
レコードの階層に対応するレコード構造階層５６０およびレイアウトの階層に対
応するレイアウト階層５７０（例えば、図３１Ａ〜３１Ｃを参照して説明したワ
ードプロセッサにより生成された文書等）である。レコード階層５６０は、表４
０９のレコード構造を表し、レコード５６２は、表４０９中の行に対応し、表４
０９の列に対応する属性５６４を含む複数の属性を含む。次に、これらの属性は
、多様なアイテムを含み得る。例えば、属性５６４は、図示されるようにブロッ
ク５６６により表されるテキストと、ブロック５６８により表されるフィールド
リファレンスと、他のアイテムとを含む。

【０２１１】 次に、レイアウト階層５７０は、複数のページ（例えば、ページ５７４）を含
む文書５７２を含む。 ページ５７４は、パラグラフ５７６および５７８を含む
複数のパラグラフを含み、パラグラフ５７６は、ライン５７７および５７９を含
む複数のラインを含む。パラグラフ５７８はライン５７９を含む。

【０２１２】 本発明のワードプロセッサは、レコード構造階層５６０およびレイアウト階層
５７０の両方に共通であるボックス５６５、５６７、および５６９を含む複数の
ボックスを提供することにより、文書５７２をレコード５６２に挿入することを
可能にする。例えば、ボックス５６５は、ライン５７７の一部に対応し、属性５
６４のテキスト５６６の一部を含む。同様に、ボックス５６７はライン５７９の
一部に対応し、ブロック５６８に示すようなフィールドリファレンスを含み得る
。従って、図３２に示すような共用ボックス構造を用いれば、あらゆる種類のワ
ード処理文書と表４０９中のあらゆるレコードとの間にインターフェースを設け
ることができる。

【０２１３】 概念的には、各ボックスは、ビットマップとして保管され、その高さおよび幅
は既知であるので、本システムは、木構造中のボックスに対応するビットマップ
全てを表示することにより、木構造５７１を表示する。例えば新しく単語を追加
などすることにより、木構造が変化すると、新しい単語ボックスおよび比較的少
数の隣接ボックスのみを再計算すればよい。同様に、ライン区切りすなわちパラ
グラフの再構造があっても、ほとんどの単語ボックスは影響を受けずに再使用さ
れ、ラインボックスのみを再計算すればよい。図３２に示すような木構造５７１
を編集するため、ユーザはテキストの一部上でカーソルをクリックし得る。本シ
ステムは、木構造５７１中を反復的な降順で、編集される単語ボックスまたはグ
ルーを配置する。

【０２１４】 ワードプロセッサは、複数のフォントおよび特殊効果（例えば、下付き文字、
ドロップキャップ、およびグラフィックオブジェクトを含む他の機能）をサポー
トする。基本フォントと異なるフォントの単語は、異なるボックス中にあり、ラ
イン上の他のボックスと異なる高さを有し得る。ラインボックスの高さは、その
ラインボックス中で最大の単語ボックスの高さである。単語中の効果は、単語を
グルーを介在させずに下位ボックスに分割することにより処理できる。ここでも
、単語ボックスの高さは、単語ボックス中の最大のボックスの高さである。ビッ
トマップ等のグラフィックオブジェクトは、固定幅のボックスとして処理および
フォーマットされ得る。

【０２１５】 本発明のワードプロセッサは、表４０９中のレコードを編集するために用いら
れ得る。レコード中の各フィールドに関連するテキストは、フィールド間間隔、
フィールド中でのテキストフロー、および他のフォーマット化パラメータの目的
のための「パラグラフ」として見なすことができる。テキスト編集中に全フィー
ルドを同じ方法で格納すれば、テキストの動きおよび「フロー」を自然に見せる
ことができる。

【０２１６】 上述したように、編集対象のテキストはフィールドに分割され、各フィールド
は基本であるデータベース中の列に対応する。従来のスタティックデータエント
リフォームとは異なり、属性の位置およびサイズは一定ではなくダイナミックで
あり、レコードフィールドを編集する際、ワードプロセッサの全機能（例えば、
フォント、埋め込みグラフィック等）が利用可能である。

【０２１７】 同様に、このワードプロセッサでは、データベースの全機能（例えば、ルック
アップおよびメールマージ等）が利用可能である。特定のフィールドのデータエ
ントリに適合する属性全てが、このワードプロセッサにより実施される。このよ
うな属性は、マスク（例えば、＃＃＃−＃＃＃＃）、存在要件、範囲および数値
に関する制約等を含み得る。フィールドは、明示的にラベル付けもでき、あるい
は隠蔽および暗示も可能である。

【０２１８】 本発明のワードプロセッサは、フィールド名の接頭辞をタイプしてボタンを押
すことにより、現存するフィールドに追加を行うことを可能にする。次いで、本
システムは、残りのフィールド名を自動的に補完する。

【０２１９】 本発明のワードプロセッサは、他のデータベース機能をサポートする。例えば
、ユーザは、ポップアップダイアログボックスを用いることにより、新しいフィ
ールドを生成することができる。同様に、他のレコードへの関連または重要単語
もダイアログボックスにより追加可能である。特に本発明の表４０９に関して、
ＯＩＤリファレンスは、別のフィールド中のフィールドをサポートし得、別のフ
ィールド中の特定のフィールドは、テキスト中に埋め込まれたフィールドレファ
レンスのリストである「テンプレート」の使用をサポートする。例えば、「Ｅｎ
ｔｅｒ ｔｈｅ ｆｉｒｓｔ ｎａｍｅ ｈｅｒｅ ＜ｆｉｅｌｄｒｅｆ ｉｄ
＝ｆｉｒｓｔＮａｍｅ＞ａｎｄ ｔｈｅ ｌａｓｔ ｎａｍｅ ｈｅｒｅ＜ｆｉ
ｅｌｄｒｅｆ ｉｄ＝ｌａｓｔＮａｍｅ＞」というテンプレートは、ユーザには
「Ｅｎｔｅｒ ｔｈｅ ｆｉｒｓｔ ｎａｍｅ ｈｅｒｅ： Ｊｏｈｎ ａｎｄ
ｔｈｅ ｌａｓｔ ｎａｍｅ ｈｅｒｅ： Ｄｏｅ．」と見える。テンプレー
トを用いると、ユーザは、複雑なフォーム描画ツールを用いなくてもダイナミッ
クフォームを容易かつ短時間に作成することができる。

【０２２０】 あらゆる組み合せのフィールドまたはレイアウトは、名前を付けてテンプレー
トとして保存および再使用可能である。このようなテンプレートは、フィールド
のフォーマットおよびレイアウト全てを保管するが、実際のフィールドデータ自
体は含まず、その代わりワードプロセッサ中のデータ用のプレースホルダとして
機能する（上述したような）空フィールドリファレンスを含む。

【０２２１】 本発明のワードプロセッサのユーザインターフェースを用いると、ユーザは、
２つのデータ入力モードを切り替えることができる。本発明のワードプロセッサ
は、１つのレコードへの入力を一度に自在に行うために用いられ、一方、列表示
は、データを列に入力するために用いられる。ユーザは、これらの２つの表示間
をデータ損失無く切り換えて往復することができ、ワードプロセッサから列表示
に切り換わると、１つのアイテムに入力されたフィールドは、列表示に表示され
る列になる。

【０２２２】 最後に、ワードプロセッサ表示に現れている「フィールド中のフィールド」は
、列表示中の列に分割される。すると、ユーザは、列モードで変更することがで
きるようになり、再び切り換えてワードプロセッサ表示に戻ると、列が再度組み
合わされる。

【０２２３】 （構造化ｅメール） 本発明の特定の用途は、「構造化された」ｅメールの生成、自動インデックス
化、編成および検索をサポートすることである。構造化ｅメールは、メッセージ
の本文中にフィールドおよび他の構造情報を格納する従来のｅメールを改変した
ものである。上述したように、本発明は、ワードプロセッサおよびテンプレート
の使用を通じて、ｅメールに必要なデータを自在に入力することをサポートし、
このようなｅメールの管理工程、インデックス化工程、および検索工程に本明細
書中に説明した利点全てを提供する。

【０２２４】 １９９５年２月３日に出願された、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔ
ｕｓ ｆｏｒ ａ Ｐｈｙｓｉｃａｌ Ｓｔｏｒａｇｅ Ａｒｃｈｉｔｅｃｔｕ
ｒｅ ｆｏｒ ａ Ｓｈａｒｅｄ Ｆｉｌｅ Ｅｎｖｉｒｏｎｍｅｎｔ」という
名称の本出願と同時係属中の特許出願第０８／３８４，７０６号に記載されてい
る分散型格納システムおよびｅメール転送（例えば、Ｓｉｍｐｌｅ Ｍａｉｌ
Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ、ＳＭＴＰ）と共に用いると、本発明は
、ｅメールの有利なインプリメンテーションを提供する。

【０２２５】 （パスワード） 特定のデータアイテムへのアクセスを特定のユーザに限定しなければならない
場合がよくある。これらの限定を適用するために、情報管理システムは、アクセ
スを要求するユーザの同一性を判定する必要がある。同一性判定は、現在２種類
の方法で行われており、１つの方法としては、ユーザからのリクエスト情報の使
用について独自の特性を物理的に測定する方法があり、もう１つの方法としては
、現行のほとんどの情報管理システムが依存している「パスワード」を用いる方
法がある。しかし、パスワードシステムに関するセキュリティの問題を回避する
ために、以下の３つのガイドラインをパスワードに適用する： ａ）システムに侵略する者は、力ずくのアプローチおよびパスワードを類推す
る辞書を用い得るので、パスワードを作成するのに一般的な言葉は用いるべきで
はない。

【０２２６】 ｂ）パスワードは、短いよりも長くあるべきである。

【０２２７】 ｃ）パスワードを頻繁に変更して、パスワードが盗まれた場合にでも、パスワ
ードが長期間有効にならないようにすべきである。

【０２２８】 最後に、パスワードは、決して何かに書き留めたり、ログインスクリプトに埋
め込んだりするべきではなく、常時双方向であるべきである。

【０２２９】 本発明のパスワードシステムによれば、ユーザの同一性は、広範囲にわたる質
疑応答のやり取りを通して判定される。特定の個人的な質問に対する応答は、ユ
ーザの同一性を非常に正確かつ短時間で確認する。質疑応答が続くうちに、いか
に精巧な模倣者でも、最後には正確に応答することができなくなる。

【０２３０】 例えば、質問の例としては、「朝食のシリアルであなたの好みのものはなんで
すか？」； 「１９９０年４月にあなたはどこにいましたか？」； 「あなたの
歯ブラシの色は何色ですか？」などがある。これらの質問は広範囲に亘っており
、模倣は困難である。さらに、正しい応答は、非常に大きな解空間を伴う自然な
英語の文章で行われるため、力ずくのアプローチが成功することはまず無い。

【０２３１】 応答の有効性を高めるのにユーザの応答と格納された回答とを正確にマッチン
グする必要は無く、本発明のシノニム、シソーラスおよび他の機能に従って「フ
ァジー」および「関連」マッチングを用いることができる。

【０２３２】 本発明のパスワードシステムによれば、ユーザは、質問リストおよび対応する
回答を作成し、このリストは格納される。ユーザは、これらの質問を完全に把握
しているので、質問および回答を作成するプロセスを楽しいと感じ得、その結果
、質問および回答リストを頻繁に変更し得、システムのセキュリティがさらに増
強される。

【０２３３】 好適な実施形態によれば、ユーザは、５０〜１００の質問および回答のリスト
を作成し、このリストは暗号化され、格納される。質問は全て新しいものであり
得、または興味深い質問の大規模データベースに基づき得る。ユーザがシステム
にログオンすると、システムは、ユーザに関連する質問のうち１つをランダムに
選択し、その質問をユーザに提示する。次いで、ユーザは応答をタイプし、その
応答は正しい回答とマッチングされる。マッチングは、上述したようにファジー
または関連を用いて行うことができる。応答が正しくマッチングすると、アクセ
スが許可される。

【０２３４】 別の実施形態において、特定のリスク閾値に達するまで繰り返し質問をするこ
とによりセキュリティがより強固になり得る。例えば、「あなたの歯ブラシの色
は何色ですか？」への回答が「赤」という単語一語である場合は、力ずくの類推
が有効になり得る。このシナリオの場合、質問を繰り返し行うと、力ずくの類推
が成功する確率が低減する。

【０２３５】 特許法の規定に従って本発明を説明してきたが、当業者であれば、その特定の
要件または条件を満たしながら、本発明の変更および改変方法を理解する。

【図面の簡単な説明】

【図１】 図１は、本発明の教示内容を組み込んだ１つの可能なコンピュータシステムを
示す機能的ブロック図である。

【図２】 図２は、クライアント−サーバアーキテクチャにおける本発明のパーティショ
ン構造を示すブロック図である。

【図３】 図３は、図２のパーティション間のリンケージ、およびファイルが１つのパー
ティションから別のパーティションへと転送される様子を示す図である。

【図４Ａ】 図４Ａは、１つ以上のパーティション内に存在することができる追加可能リス
トデータアイテムの構造を示す図である。

【図４Ｂ】 図４Ｂは、１つ以上のパーティション内に存在することができる追加可能テキ
ストデータアイテムの構造を示す図である。

【図５】 図５は、本発明の教示内容によるデータアイテムの読み出しおよび書き込みの
フローチャートである。

【図６】 図６は、ジャーナルパーティションに配置されたファイルをライブラリパーテ
ィションに配置されたファイルへと結合する動作を示す図である。

【図７】 図７は、データを統合ファイルへ書き込むための、本発明の工程の順序を示す
フローチャートである。

【図８】 図８は、統合ファイルを統合するための、本発明の工程の順序を示すフローチ
ャートである。

【図９】 図９は、統合ファイルをライブラリファイルに結合するための、本発明の工程
の順序を示すフローチャートである。

【図１０】 図１０は、好適な実施形態におけるジャーナルパーティションファイルの構造
を示す図である。

【図１１】 図１１は、ジャーナルパーティションに格納されたオブジェクトの構造を示す
図である。

【図１２】 図１２は、ジャーナルファイルからデータアイテムを挿入し、更新し、そして
消去するためのフローチャートである。

【図１３】 図１３は、ジャーナルファイルに格納されたオブジェクトを物理的メモリのブ
ロックにマッピングするテーブルを格納するための、本発明の「センチネル」機
能を示す図である。

【図１４】 図１４は、本発明のメインコンポーネントを示すブロック図である。

【図１５】 図１５は、本発明のデータベースのテーブル構造を示す図である。

【図１６】 図１６は、図１５のテーブルにおけるロウおよびカラムを規定するオブジェク
ト識別番号（ＯＩＤ）を計算する方法のフローチャートである。

【図１７】 図１７は、本発明のカラム同期化機能を示す図１４のテーブルの一部の図であ
る。

【図１８】 図１８は、図１５のテーブルをサーチする方法のフローチャートである。

【図１８Ａ】 図１８Ａは、図１５のテーブルのカラムを同期化するためのフローチャートで
ある。

【図１８Ｂ】 図１８Ｂは、カラムを同期化した結果を示す図である。

【図１９Ａ】 図１９Ａは、１つのカラム内で別のカラムへの参照を示す図である。

【図１９Ｂ】 図１９Ｂは、カラム内で別のカラムへ参照するための代替的実施形態を示す図
である。

【図２０】 図２０は、特定のレコードのうちどのカラムが値を有するかを示す本発明の「
レコードコンテンツ」カラムを示す図である。

【図２１】 図２１は、レコードを編成するフォルダ構造を示す図である。そのフォルダ構
造は、図１５のテーブル内に格納される。

【図２２】 図２２は、図１５のテーブルのセルとソートしたキーワードインデックスとの
間の対応を示す図である。

【図２３】 図２３は、セル内のワードとキーワードインデックスレコードとを関連させる
セル内の「アンカー」を示す図である。

【図２４】 図２４は、図１５のテーブルに格納されたキーワードインデックスレコードを
示す図である。

【図２５】 図２５は、特定のデータレコードとキーワードインデックスレコードとの間の
関連性を示す図である。

【図２６】 図２６は、図２５の関連性をグラフィカル形式で示す図である。

【図２７Ａ】 図２７Ａは、拡張されたサーチをグラフィカル形式で示す図である。

【図２７Ｂ】 図２７Ｂは、さらに拡張されたサーチをグラフィカル形式で示す図である。

【図２８】 図２８は、図１５のテーブルに格納された本発明のシソーラス構造を示す図で
ある。

【図２９】 図２９は、従来技術によるハイパーテキストを示す図である。

【図３０】 図３０は、本発明のハイパーテキスト機能を示す図である。

【図３１Ａ】 図３１Ａは、本発明のワードプロセッサの特徴およびワードボックス構造を示
す図である。

【図３１Ｂ】 図３１Ｂは、本発明のワードプロセッサのワードおよび水平ラインボックス構
造を示す図である。

【図３１Ｃ】 図３１Ｃは、本発明のワードプロセッサの垂直方向のボックス構造を示す図で
ある。

【図３２】 図３２は、本発明のワードプロセッサのボックス木構造を示す図である。

【図３３Ａ】 図３３Ａは、従来技術によるアルゴリズムを選別した結果を示す図である。

【図３３Ｂ】 図３３Ｂは、本発明によるアルゴリズムを選別した結果を示す図である。

【図３４】 図３４は、図１５のテーブルのセルと選別したデータインデックスとの間の対
応を示す図である。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/30 ２４０ Ｇ０６Ｆ 17/30 ２４０Ａ ２４０Ｂ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ， ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，Ｈ Ｕ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ， ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，Ｐ Ｌ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ， ＵＺ，ＶＮ，ＹＵ，ＺＷ

Claims (1)

【特許請求の範囲】
1. 【請求項１】 少なくとも１つのコンピュータを備えるコンピュータネット
   ワーク上の論理表にしたがって構成されたメモリ中にある共通ファイルへの同時
   アクセスを提供する方法であって、 拡張可能な論理表を構成する工程であって、該論理表は、 複数の行であって、各該行は、各該行を同定するためのオブジェクト識別
   番号（ＯＩＤ）を含み、各該行は情報のレコードに対応する、行と、 該複数の行と交差して、基本的な格納単位である複数のセルを規定する複
   数の列であって、各該列を識別するＯＩＤを含む、列と、 を含み、 少なくとも１つの行は、複数のラベル付きの列に関連を有するフィールドセ
   ルを含み、 該少なくとも１つのコンピュータ上の該論理表をパーティション化して、先
   ず、第１のパーティションを第１のユーザに提供して、該第１のユーザに対応す
   るファイルの更新情報を格納し、該論理表は該第２のユーザにとって少なくとも
   部分的にアクセス不可となる、工程と、 該少なくとも１つのコンピュータ上の該論理表をパーティション化して、第
   ２のパーティションを該第２のユーザに提供して、該第２のユーザに対応するフ
   ァイルの更新情報を格納し、該論理表は第１のユーザにとって少なくとも部分的
   にアクセス不可となる、工程と、 該少なくとも１つのコンピュータ上の該論理表をパーティション化して、該
   第１および第２のユーザパーティションから選択された更新情報を格納して第１
   の共通パーティションを作成し、これにより、該第１位および第２のユーザは、
   それぞれ該第１および第２のパーティションを備える関連付けられたパーティシ
   ョンチェインおよび該共通パーティションを有する工程と、 共通データを変更せずに第１のユーザ更新データを該第１のパーティション
   に格納する工程であって、該第１のユーザが更新を行った日付は、該共通データ
   ファイルに対して該第１のユーザが行った変更に対応する、工程と、 共通データを変更せずに第２のユーザ更新データを該第２のパーティション
   に格納する工程であって、該第２のユーザが更新を行った日付は、該共通データ
   ファイルに対して該第２のユーザが行った変更に対応する、工程と、 該第１の共通パーティション中の該第１および第２のユーザパーティション
   から、所望の更新情報を選択的に格納する工程と、 該第１の共通パーティションへのアクセスを該第１および第２のユーザの各
   々に提供する工程と、 を包含する方法。