JP2003514300A - 任意数成分対任意数成分対応コンピュータシステム - Google Patents

Abstract

(57)【要約】 【課題】 任意数成分対任意数成分対応コンピュータシステムを提供すること。 【解決手段】 任意数成分対任意数成分対応コンピュータシステムのための一般的なデータ及びソフトウェアの構造及び方法である。当該コンピュータシステムにおいては、任意成分の任意数は、本質的に階層構造でなく且つ本質的に限定されていない任意の他の成分の任意数に関連付け可能である。当該構造と方法は階層構造の概念を有しており、各概念或いは概念のアセンブリは、唯一に特定され、番号の概念言語における数字、或いは番号でない概念言語において唯一に認識される。各成分或いは集合体は、本質的に、共通した或いは関連した成分を含む他の全てのデータ項目に関係付けられている。

Description

【発明の詳細な説明】

【０００１】 本発明は、一般にコンピュータシステムの分野に関わる。本発明は特に詳細に
は、ヒトのデータ操作を模倣することが可能なコンピュータシステムに関わる。
さらに詳細には、本発明は、ヒト型の情報処理をシミュレートし、コンピュータ
システムとの自然言語通信を可能とする、任意数対任意数対応コンピュータシス
テムに関わる。

【０００２】 （関連申請の参照） 本申請は、１９９９年１１月１２日登録の、米国暫定申請第６０／１６４，８
８４号の効果を本申請に属するものとして請求する。

【０００３】 （発明の背景） コンピュータシステムの受容と使用は、同システムの使用をより易しいものと
することができるならば、目覚しく増加させることが可能であろう。しかしなが
ら、コンピュータの使用を簡単にする行程は、現在障害に突き当たったようであ
る。なぜなら、従来のコンピュータシステムは、情報を、限定された、階層的な
やり方で処理しており、そのやり方は、ヒトが情報を処理する、無制限的、非階
層的やり方とは基本的に相容れないものだからである。

【０００４】 従来技術においては、ソフトウェアやデータの構築・保存は、１対多数装置の
要求に合致するようになっている。１対多数装置とは、「そこにおいては、一つ
の集積構造が、１個以上の集積構造にたいして、内在的に階層的で、かつ、内在
的に制限的なやり方で、固定的な関係を有する装置」と定義される。今日のソフ
トウェアにおいては、この固定関係は、通常、ユーザーが変更不可能なプログラ
マー創成関係である。従来技術全体に見られるこの状況は、一つの工場に例えら
れる。すなわち、エンジンの組み立てに従事する工場に、ある特定の部品、例え
ば、ある特定のネジだけが配送され、そのネジは、エンジン内部のただ一箇所に
しか認められない、という状況である。その特定のネジを他の場所に使うことが
できるようにするためには、例えば、それを、クルマのドア取り付けに使うよう
にするためには、唯一の解決法は、ドライバーまたはレンチのような道具を用い
て、エンジン内部に挿入し、必要な部品ネジを外し、それをドアの取り付けに使
用することである。従来技術においては、上記ドライバーやレンチに相当する道
具は、ＯＬＥやデータ輸入／輸出ソフトウェアツールのような道具であって、こ
れらによって、部品が保存される集積体から部品を抽出することが可能となる。

【０００５】 従来のコンピュータシステムでは、使用が簡単になるよりはむしろ、システム
の機能性が増すにつれて必然的に使用が難しくなっている。コンピュータ業界は
従来からこの問題を緩和するための試みを行っている。例えば、アプリケーショ
ンをさらに直観的なものにすることによって、ユーザーインターフェイスをより
ユーザーフレンドリーなものとするためにいくつかの試みが為されてきた。言語
処理を、そのアプリケーションと結合させたシステムさえあった。にも拘わらず
、従来のコンピュータシステムのほとんど全てにおいて、ヒトは、自分のコンピ
ュータシステムのように「考える」ことをより習得することによって、より効率
的にそのコンピュータを使いこなせるようになると教育されている。すなわち、
ヒトは、コンピュータとの作業経験を増すにつれて、コンピュータとより効率的
な相互関係を持つようになるとされる。この親密化行程は、効果的な文書化によ
ってさらに加速することが可能ではあるけれども、新しいコンピュータシステム
の使用法を習得する際には、登らなければならない学習曲線が必ずある。その結
果、さらに機能性が付加されればされるほど、その制御法を習得する際のユーザ
ーの困難は益々大きくなる。従って、オフィスタイプのソフトウェアは自己制限
的となる。なぜなら、多くのユーザーは、その機能の１０％を越えて使用するこ
とはないからである。機能性が付加されるにつれて、複雑性が飛躍的に増してい
る。多くの高機能プログラムは、強化されるとクラッシュの頻度が増す。その結
果、現在のソフトウェアの多くは、その複雑性のために自己制限的となっている
。上記のように、従来技術は、改善すべき多くの点を抱えている。

【０００６】 従来のソフトウェアシステムはさらに、修理、維持、および、アップグレード
が難しい点では定評がある。ソフトウェアシステムがより強力に、複雑になるに
つれて、単純であるべき作業、例えば、従来バージョンや、他のシステムとのコ
ンパティビリティの維持を実現する能力の実現が次第に困難になっている。この
ような困難は、全ての最高級ソフトウェアが、事実上、１対多システムとして構
築されているために生ずるものである。このために、ある単一ソフトウェア断片
、例えば、ワードプロセッサーは、その文書フォーマット、スクリーンディスプ
レー、その創成する文書、その知っている出力法等などに固定的に関与すること
になる。プログラムの作成中にこのような固定的な関係が導入された時点から、
同プログラムの操作するデータを他の用途に使用することは、プログラマーやユ
ーザーの介入無しでは、難しくなる。さらに、ユーザーの介入は、プログラマー
が、ユーザーの介入を可能にするツールを供給しない限り、不可能である。もと
もとはコンパティブルとなるよう意図されたものの、導入行程においてアイテム
の上にアイテムを重ねていくうちにどこかが間違って完全にはコンパティブルで
はなくなったソフトウェアシステム同士、それらのコンパティビリティを単に維
持しようとするだけのために、これまで数百万時間の作業時間が費やされてきて
いる。この問題は、現在では、進化するソフトウェアシステムの内在的特徴であ
るように見える。その結果、ソフトウェア開発業者は、絶えざるアップグレード
およびコンパティビリティ問題と取り組むためのスタッフと予算の必要を受け入
れてきた。

【０００７】 従来のソフトウェアシステムはまた驚くほど冗長である。この冗長は、従来の
全てのアプリケーションプログラムに付きものの、閉鎖的特徴から生ずる。例え
ば、１対多原理に沿って構築された様々なプログラムは、会計ソフトウェア用や
、Ｅ−ｍａｉｌソフトウェア用に別々のアドレスリストを保存する。従って、そ
のようなソフトウェアをロードしたコンピュータには、二つの異なる組のコード
が存在し、かつ、各組のコードは、同一の、または、類似の結果を実現すること
になる。同一のコンピュータに、各々異なる１対多プログラムに属する、いくつ
かの別々のアドレスリストが搭載されることは珍しいことではない。オブジェク
ト指向ソフトウェアの登場は、機能性の比較的高レベルにおいてこの問題を緩和
したけれども、低レベルにおいては、問題は依然として緩和されないままである
。言いかえれば、オブジェクト指向プログラムでさえ、比較的低レベルの作業、
例えば、データをメモリーから抽出すること、データをディスプレー装置に出力
すること、または、数学的・論理的操作を実行すること等の作業のためには、繰
り返し指令をプログラムするのである。以上から、従来技術における核心的問題
は、ソフトウェアと、ヒトのデータ操作との間の、基本的なシステムミスマッチ
である。

【０００８】 従って、当分野においては、使用、修理、維持およびアップグレードがより簡
単なコンピュータシステムにたいしては需要がある。さらに、不要な冗長を回避
させるコンピュータシステムにたいしても需要がある。さらに、データを、無制
限な、非階層的基盤で操作することが可能なコンピュータシステムにたいしても
需要がある。

【０００９】

【発明が解決しようとする課題】

本発明は、上記事情を鑑みてなされたもので、任意数成分対任意数成分対応コ
ンピュータシステムを提供することを目的としている。

【００１０】

【課題を解決するための手段】

本発明は、ヒトの情報処理をシミュレートするように構成される、任意数対任
意数対応コンピュータ装置において上記需要に応えるものである。任意数対任意
数対応装置とは、「そこにおいては、いかなる成分または成分集合体も、任意の
数の成分または成分集合体に、内在的に階層的でなく、内在的に非制限的なやり
方で関係付けることが可能な装置」と定義される。コンピュータシステムに関連
させてさらに詳細に言えば、任意数対任意数対応装置とは、「そこにおいては、
任意の数の成分または成分集合体が、任意の数の成分または成分集合体に、内在
的に階層的でなく、内在的に非制限的なやり方で関係付けることが可能なコンピ
ュータ装置」と定義される。この任意数対任意数対応装置は、ユーザーデータ、
装置データおよびソフトウェアを含むと定義されるデータに関連して記述される
。従って、本装置の定義はさらに細かく、「そこにおいては、任意の数の、任意
のデータ成分またはデータ成分集合体が、任意の数のデータ成分またはデータ成
分集合体に、内在的に階層的でなく、内在的に非制限的なやり方で関係付けるこ
とが可能なコンピュータ装置」と述べることが可能である。しかしながら、本任
意数対任意数対応装置の原理および基礎法は、同様に、ハードウェアの構築にも
適用拡張が可能であることを理解しなければならない。もしもそのように適用さ
れるならば、装置は、相当の付加的効果を生み出すことが可能である。なぜなら
、その場合、ハードウェア、ソフトウェア、および、ヒトユーザーの全てが、同
じ、任意数対任意数対応装置の基本原理に則って動作することになるからである
。

【００１１】 任意数対任意数対応装置の使いやすさ、パワーおよび有用性は次の事実から派
生する。すなわち、ヒトユーザーは、言葉で表わされるようなデータは、任意数
対任意数原理に則って操作することが可能なのである。逆に、現在の最高級ソフ
トウェアは使用が難しいが、それは、ヒトユーザーの、任意数対任意数的データ
処理法と深刻に、かつ、基本的に対立する、１対多原理の上に構築されているか
らである。

【００１２】 従来のコンピュータシステムとは違って、この任意数対任意数コンピュータシ
ステムは、全てのデータとソフトウェア入力を、非分割的で、再生可能な成分に
分解する。この成分の中には、データベースのような、その中において装置その
ものが構築される構造に関するデータも含まれる。任意数対任意数装置は、各成
分を、個別の記録として保存し、次に、様々な道具を介して、それら成分を相互
にタイプによって関連づける。すなわち、各データ成分は、ある明瞭な意味を有
するが、それ以上分解されたら、その意味の完全性を失ってしまうという、その
ような意味を有する。さらに、各ソフトウェア成分は、それ以上分解されたら、
その有用な機能的完全性を失ってしまうという、ある単一の機能を実行する。次
に、このように分解することによって、いずれのタイプのデータ成分またはデー
タ集合体であっても、１個以上のソフトウェア成分、または、ソフトウェア成分
集合体と平行に並べる、または、特異的に関連させることが可能となる。これら
ソフトウェア成分、または、ソフトウェア成分集合体は、関連付けられたデータ
成分タイプまたは集合体タイプを処理するように構成されるものである。この構
造によって、任意のデータ成分またはソフトウェア成分を、他の任意のデータ成
分またはソフトウェア成分と相関させることが、その相関に第三成分を必ずしも
介在させる必要なく、可能となる。その結果、各データおよびソフトウェア成分
、または、成分集合体の単一例にたいし、多数のソフトウェアモジュールにおい
て、また、多数のソフトウェアモジュールによって、使用のために、独立に、直
接にアクセスすることが可能となる。さらに、このアクセスは、階層的やり方、
非階層的やり方のいずれでも実行が可能である。このようなアクセスレベルの設
定は、コンピュータシステムにおける冗長を回避し、修理、維持、および、アッ
プグレードを単純化する。さらにこれによって、ある単一のソフトウェア成分ま
たは成分集合体が、同じデータタイプの、異なる事例に作用すること、あるいは
、目的の成分の動作を制御する外部的な保存条件や、他の外部的に保存されるデ
ータを変更することによって、全く異なるデータタイプにたいしても作用するこ
と、が可能となる。

【００１３】 この任意数対任意数コンピュータ装置は、通常、データと、ソフトウェアコー
ドとを、データ関連表の中に保存する。この表は、データベースに保存される全
てのデータとソフトウェア成分にたいして普遍的インターフェイスとして機能す
るデータ分類構造を含む。このデータ関連表機構は、データ成分集合のための、
また、過去に集合された構造のさらなる集合のための、事実上集合プランとなる
ものであるが、クルマや飛行機の組み立てプランと類似のものである。これらの
車両は、ネジ、ボルトやナットのような、単一機能の、個別部品から建造される
。クルマや飛行機を組み立てる工場においては、これら単一機能部品は、保存箱
に貯えられ、次に集合せられて、完全なクルマや飛行機を生み出す。

【００１４】 任意数対任意数コンピュータ装置においては、データは、通常、ユーザーから
、部品としてではなく、集合体として受け取られる。例えば、どのような単語で
あっても、それは、最小限、その単語そのものプラス、それに伴う、目に見えな
い概念または意味の集合体である。例えば、「ファックス」のような単語の場合
、伝達されたこの単語は、事実上、単一の単語（ファックス）プラス、同単語の
１ダースを越える個々の意味成分から成る集合体である。しかしながら、上記成
分原理を導入しないならば、さらにそれ以上使用しようとして、ヒトの慣れ親し
んだやり方で、個々の成分に簡単に、滑らかに、弾力的にアクセスしようとして
も、それは通常不可能である。理由は単純で、個々の成分にアドレスする、また
は、参照する簡単な方法がないからである。

【００１５】 もしも成分原理概念をこの問題に適用し、かつ、個々の成分をそれぞれに保存
するならば、いかなる成分も個々に参照することが可能となり、従って、任意の
他の成分と共に使用することが可能となる。この分解行程が無いと、集合体その
ものが１対多集合体（１単語、数個の意味）となり、従って、いかなる単一成分
であれ、同時に他の全ての成分を使用することなしには、使用することが不可能
になる。この非弾力性が、従来技術の慣行の基礎に横たわる問題である。

【００１６】 従って、ユーザーまたはその他の場所から受け取ったデータ集合体を先ず分解
し、それから、タイプごとに―例えば、工場の物理的部品箱と同様の、データク
ラス記録として、成分形として保存する必要がある。単語とその意味のようなデ
ータの場合には、このタイプ分けは―これが本発明の特徴であるが―文法、シン
タックス、または、確率のような一般に使用される機構には依らず、むしろ、意
味や機能に依って行う。次に単語は、文法的分類ではなく、意味によって関連付
けられるから、意味の違い、類似や内容を、特定単語の文法的分類と無関係に、
見つけ出し使用することが可能である。例えば、任意数対任意数装置においては
、「招待する」、「招待」、「招くように」という単語は、全て、共通の語幹の
意味によって関連付けられ、これによって、実験によって接頭語・接尾語の様々
の組合せを用いて創成することが可能であると示されたように、その他に、全部
で１４，５００個の、「招待」に関する、理解可能な変種が関連付けられること
になる。

【００１７】 一旦分解され、保存されたならば、データ成分は、使用のために利用が可能で
あり、いかなる有効な組合せにおいても集合が可能であり、その際、各集合体は
、１個以上のデータ関連表記録に記録される。この成分原理による任意数対任意
数装置を構築する際に望ましい一つの原理は、現在従来技術では普通のものとな
っている、ある一つのデータ成分または成分集合体、および、他の成分または成
分集合体の間に設けられた、プログラマー創成の固定関係を極小化する能力であ
る。理想的には、これらの固定関係は、当面の用途のために、できる限り排除す
べきである。従来のデータベースでは、プログラマーが、データベース中のある
フィールドにあるフィールド名またはラベルを与え、そのデータベースを使用す
るユーザーインターフェイスの同じフィールドには別の名前を付与することがし
ばしばあった。次に、その名前またはラベルが画面に表示されるが、この最初の
名前も同時に変更しない限り、もう一つの名前を画面に表示することは不可能で
あった。その結果、このプログラマーは、あるフィールドと、特定のフィールド
の表示を可能とする唯一のラベルとの間に固定した関係を創成することになって
しまった。任意数対任意数装置では、このようなデータベースフィールド名は、
ユーザーに関する限り、あたかもそれらが存在しないものであるかのように処理
することによって、データベースそのものにおいて分解される。その代わりに、
任意の数の異なるラベル記録が、その記述するデータの特定タイプの利用法とフ
ィールド的に平行となるようなやり方でデータ関連表に保存される。任意数対任
意数インターフェイスを持つ出力機構によって、どの記録であれ、各フィールド
中の内容を利用して、出力されるフィールドにたいして、あるいは、フイールド
同士の組合せにたいして、新規ラベルまたは再表示ラベルを付与することが可能
である。従って、どのようなフィールドにたいしてもどのようなラベルを付与す
ることも可能であり、また、個々のユーザーが、たまたま彼等に適合する任意の
やり方で、任意のタイプのデータにラベルを付けることが可能である。データは
さらに、ある任意の出力において、単に別の記録言語を選択するだけで、他の言
語で再表示することすら可能である。

【００１８】 既存の１対多ソフトウェア構築法は、データを眺める人の好みに従って、デー
タ出力の方法や表示法を変更することを極めて困難にする。本発明は、いかなる
データの入力・出力も、各個人ユーザーに適合するように変更することを可能に
することによって、重要な使いやすさ要素を導入する。

