JPS63217465A - 情報抽出方法 - Google Patents

Abstract

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

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本明細書で開示する発明は一般にデータ処理に関し、さ
らに具体的には、データ処理における言語学的アプリケ
ーシヨンに関するものである。

Ｂ、従来技術 テキスト処理システムおよびワード処理システムは、独
立型アプリケーション用および分散処理アプリケーショ
ン用のものが開発されてきた。テキスト処理およびワー
ド処理という用語は、本明細書では互いに置き換えて使
えるものとし、主として、文字で書かれたテキストを構
成する英数字ストリングの作成、編集、通信、または印
刷、あるいはこれらすべてに使用されるデータ処理シス
テムを指すものである。ワード処理用の具体的な分散処
理システムは、１９８５年９月３０日に出願された同時
係属の米国特許出願第７８１８６２号に開示されている
。この特許出願の図および明細書を、本明細書の発明を
適用することができるホスト・システムの一例として、
引用により本明細書に組み込む。

文書検索は、ユーザの照会に関連した情報を含んでいる
記憶文書を発見する機能である。従来技術のコンピュー
タによる文書検索法は、論理的に、文書検索データ・ベ
ースを作成するための第１の−処理と、そのデータ・ベ
ースをユーザの照会で問い合わせるための第２の処理に
分類される。データ・ベースを作成する処理では、デー
タ・ベースに入力したい各文書を一義的な文書番号と関
連づける。次に、文書のテキストに含まれる単語を走査
して、逆ファイル索引にコンパイルする。逆ファイル索
引は、走査されるすべての文書に出てくる異なる単語を
すべて集めたものである。文書の各単語を走査するとき
、対応する文書番号をその単語と関連づけ、逆ファイル
索引全体を探索して、その単語が、データ・ベースに入
力された現文書または前文書で、以前に出てきたかどう
か判定する。その単語が前に出てきていない場合は、そ
の単語を新しい単語として逆ファイル索引に入力し、文
書番号をそれと関連づける。一方、現文書または前文書
で、その単語が前に出てきている場合は、逆ファイル索
引中のその単語の位置を見つけ、単語が見つかった前文
書の番号の集まりに現文書の番号を追加する。追加の文
書がデータ・ベースに付加されるとき、逆ファイル索引
中の異なるそれぞれの単語について、その単語を含む文
書に対する追加の文書番号が累積される。逆ファイル索
引は文書検索システム内のデータ・プロセッサのメモリ
に記憶される。各文書番号と、そのタイトルや位置やそ
の他の識別属性等の対応する文書識別を含む文書テーブ
ルもメモリに記憶することができる。通常、文書索引デ
ータ・ベースを作成するための従来技術の手法では、逆
ファイル索引をコンパイルする際に文書全体を走査する
ことが必要であった。逆ファイル索引および文書テーブ
ルがコンピュータ・メモリ内で作成された後、従来技術
のコンピュータによる文書検索法の第２の段階を実行す
ることができる。すなわち、特定の検索アプリケーショ
ンでユーザがシークしている文書の種類を特徴づけるた
めにユーザが選択した照会単語または表現をユーザが入
力することができる。

ユーザがその照会単語を入力すると、各単語が逆ファイ
ル索引と比較されて、その単語が逆ファイル索引に以前
に入力されたいずれかの単語と一致するかどうかが判定
される。照会単語とうまく一致したときは、逆ファイル
索引中の一致した項目に対する対応する文書番号が記録
される。ユーザの入力照会中に、他にもまだ、単語があ
る場合は、それぞれの単語が逆ファイル索引中の単語と
の突合せ操作を施されて、一致した単語の対応する文書
番号が記録される。次に、得点評価法を用いて、ユーザ
の入力照会中の単語と一致する単語を最も多く含む文書
を識別する。得点が最高の文書は、次にそれらのタイト
ルまたはその他の識別属性を検索システム内のコンピュ
ータ用の表示モニタ上に表示させることができる。その
ような従来技術の文書検索システムの一例はＩＢＭシス
テム／３７０記憶・文書情報検索システム（ＳＴＡＩＲ
８）であり、このシステムはｒＩＢＭシステム／３７０
記憶・情報検索システム／仮想記憶装置−シラーラス・
言語学的統合システム（ＩＢＭ　Ｓｙｓｔｅｍ／３７０
Ｓｔｏｒａｇｅ　ａｎｄ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒ
ｅｔｒｉｅｖａＩ　Ｓｙｓｔｅｍ／Ｖｉｒｔｕａｌ　Ｓ
ｔｏｒａｇｅ−Ｔｈｅｓａｕｒｕｓ　ａｎｄ　Ｌｉｎｇ
ｕｉｓｔｉｃＩｎｔｅｇｒａｔｅｄ　Ｓｙｓｔｅｍ）　
Ｊと題するＩＢＭ社の刊行物ＧＨ１２−５１２３−１（
１９７８年１１月）に記載されている。もう一つのこう
したシステムが米国特許第４３５８８２４号に記載され
ている。

Ｃ０発明が解決しようとする問題点 これら従来技術の文書検索システムは十分に働くとはい
え、文書は異なるテーマを有し、異なるときに異なる著
者の手で書かれているので、ユーザは特定の著者または
特定の主題または日付、あるいはその両方の特定の文書
だけをシークすればよい。この検索関連情報を検索パラ
メータと呼ぶ。

文書を検索したいと考えるユーザが著者、日付、受信者
、住所、主題の記述、またはその他の文書パラメータの
みを覚えているようなビジネス通信文の場合に特にそう
である。したがって、データ・ベース作成の過程でビジ
ネス通信文パラメータヲ分離し、したがって、そのよう
なビジネス通信文パラメータを含む照会を使ってビジネ
ス通信文の検索が容易になる、文書検索システムを有す
ることが望ましい。ビジネス通信文を確実に検索する問
題は、データ・ベース作成段階においてデータ・ベース
にコンパイルされたパラメータの項目と正確に同じでな
い項目を含む照会をユーザがコンパイルする場合、さら
に大きくなる。データ・ベースのコンパイルで使用され
る項目とは言語構造、構文または意味が異なる項目を照
会中で使っているビジネス通信文を検索するのに適した
文書検索システムを有することが望ましい。

Ｄ０問題点を解決するための手段 自由な書式の文書の著者、日付、受信者、住所、主題の
記述等のパラメータ・フィールドを自動的に識別する、
パラメータ情報抽出（Ｐ　Ｉ　Ｆ）システムが開発され
た。プログラム生成データを直接使って、または手動で
補足して、自動インデクシングまたはインデクシング・
エイドを提供することができる。

ＰＩＦシステムは、構造、構文、および意味論上の知識
を使ってその目的を達成する。構造解析によって文書の
見出し、本文、および結びを識別する。パラメータ情報
を含む構成要素である見出しおよび結びを、次に一連の
形態論、構文、および意味論上のパターン突合せ手順に
よって解析して、コンピュータで容易に操作可能な標準
化された形でパラメータ情報を提供する。

Ｅ、実施例 文書検索とは、ユーザの照会に関連する情報を含む記憶
文書を見つけるという問題である。文書は異なるテーマ
を有し、異なるときに異なる著者の手で書かれているの
で、ユーザは特定の著者または特定の主題または日付、
あるいはそのすべてだけをシークすればよい。この検索
関連情報を「パラメータ」と呼ぶ。本明細書では、特定
の文書属性を分離し、それらをオフィス文書を記憶する
ための構造に符号化するシステムを説明する。

この構造は、通常のオフィス環境でのユーザの照会己と
って重要な項目のみを識別するデータ・ベースを構築す
るのに適している。

手法 パラメータ・データを自動的に抽出するタスクは明確な
ように見えるものではあるが、文書様式はしばしば著者
の気まぐれによって決まり、語寅は自由であり、抽出す
べきフィールドの内容が未知なので、この問題は難しい
。ここで使用する本発明の手法は、構造、構文、および
意味論上の知識に対するコンピュータ言語学的方法にも
とづいている。ＰＩＦシステムに与えられたオフィス・
テキスト中の各英文を、構文解析アルゴリズム（パーサ
）、文章解釈手順、フレーム解釈プログラム、およびテ
キスト情報を標準様式に変換するマツピング・プログラ
ムを使って解釈する。

構造（文章）解析は、文章のモデルを使って、ビジネス
通信文の３つの識別可能な構成要素、すなわち、文書の
見出しと本文と結びにプログラミング環境の焦点を合わ
せるものである。一方、構文解析は、テキストを文法的
に解釈して単語の品詞と文の句構造を判定することに関
するものである。

構造情報および構文情報を使って、予想事項の骨格を設
定し、後続のフィールド本位の意味論的テキスト解析を
推進することができる。最後に、実際のデータ抽出は、
文書に出てくるデータを、出力構造中のデータ用に予約
されたスロットにマツプすることから成る。これが「デ
ータ仕上げ」手順であり、情報を使用する情報記憶検索
プログラムが要求するようにデータの様式を標準化する
。

旦ス至ノ上二土 自然言語の文を解析するため、コンピュータ・プログラ
ムは文中の単語および句を認識し、それらの構文構造を
表わすデータ構造を組み立て、それを組み合わせて文全
体に対応する構造にする。

句を認識し、構造作成手順を呼び出すアルゴリズムが構
文解析アルゴリズム（パーサ）である。そのような構文
解析アルゴリズムは、１９８６年１０月２９日に出願さ
れた、同時係属の米国特許出願第９２４６７０号に開示
されている。

構文解析アルゴリズムは、テキストを解析して品詞およ
び句構造を含む文の成分を認識する。このアルゴリズム
はリスト・ノード、ストリング・ノード、および属性ノ
ードから成る両方向リスト・データ構造を組み立てる。

リスト・ノードを使うと、データ構造を順方向および逆
方向に走査することができる。ストリング・ノードはリ
スト・ノードに付随するもので、テキスト内の各々の語
柔項目を表わし、属性ノードを指すポインタを含む。

属性ノードは属性名と値から成り、これを使って品詞、
句のネスティングのレベル、行の開始等を表わすことが
できる。ＰＩＦシステムはサービス・サブルーチンを介
して構文解析アルゴリズムの単語本位データ構造にアク
セスし、ストリング・ノードに対応する語柔項目を得、
またそれらに関連する属性を検索する。

章解釈モジュール パラメータ情報が分離できるかどうかは、文書内の文章
構造を正しく識別できるかどうかにかかっている。解析
のこの側面は文書の様式によって大きく左右される。シ
ステムが必要とする情報の大部分は、文書の見出しと結
びにある。したがって、特定の探索手順では、その労力
を文書のこれらの部分に集中している。

ＰＩＦシステムでは、見出しは挨拶文の前の文書の最上
部を意味する。・見出しは通常、文中に動詞を含まない
（主題または参照の記述を除く）。

ビジネス文書の見出しは日付、発信者および受信者の名
前、住所、および主題の記述を含む。見出しは、またカ
ーボン・コピー（ｃ　ｃ）　情ＩＬ　−Ｌ　−ザＩＤ／
ノードＩＤ情報、および以前の通信に対する参照も含む
ことがある。

結びは著者の署名を含むビジネス文書の最下部であるが
、カーボン・コピー（ｃｃ）情報、ユーザＩＤ／ノード
ＩＤ情報、および発信者の住所を含むこともある。

文章構造解析の基本的目的は、情報の抽出を改善するた
めの位置上の手がかりを得て使用することである。これ
らの手がかりは、同一指向対象（実データ）がありそう
な文章内の位置を調べるようプログラムに指示するため
の知識を符号化したものである。したがって、文書の見
出しおよび結びを明確に認識することは、あいまいさを
なくすために非常に重要である。たとえば、日付情報は
見出しだけでな（文書の本文中にあることもあるが、見
出し部分からの日付のみが、文章解釈プログラムが文書
構造を識別した後に抽出される。

フレーム解釈モジュール 構文解析（パーサ）データ構造から抽出されたパラメー
タ情報は識別され、フレームの形の標準様式で記憶され
る。フレームとは特定の状況で満たさなければならない
一連の予想を与えるものである。本発明のビジネス通信
文データの解析の場合、フレーム手順で具体化される予
想は、見出しと本文と結びを備えた文章構造が存在する
だろうというものである。これらの各部分には、さらに
低位の予想がある。しかし、すべてのビジネス文書にこ
れらの要素がすべて含まれるわけではないので、これら
の予想が常に実現されるとは限らない。

フレームは、１組のスロットとそれらの内容によって表
わされる一塊の知識を定義する。概念を組織的に関連づ
ける働きをするのはまさにこれらのスロットである。Ｐ
ＩＥフレームは一定数のカテゴリと可変数のスロットを
有する。このフレームのカテゴリは、次の１０個のパラ
メータに対応している。すなわち、１）手紙の日付、２
）発信者の名前、３）受信者の名前、４）発信者の肩書
、５）発信者の住所、６）発信者のユーザＩＤ／ノード
ＩＤ、７）受信者のユーザＩＤ／ノードＩＤ１８）カー
ボン・コピー・リスト、９）主題の記述、および１０）
参照の記述である。フレームのスロットは、上記のそれ
ぞれのカテゴリに対応するが、各カテゴリについて１つ
または複数の事例が発生することが可能である。このこ
とは、不特定の数の受信者、またはカーボン・コピー名
が文書中に存在する可能性があるので、重要である。

アドレスや日付等のフィールドを分離するために様々な
形式のパターン認識が必要である。たとえば、人名の認
識機構は文脈（”Ｈ乙”、”Ｄｒ、’等の個人的肩書）
または構文構造（”ｔｏ　Ｊ、Ｄｏｓ”等の前置詞句）
に依存する。一方、日付は一層予測可能な様式を有し、
形式言語または構文ダイヤグラムで記述されるを限状態
手順の適用によって認識される。

マツピング・モジュール フレーム解釈モジュールは特定のスロットに対するデー
タを探索する際に文書の関連部分を走査するが、マツピ
ング手順はデータの様式を標準化し、それをフレームの
スロット中で編成する。たとえば、日付は手紙の本文中
でテキスト形式と数字形式の両方で出てくる。また、数
字による日付の表わし方には、アメリカ式とヨーロッパ
式がある。マツピング手順はこれらの日付をＹＹＭＭＤ
Ｄ形式に変換する。ただし、ＹＹは年、ＭＭは月、ＤＤ
は日である。固有名詞も走査して、Ｍｒ、、Ｄｒ。

等の肩書を取り去る。マツピング・モジュールは、予想
される対象に様式が対応することを確かめるために、抽
出すべきデータの形式構文記述を使って、１０個のカテ
ゴリに対するフレームのスロットを埋める。

マツピングで使用される構造情報は、フィールドの識別
中に使用される情報を補完する。形式構文記述により、
正しく認識されたデータのみが出力フレームのスロット
内に入れられるようになる。

要するに、構文記述は、選択されたデータの様式を標準
化するための「仕上げ」フィルタとして曇く。テキスト
の形式記述を作成するには、正確かつ広範囲の記述を作
成するために相当量のテキストを解析することが必要で
ある。

１翌 自然言語理解システムを構築する際、プログラムは種々
の程度の言語学的知識を必要とする。したがって、下す
べき第１の主要な決定の１つは、必要な言語学的および
概念上の知識をどのように表現し、編成するかである。

ビジネス通信文テキストからパラメータ情報を抽出する
プログラムは、少なくとも、パラメータ情報を識別する
ためにテキスト中でどれだけ多くの情報が必要かを決定
し、その情報をデータ・ベース中で意味を変えずに適当
な表現に変換できる程度に、資料を「理解」しなければ
ならない。

通常のオフィス環境でユーザの照会に関連する項目だけ
を識別するために、ＰＩＥシステムは多数の異なる文書
属性を分離し、それらの属性を、データ・ベースを構築
するのに適した様式または構造に符号化しなければなら
ない。生成された構造は文書からのすべてのパラメータ
情報を含まなければならない。

ここで、主題に関して少し見通しを示すため、自然言語
の幾つかの側面について簡単に考察する。

専門情報抽出（Ｓ　Ｉ　Ｅ）システムは、テキストから
パラメータ情報を取り出して、データ・ベースに入れる
。ＳＩＥタスクとは、限定された主題を扱い、限られた
数の独立パラメータにもとづいて分類できる情報を必要
とし、専門化された形式の言語を扱うタスクを意味する
ものとする。ここで選択したＳＩＥの特定の事例は高度
に構造化されたビジネス通信文である。

処理される言語の幾つかの側面を「理解」しようという
プログラムは、どのような目的であれ、種々の量の言語
学的知識を必要とする。必要とされる言語学の専門知識
の程度は、アプリケーションによって変わってくる。た
とえば、ワード処理用のプログラムでは言語学的知識は
ほとんど必要でないが、単語索引を作成するためのプロ
グラムは少なくとも単語の定義を知っている必要がある
。

自然言語理解システムを作成するための種々の水準の言
語学的知識には下記のものがある。

１、語棄の知識−その言語の単語とそれらの個々の構文
特性（それらの「品詞」、およびしばしば同時発生関係
および恐らくは語僧の分解を含めてより複雑な特性）お
よび意味。

２、型態論上の知識−特定の状況で単語がどのように形
を変えるか（たとえば、複数形または過去形がどのよう
に形成されるか）。

３、構文の知識−単語をどのように組み合わせると意味
のある文になるか。

４、意味論上の知識−文の形式がどのようにして特定の
意味を表現するか。

５、文章の知識−文をどのように組み合わせると文章に
なるか、すなわち、１つの文章中で文が、形式と内容（
構文と意味論）の両面で互いにどのように関連するか。

その言語の意味論の理解は、語気、構文および文章の知
識によっである程度左右される。語気の知識は個々の単
語の意味に関する情報を与えるが、その際に、その言語
での意味のあるそれぞれの文または文章について、これ
らの意味をどのように組み合わせれば文（または複数の
文から成る文章）が意味をなすかを表現する必要がある
。文の形を意味の何らかの表現にマツピングするタスク
は意味論マツピングと呼ばれる。もちろん、意味論マツ
ピングを行なう前に、何らかの意味表現を定義する必要
がある。

意味表現は、ある言語の意味を表現する手段をもたらす
ように設計された機械ベースのデータ表現である。コン
ピュータ言語学および人工知能の分野では、コンピュー
タ操作に適した様式で知識を表わすために「フレーム」
を使用している。フレームは、属性を概念エンティティ
に割り当てるのに必要な制御構造を単純化する働きをす
る。各属性をフレーム内の対応するスロットに入れるこ
とは、意味論マツピングのタスクである。

言語処理のすべての段階で、人間の聞き手または読み手
は言語学的知識および非言語学的知識を適用しており、
言語処理用のコンピュータ・システムも言語学的知識お
よび非言語学的知識を使用しなければならない。

１つのタイプの非言語学的知識の具体的な形は、通常状
々が論理（真／偽だけでなく、時間関係や確率論的推論
なども含む）と考えるものである。

言語を扱うときに常に使用されるもう１つのタイプの非
言語学的知識は経験的知識であり、この経験的知識は特
に言語学的でも論理的でもない世の中に関する事実から
成る。

このＰＩＦシステムでは、経験的知識は、テキストの主
題に関する我々の知識から引き出されたヒユーリスティ
ック（発見的手法）および仮定の形でプログラム中に存
在する。（所期のパラメータ情報を抽出するために使用
する）意味論的部分では、経験的知識は「フレーム」の
形で表わされる。「フレーム」が必ずしもその意味で常
に使用されるということではないが、以下の考察でこの
用語をその意味で使用する。フレームは、タスクに適用
される非言語学的「予想」を符号化したものである。

自然言語を扱う場合でも、人工言語を扱う場合でも、そ
の言語の標本に表現されている情報を抽出するには、そ
の言語の規則に従って文章の形を解析し、意味の分析に
進む。可能な文章の形を記述する規則を、その言語の構
文と呼ぶ。

ＰＩＦプログラムでは、限られた分野の文書中で有限の
数のパラメータを決定するだけでよい。

他の方法でこの問題を扱っても無駄なことが理論的考察
および経験かられかっているので、所期の情報をその言
語で表現する方法は無数にあると仮定してもよい。この
場合も、該当する問題分割および形式記述を使って、有
限の手段によりこれらの無限の可能性を扱うことが必要
である。

まず潜在的な入力資料でその特別な特性について詳細に
調べることにより、何らかの利益が得られる可能性があ
る。このことはこれらの特別な特性を使うと、言語が処
理し易くなることがある。

言語は、規則性を有することがあり、それを人工的言語
に組み込むと、処理がし易くなる。具体的な例を挙げる
と、受信者の名前の前には常に前置詞″ｔｏ”がつく。

