JP2016225869A - 情報処理装置、情報処理システム及びプログラム - Google Patents

Abstract

【課題】伝送遅延の影響によって発生する発話の衝突や妨害などのコミュニケーション障害を低減する。
【解決手段】通信Ｉ／Ｆ４２は、発話の開始を通知する第１のコントロールパケットと発話の終了を通知する第２のコントロールパケットと音声パケットを受信する。前記第１のコントロールパケット及び前記第２のコントロールパケットに基づいて通話相手の発話長を算出する。前記第１のコントロールパケット及び先ほど算出した発話長に基づいて発話終了時刻を算出する。算出した発話終了時刻に発話の終了をユーザに通知する。
【選択図】図１０

Description

本発明は、情報処理装置、情報処理システム及びプログラムに関し、特に、ネットワークを介したテレビ会議システム等において通信路に伝送遅延があっても円滑なコミュニケーションを可能にする技術に関する。

インターネット等の通信ネットワークを介して、遠隔地との間でテレビ会議を行う伝送システムが普及している。このような伝送システムでは、複数の伝送端末の間で映像や音声データの送受信が行われることで会議が実現する。

ところが、従来のテレビ会議システムでは、ネットワークを介すことにより、伝送遅延が発生する。このため、自拠点でなされた発話が、相手拠点に到達するまでに時間がかかり、相手拠点からの応答も遅延するため、更に時間がかかるため、自拠点に届く相手拠点からの応答が大きく遅れてしまう。しかし、発話者は遅延があることなど意識して会話をしていないため自拠点での発話直後に相手拠点に到達していると考える。そのため、双方が同時に発話するような、発話の衝突や妨害等のコミュニケーション障害が発生する問題があった。

特許文献１には、ネットワークを介したユーザ同士の会話を円滑に進行させることを目的とした技術が開示されている。特許文献１の映像／音声送受信装置は、拠点Ａの映像／音声データを拠点Ｂに送信し、受信した拠点Ｂで遅延時間を加味した上で、拠点Ｂのローカルの映像／音声と合成し、時間軸上で同期がとれた映像／音声を生成し、その映像／音声を拠点Ａに送信することで、同期のとれた映像を出力するとしている。

特許文献１は、確かに、遅延時間を考慮して、ネットワークを介したユーザ同士の会話を円滑に進行させようとはしている。しかし、両拠点の映像／音声データの同期がとれたとしても、実際に会議を行っている人間の発話と、前記映像とではズレが生じ、コミュニケーション障害が発生する可能性がある。更に言えば、合成用のデータと、相手拠点に表示させるデータを送信する必要があるため、通常の２倍のプロセスになり、さらにデータ量も多くなるのでネットワーク帯域を圧迫する結果になる可能性がある。

本発明は、上記実情に鑑みてなされたものであって、伝送遅延の影響によって発生する発話の衝突や妨害などのコミュニケーション障害を低減することを目的とする。

上記目的を達成するために本発明の第１の装置は、
発話の開始を通知する第１のコントロールパケットと発話の終了を通知する第２のコントロールパケットと音声パケットを受信する通信手段と、
前記第１のコントロールパケット及び前記第２のコントロールパケットに基づいて通話相手の発話長を算出する発話長算出手段と、
前記第１のコントロールパケット及び前記発話長算出手段が算出した発話長に基づいて算出される発話終了時刻に、発話の終了をユーザに通知する発話終了通知手段と、
を有することを特徴とする。

本発明によれば、伝送遅延の影響によって発生する発話の衝突や妨害などのコミュニケーション障害を低減することが可能となる。

本発明が実施されるテレビ会議システム及びテレビ会議端末を示す図である。 図１に示すカメラ６と処理装置４のハードウェア構成を示す図である。 通常の遅延がある場合のテレビ会議システムで発生し得る、発話が衝突するコミュニケーション障害の例を示す図である。 通常の遅延がある場合のテレビ会議システムで発生し得る、発話が妨害されるコミュニケーション障害の例を示す図である。 実施形態１のシステムの送信側ブロック図である。 実施形態１のシステムの受信側ブロック図である。 実施形態１の装置の動作を説明するための図である。 実施形態１における送信側処理のフローチャートである。 実施形態１における受信側処理のフローチャートである。 実施形態２のシステムの受信側ブロック図である。 実施形態２の装置の動作を説明するための図である。 実施形態３のシステムにおける送信側端末の動作を示すフローチャートである。 実施形態における、優先度制御を行うための、コントロールパケットと音声、映像パケットの優先度設定の例を示す図である。 実施形態における通知手段の一例であるインジケータ表示について説明するための図である。

