JP5006449B2 - ゾーン関連の呼を完了させるための方法及びシステム - Google Patents

Description

本発明は、一般的に、携帯及び固定端末、無線ネットワーク基盤、ネットワークノード並びに陸上（land based）トランスポートネットワークを含む通信システム内での、上記無線ネットワーク基盤の１つ以上のセルを含むように定義された１つ以上のゾーンを有する携帯端末の相手への呼の完了（completion）に関する。

より具体的には、本発明は、呼び出された携帯端末がそのゾーン内に存在しない場合における発呼者（calling party）の選択可能な呼の完了のための方法及びシステムを促進する。

最新の技術水準の通信システムは、ホーム又はオフィスゾーンの概念を以前から知っている。ここで、その現在位置が事前に定義されたゾーン（実際にはＨＰＬＭＮの１つ以上のセル）の内側にある携帯電話は、そういったゾーンの外側にあるときとは違った扱いを受ける。通常、ゾーンの内側において電話をかける場合、料金はより低くなる。これは、固定ネットワークにおける市内電話と似ている。そういった携帯電話が呼び出される場合、関連する呼の完了は、着呼者（called party）がそのゾーン内にいる場合は単に接続、又はゾーンの外側にいる場合はボイスメールに接続することから成る。より高度なものになると、より高い料金レートを伴う“とにかく接続”というオプションを選択する自由を発呼者に与える。図１は、最新の技術水準のシステムの概観を示す。

携帯電話についての着呼Ａは、当該携帯電話のＨＰＬＭＮ（Home Public Land mobile network）におけるＭＳＣ（Mobile services Switching Centre）に達する。上記携帯電話がＨＰＬＭＮとは別のＰＬＭＮ内にある場合、このＭＳＣは終端ＭＳＣ（Ｔ−ＭＳＣ）と区別するため、その意味によりＧ−ＭＳＣ（ゲートウェイＭＳＣ）としても知られる。ＭＳＣの最初の動作は、ＨＬＲ（Home location Register）へのインタフェース４を介してＨＬＲに記憶された加入者データを取得することである。加入者データにおけるセットパラメータＴ−ＳＣＩ（terminating CAMEL subscription information）に基づいて、又は番号解析においてゾーン関連の携帯番号を検出することにより、ＭＳＣは、ＣＡＰ−ＩＤＰメッセージ（CAMEL Application Part−Initial Detection Point）を用いてＳＣＰ（Service Control Point）におけるゾーンアプリケーションＣを呼び出す。ゾーンアプリケーションは、上記携帯電話の位置をチェックする。そのためそれは、インタフェース３を介してＨＬＲへＭＡＰ−ＡＴＩ（Mobile Application Part−Any Time Interrogation）を行うことができる。これにより、特に最後に記憶された上記携帯電話の位置が提供されるであろう。一方、詳細な位置情報は、ＨＬＲにおいて定期的に更新されない。ＨＬＲの記憶した位置は、日時（age）が判定され得るようタイムスタンプが付される。ＭＡＰ−ＡＴＩの代わりに、ゾーンアプリケーションはインタフェース３を介してＭＡＰ−ＡＬＲ（Mobile Application Part−Active Location Request）をＨＬＲへ送信し得る。ここでＨＬＲは、インタフェース４を介してＴ−ＭＳＣへ位置要求を行う。Ｔ−ＭＳＣは、インタフェース４を介して位置レポートを伴って応答する。図１において上記携帯電話はＨＰＬＭＮ内に存在し、そのためＧ−ＭＳＣとＴ−ＭＳＣが同じである状況が示されている。位置レポートはタイムスタンプと共にＨＬＲに記憶され、次のＭＡＰ−ＡＴＩによりアクセスされ得る。ゾーンアプリケーションがＭＡＰ−ＡＬＲを行ったように、ＨＬＲはインタフェース３を介してゾーンアプリケーションへ位置レポートを提供する。

レポートにおける位置情報は、次のいくつかの要素を含む；
ＭＣＣ−Mobile Country Code（携帯が現在ある国）、
ＭＮＣ−Mobile Network Code（携帯にサービス提供しているＰＬＭＮ）、
ＬＡＣ−Location Area Code（ＰＬＭＮはＬＡに分割される）、
ＣＩ−Cell Identifier（携帯が滞在しているＧＳＭのセル）、
ＳＡＩ−Service Area Identifier（携帯にサービス提供しているＵＭＴＳのノードＢ）、
ＬＡＴ／ＬＯＮＧ位置及び当該位置における不確かさ、
携帯の速度。

要素ＭＣＣ、ＭＮＣ、及びＬＡＣは標準であり常に提供される。ＣＩは、ＧＳＭ電話についてのみ与えられ、ＳＡＩはＵＭＴＳ電話についてのみ与えられる。ＬＡＴ／ＬＯＮＧ位置及び速度はＭＳＣにおける設定に依存しており、ブロックされる、自由である、又はオペレータのネットワークノードについてのみ利用可能であり得る。ＬＡＴ／ＬＯＮＧ位置についての詳細は、３ＧＰＰの技術仕様２３．０３２において見つけることができる。速度は、ＭＳＣにおいて速度の測定が実行される場合にのみ利用可能である。

ネットワークがＭＰＳ（Mobile Positioning System）を備えている場合、ＨＬＲの代わりにＭＰＳからＭＡＰインタフェースを介してＭＬＰプロトコルを使用して高度位置レポートを取得することも可能である。その出力はＨＬＲにより提供されるものと似ている。

ゾーンは、１つ以上のセル（ＧＳＭ）又はサービスエリア（ＵＭＴＳ）として定義される。デフォルトでは、それらは全てＨＰＬＭＮ内に位置している。それらはＨＰＬＭＮの境界線上又はＨＰＬＭＮの内側の他のどこにでも存在してよい。定義されたゾーンは、２つの隣接するロケーションエリアの境界線をまたがって位置してもよい。

ゾーンアプリケーションは、ＭＣＣ、ＭＮＣ及びＣＧＩ／ＳＡＩの値を用いてゾーンを形成する定義されたセルと実際の位置とを比較する。携帯が上記ゾーン内にある場合、携帯Ｂへの接続がオーダされ、そうでない場合、携帯ＢのボイスメールＢ_ＶＭへの接続がオーダされる。オーダは、インタフェース２を介してＣＡＰ−ＣＯＮ（CAMEL Application Part-Connect）と共にＭＳＣへ送信される。その後ＭＳＣは、携帯Ｂ又はそのボイスメールＢ_ＶＭのいずれかへの接続を確立する。

単なる音声メールへの接続の代わりに、追加的な料金を伴うもののとにかく接続することをユーザが選択し得る、より高度なモードが知られている。この場合、まず発呼者Ａへのアナウンスメントを再生するためのオーダがＭＳＣへ与えられる。オーダＣＡＰ−ＰＡ（CAP-Play Announcement）は、（事前に記録されたメッセージの）固定メッセージ識別子、（音声に変換されることになる）テキスト文字列、又は（時間、日付、期間、もしくは値段のような、識別子と共に提供されて音声に変換される変数パラメータを含む、事前に記録されたメッセージの）変数メッセージ識別子から、又はその組合せから成る。

このアナウンスメントは、発呼者が電話機上のキーの１つを押すことによりオプションを選択できるようにユーザが選択可能なオプションを含んでもよい。

