JPH02297229A - データベース・システム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 光」９ｊ所 本発明は分散型コンピュータ・システムのための文書デ
ータベースに関し、特に電子文書への共有アクセスをパ
ーソナル・コンピュータと専門ワークステーション（以
下、併せて「ワークステーション」という）のユーザに
、ワークステーションのハードウェア構成とソフトウェ
ア操作環境中の相違にもかかわらず、電子文書のコード
フォーマットと、ネットワーク環境の移送と通信プロト
コールを提供するための方法と手段に関する。

溌」厖ｑ背１ 異なったハードウェア構成と異なったソフトウェア操作
環境を有するコンピュータ上で文書を作成し編集するた
めに、様々なテキストと合成画像エディターが開発され
ている。残念ながら、そのようなエディタの多数は、そ
のようなフォーマットの構造と内容をコード化するため
に異なった文書記載言語（ＤＤＬ）を使用しているため
、特定のコンピュータ・システムによってそのフォーマ
ットを操作し翻訳することはできるが、その他のコンピ
ュータ・システムによって操作し翻訳することはできな
い。例えば、ＷＹＳＩＷＹＧ　（“Ｗｈａｔ　ＹｏｕＳ
ｅｅ　１ｓＷｈａｔ　Ｙｏｕ　Ｇｅｔ　”　ｒ見るもの
が手に入る」）テキスト・エディタは、一般に、システ
ム特有のコードフォーマットを有するＤＤＬに基づいて
いる。

そのような文書コードフォーマントが相違している結果
、「文書交換システム」の問題が存在し、その問題が、
異なったコンピュータ・ハードウェア構成および／また
は異なったソフトウェア演算環境を使用するユーザによ
る電子文書の共用を妨げている。ユーザは、時には、共
用したいと堕む文書のための、ＡＳＣＩＩ　コードのよ
うな平文テキスト・コードを使用することによって、ま
たは、異なったコードフォーマットを有する文書をフォ
ーマット変換装置に通して実行させることによって、こ
の問題に対処することができる。ただし、平文テキスト
・コードは、著者が意図した外形を電子文書に与えるた
めに要求されるフォーマ・ノド情報の多くを犠牲にする
。他方、フォーマット変換プログラムは、そのプログラ
ムが常駐するホスト・コンピュータのオペレーティング
システムによって限定されるだけでなく、通常は、その
プログラムを実行するために利用することができる実質
的な計算能力をホスト・コンピュータが持っていること
が必要である。さらに、公知のフォーマット変換装置は
、一般に、文書の原フォーマットと所望のフォーマット
の両方の入り狗−す−知識を必要とするため、そのよう
なフォーマット変換装置はこの問題の部分的解決である
に過ぎない。

Ｆｉｌｅｎｅｔのような画像データベースは、文書外形
の要素の一部と文書の記載を結合する。そのデータベー
スは画像の記憶と検索のために設計されたものであるが
、記憶された画像すなわち「外形」は、所定のただ一つ
の書式の中でしか検索することができない。そのため、
そのようなデータベースから検索する画像の翻訳のため
に、クライアントがカスタム・デイスプレーおよび／ま
たはカスタム・ソフトウェアを必要とすることが多い。

代表的な場合、そのようなデータベースには、記憶され
た各画像についての個別の質問可能な（ｑｕｅｒｉａｂ
ｌｅ）情報が含まれているが、従来この説明情報は、ユ
ーザの要求に合わせるために補足することができる無制
限の画像記述を提供するよりはむしろ、少数の所定のフ
ィールドに限定されている。

さらに、すべての画像説明をそのようなデータベースの
同じレベルに記憶させることが標準的方法であるため、
一つの記述が他の記述を示すことはできない。

本発明を実行するためには、拡張型遠隔手続き呼出しく
ＲＰＣ）演算を使用する。したがって、呼び出された手
続きが実行されている間、クライアントからの定期的コ
ールバック（すなわち、クライアントによるサーバ・ポ
ーリング）を必要とする拡張型ＲＰＣ演算の他にも、ク
ライアントが呼び出した手続きが完了に達したとき、ク
ライアントにサーバ・コールバックを提供するための公
知の拡張型ＲＰＣ演算が存在することを理解すべきであ
る。ただし、そのような公知のＲＰＣ演算のサーバ・コ
ールバックは、クライアントに部分的な結果を与えない
。さらに、公知のクライアント・ポーリング方法は、呼
び出された手続きが開始された後におけるサーバの状態
の変化を考慮に入れていない。

光囲■！對 本発明によれば、異なったコードフォーマットによって
そのような文書を表示するため、および、異なったファ
イル伝送プロトコールを使用してそのような文書を伝送
するため、異なったハードウェア構成と異なったソフト
ウェア演算環境を有するコンピュータの間で、完全にフ
ォーマツティングされた電子文書の視覚的に忠実な翻訳
を交換するためのデータベース・システムが、提供され
る。

そのようなコンピュータの間のそのような文書の伝送に
含まれるすべての書式変換とその他の活動は、本質的に
ユーザには明白であり、ユーザのいずれかの側が、他の
ユーザのいずれかの計算および／またはネットワーク環
境に関する先験的知識を持っていることを要求しない。

本発明のさらに詳細な特長を保持するに際し、すべての
データベース演算は、クライアントのアプリケーション
が、データベースの演算が作業を完了するのを待つこと
なく、比較的迅速に演算から部分的結果を得ることがで
きるようにする遠陪手続き呼出しプロトコールによって
開始され、データベース演算の進捗はそのプロトコール
によって点検される。このデータベース演算は、主サー
バ・、プログラムによって子プロセスとして分岐されて
いるので、別のデータベース演算プログラムを追加する
ことによって、このデータベース・システムの機能を容
易に拡張することができる。

本発明の追加目的と長所は、添付図面を参照して下記の
詳細な説明を読むと、明らかになるであろう。

−された　　　の　　な 以下、図示された実施例を具体的に参照して本発明の詳
細な説明するが、本発明をその実施例に限定する意図で
はないことを理解すべきである。

反対に、添付請求項によって定義された通り、本発明の
精神と範囲に属するすべての修正、代替及び均等物を本
発明中に包含させることを狙いとしている。

■、ａ能的概観 Ａ、外形＋記述としての電子文書 本発明によれば、電子文書は、個別に記憶、操作、検索
される「外形」と「記述」の２部分に分割されている。

文書記述には、文書記述が関係する文書に関する記号情
報すべてが含まれている。

したがって、そのような記述は、通常のデータベース照
会を使用して規定される探索のための一次情報源である
（外形内容に整合する全体パターンを除く）。他方、文
書外形には、文書外形が関係する文書を視認者が認識す
るため必須である精神物理学的に重要な情報すべてが含
まれている。外形も記述も、所定の電子文書を規定する
ために十分でないが文書を十分に規定するために結合し
ている。外形と記述は互いに結合する。外形と記述が相
互に結合するのは、各記述が関係する外形の識別子また
は「ハンドル」が常に各記述に含まれているからである
。しかし、一部の記述が、文書のページや図書の章のよ
うに複合的な外形に関係していることがあり、そのため
、そのような記述は複合ハンドルを含むことができる。

また、記述が（外形に対向するような）記述に関係する
ことがある。その場合、記述は、その記述が関係する記
述のハンドルを含むことになる。

Ｂ０文書の記憶と検索 すべての外形は固定されているが、外形の表示すなわち
「翻訳」は様々であり、個々の視認者の個人的ニーズに
合わせて誂えることができる。したがって、文書外形は
、入力装置のコードフォーマットを改編することなく、
どの「クライアント」のワークステーションまたは入力
スキャナー用サーバのような入力サーバからでも、本発
明のデータベース・システム中に入力させることができ
る。

同様に、どのクライアント・コンピュータ・デイスプレ
ー・スクリーンまたは電子プリンタ・サーバでも、記憶
されたどの外形にでもアクセスすることができ、その外
形をクライアントが規定したフォーマントに翻訳するこ
とができる。

例えば、第１図に示す通り、ペーパー文書２２を強度サ
ンプルフォーマットの非圧縮または圧縮アレーに従って
コード化される対応電子ビットマツプに変換するために
、はぼ従来の入力スキャナ−２１を使用することができ
る。このビットマツプは、１つまたは複数の外形データ
ベース２４中に外形として記憶される。その上、以下に
さらに十分に記載する通り、そのビットマツプは、記憶
された外形に指定された独特な名称またはハンドルのＡ
ＳＣＩＩＩＩテキストコードを含む記述を作るため、２
５においてのように、標準文字認識方法を使用して処理
される。示されているように、代表的な場合、そのよう
な文書記述は、データベース・システムによって自動的
に、および／またはクライアントの管理の下で追加され
る補足情報によって増大される。次に、記述は１つまた
は複数のデータベース２６中に記憶される。クライアン
トのワークステーション２８上で作成された電子文書の
外形と記述をそれぞれ外形データベース２４と記述デー
タベース２６に入ツノするためには、同様な、ただしよ
り直接的な手順が使用される。

第２図を参照すると、クライアントワークステーション
２８のユーザは、３２において、データベースが規定す
る照会との整合のために１つまたは複数の記述データベ
ース２６を探索するため、直接的なデータベース照会ツ
ールを実行することができることが理解される。そのよ
うな照会を選択された記述データベース２６に向けるた
めには、３３における適当なルーティング方法を使用す
ることができる。照会マツチング記述のリストをユーザ
に提供するため、照会３２に整合する記述はクライアン
ト２８に戻される。