したがって、”ｔｏ″が前に付いた人名を探せば、関連
するパラメータが抽出され、また文の構造の他の側面を
決定するのに役立つ情報が得られると期待できる。

専門的な言語資料の情報特性を得るために使用されるが
、その言語全体に対して言語学的に動機づけできない方
法は、「その場限りの方法」と呼ばれる。一般のコンピ
ュータによる方法の場合と同様に、「その場限りの方法
」はアルゴリズムによるものでもヒユーリスティツタな
ものでもよいが、たぶん後者である。すなわち、それら
の方法はおそらく経験則であり、常にではないがしばし
ば答を返す（ときには誤った答を返すこともあるが、そ
れが余り頻繁な場合は答をチェックする何らかの方法が
必要であり、さもないと、この方法は逆効果になる）。

答が返されない場合は、他のヒユーリスティックが適用
されるが、場合によっては、どれもうまくいかないこと
もある。

このプロジェクトで作成される体系の文法は、辞書、構
文、意味表現構造、および意味論マツピングから成る。

辞書はその言語の単語リストと各単語に対する１つまた
は複数の文法カテゴリから成る。構文はその言語の文の
構造を文法カテゴリとして規定する。形態論的手順は単
語の構造中の規則を認識し、それによって辞書の大きさ
を縮小させる。文章構造、または文外の構文も含まれる
。

ビジネス通信文のテキスト中の文の意味を理解するため
、本発明は、構文構造を解析し、各文をその文章の意図
の点から解釈し、参照項目のあいまいさをなくシ、各文
の単語をプログラムで使用する表現にマツプすることが
できる。

したがって、ビジネス通信文からパラメータ情報を抽出
する自動処理は、４つの主要タスクに分けることができ
る。すなわち、テキストの構文解析、テキストの構造解
析、テキストの意味論解析、および意味論マツピング手
順である。

文法の横築は、自然言語テキスト等相当な変化を示すテ
キストを処理するために行なわれねばならない基本的タ
スクの１つである。文法は、テキストを解析するために
作成されるコンピュータ・プログラムの基礎である。

言語の構文構造を利用して、コンピュータ・システムで
個々の文の構造を判定できるようにするには、まず文法
を形式化し、そこからあいまいさを取り除き、次に、構
文解析アルゴリズムを開発することが必要である。した
がって、このプロジェクトの構文解析タスクは、ビジネ
ス通信文書を構文解析の目的に十分な形で記述する文法
と、プログラムの形で実現された、ビジネス通信文から
パラメータ情報を抽出する構文解析アルゴリズムとの使
用に関するものであった。

自然言語の文を解析する場合、コンピュータ・プログラ
ムは文中の句を認識し、それらの各々についてデータ構
造を作成し、それらの構造を組み合わせて、文全体に対
応する構造にする。句を認識し、構造作成手順を呼び出
すアルゴリズムは、プログラムの形で実現された構文解
析アルゴリズムである。

別の方向に話を変えると、言語理解は文章の形で組み込
まれる。言語の理解には、言語をそれが組み込まれてい
る文章として解釈することが必要である。したがって、
どんな「理解」システムでもその意味論的解析には、状
況、対象および事象を理解するための知識を含め、さら
に、文章の形態に関する規則についての知識をも含めな
ければならない。

言語解析における意味論の役割は、記号を概念に関連づ
けることである。意味論マツピングは構文的に正しい各
文に、意味表現言語による意味表現を与えるもので、シ
ステム全体の要である。意味論マツピングが基本的に簡
単である場合は、構文処理をしばしば削減することがで
きる。このことはＳＩＥシステムの長所のひとつである
。主題が専門的であるため、「その場限りの」手順また
はテキスト解析から引き出したアルゴリズム手順を使っ
て構文処理をしばしば簡単にすることができる。

意味論的解析は、特定の対象または事象に対する参照を
認識すること、および普通の概念を特殊な概念に統合す
ることから成るものと考えることができる。言語理解が
単文の境界を超えたものであるときは、種々の言語学的
構造が認識される。

したがって、現在の理論によれば、文書パラメータ等の
普通の事象が記述されている場合、パラメータ記述を理
解するには、現在の記述と文書パラメータの類型の記述
との間の類似点および相違点を認識することが必要であ
る。

専門的な自然言語テキストから情報を自動的に抽出する
という複雑な仕事には、入手できる言語学的知識または
「その場限りの」ヒユーリスティックの一方だけを適用
する場合よりも満足できる結果をもたらすために、言語
理論と（資料の専門的な性質に基づ＜）「その場限りの
」ヒユーリスティックとを組み合わせるという方法論の
枠内で、精巧な手法が必要である。

言語理解システムを設計する際に対処しなければならな
い問題の１つは、システム構成要素およびそれらの相互
作用をどのように設計するかである。それ故、実現すべ
きフレームを識別することが非常に重要な問題である。

パラメータ情報を抽出するために、まず考えることは、
上述の予想事項、すなわち、日付、発信者の名前、受信
者の名前、住所等を含むフレームを定義することである
と思われる。しかし、テキスト中で見つかったパラメー
タをどのように使ってフレームのスロットを埋めるかを
考えると、ビジネス通信文テキストの文章構造と、提示
される情報の意味論的内容を考慮することが必要となる
。ｒＰＩＥモデル」と呼ばれる構造は、文章構造を統合
するもので、２つの手順、すなわち、文章ＰＩＥモジュ
ールとＰＩＥフレームとを設計するための論理的基礎と
なる。

ＰＩＦシステムに提示されるオフィス通信テキストの各
英文は、構文解析アルゴリズム、文章解析手順、フレー
ム解釈プログラム、およびテキスト情報を標準様式に変
換するマツピング・プログラムを使って解釈される。第
１図にＰＩＦシステムのデータの流れを示す。

以下の各節で、この作業で使用した言語学的手法および
用語について説明する。

叉皇夏工 文章構造の解析の基本的目的は、情報の抽出を改善する
位置上の手がかりを得て、それを使用することである。

言い換えると、特定の単語が現われる文脈についての知
識があれば、あいまいさをなくすのに十分な程度にそれ
らの意味の範囲が狭められる。したがって、文章解析に
より、各文書の見出し、本文および結びを識別すること
により、専門的な情報の抽出タスクが洗練されたものに
なる。

文章とは、つながった任意の１つのテキスト、または複
数の文、あるいは複数の独立した文の断片である。文章
を解釈するには、指向項目についてそれらの文問および
文外のつながりのあいまいさをなくシ、文章中の各文の
意図を判定する必要がある。

ＰＩＦシステムでの文章解析の目的は、値および必要な
情報でフレームのスロットを正しく埋めることである。

ＰＩＦシステムは英語によるビジネス通信文を理解する
ように設計されているが、その構成はビジネス通信文デ
ータの文章構造を解釈するのにどんな方法を使うかによ
って決まる。

コンピュータ言語学の興味ある側面の１つは、テキスト
を理解するために実現する必要がある特定のタスクが互
いにからみ合っていて、純粋に階層的にシステムを設計
できないこ七である。たとえば、オフィス通信文からパ
ラメータ情報を抽出するタスクでは、ある文書中でモデ
ルの３つの構成要素、すなわち、見出し、本文、および
結びを識別したとき、最も効果的に働くことができる。

しかし、テキストの文を識別してこれらの３つのカテゴ
リに分類するには、３つの構成要素の各々の特性に関す
る詳細な知識を有するアルゴリズム手順が必要である。

ビジネス通信文の文章モデルの例を第２図に示す。ＰＩ
Ｅシステムの目的は文書の見出し部分または結び部分、
あるいはその両方からパラメータ情報を抽出することな
ので、見出しおよび結びを明確に認識することがあいま
いさをなくすために非常に重要である。ＰＩＦシステム
の文章モデルについては後述する。

ｌヱニ互土星 フレーム手順は、特定の状況で満たさなければならない
１組の予想をもたらす。ビジネス通信文データの解析の
場合、フレーム手順で具体化される予想は、見出しと本
文と結びを備えた文章が存在するだろうということであ
る。これらの部分の各々には、さらに低位の予想がある
。低位の予想とはたとえば次のようなものである。すな
わち、手紙の日付、発信者の名前、受信者の名前、発信
者の肩書、発信者の住所、その他のパラメータである。

すべてのビジネス文書にこれらのパラメータがすべて含
まれるわけではないので、これらの予想が常に実現され
るとは限らない。

フレームは、スロットとそれらの内容から成る１塊の知
識であると定義される。他の概念に対する連想リンクの
目的で曇くのは、まさにこれらのスロットである。ＰＩ
Ｅフレームは一定数のカテゴリと可変数のスロットを有
する。このフレームのカテゴリは、次の１０個のパラメ
ータに対応している。すなわち、１）手紙の日付、２）
発信者の名前、３）受信者の名前、４）発信者の肩書、
５）発信者の住所、６）発信者のユーザＩＤ／ノードＩ
Ｄ１７）受信者のユーザＩＤ／ノードＩＤ１８）カーボ
ン・コピー・リスト、９）主題の記述、および１０）参
照の記述である。フレームのスロットは、上記のそれぞ
れのカテゴリに対応するが、各カテゴリについて１つま
たは複数の事例が生じることが可能である。このことは
、不特定の数の受信者、またはカーボン・コピー名が文
書中に存在する可能性があるので、重要である。

マツピング手順 マツピング手順の機能は、記号を概念に関連づけること
である。ＰＩＦマツピング手順は、特定の属性をそれぞ
れ文書の様々な部分からＰＩＥフレーム・スロットを埋
めるために必要な対応する意味論エンティティに変換す
る。

フレーム解釈手順は特定のスロットに対するデータを探
索する際に文書の関連部分を走査するが、マツピング手
順はデータの様式を標準化し、それをフレームのスロッ
ト中で編成する。たとえば、日付は手紙の本文中で文字
形式と数字形式の両方で出てくる。また、数字による日
付の表わし方には、アメリカ式とヨーロッパ式がある。

マツピング手順はこれらの日付をＹＹＭＭＤＤ形式に変
換する。ただし、ＹＹは年、ＭＭは月、ＤＤは日である
。固有名も走査して、訃１、Ｄｒ、等の肩書を取り去る
。

ＰＩＥフレーム用のＰＩＦマツピング手順は１０個のカ
テゴリに対するスロットを埋める（第１表参照）。これ
らのカテゴリは構文判定基準を使って認識され、データ
構造中に記載される。文書中で複数の受信者を指定する
ことがあるので、ＰＩＥマツピング手順は文書の文章か
らそれを集め、標準様式に変換して、ＰＩＥフレーム・
スロットに入れる。

構文モジュールおよび構文解　アルゴリズムノ璽皿 文法の構文部分を構築することは明らかに、テキストが
言語学的に解析できるようにするために、特に意味が抽
出できるようにするために実施しなければならない基本
的タスクの１つである。コンピュータ言語学では、この
文法は、コンピュータ・プログラムがテキストの構造を
判定するための基礎となる。この処理を構文解析と呼ぶ
。

自然言語の文を解析する場合、コンピュータ・プログラ
ムは文中の句を認識し、それらの各々に対する構文構造
を表わすデータ構造を作成し、それらの構造を組み合わ
せて文全体に対応する構造にする。句を認識し、構造作
成手順を呼び出すアルゴリズムは、上記の「自然言語テ
キストの構文解析アルゴリズム（Ａ　Ｐａｒｓｅｒ　ｆ
ｏｒ　ＮａｔｕｒａｌＬａｎｇｕａｇｅ　Ｔｅｘｔ）　
Ｊと題するＡ、ザモラ（Ｚａｍｏｒａ）等の同時係属の
特許出願に開示されている構文解析アルゴリズムである
。

この構文解析アルゴリズムは決定論的、手続的構文解析
アルゴリズムであり、基本的にボトム・アップ処理およ
び複数パス走査機構を使用する。

このアルゴリズムは種々の文法解析手法を用いる。

各単語について可能なすべての品詞を含む大きな辞書を
使用すると、補充文法と呼ばれる新規な文法解析の実現
が可能になる。

この構文解析アルゴリズムは、テキストを解析して、品
詞と句構造を含む文の成分を識別する。

このアルゴリズムは、リスト・ノード、ストリング・ノ
ード、および属性ノードから成る両方向リスト・データ
構造を組み立てる。リスト・ノードは、データ構造を順
方向および逆方向に走査することができ、ストリング・
ノードに対するリンクを有する。ストリング・ノードは
テキスト内の各々の語垂項目を表わし、属性ノードを指
すポインタを含む。属性ノードは属性名と値から成り、
これを使って品詞、ネスティングのレベル、行の開始等
を示すことができる。

ＰＩＦシステムはサービス・サブルーチンを介して構文
解析アルゴリズムの単語本位データ構造にアクセスし、
ストリング・ノードに対応する語業項目を得、またそれ
らに関連する属性を検索する。

ＰＩＦシステムが構文解析データ構造から抽出する情報
は以下の通りである。単語自体、構文特性（その単語の
品詞を含む）、形態論的特性（句読点、数値データ、大
文字使用情報、略語等）、文区切り文字特性（これは各
文の終りのコロン、感嘆符、疑問符、セミコロン、およ
びピリオドを含む）、人名特性（人名を識別する）、お
よび文書様式化特性（改行、タブ操作、空白行等）。

前述のように、パラメータ情報が分離できるかどうかは
、文書中の文章構造を正しく識別できるかどうかにかか
っている。解析のこの側面は文書の様式によって大きく
左右され、行間隔や字下げ等の特徴が、テキストを見出
しと本文と結びに正しく分けるために非常に重要である
。文章解析では、テキストをどんな形で独立した行に配
置するかについて、通常、意味論的または視覚的な句読
法の動機づけがあるという事実を考慮しなければならな
い。

文章解釈は、文章のモデルを使ってビジネス通信文文章
構造の３つの識別可能な構成要素、すなわち、文書の見
出しと本文と結びにプログラミング環境の焦点を合わせ
るプログラムによって行なう。

ＰＩＥシステムでは、見出しは挨拶文の前の文書の最上
部を意味する。見出しは通常、文中に動詞を含まない（
主題または参照の記述を除く）。

ビジネス文書の見出しは日付、発信者および受信者の名
前、住所、および主題の記述を含む。見出しは、またカ
ーボン・コピー（ｃ　ｃ）　情報、ユーザＩＤ／ノード
ＩＤ情報、および参照の記述をも含むことがある。

結びは、動詞を含まない文書の最下部を意味する。ビジ
ネス文書の結びは著者の署名を含むが、カーボン・コピ
ー（ｃｃ）情報、ユーザＩＤ／ノードＩＤ、および発信
者の住所を含むこともある。

ビジネス文書の本文は文書の主題を含む。ビジネス通信
文書の一例を第２表に示す。

第２表は、日付、名前、住所、およびパラメータと見な
されることがあるその他の情報が文書の見出しまたは結
びに出現することがあることを示している。ＰＩＦシス
テムで文書の本文を調べて見出しと結びだけを識別する
のは、このためである。

ビジネス通信文書の文章モジュールには、例１ないし５
に示す異なる５つのタイプの文書構造が含まれる。これ
らのタイプは次の通りである。

見出し一本文一結び構造 見出し一本文構造 本文一結び構造 本文構造 数個の見出しと結びから成る構造 サンプリングした文書のうち８３％が見出し一本文一結
び構造を有していた。見出し一本文構造（結びなし）は
３％の文書で見られた。サンプリングした文書のうち別
の３％は本文−結び構造（見出しなし）を有していた。

文書の９％は本文のみ（見出しおよび結びなし）を存し
、サンプリングした文書の１％は数個の見出しと結び（
メモ構造中のメモ）を存していた。

種々の文書構造で、まず各文書の文章様式の識別が必要
であり、次にその構造に基づく文書の構成要素の分離が
必要である。

本発明の実施例では、動詞を探し出すことによってビジ
ネス通信文の類似文章構造を判定するブートストラップ
手順を使用した。これは、最小限のコンピュータ資源で
文章構造の３つの構成要素を識別する効果的な方法の基
礎となる。この仮定は、主題または参照の記述を除き、
文書の見出しも結びも文中に動詞を含まないという事実
に基づいている。

文書の見出しおよび結びの識別は文書中の個々の行（レ
コード）の認識に基づき、文全体の認識に基づくもので
はない。その理由は、ビジネス通俳文は非常にしばしば
不正確に書かれ（文の終りに文区切り文字を置かない）
、構文解析アルゴリズムはこれらの場合に文を正しく分
離することができないからである。

例　　１ 見出し一本文一結び文書構造 見出し Ｄａｔｅ：　　Ｊｕｎｅ　２９．、１９８５Ｎａｍｅ　
＆　Ｔｉｅ／Ｅｘｔ、　：　Ｃｈａｒｌｅｓ　Ｒ，Ｂａ
ｋｅｒ／３３３−５４６５’　　　　Ｔｉｔｌｅ／Ｄｅ
ｐｔ、　Ｎａｍｅ：　Ｍａｎａｇｅｒ／ＰＰＣＲｅｇｉ
ｏｎａｌＲｅｓｅａｒｃｈ　Ｄｉｖ。

Ｉｎｔｅｒｎａｌ　Ａｄｄｒｅｓｓ：　４ｇ−Ｎ−９９
／Ｃ１ａｒｋｓｔｏｗｎ、　ＮＹｏｒ　Ｕ、Ｓ、　Ｍａ
ｉｌ　Ａｄｄｒｅｓｓ：　９８７　Ｒｅ５ｅａｒｃｈ　
ＢｏｕｌｅｖａｒｄＳｕｂｊｅｃｔ：　Ｐｈａｓｉｎｇ
　Ｏｕｔ　ｏｆ　Ｎｏｎ−ＰＰＣυｏｒｋｓｃｏｐｅｓ
本文 Ｐｕｒｓｕａｎｔ　ｔｏ　ｏｕｒ　ｍｅｅｔｉｎｇ　ｏ
ｆ　Ｊｕｎｅ　２２．１９８５＋　Ｉａｍ　ｐｕｔｔｉ
ｎｇ　ｉｎ　ｐｌａｃｅ　ａ　ｐｌａｎ　ｔｏ　ｂｅ　
ｉｎ　ａｐｏｓｉｔｉｏｎ　ｔｏ　ｐｈａｓｅ　ｏｕｔ
　ａｌｌ　ｎｏｎ−ＰＰＣｐｒｏｄｕｃｔｒｅｌａｔｅ
ｄ　ａｎｄ　ａｄ　ｔｅｃｈ　ｗｏｒｋ　ｂｙ　ｙｅａ
ｒ　ｅｎｄ　１９８５゜Ｉ　ｍａｙ　１ｏｏｋ　ｔｏ　
ａｉｄ　ｆｒｏｍ　ｙｏｕ　ｏｎ　ｏｃｃａｓｉｏｎ　
ｔ。

ｈｅｌｐ　ｉｎ　ｆｏｃｕｓｉｎｇ　ａｔｔｅｎｔｉｏ
ｎ　ｏｆ　５ｐｅｃｉｆｉｃｐｒｏｄｕｃｔ　ｍａｎａ
ｇｅｒｓ　ｏｎ　ｔｈｅ　ｐｏｔｅｎｔｉａｌ　ｏｆ　
５ｕｃｈ　ａｎａｒｒａｎｇｅｍｅｎｔ。

