JP2011119910A - アラートコールシステム及び処理方法 - Google Patents

Abstract

【課題】アラートコール（緊急の呼び出し）の伝達性をさらに向上させる。
【解決手段】アラートコールであることを示す情報と共に発呼を受けると、前記発呼をした発呼側端末のユーザと、前記発呼に対する着呼側端末のユーザとがアラートコールの発着呼を許諾する取り決めを結んでいることを確認した上で前記発呼をアラートコールとして回線をつなぎ、前記着呼側端末のユーザが不在であると判断される場合には、前記発呼側端末からの音声入力をアラートメッセージとして受け付けて、一時的に蓄積し、蓄積した前記アラートメッセージを、辞書データベースを用いてテキスト変換し、テキスト変換後の前記アラートメッセージを前記着呼側端末へ電子メールとして送付する。
【選択図】図１

Description

本発明は、アラートコールシステム及び処理方法に関し、特に、アラートコールの伝達性を向上する技術に関する。

従来、携帯電話において、マナーモードやサイレントモードのように消音設定している際、発信者が緊急の用事で電話発呼しても着信側にて気付かない等により電話にでられず、リアルタイムなコミュニケーションが不可となる事象が発生していた。

本発明に関連する技術としては、例えば、特許文献１に記載の技術がある。当該関連技術は、携帯電話のいわゆるマナーモード時に緊急の特別呼び出しの通知を可能にすることを課題としたもので、あらかじめ契約している発信者／着信者間の緊急の特別呼び出しに対して、携帯電話がマナーモード設定に関係なく着信音を鳴らすことで解決する（段落００１９、００２０等参照）。

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

一方で、特許文献１は、着信音の鳴動が絶対に許されない特定の場所において周りの人たちに迷惑をかけないことを課題の少なくとも一つとしており（段落０００２）、むしろマナーモード設定に関係なく着信音を鳴らすことによって生じる課題を解決する技術の開示が主である記載箇所もある（段落００１６、００２２）。そのため、着信側が緊急の特別呼び出しに気づけないケースを残している。このことは、緊急のメッセージの着実な伝達という「伝達性」に問題点があると考えられる。

そこで本発明は、上記実情に鑑みて、アラートコールの伝達性をさらに向上させたアラートコールシステム及び処理方法を提供することを目的とする。

上記目的を達成するために本発明は、第１の態様として、呼制御サーバと、音声蓄積サーバと、テキスト変換サーバと、を含むアラートコールシステムであって、前記呼制御サーバは、アラートコールであることを示す情報と共に発呼を受けると、前記発呼をした発呼側端末のユーザと、前記発呼に対する着呼側端末のユーザとがアラートコールの発着呼を許諾する取り決めを結んでいることを確認した上で前記発呼をアラートコールとして回線をつなぐ呼制御手段を備え、前記音声蓄積サーバは、前記着呼側端末のユーザが不在であると判断される場合には、前記発呼側端末からの音声入力をアラートメッセージとして受け付けて、一時的に蓄積する音声蓄積手段を備え、前記テキスト変換サーバは、辞書データベースと、蓄積した前記アラートメッセージを前記辞書データベースを用いてテキスト変換するテキスト変換手段と、を備え、前記呼制御手段は、テキスト変換後の前記アラートメッセージを前記着呼側端末へ電子メールとして送付することを特徴とする、アラートコールシステムを提供するものである。

また、上記目的を達成するために本発明は、第２の態様として、アラートコールであることを示す情報と共に発呼を受けると、前記発呼をした発呼側端末のユーザと、前記発呼に対する着呼側端末のユーザとがアラートコールの発着呼を許諾する取り決めを結んでいることを確認した上で前記発呼をアラートコールとして回線をつなぎ、前記着呼側端末のユーザが不在であると判断される場合には、前記発呼側端末からの音声入力をアラートメッセージとして受け付けて、一時的に蓄積し、蓄積した前記アラートメッセージを、辞書データベースを用いてテキスト変換し、テキスト変換後の前記アラートメッセージを前記着呼側端末へ電子メールとして送付することを特徴とする、アラートコール処理方法を提供するものである。

本発明によれば、アラートコールの伝達性をさらに向上させたアラートコールシステム及び処理方法を提供することが可能となる。