アナウンスメントを再生後、ＭＳＣはＣＡＰ−ＰＡの詳細を含むＣＡＰ−ＳＳＲ（CAP-Specialized Resource Report）を返答する。押されたキーの情報をユーザから受信するために、ゾーンアプリケーションは、ＣＡＰ−ＰＣ（CAP- Prompt and Collect user information）を送信しなければならない。ＣＡＰ−ＰＣは、求められている数字、タイムアウトの値などの数を含む。ＭＳＣは、上記数字が入力されている場合又はタイムアウト後、ＣＡＰ−ＰＣＲ（CAP-PC Result）を伴って応答する。

ゾーンサーバアプリケーションは、ユーザの選択に基づいて携帯Ｂ又はそのボイスメールＢ_ＶＭのいずれかへのＣＡＰ−ＣＯＮを伴って動作する。

ＣＡＰ動作についての全詳細は、ＣＡＰ技術仕様３ＧＰＰのＴＳ２９．０７８において見つけることができる。

図１は、ＳＣＰにおけるゾーンサーバアプリケーションに基づく実装を示しているが、ＭＳＣに対してＳＣＰとして動作する専用ゾーンサーバノードのような様々な他のやり方でそれは実装され得る。

ゾーンのエリアは一般的に、ＨＰＬＭＮの全エリアと比較するとかなり小さい。そのため発呼者に提供される情報は、次に限定される；着呼者がＶＰＬＭＮ内にいる、ＨＰＬＭＮ内にいる、又はその定義されたゾーンの１つにいる。ゾーンが２つのロケーションエリアの境界線をまたがって位置する場合、ゾーンは１つより多くのロケーションエリア内にセルを有し得るため、ロケーションエリア（ＬＡ）をプレゼンス検出のための中間エリアとしては使用できない。

本発明の目的は、着呼者の現在位置についてのより詳細な情報及び関連する呼の完了オプションのより広い選択肢を発呼者に提供することである。

公衆陸上移動体ネットワーク（Public Land Mobile Network）における１つ以上の定義されたゾーンを有し、その定義されたゾーンの１つに存在しない携帯加入者への、発呼者からの呼を完了させるための方法の現行の発明を伴って解決策が提供される。上記方法は；上記ゾーンサーバにより、ゾーン（α）より大きく、半径（ε）と上記ゾーン（α）のゾーン地理的中心座標（δ）とを有する、上記ゾーン（α）の周囲の円形の外周（θ）の内部において、上記携帯加入者の端末のプレゼンスを判定するステップと、ゾーンとの関連における上記携帯加入者の現在位置と、上記発呼者が上記呼を完了するためのオプションとを含むアナウンスメントを上記発呼者へ行わせるステップと、上記オプションの上記発呼者からの選択を解析し実行するステップと、を含む。

現行の発明のさらなる事例は；上記携帯加入者の上記現在位置を上記発呼者が受信することについての許可をチェックする上記主な方法についての追加的なステップと、上記携帯加入者が１つより多くの定義されたゾーンを有する場合に最も近いゾーンを判定する上記主な方法についての追加的なステップと、人がゾーンの内部にいる場合のオプションを伴うアナウンスメントも再生する選択肢と、上記現在位置を受信することについての上記許可についての親による制御と、を提供する。

携帯加入者のための少なくとも１つの定義されたゾーンと着呼トリガとを有する上記携帯加入者の位置レポートを受信するためのゾーンサーバであって、ＭＡＰインタフェースコントローラを介するホームロケーションレジスタに向けてのＭＡＰインタフェースと、ＣＡＰインタフェースコントローラを介する移動体交換局（ＭＳＣ）に向けてのＣＡＰインタフェースと、を有し、
上記ゾーンサーバは、
ゾーンベースに接続され、受信される上記位置レポートに基づいて、携帯加入者の上記少なくとも１つの定義されたゾーンの最も近いゾーンと、上記最も近いゾーンの外部及び上記最も近いゾーンの周囲の円形の外周の内部における上記携帯加入者のプレゼンスとを判定するための計算部機能と、
携帯加入者の上記少なくとも１つの定義されたゾーン及びプレゼンス、並びにプレゼンス情報を発呼者が受信することについての許可を記憶するためのゾーンベースと、
上記ゾーンベース１０５に接続され、発呼者がプレゼンスを受信すべきかをチェックし、呼を完了するためのオプションを含む上記発呼者のためのアナウンスメントを組み立て、並びに、受信された上記着呼トリガに基づいて上記発呼者から選択されたオプションを解析し及び実行するための決定機能と、
上記決定機能及びイベントベースに接続され、上記決定機能からの未来のイベントトリガを受信し、上記未来のイベントトリガを解析し、上記イベントベース内に未来のイベントを記憶し、実行すべき未来のイベントについて上記イベントベースをスキャンし、当該未来のイベントを実行するためのイベントマネージャと、
実行すべき未来のイベントを記憶するためのイベントベースと、
を特徴とする、ゾーンサーバにより、本発明の第一の実施形態が提供される。

上記第一の実施形態は、上記決定機能が、携帯加入者から上記ＣＡＰインタフェースを介して知的ネットワークサービス呼（Intelligent Network Service calls）を受信し、受信される上記知的ネットワークサービス呼に基づいて発呼者についての上記許可を判定し、上記ゾーンベース内に当該許可を記憶するために特別に適合されることをさらに特徴とする。この特徴により、上記携帯加入者は、上記ゾーンサーバへサービスコールをかけることにより、詳細なプレゼンス情報についての許可を発呼者についてオン又はオフに切り換えることが可能となる。

上記第一の実施形態はまた、上記決定機能が、携帯加入者からの許可オーダメッセージを受信するためのインターネットプロトコル接続を有し、上記許可オーダメッセージに基づいて詳細なプレゼンス情報を発呼者が受信することについての許可を更新するように特別に適合されることをさらに特徴とする。この特徴により、上記携帯加入者へ電話をかける際に詳細なプレゼンス情報を受信することとの関連において非グループの発呼者とは異なる扱いを受ける発呼者のグループを、上記携帯加入者がウェブインタフェースを用いて維持することが可能となる。

第二の実施形態は、ゾーンサーバアプリケーションとして１つ以上のネットワークノード内に設けられる、ゾーンサーバの全ての機能を実行するソフトウェアアプリケーションにより提供される。上記ゾーンサーバアプリケーションは、上記ノード内に設けられ、上記ソフトウェアアプリケーションが記憶されているキャリアから読み込まれ、又は上記ソフトウェアアプリケーションが記憶されているレポジトリから移植される。上記ゾーンサーバアプリケーションの実施形態により、ネットワークノード内に既に存在し得る上記インタフェースコントローラのようなアイテムの使用が可能となる。

最新の技術水準のシステムを表す。 本発明に係る近傍ゾーンを表す。 ゾーンサーバにおける実施形態を表す。 ゾーンサーバのテーブル及びレコードの構造を表す。 ゾーンサーバのテーブル及びレコードの構造を表す。 ゾーンサーバのテーブル及びレコードの構造を表す。 ゾーンサーバのテーブル及びレコードの構造を表す。 本発明に係る近傍ゾーンのさらなる実施形態を表す。 さらなる実施形態に必要なテーブル及びレコードの拡張を表す。 さらなる実施形態に必要なテーブル及びレコードの拡張を表す。

概説されているように、着呼者がそのゾーンの１つにいない場合に着呼者のゾーン又はゾーン群に関連する着呼者の位置についてより詳細な情報を発呼者に提供することが目的である。この情報は、呼の完了を選択するためのベースを提供するよう活用されるべきである。

