JP2003333182A - 電気通信網における方法と装置 - Google Patents

Abstract

(57)【要約】 【課題】 複数のサービス提供者とサービス・イネーブ
ラが存在する通信網内の種々のサービスに関係する種々
のデータを統合する装置と方法を提供する。 【解決手段】 このシステムは使用者および加入者情報
を持つ共通加入者／使用者データベース（３００）と使
用者データ記録（８０３）を提供する。使用者データ記
録は、加入者と使用者を識別する少なくとも１つの識別
フィールド（８０５，８１０）と、サービス網（２０
０）内で提供される複数のサービスから選択されたサー
ビスを指定する少なくとも１つのサービス・フィールド
（６３５，６４０）とを含む。この選択されたサービス
は使用者または加入者が選択する。前記サービス・フィ
ールドの少なくとも１つは、加入者／使用者に関係する
連結データ（８６０）にリンクし、これは共通加入者／
使用者データベースの外部に記憶される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は一般に通信網内のデ
ータ分配の分野に関するもので、特に複数のサービス提
供者とサービス・イネーブラ（service enablers）が存
在する通信網内の種々のサービスに関係する種々のデー
タの統合に関する。

【０００２】

【従来の技術】これまでは、移動電話網（ＰＬＭＮ）や
固定回路交換網（ＰＳＴＮ）やデータ通信網などの通信
網は別個のシステムであった。電気通信網の特徴は垂直
に統合されていることである。これはアプリケーション
やサービスが転送技術に密接に結び付いていることを意
味する。例えば、移動体システムＧＳＭは一組のサービ
スとアプリケーションを提供するが、その外観と利点と
限界の少なくとも大部分は通信技術により与えられる。
固定電話網（ＰＳＴＮ）はこのシステムに用いられる通
信技術に密接に連結するサービスとアプリケーションの
異なる集合を提供し、そのサービスの使用と概観の多く
はＰＬＭＮにおける同様のサービスとは異なっている。
最終使用者には同じように見えるサービスも、技術に密
接に関係するので、異なる網では非常に異なる方法で実
現される。

【０００３】サービスと通信技術とが密接に関係してい
ることも、網の運営者が最終使用者へのサービスの主要
な提供者でもあったということの重要な理由であった。
サービスを提供するには、網全体の知識とアクセスが欠
かせない。垂直に統合された網を図１に示す。

【０００４】多様化されたサービス（複合サービス）
と、サービス提供者の間の競争を促進することの要求が
高まっている。同時に、電気およびデータ通信網が発展
した。新しい世代の通信システムはセルラ電話やＩＰに
基づくデータ通信などの種々の通信技術を統合する。新
しいシステムは、例えばアクセス層とコア層とサービス
層を備える水平に層化されたものとして描かれることが
多い。図２は層化された通信システムを示す。このシナ
リオでは、例えば運営者、サービス提供者、サービス・
イネーブラ、コンテンツ提供者、アプリケーション（イ
ンターネット（Ｒ））サービス提供者などの既存および
新規のプレーヤが相互に作用して多様なサービスを最終
使用者に提供する。サービスは、網（サービス網２０
０）の形を有するサービス層内で提供され管理される。
サービス網２００はコア網２１０と相互に作用し、一般
にＩＰ構造を有して転送および交換機能を提供する。コ
ア網から複数のアクセス網と通信することができる。ア
クセス網は、ＧＳＭやＵＭＴＳなどの種々の容量と特徴
を持つセルラ・システム２２０や、固定電話（ＰＳＴ
Ｎ）２３０や、ＩＰに基づくデータ通信２４０や、ケー
ブルＴＶ２５０を含む種々の網でよい。サービス網２０
０は、好ましくはオープン構造（例えばオープン・サー
ビス構造ＯＳＡ）とオープン・インターフェース（例え
ば、ＯＳＡアプリケーション・プログラム・インターフ
ェースＡＰＩ）を有し、これにより多数のプレーヤは相
互に作用して最終使用者にサービスを提供することがで
きる。垂直に統合された網と層化された網との比較はエ
リクソン・レビュー（Ericsson Review）No.2, 2001に
述べられている。

【０００５】好ましくは提供されるサービスは、最終使
用者の個人的な要求や、アクセス方法（移動体システム
や、固定システムなど）や、アクセスする端末の特性
（例えば移動体端末の容量など）や、加入方式などに従
って調整してよい。例えばアクセス方法はサービス網内
のサービスの実行に影響を与えるが、サービスを実行す
る多くの部分は、例えばアクセス方法に関わらず似てい
るかまたは同じである。したがって、サービス提供者は
同じ「積み木（building blocks）」を用いて、異なる
最終使用者用に調整した異なるサービスを構築すること
ができる。積み木は、例えば電話番号サービスや、メッ
セージ・サービスや、位置決めツールなどである。サー
ビス網の開放性と、２つ以上の特定のサービスに積み木
を用いることが可能であることとが、運営者やサービス
提供者やサービス・イネーブラなどのプレーヤと最終使
用者とに、新しいサービスをそれぞれ開発し使用する魅
力を与える重要な要因と見なされている。

【０００６】提供されるサービスは、二人の移動体加入
者の間に呼を設定するなどの基本的な電話サービスか
ら、異なるアクセス網や１つ以上のインターネット・ア
プリケーションやセキュリティ・サービスが関わる複合
サービスまでにわたる。複合サービスは、位置決めや、
メッセージ交換や、電子商取引を用いるサービスを含ん
でよい。位置決めに基づくサービスは、例えば最終使用
者の位置の近くにあるホテルを探すことである。かかる
サービスは、移動体位置決めセンタを介する移動体シス
テムの位置決めツールや、或る地域内のホテルを探した
り分類したりする１つ以上のインターネット・アプリケ
ーションや、最終使用者（例えばＷＡＰ）の端末に表示
するのに適したフォーマットに情報を変換するアプリケ
ーションや、部屋の予約や支払いを容易にする電子商取
引アプリケーションを用いることを含む。複合サービス
の別の例は、いわゆるフリート管理（fleet managemen
t）に関係する。使用者の選択されたグループ内の個々
の使用者の位置に関する情報が、そのグループ内の一人
または全ての使用者に提供される。各使用者の位置は位
置決めシステムにより与えられる。これにより、使用者
はグループ内の全ての他の人の位置に関する最新の情報
を得ることができる。この種のサービスは、例えば一群
の配送車を管理するのに有用である。かかるサービスを
提供し実行するには、種々のサブシステムの間の多数の
インターフェースが必要である。種々のサービス・シス
テムが種々のサービス・イネーブラから提供されるの
で、サービス網と、オープン構造と標準化されたインタ
ーフェースを有するサービス網が必要なことは明らかで
ある。

【０００７】

【発明が解決しようとする課題】サービス網内で多数の
サービス提供者やイネーブラが多数のサービスを提供
し、最終使用者が種々のアクセス網内に広がり、個人的
なサービスや種々の支払い方法の要求が生じると、正し
い最終使用者データの要求が高まり、そのデータに即座
にアクセスすることが重要になる。今日の網では最終使
用者に関係するデータは網全体に分散され、多くの場合
に冗長な最終使用者データが記憶され、用いられてい
る。データが分散して記憶されかつ冗長なので、最終使
用者情報を検索し更新するのが困難である。最終使用者
データが分散されている既存の網では、複合サービスの
安定した機能性を実現し確保することは非常に困難であ
る。最終使用者データが分散されていることの１つの欠
点を、例えば位置決めサービスに基づく或る複合サービ
スへの加入を最終使用者が止める場合の例で示す。この
場合、位置決めサービスを提供するサービス・システム
からその加入者に関係する全てのデータが削除される。
位置決めを用いる他の複合サービスをその最終使用者が
利用したいと思っても、位置決めサービスを提供するサ
ービス・システムからその最終使用者に関係するデータ
がすでに削除されているので、かかる他の複合サービス
は重要な最終使用者関係データを持っていない。或る場
合にはこの複合サービスを実行できないし、また或る場
合には最終使用者データを網内の他の場所から検索でき
たとしても、複合サービスの実行が遅れたり、トラヒッ
ク負荷が増えたりする。

【０００８】また、使用者はサービスに従って異なるＩ
Ｄ、名前、別名により識別される。例えば、従来の電話
サービスでは使用者の電話番号が用いられ、電子メール
通信に基づくサービスでは電子メール・アドレスが用い
られ、カレンダに基づくサービスでは使用者の別名が用
いられる。複合サービスは種々の識別手段を持つ使用者
データにアクセスする必要があり、使用者データが分散
されている場合は、全ての複合サービスが全ての使用者
識別を記憶し更新する必要がある。

【０００９】最終使用者データの現在の処理方法に伴う
問題を要約すると次のようになる。 ａ） サービスに関係する最終使用者データに即座にア
クセスすることができず、また完全な最終使用者データ
へのアクセスは非常に困難で時間がかかる可能性があ
る。 ｂ） １つのサービス・システムと別のサービス・シス
テムとの関係を示す情報が容易に得られないので、例え
ば最終使用者データが変更された場合に他のサービス・
システムにどのように影響を与えるかを知ることができ
ない。 ｃ） 最終使用者データが分散されるため、また異なる
サービス・システムの間の関係が分からないために、シ
ステム内のデータの一貫性が弱くなり、トラヒック負荷
が増加する。

【００１０】

【課題を解決するための手段】本発明が解決しようとす
る問題は、複合サービスおよび/または多数のサービス
を提供するサービス網において、最終使用者および加入
者データを記憶しアクセスして、データに即座にアクセ
スしまたデータの一貫性を保持するようにするための方
法とシステムと記憶エンティティを提供することであ
る。この問題は、請求項１に定義されるシステムと、請
求項１５に係るデータ記録と、請求項３５に定義される
方法と、請求項４０および４１に定義されるＲＥＦおよ
びコンピュータ・プログラム製品と、により解決され
る。

