JP6842227B1 - グループ通話システム、グループ通話方法及びプログラム - Google Patents

Abstract

【課題】本発明は、グループ通話と外部システムとを連携し、グループ通話を違和感なく実現しながら、外部システムからグループ通話への割り込みによる音声出力と、グループ通話からの音声を外部システムへ入力することを目的とする。【解決手段】複数の端末でグループ通話を実現するグループ通話システム１において、デーモンサーバ２００は、利用者端末５０との音声の送受信を行う音声サーバ２２０又は外部システム３３０からの音声データの受信を常時受付け、受付けた音声データを、所定のフォーマットに変更する。そして、音声サーバ２２０から音声データを受信した場合は、フォーマットが変更された音声データを、外部システム３００に送信し、外部システム３００から音声データを受信した場合は、フォーマットが変更された音声データを、利用者端末５０に出力するために、音声サーバ２２０に送信する。【選択図】図１

Description

本発明は、複数の端末により利用者がグループ通話を実現するグループ通話システム、グループ通話方法及びプログラムに関する。

従来より、電話やＩＰ電話による電話会議等により、複数人からなるグループによる通話（グループ通話）を行うシステムが知られている。このようなシステムは、通話を開始する前に、互いに通話者が有する端末装置をグループとして登録し、このグループに登録された端末装置間で、グループ通話を行い、音声のやりとりを行っている。

このようなシステムの例として、各通話者が、自身が有する端末装置と近距離無線方式で接続したヘッドセットを用い、グループ通話を行う構成が開示されている（特許文献１参照）。

特開２０１１−１８２４０７号公報

しかしながら、特許文献１の構成では、グループ通話を開始すると、それに割り込む形で、外部からの音声を通話に取り込み、逆に、グループ通話の内容を、外部システムに出力することができなかった。例えば、介護施設の職員がグループ通話をする際、職員の一人が介護システムに音声でその日の日報を登録したり、グループ通話中にナースコールを検知した外部システムが、このグループ通話にナースコールを音声出力することは不可能であった。

本発明は、グループ通話と外部システムとを連携し、グループ通話を違和感なく実現しながら、外部システムからグループ通話へ音声割り込みによる音声出力と、グループ通話からの音声を外部システムへ入力することが可能なグループ通話システム、グループ通話方法及びプログラムを提供することを目的とする。

本発明では、以下のような解決手段を提供する。

（１）複数の端末でグループ通話を実現するグループ通話システムであって、
前記端末との音声の送受信を行う音声サーバ及び外部システムからの音声データの受信を常時受付ける常駐受付手段と、
受付けた前記音声データを、所定のフォーマット（例えば、音声サーバから受信した場合は、リニアＰＣＭフォーマット、外部システムから受信した場合は、後述する第１のフォーマット）に変更するフォーマット変更手段と、
前記音声サーバから前記音声データを受信した場合は、フォーマットが変更された音声データを、前記外部システムに送信し、
前記外部システムから前記音声データを受信した場合は、フォーマットが変更された音声データを、前記端末に出力するために、前記音声サーバに送信する送信手段と、を備えるグループ通話システムを提供する。

本発明によれば、複数の端末でグループ通話を実現するグループ通話システムは、端末との音声の送受信を行う音声サーバ又は外部システムからの音声データの受信を常時受付け、受付けた音声データを、所定のフォーマットに変更し、音声サーバから音声データを受信した場合は、フォーマットが変更された音声データを、外部システムに送信し、外部システムから前記音声データを受信した場合は、フォーマットが変更された音声データを、端末に出力するために、音声サーバに送信する。

本発明は、システムのカテゴリであるが、方法及びプログラム等の他のカテゴリにおいても、そのカテゴリに応じた同様の作用・効果を発揮する。

（２）（１）のグループ通話システムであって、さらに、前記送信手段が、外部システムから前記音声データを受信した場合において、
前記端末は、
前記グループ通話内に外部システムを示す仮想的な利用者として音声ボットを表示する音声ボット表示手段と、
前記外部システムからの音声データを、前記音声サーバを介して、前記音声ボットが音声データとして出力するボット出力手段と、を備えるグループ通話システムを提供する。

（３）（１）のグループ通話システムであって、さらに、前記送信手段が、前記音声サーバから前記音声データを受信した場合において、
前記端末は、
前記グループ通話内に外部システムを示す仮想的な利用者として音声ボットを表示する音声ボット表示手段と、
前記音声ボットに発話された音声データを前記音声サーバに送信する音声データ送信手段と、を備え、
前記音声データを受信した音声サーバを介して前記音声データを受信し、前記フォーマット変更手段が前記音声データのフォーマット変更を行い、
前記送信手段は、前記外部システムにフォーマット変更された当該音声データを送信するグループ通話システムを提供する。

本発明によれば、グループ通話と外部システムとを連携し、グループ通話を違和感なく実現しながら、グループ通話への音声割り込みと、グループ通話から外部システムへの音声出力が可能な音声入出力システムを提供することが可能となる。

図１は、グループ通話システム１の全体構成図である。 図２は、デーモンサーバ２００、コマンドサーバ１００、利用者端末５０の機能ブロック図である。 図３は、外部システム３００からグループ通話への音声出力処理を示す図である。 図４は、グループ通話から外部システムへの入力処理を示す図である。 図５は、コマンドサーバ１００とデーモンサーバ２００が実行するキーワード検知処理のフローチャートを示す図である。

