JP4509590B2 - 音声認識システムおよびそのプログラム - Google Patents

Description

本発明は、ＩＰ接続環境を用いて音声通話を行うＩＰ電話とはスイッチングハブを経由して接続され、通話セッション毎に保存された音声ストリームパケットをデータベースから抽出して音声認識を行う、音声認識システムおよびそのプログラムに関する

通信コストの低減を目的にＶｏＩＰ（Voice over Internet Protocol）電話が普及し、コンピュータと電話／音声通信を融合するＣＴＩ（Computer Telephony Information）システムへの応用が注目されるようになった。

ところで、例えば、コールセンタにおいて電話のログを取得するシステムの一つに、Ａｄｖａｎｃｅｄ Ｍｅｄｉａ社の「ＡｍｉＶｏｉｃｅ Ｃａｌｌ Ｓｃｒｉｂｅｒ」が知られている。本システムは、通話録音装置で録音された音声を認識し、認識結果と発話毎に分割された音声を保存するサーバを基本構成とする（例えば、非特許文献１参照）。
また、ログイット社のＮｉｃｅＬｏｇ（登録商標）も知られている。当該製品は、ＶｏＩＰ録音を可能にした記録装置であって、ＩＰパケット中のＨ．３２３情報をスニファーすることによって音声データを記録する、あるいは、ネットワーク上に多地点会議装置（ＭＣＵ）を配置しておき、そのＭＣＵからＨ．３２３情報を取得することによって音声データを記録する（例えば、非特許文献2参照）。
http://advanced-media.co.jp/prooducts/1502.html＜インターネット＞２００４年１月１５日閲覧、「ＡｍｉＶｏｉｃｅｓｅｒｉｅｓ製品情報」 http://www.logit.co.jp/products/nicelog/voip.html＜インターネット＞２００４年１月１５日閲覧、ログイット株式会社Ｐｒｏｄｕｃｔｓ［製品紹介］「ＶｏＩＰ録音を可能にした最新のＩＰレコーディング」

ところで、音声とテキストの関連付けに関し、従来のアナログ環境下ではテープやＷＡＶＥファイルに保存した音声とテキストの関連付けは実現されているが、上記したＶｏＩＰ環境での実現例はない。すなわち、ＶｏＩＰ環境においては音声データを認識単位に区切る必要があり、音声ストリーム（ＲＴＰ：Real Time Transport Protocolパケット）をそのまま繋ぎあわせると認識された音声が連続して聞こえ（例えば、「わた」＋「あめ」が、「わたあめ」）別の意味になってしまうことがある。このように、音声認識時に間違った語彙に変換され、テキストとの対応が取れない場合がある。

本発明は上記事情に鑑みてなされたものであり、音声データを認識する単位に無音で区切り、認識音声とテキストを関連付けて保存することにより、音声認識時に誤った語意に変換されることを防いだ、音声認識システムおよびそのプログラムを提供することを目的とする。

上記した課題を解決するために本発明は、ＩＰ接続環境を用いて音声通話を行うＩＰ電話とはスイッチングハブを経由して接続され、通話セッション毎に保存された音声ストリームパケットを第１の記憶装置から抽出して音声認識を行う音声認識システムであって、前記抽出された音声ストリームパケットを無音区間（時間α）で仕切り、当該無音区間の間に含まれる無音区間（β、但しα＞β）に無音データを挿入する音声認識前処理部と、当該無音区間（α）を単位に前記音声ストリームパケットの音声認識を行い、テキストデータに変換する音声認識部と、前記変換されたテキストデータを前記変換前の音声ストリームパケットと関連付けて第２の記憶装置に保存する認識音声・テキスト管理部と、を備えたことを特徴とする。

また、本発明において、前記音声認識前処理部は、前記抽出された音声ストリームパケットのヘッダ情報を参照し、当該ヘッダ情報に含まれるタイムスタンプから所定時間以上間隔のある個所を前記仕切りとして判定し、前記音声認識部に対して音声認識の単位として供給することを特徴とする。

また、本発明において、外部から音声検索要求を受信し、前記通話セッション毎に作成されたインデックスデータが示す前記音声ストリームパケットの格納場所から該当する音声ストリームパケットを検索して再生する検索要求・再生応答部、を備えたことを特徴とする。

