WO2009110158A1

WO2009110158A1 - サービス制御装置、サービス制御システム及び方法

Info

Publication number: WO2009110158A1
Application number: PCT/JP2008/073179
Authority: WO
Inventors: 武田　幸子; 晶彦高瀬; 松原　大典
Original assignee: 株式会社日立製作所
Priority date: 2008-03-06
Filing date: 2008-12-19
Publication date: 2009-09-11
Also published as: EP2254317A1; JP2013225941A; EP2254317A4; US20140164543A1; CN101911664A; JP5716795B2; JPWO2009110158A1; US20110029654A1; US8656001B2

Abstract

　通信事業者がメッセージ変換機能を備えたアプリケーションサーバ２を備える。アプリケーションサーバ２はトリガルール２２０とメッセージルール２３０を参照して、サービス機能振り分け処理を行う。通信事業者はサービス事業者に個々のサーバアドレスを通知することなく、各種サービス機能の提供が可能になる。

Description

サービス制御装置、サービス制御システム及び方法

参照による取り込み

　本出願は、２００８年３月６日に出願された日本特許出願第２００８－０５５７００号の優先権を主張し、その内容を参照することにより本出願に取り込む。

　本願明細書で開示される技術は、ネットワークに接続された通信装置、通信システム及び通信制御方法に関する。特に、複数の通信サーバが相互通信を行う際のサーバ連携、及び、メッセージ変換処理に関する。中でも、ＳＩＰによるセッション制御を適用した通信システムと、Ｗｅｂアプリケーションを提供する通信システムを相互接続した通信システムにおけるメッセージ変換方法に関する。

　音声、データ、動画像など多様なマルチメディア・サービスの高速かつ高品質な提供を目指して、第３世代移動通信システムの標準化が行われている。３ＧＰＰ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）は、パケット交換網上で、ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）技術を活用して、音声、映像などのマルチメディア・サービスを提供する「Ａｌｌ　ＩＰベース移動通信網」の標準化を進めている。

　Ａｌｌ　ＩＰ移動通信網におけるセッション制御システムはＩＭＳ（ＩＰ　Ｍｕｌｔｉｍｅｄｉａ　Ｓｕｂｓｙｓｔｅｍ）と呼ばれる。ＩＭＳは次世代ネットワーク（ＮＧＮ：Ｎｅｘｔ　Ｇｅｎｅｒａｔｉｏｎ　Ｎｅｔｗｏｒｋ）のセッション制御技術にも採用されている。

　ＩＭＳにおけるセッション制御プロトコルとして、ＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）が利用される（例えば、ＩＥＴＦ　ＲＦＣ３２６１（２００２．６）参照）。ＳＩＰは、ＩＥＴＦで仕様化されたＩＰマルチメディア通信のセッション制御を行うプロトコルである。ＳＩＰは、通信装置間のセッション確立、維持及び切断を制御する。
　ＳＩＰを用いた代表サービスにＩＰ電話サービスがある。ＩＰ電話サービスは、音声情報をＩＰネットワーク上で送受信するサービスである。ＳＩＰによるＩＰ電話サービスでは、通信開始前に通信装置間に仮想的な通話路（セッション）が設定される。ＩＰパケット化された音声データが、設定された通信路上で転送される。

　音声データの属性などのメディア情報は、セッション確立時に決定される。通信装置は、メディア情報を、ＳＩＰメッセージに含まれるＳＤＰ（Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）によって通知する。ＳＤＰでは、セッションに関する様々な情報（例えば、ＩＰアドレス、ポート番号、メディア種別など）を記述することができる。ＳＩＰプロトコルを用いたアプリケーションサービスの例として、Ｔｈｉｒｄ　Ｐａｒｔｙ　Ｃａｌｌ　Ｃｏｎｔｒｏｌがある（例えば、ＩＥＴＦ　ＲＦＣ３７２５（２００４．６）参照）。

　さらに、通信事業者が提供する通信サービスをＷｅｂサービスから利用可能にするため、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）の検討が進んでいる。

　ＡＰＩを規定する業界団体としてＰａｒｌａｙ　Ｇｒｏｕｐがある。Ｐａｒｌａｙ　Ｇｒｏｕｐでは「Ｐａｒｌａｙ－Ｘ」と呼ばれるＡＰＩを策定中である。Ｐａｒｌａｙ　Ｇｒｏｕｐは、欧州電気通信標準化ＥＴＳＩ（Ｅｕｒｏｐｅａｎ　Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｓｔａｎｄａｒｄｓ　Ｉｎｓｔｉｔｕｔｅ）や第３世代移動通信標準化団体３ＧＰＰと連携している。Ｐａｒｌａｙ　Ｘの仕様はこの３団体から共同で発行されている。
　「Ｐａｒｌａｙ－Ｘ」は、Ｗｅｂサービス環境での使用を目的とした、ネットワークやベンダに非依存、かつ、実装言語に限定しないＷｅｂサービスのＡＰＩである。「Ｐａｒｌａｙ　Ｘ」は、Ｗｅｂ開発者向けに抽象化されたオープンインタフェースを定義するが、その実装方法は規定されていない。

　「Ｐａｒｌａｙ－Ｘ」ではサービス毎にＡＰＩのセットが規定されている。Ｐａｒｌａｙ－Ｘ　ＡＰＩを用いて提供されるサービスとして、例えば、Ｗｅｂアプリケーションから２者通話サービスを起動する３ＰＣＣ（３ｒｄ　Ｐａｒｔｙ　Ｃａｌｌ　Ｃｏｎｔｒｏｌ）がある（４ｔｈ　Ｄｒａｆｔ　ＥＳ　２０２　５０４－２　Ｐａｒｌａｙ　Ｘ　３．０（２００７．８））。

ＩＥＴＦ　ＲＦＣ３２６１（２００２．６）ＩＥＴＦ　ＲＦＣ３７２５（２００４．４）４ｔｈ　Ｄｒａｆｔ　ＥＳ　２０２　５０４－２　Ｐａｒｌａｙ　Ｘ　３．０（２００７．８）

　３ＰＣＣ用のＡＰＩでは、Ｗｅｂアプリケーションサーバから通信システムへの要求メッセージ（開始、終了、呼情報問い合わせ）とその応答メッセージが規定されている。
　ＳＩＰプロトコルを用いたアプリケーションの例として、Ｔｈｉｒｄ　Ｐａｒｔｙ　Ｃａｌｌ　Ｃｏｎｔｒｏｌがあり、ＳＩＰメッセージのシーケンス例が示されている。しかし、上記Ｐａｒｌａｙ　Ｘ　ＡＰＩと上記ＳＩＰメッセージの変換手段に関して、実装方法は規定されていない。

　このため、サービス事業者が通信事業者のサービス機能をＰａｒｌａｙ　Ｘに代表されるオープンＡＰＩ経由で利用する通信システムにおいて、通信事業者は要求されたサービス機能に対応したサーバを特定する必要が生じるという課題があった。

　本発明の目的は、通信事業者はサービス事業者に個々のアプリケーションサーバのアドレスを通知することなく、各種サービス機能の利用を実現可能にする手段を提供することにある。

　本願で開示する代表的な発明では、通信システムがオープンＡＰＩとＳＩＰの変換機能を備えたアプリケーションサーバを備える。アプリケーションサーバはトリガルールとメッセージルールを参照して、サービス機能の振り分け処理を行う。本機能を備えることにより、通信事業者はサービス事業者に個々のアプリケーションサーバアドレスを通知することなく、各種サービス機能の提供が可能になる。

