JP5222974B2

JP5222974B2 - 通信システム及び通信方法

Info

Publication number: JP5222974B2
Application number: JP2011100154A
Authority: JP
Inventors: 道子涌井; 英輔遠藤; 慎也立元; 哲也三ケ尻; 範昭萩谷
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2011-04-27
Filing date: 2011-04-27
Publication date: 2013-06-26
Anticipated expiration: 2031-04-27
Also published as: JP2012231435A; WO2012147589A1

Description

本発明は通信システム及び通信方法に関する。

移動局の移動通信を可能にする通信システムは、主に無線アクセス制御を行う無線アクセスネットワーク（RAN）と、移動管理、呼制御、サービス制御等を行うコアネットワーク（CN）とを有する。RANには、移動局との無線通信を行う無線基地局が少なくとも含まれる。CNは、回線交換（CS：Circuit Switched）網と、パケット交換（PS：Packet Switched）網とで構成される。一般に、CS網は音声電話やTV電話等の音声系サービスを提供し、PS網はウェブブラウジング等のようなデータ通信系サービスを提供する。CS網には、移動サービス交換機（MSC：Mobile−services Switching Center）があり、PS網にはサービングGPRSサポートノード（SGSN：Serving GPRS Support Node）等がある。この種の従来の通信システムについては、非特許文献1に記載されている。

ところで、災害時や輻輳時において、緊急通信や重要通信のリソースを確保するために、通常の通信を規制する場合がある。例えばCS網に規制がかかっていた場合、一般の発側ユーザ装置から着側ユーザ装置への音声発信は交換機等により拒否される。従来の規制方式については、非特許文献2に記載されている。

3GPP TS23．002 v6．10．0（2005−12）野口勝広他、「FOMA アクセス規制の回線交換／パケット交換分離機能」、NTT DoCoMoテクニカル・ジャーナル、Vol．14、No．4、2007年1月

しかしながら、CS網が規制により使用できない場合において、PS網も使用できないとは限らない。むしろ、CS網は使用できないがPS網は使用できる場合がある。このような場合には、PS網を利用することで何らかの通信を行うことが技術的には可能である。しかしながら、通信端末を使いこなす能力に乏しいユーザにとって、状況に応じて適切な通信網を使って、例えば安否確認を行ったりメッセージを伝えたりすることは容易でない。

本発明の課題は、発側ユーザ装置から着側ユーザ装置への発信が、回線交換網の規制により拒否された場合でも、発側ユーザ装置からのメッセージが着側ユーザ装置に簡易な操作により届くようにすることである。

一実施例による通信システムは、
発側のユーザ装置と、
回線交換網と、
パケット交換網と、
着側のユーザ装置と
を少なくとも有する通信システムであって、
前記発側のユーザ装置から前記着側のユーザ装置への発信が、前記回線交換網の規制により拒否された場合、前記発側のユーザ装置がユーザのメッセージを表す音声ファイルを作成し、
前記発側のユーザ装置が、前記音声ファイルを添付ファイルとして含む電子メールを、前記発信に使用した番号と共にメールサーバに通知し、
前記メールサーバが、ユーザ装置への発信に使用される番号と該ユーザ装置のユーザのメールアドレスとの所定の対応関係を参照し、前記着側のユーザ装置への前記発信に使用された番号に対応付けられている着側メールアドレスを発見できた場合、前記電子メールの宛先を前記着側メールアドレスに修正し、修正後の電子メールを前記パケット交換網を通じて送信し、
前記着側のユーザ装置が、前記音声ファイルを添付ファイルとして含む前記修正後の電子メールを前記パケット交換網を通じて受信する、通信システムである。

一実施例によれば、発側ユーザ装置から着側ユーザ装置への発信が、回線交換網の規制により拒否された場合でも、発側ユーザ装置からのメッセージが着側ユーザ装置に簡易な操作により届くようにすることができる。

通信システムの概要を示す図。メール添付方式においてメールサーバがアドレス変換する場合の動作例を示す図。メールサーバに記憶されている対応関係の一例を示す図。メール添付方式において発側UEがアドレス変換する場合の動作例を示す図。メール添付方式においてメールサーバ又は発側UEがアドレス変換する場合の動作例を示す図。組み合わせの動作例において、ファイルサーバが着側UEに通知する場合の動作例を示す図。組み合わせの動作例において、発側UEが着側UEに通知する場合の動作例を示す図。実施例による方法と既存の方法との選択肢をユーザに提供する場合の概念図。ユーザ装置の機能ブロック図。メールサーバの機能ブロック図。ファイルサーバの機能ブロック図。

本実施例では、発側のユーザから着側ユーザへの発信が、回線交換網の規制により拒否された場合に、発側のユーザのメッセージを表す音声ファイルが作成される。その後、発側又はメールサーバが、発信に使用された番号に予め対応付けられているメールアドレスを検索し、着側のユーザが、音声ファイルを含む電子メールをパケット交換網を通じて受信する。本実施例は、回線交換網に規制がかかっていたとしても、パケット交換網に規制がかかっていなければ、発側から着側へメッセージを、発側及び着側何れのユーザにとっても簡易な操作により届けることができる。このため、ユーザ装置の操作に精通していないユーザであっても本実施例による恩恵を享受することができる。

以下の観点から実施例を説明する。

1．通信システム
2．メール添付方式
2．1 メールサーバがアドレス変換
2．2 発側UEがアドレス変換
3 組み合わせ
3．1 ファイルサーバが着側UEに通知
3．2 発側UEが着側UEに通知
4．変形例
5．ユーザ装置
6．メールサーバ
7．ファイルサーバ