本発明を好適に実施した実施形態の全体構成を示す図である。 図１の通信網１０２のアーキテクチャ構成を示す図である。 図１の携帯電話１００，１０１の構成を示す図である。 本実施形態に係るアラートコール処理を実行するための事前処理の流れを示すフローチャートである。 本実施形態に係るアラートコール処理の流れを示すフローチャートである。 本実施形態に係るアラートコール処理において着呼側ユーザが「不在」と判断される場合の処理の流れを示すフローチャートである。

図１に、本実施形態の全体構成を示す。本実施形態に係るシステムは、アラート証明書発行機能を持つ携帯電話１００と携帯電話１０１と通信網１０２を含む構成である。携帯電話１００と携帯電話１０１は、通信網１０２を介して通信可能に接続する。

通信網１０２は、無線アクセスネットワークノード１０３と無線アクセスネットワークノード１１１と、回線交換機１０４と、パケット交換機１１０と、呼制御サーバ１０５と、音声蓄積サーバ１０７と、音声ガイダンスサーバ１０８と、加入者管理サーバ１０９と、を有して構成される。

無線アクセスネットワークノード１０３と無線アクセスネットワークノード１１１は、無線アクセス制御機能を持つ。回線交換機１０４は、回線交換制御機能を持つ。パケット交換機１１０は、パケット交換制御機能を持つ。呼制御サーバ１０５は、セッション管理機能とアラート証明書識別機能とサービス切り替え機能を持つ。音声地区正規サーバ１０７は、音声データを一時的に蓄積する機能を持つ。音声ガイダンスサーバ１０８は、あらかじめ決められたパターン時に機械的に音声ガイダンスを携帯電話へ流す機能を持つ。加入者管理サーバ１０９は、携帯電話の加入者情報の管理する機能を持つ。

次に、図２を参照して図１の通信網１０２の各装置内部構成を示すと共に、各機能ブロック・各装置間の繋がりを説明する。図２において、通信インターフェースは「ＩＦ」と記載し、以下の実施形態の記載でも同様とする。

無線アクセスネットワークノード１０３は、携帯電話の発着信時に接続先交換機及び携帯電話を識別する処理部２０５と内部装置／外部装置と接続する為のＩＦ部２０４から構成され、ＩＦ部２０４は処理部２０５とＩＦ部２００とＩＦ部２０６とＩＦ部２２３と接続する。

無線アクセスネットワークノード１１１は、携帯電話の発着信時に接続先交換機及び携帯電話を識別する処理部２２６と内部装置／外部装置と接続する為のＩＦ部２２５から構成され、ＩＦ部２２５は処理部２２６とＩＦ部２２３とＩＦ部２２７とＩＦ部２０６と接続する。

回線交換機１０４は、携帯電話の音声発着信時に接続先無線アクセスネットワークノード及び呼制御サーバを識別する処理部２０７と内部装置／外部装置と接続する為のＩＦ部２０６から構成され、ＩＦ部２０６は処理部２０７とＩＦ部２０８とＩＦ部２０４とＩＦ部２２５と接続する。

パケット交換機１１０は、携帯電話のパケット処理時に接続先無線アクセスネットワークノード及び呼制御サーバを識別する処理部２２４と内部装置／外部装置と接続する為のＩＦ部２２３から構成され、ＩＦ部２２３は処理部２２４とＩＦ部２０８とＩＦ部２０４とＩＦ部２２５とＩＦ部２２０と接続する。

呼制御サーバ１０５は、アラート証明書識別機能とサービス切替機能と接続先サーバを識別機能を持つアプリケーション制御部２０９とサービス切替時にセッションＩＤを一時的に保持するセッション管理部２１０と内部装置／外部装置と接続する為のＩＦ部２０８から構成され、ＩＦ部２０８はアプリケーション制御部２０９とセッション管理部２１０とＩＦ部２２０とＩＦ部２１１とＩＦ部２１２とＩＦ部２１３とＩＦ部２０６と接続する。