【００１９】 さらに、表示されたフィールド名と、データベースフィールド名とを分離し、
また、データを操作するソフトウェア機構を、その結果を出力する機構と完全に
分離する成分原理を用いることによって、いかなるデータベースフィールドに関
しても、異なる目的、異なるタイプのデータ、または、異なるユーザーのために
要求される度毎に、好きなだけ再表示が可能となる効果がもたらされる。あるデ
ータベースフィールドにおけるフィールド再表示を可能にすることは、さらに重
要な付加的効果を持つ。すなわち、事実上、単一使用データベースであっても、
内在的にはいかなるデータを記録することも可能な、潜在能力としては普遍的デ
ータベースになり得るという効果である。さらに、いかなるデータでも記録可能
な能力は、全てのデータを、単一の標準フォーマットに記録することを可能にす
る。これによってさらに、全てのデータを単一構造の中に、または、機能的に類
似であって、大きな変換無しに伝送データを受容することの可能な、複数の構造
の中に記録することが可能となる。データ項目間の関係は、そのもっとも基本的
なレベルにおいては、単一成分間における共通性に、または、共通性の欠如にあ
り、また、任意の成分は、ただ一つの場所、例えば、ただ一つのフィールドにし
か存在しないという事実のために、関係の（または、関係欠如の）発見ははるか
に容易になる。さらに、様々のデータ集合体間に実際に存在する関係を、はるか
に容易に、見出し、表示し、または、その他使用することが可能である。データ
項目間の類似性、相違性、同一性、および、近似性は、任意のデータ項目におけ
る、個々の成分および／または成分集合体の存在または欠如に基づいてのみ確実
に実行することが可能なのであるから、この保存の成分原理を、成分を単一の構
造、または、相互に通信可能な複数の構造に保存可能な能力と併用するならば、
それによって、任意数対任意数装置は、類似性、相違性、同一性、および、近似
性を確実に、ヒト的なやり方で計算することが可能になる。

【００２０】 同様に、また、さらに別の例として、表同士の間において、従来のプログラマ
ー創成関係は通常回避される。なぜなら、そのような関係は、成分原理に反する
からである。一つの表のデータと、別表データ間における、単一の、固定的な、
プログラマー創成関係―例えば、ある表の記録数であって、同時に別の表に埋没
されている記録数がそうであるが―は、可能な、潜在的には数十億となる他の関
係を創成するのに、さらにプログラマー創成の機構を必要とする。従って、任意
数対任意数装置のソフトウェア構築は、ヒトが、データ間に、好みの関係を創成
することを可能とするように仕向けられる。一方、従来技術においては、通常、
データ間の関係を創成するのはプログラマーである。それでいて、既存のプログ
ラミング行程は、ヒトの能力や、ヒトが単語を操作して、データ間にかって存在
したことがない関係を創成するスピードについていくにはあまりに遅すぎる。コ
ンピュータを使用する人々の多くはプログラマーではなく、現在のソフトウェア
法を用いて直ぐに関係を創成することはできない。それなのに、実際には、言語
上の、ヒト対ヒトのデータ伝達は、データを表わすシンボル機構、すなわち、文
字や単語を用いて、データ間の特定の関係を伝達することから成っている。

【００２１】 成分原理は、データ部分をタイプで分解するが、その分解を、それ以上分解す
ると、その部分の元の意味や機能の全体性を失うことになる程度にまで行うこと
を要求する。次に、この分解されたデータをタイプ毎に保存し再使用に備える。
任意数対任意数コンピュータ装置においては、この原理はハードウェアにたいし
てだけでなく、まとめてソフトウェアと呼ばれる、様々のタイプの物の構築にも
適用される。こうした考えでは、従来大きな固まりとして構築されていたソフト
ウェアは分解されなければならない、または、そのソフトウェア自体；後述する
ように、それに参照される概念言語数；他の記録への参照；必要に応じて、また
、データ関係表の許す媒体によって限定されるディスクファイルへの参照等を含
むフィールドや記録として記述されなければならない。

【００２２】 任意数対任意数装置では、ソフトウェアは、様々なタイプまたはカテゴリーに
分解され、次に、データ関係表記録に記録される。このようなソフトウェア記録
タイプの実例は、実行記録である。すなわち、それぞれのフィールド中の実際の
コードまたはコードすべき引例を含む記録タイプ；記録を含むラベル記録；コー
ドの作用する条件を含む条件記録；ユーザーに入力を促すプロンプト記録；ヘル
プを含むヘルプ記録等である。共同作用時は、様々の記録タイプは、モジュール
と呼ばれる。一般に、単一フィールドのコードは、ラベルまたはプロンプト記録
における同じフィールドの値と同様、全て、同じフィールドに適用される。これ
が、フィールドパラレル構築と呼ばれる方法である。

【００２３】 本方法の特徴的で、強力な効果は、「もし見つからなければ」条件記録と呼ば
れる、特定の条件記録サブタイプを使用した場合に発揮される。この記録は、そ
のデータフィールドにある特定の条件を含む。「指令フィールド」と名づけられ
る実行フィールドにおいて、この記録は、「もし見つからなければ」条件記録に
含まれる条件がマッチした場合に為すべきことを記載した１個以上の記録を含む
、または、指定することが可能である。別態様として、指令フィールドではなく
、フィールドパラレル指令記録タイプを、「もし見つからなければ」条件記録に
たいする適合ペアとして使用することも可能である。この機構は、同様に設置さ
れた任意数対任意数原理の上に構築された任意の数の装置を効果的に融合すると
いう独特の利点を有し、それらの装置が、そのデータとソフトウェア能力におい
て、透明な全体として作動することを可能にする。

【００２４】 成分原理法を、データとソフトウェアの両方に適用すると、独特の新規の効果
が得られる。すなわち、何か特定タイプのデータが、成分として、または、成分
の集合体として存在している場合、それにたいして、ある１個のソフトウェア成
分、または、複数のソフトウェア成分、あるいは、ある１個のソフトウェア集合
体、または、異なるタイプの複数のソフトウェア成分集合体を正確にかつ厳密に
平行させることが可能である、ということである。従って、これらの成分または
成分集合体は、いずれのデータタイプにたいしても厳密な変換を実行することが
可能である。言いかえれば、ある特定のタイプのデータ集合体が存在する場合、
そのデータ集合体を処理するために、特定のタイプのソフトウェア集合体を構築
することが可能である。データタイプは、成分レベルから上に向かって、データ
関連表を通じて、ある任意のデータ変換またはディスプレーを実行するのに必要
な、特定のソフトウェア成分あるいは集合体と関連させることが可能であるから
、これまで未知のデータ成分集合体を特定するユーザーの行為が直ちに、ユーザ
ーの注文したその作業―変換、表示、あるいは、出力―を実行するのに必要なソ
フトウェア成分の集合体を創成することになる。これによって、ユーザーの特定
したデータが、次には、それを処理するのに必要とされるソフトウェア成分の瞬
間的な集合を駆動するという、独特の、新規の効果がもたらされる。この独特の
自発性は、従来技術と正反対である。なぜなら、従来技術においては、ソフトウ
ェアの構築そのものがデータと、受容可能なデータ関係を規定するからである。
その他の効果としては、任意数対任意数装置は、どのようなデータでも受容し操
作することが可能であるので、十分なソフトウェア成分が与えられる限り、ヒト
ユーザーは、その任意数対任意数装置の制限、限界、または、規則を学習する必
要はもはやないということがある。なぜなら、その装置は、ユーザーの欲するも
のは何でも受容することが可能だからである。使い易さは、実質的に、飛躍的に
向上する。

【００２５】 任意数対任意数装置の構築に関する、その他の教示としては、ソフトウェア成
分は、ほとんど完全にデータタイプを処理するために構築されるが、特定のデー
タ例を処理するためにはほぼ絶対的に構築されないということがある。例えば、
あるＥ−ｍａｉｌアドレスを、ユーザー名とドメイン名から成る成分に分割する
ことが可能な、単一ロジック断片は、Ｅ−ｍａｉｌアドレスを特定的に分割する
ために書き込まれてはおらず、どのような値でも、その成分に分割するように書
き込まれている。そのロジックが分割すべきもの、分割のための根拠としてそれ
が使用するもの、その結果を設置する場所、これらは全て、特定の記録タイプに
おける、その他の記録またはフィールド値によって特定される。従って、何を分
割するためにも、ただ一つの、実際のコード断片が必要とされるに過ぎない。さ
らにそれ以外の、独特の効果的利点としては、大量の操作が、このタイプの一般
的ロジックによって処理が可能であるということがある。通常の設置条件の場合
、ファックス、Ｅ−ｍａｉｌ、手紙、または、会計のような、いずれのデータタ
イプであっても、全てのデータタイプを創成するのに、ただ一つのモジュールが
必要とされるだけである。この一般的モジュールは、「ボスモジュール」から供
給される特定の記録や指令に基づいて様々に振る舞う。ボスモジュール、すなわ
ち、他のモジュールを動かす、従ってただ一つの機能を実行するだけのモジュー
ルにはただ一つのタイプしかない。任意数対任意数装置では、Ｅ−ｍａｉｌを創
成するのに必要なソフトウェアと、手紙を創成するのに必要なソフトウェアの間
に見られる、唯一の真の相違は、そのアイテム（品目）を創成するのに必要とさ
れる特定のボスモジュールと関連する、条件記録およびその他の非コード記録で
ある。このため、Ｅ−ｍａｉｌを創成するために一旦モジュールが構築されたな
らば、それらにたいして、別のタイプのデータ品目、例えば、ファックスを創成
させるのに、そのモジュールのコードに何の変更を加える必要もない。必要な唯
一の変更は、多くのフィールドにおいて、コード（フィールドロジック）を含む
実行記録に含まれる、ロジックそのものにたいしては外部的な条件、プロンプト
、および、その他の記録にたいしてである。上記から、コード基盤の大きさにお
いて大きな減少がもたらされ、誤りの危険率が低下し、かつ、構築スピードが向
上するという点で独特の効果がもたらされる。

【００２６】 このデータ分類構造はさらに、数字概念言語を含み、かつ、同言語の定義を助
ける。この言語は、もしもその言語を用いなければ、その特定の意味はあいまい
になるか、あるいは、１個以上の成分意味または使用法を含むことになるかもし
れない、言語または他の用語の特定の意味にたいして、特定の成分を一意的に確
定する。さらに、この数字概念言語は、全てのソフトウェア成分および成分集合
体について、特定成分を一意的に確定する。また、このデータ分類構造は、自然
言語（要すれば、その他の言語）を、数値概念言語に翻訳し、データ関係表に入
力させる言語処理システムと協力することが可能である。これによって、任意数
対任意数装置には、ユーザーとコミュニケートし、自然言語指令を理解し、実行
するのに自然言語を使用する能力が付与されたことになる。言いかえれば、この
任意数対任意数装置は、ヒト様自然言語議論において交信することが可能なよう
に構成される。全ての言語が、成分に基づいて処理されるわけであるから、この
任意数対任意数コンピュータシステムはさらに機械語でコミュニケートすること
も可能であり、ヒトの言語間、機械語間、および、ヒトの言語と機械語の間で正
確に翻訳することも可能である。

【００２７】 任意数対任意数コンピュータ装置の「データ関連表」構造は、表記録間に、お
よび／または、フィールド数値間またはフィールド数値の組合せ間に、関係を創
成するフィールド平行法によって実現される。このデータ関連表では、多数の記
録の中の同じフィールドが、データ分類構造の同じデータクラスに一致すること
があり得る。これによって、ソフトウェア数値概念言語特定子を特定フィールド
に入力し、それによって、対応するデータ記録の上の同じフィールドに位置する
データ入力のソフトウェアコードを特定することが可能となる。例えば、各デー
タ成分は、通常、そのデータ記録を入力し、および／または、出力するために、
１個以上の第２ソフトウェア成分に関連するばかりでなく、そのデータ成分を操
作するために、１個以上の第１ソフトウェア成分にも関連する。さらに、ソフト
ウェアモジュールを定義するのに、多数のソフトウェア型記録を用いてもよい。
この構造によって、この任意数対任意数装置を、ハードウェアおよびソフトウェ
アとどのように組み合わせて導入することも、もともとその任意数対任意数コン
ピュータ装置用に設計されていなかったハードウェアやソフトウェアを制御・作
動するように構成させることも可能となる。

【００２８】 従来技術では、多くの処理は時間継起的であるが、それと違って、フィールド
平行原理では、一つの記録、または、複数の記録のフィールド中のデータを個別
に、しかもどのような順序でも、さらに、個別的にでも、あるいは、全てのフィ
ールドを同時に処理する集団的平行的のいずれでも、処理することが可能である
。データ関係表のフィールド平行構築を、データ関係表フィールド当りのデータ
バス、メモリーチップ、ディスクシステム内において、および、個々のプロセッ
サーやプロセッサーパイプにおいて、ハードウェアをフィールド平行的に構築す
ることによって、さらに反映させるならば、処理において、相当のスピード増加
が、通常の複雑化や、付加的な出費を伴うことなく実現が可能である。例えば、
それぞれが１００ ＭＨｚで作動する１２０個のプロセッサーが同時に平行に１
２０個のフィールドを処理するならば、理論的には、１２０ ＧＨｚのプロセッ
サー、データバスまたはチップメモリーを要することなく、１２０ ｘ １００
０ ＭＨｚ、すなわち、１２０ ＧＨｚのスピードを実現することが可能となる
。この全体システムは、従来の、時間継起的処理法の理論的物理限界を越える。
最後に、このフィールド平行原理を、モデムやビデオコントローラー・カードの
ような周辺システムにまでさらに推し進めるならば、これらシステムは、この上
ない精度で制御されるばかりでなく、さらに速やかに動作することが可能となる
。この原理を、各データ関連表に特定のチャンネルが割り当てられる、装置間の
伝送線に拡張するならば、この平行伝送線を同様に利用することが可能となろう
。

【００２９】 任意数対任意数装置のソフトウェアに関する、もう一つの好ましい動作原理は
、ある命令を実行するよう装置に命じたヒトは、元の命令の中に含まれる用語を
使用する場合を除いては、その命令や、その実行の順序を参照することができな
いということがある。その用語とはすなわち、階層概念を通じて、元の命令中の
いくつかの用語、または、その命令の実行時間のような、命令実行を取り巻く状
況を参照するものである。データ関係表は、命令と、命令実行を取り巻く状況が
、１個以上の記録に記録されることを可能とする。

【００３０】 前の命令を参照する、または、ある命令の実行結果を参照する際のヒトのやり
方が、ある特定の動作原理の形で、任意数対任意数装置の中に導入されている。
その原理の一つとして、全てのヒトの命令が個別に、できるだけ詳細に常に記録
されるということがある。もう一つの原理として、以前に与えられた命令や、そ
れらの命令の実行結果を含む、データ関連表記録が、好ましくは絶対に上書きさ
れないようにして、コピーだけが可能であって、かつ、コピーされた後変更が可
能な形で保存されるということがある。もちろん、以前の記録に上書きしたり、
消去したりすることは、その項目を、それが以前に存在していた状態では、さら
にその後の活動を特定するのに必要とされる状態では回収不能とすることとなる
。例えば、「先週ＡＢＣプリンターでプリントした手紙を送った相手に、Ｅ−ｍ
ａｉｌを送れ」という命令を与えたとすると、問題の手紙が、ユーザーの特定し
たプリンターで印刷されたことが以前に記録されていないならば、この命令は実
行される筈がない。

【００３１】 さらにもう一つの動作原理として、上書き・消去禁止記録の実行の結果、過剰
の記録が出来したならば、それら過剰記録を先ず圧縮文書化し、その後、「無制
限原理」と名づけられる原理による「詳細崩壊アルゴリスム」を用いて取り除く
。この無制限原理は、「ソフトウェアは、ヒトが自らに制限を加えないやり方に
おいては、いかなる点でもヒトを制限してはならない」と明言することができる
。例えば、ヒトは、前日、昼に何を食べたかを記憶しているかも知れないが、通
常、１４，１６７日前の昼に何を食べたかを思い出すことはないし、また、そん
なデータを回収することに興味を覚えることは全く無いであろう。過去の出来事
は、重要性の程度において様々であるのだから、「重要性」実行フィールドと、
「重要性」記録タイプを導入することによって、データのタイプに等級をつける
ことが可能になる。この等級を用いて、崩壊アルゴリスムにより、最終的にもは
や興味の無くなった記録を取り除くことが可能となる。さらにもう一つの原理と
して、記録は通常消去または上書きされないという前述の原理があるから、デー
タ関係表は、最新時点から過去に向かって時間順序で配列された、時間追跡記録
、または、過去の事象の連続記録を形成することになる。

【００３２】 従って、従来技術の慣行と対照的に、このデータ関連表にたいして実行される
探索は、一般に、全体表の探索を必要としない。探索には、現在時間から始まっ
て、必要なマッチを探し出すために後方に進むことが要求されるが、全体表の探
索要求に比べれば比較的少ない数の探索数で済む。理論的には全体表の探索が必
要とされる場合でも、例えば、「ジョーからの全てのＥ−ｍａｉｌ」を探せとい
う場合であっても、実行フィールドと、それらのフィールド―ジョーのユーザー
番号記録タイプ、記録サブタイプ、および、記録のサブサブタイプ等を使用する
ことによって、探索を、ジョーのユーザー番号を持つＥ−ｍａｉｌの記録タイプ
のみに限定することが可能である。従って、探索は必要ではなく、適当なフィー
ルドに適当な数字概念言語を含む全ての記録の回収が必要とされるだけである。

【００３３】 任意数対任意数装置では、各データ関係表は、人生、時間、空間、エネルギー
および物質に関して１個以上のフィールドを含むことができる。これらの五つの
カテゴリーにおいて異なる数値を使用することによって、様々な方法を用いて、
どのようなデータでも記録することが可能となることが判明している。一つのフ
ィールドは、一つの概念または複数の概念の組合せにたいして一つの数値を含む
か、または、もう一つ別の記録を指定することが可能である。従って、各特定フ
ィールドの数値を、さらに別の記録で指定することが可能であり、また、その別
の記録の各フィールドの数値を、同様に、さらに別の記録で特定することが可能
である。どのような概念でも、フィールドとして、または、そのタイプの記録に
よって、または、その両方によって特定することが可能であり、そして、一方が
他方を指定することも可能である。これら二つの機構を組合せることによって、
独特の効果をもたらすことが可能である。すなわち、この効果は、（１）ある特
定の時間を、ある事象の起きた時点、起きるであろう時点として特定する場合の
ように、別のものの観点で特定することを可能にすることによって、（２）デー
タ関連表を自動的に別物に変換することによって、また、（３）データ関連保存
機構を無限の大きさを取り得るようにすることによって、もたらされる。