結び Ｃ，Ｒ，Ｂａｋｅｒ ９ＬＯ９９ 例　　２ 見出し一本文文書構造 見出し Ｄａｔｅ：　　６　Ｓｅｐｔｅｍｂｅｒ　１９８２．１
７：０５：１３　ＣＥＴ　ＡＣＫＦｒｏｍ：　　Ｌｙｎ
ｎｅ　Ｊａｃｋｓｏｎ　９８９７８７６５　ａｔ　ＧＥ
ＲＨＡＨＭＰｈｏｎｅ：　　（０）９８７１０９０９−
７８６５ＢＡＡ　Ｓｔｕｔａｍｅｒｅ Ｄｅｐｔｍｔ　９９９９／９９９−００Ｐａｓｃａｌｓ
ｔｒ、　９００ Ｔｏ：　　　υＥｎｓｃｈ　　ＨＡＮＴＡＮ　ａｔ　Ｙ
ＭＴＢＮＴｃｃ：　　　Ｍａｎｖｏｙ　ＭＡＮＶＯＹ　
ａｔ　ＹＭＴＢＮＴＳｕｂｊｅｃｔ：　　Ｄａｎ　５ｃ
ｈｎｅｉｄｅｒ本文 Ｄａｎ　５ｃｈｎｅｉｄｅｒ　５ｐｒａｉｎｅｄ　ｈｉ
ｓ　ａｎｋｌｅ　ｏｎ　５ａｔｕｒｄａｙａｎｄ　ｎｏ
ｗ　ｈａｓ　ｈｉｓ　ｆｏｏｔ　ｐｕｔ　ｉｎ　ｐｌａ
ｓｔｅｒ、　Ａｓ　ｈｅｉｓ　ｓｏｍｅｗｈａｔ　ｉｍ
ｍｏｂｉｌｅ：　ｃｏｕｌｄ　ｙｏｕ　ｐｌｅａｓｅ　
ｍｅｅｔｈｉｍ　ａｔ　ｔｈｅ　Ａｉｒｐｏｒｔ、　Ｈ
ｅ　ｗｉｌｌ　ａｒｒｉｖｅ　ｏｎＷｅｄｎｅｓｄａｙ
、　８ｔｈ　ａｔ　１６．００　ｗｉｔｈ　５９３　（
Ｉ　ｃｏｕｌｄｎｏｔ　ｆｉｎｄ　ｏｕｔ　ｗｈａｔ　
１ｉｎｅ）　ｃｏｍｉｎｇ　ｆｒｏｍ　Ｎｅｗ　Ｙｏｒ
ｋａｎｄ　５ｕｐｐｏｓｅｄｌｙ　ｌａｎｄｉｎｇ　ｉ
ｎ　Ｗａｓｈｉｎｇｔｏｎ　Ｄｕｌｌｅｓ。

Ｙｏｕ　ｗｉｌｌ　ｅａｓｉｌｙ　ｄｅｔｅｃｔ　ｈｉ
ｍ　ｂｅｃａｕｓｅ　ｏｆ　ｔｈｅｒｉｇｈｔ　ｆｏｏ
ｔ。

例　　３ 本文−結び文書構造 本文 Ｄａｎ　５ｃｈｎｅｉｄｅｒ　５ｐｒａｉｎｅｄ　ｈｉ
ｓ　ａｎｋｌｅ　ｏｎ　５ａｔｕｒｄａｙａｎｄ　ｎｏ
ｗ　ｈａｓ　ｈｉｓ　ｆｏｏｔ　ｐｕｔ　ｆｎ　ｐｌａ
ｓｔｅｒ、　Ａｓ　ｈｅｉｓ　ｓｏｍｅｗｈａｔ　ｉｍ
ｍｏｂｉｌｅ：　ｃｏｕｌｄ　ｙｏｕ　ｐｌｅａｓｅ　
ｍｅｅｔｈｉｍ　ａｔ　ｔｈｅ　Ａｉｒｐｏｒｔ、　Ｈ
ｅ　ｗｉｌｌ　ａｒｒｉｖｅ　ｏｎｌＪｅｄｎｅｓｄａ
ｙ、　８ｔｈ　ａｔ　１６．００　ｗｉｔｈ　５９３　
（Ｉ　ｃｏｕｌｄｎｏｔ　ｆｉｎｄ　ｏｕｔ　ｗｈａｔ
　１ｉｎｅ）　ｃｏｍｉｎｇ　ｆｒｏｍ　Ｎｅｗ　Ｙｏ
ｒｋａｎｄ　５ｕｐｐｏｓｅｄｌｙ　ｌａｎｄｉｎｇ　
ｉｎυａｓｈｉｎｇｔｏｎ　Ｄｕｌｌｅｓ。

Ｙｏｕ　ｗｉｌｌ　ｅａｓｉｌｙ　ｄｅｔｅｃｔ　ｈｉ
ｍ　ｂｅｃａｕｓｅ　ｏｆ　ｔｈｅｒｉｇｈｔ　ｆｏｏ
ｔ。

結び Ｔｈａｎｋｓ、　Ｊｏｈｎ 例　　４ 本文文書構造 本文 ＭＵＬＴＩ　ＬＡＹＥＲＴＨＩＮ　ＴＲＡＨＳＰＡＲＥ
ＨＴ　ＯＶＥＲＬＡＹＤＥＶＥＬＯＰＭＥＮＴ　ＰＲＯ
ＰＯＳＡＬｏ　Ｃｏｎｄｕｃｔｉｖｅ　５ｕｒｆａｃｅ
ｓ　ｏｆ　ｔｒａｎｓｐａｒｅｎｃｉｅｓｒ６ｇｉ５ｊ
６ｒＩｇｙ　ｒ６ｓｏｌｕｔｉｏｎ　ｔｏｕｃｈ−Ｍａ
ｓｋ　ｄｅｐｏｓｉｔｉｏｎ　ｏｆ　ｃｏｎｄｕｃｔｏ
ｒｓ　ｏｎ　ｐｌａｓｔｉｃ−Ｌｅｓｓ　０ｐｔｉｃａ
ｌ　Ａｂｓｏｒｐｔｉｏｎ−Ｌｅｓｓ　Ｐａｒａｌｌａ
ｘ 例　　５ 数個の見出しと結びから成る文書構造 Ｃｈａｒｌｅｓ：　　Ｔｈ１ｓ　ｉｓ　ＳＬＮ　Ｔｒａ
ｎｓｌａｔｉｏｎ　Ｃ１ａｓｓ　Ｉｗａｓ　ｔａｌｋｉ
ｎｇ　ａｂｏｕｔ　ｙｅｓｔｅｒｄａｙ、　　Ｍａｙ　
Ｉ　ａｓｋｙｏｕｒ　ａｐｐｒｏｖａｌ　ａｎｄ　ｔｈ
ｅｎ　ｐｒｅｐａｒｅ　ａ　１ｅｔｔｅｒｆｏｒ　Ｒａ
ｎｄｏｌｐｈ’ｓ　ｓｉｇｎ−ｏｆｆ。

Ｔｈａｎｋｓ、　Ｊｏｈｎ Ｄａｔｅ：　　１１　Ｍａｙ　１９８４．１８：５３：
３０　ＳＥＴＦｒｏｍ：　　Ｊａｎｅ　Ｃａ５ｅｎ　０
７０３１−１７−６２６７　ＣＮＧ　ａｔ５ＧＶＮ３ ＰＤＷ ７８８７　Ｓｉｎｄｅｌｆｉｎ Ｓｃｈｗｅｎｓｓｔｒ　５８−６０ Ｔｏ：　　　Ｊａｍｅｓ　Ｊｏｎｅｓ　（３０２）　９
８７５５６５１１ＪＯＮＥ　ａｔＥＮＥ ｃｃ：　　　Ｒｏｇｅｒ　Ｂｒｏｗｎ　ＢＲＷ　ａｔ　
ＳＥＲＢＭＩＳｕｂｊｅｃｔ：　　ＧＯＳＳ　　ｐａｒ
ｔｉｃｉｐａｔｉｏｎ　　ｉｎ　　５ＬＮｔｒａｎｓｌ
ａｔｏｒ’ｓ　　ｃｌａｓｓ。

Ａ　ｃｌａｓｓ　　ｉｓ　５ｃｈｅｄｕｌｅｄ　ｆｏｒ
　Ｊｕｌｙ　８−９　ｔ。

ａｃｑｕａｉｎｔ　　ｔｈｅ　　ｔｒａｎｓｌａｔｏｒ
ｓ　ｏｆ　　ｔｈｅ　　ＥＳ／６５４　ＮＭＩａｎｄ　
ｄｏｃｕｍｅｎｔａｔｉｏｎ　　ｗｉｔｈ　　ｔｈｅ　
　ｐｒｏｄｕｃｔ　ａｎｄ　ｔ。

ｐｒｏｖｉｄｅ　　ｅｘｐｌａｎａｔｉｏｎ　　ａｎｄ
　　ｈｉｎｔｓ　　ｆｏｒ　　ｔｈｅ　　ｕｓｅ　　ｏ
ｆＥＳ／６５４　ａｓ　ａ　　ｔｒａｎｓｌａｔｉｎｇ
　ｔｏｏｌ、　　Ｔｈｅ　ｃｌａｓｓｗｉｌｌ　ｂｅ　
ｈｅｌｄ　　ｉｎ　Ｂｏｎｎ　ａｎｄ　ｗｅ　ａｒｅ　
ｂｅｇｉｎｎｉｎｇｔｈｅ　　ｐｌａｎｎｉｎｇ　　ｎ
ｏｗ。

Ｔｈａｎｋ　ｙｏｕ　　ｆｏｒ　ｙｏｕｒ　ｃｏｏｐｅ
ｒａｔｉｏｎ。

ａｎｅ ＰＩＦシステムで行なう仮定の１つは、文章構造の一部
として、文書の新しい各部分で改行することである。た
とえば、本文は決して見出しと同じ行で始まらず、結び
は必ず本文とは別の行にある。したがって、ＥＮＤ　　
ＤＯＣおよびＨＥＡＤＤＯＣは、新しい部分が開始する
レコード（すなわち、行）を識別する。構文解析アルゴ
リズムの１つの重要な機能は、文書内の各レコードの開
始列および空白行の数に対する情報を保持することであ
る。この機能は、他の明白な文章の手がかりが存在して
いない場合に、ＰＩＦシステムが構文解析アルゴリズム
から見出しの最後のレコードおよび結びの最初のレコー
ドを正しく識別するのに役立つ。

文章解析は、「フレーム」を使用してテキストから意味
を抽出するための基礎である。文章解析が基礎となるの
は、文章のタイプが正しく識別されなかった場合、誤っ
たフレーム・マツピング手順が適用され、結果は価値の
ないものになるためである。人々が思いがけない手がか
りによって誤りを犯すのとまったく同様に、テキストの
表面構造を調べて文章構造を分類しようとするコンピュ
ータ・プログラムは、予期しなかった状況で誤りを犯す
。

ＰＩＥプログラムはＰＬ／１プログラム言語で開発され
、モジュラ一方式で設計されている。主モジュールＭＡ
ＩＮＥＸＴは、第４図の流れ図に示すように、８つの外
部サブルーチンを調整する。

ＭＡＩＮＥＸＴはまず構文解析データ構造をその文書に
対する行本位データ構造にマツプする。このデータ構造
は構文解析データ構造を参照する。

ＭＡＩＮＴＥＸＴは次に、第５図および第６図の流れ図
にそれぞれ示すように、モジュールＥＮＤＤＯＣおよび
ＨＥＡＤＤＯＣを呼び出して文書の結びおよび見出しを
識別する。文書の結びから抽出する必要があるパラメー
タ情報は付属識別子（”Ａｐｐｅｎｄｉｘ″″Ａｔｔａ
ｃｈｍｅｎｔ″等）の前に置かれ、文書のこれらの部分
を識別すると後でそれらを無視できるので、見出しより
前に結びの識別を行なって、以後の処理を簡単にする。

第７図および第８図にそれぞれ示すように、各フレーム
・スロットに対するフィールドを含む行を識別するため
に、モジュールＨＥＡＤＩＮＧおよびＥＮＤＩＮＧが呼
び出される。ＨＥＡＤＩＮＧおよびＥＮＤＩＮＧによっ
て抽出された生データは一次的構造に入れられ、第９図
の流れ図に示すように、データは後でその一時的構造か
らＩ　５ＯＬＥＸＴマツピング手順により出力フレーム
に転送される。これらのモジュールの流れ図を第４図な
いし第９図に示す。

ビジネス通信の文書は異なる多くの様式を有する（例６
ａ−ｄ１７ａ−ａｓ　８ａ−ｃ１９および１０に示すメ
モ様式、メツセージ様式等）。文章構造の識別は、文書
の構文と、それらに含まれるフレーム・スロットの種類
によって左右される。

結び識別アルゴリズム（ＥＮＤ　　ＤＯＣ）は主として
文書の構文（品詞および文区切り文字）に依存する。文
書の結びの文脈は通常、フレーム・スロットの数のみが
変わる（署名だけのことも、また何か他の情報を含むこ
ともある）。文書の見出しはフレーム・スロットの数が
変わるだけでなく、標準の成文手順に依存するビジネス
通信文パラメータの標準様式表現上も様々である。

例６ａ タイプ１．メモ様式 メモ１　様式 Ｄａｔｅ：　　Ｎｏｖｅｍｂｅｒ　１３．１９８４Ｎａ
ｍｅ　＆　Ｔｉｅ／Ｅｘｔ、　　：　Ｃｈａｒｌｅｓ　
Ｒ，Ｂａｋｅｒ／６５４−２３１５Ｔｉｔｌｅ／Ｄｅｐ
ｔ、　Ｎａｍｅ　：　Ｍａｎａｇｅｒ／ＰＣＷ　Ｒｅｓ
ｅａｒｃｈＤｅｐａｒｔｍｅｎｔ Ｉｎｔｅｒｎａｌ　Ａｄｄｒｅｓｓ　：　５３−Ｎ−３
６／Ｃ１ａｒｋｓｔｏｗｎ、　ＭＹｏｒ　Ｕ、Ｓ、　Ｍ
ａｉｌ　Ａｄｄｒｅｓｓ　：　５３６　Ｐａｒｋｅｒ　
ＲｏａｄＳｕｂｊｅｃｔ：　　ＯｖｅｒｔｉｍｅＰｅｒ
　　ｍｙ　　ｅａｒｌｉｅｒ　　ｃｏｎｖｅｒｓａｔｉ
ｏｎｓ　　ｗｉｔｈ　　ＴｅｄＴｈｏｍｐｓｏｎ、Ｉ　
　ａｍ　ａｄｄｒｅｓｓｉｎｇ　　ｔｈｅ　　ｏｖｅｒ
ｔｉｍｅｐｒｏｂｌｅｍ　ｏｆ　Ｃａｒｏｌ　　Ｄａｌ
ｅｙ　ａｎｄ　Ｍａｒｇａｒｅｔ　Ａｍｏｓ。

Ｉｔ　　ｉｓ　　１ｉｋｅｌｙ　ａ　ｔｈｉｒｄ　５ｅ
ｃｒｅｔａｒｙ　ｗｉｌｌ　　ｂｅ　ｈｉｒｅｄ。

Ｃ，Ｒ，Ｂａｋｅｒ ｃｃ：　　　Ｓ、Ｎ、Ｍａｎｉｓ ＰＩＦ結果 ＤＡＴＥ： ＴＯ： Ｊｏｈｎ　Ｂｌａｃｋｓｍｉｔｈ ＦＲＯＭ： Ｃｈａｒｌｅｓ　Ｒ，Ｂａｋｅｒ ＣＣ： Ｓ、　　Ｎ、　　Ｍａｎｉｓ ＴＩＴＬＥ： Ｍａｎａｇｅｒ／　　ＰＣＷ　　Ｒｅ５ｅａｒｃｈ　　
ＤｅｐａｒｔｍｅｎｔＡＤＤＲＥＳＳ： ５３−Ｎ−３６／Ｃ１ａｒｋｓｔｏｗｎ、ＭＹ　　０８
７９７　５３６　　Ｐａｒｋｅｒ　　ＲｏａｄＳＵＢＪ
ＥＣＴ： Ｏｖｅｒｔｉｍｅ 例６ｂ メモ２　様式 １、標準ＶＮＥＴ様式 Ｄａｔｅ：　　６０ｃｔｏｂｅｒ　１９８３１５：３３
：１１　ＳＥＴＦｒｏｍ：　　Ｍｉｃｈａｅｌ　Ｓｍ１
ｔｈ　７０３４−３５−３６２４　Ｍｌ（Ｌ　ａｔＭＥ
ＶＭＩ ＰＰＰＤ　Ｄｏｎｄｅｌｎｅｒ＋　ＧｅｒｍａｎｙＰｒ
ｏｄｕｃｔ　ＭａｎａｇｅｍｅｎｔＢｌｄｇ、　９８６
２−８６．　Ｄｅｐｔ、　００７８Ｔｏ：　　　Ｊａｍ
ｅｓ　Ｎ、　Ｗａｙ　（３３５）９３１−３５２１　Ｇ
ｔｌＥＹＧ　ａｔＪＴＶＭＥ Ｃ，Ｒ，Ｂａｋｅｒ　ＧＧＩＩＥＹＵＩ　ａｔ　ＹＴＹ
ＶＭＥＴ、　Ｅ、　Ｇｒｅｅｎ　ＧＲＥＥＨＴＥ　ａｔ
　ＴＹＥＶＭＥＥｌａｉｎｅ　Ｍａｒｔｉｎ　３３１−
５２３−９２４−５２２１　ＥＬＩＮａｔ　ＹＫＥＶＭ
Ｅ Ｒｉｃｋ　Ｅａｇａｒｔｅ　ＥＡＧ　ａｔ　ＥＫＴＶＭ
Ｅｓｔ＋ｅ、ｒＥｃＴ：　　　ｐｐｐｏ　　Ｓａｍｆａ
ｒｉｅｎ　　１９８４　　ＴＥＲＭＬｉｎｇｕｉｓｔｉ
ｃ　　５ｕｐｐｏｒｔＲｅｆｅｒｅｎｃｅ：　　Ｙｏｕ
ｒ　　ｍｅｓｓａｇｅ　　ｔｏ　　Ｅａｇｅｒｔｅ／５
ｐｅｈｔｔ。

Ｓａｍｅ　　５ｕｂｊｅｃｔ、１２／３０／８３Ｅ、Ｍ
ａｒｔｉｎ’ｓ　　ｎｏｔｅ、１９８４　Ｇｅｒｍａｎ
Ｌａｎｇｕａｇｅ　　５ｕｐｐｏｒｔ、１２１０４／８
３Ｏｕｒ　　Ｐｌａｎｓ　　＆　Ｃｏｎｔｒｏｌ　　ｄ
ｅｐａｒｔｍｅｎｔ　　ｗｉｌｌ　　ｃｏｎｔａｃｔｙ
ｏｕｒ　　Ｆｉｎａｎｃｉａｌ　　ｄｅｐａｒｔｍｅｎ
ｔ　　ｔｏ　　ｃｌａｒｉｆｙ　　ｔｈｅ　　ＩＣＡｐ
ｒｏｃｅｄｕｒｅ。

Ｒｅｇａｒｄｓ。

Ｍｉｃｈａｅｌ　　Ｓｍ１ｔｈ Ｐｒｏｄ、Ｍｇｒ。

ＰＰＰＤ　　Ｎｅｗ　　ＢｒｉｔａｉｎＰＩＦ結果 ＤＡＴＥ： ＴＯ： Ｊａｍｅｓ　Ｎ、　Ｗａｙ＋　Ｃ，Ｒ，Ｂａｋｅｒ、　
Ｔ、　Ｅ、　Ｇｒｅｅｎ。

Ｅｌａｉｎｅ　Ｍａｒｔｉｎ、　Ｒｉｃｋ　Ｅａｇａｒ
ｔｅＴｏ　ＶＮＥＴ： ＧＨＥＹＧ　＠　）ＩＪＴＶＭＥ、　ＧＧＨＥＹＵＩ　
＠　ＹＴＹＶＭＥ、　ＧＲＥＥＮＴＥ　＠ＴＹＥＶＭＥ
、　ＥＬＩＮ　＠　ＹＫＥＶＭＥ　ＥＡＧ　＠　ＥＫＴ
ＶＭＥＲＯＩＣ Ｍｉｃｈａｅｌ　ＳＳｍ１ｔ ｈＦＲＯＶＮＥＴ： ＭＩＩＬ　＠　ＳＭＥＶＭＩ ＡＤＤＲＥＳＳ： ＰＰＰＤ　　Ｄｏｎｄｅｌｎｅｒ、Ｇｅｒｍａｎｙ　　
Ｐｒｏｄｕｃｔ　ＭａｎａｇｅｍｅｎｔＢｌｄｇ、９８
６２−８６．Ｄｅｐｔ、００７ＳＵＢＪＥＣ’ｒ： ＰＰＰＤ　　Ｓａｍｆａｒｉｅｎ　　１９８４　ＴＥＲ
Ｍ　　Ｌｉｎｇｕｉｓｔｉｃ　　５ｕｐｐｏｒｔＲＥＦ
ＥＲＥＮＣＥ： Ｙｏｕｒ　ｍｅｓｓａｇｅ　　ｔｏ　Ｅａｇａｒｔｅ／
５ｐｅｈｔｔ、Ｓａｍｅ　５ｕｂｊｅｃｔ。

１２／３０／８３　　Ｅ。