上記した課題を解決するために本発明は、ＩＰ接続環境を用いて音声通話を行うＩＰ電話とはスイッチングハブを経由して接続され、通話セッション毎に保存された音声ストリームパケットを第１の記憶装置から抽出して音声認識を行う音声認識システムに用いられるプログラムであって、前記抽出された音声ストリームパケットを無音区間（時間α）で仕切り、当該無音区間の間に含まれる無音区間（β、但しα＞β）に無音データを挿入する処理と、当該無音区間（α）を単位に前記音声ストリームパケットの音声認識を行い、テキストデータに変換する処理と、前記変換されたテキストデータを前記変換前の音声ストリームパケットと関連付けて第２の記憶装置に保存する処理と、をコンピュータに実行させることを特徴とする。

本発明によれば、認識前処理部が、抽出した音声ストリームパケットを無音区間（α）で仕切り、当該無音区間の間に含まれる無音区間（β）に無音データを挿入することで、音声認識部が、その無音区間（α）を単位に音声ストリームパケットの音声認識を行ってテキストデータに変換し、認識音声・テキスト管理部を介してそのテキストデータを変換前の音声ストリームパケットと関連付けて保存することにより、両者の関連付けが可能となる。認識前処理部はまた、抽出された音声ストリームパケットのヘッダ情報を参照し、当該ヘッダ情報に含まれるタイムスタンプから所定時間以上間隔のある個所を仕切りとして判定し、音声認識部に対して音声認識の単位として供給することで、音声認識時に誤った語意に変換されることを防ぐことができる。

更に、本発明によれば、検索要求・再生応答部が、音声検索要求を受信して通話セッション毎に作成されたインデックスデータが示す音声ストリームパケットの格納場所から該当する音声ストリームパケットを検索して再生することにより、検索処理の高速化を実現できる。このとき、容量の大きな音声メディアを外部に保存することで内部ストレージの圧迫も回避できる。

図１は、本発明実施形態における音声認識システムの構成を示す図である。ここでは、ＶｏＩＰを利用したＩＰ電話の接続環境におけるコールセンタのネットワーク構築例が示されている。

図１において、符号１、２は、互いに送信元、送信先となるＩＰ電話であり、両者は、ＩＰ／ＰＳＴＮ（Public Switched Telephone Network）網３を介して接続される。符号４は、ＧＷ（Gate Way）／ルータであり、ＩＰ電話１、２間の通信を中継する。また、ＧＷ／ルータ４とＩＰ電話２間にはスイッチングハブ５が接続され、当該スイッチングハブ５は、ＩＰ電話１、２間の通信データを取り込み、そしてその通信データはロギングサーバ６によってスニッフィングされ、採取された通信データのログはデータベース（ＤＢ８）へ保存される。また、符号７は、音声認識サーバであり、ＤＢ８に保存されたログを読み込んで音声認識（音声テキスト変換）を行い、その結果であるテキストデータと音声データとを通話セッション毎に対応づけてＤＢ８に保存する。
なお、符号９は、検索用ＰＣであり、テキストをキーにＤＢ８を参照して必要な音声データを検索して再生することができる。

図２は、図１に示すロギングサーバ６、音声認識サーバ７の内部構成の一例を示すブロック図である。ここでは本発明と関係するブロックのみ抽出して示されている。
ロギングサーバ６は、ログ保存部（ＶｏＩＰ）６１と、テンポラリＤＢ８１と、パケット抽出部（シグナリング）６２と、パケット抽出部（音声ストリーム）６３と、セッション識別部６４と、ログ保存部６５と、パケット補間部（シグナリング／音声ストリーム）６６と、ログＤＢ８２で構成される。

ログ保存部６１は、ＩＰ電話１、２の接続を中継するスイッチングハブ５を介して受信されるデータからＶｏＩＰパケットを抽出してテンポラリＤＢ８１に一時保存する。また、パケット抽出部６２は、テンポラリＤＢ８１に保存されたＶｏＩＰパケットからシグナリングパケットを抽出し、パケット抽出部６３は、抽出されたシグナリングパケットから音声ストリーム情報を判別してテンポラリＤＢ８１から音声ストリームパケットを抽出する。
セッション識別部６４は、通話セッションの識別処理を行いログ保存部６５へその識別情報を供給する。ログ保存部６５は、パケット抽出部６２で抽出されたシグナリングパケットと、パケット抽出部６３で抽出された音声ストリームパケットとをセッション識別部で識別された識別情報に基づき関連付け、セッション毎にログＤＢ８２に保存する。
図７に、ログＤＢ８２に対しセッション毎に保存されるＶｏＩＰパケットのデータ構造の一例が示されている。図７に示されるように、セッション（＃０〜＃ｎ）毎、シグナリングでやりとりしたデータ、およびＲＴＰヘッダ付きの音声ストリームパケットが上り（アップストリーム）、下り（ダウンストリーム）毎タイムスタンプ付きで保存される。