第３図において、クライアントのワークステーション２
８のユーザは、クライアントのワークステーション２８
のハンドルを１つまたは複数の外形データベース２４に
提供することにより、また、外形が翻訳されることにな
る装置と外形を翻訳デバイスに送るときのデータ・コー
ドフォーマットを定義する翻訳仕様を提供することによ
って、外形にアクセスする。選択された外形のためのハ
ンドルは、上記で説明した通り、探索照会整合記述から
得ることができ、または、ユーザがセーブしておいたか
、そのような検索に頼ることなく取得したハンドルとす
ることができる。代表的には、外形を翻訳することにな
る装置は、その装置の解像度、所望の翻訳の幅と高さ、
および、翻訳装置のグレースケールとカラー特性に関し
て翻訳仕様が規定する。翻訳仕様にはまた、例えば、コ
ンピュータ・デイスプレー上で外形を翻訳しなければな
らない場合における周辺照明条件のような、人間の目に
対する外形の認識に影響を与えることがある環境条件に
関するその他の情報も含めることができる。概して、そ
のような翻訳仕様は、クライアントのワークステーショ
ン２８の上に存在するアプリケーション・プログラムと
コンパチブルであるデータ・コードフォーマットを要求
する。

例えば、ＭａｃｉｎｔｏｓｈのクライアントはＭａｃＰ
ａｉｎｔフォーマットを、ＰＣのクライアントはＴｌＦ
Ｆフォーマットを、Ｖｉｅｗｐｏｉｎｔのクライアント
はＲＥＳフォーマットを、それぞれ規定するはずである
。

所定の外形のすべての翻訳は、同じハンドルによって識
別される。したがって、特定の外形の所望の翻訳が外形
データベース２４のいずれかにおいて入手することがで
きるか否かを決定するために、ユーザが供給した外形ハ
ンドルと翻訳仕様を使用することができる。有利なこと
であるが、作られたすべての翻訳は、４１において、外
形データベース２４によって、例えば２４時間のような
所定の時間の間、キャッシュされるので、頻繁に要求さ
れる翻訳を要求するクライアントは、そのような翻訳の
中間フォーマット変換またはその他の処理をすることな
く、その翻訳を直接入手することができる。ただし、ユ
ーザが規定した外形の翻訳を利用することができない場
合は、適当なフォーマット変換プログラム４２を呼び出
すため、選択された外形が外形データベース２４内に存
在するときのフォーマットを、ユーザが規定したフォー
マットと比較する。代表的には、フォーマント変換プロ
グラム４２を選択するためにフォーマソト変換のマトリ
ックスＭｉ織表４３を使用する。

記ｊｆＪされフォーマット変換された翻訳を要求するク
ライアントは、クライアントが規定したファイル伝送プ
ロトコルの使用を介して、データベース・ファイル・サ
ーバ４４を経由して、その翻訳を検索することができる
。

Ｃ９適時かつ最善努力翻訳の有意性 上記で説明した抜粋翻訳仕様を使用することは、記憶さ
れた外形がワークスチー、ジョン２８のデイスプレー・
モニタまたはプリンタ４６のような出力装置上に出現す
る直前に、翻訳（すなわち、記ｔαされた外形の精神物
理学的に等価である表現）を作ることができることを意
味する。その結果、翻訳を作っている間に、翻訳を見る
ときの照明条件、出力装置のコントラストとカラー領域
、および、コントラストとカラーに対するユーザの感受
性のような変数を含め、翻訳に対する人間の知覚に悪影
響を及ぼす環境とユーザ規定の変数を考慮することがで
きる。実行されるそのような翻訳仕様と適時の翻訳は、
異なったクライアントが同じ外形の異なった翻訳を取得
することができるようにする。また、あるクライアント
が、異なった時期に、１つの外形の異なった翻訳を取得
することができるようにする。換言すると、クライアン
トは、自己の用件を満足させるように翻訳を誂えること
ができる。

したがって、本発明が意図するクライアントを中心とし
た翻訳が、外形が１つまたは複数である特定のフォーマ
ットの外形データベース２４に入力された時から、クラ
イアントによってその書式または異なった書式で検索さ
れるまで、異なった多数の変形を外形に加えることがで
きるようにすることは明らかであろう。ただし、そのよ
うな変形は、文書の著作者が伝えたいと意図した視覚情
報に忠実なのであるから、その視覚情報すなわち「外形
」を規定するために当初使用されたコードフォーマット
が何であっても、そのような変形はすべて相互関係を有
している。どの翻訳であっても、記憶された外形の精神
物理学的に等価である表示を作るための、「最善努力」
による意図なのである。ただし、精神物理学的に等価で
ある表示は、記憶された外形とその外形の翻訳との間の
ビット毎の対応を必要としない。むしろ、必要であるの
は、翻訳が、原外形すなわち記憶された外形と、人間の
知覚レベルにおいて密接に一致することだけである。こ
のことは、例えば、外形を、再操作による検索に備えて
、例えばマイクロフィルムの上に、アナログ情報として
記憶させることができることを意味する。また、形状の
視覚角度ひずみを補償するため、視覚変形の角度を幾何
学的形状を代表するピクセル・パターンに適用すること
ができることを意味する。例えば、四角形を表示させる
ための非四角形のピクセル・パターンを作り、その結果
、斜めの角度で見られたとき、そのピクセル・パターン
が人間の目には四角形に見えるようにするために、その
ような変形を使用することができる。

Ｄ、照会と翻訳の管理 本発明の重要な特長を保持するため、いずれかのクライ
アントのためのすべてのデータベース演算は、所望のデ
ータベースの演算を開始させるための一つの部分（以下
、［位置付けＪ　ＲＰＣという）と、演算の進捗を点検
するための他の一つの部分（以下、［再位置付けＪ　Ｒ
ＰＣという）とで構成された遠隔手続き呼出しくＲＰＣ
）によって呼出される。そのような呼出しは、両方とも
、データベース・サーバに、呼出された演算から入手す
ることができる結果を発見することができるファイル位
置、演算の完了に向かってなされた進捗の表示、演算の
完了が予期される時期の推定、および、呼出された演算
が追加作業を行ったときのみに変化する「進捗鼓動」に
ついての同じ情報をクライアントに戻させる。この情報
は、「実行−サーバー推定」によって提供される。この
推定は、下記を与えるための整数値を含む４つのフィー
ルドで構成されている：　（１）結果ファイルの位置（
ファイル位置が未知である場合、−１値をこのフィール
ドに入力する’）　、（２）まだベンディングである作
業の推定（代表的には、値が０であることはすべての作
業が行われたことを示し、値が−１であることは推定が
ないことを示す）（３）完了までに予測される時間（秒
１社位）（この場合も、値が−１であることは値が未知
であることを示す）、（４）その他の結果を利用するこ
とができるようになるまでの推定時間（秒単位）（この
場合も、値が−１であることは値が未知であることを示
す）。

そのような、いわゆる実行−サーバー推定には３つの重
要な用途がある。第１に、クライアントは部分的結果に
アクセスすることができる。このことは、翻訳が作られ
ている間特に有用であるが、それは、翻訳が時間を要す
る手続きだからである。

第２に、その推定は、なされている進捗に関するフィー
ドバックをクライアントに提供する。さらに、そのよう
な推定は、クライアントが選択した最適化規準に基づく
サーバ結果のためのクライアントによる最適化ポーリン
グを容易にする。例えば、データベース演算との関与を
最低にしたいと望むクライアントは、予測された完了時
刻において結果を求めるためにデータベースを呼出すこ
とができる。したがって、クライアントが結果を求めた
とき演算が完了していない場合、クライアントは、適切
なコールバック時刻を決定するためその呼出しに応えて
戻された、最新化された完了推定を使用することができ
る。逆に、データベース演算上でなされている進捗にさ
らに密接に従いたいと希望するクライアントは、サーバ
をさらに頻繁に呼出すことができるが、重複呼出しがあ
まりにも頻繁になされたため、１つの呼出しから他の呼
出しに報告する進捗がない（すなわち、進捗の鼓動に変
化がない）場合、そのような重複実行サーバー推定はそ
のクライアントに戻される。

Ｅ１文書ハンドル すでに指摘したとおり、いずれかの外形データベース２
４に入力された各所しい外形について独特な文書ハンド
ルが作られる。単一のハンドルが、ある与えられた外形
の、可能性のあるすべての翻訳に集合的に照会される。

そのようなハンドルには持久性があるので、クライアン
トは、外形の検索に際して後日使用するため、ハンドル
を無期限にセーブすることができる。さらに、分散型フ
ァイル・システムは、ハンドルのための中央レジストリ
ーまたはデータベースを使用することなく、分散型ファ
イル・システムに入力される異なった外形のための全く
独自な文書ハンドルを、独立して作る。

各文書ハンドルには、例えば８−ビットのバイト３２個
のシーケンスで構成された２進コードと、例えば２進コ
ード化されたバイトのそれぞれを代表するため、１６進
数字２つで構成されたテキスト・コード（スペースを節
約するため、２進コードのすべてのトレーリング・ゼロ
・バイトをテキスト・コードから落とすことができる）
の２つのコードがある。以下でさらに詳細に説明する通
り、文書ハンドルの２進コードは、データベース・サー
バのための遠隔手続き呼出しインターフェイスにおいて
使用することができ、一方、テキスト・コードは、対応
する記述の中の文書外形を参照するために使用される（
クライアントとサーバ・ソフトウェアによる使用を容易
にするため、文書記述にはテキストだけしか含めること
ができない）。