　本願で開示する他の代表的な発明では、上記アプリケーションサーバが、さらに、サービス事業者の要求に応じたカスタマイズ処理（例：パラメータの追加処理機能）など付加情報処理機能と、各処理の内容に応じた高速化エンジン（例：課金情報などトランザクション処理の高速化エンジン）を備える。本機能を備えることにより、アプリケーションサーバは、カスタマイズ化や特定処理の高速化の実現が可能になる。

　本発明の一実施形態によれば、通信事業者はサービス事業者に個々のサーバアドレスを通知することなく、各種サービス機能の提供が可能になる。また、通信事業者が処理のカスタマイズ化や特定処理の高速化を行うことが可能になる。これによりユーザニーズに応じて、様々なサービスを迅速に提供することが可能になる。
　本発明の他の目的、特徴及び利点は添付図面に関する以下の本発明の実施例の記載から明らかになるであろう。

　本発明の第１の実施の形態を、図面を用いて説明する。

　代表例として、第３者呼制御（３ＰＣＣ）サービスを利用する際の通信方法を詳細に説明する。

　図１は、本発明の第１の実施の形態の通信網の構成例を示す説明図である。

　本実施の形態における通信網は、ＩＰ網Ｎ１と、アクセス網Ｎ２（Ｎ２ａ、Ｎ２ｂ、Ｎ２Ｃ）によって構成される。

　図１には、端末（以下、ＵＥ：Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ）７の例として固定端末（７ａ～７ｄ）を示す。以下、端末７を区別して記載する場合、符号に添字「ａ」「ｂ」「ｃ」「ｄ」を付して、例えば端末７ａ及び端末７ｂのように記載する。その他の構成要素も、同様の規則に従って記載される。

　ＩＰ網Ｎ１とアクセス網Ｎ２とは、アクセスゲートウェイ装置（ＡＧＷ）６（６ａ、６ｂ、６ｃ）を介して接続される。アクセスゲートウェイ装置６の代わりに、ルータなど、他の通信装置を介して、ＩＰ網Ｎ１とアクセス網Ｎ２が接続されてもよい。アクセスゲートウェイ装置６は、端末７とＩＰ網Ｎ１との間で送受信されるＩＰパケットを転送する機能を提供する。

　ＩＰ網Ｎ１は、少なくてもＳＩＰサーバ１、ＷＥＢサーバ４、アプリケーションサーバ２、３ＰＣＣサーバ３を備える。ＩＰ網Ｎ１がさらにプレゼンスサーバ５を備えてもよい。ＩＰ網Ｎ１がプレゼンスサーバ５を備える場合、ＩＰ網Ｎ１はプレゼンスサービスの提供が可能になる。
　Ｗｅｂサーバ４は、３ＰＣＣサービスやプレゼンスサービスを起動するためのユーザインタフェース機能、３ＰＣＣサービスの起動に必要な機能、アプリケーションサーバ２との相互接続機能を備える。

　アプリケーションサーバ２は、通信網が備える各種サービス機能を利用するために必要な、サービス機能振り分け機能や、カスタマイズ機能を制御する機能を備える。

　３ＰＣＣサーバ３は、３ＰＣＣサービスの実行を制御する機能を備える。

　プレゼンスサーバ５は、プレゼンスサービスの実行を制御する機能を備える。

　なお、図１には、例として、ＳＩＰサーバ１、Ｗｅｂサーバ４、アプリケーションサーバ２、３ＰＣＣサーバ３、プレゼンスサーバ５を、それぞれ１つずつ示した。しかし、本発明を実施する際に、これらの構成要素の数は任意であってよい。

　図２は、本発明の第１の実施の形態におけるアプリケーションサーバ２の構成例を示す説明図である。

　アプリケーションサーバ２は、回線２２（２２ａ、２２ｂ）を収容するインタフェース部（ＩＦ）２１（２１ａ、２１ｂ）と、ＣＰＵ２４と、メモリ２５と、データベース（ＤＢ）２６とによって構成される。各構成要素は、バス２３で接続される。

　メモリ２５には、プロトコル処理を実行するプログラム２８及びＷｅｂサーバ４からメッセージを受け取り、３ＰＣＣサーバ３やプレゼンスサーバ５の間の相互接続機能を実行するプログラム２９が記憶されている。メモリ２５には、さらに他のプログラムが記憶されてもよい。

　ＣＰＵ２４は、メモリ２５に記憶されたプログラムを実行するプロセッサである。以下の説明においてアプリケーションサーバ２が実行する処理は、実際には、ＣＰＵ２４がいずれかのプログラムを実行することによって実行される。

　プロトコル処理を実行するプログラム２８は、ＷＥＢサーバ４との間で信号を送信または受信するための機能を備えるプログラム、及び、３ＰＣＣサーバ３やプレゼンスサーバ５との間で信号を送信または受信するための機能を備えるプログラムを含む。例えば、ＷＥＢサーバ４とアプリケーションサーバ２がＳＯＡＰ　ｏｖｅｒ　ＨＴＴＰで通信を行う場合、ＳＯＡＰ制御部とＨＴＴＰプロトコル制御部を用いて通信を行う。また、アプリケーションサーバ２と３ＰＣＣサーバ３がＨＴＴＰで通信を行う場合、ＨＴＴＰプロトコル制御部を用いて通信を行う。

　なお、図２には、通信プロトコルとしてＨＴＴＰとＳＯＡＰを示した。しかし、本発明を実施する際に、ＨＴＴＰ、ＳＯＡＰ以外のプロトコルを利用してもよい。

　相互接続機能を実行するプログラム２９は、セッション情報テーブル２１０、トリガルール２２０、メッセージルール２３０、パラメータルール２４０、付加情報処理エンジン２５０、サービス判定ルーチン２６０、変換エンジン２７を含む。データベース２６が、セッション情報テーブル２１０、トリガルール２２０、メッセージルール２３０、パラメータルール２４０を含んでもよい。

　アプリケーションサーバ２が、トリガルール２２０、メッセージルール２３０、パラメータルール２４０、サービス判定ルーチン２６０を備えることによって、アプリケーションサーバ２はＷＥＢサーバ４から受信した要求に応じたサービス機能を制御することが可能になる。ここで、サービス機能は、プレゼンスサーバ５や３ＰＣＣサーバ３で実現される。サービス機能をイネーブラとよぶこともある。

　さらに、アプリケーションサーバ２が、付加情報処理エンジン２５０を備えることにより、カスタマイズ機能や高速化が必要な機能の制御が可能になる。

　図７は、本発明の第１の実施の形態におけるサービス判断ルーチン２６０を示す説明図である。

　図５Ａは、本発明の第１の実施の形態のセッション情報テーブル２１０の構成の一例を示す説明図である。アプリケーションサーバ２は、ＷＥＢサーバ４から要求を受信すると、セッション情報テーブル２１０を参照、及び、更新する。

　セッション情報テーブル２１０は、少なくてもＰａｒｌａｙ　Ｘの呼セッション識別子（Ｐａｒｌａｙ　Ｘ　ｃａｌｌ　ｓｅｓｓｉｏｎ　Ｉｄｅｎｔｉｆｉｅｒ）２１１に対応するＷＥＢサーバアドレス２１２、イネーブラのアドレス２１３、トリガルール２１４を格納する。さらに、セッション情報テーブル２１０がセッション状態２１５を格納してもよい。セッション情報テーブル２１０がトリガルール２１４を含むことにより、アプリケーションサーバ２は、起動すべきサービス機能を迅速に検出することが可能になる。セッション情報テーブル２１０にセッション状態２１５を含むことにより、アプリケーションサーバがセッション状態を保持することが可能になる。

　図５Ｂは、本発明の第１の実施の形態のトリガルール２２０の構成の一例を示す説明図である。