＜実施形態の概要＞
以下、本発明を実施形態により添付図面を参照しながら詳細に説明するが、その前にまず、下記実施形態の概要を述べる。下記の実施形態は、遠隔拠点間で会議を行う、テレビ会議システムにおいて、以下の特徴を有する。

要するに、遠隔拠点間で会議を実現する、テレビ会議システムにおける拠点装置において、コントロールパケットとデータパケットの伝送制御により、音声データ到着以前に発話が相手拠点でなされていることを通知し、更に発話終了通知をする。その結果、伝送遅延の影響によって発生する、双方が同時に発話するような、発話の衝突や妨害等のコミュニケーション障害の発生頻度が低減する。

ここで、好ましくは、音声データより高い優先度の発話開始、終了のコントロールパケットを優先的に伝送する。このことにより、伝送遅延のため受信が遅れる音声データより前に、相手拠点が発話していることを通知することができる。

また、上記発話開始、終了のコントロールパケットの到着時刻の差分から、相手の発話長を算出することができるため、相手の発話が終了するタイミングが容易に判断できる。したがって、伝送遅延の影響によって発生する、コミュニケーション障害をさらに低減させることが可能になる。

＜「コミュニケーション障害」の説明＞
図１に、本発明が実施されるテレビ会議システム及びテレビ会議端末を示す。
図１には、テレビ会議システム１の概略図が示されている。本テレビ会議システム１は、拠点Ａ拠点Ｂ（２拠点以上も可能だが、今回は便宜的に２拠点を想定する）に設置された複数のテレビ会議端末３a、３bと、これらテレビ会議端末が接続されるネットワーク２で構成される。

各拠点のテレビ会議端末３a、３bは、音声入力機構のマイク５、映像入力機構のカメラ６、音声出力機構のスピーカー７、映像出力機構のディスプレイ８などを備え、処理装置４によって音声データや映像データが処理されてネットワーク２を介して、相手側のテレビ会議端末と音声データ、映像データのやり取りを行う。

図２に図１のカメラ６及び処理装置４のハードウェア構成を示す。カメラ６は、被写体が入射するレンズ１０と、レンズ１０によって結像された対象の像をアナログ信号に変換するＣＣＤ(Charge Coupled Device)やＣＭＯＳ(Complementary Metal Oxide Semiconductor)などの画像センサ１１と、アナログ信号をデジタル信号に変換する画像処理部１２と、画像処理された画像データを処理装置１４に送信する画像Ｉ／Ｆで構成される。

処理装置１４は、カメラ６からの画像データを受信する画像Ｉ／Ｆ１５と、種々の処理を行うＣＰＵ１６と、ＣＰＵ１６の処理に必要な各種ソフトデータや、画像データなどを格納するメモリ１７と、自拠点の音声、または相手拠点の音声の入出力を行う音声入出力部１８（音声入力デバイスのマイクや音声出力デバイスのスピーカー等）と、画像データや制御データなどを、ネットワークに接続された相手側端末に送受信する通信Ｉ／Ｆ１９と、装置全体を制御する制御部２０と、相手端末からの受信データを出力する映像出力部２１と、出力した映像を表示するディスプレイ２２で構成される。メモリ１７は、揮発性メモリであるＲＡＭや不揮発性メモリであるＲＯＭなどの総称である。

図３は通常の遅延がある場合のテレビ会議システムで発生し得る、発話が衝突するコミュニケーション障害の例を示す。ここでは、Ａ拠点２４とＢ拠点２５の間に伝送遅延２９があることを想定する。

Ａ拠点２４の発話２６は、伝送遅延２９の影響により、Ｂ拠点２５には２６´のタイミングで到着する。Ｂ拠点２５では、発話２６´に対し、発話２７で即答している。しかし、発話２７も発話２６同様、伝送遅延の影響を受けるため、Ａ拠点２４には２７´のタイミングで到着する。

このとき、Ａ拠点の発話者は、伝送遅延量を把握しているわけではないため、発話２６に対する応答がなかなか来ず、発話２８を開始してしまい、遅延してきたＢ拠点の発話２７´と衝突してしまう。そのため、コミュニケーション障害が発生する。

