JP2005502224A - 加入者グループへのサービスの提供 - Google Patents

Abstract

アドレスにより各々アドレス可能な通信ターミナルへサービスを提供するための通信システムにおいて、上記ターミナルへサービスを提供するサービス提供ユニットと、サービスの指示を記憶するサービスフィールドと、１つ以上のターミナルのアドレスを指定する表現を記憶するアドレスフィールドとを各々含む１組のサービス提供定義を記憶するためのサービスデータ記憶ユニットと、システム内で通信を受信し、通信に指定されたアドレスを各サービス提供定義のアドレスフィールドに記憶された表現と比較し、そしてその比較に基づいて、上記サービス提供ユニットが、上記アドレスで識別されるターミナルへサービスを提供するようにさせるサービスロジックユニットとを備えた通信システム。

Description

【技術分野】
【０００１】
本発明は、通信システムにおけるサービスの提供に係り、より詳細には、加入者グループへのサービスの提供に係る。
【背景技術】
【０００２】
移動電話ネットワークのような通信システムのオペレータは、システムの加入者にサービスを提供することができる。個々の加入者は、異なるサービスに対して支払するように選択することができる。更に、サービスは、それらサービスに対して共同で契約した結果として、或いは例えば、加入者のグループに向けられるプロモーションとして、加入者のグループに提供することができる。このようなサービスは、必ずしもそうではないが、通常は、インテリジェントネットワーク構成体により提供される。
【０００３】
あるサービスの提供は、加入者ターミナルからのコールにより開始される。これらサービスの例は、天気レポート及びｅ−メールの送信である。他のサービスの提供は、加入者ターミナルへのコールにより開始される。これらサービスの例は、コール転送及び音声メールである。
【０００４】
コールがネットワークにより処理されるときには、ネットワークは、そのインスタンスにおいて当該サービスを提供できるかどうか判断しなければならない。これを行うために、当該加入者がサービスを受信することが許されたかどうかチェックしなければならない。これを行う１つの方法は、加入者に対して記憶された口座詳細に問合せすることである。しかしながら、このシステムが採用された場合には、加入者のグループに付加的なサービスを提供するか又は拒絶するようにシステムを構成することが非常に不便である。というのは、グループ内の各加入者の口座詳細を変更しなければならないからである。例えば、プロモーションオファーとして、会社は、加入者のグループにサービスへのアクセスを短時間与えることを希望する。上述した構成においては、サービスの提供を許すためにグループ内の全加入者の口座を変更しなければならず、そしてプロモーションが終了すると、サービスを拒絶するためにそれらを再び変更しなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従って、どの加入者にサービスを提供するか決定するための改良されたシステムが要望される。
【課題を解決するための手段】
【０００６】
本発明の１つの特徴によれば、アドレスにより各々アドレス可能な通信ターミナルへサービスを提供するための通信システムにおいて、ターミナルへサービスを提供するサービス提供ユニットと、サービスの指示を記憶するサービスフィールドと、１つ以上のターミナルのアドレスを指定する表現を記憶するアドレスフィールドとを各々含む１組のサービス提供定義を記憶するためのサービスデータ記憶ユニットと、システム内で通信を受信し、通信に指定されたアドレスを各サービス提供定義のアドレスフィールドに記憶された表現と比較し、そしてその比較に基づいて、サービス提供ユニットが、上記アドレスで識別されるターミナルへサービスを提供するようにさせるサービスロジックユニットとを備えた通信システム。
【０００７】
好ましくは、上記サービス提供定義の少なくとも１つは、２つ以上のターミナルのアドレスを指定する表現を記憶する。最も好ましくは、上記表現は、ワイルドカード表現である。それとは別に又はそれに加えて、上記表現は、アドレス又はワイルドカード表現のリストの形態をとる。上記表現は、１組の数字的に連続するアドレスを定義するのが適当であり、各々の第１部分が同じである１組のアドレスを定義するのが最も好ましい。
【０００８】
各アドレスは、番号であるのが適当である。例えば、各アドレスは、ＭＳＩＳＤＮであるか又はそれを含む。
上記通信は、例えば、音声及び／又はテキスト及び／又はビデオ通信である。
上記ターミナルは、移動ステーションである。
上記サービス提供ユニットは、サービスを提供することができ、コールの料金の一部分又は全部が、ターミナルの加入者とは個別のスポンサー当事者に向けられるのが好ましい。このように、ある個人が便利にもコールの料金のスポンサーとなることができる。
【０００９】
サービスロジックユニットは、上記アドレスがいずれかのサービス提供定義のアドレスフィールドに記憶された表現に一致する場合に、サービス提供ユニットがその定義に指示されたサービスを提供するようにさせるのが適当である。或いは又、サービスロジックユニットは、上記アドレスが２つ以上のサービス提供定義のアドレスフィールドに記憶された表現に一致する場合に、これら定義に指示されたサービスを所定のルールに従って優先順位決めし、そしてこれらのルールに基づいて、サービス提供ユニットがこれら定義に指示されたサービスのサブセットを提供するようにさせる。又、サービスロジックユニットは、サービス提供ユニットがその定義に指示された１つ又は複数のサービスを通信の当事者に提供するようにさせる。
【００１０】
サービスロジックユニットは、通信の発信当事者のアドレスを、各サービス提供定義のアドレスフィールドに記憶された表現と比較し、そしてこの比較に基づいて、サービス提供ユニットが上記アドレスで識別されたターミナルへサービスを提供するようにさせる。上記アドレスは、Ａ番号である。
サービスロジックユニットは、通信の着信当事者のアドレスを、各サービス提供定義のアドレスフィールドに記憶された表現と比較し、そしてこの比較に基づいて、サービス提供ユニットが上記アドレスで識別されたターミナルへサービスを提供するようにさせる。上記アドレスは、Ｂ番号である。
上記通信システムは、ＧＳＭ規格又はそこから派生する規格に従うのが好ましい。
【発明を実施するための最良の形態】
【００１１】
以下、添付図面を参照して、本発明を一例として詳細に説明する。
本発明は、ＧＳＭ（移動通信用のグローバルシステム）システムを参照して説明するが、このようなシステムに限定されない。ＧＳＭシステムでは、あるターミナルから別のターミナルへコールがなされるときに、発呼ターミナルの番号をＡ番号と称し、そして被呼ターミナルの番号をＢ番号と称する。ＧＳＭシステムでは、この形式の「番号」は、「長番号」の一部分としてコールにおいて搬送されるＭＳＩＳＤＮ番号である。他のシステムでも、同様の加入者識別が使用される。
【００１２】
コールがなされるときには、コールデータは、Ａ番号及びＢ番号を含む。それ故、これらの番号は、コールの結果としてサービスを提供すべきかどうか決定するための分析に使用できる。
図１は、本発明による通信システムを示す。このシステムは、一般的に６で示されたネットワーク側ユニットとワイヤレス通信することのできる多数のターミナル１−５を備えている。ネットワーク側ユニットは、ＭＳＣ（移動交換センター）７と、少なくとも１つのサービス提供ユニット８と、サービス制御ブロック９とを備えている。このサービス制御ブロックは、サービスデータベース１０及びサービスロジックユニット１１を備えている。サービス制御ブロックは、ＭＳＣ７に接続されてＭＳＣからコールデータを受信すると共に、サービス提供ユニット８に接続されて、このサービス提供ユニットがサービスを提供するようにさせる。
【００１３】
ＭＳＣ７がコールを受け取り、それに応答してサービスを提供する必要があるときには、コールのデータがサービス制御サブシステムへ送信される。このデータは、Ａ及びＢ加入者番号の少なくとも１つを含む。サービス制御サブシステムでは、サービスデータベースが、どのターミナルにどのサービスを提供するかを定義する１組の定義を記憶する。各定義は、それに関連したサービス（又は２つ以上のサービス）の指示と、１つ以上の加入者番号を指示する表現とを含む。加入者番号は、定義における表現に対してテストされ、コール（例えば、音声メール）に対して又はコール（例えば、天気レポート）に応答してサービスを提供するかどうか決定する。定義が、サービスを提供できることを指示する場合には、サービス制御サブシステムがサービス提供ユニットにサービスの提供を許可する。２つ以上のサービスを提供できる場合には、それらが所定のハイアラーキーに基づいて優先順位決めされ、従って、一致した全てのサービスを提供しなくてもよい。
【００１４】
ある表現は、２つ以上の加入者番号を指示できるので、ターミナルのグループへのサービスの提供を許すようにサービス制御サブシステムを構成するのは容易である。
本発明の実施について、以下に詳細に説明する。この実施は、ＶＰＮ（バーチャルプライベートネットワーク）又はＰＢＸ（プライベートブランチ交換機）に対応するサービスの割り当てに上記原理を適用することを示す。ＶＰＮ又はＰＢＸ内の加入者番号は、他のデジット（通常は最終デジット）で識別されるＶＰＮ又はＰＢＸ内の特定番号と共通したデジット（通常は初期デジット）をしばしば有する。このようなグループを定義するサービス定義に対する表現を形成するのは、特に容易である。というのは、この定義は、共通のデジットを参照すればよいからである。更に複雑な定義の形態を使用して、非連続番号のグループを定義できることも明らかであろう。ＶＰＮ又はＰＢＸに関係しないグループを定義することができる。
【００１５】
好ましい実施形態では、少なくとも１つの定義は、２つ以上の加入者番号を指定する表現を含む。２人以上の加入者を指定する１つの簡単な方法は、ワイルドカードを表現に使用することである。従って、表現「＋３５８４０」は、全てが＋３５８４０で始まる番号のグループ、例えば、＋３５８４０１２３４５及び＋３５８４０９８７６５を指定する。番号の連続グループを表現する別の方法は、グループの最も上の番号と最も下の番号を指定することである。或いは又、番号及び／又はワイルドカード表現のリストとしてグループを指定することもできる。
【００１６】
サービス定義が、Ａ及びＢ番号の一方又は両方に基づいて２つ以上のサービスを提供することを指示する場合には、所定の１組の優先順位に基づいてそれらサービス間で選択が行われる。例えば、コールに対して複数の料率を適用できることを分析が示す場合には、それらの料率の最低のものをコールに適用すべきであることを優先順位が指示してもよい。
【００１７】
ある環境においては、割引料率のようなサービスは、Ａ及びＢ加入者の両方が共通グループのメンバーである場合しか適用できない。その一例は、会社がその従業員間のコールに割引料率を構成した場合である。
この説明は、「ＶＰＮ大番号レンジ／ＰＢＸサポート」特徴をサポートするための特徴実施原理をカバーする。この特徴は、番号レンジにＩＮサービスを提供できると共に、行先番号／アドレスの不完全なデジットを送信することがあり又は行先デジットがアドレスの初期デジットを越えて遅延されることのあるＰＢＸにより発信されるコールに対して性能を改善することができる。
【００１８】
ＶＰＮは、市場において益々広範囲に利用されるＩＮサービスとなっている。ＶＰＮサービスは、通常、数千の加入者にサービスするＰＢＸを有する法人顧客をターゲットとするものである。これは、全てのＰＢＸ内線番号がＶＰＮサービスを受けるべきときに、公知解決策では、全ての内線番号に１つづつサービスを提供する必要があることを意味する。これは、ルーティングに長い時間を要すると共に、アドレスデータベースにスペースを必要とする。本発明の特徴は、全ＰＢＸに対し又はＰＢＸのドメインにおけるある番号レンジに対してＶＰＮサービスを提供するのに１つのエントリーだけで良いようにする。
【００１９】
この説明において、サブシステムという語は、それ自身の個別に定義できるファンクションを有するシステムの一部分を指す。サブシステムは、プログラムブロックに更に分割することができる。短番号表示７４＊又は７４は、短番号レンジを指示する（短番号のスタートデジットによる）。長番号表示３５８３２５７４＊又は３５８３２５７４は、ディレクトリー番号レンジを指示する（ディレクトリー番号のスタートデジットによる）。
【００２０】
本発明の特徴は、現在のＩＮ概念に対する拡張を表わす。この拡張は、番号レンジを加入者とみなすようなものである。従って、個々の加入者に対して実行できる全てのオペレーションは、番号レンジに対しても実行できる。より効率的なサーチアルゴリズム、及びグループメンバー番号のより特定の構成により、性能改善が達せられる。
【００２１】
番号レンジは、この番号レンジが番号変換ルールを含むことを除くと、グループにおいてグループメンバーとして定義される。この番号変換ルールでは、短番号のプレフィックスに基づいて長番号を分析し、そしてそれとは逆に分析することもできる。以下の例は、番号変換の考え方を示す。
７７０００から７７９９９までの短番号を有するＰＢＸがある。これら短番号は、７７０００が３５８３２５７７０００へ変換され、７７００１が３５８３２５７７００１へ変換され、等々のように、長番号へ各々変換される。長番号も、同様に、短番号へ各々変換される。従って、番号変換は、次の通りである。
７７ ←→ ３５８３２５７７
短番号の長さが５で、例えば被呼短番号７７４０４である場合には、この番号が３５８３２５７７４０４に変換され、従って、７７が被呼番号の始めから切り取られ、残りが長番号の後に貼り付けられる。
【００２２】
図３は、ここに示す例によるシステムの基本的なアーキテクチャーを示す。本発明を実施するためのシステムの好ましい特徴は、次の通りである。
１．サービスロジックは、番号変換ルールに基づき番号レンジ内で短番号からディレクトリー番号を形成できねばならない。
２．サービスロジックは、番号変換ルールに基づき番号レンジ内でディレクトリー番号から短番号を形成できねばならない。
３．ディレクトリー番号により番号レンジ内でグループメンバーになされたコールがオンネットコールとして取り扱われることを定義できねばならない。
【００２３】
４．サービスロジックは、番号レンジに与えられるサービスを、サービスの優先順位及び通常の相互作用ルールに基づいて個々の加入者に与えられるサービスと同様に取り扱うことができねばならない。サービスは、常に、最も正確に探索された加入者番号に対して実行される。
５．加入者は、与えられた個々のサービス及び番号レンジサービスの両方を受けることができる。これらのサービスは、通常、優先順位及び相互作用ルールに基づいて取り扱われる。
６．同じサービスが個々の加入者及びその加入者を含む番号レンジに与えられる場合には、個々のサービスのみが実行される。
【００２４】
７．加入者が個々の及びある番号レンジ内のグループメンバーであると定義された場合には、個々の値のみが使用される（例えば、クラス情報）。個々のメンバーは、グループに存在しなければならず、そしてサービスは、この番号に与えられる必要がある。与えられるデータ及びグループメンバーデータから、常に、最も正確な番号が見つかる。
８．サービスロジックは、ワイルドカードで定義された番号レンジを取り扱うことができねばならない。ワイルドカードに置き換えられるデジットの最大数は、少なくとも４である。従って、番号レンジ３５８３２５７７＊は、次のものを含む。
３５８３２５７７０−３５８３２５７７９
３５８３２５７７００−３５８３２５７７９９
３５８３２５７７０００−３５８３２５７７９９９
３５８３２５７７００００−３５８３２５７７９９９９
ワイルドカードは、使用されない。同じ機能が依然達成される。置き換えできるデジットの数は、制限されない。
【００２５】
９．１つのグループ内に多数の番号レンジが重畳することはない。サブグループが存在し得る。一致する最も正確な番号レンジが使用される。
１０．加入者の言語が個々の加入者に対して定義されている場合には、サービス提供における番号レンジに対して与えられた言語に代わってそれが常に使用される。サービスは、個々の加入者に提供することが必要である。
１１．番号レンジの同じ取り扱いをＣＡＭＥＬサービスにも使用できねばならない。
【００２６】
１２．グループアドミニストレーターは、番号レンジのクラスを変更できねばならない。グループアドミニストレーターは、ｉＳＭＡＰ（インターネットイネーブルされるサービスマネージメントアクセスポイント）を経て番号レンジのクラスを変更することができる。
グループアドミニストレーターは、番号レンジの番号変換ルールにおける短番号部分を変更できねばならない。例えば、グループアドミニストレーターは、番号レンジの変換ルールを変更することができる。
Ｃｈａｎｇｅ：７７＊ → ３５８ ３ ２５７ ７＊
Ｔｏ：４５＊ → ３５８ ３ ２５７ ７＊
グループアドミニストレーターでは短番号しか変更できないように限定されねばならない。
【００２７】
１３．グループアドミニストレーターは、番号レンジの番号変換ルールにおいてディレクトリー番号部分を変更できてはならない。
１４．グループアドミニストレーターがグループ及びグループメンバーをブラウズするときには、個々の加入者と同様に、１つの番号レンジが１つのエントリーとして取り扱われる。
１５．グループアドミニストレーターによりなされた（例えば、クラスに基づいて）サーチの結果がある番号レンジであり、そしてその番号レンジ内に、個々のグループメンバーがそのサーチに対して含まれないような個々の定義を有する（例えば、その番号レンジ以外のクラスを有する）グループメンバーがいる場合には、グループアドミニストレーターに通知を与えて、そのアドミニストレーターが更に別の考えられるアクションを判断できるようにしなければならない。
【００２８】
１６．サービスプロバイダーは、提供及びグループ定義にワイルドカードを使用して番号レンジを定義することができねばならない。ワイルドカードと置き換えることのできるデジットの最大数は、少なくとも４である。従って、番号レンジ３５８３２５７７＊は、次のものを含む。
３５８３２５７７０−３５８３２５７７９
３５８３２５７７００−３５８３２５７７９９
３５８３２５７７０００−３５８３２５７７９９９
３５８３２５７７００００−３５８３２５７７９９９９
【００２９】
１７．サービスプロバイダーは、番号レンジをグループに追加しそして各番号レンジに対して個々の変換ルールを定義することができねばならない。１つのグループ内で各番号レンジに対して変換ルールが存在し得る。
１８．１つのグループ内に重畳する番号レンジを定義できてはならない。同じ番号レンジが多数の異なるグループ内のメンバーであってもよい。
１９．個々のグループメンバーを番号レンジと共に同じグループに追加できねばならない。個々のグループメンバーは、同じグループ内の番号レンジと重畳することができる。
【００３０】
２０．番号レンジは、グループを定義して取り扱うときに、個々のグループメンバーとして取り扱われる。
２１．番号レンジは、提供の際に、個々の加入者として取り扱われる。
２２．サービスプロバイダーは、個々の加入者、及び加入者を含む番号レンジに同じサービスを提供できねばならない。加入者がある個々のデータをもつべき場合には、その加入者に個々にサービスを提供しなければならない。
【００３１】
２３．サービスプロバイダーは、番号レンジ及び個々のサービスの両方を加入者に提供できねばならない。
２４．提供するサービスに拘りなく、重畳する番号レンジを使用できてはならない。
２５．番号レンジ内のグループメンバーは、常に、実際のグループメンバーである。番号レンジは、仮想グループメンバーが定義されるときには、使用することができない。仮想グループメンバーは、グループに１つづつ追加されねばならない。
【００３２】
サービスロジックは、番号レンジに提供されるサービスを取り扱うことができる。番号レンジは、加入者のように取り扱われる。番号レンジは、提供されるグループサービス又は個々のサービスを受けることができる。サブグループ及び個々の加入者には、番号レンジ内でサービスを提供することができねばならない。これは、「ＤｉｒｅｃｔｏｒｙＮｕｍｂｅｒ」及び「ＤｉｒＮｕｍＲａｎｇｅ」のテーブルから見出される最も正確な番号に対してサービスが常に実行されるようにして達成できる。例えば、番号レンジ（＝３５８３２５７７）である加入者Ａは、提供されたサービスＳ１を受ける。番号レンジ（＝３５８３２５７７１）であって、Ａのサブグループである加入者Ｂは、提供されたサービスＳ２を受ける。発呼加入者番号は、３５８３２５７７１０５であり、最も正確な番号レンジ３５８３２５７７１サービスＳ２が実行される。
【００３３】
ＤｉｒＮｕｍＲａｎｇｅテーブルは、サービスキーが値１のビット１７を含む場合だけ読み取られる。図４を参照して述べるように、トリガー動作が生じると、加入者のＰｒｏｖｉｓｉｏｎＩｄを次のように見出すことができる。
− 加入者は、発信サービスにおける発呼番号及び着信サービスにおける被呼番号でＤｉｒｅｃｔｏｒｙＮｕｍｂｅｒテーブルからサーチされる。このＤｉｒｅｃｔｏｒｙＮｕｍｂｅｒテーブルから番号が見つかった場合には、サービスロジックは、Ｊ４の場合のように実行を続ける。ＳｅｒｖｉｃｅＫｅｙに番号が見つからない場合には、１７ビットがチェックされる。１７ビットが値０である場合には、加入者は、ＩＮサービスを受けず、Ｊ４の場合のように処理される。
【００３４】
−１７ビットが値１である場合には、ＤｉｒＮｕｍｂｅｒＣｏｎｆＤａｔａが一次キー（１）で読み取られる。
−ＤｉｒＮｕｍｂｅｒＲａｎｇｅは、発呼又は被呼番号のデジットのＡｎａｌｙｓｉｓＭｉｎＬｅｎ量で読み取られる。
−一致する行が見つからない場合には、サービスロジックは、加入者がデータベースから見つからないときにＪ４の場合のように実行を続ける。
【００３５】
−一致する行が見つかった場合には、４ビットが値０であるかどうかについてＭｏｒｅＤｉｇｉｔｓＭａｓｋがチェックされ、従って、より多くのデジットをチェックする必要がある。次いで、現在デジット及びビット０−３のデジット値が、使用可能なデジット以下であるかどうかチェックされる。もしそうであれば、番号の長さが分かる。従って、ＭｏｒｅＤｉｇｉｔｓＭａｓｋの定義されたデジットに加算された現在デジットがＡｎａｌｙｓｉｓＭａｘＬｅｎより小さいことをチェックする必要がある。もしそうであれば、ＭｏｒｅＤｉｇｉｔｓＭａｓｋの定義されたデジットに加算された現在デジットで番号レンジをサーチすることができる。発呼又は被呼番号の長さがその定義されたものより短いか又はＡｎａｌｙｓｉｓＭａｘＬｅｎを越える場合には、サービスロジックは、加入者をデータベースから見つけられないときにＪ４のように実行を続ける。
【００３６】
−一致する行が見つかった場合には、４ビットが値１であるかどうかについてＭｏｒｅＤｉｇｉｔｓＭａｓｋがチェックされ、従って、この行は、潜在的番号レンジ加入者であり、それがメモリに記憶される。次いで、ビット０−３の値が０より大きいかどうかチェックされる。もしそうであれば、番号の長さが分かり、そのデジットの量を以前のサーチにおける現在デジット番号に追加して、ＤｉｒＮｕｍｂｅｒＲａｎｇｅテーブルから行を見つけることができる。
【００３７】
−一致する行が見つかった場合には、４ビットが値１であるかどうかについてＭｏｒｅＤｉｇｉｔｓＭａｓｋがチェックされ、従って、この行は、潜在的番号レンジ加入者であり、それがメモリに記憶される。次いで、ビット０−３の値が０より大きいかどうかチェックされる。もしそうでなければ、この行の番号は、番号レンジ加入者であり、サービスロジックは、個々の加入者とでＪ４のように実行を続ける。
【００３８】
一致する行がいったん見つかり、それがメモリに記憶され、そして更に深い番号レンジがサーチされて、見つからなかった場合には、その記憶された行が番号レンジ加入者情報を含み、そしてサービスロジックは、個々の加入者とでＪ４のように実行を続ける。
【００３９】
グループ及びグループメンバーのデータは、新たな構造を使用することを希望する場合には、新たなテーブルＧｒｏｕｐＣｏｎｆＤａｔａ、ＮｅｗＧｒｏｕｐＭｅｍｂｅｒ、ＭｅｍｂｅｒＡｎａｌｙｓｉｓ及びＳｈｏｒｔＮｕｍｂｅｒＡｎａｌｙｓｉｓに記憶される。グループ及びグループメンバーは、ＧｒｏｕｐＣｏｎｆＤａｔａから当該ＧｒｏｕｐＩｄで行が見つけられる場合にのみ、これらの新たなテーブルに存在し得る。ＧｒｏｕｐＩｄは、加入者が見つかった後にＳｅｒｖｉｃｅｓＯｆＳｕｂｓｃｒｉｂｅｒテーブルから従来のやり方で見つけることができる。最も正確な番号は、短番号及びディレクトリー番号と共にサービス提供データ及びグループメンバーデータから見つけられる。
【００４０】
図５−８は、発呼者又は被呼者がグループのメンバーであるかどうかをいかにチェックするか示す。
図５を参照すると、
−ＳｅｒｖｉｃｅｓＯｆＳｕｂｓｃｒｉｂｅｒテーブルから見つかったＧｒｏｕｐＩｄを一次キーとして使用して、ＧｒｏｕｐＣｏｎｆＤａｔａが読み取られる。行が見つからない場合には、どのサービスを提供すべきか決定するための従来の技術を使用することができる。行が見つかった場合には、コンフィギュレーションデータが読み取られ、後で使用するために記憶される。
−次いで、ＯＢＣＳＭにおいてサービスがスタートしたかどうかチェックされる。もしそうでなければ、メンバー分析においてサーチが続けられる。もしそうであれば、Ｂ番号が分析される。
−Ｂ番号の分析は、発呼者が移動ステーションである場合に被呼番号を国際フォーマットで返送し、そして確実さのために番号が長い場合には情報を返送しなければならない。（確実さのための長いものは、例えば、ＭＳＣ／ＳＳＰから国際フォーマットで受信される番号である。）
【００４１】
−次いで、番号が確実さのために長いかどうかチェックされる。もしそうでなければ、考えられる短いものにおいて分析が続けられる。もしそうであれば、強制オンネット短番号サービスパラメータＦＤＥがサービスに対して選択されるかどうかチェックされる。もしそうでなければ、コールがオフネットコールであり、この特徴は、もはや番号に関心のないものである。もしそうであれば、メンバー分析において分析が続けられる。
−メンバーが短番号及びメンバー形式（実際の又はそうではない）で見つかった場合には、考えられる短いものが情報を返送する。
【００４２】
−メンバーが短いもので見つからない場合には、実行が強制オンネット短番号の使用のチェックに戻る。
−メンバーが見つかった場合には、メンバーが実際のものかどうかのチェックが行われる。メンバーが実際のものである場合は、コールがオンネットコールであると解釈され、使用される短番号及びその情報が、必要なポイントで見つかったメンバーに転送される。
−メンバーが見つからずそしてメンバーが実際のものでない場合には、コールが仮想メンバーへのコールであると解釈され、短番号及びその情報が、必要なポイントで見つかったメンバーに転送される。
【００４３】
図６は、考えられる短番号サーチを示し、これを以下に説明する。
−先ず、発呼者が移動ステーションであるかどうかチェックされる。
−もしそうであれば、ＩｎｉｔｉａｌＤｐで受け取られた被呼番号を使用してＮｅｗＧｒｏｕｐＭｅｍｂｅｒテーブルが読み取られる。メンバーが見つかった場合には、メンバーのメンバー形式がチェックされ、そして短いもので見つかった情報が返送される。そうでなければ、３の場合のように継続される。
−次いで、ＳｈｏｒｔＭｉｎＬｅｎが使用可能なデジット以下であるかどうかチェックされる。もしそうでなければ、要求されたデジットがスイッチから求められる。デジットが受け取られた後に、４において実行が続けられる。
【００４４】
−もしそうであれば、ＳｈｏｒｔＭｉｎＬｅｎ定義量デジットを一次キーとして使用することによりＳｈｏｒｔＮｕｍｂｅｒＡｎａｌｙｓｉｓテーブルが読み取られる。
−一致する行が見つかった場合には、４ビットが値０であるかどうかについてＭｏｒｅＤｉｇｉｔＭａｓｋがチェックされ、次いで、更なるデジットをチェックする必要がある。次いで、現在のデジット及びビット０−３のデジット値が使用可能なデジット以下であるかどうかチェックされる。もしそうであれば、番号の長さが分かる。次いで、現在デジット＋ＭｏｒｅＤｉｇｉｔが使用可能なデジット以下であるかどうかチェックする必要がある。もしそうであれば、ＭｏｒｅＤｉｇｉｔＭａｓｋに定義されたデジットに加算された現在デジットで番号レンジをサーチすることができる。もしそうでなければ、更なるデジットは、スイッチから求められない。
【００４５】
−一致する行が見つかった場合には、４ビットが値１であるかどうかについてＭｏｒｅＤｉｇｉｔＭａｓｋがチェックされ、次いで、この行は潜在的な番号であり、これがメモリに記憶される。次いで、ビット０−３の値が０より大きいかどうかチェックされる。もしそうであれば、番号の長さが分かり、そのデジットの量を以前のサーチにおける現在デジット番号に追加して、ＮｅｗＧｒｏｕｐＭｅｍｂｅｒテーブルから行を見つけることができる。
【００４６】
−一致する行が見つかった場合には、４ビットが値１であるかどうかについてＭｏｒｅＤｉｇｉｔＭａｓｋがチェックされ、次いで、この行は潜在的な番号であり、これがメモリに記憶される。次いで、ビット０−３の値が０より大きいかどうかチェックされる。もしそうでなければ、この番号が一次キーとして使用されて、ＮｅｗＧｒｏｕｐＭｅｍｂｅｒからメンバーが見つけられる。
【００４７】
−一致する行がもう一度見つかると、それがメモリに記憶され、そして更に深い番号レンジがサーチされ、それが見つからないと、記憶された行がメモリ内に番号を含み、これを一次キーとして使用して、ＮｅｗＧｒｏｕｐＭｅｍｂｅｒから番号を見つける。
−メンバーが見つかった場合には、短番号の長さがＳｈｏｒｔＮｕｍＬｅｎに等しいことがチェックされる。もしそうであれば、この番号は、メンバー及びメンバーのメンバー形式であり、短いもので見つかった情報が返送される。もしそうでなければ、これは、短番号でなく、そして見つからず且つ実際のものでないことが返送される。
【００４８】
変換及びＣＬＩ変更については、グループメンバーが見つかったときに、グループメンバーは、メンバーの番号レンジも見つけることができねばならない。これらの番号レンジは、ディレクトリー番号から短番号への及びそれとは逆の変換ルールを有する。この変換ルールは、データベーステーブルＮｅｗＧｒｏｕｐＭｅｍｂｅｒに定義され、変換ルールが存在するかどうか定義するフィールドＩｓＴｒａｎｓｌａｔｉｏｎがある。変換ルールそれ自体は、フィールドＮｕｍｂｅｒ（短番号）、ＬｏｎｇＮｕｍｂｅｒ（番号レンジ）及びＳｈｏｒｔＮｕｍＬｅｎに情報を含む。Ｎｕｍｂｅｒフィールドは、短番号のどの部分がＬｏｎｇＮｕｍｂｅｒの情報と置き換えられるか定義する。ＳｈｏｒｔＮｕｍＬｅｎフィールドは、短番号の長さを通知し、従って、正しい長さの番号だけが短から長に変換されることを定義し、そしてＬｏｎｇＮｕｍＬｅｎは、長番号に対して同じことを定義する。例えば、次のデータをデータベースから見つけることができる場合には、