図２において概説されるように、ゾーンαの周りの円形の“近傍ゾーン”の外周θでこの目的は達成される。ゾーンαは、各々がセル地理的中心座標γを有する１つ以上のセルβにより定義される。ゾーンが１つより多くのセルを含む場合、当該ゾーンはゾーン地理的中心座標δを有する。ゾーン地理的中心座標は、セル境界線の最大及び最小の緯度並びに経度の中央である。近傍ゾーンの外周は、ゾーン地理的中心座標及び外周半径εにより定義される。

着呼者がそのゾーン内にいない場合の現在位置とそのゾーンの周りの近傍ゾーンの外周との間の関係は、発呼者に提示される呼の完了オプションのための基礎である。ゾーン地理的中心に関連する着呼者の接線移動ωにより情報は追加的に補強される。

着呼者が１より多くのゾーンを有する場合、着呼者の現在位置とゾーン地理的中心座標との間の距離が最も近いゾーンが選ばれる。ゾーンの選択は、移動も考慮に入れることによりさらに高度なものになり得る。到着推定時間（ＥＴＡ：Estimate Time of Arrival）、又はゾーンから離れている移動の場合は帰還推定時間（ＥＴＲ：Estimate Time to Return）が、距離及び接線移動により与えられる。最も小さいＥＴＡ／ＥＴＲは、最近傍ゾーンを判定する。ＥＴＡ／ＥＴＲは、各ゾーンについて接線移動が実質的に０より大きい場合にのみ使用され得る。

本発明の特徴は、一連の実施形態を用いて説明される。本発明の基本的なアイデアから離れることなく現行の発明から複数の他の利用が可能であることは理解されるべきである。

図３に、ゾーンサーバにおける現行の発明の１つの実施形態が示されている。イントロダクションにおいて概説されているように、実装は、ＳＣＰ上で動作しているゾーンサーバアプリケーション若しくは専用ゾーンサーバノード、又はそれらの組合せとしてなされ得る。次の説明は、専用ゾーンサーバノードの実装に基づいている。機能が複合的な又は単一のソフトウェアの実装に容易に移植され得ることは理解され得る。

ゾーンサーバは、三つの基本的な非同期の機能を有する；ゾーンを有し当該ゾーンサーバによりサービス提供される移動局の位置をアクティブに追跡し続け、上記移動局へ向かう呼に対して動作し、及び上記移動局へ試みられた接続に関連する発呼者についてスケジュールされるイベントを処理する。

ゾーンサーバＣは、次の機能を含む；
−ＨＬＲといった、通信ネットワークにおける他のノードへのＭＡＰ（Mobile Application Part）インタフェースを処理するためのＭＡＰインタフェースコントローラ１０１．
−ＭＳＣといった、通信ネットワークにおける他のノードへのＣＡＰ（CAMEL Application Part）インタフェースを処理するためのＣＡＰコントローラ１０２。
−定義されたゾーンを有し、上記ゾーンサーバにより処理される移動局の位置検索を処理する計算部１０４。当該計算部は、距離の計算及び移動の計算も実行する。計算結果は、ゾーンベース１０５に記憶される。また、計算が要求されると、計算部はゾーンベースから前回の計算結果を取得する。計算部の機能は、イベントマネージャ１０６及び決定機能１０３と独立して実行される。
−上記ゾーンサーバにより処理される各移動局のアイデンティティ／ゾーンの組合せについてのレコードを保持するゾーンベース１０５。レコードは、移動局のその定義されたゾーン各々への距離及び当該定義されたゾーンの地理的中心に対する相対的な移動を含む。またゾーン、近傍ゾーンの外周、ＨＰＬＭＮ又はＶＰＬＭＮにおける現在のプレゼンスもゾーンベースに記憶される。
−ゾーンを有し、上記ゾーンサーバによりサービス提供される移動局が呼び出されると動作する決定機能１０３。ＭＳＣがＣＡＰインタフェースを介してＣＡＰ−ＩＤＰを送信することにより開始される。決定機能は、ゾーンベース１０５から上記移動局がそのゾーンの１つに存在することを読み取ると、接続オーダを与える。オーダは、ＣＡＰ−ＣＯＮメッセージを用いてＭＳＣに対してＣＡＰインタフェースを介して与えられる。そのゾーンのいずれにも存在しない場合、決定機能は専用のアナウンスメントを発呼者へ再生するようオーダし、そのゾーンに関連する呼び出された移動局の現在位置及び移動に関連する呼の完了についてのオプションを与える。決定機能は、発呼者のオプション選択を受信し、当該オプションを実行する。これは、呼の終了、ボイスメールへの接続、着呼者払いによる接続、を含み得る。呼の終了の前にそれはイベントマネージャ１０６に対して未来のイベントをスケジュールしてもよい。
−スケジュールされるべきイベントを決定機能１０３から受信するイベントマネージャ１０６。イベントマネージャは、イベントベース１０７にイベントを記憶する。イベントマネージャは、記憶されたイベントについての条件が満たされているか持続的にチェックする。そのためそれは、ゾーンベースから関連する情報を読み取る。条件が満たされている場合、上記イベントにおけるアクションが実行される。これにより、前回の発呼者と移動局との間の呼、又はボイスメッセージ、ＳＭＳなどを用いる発呼者への通知がセットアップされ得る。イベントマネージャは、上記イベントにおけるアクションを実行するために利用可能なＭＡＰ及びＣＡＰインタフェースの両方を有する。
−発呼者、移動局、満たされるべき条件、及び取られるべきアクションについての詳細を伴うレコードを各イベントについて保持するイベントベース１０７。

言及される機能の各々は、次のセクションにおいてより詳細に説明されるであろう。

ＭＡＰ及びＣＡＰインタフェースコントローラ
ＣＡＭＥＬ及びモバイルアプリケーションパート（ＣＡＰ／ＭＡＰ）についてのインタフェースコントローラは、３ＧＰＰの技術仕様２９．００２及び２９．０７８に従った最新の技術水準による実装である。実際のネットワーク及びゾーンサーバの実装に応じて、ＭＡＰ及びＣＡＰインタフェースは、他のノードへの接続について、ＩＳＵＰ（ＩＳＤＮユーザパート）のＩＴＵ−Ｔ勧告Ｑ．７６３及び７６４並びにＥＴＳＩ標準に従ったＩＮＡＰ（Intelligent network application protocol）を伴って拡張され得る。

