(57)【要約】【課題】特別な機器を用意することなく、サービスの切り替えや、追加、Ｗｅｂサービスなどの外部サービスとの連携等を容易に実現する。【解決手段】音声情報処理サーバ４とメディアサーバ５とは、電話用端末３−Ａと電話用端末３−Ｂとの音声通信を中継し、音声通信に含まれるキーワードを抽出する。ＡＳＰサーバ２のイベント管理機能部２−２は、抽出したキーワードに基づいた情報を特定する。ＡＳＰサーバ２のイベント送受信機能部２−１は、表示用端末１−Ａと表示用端末１−Ｂとに、イベント管理機能部２−２が特定した情報を送信し、送信した情報に基づいた画像を表示させる。【選択図】図１
2010211172.tif 000002
【特許請求の範囲】
【請求項１】
第１の電話用端末と第２の電話用端末との音声通信を中継し、当該音声通信に含まれるキーワードを抽出する音声情報処理サーバと、
前記音声情報処理サーバが抽出した前記キーワードに基づいた情報を特定するイベント管理機能部と、前記第１の電話用端末に対応する第１の表示端末と前記第２の電話用端末に対応する第２の表示端末とに、前記イベント管理機能部が特定した前記情報を送信し、当該情報に基づいた画像を表示させるイベント送受信機能部とを備えた情報提供サーバと、
を備えたことを特徴とする音声認識コミュニケーション支援システム。
【請求項２】
前記イベント送受信機能部は、前記イベント管理機能部が特定した前記情報を前記音声情報処理サーバに送信し、
前記音声情報処理サーバは、前記イベント送受信部から送信された前記情報に基づいた音声を前記第１の電話用端末と前記第２の電話用端末とに再生させる
ことを特徴とする請求項１に記載の音声認識コミュニケーション支援システム。
【請求項３】
前記イベント送受信機能部は、インターネットを介して情報を提供しているサーバから前記イベント管理機能部が特定した前記情報を取得する
ことを特徴とする請求項１または請求項２のいずれか１項に記載の音声認識コミュニケーション支援システム。
【請求項４】
前記音声情報処理サーバは、前記イベント送受信部から送信された前記情報に基づいて合成音声を生成し、当該合成音声を前記第１の電話用端末と前記第２の電話用端末とに再生させる
ことを特徴とする請求項１から請求項３のいずれか１項に記載の音声認識コミュニケーション支援システム。
【請求項５】
音声情報処理サーバが、第１の電話用端末と第２の電話用端末との音声通信を中継し、当該音声通信に含まれるキーワードを抽出する音声情報処理ステップと、
前記音声情報処理ステップで抽出した前記キーワードに基づいた情報をイベント管理機能部が特定するイベント管理機能ステップと、イベント送受信機能部が、前記第１の電話用端末に対応する第１の表示端末と前記第２の電話用端末に対応する第２の表示端末とに、前記イベント管理機能ステップで特定した前記情報を送信し、当該情報に基づいた画像を表示させるイベント送受信機能ステップと、
を含んだことを特徴とする音声認識コミュニケーション支援方法。
【請求項６】
前記第１の電話用端末と前記第２の電話用端末との間の発着信に係る呼制御を行い、前記第１の電話用端末と前記第２の電話用端末と前記音声情報処理サーバとの間で三者間通話を確立する呼制御サーバを更に備える、
ことを特徴とする請求項１から４のいずれかに記載の音声認識コミュニケーション支援システム。
【請求項７】
前記第１の電話用端末と前記第２の電話用端末との間で送受信されるメッセージをミラーリングし、前記第１の電話用端末と前記第２の電話用端末とのセッション確立状況を把握し、該セッション確立状況を前記音声情報処理サーバに通知するパケットキャプチャ手段を更に備える、
ことを特徴とする請求項６に記載の音声認識コミュニケーション支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通話時における会話を、ネットワークを介した音声認識装置を利用して、認識したキーワードに見合ったキャラクタ画像・音声等を全ユーザに送ることにより、通話時におけるコミュニケーションを支援する音声認識コミュニケーション支援システム、及び音声認識コミュニケーション支援方法に関する。
【背景技術】
【０００２】
従来、通話中の会話を音声認識で判別し、認識に応じたサービスを展開するシステムが知られている。例えば、通話中に一定間隔で音声認識を行い、キャラクタに音声認識に見合ったアクションを取らせ、端末の画面に表示させる技術がある（例えば、非特許文献１参照）。また、ユーザと音声対話を行う対話システムにおいて、特定の目的に応じた応答内容の生成を容易に変更可能にする技術も知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−３０１１３８号公報
【非特許文献】
【０００４】
【非特許文献１】高原祥充、山田充、辻善男、渡辺富夫、“引き込み原理を利用した携帯電話通話システムの開発”、［ｏｎｌｉｎｅ］、［平成２１年２月３日検索］、インターネット＜http://www.pref.okayama.jp/sangyo/kougi/publishment/report/pdf/2002/H15-7-29-106-108.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した従来技術では、キャラクタに音声認識に見合ったアクションを取らせるために、携帯電話に外付け装置を取り付けて、その外付け装置内で音声認識処理を行うものであった。このため、そのサービスを利用するには、ユーザは、外付け装置を準備（購入）しなければならないという問題があった。
【０００６】
また、応答内容の変更を容易にする従来技術では、キーワードのデータベースを用いることで、応答内容の変更を可能にしていたが、音声による応答しかできず、Ｗｅｂサービスなどの他のサービスとの連携も容易でなく、ユーザの希望、目的等に応じて、その都度、Ｗｅｂサービス毎に個別に実装する必要があり、ネットワーク上にある複数の既存のＷｅｂサービスを柔軟に連携させることができないという問題があった。
【０００７】
本発明は、このような事情を考慮してなされたものであり、その目的は、特別な機器を用意することなく、サービスの切り替えや、追加、Ｗｅｂサービスなどの外部サービスとの連携等を容易に実現することができる音声認識コミュニケーション支援システム、及び音声認識コミュニケーション支援方法を提供することにある。
【課題を解決するための手段】
【０００８】
本発明は、第１の電話用端末と第２の電話用端末との音声通信を中継し、当該音声通信に含まれるキーワードを抽出する音声情報処理サーバと、前記音声情報処理サーバが抽出した前記キーワードに基づいた情報を特定するイベント管理機能部と、前記第１の電話用端末に対応する第１の表示端末と前記第２の電話用端末に対応する第２の表示端末とに、前記イベント管理機能部が特定した前記情報を送信し、当該情報に基づいた画像を表示させるイベント送受信機能部とを備えた情報提供サーバと、を備えたことを特徴とする音声認識コミュニケーション支援システムである。
【０００９】
また、本発明の音声認識コミュニケーション支援システムにおいて、前記イベント送受信機能部は、前記イベント管理機能部が特定した前記情報を前記音声情報処理サーバに送信し、前記音声情報処理サーバは、前記イベント送受信部から送信された前記情報に基づいた音声を前記第１の電話用端末と前記第２の電話用端末とに再生させることを特徴とする。
【００１０】
また、本発明の音声認識コミュニケーション支援システムにおいて、前記イベント送受信機能部は、インターネットを介して情報を提供しているサーバから前記イベント管理機能部が特定した前記情報を取得することを特徴とする。
【００１１】
また、本発明の音声認識コミュニケーション支援システムにおいて、前記音声情報処理サーバは、前記イベント送受信部から送信された前記情報に基づいて合成音声を生成し、当該合成音声を前記第１の電話用端末と前記第２の電話用端末とに再生させることを特徴とする。
【００１２】
また、本発明は、音声情報処理サーバが、第１の電話用端末と第２の電話用端末との音声通信を中継し、当該音声通信に含まれるキーワードを抽出する音声情報処理ステップと、前記音声情報処理ステップで抽出した前記キーワードに基づいた情報をイベント管理機能部が特定するイベント管理機能ステップと、イベント送受信機能部が、前記第１の電話用端末に対応する第１の表示端末と前記第２の電話用端末に対応する第２の表示端末とに、前記イベント管理機能ステップで特定した前記情報を送信し、当該情報に基づいた画像を表示させるイベント送受信機能ステップと、を含んだことを特徴とする音声認識コミュニケーション支援方法である。
【００１３】
また、本発明の音声認識コミュニケーション支援システムにおいて、前記第１の電話用端末と前記第２の電話用端末との間の発着信に係る呼制御を行い、前記第１の電話用端末と前記第２の電話用端末と前記音声情報処理サーバとの間で三者間通話を確立する呼制御サーバを更に備える、ことを特徴とする。
【００１４】
また、本発明の音声認識コミュニケーション支援システムにおいて、前記第１の電話用端末と前記第２の電話用端末との間で送受信されるメッセージをミラーリングし、前記第１の電話用端末と前記第２の電話用端末とのセッション確立状況を把握し、該セッション確立状況を前記音声情報処理サーバに通知するパケットキャプチャ手段を更に備える、ことを特徴とする。
【発明の効果】
【００１５】
この発明によれば、特別な機器を用意することなく、サービスの切り替えや、追加、Ｗｅｂサービスなどの外部サービスとの連携等を容易に実現することができるという利点が得られる。
【図面の簡単な説明】
【００１６】
【図１】本発明の第１実施形態による音声認識コミュニケーション支援システムの構成を説明するためのブロック図である。
【図２】本第１実施形態による音声認識コミュニケーション支援システムによるサービスの提供手順の概要を説明するためのブロック図である。
【図３】本第１実施形態による音声認識コミュニケーション支援システムによるサービスの提供に伴う通信手順の概要を説明するためのブロック図である。
【図４】本第１実施形態による、ＡＳＰサーバ２から提供される、ユーザＡ、Ｂの表示用端末１−Ａ、１−Ｂのブラウザでの表示例を示す模式図である。
【図５】本第１実施形態による、ＡＳＰサーバ２で着信側の本来の電話番号（広義にはアドレス情報）を取得するためのデータベースの内容を示す概念図である。
【図６】本第１実施形態による、セッション確立時に参照されるキャラクタ（動画）画像の動き情報を取得するためのデータベースの内容を示す概念図である。
【図７】本第１実施形態による、音声認識が失敗した場合に参照されるキャラクタ（動画）画像の動き情報を取得するためのデータベースの内容を示す概念図である。
【図８】本第１実施形態による、音声認識が失敗した場合に参照される吹き出し部に表示するテキスト情報を取得するためのデータベースの内容を示す概念図である。
【図９】本第１実施形態による、音声認識が失敗した場合に参照される音声合成により再生される音声情報を取得するためのデータベースの内容を示す概念図である。
【図１０】本第１実施形態による、キーワードが検出された場合（ケース２）に参照されるキャラクタ（動画）画像の動き情報、または吹き出し部に表示するテキスト情報を取得するためのデータベースの内容を示す概念図である。
【図１１】本第１実施形態による、Ｗｅｂ連携の特殊キーワード（口コミ情報）が検出された場合（ケース３−１）に参照されるキャラクタ（動画）画像の動き情報を取得するためのデータベースの内容を示す概念図である。
【図１２】本第１実施形態による、Ｗｅｂ連携の特殊キーワード（天気情報）が検出された場合（ケース３−２）参照されるキャラクタ（動画）画像の動き情報を取得するためのデータベースの内容を示す概念図である。
【図１３】本第１実施形態による、セッション切断時に参照されるキャラクタ（動画）画像の動き情報を取得するためのデータベースの内容を示す概念図である。
【図１４】本第１実施形態による、セッション確立時、セッション切断時に参照されるキャラクタ（動画）画像の動き情報を取得するためのデータベースの内容を示す概念図である。
【図１５】本第１実施形態の動作を説明するためのフローチャートである。
【図１６】本第１実施形態の動作を説明するためのフローチャートである。
【図１７】本第１実施形態の動作を説明するためのフローチャートである。
【図１８】本第１実施形態の動作を説明するためのシーケンス図である。
【図１９】本第１実施形態の動作を説明するためのシーケンス図である。
【図２０】本第１実施形態の動作を説明するためのシーケンス図である。
【図２１】本第１実施形態の動作を説明するためのシーケンス図である。
【図２２】本第１実施形態による、音声認識でキーワードが検出されない場合、すなわちケース１での動作を説明するためのシーケンス図である。
【図２３】本第１実施形態による、音声認識でキーワードが検出された場合、すなわちケース２での動作を説明するためのシーケンス図である。
【図２４】本第１実施形態による、音声認識でキーワードが検出された場合、すなわちケース３−１での動作を説明するためのシーケンス図である。
【図２５】本第１実施形態による、音声認識でキーワードが検出された場合、すなわちケース３−２での動作を説明するためのシーケンス図である。
【図２６】本第１実施形態による第１の変形例の動作を説明するためのシーケンス図である。
【図２７】本第１実施形態による第１の変形例の動作を説明するためのシーケンス図である。
【図２８】本第１実施形態による第１の変形例の動作を説明するためのシーケンス図である。
【図２９】本第１実施形態による第１の変形例の動作を説明するためのシーケンス図である。
【図３０】本第１実施形態による第２の変形例の動作を説明するためのシーケンス図である。
【図３１】本第２実施形態による、音声認識コミュニケーション支援システムの構成を説明するためのブロック図である。
【図３２】本第２実施形態の動作を説明するためのシーケンス図である。
【図３３】本第２実施形態の動作を説明するためのシーケンス図である。
【図３４】本第２実施形態の動作を説明するためのシーケンス図である。
【図３５】本第２実施形態の動作を説明するためのシーケンス図である。
【図３６】本第２実施形態の動作を説明するためのシーケンス図である。
【図３７】本第２実施形態の動作を説明するためのシーケンス図である。
【図３８】本第２実施形態の動作を説明するためのシーケンス図である。
【図３９】本第２実施形態の動作を説明するためのシーケンス図である。
【図４０】本第３実施形態による音声認識コミュニケーション支援システムの構成を説明するためのブロック図である。
【発明を実施するための形態】
【００１７】
以下、本発明の一実施形態を、図面を参照して説明する。
【００１８】
Ａ．第１実施形態
図１は、本発明の第１実施形態による音声認識コミュニケーション支援システムの構成を説明するためのブロック図である。図において、音声認識コミュニケーション支援システムは、ユーザＡ、Ｂが用いる表示用端末１−Ａ、１−Ｂ、ＡＳＰ（Application Service Provider、アプリケーションサービスプロバイダ）サーバ２（情報提供サーバ）、ユーザＡ、Ｂが用いる電話用端末３−Ａ、３−Ｂ、音声情報処理サーバ４、メディアサーバ５から構成される。
【００１９】
表示用端末１−Ａ、１−Ｂは、各々、ユーザＡ、Ｂが用い、Ｗｅｂブラウザソフトウェアが起動可能な情報処理端末：携帯電話、パーソナルコンピュータ、フォトフレーム、テレビなどからなる。また、電話用端末３−Ａ、３−Ｂは、各々、ユーザＡ、Ｂが用いる通信端末であり、携帯電話、ソフトフォンなどからなる。なお、以下では、表示用端末１−Ａ、１−Ｂと電話用端末３−Ａ、３−Ｂとを分けて説明するが、表示用端末１−Ａと電話用端末３−Ａ、及び、表示用端末１−Ｂと電話用端末３−Ｂは、それぞれ、同一のものでも良い。
【００２０】
ＡＳＰサーバ２は、サービスを提供する主体であり、後述する音声情報処理サーバ４からの音声認識結果に応じて、表示用端末１−Ａ、１−Ｂに対するキャラクタ（動画）画像（文字を含む）の提供などを行う。ＡＳＰサーバ２は、イベント送受信機能部２−１、及びイベント管理機能部２−２を備えている。イベント送受信機能部２−１は、表示用端末１−Ａ、１−Ｂのブラウザ、あるいは音声情報処理サーバ４との間で、要求や、情報などを送受信したり、表示用端末１−Ａ、１−Ｂのブラウザに表示するデータを送信したり、音声情報処理サーバ４に電話等の端末に対する音声再生の要求を行ったりする。イベント管理機能部２−２は、イベント送受信機能部２−１が受信した情報を管理し、情報をもとに次のアクションをイベント送受信機能部２−１に実行させる機能を有する。
【００２１】
音声情報処理サーバ４は、電話用端末３−Ａ、３−Ｂ間の発着信や、電話用端末３−Ａ、３−Ｂ間の通話音声のメディアサーバ５への送信、音声認識の結果に基づいたキーワードの検出、キーワード検出結果のＡＳＰサーバ２への通知、音声認識の結果に応じたキャラクタ音声や、合成音声の電話用端末３−Ａ、３−Ｂへの提供などを行う。
【００２２】
メディアサーバ５は、音声情報処理サーバ４からの通話音声を音声認識し、該音声認識の結果を音声情報処理サーバ４に通知する。なお、音声情報処理サーバ４がメディアサーバ５の機能を有していてもよく、音声情報処理サーバ４とメディアサーバ５とを合わせて音声情報処理サーバ４としてもよい。Ｗｅｂサービス６は、ＡＳＰサーバ２からの要求に応じてＷｅｂ情報を提供する。
【００２３】
図２は、本第１実施形態による音声認識コミュニケーション支援システムによるサービスの提供手順の概要を説明するためのブロック図である。図において、音声認識コミュニケーション支援システムは、通話時に音声認識を行い、音声認識に応じたキャラクタ画像（共有キャラクタ）、及びキャラクタ音声をユーザ間で共有する。
【００２４】
そのために、
Ａ１．ユーザＡ、及びユーザＢは、表示用端末１−Ａ、１−Ｂのブラウザ（Ｗｅｂブラウザソフトウェアが起動可能な情報処理端末：携帯電話、パーソナルコンピュータ、フォトフレーム、テレビなど）を起動し、インターネットを介して本サービス（ＡＳＰサーバ２）にアクセスし、本サービスを利用する準備をする（Ｓａ１）。
【００２５】
ブラウザは、Ａｊａｘ（エイジャックス：「Asynchronous（エイシンクロナス、非同期）JavaScript（登録商標） ＋ XML」）でポーリングしてイベント情報の有無をＡＳＰサーバ２から取得する。
【００２６】
なお、ユーザＢ（着信側）がブラウザから本サービスにアクセスするタイミングは、セッション確立の前でも後でも良い。ユーザＢがアクセスしなくても、ユーザＡ（発信側）は、本サービスを利用可能である。また、音声に関しては、ユーザＡが利用していれば、ユーザＢにも再生される。
【００２７】
Ａ２．ユーザＡの電話用端末３−Ａ（携帯電話、ソフトフォンなど）とユーザＢの電話用端末３−Ｂ（携帯電話、ソフトフォンなど）との間でセッションが確立する（Ｓａ２）。
【００２８】
Ａ３．二者のセッションが確立すると、音声情報処理サーバ４がＡＳＰサーバ２に通知する（Ｓａ３）。
【００２９】
ＡＳＰサーバ２にセッションの確立が通知されると、本サービスが開始される。
ユーザＡの電話用端末３−ＡとユーザＢの電話用端末３−Ｂとの間の通話中に、会話内容をメディアサーバ５により音声認識し、音声情報処理サーバ４により予め登録したキーワードがあるか判定し、予め登録したキーワードが発せられると、ＡＳＰサーバ２により、キーワードに合ったキャラクタ（動作）画像（文字を含む）がユーザＡの表示用端末１−Ａのブラウザ、及びユーザＢの表示用端末１−Ｂのブラウザに表示され、音声情報処理サーバ４により、キャラクタ音声がユーザＡの電話用端末３−ＡとユーザＢの電話用端末３−Ｂで再生される。なお、表示端末１−Ａ，１−Ｂに表示されるキャラクタ画像は、文字・記号や動画を含んでいてもよい。
【００３０】
より具体的に説明すると、音声認識に応じ、以下のケース１〜３等のシナリオが自動的に起動される。
【００３１】
Ａ４．ケース１（キーワードが検出されない場合）
ＡＳＰサーバ２は、キーワードが検出されない場合ランダムにキャラクタ（動作）画像（文字を含む）を、ユーザＡの表示用端末１−Ａのブラウザ、及びユーザＢの表示用端末１−Ｂのブラウザに表示する。
【００３２】
また、音声情報処理サーバ４は、ランダムにキャラクタ音声を、ユーザＡの電話用端末３−ＡとユーザＢの電話用端末３−Ｂで再生する。
【００３３】
Ａ５．ケース２（キーワードが検出された場合）
ＡＳＰサーバ２は、キーワードに応じたキャラクタ（動作）画像（文字を含む）に差し替え、ユーザＡの表示用端末１−Ａのブラウザ、及びユーザＢの表示用端末１−Ｂのブラウザに表示する。
【００３４】
Ａ６．ケース３（Ｗｅｂ連携特殊キーワードが検出された場合）
ユーザＡの電話用端末３−Ａ、またはユーザＢの電話用端末３−Ｂで、外部のＷｅｂサービスとの連携するためのキーワード（特殊キーワード）が発せられると、ＡＳＰサーバ２は、以下に示すように、Ｗｅｂサービス６と連携したサービスを提供する。
【００３５】
Ａ６−１．ケース３−１（吹き出し部への表示）
Ｗｅｂサービス６から取得した情報がキャラクタ画像の横の吹き出し部に表示される。
【００３６】
Ａ６−２．ケース３−２（合成音声）
Ｗｅｂサービス６から取得した情報が、合成音声で電話用端末において再生される。
【００３７】
次に、図３は、基本的に図１と同じであるが、本第１実施形態による音声認識コミュニケーション支援システムによるサービスの提供に伴う通信手順の概要を説明するためのブロック図である。ユーザＡ、及びユーザＢは、表示用端末１−Ａ、１−Ｂのブラウザ（Ｗｅｂブラウザソフトウェアが起動可能な情報処理端末：パーソナルコンピュータ）を起動し、インターネットを介して本サービス（ＡＳＰサーバ２）にアクセスし、本サービスを利用する準備をする（Ｓｂ１）。ブラウザは、Ａｊａｘ（エイジャックス：「Asynchronous JavaScript（登録商標） ＋ XML」）でポーリングしてイベント情報の有無をＡＳＰサーバ２から取得する。
【００３８】
なお、ユーザＢ（着信側）がブラウザから本サービスにアクセスするタイミングは、セッション確立の前でも後でも良い。ユーザＢがアクセスしなくても、ユーザＡ（発信側）は、本サービスを利用可能である。また、音声に関しては、ユーザＡが利用していれば、ユーザＢにも再生される。
【００３９】
ユーザＡが電話用端末３−Ａで電話帳からユーザＢのキャラクタ電話用の電話番号を選択して発信する（Ｓｂ２）。音声情報処理サーバ４は、ユーザＢの電話用端末３−Ｂに着信があったことを、ＡＳＰサーバ２に通知する（Ｓｂ３）。ＡＳＰサーバ２は、着信通知があると、ユーザＢの電話用端末３−Ｂの本来の電話番号に発呼することを音声情報処理サーバ４に要求する（Ｓｂ４）。音声情報処理サーバ４は、ユーザＢの電話用端末３−Ｂの本来の番号（電話番号、広義でアドレス情報）で発呼し、ユーザＢの電話用端末３−Ｂに着信する（Ｓｂ５）。
【００４０】
以下、図２と同様に、本サービスが開始される。サービス内容は、前述した通りであるので説明を省略する。
【００４１】
次に、図４は、本第１実施形態による、ＡＳＰサーバ２から提供される、ユーザＡ、Ｂの表示用端末１−Ａ、１−Ｂのブラウザでの表示例を示す模式図である。ユーザＡ、Ｂの表示用端末１−Ａ、１−Ｂのブラウザが、ブラウザによりサービス用ＷｅｂページのＵＲＩにアクセスし、提供される背景画像を取得して表示する。また、ＡｊａｘでＡＳＰサーバ２にポーリングし、通話中の会話内容に応じたキャラクタ（動画）画像や、テキスト情報などを取得し、キャラクタ（動作）画像を差し替え可能に表示するとともに、吹き出し部にテキスト情報（文字情報）を差し替え可能に表示する。
【００４２】
次に、図５は、本第１実施形態による、ＡＳＰサーバ２で着信側の本来の番号（電話番号、広義にはアドレス情報）を取得するためのデータベースの内容を示す概念図である。データベース１０は、電話用端末の本来の番号とサービス用番号とが対応付けて記憶されている。
【００４３】
イベント送受信機能部２−１は、音声情報処理サーバ４から着信通知があると、図５に示すデータベースから電話用端末３−Ｂ（着信側）の本来の番号を取得し、電話用端末３−Ａと電話用端末３−Ｂとのセッションを確立するために、取得した電話用端末３−Ｂの本来の電話番号を引数にして、音声情報処理サーバ４に対して「ａｄｄＣａｌｌＰａｒｔｉｃｉｐａｎｔメッセージ」を送信する。「ａｄｄＣａｌｌＰａｒｔｉｃｉｐａｎｔメッセージ」を受信した音声情報処理サーバ４は、本来の電話番号で端末Ｂに対して発呼し、呼び出すことで、当該音声認識コミュニケーション支援システムによるサービス提供が開始される。
【００４４】
次に、図６は、本第１実施形態による、セッション確立時に参照されるキャラクタ（動画）画像の動き情報を取得するためのデータベースの内容を示す概念図である。図において、セッション確立時に実施される、キャラクタ（動画）画象に施す動き情報（登場）が記憶されている。セッション確立時の動き情報としては、「登場」が設定されている。登場時のキャラクタ（動画）画象の動きとしては、例えば、図１４（ａ）に示すような動きが考えられる。
【００４５】
ＡＳＰサーバ２は、二者のセッションが確立されたことが、音声情報処理サーバ４から通知されると、図６に示すデータを参照し、キャラクタ（動画）画象の動き情報（登場）を取得し、該取得した動き情報（登場）に従ってキャラクタ(動画)画象をユーザＡの表示用端末１−Ａのブラウザ、及びユーザＢの表示用端末１−Ｂのブラウザに提供する。
【００４６】
次に、図７は、本第１実施形態による、音声認識が失敗した場合に参照されるキャラクタ（動画）画像の動き情報を取得するためのデータベースの内容を示す概念図である。図において、音声認識が失敗した場合に実施される、キャラクタ（動画）画象に施す動き情報が記憶されている。音声認識が失敗した場合の動き情報としては、「頷く」、「首を振る（または、手をポンと打つ）」、「寝る」、「踊る」、「あくび」、「内緒」などが設定されている。
【００４７】
ＡＳＰサーバ２は、音声認識が失敗した場合、あるいは通話音声にキーワードが検出されない場合、図７に示すデータを参照し、キャラクタ（動画）画象の動き情報（登場）をランダムに取得し、取得したキャラクタ（動作）画像（文字を含む）を、ユーザＡの表示用端末１−Ａのブラウザ、及びユーザＢの表示用端末１−Ｂのブラウザに表示する。
【００４８】
図８は、本第１実施形態による、音声認識が失敗した場合に参照される吹き出し部に表示するテキスト情報を取得するためのデータベースの内容を示す概念図である。図において、音声認識が失敗した場合に実施される、吹き出し部に表示するテキスト情報が記憶されている。音声認識が失敗した場合に吹き出し部に表示するテキスト情報としては、「うん、うん。」、「なるほど〜。」、「遊ぼ♪」、「ん〜♪」、「そっかぁ」、「そういえば…、あの話はどうなったの？」などが設定されている。
【００４９】
ＡＳＰサーバ２は、音声認識が失敗した場合、あるいは通話音声にキーワードが検出されない場合、図８に示すデータを参照し、吹き出し部に表示するテキスト情報をランダムに取得し、取得したテキスト情報を、ユーザＡの表示用端末１−Ａのブラウザ、及びユーザＢの表示用端末１−Ｂのブラウザで表示されているキャラクタ（動画）画象の横の吹き出し部に表示する。
【００５０】
次に、図９は、本第１実施形態による、音声認識が失敗した場合に参照される音声合成により再生される音声情報を取得するためのデータベースの内容を示す概念図である。図において、音声認識が失敗した場合に実施される、電話用端末３−Ａ、３−Ｂで再生する音声データが記憶されている。音声認識が失敗した場合に、音声合成により再生される音声情報としては、「ふーん、そうなんだ〜」、「どうしたの？」、「なるほど〜。」などが設定されている。
【００５１】
ＡＳＰサーバ２は、音声認識が失敗した場合、あるいは通話音声にキーワードが検出されない場合、図９に示す音声データを参照し、いずれかの音声情報をランダムに取得し、音声情報処理サーバ４に送信する。音声情報処理サーバ４では、受信した音声データを話用端末３−Ａ、３−Ｂに送信して再生させる。
【００５２】
次に、図１０は、本第１実施形態による、キーワードが検出された場合（ケース２）に参照されるキャラクタ（動画）画像の動き情報、または吹き出し部に表示するテキスト情報を取得するためのデータベースの内容を示す概念図である。図において、キーワードが検出された場合（ケース２）に実施される、キャラクタ（動画）画象に施す動き情報と対応するキーワードとが記憶されている。キーワードとして、「ありがとう、サンキュー、好き、一緒、会う、会いたい、嬉しい、嬉しかった、楽しい、楽しかった、楽しみ、可愛い、カッコいい、カッケー、美味しい、美味しかった、美味い、おめでとう、良かった」のいずれかが検出された場合には、「手に持っているハートを前に出す（または、手に持っているハートを抱きしめる）」というような動作を行うように設定されている。
【００５３】
同様に、キーワードとして、「ごめん、すまん、申し訳、わりー、残念、大変、風邪、疲れた、疲れちゃった、できない、腹痛、怪我、病気、病院、だるい、だりー、悲しい、寒い、さみー、暑い、あちー、痛い、いてー、辛い、やだ、嫌」のいずれかが検出された場合には、「半べそ」というような動作を行うように設定されている。
【００５４】
また、キーワードとして、キャラクタの名前が検出された場合には、「飛び跳ねる」というような動作を行うとともに、吹き出し部に「なに？なに〜？」と表示するように設定されている。
【００５５】
また、キーワードとして、「バイバイ、ばいばーい、さようなら、さよなら、またね、失礼します、じゃあね、もしもし、おはよう、こんにちは、こんばんは、元気」のいずれかが検出された場合には、「手を振る」というような動作を行うように設定されている。
【００５６】
また、キーワードとして、「食事、ご飯、食べ物、ケーキ、パン、お菓子、お腹すいた、腹減った、おかず、晩御飯、晩飯、ランチ、昼食、お昼、朝食、夕食、デザート、めし、レストラン」が検出された場合には、「フォークとナイフを持つ」というような動作を行うとともに、吹き出し部に「お腹すいたぁ」と表示するように設定されている。
【００５７】
また、キーワードとして、「おめでとう、頑張って、頑張ろう、頑張れ、頑張った、やったー、合格、良かった、バンザイ」のいずれかが検出された場合には、「ガッツポーズ（または、バンザイ」というような動作を行うように設定されている。
【００５８】
次に、図１１は、本第１実施形態による、Ｗｅｂ連携の特殊キーワード（口コミ情報）が検出された場合（ケース３−１）に参照されるキャラクタ（動画）画像の動き情報を取得するためのデータベースの内容を示す概念図である。図において、Ｗｅｂ連携の特殊キーワードが検出された場合（ケース３−１）に実施される、キャラクタ（動画）画象に施す動き情報と対応する特殊キーワードとが記憶されている。キーワードとして、「レストラン、ランチ、ディナー」のいずれかが検出された場合には、「口パク」というような動作を行うように設定されている。
【００５９】
次に、図１２は、本第１実施形態による、Ｗｅｂ連携の特殊キーワード（天気情報）が検出された場合（ケース３−２）参照されるキャラクタ（動画）画像の動き情報を取得するためのデータベースの内容を示す概念図である。図において、Ｗｅｂ連携の特殊キーワードが検出された場合（ケース３−２）に実施される、キャラクタ（動画）画象に施す動き情報と対応する特殊キーワードとが記憶されている。キーワードとして、「明日の天気、今日の天気、明後日の天気、天気、明日、明後日」のいずれかが検出された場合には、「ポケットからラジオを取り出す」というような動作を行うように設定されている。
【００６０】
次に、図１３は、本第１実施形態による、セッション切断時に参照されるキャラクタ（動画）画像の動き情報を取得するためのデータベースの内容を示す概念図である。図において、セッション切断時に実施される、キャラクタ（動画）画象に施す動き情報（登場）が記憶されている。セッション切断時の動き情報としては、「手を振る」が設定されている。キャラクタ（動画）画象の動きとしては、例えば、図１４（ｂ）に示すような動きが考えられる。
【００６１】
ＡＳＰサーバ２は、二者のセッションが切断されたことが、音声情報処理サーバ４から通知されると、図１３に示すデータを参照し、キャラクタ（動画）画象の動き情報（手を振る）を取得し、該取得した動き情報（登場）に従ってキャラクタ(動画)画象をユーザＡの表示用端末１−Ａのブラウザ、及びユーザＢの表示用端末１−Ｂのブラウザに提供する。
【００６２】
次に、本第１実施形態の動作について説明する。
図１５乃至図１７は、本第１実施形態の動作の概要を説明するためのフローチャートである。表示用端末１−Ａ（ブラウザＡ）のユーザＡが、ブラウザＡから本サービスのページにアクセスしたことがＡＳＰサーバ２に通知されると、まず、ＡＳＰサーバ２は、音声情報処理サーバ４に対してｓｔａｒｔＣａｌｌＮｏｒｔｉｆｉｃａｔｉｏｎメッセージを送信する（ステップＳ１）。これにより、ＡＳＰサーバ２と音声情報処理サーバ４とが連携可能となる。次に、ＡＳＰサーバ２は、音声情報処理サーバ４にａｄｄＣａｌｌＰａｒｔｉｃｉｐａｎｔメッセージを送信し（ステップＳ２）、電話用端末３−Ａと電話用端末３−Ｂとの間でセッションが確立したか否かを確認するために、ｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｍａｔｉｏｎメッセージを音声情報処理サーバ４に送信する（ステップＳ３）。
【００６３】
次に、ＡＳＰサーバ２は、音声情報処理サーバ４から返されるセッション状況を元にセッションが確立したか否かを判定し（ステップＳ４）、電話用端末３−Ａと電話用端末３−Ｂとのセッションが確立したことが判定されると、表示用端末１−Ａ、１−Ｂにキャラクタを表示する（ステップＳ５）。次に、ＡＳＰサーバ２は、音声情報処理サーバ４にｓｔａｒｔＰｌａｙＡｎｄＲｅｃｏｇｉｎｉｚｅＮｏｔｉｆｉｃａｔｉｏｎメッセージを送信し、音声認識の開始を通知する（ステップＳ６）。
【００６４】
次に、ＡＳＰサーバ２は、音声情報処理サーバ４にＳｔａｒｔＰｌａｙＡｎｄＲｅｃｏｇｉｎｉｚｅＩｎｔｅｒａｃｔｉｏｎメッセージを送信し、音声情報処理サーバ４は、電話用端末３−Ａと電話用端末３−Ｂとの会話の音声認識を開始する（ステップＳ７）。ＡＳＰサーバ２は、音声情報処理サーバ２からの音声認識結果に基づいて、電話用端末３−Ａと電話用端末３−Ｂとの会話に、予め設定したキーワードに一致する語彙が検出されるか否かを判定する（ステップＳ８）。
【００６５】
そして、音声認識に失敗すると（キーワードが検出されない場合、あるいは無音である場合）、ｇｅｔＭｅｓｓａｇｅＳｔａｔｕｓメッセージに従って、現在、音声が再生されているか否かを判定する（ステップＳ９）。そして、現在、音声が再生されていない場合には、キャラクタ音声を再生させるために、音声情報処理サーバ４に再生を要求するｐｌａｙＡｕｄｉｏＭｅｓｓａｇｅメッセージを送り、音声情報処理サーバ４は、要求されたキャラクタ音声を、電話用端末３−Ａ、及び電話用端末３−Ｂで再生させる（ステップＳ１０）。また、音声認識に失敗すると（キーワードが検出されない場合、あるいは無音である場合）、ＡＳＰサーバ２は、表示用端末１−Ａ、１−Ｂにキャラクタを（頷く、首を振るなどをランダムに）表示する（ステップＳ１１）。以降、上記ステップＳ９、Ｓ１０による音声再生処理と、ステップＳ１１によるキャラクタの表示とをランダムに実行する。
【００６６】
その後、一定間隔、あるいはキーワードを再び検出した場合には、ステップＳ７に戻り、上述した処理を繰り返す、あるいは、表示用端末１−Ａ、１−Ｂのブラウザによるポーリングを行う場合には、ステップＳ４に戻り、上述した処理を繰り返す。
【００６７】
一方、ステップＳ８で、音声認識が成功すると（キーワードが検出された場合）、そのキーワードに応じて、キャラクタを（喜ぶ、悲しむなど）表示する（ステップＳ１２）。すなわち、この場合、キャラクタがキーワードに応じて動くように表示されることになる。その後、一定間隔、あるいはキーワードを再び検出した場合には、ステップＳ７に戻り、上述した処理を繰り返す、あるいは、表示用端末１−Ａ、１−Ｂのブラウザによるポーリングを行う場合には、ステップＳ４に戻り、上述した処理を繰り返す。
【００６８】
また、ステップＳ８で、音声認識が成功すると（特殊キーワード＝Ｗｅｂ連携キーワードが検出された場合）、ＡＳＰサーバ２は、特殊キーワードに応じてＷｅｂサーバ６からテキスト情報を取得し、該取得したテキスト情報を、表示用端末１−Ａ、１−Ｂのブラウザに表示されているキャラクタの横の吹き出し部に表示する（ステップＳ１３）。
【００６９】
あるいは、ＡＳＰサーバ２は、ｇｅｔＭｅｓｓａｇｅＳｔａｔｕｓメッセージに従って、現在、音声が再生されているか否かを判定する（ステップＳ１４）。そして、現在、音声が再生されていない場合には、合成音声を再生させるために、音声情報処理サーバ４に合成音声の再生を要求するｐｌａｙＴｅｘｔＭｅｓｓａｇｅメッセージを送り、音声情報処理サーバ４は、テキスト情報から要求された合成音声を生成し、電話用端末３−Ａ、及び電話用端末３−Ｂで再生させる（ステップＳ１５）。
【００７０】
いずれの場合も、その後、一定間隔、あるいはキーワードを再び検出した場合には、ステップＳ７に戻り、上述した処理を繰り返す、あるいは、表示用端末１−Ａ、１−Ｂのブラウザによるポーリングを行う場合には、ステップＳ４に戻り、上述した処理を繰り返す。
【００７１】
次に、上述した本第１実施形態の動作を、より詳細に説明する。
図１８乃至図２１は、本第１実施形態の動作を説明するためのシーケンス図である。まず、表示用端末１−Ａ（ブラウザＡ）のユーザＡが、ブラウザＡから本サービスのページにアクセスすると、ブラウザＡは、本サービスを提供するＡＳＰサーバ２のイベント送受信機能部２−１にＨＴＴＰ  ＧＥＴメソッドでＨＴＴＰリクエストメッセージを送る（ＳＡ１）。イベント送受信機能部２−１は、ＨＴＴＰレスポンスをし、ブラウザＡにサービスのスタート画面を表示させる（ＳＡ２）。
【００７２】
イベント送受信機能部２−１は、上記ＨＴＴＰＧＥＴメソッドのメッセージを受け、音声情報処理サーバ４と連携するために、音声情報処理サーバ４にｓｔａｒｔＣａｌｌＮｏｒｔｉｆｉｃａｔｉｏｎメッセージを送る（ＳＡ３）。
【００７３】
一方、ユーザＢの表示用端末１−Ｂ（ブラウザＢ）も表示用端末１−Ａ（ブラウザＡ）と同様に、サービスのスタート画像を表示させるために、サービス元であるＡＳＰサーバ２のイベント送受信機能部２−１にＨＴＴＰ  ＧＥＴメッセージを送る（ＳＡ４）。イベント送受信機能部２−１は、ブラウザＢにサービスブラウザ画面を表示させる（ＳＡ５）。
【００７４】
ブラウザＡは、Ａｊａｘによってポーリングし、ＡＳＰサーバ２のイベント送受信機能部２−１にイベントの有無の情報を要求する（ＳＡ６）。イベント送受信機能部２−１は、イベント管理機能部２−２にイベントの更新状況の情報を要求する（ＳＡ７）。イベント管理機能部２−２は、イベント送受信機能部に更新状況の結果（ここでは「更新なし」）をイベント送受信機能部２−１に返す（ＳＡ８）。イベント送受信機能部２−１は、ブラウザＡにイベント情報の有無のレスポンスを返す（ＳＡ９）。
【００７５】
ユーザＢの表示用端末１−Ｂ（ブラウザＢ）も表示用端末１−Ａ（ブラウザＡ）と同様に、Ａｊａｘによってポーリングし、ＡＳＰサーバのイベント送受信機能部２−１からイベントの有無の情報の取得を試みる（ＳＡ１０）。イベント送受信機能部２−１は、イベント管理機能部２−２からイベントの更新状況の情報を取得する（ＳＡ１１）。イベント管理機能部２−２は、イベント送受信機能部２−１に更新状況の結果（ここでは「更新なし」）を返す（ＳＡ１２）。イベント送受信機能部２−１は、ブラウザＡにイベント情報の有無のレスポンスを返す（ＳＡ１３）。
【００７６】
電話用端末３−ＡのユーザＡが電話用端末３−ＢのユーザＢと通話するために、音声情報処理サーバ４に向けて発呼する（ＳＡ１４）。音声情報処理サーバ４は、電話用端末３−Ａからの発呼を受け、誰から着信があったかイベント送受信機能部２−１に通知するために、イベント送受信機能部２−１にｎｏｔｉｆｙＣａｌｌｅｄＮｕｍｂｅｒメッセージを送る（ＳＡ１５）。イベント送受信機能部２−１は、データベース１０（図５参照）から電話用端末３−Ｂの本来の番号を取得し、電話用端末３−Ａと電話用端末３−Ｂのセッションを確立するために、電話用端末３−Ｂの本来の番号を引数に音声情報処理サーバ４にａｄｄＣａｌｌＰａｒｔｉｃｉｐａｎｔメッセージを送る（ＳＡ１６）。音声情報処理サーバ４は、電話用端末３−Ｂの本来の番号に発呼する（ＳＡ１７）。電話用端末３−Ｂが電話に出ると、電話用端末３−Ａと電話用端末３−Ｂとの間でセッションが確立する（ＳＡ１８）。
【００７７】
次に、イベント送受信機能部２−１は、電話用端末３−Ａと電話用端末３−Ｂとの間でセッションが確立したか否かを確認するために、電話用端末３−Ａと電話用端末３−ＢのＣａｌｌＳｅｓｓｉｏｎＩＤを引数としたｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｍａｔｉｏｎメッセージを音声情報処理サーバ４に送る（ＳＡ１９）。音声情報処理サーバ４は、セッション情報をイベント送受信機能部２−１に返す（ＳＡ２０）。以下、切断時までポーリングを続ける。
【００７８】
イベント送受信機能部２−１は、上記ＳＡ１９、ＳＡ２０により、電話用端末３−Ａと電話用端末３−Ｂとの間でセッションが確立したことを確認すると、キャラクタが登場する画像（ｃｏｍｅ−ｏｎ．ｇｉｆ（図１４（ａ））など）を表示用端末１−Ｂ（ブラウザＢ）と表示用端末１−Ａ（ブラウザＡ）に表示させる（ＳＡ２１）。
【００７９】
イベント送受信機能部２−１は、音声認識の開始を通知するために、音声情報処理サーバ４に監視対象コールセッションＩＤを引数としたｓｔａｒｔＰｌａｙＡｎｄＲｅｃｏｇｉｎｉｚｅＮｏｔｉｆｉｃａｔｉｏｎメッセージを送る（ＳＡ２２）。イベント送受信機能部２−１は、音声認識を開始するために、音声情報処理サーバ４に監視対象コールセッションＩＤを引数としたＳｔａｒｔＰｌａｙＡｎｄＲｅｃｏｇｉｎｉｚｅＩｎｔｅｒａｃｔｉｏｎメッセージを送る（ＳＡ２３）。
【００８０】
次に、電話用端末３−Ａ（あるいは、電話用端末３−Ｂ）で音声の会話がなされると（ＳＡ２４）、音声情報処理サーバ４は、メディアサーバ５にその音声を送る（ＳＡ２５）。メディアサーバ５は、音声認識を行い、音声情報処理サーバ４にレスポンスを返し（ＳＡ２６）、音情報処理サーバ４は、音声認識で検出された言葉をｎｏｔｉｆｙＰｌａｙＡｎｄＲｅｃｏｇｎｉｚｅＥｖｅｎｔメッセージでイベント送受信機能部２−１に送る（ＳＡ２７）。イベント送受信機能部２−１は、イベント管理機能部２−２に音声情報処理サーバ４で検出された言葉を通知し（ＳＡ２８）、イベント管理機能部２−２は、検出された言葉がデータベース１０〜１７（図６〜図１３参照）の中のキーワードと一致するか否かを判定する（ＳＡ２９）。
【００８１】
イベント管理機能部２−２は、キーワード検出判定した結果から、データベース１０〜１７（図６〜図１３参照）からキーワードに合ったキャラクタ（動画）画象の動き情報や、テキスト情報（キーワードが検出されない場合には、図７〜図９のデータベース１２〜１４）を選択する。前述したＳＡ６〜ＳＡ９で説明したように、ブラウザＡは、イベント送受信機能部２−１にイベントの有無の情報を取得するポーリングをしており、そのポーリングの度に、イベント送受信機能部２−１は、イベント管理機能部２−２にイベント更新状況の情報を取得している。
【００８２】
このため、イベント管理機能部２−２が、ｎｏｔｉｆｙＰｌａｙＡｎｄＲｅｃｏｇｎｉｚｅＥｖｅｎｔを受け取り、キーワードの検出判定し、さらにキーワードに合ったキャラクタ（動画）画象の動き情報や、テキスト情報を検出しておくことで、イベント管理機能部２−２のイベント送受信機能部２−１に対するレスポンスにより、画像が更新され、ブラウザＡの画像が差し替えられる（ＳＡ３０）。また、ブラウザＢにおいてもブラウザＡと同様に、画像が差し替えられる（ＳＡ３１）。画像を差し替えると、再び、上記ＳＡ３０、ＳＡ３１を行う。
【００８３】
イベント送受信機能部２−１は、再び、音声認識を開始するために、音声情報処理サーバ４に監視対象コールセッションＩＤを引数としたＳｔａｒｔＰｌａｙＡｎｄＲｅｃｏｇｉｎｉｚｅＩｎｔｅｒａｃｔｉｏｎメッセージを送る（ＳＡ３２）。以後、上記ＳＡ２４〜ＳＡ３２は、通話中、繰り返し実行される。
【００８４】
セッションの切断時は、次の通りである。
上記ＳＡ１９、ＳＡ２０のように、イベント送受信機能部２−１は、音声情報処理サーバ４にｇｅｔｃａｌｌＳｅｓｓｉｏｎＩｎｆｏｍａｔｉｏｎメッセージを送り、電話用端末３−Ａと電話用端末３−Ｂのセッション状況を定期的に確かめている。電話用端末３−Ｂ（あるいは、電話用端末３−Ａ）から、ＢＹＥのＳＩＰメッセージが音声情報処理サーバ４に送られると（ＳＡ３３）、電話用端末３−Ｂ（あるいは、電話用端末３−Ａ）がセッションから外れる。
【００８５】
このため、音声情報処理サーバ４からイベント送受信機能部２−１へのｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｍａｔｉｏｎメッセージのレスポンスが電話用端末３−Ａ（あるいは、電話用端末３−Ｂ）のＣａｌｌＩＤだけとなる（ＳＡ３４）。イベント送受信機能部２−１は、ＣａｌｌＩＤが電話用端末３−Ａ（あるいは、電話用端末３−Ｂ）だけになると、ブラウザＢ、及びブラウザＡに通話終了を表す画像（ｂｙｅ．ｇｉｆ、図１４（ａ）など）を送る（ＳＡ３５）。その後、電話用端末３−Ａと電話用端末３−Ｂとのセッションを切断する（ＳＡ３６）。
【００８６】
次に、電話用端末３−Ａと電話用端末３−ＢのユーザＡ、Ｂから発せられる言葉に応じて、上述したＳＡ２９〜ＳＡ３０で繰り返し実行される、ケース１〜ケース３について詳細に説明する。
【００８７】
ａ．ケース１（音声認識でキーワードが検出されない場合）
図２２は、本第１実施形態による、音声認識でキーワードが検出されない場合、すなわちケース１での動作を説明するためのシーケンス図である。なお、図２０乃至図２１に対応する部分には同一の符号を付け説明を省略する。
【００８８】
イベント管理機能部２−２は、予め登録されたキーワードが検出されたか否かを判定し（ＳＡ２９）、キーワードが検出されない場合（あるいは音声認識に失敗した場合）には、データベース１２〜１４（図７〜図９）から検出されないときのための画像を、ランダムに選択し、ブラウザＡ、Ｂで表示させる（ＳＡ３０ａ、ＳＡ３１ａ）。
【００８９】
前述したＳＡ６〜ＳＡ９で説明したように、ブラウザＡは、イベント送受信機能部２−１にポーリングしており、そのポーリングの度に、イベント送受信機能部２−１は、イベント管理機能部２−２から更新状況を取得しているで、イベント管理機能部２−２が画像を選択すると、そのポーリングのレスポンスに更新状況が記述され、ブラウザＡの画像が差し替えられる。ブラウザＢについてもブラウザＡと同様に、画像が差し替えられる。
【００９０】
イベント送受信機能部２−１は、イベント情報があると、予め登録されたキーワードが検出されるか否かの判断を行い、検出されない場合には、音声情報処理サーバ４が音声を再生しているか否かを確かめるために、イベント送受信機能部２−１は、音声情報処理サーバ４にｇｅｔＭｅｓｓａｇｅＳｔａｔｕｓメッセージを送る（ＳＡ４０）。音声情報処理サーバ４は、再生しているか否かのレスポンスをイベント送受信機能部２−１に返す（ＳＡ４１）。
【００９１】
音声情報処理サーバ４が何も再生していない場合、イベント送受信機能部２−１は、データベース１４のキャラクタ音声（キャラクタの声など（図９））を再生させるために、音声情報処理サーバ４に再生を要求するｐｌａｙＡｕｄｉｏＭｅｓｓａｇｅメッセージを送る（ＳＡ４２）。音声情報処理サーバ４は、要求されたキャラクタ音声を、電話用端末３−Ａ、及び電話用端末３−Ｂで再生させる（ＳＡ４３）。以降、上記キャラクタ画像の表示と、上記キャラクタ音声の再生とをランダムに実行する。
【００９２】
ｂ．ケース２（音声認識でキーワードが検出された場合）
図２３は、本第１実施形態による、音声認識でキーワードが検出された場合、すなわちケース２での動作を説明するためのシーケンス図である。なお、図２０乃至図２１に対応する部分には同一の符号を付け説明を省略する。
【００９３】
イベント管理機能部２−２は、予め登録されたキーワードが検出されたか否かを判定し、キーワードが検出された場合には、データベース１５（図１０）からキーワードに合ったキャラクタ（動画）画像の動き情報を選択し、ブラウザＡ、Ｂで表示させる（ＳＡ３０ｂ、ＳＡ３１ｂ）。
【００９４】
前述したＳＡ６〜ＳＡ９で説明したように、ブラウザＡは、イベント送受信機能部２−１にポーリングしており、そのポーリングの度に、イベント送受信機能部２−１は、イベント管理機能部２−２から更新状況を取得しているで、イベント管理機能部２−２が画像を選択すると、そのポーリングのレスポンスに更新状況が記述され、ブラウザＡの画像が差し替えられる。ブラウザＢについてもブラウザＡと同様に、画像が差し替えられる。
【００９５】
ｃ．ケース３（音声認識で特殊キーワード（Ｗｅｂ連携キーワード）が検出された場合）
図２４及び図２５は、本第１実施形態による、音声認識でキーワードが検出された場合、すなわちケース３−１、３−２での動作を説明するためのシーケンス図である。なお、図２０乃至図２１に対応する部分には同一の符号を付け説明を省略する。
【００９６】
イベント管理機能部２−２は、予め登録されたキーワードが検出されたか否かを判定し、データベース１６、１７を参照し、Ｗｅｂ連携の特殊キーワード（図１１、図１２）が検出された場合には、Ｗｅｂサービス６から天気情報などを取得する（ＳＡ４５）。Ｗｅｂサービス６は、イベント送受信機能部２−１にレスポンスを返す（ＳＡ４６）。イベント送受信機能部２−１は、ブラウザＡ、及びブラウザＢに表示させるために、Ｗｅｂサービス６から取得した情報を一保存する（ＳＡ４７）。以降、ケース３−１（吹き出し表示）とケース３−２（合成音声）とでそれぞれの処理を実行する。
【００９７】
ｃ−１．ケース３−１（吹き出し表示）
前述したように、ブラウザＡは、イベント送受信機能部２−１にキーワードが検出されたか否かの取得を試みている。イベント送受信機能部２−１は、イベント管理機能部２−２からイベント情報を取得するポーリングを行っているので、ブラウザＡの吹き出し部に天気情報などのｗｅｂサービス６から取得した情報を表示させる（ＳＡ３０ｃ）。キャラクタ（動画）画像は、図１１に示すデータベース１６の動き情報（口パク）に応じて差し替えられる。
【００９８】
ブラウザＢについてもブラウザＡと同様に、Ｗｅｂサービス６から取得した天気情報などの情報を吹き出し部に表示させる。さらに、キャラクタ（動画）画像は、図１１に示すデータベース１６の動き情報（口パク）に応じて差し替えられる（ＳＡ３１ｃ）。イベント送受信機能部２−１は、ブラウザＡ・Ｂに表示させたので、Ｗｅｂサービス６から取得し、保存していた天気情報などの情報を消去する（ＳＡ４８）。
【００９９】
ｃ−２．ケース３−２（合成音声）
イベント送受信機能部２−１は、電話用端末３−Ａ、及び電話用端末３−Ｂに合成音声を流すために、まず、何も音声が再生されていないことを確かめるべく、ｇｅｔＭｅｓｓａｇｅＳｔａｔｕｓのメッセージを音声情報処理サーバ４に送る（ＳＡ５０）。音声情報処理サーバ４からのレスポンスで、音声が生成されていないことが確かめられると、イベント送受信機能部２−１は、ブラウザＡからの要求に応じて、イベント管理機能部２−２に画像差し替えを要求し、イベント管理機能部２−２は、データベース１７（図１２）からキャラクタの動き情報（ポケットからラジオを取り出す：ラジオクリック．ｇｉｆ）の画像を選択し、ブラウザＡで表示させる（ＳＡ５１）。
【０１００】
ブラウザＢについてもブラウザＡと同様に、イベント管理機能部２−２が、データベース１７（図１２）からキャラクタの動き情報（ポケットからラジオを取り出す：ラジオクリック．ｇｉｆ）の画像を選択し、ブラウザＢで表示させる（ＳＡ５２）。
【０１０１】
次に、イベント送受信機能部２−１は、Ｗｅｂから取得した情報を合成音声で端末Ａ、端末Ｂに流すために音声情報処理サーバ４にｐｌａｙＴｂｘｔＭｅｓｓａｇｅメッセージを送る（ＳＡ５３）。音声情報処理サーバ４は、メディアサーバ６にそのメッセージを送り、メディアサーバ６は、Ｗｅｂから取得した文字列の情報を合成音声に変換し、音声情報処理サーバ４に返す（ＳＡ５４）。音声情報処理サーバ４は、合成音声を電話用端末３−Ａ、及び電話用端末３−Ｂで再生させる（ＳＡ５５）。イベント送受信機能部２−１は、ブラウザＡ・Ｂに表示させたので、Ｗｅｂサービス６から取得し、保存していた天気情報などの情報を消去する（ＳＡ４８）。
【０１０２】
Ｂ．変形例
次に、本第１実施形態の変形例について説明する。
【０１０３】
Ｂ−１．第１の変形例
前述したＳＡ６〜ＳＡ９でのポーリング方法、および、ＳＡ３０、ＳＡ３１の画像の表示方法は、以下のようにすることも可能である。
【０１０４】
図２６乃至図２９は、本第１実施形態による第１の変形例の動作を説明するためのシーケンス図である。なお、対応する部分には同一の符号を付けて説明を省略する。ブラウザＡは、ＡＳＰサーバ２のイベント送受信機能部２−１にイベント有無の情報の取得を試みる（ＳＡ６０、ＳＡ７０）。イベント送受信機能部２−１は、イベント管理機能部２−２からイベントの更新状況の情報を取得する（ＳＡ６１、ＳＡ７１）。そして、イベント管理機能部２−２は、何らかのイベントがあるまでレスポンスを保留状態にする（ＳＡ６２、ＳＡ７２）。ブラウザＢについてもブラウザＡと同様である（ＳＡ６３〜ＳＡ６５、ＳＡ７３〜ＳＡ７５）。また、画像を表示する際には、ブラウザＡ、ブラウザＢに同時に差し替え画像を表示する（ＳＡ６９、ＳＡ７７、ＳＡ７８）。
【０１０５】
Ｂ−２．第２の変形例
前述したＳＡ３〜ＳＡ１８における、電話用端末３−Ａと電話用端末３−Ｂとのセッションを確立する手順は、以下のようにすることも可能である。
【０１０６】
図３０は、本第１実施形態による第２の変形例の動作を説明するためのシーケンス図である。なお、図２０乃至図２５と同じ部分は省略している。また、図２０乃至図２５に対応する部分には同一の符号を付けて説明を省略する。ユーザＡ（または、ユーザＢ）がブラウザＡ（または、ブラウザＢ）上で発呼ボタンをクリックすると（ＳＡ８０）、ブラウザＡ（または、ブラウザＢ）からイベント送受信機能部２−１に発呼要求メッセージが送られる（ＳＡ８１）。イベント送受信機能部２−１は、ブラウザＡ（または、ブラウザＢ）からの発呼要求を受けると、音声情報処理サーバ４に電話用端末３−Ａと電話用端末３−Ｂの電話番号を引数としたｍａｋｅＣａｌｌＳｅｓｓｉｏｎメッセージを送る（ＳＡ８２）。音声情報処理サーバ４は、電話用端末３−Ａと電話用端末３−Ｂに発呼し（ＳＡ８３）、電話用端末３−Ａと電話用端末３−Ｂのセッションを確立する（ＳＡ１８）。
【０１０７】
上述した第１実施形態によれば、音声認識機能をネットワーク側におくことで、ユーザは特別な準備をすることなく、サービスを容易に利用することができる。また、音声認識でキーワードの認識を契機に実行するサービスを容易に開発することができる。また、これまで、ｖｏｉｃｅＸＭＬ等では、容易に実現できなかった外部のＷｅｂサービスとの連携も容易に実現することができる。
【０１０８】
また、音声認識を契機にキャラクタを動かしたり、キャラクタに話させたりすることにより、ユーザ間のコミュニケーションの活発化を促すことができる。また、全ユーザに同一画像を表示させることにより、ユーザはつながり感を感じ、音声を越えた視覚でも、通話を楽しむことができる。
【０１０９】
Ｃ．第２実施形態
次に、本発明の第２実施形態について説明する。
図３１は、本第２実施形態による、音声認識コミュニケーション支援システムの構成を説明するためのブロック図である。なお、図１に対応する部分には同一の符号を付けて説明を省略する。図において、本第２実施形態では、電話用端末３−Ａ、３−Ｂと音声情報処理サーバ４との間にＳＩＰ（Session Initiation Protocol）サーバ７を設け、該ＳＩＰサーバ７により、電話用端末３−Ａ、３−Ｂとの間の呼制御を実行する。つまり、前述した第１実施形態では、音声情報処理サーバ４が行っていた、電話用端末３−Ａ、３−Ｂ間の発着信に係る呼制御を、本第２実施形態では、ＳＩＰサーバ７が実行するようになっている。
【０１１０】
言い換えると、本第２実施形態では、音声情報処理サーバ４は、ＡＳＰサーバ２とＳＩＰサーバ７、及び、ＡＳＰサーバ２とメディアサーバ５との間に位置し、ＳＩＰ（Session Initiation Protocol）とＳＯＡＰ（Simple Object Access Protocol）の変換を行うとともに、ＳＩＰサーバ７及びメディアサーバ５の機能にアクセスするＡＰＩ（Application Program Interface）を提供する。
【０１１１】
次に、上述した本第２実施形態の動作を、より詳細に説明する。
図３２乃至図３９は、本第２実施形態の動作を説明するためのシーケンス図である。まず、表示用端末１−Ａ（ブラウザＡ）のユーザＡが、ブラウザＡから本サービスのページにアクセスすると、ブラウザＡは、本サービスを提供するＡＳＰサーバ２のイベント送受信機能部２−１にＨＴＴＰ  ＧＥＴメソッドでＨＴＴＰリクエストメッセージを送る（ＳＢ１）。イベント送受信機能部２−１は、ＨＴＴＰレスポンスをし、ブラウザＡにサービスのスタート画面を表示させる（ＳＢ２）。
【０１１２】
イベント送受信機能部２−１は、上記ＨＴＴＰＧＥＴメソッドのメッセージを受け、ＳＩＰサーバ７と連携するために、音声情報処理サーバ４にｓｔａｒｔＣａｌｌＮｏｒｔｉｆｉｃａｔｉｏｎメッセージを送り（ＳＢ３）、音声情報処理サーバ４は、ＳＩＰサーバ７にメッセージを送る（ＳＢ４）。
【０１１３】
一方、ユーザＢの表示用端末１−Ｂ（ブラウザＢ）も表示用端末１−Ａ（ブラウザＡ）と同様に、サービスのスタート画像を表示させるために、サービス元であるＡＳＰサーバ２のイベント送受信機能部２−１にＨＴＴＰ  ＧＥＴメッセージを送る（ＳＢ５）。イベント送受信機能部２−１は、ブラウザＢにサービスブラウザ画面を表示させる（ＳＢ６、図３１のＳｃ１）。
【０１１４】
ブラウザＡは、Ａｊａｘによってポーリングし、ＡＳＰサーバ２のイベント送受信機能部２−１にイベントの有無の情報を要求する（ＳＢ７）。イベント送受信機能部２−１は、イベント管理機能部２−２にイベントの更新状況の情報を要求する（ＳＢ８）。イベント管理機能部２−２は、イベント送受信機能部２−１に更新状況の結果（ここでは「更新なし」）をイベント送受信機能部２−１に返す（ＳＢ９）。イベント送受信機能部２−１は、ブラウザＡにイベント情報の有無のレスポンスを返す（ＳＢ１０）。
【０１１５】
ユーザＢの表示用端末１−Ｂ（ブラウザＢ）も表示用端末１−Ａ（ブラウザＡ）と同様に、Ａｊａｘによってポーリングし、ＡＳＰサーバ２のイベント送受信機能部２−１からイベントの有無の情報の取得を試みる（ＳＢ１１）。イベント送受信機能部２−１は、イベント管理機能部２−２からイベントの更新状況の情報を取得する（ＳＢ１２）。イベント管理機能部２−２は、イベント送受信機能部２−１に更新状況の結果（ここでは「更新なし」）を返す（ＳＢ１３）。イベント送受信機能部２−１は、ブラウザＡにイベント情報の有無のレスポンスを返す（ＳＢ１４）。
【０１１６】
電話用端末３−ＡのユーザＡが電話用端末３−ＢのユーザＢと通話するために、電話用端末３−Ｂに向けて発呼する（ＳＢ１５、ＳＢ１６）。ＳＩＰサーバ７は、電話用端末３−Ａからの発呼を受け、誰から着信があったかイベント送受信機能部２−１に通知するために、イベント送受信機能部２−１にｎｏｔｉｆｙＣａｌｌｅｄＮｕｍｂｅｒメッセージを送る（ＳＢ１７、ＳＢ１８）。イベント送受信機能部２−１は、そのメッセージをイベント管理機能部２−２に送る（ＳＢ１９）。
【０１１７】
イベント送受信機能部２−１は、電話用端末３−Ａと電話用端末３−Ｂとの間でセッションが確立したか否かを確かめるために、電話用端末３−ＢのＣａｌｌＳｅｓｓｉｏｎＩＤを引数としたｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｍａｔｉｏｎメッセージを音声情報処理サーバ４に送り（ＳＢ２０）、音声情報処理サーバ４は、ＳＩＰサーバ７に送る（ＳＢ２１）。ＳＩＰサーバ７は、セッション情報を音声情報処理サーバ４に返し（ＳＢ２２）、音声情報処理サーバ４は、イベント送受信機能部２−１にレスポンスを返す（ＳＢ２３、図３１のＳｃ２）。以下、切断時まで、セッションが確立したか否かを確かめためのポーリングを続ける。そして、電話用端末３−Ｂが電話に出ると、電話用端末３−Ａと電話用端末３−Ｂとの間でセッションが確立する（ＳＢ２４、図３１のＳｃ３）。
【０１１８】
イベント送受信機能部２−１は、上記ＳＢ２０〜ＳＢ２３により、電話用端末３−Ａと電話用端末３−Ｂとの間でセッションが確立したことを確認すると、キャラクタが登場する画像（ｃｏｍｅ−ｏｎ．ｇｉｆ（図１４（ａ））など）を表示用端末１−Ｂ（ブラウザＢ）と表示用端末１−Ａ（ブラウザＡ）に表示させる（ＳＢ２５）。画面イメージは、図４に示すようになり、ここでは、ＲＴＰ（Real-time Transport Protocol）は、電話用端末３−Ａと電話用端末３−Ｂの間に張られている（図３１を参照）。
【０１１９】
さらに、イベント送受信機能部２−１は、メディアサーバ５により音声認識を開始するために、音声情報処理サーバ４にａｄｄＣａｌｌＰａｒｔｉｃｉｐａｎｔのメッセージを送り（ＳＢ２６）、メディアサーバ５と電話用端末３−Ａと電話用端末３−Ｂとの３者通話を実現する（ＳＢ２７）。ここで、ＲＴＰは、電話用端末３−Ａとメディアサーバ５間、及び電話用端末３−Ｂとメディアサーバ５間に張られる（図３１を参照）。
【０１２０】
イベント送受信機能部２−１は、音声認識の結果の通知先を登録するために、音声情報処理サーバ４に監視対象コールセッションＩＤを引数としたｓｔａｒｔＰｌａｙＡｎｄＲｅｃｏｇｉｎｉｚｅＮｏｔｉｆｉｃａｔｉｏｎメッセージを送る（ＳＢ２８）。音声情報処理サーバ４は、メディアサーバ５にそのメッセージを送る（ＳＢ２９）。
【０１２１】
また、イベント送受信機能部２−１は、音声認識を開始するために、音声情報処理サーバ４に監視対象コールセッションＩＤを引数としたｓｔａｒｔＰｌａｙＡｎｄＲｅｃｏｇｉｎｉｚｅＩｎｔｅｒａｃｔｉｏｎメッセージを送り（ＳＢ３０）、音声情報処理サーバ４は、メディアサーバ５にそのメッセージを送る（ＳＢ３１）。
【０１２２】
次に、電話用端末３−Ａ（あるいは、電話用端末３−Ｂ）で音声の会話がなされると（ＳＢ３２）、メディアサーバ５は、音声情報処理サーバ４に検出された音声（言葉）を送り（ＳＢ３３）、音声情報処理サーバ４は、音声認識で検出された音声（言葉）をｎｏｔｉｆｙＰｌａｙＡｎｄＲｅｃｏｇｎｉｚｅＥｖｅｎｔメッセージでイベント送受信機能部２−１に送る（ＳＢ３４）。
【０１２３】
イベント送受信機能部２−１は、イベント管理機能部２−２にその検出された言葉を通知し（ＳＢ３５）、イベント管理機能部２−２は、検出された言葉がデータベース１５〜１７（図１０〜図１２を参照）の中のキーワードと一致するか否かを判定する（ＳＢ３６）。イベント管理機能部２−２は、キーワード検出判定した結果から、データベース１０〜１７（図６〜図１３参照）からキーワードに合った画像（キーワードが検出されない場合には図７）を選択する。
【０１２４】
前述したＳＢ７〜ＳＢ１０で説明したように、ブラウザＡは、イベント送受信機能部２−１にイベントの有無の情報を取得するポーリングをしており、そのポーリングの度に、イベント送受信機能部２−１は、イベント管理機能部２−２にイベント更新状況の情報を取得している。
【０１２５】
このため、イベント管理機能部２−２が、ｎｏｔｉｆｙＰｌａｙＡｎｄＲｅｃｏｇｎｉｚｅＥｖｅｎｔを受け取り、キーワードの検出判定し、さらにキーワードに合ったキャラクタ（動画）画象を検出しておくことで、イベント管理機能部２−２のイベント送受信機能部２−１に対するレスポンスにより、画像が更新され、ブラウザＡの画像が差し替えられる（ＳＢ３７）。また、ブラウザＢにおいてもブラウザＡと同様に、画像が差し替えられる（ＳＢ３８）。画像を差し替えると、再び、上記ＳＢ３７、ＳＢ３８を行う。
【０１２６】
イベント送受信機能部２−１は、再び、音声認識を開始するために、音声情報処理サーバ４に監視対象コールセッションＩＤを引数としたＳｔａｒｔＰｌａｙＡｎｄＲｅｃｏｇｉｎｉｚｅＩｎｔｅｒａｃｔｉｏｎメッセージを送り（ＳＢ３９）、音声情報処理サーバ４は、メディアサーバ４に送る（ＳＢ４０）。以後、電話用端末３−Ａと電話用端末３−Ｂのユーザから発せられる言葉によって、ケース１〜ケース４の何れかのステップとなり、通話中、上記ＳＢ３２〜ＳＢ４０を繰り返す。
【０１２７】
セッションの切断時は、次の通りである。
上記ＳＢ２０、ＳＢ２１のように、イベント送受信機能部２−１は、音声情報処理サーバ４にｇｅｔｃａｌｌＳｅｓｓｉｏｎＩｎｆｏｍａｔｉｏｎメッセージを送り、音声情報処理サーバ４がＳＩＰサーバ７にそのメッセージを送ることで、電話用端末３−Ａと電話用端末３−Ｂとのセッション状況を定期的に確かめている。電話用端末３−Ｂ（あるいは、電話用端末３−Ａ）から、ＢＹＥのＳＩＰメッセージがＳＩＰサーバ７に送られると（ＳＢ４１）、電話用端末３−Ｂ（あるいは、電話用端末３−Ａ）がセッションから外れる。
【０１２８】
このため、音声情報処理サーバ４からイベント送受信機能部２−１へのｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｍａｔｉｏｎメッセージのレスポンスが電話用端末３−Ａ（あるいは、電話用端末３−Ｂ）のＣａｌｌＩＤだけとなる（ＳＢ４２）。イベント送受信機能部２−１は、ＣａｌｌＩＤが電話用端末３−Ａ（あるいは、電話用端末３−Ｂ）だけになると、ブラウザＢ、及びブラウザＡに通話終了を表す画像（ｂｙｅ．ｇｉｆ、図１４（ａ）など）を送る（ＳＢ４３）。その後、電話用端末３−Ａと電話用端末３−Ｂとのセッションを切断する（ＳＢ４４）。
【０１２９】
次に、電話用端末３−Ａと電話用端末３−ＢのユーザＡ、Ｂから発せられる言葉に応じて、上述したＳＢ３２〜ＳＢ４０で繰り返し実行される、ケース１〜ケース４について詳細に説明する。
【０１３０】
ａ．ケース１（音声認識でキーワードが検出されない場合）
図３６は、本第２実施形態による、音声認識でキーワードが検出されない場合、すなわちケース１での動作を説明するためのシーケンス図である。なお、図３２乃至図３５に対応する部分には同一の符号を付け説明を省略する。
【０１３１】
（Ａ）イベント管理機能部２−２は、予め登録されたキーワードが検出されたか否かを判定し、キーワードが検出されない場合には、データベース１２、１３（図７及び図８）から検出されないときのための画像をランダムに選択し、ブラウザＡ、Ｂで表示させる（ＳＢ３７ａ、ＳＢ３８ａ）。上記ＳＢ７〜ＳＢ１０のように、ブラウザＡからイベント送受信機能部２−１にポーリングしており、そのポーリングの度に、イベント送受信機能部２−１は、イベント管理機能部２−２から更新状況を取得しているので、イベント管理機能部２−２が画像を選択すると、そのポーリングのレスポンスに更新状況が記述され、ブラウザＡの画像が差し替えられる。ブラウザＢについてもブラウザＡと同様に、画像が差し替えられる。
【０１３２】
（Ｂ）イベント送受信機能部２−１は、イベント情報があると、予め登録されたキーワードが検出されるか否かの判定を行い、キーワードが検出されない場合には、メディアサーバ５が音声を再生しているか否かを確かめるために、イベント送受信機能部２−１は、音声情報処理サーバ４にｇｅｔＭｅｓｓａｇｅＳｔａｔｕｓメッセージを送り（ＳＢ４０）、音声情報処理サーバ４は、メディアサーバ５にそのメッセージを送る（ＳＢ４１）。メディアサーバ５は、再生されているか否かのレスポンスを音声情報処理サーバ４に返し（ＳＢ４２）、音声情報処理サーバ４は、イベント送受信機能部２−１にレスポンスを返す（ＳＢ４３）。
【０１３３】
メディアサーバ５が何も再生していない場合、イベント送受信機能部２−１は、音声（キャラクタの声など（図９））を再生させるために、音声情報処理サーバ４に再生を要求するｐｌａｙＡｕｄｉｏＭｅｓｓａｇｅメッセージを送り（ＳＢ４４）、音声情報処理サーバ４は、メディアサーバ５にそのメッセージを送る（ＳＢ４５）。メディアサーバ５は、このメッセージに対する制御のための識別情報を音声情報処理サーバ４にに返し（ＳＢ４６）、音声情報処理サーバ４は、イベント送受信機能部２−１にレスポンスを返す（ＳＢ４７）。そして、メディアサーバ５は、要求された音声を電話用端末３−Ａ、及び電話用端末３−Ｂで再生させる（ＳＢ４８）。
【０１３４】
以降、上記（Ａ）キャラクタ画像の表示と、上記（Ｂ）キャラクタ音声の再生とをランダムに実行する。
【０１３５】
ｂ．ケース２（音声認識でキーワードが検出された場合）
図３７は、本第２実施形態による、音声認識でキーワードが検出された場合、すなわちケース２での動作を説明するためのシーケンス図である。なお、図３２乃至図３５に対応する部分には同一の符号を付け説明を省略する。
【０１３６】
イベント管理機能部２−２は、予め登録されたキーワードが検出されたか否かを判定し、キーワードが検出された場合には、データベース１５（図１０）からキーワードに合った画像を選択する。上記ＳＢ７〜ＳＢ１０のように、ブラウザＡからイベント送受信機能部２−１にポーリングしており、そのポーリングの度に、イベント送受信機能部２−１は、イベント管理機能部２−２に更新状況を取得するポーリングをしているので、イベント管理機能部２−２が画像を選択すると、そのポーリングのレスポンスに更新状況が記述され、ブラウザＡの画像が差し替えられる（ＳＢ３７ｂ）。ブラウザＢについても、ブラウザＡと同様に、画像が差し替えられる（ＳＢ３８ｂ）。
【０１３７】
ｃ．ケース３（音声認識で特殊キーワード（ｗｅｂ連携キーワード）が検出された場合）
図３８は、本第２実施形態による、音声認識でキーワードが検出された場合、すなわちケース３−１、３−２での動作を説明するためのシーケンス図である。なお、図３２乃至図３５に対応する部分には同一の符号を付け説明を省略する。
【０１３８】
イベント管理機能部２−２は、予め登録されたキーワードが検出されたか否かを判定し、データベース１６、１７を参照し、Ｗｅｂ連携の特殊キーワード（図１１、図１２）が検出された場合には、Ｗｅｂサービス６から天気情報などを取得する（ＳＢ５０）。Ｗｅｂサービス６は、イベント送受信機能部２−１にレスポンスを返す（ＳＢ５１）。イベント送受信機能部２−１は、ブラウザＡ、及びブラウザＢに表示させるために、Ｗｅｂサービス６から取得した情報を一保存する（ＳＢ５２）。以降、ケース３−１（吹き出し表示）とケース３−２（合成音声）とでそれぞれの処理を実行する。
【０１３９】
ｃ−１．ケース３−１（吹き出し表示）
前述したＳＢ７〜ＳＢ１０で述べたように、ブラウザＡは、イベント送受信機能部２−１にキーワードが検出されたか否かの取得を試みている。イベント送受信機能部２−１は、イベント管理機能部２−２からイベント情報を取得するポーリングを行っているので、ブラウザＡの吹き出し部に天気情報などのｗｅｂサービス６から取得した情報を表示させる（ＳＢ３７ｃ）。キャラクタ（動画）画像は、図１１に示すデータベース１６の動き情報（口パク）に応じて差し替えられる。
【０１４０】
ブラウザＢについてもブラウザＡと同様に、Ｗｅｂサービス６から取得した天気情報などの情報を吹き出し部に表示させる。さらに、キャラクタ（動画）画像は、図１１に示すデータベース１６の動き情報（口パク）に応じて差し替えられる（ＳＢ３８ｃ）。イベント送受信機能部２−１は、ブラウザＡ・Ｂに表示させたので、Ｗｅｂサービス６から取得し、保存していた天気情報などの情報を消去する（ＳＢ５３）。
【０１４１】
ｃ−２．ケース３−２（合成音声）
イベント送受信機能部２−１は、電話用端末３−Ａ、及び電話用端末３−Ｂに合成音声を流すために、まず、何も音声が再生されていないことを確かめるべく、ｇｅｔＭｅｓｓａｇｅＳｔａｔｕｓのメッセージを音声情報処理サーバ４に送り（ＳＢ５３）、音声情報処理サーバ４は、メディアサーバ５にそのメッセージを送る（ＳＢ５４）。メディアサーバ５は、そのメッセージに対するレスポンスを音声情報処理サーバ４に返し（ＳＢ５５）、音声処理情報処理サーバ４は、イベント送受信機能部２−１にそのレスポンスを返す（ＳＢ５６）。イベント送受信機能部２−１は、メディアサーバ５からのレスポンスで音声が生成されていないことが確かめられると、以下の処理を実行する。
【０１４２】
イベント送受信機能部２−１は、ブラウザＡからの要求に応じて、イベント管理機能部２−２に画像差し替えを要求し、イベント管理機能部２−２は、データベース１７（図１２）からキャラクタの動き情報（ポケットからラジオを取り出す：ラジオクリック．ｇｉｆ）の画像を選択し、ブラウザＡで表示させる（ＳＢ５７）。
【０１４３】
ブラウザＢについてもブラウザＡと同様に、イベント管理機能部２−２が、データベース１７（図１２）からキャラクタの動き情報（ポケットからラジオを取り出す：ラジオクリック．ｇｉｆ）の画像を選択し、ブラウザＢで表示させる（ＳＢ５８）。
【０１４４】
次に、イベント送受信機能部２−１は、Ｗｅｂサービス６から取得した情報を合成音声で電話用端末３−Ａ、及び電話用端末３−Ｂに流すために、音声情報処理サーバ４にｐｌａｙＴｅｘｔＭｅｓｓａｇｅメッセージを送り（ＳＢ５９）、音声情報処理サーバ４は、そのメッセージをメディアサーバ５に送る（ＳＢ６０）。メディアサーバ５は、ｗｅｂサービス６から取得した文字列の情報を音声合成に変換し、電話用端末３−Ａ、及び電話用端末３−Ｂで再生させる（ＳＢ６１）。イベント送受信機能部２−１は、ブラウザＡ・Ｂに表示させたので、Ｗｅｂサービス６から取得し、保存していた天気情報などの情報を消去する（ＳＢ５３）。
【０１４５】
Ｄ．第３実施形態
次に、本発明の第３実施形態について説明する。
図４０は、本第３実施形態による音声認識コミュニケーション支援システムの構成を説明するためのブロック図である。なお、図３１に対応する部分には同一の符号を付けて説明を省略する。
【０１４６】
本第３実施形態では、電話用端末３−Ａ、電話用端末３−Ｂ、ＳＩＰサーバ７、メディアサーバ５、音声情報処理サーバ４が同一スイッチングハブ９内に構成されている場合を想定している。スイッチングハブ９は、上記の機器に加えてパケットキャプチャ装置８を更に備えている。パケットキャプチャ装置８は、それぞれの機器に到達するパケット（メッセージ）をミラーリング（コピー）して、キャプチャ内容に応じて、以下のような処理を実行する。
【０１４７】
まず、電話用端末３−Ａと電話用端末３−Ｂとの間でのセッション確立のために、ブラウザＡは、前述した第２実施形態と同様に、図３２に示すＳＢ１〜ＳＢ１０を実行することで、Ａｊａｘによってポーリングする。イベント送受信機能部２−１は、上記ブラウザＢからのＨＴＴＰ  ＧＥＴメソッドのメッセージを受け（図３２のＳＢ５）、イベント送受信機能部２−１は、電話用端末３−Ａと電話用端末３−Ｂとの間でセッションが確立したか否かを確かめるために、電話用端末３−Ａと電話用端末３−ＢとのＣａｌｌＳｅｓｓｉｏｎＩＤを引数としたｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｍａｔｉｏｎメッセージを音声情報処理サーバ４に送り、音声情報処理サーバ４は、ＳＩＰサーバ７に送る。ＳＩＰサーバ７は、セッション情報を音声情報処理サーバ４に返し、音声情報処理サーバ４は、イベント送受信機能部２−１にレスポンスを返す（図４０のＳｄ１）。以下、切断時まで当該ポーリングを続ける（図３３のＳＢ２０〜ＳＢ２３）。
【０１４８】
次に、電話用端末３−ＡのユーザＡが電話用端末３−ＢのユーザＢに向けて発呼し、電話用端末３−Ｂが電話に出ると、電話用端末３−Ａと電話用端末３−Ｂとのセッションが確立する（図４０のＳｄ２）。パケットキャプチャ装置８は、それぞれの機器に到達するパケット（メッセージ）をミラーリング（コピー）し、電話用端末３−Ａと電話用端末３−Ｂのセッション確立状況を把握する。パケットキャプチャ装置８は、ユーザ同士のセッションの確立を音声情報処理サーバ４に通知する。通知を受けた段階で、前述のｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｍａｔｉｏｎのレスポンスが「セッション確立」となる。
【０１４９】
イベント送受信機能部２−１は、電話用端末３−Ａと電話用端末３−Ｂのセッションが確立したことを確認すると、キャラクタが登場する画像（ｃｏｍｅ−ｏｎ．ｇｉｆ（図１４（ａ））など）をブラウザＡ、およびブラウザＢに表示させる（図３３のＳＢ２５）。
【０１５０】
また、イベント送受信機能部２−１は、電話用端末３−Ａと電話用端末３−Ｂのセッションが確立したことを確認すると、電話用端末３−Ａと電話用端末３−Ｂのセッションにメディアサーバ５を巻き込み、３者通話を実現するために（ユーザ同士の会話をメディアサーバ５が音声認識するために）、音声情報処理サーバ４にａｄｄＣａｌｌＰａｒｔｉｃｉｐａｎｔのメッセージを送り、電話用端末３−Ａと電話用端末３−Ｂとのセッションにメディアサーバ５を追加し、３者通話を実現する（図３３のＳＢ２６、ＳＢ２７）。以下、前述した第２実施形態で述べた、図３３のＳＢ２８以降と同様の処理を実行する。
【０１５１】
そして、セッションの切断時は、以下の通りである。
イベント送受信機能部２−１は、前述したように、音声情報処理サーバ４にｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｍａｔｉｏｎメッセージを送り、音声情報処理サーバ４がＳＩＰサーバ７にそのメッセージを送ることで、電話用端末３−Ａと電話用端末３−Ｂとのセッション状況を定期的に確認している。
【０１５２】
電話用端末３−Ｂ（あるいは電話用端末３−Ａ）からＢＹＥのＳＩＰメッセージがＳＩＰサーバ７に送られると、電話用端末３−Ａと電話用端末３−Ｂとがセッションから外れる。イベント送受信機能部２−１は、ＣａｌｌＩＤが電話用端末３−Ａ（あるいは電話用端末３−Ｂ）だけになると、ブラウザＢ及びブラウザＡに通話終了を表す画像（ｂｙｅ．ｇｉｆ（図１４（ｂ））など）を送る。
【０１５３】
パケットキャプチャ装置８は、ミラーリングをしているので、電話用端末３−Ａと電話用端末３−Ｂとのセッションが切断されると、音声情報処理サーバ４に通知する。音声情報処理サーバ４のイベント送受信機能部２−１に対するｇｅｔＣａｌｌＳｅｓｓｉｏｎＩｎｆｏｍａｔｉｏｎメッセージのレスポンスが「セッション切断」になり、イベント送受信機能部２−１は、イベント管理機能部２−２にそのメッセージを送り、ＡＳＰサーバ２は、切断を把握する。イベント管理機能部２−２は、メディアサーバ５をセッションから解放するために、音声情報処理サーバ４にｅｎｄＣａｌｌＳｅｓｓｉｏｎのメッセージを送り、音声情報処理サーバ４は、メディアサーバ５をセッションから開放し、サービスが終了する。
【０１５４】
上述した第１から第３実施形態によれば、音声認識機能をネットワーク側におくことで、ユーザは、特別な準備を必要とすることなく、サービスを利用することが可能になる。また、音声認識でキーワードの認識を契機に実行するサービスの開発が容易になる。また、これまで、ｖｏｉｃｅＸＭＬ等では、容易に実現できなかった外部のｗｅｂサービスとの連携も容易に実現可能である。
【０１５５】
また、音声認識を契機にキャラクタを動かしたり、キャラクタに話させることにより、ユーザ間のコミュニケーションの活発化を促すことができる。全ユーザに同一画像を表示させることにより、ユーザは、つながり感を感じ、音声だけを越えた視覚でも通話を楽しむことができる。
【０１５６】
以上、図面を参照して本発明の実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
【符号の説明】
【０１５７】
１−Ａ、１−Ｂ  表示用端末
２  ＡＳＰサーバ
２−１  イベント送受信機能部
２−２  イベント管理機能部
３−Ａ、３−Ｂ  電話用端末
４  音声情報処理サーバ
５  メディアサーバ
６  Ｗｅｂサービス
７  ＳＩＰサーバ
８  パケットキャプチャ装置
【図１】
2010211172.tif 000003
【図２】
2010211172.tif 000004
【図３】
2010211172.tif 000005
【図４】
2010211172.tif 000006
【図５】
2010211172.tif 000007
【図６】
2010211172.tif 000008
【図７】
2010211172.tif 000009
【図８】
2010211172.tif 000010
【図９】
2010211172.tif 000011
【図１０】
2010211172.tif 000012
【図１１】
2010211172.tif 000013
【図１２】
2010211172.tif 000014
【図１３】
2010211172.tif 000015
【図１４】
2010211172.tif 000016
【図１５】
2010211172.tif 000017
【図１６】
2010211172.tif 000018
【図１７】
2010211172.tif 000019
【図１８】
2010211172.tif 000020
【図１９】
2010211172.tif 000021
【図２０】
2010211172.tif 000022
【図２１】
2010211172.tif 000023
【図２２】
2010211172.tif 000024
【図２３】
2010211172.tif 000025
【図２４】
2010211172.tif 000026
【図２５】
2010211172.tif 000027
【図２６】
2010211172.tif 000028
【図２７】
2010211172.tif 000029
【図２８】
2010211172.tif 000030
【図２９】
2010211172.tif 000031
【図３０】
2010211172.tif 000032
【図３１】
2010211172.tif 000033
【図３２】
2010211172.tif 000034
【図３３】
2010211172.tif 000035
【図３４】
2010211172.tif 000036
【図３５】
2010211172.tif 000037
【図３６】
2010211172.tif 000038
【図３７】
2010211172.tif 000039
【図３８】
2010211172.tif 000040
【図３９】
2010211172.tif 000041
【図４０】
2010211172.tif 000042