【００１１】本発明の１つの実施の形態に係るシステム
は、共通加入者／使用者データベースと、使用者および
加入者の情報を含む加入者／使用者データ記録を提供す
る。加入者／使用者データ記録を構成するのは、加入者
と使用者を識別する少なくとも１つの識別フィールド
と、サービス網内で提供される複数のサービスから少な
くとも１つの選択されたサービスを指定する少なくとも
１つのサービス・フィールドである。ただし、この少な
くとも１つの選択されたサービスは使用者または加入者
が選択する。前記少なくとも１つのサービス・フィール
ドの少なくとも１つは加入者／使用者に関係するデータ
を連結するリンクを提供し、これは共通加入者／使用者
データベースの外部に記憶される。このように、共通加
入者／使用者データベースと加入者／使用者記録によ
り、サービス網内の使用者および／または加入者データ
にアクセスするための単一アクセス点の設定が容易にな
る。

【００１２】本発明の別の実施の形態では、加入者／使
用者データ記録は少なくとも２つのサービス・フィール
ドで構成する。１つは、加入者が利用できるサービスの
第１のグループを指定するサービス加入フィールドで、
サービスの第１のグループ内のサービスはサービス網内
で提供される前記複数のサービスから選択される。もう
１つは少なくとも１つのサービス・アクティベーション
・フィールド（service activation field）で、各サー
ビス・アクティベーション・フィールドはサービスの第
１のグループから選択された、使用者によって起動され
た（activated）サービスを指定する。サービス加入フ
ィールドおよび／またはサービス・アクティベーション
・フィールドは加入者／使用者に関するデータを連結す
るリンクを提供し、これは前記共通加入者／使用者デー
タベースの外部に記憶される。

【００１３】本発明に係る、サービス網内の使用者およ
び加入者データを記憶し保持するデータ記録を構成する
のは、加入者と使用者を識別する少なくとも１つの識別
フィールドと、サービス網内で提供される複数のサービ
スから少なくとも１つの選択されたサービスを指定する
少なくとも１つのサービス・フィールドである。ただ
し、この少なくとも１つの選択されたサービスは使用者
または加入者が選択する。前記少なくとも１つのサービ
ス・フィールドの少なくとも１つは加入者／使用者に関
するデータを連結するリンクを提供し、これは共通加入
者／使用者データベースの外部に記憶される。

【００１４】本発明により、共通加入者／使用者データ
ベースと使用者データ記録はサービス網内の使用者およ
び加入者データにアクセスするための単一アクセス点を
提供する。したがって使用者データへの迅速なアクセス
が可能になり、使用者データは単一アクセス点だけを通
してアクセスされまた必要であれば追加され更新され削
除されるので、データの一貫性が達成される。本発明の
１つの実施の形態に係る方法は次のステップを含む。 ・ 上に述べたシステムとデータ記録が提供するサービ
ス網内の単一アクセス点にアクセスし、 ・ 単一アクセス点にデータの読取りおよび／または書
込みを要求し、 ・ 単一アクセス点を介して使用者データ記録との間で
データの検索または転送を行う。

【００１５】本発明に係る方法の１つの利点は、使用者
／加入者データに対する全ての要求がサービス網内の１
つの場所（単一アクセス点）に向けられることである。
本発明の別の利点は、データを連結するリンクと連結デ
ータにアクセスするのに必要な情報が、前記データを検
索する本発明の方法を用いて本発明のシステムにより提
供されることである。

【００１６】定義サービス網（ＳＮ） -- 通信システムの水平に層化され
た構造におけるサービス層に対応する。最終使用者サー
ビスを提供するのに必要なノードと複数のサービス・シ
ステムはサービス網の一部と考える。正確にどのノード
がサービス網に属すると見なされるかは実施の形態によ
る。１つ以上の層／網に属するノードがあってよい。サービス・システム -- サービスまたはサービスの一部
を提供するシステム。サービス・システムは一般にサー
ビス網に属する。サービス・システムは他のサービス・
システムを用いて（通信して）特定のサービスを最終使
用者に提供してよい。サービス・システムは１つ以上の
異なるサービス、またはサービスのグループを提供して
よい。複合サービス -- 特定のサービスを最終使用者に提供す
るのに２つ以上のサービス・システムを関連させる必要
のあるサービス。

【００１７】

【発明の実施の形態】本発明の実施の形態について、図
面を参照して以下に説明する。本発明は、最終使用者に
関係するデータが網内に分散するために生じる問題に対
処するため、最終使用者に関係するデータのための単一
アクセス点（Single Access Point：ＳＡＰ）をサービ
ス網内に設ける。最高レベルのＳＡＰは共通加入者／使
用者データベース（Common Subscriber-user Databas
e：ＣＳＤ）と、ＣＳＤ内に記憶するデータ記録で構成
する。データ記録は使用者に関係するデータを記憶し、
使用者に関係するデータを記憶する他の記録にリンクす
る。相互に作用して複合サービスを形成する異なるサー
ビス・システムの間の依存性も好ましくはＣＳＤ内に記
憶する。ＣＳＤはサービス網２００からアクセス可能で
あり、一般にサービス網２００内に常駐する。

【００１８】図３にＣＳＤの役割を示す。一般に複数の
サービス・システムからアクセスされる使用者または加
入者に関係するデータは、ＣＳＤ３００内に記憶され
る。またＣＳＤ３００内には、ＣＳＤ３００内に記憶さ
れる最終使用者データとＣＳＤ３００内に記憶されない
最終使用者に関係するデータとを連結するリンクを記憶
する。連結データと呼ぶこのデータは一般に或るサービ
スまたはサービスのグループに特有のものであり、特定
のサービス・システムにだけ関連する。サービス・シス
テムＡ３１０と、サービス・システムＢ３２０と、サー
ビス・システムＣ３３０は、或るサービスまたはサービ
スのグループを提供するサービス網２００内のシステム
の例である。リンクＡ３４０と、リンクＢ３５０と、リ
ンクＣ３６０は、ＣＳＤ３００内のデータ記録が連結デ
ータにリンクすなわち参照項目を提供することを示す。
共通使用者および加入者データはサービス・システムＡ
３１０、またはＢ３２０、またはＣ３３０内に重複して
記憶されるのではなく、ＣＳＤ３００内に記憶される。
これにより一貫性が確保される。

【００１９】複合サービスの場合は１つ以上のサービス
・システム（例えば、サービス・システムＢ３２０とＣ
３３０）を用いる必要があり、２つのシステムＢとＣの
間の依存性はＣＳＤ３００内に記憶される。これをリン
クＢ＋Ｃ３７０で示す。或る実施の形態では、例えばサ
ービス・システムＡは電話番号サービスを提供し、サー
ビス・システムＢは移動体端末の位置決めを提供し、サ
ービス・システムＣは町の中のホテルやタクシーやレス
トランを探すインターネット・アプリケーションを提供
をする。この場合、位置に基づくサービスを最終使用者
に提供するにはサービス・システムＢとサービス・シス
テムＣは相互に作用しなければならない。

【００２０】或る実現されたサービス網では、サービス
・システムの数は一般にここに示した数よりはるかに多
く、システム間の依存性と相互作用は３システム以上を
含む。したがって、上記は制限のない例と考えるべきで
ある。サービスを提供するシステムの数やこれらのシス
テム間の複雑な依存性に関わらず、共通の使用者に関係
するデータは重複して記憶されない。これによりデータ
の一貫性を確保することができる。ＣＳＤ内に記憶して
データの一貫性を可能にするデータ記録の構造について
以下に詳細に説明する。

【００２１】ほとんどの実施の形態において、ＣＳＤは
非常に大きなデータベースである。なぜなら、サービス
網が提供する複数のサービスを用いる最終使用者につい
ての使用者関係データを含まなければならないからであ
る。これは図４に示すように分散データベースを用いる
ことにより対処することができる。ＣＳＤ３００のデー
タは種々のユニット内に含まれる複数のデータベース４
００に分割される。ＣＳＤインデックス・テーブル（in
dex table）４１０により、データベース４００内のデ
ータの内部の分散を隠す。ＣＳＤインデックス・テーブ
ル４１０は、データベースの１つを含むユニットの１つ
または別個のユニット内に記憶してよい。データベース
４００とＣＳＤインデックス・テーブル４１０はＣＳＤ
フロントエンド４２０に接続する。ＣＳＤフロントエン
ド４２０とデータベース４００内に記憶されるデータ記
録とを組み合わせてＳＡＰ４３０を形成する。ＣＳＤフ
ロントエンド４２０は図の矢印で示す全てのデータの要
求を受け、ＣＳＤインデックス・テーブル４１０を用い
てデータベース４００からデータを検索する。外部から
はＣＳＤ３００は１つのアクセス点を持つ１つのデータ
ベースに見えるが、内部では多数の別個のデータベース
４００を用いてよい。分散データベースの詳細な構造は
この技術で公知なのでこの明細書から省く。理解される
ように、ここに説明するエンティティは論理エンティテ
ィと考えるべきものである。上に述べたようにデータベ
ースは物理的に異なるユニットに分配して提供してよい
が、ＣＤＳフロントエンド４２０やＣＳＤインデックス
・テーブル４１０などの他のエンティティも、物理的に
別個のユニットに分配することを含む多くの異なる方法
で実現してよい。単一アクセス点ＳＡＰという用語は、
概念的にサービス網内の最終使用者に関係するデータの
論理的アクセス点という意味に理解すべきである。実際
には、ＣＤＳフロントエンド４２０は多数の同時アクセ
スだけでなく、例えばＩＰアドレスやＨＴＭＬアドレス
やＥ．１３６アドレスを用いることによるアクセス、ま
たはＵＲＬによるアクセスを含む種々の手段や方法によ
るアクセスも処理する機能を有する必要がある。

