JP2011139303A - 通信システム、制御装置、通信制御方法、およびプログラム - Google Patents

通信システム、制御装置、通信制御方法、およびプログラム Download PDF

Info

Publication number
JP2011139303A
JP2011139303A JP2009298021A JP2009298021A JP2011139303A JP 2011139303 A JP2011139303 A JP 2011139303A JP 2009298021 A JP2009298021 A JP 2009298021A JP 2009298021 A JP2009298021 A JP 2009298021A JP 2011139303 A JP2011139303 A JP 2011139303A
Authority
JP
Japan
Prior art keywords
voice
processing
audio data
communication system
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2009298021A
Other languages
English (en)
Inventor
Keiko Inagaki
敬子 稲垣
Kentaro Nagatomo
健太郎 長友
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2009298021A priority Critical patent/JP2011139303A/ja
Publication of JP2011139303A publication Critical patent/JP2011139303A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Telephonic Communication Services (AREA)

Abstract

【課題】リアルタイムな音声データ通信を実現する通信システム、制御装置、通信制御方法、およびプログラムを提供する。
【解決手段】通信システム1は、音声認識サーバ40と、TCP上で、HTTPを用いて、一連の音声データを順次、一つのセッションにつき複数のコネクション30を利用して送出する音声データ送出部134と、複数の音声データをそれぞれ受信する音声データ受信部102と、複数のコネクション30を利用してそれぞれ受信した複数の音声データの中から一つの音声データを選択し、選択された音声データを順に並べ、音声認識サーバ40に送信し、音声認識サーバ40により音声認識処理された認識結果を非同期に受信する制御部110と、受信した認識結果を、一つのセッションにつき複数のコネクション30を利用して転送する転送部118と、を備える。
【選択図】図1

Description