なお、ログ保存部６５は、パケット抽出部６２により抽出されたシグナリングパケットのスタート、エンドを判別して、ログＤＢ８２における記憶領域の確保と閉鎖を行い、パケット抽出部６３により抽出された音声ストリームパケットを判別してログＤＢ８２に確保された記憶領域へログ保存を開始する。
一方、パケット補間部６６は、テンポラリＤＢ８１に未抽出の音声ストリームパケットが残存した場合、当該残存する音声ストリームパケットのヘッダ情報を参照し、セッションが同じで複数あるパケットを抽出して同一セッションの音声ストリームパケットとしてログＤＢ８２に追加保存する。また、音声ストリームパケットが一部ロストしていた場合、テンポラリＤＢ８１に残存する音声ストリームパケットのヘッダ情報を参照し、ロストしたパケットの前後のシーケンス番号に相当する音声ストリームパケットを読み出し、当該前後の音声ストリームパケットをコピーしてロストしたパケットのシーケンス番号を割当て、コピーした音声ストリームパケットをログＤＢ８２に追加保存する。

一方、音声認識サーバ７は、認識前処理部７１と、音声認識部７２と、認識音声・テキスト管理部７３と、検索要求・再生応答部７４と、音声・テキストＤＢ８３で構成される。
認識前処理部７１は、後述するように、抽出された音声ストリームパケットを無音区間（α）で仕切り、当該無音区間の間に含まれる無音区間（β）に無音データを挿入して音声認識部７２へ供給する。すなわち、音声認識前処理部７１は、抽出された音声ストリームパケットのヘッダ情報を参照し、当該ヘッダ情報に含まれるタイムスタンプから所定時間以上間隔のある個所を仕切りとして判定し、音声認識部７２に対して音声認識の単位として供給する。
音声認識部７２は、当該無音区間（α）を単位に音声ストリームパケットの音声認識を行い、テキストデータに変換して認識音声・テキスト管理部７３へ供給する。また、認識音声・テキスト管理部７３は、音声認識部７２によって変換されたテキストデータを変換前の音声ストリームパケットと関連付けて音声・テキストＤＢ８３に保存する。

音声・テキストＤＢ８３のデータ構造の一例を図８に示す。図８に示されるように、音声・テキストＤＢ８３には、図７に示されるログＤＢ８２が保存する内容に、更に、セッション毎の認識テキスト（音声ストリームを音声認識したデータ）、および音声ストリームと当該テキストとの時間関係データが追加保存される。また、インデックス情報が付加され、検索を高速化する配慮もなされている。すなわち、インデックスには、メディアデータ（音声ストリーム）の格納場所が示されている。
検索要求・再生応答部７４は、外部から音声検索要求を受信し、通話セッション毎に作成されたインデックスデータが示す音声ストリームパケットの格納場所から該当する音声ストリームパケットを検索して再生する機能を持つ。

図３は、本発明実施形態の基本動作を説明するために引用したフローチャートであり、図４、図５にロギング処理の詳細動作が、図１０にログを用いた音声認識処理が示されている。図１０は、本発明のフログラムの処理手順も示している。
また、図６〜図８、図９、図１１は、いずれも動作概念図であり、図３〜図５、図１０に示すフローチャートの理解を助ける意味で引用した。
以下、図３〜図１１を参照しながら図１、図２に示す本発明実施形態の動作について詳細に説明する。

まず、図３に示すフローチャートを参照して図１に示す本発明実施形態の音声認識システムの基本動作から説明する。
まず、ＩＰ電話１、２間で通話が行われる（Ｓ３１）。このとき、ログサーバ６によるロギング処理が開始され、採取された通話ログをログＤＢ８に保存する（Ｓ３２）。ロギング処理の詳細は、図４、図５に示すフローチャートを参照しながら後述する。そして、音声認識サーバ７による音声テキスト変換が行われ（Ｓ３３）、通話セッション毎、認識されたテキストと音声と対応づけられた音声−テキスト対応テーブルが作成され、ＤＢ８に格納される（Ｓ３４）。
一方、テキストをキーにした検索要求があったときに（Ｓ３５、Ｙｅｓ）ＤＢ８に格納された音声−テキスト対応テーブルを検索して対応する音声を再生する（Ｓ３６）。