【００２２】ＣＳＤ３００内に記憶される使用者関係デ
ータは３つのエンティティの回りに構築される。３つの
エンティティ（すなわち加入者と使用者とサービス）と
それらの関係を図５に示す。エンティティ加入者５１０
はサービス網内で提供されるサービスの１つ以上の集合
すなわちパッケージ５２５に加入する。加入者５１０は
１つ以上の使用者５０５を所有する。使用者５０５はサ
ービス５２０を活発に利用する。使用者は、加入者５１
０が加入するサービスの集合５２５に属するサービスだ
けを使用することができる。使用者５０５は常に加入者
５１０に属していなければならない。加入者５１０は常
に一人以上の使用者５０５を所有する。多くの場合加入
者５１０と使用者５０５は同じ人であるが、例えばビジ
ネスの加入者の場合は、加入者は会社でよく、使用者は
その会社の社員でよい。

【００２３】概念的レベルでは、使用者と加入者とサー
ビスを識別するデータと、これらのエンティティの間の
関係の定義は、使用者データ・モデルと呼ぶデータ・モ
デルに従って構築される。使用者データ・モデルＵＤＭ
は実際の使用者関係データとサービス関係データだけで
なく、最終使用者のサービスへの加入を含む。またサー
ビス網内の重要な要素として活動して、連結データの記
憶場所を絶えず参照することによりサービス内の使用者
コンテキストの検索と管理を可能にするのはモデルであ
る。本発明では、ＣＳＤ３００内に記憶される最終使用
者関係データは使用者データ・モデルの原理に従って構
築される。得られたデータ記録を使用者データ記録ＵＤ
Ｒと呼び、これはＣＳＤ３００内に記憶される。連結デ
ータの記憶場所への参照は、ＣＳＤ３００内の記録か
ら、サービスを提供するシステムＡ３１０，Ｂ３２０，
Ｃ３３０内に記憶されている使用者関係データの一部へ
のリンク３４０，３５０，３６０に対応する。ＵＤＲは
別の種類のデータ（例えば、利用可能なサービスとその
特徴に関する情報）へのリンクも含んでよい。

【００２４】使用者データ・モデルの原理について、図
６を参照して説明する。使用者データ記録ＵＤＲはＵＤ
Ｍの原理に従って構築される。ＣＳＤ３００内に記憶さ
れるデータの構造は、データの内部複写を防ぎ、システ
ムに正しく連結して最も論理的にサービスを提供しまた
必要なデータを保持するように、慎重に設計しなければ
ならない。データを論理的にグループ化することにより
オブジェクトを作る。主要なオブジェクトは上に説明し
た主エンティティに対応する加入者と使用者とサービス
である。図内の矢印はオブジェクトの間のリンクを示
す。実施の形態はＣＳＤを構築するのに用いる技術に従
って変わってよいが、論理的なグループ化は同じでなけ
ればならない。

【００２５】好ましくは次のオブジェクトをＵＤＭ内に
含むべきである。 ・ 使用者６０５： 基本的な使用者情報（例えば、使
用者識別）を含む。使用者６０５は常に加入者６１０に
属する。 ・ 加入者６１０： 基本的な加入者情報（例えば、加
入者識別）を含む。 ・ カストマ・セグメント６１５： 加入者６１０を分
類するのに用いる。カストマ・セグメント記述と基本的
データを含む。 ・ 提供されるサービス６２０： サービスの基本的情
報を含む。 ・ サービス・パッケージ６２５： 提供されるサービ
ス６２０をパッケージ化するのに用いる。 ・ サービス・パッケージ加入６３０： 加入者６１０
がサービス・パッケージ６２５に実際に加入したことを
反映するのに用いる。

【００２６】・ サービス加入６３５： サービス・パ
ッケージ加入６３０の指定に従って加入者がサービス・
パッケージ内の個別のサービス６２０に実際に加入した
ことを反映するのに用いる。 ・ サービス・アクティベーション６４０： 使用者６
０５がサービス加入６３５からの個別のサービスを実際
に起動したことを反映するのに用いる。 ・ 加入者共用資源６４５： 加入者６１０が加入した
或るサービス内で用いられサービス加入６３５により指
定される共用資源の基本的データを含む。共用資源は、
他のサービス・システムによるサービスの実行を支援す
るのに必要なサービスを提供する任意のシステムであ
る。 ・ 使用者共用資源６５０： 使用者６０５が或る起動
されたサービス６４０で用いる共用資源の基本的データ
を含む。この共用資源は他のサービス・システムによる
サービスの実行を支援するのに必要な任意のシステムで
ある。

【００２７】使用者オブジェクト６０５と加入者オブジ
ェクト６１０は識別オブジェクトの例である。オブジェ
クト・サービス加入６３５とオブジェクト・サービス・
アクティベーション６４０はサービス・オブジェクトの
例である。サービス網２００内に存在する全てのサービ
スはＵＤＭに知られている。加入者６１０が或るサービ
スに加入する。提供されるサービス・オブジェクト６２
０は提供される全てのサービスについての情報を含み、
他のシステム内に記憶されているサービスに関係するデ
ータへの参照項目を保持する。好ましくは、複数のサー
ビスに関する詳細なデータは共通サービス・データベー
ス内に記憶する。共通サービス・データベースはサービ
スに関するより詳細な情報を含み、提供されるサービス
・オブジェクト６２０の内容は使用者のために特化され
たサービス情報を表す。これにより、提供されるサービ
ス６２０をＣＳＤ３００と共通サービス・データベース
との間の接触点と見なすことができる。加入者６１０は
サービスに１つずつ加入することもできるが、これでは
準備が面倒になる。好ましくは、同様のサービス、また
は同じ加入者を引き付けそうなサービスをグループ化す
る。これはオブジェクト・サービス・パッケージ６２５
に反映される。或るサービスは複数のサービス・パッケ
ージで提供してよい。また或るサービス・パッケージ
を、同じ特徴と期待ニーズを持つ加入者のグループに提
供してよい。このように加入者６１０をグループ化して
カストマ・セグメント６１５を作り、加入者６１０は自
分が属するカストマ・セグメントに提供される全てのサ
ービスに加入してよい。或るサービスをカストマ・セグ
メントに追加するときは１つ以上のサービス・パッケー
ジ６２５に含める。要するに、サービス・パッケージ６
２５は提供されるサービス６２０をグループ化し、カス
トマ・セグメント６１５は加入者６１０をグループ化す
る。

【００２８】加入者６１０はそのカストマ・セグメント
に提供されるサービスに、個別のサービスの形ではなく
サービス・パッケージ６２５の形で加入する。サービス
を別個に提供する必要がある場合でも、サービス・パッ
ケージ６２５に含めなければならない。オブジェクト・
サービス・パッケージ加入６３０は加入者が加入するサ
ービス・パッケージの情報を保持し、オブジェクト・サ
ービス加入６３５は含まれる個別の提供されるサービス
６２０に関する情報を保持する。これらは個別の使用者
６０５に提供されるサービスである。使用者は加入者が
加入する全てのサービスを用いてよいが、多くの場合、
使用者はサービスを選択する。使用者によるサービスの
選択はオブジェクト・サービス・アクティベーション６
４０に含まれる。オブジェクト・サービス・アクティベ
ーション６４０は連結データ（affiliate data）への参
照項目（references）を含む。

【００２９】複合サービスでは、例えば前に説明したホ
テルを予約する例のように、サービスを提供する２つ以
上のシステムが関わる必要があることが多い。位置決め
に基づくサービスは、一般に２つのシステム、移動体位
置決めセンタＭＰＣ（mobilepositioning centre）と、
移動体網（アクセス網）の使用者のプロフィールを記憶
するホーム加入者サーバＨＳＳ（home subscriber serv
er）とが関わる。ＭＰＣやＨＳＳなどのシステムは共用
資源またはサービス・イネーブラの例である。オブジェ
クト加入者共用資源６４５と使用者共用資源６５０は複
合サービスを提供する種々のシステムの間の依存性と、
これらのシステムの連結データへの参照項目とを含む。
依存性を指定することにより、１つのサービス・システ
ムに必要なデータが別のシステムにより変更または削除
されるのを防ぐことができる。例えば、別のサービス・
システムがその複合サービスを実行するのに加入／アク
ティベーションを必要とする場合は、ＭＰＣを用いる１
つのサービス・システムはＭＰＣの加入／アクティベー
ションを終了させる。

【００３０】複数の複合サービスが用いる共用資源の別
の例はカレンダである。種々の項目がどのようにして作
成されたかに関わらず、使用者は一般に全ての項目を示
す唯一のカレンダだけを希望する。上に述べたホテル予
約の例では、ホテルを予約するサービスは好ましくはカ
レンダにもアクセスして自動的に予約を入れる。使用者
は同じカレンダを用いて会議を予約したり誕生日を記憶
したりする。ビジネスの場合に加入者が希望するのは、
全ての使用者が共通のカレンダまたはそれぞれ相互のカ
レンダにアクセスすることが可能なこと、例えば使用者
のグループが会議に集まれる日を自動的にチェックする
という機能を用いることが可能なことである。このよう
に、サービス「カレンダ」は、使い方に従って、複合サ
ービスの独立のサービスとも、「ビルディング・ブロッ
ク」とも、サービス・イネーブラとも見なすことができ
る。