以下、本発明を実施するための最良の形態について図を参照しながら説明する。なお、これらはあくまでも例であって、本発明の技術的範囲はこれに限られるものではない。

［グループ通話システム１の概要］
本発明の好適な実施形態の概要について、図１に基づいて説明する。図１は、本発明の好適な実施形態であるグループ通話システム１の概要を説明するための図である。グループ通話システム１は、利用者端末５０ａ、ｂ、ｃと、音声サーバ２２０と、ＡＰＩ（Application Programming Interface）サーバ１１０と、デーモンサーバ２００と、コマンドサーバ１００と、外部システム３００と、から構成されてよい。

利用者端末５０ａ、ｂ、ｃは、それぞれ音声サーバ２２０、ＡＰＩサーバ１１０と通信可能に接続され、音声サーバ２２０は、音声データの送受信を行うために、デーモンサーバ２００と通信可能に接続され、ＡＰＩサーバ１１０は、コマンドサーバ１００と通信可能に接続される。そして、外部システム３００は、デーモンサーバ２００及びコマンドサーバ１００と各々、通信可能に接続される。

利用者端末５０ａ、ｂ、ｃは、例えば、スマートフォンやタブレット端末等の携帯端末や、スマートグラス等のヘッドマウントディスプレイといったウェアラブル端末であってよい。グループ通話を行うために、この利用者端末５０ａ、ｂ、ｃと近距離無線通信等により通信可能に接続されたマイク付きの耳当て型ヘッドフォン５５ａ、ｂ、ｃが使用され利用者の音声入出力が行われてもよい。

利用者端末５０ａ、ｂ、ｃには、グループ通話用のアプリケーション・プログラムがインストールされ、これが実行され、ＡＰＩサーバ１１０及び音声サーバ２２０と通信を行うことでグループ通話が実現される。ここで、利用者端末５０ａ、ｂ、ｃ毎に、各利用者のユーザＩＤが対応付けられており、さらに、利用者端末５０ａ、ｂ、ｃにより構成される一のグループ通話は、他のグループ通話と識別するために、トークルームＩＤが付与される。これによって、特定のメンバーが指定されたトークルームでの会話は、指定外のメンバーには送信されない。

利用者端末５０ａ、ｂ、ｃは、グループ通話を違和感なく実現するために音声データのフォーマットを適宜変更する。すなわち、利用者端末５０ａ、ｂ、ｃのヘッドフォン５５ａ、ｂ、ｃに内蔵されたマイクによって取得された利用者の音声を、連続的な音声データ、例えば、リニアＰＣＭ（Pulse Code Modulation）フォーマットで取得する。一般的に、音声における会話において、発話者である利用者の発話は、いつ終了するかが事前に予想が出来ず、話者がしゃべり続ける限り、音声データは連続的なものになるため、この音声データは、長い連続的なデータとなる。

次に、利用者端末５０ａ、ｂ、ｃは、受信したリニアＰＣＭフォーマットの長い連続的なデータを、例えば、１０ｍ秒乃至１秒の長さ、最適にはデータサイズと遅延時間のバランスの取れた４０ｍ秒毎に断片化し、所定のオーバーヘッド付加した「第１のフォーマット」にコード化した音声パケットを生成する。このパケット生成は、随時行われ、長い連続的なリニアＰＣＭフォーマットデータの全体の受信完了を待つことなく、データの受信と音声パケットの生成が同時進行で行われて良い。ところで、上記の「第１のフォーマット」の変換は、利用者端末５０内部の処理で行われてもいいし、リニアＰＣＭフォーマットのまま音声サーバ２２０にデータを送信し、音声サーバ２２０の内部で実行されてもよい。例えば、利用者端末がネットワーク通信速度に制限のある４Ｇ環境におかれている場合、よりデータ圧縮がされた「第１のフォーマット」による通信のほうが通信効率が良いため、本実施例においては利用者端末５０内部で変換処理を行うものとしている。

この第１のフォーマットは、例えば、サンプリングレートが、16Khz‐44.1khzの、Ｏｐｕｓフォーマット（非可逆音声圧縮フォーマット）であってよい。本実施例においては、この第１のフォーマットにオーバーヘッドを付与しており、例えば、（１）発話者を識別するユーザＩＤ、（２）音声を届ける相手の相手先ユーザＩＤやトークルームＩＤ、（３）発話の時刻を示すタイムスタンプが格納されている。

発話した利用者端末５０ｃは、第１のフォーマットの音声データを音声サーバ２２０に送信し、音声サーバ２２０は、発話者以外の利用者端末５０に対して、この音声データを送信する。逐次受信した利用者端末５０ａ、ｂは、オーバーヘッドに格納されたタイムスタンプの順に、再び音声にデコードする。これにより、利用者端末５０ａ、ｂは、互いに発話者の発話を聞き取ることができて、グループ通話を成立させる。
この第１のフォーマットの断片化は、０．５秒以下、好ましくは３０乃至４０ｍ秒等の短い時間とすることで、長いリニアＰＣＭの音声データが終了することを待つことなく、実質的なリアルタイム（可能な限り遅延が小さく、実用上リアルタイムと遜色がない）での通話が可能となる。さらに、断片化する時間を短くすることで、１つの音声パケットが受領されなくても音声として聴取者が意味を聞き取り理解するのに大きな問題が生じない。