計算部
計算部は、リクエスタ、レポートＦＩＦＯ、及び位置計算部の３つのベース機能を含む。リクエスタは、ゾーンベースに含まれる各ＭＳＩＳＤＮについてＨＬＲへ位置要求を送信する。これによりゾーンベースに新しいゾーンが追加されることが可能となり、それはリクエスタにより自動的に考慮されるであろう。イントロダクションで示されているように、要求はＡＴＩ又はＡＬＲ要求のいずれかであり得る。ＡＴＩ要求は、ＨＬＲにおいて利用可能であるような位置レポートを生成する。ＡＬＲ要求は、ＨＬＲに実際の位置レポートについてＭＳＣへの問い合わせを行わせる。この差は別にして、リクエスタは１度の要求又は購読を行い得る。一方、ＡＬＲの購読（subscription）は、システムに高い負荷を与える。負荷を削減するために、ＰＣＴ出願ＷＯ２００７／０５０１４８２において説明されているようなより合理的な方法が利用可能である。ＨＰＬＭＮの境界線をたどらない近傍ゾーンの外周の性質のため何らかの適応がなされなければならないことは、留意されるべきである。そのため隣接するＶＰＬＭＮをＨＰＬＭＮとして扱うことが求められ、上記方法においてＬＡＣレベルは省略され得る。携帯の現在位置がＨＰＬＭＮ又は隣接するＶＰＬＭＮの１つの外側にある間は、距離の計算は実行されないであろうことから、ＡＴＩの購読で十分である。ＭＣＣ、ＭＮＣ、又はＬＡＣの変化のためＨＬＲがＭＳＣから更新情報を受信すると、ＨＬＲは自動的に更新情報を送信するであろう。ＡＬＲの購読の場合、レポート間隔が指定される必要がある。ゾーンまでの距離及びゾーン地理的中心へ向かう接線移動の値に基づいて、購読をレポート間隔との関連において調節することにより、ここでも負荷を削減することは可能である。

ＨＬＲから受信される位置レポートは、位置計算部により処理される前に一時的にＦＩＦＯに記憶される。単純なＦＩＦＯの代わりに、同じＭＳＩＳＤＮについてのより古いレポートがまだＦＩＦＯ内にあるかをチェックするより合理的なＦＩＦＯが使用され得る。この場合、より古いレポートは削除される。そうしてＦＩＦＯのサイズをサービス提供されるＭＳＩＳＤＮの数に合わせることができ、オーバフローのリスクが軽減される。

位置計算部は、ＦＩＦＯから位置レポートを読み出し、当該位置レポートにおいて言及されているのと同じＭＳＩＳＤＮを有する全てのレコードをゾーン−セルテーブル２０４から読み取る。位置レポートの処理は３つのステージで行われ、上記ＭＳＩＳＤＮに属する各定義されたゾーンについて実行される。そのため読み出されたレコードは、ゾーン番号に基づくセットにグループ化される。

位置計算部は第一ステージにおいて、上記位置レポートにおいて言及されているＭＣＣ、ＭＮＣ、及びＧＣＩ／ＳＡＩをＭＳＩＳＤＮについて読み出されたレコードの第一セット、すなわち第一ゾーンにおいて対応する値と比較する。ＭＣＣ、ＭＮＣ、及びＧＣＩ／ＳＡＩがマッチする場合、同じＭＳＩＳＤＮ及びゾーン番号を有するゾーンテーブル２００のレコードにおいてプレゼンスは“ゾーン”にセットされる。ＭＣＣ及びＭＮＣのみがマッチしＧＣＩはマッチしない場合、値はＨＰＬＭＮにセットされる。ＭＣＣ及びＭＮＣがマッチしない場合、ＨＰＬＭＮに隣接し又はＨＰＬＭＮと同じエリアを（部分的に）カバーする別のＭＣＣ−ＭＮＣの組合せに、上記位置レポートにおいて言及されているＭＣＣ及びＭＮＣがマッチするかのチェックが、別々に実行される。位置計算部は、マッチしている場合は（ＰＬＭＮをカバーする）ＣＰＬＭＮに、マッチしていない場合はＶＰＬＭＮに値をセットする。ＣＰＬＭＮの判定は、ＬＡＣを同様に考慮することによってより正確に行われ得る。このステージは、上記位置レポートから読み出されたタイムスタンプを上記レコードのタイムスタンプフィールドへコピーすることにより完了する。

第二ステージにおいて、ゾーンのＧＣＣ（地理的中心座標）に関連する距離及び移動が判定される。そのため計算部は、ゾーン−距離テーブル２０２からマッチしているＭＳＩＳＤＮ及びゾーン番号を有するレコードを読み取る。各ＭＳＩＳＤＮ及びゾーン番号について、継続的な測定結果を保持するため固定数のゾーン距離のレコードがＭＳＩＳＤＮとゾーンの組合せを定義する際に入力されている。レコードの数がシステムにより定義された数に一定で維持されるよう、最も古い測定レコードは位置レポートからの新しい測定結果で上書きされるであろう。距離の計算は、前もって判定されたプレゼンスがＨＰＬＭＮ又はＣＰＬＭＮである場合にのみ実行される。プレゼンスがＶＰＬＭＮ又はゾーンである場合、距離値はＶＰＬＭＮについて−１、ゾーンについて０にセットされる。２つ目のチェックは、上記位置レポートにおけるＬＡＴ／ＬＯＮＧ（緯度−経度）座標の存在である。存在する場合、このＬＡＴ／ＬＯＮＧ座標とゾーンテーブルから以前読み出されたレコードにおいて存在するゾーン地理的中心座標との間の距離が計算される。この計算は、楕円体地球のプロファイルについてよく知られた補正及び緯度補正を含み得る。存在しない場合、上記レポートにおいて言及されているＧＣＩの中心座標が距離の計算のための基礎として考えられる。計算された距離及びタイムスタンプは、上述のゾーン−距離テーブルから読み出された最も古いレコードに入力される。

移動の計算は、プレゼンスがＣＰＬＭ、ＨＰＬＭＮ又はゾーンである場合に行われる。ＶＰＬＭＮの場合、移動値は空白のままである。移動は、最も古い距離と計算された距離との間の差を対応するタイムスタンプの時間差で割って計算される。最も古い距離値が−１である場合、次の距離値が有効距離を有すると考えられる。１つの有効距離しか存在しない場合（海外から戻ってくる場合）、移動は計算されず、移動値は空白のままである。言及されたスライディング線形法の代わりに、２つの最新の距離の間の移動をより重視するより高度なより高次の方法を使用することも可能である。

第三ステージにおいて、プレゼンス値がＣＰＬＭＮ又はＨＰＬＭＮである場合に、近傍ゾーンにおけるプレゼンスが判定される。これは、ゾーン地理的中心からの事前に定義された距離に基づいて単純に行われ得る。計算された距離がより小さく又は等しい場合、移動局は近傍ゾーンにあるとセットされる。より専用的な方法は、局がそのゾーンへ向かって移動している場合に到着推定時間の方法を使用することである。最大の到着推定時間を与えるようシステムパラメータが定義される。実際の到着推定時間は、移動及び距離から計算される。この到着推定時間が上記システムパラメータよりも短い場合、移動局のプレゼンスは、近傍ゾーンにあるとされる。移動局がゾーンから離れて移動している場合も同じことが適用され得る。単純に移動が正であるものとし、向かってきているときと同様にすることで、帰還推定時間を使用することができる。移動値がとても小さく又は０である場合、推定時間の方法は使用されるべきではなく、事前に定義された距離パラメータとの比較が代わりに行われるべきである。近傍ゾーンにおけるプレゼンスが検出された場合、同じＭＳＩＳＤＮ及びゾーン番号を有するゾーンテーブルからのレコードにおけるプレゼンス値は、近傍ゾーン値で上書きされる。

１つより多くのゾーンがＭＳＩＳＤＮについて定義されている場合、同じゾーン番号を伴う次のレコードのセットは、前述されているように取得され処理される。これは、レポートにおいて言及されているＭＳＩＳＤＮについての全てのゾーンについて位置レポートが処理されるまで継続する。

ゾーンベースへの書き戻しは各計算において記述されているが、位置レポートについての全ての計算が行われるまでゾーンベースへの書き戻しを実際には省略するのが最善である。これにより変化を一貫したものとし、イベントマネージャまたは決定機能がゾーンベースから部分的に更新されたデータを読み取らないことが保証される。