Ｍａｒｔｉｎ’ｓ　　ｎｏｔｅ　　１９８４　Ｇｅｒｍ
ａｎ　　Ｌａｎｇｕａｇｅ　　５ｕｐｐｏｒｔ＋例６ｃ ２、非標準メモ様式 ％式％ ： ： ３、ＩＴＰＳメモ様式 ＩＴＰＳ　ＭＳＧ　ＵＮＣＬＳ　ＰＰＤＣＨＯＣＣＭＳ
Ｇ　ＭＡＩＬＴｏ：　　ＰＰＰＤ　−ＷＩＮＴＥＲＳＦ
ｒｏｍ：　　ＧＥＥＳＥＣＩ（ＨＩＥＶＭＴ）　８４／
１２１０３１８：２０：２３ＩＴＰＳ：　　ＡＦＳＤ Ｉｎ　ｒｅｓｐｏｎｓｅ　ｔｏ　ｙｏｕｒ　ｔｅｌｅｘ
　ｏｆ　０ｃｔｏｂｅｒ　２１゜１９８３　ｉｔ　ｉｓ
　ｍｙ　ｕｎｄｅｒｓｔａｎｄｉｎｇ　ｔｈａｔ　Ｐｒ
ｏｄｕｃｔＡｓｓｕｒａｎｃｅ　ｉｓ　ｙｏｕｒ　ｒｅ
ｓｐｏｎｓｉｂｉｌｉｔｙ　ｂｏｔｈｆｕｎｄｉｎｇ　
ａｎｄ　ｎｅｇｏｔｉａｔｉｏｎ、　　Ｔｈｅ　ｌｏｎ
ｇｅｒ　ｙｏｕｄｅｌａｙ　ｔｈｅ　ｍｏｒｅ　ｉｍｐ
ｏｓｓｉｂｌｅ　ｉｔ　ｗｉｌｌ　ｂｅｃｏｍｅ　ｔ。

ｍｅｅｔ　ｃｏｍｍｉｔｔｅｄ　ｄａｔｅｓ　ｄｕｅ　
ｔｏ　Ａｓ５ｕｒａｎｃｅ　ｎｏｎｉｎｖｏｌｖｅｍｅ
ｎｔ。

Ｃｈａｒｌｅｓ　Ｒ，Ｂａｋｅｒ ｃｃ：　　Ｊ、Ｅｎｇｅｌｂａｒｇｅｒυ、Ｇｒｅｅｎ
ｖａｙ Ｗ、　Ｓ、旧１１ｅｒ Ｔ、Ａｒｍｓｔｒｏｎｇ ＤＡＴＥ： ＴＯＶＮＥＴ： ＰＰＰＤ　　＠　　ＷＩＮＴＥＲＳ ＦＲＯＭ　ＶＮＥＴ： ＧＥＥＳＥＣＩ　　＠　　ＩＩＩＥＶＭＴＣＣ： Ｊ、　Ｅｎｇｅｌｂｅｒｇｅｒ＋す、　Ｇｒｅｅｎｗａ
ｙ、　Ｗ、　Ｓ、旧１１ｅｒ。

Ｔ、Ａｒｍｓｔｒｏｎｇ 例７ａ タイプ２　メツセージ様式 メツセージ様式１ −Ｍ５Ｇ　ＤＴＩ（ＯＭＡＳ−ＡＳＩＪＥＭ　ＴＯ：　
　ＧＥＹ３４１−ＲＴＥＹＨＴ０９／１７／８４１４：
１３：４２ Ｓｕｂｊｅｃｔ：　　５ＥＢＯＳＴ Ｊｏａｎ＋ Ｔｗｏ　ｐｅｏｐｌｅ　ｈａｖｅ　ｄｒｏｐｐｅｄ　ｏ
ｕｔ　ｆｒｏｍ　ｔｈｅｇｒｏｕｐ　ｄｕｅ　ｔｏ　ｖ
ｉｓｉｔ　ｙｏｕ　ｏｎ　Ｔｕｅｓｄａｙ　Ｏｃｔ　２
５゜１Ｊａｌｔｅｒ　５ｐｅｎｃｅｒ、　ＵＭＲｅｐｒ
ｅｓｅｎｔａｔｉｖｅ。

Ｉｎｔｅｒｎａｔｉｏｎａｌ　５ａｌｅｓ、　ＴＥＣ６
５３Ｈａｍｉｌｔｏｎ　５ｔｒｅｅｔ。

Ｎｅｗａｒｄ、　　８−６４３−６３２１　ＤＴＨＯＭ
ＡＳ　ａｔ　ＡＳＩＪＥＭ　５ＥＢＯＳＴＰＩＦ結果 ＤＡＴＥ： ＴＯＶＮＥＴ： ＧＥＹ３４１　＠　ＲＴＥＹＨＴ ＦＲＯＭ： Ｗａｉｔｅｒ　Ｓｐｅｎｃｅｒ ＦＲＯＭ　Ｖ１４ＥＴ： ＤＴＨＯＭＡＳ　＠　ＡＳＷＥＭ ＳＵＢＪＥＣＴ： ＥＢＯＳＴ 例７ｂ メツセージ様式２ ％式％ 例７ｃ １１：３１” Ｔｏ：　　ＩＩＬＩＧＦｓ−ＳＮＡＴＩｔ４ＳＦＲＯＭ
：　　Ｗ、　　ｔｌ、　　Ｒｅｅｄ　８−３２１−５２
７６８７　５ｏｕｔｈ　　ＢｒｏａｄｗａｙＢｒｏｏｋ
ｌｙｎ、Ｈ，Ｙ、１０４４１ＳＵＢＪＥＣＴ：　　Ｓｍ
ａｒｔ　　ＣａｒｄｓＲＥ：　　’ゴｈｅ　Ｎｉ１ｓｏ
ｎ　Ｒｅｐｏｒｔ＋”　　ｌ５ｓｕｅ　３３３．　　Ｊ
ｕｎｅ１９８３、ｐａ、５．ｔｏｐ Ｔｈｅ　ｒｅｆｅｒｅｎｃｅｄ　ｐｕｂ　ｒｅｐｏｒｔ
ｓ　ｏｎ　ｔｈｅ　ｕｓｅ　ｂｙＲｅｘｒｏｔｈ　ｏｆ
　ｍｉｃｒｏｗａｖｅｓ、　　ｒａｔｈｅｒ　ｔｈａｎ
　ｍｅｔａｌｃｏｎｔａｃｔｓ、　　ｔｏ　ｃｏｍｍｕ
ｎｉｃａｔｅ　ｂｅｔｗｅｅｎ　ａ　ｓｍａｒｔｃａｒ
ｄ　　ａｎｄ　　ａ　　ｔｅｒｍｉｎａｌ。

Ｗｉｌｌｉａｍ ＰＩＦ結果 ＤＡＴＥ：　　８４０４２７ Ｔｏ　ＶＮＥＴ：　　ＩＩＵＧＦＳ　＠　ＳＮＡＴＩ１
４ＳＦＲＯＭ：　　Ｗ、　Ｉｆ、　ＲｅｅｄＦＲＯＭノ
ＮＥＴ：　　ＥＴＩＩＯＩ　＠　ＥＷＴＳＩＶＭＡＤＤ
ＲＥＳＳ：　　８７５ｏｕｔｈ　Ｂｒｏａｄｗａｙ　Ｂ
ｒｏｏｋｌｙｎ　Ｎ、Ｙ。

ＳＵＩ３ＪＥＣＴ：　　Ｓｍａｒｔ　ＣａｒｄｓＲＥＦ
ＥＲＥＮＣＥ：　　’ゴｈｅ　旧１ｓｏｎ　Ｒｅｐｏｒ
ｔ、”　　ｌ５ｓｕｅ　３３３＋Ｊｕｎｅ　１９８３．
　ｐａ、　５．　ｔｏｐ例８ａ タイプ３．一般的配布メモ様式 １、上司への要点報告様式 Ｃｏｒｐｏｒａｔｅ　ＨｅａｄｑｕａｒｔｅｒｓＡｕｇ
ｕｓｔ　７．１９７５ Ｍｅｍｏｒａｎｄｕｍ　ｔｏ　ＭａｎａｇｅｒｓＳｕｂ
ｊｅｃｔ　１９７５　Ｅｍｐｌｏｙｅｅ　Ｂｅｎｅｆｉ
ｔｓ　ＳｔａｔｅｍｅｎｔＴｈｅ　ＣＤＩ　５ｔｏｃｋ
ｈｏｌｄｅｒｓ　ｈａｖｅ　ａｐｐｒｏｖｅｄ　ｔｈｅ
ｐｒｏｐｏｓｅｄ　ｃｈａｎｇｅｓ　ｔｏ　ｔｈｅ　Ｃ
ＤＩ　Ｒｅｔｉｒｅｍｅｎｔ　Ｐｌａｎ。

Ｔｈｅ　１９７５　ｅｍｐｌｏｙｅｅ　ｂｅｎｅｆｉｔ
ｓ　ｓｔａｔｅｍｅｎｔｓ　ｗｉｌｌｂｅ　ｍａｉｌｅ
ｄ　ｔｏ　ｅｍｐｌｏｙｅｅｓ　ｖｅｒｙ　５ｈｏｒｔ
ｌｙ、　　Ｔｈｅｙｗｉｌｌ　ｒｅｆ！ｅＣｔ　ｅｓｔ
ｉｍａｔｅｄ　ｒｅｔｉｒｅｍｅｎｔ　ｉｎｃｏｍｅｂ
ａｓｅｄ　ｏｎ　ｔｈｅ　ｉｍｐｒｏｖｅｄ　Ｐｌａｎ
、　ａｓ　ｗｅｌｌ　ａｓｂｅｎｅｆｉｔｓ　ｕｎｄｅ
ｒ　ｔｈｅ　ｏｔｈｅｒ　ＣＤＩ　ｐｌａｎｓ。

Ｗ、　Ｔ、　Ｃｒａｎｆｏｒｄ ＤＡＴＥ：　　７５０８０７ ＴＯ：　　　Ｍａｎａｇｅｒｓ ＦＲＯＭ：　　Ｗ、Ｔ、ＣｒａｎｆｏｒｄＳＵＢＪＥＣ
Ｔ：　　　１９７５　　Ｅｍｐｌｏｙｅｅ　　Ｂｅｎｅ
ｆｉｔｓ　　Ｓｔａｔｅｍｅｎｔ例８ｂ ２．会長の手紙 Ｃｈａｉｒｍａｎ’ｓ　Ｌｅｔｔｅｒ ＴＩＩＩＮＫ−Ａｕｇｕｓｔ、　１９７３Ｆｅｌｌｏｗ
　ＣｏｌｌＣｏ１１ｅａ：ｌＪｅ　ｃａｎｎｏｔ　ｓａ
ｆｅｇｕａｒｄ　ｔｈｅ　ｅｓｓｅｎｔｉａｌｓ　ｏｆ
ｏｕｒ　ｂｕｓｉｎｅｓｋｓ　ｕｎｌｅｓｓ　ｅａｃｈ
　ｏｆ　ｕｓ　ｍａｋｅｓｓｅｃｕｒｉｔｙ　ｈｉｓ　
ｏｒ　ｈｅｒ　ｐｅｒｓｏｎａｌ　ｒｅｓｐｏｎｓｉｂ
ｉｌｉｔｙ。

Ｉ　ａｓｋ　ｙｏｕｒ　ｃｏｎｔｉｎｕｉｎｇ　ｕｎｄ
ｅｒｓｔａｎｄｉｎｇ、　ａｎｄｖｉｇｉｌ。

Ａｒｔ　Ｐａｌｍｅｒ ＰＩＦ結果 ＤＡＴＥ：　　７３０８００ ＴＯ：　　Ｆｅｌｌｏｗ　ＣｏｌｌｅａｇｕＣｏｌｌｅ
ａ：　　Ａｒｔ　Ｐａｌｍｅｒ 例８ｃ ３、専門団体の会員への手紙 Ｊｕｎｅ　２６．１９８５ ＴＯ：　　ＵＥＤ　Ｂｏａｒｄ　ＭｅｍｂｅｒｓＦＲＯ
Ｍ：　　Ｆ、　Ｒ，Ｒｈ１ｎｅｈａｒｔＤ３２／３８２ １１ｏｕｓｔｏｎ ＳＵＢＪＥＣＴ：　　ＪｕＩｙ　ＵＥＤ　Ｂｏａｒｄ　
ＭｅｅｔｉｎｇＴｈｅ　Ｊｕｌｙ　ＬＩＥＤ　Ａｒｃｈ
ｉｔｅｃｔｕｒｅ　Ｒｅｖｉｅｗ　ＢｏａｒｄＭｅｅｔ
ｉｎｇ　ｉｓ　ｂｅｉｎｇ　ｒｅｓｃｈｅｄｕｌｅｄ　
ｆｒｏｍ　Ｊｕｌｙ　２９゜１９８５、　ｔｏ　Ｊｕｌ
ｙ　３０．１９８５゜Ｆ、　Ｒ，Ｒｈ１ｎｅｈａｒｔ ｃｃ、　　Ｔ、　Ｇ、　Ｐｏｐｅ、　Ｄ３３／８４２．
　［ＩｏｕｓｔｏｎＤ、　Ｂ、　０１ｄｓ、　Ｄ４３／
３０４．　［１ｏｕｓｔｏｎＰＩＦ結果 ＤＡＴＥ：　　８５０６２６ Ｔｏ：　　ＵＥＤ　Ｂｏａｒｄ　ＭｅｍｂｅｒｓＦＲＯ
Ｍ：　　Ｆ、　Ｒ，Ｒｈ１ｎｅｈａｒｔＣＣ：　　Ｔ、
　Ｇ、　Ｐｏｐｅ、　Ｄ、　Ｂ、　０１ｄｓＡＤＤＲＥ
ＳＳ：　　Ｄ３２／３８２　ＨｏｕｓｔｏｎＳＩＩＢＪ
ＥＣＴ：　　Ｊｕｌｙ　ＵＥＤ　Ｂｏａｒｄ　Ｍｅｅｔ
ｉｎｇ例　　９ タイプ４．略式の手紙様式 Ｐｌｅａｓｅ　ｉｇｎｏｒｅ　ｔｈｅ　ｆｉｒｓｔ　ｃ
ｏｐｙ　ｏｆ　ｔｈｅ　ｖ−ｎｅｔｓｉｎｃｅ　Ｉ　ｍ
ａｄｅ　ｓｏｍｅ　ｃｏｒｒｅｃｔｉｏｎｓ　ａｆｔｅ
ｒ　Ｉ　ｆｉｒｓｔｓｅｎｔ　ｉｔ。

Ｔｈａｎｋ　ｙｏｕ。

Ｂｅｖｅｒｌｙ ＰＩＥ結果 ＴＯ：　　Ｂａｒｂ ＦＲＯＭ：　　Ｂｅｖｅｒｌｙ 例１０ タイプ５．その他のビジネス文書 １、　　Ｗｈｅｎ　ｌｅａｖｉｎｇ　Ｎａｔｉｏｎａｌ
　Ａｉｒｐｏｒｔ、　ｆｏｌｌｏｗｓｉｇｎｓ　ｆａｒ
　ｌ−３９５Ｎｏｒｔｈ、　　Ｔｈ１ｓ　ｗｉｌｌ　ｐ
ｕｔｙｏｕ　ｏｎ　ａ　ｈｉｇｈｗａｙ。

２．５ｔａｙ　ｏｎ　ｔｈｅ　ｈｉｇｈｗａｙ、　ｐａ
ｓｔ　ｔｈｅ　ｅｘｉｔ　ｆｏｒＩ−３９５Ｎｏｒｔｈ
。

３、　５ｔａｙ　ｏｎ　ｔｈｅ　ｈｉｇｈｗａｙ、　ｐ
ａｓｔ　ｔｈｅ　ｅｘｉｔ　ｆｏｒＩ−３９５５ｏｕｔ
ｈ。

４、　　Ｔｈｅ　ｈｉｇｈｗａｙ　ｗｉｌｌ　ｆｏｒｋ
、　　５ｔａｙ　ｔｏ　ｔｈｅｒｉｇｈｔ、　ｆｏｌｌ
ｏｗｉｎｇ　ｔｈｅ　ｓｉｇｎ　ｔｈａｔ　５ａｙｓ”
Ｐａｒｋｗａｙ　（Ｄｕｌｌｅｓ　Ａｉｒｐｏｒｔ）、
Ｔｈ１ｓ　ｗｉｌｌｐｕｔ　ｙｏｕ　ｏｎ　ｔｈｅ　Ｇ
ｅｏｒｇｅ　ＩＪａｓｈｉｎｇｔｏｎＰａｒｋｗａｙ。

５、　５ｔａｙ　ｏｎ　　ｔｈｅ　Ｐａｒｋｗａｙ　　
ｆｏｒ　　ａｂｏｕｔ　　１０　　ｍ１ｌｅｓ。

６、　　Ｔａｋｅ　　ｔｈｅ　　ｅｘｉｔ　　ｍａｒｋ
ｅｄ　　”ｔｏ　　Ｉ−４９５（Ｍａｒｌ−４９５（、
Ｔｈ１ｓ　ｗｉｌｌ　　ｐｕｔ　ｙｏｕ　ｏｎ　　ｌ−
４９５゜７、　５ｔａｙ　ｏｎ　　ｌ−４９５ｆｏｒ　
ａｂｏｕｔ　５　　ｍ１ｌｅｓ、　　Ｔｈｅｈｉｇｈｗ
ａｙ　ｗｉｌｌ　　ｆｏｒｋ、　　５ｔａｙ　ｔｏ　ｔ
ｈｅ　　１ｅｆｔ。

ｆｏｌｌｏｗｉｎｇ　５１ｇｎ５　ｆｏｒ　　ｌ−２７
０（Ｒｏｃｋｖｉｌｌｅ。

Ｆｒｅｄｅｒｉｃｋ）。

ＰＩＦ結果 ＮＯＰＡＲＡＭＥＴＲＩＣＩＮＦＯＲＭＡＴＩＯＮ　Ｉ
Ｓ　ＥＸＴＲΔＣＴＥＤ文書の結びの識別 ビジネス通信文のテキストは手紙形式と表形式の２つの
異なる文書様式に分けることができる。

手紙形式の文書の本文は通常、文法にかなった完全な文
から成る。手紙形式の文書様式を第２表に示す。５００
通の見本文書の８９％は手紙形式の様式である。

表形式の文書は通常、文法にかなった完全な文から成っ
ていないが、たとえば以下のように、表、予定表、人名
のリスト等を含む。

ＧＥＮＤＡ ９：３０　ａ、ｍ、　　０ＶＥＲＶＩＥ＆１−　　　Ｍ
ＩＳＳＩＯＮ −ＡＣＴＩＶＩＴＩＥＳ １０：００　ａ、ｍ、　　ＲＥＦＲＥＳＨＭＥＮＴ　Ｂ
ＲＥΔに１０：１５　ａ、ｍ、　　Ｇｒｏｕｐ　Ａ　Ｇ
ｒｏｕｐ　Ｂ　Ｇｒｏｕｐ　Ｃ１０＋４５　ａ、ｍ、　
　Ｇｒｏｕｐ　ＣＧｒｏｕｐ　Ａ　Ｇｒｏｕｐ　Ｂ１１
：１５　ａ、ｍ、　　Ｇｒｏｕｐ　Ｂ　Ｇｒｏｕｐ　Ｃ
Ｇｒｏｕｐ　Ａ１１：４５　　ａ、ｍ、　　　ＡＳＳＥ
ＭＢＬＥ　　ＡＮＤ　　ＴＲＡＮＳＰＯＲＴ　　ＴＯＲ
ＥＳＴΔ［ＩＲＡＮＴ １２：１５　ｐ’、ｍ、　　ＬＵＨＣＩＩこの形式の文
書は通常、動詞を含まない。５００通の見本文書の１１
％が表形式の様式である。

手紙および表形式の両方の情報を含む混合様式の文書も
ビジネス通信文テキストで存在することがある。文法に
かなった完全な文が表の前にある場合、ＰＩＥシステム
はこれを表形式の文書と見なす。文書の下部の表の後に
完全な文がある場合、その文書は手紙形式と見なされる
。

ＰＩＦシステムでの文書の結びの識別は、見出しを識別
するより前に、ＥＮＤ　　ＤＯＣ手順によって行なう（
第５図の流れ図参照）。

結びを識別するための手順は、これらの形式の文書様式
の間で相当界なる。手紙形式の結び識別手順は最後の動
詞と文書の下部の°“ｒｅｇａｒｄｓ“や”　５ｉｎｃ
ｅｒｅｌｙ　’“等の挨拶の結語を探し出す。上記の手
がかりの後にある、動詞を含まない文書の部分がＰＩＦ
システムによって文書の結びと見なされる。手紙形式の
文書でそのような手がかりが見つからず、最後の文が冠
詞または動詞のいずれかを含む場合は、この文書の文章
構造は結びを含まない。

