JPH0863181A - ユニファイされた文法コンパイラを含む音声インタプリタ - Google Patents

Abstract

(57)【要約】 【目的】 本発明は、マイクロプロセッサ・ベースの汎
用コンピュータ上で動作するユーザ・アプリケーション
のためにリアルタイムで音声を理解することができる音
声インタプリタ用のユニファイされた文法を提供するも
のである。 【構成】 音声インタプリタは、ユニファイされた文法
（ＵＧ）コンパイラと、音声認識プログラムと、自然言
語（ＮＬ）プロセッサとを含む。ＵＧコンパイラは、共
通のＵＧ辞典およびユニファイされた文法記述を受け取
り、音声認識プログラムおよび自然言語プロセッサ用
に、調和の取れた音声認識（ＳＲ）文法およびＮＬ文法
をそれぞれ生成する。この辞典は、所定の特性、すなわ
ち特徴を有する複数のＵＧ語項目を含み、ＵＧ記述は、
文法的に許容される語シーケンスを定義する複数の複雑
なＵＧ項目を含む。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、音声理解に関し、詳細
には、リアルタイムで音声を理解することができる音声
インタプリタに関する。

【０００２】コンピュータ・ベースのリアルタイム音声
解釈は、２つの異なる人間の認識プロセスを模倣する。
第１に、音声認識プログラムは、入力された音声ストリ
ームを適当な語シーケンスに変換する。次に、自然言語
プロセッサは、このような語を認識し、すなわち、特定
のユーザ・アプリケーションに関する意味を語シーケン
スから抽出しようとする。歴史的に見ると、汎用コンピ
ュータの計算上の限界のために、リアルタイム音声分析
は、ディジタル信号プロセスなど精巧な専用ハードウェ
アの助けを得て行われている。しかし、最近、マイクロ
プロセッサの計算力が向上したので、ディジタル化音声
のリアルタイム音声解釈は現在、完全に、マイクロプロ
セッサ・ベースの汎用コンピュータ上で動作するソフト
ウェアによって行うことができる。

【０００３】図１は、主としてソフトウェア・プログラ
ムであり、共に、コンピュータのメモリ（図示せず）に
ロードされる、音声インタプリタ１００とターゲット・
ユーザ・アプリケーション（図示せず）とを含む従来型
の音声解釈用システムを示す。インタプリタ１００は、
直列に結合された、従来型の音声認識プログラム１２０
と、従来型の自然言語（ＮＬ）プロセッサ１３０と、ア
プリケーション・コマンド翻訳プログラム１４０とを含
む。音声インタプリタ１００はさらに、ＮＬ記述をＮＬ
文法に変換するためにＮＬプロセッサ１３０に結合され
たＮＬ記述コンパイラ１３５を含む。音声認識プログラ
ム１２０には音声認識（ＳＲ）文法が提供される。

【０００４】音声インタプリタ１００は、音響入力装置
１１０にも結合されている。音響入力装置１１０は、人
間のユーザ１０５によって生成された入力音声ストリー
ムを、機械で読みとれる形に変換する。ディジタル・コ
ンピュータ実施態様では、音響入力装置１１０は、音声
をディジタル化するアナログ・ディジタル（Ａ／Ｄ）変
換器を含む。次に、音声認識プログラム１２０は、（Ｓ
Ｒ文法によって定義されている）内部有限状態機械を型
板として使用して、ディジタル化音声を、認識される語
のシーケンスに変換する。ＮＬプロセッサ１３０は、Ｎ
Ｌコンパイラ１３５からのＮＬ文法によって定義されて
いる内部パターンとこのような語シーケンスを比較し、
許容される文を認識し、アプリケーション・コマンド翻
訳プログラム１４０に許容される文を表す対応するサマ
リー構造を作成する。翻訳プログラム１４０は次いで、
知られている１組のユーザ・アプリケーション・コマン
ドとサマリー構造を一致させ、次の処理ができるように
ユーザ・アプリケーション（図示せず）に適当なコマン
ドを返す。

【０００５】直感的には、人間のリスナが、どれだけう
まく、音声をリアルタイムで直感的に理解するかを考え
ると、音声解釈を実行するようにコンピュータをプログ
ラムすることは取るに足りないことのように思われる。
しかし、実際には、大量の語彙を使用する様々な話者か
らの連続音声をリアルタイムで解釈するようにコンピュ
ータをプログラムし、同時に、低エラー率を維持するこ
とは、非常に捕らえどころのないことであることが分か
っている。現在の所、商業的に受け入れられているエラ
ー率（９０％を超える語が正しく理解される）は、小規
模な１組の人間の話者のみに機能するように従来技術の
音声認識プログラム１２０を「訓練」し、すなわち、話
者依存システムを構成し、あるいは、語彙および文法を
厳しく制限することによって達成されている。

【０００６】音声解釈の問題は２つある。英語の完全な
語彙のＳＲ処理とＮＬ処理は共に、極めて困難なことで
ある。音響入力音声を大量の語彙をもつ無制限の言語に
突き合わせて試験することは、実際的なＳＲ処理ではな
い。ＳＲタスクの困難さの度合い、すなわち、語彙の量
に関連する問題と組み合わされる、どの語シーケンスが
許容されるかの問題を表すために、パープレクシティの
概念が使用されている。パープレクシティは、音声認識
プログラムが平均語境界で選択する必要がある「同様に
可能性の高い」語の平均数として定義されている。した
がって、語の確率も語シーケンスの確率もないときのパ
ープレクシティは、総語彙量に等しい。

【０００７】幸運なことに、コンピュータ・ベースの多
数のユーザ・アプリケーションでは、語彙、すなわち、
コマンド・セットはかなり限られており、許容される語
シーケンスを定義する文法は極めて厳密なものであって
よく、通常、約５０のパープレクシティをもたらす。そ
のような英語のサブセットに関連する厳密さのために、
リアルタイムＮＬ理解は、マイクロプロセッサ・ベース
のコンピュータで動作するこのようなユーザ・アプリケ
ーションに対する実際的な計算タスクとなっている。そ
の結果、従来型のＳＲプロセッサおよびＮＬプロセッサ
は、その言語で許容される可能な語およびシーケンスの
探索を著しく制限するＳＲ文法およびＮＬ文法を使用す
ることによって、リアルタイムで、かつ受け入れること
のできる成功率で話者依存音声を処理することができ
る。

【０００８】ＳＲ処理とＮＬ処理は、機能が異なるの
で、異なる問題を与える。ＳＲは、ディジタル化された
音声を「適当な」語シーケンスに変換することを含む
が、ＮＬ処理は、（場合によっては、誤った）入力語シ
ーケンスから所与のアプリケーション向けの意味を抽出
することを含む。さらに、ＳＲは、大量のデータの「浅
い」処理を含むが、ＮＬ理解は通常、ずっと少ない量の
データの「深い」処理を含む。

【０００９】従来技術の音声認識プログラム１２０は、
その認識速度および認識精度を向上させるために、個別
のＳＲ文法を使用して、探索を、アプリケーションで許
容される可能性の高い語シーケンスに制限する。通常、
ＳＲ文法は、比較的少数の許容できる語シーケンスの意
味を解読する必要なしに、このようなシーケンスに対応
する簡単な有限状態構造を定義する。典型的なＳＲ有限
状態構造は簡単で「浅い」構造であるので、ＳＲ文法を
表す従来型のプログラミング・ツールは同様にプリミテ
ィブなものである。そのため、音声認識プログラム用の
ＳＲ文法を作成することは、アセンブラ・プログラミン
グ言語でコード化を行うタスクに類似している。すなわ
ち、非常に労力がかかって面倒なものであり、出力を理
解するのが容易でない。さらに、ＳＲ文法は、空間と時
間の折合いにおいて最高の性能を達成し、パープレクシ
ティを最小限に抑えるために、特定の音声認識プログラ
ムによって課される構文上の制限に適応するための固有
の制限に従う必要がある。

【００１０】たとえば、ユーザ・アプリケーション用の
ログイン・シーケンスで、許容されるユーザの姓名のリ
ストは、「ＢＯｂ Ｊｏｎｅｓ」、「Ｊａｎｅ Ｓｍｉ
ｔｈ」、「Ｊａｎｅ Ｊｏｎｅｓ」、および「Ｐｅｔｅ
Ｂａｋｅｒ」に限られる。代替の姓名を定義するその
ようなアプリケーション用の典型的なＳＲ文法規則は、
以下のようにコード化することができる。 $fullname:(Bob Jones｜Jane Smith｜Jane Jones｜Pete
Baker); ここで＄マークはＳＲ規則名およびＳＲ規則要素名に先
立つ。

【００１１】上記のＳＲ文法規則は、正確であるが、１
組の多数のユーザ名に対して実施するには非常に広範囲
で面倒なものである。精巧な音声認識プログラムは、以
下の規則など、わずかにより強力で柔軟なＳＲ文法規則
バージョンを受理することができる。 $fullname:$firstname$lastname; $firstname:(Bob｜Jane｜Pete); $lastname:(Jones｜Smith｜Baker);

【００１２】第２のバージョンに関する問題は、許容範
囲が広すぎ、すなわち、このバージョンが姓名の無効な
順列を制限し、かつなくす手段をもたないことである。
そのため、「Ｂｏｂ Ｓｍｉｔｈ」および「Ｐｅｔｅ
Ｊｏｎｅｓ」も、音声認識プログラム１２０によって誤
って受理され、無効な姓名がＮＬプロセッサ１３０に送
られる。

【００１３】これに対して、ＮＬプロセッサ１３０は、
適当な語シーケンス（文）を音声認識プログラム１２０
から受け取り、ＮＬ文法によって定義されている複数の
内部ＮＬパターンと各文を比較して語シーケンスの「意
味」を抽出する。これは、許容される句構造を表す基礎
ＮＬ文法定義によって暗黙的に表されるＮＬパターンに
対応する各文ごとの句パターンを算出することによって
行われる。たとえば、「名前」リストの語が認識された
際、ＮＬ文法規則によって、ＮＬプロセッサ１３０は、
「動詞」リストの語を探索して以後の語を解析する。

【００１４】このようなリスト、たとえば、「名前」、
「動詞」は、ＮＬ文法の記述の生成を簡単にする多数の
プログラミング・ツールを使用して表される。これらの
ツールには、許容される語とその特徴を定義する辞典
（語ライブライリ）が含まれ、この特徴は、試験のため
と、ＮＬ文法によって意味をコード化するために使用さ
れる。他のプログラミング・ツールは、１組のＮＬ試験
をＮＬ記述言語で表し、それによって、規則制限を表
す、より分かりやすい機構を作成することができる機能
を提供する。同様に、ＮＬ文法に関連する「動作」（割
当て）は、語シーケンスからの「意味」の抽出をサポー
トする。ＮＬ記述のコード化は、広範囲で強力な１組の
プログラミング・ツールを使用して行われるので、効率
的にかつ正確に実行することがより容易なタスクであ
る、高水準プログラミング言語でのコード化に類似して
いる。

【００１５】別々に生成されたＳＲ文法とＮＬ文法を使
用する上述の従来型の音声インタプリタ１００は、いく
つかの欠点を有する。これらの欠点は主として、音声認
識プログラム１２０がＮＬプロセッサ１３０と「協働し
て」機能するようにＳＲ文法とＮＬ文法の調和をとるこ
とが絶対に必要であるである。

【００１６】１つの問題は、ＳＲ文法の「厳密さ」（音
声認識プログラム１２０が出会うパープレクシティを制
御すること）とＮＬプロセッサ１３０の性能の間の折合
いが重大であることである。ＳＲ文法が厳密過ぎ、すな
わち、語シーケンスのフィルタリングが過度に厳密であ
る場合、わずかに誤って発音された語や取るに足らない
文法エラーを含むシーケンスなど、大量の有用な語シー
ケンスが、音声認識プログラム１２０によって拒否さ
れ、ＮＬプロセッサ１３０に到達しなくなる。普通なら
有用な語シーケンスが自動的に拒否されると、ＮＬプロ
セッサ１３０が適当さの少ない語シーケンスを受け取
り、あるいは、コマンドまたは応答が完全に失われる。
その結果、ユーザ・アプリケーションは、コマンドまた
は応答の繰返しを要求することが必要になり、最終的
に、人間のユーザ１０５を困惑させる。

【００１７】逆に、ＳＲ文法が過度に「ゆるやかな」も
のである場合、音声認識プログラム１２０は、良好な認
識結果を達成するのに必要な適当な制限なしで推定を行
い、そのため、ＮＬプロセッサ１３０はあまりにも多く
の誤った語シーケンスを受け取り、そのため、ＮＬプロ
セッサ１３０に大量の「ワード・サラダ」に相当するも
のが提供される。その結果、音声認識プロセッサ１２０
が、実際上のフロント・エンド・フィルタとして機能で
きなかったので、ＮＬプロセッサ１３０の性能は低下す
る。

【００１８】他の問題は、ユーザ・アプリケーションの
語彙または文法を変更したとき、たとえば、新しいコマ
ンド／ユーザ名または許容される新しいコマンド形／表
現を追加した時に必ず発生する。そのような変更は、さ
さいなものかどうかにかかわらず、ＳＲ文法とＮＬ文法
の両方に加えなければならない。このような同時変更は
調和をとらなければならず、そうしない場合、音声認識
インタプリタ１００の内部動作に障害がもたらされる。
この調和要件は、ＳＲ文法を表すために使用できる従来
型の形式が一般に弱いものであるため、はるかに大きな
問題である。