　トリガルール２２０は、少なくてもＰａｒｌａｙ　Ｘ　ＡＰＩのｎａｍｅｓｐａｃｅ２２１に対応するトリガルール２２２とイネーブラＩＰアドレス２２３を格納する。アプリケーションサーバ２は、ＷＥＢサーバ４から要求を受信すると、受信メッセージからｎａｍｅｓｐａｃｅを抽出し、ｎａｍｅｓｐａｃｅ２２１に対応するトリガルール２２２を特定する。さらに、該当エントリに対応するイネーブラＩＰアドレス２２３を抽出し、要求メッセージに対応したサービス機能を有するサーバのアドレス情報を特定する。
　トリガルール２２０は、さらに、付加情報処理有無２２４を格納してもよい。
　トリガルール２２０が付加情報処理有無２２４を含むことにより、アプリケーションサーバ２はトリガルール毎のカスタマイズ処理や高速化処理を特定することが可能になる。

　図６Ａは、本発明の第１の実施の形態のメッセージルール２３０の構成の一例を示す説明図である。アプリケーションサーバ２は、トリガルールを特定した後、トリガルールに応じたメッセージルールを参照し、Ｐａｒｌａｙ　Ｘメッセージ２３１とＳＩＰメッセージ２３２の変換を行う。

　メッセージルール２３０は、少なくてもＰａｒｌａｙ　Ｘメッセージ２３１に対応するＳＩＰメッセージ２３２を格納する。メッセージルール２３０は、さらに、パラメータ変換処理の有無を示すフラグ２３３を格納してもよい。
　メッセージルール２３０がパラメータ変換処理の有無を示すフラグ２３３を含むことにより、アプリケーションサーバ２はメッセージに含まれるパラメータの変換要否の判断を行うことが可能になる。

　図６Ｂは、本発明の第１の実施の形態のパラメータルール２４０の構成の一例を示す説明図である。パラメータルール２４０は、少なくてもＰａｒｌａｙ　Ｘのパラメータ２４１に対応するＳＩＰパラメータ２４２を格納する。本テーブルを備えることにより、アプリケーションサーバ２は、Ｐａｒｌａｙ　ＸパラメータとＳＩＰパラメータの変換を行うことが可能になる。

　アプリケーションサーバ２は、メッセージルール２３０を参照の結果パラメータ変換が必要と判断すると、メッセージに含まれるＰａｒｌａｙ　Ｘパラメータを検索キーとして、パラメータルール２４０を参照する。パラメータルール２４０に該当エントリが存在する場合、アプリケーションサーバ２はＰａｒｌａｙ　ＸのパラメータとＳＩＰメッセージのパラメータ（ＳＩＰ　ｈｅａｄｅｒ）の変換を行う。

　図３は、本発明の第１の実施の形態における３ＰＣＣサーバ３の構成例を示す説明図である。

　３ＰＣＣサーバ３は、回線３２（３２ａ、３２ｂ）を収容するインタフェース部（ＩＦ）３１（３１ａ、３１ｂ）と、ＣＰＵ３４と、メモリ３５と、データベース（ＤＢ）３６とによって構成される。各構成要素は、バス３３で接続される。

　メモリ３５には、プロトコル処理を実行するプログラム３８（ＳＩＰプロトコル制御、ＨＴＴＰプロトコル制御）、３ＰＣＣサーバ処理を実行するプログラム３９（ＳＩＰ　Ｕｓｅｒ　Ａｇｅｎｔ処理を行うプログラム、３ＰＣＣ制御処理を行うプログラム）が記憶されている。メモリ３５には、さらに他のプログラムが記憶されていてもよい。

　ＣＰＵ３４は、メモリ３５に記憶されたプログラムを実行するプロセッサである。以下の説明において３ＰＣＣサーバ３が実行する処理は、実際には、ＣＰＵ３４がいずれかのプログラムを実行することによって実行される。

　プロトコル処理を実行するプログラム３８は、ＳＩＰサーバ１との間で信号を送信または受信するための機能を備えるプログラム（ＳＩＰプロトコル制御）、及び、アプリケーションサーバ２との間で信号を送信または受信するための機能を備えるプログラム（ＨＴＴＰプロトコル制御）を含む。なお、図３には、通信プロトコルとしてＨＴＴＰとＳＩＰを示した。しかし、本発明を実施する際、ＨＴＴＰ以外の通信プロトコルを利用して、３ＰＣＣサーバ３とアプリケーションサーバ２が通信を行ってもよい。

　３ＰＣＣサーバ処理を実行するプログラム３９は、ＳＩＰ　Ｕｓｅｒ　Ａｇｅｎｔ処理を行うプログラム、３ＰＣＣ制御処理を行うプログラムを含む。さらに、３ＰＣＣ制御処理を行うプログラムのほかに、Ｐａｒｌａｙ　Ｘ側のセッション識別子と３ＰＣＣセッションの識別子の対応情報を備えてもよい。さらに、３ＰＣＣサーバ３のメモリ３５は、３ＰＣＣサーバ処理に必要な情報を含んでもよい。３ＰＣＣサーバ処理に必要な情報は、ＤＢ３６に格納されてもよい。

　図４は、本発明の第１の実施の形態におけるプレゼンスサーバ５の構成例を示す説明図である。

　プレゼンスサーバ５は、回線５２（５２ａ、５２ｂ）を収容するインタフェース部（ＩＦ）５１（５１ａ、５１ｂ）と、ＣＰＵ５４と、メモリ５５と、データベース（ＤＢ）５６とによって構成される。各構成要素は、バス５３で接続される。

　メモリ５５には、プロトコル処理を実行するプログラム５８（ＳＩＰプロトコル制御、ＨＴＴＰプロトコル制御）、プレゼンスサーバ処理を実行するプログラム５９（ＳＩＰ　Ｕｓｅｒ　Ａｇｅｎｔ処理を行うプログラム、プレゼンス制御処理を行うプログラム）が記憶されている。メモリ５５には、さらに他のプログラムが記憶されてもよい。さらに、メモリ５５は、プレゼンス制御処理に必要な情報を含んでもよい。プレゼンス制御処理に必要な情報は、ＤＢ５６に格納されてもよい。

　ＣＰＵ５４は、メモリ５５に記憶されたプログラムを実行するプロセッサである。以下の説明においてプレゼンスサーバ５が実行する処理は、実際には、ＣＰＵ５４がいずれかのプログラムを実行することによって実行される。

　プロトコル処理を実行するプログラム５８は、ＳＩＰサーバ１との間で信号を送信または受信するための機能を備えるプログラム（ＳＩＰプロトコル制御）、及び、アプリケーションサーバ２との間で信号を送信または受信するための機能を備えるプログラム（ＨＴＴＰプロトコル制御）を含む。なお、図４には、通信プロトコルとしてＨＴＴＰとＳＩＰを示した。しかし、本発明を実施する際、ＨＴＴＰ以外の通信プロトコルを利用して、プレゼンスサーバ５とアプリケーションサーバ２が通信を行ってもよい。

　プレゼンスサーバ処理を実行するプログラム５９は、ＳＩＰ　Ｕｓｅｒ　Ａｇｅｎｔ処理を行うプログラム、プレゼンス制御処理を行うプログラムを含む。さらに、プレゼンス制御処理を行うプログラムのほかに、Ｐａｒｌａｙ　Ｘ側のセッション識別子とプレゼンスセッションの識別子の対応情報を備えてもよい。

　次に、図８、図９、図１０を参照して、図１に示すアクセス網Ｎ２ａに在圏する端末（７ａ）が３ＰＣＣサービスを起動するシーケンスを説明する。