テキスト変換サーバ１０６は、音声データをワード分割する機能と音声ワードを検索辞書中の該当するテキストと一致させる機能と分割テキスト化されたデータを文章としてマージする機能を持つアプリケーション制御部２１４と音声データのワード中の波長とテキストデータをリンク付けしたデータベースを持つ検索辞書ＤＢ２１５と内部装置／外部装置と接続する為のＩＦ部２１１から構成され、ＩＦ部２１１はアプリケーション制御部２１４と検索辞書ＤＢ２１５とＩＦ部２０８とＩＦ部２１２とＩＦ部２１３と接続する。

音声蓄積サーバ１０７は、呼制御サーバより受信した音声データと発信者の情報を一致させてテキスト変換サーバにて変換が完了するまで一時的に保存管理する制御を行うアプリケーション制御部２１６と音声データを一時的に保存するキャッシュストレージ部２１７と内部装置／外部装置と接続する為のＩＦ部２１２から構成され、ＩＦ部２１２はアプリケーション制御部２１６とキャッシュストレージ部２１７とＩＦ部２０８とＩＦ部２１１とＩＦ部２１３と接続する。

音声ガイダンスサーバ１０８は、着信側がオフフックしない場合にサービス切替に移行する際の特定の音声ガイダンスを発信側携帯電話１０１へ流す機能を持つアプリケーション制御部２１８とガイダンスとして流す音声データを保存するガイダンス用音声ＤＢ２１９と内部装置／外部装置と接続する為のＩＦ部２１３から構成され、ＩＦ部２１３はアプリケーション制御部２１８とガイダンス用音声ＤＢ２１９とＩＦ部２０８とＩＦ部２１１とＩＦ部２１２と接続する。

加入者管理サーバ１０９は、携帯電話の契約者データ及び所在地を特定する情報を制御するアプリケーション制御部２２１と加入者情報を保存する加入者ＤＢ２２２と内部装置／外部装置と接続する為のＩＦ部２２０から構成され、ＩＦ部２２０はアプリケーション制御部２２１と加入者ＤＢ２２２とＩＦ部２０８とＩＦ部２２３と接続する。

図２に示した各サーバが有する諸機能は、例えば、汎用の電子計算機にソフトウェアプログラムを実行させて、そのハードウェアとソフトウェアプログラムの協働によって実現することができる。また、そのようなソフトウェアプログラムは、電磁的あるいは光学的な方法によってコンピュータ読取可能な記録媒体に記録させることができる。

次に、図３を参照して図１の携帯電話１００，１０１の各装置内部構成を説明する。図３（ａ）は携帯電話１００の構成を示す。携帯電話１００は、アプリケーション制御を行うアプリケーション制御部２０１とアラート証明書の発行と相互認証を行う認証部２０２と電話帳及び関連する個人情報を管理する電話帳ＤＢ部２０３と内部装置／外部装置と接続する為のＩＦ部２００から構成され、ＩＦ部２００はアプリケーション部２０１と認証部２０２と電話帳ＤＢ部２０３とＩＦ部２０４と接続する。

図３（ｂ）は携帯電話１０１の構成を示す。携帯電話１０１はアプリケーション制御を行うアプリケーション制御部２２８とアラート証明書の発行と相互認証を行う認証部２２９と電話帳及び関連する個人情報を管理する電話帳ＤＢ部２３０と内部装置／外部装置と接続する為のＩＦ部２２７から構成され、ＩＦ部２２７はアプリケーション部２２８と認証部２２９と電話帳ＤＢ部２３０とＩＦ部２２５と接続する。

図３に示した各携帯電話が有する諸機能は、例えば、通常の携帯端末にソフトウェアプログラムを実行させて、そのハードウェアとソフトウェアプログラムの協働によって実現することができる。また、そのようなソフトウェアプログラムは、電磁的あるいは光学的な方法によってコンピュータ読取可能な記録媒体に記録させることができる。

以下、図１ないし図３を参照して説明した本実施形態の構成によるアラートコール処理について説明する。まず、図４を参照して、アラートコール処理を実行するための事前処理について説明する。

＜アラートコール処理を実行するための事前処理＞
アラートコールを設定しようとするユーザを、以下、「設定ユーザ」という。また、設定ユーザがアラートコールの設定対象に選ぶユーザを、以下、「設定対象ユーザ」という。