以下、図１、図２に示すロギングサーバ６によるロギング処理の詳細を、図４、図５に示すフローチャート、ならびに図６〜図８に示す動作概念図を参照しながら詳細な動作説明を行う。動作説明に先立ち、図１２を用いてＶｏＩＰの概略説明を行う。
図１２に示されるように、ＶｏＩＰでは、呼制御、通信情報、ＲＴＰ（Real Time Transport Protocol）接続のための情報等に関するシグナリングの転送は、ＴＣＰ（Transmission Control Protocol）を使用するため、ＩＰパケットは完全に相手側に送信される。しかしながら、音声の転送はＵＤＰ（User Datagram Protocol）を使用するため、ＩＰパケットを完全に相手側に送信することは保証されず、従って送信途中でＩＰパケットを失う（ロストする）ことが多々ある。また、ＩＰパケットの取得および保存する処理が遅いとアプリケーションが追随できず、一層、ＩＰパケットをロストする可能性が高くなる。このようにＩＰパケットがロストしたことによって不足すると音声認識の精度が低下する。このため、以下に説明する処理が実行される。以下に詳細説明を行う。

図４に示すフローチャートにおいて、まず、ログ保存部６１は、ＩＰ電話１、２の接続を中継するスイッチングハブ５を介して受信されるデータからＶｏＩＰパケットを抽出してテンポラリＤＢ８１に一時保存する（Ｓ５１、Ｓ５２）。
次に、パケット抽出部６２は、テンポラリＤＢ８１に保存されたＶｏＩＰパケットからシグナリングパケットを抽出してパケット抽出部６３、およびセッション識別部６４へ供給する（Ｓ５３）。パケット抽出部６３は、ログ保存部６１により抽出され保存されたシグナリングパケットから音声ストリーム情報を判別し、更にテンポラリＤＢ８１から音声ストリームパケットを抽出してログ保存部６５へ供給する（Ｓ５４）。このときログ保存部６５は、抽出されたシグナリングパケットと音声ストリームパケットとを、セッション識別部６４によって識別された識別情報に基づき関連付け、セッション毎ログＤＢ８２に保存する（Ｓ５５）。

テンポラリＤＢ８１に保存されたＶｏＩＰパケットの判別処理の詳細を図５に示す。図５に示すフローチャートおいて、まず、パケット抽出部６２、６３は、テンポラリＤＢ８１に保存された全ＶｏＩＰパケットの判別を開始する（Ｓ４１）。そして、ログ保存部６５は、シグナリングと音声ストリーム、およびその他データの分類を行い（Ｓ４２）、パケット抽出部６２により抽出されたシグナリングパケットのスタート、エンドを判別して（Ｓ４３）、ログＤＢ８２における記憶領域の確保と閉鎖を行い（Ｓ４４、Ｓ４５）、また、パケット抽出部６３により抽出された音声ストリームパケットを判別して先にログＤＢ８２の確保された記憶領域へログ保存を開始する（Ｓ４７）。
なお、Ｓ４３の処理において、シグナリングパケットがその他データである場合は適切な処理を行い（Ｓ４６）、また、Ｓ４２の処理において、保存データがシグナリングパケットでも音声ストリームパケットにも該当しないその他データである場合は破棄する（Ｓ４８）。

説明を図４のフローチャートに戻す。以上のようにログＤＢ８２に抽出した音声ストリームパケットをセッション毎に保存した後、テンポラリＤＢ８１から未だ抽出されていない音声ストリームパケットが残った場合（Ｓ５６“有り”）、シグナリングパケットがロストしていたことになる（Ｓ５７“シグナリリング”）。
このとき、パケット補間部６６は、音声ストリームのＲＴＰヘッダ中、ＳＳＲ（Synchronization Source）値が同一で複数あるものを抽出し（Ｓ５８）、同一セッションのデータとしてログＤＢ８２に追加保存する（Ｓ５９）。また、音声ストリームパケットが一部ロストしていた場合は（Ｓ５７“音声ストリーム”）、テンポラリＤＢ８１に残存する音声ストリームパケットのヘッダ情報を参照し、ロストした前後のシーケンスＮｏ．のデータを取得する（Ｓ６０）。そして、データに誤差が少ない場合は、前後のデータをコピーし（Ｓ６１）、ロストしたシーケンスＮｏ．を割当てて追加保存する（Ｓ６２）。