＜1．通信システム＞
図1は、実施例において想定される通信システムの一例を示す。通信システムは、発側のユーザ装置（発側UE）11と、着側のユーザ装置（着側UE）12と、回線交換網（CS網）13と、交換機14と、パケット交換網（PS網）15と、サーバ16とを少なくとも有する。図示の簡明化のため、発側UE11、着側UE12、交換機14、サーバ16はそれぞれ1つしか描かれていないが、具体的な個数は任意である。

発側のユーザ装置（発側UE）11及び着側のユーザ装置（着側UE）12は、一般的には、CS網13及びPS網15を通じて通信することが可能な適切な如何なるユーザ装置UEでもよい。ユーザ装置は、移動端末でもよいし、固定端末でもよい。ユーザ装置は、具体的には、携帯電話、情報端末、高機能携帯電話、スマートフォン、タブレット型コンピュータ、パーソナルディジタルアシスタント、携帯用パーソナルコンピュータ、デスクトップコンピュータ、固定電話等であるがこれらに限定されない。ただし、着側のユーザ装置（着側UE12）は、CS網13による通信を実行できないユーザ装置、すなわちPS網15による通信しか実行できないユーザ装置でもよい。

回線交換網（CS網）13は、CS網は音声電話やTV電話等の音声系サービスを提供するための通信網である。

交換機14はCS網における通信を制御するコアネットワークCNのノードである。交換機14は、例えば、加入者情報の管理、移動管理、発着信制御、課金制御、QoS制御等の処理を行う。

パケット交換網（PS網）15は、ウェブブラウジング等のようなデータ通信系サービスを提供するための通信網である。図示の簡明化のため省略されているが、実際にはPS網にも交換機が存在し、パケット通信に関して、加入者情報の管理、移動管理、発着信制御、課金制御、QoS制御等の処理を行う。

サーバ16は、PS網15内に設けられ、後述のメールサーバ又はファイルサーバに該当する。

概して、図1に示す通信システムでは、発側UE11から着側UE12への発信が、CS網13の規制により拒否された場合に、発側UE11がユーザのメッセージを表す音声ファイルを作成する。その後、発側UE11又はサーバ16が、発信に使用された番号に予め対応付けられているメールアドレスを検索し、着側UE12が、音声ファイルを含む電子メールをPS網15を通じて受信する。規制は、災害時や輻輳時に交換機14により行われる。発側UE11のCS網と着側UE12のCS網とは同一でもよいし、異なっていてもよい。異なっていた場合、発側UE11のCS網及び着側UE12のCS網の双方又は一方において、規制がかかる可能性がある。本実施例は、何れの場合であっても、PS網に規制がかかっていなければ、発側UE11から着側UE12へメッセージを、発側及び着側何れのユーザにとっても簡易な操作により届けることができる。このため、ユーザ装置の操作に精通していないユーザであっても本実施例による恩恵を享受することができる。PS網が規制されていたとしても、通信を成功させる確率がCS網よりもPS網の方が高かった場合にも、本実施例による方法が有効に使用可能である。この場合、PS網における発信は失敗する可能性があるが、そのようなときにはユーザ装置から再送が行われてもよい。再送の間隔や再送回数等の再送の仕方については、ネットワーク側から受信した報知情報、エラーメッセージ又はセルブロードキャストサービス（CBS）メッセージ（例えば、エリアメール）等から判定することができるように、通信システムが構築されていてもよい。

なお、簡明化のため、図示の例では交換機が規制をかけている場合を示しているが、無線アクセス制御装置（RNC）のような制御装置が規制率等を報知情報として基地局を介してユーザ装置に通知することで、規制の状況が通知されてもよい。

＜2．メール添付方式＞
以下、図1に示すような通信システムにおいて行われる動作例を説明する。

＜＜ 2．1 メールサーバがアドレス変換＞＞
図2は、メール添付方式においてメールサーバがアドレス変換する場合の動作例を示す。

ステップS201において、発側UE11は、着側UE12宛に回線交換網（CS網13）による通信を試みる。発側UE11が発信する通信は、典型的には移動端末や固定端末宛の音声通信であるが、本実施例はそのような具体例に限定されず、CS網13を用いる任意の通信に適用可能である。例えば、災害伝言板のような特定の電話番号への発信等にも本実施例を適用することができる。

ステップS203において、交換機14は、通信の規制を行っている場合、通常の発信を拒否する処理を行う。具体的には、発側UE11に対してエラーメッセージを作成する。

ステップS205において、エラーメッセージが発側UE11に届く。なお、簡明化のため、図示の例では交換機が規制をかけている場合を示しているが、無線アクセス制御装置（RNC）のような制御装置が規制率等を報知情報として基地局を介してユーザ装置に通知することで、規制の状況が通知されてもよい。このことは図2だけでなく、他の図においてもあてはまる。

ステップS207において、発側UE11は、受信したエラーメッセージから、規制により発信が拒否されたことを確認する。エラーメッセージが、規制の原因の情報を含んでいた場合、発側UE11はどのような原因であるかを判別する。例えば、規制の原因として、災害によるものであること、年始の輻輳によること、チケット販売による輻輳であること、コンサートやイベントによる輻輳であること等が考えられる。これらのうち、本実施例では災害により規制がなされているか否かが確認される。規制の原因が災害によるものであった場合、発側UE11は、動作モードを通常モードからNW混雑回避モードに切り替え、ステップS207以降の処理を実行する。通常モードの場合、ステップS207以降の処理は行われない。後述するように、NW混雑回避モードの場合、CS網が規制されていたとしても、PS網が規制されていなければ、発側のユーザのメッセージを着側へ簡易な操作により届けることができる。