【００３４】 任意数対任意数装置のさらに別の好ましい原理として、共同縮小概念がある。
これは、通常のコンピュータ装置において探索の速度と正確度を劇的に改善する
。この原理は、任意数対任意数装置機能における基本要素であり、保存媒体や、
その使用に基づく「探索」モジュールの構築に適用される。共同縮小概念は、「
ヒトが何かを特定するのに、それぞれの概念が、他の全ての概念を排除する、そ
のような概念を付加し続けて、最終的に特定された概念が一意的となり、他の全
ての概念を明瞭に排除するに至る」場合に記述されると見ることもできる。これ
らの概念が供給される順序は、最終的に特定された概念にとっては非本質的であ
る。もっともこの順序は、その後に供給されるかも知れない、さらに別の概念に
とっては非本質的ではない場合があるかも知れないが。ヒト同士の相互作用にお
いて、他者に与えられた特定が、一意的と考えられたものの実際にはそうでない
場合、聞き手は、話し手にたいして、最終的な特定が一意的になるまでさらに概
念を供給するように促し続ける。例えば、社長が秘書にこう言ったとしよう、「
ニューヨークを呼んでくれ給え」。秘書はこう返答するであろう、「ニューヨー
クのどなたですか？ニューヨークには数百万人もいるんですのよ」。社長は「お
顧客さん」とさらに明らかにし、秘書は「どちらの？お顧客さんは約１０００人
もいますのよ」と答えるかも知れない。社長は、「さらに別の」概念を付加する
かもしれない、「わしのじゃ（わたしの顧客）」。秘書は、さらに、「その全部
ですか？」と次の返答を促し、さらに別の概念を受け取るかも知れない。「いや
、わしの友人だけだ」。この、他者との共同縮小概念の相互作用は、「共同縮小
概念プロンプト」と名づけられ、共同縮小原理特定化と、それによってもたらさ
れた結果とのミスマッチによってトリガーされる。重要なことは、この機構は、
複数の任意数対任意数装置間ばかりでなく、任意数対任意数装置とそのユーザー
との間に導入することが可能であるということであり、それによって、建設的な
相互作用の実現が可能となる。

【００３５】 上記概念ならびに原理は、汎用データベース構造を通じて実現してもよい。こ
の構造は、意味上のネットワークと、そこにおいては、個々の概念は、１個の数
字、または、複数の数字で一意的に特定される、要すればあってもよい概念上の
階層を導入する。言いかえれば、各概念には、数字概念言語における数字が割り
当てられる。データベースにおけるデータ項目を表わす各概念または概念集合体
は、そのデータ項目を参照する、または、同項目と関連する、あるいは、そのデ
ータ項目が参照する他の全てのデータ項目と意味上のネットワーク連結を持って
いてもよい。その場合、その連結は、ある概念によって特定される関係のタイプ
を表わす。実際の単語やフレーズを特定の言語で記録するのに使用されるフィー
ルドを除き、任意数対任意数装置全体に渡って、数字概念言語を使用してもよい
。一方で、単語自体を、それらを数字概念言語に翻訳することなく使用すること
によって、さらに単純で、さらに制限的ではあるが、極めて有用な任意数対任意
数装置が構築されており、成功を収めている。簡単なアプリケーションの場合、
完全な数字概念言語の導入は過剰装備となる可能性がある。

【００３６】 一般的に述べるならば、本発明は、どのようなタイプのコンピュータ保存媒体
にも保存が可能であり、ソフトウェア、ハードウェア、または、ソフトウェアと
ハードウェアの組合せの中で発現の可能なコンピュータシステムを含む。すなわ
ち、本発明は、ソフトウェアとして保存が可能な、または、コンピューターハー
ドウェアを通じて導入が可能な、または、ソフトウェア・ハードウェア保存媒体
の組合せにおいて保存が可能な、指令によって定義される、コンピュータ実行可
能な方法を含む。ソフトウェアおよび／またはハードウェア内部で発現される、
このコンピュータ実行可能な指令は、元の意味を有するデータを、そのデータを
、それ以上の分解は実質的に元の意味を全て失わせることになるまで、データ成
分に分解することによって保存するコンピュータシステムを定義する。次に、こ
のコンピュータシステムは、各データ成分を独立に保存する。同様に、ある要求
される機能を有するソフトウェアは、そのソフトウェアを、それ以上の分解は、
実質的に要求される機能の全てを失わせることになるまで分解して、ソフトウェ
ア成分の一つの数として創成することによって保存する。次に、コンピュータシ
ステムは、各ソフトウェア成分を独立に保存する。

【００３７】 このコンピュータシステムは、通常、データ成分をデータ成分タイプに分類し
、関連するデータ成分タイプにたいして操作を実行するように構成される、１個
以上のソフトウェア成分、または、ソフトウェア成分集合体を創成する。同様に
、このコンピュータシステムは、データ成分の集合体を、成分集合体タイプに分
類し、関連データ成分集合タイプにたいして操作を実行するように構成される、
１個以上のソフトウェア成分を創成してもよい。

【００３８】 任意数対任意数構成においてデータ成分とソフトウェア成分の保存をやり易く
するために、このコンピュータシステムは、データ項目を分類するための、一組
の、意味上のデータクラスを含む、データ分類インターフェイスを定義する。こ
のコンピュータシステムはさらに、データ項目に一致する数字インディケーター
を含むように構成されるフィールドを含む、一組の記録を定義する。これら数字
インディケーターは、数字概念言語辞書に定義されるが、それによれば、各数字
インディケーターは、基礎のデータ項目に一意的に関連する。この方法により、
コンピュータシステムは、意味上のデータクラスを、記録のフィールドと相関さ
せることが可能になり、さらに、ある記録のある特定フィールドに所在するある
特定の数値インディケーターを、関連するデータクラスと関連づけることが可能
となる。次に、このコンピュータシステムは、データ成分を、データ構造におい
て発現される記録として保存し、さらにソフトウェア成分も、同データ構造にお
いて発現される記録として保存される。特に、ある特定フィールドにおいて数値
特定子を含む、１個以上のデータ成分と、同じフィールド内の数値特定子を含む
、１個以上のソフトウェア成分は、そのデータ成分に作用するよう構成されるソ
フトウェア成分を特定する。

【００３９】 このコンピュータシステムはさらに、自然言語ブロックを受容するように構成
され、そのブロックを、データ関連構造中に発現される、１個以上の記録に変換
してもよい。次に、このコンピュータシステムは、数値特定子を含む、これらの
記録の、１個以上のフィールドを特定し、それらのフィールドに数値特定子を有
するデータ成分にたいして作用するよう構成される、１個以上のソフトウェア成
分を特定し、そのデータ成分に作用するよう、これらのソフトウェア成分を呼び
出してもよい。

【００４０】 このコンピュータシステムは、命令実行システムを含むように構成されていて
もよく、データ入力を受容し、かつ、そのデータ入力に応じて操作を実行する。
この命令実行システムは、データ分類インターフェイスを含む、データ関連構造
を定義し、同インターフェイスは、データとソフトウェア項目を分類するための
、一組の意味的データクラスを定義する。この一組のデータクラスが「意味的」
と言われる理由は、各データクラスが、そのクラスに割り当てられたデータ項目
にたいして、特定の意味を付与するからである。例えば、データクラス「名前」
に割り当てられた「ボブ」という用語は、「ボブ」という用語が名前であること
を示すが、一方、データクラス「活動」に割り当てられた「ボブ」は「浮き沈み
する」の動詞形であることを示す。このようにしてデータクラス構造は、それ自
体ではいくつかの異なる意味を有する可能性のある用語について、その明確な意
味を特定するのに役立つ。

【００４１】 命令実行システムはさらに、データ項目と一致する数値インディケーターを含
むように構成されるフィールドを定義する、１組の記録を含む。これらの数値イ
ンディケーターは、通常、数字概念言語辞書において定義され、それによれば、
各数値インディケーターは、１個のデータ項目と一意的に関連する。このデータ
関連構造は、データ分類インターフェイスの意味的データクラスを、記録の様々
のフィールドと関連づける。この構造は、ある記録フィールドにおけるある特定
の数値インディケーターの関連を受容し、そのデータ項目にたいして明瞭な意味
を特定するデータ成分を指示する。

【００４２】 この命令実行システムは通常、コマンド、請求、あるいは、ユーザーや他のコ
ンピュータシステムから受け取った、他のデータ入力のような、沢山のデータブ
ロックを含む。各データブロックは、元の意味を有するがさらに、それ以上の分
解が、実質的に全ての元の意味を失わせることになるまで分解されてデータ成分
となる。次に、各データ成分は、データ関連構造に発現される記録として、独立
に保存される。同様に、ある要求される機能を有するソフトウェアは、そのソフ
トウェアを、それ以上の分解は、実質的に要求される機能の全てを失わせること
になるまで分解された、ソフトウェア成分の一つの数から構築されてもよい。各
ソフトウェア成分は、データ関連構造に発現される記録として、独立に保存され
る。

【００４３】 データ関連構造は、データ関連表として、または、意味的ネットワークとして
機能的に構成されていてもよい。データ分類インターフェイスのデータクラスは
通常、管理、人生、時間、空間、活動、および、物質を含むカテゴリーグループ
から選ばれた、一組の意味的データカテゴリーに分類される。さらに、データ関
連構造に発現される記録は通常、データ記録、条件記録、コード記録、プロンプ
ト記録、ラベル記録、ヘルプ記録、および、その他のタイプの記録を含む、一群
の記録タイプから選ばれる。データ関連構造のある部分においては、データ関連
構造において発現される、一群の連接コード記録が、多段階操作を実行するため
のソフトウェアモジュールを定義する。また別の部分では、ある特定フィールド
の数値特定子を含むデータ記録と、同じフィールドにおいて数値特定子を含む、
１個以上のコード記録が、そのデータ記録に作用するように構成されるソフトウ
ェアを特定してもよい。

【００４４】 このコンピュータシステムはさらに、通常、インタフェイス制御システムから
自然言語ブロックを受け取る言語処理システムの他に、自然言語ブロックを受容
するよう動作するインタフェイス制御システムを含んでいてもよい。次に、この
言語処理システムは、自然言語ブロックを、データ関連構造に発現され、かつ、
その自然言語ブロックに一意的な意味を付与する、１個以上の記録に変換する。
次に、これらの記録は、命令実行システムに手渡される。

【００４５】 この場合、命令実行システムは、言語処理システムから対応記録を受け取り、
その対応記録が、明瞭なコマンドを定義しているかどうかを判断するように構成
されていてもよい。次に、この命令実行システムは、対応記録が、明瞭なコマン
ドを定義している場合には、同コマンドを実行してもよい。別態様として、命令
実行システムは、対応記録が明瞭なコマンドを定義していない場合、インターフ
ェイス制御システムにたいして、ユーザーに、さらなる情報を促すよう仕向ける
ようにしてもよい。

【００４６】 本発明が、従来のコンピュータシステムの欠点を克服する改良を提供し、前述
の効果を達成したことは、本発明の実施態様に関する下記の詳細な説明と、付属
の図面や請求項から明らかとなろう。

【００４７】

【発明の実施の形態】

この発明は、人間形式の情報処理をシミュレーションするために有効に利用さ
れることが可能な任意成分対任意成分対応計算機において、実施形態化される。
図面に戻って、同様な要素は、いくつかの図面にわたって、同様な要素を参照し
ている。図１は、ユーザ１２によってアクセス可能な任意成分対任意成分対応計
算機１０の機能ブロック図である。任意成分対任意成分対応計算機において、ユ
ーザは、人間、またはユーザとして動作する同一または別の任意成分対任意成分
対応計算機である。任意成分対任意成分対応計算機１０は、インタフェース制御
システム１４とオーダー実行システム１６とを含んでいる。この一実施形態では
、任意成分対任意成分対応計算機１０は、自然言語テキストを解釈することが可
能な言語処理システムを含んでいない。その代わりとして、インタフェース制御
システム１４が、構造化されたデータ入力を受け取るように設定されている。構
造化されたデータ入力は、それらの構造化された性質によって、あいまいのない
ものである。たとえば、構造化された入力は、ボタン、選択リスト、チェックボ
ックス、テキストボックス、およびそれらに似たアイテムを典型的には含んでい
る。そして、構造化された入力は、任意のタイプの構造化されたデータを含むこ
とが可能である。インタフェース制御システム１４の一例が、現出願人の継続中
である米国特許明細書No. 「グラフィカル・ユーザ・インタフェース」（２００
０年１１月１３出願）に記述されている。この特許明細書は、参照文献として、
本明細書に取り込まれる。

【００４８】 オーダー実行システム１６は、上述の構造化された入力を受け取り、完全な指
示が伝達されたかどうか決定する。完全な指示が伝達されていない場合は、オー
ダー実行システム１６は、追加情報のためのプロンプトをインタフェース制御シ
ステム１４に戻す。インタフェース制御システム１４は、ユーザにプロンプトを
提供する。このプロンプトは、ディスプレー上に視覚的にユーザに提供されるか
、テキストを音声に変換するような任意のほかの方法によって提供される。もし
くは、プロンプトは、インター機器コミュニケーションチャネルによってほかの
任意成分対任意成分対応計算機に提供される。この処理は、オーダー実行システ
ム１６が完全な指示を受け取るまで、繰り返される。そして、オーダー実行シス
テム１６は、完全な指示を実行する。このシステムの望ましい特徴は、オーダー
実行システム１６の構造と動作にある。オーダー実行システム１６は、１つまた
はそれ以上のデータ関係テーブルの形式で、any-to-any計算構造を実行する。こ
のタイプのテーブルは、図７および図８を参照して、下記に詳細に記述される。

【００４９】 図２は、任意成分対任意成分対応計算機１０の機能ブロック図である。任意成
分対任意成分対応計算機１０は、上述したインタフェース制御システム１４とオ
ーダー実行システム１６に加えて、言語処理システム１８を含んでいる。言語処
理システム１８は、構造化されていない自然言語入力を使用して、システム１０
とコミュニケーションすることをユーザ１２に許可する。換言すれば、言語処理
システム１８は、通常の自然言語テキストを数的概念言語に変換する。数的概念
言語は、オーダー実行システム１６が理解して、適切な様式で応答することがで
きるものである。

【００５０】 図３は、オーダー実行システム１６に含まれているアイテムの機能ブロック図
である。これらのアイテムは、データ関係テーブル１７内の記録として表現され
ているソフトウェアコンポーネント２０を含んでいる。各ソフトウェアコンポー
ネントは、単一のデータコンポーネントまたはコンポーネントアセンブリ上で単
一の機能を実行する。換言すれば、通常ひとまとめにして「ソフトウェア」と呼
ばれているおのおの異なったタイプのものが、コード自体、外的条件、プロンプ
ト、ラベル、ヘルプ、およびフィールドネーム等の構成コンポーネントに分解さ
れる。コード自体は、データコンポーネントの単一タイプ上に単一動作をするこ
とが可能なエクステントに分解される。その後、各ソフトウェアコンポーネント
は、分離して格納される。また、各ソフトウェアコンポーネントは、ソフトウェ
アコンポーネント間でのコミュニケーション方法とともに、ほかのソフトウェア
コンポーネントから独立してアクセスされたり、使用されたりすることを各ソフ
トウェアコンポーネントに許可する。相関関係の第３のコンポーネントを必ずし
も含む必要なく、このように任意のデータまたはソフトウェアコンポーネントま
たはコンポーネントアセンブリは、任意のデータコンポーネントまたはコンポー
ネントアセンブリまたはソフトウェアコンポーネントまたはコンポーネントアセ
ンブリと相関されることが可能である。

【００５１】 任意成分対任意成分対応計算機において、ソフトウェアに適用されるコンポー
ネント原理は、コードの分離に起因している。そのコードは、データを出力する
ために必要なコードからのデータを操作または変更するために必要なものである
。この分離による第１の間接的な利点は、任意の１つのソフトウェアコンポーネ
ントまたはコンポーネントアセンブリがその結果を、多くの代替となる出力コン
ポーネントアセンブリと同様に、ほかの操作モジュールの任意の組み合わせに出
力することができることである。任意の組み合わせは、視覚的でない場合、また
はほかの出力の組み合わせの場合もある。第２の利点は、ある任意成分対任意成
分対応計算機において、スクリーンまたはプリンタのような周辺装置への任意の
出力は、データの出力時間の空間アセンブリであるとして完全に扱われることで
ある。たとえば、任意成分対任意成分対応計算機における「a letter」は、コン
ポーネントアセンブリとして記録されている。コンポーネントアセンブリは、ユ
ーザが「a letter」であると認識するようなデータの空間関係のスクリーン上の
特定の空間関係で単純に配置されている。このany-to-anyインタフェースの方法
論は、出力時間のような空間関係を完全に介して関係を作り出す能力に起因して
いる。たとえば、個々のコンポーネントである、「Mr.」、「John」、および「B
rown」が、それら自体の境界のないスクリーン上のフィールド（「アクティブエ
レメント」と呼ばれる）にそれぞれ表示される場合で、かつ、これらのフィール
ドが連続的に配置されていて、それらが「Mr. John Brown」として見える場合、
ユーザは、これが人の名前であると理解する。しかしながら、これらのデータコ
ンポーネントが、スクリーンの異なった部分に異なって表示される場合、たとえ
ば、「Brown」が、「is a good person」を提示しているフィールドの隣に表示
されている場合は、ユーザは「Brown is a good person」と理解する。しかしな
がら、ただ１つの記録である「Brown」にこれらを実行する必要がある。表示さ
れるデータ、および、ディスプレー内または出力でのデータの位置が、データ特
定記録と視覚特定記録によって、それぞれ制御されている。このany-to-any出力
方法のさらなる利点は、それ自体がソフトウェアストレージのコンポーネント原
理によって可能になることである。その利点は、たとえば、写真を手紙に入れる
ようにシステムが要求された場合、複雑なリンク方法は必要としないことである
。その代わりに、写真を含んでいる記録のフィールドが、その手紙のデータの残
り部分に対する特別な空間関係で単に表示される。視覚的な表示または任意のほ
かの出力が全く異なる方法でふるまうために、基礎となるデータ操作論理または
アイテムの表示を制御するコードにとって、変更は不要である。たとえば、一人
のユーザのインタフェースのふるまいの記録によれば、特定の表示モジュールが
、必要とされるプロンプトをユーザに同時に、初心者に適した方法である「スプ
ーンフィードインタフェース」で出力する。一方、別のふるまいの記録は、別の
記録と関連しており、より技量のあるユーザ向けである。このふるまいの記録に
よれば、同一な表示モジュールがすべての必要とされるプロンプトおよび既知の
値を同時に表示する。双方のいずれでも、新しい操作論理または出力論理は不要
である。唯一の必要とされる変更は、単一インタフェースのふるまいの記録であ
る。要するに、記録を単純に変更することによって、実行される必要があること
について、field-by-field基底に基づいて、表示モジュールが異なる指示をする
。

