以下に添付図面を参照して、本願の開示する通報システムおよび通信装置のいくつかの実施例を詳細に説明する。ただし、これらの実施例における例示で本発明が限定されるものではない。
なお、以下では、本願に開示する通報システムが適用されるグループ通信システムの基本的な構成例や動作例について図1〜図11を用いて説明した後に、ユーザに緊急事態が発生した場合における具体的な処理を図12〜図18を用いて説明する。
まず、本実施例に係るグループ通信システムのシステム構成について図1を用いて説明する。図1は、本実施例に係るグループ通信システムの構成例を示す図である。なお、以下では、通信装置の一例として、携帯端末装置を用いて説明するが、通信装置は、携帯端末装置以外の装置(たとえば、車載装置)であってもよい。
図1に示すように、本実施例に係るグループ通信システム100は、サーバ1と、携帯端末装置2と、車載装置3とを含んで構成される。グループ通信システム100では、同一のグループに所属するユーザ同士が音声や文字による通信(以下、「グループトーク」と記載する)を行う。
サーバ1は、グループトークサービスを提供する装置である。サーバ1は、たとえばパーソナルコンピュータ等の一般的なコンピュータであり、CPU(Central Processing Unit)等の制御部を備える。サーバ1の制御部は、携帯端末装置2からの要求に応じて、グループトークに関する各種の処理を実行する。
また、サーバ1は、ユーザ管理DB(データベース)11aおよびグループ管理DB(データベース)11bを含んだデータベースを備える。
ユーザ管理DB11aは、グループトークサービスに加入しているユーザに関する情報を管理するデータベースである。このユーザ管理DB11aは、たとえば、ユーザのID、氏名、現在位置といった情報をユーザ管理情報として管理する。
また、グループ管理DB11bは、ユーザによって形成されるグループに関する情報を管理するデータベースである。このグループ管理DB11bは、たとえば、グループのID、グループ名、グループに所属するユーザのIDといった情報をグループ管理情報として管理する。
なお、ユーザ管理情報およびグループ管理情報の具体的な内容については、図4Aおよび図4Bを用いて後述する。
携帯端末装置2は、たとえばスマートフォンや携帯電話であり、インターネットや無線通信網といったネットワーク50を介してサーバ1と相互に接続される。また、携帯端末装置2は、Wi−Fi(登録商標)やブルートゥース(登録商標)などの近距離無線通信を用いて車載装置3と接続する。
車載装置3は、ユーザが運転する車両70に搭載される車載装置である。かかる車載装置3は、たとえば、表示機能やオーディオ再生機能、携帯端末装置2との通信機能といった基礎的な機能のみを実装し、携帯端末装置2と連携することで多機能化する。なお、車載装置3は、これに限ったものではなく、上述した基礎的な機能以外の機能(たとえば、ナビゲーション機能)を備えていてもよい。
なお、携帯端末装置2/車載装置3間の通信は、たとえばZigBee(登録商標)等の他の無線通信規格を用いた近距離無線通信であってもよい。また、携帯端末装置2/車載装置3間の通信を有線通信で行うこととしてもよい。また、ここでは、車両70が電気自動車であるものとするが、車両70は、電気自動車に限らず、ハイブリッド車やガソリン車であってもよい。
次に、車両70に設置される車載装置3等の機器について図2を用いて説明する。図2は、車両70に設置される機器を示す図である。図2に示すように、車両70には、車載装置3、認証装置4、マイク5、スピーカ6、メーデースイッチ7等が設けられる。
認証装置4は、車両70へ乗車したユーザの認証を行うための装置である。具体的には、認証装置4は、RFID(Radio Frequency Identification)等の近距離無線通信を用いて携帯端末装置2からユーザIDを取得し、取得したユーザIDを車載装置3へ受け渡す処理を行う。
なお、ここでは、認証装置4が取得するユーザIDが、携帯端末装置2の固体識別情報(UID)であるものとするが、ユーザIDは、UID以外の識別情報であってもよい。
マイク5は、ユーザの音声を音声データとして取得する音声入力部である。マイク5によって取得された音声データは、車載装置3へ受け渡される。また、スピーカ6は、車載装置3から受け取った音声データに基づく音声を出力する音声出力部である。
ここでは、マイク5およびスピーカ6がハンドルに設けられるものとするが、マイク5およびスピーカ6は、ハンドル以外の場所に設置されてもよい。たとえば、スピーカ6は、車両70の天井、ドアやフロントパネル等に設置されてもよい。
車載装置3は、フロントパネルの中央、言い換えれば、ドライバーから見て左斜め前方に設置される。ただし、これに限ったものではなく、車載装置3は、フロントパネルの右端、言い換えれば、ドライバーから見て右斜め前方に設置されてもよいし、フロントパネル以外の場所に設置されてもよい。
メーデースイッチ7は、たとえば、ユーザに身体的な異常が発生した場合や車両70の走行用の電池の残量が所定量未満となった場合などに、ユーザによって押下される物理的なスイッチである。グループ通信システム100では、かかるメーデースイッチ7が押下されることで、ユーザに緊急事態が発生したことが、グループトークサービスに加入する他のユーザに対して通知される。かかる点については、実施例2において具体的に説明する。
なお、車両70には、図2に示す機器以外の機器が設置されてもよい。たとえば、車両70には、車両周辺や車内を撮影するカメラが設置されてもよい。
次に、携帯端末装置2および車載装置3の構成について図3を用いて説明する。図3は、携帯端末装置2および車載装置3の構成を示すブロック図である。なお、図3では、携帯端末装置2および車載装置3の特徴を説明するために必要な構成要素のみを示しており、一般的な構成要素についての記載を省略している。
携帯端末装置2は、近距離通信インタフェース21と、位置情報取得部22と、記憶部23と、制御部24とを備える。また、記憶部23は、ユーザID23aと、グループトークアプリケーションソフトウェア23bと、地図情報23cと、車載装置連携アプリケーションソフトウェア23dとを記憶する。また、制御部24は、認証処理部24aと、アプリ実行部24bと、ナビゲーション部24cと、緊急状態検出部24dとを備える。さらに、アプリ実行部24bは、画像生成部241と、受信処理部242と、送信処理部243とを備える。
一方、車載装置3は、近距離通信インタフェース31と、タッチパネルディスプレイ32と、記憶部33と、制御部34とを備える。また、記憶部33は、設定情報33aを記憶する。また、制御部34は、認証処理部34aと、操作情報送信部34bと、表示制御部34cと、音声出力制御部34dと、音声認識処理部34eと、実行指示部34fとを備える。
なお、図3に示すように、携帯端末装置2には車載装置3との連携動作を実現するための車載装置連携アプリケーションソフトウェア23dが搭載されている。また、車載装置3には携帯端末装置2との間で連携動作を行う連携機能が搭載されている。これにより、たとえば、携帯端末装置2から各種アプリケーションによって生成された画像データが車載装置3に伝送されて車載装置3のタッチパネルディスプレイ32に表示され、また車載装置3からタッチパネルディスプレイ32等への操作内容を示す操作情報等が携帯端末装置2へ伝送されて携帯端末装置2がかかる操作情報に基づいて処理を行う、といった連携動作が実現される。
なお、車載装置連携アプリケーションは、グループトークアプリケーション以外のアプリケーションとも連携し、かかるアプリケーションを車載装置3のタッチパネルディスプレイ32や図示しないハードスイッチ等を用いて使用することが可能となる。このように、車載装置連携アプリケーションは、OS(Operation System)およびアプリケーションの中間的な性質を持ったアプリケーションである。
まず、携帯端末装置2の構成について説明する。近距離通信インタフェース21は、車載装置3との間で近距離無線通信を行うための通信デバイスである。また、位置情報取得部22は、たとえばGPS(Global Positioning System)受信部であり、測位衛星から提供される位置情報を取得し、取得した位置情報をアプリ実行部24bやナビゲーション部24cへ渡すデバイスである。
記憶部23は、不揮発性メモリやハードディスクドライブといった記憶デバイスであり、ユーザID23a、グループトークアプリケーションソフトウェア23b、地図情報23cおよび車載装置連携アプリケーションソフトウェア23dを記憶する。
ユーザID23aは、たとえば携帯端末装置2のUIDである。なお、ユーザID23aは、UIDに限ったものではなく、たとえば、ユーザによって任意に設定されるIDであってもよいし、サーバ1によって自動的に割り振られるIDであってもよい。
グループトークアプリケーションソフトウェア23bは、サーバ1によって提供されるグループトークサービスを実現するためのソフトウェアである。地図情報23cは、記憶部23に予め記憶されていてもよいし、地図情報を保有するサービスセンタから必要な地図情報のみを適宜ダウンロードすることとしてもよい。車載装置連携アプリケーションソフトウェア23dは、車載装置3との連携動作を実現するためのソフトウェアである。かかる車載装置連携アプリケーションソフトウェア23dは、たとえば、サーバ1からダウンロードすることができる。
制御部24は、携帯端末装置2全体を制御する制御部であり、認証処理部24a、アプリ実行部24b、ナビゲーション部24cおよび緊急状態検出部24dを備える。また、制御部24は、近距離通信インタフェース21による近距離無線通信を用いて車載装置3との間で通信リンクを確立する処理等も行う。
認証処理部24aは、認証装置4からの要求に応じてユーザID23aを認証装置4へ送信する処理を行う処理部である。認証装置4へ送信されたユーザID23aは、認証装置4によって車載装置3の認証処理部34aへ受け渡される。
アプリ実行部24bは、グループトークアプリケーションに従ってグループトークに関する各種の処理を実行する処理部である。具体的には、アプリ実行部24bは、画像生成部241、受信処理部242および送信処理部243を備える。
画像生成部241は、グループトークに関する各種の画像を生成し、生成した画像を近距離通信インタフェース21経由で車載装置3へ送信する処理部である。
たとえば、この画像生成部241は、グループの選択候補画像に加え、グループに所属する各メンバーの所在地を示す所在地画像を含んだグループ選択画像を生成する。かかる点については、後述する。
受信処理部242は、サーバ1から送信される各種情報を受信する処理部である。たとえば、受信処理部242は、グループに所属する各メンバーの位置情報をサーバ1から受信し、受信した位置情報を画像生成部241へ受け渡す。
また、受信処理部242は、グループトークを行うグループトークモード中において、他のユーザの音声データをサーバ1から受信する受信処理を実行する。具体的には、受信処理部242は、音声データを含むトークデータをサーバ1から受信し、受信したトークデータを記憶部23へ記憶する。記憶部23に記憶されたトークデータは、ユーザによるタッチパネルディスプレイ32への入力操作に応じて記憶部23から取り出され、かかるトークデータに含まれる音声データがスピーカ6から出力されることとなる。
送信処理部243は、グループトークモード中において、マイク5を介して取得されるユーザの音声データを車載装置3から近距離通信インタフェース21経由で受信してサーバ1へ送信する送信処理を実行する。
具体的には、送信処理部243は、車載装置3から音声データを受信すると、位置情報取得部22から現在の位置情報を取得し、音声データ、位置情報、時刻、ユーザID、後述するグループID等を含んだトークデータをサーバ1へ送信する。
また、送信処理部243は、後述する緊急状態検出部24dから緊急事態が発生した旨の情報を受け取った場合に、緊急情報を生成してサーバ1へ送信する処理も行う。緊急情報は、ユーザに緊急事態が発生したことをあらわす情報であり、ユーザID23a、ユーザの位置情報、緊急状態の種別をあらわす種別情報などを含んだ情報である。ユーザID23aは、記憶部23から取得され、位置情報は、位置情報取得部22から取得される。また、種別情報は、緊急状態検出部24dから取得される。
このように、送信処理部243は、緊急状態検出部24dによって緊急状態が検出された場合に、緊急状態に関する緊急情報をサーバ1に対して送信する通報処理部の一例として機能する。
なお、アプリ実行部24bは、車載装置3の認証処理部34aからグループトークアプリケーションソフトウェア23bの起動指示を受信した場合に、かかる起動指示に従ってグループトークアプリケーションソフトウェア23bを起動させる処理も行う。また、アプリ実行部24bは、後述する緊急状態検出部24dからグループトークアプリケーションソフトウェア23bの起動指示を受信した場合にも、グループトークアプリケーションソフトウェア23bを起動させる。
ナビゲーション部24cは、位置情報取得部22によって取得された位置情報と、記憶部23に記憶される地図情報23cとを用いてユーザへの経路案内を行う処理部である。ナビゲーション部24cによって生成される経路案内情報は、アプリ実行部24bへ渡される。
緊急状態検出部24dは、緊急事態が発生したことを検出する処理部である。具体的には、緊急状態検出部24dは、メーデースイッチ7が押下された旨の情報を車載装置3から受信した場合に、緊急事態が発生したことを検出し、緊急事態が発生した旨の情報を送信処理部243へ通知する。
また、緊急状態検出部24dは、緊急状態の種別を判定する緊急状態種別判定処理も併せて行う。たとえば、緊急状態検出部24dは、車両70の電池の残量が所定量未満の状態で、車載装置3からメーデースイッチ7が押下された旨の情報を受信した場合には、緊急状態種別が「電池残量不足」であると判定する。ここで、緊急状態検出部24dは、車両70の電池残量を車載装置3から定期的に受信するものとする。
また、緊急状態検出部24dは、車両70の電池の残量が所定量未満でない状態で、車載装置3からメーデースイッチ7が押下された旨の情報を受信した場合には、緊急状態種別がユーザの「身体異常」であると判定する。
なお、ここで説明した緊急状態種別判定処理は、あくまでも一例である。たとえば、緊急状態検出部24dは、車両70に設置されるカメラを用いてユーザの表情を撮影し、撮影したユーザの表情から緊急状態種別「身体異常」を判定してもよい。また、緊急状態検出部24dは、車両70のハンドル等に設置される心拍計を用いてユーザの心拍数を計測し、計測した心拍数から緊急状態種別「身体異常」を判定してもよい。また、緊急状態検出部24dは、車両70の挙動から緊急状態種別「身体異常」を判定してもよい。
また、緊急状態検出部24dは、車両70のエアバッグが展開された旨の情報を車載装置3から受信した場合に、緊急状態種別が「車両事故」であると判定してもよい。かかる場合には、緊急状態検出部24dは、ユーザによってメーデースイッチ7が押下されなくとも、緊急事態が発生したことを検出するものとする。
つづいて、車載装置3の構成について説明する。近距離通信インタフェース31は、携帯端末装置2との間で近距離無線通信を行うための通信デバイスである。タッチパネルディスプレイ32は、各種画像を表示するためのディスプレイの表面に入力用のタッチパネルを付した入出力デバイスである。タッチパネルディスプレイ32は、ユーザから入力操作を受け付けると、受け付けた入力操作に応じた操作情報を操作情報送信部34bへ受け渡す。
記憶部33は、不揮発性メモリやハードディスクドライブといった記憶デバイスであり、設定情報33aを記憶する。設定情報33aは、たとえば、登録済みのユーザIDごとに、かかるユーザIDを持つユーザのユーザ名等を関連付けた情報を含んだ情報である。
また、設定情報33aには、「キラーワード」も含まれる。このキラーワードは、車両70に搭載されるエアコン等の機器、あるいは、携帯端末装置2が備えるナビゲーション部24c等を音声によって制御するための専用の言葉であり、たとえばユーザによってあらかじめ登録される。
制御部34は、車載装置3全体を制御する制御部であり、認証処理部34a、操作情報送信部34b、表示制御部34c、音声出力制御部34d、音声認識処理部34eおよび実行指示部34fを備える。
認証処理部34aは、認証装置4から受け取ったユーザIDに基づいてユーザ認証を行う処理部である。具体的には、認証処理部34aは、認証装置4から受け取ったユーザIDが設定情報33aに含まれるユーザIDと一致するか否かを判定し、一致すると判定した場合に、このユーザを認証する。
また、認証処理部34aは、ユーザを認証すると、グループトークアプリケーションソフトウェア23bの起動指示を近距離通信インタフェース31経由で携帯端末装置2のアプリ実行部24bへ送信する。これにより、携帯端末装置2のアプリ実行部24bは、グループトークアプリケーションソフトウェア23bを起動させる。
操作情報送信部34bは、タッチパネルディスプレイ32から受け取った操作情報を近距離通信インタフェース31経由で携帯端末装置2へ送信する処理部である。また、操作情報送信部34bは、メーデースイッチ7が押下された場合には、メーデースイッチ7が押下された旨の情報を携帯端末装置2へ送信する処理を行う。
表示制御部34cは、タッチパネルディスプレイ32に対して各種の画像を表示させる処理部である。たとえば、表示制御部34cは、近距離通信インタフェース31経由で携帯端末装置2から受信したグループ選択画像をタッチパネルディスプレイ32に対して表示させる処理を行う。
音声出力制御部34dは、携帯端末装置2から近距離通信インタフェース31経由でトークデータを受信し、受信したトークデータに含まれる音声データに基づいてスピーカ6から音声を出力させる処理を行う。
音声認識処理部34eは、マイク5を介して取得した音声データを近距離通信インタフェース31経由で携帯端末装置2へ送信する処理部である。また、音声認識処理部34eは、マイク5を介して取得した音声データから発話内容を認識する音声認識処理も行う。
また、音声認識処理部34eは、音声認識処理によって認識された発話内容と、設定情報33aに含まれるキラーワードとを比較し、発話内容にキラーワードが含まれると判定した場合には、このキラーワードを実行指示部34fへ受け渡す処理も併せて行う。
実行指示部34fは、音声認識処理部34eからキラーワードを受け取った場合に、受け取ったキラーワードに対応する処理をエアコン等の機器に対して実行させる処理を行う処理部である。また、実行指示部34fは、キラーワードに対応する処理がナビゲーションに関する処理である場合には、キラーワードに対応する処理を行わせるための制御データを近距離通信インタフェース31経由で携帯端末装置2へ送信する。
また、実行指示部34fは、後述する同期制御データを携帯端末装置2から近距離通信インタフェース31経由で受信した場合には、受信した同期制御データに含まれる制御データに応じて、該当する機器に対して該当する処理を実行させる。かかる点については、後述する。
なお、ここでは、携帯端末装置2および車載装置3の特徴を説明するために必要な構成や機能についてのみ示したが、携帯端末装置2および車載装置3は、上記以外の構成や機能を備えていても構わない。たとえば、車載装置3の音声出力制御部34dは、上述した動作だけでなく、楽曲や音声案内等の出力制御も行う。
次に、サーバ1が備えるユーザ管理DB11aおよびグループ管理DB11bによってそれぞれ管理されるユーザ管理情報およびグループ管理情報の内容について図4Aおよび図4Bを用いて説明する。図4Aは、ユーザ管理情報の一例を示す図であり、図4Bは、グループ管理情報の一例を示す図である。
図4Aに示すように、ユーザ管理情報は、ユーザIDに対して、「ユーザ名」項目、「アイコン画像」項目、「現在位置」項目、「経路」項目、「状態」項目、「所属グループ」項目、「救援意思」項目、「職業/資格」項目、「車両搭載装備」項目、「血液型」項目、「持病」項目および「緊急連絡先」項目を関連付けた情報である。
「ユーザ名」項目は、ユーザの氏名が格納される項目である。なお、ユーザ名は、本名ではなく、ニックネーム等であってもよい。「アイコン画像」項目は、たとえばユーザの顔写真など、ユーザを特定するアイコン画像としてユーザが任意に選択した画像が格納される項目である。
「現在位置」項目は、ユーザの位置情報が格納される項目である。具体的には、サーバ1は、各ユーザの携帯端末装置2から位置情報を定期的に収集して、ユーザ管理情報の「現在位置」項目を更新する。このように、サーバ1は、携帯端末装置2から位置情報を定期的に収集することによって各ユーザの所在地を管理する。
「経路」項目は、目的地までの予定経路、出発地から現在位置までの通過済み経路などの情報が格納される項目である。たとえば、サーバ1は、ナビゲーション部24cによって生成される経路案内情報を携帯端末装置2から取得して、「経路」項目を更新する。
「状態」項目は、ユーザの状態情報が格納される項目である。ユーザの状態情報とは、たとえば、車両70に乗車中か否かを示す情報である。たとえば、図4Aに示すユーザ管理情報の「状態」項目には、「乗車中」が格納されている。これは、ユーザID「U01」のユーザ(山田太郎)が、車両70に乗車中であることを示している。
ここで、ユーザが車両70に乗車中か否かは、携帯端末装置2から送信される情報によって特定することができる。
たとえば、携帯端末装置2は、グループトークアプリケーションソフトウェア23bの起動を車載装置3からの指示によって行った場合には、ユーザが乗車中である旨の情報をユーザIDとともにサーバ1へ送信する。また、携帯端末装置2は、ユーザ操作によってグループトークアプリケーションソフトウェア23bを起動させた場合には、ユーザが非乗車中である旨の情報をユーザIDとともにサーバ1へ送信する。そして、サーバ1は、携帯端末装置2から送信されるこれらの情報に基づいて、ユーザ管理情報の「状態」項目を更新する。
また、ユーザが車両70に乗車中か否かを判断する方法としては、車載装置3と携帯端末装置2との接続状態(近距離無線通信の通信状態)に基づいて判断する方法であってもよい。この場合、車載装置3と携帯端末装置2とが接続されている状態で、グループトークアプリケーション23bを起動させた場合には、ユーザが乗車中である旨の情報をユーザIDとともにサーバ1へ送信する。車載装置3と携帯端末装置2とが接続されていない状態で、グループトークアプリケーション23bを起動させた場合には、ユーザが非乗車中である旨の情報をユーザIDとともにサーバ1へ送信する。
「所属グループ」項目は、ユーザが所属するグループの識別情報(グループID)が格納される項目である。たとえば、図4Aに示す場合には、ユーザID「U01」に対して所属グループ「G01」、「G02」および「G03」が関連付けられている。これは、ユーザ「山田太郎」が、それぞれグループID「G01」、「G02」および「G03」によって識別される3つのグループに所属していることを示している。
「救援意思」項目は、グループトークサービスに加入するユーザの何れかが緊急事態に陥った場合に、救援に向かう意思があるか否か、すなわち、サーバ1から後述する救援要請情報を受信する意思があるか否かを示す情報が格納される項目である。たとえば、救援に向かう意思のあるユーザの「救援意思」項目には「あり」が格納される。
「職業/資格」項目は、ユーザの職業あるいはユーザが保有する資格に関する情報が格納される項目である。図4Aに示す例では、「職業/資格」項目に「医師」が格納される。「車両搭載装備」項目は、ユーザが所有する車両70に搭載される装備に関する情報が格納される項目である。たとえば、図4Aに示す例では、「車両搭載装備」項目に「走行用バッテリ」が格納される。
「血液型」項目は、ユーザの血液型に関する情報が格納される項目であり、「持病」項目は、ユーザの持病に関する情報が格納される項目である。また、「緊急連絡先」項目は、ユーザが緊急事態に陥った場合の緊急連絡先の電話番号が格納される項目である。
なお、図4Aに示すユーザ管理情報は、あくまで一例であり、図4Aに示した項目以外の項目をユーザ管理情報が含んでいてもよい。
つづいて、グループ管理情報の内容について図4Bを用いて説明する。図4Bに示すように、グループ管理情報は、グループIDに対して、「グループ名」項目、「トーク中」項目、「所属ユーザ」項目および「通信履歴」項目を関連付けた情報である。
ここで、「グループ名」項目は、グループIDに対応するグループのグループ名が格納される項目である。「トーク中」項目は、グループIDに対応するグループが現在グループトーク中であるか否かを示す情報が格納される項目である。たとえば、図4Bに示す場合には、「トーク中」項目に対して「○」が格納されている。これは、グループID「G01」のグループが現在グループトーク中であることを示している。
「所属ユーザ」項目は、グループIDに対応するグループに所属するユーザのユーザIDが格納される項目である。また、「通信履歴」項目は、「所属ユーザ」項目に格納される各ユーザIDと関連付けられ、各ユーザの通信履歴が格納される項目である。この通信履歴には、トークデータのほか、ユーザがグループトークに参加した時刻、グループトークから退会した時刻、あるいは、ユーザがグループトークに参加中か否かを示す情報等が含まれる。
このように、サーバ1は、グループトークにおける各グループの一覧情報であるグループ管理情報を記憶する記憶部としてグループ管理DB11bを備える。また、サーバ1は、各グループに所属するユーザが所有する携帯端末装置2から取得される位置情報を含んだユーザ管理情報を記憶する記憶部としてユーザ管理DB11aを備える。
次に、ユーザが認証装置4を用いてユーザ認証を行ってからグループトークが開始されるまでの各手順について、車載装置3のタッチパネルディスプレイ32に対して表示される画面を参照しつつ説明する。図5A〜図5Fは、タッチパネルディスプレイ32の表示例を示す図である。
グループトークサービスの加入者であるユーザは、車両70に乗車すると、まず、認証装置4に対して携帯端末装置2をかざす。これにより、携帯端末装置2の記憶部23に記憶されるユーザID23aが認証装置4によって読み取られ、車載装置3の認証処理部34aが、ユーザID23aと設定情報33aとを用いてユーザ認証を行う。
つづいて、認証処理部34aは、ユーザを認証すると、ユーザが認証された旨の情報をこのユーザのアイコン画像やユーザ名等とともに表示制御部34cへ受け渡す。そして、表示制御部34cは、これらの情報に基づいて認証成功画像を生成し、生成した認証成功画像をタッチパネルディスプレイ32に対して表示させる。
図5Aには、認証成功画像の一例を示している。図5Aに示すように、認証成功画像には、認証されたユーザのアイコン画像やユーザ名等が含まれる。
また、認証処理部34aは、ユーザを認証すると、グループトークアプリケーションソフトウェア23bの起動指示を携帯端末装置2のアプリ実行部24bへ送信する。そして、アプリ実行部24bは、かかる起動指示に従ってグループトークアプリケーションソフトウェア23bを起動させる。なお、本実施例では、グループトークアプリケーションソフトウェア23bを認証後に自動起動する方式としたが、認証後に自動起動するのではなく、認証後のユーザによる起動操作によって起動する方式でも良い。
つづいて、携帯端末装置2では、アプリ実行部24bの画像生成部241が、メニュー画面を生成し、生成したメニュー画面を車載装置3の表示制御部34cへ送信する。そして、車載装置3では、表示制御部34cが、画像生成部241から受信したメニュー画面をタッチパネルディスプレイ32に対して表示させる。
図5Bには、メニュー画面の一例を示している。図5Bに示すように、メニュー画面には、グループトークサービスを含む各種のサービスに対応する画像が含まれる。
ここで、ユーザによってグループトークサービスに対応する画像がタッチされたとする。かかる場合、車載装置3では、操作情報送信部34bが、タッチパネルディスプレイ32から操作情報を受け取り、受け取った操作情報を携帯端末装置2へ送信する。
携帯端末装置2では、送信処理部243が、グループトークサービスに対応する画像がタッチされた旨の操作情報を車載装置3から受信すると、グループ選択画像の生成に必要な情報を取得するための取得要求をユーザID23aや位置情報等とともにサーバ1へ送信する。
サーバ1は、これらの情報を受信すると、ユーザ管理DB11aを参照し、ユーザが所属するグループのグループIDを取り出す。たとえば、ユーザがユーザID「U01」の「山田太郎」である場合、サーバ1は、グループID「G01」、「G02」および「G03」を取り出す。
また、サーバ1は、取り出したグループIDに対応するグループ管理情報をグループ管理DB11bから取り出すとともに、取り出したグループ管理情報に含まれる所属ユーザのユーザIDに対応するユーザ管理情報をユーザ管理DB11aから取り出す。たとえば、サーバ1は、グループID「G01」に対応するグループ管理情報をグループ管理DB11bから取り出すとともに、このグループの所属ユーザ「U02」のユーザ管理情報をユーザ管理DB11aから取り出す。
そして、サーバ1は、ユーザ管理DB11aおよびグループ管理DB11bから取り出した情報を取得要求の送信元である携帯端末装置2へ送信する。
つづいて、携帯端末装置2では、受信処理部242が、サーバ1からグループ選択画像の生成に必要な情報を受信し、受信した情報を画像生成部241へ受け渡す。そして、画像生成部241は、受信処理部242から受け取った情報と、記憶部23に記憶される地図情報23cとに基づいて、グループ選択画像を生成する。
画像生成部241は、かかるグループ選択画像を生成すると、生成したグループ選択画像を車載装置3へ送信する。そして、車載装置3では、表示制御部34cが、画像生成部241から受信したグループ選択画像をタッチパネルディスプレイ32に対して表示させる。
また、画像生成部241は、受信処理部242から受け取った情報を記憶部23に一時的に記憶させる。
図5Cには、グループ選択画像の一例を示している。図5Cに示すように、グループ選択画像には、選択候補画像61と、所在地画像62とが含まれる。
選択候補画像61は、グループトークを開始させるグループの選択候補を示す画像である。具体的には、選択候補画像61は、選択候補となるグループにそれぞれ対応する画像を含んでいる。
この選択候補画像61は、選択候補となるグループのうち一部のグループを含んで構成される。具体的には、選択候補画像61は、選択候補となるグループの画像がユーザの操作に応じて仮想的に回転して切り替わる、いわゆるドラム式の表示形式を採用した画像である。
選択候補となるグループの画像には、たとえば、グループ名と、所属メンバーのアイコン画像とが含まれる。図5Cに示す場合、選択候補画像61には、グループ名「家族」のグループに対応する画像、「友人1」のグループに対応する画像および「同僚」のグループに対応する画像が含まれている。
また、グループ名「友人1」のグループに対応する画像には、このグループに所属するユーザとして、4人のユーザ(ここでは、ユーザA〜Dとする)のアイコン画像が含まれている。また、グループ「友人1」の画像の左右にそれぞれ位置するグループ「家族」の画像およびグループ「同僚」の画像には、グループ「家族」の所属メンバーの一部であるユーザZのアイコン画像およびグループ「同僚」の所属メンバーの一部であるユーザEのアイコン画像がそれぞれ含まれる。
なお、グループ名は、グループ管理情報に含まれる情報であり、所属メンバーのアイコン画像は、ユーザ管理情報に含まれる情報である。画像生成部241は、これらの情報を受信処理部242から受け取り、選択候補画像61を生成する。
選択候補画像61の中央位置は、選択候補画像61の中でフォーカスの合った位置であり、かかる位置に配置されるグループ(図5Cでは、「友人1」)、すなわち、フォーカスの合ったグループが、仮選択状態のグループとなる。
そして、所在地画像62は、選択候補画像61の中央位置に配置されるグループ(図5Cでは、「友人1」)に所属するユーザの所在を示す画像である。すなわち、所在地画像62は、仮選択状態のグループに所属するユーザの位置情報に応じた地図画像上の位置にユーザのアイコン画像を重畳させた画像である。
たとえば、図5Cに示す場合、選択候補画像61の中央には、グループ「友人1」の画像が配置されており、所在地画像62には、かかるグループ「友人1」の所属メンバーであるユーザA〜Dのアイコン画像が地図画像上に重畳されている。
この時、選択候補画像61の中央に位置するグループは仮選択状態にあり、この仮選択状態のグループに対応する所在地画像62が表示される。そして、タッチパネルディスプレイ32へのタッチ操作や押圧操作等の確定操作によって仮選択状態のグループの選択が確定され、この確定されたグループでグループトークが開始される。
なお、仮選択状態にないグループ、すなわち、選択候補画像61の中央に位置しないグループ(例えば、図5Cでは、グループ「友人1」の両隣に位置するグループ「家族」とグループ「同僚」)に対して、タッチパネルディスプレイ32へのタッチ操作や押圧操作を行ったとしても確定操作は行われず、タッチ操作あるいは押圧操作されたグループが選択候補画像61の中央に移動し、仮選択状態となる。このように、画像生成部241は、複数のグループの中から仮選択グループを指定するグループ指定手段の一例として機能する。
ここで、仮選択状態とは、選択候補画像61の中央に設けられたカーソルによって特定されたグループに所属するメンバーの状態を表示させており、グループトークに参加する前の状態である。
このように、本実施例に係るグループ通信システム100では、グループ選択画像として、選択候補画像61とともに、グループに所属するユーザの所在地を示す所在地画像62を併せて表示する。
したがって、ユーザは、グループのメンバーの所在地を把握したうえで、グループトークを行うか否かを決定することができる。すなわち、ユーザは、実際にグループトークを開始しなくとも、グループのメンバーがどこにいるのかを把握することができる。また、ユーザは、単に他のメンバーの所在地を把握したい場合に、一旦グループトークへ参加して直ぐに退会するといった煩雑な行動を取る必要がない。
また、本実施例に係るグループ通信システム100では、表示制御部34cが、選択候補となるグループのうち一部のグループを含んだ選択候補画像61をタッチパネルディスプレイ32へ表示させるとともに、タッチパネルディスプレイ32に対する入力操作に応じて選択候補画像61に含ませるグループを変更する。
具体的には、携帯端末装置2の画像生成部241は、車載装置3の操作情報送信部34bから選択候補画像61に対する入力操作(たとえば、左右へのスライド操作)の操作情報を受信すると、受信した操作情報に応じて、グループの画像をスライドさせた選択候補画像61をあらたに生成する。そして、画像生成部241は、あらたに生成した選択候補画像61を車載装置3の表示制御部34cへ送信する。
これにより、タッチパネルディスプレイ32には、ユーザのスライド操作に応じてグループの画像がスライドした選択候補画像61が表示される。たとえば、図5Dには、図5Cに示す選択候補画像61がユーザによって左方向へスライドされた結果、グループ「同僚」に対応する画像が中央に位置し、グループ「同僚」に所属するユーザE〜Gの所在を示す所在地画像62が表示された場合の例について示している。
このように、本実施例に係るグループ通信システム100では、選択候補画像61の表示形式をドラム式とすることで、タッチパネルディスプレイ32における選択候補画像61の表示領域を小さくでき、所在地画像62を表示させるスペースを確保することができる。
なお、ここでは、選択候補画像61の表示形式がドラム式である場合の例について説明したが、選択候補画像61の表示形式は、必ずしもドラム式である必要はない。また、選択候補画像61に含まれるグループの画像は、選択候補画像61および所在地画像62の配列方向と同一の方向に配列させても構わない。また、ここでは、選択候補画像61の下に所在地画像62が配置される場合の例を示したが、これとは逆に、所在地画像62の下に選択候補画像61が配置されてもよい。
なお、グループに所属するユーザの人数が多い場合、選択候補画像61におけるグループの画像には、一部のユーザだけが含まれるようにしてもよい。また、かかる場合、グループに所属するユーザの表示順序を、グループトークへ参加する可能性が高い順としてもよい。たとえば、グループトークへの参加率が高いほど、グループトークへ参加する可能性が高いと判断することができる。また、現在通信不能(オフライン)のユーザは、グループトークへ参加する可能性が低いと判断することができる。このように、グループ選択時においてタッチパネルディスプレイ32に表示されるユーザの表示順序を、グループトークへ参加する可能性が高い順とすることで、グループ選択をより適切に行うことができる。
また、グループに所属するユーザの表示順序を、グループトークへ参加した日時が古い順としたり、グループトークでの発言回数が多い順としたりしてもよい。たとえば、グループトークへの参加した日時が古いユーザほど、あるいは、グループトークでの発言回数が多いユーザほど、グループトークの話題の中心にいる可能性が高いと判断することができる。このように、グループ選択時においてタッチパネルディスプレイ32に表示されるユーザの表示順序を、グループトークの話題の中心にいる可能性が高い順とすることで、グループ選択をより適切に行うことができる。
また、画像生成部241は、受信処理部242から受け取った情報のうち所属メンバーの状態情報に応じて、地図画像上に重畳させるアイコン画像を変更する。
たとえば、ユーザAのユーザ管理情報に含まれる「状態」項目が「非乗車中」である場合、画像生成部241は、ユーザAのアイコン画像を地図画像上に重畳させる。一方、ユーザBのユーザ管理情報に含まれる「状態」項目が「乗車中」である場合、画像生成部241は、ユーザBのアイコン画像と車両のイラストとを組み合わせた画像を地図画像上に重畳させる。
このように、所属メンバーの状態に応じて地図画像上に重畳させる画像を変更することで、ユーザは、各メンバーの状態を把握することができる。
また、画像生成部241は、所属メンバーの各位置情報に基づいて地図画像の縮尺を決定する。すなわち、画像生成部241は、グループに所属する全てのユーザのアイコン画像が所在地画像62に含まれるように地図画像の縮尺を決定する。これにより、ユーザは、グループに所属する全てのユーザの所在地を容易に把握することができる。
なお、縮尺には上限(範囲を広げ過ぎない)を設け、その範囲内に位置しないメンバーについては、表示領域におけるメンバーの位置方向の端部にユーザのアイコン画像を配置するものとする。また、この場合、ユーザのアイコン画像に加工を施し(色調の変化やマーク付与等)、表示された地図の外側に当該ユーザが位置することが分かるようにすることが好ましい。
図5Dに戻り、選択候補画像61に含まれるグループ「同僚」の画像がユーザによってタッチ操作された場合について説明する。
ユーザが、選択候補画像61に含まれるグループ「同僚」の画像をタッチすると、グループ「同僚」の画像が中央位置に配置された選択候補画像61、すなわち、グループ「同僚」にフォーカスの合った選択候補画像61がタッチパネルディスプレイ32に表示される。また、仮選択状態のグループは、「友人1」から「同僚」へと変更される。これにより、タッチパネルディスプレイ32には、所在地画像62として、グループ「同僚」に所属するユーザの所在を示す画像が表示される。
グループ「同僚」の画像が選択候補画像61の中央位置に配置されたのち(すなわち、グループ「同僚」が仮選択状態となったのち)、グループ「同僚」の画像がユーザによってタッチ操作されると、車載装置3の操作情報送信部34bは、かかるタッチ操作に関する操作情報を携帯端末装置2へ送信する。そして、携帯端末装置2では、送信処理部243が、かかる操作情報を受信すると、グループ「同僚」のグループIDおよび自装置のユーザID等を含んだグループトーク開始要求をサーバ1へ送信する。
サーバ1は、携帯端末装置2からグループトーク開始要求を受信すると、かかるグループトーク開始要求からグループIDを取り出し、かかるグループIDに対応するグループに所属する各ユーザのユーザIDをグループ管理DB11bから取り出す。また、サーバ1は、取り出したユーザIDに対応するユーザの携帯端末装置2に対してグループトークへの参加の可否を確認する通知を送信する。
そして、グループに所属するいずれかのユーザからグループトークへの参加を許可する旨の通知を受信すると、サーバ1は、グループトークを開始させる。なお、メンバーからグループトークへ参加するか否かの応答があるまでの間、タッチパネルディスプレイ32には、図5Eに示すように、メンバーを呼び出し中である旨の画面が表示される。
このように、仮選択状態でないグループに対して選択操作を行うことで、選択されたグループが仮選択状態となる。さらに、仮選択状態のグループに対して選択操作を行うことで、仮選択状態のグループが、グループトークを開始するグループとして確定する。
図5Fに、グループトーク中にタッチパネルディスプレイ32に表示されるトーク中画像の一例を示す。以下では、図5Fを参照して、グループトークにおける処理内容について説明する。
グループトークモードへ移行すると、車載装置3では、音声認識処理部34eが、マイク5から音声データを取得する処理を開始し、携帯端末装置2では、送信処理部243が、トークデータの送信処理を開始する。
具体的には、車載装置3の音声認識処理部34eは、マイク5を介して音声データを取得し、取得した音声データを携帯端末装置2へ送信する。そして、携帯端末装置2では、送信処理部243が、車載装置3から音声データを受信すると、位置情報取得部22から位置情報を取得し、音声データ、位置情報、時刻、ユーザID、グループID等を含んだトークデータを生成しサーバ1へ送信する。
サーバ1は、携帯端末装置2からトークデータを受信すると、受信したトークデータを同一のグループに所属する他のユーザの携帯端末装置2に対して送信する。携帯端末装置2では、受信処理部242が、他の携帯端末装置2からのトークデータをサーバ1経由で受信すると、受信したトークデータを記憶部23へ記憶させる。
また、携帯端末装置2では、画像生成部241は、記憶部23にあらたなトークデータが記憶されると、あらたに記憶されたトークデータに含まれるユーザIDおよび位置情報を取り出す。また、画像生成部241は、取り出したユーザIDに対応するユーザのアイコン画像と所定の画像(たとえば、吹き出しの画像)とを組み合わせた画像(以下、「つぶやきマーク」と記載する)を生成する。
また、画像生成部241は、生成したつぶやきマーク65をトークデータから取り出した位置情報に応じた地図画像上の位置に重畳させたトーク中画像を生成し、生成したトーク中画像を車載装置3へ送信する。そして、車載装置3の表示制御部34cは、携帯端末装置2から受信したトーク中画像をタッチパネルディスプレイ32に対して表示させる。
これにより、図5Fに示すように、タッチパネルディスプレイ32には、地図画像上につぶやきマーク65が重畳されたトーク中画像が表示される。このトーク中画像は、グループに所属するユーザがトークデータを送信するごとに更新され、新たなつぶやきマーク65が地図画像上に追加されることとなる。
このように、表示制御部34cは、グループの中から一のグループを選択する選択操作が行われた場合に、選択されたグループに所属するユーザの携帯端末装置2と、自装置との間で通信リンクが確立された携帯端末装置2との間でグループトークを行うためのトーク中画像をタッチパネルディスプレイ32へ表示させる。
ユーザは、タッチパネルディスプレイ32に表示されたつぶやきマーク65をタッチすることによって、タッチしたつぶやきマーク65に対応する音声メッセージを聞くことができる。
具体的には、車載装置3では、操作情報送信部34bが、タッチパネルディスプレイ32からつぶやきマーク65へのタッチ操作に関する操作情報を受け取り、受け取った操作情報を携帯端末装置2へ送信する。また、携帯端末装置2では、アプリ実行部24bが、車載装置3から上記の操作情報を受信すると、記憶部23に記憶されたトークデータのうち、ユーザがタッチしたつぶやきマーク65に対応するトークデータから音声データを取り出して車載装置3へ送信する。
そして、車載装置3では、音声出力制御部34dが、携帯端末装置2が受信した音声データに基づき、ユーザがタッチしたつぶやきマーク65に対応する音声メッセージをスピーカ6から出力させる。
次に、サーバ1、携帯端末装置2および車載装置3の具体的動作について説明する。まず、携帯端末装置2が実行するアプリ起動時処理について図6を用いて説明する。図6は、アプリ起動時処理の処理手順を示すフローチャートである。
なお、アプリ起動時処理は、携帯端末装置2がグループトークアプリケーションソフトウェア23bの起動を指示されてから後述するグループ選択モードフラグまたはグループ形成モードフラグがオンされるまでの処理である。
図6に示すように、携帯端末装置2では、受信処理部242が、自装置から所定範囲内に所在するユーザのユーザ情報をサーバ1から取得し(ステップS101)、画像生成部241が、受信処理部242によって取得されたユーザ情報に基づき、地図画像上にユーザのアイコン画像を重畳させた画像を生成する(ステップS102)。
つづいて、携帯端末装置2では、送信処理部243が、「グループ選択モード」が選択されたか否かを判定する(ステップS103)。ここで、「グループ選択モード」とは、登録済みのグループからグループトークを開始するグループを選択するモードである。
たとえば、タッチパネルディスプレイ32には、ステップS102において生成された画像とともに、「グループ選択モード」を選択するための画像および後述する「グループ形成モード」を選択するための画像が表示される。そして、ユーザが「グループ選択モード」を選択するための画像に対してタッチ操作を行い、車載装置3の操作情報送信部34bが、かかる操作情報を携帯端末装置2へ送信することで、携帯端末装置2の送信処理部243は、「グループ選択モード」が選択されたと判定する。
ステップS103において「グループ選択モード」が選択されたと判定すると(ステップS103,Yes)、アプリ実行部24bは、グループ選択モードフラグをオンし(ステップS104)、アプリ起動時処理を終了する。
一方、「グループ選択モード」が選択されていない場合(ステップS103,No)、送信処理部243は、「グループ形成モード」が選択されたか否かを判定する(ステップS105)。そして、「グループ形成モード」が選択されたと判定すると(ステップS105,Yes)、アプリ実行部24bは、グループ形成モードフラグをオンして(ステップS106)、アプリ起動時処理を終了する。
なお、アプリ実行部24bは、ステップS105において「グループ形成モード」が選択されていない場合には(ステップS105,No)、処理をステップS101へ戻し、ステップS101以降の処理を繰り返す。
次に、携帯端末装置2が実行するグループ選択処理の処理手順について図7を用いて説明する。図7は、グループ選択処理の処理手順を示すフローチャートである。なお、グループ選択処理は、図6のステップS104においてグループ選択モードフラグがオンされた場合に実行される処理である。
図7に示すように、グループ選択処理を開始すると、携帯端末装置2の送信処理部243は、グループ選択画像の生成に必要な情報を取得するための情報取得要求をユーザID23aや位置情報等とともにサーバ1へ送信する(ステップS201)。
つづいて、携帯端末装置2では、受信処理部242が、グループ選択画像の生成に必要な情報をサーバ1から受信し(ステップS202)、画像生成部241が、選択候補画像61および所在地画像62を含んだグループ選択画像を生成する(ステップS203)。これにより、タッチパネルディスプレイ32には、表示制御部34cによってグループ選択画像が表示されることとなる。
つづいて、送信処理部243は、グループ確定操作がなされたか否かを判定する(ステップS204)。たとえば、送信処理部243は、選択候補画像61の中央位置に配置されるグループの画像、すなわち、仮選択状態のグループの画像に対してタッチ操作がなされた旨の操作情報を車載装置3から受信した場合に、グループ確定操作がなされたと判定する。
ステップS204においてグループ確定操作がなされたと判定すると(ステップS204,Yes)、アプリ実行部24bは、グループトークモード開始要求をサーバ1へ送信する(ステップS205)。そして、アプリ実行部24bは、グループ選択モードフラグをオフするとともに(ステップS206)、グループトークモードフラグをオンして(ステップS207)、グループ選択処理を終了する。
一方、ステップS204においてグループ確定操作がなされていない場合(ステップS204,No)、送信処理部243は、仮選択グループ変更操作がなされたか否かを判定する(ステップS208)。仮選択グループ変更操作とは、たとえば、仮選択状態でないグループの画像へのタッチ操作、あるいは、選択候補画像61に対するスライド操作のことである。送信処理部243は、選択候補画像61に対してこれらの操作がなされた旨の操作情報を車載装置3から受信した場合に、選択候補変更操作がなされたと判定する。
ステップS208において仮選択グループ変更操作がなされたと判定すると(ステップS208,Yes)、画像生成部241は、選択候補画像61を更新するとともに(ステップS209)、所在地画像62を更新し(ステップS210)、処理をステップS204へ戻す。なお、アプリ実行部24bは、仮選択グループ変更操作がなされていない場合にも(ステップS208,No)、処理をステップS204へ戻す。
次に、車載装置3が実行するグループトーク送信処理の処理手順について図8を用いて説明する。図8は、グループトーク送信処理の処理手順を示すフローチャートである。ここで、グループトーク送信処理は、グループトークモードフラグがオンされた場合に実行される処理のうち、トークデータ等の送信に関する処理である。なお、図8に示すグループトーク送信処理は、グループトークモードフラグがオンされている間、繰り返し実行される。
図8に示すように、グループトーク送信処理を開始すると、車載装置3の音声認識処理部34eは、マイク5を介して音声データを取得し(ステップS301)、取得した音声データに対して音声認識処理を行う(ステップS302)。
つづいて、音声認識処理部34eは、発話内容にキラーワードが含まれるか否かを判定する(ステップS303)。キラーワードとは、上述したように、車両70に搭載されるエアコン等の機器、あるいは、携帯端末装置2が備えるナビゲーション部24c等を音声によって制御するための専用の言葉である。
ステップS303において発話内容にキラーワードが含まれると判定した場合(ステップS303,Yes)、実行指示部34fは、キラーワードに対応する処理の実行指示を行う(ステップS304)。
このように、本実施例では、音声認識処理部34eが、マイク5を介して取得した音声データから発話内容を認識し、実行指示部34fが、音声認識処理部34eによる音声認識の結果、あらかじめ登録されたキラーワードが発話内容に含まれる場合に、キラーワードに応じた処理を実行させることとした。したがって、ユーザは、グループトークを楽しみながら、車両70に搭載されるエアコンやオーディオ等に対する操作を容易に行うことができる。
また、実行指示部34fは、他メンバー同期制御が設定されているか否かを判定する(ステップS305)。ここで、他メンバー同期制御とは、キラーワードに対応する処理を同一グループに所属する他のユーザの携帯端末装置2や車両70についても実行させる制御のことである。
なお、他メンバー同期制御の設定は、キラーワード毎に設定する構成、例えばキラーワードKW1についてはメンバー同期制御が設定され、キラーワードKW2にはメンバー同期制御が設定されていないと言った、キラーワード毎に他メンバーの携帯端末装置2等に対する処理を変更できる構成にするのが望ましい。
ステップS305において他メンバー同期制御が設定されている場合(ステップS305,Yes)、実行指示部34fは、ステップS304において実行指示した内容と同様の制御コマンドを含む同期制御データを携帯端末装置2に対して送信し(ステップS306)、グループトーク送信処理を終了する。このように、実行指示部34fは、あらかじめ登録されたキラーワードが発話内容に含まれる場合に、かかるキラーワードに応じた処理を実行させる旨の同期制御データを携帯端末装置2経由でサーバ1へ送信する。
一方、ステップS303において発話内容にキラーワードが含まれない場合(ステップS303,No)、制御部34は、現在のモードがトーク停止モードであるか否かを判定する(ステップS307)。たとえば、図5Fに示すトーク停止ボタン66がタッチ操作された場合、制御部34は、トーク停止モードであると判定する。
ステップS307において現在のモードがトーク停止モードではない場合(ステップS307,No)、音声認識処理部34eは、ステップS301において取得した音声データを携帯端末装置2へ送信する(ステップS308)。そして、制御部34は、ステップS308の処理を終えた場合、あるいは、ステップS305において他メンバー同期制御が設定されていない場合(ステップS305,No)に、グループトーク送信処理を終了する。また、制御部34は、ステップS307において現在のモードがトーク停止モードであると判定した場合にも(ステップS307,Yes)、グループトーク送信処理を終了する。
なお、音声認識処理部34eによって送信された音声データは、携帯端末装置2の送信処理部243によって受信される。そして、送信処理部243は、車載装置3から受信した音声データを所定の発話期間ごとに区切り、音声データ、位置情報、時刻、ユーザID、グループID等を含んだトークデータを生成してサーバ1へ送信する。
次に、携帯端末装置2が実行するグループトーク受信処理の処理手順について図9を用いて説明する。ここで、グループトーク受信処理は、グループトークモードフラグがオンされた場合に実行される処理のうち、トークデータ等の受信に関する処理である。なお、図9に示すグループトーク受信処理は、グループトークモードフラグがオンされている間、繰り返し実行される。
図9に示すように、グループトーク受信処理を開始すると、携帯端末装置2の画像生成部241は、所属メンバーの位置情報に応じて地図画像の縮尺を決定し(ステップS401)、決定した縮尺の地図画像上に所属メンバーのアイコン画像を重畳させる(ステップS402)。
これにより、タッチパネルディスプレイ32には、表示制御部34cによってトーク中画像が表示されることとなる。なお、所属メンバーのアイコン画像は、所属メンバーの状態に応じて決定される。たとえば、ユーザの状態情報が「乗車中」である場合には、ユーザ既定のアイコン画像および車両のイラストを組み合わせた画像が、ユーザのアイコン画像として用いられる。
つづいて、携帯端末装置2では、画像生成部241が、つぶやきマーク65の描画処理を行う(ステップS403)。すなわち、画像生成部241は、地図画像上につぶやきマーク65を追加したトーク中画像を生成する。
つづいて、受信処理部242は、同期制御データを受信したか否かを判定する(ステップS404)。かかる処理において同期制御データを受信していない場合(ステップS404,No)、送信処理部243は、つぶやきマーク65の選択操作がなされたか否かを判定する(ステップS405)。たとえば、送信処理部243は、つぶやきマーク65に対してタッチ操作がなされた旨の操作情報を車載装置3から受信した場合に、つぶやきマーク65の選択操作がなされたと判定する。
ステップS405においてつぶやきマーク65が選択されたと判定した場合(ステップS405,Yes)、アプリ実行部24bは、選択されたつぶやきマーク65に対応する音声データを記憶部23から取り出して車載装置3へ送信し(ステップS406)、処理を終える。なお、アプリ実行部24bは、ステップS405においてつぶやきマーク65の選択操作がなされていない場合にも(ステップS405,No)、処理を終える。
また、ステップS404において同期制御データを受信したと判定すると(ステップS404,Yes)、アプリ実行部24bは、同期制御データに含まれる制御コマンドに対応する処理の実行を指示し(ステップS407)、グループトーク受信処理を終了する。
なお、アプリ実行部24bは、同期制御データによる制御対象が車両70に搭載された機器である場合には、受信した同期制御データを車載装置3へ送信する。これにより、車載装置3の実行指示部34fが、同期制御データに含まれる制御コマンドに対応する処理の実行を指示することとなる。また、同期制御データに含まれる制御コマンドに対応する処理を、ユーザによる実行許可操作後に実行するようにしても良い。
このように、実行指示部34fは、あらかじめ登録されたキラーワードが発話内容に含まれる場合に、キラーワードに応じた処理を実行させる旨の同期制御データを携帯端末装置2経由でサーバ1へ送信するとともに、サーバ1から携帯端末装置2経由で同期制御データを受信した場合には、受信した同期制御データに応じた処理を実行させる。
これにより、たとえば同一のグループに所属するメンバーのうちの1人が目的地の設定を音声操作により行うことで、残りのメンバーは目的地の設定操作を行うことなく同じ目的地を設定することができる。
ところで、ここでは、キラーワードに応じた処理の実行をグループトークに参加する全メンバー間で同期させる場合の例について説明したが、キラーワードに応じた処理の実行は、指定したメンバー間においてのみ同期させてもよい。
たとえば、ユーザは、キラーワードとともに、キラーワードに応じた処理を同期させたいユーザのユーザ名を発話する。実行指示部34fは、発話内容にキラーワードに加えてユーザ名が含まれる場合には、発話内容に含まれるユーザのユーザIDをさらに含んだ同期制御データを生成してサーバ1へ送信する。
そして、サーバ1は、受信した同期制御データに同期対象となるユーザのユーザIDが含まれる場合には、同期制御データに含まれるユーザIDに対応する携帯端末装置2に対してのみ同期制御データを送信する。
このように、実行指示部34fは、処理の実行対象となるユーザのユーザ名が発話内容に含まれる場合には、処理の実行対象となるユーザのユーザIDをさらに含んだ同期制御データを携帯端末装置2経由でサーバ1へ送信することとした。したがって、ユーザは、キラーワードに応じた処理を同期させるメンバーを任意に指定することができる。
なお、ここでは、キラーワードに応じた処理を同期させたいユーザのユーザ名を発話することで、同期対象となるメンバーを指定する場合の例について説明したが、同期対象となるメンバーをサーバ1のグループ管理DB11b等にあらかじめ登録しておいてもよい。このようにすれば、ユーザは、同期させたいユーザのユーザ名を発話する必要がなくなる。
次に、携帯端末装置2が実行する退会処理である端末側退会処理の処理手順について図10を用いて説明する。図10は、端末側退会処理の処理手順を示すフローチャートである。なお、退会処理とは、グループトークを終了するための処理のことである。
図10に示すように、端末側退会処理を開始すると、携帯端末装置2の送信処理部243は、退会操作がなされたか否かを判定する(ステップS501)。たとえば、送信処理部243は、タッチパネルディスプレイ32に表示される退会ボタン(図示せず)がタッチされた旨の操作情報を車載装置3から受信した場合に、退会操作がなされたと判定する。
ステップS501において退会操作がなされていない場合(ステップS501,No)、ナビゲーション部24cは、設定された目的地へ到着したか否かを判定する(ステップS502)。かかる処理において、目的地へ到着していない場合(ステップS502,No)、アプリ実行部24bは、処理を終了する。
一方、ステップS501において退会操作がなされたと判定した場合(ステップS501,Yes)、または、ステップS502において目的地へ到着したと判定した場合(ステップS502,Yes)、送信処理部243は、ユーザID23aおよびグループID等を含んだ退会データをサーバ1へ送信する(ステップS503)。そして、アプリ実行部24bは、グループトークモードフラグをオフし(ステップS504)、端末側退会処理を終了する。なお、ステップS502において目的地へ到着していない場合(ステップS502,No)にも、アプリ実行部24bは端末側退会処理を終了する。
このように、目的地に到着した場合にも退会データを送信することとした。これは、目的地に到着した場合、次の目的とする行動をするのが通常で、例えば自動車の場合は降車して施設に対応した行動を行うと言った状況が全く異なったものとなるため、グループトークから退会するのが通常である。このため、目的地に到着したことを条件として退会データを送信することなど退会処理を自動的に行えば、退会に必要な操作を行うことなく退会することができる。尚、念のために目的地到着後、ユーザの退会確認操作(退会確認ボタンを表示し、それに対するユーザの操作)に基づき退会処理を実行しても良い。
なお、目的地に到着した場合には、タッチパネルディスプレイ32に対してグループトークから退会するか否かの確認画面を表示させ、退会する旨の操作があった場合に、ステップS503以降の処理を行ってもよい。また、かかる場合には、ユーザの便を考慮し、確認画面を表示させてから所定時間以内に操作がなかった場合にも、ステップS503へ移行することとしてもよい。
次に、サーバ1が実行する退会処理であるサーバ側退会処理の処理手順について図11を用いて説明する。図11は、サーバ側退会処理の処理手順を示すフローチャートである。なお、この処理はユーザからの退会データの受信検知により実行する。
図11に示すように、サーバ1は、携帯端末装置2から退会データを受信したか否かを判定し(ステップS601)、受信したと判定すると(ステップS601,Yes)、該当グループの全メンバーがグループトークから退会したか否かを判定する(ステップS602)。かかる処理において全メンバーがグループトークから退会したと判定しない場合(ステップS602,No)、すなわち、グループトークへの参加者が1人でも存在する場合、サーバ1は、受信した退会データを既退会者を含む全メンバーの携帯端末装置2へ送信する(ステップS603)。
なお、携帯端末装置2では、サーバ1から退会データを受信すると、画像生成部241が、退会データの送信元であるユーザがグループトークから退会した旨のメッセージを生成し、車載装置3の表示制御部34cへ送信する。このとき、画像生成部241は、退会データの送信元であるユーザのアイコン画像を地図画像上から削除、あるいは表示形態を変更してもよい。
ステップS602において全メンバーがグループトークから退会したと判定した場合(ステップS602,Yes)、サーバ1は、解散データを既退会者を含む全メンバーの携帯端末装置2へ送信する(ステップS604)。解散データとは、グループトークが終了したことを示すデータである。携帯端末装置2では、サーバ1から解散データを受信すると、画像生成部241が、グループトークが終了した旨(グループが解散した旨)のメッセージを生成し、車載装置3の表示制御部34cへ送信する。
サーバ1は、ステップS603またはステップS604の処理を終えると、該当グループのグループ管理情報を更新し(ステップS605)、サーバ側退会処理を終了する。なお、サーバ1は、ステップS601において退会データを受信していない場合にも(ステップS601,No)、サーバ側退会処理を終了する。
このように、既に退会したメンバーに対しても退会データや解散データを送信することで、誰が何時退会したかあるいはグループが何時解散されたかを自分がグループから退会した後においても把握することができる。
なお、本例の場合、一度退会したメンバーがグループ存続を確認して復帰することを考慮して、全メンバーがグループトークから退会したと判定した場合(ステップS602,Yes)に解散処理を行ったが、グループトークが成立しない状態である残メンバーが一人になった場合に解散処理を行っても良い。
次に、上述してきたグループ通信システム100において、緊急事態が発生した場合の具体的な処理等について説明する。まず、サーバ1の構成について図12を用いて説明する。図12は、サーバ1の構成を示すブロック図である。なお、図12では、サーバ1の特徴を説明するために必要な構成要素のみを示しており、一般的な構成要素についての記載を省略している。
図12に示すように、サーバ1は、データベース11と、制御部12とを備える。また、データベース11は、ユーザ管理情報11aと、グループ管理情報11bと、絞り込み情報11cとを記憶する。また、制御部12は、グループトーク制御部12aと、救援要請部12bとを備える。
データベース11は、ハードディスクドライブ等の記憶デバイスであり、ユーザ管理情報11aと、グループ管理情報11bと、絞り込み情報11cとを記憶する。なお、ユーザ管理情報11aおよびグループ管理情報11bについては、図4Aおよび図4Bを用いて既に説明しているため、ここでの説明は省略する。
絞り込み情報11cは、救援を要請するユーザ、すなわち、後述する救援要請情報の送信先となるユーザを絞り込むために用いられる情報である。ここで、絞り込み情報11cの内容について図13を用いて説明する。図13は、絞り込み情報11cの一例を示す図である。
図13に示すように、絞り込み情報11cは、「緊急状態種別」項目に対して「職業/資格」項目および「車両搭載装備」項目を関連付けた情報である。たとえば、緊急状態種別「身体異常」には、職業/資格「医師」、「救急救命士」、「看護師」が関連付けられている。また、緊急状態種別「身体異常」には、車両搭載装備「AED」が関連付けられている。また、緊急状態種別「電池残量不足」には、車両搭載装備「走行用バッテリ」が関連付けられている。
なお、AED(Automated External Defibrillator:自動体外式除細動器)は、心臓の働きを取り戻すことを目的として人体に電気的なショックを与える医療機器である。このAEDの主要部品として大電力を蓄積でき、かつ急激に放電できるバッテリが必要であるが、走行用バッテリはその条件を満たしており比較的安価な構成追加で実現できる。また車載用ナビゲーション装置等の構成(ディスプレイやマイクロコンピュータ、音声出力回路等)を利用することにより、より安価に車載用AEDを実現できる。
図12に戻り、サーバ1の制御部12について説明する。制御部12は、サーバ1全体を制御する制御部であり、グループトーク制御部12aと、救援要請部12bとを備える。グループトーク制御部12aは、図1〜図11を用いて説明したグループトークに関する各種の処理を実行する処理部である。
救援要請部12bは、携帯端末装置2から緊急情報を受信した場合に、受信した緊急情報に基づく救援要請情報を生成し、生成した救援要請情報を、緊急情報の送信元であるユーザが所属するグループの所属メンバーの携帯端末装置2に対して送信する処理部である。
救援要請情報には、緊急情報の送信元であるユーザ(すなわち、緊急事態に陥っているユーザ)のユーザ名、アイコン画像、現在位置、血液型、持病、緊急連絡先等の情報を含んだ情報である。救援要請部12bは、携帯端末装置2から緊急情報を受信すると、受信した緊急情報に含まれるユーザIDから緊急事態に陥っているユーザを特定し、特定したユーザのユーザ管理情報を用いて救援要請情報を生成する。
このように、救援要請部12bは、緊急情報の送信元であるユーザが所属するグループの所属メンバーに対して救援要請情報を送信する。すなわち、救援を求めるユーザと身近な人に対して救援要請情報が送信されるため、救援要請情報を単純に送信する場合と比較して、救援要請情報を受けたユーザが救援を求めるユーザの元へ駆け付ける確率を高めることができる。このため、救援要請情報の送信に要する通信量を抑えつつ、適切な通報を行うことが可能となる。なお、救援要請情報の送信に要する通信量を抑えることで、たとえば、大規模災害や同時多発的に緊急事態が発生した場合にも、通信回線が混雑し、救援が遅れてしまうといった事態が防止される。
また、救援要請部12bは、救援要請情報を送信するユーザを所定の条件に基づいて絞り込む絞り込み処理を行う。
ここで、救援要請部12bが実行する絞り込み処理の内容について図14A〜図14Cを用いて説明する。図14A〜図14Cは、絞り込み処理の一例を示す図である。なお、図14Aには、ユーザU01が緊急事態に陥った場合の例を示している。また、図14Aに示すユーザU02〜U22は、ユーザU01が所属するグループの所属メンバーである。
図14Aに示すように、ユーザU01(図4Aに示す「山田太郎」)は、緊急事態に陥ると、メーデースイッチ7を押下する。携帯端末装置2では、緊急状態検出部24dが、メーデースイッチ7が押下された旨の情報を車載装置3から受信すると、緊急状態種別を判定し、送信処理部243が、ユーザID、現在位置情報、緊急状態種別等を含んだ緊急情報をサーバ1へ送信する。
つづいて、サーバ1の救援要請部12bは、携帯端末装置2から緊急情報を受信すると、受信した緊急情報に含まれる現在位置情報を用い、ユーザU01の現在位置を中心とする所定の距離範囲(以下、「対象範囲」と記載する)に所在するユーザU02〜U10をユーザ管理情報11aを参照して特定する。そして、救援要請部12bは、特定したユーザU02〜U10に対して救援要請情報を送信する。
このように、救援要請部12bは、グループトークにおける何れかのグループに所属し、かつ、緊急情報の送信元である携帯端末装置2から所定範囲内に位置するユーザの携帯端末装置2に対して救援要請情報を送信する。すなわち、救援要請情報の送信先となるユーザを、緊急事態に陥ったユーザの周囲に所在するユーザに絞り込むことにより、緊急事態に陥ったユーザのもとへ比較的早く駆けつけることのできるユーザに絞り込む。これにより、救援要請情報の送信に要する通信量をさらに抑えつつ、適切な通報を行うことができる。
また、救援要請部12bは、緊急状態の種別に応じて、救援要請情報を送信するユーザをさらに絞り込んでもよい。
たとえば、図14Bに示すように、ユーザU01からの緊急情報に含まれる緊急状態種別が「身体異常」であるとする(図14Bの(1)参照)。かかる場合、救援要請部12bは、絞り込み情報11cを参照し、緊急状態種別「身体異常」に対応する職業/資格「医師」、「救急救命士」および「看護師」を特定する。また、救援要請部12bは、ユーザ管理情報11aを参照し、図14Aに示すユーザU02〜U10の中から、職業/資格「医師」、「救急救命士」または「看護師」を保有するユーザを特定する。
たとえば、図14Bに示すように、ユーザU02が「医師」であり(図14Bの(2a)参照)、ユーザU07が「看護師」であり(図14Bの(2b)参照)、ユーザU10が「救急救命士」であるとする(図14Bの(2c)参照)。かかる場合、救援要請部12bは、ユーザU02、ユーザU07およびユーザU10に対して救援要請情報を送信する。同様に、「身体異常」に有効である可能性のある医療設備を持つ車両、例えば車両搭載装備「AED」を搭載する車両70を所有するユーザに対して救援要請情報を送信すると言ったことも有効である。
また、図14Cに示すように、ユーザU01からの緊急情報に含まれる緊急状態種別が「電池残量不足」であるとする(図14Cの(1)参照)。かかる場合、救援要請部12bは、絞り込み情報11cを参照し、緊急状態種別「電池残量不足」に対応する車両搭載装備「走行用バッテリ」を特定する。また、救援要請部12bは、ユーザ管理情報11aを参照し、図14Aに示すユーザU02〜U10の中から、「走行用バッテリ」を搭載する車両70を所有するユーザを特定する。
たとえば、図14Cに示すように、ユーザU06が走行用バッテリ搭載車を所有するとする(図14Cの(2a)参照)。かかる場合、救援要請部12bは、ユーザU06に対して救援要請情報を送信する。
このように、救援要請部12bは、受信した緊急情報に含まれる緊急状態種別情報とユーザ管理情報11aとに基づいて、緊急状態の種別に対応するユーザを抽出し、抽出したユーザの携帯端末装置2に対して救援要請情報を送信する。これにより、救援要請情報の送信先が、緊急状態に陥ったユーザの救援に適したユーザに絞られるため、救援要請情報の送信に要する通信量をさらに抑えつつ、適切な通報を行うことができる。
また、救援要請部12bは、受信した緊急情報に含まれる緊急状態種別情報とユーザ管理情報11aに含まれる車両搭載装備項目とに基づいて緊急状態の種別に対応する車両70を所有するユーザを抽出し、抽出したユーザの携帯端末装置2に対して救援要請情報を送信する。これにより、ユーザが運転する車両70に緊急事態が発生した場合に、救援要請情報の送信先が、救援に適した車両70を所有するユーザに絞られるため、救援要請情報の送信に要する通信量をさらに抑えつつ、適切な通報を行うことができる。
特に、救援要請部12bは、車両70の燃料(ここでは、電気自動車における走行用の電池)が所定未満であることを示す緊急状態種別「電池残量不足」を含んだ緊急情報を受信した場合には、燃料の補充が可能な車両70を所有するユーザを抽出する。これにより、ユーザが運転する車両70が電池切れ寸前となった場合に、救援要請情報の送信先が、充電可能な車両70を所有するユーザに絞られるため、救援要請情報の送信に要する通信量をさらに抑えつつ、適切な通報を行うことができる。
なお、図14A〜図14Cを用いて説明した絞り込み処理は、あくまでも一例であり、救援要請部12bは、その他の条件に従って絞り込み処理を行ってもよい。
たとえば、救援意思のあるユーザ、具体的には、図4Aに示すユーザ管理情報11aの「救援意思」項目に「あり」が関連付けられたユーザを、救援要請情報の送信先として絞り込んでもよい。このようにすれば、そもそも救援意思のないユーザに対して救援要請情報が送信されることがないため、救援要請情報の送信に要する通信量をさらに抑えることができる。
また、救援要請部12bは、たとえばグループ「家族」等のあらかじめ決められたグループに所属するユーザを救援要請情報の送信先として絞り込んでもよい。
また、ここでは、救援要請情報の送信先となるユーザを、緊急情報の送信元であるユーザが所属するグループの所属メンバーに限定する場合の例について説明したが、これに限ったものではない。すなわち、救援要請部12bは、グループトークサービスに加入する全てのユーザを救援要請情報の送信先候補としたうえで、緊急情報の送信元であるユーザの現在位置や、救援意思の有無、職業/資格、車両搭載装備情報等に応じて救援要請情報の送信先となるユーザを絞り込んでもよい。また、車両に限らず、家屋からグループトークに参加しているユーザを含めることも可能で、例えば「家屋の充電設備を提供可」と登録しておけば、近くで「電池残量不足」となった車両を救護することが可能となる。
次に、サーバ1から救援要請情報を受信した場合やメーデースイッチ7が押下された場合におけるタッチパネルディスプレイ32の表示例について図15Aおよび図15Bを用いて説明する。図15Aおよび図15Bは、タッチパネルディスプレイ32の表示例を示す図である。
図15Aには、サーバ1から救援要請情報を受信した場合におけるタッチパネルディスプレイ32の表示例、すなわち、救援を要請されたユーザのタッチパネルディスプレイ32に表示される画面の例を示している。
図15Aに示すように、サーバ1から救援要請情報を受信したユーザのタッチパネルディスプレイ32には、緊急情報の送信元であるユーザの所在地を示す画像67aおよびかかるユーザの所在地までの経路画像67bを地図画像上に重畳させた画像が表示される。これにより、救援要請情報を受信したユーザは、緊急情報の送信元であるユーザの所在地およびかかるユーザまでの経路を容易に把握することができる。
また、タッチパネルディスプレイ32には、「救援へ向かう」ボタン67cがさらに表示される。ユーザがかかる「救援へ向かう」ボタン67cを押下することによって、緊急情報の送信元であるユーザの所在地までの経路が設定される。これにより、救援へ向かうことを決めたユーザは、緊急情報の送信元であるユーザのもとへ迅速に駆け付けることができる。
また、図15Bには、メーデースイッチ7が押下された場合におけるタッチパネルディスプレイ32の表示例、すなわち、緊急事態に陥ったユーザのタッチパネルディスプレイ32に表示される画面の例を示している。
図15Bに示すように、緊急事態に陥ったユーザのタッチパネルディスプレイ32には、緊急連絡先を示す画像68a、緊急事態に陥ったユーザの顔画像68bおよび緊急事態に陥ったユーザに関する情報(ここでは、名前、想定される症状、血液型)を示す画像68cを含んだ画像が表示される。
かかる画像を緊急事態に陥ったユーザのタッチパネルディスプレイ32に表示させることで、緊急事態に陥ったユーザが意識を失っている場合であっても、車両70の周囲を通りがかった人に対して緊急事態が発生した等を知らせることができる。なお、図15Bに示す画像は、サーバ1から救援要請情報を受信したユーザのタッチパネルディスプレイ32に表示されてもよい。なお、特に身体異常や事故等の場合、これと並行して、ヘッドランプ等の灯火類を点滅させる、クラクションを特定のパターンで発呼させる等、周囲に緊急事態を気付かせる動作を行う事も有効である。
次に、携帯端末装置2が実行する緊急情報送信処理の処理手順について図16を用いて説明する。図16は、緊急情報送信処理の処理手順を示すフローチャートである。この処理は、自動車起動中(イグニッションキーON)あるいは自動車に搭乗者がいる場合(シートスイッチ等のセンサにより検知)に、繰り返し実行される。
図16に示すように、携帯端末装置2では、緊急状態検出部24dが、メーデースイッチ7が押下されたか否かを判定する(ステップS701)。具体的には、緊急状態検出部24dは、メーデースイッチ7が押下された旨の情報を車載装置3から受信した場合に、メーデースイッチ7が押下されたと判定する。なお、緊急状態検出部24dは、メーデースイッチ7が押下された旨の情報を受信していない場合には(ステップS701,No)、処理を終了する。
ステップS701においてメーデースイッチ7が押下されたと判定すると(ステップS701,Yes)、アプリ実行部24bは、グループトークアプリケーションソフトウェア23bを起動させる(ステップS702)。なお、ステップS702の処理は、グループトークアプリケーションソフトウェア23bが既に起動している状態であれば、省略される。
つづいて、緊急状態検出部24dは、緊急状態種別判定処理を行う(ステップS703)。たとえば、緊急状態検出部24dは、車両70の電池の残量が所定量未満の状態で、車載装置3からメーデースイッチ7が押下された旨の情報を受信した場合には、緊急状態種別が「電池残量不足」であると判定する。
また、アプリ実行部24bは、自装置の周囲に存在する携帯端末装置2に関する情報を収集する(ステップS704)。たとえば、アプリ実行部24bは、近距離通信インタフェース21を介して周囲の携帯端末装置2と接続し、接続した周囲の携帯端末装置2の電話番号やメールアドレスといった情報を収集する。なお、車載装置3の制御部34が自装置の周囲に存在する携帯端末装置2に関する情報を近距離通信インタフェース31経由で収集して携帯端末装置2へ受け渡してもよい。
つづいて、送信処理部243は、ステップS704において取得した周囲の携帯端末装置2に関する情報と、ステップS703において判定された緊急状態種別等を含んだ緊急情報とをサーバ1へ送信する(ステップS705)。
このように、グループ通信システム100では、緊急事態に陥ったユーザの周囲に位置する携帯端末装置2に関する情報もサーバ1へ送信される。そして、自装置の周囲に存在する携帯端末装置2には、サーバ1から救援要請情報が送信されることとなる。
これにより、サーバ1は、グループトークサービスに加入しているか否かにかかわらず、緊急事態に陥ったユーザの周囲に存在する人に対して救援要請情報を送信することができる。したがって、たとえばグループトークサービスに加入するユーザが緊急事態に陥ったユーザの周囲に存在しない場合であっても、迅速な救援を受けることができる。
なお、ステップS704の処理およびステップS705における周囲の携帯端末装置2に関する情報の送信は、必ずしも実行される必要はなく、たとえば救援要請情報の送信に要する通信量を考慮する場合には、ステップS704の処理を省略してもよい。
つづいて、送信処理部243は、周囲の携帯端末装置2に対して緊急情報送信要求を送信する(ステップS706)。ここで、緊急情報送信要求は、緊急情報をサーバ1に対して送信すべき旨の要求であり、緊急情報およびサーバ1のアドレス等を含んだ情報である。周囲の携帯端末装置2は、かかる緊急情報送信要求を受信すると、サーバ1に対して緊急情報を送信する。
このように、緊急情報を複数の携帯端末装置2からサーバ1へ送信することによって、より確実に救援を受けることが可能となる。なお、ステップS706の処理は、たとえば通信量を考慮する場合には省略してもよい。
そして、画像生成部241は、図15Bに示す緊急事態発生画像を生成して(ステップS707)、緊急情報送信処理を終了する。
なお、ここでは、図16に示すステップS701〜ステップS707の全ての処理を携帯端末装置2が実行する場合の例を示したが、ステップS701〜ステップS707の一部を車載装置3が実行してもよい。
特に、ステップS706の処理は、車載装置3が実行する場合に有効である。すなわち、緊急事態が車両事故等である場合、緊急事態に陥ったユーザの携帯端末装置2が故障し、かかる携帯端末装置2から緊急情報を送信できなくなるおそれがある。このような場合であっても、車載装置3の制御部34が、周囲の携帯端末装置2に対して緊急情報送信要求を送信することで、緊急情報をサーバ1に対して確実に送信することができる。
また、サーバ1との通信を携帯端末装置2ではなく車載装置3が行う場合、すなわち、車載装置3が通信装置である場合には、ステップS701の処理やステップS703〜S706の処理を車載装置3の制御部34が行ってもよい。かかる場合、車載装置3の制御部34が、緊急状態検出部および通報処理部として機能する。
次に、サーバ1が実行する救援要請処理の処理手順について図17を用いて説明する。図17は、救援要請処理の処理手順を示すフローチャートである。この処理は、常時繰り返し実行される。
図17に示すように、サーバ1の救援要請部12bは、携帯端末装置2から緊急情報を受信したか否かを判定し(ステップS801)、受信したと判定した場合には(ステップS801,Yes)、受信した緊急情報に基づき、緊急情報の送信元であるユーザ(以下、「要救援者」と記載する)と同一グループの所属メンバーを特定する(ステップS802)。なお、ステップS801において緊急情報を受信していない場合(ステップS801,No)、救援要請部12bは、処理を終了する。
つづいて、救援要請部12bは、ステップS802において特定されたユーザのうち救援要請情報の送信先となるユーザを、要救援者の位置情報を用いて絞り込む(ステップS803)。これにより、救援要請情報の送信先となるユーザが、要救援者に比較的近い位置に所在するユーザに絞り込まれる。
つづいて、救援要請部12bは、緊急状態種別が「身体異常」であるか否かを判定し(ステップS804)、「身体異常」であると判定した場合には(ステップS804,Yes)、救援要請情報の送信先となるユーザを、「身体異常」に対応する職業/資格を保有するユーザでさらに絞り込む(ステップS805)。
一方、ステップS804において緊急状態種別が「身体異常」ではない場合(ステップS804,No)、救援要請部12bは、緊急状態種別が「電池残量不足」であるか否かを判定する(ステップS806)。かかる処理において緊急状態種別が「電池残量不足」であると判定した場合(ステップS806,Yes)、救援要請部12bは、救援要請情報の送信先となるユーザを、「電池残量不足」に対応する車両70を所有するユーザでさらに絞り込む(ステップS807)。
また、ステップS806において緊急状態種別が「電池残量不足」ではない場合(ステップS806,No)、救援要請部12bは、その他の条件に応じて絞り込みを行う(ステップS808)。たとえば、救援要請部12bは、救援意思のあるユーザ、具体的には、図4Aに示すユーザ管理情報11aの「救援意思」項目に「あり」が関連付けられたユーザを、救援要請情報の送信先として絞り込んでもよい。救援要請部12bは、たとえばグループ「家族」等のあらかじめ決められたグループに所属するユーザを救援要請情報の送信先として絞り込んでもよい。
なお、このフローチャートでは、処理を分かりやすくするため「身体異常」と「電池残量不足」の条件で絞込み処理を行っているが、分岐処理を増やす、あるいはテーブルを用いた検索処理を行う等の方法により、多種多様な緊急状態種別に適した絞込み処理を行うことが可能となる。
ステップS805,S807,S808の処理を終えると、救援要請部12bは、救援要請情報の送信先として絞り込んだユーザの携帯端末装置2に対して救援要請情報を送信し(ステップS809)、救援要請処理を終了する。
なお、サーバ1が実行する救援要請処理の処理手順は、図17に示す処理手順に限定されるものではない。たとえば、救援要請部12bは、ステップS802の処理およびステップS803の処理を行わないこととしてもよい。すなわち、救援要請情報の送信先は、要救援者と同一グループの所属メンバーや、要救援者の近くに所在するユーザに限定されない。
次に、携帯端末装置2が実行する処理の処理手順について図18を用いて説明する。図18は、携帯端末装置2が実行する処理の処理手順を示すフローチャートである。
図18に示すように、携帯端末装置2では、緊急状態検出部24dが、救援要請情報を受信したか否かを判定し(ステップS901)、受信したと判定すると(ステップS901,Yes)、受信した救援要請情報に基づき、図15Aに示す緊急事態発生画像を生成する(ステップS902)。ステップS902において生成された緊急事態発生画像は、車載装置3のタッチパネルディスプレイ32に対して表示されることとなる。
つづいて、緊急状態検出部24dは、ユーザが救援へ向かうか否かを判定する(ステップS903)。具体的には、緊急状態検出部24dは、図15Aに示す「救援へ向かう」ボタン67cが押下された旨の情報を車載装置3から受信した場合に、ユーザが救援へ向かうと判定する。
ステップS903において、ユーザが救援へ向かうと判定すると(ステップS903,Yes)、ナビゲーション部24cは、要救援者までの経路を設定する(ステップS904)。
また、送信処理部243は、要救援者への連絡処理を行う(ステップS905)。具体的には、送信処理部243は、自装置のユーザが要救援者の救援へ向かう旨の情報をサーバ1へ送信する。かかる情報を受信したサーバ1は、要救援者の携帯端末装置2に対して上記のユーザが救援へ向かうことを示す情報を上記のユーザが到着するまでの予想時間等とともに送信する。これにより、要救援者は、救援に来る人物が存在することを知ることができる。
一方、ステップS901において救援情報を受信していない場合(ステップS901,No)、緊急状態検出部24dは、メーデースイッチ7が押下されたか否かを判定する(ステップS906)。かかる処理においてメーデースイッチ7が押下されたと判定すると(ステップS906,Yes)、送信処理部243は、緊急事態が発生した旨のトークデータである緊急事態発生トークデータを生成してサーバ1へ送信する(ステップS907)。また、ステップS906においてメーデースイッチ7が押下されていない場合(ステップS906,No)、アプリ実行部24bは、本処理を終える。
ステップS905またはステップS907の処理を終えたとき、あるいは、ステップS903において「救援へ向かう」ボタン67cが押下されない場合(ステップS903,No)、アプリ実行部24bは、グループトーク中処理を終了する。
上述してきたように、本実施例では、グループに所属するユーザ間でのメッセージの送受信をサーバ経由で行う携帯端末装置が、ユーザの緊急状態を検出する緊急状態検出部と、緊急状態検出部によって緊急状態が検出された場合に、緊急状態に関する緊急情報をサーバに対して送信する送信処理部とを備え、サーバが、携帯端末装置から緊急情報を受信した場合に、グループに所属する他のユーザの通信装置に対して緊急情報に基づく救援要請情報を送信する救援要請部を備えることとした。したがって、本実施例によれば、緊急事態が発生した場合に適切な通報を行うことができる。
なお、上述した実施例において携帯端末装置2が実行する処理は、車載装置3が実行してもよい。同様に、車載装置3が実行する処理を携帯端末装置2が実行してもよい。
たとえば、上述してきた実施例では、サーバ1との通信を携帯端末装置2が行う場合の例について説明したが、サーバ1との通信は、車載装置3が行ってもよい。また、上述してきた実施例では、携帯端末装置2がナビゲーション機能を備える場合の例について説明したが、ナビゲーション機能は、車載装置3が備えていてもよい。また、車載装置3が備える音声認識処理部34eや実行指示部34fを携帯端末装置2が備えていてもよい。
また、上述してきた実施例では、グループ通信システム100が、サーバ1と、携帯端末装置2と、車載装置3とを含んで構成される場合の例について説明したが、グループ通信システムの構成は、これに限ったものではない。たとえば、グループ通信システムは、携帯端末装置を含まず、サーバと車載装置とを含んで構成されてもよい。かかる場合には、車載装置が、図3に示す位置情報取得部22、記憶部23、アプリ実行部24b、ナビゲーション部24c、緊急状態検出部24dを備えていればよい。
また、グループ通信システムは、車載装置を含まず、サーバと携帯端末装置とを含んで構成されてもよい。かかる場合には、携帯端末装置が、操作情報送信部34b、表示制御部34c、音声出力制御部34d、音声認識処理部34e、実行指示部34fを備えていればよい。
また、グループ通信システムは、緊急通報対応サーバおよびグループトークサーバの2つのサーバを備えていてもよい。かかる場合には、緊急通報対応サーバおよびグループトークサーバが連携することによって、図1に示すサーバ1と同様の動作を行うこととすればよい。
さらなる効果や変形例は、当業者によって容易に導き出すことができる。このため、本発明のより広範な態様は、以上のように表しかつ記述した特定の詳細および代表的な実施の形態に限定されるものではない。したがって、添付の特許請求の範囲およびその均等物によって定義される総括的な発明の概念の精神または範囲から逸脱することなく、様々な変更が可能である。