なお、図４において、ステップＳ１０１、Ｓ１０２、Ｓ１０９が設定ユーザ側の携帯電話１０１が実行する処理、ステップＳ１０３、Ｓ１０４が通信網１０２で実行される処理、ステップＳ１０５〜Ｓ１０８、Ｓ１１０が設定対象ユーザ側の携帯電話１００が実行する処理である。

設定ユーザが携帯電話１０１で電話帳を起動すると、アプリケーション制御部２２８が電話帳ＤＢ部２３０より電話帳データを引き出す。すると、ＩＦ部２２７を介して携帯電話１０１の画面上に電話帳が表示される。

設定ユーザが、表示された電話帳よりアラートコールの設定対象とするユーザを選択すると、携帯電話１０１の画面上に選択されたユーザの電話番号やメールアドレス等のデータが表示され、画面上に表示される「アラートコール設定」ボタンを選択すると携帯電話１０１の画面上に「アラートコール受信許諾処理を行っております。結果が届き次第、お知らせいたします」と表示され、電話帳は自動的に閉じられる。

設定ユーザが「アラートコール設定」ボタンを選択すると、アプリケーション制御部２２８はＩＦ部２２７を経由して認証部２２９へ「アラートコール証明書」発行依頼を行い、認証部２２９は「アラートコール証明書」をＩＦ部２２７を経由してアプリケーション制御部２２８へ送る。この事前処理における、アプリケーション制御部２２８が行うここまでの処理をアラートコール設定指示受付処理という（図４のステップＳ１０１）。

アプリケーション制御部２２８は、「携帯電話１０１の加入者情報」と「相手の電話番号」と「アラートコール証明書」をＩＦ部２２７とＩＦ部２２５とＩＦ部２２３とＩＦ部２０８を経由してアプリケーション制御部２０９へ送付する（ステップＳ１０２）。

アプリケーション制御部２０９は、「相手の電話番号」をＩＦ部２０８とＩＦ部２２０を経由してアプリケーション制御部２２１へ送付し、アプリケーション制御部２２１は加入者ＤＢ２２２より「相手の電話番号」と一致するユーザのルーティング情報を取り出し、ＩＦ部２２０とＩＦ部２０８を経由してアプリケーション制御部２０９へ送付する。

なお、ここで、ルーティング情報とは、ユーザがどの無線アクセスネットワークノードの配下に在圏しているか（又はどこにも在圏していないか）を示す情報である。説明の便宜のため、ここで送付されるルーティング情報は、「パケット交換機１１０と無線アクセスネットワークノード１０３の配下に在圏」という情報であるものとする。

つまり、呼制御サーバ１０５のアプリケーション制御部２０９が行うここまでの処理は、設定対象ユーザのルーティング情報を確認する処理である（ステップＳ１０３）。

アプリケーション制御部２０９は、ルーティング情報を元に着信側携帯電話１００の在圏するＩＦ部２０８とＩＦ部２２３とＩＦ部２０４とＩＦ部２００を経由してアプリケーション制御部２０１へ「携帯電話１０１の加入者情報（電話番号／ユーザ名）」と「アラートコール証明書」と「アラートコール証明書発行依頼」を送付する（ステップＳ１０４）。

「アラートコール証明書発行依頼」は設定対象ユーザ側の携帯電話である携帯電話１００にて受け付けられる（ステップＳ１０５）。この受付処理には、設定対象ユーザへの通知と、設定対象ユーザの諾否を問い合わせる処理が含まれる。具体的には、携帯電話１００の画面上に、「携帯電話１０１のユーザよりアラートコール証明書発行依頼が届いております。」というメッセージが表示され、「許諾」「拒否」を選択可能となる。アプリケーション制御部２０１がユーザの入力を確認し、諾否を判断する（ステップＳ１０６）。設定対象ユーザが「許諾」を選択した場合にはステップＳ１０７へ、「拒否」を選択した場合にはステップＳ１１０へ遷移する。

設定対象ユーザが「許諾」を選択した場合、アプリケーション制御部２０１はＩＦ部２００を経由して認証部２０２に携帯電話１０１の「アラートコール証明書」を保存し（ステップＳ１０７）、認証部２０２より携帯電話１００の「アラートコール証明書」を取り出しＩＦ部２００とＩＦ部２０４とＩＦ部２２３とＩＦ部２２５とＩＦ部２２７を経由してアプリケーション制御部２２８へ送付する（ステップＳ１０８）。