文書ハンドルは、階層形識別子スペースを提供する。そ
の提供のため、文書ハンドル可変数のフィールドに分割
されており、各フィールドは、直前のフィールドによっ
て設定された文脈節に基づいた解釈を受けることができ
る。クライアントはそのようなハンドルを単一の識別子
として使用するので、クライアントがハンドルの内容を
解釈する必要はない。ただし、データベース・サーバは
、ハンドルの内容を解釈して、外形の記憶位置のような
、関連する外形についての抜粋コード化情報にする。さ
らに特定すると、単一の外形データベースを有する単純
なシステムのためのサーバは、典型的な場合、局所的に
知られたすべてのデータベース・ハンドルのインデック
スを維持するだけであるが、さらに高度化したデータベ
ース・システムのためのサーバは、対応する外形がい（
つかの局所的データベースの１つに記憶されているか否
か、または、外形を得るために他のサーバにも接触しな
ければならなか否かを決定するために、文書ハンドルを
使用することができるはずである。

基本文書ハンドルのために適した内部フォーマットは下
記の通りである（可変でない場合、２進フイールドの長
さのビット数が示されている）：＜ｄｏｃｕｍｅｎｔｈ
ａｎｄｌｅ　　ｌ　　２５６＞＝＜ｈａｎｄｌｅ　　ｔ
ｙｐｅ　　ｌ　８＞＜ｆｉｅｌｄ＞、、、、　　＜ｆｉ
ｅｌｄ＞ 上記の式において、 ＜ｆｉｅｌｄ＞＝＜ｆｉｅｌｄ　ｔｙｐｅ　ｌ　１６＞
＜ｆｉｅｌｄ　ｂｙｔｅｓ＞　；＜ｆｉｅｌｄ　　ｔｙ
ｐｅ　　ｌ　　１６＞＝＜ｕｎｉｑｕｅｎｅｓｓ　　ｒ
ｕｌｅ　　ｌ　　ＩＤ＜ｆｉｅｌｄ　　ｌｅｎｇｔｈ　
　ｌ　５　　＞　　ｉ＜ｆｉｅｌｄ　ｌｅｎｇｔｈ＞は
、＜ｆｉｅｌｄ　ｂｙｔｅｓ＞中のバイト数であり、＜
ｈａｎｄｌｅ　ｔｙｐｅ＞　＝　１である。

予想される通り、さらに洗練されたシステムにおいては
１個以上のハンドル・タイプが要求されることがあり、
その場合には、＜ｈａｎｄｌｅ　ｔｙｐｅ＞が１に等し
くないことがある。適当な場合、与えられたハンドル内
にそれ以上のフィールドがないことを示すため、すべて
のゼロを含む＜ｆｉｅｌｄ　ｔｙｐｅ＞が保存される。

文書ハンドルのための一意性規則の代表的なセットを２
進フイールドフオーマツトと共に下記に列記するが、さ
らに洗練されたデータベース・システムのためのサーバ
が必要とするデータベースと文書位置についてのヒント
を文書ハンドルがコード化することができるようにする
ためには、フィールド・タイプの追加が要求されること
になることを理解しなければならない： 規則１　：　＜ｒｅｇｉｓｔｅｒｅｄ　ｈｏｓｔ　ｌ　
１６＞＜ｔｉｍｅｓｔａｍｐ　ｌ　３２＞［＜ｔｉｅ−
ｂｒｅａｋｅｒ＞］ 規則２　　：　＜Ｓｕｎ　　ｈｏｓｔ　ｌ　３２＞　　
［＜ｔｉｅ−ｂｒｅａｋｅｒ＞］規則３　：　＜ｒｐ　
ｈｏｓｔ　ｉｄ　ｌ　３２＞＜ｔｉｍｅｓｔａｍｐ　ｌ
　３２＞［＜ｔｉｅ−ｂｒｅａｋｅｒ＞］ 規則４　：　＜ｅｉｔｈｅｒ　ｈｏｓｔ　ｉｄ　ｌ　４
Ｂ＞＜ｔｉｎ＋ｅｓｔａｍｐ　ｌ　３２＞［＜ｔｉｅ−
ｂｒｅａｋｅｒ＞］ 規則５　：＜ｒｅｌａｔｉｖｅ　ｉｄ＞　　（前のフィ
ールドに対して独自） 規則６　：　＜ｄａｔｅ　ｏｆｆｓｅｔ　ｌ　３２＞＜
ｒｅｌａｔｉｖｅ　ｉｄ＞］規則７　：　＜ｄａｔａ　
ｏｆｆｓｅｔ　！　３２＞＜ｄａｔｅ　ｌｅｎｇｔｈ　
ｌ　３２＞［＜ｒｅｌａｔｉｖｅ　ｉｄ＞］ 規則８　：　＜Ｐｕｐ　ｈｏｓｔ　ｉｄ　ｌ　１６＞　
＜ｔｉｍｅｓｔａｍｐ　ｌ　３２＞［＜ｔｉｅ−ｂｒｅ
ａｋｅｒ＞］ 規貝り９　　：　＜ｈａｎｄｌｅ　　５ｕｂｔｙｐｅ　
　ｌ　８　　＞　　［＜ｒｅｌａｔｉｖｅ　　ｉｄ＞］
現在までに定義されているハンドル。サブタイプ（一意
性規則９）は下記の通りである：０ｘ０１　：　　文書
は不変である。

０ｘ０２　：　　文書は記述である。

すでに指摘した通り、文書ハンドルはテキスト・コード
も持っているため、代表的な例のアバケース１６進テキ
スト・コードを、そのフィールドの説明と共に、下記に
規定する： ハンドル：　０１０１２１０３Ｑ１０？５９２２２２８
６４８Ｂ２５Ｃ上記において、 ０１は、ハンドル・タイプ１を意味し、０１２１は、一
意性規則またはフィールド・タイプ９、長さｌを意味す
る。

０３は、ハンドル・サブタイプが０ｘ０３　　（不変記
述）であることを意味する。

０１０７は、一意性規則またはフィールド・タイプ８、
長さ７を意味する。

５９２２は、Ｐ叶アドレス：１３１１４２ｆｌを意味す
る。

２２８６４８Ｅ２は、１９８８年５月９日（月曜日）１
７時１６分３４秒についてのＵｎｉｘ会議タイムスタン
プである。

５Ｃは、タイムスタンプに追加解像力を提供するための
ブレーカ−整数値である。

（００，、、，００）は省略されている（すなわち、１
３ビトが使用されており、１９バイトが使用されていな
い。） ■、実施例の詳細 Ａ、序論 第４図を参照すると、遠隔クライアント・アプリケーシ
ョン・プログラム５２−５４との通信のための標準５ｕ
ｎＲＰＣインターフエイスを備えたＳｕｎワークステー
ション（図示されていない）上でＬｌｎｉｘデータベー
スを実行することにより、本発明のデータベース・シス
テム５１が都合よく実行されている。クライアント・ア
プリケーション５２−５４は、文書記憶と検索アプリケ
ーション、データベー・ス探索アプリケーション、入力
スキャナ・サーバ・プログラムとプリント・サーバ・プ
ログラムを含む様々なフォーマットを取ることができる
。データベース・システム５１のためのサーバ・プログ
ラムは、ｒｐｃｇｅｎ、　ＣとＣ−５ｈｅｌｌプログラ
ム言語で書かれており、文書の記述と外形は、Ｕｎｉｘ
ファイル・ディレクトリ−の階層を使用するデータベー
スが記憶する。

図示されているとおり、データベース・システム５１に
は、５ｕｎＲＩ’Ｃインターフエイスを経由して遠隔ク
ライアント・アプリケーション５２−５４と通信するた
めの主サーバ・プログラム５５が含まれている。この主
サーバ・プログラム５５は、３つの遠隔手続きプロトコ
ル、すなわち、Ｌｏｃａｔｅ。

しｏｃａｔｅ　ＭｏｒｅとＲｅ１ｅａｓｅＯｐを使用す
る基本データベース・プロトコルを実行するに過ぎない
。

ＮｃｗＤｏｃＤｅｓｃ演算プログラム５６、Ｒｅｎｄｅ
ｒ演算プログラム５７やＤｅｓｃ　ｒｉｐｔｉｏｎｓｅ
ａｒｃｈ演算プログラム５８のような特定のデータベー
ス演算は、独立したＬｌｎｉｘプロセスとして主サーバ
・プログラム５５から呼び出される個々のプログラムに
よって扱われる。次に、演算プログラム５６−５８は、
標（表出力装置を経由して、主サーバ・プログラム５５
に結果を伝える。したがって、ユーザが誂えた探索と変
換演算のためのような別のデータベース演算プログラム
を追加することによって、データベース・システム５１
の機能性を容易に拡張することができることは明らかで
あろう。すでに指摘したとおり、ファイルは、クライア
ントが規定した伝達プロトコルの使用を通して、１つま
たは複数のネ・ノドワーク・ファイル・サーバ４４を経
由し、クライアント・アプリケーション５２５４とデー
タベース・システムのデータベース５９の間で両方向に
伝送される。他方、主サーバ・プログラム５５は、６０
においてのように、外形と記述データベース５９内の一
時的フアイルと永久ファイルに直接アクセスすることが
できる。

Ａ、主サーバ・プログラム 第５図を参照すると、主サーバ・プログラム５５がクラ
イアント・アプリケーション５２５５から遠隔手続き呼
出しを受け、クライアントのために要求されたデータベ
ース演算を実行するための適当なデータベース演算を呼
出し、クライアントが要求したデータベース演算の進捗
を追跡し、演算の結果を、その演算を要求したクライア
ントに戻すことを知ることができる。主サーバ・プログ
ラム５５は、ｒｐｃｇｅｎとＣプログラム言語を使用し
て適当に実行される。

