JP2016152446A - 発信地域指定サーバ、発信地域指定システム、および、発信地域指定方法 - Google Patents
発信地域指定サーバ、発信地域指定システム、および、発信地域指定方法 Download PDFInfo
- Publication number
- JP2016152446A JP2016152446A JP2015027755A JP2015027755A JP2016152446A JP 2016152446 A JP2016152446 A JP 2016152446A JP 2015027755 A JP2015027755 A JP 2015027755A JP 2015027755 A JP2015027755 A JP 2015027755A JP 2016152446 A JP2016152446 A JP 2016152446A
- Authority
- JP
- Japan
- Prior art keywords
- call
- area
- life
- control signal
- incoming
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Abstract
【課題】移動体端末のユーザが遠方の地域にいながらも、自身の生活拠点に関連するサービスを受けられるようにすること。【解決手段】発信地域指定サーバ１は、着信先特定用テーブル１１の生活圏フラグが生活圏を優先させる旨であるときには、呼制御信号に付されている発信者ＩＤをもとに、発信者生活圏テーブル１３から対応する生活圏情報を読み取り、その読み取った生活圏情報と着信代表番号との組み合わせをもとに、着信先特定用テーブル１１から対応する着信番号を特定し、特定した着信番号に向けて呼制御信号を転送する。【選択図】図２
Description
本発明は、発信地域指定サーバ、発信地域指定システム、および、発信地域指定方法の技術に関する。
公衆電話網において、発信地域指定サービスが提供されている（例えば、特許文献１、非特許文献１参照）。この発信地域指定サービスでは、単一の受付用電話番号に発信された呼の着信先を、発信端末が在圏する発信地域に応じて切り換える。そのため、企業などが契約した受付用電話番号毎に発信地域と着信電話番号との対応が設定されたデータベースを参照することにより、発信端末の在圏地域に応じて着信電話番号の選択が行われる。
ＮＴＴコミュニケーションズ、"フリーダイヤル（発信地域指定）"、［online］、［2015年2月9日検索］、インターネット〈URL：http://www.ntt.com/freedial/popup/popup2.html〉
移動体端末の普及（特にスマホ）により、固定電話のみで実現していたサービスを移動体端末でも利用したいというニーズが高まっている。しかし、特許文献１などに記載された従来の技術は、発信端末として位置が変化しない固定端末のみ対応可能なシステムであり、発信端末として移動通信端末機は対応不可である。よって、発信地域指定サービスを移動体端末に対応させるように、拡張する必要がある。
以下に、位置が変動する移動通信端末機の位置を特定し、この位置情報を通信網に通知し、動的に変動する発信者の位置情報に応じた呼接続を行うことにより、これまで固定通信端末機のみに対応した発信地域指定システムを、移動端末機にも対応可能なように拡張させることを検討する。
図９（ａ）は、検討例の発信地域指定サービスを示す説明図である。
複数のオペレータ端末３ｚには、同じ受付用電話番号が割り当てられている。移動体端末であるユーザ端末２ｚの発信地域に応じてどのオペレータ端末３ｚを着信先とするかが、切り換わる。
例えば、東京を生活圏とするユーザのユーザ端末２ｚが、東京から発信した場合、発信地域（東京）を担当するオペレータ端末３ｚへ接続される。
一方、京都から別のユーザ端末２ｚが発信した場合、発信地域（京都）を担当する東京とは別のオペレータ端末３ｚへ接続される。
複数のオペレータ端末３ｚには、同じ受付用電話番号が割り当てられている。移動体端末であるユーザ端末２ｚの発信地域に応じてどのオペレータ端末３ｚを着信先とするかが、切り換わる。
例えば、東京を生活圏とするユーザのユーザ端末２ｚが、東京から発信した場合、発信地域（東京）を担当するオペレータ端末３ｚへ接続される。
一方、京都から別のユーザ端末２ｚが発信した場合、発信地域（京都）を担当する東京とは別のオペレータ端末３ｚへ接続される。
図９（ｂ）は、図９（ａ）の発信地域指定サービスの問題点を示す説明図である。
例えば、東京を生活圏とするユーザのユーザ端末２ｚが、東京から京都に移動したとする。そして、移動先の京都からユーザ端末２ｚが発信した場合、発信地域（京都）を担当するオペレータ端末３ｚへ接続される（実線矢印）。しかし、このユーザは、自身の生活圏である東京を担当するオペレータ端末３ｚへの接続を希望している（破線矢印）。
このように、移動体端末の現在位置を単に発信地域とするだけでは、移動体端末の生活圏を考慮した発信地域指定サービスを実現できない場合がある。
例えば、東京を生活圏とするユーザのユーザ端末２ｚが、東京から京都に移動したとする。そして、移動先の京都からユーザ端末２ｚが発信した場合、発信地域（京都）を担当するオペレータ端末３ｚへ接続される（実線矢印）。しかし、このユーザは、自身の生活圏である東京を担当するオペレータ端末３ｚへの接続を希望している（破線矢印）。
このように、移動体端末の現在位置を単に発信地域とするだけでは、移動体端末の生活圏を考慮した発信地域指定サービスを実現できない場合がある。
そこで、本発明は、移動体端末のユーザが遠方の地域にいながらも、自身の生活拠点に関連するサービスを受けられるようにすることを、主な課題とする。
前記課題を解決するために、本発明の発信地域指定サーバは、着信代表ＩＤごとに、その着信代表ＩＤあての呼制御信号の発信地域として、生活圏を優先させるか否かを示す生活圏フラグと、発信地域ごとの着信番号とを対応づける着信先特定用データと、
発信者ＩＤごとに、その発信者の生活圏情報を対応づける生活圏特定用データと、がそれぞれ格納されている記憶手段と、
前記呼制御信号の通知を受け、その呼制御信号の着番号である前記着信代表ＩＤをもとに、前記着信先特定用データから対応する前記生活圏フラグを読み込み、
前記生活圏フラグが生活圏を優先させる旨であるときには、前記呼制御信号に付されている前記発信者ＩＤをもとに、前記生活圏特定用データから対応する前記生活圏情報を読み取り、その読み取った生活圏情報と前記着信代表ＩＤとの組み合わせをもとに、前記着信先特定用データから対応する着信番号を特定し、
前記生活圏フラグが生活圏を優先させない旨であるときには、前記呼制御信号に付されている発信端末の現在位置と前記着信代表ＩＤとの組み合わせをもとに、前記着信先特定用データから対応する着信番号を特定し、
前記通知された前記呼制御信号の着番号を前記着信代表ＩＤから前記特定した着信番号へと置き換えてから、前記特定した着信番号に向けて前記呼制御信号を転送する制御部とを有することを特徴とする。
発信者ＩＤごとに、その発信者の生活圏情報を対応づける生活圏特定用データと、がそれぞれ格納されている記憶手段と、
前記呼制御信号の通知を受け、その呼制御信号の着番号である前記着信代表ＩＤをもとに、前記着信先特定用データから対応する前記生活圏フラグを読み込み、
前記生活圏フラグが生活圏を優先させる旨であるときには、前記呼制御信号に付されている前記発信者ＩＤをもとに、前記生活圏特定用データから対応する前記生活圏情報を読み取り、その読み取った生活圏情報と前記着信代表ＩＤとの組み合わせをもとに、前記着信先特定用データから対応する着信番号を特定し、
前記生活圏フラグが生活圏を優先させない旨であるときには、前記呼制御信号に付されている発信端末の現在位置と前記着信代表ＩＤとの組み合わせをもとに、前記着信先特定用データから対応する着信番号を特定し、
前記通知された前記呼制御信号の着番号を前記着信代表ＩＤから前記特定した着信番号へと置き換えてから、前記特定した着信番号に向けて前記呼制御信号を転送する制御部とを有することを特徴とする。
これにより、生活圏フラグが生活圏を優先させるときには、事前登録された生活圏情報が発信端末の現在位置よりも優先して発信地域とみなされるので、移動体端末のユーザが遠方の地域にいながらも、自身の生活拠点に関連するサービスを受けられるようにすることができる。
本発明は、前記生活圏特定用データには、前記発信者ＩＤごとに、その発信者の生活圏情報に加えて、その発信端末番号が対応づけられており、
前記生活圏フラグが生活圏を優先させる旨であるときには、前記呼制御信号に付されている前記発信者ＩＤをもとに、前記生活圏特定用データから対応する前記生活圏情報に加えて、対応する前記発信端末番号を読み取り、
前記呼制御信号を転送するときに、前記読み取った発信端末番号を発番号とすることを特徴とする。
前記生活圏フラグが生活圏を優先させる旨であるときには、前記呼制御信号に付されている前記発信者ＩＤをもとに、前記生活圏特定用データから対応する前記生活圏情報に加えて、対応する前記発信端末番号を読み取り、
前記呼制御信号を転送するときに、前記読み取った発信端末番号を発番号とすることを特徴とする。
これにより、発信端末からの呼制御信号に対して発信端末番号を直接記載する必要がなくなるので、Ｗｅｂアクセスの呼制御信号にも対応した発信地域指定サービスを提供できる。
本発明は、前記発信端末の契約時に入力される前記発信者ＩＤと、その発信者の生活圏情報との対応情報を受け付け、その受け付けた対応情報を前記生活圏特定用データに登録することを特徴とする。
これにより、ユーザは発信端末を直接操作することなく、通信事業者のオペレータなどに生活圏情報の登録を契約時に代行してもらえる。
本発明は、前記発信地域指定サーバと、前記発信端末とを含めて構成され、
前記発信端末が、自身の位置測定手段により測定した位置情報を、前記生活圏特定用データに登録することを特徴とする。
前記発信端末が、自身の位置測定手段により測定した位置情報を、前記生活圏特定用データに登録することを特徴とする。
これにより、最新で正確な位置情報を生活圏情報として登録できる。
本発明は、前記発信地域指定サーバと、外部データベースシステムとを含めて構成され、
前記外部データベースシステムが、前記発信端末から書き込まれる位置情報を、前記生活圏特定用データに登録することを特徴とする。
前記外部データベースシステムが、前記発信端末から書き込まれる位置情報を、前記生活圏特定用データに登録することを特徴とする。
これにより、発信端末のユーザは、生活圏情報の登録専用の操作を習得しなくても、日常的に活用している外部データベースシステムを経由して、生活圏情報として登録できる。
本発明によれば、移動体端末のユーザが遠方の地域にいながらも、自身の生活拠点に関連するサービスを受けられるようにすることができる。
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
図１（ａ）は、発信地域指定システムの登録処理を示す説明図である。発信地域指定システムは、発信地域指定サーバ１と、ユーザ端末２と、オペレータ端末３と、外部ＤＢ２ｃとがネットワークで接続されて構成される。
これらの発信地域指定システムの各装置は、ＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
これらの発信地域指定システムの各装置は、ＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
ユーザ端末２は、オペレータ端末３に発呼するためにユーザが使用する端末である。オペレータ端末３は、ユーザ端末２からの発呼を着信する端末である。外部ＤＢ２ｃは、例えば、Facebook（登録商標）などのＳＮＳ（Social Networking Service）サーバであり、ユーザ端末２から投稿記事とともに、そのユーザ端末２の位置情報（緯度経度情報）が適宜書き込まれる。
発信地域指定サーバ１は、他装置（ユーザ端末２、オペレータ端末３、外部ＤＢ２ｃ）から、ユーザ端末２の生活圏（例えば、東京）の位置情報（緯度経度情報）の登録を受け付ける。
発信地域指定サーバ１は、他装置（ユーザ端末２、オペレータ端末３、外部ＤＢ２ｃ）から、ユーザ端末２の生活圏（例えば、東京）の位置情報（緯度経度情報）の登録を受け付ける。
図１（ｂ）は、図１（ａ）の発信地域指定システムの呼接続処理を示す説明図である。
図９（ｂ）と比較すると、移動先の京都からの発信は、直接京都のオペレータ端末３に転送される代わりに、発信地域指定サーバ１に転送される。そして、発信地域指定サーバ１は、図１（ａ）で事前登録されたユーザ端末２の生活圏（＝東京）を考慮して、ユーザ端末２の現在地（京都）よりも生活圏（東京）を優先させて発信地域とみなし、その発信地域を担当するオペレータ端末３へと呼接続を転送する。
これにより、このユーザは、移動先の京都にいながら、自身の生活圏である東京を担当するオペレータ端末３への接続を享受できる。
図９（ｂ）と比較すると、移動先の京都からの発信は、直接京都のオペレータ端末３に転送される代わりに、発信地域指定サーバ１に転送される。そして、発信地域指定サーバ１は、図１（ａ）で事前登録されたユーザ端末２の生活圏（＝東京）を考慮して、ユーザ端末２の現在地（京都）よりも生活圏（東京）を優先させて発信地域とみなし、その発信地域を担当するオペレータ端末３へと呼接続を転送する。
これにより、このユーザは、移動先の京都にいながら、自身の生活圏である東京を担当するオペレータ端末３への接続を享受できる。
図２は、図１の発信地域指定システムのうちの、発信地域指定サーバ１と、ユーザ端末２との詳細を示す構成図である。
発信地域指定サーバ１は、着信先特定用テーブル１１と、着信検索部１２と、発信者生活圏テーブル１３と、発信検索部１４と、ＣＡ特定用テーブル１５と、ＣＡ検索部１６と、方形区画番号算出部１７と、制御部１８と、呼信号処理部１９ａと、通信部１９ｂと、ＮＴＰ（Network Time Protocol）サーバ１９ｃとを含めて構成される。
ユーザ端末２は、呼制御部２１と、メディア処理部２２と、マイク２３と、カメラ２４と、通信部２５と、電話帳２６と、ブラウザ２７と、位置情報取得部２９と、ＧＰＳ（Global Positioning System）２９ａと、Ａ−ＧＰＳ（Assisted GPS）２９ｂと、無線通信部２９ｃとを含めて構成される。
ユーザ端末２は、呼制御部２１と、メディア処理部２２と、マイク２３と、カメラ２４と、通信部２５と、電話帳２６と、ブラウザ２７と、位置情報取得部２９と、ＧＰＳ（Global Positioning System）２９ａと、Ａ−ＧＰＳ（Assisted GPS）２９ｂと、無線通信部２９ｃとを含めて構成される。
発信検索部１４は、ユーザ端末２を使用するユーザごとに、その生活圏を示す情報を発信者生活圏テーブル１３に登録するとともに、要求に応じて検索する（詳細は、図３（ｂ））。
着信検索部１２は、着信先を示す情報（着信代表番号または着信ＵＲＬ（Uniform Resource Locator））ごとに、特定された発信区域（発信元ＣＡ）に対応する着信番号を、着信先特定用テーブル１１から検索する（詳細は、図３（ａ））。
方形区画番号算出部１７は、ユーザ端末２を使用するユーザの現在地または生活圏を示す緯度経度情報からその方形区画座標を算出する（詳細は、図５）。
ＣＡ検索部１６は、方形区画座標をもとに、ユーザ端末２の発信区域（発信元ＣＡ）をＣＡ特定用テーブル１５から検索する（詳細は、図３（ｃ））。
着信検索部１２は、着信先を示す情報（着信代表番号または着信ＵＲＬ（Uniform Resource Locator））ごとに、特定された発信区域（発信元ＣＡ）に対応する着信番号を、着信先特定用テーブル１１から検索する（詳細は、図３（ａ））。
方形区画番号算出部１７は、ユーザ端末２を使用するユーザの現在地または生活圏を示す緯度経度情報からその方形区画座標を算出する（詳細は、図５）。
ＣＡ検索部１６は、方形区画座標をもとに、ユーザ端末２の発信区域（発信元ＣＡ）をＣＡ特定用テーブル１５から検索する（詳細は、図３（ｃ））。
呼信号処理部１９ａは、ユーザ端末２からの発呼をオペレータ端末３への着呼として中継するように呼制御を実施する。
制御部１８は、呼信号処理部１９ａからの通知を受け、発信地域指定サーバ１の各構成要素を適宜実行させる。
通信部１９ｂは、発信地域指定システムの他装置（ユーザ端末２、オペレータ端末３など）と接続するインタフェースである。なお、通信部１９ｂが接続するネットワークの種別は、例えば、移動体通信網、ＩＰ（Internet Protocol）通信網、および、公衆電話網が例示される。
ＮＴＰサーバ１９ｃは、ネットワークに接続される各装置の時計を正しい時刻へ同期する。
制御部１８は、呼信号処理部１９ａからの通知を受け、発信地域指定サーバ１の各構成要素を適宜実行させる。
通信部１９ｂは、発信地域指定システムの他装置（ユーザ端末２、オペレータ端末３など）と接続するインタフェースである。なお、通信部１９ｂが接続するネットワークの種別は、例えば、移動体通信網、ＩＰ（Internet Protocol）通信網、および、公衆電話網が例示される。
ＮＴＰサーバ１９ｃは、ネットワークに接続される各装置の時計を正しい時刻へ同期する。
呼制御部２１は、他の装置との間で通信を行なうための回線の接続や切断を行う。
メディア処理部２２は、マイク２３を介して入力される音声データ、および、カメラ２４を介して入力される画像データを、通信部２５を介して他の装置との間で送受信する制御を司る。
電話帳２６には、ユーザ端末２やオペレータ端末３などの各装置との間で呼制御信号をやりとりするための電話番号やＵＲＬが登録されている。
ブラウザ２７は、利用者の操作にしたがって所望のＷｅｂページ画面を表示したり、データの入力を受け付けたりする。
メディア処理部２２は、マイク２３を介して入力される音声データ、および、カメラ２４を介して入力される画像データを、通信部２５を介して他の装置との間で送受信する制御を司る。
電話帳２６には、ユーザ端末２やオペレータ端末３などの各装置との間で呼制御信号をやりとりするための電話番号やＵＲＬが登録されている。
ブラウザ２７は、利用者の操作にしたがって所望のＷｅｂページ画面を表示したり、データの入力を受け付けたりする。
位置情報取得部２９は、ＧＰＳ２９ａ、Ａ−ＧＰＳ２９ｂ、および無線通信部２９ｃによって測位された位置情報のなかから、所定の優先順位でいずれか１つの位置情報を選択して取得する。この優先順位は、（１）Ａ−ＧＰＳ２９ｂ、（２）ＧＰＳ２９ａ、（３）無線通信部２９ｃとすることが好ましい。
ＧＰＳ２９ａは、地球を周回している複数のＧＰＳ衛星９ａから測位信号（ＧＰＳ信号）を受信することによって、自身の緯度経度および高度を測位する。
Ａ−ＧＰＳ２９ｂは、ＧＰＳ衛星９ａからの測位信号に加えて、ＧＰＳ信号に含まれるデータの一部を移動体通信網の基地局９ｂから高速受信することで、測位エリアを拡大するとともに測位時間を短縮する。
無線通信部２９ｃは、Wi-Fi（Wireless Fidelity）（登録商標）規格などの無線通信を行う無線ルータ９ｃが保持している緯度経度の位置情報に基づいて自身の緯度経度を測位する。
ＧＰＳ２９ａは、地球を周回している複数のＧＰＳ衛星９ａから測位信号（ＧＰＳ信号）を受信することによって、自身の緯度経度および高度を測位する。
Ａ−ＧＰＳ２９ｂは、ＧＰＳ衛星９ａからの測位信号に加えて、ＧＰＳ信号に含まれるデータの一部を移動体通信網の基地局９ｂから高速受信することで、測位エリアを拡大するとともに測位時間を短縮する。
無線通信部２９ｃは、Wi-Fi（Wireless Fidelity）（登録商標）規格などの無線通信を行う無線ルータ９ｃが保持している緯度経度の位置情報に基づいて自身の緯度経度を測位する。
図３（ａ）は、着信先特定用テーブル１１を示す構成図である。
着信先特定用テーブル１１は、着信代表番号と、着信URLと、生活圏フラグと、接続先ＣＡコードと、ＣＡ名と、接続先の着信番号とを対応づけて構成される。なお、ＣＡ（Charge Area）とは、電話の料金区域であり、ＣＡコードとはＣＡの識別情報であり、ＣＡ名とは料金区域の識別名である。
ユーザ端末２がオペレータ端末３の着信先（着信代表ＩＤ）として着信代表番号または着信ＵＲＬを指定した発呼を送信すると、着信検索部１２は、対応する発信地域ごとの接続先情報（接続先ＣＡコードと、そのＣＡコードが示すＣＡ名と、そのＣＡ名を担当する接続先であるオペレータ端末３の着信番号）を検索する。
着信先特定用テーブル１１は、着信代表番号と、着信URLと、生活圏フラグと、接続先ＣＡコードと、ＣＡ名と、接続先の着信番号とを対応づけて構成される。なお、ＣＡ（Charge Area）とは、電話の料金区域であり、ＣＡコードとはＣＡの識別情報であり、ＣＡ名とは料金区域の識別名である。
ユーザ端末２がオペレータ端末３の着信先（着信代表ＩＤ）として着信代表番号または着信ＵＲＬを指定した発呼を送信すると、着信検索部１２は、対応する発信地域ごとの接続先情報（接続先ＣＡコードと、そのＣＡコードが示すＣＡ名と、そのＣＡ名を担当する接続先であるオペレータ端末３の着信番号）を検索する。
なお、生活圏フラグが「○」であるときには、ユーザ端末２の現在地よりも生活圏を優先させて発信地域とみなす。
例えば、武蔵野市を生活圏とするユーザについて、そのユーザ端末２の現在地＝京都から「0120-xxxx」あてに発呼された場合、生活圏フラグが「○」であるので、着信先特定用テーブル１１の「接続先ＣＡコード＝武蔵野市」に該当し、発信地域指定サーバ１は、着信番号「0422-59-xxxx」へと接続する。
例えば、武蔵野市を生活圏とするユーザについて、そのユーザ端末２の現在地＝京都から「0120-xxxx」あてに発呼された場合、生活圏フラグが「○」であるので、着信先特定用テーブル１１の「接続先ＣＡコード＝武蔵野市」に該当し、発信地域指定サーバ１は、着信番号「0422-59-xxxx」へと接続する。
一方、生活圏フラグが「×」であるときには、ユーザ端末２の現在地を生活圏よりも優先させて発信地域とみなす。
例えば、国分寺を生活圏とするユーザについて、そのユーザ端末２の現在地＝京都から「0123-vvvv」あてに発呼された場合、生活圏フラグが「×」であるので、着信先特定用テーブル１１の「接続先ＣＡコード＝京都」に該当し、発信地域指定サーバ１は、着信番号「075-200-xxxx」へと接続する。
例えば、国分寺を生活圏とするユーザについて、そのユーザ端末２の現在地＝京都から「0123-vvvv」あてに発呼された場合、生活圏フラグが「×」であるので、着信先特定用テーブル１１の「接続先ＣＡコード＝京都」に該当し、発信地域指定サーバ１は、着信番号「075-200-xxxx」へと接続する。
図３（ｂ）は、発信者生活圏テーブル１３を示す構成図である。
発信者生活圏テーブル１３は、発信端末番号と、発信者ＩＤと、生活圏情報（生活圏と、生活圏ＣＡコードと、ＣＡ名）とを対応づけて構成される。
ユーザ端末２に割り当てられた電話番号である発信端末番号と、ユーザ端末２に割り当てられたＩＭＥＩ（International Mobile Equipment Identity）やＭＡＣ（Media Access Control）アドレスなどの固有のＩＤである発信者ＩＤとは、それぞれ発信者を特定する情報である。
１人の発信者を特定する情報ごとに、１つの生活圏情報（生活圏と、生活圏ＣＡコードと、ＣＡ名）が登録される。
発信者生活圏テーブル１３は、発信端末番号と、発信者ＩＤと、生活圏情報（生活圏と、生活圏ＣＡコードと、ＣＡ名）とを対応づけて構成される。
ユーザ端末２に割り当てられた電話番号である発信端末番号と、ユーザ端末２に割り当てられたＩＭＥＩ（International Mobile Equipment Identity）やＭＡＣ（Media Access Control）アドレスなどの固有のＩＤである発信者ＩＤとは、それぞれ発信者を特定する情報である。
１人の発信者を特定する情報ごとに、１つの生活圏情報（生活圏と、生活圏ＣＡコードと、ＣＡ名）が登録される。
図３（ｃ）は、ＣＡ特定用テーブル１５を示す構成図である。
ＣＡ特定用テーブル１５は、料金区域（ＣＡ）ごとに、その方形区画番号（Xnca,Ynca）と、ＣＡコードと、ＣＡ名とが対応づけて構成される。ＣＡ検索部１６は、方形区画番号算出部１７が求めた方形区画番号（Xnca,Ynca）を検索キーとして、ＣＡ特定用テーブル１５から対応するＣＡコードと、ＣＡ名とを抽出する。
ＣＡ特定用テーブル１５は、料金区域（ＣＡ）ごとに、その方形区画番号（Xnca,Ynca）と、ＣＡコードと、ＣＡ名とが対応づけて構成される。ＣＡ検索部１６は、方形区画番号算出部１７が求めた方形区画番号（Xnca,Ynca）を検索キーとして、ＣＡ特定用テーブル１５から対応するＣＡコードと、ＣＡ名とを抽出する。
図４は、発信地域指定システムの登録処理を示すフローチャートである。本フローチャートの開始前の準備として、制御部１８は、ＮＴＰサーバ１９ｃと定期的に同期を取ることで、正しい時刻を発信地域指定サーバ１に設定しておく。
Ｓ１０１は、開始契機を待つ処理である。以下に示すように、制御部１８は、発信者生活圏テーブル１３に登録する生活圏情報の情報源に応じた開始契機になるまで待つ。
オペレータ端末３からの登録：ユーザがユーザ端末２を初回契約したとき。
ユーザ端末２からの登録：ユーザが生活圏にいる深夜などの時間帯。または、ユーザがユーザ端末２を操作して、生活圏情報の送信指示を出したとき。
外部ＤＢ２ｃからの登録：外部ＤＢ２ｃにユーザ端末２の緯度経度情報が書き込まれたとき。または、１ヶ月に１回などの所定期間ごと。
オペレータ端末３からの登録：ユーザがユーザ端末２を初回契約したとき。
ユーザ端末２からの登録：ユーザが生活圏にいる深夜などの時間帯。または、ユーザがユーザ端末２を操作して、生活圏情報の送信指示を出したとき。
外部ＤＢ２ｃからの登録：外部ＤＢ２ｃにユーザ端末２の緯度経度情報が書き込まれたとき。または、１ヶ月に１回などの所定期間ごと。
Ｓ１０２は、対象者のリストアップ処理である。制御部１８は、発信者生活圏テーブル１３の発信者ＩＤのうち、全ての発信者、または、対応する生活圏が未記入の発信者を、今回の発信者生活圏テーブル１３への登録対象者として、その発信端末番号または発信者ＩＤをリストアップする。
よって、図４のフローチャートを開始する前に、オペレータ端末３などは、発信地域指定システムにおいて生活圏の情報を活用したいユーザの発信端末番号と発信者ＩＤとを、あらかじめ発信者生活圏テーブル１３に登録しておく。
Ｓ１１１〜Ｓ１１８は、Ｓ１０２でリストアップされた対象者を一人ずつ選択するループである。
よって、図４のフローチャートを開始する前に、オペレータ端末３などは、発信地域指定システムにおいて生活圏の情報を活用したいユーザの発信端末番号と発信者ＩＤとを、あらかじめ発信者生活圏テーブル１３に登録しておく。
Ｓ１１１〜Ｓ１１８は、Ｓ１０２でリストアップされた対象者を一人ずつ選択するループである。
Ｓ１１２は、生活圏情報の情報源に応じた分岐処理である。制御部１８は、情報源がオペレータ端末３からの場合（Ｓ１１２，オペレータ端末）はＳ１１３へ、情報源がユーザ端末２からの場合（Ｓ１１２，ユーザ端末）はＳ１１４へ、情報源が外部ＤＢ２ｃからの場合（Ｓ１１２，外部ＤＢ）はＳ１１５へ、それぞれ処理を分岐させる。
Ｓ１１３は、オペレータ端末３から緯度経度情報（またはその変換結果である生活圏情報のＣＡコード）を取得する処理である。
Ｓ１１３は、オペレータ端末３から緯度経度情報（またはその変換結果である生活圏情報のＣＡコード）を取得する処理である。
Ｓ１１４は、ユーザ端末２から緯度経度情報を取得する処理である。
制御部１８は、Ｓ１０２で取得した発信端末番号または発信者ＩＤを用いて、ユーザ端末２の位置情報取得部２９に対して、そのユーザ端末２の緯度経度情報を取得する旨の要求を送信する。その応答として、制御部１８は、ユーザ端末２の緯度経度情報を取得する。
または、契約者は、自身の契約端末であるユーザ端末２を介して、自身の生活圏情報を発信者生活圏テーブル１３に登録する。この登録処理は、例えば、ユーザ端末２内のブラウザ２７を介して、HTTPなどのプロトコルを利用して、アクセスされる。
制御部１８は、Ｓ１０２で取得した発信端末番号または発信者ＩＤを用いて、ユーザ端末２の位置情報取得部２９に対して、そのユーザ端末２の緯度経度情報を取得する旨の要求を送信する。その応答として、制御部１８は、ユーザ端末２の緯度経度情報を取得する。
または、契約者は、自身の契約端末であるユーザ端末２を介して、自身の生活圏情報を発信者生活圏テーブル１３に登録する。この登録処理は、例えば、ユーザ端末２内のブラウザ２７を介して、HTTPなどのプロトコルを利用して、アクセスされる。
Ｓ１１５は、外部ＤＢ２ｃから緯度経度情報を取得する処理である。制御部１８は、クラウドなどの外部ネットワークを介して、外部ＤＢ２ｃに登録されている生活圏情報を抽出する。
Ｓ１１６は、Ｓ１１３〜Ｓ１１５のいずれかで取得した緯度経度情報をＣＡコードへ変換する処理である。そのため、まず方形区画番号算出部１７は、ユーザ端末２を使用するユーザの現在地または生活圏を示す緯度経度情報からその方形区画座標を算出する（詳細は、図５）。次に、ＣＡ検索部１６は、算出された方形区画座標をもとに、ユーザ端末２の発信区域（発信元ＣＡ）をＣＡ特定用テーブル１５から検索する。なお、Ｓ１１３〜Ｓ１１５のいずれかで取得した生活圏情報がすでにＣＡコードの形式である場合、Ｓ１１６の変換処理は省略できる。
Ｓ１１６は、Ｓ１１３〜Ｓ１１５のいずれかで取得した緯度経度情報をＣＡコードへ変換する処理である。そのため、まず方形区画番号算出部１７は、ユーザ端末２を使用するユーザの現在地または生活圏を示す緯度経度情報からその方形区画座標を算出する（詳細は、図５）。次に、ＣＡ検索部１６は、算出された方形区画座標をもとに、ユーザ端末２の発信区域（発信元ＣＡ）をＣＡ特定用テーブル１５から検索する。なお、Ｓ１１３〜Ｓ１１５のいずれかで取得した生活圏情報がすでにＣＡコードの形式である場合、Ｓ１１６の変換処理は省略できる。
Ｓ１１７は、Ｓ１１６で変換されたＣＡコードの登録処理である。制御部１８は、Ｓ１１１〜Ｓ１１８のループで選択された対象者の発信者ＩＤと対応づけて、Ｓ１１６で変換されたＣＡコードを、発信者生活圏テーブル１３に登録する。
なお、このＳ１１７の登録処理について、Ｓ１１４，Ｓ１１５で緯度経度情報を取得した場合は、あらかじめ事前登録された契約者の特定情報（発信端末番号、発信者ＩＤ）に対して、Ｓ１１６で変換されたＣＡコードを対応づける。
一方、Ｓ１１３でオペレータ端末３を経由する場合は、契約者の特定情報（発信端末番号、発信者ＩＤ）とその契約者の生活圏情報（緯度経度情報から変換されるＣＡコード）との対応情報が、契約者（端末所有者）の代理でオペレータ端末３などを介して、入力される。
一方、Ｓ１１３でオペレータ端末３を経由する場合は、契約者の特定情報（発信端末番号、発信者ＩＤ）とその契約者の生活圏情報（緯度経度情報から変換されるＣＡコード）との対応情報が、契約者（端末所有者）の代理でオペレータ端末３などを介して、入力される。
図５は、方形区画番号算出部１７の処理（Ｓ１１６）を示す説明図である。方形区画番号算出部１７は、ユーザ端末２の緯度経度情報からその方形区画座標を算出する。
方形区画座標とは、国内の通信事業者が共通して用いる国内の任意の地点を示すための座標である。方形区画座標のＣＡ原点（０，０）は、与論島と沖縄本島との中間付近の緯度経度＝（θica,θkca）の位置に設けられている。
方形区画座標とは、国内の通信事業者が共通して用いる国内の任意の地点を示すための座標である。方形区画座標のＣＡ原点（０，０）は、与論島と沖縄本島との中間付近の緯度経度＝（θica,θkca）の位置に設けられている。
例えば、東京の方形区画座標は、東西方向の距離（2Yca）と南北方向の距離（2Xca）とを組み合わせて、（2Yca,2Xca）とする。なお、距離に乗数２を用いるのは、１区画の大きさが縦横２ｋｍ単位だからである。方形区画番号算出部１７は、東京の緯度経度＝（θi,θk）から、東京の方形区画座標（2Yca,2Xca）を求めるため、以下の式を計算する。
2Yca＝Re・（θk−θkca）・cosθica
2Xca＝Re・（θi−θica）
ただし、「Re」は地球の半径を示し、「Re・（θk−θkca）」はＣＡ原点の緯度の半径を示し、「θk-θkca」はＣＡ原点の経度と東京の経度との差を示し、「θi−θica」はＣＡ原点の緯度と東京の緯度との差を示す。
2Yca＝Re・（θk−θkca）・cosθica
2Xca＝Re・（θi−θica）
ただし、「Re」は地球の半径を示し、「Re・（θk−θkca）」はＣＡ原点の緯度の半径を示し、「θk-θkca」はＣＡ原点の経度と東京の経度との差を示し、「θi−θica」はＣＡ原点の緯度と東京の緯度との差を示す。
方形区画番号とは、国内全域を市内通話料金で通話できる通話区域である単位料金区域（ＭＡ：Message Area）に分割するときの最小単位である料金区域（ＣＡ）のそれぞれについて、その代表地点の位置を方形区画座標によって表したものである。
換言すると、方形区画番号とは、各方形区画の代表地点のうちの方形区画座標からの距離が最小となる代表地点について、その方形区画の番号である。
方形区画番号算出部１７は、例えば、東京の方形区画座標（2Yca,2Xca）から東京の方形区画番号（Xca,Yca）を求めるために、両座標の順序を入れ替え、両座標の値を２で除算する。
換言すると、方形区画番号とは、各方形区画の代表地点のうちの方形区画座標からの距離が最小となる代表地点について、その方形区画の番号である。
方形区画番号算出部１７は、例えば、東京の方形区画座標（2Yca,2Xca）から東京の方形区画番号（Xca,Yca）を求めるために、両座標の順序を入れ替え、両座標の値を２で除算する。
以下、図６〜図８の各シーケンス図を参照して、発信地域指定システムの呼接続処理を説明する。これらのシーケンス図およびその説明では、以下の表記を用いる。
「who:」は、ユーザ端末２の使用者であり、発信者を示す情報である。具体的には、発信者生活圏テーブル１３の発信端末番号や発信者ＩＤが記載される。
「from:」は、ユーザ端末２の発信地域を示す情報である。着信先特定用テーブル１１では接続先ＣＡコードやＣＡ名に該当し、発信者生活圏テーブル１３では生活圏ＣＡコードやＣＡ名に該当する。
「to:」は、着信先であるオペレータ端末３を示す情報である。着信先は、ユーザ端末２によって発呼時に代表指定されるもの（着信先特定用テーブル１１の着信代表番号や着信ＵＲＬ）と、その代表に対して発信地域をもとに特定された接続先指定されるもの（着信先特定用テーブル１１の接続先の着信番号）とがある。
「who:」は、ユーザ端末２の使用者であり、発信者を示す情報である。具体的には、発信者生活圏テーブル１３の発信端末番号や発信者ＩＤが記載される。
「from:」は、ユーザ端末２の発信地域を示す情報である。着信先特定用テーブル１１では接続先ＣＡコードやＣＡ名に該当し、発信者生活圏テーブル１３では生活圏ＣＡコードやＣＡ名に該当する。
「to:」は、着信先であるオペレータ端末３を示す情報である。着信先は、ユーザ端末２によって発呼時に代表指定されるもの（着信先特定用テーブル１１の着信代表番号や着信ＵＲＬ）と、その代表に対して発信地域をもとに特定された接続先指定されるもの（着信先特定用テーブル１１の接続先の着信番号）とがある。
さらに、ある信号Ａに含まれるデータａ，ｂ，ｃが存在するとき、「信号Ａ（データａ／データｂ／データｃ）」と表記する。この表記は、信号Ａに含まれる最小限のデータ群を例示したものであり、列挙されない別のデータ（データｄ）が信号Ａに含まれることとしてもよい。
図６は、発信地域指定システムの呼接続処理の第１例を示すシーケンス図である。この第１例では、着信代表番号あての発呼について、ユーザの生活圏（武蔵野市）をユーザ端末２の発信地域とみなすことを特徴とする。
Ｓ２０１は、電話発信処理である。ユーザ端末２は、電話発信時に自身の現位置情報を取得し、ＳＩＰ（Session Initiation Protocol）などの呼制御信号（who:発番号＝080-2552-xxxx／from:京都／to:0120-xxxx）に含めてから呼信号処理部１９ａに送信（電話発信）する。なお、呼制御信号に含まれる各データは、次の通りである。
・who:発番号＝080-2552-xxxx（図では「080-**」と略）は、発信者生活圏テーブル１３の第１行のものである。
・from:京都は、ユーザ端末２の現位置情報（緯度・経度）である。
・to:代表番号＝0120-xxxx（図では「0120-**」と略）は、着信先特定用テーブル１１の第１行のものである。
Ｓ２０１は、電話発信処理である。ユーザ端末２は、電話発信時に自身の現位置情報を取得し、ＳＩＰ（Session Initiation Protocol）などの呼制御信号（who:発番号＝080-2552-xxxx／from:京都／to:0120-xxxx）に含めてから呼信号処理部１９ａに送信（電話発信）する。なお、呼制御信号に含まれる各データは、次の通りである。
・who:発番号＝080-2552-xxxx（図では「080-**」と略）は、発信者生活圏テーブル１３の第１行のものである。
・from:京都は、ユーザ端末２の現位置情報（緯度・経度）である。
・to:代表番号＝0120-xxxx（図では「0120-**」と略）は、着信先特定用テーブル１１の第１行のものである。
Ｓ２０２は、発信通知処理である。
呼信号処理部１９ａは、Ｓ２０１の呼制御信号（who:発番号＝080-2552-xxxx／from:京都／to:0120-xxxx）をそのまま制御部１８に通知（自動的にルーチング）する。
Ｓ２１１は、生活圏確認処理である。制御部１８は、着信先特定用テーブル１１（着信検索部１２）に対して、Ｓ２０２の呼制御信号に含まれる（to:0120-xxxx）を検索キーとして、その生活圏フラグが○か×かを確認させる。
Ｓ２１２は、確認応答処理である。今回は、図３（ｂ）で示したとおり生活圏フラグが○であるので、着信検索部１２は、その旨を制御部１８に応答する。
呼信号処理部１９ａは、Ｓ２０１の呼制御信号（who:発番号＝080-2552-xxxx／from:京都／to:0120-xxxx）をそのまま制御部１８に通知（自動的にルーチング）する。
Ｓ２１１は、生活圏確認処理である。制御部１８は、着信先特定用テーブル１１（着信検索部１２）に対して、Ｓ２０２の呼制御信号に含まれる（to:0120-xxxx）を検索キーとして、その生活圏フラグが○か×かを確認させる。
Ｓ２１２は、確認応答処理である。今回は、図３（ｂ）で示したとおり生活圏フラグが○であるので、着信検索部１２は、その旨を制御部１８に応答する。
Ｓ２１３は、生活圏要求処理である。制御部１８は、発信者生活圏テーブル１３（発信検索部１４）に対して、Ｓ２０２の呼制御信号に含まれる各データを含むクエリ（who:080-2552-xxxx／from:京都／to:0120-xxxx）を通知し、そのクエリに合致する生活圏情報を要求する。なお、生活圏情報はユーザ（who:）に対応づけられているので、その他の情報（from:とto:）はクエリから省略してもよい。
Ｓ２１４は、生活圏応答処理である。発信検索部１４は、Ｓ２１３のクエリの（who:080-2552-xxxx）から発信者生活圏テーブル１３を検索し、その検索結果である生活圏ＣＡコード（42200＝武蔵野市）を制御部１８に応答する。
Ｓ２１４は、生活圏応答処理である。発信検索部１４は、Ｓ２１３のクエリの（who:080-2552-xxxx）から発信者生活圏テーブル１３を検索し、その検索結果である生活圏ＣＡコード（42200＝武蔵野市）を制御部１８に応答する。
Ｓ２１５は、着信先確認処理である。制御部１８は、着信先特定用テーブル１１（着信検索部１２）に対して、Ｓ２１４で得たfrom:を含むクエリ（who:080-2552-xxxx／from:42200＝武蔵野市／to:0120-xxxx）を通知し、そのクエリに合致する接続先の着信番号を要求する。なお、（who:080-2552-xxxx）は今回の検索で使用しないので、クエリから省略してもよい。
Ｓ２１６は、着信先応答処理である。着信検索部１２は、Ｓ２１５のto:0120-xxxxを着信先特定用テーブル１１の着信代表番号から検索し、Ｓ２１５のfrom:42200＝武蔵野市を着信先特定用テーブル１１の接続先ＣＡコード＆ＣＡ名から検索し、双方の検索条件に同時に一致するレコードの接続先の着信番号（0422-59-xxxx）を着信先として取得し、その着信先（to:0422-59-xxxx）を制御部１８に応答する。
Ｓ２１６は、着信先応答処理である。着信検索部１２は、Ｓ２１５のto:0120-xxxxを着信先特定用テーブル１１の着信代表番号から検索し、Ｓ２１５のfrom:42200＝武蔵野市を着信先特定用テーブル１１の接続先ＣＡコード＆ＣＡ名から検索し、双方の検索条件に同時に一致するレコードの接続先の着信番号（0422-59-xxxx）を着信先として取得し、その着信先（to:0422-59-xxxx）を制御部１８に応答する。
Ｓ２２１は、発信要求処理である。制御部１８は、Ｓ２０２への応答として、呼信号処理部１９ａに対して、呼制御信号（who:080-2552-xxxx／from:京都／to:0422-59-xxxx）を発信要求する。ここで、Ｓ２０２のto:が生活圏を考慮したＳ２１６の着信先（to:0422-59-xxxx）へと変換されている。
Ｓ２２２は、発信転送処理である。呼信号処理部１９ａは、Ｓ２２１の呼制御信号の（to:0422-59-xxxx）を着番号とし、（who:＝080-2552-xxxx）を発番号とした発呼を着番号のオペレータ端末３に発信転送する。
Ｓ２２３で、Ｓ２０１の発呼とＳ２２２の着呼とが接続されることで、ユーザ端末２とオペレータ端末３とが通話可能となる。
Ｓ２２２は、発信転送処理である。呼信号処理部１９ａは、Ｓ２２１の呼制御信号の（to:0422-59-xxxx）を着番号とし、（who:＝080-2552-xxxx）を発番号とした発呼を着番号のオペレータ端末３に発信転送する。
Ｓ２２３で、Ｓ２０１の発呼とＳ２２２の着呼とが接続されることで、ユーザ端末２とオペレータ端末３とが通話可能となる。
図７は、発信地域指定システムの呼接続処理の第２例を示すシーケンス図である。この第２例では、着信ＵＲＬあてのweb発信について、ユーザの生活圏（武蔵野市）をユーザ端末２の発信地域とみなすことを特徴とする。
Ｓ３０１は、web発信処理である。ユーザ端末２は、web発信時に自身の現位置情報を取得し、ＨＴＴＰ（HyperText Transfer Protocol）などのセッション制御信号（who:3533xxxxxxxxxxx／from:京都／to:http://www.kosetsuzoku.seikatsuken.jp）に含めてから呼信号処理部１９ａに送信（電話発信）する。なお、セッション制御信号に含まれる各データは、次の通りである。
・who:3533xxxxxxxxxxx（図では「3533xxx」と略）は、ＩＭＥＩなどの発信者ＩＤである。
・from:京都は、ユーザ端末２の現位置情報（緯度・経度）である。
・to:http://www.kosetsuzoku.seikatsuken.jp（図では「〜seikatsu〜」と略）は、WebサーバのドメインＵＲＬなどのサーバ運営者情報である。このWebサーバが、from:の現位置情報の取得をユーザ端末２に要求する。
Ｓ３０１は、web発信処理である。ユーザ端末２は、web発信時に自身の現位置情報を取得し、ＨＴＴＰ（HyperText Transfer Protocol）などのセッション制御信号（who:3533xxxxxxxxxxx／from:京都／to:http://www.kosetsuzoku.seikatsuken.jp）に含めてから呼信号処理部１９ａに送信（電話発信）する。なお、セッション制御信号に含まれる各データは、次の通りである。
・who:3533xxxxxxxxxxx（図では「3533xxx」と略）は、ＩＭＥＩなどの発信者ＩＤである。
・from:京都は、ユーザ端末２の現位置情報（緯度・経度）である。
・to:http://www.kosetsuzoku.seikatsuken.jp（図では「〜seikatsu〜」と略）は、WebサーバのドメインＵＲＬなどのサーバ運営者情報である。このWebサーバが、from:の現位置情報の取得をユーザ端末２に要求する。
Ｓ３０２は、発信通知処理である。
呼信号処理部１９ａは、Ｓ３０１のセッション制御信号（who:3533xxxxxxxxxxx／from:京都／to:http://www.kosetsuzoku.seikatsuken.jp）をそのまま制御部１８に通知（自動的にルーチング）する。
Ｓ３１１は、生活圏確認処理である。制御部１８は、着信先特定用テーブル１１（着信検索部１２）に対して、Ｓ３０２のセッション制御信号に含まれる（to:http://www.kosetsuzoku.seikatsuken.jp）を検索キーとして、その生活圏フラグが○か×かを確認させる。
Ｓ３１２は、確認応答処理である。今回は、図３（ｂ）で示したとおり生活圏フラグが○であるので、着信検索部１２は、その旨を制御部１８に応答する。
呼信号処理部１９ａは、Ｓ３０１のセッション制御信号（who:3533xxxxxxxxxxx／from:京都／to:http://www.kosetsuzoku.seikatsuken.jp）をそのまま制御部１８に通知（自動的にルーチング）する。
Ｓ３１１は、生活圏確認処理である。制御部１８は、着信先特定用テーブル１１（着信検索部１２）に対して、Ｓ３０２のセッション制御信号に含まれる（to:http://www.kosetsuzoku.seikatsuken.jp）を検索キーとして、その生活圏フラグが○か×かを確認させる。
Ｓ３１２は、確認応答処理である。今回は、図３（ｂ）で示したとおり生活圏フラグが○であるので、着信検索部１２は、その旨を制御部１８に応答する。
Ｓ３１３は、生活圏要求処理である。制御部１８は、発信者生活圏テーブル１３（発信検索部１４）に対して、Ｓ３０２のセッション制御信号に含まれる各データを含むクエリ（who:3533xxxxxxxxxxx／from:京都／to:http://www.kosetsuzoku.seikatsuken.jp）を通知し、そのクエリに合致する生活圏情報を要求する。なお、生活圏情報はユーザ（who:）に対応づけられているので、その他の情報（from:とto:）はクエリから省略してもよい。
Ｓ３１４は、生活圏応答処理である。発信検索部１４は、Ｓ３１３のクエリの（who:3533xxxxxxxxxxx）から発信者生活圏テーブル１３を検索し、その検索結果である生活圏ＣＡコード（42200＝武蔵野市）と、対応する発信端末番号（who:080-2552-xxxx）とを制御部１８に応答する。
Ｓ３１４は、生活圏応答処理である。発信検索部１４は、Ｓ３１３のクエリの（who:3533xxxxxxxxxxx）から発信者生活圏テーブル１３を検索し、その検索結果である生活圏ＣＡコード（42200＝武蔵野市）と、対応する発信端末番号（who:080-2552-xxxx）とを制御部１８に応答する。
Ｓ３１５は、着信先確認処理である。制御部１８は、着信先特定用テーブル１１（着信検索部１２）に対して、Ｓ３１４で得たwho:とfrom:とを含むクエリ（who:080-2552-xxxx／from:42200＝武蔵野市／to:http://www.kosetsuzoku.seikatsuken.jp）を通知し、そのクエリに合致する接続先の着信番号を要求する。なお、（who:080-2552-xxxx）は今回の検索で使用しないので、クエリから省略してもよい。
Ｓ３１６は、着信先応答処理である。着信検索部１２は、Ｓ３１５のto:http://www.kosetsuzoku.seikatsuken.jpを着信先特定用テーブル１１の着信ＵＲＬから検索し、Ｓ３１５のfrom:42200＝武蔵野市を着信先特定用テーブル１１の接続先ＣＡコード＆ＣＡ名から検索し、双方の検索条件に同時に一致するレコードの接続先の着信番号（0422-59-xxxx）を着信先として取得し、その着信先（to:0422-59-xxxx）を制御部１８に応答する。
Ｓ３１６は、着信先応答処理である。着信検索部１２は、Ｓ３１５のto:http://www.kosetsuzoku.seikatsuken.jpを着信先特定用テーブル１１の着信ＵＲＬから検索し、Ｓ３１５のfrom:42200＝武蔵野市を着信先特定用テーブル１１の接続先ＣＡコード＆ＣＡ名から検索し、双方の検索条件に同時に一致するレコードの接続先の着信番号（0422-59-xxxx）を着信先として取得し、その着信先（to:0422-59-xxxx）を制御部１８に応答する。
Ｓ３２１は、発信要求処理である。制御部１８は、Ｓ３０２への応答として、呼信号処理部１９ａに対して、呼制御信号（who:080-2552-xxxx／from:京都／to:0422-59-xxxx）を発信要求する。ここで、Ｓ３０２のto:が生活圏を考慮したＳ３１６の着信先（to:0422-59-xxxx）へと変換されている。
Ｓ３２２は、発信転送処理である。呼信号処理部１９ａは、Ｓ３２１の呼制御信号の（to:0422-59-xxxx）を着番号とし、（who:＝080-2552-xxxx）を発番号とした発呼を着番号のオペレータ端末３に発信転送する。さらに、呼信号処理部１９ａは、Ｓ３２２ｂにおいて、Ｓ３０１のweb発信をしたユーザ端末２に対しても、Ｓ３２２の発呼（発番号と着番号を入れ替えたもの）を発信転送する。つまり、呼信号処理部１９ａは、3rd party callとして、ユーザ端末２とオペレータ端末３との接続を仲介する。
Ｓ３２３で、Ｓ３２２、Ｓ３２２ｂの呼が接続されることで、ユーザ端末２とオペレータ端末３とが通話可能となる。
Ｓ３２２は、発信転送処理である。呼信号処理部１９ａは、Ｓ３２１の呼制御信号の（to:0422-59-xxxx）を着番号とし、（who:＝080-2552-xxxx）を発番号とした発呼を着番号のオペレータ端末３に発信転送する。さらに、呼信号処理部１９ａは、Ｓ３２２ｂにおいて、Ｓ３０１のweb発信をしたユーザ端末２に対しても、Ｓ３２２の発呼（発番号と着番号を入れ替えたもの）を発信転送する。つまり、呼信号処理部１９ａは、3rd party callとして、ユーザ端末２とオペレータ端末３との接続を仲介する。
Ｓ３２３で、Ｓ３２２、Ｓ３２２ｂの呼が接続されることで、ユーザ端末２とオペレータ端末３とが通話可能となる。
図８は、発信地域指定システムの呼接続処理の第３例を示すシーケンス図である。この第３例では、着信ＵＲＬあてのweb発信について、ユーザの現在地（京都）をユーザ端末２の発信地域とみなすことを特徴とする。
Ｓ４０１は、web発信処理である。ユーザ端末２は、web発信時に自身の現位置情報を取得し、ＨＴＴＰなどのセッション制御信号（who:3533xxxxxxxxxxx／from:京都／to:http://www.kosetsuzoku.notseikatsuken.jp）に含めてから呼信号処理部１９ａに送信（電話発信）する。なお、セッション制御信号に含まれる各データは、次の通りである。
・who:3533xxxxxxxxxxx（図では「3533xxx」と略）は、ＩＭＥＩなどの発信者ＩＤである。
・from:京都は、ユーザ端末２の現位置情報（緯度・経度）である。
・to:http://www.kosetsuzoku.notseikatsuken.jp（図では「〜notseikatsu〜」と略）は、WebサーバのドメインＵＲＬなどのサーバ運営者情報である。このWebサーバが、from:の現位置情報の取得をユーザ端末２に要求する。
Ｓ４０１は、web発信処理である。ユーザ端末２は、web発信時に自身の現位置情報を取得し、ＨＴＴＰなどのセッション制御信号（who:3533xxxxxxxxxxx／from:京都／to:http://www.kosetsuzoku.notseikatsuken.jp）に含めてから呼信号処理部１９ａに送信（電話発信）する。なお、セッション制御信号に含まれる各データは、次の通りである。
・who:3533xxxxxxxxxxx（図では「3533xxx」と略）は、ＩＭＥＩなどの発信者ＩＤである。
・from:京都は、ユーザ端末２の現位置情報（緯度・経度）である。
・to:http://www.kosetsuzoku.notseikatsuken.jp（図では「〜notseikatsu〜」と略）は、WebサーバのドメインＵＲＬなどのサーバ運営者情報である。このWebサーバが、from:の現位置情報の取得をユーザ端末２に要求する。
Ｓ４０２は、発信通知処理である。
呼信号処理部１９ａは、Ｓ４０１のセッション制御信号（who:3533xxxxxxxxxxx／from:京都／to:http://www.kosetsuzoku.notseikatsuken.jp）をそのまま制御部１８に通知（自動的にルーチング）する。
Ｓ４１１は、生活圏確認処理である。制御部１８は、着信先特定用テーブル１１（着信検索部１２）に対して、Ｓ４０２のセッション制御信号に含まれる（to:http://www.kosetsuzoku.notseikatsuken.jp）を検索キーとして、その生活圏フラグが○か×かを確認させる。
Ｓ４１２は、確認応答処理である。今回は、図３（ｂ）で示したとおり生活圏フラグが×であるので、着信検索部１２は、その旨を制御部１８に応答する。
呼信号処理部１９ａは、Ｓ４０１のセッション制御信号（who:3533xxxxxxxxxxx／from:京都／to:http://www.kosetsuzoku.notseikatsuken.jp）をそのまま制御部１８に通知（自動的にルーチング）する。
Ｓ４１１は、生活圏確認処理である。制御部１８は、着信先特定用テーブル１１（着信検索部１２）に対して、Ｓ４０２のセッション制御信号に含まれる（to:http://www.kosetsuzoku.notseikatsuken.jp）を検索キーとして、その生活圏フラグが○か×かを確認させる。
Ｓ４１２は、確認応答処理である。今回は、図３（ｂ）で示したとおり生活圏フラグが×であるので、着信検索部１２は、その旨を制御部１８に応答する。
Ｓ４１３は、発信端末番号の要求処理である。制御部１８は、発信者生活圏テーブル１３（発信検索部１４）に対して、Ｓ４０２のセッション制御信号に含まれる各データを含むクエリ（who:3533xxxxxxxxxxx／from:京都／to:http://www.kosetsuzoku.notseikatsuken.jp）を通知し、そのクエリに合致する生活圏情報を要求する。なお、発信端末番号はユーザ（who:）に対応づけられているので、その他の情報（from:とto:）はクエリから省略してもよい。
Ｓ４１４は、発信端末番号の応答処理である。発信検索部１４は、Ｓ４１３のクエリの（who:3533xxxxxxxxxxx）から発信者生活圏テーブル１３を検索し、その検索結果である発信端末番号（who:080-2552-xxxx）を制御部１８に応答する。
Ｓ４１４は、発信端末番号の応答処理である。発信検索部１４は、Ｓ４１３のクエリの（who:3533xxxxxxxxxxx）から発信者生活圏テーブル１３を検索し、その検索結果である発信端末番号（who:080-2552-xxxx）を制御部１８に応答する。
ここで、制御部１８は、ユーザ端末２の現位置情報である（from:京都）のデータ形式を緯度経度情報からＣＡコードへ変換する旨の計算を行う（Ｓ４１５ａ）。この変換処理は、Ｓ１１６で説明したとおり、方形区画番号算出部１７、ＣＡ検索部１６によって行われる。
Ｓ４１５は、着信先確認処理である。制御部１８は、着信先特定用テーブル１１（着信検索部１２）に対して、Ｓ４１４で得たwho:とＳ４１５ａで計算されたfrom:とを含むクエリ（who:080-2552-xxxx／from:58000＝京都／to:http://www.kosetsuzoku.notseikatsuken.jp）を通知し、そのクエリに合致する接続先の着信番号を要求する。なお、（who:080-2552-xxxx）は今回の検索で使用しないので、クエリから省略してもよい。
Ｓ４１６は、着信先応答処理である。着信検索部１２は、Ｓ４１５のto:http://www.kosetsuzoku.notseikatsuken.jpを着信先特定用テーブル１１の着信ＵＲＬから検索し、Ｓ４１５のfrom:58000＝京都を着信先特定用テーブル１１の接続先ＣＡコード＆ＣＡ名から検索し、双方の検索条件に同時に一致するレコードの接続先の着信番号（075-200-xxxx）を着信先として取得し、その着信先（to:075-200-xxxx）を制御部１８に応答する。
Ｓ４１６は、着信先応答処理である。着信検索部１２は、Ｓ４１５のto:http://www.kosetsuzoku.notseikatsuken.jpを着信先特定用テーブル１１の着信ＵＲＬから検索し、Ｓ４１５のfrom:58000＝京都を着信先特定用テーブル１１の接続先ＣＡコード＆ＣＡ名から検索し、双方の検索条件に同時に一致するレコードの接続先の着信番号（075-200-xxxx）を着信先として取得し、その着信先（to:075-200-xxxx）を制御部１８に応答する。
Ｓ４２１は、発信要求処理である。制御部１８は、Ｓ４０２への応答として、呼信号処理部１９ａに対して、呼制御信号（who:080-2552-xxxx／from:京都／to:075-200-xxxx）を発信要求する。ここで、Ｓ４０２のto:が現在地を考慮したＳ４１６の着信先（to:075-200-xxxx）へと変換されている。
Ｓ４２２は、発信転送処理である。呼信号処理部１９ａは、Ｓ４２１の呼制御信号の（to:075-200-xxxx）を着番号とし、（who:＝080-2552-xxxx）を発番号とした発呼を着番号のオペレータ端末３に発信転送する。さらに、呼信号処理部１９ａは、Ｓ４２２ｂにおいて、Ｓ４０１のweb発信をしたユーザ端末２に対しても、Ｓ４２２の発呼（発番号と着番号を入れ替えたもの）を発信転送する。つまり、呼信号処理部１９ａは、3rd party callとして、ユーザ端末２とオペレータ端末３との接続を仲介する。
Ｓ４２３で、Ｓ４２２、Ｓ４２２ｂの呼が接続されることで、ユーザ端末２とオペレータ端末３とが通話可能となる。
Ｓ４２２は、発信転送処理である。呼信号処理部１９ａは、Ｓ４２１の呼制御信号の（to:075-200-xxxx）を着番号とし、（who:＝080-2552-xxxx）を発番号とした発呼を着番号のオペレータ端末３に発信転送する。さらに、呼信号処理部１９ａは、Ｓ４２２ｂにおいて、Ｓ４０１のweb発信をしたユーザ端末２に対しても、Ｓ４２２の発呼（発番号と着番号を入れ替えたもの）を発信転送する。つまり、呼信号処理部１９ａは、3rd party callとして、ユーザ端末２とオペレータ端末３との接続を仲介する。
Ｓ４２３で、Ｓ４２２、Ｓ４２２ｂの呼が接続されることで、ユーザ端末２とオペレータ端末３とが通話可能となる。
以上、図６〜図８を参照して、発信地域指定システムの呼接続処理を説明した。
なお、図７、図８のweb発信処理（Ｓ３０１，Ｓ４０１）のセッション制御信号に含めるwho:として、発信者ＩＤ（3533xxxxxxxxxxx）の代わりに、発信端末番号（080-2552-xxxx）を用いてもよい。そのときには、発信検索部１４は、発信者ＩＤ（3533xxxxxxxxxxx）から発信端末番号（080-2552-xxxx）を求めなくてもよいので、図７ではＳ３１４で発信端末番号（080-2552-xxxx）を応答に含める処理を省略でき、図８ではＳ４１３，Ｓ４１４の処理を省略できる。
なお、図７、図８のweb発信処理（Ｓ３０１，Ｓ４０１）のセッション制御信号に含めるwho:として、発信者ＩＤ（3533xxxxxxxxxxx）の代わりに、発信端末番号（080-2552-xxxx）を用いてもよい。そのときには、発信検索部１４は、発信者ＩＤ（3533xxxxxxxxxxx）から発信端末番号（080-2552-xxxx）を求めなくてもよいので、図７ではＳ３１４で発信端末番号（080-2552-xxxx）を応答に含める処理を省略でき、図８ではＳ４１３，Ｓ４１４の処理を省略できる。
また、図６〜図８の各発信処理（Ｓ２０１，Ｓ３０１，Ｓ４０１）の各信号に含めるwho:について、ユーザ端末２が社内供用電話であるなど、ユーザ端末２の契約者（所有者）から、今回の発呼したユーザが一意に特定できない場合もある。その場合には、発呼時に発信地域指定サーバ１からガイダンスで発呼するユーザの発信者ＩＤ（APIKeyなど）の入力を促し、入力された発信者ＩＤを各発信信号に含めるwho:として用いてもよい。
そのとき、今回入力された発信者ＩＤに対する生活圏情報が発信者生活圏テーブル１３に未登録であるときには、図４のＳ１１１〜Ｓ１１８内の処理を再度実行し、外部ＤＢ２ｃなどから新たに生活圏情報を取得して、発信者生活圏テーブル１３に登録してもよい。
そのとき、今回入力された発信者ＩＤに対する生活圏情報が発信者生活圏テーブル１３に未登録であるときには、図４のＳ１１１〜Ｓ１１８内の処理を再度実行し、外部ＤＢ２ｃなどから新たに生活圏情報を取得して、発信者生活圏テーブル１３に登録してもよい。
以上説明した本実施形態の発信地域指定システムは、移動通信端末機（ユーザ端末２）を所有するユーザの現在地情報に基づいて拠点（オペレータ端末３）に着信させるシステムである。ここで、発信地域指定サーバ１は、ユーザ端末２の生活圏情報を取得し、発信者生活圏テーブル１３にて管理する。そして、発呼時には、発信地域指定サーバ１は、発信者生活圏テーブル１３から読み込んだ生活圏の近傍に位置する適切な拠点（オペレータ端末３）に着信させる（図２参照）。生活圏とは、生活拠点であり、生活上適切な地域とも言える。
なお、発信者生活圏テーブル１３には、生活圏情報と対応づけてユーザの特定情報がＩＭＥＩなどの形式で格納される。そして、ユーザ端末２は、登録時と発呼時とで同じ（または対応可能な）ユーザの特定情報を用いることで、発呼信号のユーザを特定できる。ユーザの特定情報は、Ｗｅｂページなどからのアクセス信号においてＨＴＴＰベースのプロトコル内に記載可能である。
これにより、ユーザ端末２のユーザは、遠方の地域にいながらも、自身の生活拠点に紐づいた電話応対などのサービスを受けることが可能となる。また、電話応対を主な業務とする事業者としても、顧客の生活圏に即した迅速な対応が可能となり、顧客満足度向上にもつながる。
１ 発信地域指定サーバ
２ ユーザ端末
２ｃ 外部ＤＢ
３ オペレータ端末
１１ 着信先特定用テーブル（着信先特定用データ）
１２ 着信検索部
１３ 発信者生活圏テーブル（生活圏特定用データ）
１４ 発信検索部
１５ ＣＡ特定用テーブル
１６ ＣＡ検索部
１７ 方形区画番号算出部
１８ 制御部
１９ａ 呼信号処理部
１９ｂ 通信部
１９ｃ ＮＴＰサーバ
２１ 呼制御部
２２ メディア処理部
２３ マイク
２４ カメラ
２５ 通信部
２６ 電話帳
２７ ブラウザ
２９ 位置情報取得部
２９ａ ＧＰＳ
２９ｂ Ａ−ＧＰＳ
２９ｃ 無線通信部
２ ユーザ端末
２ｃ 外部ＤＢ
３ オペレータ端末
１１ 着信先特定用テーブル（着信先特定用データ）
１２ 着信検索部
１３ 発信者生活圏テーブル（生活圏特定用データ）
１４ 発信検索部
１５ ＣＡ特定用テーブル
１６ ＣＡ検索部
１７ 方形区画番号算出部
１８ 制御部
１９ａ 呼信号処理部
１９ｂ 通信部
１９ｃ ＮＴＰサーバ
２１ 呼制御部
２２ メディア処理部
２３ マイク
２４ カメラ
２５ 通信部
２６ 電話帳
２７ ブラウザ
２９ 位置情報取得部
２９ａ ＧＰＳ
２９ｂ Ａ−ＧＰＳ
２９ｃ 無線通信部
Claims (6)
- 着信代表ＩＤごとに、その着信代表ＩＤあての呼制御信号の発信地域として、生活圏を優先させるか否かを示す生活圏フラグと、発信地域ごとの着信番号とを対応づける着信先特定用データと、
発信者ＩＤごとに、その発信者の生活圏情報を対応づける生活圏特定用データと、がそれぞれ格納されている記憶手段と、
前記呼制御信号の通知を受け、その呼制御信号の着番号である前記着信代表ＩＤをもとに、前記着信先特定用データから対応する前記生活圏フラグを読み込み、
前記生活圏フラグが生活圏を優先させる旨であるときには、前記呼制御信号に付されている前記発信者ＩＤをもとに、前記生活圏特定用データから対応する前記生活圏情報を読み取り、その読み取った生活圏情報と前記着信代表ＩＤとの組み合わせをもとに、前記着信先特定用データから対応する着信番号を特定し、
前記生活圏フラグが生活圏を優先させない旨であるときには、前記呼制御信号に付されている発信端末の現在位置と前記着信代表ＩＤとの組み合わせをもとに、前記着信先特定用データから対応する着信番号を特定し、
前記通知された前記呼制御信号の着番号を前記着信代表ＩＤから前記特定した着信番号へと置き換えてから、前記特定した着信番号に向けて前記呼制御信号を転送する制御部とを有することを特徴とする
発信地域指定サーバ。 - 前記生活圏特定用データには、前記発信者ＩＤごとに、その発信者の生活圏情報に加えて、その発信端末番号が対応づけられており、
前記制御部は、前記生活圏フラグが生活圏を優先させる旨であるときには、前記呼制御信号に付されている前記発信者ＩＤをもとに、前記生活圏特定用データから対応する前記生活圏情報に加えて、対応する前記発信端末番号を読み取り、
前記呼制御信号を転送するときに、前記読み取った発信端末番号を発番号とすることを特徴とする
請求項１に記載の発信地域指定サーバ。 - 前記制御部は、前記発信端末の契約時に入力される前記発信者ＩＤと、その発信者の生活圏情報との対応情報を受け付け、その受け付けた対応情報を前記生活圏特定用データに登録することを特徴とする
請求項１または請求項２に記載の発信地域指定サーバ。 - 請求項１または請求項２に記載の発信地域指定サーバと、前記発信端末とを含めて構成され、
前記発信端末は、自身の位置測定手段により測定した位置情報を、前記生活圏特定用データに登録することを特徴とする
発信地域指定システム。 - 請求項１または請求項２に記載の発信地域指定サーバと、外部データベースシステムとを含めて構成され、
前記外部データベースシステムは、前記発信端末から書き込まれる位置情報を、前記生活圏特定用データに登録することを特徴とする
発信地域指定システム。 - 発信地域指定サーバは、記憶手段と、制御部とを有しており、
前記記憶手段には、
着信代表ＩＤごとに、その着信代表ＩＤあての呼制御信号の発信地域として、生活圏を優先させるか否かを示す生活圏フラグと、発信地域ごとの着信番号とを対応づける着信先特定用データと、
発信者ＩＤごとに、その発信者の生活圏情報を対応づける生活圏特定用データと、がそれぞれ格納されており、
前記制御部は、
前記呼制御信号の通知を受け、その呼制御信号の着番号である前記着信代表ＩＤをもとに、前記着信先特定用データから対応する前記生活圏フラグを読み込み、
前記生活圏フラグが生活圏を優先させる旨であるときには、前記呼制御信号に付されている前記発信者ＩＤをもとに、前記生活圏特定用データから対応する前記生活圏情報を読み取り、その読み取った生活圏情報と前記着信代表ＩＤとの組み合わせをもとに、前記着信先特定用データから対応する着信番号を特定し、
前記生活圏フラグが生活圏を優先させない旨であるときには、前記呼制御信号に付されている発信端末の現在位置と前記着信代表ＩＤとの組み合わせをもとに、前記着信先特定用データから対応する着信番号を特定し、
前記通知された前記呼制御信号の着番号を前記着信代表ＩＤから前記特定した着信番号へと置き換えてから、前記特定した着信番号に向けて前記呼制御信号を転送することを特徴とする
発信地域指定方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015027755A JP2016152446A (ja) | 2015-02-16 | 2015-02-16 | 発信地域指定サーバ、発信地域指定システム、および、発信地域指定方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015027755A JP2016152446A (ja) | 2015-02-16 | 2015-02-16 | 発信地域指定サーバ、発信地域指定システム、および、発信地域指定方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2016152446A true JP2016152446A (ja) | 2016-08-22 |
Family
ID=56695541
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015027755A Pending JP2016152446A (ja) | 2015-02-16 | 2015-02-16 | 発信地域指定サーバ、発信地域指定システム、および、発信地域指定方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2016152446A (ja) |
-
2015
- 2015-02-16 JP JP2015027755A patent/JP2016152446A/ja active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20160309026A1 (en) | Virtual identifier for emergency call handling | |
| JP2013179507A (ja) | プッシュ配信装置、携帯端末、プッシュ配信方法およびプッシュ配信システム | |
| KR20200143194A (ko) | 상담 전화 연결 시스템 및 방법 | |
| US9307077B2 (en) | Communication system | |
| JP6418629B2 (ja) | 遠隔会議システム、遠隔会議装置、遠隔会議方法及びプログラム | |
| JP2013207320A (ja) | 電話システムおよびプログラム | |
| JP6599833B2 (ja) | Ｓｍｓ配信装置及びｓｍｓ配信方法 | |
| JP2016152446A (ja) | 発信地域指定サーバ、発信地域指定システム、および、発信地域指定方法 | |
| JP5853544B2 (ja) | サーバ装置、プログラム及び通信システム | |
| JP2002159063A (ja) | 携帯端末の位置情報提供許諾方法 | |
| JP5813056B2 (ja) | サーバ装置、その制御方法、及びその制御プログラム | |
| WO2008053836A1 (fr) | Procédé de contrôle de communication, système de communication, contrôleur de communication, terminal de communication et programme | |
| KR101116009B1 (ko) | 위치정보를 호신호로 접속하는 통신방법 | |
| JP2009130482A (ja) | 緊急通報時の位置情報転送システム | |
| JP5660744B2 (ja) | 携帯端末、配信システム、配信方法およびプログラム | |
| JP5705346B2 (ja) | 配信装置、配信方法、配信システムおよびプログラム | |
| US20170105092A1 (en) | Application and a method for two-way communication between participating smartphones, of each other's real-time geographic location information, during a phone call. | |
| KR20150003949A (ko) | 사용자 상황 기반 통화 연결음 광고 제공 시스템 및 방법 | |
| US20130148540A1 (en) | Method and apparatus for call set-up based on network available to receiver | |
| JP5873314B2 (ja) | 通信装置、通信システム、及び通信方法 | |
| JP2002315053A (ja) | 移動通信システムおよび移動通信端末ならびにメッセージ転送方法および自動通信方法 | |
| JP2015192185A (ja) | 呼接続方法および呼接続システム | |
| KR20120025911A (ko) | 발신자 정보 제공 시스템 및 방법 | |
| JP5926360B2 (ja) | スケジューリング制御装置およびスケジューリング制御プログラム | |
| JP4810161B2 (ja) | 分離課金通信システム |