アプリケーション制御部２２８はＩＦ部２２７を経由して認証部２２９に携帯電話１００の「アラートコール証明書」を保存する（ステップＳ１０９）。ここまでの処理が事前に実施されている場合、アラートコール処理を行う事が可能となる。

一方で、設定対象ユーザが「拒否」を選択した場合、アプリケーション制御部２０１は受信した「アラートコール証明書」を破棄し（ステップＳ１１０）、「拒否通知」をＩＦ部１００とＩＦ部１０３とＩＦ部２２３とＩＦ部２２５とＩＦ部２２７を経由してアプリケーション制御部２２８へ送付する。携帯電話１０１上で「アラートコール設定を拒否されました。」という旨の表示が行われ、設定処理に関しては中止となり、アラートコール処理を行う事が不可能となる。

以下では、図４の処理後、お互いの携帯電話１００，１０１が認証部２０２、２２９にアラートコール証明書を保存しており、アラートコール設定がなされた状態における処理を説明する。

＜アラートコール処理＞
図５に本実施形態のアラートコール処理の流れを示す。なお、以下では、アラートコールを発呼しようとするユーザを「発呼側ユーザ」と呼び、着呼側のユーザを「着呼側ユーザ」と呼ぶ。

発呼側ユーザが携帯電話１０１で電話帳を起動すると、アプリケーション制御部２２８が電話帳ＤＢ部２３０より電話帳データを引き出すと、ＩＦ部２２７を介して携帯電話１０１の画面上に電話帳が表示される。発呼側ユーザが表示された電話帳より、アラートコールの設定対象とするユーザを選択すると、携帯電話１０１の画面上に選択されたユーザの電話番号やメールアドレス等のデータが表示され、画面上に表示される「アラートコール」ボタンを選択すると携帯電話１０１の画面上に「アラートコーリング中」と表示される。発呼側ユーザが「アラートコール」ボタンを選択すると、アプリケーション制御部２２８は、ＩＦ部２２７を経由して認証部２２９へ「アラートコール証明書」発行依頼を行い、認証部２２９は、「アラートコール証明書」をＩＦ部２２７を経由してアプリケーション制御部２２８へ送る。

アプリケーション制御部２２８は、「携帯電話１０１の加入者情報」と「相手の電話番号」と「アラートコール証明書」をＩＦ部２２７とＩＦ部２２５とＩＦ部２０６とＩＦ部２０８を経由してアプリケーション制御部２０９へ送付する（ステップＳ２０１）。

アプリケーション制御部２０９は、「相手の電話番号」をＩＦ部２０８とＩＦ部２２０を経由してアプリケーション制御部２２１へ送付し、アプリケーション制御部２２１は加入者ＤＢより「相手の電話番号」と一致するユーザのルーティング情報「回線交換機１０４と無線アクセスネットワークノード１０３の配下に在圏」を取り出し、ＩＦ部２２０とＩＦ部２０８を経由してアプリケーション制御部２０９へ送付する。

つまり、呼制御サーバ１０５のアプリケーション制御部２０９が行うここまでの処理は、着呼側ユーザのルーティング情報を確認する処理である（ステップＳ２０２）。

アプリケーション制御部２０９は、ルーティング情報を元に着信側携帯電話１００の在圏するＩＦ部２０８とＩＦ部２０６とＩＦ部２０４とＩＦ部２００を経由してアプリケーション制御部２０１へ「携帯電話１０１の加入者情報（電話番号／ユーザ名）と「アラートコール証明書」と「アラートコール依頼」を送付する（ステップＳ２０３）。

アプリケーション制御部２０１は、「アラートコール依頼」を受信すると受信した「アラートコール証明書」をＩＦ部２００を経由して認証部２０２へ送付し、認証部２０２は既に格納してあるアラートコール証明書と受信した「アラートコール証明書」の照合を行い（ステップＳ２０４）、同一のものがあればアプリケーション制御部２０１へ「アラート実施依頼」を送付し、アラートコールを実施する（ステップＳ２０５）。