すでに説明した通り、本発明を実行するために使用され
たＲ　Ｐ　Ｃプロトコルは、Ｌｏｃａｔｅｓ　Ｌｏｃａ
ｔｅＭｏｒｅとＲｅ１ｅａｓｅＯρの３つの遠隔手続き
を定義する。

Ｌｏｃａ　ｔｅとＬｏｃａｔｅＭｏｒｅ手続きは、クラ
イアントが要求するデータベース演算からの部分的結果
をクライアントが迅速に得ることができるようにする。

具体的にいえば、そのような手続きは、演算が完了する
までクライアントに結果を待つことを求めるよりは、要
求されたデータベースの演算が行われている間に部分的
結果を利用することができるようにすることが多い。そ
の目的のため、要求されたデータベース演算の各結果と
共に、演算“ｉｄ”すなわちハンドルがクライアントに
戻される。このハンドルは、要求された演算の進捗に関
する追加の結果と最新化状態情報を得るため同じ演算に
ついての、クライアントの次に呼出しにおいて使用され
る。そのような演算ハンドルそれぞれはクライアントに
戻される結果ストリーム中の１つの位置を占めるだけで
あるため、後で作られた結果が返送された後であっても
各演算ハンドルを再使用することができる。例えば、結
果の伝送を要求するために演算ハンドルを再使用するこ
とができる。また、後で更に詳細に説明する通り、異な
った「結果タイプ」を規定することにより、異なった方
法で結果をフィルターするためにそのようなハンドルを
再使用することができる。

主サーバ・プログラム５５は、データベース位置とその
他の値（“Ｎ”と名付けられたＳｕｎ　ＮＦＳファイル
伝送プロトコルをＡｒｐａホスト名スペ名入ペース内ｎ
ｓｅ１．．　ｐａｒｃ、　ｘｅｒｏｘ、　ｃｏＩＩＩ　
″と名付けられたサーバ上で実行する、“Ｓｙｓｔｅｍ
　３３　”として知られるデータベース・システムにつ
いての代表的な省略値は、括弧に入れて示す）を設定す
るため、下記のＵｎｉｘ環境変数を使用する：５３３Ｓ
ＥＲＶＥＲ−プロトコールとサーバ名（Ｎａｎｓｅｌ）
Ｓ３３ＤＢＤＩＲ−データベース・ディレクトリ−（／
ａｎｓｅｌ１０４／ｓｙｓ　ｔｅｍ３３）５３３ＢＩＮ
ＤＥＲ−プログラム・ディレクトリ−（／ａｎｓｅｌ１
０４／ｓｙｓ　ｔｅｍ３３／ｂｉｎ／３．５）Ｓ３３Ｄ
ＥＢＵＧ−デバグ・フラグの整数コード（Ｏｘ５Ｆ） Ｓ３３ＧＲＯＩＪＰ−限定演算に対するアクセスを認可
されているＵｎｉｘのＩロ　（３３） Ｓ３３ＣＴＩＭＥ−クライアント・タイムアウトの間の
秒数（６００） Ｓ３３ＳＴＩＭＥ−付加演算プログラム・タイムアウト
の間の秒数（３００） データベース演算プログラム５６−５８　（第４図）は
また、そのような環境変数にアクセスすることができる
。

１、　　Ｌｏｃａｔｅ手続き Ｌｏｃａ　ｔｅ手続きは、その手続きを呼出すクライア
ントから、下記のアーギュメントを取る：クライアント
識別ストリング、演算プログラム名とストリング・アー
ギュメントのリストを含む演算プログラム・アーギュメ
ント、３２−バイト・ドキュメント・ハンドル、ファイ
ル・プロトコルのリストとサーバ名、書式名のリスト、
整数タイムリミツト、整数結果バッファー・サイズ、お
よび、整数結果のタイプ。図示された実施例において、
アーギュメントは、Ｕｎｉｘの“ａｒｇｖ”メカニズム
によってデータベース演算プログラム５６−５８（第４
図）に送られる。

代表的には、クライアント識別ストリング（Ｌｏｃａｔ
ｅＡｒｇｓ、　ｕｓｅｒＮａｍｅ　”　）には、データ
ベース・システム５１にアクセスする個人の登録名が含
まれている。プログラム・アーギュメント中の第１のス
トリング（”　ＬｏｃａｔｅＡｒｇｓ、　Ｌｏｃａｔｅ
Ｓｐｅｃ″）は演算プログラム名であるため、実行され
るデータベース演算を決定する。プログラム・アーギュ
メント中の残りのストリングとその他の手続きアーギュ
メントの解釈は命名されたデータベース演算に基づいて
行われるので、命名された演算が必要としない場合、そ
のようなアーギュメントの一部が空またはゼロであるこ
とがある。第５図に示されている通り、Ｌｏｃａ　ｔｅ
手続きは、６１においてのように、命名されたデータベ
ース演算に対応する実行可能なＵｎｉｘファイルについ
てのプログラムの点検を主サーバ・プログラム５５に行
わせる。

そのようなファイルが発見された場合、６２においての
ように、主サーバ・プログラム５５は、子プロセスとし
て、命名された演算プログラム６３をフォークし、残り
の演算プログラム・アーギュメントを命名された演算プ
ログラム６３に送る。

その他の手続きアーギュメントを簡単に検討すると、ク
ライアントは、Ｌｏｃａ　ｔｅ手続きを呼出すとき、そ
のデータベース内に記憶された特定の文書（すなわち、
記述または外形）を識別するための検索演算には文書ハ
ンドル・アーギュメント（ＬｏｃａｔｅＡｒｇｓ、　ｄ
ｏｃｌｄ”）を使用することを理解しなければならない
と規定することができる。このアーギュメントはまた、
新しい記述または既存の外形の新しいバージョンのいず
れかをデータベースに付加するために要求される場合は
、記憶演算のために使用することができる。サーバ／プ
ロトコル名称アーギュメント・アレー（“しｏｃａｔｅ
Ａｒｇｓ。

１ｏｃＦｉｌｔｅｒｓ、　５ｅｒｖｅｒｓ”）は１デー
タベースから文書を検索するためにクライアントが使用
することができるファイル伝送プロトコルおよび／また
はサーバを識別するための役に立つだけでなく、文書の
記憶演算のためにデータベースがクライアントのファイ
ルにアクセスするために使用することができるプロトコ
ルとサーバを規定するためにも役に立つ。同様に、フォ
ーマット名アーギュメント　（ＬｏｃａｔｅＡｒｇｓ、
ＩｏｃＦｉｌｔｅｒｓ、　　ｔｉｍｅＬｉｍｔ”）は、
　（ａ）クライアントが受入れたいと望む文書コード化
フォーマットを規定する演算が検索するため、および、
（ｂ）クライアントのファイルのコード化フォーマット
を規定する記憶演算のために使用することができる。次
に、タイムリミツト・アーギュメントじＬｏｃａｔｅＡ
ｒｇｓ、　１ｏｃＰｉｌｔｅｒｓ、　ｔｉｍｅＬｉｍｉ
ｔ”）の価は、（ａｌネットワーク・ファイル・サーバ
４４（第４図）の演算上に検索演算の結果を維持してい
たいとクライアントが望む期間と、（ｂ）記憶演算のた
めにクライアントのファイルが有効である期間を、クラ
イアントが規定することができるようにする。

さらに、結果バッファ・サイズ・アーギュメント（“Ｌ
ｏｃａｔｅＡｒｇｓ、ｂｕｆｆｅｒＳｉｚｅ”）は、単
一の返信パケット（ネットワーク・パケット・オーバー
ヘッドを除く）内で受領したいとクライアントが望む結
果データ・バイトの最大数をクライアントが規定するこ
とができるようにする。

Ｌｏｃａ　ｔｅ手続きについての結果タイプ・アーギュ
メント（”ＬｏｃａｔｅＡｒｇｓ、　ＩｏｃａｔｅＳｐ
ｅｃ”）は、クライアントが要求している結果のフォー
マットを規定する。発見された突合せの数のみの戻し、
突合せの文書ハンドルの戻し、突合せのファイル位置の
戻し、時間見積りのみの戻しを含め、このアーギュメン
トによって様々なオプションをコード化することができ
るが、命名されたデータベース演算、突合せの位置とフ
ァイル長さ両方の戻し、文書ハンドルのみおよび／また
は発見された最初の突合せのファイル位置の戻しは行わ
ず、戻されたファイル位置は、ゼロ・オフセットなしで
ファイルを規定することができる。

再び第５図に注目すると、命名されたデータベース演算
６３を開始するために主サーバ・プログラム５５が子プ
ロセスを呼出した後、主す−ノしプログラム５５のＬｏ
ｃａ　ｔｅ手続きがその手続きのための演算ハンドルを
作り、６７において示された通り、その演算ハンドルを
ジョブ・テーブル６４に入力する。その後、Ｌｏｃａ　
ｔｅ手続きは、６９においてのように、その演算ハンド
ルが入力されたことを確認するため、６８においてのよ
うに、ジョブ・テーブル６４の中でその演算ハンドルを
調べる。入力が発見されない場合、エラー・メソセージ
がクライアントに戻される。ただし、演算ハンドルが発
見された場合、Ｌｏｃａ　ｔｅ手続きは、７１において
示されている通り、データベース・サーバが識別された
位置にデータベース演算６３のための結果ファイル６６
を制定するようにさせる。