【００３１】本発明の別の実施の形態では、複合サービ
スを形成するサービスの間の依存性または共用資源の使
用は、ＣＳＤ内にではなく共通サービス・データベース
内に記憶される。この実施の形態では、サービスの間の
依存性は、ＣＳＤ内に使用者／加入者レベルで記憶され
るのではなく、共通サービス・データベース内にサービ
ス毎のレベルで記憶される。この別の実施の形態では、
サービス・システム内に記憶すべき依存性はより少なく
なる。なぜなら、依存性は多数の使用者に共通であり、
使用者の数は一般にサービスの数よりもはるかに多いか
らである。他方で、例えば使用者が複合サービスを停止
（deactivate）する場合は、サービスの間の依存性につ
いて知るために共通サービス・データベースにアドレス
指定しなければならない。全ての使用者／加入者に関係
するデータに対するするアクセス点を１つだけにすると
いう考え方を維持するため、使用者／加入者データを更
新する目的でサービスの間の依存性をチェックする場合
は、共通サービス・データベースへのアクセスは好まし
くはＳＡＰを通して行うようにする。

【００３２】サービス網は、例えばＧＳＭなどの回路交
換移動体システムや、ＧＰＲＳなどのパケット交換シス
テムや、ＵＭＴＳなどの結合システムなど、種々の通信
技術を用いて複数の異なるアクセス網にサービスを提供
する。ＵＤＭは、最終使用者がどのアクセス網を用いる
かだけでなく、アクセス網の使用者ＩＤや属性について
の情報を提供する。

【００３３】ＵＤＭの原理を示す例について図７を参照
して以下に説明する。この略図はサービス網内で提供さ
れる複数のサービスを利用する一人の加入者と二人の使
用者を示す。これはこの例を明確にするためであって、
本発明を制限するものではない。実際には、加入者／使
用者は多数のサービスを用いる。リッチマン家はカスト
マ・セグメント６１５：「ファミリーＶＩＰＳ」に登録
したサービス網カストマである。リッチマン家は「リッ
チマン氏」と「リッチマン夫人」と「息子」から成り、
実際にサービスに加入する資格があるのは父親である加
入者６１５：「リッチマン氏」 だけである。カストマ
・セグメントはサービス・パッケージ６２５：「パーテ
ィ・パック」とサービス・パッケージ：「ファイナン
ス」を彼らに提供する。

【００３４】連結データ６６０の「ボックス」はサービ
スに関わる全ての連結データを表す。この例では、連結
データ６６０は、提供されるサービス６２０「リムジン
予約」および「ジェット機予約」サービスと、共用資源
６５０「ＭＰＣ」の連結データである。注意すべきであ
るが、この例では提供されるサービス６２０「リムジン
予約」は位置に基づくサービスなので使用者共用資源６
５０「ＭＰＣ」に依存する。

【００３５】サービス・パッケージ６２５：「パーティ
・パック」は彼らが実際に必要とするものであって、彼
らはそれを購入した。これは、加入者６１０：「リッチ
マン氏」とサービス・パッケージ６２５：「パーティ・
パック」に関係する対応するサービス・パッケージ・オ
ブジェクトが存在することに反映されている。このサー
ビス・パッケージを購入すると、サービス・パッケージ
６２５：「パーティ・パック」に含まれる３つのサービ
ス加入６３５（提供されるサービス６２０毎に１つ）が
作成される。他方で、サービス・パッケージ６２５：
「ファイナンス」はまだこの家族には余り魅力がない。
これは、この目的のサービス・パッケージ加入６３０が
図の中に見られないので分かる。

【００３６】一人の使用者６０５：「リッチマン夫人」
は提供されるサービス６２０：「リムジン予約」を用
いる資格がある。これはサービス加入６３５（これは提
供されるサービス６２０：「リムジン予約」に関係す
る）に関係するサービス・アクティベーション・オブジ
ェクト６４０が存在することで表されている。また対応
する使用者データ・オブジェクトが使用者：「リッチマ
ン夫人」の「リムジン予約」連結データ内に存在する。
注意すべきであるが、これは彼女が今のところ用いるこ
とのできる唯一の提供されるサービスなので、彼女が別
のサービスを用いたいと思えば、それに応じて新しいサ
ービス・アクティベーション・オブジェクト６４０を作
成しなければならない。支払いは自分がするのだから、
加入者６１０：「リッチマン氏」はこれに対して同意を
与えなければならない。

【００３７】飛行機に乗りたい別の使用者６０５：「息
子」はこれも加入したサービス・パッケージ６２５：
「パーティ・パック」に含まれる提供されるサービス６
２０：「ジェット機予約」を用いる資格がある。また対
応する使用者データ・オブジェクトが使用者：「息子」
の「ジェット機予約」連結データ内に存在する。注意
すべきであるが、これは彼が今のところ用いることので
きる唯一の提供されるサービスなので、別のサービスを
用いたいと思えば、それに応じて新しいサービス・アク
ティベーション・オブジェクト６４０を作成しなければ
ならない。この場合も、支払いは結局自分がするのだか
ら、加入者：「リッチマン氏」はこれに対して同意を与
えなければならない。

【００３８】サービス・パッケージ６２５：「パーティ
・パック」内の第３の提供されるサービス６２０：「パ
ーティ設定」にはどの使用者も加入していないので、こ
のサービスとこれらの使用者については加入活動化オブ
ジェクトも連結データ内の使用者データも存在しない。
提供されるサービス６２０：「リムジン予約」は位置に
基づくサービスなので、使用者：「リッチマン夫人」も
ＭＰＣに準備されている。これは、対応する使用者共用
資源６５０とＭＰＣ連結データ内の使用者データ・オブ
ジェクトが存在することに反映されている。これに反し
て、提供されるサービス：「ジェット機予約」は共用資
源内に使用者データを準備する必要がないので、このサ
ービスに関係する使用者：「息子」に対しては使用者共
用資源オブジェクトが作成されていない。

【００３９】この例では、連結データ内に加入者データ
・オブジェクトも加入者共用資源オブジェクトもない。
なぜなら、この例の中のどの加入済みサービスも、異な
る使用者との共通の環境を必要としないからである（し
たがってこの例では、どの連結データにも加入者データ
を準備する必要がない。もっとも、本発明ではこの種の
準備をすることは可能であるが）。この例では、サービ
ス加入オブジェクトの役割は加入とこれに関係する提供
されるサービスとを単に連結することである。

【００４０】ＣＳＤ３００内に記憶されている使用者と
加入者とサービスのデータは上記のＵＤＭに従って構築
される。得られたデータ記録（data record）について
図８を参照して以下に説明する。図の中の矢印はフィー
ルドの間の依存性を示す。細い矢印は１対１の依存性を
示し、太い矢印は複数のフィールドの間の依存性を示
す。使用者データ記録ＵＤＲ８０３は、基本的な加入者
情報（例えば加入者識別）を含む加入者フィールド８１
０を含む。加入者が所有する使用者を１つ以上の使用者
フィールド８０５が指定する。使用者フィールド８０５
と加入者フィールド８１０は識別フィールドの例であ
る。カストマ・セグメント・フィールド８１５は加入者
の特徴を表し、また加入者に提供されるサービス・パッ
ケージを定義する。パッケージ毎に１つのサービス・パ
ッケージ・フィールド８２５は利用可能なサービス・パ
ッケージを定義し、また各サービス・パッケージ・フィ
ールド８２５には、別個のサービス毎の基本的サービス
情報を含む提供されるサービス・フィールド８２０が連
結する。

【００４１】サービス・パッケージ加入フィールド８３
０は加入者が加入したサービス・パッケージを定義し、
サービス毎に１つのサービス加入フィールド８３５は全
ての個別に利用可能なサービスを定義する。前に説明し
たように、各使用者はどのサービスを起動するかを選択
することができる（サービス・アクティベーション・フ
ィールド８３５のサービスから）し、また各使用者がサ
ービスを選択するにはサービス・アクティベーション・
フィールド８４０で指定する。したがって各使用者フィ
ールド８０５はサービス・アクティベーション・フィー
ルド８４０に連結する。サービス・アクティベーション
・フィールド８４０は連結データ（すなわち、サービス
・システム３４０，３５０，３６０内に記憶されている
最終使用者データの一部）へのリンクを含む。リンク
は、好ましくは連結データ記憶場所へのアドレス（例え
ば、ＩＰアドレス）である。サービス加入フィールド８
３５とサービス・アクティベーション・フィールド８４
０はサービス・フィールドの例である。使用者が選択し
た任意のサービスが共用資源を使用する必要がある（す
なわち、１つ以上の複合サービスが同じサービス・シス
テムを用いる）場合は、使用者共用資源フィールド８５
０内にシステムの間の依存性だけでなくこれらのシステ
ム内に記憶されている連結データへのリンクが含まれ
る。同様にして、加入者共用資源フィールド８４５は加
入者レベルでのシステムの間の依存性を含む。

【００４２】ＵＤＲは、連結データへのリンクだけでな
く例えば連結データにアクセスするまたは共用資源を用
いるのに必要な情報も含む。かかる情報の例は、種々の
サービスで用いられる使用者識別のための種々の手段で
ある。一般に識別子として、従来の電話サービスは電話
番号を用い、電子メール・サービスは電子メール・アド
レスを用い、カレンダ機能は別名を用いる。種々のサー
ビス・システムを用いる複合サービスは、使用者識別の
ための１つ以上のこれらの異なる手段を必要とする。使
用者識別の異なる手段は連結する必要がある（いわゆる
識別マッピング）。これは本発明に係るデータ・モデル
とデータ記録が、識別の種々の手段と属するサービスを
ＵＤＲ内に含むことにより、また好ましくはフィールド
内にサービス・システム（すなわち、加入者共用資源フ
ィールド８４５と、使用者共用資源フィールド８５０
と、サービス・アクティベーション・フィールド８４
０）へのリンクも保持することにより、提供する。

