(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0015】
以下、本発明を実施するための最良の形態について図を参照しながら説明する。なお、これらはあくまでも例であって、本発明の技術的範囲はこれに限られるものではない。
【0016】
[グループ通話システム1の概要]
本発明の好適な実施形態の概要について、
図1に基づいて説明する。
図1は、本発明の好適な実施形態であるグループ通話システム1の概要を説明するための図である。グループ通話システム1は、利用者端末50a、b、cと、音声サーバ220と、API(Application Programming Interface)サーバ110と、デーモンサーバ200と、コマンドサーバ100と、外部システム300と、から構成されてよい。
【0017】
利用者端末50a、b、cは、それぞれ音声サーバ220、APIサーバ110と通信可能に接続され、音声サーバ220は、音声データの送受信を行うために、デーモンサーバ200と通信可能に接続され、APIサーバ110は、コマンドサーバ100と通信可能に接続される。そして、外部システム300は、デーモンサーバ200及びコマンドサーバ100と各々、通信可能に接続される。
【0018】
利用者端末50a、b、cは、例えば、スマートフォンやタブレット端末等の携帯端末や、スマートグラス等のヘッドマウントディスプレイといったウェアラブル端末であってよい。グループ通話を行うために、この利用者端末50a、b、cと近距離無線通信等により通信可能に接続されたマイク付きの耳当て型ヘッドフォン55a、b、cが使用され利用者の音声入出力が行われてもよい。
【0019】
利用者端末50a、b、cには、グループ通話用のアプリケーション・プログラムがインストールされ、これが実行され、APIサーバ110及び音声サーバ220と通信を行うことでグループ通話が実現される。ここで、利用者端末50a、b、c毎に、各利用者のユーザIDが対応付けられており、さらに、利用者端末50a、b、cにより構成される一のグループ通話は、他のグループ通話と識別するために、トークルームIDが付与される。これによって、特定のメンバーが指定されたトークルームでの会話は、指定外のメンバーには送信されない。
【0020】
利用者端末50a、b、cは、グループ通話を違和感なく実現するために音声データのフォーマットを適宜変更する。すなわち、利用者端末50a、b、cのヘッドフォン55a、b、cに内蔵されたマイクによって取得された利用者の音声を、連続的な音声データ、例えば、リニアPCM(Pulse Code Modulation)フォーマットで取得する。一般的に、音声における会話において、発話者である利用者の発話は、いつ終了するかが事前に予想が出来ず、話者がしゃべり続ける限り、音声データは連続的なものになるため、この音声データは、長い連続的なデータとなる。
【0021】
次に、利用者端末50a、b、cは、受信したリニアPCMフォーマットの長い連続的なデータを、例えば、10m秒乃至1秒の長さ、最適にはデータサイズと遅延時間のバランスの取れた40m秒毎に断片化し、所定のオーバーヘッド付加した「第1のフォーマット」にコード化した音声パケットを生成する。このパケット生成は、随時行われ、長い連続的なリニアPCMフォーマットデータの全体の受信完了を待つことなく、データの受信と音声パケットの生成が同時進行で行われて良い。ところで、上記の「第1のフォーマット」の変換は、利用者端末50内部の処理で行われてもいいし、リニアPCMフォーマットのまま音声サーバ220にデータを送信し、音声サーバ220の内部で実行されてもよい。例えば、利用者端末がネットワーク通信速度に制限のある4G環境におかれている場合、よりデータ圧縮がされた「第1のフォーマット」による通信のほうが通信効率が良いため、本実施例においては利用者端末50内部で変換処理を行うものとしている。
【0022】
この第1のフォーマットは、例えば、サンプリングレートが、16Khz‐44.1khzの、Opusフォーマット(非可逆音声圧縮フォーマット)であってよい。本実施例においては、この第1のフォーマットにオーバーヘッドを付与しており、例えば、(1)発話者を識別するユーザID、(2)音声を届ける相手の相手先ユーザIDやトークルームID、(3)発話の時刻を示すタイムスタンプが格納されている。
【0023】
発話した利用者端末50cは、第1のフォーマットの音声データを音声サーバ220に送信し、音声サーバ220は、発話者以外の利用者端末50に対して、この音声データを送信する。逐次受信した利用者端末50a、bは、オーバーヘッドに格納されたタイムスタンプの順に、再び音声にデコードする。これにより、利用者端末50a、bは、互いに発話者の発話を聞き取ることができて、グループ通話を成立させる。
この第1のフォーマットの断片化は、0.5秒以下、好ましくは30乃至40m秒等の短い時間とすることで、長いリニアPCMの音声データが終了することを待つことなく、実質的なリアルタイム(可能な限り遅延が小さく、実用上リアルタイムと遜色がない)での通話が可能となる。さらに、断片化する時間を短くすることで、1つの音声パケットが受領されなくても音声として聴取者が意味を聞き取り理解するのに大きな問題が生じない。
【0024】
各ヘッドフォン55a、b、cと利用者端末50a、b、cを含む本実施例のシステムには、各ヘッドフォン装着者の発話を検知する機能が搭載されており、発話者の音声を強調もしくは選択してコード化する発話検知モードと、ヘッドフォン55a、b、cに設けられたボタン56a、b、cを押した際にのみ、発話者の音声の取得を開始するプッシュ・トゥ・トークモードを切り替えて使用することができる。
【0025】
なお、後述するように、音声サーバ220は、第1のフォーマットの音声データをデーモンサーバ200等の所定のサーバから受信した場合には、第1のフォーマットの音声データで、利用者端末50a、b、cに送信してよい。
【0026】
外部システム300は、グループ通話と連携する基幹システム、すなわち、ERP(Enterprise Resource Planning)システムであってよく、上述のように、介護システム、作業管理システム等であってよい。
【0027】
コマンドサーバ100は、デーモンサーバ200と通信可能に接続されたサーバであって、外部システム300又はAPIサーバ110からの指示に応じて、デーモンサーバ200が受信した音声データを所定のフォーマットに変更するための「フォーマット変更コマンド」を、デーモンサーバ200に送信する。
【0028】
デーモンサーバ200は、音声サーバ220及び外部システム300からの音声データの受信を常時受付け、コマンドサーバ100からの「フォーマット変更コマンド」に基づいて、所定のフォーマットに変更し、音声サーバ220又は外部システム300に変更した音声データを送信する。
【0029】
図2に示すように、デーモンサーバ200は、所定のプログラムをメモリに記憶し、プロセッサー(CPU等)がメモリに記憶されたプログラムを読み込むことで、常駐受付モジュール201、フォーマット変更モジュール202、音声データ送信モジュール203、キーワード検知モジュール204を実現する。さらに、コマンドサーバ100は、所定のプログラムをメモリに記憶し、プロセッサーが読み込むことで、フォーマット変更コマンド送信モジュール120を実現する。さらに、利用者端末50は、所定のプログラムをメモリに記憶し、これをプロセッサーが読み込むことで、音声ボット表示モジュール51、ボット出力モジュール52、音声データ送信モジュール53を実現する。
【0030】
なお、コマンドサーバ100及びデーモンサーバ200の各機能は、1台のコンピュータで実現されてもよいし、クラウドコンピュータのように、複数のコンピュータで実現されてもよいし、コマンドサーバ100とデーモンサーバ200とが其々別のコンピュータにより実現されてもよい。
【0031】
[グループ通話への音声出力処理]
次に、
図3に基づいて、音声データを外部システム300からグループ通話に出力(割り込み)する処理について説明する。外部システム300の一例として、介護施設における入居者の状態や行動を管理する介護システムとして適宜説明する。
【0032】
ここで、外部システム300は、基幹システム(ERP)から出力する音声データを他のコンピュータに送信する機能を有したり、所定のデータ(テキストデータ等)を音声データに変換する音声変換エンジンを備え、変換された音声データを他のコンピュータに送信する機能を有していてよい。
【0033】
最初に、介護システムにおいて、ドアやベッド等に設けられたセンサや入居者自身が装着するセンサが入居者の起床を検知する。センサは、起床を検知したデータを介護システムに送信する(ステップS05)。ここで、介護システムが音声変換エンジンを有する場合、これを起動し、センサが検知したデータを、音声変換エンジンが、例えば、「入居者Aさんが、起床しました」と出力する音声データに変換する。ここで「入居者Aさんが、起床しました」という音声データが予め録音され記憶されており、センサにより検知したデータと、この録音データが予め対応付けられていることで、検知後にこの録音データを選択して音声データとしてもよい。
【0034】
このように変換された音声データ又は、選択された録音データ(以下、まとめて音声データとする)を、介護システムが、デーモンサーバ200に送信する(ステップS10)。ここで送信する音声データ又は録音データは、外部システムの使用に沿ったフォーマット、例えば、リニアPCMフォーマットの連続的な長いデータであってよい。デーモンサーバ200の常駐受付モジュール201は、この音声データを受信する。
【0035】
なお、デーモンサーバ200は、外部システム300である介護システムから、いつ音声データを受信するか不明であるため、少なくとも常駐受付モジュール201は、常時、起動しており、いわゆるデーモンとしてプログラムがメモリに常駐して音声データの受信を受付ける。この受注受付モジュール201(デーモン)は、音声データの入力に応じて必要なサブシステムを起動することが定義された必要最小限のプログラムであるため、サイズが小さく、音声データの入力がない限り動作することもないので、システム全体の負荷を不必要に増大させることがない。
【0036】
ここで、介護システムは、デーモンサーバ200に音声データを送信した際、コマンドサーバ100に、この音声データのフォーマットを所定のフォーマットに変更するよう指示する。ここで、変更を指示する所定のフォーマットは、上述の第1のフォーマットである。
【0037】
コマンドサーバ100は、このデーモンサーバ200が受信した音声データを介護システムから指示があった所定のフォーマットである第1のフォーマットに変更する「フォーマット変更コマンド」を、デーモンサーバ200に送信する(ステップS11)。
【0038】
ここで、この介護システム(外部システム300)から受信した音声データのオーバーヘッドには、
(1) 発話者を識別するユーザID
ここでは、介護システムのユーザIDであって、ボットIDである。すなわち、外部システム300も一人の仮想的な利用者としてユーザIDが付与された状態で「ボット」としてグループ通話に参加して音声出力を行う。
(2)音声を届ける相手先ユーザID,トークルームID
(3)発話の時刻を示すタイムスタンプ
が格納されており、このオーバーヘッドに基づいて、第1のフォーマットのオーバーヘッドが生成される。音声データを届ける相手先ユーザIDは、タイムスタンプ情報を用いてその時刻における当該「入居者Aさん」を担当する介護士のユーザIDを図示しないシフト管理システムから読み出して設定する。この場合に、介護システムのIDと、当該担当の介護士のIDがトークルームのメンバーとなっており、例えば医師などの医療チームや事務処理チームには音声データは送信されない。
【0039】
デーモンサーバ200のフォーマット変更モジュール202は、常駐受付モジュール201からの起動信号に応じてメインメモリに読みだされて起動し、受信した「フォーマット変更コマンド」に基づいて、外部システム300から受信した例えばリニアPCMフォーマットの音声データをグループ会話システムで使用するフォーマットと同じ第1のフォーマット(本実施例においてはOpusフォーマット)に変更する(ステップS12)。
【0040】
デーモンサーバ200の音声データ送信モジュール203は、このフォーマットを変更した音声データ(変更後音声データ)を、コマンドサーバ100が指示した利用者端末50a、b、cに出力するために、音声サーバ220に送信する(ステップS13)。
【0041】
音声サーバ220は、変更後音声データを受信し、第1のフォーマットに格納されたトークルームIDやユーザIDを参照して、該当するIDが付与された利用者端末50a、b、cに変更後音声データを送信する(ステップS14)。
【0042】
ここで、利用者端末50a、b、cの音声ボット表示モジュール51は、介護システムに対応した仮想的な利用者である「ボット」を画面に出力表示し、利用者端末50a、b、cのボット出力モジュール52は、変更後音声データを受信し、ヘッドフォン55a、b、cを介して、この変更後の音声データを介護システムの「ボット」として音声出力する。すなわち、ヘッドフォン55を用いてユーザ同士で多人数会話を行っているところに、外部システムからの音声メッセージが介入するにあたり、ユーザは恰も新たなユーザが会話に参加したかのように、自然にシステムメッセージを受領することができる。しかも、多人数の会話を前提とした本実施例で用いられているOpus形式は、データサイズが小さく、遅延の少ない送受信に適している。これを受信者の利用者端末においてリニアPCMに復号することによって、ボットが発する機械的な音声も、人間同士の継続している会話にシステムメッセージを重畳したとしても、当該会話を阻害することなく、各ユーザにメッセージを伝達可能である。なお、音声ボットの表示及び音声出力の制御は、APIサーバ100が利用者端末50a、b、cのアプリケーション・プログラムと協働して実現してよい。
【0043】
ここで、介護システムが発する音声の内容は、人とは異なり、典型的には定型文であるので、外部システム300から音声データを受信することなく、デーモンサーバ200が外部システム300から所定のパケットを受信すると、そのパケットに応じて予め対応付けられている音声データをグループ通話の利用者端末50a、b、cに出力させることも可能である。
【0044】
しかし、本実施例では、定型文であったとしても、外部システム300は、一旦、当該外部システム300が採用している通常の音声データとして出力する。そして、受信した音声データを本実施例のデーモンサーバ200が所定の第1のフォーマットに変更している。そうすることで、汎用システムである外部システム300は、元々採用している通常の音声としてデータを出力すればよく(第1のフォーマットを出力するシステムである必要が無い)、本実施例のグループ通話に音声出力するにあたり、殆どカスタマイズすることなく本実施形態の会話システムと接続し、音声メッセージを出力することが可能となる。さらに、デーモンサーバ200を含むシステム側も、追加で接続する外部システム300’を、恰も他の利用者と同じであるかのように新たなユーザIDを付与して通話環境を構築すればよく、システムに大きな負荷をかけることなく新たな外部システム300’を追加してグループ通話に割り込ませることができる。
この際、新たに追加する外部システム300’に対し、新たな種類の「ボット」を付与しても良いし、複数の外部システム300を統合して一つの「ボット」に会話させても良い。
【0045】
なお、デーモンサーバ200は、外部システム300が定期的に出力する音声データを受信する構成であってもよい。この場合、定期的とは、予め設定された時間毎であり、食事、風呂、検診といった入居者や職員(利用者)が一定期間毎や一定時間毎に行う何らかのサービス等に対応するものである。
【0046】
この場合であっても、上述したように、デーモンサーバ200が定期的に取得する音声データを、コマンドサーバ100からの「フォーマット変更コマンド」に基づいて、フォーマット変更後の音声データに変更し、このフォーマットが変更された音声データを、音声サーバ220に送信することになる。
【0047】
利用者端末50a、b、cは、ヘッドフォン55a、b、cを介して介護システムからの音声データを音声出力する際に、音声ボット表示モジュール51が、グループ通話内の仮想的な利用者として、画面に音声ボットを出力表示し、この音声ボットが発話しているかのように動画制御して、ボット出力モジュール52が、音声データをヘッドフォン55a、b、cを介して音声出力させてもよい。
【0048】
[グループ通話から外部システムへの入力]
次に、
図4を用いて、グループ通話を行っている各利用者端末50a、b、cからの発話による音声データを、各サーバを介して、外部システム300にデータとして入力させる処理について説明する。
【0049】
利用者の発話(後述する「コマンド宣言キーワード」であってもよい)をヘッドフォン55cのマイクが受信し、利用者端末50cの音声データ送信モジュール53が、リニアPCMフォーマット等の長い音声データを上述の第1のフォーマットに変更し、音声サーバ220に送信する(ステップS30)。
【0050】
音声サーバ220は、この音声データを受信し、デーモンサーバ200に送信する(ステップS31)。この際、音声サーバ220は、音声データを発話者以外の利用者端末a、bに送信する。
【0051】
次に、ステップS31に応じて、デーモンサーバ200の常駐受付モジュール201は、音声サーバ220から、第1のフォーマットとなった音声データを受信する。ここで、常駐受付モジュール201は、音声サーバ220から、いつ音声データを受信するか不明であるため、常駐受付モジュール201は、常時、起動しており、デーモンとしてプログラムがメモリに常駐して音声データの受信を受付ける。
【0052】
一方、コマンドサーバ100は、このデーモンサーバ200が取得した音声データ(第1のフォーマット)のフォーマット(例えば、断片化されていない「リニアPCMフォーマット」のデータ)をデーモンサーバ200に変更させるための「フォーマット変更コマンド」を、デーモンサーバ200に送信する。
【0053】
この処理の前提として、発話された利用者端末50cは、音声データを音声サーバ220に送信するタイミングで、利用者端末50cは、この音声データに関するデータをAPIサーバ110に送信する。この音声データに関するデータとは、この音声データが利用される外部システム300のIDや、デーモンサーバ200に変更させるフォーマットの種類を示すデータであってよい。
【0054】
APIサーバ110は、この音声データに関するデータを受信し、コマンドサーバ100に、この所定のデータを送信する。コマンドサーバ100は、APIサーバ110から所定のデータを受信し、この所定のデータに基づいて、例えば、第1のフォーマットの音声データを、断片化されていないリニアPCMフォーマットのデータに変更するよう、デーモンサーバ200に「フォーマット変更コマンド」を送信する。
【0055】
デーモンサーバ200の常駐受付モジュール201は、コマンドサーバ100から「フォーマット変更コマンド」を受信する(ステップS32)。ここで、常駐受付モジュール201は、コマンドサーバ100から、いつ「フォーマット変更コマンド」を受信するか不明であるため、常駐受付モジュール201は、常時、起動しており、デーモンとしてプログラムがメモリに常駐して「フォーマット変更コマンド」の受信を受付ける。
【0056】
デーモンサーバ200のフォーマット変更モジュール202は、コマンドサーバ100から受信した「フォーマット変更コマンド」の指示に基づいて、取得した音声データを、断片化されていないリニアPCMフォーマットのデータに変更する。
【0057】
デーモンサーバ200の音声データ送信モジュール203は、フォーマット変更した音声データを、外部システム300に送信する(ステップS33)。外部システム300は、フォーマット変更をした音声データを、例えば、自らが備える音声変換エンジンにより文字認識をしてシステムへのデータ入力としたり、コマンドとして実行することができる。
【0058】
例えば、自動車整備工場で用いられる作業管理システムの例では、「ナンバー12−34のSUV、オイル交換入ります」といった作業開始を声出し確認する音声を音声データとして作業管理システムに送信し、この音声データに含まれる「作業者名=ユーザIDに紐づいた担当者名」及び「作業名=音声認識したオイル交換」「作業対象=音声認識したナンバー12−34のSUVと、作業対象リストのマッチング結果」を作業管理システムに入力させるとともに、この「音声データのタイムスタンプ」を「作業開始時刻」として自動的に記録することが可能となる。声出し確認は、様々な作業現場で周囲に作業状況を周知させるために行われているので、その声出し確認で自動的に作業記録を作成することで、作業効率が大幅に向上する。
また、上述した自動車整備会社の例では、「オイル交換OK」という作業終了の声出し確認の音声データを受信したら、整備会社のシステムの業務日報データに、オイル交換完了のステータスを入力できる。特に作業終了時において、オイル交換作業等で汚れた手を洗浄することなく作業記録を完了し、直ちに次の作業を開始できるので、作業効率の向上効果が大きい。
【0059】
このように、利用者端末50cは、リニアPCMフォーマットの音声データを、断片化した第1のフォーマットに変更して、音声サーバ220を介してグループ通話に違和感なく音声を利用者端末50a、bに出力した後に、さらに、デーモンサーバ200がこの第1のフォーマットの音声データをリニアPCMフォーマットの音声データに変更する。ところで、リアルタイムでの音声データ授受が重視される会話と異なり、外部システム300に向けて発信する音声データはシステム動作を制御するコマンド命令や、記録事項であることが多く、リアルタイムであることの重要性は低いことが多い。従って、外部システム300へ出力する音声データのフォーマットは、通話で用いる第1のフォーマットと同じである必要性は低く、外部システム300が元々対応しているフォーマット、本実施例においてはリニアPCMフォーマットで良い。特にコマンド命令の場合、断片化されて送信されるOpusフォーマットよりも、データの始点と終点が明確なデータフォーマットの方が適しており、例えばWAV(WAVEFORM AUDIO FORMAT)であれば好適である。
【0060】
したがって、外部システム300は、このグループ通話を実現するシステム特有の第1のフォーマットの音声データを取扱うシステムである必要はなく、標準的なリニアPCMフォーマットの音声データを取り扱うシステムであれば、上記の処理を実現することが可能となる。
【0061】
なお、デーモンサーバ200は、音声サーバ220から受信した音声データに含まれる所定のキーワード(予め定められた掛け声や宣言)を検知し、このキーワード以後の音声データを、所定のデータに変更して、外部システム300に送信する構成であってもよい。この処理について、
図5に基づいて説明する。
【0062】
[キーワード検知処理]
図5は、コマンドサーバ100、デーモンサーバ200が実行するキーワード検知処理のフローチャートを示す図である。下記の処理の前提として、後述する「コマンド宣言キーワード」を検知するためのデータは、予めデーモンサーバ200に記憶されている。
【0063】
最初に、上述のステップS31に応じて、デーモンサーバ200の常駐受付モジュール201は、利用者端末50cから、音声サーバ220を介して、音声データを受信する(ステップS50)。
【0064】
そして、キーワード検知モジュール204は、受信した音声データに、コマンドを宣言するキーワードが含まれているか否かを判断する(ステップS51)。すなわち、予めデーモンサーバ200に記憶された「コマンド宣言キーワード」を検知するためのデータと、受信した音声データとを比較して判断する。
【0065】
コマンド宣言キーワードとは、例えば、所定の掛け声や宣言(「Hei,Siri」、「OK,Google等)といった、利用者ではなく、コンピュータシステムに入力させるためのコマンド指令を開始するための言葉である。なお、SiriやGoogleは各社の商標もしくは登録商標である。
【0066】
キーワード検知モジュール204は、取得した音声データを音声認識することにより、この音声データにキーワードが含まれているか否かを判断する。このとき、キーワード検知モジュール204が、音声認識を実行してもよいし、デーモンサーバ200が、音声データを音声認識するAPIに音声データを出力し、このAPIの認識結果を取得し、この認識結果に基づいて、この音声データに「コマンド宣言キーワード」が含まれているか否かを判断してもよい。
【0067】
ここで、作業管理システム、スケジュール管理システム等の特定の外部システム300にコマンドを音声で送る場合等のように、「コマンド宣言キーワード」は、必ずしもグループ通話の他の利用者に聞かせる必要がない場合がある。この場合、利用者端末50a、b、cに備える発話検知(発話検知モード)では、発話を開始したタイミングで、その発話が「コマンド宣言キーワード」であるのか、他の利用者へ話しかけたのかが判別できない。判別できないまま音声データを送信してしまうと、他の通常会話と同様、コマンド宣言キーワードと、続くコマンド命令が他のユーザに会話の一部として送信されてしまう。送信後、この発話が他の利用者に聞こえた後で、外部システム300は、当該発話が「コマンド宣言キーワード」であったことを認識することになる。
【0068】
そこで、利用者が発話するヘッドフォン55cのボタン56cにより、プッシュ・トゥ・トークモードにおいて、例えば、「コマンド宣言キーワード」をこれから発話することを音声サーバ220やデーモンサーバ200に認識させる動作として、ダブルクリックや長押し等を発話前に実行することで、「コマンド宣言キーワード」及びそれに続くコマンド指令を他の利用者に聞こえないようにフィルタすることができる。また、ダブルクリックによってコマンド入力待ちに変位させることによって、「コマンド宣言キーワード」なしとすることもでき例えばダブルクリック後15秒間程度はグループトークに発信せず、音声認識エンジンにのみ送信するようにしても良い。
【0069】
より具体的には、発話者がボタン56cを長く押した場合は、これを検知した利用者端末50cと音声サーバ220は、ボタン56cが押下されている間は、第1のフォーマットのオーバーヘッドに記載する相手先ユーザIDを当該「コマンド宣言キーワード」が指示すべき外部システム300のIDのみに設定することで、コマンド指令を他の利用者に聞こえないようにフィルタリングを実施できる。
【0070】
一方、作業現場等で手を操作機器から話してボタン56を押下できない環境等の場合は、発話時に「コマンド宣言キーワード」を検知する発話検知モードにする必要がある。この場合は、発話が「コマンド宣言キーワード」であることを認識した時点で、オーバーヘッドの相手先ユーザIDを所定の外部システム300に設定することで、コマンド宣言キーワード自体は他の利用者に聞こえてしまうが、その後のコマンド指令はフィルタすることができる。このために、本実施例においては、キーワードの検知を、リニアPCMフォーマットから第1のフォーマットへの変換と同時に行っている。前述したように、いつ発話が終わるか予測できない会話において、リニアPCMフォーマットの全体が受信されるのを待つことなく、随時OPUSフォーマットである第1のフォーマットに変換している。この変換とコマンド宣言キーワードの検知を同時に行うことで、リニアPCMフォーマット全体の受信が完了することを待つことなくコマンド宣言キーワードを検知することができるので、速やかに他のユーザをフィルタリングすることができる。特に、コマンド宣言キーワードは、発話の途中で現れることは稀であり、たいていは発話の開始時に宣言されるので、受信開始から速やかに検知を開始し、例えば5秒などの所定時間以上経過して発話が継続するときは、コマンド宣言キーワードの検出精度を低下させて、システムの負荷を低減しても良い。
また、上述した自動車整備会社の例では、「オイル交換、OK」といったように、作業現場では頻出する常用フレーズが用いられることが多い。そこで、そのような常用フレーズを全体としてコマンドとして登録しても良いし、「オイル交換」といった特定の作業項目用語と、「OK」や「開始」といった特定の作業状態用語をそれぞれ辞書登録してコード置換可能に準備しておき、外部システム300としての作業記録システムに置換したコードだけを送信しても良い。このような作業の声出し確認は、周囲の作業者に、自分の作業進捗を知らせる意味もあるため、フィルタリングする必要はない。常用フレーズをコマンド化することによって、音声認識の精度を向上させてシステムの信頼性を向上させるとともに、外部システム300に音声データを送信するよりもデータ通信量を大幅に削減し、システムの負荷を低減することができる。
【0071】
図5に戻り、キーワード検知モジュール204は、音声データに「コマンド宣言キーワード」が含まれていないと判断した場合(ステップS51 NO)、本処理を終了する。なお、キーワード検知モジュール204が、「コマンド宣言キーワード」が含まれていないと判断した場合、グループ通話システム1は、上述したステップS32以降の処理を実行する構成であってもよい。
【0072】
一方、ステップS51において、キーワード検知モジュール204は、音声データに「コマンド宣言キーワード」が含まれていると判断した場合(ステップS51 YES)、音声データに「コマンド宣言キーワード」が含まれていたことを、コマンドサーバ100に通知する(ステップS52)。
【0073】
ここで、この際にコマンド指令を外部システム300が受付ける状態となったことを発話者に認識させるべく、サウンドエフェクト(ビープ音)や音声による返事を、キーワード検知モジュール204が音声サーバ220を介して、発話者の利用者端末50cに音声出力してもよい。
【0074】
コマンドサーバ100のフォーマット変更コマンド送信モジュール120は、この通知により、デーモンサーバ200が取得した音声データは、外部システム300に対するデータであると判断する。そして、フォーマット変更コマンド送信モジュール120は、「コマンド宣言キーワード」後に音声出力されたコマンド指令の音声データを、所定のデータに変更する「フォーマット変更コマンド」を、デーモンサーバ200に送信する(ステップS53)。
【0075】
ステップS53において、フォーマット変更コマンド送信モジュール120は、このコマンド指令を所定のデータに変更させるために、「フォーマット変更コマンド」をデーモンサーバ200に送信する。この「フォーマット変更コマンド」は、デーモンサーバ200が、コマンド指令の音声データを、所定のデータに変更するためのコマンドである。例えば、デーモンサーバ200が、この音声データを、テキストデータに変更するために必要な処理を実行させるものである。
【0076】
デーモンサーバ200のフォーマット変更モジュール202は、取得したフォーマット変更コマンドに基づいて、取得した音声データのうち、キーワード以降の音声データ(コマンド指令の音声データ)を、所定のデータ(例えば、テキストデータ)に変更する(ステップS54)。
【0077】
デーモンサーバ200は、このテキストデータを、コマンドサーバ100に送信し(ステップS55)コマンドサーバ1000が、外部システム300にテキストデータを送信する(ステップS56)。このテキストデータを受信した外部システム300は、このテキストデータをコマンド指令として、所定のコマンドを実行したり、所定のデータ入力を行う。
【0078】
以上の実施例では、外部システム300は、デーモンサーバ200、コマンドサーバ100に対して一のシステム(例えば、介護システム)で説明したが、複数の外部システム300(例えば、介護システムと作業管理システムの双方)がデーモンサーバ200、コマンドサーバ100に接続され、グループ通話システム1により、グループ通話への割り込みや、外部システム300への入力を実現してもよい。その場合は、外部システム300毎に異なる上述の「ボット」が対応付けられて、利用者端末50は、外部システム300毎に異なる表示態様のボットを出力表示し、音声出力する。この際、ボットは、各外部システム300それぞれに対応付けられた個性のあるボットとしても良いし、複数のシステムを統合して象徴するボットとしても良い。
これによって、上述した介護システムであれば、予定された入浴時間をスケジュール管理モジュールが通知し、音声で介護士全員に通知しつつ、端末50aを使う担当介護士が「了解」と返事をすることで、管理記録システムに当該介護士を担当者として作業開始を登録し、「入居者Aさん、入浴完了です」の声がけで作業記録を更新しつつ、別の介護士が着替えの介助を行いながら、「爪が伸びていますね」と声がけすることで、更に別の介護士が爪切りの準備を行うとともに管理システムが作業項目として「爪切り」を追加する、といった連携が容易に実現できる。
【0079】
(1)複数の端末の各々がAPIサーバ及び音声サーバと接続されてグループ通話を実現するシステムに対して接続される音声入出力システムであって、
前記APIサーバ及び外部システムと接続され、音声データ以外のデータの処理・制御を行うコマンド手段と、
前記音声サーバ、前記コマンド手段、前記外部システムに各々接続されたデーモン手段と、
を備え、
前記デーモン手段は、
前記外部システムから受信した音声データを前記コマンド手段の指示に基づいて、所定のフォーマットに変更する変更手段と、
変更した音声データを、前記コマンド手段が指示した端末に出力するために、前記音声サーバに出力するデーモン出力手段と、
を備えることを特徴とする音声入出力システム。
【0080】
(2)複数の端末の各々が、端末を識別するAPIサーバ及び音声サーバと接続された音声入出力システムであって、
前記APIサーバ及び外部システムと接続され、音声データ以外のデータの処理・制御を行うコマンド手段と、
前記音声サーバ、前記コマンド手段、前記外部システムに各々接続されたデーモン手段と、
を備え、
前記デーモン手段は、
前記端末から前記音声サーバを介して受信した音声データを前記コマンド手段の指示に基づいて、所定のデータに変更する変更手段と、
を備え、
前記コマンド手段は、
変更した所定のデータを、前記外部システムに出力するコマンド出力手段と、
を備えることを特徴とする音声入出力システム。
【0081】
(3)前記変更手段は、前記外部システムが定期的に出力する所定の音声データを前記コマンド手段の指示に基づいて、所定のフォーマットに変更する、
ことを特徴とする(1)に記載の音声入出力システム。
【0082】
(4)前記デーモン手段は、
前記音声データに含まれるキーワードを検知する検知手段と、
をさらに備え、
前記変更手段は、検知した前記キーワード以後の音声データを、所定のデータに変更する、
ことを特徴とする(2)に記載の音声入出力システム。
【0083】
上述した手段、機能は、コンピュータ(CPU、情報処理装置、各種端末を含む)が、所定のプログラムを読み込んで、実行することによって実現される。プログラムは、例えば、コンピュータからネットワーク経由で提供される(SaaS:ソフトウェア・アズ・ア・サービス)形態で提供される。また、プログラムは、例えば、コンピュータ読取可能な記録媒体に記録された形態で提供される。この場合、コンピュータはその記録媒体からプログラムを読み取って内部記録装置又は外部記録装置に転送し記録して実行する。また、そのプログラムを、例えば、磁気ディスク、光ディスク、光磁気ディスク等の記録装置(記録媒体)に予め記録しておき、その記録装置から通信回線を介してコンピュータに提供するようにしてもよい。
【0084】
以上、本発明の実施形態について説明したが、本発明は上述したこれらの実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態に記載されたものに限定されるものではない。
【課題】本発明は、グループ通話と外部システムとを連携し、グループ通話を違和感なく実現しながら、外部システムからグループ通話への割り込みによる音声出力と、グループ通話からの音声を外部システムへ入力することを目的とする。
【解決手段】複数の端末でグループ通話を実現するグループ通話システム1において、デーモンサーバ200は、利用者端末50との音声の送受信を行う音声サーバ220又は外部システム330からの音声データの受信を常時受付け、受付けた音声データを、所定のフォーマットに変更する。そして、音声サーバ220から音声データを受信した場合は、フォーマットが変更された音声データを、外部システム300に送信し、外部システム300から音声データを受信した場合は、フォーマットが変更された音声データを、利用者端末50に出力するために、音声サーバ220に送信する。