　第１の実施の形態の端末７ａを用いるユーザが、ＷＥＢサーバ４にアクセスし（Ｓ０）、端末７ｂと間の３ＰＣＣサービスの起動を要求する場合のシーケンスを説明する。
　ＷＥＢサーバ４は端末７ａから３ＰＣＣサービスの起動要求を受信する。ＷＥＢサーバ４はアプリケーションサーバ２へ、端末７ａと端末７ｂとの間のセッション確立を要求するメッセージ（ｍａｋｅ　ｃａｌｌ　ｓｅｓｓｉｏｎ　ｒｅｑｕｅｓｔ）を送信する（Ｓ１）。このセッション確立を要求するメッセージには、少なくても端末７ａと端末７ｂの識別子を含む。

　アプリケーションサーバ２は、上記セッション確立要求を受信すると、また、応答メッセージをＷＥＢサーバ４に送信する（Ｓ２）。

　応答メッセージ（ｍａｋｅ　ｃａｌｌ　ｓｅｓｓｉｏｎ　ｒｅｓｐｏｎｓｅ）は、ＷＥＢサーバ４とアプリケーションサーバ２間のセッションを識別するため、ｃａｌｌ　ｓｅｓｓｉｏｎ　ｉｄｅｎｔｉｆｉｅｒを含む。アプリケーションサーバ２がＣａｌｌ　ｓｅｓｓｉｏｎ　ｉｄｅｎｔｉｆｉｅｒを生成する。
　ここで、アプリケーションサーバ２は、ｃａｌｌ　ｓｅｓｓｉｏｎ　ｉｄｅｎｔｉｆｉｅｒを検索キーとして、セッション情報テーブル２１０を検索する。該当エントリがなければ、新規エントリ２１０－１を選択し、該当エントリのＷｅｂサーバアドレス２１２にＷＥＢサーバ４のアドレスを登録する。

　続いて、アプリケーションサーバ２は、サービス判断ルーチン２６０を起動する。セッション確立要求メッセージＳ１を受信すると（２６１）、アプリケーションサーバ２は受信メッセージに含まれるｎａｍｅｓｐａｃｅを検索キーとして、トリガルール２２０を検索する（２６２）。該当するエントリがある場合（例えばエントリ２２０－ｎ）、該当エントリのトリガルール、及び、イネーブラＩＰアドレスを読み出し、セッション情報テーブル２１０の該当エントリ２１０－１のイネーブラＩＰアドレス２１３、トリガルール２１４に設定する（２６３）。さらに、トリガルール２２０の該当エントリの付加情報処理有無２２４に「有」が設定される場合、アプリケーションサーバは、ｎａｍｅｓｐａｃｅに応じた付加処理を実行する（２７１）。付加処理の例として、例えば拡張パラメータの追加・削除や通信ログの収集等がある。アプリケーションサーバ２が追加処理を行うことにより、サービス特有処理や通信事業者特有処理の実現が可能になる。トリガルール２２０の該当エントリの付加情報処理有無２２４に「無」が設定される場合、本ステップでの追加処理は行わない（２６４）。

　図７に戻り、サービス制御ルーチン２６０の説明を継続する。アプリケーションサーバ２はステップ２６３で決定したメッセージルール２３０を参照する。メッセージルール２３０は、トリガルール毎に存在し、トリガテーブル２２０のエントリ２２２の値で識別する。メッセージルール２３０は、少なくてもＰａｒｌａｙ　Ｘメッセージ２３１と対応するＳＩＰメッセージ２３２と、パラメータ変換有無２３３の対応情報を格納する。アプリケーションサーバ２は、上記メッセージルールに従って、メッセージの変換処理を行う（２６６）。さらに、パラメータ変換有無２３３に「有」が設定されている場合、アプリケーションサーバ２は受信メッセージに含まれるパラメータを検索キーとして、パラメータルール２４０を検索する（２６７）。パラメータが複数存在する場合は、全パラメータについて、該当するエントリの有無を確認する。該当するエントリが存在する場合、該当メッセージに含まれるパラメータをエントリに従って変換する（２６８）。

　メッセージ、および、パラメータの変換が終了すると、アプリケーションサーバ２は、セッション情報テーブル２１０を参照し、ステップＳ１受信時に生成したエントリからイネーブラＩＰアドレス（例　３ｐｃｃ－ｉｐ）を読み出す。ここで、アプリケーションサーバ２は、該当エントリ２１０－１のセッション状態２１５に、「サービス起動中」の状態を設定してもよい。

　その後、アプリケーションサーバ２は、３ＰＣＣサーバ３のアドレスである上記イネーブラＩＰアドレス宛に、メッセージおよびパラメータ変換後のメッセージ（ＳＩＰアプリケーションサーバ起動要求）を送信する（２６９、Ｓ３）。本ＳＩＰアプリケーションサーバ起動要求は、Ｐａｒｌａｙ　Ｘ　ｃａｌｌ　ｓｅｓｓｉｏｎ　ｉｄｅｎｔｉｆｉｅｒを含む。

　アプリケーションサーバ２は、前記イネーブラ（３ＰＣＣサーバ３）から応答メッセージを受信すると（Ｓ４）、本ルーチンを終了する（２７２）。
　ステップ２６２、ステップ２６５において、該当エントリが存在しない場合は、エラー処理を行い、本ルーチンを終了する（２７３）。ステップ２７０において、アプリケーションサーバ２が一定時間内に応答を受信しなかった場合、エラー処理を行い、本ルーチンを終了する（２７３）。

　すなわち、図８において、Ｓ１を受信したアプリケーション２は、メッセージルール２３０を参照し、Ｐａｒｌａｙ　Ｘメッセージ“ｍａｋｅ　ｃａｌｌ　ｓｅｓｓｉｏｎ　ｒｅｑｕｅｓｔ”をＳＩＰメッセージ“ＩＮＶＩＴＥ”に変換する。また、パラメータルール２４０を参照して、ｍａｋｅ　ｃａｌｌ　ｓｅｓｓｉｏｎ　ｒｅｑｕｅｓｔに含まれるパラメータをＳＩＰ　ＩＮＶＩＴＥに含まれるパラメータに変換（例えば、端末７ａ、７ｂの識別子を設定するパラメータ　ｃａｌｌ　ｐａｒｔｉｃｉｐａｎｔをＲｅｑｕｅｓｔ　ＵＲＩに変換）する。メッセージ、および、パラメータの変換の際、アプリケーションサーバ２は変換エンジン２７を利用する。アプリケーションサーバ２は、３ＰＣＣサーバ３に変換後のメッセージを含むＳＩＰアプリケーションサーバ起動要求を送信する。

　図８に戻り、シーケンスの説明を続ける。３ＰＣＣサーバ３は、ＳＩＰアプリケーションサーバ起動要求Ｓ３を受信すると、３ＰＣＣ制御を起動して、例えばＳＩＰベースの３ＰＣＣ制御を行う。ここで、３ＰＣＣサーバ３は、端末７ａと端末７ｂとの間の通信を識別するための３ＰＣＣ識別子を生成する。３ＰＣＣサーバ３はセッションを確立している間、３ＰＣＣ識別子を保持する。

　図３において説明したように、３ＰＣＣ制御はメモリ３５に格納され、ＣＰＵ３４によって実行されるプログラムである。

