JP2003520533A - 通信網 - Google Patents

Abstract

(57)【要約】 応用プログラミングインターフェース（ＡＰＩ）を実現する網における登録サーバはサービスを認証してから網資源のディスカバリィを用意することを選ばれた網資源にサービスを登録する。サービス及び／又は複数のサービスノードは単一のサービス合意の中で登録される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

この発明は通信網に係り、とくに登録（レジストレーション）サーバと、この
ような網の中での資源に対するプログラマブルインターフェースを実現するその
他の部品とに関する。

【０００２】

【従来の技術】

従来は、遠隔通信網における高度に進んだ通信サービスは、インテリジェント
網（ＩＮ：intelligent network）構造を用いて実施されてきた。このような構
造では、最新の進んだサービスを実施するのに必要とされた制御論理と各種の網
資源とは密接に通信網と統合されていて、一般には網オペレータの制御の下で実
行が進むように意図されている。このようなやり方は堅牢な大規模の応用が実施
できるようにしている。しかしながら、この構造は比較的に融通性がないので、
新しいサービスを開発し展開することは時間のかかるものとなっている。さらに
、網オペレータ以外にサービスプロバイダにとって網資源を利用可能とし、しか
もセキュリティ（安全）と網の完全性（インテグリティ）とを維持することは困
難となっている。

【０００３】

【発明が解決しようとする課題】

最近、開発に関心がもたれている通信応用は、網の縁（エッジ）に置かれた計
算機処理用プラットホームを用いる応用であり、サービスプロバイダの直接制御
の下で一般に動作するプラットホームを用いることである。しかしながら、この
ような計算機と電話との統合（ＣＴＩ）応用は間接的なしかも制限されたアクセ
スだけを網のもつ能力に対して有しているのであるから、このやり方はときとし
て網資源の不十分な使用を結果している。

【０００４】 通信網として応用プログラミングインターフェース（ＡＰＩ）を、網内に組入
れられたサービス部品間と網の縁で実行されている応用間とに含ませた通信網を
実施することが提案されている。このようなやり方は規模についての経済性とい
う利益と、通常の網インテリジェンス構造によって提供される信頼性について利
益とを、網の縁のフレキシビリティ（融通性）とアクセシビリティ（アクセス可
能性）と組合せるやり方となっている。

【０００５】

【課題を解決するための手段】

上述のＡＰＩを含んでいる網は本願出願人とParlay Organisationの他のメン
バと共同で開発された。Parlay OrganisationはＡＰＩについての仕様書を実施
を支援する資源と一緒に、刊行している。Parlay APIの全体像は“Parlay API B
usiness Benefits White Paper”，Parlay Organisation，11 June 1999，www.p
arlay.org.刊，Version１．２及び２，Parlay API仕様書という文書の中に含ま
れていて、ここにあげたサイトで入手可能である。

【０００６】 サービスＡＰＩを備えた通信網を実施する際に、登録サーバが使用されて網の
縁（edge-of-network）サービス応用により、サービス資源を用意する網内の部
品へのアクセスを制御する。登録サーバは認証（オーセンティケーション）プロ
セスを実行するために使用することができて、このプロセスではサービス応用の
識別子とアクセス網資源へのその応用の所有者についての権原とがチェックされ
、この際には、例えばディジタルシグネチャ（署名）と、網の権原のある（承認
された）使用者をリストしているデータベースとが使用される。登録サーバはま
たディスカバリィ（事実開示）のプロセスについても使用でき、ここではサービ
ス応用からの要求に応答して、登録サーバが利用可能な網資源の詳細を用意する
。その後に、登録サーバはサービス応用をいくつかのサービス資源とともに登録
する。これは、サービス応用に向けて論理識別子とサービスマネージャオブジェ
クトの物理アドレスを特定のサービスノード上で通信すること、及び／又は対応
しているサービス応用を識別するデータをサービスマネージャオブジェクトに向
けて通信することによって行なわれる。

【０００７】 この発明の第一の特徴（アスペクト）によると、次の方法が用意されている。