各ヘッドフォン５５ａ、ｂ、ｃと利用者端末５０ａ、ｂ、ｃを含む本実施例のシステムには、各ヘッドフォン装着者の発話を検知する機能が搭載されており、発話者の音声を強調もしくは選択してコード化する発話検知モードと、ヘッドフォン５５ａ、ｂ、ｃに設けられたボタン５６ａ、ｂ、ｃを押した際にのみ、発話者の音声の取得を開始するプッシュ・トゥ・トークモードを切り替えて使用することができる。

なお、後述するように、音声サーバ２２０は、第１のフォーマットの音声データをデーモンサーバ２００等の所定のサーバから受信した場合には、第１のフォーマットの音声データで、利用者端末５０ａ、ｂ、ｃに送信してよい。

外部システム３００は、グループ通話と連携する基幹システム、すなわち、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）システムであってよく、上述のように、介護システム、作業管理システム等であってよい。

コマンドサーバ１００は、デーモンサーバ２００と通信可能に接続されたサーバであって、外部システム３００又はＡＰＩサーバ１１０からの指示に応じて、デーモンサーバ２００が受信した音声データを所定のフォーマットに変更するための「フォーマット変更コマンド」を、デーモンサーバ２００に送信する。

デーモンサーバ２００は、音声サーバ２２０及び外部システム３００からの音声データの受信を常時受付け、コマンドサーバ１００からの「フォーマット変更コマンド」に基づいて、所定のフォーマットに変更し、音声サーバ２２０又は外部システム３００に変更した音声データを送信する。

図２に示すように、デーモンサーバ２００は、所定のプログラムをメモリに記憶し、プロセッサー（ＣＰＵ等）がメモリに記憶されたプログラムを読み込むことで、常駐受付モジュール２０１、フォーマット変更モジュール２０２、音声データ送信モジュール２０３、キーワード検知モジュール２０４を実現する。さらに、コマンドサーバ１００は、所定のプログラムをメモリに記憶し、プロセッサーが読み込むことで、フォーマット変更コマンド送信モジュール１２０を実現する。さらに、利用者端末５０は、所定のプログラムをメモリに記憶し、これをプロセッサーが読み込むことで、音声ボット表示モジュール５１、ボット出力モジュール５２、音声データ送信モジュール５３を実現する。

なお、コマンドサーバ１００及びデーモンサーバ２００の各機能は、１台のコンピュータで実現されてもよいし、クラウドコンピュータのように、複数のコンピュータで実現されてもよいし、コマンドサーバ１００とデーモンサーバ２００とが其々別のコンピュータにより実現されてもよい。

［グループ通話への音声出力処理］
次に、図３に基づいて、音声データを外部システム３００からグループ通話に出力（割り込み）する処理について説明する。外部システム３００の一例として、介護施設における入居者の状態や行動を管理する介護システムとして適宜説明する。

ここで、外部システム３００は、基幹システム（ＥＲＰ）から出力する音声データを他のコンピュータに送信する機能を有したり、所定のデータ（テキストデータ等）を音声データに変換する音声変換エンジンを備え、変換された音声データを他のコンピュータに送信する機能を有していてよい。

最初に、介護システムにおいて、ドアやベッド等に設けられたセンサや入居者自身が装着するセンサが入居者の起床を検知する。センサは、起床を検知したデータを介護システムに送信する（ステップＳ０５）。ここで、介護システムが音声変換エンジンを有する場合、これを起動し、センサが検知したデータを、音声変換エンジンが、例えば、「入居者Ａさんが、起床しました」と出力する音声データに変換する。ここで「入居者Ａさんが、起床しました」という音声データが予め録音され記憶されており、センサにより検知したデータと、この録音データが予め対応付けられていることで、検知後にこの録音データを選択して音声データとしてもよい。

このように変換された音声データ又は、選択された録音データ（以下、まとめて音声データとする）を、介護システムが、デーモンサーバ２００に送信する（ステップＳ１０）。ここで送信する音声データ又は録音データは、外部システムの使用に沿ったフォーマット、例えば、リニアＰＣＭフォーマットの連続的な長いデータであってよい。デーモンサーバ２００の常駐受付モジュール２０１は、この音声データを受信する。

なお、デーモンサーバ２００は、外部システム３００である介護システムから、いつ音声データを受信するか不明であるため、少なくとも常駐受付モジュール２０１は、常時、起動しており、いわゆるデーモンとしてプログラムがメモリに常駐して音声データの受信を受付ける。この受注受付モジュール２０１（デーモン）は、音声データの入力に応じて必要なサブシステムを起動することが定義された必要最小限のプログラムであるため、サイズが小さく、音声データの入力がない限り動作することもないので、システム全体の負荷を不必要に増大させることがない。

ここで、介護システムは、デーモンサーバ２００に音声データを送信した際、コマンドサーバ１００に、この音声データのフォーマットを所定のフォーマットに変更するよう指示する。ここで、変更を指示する所定のフォーマットは、上述の第１のフォーマットである。

コマンドサーバ１００は、このデーモンサーバ２００が受信した音声データを介護システムから指示があった所定のフォーマットである第１のフォーマットに変更する「フォーマット変更コマンド」を、デーモンサーバ２００に送信する（ステップＳ１１）。