　３ＰＣＣサービスは、３ＰＣＣ制御、ＳＩＰ　Ｕｓｅｒ　Ａｇｅｎｔ制御、ＳＩＰプロトコル制御により提供される。３ＰＣＣサーバは、まず端末７ａにセッション確立を要求する（Ｓ５－Ｓ１０）。セッション確立要求のためのＳＩＰメッセージとして、例えばＩＮＶＩＴＥを利用する。端末７ａはセッション確立要求を受け付けると２００　ＯＫで応答する。３ＰＣＣサーバ３は、応答確認ＡＣＫを端末７ａに送信する。
　次に、３ＰＣＣサーバ３は端末７ｂにセッション確立を要求する（Ｓ１１－Ｓ１６）。さらに、端末７ａに、端末７ｂとの間のメディア情報の更新を要求する（Ｓ１７－Ｓ２２）。以上の処理により端末７ａと端末７ｂとの間の通信が可能になる（Ｓ２３）。

　３ＰＣＣサーバ３は、ステップＳ２１のセッション確立応答への確認信号（ＡＣＫ）を送信後、アプリケーションサーバ２へ「セッション確立通知」信号でセッションを通知する（Ｓ２７）。上記「セッション確立通知」Ｓ２７は、ステップＳ３で受信したｐａｒｌａｙ　Ｘ　ｃａｌｌ　ｓｅｓｓｉｏｎ　ｉｄｅｎｔｉｆｉｅｒを含む。アプリケーションサーバ２は、ステップＳ２７の信号に含まれるＰａｒｌａｙ　Ｘ　Ｃａｌｌ　ｓｅｓｓｉｏｎ　ｉｄｅｎｔｉｆｉｅｒを検索し、セッション情報テーブル２１０の該当エントリ２１０－１のセッション状態２１５を「セッション確立中」に変更する。

　アプリケーションサーバ２は、上記信号を受信すると、３ＰＣＣサーバ３へＳ２７の受信確認信号「セッション確立通知応答」Ｓ２８を送信する。

　ＷＥＢサーバ４はアプリケーションサーバ２に３ＰＣＣサービスの状態を確認するために、状態問い合わせ要求（ｇｅｔ　Ｃａｌｌ　Ｓｅｓｓｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒｅｑｕｅｓｔ）を送信する（Ｓ２９）。上記要求の送信タイミングは、ＷＥＢサーバ側の設定値に依存する。

　アプリケーションサーバ２は、上記要求に含まれるｃａｌｌ　Ｓｅｓｓｉｏｎ　Ｉｄｅｎｔｉｆｉｅｒ　を検索キーとして、セッション情報テーブル２１０を検索する。該当エントリ２１０－１から、セッション状態２１５を読み出す。アプリケーションサーバ２は、セッション状態を含む応答メッセージ（ｇｅｔ　Ｃａｌｌ　Ｓｅｓｓｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　ｒｅｓｐｏｎｓｅ）をＷＥＢサーバ４に送信する（Ｓ３０）。

　ここで、端末７ａと端末７ｂが通信を行っている間、通信が正常に行われているか確認するため、３ＰＣＣサーバ３が端末７（端末７ａ、端末７ｂ）へ定期的にメッセージを送信してもよい。定期的に送信するメッセージとして、例えば、ＳＩＰ　ＩＮＶＩＴＥメッセージを利用する。図９は、３ＰＣＣサーバ３が端末７に定期的にＳＩＰ　ＩＮＶＩＴＥメッセージを送信する場合のシーケンスを示す。３ＰＣＣサーバ３がＳＩＰサーバ１経由で端末７ａにＩＮＶＩＴＥメッセージを送信する（Ｓ３１、Ｓ３２）。端末７ａは上記メッセージを受信すると応答メッセージ２００（Ｓ３３、Ｓ３４）を送信する。３ＰＣＣ３は上記応答メッセージへの確認メッセージ（Ｓ３５、Ｓ３６）を送信する。３ＰＣＣサーバ３と端末７ａの間で、本シーケンスを定期的（例えば、タイマＴ１）に繰り返す（Ｓ５１～Ｓ５６）。これにより、通信が正常に行われているかを確認する。タイマ値Ｔ１は、セッション確立時にＳＩＰメッセージを用いて決定する。

　３ＰＣＣサーバ３と端末７ｂの間でも同様のメッセージを送受信する（Ｓ３７～Ｓ４１、Ｓ５７～Ｓ６２）。タイマ値Ｔ２は、セッション確立時にＳＩＰメッセージを用いて決定する。

　本実施の形態では、セッション確立用の通信プロトコルにＳＩＰを用いている。本発明を実施する際、ＳＩＰ以外の通信プロトコルを利用して３ＰＣＣサーバ３と端末７が通信を行ってもよい。

　次に、図１０を用いて、通信終了時の処理を説明する。端末７ａがＷＥＢサーバ４に通信終了要求を送信する場合を示す。上記通信終了要求は、例えば、端末７を利用するユーザが、ＷＥＢサーバ４が提供するＷＥＢ画面上の通信終了ボタンを選択することによって、起動される（Ｓ７０）。

　Ｗｅｂサーバ４は、３ＰＣＣ通信の終了要求「ｅｎｄ　ｃａｌｌ　ｓｅｓｓｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒｅｑｕｅｓｔ」をアプリケーションサーバ２に送信する（Ｓ７１）。上記メッセージは、Ｐａｒｌａｙ　Ｘ　ｃａｌｌ　Ｓｅｓｓｉｏｎ　Ｉｄｅｎｔｉｆｉｅｒを含む。

　ここで、アプリケーションサーバ２は、Ｐａｒｌａｙ　Ｘ　ｃａｌｌ　Ｓｅｓｓｉｏｎ　Ｉｄｅｎｔｉｆｉｅｒを検索キーとして、セッション情報テーブル２１０を検索する。該当エントリ２１０－１から、イネーブラＩＰアドレス２１３とトリガルールを読み出すと共に、セッション状態２１５を「切断中」に更新する。

　次に、アプリケーションサーバ２は、上記メッセージを受信するとサービス判断ルーチン２６０を起動する。アプリケーションサーバ２は、上記メッセージに含まれる「ｎａｍｅｓｐａｃｅ」を検索キーとして、トリガルール２２０を参照する。該当するエントリが存在すれば、アプリケーションサーバ２は、該当エントリの付加情報処理有無２２４を参照する。該エントリに「有」が設定されている場合、アプリケーションサーバ２は、ｎａｍｅｓｐａｃｅに応じた付加処理を実行する。

　さらに、アプリケーションサーバ２はトリガルールに対応するメッセージルールテーブル２３０を参照する。アプリケーションサーバ２は、ステップＳ７１で受信したＰａｒｌａｙ　Ｘメッセージを検索キーとして、トリガルールテーブル２３０を検索する。ここで、該当エントリ２３０－２から、対応するＳＩＰメッセージ名２３２（ＢＹＥ）とパラメータ変換の有無２３３（無）を読み出す。次にアプリケーションサーバ２は、変換エンジン２７を利用して、メッセージ、および、パラメータの変換を行う。この後、アプリケーションサーバ２は、メッセージ変換後の終了要求メッセージをイネーブラＩＰアドレス２１３に設定されている宛先「３ｐｃｃ－ｉｐ」に送信する（Ｓ７３）
　３ＰＣＣサーバ３は、上記要求を受信すると、応答メッセージ「終了要求応答」をアプリケーションサーバ２へ送信する。また、３ＰＣＣサーバ３は、端末７ａと端末７ｂにそれぞれＳＩＰのセッション終了メッセージ（ＢＹＥ）を送信する（Ｓ７５からＳ８２）。

