JP5495265B2 - 競合制御システム、サーバ及び競合制御プログラム - Google Patents

Description

本発明は、競合制御システム、サーバ及び競合制御プログラムに関し、例えば、ＩＭＳ（IP Multimedia Subsystem）に規定されているｉＦＣ（Initial Filter Criteria）を拡張して、複数のＡＳ（Application Server）に対して動作制御を行う競合制御システム、サーバ及び競合制御プログラムに適用し得るものである。

近年、例えばインターネットと携帯電話ネットワークとを融合させてユビキタスな無線アクセスを許容し、品質の高いマルチメディアサービスを提供する新しいネットワークが提案されている。この新しいネットワークを実現する技術は、例えばＩＭＳ標準化技術として規定されている。

ＩＭＳ標準では、ユーザを収容／制御するＳ−ＣＳＣＦ（Serving−Call／Session Control Function）と、アプリケーションサービスを提供するＡＳと、複数のＡＳに対してコントロールするＳＣＩＭ（Service Capability Interaction Manager）によって呼処理サービスを行うモデルが提起されている。

図２は、非特許文献１の図５．１．１に示されるＩＭＳ標準網の構成図である。また、図３は、複数のＡＳに対して起動制御を行うＩＭＳ標準化技術を示すシーケンスである。ここでは、ユーザ発信からＡＳ起動を行う手順を説明する。

まず、ユーザ１は、Ｓ−ＣＳＣＦ２に対してサービス起動要求を送信する（ステップＳ１）。Ｓ−ＣＳＣＦ２は、ユーザ１からのサービス起動要求を受信すると、ｉＦＣ分析を行う（ステップＳ２）。

ここで、ｉＦＣ（フィルタ判断基準）とは、それぞれのユーザ１に対して提供するサービスを決定するためのサービス決定基準をいう。また、ｉＦＣ分析とは、ＡＳを起動するために、複数のｉＦＣを優先度（Priority）に従って順次判断する動作をいう。

例えば、ユーザ登録を行う際に、図２に示すＨＳＳ（Home Subscriber Server）には、ユーザに関する情報であるユーザプロファイルが保持される。ユーザ登録処理の際に、Ｓ−ＣＳＣＦは、ＨＳＳからユーザプロファイルを取得する。そして、図４に示すように、ユーザプロファイル５１はｉＦＣを含むものである。

図４に示すように、ユーザプロファイル５１には、複数のｉＦＣ＃１〜ｉＦＣ＃３を設定することができる。これは、ｉＦＣは、ユーザ管理者が、ユーザとの間のサービス契約により設定されるものであるからである。つまり、ｉＦＣが設定されていることがサービス契約をしていることを示し、設定されていないことがサービス契約をしていないことを示す。

また、図４に示すように、ｉＦＣ５２は、優先度（Priority）５２１、トリガーポイント５２２、ＡＳ（アプリケーションサーバ）５２３に関する情報を含むものである。

優先度（Priority）５２１は、ＡＳの起動順序を示すものであり、他のＡＳとの関係からシステム一意に決定されるものである。また、この優先度（Priority）は、例えばシステム設計者により定義されるものである。

トリガーポイント５２２には、ＡＳを起動する条件であるサービスポイントトリガーが記載されており、例えばサービス提供者により定義されるものである。このサービスポイントトリガーには、ＡＳ起動条件として、例えば、Request URI、SIPメソッド、SIPヘッダ、セッション条件、セッション記述などが記載されている。

ＡＳ５２３には、起動するＡＳに関する情報が記載される。例えば、SIP URI、デフォルト処理、サービス情報等が記載される。

Ｓ−ＣＳＣＦ２は、最初のサービス起動要求（ini−Request）を受信すると、その直後に当該ユーザのユーザプロファイルに含まれる各ｉＦＣのトリガーポイント５２２を参照して、今回のサービス起動要求と条件が一致するサービスポイントトリガーがあるか否かを検索し、トリガーヒットした場合にはＡＳ（＃１）３に対して、サービス起動要求を転送する（ステップＳ３、Ｓ４）。

サービス起動要求を受信したＡＳ（＃１）３は起動し、ユーザ１に対してサービス提供動作を行う（ステップＳ５）。

そして、ＡＳ（＃１）３は、サービス提供動作を実施すると、Ｓ−ＣＳＣＦ２に対してサービス起動要求を送信する（ステップＳ６）。