−ＶＰＮグループメンバーＡが、７４２３４でグループメンバーＢにコールする。
−Ｂがグループメンバーであることが分かる。被呼短番号が、データベースに定義されたものと同じ長さをもつことがチェックされる。
−開始部からの短番号７４２３４から、番号７４が除去され、そして残り（２３４）がＬｏｎｇＮｕｍｂｅｒの終了部に貼付される。番号の長さが１１であることがチェックされる。
−従って、接続内の番号は、３５８３２５７４２３４である。
【００４９】
図８は、更に一般的な図である。
常に、最も正確なディレクトリー番号又はディレクトリー番号レンジを、その加入者に対するＰｒｏｖｉｓｉｏｎＩｄと一緒に見つけるのが非常に好ましい。番号レンジは、加入者として処理され、そして加入者テーブルにおける加入者の全ての情報を有する。
【００５０】
実施に関して、基本的な考え方は、各番号レンジが個々の加入者又はグループメンバーとしてみなされ、加入者又はグループ番号に関して実行できる全てのことは、番号レンジに関して実行できねばならない。ツールキットツールは、古いデータベース構造及びこの新しい構造の両方をサポートしなければならない。グループメンバーは、同じＳＣＰ内の両構造に属することができ、従って、当然、グループメンバーは、２つの異なるグループのメンバーでなければならない。同じグループのメンバーは、古い構造又は新しい構造の一方にしか属することができず、両方に属することはできない。サービスは、常に、最も正確な番号に対して実行され、そしてグループメンバーは、常に、考えられる最も正確な番号で見つけられる。
【００５１】
サービスプロバイダーが番号レンジでグループを形成したいときには、最初に、コンフィギュレーションデータを記憶することができる。次いで、番号レンジのグループメンバーが１つの行エントリーとして入力され、グループメンバーの全ての古いデータが、当然、例えば、次のように入力される。