なお、同一のものが無ければ「アラートコール」は中止となり、通常の電話着信処理を行う（通常の携帯電話着信処理に関しては既存技術を活用する為、記載は割愛する）。

＜アラートコール実施処理＞
「アラート実施依頼」を受信したアプリケーション制御部２０１は、携帯電話１００のモード状態（通常／マナー／サイレント／ドライブ）を確認し、現在のモード状態に関わらず「着信鳴動」の実施を行うように決定する。

アプリケーション制御部２０１が「着信鳴動」の実施を行うように決定すると、携帯電話１００のスピーカー部よりリンギング時の着信音が流れ出す（通常モードならば既に設定済の着信音、それ以外のモードの場合には着信音１として既存端末にデフォルト登録されている着信音を鳴動する。但し、この着信音に関してはユーザ側で自由に設定可能とする）。

着信鳴動中、ユーザが付近にいてオフフック（受話器を取る）すると通話状態となり、通常の携帯電話上の相互音声通信が携帯電話１００と携帯電話１０１間で実施され、処理は終了する。逆に着信鳴動中にユーザが気づかずに一定時間（携帯電話１００の所有者が自由に設定可能）呼び出し中状態のままとなると「不在」と判定し、アプリケーション制御部２０１はＩＦ部２００とＩＦ部２０４とＩＦ部２０６とＩＦ部２０８を経由してアプリケーション制御部２０９へ「不在」通知を送付する。

つまり、アプリケーション制御部２０１がアラートコールを実施したにもかかわらず所定の時間がオンフックのままで経過すると、呼制御サーバ１０５のアプリケーション制御部２０９へ「不在」通知を送付する（ステップＳ２０６、Ｓ２０７）。

以上が、本実施形態に係るアラートコール処理の基本的な部分である。しかしながら、ここまでの処理では、着呼側ユーザが「不在」と判断される場合に、着呼側ユーザが緊急の呼び出しであるアラートコールに充分に気付けないケースを残している。着呼側ユーザが「不在」と判断される場合は、図５のステップＳ２０７にて不在通知が送付されたケースの他、着呼側の携帯電話が在圏外や、電源ＯＦＦ時のケースも該当する。本実施形態に係るアラートコール処理においては、着呼側ユーザが「不在」と判断される場合に、図６に示す処理を行って、この問題を解決する。

図６は、着呼側ユーザが「不在」と判断される場合の処理の流れを示すフローチャートである。
「不在」通知を受信したアプリケーション制御部２０９は、「不在」扱いとなった呼のセッションＩＤ（呼び出し中のコールＩＤ）をＩＦ部２０８を経由してセッション管理部２１０へ問い合わせ、セッション継続中のセッションＩＤを受け取る（仮にセッションＩＤ＝０００００１とする）。つまり、呼制御サーバ１０５のアプリケーション制御部２０９は、「不在」扱いとなったこのセッションＩＤを確認する（ステップＳ３０１）。

アプリケーション制御部２０９は、ＩＦ部２０８とＩＦ部２１３を経由してアプリケーション制御部２１８に「ガイダンス依頼」と「セッションＩＤ」を送付する。つまり、呼制御サーバ１０５のアプリケーション制御部２０９は、音声ガイダンスサーバ１０８にセッションＩＤを送付する（ステップＳ３０２）。ここで、セッションＩＤには、「サービス識別子＝『アラートコール』」を値とするサービス識別子を含ませる。

アプリケーション制御部２１８は「ガイダンス依頼」を受けとると、「セッションＩＤ＝０００００１」中に含まれる「サービス識別子＝『アラートコール』」より、アラートコール不在時に流す音声ガイダンスと理解し、ＩＦ部２１３を経由してガイダンス用音声ＤＢ２１９より「アラートコール不在時に流す音声ガイダンス」を取り出し、ＩＦ部２１３とＩＦ部２０８を経由してアプリケーション制御部２０９へ音声データ配信を開始する（ステップＳ３０３）。