ゾーンベース
ゾーンベースは、ゾーンサーバにおける中心的な情報記憶装置である。それによりイベントマネージャ及び決定機能は、計算とは非同期に動作することが可能になる。決定機能がＨＬＲ／ＭＳＣから要求される遅い位置レポートのために接続を待つ必要がないため、これは特定の利点を有する。ゾーンベース１０５は３つの専用のテーブルを有する；
−ＭＳＩＳＤＮについての実際のゾーン定義を保持するゾーン−セルテーブル２０４。各レコード２０５は、ＭＳＩＳＤＮ、ゾーン番号、及びセル参照を保持する。セル参照は、ＭＣＣ、ＭＮＣ、及びＧＣＩ／ＳＡＩを含む。ゾーンが複数のセルを含む場合、同じＭＳＩＳＤＮ及びゾーン番号を有するいくつかのレコードが存在する。ＭＳＩＳＤＮについて１つより多くのゾーンが定義されている場合、異なるゾーン番号で同じＭＳＩＳＤＮを有する複数のレコードが存在する。
−ＭＳＩＳＤＮのゾーン番号毎に距離レコード２０３を保持するゾーン距離テーブル２０２。前述されているように、移動の計算のために複数の継続的な距離の測定結果を保持するために、ゾーン定義においてシステムパラメータの数のレコードが用意されている。距離は、メートルの整数の数として与えられる。０を使用して、距離を有するというよりむしろゾーンにおけるプレゼンスが示され、−１を使用して、移動局がＨＰＬＭＮ又はＣＰＬＭＮ内にないため距離が計算されないことが示される。
−各ＭＳＩＳＤＮとゾーン番号の組合せについてゾーンレコード２０１を保持するゾーンテーブル２００。レコードは、地理的中心座標（ＧＣＣ）、現在のプレゼンス、タイムスタンプ、及び移動についての指標を含む。ＧＣＣは、ゾーンの定義と共に入力される。現在のプレゼンス指標は、ＶＰＬＭＮ、ＣＰＬＭＮ，ＨＰＬＭＮ、近傍ゾーン又はゾーンについての値のうちの１つを有する。タイムスタンプは、処理された最新の位置レポートから読み出される。移動についての指標は、ＧＣＣに関連する接線移動を毎秒メートルで表す符号付き整数である。

前述されているように、ゾーンベースへのアクセスは、統一的なトランザクションに基づいて最善にアレンジされており、更新が統一的に実行されることを保証している。

決定機能
イントロダクションにおいて説明されているように、ゾーンを有する携帯加入者についての着呼により、ＭＳＣはゾーンサーバへＣＡＰ−ＩＤＰメッセージを送信する。ＣＡＰ−ＩＤＰメッセージは、決定機能をトリガする。決定機能は、ＭＳＩＳＤＮが着呼者のＭＳＩＳＤＮにマッチするゾーンテーブルから着呼者のプレゼンス情報を読み出す。着呼者がそのゾーンの１つにいる場合、呼は接続される。そのため決定機能は、ＣＡＰ−ＣＯＮメッセージをＭＳＣへ送信する。また、そのゾーンの１つに存在する場合には、選択可能な呼の完了オプションを伴うアナウンスメント又は伴わないアナウンスメントが、任意で発呼者へ再生される。これは、存在しない場合について以下に説明することに相当するものである。

着呼者がそのゾーンの１つにいない場合、決定機能は２つ目のチェックを実行する。２つ目のチェックは、発呼者についての高度プレゼンス通知を可能とする機能を含む。詳細についてはさらなる実施形態を参照されたい。可能とされる場合、決定機能はプレゼンス情報を使用して発呼者へ再生されるべきアナウンスメントを組み立て、プレゼンス及び移動についての情報を発呼者に与え、呼の完了の形態を選択するよう要求する。発呼者は、着呼者がそのゾーンの１つにいない場合に選択できる４つの基本的なオプションを有する；
−ボイスメールへ接続、
−追加的料金を伴って携帯へ接続、
−存在するときコールバック、
−存在するとき通知。
発呼者は、ただ接続を切るという５つ目のオプションももちろん有する。

最初の２つのオプションのいずれにおいても、決定機能はＣＡＰ−ＣＯＮメッセージをＭＳＣへ送信する。“追加的な料金を伴って携帯に接続”というオプションが選択される場合、オプションとして課金アナウンスメントが発呼者へ再生され得る。いくつかの司法管轄権においては、このアナウンスメントが義務付けられている可能性がある。後の２つのオプションにおいて、アナウンスメントにより、発呼者には選択されたオプションが通知される。そのため決定機能は、ＣＡＰ−ＰＡをＭＳＣへ送信する。このアナウンスメントを再生後、ＭＳＣはＣＡＰ−ＳＲＲを返答する。決定機能は、ＣＡＰ−Ｄｉｓｃｏｎｎｅｃｔを送信すると共に接続を終了する。決定機能は、未来のイベントレコードを用意し、それをイベントマネージャへ渡す。

発呼者により通知が選択された場合、決定機能は、ＳＭＳ通知を使用し得るか否かをチェックする。判定は、ＣＡＰ−ＩＤＰメッセージにおける発呼者についての位置番号又は情報の存在に基づく。発呼者へ再生されるアナウンスメントは、２つのパートを含む。１つ目のパートは、高度プレゼンス情報を提供し、２つ目のパートは、呼を完了するための利用可能なオプションを提供する。両方のパートが、着呼者の移動及びプレゼンス情報に左右される。下の表１は、１つ目のパートについての関係を示し、表２は、２つ目のパートについての関係を示す。

表２における通知についてのイベントのトリガは、ホームゾーンへ向かう移動に基づく。これは、最も一般的に予想される利用である。追加的なトリガは、ホームゾーンから離れての移動に基づき得る。例としては、ＨＰＬＭＮの内側にいる場合においてＨＰＬＭＮから外へ移動し、又は近傍ゾーンの外周にいる場合において近傍ゾーンから離れる。これにより、発呼者は選択できるより多くのオプションが与えられるであろう。一方実際には、面倒にならないようオプションの数は４〜６つに制限されるべきである。より多くのオプションが利用可能である場合、２段階での問合せ（2 stage inquiry）がより良い；第一段階では４つの主なオプションから１つを選択し、第二段階では必要な場合にイベントについて選択する。

着呼者の位置との関連における発呼者自身の位置を含めることにより、アナウンスメントを発呼者により有用にすることができる。そのため決定機能は、発呼者のＨＬＲまたはＭＰＳのいずれかから位置レポートを取得する。いずれのＨＬＲが接続するかはＣＡＰ−ＩＤＰに存在する。この特徴は、現在着呼者のゾーンの内側にいる発呼者にとって特に利益がある。それにより、電話をかけるよりもむしろ訪問するというオプションを発呼者に残す。

イベントベース
イベントベース１０７は、発呼者によるオプション選択によってもたらされる未来のイベントのそれぞれについてレコード２０６を保持し、呼のセットアップを終了させ、着呼者の移動に関する条件に基づいて未来のイベントをスケジュールする。レコードは、発呼者のアイデンティティ、着呼者のアイデンティティ、条件の仕様、及び条件が満たされた場合に取るべきアクションの４つの基本的な要素を保持する。アクションパートは、アクションコード及びデータフィールドの２つの要素で組み立てられる。アクションコードは、アクションのタイプを指定し、データフィールドは、アクションに要求される追加的情報の位置を指定する。例；アクションコードは“ＳＭＳにより発呼者に通知”；データフィールドはＳＭＳのための固有テキストを見つけられる位置を含む。