表形式の文書を識別することは一層難しい。この様式で
は、署名が文書の結びを識別する唯一の手がかりとなる
ことがある。文書が人名のリストの形をとる場合、文書
の本文中の人名を署名から区別するための手順は非常に
複雑になる。

”Ａｔｔａｃｈｍｅｎｔ　”、”　Ａ　ｐ　ｐ　ｅ　ｎ
　ｄ　ｉ　ｘ　”等の結びの文章の手がかりが見つから
ない場合は、プログラムは文書の最後の動詞を探し、次
に、動詞を含む文の後の最初のピリオドを探す。結びは
通常、動詞を含まないという仮定が行なわれる。異なる
２つの形式の文書様式があるので、最初のタスクは文書
様式の形式を認識することである。文書が手紙形式の場
合、文書の最後の文が動詞とピリオドを含むなら、その
文書は結びを持たない。

ＥＮＤ　　ＤＯＣ手順 ＥＮＤ　　ＤＯＣは、第５図に示すように、データ構造
を３回走査して文書の結びを識別する。最初の走査で、
プログラムは文書を前から後に走査して、追伸、付録、
添付等の文書の結びを識別する手がかりを探す。文書の
１回目の走査を文書の始めから行なう理由は、通常、付
録の方が文書の本文よりもはるかに長いからである。１
回目の走査で付録または他の添付が見つかった場合、添
付直前のレコードが、さらに処理を行なうべきその文書
の最後のレコードとなる。２回目の走査では、ＥＮＤ　
　ＤＯＣは文書の後から前に走査し、最後の動詞を探し
出すために構文解析機能がマークした区切り文字（ピリ
オド、感嘆符等）を探す。動詞によって一般に本文の最
後の文が識別される（手紙形式の文書様式）。３回目の
走査（同様に前から後）は、前の２回の走査で結びが識
別されなかったときだけ行なう。そうするのは、主とし
て文書の本文が表、電話番号付きの名前のリスト、また
は他の普通でない状況から成るとき（表形式の文書様式
）である。３回の走査がすべて失敗した場合は、その文
書は結びを持たない。

ＥＮＤ　　ＤＯＣ手順は構文解析データ構造を走査し、
文書の各行に対する様式化情報を参照するための行本位
データ構造を作成する。ＥＮＤ　　ＤＯＣは、文書が追
伸、添付、付録または予定表情報を含むかどうか識別す
るため、単語およびその特性（構文情報、文区切り文字
、句読点情報、および固有名詞情報等）を調べる。これ
らの識別子の１つが見つかった場合、この情報の直前の
レコードを文書の最後のレコードと見なし、文書の残り
を無視する。文書の最後のレコードが定義されると、Ｅ
ＮＤ　　ＤＯＣ手順は文書様式を識別し、次に手紙形式
および表形式文書をそれぞれ後から前に解析して結びを
探し出す。

ＥＮＤ　　ＤＯＣ手順は、文書様式を識別するため、文
の区切り文字が見つかるまで、構文解析データ構造を終
りから前に走査する。文の区切り文字が文書に見つから
なかった場合、プログラムは手紙形式の文書様式ではな
いと判断する。すなわち、その文書に結びがないか、ま
たはその文書が表形式（結びを含むことも、含まないこ
ともある）であるという意味である。結びが識別されな
かった場合、ＥＮＤ　　ＤＯＣ手順は、この文書の文章
構造は結びを含まないと判断する。手順が失敗して表の
文書様式の結びが見つからなかった場合は、この文書の
結びからの情報は失われる。表形式の文書は通常は結び
に署名しか含まないので、このことによって問題が起こ
ることはなく、見出しが認識された場合は、署名は冗長
なパラメータである。署名は発信者の名前を識別するた
めに重要である。署名が役立つのは、文書の見出しが見
つからず、署名が発信者の名前の唯一の依りどころとな
る場合だけである。大部分の場合、表形式の文書はその
文章構造に結びを含まない。

ＥＮＤ　　ＤＯＣは手紙形式の結びを識別するため、文
の区切り記号の後に“Ｒｅｇａｒａｄｓ　”、“５ｉｎ
ｃｅｒｅｌｙ“°等の結語表現があるかどうか検査する
。結びを識別するため使われる結語表現のリストを第３
表に示す。これらの表現の１つがレフード中で見つかっ
た場合、そのレコードが結びの最初のレコードになる。

結語表現が見つからなかった場合は、プログラムは、文
の区切り文字を何するレコードが動詞または冠詞を含む
かどうか検査を行なう。動詞または冠詞が見つかった場
合は、見つからなくなるまで、プログラムは走査を続行
する。動詞または冠詞を持たない最初のレコードが結び
の最初のレコードになる。

第２表に示すように、”Ｐｌｅａｓｅ　ｃｏｎｆｉｒｍ
　ｗｈｅｎａｒｒａｎｇｅｄ、“という文は文の区切り
文字と動詞の両方を含む。ＥＮＤ　　ＤＯＣ手順は次の
レコード“Ｊａｎ　Ｉ（ｏｌｅｎ“°を検査するが、こ
のレコードは文の区切り文字または動詞のいずれをも含
まず、かつ文の最後のレコードであるので、プログラム
はこのレコードを文書の結びの始まりとして識別する。

動詞が見つからなかった場合、プログラムは前の行を分
析して動詞または冠詞を探す。そのレコードが前のレコ
ードの続きであるために動詞を含まないことがあり得る
。たとえば、文書が以下の４つのレコードで終わること
がある。

Ｐｌｅａｓｅ　ｍａｋｅ　ａ　ｃａｒ　ｒｅｓｅｒｖａ
ｔｉｏｎ　ａｔ　ｔｈｅｌＪａｓｈｉｎｇｔｏｎ　ａｉ
ｒｐｏｒｔ　ａｎｄ　ｗｅ　ｗｉｌｌ　ｇｏ　ｂｙ　ｃ
ａｒ　ｔ。

Ｇａｉｔｈｅｒｂｕｒｇ。

Ｊａｎ　ｔｌｏｌｅｎ この場合は、最後のピリオドを有する行は動詞を含まな
い。ＥＮＤ　　ＤＯＣ手順は前の行を検査し、現在の行
が前の行の続きであることを認識する。前のすべてのレ
コードで動詞が見つからなかった場合、プログラムは、
この文書が手紙形式でないと判断し、呼出し手順に戻る
。

動詞が見つかうた場合は、前のレコード中で文の区切り
文字を検査し、それが見つかった場合は、結びを識別す
る。文の区切り文字が見つからなかった場合は、プログ
ラムは、現在のレコードが独立したレコードであるか、
それとも前のレコードの続きであるかを調べる（手紙の
筆者がレコードの終りに文の区切り文字をつけ忘れるこ
ともあり得る）。

署名情報を用いて手紙形式の様式が認識されなかった場
合、最後のステップで、プログラムは表形式の結びを識
別する。

書の見出しの識別 第６図に示す、文書の見出し識別用のＨＥＡＤＤＯＣの
アルゴリズムは文書の構文情報に依存しないので、結び
識別アルゴリズムとは異なる。見出し識別手順は手紙形
式および表形式の両方の文書様式を同じ方法で処理する
。ビジネス通信文書の見出しには種々の様式がある。見
出し識別アルゴリズムは５つの主要な見出し様式を認識
する（これらの様式を下記の例に示す）。

１、メモ様式（例６ａ−ｄ） ２、メツセージ様式Ｃ例７ａ−ｃ） ３、一般的配布メモ様式（例８ａ−ｃ）４、略式の手紙
様式（例９） ５、その他のビジネス文書（例１０） 社内便様式の例はメモ様式に準じる。その見出しには発
信者、受信者、日付、住所、主題、および参照に対する
標準スロット識別子が含まれている。メモ様式のもう１
つのカテゴリとして、システムを介して送られる略式の
メモがある。覚書、郵便等を含む通常のＶＮＥＴ電子メ
ール・メツセージは、見出し中の一貫した様式の識別子
と、受信者および発信者スロット中のユーザＩＤの存在
によって識別される。非標準的なメモには、標準的ＶＮ
ＥＴ様式が使用されないか、または発信者によって相当
変更された、すべてのオフィス間メモが含まれる。フレ
ーム・スコツＰａ別子の大部分は見出し中にあるが、そ
れらの構文は大幅に変わる。ＶＮＥＴはＶＭ／３７０用
（７）ＩＢＭ社の仮想計算機サブシステムであり、ＶＭ
／３７０システムと、ネットワーク・ジョブ・インター
フェース通信ネットワーク内で稼動するＩＢＭシステム
／３７０コンピュータとの間でのデータの送受信を管理
する。（ＩＢＭの刊行物ｒＶＭ／３７０ネットワーキン
グ−プログラムおよび操作解説書（Ｖ１４／３７０　Ｎ
ｅｔｗｏｒｋｉｎｇ−Ｐｒｏｇｒａｍ　Ｒｅｆｅｒｅｎ
ｃｅ　ａｎｄＯｐｅｒａｔｉｏｎｓ　Ｍａｎｕａｌ）　
ｊ参照）メツセージ見出し様式では、見出しの最初のレ
コードは通常、例７ａ−ｃに示すように様式化される。

メツセージレコード中の識別子の他に、見出しは発信者
、受信者、ときには主題、参照またはカーボン・コピー
に対する標準的な識別子も含むことがある。

一般的配布メモ・グループには、上司への要点報告、会
長の手紙、および専門団体の会員に配布するメモが含ま
れる。それらはすべて標準的様式であり、したがって、
容易に識別される。

略式の手紙の見出し様式の文書は、非公式なオフィス通
信文をまとめたものである。それらは通常は非常に簡単
であり、識別可能な見出しをもたない。受信者の最初の
名前が通常は文書の最初の単語となる。

その他のビジネス見出し様式には、原稿メモ、リスト、
契約、予定表、および図表等の１群の分類できない文書
が含まれる。

ＰＩＦ文章解釈モジュールで使用される文章の手がかり
はこれらのタイプの様式のそれぞれについて異なり、非
常に明確であり、見出しの識別に役立つ。

見出しの識別は、結びの識別後にＨＥＡＤＤＯＣ手順（
第６図の流れ図参照）によって行なわれる。大部分のビ
ジネス通信文書は、本文の冒頭に挨拶を含むが、あるい
は文書の見出し部分に発信者、受信者および主題識別子
を含む。それらが見つからない場合は、動詞を含む最初
の文が本文の始めを識別し、その直前の文が見出しの最
後となる。そうでない場合は、その文書は見出しを含ま
ない。

ＨＥＡＤＤＯＣ手順 ＨＥＡＤＤＯＣも、第６図に示すようにデータ構造を３
回走査することからなる。１回目と３回目の走査は、デ
ータ構造の始めからＥＮＤ　　Ｄ。

Ｃでマークされた文書の結びへと行なわれる。２回目の
走査は、ＥＮＤ　　ＤＯＣでマークされた文書の結びレ
コードから逆方向に行なわれる。１回目の走査では、”
Ｄｅａｒ”　その他の挨拶等の手がかりを探し出す。２
回目の走査では、”Ｔｏ”ご’　Ｆ　ｒ　ｏ　ｍ　”、
５ｕｂｊｅｃｔ”等の明白な見出し語を探し出すため、
句読点の手がかりを探す。３回目の走査は句読点の手が
かりが見つからなかったときだけ行ない、特徴的な句読
点または動詞を含まない見出し語を探し出すことからな
る。３回の走査がすべて失敗した場合は、見出しは識別
されない。

ＨＥＡＤＤＯＣ手順は、各見出し行ごとに構文解析デー
タ構造を走査して単語とその特性を分離する。次に、Ｈ
ＥＡＤＤＯＣ手順は挨拶の見出し識別子を探索する。見
出しの識別に使われる挨拶には、下記のようなものがあ
る。

ＥＡＲ ＭＲ，ＭＲ８，ＭＳ、ＤＲ。

Ｉ ＥＬＬＯ これらの挨拶の一つが見つかった場合、プログラムは挨
拶レコードの直前のレコードを見出しの最後のレコード
として設定する。たとえば、下記の手紙は、”Ｄｅａｒ
　Ｃｈａｒｌｅｓ”　という挨拶句を含んでいる。

Ｄａｔｅ：　　　１４　　Ｍａｒｃｈ　　１９８５．０
８：４１：５４　　ＣＴＴＴｏ：　　　　　Ｃｈａｒｌ
ｅｓ　　Ｂａｋｅｒ　　Ｏｏ、１．２０２．４４５．６
６６７　　ＣＨ八へＴ８８　　ａｔ　　ＮＭＥＢＴＴ Ｆｒｏｍ：　　　Ｇ、　　Ｓｍ１ｔｈ Ｊ、　　Ｄｏｓ Ｄｅａｒ　　Ｃｈａｒｌｅｓ。

５ｏｒｒｙ　　ｔｏ　　ｃｏｍｅ　　ｂａｃｋ　　ｔｏ
　　ｙｏｕ　　ｓｏ　　１ａｔｅ、　　　Ｉ　　ｗａｎ
ｔｔｏ　　ｔｈａｎｋ　　ｙｏｕ　　ａｇａｉｎ　　ａ
ｎｄ　　ｙｏｕｒ　　ｐｅｏｐｌｅ　　ｆｏｒ　　ｙｏ
ｕｒｗａｒｍ　　ａｎｄ　　ｆｒｉｅｎｄｌｙ　　ｗｅ
ｌｃｏｍｅ。

υａｒｍ　　ｒｅｇａｒｄｓ Ｍｉｃｈａｅｌ この場合は、挨拶文の前のすべてのレコードがこの文書
の見出しに当たる。

挨拶表現が見つからなかった場合、ＨＥＡＤＤＯＣ手順
はゴ０°′、“ＦＲＯＭ°′等の見出し識別子およびそ
の文脈を使って見出しの様式を調べ、各様式について文
書の見出しの最後のレコードを識別する。このプログラ
ムで使用される見出し識別子の完全なリストを第４表に
示す。見出し識別子の後に、通常はコロンや矢印（”：
、°“°→°“）等の句読点がつく。プログラムは、Ｅ
ＮＤ　　ＤＯＣがマークした文書の終りから構文解析デ
ータ構造を走査して、文書の本文の前の最後のコロンま
たは矢印を探す。それらの句読点符号の１つが見つかっ
た場合、見出し識別子がその句読点の前にあるかどうか
検査する。上記の例では、手紙に°“Ｄｅａｒ　Ｃｈａ
ｒｌｅｓ“という挨拶が含まれない場合、”ＦＲＯＭ：
　Ｇ、　Ｓｍ１ｔｈ　”というレコードが本文の前の最
後のコロンを有するレコードと見なされる。しかし、こ
のレコードは次の行に続いているので、最後の見出しレ
コードではない。上記の例に示すように、字下げによっ
てデータが１つの行から次の行に暗黙裏に続くという明
確なやり方に留意されたい。

ＦＲＯＭ：　　Ｇ、　Ｓｍ１ｔｈ Ｊ、　Ｄｏｓ ＨＥＡＤＤＯＣ手順は、次の行が続くかどうか調べて、
最後の見出しレコードを探し出す。継続は、構文解析デ
ータ構造からの文書様式化情報（各行の始めの位置およ
び各レコードの後の空白行の数）を解析するこ七によっ
て判定する。プログラムは次にコロン・レコード（１つ
のレコードしか識別されなかった場合）または最後の継
続レコード（この事例ではＪ、　Ｄｏｅ）　　が見出し
の最後のレコードであると決定する。

句読点が見つからなかった場合、ＨＥＡＤＤＯＣ手順は
同じ見出し手がかりを探し、また構文解析アルゴリズム
の構文特性を使って見出し識別子の文脈をも調べる。Ｈ
ＥＡＤＤＯＣ手順は、見出し識別子を含むレコードが少
なくとも１つの動詞または冠詞をも含むかどうか検査す
る。動詞または冠詞が見つからなかった場合、あるいは
主題または参照の記述中で見つかった場合は、プログラ
ムは、句読点が後についた識別子に対する場合と同様に
して、文書の行が続くかどうか調べ、最後の見出しレコ
ードを決定する。

最後に、手紙が挨拶の結語または見出し識別子のいずれ
をも含まない場合は、プログラムは文書の始めを調べて
別の行にある日付を探す。日付が見つかり、次の行が動
詞を含む場合は、プログラムは、以下に示すように、日
付を含む行の後の見出しの終りをマークする。

Ｈｏｓｔ　ａｐｐｌｉｃａｔｉｏｎｓ　ｗｈｉｃｈ　ｃ
ａｌｌ　ＴＥＴＥＲＮ　ｗｉｌｌｗａｎｔ　ｔｈｅ　ｐ
ｏｓ　ｂｉｔｓ−−１ｅｔｔｅｒ　ｃｏｄｅｓ　ａｒｅ
　ｒｅａｌｌｙｏｎｌｙ　ｆｏｒ　ｅｘｔｅｒｎａｌ　
ｄｉｓｐｌａｙ、　　Ｌｅｔ’ｓ　ｔａｋｅ　ｉｔｏｕ
ｔ−−ｗｈａｔ　ｄｏ　ｙｏｕ　ｓａｙ？１ｋｅ Ｗｈｅｎ　ａ　５ｅｐａｒａｔｅ　ｄａｔｅ　１ｉｎｅ
　ｉｓ　ｎｏｔ　ｆｏｕｎｄ。

ｔｈｅ　ｐｒｏｃｅｄｕｒｅ　ａｎａｌｙｚｅｓ　ｔｈ
ｅ　ｄｏｃｕｍｅｎｔ　ｆｏｒ　ｔｈｅｍｅｓｓａｇｅ
　１ｉｎｅ、　ｃｒｅａｔｅｄ　ｂｙ　ａ　ｓｙｓｔｅ
ｍ、　ａｎｄ　ｉｆ　１ｔｉｓ　ｆｏｕｎｄ、　ｔｈｅ
　ｍｅｓｓａｇｅ　ｒｅｃｏｒｄ　ｂｅｃｏｍｅｓ　ｔ
ｈｅｏｎｌｙ　ｒｅｃｏｒｄ　ｉｎ　ｔｈｅ　ｄｏｃｕ
ｍｅｎｔ　ｈｅａｄｉｎｇ、　　Ｔｈｅｆｏｌｌｏｗｉ
ｎｇ　ｅｘａｍｐｌｅ　１ｌｌｕｓｔｒａｔｅｓ　ｔｈ
ｉｓ　ｔｙｐｅ　ｏｆ　ａｄｏｃｕｍｅｎｔ。

ＭＳＧ：００２０８１０８／８５−１７：１２：１４　
Ａ　ＴＯ：　　ＹＪＧＴＥ　ＧＣＥＧＡＩＦＲＯＭ：　
　ＲＧＥＷ）４Ｖ　　ＲＪＦＪａｎｉｃｅ、　　ｄｏｎ
’ｔ　ｗｏｒｒｙ　ａｂｏｕｔ　ｒｅｓｅｎｄｉｎｇ　
ａｎｙｌｅｔｔｅｒｓ、　　Ｐｅｒｈａｐｓ　ｙｏｕ　
ｃａｎ　ｋｅｅｐ　ｔｈｅｐｒｏｂｌｅｍ　　ｉｎ　　
ｍ１ｎｄ　ｆｏｒ　ｔｈｅ　ｎｅｘｔ　ｔｉｍｅ　ｙｏ
ｕｓｅｎｄ、　　Ｗｅ’ｒｅ　ｊｕｓｔ　　ｒｏｏｋｉ
ｅｓ　ｏｕｔ　ｈｅｒｅ　　１ｎｔｈｅ　ｐｌａｉｎｓ
、ａｎｄ　ｗｅ　　ｈａｖｅｎ’ｔ　ｍａｓｔｅｒｅｄ
　　ＶＭｙｅｔ、　　Ｓｏ　　ｂｅ　　ｐａｔｉｅｎｔ
、　　　Ｉｔ　　ｗａｓ　　ｎ１ｃｅ　　ｏｆｙｏｕ　
　ｔｏ　　ｒｅｐｌｙ。

Ｄａｖｅ　　Ｌｉｎｇｅｒｍａｎ　　ＲＧＥＷＭＶ　　
ａｔ　　ＲＪＦＤＥＰＴ　　４２１Ｊ１０５３−１ Ｒｏｃｈｅｓｔｅｒ、　　Ｍ８　８−３２１−５１６５
そうでない場合は、文書は見出しを持たない。

サンプリングした文書の４２％は挨拶文を含む。

文書の８９％はその見出し部分が識別子から成る。

サンプリングした文書の２％だけが見出し識別子を含ま
ない。残り９％の文書は見出しを持たない文書様式（本
文−結び文章構造）として扱われた。