【０００８】 すなわち、通信網を動作する方法であって、該通信網は少くとも一つのサービ
スノードと、該少くとも一つのサービスノードへのサービス応用によるアクセス
を制御するようにされた登録サーバと、いくつかの通信サービスを実行している
登録プラットホームから遠隔のプラットホームとを含んでおり、また該方法は、 ａ）該通信網に接続された該もしくは各サービスノード上で利用可能なサービス
資源を識別するデータを配信することと、 ｂ）該登録サーバに対して通信をして、段階ａ）で識別されたサービス資源の少
くともあるものに対する前記プラットホームによるアクセスを要求することと、 ｃ）該登録サーバにおいて、段階（ｂ）の要求に応答して、前記要求されたサー
ビス資源を用意している少くとも一つのサービスノードへの該サービス応用によ
るアクセスを許すサービス合意を実行することと、 ｄ）後に該サービス応用を少くとも一つのサービスノードに義務履行させること
とを含んでいて、 前記段階ｃ）では、該サービス合意が該サービス応用の複数の事例を特定するか
、複数のサービスノードを特定するかあるいはその両方を行ない、かつ前記段階
ｄ）では、 （ｉ）該サービス応用の複数の事例を該少くとも一つのサービスノードに束縛す
る（バインド、義務履行させる）ことと、 （ii）該サービス応用の少くとも一つの事例を複数のサービスノードに束縛する
（バインド、義務履行させる）ことと、 のうちの少くとも一つを含んでいることを特徴とする通信網を動作する方法であ
る。

【０００９】 この出願の記述とクレームとでは、用語“サービスノード”は広義に使用され
ていて、通信サービスを実行するための資源を用意している網のノードを言うも
のとしている。それには、いずれの意味でも限定をかける積りはなく、計算機処
理用プラットホームであって網の縁に置かれ、かつメッセージング（メッセージ
送付）のような特殊サービスに使用されるものを含んでいる。以下に記述する例
では、サービスノードはＩＮ（インテリジェント網）構造を用いる網内のサービ
ス制御ポイントである。

【００１０】 この発明は通信網内でＡＰＩを実現する方法を用意していて、これによると高
度な回復力（レジレンス）を求められている応用を支持することがよくできる。
これが達成されるのはＡＰＩの実施を修復することによるもので、それによって
登録プロセスがもはや一対一のバインデング（義務を履行させる結合関係）をサ
ービス応用とサービスノードとの間で作ることに対して制限を加えない。がこれ
に代って、サービス応用のいくつかの事例（インスタンス）がノードで登録され
るようにするか、あるいはいくつかの異なるノードが一つのサービス応用に登録
されるか、またはその両方ができるようにしている。

【００１１】

【発明の実施の形態】

この発明を実施するシステムについて添付の図面を参照して詳細に記述して行
く。

【００１２】 通信網はアクセス網１とコア網２とを備えている。顧客端末３ａ，３ｂがアク
セス網１に接続されている。サービスプロバイダプラットホーム４ａ，４ｂもま
たアクセス網１に接続されている。登録サーバ５は網に接続され、以下に記述す
るようにＡＰＩ（アプリケーション プログラマーズ インターフェース）を網
資源に対して実現するのに使用される。これらの網資源は多数のサービスノード
６ａ，６ｂ，６ｃを含み、その各々はそれぞれのゲートウェイＧＷ１，ＧＷ２，
ＧＷ３を含んでいる。サービスノードはハードウェアとソフトウェアとを含んで
いて、それが例えば番号（ナンバ）変換（ほん訳）応用、対話形音声認識及びメ
ッセージングサービスを実行する。上述のように、用語“サービスノード”はこ
こでは広義に使用されていて、サービス応用を実行するのに使用されるノードを
指していて、網の縁の位置にあるノードに限定されていない。