なお、発側UE11が動作モードをNW混雑回避モードに切り替えるタイミングは、ステップS205のエラーメッセージを受信したタイミングでもよいし、それ以前でもよい。例えば、ステップS200において、コアネットワークCN（交換機）からユーザ装置へセルブロードキャストサービス（CBS）メッセージ（例えば、エリアメール）が通知されたことに応じて、動作モードがNW混雑回避モードに切り替えられてもよい。一例として、動作モードの切り替えは、NW混雑回避モードの動作を実行するアプリケーションを起動又は停止することで行われてもよい。この場合のCBSメッセージ（例えば、エリアメール）は、特定の地域を指定してユーザ装置に通知することが可能な通知信号であり、ユーザ装置が動作モードを変更することを促すものである。ユーザ装置が動作モードを変更することを促す手段として、ショートメッセージのように宛先（例えば、電話番号）を指定したメッセージサービスを利用してもよい。例えば、災害時においてコアネットワークCN（交換機）が、被災地のような特定の地域又はエリアに対して、そのようなCBSメッセージ（例えば、エリアメール）を送信することが考えられる。あるいは、全国的にCBSメッセージが送信されてもよい。エラーメッセージに含まれている規制の原因の情報が、災害によるものであるか否かを区別できない場合、そのような情報に基づいて動作モードをNW混雑回避モードに切り替えることはできない。これに対して、CBSメッセージは動作モードの切り替えを直接的に促すことができる。ただし、CBSメッセージは地域的に一斉に送信される必要があるが、規制の原因の情報を利用する場合は、動作モードの切り替えを真に必要とするユーザ装置に限定して個別に通知できる。

ステップS207において、NW混雑回避モードで動作する発側UE11は、着側UEのユーザに伝えるメッセージを音声で発側UE11に入力するようにユーザを促す。例えば、次のようなガイダンスの音声又は表示とともに、ユーザによる音声の入力が促されてもよい：
「ただいま電話が混み合っております。090xxxxxxxx宛のメッセージを電子メールでお届けします。発信音の後にメッセージを入力して下さい。」
これに応じて、発側UE11のユーザは、例えば、次のようなメッセージを音声で入力する。

「xxxです。無事です。あなたは？」
発側UE11は、このように入力されたメッセージを表す音声ファイルを作成する。

なお、災害によるものではない原因の輻輳の場合、ステップS205の後に「ただいま電話が混み合っており、接続することができません。」という旨のガイダンスが流れる。しかしながら、本実施例による動作が行われる場合、CS網を通じた通信は接続できないが、後述する方法によりメッセージを届けることができる。このため、本実施例の場合、接続できない旨のガイダンスを流すことが禁止される。この場合、ガイダンスの音声の再生を止めてもよいし、再生する際の音量をゼロにしもよい。

ステップS209において、発側UE11は、電子メールを作成する。この電子メールの添付ファイルとして、ステップS207で作成した音声ファイルが含まれている。

ステップS207、S209、S211による処理は、ユーザの操作を介することなく自動的に行われることが好ましい。

ステップS211において、電子メールが発側UE11からメールサーバ16へパケット交換網（PS網）を通じて送信される。図示されているように、この電子メールは、音声ファイルを含み、着側UE12の番号とともに送信される。着側UE12の番号とは、ステップS201において発信した際の番号であり、典型的には着側UE12の電話番号である。この番号は、電子メールの本文に記載されていてもよいし、添付ファイルに記載されていてもよい。

ステップS213において、メールサーバ16は、電子メールを受信し、着側UE12の番号を抽出する。メールサーバ16は、不図示のデータベースにアクセスし、着側UE12の番号に対応付けられているメールアドレスを探す。

図3は、データベースに記憶又は格納されているデータの一例を示す。データベースには、ユーザ装置UEの連絡先とメールアドレスとの対応関係が含まれている。ユーザ装置UEの連絡先は、典型的には電話番号である。メールアドレスは、ユーザ装置UEのユーザが所有しているメールアドレスである。メールアドレスは、ユーザ装置UEのメールアドレスでもよいし、そうでなくてもよい。例えば、携帯電話の番号090AAAAAAAAとその携帯電話のメールアドレスaaa＠aa.aa．aaが対応付けられていてもよい。あるいは、携帯電話の番号090BBBBBBBBとデスクトップコンピュータのメールアドレスbbb＠bb.bb．bbが対応付けられていてもよい。UEの連絡先とメールアドレスとが1対1に対応することは必須ではなく、1つ以上の連絡先に複数のメールアドレスが対応付けられていてもよい。図示の例の場合、固定電話の番号03CCCCCCCCが2つのメールアドレスに対応付けられている。UEの連絡先に複数のメールアドレスが対応付けられていた場合、メールサーバ16は、所定の優先順位にしたがって又は任意にメールアドレスを選択する。いずれにせよ、ステップS213において、着側UE12の番号に対応付けられているメールアドレスが、データベースに存在しているか否かが判定され、存在していた場合、メールアドレスが特定される。存在していなかった場合については、図4等を参照しながら説明する。

図2のステップS215において、メールサーバ16は、受信した電子メールの宛先を、ステップS213で特定したメールアドレスに設定することで、電子メールを修正する。修正後の電子メールでは、宛先が着側UE12であり、送信元が発側UE11であり、ステップS207で作成した音声ファイルが添付ファイルとして含まれている。

ステップS217において、このように修正された電子メールがメールサーバ16から着側UE12にPS網を通じて送信される。

ステップS219において、メールサーバ16は、電子メールを送信できたことを発側UE11に通知する。ただし、このような通知は必須ではない。メールサーバ16が電子メールを適切に送信できなかった場合、再送が行われる。