ＰＩＥフレーム解釈モジュールおよびＰＩＥフレーム予
想 ＰＩＥフレーム解釈プログラムの目的はテキストの意味
を理解することである。しかし、テキストの意味につい
て解析できるようになる前に、テキストを構造的および
構文的に解析することが必要である。

ビジネス通信文データの文章構造の手作業による解析で
、特定の文章状況で指向項目が受は入れられるかどうか
を決定する規則が得られている。

これらの手がかりは、同一指向対象（実データ）が見つ
かりそうな文章中の位置を調べるようプログラムに指示
するための知識を符号化したものである。

一方、構文解析は、テキストを文法的に解釈して単語の
品詞および文の句構造を判定することに関するものであ
る。

構造情報および構文情報により、以後のフィールド本位
テキスト解析を推進するための予想の骨組を設定するこ
とができる。構文解析データ構造から抽出されたパラメ
ータ情報が識別され、フレームの形の標準様式で記憶さ
れる。フレーム・モジュールは、特定の状況で満たされ
なければならない一組の予想をもたらす。

ビジネス通信文書の文章モデルに対して我々が抱く予想
を、意味論的構成要素ならびに構文エンティティおよび
語垂エンティティに関して特徴づけることができる。Ｐ
ＩＥフレームのスロットを埋めるために使用するのは後
者である。文書の見出しおよび結びに対するＰＩＥ文章
モデルの予想を第５表および第６表に要約する。

次の例１１に、見出しの予想の幾つかを含む文書の児出
し部分を示す。

例１１ Ｄａｔｅ：　　　　２１　　Ｍａｒｃｈ　　１９８４．
１８：４７：４８　　ｃｅｔ　ＡＣＫＦｒｏｍ：　　　
　０ＳＢＯＲＮＥ　ＢＯＢ　３７８４３２５０　　ａｔ
　ＹＫＥＩＪＭＴＰｈｏｎｅ：　　００　３９　２　５
３６　２３１１ＥＪＫ　　９４２３ Ｓｑｕａｒｅ　　Ｒｅｇｉｎａ ８９３０　　Ｂｒｕｓｓｅｌｓ　　ＢｅｌｇｉｕｍＴｏ
：　　　　　　Ｏｒ、Ｍ、Ｒ，Ｄｏｌｅ　ＤＯＬＥ　ａ
ｔ　　ＹＪＥＭＭＴｃｃ：　　　　　　Ｍｒ、　　Ｒ，
Ｍｅｙｅｒｓ　ＲＭＥＹＥＲＳ　ａｔ　ＢＴＨＥＭＥＳ
ＩＯｒ、Ｊ、Ｂｒｏｗｎ　　ＴＩＩＥＭＥＳＳ　　ａｔ
　　）ＩＥＨＲＮＥＳＩＭｒ、Ｇ、Ｇｒｅｅｎ　　ＴＨ
ＧＥＪυＴ　ａｔ　　ＴＵＥＩＩＩＪＭＳＩＯｒ、Ｊ、
Ｐ、Ｊａｍｅｓｏｎ　　ＰＪＡＭＥＳＯＮ　　ａｔＥＩ
ＮＣＩ Ｄｒ、Ｇ、Ｂａｒｋｓｄａｌｅ　　ＯＯＴＩＩＥＭＳＯ
ａｔＥＨＴＭＩ 次の例１２に、結びの予想の幾つかを含む文書の結び部
分を示す。

例１２ Ｂｅｓｔ　　ｒｅｇａｒｃｌｓ。

Ｒｉｃｈａｒｄ　　Ｍｏｒｒｉｓ Ｍａｎａｇｅｒ　　ｏｆ　　Ｒｅ５ｅａｒｃｈ　　＆　
　Ｄｅｖｅｌｏｐｍｅｎｔ７８６　　Ｃａｂｉｎ　　Ｒ
ｏａｄ Ｎｅｗｐｏｒｔ、　　ＭＩ　　４８５７７　　Ｕ、Ｓ、
Ａ。

ＭＯＲＲＩＳ　　ａｔ　　ＫＥＹＢＭＴ　Ｔｉｅ　　１
ｉｎｅ　　（８７６−９８７６）Ｐｈｏｎｅ　　（３７
８）９８６−３５３３ｃｃ：　　　ＣＥＩＩＮ−ＴＩＩ
ＯＲＥＭＢＴＩＩＥＩＭ口Ｙ−ＮＥＩＴ）ＩＥＢ 文書内でパラメータ情報を探し出す処理では構造（様式
化）および文法に関する情報を使用する。

たとえば、文書の住所の識別に関する若干の細部につい
て考えてみる。最初のステップは、このフィールドの大
きな特徴となっているキー・ワード（文脈判定基Ｑ）を
探すことである。後にコロンのついた”ｔｏ”という単
語（”ｔｏ　：　”、”Ｔｏ：”、゛ゴＯ：　”　）は
特定の形式の文書で高い頻度で見られる。キー・ワード
は明確で識別し易いので、それらのキー・ワードが見つ
かると、そのような関連するフィールドを探し出すタス
クが大幅に簡単になる。しかし、そのような識別子の前
後のテキストは、依然として、マツピング手段で抽出す
るためにデータにタグを付ける前に、フィールドの構文
上の要件を満たす必要がある。文法構造を解析するには
、単語（品詞）および文構造の構文上の役割を調べる必
要がある。ビジネス通信文の見出しが完全な文でないと
いう言語学上の観察を適用して、動詞に付随しない前置
詞句を探し出す。そのような句について前置詞“ｔｏ“
または“ｆｒｏｍ“を含むかどうか調べて、幾つかの形
式の通信文の受信者および発信者をそれぞれ判定する。

特徴的なキー・ワードがない場合は、文法構造および様
式の手がかりに重点を置く。構文解析アルゴリズムのサ
ブルーチンＮＡＭＥＸは人名を識別するので（下記参照
）、手紙の見出し中の前置詞句または名前の位置を使っ
て、発信者の名前を識別する。

名前を探し出すために使う位置判定基準は、確立された
ビジネス文書作成規則に基づくものである。文書様式に
は多数のバリエーションがある（例６ａ−ｄ１７ａ−Ｃ
１８ａ−Ｃ，９および１０参照）。字下げには、様々な
やり方がある。また、ビジネス用レターヘッドを使用す
る場合は、発信者の名前と住所が見出しから省略される
ことがある。しかし、これらの規則は非常に確立されて
いるので、文脈情報の比較的簡単な調査で、ビジネス用
の手紙の発信者と受信者を探し出すことが可能である。

（第１表に示すような）異なる１０個のフィール）’の
ＰＩＥフレーム・スロットを識別するため、ＨＥＡＤＩ
ＮＧ手順およびＥＮＤ　ＩＮＧ手順で文脈判定基準を使
用する（第７図および第８図の流れ図参照）。

日付判定基準 手紙の日付は通常、文書の見出し中にある。日付フレー
ム・スロットに対する日付の識別をＨＥＡＤ　ＩＮＧ手
順で行なうのはこのためである。第５表および第６表に
示すように、手紙の日付は以下の形式のうちの１つで表
わされる。

ＤＡＴＥ： ＦＥＢＲＵＡＲＹ　２９．１９８４ ＦＥＢＲＩＪＡＲＹ　　１９８４ ２９　　ＪＵＮＥ　　１９８４ １５．０８．８４ ＨＥＡＤＩＮＧ手順はまずテキストを調べて文脈上の手
がかり“”Ｄａｔｅ：“を探す。それが見つからなかっ
た場合、ＨＥＡＤＩＮＧ手順は、ｎ８または日付の特徴
である特定の数字パターンあるいはその両方が出現する
かどうか文書の見出しを解析する。日付情報の位置は、
後での処理のため、マツピング・モジュールに送られる
。

受信者判定基準 受信者情報は通常、文書の見出し中のみにある。

下記の識別子が受信者識別子と見なされる。

Ｔｏ＝ ＴＯ： ＴＯ ＴＯＡＬＬ Ｍｅｍｏｒａｎｄｕｍ　ｔ。

ＮＡＭＥ→ ）４ｅｍｏ　ｔｏ： ＨＥＡＤ　ＩＮＧ手順は、受信者識別子を含む文書の行
を識別し、次に識別子の後のテキストを検査し、データ
の位置をｌ５ＯＬＥＸＴマツピング手順に送って、受信
者の人名を受信者フレーム・スロットにマツプして入れ
る。

発信者判定基準 ビジネス通信文書中の発信者情報は見出し中にあること
も結び中にあることもある。まず、ＨＥＡＤ　ＩＮＧ手
順は、下記の発信者識別子を探し出して発信者情報を識
別しようとする。

ＦＲＯＭ： Ｆｒｏｍ　： Ｆｒｏｍ Ｎａｒｎｅ　　＆　Ｔｉｅ　　Ｅｘｔ、：Ｍｅｓｓａｇ
ｅ　　ｆｒｏｍ： ｌ５ｓｕｅｄ　　ｌ）ｙ： 発信者フィールドに対する表現は受信者と同じ様式に従
う。ＨＥＡＤＩＮＧ手順は、発信者識別子を含む文書の
行を識別し、次に、識別子の後のテキストを検査し、こ
の情報をマツピング手順に送って、発信者の人名を発信
者フレーム・スロットに入れる。

ＨＥＡＤＩＮＧ手順で発信者情報が識別されなかった場
合、ＥＮＤＩＮＧ手順が文書の結び部分でこれらの識別
子を探し、発信者情報が見つからなかった場合は、署名
モジュールが署名を発信者フレーム・スロットに入れる
。

カーボン・コピー名判定基亭 カーボン・コピー（ＣＣ）情報は文書の見出し部分にあ
ることも結び部分にあることもある。ＨＥＡＤＩＮＧ手
順およびＥＮＤ　Ｉ　ＮＧ手順は画部分を調べて下記の
識別子を探し出す。

ＣＣ：、　　ｃｃ： ＣＣ，、ｃｃ ＣＣ，： ｗｉｔｈ　　ｃｃ Δｌｓｏ　　ｔ。

ａｌｓｏ　　ｔｏ： Ｃｏｐｙ　　ｔｏ＋ Ｃｏｐｙ　　ｔｏ： Ｆｏｒ　　ｉｎｆｏｒｍａｔｉｏｎ　　ｔｏ：Ｔｏ　　
ｂｅ　　ｆｏｒｗａｒｄｅｄ　　ｔｏ：これらの識別子
の後には通常、人名またはユーザＩＤ／ノードＩＤまた
はその両方がくる。ＣＣ固有名の様式は発信者および受
信者である。それらの識別子に基づいてそれを発信者ス
ロ・ット、受信者スロット、またはＣＣスロットに分割
すればよい。ＨＥＡＤＩＮＧ手順でＣＣ情報を見つけら
れなかった場合は、ＥＮＤＩＮＧ手順がＣＣ情報を探し
出そうとし、その情報を対応するマ・ソピング手順に送
る。

ユーザＩＤ／ノードＩＤ判定基準 ユーザＩＤ／ノードＩＤ情報はそれぞれ発信者、受信者
、またはＣＣ情報と見なすことができる。

ＰＩＦシステムでこの情報に対して別個のフレーム・ス
ロットを設けるのは、人名またはＶＮＥＴ情報のいずれ
かによってユーザ探索を簡単にするためである。電子メ
ール文書（例７ａ参照）が発信者および受信者の人名を
含まず、その代りにユーザＩＤ／ノードＩＤ情報だけを
含むことが非常によくある。文書がすべての発信者およ
び受信者情報（人名およびユーザＩＤ／ノードＩＤ）を
含む場合、人名は発信者および受信者スロットに入れら
れ、ユーザＩＤ／ノードＩＤ情報もその対応するフレー
ム・スロットに入れられる。ＶＮＥＴ識別子が発信者識
別子、受信者識別子またはｃｃ識別子と同じであるのは
、このためである。ときには、ＶＮＥＴデータが”ＶＮ
ＥＴ　Ａｄｄｒｅｓｓ：”や”ＮＥＴＷＯＲＫ　ａｄｄ
ｒｅｓｓ：”等の異なる識別子を有することもある。そ
れらの識別子が見つかった場合は、そのデータを含む行
がマツピング手順に送られる。

ユーザＩＤおよびノードＩＤは見出し中にあることも結
び中にあることもある。ＨＥＡＤＩＮＧ手順およびＥＮ
Ｄ　ＩＮＧ手順はユーザＩＤ／ノードＩＤ情報子を探し
出し、それらをＣＨＥＣＫ　ＩＤマツピング手順に送っ
て、データを対応するフレーム・スロットにマツプし入
れる。

豆ｊはＤＬ１卒 受信者および発信者のアドレスも文書のどちらの部分に
置かれることもある。住所識別子はあまり多くない。

Ｉｎｔｅｒｎａｌ　Ａｄｄｒｅｓｓｌｏｒ　ＵＳ　Ｍａ
ｉｌ　Ａｄｄｒｅｓｓ：Ａｄｄｒｅｓｓ： 後に住所識別子がついた住所情報の位置が住所マツピン
グ・ルーチンに送られる。住所識別子が見つからなかっ
た場合は、レコードの位置（通常は発信者、受信者情報
または署２の後）が認識され、マツピング・モジュール
に送られる。

肩書判定基準 肩書識別の手順は住所識別に非常に類似している。肩書
とは文書の題名ではなく人の職務または地位を表わす。

ビジネス通信文テキストでは肩書識別子が１つだけある
。

Ｔｉｔｌｅ／Ｄｅｐ、　Ｍａｕｖｅ　：肩書情報は通常
、文書の見出しに置かれるが、結びに置くこともある。

肩書の識別は、大抵は肩書識別子およびその位置に基づ
いて行なわれる。

肩書識別子が見つからなかった場合は、発信者、受信者
、または署名レコードの後の肩書位置が検査され、マツ
ピング手順に送られる。

主題判定基準 主題情報は、下記の主題識別子のうちの１つを有する主
題ステートメントを文書が含む場合にのみ、主題フレー
ム・スロットに対して抽出される。

５ｕｂｊｅｃｔ： ５ｕｂｊｅｃｔ→ ５ｕｂｊ　： ５ｕｂｊｅｃｔ 主題情報は文書の見出し中のみに置かれる。主題識別子
の１つが見つかったときだけ、ＨＥＡＤＩＮＧ手１１１
Ｎは主１１１Ｎム・スロットに対して主題情報を定義す
る。ＨＥＡＤＩＮＧ手順は後に主題識別子のついた主題
レコードを主題フレーム・スロットに対して記憶する。

参照判定基準 参照識別手順は主題識別に非常に類似している。

参照の識別は、文書の見出し中の下記の参照識別子の１
つの認識のみに基づいて行なわれる。

Ｒｅ： Ｒｅｆｅｒｅｎｃｅ＝ Ｒｅｆ、： Ｒｅｆｅｒｅｎｃｅ ＨＥＡＤ　ＩＮＧ手順は参照識別子の１つを探し、参照
レコードを参照フレーム・スロットに入れる。

すべての識別子は大文字で表わされることも小文字のこ
ともある。

人名識別　順（ＮＡＭＥＸ） ＮＡＭＥＸプログラムは自由なテキスト中で人名を識別
する。自然言語テキスト中での人名の自動識別は、オフ
ィス・システムで広く使われている。１つの非常に有用
な用途は、オフィス通信文から名前を抽出して文書の発
信者および受信者の索引項目を自動的に作成することで
ある。ＮＡＭＥＸは、このサポートを提供するコンピュ
ータ・プログラムである。

ＮＡＭＥＸの戦略は大文字の単語から開始し、区切り文
字または名前以外の単語が見つかるまで右方に走査する
ことである。名前または頭文字の可能性がある単語が位
置および形態論の点で解析され、単語特徴づけテーブル
に入れられる。このテーブルを単語の特徴、文脈、およ
び地理的項目と個人的肩書を含む専門辞書に基づいて系
統的に調べて、固宵名が見つかったかどうか判断する。

人名を見つけたとプログラムが判断したときは、その境
界がマークされ、制御権が呼出しプログラムに戻る。

単語　徴づけテーブル 人名を自動的に識別するために使用する最初の段階は、
テキストの属性を要約するテーブルの作成である。この
テーブルは単語特徴づけテーブルと呼ばれ、各単語の構
文、語第、形態論、文脈、および位置に関する情報を含
む。構文情報は品詞を示し、語柔情報は、その単語が辞
書で見つかったかどうか、およびそれが略語であるかど
うかを示す。形態論的情報には、単語の長さ、その単語
がすべて小文字か、頭文字が大文字か、それともすべて
大文字かを示す大文字使用様式、および、その単語に数
字、ハイフン、またはアポストロフィが含まれているか
どうかを示す情報が含まれる。

文脈情報は、各単語の後の区切り文字と次の２文字から
成る。さらに、大域的文脈スイッチが、名前の環境中に
大文字と小文字の混在する単語があるかどうかを示す。

位置情報は、１行のテキスト中の単語の位置（最初の単
語、最後の単語）、および単語間の間隔を示す。

単語特徴づけテーブルは、区切り文字または名前の一部
とはなり得ない単語が見つかるまで各テキストの単語を
走査することにより作成される。

文脈上の手がかりに基づいてテーブルに単語が追加され
る。たとえば、最初の単語の前に前置詞”ｔｏ”　、”
ｂｙ”　、”ｆｏｒ”、”ｆｒｏｍ”　、または’ｗｉ
ｔｈ”がつく場合、名前の可能性があるとプログラムに
警告するフラッグがセットされる。同様に、連続した句
読点文字、ピリオド以外の句読点、数字ストリング、小
文字の単語、略語、および限定詞、前置詞、接続詞、代
名詞、助動詞等の品詞を伴う単語に出会ったとき、プロ
グラムはテーブルの作成を中止して解析の次の段階に進
む。

単語特徴づけテーブルの作成中の若干の段階で、以前に
テーブルに追加された項目を除去することが必要になる
。たとえば、ｎ８　ｌｌ）ＩａｙＩＩ、”　Ｊ　ｕ　ｎ
　ｅ”、および°゛Δｐｒｉ１″は人の名前にもなり得
るので、その後に数字が見つかるまで除去できない。

特定の小文字の単語がしばしばスペイン人、ドイツ人お
よびオランダ人の名前に出てくるので、テーブルに組み
込まれる。これらの単語にはｄｅ″、”ｌａ”、”　ｖ
　ａ　ｎ　”、”Ｖａｎ”および’ｄｅｒ”がある。他
にもテーブルで許容される単語の種類を限定する判定基
準がある。すなわち、所有格（°Ｓ）でないアポストロ
フィを有する単語は少なくとも２つの大文字（たとえば
、Ｏ’Ｋｏｒｎ、　Ｄ’Ａｎｇｅｌｏ）　を含む必要が
ある。ハイフンを含む単語はハイフンの次に大文字がく
る必要があり、ハイフンでつないだ名前の各部分は４文
字以上でなければならない。これは、にせの項目（Ｘ−
ＲａｙｓＸＰｒｅ−ｎａｔａｌ　等）がテーブルに入ら
ないようにするためである。混在単語は３字以上大文字
を含むことはできない（たとえば、ＥｕｒｏｔｌＯＮＥ
、　ＶＮＥＴｅｄは拒絶されるが、ＭａｃＨｅｉｌ。

０°Ｈａｒａはよい）。

テーブル解析モ亘 単語特徴づけテーブルを作成する手順で多数の無効な名
前形式が除外されるが、主として形態論的な手がかりを
使用するため、滴定な結果を得るには十分でない。テー
ブル解析手順は、人名を認識するための強力なフィルタ
として語労および文脈判定基準を使用する。解析手順は
まず、名前に属する単語にタグを付け、次に、第２段階
で、名前の構成要素が意味をなすかどうか検討してから
、名前が見つかったと結論する。

第１段階では、１字の略語は名前の部類に入るものと仮
定する。その他の単語は厳密な要件を溝たさなければな
らない。単語がその後にピリオドがつき、個人の肩書の
略語（たとえば、Ｍ乙、Ｍｒｓ　、、Ｒｅｖ、）　であ
る場合は、警告が出される。そうでない場合は、その単
語は既知の略語、システムにとって未知の略語、または
文の最後の単語である。システムにとって既知の略語は
名前区切り文字であり、それに出会うと解析の第２段階
が始まる。

個人の肩書を識別すると、後続の単語に関する重要な手
がかりが得られる。このため、プログラムは、仕事上の
地位（Ｃｈｉｅｆ、　Ｍａｙｏｒ、　ＪｕｄｇｅｓＰｒ
ｏｆｅｓｓｏｒ）　、家族関係またはを識者の階級（Ｆ
ａｔｈｅｒＸＳｉｓｔｅｒＸＢｉｓｈｏｐ）　、爵位（
Ｓｉｒ。