【００１３】 図２はサービス資源ノードの一つの構造をさらに詳細に示している。この例で
は、サービスノードは網インテリジェンスプラットホーム（ＮＩＰ）として知ら
れているプラットホームである。そこには多数の通信サービス（ＣＳ）を含んで
いて、ＣＳは網シグナリングを終端し、この例ではシグナリングシステム（ＳＳ
７）共通チャンネルシグナリングとなっている。グローバルデータサーバ（ＧＤ
Ｓ）はシグナリングレートを監視して、呼の統計を集めている。トランザクショ
ンサーバ（ＴＳ）は基本的なサービス制御機能であってサービスノードにより求
められているものを実施する。オーバーロード制御サーバ（ＯＣＳ）は過負荷制
御保護をサービスノードについてと、サービスノードから下流の部品についてと
の両方に対して実施する。例えば、ＯＳＣは過負荷状態が検出されるときにはコ
ールギャッピング（呼の間隔をとる）を始動させる。オーバーロート制御サーバ
とトランザクションサーバとは共通高速バスに接続されている。ゲートウェイ（
ＧＷ）はサービスマネージャオブジェクトの多数の事例を支持していて、このオ
ブジェクトは特定のサービス応用に対して、サービスノード内部の異なる部品の
資源を割当てる。サービスノードを作り上げている異なるサーバはそれぞれが各
ＵＮＩＸ（登録商標）ワークステーション上で実施される。異なるサーバは高速
光ファイバ（ＦＤＤＩ）ローカルエリア網（ＬＡＮＳ）２１，２２を介して通信
する。

【００１４】 図３に模式的に示したように、通信網は、応用プログラマーズインターフェー
ス（ＡＰＩ）を、網の縁でいわゆる“エンタープライズ（事業）ドメイン”で実
行している応用と網オペレータドメインでサービスを実施するのに使用される網
部品との間で実現する。この例では、インターフェースはParlay API仕様書に規
定されている。

【００１５】 図４はParlayインターフェースを実施している網の部品間のインターフェース
をもっと詳細に示している。このインターフェースはオブジェクト指向のもので
、インターフェースの二つのカテゴリィを用いて実施される。第一はサービスイ
ンターフェースであり、第二はフレームワークインターフェースである。応用の
サービスインターフェースは網のもつ能力機能にアクセスする。フレームワーク
インターフェースはサービスインターフェースについて環境を用意する。フレー
ムワークインターフェースは認証、ディスカバリィ及び登録というプロセスを実
現する。フレームワークオブジェクトで網ドメインにあるものは、クライアント
ＦＷ（フレームワーク）オブジェクトでユーザドメインにあるものと通信をする
。加えて、クライアント応用とParlayサービスとの間に直接インターフェース４
．２が存在する。しかし、こういった直接インターフェース４．２は通常はある
応用がフレームワークインターフェース４．１を介してサイン・オン（計算機へ
のアクセス、すなわちログオンと同義）した後に限ってアクセスされる。

【００１６】 この例では、フレームワークＦＷを実現するオブジェクトが登録サーバ５の上
に置かれている。クライアント応用とクライアントＦＷとはサービスプラットホ
ーム４ａ，４ｂ上で実行する。Parlayサービスでゲートウェイを含むものがサー
ビスノード６ａ，６ｂ，６ｃで実施される。

【００１７】 クライアント応用の一つが初期化されるときには、まず登録サーバを経由して
Parlay APIにログオン（サイン・オン）される。Parlay認証オブジェクトは登録
サーバ上で初期化されて、認証インターフェースを用意し、これが登録サーバと
クライアント応用との相互認証を可能とする。認証プロセスでは、応用は識別用
コードを登録サーバに戻す。登録サーバは認識された応用についてのデータベー
スを含んでいる。登録サーバは応用ＩＤ上でルックアップ（一覧）を実行しまた
応用に特有の暗号キーを検索することもできる。