【００４３】上に述べたデータ記録とこれに含まれるフ
ィールドは、多くの方法で、主としてデータベースで用
いられる技術に従って実現することができる。かかる実
施の形態の詳細は当業者に明らかであると考えられる。
また上に述べた例以外のフィールドも連結データにリン
クする。しかし実施の形態を簡単にしてデータの一貫性
を高めるために、かかるリンクを行う異なるフィールド
の数は制限することが好ましいし、不必要なおよび／ま
たは二重のリンクは設けないように注意しなければなら
ない。

【００４４】サービス・アクティベーション・フィール
ド８４０と、加入者共用資源フィールド８４５と、使用
者共用資源フィールド８５０に含まれるリンクは、ＣＳ
Ｄ３００内に記憶される主な使用者データと、サービス
・システム３４０，３５０，３６０の連結データとの間
の唯一の接続点である。これは使用者データの一貫性を
保持するのに重要である。連結データはそのサービス・
システム内だけで用いなければならない。使用者および
加入者データの要求は、好ましくはＣＳＤフロントエン
ド４２０と、ＣＳＤフロントエンド４２０が加入者およ
び使用者データを検索する先のＵＤＲ８０３とにより実
現される、単一アクセス点に対して行わなければならな
い。

【００４５】前に説明した本発明の別の実施の形態で
は、サービスの間の依存性が共通サービス・データベー
ス内に記憶されている場合は、使用者共用資源フィール
ド８５０と加入者共用資源フィールド８４５は必要な
い。この場合、対応するフィールドは共通サービス・デ
ータベースのデータ記録内で提供される。

【００４６】最終使用者データを更新するなどのデータ
管理を行うときや、サービスを実行するに必要なデータ
を検索するなどの実時間使用のときは、ＳＡＰにアクセ
スしてよい。データ管理は、使用者管理、加入者管理、
サービス管理、カストマ・セグメント管理、サービス加
入およびアクティベーションおよびサービス・パッケー
ジ管理を含む。実時間使用はサービス・システム内でア
プリケーションを実行するときに起こる。アプリケーシ
ョンが例えば位置に基づくサービスを提供するとき、ア
プリケーションはＳＡＰから検索した或る使用者データ
を位置に基づくサービスに与える必要がある。別の例と
して、アプリケーションは連結データへの参照項目や、
使用者に関連する種々の使用者ＩＤ、名前、別名のいく
つかについての知識を必要とする。

【００４７】本発明のＳＡＰを用いて、本発明に係る使
用者および加入者データにアクセスする方法について、
図９の略図を参照して以下に説明する。ここではアクセ
シング機能性をクライアント９００で表す。クライアン
ト９００は上に述べたデータ管理機能または実時間使用
を行ってよい。詳細な例は、後でサブセクション「使用
事例」に示す。クライアントの使用の初期化は一般に、
サービスを行うサービス・システム内のアプリケーショ
ンにより、またはサービス網内のサービス提供者または
他のプレーヤにより初期化されたデータ管理アプリケー
ションにより行われる。したがって、或るクライアント
は或るサービス・システムにリンクすることが多い。し
かし必ずしもそうではない。この方法は次のステップを
含む。 ９１０： クライアントはＣＳＤフロントエンド４２０
を介してＳＡＰにアクセスする。好ましくは、アクセス
はデータ管理機能（例えば、読取りおよび／または書込
み許可）にアクセスする権利を確立する要求／許可手続
きを含む。

【００４８】９２０： クライアントは、一般に使用者
IＤまたは加入者ＩＤを参照することによりＣＳＤフロ
ントエンド４２０との間のデータの読取りおよび／また
は書込みを要求する。 ９３０： ＣＳＤインデックス・テーブル４１０を用い
ることにより、ＣＳＤフロントエンド４２０は分散デー
タベースの中の正しいデータベースにアクセスする。 ９４０： ＣＳＤフロントエンド４２０はＵＤＲ８０３
との間でデータを検索しまたは転送する。 ９５０： ＣＳＤフロントエンド４２０は要求されたデ
ータをクライアントに返す。

【００４９】随意であるが、この方法は次のステップを
含んでよい。 ９５５： ＳＡＰ内に記憶されていない使用者データ
（すなわち連結データ）へのアクセスをクライアントが
要求する場合は、まず上に述べたステップに従ってＳＡ
Ｐにアクセスする。クライアントは例えばサービス・ア
クティベーション・フィールド８４０から、連結データ
と、連結データにアクセスするのに必要な使用者ＩＤま
たは使用者名などの情報へのリンクを提供される。 ９６０： クライアントはＳＡＰからの情報を用いて連
結データ記憶場所にアクセスして、使用者関係データを
要求する。 ９６５： 連結データ記憶場所は使用者関係データをク
ライアントに返す。

【００５０】随意であるが、この方法は更に次のステッ
プを含んでよい。 ９７０： クライアントが使用者データを変更または削
除または追加しようとする場合は、種々のサービス・シ
ステムの間の依存性についてＵＤＲ８０３をチェックし
なければならない。すなわち、上に述べた例示の実施の
形態では、種々のサービス・システムの間の依存性につ
いて使用者共用資源フィールド８５０と加入者共用資源
フィールド８４５をチェックする。かかる依存性がある
場合は、使用者データが別のサービス・システムで使わ
れることがあるので普通は変更または削除してはならな
いとクライアントに通知する。

【００５１】管理活動の種類によって各ステップの詳細
は変わる。主要な機能は、使用者および加入者データの
変更をＳＡＰに送ることである。一般にサービス・シス
テム内に記憶されている連結データを変更するには、Ｓ
ＡＰにアクセスして当該連結データ記憶場所がどこにあ
るかの情報（すなわち、サービス・アクティベーション
・フィールド８４０と、使用者共用資源フィールド８５
０と、加入者共用資源フィールド８４５内に与えられる
情報）を得る。次に記憶場所の連結データに直接アクセ
スする。または、かかる機能性がＳＡＰに与えられてい
る場合は、ＳＡＰを通して連結データにアクセスする。

【００５２】ステップ９１０のアクセスは、ＩＰアドレ
スまたはＵＬＲを用いるなど、多数の異なる方法で行っ
てよい。またＳＡＰはＣＳＤフロントエンド４２０を介
して、種々の異なるアクセス方法および種々のアクセス
手段だけでなく複数の同時アクセスを扱うことができ
る。種々のアクセス方法が当業者に知られている。本発
明の上に説明した方法は、コンピュータ・プログラム製
品またはコンピュータ・プログラム製品の一部として実
現してよい。プログラム製品は例えばサービス網２００
内のサービス・システムに属するコンピュータ上で実行
する。

【００５３】本発明に係るＳＡＰと方法について、サー
ビス網内の全てのサービスに適用できるものとして説明
した。これは好ましい実施の形態である。ＳＡＰはサー
ビス網内で本発明を用いないサービス・システムと共存
することもできるが、本発明が提供する利点を用いるこ
とができるのはＳＡＰを用いるサービス・システムだけ
である。本発明について現在最も実用的で好ましいと考
えられる実施の形態に関して説明したが、理解されるよ
うに、本発明はここに開示した実施の形態に限定される
ものではなく、特許請求の範囲の精神と範囲内に含まれ
る種々の変更と同等の調整をカバーするものである。

【００５４】使用例 この例において管理者という用語は、サービス網内で一
般にクライアント・サーバの関係でソフトウエア・クラ
イアントを通して動作する管理の機能性を指す。データ管理 使用者管理 使用者を得る 期待される結果：ＳＮ使用者データ・モデル内の使用者
関係情報を検索する。 前提条件：少なくとも一人の使用者が存在しなければな
らない。 事例の説明：管理者は使用者情報を検索する必要があ
り、これをＳＡＰに要求する。管理者が正当な読取り許
可機能を有する場合は、要求された情報（使用者情報、
および／または加入者データ、および／または網アクセ
ス・データ、および／または使用者共用資源）を検索す
ることができる。ＳＮ使用者データ・モデルがこの情報
を提供したとき、場合によっては、管理者が用いるシス
テム（例えば、準備ツール）はＳＮ使用者データ・モデ
ルの外部の使用者情報を検索する（すなわち、実際の加
入データおよび／または使用者共用資源データが常駐す
る連結データ記憶場所に到達する）必要がある。このた
め、これらの連結データへ向うＳＮ ＳＡＰが保持する
検索された参照項目（使用者ＩＤとサービス・アドレス
を提供する）をたどり、その連結データが発行した当該
データ・アクセス・プロトコルを用いなければならな
い。

【００５５】使用者を作成する 期待される結果：新しい使用者が定義される。 前提条件：少なくとも一人の加入者が存在しなければな
らない。私的使用者の場合、加入者は使用者と同じプロ
セスで作成される。 事例の説明：管理者は新しい使用者を作成することを希
望する。このため、管理者は使用者の基本的データを入
力し、使用者が関連する加入者を選択する。次に、新し
い使用者記録をＳＡＰ内に作成して加入者に結合する。
使用者は単独で存在することができないので、この結合
はこのプロセスに固有である。なぜなら、加入者が作成
した加入だけを利用しなければならないからである。

【００５６】使用者を削除する 期待される結果：特定の使用者とその関連する全ての情
報をＳＡＰから削除する。 前提条件：少なくとも一人の使用者が存在しなければな
らない。 事例の説明：管理者は使用者をＳＡＰから削除すること
を希望する。管理者が用いるシステム（一般に準備シス
テム）はまず、サービス・データが常駐する連結データ
記憶場所へのサービス参照項目と使用者共用資源参照項
目を得て、各記憶場所に行ってそれぞれに記憶されてい
る使用者サービス・データを削除する。次に、使用者オ
ブジェクトの他に、加入者オブジェクト、および／また
は網アクセス・オブジェクト、および／または使用者共
用資源オブジェクトを消す。

