JP4088549B2 - 電気通信網における方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は一般に通信網内のデータ分配の分野に関するもので、特に複数のサービス提供者とサービス・イネーブラ（service enablers）が存在する通信網内の種々のサービスに関係する種々のデータの統合に関する。
【０００２】
【従来の技術】
これまでは、移動電話網（ＰＬＭＮ）や固定回路交換網（ＰＳＴＮ）やデータ通信網などの通信網は別個のシステムであった。電気通信網の特徴は垂直に統合されていることである。これはアプリケーションやサービスが転送技術に密接に結び付いていることを意味する。例えば、移動体システムＧＳＭは一組のサービスとアプリケーションを提供するが、その外観と利点と限界の少なくとも大部分は通信技術により与えられる。固定電話網（ＰＳＴＮ）はこのシステムに用いられる通信技術に密接に連結するサービスとアプリケーションの異なる集合を提供し、そのサービスの使用と概観の多くはＰＬＭＮにおける同様のサービスとは異なっている。使用者には同じように見えるサービスも、技術に密接に関係するので、異なる網では非常に異なる方法で実現される。
【０００３】
サービスと通信技術とが密接に関係していることも、網の運営者が使用者へのサービスの主要な提供者でもあったということの重要な理由であった。サービスを提供するには、網全体の知識とアクセスが欠かせない。垂直に統合された網を図１に示す。
【０００４】
多様化されたサービス（複合サービス）と、サービス提供者の間の競争を促進することの要求が高まっている。同時に、電気およびデータ通信網が発展した。新しい世代の通信システムはセルラ電話やＩＰに基づくデータ通信などの種々の通信技術を統合する。新しいシステムは、例えばアクセス層とコア層とサービス層を備える水平に層化されたものとして描かれることが多い。図２は層化された通信システムを示す。このシナリオでは、例えば運営者、サービス提供者、サービス・イネーブラ、コンテンツ提供者、アプリケーション（インターネット（Ｒ））サービス提供者などの既存および新規のプレーヤが相互に作用して多様なサービスを使用者に提供する。サービスは、網（サービス網２００）の形を有するサービス層内で提供され管理される。サービス網２００はコア網２１０と相互に作用し、一般にＩＰ構造を有して転送および交換機能を提供する。コア網から複数のアクセス網と通信することができる。アクセス網は、ＧＳＭやＵＭＴＳなどの種々の容量と特徴を持つセルラ・システム２２０や、固定電話（ＰＳＴＮ）２３０や、ＩＰに基づくデータ通信２４０や、ケーブルＴＶ２５０を含む種々の網でよい。サービス網２００は、好ましくはオープン構造（例えばオープン・サービス構造ＯＳＡ）とオープン・インターフェース（例えば、ＯＳＡアプリケーション・プログラム・インターフェースＡＰＩ）を有し、これにより多数のプレーヤは相互に作用して使用者にサービスを提供することができる。垂直に統合された網と層化された網との比較はエリクソン・レビュー（Ericsson Review）No.2, 2001に述べられている。
【０００５】
好ましくは提供されるサービスは、使用者の個人的な要求や、アクセス方法（移動体システムや、固定システムなど）や、アクセスする端末の特性（例えば移動体端末の容量など）や、加入方式などに従って調整してよい。例えばアクセス方法はサービス網内のサービスの実行に影響を与えるが、サービスを実行する多くの部分は、例えばアクセス方法に関わらず似ているかまたは同じである。したがって、サービス提供者は同じ「積み木（building blocks）」を用いて、異なる使用者用に調整した異なるサービスを構築することができる。積み木は、例えば電話番号サービスや、メッセージ・サービスや、位置決めツールなどである。サービス網の開放性と、２つ以上の特定のサービスに積み木を用いることが可能であることとが、運営者やサービス提供者やサービス・イネーブラなどのプレーヤと使用者とに、新しいサービスをそれぞれ開発し使用する魅力を与える重要な要因と見なされている。
【０００６】
提供されるサービスは、二人の移動体加入者の間に呼を設定するなどの基本的な電話サービスから、異なるアクセス網や１つ以上のインターネット・アプリケーションやセキュリティ・サービスが関わる複合サービスまでにわたる。複合サービスは、位置決めや、メッセージ交換や、電子商取引を用いるサービスを含んでよい。位置決めに基づくサービスは、例えば使用者の位置の近くにあるホテルを探すことである。かかるサービスは、移動***置決めセンタを介する移動体システムの位置決めツールや、或る地域内のホテルを探したり分類したりする１つ以上のインターネット・アプリケーションや、使用者（例えばＷＡＰ）の端末に表示するのに適したフォーマットに情報を変換するアプリケーションや、部屋の予約や支払いを容易にする電子商取引アプリケーションを用いることを含む。複合サービスの別の例は、いわゆるフリート管理（fleet management）に関係する。使用者の選択されたグループ内の個々の使用者の位置に関する情報が、そのグループ内の一人または全ての使用者に提供される。各使用者の位置は位置決めシステムにより与えられる。これにより、使用者はグループ内の全ての他の人の位置に関する最新の情報を得ることができる。この種のサービスは、例えば一群の配送車を管理するのに有用である。かかるサービスを提供し実行するには、種々のサブシステムの間の多数のインターフェースが必要である。種々のサービス・システムが種々のサービス・イネーブラから提供されるので、サービス網と、オープン構造と標準化されたインターフェースを有するサービス網が必要なことは明らかである。
【０００７】
【発明が解決しようとする課題】
サービス網内で多数のサービス提供者やイネーブラが多数のサービスを提供し、使用者が種々のアクセス網内に広がり、個人的なサービスや種々の支払い方法の要求が生じると、正しい使用者データの要求が高まり、そのデータに即座にアクセスすることが重要になる。今日の網では使用者に関係するデータは網全体に分散され、多くの場合に冗長な使用者データが記憶され、用いられている。データが分散して記憶されかつ冗長なので、使用者情報を検索し更新するのが困難である。使用者データが分散されている既存の網では、複合サービスの安定した機能性を実現し確保することは非常に困難である。使用者データが分散されていることの１つの欠点を、例えば位置決めサービスに基づく或る複合サービスへの加入を使用者が止める場合の例で示す。この場合、位置決めサービスを提供するサービス・システムからその加入者に関係する全てのデータが削除される。位置決めを用いる他の複合サービスをその使用者が利用したいと思っても、位置決めサービスを提供するサービス・システムからその使用者に関係するデータがすでに削除されているので、かかる他の複合サービスは重要な使用者関係データを持っていない。或る場合にはこの複合サービスを実行できないし、また或る場合には使用者データを網内の他の場所から検索できたとしても、複合サービスの実行が遅れたり、トラヒック負荷が増えたりする。
【０００８】
また、使用者はサービスに従って異なるＩＤ、名前、別名により識別される。例えば、従来の電話サービスでは使用者の電話番号が用いられ、電子メール通信に基づくサービスでは電子メール・アドレスが用いられ、カレンダに基づくサービスでは使用者の別名が用いられる。複合サービスは種々の識別手段を持つ使用者データにアクセスする必要があり、使用者データが分散されている場合は、全ての複合サービスが全ての使用者識別を記憶し更新する必要がある。
【０００９】
使用者データの現在の処理方法に伴う問題を要約すると次のようになる。
ａ） サービスに関係する使用者データに即座にアクセスすることができず、また完全な使用者データへのアクセスは非常に困難で時間がかかる可能性がある。
ｂ） １つのサービス・システムと別のサービス・システムとの関係を示す情報が容易に得られないので、例えば使用者データが変更された場合に他のサービス・システムにどのように影響を与えるかを知ることができない。
ｃ） 使用者データが分散されるため、また異なるサービス・システムの間の関係が分からないために、システム内のデータの一貫性が弱くなり、トラヒック負荷が増加する。
【００１０】
【課題を解決するための手段】
本発明が解決しようとする問題は、複合サービスおよび/または多数のサービスを提供するサービス網において、使用者および加入者データを記憶しアクセスして、データに即座にアクセスしまたデータの一貫性を保持するようにするための方法を提供することである。
この問題は、請求項１に定義される方法により解決される。
【００１１】
本発明の１つの実施の形態に係るシステムは、共通加入者／使用者データベースと、使用者および加入者の情報を含む加入者／使用者データ記録を提供する。加入者／使用者データ記録を構成するのは、加入者と使用者を識別する少なくとも１つの識別フィールドと、サービス網内で提供される複数のサービスから少なくとも１つの選択されたサービスを指定する少なくとも１つのサービス・フィールドである。ただし、この少なくとも１つの選択されたサービスは使用者または加入者が選択する。前記少なくとも１つのサービス・フィールドの少なくとも１つは加入者／使用者に関係するデータを連結するリンクを提供し、これは共通加入者／使用者データベースの外部に記憶される。このように、共通加入者／使用者データベースと加入者／使用者記録により、サービス網内の使用者および／または加入者データにアクセスするための単一アクセス点の設定が容易になる。
【００１２】
本発明の別の実施の形態では、加入者／使用者データ記録は少なくとも２つのサービス・フィールドで構成する。１つは、加入者が利用できるサービスの第１のグループを指定するサービス加入フィールドで、サービスの第１のグループ内のサービスはサービス網内で提供される前記複数のサービスから選択される。もう１つは少なくとも１つのサービス・アクティベーション・フィールド（service activation field）で、各サービス・アクティベーション・フィールドはサービスの第１のグループから選択された、使用者によって起動された（activated）サービスを指定する。サービス加入フィールドおよび／またはサービス・アクティベーション・フィールドは加入者／使用者に関するデータを連結するリンクを提供し、これは前記共通加入者／使用者データベースの外部に記憶される。
【００１３】
本発明に係る、サービス網内の使用者および加入者データを記憶し保持するデータ記録を構成するのは、加入者と使用者を識別する少なくとも１つの識別フィールドと、サービス網内で提供される複数のサービスから少なくとも１つの選択されたサービスを指定する少なくとも１つのサービス・フィールドである。ただし、この少なくとも１つの選択されたサービスは使用者または加入者が選択する。前記少なくとも１つのサービス・フィールドの少なくとも１つは加入者／使用者に関するデータを連結するリンクを提供し、これは共通加入者／使用者データベースの外部に記憶される。
【００１４】
本発明により、共通加入者／使用者データベースと使用者データ記録はサービス網内の使用者および加入者データにアクセスするための単一アクセス点を提供する。したがって使用者データへの迅速なアクセスが可能になり、使用者データは単一アクセス点だけを通してアクセスされまた必要であれば追加され更新され削除されるので、データの一貫性が達成される。
本発明の１つの実施の形態に係る方法は次のステップを含む。
・ 上に述べたシステムとデータ記録が提供するサービス網内の単一アクセス点にアクセスし、
・ 単一アクセス点にデータの読取りおよび／または書込みを要求し、
・ 単一アクセス点を介して使用者データ記録との間でデータの検索または転送を行う。
【００１５】
本発明に係る方法の１つの利点は、使用者／加入者データに対する全ての要求がサービス網内の１つの場所（単一アクセス点）に向けられることである。
本発明の別の利点は、データを連結するリンクと連結データにアクセスするのに必要な情報が、前記データを検索する本発明の方法を用いて本発明のシステムにより提供されることである。
【００１６】
定義
サービス網（ＳＮ）-- 通信システムの水平に層化された構造におけるサービス層に対応する。使用者サービスを提供するのに必要なノードと複数のサービス・システムはサービス網の一部と考える。正確にどのノードがサービス網に属すると見なされるかは実施の形態による。１つ以上の層／網に属するノードがあってよい。
サービス・システム-- サービスまたはサービスの一部を提供するシステム。サービス・システムは一般にサービス網に属する。サービス・システムは他のサービス・システムを用いて（通信して）特定のサービスを使用者に提供してよい。サービス・システムは１つ以上の異なるサービス、またはサービスのグループを提供してよい。
複合サービス-- 特定のサービスを使用者に提供するのに２つ以上のサービス・システムを関連させる必要のあるサービス。
【００１７】
【発明の実施の形態】
本発明の実施の形態について、図面を参照して以下に説明する。
本発明は、使用者に関係するデータが網内に分散するために生じる問題に対処するため、使用者に関係するデータのための単一アクセス点（Single Access Point：ＳＡＰ）をサービス網内に設ける。最高レベルのＳＡＰは共通加入者／使用者データベース（Common Subscriber-user Database：ＣＳＤ）と、ＣＳＤ内に記憶するデータ記録で構成する。データ記録は使用者に関係するデータを記憶し、使用者に関係するデータを記憶する他の記録にリンクする。相互に作用して複合サービスを形成する異なるサービス・システムの間の依存性も好ましくはＣＳＤ内に記憶する。ＣＳＤはサービス網２００からアクセス可能であり、一般にサービス網２００内に常駐する。
【００１８】
図３にＣＳＤの役割を示す。一般に複数のサービス・システムからアクセスされる使用者または加入者に関係するデータは、ＣＳＤ３００内に記憶される。またＣＳＤ３００内には、ＣＳＤ３００内に記憶される使用者データとＣＳＤ３００内に記憶されない使用者に関係するデータとを連結するリンクを記憶する。連結データと呼ぶこのデータは一般に或るサービスまたはサービスのグループに特有のものであり、特定のサービス・システムにだけ関連する。サービス・システムＡ３１０と、サービス・システムＢ３２０と、サービス・システムＣ３３０は、或るサービスまたはサービスのグループを提供するサービス網２００内のシステムの例である。リンクＡ３４０と、リンクＢ３５０と、リンクＣ３６０は、ＣＳＤ３００内のデータ記録が連結データにリンクすなわち参照項目を提供することを示す。共通使用者および加入者データはサービス・システムＡ３１０、またはＢ３２０、またはＣ３３０内に重複して記憶されるのではなく、ＣＳＤ３００内に記憶される。これにより一貫性が確保される。
【００１９】
複合サービスの場合は１つ以上のサービス・システム（例えば、サービス・システムＢ３２０とＣ３３０）を用いる必要があり、２つのシステムＢとＣの間の依存性はＣＳＤ３００内に記憶される。これをリンクＢ＋Ｃ３７０で示す。或る実施の形態では、例えばサービス・システムＡは電話番号サービスを提供し、サービス・システムＢは移動体端末の位置決めを提供し、サービス・システムＣは町の中のホテルやタクシーやレストランを探すインターネット・アプリケーションを提供をする。この場合、位置に基づくサービスを使用者に提供するにはサービス・システムＢとサービス・システムＣは相互に作用しなければならない。
【００２０】
或る実現されたサービス網では、サービス・システムの数は一般にここに示した数よりはるかに多く、システム間の依存性と相互作用は３システム以上を含む。したがって、上記は制限のない例と考えるべきである。サービスを提供するシステムの数やこれらのシステム間の複雑な依存性に関わらず、共通の使用者に関係するデータは重複して記憶されない。これによりデータの一貫性を確保することができる。ＣＳＤ内に記憶してデータの一貫性を可能にするデータ記録の構造について以下に詳細に説明する。
【００２１】
ほとんどの実施の形態において、ＣＳＤは非常に大きなデータベースである。なぜなら、サービス網が提供する複数のサービスを用いる使用者についての使用者関係データを含まなければならないからである。これは図４に示すように分散データベースを用いることにより対処することができる。ＣＳＤ３００のデータは種々のユニット内に含まれる複数のデータベース４００に分割される。ＣＳＤインデックス・テーブル（index table）４１０により、データベース４００内のデータの内部の分散を隠す。ＣＳＤインデックス・テーブル４１０は、データベースの１つを含むユニットの１つまたは別個のユニット内に記憶してよい。データベース４００とＣＳＤインデックス・テーブル４１０はＣＳＤフロントエンド４２０に接続する。ＣＳＤフロントエンド４２０とデータベース４００内に記憶されるデータ記録とを組み合わせてＳＡＰ４３０を形成する。ＣＳＤフロントエンド４２０は図の矢印で示す全てのデータの要求を受け、ＣＳＤインデックス・テーブル４１０を用いてデータベース４００からデータを検索する。外部からはＣＳＤ３００は１つのアクセス点を持つ１つのデータベースに見えるが、内部では多数の別個のデータベース４００を用いてよい。分散データベースの詳細な構造はこの技術で公知なのでこの明細書から省く。理解されるように、ここに説明するエンティティは論理エンティティと考えるべきものである。上に述べたようにデータベースは物理的に異なるユニットに分配して提供してよいが、ＣＤＳフロントエンド４２０やＣＳＤインデックス・テーブル４１０などの他のエンティティも、物理的に別個のユニットに分配することを含む多くの異なる方法で実現してよい。単一アクセス点ＳＡＰという用語は、概念的にサービス網内の使用者に関係するデータの論理的アクセス点という意味に理解すべきである。実際には、ＣＤＳフロントエンド４２０は多数の同時アクセスだけでなく、例えばＩＰアドレスやＨＴＭＬアドレスやＥ．１３６アドレスを用いることによるアクセス、またはＵＲＬによるアクセスを含む種々の手段や方法によるアクセスも処理する機能を有する必要がある。
【００２２】
ＣＳＤ３００内に記憶される使用者関係データは３つのエンティティの回りに構築される。３つのエンティティ（すなわち加入者と使用者とサービス）とそれらの関係を図５に示す。エンティティ加入者５１０はサービス網内で提供されるサービスの１つ以上の集合すなわちパッケージ５２５に加入する。加入者５１０は１つ以上の使用者５０５を所有する。使用者５０５はサービス５２０を活発に利用する。使用者は、加入者５１０が加入するサービスの集合５２５に属するサービスだけを使用することができる。使用者５０５は常に加入者５１０に属していなければならない。加入者５１０は常に一人以上の使用者５０５を所有する。多くの場合加入者５１０と使用者５０５は同じ人であるが、例えばビジネスの加入者の場合は、加入者は会社でよく、使用者はその会社の社員でよい。
【００２３】
概念的レベルでは、使用者と加入者とサービスを識別するデータと、これらのエンティティの間の関係の定義は、使用者データ・モデルと呼ぶデータ・モデルに従って構築される。使用者データ・モデルＵＤＭは実際の使用者関係データとサービス関係データだけでなく、使用者のサービスへの加入を含む。またサービス網内の重要な要素として活動して、連結データの記憶場所を絶えず参照することによりサービス内の使用者コンテキストの検索と管理を可能にするのはモデルである。本発明では、ＣＳＤ３００内に記憶される使用者関係データは使用者データ・モデルの原理に従って構築される。得られたデータ記録を使用者データ記録ＵＤＲと呼び、これはＣＳＤ３００内に記憶される。連結データの記憶場所への参照は、ＣＳＤ３００内の記録から、サービスを提供するシステムＡ３１０，Ｂ３２０，Ｃ３３０内に記憶されている使用者関係データの一部へのリンク３４０，３５０，３６０に対応する。ＵＤＲは別の種類のデータ（例えば、利用可能なサービスとその特徴に関する情報）へのリンクも含んでよい。
【００２４】
使用者データ・モデルの原理について、図６を参照して説明する。使用者データ記録ＵＤＲはＵＤＭの原理に従って構築される。ＣＳＤ３００内に記憶されるデータの構造は、データの内部複写を防ぎ、システムに正しく連結して最も論理的にサービスを提供しまた必要なデータを保持するように、慎重に設計しなければならない。データを論理的にグループ化することによりオブジェクトを作る。主要なオブジェクトは上に説明した主エンティティに対応する加入者と使用者とサービスである。図内の矢印はオブジェクトの間のリンクを示す。実施の形態はＣＳＤを構築するのに用いる技術に従って変わってよいが、論理的なグループ化は同じでなければならない。
【００２５】
好ましくは次のオブジェクトをＵＤＭ内に含むべきである。
・ 使用者６０５： 基本的な使用者情報（例えば、使用者識別）を含む。使用者６０５は常に加入者６１０に属する。
・ 加入者６１０： 基本的な加入者情報（例えば、加入者識別）を含む。
・ カストマ・セグメント６１５： 加入者６１０を分類するのに用いる。カストマ・セグメント記述と基本的データを含む。
・ 提供されるサービス６２０： サービスの基本的情報を含む。
・ サービス・パッケージ６２５： 提供されるサービス６２０をパッケージ化するのに用いる。
・ サービス・パッケージ加入６３０： 加入者６１０がサービス・パッケージ６２５に実際に加入したことを反映するのに用いる。
【００２６】
・ サービス加入６３５： サービス・パッケージ加入６３０の指定に従って加入者がサービス・パッケージ内の個別のサービス６２０に実際に加入したことを反映するのに用いる。
・ サービス・アクティベーション６４０： 使用者６０５がサービス加入６３５からの個別のサービスを実際に起動したことを反映するのに用いる。
・ 加入者共用資源６４５： 加入者６１０が加入した或るサービス内で用いられサービス加入６３５により指定される共用資源の基本的データを含む。共用資源は、他のサービス・システムによるサービスの実行を支援するのに必要なサービスを提供する任意のシステムである。
・ 使用者共用資源６５０： 使用者６０５が或る起動されたサービス６４０で用いる共用資源の基本的データを含む。この共用資源は他のサービス・システムによるサービスの実行を支援するのに必要な任意のシステムである。
【００２７】
使用者オブジェクト６０５と加入者オブジェクト６１０は識別オブジェクトの例である。オブジェクト・サービス加入６３５とオブジェクト・サービス・アクティベーション６４０はサービス・オブジェクトの例である。サービス網２００内に存在する全てのサービスはＵＤＭに知られている。加入者６１０が或るサービスに加入する。提供されるサービス・オブジェクト６２０は提供される全てのサービスについての情報を含み、他のシステム内に記憶されているサービスに関係するデータへの参照項目を保持する。好ましくは、複数のサービスに関する詳細なデータは共通サービス・データベース内に記憶する。共通サービス・データベースはサービスに関するより詳細な情報を含み、提供されるサービス・オブジェクト６２０の内容は使用者のために特化されたサービス情報を表す。これにより、提供されるサービス６２０をＣＳＤ３００と共通サービス・データベースとの間の接触点と見なすことができる。加入者６１０はサービスに１つずつ加入することもできるが、これでは準備が面倒になる。好ましくは、同様のサービス、または同じ加入者を引き付けそうなサービスをグループ化する。これはオブジェクト・サービス・パッケージ６２５に反映される。或るサービスは複数のサービス・パッケージで提供してよい。また或るサービス・パッケージを、同じ特徴と期待ニーズを持つ加入者のグループに提供してよい。このように加入者６１０をグループ化してカストマ・セグメント６１５を作り、加入者６１０は自分が属するカストマ・セグメントに提供される全てのサービスに加入してよい。或るサービスをカストマ・セグメントに追加するときは１つ以上のサービス・パッケージ６２５に含める。要するに、サービス・パッケージ６２５は提供されるサービス６２０をグループ化し、カストマ・セグメント６１５は加入者６１０をグループ化する。
【００２８】
加入者６１０はそのカストマ・セグメントに提供されるサービスに、個別のサービスの形ではなくサービス・パッケージ６２５の形で加入する。サービスを別個に提供する必要がある場合でも、サービス・パッケージ６２５に含めなければならない。オブジェクト・サービス・パッケージ加入６３０は加入者が加入するサービス・パッケージの情報を保持し、オブジェクト・サービス加入６３５は含まれる個別の提供されるサービス６２０に関する情報を保持する。これらは個別の使用者６０５に提供されるサービスである。使用者は加入者が加入する全てのサービスを用いてよいが、多くの場合、使用者はサービスを選択する。使用者によるサービスの選択はオブジェクト・サービス・アクティベーション６４０に含まれる。オブジェクト・サービス・アクティベーション６４０は連結データ（affiliate data）への参照項目（references）を含む。
【００２９】
複合サービスでは、例えば前に説明したホテルを予約する例のように、サービスを提供する２つ以上のシステムが関わる必要があることが多い。位置決めに基づくサービスは、一般に２つのシステム、移動***置決めセンタＭＰＣ（mobile positioning centre）と、移動体網（アクセス網）の使用者のプロフィールを記憶するホーム加入者サーバＨＳＳ（home subscriber server）とが関わる。ＭＰＣやＨＳＳなどのシステムは共用資源またはサービス・イネーブラの例である。オブジェクト加入者共用資源６４５と使用者共用資源６５０は複合サービスを提供する種々のシステムの間の依存性と、これらのシステムの連結データへの参照項目とを含む。依存性を指定することにより、１つのサービス・システムに必要なデータが別のシステムにより変更または削除されるのを防ぐことができる。例えば、別のサービス・システムがその複合サービスを実行するのに加入／アクティベーションを必要とする場合は、ＭＰＣを用いる１つのサービス・システムはＭＰＣの加入／アクティベーションを終了させる。
【００３０】
複数の複合サービスが用いる共用資源の別の例はカレンダである。種々の項目がどのようにして作成されたかに関わらず、使用者は一般に全ての項目を示す唯一のカレンダだけを希望する。上に述べたホテル予約の例では、ホテルを予約するサービスは好ましくはカレンダにもアクセスして自動的に予約を入れる。使用者は同じカレンダを用いて会議を予約したり誕生日を記憶したりする。ビジネスの場合に加入者が希望するのは、全ての使用者が共通のカレンダまたはそれぞれ相互のカレンダにアクセスすることが可能なこと、例えば使用者のグループが会議に集まれる日を自動的にチェックするという機能を用いることが可能なことである。このように、サービス「カレンダ」は、使い方に従って、複合サービスの独立のサービスとも、「ビルディング・ブロック」とも、サービス・イネーブラとも見なすことができる。
【００３１】
本発明の別の実施の形態では、複合サービスを形成するサービスの間の依存性または共用資源の使用は、ＣＳＤ内にではなく共通サービス・データベース内に記憶される。この実施の形態では、サービスの間の依存性は、ＣＳＤ内に使用者／加入者レベルで記憶されるのではなく、共通サービス・データベース内にサービス毎のレベルで記憶される。この別の実施の形態では、サービス・システム内に記憶すべき依存性はより少なくなる。なぜなら、依存性は多数の使用者に共通であり、使用者の数は一般にサービスの数よりもはるかに多いからである。他方で、例えば使用者が複合サービスを停止（deactivate）する場合は、サービスの間の依存性について知るために共通サービス・データベースにアドレス指定しなければならない。全ての使用者／加入者に関係するデータに対するするアクセス点を１つだけにするという考え方を維持するため、使用者／加入者データを更新する目的でサービスの間の依存性をチェックする場合は、共通サービス・データベースへのアクセスは好ましくはＳＡＰを通して行うようにする。
【００３２】
サービス網は、例えばＧＳＭなどの回路交換移動体システムや、ＧＰＲＳなどのパケット交換システムや、ＵＭＴＳなどの結合システムなど、種々の通信技術を用いて複数の異なるアクセス網にサービスを提供する。ＵＤＭは、使用者がどのアクセス網を用いるかだけでなく、アクセス網の使用者ＩＤや属性についての情報を提供する。
【００３３】
ＵＤＭの原理を示す例について図７を参照して以下に説明する。この略図はサービス網内で提供される複数のサービスを利用する一人の加入者と二人の使用者を示す。これはこの例を明確にするためであって、本発明を制限するものではない。実際には、加入者／使用者は多数のサービスを用いる。
リッチマン家はカストマ・セグメント６１５：「ファミリーＶＩＰＳ」に登録したサービス網カストマである。リッチマン家は「リッチマン氏」と「リッチマン夫人」と「息子」から成り、実際にサービスに加入する資格があるのは父親である加入者６１５：「リッチマン氏」 だけである。カストマ・セグメントはサービス・パッケージ６２５：「パーティ・パック」とサービス・パッケージ：「ファイナンス」を彼らに提供する。
【００３４】
連結データ６６０の「ボックス」はサービスに関わる全ての連結データを表す。この例では、連結データ６６０は、提供されるサービス６２０「リムジン予約」および「ジェット機予約」サービスと、共用資源６５０「ＭＰＣ」の連結データである。注意すべきであるが、この例では提供されるサービス６２０「リムジン予約」は位置に基づくサービスなので使用者共用資源６５０「ＭＰＣ」に依存する。
【００３５】
サービス・パッケージ６２５：「パーティ・パック」は彼らが実際に必要とするものであって、彼らはそれを購入した。これは、加入者６１０：「リッチマン氏」とサービス・パッケージ６２５：「パーティ・パック」に関係する対応するサービス・パッケージ・オブジェクトが存在することに反映されている。このサービス・パッケージを購入すると、サービス・パッケージ６２５：「パーティ・パック」に含まれる３つのサービス加入６３５（提供されるサービス６２０毎に１つ）が作成される。
他方で、サービス・パッケージ６２５：「ファイナンス」はまだこの家族には余り魅力がない。これは、この目的のサービス・パッケージ加入６３０が図の中に見られないので分かる。
【００３６】
一人の使用者６０５：「リッチマン夫人」 は提供されるサービス６２０：「リムジン予約」を用いる資格がある。これはサービス加入６３５（これは提供されるサービス６２０：「リムジン予約」に関係する）に関係するサービス・アクティベーション・オブジェクト６４０が存在することで表されている。また対応する使用者データ・オブジェクトが使用者：「リッチマン夫人」の「リムジン予約」連結データ内に存在する。注意すべきであるが、これは彼女が今のところ用いることのできる唯一の提供されるサービスなので、彼女が別のサービスを用いたいと思えば、それに応じて新しいサービス・アクティベーション・オブジェクト６４０を作成しなければならない。支払いは自分がするのだから、加入者６１０：「リッチマン氏」はこれに対して同意を与えなければならない。
【００３７】
飛行機に乗りたい別の使用者６０５：「息子」はこれも加入したサービス・パッケージ６２５：「パーティ・パック」に含まれる提供されるサービス６２０：「ジェット機予約」を用いる資格がある。また対応する使用者データ・オブジェクトが使用者：「息子」 の「ジェット機予約」連結データ内に存在する。注意すべきであるが、これは彼が今のところ用いることのできる唯一の提供されるサービスなので、別のサービスを用いたいと思えば、それに応じて新しいサービス・アクティベーション・オブジェクト６４０を作成しなければならない。この場合も、支払いは結局自分がするのだから、加入者：「リッチマン氏」はこれに対して同意を与えなければならない。
【００３８】
サービス・パッケージ６２５：「パーティ・パック」内の第３の提供されるサービス６２０：「パーティ設定」にはどの使用者も加入していないので、このサービスとこれらの使用者については加入活動化オブジェクトも連結データ内の使用者データも存在しない。
提供されるサービス６２０：「リムジン予約」は位置に基づくサービスなので、使用者：「リッチマン夫人」もＭＰＣに準備されている。これは、対応する使用者共用資源６５０とＭＰＣ連結データ内の使用者データ・オブジェクトが存在することに反映されている。
これに反して、提供されるサービス：「ジェット機予約」は共用資源内に使用者データを準備する必要がないので、このサービスに関係する使用者：「息子」 に対しては使用者共用資源オブジェクトが作成されていない。
【００３９】
この例では、連結データ内に加入者データ・オブジェクトも加入者共用資源オブジェクトもない。なぜなら、この例の中のどの加入済みサービスも、異なる使用者との共通の環境を必要としないからである（したがってこの例では、どの連結データにも加入者データを準備する必要がない。もっとも、本発明ではこの種の準備をすることは可能であるが）。この例では、サービス加入オブジェクトの役割は加入とこれに関係する提供されるサービスとを単に連結することである。
【００４０】
ＣＳＤ３００内に記憶されている使用者と加入者とサービスのデータは上記のＵＤＭに従って構築される。得られたデータ記録（data record）について図８を参照して以下に説明する。図の中の矢印はフィールドの間の依存性を示す。細い矢印は１対１の依存性を示し、太い矢印は複数のフィールドの間の依存性を示す。使用者データ記録ＵＤＲ８０３は、基本的な加入者情報（例えば加入者識別）を含む加入者フィールド８１０を含む。加入者が所有する使用者を１つ以上の使用者フィールド８０５が指定する。使用者フィールド８０５と加入者フィールド８１０は識別フィールドの例である。カストマ・セグメント・フィールド８１５は加入者の特徴を表し、また加入者に提供されるサービス・パッケージを定義する。パッケージ毎に１つのサービス・パッケージ・フィールド８２５は利用可能なサービス・パッケージを定義し、また各サービス・パッケージ・フィールド８２５には、別個のサービス毎の基本的サービス情報を含む提供されるサービス・フィールド８２０が連結する。
【００４１】
サービス・パッケージ加入フィールド８３０は加入者が加入したサービス・パッケージを定義し、サービス毎に１つのサービス加入フィールド８３５は全ての個別に利用可能なサービスを定義する。前に説明したように、各使用者はどのサービスを起動するかを選択することができる（サービス・アクティベーション・フィールド８３５のサービスから）し、また各使用者がサービスを選択するにはサービス・アクティベーション・フィールド８４０で指定する。したがって各使用者フィールド８０５はサービス・アクティベーション・フィールド８４０に連結する。サービス・アクティベーション・フィールド８４０は連結データ（すなわち、サービス・システム３４０，３５０，３６０内に記憶されている使用者データの一部）へのリンクを含む。リンクは、好ましくは連結データ記憶場所へのアドレス（例えば、ＩＰアドレス）である。サービス加入フィールド８３５とサービス・アクティベーション・フィールド８４０はサービス・フィールドの例である。使用者が選択した任意のサービスが共用資源を使用する必要がある（すなわち、１つ以上の複合サービスが同じサービス・システムを用いる）場合は、使用者共用資源フィールド８５０内にシステムの間の依存性だけでなくこれらのシステム内に記憶されている連結データへのリンクが含まれる。同様にして、加入者共用資源フィールド８４５は加入者レベルでのシステムの間の依存性を含む。
【００４２】
ＵＤＲは、連結データへのリンクだけでなく例えば連結データにアクセスするまたは共用資源を用いるのに必要な情報も含む。かかる情報の例は、種々のサービスで用いられる使用者識別のための種々の手段である。一般に識別子として、従来の電話サービスは電話番号を用い、電子メール・サービスは電子メール・アドレスを用い、カレンダ機能は別名を用いる。種々のサービス・システムを用いる複合サービスは、使用者識別のための１つ以上のこれらの異なる手段を必要とする。使用者識別の異なる手段は連結する必要がある（いわゆる識別マッピング）。これは本発明に係るデータ・モデルとデータ記録が、識別の種々の手段と属するサービスをＵＤＲ内に含むことにより、また好ましくはフィールド内にサービス・システム（すなわち、加入者共用資源フィールド８４５と、使用者共用資源フィールド８５０と、サービス・アクティベーション・フィールド８４０）へのリンクも保持することにより、提供する。
【００４３】
上に述べたデータ記録とこれに含まれるフィールドは、多くの方法で、主としてデータベースで用いられる技術に従って実現することができる。かかる実施の形態の詳細は当業者に明らかであると考えられる。また上に述べた例以外のフィールドも連結データにリンクする。しかし実施の形態を簡単にしてデータの一貫性を高めるために、かかるリンクを行う異なるフィールドの数は制限することが好ましいし、不必要なおよび／または二重のリンクは設けないように注意しなければならない。
【００４４】
サービス・アクティベーション・フィールド８４０と、加入者共用資源フィールド８４５と、使用者共用資源フィールド８５０に含まれるリンクは、ＣＳＤ３００内に記憶される主な使用者データと、サービス・システム３４０，３５０，３６０の連結データとの間の唯一の接続点である。これは使用者データの一貫性を保持するのに重要である。連結データはそのサービス・システム内だけで用いなければならない。使用者および加入者データの要求は、好ましくはＣＳＤフロントエンド４２０と、ＣＳＤフロントエンド４２０が加入者および使用者データを検索する先のＵＤＲ８０３とにより実現される、単一アクセス点に対して行わなければならない。
【００４５】
前に説明した本発明の別の実施の形態では、サービスの間の依存性が共通サービス・データベース内に記憶されている場合は、使用者共用資源フィールド８５０と加入者共用資源フィールド８４５は必要ない。この場合、対応するフィールドは共通サービス・データベースのデータ記録内で提供される。
【００４６】
使用者データを更新するなどのデータ管理を行うときや、サービスを実行するに必要なデータを検索するなどの実時間使用のときは、ＳＡＰにアクセスしてよい。データ管理は、使用者管理、加入者管理、サービス管理、カストマ・セグメント管理、サービス加入およびアクティベーションおよびサービス・パッケージ管理を含む。実時間使用はサービス・システム内でアプリケーションを実行するときに起こる。アプリケーションが例えば位置に基づくサービスを提供するとき、アプリケーションはＳＡＰから検索した或る使用者データを位置に基づくサービスに与える必要がある。別の例として、アプリケーションは連結データへの参照項目や、使用者に関連する種々の使用者ＩＤ、名前、別名のいくつかについての知識を必要とする。
【００４７】
本発明のＳＡＰを用いて、本発明に係る使用者および加入者データにアクセスする方法について、図９の略図を参照して以下に説明する。ここではアクセシング機能性をクライアント９００で表す。クライアント９００は上に述べたデータ管理機能または実時間使用を行ってよい。詳細な例は、後でサブセクション「使用事例」に示す。クライアントの使用の初期化は一般に、サービスを行うサービス・システム内のアプリケーションにより、またはサービス網内のサービス提供者または他のプレーヤにより初期化されたデータ管理アプリケーションにより行われる。したがって、或るクライアントは或るサービス・システムにリンクすることが多い。しかし必ずしもそうではない。この方法は次のステップを含む。
９１０： クライアントはＣＳＤフロントエンド４２０を介してＳＡＰにアクセスする。好ましくは、アクセスはデータ管理機能（例えば、読取りおよび／または書込み許可）にアクセスする権利を確立する要求／許可手続きを含む。
【００４８】
９２０： クライアントは、一般に使用者IＤまたは加入者ＩＤを参照することによりＣＳＤフロントエンド４２０との間のデータの読取りおよび／または書込みを要求する。
９３０： ＣＳＤインデックス・テーブル４１０を用いることにより、ＣＳＤフロントエンド４２０は分散データベースの中の正しいデータベースにアクセスする。
９４０： ＣＳＤフロントエンド４２０はＵＤＲ８０３との間でデータを検索しまたは転送する。
９５０： ＣＳＤフロントエンド４２０は要求されたデータをクライアントに返す。
【００４９】
随意であるが、この方法は次のステップを含んでよい。
９５５： ＳＡＰ内に記憶されていない使用者データ（すなわち連結データ）へのアクセスをクライアントが要求する場合は、まず上に述べたステップに従ってＳＡＰにアクセスする。クライアントは例えばサービス・アクティベーション・フィールド８４０から、連結データと、連結データにアクセスするのに必要な使用者ＩＤまたは使用者名などの情報へのリンクを提供される。
９６０： クライアントはＳＡＰからの情報を用いて連結データ記憶場所にアクセスして、使用者関係データを要求する。
９６５： 連結データ記憶場所は使用者関係データをクライアントに返す。
【００５０】
随意であるが、この方法は更に次のステップを含んでよい。
９７０： クライアントが使用者データを変更または削除または追加しようとする場合は、種々のサービス・システムの間の依存性についてＵＤＲ８０３をチェックしなければならない。すなわち、上に述べた例示の実施の形態では、種々のサービス・システムの間の依存性について使用者共用資源フィールド８５０と加入者共用資源フィールド８４５をチェックする。かかる依存性がある場合は、使用者データが別のサービス・システムで使われることがあるので普通は変更または削除してはならないとクライアントに通知する。
【００５１】
管理活動の種類によって各ステップの詳細は変わる。主要な機能は、使用者および加入者データの変更をＳＡＰに送ることである。一般にサービス・システム内に記憶されている連結データを変更するには、ＳＡＰにアクセスして当該連結データ記憶場所がどこにあるかの情報（すなわち、サービス・アクティベーション・フィールド８４０と、使用者共用資源フィールド８５０と、加入者共用資源フィールド８４５内に与えられる情報）を得る。次に記憶場所の連結データに直接アクセスする。または、かかる機能性がＳＡＰに与えられている場合は、ＳＡＰを通して連結データにアクセスする。
【００５２】
ステップ９１０のアクセスは、ＩＰアドレスまたはＵＬＲを用いるなど、多数の異なる方法で行ってよい。またＳＡＰはＣＳＤフロントエンド４２０を介して、種々の異なるアクセス方法および種々のアクセス手段だけでなく複数の同時アクセスを扱うことができる。種々のアクセス方法が当業者に知られている。
本発明の上に説明した方法は、コンピュータ・プログラム製品またはコンピュータ・プログラム製品の一部として実現してよい。プログラム製品は例えばサービス網２００内のサービス・システムに属するコンピュータ上で実行する。
【００５３】
本発明に係るＳＡＰと方法について、サービス網内の全てのサービスに適用できるものとして説明した。これは好ましい実施の形態である。ＳＡＰはサービス網内で本発明を用いないサービス・システムと共存することもできるが、本発明が提供する利点を用いることができるのはＳＡＰを用いるサービス・システムだけである。
本発明について現在最も実用的で好ましいと考えられる実施の形態に関して説明したが、理解されるように、本発明はここに開示した実施の形態に限定されるものではなく、特許請求の範囲の精神と範囲内に含まれる種々の変更と同等の調整をカバーするものである。
【００５４】
使用例
この例において管理者という用語は、サービス網内で一般にクライアント・サーバの関係でソフトウエア・クライアントを通して動作する管理の機能性を指す。
データ管理
使用者管理
使用者を得る
期待される結果：
ＳＮ使用者データ・モデル内の使用者関係情報を検索する。
前提条件：
少なくとも一人の使用者が存在しなければならない。
事例の説明：
管理者は使用者情報を検索する必要があり、これをＳＡＰに要求する。管理者が正当な読取り許可機能を有する場合は、要求された情報（使用者情報、および／または加入者データ、および／または網アクセス・データ、および／または使用者共用資源）を検索することができる。
ＳＮ使用者データ・モデルがこの情報を提供したとき、場合によっては、管理者が用いるシステム（例えば、準備ツール）はＳＮ使用者データ・モデルの外部の使用者情報を検索する（すなわち、実際の加入データおよび／または使用者共用資源データが常駐する連結データ記憶場所に到達する）必要がある。このため、これらの連結データへ向うＳＮ ＳＡＰが保持する検索された参照項目（使用者ＩＤとサービス・アドレスを提供する）をたどり、その連結データが発行した当該データ・アクセス・プロトコルを用いなければならない。
【００５５】
使用者を作成する
期待される結果：
新しい使用者が定義される。
前提条件：
少なくとも一人の加入者が存在しなければならない。私的使用者の場合、加入者は使用者と同じプロセスで作成される。
事例の説明：
管理者は新しい使用者を作成することを希望する。このため、管理者は使用者の基本的データを入力し、使用者が関連する加入者を選択する。次に、新しい使用者記録をＳＡＰ内に作成して加入者に結合する。使用者は単独で存在することができないので、この結合はこのプロセスに固有である。なぜなら、加入者が作成した加入だけを利用しなければならないからである。
【００５６】
使用者を削除する
期待される結果：
特定の使用者とその関連する全ての情報をＳＡＰから削除する。
前提条件：
少なくとも一人の使用者が存在しなければならない。
事例の説明：
管理者は使用者をＳＡＰから削除することを希望する。管理者が用いるシステム（一般に準備システム）はまず、サービス・データが常駐する連結データ記憶場所へのサービス参照項目と使用者共用資源参照項目を得て、各記憶場所に行ってそれぞれに記憶されている使用者サービス・データを削除する。次に、使用者オブジェクトの他に、加入者オブジェクト、および／または網アクセス・オブジェクト、および／または使用者共用資源オブジェクトを消す。
【００５７】
使用者を更新する
期待される結果：
管理者は使用者データを変更する。
前提条件：
少なくとも一人の使用者が存在しなければならない。
事例の説明：
管理者（使用者自身でもよい）は使用者の基本的データを変更することを希望する（唯一の影響を受けるオブジェクトは使用者オブジェクトである）。ＳＡＰ内の使用者オブジェクト情報を更新する。
【００５８】
加入者管理
加入者を得る
期待される結果：
ＳＮ使用者データ・モデル内の加入者に関する情報を検索する。
前提条件：
少なくとも一人の加入者が定義されている。
事例の説明：
管理者は加入者に関係する情報をＳＡＰに要求する。この情報は次のどれかを含んでよい。すなわち、加入者の基本的データ、サービス・パッケージ加入、サービス加入データ、カストマ・セグメント・データ、加入者共用資源データ、使用者のリストである。
ＳＮ使用者データ・モデルがこの情報を提供したとき、管理者が用いるシステム（例えば、準備ツール）はＳＡＰの外部の加入者情報を検索する（すなわち、実際のサービス加入データおよび／または加入者共用資源データが常駐する連結データ記憶場所に到達する）必要がある。このため、これらの連結データへ向うＳＡＰが保持する検索された参照項目（使用者ＩＤとサービス・アドレスを提供する）をたどり、その連結データが発行した当該データ・アクセス・プロトコルを用いなければならない。
【００５９】
サービス管理
サービスを得る
期待される結果：
提供されるサービスをＳＡＰから取り出す。
前提条件：
少なくとも１つのサービスが定義されている。
事例の説明：
管理者は提供されるサービス情報をＳＮ ＳＡＰに要求する。サービス・オブジェクト内に含まれるデータを検索する。
【００６０】
サービスを追加する
期待される結果：
新しい提供されるサービスのパッケージ化が準備される。
前提条件：
サービスがすでに開発され、配置され、形成されている。すなわち、提供されるサービスが存在し、その情報がＳＮの他の部分から利用できる。
事例の説明：
提供されるサービスに加入できるようにするため、まず提供されるサービス・オブジェクトを作成してＳＡＰに示す。
提供されるサービスを作成するとき、管理者は提供されるサービス・テンプレートを提供しなければならない。
【００６１】
カストマ・セグメント
カストマ・セグメントを得る
期待される結果：
カストマ・セグメントとこれに関連する情報をＳＡＰから検索する。
前提条件：
少なくとも１つのカストマ・セグメントが存在しなければならない。
事例の説明：
管理者は、一般に準備システムを通して、カストマ・セグメントに関連する情報を知る必要がある。かかる情報をＳＮ ＳＡＰに要求すると、ＳＮ ＳＡＰはカストマ・セグメント情報とこれに関連するサービス・パッケージ情報（各サービス・パッケージ内に含まれるサービスを含む）を送る。
変形：
更に、そのカストマ・セグメントに属する加入者のリストを検索することができる。
【００６２】
カストマ・セグメントを作成する
期待される結果：
新しいカストマ・セグメントが定義され、加入者をこれに関連付けることができる。
前提条件：
少なくとも１つのサービス・パッケージが存在しなければならない。
事例の説明：
カストマ区分により加入者の分類とサービスのグループ化が可能になる。各加入者は或る（１つの）カストマ・セグメントに属さなければならないので、加入者を定義する前にこれらを作成しなければならない。
このため、管理者はカストマ・セグメントを作成して、いくつかの利用可能なサービス・パッケージをこれに結合する。かかるサービス・パッケージ内に含まれるサービスは、この新しいカストマ・セグメントに結合する各加入者に提供するサービスで構成する。新しいカストマ・セグメントはＳＡＰ内に追加され、選択されたサービスに連結される。
【００６３】
サービス加入と活動化
加入を作成する
期待される結果：
特定の使用者用の特定の提供されるサービスを起動することができるようになる。次の０を参照のこと。
前提条件：
関係者（actor）（加入者）がサービス・パッケージにすでに加入している。
事例の説明：
加入者は、サービスを起動して使用者が用いることができるようにしたいと希望する。既存の使用者とは独立のサービス加入を介して、加入オブジェクトを作成し、提供されるサービスに結合しなければならない。
連結データ準備契約に従い、また提供されるサービス・テンプレートの設定に従って固定加入関係情報を連結データに準備することにより、使用者準備を行わなければならない。これにより、連結データ内に新しい使用者データ・オブジェクトが作成される。
加入オブジェクトは連結データ内のこの使用者コンテキストを指すので、更なる活動化と他の準備に関係する活動が支援される。この参照項目は、アプリケーションが割り当てる使用者ＩＤと連結のアドレスから成る。
【００６４】
サービスを活動化する
期待される結果：
サービスを初めて用いられるよう準備する。
前提条件：
この使用者とこの提供されるサービスに関係する加入が上記に従ってすでに作成されている。
事例の説明：
或る提供されるサービスの使用準備の最後のステップはその起動である。管理者（場合によっては単に使用者でよい）はその準備テンプレートに従うサービス起動に必要な個人情報を提供する。起動設定はその連結データ準備契約に従って連結データ記憶場所に送られる。
ＳＡＰ内の対応するオブジェクト（加入オブジェクト）が更新されて、サービスが起動したことを反映する。
サービスが常駐する連結データ記憶場所への参照項目（サービス使用者ＩＤと連結アドレス）と、サービスとそれが必要とする共用資源との間の関係も確立しなければならない。
【００６５】
実時間使用の事例
共用資源を得る
期待される結果：
アプリケーションは使用者または加入者が用いる共用資源を得る。アプリケーションはこの情報を用いて、サービスを実行するために資源にアクセスしてよい。
前提条件：
使用者のための少なくとも１つのサービスの使用準備ができていなければならない。
事例の説明：
アプリケーションが提供するサービスは、実行時に、サービス実行プロセスを支援する共用資源にアクセスする必要がある。例えば、位置に基づくサービスを提供するアプリケーションは、アクセス網から位置情報を得るイネーブラにアクセスしてアプリケーションに見えるようにする必要がある。
このため、使用者／加入者に属する共用資源についての情報を得ることを希望するアプリケーションは、使用者の識別を用いてそれを要求する。全ての可能な識別はＳＮ使用者データ・モデル内に保持されており、また各サービスとその共用資源とは関連があるので、要求された情報はアプリケーションに送られる。
【００６６】
使用者ＩＤを得る
期待される結果：
アプリケーションは任意の使用者ＩＤを得る。アプリケーションはサービスを実行するためにこの情報を用いる。
前提条件：
少なくとも一人の使用者が存在しなければならない。
事例の説明：
アプリケーションが提供するサービスは使用者の任意の識別を用いることができるが、サービスの特徴によって、使用者の他の識別を知る必要がある（例えば、電子メール・アドレスを持っていると、電子メールをＳＭＳフォーマットで送るためにＭＳＩＳＤＮを知りたいと思う）。ＳＮ ＳＡＰは全ての使用者識別を知っているので、要求された情報を送る。
【００６７】
サービス・リストを得る
期待される結果：
加入したサービスのリストがＳＮ ＳＡＰにアクセスするエンティティに送られる。
前提条件：
少なくとも一人の使用者が存在する。
事例の説明：
認可のために、加入した使用者へのサービスのリストを得たいと思うエンティティがあるので、そのサービスを用いたいときは、この使用者がそのサービスを用いる権利を持つかどうかチェックする。このため、ＳＡＰは要求されるとこのリストを作成して送ることができる。
【図面の簡単な説明】
上に概説した本発明の機能と利点について、以下の図面に関連して詳細に説明する。図面中、同じ参照番号は同じ要素を指す。
【図１】 従来の垂直に統合された網の略図。
【図２】 サービス網を構成する水平に層化された網の略図。
【図３】 本発明に用いられる共通使用者／加入者データベースの略図。
【図４】 本発明の単一アクセス点の略図。
【図５】 本発明の基本的エンティティの間の関係。
【図６】 本発明に係る使用者データ・モデルの略図。
【図７】 本発明に係る使用者データ・モデルの使用例。
【図８】 本発明に係る使用者データ記録の略図。
【図９】 本発明に係る方法を示す略図。
【符号の説明】
２００ サービス網
３００ 共通加入者／使用者データベース
６３５ サービス加入
６４０ サービス起動
８０３ 使用者データ記録
８０５ 使用者フィールド
８１０ 加入者フィールド