【００１８】 ディスカバリィ相（フェーズ）では、応用は登録サーバから、財産名と財産価
値とによって識別されたサービス特徴のディスカバリィを要求する。Parlay API
仕様書は財産名の組を定義する。Parlayサービスは適当な名前を用いて登録サー
バに登録する。ディスカバリィ要求に応答して、登録サーバはサービスＩＤを戻
すが、このＩＤは要求された網サービスを識別する。後に、応用はサービスを選
ぶ。これをするために応用はサーバに対して、ディスカバリィ問合せに応答して
受取ったサービスＩＤを戻す。登録サーバはそこでサービストークンを戻すが、
このトークンはサービスの事例（インスタンス）をユニークに識別する。その結
果、応用がサービスを使用できる前に、応用は登録サーバとの合意をディジタル
的にサインする。ディジタルシグネチャ（署名）は応用ＩＤとサービストークン
とを含んでいるデータとともに記憶される。ディジタル合意（アグリーメント）
は、例えば、後に網オペレータによる課金を網サービスの使用について行うとき
の基礎として使用される。合意がサインされてしまうと、登録サーバは応用に対
して要求された網サービスマネージャインターフェースを実施するオブジェクト
についての参照基準（レファレンス）を戻す。

【００１９】 Parlayインターフェースの上述した実施はさらにParlay API仕様書１．２に詳
述されている。しかし、この発明の実施には各インターフェースに対して若干の
修正が求められている。便利に実施するのであれば、各単一のサービス合意でPa
rlayインターフェースを用いて作られるものは、単一のゲートウェイを単一のク
ライアント応用にリンクするようにしている。この発明を実施する現在の網では
、インターフェースは修正されて、複数のゲートウェイを複数のクライアント応
用に、単一のサービス合意の下で、リンクするようにしている。このやり方でPa
rlayサポートのエンドユーザサービスにとってゲートウェイかクライアント応用
かの故障に対して弾力的で回復力のあるものとすることが可能である。各サービ
スマネージャでゲートウェイ内に置かれているものは初期事象の通知を送ること
が可能とされていて、例えば、到来呼の通知を、配信アルゴリズムを用いて利用
可能なクライアント応用に向けて送ることができて、このアルゴリズムは例えば
ラウンドロビンアルゴリズムである。同じように、クライアント側では、クライ
アント応用サポートレイヤは初期セッション要求をインボーク（呼出す）ことが
できる。例えば、呼を発する要求は配信アルゴリズムを用いて多数の利用可能な
ゲートウェイの一つに向けてすることができる。こういった特徴に加えて、フレ
ームワークＦＷは今ではポーリング機構を含んでいて、登録したサービスをサポ
ートするゲートウェイの現在の状態を検出するのにあてる。故障したゲートウェ
イの検出は警報をトリガするために使用できる。クライアント応用に仕えている
ゲートウェイの各々についての利用可能性はクライアントフレームワークに向け
て送られる。機能停止の後で回復されたゲートウェイが検出されるときには、フ
レームワークは新しいサービスマネージャのインスタンシエーション（事例を挙
げての例証）を求め、新しいサービスマネージャについてのレファレンス（参照
基準）をクライアントＦＷに向けて送る（投函，ポスト）クライアントＦＷはポ
ーリング機構を実現し、これがクライアント応用の現在の状態を検出する。故障
したクライアント応用の検出は警報をトリガするのに使用されてよい。クライア
ント応用の各々についての利用可能性はフレームワークＦＷに向けて報告される
。回復されたクライアント応用が機能停止の後で検出されるときには、クライア
ントＦＷは新しいクライアント応用に向けてサービスマネージャに対するレファ
レンスの全リストを通信する。

【００２０】 Parlay APIについての修正は図４に示した特殊インターフェースの各々との関
係でここで記述することとする。これらのインターフェースの一つは、クライア
ントフレームワークとクライアント応用との間でParlay API仕様書の一部を形成
していないが、ここでは全体としてシステムの記述に対する支援として定義され
ている。

【００２１】 ＦＷ−サービスインターフェース Parlayサービス登録 １．ParlayサービスはＦＷで登録される。Parlayサービスが複数のゲートウェイ
をまたいで支持されることができるためには、Parlayサービスの登録は、そのサ
ービスを支持している個々のゲートウェイの登録からは異なっている。図５のメ
ッセージシーケンスチャートに示すように、サービスノードは先ずＦＷでの登録
を要求し、後にサービスを支持しているゲートウェイ全部の登録をインボークす
る（実施する）。別個の実施呼び出し（インボケーション）が各ゲートウェイに
送られる。