ステップS221において、着側UE12は、受信した電子メールに添付されている音声ファイルを再生する。着側UE12は、電子メールを受信しているので、通常は、電子メールの受信トレイから受信したばかりの電子メールを開き、添付ファイルを選択し、再生処理を起動することになる。しかしながら、着側UE12の操作に精通していないユーザに配慮する観点からは、次のようにすることが好ましい。すなわち、ステップS217による電子メールの受信が、あたかも電話の着信であるかのように動作し（着信音が鳴り）、その「着信」に応答する操作により、音声ファイルが再生され、一連の自動的な処理として行われることが望ましい。この場合、着側UE12のユーザによる操作は、見かけ上の「着信」に応答することだけである。ただし、着側UE12の動作モードが、そのような動作を行うモードに切り替わっている必要がある。一例として、動作モードの切り替えは、そのような動作を実行するアプリケーションを起動又は停止することで行われてもよい。モードを切り替える場合としては、少なくとも3つの選択肢がある。

第1のタイミングは、着側UE12が過去に発信等を行い、災害時であることが判明した場合であり、それにより動作モードを切り替えることが考えられる。第2のタイミングは、着側UE12が、動作モードの切り替えを促すCBSメッセージ（例えば、エリアメール）をネットワークから受信した場合である。第3のタイミングは、ステップS217において受信した電子メールに所定のフラグ（災害フラグ）が設けられており、災害時にはそのフラグが所定値（例えば、1）に設定され、着側UE12がそのようなフラグを検出した場合である。

ステップS221において、音声ファイルを再生することに代えて又はそれとともに、着側UE12は、音声ファイルをテキスト化し、テキストに変換された文字を着側UE12に表示してもよい。

ステップS222において、本実施例に必須ではないが、着側UE12が音声ファイルを取得したり再生した場合に、その旨の通知が発側UE11に向けて送信されてもよい。この通知はユーザの介入により行われてもよいし、着側UE12により自動的に行われてもよい。

ステップS223において、発側UE11は、動作モードをNW混雑回避モードから通常モードに切り替える。例えば、発側UE11は、動作モードの切り替えを促すCBSメッセージ（例えば、エリアメール）を受信したことに応じて、動作モードを切り替えてもよい。あるいは、NW混雑回避モードで動作すべきことを促すCBSメッセージを受信して以来、一定期間経過後に発側UE11は通常モードに遷移してもよい。あるいは、交換機等のネットワーク側の装置が通常モードで動作している場合に、NW混雑回避モードのユーザ装置からネットワークへのアクセスが規制されるようにすることもできる。このような場合には、ユーザ装置によるアクセスが規制により拒否された回数が所定値を超えた場合又は連続して拒否された回数が所定値を超えた場合に、ユーザ装置が動作モードをNW混雑回避モードから通常モードへ切り替えてもよい。

上述したように、メールサーバ16は、着側UE12の番号からメールアドレスを探し、そのメールアドレス宛に電子メールを転送する。このような動作は、災害時においては有用であるが、そうでない場合には不要な動作である。メールサーバ16において、メールアドレスの検索及び電子メールの修正及び転送という処理を行うべきか否かは、少なくとも3つの方法により判別できる。

第1の方法は、NW混雑回避モードの発側UE11がステップS211において送信する電子メールに所定のフラグ（災害フラグ）を設けることである。発側UE11は、NW混雑回避モードで動作して電子メールを送信する場合、災害フラグを所定値（例えば、1）に設定して送信する。メールサーバ16は、受信した電子メールの災害フラグを確認することで、メールアドレスの検索等の処理の要否を判別できる。

第2の方法は、メールサーバ16の動作モードとして、通常モードと非通常モードとを規定することである。ステップS213（メールアドレスの検索）、ステップS215（電子メールの修正）及びステップS217（修正後の電子メールの送信）という一連の処理が、通常モードでは行われず、非通常モードにおいては、受信した電子メール全てについて行われるようにすることが考えられる。

第3の方法は、第1及び第2の方法の組み合わせである。すなわち、メールサーバ16の動作モードが非通常モードでありかつ災害フラグが所定値である電子メールを受信した場合にのみ、上記の一連の処理が行われ、他の場合には上記の処理が行われない。これにより、上記の処理を真に必要とする場合にのみ行うことができるようになる。

このようにして、災害時等において、CS網は規制されているがPS網は使用可能である場合に、PS網を活用して発側UE11から着側UE12へメッセージを簡易な操作で届けるNW混雑回避モードが終了する。

＜＜ 2．2 発側UEがアドレス変換＞＞
図4は、メール添付方式において発側UEがアドレス変換する場合の動作例を示す。図2を参照しながら説明した処理については同じ参照符号が付されており、それらについて詳細には説明しない。図示の簡明化のため、図4−7においてステップS200が描かれていないが、ステップS201の前に動作モードの変更を促すCBSメッセージ（例えば、エリアメール）が送信されていてもよい。

発側UE11はCS網による発信を試みるが（S201）、規制により拒否され（S203）、エラーメッセージを受信する（S205）。これに応じて、発側UE11は、メッセージを音声により入力するようにユーザに促し、音声ファイルを作成し（S207）、その音声ファイルを添付ファイルとして含む電子メールを作成し（S209）、その電子メールを着側UE12の番号とともにメールサーバ16へ送信する（S211）。

ステップS401において、メールサーバ16は、データベースを用いて、着側UE12の番号に対応するメールアドレスを探す。着側UE12の番号に対応するメールアドレスが発見された場合、フローはステップS215に進み、電子メールの宛先を探し出したメールアドレスに設定することで修正し（S215）、メールサーバ16は修正後の電子メールを送信する（S217）。また、メールサーバ16による電子メールの送信が完了したことが、発側UE11に通知される（S219）。