Claims (10)

1. 複数のサービスを提供する複数のサービス・システム（３１０，３２０，３３０）を有するサービス網（２００）内の使用者および加入者データを記憶しまた保持する方法であって、前記システムは使用者および加入者情報を有する加入者／使用者データ記録と複数のサービスに関係する加入者／使用者情報とを含む加入者／使用者データベースを備え、前記方法は、
   ・ 使用者データを共通加入者／使用者データベース（３００）に使用者データ記録の形で記憶し、
   ・ 使用者を識別する少なくとも１つの識別オブジェクト（６０５，６１０）を前記使用者データ記録に記憶し、
   ・ 前記サービス網内で提供される前記複数のサービスから前記使用者が選択する少なくとも１つの選択されたサービスを指定する少なくとも１つのサービス・オブジェクト（６３５，６４０）を前記使用者または加入者データ記録に記憶する、
   ことを含み、
   前記少なくとも１つのサービス・オブジェクトの少なくとも１つは前記加入者または使用者に関係する連結データ（６６０）へのリンクを提供し、前記連結データは前記共通加入者／使用者データベースの外部に記憶され、
   前記方法は、更に、
   ・ 加入者または使用者に関する情報にアクセスするために前記共通加入者 / 使用者データベース（３００）にクライアントからアクセスし（９１０）、
   ・ 単一アクセス点を介して加入者または使用者データ記録から／へデータを検索または転送し、
   ・ 前記使用者または加入者データ記録のサービス・オブジェクト（６３５，６４０）が連結データ（６６０）へのリンクを含んでいるかチェックし、もし含んでいれば、連結データ記憶場所にアクセスして使用者データを検索する、
   ことを含む方法。