【００１９】上述のように、ＳＲ文法とＮＬ文法は異な
るプロセス、すなわち、語シーケンスの一致と意味抽出
を制御し、すなわち、音声認識プログラム１２０は低レ
ベルの語認識プロセスに関与し、ＮＬ認識プログラム１
３０は、人間のユーザ１０５からのコマンドまたは応
答、あるいはその両方を理解する比較的高いレベルのプ
ロセスに関与する。たとえば、ＮＬプロセッサ１３０
は、語または句の意味を抽象化し、それによって実際
上、語対「Ｉ ａｍ」、「Ｉ ｉｓ」、「Ｉ ａｒ
ｅ」、「Ｍｅ ａｍ」、「Ｍｅ ｉｓ」、および「Ｍｅ
ａｒｅ」を同じ意味を有するものとみなす。ただし、
これらの語対のうちで文法的に正しいのは最初の対だけ
である。

【００２０】そのため、ＳＲプロセスとＮＬプロセス
（とそれぞれの文法）をユニファイ（統合）しようとす
るのは反直感的である。高水準言語かアセンブラ言語類
を使用する際、最終的な個別のオブジェクト・コード命
令の構文および順序が特に重要である場合、プログラマ
は一般に、コードを高水準言語では書かない。これは、
プログラマが、高水準言語でコード化を行うときは主と
して、ルーチンの正確な表現よりもその機能に関心があ
り、表現を容易にするために細部の制御を犠牲にするか
らである。

【００２１】したがって、現在、ＮＬ文法を生成するた
めにしか使用できないプログラミング・ツールを使用す
ることによって、ＳＲ文法およびＮＬ文法を実施する現
在の所異なる２つのプロセスを統合する必要がある。そ
のような統合によって、調和のとれた１組のＳＲ文法お
よびＮＬ文法を実施し維持するのに必要なプログラミン
グ作業が大幅に低減される。さらに重要なことには、そ
の結果得られる統合された文法は、より強力で効果的で
ある。

【００２２】

【発明が解決しようとする課題】本発明は、マイクロプ
ロセッサ・ベースの汎用コンピュータ上で動作するユー
ザ・アプリケーションのために、リアルタイムで音声を
理解することができる音声インタプリタ用のユニファイ
された（統合された）文法を提供することを目的とする
ものである。

【００２３】

【課題を解決するための手段】本発明による音声インタ
プリタは、ユニファイされた文法（ＵＧ）コンパイラ
と、音声認識プログラムと、自然言語（ＮＬ）プロセッ
サとを含む。ＵＧコンパイラは、共通のＵＧ辞典および
ユニファイされた文法記述を受け取り、音声認識プログ
ラム用の音声認識（ＳＲ）文法と、自然言語プロセッサ
用のＮＬ文法を生成する。

【００２４】この辞典は、所定の特性、すなわち特徴を
有する複数のＵＧ語項目を含み、ＵＧ記述は、文法的に
許容される語シーケンスを定義する複数の複雑なＵＧ項
目を含む。ＳＲ文法は、複数のＵＧ語項目に対する複数
のＳＲ語項目と、許容される複数のＳＲ語シーケンス
と、複雑なＵＧ項目のオーグメンテーションに対応する
簡単なＳＲ規則とを含む。したがって、ＳＲ文法は、Ｓ
Ｒ語項目と、許容されるＳＲ語シーケンスと、簡単なＳ
Ｒ規則を、音声認識プログラムに提供する。これに対し
て、ＮＬ文法は、ＮＬプロセッサが、音声認識プログラ
ムから渡された許容される語シーケンスの意味を抽出で
きるようにするＮＬパターンをＮＬプロセッサに提供す
る。音声インタプリタとユーザ・アプリケーションのイ
ンタフェースをとるためにコマンド翻訳プログラムも提
供される。

【００２５】本発明の一態様によれば、ＳＲ文法および
ＮＬ文法は、共通の源、すなわち、共に、読取り可能で
容易に適応可能な「高水準」記述形式でコード化され
た、共通のユニファイされた文法記述と補助辞典をコン
パイルすることによって導出される。匹敵するＳＲ文法
およびＮＬ文法が作成されるようにＵＧコンパイル・プ
ロセスの調和をとることが可能なのは、ＵＧコンパイラ
がユニファイされた文法記述の複雑なＵＧ規則（複雑な
ＵＧ規則には、その規則を制限するオーグメンテーショ
ン（augmentation）が含まれる）を、ＳＲ文法用の許容
されるＳＲ語シーケンスおよび簡単なＳＲ規則（簡単な
規則には、オーグメンテーションは含まれない）に変換
するからである。

【００２６】本発明の一実施例では、音響装置が、音声
インタプリタ用のディジタル信号として音声を変換する
音声認識プログラムに結合されている。他の実施例で
は、入力音声が、遠隔でディジタル化され、ＩＳＤＮ電
話信号など標準ディジタル化形で音声インタプリタに提
供される。いくつかの実施例で、音声インタプリタおよ
び関連するユーザ・アプリケーションは、テキストを音
声に変換できるように音声合成器に結合される。

【００２７】本発明の音声インタプリタは、従来技術に
勝る多数の利点を有する。ＳＲ文法とＮＬ文法の生成の
調和をとり簡略化することによって、新しいユーザ・ア
プリケーション用の新しいＵＧ辞典およびユニファイさ
れた文法記述をプログラムすることと、既存のユーザ・
アプリケーション用の既存の辞典およびユニファイされ
た文法記述を修正することが共に、大幅に簡略化され
る。プログラミング効率だけでなく、この結果得られる
調和のとれたＳＲ文法とＮＬ文法は、より強力であり、
音声認識プログラムとＮＬプロセッサの相互運用性を向
上させる。したがって、本発明の音声インタプリタは、
「ハンズ・フリー」オペレータを必要とする多数の今日
のユーザ・アプリケーションにおけるビルディング・ブ
ロックとして、あるいは、運動障害のあるユーザ用に容
易に使用することができる。

【００２８】表記および用語 ＢＮＦすなわちバッカスナウア記法：形式言語の構文を
定義するメタ言語。 ＣＦＧ：文脈自由文法とは、規則が、その周囲にかかわ
らず、その内容だけを参照する形式である。 ＦＳＡ：有限状態オートマトンとは、１組の節と、節の
間の遷移アークとして表すことができる（ＣＦＧよりも
弱い）形式である。 ＨＭＭ：隠れマルコフ連鎖法：確率が、音声の要素を認
識することをモデルに学習させるように「訓練」され
る、確率的ＦＳＡ。 ＮＬ：自然言語 ＳＲ：音声認識 ＳＷＩＦＴＵＳ：テキスト理解用のＦａｓｔｕｓに代わ
るソフトウェアとは、米国カリフォルニア州マウンテン
・ビュー（Ｍｏｕｎｔａｉｎ Ｖｉｅｗ）のＳｕｎ Ｍ
ｉｃｒｏｓｙｓｔｅｍｓ Ｌａｂｏｒａｔｏｒｉｅｓ，
Ｉｎｃ．によって開発された自然言語プロセッサであ
る（「ＦＡＳＴＵＳ： Ａ ｓｙｓｔｅｍ ｆｏｒ ｅ
ｘｔｒａｃｔｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ｆｒｏ
ｍ ｔｅｘｔ」（ＡＲＰＡ Ｈｕｍａｎ Ｌａｎｇｕａ
ｇｅ Ｔｅｃｈｎｏｌｏｇｙ Ｗｏｒｋｓｈｏｐ議事
録、１３３ないし１３７ページ、Ｐｌａｉｎｓｂｏｒ
ｏ，ＮＪ、１９９３年３月）も参照されたい） ＴＴＳ：音声へのテキスト ＵＧ：ユニファイされた文法 終端：（定義された）語 非終端：＜名詞＞、＜形容詞＞など、すなわち、指定さ
れた規則を適用した結果。

【００２９】

【実施例】以下の詳細な説明は、いくつかの節に分かれ
ている。最初の節では、本発明のインタプリタをインス
トールして操作するための一般的なハードウェア・シス
テム構成について説明する。以後の節では、ユニファイ
された文法（ＵＧ）コンパイラ用の入力ファイルのフォ
ーマット、音声認識（ＳＲ）文法および自然言語（Ｎ
Ｌ）文法を生成するそれぞれのコンパイル・プロセス
と、本発明の音声認識プログラムおよびＮＬプロセッサ
の全体的な構造および動作など、本発明の様々な機能態
様について説明する。

【００３０】この説明では、多数の詳細によって本発明
を完全に理解することができる。このような詳細には、
開発者が音声インタプリタを使用する際に助けとなる機
能ブロック、フローチャート、バッカスナウア記法（Ｂ
ＮＦ）の定義、およびＬＩＳＰの定義が含まれる。ま
た、本発明の音声インタプリタは、特定の実施態様に関
して記載されているが、本発明は様々なユーザ・インタ
フェースおよび環境に適用することができる。他の例で
は、本発明を不必要にあいまいにしないように、周知の
回路および構造については詳細に説明していない。

【００３１】（ｉ）一般的なハードウェア・システム構
成 図２に示した本発明の一実施例によれば、音声インタプ
リタは、中央演算処理装置（ＣＰＵ）２５１と、ホスト
・メモリ２５２と、ホスト・バス制御装置２５３と、ホ
スト・システム・バス２６０と、モニタ２６１ａと、キ
ーボード２６１ｂと、マウス２６１ｃとを含む、汎用ホ
スト・コンピュータ２５０で実施される。アナログ・デ
ィジタル（Ａ／Ｄ）変換器２６１ｂとマイクロフォン２
６２ｂとを有する音響入力装置２６２が、システム・バ
ス２６０に結合されている。

【００３２】この実施例では、コンピュータ２５０は、
ディジタル・アナログ変換器（ＤＡＣ）２６３ａとオー
ディオ・スピーカ２６３ｂとを有する音響出力装置２６
３にも結合されている。いくつかの実施例では、アナロ
グ音声とディジタル・フォームとの間の変換が、たとえ
ば、ディジタルＩＳＤＮ電話回線を従来型のＩＳＤＮア
ダプタ（図示せず）を介してホスト・コンピュータ２５
０のシステム・バス２６０に結合することによって、ホ
スト・コンピュータ２５０から遠隔で行うことができ
る。

【００３３】（ｉｉ）音声インタプリタの一般的説明 この実施例では、図３のブロック図で示された音声イン
タプリタ３００は、コンピュータ２５０のホスト・メモ
リ２５２にロードされる。音声インタプリタ３００は、
直列に結合された、音声認識プログラム３２０と、自然
言語（ＮＬ）プロセッサ３３０と、任意選択のアプリケ
ーション・コマンド翻訳プログラム３４０とを含む。音
声インタプリタ３００は音響入力装置２６２に結合され
ている。ユニファイされた文法（ＵＧ）コンパイラ３５
０は、やはりホスト・メモリ２５２にロードされ、音声
認識プログラム３２０とＮＬプロセッサ３３０の両方に
結合されている。

【００３４】ハードウェア・システム構成の変更を含む
他の実施例が可能である。たとえば、ＵＧコンパイラ３
５０を、ＳＲ文法およびＮＬ文法を生成するためにコン
ピュータ２５０で実施し、同時に、音声認識プログラム
やＮＬプロセッサ３３０など（ＵＧコンパイラ３５０を
除く）、音声インタプリタ３００の残りの部分を、ＳＲ
文法およびＮＬ文法のコピーと共に、異なるコンピュー
タで実施することができる。ＳＲプロセスとＮＬプロセ
スを異なるコンピュータ・システム上で実行することも
可能である。

【００３５】図６に示した本発明のこの実施態様によれ
ば、パーサ４５５は、カレンダ・マネージャ、ｅメール
（電子メール）システム、音声メール・システムなどの
ユーザ・アプリケーションに対応するＵＧ規則制限を含
むユニファイされた文法（ＵＧ）記述（たとえば、ｘ．
ＵＧファイル）を処理する。パーサ４５５は、ＵＧコン
パイラ３５０のために従来型のＬＩＳＰフォーマットで
対応するユニファイされた文法（たとえば、ｘ．ＵＧＲ
ＡＭファイル）を生成する。個別の補助ＵＧ辞典（たと
えば、ｘ．ＬＥＸファイル）は、プログラミングの容易
さ、維持可能性、および移植性を拡張するために、特
性、たとえば、ユニファイされた文法によって参照され
る語の「意味」を定義する。

【００３６】たとえば、ＬＯＧＩＮ．ＬＥＸは、語「ａ
ｄａｍｓ」、「ｂａａｔｚ」、「ｍａｒｔｉｎ」、「ｓ
ｐｒｏｕｌｌ」、「ｓｕｔｈｅｒｌａｎｄ」、および
「ｙａｎｋｅｌｏｖｉｃｈ」を「ｎａｍｅｓ，ｌａｓ
ｔ」としてマーク付けし、語「ｂｅｒｔ」、「ｂｏ
ｂ」、「ｅｒｉｃ」、「ｎｉｃｏｌｅ」、「ｐａｕ
ｌ」、および「ｓｔｕａｒｔ」上に「ｎａｍｅｓ，ｆｉ
ｒｓｔ」をマーク付けし、それによって、ユニファイさ
れた文法がこれらの語を直接含む必要なしに、ユニファ
イされた文法による参照が可能になるようにする。ＵＧ
辞典は、ＵＧコンパイラ３５０の語彙プロセッサ３５０
ａによって受け取られ処理される（付録Ａ、Ｂ、Ｃはそ
れぞれ、例のｘ．ＬＥＸファイル、ｘ．ＵＧファイル、
およびｘ．ＵＧＲＡＭファイル、すなわち、ＬＯＧＩ
Ｎ．ＬＥＸ、ＬＯＧＩＮ．ＵＧ、およびＬＯＧＩＮ．Ｕ
ＧＲＡＭのリストである）。