Ｓ−ＣＳＣＦ２は、サービス起動要求を受信すると、再度、上記と同様にしてｉＦＣ分析を行う（ステップＳ７）。このとき、Ｓ−ＣＳＣＦ２は、ｉＦＣ５２の優先度（Priority）を判定して、高いものから順にサービス起動要求を行う（ステップＳ８）。

ここでは、次に優先度（Priority）が高いＡＳ（＃２）４に対してサービス起動要求を転送し（ステップＳ９）、ＡＳ（＃２）４がユーザ１に対してサービス提供動作を実施し（ステップＳ１０）、サービス提供実施後、ＡＳ（＃２）４はＳ−ＣＳＣＦ２に対してサービス起動要求を送信する（ステップＳ１１）。

上記のように、一連の動作において、複数のＡＳが起動する場合、同時に起動してよいかどうかの判断が必要となる。これを競合判断処理という（ステップＳ１２）。そして、複数のＡＳの関係が排他である場合、一方を起動させないようにすることが必要となる。これを競合動作（競合回避動作）という。

従来、ＩＭＳ標準化技術では、ＡＳの競合判断処理及び競合動作については、ＳＣＩＭにて実現することが規定されている。

３ＧＰＰ（Third Generation Partnership Project）技術仕様、"３ＧＰＰ ＴＳ 23.218 V8.4.0（2008-12）" ３ＧＰＰ（Third Generation Partnership Project）技術仕様、"３ＧＰＰ ＴＳ 29.228 V8.6.0（2009-09）"

しかしながら、ＩＭＳ標準ではＳＣＩＭのアーキテクチャを明確にしておらず、定義が曖昧である。また、ＳＣＩＭといったコンポーネントを実装する必要があるため、機器増加に伴うコスト高や煩雑な保守運用が必要になることが懸念される。

そこで、ＳＣＩＭを利用せず、ｉＦＣ判定機能により複数ＡＳの競合回避処理を行うことが望まれている。

ここでは、ｉＦＣ判定機能による複数ＡＳの競合回避処理を実現する以下の２つのケースを考察する。

ｃａｓｅ１；ＡＳ（＃１）が起動する場合、ＡＳ（＃２）は起動してはいけない。

ｃａｓｅ２：ＡＳ（＃２）が起動する場合、ＡＳ（＃１）は起動してはいけない。

図５は、ｃａｓｅ１の場合の競合回避処理を説明する説明図である。ｃａｓｅ１では、最初のｉＦＣ分析し（ステップＳ２）、ＡＳ（＃１）３が起動する。このとき、ＡＳ（＃１）３は、自身が起動していることを信号上（例えばＨｉｓｔｏｒｙ−Ｉｎｆｏ等）に記録したサービス起動要求をＳ−ＣＳＣＦ２に送信する方法が考えられる（ステップＳ１３）。これにより、Ｓ−ＣＳＣＦ２は、次に行うＡＳ（＃２）４のｉＦＣ分析にて、ＡＳ（＃１）３の起動有無を判断することが可能である。例えば、図５の「ｉＦＣ−２」の（Ａ）の部分にＡＳ（＃１）３が起動していることが記録されているので、Ｓ−ＣＳＣＦ２は、サービス起動要求をＡＳ（＃２）４に送信しないようにできる（ステップＳ１４）。

図６は、ｃａｓｅ２の場合の競合回避処理を説明する説明図である。ｃａｓｅ２では、ＡＳ（＃２）４の起動有無を判断する前にＡＳ（＃１）３が起動してしまうため、ｃａｓｅ１のように信号上での判断を行うことができない。そこで、「ｉＦＣ−２」のトリガーポイントと背反する内容を「ｉＦＣ−１」のトリガーポイント（図６の「ｉＦＣ−１」の（Ａ）参照）に記載することが考えられる。

しかしながら、上記の方法には以下のような２つの課題が生じ得る。図７は、課題を説明する説明図である。

１つ目は、ＡＳ（＃２）４の起動条件がＡＳ（＃１）３の起動条件と同様である場合である。例えば、図７（Ｂ）では、ＡＳ（＃１）３を起動させる「ｉＦＣ−１」において、サービスポイントトリガー（ＳＰＴ）に記載されている条件が、ＳＰＴ１は「条件がａ」とし、ＳＰＴ２は「条件がａではない」としている。またＡＳ（＃２）４を起動させる「ｉＦＣ−２」のＳＰＴ１は「条件がａ」としている。この場合、記述が背反となるため、正常に動作することができない。