Ｅｓｑｕｉｒｅ、Ｃｏｕｎｔｅｓｓ）　、軍人の階級（
ＣｏｌｏｎｅｌΔｄｍｉｒａｌ、Ｃｏｍｍａｎｄｅｒ）
　、または既婚未婚の別０４ｉｓｓ、　Ｍｒｓ、）を反
映する肩書を探す。”Ｄｅａｒ″という単語自体も、プ
ログラムは名前がすぐ後に現われる手がかりとして解釈
する。この形式の単語の多くは）Ｌｏｎｇｍａｎ　Ｄｉ
ｃｔｉｏｎａｒｙ　ｏｆ　ＣｏｎｔｅｍｐｏｒａｒｙＥ
ｎｇ　ｌ　ｉｓｈで、その単語が名前の前で使用される
ことを示す°“Ａ″コードつけられている。この辞書を
参考に使ったが、プログラムで使用する単語を選別して
、人名を識別しない単語を除外した。

また、その単語が名前の部類に入らないかどうか検査を
行なう。そのような単語は、処理を中止して第２段階を
開始させるので「ストッパ」と呼ぶ。この種の単語には
曜日（ＭｏｎｄａｙＸＴｕｅｓｄａｙ等）、前述の３つ
を除くｎ８．８文字以上を有し、”　ｌｌ１ｅ　ｎ　ｔ
　”　または°’ｔｉｏｎ”で終わるすべての名詞形、
団体（たとえばＮ　５ｃｈｏｏｌ、　Ｃｏｒｐｏｒａｔ
ｉｏｎｌＳｏｃｉｅｔｙｓＣｏｍｐａｎｙｓ　Ａｓ５ｏ
ｃｆａｔｉｏｎ、　ＤｉｓｔｒｉｃｔＸＮａｔｉｏｎａ
ｌ）または方向（たとえば、Ｎｏｒｔｈ、　Ｅａｓｔ、
　Ｂｏｕｌｅｖａｒｄ）を示す単語がある。人名とはな
り得ない地名も「ストッパ」である。すなわち、”Ｂｒ
ａｚｉｌ°゛、”Ｎｏｒｗａｙ”およびＡｌａｓｋａ”
は地理的なストッパ・リストに含まれるが、人名にちな
んでつけられた地理上の場所である°°Δｕｓｔｉｎ”
および１ｌｏｕｓｔｏｎ”等の名前はそのリストには含
まれない。基本的に形容詞である単語もストッパと見な
される（たとえば、Ｏｌｙｍｐｉｃ、　Ａｔ１ａｎｔｉ
ｃ）　。

単語がすべて大文字の場合は、（？！！報のように）、
テキスト全体が大文字であるか、またはその単語が頭文
字であることを意味することがあるので、厄介である。

そのような場合は、判断を行なうためにプログラムは個
人の肩書や句読点等の以前の手がかりに大きく依存する
が、その単語の文脈全体が小文字を含むかどうかさらに
検査が行われる。混在環境の中間ですべてが大文字であ
る単語は頭字語と見なされる。さらに、全部が大文字か
ら成る単語が長さ４文字以下の場合は、“Ｍｒ、”等が
前についていない限り、頭字語（たとえば、ＡＢＣ，Ｎ
ＡＴＯ）と見なされる。しかし、全部が大文字から成る
単語が、前に頭文字がついているか、あるいは行または
文の最後の単語である場合は、名前の一部として受は入
れられる。

ＮＡＭＥＸは、辞書と突き合わせた結果のタイプを検査
することにより、語気情報を使用する。

単語が辞書で見つからず、かつその単語が大文字で始ま
る場合は、名前であると想定されるが、誤った綴りであ
るか、または数少ない大文字で始まる単語である可能性
は残る。しかし、ピリオドで終わり、かつ４文字以下か
ら成る大文字で始まる単語が、名前の最初の単語きして
現われる場合、略語と見なされる。

辞書に大文字で登録されている項目と単語が一致した場
合は、その名前は固有名である。その単語が大文字で始
まり、しかも辞書に小文字で記憶されている単語と一致
する場合は、英語の単語でも固を名でもあり得る”Ｂ　
ｉ　ｌ　ｌ”、”Ｆｒａｎｋ”、”Ｇｒａｃｅ”、”Ｇ
ｒａｎｔ”、”　Ｓ　ｕ　ｅ　”等の特別な場合に該当
するかどうか調べなければならない。

これらの固存名は、英語の普通の単語でもあり得るので
、個人の肩書または句読点の手がかり（たとえば、Ｍｒ
、　ＢｒｏｗｎｌＤｒ、　Ｋ、　１Ｊｈｉｔｅ、　Ｆｒ
ｏｍ：　Ｊ。

Ｒｅｅｄ）　に基づいて分析する必要がある。これらの
手がかりがない場合は、その他のヒユーリスティック規
則を使用する。たとえば、前の単語が名前（頭文字でな
く）と見なされ、かつプログラムがその名前に対して３
つの単語を累積していない場合、その単語は名前と見な
される。文章様式規則も使用されるので、頭文字があり
、それらの頭文字が行の始めにある、またはタブが付い
ている場合は、それらの後にくる単語は名前である。上
記のような判定基準は、”Ｈａｒｏｌｄ　Ｗｈｉｔｅ”
　と’Ｕ、Ｓ。

Ｄｉｓｔｒｉｃｔ　Ａｔｔｏｒｎｅｙ”等の名前と名前
以外のものを区別する助けになる。幾つかの小文字の単
語が、前記のように特にスペイン人、オランダ人、およ
びドイツ人の名前で許容される。

ＮＡＭＥＸは単語特徴づけテーブルで２回目の走査を行
なって、テーブルでタグを付けられた単語が人名として
解釈できることを確かめる。たとえば、頭文字だけがマ
ークされていた場合（たとえば、Ｕ、Ｓ、Ｏ，）　、人
名は見つからなかったことになる。同様に、全部が大文
字から成る１つの単語は名前よりも頭字語である可能性
が大きい。名前に限らず文脈上の手がかりを求めてさら
に検査が行なわれる。たとえば、数字が人名の前にくる
ことはない（たとえば、４１　Ｓ、　Ｂｒｏａｄｗａｙ
、　２０１　ＰｅｒｒｙＰａｒｋｗａｙ）。また前置詞
”　ｉ　ｎ　”および’　ｏ　ｎ　”は、一般に無生物
エンティティを指す（たとえば、ＩｎＡｔ１ａｎｔａ、
　ｏｎ　Ｔｅ１ｅｎｅｔ）ので、人名の前では許容され
ない。名前が３つ以上の単語を含み、かつ最後の２つの
単語が辞書に小文字で載っている場合は、名前である見
込みは少ない（たとえば、Ｄａｔａｓｔｒｅａｍ　Ｉｎ
ｔｅｒｐｒｅｔｅｒ　Ｅｘｔｅｎｓｉｏｎｓ）　ｏ最後
に）名前がコンマで終わる場合は、地理的な場所を示す
州の略語が続くかどうか検査が行なわれる（たとえば）
Ｂｏｃａ　Ｒａｔｏｎ、　ＦＬ）。

ＰＩＥフレーム・スロット識別手順 文書の見出しと結びが識別されると、フレーム手順ＨＥ
ＡＤＩＮＧおよびＥＮＤ　Ｉ　ＮＧが適用される。これ
らの手順は、ＨＥＡＤＤＯＣおよびＥＮＤ　　ＤＯＣで
マークされた文書の見出しおよび結び中の各レコードを
解析して、マツピング手順で処理する必要がある特定の
フレーム・スロットに対するデータの位置を定義するた
め、大文字または小文字のいずれかによる構文、語垂、
および形態論上の予想を探す（第５表および第６表）。

ＨＥＡＤ　Ｉ　ＮＧ手順 第７図のＨＥＡＤＩＮＧ手順は、文書の主題、以前の通
信文に対する参照、住所、日付等、より多くの情報を処
理しなければならないので、第８図のＥＮＤ　Ｉ　ＮＧ
手順よりも複雑である。ＨＥＡＤＩＮＧ手順は、ＨＥＡ
ＤＤｏＣでマークされた文書の見出し中の各レコードを
走査し、単語および構文解析アルゴリズムで供給される
その特性を抽出して調べ、対応するフレーム・スロット
を埋めるために後でマツピング手順に送られるデータの
位置を認識する。たとえば、発信者情報を識別する場合
、プログラムは°’Ｆｒｏｍ：”　または’ＮＡＭＥ＆
　ＴＩＥ／ＥＸＴ、　：”等の単語の手がかりを探し、
次にテキストの環境（前置詞句、人名、動詞なし、冠詞
なし等）を調べて、データが発信者の要件に合致するか
どうか判定する。データが識別された後、プログラムは
、そのデータに回行の文書の行が属しているか検査する
。最終的には、ＨＥＡＤＩＮＧ手順はこの情報に対する
データの位置と行のカウントを記憶する。

ＥＮＤ　ＩＮＧ手順 ＥＮＤ　ＩＮＧ手順はＨＥＡＤＩＮＧ手順に類似してい
る。ＥＮＤ　Ｉ　ＮＧ手順は、手紙に署名した人の名前
、カーボン・コピー・リスト、日付、および結びで見ら
れることがあるその他の情報を探し出す。ＥＮＤ　ＩＮ
Ｇ手順は、必要な情報が文書の見出しからすでに抽出さ
れているかどうか検査することにより、労力の重複を避
けるようにする。

すでに抽出されている場合、プログラムはテキストを走
査せず、単に呼出しプログラムに戻る。

意味論マツピングはパラメータ・フィールド抽出処理の
第２段階である。意味論マツピングも構造および文法上
の情報を必要とするが、加えて、抽出されるデータの形
式的な構文記述を使って、その様式が前提条件に合致す
ることを確かめる。

意味論マツピングで使用される構造情報は、フィールド
の識別中に使用される情報を補足し、形式的構文記述は
、正しく認識されたデータのみが出力フレームのスロッ
トに入れられるようにする。構文記述は要するに、選択
されたデータの様式を標準化する「仕上げ」フィルタと
して働く。

テキストの形式記述を作成するには、正確かつ包括的な
記述を作成するために相当量のテキストを解析すること
が必要である。

テキストの意味論的表現（フレーム）へのマツピングは
、ｌ５ＯＬＥＸＴ手順が行なう（第９図の流れ図参照）
。マツピング手順はフィールドの識別には関係しない。

その機能はデータを認識することと、データを適当なス
ロットに入れることである。

ｌ５ＯＬＥＸＴマツピング手順は、対応するフレーム・
スロットに送られた各レコードを調べ、文書検索システ
ムが必要とする標準様式でデータをマツプする。

日付様式はＹＹＭＭＤＤの形を取る。ただし、ＹＹは年
、ＭＭは月、ＤＤは日である。

発信者、受信者、およびＣＣフレーム・スロットは人名
（または、コンマで区切られた幾つかの人名）だけを含
む。

ＶＮＥＴスロットはＵＳＥＲＩ　Ｄ＠Ｎ０ＤＥ　ＩＤの
形を取る。

文書検索システムに対するその他のパラメータ情報要件
を確立することができる。

ｌ５ＯＬＥＸＴ手順は、その構文および形態論的パター
ンを使ってスロット情報を認識し、統一性が得られるよ
うにデータを再構成し、文書検索システム用の標準に合
うように変換する。

データ・フィールドのマツピング 日付判定基桑記述および文書の日付は、月、日、コンマ
、年（ＦＥＢＲＵＡＲＹ　２９．１９８４）　、または
月、年（日はない）（ＦＥＢＲＵＡＲＹ　１９８４）　
、または日、月、年（２９ＪＵＮＥ　１９８４）　、ま
たはスラッシュかピリオドで分離されたその他の数（数
／数／数（Ｍ／Ｄ／Ｙ）−”７／３０／Ｆ３４、数／数
／数（Ｄ／Ｍ／Ｙ）−３０／７／８４、数／数／数（Ｙ
／Ｍ／Ｄ）−８５／１／３０、数、数、数（Ｄ、Ｍ。

Ｙ）−１５，０８，８４）で表わされることがある。第
３図の構文ダイヤグラムが、日付スロットを認識するた
めに適用される。

日付マツピング手順は、ＨＥＡＤＩＮＧ手順でマークさ
れたレコードについて、上記の構文表現に対応するパタ
ーンを含むかどうか調べる。コンマの後にスペースがな
い’Ｍａｙ　１７．１９８５”等のよく見られる幾つか
の異常な事例も処理される。日付が分離された後、日付
マツピング手順を使ってサブフィールドの内容が解釈さ
れ、日付が標準様式ＹＹＭＭＤＤ　（年、月、日）で生
成される。日付の標準化は、スラッシュで分離された数
字の日付にとって特に重要である。何故ならば、それら
の日付はヨーロッパ式（臼／月／年）で表わされること
もアメリカ式（月、日、年）で表わされることもあるか
らである。８４寸マツピング・モジュールは数値に基づ
いてこれらの様式を区別する。１２以下の数は日を表わ
すことも月を表わすこともあり、また１３以上で３１以
下の数は日を表わすことしかできない。３２以上の数は
年と見なされる。日も月も１２以下の場合、その日付は
アメリカ式であると仮定する。これらの規則で暗示され
る拘束条件を適用することにより、日付を標準様式にマ
ツプすることができる。たとえば、文書の日付がＦｅｂ
ｒｕａｒｙ　１９．１９８６である場合は、８６０２１
９に変換される。

鵬信者、６信者、およびＣＣフィールドのマツピング 受信者、発信者、およびＣＣに関する情報は文書中でい
ずれかの以下の様式で表わされることがある。

ＴＯ：　　　Ｄａｖｅ　ＧｌｉｃｋｍａｎＴｏ：　　　
ＧＢＧＳＥＣＩ−ＹＫＴＶＭＴ　ＲＯＳＥＮＢＡＵＭ　
ＷＡＬＴＥＲＴＯ：　　　Ｗ、Ｓ、ＲＯＳＥＮＢＡｔＪ
ＭＴｏ：　　　ＥＭＺ Ｔｏ：　　　Ｅｌｅｎａ ＴＯ：　　　Ｄｒ、　Ａｎｔｏｎｉｏ　Ｚａｍｏｒａ　
（３０１−９２１−６１３３ＺＡＭＯＲＡ　ａｔ　ＹＫ
ＴＶＭＴ） ＴＯ：　　　Ｍｒ、Ｗ、ＲｏｓｅｎｂａｕｍＴｏ：　　
　Ｄｒ’、　Ｋ、　Ｅｎｇｅｌｋｅ、　ｅｇｌ　ａｔ　
ｓｄｖｍＴｏ：　　　Ｍａｎａｇｅｒｓ ＴＯ：　　　Ｊｏｈｎ　Ｃａｍｅｒｏｎ　Ｒａｌｅｉｇ
ｈ、　ＮＣＦＲＯＭ：　　　１Ｊａｌｔｅｒ　　Ｓ、　
　ＲｏｓｅｎｂａｕｍＣＣ：　　　　ＫＷＢ　　−−Ｙ
ＫＴＶＭＴ　　Ｋｅｎ　　Ｂｏｒｇｅｎｄａｌｅｃｃ：
　　　　Ｇａ１ｌ　　１４．　　Δｄａｍｓ名前が大文
字を伴わないで現われることもある。

人名の記述は広範なデータ解析に基づいて行なわれた。

名前に対する構文パターンは次の通りである。１）名と
姓（Ｅｌｅｎａ　Ｚａｍｏｒａ　）　、２　）名のみ（
Ｅｌｅｎａ　）　、３’）姓のみ（Ｚａｍｏｒａ　）　
、４　）頭文字と姓（Ｅ、　Ｍ、　Ｚａｍｏｒａ）　、
５　）名、中間名の頭文字、姓（Ｅｌｅｎａ　Ｍ、　Ｚ
ａｍｏｒａ）　、および６）名、中間名、姓（Ｅｌｅｎ
ａ旧ｃｈｅｌｌｅ　Ｚａｍｏｒａ）　。

住所、発信者、およびｃｃ情報に対する手順は、対応す
る記録を走査して構文解析アルゴリズムで識別される固
有名を探しく上記のＮＡＭＥＸ構文解析アルゴリズムの
固有名の識別に関する説明を参照）、次に、構文記述、
様式および形態論上の判定基準を使って、固有名が人名
かどうか確認する。この情報は次に対応するフレーム・
スロットに入れられる。構文解析アルゴリズムで適用さ
れる判定基準と名前マツピング手順の間には多少の冗長
性があるが、後者は、様式化判定基準、形態論的特徴、
および一般的な性質をもっているために構文解析アルゴ
リズムが適用できないビジネス通信文の領域に特有な文
脈上のその他の手がかりを使用する。

発信者情報も受信者情報も、ビジネス用の手紙様式では
識別子によって明確に識別できないことがある。このタ
イプの様式の場合、この情報は文書中の人名の位置のみ
に基づいて抽出できる。通常、このタイプの文書中の発
信者および受信者の人名は見出しの１番左の隅に置かれ
る。文書に署名が含まれ、かつこれらの名前の１つが署
名と一致する場合は、その署名が発信者のフレーム・ス
ロットに入れられ、残りの名前は住所スロットに入れら
れる。人名が見つからなかった場合は、スロットは空に
なる。

ユーザＩＤ／ノードＩＤフィールドのマツピンユーザＩ
Ｄ／ノードＩＤ情報は発信者、受信者、およびＣＣデー
タと同じ識別子を有する。それらは発信者、受信者およ
びＣＣデータ中の人名と同じ行に置かれることも、また
異なる識別子を有する異なる行に置かれることもある（
上記の発信者、受信者およびＣＣの例参照）。ユーザＩ
Ｄ／ノードＩＤ情報の表現を下記の例に示す。

１１０Ｇｌｌυ−５ＴＡ１４ＩＰＳ ＧＢＧＳＥＣ５（ＹＫＴＶＭＴ） ＧＢＧＳＥＣＩ　ａｔ　ＹＫＴＶＭＴ Ｅ阿Ｚ ＹＫＴＶＭＴ　ＧＢＧＳＥＣＩ ＧＢＧＳＥＣＩ　ＹＫＴＶＭＴ ユーザＩＤ／ノードＩＤ情報に対してプログラムが使用
する構文パターンは以下の通りである。

１）ＩＤ１スラツシユ、ノードＩ　Ｄ　（ＨＵＧＨＷ−
−８ＴＡＭＩＰＳ）、２）ユーザＩＤ１左かっこ、ノー
ドＩＤ、右かっこ（ＧＢＧＦＳＥＣ５（ＹＫＴＶＭＴ）
）　、３）ユーザＩＤ１前置詞”　ａ　ｔ　”、ノード
ＩＤ　（ＧＢＧＳＥＣＩ　　ａｔ　　ＹＫＴＶＭＴ）　
、４）ユーザＩＤのみ（ＥＭＺ）　、５）ユーザＩＤ、
ノードＩＤ　（ＹＫＴＶＭＴ　　ＧＢＧＳＥＣｌ）、お
よび６）ノードＩＤ、ユーザＩＤ（ＧＢＧＳＥＣＩ　　
　ＹＫＴＶＭＴ）。

ユーザＩＤ／ノードＩＤマツピング手順は、構造、形態
論および構文上のパターンを使って、ＶＮＥＴ　　ＩＤ
のフレームに送られたレコードを調べる。ときには、ユ
ーザＩＤおよびノードＩＤ情報を区別することは非常に
難しいこともある。メツセージ様式レコード中で、この
情報は以下の形式のうちの１つで表わされることがある
。

ＭＳＧ：０００１　０５／１５／８４−１７：５７：０
８　　ＴＯ：　ＹＫＴＶ１４ＴＧ１３ＧＳＥＣＩ　Ｆｒ
ｏｍ：　　ＩＥＣＶＭ１１４ｓＧ：０００１　０５／１
５／８４−１７：５’７：０８　　ＴＯ：　ＧＢＧＳＥ
ＣＩＹＫＴＶＭＴ　　Ｆｒｏｍ：　　ＩＥＣＶＭＩマツ
ピング手順はどちらの場合でも’ｖｍ±°、ｈｏｎ　’
　１　　°ｙｋｔ’ｚ　　’ａｔｌ’）’ａＶｓ’）’
ｂｃｒ’ｔｊｂｅｔｌ、“ｂｌｄ′等のノードの形態論
的特徴を適用し、ＹＫＴＶＭＴをノードＩＤとして識別
する。