イベントマネージャ
イベントマネージャ１０６は、イベントベース１０７から次々とイベントレコードを読み取る。イベントマネージャ１０６は、ゾーンベースにクエリを行い、イベントにおける条件が満たされているかをチェックする。そうである場合、イベントに記述されているアクションが実行される。実行後に、イベントレコードはイベントベースから削除される。このプロセスは、発呼者が呼の完了の未来のイベントタイプを選択する場合、決定機能により割り込まれ得る。決定機能は、イベントマネージャにイベントレコードの内容を渡す。イベントマネージャは、イベントベースにおける新しいイベントレコードに当該内容を記憶する。

実行されるべきアクションは、ボイスメッセージ通知、ＳＭＳ通知、又は呼のセットアップを含み得る。他のタイプのアクションも可能である。イベントマネージャは、ただアクションを実行するだけである。イベントマネージャは、固定電話にＳＭＳを送信することはできない、というようなアクションの有効性をチェックしない。これは、決定機能のタスクである。

イベントマネージャについての別のタスクは、廃止された未来のイベントをチェックすることである。１つ目のオプションは、イベントテーブルにおけるイベントについて追加的なタイムスタンプを入力することである。イベントレコードを入力してから一定時間が経過してもそれを実行していなければ、イベントマネージャは当該イベントを削除し得る。２４時間よりも古いタイムスタンプを有するコールバックのイベントレコードの除去がよい例である。２つ目のオプションは、実際の移動がイベントについて予期されているものと反対である場合に、イベントレコードを削除することである。例としては、着呼者のプレゼンスが近傍ゾーンであったときに入力され、ホームにいるときにコールバックを要求するコールバックについてのイベントレコードを、実際のプレゼンスがＶＰＬＭＮに変化した場合に削除することである。

さらなる実施形態は、加入者についてのプライバシーの観点を扱う。加入者は、高度プレゼンス通知をオン又はオフに切り換えるオプションを有する。加入者には、高度位置通知の設定を決め、及び高度位置通知を自分の携帯電話Ｂを介して有効又は無効にすることを可能にするための、ウェブベースのクライアントが提供される。加えて加入者は、リスト上にない他の全ての番号と異なる扱いを受ける（固定及び携帯両方の）電話番号のリストを、ウェブベースのクライアントを介して入力することができる。これにより加入者は異なる扱いを受ける家族及び友人のグループを有することが可能となる。

図５に実施形態が説明されている。ユーザは、自分のパーソナルコンピュータＤを介してウェブサーバ上のウェブページを選択することができる。ウェブサーバは、最初のセキュアＩＰチャネル５をセットアップし、ログインページを提供する。一方ウェブサーバは、ゾーンサーバアプリケーションＣにおけるゾーンベース１０５への持続的なセキュアＩＰチャネル６を有する。これは、ゾーンサーバ又はゾーンサーバアプリケーションのホストが、ＩＰインタフェースを有することを意味する。

ＭＳＩＳＤＮ及びパスワードの入力並びにウェブサーバにおけるバリデーションの後、ウェブサーバは、加入者がゾーンベース１０５における自分のデータにアクセスし及び変更することを可能にするクライアントウェブアプリケーションを提供する。そのためウェブサーバは、上記ＭＳＩＳＤＮを含むゾーンベースへクエリを送信し、関連情報を読み出す。その後この情報は、セキュアチャネル５を介してウェブクライアントへ送信される。ユーザは、変更を行いウェブサーバに返送することができ、今度はウェブサーバがゾーンベースへ更新クエリを送信する。ウェブクライアントは、構文及び意味のチェックを用いて加入者の変更を可能とするかついての第一のチェックを実行する。またウェブサーバも、ゾーンベースへ更新クエリを送信する前に加入者の変更を可能とするかのチェックを実行する。最終的にはゾーンベースが、許可されない又は矛盾したレコードの更新を禁止するいくつかのルールを有する。

この実施形態について、次の適応がゾーンサーバになされる。第一に、図６ａ及び６ｂに示される２つの追加的なテーブルをゾーンベースは保持する。１つ目のテーブルは、ＭＳＩＳＤＮ−グループメンバー番号の組合せについてのレコード２１１を保持するゾーン−グループテーブル２１０である。ＭＳＩＳＤＮの各グループメンバーについてレコードは存在する。２つ目のテーブルは、ステータスが記憶されるＭＳＩＳＤＮ毎に１つのレコード２０９を保持するゾーン−許可テーブル２０８である。ＧＲＯＵＰステータス、ＯＴＨＥＲステータス、及びＳＷＩＴＣＨステータスと、全部で３つ存在する。ＧＲＯＵＰステータス及びＯＴＨＥＲステータスは、高度位置通知が有効であることを意味するＯＮ、それが無効であることを意味するＯＦＦ、及びそれがＳＷＩＴＣＨステータスにより制御されることを意味するＳＷＩＴＣＨの３つの値を有し得る。ＳＷＩＴＣＨステータスは、ＯＮ又はＯＦＦのみである。加入者は、ウェブインタフェースを介してＧＲＯＵＰ及びＯＴＨＥＲステータスを制御することができる；ＳＷＩＴＣＨは、携帯電話Ｂを介して制御される。ＯＴＨＥＲはＧＲＯＵＰより高いステータスを有することはできないことに留意すべきである；そのためＧＲＯＵＰのＯＦＦ及びＯＴＨＥＲのＯＮの組合せは許可されない。

第二の修正は、決定機能１０３に対するものである。１つ目の実施形態における固定された動作モードの代わりに、決定機能はここで３つの動作モードを有する。モード１は、先行技術の動作タイプと同一である。高度位置通知は実行されない。モード２は、１つ目の実施形態において説明されているものと同一である。モード３は、発呼者がグループメンバーであるか否かの追加チェックを含む。そうである場合にはモード２が適用され、そうでない場合にはモード１が適用される。

ＭＳＣからのＣＡＰ−ＩＤＰがゾーンサーバにより受信されると、ＭＳＩＳＤＮがＣＡＰ−ＩＤＰにおける着呼者の番号と等しいゾーン−許可テーブルから、決定機能がレコードを取ってくる。ＧＲＯＵＰ、ＯＴＨＥＲ及びＳＷＩＴＣＨについてのステータスに基づき、下のテーブルに従ってモードが選択される。

モード１又は２の場合、ＣＡＰ−ＩＤＰはいずれのモードにおいても直接処理される。モード３の場合、決定機能はＭＳＩＳＤＮがＣＡＰ−ＩＤＰにおける着呼者の番号にマッチする全てのレコードをゾーン−グループテーブルから取ってくる。これらのレコードにおけるグループメンバーの番号は、共にグループメンバーリストを形成する。ＣＡＰ−ＩＤＰに含まれている発呼者の番号がグループメンバーリスト内にある場合、ＣＡＰ−ＩＤＰはさらにモード２で処理され、そうでない場合、それはモード１で処理される。