２つ目は、ＡＳ（＃２）４を契約していない場合である（図７（Ｃ）の（ｂ）参照）。例えば、図７（Ｃ）では、「ｉＦＣ−１」のＳＰＴ１は「条件がａ」とし、ＳＰＴ２は「条件がｂではない」としているが、「ｉＦＣ−２」の設定がない場合である。この場合、ＡＳ−２は起動しない条件であるにも関わらずＡＳ（＃１）３が起動しなくなってしまう。

そこで、本発明は、これら競合処理での課題を解決したｉＦＣ拡張による競合調停するための制御を行う競合制御システム、サーバ及び競合制御プログラムを提供する。

かかる課題を解決するために、第１の本発明の競合制御システムは、一連の動作において同時期に複数のサーバが起動する競合動作の調停を行う競合制御システムであって、（１）ユーザにサービスを提供するサーバを起動させる起動順序を示す優先度が付されたものであって、それぞれのサーバを起動させるサーバ起動条件を有する複数のサービス決定基準を保持するサービス決定基準保持手段と、（２）サーバ起動要求を受信すると、優先度の高いサービス決定基準から順に、サーバ起動要求がサーバ起動条件を満たすか否かを判断するサーバ起動条件判断手段と、（３）サーバ起動条件判断手段によりサーバ起動条件を満たすと判断されると、これをトリガーとして、当該サービス決定基準のサーバに対してサーバ起動要求を送信するセッション処理手段とを備え、サーバ起動条件判断手段が、今回のサービス決定基準とは異なる他のサービス決定基準のサーバ起動条件を参照して、競合するサーバのうち起動させるべきサーバを判断する競合調停判断部を有することを特徴とする。

第２の本発明のサーバは、一連の動作において同時期に複数のサーバが起動する競合動作の調停を行う競合制御を行うサーバであって、（１）ユーザにサービスを提供するサーバを起動させる起動順序を示す優先度が付されたものであって、それぞれのサーバを起動させるサーバ起動条件を有する複数のサービス決定基準を保持するサービス決定基準保持手段と、（２）サーバ起動要求を受信すると、優先度の高いサービス決定基準から順に、サーバ起動要求がサーバ起動条件を満たすか否かを判断するサーバ起動条件判断手段と、（３）サーバ起動条件判断手段によりサーバ起動条件を満たすと判断されると、これをトリガーとして、当該サービス決定基準のサーバに対してサーバ起動要求を送信するセッション処理手段とを備え、サーバ起動条件判断手段が、今回のサービス決定基準とは異なる他のサービス決定基準のサーバ起動条件を参照して、競合するサーバのうち起動させるべきサーバを判断する競合調停判断部を有することを特徴とする。

第３の本発明の競合制御プログラムは、一連の動作において同時期に複数のサーバが起動する競合動作の調停を行う競合制御プログラムであって、ユーザにサービスを提供するサーバを起動させる起動順序を示す優先度が付されたものであって、それぞれのサーバを起動させるサーバ起動条件を有する複数のサービス決定基準を保持するサービス決定基準保持手段を備えるコンピュータを、（１）サーバ起動要求を受信すると、優先度の高いサービス決定基準から順に、サーバ起動要求がサーバ起動条件を満たすか否かを判断するサーバ起動条件判断手段、（２）サーバ起動条件判断手段によりサーバ起動条件を満たすと判断されると、これをトリガーとして、当該サービス決定基準のサーバに対してサーバ起動要求を送信するセッション処理手段として機能させるものであり、サーバ起動条件判断手段が、今回のサービス決定基準とは異なる他のサービス決定基準のサーバ起動条件を参照して、競合するサーバのうち起動させるべきサーバを判断することを特徴とする。

本発明によれば、ｉＦＣを拡張することで、複数のＡＳ起動に対する競合分析を実現することができる。

実施形態のネットワークの全体構成の概略を示す構成図である。 ＩＭＳ標準網の構成を示す構成図である。 複数のＡＳに対して起動制御を行うＩＭＳ標準化技術を示すシーケンスである。 ｉＦＣの構成を説明する説明図である。 ｉＦＣを利用して競合処理を回避するｃａｓｅ１の場合の処理を説明する説明図である。 ｉＦＣを利用して競合処理を回避するｃａｓｅ２の場合の処理を説明する説明図である。 ｉＦＣを利用して競合を回避する場合に生じ得る課題を説明する説明図である。 実施形態のＳ−ＣＳＣＦの機能を説明するブロック図である。 実施形態のｉＦＣの構成及び競合調停判断部の処理を説明する説明図である。 実施形態のネットワークにおけるセッション処理の全体シーケンスと、「ｉＦＣ−１」及び「ｉＦＣ−２」の構成例を示す説明図である。