本発明は、通信システム、制御装置、通信制御方法、およびプログラムに関し、特に、音声認識に関連するデータの通信システム、制御装置、通信制御方法、およびプログラムに関する。
近年のSaaS(Software as a Service)の発展により、音声認識関連のビジネスにおいても、SaaS型でのサービス提供が求められている。これにより、HTTP(HyperText Transfer Protocol)上で音声認識をさせたいというニーズが高まってきている。HTTPは通常、TCP(Transmission Control Protocol)上で実装されているが、TCPは、コネクション型のプロトコルで、フロー制御や再送制御の機構を備えているため、信頼性が求められる通信に適しているが、データ通信時に遅延が発生するという問題があった。
TCPによるリアルタイムデータ通信装置の一例が特許文献1に記載されている。特許文献1の通信装置は、クライアントと、サーバと、サーバ内にあるコネクション管理手段とから構成されており、以下のように動作する。TCP上でリアルタイム伝送を実現するために、サーバに対し複数のTCPコネクションをはっておき、コネクション管理手段が、複数のコネクションの中から適切なTCPコネクションを選択する。これにより、データのリアルタイム性を確保し、効率のよい伝送を実現することができる。
特開2005−12711号公報 特開2003−288221号公報 特開2007−164806号公報 特開2003−125022号公報
音声認識では、入力された音声データをシーケンシャルに処理するため、入力データ(パケット)に一部でも遅延が発生すると、そのパケットに含まれる音声データに対応する単語の音声認識処理ができなくなったり、処理が滞ってしまう。このため、認識結果の提示のリアルタイム性が求められているサービスでは、使い勝手が悪いという問題点があった。
上述した特許文献1に記載された通信装置においては、ストリーミングデータの伝送に関するリアルタイム性の向上については、解決しているが、音声ストリーミングデータを送信し、その音声データを音声認識処理した認識結果をさらにリアルタイムに返信することは考慮されていない。すなわち、特許文献1に記載の通信装置では、複数のコネクションの中から所定の帯域を有さないコネクションが検出された場合、他のコネクションを選択してストリーミングデータを送信するが、複数のコネクションのすべてにストリーミングデータを送信してはいない。そして、特許文献1に記載の通信装置では、コネクションの状況が悪化してからコネクションを切り替えるため、一部のストリーミングデータが伝送できない可能性があり、音声データの一部のパケットが欠落した場合にそのパケットを救済することは考慮されていない。このため、音声データのパケットのように、1パケットの欠落が認識結果に大きく影響を及ぼすシステムには適していないという問題点があった。
本発明の目的は、上述した課題であるリアルタイムな音声データ通信を実現する通信システム、制御装置、通信制御方法、およびプログラムを提供することにある。
本発明の通信システムは、
音声データを入力して音声処理を行い、その処理結果を出力する音声処理装置と、
TCP上で、HTTPを用いて、一連の音声データを順次、一つのセッションにつき複数のコネクションを利用して送出する送出手段と、
送出された複数の前記音声データをそれぞれ受信する受信手段と、
前記受信手段により複数の前記コネクションを利用してそれぞれ受信した複数の前記音声データの中から一つの音声データを選択し、選択された前記音声データを順に並べ、前記音声データを前記音声処理装置に送信し、前記音声処理装置により音声処理された前記処理結果を非同期に受信する制御手段と、
受信した前記処理結果を、一つの前記セッションにつき複数の前記コネクションを利用して転送する転送手段と、を備える。
本発明の通信制御方法は、
音声データを入力して音声処理を行い、その処理結果を出力する音声処理装置に接続される制御装置の通信制御方法であって、
前記制御装置が、
TCP(Transmission Control Protocol)上で、HTTP(HyperText Transfer Protocol)を用いて、一連の音声データを順次、一つのセッションにつき複数のコネクションを利用して送出し、
送出された複数の前記音声データをそれぞれ受信し、
複数の前記コネクションを利用してそれぞれ受信した複数の前記音声データの中から一つの音声データを選択し、
選択された前記音声データを順に並べ、
前記音声データを前記音声処理装置に送信し、
前記音声処理装置により音声処理された前記処理結果を非同期に受信し、
受信した前記処理結果を、一つの前記セッションにつき複数の前記コネクションを利用して転送する。
本発明のコンピュータプログラムは、
音声データを入力して音声処理を行い、その処理結果を出力する音声処理装置に、前記音声データをネットワークを介して送信し、前記音声認識装置から出力された前記処理結果を前記ネットワークを介して転送する制御装置を実現するためのコンピュータに、
TCP(Transmission Control Protocol)上で、HTTP(HyperText Transfer Protocol)を用いて、一連の音声データを順次、一つのセッションにつき複数のコネクションを利用して送出する手順と、
送出された複数の前記音声データをそれぞれ受信する手順と、
複数の前記コネクションを利用してそれぞれ受信した複数の前記音声データの中から一つの音声データを選択する手順と、
選択された前記音声データを順に並べる手順と、
前記音声データを前記音声処理装置に送信する手順と、
前記音声処理装置により音声処理された前記処理結果を非同期に受信する手順と、
受信した前記処理結果を、一つの前記セッションにつき複数の前記コネクションを利用して転送する手順と、を実行させるためのプログラムである。
本発明の制御装置は、
音声データを入力して音声処理を行い、その処理結果を出力する音声処理装置に接続され、
TCP(Transmission Control Protocol)上で、HTTP(HyperText Transfer Protocol)を用いて、一連の音声データを順次、一つのセッションにつき複数のコネクションを利用して送出する送出手段と、
送出された複数の前記音声データをそれぞれ受信する受信手段と、
前記受信手段により複数の前記コネクションを利用してそれぞれ受信した複数の前記音声データの中から一つの音声データを選択し、選択された前記音声データを順に並べ、前記音声データを前記音声処理装置に送信し、前記音声処理装置により音声処理された前記処理結果を非同期に受信する制御手段と、
受信した前記処理結果を、一つの前記セッションにつき複数の前記コネクションを利用して転送する転送手段と、を備える。
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
また、本発明の各種の構成要素は、必ずしも個々に独立した存在である必要はなく、複数の構成要素が一個の部材として形成されていること、一つの構成要素が複数の部材で形成されていること、ある構成要素が他の構成要素の一部であること、ある構成要素の一部と他の構成要素の一部とが重複していること、等でもよい。
また、本発明の制御方法およびコンピュータプログラムには複数の手順を順番に記載してあるが、その記載の順番は複数の手順を実行する順番を限定するものではない。このため、本発明の制御方法およびコンピュータプログラムを実施するときには、その複数の手順の順番は内容的に支障しない範囲で変更することができる。
さらに、本発明の制御方法およびコンピュータプログラムの複数の手順は個々に相違するタイミングで実行されることに限定されない。このため、ある手順の実行中に他の手順が発生すること、ある手順の実行タイミングと他の手順の実行タイミングとの一部ないし全部が重複していること、等でもよい。
本発明によれば、リアルタイムな音声データ通信を実現する通信システム、制御装置、通信制御方法、およびプログラムが提供される。
本発明の実施の形態に係る通信システムの構成を示すブロック図である。 本発明の実施の形態に係る通信システムの制御装置の構成を示す機能ブロック図である。 本発明の実施の形態に係る通信システムの動作の一例を示すフローチャートである。 本発明の実施の形態に係る通信システムの動作の一例を示すフローチャートである。 本発明の実施の形態に係る通信システムの構成を示すブロック図である。 本発明の実施の形態に係る通信システムの構成を示すブロック図である。
以下、本発明の実施の形態について、図面を用いて説明する。尚、すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。
(第1の実施の形態)
図1は、本発明の実施の形態に係る通信システム1の構成を示すブロック図である。
本実施形態の通信システムは、たとえば、ネットワーク(不図示)を介してウェブサーバ20にユーザ端末50がアクセスし、音声認識サーバ40に音声データを送信し、音声認識処理を行わせてその結果を取得し、ユーザ端末50に認識結果を返信し、ユーザ端末50の表示部(不図示)に表示させるようなサービスをユーザに提供するサービス提供システムにおける通信制御を行うものである。
本実施形態の通信システム1は、少なくとも1つのユーザ端末50がインターネットまたはイントラネットなどのネットワークを介して、上記サービス提供システムを利用する際にアクセスするウェブサーバ20と、音声認識サーバ40と、本システムの通信を制御する制御装置100と、ユーザ端末50からウェブサーバ20に音声データを送信するクライアント10と、を備える。
本実施形態において、ユーザ端末50のユーザまたは、少なくとも1つのユーザ端末50を管理する管理者は、予めサービスプロバイダなどとサービス利用に関する契約を行っており、ユーザ登録などを行い、ユーザアカウントなどを取得しているものとする。本システムにおいて、ユーザ認証などが必要な場合には、ユーザアカウントに対応するパスワードなどの情報も予め登録されているものとする。本実施形態の通信システム1は、たとえば、SaaS型のサービス提供システムにおいて、音声認識サービスを提供するシステムの通信制御処理を担うものである。
ユーザ端末50は、たとえば、図示しないCPU(Central Processing Unit)やメモリ、ハードディスク、および通信装置を備え、キーボード、マウス、またはマイク等の入力装置やディスプレイ、スピーカ、またはプリンタ等の出力装置と接続されるパーソナルコンピュータ、またはそれらに相当する装置により実現することができる。そして、CPUが、ハードディスクに記憶されるプログラムをメモリに読み出して実行することにより、上記各ユニットの各機能を実現することができる。あるいは、ユーザ端末50は、携帯電話機、PHS(Personal Handyphone System)、PDA(Personal Digital Assistants)、あるいは、ゲーム機など、インターネットに接続するインタフェース部と、表示部および操作部などのユーザインタフェース機能部と、マイクなどの音声入力部と、を有する携帯端末であってもよい。ユーザ端末50は、インターネット上のウェブページにアクセスするためのブラウザ機能(不図示)を有するものとする。
ユーザは、サービス利用に先立ち、必要に応じて、ユーザ端末50からシステムにログインし、ユーザ認証手続きを行う。認証後、システムのウェブページにブラウザを利用してアクセスし、サービス利用のウェブページをユーザ端末50の表示部に表示させて、ユーザはそのウェブページを参照することができることとなる。ユーザ端末50、クライアント10、ウェブサーバ20、制御装置100、および音声認識サーバ40の間のネットワークは図示されていない。これらのネットワークは、特に限定されず、たとえば、LAN(Local Area Network)、WAN(Wide Area Network)、公衆回線網、または携帯電話網等とすることができ、また、有線および無線通信のいずれであってもよい。ユーザ端末50が、ウェブサーバ20にアクセスでき、ウェブサーバ20が、音声認識サーバ40と通信でき、さらに、ユーザ端末50に音声認識結果を返信できればよい。また、後述するように、クライアント10、ウェブサーバ20、音声認識サーバ40、および制御装置100の少なくとも一部が同一のコンピュータで実現される場合、同一コンピュータで実現される装置間でのネットワークは不要である。
本実施形態では、音声認識サービスをウェブ上でユーザに提供する。ユーザ端末50のマイクなどを利用して、ユーザが発話した音声データを入力する。入力された音声データは、ウェブサーバ20にアップロードされ、音声認識サーバ40により音声認識され、その認識結果がユーザ端末50に返信される。そして、ユーザ端末50の表示部に認識結果が表示される。本実施形態では、認識結果は、音声入力から、ほぼリアルタイムにユーザに提示することができる。
本実施形態では、ユーザが発話した音声を音声認識処理し、認識結果をユーザ端末50に単に提示するシステムを例として説明しているが、これに限定されるものではなく、様々な利用シーンが考えられる。
図5に示すように、ウェブサーバ20は、アプリケーション実行部200をさらに備えることができ、アプリケーション実行部200により、以下に示す様々な処理をユーザ端末50から受信した音声データに基づいて音声認識サーバ40が音声認識した認識結果に対し、様々な処理を行い、その結果をユーザ端末50に返信することができる。また、本実施形態では、ユーザ端末50から受信した音声データを音声認識サーバ40により音声認識処理させる構成としたが、これに限定されるものではない。たとえば、ユーザ端末50から受信した音声データを他の音声処理装置により音声処理させ、その結果を転送部118によりに転送する構成とすることもできる。
音声処理とは、たとえば、話者識別処理や、話者認証処理、または、声質変換処理などを含むことができる。これらの音声処理では、処理を施すデータが、少なくとも有音声区間における連続性を有した方が好ましい。そのため、本発明の通信システム1による、一連の音声データの通信処理により、効率よく処理を行うことが可能になる。これらの処理では、たとえば、音声の周波数特徴量を抽出し、所定の音声の音響モデルを用いる。
話者識別処理の例では、所定の話者(たとえば、個人、男女、年齢別、言語別など)の音声の特徴量を予め登録しておき、ユーザ端末50から受信した音声データの特徴量とマッチング処理などにより話者を識別し、識別結果を返信することができる。たとえば、自動音声筆記機能付きの音声チャットアプリケーションにおいて、テキストチャットと同様に、個々の発言の発言者を特定するといった用途に応用できる。話者認証処理の例では、ユーザ毎の音声の特徴量を予め登録しておき、ユーザ端末50から受信した音声データの特徴量とマッチング処理などにより話者ユーザを特定することで、ユーザ認証処理を話者の音声データで行うことができ、認識結果を返信することができる。声質変換処理の例では、所定のボイスチェンジャー処理をユーザ端末50から受信した音声データに施し、声質が変換された音声データを返信することができる。
また、ユーザ端末50から受信した音声データに基づいて音声認識サーバ40が音声認識した認識結果を用いる処理の例として、音声メモ、留守録、通話記録、通話モニタリング、自動翻訳などの音声そのものを蓄積、転送、または利用するシステムにおいて、音声認識技術を利用してそれらの書き起こし、要約、音声全文検索、音声インデキシング、または自動翻訳等を行う処理等が考えられる。たとえば、音声データからの書き起こしを行う例では、ウェブサーバ20からユーザ端末50には、ユーザ端末50から受信した音声データに基づいて音声認識サーバ40が音声認識した認識結果のテキストデータを返信することができる。
また、要約を行う例では、ユーザ端末50から受信した音声データに基づいて音声認識サーバ40が音声認識した認識結果に対して、ウェブサーバ20にて自動要約処理を施し、その結果をテキストデータとして返信することができる。全文検索を行う例では、ユーザ端末50から受信した音声データに基づいて音声認識サーバ40が音声認識した認識結果をキーワードとして、所定のデータベース内のコンテンツやデータを検索処理したり、あるいは、指定されたキーワードを用いて、リアルタイムに得られる認識結果に対して検索処理を行い、その結果を返信することができる。前者の場合、認識結果としては、検索されたコンテンツやデータファイルの格納アドレスやファイル名等とすることができる。後者の場合、認識結果としては、ヒットしたキーワードや、音声データ内のヒット位置(たとえば、時刻情報)、ヒット件数、キーワードを含むフレーズ等とすることができる。
音声インデキシングを行う例では、ユーザ端末50から受信した音声データに基づいて音声認識サーバ40が音声認識した認識結果から、特定の話題や、場面、話者などを見つけ、頭出し位置を抽出し、その位置情報(たとえば、音声データの時刻情報)などを処理結果として返信することができる。
翻訳を行う例では、ユーザ端末50から受信した音声データに基づいて音声認識サーバ40が音声認識した認識結果を所定の他言語に翻訳処理を行い、その結果をテキストデータとして返信することができる。
また、音声認識サーバ40が音声認識した認識結果を、意味解釈や自動アノテーション(タグ付け)などを行う、後続するシステムが処理を行うのに適した形に音声の内容を整形するものが考えられる。意味解釈を行う例では、音声認識サーバ40が音声認識した認識結果が、たとえば、「明日のお昼の3時に」であった場合に、本日が2009年12月21日であれば、「2009/12/22 15:00」のように機械操作容易な形に変換し、その結果を返信することができる。タグ付けを行う例では、音声認識サーバ40が音声認識した認識結果が、たとえば、「明日の打ち合わせ」であった場合に、「明日(日時)の打ち合わせ(イベント)」などに変換することができる。なお、意味解釈とアノテーション処理は、両方の処理を合わせて行うこともできる。
さらに、音声コマンド、ゲームやeラーニングなどの双方向コンテンツの操作、音声による検索クエリ入力など、システムへの指示、操作、またはデータ入力に、音声認識サーバ40が音声認識した認識結果を用いることも考えられる。これらのシステムでは、認識結果に基づいて、ユーザ端末50のユーザの指示、操作、またはデータ入力を受け付け、たとえば、ウェブサーバ20で提供されるシステムが、受け付けた指示、操作、またはデータ入力を解釈した結果や、実行可否判断を行った結果、または、処理を実行した結果をユーザ端末50に返信することができる。
なお、以下の各図において、本発明の本質に関わらない部分の構成については省略してあり、図示されていない。以下の説明において、通信システム1は、一つのユーザ端末50のみが音声認識処理を要求しているものとし、実際はユーザ端末50がウェブサーバ20にアクセスしているが、ここでは、ユーザ端末50の動作は本発明の本質と関係ないので、詳細な説明を省略する。
また、本実施形態の通信システム1の各構成要素は、任意のコンピュータのCPU、メモリ、メモリにロードされた本図の構成要素を実現するプログラム、そのプログラムを格納するハードディスクなどの記憶ユニット、ネットワーク接続用インタフェースを中心にハードウェアとソフトウェアの任意の組合せによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。以下説明する各図は、ハードウェア単位の構成ではなく、機能単位のブロックを示している。
本実施形態の通信システム1は、図2に示すように、音声データを入力して音声処理(音声認識処理)を行い、その処理結果(認識結果)を出力する音声処理装置(音声認識サーバ40)と、TCP(Transmission Control Protocol)上で、HTTP(HyperText Transfer Protocol)を用いて、一連の音声データを順次、一つのセッションにつき複数のコネクション30a、30b、...、30c(以下、特に区別する必要がない場合は、コネクション30と示す。)を利用して並列的に同時にネットワーク(不図示)を介して多重送出する音声データ送出部134、送出された複数の音声データをそれぞれ受信する音声データ受信部102と、音声データ受信部102により複数のコネクション30を利用してそれぞれ受信した複数の音声データの中から一つの音声データを選択し、選択された音声データを順に並べ、音声認識サーバ40にネットワーク(不図示)を介して送信し、音声認識サーバ40により音声認識処理された認識結果を非同期に受信する制御部110と、受信した認識結果を、一つのセッションにつき複数のコネクション30を利用して並列的に同時にネットワークを介して多重転送する転送部118と、を備える。
具体的には、本実施形態の制御装置100は、図2に示すように、音声データ受信部102と、バッファ104と、制御部110と、送信部112と、認識結果受信部114と、バッファ116と、転送部118と、を備える。さらに、クライアント10は、音声受付部130と、バッファ132と、音声データ送出部134と、処理結果受信部140と、バッファ142と、結果出力部144と、を備える。
ウェブサーバ20、音声認識サーバ40、および制御装置100は、たとえば、図示しないCPUやメモリ、ハードディスク、および通信装置を備え、キーボードやマウス等の入力装置やディスプレイやプリンタ等の出力装置と接続されるサーバコンピュータやパーソナルコンピュータ、またはそれらに相当する装置により実現することができる。そして、CPUが、ハードディスクに記憶されるプログラムをメモリに読み出して実行することにより、上記各ユニットの各機能を実現することができる。
なお、図1に示す本実施形態では、クライアント10、ウェブサーバ20、および音声認識サーバ40は、それぞれ1つのみ備える構成としているが、これに限定されない。複数のクライアント10、複数のウェブサーバ20、および複数の音声認識サーバ40を含むことができる。
また、以下に説明するクライアント10の各機能は、ユーザ端末50のプラグインとして、ウェブサーバ20から各ユーザ端末50に提供することができる。たとえば、ユーザ端末50のウェブブラウザで利用可能なActiveX(登録商標)コントロールなどにより実現させることができる。
クライアント10において、音声受付部130は、ユーザ端末50のマイクなどの音声入力部から入力された音声データを受け付ける。バッファ132は、音声受付部130が受け付けた音声データを一時的に格納する。音声データ送出部134は、音声受付部130が受け付けた音声データをバッファ132から読み出し、ウェブサーバ20に送出する。音声データ送出部134は、TCP上で、HTTPを用いて、一連の音声ストリームデータを順次、一つのセッションにつき複数のコネクションを利用して並列的に同時にネットワークを介してウェブサーバ20に多重送出する。本実施形態において、音声ストリームデータ(以下、音声データと呼ぶ)は、TCP上で、HTTPを用いてパケット通信により、順次送信される。
本実施形態において、音声データ送出部134は、一連の音声データを分割した複数のパケットの中から順に同じパケットを複数のコネクション30(図1)を利用して、音声データの複数のパケットをウェブサーバ20に多重送出する。
ここでは、セッションとは、音声データのパケットをクライアント10(ユーザ端末50)からウェブサーバ20に送信するHTTPリクエストから、認識結果のパケットをウェブサーバ20からクライアント10(ユーザ端末50)に返信するHTTPレスポンスまでの一連の通信手順を指すものとする。なお、本実施形態において、クライアント10は、1つのIPアドレスのウェブサーバ20にアクセスし、クライアント10とウェブサーバ20の間で、HTTPによる多重通信を行う。ここで、複数のコネクション30(図1)は、ウェブサーバ20の複数の通信ポート、複数のURL(Uniform Resource Locator)、または、複数のプロセスなどで確立することができる。
本実施形態において、たとえば、1パケットは0.5秒間程度分の音声データを送信できる。クライアント10およびウェブサーバ20間で送受信されるパケットの構成は、一般的なHTTPパケットと同様な情報に加え、本発明に特有な情報を含むことができる。音声データ送信時、たとえば、このパケットが音声データ全体のどの部分なのかを示す音声データ位置情報と、をクライアント10からウェブサーバ20に発信されるHTTPリクエストのヘッダに含むことができる。音声データ位置情報は、一意に音声データパケットを識別できる情報があればよく、たとえば、音声データ先頭からの相対時刻情報や、絶対時刻情報も例としてNTP(Network Time Protocol)のタイムスタンプ等を利用したりできる。あるいは、位置情報は、ブロック長が固定の場合、何個目の音声ブロックであるかを示すように各パケットに順に振られたシリアル番号等、とすることができる。
また、本実施形態のように、複数のユーザ端末50から、複数の音声データが送信される場合、音声データ識別子をさらに含むことができる。この音声データ識別子は、たとえば、ユーザ端末50のIPアドレスや、ユーザIDなどでもよい。
さらに、HTTPリクエストのパケットヘッダには、音声終端情報、音声コーデック情報、音声認識オプション情報、および誤り訂正符号(Error Correcting Code:ECC)等を含むこともできる。音声終端情報は、たとえば、音声認識すべき一連の音声データの最後を示す情報であり、これ以降、音声データが存在しないことを示す。例として、終端フラグ、たとえば、少なくとも1ビット必要であるが、他の情報と合わせて1オクテット(8ビット)となる情報として保持させると、効率がよい。
音声コーデック情報は、たとえば、通信システム1において、ユーザ端末50またはクライアント10、およびウェブサーバ20、制御装置100、または音声認識サーバ40において、複数種類のコーデックを利用可能な場合に必要となる。コーデック処理は、ユーザ端末50またはクライアント10、あるいは、ウェブサーバ20、制御装置100、または音声認識サーバ40のいずれで行ってもよい。
たとえば、複数の音声認識サーバ40毎に異なるコーデック(たとえば、PCM(Pulse Code Modulation)用、FOMA(登録商標)(Freedom Of Mobile multimedia Access)用、およびSkype(登録商標)用など)を準備し、いずれの音声認識サーバ40に受信した音声データを認識処理させるか、受信した音声データが処理されたコーデックの種類に応じて、選択することができる。
たとえば、クライアント10から、ウェブサーバ20に、送信側で利用可能なコーデックの情報を送信し、ウェブサーバ20、制御装置100、または音声認識サーバ40がそのコーデック情報の中から、利用するコーデックを選択し、選択したコーデックの情報をクライアント10に返信する。クライアント10は、ウェブサーバ20、制御装置100、または音声認識サーバ40が選択したコーデックの情報に基づいて、以後、音声データを選択されたコーデックを利用して圧縮して送信する。ウェブサーバ20、制御装置100、または音声認識サーバ40では、選択したコーデックを用いて、受信した音声データを伸張する。なお、コーデック情報は、ユーザ端末50毎に、選択することもできる。この場合、ウェブサーバ20は、ユーザ端末50毎に選択したコーデックを後述する設定記憶部106に登録すればよい。
いずれのコーデックを利用するか、クライアント10側とウェブサーバ20側とで、情報を交換して同じコーデックを利用して、音声データを圧縮および伸張できるようにすることができる。たとえば、クライアント10側またはウェブサーバ20側の何れが先にコーデックの種類を通知してもよいし、何れが先に利用するコーデックを決定してもよい。決定権は、何れが持っていてもよいし、何れか一方に固定的に決めてもよい。たとえば、常にユーザ端末50を優先するなどしてもよい。または、コーデックの確定前にパケットを駄目元で送信してもよいし、事前に音声データを含まないパケットにコーデック情報を載せて情報交換して整合を取ってもよい。あるいは、システムで事前に決定していて固定であれば、情報を交換する必要はない。
さらに、音声データのサンプリングレートの情報や、オーディオデバイスの情報をパケットヘッダに含めて、クライアント10からウェブサーバ20に送信してもよい。また、音声ブロック長が、選択式または可変式の場合、これらの情報をパケットヘッダに含めてもよい。
また、音声認識オプション情報は、たとえば、話者の性別などの声の情報、すなわち、音響モデルを選択するための情報や、発話内容のトピックスやドメインに関するヒント情報など、音声認識辞書や言語モデルを選択するための情報、あるいは、音声認識辞書および言語モデルの指定情報を、パケットヘッダに含めて、クライアント10からウェブサーバ20に送信してもよい。
処理結果受信部140は、ウェブサーバ20から一つのセッションにつき複数のコネクションを利用して並列的に同時にネットワークを介して多重転送された複数の認証結果を受信する。処理結果受信部140は、一つのセッションにつき複数のコネクションを利用してそれぞれ多重転送された複数の処理結果(認証結果)の中から、一番早く到達した認証結果を選択して受信する。バッファ142は、処理結果受信部140が受信した認証結果を一時的に格納する。結果出力部144は、処理結果受信部140が受信した認証結果をユーザ端末50に出力する。ユーザ端末50では、結果出力部144から受け取った認証結果を、たとえば、表示部などに表示することができる。このとき、処理結果受信部140は、クライアント10に到達した順に認識結果を受信するため、本来の順番でない可能性がある。そこで、処理結果受信部140にて再度、順番に並び替えられ、出力される。このとき、認識結果は、後述する認識結果識別情報に基づいて並べ替えることができる。
また、制御装置100において、音声データ受信部102は、ウェブサーバ20がクライアント10を介して各ユーザ端末50から送信された音声データを受信する。
本実施形態において、音声データ受信部102は、TCP上で、HTTPを用いてクライアント10からウェブサーバ20に送信される一連の音声データを順次、一つのセッションにつき複数のコネクション30a、30b、...、30c(図1)(以下、特に区別する必要がない場合は、コネクション30と示す。)を利用して、並列的に同時にクライアント10からウェブサーバ20に多重に送信させ、ウェブサーバ20を介して複数の音声データをそれぞれ受信する。
本実施形態において、音声データ受信部102は、複数のコネクション30(図1)を利用して、クライアント10(ユーザ端末50)から送出された一連の音声データを分割した複数のパケットの中の同じパケットを複数、ウェブサーバ20を介して受信する。
バッファ104は、音声データ受信部102が受信した音声データを一時的に記憶する。設定記憶部106は、各種設定情報を記憶する。たとえば、上述した音声データのコーデック種類を示す情報や、ユーザID、クライアント10やウェブサーバ20のIPアドレス、音声認識サーバ40の音声認識オプション設定などの情報を記憶する。
制御部110は、制御装置100の各ユニットを制御する。本実施形態において、制御部110は、一つのセッションにつき複数のコネクション30(図1)を利用してそれぞれ受信した複数の音声データの中から、一番早く音声データ受信部102が受信した音声データを選択する。さらに、制御部110は、選択された音声データを所定のコーデックで伸張した後、順に並べ、後述する送信部112に、音声認識サーバ40へネットワーク(不図示)を介して送信させるよう指示する。
送信部112は、制御部110の指示に従い、音声データ受信部102が受信した音声データをバッファ104から読み出し、音声認識サーバ40に送信する。なお、送信部112は、音声データとともに、音声認識オプションの指定情報を音声認識サーバ40に送信し、音声認識サーバ40に指定された音声認識オプションで音声認識処理を行わせる。また、通信システム1が、複数の音声認識サーバ40を備えている場合、音声認識処理を複数の音声認識サーバ40に割り振り、処理を分散させることができる。
音声認識サーバ40は、制御装置100の送信部112から送信された音声データに、指定された音声認識オプションに基づいて音声認識処理を施し、制御装置100に認識結果を送信する。音声認識サーバ40の音声認識処理は、特に、本発明の本質に関わらないので、詳細な説明は省略するが、本実施形態では、音声認識サーバ40から出力される認識結果は非同期に制御装置100に返信される。すなわち、音声認識サーバ40は、所定の発話区間毎に音声認識処理を行うが、発話区間によって認識処理にかかる時間が異なる場合があり、先に転送したはずの音声データに対する認識結果の方が、後から転送した音声データに対する認識結果が先に早く制御装置100に届く可能性もある。特に、複数の音声認識サーバ40を用いて音声認識処理を行った場合、この傾向は顕著になる。
制御装置100において、認識結果受信部114は、音声認識サーバ40が音声認識処理した認識結果を非同期に受信する。認識結果は、たとえば、テキストデータである。バッファ116は、認識結果受信部114が受信した認識結果を一時的に記憶する。転送部118は、認識結果受信部114が非同期に受信した認識結果をバッファ116から読み出し、ウェブサーバ20にタイミングよく送信する。具体的には、転送部118は、バッファ116に格納されている認識結果を順に並べ替え、そのとき、音声データ受信部102が受信しているHTTPリクエストに対するレスポンスに順次載せて、ウェブサーバ20を介してクライアント10に多重転送させる。
すなわち、本実施形態において、音声データ受信部102は、クライアント10からのHTTPリクエストを受け付け、音声データのパケットを多重に受信するとともに、転送部118は、音声データ受信部102が受け付けたHTTPリクエストに対する返信として、HTTPレスポンスに音声認識サーバ40から非同期に受信した認識結果を含めて、多重転送する。
本実施形態において、認識結果データ送信時、たとえば、このパケットがどの認識結果データなのかを示す認識結果識別情報をウェブサーバ20からクライアント10に発信されるHTTPレスポンスのヘッダに含むことができる。
本実施形態では、この認識結果識別情報は、一意に認識結果データパケットを識別できる情報があればよく、たとえば、認識結果データが対応する音声データの先頭からの相対時刻情報や、認識結果データの絶対時刻情報もNTPのタイムスタンプ等を利用したりできる。あるいは、認識結果識別情報として、認識結果データに順にシリアル番号を振り識別子としてもよい。
さらに、本実施形態では、HTTPレスポンスのパケットヘッダには、欠落認識結果データ識別情報や、音声認識完了情報を含んでもよい。欠落認識結果データ識別情報は、たとえば、所定の時間内に期待された認識結果データが音声認識サーバ40から制御装置100に到達しない場合に、音声認識サーバ40に対して再送依頼を行うための情報であり、前回受信した認識結果識別情報などを含めて欠落した認識結果データを示して再送を要求する。また、音声データの未着のパケットが存在するが、前後の状況により、無音である可能性が高いと判断された場合には、再送要求を行わないようにすることもできる。なお、上記認識結果識別情報がシリアル番号の場合には、特定のシリアル番号の認識結果のみがなかなか届かないような状況が考えられる。
音声認識完了情報は、音声認識処理が完了したことを示す情報であり、これ以降、音声認識結果が存在しないことを示す。例として、完了フラグ、たとえば、少なくとも1ビット必要であるが、他の情報と合わせて1オクテット(8ビット)となる情報として保持させると、効率がよい。あるいは、サーバステータス情報の一部としての完了ステートを、後述する各種ステータスとして送信してもよい。
さらに、上述したHTTPリクエストのパケットヘッダと同様に、複数のユーザ端末50から、複数の音声データが送信される場合、HTTPリクエストで通知された音声データ識別子に対応する認識結果を返信するとき、対応する音声データ識別子を、HTTPレスポンスにさらに含むことができる。この音声データ識別子は、たとえば、ユーザ端末50のIPアドレスや、ユーザIDなどでもよい。
さらに、HTTPレスポンスのパケットヘッダには、音声認識サーバステータス情報や、音声ステータス情報、欠落音声ブロック識別情報などを含むことができる。音声認識サーバステータス情報は、たとえば、音声認識サーバの処理状況、例として、音声区間検出中、認識処理中、認識完了、エラーなどを含むことができる。さらに、音声認識サーバで既に処理済みの音声ブロックの識別情報を含むことができる。
音声ステータス情報は、たとえば、音声認識サーバ40で処理中の音声データに対する最新の情報、例として、声の大きさ(「小さい」または「大きい」)、速度(「早口」または「遅い」)、雑音が大きい、発話が不明瞭、音量(ボリュームメータ)等の情報を含むことができる。
欠落音声ブロック識別情報は、所定の時間内に期待された音声ブロックがクライアント10からウェブサーバ20に到達しない場合、クライアント10に対して再送依頼を行うための情報であり、前回受信した音声データ識別情報などを含めて欠落した音声データを示して再送を要求する。
クライアント10からウェブサーバ20、またはウェブサーバ20からクライアント10に送信されるデータに含まれる上記の各種情報は、HTTPリクエストやHTTPレスポンスのヘッダに含むことができる。あるいは、所定のフォーマット、たとえば、XML(eXtensible Markup Language)やJSON(JavaScript(登録商標) Object Notation)等に従って、HTTPのコンテンツボディに記載してもよい。音声データや認識結果データは、HTTPのコンテンツボディとすることができる。
また、上述したコーデック情報や音声認識オプション情報、および誤り訂正符号をHTTPレスポンスに含むこともできる。コーデック情報は、クライアント10側とウェブサーバ20側で、事前に情報を交換して同じコーデックを利用して、音声データを圧縮および伸張できるようにするためである。また、音声認識オプション情報は、クライアント10側とウェブサーバ20側で、事前に情報を交換して、音声認識処理のオプションをクライアント10から指定したり、ウェブサーバ20から通知したりするものである。
また、本実施形態において、転送部118が認識結果を転送したとき、転送が正常に完了したか否かを判断する判断部(不図示)と、判断部により認識結果の転送が正常に完了しなかったと判断された場合、転送部118に、別のセッションを用いて認識結果を再送させる再送部(不図示)と、をさらに含むことができきる。
たとえば、上記音声データ送出部134と音声データ受信部102間および転送部118と処理結果受信部140間におけるパケット送受信処理時に、タイムアウト処理を行うことができる。タイムアウト処理は、適宜、様々な手順毎に行うことができる。たとえば、HTTPリクエストに対するレスポンスまでの時間、音声データの受信完了までの時間、音声認識の処理時間、認識結果の転送完了までの時間などを監視し、所定時間以上経過した場合、それぞれ適切な処理を行うことで、エラー発生時や通信速度の低下などによる影響を最小限にとどめることができる。たとえば、一定時間内に音声データの受信や認識結果の送信が完了しなかった場合、制御部110は、送信部112に、エラー通知情報をHTTPレスポンスのヘッダに含めて通信状況をクライアント10に通知させるとともに、送信部112または転送部118に、そのパケットを別のHTTPセッションで再度送受信させるなどの処理を行わせることができる。
また、認識結果が音声認識サーバ40から得られなかった場合、制御部110は、転送部118に、エラー通知情報をHTTPレスポンスのヘッダに含めてクライアント10に向けて返信させる。なお、クライアント10は、音声データを最初に送信した後、制御装置100から認識結果データが返信されるまでの間、所定の時間レスポンスを待機してもよい。また、クライアント10は、認識処理の対象となる音声データを送信し終わった後も、認識処理が完了したことを示す認識完了情報を受信するまで、所定の期間、繰り返しHTTPリクエストを送信し続ける。
本実施の形態の制御装置(クライアント10および制御装置100)は、コンピュータプログラムに対応する各種の処理動作をCPUが実行することにより、前述のような各種ユニットが各種機能として実現される。なお、上述したように、本実施形態の制御装置(クライアント10および制御装置100)の各ユニットの各種機能は、少なくとも部分的に、クライアント10、ウェブサーバ20、または音声認識サーバ40のいずれかで実現させることができる。また、クライアント10、ウェブサーバ20、音声認識サーバ40、および制御装置100のうち少なくとも一部の機能は、同一のコンピュータにより実現させてもよい。いずれの装置でこれらの機能のいずれを実現するかは、特に限定されるものではなく、適宜、変更可能である。
本実施形態のコンピュータプログラムは、制御装置(クライアント10および制御装置100)を実現させるためのコンピュータに、TCP上で、HTTPを用いて、一連の音声データを順次、一つのセッションにつき複数のコネクションを利用して並列的に同時にネットワークを介して多重送出する手順と、送出された複数の音声データをそれぞれ受信する手順と、複数のコネクションを利用してそれぞれ受信した複数の音声データの中から一つの音声データを選択する手順と、選択された音声データを順に並べる手順と、音声データを音声認識サーバ40にネットワークを介して送信する手順と、音声認識サーバ40により音声認識処理された認識結果を非同期に受信する手順と、受信した認識結果を、一つのセッションにつき複数のコネクションを利用して並列的に同時にネットワークを介して多重転送する手順と、を実行させるように記述されている。
なお、本実施形態のコンピュータプログラムは、コンピュータで読み取り可能な記憶媒体に記録されてもよい。記録媒体は特に限定されず、様々な形態のものが考えられる。また、プログラムは、記録媒体からコンピュータのメモリにロードされてもよいし、ネットワークを通じてコンピュータにダウンロードされ、メモリにロードされてもよい。コンピュータプログラムは、クライアント10、ウェブサーバ20、および制御装置100などを実現するためのコンピュータ上で部分的に実行させることができ、これらの手順の各コンピュータへの割り当ては、特に限定されず、プログラム設計時に適宜変更可能であり、また、本発明の本質に関わらないので、詳細な説明は省略する。
上述のような構成において、本実施の形態の制御装置100による通信制御方法を以下に説明する。図3および図4は、本実施形態の通信システム1の動作の一例を示すフローチャートである。以下、図1乃至図4を用いて説明する。
本実施形態の通信制御方法は、TCP上で、HTTPを用いてクライアント10(図1)から送信された一連の音声データを順次、一つのセッションにつき複数のコネクション30(図1)を利用して並列的に同時にネットワークを介して多重送出し(図3のステップS104)、送出された複数の音声データを音声データ受信部102(図2)がそれぞれ受信し(図4のステップS122)、制御部110(図2)が、複数のコネクション30を利用してそれぞれ受信した複数の音声データの中から一つの音声データを選択し(図4のステップS124)、選択された音声データを順に並べ(図4のステップS126)、送信部112(図2)が、音声データを音声認識サーバ40(図2)に送信し(図4のステップS128)、認識結果受信部114(図2)が音声認識サーバ40により音声認識処理された認識結果を非同期に受信し(図4のステップS130)、制御部110(図2)が、転送部118に、受信した認識結果を、一つのセッションにつき複数のコネクション30を利用して並列的に同時にネットワークを介して多重転送する(図4のステップS132)。
図3に示すように、本実施形態のクライアント10において、音声受付部130が、ユーザ端末50にて入力された音声を受け付け(ステップS102)、バッファ132に一時的に格納する。そして、音声データ送出部134が、TCP上で、HTTPを用いて複数のコネクション30を利用して、並列的に同時に音声データを多重に送出する(ステップS104)。そして、処理結果受信部140が、HTTPレスポンスを待つ(ステップS106のNOかつステップS108のNO)。所定時間以内にレスポンスがなかった場合、処理結果受信部140は、タイムアウトを検出し(ステップS106のNOかつステップS108のYES)、音声データ送出部134に再送指示を行い(ステップS110)、ステップS104に戻る。
一方、レスポンスを受信した場合(ステップS106のYES)、処理結果受信部140が、一のセッションにつき複数のコネクション30を利用して、並列的に同時にウェブサーバ20を介して制御装置100から転送された認識結果を多重に受信し(ステップS112)、バッファ142に一時的に格納する。そして、処理結果受信部140は、複数の認識結果の中から一つを選択し、結果出力部144に出力させる(ステップS114)。本実施形態では、処理結果受信部140は、複数の認識結果の中から一番早く到達した処理結果を選択する。
また、図4に示すように、本実施形態の制御装置100において、音声データ受信部102が、クライアント10から送出された複数の音声データを、ウェブサーバ20を介して音声データ受信部102がそれぞれ受信する(ステップS122)。そして、制御部110が、複数のコネクション30を利用してそれぞれ受信した複数の音声データの中から一つの音声データを選択し(ステップS124)、選択された音声データを順に並べる(ステップS126)。そして、送信部112が、音声データを音声認識サーバ40に送信し(ステップS128)、認識結果受信部114が音声認識サーバ40により音声認識処理された認識結果を非同期に受信する(ステップS130)。そして、制御部110が、転送部118に、受信した認識結果を、一つのセッションにつき複数のコネクション30を利用して並列的に同時にネットワークを介して多重転送する(ステップS132)。
このようにして、制御装置100から転送された認識結果は、上述したように、タイミングよくクライアント10によって受信されることとなる。
以上説明したように、本発明の実施の形態の通信システム1によれば、複数のコネクションを利用してデータを同時に並列的に送信することで、あるコネクションで通信エラーや通信速度の低下やパケットのつまりなどが発生しても、他のコネクションで送信されたデータを利用できるので、単一コネクションによる音声データの通信で発生する再送処理が不要となり、通信遅延を回避でき、リアルタイムな効率のよいデータ通信を実現可能にすることができる。
特に、音声認識をネット越しに行い、認識結果をユーザに提示するような音声認識サービス提供システムでは、入力された音声データをシーケンシャルに処理する必要があるため、音声データのパケットは、一つでも到達が遅延したり、抜けがあると音声認識処理が行えない。そのため、確実に全てのパケットを順番に受信して処理する必要がある。本発明では、複数のコネクションでデータを並列的に同時に送信させるので、データの通信遅延を回避でき、かつ音声認識結果の精度も向上する。その結果、精度のよい音声認識結果を遅滞なくユーザに提示させることが可能となり、レスポンス性が向上し、ユーザが満足のいく品質のサービスを提供することができることとなる。
(第2の実施の形態)
図6は、本実施形態の通信システムの構成の一例を示すブロック図である。
本実施形態の通信システムは、上記実施の形態とは、クライアント10からウェブサーバ20に異なる複数の通信経路上でそれぞれ複数のコネクションを確立して、HTTP通信を行う点で相違する。ユーザ端末50、クライアント10、制御装置100、および音声認識サーバ40は、図1および図2の上記実施形態の構成と同様である。
本実施形態の通信システムの制御装置100において、音声データ受信部102(図2)は、複数のウェブサーバ22a、22b、...、22c(以下、特に区別が必要ない場合は、単にウェブサーバ22と呼ぶ。)の異なるIPアドレスにそれぞれ対応する複数のコネクション30a、30b、...、30cを確立して、HTTPを用いて多重通信を行う。
このように構成された本実施形態の通信システム1によれば、上記実施形態と同様な効果を奏するとともに、異なるIPアドレスのウェブサーバ20にアクセスするので、異なる通信経路上に各コネクション30を確立させることができるので、通信経路の通信状況が悪化しても、別の通信経路上のコネクション30を利用してパケットを送受信できるので、パケットを送受信できる可能性がより高くなる。
以上、図面を参照して本発明の実施形態について述べたが、これらは本発明の例示であり、上記以外の様々な構成を採用することもできる。
たとえば、上記実施形態では、音声データ送出部134(図2)は、一連の音声データを分割した複数のパケットの中から順に同じパケットを複数のコネクション30を利用して多重送出する構成としたが、これに限定されない。たとえば、他の実施形態において、音声データ送出部は、一連の音声データを分割した複数のパケットの中から順にパケットをずらしながら、複数のコネクション30を利用して、ウェブサーバ20に多重送出することができる。
この構成によれば、一部のパケットに遅延が生じても、他のコネクションまたは他のセクションにより、受信した他のパケットを利用することができるので、音声認識処理のリアルタイム性を確保できることとなる。特に、音声データのように一つのパケットが抜けただけでも、単語にすると1〜3語程度が認識できなくなってしまうため、遅延パケットを他のパケットで救済できると、音声認識精度が向上するとともに、処理が滞ることもなくより効果的である。
さらに、認識結果データをクライアント10に送信する場合も同様な処理を行える。すなわち、他の実施形態において、図2の転送部118は、認識結果データを分割した複数のパケットの中から順にパケットをずらしながら、複数のコネクション30を利用して送信させ、ウェブサーバ20を介してクライアント10に認識結果データの複数のパケットを受信させることができる。
この構成によれば、たとえば、ノイズなどにより伝送路に障害が発生した場合などに、同時期に同じパケットを多重に送信する形態に比較して、複数のコネクションにおいて同じパケットが欠落する可能性が低くなり、ノイズ障害によって欠落したパケットを他のコネクションで時間をずらして送信されたパケットで救済できる可能性が高くなるという効果がある。
以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
なお、本発明において利用者に関する情報を取得、利用する場合は、これを適法に行うものとする。
1 通信システム
10 クライアント
20 ウェブサーバ
22 ウェブサーバ
30 コネクション
40 音声認識サーバ
50 ユーザ端末
100 制御装置
102 音声データ受信部
104 バッファ
106 設定記憶部
110 制御部
112 送信部
114 認識結果受信部
116 バッファ
118 転送部
130 音声受付部
132 バッファ
134 音声データ送出部
140 処理結果受信部
142 バッファ
144 結果出力部
200 アプリケーション実行部