図４は通常の遅延がある場合のテレビ会議システムで発生し得る、発話が妨害されるコミュニケーション障害の例を示す。図３同様、Ａ拠点２４とＢ拠点２５の間に伝送遅延３３があることを想定する。

図４において、Ａ拠点２４の発話３０は、伝送遅延３３の影響により、Ｂ拠点２５には３０´のタイミングで到着する。Ｂ拠点２５では、発話３０´に対し、発話３１で即答している。しかし、発話３１も発話３０同様、伝送遅延の影響を受けるため、Ａ拠点２４には３１´のタイミングで到着する。

このとき、Ａ拠点の発話者は、伝送遅延量を把握しているわけではないため、発話３０に対する応答がなかなか来ず、発話３２を開始してしまい、ある程度発話進んだタイミングで、遅延してきたＢ拠点の発話３１´に発話を妨害されてしまう。そのため、コミュニケーション障害が発生する。

このコミュニケーション障害は、図３を参照しながら説明したコミュニケーション障害より、ユーザに不快感を与える。さらに、遅延の影響により発生頻度が増加するコミュニケーション障害である。

＜実施形態１＞
図５は、本発明が適用されるシステムの送信側ブロック図である。
テレビ会議システムは、本来インタラクティブにデータの送受信が行われるものであるが、説明を分かり易くするため、送信側端末、受信側端末分けて機能説明する。

送信側テレビ会議端末３５の、音声入力デバイス３６で、発話開始が検知されたことを想定する。発話開始が検知されると、パケット生成手段３８により、音声データより高優先度のコントロールパケットが生成される。また、発話終了が検知されると、パケットパケット生成手段３８により、音声データより高優先度のコントロールパケットが生成される。その後、伝送制御手段３９により、送信するパケット順序が制御され、音声データより早くコントロールパケットが伝送される。

その後、伝送制御されたパケットが、通信Ｉ／Ｆ４０で相手拠点に伝送される。端末内のみでなくインターネット上のルーティングでも同様に、優先的にコントロールパケットが処理されるため、低遅延で相手拠点まで伝送される。優先度は、例えば、ＩＰヘッダのＴｏＳ（Type of Service）フィールドや、ＤＳＣＰ（Differentiated Service Code Point）などで決定される。

図６は、本発明が適用されるシステムの受信側ブロック図である。
受信側テレビ会議端末４１では、送信側端末から送信されてきたデータを通信Ｉ／Ｆ４２で受信する。ここでは、高優先度のコントロールパケットを受信することを想定する。

発話開始のコントロールパケットを受信すると、発話開始判断手段４３により、相手拠点で発話が開始されたことを判断する。発話開始判断がされると、発話開始通知手段４４で発話が開始されたことを通知する。発話開始通知手段４４の具体的手段としては、画面上にメッセージやインジケータ等を表示する手段、ＬＥＤによって通知する手段、ブザーなどの音声で通知する手段、バイブレーションなどで通知する手段がある。

また、発話開始パケットが到着した時刻をメモリ４６に保存しておく。このタイミングはパケットのタイムスタンプ等の情報を用いればよい。発話終了のコントロールパケットを受信すると、発話長算出手段４５で、メモリ４６に保存した発話開始パケットの到着時刻と、発話終了のコントロールパケットが送信側にて生成された時刻の差分から、相手拠点でなされた発話の長さを算出する。

更に、発話終了時間算出手段４７で、音声データ到着時刻に、先程発話長算出手段４５で算出した発話長を加算することで、発話終了時間が算出される。算出された発話終了時刻から、相手の発話がいつ終わるのか判断することができるので、算出した発話終了時刻に、発話終了通知手段４９で発話の終了を通知する。しかしここで、発話終了判断手段４８は、前記発話終了算出手段で算出した発話終了時刻より、前の時刻に次の発話開始パケットを受信していない場合のみ、発話終了と判断する。このように判断することで、発話間隔が短い発話の場合に、毎回終了通知が行われなくなる。

発話終了通知手段４８の具体的手段としては、画面上にメッセージやインジケータ等を表示する手段、ＬＥＤによって通知する手段、ブザーなどの音声で通知する手段、バイブレーションなどで通知する手段がある。