形態論的パターンが、サンプルの会社システム・ノード
の解析によって生成された。ノード情報の長さも制限さ
れる。３文字以下か、９文字以上になることができない
。ユーザＩＤおよびノードよりがそれぞれ認識された後
、ｌ５ＯＬＥＸＴ手順はそれらを標準様式（ＵＳＥＲＩ
Ｄ＠Ｎ０ＤＥＩＤ）に変換する（ユーザＩＤ情報を常に
始めに置く　）　。

１１Ｒ」ＬＬ己１里より、［ＦＪＥ、鉄ヱヱ：」」」引
乙ムピング 以下の例はビジネス通信文書中の住所、肩書、参照およ
び主題の表現を示したものである。

Ａｄｄｒｅｓｓ：　　１０−８−２／Ｇａｉｔｈｅｒｓ
ｂｕｒｇ、　Ｍｄ　２０８７７　２０１Ｐｅｒｒｙ　Ｐ
ａｒｋｗａｙ Ａｄｄｒｅｓｓ：　　３６０１１ａｍｉｌｔｏｎ　Ａｗ
ｅ、、　Ｗｈｉｔｅ　ＰｌａｉｎｓＡｄｄｒｅｓｓ：　
　Ｃｅｎｔｒｏ　５ｃｉｅｎｔｉｆｉｃｏ　ｄｉ　Ｐｉ
ｓａＶｉａ　５ａｎｔａ　Ｍａｒｉａ　６７Ｐｉｓａ＋
　Ｉｔａｌｉａ Ｔｉｔｌｅ：　　　　ＬＩＫ　　Ｒｅｐｒｅｓｅｎｔａ
ｔｉｖｅ、　　ＩｎｔｅｒｎａｔｉｏｎａｌＳａｌｅｓ
　　ＩＪＴｃ ７ｉｔｌｅ’　　　　　八ｐｐｌｉｃａｔｉｏｎｓ　　
Ｄｉｖｉｓｉｏｎ　　ＭａｎａｇｅｒＴｉｔｌｅ：　　
　　Ｍａｎａｇｅｒ　　ｏｆ　　Ｌｉｎｇｕｉｓｔｉｃ
　　ＤｅｖｅｌｏｐｍｅｎｔＳｕｂｊｅｃｔ：　　Ｄｉ
ｃｔｉｏｎａｒｙ　　ＰｒｏｂｌｅｍｓＲｅｆｅｒｅｎ
ｃｅｓニーＮｅｇｏｔｉａｔｉｏｎｓ　　ａｎｃｌ　　
ｔｅｎｔａｔｉｖｅａｇｒｅｅｍｅｎｔｓ／ａｔｔａｃ
ｈｍｅｎｔｓ−Ｙｏｕｒ　　ＶＮＥＴ−ａｎｓｗｅｒｓ
　　ｏｆ　　Ｍａｙ　　１１　　ａｎｄＭａｙ　　１４ 住所の構文記述には以下のようなものがある。

１）番地、街路名、都市名、州名、郵便番号。２）都市
名、州名、郵便番号、番地、街路名。３）会社名、街路
名、番地、国名、都市名。

住所識別子の１つを伴った住所情報が住所マツピング・
ルーチンで抽出されて住所フレーム・スロットに入れら
れる。住所識別子が見つからなかった場合は、住所構文
記述に基づいて住所ｆ′？Ｊ報の探索が行なわれる。

肩書のマツピングは住所のマツピングに類似している。

すなわち、肩書識別子が省略されているとき、肩書構文
パターンを使用する。主題および参照情報は、それらの
識別子をデータから除去して、対応するフレーム・スロ
ットに入れられる。

住所、肩書、参照、および主題フィールドに対しては標
準様式の要件はないので、この情報は、適当な識別子に
関連する行の特定部分を選択することにより、またはそ
れらの構文パターンに基づいて文書から抽出される。付
随的な句読点および後の区切り文字もこれらのフィール
ドから除去される。

文書検索システムの動作 本発明によるパラメータ情報抽出システムを使用した文
書検索の動作について以下に簡単に説明する。第１０図
は、文書識別情報をデータ・ベースに入力する際に必要
な動作全体の流れ図を示す。

文書を読み取り、文書識別番号を文書に割り当てなけれ
ばならない。次に、本発明に基づくパラメータ情報を使
って文書のテキストを解析する。解析される文書に対応
するフレームのフレーム・スロットを、第１表にリスト
した当該のカテゴリで埋める。たとえば、ビジネス上の
手紙が読み込まれ、文書番号が割り当てられている場合
、本発明のパラメータ情報抽出システムによって作成さ
れた対応フレームが、手紙の日付、受信者の名前、およ
び第工表にリストした該当するその他の項目を分離する
。それらの識別されたカテゴリが文書番号に対応するフ
レームに入れられる。プログラムは次に、逆ファイル索
引を作成する段階に移る。索引を作成するには幾つかの
手法を用いることができる。。たとえば、第１表に列挙
するように、フレーム内の１０種類のカテゴリのそれぞ
れについて別個の索引を作ることができる。逆ファイル
日付索引は、手紙の日付および対応する文書番号を入力
して作成することができる。解析されている現在の手紙
と同じ日付の別のビジネス通信文が以前に入力されてい
た場合、現在の文書番号は、索引のその日付に関連する
以前の文書番号に単に連結されるだけである。受信者名
に基づいて第２の逆ファイル索引を作成することができ
、解析されている現在のビジネス通信文に対する受信者
の名前をその対応する文書番号と共にその索引に入れる
ことができる。逆ファイル索引を作成するのに別の手法
を取ることもできる。たきえば、各項目が文書番号、お
よび対応する文書に対して特定のキー・ワードが現われ
たフレーム・カテゴリに対するフィールドを含む単一の
索引を作成することができる。こうして得られる逆ファ
イル索引はキー・ワード、それらのキー・ワードが見つ
かった対応する文書の番号、および当該の文書中のキー
・ワードに対するフレーム・カテゴリの指示の集合体で
ある。

第１１図は、文書識別情報を検索するために、本発明に
従って作成されたデータ検索システムに照会を入力する
概略的流れ図を示す。最初のステップは照会の人力を受
は取ることであり、この入力は照会単語の様式化されて
いないシーケンスの形をとっても、また、第１表に列挙
したフレーム・カテゴリのどれかに対応する照会単語を
含む様式化された照会の形をとってもよい。説明をしや
すくするため、ここでは、フレーム・カテゴリに基づく
様式化された照会について説明する。次のステップでは
、主題の記述または参照の記述等のフレーム・カテゴリ
が、索引を作成したときそれらが解析された形と同じ句
表現になっていないことがあるので、照会の解析に、言
語および様式に依存する要素を取り除き、同意語を識別
し、日付等の表現を標準形式にするための言語的処理が
含まれることがある。主題記述カテゴリ中で照会単語に
対する同意語が存在する場合、当該の照会単語の同意語
を、索引探索ステップに出力することができる、主題の
記述に対するフレーム・スロット・カテゴリに対応する
１組の単語としてリストすることができる。索引探索ス
テップでは、特定のフレーム・カテゴリに対する逆ファ
イル索引を探索して、照会単語（およびその同意語）と
索引内の目標単語が一致するかどうか判定する。一致が
識別されたときは、対応する文書番号が記録される。

特定のフレーム・スロット・カテゴリに対するすべての
照会単語および同意語が、フレーム・スロット・カテゴ
リに対応する逆ファイル索引で探索された後、それによ
って得られた一致した項目に対する文書番号を探索動作
でのその出現頻度の順に並べることができる。これによ
り、ユーザが検索するためにシークした文書を識別する
確率の降順に並べられた文書識別のリストが得られる。

文書番号を文書の引用、文書の題名、文書の場所または
文書のその他の識別属性と相関させる別の文書識別テー
ブルを維持することもできる。

このようにして、ビジネス通信文を、従来技術よりも効
率的で信頼性の高い方法で索引を付け、検索することが
できる。

第７表は、索引への各入力の一部としてパラメータ情報
抽出（Ｐ　Ｉ　Ｆ）フレーム・カテゴリで作成された逆
ファイル索引の一例を示す。索引が作成されると、関連
するディスク・ドライブまたは他の大容量記憶装置に記
憶され、読み取られて、文書検索プログラムを実行する
コンピュータのランダム・アクセス・メモリに記憶され
る。第７表に示す例では、例６　ａｓ　ｂｓ　Ｃおよび
ｄのサンプルの文書が、該当する６つのフレーム・カテ
ゴリ、すなわち、各文書の日付、ｔｏ、ｔｏ　ＶＮＥＴ
、ｆｒｏｍ１ｃｃ％　および主題を使って逆ファイル索
引にコンパイルされた。第７表に示す逆ファイル索引の
編成は、キー・ワードが同じフレーム・カテゴリのもと
で編成されているが、フレーム・カテゴリが混合されて
、キー・ワードの順序をハツシング・アルゴリズムその
他の手法で決定することができるようになった他の逆フ
ァイル索引の編成を用いることもできる。

Ｆ０発明の効果 本発明にもとづくパラメータ情報抽出法によって生成さ
れたフレーム・カテゴリの指示がキー・ワード項目に含
まれる、逆ファイル索引の重要な特徴は、文書の日付、
受信者、カーボン・コピー・リスト、および他のパラメ
ータ等のビジネス通信文の一般的なパラメータにアクセ
スできるように構成された照会を迅速かつ確実に突き合
わせできることである。

第１表 ビジネス通信文に関するフレーム・スロット手紙の日付 受信者の名前 発信者の名前 発信者の住所 発信者の肩書 発信者のユーザＩＤ／ノードＩＤ 受信者のユーザＩＤ／ノードＩＤ カーボン・コピー・リスト 主題の記述 参照の記述 第２表 一般的なビジネス通信文 見出し Ｄａｔｅ：　　２９　Ｊｕｎｅ　１９８４．１５：１５
：０３　ＧＯＴＦｒｏｍ：　　　Ｊａｎ　　Ｈｏ１ｅｎ
　　ＪＡｔ（ＨＯＬＥＨａｔ　　ＯＳＬＯＶＭＴｏ：　
　　ＧＢＧＳＥＣＩ　ａｔ　ＹＫＴＶＭＴｃｃ、：　　
ＺＡ）ＩＯＲＡ　ａｔ　ＹＫＴＶＭＴＳｕｂｊ：　　Ｌ
ＥＸＩＳ　ｐｒｏｊｅｃｔ、　Ｎｏｒｗａｙ本文 １１ｉ。

Ｉ　ｎｅｅｄ　ｙｏｕｒ　ａｓｓｉｓｔａｎｃｅ　ｔｏ
　ｍａｋｅ　ｈｏｔｅｌｒｅｓｅｒｖａｔｉｏｎｓ　ａ
ｎｄ　ａｄｖｉｃｅ　ｆｏｒ　ｔｈｅ　ｍｏｓｔｃｏｎ
ｖｅｎｉｅｎｔ　ｗａｙ　ｔｏ　ｔｒａｖｅｌ　ｆｒｏ
ｍ　Ｗａｓｈｉｎｇｔｏｎ　ＤＣａｉｒｐｏｒｔ　ｔｏ
　Ｇａｉｔｈｅｒｓｂｕｒｇ。

１１１ｅ　ａｒｅ　ｔｗｏ　ｐｅｏｐｌｅ　ａｒｒｉｖ
ｉｎｇ　ｏｎ　５ｕｎｄａｙ、　Ｊｕｌｙ　８ｗ１ｔｈ
　ｆｌｉｇｈｔ　Ｎｏ、　ＴＶ　７４９　ｆｒｏｍ　Ｊ
、　Ｆ、　Ｋｅｎｎｅｄｙ。

Ａｒｒｉｖａｌ　ｔｉｍｅ　ｉｓ　ｅｓｔｉｍａｔｅｄ
　ｔｏ　ｂｅ　７：１１　ｐ、ｍ。

Ｏｕｒ　ｎａｍｅｓ　　ａｒｅ：　　Ｊａｎ　　ｌ１ｏ
ｌｅｎ、ＩＢＭ　Ｏｓｌ。

Ｊａｎ　　Ｅｎｇｈ、Ｕｎｉｖｅｒｓｉｔｙ　　ｏｆ　
Ｏｓｌ。

Ｐｌｅａｓｅ　ｍａｋｅ　ａ　ｃａｒ　ｒｅｓｅｒｖａ
ｔｉｏｎ　ａｔ　ｌＪａｓｈｉｎｇｔｏｎＡｉｒｐｏｒ
ｔ　ａｎｄ　　ｗｅ　　ｗｉｌｌ　　ｇｏ　　ｂｙ　ｃ
ａｒ　　ｔ。

Ｇａ１ｔｈｅｒｓｂｕｒ８゜ Ｐｌｅａｓｅ、　　ｍａｋｅ　ｔｈｅ　ｆｏｌｌｏｗｉ
ｎｇ　ｈｏｔｅｌｒｅｓｅｒｖａｔｉｏｎｓ： Ｊａｎ　　１ｌｏｌｅｎ　　ｆｒｏｍ　Ｊｕｌｙ　　８
　−　Ｊｕｌｙ　　１３Ｊａｎ　　Ｅｎｇｈ　　ｆｒｏ
ｍ　Ｊｕｌｙ　８　−　Ｊｕｌｙ　２０Ｐｌｅａｓｅ　
ｃｏｎｆｉｒｍ　ｗｈｅｎ　ａｒｒａｎｇｅｄ。

結び Ｊａｎ　Ｈｏ１ｅｎ 第３表 ビジネス通信文の結語のリスト ＲＥＧＡＲＤＳ、　ＢＥＳＴ　ＲＥＧＡＲＤＳ、υ１刊
ＲＥＧＡＲＤＳ。

υＡＲＭ　ＲＥＧＡＲＤＳ、　ＥＴＣ。

ＴＩＩＡＮＫＳ、　ＴＩＩＡＮＫＳ　ＩＮ　ＡＤＶＡＮ
ＣＥ、　ＭＡＮＹ　ＴＩＩＡＮＫＳ。

ＴｌｌΔＮＫ　Ｙｏｕ、　ＥＴＣ。

５ＩＮＣＥＲＥＬＹ ＹＥ ＲＥＳＰＥＣＴＦＵＬＬＹ ＶＥＲＹ　ＴＲＵＬＹ ０ＵＲＳ ＢＥＳＴ暫ｌ５ＩＩＥＳ ＧＯＯＤ　　ＬＵＣＫ 第４表 見出し識別子のリスト ＲＥＦＥＲＥＮＣＥ、　ＲＥＦＥＲＥＮＣＥＳ、　ＲＥ
、、　ＲＥＦＳ［ＩＢＪＥＣＴ、　５ＵＢＪ。

ＴＯ，１４ＥＭｏ　Ｔｏ、　１４ＥＭＯＲＡＮＤＵ１４
　Ｔ。

ＮＡＭＥ、　ＮＡＭＥ　＆　ＴＩＥ　ＥＸＴ。

ＲＯＭ ＣＣ，Ｃ０ＰＹ　Ｔｏ、　ＡＬＳＯＴＯ，ＣＡＲＢＯＮ
　Ｃ０ＰＹＵＳＥＲＩＤ、　）ＩＯＤＥＩＤ ＴＩＴＬＥ／ＤＥＰ、　ＮＡ１４Ｅ ＡＤＤＲＥＳＳ、　　ＮＥＴυＯＲＫ　　ＡＤＤＲＥＳ
Ｓ、　　ＩＮＴＥＲＩ（ΔＬ　　ＡＤＤＲＥＳＳ。

ＭＡＩＬ　ＡＤＤＲＥＳＳ ＡＴＥ 置ＥＰＩＩＯＮＥ、　ＰＩＩＯＮＥ、　置。

ＩＮＦＯＲＭＡＴＩＯＮ　ＴＯ ＭＥＳＳＡＧＥ　　ＦＯＲ ＭＥＳＳＡＧＥ　ＦＲＯＭ ＩＳＳＵＥＤ　ＢＹ 第５表 見出しの予想 意味論的予想　　　　構文および語負上の予想の例 手紙の日付 ＦＥＢＲＵＡＲＹ　２９．１９８４ ２９　ＪＵＮＥ　１９８４ ？／３０／８４ １５．０８．８４ ＤＡＴＥ： 発信者の名前 ＦＲＯＭ、　ＦＲＯＩＣ ＮＡＭＥ　＆　ＴＩＥ／ＥＸＴ、： 受信者の名前 ＴＯ，ＴＯ： 住所 ＡＤＤＲＥＳＳ、ＡＤＤＲＥＳＳ　： ＡＤＤＲ，、ＡＤＤＲ：、　ＡＤＤＲ，：ＴＩＴＬＥ ＴＩＴＬＥ、ＴＩＴＬＥ： ＴＩＴＬＥ　　／　　ＤＥＰＴ、　　ＮＡＭＥ：カーボ
ン・コピー・リスト ｃｃ、　ｃｃ’ｓ、　ｃｃ： Ｃ０ＰＹ　Ｔｏ： ＮＥＴ １１ＵＧＩＩＩＪ−ＳＴＡＭＩＰＳ ＧＢＧＳＥＣ５（ＹＫＴＶＨＴ） ＧＢＧＳＥＣＩ　ＡＴ　ＹＫＴＶＭＴ １４Ｚ ＹＫＴＶＭＴ　ＧＢＧＳＥＣＩ ＧＢＧＳＥＣＩ　ＹＫＴＶＭＴ 主題 ５ＵＢＪＥＣＴ、　５ＵＢＪＥＣＴ： ５ＵＢＪ、、　５ＵＢＪ： 参照 ＲＥＦＥＲＥＮＣＥ、　ＲＥＦＥＲＥＮＣＥ：ＲＥＦ、
、　ＲＥＦＴ、　ＲＥＦ、： 第６表 結びの予想 意味論的予想　　　　構文および語第上の署名 住所 識別子無し 肩書 識別子無し カーボン・コピー・リスト ＣＣ，ＣＣ’Ｓ、　ＣＣ： Ｃ０ＰＹ　ＴＯ： ＮＥＴ ＋１［ＩＧＨｌｉｌ−３ＴＡＭＩＰＳ ＧＢＧＳＥＣ５（ＹＫＴＶ）（Ｔ） ＧＢＧＳＥＣＩ　ＡＴ　ＹＫＴＶＭＴ ＭＺ ＹＫＴＶ）ＩＴ　ＧＢＧＳＥＣＩ ＧＢＧＳＥＣＩ　ＹＫＴＶＭＴ 第７表 ＰＩＥフレーム・カテゴリによる 逆ファイル索引

【図面の簡単な説明】

第１図はパラメータ情報抽出処理のデータ流れ図である
。 第２図はビジネス通信文書の文章モデルである。 第３図は日付構文のデータ流れ図である。 第４図は、文書からパラメータ・フィールドを抽出する
ＭＡＩＮＥＸＴプログラムの流れ図である。 第５図は、文書の結びを識別するＥＮＤ　　Ｄ。 Ｃプログラムの流れ図である。 第６図は、文書の見出しを識別するＨＥＡＤＤＯＣプロ
グラムの流れ図である。 第７図は、見出しからパラメータ・フィールドを抽出す
るＨＥＡＤＩＮＧプログラムの流れ図である。 第８図は、結びからパラメータ・フィールドを抽出する
ＥＮＤ　ＩＮＧプログラムの流れ図である。 第９図は、パラメータ・フィールド・フレームを作成す
るｌ５ＯＬＥＸＴプログラムの流れ図である。 第１０図は、文書識別をデータ・ベースに入力する動作
を示す流れ図である。 第１１図は、データ・ベースから文書識別を検索するた
めの照会の入力を示す流れ図である。 出願人　　インターナショナル・ビジネス・マシーンズ
ーコーポレーション 代理人　　弁理士　　岡　　１）　次　　生（他１名） 文ｔａ折　　　フし−ム解釈　　　マソピーグへ°〜サ
　　　　モジー−２し　　　、っ、−Ｌ　　　　　モジ
ューｊし第１図 第３図

Claims (1)

1. 【特許請求の範囲】 自由な書式の文書から通常明記される特定情報を自動的
   に抽出するための下記ステップ（イ）ないし（ホ）を有
   する情報抽出方法： （イ）上記文書を読込み、 （ロ）構造、構文および意味論に関する知識データ・ベ
   ースを読込み、 （ハ）上記構造に関する知識データ・ベースを用いて上
   記文書の１つ以上の主要情報要素を識別し、（ニ）上記
   構文および意味論に関する知識データ・ベースとパター
   ン・マッチング手順を用いて上記主要情報要素を解析す
   ることにより、上記特定情報を得て、それを標準様式で
   生じ、 （ホ）上記主要情報要素内の上記特定情報に対応するス
   ロットを有する定様式フレームを生じる。