一方、ステップS401において、着側UE12の番号に対応するメールアドレスが発見された場合、フローはステップS403に進む。

ステップS403において、発側UE11は、メールサーバ16が適切なメールアドレスを発見できなかった旨の通知を受けたことに応答して、着側UE12の番号に対応するメールアドレスを、自身の電話帳の中で探す。そのようなメールアドレスが発見された場合、フローはステップS405に進み、発見されなかった場合については後述する。

ステップS405において、発側UE11は、ステップS209において作成した電子メールの宛先を、ステップS403で発見したメールアドレスに設定することで、電子メールを修正する。修正後の電子メールでは、宛先が着側UE12であり、送信元が発側UE11であり、ステップS207で作成した音声ファイルが添付ファイルとして含まれている。

ステップS407において、このように修正された電子メールが発側UE11から着側UE12にPS網を通じて送信される。この電子メールが着側UE12に適切に届かなかった場合、再送が行われる。

ステップS221において、着側UE12は、受信した電子メールに添付されている音声ファイルを再生する。

ステップS222において、着側UE12が音声ファイルを取得したり再生した場合に、その旨の通知が発側UE11に向けて送信されてもよい。

ステップS223において、発側UE11は、動作モードをNW混雑回避モードから通常モードに切り替える。

図4に示す動作例の場合、着側UE12のメールアドレスを、メールサーバ16が発見できなかった場合に、発側UE11が探している（S401においてNO、S403）。しかしながら、このような順序は必須ではない。メールサーバ16によるメールアドレスの検索の前に、発側UE11によるメールアドレスの検索が行われてもよい。

図5はそのような場合の動作例を示す。図2を参照しながら説明した処理については同じ参照符号が付されており、それらについて詳細には説明しない。

発側UE11はCS網による発信を試みるが（S201）、規制により拒否され（S203）、エラーメッセージを受信する（S205）。これに応じて、発側UE11は、メッセージを音声により入力するようにユーザに促し、音声ファイルを作成する（S207）。

ステップS501において、発側UE11は、着側UE12の番号に対応するメールアドレスを、自身の電話帳の中で探す。着側UE12の番号に対応するメールアドレスを発見できなかった場合、フローはステップS209に進み、音声ファイルを添付ファイルとして含む電子メールを作成し（S209）、その電子メールを着側UE12の番号とともにメールサーバ16へ送信する（S211）。メールサーバ16は、データベースを用いて、着側UE12の番号に対応するメールアドレスを探し（S213）、電子メールの宛先を探し出したメールアドレスに設定し（S215）、修正後の電子メールを送信する（S217）。また、メールサーバ16による電子メールの送信が完了したことが、発側UE11に通知される（S219）。着側UE12は受信した音声ファイルを再生する。

ステップS501において、発側UE11が、着側UE12の番号に対応するメールアドレスを発見できた場合、フローはステップS503に進む。

ステップS503において、発側UE11は、発見できたメールアドレスを宛先とし、添付ファイルを音声ファイルとする電子メールを作成する。

ステップS505において、電子メールが発側UE11から着側UE12にPS網を通じて送信される。

＜3 組み合わせ＞
上述したように、メールアドレスの検索は、メールサーバ16により行われてもよいし、発側UE11により行われてもよい。しかしながら、双方により行われた後でも依然としてメールアドレスを発見できないことが懸念される。この場合、メールアドレスを特定して音声ファイルを電子メールで着側UE12に送信することはできない。以下に説明する動作例は、このような場合にも対処できる。

＜＜ 3．1 ファイルサーバが着側UEに通知＞＞
図6は、組み合わせの動作例において、ファイルサーバが着側UEに通知する場合の動作例を示す。図2を参照しながら説明した処理については同じ参照符号が付されており、それらについて詳細には説明しない。

ステップS601において、発側UE11は、着側UE12の番号に対応するメールアドレスを、自身の電話帳の中で探す。着側UE12の番号に対応するメールアドレスを発見できた場合、図示の簡明化のため描かれてはいないが、図5のステップS503及びS505の処理と同様に、発側UE11は、音声ファイルを添付ファイルとして含む電子メールを作成し、その電子メールを着側UE12へ送信する。そして、着側UE12は受信した音声ファイルを再生し（S221）、その旨が発側UE11に通知される。

ステップS601において、発側UE11が、着側UE12の番号に対応するメールアドレスを発見できなかった場合、フローはステップS209に進み、音声ファイルを添付ファイルとして含む電子メールを作成し（S209）、その電子メールを着側UE12の番号とともにメールサーバ16へ送信する（S211）。

ステップS603において、メールサーバ16は、データベースを用いて、着側UE12の番号に対応するメールアドレスを探す。着側UE12の番号に対応するメールアドレスが発見された場合、フローはステップS215に進み、電子メールの宛先を探し出したメールアドレスに設定することで修正し（S215）、メールサーバ16は修正後の電子メールを送信する（S217）。また、メールサーバ16による電子メールの送信が完了したことが、発側UE11に通知される（S219）。そして、着側UE12は受信した音声ファイルを再生し（S221）、その旨が発側UE11に通知される。

ステップS603において、メールサーバ16が、着側UE12の番号に対応するメールアドレスを発見できなかった場合、メールアドレスを特定して音声ファイルを電子メールで着側UE12に送信することはできない。そこで、本動作例ではステップS605以降の処理が行われる。

メールサーバ16が着側UE12の番号に対応するメールアドレスを発見できなかった場合、ステップS605において、エラーメッセージが発側UE11に届く。