また、発話開始判断の好ましい一例としては、送信側のパケット生成時に、アプリケーションレイヤのメッセージ部等を用いて、１ビットのデータを用意し、１を「発話開始」、０を「発話終了」で示す等して、判断をするという構成が挙げられる。

図７に、本実施形態の装置の動作を説明するための図を示す。ここでは、Ａ拠点５１とＢ拠点５２の間に伝送遅延があることを想定する。

Ａ拠点５１の発話５３は、伝送遅延の影響により、Ｂ拠点５２には５３´のタイミングで到着する。Ｂ拠点５２では、発話５３´に対し、発話５４で即答している。しかし、発話５４も発話５３同様、伝送遅延の影響を受けるため、Ａ拠点５１には５４´のタイミングで到着する。

この時、Ｂ拠点５２の発話５４が開始された直後、高優先度の発話開始のコントロールパケットが生成され、発話５４´の到着より早く、Ａ拠点５１に到着する。Ａ拠点５１では、発話開始のコントロールパケットを受信したら、ユーザに相手が発話中であることを通知手段６３で通知する。

また、Ｂ拠点５２では、発話５４が終了したら、高優先度の発話終了のコントロールパケットが生成され、発話５４´の終了より早く到着する。Ａ拠点では、発話開始パケット５７と発話終了パケット５８の到着時刻の差分６１から、発話長を算出する。また、発話５４´の音声データ到着時刻に、発話長６１を加算することで発話終了時刻を算出し、発話終了時刻に、発話５４´が終了したことを通知手段６４で通知する。この通知があることにより、Ａ拠点５１の発話者は終了タイミングを容易に判断することができ、次の発話５６を適切なタイミングで開始することが可能になる。

またここで、算出した発話終了時刻より前に、次のＢ拠点５２の発話５５の開始パケット５９を受信している場合は、発話終了通知６４は通知されない。ここで、発話終了と判定されない条件は、Ｂ拠点５２の発話と発話の間隔が、音声パケットの遅延量とコントロールパケットの遅延量の時間差より短い場合となる。

図８は、本実施形態における送信側処理のフローチャートである。
・Ｓ１：送信側拠点で、発話開始を検知したか判定する。検知された場合はＳ２に遷移する。
・Ｓ２：Ｓ１で発話が開始されたことを検知したら、音声パケットより、高優先度の発話開始コントロールパケットを生成する。
・Ｓ３：発話終了を検知したか判定する。検知された場合はＳ４に遷移する。
・Ｓ４：Ｓ３で発話が終了したことを検知したら、音声パケットより、高優先度の発話開始コントロールパケットを生成する。
・Ｓ５−１＆Ｓ５−２：Ｓ３、Ｓ４と並列処理し、優先度に応じて、伝送制御し、パケットを送信する。
・Ｓ６：会議が終了したら送信処理を終了する。

図９は、本実施形態における受信側処理のフローチャートである。
・Ｓ１：音声パケットより高優先度の発話開始のコントロールパケットを受信する。
・Ｓ２：Ｓ１で発話開始のコントロールパケットを受信したら、相手拠点が発話中であることを、受信側ユーザに通知する。
・Ｓ３：音声パケットより高優先度の発話終了のコントロールパケットを受信する。
・Ｓ４：Ｓ３で発話終了のコントロールパケットを受信したら、Ｓ２で受信した、発話開始のコントロールパケットと発話終了のコントロールパケットの到着時刻の差分から、発話長を算出する。
・Ｓ５：音声データの到着時刻にＳ４で算出した、発話長を加算し、発話終了時刻を算出する。
・Ｓ６：Ｓ５で算出した発話終了時刻より、前に次の発話開始パケットを受信しているかどうかを判定する。受信している場合は、発話終了を通知しないので、発話終了のコントロールパケットの受信Ｓ３に遷移する。逆に、次の発話開始パケットを受信していない場合は、所定の時刻に発話終了通知を出すＳ８に遷移する。
・Ｓ７：Ｓ５で算出した、発話終了時刻に発話終了を通知する。
・Ｓ８：会議が終了したら受信処理を終了する。

＜実施形態２＞
以下、実施形態１とは一部の構成が異なる実施形態２について説明する。実施形態１と同様の構成を備える部分については重複して説明しない。

図１０は、本実施形態のシステムの受信側ブロック図である。
受信側テレビ会議端末６５では、送信側端末から送信されてきたデータを通信Ｉ／Ｆ４２で受信する。ここでは、高優先度のコントロールパケットを受信することを想定する。