ゾーンサーバに対する第三の修正は、携帯電話Ｂを介する制御に関する。前述されているように、加入者は携帯電話を使用して、ＳＷＩＴＣＨステータスをＯＮ又はＯＦＦにセットすることができる。加入者は、サービスコール（service call）又はサービスＳＭＳというこの２つの基本的な方法を有する。サービスコールの一例は、Ｏｆｆに切り換えるための＊３００＃０＊及びＯＮに切り換えるための＊３００＃１＊である。サービスＳＭＳの一例は、＊３００への‘ＯＮ’又は‘ＯＦＦ’の送信である。

サービスコールをＳＣＰにおけるサービスアプリケーションへ到達させるための方法及びシステムは、最新の技術水準においてよく知られている。サービスコールは、最終的にＳＣＰへのＣＡＰ−ＩＤＰの送信となるであろう。コード３００は、ゾーンサーバアプリケーションを示す。ここで決定機能は、ＣＡＰ−ＩＤＰを処理しなければならない。

サービスＳＭＳを直接ＭＳＣからＳＣＰへ転送するための方法及びシステムは、それほど知られてはいない。転送はＣＡＰ−ＩＤＰで開始されるものの、内容をゾーンサーバアプリケーションへ到達させるためにＭＳＣとＳＣＰとの間のＣＡＰ及びＭＡＰインタフェースの両方の連携が必要とされる。再び３００のコードは、決定機能がＣＡＰ−ＩＤＰを処理しなければならないゾーンサーバアプリケーションを識別する。直接のＭＳＣ−ＳＣＰのＳＭＳ転送は、最新の技術水準にある。

そのため、ＣＡＰ−ＩＤＰを受信する決定機能は、それが次の３つの場合のいずれに関連するかをまずチェックする必要がある；発呼者から着呼者の携帯へ、サービスコール、又はサービスＳＭＳ。従って、最初のチェックは、ＣＡＰ−ＩＤＰにおける着呼者の番号である。これが通常のＭＳＩＳＤＮである場合、ＣＡＰ−ＩＤＰは前述のように処理され得る。着呼者の番号が上述の例に従って＊３００を含む場合、それはサービスコール又はサービスＳＭＳのいずれかである。ＣＡＰ−ＩＤＰの着呼者フィールドにおいて＊３００の後に＃０又は＃１が存在するということは、それがサービスコールであることを示す。存在しないということは、サービスＳＭＳを示す。

サービスコールの場合、着呼者フィールドにおける０又は１の値を使用してＳＷＩＴＣＨステータスを更新する。そのため決定機能は、ＭＳＩＳＤＮがＣＡＰ−ＩＤＰにおける発呼者の番号にマッチするゾーン−許可テーブルからレコードを読み出す。ＳＷＩＴＣＨの値が更新され、レコードがゾーン−許可テーブルへ書き戻される。最終的に、ＣＡＰ−ＤｉｓｃｏｎｎｅｃｔがＭＳＣへ送り返され、動作を終了する。

０又は１が存在しない場合、ＳＭＳの内容はＭＳＣから取得される。サービスコールについてのようにレコードが読み出され、ＳＭＳの内容において記述されているＯＮ又はＯＦＦの値でステータスの値が更新される。レコードが書き戻され、ＣＡＰ−Ｄｉｓｃｏｎｎｅｃｔで動作が終了する。

サービスコール又はＳＭＳでの誤った入力は処理される必要がある。サービスコールでの誤った入力に基づく動作は、最新の技術水準においてよく知られている。ＳＭＳについての誤った入力の処理は、いくらか追加的な精緻化を必要とする。例に示されているようにＳＭＳの内容がＯＮでもＯＦＦでもないことを決定機能が見出した場合、送信している加入者への値が正しくないという通知が要求される。これは、加入者とサービスとの間のＳＭＳのやりとりの一部として行われ得る。加入者とサービスアプリケーションとの間のＳＭＳのやりとりのための方法も、技術的に知られている。

この実施形態のさらなる観点は、親による制御である。親は、一方で自分の子供たちがプレゼンス通知を勝手にオフに切り換えることを望まず、もう一方で全ての人へのプレゼンス通知を制限したいかもしれない。１つ目は、常に通知を受信する番号の特別グループを追加することにより達成され得る。これらの番号は、加入の詳細の入力と共にゾーンベース内に入力される。２つ目のオプションは、許可についての制御を加入者の携帯番号から（親の）別の携帯番号に変更し、加入者の電話の許可設定についての制御を無効にすることである。後者は、ゾーンベースに追加的にＩＭＳＩ／ＭＳＩＳＤＮを記憶し、ゾーンベースにおける加入ＭＳＩＳＤＮよりむしろその番号と発呼ＭＳＩＳＤＮとのマッチングを使用するよう決定機能に要求する。親による制御が必要とされない場合、加入者の携帯が許可設定を変更することが可能となるようこのフィールドに加入者のＭＳＩＳＤＮがコピーされ得る。複数の子供を有する場合に起こり得るように、ゾーンベースに複数のレコードが存在することを決定機能が検出した場合、決定機能はまずいずれの番号の許可が変更されるべきかについて問合せをしなければならない。

教示に基づいて当業者が成し得る全ての可能な実装を示すことよりむしろ、当業者が教示を理解できるようにすることを目的として、上記実施形態は本発明を説明している。

Claims (19)

1. 携帯加入者が公衆陸上移動体ネットワークにおける少なくとも１つの定義されたゾーン（α）に割り当てられている場合において、前記携帯加入者が前記少なくとも１つの定義されたゾーンに存在しないときの、発呼者（Ａ）から前記携帯加入者（Ｂ）への呼を完了させるための方法であって；
   前記ゾーン（α）より大きく、半径（ε）と前記ゾーン（α）のゾーン地理的中心座標（δ）とにより定義される円形の外周（θ）を有する地理的エリアの内部において、前記携帯加入者の端末（Ｂ）のプレゼンスをゾーンサーバにより判定するステップと、
   前記少なくとも１つの定義されたゾーンとの関連における前記携帯加入者の現在位置と、前記発呼者が前記呼を完了するためのオプションとを含むアナウンスメントを組み立てるステップと、
   移動体サービス交換局（ＭＳＣ）に、前記発呼者への前記アナウンスメントを行わせるステップと、
   前記ＭＳＣに、前記呼を完了するための前記オプションからの前記発呼者によりなされた選択を返答させ、及び前記発呼者によりなされた前記選択を解析し実行するステップと、
   を含む方法。
2. １つより多くの定義されたゾーンを有する携帯加入者のために、前記１つより多くのゾーンに最も近いゾーンを判定する追加的なステップ、を含む、請求項１に記載の方法。
3. 最も近いゾーンとは、前記携帯加入者（Ｂ）の現在位置と前記１つより多くのゾーンからのゾーン地理的中心座標（δ）との間の最短距離を有するゾーンである、請求項２に記載の方法。
4. 最も近いゾーンとは、前記携帯加入者の現在位置とゾーン地理的中心座標との間の距離、及び前記１つより多くのゾーンからの前記ゾーン地理的中心座標（δ）に向けての接線移動（ω）に基づく、最短の到着推定時間又は帰還推定時間を有するゾーンである、請求項２に記載の方法。
5. アナウンスメントを組み立てる前記ステップは、
   前記発呼者の前記現在位置を取得するステップと、
   前記携帯加入者の前記少なくとも１つの定義されたゾーン又は外周の内部における前記発呼者のプレゼンスをチェックするステップと、
   前記少なくとも１つの定義されたゾーンとの関連における前記携帯加入者の現在位置と、前記発呼者が前記呼を完了するためのオプションとを含むアナウンスメントを組み立てるステップであって、前記アナウンスメントは、前記携帯加入者の前記少なくとも１つの定義されたゾーン又は外周の内部における前記発呼者の前記プレゼンスに特別に適合される当該ステップと、
   を含む、請求項１に記載の方法。