ここで、この介護システム（外部システム３００）から受信した音声データのオーバーヘッドには、
（１） 発話者を識別するユーザＩＤ
ここでは、介護システムのユーザＩＤであって、ボットＩＤである。すなわち、外部システム３００も一人の仮想的な利用者としてユーザＩＤが付与された状態で「ボット」としてグループ通話に参加して音声出力を行う。
（２）音声を届ける相手先ユーザＩＤ，トークルームＩＤ
（３）発話の時刻を示すタイムスタンプ
が格納されており、このオーバーヘッドに基づいて、第１のフォーマットのオーバーヘッドが生成される。音声データを届ける相手先ユーザＩＤは、タイムスタンプ情報を用いてその時刻における当該「入居者Ａさん」を担当する介護士のユーザＩＤを図示しないシフト管理システムから読み出して設定する。この場合に、介護システムのＩＤと、当該担当の介護士のＩＤがトークルームのメンバーとなっており、例えば医師などの医療チームや事務処理チームには音声データは送信されない。

デーモンサーバ２００のフォーマット変更モジュール２０２は、常駐受付モジュール２０１からの起動信号に応じてメインメモリに読みだされて起動し、受信した「フォーマット変更コマンド」に基づいて、外部システム３００から受信した例えばリニアＰＣＭフォーマットの音声データをグループ会話システムで使用するフォーマットと同じ第１のフォーマット（本実施例においてはＯｐｕｓフォーマット）に変更する（ステップＳ１２）。

デーモンサーバ２００の音声データ送信モジュール２０３は、このフォーマットを変更した音声データ（変更後音声データ）を、コマンドサーバ１００が指示した利用者端末５０ａ、ｂ、ｃに出力するために、音声サーバ２２０に送信する（ステップＳ１３）。

音声サーバ２２０は、変更後音声データを受信し、第１のフォーマットに格納されたトークルームＩＤやユーザＩＤを参照して、該当するＩＤが付与された利用者端末５０ａ、ｂ、ｃに変更後音声データを送信する（ステップＳ１４）。

ここで、利用者端末５０ａ、ｂ、ｃの音声ボット表示モジュール５１は、介護システムに対応した仮想的な利用者である「ボット」を画面に出力表示し、利用者端末５０ａ、ｂ、ｃのボット出力モジュール５２は、変更後音声データを受信し、ヘッドフォン５５ａ、ｂ、ｃを介して、この変更後の音声データを介護システムの「ボット」として音声出力する。すなわち、ヘッドフォン５５を用いてユーザ同士で多人数会話を行っているところに、外部システムからの音声メッセージが介入するにあたり、ユーザは恰も新たなユーザが会話に参加したかのように、自然にシステムメッセージを受領することができる。しかも、多人数の会話を前提とした本実施例で用いられているＯｐｕｓ形式は、データサイズが小さく、遅延の少ない送受信に適している。これを受信者の利用者端末においてリニアＰＣＭに復号することによって、ボットが発する機械的な音声も、人間同士の継続している会話にシステムメッセージを重畳したとしても、当該会話を阻害することなく、各ユーザにメッセージを伝達可能である。なお、音声ボットの表示及び音声出力の制御は、ＡＰＩサーバ１００が利用者端末５０ａ、ｂ、ｃのアプリケーション・プログラムと協働して実現してよい。

ここで、介護システムが発する音声の内容は、人とは異なり、典型的には定型文であるので、外部システム３００から音声データを受信することなく、デーモンサーバ２００が外部システム３００から所定のパケットを受信すると、そのパケットに応じて予め対応付けられている音声データをグループ通話の利用者端末５０ａ、ｂ、ｃに出力させることも可能である。

しかし、本実施例では、定型文であったとしても、外部システム３００は、一旦、当該外部システム３００が採用している通常の音声データとして出力する。そして、受信した音声データを本実施例のデーモンサーバ２００が所定の第１のフォーマットに変更している。そうすることで、汎用システムである外部システム３００は、元々採用している通常の音声としてデータを出力すればよく（第１のフォーマットを出力するシステムである必要が無い）、本実施例のグループ通話に音声出力するにあたり、殆どカスタマイズすることなく本実施形態の会話システムと接続し、音声メッセージを出力することが可能となる。さらに、デーモンサーバ２００を含むシステム側も、追加で接続する外部システム３００’を、恰も他の利用者と同じであるかのように新たなユーザＩＤを付与して通話環境を構築すればよく、システムに大きな負荷をかけることなく新たな外部システム３００’を追加してグループ通話に割り込ませることができる。
この際、新たに追加する外部システム３００’に対し、新たな種類の「ボット」を付与しても良いし、複数の外部システム３００を統合して一つの「ボット」に会話させても良い。

なお、デーモンサーバ２００は、外部システム３００が定期的に出力する音声データを受信する構成であってもよい。この場合、定期的とは、予め設定された時間毎であり、食事、風呂、検診といった入居者や職員（利用者）が一定期間毎や一定時間毎に行う何らかのサービス等に対応するものである。

この場合であっても、上述したように、デーモンサーバ２００が定期的に取得する音声データを、コマンドサーバ１００からの「フォーマット変更コマンド」に基づいて、フォーマット変更後の音声データに変更し、このフォーマットが変更された音声データを、音声サーバ２２０に送信することになる。

利用者端末５０ａ、ｂ、ｃは、ヘッドフォン５５ａ、ｂ、ｃを介して介護システムからの音声データを音声出力する際に、音声ボット表示モジュール５１が、グループ通話内の仮想的な利用者として、画面に音声ボットを出力表示し、この音声ボットが発話しているかのように動画制御して、ボット出力モジュール５２が、音声データをヘッドフォン５５ａ、ｂ、ｃを介して音声出力させてもよい。