　３ＰＣＣサーバ３は、端末７との間のセッションが終了すると、アプリケーションサーバ２へセッション切断を通知する（セッション切断通知メッセージ　Ｓ８３）。上記メッセージには、Ｐａｒｌａｙ　Ｘ　ｃａｌｌ　ｓｅｓｓｉｏｎ　ｉｄｅｎｔｉｆｉｅｒが含まれる。アプリケーションサーバ２は、上記メッセージを受信すると、Ｐａｒｌａｙ　Ｘ　ｃａｌｌ　ｓｅｓｓｉｏｎ　ｉｄｅｎｔｉｆｉｅｒを検索キーとして、セッション情報テーブル２１０を検索する。アプリケーションサーバ２は、該当エントリを検索し、セッション状態２１５を「切断終了」に変更する。次に、アプリケーションサーバ２は、上記メッセージＳ８３への応答メッセージＳ８４を３ＰＣＣサーバ３へ送信する。

　この後、アプリケーションサーバ２は、セッション情報エントリの該当エントリ２１０を一定期間保持する（一定時間後、該当エントリを削除する）。

　アプリケーションサーバ２が該当エントリを保持している間に、ＷＥＢサーバ４からアプリケーションサーバ２へ情報問合せ「ｇｅｔ　Ｃａｌｌ　Ｓｅｓｓｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　ｒｅｑｕｅｓｔ」Ｓ８５を受信した場合、該当メッセージに含まれるｃａｌｌ　ｓｅｓｓｉｏｎ　ｉｄｅｎｔｉｆｉｅｒを検索キーとして、セッション情報テーブル２１０を検索する。アプリケーションサーバ２は、該当エントリのセッション情報の値を読み出し、セッション状態「切断終了」を含む応答メッセージ「ｇｅｔ　Ｃａｌｌ　Ｓｅｓｓｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　ｒｅｓｐｏｎｓｅ」Ｓ８６をＷＥＢサーバ４へ送信する。

　アプリケーションサーバ２は、一定時間経過後（セッション情報テーブルの該当エントリを消去した後）に「ｇｅｔ　Ｃａｌｌ　Ｓｅｓｓｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　ｒｅｑｕｅｓｔ」Ｓ８５を受信すると、セッション情報テーブルに該当エントリが存在しない。この場合、アプリケーションサーバ２はＷＥＢサーバ４へ、セッション状態「該当なし」を含む応答メッセージ「ｇｅｔ　Ｃａｌｌ　Ｓｅｓｓｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　ｒｅｓｐｏｎｓｅ」Ｓ８６を送信する。上記要求Ｓ８５の送信タイミングは、ＷＥＢサーバ４側の設定値に依存する。

　本実施の形態では、イネーブラとして、３ＰＣＣサーバ３を利用する例を示した。本発明を実施する際、３ＰＣＣサーバ以外のＳＩＰアプリケーションサーバをイネーブラとして利用してもよい。３ＰＣＣサーバ以外のイネーブラとして、例えばプレゼンスサーバ５がある。

　なお、第１の実施の形態において、アプリケーションサーバ２と３ＰＣＣサーバ３、およびプレゼンスサーバ５は、ブレードサーバなどのように同一筺体の装置上で実現されてもよい。

　本発明の第１の実施の形態によると、アプリケーションサーバ２がトリガルール、パラメータルールを備え、異なるメッセージ（例：Ｐａｒｌａｙ　Ｘ　メッセージとＳＩＰメッセージ）の間で、メッセージ変換およびパラメータ変換を行うことが可能になる。さらに、トリガルールテーブルを用いて、付加情報処理有無を判断することにより、アプリケーションサーバ２において、独自パラメータの拡張やメッセージ高速化処理など、付加情報処理を行うことが可能になる。これにより、通信事業者やサービス提供者が、サービスを柔軟に提供することが可能になる。

　次に、本発明の第２の実施の形態を、図面を用いて説明する。

　上記の第１の実施の形態では、アプリケーションサーバ２がメッセージルールとパラメータルールを提供した。これに対して第２の実施の形態ではプレゼンスサーバ５や３ＰＣＣサーバ３がメッセージルールとパラメータルールを備えることを特徴とする。プレゼンスサーバ５や３ＰＣＣサーバ３がメッセージルールとパラメータルールを備えることにより、アプリケーションサーバ２はサービス機能の振り分け処理と、付加機能の高速化処理に注力することが可能になる。

　本発明の第２の実施の形態の通信網は、第１の実施の形態と同様であるため、説明を省略する（図１参照）。以下、本発明の第２の実施の形態が第１の実施の形態と相違する点についてのみ説明する。

　図１１は、本発明の第２の実施の形態におけるアプリケーションサーバ２の構成例を示す説明図である。

　第２の実施の形態において、メモリ２５はメッセージルール、パラメータルール、変換エンジンは備えない。これらの機能は、プレゼンスサーバ５や３ＰＣＣサーバ３が備える。また、アプリケーションサーバ２は、サービス判断ルーチン２６０のかわりに、サービス判断ルーチン２８０を備える。

　本実施の形態において、アプリケーションサーバ２はサービス機能の振り分け処理と、付加機能の高速化処理に注力することが可能になる。

　図１２は、本発明の第２の実施の形態における３ＰＣＣサーバ３の構成例を示す説明図である。第２の実施の形態において、３ＰＣＣサーバ３のメモリ３５は第１の実施の形態に加えて、メッセージルール３３０、パラメータルール３４０、メッセージ・パラメータ変換ルーチン３５０、変換エンジン３７を備える。

　３ＰＣＣサーバ３がメッセージルールとパラメータルールと変換エンジンを備えることにより、アプリケーションサーバ２はサービス機能の振り分け処理と、付加機能の高速化処理に注力できる。また、本実施の形態において、システム運用者は、３ＰＣＣサービス用のパラメータ拡張などの３ＰＣＣサービス特有の機能追加をアプリケーションサーバ２に影響を与えることなく実現することが可能になる。

　図１３は、本発明の第２の実施の形態におけるプレゼンスサーバ５の構成例を示す説明図である。第２の実施の形態において、プレゼンスサーバ５のメモリ５５は第１の実施の形態に加えて、メッセージルール５３０、パラメータルール５４０、メッセージ・パラメータ変換ルーチン３５０、変換エンジン５７を備える。

　プレゼンスサーバ５がメッセージルールとパラメータルールと変換エンジンを備えることにより、アプリケーションサーバ２はサービス機能の振り分け処理と、付加機能の高速化処理に注力できる。また、本実施の形態において、システム運用者は、プレゼンスサービス用のパラメータ拡張などのプレゼンスサービス特有の機能追加をアプリケーションサーバ２に影響を与えることなく実現することが可能になる。

　図１４は、本発明の第２の実施の形態におけるサービス判断ルーチン２８０を示す説明図である。第２の実施の形態におけるサービス判断ルーチン２８０は、第１の実施の形態におけるメッセージ変換、および、パラメータ変換のステップを含まない。

　図１５は、本発明の第２の実施の形態におけるメッセージ・パラメータ変換ルーチン３５０を示す説明図である。イネーブラ（例えば３ＰＣＣサーバ３、プレゼンスサーバ５）が前記メッセージ・パラメータ変換ルーチン３５０を備える。

　次に、第２の実施の形態において、図１に示すアクセス網Ｎ２ａに在圏する端末（７ａ）が３ＰＣＣサービスを起動するシーケンスを説明する。シーケンス図は第１の実施の形態と同様であるため、第２の実施の形態のシーケンスは、図８、図９、図１０を参照して、第１の実施の形態と異なる部分のみ説明する。

　ステップＳ１、Ｓ２は第１の実施の形態と同様である。

