コミュニケーション装置およびコミュニケーションシステム
【課題】任意のタイミングで、その場の雰囲気を容易に知ることを可能にする。
【解決手段】コミュニケーションサーバは、コミュニケーション装置からオーディオストリームを受信すると、１０秒毎に、その時点から過去に１５秒遡った時点までの区間内のデータを抽出し、処理区間データが特徴部分音響データ要素になり得るものかどうか判定する。その結果、なり得るものであれば、当該処理区間データに基づいて特徴部分音響データ要素が生成され、なり得ないものであり、非特徴部分音響データ要素として記録すると決定されれば、当該処理区間データに基づいて非特徴部分音響データ要素が生成され、端末ＩＤに対応付けて記録される。オーディオストリームの受信から１日経過すると、コミュニケーションサーバは、音響データ要素の中から１８個を抽出し、それらを結合して音場データを生成し、端末ＩＤに対応付けて記録する。
【解決手段】コミュニケーションサーバは、コミュニケーション装置からオーディオストリームを受信すると、１０秒毎に、その時点から過去に１５秒遡った時点までの区間内のデータを抽出し、処理区間データが特徴部分音響データ要素になり得るものかどうか判定する。その結果、なり得るものであれば、当該処理区間データに基づいて特徴部分音響データ要素が生成され、なり得ないものであり、非特徴部分音響データ要素として記録すると決定されれば、当該処理区間データに基づいて非特徴部分音響データ要素が生成され、端末ＩＤに対応付けて記録される。オーディオストリームの受信から１日経過すると、コミュニケーションサーバは、音響データ要素の中から１８個を抽出し、それらを結合して音場データを生成し、端末ＩＤに対応付けて記録する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザの音声を含む周囲の音声を集音し、音響信号として入力して外部に出力するとともに、外部から入力された音響信号を音響に変換して出力するコミュニケーション装置およびコミュニケーションシステムに関する。
【背景技術】
【０００２】
ユーザの音声を含む周囲の音声を集音し、音響信号として入力して外部に出力するとともに、外部から入力された音響信号を音響に変換して出力する装置は、従来から知られている。
【０００３】
このような装置として、たとえば宅内に居る子供や老人、ペット等の状況を宅外から見守るために宅内の撮像画像を宅外から確認可能とする遠隔見守りシステムがある（たとえば、特許文献１参照）。この遠隔見守りシステムは、宅内の様子を宅外から確認可能とする一般的な宅内見守りサービスに加え、宅内装置同士で画像および音声による交信を可能とするＴＶ電話機能サービスを提供する。特許文献１の図２に示されるように、宅内装置２は、電源スイッチ２６がオンの状態で監視スイッチ２７がオン操作されることにより、カメラ２１および人体センサ２６により宅内の様子を監視する監視モードで動作する。一方、監視スイッチ２７がオフのときには、監視モードでの制御は行わず、アイドルモード（操作待ち状態）での制御を行う。そして制御部３１は、アイドルモード時において、宅内装置２同士でのＴＶ電話機能の動作を可能とする。なお特許文献１には、ＴＶ電話機能は、アイドルモード時に限られず、監視モード時に交信キー８１が押下されたことを受けて、宅内装置２同士のＴＶ電話機能を開始するようにしてもよいとも記載されている。
【０００４】
また、会議音声等の音声を記録して利用する音声データ記録再生装置がある（たとえば、特許文献２参照）。この音声データ記録再生装置では、特定の話者の発言区間を検出し、その発言区間以外を話速変換して高速再生することにより、効率よく注目話者の発言内容およびその前後の会議の様子を把握できるようにしている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１１５３７５号公報
【特許文献２】特開２００７−２９８８７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、任意のタイミングで、その場、つまり集音装置の置かれた場所の雰囲気（全体の様子）を知りたいという要望がある。たとえば、遠隔地に住む祖父母が、孫の住む家の１日の様子（雰囲気）を知りたいという要望である。
【０００７】
しかし、このような要望には、上記従来の装置のいずれを用いても応えることはできなかった。上記遠隔見守りシステムでは、ＴＶ電話機能が動作しているときにのみ相手の宅内の雰囲気をうかがい知ることができるに過ぎず、一方、上記音声データ記録再生装置では、会議を行っている時間帯にのみその場の雰囲気をうかがい知ることができるに過ぎないからである。
【０００８】
本発明は、この点に着目してなされたものであり、任意のタイミングで、その場の雰囲気を容易に知ることが可能となるコミュニケーション装置およびコミュニケーションシステムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、請求項１に記載のコミュニケーション装置は、ユーザの音声を含む周囲の音声を集音し、音響信号として入力する入力手段と、音響信号を音響に変換して出力する出力手段と、通信ネットワークを介して接続されたコミュニケーションサーバおよび他のコミュニケーション装置と双方向にデータを通信するための通信手段と、第１および第２の処理命令を含む複数の処理命令を取得する取得手段と、前記取得手段によって前記第１の処理命令が取得された場合には、前記他のコミュニケーション装置に、前記入力手段によって入力された音響信号を前記通信手段を介して送信するように制御する一方、前記取得手段によって前記第２の処理命令が取得された場合には、前記コミュニケーションサーバから前記通信手段を介して音場データを受信し、該音場データを前記出力手段に供給することにより、当該音場データに基づく音響を出力するように制御する制御手段とを有することを特徴とする。
【００１０】
請求項２に記載のコミュニケーション装置は、請求項１のコミュニケーション装置において、前記コミュニケーションサーバから受信する音場データは、前記入力された音響信号が前記通信手段を介して前記コミュニケーションサーバに送信され、該コミュニケーションサーバが当該音響信号に基づいて生成したものであることを特徴とする。
【００１１】
請求項３に記載のコミュニケーション装置は、請求項１のコミュニケーション装置において、前記入力された音響信号に基づいて音場データを生成する生成手段をさらに有し、前記コミュニケーションサーバから受信する音場データは、前記生成手段によって生成された音場データが前記通信手段を介して前記コミュニケーションサーバに送信されたものであることを特徴とする。
【００１２】
上記目的を達成するため、請求項４に記載のコミュニケーションシステムは、少なくとも１つの請求項２に記載のコミュニケーション装置とコミュニケーションサーバとからなるコミュニケーションシステムであって、前記コミュニケーションサーバは、前記コミュニケーション装置から音響信号を入力する入力手段と、特定の時間内に受信した音響信号の中から、複数の部分音響信号を選択し、該選択した複数の部分音響信号を組み合わせることにより、音場データを生成する生成手段と、前記コミュニケーション装置からのリクエストに応じて、前記生成手段によって生成された音場データを前記コミュニケーション装置に送信する送信手段とを有することを特徴とする。
【発明の効果】
【００１３】
請求項１または４に記載の発明によれば、コミュニケーションサーバから音場データを受信し、該音場データを出力手段に供給することにより、当該音場データに基づく音響が出力されるので、音場データが任意のタイミングで、その場の雰囲気を集音して生成されたものであれば、任意のタイミングで、その場の雰囲気を容易に知ることが可能となる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施の形態に係るコミュニケーション装置の概略構成を示すブロック図である。
【図２】図１のコミュニケーション装置およびコミュニケーションサーバの各機能構成を示すブロック図である。
【図３】音場データ生成・記録処理を説明するための図である。
【図４】図１のコミュニケーション装置、特にＣＰＵが実行するメインルーチンの手順を示すフローチャートである。
【図５】図１のコミュニケーションサーバ、特にＣＰＵが実行する音響データ要素のピックアップ処理の手順を示すフローチャートである。
【図６】図１のコミュニケーションサーバ、特にＣＰＵが実行する音場データ生成・記録処理の手順を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。
【００１６】
図１は、本発明の一実施の形態に係るコミュニケーション装置１００の概略構成を示すブロック図である。
【００１７】
同図に示すように、コミュニケーション装置１００は、ユーザの音声を含む周囲の音声を集音し、集音して得られたアナログ音響信号をデジタル音響信号（以下、「音響データ」という）に変換して入力する音響入力部１０１と、コミュニケーション装置１００に対するユーザの動作を検知するためにコミュニケーション装置１００の姿勢を検出する姿勢検出部１０２と、装置全体の制御を司るＣＰＵ１０３と、該ＣＰＵ１０３が実行する制御プログラムや、各種テーブルデータ等を記憶するＲＯＭ１０４と、各種入力情報および演算結果等を一時的に記憶するＲＡＭ１０５と、通信ネットワーク２００を介して、コミュニケーションサーバ３００、他のコミュニケーション装置（端末）４００および設定装置５００とデータの送受信を行う通信インターフェース（Ｉ／Ｆ）１０６と、音響データをアナログ音響信号に変換し、さらに音響に変換して外部に出力する音響出力部１０７とにより構成されている。
【００１８】
上記構成要素１０１〜１０７は、バス１０８を介して相互に接続され、通信Ｉ／Ｆ１０６には通信ネットワーク２００が接続されている。
【００１９】
音響入力部１０１は、集音マイクやアンプ、ＡＤＣ（analog-to-digital converter）等によって構成されている。集音マイクは、本実施の形態では、周囲の雰囲気（音響）を集音する第１のマイクと、ユーザの音声を集音する第２のマイクとからなる。第１のマイクは、１つであってもよいが、複数個備えるようにして、音場特性（音場定位や奥行き感）を再現可能な音響データを入力する方が好ましい。第２のマイクは、１つあればよい。なお、２種類のマイクを設けずに、１種類のマイクで周囲の雰囲気の集音とユーザの音声の集音を兼用させるようにしてもよい。
【００２０】
音響入力部１０１から入力された音響データは、バス１０８を通ってＲＡＭ１０５に供給され、ＲＡＭ１０５内に設けられたバッファ領域（図示せず）に一時的に格納される。バッファ領域は、第１のマイクから入力された音響データを格納するものと、第２のマイクから入力された音響データを格納するものが設けられている。ＲＡＭ１０５としては、通常通り揮発性のものを採用すればよいが、これに限らず、不揮発性のもの、たとえばフラッシュメモリを採用してもよい。フラッシュメモリを採用した場合には、ＲＯＭ１０４に記憶するプログラムやデータもフラッシュメモリに格納するようにして、各内容を書き換え可能にしてもよい。
【００２１】
姿勢検出部１０２は、加速度センサやジャイロスコープ (gyroscope) などによって構成され、ユーザがコミュニケーション装置１００を叩いたり、揺らしたり、上下に移動させたりする動作に応じた信号（以下、「姿勢信号」という）を検出する。姿勢検出部１０２からの姿勢信号に基づいて検出されるユーザの動作は、本実施の形態では、コミュニケーション装置１００の動作モードを移行させるコマンドに対応付けられており、あるコマンドを入力する場合、ユーザは、そのコマンドに対応付けられた動作をコミュニケーション装置１００に対して行う。ただし、コマンドの入力は、音響入力部１０１から入力されたユーザの音声を認識することによっても行うことができるので、つまり、姿勢検出部１０２は常に必須の構成要素ではなく、省略することもできるので、図１の姿勢検出部１０２のブロックは、破線で表現されている（図２でも同様）。なお、入力されたコマンドを検知（認識）したことを、音響出力部１０７より出力される音響や、ＬＥＤ（light emitting diode）などの発光手段、バイブレータなどの振動手段を用いて報知するようにしてもよい。
【００２２】
ＣＰＵ１０３には、タイマが内蔵されている。タイマは、本実施の形態では後述するように、音響データをコミュニケーションサーバ３００に送信する際に、音響データ（のパケット）に付加するタイムスタンプを生成するために用いられる。もちろん、その他の時間の計時や、タイマ割込み処理における割込み時間の計時にも用いられる。
【００２３】
音響出力部１０７は、ＤＡＣ（digital-to-analog converter）、アンプおよびスピーカ等によって構成されている。スピーカは、前記第１のマイクと同様に、１つであってもよいが、音場特性を再現可能な音響データに基づいて音響を出力する場合には、複数のスピーカを設けて、当該音場特性を再現する方が好ましい。
【００２４】
通信ネットワーク２００としては、たとえば、ＩＥＥＥ８０２.１１やＢｌｕｅｔｏｏｔｈ（登録商標）などの無線ＬＡＮ（local area network）、ＵＳＢ（universal serial bus）やＩＥＥＥ１３９４、Ｅｔｈｅｒｎｅｔ（登録商標）などの有線ＬＡＮ、インターネットを挙げることができる。本実施の形態では、コミュニケーション装置１００は、コミュニケーションサーバ３００および他の端末４００とはインターネットを介して接続され、設定装置５００とは無線ＬＡＮを介して接続されているものとする。もちろんこれに限らず、通信ネットワーク２００は、単方式のネットワークによって構成されていてもよいし、３方式以上のネットワークによって構成されていてもよい。
【００２５】
なおコミュニケーション装置１００は、本実施の形態では単体の装置として構成したが、これに限らず、複数の装置を組み合わせて構成してもよい。たとえば、音響入力部１０１および音響出力部１０７からなる入出力デバイスと、ＣＰＵ１０３、ＲＯＭ１０４ＲＡＭ１０５および通信Ｉ／Ｆ１０６からなるクレードルとによって構成し、両者を無線または有線などの任意の接続方法で接続するという実施形態が考えられる。
【００２６】
コミュニケーションサーバ３００は、一般的なサーバ用コンピュータ、具体的には、コミュニケーション装置１００の上記図１の構成から、音響入力部１０１、姿勢検出部１０２、音響出力部１０７を除き、その代わりに、キーボード、マウス、大型ディスプレイおよび記憶装置を加えたものによって構成される。ただし、コミュニケーションサーバ３００のＣＰＵ，ＲＯＭおよびＲＡＭは、コミュニケーション装置１００のＣＰＵ１０３，ＲＯＭ１０４およびＲＡＭ１０５と比較して、その能力や容量が格段に異なっている。
【００２７】
なおコミュニケーションサーバ３００は、本実施の形態では単体の装置として構成したが、これに限らず、適宜分散構成あるいはクラウド構成としてもよい。
【００２８】
他の端末４００は、本実施の形態ではコミュニケーション装置１００の動作と同様の動作を行うので、他の端末４００のハードウェアは、コミュニケーション装置１００のそれ、つまり図１のハードウェアと同様に構成されている。
【００２９】
設定装置５００は、本実施の形態では一般的なＰＣ（パーソナルコンピュータ）によって構成されている。コミュニケーション装置１００は、設定装置５００を、前述のように無線ＬＡＮでコミュニケーション装置１００に接続し、ユーザが設定装置５００上で設定したものをコミュニケーション装置１００に送信することで、コミュニケーション装置１００の各種設定ができるようにしている。ここで、各種設定としては、たとえば、目的のネットワークに接続するために通信Ｉ／Ｆ１０６に対して行う設定、コミュニケーションサーバ３００を特定するための設定（アドレスやＩＤ（identification）など）、対話モード（その内容は、後述する）で通信する相手を特定するための設定（アドレスやＩＤなど）などを挙げることができる。なお各種設定を行うために、コミュニケーション装置１００にその入力手段を設けてもよいし、あるいは姿勢検出や音声認識にて行ってもよいので、つまり、設定装置５００は本発明のために必須の構成要素ではないので、図１の設定装置５００のブロックは、破線で表現されている（図２でも同様）。
【００３０】
なお本実施の形態では、コミュニケーションサーバ３００および他の端末４００はいずれも、１台のみとしたが、もちろんこれに限らず、それぞれ複数台設けるようにしてもよい。
【００３１】
以上のように構成されたコミュニケーション装置１００およびコミュニケーションサーバ３００が実行する制御処理を、まず図２および図３を参照してその概要を説明し、次に図４〜図６を参照して詳細に説明する。
【００３２】
図２（ａ）は、コミュニケーション装置１００の機能構成を示すブロック図であり、図中、図１のブロックと同一のブロックには、同一の符号が付与されている。
【００３３】
図２（ａ）において、制御部１００ａは、ＣＰＵ１０３、ＲＯＭ１０４およびＲＡＭ１０５によって構成され、動作モードとして、少なくとも待機モード、対話モードおよび音場モードの３種類のモードを備えている。
【００３４】
待機モードは、コミュニケーション装置１００の電源がオンされたときに選択される初期モードである。待機モードが選択されると、制御部１００ａは、音響入力部１０１（特に、前記第１のマイク）から入力された音響データを、通信Ｉ／Ｆ１０６および通信ネットワーク２００を介してコミュニケーションサーバ３００に送信する送信処理を開始する。この送信処理が開始されると、電源がオフされない限り、送信処理は停止されないので、連続して入力された音響データはそのまま連続して送信される。つまり、音響データはオーディオストリームを形成する。このため、上記送信処理を、以下「オーディオストリーム送信処理」という。
【００３５】
対話モードは、コミュニケーション装置１００と他の端末４００との間でそれぞれのユーザが対話するときに選択されるモードである。対話モードが選択されると、制御部１００ａは、音響入力部１０１（特に、前記第２のマイク）から入力された音響データ（ユーザの音声データ）を、通信Ｉ／Ｆ１０６および通信ネットワーク２００を介して他の端末４００に送信するとともに、他の端末４００から出力された音響データ（ユーザの音声データ）を、通信ネットワーク２００および通信Ｉ／Ｆ１０６を介して受信し、音響出力部１０７に供給する送受信処理を開始する。この送受信処理が開始されると、他のモードに切り換えられたり、対話が所定時間途切れたりしない限り、送受信処理は停止されないので、連続して入力された音響データはそのまま連続して送信される一方、連続して受信された音響データはそのまま連続して音響出力部１０７に供給される。つまり、音響データはオーディオストリームを形成する。このため、上記送受信処理を、以下「オーディオストリーム送受信処理」という。このオーディオストリーム送受信処理で用いる通信方式は、本実施の形態では、ＶｏＩＰ（Voice over Internet Protocol）を採用するが、これに限られる訳ではない。
【００３６】
音場モードは、コミュニケーションサーバ３００から音場データ（図３（ｂ）参照）を受信して再生するときに選択されるモードである。音場モードが選択されると、制御部１００ａは、音場データの要求を、通信Ｉ／Ｆ１０６および通信ネットワーク２００を介してコミュニケーションサーバ３００に送信し、これに応じてコミュニケーションサーバ３００が送信した音場データを、通信ネットワーク２００および通信Ｉ／Ｆ１０６を介して受信し、この音場データを再生する再生処理を実行する。音場データの再生が開始されると、制御部１００ａは、音場データに基づいて音響データを生成し、音響出力部１０７に供給する。音響出力部１０７は、前述のようにして、供給された音響データを音響に変換して外部に出力する。
【００３７】
図２（ｂ）は、コミュニケーションサーバ３００の機能構成を示すブロック図であり、同図（ｂ）において、制御部３００ａおよび音場データ生成部３００ｄは、コミュニケーションサーバ３００のＣＰＵ、ＲＯＭ、ＲＡＭおよび記憶装置によって構成され、音場データＤＢ（データベース）３００ｂおよび端末情報ＤＢ３００ｃは、上記記憶装置上に構築されている。なお、他のサーバ６００のブロックが破線で表現されているのは、本発明のために必須の構成要素ではないことを示している。つまり、他のサーバ６００は、前述のように、コミュニケーションサーバ３００を単体の装置として構成せずに、分散構成あるいはクラウド構成としたときに必要となるものである。
【００３８】
音場データ生成部３００ｄは、コミュニケーション装置１００が送信したオーディオストリームを受信し、受信したオーディオストリームに基づいて音場データを生成して記録する音場データ生成・記録処理を実行する。
【００３９】
図３は、音場データ生成・記録処理を説明するための図であり、同図（ａ）は、コミュニケーションサーバ３００がコミュニケーション装置１００から受信したオーディオストリームを処理する方法の一例を示し、同図（ｂ）は、音場データとその音場データを生成するために必要な音響データ要素（後述）が端末ＩＤに対応付けて記録された状態の一例を示している。
【００４０】
コミュニケーション装置１００がコミュニケーションサーバ３００にオーディオストリームを送信すると、制御部３００ａは、このオーディオストリームを通信Ｉ／Ｆ３００ｅを介して受信し、たとえば１０秒毎に、その時点から過去に１５秒遡った時点までの区間内のデータを抽出し、処理区間データとして一時的に記憶する。
【００４１】
処理区間データが記憶されると直ちに、音場データ生成・記録処理が開始され、音場データ生成部３００ｄは、その処理区間データが特徴部分音響データ要素になり得るものかどうか判定し、なり得るものであれば、当該処理区間データに基づいて特徴部分音響データ要素を生成し、端末ＩＤに対応付けて音場データＤＢ３００ｂに記録する一方、なり得ないものであれば、非特徴部分音響データ要素として記録するかどうか決定し、記録すると決定すれば、当該処理区間データに基づいて非特徴部分音響データ要素を生成し、端末ＩＤに対応付けて音場データＤＢ３００ｂに記録する。なお、端末ＩＤに対応付けて特徴部分音響データ要素および非特徴部分音響データ要素（両者のいずれも示す場合には、以下、「音響データ要素」という）を記録するようにしたのは、音響データ要素は（音場データも）、オーディオストリームをコミュニケーションサーバ３００に送信した装置であれば、コミュニケーション装置１００だけでなく、他の端末４００についても生成され記録されるので、音響データ要素がどの装置についてのものかを区別する必要があるからである。なお端末ＩＤは、端末情報ＤＢ３００ｃに記録され、管理されている。
【００４２】
午前１時になると、音場データ生成部３００ｄは、当該端末ＩＤ（今処理対象にしている端末はコミュニケーション装置１００のみとするので、コミュニケーション装置１００の端末ＩＤのことである）に対応付けられて記録されている、その前日１日分の特徴部分音響データ要素と非特徴部分音響データ要素の各群からそれぞれ最大１３個と最小５個を抽出し、抽出した１８個の音響データ要素を結合して音場データを生成する。生成した音場データは、端末ＩＤに対応付けて音場データＤＢ３００ｂに記録する。
【００４３】
このようにして記録された音場データが、他の端末４００（あるいはコミュニケーション装置１００）によって取得要求されると、制御部３００ａは、音場データＤＢ３００ｂから、当該端末ＩＤに対応付けられた音場データを読み出し、読み出した音場データを、通信Ｉ／Ｆ３００ｅおよび通信ネットワーク２００を介して他の端末４００（あるいはコミュニケーション装置１００）に送信する。なお音場データＤＢ３００ｂには、前日の音場データのみが記録され、前々日以前の音場データは前日の音場データによって上書きされ、残っていないものとする、つまり、各端末ＩＤに対して取得可能な音場データは１つとする。もちろんこれに限られる訳ではなく、音場データが複数の日付に亘って記録されている場合には、端末（コミュニケーション装置１００または他の端末４００）のユーザは、取得したい音場データの日付を選択する必要がある。その他、音場データが複数の日付に亘って記録されていたとしても、取得要求があれば、制御部３００ａは、記録されている音場データをすべて当該端末に送信するようにしてもよい。
【００４４】
このように本実施の形態では、第１のマイクによって任意のタイミングで集音された周囲の雰囲気（音響）に基づいて音場データを生成し、この音場データを再生するようにしたので、ユーザは、任意のタイミングで、その場の雰囲気を容易に知ることができる。
【００４５】
次に、この制御処理を詳細に説明する。
【００４６】
図４は、コミュニケーション装置１００、特にＣＰＵ１０３が実行するメインルーチンの手順を示すフローチャートである。
【００４７】
本メインルーチンは、コミュニケーション装置１００への電源がオンされたときに起動する。
【００４８】
本メインルーチンが起動すると、起動時処理（ステップＳ１〜Ｓ３）が１回実行された後、コマンドの検知処理（ステップＳ４，Ｓ５）により、コマンドが検知されるまで待機状態となる。そして、コマンドが検知されると、検知されたコマンドに応じた処理（ステップＳ６〜Ｓ１２）が実行された後、再度コマンドの検知処理に戻って、新たなコマンドの待機状態となる。その後、これらの処理が、電源がオフされるまで適宜繰り返し実行される。
【００４９】
起動時処理において、まずＣＰＵ１０３は、初期化処理（ステップＳ１）を実行する。この初期化処理では、ＣＰＵ１０３は、前記ＲＡＭ１０５をクリアした後、現在の動作モードを記憶するためにＲＡＭ１０５の所定位置に確保した動作モード記憶領域（図示せず）に「待機モード」を記憶させることで、現在の動作モードを「待機モード」に設定する。
【００５０】
次にＣＰＵ１０３は、処理をコミュニケーションサーバ３００との接続処理（ステップＳ２）に進める。この処理では、ＣＰＵ１０３は、前記ＲＯＭ１０４（またはフラッシュメモリ）に記憶されているコミュニケーションサーバ３００のサーバ名（あるいはＩＰアドレス）を読み出し、読み出したサーバ名に基づいてコミュニケーションサーバ３００にアクセスし、コミュニケーションサーバ３００に接続する。この際、コミュニケーション装置１００はコミュニケーションサーバ３００に対しＩＤ（端末ＩＤ）乃至認証情報を送信し、コミュニケーションサーバ３００にてコミュニケーション装置１００の認証がなされる。ＩＤ乃至認証情報は、ＲＯＭ１０３等に予め記憶されている。認証方法としては、ＩＤおよびパスワードによる認証や公開鍵と利用した認証等種々の態様が利用できる。また、コミュニケーション装置１００側でもコミュニケーションサーバ３００の認証を行い、相互認証を行うようにしてもよい。
【００５１】
さらにＣＰＵ１０３は、処理をオーディオストリームの送信開始処理（ステップＳ３）に進める。この処理では、ＣＰＵ１０３は、前記音響入力部１０１（特に、前記第１のマイク）から音響データが入力されるようにして、入力された音響データが、ＲＡＭ１０５の前記バッファ領域に順次格納されるようにする。そしてＣＰＵ１０３は、バッファ領域内の音響データを所定量ずつ読み出し、読み出した音響データを含むパケットデータを生成して、前記通信Ｉ／Ｆ１０６に渡す。以後ＣＰＵ１０３は、パケットデータの生成および通信Ｉ／Ｆ１０６への供給を繰り返す。本実施の形態では、オーディオストリームの送信プロトコルとして、ＲＴＰ（real-time transport protocol）を採用しているので、各パケットデータにはタイムスタンプが付与される。このタイムスタンプを生成するときに、ＣＰＵ１０３に内蔵されたタイマが使用される。なお、オーディオストリームの送信プロトコルは、ＲＴＰに限らず、オーディオストリームの受信側、つまりコミュニケーションサーバ３００側で、受信したオーディオストリームが送信した順序および時間で再現できるような送信プロトコルであれば、どのようなものを採用しても構わない。
【００５２】
次にＣＰＵ１０３は、コマンドの検知処理を実行する。コマンドの検知処理では、まずＣＰＵ１０３は、コマンドが検知されたかどうかを判定する（ステップＳ４）。本実施の形態では、検知可能なコマンドは、
（Ｃ１）対話モード移行コマンド：筐体を２回叩く
（Ｃ２）音場モード移行コマンド：筐体を静止状態から単方向に移動する（たとえば、持ち上げる）
（Ｃ３）待機モード移行コマンド：筐体を４回叩く
の３種類である。そして、ユーザがコミュニケーション装置１００の筐体（図示せず）に対して上記動作を行うと、姿勢検出部１０２はその動作に応じた姿勢信号を出力するので、ＣＰＵ１０３は、たとえば割り込み処理（図示せず）により、姿勢検出部１０２から出力された姿勢信号を解析して、上記（Ｃ１）〜（Ｃ３）のいずれのコマンドに対応する動作であるかを判定し、判定した動作に対応するコマンドを生成する。生成されたコマンドは、前記ＲＡＭ１０５の所定位置に確保したコマンド格納領域（図示せず）に格納される。ＣＰＵ１０３は、このコマンド格納領域を常時チェックし、有効なコマンドが格納されていれば、コマンドが検知されたと判定する。なお、姿勢検出部１０２から出力された姿勢信号からユーザの動作を検出する方法については、公知の方法を用いればよいので、その説明は省略する。また、検出される上記動作は、例示に過ぎず、任意の動作を採用するようにすればよい。
【００５３】
前記ステップＳ４の判定の結果、コマンドが検知されたときには、ＣＰＵ１０３は、検知されたコマンドに従って、対話モード移行時処理、音場モード移行時処理および待機モード移行時処理のうちいずれかの処理に分岐する（ステップＳ５）一方、コマンドが検知されなかったときには、ＣＰＵ１０３は、処理をコマンドの検知処理（ステップＳ４）に戻す。
【００５４】
対話モード移行時処理では、ＣＰＵ１０３は、前記動作モード記憶領域に「対話モード」を記憶させて、対話モードへ移行させ（ステップＳ６）、予め設定された他の端末（本実施の形態では、他の端末４００）にオーディオストリームを送信開始する（ステップＳ７）。なお、送信したオーディオストリームは、他の端末４００がこれに応答するかどうかに拘わらず、他の端末４００に送信される。
【００５５】
対話モードに移行した後の処理は図示されていないが、他の端末４００が応答した場合、コミュニケーション装置１００と他の端末４００とで相互に、オーディオストリームが送受信されて、それぞれのユーザ間で対話ができるようになっている。ＣＰＵ１０３は、オーディオストリームの送信状況を常時チェックし、所定時間（たとえば、５分間）、送受信されるオーディオストリームが無音状態のときには、前記コマンド格納領域に「待機モード移行コマンド」を格納して、強制的に待機モードに移行させる。また他の端末４００が、コミュニケーション装置１００からのオーディオストリームに対して応答しなかった場合にも、ＣＰＵ１０３は、同様にして強制的に待機モードに移行させる。
【００５６】
なお対話モード移行時処理は、コミュニケーション装置１００側から他の端末４００へオーディオストリームの送信を開始させる処理であるが、他の端末４００側からコミュニケーション装置１００へオーディオストリームが送信されて来た場合には、ＣＰＵ１０３は、そのオーディオストリームを検出して、現在の動作モードが対話モード以外であれば、強制的に対話モードに移行させるようにしてもよい。
【００５７】
音場モード移行時処理では、ＣＰＵ１０３は、動作モード記憶領域に「音場モード」を記憶させて、音場モードへ移行させ（ステップＳ８）、コミュニケーションサーバ３００へ音場データを要求する（ステップＳ９）。これに応じてコミュニケーションサーバ３００が、要求された音場データを送信すると、ＣＰＵ１０３は、この音場データを受信し、受信した音場データを再生する（ステップＳ１０）。
【００５８】
なお、音場データを受信して再生する方法としては、ストリーミングで自動的に行う方法やダウンロード後自動的に再生する方法などが考えられる。また、音場データが再生された後は、強制的に待機モードに移行させるようにすればよい。コミュニケーション装置１００（あるいは他の端末４００）のユーザが、音場データを選択できるようになっている場合、具体的には、音場データが、前述のように複数の日付に亘って記録されおり、そのうちのいずれかの日付の音場データを選択できるようになっていたり、特定の１つの端末ではなく、他の多くの端末ＩＤの音場データを選択できるようになっていたりした場合には、音場データを再生後も、音場モードを継続させるようにした方が好ましい。
【００５９】
待機モード移行時処理では、ＣＰＵ１０３は、動作モード記憶領域に「待機モード」を記憶させて、待機モードへ移行させ（ステップＳ１１）、他の端末へオーディオストリームを送信していれば、これを停止させる（ステップＳ１２）。
【００６０】
上記検知されたコマンドに応じた処理が終了すると、ＣＰＵ１０３は、処理をコマンドの検知処理（ステップＳ４）に戻す。
【００６１】
なお、前記起動時処理に含まれる前記オーディオストリームの送信開始処理（ステップＳ３）が一旦実行されると、それ以降には、このオーディオストリームの送信開始処理を停止する処理はないので、コミュニケーション装置１００からコミュニケーションサーバ３００へのオーディオストリームの送信は、動作モードが待機モードから対話モードあるいは音場モードに移行しても、停止されない。しかし、これに限らず、対話モードあるいは音場モードが選択されたときには、コミュニケーション装置１００からコミュニケーションサーバ３００へのオーディオストリームの送信を停止させるようにしてもよい。この場合、対話モードあるいは音場モードから待機モードに移行したとき、再度オーディオストリームの送信開始処理を実行するようにすればよい。
【００６２】
なおコマンドの入力は、本実施の形態では、姿勢検出部１０２を用いて行うようにしたが、前述のように、音響入力部１０１から入力されたユーザの音声を認識することによって行うようにしてもよい。たとえば、
（Ｃ１′）対話モード移行コマンド：「もしもし○○さん」を２回繰り返す
（Ｃ２′）音場モード移行コマンド：「音場再生します」
（Ｃ３′）待機モード移行コマンド：「待機モードに戻ります」
のように、ユーザがコマンドに対応する内容の発声を行うと、左側のコマンドが生成されるようにする。認識される音声内容は、予め登録（学習）しておくようにすればよい。この場合、認識される音声内容を任意に設定することができる。
【００６３】
これ以外に、コミュニケーション装置１００を、前述のように、入出力デバイスとクレードルによって構成し、入出力デバイスをクレードルに設置するタイプとして実現した場合、入出力デバイスがクレードルから離脱したかどうかを常時チェックするようにし、入出力デバイスがクレードルから離脱したときに、これに応じて、音場モード移行コマンドを入力するようにしてもよい。そして、入出力デバイスがクレードルへ設置されたことに応じて、待機モード移行コマンドが入力されるようにすればよい。
【００６４】
さらに、このコマンド入力方法と、姿勢検出部１０２および音響入力部１０１を用いた入力方法を組み合わせてもよい。たとえば、
（Ｃ１″）対話モード移行コマンド：音響入力部１０１を用いた音声認識
（Ｃ２″）音場モード移行コマンド：姿勢検出部１０２を用いた動作認識
（Ｃ３″）待機モード移行コマンド：入出力デバイスのクレードルへの設置状態の検出
というようにである。
【００６５】
次に、オーディオストリームを受信したコミュニケーションサーバ３００が実行する処理について説明する。
【００６６】
コミュニケーションサーバ３００は、コミュニケーション装置１００からオーディオストリームを受信すると、受信したオーディオストリームを順次、ＲＡＭの所定位置に確保したオーディオストリーム格納領域（図示せず）に格納する。ここで、コミュニケーションサーバ３００が受信するのは、実際には前述のように、所定量の音響データを含むパケットデータであって、オーディオストリームではないので、厳密に言えば、受信したパケットを適宜並べ替えて、コミュニケーション装置１００が送信したオーディオストリームを再現し、これをオーディオストリーム格納領域に格納する。
【００６７】
図５は、コミュニケーションサーバ３００、特にＣＰＵが実行する音響データ要素のピックアップ処理の手順を示すフローチャートである。本音響データ要素のピックアップ処理は、オーディオストリーム格納領域へのオーディオストリームの格納が続いている限り、つまりコミュニケーション装置１００からコミュニケーションサーバ３００へのオーディオストリームの送信が続いている限り、たとえば１０秒毎に起動されて、実行される。前記図３（ａ）において、“▼”の時点が、本音響データ要素のピックアップ処理が起動されるタイミングを示している。
【００６８】
図５に戻り、本音響データ要素のピックアップ処理が起動されると、まずＣＰＵは、処理区間データを取得する（ステップＳ１０１）。処理区間データとは、制御処理の概要で前述したように、本音響データ要素のピックアップ処理の起動時点から過去に１５秒間遡った時点までの区間内のオーディオストリーム（音響データ）である。具体的には、図３（ａ）において、起動時点が時刻ｔ２とすると、その時点の「処理区間データ」は、時刻ｔ０１の“△”から時刻ｔ２の“△”までの区間内のオーディオストリームである。その次の「処理区間データ」は、時刻ｔ１２の“△”から時刻ｔ３の“△”までの区間内のオーディオストリームである。つまり、前後の「処理区間データ」には、５秒間の重複区間（図示例では、時刻ｔ１２から時刻ｔ２までの区間）が設けられている。このように重複区間を設けた理由は、後述する。
【００６９】
次にＣＰＵは、取得した処理区間データの信号レベルの平均値を算出し、算出した平均値が閾値以上であるかどうか判定する（ステップＳ１０２）。この判定の結果、算出した平均値が閾値以上であれば、ＣＰＵは、当該処理区間データから、信号レベルの最も高い１０秒区間を選択（抽出）する（ステップＳ１０３）。そしてＣＰＵは、選択区間データの平均レベルを算出して、特徴量情報とする（ステップＳ１０４）。さらにＣＰＵは、当該選択区間データの取得日時、当該選択区間データ（音響データ）および上記特徴量情報を組にして、特徴部分音響データ要素とし、端末ＩＤと関連付けて前記音場データＤＢ３００ｂに記録した（ステップＳ１０５）後、本音響データ要素のピックアップ処理を終了する。
【００７０】
一方、ステップＳ１０２の判定の結果、算出した平均値が閾値未満であれば、ＣＰＵは、当該処理区間データから１０秒区間をランダムに選択（抽出）する（ステップＳ１０６）。なお、ここでの１０秒区間の選択は、「ランダム」に限らず、たとえば、前記ステップＳ１０３の処理とは逆に、信号レベルの最も低い１０秒区間を選択するようにしてもよい。
【００７１】
次にＣＰＵは、選択区間データを音場データＤＢ３００ｂに記録するか否かをランダムに決定する。その結果、記録するときには、ＣＰＵは、当該選択区間データの取得日時および当該選択区間データ（音響データ）を組にして、非特徴部分音響データ要素とし、端末ＩＤと関連付けて音場データＤＢ３００ｂに記録した（ステップＳ１０８→Ｓ１０９）後、本音響データ要素のピックアップ処理を終了する。ここで、非特徴部分音響データ要素は、１８個を限度として音場データＤＢ３００ｂに記録する。このため、１８個を超えて非特徴部分音響データ要素を記録する場合には、たとえば、最も古く記録されたものを削除した後、新たに生成した非特徴部分音響データ要素を記録する。なお、生成した非特徴部分音響データ要素をすべて記録しないのは、１日のオーディオストリームから生成される音響データ要素の大半が非特徴部分音響データ要素であり（であるのが一般的）、さらに非特徴部分音響データ要素はどれも似たような内容のデータであるため、必要な個数だけ記録しておけば十分だからである。これに対して、特徴部分音響データ要素は、非特徴部分音響データ要素とちょうど逆のことが言えるので、生成されたものをすべて音場データＤＢ３００ｂに記録している。
【００７２】
一方、前記ステップＳ１０７の決定の結果、記録しないときには、ＣＰＵは直ちに、本音響データ要素のピックアップ処理を終了する（ステップＳ１０８→終了）。
【００７３】
このように、音響データ要素は、１５秒間の処理区間データから１０秒区間を抽出して生成する。仮に、処理区間データを１０秒間のデータとし、この全区間を用いて音声データ要素、特に特徴部分音響データ要素を生成したとして、隣接する処理区間データを跨いで特徴部分が含まれていた場合、その特徴部をすべて含む特徴部分音響データ要素が生成されずに、その特徴部が２つに分断された２つの特徴部分音響データ要素が生成されることになる（分断されたことで、特徴部分音響データ要素が生成されずに、非特徴部分音響データ要素が生成されることもある）。この問題に対処するために、処理区間データに前記重複区間を設けるようにしている。
【００７４】
図６は、コミュニケーションサーバ３００、特にＣＰＵが実行する音場データ生成・記録処理の手順を示すフローチャートである。本音場データ生成・記録処理は、本実施の形態では、１日に１回、所定の時間（たとえば、午前１時）に起動されて、実行される。
【００７５】
本音場データ生成・記録処理が起動されると、まずＣＰＵは、音場データＤＢ３００ｂに記憶されている特徴部分音響データ要素から、条件に合うものを最大１３個抽出する（ステップＳ１１１）。この「条件」の例としては、平均レベルの高いものから順に抽出するという条件が挙げられるが、これに限られる訳ではない。また「最大」とは、被抽出対象の特徴部分音響データ要素は１３個以上あっても、その中で「条件」に合うものが１３個未満であったり、そもそも被抽出対象の特徴部分音響データ要素が１３個未満であったりして、１３個抽出できない場合があるということを意味している。
【００７６】
次にＣＰＵは、音場データＤＢ３００ｂに記憶されている非特徴部分音響データ要素から、ランダムに最低５個抽出する（ステップＳ１１２）。ここで「最低」とは、前記ステップＳ１１１の処理によって、特徴部分音響データ要素が１３個未満しか抽出されなかった場合に、１３個に満たない数分、非特徴部分音響データ要素を増やして抽出するという意味である。これは、特徴部分音響データ要素と非特徴部分音響データ要素とを合計して１８個（つまり、１８０秒分）の音響データ要素を抽出したいからである。
【００７７】
次にＣＰＵは、ステップＳ１１１，Ｓ１１２で抽出した合計１８個の音響データ要素をランダムに配置し（ステップＳ１１３）、配置後の各音響データ要素の始端および終端に対して、それぞれフェードイン処理およびフェードアウト処理を施して結合し、音場データを生成する（ステップＳ１１４）。なお、１８個の音響データ要素は、ランダムに配置して結合するのではなく、時系列順に配置して結合するようにしてもよい。
【００７８】
さらにＣＰＵは、生成した音場データに生成日時を付与し、端末ＩＤを関連付けて音場データＤＢ３００ｂに記録する（ステップＳ１１５）。
【００７９】
なお本実施の形態では、コミュニケーション装置１００がコミュニケーションサーバ３００にオーディオストリームを送信する段階からコミュニケーションサーバ３００に音場データを記録する段階まで、プライバシーを保護する処理は何も施されていないので、オーディオストリームに保護すべきプライバシーが含まれていた場合、音場データ内にも保護すべきプライバシーが含まれることがある。このため、オーディオストリームの送信段階から音場データの記録段階に至るまでのいずれかの時点で、適宜スクランブル等のプライバシー保護処理を施すようにした方がよい。特に、オーディオストリーム内に話し声が含まれる可能性がある場合には、オーディオストリームを逆再生するなどして、元の会話内容が第三者に分からないようにすることが好ましい。
【００８０】
また、本音場データ生成・記録処理は、前述のように、１日に１回、所定の時間に定期的に起動するようにしたが、これは、コミュニケーション装置１００（の、特に第１のマイク）が設置されている場所の周辺の１日の様子（音声を通しての様子）を、たとえば１８０秒という短時間に縮めたもの（音場データ）を生成し、これを次の日に再生して、その前日１日の様子を知りたいからである。したがって、再生したいときに、前日１日の様子が分かるようになっていて（つまり、前日の音響データ要素が記録されていて）、リアルタイムの再生までは望んでいなければ、端末から音場データの再生要求があったタイミングで、本音場データ生成・記録処理を起動するようにして、音場データの生成を開始するようにしてもよい。この場合、音場データは、再生要求があった時点を起点として過去１日の音響データ要素に基づいて生成するようにしてもよい。
【００８１】
さらに本実施の形態では、所定の時間として午前１時を例に挙げているが、これは、前日１日の様子を表す音場データを生成するには、その生成基礎となるオーディオストリームは、前日の午前０時から当日の午前０時までにコミュニケーションサーバ３００が受信したものが好ましいからである。つまり、１時間の余裕を見るようにしている。しかし、この余裕時間は、１時間に限らず、他のいずれの時間でもよく、さらに、余裕時間を取らなくてもよい。
【００８２】
なお本実施の形態では、音響データ要素のピックアップおよび音場データの生成の各処理はすべて、コミュニケーションサーバ３００側で行うようにしたが、この一部または全部をコミュニケーション装置１００側で行うようにしてもよい。具体的には、
（Ｍ１）コミュニケーション装置は、音響データ要素のピックアップ処理を行い、特徴部分音響データ要素あるいは非特徴部分音響データ要素としてコミュニケーションサーバ上に保持すべきデータについてのみ、コミュニケーションサーバに送信する構成
（Ｍ２）コミュニケーション装置は、音響データ要素のピックアップおよび音場データの生成の各処理をすべて行い、生成した音場データをコミュニケーションサーバに送信する構成
（Ｍ３）コミュニケーション装置は、上記（Ｍ２）の各処理に加えて、生成した音場データの保持も行い、Ｐ２Ｐ（peer to peer）にて他の端末に音場データを送信する構成
などが考えられる。
【００８３】
また本実施の形態では、特徴部分音響データ要素になり得るものかどうかの判定は、処理区間データの平均レベルに基づいて行うようにしたが、これに限らず、たとえば、ＦＦＴ（Fast Fourier transform）によって処理区間データの周波数スペクトルを検出し、これに基づいて行うようにしてもよい。この場合、特徴量情報も、周波数スペクトルあるいはこれに基づく情報となる。
【００８４】
さらに、本実施の形態を説明するために挙げた各種数値（処理区間データの“１５”秒、“１０”秒区間、音響データ要素のピックアップ処理が起動される間隔の“１０”秒など）は、例示に過ぎず、他の数値を採用することもできる。
【００８５】
なお、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムまたは装置に供給し、そのシステムまたは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【００８６】
この場合、記憶媒体から読出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードおよび該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００８７】
プログラムコードを供給するための記憶媒体としては、たとえば、フレキシブルディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。また、通信ネットワークを介してサーバコンピュータからプログラムコードが供給されるようにしてもよい。
【００８８】
また、コンピュータが読出したプログラムコードを実行することにより、上述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳなどが実際の処理の一部または全部を行い、その処理によって上述した実施の形態の機能が実現される場合も含まれることは言うまでもない。
【００８９】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって上述した実施の形態の機能が実現される場合も含まれることは言うまでもない。
【符号の説明】
【００９０】
１０１…音響入力部（入力手段、取得手段），１０２…姿勢検出部（取得手段），１０３…ＣＰＵ（取得手段、制御手段、生成手段），１０５…ＲＡＭ（入力手段），１０６…通信Ｉ／Ｆ（通信手段），１０７…音響出力部（出力手段）
【技術分野】
【０００１】
本発明は、ユーザの音声を含む周囲の音声を集音し、音響信号として入力して外部に出力するとともに、外部から入力された音響信号を音響に変換して出力するコミュニケーション装置およびコミュニケーションシステムに関する。
【背景技術】
【０００２】
ユーザの音声を含む周囲の音声を集音し、音響信号として入力して外部に出力するとともに、外部から入力された音響信号を音響に変換して出力する装置は、従来から知られている。
【０００３】
このような装置として、たとえば宅内に居る子供や老人、ペット等の状況を宅外から見守るために宅内の撮像画像を宅外から確認可能とする遠隔見守りシステムがある（たとえば、特許文献１参照）。この遠隔見守りシステムは、宅内の様子を宅外から確認可能とする一般的な宅内見守りサービスに加え、宅内装置同士で画像および音声による交信を可能とするＴＶ電話機能サービスを提供する。特許文献１の図２に示されるように、宅内装置２は、電源スイッチ２６がオンの状態で監視スイッチ２７がオン操作されることにより、カメラ２１および人体センサ２６により宅内の様子を監視する監視モードで動作する。一方、監視スイッチ２７がオフのときには、監視モードでの制御は行わず、アイドルモード（操作待ち状態）での制御を行う。そして制御部３１は、アイドルモード時において、宅内装置２同士でのＴＶ電話機能の動作を可能とする。なお特許文献１には、ＴＶ電話機能は、アイドルモード時に限られず、監視モード時に交信キー８１が押下されたことを受けて、宅内装置２同士のＴＶ電話機能を開始するようにしてもよいとも記載されている。
【０００４】
また、会議音声等の音声を記録して利用する音声データ記録再生装置がある（たとえば、特許文献２参照）。この音声データ記録再生装置では、特定の話者の発言区間を検出し、その発言区間以外を話速変換して高速再生することにより、効率よく注目話者の発言内容およびその前後の会議の様子を把握できるようにしている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１１５３７５号公報
【特許文献２】特開２００７−２９８８７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、任意のタイミングで、その場、つまり集音装置の置かれた場所の雰囲気（全体の様子）を知りたいという要望がある。たとえば、遠隔地に住む祖父母が、孫の住む家の１日の様子（雰囲気）を知りたいという要望である。
【０００７】
しかし、このような要望には、上記従来の装置のいずれを用いても応えることはできなかった。上記遠隔見守りシステムでは、ＴＶ電話機能が動作しているときにのみ相手の宅内の雰囲気をうかがい知ることができるに過ぎず、一方、上記音声データ記録再生装置では、会議を行っている時間帯にのみその場の雰囲気をうかがい知ることができるに過ぎないからである。
【０００８】
本発明は、この点に着目してなされたものであり、任意のタイミングで、その場の雰囲気を容易に知ることが可能となるコミュニケーション装置およびコミュニケーションシステムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、請求項１に記載のコミュニケーション装置は、ユーザの音声を含む周囲の音声を集音し、音響信号として入力する入力手段と、音響信号を音響に変換して出力する出力手段と、通信ネットワークを介して接続されたコミュニケーションサーバおよび他のコミュニケーション装置と双方向にデータを通信するための通信手段と、第１および第２の処理命令を含む複数の処理命令を取得する取得手段と、前記取得手段によって前記第１の処理命令が取得された場合には、前記他のコミュニケーション装置に、前記入力手段によって入力された音響信号を前記通信手段を介して送信するように制御する一方、前記取得手段によって前記第２の処理命令が取得された場合には、前記コミュニケーションサーバから前記通信手段を介して音場データを受信し、該音場データを前記出力手段に供給することにより、当該音場データに基づく音響を出力するように制御する制御手段とを有することを特徴とする。
【００１０】
請求項２に記載のコミュニケーション装置は、請求項１のコミュニケーション装置において、前記コミュニケーションサーバから受信する音場データは、前記入力された音響信号が前記通信手段を介して前記コミュニケーションサーバに送信され、該コミュニケーションサーバが当該音響信号に基づいて生成したものであることを特徴とする。
【００１１】
請求項３に記載のコミュニケーション装置は、請求項１のコミュニケーション装置において、前記入力された音響信号に基づいて音場データを生成する生成手段をさらに有し、前記コミュニケーションサーバから受信する音場データは、前記生成手段によって生成された音場データが前記通信手段を介して前記コミュニケーションサーバに送信されたものであることを特徴とする。
【００１２】
上記目的を達成するため、請求項４に記載のコミュニケーションシステムは、少なくとも１つの請求項２に記載のコミュニケーション装置とコミュニケーションサーバとからなるコミュニケーションシステムであって、前記コミュニケーションサーバは、前記コミュニケーション装置から音響信号を入力する入力手段と、特定の時間内に受信した音響信号の中から、複数の部分音響信号を選択し、該選択した複数の部分音響信号を組み合わせることにより、音場データを生成する生成手段と、前記コミュニケーション装置からのリクエストに応じて、前記生成手段によって生成された音場データを前記コミュニケーション装置に送信する送信手段とを有することを特徴とする。
【発明の効果】
【００１３】
請求項１または４に記載の発明によれば、コミュニケーションサーバから音場データを受信し、該音場データを出力手段に供給することにより、当該音場データに基づく音響が出力されるので、音場データが任意のタイミングで、その場の雰囲気を集音して生成されたものであれば、任意のタイミングで、その場の雰囲気を容易に知ることが可能となる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施の形態に係るコミュニケーション装置の概略構成を示すブロック図である。
【図２】図１のコミュニケーション装置およびコミュニケーションサーバの各機能構成を示すブロック図である。
【図３】音場データ生成・記録処理を説明するための図である。
【図４】図１のコミュニケーション装置、特にＣＰＵが実行するメインルーチンの手順を示すフローチャートである。
【図５】図１のコミュニケーションサーバ、特にＣＰＵが実行する音響データ要素のピックアップ処理の手順を示すフローチャートである。
【図６】図１のコミュニケーションサーバ、特にＣＰＵが実行する音場データ生成・記録処理の手順を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。
【００１６】
図１は、本発明の一実施の形態に係るコミュニケーション装置１００の概略構成を示すブロック図である。
【００１７】
同図に示すように、コミュニケーション装置１００は、ユーザの音声を含む周囲の音声を集音し、集音して得られたアナログ音響信号をデジタル音響信号（以下、「音響データ」という）に変換して入力する音響入力部１０１と、コミュニケーション装置１００に対するユーザの動作を検知するためにコミュニケーション装置１００の姿勢を検出する姿勢検出部１０２と、装置全体の制御を司るＣＰＵ１０３と、該ＣＰＵ１０３が実行する制御プログラムや、各種テーブルデータ等を記憶するＲＯＭ１０４と、各種入力情報および演算結果等を一時的に記憶するＲＡＭ１０５と、通信ネットワーク２００を介して、コミュニケーションサーバ３００、他のコミュニケーション装置（端末）４００および設定装置５００とデータの送受信を行う通信インターフェース（Ｉ／Ｆ）１０６と、音響データをアナログ音響信号に変換し、さらに音響に変換して外部に出力する音響出力部１０７とにより構成されている。
【００１８】
上記構成要素１０１〜１０７は、バス１０８を介して相互に接続され、通信Ｉ／Ｆ１０６には通信ネットワーク２００が接続されている。
【００１９】
音響入力部１０１は、集音マイクやアンプ、ＡＤＣ（analog-to-digital converter）等によって構成されている。集音マイクは、本実施の形態では、周囲の雰囲気（音響）を集音する第１のマイクと、ユーザの音声を集音する第２のマイクとからなる。第１のマイクは、１つであってもよいが、複数個備えるようにして、音場特性（音場定位や奥行き感）を再現可能な音響データを入力する方が好ましい。第２のマイクは、１つあればよい。なお、２種類のマイクを設けずに、１種類のマイクで周囲の雰囲気の集音とユーザの音声の集音を兼用させるようにしてもよい。
【００２０】
音響入力部１０１から入力された音響データは、バス１０８を通ってＲＡＭ１０５に供給され、ＲＡＭ１０５内に設けられたバッファ領域（図示せず）に一時的に格納される。バッファ領域は、第１のマイクから入力された音響データを格納するものと、第２のマイクから入力された音響データを格納するものが設けられている。ＲＡＭ１０５としては、通常通り揮発性のものを採用すればよいが、これに限らず、不揮発性のもの、たとえばフラッシュメモリを採用してもよい。フラッシュメモリを採用した場合には、ＲＯＭ１０４に記憶するプログラムやデータもフラッシュメモリに格納するようにして、各内容を書き換え可能にしてもよい。
【００２１】
姿勢検出部１０２は、加速度センサやジャイロスコープ (gyroscope) などによって構成され、ユーザがコミュニケーション装置１００を叩いたり、揺らしたり、上下に移動させたりする動作に応じた信号（以下、「姿勢信号」という）を検出する。姿勢検出部１０２からの姿勢信号に基づいて検出されるユーザの動作は、本実施の形態では、コミュニケーション装置１００の動作モードを移行させるコマンドに対応付けられており、あるコマンドを入力する場合、ユーザは、そのコマンドに対応付けられた動作をコミュニケーション装置１００に対して行う。ただし、コマンドの入力は、音響入力部１０１から入力されたユーザの音声を認識することによっても行うことができるので、つまり、姿勢検出部１０２は常に必須の構成要素ではなく、省略することもできるので、図１の姿勢検出部１０２のブロックは、破線で表現されている（図２でも同様）。なお、入力されたコマンドを検知（認識）したことを、音響出力部１０７より出力される音響や、ＬＥＤ（light emitting diode）などの発光手段、バイブレータなどの振動手段を用いて報知するようにしてもよい。
【００２２】
ＣＰＵ１０３には、タイマが内蔵されている。タイマは、本実施の形態では後述するように、音響データをコミュニケーションサーバ３００に送信する際に、音響データ（のパケット）に付加するタイムスタンプを生成するために用いられる。もちろん、その他の時間の計時や、タイマ割込み処理における割込み時間の計時にも用いられる。
【００２３】
音響出力部１０７は、ＤＡＣ（digital-to-analog converter）、アンプおよびスピーカ等によって構成されている。スピーカは、前記第１のマイクと同様に、１つであってもよいが、音場特性を再現可能な音響データに基づいて音響を出力する場合には、複数のスピーカを設けて、当該音場特性を再現する方が好ましい。
【００２４】
通信ネットワーク２００としては、たとえば、ＩＥＥＥ８０２.１１やＢｌｕｅｔｏｏｔｈ（登録商標）などの無線ＬＡＮ（local area network）、ＵＳＢ（universal serial bus）やＩＥＥＥ１３９４、Ｅｔｈｅｒｎｅｔ（登録商標）などの有線ＬＡＮ、インターネットを挙げることができる。本実施の形態では、コミュニケーション装置１００は、コミュニケーションサーバ３００および他の端末４００とはインターネットを介して接続され、設定装置５００とは無線ＬＡＮを介して接続されているものとする。もちろんこれに限らず、通信ネットワーク２００は、単方式のネットワークによって構成されていてもよいし、３方式以上のネットワークによって構成されていてもよい。
【００２５】
なおコミュニケーション装置１００は、本実施の形態では単体の装置として構成したが、これに限らず、複数の装置を組み合わせて構成してもよい。たとえば、音響入力部１０１および音響出力部１０７からなる入出力デバイスと、ＣＰＵ１０３、ＲＯＭ１０４ＲＡＭ１０５および通信Ｉ／Ｆ１０６からなるクレードルとによって構成し、両者を無線または有線などの任意の接続方法で接続するという実施形態が考えられる。
【００２６】
コミュニケーションサーバ３００は、一般的なサーバ用コンピュータ、具体的には、コミュニケーション装置１００の上記図１の構成から、音響入力部１０１、姿勢検出部１０２、音響出力部１０７を除き、その代わりに、キーボード、マウス、大型ディスプレイおよび記憶装置を加えたものによって構成される。ただし、コミュニケーションサーバ３００のＣＰＵ，ＲＯＭおよびＲＡＭは、コミュニケーション装置１００のＣＰＵ１０３，ＲＯＭ１０４およびＲＡＭ１０５と比較して、その能力や容量が格段に異なっている。
【００２７】
なおコミュニケーションサーバ３００は、本実施の形態では単体の装置として構成したが、これに限らず、適宜分散構成あるいはクラウド構成としてもよい。
【００２８】
他の端末４００は、本実施の形態ではコミュニケーション装置１００の動作と同様の動作を行うので、他の端末４００のハードウェアは、コミュニケーション装置１００のそれ、つまり図１のハードウェアと同様に構成されている。
【００２９】
設定装置５００は、本実施の形態では一般的なＰＣ（パーソナルコンピュータ）によって構成されている。コミュニケーション装置１００は、設定装置５００を、前述のように無線ＬＡＮでコミュニケーション装置１００に接続し、ユーザが設定装置５００上で設定したものをコミュニケーション装置１００に送信することで、コミュニケーション装置１００の各種設定ができるようにしている。ここで、各種設定としては、たとえば、目的のネットワークに接続するために通信Ｉ／Ｆ１０６に対して行う設定、コミュニケーションサーバ３００を特定するための設定（アドレスやＩＤ（identification）など）、対話モード（その内容は、後述する）で通信する相手を特定するための設定（アドレスやＩＤなど）などを挙げることができる。なお各種設定を行うために、コミュニケーション装置１００にその入力手段を設けてもよいし、あるいは姿勢検出や音声認識にて行ってもよいので、つまり、設定装置５００は本発明のために必須の構成要素ではないので、図１の設定装置５００のブロックは、破線で表現されている（図２でも同様）。
【００３０】
なお本実施の形態では、コミュニケーションサーバ３００および他の端末４００はいずれも、１台のみとしたが、もちろんこれに限らず、それぞれ複数台設けるようにしてもよい。
【００３１】
以上のように構成されたコミュニケーション装置１００およびコミュニケーションサーバ３００が実行する制御処理を、まず図２および図３を参照してその概要を説明し、次に図４〜図６を参照して詳細に説明する。
【００３２】
図２（ａ）は、コミュニケーション装置１００の機能構成を示すブロック図であり、図中、図１のブロックと同一のブロックには、同一の符号が付与されている。
【００３３】
図２（ａ）において、制御部１００ａは、ＣＰＵ１０３、ＲＯＭ１０４およびＲＡＭ１０５によって構成され、動作モードとして、少なくとも待機モード、対話モードおよび音場モードの３種類のモードを備えている。
【００３４】
待機モードは、コミュニケーション装置１００の電源がオンされたときに選択される初期モードである。待機モードが選択されると、制御部１００ａは、音響入力部１０１（特に、前記第１のマイク）から入力された音響データを、通信Ｉ／Ｆ１０６および通信ネットワーク２００を介してコミュニケーションサーバ３００に送信する送信処理を開始する。この送信処理が開始されると、電源がオフされない限り、送信処理は停止されないので、連続して入力された音響データはそのまま連続して送信される。つまり、音響データはオーディオストリームを形成する。このため、上記送信処理を、以下「オーディオストリーム送信処理」という。
【００３５】
対話モードは、コミュニケーション装置１００と他の端末４００との間でそれぞれのユーザが対話するときに選択されるモードである。対話モードが選択されると、制御部１００ａは、音響入力部１０１（特に、前記第２のマイク）から入力された音響データ（ユーザの音声データ）を、通信Ｉ／Ｆ１０６および通信ネットワーク２００を介して他の端末４００に送信するとともに、他の端末４００から出力された音響データ（ユーザの音声データ）を、通信ネットワーク２００および通信Ｉ／Ｆ１０６を介して受信し、音響出力部１０７に供給する送受信処理を開始する。この送受信処理が開始されると、他のモードに切り換えられたり、対話が所定時間途切れたりしない限り、送受信処理は停止されないので、連続して入力された音響データはそのまま連続して送信される一方、連続して受信された音響データはそのまま連続して音響出力部１０７に供給される。つまり、音響データはオーディオストリームを形成する。このため、上記送受信処理を、以下「オーディオストリーム送受信処理」という。このオーディオストリーム送受信処理で用いる通信方式は、本実施の形態では、ＶｏＩＰ（Voice over Internet Protocol）を採用するが、これに限られる訳ではない。
【００３６】
音場モードは、コミュニケーションサーバ３００から音場データ（図３（ｂ）参照）を受信して再生するときに選択されるモードである。音場モードが選択されると、制御部１００ａは、音場データの要求を、通信Ｉ／Ｆ１０６および通信ネットワーク２００を介してコミュニケーションサーバ３００に送信し、これに応じてコミュニケーションサーバ３００が送信した音場データを、通信ネットワーク２００および通信Ｉ／Ｆ１０６を介して受信し、この音場データを再生する再生処理を実行する。音場データの再生が開始されると、制御部１００ａは、音場データに基づいて音響データを生成し、音響出力部１０７に供給する。音響出力部１０７は、前述のようにして、供給された音響データを音響に変換して外部に出力する。
【００３７】
図２（ｂ）は、コミュニケーションサーバ３００の機能構成を示すブロック図であり、同図（ｂ）において、制御部３００ａおよび音場データ生成部３００ｄは、コミュニケーションサーバ３００のＣＰＵ、ＲＯＭ、ＲＡＭおよび記憶装置によって構成され、音場データＤＢ（データベース）３００ｂおよび端末情報ＤＢ３００ｃは、上記記憶装置上に構築されている。なお、他のサーバ６００のブロックが破線で表現されているのは、本発明のために必須の構成要素ではないことを示している。つまり、他のサーバ６００は、前述のように、コミュニケーションサーバ３００を単体の装置として構成せずに、分散構成あるいはクラウド構成としたときに必要となるものである。
【００３８】
音場データ生成部３００ｄは、コミュニケーション装置１００が送信したオーディオストリームを受信し、受信したオーディオストリームに基づいて音場データを生成して記録する音場データ生成・記録処理を実行する。
【００３９】
図３は、音場データ生成・記録処理を説明するための図であり、同図（ａ）は、コミュニケーションサーバ３００がコミュニケーション装置１００から受信したオーディオストリームを処理する方法の一例を示し、同図（ｂ）は、音場データとその音場データを生成するために必要な音響データ要素（後述）が端末ＩＤに対応付けて記録された状態の一例を示している。
【００４０】
コミュニケーション装置１００がコミュニケーションサーバ３００にオーディオストリームを送信すると、制御部３００ａは、このオーディオストリームを通信Ｉ／Ｆ３００ｅを介して受信し、たとえば１０秒毎に、その時点から過去に１５秒遡った時点までの区間内のデータを抽出し、処理区間データとして一時的に記憶する。
【００４１】
処理区間データが記憶されると直ちに、音場データ生成・記録処理が開始され、音場データ生成部３００ｄは、その処理区間データが特徴部分音響データ要素になり得るものかどうか判定し、なり得るものであれば、当該処理区間データに基づいて特徴部分音響データ要素を生成し、端末ＩＤに対応付けて音場データＤＢ３００ｂに記録する一方、なり得ないものであれば、非特徴部分音響データ要素として記録するかどうか決定し、記録すると決定すれば、当該処理区間データに基づいて非特徴部分音響データ要素を生成し、端末ＩＤに対応付けて音場データＤＢ３００ｂに記録する。なお、端末ＩＤに対応付けて特徴部分音響データ要素および非特徴部分音響データ要素（両者のいずれも示す場合には、以下、「音響データ要素」という）を記録するようにしたのは、音響データ要素は（音場データも）、オーディオストリームをコミュニケーションサーバ３００に送信した装置であれば、コミュニケーション装置１００だけでなく、他の端末４００についても生成され記録されるので、音響データ要素がどの装置についてのものかを区別する必要があるからである。なお端末ＩＤは、端末情報ＤＢ３００ｃに記録され、管理されている。
【００４２】
午前１時になると、音場データ生成部３００ｄは、当該端末ＩＤ（今処理対象にしている端末はコミュニケーション装置１００のみとするので、コミュニケーション装置１００の端末ＩＤのことである）に対応付けられて記録されている、その前日１日分の特徴部分音響データ要素と非特徴部分音響データ要素の各群からそれぞれ最大１３個と最小５個を抽出し、抽出した１８個の音響データ要素を結合して音場データを生成する。生成した音場データは、端末ＩＤに対応付けて音場データＤＢ３００ｂに記録する。
【００４３】
このようにして記録された音場データが、他の端末４００（あるいはコミュニケーション装置１００）によって取得要求されると、制御部３００ａは、音場データＤＢ３００ｂから、当該端末ＩＤに対応付けられた音場データを読み出し、読み出した音場データを、通信Ｉ／Ｆ３００ｅおよび通信ネットワーク２００を介して他の端末４００（あるいはコミュニケーション装置１００）に送信する。なお音場データＤＢ３００ｂには、前日の音場データのみが記録され、前々日以前の音場データは前日の音場データによって上書きされ、残っていないものとする、つまり、各端末ＩＤに対して取得可能な音場データは１つとする。もちろんこれに限られる訳ではなく、音場データが複数の日付に亘って記録されている場合には、端末（コミュニケーション装置１００または他の端末４００）のユーザは、取得したい音場データの日付を選択する必要がある。その他、音場データが複数の日付に亘って記録されていたとしても、取得要求があれば、制御部３００ａは、記録されている音場データをすべて当該端末に送信するようにしてもよい。
【００４４】
このように本実施の形態では、第１のマイクによって任意のタイミングで集音された周囲の雰囲気（音響）に基づいて音場データを生成し、この音場データを再生するようにしたので、ユーザは、任意のタイミングで、その場の雰囲気を容易に知ることができる。
【００４５】
次に、この制御処理を詳細に説明する。
【００４６】
図４は、コミュニケーション装置１００、特にＣＰＵ１０３が実行するメインルーチンの手順を示すフローチャートである。
【００４７】
本メインルーチンは、コミュニケーション装置１００への電源がオンされたときに起動する。
【００４８】
本メインルーチンが起動すると、起動時処理（ステップＳ１〜Ｓ３）が１回実行された後、コマンドの検知処理（ステップＳ４，Ｓ５）により、コマンドが検知されるまで待機状態となる。そして、コマンドが検知されると、検知されたコマンドに応じた処理（ステップＳ６〜Ｓ１２）が実行された後、再度コマンドの検知処理に戻って、新たなコマンドの待機状態となる。その後、これらの処理が、電源がオフされるまで適宜繰り返し実行される。
【００４９】
起動時処理において、まずＣＰＵ１０３は、初期化処理（ステップＳ１）を実行する。この初期化処理では、ＣＰＵ１０３は、前記ＲＡＭ１０５をクリアした後、現在の動作モードを記憶するためにＲＡＭ１０５の所定位置に確保した動作モード記憶領域（図示せず）に「待機モード」を記憶させることで、現在の動作モードを「待機モード」に設定する。
【００５０】
次にＣＰＵ１０３は、処理をコミュニケーションサーバ３００との接続処理（ステップＳ２）に進める。この処理では、ＣＰＵ１０３は、前記ＲＯＭ１０４（またはフラッシュメモリ）に記憶されているコミュニケーションサーバ３００のサーバ名（あるいはＩＰアドレス）を読み出し、読み出したサーバ名に基づいてコミュニケーションサーバ３００にアクセスし、コミュニケーションサーバ３００に接続する。この際、コミュニケーション装置１００はコミュニケーションサーバ３００に対しＩＤ（端末ＩＤ）乃至認証情報を送信し、コミュニケーションサーバ３００にてコミュニケーション装置１００の認証がなされる。ＩＤ乃至認証情報は、ＲＯＭ１０３等に予め記憶されている。認証方法としては、ＩＤおよびパスワードによる認証や公開鍵と利用した認証等種々の態様が利用できる。また、コミュニケーション装置１００側でもコミュニケーションサーバ３００の認証を行い、相互認証を行うようにしてもよい。
【００５１】
さらにＣＰＵ１０３は、処理をオーディオストリームの送信開始処理（ステップＳ３）に進める。この処理では、ＣＰＵ１０３は、前記音響入力部１０１（特に、前記第１のマイク）から音響データが入力されるようにして、入力された音響データが、ＲＡＭ１０５の前記バッファ領域に順次格納されるようにする。そしてＣＰＵ１０３は、バッファ領域内の音響データを所定量ずつ読み出し、読み出した音響データを含むパケットデータを生成して、前記通信Ｉ／Ｆ１０６に渡す。以後ＣＰＵ１０３は、パケットデータの生成および通信Ｉ／Ｆ１０６への供給を繰り返す。本実施の形態では、オーディオストリームの送信プロトコルとして、ＲＴＰ（real-time transport protocol）を採用しているので、各パケットデータにはタイムスタンプが付与される。このタイムスタンプを生成するときに、ＣＰＵ１０３に内蔵されたタイマが使用される。なお、オーディオストリームの送信プロトコルは、ＲＴＰに限らず、オーディオストリームの受信側、つまりコミュニケーションサーバ３００側で、受信したオーディオストリームが送信した順序および時間で再現できるような送信プロトコルであれば、どのようなものを採用しても構わない。
【００５２】
次にＣＰＵ１０３は、コマンドの検知処理を実行する。コマンドの検知処理では、まずＣＰＵ１０３は、コマンドが検知されたかどうかを判定する（ステップＳ４）。本実施の形態では、検知可能なコマンドは、
（Ｃ１）対話モード移行コマンド：筐体を２回叩く
（Ｃ２）音場モード移行コマンド：筐体を静止状態から単方向に移動する（たとえば、持ち上げる）
（Ｃ３）待機モード移行コマンド：筐体を４回叩く
の３種類である。そして、ユーザがコミュニケーション装置１００の筐体（図示せず）に対して上記動作を行うと、姿勢検出部１０２はその動作に応じた姿勢信号を出力するので、ＣＰＵ１０３は、たとえば割り込み処理（図示せず）により、姿勢検出部１０２から出力された姿勢信号を解析して、上記（Ｃ１）〜（Ｃ３）のいずれのコマンドに対応する動作であるかを判定し、判定した動作に対応するコマンドを生成する。生成されたコマンドは、前記ＲＡＭ１０５の所定位置に確保したコマンド格納領域（図示せず）に格納される。ＣＰＵ１０３は、このコマンド格納領域を常時チェックし、有効なコマンドが格納されていれば、コマンドが検知されたと判定する。なお、姿勢検出部１０２から出力された姿勢信号からユーザの動作を検出する方法については、公知の方法を用いればよいので、その説明は省略する。また、検出される上記動作は、例示に過ぎず、任意の動作を採用するようにすればよい。
【００５３】
前記ステップＳ４の判定の結果、コマンドが検知されたときには、ＣＰＵ１０３は、検知されたコマンドに従って、対話モード移行時処理、音場モード移行時処理および待機モード移行時処理のうちいずれかの処理に分岐する（ステップＳ５）一方、コマンドが検知されなかったときには、ＣＰＵ１０３は、処理をコマンドの検知処理（ステップＳ４）に戻す。
【００５４】
対話モード移行時処理では、ＣＰＵ１０３は、前記動作モード記憶領域に「対話モード」を記憶させて、対話モードへ移行させ（ステップＳ６）、予め設定された他の端末（本実施の形態では、他の端末４００）にオーディオストリームを送信開始する（ステップＳ７）。なお、送信したオーディオストリームは、他の端末４００がこれに応答するかどうかに拘わらず、他の端末４００に送信される。
【００５５】
対話モードに移行した後の処理は図示されていないが、他の端末４００が応答した場合、コミュニケーション装置１００と他の端末４００とで相互に、オーディオストリームが送受信されて、それぞれのユーザ間で対話ができるようになっている。ＣＰＵ１０３は、オーディオストリームの送信状況を常時チェックし、所定時間（たとえば、５分間）、送受信されるオーディオストリームが無音状態のときには、前記コマンド格納領域に「待機モード移行コマンド」を格納して、強制的に待機モードに移行させる。また他の端末４００が、コミュニケーション装置１００からのオーディオストリームに対して応答しなかった場合にも、ＣＰＵ１０３は、同様にして強制的に待機モードに移行させる。
【００５６】
なお対話モード移行時処理は、コミュニケーション装置１００側から他の端末４００へオーディオストリームの送信を開始させる処理であるが、他の端末４００側からコミュニケーション装置１００へオーディオストリームが送信されて来た場合には、ＣＰＵ１０３は、そのオーディオストリームを検出して、現在の動作モードが対話モード以外であれば、強制的に対話モードに移行させるようにしてもよい。
【００５７】
音場モード移行時処理では、ＣＰＵ１０３は、動作モード記憶領域に「音場モード」を記憶させて、音場モードへ移行させ（ステップＳ８）、コミュニケーションサーバ３００へ音場データを要求する（ステップＳ９）。これに応じてコミュニケーションサーバ３００が、要求された音場データを送信すると、ＣＰＵ１０３は、この音場データを受信し、受信した音場データを再生する（ステップＳ１０）。
【００５８】
なお、音場データを受信して再生する方法としては、ストリーミングで自動的に行う方法やダウンロード後自動的に再生する方法などが考えられる。また、音場データが再生された後は、強制的に待機モードに移行させるようにすればよい。コミュニケーション装置１００（あるいは他の端末４００）のユーザが、音場データを選択できるようになっている場合、具体的には、音場データが、前述のように複数の日付に亘って記録されおり、そのうちのいずれかの日付の音場データを選択できるようになっていたり、特定の１つの端末ではなく、他の多くの端末ＩＤの音場データを選択できるようになっていたりした場合には、音場データを再生後も、音場モードを継続させるようにした方が好ましい。
【００５９】
待機モード移行時処理では、ＣＰＵ１０３は、動作モード記憶領域に「待機モード」を記憶させて、待機モードへ移行させ（ステップＳ１１）、他の端末へオーディオストリームを送信していれば、これを停止させる（ステップＳ１２）。
【００６０】
上記検知されたコマンドに応じた処理が終了すると、ＣＰＵ１０３は、処理をコマンドの検知処理（ステップＳ４）に戻す。
【００６１】
なお、前記起動時処理に含まれる前記オーディオストリームの送信開始処理（ステップＳ３）が一旦実行されると、それ以降には、このオーディオストリームの送信開始処理を停止する処理はないので、コミュニケーション装置１００からコミュニケーションサーバ３００へのオーディオストリームの送信は、動作モードが待機モードから対話モードあるいは音場モードに移行しても、停止されない。しかし、これに限らず、対話モードあるいは音場モードが選択されたときには、コミュニケーション装置１００からコミュニケーションサーバ３００へのオーディオストリームの送信を停止させるようにしてもよい。この場合、対話モードあるいは音場モードから待機モードに移行したとき、再度オーディオストリームの送信開始処理を実行するようにすればよい。
【００６２】
なおコマンドの入力は、本実施の形態では、姿勢検出部１０２を用いて行うようにしたが、前述のように、音響入力部１０１から入力されたユーザの音声を認識することによって行うようにしてもよい。たとえば、
（Ｃ１′）対話モード移行コマンド：「もしもし○○さん」を２回繰り返す
（Ｃ２′）音場モード移行コマンド：「音場再生します」
（Ｃ３′）待機モード移行コマンド：「待機モードに戻ります」
のように、ユーザがコマンドに対応する内容の発声を行うと、左側のコマンドが生成されるようにする。認識される音声内容は、予め登録（学習）しておくようにすればよい。この場合、認識される音声内容を任意に設定することができる。
【００６３】
これ以外に、コミュニケーション装置１００を、前述のように、入出力デバイスとクレードルによって構成し、入出力デバイスをクレードルに設置するタイプとして実現した場合、入出力デバイスがクレードルから離脱したかどうかを常時チェックするようにし、入出力デバイスがクレードルから離脱したときに、これに応じて、音場モード移行コマンドを入力するようにしてもよい。そして、入出力デバイスがクレードルへ設置されたことに応じて、待機モード移行コマンドが入力されるようにすればよい。
【００６４】
さらに、このコマンド入力方法と、姿勢検出部１０２および音響入力部１０１を用いた入力方法を組み合わせてもよい。たとえば、
（Ｃ１″）対話モード移行コマンド：音響入力部１０１を用いた音声認識
（Ｃ２″）音場モード移行コマンド：姿勢検出部１０２を用いた動作認識
（Ｃ３″）待機モード移行コマンド：入出力デバイスのクレードルへの設置状態の検出
というようにである。
【００６５】
次に、オーディオストリームを受信したコミュニケーションサーバ３００が実行する処理について説明する。
【００６６】
コミュニケーションサーバ３００は、コミュニケーション装置１００からオーディオストリームを受信すると、受信したオーディオストリームを順次、ＲＡＭの所定位置に確保したオーディオストリーム格納領域（図示せず）に格納する。ここで、コミュニケーションサーバ３００が受信するのは、実際には前述のように、所定量の音響データを含むパケットデータであって、オーディオストリームではないので、厳密に言えば、受信したパケットを適宜並べ替えて、コミュニケーション装置１００が送信したオーディオストリームを再現し、これをオーディオストリーム格納領域に格納する。
【００６７】
図５は、コミュニケーションサーバ３００、特にＣＰＵが実行する音響データ要素のピックアップ処理の手順を示すフローチャートである。本音響データ要素のピックアップ処理は、オーディオストリーム格納領域へのオーディオストリームの格納が続いている限り、つまりコミュニケーション装置１００からコミュニケーションサーバ３００へのオーディオストリームの送信が続いている限り、たとえば１０秒毎に起動されて、実行される。前記図３（ａ）において、“▼”の時点が、本音響データ要素のピックアップ処理が起動されるタイミングを示している。
【００６８】
図５に戻り、本音響データ要素のピックアップ処理が起動されると、まずＣＰＵは、処理区間データを取得する（ステップＳ１０１）。処理区間データとは、制御処理の概要で前述したように、本音響データ要素のピックアップ処理の起動時点から過去に１５秒間遡った時点までの区間内のオーディオストリーム（音響データ）である。具体的には、図３（ａ）において、起動時点が時刻ｔ２とすると、その時点の「処理区間データ」は、時刻ｔ０１の“△”から時刻ｔ２の“△”までの区間内のオーディオストリームである。その次の「処理区間データ」は、時刻ｔ１２の“△”から時刻ｔ３の“△”までの区間内のオーディオストリームである。つまり、前後の「処理区間データ」には、５秒間の重複区間（図示例では、時刻ｔ１２から時刻ｔ２までの区間）が設けられている。このように重複区間を設けた理由は、後述する。
【００６９】
次にＣＰＵは、取得した処理区間データの信号レベルの平均値を算出し、算出した平均値が閾値以上であるかどうか判定する（ステップＳ１０２）。この判定の結果、算出した平均値が閾値以上であれば、ＣＰＵは、当該処理区間データから、信号レベルの最も高い１０秒区間を選択（抽出）する（ステップＳ１０３）。そしてＣＰＵは、選択区間データの平均レベルを算出して、特徴量情報とする（ステップＳ１０４）。さらにＣＰＵは、当該選択区間データの取得日時、当該選択区間データ（音響データ）および上記特徴量情報を組にして、特徴部分音響データ要素とし、端末ＩＤと関連付けて前記音場データＤＢ３００ｂに記録した（ステップＳ１０５）後、本音響データ要素のピックアップ処理を終了する。
【００７０】
一方、ステップＳ１０２の判定の結果、算出した平均値が閾値未満であれば、ＣＰＵは、当該処理区間データから１０秒区間をランダムに選択（抽出）する（ステップＳ１０６）。なお、ここでの１０秒区間の選択は、「ランダム」に限らず、たとえば、前記ステップＳ１０３の処理とは逆に、信号レベルの最も低い１０秒区間を選択するようにしてもよい。
【００７１】
次にＣＰＵは、選択区間データを音場データＤＢ３００ｂに記録するか否かをランダムに決定する。その結果、記録するときには、ＣＰＵは、当該選択区間データの取得日時および当該選択区間データ（音響データ）を組にして、非特徴部分音響データ要素とし、端末ＩＤと関連付けて音場データＤＢ３００ｂに記録した（ステップＳ１０８→Ｓ１０９）後、本音響データ要素のピックアップ処理を終了する。ここで、非特徴部分音響データ要素は、１８個を限度として音場データＤＢ３００ｂに記録する。このため、１８個を超えて非特徴部分音響データ要素を記録する場合には、たとえば、最も古く記録されたものを削除した後、新たに生成した非特徴部分音響データ要素を記録する。なお、生成した非特徴部分音響データ要素をすべて記録しないのは、１日のオーディオストリームから生成される音響データ要素の大半が非特徴部分音響データ要素であり（であるのが一般的）、さらに非特徴部分音響データ要素はどれも似たような内容のデータであるため、必要な個数だけ記録しておけば十分だからである。これに対して、特徴部分音響データ要素は、非特徴部分音響データ要素とちょうど逆のことが言えるので、生成されたものをすべて音場データＤＢ３００ｂに記録している。
【００７２】
一方、前記ステップＳ１０７の決定の結果、記録しないときには、ＣＰＵは直ちに、本音響データ要素のピックアップ処理を終了する（ステップＳ１０８→終了）。
【００７３】
このように、音響データ要素は、１５秒間の処理区間データから１０秒区間を抽出して生成する。仮に、処理区間データを１０秒間のデータとし、この全区間を用いて音声データ要素、特に特徴部分音響データ要素を生成したとして、隣接する処理区間データを跨いで特徴部分が含まれていた場合、その特徴部をすべて含む特徴部分音響データ要素が生成されずに、その特徴部が２つに分断された２つの特徴部分音響データ要素が生成されることになる（分断されたことで、特徴部分音響データ要素が生成されずに、非特徴部分音響データ要素が生成されることもある）。この問題に対処するために、処理区間データに前記重複区間を設けるようにしている。
【００７４】
図６は、コミュニケーションサーバ３００、特にＣＰＵが実行する音場データ生成・記録処理の手順を示すフローチャートである。本音場データ生成・記録処理は、本実施の形態では、１日に１回、所定の時間（たとえば、午前１時）に起動されて、実行される。
【００７５】
本音場データ生成・記録処理が起動されると、まずＣＰＵは、音場データＤＢ３００ｂに記憶されている特徴部分音響データ要素から、条件に合うものを最大１３個抽出する（ステップＳ１１１）。この「条件」の例としては、平均レベルの高いものから順に抽出するという条件が挙げられるが、これに限られる訳ではない。また「最大」とは、被抽出対象の特徴部分音響データ要素は１３個以上あっても、その中で「条件」に合うものが１３個未満であったり、そもそも被抽出対象の特徴部分音響データ要素が１３個未満であったりして、１３個抽出できない場合があるということを意味している。
【００７６】
次にＣＰＵは、音場データＤＢ３００ｂに記憶されている非特徴部分音響データ要素から、ランダムに最低５個抽出する（ステップＳ１１２）。ここで「最低」とは、前記ステップＳ１１１の処理によって、特徴部分音響データ要素が１３個未満しか抽出されなかった場合に、１３個に満たない数分、非特徴部分音響データ要素を増やして抽出するという意味である。これは、特徴部分音響データ要素と非特徴部分音響データ要素とを合計して１８個（つまり、１８０秒分）の音響データ要素を抽出したいからである。
【００７７】
次にＣＰＵは、ステップＳ１１１，Ｓ１１２で抽出した合計１８個の音響データ要素をランダムに配置し（ステップＳ１１３）、配置後の各音響データ要素の始端および終端に対して、それぞれフェードイン処理およびフェードアウト処理を施して結合し、音場データを生成する（ステップＳ１１４）。なお、１８個の音響データ要素は、ランダムに配置して結合するのではなく、時系列順に配置して結合するようにしてもよい。
【００７８】
さらにＣＰＵは、生成した音場データに生成日時を付与し、端末ＩＤを関連付けて音場データＤＢ３００ｂに記録する（ステップＳ１１５）。
【００７９】
なお本実施の形態では、コミュニケーション装置１００がコミュニケーションサーバ３００にオーディオストリームを送信する段階からコミュニケーションサーバ３００に音場データを記録する段階まで、プライバシーを保護する処理は何も施されていないので、オーディオストリームに保護すべきプライバシーが含まれていた場合、音場データ内にも保護すべきプライバシーが含まれることがある。このため、オーディオストリームの送信段階から音場データの記録段階に至るまでのいずれかの時点で、適宜スクランブル等のプライバシー保護処理を施すようにした方がよい。特に、オーディオストリーム内に話し声が含まれる可能性がある場合には、オーディオストリームを逆再生するなどして、元の会話内容が第三者に分からないようにすることが好ましい。
【００８０】
また、本音場データ生成・記録処理は、前述のように、１日に１回、所定の時間に定期的に起動するようにしたが、これは、コミュニケーション装置１００（の、特に第１のマイク）が設置されている場所の周辺の１日の様子（音声を通しての様子）を、たとえば１８０秒という短時間に縮めたもの（音場データ）を生成し、これを次の日に再生して、その前日１日の様子を知りたいからである。したがって、再生したいときに、前日１日の様子が分かるようになっていて（つまり、前日の音響データ要素が記録されていて）、リアルタイムの再生までは望んでいなければ、端末から音場データの再生要求があったタイミングで、本音場データ生成・記録処理を起動するようにして、音場データの生成を開始するようにしてもよい。この場合、音場データは、再生要求があった時点を起点として過去１日の音響データ要素に基づいて生成するようにしてもよい。
【００８１】
さらに本実施の形態では、所定の時間として午前１時を例に挙げているが、これは、前日１日の様子を表す音場データを生成するには、その生成基礎となるオーディオストリームは、前日の午前０時から当日の午前０時までにコミュニケーションサーバ３００が受信したものが好ましいからである。つまり、１時間の余裕を見るようにしている。しかし、この余裕時間は、１時間に限らず、他のいずれの時間でもよく、さらに、余裕時間を取らなくてもよい。
【００８２】
なお本実施の形態では、音響データ要素のピックアップおよび音場データの生成の各処理はすべて、コミュニケーションサーバ３００側で行うようにしたが、この一部または全部をコミュニケーション装置１００側で行うようにしてもよい。具体的には、
（Ｍ１）コミュニケーション装置は、音響データ要素のピックアップ処理を行い、特徴部分音響データ要素あるいは非特徴部分音響データ要素としてコミュニケーションサーバ上に保持すべきデータについてのみ、コミュニケーションサーバに送信する構成
（Ｍ２）コミュニケーション装置は、音響データ要素のピックアップおよび音場データの生成の各処理をすべて行い、生成した音場データをコミュニケーションサーバに送信する構成
（Ｍ３）コミュニケーション装置は、上記（Ｍ２）の各処理に加えて、生成した音場データの保持も行い、Ｐ２Ｐ（peer to peer）にて他の端末に音場データを送信する構成
などが考えられる。
【００８３】
また本実施の形態では、特徴部分音響データ要素になり得るものかどうかの判定は、処理区間データの平均レベルに基づいて行うようにしたが、これに限らず、たとえば、ＦＦＴ（Fast Fourier transform）によって処理区間データの周波数スペクトルを検出し、これに基づいて行うようにしてもよい。この場合、特徴量情報も、周波数スペクトルあるいはこれに基づく情報となる。
【００８４】
さらに、本実施の形態を説明するために挙げた各種数値（処理区間データの“１５”秒、“１０”秒区間、音響データ要素のピックアップ処理が起動される間隔の“１０”秒など）は、例示に過ぎず、他の数値を採用することもできる。
【００８５】
なお、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムまたは装置に供給し、そのシステムまたは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【００８６】
この場合、記憶媒体から読出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードおよび該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００８７】
プログラムコードを供給するための記憶媒体としては、たとえば、フレキシブルディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。また、通信ネットワークを介してサーバコンピュータからプログラムコードが供給されるようにしてもよい。
【００８８】
また、コンピュータが読出したプログラムコードを実行することにより、上述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳなどが実際の処理の一部または全部を行い、その処理によって上述した実施の形態の機能が実現される場合も含まれることは言うまでもない。
【００８９】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって上述した実施の形態の機能が実現される場合も含まれることは言うまでもない。
【符号の説明】
【００９０】
１０１…音響入力部（入力手段、取得手段），１０２…姿勢検出部（取得手段），１０３…ＣＰＵ（取得手段、制御手段、生成手段），１０５…ＲＡＭ（入力手段），１０６…通信Ｉ／Ｆ（通信手段），１０７…音響出力部（出力手段）
【特許請求の範囲】
【請求項１】
ユーザの音声を含む周囲の音声を集音し、音響信号として入力する入力手段と、
音響信号を音響に変換して出力する出力手段と、
通信ネットワークを介して接続されたコミュニケーションサーバおよび他のコミュニケーション装置と双方向にデータを通信するための通信手段と、
第１および第２の処理命令を含む複数の処理命令を取得する取得手段と、
前記取得手段によって前記第１の処理命令が取得された場合には、前記他のコミュニケーション装置に、前記入力手段によって入力された音響信号を前記通信手段を介して送信するように制御する一方、前記取得手段によって前記第２の処理命令が取得された場合には、前記コミュニケーションサーバから前記通信手段を介して音場データを受信し、該音場データを前記出力手段に供給することにより、当該音場データに基づく音響を出力するように制御する制御手段と
を有することを特徴とするコミュニケーション装置。
【請求項２】
前記コミュニケーションサーバから受信する音場データは、前記入力された音響信号が前記通信手段を介して前記コミュニケーションサーバに送信され、該コミュニケーションサーバが当該音響信号に基づいて生成したものであることを特徴とする請求項１に記載のコミュニケーション装置。
【請求項３】
前記入力された音響信号に基づいて音場データを生成する生成手段をさらに有し、
前記コミュニケーションサーバから受信する音場データは、前記生成手段によって生成された音場データが前記通信手段を介して前記コミュニケーションサーバに送信されたものであることを特徴とする請求項１に記載のコミュニケーション装置。
【請求項４】
少なくとも１つの請求項２に記載のコミュニケーション装置とコミュニケーションサーバとからなるコミュニケーションシステムであって、
前記コミュニケーションサーバは、
前記コミュニケーション装置から音響信号を入力する入力手段と、
特定の時間内に受信した音響信号の中から、複数の部分音響信号を選択し、該選択した複数の部分音響信号を組み合わせることにより、音場データを生成する生成手段と、
前記コミュニケーション装置からのリクエストに応じて、前記生成手段によって生成された音場データを前記コミュニケーション装置に送信する送信手段と
を有することを特徴とするコミュニケーションシステム。
【請求項１】
ユーザの音声を含む周囲の音声を集音し、音響信号として入力する入力手段と、
音響信号を音響に変換して出力する出力手段と、
通信ネットワークを介して接続されたコミュニケーションサーバおよび他のコミュニケーション装置と双方向にデータを通信するための通信手段と、
第１および第２の処理命令を含む複数の処理命令を取得する取得手段と、
前記取得手段によって前記第１の処理命令が取得された場合には、前記他のコミュニケーション装置に、前記入力手段によって入力された音響信号を前記通信手段を介して送信するように制御する一方、前記取得手段によって前記第２の処理命令が取得された場合には、前記コミュニケーションサーバから前記通信手段を介して音場データを受信し、該音場データを前記出力手段に供給することにより、当該音場データに基づく音響を出力するように制御する制御手段と
を有することを特徴とするコミュニケーション装置。
【請求項２】
前記コミュニケーションサーバから受信する音場データは、前記入力された音響信号が前記通信手段を介して前記コミュニケーションサーバに送信され、該コミュニケーションサーバが当該音響信号に基づいて生成したものであることを特徴とする請求項１に記載のコミュニケーション装置。
【請求項３】
前記入力された音響信号に基づいて音場データを生成する生成手段をさらに有し、
前記コミュニケーションサーバから受信する音場データは、前記生成手段によって生成された音場データが前記通信手段を介して前記コミュニケーションサーバに送信されたものであることを特徴とする請求項１に記載のコミュニケーション装置。
【請求項４】
少なくとも１つの請求項２に記載のコミュニケーション装置とコミュニケーションサーバとからなるコミュニケーションシステムであって、
前記コミュニケーションサーバは、
前記コミュニケーション装置から音響信号を入力する入力手段と、
特定の時間内に受信した音響信号の中から、複数の部分音響信号を選択し、該選択した複数の部分音響信号を組み合わせることにより、音場データを生成する生成手段と、
前記コミュニケーション装置からのリクエストに応じて、前記生成手段によって生成された音場データを前記コミュニケーション装置に送信する送信手段と
を有することを特徴とするコミュニケーションシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１２−９９９２６（Ｐ２０１２−９９９２６Ａ）
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願番号】特願２０１０−２４４１７７（Ｐ２０１０−２４４１７７）
【出願日】平成２２年１０月２９日（２０１０．１０．２９）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願日】平成２２年１０月２９日（２０１０．１０．２９）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
[ Back to top ]