Claims (17)

  1. 音声データを入力して音声処理を行い、その処理結果を出力する音声処理装置と、
    TCP(Transmission Control Protocol)上で、HTTP(HyperText Transfer Protocol)を用いて、一連の音声データを順次、一つのセッションにつき複数のコネクションを利用して送出する送出手段と、
    送出された複数の前記音声データをそれぞれ受信する受信手段と、
    前記受信手段により複数の前記コネクションを利用してそれぞれ受信した複数の前記音声データの中から一つの音声データを選択し、選択された前記音声データを順に並べ、前記音声データを前記音声処理装置に送信し、前記音声処理装置により音声処理された前記処理結果を非同期に受信する制御手段と、
    受信した前記処理結果を、一つの前記セッションにつき複数の前記コネクションを利用して転送する転送手段と、を備える通信システム。
  2. 請求項1に記載の通信システムにおいて、
    前記音声処理装置は、
    音声データを入力して音声認識処理を行い、その認識結果を出力する音声認識部を含み、
    前記制御手段は、前記受信手段により複数の前記コネクションを利用してそれぞれ受信した複数の前記音声データの中から一つの音声データを選択し、選択された前記音声データを順に並べ、前記音声データを前記音声認識部にネットワークを介して送信し、前記音声認識部により音声認識処理された前記認識結果を非同期に受信し、
    前記転送手段は、前記制御手段により受信した前記認識結果を、一つの前記セッションにつき複数の前記コネクションを利用して転送する通信システム。
  3. 請求項1または2に記載の通信システムにおいて、
    前記制御手段により受信した前記処理結果に基づいて、所定の処理を行い、その結果を前記処理結果として出力する処理手段をさらに備え、
    前記転送手段は、前記処理手段が処理した前記処理結果を入力し、入力した前記処理結果を、一つの前記セッションにつき複数の前記コネクションを利用して転送する通信システム。
  4. 請求項1乃至3いずれかに記載の通信システムにおいて、
    前記制御手段は、前記受信手段により一つの前記セッションにつき複数の前記コネクションを利用してそれぞれ受信した複数の前記音声データの中から、一番早く受信した音声データを選択し、前記音声処理装置に送信する通信システム。
  5. 請求項1乃至3いずれかに記載の通信システムにおいて、
    前記転送手段により、一つの前記セッションにつき複数の前記コネクションを利用してそれぞれ転送された複数の前記処理結果の中から、一番早く到達した処理結果を選択して受信する処理結果受信手段をさらに備える通信システム。
  6. 請求項5に記載の通信システムにおいて、
    前記音声処理を行いたい前記音声データを前記HTTPを用いて送出する前記送出手段と、前記音声処理装置から前記処理結果を受信する前記処理結果受信手段とを有するユーザ端末を備える通信システム。
  7. 請求項1乃至6いずれかに記載の通信システムにおいて、
    前記送出手段は、
    ウェブサーバの1つのIPアドレス、またはウェブサーバの1つのURL(Uniform Resource Locator)に対して複数の前記コネクションを確立して、前記HTTPを用いて通信を行う通信システム。
  8. 請求項1乃至6いずれかに記載の通信システムにおいて、
    前記送出手段は、
    複数のウェブサーバのIPアドレス、またはウェブサーバの複数のURLにそれぞれ対応する複数の前記コネクションを確立して、前記HTTPを用いて通信を行う通信システム。
  9. 請求項1乃至8いずれかに記載の通信システムにおいて、
    前記送出手段は、
    一連の前記音声データを分割した複数のパケットの中から順に同じパケットを複数の前記コネクションを利用して、前記音声データの複数の前記パケットを送出する通信システム。
  10. 請求項1乃至8いずれかに記載の通信システムにおいて、
    前記送出手段は、
    一連の前記音声データを分割した複数のパケットの中から順に前記パケットをずらしながら、複数の前記コネクションを利用して、前記音声データの複数の前記パケットを送出する通信システム。
  11. 請求項1乃至10いずれかに記載の通信システムにおいて、
    前記受信手段は、
    前記送出手段からHTTPリクエストを受け付け、前記音声データを受信し、
    前記転送手段は、
    前記受信手段が受け付けた前記HTTPリクエストに対する返信として、HTTPレスポンスに前記音声処理装置から非同期に受信した前記処理結果を含めて、転送する通信システム。
  12. 請求項11に記載の通信システムにおいて、
    前記HTTPリクエストに対する前記HTTPレスポンスに含める前記処理結果が前記音声処理装置から所定時間経過しても戻って来ない場合、前記転送手段に、前記HTTPレスポンスにエラー通知情報を含めて、転送させる通知手段をさらに備える通信システム。
  13. 請求項1乃至12いずれかに記載の通信システムにおいて、
    前記転送手段が前記処理結果を転送したとき、転送が正常に完了したか否かを判断する判断手段と、
    前記判断手段により前記処理結果の転送が正常に完了しなかったと判断された場合、前記転送手段に、別の前記セッションを用いて前記処理結果を再送させる再送手段と、をさらに備える通信システム。
  14. 請求項1乃至13いずれかに記載の通信システムにおいて、
    前記音声データを入力する音声入力手段をさらに備え、
    前記送出手段は、前記音声入力手段から入力された一連の前記音声データを送出する通信システム。
  15. 音声データを入力して音声処理を行い、その処理結果を出力する音声処理装置に接続される制御装置の通信制御方法であって、
    前記制御装置が、
    TCP(Transmission Control Protocol)上で、HTTP(HyperText Transfer Protocol)を用いて、一連の音声データを順次、一つのセッションにつき複数のコネクションを利用して送出し、
    送出された複数の前記音声データをそれぞれ受信し、
    複数の前記コネクションを利用してそれぞれ受信した複数の前記音声データの中から一つの音声データを選択し、
    選択された前記音声データを順に並べ、
    前記音声データを前記音声処理装置に送信し、
    前記音声処理装置により音声処理された前記処理結果を非同期に受信し、
    受信した前記処理結果を、一つの前記セッションにつき複数の前記コネクションを利用して転送する通信制御方法。
  16. 音声データを入力して音声処理を行い、その処理結果を出力する音声処理装置に、前記音声データをネットワークを介して送信し、前記音声認識装置から出力された前記処理結果を前記ネットワークを介して転送する制御装置を実現するためのコンピュータに、
    TCP(Transmission Control Protocol)上で、HTTP(HyperText Transfer Protocol)を用いて、一連の音声データを順次、一つのセッションにつき複数のコネクションを利用して送出する手順と、
    送出された複数の前記音声データをそれぞれ受信する手順と、
    複数の前記コネクションを利用してそれぞれ受信した複数の前記音声データの中から一つの音声データを選択する手順と、
    選択された前記音声データを順に並べる手順と、
    前記音声データを前記音声処理装置に送信する手順と、
    前記音声処理装置により音声処理された前記処理結果を非同期に受信する手順と、
    受信した前記処理結果を、一つの前記セッションにつき複数の前記コネクションを利用して転送する手順と、を実行させるためのプログラム。
  17. 音声データを入力して音声処理を行い、その処理結果を出力する音声処理装置に接続され、
    TCP(Transmission Control Protocol)上で、HTTP(HyperText Transfer Protocol)を用いて、一連の音声データを順次、一つのセッションにつき複数のコネクションを利用して送出する送出手段と、
    送出された複数の前記音声データをそれぞれ受信する受信手段と、
    前記受信手段により複数の前記コネクションを利用してそれぞれ受信した複数の前記音声データの中から一つの音声データを選択し、選択された前記音声データを順に並べ、前記音声データを前記音声処理装置に送信し、前記音声処理装置により音声処理された前記処理結果を非同期に受信する制御手段と、
    受信した前記処理結果を、一つの前記セッションにつき複数の前記コネクションを利用して転送する転送手段と、を備える制御装置。