ステップS607において、発側UE11はエラーメッセージを受信すると、ステップS207で作成した音声ファイルを、発側UE11及び着側UE12の番号（典型的には電話番号）とともに、PS網を通じてファイルサーバにアップロードする。ファイルサーバは上記のメールサーバ16と同一であってもよいし、異なっていてもよい。異なっている場合は、ファイルサーバとメールサーバとが通信可能に接続されていることが好ましい。ファイルサーバとメールサーバとが異なることは、災害時等において、ユーザが通信できる選択肢を多く確保できること等の観点から好ましい。ファイルサーバは、受信した音声ファイルを発側UE11の番号（典型的には電話番号）とともにデータベースに保存する。

ステップS609において、ファイルサーバは、発側UE11からの着側UE12宛の音声ファイルが保存されていることを、着側UE12に通知する。着側UE12への通知は如何なる方法でもよいが、一例として、発側UE11が指定している着側UE12の電話番号を用いたショートメールにより、着側UE12への通知が行われてもよい。ショートメールは、携帯電話の電話番号でやり取りできる電子メールである。ショートメールの宛先は、着側UE12だけでもよいし、着側UE12に対応付けて事前に登録されている宛先でもよい。例えば、着側UE12のユーザの家族や友人等のグループがそのような複数のユーザとして登録されていてもよい。この場合、ファイルサーバは、着側UE12とグループとの対応関係を必要に応じて参照できる必要がある。あるいは、発側UE11が指定している着側UE12の電話番号にファイルサーバが電話をかけることで、着側UE12への通知が行われてもよい。ショートメール又は電話の着信により着側UE12に通知される内容は、音声ファイルが保存されている場所（例えば、ユニバーサルリソースロケータ（URL））、発側UE11の番号、着側UEの番号等である。

ステップS611において、着側UE12は、通知されたURL等を用いて、ファイルサーバに保存されている音声ファイルにアクセスし、音声ファイルをダウンロードする。

ステップS221において、着側UE12は、ダウンロードした音声ファイルを再生する。

着側UE12は、ステップS609においてショートメール又は着信を受け、それに応じてファイルサーバにアクセスする必要がある。着側UE12の操作に精通していないユーザに配慮する観点からは、ステップS609による通知が、あたかも電話の着信であるかのように動作し（着信音が鳴り）、その着信に応答する操作により、音声ファイルのダウンロードがなされ、音声ファイルが再生されるように、一連の自動的な処理として行われることが望ましい。この場合、着側UE12が行う操作は、見かけ上の「着信」に応答することだけである。ただし、着側UE12の動作モードが、そのような動作を行うモードに切り替わっている必要がある。モードを切り替える場合としては、少なくとも2つの選択肢がある。

第1のタイミングは、着側UE12が過去に発信等を行い、災害時であることが判明した場合であり、それにより動作モードを切り替えることが考えられる。第2のタイミングは、着側UE12が、動作モードの切り替えを促すCBSメッセージ（例えば、エリアメール）をネットワークから受信した場合である。

ステップS613において、ファイルサーバは、着側UE12が音声ファイルをダウンロードしたことを発側UE11に通知する。その結果、発側UE11のユーザは、着側UE12のユーザに音声メッセージが届いたことを確認できる。この点、図4のステップS219において電子メールの送信が完了したことの通知と異なる。電子メールの送信が完了しただけでは、着側UE12のユーザに音声メッセージが届いたか否かは分からないからである。

ステップS223において、発側UE11は、動作モードをNW混雑回避モードから通常モードに切り替える。これにより、災害時等において、CS網は規制されているがPS網は使用可能である場合に、PS網を活用して発側UE11から着側UE12へメッセージを届けるNW混雑回避モードが終了する。

なお、ファイルサーバは、音声ファイルを保存するだけでなく、音声ファイルをテキスト化し、テキストの文字に変換されたテキストファイルを保存してもよい。そして、そのようなテキストファイルが、着側UE12からのダウンロードの要求に応じて送信されてもよい。

＜＜ 3．2 発側UEが着側UEに通知＞＞
ところで、図6のステップS609において、ショートメール等を用いて着側UE12の電話番号により着側UE12に通知を行うことは、発側UE11でも行うことができる。したがって、ファイルサーバから着側UE12への通知の代わりに又はそれに加えて、発側UE11から着側UE12へ、音声ファイルが保存されていることを通知してもよい。

図7は、そのように発側UEが着側UEに通知する場合の動作例を示す。概して、ステップS201からステップS607までの動作は、図6に示すものと同じであり、同じ参照番号が付されている。

ステップS701において、ファイルサーバは、発側UE11の音声ファイルを保存している場所（例えば、URL）を発側UE11にPS網を通じて通知する。

ステップS703において、発側UE11は、音声ファイルの保存場所（URL）、発側UE11の番号及び着側UE12の番号を、例えばショートメール等によりPS網を通じて着側UE12に通知する。

＜4．変形例＞
上述した動作を行うことで、災害時等において、CS網は規制されているがPS網は使用可能である場合に、PS網を活用して発側UE11から着側UE12へ音声メッセージを簡易な操作で届けることができる。このような本実施例による方法は、単独でも使用可能であるし、メッセージを伝えるための既存の方法と組み合わせて使用することもできる。

図8は、実施例による方法と既存の方法との選択肢を発側のユーザに提供する場合の概念図である。

ステップS81において、発側UE11はCS網による発信を試みるが、規制により拒否され、ステップS82に移る。ステップS82において発側UE11に表示される画面には、図示されているようなガイダンスが表示される。

ステップS83において、メッセージを入力するための選択肢が表示される。通信端末の操作に精通しているユーザは、この画面から何れかの選択肢を選択して処理を続けることができる。しかしながら、そのような処理は、通信端末の操作に精通していないユーザにとっては容易でない。この場合、一定時間経過後にステップS84に示されるような画面が表示される。

