(57)【特許請求の範囲】
【請求項１】
分散音声認識プロセスにおいて受信データを処理する方法であって、前記分散音声認識プロセスでは、複数のデータ・フレームからなるフレーム構造でデータが配列され、前記複数のデータ・フレームのそれぞれの前には、共通ヘッダ情報を含むヘッダ情報からなる各ヘッダ・フレームが配置され、第１位置から送信された前記データは第２位置にて受信され、前記データは各ヘッダ・フレーム情報を利用して処理され、当該方法は：
複数のヘッダ・フレームのそれぞれからの前記共通ヘッダ情報の受信形態を比較する段階；
所定数の前記ヘッダ・フレームが前記共通ヘッダ情報の同一の受信形態を有することが判明した場合に、該同一の受信形態を基準として分類する段階；および
前記共通ヘッダ情報の受信形態が前記基準と異なる各ヘッダ・フレームに対応する一つまたはそれ以上の受信データ・フレームを、受信した異なる形態ではなく前記の基準の形態を利用することにより処理する段階；
によって構成され、
前記ヘッダ情報は、フレーム固有ヘッダ情報をさらに含んで構成され、前記共通ヘッダ情報の受信形態が前記基準と異なる一つまたはそれ以上のヘッダ・フレームのフレーム固有ヘッダ情報は、前記共通ヘッダ情報の受信形態が前記基準と同じであるヘッダ・フレームのフレーム固有ヘッダ情報と比較して、異なる用いられかたをされ、
異なる用いられかたをされる前記フレーム固有ヘッダ情報は、第１メッセージ終了認識方法のメッセージ終了指標であり、これに応答して、第２メッセージ終了方法が開始されることを特徴とする方法。
【請求項２】
前記ヘッダ情報は、フレーム固有ヘッダ情報をさらに含んで構成され、前記共通ヘッダ情報の受信形態が前記基準と異なる一つまたはそれ以上のヘッダ・フレームのフレーム固有ヘッダ情報は除外されることを特徴とする請求項１記載の方法。
【請求項３】
前記ヘッダ情報は、ブロック・ベースの符号化方式を利用して、順方向エラー訂正符号化されることを特徴とする請求項１乃至２のいずれかに記載の方法。
【請求項４】
前記基準が判定される前に受信されたデータ・フレームは、前記基準が判定された後に、処理の前にバッファされることを特徴とする請求項１乃至３のいずれかに記載の方法。
【請求項５】
分散音声認識プロセスにおいて受信データを処理する装置であって、前記分散音声認識プロセスでは、複数のデータ・フレームからなるフレーム構造でデータが配列され、前記複数のデータ・フレームのそれぞれの前には、共通ヘッダ情報を含むヘッダ情報からなる各ヘッダ・フレームが配置され、第１位置から送信された前記データは第２位置にて受信され、前記データは各ヘッダ・フレーム情報を利用して処理され、当該装置は：
複数のヘッダ・フレームのそれぞれからの前記共通ヘッダ情報の受信形態を比較する手段；
所定数の前記ヘッダ・フレームが前記共通ヘッダ情報の同一の受信形態を有することが判明した場合に、前記同一の受信形態を基準として分類する手段；および
前記共通ヘッダ情報の受信形態が前記基準と異なる各ヘッダ・フレームに対応する一つまたはそれ以上の受信データ・フレームを、受信した異なる形態ではなく、前記の基準の形態を利用することにより処理する手段；
によって構成され、
前記ヘッダ情報は、フレーム固有ヘッダ情報をさらに含んで構成され、前記共通ヘッダ情報の受信形態が前記基準と異なる一つまたはそれ以上のヘッダ・フレームのフレーム固有ヘッダ情報は、前記共通ヘッダ情報の受信形態が前記基準と同じであるヘッダ・フレームのフレーム固有ヘッダ情報と比較して、異なる用いられかたをされ、
異なる用いられかたをされる前記フレーム固有ヘッダ情報は、第１メッセージ終了認識方法のメッセージ終了指標であり、これに応答して、第２メッセージ終了方法が開始されることを特徴とする装置。
【請求項６】
前記ヘッダ情報は、フレーム固有ヘッダ情報をさらに含んで構成され、前記共通ヘッダ情報の受信形態が前記基準と異なる一つまたはそれ以上のヘッダ・フレームのフレーム固有ヘッダ情報は除外されることを特徴とする請求項５記載の装置。
【請求項７】
前記ヘッダ情報は、ブロック・ベースの符号化方式を利用して、順方向エラー訂正符号化されることを特徴とする請求項５乃至６のいずれかに記載の装置。
【請求項８】
前記基準が判定される前に受信されたデータ・フレームは、前記基準が判定された後に、処理の前にバッファされることを特徴とする請求項５乃至７のいずれかに記載の装置。
【発明の詳細な説明】
（産業上の利用分野）
本発明は、分散音声認識プロセスにおいて受信データを処理する方法に関する。また、本発明は、分散音声認識プロセスにおいて受信データを処理する装置に関する。本発明は、無線通信リンク上で送信される際の音声認識パラメータに関する受信データの処理に適するが、それに限定されるものではない。
【０００１】
（従来の技術）
音声認識(speech recognition)は、音声からの音，単語の一部，単語または語句を自動的に認識するためのプロセスである。このようなプロセスは、スイッチ，キーボード，マウスなどより一般的に利用されるツールを用いる他に、あるいは用いる代わりに、人間と機械との間のインタフェースとして利用できる。また音声認識プロセスは、発声通信またはメッセージから自動的に情報を取り出すためにも利用できる。
【０００２】
自動音声認識を提供するために、さまざまな方法が開発され、現在も改善されつつある。ある方法は、対応する学習戦略(heuristic strategies)とともに幅広い知識に基づき、また他の方法は統計モデルを採用する。
【０００３】
典型的な音声認識プロセスでは、処理すべき音声は、例えば毎秒５０〜１００回など、サンプリング・タイムフレーム中に複数回サンプリングされる。サンプリングされた値は、音声認識パラメータを与えるアルゴリズムを利用して処理される。例えば、一つの種類の音声認識パラメータは、メル・ケプストラム係数(mel cepstral coefficient)として知られる係数からなる。このような音声認識パラメータは、アレイ(array)として知られるベクトルの形式に配列され、アレイはある次数で配列されたパラメータのグループまたはセット（群または集合）として考えることができる。サンプリング・プロセスは、さらなるサンプリング・タイムフレームのために反復される。典型的なフォーマットでは、各サンプリング・タイムフレーム毎に一つのベクトルが生成される。
【０００４】
上記のパラメータ化およびベクトル化は、音声認識プロセスのいわゆるフロントエンド動作を構成する。ベクトルに配列された上記の音声認識パラメータは、音声認識プロセスのいわゆるバックエンド動作において、音声認識手法に従って解析される。フロントエンド処理およびバックエンド処理が同じ位置であるいは同じデバイスで実行される音声認識プロセスでは、フロントエンドからバックエンドに至る間に音声認識パラメータに導入されるエラーが生じる尤度は最小限である。
【０００５】
しかし、分散音声認識プロセス(distributed speech recognition process)として知られるプロセスでは、音声認識プロセスのフロントエンド部分はバックエンド部分から離れて実行される。第１位置において、音声はサンプリングされ、パラメータ化され、音声認識パラメータはベクトルに配列される。音声認識パラメータは量子化された後、例えば、確立された通信システムの通信リンク上で、第２位置に送信される。多くの場合、第１位置は遠隔端末であり、第２位置は中央処理局である。受信された音声認識パラメータは、第２位置にて音声認識手法に従って解析される。量子化された音声認識パラメータと、そのベクトル配列はデータを構成し、このデータは第１位置から送信され、第２位置にて受信される。このデータの送信を促進するために、一般にデータは、複数のデータ・フレームからなるフレーム構造に配列され、各データ・フレームの前には、共通のヘッダ情報からなる各ヘッダ・フレームが配置される。また、ヘッダ・フレームは、該ヘッダ・フレームあるいは該ヘッダ・フレームに対応する特定のデータ・フレームのみに固有のヘッダ情報をさらに含むようなヘッダ・フレームでもよい。
【０００６】
多くの種類の通信システムにおける多くの種類の通信リンクは、分散音声認識プロセス用として検討できる。一例として、従来の有線通信システム、例えば、一般電話交換網（ＰＳＴＮ）がある。別の例としては、無線通信システム、例えば、ＴＥＴＲＡがある。別の例としては、セルラ無線通信システムがある。適用可能なセルラ通信システムの一例として、ＧＳＭ(global system for mobile communications)システムがあり、別の例としては、現在標準化が進んでいるＵＭＴＳ(Universal Mobile Telecommunications System)などのシステムがある。
【０００７】
混乱を避けるために、上記のデータ・フレームは、例えば、ＧＳＭセルラ無線通信システムの時分割多元接続（ＴＤＭＡ）タイムフレームなど、第１位置から第２位置にデータが送信されるところの通信システムの通信リンク上でデータを送信する際に用いられる送信フレームと混同すべきでないことを指摘しておく。
【０００８】
任意の通信システムにおいて任意の通信リンクを用いることにより、この通信リンク上で第１位置から第２位置に送信されるデータまたヘッダ情報にエラーが生じる可能性が生まれる。
【０００９】
音声パラメータが受ける特殊な音声認識手法により、分散音声認識プロセスの特性に特に適した方法で、ヘッダ情報に生じるエラーに対してある程度の耐性を提供する、受信データを処理するための手段を提供することが望ましい。
【００１０】
さらに、送信情報のある部分におけるエラーの存在が検出可能となるように、通信システムにおいてエラー検出手法を提供することが知られている。周知の手法の一つに、循環冗長符号化(cyclic redundancy coding)がある。また、送信情報のある部分におけるエラーを訂正するように、通信システムにおいて自動エラー訂正手法を提供することが知られている。周知の手法の一つに、ゴーレイ(Golay)エラー訂正がある。また、エラー検出およびエラー訂正を組み合わせて採用することも知られている。
【００１１】
自動エラー訂正が適用されると、訂正される情報の全体の訂正された形態が本来のエラー部分とは別のさらなる矛盾(discrepancies)を含むという危険がある。なぜならば、このような方法は最良の全体的に正しいと想定される解への近似を伴う傾向があるためである。これは、ブロック・ベースの符号化方式を利用する符号化を採用する順方向エラー訂正手法の場合である。このような例の一つにゴーレイ符号化(Golay coding)があり、この符号化により、例えば、１２ビットの情報を２４ビット中に送信でき、その際に最大３つのエラーを訂正できる。訂正手法では、情報の全体、例えば、複合的にヘッダ・フレーム全体の訂正を行う。しかし、４つ以上のエラーが２４ビット中に生じると、訂正手法はヘッダ全体を誤って訂正されたものに訂正する。分散音声認識プロセスにおいて、ヘッダ・フレーム全体を誤って訂正されたものに複合的に訂正することに関連する問題を緩和する、受信データを処理するための手段を提供することが望ましい。
【００１２】
また、他の情報形式に適用する際に二次的な問題を発生しない自動エラー訂正の手法は、、分散音声認識プロセスにおいて上記のヘッダ・フレームにおけるエラーに適用した場合に、必ずしも問題がないわけではない。これは、部分的には、対応するデータ・フレームにおけるデータは各ヘッダ・フレーム情報を利用して処理されることに起因する。従って、二次的問題を緩和する、分散音声認識プロセスにおいて受信データを処理するための手段を提供することが望ましい。
【００１３】
（発明の概要）
本発明は、上記の態様の一部または全てに対処する。
【００１４】
本発明の一態様に従って、請求項１において請求されるような、分散音声認識プロセスにおいて受信データを処理する方法が提供される。
【００１５】
本発明の別の態様に従って、請求項７において請求されるような、分散音声認識プロセスにおいて受信データを処理する装置が提供される。
【００１６】
本発明のさらなる態様は、従属請求項に請求される通りである。
【００１７】
本発明は、分散音声認識プロセスの性質に特に適した、受信データを処理する手段を提供し、この形態において、データは第１位置から第２位置に送信される際に受信され、この方法において、該データは分散音声認識プロセスにおける第２位置にて受信した後に処理される。
【００１８】
特に、本発明の方法において、音声認識プロセスにおける待ち時間(latency)を許容する可能性が利用される。特に利用されるのは、分散音声認識プロセスにおいて、メッセージの開始に向かう待ち時間は、メッセージの最後における低い待ち時間と組み合わせると、特に許容可能となるという要因である。
【００１９】
さらなる特定の利点については、以下の説明および図面から明らかになろう。
【００２０】
（好適な実施例の説明）
以下で説明する一例としての実施例では、音声認識パラメータは、図１に模式的に示すように、サンプリング・タイムフレームに対応するベクトルで配列される。
【００２１】
処理される音声信号１１０の一部を図１に示す。音声信号１００は、実際には、さらに複雑なサンプル値のシーケンスからなるので、大幅に簡略化された形式で示されている。図１において、第１サンプリング・タイムフレーム１２１，第２サンプリング・タイムフレーム１２２，第３サンプリング・タイムフレーム１２３および第４サンプリング・タイムフレーム１２４が示されている、サンプリング・タイムフレームは、図１に示すように音声信号上に重畳される。下記の実施例では、毎秒１００個のサンプリング・タイムフレームが存在する。音声信号は、各サンプリング・タイムフレームの最中に反復的にサンプリングされる。
【００２２】
下記の実施例では、音声認識プロセスは、全部で１４個の音声認識パラメータが採用されるプロセスである。最初の１２個のパラメータは、最初の１２個のスタティック・メル・ケプストラム係数(static mel cepstral coefficients)、すなわち、
【００２３】
【数１】
0004531261.tif 000002
【００２４】
であり、ここでｍはサンプリング・タイムフレーム番号を表す。１３番目に用いられる音声認識パラメータは、ゼロ番目のケプストラム係数、すなわち、ｃ0（ｍ）である。１４番目に用いられる音声認識パラメータは、対数エネルギ項(logarithmic energy term)、すなわち、ｌｏｇ［Ｅ（ｍ）］である。これらの係数の詳細および音声認識プロセスにおける用途については当技術分野で周知であり、ここではさらに詳しい説明を要しない。また、本発明はケプストラム係数以外の音声認識パラメータの他の選択または方式の場合と同様に、音声認識パラメータを形成する他のケプストラム係数の組合せでも実行できることに留意されたい。
【００２５】
各サンプリング・タイムフレーム毎の１４個のパラメータは、図１に示すように、アレイともいう対応するベクトルに配列、あるいはフォーマットされる。ベクトル１３１はサンプリング・タイムフレーム１２１に対応し、ベクトル１３２はサンプリング・タイムフレーム１２２に対応し、ベクトル１３３はサンプリング・タイムフレーム１２３に対応し、ベクトル１３４はサンプリング・タイムフレーム１２４に対応する。このようなベクトルは一般に次式のように表すことができる。
【００２６】
【数２】
0004531261.tif 000003
【００２７】
音声認識パラメータは、第１位置から第２位置に送信される前に処理される。下記の実施例では、これは次のようにして実行される。ベクトル１３１からのパラメータは量子化される。これは、ベクトルをスプリット・ベクトル量子化器(split vector quantizer)で直接量子化することによって実施される。係数はペアにグループ化され、各ペアは、該ペアについてあらかじめ決められたベクトル量子化（ＶＱ：vector quantization）コードブックを利用して量子化される。それによって得られるインデクス値のセットは、音声フレームを表すために用いられる。各ペアについて用いられるコードブック・サイズとともに、フロントエンド・パラメータ毎の係数ペアリングを以下の表１に示す。
【００２８】
【表１】
0004531261.tif 000004
【００２９】
最も近いＶＱ重心(centroid)は、インデクスを判定するために加重ユークリッド距離(weighted Euclidian distance)を利用して求められる
【００３０】
【数３】
0004531261.tif 000005
【００３１】
ここで、ｑji,i+1は、コードブックＱi,i+1におけるｊ番目のコードベクトルを表し、Ｎi,i+1はコードブックのサイズであり、Ｗi,i+1はコードブックＱi,i+1について適用される（大体は単位行列(identity)）加重マトリクスであり、ｉｄｘi,i+1（ｍ）はベクトル［ｙi（ｍ），ｙi+1（ｍ）］Tを表すために選択されたコードブック・インデクスを表す。
【００３２】
次に、生成されるインデクスは４４ビットの形式で表される。これら４４ビットは、図１の参照番号１４１に示されるように、ビット・ストリーム・フレーム１５０の最初の４４スロットに入れられる。次のベクトル、すなわち、ベクトル１３２について生成された対応する４４ビットは、図１の参照番号１４２に示されるように、ビット・ストリーム・フレーム１５０の次の４４スロットに入れられる。ビット・ストリーム・フレーム１５０の残りのビットは、図１の参照番号１４６に示されるように、循環冗長符号の４ビットからなり、このビットの値は、ビット・ストリーム・フレーム１５０の８８個の前置ビット全体について、周知な方法でエラー検出を行うように判定される。同様に、ベクトル１３３から与えられる４４ビットは、図１の参照番号１４３に示されるように、第２ビット・ストリーム・フレーム１５５の最初の４４スロットに入れられる。また、次のベクトル、すなわち、ベクトル１３４について生成された対応する４４ビットは、図１の参照番号１４４に示されるように、ビット・ストリーム・フレーム１５５の次の４４スロットに入れられる。ビット・ストリーム・フレーム１５５の残りのビットは、図１の参照番号１４８に示されるように、循環冗長符号の４ビットからなる。この配列は、以降のベクトルについて反復される。２つのベクトルからのビット・データが一つの合成ビット・ストリーム・フレームにて配列されるところの上記のビット・ストリーム・フレームのフォーマットは一例に過ぎない。例えば、各ベクトルのデータは、それ自体のエラー検出ビットを含む一つのビット・ストリーム・フレームで配列してもよい。同様に、ビット・ストリーム・フレーム毎のスロットの数は一例に過ぎない。
【００３３】
上記のビット・ストリーム・フレームに収容・配列されたデータは、図２に示すようにさらに配列される。ビット・ストリーム・フレームは、それぞれが一つまたはそれ以上のビット・ストリーム・フレームからなるデータ・フレームで配列される。本実施例では、各データ・フレームは１２個のビット・ストリーム・フレームを収容する。従って、この例では、データ・フレーム２３０が図示され、ビット・ストリーム・フレーム１５０，１５５と、２１１〜２２０と記されたさらに１０個のビット・ストリーム・フレームとによって構成される。データ・フレーム２３０の前には、図２に示されるように、その対応するヘッダ・フレーム２４０が配置される。それぞれがその前に各ヘッダ・フレームを有する各データ・フレームは、図３に示すように連続的に配列され、ここでヘッダ・フレーム２４０はその対応するデータ・フレーム２３０の前にあり、ヘッダ・フレーム３１０はその対応するデータ・フレーム３２０の前にあり、ヘッダ・フレーム３３０はその対応するデータ・フレーム３４０の前にある。実際には、対応するデータ・フレームを有する多くのこのようなヘッダ・フレームが続く。本実施例では、各ヘッダ・フレームは２４個のスロットからなる。データ・フレームおよびヘッダ・フレームの上記のフォーマットは、一例に過ぎない。同様に、データ・フレーム毎のビット・ストリーム・フレームの数およびヘッダ・フレーム内のスロットの数は一例に過ぎない。
【００３４】
各ヘッダ・フレームは共通のヘッダ情報からなる。これは、各ヘッダにおいて同一の情報である。この情報は、上記のようにデータが処理される際に用いられ、ここで用いられる情報は、サンプリング・レートが適用可能であるような例を挙げた。この例では、可能なサンプリング・レート値は８ｋＨｚおよび１６ｋＨｚである。別の可能性は、標準または雑音耐久(noise robust)プロトコルまたはトラックが適用可能であるかどうかに関する情報である。
【００３５】
各ヘッダ・フレームは、選択的にフレーム固有情報すなわち異なるヘッダについてある程度変化する情報をさらに含むことができる。フレーム固有情報の一例は、第１のメッセージ終了認識(end-of-message recognition)方法に従って、メッセージ終了指標(end-of-message indicator)、すなわち、メッセージが終了することを示す信号、を含む。この例では、第１のメッセージ終了認識方法は、データ・フレームを適切な長さに詰める(pad out)ために送信機によって挿入される、ヘッダ内のメッセージ終了指標によって通知される最後のデータ・フレーム内のオール・ゼロ・ビット・ストリーム・フレームを探すことからなる。メッセージ終了指標は、ヘッダのフレーム固有データ部分内で設定される単一ビットからなる。フレーム固有情報の別の例は、音声に対する並列チャネル、例えば、ボタン押下(button press)の信号、を実質的に表す情報である。
【００３６】
ヘッダ情報がブロック・ベースの符号化方式を利用して順方向エラー訂正符号化されるところの本発明の別の態様は、以下で説明する一例としての実施例において採用される。この例で採用される特定の種類のエラー保護はゴーレイ・エラー保護(Golay error protection)であり、その一般特性および採用モードは当技術分野において周知である。この場合、用いられる特定の値等は次の通りである。ヘッダ・フレームの情報は、［２４，１２，８］拡張システマティック・ゴーレイ・コードワードにおいて表される。この符号は１２ビットのデータをサポートし、最大３つのビット・エラーに対してエラー訂正能力を有する。このプロセスは、全部で２４ビットまでの容量を提供し、ヘッダ情報用の１２ビットと、エラー保護からの１２パリティ・ビットとからなる。利用するヘッダ情報が、この方式において全部で１２ビット未満しか必要としないような情報である場合、これらのビットは不変的なゼロに設定でき、将来の変更使用に対応できるように、すなわち、拡張ビット(expansion bits)として実質的に保留できる。２４ビットをフィールドに配列することは、当業者に既知の方法で実行できる。この例では、配列は以下の表２に示す通りであり、フィールドの定義は以下の表３に示す通りである。
【００３７】
【表２】
0004531261.tif 000006
【００３８】
【表３】
0004531261.tif 000007
【００３９】
用いられるゴーレイ発生多項式は次式の通りである。
【００４０】
【数４】
0004531261.tif 000008
【００４１】
標準［２３．１２］ゴーレイ符号は、偶数全体パリティ・チェック・ビットの追加により、２４ビットに拡張される。コードワードのパリティ・ビットは、以下の計算を用いて発生される。
【００４２】
【数５】
0004531261.tif 000009
【００４３】
ここで、Ｔは行列転置(matrix transpose)を表す。
【００４４】
混乱を避けるため、上記のヘッダ・フレーム，ビット・ストリーム・フレームおよびデータ・フレームは、データが第１位置から第２位置に送信されるところの通信システムの通信リンク上でビット・ストリーム・データを送信する際に用いられる送信フレーム、例えば、本明細書で説明される実施例にて採用される通信システムであるＧＳＭセルラ無線通信システムの時分割多元接続（ＴＤＭＡ）タイムフレーム、と混同すべきでないことを指摘しておく。この例では、第１位置は遠隔ユーザ局からなり、第２位置、すなわち、受信側位置は、例えば、セルラ通信システムの基地局に配置できる集中処理局(centralized processing station)からなる。従って、本明細書で説明する実施例では、音声認識パラメータは、無線通信リンク上で第１位置から第２位置に送信される。ただし、第１位置および第２位置の性質は、検討対象の通信システムの種類と、そこにおける分散音声認識プロセスの構成とに依存することを理解されたい。
【００４５】
ヘッダ・フレームおよびデータ・フレームは、第２位置において受信された後に第２位置においてその送信フォーマットから再構築される。その後、ヘッダ・フレームおよびデータ・フレームに収容されたデータは、各ヘッダ・フレーム情報を利用して処理される。一つの方法では、サンプリング・レートが採用されている収容された情報が用いられるように、各ヘッダ・フレーム情報が用いられる。データの処理は、ビット・ストリーム・フレームから音声認識パラメータを取り出して、音声認識自体を実行することを含む。あるいは、処理は、適切な種類のフレーム固有ヘッダ情報から導出される手順を実行することを含むことができる。上記の例では、フレーム固有ヘッダ情報は、音声に対する並列チャネル、例えば、ボタン押下の信号、を実質的に表し、そのため処理はこの信号に対して既知の方法で適切に応答することを含むことができる。
【００４６】
上記のように、ビット・ストリーム・フレームから音声認識パラメータを取り出すことは、次のようにして行われる。音声認識パラメータは、上記のベクトル量子化手順の逆手順を実行することによって、ビット・ストリーム・フレームから取り出される。さらに具体的には、インデクスはビット・ストリームから抽出され、これらのインデクスを利用して、ベクトルは以下の形式で再構築される。
【００４７】
【数６】
0004531261.tif 000010
【００４８】
また、以下の一例としての実施例では、ヘッダ情報はブロック・ベースの符号化方式を利用して順方向エラー訂正符号化されるので、このようなエラー訂正は、第２位置にてデータを受信した後に復号する必要がある。このゴーレイ・エラー保護の場合、このような復号は当技術分野で周知のいくつかの方法のうちの一つで実行できる。
【００４９】
以上、複数のデータ・フレームからなるフレーム構造にてデータが配列される分散音声認識プロセスについて説明したが、この複数のデータ・フレームの各データ・フレームの前には、共通のヘッダ情報を含むヘッダ情報からなる各ヘッダ・フレームが配置され、第１位置から送信された前記データは第２位置にて受信され、前記データは各ヘッダ・フレーム情報を用いて処理され、ヘッダ情報はブロック・ベースの符号化方式を利用して順方向エラー訂正符号化される。
【００５０】
第１実施例によるこのような音声認識プロセスにおいて受信データを処理する方法は、図４のプロセス・フローチャートに示される。図４を参照して、機能ボックス４１０は、複数のヘッダ・フレームのそれぞれからの前記共通ヘッダ情報の受信形態を比較する段階を示す。本実施例において、これはヘッダ・フレーム２４０，ヘッダ・フレーム３１０，ヘッダ・フレーム３３０および以降のヘッダ・フレームからの共通ヘッダ情報の受信形態を比較することからなる。比較すべき共通ヘッダ・フレーム情報は、本実施例では、サンプリング・レートの通知された値と、トラックが標準または雑音耐久(noise robust)であるかどうかである。
【００５１】
次の段階は、図４の機能ボックス４２０に示すように、所定の数の前記ヘッダ・フレームが前記共通ヘッダ情報の同一受信形態を有することが判明した場合に、この同一受信形態を基準として分類する段階である。本実施例では、所定の数は３０であるが、この数値は一般に検討対象の特定のシステムの条件に応じて一般に選択される。この方法段階を実行することによって、用いられる共通ヘッダ情報の値に対する信頼が得られる。この手順を実行する際に、特に所定の数がはるかに高いレベルに設定される場合に、生じる遅延は本発明において対処される。なぜならば、本発明は、メッセージの開始における待ち時間が比較的許容可能であるところの分散音声認識システムの特性を利用するためである。
【００５２】
次の段階は、図４の機能ボックス４３０に示すように、共通ヘッダ情報の受信形態が前記基準と異なる各ヘッダ・フレームに対応する一つまたはそれ以上の受信データ・フレームを、受信した異なる形態ではなく、基準形態を利用することにより処理する段階である。従って、不適切に受信された、あるいは信頼できない共通ヘッダ情報は除外され、関連するデータ・フレームが適正な共通ヘッダ情報に従って有利に処理される。
【００５３】
本実施例の一つの様式は、ヘッダ情報がフレーム固有ヘッダ情報をさらに含んで構成され、特に、フレーム固有ヘッダ情報が音声に対する並列チャネル、すなわち、ボタン押下の信号を実質的に表す、というオプションを含む。通常、処理はこの信号に対して既知の方法で適切に応答することを含む。ただし、本実施例のこの様式では、共通ヘッダ情報の受信形態が前記基準と異なる、一つまたはそれ以上のヘッダ・フレームのフレーム固有ヘッダ情報は除外される、すなわち、ボタン押下信号に対する応答は遮断される。こうすることにより、このヘッダ・フレームの共通ヘッダ情報が誤りであるならば、同じヘッダ・フレーム内のフレーム固有情報も誤りである可能性が高いという観点に基づいて、信頼できない命令は回避される。
【００５４】
また、本発明の別の様式は、ヘッダ情報はフレーム固有ヘッダ情報をさらに含んで構成され、特に第１メッセージ終了認識方法のメッセージ終了指標を適宜示すために用いられるフィールドを収容するという、オプションを含む。この第１メッセージ終了認識方法については、上で説明した通りである。上記の一例としてのヘッダ・フィールド配置について、表２および表３を参照して、メッセージ終了指標フィールドは、これらの表に設けた将来の拡張スペースのうちの一つまたはそれ以上を利用することを留意されたい。通常、処理は、メッセージ終了手順を実行することによって、このメッセージ終了指標に応答することを含む。ただし、本実施例のこの様式では、共通ヘッダ情報の受信形態が前記基準と異なる一つまたはそれ以上のヘッダ・フレームのフレーム固有ヘッダ情報、すなわち、第１メッセージ終了認識方法のメッセージ終了指標は、共通ヘッダ情報の受信形態が前記基準と同じであるヘッダ・フレームのフレーム固有ヘッダ情報と比較して、異なる用いられかたをする。特に、額面的にはメッセージ終了指標であるもの応答して、メッセージ終了手順を実際に実行するのではなく、第２メッセージ終了手順が開始される。従って、一方では、すでに誤った共通情報を有するヘッダ・フレームに収容されているので指標がエラーである場合に、この指標に応答する必要を省くことにより、メッセージ終了手順の誤った実行が回避されるが、もう一方では、部分的に誤りであるヘッダ・フレームに収容されているにもかかわらず、メッセージ終了指標が実際に正しかった場合に、メッセージ終了が実際に検出されることを保証するバックアップの意味で、別のメッセージ終了手順が起動される。なお、上記のメッセージ終了の主題は、本発明に従って、共通ヘッダ情報の矛盾に基づいて異なる処理を施すことができるフレーム固有情報の種類の一例を表すに過ぎないことを理解されたい。それどころか、実際には、本発明のこの態様は、共通情報部分においてエラーを有することがすでに判明しているヘッダ・フレームにおいて、情報がエラーを有する可能性がより高いという懸念がある場合に、慎重な処理の方が有利であろう任意の種類のフレーム固有情報に適用可能である。
【００５５】
上記の全ての実施例は、前記ヘッダ情報がブロック・ベースの符号化方式を利用して順方向エラー訂正符号化されるという、任意の特長を含むことができる。このような方式を実施することの詳細については、すでに説明済みである。この特長を含めると、本発明の利点は、このような修理のエラー訂正の複合的な性質により、特に増長される。複合的なやり方でヘッダ・フレーム全体が訂正されるので、共通ヘッダ情報が受信すべきものとは異なる場合には、基本的にヘッダ情報の残りの部分もエラーである可能性が高い。本例では、これは一つのヘッダ・フレーム内の４ビット以上がエラーである場合に特に生じる可能性が高い。
【００５６】
以上の実施例では、基準が判定される前に受信されたデータ・フレームは、以降の処理段階から単純に除外される。トレード・オフの意味では、これは処理の低減という利点を提供する。しかし、代替実施例では、前記基準が判定される前に受信されたデータ・フレームは、前記基準が判定された後に、処理の前にバッファされる。トレード・オフの意味では、これらの代替実施例は、データが失われないという意味でより良好な品質を提供するが、さらなるバッファを含むより多くの処理が必要になる。さらに、これらの代替実施例は、特に、メッセージの開始における待ち時間が比較的容易に許容できるという観点において、分散音声認識プロセスの待ち時間特性をさらに有利に利用する。
【００５７】
上記の実施例の例では、上記のデータ処理段階は、モトローラ社のＤＳＰ５６ｘｘｘ（商標）ファミリーのデバイスから選択されるデバイスなど、プログラマブル・デジタル信号処理デバイスによって実行される。あるいは、特定用途向け集積回路（ＡＳＩＣ）を採用できる。他の可能性も存在する。例えば、無線受信機と、バックエンド音声認識プロセッサの一部をなすコンピュータ・システムとの間をインタフェースするインタフェース・ユニットを利用できる。
【図面の簡単な説明】
【図１】  本発明の一実施例のサンプリング・タイムフレームに対応するベクトルで配列された音声認識パラメータの模式図である。
【図２】  本発明の一実施例の、ヘッダ・フレームと、データ・フレームで配列されたビット・ストリーム・フレームの模式図である。
【図３】  本発明の一実施例のデータ・フレームおよびヘッダ・フレームの模式図である。
【図４】  本発明の一実施例のプロセス・フローチャートである。
【図１】
0004531261.tif 000011
【図２】
0004531261.tif 000012
【図３】
0004531261.tif 000013
【図４】
0004531261.tif 000014