JP2009298021A 2009-12-28 2009-12-28 通信システム、制御装置、通信制御方法、およびプログラム Pending JP2011139303A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009298021A JP2011139303A (ja) 2009-12-28 2009-12-28 通信システム、制御装置、通信制御方法、およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009298021A JP2011139303A (ja) 2009-12-28 2009-12-28 通信システム、制御装置、通信制御方法、およびプログラム

Publications (1)

Publication Number Publication Date
JP2011139303A true JP2011139303A (ja) 2011-07-14

Family

ID=44350276

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009298021A Pending JP2011139303A (ja) 2009-12-28 2009-12-28 通信システム、制御装置、通信制御方法、およびプログラム

Country Status (1)

Country Link
JP (1) JP2011139303A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016080036A1 (ja) * 2014-11-21 2016-05-26 株式会社Jvcケンウッド 通信端末装置、通信システム、通信方法

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08186597A (ja) * 1995-01-05 1996-07-16 Nippon Telegr & Teleph Corp <Ntt> 蓄積交換網における転送遅延時間優先転送方法
JP2000261500A (ja) * 1999-03-09 2000-09-22 Fuji Xerox Co Ltd データ通信装置
JP2002185521A (ja) * 2000-12-14 2002-06-28 Nippon Telegr & Teleph Corp <Ntt> ルーティング装置および記録媒体
JP2002527919A (ja) * 1998-10-02 2002-08-27 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワーク調整された会話型サービスを提供するためのシステムおよび方法
JP2003110604A (ja) * 2001-10-02 2003-04-11 Nippon Telegr & Teleph Corp <Ntt> クライアントサーバシステム及びクライアントサーバシステムにおけるデータ通信方法
JP2005012711A (ja) * 2003-06-20 2005-01-13 Sony Corp リアルタイムデータ通信システム、リアルタイムデータ通信装置およびリアルタイムデータ通信方法
WO2006090789A1 (ja) * 2005-02-25 2006-08-31 Softbank Bb Corp. データ通信システム及びデータ通信方法
JP2006319463A (ja) * 2005-05-10 2006-11-24 Matsushita Electric Ind Co Ltd パケット伝送方法及びパケット受信装置

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08186597A (ja) * 1995-01-05 1996-07-16 Nippon Telegr & Teleph Corp <Ntt> 蓄積交換網における転送遅延時間優先転送方法
JP2002527919A (ja) * 1998-10-02 2002-08-27 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワーク調整された会話型サービスを提供するためのシステムおよび方法
JP2000261500A (ja) * 1999-03-09 2000-09-22 Fuji Xerox Co Ltd データ通信装置
JP2002185521A (ja) * 2000-12-14 2002-06-28 Nippon Telegr & Teleph Corp <Ntt> ルーティング装置および記録媒体
JP2003110604A (ja) * 2001-10-02 2003-04-11 Nippon Telegr & Teleph Corp <Ntt> クライアントサーバシステム及びクライアントサーバシステムにおけるデータ通信方法
JP2005012711A (ja) * 2003-06-20 2005-01-13 Sony Corp リアルタイムデータ通信システム、リアルタイムデータ通信装置およびリアルタイムデータ通信方法
WO2006090789A1 (ja) * 2005-02-25 2006-08-31 Softbank Bb Corp. データ通信システム及びデータ通信方法
JP2006319463A (ja) * 2005-05-10 2006-11-24 Matsushita Electric Ind Co Ltd パケット伝送方法及びパケット受信装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016080036A1 (ja) * 2014-11-21 2016-05-26 株式会社Jvcケンウッド 通信端末装置、通信システム、通信方法