6. オプションの候補は、ボイスメールへの接続、追加的な料金の負担を伴う接続、通知、又はコールバックである、請求項１に記載の方法。
7. 半径（ε）は、固定的な距離、又は、前記携帯加入者のゾーン地理的中心座標（δ）に向けての接線移動（ω）及び固定的な期間により判定される可変的な距離であり、前記可変的な距離は、最小値及び最大値により規定される、請求項１に記載の方法。
8. 前記発呼者が前記携帯加入者の現在位置を受信することについての前記携帯加入者の許可を前記ゾーンサーバによりチェックする追加的なステップ、を含む、請求項１に記載の方法。
9. 許可をチェックする前記ステップは、
   前記発呼者が定義されたグループのメンバーであるかをチェックするステップと、
   前記発呼者（Ａ）が定義されたグループのメンバーである場合に、当該グループについての現在の許可設定をチェックするステップと、
   前記発呼者（Ａ）が定義されたグループのメンバーではない場合に、非グループメンバーについての現在の許可設定をチェックするステップと、
   を含む、請求項８に記載の方法。
10. 少なくとも１つの携帯端末を含む通信システムにおいて、ゾーンサーバ又はサービス制御ポイント（ＳＣＰ）上で実行されるゾーンサーバアプリケーション（Ｃ）に接続した移動体サービス交換局（ＭＳＣ）に接続して動作可能な、携帯加入者（Ｂ）により現在の許可設定を判定するための請求項８に記載の方法であって、前記携帯加入者により、ショートメッセージサービス（ＳＭＳ）メッセージ、ＵＳＤＤメッセージ、又はＩＮ呼を、前記携帯端末から前記ゾーンサーバ又はゾーンサーバアプリケーションへ送信するステップ、を含む方法。
11. 少なくとも１つのクライアントコンピュータノード（Ｄ）を含む通信システムにおいて、ゾーンサーバ又はサービス制御ポイント（ＳＣＰ）上で実行されるゾーンサーバアプリケーション（Ｃ）に接続したゾーン制御ウェブページを備えるウェブサーバに接続して動作可能な、携帯加入者（Ｂ）により現在の許可設定を判定するための請求項８に記載の方法であって、
    前記携帯加入者により、前記クライアントコンピュータノードから前記ウェブサーバにログオンするステップと、
    前記ウェブサーバからのゾーン制御ウェブページを要求するステップと、
    前記現在の許可設定を変更するステップと、
    前記ゾーン制御ウェブページを前記ウェブサーバに返送するステップと、
    前記ウェブサーバにより、前記現在の許可設定の変更のためのオーダメッセージを前記ゾーンサーバ又はゾーンサーバアプリケーションへ送信するステップと、
    前記ゾーンサーバ又はゾーンサーバアプリケーションにより、前記オーダメッセージを受信し及び前記オーダメッセージに従って前記現在の許可設定を変更するステップと、
    を含む方法。
12. 少なくとも１つのクライアントコンピュータノード（Ｄ）を含む通信システムにおいて、ゾーンサーバ又はサービス制御ポイント（ＳＣＰ）上で実行されるゾーンサーバアプリケーション（Ｃ）に接続したゾーン制御ウェブページを備えるウェブサーバに接続して動作可能な、携帯加入者による許可グループの前記メンバーの判定の請求項９に記載の方法であって、
    前記携帯加入者により、前記クライアントコンピュータノードから前記ウェブサーバにログオンするステップと、
    前記ウェブサーバからのゾーン制御ウェブページを要求するステップと、
    前記グループのメンバーシップ内でメンバーシップを変更するステップと、
    前記ゾーン制御ウェブページを前記ウェブサーバに返送するステップと、
    前記ウェブサーバにより、前記メンバーシップの変更のためのオーダメッセージを前記ゾーンサーバ又はゾーンサーバアプリケーションへ送信するステップと、
    前記ゾーンサーバ又はゾーンサーバアプリケーションにより、前記オーダメッセージを受信し及び前記オーダメッセージに従って前記グループのメンバーシップを変更するステップと、
    を含む方法。
13. 携帯加入者のための少なくとも１つの定義されたゾーンと着呼トリガとを有する前記携帯加入者の位置レポートを受信するためのゾーンサーバ（Ｃ）であって、ＭＡＰインタフェースコントローラ（１０１）を介するホームロケーションレジスタに向けてのＭＡＰインタフェースと、ＣＡＰインタフェースコントローラ（１０２）を介する移動体サービス交換局（ＭＳＣ）に向けてのＣＡＰインタフェースとを有し、
    前記ゾーンサーバは、
    ゾーンベース（１０５）に接続され、受信される前記位置レポートに基づいて、携帯加入者の前記少なくとも１つの定義されたゾーンの最も近いゾーンと、前記最も近いゾーンの外部及び前記最も近いゾーンの周囲の円形の外周の内部における前記携帯加入者のプレゼンスとを判定するための計算部（１０４）と、
    携帯加入者の前記少なくとも１つの定義されたゾーン及びプレゼンス、並びにプレゼンス情報を発呼者が受信することについての許可を記憶するためのゾーンベース（１０５）と、
    前記ゾーンベース（１０５）に接続され、発呼者がプレゼンスを受信すべきかをチェックし、呼を完了するためのオプションを含む前記発呼者のためのアナウンスメントを組み立て、並びに、受信された前記着呼トリガに基づいて前記発呼者から選択されたオプションを解析し及び実行するための決定機能（１０３）と、
    をさらに備えることを特徴とする、ゾーンサーバ。
14. 前記決定機能（１０３）及びイベントベース（１０７）に接続され、前記決定機能からの未来のイベントトリガを受信し、前記未来のイベントトリガを解析し、前記イベントベース内に未来のイベントを記憶し、実行すべき未来のイベントについて前記イベントベースをスキャンし、当該未来のイベントを実行するためのイベントマネージャ（１０６）と、
    実行すべき未来のイベントを記憶するためのイベントベース（１０６）と、
    をさらに備える、請求項１３に記載のゾーンサーバ。
15. 前記決定機能（１０３）は、携帯加入者から前記ＣＡＰインタフェース（１０２）を介して知的ネットワーク（ＩＮ）サービス呼を受信し、受信される前記ＩＮサービス呼に基づいて発呼者についての前記許可を判定し、前記ゾーンベース（１０５）内に当該許可を記憶するために特別に適合されることをさらに特徴とする、請求項１３又は請求項１４に記載のゾーンサーバ。
16. 前記決定機能（１０３）は、携帯加入者からの許可オーダメッセージを受信するためのインターネットプロトコル接続を有し、前記許可オーダメッセージに基づいて前記ゾーンベース内に記憶されているプレゼンス情報を発呼者が受信することについての許可を更新するように特別に適合されることをさらに特徴とする、請求項１３、１４又は１５に記載のゾーンサーバ。
17. 請求項１〜１２の１項に記載の方法を実行可能な、１つ以上のネットワークノード内に設けられる、ゾーンサーバアプリケーション。
18. 請求項１〜１２の１項に記載の方法を実行可能な、ソフトウェアアプリケーション。
19. 請求項１〜１２の１項に記載の方法を実行可能な、ソフトウェアアプリケーションを含むキャリア。

Images