［グループ通話から外部システムへの入力］
次に、図４を用いて、グループ通話を行っている各利用者端末５０ａ、ｂ、ｃからの発話による音声データを、各サーバを介して、外部システム３００にデータとして入力させる処理について説明する。

利用者の発話（後述する「コマンド宣言キーワード」であってもよい）をヘッドフォン５５ｃのマイクが受信し、利用者端末５０ｃの音声データ送信モジュール５３が、リニアＰＣＭフォーマット等の長い音声データを上述の第１のフォーマットに変更し、音声サーバ２２０に送信する（ステップＳ３０）。

音声サーバ２２０は、この音声データを受信し、デーモンサーバ２００に送信する（ステップＳ３１）。この際、音声サーバ２２０は、音声データを発話者以外の利用者端末ａ、ｂに送信する。

次に、ステップＳ３１に応じて、デーモンサーバ２００の常駐受付モジュール２０１は、音声サーバ２２０から、第１のフォーマットとなった音声データを受信する。ここで、常駐受付モジュール２０１は、音声サーバ２２０から、いつ音声データを受信するか不明であるため、常駐受付モジュール２０１は、常時、起動しており、デーモンとしてプログラムがメモリに常駐して音声データの受信を受付ける。

一方、コマンドサーバ１００は、このデーモンサーバ２００が取得した音声データ（第１のフォーマット）のフォーマット（例えば、断片化されていない「リニアＰＣＭフォーマット」のデータ）をデーモンサーバ２００に変更させるための「フォーマット変更コマンド」を、デーモンサーバ２００に送信する。

この処理の前提として、発話された利用者端末５０ｃは、音声データを音声サーバ２２０に送信するタイミングで、利用者端末５０ｃは、この音声データに関するデータをＡＰＩサーバ１１０に送信する。この音声データに関するデータとは、この音声データが利用される外部システム３００のＩＤや、デーモンサーバ２００に変更させるフォーマットの種類を示すデータであってよい。

ＡＰＩサーバ１１０は、この音声データに関するデータを受信し、コマンドサーバ１００に、この所定のデータを送信する。コマンドサーバ１００は、ＡＰＩサーバ１１０から所定のデータを受信し、この所定のデータに基づいて、例えば、第１のフォーマットの音声データを、断片化されていないリニアＰＣＭフォーマットのデータに変更するよう、デーモンサーバ２００に「フォーマット変更コマンド」を送信する。

デーモンサーバ２００の常駐受付モジュール２０１は、コマンドサーバ１００から「フォーマット変更コマンド」を受信する（ステップＳ３２）。ここで、常駐受付モジュール２０１は、コマンドサーバ１００から、いつ「フォーマット変更コマンド」を受信するか不明であるため、常駐受付モジュール２０１は、常時、起動しており、デーモンとしてプログラムがメモリに常駐して「フォーマット変更コマンド」の受信を受付ける。

デーモンサーバ２００のフォーマット変更モジュール２０２は、コマンドサーバ１００から受信した「フォーマット変更コマンド」の指示に基づいて、取得した音声データを、断片化されていないリニアＰＣＭフォーマットのデータに変更する。

デーモンサーバ２００の音声データ送信モジュール２０３は、フォーマット変更した音声データを、外部システム３００に送信する（ステップＳ３３）。外部システム３００は、フォーマット変更をした音声データを、例えば、自らが備える音声変換エンジンにより文字認識をしてシステムへのデータ入力としたり、コマンドとして実行することができる。

例えば、自動車整備工場で用いられる作業管理システムの例では、「ナンバー１２−３４のＳＵＶ、オイル交換入ります」といった作業開始を声出し確認する音声を音声データとして作業管理システムに送信し、この音声データに含まれる「作業者名=ユーザＩＤに紐づいた担当者名」及び「作業名＝音声認識したオイル交換」「作業対象＝音声認識したナンバー１２−３４のＳＵＶと、作業対象リストのマッチング結果」を作業管理システムに入力させるとともに、この「音声データのタイムスタンプ」を「作業開始時刻」として自動的に記録することが可能となる。声出し確認は、様々な作業現場で周囲に作業状況を周知させるために行われているので、その声出し確認で自動的に作業記録を作成することで、作業効率が大幅に向上する。
また、上述した自動車整備会社の例では、「オイル交換ＯＫ」という作業終了の声出し確認の音声データを受信したら、整備会社のシステムの業務日報データに、オイル交換完了のステータスを入力できる。特に作業終了時において、オイル交換作業等で汚れた手を洗浄することなく作業記録を完了し、直ちに次の作業を開始できるので、作業効率の向上効果が大きい。

このように、利用者端末５０ｃは、リニアＰＣＭフォーマットの音声データを、断片化した第１のフォーマットに変更して、音声サーバ２２０を介してグループ通話に違和感なく音声を利用者端末５０ａ、ｂに出力した後に、さらに、デーモンサーバ２００がこの第１のフォーマットの音声データをリニアＰＣＭフォーマットの音声データに変更する。ところで、リアルタイムでの音声データ授受が重視される会話と異なり、外部システム３００に向けて発信する音声データはシステム動作を制御するコマンド命令や、記録事項であることが多く、リアルタイムであることの重要性は低いことが多い。従って、外部システム３００へ出力する音声データのフォーマットは、通話で用いる第１のフォーマットと同じである必要性は低く、外部システム３００が元々対応しているフォーマット、本実施例においてはリニアＰＣＭフォーマットで良い。特にコマンド命令の場合、断片化されて送信されるＯｐｕｓフォーマットよりも、データの始点と終点が明確なデータフォーマットの方が適しており、例えばＷＡＶ（ＷＡＶＥＦＯＲＭ ＡＵＤＩＯ ＦＯＲＭＡＴ）であれば好適である。