アプリケーション制御部２０９は、「セッションＩＤ＝０００００１」中に含まれる「ルーティング情報」よりＩＦ部２０８とＩＦ部２０６とＩＦ部２２５とＩＦ部２２７を経由してアプリケーション制御部２２８へ音声ガイダンスを配信する（同一のコールセッションＩＤを利用する為、一旦切断する事無く同一のセッション内で処理を可能とする）と、携帯電話１０１のスピーカーを通じてアラートコール発信者に『０９０−ｘｘｘｘ−ｘｘｘｘ、○○さんは不在です。詳細メッセージを残しますので、発信音の後にメッセージを入力して下さい。』というガイダンスが流れるので、ユーザは携帯電話１００所有者へ伝えたい緊急メッセージを音声入力する。アプリケーション制御部２２８は、携帯電話１０１の音声入力ＩＦを経由して入力された「音声メッセージ」をＩＦ部２２７とＩＦ部２２５とＩＦ部２０６とＩＦ部２０８とＩＦ部２１２を経由してアプリケーション制御部２１６へ送付する。発呼側端末におけるここまでの処理をアラートメッセージ音声入力処理という（ステップＳ３０４）。

アプリケーション制御部２１６は、「音声メッセージ」をＩＦ部２１２を経由してキャッシュストレージ部２１７に「キャッシュＩＤ＝ｘｘｘｘｘ１」と共にデータを格納し、ＩＦ部２１２とＩＦ部２１１を経由してアプリケーション制御部２１４へ「テキスト変換依頼」を通知する（ステップＳ３０５）。

アプリケーション制御部２１４は、ＩＦ部２１１とＩＦ部２１２を経由してキャッシュストレージ部２１７に保存された音声データ群より「キャッシュＩＤ＝ｘｘｘｘｘ１」と一致するデータを取り出し、ワード細分化を行う。「△△さんが、事故にあったたのでこの連絡を・・・」という連続音声データをＩＦ部２１１を経由して検索辞書２１５内で「△△さん」「が」「事故」「に」「あった」「ので」「この」「連絡」「を」・・・の様に細分化された音声波形データ群に置き換えた後に部位毎のテキスト変換を行い、部位毎のテキストを連結させる事でテキストメッセージへの変換が完了する（ステップＳ３０６）。

アプリケーション制御部２１４は、ＩＦ部２１１とＩＦ部２０８を経由してアプリケーション制御部２０９に連結した「テキストメッセージ」を送付する。アプリケーション制御部２０９は、受信した「テキストメッセージ」と予め管理してある「セッションＩＤ＝０００００１」よりＩＤ情報中に含まれる着信側の「ルーティング情報」を使って、ＩＦ部２０８とＩＦ部２２３とＩＦ部２０４とＩＦ部２００を経由してアプリケーション制御部２０１に「テキストメッセージ」を送付する（ステップＳ３０７）。

これにより、不在となっていた携帯電話１００所有者が着信に気づいた時には既にメッセージ化された内容を電子メールとして受信済となり、着信履歴よりリダイヤルする事無く、情報把握が可能となる。また、発呼側ユーザが吹き込んだ緊急のメッセージ（アラートメッセージ）を自動でテキスト化して電子メールで送付し、着呼側ユーザはアラートメッセージを文字で読めることにより、緊急のメッセージの着実な伝達という伝達性が高まる。また、情報密度が向上する。

上述した実施形態によれば、以下の第１ないし第５の効果がある。
第１の効果は、アラートコール技術を利用する事で緊急性の高い電話と通常の電話の差分を明確に着信側に伝える事が可能となる事である。

第２の効果は、アラートコールにおける携帯電話の既存モード設定の強制変更処理により、着信側の携帯電話がマナーモードやサイレントモードになっていたとしても携帯電話内蔵アプリケーションに強制鳴動処理を実施させ通常の電話着信に設定されている着信音を強制的に鳴動させる事が可能となり、着信側の携帯電話のモード設定に関わらず着信者が着信に気づく可能性を高める事である。

第３の効果は、不在と判断される場合においてもアラートメッセージのテキスト変換を行うことで、従来は音声蓄積サーバ側のストレージ領域確保に伴う運用コストの問題で、１５秒程度と短い録音設定となっておりメッセージ録音中に肝心な部分が伝えきれない、または、よく理解出来ない等の問題が解消され、長い音声メッセージもテキスト化して相手の携帯電話へ送信可能となり、情報密度が向上する事である。