【００５２】 データ関係テーブル１７もデータコンポーネント２２を含んでいる。各データ
コンポーネントは、意味の全体を失うことなくさらに分解することが不可能であ
るあいまいさのない意味を有している。これら２つのタイプのコンポーネント２
０および２２は、ビルディングブロックを形成する。高度な複雑さを持つマッチ
ングおよびパラレルなデータ、およびソフトウェアアセンブリは、ビルディング
ブロックからアセンブルされる。

【００５３】 この厳密なコンポーネントレベルデータ、およびソフトウェアストレージのア
プローチの結果として、任意のデータまたはソフトウェアコンポーネントまたは
コンポーネントアセンブリが、任意のほかのデータまたはソフトウェアコンポー
ネントまたはコンポーネントアセンブリに、相関関係の第３のコンポーネントを
必ずしも含む必要なく、相関づけることが可能である。これは、任意成分対任意
成分対応計算機の基底にある基本概念である。コンポーネントレベルのデータお
よびソフトウェアストレージのアプローチに起因する別の特徴は、各データおよ
びソフトウェアコンポーネントのうちの単一な例、または、コンポーネントアセ
ンブリに独立的かつ直接的にアクセス、またはそれを参照することができること
である。アクセスおよび参照は、任意のほかものから独立して使用するための階
層的でない様式で実行される。たとえば、マルチプルなソフトウェアモジュール
を生成する場合に実行される。この特徴は、コンピューティングシステムでの冗
長さを避け、トラブルシューティング、メンテナンス、およびアップグレードを
簡単にする。データおよびソフトウェアストレージおよび操作のコンポーネント
原理も、任意のほかのデータコンポーネントまたはアセンブリに独立に、データ
コンポーネントまたはアセンブリにアクセスする、およびそれらを操作すること
を可能にする。さらに、このコンポーネント原理によれば、パラレルなデータ／
ソフトウェアの構造のソフトウェアコンポーネントおよびアセンブリによって、
データコンポーネントおよびアセンブリを操作することが可能になる。パラレル
なデータ／ソフトウェアの構造においては、特別なデータコンポーネントまたは
アセンブリが、特別なソフトウェアコンポーネントまたはアセンブリに関連して
いる。特別なソフトウェアコンポーネントまたはアセンブリは、それらに関連し
たデータコンポーネントまたはアセンブリを操作するように配置されている。さ
らに、ストレージのコンポーネント原理もまた、鍵となる原理である。この原理
によれば、任意成分対任意成分対応計算機が、それに課される物理的な制限以外
は、制限されないようにすることが可能になる。たとえば、各電話番号が分離さ
れて記録されている場合、ディスプレイインタフェースも任意成分対任意成分対
応計算機の原理に基づいて構成されている場合、および、ソフトウェアモジュー
ルが適切に構成されている場合は、ユーザが記録されている電話番号を持たなく
てもよい、または表示する必要がなくなる。また、ユーザのために記録されてい
る千もの電話番号を持つことが可能になる。そのおのおのは、残りのデータ関係
テーブルフィールとこれらのフィールドから指示されるほかの記録を使用して、
それが動作する時間および場所および条件を提示することができる。同様に、単
一なソフトウェアコンポーネントがデータ関係テーブルの記録に記録されている
場合、記録それ自体またはベース記録から指示されるほかの記録を使用すること
、コンポーネントについて無限のデータを特定すること、および、その動作を非
常に精密に制御する、または非動作状態にすることが可能である。この能力は、
かなり実際的な応用を有する。たとえば、機密性においては、任意成分対任意成
分対応計算機の方法によれば、任意のデータの機密性が無限の精度で制御され、
各文字のレベルまで落とされる。この制御は、データを見るべきほかのユーザ、
またはそのデータで何かをするほかのユーザを同時に特定する一方で、この制御
は、単に誰がそのデータを見ることができ、厳密に彼らがそのデータを使用して
何をすることができ、何をすることができないか、ということを越えてかなり拡
張される。

【００５４】 データ関係テーブル１７は、概念階層テーブル２４も含むことが可能である。
概念階層テーブル２４は、典型的にはデータ関係テーブルの記録のアセンブリと
して格納されている。概念階層テーブル２４は、データコンポーネントおよび／
またはアセンブリの間での既知の関係に関するリストを含んでいて、ユーザが無
制限に加えることができるテーブルである。たとえば、概念階層テーブル２４は
、「りんご」が「フルーツ」として知られるクラスのメンバーであることを示し
、「犬」が「動物」として知られるクラスのメンバーであることを示す等である
。概念階層機構も、任意成分対任意成分対応計算機におけるグルーピングの多く
の形式のために使用される。

【００５５】 たとえば、任意の１つの文書またはアイテムを無制限数のグループにグループ化
するために使用される。ほかの記録タイプによれば、任意の１以上のジュニア−
シニア関係についてユーザが望んでいる任意のものをユーザが表現することが可
能になる。多くのステートオブアート（state-of-the-art）データ記録システム
に対比して、階層機構の構築は、任意の階層でのアイテムのメンバーシップが、
コピーすることなく任意のほかの階層で同様なアイテムの取り込みを、除外しな
いようなものである。マルチプルな階層でのメンバーシップは、マルチプルコピ
ーを必要としない。さらに、任意の階層は、階層の全体を通ることなく、どんな
レベルにおいても直接的にアクセス可能である。相反する階層も許容される。す
なわち、Ａがアクセスされた場合は、Ｂはそのジュニアの１つとして理解される
。一方、Ｂがアクセスされた場合は、Ａはそのジュニアとして理解される。ふた
たび、コピーは含まれず、見られるアイテムは常にアップデートされる。

【００５６】 これらのメンバーシップを記録することによって、それらが自然言語を構築す
るときに発生する場合に、計算機１０がこれらの関係を確認することが許容され
る。たとえば、“John brought over his dog and the wretched animal bit me
”のような文章において、概念階層テーブル２４は、“dog”と“animal”のタ
ームが同じものを参照するかどうかを決定する際の、計算機１０を補佐する。概
念階層テーブルも、任意成分対任意成分対応計算機１０が「最も近い真に戻れ」
として知られる関数を実行することを可能にする。たとえば、計算機は、「ジョ
ーは、列車でニューヨークに行ったか。」という質問に、「いいえ、彼は飛行機
でシカゴに行きました。」と応答することができる。同様に、計算機は、「彼は
昨日行きましたか。」という連続した質問に、「いいえ、彼は明日行きます。」
と応答することができる。

【００５７】 データ関係テーブル１７も、データ分類インタフェース２６を含んでいる。デ
ータ分類インタフェース２６は、同じタームに対する異なった意味を差別化する
ため、また、複数の可能な意味を有する言語構築の各コンポーネントの意味を一
意的に関連づける数的概念言語を定義するために使用される。データ分類インタ
フェース２６は、データ関係テーブル１７に格納されるすべての記録のために、
ユニバーサルであるが可変なインタフェースとして提供される。したがって、イ
ンタフェースは、データタイプを操作するソフトウェアにデータを関連づける。
すなわち、特別なインタフェースは、すべてのデータ関係テーブルまたは特別な
タイプのデータを含んでいる記録で典型的に動作する。インタフェースは、特別
な応用を含む、または多くの応用にわたることができる。しかしながら、インタ
フェースは、特別な応用に特化してアセンブリされることが可能である。一方、
データ関係テーブル１７中の記録は、ソフトウェアモジュール、データベース、
スプレッドシート、およびデータアイテムの以前には既知でない任意のタイプを
作り出すために、高レベルのソフトウェアおよびデータ構造に関連づけられるこ
とが可能である。このように、データ分類インタフェース２６は、データ関係テ
ーブル１７内で実行されるすべてのソフトウェアモジュールおよびデータ構造の
ために、ユニバーサルインタフェースとして効果的に役立つ。データ分類インタ
フェースも、視覚的またはほかの出力インタフェースと、言語処理システム１８
とを含み、それらとコミュニケーションしている。言語処理システム１８は、自
然言語入力を、分類インタフェースによってデータ関係テーブル１７に入れるこ
とができる数的概念言語の記録に変換する。その結果、データ関係テーブル１７
内で実行されるソフトウェアモジュールおよびデータ構造は、機械言語および入
力のうち仮想的な任意のほかのタイプと同様に自然言語入力を受け取り、処理す
る能力を持つことができる。

【００５８】 データ関係テーブル１７も論理テーブル２８を含んでいる。論理テーブル２８
は、ソフトウェアコンポーネントを、あらかじめ定義されているコンポーネント
に対応付けられている数的概念言語識別子または数に関連づける。この構造によ
れば、ソフトウェアコード自体よりも数的概念言語識別子が、データ関係テーブ
ル１７に入れられることが許容される。同様なものは、言葉の特別な意味に当て
はまることは銘記されるべきである。すなわち、言葉の各特別な意味は、データ
関係テーブル１７内の１つ以上の数的概念言語識別子として格納されている。

【００５９】 データ関係テーブル１７も記録相関関係３０を含んでいる。記録相関関係３０
は、いくつかの特徴を介して実行される。第１は、マルチプルコンポーネントは
、データ関係テーブル１７内の同様な記録の異なるデータクラスに格納されるこ
とが可能である。この特徴は、これらのコンポーネントが、その記録内で結合さ
れた意味（ソフトウェアでないデータの場合）または結合された機能（ソフトウ
ェアタイプの記録である場合）を有することを示すためである。たとえば、“fa
xed”というタームは、４つの異なるコンポーネントからなると述べることが可
能である。あるコンポーネントは、言葉自体であり、あるコンポーネントは、“
an action”を意味し、別のコンポーネントは“to send by facsimile”を意味
し、第４のコンポーネントは“in past time”を意味する。同一の記録に格納さ
れている４つのすべてのコンポーネントは、“faxed”というタームの意味を暗
示している。しかしながら、“an action”である“faxed”の意味の部分は、動
作タイプを格納するためのデータ関係テーブルフィールド内の“to send by fac
simile”というタームの数的概念言語識別子に格納されることによって定義され
る。

【００６０】 「データクラス」の概念（概念は、データの特別なテープのために使用される
データ関係テーブルの与えられたあるフィールドに入れられる）によれば、与え
られデータクラス内のすべてのアイテムは、データクラス内のデータのタイプの
例であり、そのクラスのメンバーである。なぜなら、すべてのアイテムは、それ
らが任意のほかのデータに似ているよりも互いにより似ているからである。これ
は、類似原理である。この原理を適用すると、同一な言語が１つのデータクラス
以上に適用されるような場合は、言語が異なる意味を実際に有し、異なるデータ
クラスに実際に属している各意味を有することが理解される。英語では、すべて
の言葉の意味または構造が常にある。意味または構造によれば、言語が少なくと
も２つの異なるライフデータクラス、および時間、空間、エネルギーまたは作用
、および物質の、残りのデータカテゴリーのうち少なくともに１つ以上、しばし
ばそれ以上のものに適用される。

【００６１】 記録相関のさらなるタイプは、「フィールドパラレリズム」として知られてい
る。このタイプでは、マルチプルコンポーネントが異なる記録の同一なフィール
ドに格納されている。たとえば、データ記録が、特別なフィールドに特別なコン
ポーネントエントリを有している場合、ソフトウェア記録は、それに同一なフィ
ールドにエントリを持つことができる。特別なソフトウェアアセンブリがデータ
アセンブリの特別なタイプに適用される事実、およびその逆の事実は、特別な様
式で使用されるアドミニストレーションフィールドと、特定のタイプの記録とを
含んでいるので、広く種類に富んだ機構によって示されることが可能である。フ
ィールドパラレリズムが使用されている場合は、関係するソフトウェアモジュー
ルは構成されて、その結果、与えられたあるフィールドのフィールド論理は、ハ
ンドルだけのほぼすべての場合において、データコンポーネントまたはコンポー
ネントアセンブリをその同一数的フィールドで扱うことができる。記録関連の別
の主なタイプは、データ分類インタフェース２６内で定義されるアドミニストレ
ーションフィールドを介して実行される。これらのアドミニストレーションフィ
ールドは、データを制御するために使用され、記録と記録タイプの間に特定の関
係を付け、また、記録され使用されるデータおよび／またはソフトウェアユーザ
の間に特定の関係を付ける。それに加えて、パラレリズムの任意のほかのタイプ
は、データ関係テーブル構造に構成される。データ関係テーブルの構造では、デ
ータおよびそれに関係したソフトウェアは、同一なフィールドまたはデータ関係
テーブル１７のコラム内でそれらの数的概念言語指標を介して互いにパラレルで
ある。フィールドパラレリズムは、プログラマが関係を追って、それに従うこと
のできる順序づけられたフレームワークを提供する。その関係は、潜在的に非常
に複雑になる可能性があるものである。しかしながら、フィールドパラレリズム
は、任意成分対任意成分対応計算機の構成に使用されている一方、データベース
は、空のフィールドを格納する必要がなく、それによってサーチスペースを改善
し、格納スペースを減らす。

【００６２】 図４は、言語処理システム１８に含まれるアイテムの機能ブロック図である。
これらのアイテムは、グラマストリッピングモジュール３２、グラマフォーマッ
ティングモジュール３４、言語規則ベース３６、数的概念言語（ＮＣＬ）辞書３
８を含んでいる。これらの要素は、一緒に動作し、自然言語通信を処理して、デ
ータ関係テーブル１７に入れるためのＮＣＬの記録に入れる、およびその逆の動
作をする。特に、グラマストリッピングモジュール３２は、グラマの特徴の適用
を取り除いて、効率的に自然言語コミュニケーションをデコンプレスする。たと
えば、“faxed”というタームは、“action, fax in past time”にデコンプレ
スされうる。“Joe’s”というタームは、“belonging to first name, Joe”に
デコンプレスされうる等である。グラマストリッピングモジュール３２は、また
「オペレータ」という言葉の効果もデコンプレスする。ここで、「オペレータ」
という言葉は、それら自身、または、ほかの言葉または言葉のグループとともに
、意味を有しさらに動作を実行すると定義される。これらは、代名詞、および、
ほかの指示するまたはリンクする言葉、サフィックス、およびプレフィックスと
同様に、“and”、“on”、および“of”のような言葉を含む。その後、結果と
してデコンプレスされた言語は、言語規則ベース３５によって処理される。一方
、グラマフォーマッティングモジュール３４は、ＮＣＬの記録上でコンプレッシ
ョンを実行するため、およびそれらを文法的に正しく、読むことが可能な言語に
戻すために、異なる規則ベースを使用する。すべての言語は、コンポーネントに
デコンプレッションされ、数的概念言語として格納されることが可能であり、さ
らに、１つのコンポーネントは、常にほかの言語で対応するコンポーネントまた
はコンポーネントアセンブリを有している。それゆえに、１つの言語で一度にデ
ータを入力することが可能であり、すべてのほかの言語でデータを読むことが可
能になる。その言語では、数的概念言語の翻訳が、データ関係テーブル１７内に
存在している。

【００６３】 言語規則ベース３６は、より高次レベルのコンプレッションを確認し取り除き
、特別なタームの候補となる意味が、特別な自然言語構造で示しているものを確
認するために使用される一組の規則を含んでいる。たとえば、“fax”というタ
ームは、“act of sending by fax”、“fax machine”、“document sent by f
ax”、または“document received by fax”を意味する。それぞれの候補の意味
にとって、規則ベース３６は、言語構造内で、ほかの要素を確認する。この言語
構造は、特別な意味を正しいと判定するために提示される。このような規則は、
要求規則と呼ばれている。規則ベース３６は、この規則を１ブロックの自然言語
内の各タームに対して実行し、その後、すべての意味に対する要求を同時に満足
する一組の意味を確認する。意味を決定するこの方法は、言葉で伝達される所定
のある考えが完全かつ自立していて、それゆえに処理されることが可能である場
合を見つけるという利点がある。典型的には、規則ベース３６が、進んで決定さ
れ出会った記録で典型的に表現されて、興味をもっている言語での発生する頻度
に基づく優先度で、意味を順序付けすることによって、最適化されうる。計算機
は、それが同時にすべての意味の要求を満たす１セットの意味を見出すまで、優
先度を下げる場合に意味を置換し組み合わせを実行する。いったん、よりレベル
の高いデコンプレッション規則によって以前にデコンプレスされた言語ブロック
でのタームに、あいまいさのない意味が選択されると、ＮＣＬ辞書３８はブロッ
クを、データ関係テーブル１７内のエントリのためのＮＣＬの記録に変換する。

【００６４】 図５はＮＣＬ辞書３８の構造を詳細に示す図である。「ジョーにバナナについ
てファックスしなさい（"Fax Joe about bananas"）」という言語構造４０内の
単一用語である「ファックス（ｆａｘ）」４２はＮＣＬ辞書３８の動作と構造を
示すのに使用される。同様の方法によりすべての用語はＮＣＬフォーマットに変
換されてデータリレーションテーブル１７に入力される。ＮＣＬ辞書は、各々が
データ分類であるデータ分類インターフェース２６を定義する多数の列を含む。
これは、データリレーションテーブル１７により使用されるものと同じデータ分
類インタフェースであるので、ＮＣＬ辞書３８のために作成されたＮＣＬレコー
ドは即データリレーションテーブル１７に入力することができ、データリレーシ
ョンテーブル内のデータレコードは同様にしてＮＣＬ辞書３８を用いてワードに
逆変換することができる。