すでに説明した通り、データベース演算６３は、標準出
力装置を通して、その特定の演算のための結果ファイル
６６に、その結果（作っている進捗の実行−サーバー推
定を含む）を伝送する。次に、Ｌｏｃａ　ｔｅ手続きは
、結果ファイル６６から現行の実行−サーバー推定を、
７２において示されているような、文書ファイルおよび
／またはファイル位置のような、利用することができる
その他の結果と共に読出す。その後、その手続きは、７
３においてのように、次の手続きのための演算ハンドル
を作り、７４において示されているように、そのハンド
ルと現行の実行−サーバー推定をジョブ・テーブル６４
に入力する。最後に、Ｌｏｃａ　ｌｅ手続きを完了させ
るため、結果がクライアントに戻される。

結果は、代表的には、データベース・サーバ・エラーが
発生していないときは「ノー・エラー」値（例えば、０
）を有するエラー・コード、上記に挙げた実行−サーバ
ー推定の最新化された値のための整数コード、戻される
結果の数の整数コード（「整合の数」と呼ばれることが
ある）、次の手続きのための８−ビット演算ハンドル（
このハンドルはまた、特定の呼出しに応えて戻されてい
る結果の数を識別する）で構成される結果ストリーム中
でクライアントに適当に戻される。その上、クライアン
トが規定した結果タイプに基づき、戻される整合に対応
する文書ハンドルのリスト、サーバ・ファイル位置およ
び／またはサーバ・ファイル位置とファイル長さを、戻
される結果に含めることができる。クライアントは、ク
ライアントに戻された演算ハンドルを解釈しない。それ
よりも、クライアントは、ハンドルと共に戻された実行
−サーバー推定がデータベース演算６３が終了したこと
を示しているか否かに基づいて、データベース演算６３
から、または、データベース演算６３を終了させるため
のＲｅ１ｅａｓｅＯｐ手続きからその他の結果を得るた
め、ハンドルをＬｏｃａ　ｔｅＭｏｒｅ手順に伝えるだ
けである。

２、　　ＬｏｃａｔｅＭｏｒｅ手続き すでに説明した通り、この手続きは、追加結果を得るた
め、または、同じもしくは異なった結果タイプ・フィル
ターを使用してすでに戻された結果を検討するために使
用される。その目的のため、Ｌｏｃａ　ｔｅＭｏｒｅ手
続きは下記のアーギュメントを取る：演算ハンドル（“
ＬｏｃａｔｅＭｏｒｅＡｒｇａｓ、　ｈａｎｄｌｅ”）
、整数結果バッツ７’サイズ（”　ＬｏｃａｔｅＭｏｒ
ｅＡｒｇａｓ。

ＢｕｆｆｅｒＳｉｚｅ’）、整数結果タイプ（Ｌｏｃａ
　ｔｅＭｏｒｅＡｒｇａｓ＋ｒｅｓｕｌｔＴｙｐｅ”）
　。ＬｏｃａｔｅＭｏｒｅ手続きは、６８においてのよ
うに、ジョブ・テーブル６４を点検するためにその手続
きに届けられた演算ハンドルを、データベース演算６３
のための結果ファイル６６の位置付けのために使用する
。そのため、この手続きは、７２においてのように、結
果ファイル６６から新しい結果を読み出し、７３におい
てのように他の１つの演算ハンドルを作り、７４におい
てのようにジョブ・テーブル６４を最新化し、Ｌｏｃａ
　ｔｅ手続きに関してすでに説明した方法と本質的に同
じ方法で結果をクライアントに戻すことができる。

３、Ｒｅ１ｅａｓｅＯｐ手続き この手続きは、データベース演算を終了させるため、お
よび、関連演算ハンドルを無効にさせることによって、
特定の演算のために結果ファイル６６に割り当てられた
メモリー資源をデータベース・システム５１が解放する
ことができるようにさせるために呼出される。この手続
きは、データベース演算が完了する前または後に呼出す
ことができるので、クライアントのオプションによって
演算を放棄するために使用することができる。

Ｒｅ１ｅａｓｅＯｐは、アーギュメントとして、ターゲ
ットとしたデータベース演算（すなわち、終了させなけ
ればならないデータベース演算）のための演算ハンドル
を取るので、Ｒｅ１ｅａｓｅＯρは、７５と７６におい
て示されている通り、ジョブ・テーブル６４の中で調べ
ることによって、その演算のための結果ファイル６６の
位置決めを行うことができる。ターゲットとされたデー
タベース演算のための現行の実行−サーバー推定が、７
７においてまだ演算が実行されていることを示す場合、
Ｒｅ１ｅａｓｅＯｐ手続きは７８におけるその演算のた
めの子プロセスを放棄させる。さらに、ターゲットとさ
れたデータベース演算が完成したか否かに係わらず、Ｒ
ｅ１ｅａｓｅＯｐ手続きは、７９においてのように、そ
の結果ファイル６６を削除し、８０においてのように、
そのターゲットとされた演算のための入力をジョブ・テ
ーブルから取り除く　（その演算ハンドルを無効化する
）。

Ｂ１代表的なりライアント・アプリケーション・プログ
ラム 第６図を参照すると、クライアント・アプリケーション
５２−５４　（第４図）が、８１においてのように、そ
のクライアント・アプリケーションのために実行される
ことになる演算６３（第５図）のような、各データベー
ス演算のためのＲＰＣアーギュメントを支給することが
回想されるであろう。したがって、データベース演算を
開始するためには、所望のデータベース演算の名称（例
えば、ＮｅｗＤｏｃＤｅｓｅ　”　、　　”　Ｄｅｓｃ
ｒｉｐｔｉｏｎＳｅａｒｃｈ″“Ｒｅｎｄｅｒ″等）を
含め、クライアントが規定したＲＰＣアーギュメントを
主サーバ・プログラム５５（第５図）に通すため、８２
において、Ｌｏｃａ　ｔｅ手続き（第５図）が呼出され
る。ＲＰＣエラーが発生しない場合、主サーバ・プログ
ラム５５は、命名されたデータベース演算を実行するた
めの実行可能なプログラムがデータベース・サーバのプ
ログラム・ディレクトリ−によってリストされているか
否かを決定するための演算名称アーギュメントを取る。

規定された演算プログラムのためにディレクトリ−・リ
ストが発見された場合は、上記の通り、命名されたデー
タベース演算が呼出される。反対に、リストが発見され
ない場合、または、８３において決定される通り、サー
バ・エラーが発生したことを示すエラー・コードがＬｏ
ｃａ　ｔｅ手続きによって戻された結果に含まれている
場合、このクライアント・プログラムは、８４において
のようにエラー・メツセージを出力した後、ニゲジフト
する。

Ｌｏｃａ　ｔｅ手続きが有効な結果を戻した場合、クラ
イアント・プ・ログラムは８５において戻された整合の
数を出力した後、８６において示されている通り、戻さ
れた結果のリストを処理する準備を行う。「整合の数の
み」結果タイプをクライアントが規定した場合は空であ
るが、このリストは、すストされたすべての結果の処理
が終わったか否かを決定するため、８７において点検を
受ける。処理が終っていない場合は、リスト上の次の結
果のための“ｉｄ”すなわちハンドルが８８において抽
出され、その後、その結果は、抽出されたハンドルによ
って識別された文書のためのファイル位置を含んでいる
か否かを決定するため、８９において点検を受ける。処
理が終わっている場合は、９１において示されている通
り、クライアントは、データベース演算が不完全なこと
があり、主題文書がデータベース演算の究極の作業結果
の部分的な表示にすぎないことがあっても、規定された
ファイル・サーバ４４　（第４図）を経由してデータベ
ース・システム５９内の主題文書にアクセスするために
そのファイル位置を使用することができる。Ｌｏｃａｔ
ｅ手続きによって戻されたすべての結果の処理が終わっ
たことをクライアント・プログラムが８７において確認
した後、クライアント・プログラムは、９２においての
ように、作業ベンディングの実行−サーバー推定を点検
し、その後、要求されたデータベース演算が完了したか
否かに基づいてＲｅ１ｅａｓｅＯｐ　ＲＰ　Ｃ９６また
はＬｏｃａ　ｔｅＭｏｒｅＲＰＣ９７のいずれかを作る
。

さらに特定すると、さらに実行しなければならない作業
をデータベース演算が持っている場合、クライアント・
プログラムは、１０１においてのように、Ｌｏｃａｔｅ
Ｍｏｒｅ　ＲＰ　Ｃ９７を作る前に休止することにより
、その後の結果を作るための追加時間をデータベース演
算に与える。休止１０１の継続時間は、１０２において
決定される通り、その他の結果を利用することができる
ようになるまでの時間の推定が含まれている場合、事前
の呼出しに応じて戻された実行−サーバー推定によって
決定される。そうでない場合、所定の休止時間１０３が
使用される。適当な１ＩＩ１間休止した後、クライアン
ト・プログラムは、１０４において示されている通り、
事前の呼出しに応えて戻された結果から、次の呼出しの
ための演算ハンドルを抽出する。その後、そのハンドル
は、ＬｏｃａｔｅＭｏｒｅ　ＲＰＣ９７のアーギュメン
トとして、Ｌｏｃａ　ｔｅＭｏｒｅ手続き（第５図）に
届けられる。

要求されたデータベース演算の結果すべてを得るために
、クライアントがいくつかのＬｏｃａ　ｔｅＭｏｒｅＲ
ＰＣ９７を作らなければならないことがある。