（Ａ）主たる実施形態
以下では、本発明の競合制御システム、サーバ及び競合制御プログラムの実施形態を、図面を参照しながら説明する。

（Ａ−１）実施形態の構成
（Ａ−１−１）全体構成
図１は、実施形態のネットワーク１０の全体構成の概略を示す全体構成図である。図１において、実施形態のネットワーク１０は、ユーザ端末１、Ｓ−ＣＳＣＦ２、ＡＳ（＃１）３、ＡＳ（＃２）４、ＨＳＳ５、Ｐ−ＣＳＣＦ６などを少なくとも有して構成される。

ユーザ端末１は、ユーザが利用する端末である。ユーザ端末１は、通信機能を有する様々なデバイスを広く適用することができ、例えば、携帯電話機、ＰＤＡ等の携帯端末、無線通信機能を有するパーソナルコンピュータ等を適用することができる。ユーザ端末１は、Ｐ−ＣＳＣＦ６にアクセスしてネットワーク通信を行う。

Ｐ−ＣＳＣＦ６は、アクセスしてきたユーザ端末１とネットワーク１０との間に介在するものである。Ｐ−ＣＳＣＦ６は、ユーザ端末１とネットワーク１０との間で授受される信号を転送する。

ＨＳＳ５は、ユーザ情報を保持するものである。ＨＳＳ５は、例えば、ユーザに提供するマルチメディアサービスに関するユーザプロファイル情報（例えば、サービス契約情報等）、ユーザ端末１の位置情報、セキュリティ情報（例えば認証、許可情報等を含む情報）等を有する。ＨＳＳ５は、例えば、ＩＭＳ標準技術で規定されているユーザ端末１の登録処理を行い、上記に例示したユーザ情報を有している。

ＡＳ（＃１）３、ＡＳ（＃２）４は、所定のサービスを提供するアプリケーションサーバである。

Ｓ−ＣＳＣＦ２は、セッション処理を行うものである。Ｓ−ＣＳＣＦ２は、ユーザ端末１からサービス起動要求を受けると、そのｉＦＣ分析を行い、当該ユーザのユーザプロファイルに含まれているｉＦＣを用いて、トリガーポイントに記載されている条件と一致する場合には、これをサーバ起動のトリガーとして（すなわちサービスを提供するトリガーとして）、そのｉＦＣのＡＳに対してサービス起動要求を行うものである。

図８は、Ｓ−ＣＳＣＦ２における機能を示すブロック図である。図８に示すように、Ｓ−ＣＳＣＦ２が有する機能としては、ユーザプロファイル取得・保持部２１、セッション制御部２２、ｉＦＣ分析部２３がある。

ユーザプロファイル取得・保持部２１は、ＨＳＳ５からユーザのユーザプロファイルを取得し、ユーザプロファイルを保持するものである。ユーザプロファイルを取得するタイミングや取得する方法は、特に限定されるものではなく、種々のタイミングや取得方法を広く適用することができ、ＩＭＳ標準化技術を適用することができる。例えば、ユーザ端末１の登録処理の際に、ユーザプロファイル取得部２１は、ＨＳＳ５から当該ユーザのユーザプロファイルをダウンロードして取得する方法等を適用することができる。

セッション制御部２２は、受信したリクエストに応じてセッション処理を制御するものである。セッション制御プロトコルは、特に限定されるものではないが、例えば、ＳＩＰ（Session Initiative Protocol）等を適用することができる。また、セッション制御部２２は、ｉＦＣ分析部２３により、受信したリクエストがトリガーポイントとヒットしたｉＦＣのＡＳに対してサービス起動要求を送信する。

ｉＦＣ分析部２３は、サービス起動要求を受信すると、ユーザプロファイル取得部２１が取得したユーザプロファイルに含まれている１又は複数のｉＦＣを用いてｉＦＣ分析を行うものである。また、ｉＦＣ分析部２３は、ｉＦＣ分析処理において、一連の動作で複数のＡＳに対して起動を要求する場合の競合判断処理を行う競合調停判断部２３１を有する。