【００２２】 開始（スタートアップ） １．図６に示すように、ＦＷは、Parlayサービスを支持しているすべてのゲート
ウェイ内でParlayサービスゲートウェイマネージャを作ることを要求する。新し
いサービスゲートウェイマネージャについてのレファレンスはゲートウェイによ
って戻される。 ２．一度、義務履行の結合関係（バインド）が完了すると、ＦＷはグローバル（
全地球規模の）事象通知情報をサービスゲートウェイマネージャに向けて送る。
例えば、情報は応用が所有している番号範囲を含んでいてもよい。この情報はデ
ータベース内に記憶される。

【００２３】 ゲートウェイの故障と回復 １．図７に示すように、ＦＷはゲートウェイの故障を検出して、適当な警報を生
じさせる。 ２．ＦＷはゲートウェイの回復を検出して、サインされた各サービス合意につい
て新しいParlayサービスゲートウェイマネージャのインスタンシエーション（事
例をあげての開示）を求める。これはサービス開示からの振舞いを再使用する。

【００２４】 クライアント応用の故障 １．図８に示すように、クライアント応用故障についての通知があると、ＦＷは
これを各ゲートウェイに報告する。 ２．各ゲートウェイは、有効なクライアント応用についてのゲートウェイのリス
トから古く、失効した、レファレンスを除去する。

【００２５】 ＦＷ−クライアントＦＷインターフェース 開始（図６） １．クライアントＦＷは認証ハンドシェーク（握手）をＦＷと実行する。 ２．クライアントＦＷはディスカバリィインターフェースを用いて、エンドユー
ザサービスを実行するのに必要な、Parlayサービスを見付ける。 ３．クライアントＦＷはParlayサービスを選び、回復目的で必要とされているゲ
ートウェイの数（ｎ）を特定する。またParlayサービスゲートウェイに対して、
義務履行のためバインド（結合）されることになるクライアント応用の最大数（
ｍ）を特定する。これはサービスレベル合意の一部として特定される。 ４．クライアントＦＷがサービス合意にサインをするときには、ＦＷはサービス
ゲートウェイマネージャのリストに対するレファレンスをクライアントＦＷに向
けて戻す。 ５．クライアントＦＷはＦＷを介してグローバル事象通知情報を送る。例えば、
これは応用“自体の”番号範囲であり、この情報はデータベース内に記憶される
。

【００２６】 ゲートウェイの故障と回復（図７） １．ゲートウェイの故障を検出すると、ＦＷはこれをクライアントＦＷに報告す
る。 ２．ゲートウェイの回復を検出し、新しいサービスゲートウェイマネージャのイ
ンスタンシエーションを要求すると、ＦＷはクライアントＦＷに対して報告を送
り、サービスゲートウェイマネージャのレファレンスをパラメータとして送る。

【００２７】 クライアント応用の故障と回復（図８） １．クライアント応用故障を検出すると、クライアントＦＷはこれをＦＷに報告
する。

【００２８】 クライアント応用−サービスインターフェース バインド（義務履行のための結合）（図６と７） 開始後、あるいはクライアント応用の回復後に、サービスゲートウェイマネージ
ャレファレントをクライアント応用に向けて送ること １．クライアント応用はサービスゲートウェイマネージャの各々に対して順々に
バインドする。各サービスゲートウェイマネージャはｍのクライアント応用を越
えてそこへのバインドを許さない。 ２．サービスゲートウェイマネージャは適当な配信アルゴリズムを用いて事象を
クライアント応用に分散させる。

【００２９】 あるゲートウェイの故障と回復（図７） １．ゲートウェイの故障は次によりクライアント応用に向けて通知される。 ａ）クライアントＦＷが故障を報告するか、 ｂ）クライアント応用が故障を直接検出するか（実施の際か、プロトコル固有の
故障のとき）、既存の応用セッションを時間切れ（タイムアウト）とするか（例
えば応用呼出しセッションのとき）による。 ２．ＡＰＩインボケーション（実施のための呼出し）であって既存のサービスセ
ッションに関するものは他のゲートウェイには転送されない。 ３．新しいサービスセッションについてのＡＰＩインボケーションが代りのゲー
トウェイに向けて転送される。これは適当な配信アルゴリズムを用いて行なわれ
て、残っているゲートウェイの間でインボケーションが分散される。 ４．ゲートウェイ回復では、クライアントＦＷは新しいサービスマネージャに対
するレファレンスをクライアント応用に送り、この応用が新しいサービスマネー
ジャにバインドする。