【００６５】 データ分類インターフェース２６は５つのデータカテゴリ４４、すなわち生命
、時間、空間、行動および物質を含む。データリレーションテーブル１７はさら
に第６のデータカテゴリである管理を有し、レコード操作に使用される。そして
、種々の分野における異なる組合せ数を用いてより高次のデータアセンブルおよ
びソフトウエアアセンブルを定義するように動作することができる。各データ分
類は、順次何十というデータ分類に分割され、分割された各々は、種々の用語の
候補の意味を区別するのに使用することができる意味の種類を含む。

【００６６】 この発明の一実施形態において、英語言語のための８０程度のデータ分類のセ
ットが呈示され代表的なオフィス管理タスクに使用されるプロトタイプの実施形
態のシステム１０に良好な性能を提供した。適切なデータ分類のセットは、シス
テムの機能およびユーザのボキャブラリに応じてシステム毎に変更可能である。
例えば、科学研究のために使用される相互型(any-to-any)計算機と子供の娯楽シ
ステムに使用される計算機はかなり異なるデータ分類セットを有する。

【００６７】 各データ分類はＮＣＬ辞書３８の列を形成し、辞書内の各データコンポーネン
トは行を形成し、これは「レコード」と呼ばれる。数にもとづく識別の取り決め
を可能にするために、各データ分類には番号が割当てられる。例えば、分類は左
から右に１から８０の番号が付けられる。図５に示す例では、データ分類の非常
に小さなサブセットのみを示した。特に、「生命」のカテゴリに関するデータ分
類は示されていない。「時間」のカテゴリでは、３０の番号が付けられ、「終了
時刻」のタイトルがつけられた１つのデータ分類が示されている。また、「空間
」のカテゴリでは、３１の番号がつけられ「方向」のタイトルがつけられた１つ
のデータ分類が示されている。「行動」のカテゴリには、３２の番号が付けられ
「行動の種類」のタイトルがつけられた１つのデータ分類が示されている。さら
に、「物質」のカテゴリでは、３３と４３の番号がつけられ「マシンの種類」の
タイトルがつけられた２つのデータ分類が示されている。２以上の異なるデータ
リレーションテーブルからのデータレコードは実効的に互換性がある。これは、
データ分類がデータリレーションテーブルの固有の種類のフィールドによって、
あるいは、データリレーションテーブルの固有の種類のレコードによって、ある
いはその両方によって表すことができるためである。それゆえ、当業者には、第
１のデータリレーションテーブルのある種類のレコードが第２のデータリレーシ
ョンテーブルの異なる対応する種類のレコードに便宜的に変換可能であることが
わかる。本や新聞のような単一のデータをＮＣＬに変換するときは、結果として
生ずるＮＣＬテキストをデータリレーションテーブルレコードのフォーマットで
はなく、連続したＮＣＬストリングの形態に変換して記憶するほうがより効率的
である。連続したＮＣＬストリングにおいては、各ＮＣＬコンポーネントは、デ
ータ分類の番号を示す第２の番号を有し、さらにＮＣＬストリングには必要とさ
れる管理フィールドが同様に記録されている。この方法は、ここに記載したデー
タベースのような記憶媒体がデータリレーションレコードと連続ＮＣＬの両方を
同一フォーマットで記憶すれば、コンポーネントの関係がわかるので効率的であ
る。

【００６８】 「ジョーにバナナについてファックスしなさい」という文言構成から「ファッ
クス」という用語にＮＣＬの公式を適用する例を示すために、ＮＣＬ辞書３８に
示す特別のデータ分類が含まれている。ＮＣＬ辞書の各用語の基本的な意味には
唯一の番号が割り付けられている。この例では、用語「ファックス」には番号２
４が割り付けられ、用語「ｉｎ」には番号２５が割り付けられ、用語「past(tim
e)」には番号２６が割り付けられている。ワード「ファックス」に番号２４が割
り付けられた用語の基本的意味は、ワードのすべての異なる個々の意味に共通な
ワードの意味のコンポーネント部である。各用語には、唯一のＮＣＬ基本番号が
割り付けられているけれども、この番号は、与えられたワードのスペリングが明
白な意味を持つということを内包していない。なぜなら、同じ用語でも文言のコ
ンテクストが異なれば意味を異ならせることができるからである。それゆえ、各
異なる意味は、固有のアセンブリのＮＣＬコンポーネントにより定義され、別の
ＮＣＬレコードを用いて与えられたワードの各意味を表す。基本的な意味はその
ような各レコードにおいて共通のファクタである。

【００６９】 「ファックス」の例に戻ると、この用語は、４つの異なる意味を持つことがで
きる。これら４つの異なる意味は、「ファックス」の基本的意味として、（１）
受信したドキュメント、（２）ドキュメント原稿、（３）ファックス機械、およ
び（４）送信の行為を含んでいる。これらの意味は、各々ＮＣＬ辞書３８の異な
るレコードにより表される別個コンポーネントアセンブリにより定義される。特
に、「送信行為」を意味する「ファックス」のコンポーネントは、用語「ファッ
クス」のＮＣＬ基本番号２４を「行為の種類」のデータフィールド３２に入力す
ることにより定義される。この対形成は、この特別のコンポーネントアセンブリ
の「ファックス」という用語が「行為の種類」であることを示している。この対
形成はまた、この特別のコンポーネントのための「３２・２４」というＮＣＬ表
現として述べることができる。すなわち、第１の入力３２は、フィールド番号を
示し、それにより関心のあるデータ分類を呈示し、第２の入力２４はＮＣＬ基本
番号を示す。従って、これら２つのコンポーネントの意味「行為」と「ファック
ス」（種類）は２つのＮＣＬ番号３２および２４により表される。

【００７０】 「ファックス」の例を続けると、「ファックス機械」を意味する「ファックス
」のコンポーネントは、用語「ファックス」の同じＮＣＬ基本番号２４を「マシ
ンの種類」のデータフィールド３３に入力することにより定義される。これは、
このコンポーネントに対する用語「ファックス」が「マシンの種類」すなわちフ
ァックス機械であることを示している。この結果、この特別のコンポーネントに
対するＮＣＬ表現「３３・２４」が生成される。第１の入力３３がフィールド番
号を示し、第２の入力２４がＮＣＬ基本番号を示す。

【００７１】 同様に「ドキュメント原稿」を意味する「ファックス」のコンポーネントは用
語「ファックス」のためのＮＣＬ基本概念番号２４を「マシンの種類」のデータ
分類フィールド４３に入力することにより定義される。この配置は、この場合の
用語「ファックス」は「ドキュメントの種類」すなわちファックス原稿であるこ
とを示す。従って、ＮＣＬ表現「４３・２４」はこの特別のコンポーネントアセ
ンブリに対して生成される。

【００７２】 オリジナルのドキュメントを受信したドキュメントと区別するために、「受信
したドキュメント」を参照する「ファックス」のコンポーネントアセンブリを用
いると、１つのレコード内に２つのコンポーネントを使用するのが望ましい。す
なわち、用語「ｉｎ」のＮＣＬ基本番号２５は「行為の方向」のフィールド３１
に入力される必要があり、用語「ファックス」のためのＮＣＬ基本番号２４は、
「ドキュメントの種類」のフィールド４３に入力される必要がある。この結果得
られるＮＣＬ表現「３１・２５＆４３・２４」は、「受信したファックス」の特
別の意味を生ずる。受信したファックスの量はこの例のレコードによっては示さ
れない。受信したファックスドキュメントの数を提示するためには量フィールド
にさらなるＮＣＬ用語が必要となる。この数字はもちろん零を取り得る。

【００７３】 「受信したドキュメント」を意味する用語「ファックス」のためのＮＣＬ表現
の導出はコンポーネント間の関係を内包するために単一レコード内に複数のコン
ポーネントを使用することを示す。同一のアプローチを用いて他の複合用語をコ
ード化することができる。例えば、用語「faxed」は、「行為の時間」のフィー
ルド３０に用語「past」のＮＣＬ基本番号２６を入力し、「ドキュメントの種類
」のフィールド４３に用語「ファックス」のＮＣＬ基本番号２４を入力すること
により定義できる。この結果、用語「faxed」のＮＣＬ表現「３０・２５＆４３
・２４」を生ずる。同様の方法により、コンポーネントをＮＣＬレコード内で結
合して、フレーズ、センテンスあるいは他の言語ブロックのようなマルチワーク
構成を定義することができる。さらに、同じ原理により、番号、ソフトウエア、
音の一部、画像の一部等のような非言語のデータ構成をコンポーネントのフォー
マットで表し記憶することができる。

【００７４】 図６は相互型(any-to-any)計算機械１０に使用されるロジックテーブル２８を
示す図である。

【００７５】 ロジックテーブルは、特定の塊のソフトウエアコードをＮＣＬ番号と相関させ
て、そのコードの塊が便宜的にＮＣＬレコードで示されるように機能する。この
態様でコードを記録する唯一の利点は、もしコードに誤りがあった場合に、その
コードが使用可能な潜在的に数千のモジュールに必要な更新無しに、そのコード
自体の単一かつ単独の事例を変更することが望ましいということである。第２の
利点は、プログラマが機能を追加したい場合に、必要とされるほとんどの機能が
、プログラマがモジュール単位で指定することのできる既存のロジックの形態で
すでに存在しているということである。プログラマは所望のデータ変換を行うの
に必要な追加の特定のロジックを書きさえすればよい。従って、実質的に全体構
築時間を低減することができる。

【００７６】 ロジックテーブル２８は、レコード番号のための第１の列を含む。このレコー
ド番号はコードの塊に割り付けられたＮＣＬ番号として２倍にする。さらにロジ
ックテーブル２８はこのコードの名前のための第２の列を含む。この第２列は、
ＮＣＬリファレンスの形態で最適に記録される。それにより、プログラマは、他
の言語がインストールされている場合には、自分固有の言語でロジック名を見る
ことができる。さらに第３列を含み、この第３列は、コード自体かあるいはコー
ドを見つけることのできるメモリロケーションのポインタを含む。ロジックテー
ブルはさらにコンパイルされたコードを含むことができる。あるいは、データリ
レーションテーブルタイプレコードを用いてロジック（あるいはロジックが記憶
されているメモリロケーションのポインタ）を記憶することができる。この場合
、一方のフィールドは、ロジックまたはポインタを記憶することができ、一方、
そのレコードタイプの他方のフィールドを用いてオペランド、ロジックが動作す
る条件等のようなロジックに相関させることができる。いずれの場合にも、（自
己のフィールド内のデータエレメントに変換を行う１つのコードとして定義され
る）フィールドロジックのような単一コンポーネントをここに記載した専用のテ
ーブルあるいはもっぱらそのタイプのデータ（この場合フィールドロジックデー
タ）に充てられたデータリレーションテーブルレコードに記録することができる
。データリレーションテーブル以外のテーブルは単に一部を切り詰めたデータリ
レーションテーブルレコードを構成するテーブルである。この種の最適化は将来
問題を生じる恐れがある。なぜなら、ロジックを記述する、例えばそのロジック
が動作する条件を述べるのに必要な場合、残りのデータリレーションテーブルフ
ィールドが利用できないからである。それゆえ、データリレーションテーブルと
もう一方のテーブルは単にフォーマットが互いに異なる。第２のテーブルは、特
別の目的のために最適化されたデータリレーションテーブルのバージョンとして
考えられ取り扱われる。

【００７７】 第７図はデータリレーションテーブル１７においてデータ／ソフトウエアパラ
レル三つ組の使用を示す図である。相互型(any-to-any)計算機システム１０にお
いて、フィールドパラレルレコードを用いた操作のためにデータアイテムをコー
ドとリンクさせることが望ましい場合がしばしばある。データ／ソフトウエアパ
ラレル三つ組はそのような例である。この例において、三つ組を記載しているけ
れども、相関するフィールドパラレルレコードの数は限定されない。図示例は実
際にはｎタプレットであり、関係するレコードの数に特別の制限はない。データ
分類インターフェース２６の第１の名前に対してデータレコード１を入力するこ
とができ、そのデータレコードを操作するフィールド−パラレルコードレコード
１Ａを続けることができる。コードを含むレコードは、ワードが通常使用される
「コード」とその内容を区別するために「実行レコード」という名称がつけられ
る。この場合、コードプラスラベル、プロンプト等はすべ１つの塊としてアセン
ブルされ、集合的に「コード」という名称がつけられる。実行レコードの各フィ
ールドは変換を行うのに必要なコードのラインのみを含む。実行レコードは、通
常のコードに共通に含まれるラベル、プロンプト、エラーメッセージ、及び他の
指示を含まない。データレコード内のＮＣＬ番号５７と同じフィールド内のソフ
トウエアコードのためのＮＣＬ番号１２３の入力は、そのコードは、前のレコー
ドの対応するフィールド内のデータに演算を行うように意図されている。従って
次のレコードは、同じデータアイテムに操作するための入出力レコードのような
別のコードであり得る。再度、データレコード内のＮＣＬ番号５７と同じフィー
ルド内の第２のソフトウエアコードのためのＮＣＬ番号３４１の入力は、そのコ
ードが三つ組の他のレコードの対応するフィールド内のデータあるいはデータと
ともに演算を行うように意図されている。このプロセスは、どのような数の相関
するレコードに対しても継続することができる。例えば、第１のレコードがデー
タ出力のためのフォントを定義し、別のレコードが表示ロケーションを定義し、
別のレコードが色を定義し、別のレコードがそのフィールドの条件を定義し、別
のレコードがそのフィールドのラベルを定義し、別のレコードがそのフィールド
のヘルプ表示を定義する等である。１つのコードレコードは、そのコードレコー
ドを引き出す動作を行う特定のユーザに応じて、複数セットの相関するレコード
を使用することができる。例えば、ラベルと他の表示アイテムがＮＣＬフォーマ
ットではなくテキストとして直接記憶される場合には、異なるレコードを用いて
異なる会話言語の同様の表示アイテムを記憶することができる。特定の種類のユ
ーザデータレコードに演算を行うために一緒になって作用するレコードのグルー
プは「モジュール」と呼ばれる。

【００７８】 上述したフィールドパラレル技術は強力な結果をもたらす。これは、プログラ
マが極めて複雑な関係で順番を維持し、どのようなユーザインターフェースでも
表示のためにデータアイテムを抽出可能にさせる方法を提供するためである。フ
ィールドパラレル化もまた相互型(any-to-any)マシンの階層の性質の望ましい部
分である。なぜならこの技術は、データリレーションテーブル構造自体と一緒に
なって、異なったアイテムのグループが単一フィールドレベルの下の方へ非階層
的にアクセス可能とするからである。この設定においては、特定のデータアイテ
ムが、データリレーションテーブル１７においてそのデータアイテムタイプを操
作し、表示するためのソフトウエアレコードと自動的に相関される。従って、リ
モードコンピュータシステムのユーザは単にデータリレーションテーブル１７の
所望のデータレコードの適当なフィールドにリンクすることができ、対応するソ
フトウエアコードレコードを印加することにより、データを容易にその意図した
フォーマットで表示することができる。

【００７９】 図８は、複数ＯＳ対応型（ａｎｙ−ｔｏ−ａｎｙ）計算機機械１０で使用する
情報対照テーブル１７の構成を示す図である。情報対照テーブル１７は、ＮＣＬ
辞書３８を参照して述べた同じ情報分類インターフェースを使う。但し、情報対
照テーブルは付加的な管理情報カテゴリーを含む点が異なる。よって、情報対照
テーブル１７は言語処理システム１８との通信用のインターフェースを定義する
所定数の欄を有する。この言語処理システム１８は、インターフェース出力ロジ
ックと同様に情報対照テーブル内に格納されている。また、情報対照テーブル１
７はレコード５０ａ−ｎを実質的に無制限数格納している。各レコードは１個以
上の項目５６を含む。項目５６は、特定ＮＣＬベース数を特定の情報分類に対応
する特定領域内に含む。異なるタイプのレコードが多くある。情報レコード、条
件レコード、符号レコード、督促レコード、ラベルレコード、支援レコード等で
ある。これらのレコードは、領域並行技術を使って相関付けられている。連続レ
コードの同じ領域に置かれた項目５６ａ−ｃが示す通りである。一般的には、い
かなるタイプのソフトウエアモジュール５８用の情報と命令は、近接レコードの
セットに組み込む必要はない。

【００８０】 ここに記述の領域並行レコードに加えて、もう一つ別タイプの基本レコードが
ある。これはシリーズレコードと呼ばれるもので、レコードの領域が簡単なリス
トとして機能するものである。レコード機能の残る諸原理は応用可能である。シ
リーズレコードの用途の一つは、手紙や住所などの複雑な項目の一部を成すレコ
ードをリストアップすることである。他の用途は、特定の情報対照テーブル領域
から或るシリーズレコードを指定して、この指定を実施する領域の内容を形成す
る同一タイプの複数値のリストを作成することである。

【００８１】 図９は論理流れ図１００であり、複数ＯＳ対応型計算機械１０において、自然
言語コマンドへの応答処理を説明している。ステップ１０２では、起動モジュー
ルが、前記情報対照テーブル内に組み込んだインターフェース制御システム１４
に表示を開始させる。ステップ１０２にステップ１０４が続く。ステップ１０４
では、インターフェース制御システム１４は、特にテキストボックス内への使用
者参入を受けて、あるいは複数ＯＳ対応型計算機械１０が制御する生物測定式識
別装置からの入力を受けてシステムの使用者を識別する。ステップ１０４にステ
ップ１０が続く。ステップ１０６では、許可を受けた使用者のテーブルを参照し
て使用者の参入をチェックし、現在の使用者が新たな使用者であるか否か判断す
る。一致が見られず、現在の使用者が新たな使用者である旨が示された場合は、
「ＹＥＳ」となり、ステップ１０８へと進む。ステップ１０８では、インターフ
ェース制御システム１４が使用者の経験水準、好みの画面表示等、種々の情報を
要求する新使用者登録モジュールを起動する。