競合調停判断部２３１は、ｉＦＣのトリガーポイントに記載されているＡＳ間の関連性情報を参照して、競合する複数のＡＳのうち、起動すべきＡＳを判断するものである。この実施形態では、ｉＦＣのトリガーポイントには、ＡＳ間の関連性を示す情報がＡＳ起動の条件として記載されている。競合調停判断部２３１は、このトリガーポイントに記載されているＡＳ間の関連性情報に基づき、当該ｉＦＣより優先度（Priority）が低い他のｉＦＣのトリガーポイントも参照しながら、競合判断処理を行う。

（Ａ−１−２）ｉＦＣの構成について
ｉＦＣ（サービス決定基準ともいう）は、例えばＸＭＬ（Extensible Markup Language）により記述されて構成されたものである。ｉＦＣの主な構成は、例えば図４に例示する構成と同じである。つまり、ｉＦＣ５２は、サーバ起動順序を示す優先度（Priority）５２１、サーバ起動条件であるサービスポイントトリガー（ＳＰＴ）が記述されたトリガーポイント５２２、起動するＡＳに関連する情報を示すＡＳ（アプリエーションサーバ）５２３を有する。

Ｓ−ＣＳＣＦ２において、ｉＦＣ分析部２３は、ｉＦＣ５２を、先頭から読み下ろしながら逐次解釈し、ｉＦＣ分析を行う。そのため、ｉＦＣ分析部２３は、優先度（Priority）の高いｉＦＣ５２から順に判断する。

この実施形態では、Priority0が最も優先度が高く、Priority１、2、…の順に低くなるものとする。例えば、ＡＳ（＃１）３を起動させる「ｉＦＣ−１」の優先度が「Priority0」であり、ＡＳ（＃２）４を起動させる「ｉＦＣ−２」の優先度が「Priority1」である場合、ｉＦＣ部２３は、「ＡＳ（＃１）３」→「ＡＳ（＃２）４」の順でｉＦＣ分析を行う。

つまり、ｉＦＣ分析部２３が、ＡＳ（＃１）３の「ｉＦＣ−１」を判断している時点では、ＡＳ（＃２）４が起動するどうかの判断をすることができない。

そこで、この実施形態では、ｉＦＣ分析処理において、複数のＡＳ間の関連性を判断することができるようにする。例えば、ＡＳ（＃１）３とＡＳ（＃２）４とが競合関係である場合、ＡＳ（＃１）３の「ｉＦＣ−１」を判断しているときに、ＡＳ（＃２）４の「ｉＦＣ−２」を判断できるようにする。

図９は、この実施形態のｉＦＣの構成及び競合調停判断部２３１の処理を説明する説明図である。ここでは、ＸＭＬを拡張して、ｉＦＣの記述において、ＡＳ間で関連性を持たせられるようにする場合を例示する。

図９では、３台のＡＳ間の関係性を判断する場合を例示する。「ｉＦＣ−１」はＡＳ（＃１）を起動させるものであって優先度はPriority0とする。また、「ｉＦＣ−２」はＡＳ（＃２）を起動させるものでありPriority1であり、「ｉＦＣ−３」はＡＳ（＃３）を起動させるものでありPriority2とする。

図９に例示する各ｉＦＣのトリガーポイント（TriggerPoint）に設定されているサービスポイントトリガー（ＳＰＴ）には、ＸＭＬ拡張記述により、他のｉＦＣのトリガーポイントに設定されているサービスポイントトリガーを参照することが条件として設定されている（図９のＰ１）。

例えば、「ｉＦＣ−１」のサービスポイントトリガー（ＳＰＴ）として３個の条件が設定されており、「ＳＰＴ１」は、受信したRequestが発信ini−INVITEであることを条件とし、「ＳＰＴ２」は、Priority=1の「ｉＦＣ−２」のトリガーポイントでないこと（すなわちサーバ起動条件であるＳＰＴを満たしていないこと）を条件とし、「ＳＰＴ３」は、Priority=2の「ｉＦＣ−３」のトリガーポイントでないことを条件とする。

このように、サービスポイントトリガー（ＳＰＴ）に、参照したいトリガーポイント（ＴＰ）のｉＦＣの優先度（Priority）を設定しておくことで、競合調停判断部２３１は、Priorityを位置情報として他のｉＦＣのトリガーポイントを参照し、その参照先のトリガーポイントの条件を満たしているか否かを判断することができる。

これにより、例えば、ＡＳ（＃１）３の「ｉＦＣ−１」の判断時に、ＡＳ（＃２）４が起動するかどうかを事前に確認することができる。つまり、ＡＳ（＃２）４が起動する場合には、ＡＳ（＃１）３を起動させないようにすることができ、逆に、ＡＳ（＃２）４が起動しない場合に、ＡＳ（＃１）３を起動させることができる。