【００３０】 クライアント応用の故障と回復（図８を見よ） １．クライアント応用の故障は次によりゲートウェイに通知される。 ａ）ＦＷが故障を報告する ｂ）ゲートウェイが故障を検出する（実施の場合か、プロトコル固有の故障のと
き）か、既存のサービスセッション（例えば、呼出しセッション）をタイムアウ
トとする。 ２．既存の応用セッションについてのＡＰＩインボケーションは他のクライアン
ト応用に向けて転送されない。 ３．新しい応用セッションについてのインボケーション（初期事象通知）が代り
のクライアント応用に向けて転送される。これは適当な配信アルゴリズムを用い
て行なわれて、残っているクライアント応用間でインボケーションが分散される
。 ４．回復されたクライアント応用は、サービスゲートウェイマネージャの各々と
バインドする。

【００３１】 クライアントＦＷ−クライアント応用インターフェース 開始（図６） １．クライアントＦＷはサービスゲートウェイマネージャレファレンスのリスト
をクライアント応用のすべてに向けて送る。

【００３２】 ゲートウェイの故障と回復（図７） １．ゲートウェイの故障についてＦＷから報告を受取ると、クライアントＦＷは
この情報をクライアント応用に向けて送る。 ２．各クライアント応用は有効なゲートウェイのリストから古い、失効した基準
（レファレンス）を除去する。 ３．ゲートウェイの回復があると、クライアントＦＷは新しいサービスゲートウ
ェイマネージャのレファレンスをクライアント応用のすべてに向けて送ってバイ
ンドさせる。

【００３３】 クライアント応用の故障と回復（図８） １．クライアントＦＷは故障を検出し、適当な警報を生じさせて、故障をＦＷに
向けて報告する。 ２．クライアントＦＷはクライアント応用の回復を検出する。 ３．クライアントＦＷはサービスゲートウェイマネージャレファレンスのリスト
を回復したクライアント応用に向けて送って、バインドさせる。

【図面の簡単な説明】

【図１】 この発明を実施する網を示す図。

【図２】 図１の網で使用するためのサービスプラットホームをさらに詳細に示す図。

【図３】 図１の網におけるＡＰＩの使用を模式的に示す図。

【図４】 この発明を実施する網の異なる部品間のインターフェースを示す図。

【図５】 始動と登録とをゲートウェイについて示すメッセージシーケンスチャート。

【図６】 サービス始動についてのメッセージシーケンスチャート。

【図７】 ゲートウェイの故障と回復（復帰）を示すメッセージシーケンスチャート。

【図８】 クライアント応用の故障と回復（復帰）を示すメッセージシーケンスチャート
。

【手続補正書】特許協力条約第３４条補正の翻訳文提出書

【提出日】平成１４年２月８日（２００２．２．８）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】０００８

【補正方法】変更

【補正の内容】

