(57)【特許請求の範囲】
【請求項１】
クライアントコンピューティング装置に一体化されて、一乃至複数の発声単語で構成された文を含む連続発声音声を受信し、関連する発声音声信号を発生するサウンド処理回路と、
クライアントコンピューティング装置の一部を構成し、前記発声音声信号からベクトル係数の組である第一の組の音声信号を発生する第一の信号処理回路と、
サーバーコンピューティング装置の一部を構成する第二の信号処理回路と、
前記クライアントコンピューティング装置に結合されたものであって、前記第一の組の音声信号をフォーマット化し、通信チャンネルを通じて、音声発生時にリアルタイムに、前記第二の信号処理回路へ送信する送信回路とを有し、
前記送信回路では、前記第一の組の音声信号が断続することなく連続して送信され、前記第二の信号処理回路では、連続して受信した前記第一の組の音声信号に基づいてベクトル係数の組である第二の組の音声信号が生成され、
前記第一の組の音声信号と前記第二の組の音声信号を生成するのに必要とされる信号処理機能が、前記第一の信号処理回路と前記第二の信号処理回路のそれぞれにおいて利用可能とされた計算リソースに基づいて、前記送信回路で送受信可能な交信チャンネルを通じ前記第一の信号処理回路と前記第二の信号処理回路に割り当てられ、
前記信号処理機能に基づいて、前記第一の信号処理回路での前記第一の組の音声信号の生成と、前記第二の信号処理回路における単語の認識動作及び文の認識動作とが協働して行われることを特徴とする音声認識装置。
【請求項２】
前記第一の信号処理回路で生成される前記第一の組の音声信号が、分散認識システムの処理に基づくデータコンテントを含み、
前記第二の信号処理回路では、前記第一の組の音声信号と前記第二の組の音声信号とから複合音声信号を発生し、
前記第二の信号処理回路に、前記複合音声信号を使用して発声音声の単語の認識を行う単語認識回路が設けられている請求項１記載の音声認識装置。
【請求項３】
前記第二の信号処理回路に、連続発声音声に含まれる文を認識する文認識回路を有する請求項２に記載の音声認識装置。
【請求項４】
前記文認識回路では、予め定義された多数の文から可能性のある文の候補の組を識別し、可能性のある文の候補の組の各エントリを前記連続発声音声に含まれた文と比較して、各エントリの一致を判定する請求項３に記載の音声認識装置。
【請求項５】
前記文認識回路が、認識された単語上で動作する自然語エンジンを含む請求項４に記載の音声認識装置。
【請求項６】
連続発声音声に含まれる文は、名詞句を調べることによって可能性のある文の候補の組と比較される請求項５に記載の音声認識装置。
【請求項７】
可能性のある文の候補の組は、ユーザによって与えられた動作環境に応じて前記文認識回路によってロードされるコンテックスト辞書によって決定される請求項４に記載の音声認識装置。
【請求項８】
前記第一の信号処理回路が、前記連続発声音声を格納する記憶手段と、連続発声音声に対応する音声信号を捕捉する手段と、連続発声音声に含まれる前記一乃至複数の単語に相関させるには不十分な音声からある程度認識された音声信号を発生する第一の処理手段と、を有し、
前記第二の信号処理回路が、ある程度認識された音声信号から一乃至複数の単語に相関された認識可能な音声信号を発生する第二の処理手段、を有し、
前記第一及び第二の信号処理回路の処理動作に基づいて、一乃至複数の単語に相関された音声情報が得られる請求項１ないし７のいずれかに記載の音声認識装置。
【請求項９】
前記送信回路は、前記第一と第二の信号処理回路を結合する非永久データ送信接続手段である請求項１ないし８のいずれかに記載の音声認識装置。
【請求項１０】
前記非永久データ送信接続手段は、交換された回路又はパケット交換接続手段である請求項９に記載の音声認識装置。
【請求項１１】
前記非永久データ送信接続手段は、インターネットのネットワークを含んでいる請求項９に記載の音声認識装置。
【請求項１２】
前記非永久データ送信接続手段は、ワイヤレス通信チャンネルである請求項９に記載の音声認識装置。
【請求項１３】
前記第一の信号処理回路の処理動作が、連続発声音声からスペクトルパラメータベクトルを抽出する動作を含む請求項１ないし１２のいずれかに記載の音声認識装置。
【請求項１４】
前記第一の信号処理回路の処理動作が、前記スペクトルパラメータベクトルに関するＭＦＣＣ係数を得るために、Ｍｅｌ周波数転送処理によりスペクトルパラメータベクトルを分解する動作を含んでいる請求項１３に記載の音声認識装置。
【請求項１５】
ある程度認識された音声信号は、スペクトルパラメータベクトルより得られるＭＦＣＣ係数とデルタ及び加速係数を含む観察ベクトルＯtで構成される請求項１３に記載の音声認識装置。
【請求項１６】
ある程度認識された音声信号は、観察ベクトルＯtを含み、前記第二の信号処理動作は、音声信号シンボルにより一連の観察ベクトルＯtをマッピングするためのビタビ復号動作を含んでいる請求項８に記載の音声認識装置。
【請求項１７】
前記第二の信号処理回路の処理動作が、前記音声信号シンボルを一乃至複数の単語テキストに変換する変換動作を含んでいる請求項１ないし１６のいずれかに記載の音声認識装置。
【請求項１８】
前記第二の信号処理回路の処理動作が、一乃至複数の単語のいずれが、前記一乃至複数の単語テキストに対応しているかを判定するクエリーを実行する請求項１７記載の音声認識装置。
【請求項１９】
前記第二の信号処理回路の処理動作が、一乃至複数の単語テキストのいずれが音声情報に対応しているかを判定するための環境変数を用いる請求項８に記載の音声認識装置。
【請求項２０】
前記第一の信号処理回路では、前記発声音声信号から前記発声音声の単語の認識を可能にするためにそれ自体では不十分な第一の音声信号の組を発生し、第一の組の音声信号を前記送信回路の通信チャンネルの通信プロトコルと互換性を有するフォーマットとなるように生成するとともに、サーバーコンピューティング装置に送信し、
前記第二の信号処理回路で、前記発声音声信号の単語を抽出する単語認識エンジンによって使用するのに十分な情報を含む第二の組の音声信号を生成し、
前記第一の組の音声信号と前記第二の組の音声信号を用いて分散音声認識が行なわれる請求項１記載の音声認識装置。
【請求項２１】
前記第二の音声信号の音声信号が、前記第一の組の音声信号から取り出された音声信号に基づいて計算される請求項２０に記載の音声認識装置。
【請求項２２】
前記第一と第二の信号処理回路の信号処理の分担として、前記第一の信号処理回路は、前記発声音声信号から単語認識エンジンによって使用可能な形式に変換するために必要な信号処理動作の約１／２未満の処理を行うように割り当てられる請求項１に記載の音声認識装置。
【請求項２３】
前記第一の信号処理回路は、第二の組の音声信号を発生するために必要な信号処理演算によって前記第二の信号処理回路を補助するように構成される請求項１に記載の音声認識装置。
【発明の詳細な説明】
【発明の属する技術分野】
【０００１】
この発明は、インターネットまたは局地的イントラネット等の分散ネットワーク上に与えられるユーザの音声入力及び照会に応答するシステム及び対話方法に関するものである。インターネットのワールドワイドウエブ（ＷＷＷ）サービス上で実施された場合、この対話システムは、クライアント又はユーザが英語、仏語、独語、スペイン語、日本語等の自然語により質問をすることが出来、彼又は彼女の母国語による適当な回答を彼又は彼女のコンピュータまたはその周辺機器で受け取ることができるように機能する。このシステムは、遠隔学習、電子商取引(e-commerce)、技術的電子支援サービス(technical e-support service)、インターネット検索等に特に有用である。
【従来の技術】
【０００２】
インターネット、特にワールドワイドウエブ（ＷＷＷ）は、人気の面及び商業的及び娯楽目的の双方での利用の面で成長をつづけており、この傾向は継続するものと予測される。パーソナルコンピュータシステムの使用の増加及び普及や低価格のインターネット接続が可能になったことが、この現象の加速の一因となっている。安価なインターネット接続装置及びＡＤＳＬ、ケーブルモデム、衛星モデム(satellite modem)等の高速アクセス技術の出現により、ＷＷＷの大量使用がさらに加速するものと予測される。
【０００３】
従って、ＷＷＷ上においてサービス、製品等を提供している多くの事業者が、ここ数年で劇的に増加するものと予測される。しかしながら、今日まで、ユーザのインターネット「経験」は、ほとんどキーボードや、インテリジェント電子パッド、マウス、トラックボール、プリンタ、モニタ等の非音声入力・出力に限られている。これが、いろいろな意味でＷＷＷ上における対話に対する何らかのボトルネックとなっている。
【０００４】
まず、第一に、熟練度の問題がある。多くの種類のアプリケーションが、音声を用いる環境に、より自然で、円滑に適合しようとしている。例えば、オーディオ記録物を購入しようとするほとんどの人にとり、レコード店等において、その店において見つけることが出来る特定の作者のタイトルの情報を店員に尋ねることは非常に気分の良いものである。インターネット上の項目を見つけ出すために自分の所有する媒体上においてウエブページを閲覧し、検索することはしばしば可能であるが、通常、最初に人間の助けを借りることは、ほとんど例外なく、より容易であり、効率的である。この支援の要求は、音声による問い合わせの形で行われる。さらに、物理的又は心理的障壁があるため、多くの人々は前述した従来の入出力装置の何れも使用することが出来ないか、若しくは使用しない。例えば、多くの高齢者は、ＷＷＷページ上に存在するテキストを容易に読むことが出来ないか、またはメニューのレイアウトや階層構造を理解できないか、若しくは選択した項目を表示するためにうまく移動するためにマウスを操作することが出来ない。多くの他の人々は、コンピュータシステムやＷＷＷページ等の様子や複雑さにたじろがされ、この理由からもオンラインサービスを利用しようとしない。
【０００５】
従って、通常の人間の対話を模倣することが出来るアプリケーションは、オンラインショッピングをしたいと考えるユーザやＷＷＷ上で情報を探したいと考えるユーザにとって好まれる傾向がある。また、音声によるシステムの使用は、電子商取引や電子学習（e-learning）等に参加したいと考える人々の数を増加させるものと考えられる。しかしながら、今日まで、このタイプの対話を可能とするシステムは無くまたは有るとしてもきわめてわずかであり、また、対話が行われるにしても、その性能は非常に限られている。例えば、ＩＢＭ（Ｖｉａ  Ｖｏｉｃｅ）やKurzweil（Ｄｒａｇｏｎ）により販売されている種々の商用プログラムは、インターフェースのユーザーによるある種の制御（ファイルの開閉）や（予め学習されたＵＲＬを用いた）検索を可能とするが、時間がかかるボイストレーニングを必要とせずに、異なる文化を持つ多くのユーザによる使用を可能とする融通の解法を提供するものではない。インターネットにおいて音声による機能を実施するための従来の一般的な試みは、本明細書において開示の一部として援用するアメリカ特許第５，８１９，２２０号に見ることが出来る。
【０００６】
音声を基調とするシステムの欠如による他の問題は、効率である。多くの会社は、今日、インターネット上で技術サポートを提供しており、そのいくつかはこうした問い合わせに対応するために人間のオペレータによる支援を提供している。これは、（上記のような理由により）非常に有益ではあるが、こうした問い合わせを取り扱うために人間を雇用することを必要とするため、非常にコストがかかるとともに非効率である。これには、実用上の制限があり、応答までに長い待ち時間を要したり、雇用者のオーバーヘッドが高くなる。この方法の例は、本明細書の開示の一部として援用するアメリカ特許第５，８０２，５２６号に示されている。一般に、ＷＷＷ上において提供されるサービスは「拡張可能」であるか、または、換言すれば、予測されるユーザによって、知覚される遅れや混乱が有るとしても、これが極僅かである状態で、ユーザ情報量増加を取り扱うことが可能であることが、非常に望ましい。
【０００７】
同様の意味において、多くの学生にとって、遠隔学習は急激に人気が高まっている選択肢となっており、インストラクタにとって一度に二人以上からの質問に答えることは実質的に不可能である。その場合にも、他のインストラクタの時間的制約が有るために、こうした対話は、非常に限られた時間のみ行われるものとなる。
【０００８】
しかしながら、今日まで、学習セッション終了後に、またはこうした質問に対して個人的に対応するためのインストラクタを必要とせずに、学生が人間による質疑応答の対話を継続する実用的な方法は存在しない。
【０００９】
一方、人間的な問答をエミュレートする他の態様は、口述によるフィードバックを含んでいる。換言すれば、多くの人々にとって、回答や情報を音声による態様で受けることが好ましい。この形式の機能は、ウエブサイトの訪問者との情報交換を行うためにいくつかのウエブサイトにより採用されているが、これはリアルタイムの対話型の質疑応答として行われるものではなく、その有効性及び有用性は限られている。
【００１０】
音声による対話が有用なもう一つの分野は、ＹＡＨＯＯ．ｃｏｍ、ｎｚｅｔａｃｒａａｌｅｒ．ｃｏｒｅ、Ｅｘｃｉｔｅ．ｃｏｍ等において利用可能なような、ウエブサイトにおける興味のある情報を検索するためにインターネットのユーザによって使用される所謂「サーチ」エンジンである。これらのツールは、キーワードの組み合わせ又はメタカテゴリ(metacategories)を用いて検索用の設問(search query)を形成して、一乃至複数の異なるウエブページに関連するテキストのインデックスを持つウエブページのデータベースを通して検索することを可能とする。ユーザの要求を処理した後に、サーチエンジンは、一般にサーチエンジンによって使用されるサーチ処理ロジックに基づいてユーザの特定の質問に対してサーチエンジンが最も近い一致を検出したＵＲＬポインタとウエブページからの抜粋に対応するヒット数を返送する。ウエブページのデータベースを構築するとともに検索用の設問を解釈するメカニズムを含むこうした従来のサーチエンジンの構造及び動作は、従来より周知である。今日まで、出願人が知る限り、ユーザからの検索入力に基づいて容易にしかも信頼性の高い情報のサーチ及び検索を行うことが出来るサーチエンジンはない。
【００１１】
こうした能力より得られる多くの利点があるにも拘わらず、上記の環境（電子商取引、電子サポート、遠隔学習、インターネットサーチ等）において音声を基調とするインターフェースが使用されないことには多くの理由がある。まず第一に、音声認識装置の出力が出来得る限り正確で無くてはならないという明らかな要求によるものである。現時点において使用される音声認識のためのより信頼性の高い方法の一つは、ヒドンマルコフモデル(Hidden Markov Model (HMM)−全ての時間列を算術的表現に使用されるモデルである。この技術の従来の用途は、例えば、本明細書の一部として援用するアメリカ特許第４，５８７，６７０号に開示されている。話し言葉は一乃至複数のシンボルの潜在的な連続を有していると考えられるので、各シンボルに対応するＨＭＭモデルは、話し言葉の波形からのベクトルから学習される。ヒドンマルコフモデルは、状態の有限集合であり、各集合は（通常、多次元の）確率分布に関連付けられる。特定の状態において、結果又は発言(observation)は、関連する確率分布に従って発生される。この有限状態装置は、各時間単位毎に状態を変化させ、状態ｊに入る各時点ｔにおいて、スペクトルの変数ベクトルＯｔが確率密度Ｂｊ（Ｏｔ）で発生される。これのみが結果であり、外部の観察者には見える状態ではなく、従って外部に対して状態が「隠され(hidden)」ているので、ヒドンマルコフモデルと呼ばれる。ＨＭＭの基本理論は、１９６０年代後半から１９７０年代前半においてBaum及びその同僚によって一連の古典的文献により刊行されている。ＨＭＭは、Carnegie MellonにおいてＢａｋｅｒによって口述の用途に使用され、１９７０年代後半にＩＢＭにおいてJelenik及びその同僚によって使用され、１９９０年代にイギリスのCambridge UniversityにおいてSteve Young及びその同僚により使用された。いくつかの代表的な刊行物及びテキストは以下の通りである。
【００１２】
１．L. E. Baum, T. Petrie, 「有限状態マルコフチェインに対する確率関数に関する統計的推論(Statistical inference for probabilistic fuinctions for finite state Markov chains)」Ann. Math. Stat: 1554-1563, 1966
2. L. E. Baum,  「マルコフプロセスの確率関数の統計的推定における不等式及び関連する最大化技術(An inequyality and associated maximation technique in statistical estimation fpr probabilistic functions of Markov processes)」Inequalities 3:18, 1972
3. J. H. Baker,「ドラゴンシステム−概要(The dragon system - An Overview"」、IEEE Trans. on ASSP Proc., ASSP-23(1), 24-29, Feby, 1975
4. F. Jeninek et al., 「連続音声認識：統計的方法(Continuous Speech Recognition: Statistical method)」、Handbook of Statistics, II, P. R. Kristnaiad, Ed. Amsterdam, The Netherlands. North-Holland 1982
6. J. D. Ferguson, 「ヒドンマルコフ分析：紹介(Hidden Markov Analysis: An Introduction)」Hidden Markov Model for Speech, Institute of Defence Analyses, Princeton, NJ., 1980
7. H. R. Rabiner及びB. H. Juang,「音声認識の基本(Fundamentals of Speech Recognition)」Prentice Hall, 1993
8. H. R. Rabiner, 「音声信号のデジタル処理(Digital Processing of Speech Signals)」、Prentice Hall, 1978
種々の研究機関において、音声認識の用途においてニューラルネットワークによりＨＭＭを拡張しこれをＨＭＭに組み合わせるより最近の研究が行われている。以下はその代表的な刊行物である。
9. Nelson Morgan, Herve Bourlard, Steve Renals, Michael Cohen及びHoracio Franco (1993),  連続音声認識のためのニューラルネットワーク／ヒドンマルコフモデルのハイブリッドシステム(Hybrid Neural Network/Hidden Markov Model System for Continuous Spoeech Recognition)、Journa; of Pattern Recognition and Artificial Intelligence, Vol. 7, No. 4, pp 899-916及び
I. Guyon及びP. Wang編、Advance in Pattern Recognition System using Neutral Networks, Vol. 7, of Series in Machine Perception and Artificial Intelligence, World Scientific, Feb. 1994
【００１３】
上記全ての刊行物は、本明細書の開示の一部として援用する。ＨＭＭを基調とする音声認識により、良好な結果を得ることが出来るが、この技術の最近の変化は、全ての予測されるユーザ及び環境状態におけるＷＷＷの用途において要求されるのと同様の１００％正確で矛盾しない言語の正確な要求を保証するものではない。
【００１４】
従って、ここ数年音声認識技術は使用可能であり、大幅に改良されてきてはいるが、十分に機能するように音声認識及び自然語処理の組み合わせる用途に対して要求される音声認識の正確さに関する仕様において、技術的要求には厳しい制約がある。
【００１５】
言語認識とは逆に、自然語処理（ＮＬＰ）は、書き写された発言や大きな言語単位の解釈、理解及び見出し付けに関するものである。自然な音声は、どもり−ためらい、訂正や再スタート、「うーん(well)」といった談話標識等の、一般的な音声認識装置では取り扱うことが出来ない表面現象を含んでおり、これが問題であり、音声認識と自然語処理技術とを分ける大きなギャップの原因となっている。発声の間の無音状態を除き、もう一つの問題は言葉等の有意な単位に音声をセグメント化するために使用可能な句読点が存在しないことである。最適なＮＬＰ性能を得るために、これらのタイプの現象は、その入力において注釈が付されなければならない。しかしながら、最も連続的な音声認識システムは、生の言語列を発声する。ＮＬＰを用いた従来のシステムの例は、アメリカ特許第４，９９１，０９４号、第５，０６８，７８９号、５，１４６，４０５号及び５，６８０，６２８号に示されている。これら全ては、明細書の開示の一部として援用する。
【００１６】
第二に、非常に信頼性の高い音声認識システムのほとんどは、話者に依存し、時間がかかるユーザによる「訓練(trained)」されたインターフェースを必要とし、ユーザがウエブサイトには数回しかアクセスしないようなＷＷＷ環境の見地では非常に望ましくないものである。さらに、話者に依存するシステムは、通常音声の認識を減少させる大きなユーザ辞書（ユーザ一人に各一つの）を必要とする。十分な応答性能（即ち、自然な会話を反映する−３〜５秒程度がおそらく理想的と考えられる）を持つリアルタイム対話インターフェースを実施することを非常に困難にしている。今日、代表的な市販の音声認識のためのアプリケーションソフトウエアには、ＩＢＭ（Via Voice)やＤｒａｇｏｎ(Dragon)から提供されるものが含まれる。これらのアプリケーションのほとんどは、ディクテーションや他の書き写しの用途については十分であるが、ＮＬＱＳ等の認識エラー率が０％に近いことが要求される用途においては極めて不十分である。さらに、これらの提供されるシステムは、長時間のトレーニング時間を必要とし、一般的には非クライアント−サーバ構造である。他のタイプのトレーニングを要するシステムは、Kurzweilに譲渡されたアメリカ特許第５，２３１，６７０号であり、これも本明細書の開示の一部として援用する。
【００１７】
もう一つの分散型音声基調のシステムが直面する重大な問題は、音声認識処理における普遍性／制御の欠如である。音声認識システムの一般的な単独実施において、サーチエンジン全体が単一のクライアント上で実行される。このタイプの周知のシステムは、本明細書の開示の一部として援用するアメリカ特許第４，９９１，２１７号に開示されている。これらのクライアントは種々の音声信号処理及び通信性能を持つ種々の形態（デスクトップＰＣ、ラップトップＰＣ、ＰＤＡ等）を取り得る。従って、サーバ側の見地から、こうしたユーザは大きく異なる音声認識及びエラー率性能を有しているので、音声による操作可能なウエブページにアクセスする全てのユーザの処理を均一化することは容易なことではない。Gould et al.−アメリカ特許第５，９１５，２３６号−の従来技術は使用可能な計算リソースの組に対する認識処理の調製の概念について一般的に説明しているが、この従来技術は、クライアント−サーバモデルのような分散環境においてどのようにしてリソースを最適化するかの問題の解決に至っておらずまた解決を試みてもいない。重ねて言えば、広範囲に分散した規模でこうした音声基調の技術を可能とするためには、最も性能の低いクライアントをもサポート可能とするとともに電子商取引、電子サポート及び／又は遠隔学習を実施する遠隔サーバと満足の行く状態での対話を可能とするために、個別のシステムの違いを調和させ、考慮するシステムを持つことが好ましい。
【００１８】
音声認識のための分散型の方法に関する二つの参考文献は、本明細書の開示の一部として援用するアメリカ特許第５，９５６，６８３号や第５，９５６，６８３号を含んでいる。これらの内の第一のシステム、アメリカ特許第５，９５６，６８３号−分散型音声認識システム（Qualsommに譲渡された）において、電話基調のハンドセットとリモートステーション間の分散型音声認識システムの実施が開示されている。この実施において、全てのワード認識動作はハンドセットにおいて行われているように見える。この特許は、狭帯域幅の電話チャンネルから生じる量子化ひずみによる音響特性の劣化を制限するためにポータブル又は携帯電話における音響特性の抽出のためにポータブル又は携帯電話にシステムを配置することの利点を説明しているので、上記のように推測される。この文献は、非常に低性能のクライアントのプラットフォームに関してどのようにして十分な性能を得るかの問題に関するものではない。さらに、どのようにしてシステムがリアルタイムワード認識を行うのかを判断するのは困難であり、どのようにしてシステムを自然語処理システムに結合させるかに関する説得力のある説明はない。
【００１９】
これらのうちの第二の参考文献−アメリカ特許第５，９５６，６８３号−クライアント／サーバ音声処理装置／認識装置（ＧＴＥに譲渡された）には、ＨＭＭを基調とする分散型音声認識システムの実施について説明されている。この参考文献は、多くの点において有益ではないが、適切な場合には部分的なワード認識処理を行う等によって種々のクライアントのプラットフォームに対してどのように音響特性の抽出を最適化するかを含んでいる。より重要には、ユーザの音声の認識のみを行い、ユーザのマシン上の専用フォームに記入するためにユーザの名前及び旅行目的地等のある種のキーワードを返す原始的音節に基づく認識装置のみが開示されている。また、音響パラメータのストリーミングは、無音状態を検出後にのみ行われるので、リアルタイムに実施されているとは考えられない。最後に、参考文献は自然語処理の使用可能性に言及している（第９欄）が、どのようにしてユーザに対話感覚を与えるようにリアルタイムで実施されるかに関しては何らの説明もなされていない。
【発明が解決しようとする問題点】
【００２０】
従って、本発明の目的は、上記の従来技術における制限を克服することが出来る改良されたシステム及び方法を提供することにある。
【００２１】
本発明の主要な目的は、広範なユーザグループに対して改良された精度、速度及び普遍性を達成することが出来るクライアント／プラットフォーム演算アーキテクチャに亘って柔軟且つ最適に分散された単語及び句認識システムを提供することにある。
【００２２】
本発明のもう一つの目的は、如何なる数の言語においても個別の単語及び発言全体を素早くしかも正確に認識出来るように分散ワード認識を自然語処理システムに効率的に結合させる音声認識システムを提供することにある。
【００２３】
本発明の関連する目的は、音声による問い合わせに応答して適切な回答の組を非常に正確且つリアルタイムに与えることが出来る効率的な問い合わせ応答システムを提供することにある。
【００２４】
本発明のさらにもう一つの目的は、クライアント／サーバアーキテクチャ上に分散された対話型リアルタイム教育／学習システムを提供することにある。
【００２５】
本発明の関連する目的は、ユーザが人間的な対話を経験できるように明瞭に応答する能力を備えた対話性を実施することにある。
【００２６】
本発明のさらにもう一つの目的は、こうしたサイトとの対話に音声によるデータ及びコマンドを用いることが出来、容易に拡張可能な音声による電子商取引及び電子サポートサービスを可能とするために音声認識性能を備えたインターネットウエブサイトを提供することにある。
【００２７】
本発明のもう一つの目的は、正確性及び速度を改良するために認識処理の一部として環境変数を用いる分散型音声認識システムを実施することにある。
【００２８】
本発明のさらにもう一つの目的は、特定のアプリケーション及び瞬間的な要求に必要となる如何なる数の問い合わせ題目及びユーザをもサポートする拡張可能な問い合わせ／回答データベースシステムを提供することにある。
【００２９】
本発明のさらにもう一つの目的は、比較的短時間に予測される応答のリストをより小さい候補の組に絞り込む第一のステップと、候補等から質問に応答して返送する最良の選択を特定する演算としてより集約的な第二のステップを含む２段階方式を採用する問い合わせ認識システムを提供することにある。
【００３０】
本発明のさらにもう一つの目的は、こうした発言のために適切な予測される応答の候補の組を迅速に特定するために成分を用いることが出来る、発言の単語成分を抽出することによって問い合わせの認識を容易とする自然語処理システムを提供することにある。
【００３１】
本発明の関連する目的は、発言の単語成分をこうした問い合わせに対する非常に正確な最良な応答を提供するために予測される応答の候補の組と比較することによって問い合わせの認識を容易とする自然語処理システムを提供することにある。
【問題を解消するための手段】
【００３２】
したがって、本発明の一つの全般的特徴は自然語質問システム（ＮＬＱＳ）に関し、これはインターネットまたは局地的イントラネット等の分散ネットワーク上でユーザの質問に答える完全に対話型の方法を提供するものである。この対話システムは、インターネットのワールドワイドウエブ（ＷＷＷ）サービス上で実施された場合、クライアント又はユーザが英語、仏語、独語、スペイン語等の自然語により質問をすることが出来るように機能し、また彼又は彼女の母国語の自然語により適当な回答を彼又は彼女のパーソナルコンピュータで受け取るものである。
【００３３】
このシステムは分散され、クライアントの装置における統合ソフトウエアモジュールのセットと、サーバ或いはサーバ群に存する統合ソフトウエアプログラムの別のセットとからなる。クライアント側ソフトウエアプログラムは、音声認識プログラム、エージェント及びその制御プログラム、及び通信プログラムとからなる。サーバ側プログラムは、通信プログラム、自然語エンジン（ＮＬＥ）、データベース処理装置（ＤＢ処理）、ＤＢ処理をＮＬＥと相互作用させるためのインターフェースプログラム、及びＳＱＬデータベースとからなる。さらに、クライアントの装置にはマイクロフォンとスピーカーが備えられる。処理及び送信待ち時間を最適化し、また非常に性能の低いクライアントのプラットフォームにもサポートを提供するために、発言の処理はクライアントとサーバ側とで分けられる。
【００３４】
対話学習用途の状況では、システムは特に、ユーザの質問へ単一の最良回答を与えるのに用いられる。クライアントの装置でなされる質問は、話者により明瞭に発音され、ノートブックコンピュータの場合などは内蔵され或いは通常周辺付属品として提供されるマイクロフォンによって捉えられる。質問が捉えられると、質問はクライアントの装置に存するＮＬＱＳクライアント側ソフトウエアによって部分的に処理される。この部分的処理の出力は一組の音声ベクトルであり、これはユーザ質問の認識を完了するためにインターネットを介してサーバへと運ばれる。この認識された音声は次にサーバでテキストへと変換される。
【００３５】
サーバに置かれた音声認識エンジンによってユーザの質問がデコードされた後、質問は構造化クエリー言語（ＳＱＬ）クエリーへと変換される。このクエリーは次に、予備処理のためにＤＢ処理と呼ばれるサーバ内のソフトウエア処理へ、及びユーザの質問の名詞句（ＮＰ）を抽出するために自然語エンジン（ＮＬＥ）モジュールへと同時に与えられる。ＮＬＥ内での名詞句抽出処理の間に、ユーザの質問のトークンにタグが付けられる。タグ付けされたトークンは次に、ＮＰリストが決定可能なようにグループ化される。この情報は記憶され、ＤＢ処理プロセスへと送られる。
【００３６】
ＤＢ処理では、ユーザの質問から抽出されたＮＰ及び用途に合った他の環境変数を用いてＳＱＬクエリーが完全にカスタマイズされる。例えば、訓練用途においては、コース、チャプタ及び又はセクションについてのユーザの選択が環境変数を構成する。ＳＱＬクエリーは、拡張ＳＱＬ全文述部―ＣＯＮＴＡＩＮＳ、ＦＲＥＥＴＥＸＴ、ＮＥＡＲ、ＡＮＤを用いて構成される。ＳＱＬクエリーは次に、ＳＱＬデータベース内の全文サーチエンジンへと送られ、ここで全文検索手続きが開始される。この検索手続きの結果は回答のレコードセットである。このレコードセットはユーザの質問と言語的に類似する記憶質問を含む。これらの記憶質問のそれぞれが異なるテキストファイルに記憶された対となる回答を有し、このパスがデータベースのテーブルに記憶される。
【００３７】
戻された記憶回答のレコードセット全体が次に、配列（array）の形態でＮＬＥエンジンへと戻される。そしてアレの各記憶質問は、連続して一つ一つ言語的に処理される。この言語的処理が、ユーザの質問への単一の最良回答を決定するための二段階アルゴリズムの第二ステップを構成する。この第二ステップは以下のように進行する：レコードセットに戻された各記憶質問に対して、記憶質問のＮＰがユーザ質問のＮＰと比較される。アレの全ての記憶質問がユーザ質問と比較された後、ユーザ質問と最大に一致する記憶質問が、ユーザ質問と一致する最良の記憶質問として選ばれる。最良の記憶質問の決定に用いられる基準は名詞句の数である。
【００３８】
最良記憶質問と対をなす記憶回答がユーザ質問に答えるものとして選ばれる。そして質問のＩＤタグがＤＢ処理へと渡される。ＤＢ処理はファイルに記憶された質問を返す。
【００３９】
通信リンクが再び確立され、圧縮形態で回答をクライアントへと送り返す。クライアントにより一旦受け取られた回答は解凍され、テキスト―スピーチエンジンによりユーザへとはっきりと伝えられる。このように本発明は、対話学習システム、インターネット関連商取引サイト、インターネットサーチエンジンなどを含む多くの様々な用途へと用いることができる。
【００４０】
コンピュータを使った教育環境はしばしば、学生からの質問に答えるのに相談相手あるいは生身の教師の助けを必要とする。この助けはしばしば、指定時間に質問への回答が得られるよう、事前に決められた特別フォーラム、あるいはチャットセッション又はライブでの電話参加セッションとして設けられるミーティング時間の設置というやり方となる。生徒がいつどこであってもログオンし教育を受けられるオンライン訓練の即時性及びオンデマンドな又は非同期の性質のため、質問への回答が適時的且つ費用効果の高い方法でもたらされ、よってユーザ又は生徒が与えられたものから最大限の利益を得ることができることが重要である。
【００４１】
本発明はこの問題を解決する。それは通常生身の教師又は相談相手に与えられる質問への回答をユーザ又は生徒へと与える。この発明は生徒により尋ねられた質問に対して単一の最良な回答を与える。生徒は選択肢の中の言語で彼又は彼女自身の声で質問を発する。分散型音声認識、全文検索データベース処理、自然語処理、テキスト―スピーチ技術を含む多くの技術を用いて、音声は認識され、質問への回答が見出される。回答は、生身の教師の場合同様、相談相手又は教師を真似たエージェントにより明瞭な発音で、そして選択された言語―英語、仏語、独語、日本語、あるいは他の自然口語で、ユーザへと与えられる。ユーザは、キャラクタの声の高さ、大きさ、早さなどの幾つかの音声パラメータと同じく、エージェントの性別を選ぶことができる。
【００４２】
ＮＬＱＳから利益を受ける他の用途は、電子商取引用途である。この用途においては、書籍やコンパクトディスクの価格について、あるいは購入されるアイテムの入手可能性についてのユーザ質問が、連続するウエブページの様々なリストを経由して選ぶ必要なしに検索できる。代わりに、余計なユーザ入力なしに、回答はユーザへと直接もたらされる。
【００４３】
同様に、このシステムは、照会頻度の高い質問（ＦＡＱｓ）へ回答をもたらすことに、及び電子サポートのための診断サービスツールとして使用可能であると考えられる。これらの質問は所定のウエブサイトにはよくあるもので、ユーザが支払い手続き、あるいは製品／サービスの仕様や蒙った問題に関連する情報を見つけるのを助けるために提供される。こうした用途の全てに、ＮＬＱＳアーキテクチャは適用可能である。
【００４４】
これらのアーキテクチャと関連する多数の独創的方法もまた、様々なインターネット関連用途で有益に用いられる。
【００４５】
本発明は以下に好ましい実施の形態の群において説明されるが、迅速且つ正確な音声認識を実行することが必要で、及び／又は知的システムへ人間的な対話能力を与えることが必要な多くの環境下で本発明が有益に用いられ得ることは当業者にとって明らかであろう。
【発明の実施の態様】
【００４６】
概要
上記のように、本発明は、ユーザがクライアントコンピュータシステム（単純な個人用携帯情報端末、携帯電話、洗練されたハイエンドのデスクトップＰＣ等）により英語、仏語、独語、スペイン語又は日本語等の自然語により質問の提起及び彼又は彼女の母国語の自然語により遠隔サーバより適切な回答を受け取ることを可能とする。従って、図１に示す発明の実施例は、電子商取引、電子サポート及び電子学習の用途のために人間的な対話能力／経験を与えるためにリアルタイムに対話するように構成された自然語質問システム（ＮＬＱＳ）１００の概要を説明するために有利に用いられる。
【００４７】
ＮＬＱＳ１００の処理の概要を、クライアント側システム１５０，データリンク１６０及びサーバ側システム１８０にわたって説明する。これらの構成要素は、従来より知られており、好適実施例においては、パーソナルコンピュータシステム１５０と、インターネット接続１６０Ａ、１６０Ｂ及び大規模コンピュータシステム１８０を有している。これらが例示的な構成要素であるとともに、本発明はこうしたシステムの特定の実施又は組み合わせにより決して制限させるものではないことは、当業者に理解されることである。例えば、クライアント側システム１５０はコンピュータの周辺機器や、ＰＤＡや、携帯電話の一部、インターネット対応機器の一部、インターネットにリンクされた公衆電話等として実施することも可能である。同様に、インターネット接続はデータリンク１６０Ａとして示されているが、ワイヤレスリンク、ＲＦリンク、ＩＲリンク、ＬＡＮ等のクライアントシステム１５０とサーバシステム間のデータ転送に適した経路で十分である。最後に、サーバシステム１８０は、単一の大規模コンピュータシステムとするか、若しくは多数の予測されるネットワークユーザをサポートする連結されたより小規模なシステム群とすることが出来る。
【００４８】
まず、音声入力は、発声として、クライアントの装置や個人用補助装置(personal accessory)において話者により明瞭に表現された質問や問い合わせの形で与えられる。この発言は、捕捉され、クライアントマシンに存在するＮＬＱＳのクライアント側ソフトウエア１５５によって部分的に処理される。対話の人間的な態様を容易とし、向上させるために、質問は、個人的情報検索エージェントとしてユーザを補助するユーザが見ることが出来る動画のキャラクタ１５７の存在下で提起される。エージェントはまたモニタ／ディスプレイ（図示せず）上の目で見ることが出来るテキスト出力及び／又はテキスト―スピーチエンジン１５９を用い可聴形式によりユーザと対話することが可能である。ＳＲＥ１５５によっておこなわれる部分的処理の出力は、音声ベクトル組であり、インターネット又は上述のようにインターネットにリンクされたワイヤレスゲートウエイを介してユーザの装置又は個人用補助装置をサーバ又は複数のサーバにリンクさせる通信チャンネル１６０Ａを通じて送信される。サーバ１８０において、部分的に処理された音声信号データは、サーバ側ＳＲＥ１８２によって取り扱われ、ユーザの質問に対応する認識された音声テキストが出力される。テキストに関連したユーザの質問に基づいて、テキスト−質問変換器１８４が、データベース処理装置１８６の入力として用いられる適当な質問を形成する。質問に基づいて、データベース処理装置１８６は、次いで、データベース１８８からカスタマイズされたＳＱＬ質問を用いて適切な回答を探し、検索する。自然語エンジン１９０は、データベース１８８に対する質問の構成を容易とする。ユーザの質問にマシンが回答した後、前者がデータリンク１６０Ｂを介してテキストを送信し、データリンクにおいてテキスト−スピーチエンジン１５９によって音声に変換して、動画キャラクタのエージェント１５７によって口語フィードバックとして表現される。
【００４９】
音声処理はこの要領で分解されるので、大きな、制御可能な質問／回答の組を構成するリアルタイムで、対話型の人間的な問答を構成することが出来る。動画のエージェント１５７の補助により経験が向上され、初心者のユーザにとって自然で心地よいものとする。音声認識処理をより信頼性の高いものとするために、前後関係を特定した文法及び辞書が、自然語処理ルーチンとともに、ユーザの質問の語彙の分析にＮＬＥ１９０において使用される。音声データの前後関係を特定した処理は、従来より知られているが（本明細書の開示の一部として援用するアメリカ特許第５、９６０，３９４号、５，８６７，８１７号、第５，７５８，３２２号及び第５，３８４，８９２号を参照）、発明者等は、本発明により実施されているような実施例を知らない。ユーザの質問のテキストは、ＤＢ処理装置／エンジン（ＤＢＥ）１８６によりユーザにより提起された質問を識別するために他の質問のテキストと比較される。ＳＲエンジン１５５及び１８２の対話及び関係、ＮＰＬルーチン１９０、辞書及び文法を最適化することによって、非常に高速で正確な一致を得ることが出来、独特で応答性の高い回答をユーザに提供することが出来る。
【００５０】
サーバ側１８０において、交互的な処理が、音声認識処理をさらに加速する。単純化された用語により、質問がＮＬＥ１９０に与えられ、質問が形成された後にＤＢＥ１８６に与えられる。ＮＬＥ１９０とＳＲＥ１８２は、全認識工程において相補的な機能を行う。一般に、ＳＲＥ１８２は、主にユーザによって表現されたワードの独自性を決定し、一方、ＮＬＥ１９０は、ユーザの質問とデータベース問い合わせの後に戻されるサーチ結果に双方の言語形態学上の分析を行う。
【００５１】
ユーザの質問がＮＬＥ１９０によって分析された後に、いくつかのパラメータが抽出され、ＤＢ処理に送られる。付加的な統計は処理の第二のステップのための配列に格納される。二段階アルゴリズムの第二のステップの間、レコードセットの一次サーチの結果は、ＮＬＥ１９０の処理のために送出される。この第二のステップの終わりに、ユーザの質問と一致する単一の質問は、単一の格納された質問の対をなす回答を得るための処理を行うＤＢ処理に送出される。
【００５２】
従って、本発明は自然語処理（ＮＬＰ）を形成するために使用され、音声基調のウエブアプリケーションシステムにおいて最適性能を達成する。ＮＬＰは従来より公知であるが、自然語処理（ＮＬＰ）作業における従来の試みはともかく音声認識（ＳＲ）技術と良好に結合されておらず、ウエブ基調のアプリケーション環境において合理的な結果を達成する。音声認識において、結果は一般にそれぞれ音声認識装置に適合するある程度の蓋然性を持つ見込まれる認識されたワードの格子である。前述のように、一般的ＮＬＰシステムに対する入力は、主として大きな言葉の単位である。ＮＬＰシステムは大きな言葉の単位又は書き写された発言の組を解釈し、理解し、索引付けする作業を行う。このＮＬＰ処理の結果は、ワード認識とは対照的に、言葉の単位全体を言語学的または形態学的に理解する。他の方法において、ＳＲＥにより言語単位又は連結された単語のセンテンス出力は、単に「認識」されたものと対照的に言語学的に理解される。
【００５３】
前述のように、音声認識技術はここ数年使用可能となっているが、ＮＬＱＳの発明に対する技術的要求は、十分に機能するように音声認識と自然語処理を組み合わせる用途において必要とされる音声認識精度を得るための仕様に関して非常に厳しい制限を設けている。この実現において、最良の状態においても所要の完全に１００％の音声認識精度を達成することは不可能であり、本発明は、質問中の各ワードにおいて完全な音声認識を達成することが不可能な場合にも、ともかく質問全体自体の認識は十分な精度が得られるように、音声認識処理の予測されるリスクと自然語処理の要求をバランスさせるアルゴリズムを採用する。
【００５４】
この認識精度は、音声による質問に応答するため及び予測される１００乃至２５０の質問に対して３乃至５秒の短い待ち時間（理想的には、変動する送信待ち時間を無視して）という厳しいユーザの制約にさえも合致することができる。この短い応答時間は、全体的な印象として、ユーザの見地からより自然で、好ましいリアルタイムの対話の経験を与える。勿論、例えば翻訳サービスのような、非リアルタイムの用途においても、ＨＭＭ、文法、辞書等が集約して保持されるので、この技術は有利である。
本発明において使用される音声認識の概要
【００５５】
音声認識の一般的な背景技術情報は、上記の、開示の一部として援用した参考文献において見ることが出来る。にも拘わらず、ＮＬＱＳ１００に適合した音声認識構造及び技術の具体例について、本発明の特性、質及び特徴のいくつかをより良く示すために説明する。
【００５６】
音声認識技術は、一般に二つのタイプ−話者非依存タイプ及び話者依存タイプである。話者依存タイプの音声認識技術において、各ユーザは、認識される可能性のあるワードのサンプルを記憶したボイスファイルを有している。話者依存音声認識システムは、一般に、ディクテーションやテキスト書き写しの用途に適したものとするために大きな語彙及び辞書を有している。さらに、話者依存タイプのシステムに関してメモリ及びプロセッサのリソースは通常大きく、集約的となる可能性があり、また一般的である。
【００５７】
逆に、話者非依存タイプの音声認識技術は、単一の語彙ファイルの多くのユーザのグループによる使用を可能とする。達成される精度は、与えられた言語に関してサポート可能な文法及び辞書の大きさ及び複雑さによって変化する。ＮＬＱＳに使用する場合、小さい文法及び辞書の使用によりＮＬＱＳにおいて話者非依存タイプの音声認識技術の実施が可能となる。
【００５８】
話者非依存タイプ及び話者依存タイプのいずれのタイプにおいても重要な問題又は要求される事項は、精度と速度である。ユーザ辞書のサイズが大きくなるに従って、音声認識精度は上昇し、誤認識率（ＷＥＲ）及び速度は低下する。これは、サーチ時間が増加し、辞書のサイズの増加に伴って発音の一致が複雑となるためである。
【００５９】
ＮＬＱＳ音声認識システムの基本は、一連のヒドンマルコフモデル（ＨＭＭ）であり、これは前述のように経時的に変化する信号を特徴付ける数学的モデルである。音声の一部は、一乃至複数のシンボルの潜在的列に基づいているので、各シンボルに対応するＨＭＭモデルは音声波形からのベクトルとして学習される。ヒドンマルコフモデルは、状態の有限集合であり、そのそれぞれは（通常多次元の）確率分布に関連付けられている。状態間の遷移は、遷移確率と呼ばれる確率の組によって支配される。特定の状態において、結果又は所見が、関連付けられた確率分布に従って発生される。この有限集合装置は、各時間単位ごとに状態を変化させ、状態ｊに入る時点ｔにおいてスペクトルパラメータベクトルＯtを、確率密度Ｂj（Ｏt）で発生させる。これが唯一の結果であり、外部の観察者に状態が見えないので、状態は結果に「隠されている」のでヒドンマルコフモデルと名付けられた。
【００６０】
孤立した音声認識において、各ワードに対応する一連の発言された音声ベクトルは、以下のマルコフモデルによって表現される。
【００６１】
Ｏ=o1, o2, .........ot                                         （１−１）
【００６２】
ここで、ｏtは時点ｔにおいて発言される音声ベクトルである。孤立したワード認識は以下のように算定する。
【００６３】
arg max [P(wi|Ｏ)]                                        （１−２）
【００６４】
ベイズの定理を用いることにより、
[P(wi|Ｏ)] = [P(Ｏ|wi)P(wi)]/P(Ｏ)                            （１−３）
【００６５】
一般的な場合、音声に適用された場合、マルコフモデルも有限状態装置を前提とし、各時間帯ごとに状態を変化させ、状態ｊに入る各時点において、音声ベクトルｏtが、確率密度ｂj（ｏt）から発生する。さらに、状態ｉから状態ｊへの遷移も確率的であり、離散確率ａijによって支配される。
【００６６】
状態シーケンスＸに関して、状態シーケンスＸを通して移動するモデルＭによってＯが発生される複合確率は、遷移確率と出力確率の積である。発言シーケンスのみが知られている場合、状態シーケンスは前述のように隠される。
【００６７】
Ｘが知られていないとすると、所要の尤度は、全ての予測される状態シーケンスＸ＝ｘ（１），ｘ（２），ｘ（３），．．．．ｘ（Ｔ）の加算により計算される。
【００６８】
0004987203.tif 000002
【００６９】
ワードｗiに対応するモデルの組がＭiであるとすると、式（１−２）は式（１−３）を用いまた
P(Ｏ|wi) =P(Ｏ|Mi)
と仮定することによって解かれる。
【００７０】
これらの全ては、パラメータ｛ａij｝及び｛ｂj（ｏt）｝は、それぞれのモデルＭiについて知られていることを前提としている。これは、前述のように、特定のモデルに対応する学習用例題を用いて行われる。その後に、モデルのパラメータは、頑丈で、効率的な再予測手順によって自動的に決定される。そのため、十分な数の各ワードの代表的な例が収集されると、ＨＭＭを構成することが出来、現実の音声における不可避の変化の多数の原因の全てを単にモデル化したものである。このトレーニングは従来より周知であるので、詳細な説明は省略するが、ＨＭＭはクライアント側ではなくサーバ側において導き出され、構成されるので、本発明の分散アーキテクチャによりＨＭＭの品質が向上する。このようにして、異なる地図上の地域のユーザからの適切なサンプルを簡単にコンパイル及び分析して認識すべき特定の言語において生じる可能性のある変化を最適化することが出来る。各予測されるユーザは認識処理中にＨＭＭの同一の組を使用するので、音声認識処理の均一性は良好に保持され、エラー診断を簡素化する。
【００７１】
トレーニングサンプルの組からＨＭＭのパラメータを決定するために、第一ステップは、それらが何であるかの大まかな推測を行う。次いで、ボーム−ウェルシュ推定式(Baum-Welch estimation formula)を用いて精緻化が行われる。これらの式により、最大尤度μj（μjは平均ベクトルでありΣjは分散行列）は、
μj=ΣTt=1Lj(t)ot/[ΣTt=1Lj(t)ot]
【００７２】
次に、前方−後方アルゴリズム(forward-backward algorithum)が用いられ、状態占有確率Lj(t)が計算される。状態ＮのあるモデルＭに関する前方確率αj（ｔ）は、
αj(t) = P(o1,......, otx(t) = j|M)
で表される。この確率は、帰納法を用いて計算することが出来る。
【００７３】
αj(t) =  [ΣN-1j=2α(t-1)aij]bj(ot)
【００７４】
同様に、後方確率は、帰納法を用いて計算することが出来る。
【００７５】
βj(t) =ΣN-1j=2 aijbj(ot+1)(t+1)
【００７６】
前方確率は複合確率であり、後方確率は条件的確率であることを実現することによって、状態占有の確率は二つの確率の積となる。
【００７７】
αj(t)βj(t) = P(Ｏ， x(t) = j|M)
【００７８】
それゆえに、時点ｔにおける状態ｊの確率は、
Lj(t) = 1/P[αj(t)βj(t)]
【００７９】
ここで、P=P(Ｏ|M)
【００８０】
連続音声認識のために上記を一般化するために、総和が最大動作により置き換えられる最大尤度状態シーケンスを前提とする。従って、与えられたモデルＭに関して、φj（ｔ）が時点ｔにおける状態ｊにおいて使用される発言する音声ベクトルｏ1乃至ｏtの最大尤度を示していると仮定すると、
φj（ｔ）= max [φj（ｔ）(t-1)αij]βj(ot)
【００８１】
アンダーフローを回避するためにｌｏｇ表現を用いれば、最大尤度は
ψj(t) = max [ψi(t-1) + log(αij)] + log(bj(ot))
【００８２】
これはまた、ビタビアルゴリズムとして知られている。垂直方向の寸法がＨＭＭの状態を示し、水平方向が音声フレーム、即ち時間を示すマトリクスを通る最適パスを検索することにより可視化される。連結された音声認識への拡張を完成するために、さらに潜在的なシーケンスを示す各ＨＭＭが連結されるものと仮定する。従って、連続音声認識のためのトレーニングデータは、連結された発声で構成されるが、ワード間の境界を知られる必要はない。
【００８３】
演算速度／効率を改善するために、ビタビアルゴリズムは、時々、トークンパッシングモデル(Token Passing Model)として知られるモデルを用いて収束を達成する。トークンパッシングモデルは、発言シーケンスｏ1乃至ｏtと特定のモデル間の部分一致を示し、時点ｔにおける状態ｊモデルである制約をうける。このトークンパッシングモデルは、ＨＭＭのシーケンス有限状態ネットワークとして規定することを可能とするとすれば、容易に連結音声認識に拡張することが出来る。音素に基づくＨＭＭと完全なワードを含む複合ネットワークは、確率格子からＮ個の最良の抽出ワードを用いて連結音声を形成するために単一の最良のワードを認識出来るように構成される。この複合型のＨＭＭに基づく連結音声認識装置は、ＮＬＱＳ音声認識装置モジュールの基礎となる。ともかく、本発明は、特別の形式の音声認識装置に限定されるものではなく、本発明のアーキテクチャと互換性があり、ユーザにリアルタイムに対話の経験を提供するための精度及び速度の所要の能力基準を満足する限りにおいて音声認識のための他の技術をも採用することが出来る。
【００８４】
本発明によるＨＭＭに基づく音声認識システムに関する音声の表現は、音声は本質的に（発声された音声の）準周期的パルス列と（発声されない音声の）ランダムノイズ源の何れかである。これらは、二つの音声源としてモデル化され、一方はピッチ周期Ｐのインパルス列発生器と、発声／非発声スイッチにより制御可能なランダムノイズ発生器としてモデル化される。スイッチの出力は、音声信号から予測されるゲイン関数に供給され、生成される音声の声道パラメータ特性により制御されるデジタルフィルタＨ（ｚ）に供給するように拡大される。発声／非発声の切り換え、発声音のピッチ周期、音声信号に関するゲインパラメータ及びデジタルフィルタの係数等のこのモデルに対する全てのパラメータ−は、時間の経過に応じてゆっくり変化する。ＨＭＭの組の観点において評価を可能とするようにユーザの音声入力からの音響パラメータの抽出において、ケプストラム分析は一般に、振動情報から声道情報を分離するために使用される。信号のケプストラムは、ｌｏｇスペクトルのフーリエ（又はこれと同様の）変換を採用することによって計算される。ケプストラム係数を抽出することの主要な利点は、それらが非相関化され、対角線の共分散をＨＭＭとともに使用することが可能となる。人間の耳は音声スペクトルにわたって周波数の非線形性を解消するので、同様に非線形に動作するフロントエンドが音声認識性能を改善することを示している。
【００８５】
従って、一般的線形予測に基づく分析によらず、ＮＬＱＳ音声認識エンジンのフロントエンドは、メルスケール(Mel-scale)においてほぼ等しい解像度を与えるように設計されたフィルタバンクに基づいて単純な高速フーリエ変換を行う。このフィルタバンクを実施するために、（特定の時間フレームに関する）音声データのウインドウはソフトウエアによるフーリエ変換及び取りうる大きさを用いて変換される。各ＦＦＴの大きさは、対応するフィルタの利得と乗算され、その結果が蓄積される。フロントエンドによるこのフィルタバンク分析から得られるケプストラム係数は、ｌｏｇフィルタバンクの振幅の離散コサイン変換を用いることによって音声信号の第一の部分的な処理段階において計算される。これらのケプストラム係数は、メル周波数ケプストラム係数(Mel-Frequency Cepstral Coeficient(MFCC))と呼ばれ、ユーザに音声信号の音響特性を特徴付けるためにクライアント側から送られてくる音声パラメータのいくつかを示している。これらのパラメータは、異なる性能を持つシステム（即ち、性能の低いＰＤＡから性能の高いデスクトップまでの全てに関しての）において迅速、且つ普遍的に決定される事実を含む種々の理由により選択され、操作に関連した多数の有用な認識のために適合し、比較的狭い帯域のリンクを介して迅速に送出されるように比較的小さく、コンパクトである。従って、これらのパラメータは、後続のサーバ側において十分に且つ迅速に認識処理が完結できるように使用できるように、最小量の情報を示す。
【００８６】
音声パラメータを増強するために、信号エネルギのロガリズムの形式におけるエネルギ条件が付加される。従って、ＲＭＳエネルギは１２ＭＦＣＣに付加されて、１３の係数を生成する。これらの係数は、ユーザのクライアントシステムから遠隔サーバに圧縮状態で昇進される部分的に処理された音声データを生成する。
【００８７】
本音声認識システムの性能は、サーバ側において時間導関数を計算し、基本的静的ＭＦＣＣパラメータに加算することによって大幅に強化される。これら二つの他の組の関数−（実際にいくつかのフレームにわたって測定された）フレームからフレームまでの１３の値における変化を示すデルタ及び加速係数は、音声信号の初期の処理を完了するための第二の部分的音声信号処理段階中に計算され、後者が受け取られた後に係数の元の組に加算される。これらのＭＦＣＣは、デルタ及び加速係数とともに、音声データに関する適切なＨＭＭの決定に用いられる上記した発言ベクトルＯtを構成する。
【００８８】
デルタ及び加速係数は、以下の回帰式を用いて計算される。
【００８９】
dt = Σθθ=1[ct+θ - ct-θ]/2Σθθ=1θ2
【００９０】
ここで、ｄtは対応する静的係数に関して計算された時間ｔのデルタ係数である
【００９１】
dt = [ct+θ - ct-θ]/2θ
【００９２】
音声認識システムの一般的な独立的な実施において、ＳＲエンジンの全体が単一のクライアントにより実行される。換言すれば、上記の第一及び第二の部分的処理段階は、クライアントのコンピュータにおいてＲＯＭ又はソフトウエアコードのルーチンにより動作するＤＳＰ（又はマイクロプロセッサ）によって実行される。
【００９３】
逆に、いくつかの理由、特にコスト、技術的性能及びクライアントのハードウエアの均一性の理由から、本ＮＬＱＳシステムは、分割または分散された方法を採用する。ある種の処理はクライアント側において行われるが、主要な音声認識エンジンは、集約的配置されたサーバ又は多数のサーバ上で動作する。より具体的には、上述のように、音声信号の捕捉、ＭＦＣＣベクトルの抽出及び圧縮は、第一の部分処理段階においてクライアントマシンにより実行される。ルーチンは、而して合理化されて、ブラウザプログラム（例えば、プラグインモジュール、ダウンロード可能なアプレットとしても）実行するために十分に簡素化され、使用及び利用を最大に容易化する。従って、非常に性能の低いクライアントのプラットフォームをもサポートすることが出来、予測される多数のサイトにおける本システムの使用を可能とする。一次ＭＦＣＣは、次いでダイアルアップによるインターネット接続、ＬＡＮ接続、ワイヤレス接続等のチャンネルを介してサーバに送られる。伸張後に、デルタ及び加速係数がサーバにおいて計算されて、初期の音声処理段階を完了し、結果として得られる発言ベクトルＯtが決定される。
【００９４】
音声認識エンジンの概要
音声認識エンジンもサーバに配置され、ワードレベルネットワーク、辞書及びＨＭＭの組からコンパイルされるＨＴＫに基づく認識ネットワークに基づいている。認識ネットワークは、アークにより接続されたノードの組により構成される。各ノードは、ＨＭＭモデル又はワードエンドである。各モデルのノードは、それ自体アークによって接続された状態で構成される。而して、コンパイルが完了すると、音声認識ネットワークは、遷移により連結されたＨＭＭ状態で構成される。Ｔフレームの既知でない発言入力に関して、ネットワークの入口ノードから出口ノードへの全てのパスはＴＨＭＭ状態を通る。これらのパスのそれぞれは、各パス内の個別の遷移のｌｏｇ確率及び対応する発言を発生する放出状態のｌｏｇ確率を加算することにより計算される。ビタビデコーダの機能は、最も高いｌｏｇ確率を持つパスをネットワーク上で見つけることである。この検出には、トークンパッシングアルゴリズムが用いられる。多数のノードを持つネットワークにおいて、勝者となり得るこれらのトークンの伝搬を許容することのみによって、計算時間が減少する。この処理は一括消去と呼ばれる。
【００９５】
自然語処理装置
データベースへの典型的な自然語インターフェースにおいて、ユーザは、例えば英語等の彼／彼女の自然語により質問を入力する。システムは、これを解釈し、問い合わせ言語表現に翻訳する。次いで、システムは、問い合わせ言語表現を用いて質問を処理し、サーチに成功すれば、結果を示すレコードセットは、生のテキスト又は画像形式の何れかにフォーマットされて英語で表示される。優れて動作する自然語インターフェースは多くの技術的要求事項を含んでいる。
【００９６】
例えば、これは頑丈で無ければならず、「デパートの売り上げは(what's the departments turnover)」のセンテンスにおいて、ワードwhats=what's=what isを決定する。また、departments = department'sを判定しなければならない。頑丈であることに加えて、自然語インターフェースは、言語学的、構造的、参照及び省略による曖昧さ等の自然語におけるいくつかの形式の曖昧さを識別する必要がある。これらの要求の全ては、トークン化、タグ付け、グループ化の基本的言語形態学的動作を行う一般的な能力に加えて、本発明により実施される。
【００９７】
トークン化は、テキストを個別の文字よりも大きいが句やセンテンスよりも小さい一連のトークン又は利用可能な有意な単位として扱うテキスト分析器により行われる。これらは、ワード、ワードの分離可能な部分及び句読点を含んでいる。各トークンはオフセットや長さに関連付けられる。トークン化の第一段階は、入力されたテキストから個別のトークンを抽出するセグメント化処理であり、入力されたテキスト内に由来する各トークンのオフセットを記録する。トークン化装置の出力は、各トークンのオフセット及びカテゴリをリストする。テキスト分析の次の段階において、タグ付け装置は、内蔵する形態分析器を用いて句、センテンス中の各ワード／トークンの検索を行い、音声の全ての部分を内部的にリストする。出力は、音声記録の部分にタグを付した各トークンによる入力列である。最後に、句抽出装置又は句分析装置として機能するグループ化装置は、句を形成するワードのグループを決定する。全ての近代的言語処理体系の基本であるこれら三つの動作は、ユーザの質問に対する単一の最良の回答を決定するための最適化されたアルゴリズムを全て実施する。
【００９８】
ＳＱＬデータベース及び全文問い合わせ
本システムの他の重要な構成要素は、ＳＱＬデータベースである。このデータベースは、テキストを記憶するために用いられ、特に回答−質問の対がデータベースの全文テーブルに格納される。さらに、データベースの全文検索能力が、全文検索の実行を可能とする。
【００９９】
デジタル的に記憶された全ての情報は、非構造のデータ、一次テキストの形式であるが、ヴァーチャー(varchar)やテキスト等の文字に基づく欄による公知のデータベースにこの原文データの格納が可能となる。データベースから原文データを効果的に検索するために、技術は、原文データに対する質問の発生及びＮＬＳＱシステムの場合のように回答を与える有意な方法で回答の検索を実行する必要がある。
【０１００】
二つの主要なタイプの原文サーチがある。特性（Property）−このサーチ技術は、最初に文書をフィルタにかけて著者、主題、タイプ、ワード数、印刷ページ数、最後に書かれた日付等の特性を抽出し、次いで、これらの特性に対してサーチを行う。全文−このサーチ技術は、まず文書中のノイズでないワードのインデックスを作成し、このインデックスにより次いで言語のサーチ及び近接サーチをサポートする。
【０１０１】
この特定のＲＤＢＭにおいて二つの付加的技術が実施される。ＳＱＬサーバは一体化される。サーチサービス−、インデックスエンジン及びサーチと呼ばれ全文のインデックス付け及びサーチサービス及び全文ＳＱＬ拡張及びマップを受け入れる構文解析ツールはサーチエンジンによる処理を可能な形式とする。
【０１０２】
全文能力を持つデータベース(full-text-capable database)からのプレーンテキストの全文検索の実施において四つの主要な態様を含んでいる。全文検索のために登録されたテーブル及び欄の定義の管理と;登録された欄内のデータのインデックス付け−インデックス付け処理は文字列を走査し、ワードの境界（これは単語分け（word breaking)と呼ばれる）を決定し、全てのノイズとなるワードを排除し（これはストップワード(stop words）と呼ばれる）、残りのワードに全文インデックスを与える;占有する全文インデックスに関する登録された欄に対して質問を発生する；全文インデックスの同期を保持するために登録された欄のデータにその後に生じた変化がインデックスエンジンに伝搬することを確保する。
【０１０３】
インデックス付け、問い合わせ及び同期処理のための潜在的な設計原理は、全文検索のために登録された全てのテーブルに全文ユニークキー欄（又は単一欄基本キー）が存在していることである。全文インデックスはノイズでないワードに対するエントリを各行のキー欄の値とともに各行に有している。
【０１０４】
全文検索を処理する場合、サーチエンジンはサーチ基準に一致する行のキーの値をデータベースに返す。
【０１０５】
全文管理処理は、全文検索のための関連したテーブル及びその欄を指定することによって開始される。カスタマイズされたＮＬＱＳの格納された手順は、まず全検索に都合の良いテーブル及び欄を登録するために使用される。その後に、格納された手順による別の要求が発生され、全文インデックスを格納する。この結果、潜在的インデックスエンジンが呼び出され、非同期インデックスの格納が開始される。全文インデックス付けはいずれの有意なワードが使用されたか及びそれらがどこに位置するかを検索する。例えば、全文インデックスは、「ＮＬＱＳ」のワードが、ＰｒｏｄｕｃｔＩＤ６に関連した行のＤｅｖＴｏｏｌｓテーブルのＡｂｓｔｒａｃｔ欄のワード番号４２３とワード番号９８２に見られる。このインデックス構造は、インデックスされた語を含む全てのアイテムの効率的検索をサポートするとともに、句検索や近接サーチといった上級のサーチもサポートする。（句検索の例は、「白象(white elephant)」を検索するものであり、「白(white)の後に「象」が続く、近接サーチの例は,「大きい(big)」及び「家(house)」を検索するものであり、「大きい」が「家」に近接して生じる。）全文インデックスが膨大になることを防止するために、”ａ”、”ａｎｄ”、”ｔｈｅ”等は無視される。
【０１０６】
トランズアクト−ＳＱＬ語への拡張は、全文問い合わせを構成するために使用される。ＮＬＱＳにおいて使用される二つのキーとなる述語は、ＣＯＮＴＡＩＮＳとＦＲＥＥＴＥＸＴである。
【０１０７】
ＣＯＮＴＡＩＮＳ述語は全文の登録欄における値が幾つかのワード及び句を含んでいるか否かを決定するために使用される。特に、この述語は、
・ワード又は句
・ワード又は句の接頭語
・近接するワード又は句
・他の語の屈折形であるワード（例えば、"drive"は"drives", "drove", "driving"及び"driven"の基本形である。）
・それぞれに異なる重みを割り当てられたワード又は句の組
の検索に用いられる。
【０１０８】
ＳＱＬサーバのリレーショナルエンジンは、ＣＯＮＴＡＩＮＳ及びＦＲＥＥＴＥＸＴ述語を認識し、述語中に参照されている欄が全文検索のために登録されていることの確認等の最小の構文及び意味のチェックを行う。問い合わせの実行中に、全文の述語及び他の関連した情報が全文検索部に送られる。さらに構文及び意味の確認後に、サーチエンジンが起動され、全文検索条件を満足するテーブル中の行を特定する独自のキー値を返す。さらに、ＦＲＥＥＴＥＸＴとＣＯＮＴＡＩＮＳに対して、ＡＮＤ、ＬＩＫＥ、ＮＥＡＲ等の他の述語が組み合わされて、カスタマイズされたＮＬＱＳのＳＱＬ構造を生成する。
【０１０９】
ＳＱＬデータベースの全文問い合わせのアーキテクチャ
全文問い合わせのアーキテクチャは、以下のいくつかの構成要素によって構成される−全文クエリー部、ＳＱＬサーバリレーショナルエンジン、全文プロバイダ及びサーチエンジンである。
【０１１０】
ＳＱＬデータベースの全文クエリー部は、ＳＱＬサーバからの全文述語又はローセット値関数(rowset-valued function)を受け付け、述語の一部を内部フォーマットに変換し、これをローセットの一致を返すサーチサービスに送る。ローセットは、次いでＳＱＬサーバに送り返される。ＳＱＬサーバはこの情報を用いて結果セットを生成し、これをクエリーの送信者に返す。
【０１１１】
ＳＱＬサーバリレーショナルエンジンは、ＣＯＮＴＡＩＮＳ及びＦＲＥＥＴＥＸＴ述語とともにＣＯＮＴＡＩＮＳＴＡＢＬＥ（）及びＦＲＥＥＴＥＸＴＴＡＢＬＥ（）ローセット値関数を受け入れる。解析期間中に、このコードが、全文検索のために登録されていない欄に問い合わせをしている等の状態をチェックする。有効であれば、ランタイムに、前方検索条件(ft_search_condition)及び文脈情報は、全文プロバイダに送出される。結局のところ、全文プロバイダは、ローセットをＳＱＬサーバに返し、元の問い合わせに対する結合（特定された又は暗示された）に使用される。全文プロバイダは、前方検索条件を解釈し、確認し、全文検索条件の適当な内部表現を構成して、サーチエンジンに送出する。結果は、前方検索条件を満足する行のローセットによってリレーショナルエンジンに戻される。
【０１１２】
クライアント側システム１５０
自然語問い合わせシステム１００のクライアント側システム１５０のアーキテクチャは、図２により詳細に示されている。図２に関して、クライアント側システム１５０により達成される三つの主要な処理を以下に示す。ＳＲＥ２０１、通信２０２及びＭＳエージェント２０３ルーチンで構成される初期化処理２００Ａと；ａ）ＳＲＥ２０４と通信２０５で構成されるユーザ音声の受信２０８とｂ）サーバから回答を受信２０７及びアンイニシャライゼーション(un−initialization)処理の二つのサブルーチンで構成される反復処理２００Ｂである。最後に、アンイニシャライゼーション処理２００Ｃは、ＳＲＥ２１２，通信２１３及びＭＳエージェント２１４の三つのサブルーチンで構成される。上記の三つの処理のそれぞれは、以下のパラグラフにおいて詳細に説明する。こうした処理及びルーチンの実行は、クライアントプラットフォーム毎に変化し、ある環境においては、こうした処理は専用ＤＳＰにより実行されるハードコード化(hard-coded)ルーチンによって実施可能であるが、共用のホストプロセッサによって実行されるソフトウエアとして実施することも可能であり、また両者の組み合わせを用いることも出来ることは当業者に理解されるであろう。
【０１１３】
クライアントシステム１５０における初期化
クライアント側システム１５０の初期化は図２−２に示されており、一般に、クライアント側音声認識エンジン２２０Ａ、ＭＳエージェント２２０Ｂ及び通信処理２２０Ｃの三つの別の初期化処理により構成される。
【０１１４】
音声認識エンジン２２０Ａの初期化
音声認識エンジン１５５は、２２０Ａで示されたルーチンを用いて初期化され、構成される。最初に、ＳＲＥＣＯＭライブラリが初期化される。次いで、メモリ２２０はソースを保持するように割り当てられ、コーダオブジェクトがルーチン２２１により生成される。コンフィギュレーションデータファイル２２１Ｂからのコンフィギュレーションファイル２２１ＡのロードもＳＲＥライブラリの初期化と同時に行われる。コンフィギュレーションファイル２２１Ｂにおいて、コーダへの入力のタイプ及びコーダの出力のタイプが宣言される。こうしたルーチン及び動作等は周知であり、それらは多数の相当に簡単な方法を用いて実行される。従って、それらについてはここでは詳述しない。次に、発言の音声及び無音成分は、ルーチン２２２を用いて周知の手順により目盛り付けされる。音声及び無音成分を目盛り付けするために、ユーザは好ましくは文を発言し、表示画面のテキストボックスに表示される。ＳＲＥライブラリは、将来のユーザの発言の無音及び音声成分を検出するために必要となるノイズ及び他のパラメータを予測する。
【０１１５】
ＭＳエージェント２２０Ｂの初期化
ＭＳエージェント２２０Ｂの初期化及びセットアップに用いられるソフトウエアコードは、図２−２に示されている。ＭＳエージェント２２０Ｂルーチンは、動画エージェント１５７（図１）の動作を調整し、取り扱うことを受け持つ。この初期化は、以下のステップにより構成される。
【０１１６】
１．ＣＯＭライブラリ２２３を初期化する。この部分のコードは、周知の制御を行うアクティブＸ制御を使用するために必要となるＣＯＭライブラリの初期化を行う。
２．エージェントサーバ２２４のインスタンスの生成−この部分のコードは、エージェントアクティブＸ制御のインスタンスを生成する。
３．ＭＳエージェント２２５のロード−全貌、形状、サイズ等のようなエージェントの特性に関する一般的パラメータデータを含む特定されたファイル２２５ＡからのＭＳエージェント特性をロードする。
４．キャラクタインターフェース２２６の獲得−この部分のコードは特定されたキャラクタに関する適当なインターフェースを獲得する：キャラクタは、ユーザに提供できる異なる制御／対話能力を有している。
５．エージェントキャラクタオプション２２７にコマンドを追加する−この部分のコードは、エージェントキャラクタがロードされる時に、システムトレイのアイコンをクリックすることによってアクセス可能なエージェントのプロパティシートにコマンドを付加する。例えば、キャラクタは話すことが出来、どのように彼／彼女が動くか、ＴＴＳのプロパティ等
６．エージェントキャラクタを表示２２８−この部分のコードは、ユーザによって見ることが出来るように、エージェントキャラクタを表示する。
７．AgentNofifySink−イベントを取り扱うためのもの。この部分のコードは、AgentNotifySinkオブジェクト２２９を生成し、それを２３０に登録し、エージェントプロパティインターフェース２３１を獲得する。エージェントキャラクタに関するプロパティシートは使用するルーチン２３２に割り当てられる。
８．キャラクタのアニメーションを行う２３３−この部分のコードはユーザのＮＬＱＳ１００に迎えるために特定のキャラクタにアニメーションを行わせる。
【０１１７】
上記によりＭＳエージェントを初期化するために必要となるシーケンス全体を構成する。ＳＲＥルーチンと同様に、ＭＳエージェントルーチンは、本技術に基づいて、いかなる適当な公知の手法により当業者が実施可能である。こうしたルーチンの特定の構造、動作は重要ではないので、それらについては詳細に説明しない。
【０１１８】
好適実施例において、ＭＳエージェントは特定の用途に関して適当な外観及び能力を備えるように構成される。例えば、遠隔学習への使用の場合、エージェントは、大学教授の外観や癖、態度、ジェスチャーを有している。他の視覚的小道具（黒板、教科書等）をエージェントは使用することが出来、ユーザに実際の教育環境に居たときの経験を思い起こさせる。エージェントの特徴はクライアント側１５０で構成され及び／又は特定のウエブページからのコンフィギュレーションデータ及びコマンドに応じてブラウザプログラム（図示せず）によって実行されるコードの一部により構成される。例えば、医療を提供している特定のウエブサイトでは、医者の視覚的イメージを使用することが好ましい。これら及び多くの他の変更は、ユーザによる人間的でリアルタイムな対話の経験をよりよいものとするために当業者によって採用される。
【０１１９】
通信リンク１６０Ａの初期化
通信リンク１６０Ａの初期化は図２−２の処理２２０Ｃを参照しながら説明する。図２−２に関して、この初期化は以下のコード成分により構成される。インターネット接続２３４−この部分のコードはインターネット接続を行い、接続のためのパラメータをセットする。次いで、セットコールバック状態ルーチン２３５が接続状態をユーザに知らせるためにコールバック状態をセットする。最後に、新しいＨＴＴＰインターネットセッション２３６が、新しいインターネットセッションを開始する。通信リンク１６０の詳細及びセットアップ処理２２０Ｃは重要ではなく、プラットフォームごとに変化する。ある場合、ユーザは低速のダイヤルアップ接続、専用の高速交換接続（例えば、Ｔ１）、常時接続ｘＤＳＬ、ワイヤレス接続等を使用する。
【０１２０】
クエリー／回答の反復処理
図３に示すように、初期化が完了すると、反復クエリー／回答処理が、ユーザがクエリーを開始するためにスタートボタンを押圧したときに開始される。図３に関して説明すれば、反復クエリー／回答処理は、クライアント側システム１５０のルーチンを実行するユーザ音声の受信２４０及びユーザ回答の受信２４３の、二つの主なサブプロセスによって構成する。ユーザ音声の受信２４０ルーチンは、ユーザからの音声を受信し、一方ユーザへの回答の受信２４３ルーチンは、テキスト−音声エンジン１５９によりユーザに対する音声に変換するために、サーバからのテキストの形式でユーザの質問に対する回答を受信する。ここで使用されているように、「クエリー」の用語は最も広い意味で用いられ、質問、コマンド又はシステムによって制御変数として使用されるある形式の入力を意味している。例えば、クエリーは、特定の話題に向けられた質問で構成され、例えば、遠隔学習アプリケーションにおける「ネットワークは何ですか」といったものである。電子商取引アプリケーションにおいて、クエリーは、例えば「マーク・トーエンによる本を全てリストせよ」といったコマンドである。同様に、遠隔学習アプリケーションにおける回答は、テキスト−音声エンジン１５９により可聴形式とされるテキストで構成されるが、これは、特定のアプリケーションの要求に応じて図形画像、サウンドファイル、ビデオファイル等の他の形式のマルチメディア情報とすることが出来る。クライアント側ユーザ音声受信２４０及びユーザへの回答の受信２４３ルーチンに必要な構造、機能、性能等に関して本発明の技術が与えられると、当業者はこれを種々の方法により実施することが出来る。
【０１２１】
ユーザ音声の受信−図３に示すように、ユーザ音声の受信ルーチン２４０は、ＳＲＥ２４１と、通信２４２処理とで構成され、両者は、ユーザの発言を受信し、部分的に処理するクライアント側システム１５０のルーチンとして構成される。ＳＲＥルーチン２４１は、コーダオブジェクトがソースオブジェクトからの音声データを受け取るように準備されたコーダ２４８を使用する。次に、スタートソース２４９ルーチンが開始される。この部分のコードは、コーダオブジェクトに与えられるソースオブジェクトを用いてデータ検索を開始する。次に、ＭＦＣＣベクトル２５０が、無音を検索されるまで、発生された音声から連続的に抽出される。前述のように、これは入力された音声信号の処理の第一段階を示すもので、好適実施例においては、上記にすでに説明した理由によりＭＦＣＣベクトルの計算のみに限っている。これらのベクトルは、部分的に処理された音声信号の１３の別の数値に関する１２のケプストラム係数及びＲＭＳエネルギ条件を含んでいる。
【０１２２】
ある環境において、使用可能な計算リソース、サーバ側システム１８０において使用可能なデータリンク１６０Ａにおける送信帯域、データ中においてデータの送信に使用される送信機の速度等に応じてＭＦＣＣデルタパラメータ及びＭＦＣＣ加速パラメータはクライアント側システム１５０によって計算される。これらのパラメータは、（リソースを測定するために目盛り付けルーチンのいくつかのタイプを用いて）ＳＲＥ１５５の初期化時にクライアント側システム又はユーザによる直接制御によって自動的に決定されて、信号処理の分担をケースバイケースで最適化することが出来る。いくつかの用途においても、サーバ側システム１８０に、入力された音声信号の処理を完了するためのリソースやルーチンが欠けている場合がある。従って、いくつかの用途において、信号処理の負荷の割り当てを変化させることが出来、音声信号処理の両方の段階をクライアント側システム１５０で行うことが出来、音声信号を部分的にではなく完全に処理し、サーバ側システム１８０でクエリーに変換するために送信することも出来る。
【０１２３】
好適実施例において、質問／回答の見地から十分な精度およびリアルタイム性能を確保するために、クライアント側システムにおいて十分なリソースの使用を可能として毎秒１００フレームの音声データの部分的な処理を行い、リンク１６０Ａを介して送信出来るようにする。音声認識処理を完了するために必要な最小限の情報（１３の係数のみが必要）が送信されるので、他の潜時（即ち、クライアント側の計算潜時、パケット形成潜時、送信潜時）は最小限であり、システムは高度に最適化されたリアルタイム性能を達成する。本発明の原理は、ＳＲＥ（即ち、非ＭＦＣＣベース）によって入力音声信号を分解するために他の方法が使用される他のＳＲアプリケーションへの拡張が可能であることは、明らかである。唯一の基準は、ＳＲ処理が同様に複数の段階に分割可能であることであり、異なる段階の負荷は、システム全体の達成目標や要求などに依存して、リンク１６０Ａの両側で取り扱うことが出来ることである。本発明の機能性は、システム毎を基準に達成され、各具体的な実施のために必要な予測される典型的な最適化が必要である。
【０１２４】
従って、本発明は、クライアント側システム１５０によって計算され、符号化され、送信される情報の量に応じて調整される応答率性能を達成する。リアルタイム性能が最も重要な用途において、最小量の抽出された音声データが送信されるようにして潜時を減少させ、他の用途においては、処理、符号化、送信される抽出された音声の量を変化させることが出来る。
【０１２５】
通信−送信モジュール２４２は、好適実施例においてはインターネットで掲載されるデータリンク１６０Ａを介してクライアントからサーバへのデータの送信を行うために使用される。上記に説明したように、符号化されたＭＦＣＣベクトルによって構成されるデータは、サーバ側の音声認識エンジンによって使用されて、音声認識復号が完了される。通信シーケンスは以下の通りである。
【０１２６】
OpenHTTPRequest２５１−この部分のコードはまずＭＦＣＣベクトルをバイト列に変換し、次いで、ＨＴＴＰとして知られるプロトコルとの互換を計るようにバイトを処理する。このプロトコルは、周知であり、他のデータリンク、他の適当なプロトコルも使用することが出来る。
【０１２７】
１．ＭＦＣＣバイト列の符号化２５１−この部分のコードは、ＭＦＣＣベクトルを符号化してＨＴＴＰを介してサーバに送信できるようにする。
２．データ送信２５２−この部分のコードは、ＭＦＣＣベクトルを、インターネット接続及びＨＴＴＰプロトコルを用いてサーバに送信する。
【０１２８】
サーバの応答を待つ２５３−この部分のコードは、データリンク及びサーバ側システム１８０から到来する応答を監視する。概説すれば、ＭＦＣＣパラメータは、入力される音声信号からオンザフライで抽出され、または観察される。次いで、それらはＨＴＴＰバイト列に符号化され、無音が検出される前にサーバにストリーミングの要領で送信される、即ち発声が完了する前にサーバ側システムに送信される。ユーザが話している間にデータを送信、処理出来るので、本発明のこの態様は、リアルタイム動作を容易とする。
【０１２９】
サーバからの回答を受信する２４３は、図３に示す以下のモジュールで構成される：ＭＳエージェント２４４，テキスト−音声エンジン２４５及び受信モジュール２４６である。これら三つのモジュールは、サーバ側システム１８０からの回答を受信するために連関動作する。図３に示すように、受信処理は、クライアント側システム１５０の受信ルーチンとして動作する三つの別のプロセスで構成される。最良の回答を受信する２５８は、データリンク１６０Ｂ（ＨＴＴＰ通信チャンネル）を介して最良の回答を受信する。回答は、２５９において伸張され、次いでコード２６０によりＭＳエージェント２４４に送られ、そのコード部２５４によって受信される。ルーチン２５５は、次いで、テキスト−音声エンジン２５７を用いて回答が発声される。勿論、テキストは、クライアント側システムによって用いられるモニタにフィードバックの目的で表示することが出来る。テキスト−音声エンジンは、（英語、仏語、独語、日本語等）の具体的な言語の用途に対して適切な自然語音声データファイル２５６を使用する。前述のように、回答がテキスト以上のものである場合、図形画像、音、ビデオチップ等によりユーザに回答を与える。
【０１３０】
アンイニシャライゼーションの手順と処理を図４に示す。これらの機能モジュールは、クライアント側システム１５０の基本コンポーネントをアンイニシャライゼーションするために用いられるものであり、これらの基本コンポーネントには、ＳＲＥ２７０、通信２７１およびＭＳエージェント２７２アンイニシャライゼーション手順が含まれている。ＳＲＥ２２０Ａをアンイニシャライゼーションするために、初期化フェーズで割当てられたメモリは、コード２７３によって解放され、この初期化フェーズの間に生成されたオブジェクトは、コード２７４によって削除される。同様に、図４に示すように、通信モジュール２２０Ｃをアンイニシャライゼーションするために、サーバとの間ですでに確立されたインターネット接続を、通信アンイニシャライゼーション手順２７１のコード部２７５によって閉じる。次に、初期化の段階で生成されたインターネットセッションもまた、手順２７１によって閉じる。ＭＳエージェント２２０Ｂのアンイニシャライゼーションのために、図４に示すように、ＭＳエージェントアンイニシャライゼーション手順２７２は、最初に、手順２７７を用いて、コマンド・インターフェース２２７を解放する。これにより、手順２２５によってエージェント文字のローディングの間に、プロパティシートに追加されるコマンドが発行される。次に手順２２６によって初期化された文字インターフェースが、手順２７８によって解放され、エージェントがステップ２７９でアンロードされる。さらに、ステップ２８０でシンクオブジェクト・インターフェースも解放され、その後、ステップ２８１でプロパティシート・インターフェースが解放される。次に、ステップ２８２でエージェント通知シンクがエージェントを登録解除し、最後に、ステップ２８３でエージェント・インターフェースが解除され、これにより、図２−２に示した初期化ステップで割当てられた全てのリソースが解除されるものとなる。
【０１３１】
図４に示したようなアンイニシャライゼーションの処理と手順の特定の実装方法は、上述した他の手順と同様に、クライアントおよびサーバのプラットフォームに応じて変更されることは、当該技術分野に精通した者にとっては、明白なものである。このような手順の構造、動作などは、従来例において既知のものであり、これらは、多くの直接的な方法を用いることにより実装することが可能である。従って、これらの変更については、詳細には言及しないものとする。
【０１３２】
サーバ側システム１８０の説明
序文
図１１Ａから図１１Ｃに、自然言語問い合わせシステム１００のサーバ側システム１８０に実装される処理群の一実施例の高レベルフローチャートを示す。本実施例においては、この処理は、音声入力信号を処理し、ユーザの問い合わせの意味を認識し、各問い合わせに対する適切な回答や応答を求めるための、２ステップのアルゴリズムから構成されている。
【０１３３】
図１１Ａに示した第一ステップは、高速の第一刈り込み機構としてのものであり、以下の処理を含んでいる。音声入力信号を処理した後、ユーザの問い合わせはステップ１１０１で認識され、問い合わせ文の文字列がステップ１１０７で自然言語エンジン１９０（図１参照）に送られ、同時にステップ１１０２でＤＢエンジン１８６（同様に図１参照）に送られる。ここで「認識される」とは、以前に説明したＨＭＭ手法によって、ユーザの問い合わせが特有の自然言語文の文字列に変換されることを指す。
【０１３４】
ＮＬＥ１９０では、文字列は、ステップ１１０８で、形態素言語解析の処理を経て、文字列はトークン化され、タグが付与され、タグ付きトークンが分類される。次に、ステップ１１０９で、文字列の名詞句（ＮＰ）が格納され、ＤＢプロセスでＤＢエンジン１８６が利用できるように、ステップ１１１０で、複写、転送される。図１１Ａに示すように、ステップ１１０２でＤＢエンジン１８６に転送されたユーザの問い合わせに対応する文字列は、ＮＬＥ１９０から受信したＮＰとともに用いられて、ステップ１１０３でＳＱＬクエリーが構成される。次に、ステップ１１０４で、ＳＱＬクエリーが実行され、ユーザの問い合わせに対応したもっともらしい質問の記録セットが、ステップ１１０５で全文検索の結果として得られ、さらに、ステップ１１０６で、配列の形式でＮＬＥ１９０に返送される。
【０１３５】
上述したように、サーバ側処理の第一ステップは、効率的で高速な刈り込み機構として作用し、極めて短時間のうちに、ユーザの実際の問い合わせに対応した的確な検索結果をもっともらしい文章の候補に絞りこむようにするものである。
【０１３６】
図１１Ｂに示した第二ステップは、上記の第一ステップと対比すると、認識処理の中の、より正確な選択処理部として捉えられるものである。このステップは、ユーザの問い合わせを表す可能性のある候補として全文検索によって得られ、配列状に格納された質問文の各々を言語処理するところから始まる。これらの格納された質問文の処理は、ＮＬＥ１９０で、以下のように進められる。ＳＱＬ全文検索によって得られた記録セットに対応した質問文の配列中の各質問文について、ステップ１１１１で、形態素言語解析を行う。この処理で、検索された質問文の候補に対応する文字列はトークン化され、タグが付与され、タグ付きトークンが分類される。次に、ステップ１１１２で、文字列中の名詞句を取り出し格納する。この処理は、判断点１１１３によって繰り返しの判定を受け、得られた問い合わせ文の候補についてＮＰを求めて格納するように、ステップ１１１８、１１１１、１１１２、１１１３が繰り返される。配列中の問い合わせ文の候補の各々についてＮＰが取り出されると、ステップ１１１４で、ＮＰ値の大きさにもとづいて、配列中の問い合わせ分の候補の各々と、ユーザの問い合わせとを比較する。配列中にもはや処理すべき問い合わせ文がないとステップ１１１７で判定されると、ステップ１１１７Ａで、ユーザの問い合わせに関して最大のＮＰ値をもつ格納された問い合わせを特定し、これをユーザ問い合わせにもっとも適合した格納された問い合わせと判断する。
【０１３７】
特に、認識処理の第二ステップは、複数の文字列がトークン化され複数のＮＰについて比較する必要があるため、先の第一ステップよりも計算量が多いということが分かる。しかし、第一ステップが、迅速かつ効率的に、評価すべき候補をかなりの程度になるまであらかじめ絞り込んでおくことがなければ、これは現実的とは言えない。従って、本発明での、この計算量の多さは、問い合わせ文の認識処理全体でより高精度の認識結果をもたらすことに寄与するため、その特徴はかえって価値のあるものとなる。従って、この点について、問い合わせ文認識の第二ステップでは、システム全体を通して精度を確保することを目的とし、これに対し、第一ステップは、ユーザにとってリアルタイムの応答感覚が提供できる十分な速度を提供することを目的としている。
【０１３８】
図１１Ｃに示すのは、問い合わせ、応答処理の最後の部分であり、ユーザに対して、適切な適合した回答、応答を提供する処理である。まず、ステップ１１２０で、格納された問い合わせ文中で適合したものを特定する。次に、ステップ１１２１で、特定された適合質問への回答に対応したファイルパスを取り出す。さらに処理を続け、ステップ１１２２で、このファイルパスに基づき回答を取り出し、最後にステップ１１２３で、回答を圧縮しクライアント側システム１５０に送る。
【０１３９】
上述の内容は、サーバ側システム１８０のＮＬＱＳシステムの各部分の基本要素、動作、機能および特性の概観を説明しようとしたものである。以下に、各サブシステムの詳細を説明する。
【０１４０】
サーバ側システム１８０で用いられるソフトウエアモジュール
ＮＬＱＳシステムのサーバ側システム１８０で用いられる、主要なソフトウエアモジュールを、図５に示す。これらは、一般的に、以下の要素を含んでいる。通信モジュール５００は、（図１のＳＲＥサーバ側１８２によって実行されるものであり、以下に詳説する）コミュニケーションサーバＩＳＡＰＩ５００Ａと、（図１のＤＢエンジン１８６によって実行される）データベースプロセスＤＢプロセスモジュール５０１と、（図１のＮＬＥ１９０によって実行される）自然言語エンジンモジュール５００Ｃと、ＮＬＥプロセスモジュール５００ＣとＤＢプロセスモジュール５００Ｂとの間のインターフェース５００Ｂを含んでいる。ここで示すように、コミュニケーションサーバＩＳＡＰＩ５００Ａは、サーバ側音声認識エンジンと、クライアント側システム１５０とサーバ側システム１８０との間に配置されたな適切な通信インターフェースとを含んでいる。さらに、図５によれば、自然言語問い合わせシステム１００のサーバ側論理は、２つのダイナミックリンクライブラリコンポーネント、通信サーバＩＳＡＰＩ５００とＤＢプロセス５０１を含むことに特徴があるといえる。通信サーバＩＳＡＰＩ５００は、サーバ側音声認識エンジンモジュール５００Ａ、自然言語エンジンモジュール５００ＣとＤＢプロセス５０１との間のインターフェースモジュール５００Ｂ、さらに自然言語エンジンモジュール５００Ｃという、３つのサブモジュールから構成されている。
【０１４１】
ＤＢプロセス５０１は、ＳＱＬデータベースに接続し、ユーザの問い合わせに応じて構成されるＳＱＬクエリーを実行することを基本機能とするモジュールである。さらに、このモジュールは、自然言語エンジンモジュール５００Ｃから一端回答が得られた時のファイルパスに基づき、その後は、この正確な回答を取り出すための論理に接続するインターフェースを持っている。
【０１４２】
サーバ側システム１８０上の音声認識サブシステム１８２
サーバ側音声認識エンジンモジュール５００Ａは、サーバ側１８０での音声認識エンジン１８２（図１）の必要な機能と動作とを行う分散コンポーネントの一群である。これらのコンポーネントは、既知のように、サーバ側１８０で実行されるソフトウア処理として実装することができる。図４Ａには、サーバ側の音声認識コンポーネントの動作をより詳細に展開したものを示し、以下でこれを説明する。
【０１４３】
サーバ側ＳＲＥモジュール５００Ａの部分６０１の内部では、クライアント側システム１５０で抽出され、通信チャネル１６０を介して送られた音声信号の音響特性に対応したバイナリＭＦＣＣベクトルバイトストリームを受信する。ＭＦＣＣ音響ベクトルは、符号化されたＨＴＴＰバイトストリームから以下のように復号化される。ＭＦＣＣベクトルは、組み込みＮＵＬＬ文字を含んでいるため、ＨＴＴＰプロトコルを使うようなサーバ側に対しては、これらのベクトルはこのままの形式では送出することができない。従って、まず最初に、転送に先立って、クライアント側１５０でＭＦＣＣベクトルを符号化し、全ての音声データを、データ中にＮＵＬＬ文字が含まれないようなバイトストリームに変換する。バイトストリームの終端部には、ＨＴＴＰプロトコルを用いてインターネット１６０Ａ経由でサーバに転送されるバイトストリームの終了を示すように、単一のＮＵＬＬ文字が挿入される。
【０１４４】
前述したように、クライアントとサーバ間の待ち時間を維持、保存するために、より少ない数のバイトデータ（１３のＭＦＣＣ係数）をクライアント側システム１５０から、サーバ側システム１８０へ送る。これは、各プラットフォームに対して画一性を保証するために、自動的に行うか、もしくは、特定のアプリケーション環境によって調整することができる。例えば、サーバでデルタおよび加速係数を計算（さらに２６回の計算）するのに、クライアントでこれらを符号化し、転送し、ＨＴＴＰストリームから復号化するよりも短い時間で行えるのかを判定する場合などがそうである。一般的に、サーバ側システム１８０は、ＭＦＣＣデルタおよび加速パラメータを計算するのに、充実した装備を持っているのが普通であるため、この方が好ましい。さらに、クライアントのリソースに比べ、サーバのリソースの方が管理しやすく、すなわち、より信頼性のある予測可能なシステム全体の性能をもたらす上で、将来のアップグレードや最適化等がシステム全体で享受しやすいという事情がある。従って、本発明は、クライアントマシンが極めて貧弱で、音声入力データを入力して最小限の処理だけがこなせる程度のリソースしか持ち合わせないといった最悪のシナリオでさえも実施可能である。
【０１４５】
辞書の準備と文法ファイル
図４Ａにおいて、コードブロック６０５では、ユーザによって選択された（あるいは、特定のアプリケーションの内部でのユーザの状態から探り出された）様々なオプションを受信する。例えば、遠隔教育システムの例では、コース、チャプターおよび／またはセクションデータが通信される。他のアプリケーション（例えば、電子商取引）の場合には、製品の種類、製品のカテゴリ、製品のブランドなど、ユーザが彼／彼女のブラウザ中で閲覧するために使用される他のデータオプションが通信される。これらの選択されたオプションは、ユーザが対話処理プロセスの中で経験した背景に基づくものであり、従って、検索の範囲を限定し定義するものとなる。すなわち、この背景は、音声認識エンジン１８２（図１）に動的にローディングされ、ユーザの音声発話を解析する際のビタビ復号化のための文法と辞書である。音声認識を最適化するために、本実施例では、文法と辞書ファイルの両方を用いる。文法ファイルは、利用可能なユーザの問い合わせの世界を提供する。すなわち、認識すべき、全ての可能な用語を提供する。辞書ファイルは、文法ファイル中に含まれる各語の音素（語を発音する方法に関する情報。これは、インストールされる特定の自然言語ファイルに基づくものであり、例えば、ＵＫＥｎｇｌｉｓｈ（英国英語）あるいはＵＳＥｎｇｌｉｓｈ（米国英語）のようなものである）を提供する。もし、認識可能な特定の環境での全ての文章が、単一の文法ファイルに含まれているならば、その認識の精度は悪化し、この文法および辞書ファイルだけのローディング時間は、音声認識処理の時間に比べて短くなることは明白である。
【０１４６】
この問題を避けるためには、特定の文法を動的にロードし、ユーザの使用背景、例えば、遠隔教育システムでの場合の、コース、チャプターおよびセクションの選択状態に応じて、現状の文法として動的に構成することが考えられる。ユーザが読み取り書き取りしている所定のコース、チャプターおよびセクションに従って、文法および辞書ファイルを動的にローディングしたり、ユーザによって実行されるアプリケーションプログラムによって自動的にそのローディングを行うこともできる。
【０１４７】
第二のコードブロック６０２は、音声認識エンジン１８２（図１）の初期化を実装した部分である。クライアント側システム１５０から、文法ファイル名と辞書ファイル名とともに受信したＭＦＣＣベクトルは、このブロックに入力され、音声復号器を初期化する。
【０１４８】
図４Ａに示すように、初期化プロセス６０２は、以下のサブルーチンを用いる。まず、ルーチン６０２Ａで、ＳＲＥライブラリをローディングする。次に、コード６０２Ｂで、受信したＭＦＣＣベクトルを用い、外部ソースとして識別されるオブジェクトを生成する。コード６０２Ｃは、認識オブジェクトを格納するメモリを割当てる。次にルーチン６０２Ｄもまた、認識のために必要とされるオブジェクトを生成し初期化する。これらのオブジェクトは、ソース、コーダ、およびコード６０２Ｅにより生成される辞書の認識および結果ローディング、コード６０２Ｆにより生成される隠れマルコフモデル（ＨＭＭ）、およびルーチン６０２Ｇにより生成される文法ファイルのローディングである。
【０１４９】
図４Ａに示すように、音声認識６０３が次に呼び出される処理であり、通常は、クライアント側１５０での、ユーザの音声入力信号の処理の完了に呼応して実行されるが、前述したように、ＭＦＣＣベクトルがリンク１６０を介して伝送されたときには、部分的に（すなわち、ＭＦＣＣベクトルだけが第一フェーズで計算されるのみとする）処理されることが好ましい。サブルーチン６０２Ｂによって外部ソース中に生成された関数を用いて、このコードは、外部ソース６０３Ａから一度に一つづつＭＦＣＣベクトルを読み込み、これらをブロック６０３Ｂで処理し、クライアントで取り込まれたＭＦＣＣベクトルによって表された音声パターン中の語を認識する。この第二のフェーズの間、更に付け加えられた１３のデルタ係数と、１３の加速係数を認識処理の一部として計算に加え、全部で３９の前述した観測ベクトルＯｔが得られる。さらに、以前に定義した隠れマルコフモデル（ＨＭＭ）のセットを用いて、ユーザの発声に対応した語を、前述した方法で決定する。これにより、問い合わせ処理での、語を「認識する」処理が行われ、この処理結果は、以下での問い合わせ処理で用いられる。
【０１５０】
語の認識処理の分散構成と高速性能が、それ自身特に有益であり、他の問い合わせ処理を組み込んだり、必要としない他の環境と組み合わせて実施することは、当該技術分野に精通した者にとっては、明白なものである。例えば、いくつかのアプリケーションでは、コンピュータが生成した様式の中のデータ項目を埋めるために、単純に、認識された個々の語を用いることもでき、上述したシステムと処理方法は、これを行うために高速で信頼性の高い機構を提供することができる。
【０１５１】
ユーザの音声が認識されると、ＳＲＥ１８２の処理フローは、ＳＲＥアンイニシャライゼーションルーチン６０４に進み、そこで、図示したように音声エンジンはアンイニシャライゼーションされる。このブロックでは、ルーチン６０４Ａにより、先に初期化ブロックで生成された全てのオブジェクトを削除し、初期化フェーズで初期化ブロックによって割当てられたメモリは、ルーチン６０４Ｂによって削除される。
【０１５２】
また、上述した内容は、本発明のサーバ側の音声認識システムで用いられる特定のルーチンを実装する一実施例を例証したものにすぎない。本発明の開示によれば、本発明の所定の機能性と目的を同様に達成するために、他の変形も可能となることは明白である。
【０１５３】
データベースプロセッサ１８６の動作−ＤＢプロセス
ユーザの問い合わせ処理の一部として用いられるＳＱＬクエリーの構成を、図４Ｂに示す、ここで、ＳＥＬＥＣＴ  ＳＱＬ文は、既知のＣＯＮＴＡＩＮＳ述語を用いて構成されることが好ましい。モジュール９５０は、このＳＥＬＥＣＴ  ＳＱＬ文に基づいて、ＳＱＬクエリーを構成し、このクエリーは、ユーザが発声した問い合わせ（ここでは、質問と言う）に対応し、データベース中に格納された最適な問い合わせ文を検索するために用いられる。次に、ルーチン９５１は、構成されたＳＥＬＥＣＴ文にテーブル名称を付け加える。次に、ルーチン９５２により、ユーザによって発せられた質問の名詞句の語数を計算する。さらに、ルーチン９５３で、ＮＰで与えられた全ての語を収容するために必要なメモリを割当てる。次に、ルーチン９５４により、（ＮＰで与えられた個々の語全てを識別する）語リストを求める。その後、ルーチン９５５で、この個々の語のセットを、ＮＥＡＲ（）キーワードで分離したＳＱＬクエリーに付け加える。次に、ルーチン９５６で、ＳＱＬクエリーの各ＮＰの後ろに、ＡＮＤキーワードを付け加える。最後に、コード９５７で、メモリリソースを解放し、次の繰り返し処理のために、ＮＰから受信された語を格納するメモリを割当てる。以上のように、本処理の結果、ユーザの発声した質問に対応した完全なＳＱＬクエリーが生成される。
【０１５４】
ＳＱＬサーバへの接続―図４Ｃに図示したように、ルーチン７１０でＳＱＬクエリーを構成した後、ルーチン７１１は、問い合わせデータベース７１７への接続を行い、引き続きユーザの問い合わせの処理を進める。この接続手順と、それに伴う検索記録のセットは、以下の手順で実装される。
【０１５５】
１．ルーチン７１１Ａで、サーバとデータベースの名称を、ＤＢプロセスメンバー変数に割当てる。
２．ルーチン７１１Ｂで、接続文字列を生成する。
３．コード７１１Ｃの制御の元で、ＳＱＬサーバデータベースを接続する。
４．ルーチン７１２Ａで、ＳＱＬクエリーを受信する。
５．コード７１２Ｂで、ＳＱＬクエリーを実行する。
６．ルーチン７１３で、クエリーによって検索された記録の全数を取り出す。
７．ルーチン７１３で、組になった質問の全数を格納するためのメモリを割当てる。
８．ルーチン７１３で、組になった質問の全数を、配列の形で格納する。
【０１５６】
図４Ｃのルーチン７１６で、ＮＬＥ１４（図５）から最良の回答ＩＤを受信すると、７１６Ｃに対応したコードがこれを受信し、さらにコード７１６Ｂに送り、そこで記録番号を用いて、回答ファイルへのパスが決定される。次に、７１６Ｃがこのファイルへのパスを用いてこのファイルを開き、回答に対応したファイルの内容を読み取る。さらにこの回答は、７１６Ｄのコードによって圧縮され、通信チャネル１６０Ｂ（図１）を介した伝送のために加工される。
【０１５７】
ＮＬＱＳデータベース１８８−テーブル構成
図７は、典型的なＮＬＱＳデータベース１８８（図１）で用いられるテーブルの論理構造の一実施例を示すものである。ＮＬＱＳデータベース１８８が、遠隔教育／訓練の環境として実装されたＮＬＱＳ問い合わせシステム１００の一部として用いられる場合には、このデータベースは、通常、いくつかのチャプター７０２、７０３、７０４からなるコース７０１を含む、組織化されたマルチレベルの階層構造を含むものとなる。これらのチャプターの各々は、チャプター１として示された、一つあるいはそれ以上の数のセクション７０５、７０６、７０７を有している。チャプター２、チャプター３…チャプターＮについても、同様の構造となっている。各セクションは、以下に詳説するテーブルに格納された、一つあるいはそれ以上の質問／回答の組７０８、７０９、７１０を有している。この構成は、教育／訓練の応用に対して適切で最適なものであるが、他の実装方法も可能であり、電子商取引、電子支援、インターネット閲覧などの他の応用に対してはそれらの全体システムのパラメータに応じてより好適な構成とすることができることは明白である。
【０１５８】
ＮＬＱＳデータベース１８８の構成は、前述した切り換え可能な文法構造に対して、複雑にリンクされている。言い換えると、ユーザが体現している背景（あるいは環境）は、いかなる時でも、そのセクションレベルでなされた選択に基づいて決定され、例えば、限定された質問／回答の組７０８のサブセットだけがセクション７０５で取り扱うのにふさわしいものとされる。すなわち、このような背景にユーザが直面している間、ユーザの問い合わせを扱うために、このような質問／回答の組に対して特定の適切な文法だけを切り換え選択するものとなっている。同様に、インターネットを使った商取引のための電子商取引アプリケーションは、ユーザが選択可能なオプション（製品種類、サービス、問い合わせ先情報など）を特定する第一レベルの「ホーム」ページ７０１を含み、その第二レベルは特定の「製品種類」７０２、７０３、７０４等を含み、その第三レベルは、特定の製品モデル７０５、７０６、７０７等を含むような階層構造から構成され、適当な質問／回答の組７０８、７０９とこのような製品モデルのための問い合わせを扱うためにカスタマイズされた文法から構成されるものであってよい。なお、アプリケーションによって、ビジネスのニーズと要望に応じて特定の実装方法を変えることになり、このような個々のアプリケーションに対しては、処理ルーチンを適切に最適化することが必要となる。
【０１５９】
テーブル構成
本実施例では、各コースに対して、独立したテーブルを用いている。すなわち、各データベースは、以下の３種類のテーブルを含んでいる。図７Ａに示されるマスターテーブル、図７Ｂに示されるような少なくとも一つのチャプターテーブル、および図７Ｃに示されるような少なくとも一つのセクションテーブルである。
【０１６０】
図７Ａに示すように、マスターテーブルの一実施例は、６つの列を有している。すなわち、フィールド名７０１Ａ、データ型７０２Ａ、サイズ７０３Ａ、Ｎｕｌｌ７０４Ａ、基本キー７０５Ａ、およびインデックス７０６Ａである。これらのパラメータは、データベース設計および構成の分野では、既知のものである。マスターテーブルは、２つのフィールド、チャプター名７０７Ａおよびセクション名７０８Ａのみを有している。チャプター名およびセクション名は、通常、インデックス化されている。
【０１６１】
チャプターテーブルの一実施例を、図７Ｂに示す。マスターテーブルと同様に、チャプターテーブルも６つの列を有している。すなわち、フィールド名７２０、データ型７２１、サイズ７２２、Ｎｕｌｌ７２３、基本キー７２４、およびインデックス７２５である。しかし、データには９つの行を含んでいる。すなわち、この場合は、チャプターＩＤ７２６、回答ＩＤ７２７、セクション名７２８、回答タイトル７２９、組になっている質問７３０、回答へのパス７３１、クリエータ７３２、データ生成日時７３３およびデータ修正日時７３４である。
【０１６２】
チャプターテーブルのフィールドの説明を、図７Ｃに示す。８つのフィールド７３０の各々は、記述欄７３１を有し、以下に対応したデータを格納している。
【０１６３】
回答ＩＤ７３２−ユーザの都合に合わせて、各回答ごとに自動的に更新される整数。
セクション名７３３−特定の記録が所属するセクションの名称。本フィールドと回答ＩＤとを合わせて、基本キーとして用いられる。
【０１６４】
回答タイトル７３４−ユーザの問い合わせへの回答のタイトルの簡単な説明。
組になっている質問７３５−次の列、回答へのパスに格納されたパスをもつ回答に対応した、一つあるいはそれ以上の数の質問の組。
【０１６５】
回答へのパス７３６−直前の列に格納された関連した質問に対する回答を含むファイルへのパスを含むもの。単純な質問／回答アプリケーションの場合には、このファイルはテキストファイルであるが、上述したようにデータリンク１６０を介して何がしかの転写が可能なマルチメディアファイルであることも可能である。
【０１６６】
クリエータ７３７−データの中身を生成したクリエータの名称。
データ生成日時７３８−データの中身が生成された日時。
データ修正日時７３９−データの中身が変更、修正された日時。
【０１６７】
セクションテーブルの一実施例を、図７Ｄに示す。セクションテーブルは、６つの列を有している。すなわち、フィールド名７４０、データ型７４１、サイズ７４２、Ｎｕｌｌ７４３、基本キー７４４およびインデックス７４５である。データには７つの行、すなわち、回答ＩＤ７４６、回答タイトル７４７、組になっている質問７４８、回答へのパス７４９、クリエータ７５０、データ生成日時７５１およびデータ修正日時７５２を有している。これらの名称は、上述したマスターテーブルおよびチャプターテーブルと同様のフィールドおよび行に対応している。
【０１６８】
なお、本例は、以上で説明した教育／訓練アプリケーションの特定のものに対する実施の形態である。本発明が利用できる可能性のあるアプリケーションは多岐にわたっており、各アプリケーションに応じてカスタマイズが可能となっているため、（他の教育／訓練アプリケーションを含む）他のアプリケーションでは、他のテーブル、行およびフィールドの構成と階層構造が必要となったり、それらによってより良い実装形態となる場合もありうる。
【０１６９】
サーチサービス及びサーチエンジン―クエリーテキストサーチサービスは、図１０に示すＳＱＬサーチシステム１０００により実行される。このシステムはクエリーをサポートし、全文検索の処理を行う。此処に全文インデックスが存する。
【０１７０】
通常、ＳＱＬサーチシステムは、明瞭なユーザ発言に対応して構成された特定のテキストクエリーによって指定される選択基準に、データベースインデックスのいずれのエントリが一致するかを決定する。インデックスエンジン１０１１Ｂは、記憶された質問及び対応する回答に対してテキストのインデックス可能な単位に対応するインデックスを、全文インデックステーブルに集めるものである。これは文字列を走査し、ワードの境界を決定し、全てのノイズワードを取り除き、そして残った語を全文インデックスに集める。選択基準に一致する全文データベースへのエントリを容易とするために、独自のキー欄の値とランキング値が同様に返される。カタログセット１０１３はファイル―システムディレクトリであり、管理者及びサーチサービス１０１０によってのみアクセス可能である。全文インデックス１０１４は全文カタログへと組織され、これらは取り扱い容易な名称によって参照される。一般的には、全データベースの全文インデックスデータは単一の全文カタログへと配置される。
【０１７１】
前述（図７、７Ａ、７Ｂ、７Ｃ、７Ｄ）の全文データベースの図式は図１０に示すテーブル１００６に記憶されている。これらのテーブルは例えば、特定のコースに必要な記憶された質問／回答の対の構造を記述する必要がある。各テーブル―コーステーブル、チャプタテーブル、及びセクションテーブルに対してフィールド―欄情報があり、これがテーブルの論理構造を作り上げる各パラメータを規定する。この情報はユーザ及びシステムテーブル１００６に記憶される。これらのテーブルに対応するキー値は全文カタログ１０１３として記憶される。したがって、全文検索を処理すると、サーチエンジンはサーチ基準に一致する行のキー値をＳＱＬサーバに返す。リレーショナルエンジンがその後、この情報を用いて質問へと応答する。
【０１７２】
図１０に示すように、全文クエリー処理は以下のように実施される。
１．ＤＢ処理装置１８６によって形成されるＳＱＬ全文構造を用いたクエリー１００１をＳＱＬリレーショナルエンジン１００２へと提出する。
２．ＣＯＮＴＡＩＮＳ述部又はＦＲＥＥＴＥＸＴ述部を含むクエリーがルーチン１００３によって書き換えられ、後に全文プロバイダ１００７から戻される応答性の高いローセットが、述部が作用するテーブルへと自動的に結合される。この書き換えは、これらの述部が従来のＳＱＬサーバへのシームレスな拡張であることを確保するために用いられるメカニズムである。
３．この後、全文プロバイダ１００７が呼び出され、クエリーに対して以下の情報を送る。
ａ．前方検索条件パラメータ（これは全文検索条件を示す論理フラグである）
ｂ．テーブルの全文インデックスが存する全文カタログの名称
ｃ．言語（例えば、単語分け）に対して用いられるローカルＩＤ
ｄ．このクエリーに用いられるデータベース、テーブル、及び欄のアイデンティティ
ｅ．もしクエリーが２つ以上の全文構造からなるなら；この場合、全文プロバイダ１００７が各構造に対して個別に呼び出される。
４．ＳＱＬリレーショナルエンジン１００２は前方検索条件の内容を検査しない。代わりに、この情報は全文プロバイダ１００７へと渡され、これがクエリーの妥当性を確認し、その後全文検索条件の適当な内部表現を構成する。
５．次にクエリー要求／コマンドがクエリーサポート１０１１へと渡される。
６．クエリーサポート１０１２が、全文検索基準に一致するすべての行に対して独自のキー欄値を含む全文カタログ１０１３からローセット１００９を戻す。ランク値もまた各行に対して戻される。
７．キー欄値のローセット１００９がＳＱＬリレーショナルエンジン１００２へと渡される。クエリーの処理がＣＯＮＴＡＩＮＳＴＡＢＬＥ（）関数或いはＦＲＥＥＴＥＸＴＴＡＢＬＥ（）関数と関係するなら、ランク値が戻され、それ以外の場合はランク値をフィルタにかけることで除外する。
８．ローセット値１００９はリレーショナルデータベース１００６から得られた値と共に最初のクエリーへと加えられ、そして結果セット１０１５が更なる処理のために戻されてユーザへの応答を生じる。
【０１７３】
クエリー認識処理のこの段階において、ユーザによる発言は既に注意深く作られたテキストクエリーへと迅速に変換されており、そしてこのテキストクエリーは、好適に一致する質問／回答対の最終決定のために結果の初期一致群がさらに評定可能なように、最初に処理されている。これを可能とする根本原理は、全文検索のために登録された各テーブルにおける全文ユニークキー欄の存在である。このように、全文検索を処理すると、ＳＱＬサーチサービス１０１０がデータベースと一致する行のキー値をＳＱＬサーバ１００２へと戻す。これら全文データベース１０１３及び全文インデックス１０１４の維持において、本発明は、全文登録欄がアップデートされて直ぐには全文インデックス１０１４がアップデートされないという他に類を見ない特徴を有する。再度に亘り識別待ち時間を短くし反応速度を高めるなどの為に、この操作は排除される。このように、さもなくばかなりの時間を要するであろう全文インデックステーブルのこのアップデートは、他のデータベースアーキテクチャと較べ、代わりに、より好適な時に同期的に実施される。
【０１７４】
ＮＬＥ１９０とＤＢ処理装置１８８とのインターフェース
ユーザクエリー発言へと対応する質問候補の結果セット１０１５は、図４Ｄに示す更なる処理のためにＮＬＥ１９０へと送り出され、「最良」一致の質問／解答対を決定する。ＮＬＥ／ＤＢ処理装置インターフェースモジュールは、ユーザクエリーの取り扱い、ユーザクエリーに基づくＳＱＬクエリーからの検索質問の組のうちの名詞句（ＮＰｓ）の解析、検索質問のＮＰｓとユーザクエリーのＮＰとの比較などを、ＮＬＥ１９０とＤＢ処理装置１８８との間で調整する。したがって、サーバ側コードのこの部分には関数が含まれ、これがＮＬＥブロック１９０とＤＢ処理装置ブロック１８８の双方に常駐する処理の仲立ちをする。この関数は図４Ｄに示され；ここでわかるように、コードルーチン８００はユーザの質問から名詞句（ＮＰ）リストを抽出する機能を果たす。コードのこの部分はＮＬＥ１９０と影響し合い、ユーザによって明瞭に発音された文の名詞句のリストを得る。同様に、ルーチン８１３は、対応する候補／対の質問１０１５のリストからＮＰリストを検索し、これらの質問を（ＮＰ値によってランク付けされる）列へと記憶する。このように、この時点でＮＰデータが、質問候補１０１５のためと同様に、ユーザクエリーのために生成されている。「如何なる問題が大統領にアメリカ企業に対する外国貿易政策の影響を考慮せしめたのか？（What issues have guided the President in considering the impact of foreign trade policy on American businesses?）」のような一文の名詞句断定の一例としては、ＮＬＥ１９０は以下のものを名詞句として返すであろう：大統領（President）、問題（issues）、貿易政策の影響（impact of foreign trade policy）、アメリカ企業（American businesses）、影響（impact）、外国貿易の影響（impact of foreign trade）、外国貿易（foreign trade）、外国貿易政策（foreign trade policy）、貿易（trade）、貿易政策（trade policy）、政策（policy）、企業（businesses）。ＮＬＥ１９０によって用いられる方法論はしたがって、例示のクエリーに対応して生成されたこの名詞句の組及び名詞準句（noun sub-phrases）から当業者には明らかである。
【０１７５】
次に、最良回答獲得（Get Best Answer）ＩＤ８１５として識別される関数が実施される。コードのこの部分はユーザクエリーに対応する最良の回答ＩＤを獲得する。これを為すために、ルーチン８１３Ａ及び８１３Ｂはまず、ユーザクエリーでの名詞句と一致する検索群１０１５における各エントリに対して、名詞句の数を見出す。その後、ルーチン８１５Ａが、最大数の一致名詞句を含む検索候補群１０１５から最終的な結果レコードを選択する。
【０１７６】
従来、名詞とは一般に「命名」語、具体的には「人、場所、又は物」の名称と考えられている。ジョン（John）、ロンドン（London）、及びコンピュータ（computer）などの名詞は確かにこの説明に合致するが、本発明によって名詞として分類される語のタイプはこれよりもずっと広い。名詞はまた、誕生（birth）、幸福（happiness）、進化（evolution）、科学技術（technology）、経営（management）、想像（imagination）、報復（revenge）、政治（politics）、希望（hope）、料理法（cookery）、スポーツ（sport）、識字能力（literacy）、などの抽象的及び無形の概念をも示すことができる。会話の他の箇所に比べ名詞は非常な多様性を有するが故に、言語基準のキーとして名詞句を考慮することが遥かに適切であることを出願人は見出した。そして、本発明により名詞と分類される非常に多くの項目は、当該分野において知られる先行技術と比べより簡単且つ迅速に個々の発言を選別し識別することに役立つ。
【０１７７】
これと同じ考えに従い、本発明はまた別の言語要素―語句（word phrase）を採用・遂行し、音声クエリー認識を容易となす。名詞句、動詞句、或いは形容詞句であろうと、語句の基本構造は３つの部分―「主要語前の文字列（pre-Head string）」、「主要語（Head）」、及び「主要語後の文字列（post-Head string）」からなる。例えば、最小限の名詞句「その子供たち（the children）」においては、「子供たち（children）」が名詞句の主要語として分類される。要約すれば、名詞句の多様性及び頻度故に、それにより記憶回答が言語学的に選ばれる基準として名詞句を採用することは、他の自然語同様、英語の自然語への本技術の適用において確固たる根拠を有する。そしてつまり、総合された発言中の全名詞句は音声クエリーフィンガープリントの独自のタイプとして極めて好適に作動する。
【０１７８】
次に、選ばれた最終結果のレコード質問に対する最良回答に対応するＩＤがルーチン８１５によって生成され、次にこれを図４Ｃに示すＤＢ処理へと返す。ここでわかるように、最良回答ＩＤはルーチン７１６Ａによって受け取られ、ルーチン７１６Ｂによって用いられ回答ファイルパスを検索する。次にルーチン７１６Ｃが回答ファイルを開いて読み取り、ルーチン７１６Ｄへと同一の内容を伝える。後者は次に回答ファイルデータを圧縮し、前述の処理のために（すなわち、可聴フィードバック、可視テキスト／画像などへの変換のために）データリンク１６０を介してそれをクライアント側システム１５０へと送る。繰り返せば、学習／教育用途に関しては回答ファイルは単一のテキスト句からなるものでよいが、他の用途においては内容及びフォーマットは好適な形式の特定な質問へと体裁を整えられることとなる。例えば、「回答」は応答するカテゴリ要素のリスト（すなわち、特定の著者の本のリスト）などへと対応する複数のエントリのリストからなるものとできる。その他の変更例は独自の状況に応じて明らかである。
【０１７９】
自然語エンジン１９０
再度図４Ｄを参照し、ＮＬエンジン１９０の概略構造を述べる。このエンジンは、クエリーから抽出された句の句解析と並んでワード解析、すなわちユーザクエリーを作り上げるワードの形態素解析を行う。
【０１８０】
図８Ａに示すように、形態素解析に用いられる関数は、トークナイザー（tokenizers）８０２Ａ、ステマー（stemmers）８０４Ａ、形態素アナライザー（morphological analyzers）８０６Ａを含む。句解析を構成する関数は、トークナイザー、タガー（taggers）、及びグルーパー（groupers）を含み、その関係は図８に示される。
【０１８１】
トークナイザー８０２Ａはソフトウエアモジュールであり、入力文８０１Ａのテキストを分解し、トークン８０３Ａのリストとするように機能する。この機能の実行において、トークナイザー８０２Ａは入力テキスト８０１Ａを走査し、トークン、すなわち、概して個々の文字よりは大きいが句及び文よりは小さい有用な有意味単位、の一群としてこれを扱う。これらのトークン８０３Ａはワード、ワードの分離可能部分、及び句読点を含む。各トークン８０３Ａにはオフセットと長さが与えられる。トークン化の第一段階は、入力テキストから個別のトークンを抽出し、入力テキスト内に由来する各トークンのオフセットのトラックを維持するセグメント化である。次に、その形状に基づいてカテゴリを各トークンと関連させる。トークン化処理は技術的に公知であり、よって本発明に好適な如何なる従来の出願によっても実施可能である。
【０１８２】
トークン化に続きステマー処理８０４Ａが実行されるが、これはトークンを解析しそれぞれの基語（stems）８０５Ａを決定するための２つの別個の形態―屈折形及び派生形、を含む。屈折ステマーは接辞を認識し、基語であるワードを返す。一方派生ステマーは派生接辞を認識し、一つまたは複数の基語を返す。ステマー８０４Ａは入力ワードをその基語と関連付けるが、音声情報の部分は有しない。アナライザー８０６Ｂは文脈とは無関係にワードを取り上げ、発言８０６Ａのうちの可能性のある部分の群を返す。
【０１８３】
図８に示すように、句解析８００は次のステップであり、トークン化の後に行われる。トークン８０３はタガールーチン８０４によって音声タグの部分へと割り当てられ、そしてグルーパールーチン８０６が、ある種の統語的タイプの句としてワードのグループを認識する。これらの統語的タイプは、例えば前述の名詞句を含むが、必要に応じて動詞句、形容詞句などの他のタイプも含むことが可能である。具体的には、タガー８０４は会話の一部から曖昧さを除去するもの（parts-of-speech disambiguator）であり、文脈においてワードを解析する。これは固有の形態素アナライザー（図示せず）を有し、各トークンにおいて会話のうちの可能性のある全ての部分を識別可能せしめる。タガー８０４の出力は文字列であり、各トークンは会話部分（parts-of-speech）ラベル８０５でタグ付けされている。言語処理８００における最後のステップはワードのグループ化であり、句８０７を形成する。この機能はグルーパー８０６によって実行され、そしてもちろん、タガー構成要素８０４の性能及び出力に大きく依存する。
【０１８４】
したがって、言語処理８００の最後では、名詞句（ＮＰ）８０７のリストがユーザのクエリー発言に応じて生成される。ＮＬＥ１９０によって生成されたこのＮＰｓの群は、最良の回答を得るための検索を精緻化するのに著しく役立ち、よって後にユーザの質問に対して単一の最良な回答がもたらされることが可能となる。
【０１８５】
ＮＬＥ１９０の特有な構成要素が図４Ｄに示され、そして幾つかの構成要素を含む。これらの構成要素のそれぞれが今説明したようなＮＬＥ１９０に要求される幾つかの異なった機能を果たす。
【０１８６】
グルーパーリソースオブジェクト及びライブラリの初期化９００―このルーチンは、グルーパーリソースオブジェクト及びライブラリの創出に必要な構造体変数を初期化する。具体的には、これはＮＬＥ１９０によって用いられる特定の自然語を初期化し名詞句を作り出すもので、例えば、英語市場に供されるシステムでは英語の自然語が初期化される。次にそれはまた、それぞれルーチン９００Ａ、９００Ｂ、９００Ｃ及び９００Ｄを用いて（前述の）トークナイザー、タガーそしてグルーパーに必要とされるオブジェクト（ルーチン）を創出し、これらのオブジェクトを好適な値で初期化する。これはまたメモリを割り当て、検索された質問対についての認識された全ての名詞句を記憶する。
【０１８７】
与えられたテキストからの（クエリーすなわち対の質問からの）ワードのトークン化は、ルーチン９０９Ｂを用いて実行される―ここで全てのワードはＮＬＥ１９０リソースによって使用されるローカル辞書の助けによってトークン化される。結果トークン化されたワードはタガールーチン９０９Ｃに渡される。ルーチン９０９Ｃでは、全てのトークンのタグ付けが行われ、出力がグルーパールーチン９０９Ｄへと渡される。
【０１８８】
ＮＰリストを形成するためのタグ付けされた全てのトークンのグループ化は、グルーパーがタグ付けされた全てのトークンワードをグループ化して名詞句を出力するようにルーチン９０９Ｄによって実行される。
【０１８９】
グルーパーリソースオブジェクトの非初期化及びリソースの解放は、ルーチン９０９ＥＡ、９０９ＥＢ、及び９０９ＥＣによって実行される。これらはトークンリソース、タガーリソース、グルーパーリソースをそれぞれ含む。初期化後、リソースは解放される。全ての名詞句を記憶するのに用いられたメモリもまた割り当てを取り消される。
【０１９０】
更なる実施例
図１３に示される本発明の電子商取引実施例では、ウエブページ１３０が書籍１３１、音楽１３２などの標準的な可視リンクを有し、適当なリンクをクリックすることで顧客はそれらのページへと案内される。ウエブページは、ＨＴＭＬ、ｊａｖａアプレット、或いはユーザのブラウザと相互作用する同様のコード付け技法を用いて実行することができる。例えば、仮に顧客がアルバートというアーティストによるアルバムＣを購入したいと欲するなら、彼は幾つかのウエブページを以下のようにして詳しく検討することができる：彼はまず音楽（図１３、１３６）をクリックし、それからレコード（図１４、１４５）をクリックする。図１５に示すように、これはレコード１５５のためのリンクを有する別のウエブページ１５０を立ち上げ、下位カテゴリ―アーティスト１５６、歌１５７、曲名１５８、ジャンル１５９を有する。顧客は次に選択範囲のうちからアーティストを選ぶためにアーティスト１５６をクリックしなくてはならない。これは図１６に示すように別のウエブページ１６０を表示する。このページには図示のように様々なアーティスト１６５がリストされ―カテゴリ  アーティスト１６５の元にアルバート１６５、ブルックス１６６、チャーリー１６７、ホワイト１６９がリストされている。顧客はここで、アルバートで入手可能なアルバムを閲覧するためにアルバート１６６をクリックしなくてはならない。これが為されると、別のウエブページが図１７に示すように表示される。このウエブページ１７０は再び、同様な外観及び雰囲気を表すが、見出しタイトル１７５の元には入手可能なアルバム１７６、１７７、１７８がリストされている。顧客はまた、各アルバムについて追加情報１７９を読むことができる。このアルバム情報は小売店で購入される収縮包装されたアルバムの解説書きに類似したものである。一つのアルバムＡが特定されると、顧客はアルバムＡ１７６をクリックしなくてはならない。これにより通常は、その入手可能性、価格、送料及び手数料などについての情報を有する別のテキストボックスが立ち上がる。
【０１９１】
ウエブページ１３０が上述したタイプのＮＬＱＳの機能を備えると、ウエブページは上述したクライアント側及びサーバ側音声認識モジュールと相互作用する。この場合、ユーザはコンタクト・ミー・フォー・ヘルプ（Contact Me for Help）１４８と称されるボタン（例えば、これはスクリーン上のリンクボタンであってもよいし、キーボード上のキーであってもよい）を単にクリックすることで問い合わせを開始することができ、そして必要とする情報を如何に引き出すかをキャラクタ１４４に教わる。もしユーザがアルバートというアーティストのアルバムＡを欲するなら、ユーザは煉瓦やモルタルの施設で人間の店員に質問をするときと大体同じように「ブルックスのアルバムＡはありますか？」と明瞭に発音する。本発明の迅速な認識性能により、ユーザの質問には、ユーザの自国語で回答を喋りたてるキャラクタ１４４からリアルタイムで回答がある。必要であれば、キャラクタの回答が見え、そしてセーブ／プリントオプションも実行可能なように、読みやすいワード吹き出し１４９も表示してよい。ウエブサイトの各ページについて、同様に適当な質問／回答の対を本教示に基づいて構成することができ、よって顧客は、ウエブサイトの全ての局面において通常会話的、人間的な質疑応答の対話をエミュレートする環境を供与される。キャラクタ１４４は、特定の商業用途に応じて、或いは顧客の体験をより良いものとするために特定の音声スタイル（男性、女性、若者、年配者、など）を取るようユーザ自身の好みなどによって変更・調整可能である。
【０１９２】
同様なやり方で、明瞭に発音されたユーザクエリーが従来のサーチエンジンクエリーの一部として受け取られ、従来のテキストクエリーを用いて為すのと同様なやり方でインターネット上の興味ある情報を探し出す。仮に適度に近接した質問／回答の対がサーバ側で得られないなら（例えば仮に、ユーザの質問への適当な対の一方としてある程度の信頼水準に達しなければ）、ユーザは範囲拡大のオプションをあてがわれ、そしてクエリーは同時に多数のサーバに亘る一つ以上の異なるＮＬＥｓへと供与され、好適に合致する質問／回答の対を見出す尤度を向上させる。さらに、必要であれば、従来のサーチエンジンがユーザの質問へと対応する多数の潜在的「ヒット」を返すのと同じやり方で、一つ以上の「適合」を見出すことも可能である。このような質問には、もちろん、リアルタイム動作は可能とは思われないが（散在的且つ分散的処理が故に）、広範囲な補助的質問／回答データベースシステムによってもたらされる利点はいくらかのユーザにとっては望ましいであろう。
【０１９３】
同様に明らかなことには、本発明のＮＬＱＳは非常に自然であり、且つユーザに、そして電子商取引オペレータにも同様に多くの時間を節約する。電子サポート実施例においては、顧客は、生身の顧客エージェントを必要とせずに、迅速且つ効率的に情報検索できる。例えば、消費者コンピュータシステムベンダ関連サポートサイトでは、単純な診断用ページが彼／彼女をアシストするための可視サポートキャラクタと共にユーザへと提供される。そしてユーザは「症状」ページからアイテム（すなわち、「モニタ」問題、「キーボード」問題、「プリンタ」問題など）を、サポートキャラクタからの勧めに応じてそのような症状を明瞭に発音することだけで選択できる。その後システムは、認識された特定の病症に対して、リアルタイムでユーザをより詳細な下位メニュー、可能性のある解決法などへと導く。プログラム可能なキャラクタの使用はこのようにウエブサイトを、膨大な数のヒット、すなわち顧客を受け入れ可能な規模とすることができ、これには対応して人的資源の数を増やす必要及びそれに付随する研修の問題が存在しない。
【０１９４】
更なる実施例として、特定のウエブサイト上での情報検索を本発明のＮＬＱＳを使用して速めることができる。さらに非常に役立つことには、情報は会話という自然なインターフェースを介してユーザフレンドリーな様式で提供される。ウエブサイトの大多数は現在、質問または問題に対する回答を得るために通常ユーザが一つ一つ取り組む照会頻度の高い質問のリストを採用している。例えば、図１３に示すように、顧客はヘルプ１３３をクリックしてリスト群とのインターフェースを開始する。図１８に示すように、一般的なウエブページ用のウエブサイトプランが表示される。これは、照会頻度の高い質問のリストにたどり着くために通り過ぎなくてはならないページの数を示している。このページで一度、ユーザはスクロールし、彼／彼女の問い合わせと一致する質問を手動で特定しなくてはならない。この処理は大概骨の折れる仕事でありユーザの問い合わせに答える情報を出すとも出さないとも限らない。この情報を表示するための現在の技術が図１８に示されている。この図は、一般的なウエブサイトで情報が如何に組織化されているかを特定しており：ウエブページのホームページ上に通常示されるヘルプリンク（図１３、１３３）は、１８０として図１８に図示されている。再度図１８を参照すると、情報の各下位カテゴリは別のページにリストされている。例えば、１８１は、「初めての方に」、「検索情報」、「注文」、「発送」、「あなたの口座」などの下位トピックスをリストする。他のページは「口座情報」１８６、「レートとポリシー」１８５などを取り扱う別のレベルでは、「初めての方に」１９６、「照会頻度の高い質問」１９５、「安全購入の保障」１９４などの特定のページ上で下位―下位トピックスのみを取り扱うページがある。よって、もし顧客が照会頻度の高い質問リンクへと行くことで最良の答えを得られる問い合わせを抱えているなら、彼又は彼女は照会頻度の高い質問ページ１９５へとたどり着くために、３つのレベルの混雑し取り散らかったスクリーンページを通り過ぎなくてはならない。通常、手動でスクロールし通過しなくてはならない質問１９８のリストは多い。視覚的スクロールの間に、顧客は、彼又は彼女の質問をリストされた各質問と視覚的及び知的に一致させなくてはならない。可能性のある一致が見出されると、質問はクリックされ、そしてテキスト形式で回答が現れ、そして読み取られる。
【０１９５】
これとは対照的に、本ＮＬＱＳが使用可能なウエブページを用いて質問に対して回答を得る処理は、ずっと少ない労力で、効率的に実行可能である。ユーザは「ヘルプ」（図１３、１３３）とのワードを明瞭に発音する。これは即座にキャラクタ（図１３、１３４）を出現せしめ、「お手伝いしましょうか。あなたの質問を言ってください？」との友好的な対応をとらせる。顧客が質問を述べると、キャラクタは活発に振る舞い、或いは「ありがとうございます、答えを持ってすぐに戻ってきます。」と返す。短時間（好ましくは、５〜７秒を超えない）が経過後、キャラクタはユーザの質問に対する回答を喋る。図１８に示すように、回答は会話の形式でユーザへと戻される回答１９９であり、これは質問１９５と対になった回答である。例えば、回答１９９：「Ｖｉｓａ、ＭａｓｔｅｒＣａｒｄ、Ｄｉｓｃｏｖｅｒのクレジットカードなら受け取れます。」は問い合わせ２００「どのような形態の支払いを受け入れるか？」に対する反応である。
【０１９６】
本発明の別の実施例が図１２に示される。このウエブページは、ウエブ基盤の学習環境においてＮＬＱＳを採用した典型的なウエブサイトを示すものである。図１２に示すように、ブラウザ１２０におけるウエブページは２つ以上のフレームへと分割されている。インストラクタを装うキャラクタ１２１は画面上で利用可能であり、マイクロフォンへと「ヘルプ」というワードを喋ること（図１３、１３４）、又は「会話するにはここをクリックしてください（Click to Speak）」リンクをクリックすること（図１２、１２８）のいずれかによって学生がクエリーモードを開始したときに現れる。するとキャラクタ１２１は学生を促してドロップダウンリスト１２３からコース１２２を選択させる。もしユーザがコース「Ｃプラスプラス」を選ぶと、キャラクタは口頭で、コース「Ｃプラスプラス」が選択されたことを確認する。キャラクタは続いて学生に、そこから質問が利用可能なチャプタ１２４のための選択肢を含むドロップダウンリスト１２５から次の選択をするように仕向ける。学生が選択後再び、キャラクタ１２１は会話で選択を確認する。次に、キャラクタ１２１は学生を促し、そこから質問が利用可能なチャプタの「セクション」１２６をドロップダウンリスト１２７から選ばせる。学生が選択後再び、キャラクタ１２１は選ばれた「セクション」１２６を明瞭に発音することで選択を確認する。学生に注意を促すものとして、可能性のある質問のリストがリストボックス１３０に現れる。さらに、システムを利用するための情報１２９が表示される。選択がすべて終わると、学生はキャラクタから以下のように質問を行うよう促される：「ここであなたの質問をしてください」。そして学生は彼の質問を喋り、短時間経過後、キャラクタは以下のように質問を前置した回答で応じる：「あなたの質問・・・・・に対する答えは以下のものです：・・・・・・・・」。このやり方は、コースのどの箇所についても質問に対する解答を学生が迅速に検索できるものとし、指導書の退屈さや引用あるいはインデックスに取って代わる。すなわちこれは、進行中の質問に答える仮想教師、すなわちフラッシュカード代替物であることから、多くの用途に役立つ。
【０１９７】
発明者に入手可能な暫定データから見積もると、システムは１００〜２５０の質問／回答の対を容易に収容でき、それと同時に上述の構造及び方法を用いてユーザにリアルタイム感覚及び外観（すなわち、待ち時間１０秒未満、送信はカウントせず）を提供できる。当然ながら、さらなる処理速度が利用可能となり、また各特定環境に対して言及された様々な構成要素へとルーチン最適化が行われれば、これらの数値が良くなることが期待される。
【０１９８】
繰り返すが、上記のものは、本発明の数多い可能性ある用途を単に例示したにすぎず、他の民生用途（知的な双方向おもちゃなど）と同様、より多くのウエブ基盤企業が本教示を利用することが期待される。ここまで本発明を好ましい実施の形態に基づいて記述したが、本発明の教示から離れることなく前記実施例に対して多くの変更・修正を行い得ることは当業者にとって明らかであろう。また、本発明のより適切な局面を適度に重要視し焦点をあわせるために、本開示の多くの局面が簡略化されていることも当業者にとって明らかであろう。本発明の方法を達成するために実行されるマイクロコード及びソフトウエアルーチンは、永久磁気媒体、非揮発性ＲＯＭ、ＣＤ−ＲＯＭ、或いは他の好適な機械可読フォーマットにおいて様々な形態で実施可能である。したがって、付随のクレームによって規定されるように、そのような変更・修正のすべてが本発明の範囲及び精神内に含まれるものとする。
【図面の簡単な説明】
【０１９９】
【図１】  図１は本発明の自然語クエリーシステム（ＮＬＱＳ）の好ましい実施の形態のブロック図であり、これはクライアント／サーバのコンピュータアーキテクチャにわたり分散されており、対話学習システム、電子商取引システム、電子サポートシステムなどとして使用可能である。
【図２】  図２はクライアント側システムの好ましい実施の形態のブロック図であり、音声獲得モジュール、部分的音声処理モジュール、コード化モジュール、伝達モジュール、エージェント制御モジュール、及び回答／音声フィードバックモジュールを含み、これは上記ＮＬＱＳに使用可能である。
図２−２は図２のクライアント側システムに用いられる初期化ルーチン及び手続きの組の好ましい実施の形態のブロック図である。
【図３】  図３は図２のクライアント側システムでの発言の繰り返しの組の取り扱いに用いられるルーチン及び手続きの組の好ましい実施の形態のブロック図であり、遠く離れたサーバへとそのような発言の音声データを送信し、そのようなサーバから好適な反応を受け取る。
【図４】  図４は図２のクライアント側システムの非初期化に用いられる初期化ルーチン及び手続きの組の好ましい実施の形態のブロック図である。
図４Ａは図５のサーバ側システム用の音声認識モジュールの分散構成要素を実行するために用いられるルーチン及び手続きの組の好ましい実施の形態のブロック図である。
図４Ｂは図５のサーバ側システム用のＳＱＬクエリービルダを実行するために用いられるルーチン及び手続きの好ましい組のブロック図である。
図４Ｃは図５のサーバ側システム用のデータベース制御処理モジュールを実行するために用いられるルーチン及び手続きの組の好ましい実施の形態のブロック図である。
図４Ｄは図５のサーバ側システム用に、クエリー構築サポート、クエリー応答モジュール、及びデータベース制御処理モジュールへとインタフェースを提供する自然語エンジンを実行するために用いられるルーチン及び手続きの組の好ましい実施の形態のブロック図である。
【図５】  図５はサーバ側システムの好ましい実施の形態のブロック図であり、発言の処理を完了するための音声認識モジュール、環境及び文法制御モジュール、クエリー構築モジュール、自然語エンジン、データベース制御モジュール、及び上記ＮＬＱＳで使用可能なクエリー応答モジュールを含む。
【図７】  図７は図５に示すサーバ側システムの一部として用いられる全文データベースの構成を示す。
図７Ａは本発明の対話学習実施例用に、図５に示すサーバ側システムの一部として用いられる全文データベースコーステーブルの構成を示す。
図７Ｂは本発明の対話学習実施例用に、図５に示すサーバ側システムの一部として用いられる全文データベースチャプタテーブルの構成を示す。
図７Ｃは本発明の対話学習実施例用に、図５に示すサーバ側システムの一部として用いられるチャプタテーブルで用いられるフィールドを記述する。
図７Ｄは本発明の対話学習実施例用に、図５に示すサーバ側システムの一部として用いられるセクションテーブルで用いられるフィールドを記述する。
【図８】  図８は自然語エンジンの好ましい実施の形態により発言に対してなされる第一段階の操作のフローダイアグラムであり、トークン化、タグ付け、グループ化を含む。
図８Ａは自然語エンジンの好ましい実施の形態により発言に対してなされる操作のフローダイアグラムであり、ステム化、字句解析を含む。
【図１０】  図１０は本発明のＳＱＬデータベースサーチ及びサポートシステムの好ましい実施の形態のブロック図である。
【図１１】  図１１Ａ〜Ｃは図２のＮＬＱＳによる質問認識のために実行される好ましい二段階処理で行われるステップを示すフローダイアグラムである。
【図１２】  図１２はウエブ基盤の会話基盤学習／訓練システムの一部として実施される本発明の更なる実施例の説明図である。
【図１３】  ウエブ基盤の電子商取引システムの一部として実施される本発明の更なる実施例の説明図である。
【図１４】  ウエブ基盤の電子商取引システムの一部として実施される本発明の更なる実施例の説明図である。
【図１５】  ウエブ基盤の電子商取引システムの一部として実施される本発明の更なる実施例の説明図である。
【図１６】  ウエブ基盤の電子商取引システムの一部として実施される本発明の更なる実施例の説明図である。
【図１７】  ウエブ基盤の電子商取引システムの一部として実施される本発明の更なる実施例の説明図である。
【図１８】  図１８は電子商取引ウエブサイト用の音声基盤のヘルプページの一部として実施される本発明の更なる実施例の説明図である。
【図１】
0004987203.tif 000003
【図２】
0004987203.tif 000004
0004987203.tif 000005
0004987203.tif 000006
0004987203.tif 000007
【図３】
0004987203.tif 000008
【図４】
0004987203.tif 000009
0004987203.tif 000010
0004987203.tif 000011
0004987203.tif 000012
0004987203.tif 000013
【図５】
0004987203.tif 000014
【図７】
0004987203.tif 000015
0004987203.tif 000016
0004987203.tif 000017
0004987203.tif 000018
0004987203.tif 000019
【図８】
0004987203.tif 000020
0004987203.tif 000021
【図１０】
0004987203.tif 000022
【図１１】
0004987203.tif 000023
0004987203.tif 000024
0004987203.tif 000025
【図１２】
0004987203.tif 000026
【図１３】
0004987203.tif 000027
【図１４】
0004987203.tif 000028
【図１５】
0004987203.tif 000029
【図１６】
0004987203.tif 000030
【図１７】
0004987203.tif 000031
【図１８】
0004987203.tif 000032
0004987203.tif 000033