例えば、ＸＭＬには、様々な拡張が提案されており、その中でＸＰａｔｈ拡張を利用することで、構文中を再帰的に参照することができる。

このとき、次の点に留意する。例えば、図９に例示する「ｉＦＣ−３」のトリガーポイントには、対応するPriorityのｉＦＣが存在しないことを条件としている。この場合、当該条件は「False」として取り扱う（図９のＰ３）。

また例えば図９に例示する「ｉＦＣ−２」のトリガーポイントには、Priority=2を参照することをサービスポイントトリガーとしている（「ＳＰＴ３」）。「ｉＦＣ−１」の判断時に、参照先として「ｉＦＣ−２」のトリガーポイントを含め判断する（図９のＰ２）。

しかし、「ＡＳ（＃１）」→「ＡＳ（＃２）」→「ＡＳ（＃１）」→「ＡＳ（＃２）」→…といった無限ループを起こす可能性があることである。そのため、参照先ｉＦＣのPriorityが自ｉＦＣより高い場合、参照する記述をしてはならないルール付けが必要である（図９のＰ４）。

（Ａ−２）実施形態の動作
次に、この実施形態のＳ−ＣＳＣＦ２における競合制御処理の動作を、図面を参照しながら説明する。

図１０は、ネットワーク１０におけるセッション処理の全体シーケンスと、「ｉＦＣ−１」及び「ｉＦＣ−２」の構成例を示す説明図である。

なお、ユーザ端末１の登録処理は、例えばＩＭＳ標準化技術に規定されている処理により、既に行われているものとする。そのため、ユーザに提供するサービス契約はユーザとユーザ管理者等との間でなされており、そのサービス契約に関する情報がユーザプロファイル情報に含まれている。つまり、ｉＦＣ（サービス決定基準）も、ユーザプロファイル情報に含まれているものとする。

まず、ユーザ端末１は、Ｐ−ＣＳＣＦ６にアクセスしてネットワーク１０との接続を開始する。また、ユーザ端末１は、最初のサービス起動要求（ini−Request）をＳ−ＣＳＣＦ２に送信する（ステップＳ１０１）。

Ｓ−ＣＳＣＦ２は、ユーザ端末１から最初のサービス起動要求を受信すると、ＨＳＳ５から取得したユーザプロファイル情報に含まれる当該ユーザのｉＦＣ（サービス決定基準）を用いて、ｉＦＣ分析を行う（ステップＳ１０２）。

ここで、Ｓ−ＣＳＣＦ２のｉＦＣ分析部２３は、優先度が最も高いPriority0のｉＦＣから分析を実施する。また、Priority0の「ｉＦＣ−１」は、図１０に例示するように、２つのサービスポイントトリガー（ＳＰＴ）が設定されている。１つ目のＳＰＴは、INVITEを受信したことを条件としており、２つ目のＳＰＴは、Priority=1の「ｉＦＣ−２」のトリガーポイントでないこと（ＡＳ（＃２）が起動しないこと）である。

ｉＦＣ分析部２３は、受信したサービス起動要求がINVITEメッセージであり、１つ目のＳＰＴの条件に該当するためＴｒｕｅとなる（図１０（Ａ）参照）。

次に、２つ目のＳＰＴは、ＡＳ（＃２）４が起動するならば、ＡＳ（＃１）３が起動しないことを示すため、ＡＳ（＃２）４が起動する場合に、他のｉＦＣの結果がＴｒｕｅとなるため、結果は排他として扱うように、例えばＣｏｎｄｉｔｉｏｎ Ｎｅｇａｔｅｄ＝１とする（図１０（Ｂ）参照）。

ｉＦＣ分析部２３は、他のｉＦＣの中に参照すべき位置情報としてPriority=1が設定されているので（図１０（Ｃ）参照）、このPriority1の「ｉＦＣ−２」のトリガーポイントを参照する（図１０（Ｄ）参照）。

図１０（Ｅ）の例の場合、「ｉＦＣ−２」のＳＰＴには、INVITEを受信したことを条件とすることが設定されているから、ＡＳ（＃２）４の起動条件に合致する。他のｉＦＣである「ｉＦＣ−２」のＳＰＴはＴｒｕｅとなるため、「ｉＦＣ−１」の２つ目のＳＰＴ結果はＦａｌｓｅとして扱う。