【０００８】 通信網を動作する方法は、該通信網はいくつかのサービスノードと、該いくつ
かのサービスノードへのサービス応用によるアクセスを制御するようにされた登
録サーバと、いくつかの通信サービス応用を実行している登録プラットホームか
ら遠隔のプラットホームとを含んでおり、また該方法は、 ａ）該通信網に接続された該もしくは各サービスノード上で利用可能なサービス
資源を識別するデータを配信することと、 ｂ）該登録サーバに対して通信をして、段階ａ）で識別されたサービス資源の少
くともあるものに対する前記プラットホーム上で実行されている少くとも一つの
サービス応用によるアクセスを要求することと、 ｃ）該登録サーバにおいて、段階（ｂ）の要求に応答して、前記要求されたサー
ビス資源を用意しているいくつかのサービスノードへの該サービス応用によるア
クセスを許すサービス合意を実行することと、 ｄ）後に該サービス応用を少くとも一つのサービスノードに束縛する（バインド
、義務履行させる）こととを含んでいて、 前記段階ｃ）では、該サービス合意が該サービス応用の複数の事例を特定するか
、複数のサービスノードを特定するかあるいはその両方を行ない、かつ前記段階
ｄ）では、 （ｉ）該サービス応用の複数の事例を該少くとも一つのサービスノードに束縛す
る（バインド、義務履行させる）ことと、 （ii）該サービス応用の少くとも一つの事例を複数のサービスノードに束縛する
（バインド、義務履行させる）ことと、 のうちの少くとも一つを含んでいることを特徴とする通信網を動作する方法であ
る。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 メイスン、ジェレミー・ロジャー イギリス国、アイピー４・４ビーピー、サ フォーク、イプスウィッチ、ブランズウィ ック・ロード 33 Ｆターム(参考） 5K024 BB04 CC00 DD00 GG01 GG03 5K051 AA05 BB00 CC00 EE01 EE02 FF01 FF07 HH02 HH11

Claims (7)

【特許請求の範囲】
1. 【請求項１】 通信網を動作する方法であって、該通信網は少くとも一つの
   サービスノードと、該少くとも一つのサービスノードへのサービス応用によるア
   クセスを制御するようにされた登録サーバと、いくつかの通信サービスを実行し
   ている登録プラットホームから遠隔のプラットホームとを含んでおり、また該方
   法は、 ａ）該通信網に接続された該もしくは各サービスノード上で利用可能なサービス
   資源を識別するデータを配信することと、 ｂ）該登録サーバに対して通信をして、段階ａ）で識別されたサービス資源の少
   くともあるものに対する前記プラットホームによるアクセスを要求することと、 ｃ）該登録サーバにおいて、段階（ｂ）の要求に応答して、前記要求されたサー
   ビス資源を用意している少くとも一つのサービスノードへの該サービス応用によ
   るアクセスを許すサービス合意を実行することと、 ｄ）後に該サービス応用を少くとも一つのサービスノードに束縛させることとを
   含んでいて、 前記段階ｃ）では、該サービス合意が該サービス応用の複数の事例を特定するか
   、複数のサービスノードを特定するかあるいはその両方を行ない、かつ前記段階
   ｄ）では、 （ｉ）該サービス応用の複数の事例を該少くとも一つのサービスノードに束縛さ
   せることと、 （ii）該サービス応用の少くとも一つの事例を複数のサービスノードに束縛させ
   ることと、 のうちの少くとも一つを含んでいることを特徴とする通信網を動作する方法。
2. 【請求項２】 請求項１記載の方法であって、前記段階ｄ）はサービス応用
   の複数の事例を該少くとも一つのサービスノードに束縛させることを含み、該方
   法は成功した初期事象通知を該サービス応用の複数の事例間で配信することを含
   む方法。
3. 【請求項３】 請求項１または２記載の方法であって、複数のサービスノー
   ドをサービス応用の該少くとも一つの事例で登録することを含み、該方法は成功
   した初期セッション要求を該複数のサービスノード間で配信することを含む方法
   。
4. 【請求項４】 請求項１ないし３のいずれか１項記載の方法であって、さら
   に、該登録サーバによって実行される、該登録サーバに登録された複数のサービ
   スノードを繰返しポーリングする段階と、該サービスノードの利用可能性につい
   ての何らかの変化を示しているデータを該もしくは各応用事例に向けて通信する
   段階とを含む方法。
5. 【請求項５】 請求項１ないし４のいずれか１項記載の方法であって、さら
   に、該登録サーバで登録された複数のサービス応用事例の各々を繰返しポーリン
   グすることと、該もしくは各サービスノードに向けて、該サービス応用事例の利
   用可能性についての何らかの変化を示しているデータを通信することとを含む方
   法。
6. 【請求項６】 請求項１ないし５のいずれか１項記載の方法により動作する
   ようにされている通信網。
7. 【請求項７】 請求項６記載の網で使用するために適応している登録サーバ
   。