2. ・ 前記サービス網内で提供される前記複数のサービスから選択される加入者が利用可能なサービスの第１のグループを指定するサービス加入オブジェクト（６３５）と、
   ・ 前記サービスの第１のグループから選択された、使用者によって起動されたサービスをそれぞれが指定する少なくとも１つのサービス・アクティベーション・オブジェクト（６４０）と、
   を記憶することを更に含み、
   前記サービス加入オブジェクトおよび／またはサービス・アクティベーション・オブジェクトは加入者または使用者に関係する連結データにリンクし、また前記連結データは前記共通加入者／使用者データベースの外部に記憶される、
   請求項１記載の方法。
3. ・ 前記加入者に属する各使用者をそれぞれが識別する複数の使用者オブジェクト（６０５）と、
   ・ サービス・アクティベーション・オブジェクト（６４０）であって、各使用者オブジェクトにリンクし、前記サービスの第１のグループから選択される各使用者が利用可能なサービスの使用者当たりのグループを指定し、また前記共通加入者／使用者データベースの外部に記憶されている連結データにリンクする、使用者毎の少なくとも１つのサービス・ アクティベーション・オブジェクト（６４０）と、
   を記憶することを更に含む請求項２記載の方法。
4. 複合サービスを実行する種々のサービス・システムの間の依存性を定義する情報を記憶することを更に含む請求項３記載の方法。
5. 使用者毎に、前記使用者オブジェクトと前記サービス・アクティベーション・オブジェクトとにリンクする使用者共用資源オブジェクト（６５０）を記憶することを更に含み、前記使用者共用資源オブジェクトは使用者レベルのサービス・システムの間の依存性を定義する、請求項４記載の方法。
6. 前記加入者オブジェクトと前記サービス加入オブジェクトとにリンクする加入者共用資源オブジェクト（６４５）を記憶することを更に含み、前記加入者共用資源オブジェクトは加入者レベルのサービス・システムの間の依存性を定義する、請求項４記載の方法。
7. 使用者毎に、使用者を識別するための複数の手段を記憶することを更に含む請求項４記載の方法。
8. 前記識別手段は、電話番号、個人識別コード、電子メール・アドレス、名前、または別名の１つ以上である、請求項７記載の方法。
9. 前記識別手段はサービス・システムの間の依存性も記憶するオブジェクト内に記憶される、請求項７記載の方法。
10. 前記使用者が利用可能なサービスを指定する複数のオブジェクトを記憶することを更に含み、前記複数のオブジェクトは、
    ・ 前記加入者オブジェクト内で指定される加入者が利用可能なサービスのグループをそれぞれが指定する、少なくとも１つのサービス・パッケージ・オブジェクト（６２５）と、
    ・ 前記加入者オブジェクトの加入者を特徴づけまたサービス・パッケージを指定するカストマ・セグメント・オブジェクト（６１５）と、
    ・ 前記サービス・パッケージ・オブジェクトが指定するサービス・パッケージに含まれる別個のサービス毎のサービス情報を含む少なくとも１つの提供されるサービス・オブジェクト（６２０）と、
    を含む、請求項３記載の方法。

Images