つまり、「ｉＦＣ−１」については、１つ目のＳＰＴはＴｒｕｅ、２つ目のＳＰＴはＦａｌｓｅであるため、ｉＦＣ分析部２３は、Priority=0のサーバ起動条件に該当しないと判断され、ＡＳ（＃１）３は起動しない（ステップＳ１０３）。

そして、ｉＦＣ分析部２３は、次に優先度の高いPriority=1の「ｉＦＣ−２」を用いてｉＦＣ分析を行う（ステップＳ１０４）。

「ｉＦＣ−２」のＳＰＴは、INVITEを受信することであり、ＡＳ（＃２）４の起動条件に合致するから、ＡＳ（＃２）４を起動するために、セッション制御部２２は、ＡＳ（＃２）４に対してサービス起動要求を送信する（ステップＳ１０５）。

ＡＳ（＃２）４は、自身が起動していることを信号上（例えばＨｉｓｔｏｒｙ−Ｉｎｆｏ等）に記録したサービス起動要求をＳ−ＣＳＣＦ２に送信する。これにより、Ｓ−ＣＳＣＦ２に対して、ＡＳ（＃２）４が起動していることを認識させることができる（ステップＳ１０６）。

例えば、図７（Ｂ）で例示したように、複数のＡＳのサーバ起動条件が同じであり、条件違背で複数のＡＳが競合動作をしてしまう場合でも、上記のような処理を行うことにより、これを解消することができる。

また、図７（Ｃ）で例示したように、他のＡＳが起動していないことが条件となっている場合に、その他のＡＳのサービスをユーザが契約していないために、当該ＡＳを起動させることができないときでも、次のような処理により解消することができる。

この場合、図１０を用いて説明すると、「ｉＦＣ−２」が設定されていない場合である。

Ｓ−ＣＳＣＦ２が、ユーザ端末１からサーバ起動要求を受信すると（ステップＳ１０１）、優先度が最も高いPriority=0の「ｉＦＣ−１」を用いてｉＦＣ分析を行う（ステップＳ１０２）。

このとき、ｉＦＣ分析部２３は、「ｉＦＣ−１」のトリガーポイントの２つ目のＳＰＴが、Priority=1を参照する旨であるから、Priority=1を辿って「ｉＦＣ−２」のトリガーポイントを参照する。

しかし、「ｉＦＣ−２」が設定されていないから、ｉＦＣ分析部２３は、Ｆａｌｓｅとして扱う。すなわち、他のｉＦＣである「ｉＦＣ−２」のＳＰＴはＴｒｕｅとなるため、「ｉＦＣ−１」の２つ目のＳＰＴ結果はＦａｌｓｅとして扱う。

つまり、「ｉＦＣ−１」については、１つ目のＳＰＴはＴｒｕｅ、２つ目のＳＰＴもＴｒｕｅとなるため、ｉＦＣ分析部２３は、Priority=0のサーバ起動条件に該当すると判断する。

そして、ＡＳ（＃１）３を起動するために、セッション制御部２２は、ＡＳ（＃１）３に対してサービス起動要求を送信する（ステップＳ１０５）。

なお、ＡＳ（＃１）３は、自身が起動していることを信号上（例えばＨｉｓｔｏｒｙ−Ｉｎｆｏ等）に記録したサービス起動要求をＳ−ＣＳＣＦ２に送信する。これにより、Ｓ−ＣＳＣＦ２に対して、ＡＳ（＃１）３が起動していることを認識させることができる。

（Ａ−３）実施形態の効果
以上のように、実施形態の競合制御方式によれば、以下の効果により、コスト及び保守性の向上が期待できる。

実施形態によれば、ＳＣＩＭを必要としないのでコストを抑えることができ、ｉＦＣの記述を行うだけでＡＳの競合判定を可能とする。

また、実施形態によれば、ｉＦＣの拡張となるが、ＸＭＬ記述を逸脱しないため、Ｓ−ＣＳＣＦへの影響は少ない。

さらに、実施形態によれば、新規ＡＳ追加時はｉＦＣの変更を行うのみで対応が可能である。

（Ｂ）他の実施形態
上述した実施形態では、ｉＦＣを拡張することでのＳＣＩＭによらない競合方式を説明したが、本発明とＳＣＩＭを連携させることで、さらに細かな競合処理（競合回避処理）を実現することができる。ＡＳ起動の有無判定はｉＦＣ分析機能として行い、ＡＳ起動後のＡＳ間やり取りを必要とする制御はＳＣＩＭにて実現という機能分離が可能となる。