ステップS84において、発側UE11は、発信が拒否された番号宛のメッセージを音声で入力するように、ユーザを促す。

ステップS85において、ユーザが音声を入力し、音声ファイルが作成される。この動作は、図2のステップS207に対応する。

ステップS88において、音声ファイルは、メールサーバ又はファイルサーバに送信される。このステップは、図2のステップS211又は図6のステップS607に対応する。

一方、通信端末について、ある程度以上の操作を行うことができるユーザは、ステップS83において、意図する方法でメッセージを入力することができる。例えば、ボタンPを選択することで、災害伝言板にアクセスすることが選択され、ステップS86において災害伝言板のウェブサイトに接続される。また、ボタンQを選択することで、ユーザはテキストメッセージを入力し、ステップS87において、入力されたテキストがショートメールにより送信される。ユーザが入力するテキストは、一文字ずつユーザが入力してもよし、所定の選択肢から選択されてもよい。例えば、「無事」及び「助けがほしい」という定形テキストの選択肢が用意され、何れかをユーザが選択してもよい。ボタンRを選択した場合は、ステップS85の場合と同様に音声が入力され、ステップS88において音声ファイルがメールサーバ又はファイルサーバに送信される。

このように本実施例は既存の方法と適宜組み合わせて使用することができる。

＜5．ユーザ装置＞
図9は、ユーザ装置の機能ブロック図を示す。このユーザ装置は、図1の発側UE11及び着側UE12に使用することができる。図9にはユーザ装置に備わる様々な機能部又は処理部のうち実施例に特に関連するものが示されている。ユーザ装置は、受信部91、エラーメッセージ分析部92、ユーザインターフェース93、音声ファイル作成部94、電子メール作成部95、送信部96、音声ファイル抽出部97及び制御部98を少なくとも有する。

受信部91は、CS網又はPS網を介して伝送された無線信号を受信し、ベースバンド信号に変換する。

エラーメッセージ分析部92は、発信が拒否された場合に受信したエラーメッセージを分析し、拒否された原因を分析する。そのような原因として、災害、年始、イベント等に起因する輻輳が挙げられる。

ユーザインターフェース93は、ユーザに対して視覚的、聴覚的及び／又は触覚的（機械的）なインターフェースの機能を発揮する。具体的には、ユーザインターフェース505は、ディスプレイ、キーパッドを備えた制御パネル、陰極線管（CRT）、液晶ディスプレイ（LCD）、有機ELパネル、タッチスクリーン等のような視覚的なインターフェース、キーボード、マウス、トラックボール等のような機械的なインターフェース、マイクロフォン、スピーカ等のような聴覚的インターフェース及びそれらの組み合わせであるが、これらに限定されない。一実施例において、ユーザインターフェース93は、接触感知式の透明パネルでカバーされた表示部を有し、ユーザ装置の動作を制御するためのユーザの指の動きを検知する。

音声ファイル作成部94は、ユーザインターフェース93を通じてユーザが入力した音声によるメッセージから音声ファイルを作成する。

電子メール作成部95は、音声ファイルを含む電子メールや、ショートメールメッセージ等を作成する。

送信部96は、発信信号や電子メール等を送信する。

音声ファイル抽出部97は、受信した電子メールに添付されている音声ファイルを抽出する。抽出された音声ファイルはインターフェース93により再生される。

制御部98は、ユーザ装置内の様々な機能部の動作を制御し、特に、上述したような実施例の動作をユーザ装置が実行できるようにする。
＜6．メールサーバ＞
図10は、メールサーバの機能ブロック図を示す。このメールサーバは、図1におけるサーバ16に使用することができる。図10にはメールサーバに備わる様々な機能部又は処理部のうち実施例に特に関連するものが示されている。メールサーバは、受信部101、記憶部102、メールアドレス検索部103、修正部104及び送信部105を少なくとも有する。

受信部101は、PS網を介して信号を受信する。

記憶部102は、電子メールを保存して管理することに加えて、図3に示すようなユーザの連絡先とそのユーザのメールアドレスとの対応関係を記憶する。

メールアドレス検索部103は、発側UEから受信した電子メールから着側UEの番号を抽出し、その着側UEの番号に対応するメールアドレスを探す。そのようなメールアドレスを発見できた場合は、発見したメールアドレスを修正部104に通知する。発見できなかった場合、エラーメッセージを作成し、送信部105に通知する。

修正部104は、発側UEから受信した電子メールの宛先を、メールアドレス検索部103が発見したメールアドレスに設定することで電子メールを修正する。

送信部105は、修正部104により修正された電子メールを送信する。また、送信部105は、着側UE12の番号に対応する電子メールを発見できなかった場合、その旨を示すエラーメッセージを発側UEに通知する。

＜7．ファイルサーバ＞
図11は、ファイルサーバの機能ブロック図を示す。このファイルサーバは、図1におけるサーバ16に使用することができる。図11にはファイルサーバに備わる様々な機能部又は処理部のうち実施例に特に関連するものが示されている。ファイルサーバは、受信部111、通知信号生成部112、記憶部113及び送信部114を少なくとも有する。

受信部111は、PS網を介して信号を受信する。例えば、受信部111は発側UEがアップロードする音声ファイルを受信する。

通知信号生成部112は、発側UEから通知された着側UEの番号を用いて通知信号を作成する。通知信号は典型的にはショートメールである。

記憶部113は、発側UEがアップロードした音声ファイルを発側UEの番号とともに記憶及び管理する。

送信部114は、通知信号を着側UEに通知する。また、送信部114は着側UEからの要求に応じて、音声ファイルを送信する。

