(57)【要約】【課題】利用者が非常時になった場合においても第三者に連絡先を通知できるようにした電話番号通知システムを提供する。【解決手段】利用者が通常時に使用する端末２の第１電話番号と、第１電話番号に発呼した端末３の第２電話番号とを対応付けて記録する対応テーブル２０と、第１電話番号と、利用者が通常時か又は非常時であるかを表す状況情報と、利用者が非常時に使用する端末４の第３電話番号とを対応付けて記録する番号管理データベース３０と、第２電話番号の端末３から第１電話番号に発呼した場合に、第１電話番号の利用者の状況情報が非常時であり、且つ対応テーブル２０に第２電話番号が記録済みであれば第２電話番号の端末３に、第３電話番号を送信する呼制御サーバ１０とを備える。【選択図】図１
2018026652.tif 000002
【特許請求の範囲】
【請求項１】
利用者が通常時に使用する端末の第１電話番号と、前記第１電話番号に発呼した端末の第２電話番号とを対応付けて記録する対応テーブルと、
前記第１電話番号と、利用者が通常時か又は非常時であるかを表す状況情報と、前記利用者が非常時に使用する端末の第３電話番号とを対応付けて記録する番号管理データベースと、
前記第２電話番号の端末から前記第１電話番号に発呼した場合に、前記第１電話番号の利用者の前記状況情報が非常時であり、且つ前記対応テーブルに前記第２電話番号が記録済みであれば前記第２電話番号の端末に、前記第３電話番号を送信する呼制御サーバと
を備えたことを特徴とする電話番号通知システム。
【請求項２】
前記対応テーブルの第２電話番号は、前記第１電話番号に対する発呼回数の最上位から所定の順位までの端末の電話番号であることを特徴とする請求項１に記載の電話番号通知システム。
【請求項３】
前記対応テーブルの第２電話番号は、前記第１電話番号に対する通信時間の最上位から所定の順位までの端末の電話番号であることを特徴とする請求項１に記載の電話番号通知システム。
【請求項４】
前記番号管理データベースは、前記第１電話番号に代えて前記利用者を識別する識別子を記録し、
前記対応テーブルは、前記第１電話番号に対応付けて前記識別子を記録する
ことを特徴とする請求項１乃至３の何れかに記載の電話番号通知システム。
【請求項５】
電話番号通知を行う呼制御サーバであって、
ネットワークに接続された端末間の通信を監視して利用者の通信履歴を作成する通信履歴作成部と、
前記通信履歴から、利用者が通常時に使用する第１電話番号と、前記第１電話番号に発呼した端末の第２電話番号とを抽出する電話番号抽出部と、
前記第１電話番号と、前記第２電話番号とを対応付けて対応テーブルに記録する対応テーブル作成部と、
利用者が非常時に使用する端末の第３電話番号、利用者が通常時か又は非常時であるかを表す状況情報、及び前記第１電話番号を、番号管理データベースに登録する登録部と、
前記第２電話番号の端末から前記第１電話番号に発呼した場合に、前記第１電話番号の利用者の前記状況情報が非常時であり、且つ前記対応テーブルに前記第２電話番号が記録済みであれば前記第２電話番号の端末に、前記第３電話番号を送信する送信部と
を備えたことを特徴とする呼制御サーバ。
【請求項６】
呼制御サーバが行う電話番号通知方法であって、
対応テーブルに、利用者が通常時に使用する端末の第１電話番号と、前記第１電話番号に発呼した端末の第２電話番号とを対応付けて記録し、
番号管理データベースに、前記第１電話番号と、利用者が通常時か又は非常時であるかを表す状況情報と、前記利用者が非常時に使用する端末の第３電話番号とを対応付けて記録し、
前記第２電話番号の端末から前記第１電話番号に発呼した場合に、前記第１電話番号の利用者の前記状況情報が非常時であり、且つ前記対応テーブルに前記第２電話番号が記録済みであれば前記第２電話番号の端末に、前記第３電話番号を送信する
ことを特徴とする電話番号通知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、利用者が非常時に使用する電話番号を、関係者に通知する電話番号通知システム、呼制御サーバ、及び電話番号通知方法に関する。
【背景技術】
【０００２】
従来、第三者に自身の連絡先である電話番号を通知する方法としては、例えば特許文献１に開示された方法が知られている。この方法は、利用者が「開示用電話番号」と開示先の「発信者電話番号」を予め登録しておき、登録された発信者端末からの受信があった場合に、「開示用電話番号」を通知するものである。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−５１４２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、例えば大規模災害が発生し、通常時に使用している端末が使用不能になった場合、従来の方法は使用できない。つまり、災害を予測することは困難であるため、罹災後に新たに使用する電話番号を、予め登録しておくことはできない課題がある。
【０００５】
また、近年、携帯電話の普及、および、固定電話の高機能化により必要な連絡先の電話番号は、これらの電話機に登録されている。したがって、大地震や大津波などの大規模災害が発生し、利用者が罹災して通常時に使用していた電話機が使用不能になった場合、利用者は連絡先の情報を失うため関係者と連絡を取るのが困難になる。また、利用者の関係者は、利用者が避難先で利用している電話番号を知る術が無いため、利用者と連絡を取るのができない等の課題がある。
【０００６】
本発明は、これらの課題に鑑みてなされたものであり、利用者が非常時である場合においても第三者に連絡先を通知できるようにした電話番号通知システム、呼制御サーバ、及び電話番号通知方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の電話番号通知システムは、利用者が通常時に使用する端末の第１電話番号と、前記第１電話番号に発呼した端末の第２電話番号とを対応付けて記録する対応テーブルと、前記第１電話番号と、利用者が通常時か又は非常時であるかを表す状況情報と、前記利用者が非常時に使用する端末の第３電話番号とを対応付けて記録する番号管理データベースと、前記第２電話番号の端末から前記第１電話番号に発呼した場合に、前記第１電話番号の利用者の前記状況情報が非常時であり、且つ前記対応テーブルに前記第２電話番号が記録済みであれば前記第２電話番号の端末に、前記第３電話番号を送信する呼制御サーバとを備えたことを要旨とする。
【０００８】
また、本発明の呼制御サーバは、電話番号通知を行う呼制御サーバであって、ネットワークに接続された端末間の通信を監視して利用者の通信履歴を作成する通信履歴作成部と、
前記通信履歴から、利用者が通常時に使用する第１電話番号と、前記第１電話番号に発呼した端末の第２電話番号とを抽出する電話番号抽出部と、前記第１電話番号と、前記第２電話番号とを対応付けて対応テーブルに記録する対応テーブル作成部と、利用者が非常時に使用する端末の第３電話番号、利用者が通常時か又は非常時であるかを表す状況情報、及び前記第１電話番号を、番号管理データベースに登録する登録部と、前記第２電話番号の端末から前記第１電話番号に発呼した場合に、前記第１電話番号の利用者の前記状況情報が非常時であり、且つ前記対応テーブルに前記第２電話番号が記録済みであれば前記第２電話番号の端末に、前記第３電話番号を送信する送信部とを備えたことを要旨とする。
【０００９】
また、本発明の電話番号通知方法は、呼制御サーバが行う電話番号通知方法であって、対応テーブルに、利用者が通常時に使用する端末の第１電話番号と、前記第１電話番号に発呼した端末の第２電話番号とを対応付けて記録し、番号管理データベースに、前記第１電話番号と、利用者が通常時か又は非常時であるかを表す状況情報と、前記利用者が非常時に使用する端末の第３電話番号とを対応付けて記録し、前記第２電話番号の端末から前記第１電話番号に発呼した場合に、前記第１電話番号の利用者の前記状況情報が非常時であり、且つ前記対応テーブルに前記第２電話番号が記録済みであれば前記第２電話番号の端末に、前記第３電話番号を送信することを要旨とする。
【発明の効果】
【００１０】
本発明によれば、利用者が非常時である場合においても第三者に連絡先を通知できる電話番号通知システム、呼制御サーバ、及び電話番号通知方法を提供することができる。
【図面の簡単な説明】
【００１１】
【図１】本実施の形態の電話番号通知システムの構成例を示す図である。
【図２】本実施の形態の呼制御サーバの機能構成例を示す図である。
【図３】本実施の形態の呼制御サーバが行う電話番号通知方法の動作フローを示す図である。
【図４】通信履歴の一例を示す図である。
【図５】登録部の動作フローを示す図である。
【図６】ホワイトリストの一例を示す図である。
【図７】図２に示すホワイトリスト作成部の動作フローの一例を示す図である。
【図８】図２に示す番号管理データベースの一例を示す図である。
【発明を実施するための形態】
【００１２】
以下、本発明の実施の形態について図面を用いて説明する。複数の図面中同一のものに
は同じ参照符号を付し、説明は繰り返さない。
【００１３】
図１に、本実施の形態の電話番号通知システム１の構成例を示す。電話番号通知システム１は、呼制御サーバ１０、対応テーブル２０、番号管理データベース（以降、番号管理ＤＢ）３０、及びネットワーク４０を備える。
【００１４】
ネットワーク４０は、例えば電話回線網である。なお、電話回線網は、交換機回線網で有っても良いし、ＩＰ（Internet Protocol）網で有っても良い。ネットワーク４０を介して、利用者が通常時に使用する第１電話番号の端末２、利用者の知人・友人等である関係者が使用する第２電話番号の端末３、及び利用者が非常時に使用する第３電話番号の端末４が接続する。
【００１５】
図１では、呼制御サーバ１０、対応テーブル２０、及び番号管理ＤＢ３０もネットワーク４０で接続される例を示している。なお、対応テーブル２０と番号管理ＤＢ３０は、呼制御サーバ１０に含めても良い。
【００１６】
ここで、非常時とは、利用者が例えば大地震や大津波などの大規模災害に罹災し、日常生活を営めなくなった状況のことである。なお、非常時は大規模災害に限られない。
【００１７】
以降の説明においては、利用者が罹災した場合で説明する。利用者が通常時に使用していた電話機又は携帯電話が罹災したことで使用不能になり、罹災した利用者が被災地の避難所に避難した状況を想定する。第３電話番号は、その状況における避難所の例えば固定電話の電話番号である。
【００１８】
電話番号通知システム１は、利用者が通常時に使用する端末の第１電話番号と、第１電話番号に発呼した端末の第２電話番号とを対応付けて記録する対応テーブル２０と、第１電話番号と、利用者が通常時か又は非常時であるかを表す状況情報と、利用者が非常時に使用する端末４の第３電話番号とを対応付けて記録する番号管理ＤＢ３０と、第２電話番号の端末３から第１電話番号に発呼した場合に、第１電話番号の利用者の状況情報が非常時であり、且つ対応テーブル２０に第２電話番号が記録済みであれば第２電話番号の端末３に、第３電話番号を送信する呼制御サーバ１０とを備える。
【００１９】
実施の形態に係る電話番号通知システム１によれば、利用者が非常時になった場合においても第三者に連絡先を通知することができる。つまり、第三者が使用する第２電話番号の端末３に、利用者が非常時に使用する端末４の第３電話番号を通知することができる。
【００２０】
ここで、呼制御サーバ１０の機能構成例を示す図２を参照する。呼制御サーバ１０は、通信履歴作成部１１、電話番号抽出部１２、対応テーブル作成部１３、送信部１４、登録部１５、及び通信インターフェース１６を備える。なお、図２において、呼制御サーバ１０が行う一般的な呼制御処理に関する機能構成の表記は省略している。
【００２１】
通信インターフェース１６は、呼制御サーバ１０の機能構成部と、ネットワーク４０を接続するインターフェースである。図２は、ネットワーク４０を介して対応テーブル２０と番号管理ＤＢ３０と、呼制御サーバ１０とが接続する例を示している。なお、図２では省略しているが、呼制御サーバ１０は、ネットワーク４０を介して利用者が通常時に使用する端末２、関係者が使用する第２電話番号の端末３、及び利用者が非常時に使用する第３電話番号の端末４と接続する（図１参照）。
【００２２】
（電話番号通知方法）
ここで、呼制御サーバ１０が行う電話番号通知方法を、その動作フローを示す図３を参照して説明する。図２も同時に参照する。
【００２３】
通信履歴作成部１１は、ネットワーク４０に接続された端末間の通信を監視して利用者の通信履歴１１０を作成する（ステップＳ１）。ここで端末間とは、例えば端末２と端末３との間の通信のことである。なお、通信履歴作成部１１は、呼制御サーバ１０が管轄する全ての端末間の通信を対象に、通信履歴１１０を作成する。
【００２４】
図４に、通信履歴１１０の一例を示す。受信電話番号は、例えば端末２の第１電話番号（03-1234-5678）である。発信電話番号は、例えば端末３の第２電話番号（050-123-4567）である。開始時刻は通信の開始時刻である。終了時刻は通信の終了時刻である。開始時刻と終了時刻は、秒単位での記録が可能である。開始時刻と終了時刻から通信時間を求めることができる。
【００２５】
また、通信履歴１１０には、第１電話番号に対する複数の第２電話番号からの通信も記録される。第２電話番号（043-125-5432）は、図１では表記していない端末の電話番号である。一つの第１電話番号と、その第１電話番号に発呼した端末の第２電話番号とが関連付けられて１個の通信履歴（Ａデータ）を構成する。他の利用者の端末の第１電話番号（011-345-6789）に発呼した端末の第２電話番号のグループはＢデータを構成する。このように通信履歴１１０は、１個の第１電話番号に対応付けられた複数の第２電話番号のグループが、多数個集まって構成される。
【００２６】
電話番号抽出部１２は、通信履歴１１０から、利用者が通常時に使用する端末の第１電話番号と、第１電話番号の端末に発呼した端末の第２電話番号とを抽出する（ステップＳ２）。図４に示す通信履歴１１０からは、第１電話番号（03-1234-5678）と、その第１電話番号に対応する第２電話番号（050-123-4567）と（043-125-5432）が抽出される。また、第１電話番号（011-345-6789）と、第２電話番号（03-123-6701）と（0422-58-3456）と（043-452-6453）とが抽出される。
【００２７】
対応テーブル作成部１３は、第１電話番号に発呼した端末の第２電話番号を対応付けて記録した対応テーブル２０を作成する（ステップＳ３）。なお、対応テーブル２０は、ホワイトリストと称しても良いものである。ホワイトリストは、ブラックリストの対義語であり、警戒する必要のない対象の一覧表のことである。対応テーブル２０の具体的な作成方法については後述する。
【００２８】
送信部１４は、電話番号抽出部１２で抽出された第１電話番号で、番号管理ＤＢ３０を検索し（ステップＳ５のＹＥＳ）、第１電話番号の端末を使用する利用者の状況情報が非常時を表す場合に（ステップＳ６）、第２電話番号の端末に、第３電話番号を送信する（ステップＳ７、Ｓ８）。なお、番号管理ＤＢが複数ある場合、送信部１４（呼制御サーバ）は、他の番号管理ＤＢを第１電話番号で検索する。
【００２９】
なお、第１電話番号が番号管理ＤＢ３０に登録されていない場合（ステップＳ５のＮＯ）、
非常時でない場合（ステップＳ６のＮＯ）、及び対応テーブル２０に第２電話番号が登録されていない場合（ステップＳ７のＮＯ）は、第３電話番号の送信は行われない。
【００３０】
（登録部）
次に、図５に示す登録部１５の動作フローを参照して、その動作を説明する。
【００３１】
登録部１５は、利用者が非常時において使用する端末の第３電話番号と、利用者が通常時か又は非常時であるかを表す状況情報と、第１電話番号とを対応付けて番号管理ＤＢ３０に登録する。第３電話番号と状況情報と第１電話番号の登録は、利用者の要求に基づいて行われる（ステップＳ９のＹＥＳ）。
【００３２】
利用者が罹災後に第３電話番号の端末で、関係者からの通信を受信したい場合、利用者は番号管理ＤＢ３０に第３電話番号を登録する（ステップＳ１０）。そして、状況情報を非常時にセットする（ステップＳ１１）。状況情報は、例えば１ビットの情報であり、非常時の場合にそのビットを１にセットする。通常時の場合は、０にリセットする。続いて利用者は、登録部１５を介して番号管理ＤＢ３０に第１電話番号を登録する（ステップＳ１２）。
【００３３】
以上説明したステップＳ９〜ステップＳ１２の動作は、利用者の登録要求に応じてその都度繰り返される。
【００３４】
〔対応テーブル〕
図６に、対応テーブル２０の一例を示す。対応テーブル２０は、利用者が通常時に使用する端末の第１電話番号と、その第１電話番号の端末に発呼した端末の第２電話番号との組で構成される。なお、図６の１列目に示す識別子は無くても良い。
【００３５】
図７を参照して対応テーブル２０の作成方法について説明する。対応テーブル２０は、例えば通話履歴１１０の第１電話番号に対する通話時間の長い上位１０件の第２電話番号を抽出する（ステップＳ３０）。そして、第１電話番号に対して抽出した第２電話番号を記録して対応テーブル２０を作成する（ステップＳ３１）。
【００３６】
このように、対応テーブル２０は、通信履歴１１０に含まれる第１電話番号と、第１電話番号に対する通信時間の最上位から所定の順位までの端末の第２電話番号とを対応付けたものであっても良い。第１電話番号と、通話時間の多い第２電話番号とで対応テーブル２０を作成することで、特別な操作を必要とすることなく、罹災後に連絡を取る必要のある関係者の第２電話番号を抽出することができる。
【００３７】
また、通話回数の多い上位から所定の順位までの端末の第２電話番号を抽出しても良い。つまり、対応テーブル２０は、通信履歴１１０に含まれる第１電話番号と、第１電話番号に対する発呼回数の最上位から所定の順位までの端末の第２電話番号とを対応付けたものであっても良い。
【００３８】
以上説明したように、通信履歴１１０から自動的に対応テーブル２０を作成することができる。つまり、特別な操作をすることなく、非常時に、利用者が自身の電話番号を知らせたい相手先の電話番号を特定することが可能である。
【００３９】
（変形例）
送信部１４は、第１電話番号をキーとして第２電話番号を検索する例を示したが、この例に限定されない。送信部１４は、識別子をキーとして第２電話番号を検索しても良い。
【００４０】
識別子をキーとして第２電話番号を検索する場合の番号管理ＤＢ３０の一例を図８に示す。番号管理ＤＢ３０は、第３電話番号、識別子、及び状況情報を対応付けて記憶しても良い。つまり、第１電話番号に代えて利用者を識別する識別子を記録するようにしても良い。
【００４１】
この場合、対応テーブル２０は、第１電話番号に対応付けられた識別子を記録する。識別子は、一意の数字、マイナンバー、生体情報等、識別できるもので有れば何であっても良い。なお、識別子と第１電話番号とが対応付けられていれば、図６に示す対応テーブル２０に記録された第１電話番号は不要である。
【００４２】
以上説明したように本実施の形態の電話番号通知システムによれば、利用者が非常時になった場合においても第三者に連絡先を通知できる。その通知は、特定の発信者（第２電話番号）にのみ、例えば避難場所の電話番号（第３電話番号）を通知できる。また、被災者は、自身の電話番号を知らせたい相手先の情報（電話番号）の記録が無くても知らせたい相手先を特定できる。
【００４３】
また、特別な操作が無くても特定の発信者を選別することができる。また、避難所の電話が共用であっても、無駄な通話を発生させない。また、発信者は特別な操作をしなくても呼制御サーバ１０の転送機能によって、被災者の避難場所に電話することができる。
【００４４】
なお、本実施の形態は、利用者が罹災した場合を例に説明を行ったが、それ以外の場合にも適用することが可能である。例えば、非常時では無いが海外旅行の期間も非常時と同様に扱っても良い。例えば滞在先のホテルの端末の電話番号を、第３電話番号として関係者に通知することができる。
【００４５】
また、上記の実施の形態では、呼制御サーバ１０と、番号管理ＤＢ３０と対応テーブル２０とが、ネットワーク４０を介して接続する例で説明したが、本発明はこの例に限定されない。番号管理ＤＢ３０と対応テーブル２０は、呼制御サーバ１０に含めても良い。つまり、電話番号システム１は、１個の呼制御サーバ１０で構成することも可能である。このように本発明は、上記の実施の形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【符号の説明】
【００４６】
１：電話番号通知システム
２、３、４：端末
１０：呼制御サーバ
１１：通信履歴作成部
１２：電話番号抽出部
１３：対応テーブル作成部
１４：送信部
１５：登録部
１６：通信インターフェース
２０：対応テーブル
３０：番号管理データベース
４０：ネットワーク
【図１】
2018026652.tif 000003
【図２】
2018026652.tif 000004
【図３】
2018026652.tif 000005
【図４】
2018026652.tif 000006
【図５】
2018026652.tif 000007
【図６】
2018026652.tif 000008
【図７】
2018026652.tif 000009
【図８】
2018026652.tif 000010