発話開始のコントロールパケットを受信すると、発話開始判断手段４３により、相手拠点で発話が開始されたことを判断する。発話開始判断がされると、発話開始通知手段４４で発話が開始されたことを通知する。通知手段として、画面上にメッセージやインジケータ等を表示する手段、ＬＥＤによって通知する手段、ブザーなどの音声で通知する手段、バイブレーションなどで通知する手段がある。

また、発話開始パケットが到着した時刻をメモリ４６に保存しておく。この時刻はパケットのタイムスタンプ等の情報等を用いればよい。発話終了のコントロールパケットを受信すると、発話長算出手段４５で、メモリ４６に保存した発話開始パケットの到着時刻と、発話終了のコントロールパケットが送信側にて生成された時刻の差分から、相手拠点でなされた発話の長さを算出する。

更に、音声データの到着時刻をメモリ４６に保存しておけば、発話終了時間算出手段４７で、音声データ到着時刻に、先程発話長算出手段で算出した発話長を加算することで、発話終了時間が算出される。算出された発話終了時間より、相手の発話がいつ終わるのか分かるので、発話が終了する時間に、発話終了通知手段４９により、発話の終了を通知する。しかしここで、発話終了判断手段４８は、前記発話終了算出手段で算出した発話終了時刻より前の時刻に、次の発話開始パケットを受信していない場合のみ、発話終了と判断する。

通知手段としては、画面上にメッセージやインジケータ等を表示する手段、ＬＥＤによって通知する手段、ブザーなどの音声で通知する手段、バイブレーションなどで通知する手段がある。

さらに、遅延量検出手段６６によって、音声データと高優先度のコントロールパケットの遅延時間を検出する。検出する方法として好ましくは、アプリケーションレイヤのメッセージ領域に、送信時刻や受信時刻から検出する方法や、それぞれの送受信パケットのタイムスタンプの差分から検出する方法や、音声データやコントロールパケットの疑似データをフリーのアプリケーションで生成して送信する方法等が挙げられる。

遅延量検出手段６６で、音声データと高優先度のコントロールパケットの遅延時間が既知になったら、それらパケットの遅延時間の差分を、差分遅延算出手段６７により算出する。発話到着時刻判断手段６８により、発話開始コントロールパケットの到着時刻に、遅延算出手段６７で算出された遅延時間の差分を加算することで、発話が到着する時刻を判断することが可能となる。

図１１は、本実施形態の装置の動作を説明するための図である。ここでは、Ａ拠点５１とＢ拠点５２の間に伝送遅延があることを想定する。

Ａ拠点５１の発話６９は、伝送遅延の影響により、Ｂ拠点５２には６９´のタイミングで到着する。Ｂ拠点５２では、発話６９´に対し、発話７０で即答している。しかし、発話７０も発話６９同様、伝送遅延の影響を受けるため、Ａ拠点５１には７０´のタイミングで到着する。

この時、Ｂ拠点５２の発話７０が開始された直後、高優先度の発話開始のコントロールパケット７２が生成され、発話７０´の到着より早く、Ａ拠点５１に到着する。Ａ拠点５１では、発話開始のコントロールパケット７２を受信したら、ユーザに相手が発話中であることを通知手段７７で通知する。また、Ｂ拠点５２では、発話７０が終了したら、高優先度の発話終了のコントロールパケット７３が生成され、発話７０´の終了より早く、Ａ拠点５１に到着する。Ａ拠点５１では、発話７０の遅延時間７４と、発話開始のコントロールパケット７２の遅延時間７５の差分７６を算出し、発話開始のコントロールパケットの到着時刻に差分遅延７６を加算することで、Ｂ拠点５２の発話がもうすぐに届くことを通知手段７８で通知する。さらに、図7で説明した通り、発話終了時刻を算出し、通知手段７９で通知する。またここで、Ｂ拠点５２で、発話７０と次の発話の間隔が、音声パケットの遅延時間とコントロールパケットの遅延時間の差分より短い場合は、発話終了通知は、通知手段７９で通知されない。

＜実施形態３＞
以下、前述した実施形態とは一部の構成が異なる実施形態３について説明する。前述した実施形態と同様の構成を備える部分については重複して説明しない。