したがって、外部システム３００は、このグループ通話を実現するシステム特有の第１のフォーマットの音声データを取扱うシステムである必要はなく、標準的なリニアＰＣＭフォーマットの音声データを取り扱うシステムであれば、上記の処理を実現することが可能となる。

なお、デーモンサーバ２００は、音声サーバ２２０から受信した音声データに含まれる所定のキーワード（予め定められた掛け声や宣言）を検知し、このキーワード以後の音声データを、所定のデータに変更して、外部システム３００に送信する構成であってもよい。この処理について、図５に基づいて説明する。

［キーワード検知処理］
図５は、コマンドサーバ１００、デーモンサーバ２００が実行するキーワード検知処理のフローチャートを示す図である。下記の処理の前提として、後述する「コマンド宣言キーワード」を検知するためのデータは、予めデーモンサーバ２００に記憶されている。

最初に、上述のステップＳ３１に応じて、デーモンサーバ２００の常駐受付モジュール２０１は、利用者端末５０ｃから、音声サーバ２２０を介して、音声データを受信する（ステップＳ５０）。

そして、キーワード検知モジュール２０４は、受信した音声データに、コマンドを宣言するキーワードが含まれているか否かを判断する（ステップＳ５１）。すなわち、予めデーモンサーバ２００に記憶された「コマンド宣言キーワード」を検知するためのデータと、受信した音声データとを比較して判断する。

コマンド宣言キーワードとは、例えば、所定の掛け声や宣言（「Hei，Siri」、「OK，Google等）といった、利用者ではなく、コンピュータシステムに入力させるためのコマンド指令を開始するための言葉である。なお、ＳｉｒｉやＧｏｏｇｌｅは各社の商標もしくは登録商標である。

キーワード検知モジュール２０４は、取得した音声データを音声認識することにより、この音声データにキーワードが含まれているか否かを判断する。このとき、キーワード検知モジュール２０４が、音声認識を実行してもよいし、デーモンサーバ２００が、音声データを音声認識するＡＰＩに音声データを出力し、このＡＰＩの認識結果を取得し、この認識結果に基づいて、この音声データに「コマンド宣言キーワード」が含まれているか否かを判断してもよい。

ここで、作業管理システム、スケジュール管理システム等の特定の外部システム３００にコマンドを音声で送る場合等のように、「コマンド宣言キーワード」は、必ずしもグループ通話の他の利用者に聞かせる必要がない場合がある。この場合、利用者端末５０ａ、ｂ、ｃに備える発話検知（発話検知モード）では、発話を開始したタイミングで、その発話が「コマンド宣言キーワード」であるのか、他の利用者へ話しかけたのかが判別できない。判別できないまま音声データを送信してしまうと、他の通常会話と同様、コマンド宣言キーワードと、続くコマンド命令が他のユーザに会話の一部として送信されてしまう。送信後、この発話が他の利用者に聞こえた後で、外部システム３００は、当該発話が「コマンド宣言キーワード」であったことを認識することになる。

そこで、利用者が発話するヘッドフォン５５ｃのボタン５６ｃにより、プッシュ・トゥ・トークモードにおいて、例えば、「コマンド宣言キーワード」をこれから発話することを音声サーバ２２０やデーモンサーバ２００に認識させる動作として、ダブルクリックや長押し等を発話前に実行することで、「コマンド宣言キーワード」及びそれに続くコマンド指令を他の利用者に聞こえないようにフィルタすることができる。また、ダブルクリックによってコマンド入力待ちに変位させることによって、「コマンド宣言キーワード」なしとすることもでき例えばダブルクリック後15秒間程度はグループトークに発信せず、音声認識エンジンにのみ送信するようにしても良い。

より具体的には、発話者がボタン５６ｃを長く押した場合は、これを検知した利用者端末５０ｃと音声サーバ２２０は、ボタン５６ｃが押下されている間は、第１のフォーマットのオーバーヘッドに記載する相手先ユーザＩＤを当該「コマンド宣言キーワード」が指示すべき外部システム３００のＩＤのみに設定することで、コマンド指令を他の利用者に聞こえないようにフィルタリングを実施できる。