Similar Documents

Publication Publication Date Title
US20230246945A1 (en) System and method for client communication in a distributed telephony network
US9761241B2 (en) System and method for providing network coordinated conversational services
KR100430953B1 (ko) 네트워크 협동 대화 서비스를 제공하기 위한 시스템 및 방법
US7821953B2 (en) Dynamically selecting CODECS for managing an audio message
EP2274870B1 (en) Open architecture based domain dependent real time multi-lingual communication service
US20070133523A1 (en) Replay caching for selectively paused concurrent VOIP conversations
US9767802B2 (en) Methods and apparatus for conducting internet protocol telephony communications
WO2017206767A1 (zh) 一种诊断语音时延的方法、网关设备和计算机存储介质
WO2009110158A1 (ja) サービス制御装置、サービス制御システム及び方法
JP2011139303A (ja) 通信システム、制御装置、通信制御方法、およびプログラム
Burnett et al. Media Resource Control Protocol Version 2 (MRCPv2)
EP3039848B1 (en) Methods and apparatus for conducting internet protocol telephony communications
TW564364B (en) System and method for real-time active customer service on internet
JP4925972B2 (ja) メディアアプリケーションサービスシステムおよびメディアアプリケーションサービス方法
Huerta et al. RTTS: Towards Enterprise-level Real-Time Speech Transcription and Translation Services
Burnett Internet-Draft Voxeo Intended status: Standards Track S. Shanmugham Expires: May 18, 2012 Cisco Systems, Inc. November 15, 2011
Burnett Internet-Draft Voxeo Intended status: Standards Track S. Shanmugham Expires: January 12, 2012 Cisco Systems, Inc. July 11, 2011
Burnett et al. RFC 6787: Media Resource Control Protocol Version 2 (MRCPv2)
Burnett Media Resource Control Protocol Version 2 (MRCPv2) draft-ietf-speechsc-mrcpv2-28
Tsourakis et al. An architecture for miultiemodal applications over wireless data networks
Shanmugham Internet-Draft Cisco Systems, Inc. Intended status: Standards Track D. Burnett Expires: September 6, 2007 Nuance Communications March 5, 2007

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120509

A131 Notification of reasons for refusal

Effective date: 20120515

Free format text: JAPANESE INTERMEDIATE CODE: A131

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120717

A131 Notification of reasons for refusal

Effective date: 20120821

Free format text: JAPANESE INTERMEDIATE CODE: A131

A02 Decision of refusal

Effective date: 20130305

Free format text: JAPANESE INTERMEDIATE CODE: A02