【００８２】 ステップ１０８と、ステップ１０６での「ＮＯ」に続いて、ステップ１１０が
実行される。ステップ１１０では、インターフェース制御システム１４が、使用
者個人に適した、また使用者がキーボードと画面とを介して又は電話やＥメール
を使って通信している人物であるか、或いは使用者が実際に他の複数ＯＳ対応型
計算機械であるかと言った環境とに適したタイプの使用者インターフェースを選
択、要求する目的で使用者を認識する。ステップ１１０にステップ１１２が続く
。ステップ１１２では、インターフェース制御システム１４が現在の使用者に適
したタイプの使用者インターフェースを選択、要求する。この使用者インターフ
ェースを表示すると、インターフェース制御システム１４は、ステップ１１６に
て自然言語ブロックを使用者から受け取る準備が整う。よって、ステップ１１２
にステップ１１４が続く。ステップ１１４では、インターフェース制御システム
１４は、自然言語ブロックを使用者から受け取る。

【００８３】 ステップ１１２にステップ１１４が続く。ステップ１１４では、言語ブロック
が使用者からのコマンドを解析し、コマンドを数量概念言語（ＮＣＬ）に変換す
る。この言語変換は言語処理システム１８の中核であり、図１０を参照して以下
説明する。ルーチン１１６にステップ１１８が続く。ステップ１１８では、変換
後のコマンドを表すＮＣＬレコードが命令実行システム１６へ送られる。ステッ
プ１１８において、コマンドはソフトウエアモジュールにマッチングされ、滞欧
のモジュールが起動される。ステップの次にステップ１２０が続く。ステップ１
２０では、命令実行システム１６はコマンドを分析し、使用者のコマンドが完全
で実行可能な命令文を定義しているか否かを判断する。使用者のコマンドが完全
で実行可能な命令文を定義してない場合は、「ＮＯ」となり、ステップ１２２へ
進む。ステップ１２２では、命令実行システム１６は、インターフェース制御シ
ステム１４に付加的情報を入力するよう使用者に督促させる。ステップ１２２に
ステップ１１４が続く。ステップ１１４では、インターフェース制御システム１
４が督促に応じた自然言語ブロックを再度受け取り、このブロックをルーチン１
１６において言語処理システム１８へ送る。（実際には、コマンドは自然言語入
力情報、あるいは画面上の特定領域への入力情報から受け取り可能である）使用
者のコマンドが再びチェックされ、使用者のコマンドが完全で実行可能な命令文
であるか否か判断する。このチェック処理は、使用者のコマンドが完全で実行可
能な命令文となるまで継続する。使用者のコマンドが完全で実行可能な命令文で
あると判断した時点で、ステップ１２０からステップ１２４へ進む。ステップ１
２４で、命令実行システム１６はコマンドを実行する。ステップ１２４にステッ
プ１２６が続く。ステップ１２６では、命令実行システム１６はインターフェー
ス制御システム１４に命令実行結果を表示させる。ステップ１２６に「継続」ス
テップが続く。この「継続」ステップでは、複数ＯＳ対応型計算機械１０が他の
コマンドを受けたり、果たし得る他の機能を実行できる。適切なモジュールを使
って、複数ＯＳ対応型計算機械は異なる使用者、異なるソースからのコマンドを
同時に処理可能である。

【００８４】 図１０を再度参照するに、この論理流れ図は図９に示すステップ１１６に対応
し、複数ＯＳ対応型計算機械１０に設けた言語処理システムを示すものである。
図１０は、図９に示すステップ１１４続くステップから始まる。すなわちステッ
プ２０２において、言語処理システム１８が自然言語命令をインターフェース制
御システム１４から受け取る。ステップ２０２にステップ２０４が続く。ステッ
プ２０４では、言語ブロックが圧縮される。これには、ある言語の構文と慣用表
現を解釈し除去する「文法解析」処理が含まれる。これら構文と慣用表現は全て
、ブロック内に埋め込まれた状態で続く圧縮処理で作用する。ステップ２９４に
ステップ２０６が続く。ステップ２０６では、言語処理システム１８がブロック
から第１言語用語を得る。ステップ２０６からステップ２０８へ進む。ステップ
２０８において、言語処理システム１８は、この用語に対する全ての候補レコー
ド（用語の意味に対応し得るレコード）を検索する。ステップ２０８にステップ
２１０が続く。ステップ２１０では、言語処理システム１８は言語ブロックをチ
ェックし、他の用語がブロックに残っているか否かを判断する。他の用語がブロ
ックに残っていれば、「ＹＥＳ」となり、ステップ２０６へ戻る。そこで言語処
理システム１８は次の用語を得て、その候補レコードを検索する。この処理はス
テップ２０６、２０８および２１０を通じて行われ、言語ブロック内に付加的言
語用語が残らないまで続行する。

【００８５】 ブロック内の用語全てに対する候補レコードが検索された時点で、「ＮＯ」と
判断され、ステップ２１０からステップ２１２へ進む。ステップ２１２では、言
語処理システム１８は言語規則ベース３６を適用して、ブロック内の各用語の正
しい意味に対応する候補レコードを選択する。特に、言語規則ベース３６はブロ
ック内の各用語に対する候補レコードを、対象言語に現れる頻度に基づく優先順
位に並べる。この頻度は前もって決めたもので、得たレコード内に記述されてい
る。本処理はブロック内の用語の意味を、逆優先順序で並び変え、組み合わせる
もので、ブロック内の全用語の意味要件を同時に満たす意味のある群（セット）
が見つかるまで続行される。意味の群が見つかった場合、ブロック内の用語は完
全な命令を構成する。見つからなかった場合は、命令は不完全であるので、使用
者に、情報を更に入力するように督促する。ステップ１１２にステップ２１４が
続く。ステップ２１４では、ブロックに対して選んだ全てのレコードが組み合わ
され、ブロック用のデータベースレコード単位を構成する。ステップ２１４から
ステップ２１６へ進む。ステップ２１６において、言語処理システム１８は、ブ
ロック用のデータベースレコード単位を命令実行システム１６へ送る。ステップ
２１６に「継続」ステップが続く。この「継続」ステップから図９に示すステッ
プ１１８へ戻る。

【００８６】 図１１は論理流れ図であり、言語処理システム１８を含まない複数ＯＳ対応型
計算機械１０内で、自然言語コマンドに対する応答処理を表すものである。この
種のシステムは、前述のように表示器駆動開始機能、使用者認識機能、特定使用
者用の表示画面またはインターフェース種類の表示機能を含む。言語処理システ
ム１８を用いる計算システム１０と異なり、図１に示す本システムはステップ２
５２において構成済みコマンドをインターフェース制御システム１４から受け取
る。この構成済みコマンドは、Ｅメールのようなモジュールの名前を付したイン
タフェース能動素子の形態を通常取り、当該モジュールを起動するものである。
モジュールは、その状態レコードを使って、受け取ったコマンドが完全かつ実行
可能な命令文を定義しているか否かを判断する。使用者のコマンドが完全かつ実
行可能な命令文を定義していない場合は、「ＮＯ」と判断されステップ２５８へ
進む。ステップ２５８では、インターフェース制御システム１４は使用者に付加
的な情報を入力するように督促する。ステップ２５８に続いて、ルーチン２５０
からステップ２５２へ戻る。ステップ２５２では、インターフェース制御システ
ム１４は構成済みコマンドを使用者からシステム１４から再度受け取り、このコ
マンドを送る。コマンドが完全かつ実行可能な命令文であると判断された時点で
、「ＹＥＳ」となり、ステップ２５６からステップ２６０へ進む。ステップ２６
０では、命令実行システム１６がこのコマンドを実行する。ステップ２６０に「
継続」ステップが続く。この「継続」ステップでは、複数ＯＳ対応型計算機械１
０は他のコマンドを受けたり、果たし得るいかなる機能を実行できる。

【００８７】 複数ＯＳ対応型計算機械の構成と動作とを詳しく説明した。しかし、特定用途
の特定実施例は大幅に異なる構成を持ってもよい。異なる構成と言っても、上述
の複数ＯＳ対応型計算機械の技術と方法に従うもので、上述の構成概念を計算に
応用できるタイプの機械である。例えば、文書の仕分けと検索、ファックス送信
等の典型的事務機能を果たすように構成された複数ＯＳ対応型計算機械で用いる
代表的なデータベース構成を以下、説明する。この特定用途のデータベースの好
ましい構成は、改良型意味論ネットワークである。このデータベースは必ずしも
改良型意味論ネットワークとして実施されなくともよい。しかし、かかるネット
ワークとして構成することは効果的である。その理由は、改良型意味論ネットワ
ークは情報提供が柔軟であり、フラットテーブルの無駄と膨張とをなくし、相互
情報量軽減型（ｃｏ−ｒｅｄｕｃｉｎｇ）概念探索メカニズムを効果的に支援し
、設置スペースと作動速度の点で経済的であるからである。図１２乃至図１８は
、本発明実施例のデータベース構成の代表的な部分のみを示す。数兆個ものレコ
ードを各データベース構成は格納するからである。

【００８８】 図１２は、データベースの様々な概念をいくつかを含むＮＣＬテーブル３０
０の一部を示す。このテーブルはテーブル＃１と名付けられ、データベースに既
知の情報対照テーブル概念３０２の全てを単にリストアップしたものである。上
述し、あとで詳述する情報対照テーブル概念（ＮＣＬテーブルレコード）は、単
に物理的なテーブル配置であると見るべきではなく、データベースに既知の、様
々なタイプの概念レベル関係の仕様と見るべきである。換言すれば、情報対照テ
ーブルの概念はデータベースシステム用のＮＣＬテーブルを具備する。そして、
このシステムにおいて、レコード種別を含む領域としてテーブルが使用する概念
をＮＣＬテーブルは定義する。複数ＯＳ対応型計算機械において、諸概念はデー
タベースの一部であると定義され、領域として使用される。事実、データベース
内のいかなる概念は特定領域タイプと考えられる。概念は全て、その論理例（レ
コード）を持つ論理タイプと考えられるので、かかる値で表される単位情報はい
ずれも、相互関連概念の多次元空間内の多次元座標位置と考えることができる。
概念の数は本来無限であり、例(レコード)の数も本来無限であるので、概念空間
は無限大である。よって、ひとつの単位情報の意味はこの概念マッピングにより
把握される。各概念は独立したレコードである。概念の各々は情報対照テーブル
レコードの構築に使用できるが、全ての概念が各レコードの構築に使用される必
要はない。各タイプのレコードにより通常使用されたり、レコードに通常内包さ
れた概念は、情報関連レコードタイプにより指定される。情報関連レコードタイ
プは、それ自体がＮＣＬテーブルにおける他の概念である。しかし、レコードタ
イプは、概念の特定群に限定されるものではない。各概念は番号が付され、他の
データベースの全てにおいて、その概念番号とそのレコード番号とにより特定さ
れる。概念番号は論理ラベル番号としても知られている。

【００８９】 ＮＣＬテーブル３００は、６つの領域と、ひとつのレコード番号/論理テー
ブル番号領域３０４と、ひとつの物理テーブル番号領域３０６と、ひとつのテー
ブル形式番号領域３０８と、ひとつのテーブル名領域３１０と、ひとつの前方参
照順序領域３１２と、ひとつの後方参照順序領域３１４とを有する。レコード番
号/論理テーブル番号領域３０４は番号概念言語内の特定概念の独自概念番号と
して機能する。物理テーブル番号領域３０６は、或る概念のデータが存在するテ
ーブルを指定する。テーブル形式番号領域３０８は、物理テーブル番号領域３０
６内で参照した物理領域の構造を参照するものである。テーブル形式番号領域３
０８は物理領域の一部として、あるいはＮＣＬテーブル内で最適領域として格納
される。テーブル名領域３１０は、提示された特定概念について、物理格納情報
タイプを前方参照するのに使う。この前方参照は、基本値のジャバ級名と非基本
値の「空参照」（オール・ゼロ）とを指定している文字列テーブル内にレコード
を格納するのに使用してよい。前方ポインタ順序３１２は、このレコードための
概念を定義するのに用いる概念を参照するためのものである。また、後方ポイン
タ順序３１４は、この概念を用いて定義される概念を参照するためのものである
。前方ポインタと後方ポインタは、共に意味論ネットワークにおいてリンクとし
て機能する。これらリンクには、リンクを網羅する関連タイプを指定する概念が
含まれる。このようなリンクとして働くので、前方指定と後方指定は意味論的値
を有する。本実施例では、両ポインタは、「６．１．２３」のような３部分構成
の番号である。第1の部分はＮＣＬテーブル３００内の概念番号である。第２の
部分はタイプ認識（ＩＤ）番号または論理テーブル番号である。論理テーブル番
号とはＮＣＬテーブル３００内の概念番号のひとつである。第３の部分は、タイ
プＩＤ番号が参照する概念が使用する物理テーブル内のレコード番号である。こ
れら三つの番号部分を参照して、もっとも基本的な構成関係、即ち「使用者/被
使用物」リンクを意味論ネットワークで表現する。従って、ＮＣＬテーブルの前
方、後方ポインタ順序に関して言えば、前方ポインタ順序は、概念が狭い、すな
わち「親概念」と感受され得る広い概念より狭い「子概念」であることを示す。
ここで言う親は、子を「使う」と言える。逆に、後方ポインタ順序は、概念が広
い、すなわち「子概念」と感受され得る狭い概念より広い「親概念」であること
を示す。この見方では、子は親に「使われる」ことになる。各樹部分ポインタは
概念関連タイプの情報を持つので、このような提示方法は、いかなる種類の関係
に適用できる。いかなる関係とは、定義（例えば、ＮＣＬテーブル３００におけ
る定義）、取り込み又は合成、類似または差異、継承性、分類上の関係等を含む
が、これらに限定されない。例えば、「家具」という概念は「椅子」という概念
に対して高レベル、すなわち広い概念である。一方、「ルイ４世の椅子」は「椅
子」よりも狭い概念である。概念の階層で、最も高レベルの概念は、生命、時間
、空間、エネルギー、物質の５つの大カテゴリーに分類される。前方参照順序領
域３１２と後方参照順序領域３１４との意味合いをより明確に理解するには、図
１３を参照して、当該特定言語における諸概念の名前を把握することが有用であ
る。

【００９０】 図１３は、本発明の翻訳テーブル３３０の例示である。このテーブルをテーブ
ル♯２と呼ぶ。翻訳テーブル３３０は、そのコンセプトの名前に対するストリン
グテーブルを参照することによって、コンセプトを自然言語ワードにＮＣＬ翻訳
したものを含む。カッコに示すコンセプトの英語板は、明確さと理解の容易さの
ためにのみ与えられる。翻訳テーブル３３０は、（１）レコード番号フィールド
３３２、（２）コンセプト番号フィールド３３４（コンセプト番号フィールド３
３４は図１のＮＣＬテーブル３００のレコード番号／ロジックテーブル番号フィ
ールド３０４内の同一物を追跡する）、（３）言語番号フィールド３３６、（４
）フォワード参照フィールド３３８の４つのフィールドを有している。

【００９１】 図１２に戻って、ＮＣＬテーブル３００内のフォワードポインタ参照を例示す
るために、レコード♯２２は、それが“物”コンセプトであることを示す。それ
は、フォワード参照シーケンスフィールド３１２のフォワード参照ポインタを含
んでいないので物カテゴリーにおける最上レベルにある（図２のレコード♯２２
を参照）。レコード♯２４は“現在”コンセプトを表わし、６．１．２３．のフ
ォワードポインタシーケンス値を有している。６はＮＣＬテーブル３００内の♯
６を意味している。翻訳テーブル内の一致レコードはこのフィールドタイプはコ
ンセプトであることを示している。２番目の番号、番号１、はＮＣＬテーブル３
００内のレコード番号を意味する。２番目の番号は、それはＮＣＬタイプであり
、レコード番号（３部フォワード参照シーケンス内の３番目の数）を探すのに用
いられる物理テーブル番号フィールド３０６内の物理テーブル番号は、テーブル
♯１（ＮＣＬテーブル３００）であることを示している。３番目の数は、２番目
の数によって決定された参照された物理テーブルにおけるレコード番号を示す。
この場合、数２３はテーブル♯１（ＮＣＬテーブル３００）におけるレコード♯
２３を指し示す。図１３の翻訳テーブル３３０によれば、レコード♯２３は時間
カテゴリである。すなわち、ＮＣＬテーブル３００におけるレコード♯２４（現
在）は時間コンセプトのジュニアまたは子供コンセプトである。バックワードポ
インタシーケンスフィールド３１４は、この場合のバックワードポインタが現在
のフィールドがシニアまたは親コンセプトが指し示しているジュニアまたは子供
コンセプトを指し示す点を除いて、フォワードポインタシーケンスフィールド３
１２と類似である。この場合、シニアまたは親コンセプトは単にその定義におい
て他のコンセプトを使用するコンセプトを意味するのに対して、ジュニアまたは
子供コンセプトは単に他のコンセプトの定義によって使用されるコンセプトを意
味する。

【００９２】 any-to-any計算機械は数コンセプト言語を基礎としているので、図１２−１７
の様々なレコードに用いられるカッコの記述子又は他の記号は理解を容易にする
ためにのみここに含まれている。この計算機械に実際に用いられるテーブルは、
ストリングテーブルなどのような、プリミティブデータクラス値テーブルにおけ
るフィールド値フィールドを除いて、様々なテーブル、レコード番号、そしてコ
ンセプトに対する数参照のみを含む。

【００９３】 データタイプもまたＮＣＬテーブル３００に含まれている。これらのタイプコ
ンセプトの例示はレコード番号３−１７などである。データ関係テーブルレコー
ドのデータレコードは翻訳テーブル３３０を介してＪａｖａクラスに関連してお
り、システムの内部言語を表わす言語番号ゼロを使用している。