【００３７】さらに、ＵＧコンパイラ３５０は、音声認
識プログラム３２０を制御するＳＲ文法（たとえば、
ｘ．ＨＧファイル）と、ＮＬプロセッサ３３０を制御す
るＮＬ文法（たとえば、ｘ．ＧＲＡＭファイル）を提供
する（付録ＤおよびＥはそれぞれ、ｘ．ＨＧファイルお
よびｘ．ＧＲＡＭファイルのリストの例である）。

【００３８】図７は、音声インタプリタ３００の動作を
示す流れ図である。簡単に言うと、ＵＧコンパイラ３５
０は、音声認識プログラム３２０のためにＵＧ記述およ
びＵＧ辞典をＳＲ文法に変換し（ボックス５２０）、Ｎ
Ｌプロセッサ３３０のためにＵＧ記述およびＵＧ辞典を
ＮＬ文法に変換する（ボックス５３０）。次に、音声認
識プログラム３２０は、ＳＲ語項目、許容されるＳＲ語
シーケンス、および簡単なＳＲ規則とディジタル化音響
信号を比較し、有効化された語シーケンスをＮＬプロセ
ッサ３３０に提供する（ボックス５４０）。ＮＬプロセ
ッサ３３０は次いで、ＮＬ文法を使用して、有効化され
た語シーケンスから「意味」を抽出し、アプリケーショ
ン・コマンド翻訳プログラム３４０用のコマンドを表す
サマリー構造を提供する（ボックス５５０）。

【００３９】図８は、ＵＧコンパイラ３５０によってＵ
Ｇ辞典およびＵＧ文法からＳＲ文法を生成することを示
す流れ図である。第１に、ＵＧコンパイラ３５０は、辞
典の複数のＵＧ語項目に対応する複数のＳＲ語項目を生
成する（ボックス５２１）。次に、ＵＧコンパイラ３５
０は、許容される複数のＳＲ語シーケンスと、ＵＧ記述
の複雑な規則に対応する簡単なＳＲ規則とを生成する
（ボックス５２２）。最後に、ＵＧコンパイラ３５０
は、ＳＲ語項目、許容されるＳＲ語シーケンス、および
簡単なＳＲ規則を収集して、音声認識プログラム３２０
用のＳＲ文法を形成する。

【００４０】上述のように、音声認識プログラム３２０
およびＮＬプロセッサ３３０の動作は、ＵＧコンパイラ
３５０によってＵＧ辞典およびユニファイされた文法が
コンパイルされた結果であるＳＲ文法およびＮＬ文法に
よって支配される。そのため、音声認識プログラム３２
０とＮＬプロセッサ３３０の両方によって使用される機
能原則を例示するうえで、この実施態様で実施されるＵ
Ｇ辞典およびＵＧ記述の構文の説明が有用である（付録
Ｆは、ＵＧ辞典およびＵＧ記述のフォーマットを詳細に
説明するユーザ・マニュアルである）。

【００４１】（ｉｉｉ）ＵＧ辞典の構文 ユーザ・アプリケーションに応じて、１つまたは複数の
ＵＧ辞典がＵＧコンパイラ３５０に提供される。たとえ
ば、前述の実施例では、ＬＯＧＩＮ．ＬＥＸはユーザ・
ログイン・プロセスの間に使用される語彙を含み、ＣＡ
ＬＥＮＤＡＲ．ＬＥＸは、カレンダ・マネージャ用の関
連意味情報を含む語彙を含む。

【００４２】ＵＧ辞典内で、各語項目は以下のフォーマ
ットで示した多数の特徴を有する。 (word ((feature.value) (feature value1 value2 value3) ;;Comment ) )

【００４３】たとえば、語「ｍａｉｌ」用の語項目は以
下のようにコード化することができる。 (mail ;;The word being defined. ( (cat.n) ;;The word sense is of category noun. (sem.application) ;;Its semantic class is“application." (appl.email) ;;The application is“email." ) ( (cat.v) ;;The sense is of category verb. (sem.move_data) (appl.send_mail) ) )

【００４４】特徴には、構文的範疇（「ｃａｔ」）や語
項目のルート・フォーム（「ｒｏｏｔ」）など所定の特
徴が含まれる。語項目は、意味値（「ｓｅｍ」）や複数
特徴マーク付け（「ｐｌｕｒａｌ」）など、定義済みの
語を使用する文の意味を抽出するのに必要な他の属性を
含むこともできる。特徴およびそれに関連する値は、語
項目をこのような属性に関連付ける機構を提供する。

【００４５】「ｃａｔ」や「ｒｏｏｔ」など所定の特徴
は、すべての語項目のために存在するという点で他の特
徴と区別することができる。語が複数の意味を有する場
合（たとえば、「ｍａｉｌ」は動詞でも名詞でもよ
い）、各意味の定義は１つの語項目内でクラスタ化され
る。上記の特定の例では、「ｍａｉｌ」用の語項目は、
この語の名詞の意味を定義する値「ｎ」（名詞）を有す
る特徴「ｃａｔ」を含む第１の意味と、同じ語の動詞の
意味を定義する値ｖ（動詞）を有する異なる特徴「ｃａ
ｔ」を含む第２の意味とを有する。

【００４６】語項目の所定の特徴「ｒｏｏｔ」は通常、
形態素構文によって定義される語を除き、すなわち、語
の定義が他の語の定義から導出されるときを除き、語彙
プロセッサ３５０ａによって語自体に設定される。特徴
「ｒｏｏｔ」を設定することによって、根が不定形の
「ｂｅ」である語「ａｍ」を定義することを含む、その
ようなある例では、「ａｍ」と「ｂｅ」の間のリンケー
ジ情報をＮＬプロセッサ３３０に送る機構が、ＵＧコン
パイラ３５０のためにＮＬ文法中に提供される。逆に、
基本語形の派生物として定義されている不規則語形を含
め、リンケージ情報のない独立に定義された語の場合、
特徴「ｒｏｏｔ」は、語彙プロセッサ３５０ａによって
内部で生成される。同様に、所定の他の特徴である「ｗ
ｏｒｄ」は、語彙プロセッサ３５０ａによって内部で生
成され、ＵＧ辞典中に明示的に指定する必要はない。

【００４７】他の特徴クラスは特殊な特徴である。たと
えば、特殊な特徴「ｃｏｎｔｒａｃｔｉｏｎｓ−ｏｆ」
は、単一の語（たとえば、「ｄｉｄｎ’ｔ」）として発
音されるが、ＮＬプロセッサ３３０によって語シーケン
ス（たとえば、「ｄｉｄ ｎｏｔ」）と同様に扱われ
る、語のシーケンスを定義するために使用される。他の
特殊な特徴である「ｉｒｒｅｇｕｌａｒ」特徴は、英語
に関する通常の規則に従わない派生された語形、たとえ
ば、不規則に形成された過去時制、過去分詞、ｉｎｇ
形、三人称、複数形などを定義するためのものである。
たとえば、構文を適切に処理して不規則動詞「ｂｅ」の
意味を抽出する１つの方法は、不規則な過去時制、過去
分詞、ｉｎｇ形、および三人称、すなわち、それぞれ、
「ｗａｓ」、「ｂｅｅｎ」、「ｂｅｉｎｇ」、および
「ｉｓ」を有するものとして動詞「ａｍ」を定義するこ
とである。

【００４８】意味値を語に割り当てるとき、単一の値で
はなく１組の値を特徴に関連付けることが妥当なことも
ある。たとえば、１群のコンピュータ・ユーザ名、「Ｂ
ｏｂＪｏｎｅｓ」、「Ｂｏｂ Ｓｍｉｔｈ」、および
「Ｂｏｂ Ｄｏｅ」の名前「Ｂｏｂ」用の語項目の特徴
は、それぞれ、異なる姓に対応する、複数の値に関連付
けられる。この例では、名前「Ｂｏｂ」の「ｕｓｅｒｉ
ｄ」特徴は、「Ｊｏｎｅｓ」、「Ｓｍｉｔｈ」、および
「Ｄｏｅ」のアプリケーション・ユーザ識別子（ＩＤ）
に対応する複数の値に関連付けられている。

【００４９】ＵＧ辞典を単一のファイルとして使用する
か、それとも、１組のファイルとして使用するかは、設
計上の選択に過ぎず、プログラミングの都合に応じて行
われることに留意されたい。論理的には、ＵＧ辞典によ
って提供されるすべての情報は、ＵＧ記述中の追加規則
として組み込むことができる。ＵＧ辞典は、各語ごとに
効率的な表現を提供し、それによって、ＵＧ記述中の各
語ごとに特殊目的の規則を与える必要をなくすものに過
ぎない。したがって、他の実施例では、ＵＧ辞典は、拡
張されたＵＧ記述内に含まれる。

【００５０】（ｉｖ）ユニファイされた文法（ＵＧ）記
述の構文 この実施例では、ＵＧ記述は、音声認識プログラム３２
０によって認識できる語に対応する語項目に関連付けら
れた１組のＵＧ規則を含む。これらのＵＧ規則は。バッ
カスナウア記法（ＢＮＦ）定義と、ＢＮＦ定義を制限
し、あるいは、（辞典の）語項目およびＵＧ規則をＮＬ
プロセッサ３３０によってどのように処理するかを指定
する、補助的な「オーグメンテーション」とを含む。オ
ーグメンテーションには、「ローカル宣言」、「試
験」、および「動作」が含まれる。ＵＧ規則と、ＵＧ規
則のＵＧ記述のオーグメンテーションが、対応するＵＧ
辞典によって定義されている語と、他のＵＧ規則とを参
照することに留意されたい。

【００５１】ＵＧ規則の構造 注： ローカル宣言、試験、および割当てをまとめてオ
ーグメンテーションと呼ぶ。たとえば、ログイン文用の
ＵＧ規則は以下のようにコード化することができる。