一方、作業現場等で手を操作機器から話してボタン５６を押下できない環境等の場合は、発話時に「コマンド宣言キーワード」を検知する発話検知モードにする必要がある。この場合は、発話が「コマンド宣言キーワード」であることを認識した時点で、オーバーヘッドの相手先ユーザＩＤを所定の外部システム３００に設定することで、コマンド宣言キーワード自体は他の利用者に聞こえてしまうが、その後のコマンド指令はフィルタすることができる。このために、本実施例においては、キーワードの検知を、リニアＰＣＭフォーマットから第１のフォーマットへの変換と同時に行っている。前述したように、いつ発話が終わるか予測できない会話において、リニアＰＣＭフォーマットの全体が受信されるのを待つことなく、随時ＯＰＵＳフォーマットである第１のフォーマットに変換している。この変換とコマンド宣言キーワードの検知を同時に行うことで、リニアＰＣＭフォーマット全体の受信が完了することを待つことなくコマンド宣言キーワードを検知することができるので、速やかに他のユーザをフィルタリングすることができる。特に、コマンド宣言キーワードは、発話の途中で現れることは稀であり、たいていは発話の開始時に宣言されるので、受信開始から速やかに検知を開始し、例えば５秒などの所定時間以上経過して発話が継続するときは、コマンド宣言キーワードの検出精度を低下させて、システムの負荷を低減しても良い。
また、上述した自動車整備会社の例では、「オイル交換、ＯＫ」といったように、作業現場では頻出する常用フレーズが用いられることが多い。そこで、そのような常用フレーズを全体としてコマンドとして登録しても良いし、「オイル交換」といった特定の作業項目用語と、「ＯＫ」や「開始」といった特定の作業状態用語をそれぞれ辞書登録してコード置換可能に準備しておき、外部システム３００としての作業記録システムに置換したコードだけを送信しても良い。このような作業の声出し確認は、周囲の作業者に、自分の作業進捗を知らせる意味もあるため、フィルタリングする必要はない。常用フレーズをコマンド化することによって、音声認識の精度を向上させてシステムの信頼性を向上させるとともに、外部システム３００に音声データを送信するよりもデータ通信量を大幅に削減し、システムの負荷を低減することができる。

図５に戻り、キーワード検知モジュール２０４は、音声データに「コマンド宣言キーワード」が含まれていないと判断した場合（ステップＳ５１ ＮＯ）、本処理を終了する。なお、キーワード検知モジュール２０４が、「コマンド宣言キーワード」が含まれていないと判断した場合、グループ通話システム１は、上述したステップＳ３２以降の処理を実行する構成であってもよい。

一方、ステップＳ５１において、キーワード検知モジュール２０４は、音声データに「コマンド宣言キーワード」が含まれていると判断した場合（ステップＳ５１ ＹＥＳ）、音声データに「コマンド宣言キーワード」が含まれていたことを、コマンドサーバ１００に通知する（ステップＳ５２）。

ここで、この際にコマンド指令を外部システム３００が受付ける状態となったことを発話者に認識させるべく、サウンドエフェクト（ビープ音）や音声による返事を、キーワード検知モジュール２０４が音声サーバ２２０を介して、発話者の利用者端末５０ｃに音声出力してもよい。

コマンドサーバ１００のフォーマット変更コマンド送信モジュール１２０は、この通知により、デーモンサーバ２００が取得した音声データは、外部システム３００に対するデータであると判断する。そして、フォーマット変更コマンド送信モジュール１２０は、「コマンド宣言キーワード」後に音声出力されたコマンド指令の音声データを、所定のデータに変更する「フォーマット変更コマンド」を、デーモンサーバ２００に送信する（ステップＳ５３）。

ステップＳ５３において、フォーマット変更コマンド送信モジュール１２０は、このコマンド指令を所定のデータに変更させるために、「フォーマット変更コマンド」をデーモンサーバ２００に送信する。この「フォーマット変更コマンド」は、デーモンサーバ２００が、コマンド指令の音声データを、所定のデータに変更するためのコマンドである。例えば、デーモンサーバ２００が、この音声データを、テキストデータに変更するために必要な処理を実行させるものである。

デーモンサーバ２００のフォーマット変更モジュール２０２は、取得したフォーマット変更コマンドに基づいて、取得した音声データのうち、キーワード以降の音声データ（コマンド指令の音声データ）を、所定のデータ（例えば、テキストデータ）に変更する（ステップＳ５４）。

デーモンサーバ２００は、このテキストデータを、コマンドサーバ１００に送信し（ステップＳ５５）コマンドサーバ１０００が、外部システム３００にテキストデータを送信する（ステップＳ５６）。このテキストデータを受信した外部システム３００は、このテキストデータをコマンド指令として、所定のコマンドを実行したり、所定のデータ入力を行う。

以上の実施例では、外部システム３００は、デーモンサーバ２００、コマンドサーバ１００に対して一のシステム（例えば、介護システム）で説明したが、複数の外部システム３００（例えば、介護システムと作業管理システムの双方）がデーモンサーバ２００、コマンドサーバ１００に接続され、グループ通話システム１により、グループ通話への割り込みや、外部システム３００への入力を実現してもよい。その場合は、外部システム３００毎に異なる上述の「ボット」が対応付けられて、利用者端末５０は、外部システム３００毎に異なる表示態様のボットを出力表示し、音声出力する。この際、ボットは、各外部システム３００それぞれに対応付けられた個性のあるボットとしても良いし、複数のシステムを統合して象徴するボットとしても良い。
これによって、上述した介護システムであれば、予定された入浴時間をスケジュール管理モジュールが通知し、音声で介護士全員に通知しつつ、端末５０ａを使う担当介護士が「了解」と返事をすることで、管理記録システムに当該介護士を担当者として作業開始を登録し、「入居者Ａさん、入浴完了です」の声がけで作業記録を更新しつつ、別の介護士が着替えの介助を行いながら、「爪が伸びていますね」と声がけすることで、更に別の介護士が爪切りの準備を行うとともに管理システムが作業項目として「爪切り」を追加する、といった連携が容易に実現できる。

（１）複数の端末の各々がＡＰＩサーバ及び音声サーバと接続されてグループ通話を実現するシステムに対して接続される音声入出力システムであって、
前記ＡＰＩサーバ及び外部システムと接続され、音声データ以外のデータの処理・制御を行うコマンド手段と、
前記音声サーバ、前記コマンド手段、前記外部システムに各々接続されたデーモン手段と、
を備え、
前記デーモン手段は、
前記外部システムから受信した音声データを前記コマンド手段の指示に基づいて、所定のフォーマットに変更する変更手段と、
変更した音声データを、前記コマンド手段が指示した端末に出力するために、前記音声サーバに出力するデーモン出力手段と、
を備えることを特徴とする音声入出力システム。