　続いて、アプリケーションサーバ２は、サービス判断ルーチン２８０を起動する。セッション確立要求メッセージＳ１を受信すると（２８１）、アプリケーションサーバ２は受信メッセージに含まれるｎａｍｅｓｐａｃｅを検索キーとして、トリガルール２２０を検索する（２８２）。該当するエントリがある場合（例えばエントリ２２０－１）、該当エントリのトリガルール、及び、イネーブラＩＰアドレスを読み出し、セッション情報テーブル２１０の該当エントリ２１０－１のイネーブラＩＰアドレス２１３、トリガルール２１４に設定する（２８３）。さらに、トリガルール２２０の該当エントリの付加情報処理有無２２４に「有」が設定される場合、アプリケーションサーバ２は、ｎａｍｅｓｐａｃｅに応じた付加処理を実行する（２８８）。付加処理の例として、例えば拡張パラメータの追加・削除や通信ログの収集等がある。アプリケーションサーバ２が追加処理を行うことにより、サービス特有機能や通信事業者特有機能の実現が可能になる。

　トリガルール２２０の該当エントリの付加情報処理有無２２４に「無」が設定される場合、本ステップでの追加処理は行わない（２８４）。ステップ２８２において、該当エントリが存在しない場合、エラー処理を実施し（２８９）、本ルーチンを終了する。

　続いて、アプリケーションサーバ２は、ステップＳ１受信時に生成したセッション情報テーブル２１０のエントリ２１０－１からイネーブラＩＰアドレス（例　３ｐｃｃ－ｉｐ）を読み出す。ここで、アプリケーションサーバ２は、該当エントリ２１０－１のセッション状態２１５に、「サービス起動中」の状態を設定してもよい。

　アプリケーションサーバ２は、上記イネーブラＩＰアドレス（３ＰＣＣサーバ３）宛に、ＳＩＰアプリケーションサーバ起動要求Ｓ３を送信する（２８５）。本ＳＩＰアプリケーションサーバ起動要求には、Ｐａｒｌａｙ　Ｘ　ｃａｌｌ　ｓｅｓｓｉｏｎ　ｉｄｅｎｔｉｆｉｅｒを含む。

　３ＰＣＣサーバ３は、上記ＳＩＰアプリケーションサーバ起動要求Ｓ３を受信すると、メッセージ・パラメータ変換ルーチン３５０を起動する（３５１）。

　３ＰＣＣサーバ３はメモリ３５からメッセージルール３３０を参照する。メッセージルール３３０は、少なくてもＰａｒｌａｙ　Ｘメッセージ３３１と対応するＳＩＰメッセージ３３２と、パラメータ変換有無３３３の対応情報を格納する。３ＰＣＣサーバ３は、上記メッセージルールに従って、メッセージの変換処理を行う（３５３）。３ＰＣＣサーバ３は、メッセージ変換を行う場合、変換エンジン３７を利用してもよい。

　さらに、パラメータ変換有無３３３に「有」が設定されている場合、３ＰＣＣサーバ３は受信メッセージに含まれるパラメータを検索キーとして、パラメータルール３４０を検索する（３５４）。パラメータが複数存在する場合は、全パラメータについて、該当するエントリの有無を確認する。該当するエントリが存在する場合、該当メッセージに含まれるパラメータをパラメータ変換テーブルに従って変換する（３５５）。

　メッセージ、および、パラメータの変換が終了すると、３ＰＣＣサーバ３は本ルーチンを終了する（３５６）。ステップ３５２において、該当するメッセージルールがない場合、エラー処理を行い、本ルーチンを終了する（３５７）。

　続いて、３ＰＣＣサーバ３は３ＰＣＣ制御を起動して、例えばＳＩＰベースの３ＰＣＣ制御を行う。以降、ステップＳ５からＳ６２までの処理は、第１の実施の形態と同様である。

　次に、図１０を用いて、通信終了時の処理を、第１の実施の形態と異なる部分のみ説明する。

　アプリケーションサーバ２は、「ｅｎｄ　ｃａｌｌ　ｓｅｓｓｉｏｎ　ｉｎｆｏｒｍａｔｉｏｎ　ｒｅｑｕｅｓｔ」Ｓ７１を受信するとサービス判断ルーチン２８０を起動する。アプリケーションサーバ２は、上記メッセージに含まれる「ｎａｍｅｓｐａｃｅ」を検索キーとして、トリガルール２２０を参照する。該当するエントリが存在すれば、該当エントリの付加情報処理有無２２４を参照する。該エントリに「有」が設定される場合、アプリケーションサーバ２は、ｎａｍｅｓｐａｃｅに応じた付加情報処理を実行する。その後、アプリケーションサーバ２は、セッション情報テーブルの該当エントリからイネーブラＩＰアドレス２１３を読み出し、設定されている宛先「３ｐｃｃ－ｉｐ」に終了要求メッセージを送信する（Ｓ７３、２８５）。

　３ＰＣＣサーバ３は、上記終了要求メッセージＳ７３を受信すると、メッセージ・パラメータ変換ルーチン３５０を起動する。

　まず、３ＰＣＣサーバ３は、ステップＳ７１で受信したＰａｒｌａｙ　Ｘメッセージを検索キーとして、メッセージルールテーブル３３０を参照する。ここで、該当エントリ３３０－２から、対応するＳＩＰメッセージ３３２（ＢＹＥ）とパラメータ変換の有無３３３（無）を読み出す。パラメータの変更が不要の場合、本ルーチンを終了する。次に３ＰＣＣサーバ３は、変換エンジン３７を利用して、メッセージの変換を行う。続いて、３ＰＣＣサーバ３は、端末７ａと端末７ｂにそれぞれＳＩＰのセッション終了メッセージ（ＢＹＥ）を送信する（Ｓ７５からＳ８２）。以降の処理は、第１の実施の形態と同様である。図１６Ａに本実施の形態での３ＰＣＣサーバ３におけるメッセージルールの構成の一例を、図１６Ｂに３ＰＣＣサーバ３におけるパラメータルールの構成の一例を、各々示す。

　本実施の形態では、イネーブラとして、３ＰＣＣサーバ３を利用する例を示した。本発明を実施する際、３ＰＣＣサーバ以外のＳＩＰアプリケーションサーバをイネーブラとして利用してもよい。３ＰＣＣサーバ以外のイネーブラとして、例えばプレゼンスサーバ５がある。この場合、プレゼンスサーバ５がメッセージ・パラメータ変換ルーチン３５０を起動時に参照するテーブルは、メッセージルール５３０とパラメータルール５４０となる。

　本発明の第２の実施の形態によると、アプリケーションサーバ２がトリガルールを備え、プレゼンスサーバ５、および、３ＰＣＣサーバ３がメッセージルールとパラメータルールを提供する。これにより、アプリケーションサーバ２はサービス機能の振り分け処理と、付加機能の高速化処理に注力することが可能になる。また、ＳＩＰアプリケーションサーバに特有の処理（例：特殊パラメータの追加）を３ＰＣＣサーバ３、或いは、プレゼンスサーバ５に閉じて実現することが可能になる。これにより、通信事業者やサービス提供者は、サービスの追加や拡張を行うことが可能になる。すなわち、サービスの迅速な提供やサービスのカスタマイズ化が可能になる。

　なお、第２の実施の形態において、アプリケーションサーバ２と３ＰＣＣサーバ３、およびプレゼンスサーバ５が、ブレードサーバなどのように同一筺体の装置上で実現されてもよい。
　上記記載は実施例についてなされたが、本発明はそれに限らず、本発明の精神と添付の請求の範囲の範囲内で種々の変更および修正をすることができることは当業者に明らかである。

　本発明を用いることによって、通信事業者やサービス提供者が、サービスを柔軟に提供することが可能になる。具体的には、アプリケーションサーバ２がトリガルール、パラメータルールを備え、異なるメッセージ（例：Ｐａｒｌａｙ　Ｘ　メッセージとＳＩＰメッセージ）の間で、メッセージ変換およびパラメータ変換を行うことが可能になる。さらに、トリガルールテーブルを用いて、付加情報処理有無を判断することにより、アプリケーションサーバにおいて、独自パラメータの拡張やメッセージ高速化処理など、付加情報処理を行うことが可能になる。