第４の効果は、アラートコール受信許諾処理により、緊急呼扱いに変換を可能とする様な利用者にとって優先度の高いユーザを予め設定する事が可能となる事、許容するか否かは受信者側に権限が委ねられ、民事間の問題発生の抑制と共に利用者のプライベート保護にも配慮が可能となる事である。

第５の効果は、呼処理サーバにおける同一セッションを利用したサービス切替処理により、従来ならば発信側で一旦音声発信を切断させ、切断処理が完全に終了した後に電子メールサービスを新規起動する為、操作の手間が発生するが、自動で電子メールサービスに切替ると共に音声メッセージからのテキストデータ化を行う事が可能となり、テキストメッセージの入力の手間の解消が可能となる事である。

１００、１０１ 携帯電話
２０１、２２８ アプリケーション制御部
２０２、２２９ 認証部
２０３、２３０ 電話帳データベース
１０２ 通信網
１０５ 呼制御サーバ
２０９ （呼制御サーバの）アプリケーション制御部
１０６ テキスト変換サーバ
１０７ 音声蓄積サーバ
１０８ 音声ガイダンスサーバ
１０９ 加入者管理サーバ
１１０ パケット交換機

Claims (5)

1. アラートコールであることを示す情報と共に発呼を受けると、
   前記発呼をした発呼側端末のユーザと、前記発呼に対する着呼側端末のユーザとがアラートコールの発着呼を許諾する取り決めを結んでいることを確認した上で前記発呼をアラートコールとして回線をつなぎ、
   前記着呼側端末のユーザが不在であると判断される場合には、前記発呼側端末からの音声入力をアラートメッセージとして受け付けて、一時的に蓄積し、
   蓄積した前記アラートメッセージを、辞書データベースを用いてテキスト変換し、
   テキスト変換後の前記アラートメッセージを前記着呼側端末へ電子メールとして送付することを特徴とする、アラートコールシステム。
2. 呼制御サーバと、音声蓄積サーバと、テキスト変換サーバと、を含むアラートコールシステムであって、
   前記呼制御サーバは、アラートコールであることを示す情報と共に発呼を受けると、前記発呼をした発呼側端末のユーザと、前記発呼に対する着呼側端末のユーザとがアラートコールの発着呼を許諾する取り決めを結んでいることを確認した上で前記発呼をアラートコールとして回線をつなぐ呼制御手段を備え、
   前記音声蓄積サーバは、前記着呼側端末のユーザが不在であると判断される場合には、前記発呼側端末からの音声入力をアラートメッセージとして受け付けて、一時的に蓄積する音声蓄積手段を備え、
   前記テキスト変換サーバは、辞書データベースと、蓄積した前記アラートメッセージを前記辞書データベースを用いてテキスト変換するテキスト変換手段と、を備え、
   前記呼制御手段は、テキスト変換後の前記アラートメッセージを前記着呼側端末へ電子メールとして送付することを特徴とする、アラートコールシステム。
3. 前記呼制御手段は、前記アラートコールを着呼側端末が着呼した後、所定の時間が経過してもオンフックのままである場合に、前記着呼側端末のユーザが不在であると判断することを特徴とする、請求項２記載のアラートコールシステム。
4. 前記呼制御手段は、前記着呼側端末が、アラートコールシステムの有するどの無線アクセスネットワークノードの支配下にも在圏していない場合に、前記着呼側端末のユーザが不在であると判断することを特徴とする、請求項２又は３記載のアラートコールシステム。
5. アラートコールであることを示す情報と共に発呼を受けると、
   前記発呼をした発呼側端末のユーザと、前記発呼に対する着呼側端末のユーザとがアラートコールの発着呼を許諾する取り決めを結んでいることを確認した上で前記発呼をアラートコールとして回線をつなぎ、
   前記着呼側端末のユーザが不在であると判断される場合には、前記発呼側端末からの音声入力をアラートメッセージとして受け付けて、一時的に蓄積し、
   蓄積した前記アラートメッセージを、辞書データベースを用いてテキスト変換し、
   テキスト変換後の前記アラートメッセージを前記着呼側端末へ電子メールとして送付することを特徴とする、アラートコール処理方法。

Images