【００５２】 {loginSentence/application:=sem=application[“please"]; head application; #A declaration. application.confirm=t; #A test. object:=application.appl; #An assignment. action:='switch; #Another assignment. }

【００５３】ＵＧ記述（入力ファイル）は、すべてのＵ
Ｇ規則に適用されるパラメータを設定する任意選択のグ
ローバル宣言で開始する。グローバル宣言は、音声認識
プログラム３２０およびＮＬプロセッサ３３０の動作を
制御できるように、単にＵＧコンパイラ３５０によって
内部宣言ファイル（たとえば、Ｘ．ＤＥＣＬＳ）に渡さ
れる。

【００５４】各ＵＧ規則には、規則名、ＵＧパターンの
ＢＮＦ定義、任意選択の１組のローカル宣言、試験、お
よび動作の諸要素が含まれる。上述のように、１組のロ
ーカル宣言、試験、および動作はまとめてオーグメンテ
ーションとして知られている。オーグメンテーションを
含むＵＧ規則を複雑な規則と呼び、オーグメンテーショ
ンなしのＵＧ規則を簡単な規則と呼ぶことに留意された
い。

【００５５】ローカル宣言には、「バイアス」宣言およ
び「領域」宣言（ＳＲ文法用）、ＮＬ文法用の「ヘッ
ド」宣言、ならびにＮＬプロセッサ３３０用の「パス」
宣言を含めることができる。任意選択の「バイアス」宣
言は、そのようにマーク付けされたＵＧ規則バージョン
に対応する特定の語シーケンスが音声認識プログラム３
２０によって認識される、他の代替バージョンに対する
ゆう度を予測する。「領域」宣言は、それぞれのＳＲ文
法を使用する際、音声認識プログラム３２０によってＵ
Ｇ規則を選択的にオンおよびオフにできるようにＵＧ規
則にマーク付けする。いくつかの実施態様で、音声認識
プログラム３２０は、バイアスまたは領域をサポートす
ることができず、したがって、バイアス宣言または領域
宣言、あるいはその両方は単に無視される。

【００５６】ＵＧパターンは、ＵＧ規則の右側（ＲＨ
Ｓ）であり、続いて、入力語シーケンス、およびすでに
一致した他のＵＧパターンとの比較のためにＮＬプロセ
ッサ３３０によって使用される。所定の特徴（ｃａｔ、
ｓｅｍ、ｒｏｏｔ、またはｗｏｒｄ）の組合せによって
指定された語と、以前に定義されたＵＧパターンを使用
して、各ＵＧパターンを構成することができる。拡張Ｂ
ＮＦの標準演算子もサポートされ、そのため、任意選択
の規則構成要素（様々な種類の任意選択度を含む）およ
び代替選択肢をＵＧパターン中に容易に定義することが
できる。ＵＧパターン内にかつて存在し、あるいは存在
しない任意選択の規則構成要素は、それを角括弧で囲む
ことによって示される。代替規則構成要素、すなわち、
１つの選択肢が存在しなければならない構成要素は、
「｜」（縦棒）記号で分離されてリストされる。たとえ
ば、任意選択で「ｐｌｅａｓｅ」または「ｃａｎ ｙｏ
ｕ」が前に来て、任意選択で「ｍｅ」が後に続く、語
「ｈｅｌｐ」を含む文を定義するＵＧ規則は、以下のよ
うにコード化することができる。 {loginSentence/help:=[“please"｜(“can"“you")]
“help"[“me"];}

【００５７】また、ＵＧパターン要素の後に続くクリー
ネ・プラス（「＋」）は、要素の１つまたは複数の実現
値を示し、クリーネ・スター（「^*」 ）記号は、要素の
０以上の実現値を示す。したがって、「ｐｌｅａｓｅ」
＋は、「ｐｌｅａｓｅ」および「ｐｌｅａｓｅ ｐｌｅ
ａｓｅ ｐｌｅａｓｅ」に一致し、（［「ｐｒｅｔｔ
ｙ」］「ｐｌｅａｓｅ」）^* は、「ｐｌｅａｓｅ ｐｌ
ｅａｓｅ」、「ｐｒｅｔｔｙ ｐｌｅａｓｅ」、「ｐｌ
ｅａｓｅ」に一致し、「ｐｌｅａｓｅ」の実現値がない
ケースにも一致する。ＵＧ規則定義の要素は、様々なオ
ーグメンテーションによってその部分を明確に参照でき
るようにタグでラベル付けすることができる。このよう
なタグは、ＵＧ規則定義ではスラッシュ記号（「／」）
の後に現れる。

【００５８】ＵＧパターン中でクリーネ・プラスまたは
クリーネ・スターが使用されるために任意の多数の一致
が許容されるとき、そのようなパターンの値を使用する
と、１つの要素しか一致せず、あるいはどの要素にも一
致しないパターンとは異なる機能が得られる。ＵＧコン
パイラ３５０は、単にパターンの標準名（またはそのパ
ターンに関連するタグ）を使用することによって、クリ
ーネ演算子に最後に一致したＵＧパターンへの参照を可
能にすることにより、この複雑さに適応する。オーグメ
ンテーションは、パターン名（または関連するタグ）を
使用して、それにアスタリスク（「^*」 ）を追加するこ
とによって、すべての一致の網羅的なリストにアクセス
することができる。続いて、スター付きの名前を使用す
る試験または割当ては、一致したパターンが以前に一致
した順序で、前記各パターンにアクセスするループとし
て、コンパイルされる。

【００５９】タグ 規則名の場合と同様に、パターン中の個別の要素にタグ
付けし、それによって、パターン内の要素を交互に参照
する他の方法を提供することができる。したがって、規
則中の所定の特徴（たとえば、ｓｅｍ＝ａｐｐｌｉｃａ
ｔｉｏｎ）によって辞典中の１組の語を参照できるのと
まったく同じように、タグによって、規則中の１組の要
素を参照することができる。タグ付けされた１つの例を
以下に示す。 {nameSent:=((“I"/pn“am")｜(“my"/pn“name"“i
s"))sem=firstname;}

【００６０】この場合、（代名詞用の）タグ「ｐｎ」
は、どの語が最終的に認識されるかに関連する特徴−値
対を抽出し、それによって、２つの別々のオーグメンテ
ーションの必要をなくすオーグメンテーションによって
参照することができる。タグは、パターン中の普通なら
同じ要素を区別するためにも使用される。たとえば、ロ
グイン・プログラムでは、３桁のパスワードを言うよう
にユーザに求めることができる。そのような規則の例を
示す。 {password:=cat=number cat=number cat=number:}

【００６１】（おそらく、各番号の数値を抽出するため
に）特定の各番号を別々に参照できるようにするには、
以下のタグを使用する。 {password:=cat=number/num1 cat=number/num2 cat=num
ber/num3:}

【００６２】規則の続くオーグメンテーションでは、
「ｎｕｍ１」、「ｎｕｍ２」、または「ｎｕｍ３」を別
々に参照することが可能である。パターンでは、タグを
適用できるのは、結果として得られる単一の要素だけで
ある。たとえば、以下のパターンでは、タグ「ｔｉｔｌ
ｅ」は最終的に、どちらが最終的に一致するかにかかわ
らず、「ｐｒｏｆｅｓｓｏｒ」または「ｄｏｃｔｏｒ」
に接続される。 {userName:=(“professor"｜“doctor")/title sem=las
tname;}

【００６３】ヘッド ユニファイされた文法を使用して、音声認識プログラム
３２０からの語だけでなく、特徴およびその他の情報を
ユーザ・アプリケーションに転送することも可能であ
る。一般に、大部分のこの特徴は、パターン中で最も重
要な単一の要素から発生する。言語学者は、この要素を
規則の「ヘッド」と呼んでいる。

【００６４】ヘッド宣言は、「ｕｐ」特徴情報を、後で
使用できるように渡す、１つの機構である。パターンの
単一の要素を規則のヘッドとして選択することができ
る。通常、ヘッド要素には、ユーザ・アプリケーション
に転送する必要がある大部分の特徴が関連付けられてい
る。たとえば、後述の名前文規則例で、「ｆｉｒｓｔｎ
ａｍｅ」は、以下に示したヘッドとして宣言することが
できる。

【００６５】 {nameSent:=((“I"“am")｜(“my"“name"“is"))sem=firstname; head firstname; }

【００６６】名前が文の最も重要な部分なので、「Ｉ
ａｍ」句および「ｍａｙ ｎａｍｅｉｓ」句が基本的に
文の意味に寄与しないことに留意されたい。

【００６７】たとえば、ＵＧ辞典が以下の項目を含むと
仮定する。 (bob ((cat.proper_noun)(sem.firstname)(userid.rjon
es))) (is ( (cat.v)(root .be)....) (my ( (cat.pronoun)(sem .owner))) (name ( (cat.n)))

【００６８】また、ユニファイされた文法がトップ・レ
ベル文を含むと仮定する。 {top-level:=nameSent; }

【００６９】文「Ｍｙ ｎａｍｅ ｉｓ Ｂｏｂ」を、
この実施例の音声インタプリタ３００を通過させること
によって、以下の特徴値対出力リストが得られる。 cat: proper_noun sem: firstname userid:rjones heads:(nameSent firstname)

【００７０】「Ｂｏｂ」に関連する特徴および値しかユ
ーザ・アプリケーションには伝搬しないことに留意され
たい。これは、ｎａｍｅＳｅｎｔのヘッドに関連する特
徴がトップ・レベル文に伝搬し、トップ・レベル文に関
連する特徴がＮＬプロセッサ３３０によって出力される
からである（ヘッド要素に関連する特徴以外の特徴の伝
搬については、「割当て」と題する以下の節も参照され
たい）。

【００７１】ある種の語シーケンスでは、ユーザ・アプ
リケーションへの移行を必要とする情報がない。たとえ
ば、文に意味を追加しない、文の始めまたは終りにある
ていねい句がそうである。以下に示したように、「ヘッ
ドなし」宣言は、規則の特徴が伝搬されないことを明示
的に宣言する。 {top-level:=loginSentence[politePhrase]; head loginSentence; } ... {politePhrase:=([“if"“you"]“please")|“thanks"; nohead }

【００７２】規則のパターンが単一の要素しかもたない
場合には、ヘッドを宣言する必要はない。ヘッドはその
要素であると仮定される。同様に、パターンが再帰的な
ものである（すなわち、規則名が規則のパターンに現れ
る）場合、ヘッドは、再帰的要素であると仮定される。
あいまいなケースでは、パターンが複数の要素を含み、
ヘッドなし宣言がある場合、ヘッドなし宣言が仮定さ
れ、規則から特徴が伝搬することはなくなるので、ヘッ
ド宣言またはヘッドなし宣言を含むことが望ましい。

【００７３】再帰的入れ子 この実施例では、ＵＧ記述は、ＮＬパターンの簡単な入
れ子および再帰的入れ子もサポートする。したがって、
ＵＧ規則は、他のＵＧ規則を定義するＵＧパターンによ
って参照することができる。プリアンブルおよび名前に
関する以下の例はこの機能を示す。 {IPreamble:=“I"“am";} {myPreamble:=“my"“name"“is";}

【００７４】この例を継続して、以下のような１組の名
前規則を定義する。 {userName/full:=sem=firstname[sem=lastname];} {userName/title:=[“professor"｜“doctor"]sem=last
name;}

【００７５】次に、他のＵＧ規則中のｕｓｅｒＮａｍｅ
を参照する。 {nameSent:=(IPreamble｜myPreamble)/preamble userNa
me;}

【００７６】このように上記のＵＧ規則を組み合わせて
使用すると、以下の有効な文が得られる。 Ｉ ａｍ Ｂｏｂ Ｍｙ ｎａｍｅ ｉｓ Ｂｏｂ Ｉ ａｍ Ｂｏｂ Ｊｏｎｅｓ Ｍｙ ｎａｍｅ ｉｓ Ｐｒｏｆｅｓｓｏｒ Ｊｏｎｅ
ｓ

【００７７】再帰的に定義されたＵＧ規則を使用する
と、あらゆる組合せを明示的に列挙することなしに、任
意の繰返し語実現値を定義するのに適した柔軟なＵＧ規
則が得られる。

【００７８】いくつかの実施例で、再帰的入れ子は、特
定の音声認識プログラムに必要なＳＲ文法形式ではサポ
ートされない。このような場合、ＵＧコンパイラ３５０
は、ＵＧ文法によって必要とされる再帰を個別のケース
をカバーする明示的に定義された１組のＵＧ規則に拡張
する。再帰的定義は理論的には、ある種の要素の無限繰
返しを可能にするが、実施される拡張はグローバル宣言
によって制限される。

【００７９】試験 試験は、パターンで可能なものよりも強力に規則を制限
する方法である。パターンで直接使用できる所定の特徴
は４つだけでなので（ｃａｔ、ｓｅｍ、ｗｏｒｄ、およ
びｒｏｏｔ）、試験は、ユーザ定義特徴または複数の所
定の特徴に関する検査する方法である。

【００８０】語、具体的には、音声の異なる部分での使
用度に依存する意味をもつ語の複数の所定の特徴に関す
る試験することが必要になることがある。たとえば、ア
プリケーション名を参照する語（たとえば、ｍａｉｌ、
ｌｏｇｉｎ）は、動詞の意味を有することもできる。し
たがって、語の正しい意味の一致を保証するには、一方
の特徴をパターンに含め、他方の特徴を試験に含めるこ
とによって、２つの所定の特徴に関する試験を実施する
ことができる。

【００８１】 {applSentence:=[“switch"“to"]sem=application[politePhrase]; head application; application.cat='n; }

【００８２】上記の例では、試験（ａｐｐｌｉｃａｔｉ
ｏｎ．ｃａｔ＝’ｎ）は、「パターンｓｅｍ＝ａｐｐｌ
ｉｃａｔｉｏｎに一致する語のｃａｔ特徴は名詞であ
る」と翻訳される。オーグメンテーションにリテラル値
が現れる場合、リテラル値の前に単一引用符が来ること
に留意されたい。

【００８３】（ｓｅｍ＝ａｐｐｌｉｃａｔｉｏｎと同様
に）パターンが所定の特徴を含むときは必ず、等号の後
に来る名前（たとえば、ａｐｐｌｉｃａｔｉｏｎ）を使
用することによって、試験オーグメンテーションまたは
割当てオーグメンテーション中のパターンのこの部分に
対する参照を行うことができる。次いで、ドット構文を
使用して、その要素の任意の特徴を参照する。たとえ
ば、「ａｐｐｌｉｃａｔｉｏｎ．ｃａｔ」は、パターン
「ｓｅｍ＝ａｐｐｌｉｃａｔｉｏｎ」に一致する語のｃ
ａｔ特徴を参照する。これは、「ｍａｉｌ」、「ｃａｌ
ｅｎｄａｒ」、「ｒｅｌｏｄｅｘ」などのｃａｔ特徴で
あってよい。

【００８４】特徴の値に関して試験するだけでなく、特
徴が存在するかどうかを試験することも可能である。た
とえば、規則によって、「ｔｈｅ ｆｉｒｓｔ ａｐｐ
ｌｉｃａｔｉｏｎ」、「ｔｈｅ ｓｅｃｏｎｄ ｐｒｏ
ｇｒａｍ」、「ｔｈｅ ｔｈｉｒｄ ｏｎｅ」などのシ
ーケンスが可能になる。この規則では、任意選択で、
「ｔｈｅ」の後に数が来て、その後に対象（他の規則で
は、語「ａｐｐｌｉｃａｔｉｏｎ」の同義語と定義され
る）が来ることが可能であり、かつこの規則は、以下に
示すように、数を序数に制限する試験を含むことができ
る。

【００８５】

【００８６】上述の試験が可能であるのは、例のＵＧ辞
典に示したように、基数（１、２、３など）の基数特性
が「真」にセットされるように数が定義されるからであ
る。

【００８７】順序数（ｆｉｒｓｔ、ｓｅｃｏｎｄ、ｔｈ
ｉｒｄなど）では基数特徴は定義されない。したがっ
て、パターン中で順序数だけを使用するには、基数特性
が「真」にセットされていないことを確認する検査を行
う。そのような試験は、特殊な値「ｎｉｌ」を使用して
行うことができる。以下に示す不等号（！＝）試験演算
子を使用して同じ試験を行うこともできる。 {phrase:=[“the"]cat=number object; head object; number.cardinal!=t; }

【００８８】ＵＧ辞典では、単一の値ではなく１組の値
を特徴に割り当てることも可能である。たとえば、ログ
イン・アプリケーションは、同じ名前を有する多数のユ
ーザを処理する必要があることがある。ＵＧ辞典中の名
前に関する項目の一例は以下のとおりである。

【００８９】 (bob ( (cat.proper_noun) (sem.firstname) (userid bsmith rjones bmcbride) ) ) (jones ( (cat.proper_noun) (sem.lastname) (userid ajones bjones kjones rjones tjones) ) )

【００９０】ユーザ・アプリケーションでは、後に姓が
続く名前を受理する規則は以下のようにコード化するこ
とができる。 {userName/full:=sem=firstname sem=lastname;}

【００９１】この規則が名前と姓の任意の組合せを一致
させないようにするには、名前のｕｓｅｒｉｄ値と姓の
ｕｓｅｒｉｄ値の共通部分があるかどうかを検査する試
験を追加することができる。

【００９２】一例を示す。

【００９３】セット共通部分演算子（〜＝）は、フィー
ルド値の一致に関する検査を行うために使用される。こ
の例では、値「ｒｊｏｎｅｓ」が名前ｕｓｅｒｉｄ特徴
と姓ｕｓｅｒｉｄ特徴の両方に関連するので、名前「Ｂ
ｏｂ Ｊｏｎｅｓ」はこのパターンに一致する。「Ｔｏ
ｍ Ｊｏｎｅｓ」は、「Ｔｏｍ」に関するこの辞典項目
が与えられている場合、このパターンに一致しない。

【００９４】

【００９５】要するに、「試験」オーグメンテーション
は、ＵＧパターンのＢＮＦ定義によって達成できるより
も強力にＵＧ規則を制限し、すなわち、「試験」オーグ
メンテーションは、ＵＧパターンで定義できる限られた
１組の制約を上回る追加制限を表現する機構を提供す
る。たとえば、複数の特徴を有する語を試験するＵＧ規
則では、（１つの所定の特徴のうちの必要な明示的な値
である）１つの特徴はＵＧパターン内に含まれ、残りの
特徴はＵＧ規則の試験オーグメンテーションとして含ま
れる。同様に、パターンが規則名を含む場合、試験オー
グメンテーションによって、指定された規則の以前の適
用例の特徴の追加試験が可能になる。したがって、さら
に具体的な例では、ＵＧ規則に「ｃａｔ＝ｎ」が現れた
とき、ＵＧコンパイラ３５０は、「ｎ．ｓｅｍ＝’ａｐ
ｐｌｉｃａｔｉｏｎ；」などの試験オーグメンテーショ
ンを、（範疇に対するＵＧ規則参照から）その語が名詞
でなければならないことを意味すると解釈し、かつその
意味範疇が「ａｐｐｌｉｃａｔｉｎ」でなければならな
いことを意味すると解釈する。

【００９６】最後に、複雑すぎてＵＧ記述の正規宣言制
限言語を使用しても表現できない試験オーグメンテーシ
ョンは、Ｌｉｓｐで書かれた述語として表すことができ
る。たとえば、ｔｅｅｎである数に関する規則はＬｉｓ
ｐ試験として実施することができる。 {teen:=cat=number; lispp(and(<12(get-v-p number numval)) (>20(get-v-q number numval))); }

【００９７】上記の例で、Ｌｉｓｐ表現が「真」である
のは、数の値が１３ないし１９の範囲に入る場合だけで
あることに留意されたい。

【００９８】割当て 割当ては、ヘッド宣言によってコピーされる特徴−値対
を補助する機構を提供する。以下の例を想起されたい。 {nameSent :=((“I"/pn“am")|(“my"/pn“name"“is"))sem=firstname; head firstname; }

【００９９】この場合、パターンｓｅｍ＝ｆｉｒｓｔｎ
ａｍｅに一致した語に関連するすべての特徴および値
は、「トップ・レベル」ｎａｍｅＳｅｎｔに対して設定
された特徴−値まで伝搬する。どのプリアンブル句を使
用するかに応じて異なるフィードバックをユーザ・アプ
リケーションに提供することが望ましいと仮定する。こ
の場合、どの代名詞（「Ｉ」または「ｍｙ」）が受け取
られたかに関する情報をユーザ・アプリケーションに渡
す必要がある。以下のものは、この追加情報をヘッドに
関連付ける割当て文の一例である。 {nameSent:=((“I"/pn“am")|(“my"/pn“name"“is"))sem=firstname; head firstname; pronoun:=pn.word; }

【０１００】この割当てでは、「ｐｒｏｎｏｕｎ」と呼
ばれる新しい特徴が生成された。この特徴の値は「Ｉ」
または「ｍｙ」である（ｐｎ．語は、ｐｎタグを含む要
素の語特徴を意味する）。したがって、話者１０５が
「Ｍｙ ｎａｍｅ ｉｓ Ｂｏｂ」と言った場合、その
結果ＮＬプロセッサ３３０から得られる特徴−値リスト
は以下のようなものになる。 cat: proper_noun sem firstname userid:rjones pronoun:my heads:(nameSent firstname)

【０１０２】割当てを使用すると、新しい特徴−値対を
生成することも、あるいは、最初の割当てまたはヘッド
定義によってすでに設定されている特徴の値を書き換え
ることもできる。割当ては、追加情報をユーザ・アプリ
ケーションに伝搬させる必要があるとき必ず使用され
る。この実施例では、例えば、ｅメールからカレンダ・
マネージャへのアプリケーションの変更に必要な追加情
報には、新しい特徴「ｃｏｍｍａｎｄ」と、語「ｃａｌ
ｅｎｄａｒ」に関連するすべての特徴が含まれる。既存
の特徴−値対がまだ存在していないかどうか、すなわ
ち、割当てによって、以前に設定された値が上書きされ
ないかどうかに応じて、割当てを条件付きにすることが
望ましいこともある。ユニファイされた文法では、条件
付き割当ては、「ソフト割当て」と呼ばれ、ソフト割当
て演算子「∧＝」によって表される。一例を示す。 ＵＳＥＲＩＤ ∧＝’ｉｍｐｌｉｃｉｔ；

【０１０３】（ｖ）ＵＧ記述のユニファイされた文法へ
の変換 様々な入力ファイル、すなわち、ＵＧ辞典およびＵＧ記
述の構文について説明したが、次に、ＵＧベースの音声
インタプリタ３００の様々な構成要素の動作について詳
細に説明する。図３および図６は、音声インタプリタ３
００のブロック図である。図７、８は、ＵＧベースの音
声インタプリタ３００の初期設定シーケンスを示すハイ
・レベル・フロー・チャートである。上述のように、Ｕ
Ｇコンパイラ３５０は、音声認識プログラム３２０およ
びＮＬプロセッサ３３０によって必要とされる出力ファ
イル、すなわち、ＳＲ文法およびＮＬ文法を生成してそ
れぞれの初期設定シーケンスを完了する責任を負う。

【０１０４】パーサ４５５は、ＵＧ記述中のＵＧ規則定
義を受け取り、この定義をＬＩＳＰフォーマットに変換
し、ユニファイされた文法としてＵＧコンパイラ３５０
に出力する。この変換は、構文的変更に限られ、すなわ
ち、ＵＧ規則定義の意味は元のままである。ユーザ・ア
プリケーションに応じて、１つまたは複数のＵＧ記述が
独立に任意の順序で構文解析される。その結果得られる
ユニファイされた文法はＵＧコンパイラ３５０に提供さ
れ、ＵＧコンパイラは、定義されているＵＧ規則に基づ
いて内部ＳＲ文法有限状態構造を生成する。ＵＧコンパ
イラ３５０は、ＢＮＦ定義およびＢＮＦオーグメンテー
ションを、ＮＬプロセッサ３３０によって必要とされる
フォーマットに修正する。

【０１０５】（ｖｉ）辞典およびユニファイされた文法
のコンパイルによるＳＲ文法の生成 この実施例で、音声認識プログラム３２０によって必要
とされるＳＲ文法は、オーグメンテーションを含むこと
も、あるいは、辞典から得た特徴を使用することもでき
ないので、オーグメンテーションなしの適当なＳＲ文法
を生成するには後述のステップが必要である。

【０１０６】第１に、ＵＧコンパイラ３５０は、ＵＧ語
項目を含むＵＧ辞典をロードし、語項目の完全な内部形
を作成する形態素拡張子を生成する。ＵＧコンパイラ３
５０は次いで、文法規則および内部語項目を使用して、
音声認識プログラム３２用のＳＲ文法の部分を生成す
る。

【０１０７】ＵＧ辞典中の各語のあらゆる形を定義する
必要をなくすために、語彙プロセッサ３５０ａは、ＳＲ
文法用の（一次的な）許容される語を生成するとき、許
容される語の様々なカテゴリ、たとえば、名詞、形容
詞、動詞に関する適当な派生形も生成する。たとえば、
すべての名詞に対して複数形が合成され、形容詞の２つ
の形、すなわち、比較級（たとえば、ｃｏｌｄｅｒ、ｂ
ｉｇｇｅｒ）および最上級（たとえば、ｃｏｌｄｅｓ
ｔ、ｂｉｇｇｅｓｔ）が生成される。また、各動詞ごと
に、派生された４つの代替形、すなわち、単純過去形
（たとえば、Ｉ ｃｏｕｎｔｅｄ）、過去分詞（たとえ
ば、Ｉ ｈａｖｅ ｃｏｕｎｔｅｄ）、現在分詞または
「ｉｎｇ」形（たとえば、Ｉ ａｍ ｃｏｎｔｉｎｕｉ
ｎｇ）、および三人称単数形（たとえば、Ｈｅ ｃｏｕ
ｎｔｓ）がある。上述の特殊な特徴「ｉｒｒｅｇｕｌａ
ｒ」を使用して、派生形の生成の結果得られる拡張子が
制御され、すなわち、誤った派生形が避けられることに
留意されたい。

【０１０８】これに対して、特殊な特徴は、コンパイル
された後、音声認識プログラム３２０に出力されるＳＲ
文法には含まれない。その代わり、「ｃｏｎｔｒａｃｔ
ｉｏｎｓ−ｏｆ」など特殊な特徴によって、語彙プロセ
ッサ３５０ａは、特殊な処理を必要とする語項目を生成
する。

【０１０９】「ｃｏｎｔｒａｃｔｉｏｎｓ−ｏｆ」特徴
を有する語は、その各構成要素「語」がおそらく、音声
の異なる部分であるために、構文分析および意味分析向
けの単一の語とみなすことができないので、特殊な処理
を必要とする。したがって、収縮を構成する個別の語の
シーケンスを定義することにより、「ｃｏｎｔｒａｃｔ
ｉｏｎ−ｏｆ」特徴によって、ＵＧコンパイラ３５０
は、ＮＬ文法における収縮された音声の拡張形を構成し
て収縮形をこの拡張形に置き換え、拡張形に基づく規則
を使用し、しかもＳＲ文法における収縮形に基づく音声
を使用することができる。たとえば、「ｄｉｄｎ’ｔ」
を「ｄｉｄ ｎｏｔ」の収縮形として定義し、それによ
って、「ｄｉｄｎ’ｔ」が、１語として聞き取られる
が、続いて、２語と同様に処理されるようにすることが
できる。

【０１１０】次に、ＵＧコンパイラ３５０は、ユニファ
イされた文法を介して提供された定義済みのＵＧ規則に
基づいて内部ＳＲ文法有限状態構造を構成する。ＵＧコ
ンパイラ３５０は、ＳＲ文法におけるＳＲ規則を定義す
ることによって各ＵＧ規則の等価物を生成し、各ＳＲ規
則には規則名が割り当てられる。この規則名は、ＵＧ規
則から導出され、固有のものであり、あるいは、名前と
タグが共に固有の規則識別子を形成するように名前に関
連付けられた固有のタグを有する。固有の規則名または
タグは、ＵＧ規則の書込みおよびデバッグが容易になる
ように、ＵＧ規則の代替パターンと前記名前を共用する
各規則を識別する。

【０１１１】ＵＧコンパイラ３５０は、コンパイルすべ
きＵＧ文法の主要な各規則を識別し、続いて、各ＵＧ規
則の各部分を処理することによって、ＳＲ文法を生成す
る。各ＵＧ規則の各部分によって、結果として得られる
ＳＲ文法において対応するＳＲ規則が生成される。この
ＳＲ規則は、各部分の試験オーグメンテーションに対応
するできるだけ多くの許容される語またはシーケンスを
有する。言い換えると、オーグメンテーションを含むＵ
Ｇ規則は、オーグメンテーション試験の各結果ごとに、
主要な各ＳＲ規則内の代替規則として拡張される。さら
に、代替規則は、他の試験に依存する場合、最終的に、
対応する許容される語またはシーケンスを参照する、１
組のＢＮＦ定義を有する（オーグメンテーションなし
の）主要なＳＲ規則によってあらゆるＵＧ規則を表すこ
とが可能になるまで拡張される。（オーグメンテーショ
ンを含む）複雑なＵＧ規則を（オーグメンテーションな
しの）簡単なＳＲ規則に変換するこのプロセスをＵＧ規
則の「辞典化」と呼び、すなわち、ＵＧ文法は、他の簡
単な規則と、（拡張内部形の）辞典に依存する形に変換
される。

【０１１２】対応する簡単な（ＳＲ）規則の許容範囲が
大きすぎるとき、ＵＧコンパイラ３５０は、その規則
を、許容される語シーケンスの論理和に変換し、すなわ
ち、ＳＲ規則は、１つの複雑なＵＧ規則によって定義さ
れる少なくとも２つの許容される（すなわち、文法的に
許容される）語シーケンスに対応する。たとえば、ユー
ザ・アプリケーション用のログイン・シーケンスで、ユ
ーザの許容される姓名のリストは、「Ｂｏｂ Ｊｏｎｅ
ｓ」、「Ｊａｎｅ Ｓｍｉｔｈ」、「ＪａｎｅＪｏｎｅ
ｓ」、および「Ｐｅｔｅ Ｂａｋｅｒ」に限られる。代
替姓名を定義するそのようなアプリケーション用のＵＧ
文法規則は、以下のようにコード化することができる。

【０１１３】対応するＵＧ辞典には、以下の項目および
特徴がある。

【０１１４】ＵＧコンパイラ３５０は、上記のＵＧ規則
を使用して、それぞれの名前および姓に関連するユーザ
ＩＤを比較し、ＳＲ文法における「＄ｆｕｌｌｎａｍ
ｅ」に関する以下の定義を生成する。 $fullname:($firstname_eq_userid_bobjones$lastname_eq_userid_ bobjones｜ $firstname_eq_userid_janesmith $lastname_eq_userid _janesmith｜ $firstname_eq_userid_janejones $lastname_eq_userid _janejones｜ $firstname_eq_userid_petebaker $lastname_eq_userid _petebaker); $firstname_eq_userid_bobjones:Bob; $lastname_eq_userid_bobjones:Jones; $firstname_eq_userid_janesmith:Jane; $lastname_eq_userid_janesmith:Smith; $firstname_eq_userid_janejones:Jane; $lastname_eq_userid_janejones:Jones; $firstname_eq_userid_petebaker:Pete; $lastname_eq_userid_petebaker:Baker; $firstname:(Bob｜Jane｜Pete) $lastname:(Jones｜Smith｜Baker) 続いて、簡単なＳＲ規則は「＄ｆｕｌｌｎａｍｅ」を参
照することができる。

【０１１５】図９は、主要なＵＧ規則をＳＲ規則に変換
するためにＵＧコンパイラ３５０によって使用される方
法を示すフロー・チャートである。主要な各ＵＧ規則の
あらゆる部分が、試験オーグメンテーションを表す簡単
な規則として辞典化され、あるいは書き換えられた後、
主要な各ＳＲ規則をその構成要素規則の論理和として定
義する、ＳＲ文法用の新しいＳＲ文法定義が生成される
（ボックス６２０）。この論理和によって、主要なＵＧ
規則から導出された簡単な規則のすべての定義から１つ
の定義を選択することができる。

【０１１６】規則パターンに規則名（たとえば、「ｅｍ
ａｉｌ」）が定義されているが、その規則名に適用され
る追加試験（たとえば、「ｅｍａｉｌ．ｃａｔ＝’
ｖ」）があり、すなわち、その規則名が辞典中の定義と
純粋に同じものではない場合、非辞典規則構成要素と、
最初の規則構成要素およびすべての試験オーグメンテー
ションの適用を記述する規則名との間の関連付けが形成
される（ボックス６３０）。次に、ＵＧコンパイラ３５
０は、同じ規則名をもつ、ＳＲ文法における既存の規則
に関する検査を行う。同じ名前を有するＳＲ規則が存在
する場合、「新しい」規則はすでに、ＳＲ文法に定義さ
れており、次の処理は必要とされない。一方、その規則
名が以前に定義されなかった場合、すべての規則制限
が、新しい規則に組み込まれ、かつこれらの制限を使用
して、ＵＧ辞典中の各語との突合せによる試験を行い、
ＳＲ文法において新しいＳＲ規則の辞典化定義が生成さ
れる（ボックス７００）。規則構成要素に（単なる語で
はなく）他の規則への参照が含まれる場合、辞典化プロ
セスは、参照される規則の辞典化も含む。

【０１１７】図１０および図１１は、主要なＵＧ規則の
一部（最初にＵＧ規則定義から導出されたもの）を辞典
化し、同時に、ＳＲ文法を生成するために、ＵＧコンパ
イラ３５０によって使用される方法を示すフローチャー
トである。ＵＧ構成要素３５０は、規則構成要素をコン
パイルするためにまず、ユニファイされた文法における
ＵＧ規則のパターンに現れる特定の規則構成要素に関連
するすべてのオーグメンテーションを収集する（ボック
ス７１０）。１つまたは複数のオーグメンテーションが
見つかった場合、そのオーグメンテーションに基づいて
新しい規則名が生成される（ボックス７２０）。

【０１１８】オーグメンテーションが見つからなかった
場合、パターンのこの部分に処理は必要とされない。逆
に、オーグメンテーションが見つからず、規則制限が既
存の規則名を参照せず、すなわち、ＵＧ規則制限がその
代わりに、特徴を参照する場合、規則制限の記述に基づ
いて、新たに提案された規則名が生成され、新しい規則
が、この制限を満たす語または語シーケンスの集合とし
て定義される（ボックス７３０）。

【０１１９】次に、ＵＧコンパイラ３５０は、構成して
いるＳＲ文法の部分に、同じ名前をもつ既存の簡単な規
則が含まれるかどうかを検査する（ボックス７５５）。
規則名がすでに存在する場合、この規則構成要素に対す
る次の処理は必要とされない。しかし、その規則がまだ
定義されておらず、特徴値がＵＧ辞典から導出される場
合、特徴が、ＵＧ辞典からコピーされるだけでなく、場
合によっては、任意の規則の「動作」オーグメンテーシ
ョン（割当て）によって割り当てられるかどうかを決定
する定義が前述のように行われ、ＵＧコンパイラ３５０
は、この規則の完全な１組の部分定義内の宣言動作と、
Ｌｉｓｐによって実施される動作の両方、および上向き
にこの規則のパターンの他の構成要素に値を渡す規則中
の宣言動作と、Ｌｉｓｐによって実施される動作の両方
を含め、割当ての探索を開始する（ボックス８００）。

【０１２０】図１２および図１３は、規則の継承された
すべての特徴割当てを見つけるためにＵＧコンパイラ３
５０によって使用される方法８００を示すフローチャー
トである。この探索ステップは、パターン中に他の規則
名が含まれない規則しか残らなくなり、すなわち、ＵＧ
コンパイラが「再帰的に拡張された１組の規則」を使用
するようになるまで繰り返される。値が導出された規則
は、規則ヘッドからの経路をトレースしてその規則のす
べての部分規則を見つけ、次いで、各部分規則に対して
このプロセスを再帰的に繰り返すことによってアクセス
できるようになる。探索は、パターンに辞典要素しか現
れなくなったため、あるいは、明示的な「ヘッドなし」
宣言のために、「ヘッド」がなくなったときに終了す
る。

【０１２１】この探索で特徴の割当てが見つからなかっ
た場合、そのような規則特徴は、ＵＧ辞典中の語に関連
する最初の特徴値から最終的に導出されたことが分か
る。ＵＧコンパイラ３５０は次いで、ＵＧ辞典中のすべ
ての語の意味を走査して、この規則構成要素に関して表
されたすべての規則制限に従う特徴値を収集する（ボッ
クス７６５）。特徴値対の各組ごとに、規則制限・特徴
値対の記述を使用して、新しい規則名が生成される。特
徴（たとえば、「ｅｙｅ−ｃｏｌｏｒ」）は多数の異な
る値を有することができるが、あらゆる特徴−値対（た
とえば、「ｅｙｅ−ｃｏｌｏｒ＝ｂｌｕｅ」）が固有の
ものであることに留意されたい。

【０１２２】しかし、規則名が新たに作成され、すなわ
ち、規則名が以前に定義されておらず、かつ規則の動作
において試験済みの特徴に値が割り当てられたが、その
動作が、一定値、または最初に一定値から導出された他
の特徴から取り出された値にその試験済み特徴を割り当
てた場合、その動作オーグメンテーションは、その特徴
値が最初に語彙源から導出されたときと同様に処理さ
れ、処理は、割当て値を、辞典から取り出された場合と
同様に使用して継続し、新しい簡単な規則が生成される
（ボックス７８０）。

【０１２３】その動作が他の規則の値を参照した場合、
その参照は、一定値、または他の語彙規則構成要素に対
する参照が検索されるまで、すべてのコピー層を介して
追跡される。そのような一定値が見つかった場合、その
値は、直接辞典によって割り当てられた場合と同様に処
理される。次に、新たに作成された名前は、一定値を有
する新たに定義された規則に採用され、それによって、
収集された特徴に対応する語が許可される。これで、こ
の規則構成要素の処理が完了した（ボックス７７０）。

【０１２４】逆に、規則名が新たに作成され、すなわ
ち、規則名が以前に定義されておらず、ある部分規則の
「動作」によって特徴値が割り当てられ、その動作が、
一定値に設定されておらず、他の特徴にも関連付けられ
ていない場合、新たに作成された規則名が採用される
（ボックス７８５）。この場合、この特定の特徴値に関
連する試験オーグメンテーションは無視され、規則構成
要素の処理は完了したと宣言される。これは、ＵＧコン
パイラ３５０によって試験オーグメンテーションを事前
に計算して最終ＳＲ文法形に変換し、すなわち、完全に
分解することができず、したがって、場合によっては、
ＵＧ試験が削除した他の語シーケンスを含め、最初のＵ
Ｇ規則が許容するあらゆる語シーケンスを許容する規則
がもたらされる例である。

【０１２５】複雑な規則を簡単な規則で完全に置き換え
ることができないときは必ず、その代わりに、より許容
範囲の広いバージョンが使用される。たとえば、ＵＧコ
ンパイル時に試験オーグメンテーションが計算できない
とき、この関連特徴値は「真」にセットされる。さらに
具体的な例では、「曜日」要素と「日付」要素とを含む
パターンを含む複雑なＵＧ規則をコンパイルする際、月
および年の予備知識なしで「曜日」要素と「日付」要素
が一致するかどうかを事前に判定することはできない。

【０１２６】音声認識プログラム３２０の性能を最適化
するには、ＵＧ制限を他の規則または一定値しか含まれ
ない簡単な試験に分解し、次いで、簡単な各試験を辞典
化した結果を、複合制限を反映するように作成された規
則名をもつ新しい規則として再構成することによって、
ユニファイされた文法の複数のＵＧ規則制限を組み合わ
せる。この分解プロセスは、それぞれ、規則構成要素、
たとえば、等号試験、不等号試験、またはセット・イン
クルージョン試験、またはセット・エクスクルージョン
試験を表す、２つの簡単な一定値を比較することしか試
験に含まれなくなるまで繰り返される。ＵＧコンパイラ
３５０は、ＵＧ規則から導出された簡略化されたこれら
の試験を使用して、辞典を探索し、これらの試験に適合
する語を見つけ、次いで、ＳＲ文法用の対応する１組の
許容される語または句を作成することによって新しい各
規則中の試験を置き換える。

【０１２７】規則の２つの異なる構成要素から導出され
た特徴を比較することが、規則の制限に含まれるとき
は、この分解プロセスの関与の度合いがさらに大きくな
る。ＵＧコンパイラ３５０は、この比較形を辞典化する
ために、上述の分解規則を使用して、各特徴の値を、Ｕ
Ｇ辞典または割当て中の対応する最終的な起点まで追跡
する。次に、ＵＧコンパイラ３５０は、比較すべき２つ
の特徴のそれぞれに関するすべての可能な値を収集し、
それを「マップ」して、置き換えられている規則制限に
対して「真」である組合せを収集する。各「真」の組合
せごとに、新しい記述名をもつ新しい規則が作成され
る。パターンの２つの要素の特徴間の試験を組み込んだ
ユニファイされた文法の（最初の）ＵＧ規則によって、
ＵＧコンパイラ３５０は、上述のペアリング・プロセス
およびマッピング・プロセスによってＳＲ文法において
作成された新しい個別の簡単なＳＲ規則の論理和をとる
（いずれか１つの選択を可能にする）、ＳＲ文法におけ
る対応する規則を生成する。新たに作成された規則名が
すでに定義されている場合、既存の定義はＳＲ文法にお
ける規則に採用され、そうでない場合新しい論理和がそ
の規則用の定義になる。

【０１２８】この実施態様では、「デッド・エンド」に
出会うのは、再構成時にＵＧ規則の特定の部分に特徴値
の「不当な」組合せが残っているときだけである。これ
が起こると、生成された規則は、「生じないストリン
グ」（ＳＷＣＯ）に依存するものとして定義され、それ
によって、その特定の分析経路の障害がフラグによって
示される。続いて、コンパイラ・プロセスの「クリーン
ナップ」フェーズの間、ＵＧコンパイラ３５０は、ター
ゲット音声認識プログラム用の特定のＳＲ文法によって
サポートされる形式の範囲内で「プルーニング」を実行
できる場合、ＳＲ文法中の論理和内の障害フラグ参照の
オカレンスを除去する。特定のＳＲ文法に対する制限の
ために、そのようなＳＷＣＯ文字列がＳＲ文法に残って
いる場合、ＳＷＣＯ文字列を有する規則を「スタブ・ア
ウト」（マスク）するために特殊な「ＳＷＣＯ」定義が
ＳＲ文法に組み込まれる。

【０１２９】最後に、ＵＧコンパイラ３５０は、あらゆ
る主要な規則定義をループし、主要な各ＵＧ規則から生
成されたすべてのＳＲ規則を、ＳＲ文法に組み込めるよ
うに収集する。この実施態様では、結果として得られる
ＳＲ文法内で、ＳＲ規則は、親ＵＧ文法の特定の主要な
各規則名から導出された名前によって構成され、許容さ
れる様々なタグ付き変形例は代替ＳＲ規則定義としてグ
ループ化されることに留意されたい。言い換えると、コ
ンパイル・プロセスの終りに、各代替ＳＲ規則定義ごと
に結果として得られる変形例の論理和がとられて、ＵＧ
文法の主要ＵＧ規則に対応するＳＲ文法における（複
合）「主要」ＳＲ規則が生成される。このステップは、
より小規模なＳＲ文法をもたらし、同時に、認識可能な
規則名を保持してＵＧ記述の発展および維持を助ける。

【０１３０】標準フォーマットがないので、市販の音声
認識プログラム用の入力ファイル・フォーマットでは様
々な異なる形式が使用されている。たとえば、この実施
例では、ＵＧコンパイラ３５０は、音声認識プログラム
３２０用の認識プログラム固有のＳＲ文法（たとえば、
Ｈａｒｋ音声認識プログラム用の．ＨＧファイル）を生
成する。続いて、音声認識プログラム３２０は、ＵＧコ
ンパイラ３５０からのＳＲ文法に基づいて内部ＳＲ状態
マシンを構成する。

【０１３１】（ｖｉｉ）辞典とユニファイされた文法の
コンパイルによるＮＬ文法の生成 ＵＧコンパイラ３５０は、各ユニファイされた文法ごと
に、ＮＬプロセッサ３３０用のＮＬ文法も生成する。上
述のように、ＵＧ辞典中の各語のあらゆる形を定義する
必要をなくすために、語彙プロセッサ３５０ａは、ＮＬ
文法向けの（一次）語を生成するとき、語の様々な範疇
に関する適当な派生形、たとえば、名詞、形容詞、動詞
なども生成する。これに対して、特殊な特徴は、コンパ
イルされた後、ＮＬプロセッサ３３０に出力されるＮＬ
文法に含まれない。

【０１３２】ＵＧコンパイラ３５０は、各ＮＬ規則が、
規則名で始まる、ＮＬ文法における各ＵＧ規則のインス
タンスを生成する。規則名は、ＵＧ規則から導出され、
固有のものであり、あるいは、名前とタグが固有の規則
識別子を形成するように規則名に固有のタグが関連付け
られる。固有のＮＬ規則名またはタグは、各ＮＬ規則を
識別し、同時に、ＵＧ規則を容易に書き込みデバッグで
きるように、ＵＧ規則の代替パターンと主要な名前を共
用する。

【０１３３】「ヘッド」宣言から導出されるＵＧ規則お
よびその結果得られる動作のオーグメンテーションは、
ＮＬプロセッサ３３０による処理の間に使用すべきコー
ド・セグメントとしてコンパイルされる。実際のオーグ
メンテーションがＮＬ処理時に簡単に実行できるので、
ＮＬ文法では、オーグメンテーションの事前コンパイル
は必要とされない。

【０１３４】（ｖｉｉｉ）音声認識プログラムの動作 この実施例では、音声認識プログラム３２０は、７０
Ｆａｗｃｅｔｔ Ｓｔｒｅｅｔ， Ｃａｍｂｒｉｄｇ
ｅ， ＭＡ ０２１３８のＢ．Ｂ．Ｎ．社から入手でき
るＨａｒｋ音声認識プログラムである。他の市販の音声
認識プログラムを入手することができ、当業者によっ
て、ＵＧコンパイラ３５０を、本発明の趣旨から逸脱せ
ずに異なる音声認識プログラムによって動作するように
なすことができる。ＵＧコンパイラ３５０と共に動作す
る市販の音声認識プログラムの例には、Ｔｅｘａｓ Ｉ
ｎｓｔｒｕｍｅｎｔのＤａｇｇｅｒおよびＣａｒｎｅｇ
ｉｅＭｅｌｌｏｎ ＵｎｉｖｅｒｓｉｔｙのＳｐｈｉｎ
ｘ Ｖｅｒ Ｉが含まれる。Ｈａｒｋが市販されている
ので、本発明の原則を示すのに十分な説明を含める。

【０１３５】簡単に言うと、ＵＧコンパイラ３５０によ
って生成されるＳＲ文法は、音声インタプリタ３００の
初期設定時に音声認識プログラム３２０にロードされ
る。次に、音声認識プログラム３２０は、音声の低レベ
ル特性を表し、音声が様々な状況で発話されたときに形
態音素のシーケンスに関係付ける、ベクトル量子化隠れ
マルコフ・モデルを使用して入力音声を一致させる。次
に、音声認識プログラム３２０は、以前にＳＲ文法から
構成されたＳＲ有限状態マシンを使用することによっ
て、最も可能性の高い語シーケンスを生成する。Ｈａｒ
ｋおよびその他の音声認識プログラムが市販されている
ので、音声認識プログラム３２０の詳細な説明および動
作は提示しない。

【０１３６】（ｉｉｘ）ＮＬプロセッサの動作 この実施例では、ＳＷＩＦＴＵＳ（テキスト理解のため
のＦａｓｔｕｓに代わるソフトウェア）と呼ばれるＮＬ
プロセッサ３３０は、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍ
ｓ Ｌａｂｏｒａｔｏｒｉｅｓ， Ｉｎｃ．で作成さ
れ、Ｓｔａｎｆｏｒｄ， ＣａｌｉｆｏｒｎｉａのＳＲ
Ｉ ＩｎｔｅｒｎａｔｉｏｎａｌのＪｅｒｒｙ Ｈｏｂ
ｂｓによって開発されたＦａｓｔｕｓと呼ばれるＮＬプ
ロセッサの文献に基づいて設計されたものである。図４
に示したように、ＮＬプロセッサ３３０は、語彙プロセ
ッサ３３０ａと、パターン認識プログラム３３０ｂと、
任意選択の知識ベース３３０ｃとを含む。

【０１３７】語彙プロセッサ３３０ａは、音声インタプ
リタ３００の初期設定時に、各ワードのすべての意味を
ＵＧ辞典から内部ＮＬ辞典にロードする。ＮＬ文法が、
ＵＧ辞典の語彙情報に対する参照と、ＵＧ文法から得た
オーグメンテーションを含む規則とを含むことに留意さ
れたい。内部ＮＬ辞典は、語彙の意味を定義する簡潔で
拡張可能で小型の構造をＮＬプロセッサ３３０に提供す
る。このようなＮＬ辞典語項目は、ＵＧ辞典の特徴値対
を、一致したＵＧ規則を表すために使用される構造と互
換性がある構造としてコード化する。

【０１３８】上述のように、ある種の語項目、たとえ
ば、「ｃｏｎｔｒａｃｔｉｏｎｓ ｏｆ」は、特殊な処
理を必要とし、ＵＧ文法に対して透過的である特殊なＮ
Ｌ規則に変換される。ＵＧ語項目構造とＮＬ語項目構造
は論理的に類似している。一般ＮＬ辞典と定義域固有Ｎ
Ｌ辞典は共に、複数のユーザ・アプリケーションをサポ
ートする実施態様で一般ＮＬ辞典を共用することから得
られる経済性を推進するためにＵＧコンパイラ３５０に
よって使用することができる。

【０１３９】語彙プロセッサ３３０ａは、拡張可能な１
組の所定の形態素生成ＮＬルーチンも含む。このような
ＮＬルーチンは、定義された不規則形指定によって具体
的に示されない限り、英語形態の所定の１組のＮＬ規則
を使用することによって、入力語彙の最も一般的な派生
形を定義する。派生された各語の意味の根形は、ＮＬパ
ターン内での一致のために維持される。頭字語および代
替スペリングは語項目内に宣言される。この実施態様で
は、単一の概念を表す多重語項目、たとえば、「Ｕｎｉ
ｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ」は、ハ
イフンで区切られた句として入力することができ、その
語がハイフンなしで、すなわち、連続シーケンス中の別
々の語として現れたとき、同じ句を認識する対応するＮ
Ｌ規則が、自動的に生成される。

【０１４０】パターン認識プログラム３３０ｂは、ＮＬ
文法から生成された１組のＮＬパターンを、音声認識プ
ログラム３２０から入力された語と比較する、パターン
認識ルーチンを含む。この実施態様では、ＮＬパターン
は、名前と、パターン本体と、Ｌｉｓｐで表された１対
のオーグメンテーションとを含む、ＮＬ文法から導出さ
れる４つ組である。パターン認識プログラム３３０ｂは
基本的に、縦続される有限状態オートマトン（ＦＳＡ）
ベースのシステムであり、オーグメンテーションを評価
し、同時に、関連する各パターンを突き合わせる。上記
で詳しく説明したように、任意選択度、論理和、クリー
ネ・プラス、クリーネ・スターなど共通式演算子がサポ
ートされる。ＮＬ語パターンは、他のＮＬ語パターンを
再帰的に参照することによって定義できるので、パター
ン認識プログラム３３０ｂは、形式的には（少なくと
も）文脈自由文法（ＣＦＧ）等価物であることに留意さ
れたい。

【０１４１】ＮＬプロセッサ３３０は、この実施例の初
期設定時に、ＡｈｏおよびＵｌｌｍａｎによって発表さ
れたアルゴリズム（「コンパイラの構成」参照）を使用
する実行可能なＦＳＡベースのシステムを生成するよう
に、ＮＬ規則定義を含むＮＬ文法を処理し、ＮＬ文法の
各ＮＬ規則は、主要な規則名に基づくパターン名に関連
付けられる。言い換えると、ＮＬ文法の規則がパターン
認識プログラム３３０ｂにロードされると、対応するＦ
ＳＡが構成される。辞典語項目に対するＮＬパターンの
一致は、ＦＳＡ弧に接続されたコンパイル済みのＬＩＳ
Ｐ関数に変換され、ＬＩＳＰ関数は、パターン認識プロ
グラム３３０ｂが、現行の語の意味の入力と、以前に一
致したＮＬパターンとを、コンパイル済みパターンの
「真」引数として受理した場合に横に移動される。

【０１４２】パターン認識プログラム３３０ｂが、音声
認識プログラム３２０からの入力語シーケンスにＮＬ語
パターンを首尾良く一致させ、すなわち、すべてのパタ
ーン試験が「真」になったとき、ＮＬプロセッサ３３０
は規則の第１組のオーグメンテーションを評価する
（「試験」）。第１組のオーグメンテーションが成功し
た場合、その入力シーケンスは「認識され」、その結果
得られる形が、その規則に関連する第２組のオーグメン
テーションを評価することによって、生成され充填され
る（「動作」）（最初のＵＧ文法からの「ヘッド」動作
が、ＮＬ文法における「動作」オーグメンテーションに
なったことに留意されたい）。次いで、一致の結果は、
他のパターン一致に使用され、その結果に関連する特徴
−値対に沿って進むことができる。このプロセスは、す
べての可能な突合せが行われるまで継続し、その時点
で、「トップ・レベル」パターンとマーク付けされたパ
ターンを返す（これらは、完全な文をカバーするように
設計されたものである）。

【０１４３】パターン認識プログラム３３０ｂは、各
語、その根、その音声部分、その知識ベース・クラスの
試験の組合せ（直接あるいは包摂）、辞典中の特徴−値
対との突合せ、あるいは、上記の試験の否定によって、
入力語シーケンスの語を処理する。認識プログラム３３
０ｂによって、任意の関数がこれらの試験の述語として
働くこともできる。ＮＬパターンの各部を参照するため
にオーグメンテーションによって使用される名前は、Ｎ
Ｌパターン自体から、あるいは、ＮＬパターンの要素に
任意選択のタグを追加することによって、導出される。
また、ＮＬパターンでワイルドカードを使用すれば、音
声認識プログラム３２０によって完全には認識されなか
った入力語シーケンスから主要な特徴を抽出するバック
アップ機構が提供される。「主要な」語を求めることに
よって、ワイルドカードは、音声認識プログラムの現世
代の固有の不正確さを低減するように働くことができ
る。空定義を含む意味構造が、語およびワイルドカード
に関する述語検査が可能になるように、ＮＬ辞典に定義
されていない語項目に関して検査されることに留意され
たい。

【０１４４】パターン認識プログラム３３０ｂは、別々
の「パス」におけるＮＬパターンの複数の突合せもサポ
ートし、第１のパスの後のパスで使用すべき規則は、Ｕ
Ｇ文法における局所宣言でマーク付けされる。１組の第
２パス・パターンは、「第１のパス」パターンによって
一致がもたらされなかったときに使用される。二次（ま
たは三次など）パターンのこの「安全ネット」は一般
に、ＮＬパターンの一次集合よりも「緩やかな」もので
ある。たとえば、ある二次パス・パターンは、「ｅメー
ル」など選択されたキーワードの突合せしか行おうとし
ない。一次パターンによる一致が好ましいので、二次パ
ターンは分離されており、呼び出されるのは、第１のパ
ス・パターンのトップ・レベル一致が失敗した場合だけ
である。

【０１４５】音声認識プログラム３２０は、構成された
ＦＳＡネットワークと、下降形再帰一致アルゴリズムを
適用するオーグメンテーションとを使用して入力語を解
析する、ＮＬプロセッサ３３０に対して発話された許容
される語シーケンスを最も適切に推定する。「トップ・
レベル」と呼ばれる特定のパターンに関して成功した固
有の各一致ごとに、その結果得られるそのパターンの特
徴−値対構造が返される。文全体をカバーすべきである
すべてのパターンは、「トップ・レベル」パターンを一
致させる代替方法として定義され、したがって、これ
は、文全体をカバーするように指定され、かつ「残るも
の」がないように一致を行う規則によって、その結果得
られる特徴−値構造が、アプリケーション翻訳プログラ
ムによって使用できるように返されることを意味する。

【０１４６】任意選択の知識ベース３３０ｃが、１つま
たは複数の知識ベースを含み、簡単な包摂ルーチンおよ
び継承ルーチンをサポートすることに留意されたい。知
識ベースは、一般バージョンと主題固有バージョンの両
方を含み、パターンの試験をサポートするために、意味
クラス、たとえば、「ｄｉｓｐｌａｙ ａｃｔｉｏｎ
ｓ」、「ｄｉｓｐｌａｙ」、「ｓｈｏｗ」、「ｐｒｅｓ
ｅｎｔ」の階層にマーク付けすることなど、辞典に組み
込むのに不適切な意味の一般化を捕捉するために使用す
ることができる。知識ベースは、任意選択であり、一般
に、ＵＧ辞典中の簡単なマーク付けで十分なユーザ・ア
プリケーションでは必要とされない。

【０１４７】（ｉｘ）代替実施例 この実施例では、音声インタプリタ３００は、ユーザ・
アプリケーション・プログラムによって生成されたメッ
セージと、カレンダ・マネージャまたはｅメール・シス
テム、あるいはその両方に記憶されているテキストと
を、ユーザ・アプリケーション用の音声プロンプトおよ
び応答に変換する、音声合成器（図示せず）に結合され
ている。また、ＮＬプロセッサ３３０からのテキスト出
力を、作成された形式、たとえばＡＳＣＩＩで保存する
ことができる。他の実施例では、図３Ｂのブロック図で
示したように、ＳＲ文法とＮＬ文法はそれぞれ、ＳＲコ
ンパイラ３２５とＮＬコンパイラ３３５によって別々に
生成される。他の実施例では、図３Ｃのブロック図に示
したように、音声認識プログラム３２０は、ＮＬプロセ
ッサ３３０からのフィードバックも受け取り、ＮＬプロ
セッサ３３０がたとえば、音声認識プログラム３２０か
らの妥当性検査された語シーケンスを拒否し、妥当性検
査された他の（次に可能性の高い）語シーケンスを送る
ように音声認識プログラム３２０に要求できるようにす
る。これは、音声解釈プロセスと音声認識プロセスを統
合する強力な特徴である。

【０１４８】他の修正も可能である。たとえば、音声メ
ール・システムでは、音声インタプリタ３００が、音声
を再生できるように保存するためにディジタル・アナロ
グ・オーディオ・レコーダに結合される。また、インタ
プリタ３００は、音声合成器に結合され、あるいは、ビ
デオ・オン・デマンド・システムのためにビデオ・プレ
ーヤ／レコーダに結合される。ＵＧコンパイラ３５０に
よって生成される文法を使用できるようになすことがで
きる他のアプリケーションには、速記文字を複写し、手
書きの文字を認識し、あるいは、漢字／日本語文字など
絵文字を認識する音声・絵文字認識システムが含まれ
る。一般に、言語を表す人間が生成した入力は、認識シ
ステムへの入力として使用することができる。

【図面の簡単な説明】

【図１】 従来技術の音声解釈システムのブロック図で
ある。

【図２】 本発明によって汎用ホスト・コンピュータで
実施される音声インタプリタを示す図である。

【図３】 図２の音声インタプリタの主な構成要素を示
す、ブロック図である。

【図４】 音声インタプリタの他の実施例を示すブロッ
ク図である。

【図５】 音声インタプリタの他の実施例を示すブロッ
ク図である。

【図６】 音声インタプリタの主な構成要素と、それら
の構成要素間の様々な入出力を示すブロック図である。

【図７】 音声インタプリタの動作を示す流れ図であ
る。

【図８】 レキシコンおよびＵＧ文法からＳＲ文法を生
成することを示す流れ図である。

【図９】 主要なＵＧ規則をＳＲ規則に変換する方法を
示すフロー・チャートである。

【図１０】 ＳＲ文法を生成するために主要なＵＧ規則
の一部を語彙化する方法を示すフローチャートである。

【図１１】 ＳＲ文法を生成するために主要なＵＧ規則
の一部を語彙化する方法を示すフローチャートである。

【図１２】 規則の継承されたすべての特徴割当値を見
つける方法を示すフローチャートである。

【図１３】 規則の継承されたすべての特徴割当値を見
つける方法を示すフローチャートである。

【符号の説明】

１００ インタプリタ、 １０５ 人間のユーザ、 １
１０ 音響入力装置 １２０ 音声認識プログラム、 １３０ 自然言語（Ｎ
Ｌ）プロセッサ、１３５ ＮＬ記述コンパイラ、１４０
アプリケーション・コマンド翻訳プログラム、２５０
ホスト・コンピュータ、 ２５１ 中央演算処理装置
（ＣＰＵ）、２５２ ホスト・メモリ、 ２５３ ホス
ト・バス制御装置、２６０ ホスト・システム・バス、
２６１ａ モニタ、２６１ｂ キーボード、 ２６１
ｃ マウス、 ２６２ 音響入力装置、２６２ａ アナ
ログ・ディジタル（Ａ／Ｄ）変換器、２６２ｂ マイク
ロフォン、 ２６３ 音響出力装置、２６３ａ ディジ
タル・アナログ変換器（ＤＡＣ）、２６３ｂ オーディ
オ・スピーカ。

Claims (14)

【特許請求の範囲】
1. 【請求項１】 辞典およびユニファイされた文法（Ｕ
   Ｇ）記述を音声認識プログラムを制御する音声認識（Ｓ
   Ｒ）文法に変換する方法であって、辞典が、所定の特性
   を有する複数のＵＧ語項目を含み、ＵＧ記述が、複数の
   ＵＧ規則を含み、各ＵＧ規則が、少なくとも１つのオー
   グメンテーションを含み、ＵＧ規則が文法的に許容され
   る語シーケンスを定義し、前記方法が、メモリが結合さ
   れた中央演算処理装置（ＣＰＵ）と、ＣＰＵに結合され
   たシステム・バスと、音響信号を表すディジタル信号を
   受け取るためにシステム・バスに結合された入力手段と
   を含むシステムの前記メモリに記憶されている複数のプ
   ログラム命令およびデータとして実施される方法におい
   て、 前記複数のＵＧ語項目に対応する前記ＳＲ文法における
   複数のＳＲ語項目を辞典から生成するステップと、 前記ＵＧ規則のオーグメンテーションに対応する、前記
   ＳＲ文法における複数の許容されるＳＲ語シーケンスお
   よび複数のＳＲ規則を辞典およびＵＧ記述から生成する
   ステップと、 前記ＳＲ語項目、前記許容されるＳＲ語シーケンス、前
   記ＳＲ規則をメモリに記憶するステップとを含むことを
   特徴とする方法。
2. 【請求項２】 さらに、前記複数のＵＧ語項目に対応す
   る前記ＳＲ文法における複数の派生語形を生成するステ
   ップを含むことを特徴とする請求項１に記載の方法。
3. 【請求項３】 前記音声認識プログラムに結合されたＮ
   Ｌプロセッサを制御する自然言語（ＮＬ）文法を生成す
   るステップを含むことを特徴とする請求項１に記載の方
   法。
4. 【請求項４】 前記選択された語の所定の特性をＮＬプ
   ロセッサに伝搬させるステップを含むことを特徴とする
   請求項７に記載の方法。
5. 【請求項５】 辞典およびユニファイされた文法（Ｕ
   Ｇ）記述に対応する音声認識（ＳＲ）文法によって制御
   される音声認識プログラムによってディジタル化音響信
   号を認識する方法であって、辞典が、所定の特性を有す
   る複数のＵＧ語項目を含み、ＵＧ記述が、複数のＵＧ規
   則を含み、各ＵＧ規則が、少なくとも１つのオーグメン
   テーションを含み、ＵＧ規則が文法的に許容される語シ
   ーケンスを定義し、前記方法が、メモリが結合された中
   央演算処理装置（ＣＰＵ）と、ＣＰＵに結合されたシス
   テム・バスと、ディジタル化音響信号を受け取るために
   システム・バスに結合された入力手段とを含むシステム
   の前記メモリに記憶されている複数のプログラム命令お
   よびデータとして実施される方法において、 前記複数のＵＧ語項目に対応する前記ＳＲ文法における
   複数のＳＲ語項目を辞典から生成するステップと、 前記ＵＧ規則のオーグメンテーションに対応する、前記
   ＳＲ文法における複数の許容されるＳＲ語シーケンスお
   よび複数のＳＲ規則を辞典およびＵＧ記述から生成する
   ステップと、 自然言語プロセッサに対するディジタル化音響信号に対
   応する妥当性検査された語シーケンスを生成するため
   に、ディジタル化音響信号を前記ＳＲ語項目、前記ＳＲ
   語シーケンス、および前記ＳＲ規則と比較するステップ
   とを含むことを特徴とする方法。
6. 【請求項６】 さらに、前記複数のＵＧ語項目に対応す
   る前記ＳＲ文法における複数の派生語形を生成するステ
   ップを含むことを特徴とする請求項５に記載の方法。
7. 【請求項７】 前記音声認識プログラムに結合されたＮ
   Ｌプロセッサを制御する自然言語（ＮＬ）文法を生成す
   るステップを含むことを特徴とする請求項５に記載の方
   法。
8. 【請求項８】 前記選択された語の所定の特性をＮＬプ
   ロセッサに伝搬させるステップを含むことを特徴とする
   請求項７に記載の方法。
9. 【請求項９】 音声認識プログラムを制御するために、
   辞典およびユニファイされた文法（ＵＧ）記述を音声認
   識（ＳＲ）文法に変換する装置において、辞典が、所定
   の特性を有する複数のＵＧ語項目を含み、ＵＧ記述が、
   複数のＵＧ規則を含み、各ＵＧ規則が、少なくとも１つ
   のオーグメンテーションを含み、ＵＧ規則が文法的に許
   容される語シーケンスを定義し、前記装置が、中央演算
   処理装置（ＣＰＵ）と、ＣＰＵに結合されたメモリと、
   ＣＰＵに結合されたシステム・バスと、音響信号を表す
   ディジタル信号を受け取るためにシステム・バスに結合
   された入力手段とを含むシステム内に組み込まれる装置
   において、、 前記複数のＵＧ語項目に対応する前記ＳＲ文法における
   複数のＳＲ語項目を辞典から生成する語彙プロセッサ
   と、 前記ＵＧ規則のオーグメンテーションに対応する、前記
   ＳＲ文法における複数の許容されるＳＲ語シーケンスお
   よび複数のＳＲ規則を、辞典およびＵＧ記述から生成す
   るシーケンス・規則生成プログラムとを備えることを特
   徴とする装置。
10. 【請求項１０】 さらに、前記音声認識プログラムに結
    合されたＮＬプロセッサを制御するためにＮＬ文法を生
    成する自然言語（ＮＬ）生成プログラムを備えることを
    特徴とする請求項９に記載の装置。
11. 【請求項１１】 さらに、ＵＧ記述をＬＩＳＰフォーマ
    ットに変換する構文解析プログラムを備えることを特徴
    とする請求項９に記載の装置。
12. 【請求項１２】 ディジタル化音響信号を認識する音声
    認識システムにおいて、前記システムが、辞典およびユ
    ニファイされた文法（ＵＧ）記述に対応する音声認識
    （ＳＲ）文法によって制御され、辞典が、特性を有する
    複数のＵＧ語項目を含み、ＵＧ記述が、文法的に許容さ
    れる語シーケンスを定義する複数のＵＧ規則を含み、前
    記システムが、 中央演算処理装置（ＣＰＵ）と、 ＣＰＵに結合されたメモリと、 ＣＰＵに結合されたシステム・バスと、 ディジタル化音響信号を受け取るためにシステム・バス
    に結合された音響入力手段と、 前記複数のＵＧ語項目に対応する複数のＳＲ語項目を辞
    典から生成する語彙プロセッサと、 前記ＵＧ規則のオーグメンテーションに対応する、前記
    ＳＲ文法における複数の許容されるＳＲ語シーケンスお
    よび複数のＳＲ規則を、辞典およびＵＧ記述から生成す
    るシーケンス・規則生成プログラムとを備えることを特
    徴とするシステム。
13. 【請求項１３】 さらに、前記音声認識プログラムに結
    合されたＮＬプロセッサを制御するためにＮＬ文法を生
    成する自然言語（ＮＬ）生成プログラムを備えることを
    特徴とする請求項１２に記載の装置。
14. 【請求項１４】 さらに、ＵＧ記述をＬＩＳＰフォーマ
    ットに変換するパーサを備えることを特徴とする請求項
    １２に記載の装置。