図６に、上記した本発明のパケットロギングシステムによるログ保存のための処理が概念的に示されている。図６に示されるように、ロギングサーバ６は、受信したデータ（シグナリングパケット、音声ストリームパケット、その他データ）の全てをＤＢ８に一時保存し（ａ）、更に、上記した手順に従いＤＢ８からセッション毎に必要なパケットを抽出し、同じくＤＢ８に保存する（ｂ）。最後に、音声認識サーバ７によって認識結果であるテキストを付与してＤＢ８に追加保存して終了となる。

このことにより、システム負荷を減らし、採取したＩＰパケットを高速に保存処理することができ、ＩＰパケットロストが音声認識に与える影響を極力回避できる。また、シグナリングパケットやその他音声ストリームパケットの一部がロストしてもその影響を補正できる。

次に、図９〜図１１を参照してログＤＢ８２に保存された音声データを読み出して音声認識を行い、認識テキストを追加保存する動作について詳細説明を行う。
図９に（ａ）として示される波形は、電話で両者が「もしもし。＊＊＊です。」「ああ！」「はい。それではまたの機会に」と発話したときの波形レベルでの特徴点（図中、楕円で囲まれたハッチング部分）を示す図であり、主に句読点等の特徴点を見出し、文節毎に音声認識を行えば音声と認識テキストとの関連付けを行うことが可能であることがわかる。そこで、本発明では、ＲＴＰの無音区間から会話の特徴点を検出し、会話のやりとり毎に音声認識を行うこととした。また、文節単位で音声と認識テキストとの関連付けが可能である。

図１０に、ＲＴＰの無音区間から会話の特徴点を検出し、会話のやりとり毎に音声認識を行うための処理手順がフローチャートで示され、図１１にその動作概念図が示されている。以下、図１０、図１１を参照しながら、図１、図２に示す本発明実施形態の動作について詳細に説明する。
まず、認識前処理部７１は、ログＤＢ８２から音声ストリームパケットを抽出してそのヘッダ情報を参照し（Ｓ１０１）、当該ヘッダ情報に含まれるタイムスタンプＴから所定時間（ｔ）以上間隔のある個所を、上記した特徴点を示す仕切りとして判定し（Ｓ１０２）、音声認識部７２に対して音声認識の単位として供給する。具体的には、図１１（ａ）に示されるように、抽出された音声ストリームパケットを無音区間（α：ｔ＜ｔ３ｓ−ｔ２ｅ）で仕切り（Ｓ１０３）、当該無音区間の間に含まれる無音区間（β、但しα＞β）に無音データを挿入する（Ｓ１０４）。そしてその単位毎にヘッダ（開始時刻、有音時間、無音時間）を付加して音声認識部７２を起動する。

音声認識部７２は、上記した無音区間（β）を単位に音声ストリームパケットの音声認識を行い、テキストデータに変換して認識音声・テキスト管理部７３へ供給する（Ｓ１０５）。認識音声・テキスト管理部７３は、その認識テキストと音声との紐付け作業を行い、音声・テキストＤＢ８３に保存する（Ｓ１０６）。すなわち、図１１（ｂ）に示されるように、音声認識部７２でヘッダと音声から成る認識前音声の音声認識を行い、認識音声・テキスト管理部７３で、ヘッダと認識テキストから成る認識後テキストと、無音区間が付加された認識後音声とを関連付ける。
そして、検索要求・再生応答部７３が、外部からテキストをキーに音声検索要求を受信したとき、音声・テキストＤＢ８３を検索し、図８に示されるように、通話セッション毎に作成されたインデックスデータが示す音声ストリームパケットの格納場所から該当する音声ストリームパケットを検索して再生する。

以上説明のように本発明は、抽出した音声ストリームパケットを無音区間（α）で仕切り、当該無音区間の間に含まれる無音区間（β）に無音データを挿入することで、その無音区間（α）を単位に音声ストリームパケットの音声認識を行ってテキストデータに変換し、認識音声・テキスト管理部を介してそのテキストデータを変換前の音声ストリームパケットと関連付けて保存することで両者の関連付けが可能となり、また、抽出された音声ストリームパケットのヘッダ情報を参照し、当該ヘッダ情報に含まれるタイムスタンプから所定時間以上間隔のある個所を仕切りとして判定し、音声認識の単位として供給することで、音声認識時に誤った語意に変換されることを防ぐものである。
更に、音声検索要求を受信して通話セッション毎に作成されたインデックスデータが示す音声ストリームパケットの格納場所から該当する音声ストリームパケットを検索して再生することにより、検索処理の高速化を実現できる。このとき、容量の大きな音声メディアを外部に保存することで内部ストレージの圧迫も回避できるものである。