【００９４】 基本的または原始レベルにおいて、データベースは、ストリング、整数、日付
などのプリミティブデータ値を記憶、サーチ、回収する方法を“知っている”。
このため、２，３のＪａｖａクラスはデータベースではプリミティブデータクラ
ステーブルとして知られており、対応するタイプの値を記憶するのに用いられる
。さらにデータベースは、Ｊａｖａクラスとして実行される、ロジックに対する
実行可能なコードを記憶及び回収することができる。Ｊａｖａクラスがネイティ
ブなデータ構造を表わす場合には、Ｊａｖａクラスは２つの機能を提供または継
承する。１つはデータ関係レコードからオブジェクトデータを読むこと、もう１
つはオブジェクトデータをデータ関係レコードに書き込むことである。このよう
にして、構造の詳細及びデータベースの実装は完全にロジック及び他のＪａｖａ
コードから隠蔽される。Ｊａｖａにおけるデータ関係テーブルレコードを表わす
ために、タイプ♯＋レコード♯参照を有するデータ関係テーブルレコードクラス
は、そのレコードに対する持続的識別子として定義される。レコードクラスは、
実際に使用されるフィールド及び値を示すキー＋値対の散在(sparse)マップを記
憶する。ここで、マップに対するキーはその値に対するコンセプトフィールドを
示すＮＣＬコンセプト番号であり、その値はプリミティブタイプ、データ構造ク
ラス、データ関係テーブルレコードまたはレコードオブジェクトを含むＪａｖａ
オブジェクトである。したがって、データベース構造が結果的に変更の必要があ
る場合には、現在のＪａｖａコードへの影響は最小である。Ｊａｖａプログラマ
にとって、データベースはデータ関係テーブルレコードオブジェクトを含む、ネ
イティブなＪａｖａオブジェクトを読み書きすることのようである。データ関係
テーブルレコードがＪａｖａによってデータベースから読み出されるとき、デー
タ関係テーブルレコードの参照からのタイプ番号が、データベースに内部言語（
ＮＣＬそのものを表わす言語ゼロ）におけるタイプ番号によって示されるコンセ
プトの名前をたずねることによって、Ｊａｖａクラスの名前を回収するのに使用
される。同様にして、フィールドラベルとして用いられるコンセプト番号は、Ｊ
ａｖａオブジェクトフィールド名を取得するために内部言語（ＮＣＬそのものを
表わす言語ゼロ）におけるコンセプトの名前と交換される。この情報はＪａｖａ
にとって回収したネイティブなＪａｖａオブジェクトを再構成するのに十分なも
のである。データベースはわずかな前述のプリミティブデータタイプを越えて特
定のＪａｖａクラスに無知のままである。

【００９５】 いくつかの他のレコードサブタイプは、ラベル、プロンプト、デフォールトビ
ュー、クエリー、ヘルプなどを含む特定のレコードまたはコンセプトに関連して
いる。この特定の実施形態においては、これらのレコードサブタイプは、図１４
に示すように、テーブル♯３３５０としてデータ関係テーブル−ＬＰＱＨと呼ば
れる自身のテーブル内に提供されている。データ関係テープル−ＬＰＱＨ３５０
は、レコード番号フィールド３５２、データ関係テーブルフォワード参照フィー
ルド３５４、サブタイプフィールド３５６、言語番号フィールド３５８、フィー
ルドフォワード参照シーケンスフィールド３６０を有する。データ関係テーブル
−ＬＰＱＨ３５０は、通常の方法で動作する（図示しない）バックワード参照シ
ーケンスフィールドをも有する。データ関係テーブルフォワード参照フィールド
３５４は、フォワードポインタであるから、それは上記した３部参照シーケンス
を有する。上記したのと同じパターンを辿ると、第１のデジットはＮＣＬテーブ
ル３００内のコンセプト番号を参照し、第２の番号はタイプ番号（この場合はサ
ブタイプ）を参照し、第３の番号はテーブル♯４内のレコード番号を参照する。
言語番号フィールド番号は使用されている言語を示している。この場合、番号“
１”はそれが英語であることを意味する。フィールドフォワード参照シーケンス
フィールド３６０は、特定のデータレコードに関連するレベルとしてストリング
テーブル内のフィールドを参照する。便宜的に、データ関係テーブル−ＬＰＱＨ
３５０は、特定のユーザ及び他の所望の管理フィールドによって好まれるように
すべく、ユーザ番号フォワード参照フィールド（図示せず）をも有している。

【００９６】 このデータベースシステムにおける参照は参照されたテーブルまたはアイテム
タイプ（加えてレコード番号）を含むので、データ関係テーブルレコードが任意
の数のフィールドのアッセンブリを生成するべく使用される。任意の数のレコー
ドタイプのアッセンブリを生成するべく同じ機構が使用され、後述する別個のア
ッセンブリテープル機構に対する必要性をなくしている。

【００９７】 新たなコンセプトフィールドが後にレコードタイプに追加されたなら、それら
はデータ関係テーブルレコード−ＤＡＴＡにおけるフィールドシーケンスの最後
になる。事実、現存のレコードの更新が許されるなら、任意のフィールドが好き
なときに任意のレコードに追加できる。これは、現在のレコードあるいはテーブ
ルを再構成する必要をなくして現在のタイプを増大し、ＮＣＬテーブル３００に
新たなコンセプトフィールドを追加する方法を提供する。

【００９８】 この参照機構の柔軟性のために、データ関係レコードは、その参照シーケンス
におけるＮＣＬテーブルコンセプトフィールドの他のレコードタイプを特定する
ことができ、他のレコードタイプのアッセンブリを効果的に生成することができ
る。加えて、データ関係レコードはそのフォワード参照シーケンスにおけるＮＣ
Ｌテーブルコンセプトフィールドの代わりに個々のデータレコードを特定して、
個々のレコード（“シングルトンオブジェクト”または“シングルトンクラス”
とも呼ばれる）のアッセンブリを生成することができる。この種のアッセンブリ
は、多数のデータレコードを特定するためのテンプレートとして使用することは
あまりできない。なぜならば、すべてのそのようなデータレコードはまさに同じ
データを含んでいるからである。しかしながら、それは、複雑な構成や、文字、
スプレッドシートあるいは他の複雑な文書などのより高い順位のデータアイテム
を具備するデータアッセンブリをモデル化するのに有益である。

【００９９】 同じ機能は使用されているフィールドにおけるタイプと値の混合を可能にし、
テンプレートに対する支持を可能にする。このことは、モジュールやロジックな
どの実行可能アイテムをも参照することになり、テンプレートを特定する上で大
きな柔軟性となる。例えば、データレコードは、データフィールド、特定のユー
ザのアドレスレコード（通常とおりアッセンブリである）、（“拝啓”などの）
特定のあいさつデータレコード、テキストアッセンブリ（後述）に対する他のデ
ータレコードタイプあるいはコンセプト、特定の署名レコード（加えてテキスト
アッセンブリ）、そしてデジタル化された署名に対するデータレコードを特定す
る。これらのエントリはフォームレターに対するテンプレートタイプを効果的に
定義する。テキストアッセンブリに対するデータレコードタイプは、フォームレ
ターの本体に対する“ボラープレートbollerplate”に影響を与えるべく、予め
存在するテキストデータレコードを名前フィールド参照と組合わせる。

【０１００】 この新たなテンプレートあるいはタイプのインスタンスは、ユーザあるいは他
の入力源に対して、新たなデータレコードに対するデータ−値マッピングを完成
させるべく名前フィールド値を書き込むことを依頼し、本体テキストに記載され
ている名前のみが異なるフォームレターを簡単に作り上げる。

【０１０１】 一般に、各ＮＣＬテーブルコンセプトフィールドは、データ関係テーブルレコ
ード−ＤＡＴＡとして図１５に示すように、自身のデータクラス値テーブル３７
０を有している。多数の値を有する各コンセプトは、同様なデータクラス値テー
ブルを有しているが、そのようなテーブルはただ１つのコンセプトの値のみを含
まない。実際の傾向は、高速なアクセス及び蓄積オーバヘッドを低減するために
、同じ物理テーブルにおいて同様の構造とサイズを有するデータクラス値を記憶
することであるが、論理モデルの観点から、各データクラス値テーブルは独立し
ている。事実、すべてのデータクラス値は、（データ関係テーブルレコード−Ｄ
ＡＴＡテーブル３７０などの）単一のテーブルに記憶可能である。この場合、ス
トリングやデートなどのプリミティブデータ値タイプは最適なインデックス化と
サーチのために個々のテーブルに分離される。

【０１０２】 フィールドの値として使用される各参照に対して、参照されたデータアイテム
は、導出された“バックポインタ”、参照バック参照シーケンスフィールド３７
６においてタイプされた関係を記憶する。言い換えると、すべての参照された値
は、どのレコード及びフィールドがそれらを参照したかを“知っている”。これ
らの依存関係を維持するために、データベースの中の各レコードは、依存性トレ
ーラを有している。この依存性トレーラは単に、コンセプト番号、タイプＩＤ番
号、それが値として参照されたテーブル内のレコード番号フィールドのレコード
番号からなるシーケンスまたはリストである。これらの依存性トレーラはバック
参照シーケンスとして呼ばれる。２つの術語は交換可能である。同様にして、フ
ィールドフォワード参照シーケンスフィールド３７４はデータアイテムによって
参照される全ての値に対するフォワードポインタを記憶する。依存関係の収集物
はデータベースに対する意味論上のネットワークを具備し、すべてのレコード内
のすべてのフィールドをインデックスすることと全く等価な直接アクセスパスを
提供する。

【０１０３】 データベースに使用した基本または原子データ値は一度および一度だけ記憶さ
れそしてそれらを必要とする全ての記録で参照される。この方法は必要とされる
記憶装置を減少し、付加的なアクセス時間を犠牲にしてもコーレデューシング概
念探索機構を簡単化する。例えば、図１６は、文字列値に対するデータクラス文
字列表３８０の一部を示し、各一意文字列値は一度だけ記憶され、そしてある一
定の文字列値に設定した全てのフィールド値は、所望の文字列の記録番号及び文
字列表番号を単純に参照する。表３８０は、他のデータ関連表記録で使用するた
めに基本文字列値を単純に保持する。表３８０は、記録番号フィールド（欄）３
８２、フィールド値フィールド３８４及びバック参照シーケンスフィールド３８
６を備えている。バック参照シーケンスは、どの種類の記録であるか又はどのフ
ィールドが使用されるかに関係なく、この特定の文字列をあるフィールドにおけ
る値として用いることにより全ての記録にポイントする。各バック参照は前に説
明したように一連の三つの番号である。第１の番号は、概念を指示するＮＣＬ表
３００における論理表番号３０２にポイントする。第２の番号は、特定のデータ
値がどのように使用されるか（型ＩＤ）を示しそしてその特定の論理表番号で使
用した物理的表を指示するＮＣＬ表３００における記録番号にポイントする。第
３の番号は、第２の番号参照で指示した論理表番号（型ＩＤ）で使用した物理的
表における記録番号を表している。データクラス文字列表３８０は必要ならば前
方参照シーケンス（図示していない）を有することができる。

【０１０４】 所与データ項に対するバック参照シーケンスの図示例の説明はこの“索引付け
”がどのように作用するかを明りょうにするのに役立つべきである。文字列表３
５０における記録番号１１２（ｍｅ＠ホームネット）に対するバック参照シーケ
ンスポインターは３１．２９．４及び３１．２９．１２である。各シーケンス番
号における最初の番号３１は図１２のＮＣＬ表３００における論理表番号又は記
録番号及び図１３の変換表３３０における関連記録番号を参照する。論理表番号
３１を参照することによりこのデータ項が概念“Ｅメールアドレス”であること
を表している。第２の番号２９は、このデータ項が、文字列がＥメールアドレス
型のデータであることを表すサブＥメールＥメールアドレス型であることを表し
ている。このデータ型は物理的表＃４、図１５のデータ関連表記録ＤＡＴＡ３７
０を参照する。図１５及び表３７０（データ関連表記録ＤＡＴＡ）では、バック
参照シーケンスポインターの第３の番号は、表３７０における相応した記録番号
に関する４及び１２である。記録＃４、＃１２に対するフィールド前方参照シー
ケンス３７４はこれらのデータ記録を参照する同じデータ項、図１６の文字列表
３８０における“ｍｅ＠ホームネット”文字列に対して前方にポイントする。記
録＃４、＃１２に対する参照後方参照シーケンス３７４は二つの異なる概念３３
．３２．３及び３４．３２．９に対して後方にポイントする。これらのデータ項
の表す概念及び型を決める同じ処理を通すことにより、３３．３２．３“Ｆｒｏ
ｍ”概念であり、３４．３２．９は“Ｔｏ”概念であることがわかる。言い換え
れば、この文字列値は、これらの概念に対する変換表３３０における文字列値前
方ポインターで指示されるＥメール型の“Ｔｏ”アドレス又は“Ｆｒｏｍ”アド
レスとして用いられる。この場合、前方及び後方ポインターは、データ文字列“
ｍｅ＠ホームネット”がＥメールアドレスでありそして“Ｆｒｏｍ”Ｅメールア
ドレス及び“Ｔｏ”Ｅメールアドレスとして用いられることをディスクローズし
ている。

【０１０５】 次に、コーレデューシング概念の簡単化形態を例示している図１８を参照する
と、反復記号４１０、４２０、４３０、４４０はワード“Ｍｙ”４１２、“Ｎｅ
ｗ Ｙｏｒｋ”４２２、“Ｃｌｉｅｎｔ”４３２、及び“Ｆｒｉｅｎｄｓ”４４
２でそれ自体表される（また人間間で伝送される）概念を表している。人が他人
にワード“Ｍｙ”４２２を言う時、聞く人は、このワードが話す人にある仕方で
属している全てのもの、すなわち彼の車、彼の家、彼の妻に関するものであり、
そして“ｍｙ”の適用されない他の全ての概念を除外するものと理解する。言い
換えれば、各ワードの伝達は、しばしばアートの状態及び種々の言語学上の練習
において教示される包含又は展開又は推敲プロセスに正反対に相対した連続した
除外プロセスである。同様に、話す人がワード“Ｆｒｉｅｎｄｓ”４４２を言う
と、伝送概念４４０は、ワード“ｆｒｉｅｎｄ”の適用され得る世界中の不特定
の人及び万人を包囲し、全ての他の概念を除外する。世界中には６０億人が存在
し、そのほとんど人がワード“Ｆｒｉｅｎｄｓ”４４２の適用され得る一人以上
の人を知っていると想定されるので、ワード“Ｆｒｉｅｎｄｓ”４４２自体を言
うことにより伝達される概念４４０は莫大である。

【０１０６】 しかしながら、ワード“Ｍｙ”４１２及び“Ｆｒｉｅｎｄｓ”４４２が前後し
て一緒に言われると、明らかに目下参照されていることは、“Ｍｙ”の概念４１
０の一部が“Ｆｒｉｅｎｄｓ”の概念も含むことであり、また同様に“Ｆｒｉｅ
ｎｄｓ”の概念４４０の一部が“Ｍｙ”の概念も含むことである。言い換えれば
、二つのワードを一緒に言うことは組み合わさった両概念４１０、４４０の概念
を他を含むそれぞれの概念の部分に減少する効果をもっている。これは、二つの
反復記号４１０、４４０の互いに重なる部分を観ることにより例示される部分で
ある。ワード“Ｎｅｗ Ｙｏｒｋ”４２２及び“Ｃｌｉｅｎｔ”４３２を言い、
それにより関連した概念４２０、４３０を伝達すると、減少プロセスがさらに続
き、常に全ての概念が重なる各概念の部分４５０を実際に特定化する。概念の供
給される順序は、特定化した結果としての概念には重要ではないが、さらに後に
供給されたワードの意味にとっては重要でなくはない。従って、“Ｍｙ Ｎｅｗ
Ｙｏｒｋ ｃｌｉｅｎｔ ｆｒｉｅｎｄｓ”は、通常の表現の逆である“ｍｙ
ｃｌｉｅｎｔ ｆｒｉｅｎｄｓ ｉｎ Ｎｅｗ Ｙｏｒｋ”又は“ｆｒｉｅｎ
ｄｓ、Ｎｅｗ Ｙｏｒｋ、ｃｌｉｅｎｔ、ｍｙ”と正確に同じことを特定してい
る。

【０１０７】 ユーザーが、作用の実行されることになる事柄を特定したい、例えば“ｍｙ
Ｎｅｗ Ｙｏｒｋ ｃｌｉｅｎｔ”にＥメールを送りたい時には、仕様“Ｍｙ
Ｎｅｗ Ｙｏｒｋ ｃｌｉｅｎｔ”は、正しいデータクラスのデータ構成要素の
各々をもつデータ関連表記録の形式のデータ関連表に問い合わせとして供給され
る。一致される記録又は複数の貴論におけるＮＣＬエントリーの部分は、量が一
つであることを記述するＮＣＬエントリーを含んでいる。項“ｃｌｉｅｎｔ”は
１の量の概念を含み、この情報は項“ｃｌｉｅｎｔ”に対するＮＣＬ変換に現れ
る。探索コマンドがランする場合、仕様に合った一人以上の人が存在すると、結
果は、一つ又は実際には幾つかである不一致関連量である。不一致は探索モジュ
ールをトリガーして“ｗｈｉｃｈ ｏｎｅｓ？”のような組み合さったプロンプ
ト記録から導出したプロンプトを発生し、それによりコーレデューシング概念原
理を適用する。この原理はさらに結果としての一致を表示しかつ別の概念をプロ
ンプト操作することにより適用され得る。これにより対話型探索を行うことがで
きる。