【００５７】使用者を更新する 期待される結果：管理者は使用者データを変更する。 前提条件：少なくとも一人の使用者が存在しなければな
らない。 事例の説明：管理者（使用者自身でもよい）は使用者の
基本的データを変更することを希望する（唯一の影響を
受けるオブジェクトは使用者オブジェクトである）。Ｓ
ＡＰ内の使用者オブジェクト情報を更新する。

【００５８】加入者管理 加入者を得る 期待される結果：ＳＮ使用者データ・モデル内の加入者
に関する情報を検索する。 前提条件：少なくとも一人の加入者が定義されている。 事例の説明：管理者は加入者に関係する情報をＳＡＰに
要求する。この情報は次のどれかを含んでよい。すなわ
ち、加入者の基本的データ、サービス・パッケージ加
入、サービス加入データ、カストマ・セグメント・デー
タ、加入者共用資源データ、使用者のリストである。Ｓ
Ｎ使用者データ・モデルがこの情報を提供したとき、管
理者が用いるシステム（例えば、準備ツール）はＳＡＰ
の外部の加入者情報を検索する（すなわち、実際のサー
ビス加入データおよび／または加入者共用資源データが
常駐する連結データ記憶場所に到達する）必要がある。
このため、これらの連結データへ向うＳＡＰが保持する
検索された参照項目（使用者ＩＤとサービス・アドレス
を提供する）をたどり、その連結データが発行した当該
データ・アクセス・プロトコルを用いなければならな
い。

【００５９】サービス管理 サービスを得る 期待される結果：提供されるサービスをＳＡＰから取り
出す。 前提条件：少なくとも１つのサービスが定義されてい
る。 事例の説明：管理者は提供されるサービス情報をＳＮ
ＳＡＰに要求する。サービス・オブジェクト内に含まれ
るデータを検索する。

【００６０】サービスを追加する 期待される結果：新しい提供されるサービスのパッケー
ジ化が準備される。 前提条件：サービスがすでに開発され、配置され、形成
されている。すなわち、提供されるサービスが存在し、
その情報がＳＮの他の部分から利用できる。 事例の説明：提供されるサービスに加入できるようにす
るため、まず提供されるサービス・オブジェクトを作成
してＳＡＰに示す。提供されるサービスを作成すると
き、管理者は提供されるサービス・テンプレートを提供
しなければならない。

【００６１】カストマ・セグメント カストマ・セグメントを得る 期待される結果：カストマ・セグメントとこれに関連す
る情報をＳＡＰから検索する。 前提条件：少なくとも１つのカストマ・セグメントが存
在しなければならない。 事例の説明：管理者は、一般に準備システムを通して、
カストマ・セグメントに関連する情報を知る必要があ
る。かかる情報をＳＮ ＳＡＰに要求すると、ＳＮ ＳＡ
Ｐはカストマ・セグメント情報とこれに関連するサービ
ス・パッケージ情報（各サービス・パッケージ内に含ま
れるサービスを含む）を送る。 変形：更に、そのカストマ・セグメントに属する加入者
のリストを検索することができる。

【００６２】カストマ・セグメントを作成する 期待される結果：新しいカストマ・セグメントが定義さ
れ、加入者をこれに関連付けることができる。 前提条件：少なくとも１つのサービス・パッケージが存
在しなければならない。 事例の説明：カストマ区分により加入者の分類とサービ
スのグループ化が可能になる。各加入者は或る（１つ
の）カストマ・セグメントに属さなければならないの
で、加入者を定義する前にこれらを作成しなければなら
ない。このため、管理者はカストマ・セグメントを作成
して、いくつかの利用可能なサービス・パッケージをこ
れに結合する。かかるサービス・パッケージ内に含まれ
るサービスは、この新しいカストマ・セグメントに結合
する各加入者に提供するサービスで構成する。新しいカ
ストマ・セグメントはＳＡＰ内に追加され、選択された
サービスに連結される。

【００６３】サービス加入と活動化 加入を作成する 期待される結果：特定の使用者用の特定の提供されるサ
ービスを起動することができるようになる。次の０を参
照のこと。 前提条件：関係者（actor）（加入者）がサービス・パ
ッケージにすでに加入している。 事例の説明：加入者は、サービスを起動して使用者が用
いることができるようにしたいと希望する。既存の使用
者とは独立のサービス加入を介して、加入オブジェクト
を作成し、提供されるサービスに結合しなければならな
い。連結データ準備契約に従い、また提供されるサービ
ス・テンプレートの設定に従って固定加入関係情報を連
結データに準備することにより、使用者準備を行わなけ
ればならない。これにより、連結データ内に新しい使用
者データ・オブジェクトが作成される。加入オブジェク
トは連結データ内のこの使用者コンテキストを指すの
で、更なる活動化と他の準備に関係する活動が支援され
る。この参照項目は、アプリケーションが割り当てる使
用者ＩＤと連結のアドレスから成る。

【００６４】サービスを活動化する 期待される結果：サービスを初めて用いられるよう準備
する。 前提条件：この使用者とこの提供されるサービスに関係
する加入が上記に従ってすでに作成されている。 事例の説明：或る提供されるサービスの使用準備の最後
のステップはその起動である。管理者（場合によっては
単に使用者でよい）はその準備テンプレートに従うサー
ビス起動に必要な個人情報を提供する。起動設定はその
連結データ準備契約に従って連結データ記憶場所に送ら
れる。ＳＡＰ内の対応するオブジェクト（加入オブジェ
クト）が更新されて、サービスが起動したことを反映す
る。サービスが常駐する連結データ記憶場所への参照項
目（サービス使用者ＩＤと連結アドレス）と、サービス
とそれが必要とする共用資源との間の関係も確立しなけ
ればならない。

【００６５】実時間使用の事例 共用資源を得る 期待される結果：アプリケーションは使用者または加入
者が用いる共用資源を得る。アプリケーションはこの情
報を用いて、サービスを実行するために資源にアクセス
してよい。 前提条件：使用者のための少なくとも１つのサービスの
使用準備ができていなければならない。 事例の説明：アプリケーションが提供するサービスは、
実行時に、サービス実行プロセスを支援する共用資源に
アクセスする必要がある。例えば、位置に基づくサービ
スを提供するアプリケーションは、アクセス網から位置
情報を得るイネーブラにアクセスしてアプリケーション
に見えるようにする必要がある。このため、使用者／加
入者に属する共用資源についての情報を得ることを希望
するアプリケーションは、使用者の識別を用いてそれを
要求する。全ての可能な識別はＳＮ使用者データ・モデ
ル内に保持されており、また各サービスとその共用資源
とは関連があるので、要求された情報はアプリケーショ
ンに送られる。

【００６６】使用者ＩＤを得る 期待される結果：アプリケーションは任意の使用者ＩＤ
を得る。アプリケーションはサービスを実行するために
この情報を用いる。 前提条件：少なくとも一人の使用者が存在しなければな
らない。 事例の説明：アプリケーションが提供するサービスは使
用者の任意の識別を用いることができるが、サービスの
特徴によって、使用者の他の識別を知る必要がある（例
えば、電子メール・アドレスを持っていると、電子メー
ルをＳＭＳフォーマットで送るためにＭＳＩＳＤＮを知
りたいと思う）。ＳＮ ＳＡＰは全ての使用者識別を知
っているので、要求された情報を送る。

【００６７】サービス・リストを得る 期待される結果：加入したサービスのリストがＳＮ Ｓ
ＡＰにアクセスするエンティティに送られる。 前提条件：少なくとも一人の使用者が存在する。 事例の説明：認可のために、加入した使用者へのサービ
スのリストを得たいと思うエンティティがあるので、そ
のサービスを用いたいときは、この使用者がそのサービ
スを用いる権利を持つかどうかチェックする。このた
め、ＳＡＰは要求されるとこのリストを作成して送るこ
とができる。

【図面の簡単な説明】

上に概説した本発明の機能と利点について、以下の図面
に関連して詳細に説明する。図面中、同じ参照番号は同
じ要素を指す。

【図１】従来の垂直に統合された網の略図。

【図２】サービス網を構成する水平に層化された網の略
図。

【図３】本発明に用いられる共通使用者／加入者データ
ベースの略図。

【図４】本発明の単一アクセス点の略図。

【図５】本発明の基本的エンティティの間の関係。

【図６】本発明に係る使用者データ・モデルの略図。

【図７】本発明に係る使用者データ・モデルの使用例。

【図８】本発明に係る使用者データ記録の略図。

【図９】本発明に係る方法を示す略図。

【符号の説明】

２００ サービス網 ３００ 共通加入者／使用者データベース ６３５ サービス加入 ６４０ サービス起動 ８０３ 使用者データ記録 ８０５ 使用者フィールド ８１０ 加入者フィールド ８６０ 連結データ

