(57)【要約】通信セッションを制御するＳＩＰのようなセッションプロトコルのメッセージによって起動される複数のサービスを管理する方法及びシステムが開示され、この方法は、サービスを呼び出すための状態（４０３、４０４、４０５）をそれぞれが特定するいくつかの実行ルールを取得する工程と、前記メッセージが第１状態を満足する場合、呼出対象の第１サービスを生成して、第１変更メッセージ（１６１５）を出力する第１実行ルールと、第１変更メッセージが第２状態を満足する場合、第１変更メッセージを入力として、呼出対象の第２サービスを生成する第２実行ルール（１６０７）とを所定の順序で処理する工程とを備える。
2004532472.tif 000002
【特許請求の範囲】
【請求項１】
通信セッションを制御するセッションプロトコルのメッセージ（１３０６、１６０９）によって起動される複数のサービス（３０９、３１０、３１１、１３０５、１６１１、１６１２、１６１３）を管理する方法であって、
サービスを呼び出すための状態（４０３、４０４、４０５）をそれぞれが特定するいくつかの実行ルール（３０８、４０１、４０２、１６０６、１６０７、１６０８）を取得する工程と、
前記メッセージが第１状態を満足する場合、呼出対象の第１サービス（１６１１）を生成して、第１変更メッセージ（１６１５）を出力する第１実行ルール（１６０６）と、前記第１変更メッセージが第２状態を満足する場合、第１変更メッセージを入力として、呼出対象の第２サービス（１６１２）を生成する第２実行ルール（１６０７）とを所定の順序で処理する工程と
を備えること特徴とする方法。
【請求項２】
前記いくつかの実行ルールは、いくつかのルールモジュール（３０８、４００、１２１６、１２１７、１２１８、１２１９、１３０１、１６０２）にグループ化され、各ルールモジュールは、いくつかの実行ルールを含み、前記方法は、更に、
第１累積変更メッセージ（１２０６）を出力する前記いくつかのルールモジュールの内の第１ルールモジュール（１２１６）を処理する工程と、
前記第１累積変メッセージを入力として提供する前記いくつかのルールモジュールの内の第２ルールモジュール（１２１７）の呼出処理を行う工程と
を備えることを特徴とする請求項１に記載の方法。
【請求項３】
各ルールモジュールは、前記いくつかのルールモジュールの処理順序を示す優先度と関連付けられている
ことを特徴とする請求項２に記載の方法。
【請求項４】
各ルールモジュールは、前記ルールモジュールを編集することが認証されたルールモジュール所有者（４０９）に対応する
ことを特徴とする請求項２または３に記載の方法。
【請求項５】
前記第１ルールモジュールは、前記累積変更メッセージの所定部分に関連するロックフラグを変更する権限を示し、かつ前記累積変更メッセージの前記所定部分が少なくとも前記第２ルールモジュールから呼び出されるサービスによって変更されるかを特定する特権を割り当てる
ことを特徴とする請求項２乃至４のいずれか１項に記載の方法。
【請求項６】
前記第２ルールモジュールの呼出処理を行う工程は、更に、前記ロックフラグが第１ルールモジュールによって設定解除（unset）がマークされない限り、前記第２ルールモジュールから呼び出されるサービスによる前記累積変更メッセージの前記所定部分の変更を防止するために該ロックフラグを設定する工程を備える
ことを特徴とする請求項５に記載の方法。
【請求項７】
前記いくつかの実行ルールを取得する工程は、更に、前記メッセージのヘッダ情報に基づいて所定の契約関係を検出し、前記検出された契約関係に基づいていくつかのルールモジュールを選択する工程を備える
ことを特徴とする請求項２乃至６のいずれか１項に記載の方法。
【請求項８】
前記第１ルールモジュール（１２１６）を処理する工程は、更に、所定の第３ルールモジュール（１２２０）を呼び出す工程を備える
ことを特徴とする請求項２乃至７のいずれか１項に記載の方法。
【請求項９】
前記第１及び第２ルールモジュールはそれぞれ、該第１あるいは第２ルールモジュールに対応するアクセス権を特定する第１及び第２アクセス制御リスト（４１１）に関連付けられている
ことを特徴とする請求項２乃至８のいずれか１項に記載の方法。
【請求項１０】
前記第１及び第２ルールモジュールはそれぞれ、所定マークアップ言語の第１及び第２スクリプトからなる
ことを特徴とする請求項２乃至９のいずれか１項に記載の方法。
【請求項１１】
前記メッセージは、第１及び第２の属性セットを有し、前記実行ルールは、対応する制約に従って、少なくとも第１及び第２処理クラス（５０９、５１０、９０３、９０４）の実行ルールにグループ化され、前記第２処理クラスは、前記第２の属性セットの属性を変更することだけに制約されており、前記実行ルールを処理する工程は、更に、前記第２処理クラスの任意の実行ルールを処理する前に、前記第１処理クラスの実行ルールを処理する工程を備える
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記メッセージは、第１及び第２の属性セットを有し、前記実行ルールは、対応する制約に従って、少なくとも第１及び第２処理クラス（９０３、９０４）の実行ルールにグループ化され、前記第２処理クラスは、前記第２の属性セットの属性を変更することだけに制約されており、前記方法は、前記第１ルールモジュール（９０１）を処理する工程と前記第２ルールモジュール（９０２）の呼出処理を行う工程を繰り返す工程を更に備え、ここで、各繰り返し処理において、前記第１及び第２ルールモジュールの処理は、対応する処理クラスのルールを実行することに制限され、ここで、各繰り返し処理は、次の繰り返し処理に対する入力として使用される対応する累積変更メッセージを出力する
ことを特徴とする請求項２乃至１０のいずれか１項に記載の方法。
【請求項１３】
前記処理クラスは、前記セッションプロトコルのリクエスト（６０７）及び応答（６０８）によって起動される実行ルールに対して別々に定義される
ことを特徴とする請求項１１または１２に記載の方法。
【請求項１４】
前記第１の属性セットは、前記メッセージのシグナリングプロパティを有する
ことを特徴とする請求項１１乃至１３のいずれか１項に記載の方法。
【請求項１５】
前記処理クラスは、前記セッションプロトコルに従う再帰メッセージフローの所定位置に対応する
ことを特徴とする請求項１１乃至１４のいずれか１項に記載の方法。
【請求項１６】
前記処理クラスは、前記メッセージのシグナリングプロパティ（７０２）を与える第１処理クラス（Ｐ１）の実行ルール、前記メッセージの非シグナリングメッセージ本体コンテンツ（７０４）を与える第２処理クラス（Ｐ２）の実行ルールと、前記メッセージの前記シグナリングプロパティも前記非シグナリングメッセージ本体コンテンツも与えない第３処理クラス（Ｐ３）の実行ルールを含んでいる
ことを特徴とする請求項１１乃至１５のいずれか１項に記載の方法。
【請求項１７】
前記第１及び第２処理クラスのすべての実行ルールが処理される場合に、変更メッセージ（７０３）が生成される
ことを特徴とする請求項１６に記載の方法。
【請求項１８】
呼び出す前記第１サービスは、更に、第２変更メッセージを出力し、前記方法は、更に、前記第１変更メッセージを入力として次の実行ルールを処理する工程と、前記第２変更メッセージを入力として次の実行ルールを処理する工程とを備える
ことを特徴とする請求項１乃至１７のいずれか１項に記載の方法。
【請求項１９】
前記方法は、更に、
どのサービスが実行されているかについての情報と、どの順序でサービスが実行されているかについての情報を記憶する工程と、
所定のイベントが発生している場合、前記第１サービスへ通知を返信するリクエストを前記第１サービスから受信する工程と、
前記記憶されている情報に関連する前記リクエストを記憶する工程と、
前記イベントの発生において、前記記憶されている情報に従って前記第１サービスへ通知する工程と
ことを特徴とする請求項１乃至１８のいずれか１項に記載の方法。
【請求項２０】
前記実行モジュールは、コンピュータ可読スクリプトを有し、前記実行ルールの所定の処理順序は、前記スクリプト上の実行ルールの順序によって判定される
ことを特徴とする請求項２乃至１９のいずれか１項に記載の方法。
【請求項２１】
前記実行ルールを処理する工程は、更に、少なくとも前記第２サービスによる変更に対してロックされている前記第１変更メッセージの少なくとも一部にマーキングする工程を備える
ことを特徴とする請求項１乃至２０のいずれか１項に記載の方法。
【請求項２２】
前記セッションは、発信側及び着信側を含むいくつかの加入者に関連し、サービスは、加入者からのリクエストによって起動されるように構成され、前記方法は、更に、前記着信側によって要求される任意のサービスを呼び出す前に、前記発信側によって要求されるサービスを呼び出す工程を備える
ことを特徴とする請求項１乃至２１のいずれか１項に記載の方法。
【請求項２３】
前記セッションプロトコルは、セッション初期化プロトコルである
ことを特徴とする請求項１乃至２２のいずれか１項に記載の方法。
【請求項２４】
前記通信セッションは、マルチメディアセッションである
ことを特徴とする請求項１乃至２３のいずれか１項に記載の方法。
【請求項２５】
前記実行ルールは、動的に更新されるように構成されている
ことを特徴とする請求項１乃至２４のいずれか１項に記載の方法。
【請求項２６】
通信セッションを制御するセッションプロトコルのメッセージによって起動される複数のサービス（３０９、３１０、３１１）を呼び出すように構成されているサービス実行環境モジュール（２０１、３０１）を有するデータ処理システムであって、
前記データ処理システムは、更に、サービスを呼び出す状態をそれぞれが特定する複数の実行ルールを記憶するように構成されている記憶媒体（３０７）を有し、
前記サービス実行環境モジュールは、
−いくつかの実行ルール（３０８）を検索し、
−前記メッセージが第１状態を満足する場合、呼出対象の第１サービスを生成して、第１変更メッセージを出力する第１実行ルールと、前記第１変更メッセージが第２状態を満足する場合、第１変更メッセージを入力として、呼出対象の第２サービスを生成する第２実行ルールとを所定の順序で処理する
ように構成されているルールエンジンモジュール（３０３）を有する
ことを特徴とするデータ処理システム。
【請求項２７】
データ処理システムにおいて、通信セッションを制御するセッションプロトコルのメッセージによって起動される複数のサービスを呼び出すように構成されているサービス実行環境モジュール（２０１、３０１）であって、
前記サービス実行環境モジュールは、
−サービスを呼び出す状態をそれぞれが特定するいくつかの実行ルール（３０８）を検索し、
−前記メッセージが第１状態を満足する場合、呼出対象の第１サービスを生成して、第１変更メッセージを出力する第１実行ルールと、前記第１変更メッセージが第２状態を満足する場合、第１変更メッセージを入力として、呼出対象の第２サービスを生成する第２実行ルールとを所定の順序で処理する
ように構成されているルールエンジンモジュール（３０３）を有する
ことを特徴とするサービス実行環境モジュール。
【請求項２８】
前記ルールエンジンモジュールは、所定のルール実行特定言語を解釈するように構成されている
ことを特徴とする請求項２７に記載のサービス実行環境モジュール。
【請求項２９】
前記ルールエンジンモジュールは、更に、前記実行ルールを検索するように構成されているルールベースプロセッサモジュール（１６０１）と、前記実行ルールを処理するように構成されているルールモジュール処理モジュール（３１４、１６０４、１６０５）を有する
ことを特徴とする請求項２７または２８に記載のサービス実行環境モジュール。
【請求項３０】
データ処理システム上で実行される場合、請求項１乃至２５のいずれか１項に記載の方法の各工程を実行するように構成されているコード手段を有するソフトウェアプログラム。
【請求項３１】
前記ソフトウェアプログラムは、コンピュータ可読媒体に埋め込まれている
ことを特徴とする請求項３０に記載のソフトウェアプログラム
【請求項３２】
請求項２乃至２５のいずれか１項に記載の方法を使用するルールモジュールを有するデータレコード。
【請求項３３】
サービスネットワーク内のサービスの配置を管理する方法であって、
コンピュータ可読スクリプト内において、動作中の前記サービスに認められているいくつかの特権及び権利を特定する工程と、
フィーチャ相互作用の発生の可能性を解析する工程と、
コンピュータ可読ルールモジュールスクリプトとして記憶されている実行ルールのセットとして前記サービスに対する配置ストラテジーを特定する工程と
を備えることを特徴とする方法。
【請求項３４】
前記方法は、更に、ルールモジュール優先度を前記ルールモジュールスクリプトに割り当てる工程を備える
ことを特徴とする請求項３３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信セッションに関する複数のサービスの管理に関するものであり、この通信セッションは、その通信セッションに関するセッション情報を提供するセッションプロトコルによって制御される。
【背景技術】
【０００２】
ＩＰテレフォニー（telephony）、マルチメディアセッション、ビデオストリーミング等のインターネットを介するインタラクティブ通信セッションの要求が増大している。インタラクティブ通信セッションは、セッションプロトコルによって制御され、これには、ユーザ間のセッションの初期化、終了及び変更を処理するセッション初期化プロトコル（ＳＩＰ）がある。ＳＩＰは、初期形対象のセッションのタイプには関知しない、つまり、ＳＩＰメッセージの実体には関知しないで、むしろ、セッションの管理に関知するものである。これは、例えば、接続対象のユーザが実際に存在する場所の判定、来訪するユーザのセッションの記述の配信、セッションを記述するための共通フォーマットのネゴシエーション等がある。
【０００３】
ＳＩＰは、要求（リクエスト）−応答パラダイムに基づいている。例えば、セッションを初期化する場合、発信側は、その発信側が発呼したいユーザ、即ち、着信側（callee）に向けてリクエストを送信する。リクエストメッセージは、典型的には、メッセージを転送し配信するために応答可能ないくつかのプロキシサーバを介して、着信側に送信される。次に、着信側は、着信（invitation）を受け入れるかあるいは拒否するかの応答を送信する。この応答は、プロキシサーバの並びの順路を逆順で辿って返信される。
【０００４】
ＳＩＰのようなセッションプロトコルによって提供される標準的なセッション管理に加えて、追加のサービスを発信側、着信側、あるいはそれらの中間にある任意のプロキシサーバで実現することができる。
【０００５】
ここで、サービスという用語は、機能の単位を意味し、この機能は、基本システムに増分的に追加することでき、加入者、管理者あるいはその類のユーザによって知覚可能な出力形態である。尚、サービス、例えば、着信転送、ボイスメール、ビデオ会議等は、セッション管理用のシステム、例えば、ＳＩＰシステムのような基本システムへの拡張モジュールである。基本システムでの機能の追加及び有効化の処理は、フィーチャ配置と呼ばれている。
【０００６】
セッション中には、フィーチャは、あるイベントによって起動することができる。起動、即ち、あるイベントで与えられているアプリケーションを呼び出す動作は、通常、加入者とサービスプロバイダ間の契約関係に基づいている。１つ以上のフィーチャがサービスネットワークに配置され、かつ１つ以上のサービスが１人以上のユーザに対して同時に起動できる場合、フィーチャ相互作用（feature interaction）が生じる。ここで、フィーチャ相互作用という用語は、あるフィーチャが別のフィーチャに影響を与えるあるいは別のフィーチャに変化することを意味する。フィーチャ相互作用は、モジュールフィーチャの必然的な副産物である。これには、好ましいフィーチャ相互作用と好ましくないフィーチャ相互作用が存在する。しかしながら、フィーチャ相互作用が適切に管理されない場合にはサービスネットワークの全体の行動（behaviour）が制御不能となる問題がある。その結果、サービスネットワークの能力に相当な要求を求めるＵＭＴＳのような新技術の出現とともに、サービスアプリケーションの数と複雑さが増えるにつれて、フィーチャ相互作用の問題も大きくなっている。これらのサービスは、別々に開発され、かつサービスプロバイダは、使用される通信プロトコルのデフォルト行動のアクションを解決し、かつ成立すべき、これらのサービスからの命令がどのように衝突しているかを特定できる必要がある。
【０００７】
サービスネットワークに新規のサービスを追加する場合、例えば、フィーチャの組をテストすることによって、フィーチャ相互作用を防止するために、複数の機能の行動が、アドホックあるいはシステマチックにテストすることができる。フィーチャ相互作用のインスタンスがテスト中あるいは配置後に検出される場合、検出される問題は、例えば、１つ以上の組込サービスアプリケーションを再設計することによって抑えることができる。
【０００８】
上述の方法は、特に、サービスの数と複雑さが増えるにつれて、大量のリソースを必要とする。ここで、上述の従来技術は、サービスアプリケーションの数と複雑さを十分に量れないという問題がある。
【０００９】
本発明に従えば、通信セッションを制御するセッションプロトコルのメッセージによって起動される複数のサービスを管理する方法によって、上記及びその他の問題が解決され、  この方法は、
サービスを呼び出すための状態をそれぞれが特定するいくつかの実行ルールを取得する工程と、
前記メッセージが第１状態を満足する場合、呼出対象の第１サービスを生成して、第１変更メッセージを出力する第１実行ルールと、第１変更メッセージが第２状態を満足する場合、第１変更メッセージを入力として、呼出対象の第２サービスを生成する第２実行ルールとを所定の順序で処理する工程と
を備える。
【００１０】
つまり、通信セッション中に起動されるサービスの呼出は、所定の順序で処理されるいくつかの実行ルールによって制御され、これによって、呼出対象のサービスの順序を制御する。それゆえ、実行順序が制御されていないことによる任意のすべての行動を回避するる、サービス実行ルールに基づくアプリケーションを起動するメカニズムが提供される。また、実行ルールを編集することによって、様々な配置ストラテジーを容易に実現することができ、これによって、柔軟で、より細かく分けられた（fine-grained）サービス配置インフラストラクチャを提供する、これは、サービスネットワークのパフォーマンスを最適化することを可能にするサービスのチェーンの順序付けにおいて大きな柔軟性を与える。
【００１１】
ここで、本発明に従えば、かなりの量の複雑なサービスを実行する場合、例えば、サービスネットワーク内のサービスの追加、削除、中断、再起動あるいは再配置を行う場合のフィーチャ相互作用を系統立て回避することを可能にする、柔軟なサービス配置インフラストラクチャが提供される。
【００１２】
個々の保管人間のサービス管理問題を分散することを可能にする、サービス実行を定義する標準化フレームワークが提供され、これによって、いくつかのサービスをスケーラブルにする方法を提供する。
【００１３】
実行ルールは、１つ以上のアクションを実行する、例えば、サービスアプリケーションを呼び出すための１つの以上の状態を含んでいる。
【００１４】
通信セッションという用語は、通信ネットワークのユーザ間の通信セッションを意味する、ここで、通信ネットワークは、例えば、ＴＣＰ／ＩＰネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、インターネットの類である。通信セッションの例には、ボイスオーバインターネット、ＩＰテレフォニー、ビデオ会議、ビデオストリーミング等が含まれる。
【００１５】
セッションプロトコルという用語は、通信セッションを制御するプロトコル、特に、セッションの初期化、終了及び変更を意味する。好ましくは、セッションプロトコルは、通信セッションの関係ユーザ間の通信ネットワークのノードを介して送信されるリクエスト／応答メッセージに基づいている。このようなセッションプロトコルの例には、セッション初期化プロトコル（ＳＩＰ）がある。他の例には、Ｈ．３２３プロトコル一式、ＭＧＣＰ及びＩＰＤＣのような関連プロトコル、ＳＧＣＰ、Ｈ．２４８等が含まれる。
【００１６】
サービスという用語は、基本システムに増分的に追加されるフィーチャの単位である。サービスは、加入者へサービスを提供するばかりでなく、ネットワーク管理者の管理業務のような他のサービスも提供することができる。このようなサービスの例には、着信転送、着信待機、ボイスメール、統計機能、コールバック、ビデオ会議、ビデオオンデマンド、匿名（anonymizer）サービス、オートリプライ等が含まれる。サービスは、例えば、ＯＳＡ、Ｊａｖａ、ＣＧＩ、Ｐｅｒｌ、Ｃ＋＋、ＸＭＬ等の様々な技術を使用して実現することができる。
【００１７】
ＳＩＰプロトコルのコンテキストにおいては、サービスは、アプリケーションである、あるいはＳＩＰサーバ上で論理的に実行されるあるいはＳＩＰサーバによって通信されるアプリケーションサーバ上で遠隔的に実行されるいくつかのアプリケーション、例えば、ＣＧＩ−スクリプトあるいはＣＰＬスクリプトである。後者の場合、サービスは、いくつかの標準ネーミング技術、即ち、ＳＩＰ  Ｒｅｑｕｅｓｔ−ＵＲＩ群を使用してアクセスし、呼び出すことができる。選択的には、サービスは、例えば、３ＧＰＰ  ＯＳＡ  ＡＰＩフレームワークを使用してＳＩＰサーバ上で自身を実際に登録することができる。ＳＩＰサービスは、発信及び着信サービスにグループ化することができる、即ち、これらは、発信側及び着信側に関連している。
【００１８】
サービスは、メッセージヘッダ、メッセージ本体、ＳＰＰあるいはその類の状態において、起動することができる。
【００１９】
サービスアプリケーションに提供されるＳＩＰサーバの機能は、例えば、いくつかのＡＰＩ、例えば、サーバ側ＯＳＡ  ＡＰＩ、統計的機能あるいはその類へのアクセスのようなサービスフィーチャと呼ばれる。サービスフィーチャは、更に、ＳＩＰサーバで、他のサービスアプリケーションによって使用されるサービスを登録し、提供するサービスアプリケーションとなり得る。
【００２０】
本発明の更なる効果は、サービスの実現、シグナリングプロトコル及びプラットホームに対して独立して使用される技術であることである。ここで、ネットワークオペレータは、どのタイプのサービスがサービスネットワーク内で配置されるかを前もって知る必要はなく、これによって、サービス配置インフラストラクチャの耐性及び拡張性を提供する。
【００２１】
自身が所有するサービスを登録することを望む保管人の数がかなり大きくなるにつれて、スケラービリティが必要となる。また、ドメインに関連する加入者の数がかなり多くなっているので、スケラービリティの問題が重要になっている。サービスは、様々なタイプのイベントによって起動され得り、かつ複数の様々な状態、例えば、ソースと宛先アドレスのマッチング、時間依存性あるいはいくつかの他の前提状態に基づいて読み出され得る。また、サービスに関連する非ＳＩＰが、例えば、与えられているポイントである状態が満足している場合に、呼び出され得る。様々なサービス技術、例えば、ＣＰＬを使用することができる。サービスに関連するＳＩＰは、非ＳＩＰイベント、例えば、ＨＴＴＰイベントで呼び出され得る。１０万人の加入者に提供され得るサービスには、サードパーティサービスプロバイダの１万のサービスから１万のサービスが発生し得る。つまり、サービス及びサービス相互作用を管理するタスクは、管理を行う管理者に対して複雑でかつ大きすぎるタスクになり易い。
【００２２】
本発明の実施形態に従えば、上記のいくつかの実行ルールは、いくつかのルールモジュールにグループ化され、各ルールモジュールはいくつかの実行するを含み、更に、上記方法は、更に、以下の工程を有する。
【００２３】
−第１累積変更メッセージを出力する前記いくつかのルールモジュールの内の第１ルールモジュールを処理する工程と、
前記第１累積変メッセージを入力として提供する前記いくつかのルールモジュールの内の第２ルールモジュールを呼出処理を行う工程とを備える。
【００２４】
つまり、実行ルールをルールモジュールにグループ化することによって、即ち、実行ルールのグループによって、フィーチャ相互作用の問題は、ルールモジュール間の同一ルールモジュールと相互作用内で呼び出されるフィーチャ間のフィーチャ相互作用の問題に分割される。その結果、本発明の効果は、サービスの数を量り、フィーチャ相互作用を管理する方法が提供されることである。特に、様々なサービスが様々なサービスプロバイダ、例えば、様々な企業あるい会社内の様々な組織体によって提供される場合、単一のプロバイダは、提供されるすべてのサービスをテストするためにアクセスする必要はない、あるいはテストすることができない。ここで、本発明の効果は、フィーチャ相互作用解析の解析タスクが、ルールモジュールに従って分割することができ、かつ様々なプロバイダに分散することができることである。これは、更に、サービス管理コストを、加入者及びサービスの数が増えるにつれて、独立のパーティに委託できることを含んでいる。
【００２５】
ＳＩＰサーバ上のサービスをアップロード／登録、かつ管理することを要求することができる保管人は、所有者、ＳＩＰサーバのプロバイダあるいは管理者、ネットワークオペレータ等となり得る。これは、様々なタイプのリテーラー（retailers）、例えば、仮想テレコムオペレータ、インターネットサービスプロバイダ等にもなり得る。更に、これは、例えば、アプリケーションサービスプロバイダ、コンテンツサービスプロバイダ、サービス／フィーチャプロバイダのような様々なタイプのサービスプロバイダにもなり得る。また、民間組織、民間企業及び加入者は、保管人になり得る。
【００２６】
その結果、本発明に従えば、柔軟で、拡張可能で、かつスケーラブルな、保管人間の契約関係の管理が達成され、これには、課金、調停、ポリシー及びセキュリティの管理が含まれる。
【００２７】
本発明の更なる効果は、実行ルールのモジュール構造を提供することであり、これによって、ユーザ、ユーザグループ、加入者等に対するサービスプロファイルの埋込を可能にする。更に、モジュール化の効果は、ルールモジュールの再使用を可能にして、これによって、サービス環境のメンテナンスを更に容易にする。
【００２８】
ルールモジュールの数の処理の順序を示す優先度が各ルールモジュールに関連付けられている場合、ルールモジュールの実行順序は、単純なパラメータによって判定され、これによって、ルールモジュールの実行順序に対して容易でかつトランスペアレントな制御を提供する。
【００２９】
各ルールモジュールが、そのルールモジュールを編集することを認証されているルールモジュール所有者に対応する場合、ルールモジュールに対する管理権限が容易に確立され、これによって、ルールモジュールの編集、ルールモジュール内のフィーチャ相互作用解析等のような管理権限の委任を更に容易にする。
【００３０】
本発明の実施形態に従えば、第１ルールモジュールは、累積変更メッセージの所定部分に関連するロックフラグを変更する権限を示し、かつ累積変更メッセージの所定部分が少なくとも第２ルールモジュールから呼び出されるサービスによって変更されるかを特定する特権を割り当てる。その結果、次のサービスによるメッセージの個々の属性あるいは属性のグループの変更を明示的に可能にするあるいは防止するためのメカニズムが提供される。ここで、別のサービスによって、あるサービスのコンテキストの変更によるフィーチャ相互作用を防止するための有効なツールが提供される。このタイプのフィーチャ相互作用は、サービスの行動の多義性あるいは衝突を生じる可能性があるフィーチャ仮定の違反として参照される。ある属性のロック及びアンロックの少なくとも一方を行う権限が、ルールモジュールに割り当てられている所定の特権に関係しているので、ネットワークオペレータは特権の誤用を検出することができ、これによって、未認証行動を防止し、かつ本方法のセキュリティを向上する。特権違反は、例えば、サービスの通知及び無効化の少なくとも一方によって、動作中に検出して、解決することができる。
【００３１】
本発明の更なる実施形態に従えば、第２ルールモジュールの呼出処理を行う工程は、更に、ロックフラグが第１ルールモジュールによって設定解除（unset）がマークされない限り、第２ルールモジュールから呼び出されるサービスによる累積変更メッセージの所定部分の変更を防止するためにロックフラグを設定する工程を備える。その結果、デフォルトでは、メッセージ属性は、制御があるルールモジュールから別のルールモジュールへ移る場合に、次の変更に対してロックされている。ここで、第２ルールモジュールは、第１ルールモジュールがアンロックされていることを明示的にマークされていることを示すメッセージ属性のみを変更することができ、これによって、更に、ルールモジュール間の取り得るフィーチャ相互作用の制御を改善し、かつ特徴解析タスクを個々のルールモジュール内に制限する。この結果、更なるスケーラビリティを改善する。
【００３２】
いくつかの実行ルールを取得する工程が、更に、メッセージのヘッダ情報に基づいて所定の契約関係を検出し、検出された契約関係に基づいていくつかのルールモジュールを選択する工程を備える場合、オペレータに対するサポートをサードパーティサービス及びユーザ定義サービスの少なくとも一方に管理させることを可能にするモジュール及びスケーラブル方法が提供される。契約関係がヘッダ情報に基づいて検出されると、与えられているメッセージに対して関連しているこれらのサードパーティあるいはユーザ定義サービスは、検出された契約関係に基づいて識別することができる。
【００３３】
本発明の別の実施形態に従えば、第１ルールモジュールを処理する工程は、更に、所定の第２ルールモジュールの呼出を行う工程を備える。その結果、ルールモジュールは、他のルールモジュールを呼び出すことができ、これによって、階層ルールモジュールを生成し、かつ更に、配置インフラストラクチャのスケーラビリティ及び柔軟性を改善するための強力なツールを提供する。本発明の効果は、ある所有者によって所有されるあるルールモジュールを別のパーティによって所有される別のルールモジュールへの委任を可能にすることである。あるパーティは、そのパーティによって適切とされる順序でアプリケーションを呼び出すことができ、かつ様々なアプリケーションを呼び出すことができる別のパーティへ制御を渡すことができる。第１パーティは、第２パーティからの出力をチェックするために続けて制御を回復することができる。
【００３４】
この委任が実行される場合、第１パーティは、アクションに対して上書きされないかを示すことによって、次のアプリケーションに送信されたメッセージ内のどのメッセージプロパティを変更できるかを決定することができる。
【００３５】
本発明の効果は、他のルールモジュール内からルールモジュールを起動して、メッセージプロパティをロックする機能に基づく管理権限の階層的委任を可能にすることである。
【００３６】
第１及び第２ルールモジュールがそれぞれ、第１あるいは第２ルールモジュールに対応するアクセス権を特定する第１及び第２アクセス制御リストに関連している場合、アクセス件の違反が検出されて解決される、これによって、本方法のセキュリティが更に向上する。
【００３７】
第１及び第２ルールモジュールがそれぞれ、所定マークアップ言語の第１及び第２スクリプトからなる場合、ルールモジュールを記述するための単純な言語が提供される。ここで、管理者にとっては、ルールをどのように表現し、かつそのルールの意味が何であるかを理解することは容易であり、これによって、ルール言語の基本定義を所有機能に拡張する簡単なメカニズムを提供する。このような言語定義の例には、ＸＭＬがある。
【００３８】
本発明の更なる効果は、拡張可能なフレームワークを提供することである、即ち、例えば、ＳＩＰに新規な方法が追加される場合に、プロトコル、サービス技術及びメッセージプロパティを容易に追加することである。
【００３９】
本発明の更なる効果は、スケーラブルなフレームワークを提供することである、即ち、ルールを表現する同一の方法を、大規模のＩＳＰネットワーク及び小規模エンドユーザ端末、例えば、３Ｇセル電話において可能である。
【００４０】
本発明の別の実施形態に従えば、メッセージは、第１及び第２の属性セットを有し、実行ルールは、対応する制約に従って、少なくとも第１及び第２処理クラスの実行ルールにグループ化され、ここで、第２処理クラスは、第２の属性セットの属性を変更することだけに制約されており、実行ルールを処理する工程は、更に、第２処理クラスの任意の実行ルールを処理する前に、第１処理クラスの実行ルールを処理する工程を備える。その結果、サービスは、シグナリングメッセージのどの部分が更新されるかによって、所定の行動を有するグループにグループ化される。ここで、サービスは、第１のメッセージ属性のセットが、第１処理クラスの実行後に変更されないことに依存しても良い。これは、更に、フィーチャ相互作用解析のタスクを管理可能なサブタスクに分割するメカニズムを提供する。以下では、処理クラスは、処理ポイントとしても参照する。属性のセットは、メッセージヘッダ情報及び、実際のセッションコンテンツを有するメッセージ本体からなる。属性は、更に、例えば、シグナリング属性等の様々なタイプのヘッダ情報に分割されても良い。
【００４１】
本発明の更なる効果は、どのようにしてアプリケーションが相互作用することが許可されるかを特定する手段を提供することである。
【００４２】
好ましくは、処理クラスは、リクエスト及び応答に対する所定の順序で処理され、かつ発信、着信及び「着信転送（forwarded by）による」サービスに適用される。
【００４３】
本発明の更なる実施形態に従えば、メッセージは、第１及び第２の属性セットを有し、実行ルールは、対応する制約に従って、少なくとも第１及び第２処理クラスの実行ルールにグループ化され、ここで、第２処理クラスは、第２の属性セットの属性を変更することだけに制約されており、本方法は、更に、第１ルールモジュールを処理する工程と、第２ルールモジュールの呼出処理を行う工程を繰り返す工程を備え、ここで、各繰り返し処理において、第１及び第２ルールモジュールの処理は、対応する処理クラスのルールを実行することに制限され、ここで、各繰り返し処理は、次の繰り返し処理に対する入力として使用される対応する累積変更メッセージを出力する。その結果、処理クラスの概念を有するルールモジュール上の分割の組み合わせが提供され、これによって、サービスに課せられている管理所有関係及び制約に従ってサービスを分割するより細かく分けられたフレームワークを提供する。
【００４４】
処理クラスが、セッションプロトコルのリクエスト及び応答によって起動される実行ルールに対して、別々に定義されている場合、サービスの処理クラスへの分割は、更に、メッセージのタイプに従って分割され、これによって、より細かく分けられた分割を提供する。
【００４５】
本実施形態に従えば、所定位置に対応する処理クラスは、セッションプロトコルに従う再起メッセージフローの所定位置に対応し、これによって、フィーチャ相互作用の解析を簡略化する。
【００４６】
好ましくは、処理クラスは、メッセージのシグナリングプロパティを与える第１処理クラスの実行ルール、メッセージの非シグナリングメッセージ本体コンテンツを与える第２処理クラスの実行ルールと、メッセージのシグナリングプロパティも非シグナリングメッセージ本体コンテンツも与えない第３処理クラスの実行ルールを含んでいる。ここで、シグナリングプロパティという用語は、サービスを呼び出すためのルールモジュール状態に照合し得るＳＩＰ及びＳＤＰメッセージプロパティを意味する。
【００４７】
第１及び第２処理クラスのすべての実行ルールが処理される場合に、変更メッセージが生成される場合、本方法の効果は、第３処理クラスのサービスを待機する必要なく応答が返信されることで、向上する。
【００４８】
本発明の別の実施形態に従えば、呼び出す第１サービスは、更に、第２変更メッセージを出力し、本方法は、更に、前記第１変更メッセージを入力として次の実行ルールを処理する工程と、第２変更メッセージを入力として次の実行ルールを処理する工程とを備える。ここで、サービスが、それぞれが次のサービスのチェーンへの入力となる様々な出力を返すと、サービスのカスケード化チェーンのツリーを実現することができる。
【００４９】
本発明の更に別の実施形態に従えば、本方法は、
−どのサービスが実行されているかについての情報と、どの順序でサービスが実行されているかについての情報を記憶する工程と、
−所定のイベントが発生している場合、第１サービスへ通知を返信するリクエストを第１サービスから受信する工程と、
−記憶されている情報に関連するリクエストを記憶する工程と、
−イベントの発生において、記憶されている情報に従って第１サービスへ通知する工程とを備える。
【００５０】
ここで、サービスアプリケーションによるフィーチャイベントの通知を要求するための有効なメカニズムが提供され、これによって、アプリケーション等の監視が可能となる。
【００５１】
実行モジュールがコンピュータ可読スクリプトからなり、かつ実行ルールの所定の処理順序がスクリプト上の実行ルールの順序によって判定される場合、ルールモジュールの管理者によってフィーチャイベントに関するサービス実行の順所及び通知の順序を制御するための単純なメカニズムが提供される。
【００５２】
好ましくは、サービスのカスケード化順序は、ルールモジュール内の実行ルールの順序及びルールモジュールの順序によって判定される。
【００５３】
実行ルールが動的に更新されるように構成される場合、即ち、サービスネットワークの動作中は、リアルタイムサービス管理が提供される。
【００５４】
本発明は、更に、通信セッションを制御するセッションプロトコルのメッセージによって起動される複数のサービスを呼び出すように構成されているサービス実行環境モジュールを有するデータ処理システムに関連しており、ここで、
データ処理システムは、更に、サービスを呼び出す状態をそれぞれが特定する複数の実行ルールを記憶するように構成されている記憶媒体を有し、
サービス実行環境モジュールは、
−いくつかの実行ルールを検索し、
−メッセージが第１状態を満足する場合、呼出対象の第１サービスを生成して、第１変更メッセージを出力する第１実行ルールと、第１変更メッセージが第２状態を満足する場合、第１変更メッセージを入力として、呼出対象の第２サービスを生成する第２実行ルールとを所定の順序で処理する
ように構成されているルールエンジンモジュールを有する。
【００５５】
本発明は、更に、データ処理システムにおいて、通信セッションを制御するセッションプロトコルのメッセージによって起動される複数のサービスを呼び出すように構成されているサービス実行環境モジュールに関連しており、ここで、
サービス実行環境モジュールは、
−サービスを呼び出す状態をそれぞれが特定するいくつかの実行ルールを検索し、
−前記メッセージが第１状態を満足する場合、呼出対象の第１サービスを生成して、第１変更メッセージを出力する第１実行ルールと、第１変更メッセージが第２状態を満足する場合、第１変更メッセージを入力として、呼出対象の第２サービスを生成する第２実行ルールとを所定の順序で処理する
ように構成されているルールエンジンモジュールを有する。
【００５６】
本発明は、更に、データ処理システム上で実行される場合、上述及び後述の方法の各工程を実行するように構成されているコード手段を有するソフトウェアプログラムに関連している。
【００５７】
ソフトウェアプログラムは、コンピュータ可読媒体に埋め込むことができる。コンピュータ可読媒体という用語は、磁気テープ、光ディスク、デジタルビデオディスク（ＤＶＤ）、コンパクトディスク（ＣＤあるいはＣＤ−ＲＯＭ）、ミニディスク、ハードディスク、フロッピーディスク、強誘電体（ferro-electric）メモリ、電気的消去書換可能リードオンリメモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、ＥＰＲＯＭ、リードオンリメモリ（ＲＯＭ）、静的ランダムアクセスメモリ（ＳＲＡＭ）、動的ランダムアクセスメモリ（ＤＲＡＭ）、同期動的ランダムアクセスメモリ（ＳＤＲＡＭ）、強磁性メモリ、光記憶、電化結合素子、スマートカード、ＰＣＭＣＩＡカード等を含んでいる。
【００５８】
本発明は、更に、サービスネットワーク内のサービスの配置を管理する方法に関するものであり、この方法は、
−コンピュータ可読スクリプト内において、動作中の前記サービスに認められているいくつかの特権及び権利を特定する工程と、
−フィーチャ相互作用の発生の可能性を解析する工程と、
−コンピュータ可読ルールモジュールスクリプトとして記憶されている実行ルールのセットとして前記サービスに対する配置ストラテジーを特定する工程とを備える。
【００５９】
本発明は、更に、上述及び後述の方法で使用するためのルールモジュールからなるデータレコードに関するものである。
【発明を実施するための最良の形態】
【００６０】
図１はＳＩＰサービスネットワークにおける様々なタイプのフィーチャ相互作用を示している。ＳＩＰの導入によって、新規な範囲の会話及びリアルタイムサービスがインターネット上で出現している。これらのサービス１０１〜１０５は、エンドユーザ端末１０６〜１０８、または、着信側ユーザエージェント、あるいは１つ以上の中間ネットワークサーバ１０９によって管理することができる。中間サーバ１０９は、付加価値サービス１０２〜１０３を、発信（originting）及び着信（terminating）ユーザエージェントの少なくとも一方に提供できるばかりか、関連メディアクライアント及びサーバアプリケーション（群）にも提供できる。これらの中間サーバは、プロキシサーバ、リダイレクトサーバ、専用アプリケーションサーバあるいはユーザエージェントであり得る。
【００６１】
ユーザエージェント間で送信される通信メッセージは、インターネット１１０あるいは別の通信ネットワークを介して中間サーバ１０９によって転送される。中間ＳＩＰサーバ１０９が有する基本的な課題は、ユーザのサービスレベルの期待を満足すること、良好なネットワークパフォーマンスを維持すること、かつ新規のサービスの定義を柔軟にかつスケーラブル（scalable：変更可能）にすることである。パフォーマンスはキー発行であるので、アーキテクチャは、いくつかのサービスに対しては、ＳＩＰサーバ上で実行可能とするべきである。ＳＩＰサーバ上であるサービスを実行することができるあるいは可能でない場合もあるので、アーキテクチャは、サービスに対して、リモートサーバ上で実行できるようにもしておくべきである。
【００６２】
サービスの定義の柔軟性の要求があるので、ＳＩＰサーバの機能は、前もって定義されるべきではない。特に、サービスは、サービスプロバイダ及び加入者を含む種類のソースから継続的にアップロードされ／登録され得る。
【００６３】
ＳＩＰサーバの所有者は、ＳＩＰサーバプロバイダであると同時に、管理者及び加入者プロバイダであり得る。この保管人（stakeholder）はネットワークオペレータと呼ばれ、これは、ＴｅｌｃｏあるいはＩＳＰの類となり得る。ネットワークオペレータは、ＳＩＰサーバのドメイン名を所有することができ、かつサードパーティサービスプロバイダへサービスフィーチャを提供することができる。ネットワークオペレータは、ＳＩＰサーバ上にサービスアプリケーションとルールモジュールをインストールして、加入者へサービスを提供する。この場合、ネットワークオペレータは、サービスプロバイダかつサービス管理者として動作する。加入者は、加入を行い、ＳＩＰサーバによって提供される加入者サービスを受けるために、ネットワークオペレータと契約関係を結んでいる。加入者は、加入者自身がサービスアプリケーションとルールモジュールをＳＩＰサーバへアップロードすることを可能にするサービスを持つことができる。加入者は、専用使用、即ち、パーソナライズ化サービス用のサービスを所有する。簡単のために、ネットワークオペレータ（群）以外のパーティのすべて及び加入者はネットワークオペレータと契約関係を結んでおり、このネットワークオペレータは、サードパーティサービスプロバイダと呼ばれる。ネットワークサーバの所有者、ネットワークサーバプロバイダ、ネットワークサーバ管理者、サードパーティサービスプロバイダ及び加入者は、中間ＳＩＰサーバでは、サービスを配置する潜在的なプラットフォームとして見なされ、このサービスは、ある理由あるいは別の理由によって、終端ユーザエージェントでは配置できないあるいは配置されるべきではない。
【００６４】
標準化プロトコル（例えば、ＳＩＰ、ＳＤＰ、ＳＯＡＰ）、言語（例えば、ＣＰＬ）及びインタフェース（例えば、ＳＩＰ−ＣＧＩ、３ＧＰＰ  ＯＳＡ  ＡＰＩ）の種類があり、これらは、様々な目的のサービスの制御を処理する。また、サービスは、複数のプロトコル、ネットワークコンポーネント、言語及びインタフェースを介する自身の制御の適用を行う。ＳＩＰサーバは、必要に応じて、これらの目的のすべてをサポートするために拡張可能であるべきである。これらのサービスアプリケーションは、様々なパーティによって所有することができ、これらのパーティは、様々な認証レベルを有し、かつＳＩＰサーバの所有者との間で様々な契約関係を結んでいる。サービスアプリケーションは、様々な状態下での様々な特定発信／セッション処理点のＳＩＰリクエスト及び応答（但し、これであることに限定されない）のデフォルト処理に付加価値を与えることができる。
【００６５】
以下の例は、あるＳＩＰイベントに基づいて、複数のサービスが呼び出されることを想定していることを示している。ボブ（Bob）という名の加入者が、Ｔｅｌｃｏという名のいくつかのＳＩＰプロバイダに、ＳＩＰ加入している例を想定する。ボブは、ネットワーク内で自身が存在しようとするサービスの種類を有している。ターミナル非依存（independent）サービスのようなサービスあるいはボブの端末がどんなものであろうとそれに対応するサービスが、現在使用中にある。また、ボブにセキュリティ、プライバシー及び信頼性を与えるサービスも存在している。また、ボブは、自身のサービスを管理することを希望していない。更に、ボブは、Ｃｏｒｐ．という名の会社に従事していると仮定する。サービスは、ボブへの着信ＩＮＶＩＴＥメッセージを管理するために呼び出されるサービスは、このようになっている。
【００６６】
Ｔｅｌｃｏは、ＳＩＰサーバを所有し、かつ管理することができる。また、Ｔｅｌｃｏは、ＳＩＰサービスを加入者へ提供し、かつサードパーティサービスを務める。Ｔｅｌｃｏは、ボブが着信ＩＮＶＩＴＥの加入者であることを認識する。第１のサービスは、Ｔｅｌｃｏ発信ベアリングアプリケーションであり、ボブが最新の請求を支払っているかをチェックする。第２のサービスは、Ｔｅｌｃｏによって提供されるサービスである。これは、単に、発信側のメディアコーデックがボブの現在の位置／端末によって処理できるかをチェックする。処理できない場合、アプリケーションがメディアストリームコンバータをメディアストリームフロー（サードパーティ発信制御を使用して）に適用する。この変換は、ボブに対してトランスペアレントであり、アプリケーションは、ボブからの応答を監視し、必要に応じてセッション記述を更新する。第３のサービスは、ボブ自身の着信側プリファレンス、例えば、ＣＰＬスクリプトである。このアプリケーションは、プロキシ化リクエストに対する応答を監視し、できる限り、ＩＮＶＩＴＥを、それに基づく複数の宛先へ転送する。いわゆるＩＮＶＩＴＥは、ボブの現在のプライベートＳＩＰ  ＵＲＬとなる。「無応答」では、ＩＮＶＩＴＥは、彼の妻であるアリスに対し代用される。いくつかの場合、ボブは、すべてのプライベートな発信を、自身の企業のＳＩＰ  ＵＲＬへ転送することを希望する。第４のサービスは、Ｔｅｌｃｏのサービスであるが、これは、ｂｅｓａｆｅ．ｃｏｍという名のサードパーティアプリケーションサービスプロバイダから、Ｔｅｌｃｏへ提供される。このサービスは、メッセージ本体のコンテンツタイプをチェックし、必要な場合、例えば、アニメ化ｖＣａｒｄが含まれている場合に、ウイルスチェックを提供する。第５のサービスはＩＳＰサービスであり、これは、Ｔｅｌｃｏの課金を払い戻す着信側向けマルチメディア広告を提供する。セッションが確立されており、かつそれがビデオ会議セッションである場合、ボブは、ビデオ画像の下部に小さなストリーミングバーの情報を受信する。このサービスは、監視アプリケーションであり、かつサードパーティ発信制御を使用する。ＩＳＰは、Ｔｅｌｃｏ  ＳＩＰサーバのアカウントを有しており、かつＴｅｌｃｏによって所有される加入者に直接サービスを提供することができる。ボブは、Ｔｅｌｃｏを介さずに、ＩＳＰのサービスに直接加入している。第６のサービスは、ボブが従事する会社によって管理されるサービスである。発信がボブの現在の会社のＳＩＰ  ＵＲＬにある場合、その会社のプライベートＬＡＮネットワーク内でのみ既知のデータに基づいて、その発信がボブに転送される。最後の第７のサービスは、Ｔｅｌｃｏがいくつかのロギング（loggin：ログ記録）を実行する場合に応じた管理目的用である。
【００６７】
上述の例は、あるイベントによって起動される様々なサービスに関連する契約関係の多様性を示している。サービスは、様々な保管者によって所有されても良く、かつ様々な技術を使用して実現されても良い。
【００６８】
サービスネットワークに配置される様々なサービスは、互いに相互作用する可能性がある。これらの相互作用は、シングルユーザ、複数ユーザに関連するサービス間、あるいはカスタマーサービスとシステムサービス間で実現される可能性がある。相互作用は、更に、同一ネットワークコンポーネントあるいは異なるネットワークコンポーネント上で動作するサービス間で実現される可能性がある。図１では、異なるタイプの相互作用が示されており、ここでは、シングルユーザ−複数コンポーネント（ＳＵＭＣ）、消費者−システム（ＣＵＳＹ）、複数ユーザ−シングルコンポーネント（ＭＵＳＣ）、複数ユーザ−複数コンポーネント（ＭＵＭＣ）、及びシングルユーザ−複数コンポーネント（ＳＵＭＣ）の相互作用を示している。
【００６９】
フィーチャ相互作用には多くの原因があり、これには、「フィーチャ特権の違反」及び「フィーチャ仮定の違反」が含まれる。
【００７０】
フィーチャ特権の違反：フィーチャの特権が壊れることは、フィーチャが余剰に起動されるあるいは未認証パーティによって起動される場合である。フィーチャ特権を違反することによって生じる主要な問題は、リソースの余剰消費あるいはリソースへの未認証アクセスがある。これは、通常、意図されていないあるいは悪意の可能性がある。フィーチャ特権の違反が生じる場合、リソースへのアクセスに対して、認証済あるいは未認証のフィーチャ間での衝突が生じる。フィーチャが余剰に起動されるあるいは未認証パーティによって起動される場合、続いて、フィーチャ仮定の違反に対する原因となり得る。明白なことは、フィーチャ仮定の違反の回避が要求されていることである。
【００７１】
以下に説明するように、本発明に従えば、フィーチャ特権の違反は、コンテキスト上、契約関係上、状態上、アクセス制御リスト上、特権及び権利に対するフィルタリングによって解決される。
【００７２】
コンテキストのフィルタリングは、あるコンテキストのイベントを解釈する条件に関連する。これの必要性は、集中ネットワーク上で動作するネットワークマルチメディアサービスを管理する場合に明らかとなる。
【００７３】
契約関係のフィルタリングは、イベントをフィーチャセットにマッピングする条件に関連し、このフィーチャセットは、そのイベントを処理するために契約上課せられているものである。この問題は、特に、未統制市場で重要であり、未統制市場では、ネットワークインフラストラクチャ及びセッション制御サービスのプロバイダが加入者へ付加価値サービスを提供することができるばかりでなく、サードパーティは、同様の提供を行う正当な権利を有している。
【００７４】
アクセス制御ポリシーのフィルタリングは、イベントが認証済の行動だけがノードで生じることを補償している。
【００７５】
状態のフィルタリングは、イベントが発生して、かつ起動対象のフィーチャが、契約関係及びアクセス特権上のコンテキストに基づいて検出される場合に、フィーチャが余剰に起動されないことを補償する。これらの状態は、例えば、イベント、システムプロパティあるいはネットワークプロパティに依存しても良い。
【００７６】
フィーチャ仮定の違反：フィーチャ行動についての仮定が壊れることは、フィーチャのコンテキストが、その機能が意図するように動作できない方法で別のフィーチャに変更される場合である。フィーチャ仮定の違反は、多義性あるいは行動の衝突が生じる可能性がある。
【００７７】
フィーチャは、実行するサービスアプリケーションを視認できる行動である。サービスアプリケーションによって発行される命令は、ＳＩＰノードの付加価値行動を制御するために発行し、これが、フィーチャ相互作用と呼ばれるものである。しかしながら、多くのフィーチャは、それらの行動を、制御命令がＳＩＰノードに返信される前に、メッセージに適用する可能性がある。ＳＩＰノードに返信される制御命令あるいは命令セットは、サービス制御命令と呼ばれるものである。これは、得られるイベントコンテキスト、即ち、ＳＩＰメッセージのプロパティを含み、このＳＩＰメッセージは、サービスアプリケーションを起動したオリジナルイベントコンテキストに対する応答で、アップストリームあるいはダウンストリームで送信されなければならない。フィーチャがカレントイベントコンテキストを介する制御を行うシーケンスに、サービス制御命令が依存していない場合に、多義性行動が生じる。多義性命令は、互いに排他的には必要とされない。
【００７８】
一例として、ＳＩＰメッセージ本体がｇｉｆフォーマットのカラー画像を含んでいるとする。ｇｉｆフォーマットのメッセージ本体コンテンツで起動されるサービスアプリケーションとしてＳ１を定義する。Ｓ１は、ｇｉｆフォーマットからｊｐｇフォーマットへ変換するサービスアプリケーションであるとする。また、ｇｉｆフォーマットのメッセージ本体コンテンツで起動されるサービスアプリケーションとしてＳ２を定義する。Ｓ２は、ｇｉｆ画像を白黒画像に変換するサービスアプリケーションであるとする。
【００７９】
Ｓ１は、ｇｉｆコンテンツによって呼び出され、起動される第１アプリケーションであるとする。Ｓ１は、ｇｉｆ画像をｊｐｇ画像へ変換し、それをカレントイベントコンテキストに書き込む。Ｓ２は、呼び出されることはない。その結果、イベントコンテキストは、カラーｊｐｇ画像を含むことになる。
【００８０】
ここで、Ｓ２は、ｇｉｆコンテンツによって呼び出され、起動される第１アプリケーションであるとする。Ｓ２は、カラーｇｉｆ画像を白黒画像に変換し、それをカレントイベントコンテキストに書き込む。続いて、Ｓ１が、そのカレントイベントコンテキストによって特定されるｇｉｆコンテンツに基づいて呼び出される。Ｓ１は、ｇｉｆ画像をｊｐｇ画像に変換し、それをカレントイベントコンテキストに書き込む。その結果、イベントコンテキストは、白黒ｊｐｇ画像を含むことになる。
【００８１】
明白なことは、Ｓ１とＳ２は、多義性行動をもたらすので、１つのフィーチャのコンテキストは、別のフィーチャによって変更される。
【００８２】
衝突フィーチャ命令は、互いに排他的となる命令である。衝突命令は、互いに無視する試行を行う。この場合、衝突命令は、通常、多義性行動の原因にもなる。
【００８３】
また、すべてのフィーチャ命令は、それらが確実に認証されていない限り、潜在的な未承認命令群である。未認証フィーチャ命令は、悪意性を持ち得る、あるいはバグのある（buggy）サービスアプリケーションとなり得る。どちらの場合でも、それらは、システムの安全性及び完全性に傷害を与え得るので、検出されるべきである。
【００８４】
監視サービスアプリケーションは、既に上述している問題に更なる問題が生じ得る。監視サービスアプリケーションは、それらが継続的に動作している場合には、非同期フィーチャ命令を任意にＳＩＰノードに発行することができる。それらが将来のイベントを監視している場合、それらは、これらのイベント上で動作し、かつより多くのフィーチャ命令を提供する。複数の監視サービスアプリケーションが同時に存在する場合、それらが生成するフィーチャ命令は、それらがイベントについて通知される順序に依存し得る。これは、上述の問題を複雑にする。
【００８５】
フィーチャ仮定の違反の検出及び分析は、フィーチャ特権の違反の分析よりもかなり複雑である。以下に説明するように、本発明に従えば、多義性行動の解決方法を特定する手段が提供され、フィーチャ相互作用管理を別々のフィーチャグループと管理ドメインに分割する手段が提供され、ランタイムで検出されるフィーチャ相互作用干渉を解決するための単純なデフォルトルールが提供される。フィーチャ仮定の違反は、カスケード化チェーン原理と条件付き起動に基づくフィーチャ順序付けと、ロック／アンロックメカニズムに基づくフィーチャ優先度によって解決される。これについては、以下でより詳細に説明する。
【００８６】
フィーチャ相互作用の別の原因は、ネットワークサポートの制限、例えば、プロトコル機能制限あるいはユーザインタフェース制限、分散システムにおける固有の問題、例えば、リソースコンテンション、フィーチャ相互授与（co-ordination）、タイミング、あるいは非アトミックオペレーション、システムセキュリティの違反、不正、改竄あるいは盗聴メッセージ、衝突対象を有するフィーチャによる非協働相互作用等を含んでいる。
【００８７】
一般的には、フィーチャ相互作用に対する３種類の解決方法は、以下のように区別される：
インフラストラクチャ：フィーチャの配置用のインフラストラクチャの配置は、フィーチャ相互作用管理を統合する、即ち、定義されているいくつかのフィーチャ相互作用の原因を取り扱う。フィーチャ相互作用は、フィーチャ配置時間、即ち、ルール基準ポリシー等の仕様あるいは施行中の前（仕様）と後（施行）の両方が管理される。本発明に従えば、ルールモジュールスクリプトは、フィーチャを配置するインフラストラクチャを構成し、これは、フィーチャ相互作用管理用のフレームワークを提供する。
【００８８】
サービス生成：フィーチャ相互作用の原因に関するフィーチャの設計、即ち、設計段階中のフィーチャ相互作用の検出である。ここで、フィーチャ配置、例えば、明示的なフィーチャ相互作用原因解析、検証テスト等を介する前にフィーチャ相互作用が管理されても良い。本発明に従えば、条件としては、サービス生成及びフィーチャ配置ストラテジー仕様が課せられている。
【００８９】
ランタイム：フィーチャ相互作用が生じた場合のフィーチャ相互作用の分析である。フィーチャ相互作用がフィーチャ配置の前に全く識別できない場合でも、これらは、ランタイムで、例えば、暗号証明、認証及び機密、ルール基準ポリシー、分析アルゴリズム、ＡＩネゴシエーション等によって、検出されなければならない。本発明に従えば、ランタイムで検出されるフィーチャ相互作用がどのようにして解決されるかについての単純なルールが提供される。これらのルールは、ルールモジュールに関連するアクセス制御リストのチェック、アラーム通知及びオペレーション以外の違反ルールモジュールを取得することによるアクセス違反の分析、特権及び権利を特定するスクリプトのチェック、及びアラーム通知及びオペレーション以外の違反フィーチャを取得することによる特権及び権利の違反の解析を含んでいる。
【００９０】
本発明に従う一般的な管理プロセスは、以下のステップを含んでいる。
【００９１】
１．他のフィーチャとは独立しているフィーチャ設計仕様：サービスは、他のフィーチャとの相互作用を考慮しないで設計され、かつ特定される。しかしながら、本発明の実施形態に従えば、サービスは、以下の処理ポイントモデルに関連して設計される。
【００９２】
２．契約ネゴシエーション：サービスネットワークにサービスを配置することを希望するパーティは、サービスネットワークの管理者とネゴシエートする、ここで、特権及び権利はサービスに対して認められている。本発明の実施形態に従えば、サービスに関連する特権及び権利スクリプトが生成される。
【００９３】
３．フィーチャ相互作用解析：取り得るフィーチャ相互作用が、サービスネットワークに配置されるいくつかのフィーチャについての経験及び取り得る知識に基づいて調査される。
【００９４】
４．フィーチャ配置ストラテジー仕様：サービスを配置するルールモジュールの著作者は、管理ドメインを取得する。フィーチャ相互作用解析とサービス、加入者及びユーザについての知識に基づいて、フィーチャ配置ストラテジーが、ルールモジュールスクリプトで特定される。
【００９５】
５．フィーチャ実装
６．検証テスト
７．フィーチャ導入及び有効化
８．フィーチャランタイム行動及び管理
９．フィーチャ無効化及び削除
本発明に従えば、フィーチャ相互作用管理用フレームワークは、以下のように提供される
−単純な言語と、容易に原理が理解できるフレームワークを提供することによって仕様ルールに解析段階を容易にマッピングすることを可能にし、
−フィーチャグルーピング間の明確な境界を定義する、このフィーチャグルーピングは、与えられている解析エンティティに知られていて、かつ知られていない、
−単純、つまり、容易に理解することができる、フィーチャのグループ間の制御のハンドオーバ用のルールを提供する。フィーチャのあるグループから別のグループへハンドオーバされる場合、フィーチャの次のグループが直前のグループに干渉しないことを補償するメカニズムが存在し、
−直前の状態が保証されていて、かつアプリケーションがある命令をサーバに与えることだけを許容している状態でのイベントの処理の処理ポイントを特定することによって解析段階を簡略化する。
【００９６】
図２は、本発明の実施形態に従うサービス環境ＳＩＰサーバアーキテクチャに含まれるネットワーク要素を示している。前段ＳＩＰクライアント２０３は、任意のクライアント、例えば、ＳＩＰアクション可能ＰＣ、無線端末、前段ホッププロキシ、ＳＩＰ／ＰＳＴＮゲートウェイ等を表している。クライアントは、ＳＩＰサーバ２０２に対する着信リクエストでセッションサービス用のリクエストを生成する。ＳＩＰサーバ２０２は、プロキシ、リダイレクトあるいは専用ＳＩＰ動作可能アプリケーションサーバを表しており、ここでは、サービスサポート環境２０１が実現される。選択的には、付加価値サービス、例えば、ユーザエージェント、レジスタあるいはその類を起動する任意の他のＳＩＰ動作可能エンティティであっても良い。ＳＩＰサーバサービスサポート環境２０１に配置されるサービスは、サービスアプリケーションによって定義され、これには、例えば、ＳＩＰ−ＣＧＩスクリプト、ルールモジュール及びサービスフィーチャがある。ＳＩＰノード２０２は、イベントの受信でサービスサポート環境２０１に対するハンドオーバ制御を行うことができる。サービスサポート環境２０１は、続けて、あるフィルタ基準に従って、かつそのイベントに基づいて関連サービスアプリケーションを呼び出すことができる。サービスアプリケーションは、フィーチャ命令あるいは命令群を返信する。サービスサポート環境２０１は、イベントをどのように処理するかについてをＳＩＰノード２０２に通知するサービス制御命令とともに、ＳＩＰノード２０２に対し、制御をハンドバックする。ＳＩＰノードは、リクエストを次のＳＩＰクライアント２０４へ送信する。そのリクエストの応答は、ＳＩＰノード２０２を介して反対方向に次のＳＩＰクライアント２０４から前段のＳＩＰクライアント２０３へ転送され、可能であれば、追加のサービスを起動する。次段のＳＩＰサーバ２０４は任意のサーバ、例えば、ＳＩＰ動作可能ＰＣ、無線端末、次のホッププロキシ、ＳＩＰ／ＰＳＴＮゲートウェイ等を表している。サーバは、着信リクエストを処理する。リモートサーバ２０６は、例えば、別のサービスサポート環境で、リモートサービスの実行を行う。例えば、パフォーマンス基準に基づいて、サービスサポート環境２０１は、例えば、リクエスト／応答プロトコルを使用することによって、リモートサーバ２０６の処理を初期化することができる。この方法では、様々なカテゴリのサービスを呼び出し、様々なホストで管理することができる。リモートサーバに対して使用されるプロトコルは、例えば、ＳＩＰ、ＩＣＡＰ、ＨＴＴＰ、ＯＳＡ、ＡＰＩ等の任意のプロトコルをサポートするサポートリクエスト／応答ダイアログであり得る。管理サーバ２０５は、サービス環境での管理タスクを実行する。これは、ＳＩＰノード２０２のドメインに関連づけられているサービスサポート環境２０１を構成することができる。ここで、サービスサポート２０１の環境は、ＳＩＰノード、サービスアプリケーション、リモートホスト及び管理エンティティを含んでいる。
【００９７】
図３は本発明の実施形態に従うサービス実行ルールメカニズムをサポートするＳＩＰサーバのシステムアーキテクチャを示している。サービスサポート環境３０１は、配置インフラストラクチャ、即ち、あるフィーチャが別のフィーチャにどのように相互作用するかを実現する。ここで、サービスサポート環境３０１は、付加価値サービスをサポートするＳＩＰサーバ内で機能を提供する。サービスサポート環境３０１は、実行ルールベース３０７に記憶されるルールモジュール３０７を管理するルールエンジン３０３を有している。ルールエンジン３０３は、更に、ルールモジュールを処理することが可能なルールモジュール実行モジュール３１４を有している。ルールエンジンは、サービス実行エンジンマネージャ３０２を介してサービス３０９〜３１１を呼び出すことができる。サービス定義マネージャ３１２は、ルールモジュールの管理機能を提供する。ＳＩＰサーバは、更に、ＳＩＰデフォルト機能３０６及びＳＩＰメッセージパーサー３０５を含むＳＩＰプロトコルスタック３０４を実現する。メッセージパーサー３０５はＳＩＰプロトコルをサポートし、かつルールエンジン３０３によって解釈可能なメッセージプロパティを抽出する。管理サーバ３１３は、サービス環境上で管理タスクを実行する。
【００９８】
本発明に従うサービス配置ポリシーを実現する重要なメカニズムは、配置ルールの仕様を、ルールモジュールで特定されるサービス実行ルールとすることである。サービス実行ルールは、状態が満足している場合、取得する必要のある状態とアクションを特定する。本発明に従えば、これらのルールを特定するプログラミング言語が定義され、これは、サービス実行ルール言語（ＳＥＲＬ）として呼ばれる。
【００９９】
ルールモジュール３０８は、ルールエンジン３０３によって管理され、かつ実行される。ルールエンジン３０３は、起動及びフィーチャ相互作用メカニズムを実現する主要な機能エンティティであり、かつサービスサポート環境３０１の一部である。イベントが発生すると、メッセージパーサはルールエンジン３０３を呼び出し、イベントをルールエンジン３０３へとハンドオーバする。ルールエンジン３０３は、関連ルールモジュール３０８を検出してロードし、かつ受信したイベントに関連するそれらを正しい順序で処理する。フィルタリングは、契約関係の検出を含んでいる。イベントは、ルールモジュールが処理される場合のコンテキスト、即ち、ＳＩＰメッセージイベントのプロパティに従って状態が評価される場合のコンテキストを定義する。ルールエンジン３０３は、与えられたメッセージプロパティにルールパターンが照合する場合に対応するアクションを呼び出す。これらのアクションの内容に基づいて、ルールエンジン３０３は、呼出命令をアプリケーション実行エンジンマネージャ３０２あるいはサービスサポートシステム内の別の適切なエンティティに発行することができる。ＳＥＲＬスクリプトは、サービスについての知識を有していない、この知識とは、通常、フィーチャをどのように呼び出して管理するかについての知識以外のそのサービスが呼び出しかつ管理する知識である。呼び出されたサービスアプリケーションから受信した制御命令は、最新のルールモジュールが処理されている場合に、ＳＩＰスタック３０４に渡される。
【０１００】
ルールエンジン３０３は、更に、異なるサービス間で送信される情報を管理する。イベントが発生すると、イベントの関連プロパティを含むイベントコンテキストは、標準的な方法で確立される。メッセージプロパティは、名前と値を有している。値は、メッセージによって判定することができる。例えば、ＳＩＰメッセージプロパティの例は、以下のようになる。
【０１０１】
名前：sipRequest.Request-URL,   値：sip:bob@corp.com
名前：sipRequest.To,            値：Bob Smith ＜sip:bob@corp.com＞
名前：sipResponce.Status-Code,  値：301
ＳＤＰメッセージプロパティの例は、以下のようになる。
【０１０２】
名前：sdp.m,  値：video 48232 RTP/AVP 0
ルールエンジン３０３は、いくつかの内部ＡＰＩをサポートし、これは、機能エンティティとインタフェースすることによってアクセスすることができる。これらのＡＰＩは、以下のものを含んでいる。
【０１０３】
−メッセージ通知ＡＰＩ、メッセージパーサ３０５からルールエンジン３０３へのメッセージ通知用のＳＩＰスタック３０４によって使用される。
【０１０４】
−ルールベース定義ＡＰＩ、サービス定義マネージャ３１２によって使用される。
【０１０５】
−サービス命令ＡＰＩ、サービスアプリケーション３０９〜３１１のために、命令をルールエンジン３０３にハンドオーバするためのアプリケーション実行エンジンマネージャ３０２によって使用される。
【０１０６】
−アーミング（arming）ＡＰＩ、サービスアプリケーション３０９〜３１１のために、トリガーとトランザクションイベントのアーミングをリクエストするためのアプリケーション実行エンジンマネージャ３０２によって使用される。
【０１０７】
アプリケーション実行エンジンマネージャ３０２は、様々なタイプのサービスアプリケーションに対していくつかのアプリケーション実行エンジン３１５を組み込み、かつ管理する、これには、例えば、ＯＳＡエンジン、ＣＰＬエンジン、ＣＰＬインタプリタ、ＣＧＩエンジン及びサーバレットエンジンがある。これは、ルールエンジン３０３によって導入されるインタフェースをサポートし、かつアプリケーションＡＰＩとルールエンジンＡＰＩ間のマッピングを行う。ルールエンジン３０３の観点からは、すべてのアプリケーション実行エンジン３１５は、１つのエンティティ、即ち、アプリケーション実行エンジンマネージャ３０２のように見える。サービス定義マネージャ３１２は、更に、アプリケーション実行エンジン３１５に機能を提供することができる。
【０１０８】
アプリケーション実行エンジンマネージャ３０２によって提供されるＡＰＩは、以下のものを含んでいる。
【０１０９】
−呼出ＡＰＩ、ルールエンジンからアプリケーション実行エンジンマネージャ３０２への呼出命令用のルールエンジン３０３によって使用される。
【０１１０】
−通知ＡＰＩ、ルールエンジンからアプリケーション実行エンジンマネージャ３０２への通知命令用のルールエンジン３０３によって使用される。
【０１１１】
デフォルトＳＩＰサーバ行動３０６は、プロキシサーバ、リダイレクトサーバ、アプリケーションサーバあるいは汎用のユーザエージェントの機能を有している。更に、レジスタあるいはＩＭ＆Ｐ機能を含んでいていも良い。これは、命令を発行するために、ルールエンジン３０３によってアクセスできるインタフェースを提供する。選択的には、サービスアプリケーションは、ＳＩＰサーバ行動を実現することができる。それゆえ、サービスアプリケーションの要求に応じて、上述の各機能の一部のみを呼び出すためのルールエンジンを実現することができる。
【０１１２】
サービス定義マネージャ３１２は、管理サーバ３１３、サービスアプリケーション３０９〜３１１及びＳＩＰスタック３０４によって使用されるＯ＆Ｍ  ＡＰＩを提供する。ＡＰＩは、以下のものための機能を提供する。
【０１１３】
−新規ルールモジュール及びサービスアプリケーションの証明及び認証マニュアル
−ルールモジュール及びサービスアプリケーションの権利及び特権の構成マニュアル
−ルールモジュール及びサービスアプリケーションのローディングマニュアル
−ルールモジュール及びサービスアプリケーションの起動／停止マニュアル
−ルールモジュールの有効化マニュアル
−スクリプト言語を使用して実現されるサービスアプリケーションの有効化マニュアル
−ルールモジュール及びサービスアプリケーションの削除マニュアル
−ルールモジュール及びサービスアプリケーションとそれらのステータスのリスティング（listing）マニュアル
−ルールモジュールの変更マニュアル
サービス定義マネージャ３１２は、更に、上述のマニュアル機能及び追加機能の少なくとも一方のいくつかの自動処理をサポートするインタフェースを提供することができる、この追加機能は、例えば、利用可能なサービスフィーチャのリスティング、インタフェース及びサービスフィーチャのバージョンの少なくとも一方の取得、サポートされている実行エンジン及びスクリプト言語、例えば、ＪＶＭ、ＣＰＬ、Ｐｅｒｌ等のリスティング、サービスフィーチャのインストール／アンインストール、サービスフィーチャの起動／停止、サービスをフィーチャとして他のサービスアプリケーションに提供するサービスアプリケーションの登録、サービスフィーチャの加入、サービスフィーチャの呼出／終了、「プロセッサ負荷の監視」や「発信集中時間帯」のような統計オペレーション、アカウントオペレーション、アカウントレコードの起動／停止、読出、リセット等がある。
【０１１４】
ここで、サービスフィーチャという用語は、サービスアプリケーションに提供される機能を意味する。サービスフィーチャは、サービスサポート環境３０１及びＳＩＰスタック３０４に統合されているものと見なされる。アプリケーション実行エンジンマネージャ３０２とサービス定義マネージャ３１２はともに、サービスフィーチャをサービスアプリケーション３０９〜３１１を提供する。但し、アプリケーション実行エンジンマネージャ３０２によって提供されるフィーチャのいくつかは、ルールエンジン３０３及びＳＩＰスタック３０４を介して処理される。
【０１１５】
サービスアプリケーション３０９〜３１１はプログラムであり、コンパイルあるいはインタプリトされて、ＳＩＰサーバのサービスサポート環境３０１内で動作する、あるいはリモートサーバ上で動作する。これらの用途は、ＳＩＰサーバの基本機能に関連付けるあるいは関連づけないようにすることができる。サービスアプリケーションは、ＳＩＰサーバ行動を実現することができる。サービスアプリケーションは、サービスを他のサービスアプリケーションに提供することができる、即ち、それらをサービスフィーチャとすることができる。例えば、サービスアプリケーションは、いくつかのＭＩＭＥタイプのコンバータを含むことができ、かつそれをサービスフィーチャとして他のサービスアプリケーションに提供することができる。他のサービスアプリケーションは、サービスを実行するためにこの機能を使用することができる。好ましくは、サービスアプリケーションは、ＳＩＰサーバ間で移動可能とするべきであり、かつリモートサーバ上で実行することができる。サービスアプリケーションは、アプリケーション等への特定ファイルパス、公開標準化ＡＰＩ、例えば、ＳＩＰ−ＣＧＩ、ＯＳＡ  ＡＳＩ、ＨＴＴＰ、ＩＣＡＰ、ＣＰＬ、サーブレット等を使用することによって、グローバルあるいはローカルネーミング取り決めを介して、標準化あるいはローカル名前空間にアクセスすることができる。
【０１１６】
サービスアプリケーションにアクセスする標準化メカニズムは、サードパーティサービスプロバイダに対して有効である。
【０１１７】
ＳＩＰサーバは、遠隔に配置されているサービスアプリケーションを管理する必要はない、これは、ＳＩＰサーバがそれらについての知識を持っていない可能性があるからである。この場合、ＳＩＰサーバあるいはアプリケーション実行エンジンマネージャ３０２は、情報を起動することによって提供されるロケーション情報を必要とする。
【０１１８】
メッセージパーサ３０５は、受信されたメッセージを解釈し、予め定義されている要素をメッセージプロパティとして分離し、適切な場合に有効化されるアクションを発生することが可能である。イベントが発生すると、メッセージパーサ３０５によって分離された関連プロパティを含むメッセージオブジェクトが確立される。
【０１１９】
好ましくは、任意のサポートされているプロトコルは、対応するメッセージパーサを有している。パーサは、下位のプロトコル、即ち、ＳＩＰのような他のプロトコルに組込まれるプロトコルに対応する下位のパーサを含むことができる。例えば、ＳＩＰメッセージパーサ内には、例えば、ＳＤＰ、ＨＴＭＬ、ＸＭＬ及びＸＨＴＭＬのような様々なメディアのタイプを取り扱う複数のパーサを存在していても良い。ルールエンジンの観点からは、すべてのパーサは、１つのエンジンのように見える。メッセージパーサ用のＡＰＩは、好ましくは、新規のプロトコルとコンテンツ用のパーサをモジュールとして追加できるように定義されるべきである。
【０１２０】
サービスサポート環境３０１によってサポートされる任意のプロトコルに対して、プロトコルのメッセージパーサとルールエンジン間のインタフェースは、以下のものを含んでいる。
【０１２１】
−プロパティ名、プロパティを特徴付けるメッセージとの関係及びプロパティを変更するためのアクションの能力を含むメッセージパーサによって定義されるプロパティ群
−ルールを有効化できる処理ポイント
本発明の実施形態では、サービスサポート環境３０１あるいはサービスサポート環境内の各機能エンティティは、複数のサーバを実現する別々のホストに配置することができる、このサーバは、例えば、ＳＩＰ、Ｗｅｂ、ＷＡＰ、Ｉ−Ｍｏｄｅ、ＲＴＳＰサーバ及び、例えば、データベース、ＯＳＡ、Ｗｅｂ、ＳＩＰ等の多元アクセスアプリケーションサーバがある。
【０１２２】
例えば、ルールエンジン３０３、アプリケーション実行マネージャ３０２及びサービス定義マネージャ３１２は、それぞれ自身のホスト、可能であれば、ＩＰを介して接続されるホストに配置することができる。ルールエンジンと様々なサーバ間のインタフェースは、標準化するあるいは専用化することができる。ルールエンジン、アプリケーション実行エンジンマネージャ及びサービス定義マネージャ間のインタフェースは、好ましくは、専用化かつパッケージ化するべきである。サービスアプリケーションサーバとサービスサポート環境間のインタフェースは、ＯＳＡ  ＡＰＩ、ＨＴＴＰ、ＳＩＰあるいはいくつかのＳＱＬベースのＡＰＩのようなデータベースＡＰＩのように、標準化されていることが好ましい。このような分散型構成では、本発明の更なる効果が得られることが明らかであり、これは、ルールエンジンが、多くのタイプのイベント、例えば、ＳＩＰイベントばかりでなく、ＨＴＴＰイベント、ＳＭＴＰイベント、Ｗａｐイベント、ＭＰＥＧ７イベントあるいは３Ｄ仮想現実あるいはゲームオブジェクトイベントのようなメディアコーディックイベント等のイベントを管理することができることである。
【０１２３】
更に、図３を参照すると、本発明の実施形態に従う起動メカニズムを、簡単な例で示すことができる、この簡単な例では、１つのルールモジュールだけが受信イベントに関連していると想定している。図３において、丸数字は、以下の起動例の各工程を参照するものである。
【０１２４】
１．ＳＩＰリクエストは、メッセージパーサ３０５で受信される。
【０１２５】
２．ＳＩＰメッセージパーサ３０５は、ＳＩＰメッセージオブジェクトを生成する。ルールエンジン３０３は、これをＳＩＰイベントコンテキストに変換する。
【０１２６】
３．関連ルールモジュール３０８は、イベントコンテキスト、処理ポイント及び契約関係に基づいて、実行ルールベース３０７に配置される。本実施形態のメカニズムは、以下で説明される。
【０１２７】
４．ルールエンジン３０３は、実行ルールベース３０７から検出したルールモジュール３０８をルールモジュール実行エンジン３１４にロードし、それを実行する。例を示すと、ロードされたルールモジュールが以下の機能、即ち、サービスアプリケーション３１０及び３１１用の起動基準及び呼出アクションを特定するルールを含んでいるとする。
2004532472.tif 000003
５．起動が行われ、特定されたサービスアプリケーションＹ（３１０）が、呼出コマンドをアプリケーション実行エンジンマネージャ３０２に送信することによって呼び出される。
【０１２８】
６．アプリケーション実行エンジンマネージャ３０２は、アプリケーションＹ（３１０）を配置する。
【０１２９】
７．アプリケーション実行エンジンマネージャ３０２は、関連サービスアプリケーションＹ（３１０）をアプリケーション実行エンジン３１５にロードし、続いて、それを実行するために有効化する。
【０１３０】
８．アプリケーション３１０から得られる命令は、ルールエンジン３０３に戻される。
【０１３１】
９．ルールエンジン３０３は、ルールモジュールの処理を再開し、別のアプリケーションＺ（３１１）を起動する。呼出コマンドは、アプリケーション実行エンジンマネージャ３０２に与えられる。
【０１３２】
１０．アプリケーション実行エンジンマネージャ３０２は、アプリケーションＺ（３１１）を配置する。
【０１３３】
１１．アプリケーション実行エンジンマネージャ３０２は、関連サービスアプリケーションＺ（３１１）をそのアプリケーションを実行できる実行エンジン３１５にロードし、続いて、それを有効化する。
【０１３４】
１２．アプリケーション３１１から得られる命令は、ルールエンジン３０３に戻される。
【０１３５】
１３．ルールエンジン３０３は、ルールモジュールの処理を再開し、ルールモジュールがこれ以上実行するルールがないこと、かつロードするルールモジュールがこれ以上ないことを検出する。
【０１３６】
１４．ＳＩＰデフォルト行動３０６は、ルールエンジン３０３からの出力と、得られるデフォルト出力とをマージし、ＳＩＰメッセージをメッセージパーサ／コンバータ３０５へ送信する。
【０１３７】
１５．ＳＩＰメッセージは、例えば、プロキシ化されている。
【０１３８】
複数のルールモジュールの場合、上記のステップ１３及び１４は、選択的には、以下のようにしても良い。
【０１３９】
１３．ルールエンジン３０３は、ルールモジュールの処理を再開し、かつルールモジュールがこれ以上実行するルールがないことを検出する。ルールエンジン３０３は、以前に実行されているルールモジュールより優先度が低いルールモジュールを検索する。
【０１４０】
１４．上述の例のポイント３へ進む。ルールモジュールが、上述の例のものとして実行されることが検出される場合、呼出可能な他のアプリケーション、例えば、アプリケーション３０９が呼び出される。
【０１４１】
セッションを制御するためのルールモジュールあるいはサービスがインストールされていない場合、ルールエンジン３０３は制御をＳＩＰサーバへハンドオーバし、空出力を指定する。ＳＩＰサーバは、レジスタ、リダイレクトサーバ及びプロキシサーバ用のデフォルトＳＩＰ行動に従うＳＩＰ−ＣＧＩのように、できる限り、空出力とサーバのデフォルト行動３０６をマージする。
【０１４２】
図４は、本発明の実施形態に従うルールモジュールの構造を示している。本発明に従えば、ルールモジュール４００は、概念的には、いくつかのサービス実行ルール４０１〜４０２からなるツリーであり、各ルールは、いくつかの状態４０３〜４０４及び４０５と、いくつかのアクション４０６〜４０７及び４０８を特定し、これらは、対応する状態が満足する場合に必要とされる。以下では、状態は、パターンと呼ばれる。最上位レベルで、ルールモジュールは、更に、以下のようになる。
【０１４３】
−所有者情報４０９は、ルールモジュールの所有者、即ち、注目のＳＩＰノードを有する識別可能なパーティを特定する。このパーティは、複数のルールモジュールを所有しても良い。所有者情報は、更に、契約関係についての情報を含んでいても良い。
【０１４４】
−プロトコル情報４１０は、ルールモジュールのルールを解釈するためのコンテキストを特定する。プロトコルの例は、ＳＩＰ、ＳＤＰ、ＨＴＴＰ、Ｈ．３２３等がある。好ましくは、これらは、ルールモジュール毎に１つのプロトコルのみが定義されるべきである。そうでなければ、いくつかが重複する場合は、多義性の解釈が与えられる。例えば、ＳＩＰ及びＨＴＴＰの両方は、コンテンツタイプヘッダフィールドを有している。
【０１４５】
−アクセス制御情報４１１は、どのパーティが、ルールモジュールを呼び出し、管理し、かつ読み出す権利を有しているかを特定する。
【０１４６】
ルールモジュールは、更に、ルールモジュール及びインデックス情報４１４用の更なるコンテキスト情報を提供する補助情報を更に持つことができる。
【０１４７】
パターン４０３〜４０５は、イベントコンテキスト内のメッセージプロパティに関して評価できる表現であり、かつコンテキスト内のプロパティを照合するために、ルールが照合するがしないかに関して評価できる表現である。アクション５０６〜４０８は、アプリケーション、ビルトインサービスフィーチャ、リモートサーバ、負荷共有ホストあるいは呼出対象の次のホップＳＩＰサーバを識別することができる。これらは、更に、ダウンロードされ、かつ外部に配置されたアクションオブジェクト等を識別することができる。ルール、状態及びアクションは、これらの行動を記述するパラメータを持つことができ、これらは、ツリーノードの属性である。ブランチは、どのブランチが最初に処理されるべきかを示す重みを有している。
【０１４８】
好ましくは、各ルールモジュールは、それに割り当てられた系統立てられた順序の優先度、即ち、ルールモジュールがルールエンジンによってロードされる場合のシーケンスを特定する順位優先度を有している。
【０１４９】
本発明の実施形態に従えば、グラフィカル表現のツリーのノードは、ＸＭＬ要素によって表現される。１つのノードから次のノードへのブランチは、分岐しているノードを表現する要素内の次のノード（群）を表現する要素を囲むことによって表現される。分岐の重みは、スクリプトで表現される場合の順序によって与えられる。この重みは、イベントが受信される場合に要素を処理する順序を与える。換言すれば、スクリプトは、最上部から最下部まで実行される。つまり、本実施形態では、ＳＥＲＬスクリプト内ではループは存在しない。好ましくは、ルールモジュールのフォーマットは、ＸＭＬ  ＤＴＤあるいはＸＭＬスキーマとして特定される。
【０１５０】
本実施形態の効果は、言語を特定するための標準化拡張言語に基づいていることである。
【０１５１】
本発明の実施形態では、ポリシーは、権限及び権利を特定するルールに関連づけることができる。ルールモジュールの各ノードは、関連づけられたポリシーノードを有することができ、アクセス制御リストを含むことができる。
【０１５２】
以下は、ＳＥＲＬスクリプトとして特定されるルールモジュールのインスタンスの例である。：
2004532472.tif 000004
図５は、本発明の実施形態に従って、制約のあるサービスのセットへのサービスのグルーピングを示している。本実施形態に従えば、サービス５０１〜５０８は、フィーチャグループ５０９〜５１０のセットにグループ化されている。図５に示される例では、フィーチャグループ５０９はフィーチャ５０１〜５０４を含み、フィーチャグループ５１０はフィーチャ５０５〜５０８を含んでいる。各フィーチャグループに対し、ある制約が、そのグループのサービスに課されている、即ち、それは、予め定義されているタイプの命令を発行することのみ許容されている。フィーチャグループは、１つのフィーチャがフィーチャグループ内でどのように相互作用を行うことを許可されているかを特定しないばかりか、それらはグループ行動における制約を違反しない。フィーチャグループは、例えば、フィーチャグループを数え上げることによって、連続して順序が付けられる。図５の例では、フィーチャグループ５０９は、フィーチャグループのシーケンスのＫ番目のフィーチャグループであり、かつフィーチャグループ５１０はＫ＋１に数えられる。フィーチャグループの順序付けは、実行順序を課しており、そうすることで、フィーチャグループ５０９のフィーチャは、グループ５１０のフィーチャを実行する前に実行される。好ましくは、フィーチャグループの定義は、例えば、グループインデックスを特定することによって、あるいは直前及び次のフィーチャグループを特定することによって、あるいはその類を特定することによって、グループの順序付けの仕様を示すものである。好ましくは、フィーチャグループの定義は、更に、前の状態、即ち、フィーチャグループのフィーチャの定義が依存する状態の仕様と、フィーチャグループのサービスの行動に従う制約の仕様を示しても良い。ここで、フィーチャグループは、サービスが呼び出される場合に順序付けされたシーケンスを提供することによってフィーチャ相互作用の基本的なタイプを形式化する順序付けメカニズムである。それゆえ、このメカニズムは、フィーチャ相互作用の問題を、制約のあるフィーチャのセットにグルーピングするフレームワークを提供する。このメカニズムは、実際にはこれらのフィーチャグループ間のフィーチャ相互作用を解決する、これは、フィーチャグループの制約によって、あるグループから次のグループへ制御をハンドオーバする場合のフィーチャ仮定が判定され、かつ予め定義されるからである。グルーピングの利点は、フィーチャ相互作用解析の問題を、より小さく個別の問題に分解するメカニズムを提供する、これによって、この問題の管理をより容易にする。また、形式化された問題の部分は個々のパーティに委任することができるので、この問題をよりスケーラブルにする。フィーチャグループのメカニズムは、管理者及びサービスプロバイダに、サービスアプリケーションが呼び出されるべき処理時間中の異なるポイントにサービスアプリケーションをカテゴライズする機能を与える。
【０１５３】
図６は、本発明の実施形態に従う再帰ＳＩＰメッセージフローにおいて、サービスの対応する位置で、制約のあるサービスのセットへのサービスのグルーピングを示している。本実施形態に従えば、フィーチャグループは、論理的なリクエスト／応答再帰メッセージフローの位置Ｐ１〜Ｐ６に関連していて、このフローはイベントコンテキストに対して保証されているある前提状態を有しており、ここでは、サービスアプリケーションは、この行動がその位置で許容されるかについての制約に基づいて呼び出される。これらのフィーチャグループは、処理ポイントと呼ばれる。
【０１５４】
６つの処理ポイントＰ１〜Ｐ６が、サービスの通常のグルーピングである。処理ポイントＰ１〜Ｐ３とＰ４〜Ｐ６は、対応する問題に論理的に対処する。処理ポイントＰ１〜Ｐ３は、リクエスト６０７で起動されるサービスを含み、処理ポイントＰ４〜Ｐ６は、応答６０８で起動されるサービスを含んでいる。論理的には、処理ポイントＰ１とＰ４、処理ポイントＰ２とＰ５及び処理ポイントＰ３とＰ６は、対応する制約に対応している。
【０１５５】
ＳＩＰメッセージは、大きく２つの部分に分けることができ、これは、シグナリングプロパティ、即ち、ＳＩＰ、ＳＤＰ等に関連するプロパティと、ｇｉｆ、ｈｔｍｌ等のシグナリングに関連しないメッセージ本体のコンテンツである。それゆえ、ＳＩＰイベントで起動されるサービスは、以下のものにグループ化することができる。
【０１５６】
−シグナリングプロパティに埋め込むグループ
−非シグナリングメッセージ本体のコンテンツのみに埋め込むグループ
−シグナリングプロパティでも非シグナリングメッセージ本体のコンテンツでもないものに埋め込むグループ
これは、３つの処理ポイントＰ１〜Ｐ３、それぞれに関連する３つのグループ６０１〜６０３へのサービスの基本的なグルーピングを行う。同様に、応答パスにおいて、対応するグループ６０４〜６０６は、それぞれ処理ポイントＰ４〜Ｐ６に関連している。
【０１５７】
ここで、シグナリングプロパティという用語は、サービスを呼ぶ出すためのルールモジュール状態で照合可能なＳＩＰ及びＳＤＰメッセージプロパティを示している。従って、シグナリングプロパティを変更するアプリケーションは、別の呼出対象のアプリケーションを発生する可能性があり、更に、別のアプリケーションを次々と呼び出す可能性がある。シグナリングプロパティに対する変更がすべて発生した後に、シグナリングプロパティを変更しないサービスアプリケーションの処理を処理ポイントに移動する利点は、管理者にとって、処理ポイントＰ２とＰ５でアプリケーションの順序付けにおけるタスクが容易となることである。
【０１５８】
本発明の実施形態では、処理ポイントＰ１〜Ｐ６は、以下のように定義することができる。
【０１５９】
−処理ポイントＰ１−前のホップクライアントリクエスト：直前のホップクライアントからのＳＩＰリクエスト６０７が受信される。この特定のリクエストと特定の加入者に対しては、任意の以前の処理ポイントではルールモジュールは呼び出されていない。この処理ポイントは、メッセージ本体コンテンツ以外で得られるメッセージ（群）のＳＩＰ／ＳＤＰシグナリングプロパティを埋め込むサービスを有している。
【０１６０】
−処理ポイントＰ２−リクエストコンテンツポイント：得られるＳＩＰ／ＳＤＰメッセージ（群）のシグナリングプロパティが生成され、かつキャッシュされている、即ち、ＳＩＰメッセージの部分が送信される状態にある。発信／メディア制御シグナリングプロパティへの追加の更新は、明示的に認証されていない限り、発生すべきではない。処理ポイントＰ２で呼び出されるサービス６０２は、処理ポイントＰ１で生成されるＳＩＰ／ＳＤＰシグナリングプロパティを埋め込むべきではない。しかしながら、これらは、そのルール以外となり得る。例えば、サービスは、アラート情報、発信情報、コンテンツ配置、コンテンツエンコーディング、コンテンツ言語、コンテンツ長、コンテンツタイプ及び条件のようなＳＩＰヘッダを埋め込むことができる。これらのシグナリングプロパティが、処理ポイントＰ１及びＰ２の両方で変更される場合、十分な注意を払うべきである。この処理ポイントで処理することができるメディアコンテンツのタイプの例は、ＳＯＡＰ、ＨＴＭＬ、ｖＸＭＬ、ＳＭＩＬ、ｇｉｆ、ｍｐｅｇ７、ａｕ等を含んでいる。
【０１６１】
−処理ポイントＰ３−リクエストバッチポイント：ＳＩＰ処理メッセージ（群）が、生成され、送信されている。処理メッセージ（群）へのこれ以上の更新は発生することができない。呼び出される必要はあるが、リクエストを処理するために必要とされるものを生成しない、かつ出力しないサービス６０３に、処理ポイントは対応する。これらのサービスは、処理メッセージ（群）を読み出すだけで、それを更新することはできない。
【０１６２】
処理ポイントである、
−Ｐ４−前のホップサーバ応答
−Ｐ５−応答コンテンツポイント
−Ｐ６−応答バッチポイント
は、処理ポイントＰ１〜Ｐ３と同様に、応答メッセージ６０８に対してそれぞれ定義することができる。
【０１６３】
選択的にはあるいは更には、他の処理ポイントを定義することができる。例えば、追加の処理ポイントＰ０（不図示）は、フィーチャにおける制約なしに定義することができ、これは、任意のイベントにおいて、即ち、リクエスト６０７及び６０８の両方の受信において起動される。
【０１６４】
好ましくは、追加の処理ポイントを、上位レベルの処理ポイントの１つに関連づけることができる。例えば、処理ポイントＰ１に対して定義することができるサブ処理ポイントは、Ｐ１．１、Ｐ１．２、Ｐ１．２．１、Ｐ１．２．２等で示すことができる。好ましくは、特定された前の状態に従って呼び出されることが有益となり得るサービスの論理的なグループを処理ポイントが定義する場合、新規の処理ポイントのみが定義されるべきである。
【０１６５】
以下のテーブルは、いくつかのサービスの例を含んでおり、これは、発信（originating）及び着信（terminating）ＳＩＰサーバでの様々な処理ポイントで定義することができる。
2004532472.tif 000005
図７は、本発明の実施形態に従う様々な処理ポイントに属するサービス間の処理フローを示している。図６で説明した実施形態では、ＳＩＰメッセージの様々な部分を埋め込むサービスは、様々な処理ポイントにグループ化されている。これは、サービスを有効に処理するために利用することができる。着信メッセージ７０１のＳＩＰシグナリングプロパティを埋め込むサービスは、処理ポイントＰ１に含まれている。それゆえ、処理ポイントＰ１からの出力は、最終の発信／メディア制御命令７０２を有している。これは、直ちに、可能なＳＩＰサーバデフォルト行動とマージすることができ、発信ＳＩＰメッセージ７０３を用意するメッセージコンバータ７０５へハンドオーバすることができる。加えて、処理ポイントＰ２で呼び出されるサービスは、シグナリングプロパティがこれ以上変化することがないことを信頼することができる、例えば、これらのサービスは、最終的に生成された宛先アドレスに依存するサービスに信頼性を与えることができる。
【０１６６】
処理ポイントＰ２の非シグナリングＳＩＰメッセージ本体コンテンツのみ（かつ可能であれば、関連コンテンツヘッダフィールド）を埋め込むサービスを集約することによって、得られる発信ＳＩＰメッセージ（群）７０３をサーバに対して実際に送信するための、処理ポイントＰ２からの出力７０４が十分に存在する。処理ポイントＰ２からの出力７０４は、メッセージコンバータ７０５へハンドオーバされ、処理ポイントＰ１からの出力７０２とマージされ、メッセージ７０３が送信される。
【０１６７】
処理ポイントＰ１及びＰ２からの出力が存在する場合、処理Ｐ３に到達される。処理ポイントＰ３のサービスは、得られるＳＩＰメッセージ７０３のコンテンツを埋め込まないが、それを信頼することができる。ここで、好ましくは、処理ポイントＰ１及びＰ２から生成されるＳＩＰメッセージは、処理ポイントＰ３に対するサービスの実行を待機する前に送信されても良く、これによって、システムの効率が向上する。
【０１６８】
ここで、処理ポイントに従うサービスのグルーピングは以下の効果を有している：処理ポイントは、フィーチャ相互作用の問題を簡単化する。処理ポイントは、フィーチャ相互作用の問題をよりスケーラブルにする。処理ポイントは、並行処理、即ち、マルチプロセッサを使用する場合に、処理メッセージの待ち時間を改善する。応答あるいはプロキシリクエストは、ネットワークにより早くハンドバックすることができる、これは、ＳＩＰサーバへの命令を特定しないサービスアプリケーションが処理ポイントＰ３に配置されているからである。ここで、応答あるいはプロキシリクエストは、呼出対象の処理ポイントＰ３のサービスアプリケーションを待機する必要はない。
【０１６９】
図８は、本発明の実施形態に従う管理権限に対応するルールモジュールへのサービスのグルーピングを示している。ルールモジュールは、それに関連するルールモジュール所有者を有しているので、これらは、管理者、即ち、ルールモジュール所有者がサービス配置ポリシーを特定することができる管理ドメインに対応する。ルールモジュール内では、アクションの順序は、ルールモジュールの所有者、即ち、ＳＥＲＬスクリプトの著作者によって割り当てられる。
【０１７０】
本発明の実施形態に従えば、各ルールモジュールは、自身に割り当てれている優先度を有している。優先度は、ルールモジュール間の関係を特定する。より上位のルールモジュール優先度のルールモジュールでは、より早いルールが適用される。図８は、２つのルールモジュール８０１及び８０２を示している。ルールモジュール８０１は、管理者Ａによって所有され、一方、ルールモジュール８０２は、管理者Ｂによって所有される。ルールモジュール８０１〜８０２のルールモジュール優先度は、ルールモジュールの順序によって示される、ここで、下位の順序が上位優先度に対応し、かつ上位の順序が下位優先度に対応する。例えば、ルール順序１は、最上位優先度として定義される。図８の例では、ルールモジュール８０１は、ルールモジュール順次ｈを有し、ルールモジュール８０２はルールモジュール順序ｈ＋１を有している。その結果、ルールモジュール８０１によって呼び出されるサービス８０３〜８０４は、ルールモジュール８０２のサービス８０５の前に実行される。
【０１７１】
同一の所有者を有するルールモジュールは、同一の順序付け優先度を持つことができる。好ましくは、この場合、それらは、様々なイベントコンテキスト（例えば、ＳＩＰ、ＨＴＴＰ、．．．．）を持つべきであり、これにより、同一の優先度を有する１つ以上のルールモジュールが同一のイベントコンテキストで呼び出されることを防止する。換言すれば、与えられているイベントコンテキストから同一のメッセージプロパティで呼び出すことができるルールモジュールは、異なるプロパティを有している。
【０１７２】
各管理ドメインは、他の管理ドメインと独立している。これは、ある管理ドメインが他のドメインに配置されているサービスの知識を持つ必要がないことを意味している。各管理者は、与えられているドメインのサービス配置ポリシーを解析し、かつ特定することができる。
【０１７３】
１つ以上のルールモジュールあるいはサービスアプリケーションが、与えられているイベントで呼び出される場合、これらはそれぞれ、フィーチャ命令のセットを提供し、これは、このイベントがどのようにして処理されるか、例えば、イベントが処理されるべきかあるいは終了されるべきかを特定する。厳密には、このようなフィーチャ命令は、同時に処理されるべきではなく、かついくつかのフィーチャ命令が互いに無効化する可能性がある。しかしながら、いくつかの場合では、どの順序でフィーチャ命令が適用されるかあるいはそれらが同時に適用されるかが重要でない場合がある。
【０１７４】
本発明に従えば、制御を他の管理ドメインにハンドオーバする場合には、管理ドメインにそれらのフィーチャ命令を保護することを可能にするメカニズムが提供される。これは、各管理ドメインが、自身のフィーチャの正規の行動に対して重要でないプロパティへ制御をハンドオーバすることを制限できることを意味する。あるサービスから別のサービスへ渡されるオブジェクトは、カレントイベントコンテキスト８０６〜８０７である。好ましくは、同一の管理ドメインに属するサービスアプリケーション間のイベントコンテキスト８０６の制御をハンドオーバする場合、デフォルトルールは、イベントコンテキストのプロパティが保護されない。いくつかのものを保護しなければならない場合、それは明示的に実行されなければならない。しかしながら、管理ドメイン間では、イベントコンテキスト８０７のすべてのプロパティが、デフォルトで保護される。いくつかのものを管理ドメイン間で保護する必要がない場合、それは、明示的に保護されていないことを示さなければならない。好ましくは、保護される及び保護されない少なくとも一方のプロパティを示すための権利は、ルールモジュールに関連する特権によって決定されるべきである。
【０１７５】
換言すれば、より上位のプロパティルールモジュールは、それらがメッセージプロパティをロックする特権を有している場合に、そのメッセージプロパティをロックすることができ、かつロックされたメッセージプロパティは、ルールモジュールがメッセージプロパティをアンロックする特権を持たない限り、ルールモジュールによってアンロックすることができない。
【０１７６】
以下の、ルールモジュールのフラグメントの例は、フィーチャＦ１が実行された後のメッセージプロパティのロッキング／アンロッキングを示している。
2004532472.tif 000006
本発明の実施形態では、アクション出力は、ルールモジュールで終了することができる、即ち、ダウンストリームアプリケーションは呼び出されない。また、アクションは、カレントイベントコンテキストのメッセージプロパティに明示的に特権を設定することができる、これは、それらがそのような特権を有している場合である。本実施形態の効果は、優先度が一旦割り当てられると、管理ドメインは独立することである。
【０１７７】
本実施形態に従えば、総合管理者は、ルールモジュールの所有者それぞれの契約関係に基づいて、ルールモジュールのプロパティあるいはプロパティの範囲を割り当てる。総合ドメイン管理者は、通常、最上位のプロパティルールモジュールの所有者でもある。例えば、階層の上位には、ホストのドメイン名及びＩＰアドレスを所有するＳＩＰサービスサービスプロバイダが存在する。ＳＩＰサービスプロバイダは、多くのサービスを多くのパーティに提供することができる。ＳＩＰサービスプロバイダは、自身の目的のために、例えば、ロギング、アカウンティング（acounting：アカウント取得）、統計処理、不正検出、広告処理等のために、アプリケーションを実行することもできる。ＳＩＰサービスプロバイダは、サーバに１つ以上のルールモジュールを配置することができる。
【０１７８】
例えば、ＳＩＰサービスプロバイダは、自身の加入者それぞれに対してルールモジュールを配置することができる。ＳＩＰイベントがＳＩＰサーバで受信された場合、ＳＩＰサービスプロバイダのメインルールモジュールは、いくつかの自身のサービスを呼び出すことができ、かつ適切な加入者に対するルールモジュールへ制御をハンドーバする。このルールモジュールでは、特定加入者に対して設計されているサービスを起動するルールが存在しても良い。これらのサービスは、ＳＩＰサービスプロバイダによって、あるいはサードパーティサービスプロバイダから譲渡されたＳＩＰサービスプロバイダによって提供されても良い。ＳＩＰサービスプロバイダは、好ましくは、ＳＥＲＬを使用することによって、これらのサービス間のフィーチャ相互作用問題を解析し、かつサービスアプリケーション間の順序優先度と命令優先度を特定することができる。この場合、メインルールモジュールと加入者ルールモジュールの両方が、ＳＩＰサービスプロバイダによって所有され、かつ管理される。これらは、１つの管理ドメインに存在していると言える。順序優先度のいくつかのポイントで、ＳＩＰサービスプロバイダは、加入者自身によって所有されるルールモジュールへハンドオーバすることを決定することができる。ここで、個々の加入者は、自身が所有するＳＥＲＬスクリプトを記述することができる、あるいは、例えば、ＨＴＭＬ形式を介して生成されるＳＥＲＬスクリプトのプリファレンスを更新することがだけができることに注意されたい。加入者のルールモジュールは、ＣＰＬスクリプトを呼び出すことができる、あるいは、逆に、別のルールモジュール、いくつかのサードパーティサービスプロバイダのルールモジュールあるいはその類を呼び出すことができる。加入者のルールモジュールが１つ以上のアクションを含んでいる場合、加入者は、どのアクションがまず実行されるべきかを特定しなければならない。同様に、サードパーティルールモジュールでは、アクションは、サードパーティの要望に従って、順序付けされなければならない。
【０１７９】
別の状況では、加入者は、企業消費者の従業員である場合がある。この場合、ＳＩＰサービスプロバイダのルールモジュールは、まず、いくつかのアプリケーションを呼び出すことができる企業消費者のルールモジュールへハンドオーバしてから、個々の加入者のルールモジュールへハンドオーバすることができる。
【０１８０】
上位レベルの管理者は、優先度順序をいくつかのルールモジュールに散在させようとする。しかしながら、これは、他のパーティの下位の優先度のルールモジュールに、ルールモジュールを散在させることは扱いにくい場合がある。この問題に対する１つの解決策は、後で使用することができる十分なバックアップ範囲を有するルールモジュール優先度に分割することである。選択的には、図１２で説明されるような、階層管理ドメインモデルを適用することができる。
【０１８１】
好ましくは、サービスサポート環境は、保護されたプロパティをアプリケーションが変更することを試行する場合に管理者へ通知するメカニズムをサポートする。好ましくは、保護されたプロパティを変更することを試行するアプリケーションは、サービスから取得される。
【０１８２】
上述のスキームの変形が可能であることに注意されたい。例えば、管理ドメインの階層では、各レベルの管理者は、下位の優先度のレベルのルールモジュールを割り当てられている優先度範囲内に配置するための絶対的な機会を持つことができる。上位レベルの管理者は、この機会を指定する。
【０１８３】
本実施形態の利点は、サービス配置ポリシーを管理し、かつ実現するためのスケーラブルメカニズムを提供することである。本実施形態に従えば、サービスサポート環境は、ドメイン管理者に対してかなりの余計な作業を行わせることなく、サードパーティサービス配置ポリシーを取り扱うことができる。これは、更に、いくつかの保管人あるいはそれらの間のいくつかの契約関係に制限が設けられるという利点がある。
【０１８４】
本実施形態の更なる利点は、フィーチャ相互作用解析のタスクが管理ドメインに小分けされ、これによって、関係のあるパーティ間の問題を分散することを可能にすることである。
【０１８５】
図９は、処理ポイントと管理権限の両方に従ってサービスがグループされる本発明の実施形態を示している。図９は、優先度順序ｈのルールモジュール９０１と優先度順序ｈ＋１のルールモジュール９０２を示している。ルールモジュール９０１は、サービスＦ１、Ｆ２、Ｆ５及びＦ６を呼び出し、一方、ルールモジュール９０２は、サービスＦ３、Ｆ４、Ｆ７及びＦ８を呼び出す。サービスＦ１〜Ｆ８は、更に、処理ポイント９０３及び９０４に関連している。処理ポイント９０３は、サービスＦ１〜Ｆ４を含み、処理ポイント９０４はサービスＦ５〜Ｆ８を含んでいる。処理ポイント９０３はインデックスＫ、処理ポイント９０４はインデックスＫ＋１となるように、処理ポイント９０３〜９０４に文字が付与されている、これは、処理ポイント９０３が処理ポイント９０４の前に処理されることを示している。
【０１８６】
本実施形態に従えば、ルールは、処理ポイントのシーケンスに適用される。その結果、ルールモジュールを処理する場合、現在の処理ポイントに属するサービス実行ルールだけが実行される。
【０１８７】
各処理ポイントに対して、優先度に従ってグループ化され、かつその処理ポイントで呼び出されるルールモジュールのセットが存在する。優先度１のルールモジュールすべては、セット１にグループ化され、優先度２のルールモジュールすべてはセット２にグループ化され、以下、同様にしてグループ化される。しかしながら、イベントコンテキストが与えられると、ほとんどのルールモジュールが各セットで呼び出される。ルールモジュールは、複数の処理ポイントに分散することができる。
【０１８８】
図９の例では、まず、処理ポイント９０３のサービスが、それらのルールモジュール優先度に従って処理される、即ち、サービスＦ１及びＦ２がサービスＦ３及びＦ４の前に処理される。続いて、処理ポイント９０４で、優先度ｈのフィーチャＦ５及びＦ６が、サービスＦ７及びＦ８の前に呼び出される。
【０１８９】
図９に示されるルールモジュール９０１及び９０２は、以下のルールモジュール例で示されるように表現することができる。
【０１９０】
ルールモジュール９０１：
2004532472.tif 000007
ルールモジュール９０２：
2004532472.tif 000008
図１０は、複数のルールモジュールと複数の処理ポイントの場合の図９の実施形態の処理メカニズムを示している。本実施形態に従えば、Ｐ０からＰ３で示される４つの処理ポイントと、それぞれ優先度１から５を有するＲＭ  ＡからＲＭ  Ｅの５つのルールモジュールが存在する。図９と併せて説明される処理ルールに従えば、サービスは、番号１から２０と矢印で示される図１０の丸数字によって示されるように、処理される。各丸数字は、いくつかのアクションを呼び出すルールのセットを表している。
【０１９１】
図１１は、図９と併せて説明される処理ルールの別の例を示している。図１１は、左側に１１０１にルールモジュールＲＭ  ＡからＲＭ  Ｅのインスタンス１１１１ａ〜１１１５ａと、右側１１０２にルールモジュールＲＭ  ＡからＲＭ  Ｅのインスタンス１１１１ｂ〜１１１５ｂを示している。ルールモジュールＲＭ  ＡからＲＭ  Ｅは、処理ポイントＰ０からＰ６に対応するルールを有している。ここで、左側１１０１のルールモジュールのインスタンスは、右側１１０２のルールモジュールと同一のルールモジュールの異なるセクションを示している。図６で説明したように、処理ポイントＰ１〜Ｐ３は、ＳＩＰリクエストによって起動され、一方、処理ポイントＰ４〜Ｐ６は応答によって起動される。処理ポイントＰ０は、リクエスト及び応答の両方によって起動される。尚、本例では、着信ＳＩＰリクエスト１１０３、例えば、ＩＮＶＩＴＥリクエストは、図１１の左側１１０１の矢印で示される順序で、処理ポイントＰ０〜Ｐ３に関連するルールモジュールＲＭ  ＡからＲＭ  Ｅのサービスを起動する。図１１の例では、更に、サービス１１０４は応答１１０５を発生する命令を出力すると仮定する。この応答は、一方で、処理ポイントＰ０及びＰ４〜Ｐ６に関連するルールモジュールＲＭ  Ａ（１１１ｂ）からＲＭ  Ｅ（１１１５ｂ）のルールの処理を起動する、これは、図１１の右側１１０２で示されるように、サービス（群）１１０６で開始し、発信メッセージ１１０８、例えば、生成された仮応答を出力する。左側１１０１のサービスの処理は、更に、発信メッセージ１１０７、例えば、ＩＮＶＩＴＥプロキシリクエストを出力する。
【０１９２】
図１２は、本発明の実施形態に従う階層ルールモジュール処理を示している。ルールエンジン１２００がイベント１２０１を受信すると、これは、ルール単位で、このイベントに対する様々な優先度の関連ルールモジュール１２１６〜１２１９を識別する。ルールエンジン１２００は、カレントイベントコンテキスト１２０２を生成し、最上位優先度のルールモジュール１２１６の処理を初期化し、生成されているカレントイベントコンテキスト１２０２を介してルールモジュール１２１６へ制御を渡す。最上位優先度のルールモジュール１２１６の処理が完了すると、ルールエンジン１２００は、ルールモジュール優先度に従って次のルールモジュール１２１７を呼び出し、変更されたカレントイベントコンテキスト１２０６を次のルールモジュール１２１４へ渡す。同様に、次のルールモジュール１２１８〜１２１９が呼び出され、それぞれのカレントイベントコンテキスト１２０７及び１２１４を介して制御がそれらに渡される。そして、それによって得られるイベントコンテキスト１２１５はルールエンジン１２００に返される。本発明の実施形態に従えば、それぞれ呼び出されたルールモジュールが、連続して１つ以上の他のルールモジュールを呼び出すことができる。本実施形態に従えば、ルールモジュールは、２つのタイプのルールモジュールに分けられる：自身の順序優先度で、ルールエンジン１２０によって呼び出されるルールモジュール１２１６〜１２１９と、他のルールモジュールによってのみ呼び出されるルールモジュール１２２０〜１２２５である。後者のタイプのルールモジュールは、通常、特定順序優先度、例えば、順序優先度０によって識別される。本実施形態に従えば、この優先度のルールモジュールは、それらに関連する特別な制限を有している：この優先度を有するルールモジュールは、ルールエンジン１２００のルールベース処理プロシージャによって呼び出されるべきではないが、それを行う明示的な特権を有する別のルールモジュールから呼び出される。０とは異なる順序優先度のルールモジュールは、他のルールモジュールから呼び出されないばかりか、ルールエンジンによっても呼び出されない。同一の所有者のルールモジュールは、同一の順序優先度（０とは異なる）を持つことができるが、この場合、異なるイベントコンテキスト、例えば、ＳＩＰ、ＨＴＴＰ等を持つべきである。これは、それらが、同一のイベントコンテキストで呼び出されるべきでないことを意味する。異なる所有者のルールモジュールは同一の順序優先度を持つことができるが、この場合、これらは、同一のイベントの同一のプロパティで呼び出されるべきではない。換言すれば、与えられているイベントコンテキストから同一メッセージプロパティで呼び出すことができるルールモジュールは、それがゼロでない限り、異なる優先度を持つべきでない。最初のルールモジュール１２１６は、順序優先度０の任意のルールモジュールが呼び出される前に、ルールエンジンによって呼び出される。このルールモジュールは、ルートルールモジュールと呼ばれる。ルートルールモジュールが優先度０のルールモジュールを呼び出す場合、これらは、他の優先度０のルールモジュールを再度呼び出すことができる。ルールモジュール間のこれらの関係は、ルールモジュール階層と呼ばれる。ルールモジュール内からのルールモジュールを呼び出すメカニズムは、階層管理ドメインモデルとも呼ばれる、管理ドメインの階層分布を与える。このモデルの利点は、管理が容易で、かつマスタルールモジュールへかなりの量の制御を与えることである。更なる利点は、かなりの数の優先度を次のルールモジュールに再割当することなく、追加のルールモジュールを、既存の階層に追加できることである。上述のルールは、ルールモジュールがルールベース処理プロシージャのアクシデントによって２回起動されることを回避する。
【０１９３】
図１２に示される例では、ルールモジュール１２１６は、ルールモジュール１２２１及び１２２２の順序でそれらを呼び出し、対応するイベントコンテキスト１２０３〜１２０４へ制御を渡し、それによって得られるカレントイベントコンテキスト１２０５を受信する。同様に、ルールモジュール１２１８は、対応するイベントコンテキスト１２０８〜１２０９と、それによって得られるイベントコンテキスト１２１３でルールモジュール１２２２〜１２２３を呼び出す。そして、ルールモジュール１２１８によって呼び出されるルールモジュール１２２３は、更に、対応するイベントコンテキスト１２１０〜１２１１とそれによって得られるイベントコンテキスト１２１２でルールモジュール１２２４〜１２２５を呼び出す。
【０１９４】
ここで、イベントコンテキスト１２０２〜１２１５で示される順で、カレントイベントコンテキストのシーケンスを生成する、階層呼出処理が実行される。
【０１９５】
ここで、これ以上処理ポイントが定義されない場合は、上述のルールモジュール処理は処理ポイント単位であると理解されるべきでない、即ち、各処理ポイントに対して対応する階層ルールモジュールが処理されることに注意されたい。
【０１９６】
ルールエンジン１２００のルールベース処理プロシージャの重要なタスクは、ＳＩＰイベントを関連ルールモジュールへマッピングすることである。この処理は、当該のドメインで定義されている契約関係にほとんど依存している。ＳＩＰイベントは、取り得る契約関係を検出するために使用することができる、いくつかのメッセージをプロパティを含んでいる。これらのプロパティは、ｓｉｐｒｅｑｕｅｓｔ．ｆｒｏｍ、ｓｉｐｒｅｑｕｅｓｔ．ｔｏ、ｓｉｐｒｅｑｕｅｓｔ．ＲｅｑｕｅｓｔＵＲＩ、ｓｉｐｒｅｓｐｏｎｃｅ．ｆｒｏｍ、ｓｉｐｒｅｓｐｏｎｃｅ．ｔｏ、ｓｉｐｒｅｓｐｏｎｃｅ．ｃｏｎｔａｃｔ及びｓｉｐｒｅｓｐｏｎｃｅ．ｖｉａを含んでいる。特に、ＳＩＰメッセージのＦｒｏｍ及びＲｅｑｕｅｓｔ−ＵＲＩは、ネットワークオペレータあるいはサードパーティサービスプロバイダで、契約関係を検出するために使用されるイベントの重要なプロパティである。しかしながら、他のメッセージプロパティは、例えば、コンタクトヘッダ及びｖｉａヘッダで考慮される。契約関係を検出する、つまり、ルールモジュールを起動するために使用することができるメッセージプロパティは、ルールモジュールトリガー（ＲＭＴｒｉｇｇｅｒ）と呼ばれる。
【０１９７】
ＳＩＰリクエストメッセージがＳＩＰサーバへ到達すると、ＦｒｏｍあるいはＲｅｑｕｅｓｔ−ＵＲＩメッセージプロパティの少なくとも１つは、ＳＩＰサーバのネットワークオペレータの１人と契約関係を有する加入者を特定すべきである。ＦｒｏｍあるいはＲｅｑｕｅｓｔ−ＵＲＩのメッセージプロパティは、ｎｅｔｏｐＸ．ｃｏｍのようなドメイン名、あるいは１２３．１２３．１２３．０００のようなＳＩＰサーバのネットワークオペレータの１つのＩＰアドレスを含んでいても良い。加えて、ＦｒｏｍあるいはＲｅｑｕｅｓｔ−ＵＲＩは、名前あるいは電話番号のような加入者識別子を含んでいる。これは、ＳＩＰ  ＵＲＬあるいはＴＥＬ  ＵＲＬに含まれている。ＳＩＰ−ＵＲＬは、「ｔｒａｎｓｐｏｒｔ−ｐａｒａｍ」、「ｕｓｅｒ−ｐａｒａｍ」及び「ｏｔｈｅｒ−ｐａｒａｍ」のようなパラメータも有している。これらのパラメータは、移動端末加入者及び端末群を識別するためのＩＭＳＩとして、ネットワークオペレータを特定する情報を含むことができる。
【０１９８】
例えば、上述のプロパティを使用して、ＳＩＰイベントに固有のネットワークオペレータがマッピングされる、これは、いくつかの条件を満足する場合、ＳＩＰサーバのネットワークオペレータのそれぞれが、ｎｅｔｏｐＸ．ｃｏｍ及びｎｅｔｏｐＹ．ｃｏｍのような固有のドメイン名を有している場合、及びそれらが異なるＩＰアドレスを有している場合である。これらが同一ＩＰアドレスを共有する場合、推測関係分析が、Ｆｒｏｍ及びＲｅｑｕｅｓｔ−ＵＲＩがＩＰアドレスを含むがドメイン名を含まないような多義性となる可能性がある。
【０１９９】
ＳＩＰサーバにサービスアプリケーションを更新／登録するサードパーティサービスプロパイダは、検出できるネットワークオペレータとの契約関係を有している。例えば、サードパーティサービスプロバイダは、サードパーティサービスプロバイダを契約関係のあるネットワークオペレータから割り当てられたＩＤを受信することができる。ネットワークオペレータが、例えば、ｎｅｔｏｐＸ．ｃｏｍのようなドメイン名と関連ＩＰアドレスを有している場合、固有名ｐａｒｔｙＺを有するサードパーディサービスプロバイダは、例えば、「ｐａｒｔｙＺ．ｎｅｔｏｐＸ．ｃｏｍ」のような名前取り決めに続く割当ＩＤを受信することができる。ここで、Ｆｒｏｍ及びＲｅｑｕｅｓｔ−ＵＲＩは、関連ルールモジュールと照合される。ｎｅｔｏｐＸ．ｃｏｍ及びｐａｒｔｙＺ．ｎｅｔｏｐＸ．ｃｏｍの両方がＦｒｏｍあるいはＲｅｑｕｅｓｔ−ＵＲＩのいずれかでｎｅｔｏｐＸ．ｃｏｍを含むイベントで呼び出されるべきである場合、それらは、異なる明示的な順序付け優先度を持つべきである。これは、他の名前取り決めが代わりに導入され得ることが理解される。
【０２００】
順序優先度及びルールモジュール階層のメカニズムは、図１２とともに上述されたように、互いに独立して適用され得るあるいは互いの組み合わせで適用され得ることが理解される。
【０２０１】
図１３は、本発明の実施形態に従うＳＩＰメッセージ及び命令セットのフローの例を示している。メッセージパーサ１３０４は、オリジナルメッセージ１３０６をオリジナルＳＩＰメッセージオブジェクト１３０３に変換する。これは、初期ルールモジュール１３０１、ここでは、サービスアプリケーションの最初のシーケンスを呼び出すために使用される。ルールモジュール１３０１がルールエンジンへロードされ、かつ起動されると、メッセージパーサ１３０４から受信されるシグナリングメッセージオブジェクト１３０３に依存して、かつ、例えば、上述の図１２で説明されるように、どのルールモジュール１３０１が識別されるかに基づいて、１つ以上のアクションに到達する。アクションに到達すると、そのアクションに関連するサービスアプリケーション１３０５が呼び出される、つまり、有効化され、可能であれば、パラメータとともに、かつ可能であれば、アプリケーションを起動したシグナリングメッセージオブジェクト１３０３全体へのアクセスとともに有効化される。シグナリングメッセージ全体へのアクセス特権は、例えば、ＣＧＩ  ＡＰＩ対ＯＳＡ  ＡＰＩのような使用されるサービスアクセスＡＰＩの機能及び範囲に依存するとともに、ルールモジュール１３０１の所有者の特権及び呼び出されるサービスアプリケーション１３０５の特権にも依存している。初期シグナリングメッセージオブジェクト１３０３は、複数のメディアタイプを含むことができるオリジナルＳＩＰメッセージ１３０６に埋め込まれるメッセージプロパティのセット全体を表現している。呼び出されるサービスアプリケーション１３０５は、シグナリングメッセージ１３０３に基づいていくつかの処理を実行し、かつその結果１３０７をルールエンジン１３０３へハンドバックする。これの結果は、命令セットとして参照され、例えば、ＣＧＩ命令、ＯＳＡ  ＡＰＩ命令等の複数の命令を潜在的に含むことができる。複数のサービスが、１つのシグナリングメッセージに基づいて呼び出されると、ルールモジュールプロセッサは、複数の命令セットを出力する。この命令のセットのセットは、「命令セットベース」と呼ばれる。
【０２０２】
ルールエンジン１３０２及びアプリケーション実行エンジンは、どの命令がＳＩＰサーバデフォルト行動１３０８へ渡されるかを判定する。命令セットは、命令がＳＩＰサーバデフォルト行動１３０８へ渡される前に、特権及びフィーチャ相互作用分析に基づいてフィルタにかけられる、ここで、ＳＩＰサーバデフォルト行動１３０８は、更に、命令セットとデフォルトＳＩＰ命令セット１３１２をマージすることができる。得られる命令のセットは、「出力（処理結果）（resulting）命令セット」と呼ばれる。出力ＳＩＰメッセージオブジェクト（群）１３０９は、実際のＳＩＰメッセージを表現し、これは、ダウンストリームあるいはアップストリームで送信されるものである。ここで、これは、１つ以上の出力ＳＩＰメッセージオブジェクト１３０９をもたらし、これは、メッセージコンバータ１３１０へ送信され、続いて、送信対象の１つ以上のＳＩＰメッセージ１３１１へ変換される。
【０２０３】
図１４は、本発明の実施形態に従う複数の命令セットを管理するメカニズムを示している。本実施形態に従えば、イベントコンテキストは、ＳＩＰメッセージオブジェクトの表現であるが、これは、フィーチャ相互作用情報ばかりかＳＩＰメッセージ本体に含まれるＭＩＭＥタイプのような追加情報を含んでいる。オリジナルイベントコンテキスト１４０１は、オリジナルＳＩＰメッセージオブジェクト１４０２を表現している。カレントイベントコンテキスト１４０３ａ〜ｂは、サービスアプリケーション１４０４〜１４０５によって生成される命令セットに基づくイベントコンテキストである。任意の時間に、１つのサービスアプリケーションがカレントイベントコンテキストの制御下にある。複数のサービスアプリケーションが実行中で、かつトランザクションの処理へ制御を適用する場合でさえも、それらの１つだけが任意にカレントイベントコンテキストの制御を行っている。図１４の例の場合、２つのサービスアプリケーション１４０４〜１４０５が示されている。まず、サービスアプリケーション１４０４はカレントイベントコンテキスト１４０３ａを介する制御を行っている。アプリケーション１４０４がその処理を完了している場合、カレントイベントコンテキストを介する制御が、サービスアプリケーション１４０５へハンドオーバされる。この時点で、サービスアプリケーション１４０５は、カレントイベントコンテキスト１４０３ｂを制御する、即ち、これは、カレントイベントコンテキストの読み書きの権利を有している。本発明の実施形態では、他のサービスアプリケーションは、カレントイベントコンテキスト１４０３ｂを読み出す権利を持っていても良い。
【０２０４】
ここで、次のサービスアプリケーションの起動は、カレントイベントコンテキストに基づいている。カレントイベントコンテキストが取り得るフィーチャ相互作用問題に対して取り除かれる、それによって、続いて呼び出されるサービスアプリケーションはそれを信頼することができる。制御が、ルールエンジンによって提供される呼出メカニズムを介して１つのサービスアプリケーションから次のサービスアプリケーションへ制御がハンドーバされると、カレントイベントアプリケーションの所有権がハンドオーバされる。この方法では、すべてのサービスアプリケーションが呼び出され、かつそれらの命令が適用されると、最終的な出力イベントコンテキスト１４０６が得られる。つまり、出力イベントコンテキスト１４０６は、出力ＳＩＰメッセージオブジェクト（群）１４０７を表現している。このメカニズムは並列処理が除外されないことに注意する、これは、サービスアプリケーション１４０４及び１４０５を並列で実行することができるからである。しかしながら、本実施形態に従えば、カレントイベントコンテキストの更新シーケンスで適用される。
【０２０５】
更に、サービスアプリケーションは、複数の宛先へリクエストを分割できることに注意されたい。これは、複数のカレントイベントコンテキストを生成することになる。
【０２０６】
図１５は本発明の実施形態に従うサービスアプリケーションのカスケード化チェーンのツリーを示している。異なるＳＩＰサーバ上でサービスが実行され、かつサービスが制御をセッションへ適用する場合、これらのサービスが互いに知らないとしても、これらのサービスは、サービスの正常な順序付けを提供する。この順序付けは、アップストリームあるいはダウンストリームであると呼べるかもしれない。ダウンストリーム順序付けは、発信クライアントから宛先サーバへとダウンストリームで呼び出されるサービスの順序付けである。アップストリーム順序付けは、宛先サーバから発信クライアントへとアップストリームで呼び出されるサービスの順序付けである。セッションのあるインスタンスへ制御を適用するサービスが、同一のＳＩＰサーバ上で与えられている順序で呼び出されると、サービスは、同一の順序付け原理に従ってカスケードされると判断することができる。この順序付け原理は、カスケードサービスと呼ばされ、サービスのチェーンはカスケード化チェーンサービスと呼ばれる。
【０２０７】
リクエストが受信されると、より前のサービスがそのイベントに基づいて呼び出され、より論理的にアップストリームであるそのサービスは、カスケード化サービスのチェーンであるとみなされる。応答が受信されると、より前のサービスがそのイベントに基づいて呼び出され、より論理的なダウンストリームであるサービスは、カスケード化サービスのチェーンであるとみなされる。ここで、アプリケーションは、それらが異なるホスト上で起動されたものとして処理される。
【０２０８】
このモデルは概念的には単純であり、かつ同一のＳＩＰイベントで複数のサービスアプリケーションの命令間での衝突を解決するための自然アルゴリズムを提供する。
【０２０９】
ＳＩＰイベントの受信において、アクションが以下の方法の優先度順序で実行される。  １）制御が、第１アプリケーションへ渡される。
【０２１０】
２）いくつかの応答が、第１アプリケーションから受信される。
【０２１１】
３）制御が、第２アプリケーションへ渡される。
【０２１２】
４）いくつかの応答が、第２アプリケーションへ渡され、以下、同様にして実行される。
【０２１３】
しかしながら、第１アプリケーションがリクエストを終了する場合、第２アプリケーションは呼び出されない。
【０２１４】
この方法では、次のアプリケーションを呼び出すかどうかについての決定は、直前のアプリケーションからの出力に依存させることができる。また、アクションに関連する命令優先度は、カスケード原理に従って順序付けされたデフォルトによるものである。
【０２１５】
アプリケーションが、リクエストを分割する場合、これは単純なチェーンのカスケード化サービスというよりも、カスケード化サービスのツリーとなする。これは、「リクエストツリー」と呼ばれる。リクエストツリーは、いくつかのカスケード化チェーンのアプリケーションを表現している。リクエストツリーのルートからあるリーフまでの各経路は、カスケード化チェーンを表現している。
【０２１６】
図１５は、リクエストツリーの例を示しておりで、ここでは、入力として、サービスアプリケーションＡＰＰ１が、オリジナルイベントコンテキストＯＥＣを有するルールモジュール実行モジュール１５０１によって呼び出される。制御がアプリケーションＡＰＰ１から次のアプリケーションＡＰＰ２へハンドオーバされると、アプリケーションＡＰＰ２は、カレントイベントコンテキストＥＣ２へ制御を移す。アプリケーションＡＰＰ２は、イベントコンテキストＥＣ３とイベントコンテキストＥＣ４を生成するリクエストを分割する。下位の優先度のアクションは、イベントコンテキストＥＣ３の１つ以上のプロパティによってアプリケーションＡＰＰ３を呼び出す。別の下位の優先度のアクションは、イベントコンテキストＥＣ４の１つ以上のプロパティによって別のアプリケーションＡＰＰ４を呼び出す。これは、呼び出されたアプリケーションの過程を表現するツリー状の構造を導き出す。このツリーにおいて、ブランチはイベントコンテキストを表現している。ノードは、トリガーを表現している。ツリーのルートは、オリジナルイベントコンテキストＯＥＣである。ツリーのリーフは、出力イベントコンテキストＲＥＣ１及びＲＥＣ２である。
【０２１７】
ルールモジュールにおいてこれ以上のアクションが存在しない場合、すべてのカレントイベントコンテキストがルールベース処理プロシージャ１５０２にフィードバックされる。このプロシージャは、より多くのリクエストツリーを構築する別のルールモジュールを呼び出す。その結果、ツリーは、起動されるサービスに依存して、多くのノードとブランチを持つことで、かなり大きくなる可能性がある。
【０２１８】
いくつかの場合、アプリケーションが非同期フィーチャ命令をサービスサポート環境に送信できる、即ち、既存トランザクションと関連していないことに注意されたい。この場合、アプリケーションは、新規のトランザクションを開始し、これは、新規のカスケード化チェーンツリーのルートとなることが想定される。
【０２１９】
サービスの並列処理を可能にするために、サービスサポート環境は、制御を１つ以上のサービスに同時に渡すことが可能である。これは、カスケード化サービスモデルでは矛盾とならない、なぜなら、並列して呼び出されたサービスからの命令は、カスケードする順序で適用されるべきであるからである。より多くのダウンストリームサービスが、より多くのアップストリームサービスの前に応答する場合、ルールエンジンは、その命令を取り次ぐ前に、応答のために、より多くのアップストリームを待機する。命令は、サービスが１つずつ呼び出されるように取り次がれる。管理者は、アクションのグループがこの方法で同時に適用されるべきであるかを特定することができるようにするべきである。
【０２２０】
図１６は、本発明の実施形態に従うルールエンジンのソフトウェアコンポーネントを示している。ルールベース処理プロシージャ１６０１は、正しい順序で、ルールベース１６０３に記憶されているルールモジュール１６０２を呼び出す。ルールモジュール処理プロシージャ１６０４は、ルールモジュールのルールを実行する。サービス相互作用モジュール１６０５は、起動、フィーチャ相互作用、特権及び権利の適用を含む機能１７００のセットを含んでいる。機能１７００は、図１７でより詳細に説明する。
【０２２１】
ＳＩＰイベントがオリジナルイベントコンテキスト１６０９の形態でルールエンジンに通知されると、ルールベース処理プロシージャ１６０１が、正しい順序で正規のルールモジュールを検出し、かつ実行するために実行される。ルールベース処理プロシージャ１６０１は、処理対象のルールモジュールとオリジナルイベントコンテキスト１６１０をルールモジュール処理プロシージャ１６０４へ渡す。各ルールモジュールのルールの順序付けとともにルールモジュールの順序付けは、ルールモジュール処理プロシージャ１６０４によって処理されるパターン（patern）及びアクション１６０６〜１６０８の順序付けを判定する。アクションは、対応するサービスアプリケーション１６１１〜１６１３を呼び出す。サービスアプリケーション１６１１を呼び出す場合、オリジナルイベントコンテキストは、カレントイベントコンテキストＣＥＣ１としてサービス相互作用モジュール１６０５へ渡され、一方、イベントコンテキストＥＣ１をサービスアプリケーション１６１１へ渡す。サービスアプリケーション１６１１は、サービス相互作用モジュール１６０５によってカレントイベントコンテキストの更新を発生するフィーチャ命令１６１４のセットを得る。この得られるカレントイベントコンテキスト１６１５は、ルールモジュール処理プロシージャ１６０４へ戻される。サービスアプリケーション１６１２及び１６１３は、同様の方法で呼び出され、それによって得られる対応する命令セット１６１６〜１６１７は、サービス相互作用モジュール１６０５によって対応するカレントイベントコンテキスト１６１８〜１６１９に変換される。この変換中に、サービス相互作用モジュール１６０５は、認証チェックを実行し、サービスアプリケーション１６１３が未認証命令セット１６１７を返す場合、未認証命令は変換されない。ここで、カレントイベントコンテキスト１６１９は、入力イベントコンテキスト１６２０とは異なっていない。好ましくは、サービスアプリケーションは、この失敗についての通知１６２１を行う。サービスは、図１５及び図１８で説明される複数のカレントイベントコンテキストの発生をもたらす可能性があることに注意されたい。ルールモジュールは、パターン及びアクション１６０６〜１６０８の処理を終了する場合、最終的なカレントイベントコンテキスト１６２２のセットはルールベース処理プロシージャ１６０１へ戻される。次のルールモジュールの呼出は、このカレントイベントコンテキストのセットに依存している。サービスアプリケーションが、以下で詳細を説明するように、フィーチャイベントに対するイベント及びトリガーをアーミングする（arming：持てる）／アーミングしない（disarming：持たない）可能性があることに注意されたい。ここで、サービスアプリケーションは、更に、アーミングリクエスト１６２３を戻すことができる。
【０２２２】
図１７は、図１６の実施形態のサービスアプリケーションの処理とルールモジュールの処理間でサービス相互作用モジュールによって実行される工程を示している。この機能１７００は、フィーチャ相互作用管理と、ルールエンジン１７０２及びアプリケーション実行エンジン１７０３によって実行される特権のチェックを含んでいる。呼出コマンド及びカレントイベントコンテキストＣＥＣａがルールモジュールプロセッサ１６０１から受信される場合、ステップ１７０４で、ルールモジュールの特権がチェックされる。ルールモジュールの特権は、そのルールモジュールに関連するアクセス制御リストＡＣＬ２で特定されている。ルールモジュールが呼出コマンドを発行する特権を有している場合、ステップ１７０５で、ルールエンジン１７０２は呼出コマンドを、アプリケーション実行エンジンマネージャ（不図示）を介して、アプリケーション実行エンジン１７０３に送信する。ｆ（ＣＥＣａ）で示されるように、カレントイベントコンテキストの一部をアプリケーション実行エンジン１７０３に送信する必要はない。
【０２２３】
ステップ１７０６で、アプリケーション実行エンジン１７０３は、受信したイベントコンテキストｆ（ＣＥＣａ）を、呼出対象のサービスアプリケーション１７０７に適しているデータフォーマットに変換する。これは、サービスアプリケーションの呼出用の適切な名前空間への変換も含んでいても良い。また、ステップ１７０８で、アプリケーション実行エンジン１７０３は、特権及び権利をチェックする。サービスアプリケーション１７０７に関連するアクセス制御リストＡＣＬ３は、ｆ（ＣＥＣａ）の値あるいはその一部にアクセスするために、サービスアプリケーション１７０７の特権を特定することができる。また、ルールモジュールは、別のアクセス制御リストＡＣＬ４に依存するサービスアプリケーション１７０７にアクセスしており、これは、サービスアプリケーション１７０７に関連している。アクセスが行われる場合、ステップ１７０９で、サービスアプリケーション１７０７が呼び出され、かつイベントコンテキストｇ（ＥＣａ）の関連部分が入力として提供される。続いて、サービスアプリケーション１７０７は、命令セット１７１０あるいは命令セットの中間表現を送信することによって、アプリケーション実行エンジン１７０３を介して制御をルールエンジン１７０２に戻す。ステップ１７１１で、これらの命令を発行するサービスアプリケーション１７０７の特権及び権利が、例えば、サービスアプリケーション１７０７に関連するアクセス制御リストＡＣＬ５に基づいて、チェックされる。サービスアプリケーション１７０７が、これらの命令を発行する特権を有している場合、命令は中間表現から変換され（ステップ１７１２）、変換された命令１７１３は、ルールエンジンへ渡される。また、任意のアーミングリクエスト１７１６が同様に渡される。ステップ１７１４で、取り得るフィーチャ相互作用問題が、既に認証され、かつ呼び出されているサービスアプリケーションから発行されたより早い命令で解決される。この解決は、既に呼び出されているアプリケーションがカレントイベントコンテキストで保護されているメッセージプロパティを有しているかに基づいている。次のカレントイベントコンテキストＣＥＣｂが生成され、ルールモジュールプロセッサ１６０１に返される。そして、ステップ１７１５で、ルールエンジンは、呼び出されているサービスについての情報を、例えば、図１４で説明しているリクエストツリーを構築することによって、メモリに記憶する。リクエストツリーは、将来のイベントの通知とともに使用される。
【０２２４】
上述したように、いくつかのサービス、例えば、モニタリングアプリケーションは、将来のイベントで関係する。将来のイベントのこの関係についてをルールエンジンを通知するために、サービスアプリケーションは、イベント通知に対するリクエストを行う必要があり、かつこれは、イベント通知用の動的アーミングと呼ばれる。
【０２２５】
本発明の実施形態に従えば、トランザクションイベントの動的アーミングは、ＳＩＰトランザクションの処理に結び付けられ、これは、やがてバインドされる。トランザクションは、通常、ＳＩＰサーバの構成に依存して、ミリ秒から数分の間、継続することができる。トランザクションイベントの動的アーミングは、トランザクションの存続時間のみに適用するので、このタイプのアーミングは非永久的で、かつトランザクションが終了する場合に明示的に解除される（disarmed）、これによって、高速メカニズムを提供する。アプリケーションが、そのアプリケーションで起動されるトランザクションに関係するイベントをアームする場合、アプリケーションは、カスケード化サービスモデルでその位置を維持する。応答は、それらをアームしている、ツリーのリーフから始まるアプリケーション全て、即ち、ほとんどのダウンストリームアプリケーションに対して通知される。トランザクションの存続期間中には、リクエストツリーが、ルールエンジンのメモリに存在している。同一のトランザクションに関連する次のイベントは、リクエストツリーに関連している。リクエストツリーに関連するイベントは、アプリケーション、ダウンストリームサーバ及びアップストリームクライアントから発生し得る。
【０２２６】
アップストリームからのイベントは、リクエストツリーのルートに入力する。これは、それらが、リクエストツリーのルーでアプリケーションに最初に通知されることを意味する。オリジナルツリーで更に送信されないが、新規のリクエストツリーが構築される場合、このアプリケーションはイベントを終了するあるいはリダイレクトすることができる。リクエストは、オリジナルリクエストとして同一の宛先すべてへ送信される必要もなく、あるいはリクエストは、オリジナルリクエストが送信される宛先の１つへ送信される必要がある。アプリケーションからのイベントは、リクエストツリーの適切なノードに入力する。ダウンストリームサーバからのイベントは、リクエストツリーのリーフの１つに入力する。
【０２２７】
ルールエンジンが、呼び出されるアプリケーションの順序、即ち、リクエストツリーの順序を記憶している場合に、これは、リクエストツリーの走査（travesal）メカニズムを導く。トランザクションのコンテキスト内でイベントが通知される順序に対する明確なルールを提供することが、本実施形態の利点である。この明確なルールは、カスケード化サービスモデルであり、これは、管理者及びアプリケーション設計者によって容易に理解することができる概念的で単純なルールである。これは、アプリケーション実行エンジンがルールをルールベースに追加することによって、ＡＰＩを簡略化する。ルールモジュールの特定ブランチのＣＡＮＣＥＬ（キャンセル）をアームしなければならないというよりも、与えられている発信の区切り（call leg）のキャンセルを簡単にアームすることができる。
【０２２８】
リクエストツリー走査をじするための様々な方法が存在する。
【０２２９】
例えば、ルールエンジンは、ＶＩＡヘッダ及びブランチパラメータを使用することによって、この走査を達成することができる。実際には、これは、リクエストをＳＩＰサーバへ送信することによって宛先アドレスが変更される毎に、ルールエンジンの異なるインスタンスを生成することを意味する。ＳＩＰスタックによって実行されるＤＮＳルックアップは、秒単位で、サーバによる処理対象のリクエストが返信されるかどうかを判定する。リクエストがＳＩＰサーバから受信されると、それは新規のリクエストとして取り扱われる。ルールエンジンは、そのサービスを保証するメカニズムを持つべきであり、例えば、ＦＲＯＭフィールド上で起動されるサービスが誤って再度呼び出されることはない。
【０２３０】
選択的には、本実施形態では、イベントは、リクエストツリー全体、即ち、リクエストツリーのすべてのリーフがネットワーク内のあらゆる宛先を表現するまでのあらゆる送信（forwardings）を含むリクエストツリーに対するホストで取り扱われる。本実施形態は、シグナリング状態装置及びマネージャクラスのいくつかのインスタンスが必要とされる場合により有効となる利点を有している。例えば、アプリケーションの各トリガーに対して、リクエストツリーの直前及び次のノードへのポインタを持つことができるノードオブジェクトの命令を持つことによって、リクエストツリーが実現されても良い。以下の擬似コードフラグメントは、リクエストツリーの構築がどのようにしてルールベース処理及びルールモジュール処理に対するアルゴリズムに組み込まれるかを示している。この概念は、ＲｅｑｕｅｓｔＴｒｅｅＮｏｄｅを有する各イベントコンテキストに関連していることを示している。これは、イベントコンテキストが生成されている場所でのＲｅｑｕｅｓｔＴｒｅｅＮｏｄｅである。各ノードは、リクエストツリーのルートである、あるいはアクション実行に関連している。
2004532472.tif 000009
サービスアプリケーションの論理的カスケーディングのモデルについて検討すると、以下の２つの一般的なルールが、以下のサービス実行環境に対して一般化することができる。
【０２３１】
−アップストリーム走査イベントは、多くの論理的なダウンストリームアプリケーションに対してまず通知されるべきである。
【０２３２】
−ダウンストリーム走査イベントは、多くの論理的なアップストリームアプリケーションに対してまず通知されるべきである。
【０２３３】
より複雑で管理不能な状況を防止するための配信イベント通知が、任意の順序でカスケード化サービスに通知できる場合に、サービスの論理的なカスケード化順序が維持される。
【０２３４】
好ましくは、このようなイベントをアームするアプリケーションが、処理ポイント１あるいは４及びそれらのサブ処理ポイントで呼び出される。好ましくは、ネットワークオペレータは、処理ポイント４に対するルールリストで、動的なアーム化トリガーが通知されるべきポイントを特定することができる。これは、リクエストに対して確立されるサービスの論理的なカスケード化チェーンが維持され、かつ新規のサービスがこのチェーンの前あるいは後に起動されることを意味する。同一ルールを、既存のトランザクションに関連する次のリクエストに対して適用できる。この時点では、処理ポイント１に存在し、管理者は、いつ動的なアーム化イベントを通知するかを特定することができる。
【０２３５】
選択的にあるいは補助的に、別のタイプのアーミングを適用することができ、これは、動的アーム化トリガーと呼ばれ、ルールとして、ルールベースの適切なルールモジュールに追加される。動的アーム化トリガーは、アプリケーションが起動されている場合のトランザクションに関係しないイベントの通知に対する処理能力及び実行メモリに関して、より安価なメカニズムを提供する。好ましくは、イベント通知に対するこれらのリクエストは、永久記憶に記憶されるべきである、即ち、これらは、ルールベースのルールとなる。これらのルールは期限タイマーを指定することによって反永久とすることができる、あるいは永久とすることができる。後者の場合、サービスアプリケーションは、それを消去するためのイベント通知用のリクエストを明示的に解除するべきである。選択的には、これらは、「１回の通知後の解除（report-once then disarm）」モードでアームされても良い。また、期限時間が与えられていない場合、デフォルト時間、例えば、１時間をそのルールに適用することができる。この時間が経過すると、そのルールは消去される。これは、サーバがデータ記憶容量を消費してしまうことを回避する利点がある。
【０２３６】
好ましくは、トリガールールは、更新する特権及び権利を有するアプリケーションのルールモジュールに追加される。これは、通常、アプリケーションが起動されるルールモジュールと同一となる。もちろん、ルールモジュール内の優先度順序において、これらのルールがどこで追加されるべきかは、絶対的なルール優先度順序、即ち、既存ルールモジュール内でルールがどこに配置されるべきかを表す整数によって判定することができる。ＳＥＲＬスクリプトが最初に追加される場合、ルールは、そのルールがスクリプト内で現れる順序で順序付けされる。Ｎ個のルールが存在する場合、１からＮの整数が、これらのルールに絶対的に関連付けられている。ルールは、これらの番号を参照することによって削除することができる。ルールは、新規のルールをその後ろに配置すべきルールを参照することによって追加することができる。これは、ルールが大きなルールモジュールに追加される場合に交換するために必要なデータ量が削減されるという利点を有している。
【０２３７】
位置が特定されない場合、ルールモジュールエンジンは、以下のトリガーを追加する場合に以下のアルゴリズムに従う：新規ルールとして同一プロパティパターンに対するルールモジュールを検索する。パターンが検出される場合、任意のサブパターンに対する検索を続行する。サブパターンが検出されない場合、最上位優先度ルールとしてルールをアクションのリストに挿入する。同様のパターンがルールモジュールに既に存在しない場合、第１パターンとして挿入する。このアルゴリズムは、ルールに対する論理的に有利な配置を提供する。例えば、ＴＡＲＧＥＴ＝ＦＲＯＭである発信側に対するアクションが、ＴＡＲＧＥＴ＝ＲｅｑｕｅｓｔＵＲＩである着信側に対するアクションと混合しないことを保証する。また、これは、最後に追加されたルールが、イベントが発生する場合に最初に遭遇することも意味する。これは、最も簡単なデフォルト行動である。
【０２３８】
トリガールールが永久であるか、あるいはイベントが一旦通知されると自動的に消去されるべきであるかを示すことができる。どのタイプのルールをアプリケーションが動的に追加できるかは、アプリケーションに割り当てられている特権及び権利に関係付けることができる。
【０２３９】
別の実施形態では、カスケード化リクエストツリーは、イベントの存続期間に対してのみ維持される。この場合、そのチェーンの最新アプリケーションは、その処理を完了しており、ＳＩＰイベントが送信されて、カスケード化チェーンはこれ以上関係しない。その時点までに、ルールエンジンに対して、メモリ内のカスケード化チェーンの表現を保持することが有益である。これは、アプリケーションが別々のサーバ上で動作し、かつ呼出に対して応答するためのある程度の時間を必要とするからである。ルールエンジンが応答に対して待機している一方で、チェーン内のより早いアプリケーションは、リクエストをキャンセルすることができる。これが発生する場合、ルールエンジンは、アプリケーションのアプリケーション実行エンジンに待機中であることを通知する必要がある。これは、ルールエンジンがチェーン内でどれが次のアプリケーションであるかを覚えているべきであることを意味する。ＳＩＰイベントが送信されている時間に、チェーン内のすべてのアプリケーションは、注目しているイベントに対するルールをアームしているべきである、即ち、カスケード化チェーンを記憶するためのルールエンジンはこれ以上必要ない。この解決策の利点は、ルールエンジン自身が単純になることである。これは、関連処理ポイントでルールモジュールに基づくイベントを通知する。しかしながら、この解決策は、イベントの複雑な順序付けを管理し、かつアプリケーションに配置するために複雑となる、即ち、アプリケーションは、どの優先度位置で、ルールがルールモジュールに追加されるべきかを決定する必要がある。
【０２４０】
図１８は、本発明の実施形態に従うルールモジュールの処理のツリー構造を示している。イベントが受信されると、ルールベース処理は、ルールベースツリーとして参照される処理パターンを展開する。リクエストがオリジナルイベントコンテキスト１８０１に対応するＳＩＰサーバに到達すると、関連する加入者は、発信パーティ（即ち、発信側）及び着信パーティ（即ち、着信側）の少なくとも一方であり得る。発信側は、Ｆｒｏｍヘッダフィールドによって識別される。着信側（あるいは現在の着信側）は、Ｒｅｑｕｅｓｔ−ＵＲＩによって識別される。Ｆｒｏｍヘッダフィールド及びＲｅｑｕｅｓｔ−ＵＲＩは、ＳＩＰサーバで加入者を固有に識別すべきであり、このＳＩＰサーバでは、これらの加入者は、ネットワークオペレータ及びサービスプロバイダと契約関係を持っている。以下のカスケーディング原理では、発信及び着信パーティが同一ホストに配置されているとしても、発信サービス１８０２は、着信サービス１８０３の前に呼び出される。第３カテゴリのサービスも呼び出すことができる。これらは、着信転送（forwaded-by）サービスと呼ばれる。別の加入者に属する新規の宛先にリクエストが送信される場合に、このカテゴリのサービスが呼び出される。この場合、発信サービスは、着信側のために呼び出される必要がある。各パーティに対しては、サービスは、異なる処理ポイント１８０４〜１８０９で配置されるルールモジュールの位置に基づいて呼び出される。各処理ポイントに対しては、ルールモジュール優先度１８１０〜１８１４のセットは、照合のために検査される。各優先度内において、ルールモジュール１８１５〜１８１７の多くとも１つが呼び出される。しかしながら、ルールモジュール１８１７は、図１２で説明されるように、ルールモジュール階層１８１８のルートとなり得る。簡単のために、このようなルールモジュール階層は、単一のルールモジュールであると想定する。ここで、ルールモジュールによって呼び出される、ルールモジュール処理１６０１の機能、サービス相互作用モジュールの機能１７００及びサービスアプリケーション１８１９は、ルールベースツリーのリーフとして想定することができる。カレントイベントコンテキストＣＥＣに基づいて、ルールモジュール１８１７が呼び出され、それは、得られるイベントコンテキストＲＥＣを返信する。この得られるイベントコンテキストＲＥＣが、呼び出される次のルールモジュールに対するカレントイベントコンテキストＣＥＣとして考慮される。すべてのルールモジュールが呼び出され、かつそれらの最後が、得られるイベントコンテキストを返信すると、その得られるイベントコンテキストは、オリジナル着信ＳＩＰメッセージへの回答として、アップストリーム及びダウンストリームの少なくとも一方に送信されるＳＩＰシグナリングメッセージのセットとなる。
【０２４１】
図１８で図示される上述の処理構造は、以下の擬似コードフラグメントによって更に示すことができる。
2004532472.tif 000010
2004532472.tif 000011
2004532472.tif 000012
サービスアプリケーションは、ＦｒｏｍヘッダフィールドあるいはＲｅｑｕｅｓｔ−ＵＲＩを変更することができることに注意されたい。また、得られるＦｒｏｍヘッダフィールドあるいは得られるＲｅｑｕｅｓｔ−ＵＲＩは、イベントを処理するＳＩＰサーバに対してさえ未知である別の加入者に属することができる。得られるＦｒｏｍ及びＲｅｑｕｅｓｔ−ＵＲＩの少なくとも一方は、ＳＩＰサーバで加入者に知られていない新規なものであり、この加入者に関連するサービスが同様に呼び出される。この場合、ルールベース処理プロシージャは、階層構造のルールベースツリーを再帰的に呼び出すことになる。
【０２４２】
ルールモジュールの処理は、優先度順序で各アクションを行い、閉じられているパターンがカレントイベントコンテキストと照合するかどうかを評価し、照合する場合にアクションを適用する工程を有する。以下では、本発明の実施形態に従う方法を詳細に説明する。
【０２４３】
以下の擬似コードフラグメントは、ルールモジュールを処理するアルゴリズムの高レベル記述を提供する。
2004532472.tif 000013
ここで、enclosingPatternsTrue方法は、アクションを閉じるパターンがトゥルー（真）であるかを示すブーリアン（boolean）である。processAction方法は、以下の擬似コードセグメントで示されるようにして実現することができる：
2004532472.tif 000014
ここで、ＥＣ［］は、以下のイベントコンテキストのセットである。これが空である場合、サービスは、リクエストあるいは応答を終了する。
【０２４４】
サービスアプリケーションは、更に、イベントコンテキストを送信するための命令ではない命令を更に発行することができる。ここでは、上述のアルゴリズムには示されていない。このような命令は、ルールベースマネージャによって処理することができる。
【０２４５】
優先度順序でアクションを実行する場合、アクションの結果は、カレントイベントコンテキストを変更することができる。このようなアクションの後、カレントルールモジュールの処理は継続する。カレントルールモジュールの実行後、更なるルールモジュールが、ルールベース処理プロシージャに従って実行されても良い。カレントイベントコンテキストによって特定されるように、そのアクションを閉じるパターン（群）が新規メッセージプロパティと照合する場合、より下位の優先度順序のアクションのみが実行される。これは、２つのパターンに含まれる２つのアクションを記述する以下のフラグメントの擬似スクリプト例によって示される。
2004532472.tif 000015
２つのアクションは、２つのパターンに含められ、このパターンは、リクエストがＩＮＶＩＴＥであり、かつＲｅｑｕｅｓｔＵＲＩがドメイン名ｘｃｏｒｐ．ｃｏｍを含んでいる場合に、アクションのみが適用されるべきであることを示している。第１のアクションは、ユーザ供給ＣＰＬスクリプトを呼び出す。ユーザＣＰＬスクリプトがリクエストの宛先を変更しない場合、標準化プロキシ行動が呼び出されて、ユーザを配置し、リクエストのプロキシを行う。宛先を別のホストへ決定することによってＣＰＬスクリプトが宛先を変更する場合、標準化プロキシ行動は呼び出される必要はない。
【０２４６】
新規ユーザを表現することによって、ルールモジュールを起動したメッセージプロパティが変更される場合、そのルールモジュールの処理が停止される。これの目的は、ルールモジュールが単一のユーザで処理されるものとして想定できることである。これは、ルールモジュール処理及びスクリプトオーサリングを簡略化する。
【０２４７】
図１９は本発明の実施形態に従ってサービスアプリケーションが新規イベントコンテキストを生成する状況でのルールモジュールの再帰処理を示している。新規イベントコンテキストは、オリジナルルールモジュールトリガーを変更することができ、この場合、新規ルールモジュールは再帰的に呼び出すことができる。例えば、加入者の着信側プリファレンス、例えば、ＣＰＬスクリプトは、同一ＳＩＰサーバの別の加入者に関連する新規の宛先へリクエストを送信することができる。この場合、送信側の加入者の着信側プリファレンス、例えば、別のＣＰＬスクリプトが同様に呼び出されるべきである。
【０２４８】
図１９の例で示されるように、ＳＩＰリクエストメッセージが他の加入者アカウントに関連する複数の新規の宛先へ送信される場合に、初期イベントコンテキスト１９０１は、再帰ルールモジュール呼出を生成する。図１９の例では、アプリケーション１９１４は、加入者Ａでのルールモジュール１９０３によって起動される。ルールモジュール１９０３は、オリジナルイベントコンテキスト１９０１によって起動される。アプリケーション１９１４は、３つのイベントコンテキスト１９０４〜１９０６を生成する、ここでは、ルールモジュールトリガーが、新規の加入者アカウントに関連する２つのイベントコンテキスト１９０５〜１９０６で変更される。イベントコンテキスト１９０４は、更新されたイベントコンテキストであるが、アプリケーション１９１４で最初に呼び出されたルールモジュールを有する同一の加入者には関連していない。この場合、新規のイベントコンテキスト１９０５〜１９０６に関連する加入者のルールモジュール１９０７〜１９０８もそれぞれ呼び出される。一方、ルールモジュール１９０７は、２つの新規のイベントコンテキスト１９０９及び１９１０を生成するアプリケーション１９１５を呼び出し、以下、同様に行う。その結果、リーフが、得られるイベントコンテキスト１９１０〜１９１３のセットに対応する場合に、ツリー処理構造が生成される。続いて、得られるイベントコンテキスト１９１０〜１９１３が、ＳＩＰメッセージをアップストリームあるいはダウンストリームあるいはその両方に送信するためにＳＩＰサーバを起動する。これは、図１９の例が、ルールモジュールがそれぞれ１つのアクションのみを含んでいると想定する簡単な例を示していることに注意されたい。
【０２４９】
図１９の５つのアプリケーション１９１４〜１９１８が、得られるＳＩＰメッセージに対する次のリプライを通知することを要求する場合、カスケーディング原理に従えば、応答は、ほとんどの論理的なダウンストリームアプリケーションに最初に通知される。図１９では、得られるイベントコンテキスト１９１０に対する応答は、線分１９１９で示されるように、まず、アプリケーション１９１８に通知され、次に、アプリケーション１９１５、そして、アプリケーション１９１４へ通知される。得られるイベントコンテキスト１９１１に対して、対応するシーケンスは、線分１９２０で示されるように、アプリケーション１９１５及びアプリケーション１９１４である。得られるイベントコンテキスト１９１２に対して、シーケンスは、線分１９２１で示されるように、アプリケーション１９１６及びアプリケーション１９１４である。そして、得られるイベントコンテキスト１９１３に対して、シーケンスはアプリケーション１９１７及びアプリケーション１９１４である。
【０２５０】
図２０は、本発明の実施形態に従うルールモジュールに関連するアクセス制御を実行するメカニズムを示している。２つのタイプのアクセス制御が実行される。ルールモジュールへのアクセスは、証明及び認証されたパーティに対してのみ認められるべきであり、かつサービスフィーチャへのアクセスは、証明及び認証されたルールモジュールに対してのみ認められるべきである。本実施形態に従えば、このアクセス制御は、いわゆるアクセス制御リスト（ＡＣＬ）を使用することによって実現することができる。このようなリストは、ルールモジュールに埋め込むことができるあるいは同一ディレクトリに配置することができる、そうでなければルールモジュールに関連するＸＭＬ文書であっても良い。アクセス制御リストは、アクセス制御ルールを含んでいる。アクセス制御リストは、ルールモジュールへのアクセスが認められている個人あるいはグループのそれぞれを計数することができる。このメカニズムは、ルールモジュールの特権及び権利、例えば、どのサービスフィーチャをルールモジュールが使用しているかを明示的に特定するためにも使用することができる。それゆえ、このメカニズムは、管理者に、ルールモジュールの特権及び権利を管理させることができる。
【０２５１】
また、このメカニズムは、サービスアプリケーションの特権及び権利を管理するために使用することができる。加入者がＣＰＬスクリプトをアップロードする場合、正しい時間でサービスを呼び出す関連ルールモジュールが存在しても良い。この場合、ルールモジュールは、明示的な特権及び権利を持ち続けるべきである。これは、ＣＰＬスクリプトとアクセス制御リストを関連付けることによって管理することができる。このメカニズムは、更に、サービスアプリケーションの特権及び権利、例えば、どのサービスフィーチャ、ＡＰＩ等の、どのサービスアプリケーションを使用できるかを明示的に特定するために使用することができる。ここで、このメカニズムは、管理者に、サービスアプリケーションの特権及び権利を管理させることができる。
【０２５２】
図２０の丸数字を参照して、以下の特権をチェックすることができる。
【０２５３】
１）オリジナルイベントコンテキスト２００１は、適切な加入者（Ａが発信側、Ｂが着信側）の証明後に、ルールエンジンに送信される。ルールモジュール及びサービスアプリケーションは、すべて証明されており、与えられている特権及び権利を有している。
【０２５４】
２）ルールベースプロセッサ２００２は、証明されている加入者ＡあるいはＢあるいはそれらの両方に関連するルールベース２００３のルールモジュールへのアクセスを試行する。ルールベースプロセッサ２００２は、このイベントを処理する場合の他の加入者に関連するルールモジュールへアクセスすることは許可されるべきでない。ルールベース２００３は、ルールエンジンが自身を証明すべきである場合には、リモートサーバに配置されても良い。
【０２５５】
３）アクセス制御リスト２００５に従うことが可能である場合、ルールベースプロセッサ２００２は、ロードされているルールモジュール２００４、いわゆる、Ａに所有されるルールモジュール１を呼び出すことができる。
【０２５６】
４）アクセス制御リスト２００６に従うことが可能である場合、ルールモジュール２００４は、別の所有者Ｂに関連する別のルールモジュール２００７を呼び出すことを試行することができる。
【０２５７】
５）アクセス制御リスト２００８に従うことが可能である場合、ルールベースプロセッサ２００２は、ロードされているルールモジュール２００７を呼び出すことができる。
【０２５８】
６）アクセス制御リスト２００５及び２０１２に従うことが可能である場合、ルールモジュール２００４は、可能であれば、サービスアプリケーション２０１０を呼び出すことを試行することができる。サービスアプリケーション２０１０は、アクセス制御リスト２０１１に従って、イベントコンテキスト２０１３にアクセスすることができる。
【０２５９】
７）サービスアプリケーション２０１０は、アクセス制御リスト２０１５に従うことが可能である場合、ルールモジュールプロセッサへ取り次がれる命令２０１４のセットを返信することができる。
【０２６０】
８）サービスアプリケーション２０１０は、アクセス制御リスト２０１５に従うことが可能である場合、イベントに対してアームする／アームしないことができる。
【０２６１】
９）サービスアプリケーション２０１０は、アクセス制御リスト２０１２に従うことが可能である場合、呼び出されているルールモジュール以外の別のルールモジュール２００７に命令を与えることを試行することができる。
【０２６２】
ルールモジュールへのアクセス制御は、ルールモジュールのポリシーノードによって実行することができる。ルールモジュールに埋め込まれているルールモジュールアクセス制御リストの例は、以下のように参照される：
2004532472.tif 000016
このポリシーは、加入者アリスがルールモジュールを呼び出すことができるが、それを読み出したりあるいは書き込むことができない場合に、そのルールモジュール全体に適用することができる。
【０２６３】
このようなポリシーのＸＭＬスクリプトは、ルールモジュール内に埋め込むことができるばかりか、これらは、データ要素に関連づけることもできる。例えば、ネットワークオペレータは、ポリシーのＸＭＬスクリプトを加入者のルールモジュールに関係づけることができ、ルールモジュールの所有者に対するネットワークオペレータによって認められている特権を特定する。これらの特権はサービスあるいはサービスのフィーチャを特定することができ、以下のサービスアクセス制御リストの例で示されるように、ルールモジュールを呼び出すことができる：
2004532472.tif 000017
ＳＩＰサーバサービスサポート環境は、更に、例えば、コンテンツ課金、アプリケーション課金、利用課金あるいはその類に対するアカウントレコードを生成するように構成することができることに注意されたい。例えば、このレコードは、ＳＥＲＬスクリプトあるいはＣＰＬスクリプトからのログを介して提供され、ライブラリ機能あるいはサービスアプリケーション等を介して管理される。
【０２６４】
また、加入者及びサードパーティサービスプロバイダがサービスアプリケーションをアップロードするばかりか、フィーチャ相互作用分析の度合を含むサービスアプリケーションを、どのようにして、かついつ呼び出すかについての命令をアップロードすることが可能であるとしても、本発明に従うサービストリガリング実行システムは、ＳＩＰノードの安全性及び完全性を確保するためのセキュリティ測定を実行することが好ましい。可能なセキュリティ測定は、ルールモジュール、サービスアプリケーション、名前空間取り決めポリシー、証明メカニズム、認証メカニズム、アクセス保護、アップロードされているルールモジュールの証明及び有効化、ロギング及びモニタリング等の特権及び権利の構成を含んでいる。
【０２６５】
本発明は、主として、ネットワークサービスに関して説明されていることに注意されたい。しかしながら、これは、エンドユーザ装置で使用することにも適用可能である。
【０２６６】
また、主として、ＳＩＰに関連して説明される本発明は、他のシグナリングプロトコルにも、同様に、利用できることに注意されたい。ＳＥＲＬは、ＳＩＰイベントに基づいてサービスを呼び出すことに制限されないばかりか、ビジネスモデルの任意のタイプのコンテキストで、任意のタイプのイベントに基づいて任意のタイプのサービスアプリケーションを呼び出すことができる。本発明は、ＳＩＰが可能なノードに対するサービスを管理するために適用することができる。ＳＥＲＬスクリプトを使用することで、サービスを、ユーザエージェント、レジスタ、リダイレクトサーバあるいはプロキシサーバを実現するノードから呼び出すことができる。
【０２６７】
そして、３ＧＰＰアーキテクチャにおいて、すべての加入者データが、いわゆるホーム加入者サーバ（ＨＳＳ）で管理されることに注意されたい。アプリケーションに関連するＳＩＰは、サービング発信状態制御機能（Ｓ−ＣＳＣＦ）と呼ばれるノードから呼び出される。加入者がネットワークに接続する場合、自身のユーザ端末（ＵＥ）は、適切なＳ−ＣＳＣＦを選択するためのＣＳＣＦディスカバリーを実行する。Ｓ−ＣＳＣＦは、対象の加入者へサービスを提供することをＨＳＳに登録する。サービストリガーは、ＳＥＲＬフォーマットのサービス実行ルールの形式で、ＨＳＳからＳ−ＣＳＣＦへ送信することができる。ＨＳＳは、Ｓ−ＣＳＣＦが正常にインストールされているサービスを有していることに基づいて、異なるＳ−ＣＳＣＦを割り当てることを決定するために、加入者に関連するサービス実行ルールを使用することもできる。ここで、本発明の実施形態は、正常な処理ポイント及び優先度でのトリガーに基づいて加入者を配置するためのＨＳＳに対する順序で使用することができる、つまり、Ｓ−ＣＳＣＦでインストールされている固定サービスの正常な優先度順序で使用することができる。ここで、本発明に従うメカニズムは、３ＧＰＰ  ＩＰＭＭドメインに埋め込むことができる。
【図面の簡単な説明】
【０２６８】
【図１】ＳＩＰサービスネットワークの様々なタイプのフィーチャ相互作用を示す図である。
【図２】本発明の実施形態に従うサービス環境ＳＩＰサーバアーキテクチャに含まれるネットワーク要素を示す図である。
【図３】本発明の実施形態に従うサービス実行ルールメカニズムをサポートするＳＩＰサーバのシステムアーキテクチャを示す図である。
【図４】本発明の実施形態に従うルールモジュールの構造を示す図である。
【図５】本発明の実施形態に従う、制約のあるサービスのセットへのサービスのグルーピングを示す図である。
【図６】本発明の実施形態に従う再帰ＳＩＰメッセージフローの位置に制約のあるサービスのセットへのサービスのグループ化を示す図である。
【図７】本発明の実施形態に従う様々な処理ポイントに属するサービス間の処理フローを示す図である。
【図８】本発明の実施形態に従う管理権限に対応するルールモジュールへのサービスのグループピングを示す図である。
【図９】処理ポイントと管理権限の両方に従ってサービスがグループ化される本発明の実施形態を示す図である。
【図１０】複数のルールモジュールと複数の処理ポイントの場合の図９の実施形態の処理メカニズムを示す図である。
【図１１】図９に関連して説明される処理ルールの別の例を示す図である。
【図１２】本発明の実施形態に従う階層ルールモジュール処理を示す図である。
【図１３】本発明の実施形態に従うＳＩＰメッセージイベントコンテキスト及び命令セットのフローの例を示す図である。
【図１４】本発明の実施形態に従う複数の命令セットを管理するメカニズムを示す図である。
【図１５】本発明の実施形態に従うサービスアプリケーションのカスケード化チェーンのツリーを示す図である。
【図１６】本発明の実施形態に従うサービスサポート環境のソフトウェアコンポーネントを示す図である。
【図１７】図１６の実施形態のルールモジュールの処理とサービスアプリケーションの処理間でサービス相互作用モジュールによって実行される工程を示す図である。
【図１８】本発明の実施形態に従うルールモジュールの処理のツリー構造を示す図である。
【図１９】本発明の実施形態に従ってサービスアプリケーションが新規のイベントコンテキストを生成する状況でのルールモジュールの再帰処理を示す図である。
【図２０】本発明の実施形態に従うルールモジュールに関係してアクセス制御を実行するメカニズムを示す図である。
【図１】
2004532472.tif 000018
【図２】
2004532472.tif 000019
【図３】
2004532472.tif 000020
【図４】
2004532472.tif 000021
【図５】
2004532472.tif 000022
【図６】
2004532472.tif 000023
【図７】
2004532472.tif 000024
【図８】
2004532472.tif 000025
【図９】
2004532472.tif 000026
【図１０】
2004532472.tif 000027
【図１１】
2004532472.tif 000028
【図１２】
2004532472.tif 000029
【図１３】
2004532472.tif 000030
【図１４】
2004532472.tif 000031
【図１５】
2004532472.tif 000032
【図１６】
2004532472.tif 000033
【図１７】
2004532472.tif 000034
【図１８】
2004532472.tif 000035
【図１９】
2004532472.tif 000036
【図２０】
2004532472.tif 000037
【国際公開パンフレット】
2004532472.tif 000038
2004532472.tif 000039
2004532472.tif 000040
2004532472.tif 000041
2004532472.tif 000042
2004532472.tif 000043
2004532472.tif 000044
2004532472.tif 000045
2004532472.tif 000046
2004532472.tif 000047
2004532472.tif 000048
2004532472.tif 000049
2004532472.tif 000050
2004532472.tif 000051
2004532472.tif 000052
2004532472.tif 000053
2004532472.tif 000054
2004532472.tif 000055
2004532472.tif 000056
2004532472.tif 000057
2004532472.tif 000058
2004532472.tif 000059
2004532472.tif 000060
2004532472.tif 000061
2004532472.tif 000062
2004532472.tif 000063
2004532472.tif 000064
2004532472.tif 000065
2004532472.tif 000066
2004532472.tif 000067
2004532472.tif 000068
2004532472.tif 000069
2004532472.tif 000070
2004532472.tif 000071
2004532472.tif 000072
2004532472.tif 000073
2004532472.tif 000074
2004532472.tif 000075
2004532472.tif 000076
2004532472.tif 000077
2004532472.tif 000078
2004532472.tif 000079
2004532472.tif 000080
2004532472.tif 000081
2004532472.tif 000082
2004532472.tif 000083
2004532472.tif 000084
2004532472.tif 000085
2004532472.tif 000086
2004532472.tif 000087
2004532472.tif 000088
2004532472.tif 000089
2004532472.tif 000090
2004532472.tif 000091
2004532472.tif 000092
2004532472.tif 000093
2004532472.tif 000094
2004532472.tif 000095
2004532472.tif 000096
2004532472.tif 000097
2004532472.tif 000098
2004532472.tif 000099
2004532472.tif 000100
2004532472.tif 000101
2004532472.tif 000102
2004532472.tif 000103
2004532472.tif 000104
2004532472.tif 000105
2004532472.tif 000106
2004532472.tif 000107
2004532472.tif 000108
2004532472.tif 000109
2004532472.tif 000110
2004532472.tif 000111
2004532472.tif 000112
2004532472.tif 000113
2004532472.tif 000114
2004532472.tif 000115
2004532472.tif 000116
2004532472.tif 000117
2004532472.tif 000118
2004532472.tif 000119
2004532472.tif 000120
2004532472.tif 000121
2004532472.tif 000122
2004532472.tif 000123
2004532472.tif 000124
2004532472.tif 000125
2004532472.tif 000126
2004532472.tif 000127
2004532472.tif 000128
2004532472.tif 000129
2004532472.tif 000130
2004532472.tif 000131
2004532472.tif 000132
2004532472.tif 000133
2004532472.tif 000134
2004532472.tif 000135
2004532472.tif 000136
2004532472.tif 000137
2004532472.tif 000138
2004532472.tif 000139
2004532472.tif 000140
2004532472.tif 000141
2004532472.tif 000142
2004532472.tif 000143
2004532472.tif 000144
2004532472.tif 000145
2004532472.tif 000146
2004532472.tif 000147
2004532472.tif 000148
2004532472.tif 000149
2004532472.tif 000150
2004532472.tif 000151
2004532472.tif 000152
2004532472.tif 000153
2004532472.tif 000154
【手続補正書】
【提出日】平成15年4月11日(2003.4.11)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通信セッションを制御するセッションプロトコルのメッセージ（１３０６、１６０９）によって起動される複数のサービス（３０９、３１０、３１１、１３０５、１６１１、１６１２、１６１３）を管理する方法であって、
−それぞれがいくつかの実行ルール（３０８、４０１、４０２、１６０６、１６０７、１６０８）を有するいくつかのルールモジュールを取得する工程と、各実行ルールは、サービスを呼び出すための状態（４０３、４０４、４０５）を特定し、
−前記いくつかのルールモジュールの内の第１ルールモジュール（１２１６）の処理を行う工程と、前記処理は、前記第１ルールモジュールの実行ルールの少なくとも一部として、前記メッセージが第１状態を満足する場合、呼出対象の第１サービス（１６１１）を生成して、第１変更メッセージ（１６１５）を出力する第１実行ルール（１６０６）と、前記第１変更メッセージが第２状態を満足する場合、第１変更メッセージを入力として、呼出対象の第２サービス（１６１２）を生成する第２実行ルール（１６０７）とを、所定の順序で処理し、前記第１ルールモジュールの前記処理は、第１累積変更メッセージ（１２０６）を出力し、
−前記第１累積変更メッセージを入力として提供する前記いくつかのルールモジュールの内の第２実行ルールモジュール（１２１７）を呼出処理を行う工程とを備え、
前記第１ルールモジュールには、前記累積変更メッセージの所定部分に関連するロックフラグを変更する権限を示す特権が割り当てられ、前記ロックフラグは、前記累積変更メッセージの前記所定部分が、少なくとも前記第２ルールモジュールから呼び出されるサービスによって変更されるかを特定する
こと特徴とする方法。
【請求項２】
各ルールモジュールは、前記いくつかのルールモジュールの処理順序を示す優先度と関連付けられている
ことを特徴とする請求項１に記載の方法。
【請求項３】
各ルールモジュールは、前記ルールモジュールを編集することが認証されたルールモジュール所有者（４０９）に対応する
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記第２ルールモジュールの呼出処理を行う工程は、更に、前記ロックフラグが第１ルールモジュールによって設定解除（unset）がマークされない限り、前記第２ルールモジュールから呼び出されるサービスによる前記累積変更メッセージの前記所定部分の変更を防止するために該ロックフラグを設定する工程を備える
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記いくつかの実行ルールを取得する工程は、更に、前記メッセージのヘッダ情報に基づいて所定の契約関係を検出し、前記検出された契約関係に基づいていくつかのルールモジュールを選択する工程を備える
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記第１ルールモジュール（１２１６）を処理する工程は、更に、所定の第３ルールモジュール（１２２０）を呼び出す工程を備える
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記第１及び第２ルールモジュールはそれぞれ、該第１あるいは第２ルールモジュールに対応するアクセス権を特定する第１及び第２アクセス制御リスト（４１１）に関連付けられている
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記第１及び第２ルールモジュールはそれぞれ、所定マークアップ言語の第１及び第２スクリプトからなる
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記メッセージは、第１及び第２の属性セットを有し、前記実行ルールは、対応する制約に従って、少なくとも第１及び第２処理クラス（９０３、９０４）の実行ルールにグループ化され、前記第２処理クラスは、前記第２の属性セットの属性を変更することだけに制約されており、前記方法は、前記第１ルールモジュール（９０１）を処理する工程と前記第２ルールモジュール（９０２）の呼出処理を行う工程を繰り返す工程を更に備え、ここで、各繰り返し処理において、前記第１及び第２ルールモジュールの処理は、対応する処理クラスのルールを実行することに制限され、ここで、各繰り返し処理は、次の繰り返し処理に対する入力として使用される対応する累積変更メッセージを出力する
ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
前記処理クラスは、前記セッションプロトコルのリクエスト（６０７）及び応答（６０８）によって起動される実行ルールに対して別々に定義される
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記第１の属性セットは、前記メッセージのシグナリングプロパティを有する
ことを特徴とする請求項９また１０に記載の方法。
【請求項１２】
前記処理クラスは、前記セッションプロトコルに従う再帰メッセージフローの所定位置に対応する
ことを特徴とする請求項９乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記処理クラスは、前記メッセージのシグナリングプロパティ（７０２）を与える第１処理クラス（Ｐ１）の実行ルール、前記メッセージの非シグナリングメッセージ本体コンテンツ（７０４）を与える第２処理クラス（Ｐ２）の実行ルールと、前記メッセージの前記シグナリングプロパティも前記非シグナリングメッセージ本体コンテンツも与えない第３処理クラス（Ｐ３）の実行ルールを含んでいる
ことを特徴とする請求項９乃至１２のいずれか１項に記載の方法。
【請求項１４】
前記第１及び第２処理クラスのすべての実行ルールが処理される場合に、変更メッセージ（７０３）が生成される
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
呼び出す前記第１サービスは、更に、第２変更メッセージを出力し、前記方法は、更に、前記第１変更メッセージを入力として次の実行ルールを処理する工程と、前記第２変更メッセージを入力として次の実行ルールを処理する工程とを備える
ことを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
前記方法は、更に、
どのサービスが実行されているかについての情報と、どの順序でサービスが実行されているかについての情報を記憶する工程と、
所定のイベントが発生している場合、前記第１サービスへ通知を返信するリクエストを前記第１サービスから受信する工程と、
前記記憶されている情報に関連する前記リクエストを記憶する工程と、
前記イベントの発生において、前記記憶されている情報に従って前記第１サービスへ通知する工程と
ことを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
【請求項１７】
前記実行モジュールは、コンピュータ可読スクリプトを有し、前記実行ルールの所定の処理順序は、前記スクリプト上の実行ルールの順序によって判定される
ことを特徴とする請求項１乃至１６のいずれか１項に記載の方法。
【請求項１８】
前記セッションは、発信側及び着信側を含むいくつかの加入者に関連し、サービスは、加入者からのリクエストによって起動されるように構成され、前記方法は、更に、前記着信側によって要求される任意のサービスを呼び出す前に、前記発信側によって要求されるサービスを呼び出す工程を備える
ことを特徴とする請求項１乃至１７のいずれか１項に記載の方法。
【請求項１９】
前記セッションプロトコルは、セッション初期化プロトコルである
ことを特徴とする請求項１乃至１８のいずれか１項に記載の方法。
【請求項２０】
前記通信セッションは、マルチメディアセッションである
ことを特徴とする請求項１乃至１９のいずれか１項に記載の方法。
【請求項２１】
前記実行ルールは、動的に更新されるように構成されている
ことを特徴とする請求項１乃至２０のいずれか１項に記載の方法。
【請求項２２】
通信セッションを制御するセッションプロトコルのメッセージによって起動される複数のサービス（３０９、３１０、３１１）を呼び出すように構成されているサービス実行環境モジュール（２０１、３０１）を有するデータ処理システムであって、前記データ処理システムは、更に、いくつかの実行ルールをそれぞれが有する複数のルールモジュールを記憶するように構成されている記憶媒体（３０７）を有し、各実行ルールは、サービスを呼び出す状態を特定し、
前記サービス実行環境モジュールは、
−いくつかのルールモジュールを検索し、
−前記ルールモジュールの第１ルールモジュールの処理を行い、前記処理は、前記第１ルールモジュールの実行ルールの少なくとも一部として、前記メッセージが第１状態を満足する場合、呼出対象の第１サービスを生成して、第１変更メッセージを出力する第１実行ルールと、前記第１変更メッセージが第２状態を満足する場合、第１変更メッセージを入力として、呼出対象の第２サービスを生成する第２実行ルールとを所定の順序で処理し、前記第１ルールモジュールの前記処理は、第１累積変更メッセージを出力し、
−前記第１累積変更メッセージを入力として提供する前記いくつかのルールモジュールの内の第２実行ルールモジュール（１２１７）を呼出処理を行う
ように構成されているルールエンジンモジュール（３０３）を有し、
前記第１ルールモジュールには、前記累積変更メッセージの所定部分に関連するロックフラグを変更する権限を示す特権が割り当てられ、前記ロックフラグは、前記累積変更メッセージの前記所定部分が、少なくとも前記第２ルールモジュールから呼び出されるサービスによって変更されるかを特定する
ことを特徴とするデータ処理システム。
【請求項２３】
前記ルールエンジンモジュールは、所定のルール実行特定言語を解釈するように構成されている
ことを特徴とする請求項２２に記載のサービス実行環境モジュール。
【請求項２４】
前記ルールエンジンモジュールは、更に、前記実行ルールを検索するように構成されているルールベースプロセッサモジュール（１６０１）と、前記実行ルールを処理するように構成されているルールモジュール処理モジュール（３１４、１６０４、１６０５）を有する
ことを特徴とする請求項２２または２３に記載のサービス実行環境モジュール。
【請求項２５】
データ処理システム上で実行される場合、請求項１乃至２１のいずれか１項に記載の方法の各工程を実行するように構成されているコード手段を有するソフトウェアプログラム。
【請求項２６】
前記ソフトウェアプログラムは、コンピュータ可読媒体に埋め込まれている
ことを特徴とする請求項２５に記載のソフトウェアプログラム
【請求項２７】
請求項１乃至２１のいずれか１項に記載の方法を使用するルールモジュールを有するデータレコード。
【国際調査報告】
2004532472.tif 000155
2004532472.tif 000156
2004532472.tif 000157