図１２は、本実施形態のシステムにおける送信側端末の動作を示すフローチャートである。
・Ｓ１：音声遅延と、音声データより高優先度のコントロールパケットの遅延を検出する。
・Ｓ２：検出した音声遅延とコントロールパケットの遅延の差分を求める。
・Ｓ３：発話開始のコントロールパケットを受信する。
・Ｓ４：Ｓ３で発話開始のコントロールパケットを受信したら、発話開始のコントロールパケットを受信した時刻にＳ２で求めた差分遅延を加算し、発話の到着時刻を算出する。
・Ｓ５：発話の到着時刻から、発話の進行状態をインジケータ等で表示する。
・Ｓ６：送信拠点からの発話が到着することを受信側のユーザに通知する。
・Ｓ７：発話終了のコントロールパケットを受信する。
・Ｓ８：Ｓ７で発話終了パケットを受信したら、Ｓ３で受信した発話開始のコントロールパケットの到着時刻と、Ｓ７で受信した発話終了のコントロールパケットの到着時刻の差分から、発話長を算出する。
・Ｓ９：音声データの到着時刻に、Ｓ８で算出した発話長を加算し、発話終了時刻を算出する。
・Ｓ１０：Ｓ５で算出した発話終了時刻より、前に次の発話開始パケットを受信しているかどうかを判定する。受信している場合は、発話終了を通知しないので、発話終了のコントロールパケットの受信するＳ７に遷移する。逆に、次の発話開始パケットを受信していない場合は、所定の時刻に発話終了通知を出すＳ１１に遷移する。
・Ｓ１１：Ｓ９で算出した発話終了時刻に受信側拠点ユーザに発話終了を通知する。
・Ｓ１２：会議が終了したら受信処理を終了する。

＜優先度設定＞
図１３は、優先度制御を行うための、コントロールパケットと音声、映像パケットの優先度設定の例である。本例は、上記実施形態１ないし３のいずれにおいても構成の一部とすることができる。

図１３において、ＩＰヘッダのDiff.Serv ( Differentiated Services )は、ＩＰネットワークにおいて、優先度制御を行っている。このフィールドは、８ｂｉｔのデータであり、上位３ｂｉｔ（DS5、DS4、DS3）が優先度を決めている。この時値が大きい程優先度が高くなり、早く処理される。次の３ｂｉｔ（DS2、DS1、DS0）でパケット廃棄率を、下位２ｂｉｔ（ECN）は未使用ｂｉｔである。

ここで、最上位3bitが、111と110の場合はルーティングプロトコルなどで用いるために使用されるので、ユーザは使用することができない。また101はEF(Expedited Forwarding)と呼ばれ、緊急転送されるクラスである。

これを活かし、上位3bitコントロールパケットには101：緊急転送用のクラス（優先度高）、音声パケットには100：クラス4（優先度中）、映像パケットには000：ベストエフォートクラス（優先度低）のようにする。
上記の構成をとることで、パケットの優先度制御が可能になる。

＜インジケータ表示＞
図１４は、通知手段の一例であるインジケータ表示について説明するための図である。このインジケータ表示の構成は、上記実施形態１ないし３のいずれにおいても構成の一部とすることができる。図１４においては、相手拠点が発話を開始したか、その発話がいつ届くか、そして、いつその発話が終了するかをインジケータ８０で示す。

まず、受信側拠点では、発話開始パケットを受信する。発話開始パケットを受信すると、インジケータの左部に音声レベルを示す棒が現れる（８１）。この時、相手の発話が開始されたことを通知する。この音声信号は時間経過に応じて、右に進行していく（８２）。また、相手の発話が届く時刻を算出し、その時刻からインジケータの右部で相手の発話がもうすぐ届くことを通知する（８３）。更に時間経過し、音声信号が進むと、発話の終了を通知する（８４）。

このようにして、遅延がある伝送路上で、送信側拠点で発話が開始されたこと、送信側拠点でされた発話が、受信側拠点にもうすぐ届くこと、さらに、その発話がもうすぐ終了することを通知することで、受信側拠点では、発話のタイミングが正確に判断できるため、発話が衝突することや、発話が妨害されるようなコミュニケーション障害を低減することが可能である。

＜発話長算出の異なる実施例＞
実施形態１〜３では、発話長算出手段４５が送信側での発話の長さを算出するにあたって、発話開始のコントロールパケットが受信側に到着した時刻を起点に算出している。他方、起点を送信側でコントロールパケットを生成した時刻としてもよい。この場合は、図５のパケット生成手段３８が、図１３に示すようなコントロールパケットを生成する際に、DATEフィールドに送信側装置（テレビ会議端末３）のタイムスタンプを刻印する。