フロントページの続き (72)発明者 マヌエル ロレンツォ エルナンデス スペイン国 マドリッド、オナ 37 ９エ イ (72)発明者 ジェンス ジョンソン スウェーデン国 リンケピング、トルンス ラガレガタン 52 (72)発明者 アンデルス エリクソン スウェーデン国 リンケピング、アレンデ ガタン 59 (72)発明者 イングヴァル ベルグ スウェーデン国 リンケピング、エストラ ストランドヴェーゲン ８ (72)発明者 ラルス ジェンセン スウェーデン国 ストックホルム、 エリ ク ダールベルグスガタン 55 ブイ Ｆターム(参考） 5K024 AA72 AA76 AA77 AA79 CC01 CC09 CC11 DD01 DD04 FF04 FF06 GG01 GG03 GG05 GG12 5K030 KA05 KA06 KA07 LB05

Claims (41)

【特許請求の範囲】
1. 【請求項１】 複数のサービスを提供する複数のサービ
   ス・システム（３１０，３２０，３３０）を有するサー
   ビス網（２００）内の使用者および加入者データを記憶
   しまた保持するシステムであって、前記システムは使用
   者および加入者情報を有する加入者／使用者データ記録
   を含む加入者／使用者データベースを備え、その特徴
   は、前記加入者／使用者データベースは複数のサービス
   に関係する加入者／使用者情報を保持する共通加入者／
   使用者データベース（３００）であることと、前記加入
   者／使用者データ記録（８０３）は、 ・ 加入者と使用者を識別する少なくとも１つの識別フ
   ィールド（８０５，８１０）と、 ・ 前記サービス網内で提供される前記複数のサービス
   から前記使用者または加入者が選択する少なくとも１つ
   の選択されたサービスを指定する少なくとも１つのサー
   ビス・フィールド（８３５，８４０）と、を含むことで
   あり、 前記少なくとも１つのサービス・フィールドの少なくと
   も１つは前記加入者／使用者に関係する連結データ（８
   ６０）にリンクし、前記連結データは前記共通加入者／
   使用者データベースの外部に記憶され、これにより前記
   共通加入者／使用者データベースと前記加入者／使用者
   記録は前記サービス網内の使用者および／または加入者
   データにアクセスする単一アクセス点を容易にする、使
   用者および加入者データを記憶し保持するシステム。
2. 【請求項２】 前記加入者／使用者データ記録は少なく
   とも２つのサービス・フィールド、すなわち、 ・ 前記サービス網内で提供される前記複数のサービス
   から選択される前記加入者が利用可能なサービスの第１
   のグループを指定するサービス加入フィールド（８３
   ５）と、 ・ 前記サービスの第１のグループから選択された、使
   用者によって起動されたサービスをそれぞれが指定する
   少なくとも１つのサービス・アクティベーション・フィ
   ールド（８４０）と、を含み、前記サービス加入フィー
   ルドおよび／またはサービス・アクティベーション・フ
   ィールドは加入者／使用者に関係する連結データにリン
   クし、また前記連結データは前記共通加入者／使用者デ
   ータベースの外部に記憶される、請求項１記載の使用者
   および加入者データを記憶し保持するシステム。
3. 【請求項３】 前記使用者データ記録は、 ・ 前記加入者に属する各使用者をそれぞれが識別する
   複数の使用者フィールド（８０５）と、 ・ サービス・アクティベーション・フィールド（８４
   ０）であって、各使用者フィールド（８０５）にリンク
   し、前記サービスの第１のグループから選択される各使
   用者が利用可能なサービスの使用者当たりのグループを
   指定し、また前記共通加入者／使用者データベースの外
   部に記憶されている連結データ（８６０）にリンクす
   る、使用者毎の少なくとも１つのサービス・アクティベ
   ーション・フィールド（８４０）と、を含む、請求項２
   記載の使用者および加入者データを記憶し保持するシス
   テム。
4. 【請求項４】 前記共通加入者データベースは分散デー
   タベース（４００）である、請求項３記載の使用者およ
   び加入者データを記憶し保持するシステム。
5. 【請求項５】 前記使用者データ記録は複合サービスを
   実行する種々のサービス・システムの間の依存性を記憶
   する、請求項３記載の使用者および加入者データを記憶
   し保持するシステム。
6. 【請求項６】 前記連結データへのリンクは、ＩＰアド
   レス、ＵＲＬ、ＨＴＭＬアドレス、またはＥ．１６３ア
   ドレスの形である、請求項３記載の使用者および加入者
   データを記憶し保持するシステム。
7. 【請求項７】 前記連結データへのリンクはＩＰに基づ
   く網内で認識されるアドレスの形である、請求項３記載
   の使用者および加入者データを記憶し保持するシステ
   ム。
8. 【請求項８】 使用者毎の前記使用者データ記録は前記
   使用者フィールドと前記サービス・アクティベーション
   ・フィールドとにリンクする使用者共用資源フィールド
   （８５０）を含み、前記使用者共用資源フィールドは使
   用者レベルのサービス・システムの間の依存性を記憶す
   る、請求項５記載の使用者および加入者データを記憶し
   保持するシステム。
9. 【請求項９】 前記使用者データ記録は前記加入者フィ
   ールド（８４５）と前記サービス加入フィールドとにリ
   ンクする加入者共用資源フィールドを含み、前記加入者
   共用資源フィールドは加入者レベルのサービス・システ
   ムの間の依存性を記憶する、請求項５記載の使用者およ
   び加入者データを記憶し保持するシステム。
10. 【請求項１０】 使用者毎の前記使用者データ記録は各
    使用者を識別するための複数の手段を記憶する、請求項
    ３記載の使用者および加入者データを記憶し保持するシ
    ステム。
11. 【請求項１１】 前記識別手段は、電話番号、個人識別
    コード、電子メール・アドレス、名前、または別名の１
    つ以上である、請求項１０記載の使用者および加入者デ
    ータを記憶し保持するシステム。
12. 【請求項１２】 前記識別手段はサービス・システムの
    間の依存性も記憶するフィールド内に記憶される、請求
    項１０記載の使用者および加入者データを記憶し保持す
    るシステム。
13. 【請求項１３】 異なるサービス・システム全体で複合
    サービスすなわち複数の他のサービスの共用資源として
    働く１つのサービス・システムを形成し、また異なるサ
    ービス・システムの間の依存性は共通サービス・データ
    ベース内に記憶される、請求項２記載の使用者および加
    入者データを記憶し保持するシステム。
14. 【請求項１４】 前記使用者データ記録は前記使用者が
    利用可能なサービスを指定する複数のフィールドを更に
    含み、前記複数のフィールドは、 ・ 前記加入者フィールド内で指定される加入者が利用
    可能なサービスのグループをそれぞれが指定する、少な
    くとも１つのサービス・パッケージ・フィールド（８２
    ５）と、 ・ 前記加入者フィールドの加入者を特徴づけまたサー
    ビス・パッケージを指定するカストマ・セグメント・フ
    ィールド（８１５）と、 ・ 前記サービス・パッケージ・フィールドが指定する
    サービス・パッケージに含まれる別個のサービス毎のサ
    ービス情報を含む少なくとも１つの提供されるサービス
    ・フィールド（８２０）と、を含む、請求項３記載の使
    用者および加入者データを記憶し保持するシステム。
15. 【請求項１５】 複数のサービスを提供する複数のサー
    ビス・システム（３１０，３２０，３３０）を有するサ
    ービス網（２００）内の使用者および加入者データを記
    憶しまた保持するデータ記録であって、前記システムは
    使用者および加入者情報を有する加入者／使用者データ
    記録を含む加入者／使用者データベースを備え、その特
    徴は、前記加入者／使用者データベースは複数のサービ
    スに関係する加入者／使用者情報を保持する共通加入者
    ／使用者データベース（３００）であることと、前記加
    入者／使用者データ記録（８０３）は、 ・ 加入者と使用者を識別する少なくとも１つの識別フ
    ィールド（８０５，８１０）と、 ・ 前記サービス網内で提供される前記複数のサービス
    から前記使用者または加入者が選択する少なくとも１つ
    の選択されたサービスを指定する少なくとも１つのサー
    ビス・フィールド（８３５，８４０）と、を含むことで
    あり、 前記少なくとも１つのサービス・フィールドの少なくと
    も１つは前記加入者／使用者に関係する連結データ（８
    ６０）にリンクし、前記連結データは前記共通加入者／
    使用者データベース（３００）の外部に記憶され、 これにより前記共通加入者／使用者データベースと前記
    加入者／使用者記録は前記サービス網内の使用者および
    ／または加入者データにアクセスする単一アクセス点を
    容易にする、データ記録。
16. 【請求項１６】 前記加入者／使用者データ記録（８０
    ３）は少なくとも２つのサービス・フィールド、すなわ
    ち、 ・ 前記サービス網内で提供される前記複数のサービス
    から選択される前記加入者が利用可能なサービスの第１
    のグループを指定するサービス加入フィールド（８３
    ５）と、 ・ 前記サービスの第１のグループから選択された、使
    用者によって起動されたサービスをそれぞれが指定する
    少なくとも１つのサービス・アクティベーション・フィ
    ールド（８４０）と、を含み、 前記サービス加入フィールドおよび／またはサービス・
    アクティベーション・フィールドは前記加入者／使用者
    に関係する連結データにリンクし、また前記連結データ
    は前記共通加入者／使用者データベースの外部に記憶さ
    れる、請求項１５記載のデータ記録。
17. 【請求項１７】 前記使用者データ記録は、 ・ 前記加入者に属する各使用者をそれぞれが識別する
    複数の使用者フィールド（８０５）と、 ・ サービス・アクティベーション・フィールド（８４
    ０）であって、各使用者フィールドにリンクし、前記サ
    ービスの第１のグループから選択される各使用者が利用
    可能なサービスの使用者当たりのグループを指定し、ま
    た前記共通加入者／使用者データベースの外部に記憶さ
    れている連結データ（８６０）にリンクする、使用者毎
    の少なくとも１つのサービス・アクティベーション・フ
    ィールド（８４０）と、を含む、請求項１６記載のデー
    タ記録。
18. 【請求項１８】 前記使用者データ記録は複合サービス
    を実行する種々のサービス・システムの間の依存性を記
    憶する、請求項１６記載のデータ記録。
19. 【請求項１９】 使用者毎の前記使用者データ記録は前
    記使用者フィールドと前記サービス・アクティベーショ
    ン・フィールドとにリンクする使用者共用資源フィール
    ド（８５０）を含み、前記使用者共用資源フィールドは
    使用者レベルのサービス・システムの間の依存性を記憶
    する、請求項１８記載のデータ記録。
20. 【請求項２０】 前記使用者データ記録は前記加入者フ
    ィールドと前記サービス加入フィールドとにリンクする
    加入者共用資源フィールド（８４０）を含み、前記加入
    者共用資源フィールドは加入者レベルのサービス・シス
    テムの間の依存性を記憶する、請求項１８記載のデータ
    記録。
21. 【請求項２１】 使用者毎の前記使用者データ記録は各
    使用者を識別するための複数の手段を記憶する、請求項
    １７記載のデータ記録。
22. 【請求項２２】 前記識別手段は、電話番号、個人識別
    コード、電子メール・アドレス、名前、または別名の１
    つ以上である、請求項２１記載のデータ記録。
23. 【請求項２３】 前記識別手段はサービス・システムの
    間の依存性も記憶するフィールド内に記憶される、請求
    項２１記載のデータ記録。
24. 【請求項２４】 前記使用者データ記録は前記使用者が
    利用可能なサービスを指定する複数のフィールドを更に
    含み、前記複数のフィールドは、・ 前記加入者フィー
    ルド内で指定される加入者が利用可能なサービスのグル
    ープをそれぞれが指定する、少なくとも１つのサービス
    ・パッケージ・フィールド（８２５）と、 ・ 前記加入者フィールドの加入者を特徴づけまたサー
    ビス・パッケージを指定するカストマ・セグメント・フ
    ィールド（８１５）と、 ・ 前記サービス・パッケージ・フィールドが指定する
    サービス・パッケージに含まれる別個のサービス毎のサ
    ービス情報を含む少なくとも１つの提供されるサービス
    ・フィールド（８２０）と、を含む、請求項１７記載の
    データ記録。
25. 【請求項２５】 複数のサービスを提供する複数のサー
    ビス・システム（３１０，３２０，３３０）を有するサ
    ービス網（２００）内の使用者および加入者データを記
    憶しまた保持する使用者データ・モデルであって、前記
    システムは使用者および加入者情報を有する加入者／使
    用者データ記録を含む加入者／使用者データベースを備
    え、その特徴は、前記使用者データ・モデルは共通加入
    者／使用者データベース（３００）への使用者および加
    入者データの記憶を容易にすることと、前記共通加入者
    ／使用者データベースは複数のサービスに関係する加入
    者／使用者情報を保持することと、使用者データ・モデ
    ルは、 ・ 加入者と使用者を識別する少なくとも１つの識別オ
    ブジェクト（６０５，６１０）と、 ・ 前記サービス網内で提供される前記複数のサービス
    から前記使用者または加入者が選択する少なくとも１つ
    の選択されたサービスを指定する少なくとも１つのサー
    ビス・オブジェクト（６３５，６４０）と、を含むこと
    であり、 前記少なくとも１つのサービス・オブジェクトの少なく
    とも１つは前記加入者／使用者に関係する連結データ
    （６６０）にリンクし、前記連結データは前記共通加入
    者／使用者データベースの外部に記憶され、 これにより前記共通加入者／使用者データベースと前記
    データ・モデルは前記サービス網内の使用者および／ま
    たは加入者データにアクセスする単一アクセス点を容易
    にする、データ・モデル。
26. 【請求項２６】 前記加入者／使用者データ記録は少な
    くとも２つのサービス・オブジェクト、すなわち、 ・ 前記サービス網内で提供される前記複数のサービス
    から選択される前記加入者が利用可能なサービスの第１
    のグループを指定するサービス加入オブジェクト（６３
    ５）と、 ・ 前記サービスの第１のグループから選択された、使
    用者によって起動されたサービスをそれぞれが指定する
    少なくとも１つのサービス・アクティベーション・オブ
    ジェクト（６４０）と、を含み、 前記サービス加入オブジェクトおよび／またはサービス
    ・アクティベーション・オブジェクトは加入者／使用者
    に関係する連結データにリンクし、また前記連結データ
    は前記共通加入者／使用者データベースの外部に記憶さ
    れる、請求項２５記載のデータ・モデル。
27. 【請求項２７】 前記使用者データ・モデルは、 ・ 前記加入者に属する各使用者をそれぞれが識別する
    複数の使用者オブジェクト（６０５）と、 ・ サービス・アクティベーション・オブジェクト（６
    ４０）であって、各使用者オブジェクトにリンクし、前
    記サービスの第１のグループから選択される各使用者が
    利用可能なサービスの使用者当たりのグループを指定
    し、また前記共通加入者／使用者データベース（３０
    ０）の外部に記憶されている連結データにリンクする、
    使用者毎の少なくとも１つのサービス・アクティベーシ
    ョン・オブジェクト（６４０）と、を含む、請求項２６
    記載のデータ・モデル。
28. 【請求項２８】 前記使用者データ・モデルは複合サー
    ビスを実行する種々のサービス・システムの間の依存性
    を定義する、請求項２７記載のデータ・モデル。
29. 【請求項２９】 使用者毎の前記使用者データ・モデル
    は前記使用者オブジェクトと前記サービス・アクティベ
    ーション・オブジェクトとにリンクする使用者共用資源
    オブジェクト（６５０）を含み、前記使用者共用資源オ
    ブジェクトは使用者レベルのサービス・システムの間の
    依存性を定義する、請求項２８記載のデータ・モデル。
30. 【請求項３０】 前記使用者データ・モデルは前記加入
    者フィールドと前記サービス加入オブジェクトとにリン
    クする加入者共用資源オブジェクト（６４５）を含み、
    前記加入者共用資源オブジェクトは加入者レベルのサー
    ビス・システムの間の依存性を定義する、請求項２８記
    載のデータ・モデル。
31. 【請求項３１】 使用者毎の前記使用者データ・モデル
    は各使用者を識別するための複数の手段を定義する、請
    求項２８記載のデータ・モデル。
32. 【請求項３２】 前記識別手段は、電話番号、個人識別
    コード、電子メール・アドレス、名前、または別名の１
    つ以上である、請求項３１記載のデータ・モデル。
33. 【請求項３３】 前記識別手段はサービス・システムの
    間の依存性も記憶するオブジェクト内で定義される、請
    求項３１記載のデータ・モデル。
34. 【請求項３４】 前記使用者データ・モデルは前記使用
    者が利用可能なサービスを指定する複数のオブジェクト
    を更に含み、前記複数のオブジェクトは、 ・ 前記加入者オブジェクト（６１０）が指定する加入
    者が利用可能なサービスのグループをそれぞれが指定す
    る、少なくとも１つのサービス・パッケージ・オブジェ
    クト（６２５）と、 ・ 前記加入者オブジェクトの加入者を特徴づけまたサ
    ービス・パッケージを指定するカストマ・セグメント・
    オブジェクト（６１５）と、 ・ 前記サービス・パッケージ・オブジェクトが指定す
    るサービス・パッケージに含まれる別個のサービス毎の
    サービス情報を含む少なくとも１つの提供されるサービ
    ス・オブジェクト（６２０）と、を含む、請求項２７記
    載のデータ・モデル。
35. 【請求項３５】 複数のサービスを提供する複数のサー
    ビス・システムを含むサービス網内の使用者および加入
    者データにアクセスする方法であって、 ・ サービス網内の単一アクセス点にアクセスする（９
    １０）ステップと、 ・ 前記単一アクセス点との間のデータの読取りおよび
    /または書込みを要求する（９２０）ステップと、 ・ 前記単一アクセス点を介して、請求項１５から２４
    までの任意の項に定義されている加入者／使用者データ
    記録との間でデータを検索しまたは転送する（９３０−
    ９５０）ステップと、を含む、使用者および加入者デー
    タにアクセスする方法。
36. 【請求項３６】 更に、・ 前記使用者データ記録が種
    々のサービス・システムの間の依存性に関する情報を含
    むかどうかチェックする（９７０）、ステップを含む、
    請求項３５記載の使用者および加入者データにアクセス
    する方法。
37. 【請求項３７】 前記チェックするステップは、 ・ 種々のサービス・システムの間の依存性を示すリン
    クについて、前記サービス・アクティベーション・フィ
    ールド（８４０）と、使用者共用資源フィールド（８５
    ０）と、加入者共用資源フィールド（８４５）とをチェ
    ックする、ことを含む、請求項３６記載の使用者および
    加入者データにアクセスする方法。
38. 【請求項３８】 前記単一アクセス点内に記憶されてい
    ない連結データが必要な場合にとられるステップ、すな
    わち、 ・ 前記連結データへのリンクと前記連結データにアク
    セスするのに必要な情報とを検索するために前記単一ア
    クセス点にアクセスする（９５５）ステップと、 ・ 前のステップで検索したリンクと情報を用いて連結
    データ記憶場所にアクセスする（９６０）ステップと、
    を更に含む、請求項３５記載の使用者および加入者デー
    タにアクセスする方法。
39. 【請求項３９】 前記各ステップはソフトウエア・クラ
    イアントが実行する、請求項３５−３８のどれか記載の
    使用者および加入者データにアクセスする方法。
40. 【請求項４０】 請求項３５−３９に記載のステップを
    制御するソフトウエア・コード手段を含む、サービス網
    内のユニット内の処理手段の内部メモリに直接ロードす
    ることが可能なコンピュータ・プログラム製品。
41. 【請求項４１】 サービス網内の或るユニットの処理ユ
    ニット内の処理手段により請求項３５−３９記載の任意
    のステップの実行を制御する読取り可能なプログラムを
    含む、コンピュータが使用可能な媒体に記憶されるコン
    ピュータ・プログラム製品。