したがって、核Ｌｏｃａ　ｔｅＭｏｒｅ手続きによって
クライアントに戻された部分的結果が、上記の通り、１
、ｏｃａｔｅ手続きによって戻された部分的結果の処理
に関して処理されることを理解しなければならない。こ
のことは、クライアントが、Ｌｏｃａｔｅ結果がら抽出
する場合と同じタイプの情報をＬｏｃａ　ｔｅＭｏｒｅ
結果から抽出することができることを意味する。

普通の過程においては、クライアント・プログラムは、
要求されたデータベース演算がその作業を完了した子と
を先ず９２において決定し、次に、その特定の演算のた
めの結果ファイル６６を削除し、ジョブ・テーブル６４
から関連入力を取り除くためにＲｅ１ｅａｓｅＯｐ　Ｒ
Ｐ　Ｃ９６を作った後に終了する（第５図参照）。

Ｃ０代表的なデータベース演算プログラム第５図に示さ
れている通り、すべてのデータベース演算プログラム６
３は、主サーバ・プログラム５５の子プロセスとして呼
出される。その結果、特定のクライアント・アプリケー
ションおよび／またはユーザの独特な要件を満足させる
ために設計されたデータベース演算を実行するために誂
えられたプログラムとして、データベース・サーバに別
のデータベース演算プログラムを容易に追加することが
できる。事実、データベース演算プ■コグラムの種類を
、事実上無制限にすることができるので、一部の代表的
な例を提供するため、い（つかの基本的データベース演
算プログラムを説明することにする。

クライアント・アプリケーション５２−５４（第５図）
によって、様々なデータベース演算のためのアーギュメ
ントを、主サーバ・プログラム５５に都合よく伝えるこ
とができる。Ｌｏｃａ　ｔｅＭｏｒｅ手続きとＲｅ１ｅ
ａｓｅＯｐ手続きは比較的少数のアーギュメントを取る
ので、そのような手続きのアーギュメントのＭｉ織は比
較的重置である。ただし、Ｌｏｃａ　ｔｅ手続きはもっ
と多数のアーギュメントを取るため、Ｌｏｃａ　ｔｅ手
続きの適当な組繊をｆ’Ｊ　？Ｍに規定することが役に
立つであろう。理解される通り、有利なことに、Ｌｏｃ
ａ　ｔｅ手続きのための初期アーギュメントの一つには
、クライアントが実行したいと望むデータベース演算の
ためのプログラム名が含まれている。その後、そのアー
ギュメントの後に、プログラム・アーギュメント（すな
わち、命名されたデータベース演算プログラムにサーバ
・プログラム５５が届けるアーギュメント）が続き、次
に、その後に、クライアントのために翻訳しなければな
らないデータベース文書のハンドルのような、その後の
クライアント要件を識別する追加手続きアーギュメント
、クライアントとの間で文書をやり取りするための受諾
することができるサーバおよび／またはファイル伝送プ
ロトコル（利用することができるいずれかのサーバとフ
ァイル伝送プロトコルが受諾することができるものであ
る場合、このストリングは空であることがある）、ター
ライアントが使用するかクライアントが受諾することが
できる文書コード化フォーマット　（それぞれ、記憶ま
たは翻訳しなければならない文書のための）と、クライ
アントが要求した結果タイプが続く。

１、データベースに対する文書と記述の追加第７図には
、クライアントが、新しい文書および／または新しい記
述を、それぞれ外形データベースと記述データベースに
追加することができるようにするためのＮｅｗＤｏｃＤ
ｅｓｃプログラム６３ａが示されている。その目的のた
め、クライアントがこのプログラムのサービスを要求す
る場合、ＮｅｗＤｏｃＤｅｓｃは、１３１と同様に、ク
ライアントが規定した文書および／または記述ファイル
１３２を一時フアイル１３３中にコピーする。このコピ
ーによって、１３６と同様にサーバが作った記述フィー
ルドはクライアントが供給した記述フィールドと併合す
る。その後、新しい文書および／または記述ファイルは
、１３７において、−時ファイル１３３からさらに永久
的なデータベース・ファイル位置５９に伝送される。図
示された実施例においては、１４３と同様に、データベ
ース記述インデックス１４２を新しい記述の内容で最新
化するため、子プロセスは１４１において親ＮｅｗＤｏ
ｃＤｅｓｃプロセスから呼び出され、その後、子プロセ
スは終了される。その上、記述インデックス１４２が最
新化されている間、親プロセスは、１４５において示さ
れている通り、演算結果ファイル６６中に新しく追加さ
れた文書および／または記述の識別ハンドルとファイル
位置を記録した後、親プロセスは終了する。

新しい文書をデータベースに追加しなければならない場
合において、代表的な場合、ＮｅｗＤｏｃＤｅｓｃプロ
セスのためのプログラム・アーギュメントの中の第１の
ストリングは文書のコピーをクライアントが利用すると
きのファイル名であり、次のストリングは空である。さ
らに、文書と記述の両方をデータベースに追加しなけれ
ばならない場合、両方のストリングの後に別の空ストリ
ング、または、新しい記述に含めなければならない記述
ファイルの名称のいずれかが続く。データベース内に現
存する記述のためにクライアントが規定した探索ドメイ
ンを次のストリングに含めることができ、そのストリン
グの後に、残りのプログラム・アーギュメントすべてが
、現存する記述中に挿入しなければならないクライアン
トが規定した属性名称と値のベアであることを示す空ス
トリングを続けることができる。また別の例を提供する
ため、すでにデータベース内に常駐する文書のために新
しい記述を追加する場合、プログラム・アーギュメント
は、現存する文書または常駐文書のハンドルを追加して
規定するが、その他の点では、プログラム・アーギュメ
ントは、−ａに、新しい文書を追加する場合と同じであ
る。

ＮｅｗＤｏｃＤｅｓｃデータベースの演算を実施する間
、データベースは、クライアントが供給した（すなわち
、現存する文書のための新しい記述を追加するため）文
書ハンドルをベリファイする（図示されていない手段で
）か、または、クライアントが命名したファイルから新
しいデータベース文書を作る。さらに、データベースに
新しい文書が追加される場合は常に、凭−バは、その文
書のための独特なハンドルおよび／またはファイル位置
を、ハンドルおよび／またはファイル位置がクライアン
トに戻されたか否かを決定する、クライアントが規定し
たと共に、主サーバ・プログラム５５（第５図）に戻す
。

データベースに新しい文書記述が追加される場合は常に
、サーバは、新しい記述の下記のフィールドを完成させ
る：　　ＤｅｓｃｌＤ、　Ｔｈ１ｓＤｅｓｃｌＤ、　Ｄ
ｅｓｃＣｒｅａｔｅＤａｔｅ、　ＤｅｓｃＣｒｅａｔｏ
ｒ、　ＤｏｃｌＤ、　ＤｏｃＦｏｒｍａｔ（新しい文書
のための記述にのみ追加される）。

その上、データベースに新しい記述を追加する間、サー
バは、フライアンｌ−が命名した記述ファイルからのフ
ィールドはもちろん、プログラム・アーギュメント中の
属性からのフィールドをサーバに付加する。有利なこと
に、データベース中には各記述の可変バージョンと不変
バージョンが記憶されているので、そのような記述を作
った後、サーバは、可変バージョン（例えば、Ｄｅｓｃ
ｌＤ　）と不変バージョン（例えば、Ｔｈ１ｓＤｅｓｃ
ＩＤ　）の両方のための文書ハンドルおよび／またはフ
ァイル位置を戻す。

２、　データベース探索 第８Ａ図と第８Ｂ図に示されている通り、クライアント
が規定した１つまたは複数の探索パターンとの整合のた
め、クライアントが規定した探索ドメイン（例えば、命
名されたデータベース）内に位置するデータベース記述
の、クライアントが規定した１つまたは複数のフィール
ドを探索するため、また、ＤｅｓｃｒｉｐｔｉｏｎＳｅ
ａｒｃｈ演算がある。代表的な場合、「パターン・タイ
プ」アーギュメントは、パターン整合の様々な程度を規
定する探索照会をクライアントが制定することができる
ようにするために使用される。例えば、正確な整合が要
求されていることを示すために、「均等な」検索タイプ
・アーギュメントを使用することができ、規定された探
索パターンが前置した整合を識別するために「前置」ア
ーギュメントを使用することができ、また、探索パター
ン内で何ががいずれがのワイルドカード（“＊”）と整
合していることを示すために、「ワイルドカード」アー
ギュメントを使用することができる。

代表的な場合、この演算のための処理プログラム・アー
ギュメントは探索ドメインであり、残りのプログラム・
アーギュメントは、探索照会中に内蔵された次々の「探
索フィルター」のためのパターン・タイプ、フィールド
名と探索パターンを規定する３−ビット・バイトである
のが好都合である。予期される通り、上記で説明した結
果タイプ・アーギュメントは、戻された結果をクライア
ントの具体的なニーズに合わせて誂えることができるよ
うにするので、データベース探索を行う間、特に有利で
ある。

第８Ａ図を詳細に調べると、クライアントがクライアン
トの探索照会内に複数の探索パターンを規定したか否か
を決定するため、ＤｅｓｃｒｉｐｔｉｏｎＳｅａｒｃｈ
プログラム１５０が、１２１においてそのプログラムの
アーギュメントを点検することが示されている。１つだ
けの探索パターンが規定されている場合、データベース
のための記述インデックス（第７図）のクライアントが
規定したフィールドは、整合のため、１５２において探
索され、整合記述の識別ハンドルとファイル位置は、結
果ファイル６６　（第５図）への記録のため、１５３に
おいて出力される。ただし、探索照会が複数の探索パタ
ーンを規定した場合（すなわち、第２またはより高い順
位の結果のフィルタリングが必要である場合）　、５ｅ
ａｒｃｈＦｉｌｔｅｒプログラム１６１（第８Ｂ図参照
）を呼び出すため、１５５において、親プロセスから子
プロセスがフォークされる。