なお、上記した本発明実施形態では、ＶｏＩＰパケットのロギング処理と、認識処理をそれぞれロギングサーバ６、音声認識サーバ９が機能分散して協働して実現する構成についてのみ説明したが、性能さえ許せばＤＢ８を管理する単一のサーバ（図示せず）で実現しても良い。
また、図２に示す、ログ保存部（ＶｏＩＰ）６１、パケット抽出部（シグナリング）６２、パケット抽出部（音声ストリーム）６３、セッション識別部６４、ログ保存部６５、パケット補間部（シグナリング／音声ストリーム）６６、認識前処理部７１、音声認識部７２、認識音声・テキスト管理部７３、検索要求・再生応答部７４のそれぞれで実行される手順をコンピュータ読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって本発明の音声認識システムを実現することができる。ここでいうコンピュータシステムとは、ＯＳ（Operating System）や周辺機器等のハードウェアを含む。

また、「コンピュータシステム」は、ＷＷＷ（World Wide Web）システムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

以上、この発明の実施形態につき、図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

本発明実施形態の構成例を示す図である。 図１に示すロギングサーバの内部構成を示すプロック図である。 本発明実施形態の基本動作を示すフローチャートである。 本発明実施形態によるログ保存処理の流れを示すフローチャートである。 本発明実施形態による保存データの判別処理の流れを示すフローチャートである。 本発明実施形態によるログ保存処理の動作概念図である。 本発明実施形態によりログＤＢに保存されるデータの構造の一例を示す図である。 本発明実施形態により音声・テキストＤＢに保存されるデータの構造の一例を示す図である。 音声と認識テキストとの関連付けを説明するために引用した図である。 本発明実施形態による音声認識処理の流れを示すフローチャートである。 本発明実施形態による音声認識処理の動作概念図である。 ＶｏＩＰの概要を説明するために引用した図である。

符号の説明

１、２…ＩＰ電話、３…ＩＰ／ＰＳＴＮ網、４…ＧＷ／ルータ、５…スイッチングハブ、６…ロギングサーバ、７…音声認識サーバ、８…データベース（ＤＢ）、９…検索用ＰＣ、７１…認識前処理部、７２…音声認識部、７３…認識音声・テキスト管理部、７４…検索要求・再生応答部、８２…ログＤＢ、８３…音声・テキストＤＢ

Claims (2)

1. ＩＰ接続環境を用いて音声通話を行うＩＰ電話とはスイッチングハブを経由して接続され、通話セッション毎に分割して保存された音声ストリームパケットを第１の記憶装置から抽出して音声認識を行う音声認識システムであって、
   前記抽出された音声ストリームパケットのヘッダ情報を参照し、当該ヘッダ情報に含まれるタイムスタンプから所定時間以上間隔のある個所を無音区間（時間α）として仕切り、当該無音区間の間に含まれる無音区間（β、但しα＞β）に無音データを挿入する音声認識前処理部と、
   当該無音区間（α）を単位に前記音声ストリームパケットの音声認識を行い、テキストデータに変換する音声認識部と、
   前記変換されたテキストデータを前記変換前の音声ストリームパケットと関連付けて第２の記憶装置に保存する認識音声・テキスト管理部と、
   を備えたことを特徴とする音声認識システム。
2. ＩＰ接続環境を用いて音声通話を行うＩＰ電話とはスイッチングハブを経由して接続され、通話セッション毎に分割して保存された音声ストリームパケットを第１の記憶装置から抽出して音声認識を行う音声認識システムに用いられるプログラムであって、
   前記抽出された音声ストリームパケットのヘッダ情報を参照し、当該ヘッダ情報に含まれるタイムスタンプから所定時間以上間隔のある個所を無音区間（時間α）で仕切り、当該無音区間の間に含まれる無音区間（β、但しα＞β）に無音データを挿入する処理と、
   当該無音区間（α）を単位に前記音声ストリームパケットの音声認識を行い、テキストデータに変換する処理と、
   前記変換されたテキストデータを前記変換前の音声ストリームパケットと関連付けて第２の記憶装置に保存する処理と、をコンピュータに実行させるプログラム。

Images