（２）複数の端末の各々が、端末を識別するＡＰＩサーバ及び音声サーバと接続された音声入出力システムであって、
前記ＡＰＩサーバ及び外部システムと接続され、音声データ以外のデータの処理・制御を行うコマンド手段と、
前記音声サーバ、前記コマンド手段、前記外部システムに各々接続されたデーモン手段と、
を備え、
前記デーモン手段は、
前記端末から前記音声サーバを介して受信した音声データを前記コマンド手段の指示に基づいて、所定のデータに変更する変更手段と、
を備え、
前記コマンド手段は、
変更した所定のデータを、前記外部システムに出力するコマンド出力手段と、
を備えることを特徴とする音声入出力システム。

（３）前記変更手段は、前記外部システムが定期的に出力する所定の音声データを前記コマンド手段の指示に基づいて、所定のフォーマットに変更する、
ことを特徴とする（１）に記載の音声入出力システム。

（４）前記デーモン手段は、
前記音声データに含まれるキーワードを検知する検知手段と、
をさらに備え、
前記変更手段は、検知した前記キーワード以後の音声データを、所定のデータに変更する、
ことを特徴とする（２）に記載の音声入出力システム。

上述した手段、機能は、コンピュータ（ＣＰＵ、情報処理装置、各種端末を含む）が、所定のプログラムを読み込んで、実行することによって実現される。プログラムは、例えば、コンピュータからネットワーク経由で提供される（ＳａａＳ：ソフトウェア・アズ・ア・サービス）形態で提供される。また、プログラムは、例えば、コンピュータ読取可能な記録媒体に記録された形態で提供される。この場合、コンピュータはその記録媒体からプログラムを読み取って内部記録装置又は外部記録装置に転送し記録して実行する。また、そのプログラムを、例えば、磁気ディスク、光ディスク、光磁気ディスク等の記録装置（記録媒体）に予め記録しておき、その記録装置から通信回線を介してコンピュータに提供するようにしてもよい。

以上、本発明の実施形態について説明したが、本発明は上述したこれらの実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態に記載されたものに限定されるものではない。

１ グループ通話システム、１０ コンピュータ、５０ａ〜ｃ 利用者端末、５５ａ〜ｃ ヘッドフォン、１００ コマンドサーバ、１１０ ＡＰＩサーバ、２００ デーモンサーバ、２２０ 音声サーバ、３００ 外部システム

Claims (5)

1. 複数の端末でグループ通話を実現するグループ通話システムであって、
   前記端末との音声の送受信を行う音声サーバ又は外部システムからの音声データの受信を常時受付ける常駐受付手段と、
   受付けた前記音声データを、所定のフォーマットに変更するフォーマット変更手段と、
   前記音声サーバから前記音声データを受信した場合は、フォーマットが変更された音声データを、前記外部システムに送信し、
   前記外部システムから前記音声データを受信した場合は、フォーマットが変更された音声データを、前記端末に出力するために、前記音声サーバに送信する送信手段と、を備えるグループ通話システム。
2. 前記送信手段が、前記外部システムから前記音声データを受信した場合において、
   前記端末は、
   前記グループ通話内に外部システムを示す仮想的な利用者として音声ボットを表示する音声ボット表示手段と、
   前記外部システムからの音声データを、前記音声サーバを介して、前記音声ボットが音声データとして出力するボット出力手段と、を備える請求項１に記載のグループ通話システム。
3. 前記送信手段が、前記音声サーバから前記音声データを受信した場合において、
   前記端末は、
   前記グループ通話内に外部システムを示す仮想的な利用者として音声ボットを表示する音声ボット表示手段と、
   前記音声ボットに発話された音声データを前記音声サーバに送信する音声データ送信手段と、を備え、
   前記音声データを受信した音声サーバを介して前記音声データを受信し、前記フォーマット変更手段が前記音声データのフォーマット変更を行い、
   前記送信手段は、前記外部システムにフォーマット変更された当該音声データを送信する請求項１に記載のグループ通話システム。
4. 複数の端末でグループ通話を実現するグループ通話システムが実行する通話方法であって、
   前記端末との音声の送受信を行う音声サーバ又は外部システムからの音声データの受信を常時受付けるステップと、
   受付けた前記音声データを、所定のフォーマットに変更するステップと、
   前記音声サーバから前記音声データを受信した場合は、フォーマットが変更された音声データを、前記外部システムに送信し、
   前記外部システムから前記音声データを受信した場合は、フォーマットが変更された音声データを、前記端末に出力するために、前記音声サーバに送信する送信ステップと、を備えるグループ通話方法。
5. 複数の端末でグループ通話を実現するグループ通話システムに、
   前記端末との音声の送受信を行う音声サーバ又は外部システムからの音声データの受信を常時受付けるステップ、
   受付けた前記音声データを、所定のフォーマットに変更するステップ、
   前記音声サーバから前記音声データを受信した場合は、フォーマットが変更された音声データを、前記外部システムに送信し、
   前記外部システムから前記音声データを受信した場合は、フォーマットが変更された音声データを、前記端末に出力するために、前記音声サーバに送信する送信ステップ、を実行させるためのプログラム。

Images