その後、親ＤｅｓｃｒｉｐｔｉｏｎＳｅａｒｃｈプログ
ラム１５０は、第１の探索パターン（すなわち、第１順
位のフィルターリング）に整合している記述のために探
索１４２を行うが、５ｅａｒｃｈＦ　ｉ　ｌ　ｔｅｒプ
ログラム１６１による追加フィルタリングのため、ｇｌ
ｌＤｅｓｃｒｉｐｔｉｏｎ　５ｅａｒｃｈプログラム１
５０は、１５３において示されている通り、発見した整
合記述のハンドルとファイル位置を出力した後に終了す
る。

第８Ｂ図に示されている通り、探索結果の高順位フィル
タリングを実行するため、５ｅａｒｃｈＦ　ｉ　ｌ　ｔ
ｅｒプログラム１６１は、探索照会の順番の高順位探索
フィルターにしたがって、ＤｅｓｃｒｉｐｔｉｏｎＳｅ
ａｒｃｈプログラム１５０から受けとった部分的結果を
フィルターする。その目的のため、探索照会に１つだけ
の追加探索パターン（すなわち、それまでに結果に対し
て突き合わされたことがない探索パターン）しか含まれ
ていないことが１６２において決定された場合、５ｅａ
ｒｃｈＦ　ｔ　ｌ　ｔｅｒプログラムは、このすでに突
き合わされたことがないパターンに対して試験しなけれ
ばならない部分的結果が存在するか否かを決定するため
、１６３において点検する。部分的結果がない場合、プ
ログラムは終了する。ただし、１つまたは複数の記述が
低い順位のフィルタリング（すなわち、第１順位のフィ
ルタリング）を満足させる場合、そのような記述の次々
のハンドルとファイル位置が１６５において入力される
ので、次に高い順位のフィルターを対応記述が満足させ
るか否かを決定するため、１６６において対応記述を再
試験することができる。高い順位のフィルターと整合す
る記述のハンドルとファイル位置は、結果ファイル６６
中に記録するため、または下記に説明する通り、探索照
会が探索結果のそれ以上のフィルタリングを要求してい
るか否かに応じて、５ｅａｒｃｈＦｉｌｔｅｒプログラ
ム１６１によってさらにフィルターするため、１６７に
おいて出力される。

探索の結論を出すため、５ｅａｒｃｈＰ　ｉ　Ｉ　ｔｅ
ｒプログラム１６１のいくつかの再帰を要求することが
できる。さらに具体的にいえば、探索照会が、１つまた
は複数の高い順位の探索パターンに従ってＤｅｓｃｒｉ
ｐｔｉｏｎｓｅａｒｃｈプログラム１５０の結果のフィ
ルタリングを要求していることが１６２において決定さ
れた場合は、上記の通り、次に高い順位の（すなわち、
第２順位）探索フィルターを満足さ゛せる記述のため、
５ｅａｒｃｈＦｉｌｔｅｒプログラム１６１が、第１順
位のフィルター済み結果をスクリーンする。ただし、こ
の状況において、５ｅａｒｃｈＦｉｌｔｅｒプログラム
が１６７において出力する結果はまだ部分的にしかフィ
ルターされていないため、プログラムは、１６９におい
て示されている通り、自身を再帰的に呼出すため、１６
８において子プロセスをフォークする。５ｅａｒｃｈＦ
　ｉ　１　ｔｅｒプログラムの再帰は、記述が次に高い
順位の探索フィルターを満足させるか否かを決定するた
め、対応記述に連続的にアクセスするために親５ｅａｒ
ｃｈＦ　ｉ　ｌ　ｔｅｒプログラム１６１が１６７にお
いて出力したハンドルとファイル位置を次々に利用する
。その結果、この高順位のフィルタリングを満足させる
ことが発見された記述のハンドルとファイル位置は、結
果ファイル６６中に記憶させるための完全にフィルター
された結果、または、５ｅａｒｃｈＦ　ｉｆ　ｔｅｒプ
ログラム１６１のその後の再帰のための部分的にフィル
クーされた結果のいずれかとして出力される。認められ
る通り、探索結果が結果ファイル６６中に記録されるの
は、対応記述が探索照会に忠実に応答したことが確認さ
れた後に限られるが、完全にフィルターされた結果の一
部は、他の部分的にフィルターされた結果が試験されて
いる間に、クライアントに戻すために利用することがで
きる。

３、文書外形の検索 次に第９図を参照すると、翻訳演算１７０は、データベ
ース中の対応文書の位置決めのために文書ハンドルを使
用し、必要であり可能であれば、クライアントが要求し
た表示または「翻訳」にその文書を伝送する。最初のア
ーギュメントが演算プログラム名（「翻訳」）を定め、
次のストリング・グループには翻訳演算のためのオプシ
ョナル・プログラム・アーギュメントが含まれている（
また、示されている通り、省略翻訳プロセスを使用する
ことをユーザーが希望する場合、空とすることができる
）。この演算のための代表的結果タイプ・オプションに
は、翻訳された文書のファイル位置の戻し、規定された
変形を実行するが変換は実行しないために要求される時
間の推定の戻しと、ファイル位置を伴うファイル長さの
戻しが含まれる。

図示されている通り、翻訳演算プログラム１７０が呼出
された場合、子のプログラムは先ず、プログラム名に続
く第１のアーギュメントが専門化された翻訳プログラム
すなわち誂えられた翻訳プログラム１７２を規定してい
るか否かを決定するため、１７１において点検する。専
門化された翻訳プログラム１７２が規定されている場合
を除き、翻訳演算は、省略プロセスを呼出す。省略プロ
セスの間に、翻訳演算は、対応文書のデータベースに記
憶された翻訳の位置を１７３と同様に決めるために、ク
ライアントが提供した文書ハンドルを使用する（すでに
記載した通り、データベースは、同じハンドル名の下に
、同じ文書の複数の翻訳を含むことができる。これは、
すべての翻訳が、例えば２４時間のような所定の期間の
間、記憶されるからである）。その後、このプロセスは
、１７４と同様に、このプロセスが位置付けした翻訳の
フォーマットを、クライアントが規定した翻訳フォーマ
ントに対して比較する。受諾することができるフォーマ
ットを有する翻訳が記憶されていることが発見された場
合、そのファイル名と位置が、プロセス結果ファイル６
６中への記録のため、１７５において出力され、その後
、翻訳プログラム１７０は終了する。反対に、受諾する
ことができる書式の翻訳が発見されない場合、翻訳プロ
グラム１７０は、１７７と同様に、利用することができ
る翻訳のいずれかをクライアントが要求するフォーマッ
トに変換することができるか否かを決定するため、調査
テーブルを点検する。翻訳することができない場合、翻
訳プログラム１７０は、１７８と同様に、「翻訳不能」
エラーを報告した後、終了する。もちろん、要求される
場合、翻訳プログラム１７０に追加変換を追加すること
ができるので、追加変化が含まれていることを保証する
ために十分な頻度で変換が要求される場合、追加変換を
提供することができ、追加変換を含めるために調査テー
ブルを最新化することができる。

クライアントのためにフォーマント変換文書の翻訳を準
備するため、図示された省略翻訳プロセスは、変換され
た翻訳のためのサーバ割り当てファイル名が付いた一時
フアイル１８０をデータベース・サーバに作らせる。こ
の−時ファイルの名称と位置は、結果ファイル６６中に
記録するため、１８１において出力される。その後、外
形データベース２４（第３図）から変換しなければなら
ない文書を省略プロセスが検索し、１８３において、所
要のフォーマットへ変換させ始める。文書の、フォーマ
ットされ、変換され、コード化された表示は、作られて
いる間に一時フアイル１８０中に書き込まれるので、文
書が十分に変換される前であっても、クライアントは変
換の部分的結果を利用することができる。変換１８３が
完了すると、翻訳プロセス１７０は、結果ファイル６６
中への記録のため、変化の完了を報告し、１８６におい
て示されている通り、変換された翻訳を外形データベー
ス（第３図）の記憶メモリ一部分４１に記憶する。

個々のユーザーまたはユーザー・グループは、自己が検
索する翻訳を自己の要件に合わせて誂えるため、専門化
された翻訳プログラム１７２を使用することができる。

翻訳は「適時」方式で作ることができるので、外形デー
タベース２４（第３図）のために過度の文書記憶容量を
必要とすることなく、事実上無制限の種類の翻訳を提供
することができる。事実、ユーザ／クライアントは、ユ
ーザが翻訳を見たいと願う異なった環境状態、または、
異なった出力装置が置かれている環境状態に対して幾分
なりと最適化された翻訳を作るために、異なった時にお
いて異なった専門化翻訳プログラム１７２を呼出すとい
う、翻訳プログラム１７０の「適時」翻訳能力を利用す
ることができる。