【００５２】
グループメンバーがリストされ／ブラウズされるときには、番号レンジが１つのエントリーとしてみなされる。ＳＭＩは、必要なデジットを分析テーブルに挿入する処理をしなければならない。グループがセーブ後にブラウズされるときには、最も正確なメンバーがリストの最上部になければならない。
サービスプロバイダーは、番号レンジにサービスを提供できねばならない。重畳する番号レンジが存在でき、同じ番号レンジが、個々の加入者のような１つのＰｒｏｖｉｓｉｏｎＩｄのみで存在できる。発信サービス及び着信サービスは、番号レンジ加入者に提供できるが、ユニバーサルアクセス又は位置更新サービスは提供できない。
【００５３】
番号レンジを提供できる前に、ＤｉｒＮｕｍｂｅｒＣｏｎｆＤａｔａをコンフィギュレーションしなければならない。これは、提供ツールで行うことができ、このコンフィギュレーションを実行するのは、ネットワークオペレータしか許されない。このコンフィギュレーションデータは、提供の前に必要とされる。というのは、このデータは、ギャップが生じないようにデータベースを充填することが必要だからである。
【００５４】
サブグループ又は個々の加入者が、それらサブグループ又は個々の加入者が属する番号レンジに提供されるサービスとは異なるサービス又は異なる提供値を有することを希望する場合には、これらサービスは、サブグループ又は個々の加入者に個々に提供されねばならない。例えば、番号レンジ３５８３２５７７がサービスＳ１を有し、そして個々の加入者３５８３２５７７０６６がサービスＳ１において異なる通知を有する必要がある場合には、このサービスＳ１をこの個々の加入者に提供しなければならず、そしてこの個々の加入者は、番号レンジの提供データの変化で何ら影響されない。
【００５５】
ＳＭＩは、必要なデジットを分析テーブルに挿入する処理をしなければならない。加入者がセーブ後にブラウズされるときには、最も正確なメンバーがリストの最上部になければならない。
ＳＭＡＰ（サービスマネージメントアクセスポイント）ウェブサブシステムが設けられてもよい。このとき、グループに関する新たな情報を、ＳＭＡＰウェブを経て入力できるのが好ましい。全ての情報をＧｒｏｕｐＣｏｎｆＤａｔａテーブルに入力できねばならない。グループが、このＶＰＮ大番号又はＰＢＸサポート機能を使用したい場合には、グループ番号がグループに入力される前に判断されねばならない。従って、このグループに新たな構造が使用されるか古い構造が使用されるかの選択が存在しなければならない。又、グループコンフィギュレーションデータは、グループメンバーを入力する前に入力されねばならない。というのは、ギャップを回避するためにＭｅｍｂｅｒＡｎａｌｙｓｉｓ及びＳｈｏｒｔＮｕｍｂｅｒＡｎａｌｙｓｉｓテーブルに必要なデジットが充填され、そしてコンフィギュレーションデータがそこに使用されるからである。このようにギャップが回避されると、有効なサービスロジック機能が確保される。ギャップが存在する場合には、サービスロジックにおいてグループメンバーをサーチしても、上述したように機能しない。ｉＳＭＡＰは、古いデータベース構造及びこの新しい構造の両方をサポートしなければならない。グループメンバーは、同じＳＣＰの両構造に属することができ、従って、当然、グループメンバーは、２つのグループのメンバーでなければならない。同じグループのメンバーは、古い構造又は新しい構造の一方にしか属することができず、両方に属することはできない。
【００５６】
本発明は、ここに暗示的に又は明確に開示した特徴又は特徴の組合せ、或いはそれを一般化したものを包含することが明らかであろう。以上の説明に鑑み、当業者であれば、本発明の範囲内で種々の変更や修正がなされ得ることが明らかであろう。
【図面の簡単な説明】
【００５７】
【図１】本発明による通信システムを示す図である。
【図２】大番号のレンジの重畳を示す図である。
【図３】システムの相互作用を示す図である。
【図４】加入者のＰｒｏｖｉｓｉｏｎＩｄのサーチを示す図である。
【図５】グループメンバーサーチを示す図である。
【図６】考えられる短番号サーチを示す図である。
【図７】メンバー分析プロトコルを示す図である。
【図８】番号変換のためのメンバー探索プロセスを示す図である。