この変形例によれば、受信側で発話開始パケットが到着した時刻をメモリ４６に保存しておく必要がなくなり、受信側のメモリ使用量や制御負荷を抑えることができる。また、この変形例においては、発話終了の時刻についても発話終了のコントロールパケットのDATEフィールドなどに当該パケットの生成時刻を刻印し、受信側の発話長算出手段４５が刻印された時刻を用いて発話長を算出することも好ましい。この構成の場合、通信路の状態にあまり左右されない発話長を算出することが可能になる。

他方、発話の起点を発話開始のコントロールパケット生成時に置き、且つ、発話の終点を発話終了のコントロールパケットの受信側到着時に置く構成とした場合は、伝送遅延を考慮すると、発話長算出手段４５が算出する発話長が最も長くなる可能性が高くなる。したがって、発話の衝突や妨害等のコミュニケーション障害を低減するという課題を解決するための構成としては、発話の終点を発話終了のコントロールパケット生成時に置く構成よりも好ましい。すなわち、より長く、送信側で発話中であることを示す通知を出し続けることになるので、コミュニケーション障害をさらに低減することができる。

＜作用効果＞
以上に開示した技術の作用効果について述べる。
実施形態１によれば、コントロールパケットとデータパケットの伝送制御により、音声データ到着以前に発話が相手拠点でなされていることを通知し、更に発話終了通知をすることで、伝送遅延の影響によって発生する、双方が同時に発話するような、発話の衝突や妨害等のコミュニケーション障害を低減することができる。

また、実施形態２によれば、相手の発話開始タイミングがより正確に判り易くすることができるので、コミュニケーション障害を低減する効果がある。

また、上述したインジケータ表示によれば、疑似音声波形をディスプレイに表示することができ、視覚的フィードバックを与える手段を有することになるので、相手拠点が発話中であることを分かり易くすることができる。
また、インジケータ表示が警告音のような、音声波形を模した視覚的フィードバックとして構成されることで、相手拠点が発話中であることをさらに分かり易くすることができる。
また、実施形態中で言及したように、ユーザに通知する手段としてインジケータ表示のような視覚的フィードバックに代えて、又は、視覚的フィードバックに加えて、バイブレーション等の触覚的フィードバックを与えることとした場合も、相手拠点が発話中であることをさらに分かり易くすることができる。

また、図１３を参照しながら説明したような優先度設定が発話開始又は終了を示すコントロールパケットに対して設定されることで、音声パケット（実施形態では映像パケットも含む）よりも早く受信側拠点へコントロールパケットが届くと考えられる。そのため、遅延が生じがちな通信路であっても、いち早く発話終了が受信側へ通知され、発話終了が予想される時刻の算出が可能になる。

さらに、図７の発話５５のように、送信側の発話５４が一度途切れた後にさらにつづけられた場合でも、発話５５の発話開始が発話の開始パケット５９によりいち早く受信側に届けることができる。そのため、発話終了通知６４がなされる前に、発話終了通知６４を行わないように判断することができる。図４を参照しながら説明した遅延に起因する発話の妨害を未然に防ぐことが可能になると考えられ、ユーザの不快感を抑えることができる。
言い換えれば、短い間がある発話の時に、毎回発話終了通知がされないので煩わしくないという効果がもたらされる。

なお、発話終了判断手段４８が「発話が終了したか否かを判断する」ないし「発話終了通知手段４９に発話の終了をユーザに通知させるか否かを判断する」判断プロセスは、図４を参照しながら説明した遅延に起因する発話の妨害が起きるケースを防ぐために、以下の構成を備えることが好ましい。
すなわち、前の通話の、算出により予想される発話終了時刻と、後の発話の開始を受信側に通知するコントロールパケットに基づいて把握される後の発話の発話開始時刻とに基づいて、判断すること。
この構成においては、さらに好ましくは、後者が前者に先行する場合は、「発話が終了しないと判断する」か「発話終了をユーザに通知しない」構成とするとよい。
以上に述べた構成によれば、短い間がある発話の時に、毎回発話終了通知がされないので煩わしくないという効果がもたらされる。