本発明の第１の実施の形態の通信網の構成例を示す説明図である。本発明の第１の実施の形態のアプリケーションサーバ２の構成例を示す説明図である。本発明の第１の実施の形態の３ＰＣＣサーバ３の構成例を示す説明図である。本発明の第１の実施の形態のプレゼンスサーバ５の構成例を示す説明図である。本発明の第１の実施のアプリケーションサーバ２におけるセッション情報テーブルの構成の一例を示す説明図である。本発明の第１の実施のアプリケーションサーバ２におけるトリガルールの構成の一例を示す説明図である。本発明の第１の実施のアプリケーションサーバ２におけるメッセージルールの構成の一例を示す説明図である。本発明の第１の実施のアプリケーションサーバ２におけるパラメータルールの構成の一例を示す説明図である。本発明の第１の実施の形態のアプリケーションサーバ２におけるサービス判断ルーチンを説明するフローチャートである。本発明の第１の実施の形態の３ＰＣＣサービスの手順を説明するシーケンス図である。本発明の第１の実施の形態の３ＰＣＣサービスの手順を説明するシーケンス図である。本発明の第１の実施の形態の３ＰＣＣサービスの手順を説明するシーケンス図である。本発明の第２の実施の形態のアプリケーションサーバ２の構成例を示す説明図である。本発明の第２の実施の形態の３ＰＣＣサーバ３の構成例を示す説明図である。本発明の第２の実施の形態のプレゼンスサーバ５の構成例を示す説明図である。本発明の第２の実施の形態のアプリケーションサーバ２におけるサービス判断ルーチンを説明するフローチャートである。本発明の第２の実施の形態のメッセージ・パラメータ変換ルーチンを説明するフローチャートである。本発明の第２の実施の形態の３ＰＣＣサーバ３におけるメッセージルールの構成の一例を示す説明図である。本発明の第２の実施の形態の３ＰＣＣサーバ３におけるパラメータルールの構成の一例を示す説明図である。

符号の説明

　２　アプリケーションサーバ
　３　３ＰＣＣサーバ
　５　プレゼンスサーバ
　２２０　トリガルール
　２３０　メッセージルール
　２４０　パラメータルール
　２６０　サービス判断ルーチン

Claims

　少なくとも１つの端末と、前記端末に通信サービスを提供するサービス制御サーバと、ユーザインタフェースを備えるウェブサーバと、前記ウェブサーバと前記サービス制御サーバとの通信回線を備えるアプリケーションサーバとを備えた通信システムであって、
　前記アプリケーションサーバは、前記ウェブサーバからサービス要求信号を受信するときに受信したサービス要求信号に含まれる識別子から対応するサービス機能を特定する手段と、特定したサービス機能に応じて受信メッセージを変換する手段と、受信したサービス要求信号に応じた前記サービス制御サーバを起動する手段とを有する通信システム。
　前記アプリケーションサーバは、さらに、サービス要求信号をセッション制御信号に変換する手段を備える請求項１に記載の通信システム。
　前記セッション制御信号がＳＩＰである請求項２に記載の通信システム。
　前記アプリケーションサーバは、サービス要求信号に対応した付加情報処理の有無を検出する手段をさらに有し、上記付加情報処理を検出した場合に上記付加情報処理に対応するプログラムを実現する手段を備える請求項１に記載の通信システム。
　前記サービス要求信号がＰａｒｌａｙ　Ｘ　ＡＰＩである請求項４に記載の通信システム。
　前記アプリケーションサーバは、Ｐａｒｌａｙ　Ｘ　ＡＰＩのサービス要求信号を受信した場合に、サービス機能を備えるサービス制御サーバをＰａｒｌａｙ　Ｘ　ＡＰＩに含まれるメッセージに応じて特定する請求項５に記載の通信システム。
　端末に通信サービスを提供するサービス制御サーバと、ユーザインタフェースを備えるウェブサーバとの通信回線を備え、
　前記ウェブサーバからサービス要求信号を受信するときに受信したサービス要求信号に含まれる識別子から対応するサービス機能を特定する手段と、特定したサービス機能に応じて受信メッセージを変換する手段と、受信したサービス要求信号に応じた前記サービス制御サーバを起動する手段とを有するアプリケーションサーバ。
　前記サービス要求信号を前記セッション制御信号に変換する手段を備える請求項７に記載のアプリケーションサーバ。
　前記セッション制御信号がＳＩＰである請求項８に記載のアプリケーションサーバ。
　サービス要求信号に対応した付加情報処理の有無を検出する手段をさらに有し、上記付加情報処理を検出した場合に上記付加情報処理に対応するプログラムを実現する手段を備える請求項７に記載のアプリケーションサーバ。
　前記サービス要求信号がＰａｒｌａｙ　Ｘ　ＡＰＩである請求項１０に記載のアプリケーションサーバ。
　Ｐａｒｌａｙ　Ｘ　ＡＰＩのサービス要求信号を受信した場合に、サービス機能を備えるサービス制御サーバをＰａｒｌａｙ　Ｘ　ＡＰＩに含まれるメッセージに応じて特定する請求項１１に記載のアプリケーションサーバ。
　少なくとも１つの端末と、前記端末に通信サービスを提供するサービス制御サーバと、ユーザインタフェースを備えるウェブサーバと、前記ウェブサーバと前記サービス制御サーバとの通信回線を備えるアプリケーションサーバとを備えた通信システムにおいて、
　前記アプリケーションサーバは、前記ウェブサーバからサービス要求信号を受信するときに受信したサービス要求信号に含まれる識別子から対応するサービス機能を特定する手段と、特定したサービス機能に応じて受信メッセージを変換する手段とを有し、受信したサービス要求信号に応じた前記サービス制御サーバを起動する通信方法。
　前記アプリケーションサーバは、さらに、サービス要求信号をセッション制御信号に変換する手段を備える請求項１３に記載の通信方法。
　少なくとも１つの端末と、前記端末に通信サービスを提供するサービス制御サーバと、ユーザインタフェースを備えるウェブサーバと、前記ウェブサーバと前記サービス制御サーバとの通信回線を備えるアプリケーションサーバとを備えた通信システムであって、
　前記アプリケーションサーバは、前記ウェブサーバからサービス要求信号を受信すると、受信したサービス要求信号に含まれる識別子から対応するサービス機能を特定する手段と、受信したサービス要求信号に応じた前記サービス制御サーバを起動する手段とを有し、
　前記サービス制御サーバが特定したサービス機能に応じて受信メッセージを変換する手段を有する通信システム。
　前記サービス制御サーバは、さらに、サービス要求信号をセッション制御信号に変換する手段を備える請求項１５に記載の通信システム。
　前記セッション制御信号がＳＩＰである請求項１６に記載の通信システム。
　前記アプリケーションサーバは、サービス要求信号に対応した付加情報処理の有無を検出する手段をさらに有し、上記付加情報処理を検出した場合に上記付加情報処理に対応するプログラムを実現する手段を備える請求項１５に記載の通信システム。
　前記サービス要求信号がＰａｒｌａｙ　Ｘ　ＡＰＩである請求項１８に記載の通信システム。
　前記アプリケーションサーバは、Ｐａｒｌａｙ　Ｘ　ＡＰＩのサービス要求信号を受信したとき、サービス機能を備えるサービス制御サーバをＰａｒｌａｙ　Ｘ　ＡＰＩに含まれるメッセージに応じて特定する請求項１９に記載の通信システム。