【０１０８】 簡単な場合は、このプロセスが従属後書きでどのように行われるかを例示する
。例えば、ユーザーが計算機にコーレデューシング概念に等価の質問をして“Ｂ
ｉｇ ＆ Ｈａｉｒｙ ＆ Ｃａｒｎｉｖｏｒｏｕｓ ＆ Ｂｒｏｗｎ”を探索
する。この問い合わせは、概念“ｂｉｇ”、“ｈａｉｒｙ”、“ｃａｒｎｉｖｏ
ｒｏｕｓ”及び“ｂｒｏｗｎ”に対する相応したデータ値を探索し、それらの従
属後書きを参照のセットとして処理し、そして参照のセットを共通集合すること
によって行われる。結果としてセットは全ての品質データ記録を簡潔に特定し、
そしてこれらのデータ記録は読み出され得る。このメカニズムは、初期概念値記
録及び結果としてのセットで参照した記録を除いて全ての記録を読み出す必要な
く、任意の数の概念項を用いてそのような問い合わせを満足する。また、この種
の問い合わせは、“ｌａｒｇｅ”、“ｆｕｒｒｙ”、“ｏｍｎｉｖｏｒｏｕｓ”
のような一層概念的なグランドをカバーする任意の概念階層によってよりアブス
トラクトな概念に容易に拡張できる。このメカニズムにより、コンピューターは
“復帰最近真理”操作でき、人間の習慣をエミュレートする機構に加えられる項
は、所与問い合わせが正しくない場合に人間を正しい最近有効情報に復帰できる
。従って一人が別の問い合わせ“Ｊｏｙは飛行機でニューヨークへ行ったのか？
”を行うことができ、そして“いいえ、彼は列車でサンフランシスコへ行きまし
た”との回答を受ける。項“ニューヨーク”及び“サンフランシスコ”は、それ
らが空間データカテゴリー概念階層の一つのジュニアであり、すなわち米国の概
念の範囲内であるので、相互に関連している。同様に、“飛行機”及び“列車”
は “旅行”がシニアメンバーである作用データ概念カテゴリー階層のメンバー
である。なおこの探索はシーケンス記録のようなコンテナを介して自動的に伝え
られる。

【０１０９】 既存のブール演算子を用いることにより、ドラマテックな結果をもつ任意の既
存のインターネット探索エンジンにコーレデューシング概念原理を適用するのに
ほとんどプログラミング操作は必要でない。ユーザーの探索に対する過剰な一致
が得られる際には、コーレデューシング概念原理は、別の概念に対してユーザー
を引き続きプロンプトすることによって適用される。既存の探索エンジン論理は
これらのプロンプトを使用して目下供給されている全ての概念に一致しない記録
を削除する。このプロセスは明確に続けられ、それにより、ブール演算子又は複
雑なアドバンス探索の構成を理解する必要なしに、ユーザーは数千のヒットの数
百倍のものを彼の必要な二、三にダウンできる。

【０１１０】 同様に、既存のインターネット探索エンジンに対するさらなる改良は、データ
ベースがすでに含んでいるデータ（上述の計算機原理のように）をできるだけ多
くのデータクラスに分類することによって得られ得る。従って、ユーザーは全て
のデータクラスを同時に与えそして彼の利用できるデータをできるだけ多くのデ
ータクラスに入れることのできるインターフェースをもつ。従って、最初の探索
で、ステートオブザアートプラクティスに比較して相当に減少したセットの記録
が生じられる。このプラクティスにより、インターフェースの視覚的特定データ
エントリーバージョンがリストされるべきウエブマスターに与えられる場合、ウ
エブマスターは彼のサイトをリストできそして彼のサイトを“クロー”するため
探索エンジンを待つことなしに恐らくそれをリストすることなしに瞬時的にそれ
を再び探索できる。この任意の計算機に夜この方法は、アートの状態における相
当な問題を解決でき、ウエブサイトの７０％は任意の探索エンジンにリストされ
ない。

【０１１１】 さらに、この問い合わせ機構は、従属後書きセットを一度に一つづつ単に共通
集合し、す中間結果を表示し、そして関係タイプを用いて従属後書きセットを予
備フィルタリングすることにより増加すなわち“ダイナミック”探索操作をサポ
ートする。これらのセットは共通集合ではない共用又は差のような任意の有効な
セット演算子を用いて結合され得る。 この実施の形態の物理的構造は図５、図
６及び図７に例示したものと相当異なるが、最初のものと論理的に等価である。
それの能力及び特徴は正確には以下の説明における要求として定義したものであ
り、またそれの利点は、リアルワールドデータに対する比較的有効で融通性のあ
る記憶機構であることにある。意味ネットワークにおけるそれの基本は、ハイパ
ーオブジェクト方向決めプログラミングモデルに対して容易に拡張できるステー
トオブザアート技術に基づく十分に検討した形式グランディングを備えている。
概念階層における定義された関係の形式に対するさらなる拡張により、エックス
パートシステムで普通に要求されるもののような比較的複雑な知識表示をサポー
トできる。

【０１１２】 図１９Ａ−Ｈは本発明において説明した種々の一般的なフィールド名及びデー
タカテゴリーを示している。図１９Ａは、データカテゴリーフィールド５０２と
、フィールド番号フィールド５０４と、一般的なフィールド名フィールド５０６
と、情報フィールド５０８と、例フィールド５１０とを備えたデータ関連表デー
タクラスリスト５００を示している。；データカテゴリーフィールド５０２は、
前に述べた六つの主カテゴリー、生活、時間、空間、作用（エネルギー）、事象
及び管理の種々の表示を含んでいる。フィールド番号フィールド５０４は各一般
的なフィールド名に対する割当フィールド番号を含んでいる。一般的なフィール
ド名フィールド５０６は、記録番号フィールド５０４における特定の記録番号と
組み合さった特定のフィールドの名を参照する。情報フィールド５０８は、フィ
ールド名フィールド５０６におけるフィールド名で表される特定のフィールドの
簡単な記載を含んでいる。例フィールド５１０はフィールド番号５０４と組み合
さったデータの形式の短い例を含んでいる。これらのフィールド名及びモジュー
ルの大部分は詳細な説明の残りの部分により明りょうに記載されている。

【０１１３】 上記の観点で、種々の表、ソフトウエア論理及びコンピュータを任意の計算機
として機能させ得る方法のさらに一般的で詳細な説明を以下に記載する。

【０１１４】 発明の実施の形態について説明してきたが、上記の説明は単に例示のためのも
のである。当業者には認められるように、本発明の例示実施の形態の方法及び装
置は多くの応用がなされ得る。ここに説明してきた本発明の例示実施の形態のさ
らなる変更はそれぞれの技術分野における当業者によってなされ、そしてそのよ
うな全ての変更は特許請求の範囲に定義した本発明の例示実施の形態の範囲内に
あるとみなされる。

【図面の簡単な説明】

【図１】 インターフェイス制御システムと命令実行システムを含む、任意数対任意数対
応コンピュータ装置の、機能的ブロックダイアグラムである。

【図２】 インターフェイス制御システム、言語処理システムおよび命令実行システムを
含む、任意数対任意数コンピュータ装置の機能的ブロックダイアグラムである。

【図３】 任意数対任意数コンピュータ装置に使用される命令実行システムに含まれる項
目の機能的ブロックダイアグラムであり、これらの項目は、データ関連表の形で
保存されることがある。

【図４】 任意数対任意数コンピュータ装置で使用される言語処理システムに含まれる項
目の機能的ブロックダイアグラムである。

【図５】 任意数対任意数コンピュータ装置で使用される数値概念言語辞書を示す模式図
である。

【図６】 任意数対任意数コンピュータ装置で使用される論理表を示す模式図である。

【図７】 任意数対任意数コンピュータ装置で使用されるデータ関連表における、データ
／ソフトウェアｎ重体の使用例を示す模式図である。

【図８】 任意数対任意数コンピュータ装置で使用されるデータ関連表の構造を示す模式
図である。

【図９】 言語処理システムを含む、任意数対任意数コンピュータシステムにおける、自
然言語コマンドに対応する行程を示す論理フローチャートである。

【図１０】 任意数対任意数コンピュータシステムにおける言語処理システムの論理フロー
チャートである。

【図１１】 言語処理システムを含まない任意数対任意数コンピュータシステムにおける、
自然言語コマンドに対応する行程を示す論理フローチャートである。

【図１２】 概念と、データクラス表物理的保存状態を定義する、数値概念言語表の埋設状
態を示す模式図である。

【図１３】 図１８に示したストリング（文字列）表の、ストリング値にたいする前方参照
を含む翻訳表を示す模式図である。

【図１４】 データ関連表の、ラベル、プロンプト、請求、および、ヘルプ記録サブタイプ
を示す模式図である。

【図１５】 データ値の数値概念言語を含む、データクラス表記録ＤＡＴＡを示す模式図で
ある。

【図１６】 データクラス・ストリング表の一部を示す模式図であって、同表は、英語概念
言語におけるストリング値を、それに関連する、変換された数値概念言語値と併
せて含む。

【図１７】 関連概念のバイトコードにたいする参照を含むＪａｖａクラス表の一部を示す
模式図である。

【図１８】 共同縮小概念原理を示す模式図である。

【図１９Ａ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｂ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｃ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｄ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｅ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｆ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｇ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｈ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｉ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｊ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｋ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｌ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｍ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【図１９Ｎ】 本発明の一つの実施態様に使用される、一般フィールド名とデータカテゴリー
を列挙する模式図である。

【符号の説明】

１０…システム １２…ユーザ １４…インタフェース制御システム １６…実行システム １７…データ関係テーブル １８…言語処理システム ２０…コンポーネント ２２…データコンポーネント ２４…概念階層テーブル ２６…データ分類インタフェース ２８…論理テーブル ３０、３１…フィールド ３３…データフィールド ３４…グラマフォーマッティングモジュール ３５…言語規則ベース ３６…規則ベース ３８…数的概念言語辞書 ４０…言語構造 ４３…データ分類フィールド ４４…データカテゴリ ５０ａ…レコード ５８…ソフトウエアモジュール

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ， ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，Ｇ Ｍ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ， ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ， ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，Ｂ Ｚ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ， ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，Ｊ Ｐ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ， ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，Ｒ Ｏ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ，ＵＺ， ＶＮ，ＹＵ，ＺＡ，ＺＷ Ｆターム(参考） 5B076 DA03 DD04 5B081 AA08 BB03

Claims (20)

【特許請求の範囲】
1. 【請求項１】 データをデータ成分に逆アセンブリし、そのうちの逆アセンブリは、実質的に
   全ての根源意味の欠如を引き起こすものであって、 各データ成分を独立に記憶すること、 を特徴とするデータをデータ成分に分解し、実質的に全ての根源の意味を有す
   るデータを記憶する方法を定義したコンピュータ実行可能な指示を格納するコン
   ピュータ読みとり可能な記憶媒体。
2. 【請求項２】 複数のソフトウェア成分としてソフトウェアを生成することで、所望する機能
   を有するソフトウェアを記憶し、そのうちの前記逆アセンブリは、実質的に全て
   の前記所望するソフトウェアの欠如を引き起こすものであって、 各ソフトウェア成分を独立に記憶すること、 を特徴とする請求項１記載のコンピュータが読みとり可能な記憶媒体。
3. 【請求項３】 前記データ成分をデータ成分タイプに分類し、 関連するデータ成分タイプに関して動作を実行する、一又はそれ以上のソフト
   ウェア成分或いはソフトウェア成分のアセンブリを記憶すること、 を具備することを特徴とする請求項２記載のコンピュータが読みとり可能な記
   憶媒体。
4. 【請求項４】 データ成分のアセンブリをデータ成分のアセンブリタイプに分類し、 関連するデータ成分アセンブリタイプに関して動作を実行する、一又はそれ以
   上のソフトウェア成分或いはソフトウェア成分のアセンブリを記憶すること、 を具備することを特徴とする請求項３記載のコンピュータが読みとり可能な記
   憶媒体。
5. 【請求項５】 データ項目をカテゴライズするための複数のセマンティックデータ分類を具備
   するデータ分類インタフェースを定義し、 データ項目に対応する数値インジケータを含むフィールドを具備する複数のレ
   コードを定義し、 数字概念言語によって定義された複数の数値インジケータであって、当該数値
   インジケータのそれぞれは、あるベースデータ項目に固有に関連付けられており
   、 データ項目に関連付けられたレコードの特定フィールドに置かれた特定の数値
   インジケータを結びつけたレコードのフィールドに、セマンティックデータを関
   連させ、 データ成分を、データ構造において表現されたレコードとして記憶すること、 を具備することを特徴とするデータをデータ成分に分解し、実質的に全ての根
   源の意味を有するデータを記憶する方法を定義したコンピュータ実行可能な指示
   を格納するコンピュータ読みとり可能な記憶媒体。
6. 【請求項６】 データ関係構造に表現されたレコードとして、前記ソフトウェア成分をさらに
   記憶することを特徴とする請求項５記載のコンピュータ読みとり可能な記憶媒体
   。
7. 【請求項７】 特定のフィールドにおける数値識別子を有する一又はそれ以上のデータ成分と
   、前記特定のフィールドにおける数値識別子を有する一又はそれ以上のソフトウ
   ェア成分とは、データ成分を動作するソフトウェア成分と識別することを特徴と
   する請求項６記載のコンピュータ読みとり可能な記憶媒体。
8. 【請求項８】 自然言語ブロックを受信し、 前記自然言語ブロックを、データ関係構造に表現された一又はそれ以上の対応
   するレコードに変換し、 前記データ関係構造において対応するレコードを記憶すること、 を特徴とする請求項７記載のコンピュータ読みとり可能な記憶媒体。
9. 【請求項９】 一又はそれ以上のフィールドであって、数値識別子を有する前記対応するレコ
   ードのフィールドを識別し、 フィールドにおいて数値識別子を有するデータ成分を動作する一又はそれ以上
   のソフトウェア成分を識別し、 前記データ成分を動作するためのソフトウェア成分を呼び出すこと、 を特徴とする請求項８記載のコンピュータ読みとり可能な記憶媒体。
10. 【請求項１０】 コンピュータが実行可能な指示を記憶するコンピュータ読みとり可能な記憶媒
    体であって、 前記コンピュータが実行可能な指示は、データ入力の受信及び当該データ入力
    に応答した動作の実行を行うことが可能な順序実行システムを含むコンピュータ
    システムを定義するものであり、 前記順序実行システムはデータ関係構造を具備し、 前記データ関係構造は、 根源の意味を有するデータ項目をカテゴライズする複数のセマンティックデー
    タ分類を定義するデータ分類インタフェースと、 前記データ項目に対応する数値インジケータを有するフィールドを定義する複
    数のレコードと、 各数値インジケータがベースデータ項目に固有に関連する数字概念言語辞書に
    よって定義される数値インジケータと、 前記データ項目に対してあいまいでない意味を識別するデータ成分を暗示する
    レコードの特定のフィールドにおいて、特定の数値インジケータの連想を適応す
    るためのレコードのフィールドに関するセマンティックデータ分類と関連をもつ
    データ関係構造と、を具備すること、 を特徴とするコンピュータ読みとり可能な記憶媒体。
11. 【請求項１１】 データ成分に逆アセンブリされた根源の意味を有するデータブロックであって
    、当該逆アセンブリは実質的に全ての前記根源の意味の欠如を引き起こすデータ
    ブロックと、 前記データ関係構造において表現されたレコードとして、独立に記憶された各
    データ成分と、 を具備することを特徴とする請求項１０記載のコンピュータ読みとり可能な記
    憶媒体。
12. 【請求項１２】 複数のソフトウェア成分から構築された所望の機能を有するソフトウェアであ
    って、その中の逆アセンブリは、実質的に全ての前記所望の機能の欠如を生じさ
    せるソフトウェアと、 データ関係構造において表現されたレコードとして独立に記憶された各ソフト
    ウェア成分と、 を具備することを特徴とする請求項１１記載のコンピュータ読みとり可能な記
    憶媒体。
13. 【請求項１３】 前記データ関係構造は、機能的にデータ関係テーブルとして構成されているこ
    とを特徴とする請求項１２記載のコンピュータ読みとり可能な記憶媒体。
14. 【請求項１４】 前記データ関係構造は、機能的にセマンティックネットワークとして構成され
    ていることを特徴とする請求項１２記載のコンピュータ読みとり可能な記憶媒体
    。
15. 【請求項１５】 前記データ分類インタフェースのデータ分類は、管理（administration）、生
    活（life）、時間（time）、空間（space）、行動（action）、物質（matter）
    を有するカテゴリの群から選択された複数のセマンティックデータカテゴリにグ
    ループ化されていることを特徴とする請求項１２記載のコンピュータ読みとり可
    能な記憶媒体。
16. 【請求項１６】 前記データ関係構造において表現されたレコードは、データレコード、コンデ
    ィションレコード、コードレコード、プロンプトレコード、ラベルレコード、ヘ
    ルプレコードを有するレコードタイプの群から選択されていることを特徴とする
    請求項１２記載のコンピュータ読みとり可能な記憶媒体。
17. 【請求項１７】 自然言語ブロックを受信する動作が可能なインタフェース制御システムと、 前記インタフェース制御システムから自然言語ブロックを受信し、前記自然言
    語ブロックを前記データ関係構造において表現された一又はそれ以上の対応する
    レコードに変換し、且つ前記自然言語ブロックを要因とする固有の意味を含み、
    順序実行システムに対して対応するレコードをパッシングする、各動作が可能な
    言語処理システムと、 を具備することを特徴とする請求項１２記載のコンピュータ読みとり可能な記
    憶媒体。
18. 【請求項１８】 前記言語処理システムから対応するレコードを受信し、 前記対応するレコードがあいまいでない命令を定義するか否かを決定し、 前記対応するレコードがあいまいでない命令を定義する場合、命令を実行し、 前記対応するレコードがあいまいでない命令を定義しない場合、付加的な情報
    に対して前記インタフェース制御システムをユーザにプロンプトさせること、 を特徴とする請求項１７記載のコンピュータ読みとり可能な記憶媒体。
19. 【請求項１９】 前記データ関係構造において表現された複数の構成コードレコードは、マルチ
    ステップ動作を実行するソフトウェアモジュールを定義することを特徴とする請
    求項１８記載のコンピュータ読みとり可能な記憶媒体。
20. 【請求項２０】 特定のフィールドの数値識別子を有する一又はそれ以上のデータレコード、及
    び前記特定のフィールドの数値識別子を有する一又はそれ以上のコードレコード
    は、前記データレコードによって定義されたデータに関する動作を行う前記コー
    ドレコードによって定義されたソフトウェアを識別することを特徴とする請求項
    １８記載のコンピュータ読みとり可能な記憶媒体。