また、上述した各実施形態は、受信側の構成だけでなく図５に示したような送信側の構成も備えていることが好ましい。テレビ会議システムに参加する各ノードがそのような構成であれば、同一セッション上の、全ての端末に対してコミュニケーション障害を低減させる効果を与えることができる。
なお、上述の効果は、実施形態中で説明した各機能、各構成をコンピュータに実行させるためのプログラムによってももたらすことができる。

４２ 通信Ｉ／Ｆ
４３ 発話開始判断手段
４４ 発話開始通知手段
４５ 発話長算出手段
４７ 発話終了時間算出手段
４８ 発話終了判断手段
４９ 発話終了通知手段
６６ 遅延量検出手段
６７ 差分遅延算出手段
６８ 発話到着時刻判断手段

特開２０１２−０５４６９３号公報

Claims (9)

1. 発話の開始を通知する第１のコントロールパケットと発話の終了を通知する第２のコントロールパケットと音声パケットを受信する通信手段と、
   前記第１のコントロールパケット及び前記第２のコントロールパケットに基づいて通話相手の発話長を算出する発話長算出手段と、
   前記第１のコントロールパケット及び前記発話長算出手段が算出した発話長に基づいて算出される発話終了時刻に、発話の終了をユーザに通知する発話終了通知手段と、
   を有することを特徴とする、情報処理装置。
2. 音声パケットの遅延時間と前記第１のコントロールパケットの遅延時間を検出する遅延検出手段と、
   前記遅延検出手段によって検出された遅延時間の差分を算出する差分遅延算出手段と、
   前記第１のコントロールパケット到着時刻に前記差分遅延算出手段で算出された遅延時間の差分を加算し、伝送後の音声データの到着時刻を判断する発話到着時刻算出手段と、
   を有することを特徴とする、請求項１に記載の情報処理装置。
3. 前記第１のコントロールパケットに基づいて通信相手先における発話の開始を判断する発話開始判断手段と、
   前記発話開始判断手段により通信相手先における発話の開始が判断された場合に、その旨をユーザに通知する発話開始通知手段と、
   を有することを特徴とする、請求項１又は２に記載の情報処理装置。
4. 前記発話終了通知手段は、ユーザに聴覚的フィードバックを与えることを特徴とする、請求項１から３のいずれか１項に記載の情報処理装置。
5. 前記第１のコントロールパケット及び前記第２のコントロールパケットは、通信路において前記音声パケットよりも優先的に制御が行われるように設定されたパケットであることを特徴とする、請求項１から４のいずれか１項に記載の情報処理装置。
6. 前の発話の前記発話終了時刻と、次の発話の開始を通知する前記第１のコントロールパケットとに基づいて、前の発話の終了をユーザに通知するか否かを判断する発話終了判断手段を有することを特徴とする、請求項１から５のいずれか１項に記載の情報処理装置。
7. 前記第１のコントロールパケットと前記第２のコントロールパケットを生成するパケット生成手段を備え、
   前記通信手段は、生成した前記第１のコントロールパケットと前記第２のコントロールパケットを通話相手先の情報処理装置に対して送出する
   ことを特徴とする、請求項１から６のいずれか１項に記載の情報処理装置。
8. ネットワーク上の複数の情報処理装置からなる情報処理システムであって、
   前記情報処理装置の各々は、
   発話の開始を通知する第１のコントロールパケットと発話の終了を通知する第２のコントロールパケットを生成するパケット生成手段と、
   前記第１のコントロールパケットと前記第２のコントロールパケットと音声パケットを受信する通信手段と、
   前記第１のコントロールパケット及び前記第２のコントロールパケットに基づいて通話相手の発話長を算出する発話長算出手段と、
   前記第１のコントロールパケット及び前記発話長算出手段が算出した発話長に基づいて算出される発話終了時刻に、発話の終了をユーザに通知する発話終了通知手段と、
   を有することを特徴とする、情報処理システム。
9. コンピュータを、
   発話の開始を通知する第１のコントロールパケットと発話の終了を通知する第２のコントロールパケットと音声パケットを受信する通信手段と、
   前記第１のコントロールパケット及び前記第２のコントロールパケットに基づいて通話相手の発話長を算出する発話長算出手段と、
   前記第１のコントロールパケット及び前記発話長算出手段が算出した発話長に基づいて算出される発話終了時刻に、発話の終了をユーザに通知する発話終了通知手段
   として機能させるための、プログラム。

Images