以上本発明は特定の実施例を参照しながら説明されてきたが、それらは単なる例示に過ぎず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。例えば、本発明は、CS網及びPS網を使用する適切な如何なる通信システムに適用されてもよい。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。実施例又は項目の区分けは本発明に本質的ではなく、2以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。説明の便宜上、本発明の実施例に係る装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。ソフトウェアは、ランダムアクセスメモリ（RAM）、フラッシュメモリ、読み取り専用メモリ（ROM）、EPROM、EEPROM、レジスタ、ハードディスク（HDD）、リムーバブルディスク、CD−ROM、データベース、サーバその他の適切な如何なる記憶媒体に用意されてもよい。本発明は上記実施例に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。

11 発側のユーザ装置（発側UE）
12 着側のユーザ装置（着側UE）
13 回線交換網（CS網）
14 交換機
15 パケット交換網（PS網）
16 サーバ
91 受信部
92 エラーメッセージ分析部
93 ユーザインターフェース
94 音声ファイル作成部
95 電子メール作成部
96 送信部
97 音声ファイル抽出部
98 制御部
101 受信部
102 記憶部
103 メールアドレス検索部
104 修正部
105 送信部
111 受信部
112 通知信号生成部
113 記憶部
114 送信部

Claims

発側のユーザ装置と、
回線交換網と、
パケット交換網と、
着側のユーザ装置と
を少なくとも有する通信システムであって、
前記発側のユーザ装置から前記着側のユーザ装置への発信が、前記回線交換網の規制により拒否された場合、前記発側のユーザ装置がユーザのメッセージを表す音声ファイルを作成し、
前記発側のユーザ装置が、前記音声ファイルを添付ファイルとして含む電子メールを、前記発信に使用した番号と共にメールサーバに通知し、
前記メールサーバが、ユーザ装置への発信に使用される番号と該ユーザ装置のユーザのメールアドレスとの所定の対応関係を参照し、前記着側のユーザ装置への前記発信に使用された番号に対応付けられている着側メールアドレスを発見できた場合、前記電子メールの宛先を前記着側メールアドレスに修正し、修正後の電子メールを前記パケット交換網を通じて送信し、
前記着側のユーザ装置が、前記音声ファイルを添付ファイルとして含む前記修正後の電子メールを前記パケット交換網を通じて受信する、通信システム。
前記メールサーバが、前記着側のユーザ装置への前記発信に使用された番号に対応付けられている前記メールアドレスを発見できなかった場合において、前記発側のユーザ装置が、前記着側のユーザ装置の着側メールアドレスを電話帳の中で発見できた場合、前記発側のユーザ装置が、前記電子メールの宛先を前記着側メールアドレスに修正し、修正後の電子メールを前記パケット交換網を通じて送信する、請求項1記載の通信システム。
前記メールサーバが前記修正後の電子メールを前記パケット交換網により送信できたことが、前記メールサーバから前記発側のユーザ装置に通知される、請求項1記載の通信システム。
前記発側のユーザ装置が、前記着側のユーザ装置の着側メールアドレスを電話帳の中で発見できた場合、前記発側のユーザ装置が、前記修正後の電子メールを、前記パケット交換網を通じて送信する、請求項2記載の通信システム。
前記発側のユーザ装置も前記メールサーバも前記着側メールアドレスを発見できなかった場合、前記発側のユーザ装置は、前記音声ファイルを前記発側のユーザ装置の番号とともにファイルサーバにアップロードし、
前記着側のユーザ装置が前記ファイルサーバから前記音声ファイルをダウンロードする、請求項1記載の通信システム。
前記音声ファイルが前記ファイルサーバにアップロードされたことを、前記ファイルサーバが前記着側のユーザ装置に通知する、請求項5記載の通信システム。
前記音声ファイルが前記ファイルサーバにアップロードされたことを、前記ユーザ装置が前記着側のユーザ装置に通知する、請求項5記載の通信システム。
前記着側のユーザ装置が前記音声ファイルをダウンロードしたことが、前記ファイルサーバから前記発側のユーザ装置に通知される、請求項5記載の通信システム。
前記発側のユーザ装置から前記着側のユーザ装置への発信が前記回線交換網の規制により拒否されたことに応答して、前記発側のユーザ装置が、ユーザのメッセージを表す音声ファイルを作成する機能を動作可能にするか否かを決定する、請求項1記載の通信システム。
前記発側のユーザ装置がネットワークからメッセージを受信したことに応答して、前記発側のユーザ装置が、ユーザのメッセージを表す音声ファイルを作成する機能を動作可能にするか否かを決定する、請求項1記載の通信システム。
発側のユーザ装置と、回線交換網と、パケット交換網と、着側のユーザ装置とを少なくとも有する通信システムにおける通信方法であって、
前記発側のユーザ装置から前記着側のユーザ装置への発信が、前記回線交換網の規制により拒否された場合、前記発側のユーザ装置がユーザのメッセージを表す音声ファイルを作成し、
前記発側のユーザ装置が、前記音声ファイルを添付ファイルとして含む電子メールを、前記発信に使用した番号と共にメールサーバに通知し、
前記メールサーバが、ユーザ装置への発信に使用される番号と該ユーザ装置のユーザのメールアドレスとの所定の対応関係を参照し、前記着側のユーザ装置への前記発信に使用された番号に対応付けられている着側メールアドレスを発見できた場合、前記電子メールの宛先を前記着側メールアドレスに修正し、修正後の電子メールを前記パケット交換網を通じて送信し、
前記着側のユーザ装置が、前記音声ファイルを添付ファイルとして含む前記修正後の電子メールを前記パケット交換網を通じて受信するステップ
を有する通信方法。