Claims (18)

1. アドレスにより各々アドレス可能な通信ターミナルへサービスを提供するための通信システムにおいて、
   上記ターミナルへサービスを提供するサービス提供ユニットと、
   サービスの指示を記憶するサービスフィールドと、１つ以上のターミナルのアドレスを指定する表現を記憶するアドレスフィールドとを各々含む１組のサービス提供定義を記憶するためのサービスデータ記憶ユニットと、
   上記システム内で通信を受信し、通信に指定されたアドレスを各サービス提供定義のアドレスフィールドに記憶された表現と比較し、そしてその比較に基づいて、上記サービス提供ユニットが、上記アドレスで識別されるターミナルへサービスを提供するようにさせるサービスロジックユニットと、
   を備えた通信システム。
2. 上記サービス提供定義の少なくとも１つは、２つ以上のターミナルのアドレスを指定する表現を記憶する請求項１に記載の通信システム。
3. 上記表現は、ワイルドカード表現である請求項２に記載の通信システム。
4. 上記表現は、１組の数字的に連続するアドレスを定義する請求項２又は３に記載の通信システム。
5. 上記表現は、各々の第１部分が同じである１組のアドレスを定義する請求項２ないし４のいずれかに記載の通信システム。
6. 各アドレスは番号である請求項１ないし５のいずれかに記載の通信システム。
7. 各アドレスは、ＭＳＩＳＤＮであるか又はそれを含む請求項６に記載の通信システム。
8. 上記通信は、音声通信である請求項１ないし７のいずれかに記載の通信システム。
9. 上記ターミナルは、移動ステーションである請求項１ないし８のいずれかに記載の通信システム。
10. 上記サービス提供ユニットは、サービスを提供することができ、コールの料金は、ターミナルの加入者とは個別のスポンサー当事者へ向けられる請求項１ないし９のいずれかに記載の通信システム。
11. 上記サービスロジックユニットは、上記アドレスがいずれかのサービス提供定義のアドレスフィールドに記憶された表現に一致する場合に、上記サービス提供ユニットがその定義に指示されたサービスを提供するようにさせる請求項１ないし１０のいずれかに記載の通信システム。
12. 上記サービスロジックユニットは、上記アドレスが２つ以上のサービス提供定義のアドレスフィールドに記憶された表現に一致する場合に、これら定義に指示されたサービスを所定のルールに従って優先順位決めし、そしてこれらのルールに基づいて、上記サービス提供ユニットがこれら定義に指示されたサービスのサブセットを提供するようにさせる請求項１ないし１０のいずれかに記載の通信システム。
13. 上記サービスロジックユニットは、上記サービス提供ユニットがその定義に指示された１つ又は複数のサービスを通信の当事者に提供するようにさせる請求項１１又は１２に記載の通信システム。
14. 上記サービスロジックユニットは、通信の発信当事者のアドレスを、各サービス提供定義のアドレスフィールドに記憶された表現と比較し、そしてこの比較に基づいて、上記サービス提供ユニットが上記アドレスで識別されたターミナルへサービスを提供するようにさせる請求項１ないし１３のいずれかに記載の通信システム。
15. 上記アドレスは、Ａ番号である請求項１４に記載の通信システム。
16. 上記サービスロジックユニットは、通信の着信当事者のアドレスを、各サービス提供定義のアドレスフィールドに記憶された表現と比較し、そしてこの比較に基づいて、上記サービス提供ユニットが上記アドレスで識別されたターミナルへサービスを提供するようにさせる請求項１ないし１５のいずれかに記載の通信システム。
17. 上記アドレスは、Ｂ番号である請求項１６に記載の通信システム。
18. ＧＳＭ規格又はそこから派生する規格に従う請求項１ないし１７のいずれかに記載の通信システム。

Images