また、現在の固定電話では多数のサービスが提供されている。それらサービスをＮＧＮ網に巻取るとした場合、既存交換システムの実施しているサービス制御と同等のＡＳ制御が必要となる。それを実現するために本発明は非常に有効である。

１…ユーザ端末（ＵＥ）、２…Ｓ−ＣＳＣＦ、３…ＡＳ（＃１）、４…ＡＳ（＃２）、
１０…ネットワーク、２１…ユーザプロファイル取得・保持部、
２２…セッション制御部、２３…ｉＦＣ分析部、２３１…競合調停判断部。

Claims (5)

1. 一連の動作において同時期に複数のサーバが起動する競合動作の調停を行う競合制御システムであって、
   ユーザにサービスを提供するサーバを起動させる起動順序を示す優先度が付されたものであって、それぞれのサーバを起動させるサーバ起動条件を有する複数のサービス決定基準を保持するサービス決定基準保持手段と、
   サーバ起動要求を受信すると、上記優先度の高い上記サービス決定基準から順に、上記サーバ起動要求が上記サーバ起動条件を満たすか否かを判断するサーバ起動条件判断手段と、
   上記サーバ起動条件判断手段により上記サーバ起動条件を満たすと判断されると、これをトリガーとして、当該サービス決定基準のサーバに対してサーバ起動要求を送信するセッション処理手段と
   を備え、
   上記サーバ起動条件判断手段が、今回のサービス決定基準とは異なる他のサービス決定基準の上記サーバ起動条件を参照して、競合するサーバのうち起動させるべきサーバを判断する競合調停判断部を有する
   ことを特徴とする競合制御システム。
2. 上記各サービス決定基準の上記サーバ起動条件は、当該サービス決定基準よりも優先度の低い他のサービス決定基準の上記サーバ起動条件を参照することを条件としており、
   上記競合調停判断部が、上記他のサービス決定基準の上記サーバ起動条件を満たしておらず、今回のサービス決定基準の上記サーバ起動条件を満たしている場合に、今回のサービス決定基準のサーバを起動すべきサーバと判断する
   ことを特徴とする請求項１に記載の競合制御システム。
3. 上記各サービス決定基準の上記サーバ起動条件が、ＸＭＬの拡張により記述されたものであることを特徴とする請求項１又は２に記載の競合制御システム。
4. 一連の動作において同時期に複数のサーバが起動する競合動作の調停を行う競合制御を行うサーバであって、
   ユーザにサービスを提供するサーバを起動させる起動順序を示す優先度が付されたものであって、それぞれのサーバを起動させるサーバ起動条件を有する複数のサービス決定基準を保持するサービス決定基準保持手段と、
   サーバ起動要求を受信すると、上記優先度の高い上記サービス決定基準から順に、上記サーバ起動要求が上記サーバ起動条件を満たすか否かを判断するサーバ起動条件判断手段と、
   上記サーバ起動条件判断手段により上記サーバ起動条件を満たすと判断されると、これをトリガーとして、当該サービス決定基準のサーバに対してサーバ起動要求を送信するセッション処理手段と
   を備え、
   上記サーバ起動条件判断手段が、今回のサービス決定基準とは異なる他のサービス決定基準の上記サーバ起動条件を参照して、競合するサーバのうち起動させるべきサーバを判断する競合調停判断部を有する
   ことを特徴とするサーバ。
5. 一連の動作において同時期に複数のサーバが起動する競合動作の調停を行う競合制御プログラムであって、
   ユーザにサービスを提供するサーバを起動させる起動順序を示す優先度が付されたものであって、それぞれのサーバを起動させるサーバ起動条件を有する複数のサービス決定基準を保持するサービス決定基準保持手段を備えるコンピュータを、
   サーバ起動要求を受信すると、上記優先度の高い上記サービス決定基準から順に、上記サーバ起動要求が上記サーバ起動条件を満たすか否かを判断するサーバ起動条件判断手段、
   上記サーバ起動条件判断手段により上記サーバ起動条件を満たすと判断されると、これをトリガーとして、当該サービス決定基準のサーバに対してサーバ起動要求を送信するセッション処理手段
   として機能させるものであり、
   上記サーバ起動条件判断手段が、今回のサービス決定基準とは異なる他のサービス決定基準の上記サーバ起動条件を参照して、競合するサーバのうち起動させるべきサーバを判断することを特徴とする競合制御プログラム。

Images