例えば、文書のビットマツプ翻訳を誂えるために、比較
的率直な専門化翻訳プログラム１７２を提供することが
できる。代表的な場合、この翻訳オプションは、プログ
ラム・アーギュメントの第１のストリングとして、その
オプションの名称（すなわち、「ラスタシュリンク」）
を規定することによって呼出されることになる。そのオ
プションはまた、誂えられたビットマツプ翻訳の最適、
最低と最高のピクセル内容をｘ、　　ｙと２軸に沿って
規定するため、９つのその他の整数アーギュメント　（
独立した１０進八５ＣＩＩストリングとしてコード化さ
れた）を必要とすることになる。ラスタシュリンク翻訳
オプションは、そのようなアーギュメントを、下記の順
序で解釈することができる：　　ｗｉｄｔｈ、　ｈｅｉ
ｇｈｔ、　ｄｅｐｔｂ、　ｍ１ｎＷｉｄｔｈ、　ｍｉｎ
ｌｌｅｉｇｈｔ。

ｍ１ｎＤｅｐｔｈ、　ｍａｘＷｉｄｔｈ、　ｍａｘＨｅ
ｉＨｈｔとｍａｘＤａｐｔｈ　。

その場合・アーギュメント（ｒｅｎｄｅｒ、　ｒａｓｔ
ｅｒｓｈｒｉｎｋ＋１５０、１５０．１．６４．６４．
１．２００．２００．１）を伝えることによって、（６
４ｘ６４ｘｌ）と（２００ｘ２００ｘｌ）の間のビクセ
ルを含むｘｙｚ境界ボックスを有するビットマツプ翻訳
を準備するために、翻訳演算プログラム１７０が要求さ
れることがある。ｘｙｚ境界ボックスの望ましいサイズ
は、（１５０ｘ１５０ｘｌ）ピクセルであると規定され
ている。

Ｄ、ユーザ・インターフェイスの倒 木発明を利用するため、様々なユーザ・インターフェイ
スを使用することができる。データベース・システムの
特定の用途のために、一部のユーザ・インターフェイス
を専門化することができ、他のユーザ・インターフェイ
スをさらに一般化したものとすることができる。下記に
いくつかのウィンドウ型インターフェイスを説明するが
、それらの例は、少数のインターフェイス・オプション
を図示するだけであることを理解しなければならない。

第１０図は、Ｓｕｎワークステーションのユーザが、（
ａ）関連入力スキャナーをセットし、走査人力された映
像のビットマツプ表示を１つのウィンドウ２０２内で見
ること、（ｂ）常駐文字認識プロセスのためのオプショ
ンをセットし、認識されたテキストを第２のウィンドウ
２０３内で見ること、および、（（Ｊ新しい文書および
／または新しい記述を本発明のデータベースに入力する
ためのオプションをセントし、そのような外形の、サー
バを作りクライアントが規定したフィールドを、第３の
ウィンドウ２０４内で見ることができるようにするため
に、Ｓｕｎ　［Ｉｎ１ｘ　”５ｕｎｔｏｏｌｓ”環境に
おいて実行されるユーザ・インターフェイス２０１を示
す。

次に、第１１図は、他の１つのユーザ・インターフェイ
ス２１１を示す。このユーザ・インターフェイス２１１
は、Ｓｕｎ　Ｕｎｉｘ　　５ｕｎｔｏｏｌｓ″環境を基
礎としており、ユーザが、（ａ）本発明のデータベース
に探索照会を入力し、探索の結果をスプリット・ウィン
ドウ２１３の上部２１２にデイスプレーすること、（ｂ
ｌ照会突き合わせ記述をウィンドウ２１３の下部２１４
内で走りまたは拾い読み（ブロース）すること、および
、（Ｃ）対応文書外形を他のウィンドウ２１５内でデイ
スプレーすることができるようにする。

第１２図は第１１図に類似しているが、ただし、ユーザ
・インターフェイス２２１はＳｍａｌｌｔａｌｋ−８０
環境内で実行されることと、完全な解像度とサイズでデ
イスプレーする（すなわち、翻訳する）だけ十分な興味
があるか否かを決定するためなどの目的で、２２２にお
いてのように、縮小された解像度／縮小されたサイズの
外形の表示をプレビューする機会をユーザに与えるとい
う追加機能を有していることが第１１図とは相違してい
る。

結論 上記を考慮すれば、本発明が、異なった文書コードフォ
ーマットを利用する計算環境にコンピュータ・ユーザが
属している場合であってさえ、コンピュータ・ユーザが
、電子文書を人間の知覚レベル（すなわち、外形レベル
）において交換し、共有することができるようにするこ
とが理解されるであろう。必要なフォーマット変換はす
べて、ユーザ・クライアントの局部計算資源に負荷を課
すことなく、また、クライアント・アプリケーションの
側にユーザが翻訳したいと望む文書のコードフォーマッ
トに関する先旦麹左知識を要求することなく、ユーザ・
クライアント・アプリケーションのために実行される。

さらに、提供される翻訳は、一般に、翻訳される文書の
オリジナル外形に忠実であるため、原文書の精神物理学
的に重要な情報内容を木質的に保存する。

また、本発明を実行するために提供された遠隔手続き呼
出しプロトコルが、クライアントが、クライアントが呼
出した遠隔手続きの完了を待つことを要求され′ること
なく、クライアントが呼出した遠隔手続きの部分的結果
を迅速に取得することができるようにすることが認めら
れるであろう。

遠隔手続き呼出しとともにクライアントに戻される実行
〜サーバー推定は、クライアントが、クライアントの個
々の要件を最高に満足させる参加レベルに基づいてクラ
イアントが呼出す遠隔手続きによって、クライアントの
参加を最適にすることができるようにする。

【図面の簡単な説明】

第１図は機能ブロック図であって、本発明の１つの局面
にしたがった、外形と記述としての文書の記録を示して
おり、文書と記述データの流れは実線で、演算アーギュ
メントの流れは右向き矢印が付いた破線で、結果データ
の流れは、左向き矢印が付いた破線で、それぞれ示され
ている。 第２図は機能ブロック図であって、本発明の他の局面に
従った記述データベース探索を図示するため、第１図の
場合と同じタイプの線を使用している。 第３図は機能ブロック図であって、本発明のまた別の局
面に従った文書外形の翻訳を図示するため、やはり、第
１図の場合と同じタイプの線を使用している。 第４図はブロック図であって、本発明の特定の実行を図
示している。 第５図はフローチャートであって、第４図に示された実
行のための主サーバを図示しており、プログラムの制御
流れは実線で、結果データの流れは破線で、ジョブ・テ
ーブル・アクセスは点線で、それぞれ示されている。 第６Ａ及び６Ｂ図はフローチャートであって、第４図に
示された実行のための代表的なりライアント・アプリケ
ーション・プログラムを図示しており、プログラム制御
流れは実線で、データ流れは破線で、それぞれ示されて
いる。 第７図はフローチャートであって、第４図に示された実
行のデータベースに新しい文書および／または記述を追
加するためのＮｅｗＤｏｃＤｅｓｃを図示しており、プ
ログラム流れは実線で、結果データ流れは点線で、文書
データ流れは破線で、それぞれ示されている。 第８Ａ図はフローチャートであって、第４図に示された
実行のためのＤｅｓｃｒｉｐｔｉｏｎＳｅａｒｃｈ演算
を図示しており、プログラム流れは実線で、データ流れ
は、単一探索パターンの場合が点線で、複数探索パター
ンの場合が破線で、それぞれ示されている。 第８Ｂ図はフローチャートであって、第４図に示された
実行のためのＤｅｓｃｒｉｐｔｉｏｎＳｅａｒｃｈ演算
を図示しており、プログラム制御流れは実線で、第２順
位とより高い順位のフィルタリングのためのデータ流れ
は点線と破線で、それぞれ示されている。 第９Ａ及び９Ｂ図のフローチャートであって、第４図に
示された実行のためのＤｅｓｃｒｉｐｔｉｏｎＳＢａｒ
ｃｈ演算を図示しており、プログラム制御流れは実線で
、結果と文書データ流れは点線と破線で、それぞれ示さ
れている。 第１０図は、本発明に従って文書を走査し、文書のテキ
ストを認識し、文書のテキストとその記述をデータベー
スに人力するためのユーザ・インターフェイス・ツール
を図示する。 第１１図は、本発明に従って文書記述を探索し、そのよ
うな記述とそのような記述の対応外形をデイスプレーし
拾い読み（ブロース）するためのユーザ・インターフェ
イス・ツールを図示する。 第１２図は、文書記述を探索、デイスプレー拾い読み（
ブロース）するため、および、大きさと解像度の異なる
文書外形をデイスプレーし、拾い読み（ブロース）する
ためのユーザ・インターフェイス・ツールを図示する。

Claims (1)

1. 【特許請求の範囲】 別種のハードウェア構成と別種のソフトウェア演算環境
   を有するコンピュータ上で実行されているクライアント
   ・アプリケーションとインターフェイス接続され、上記
   コンピュータ中の各異なったコンピュータは完全にフォ
   ーマットされた電子文書の読み出しと書き込みのために
   いくつかの異なったコードフォーマットを利用している
   データベース・システムにおいて、 上記クライアント・アプリケーションのいずれかの要求
   に基づいて上記コードフォーマットのいずれかに書き込
   まれた電子文書を記憶するための外形データベースと、 上記クライアント・アプリケーションのいずれかの要求
   に基づいて上記データベースに記憶された電子文書のい
   ずれかにアクセスするために上記データベースに結合さ
   れている翻訳手段とで構成されており、上記翻訳手段に
   は、上記データベースに記憶された、少なくともいくつ
   かの文書のコードフォーマットを、利用中のコンピュー
   タ上で実行されているクライアント・アプリケーション
   のための他のコードフォーマットに変換する手段が含ま
   れ、上記他のコードフォーマットを利用しているコンピ
   ュータによる検索のために、上記文書の精神物理学的に
   等価である翻訳を提供することを特徴とするデータベー
   ス・システム。