(57)【要約】【課題】  ネットワーク的に効率的なルーチングを確立できるプレゼンスサービスシステムを提供する。【解決手段】  Ｓ−ＣＳＣＦは、プレゼンスサーバへ、端末からの位置登録信号を転送する条件及び編集処理を規定した位置登録転送用情報を管理しており、任意の端末から位置登録信号が到来したとき、管理している位置登録転送用情報に従い、位置登録信号を編集してプレゼンスサーバに転送する。プレゼンスサーバは、外部から到来した位置登録信号と、ルーチングポリシー情報とから、その端末への信号のルーチング方法を規定する情報を形成して管理しており、かかる情報を管理している端末への信号におけるルーチング用情報を、管理しているルーチング方法に従って設定した後、信号を送信する。【選択図】      図１
2008131590.tif 000002
【特許請求の範囲】
【請求項１】
端末の位置管理やサービス制御を行うプロキシサーバかつレジストラサーバとして機能するサービングサーバにおいて、
プレゼンティティの状態管理、購読要求の受信、ウォッチャへの情報通知を実行するプレゼンスサーバへ、端末からの位置登録信号を転送する条件及び編集処理を規定した位置登録転送用情報を管理する位置登録転送用情報管理手段と、
任意の端末から位置登録信号が到来したとき、上記位置登録転送用情報管理手段で管理されている位置登録転送用情報に従い、位置登録信号を編集して上記プレゼンスサーバに転送する位置登録信号転送手段と
を有することを特徴とするサービングサーバ。
【請求項２】
プレゼンティティの状態管理、購読要求の受信、ウォッチャへの情報通知を実行するプレゼンスサーバにおいて、
外部から到来した任意端末から位置登録信号と、ルーチングポリシー情報とから、その端末への信号のルーチング方法を規定する情報を形成して管理するルーチング情報管理手段と、
上記ルーチング情報管理手段に情報が管理されている上記端末への信号におけるルーチング用情報を、上記ルーチング情報管理手段に管理されているルーチング方法に従って設定し、上記信号を送信する端末宛信号送信手段と
を有することを特徴とするプレゼンスサーバ。
【請求項３】
端末の位置管理やサービス制御を行うプロキシサーバかつレジストラサーバとして機能するサービングサーバと、プレゼンティティの状態管理、購読要求の受信、ウォッチャへの情報通知を実行するプレゼンスサーバとを有するプレゼンスサービスシステムにおいて、
上記サービングサーバとして、請求項１に記載のサービングサーバを適用すると共に、上記プレゼンスサーバとして、請求項２に記載のプレゼンスサーバを適用したことを特徴とするプレゼンスサービスシステム。
【請求項４】
ウォッチャアプリケーションを搭載し、所定端末のプレゼンス情報の購読要求を上記プレゼンスサーバに送信するアプリケーションサーバをさらに備え、
上記プレゼンスサーバの端末宛信号送信手段は、到来した購読要求におけるルーチング用情報を、ルーチング情報管理手段に管理されているルーチング方法に従って設定し、上記購読要求を送信する
ことを特徴とする請求項３に記載のプレゼンスサービスシステム。
【請求項５】
端末の位置管理やサービス制御を行うプロキシサーバかつレジストラサーバとして機能するサービングサーバと、プレゼンティティの状態管理、購読要求の受信、ウォッチャへの情報通知を実行するプレゼンスサーバとを有するプレゼンスサービスシステムにおける、プレゼンスサービスに関するプレゼンス信号のルーチング方法であって、
上記サービングサーバが、位置登録転送用情報管理手段及び位置登録信号転送手段を有し、
上記プレゼンスサーバが、ルーチング情報管理手段及び端末宛信号送信手段を有し、
上記サービングサーバの位置登録転送用情報管理手段は、プレゼンスサーバへ、端末からの位置登録信号を転送する条件及び編集処理を規定した位置登録転送用情報を管理し、
上記サービングサーバの位置登録信号転送手段は、任意の端末から位置登録信号が到来したとき、上記位置登録転送用情報管理手段で管理されている位置登録転送用情報に従い、位置登録信号を編集して上記プレゼンスサーバに転送し、
上記プレゼンスサーバのルーチング情報管理手段は、外部から到来した任意端末から位置登録信号と、ルーチングポリシー情報とから、その端末への信号のルーチング方法を規定する情報を形成して管理し、
上記プレゼンスサーバの端末宛信号送信手段は、上記ルーチング情報管理手段に情報が管理されている上記端末への信号におけるルーチング用情報を、上記ルーチング情報管理手段に管理されているルーチング方法に従って設定し、上記信号を送信する
ことを特徴とするプレゼンス信号ルーチング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はサービングサーバ、プレゼンスサーバ、プレゼンスサービスシステム及びプレゼンス信号ルーチング方法に関し、例えば、３ＧＰＰ（３ｒｄ  Ｇｅｎａｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）で定義されたＩＭＳ（ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ）アーキテクチャを利用することを前提にしたプレゼンスサービスの実現方式に関する。
【背景技術】
【０００２】
３ＧＰＰで定義されているＩＭＳベースのネットワークを用いて、自分の状態（電話中、離席中等）をリアルタイムに相手に伝えるコミュニケーションサービスである“プレゼンスサービス”を実現するための方式が各種標準化団体（ＩＥＴＦ、３ＧＰＰ、３ＧＰＰ２、ＯＭＡ等）で検討され、アーキテクチャや信号ルーチング方式等が定義されている。
【０００３】
また、信号ルーチング方式に関しては、特許文献１等で、ルーチングに関する一部課題の解決方式が提示されている。
【特許文献１】特表２００６−５１４８１６
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、各種標準化団体による標準や特許文献１ベースでのルーチングを前提にした場合において、プレゼンティ情報を参照したいウォッチャの要求に対応するプレゼンスサーバとプレゼンティティを管理するプレゼンスサーバが同一ネットワーク（同一サーバ）上でサービスする際に、ＩＭＳアーキテクチャのモデルでは、以下のように、全ての信号がＳＩＰサーバであるＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ−Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）を経由することになる。
【０００５】
ウォッチャからの購読要求（ＳＵＢＳＣＲＩＢＥ）をプレゼンスサーバへフォワードする際においては、Ｓ−ＣＳＣＦにてＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダが挿入されるのが一般的とされている。これは、ＩＭＳアーキテクチャにおいて、Ｐ−ＣＳＣＦ（Ｐｒｏｘｙ−Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）のアドレスをＲＥＧＩＳＴＥＲ時に認識し管理するのがＳ−ＣＳＣＦであるため、他のコンポーネントからの信号リクエストを端末へ対して送信する際はＳ−ＣＳＣＦ経由にする必要がある。そのため、同一ダイアログ内で処理される、プレゼンティティの情報の通知（ＮＯＴＩＦＹ）は全て、Ｓ−ＣＳＣＦを経由されて送信されることになる。
【０００６】
全ての信号がＳＩＰサーバであるＳ−ＣＳＣＦを経由することにより、Ｓ−ＣＳＣＦに相当の性能が求められると共に、Ｓ−ＣＳＣＦを経由することで経路数（経由するサーバ）が余分にかかる。
【０００７】
また、プレゼンス情報を他のアプリケーションサーバ（ＡＳ）が利用する場合、ＡＳも、ネットワークモデル的にはウォッチャとなり得る端末等と同一の扱いになるため、ＡＳからプレゼンスサーバへＳＩＰベースでアクセスする際は、Ｉ−ＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｏｎｇ−Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）／Ｓ−ＣＳＣＦ経由でプレゼンスサーバにアクセスする必要があり、効率的とはいえない。
【０００８】
ＩＭＳでは、Ｓ−ＣＳＣＦがユーザに固定的に割り振られているわけではないので、他のネットワーク（プレゼンスサーバ等）からプレゼンティティを管理するプレゼンスサーバへＳＵＢＳＣＲＩＢＥ要求をするような場合では、プレゼンティティ情報を保有するネットワークでのＳ−ＣＳＣＦでＲｅｃｏｒｄ−Ｒｏｕｔｅを付与しない等が考えられているが、端末への信号リクエストル送信ルートに関しては、具体的な実現方式は明確でなく、上記記載の課題を解決するために何らかの仕組みが必要になる。
【０００９】
本発明は、以上の点に鑑みなされたものであり、実際の運用を想定した上で、ネットワーク的に効率的なルーチングを確立できるサービングサーバ、プレゼンスサーバ、プレゼンスサービスシステム及びプレゼンス信号ルーチング方法を提供しようとしたものである。
【課題を解決するための手段】
【００１０】
第１の本発明は、端末の位置管理やサービス制御を行うプロキシサーバかつレジストラサーバとして機能するサービングサーバにおいて、（１）プレゼンティティの状態管理、購読要求の受信、ウォッチャへの情報通知を実行するプレゼンスサーバへ、端末からの位置登録信号を転送する条件及び編集処理を規定した位置登録転送用情報を管理する位置登録転送用情報管理手段と、（２）任意の端末から位置登録信号が到来したとき、上記位置登録転送用情報管理手段で管理されている位置登録転送用情報に従い、位置登録信号を編集して上記プレゼンスサーバに転送する位置登録信号転送手段とを有することを特徴とする。
【００１１】
第２の本発明は、プレゼンティティの状態管理、購読要求の受信、ウォッチャへの情報通知を実行するプレゼンスサーバにおいて、（１）外部から到来した任意端末から位置登録信号と、ルーチングポリシー情報とから、その端末への信号のルーチング方法を規定する情報を形成して管理するルーチング情報管理手段と、（２）上記ルーチング情報管理手段に情報が管理されている上記端末への信号におけるルーチング用情報を、上記ルーチング情報管理手段に管理されているルーチング方法に従って設定し、上記信号を送信する端末宛信号送信手段とを有することを特徴とする。
【００１２】
第３の本発明は、端末の位置管理やサービス制御を行うプロキシサーバかつレジストラサーバとして機能するサービングサーバと、プレゼンティティの状態管理、購読要求の受信、ウォッチャへの情報通知を実行するプレゼンスサーバとを有するプレゼンスサービスシステムにおいて、上記サービングサーバとして、第１の本発明のサービングサーバを適用すると共に、上記プレゼンスサーバとして、第２の本発明のプレゼンスサーバを適用したことを特徴とする。
【００１３】
第４の本発明は、端末の位置管理やサービス制御を行うプロキシサーバかつレジストラサーバとして機能するサービングサーバと、プレゼンティティの状態管理、購読要求の受信、ウォッチャへの情報通知を実行するプレゼンスサーバとを有するプレゼンスサービスシステムにおける、プレゼンスサービスに関するプレゼンス信号のルーチング方法であって、（１）上記サービングサーバが、位置登録転送用情報管理手段及び位置登録信号転送手段を有し、（２）上記プレゼンスサーバが、ルーチング情報管理手段及び端末宛信号送信手段を有し、（１−１）上記サービングサーバの位置登録転送用情報管理手段は、プレゼンスサーバへ、端末からの位置登録信号を転送する条件及び編集処理を規定した位置登録転送用情報を管理し、（１−２）上記サービングサーバの位置登録信号転送手段は、任意の端末から位置登録信号が到来したとき、上記位置登録転送用情報管理手段で管理されている位置登録転送用情報に従い、位置登録信号を編集して上記プレゼンスサーバに転送し、（２−１）上記プレゼンスサーバのルーチング情報管理手段は、外部から到来した任意端末から位置登録信号と、ルーチングポリシー情報とから、その端末への信号のルーチング方法を規定する情報を形成して管理し、（２−２）上記プレゼンスサーバの端末宛信号送信手段は、上記ルーチング情報管理手段に情報が管理されている上記端末への信号におけるルーチング用情報を、上記ルーチング情報管理手段に管理されているルーチング方法に従って設定し、上記信号を送信することを特徴とする。
【発明の効果】
【００１４】
本発明によれば、ネットワーク的に効率的なルーチングを確立できるサービングサーバ、プレゼンスサーバ、プレゼンスサービスシステム及びプレゼンス信号ルーチング方法を提供できる。
【発明を実施するための最良の形態】
【００１５】
（Ａ）第１の実施形態
以下、本発明によるサービングサーバ、プレゼンスサーバ、プレゼンスサービスシステム及びプレゼンス信号ルーチング方法の第１の実施形態を、図面を参照しながら詳述する。
【００１６】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態のプレゼンスサービスシステムに係るネットワークの機能的構成を示すブロック図である。
【００１７】
図１において、プレゼンスサービスシステム１０は、機能的には、ウォッチャＩＭＳ端末１、プレゼンティティＩＭＳ端末２、Ｐ−ＣＳＣＦ３、Ｉ−ＣＳＣＦ４、Ｓ−ＣＳＣＦ５、ＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）／ＳＬＦ（Ｓｕｂｓｃｒｉｐｔｉｏｎ  Ｌｏｃａｔｏｒ  Ｆｕｎｃｔｉｏｎ）６、プレゼンスサーバ７及びアプリケーションサーバ８を構成要素としている。
【００１８】
なお、Ｐ−ＣＳＣＦ３、Ｉ−ＣＳＣＦ４、Ｓ−ＣＳＣＦ５、ＨＳＳ／ＳＬＦ６、プレゼンスサーバ７及びアプリケーションサーバ８などの機能部はそれぞれ、別個の物理的な装置によって構成されていても良く、また、１個の物理的な装置によって複数の機能部が構成されていても良く、また、複数の物理的な装置によって複数の機能部が構成されていても良い。また、図１では、ＨＳＳ及びＳＬＦを統合して示しているが、機能的には別個のものである。
【００１９】
ウォッチャＩＭＳ端末１は、プレゼンティティに関する情報を要求するウォッチャに係るＩＭＳ端末であり、アクセスネットワークＮＥＴ１を介してＩＭＳネットワークＮＥＴ２に接続するものである。
【００２０】
プレゼンティティＩＭＳ端末２は、プレゼンス情報を公開するプレゼンティティに係るＩＭＳ端末であり、アクセスネットワークＮＥＴ１を介してＩＭＳネットワークＮＥＴ２に接続するものである。
【００２１】
Ｐ−ＣＳＣＦ３は、ウォッチャＩＭＳ端末１やプレゼンティティＩＭＳ端末２とＩＭＳネットワークＮＥＴ２が最初に接する点のＳＩＰサーバである。Ｐ−ＣＳＣＦ３は、ＩＭＳ端末１、２に対して、いわゆるアウトバウンド／インバウンドプロキシサーバの役割を果たすものであり、ＳＩＰリクエストやレスポンスを適切な方向（ＩＭＳ端末方向、ＩＭＳネットワーク方向）に転送するものである。なお、図１では、ウォッチャＩＭＳ端末１及びプレゼンティティＩＭＳ端末２が同一のＰ−ＣＳＣＦ３の配下に存在するように記載しているが、ウォッチャＩＭＳ端末１及びやプレゼンティティＩＭＳ端末２が異なるＰ−ＣＳＣＦ３の配下に存在していても良いことは勿論である。
【００２２】
Ｉ−ＣＳＣＦ４は、他網からのＳＩＰメッセージを受けるためのプロキシサーバとして機能するＳＩＰサーバである。Ｉ−ＣＳＣＦ４は、主に、受けたメッセージの内容に基づいて、ユーザの登録情報（Ｓ−ＣＳＣＦアドレス）をＨＳＳ／ＳＬＦ６から取得し、ＳＩＰリクエストを自網内の適切なＳ−ＣＳＣＦ５へフォワードするものである。
【００２３】
Ｓ−ＣＳＣＦ５は、ＳＩＰのセッション制御機能やレジストラとしての機能を有するサーバである。Ｓ−ＣＳＣＦ５は、管理するユーザ（プレゼンティティやウォッチャなど）に関する全てのメッセージがルーチングされるプロキシサーバとして、サービス実現のためのメッセージ処理（アプリケーションサーバ８へのメッセージ転送処理などを含む）を行うものである。Ｓ−ＣＳＣＦ５は、レジストラとして、ユーザのロケーション情報を管理するものである。
【００２４】
ＨＳＳ／ＳＬＦ６におけるＨＳＳは、ユーザ情報（例えば、ＩＭＳ端末の位置登録情報など）を扱う中心となるデータベースである。ＨＳＳ／ＳＬＦ６におけるＳＬＦは、ＨＳＳを複数持つＩＭＳネットワークＮＥＴ２に設けられるものであり、ユーザのアドレスとＨＳＳとを結び付けるデータベースである。
【００２５】
プレゼンスサーバ７は、プレゼンティティの状態等を管理すると共に、購読要求の受信、ウォッチャへの情報通知等を実行するものである。
【００２６】
アプリケーションサーバ８は、付加サービスの制御を実行するものである。ここで、ウォッチャとして動作するアプリケーションサーバ８がＩＭＳネットワークＮＥＴ２内に設けられていても良い。
【００２７】
ＩＭＳネットワークの標準では、プレゼンスサーバ７及びアプリケーションサーバ８間のインタフェースＩＦ１や、Ｐ−ＣＳＣＦ３及びプレゼンスサーバ７間のインタフェースＩＦ２は規定されていないが、この第１の実施形態では、実際の運用を想定してこれらインタフェースを設定している。
【００２８】
図２は、プレゼンスサーバ７の詳細構成を示すブロック図である。図２において、プレゼンスサーバ７は、プレゼンス情報処理部１１、ＳＩＰ信号処理部１２、プレゼンス情報管理部１３及びユーザ管理部１４を有する。プレゼンス情報処理部１１は、プレゼンス関連情報の制御をするものであり、ＳＩＰ信号処理部１２は、信号の送受信制御をするものである。プレゼンス情報管理部１３は、各ユーザ（プレゼンティティ）のプレゼンス情報を管理するものであり、ユーザ管理部１４は、加入者情報や位置情報等を管理するものである。
【００２９】
図３は、ＨＳＳ機能をも担当するＳ−ＣＳＣＦ５の詳細構成を示すブロック図である。図３において、Ｓ−ＣＳＣＦ５は、ルーチング情報処理部２１、ＳＩＰ信号処理部２２、ルーチング情報管理部２３及びユーザ管理部２４を有する。ルーチング情報処理部２１はルーチング制御をするものであり、ＳＩＰ信号処理部２２は信号の送受信制御をするものである。ルーチング情報管理部２３はルーチング情報を管理するものであり、ユーザ管理部２４は加入者情報や位置情報等を管理するものである。
【００３０】
図４は、ルーチング情報管理部２３に設けられているＲＥＧＩＳＴＥＲ信号ルーチング管理テーブルＴＢＬ１の構成を示す説明図である。なお、ＨＳＳがＳ−ＣＳＣＦ５と切り離されて設けられている場合には、ＲＥＧＩＳＴＥＲ信号ルーチング管理テーブルＴＢＬ１をＨＳＳに設けるようにしても良い。
【００３１】
プレゼンスサービスは、ＲＥＧＩＳＴＥＲ動作と密接に関連することから、第１の実施形態では、ＲＥＧＩＳＴＥＲ信号をＳ−ＣＳＣＦ５から所定のプレゼンスサーバ７へ適宜転送することとし、そのため、Ｓ−ＣＳＣＦ５内のルーチング情報管理部２３にＲＥＧＩＳＴＥＲ信号ルーチング管理テーブルＴＢＬ１を設けている。
【００３２】
ＲＥＧＩＳＴＥＲ信号ルーチング管理テーブルＴＢＬ１は、ＲＥＧＩＳＴＥＲ信号をＳ−ＣＳＣＦ５からプレゼンスサーバ７へ転送させるための条件などを記述したものであり、その１行（１レコード）は、ターゲットプレゼンスサーバ３１、ルーチングパターン３２、Ｃｏｎｔａｃｔヘッダの設定内容３３、Ｆｒｏｍヘッダの設定内容３４の項目などでなる。
【００３３】
ターゲットプレゼンスサーバ３１の項目には、例えば、当該ＩＭＳネットワークＮＥＴ２に設けられているプレゼンスサーバ７の識別情報（ＵＲＩ）が記述され、ルーチングパターン３２の項目には、到来したＲＥＧＩＳＴＥＲ信号を転送（フォワード）するか否かの情報が記述され、Ｃｏｎｔａｃｔヘッダの設定内容３３には、到来したＲＥＧＩＳＴＥＲ信号をプレゼンスサーバ７に転送（フォワード）する場合において転送するＲＥＧＩＳＴＥＲ信号のＣｏｎｔａｃｔヘッダにどのような内容を設定するかが記述され、Ｆｒｏｍヘッダの設定内容３４には、受信したＲＥＧＩＳＴＥＲ信号をプレゼンスサーバ７に転送（フォワード）する場合において転送するＲＥＧＩＳＴＥＲ信号のＦｒｏｍヘッダにどのような内容を設定するかが記述される。
【００３４】
図４の１行目は、識別情報が「ＡＡＡ」のプレゼンスサーバ７に対しては、到来したＲＥＧＩＳＴＥＲ信号を転送しないことを表している。言い換えると、ＲＥＧＩＳＴＥＲ信号を当該Ｓ−ＣＳＣＦ５で終端することを表している。２行目は、識別情報が「ＢＢＢ」のプレゼンスサーバ７に対しては、到来したＲＥＧＩＳＴＥＲ信号におけるＣｏｎｔａｃｔヘッダ及びＦｒｏｍヘッダを、当該Ｓ−ＣＳＣＦ５のアドレスに書き換えて転送することを表している。３行目は、識別情報が「ＣＣＣ」のプレゼンスサーバ７に対しては、到来したＲＥＧＩＳＴＥＲ信号におけるＣｏｎｔａｃｔヘッダを、当該Ｓ−ＣＳＣＦ５のアドレスに書き換えて転送することを表しており、Ｆｒｏｍヘッダは書き換えられず、到来したＲＥＧＩＳＴＥＲ信号の設定内容（送信元のＩＭＳ端末（ユーザエージェント）のアドレス）のままである。４行目は、識別情報が「ＤＤＤ」のプレゼンスサーバ７に対しては、到来したＲＥＧＩＳＴＥＲ信号におけるＣｏｎｔａｃｔヘッダ及びＦｒｏｍヘッダを書き換えることなく、到来したＲＥＧＩＳＴＥＲ信号の設定内容（送信元のＩＭＳ端末（ユーザエージェント）のアドレス）のままで転送することを表している。
【００３５】
上述のように、ＲＥＧＩＳＴＥＲ信号ルーチング管理テーブルＴＢＬ１は、Ｓ−ＣＳＣＦ５に到来したＲＥＧＩＳＴＥＲ信号をプレゼンスサーバ７へ転送させるための条件などを記述しているが、ＲＥＧＩＳＴＥＲ信号の送信元のＩＭＳ端末（１、２）についての条件を設けておらず、図４に示す転送条件を満たす場合には、プレゼンスサーバ７に転送される。なお、Ｓ−ＣＳＣＦ５は、ＲＥＧＩＳＴＥＲ信号が到着した際には、ＨＳＳ／ＳＬＦ６の設定内容に基づいて、ユーザ（ユーザ端末）の認証を行うが、ＨＳＳ／ＳＬＦ６の格納内容に、転送の可否、若しくは、転送するプレゼンスサーバの識別情報などを格納しておくようにしても良い。
【００３６】
図５は、プレゼンスサーバ７のプレゼンス情報管理部１３に設けられている信号送信先管理テーブルＴＢＬ２の構成を示す説明図である。
【００３７】
信号送信先管理テーブルＴＢＬ２は、プレゼンスサーバ７からの信号（例えば、購買要求したウォッチャにプレゼンス情報を通知する際のＮＯＴＩＦＹ信号）の送信先や経路等の情報などを記述したものであり、各行（レコード）は、ＩＭＳ端末１、２の識別情報（ＳＩＰ−ＵＲＩ；ユーザＩＤ）４１、Ｃｏｎｔａｃｔ情報４２、Ｐａｔｈ情報４３、Ｒｏｕｔｅヘッダの生成有無情報４４、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダの優先非優先情報４５の項目などでなる。
【００３８】
信号送信先管理テーブルＴＢＬ２の各行（レコード）は、プレゼンスサービスに係る各ユーザ（ウォッチャ若しくはプレゼンティティだけの者を含む）毎に予め設けられているものであり（例えば、サービスの契約時などにレコードを追加する）、Ｓ−ＣＳＣＦ５から当該プレゼンスサーバ７にＲＥＧＩＳＴＥＲ信号が到来したときに、そのうちのＣｏｎｔａｃｔ情報４２及びＰａｔｈ情報４３が書き込まれるものである。
【００３９】
ユーザの識別情報（ＳＩＰ−ＵＲＩ；ユーザＩＤ）４１は、プレゼンスサーバ７から信号を送信するユーザ（例えば、ウォッチャ）に係る行を探索する際に利用されるものである。Ｃｏｎｔａｃｔ情報４２及びＰａｔｈ情報４３は、Ｓ−ＣＳＣＦ５から当該プレゼンスサーバ７に到来したＲＥＧＩＳＴＥＲ信号のＣｏｎｔａｃｔヘッダ及びＰａｔｈヘッダの内容が設定されるものであり、例えば、プレゼンス情報を通知するＮＯＴＩＦＹ信号の所定のヘッダにこの設定内容が設定される。Ｒｏｕｔｅヘッダの生成有無情報４４には、プレゼンスサーバ７からのリクエスト信号に、Ｐａｔｈ情報からＲｏｕｔｅヘッダを生成して付加するか否かが記述される。Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダの優先非優先情報４５には、ダイアログ確立されている状態で、当該プレゼンスサーバ７から信号を送信する際に、送信前に到来した受信信号に含まれているＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを参照（優先）するか否かが設定される。なお、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダの優先非優先情報４５を参照（優先）する場合、以降の信号送信は、受信信号のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダに従って送信信号を構築して送信する。また、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダの優先非優先情報４５はダイアログ確立されている状態で意味を持つ設定情報であり、ダイアログが確立されていない状態にはこの設定は意味を持たない。
【００４０】
図５は、ユーザ毎に、Ｒｏｕｔｅヘッダの生成有無情報４４やＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダの優先非優先情報４５を可変設定できるものを示したが、プレゼンスサービスシステム１の全体を通して、Ｒｏｕｔｅヘッダの生成有無情報やＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダの優先非優先情報をシステムの固定値とするようにしても良く、この場合、信号送信先管理テーブルＴＢＬ２から、Ｒｏｕｔｅヘッダの生成有無情報４４やＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダの優先非優先情報４５の項目を省略される（但し、固定情報を所で管理し、その固定情報に応じた送信時の処理がなされる）。
【００４１】
図５の１行目は、Ｒｏｕｔｅヘッダの生成有無情報４４が「有」でＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダの優先非優先情報４５が「非優先」であるので、識別情報が「１１１１」のＩＭＳ端末（１、２）に対する送信信号のＲｏｕｔｅヘッダに、Ｐａｔｈ情報に基づいたＰ−ＣＳＣＦ３のＵＲＩを設定して当該プレゼンスサーバ７から送信することを表している。言い換えると、当該プレゼンスサーバ７から、Ｓ−ＣＳＣＦ５を経由することなく、識別情報が「１１１１」のＩＭＳ端末（１、２）に対する送信信号をＰ−ＣＳＣＦ３に直接送信することを表している。
【００４２】
図５の２行目〜４行目は、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダの優先非優先情報４５が「優先」であるので、Ｒｏｕｔｅヘッダの生成有無情報４４の設定内容に関係なく、ダイアログが確立されている状態では、当該プレゼンスサーバ７は、受信信号のＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダに従った信号を構築して信号を送出することを表している。すなわち、当該プレゼンスサーバ７は、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダが規定する中継ノードを経由するような信号を構築して送出することとなる。
【００４３】
これに対して、ダイアログが確立されていない状態では、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダの優先非優先情報４５が無意味であるので、プレゼンスサーバ７は、当該プレゼンスサーバ７主導の信号（リクエスト）については、他の情報に従って信号を構築して送出することとなる。２行目の場合、Ｒｏｕｔｅヘッダの生成有無情報４４が「無」であるので、接続されているＳ−ＣＳＣＦ５に信号を送出することとなる。３行目の場合、当該プレゼンスサーバ７にＲＥＧＩＳＴＥＲ信号が送信されていないため（Ｃｏｎｔａｃｔ情報４２、Ｐａｔｈ情報４３が未設定のため）、Ｉ−ＣＳＣＦ４に信号を送出することとなる。４行目の場合であれば、Ｒｏｕｔｅヘッダの生成有無情報４４が「有」であるので、Ｓ−ＣＳＣＦ５経由ではなく、Ｐ−ＣＳＣＦ３に当該プレゼンスサーバ７主導の信号を送出することとなる。
【００４４】
（Ａ−２）第１の実施形態の動作
以下、第１の実施形態のプレゼンスサービスシステム１０の特徴的な動作を、図面を参照しながら説明する。
【００４５】
まず、Ｓ−ＣＳＣＦ５におけるＲＥＧＩＳＴＥＲ登録処理を、図６のフローチャートを参照しながら詳述する。
【００４６】
Ｓ−ＣＳＣＦ５は、ＩＭＳ端末１、２が送出したＰ−ＣＳＣＦ３及びＩ−ＣＳＣＦ４経由の位置登録信号（ＲＥＧＩＳＴＥＲ信号）を受信する（ステップ１０１）。
【００４７】
このとき、Ｓ−ＣＳＣＦ５は、認証を含めたＲＥＧＩＳＴＥＲ信号の受信による登録処理をＨＳＳ／ＳＬＦ６と連動して実施し、ＲＥＧＩＳＴＥＲ情報をＨＳＳ（６）へ登録する（ステップ１０２）。
【００４８】
第１の実施形態の場合、Ｓ−ＣＳＣＦ５は、上記のような一般的なＲＥＧＩＳＴＥＲ情報の登録処理を完了すると、図４に示すようなＲＥＧＩＳＴＥＲ信号ルーチング管理テーブルＴＢＬ１を参照し、受信したＲＥＧＩＳＴＥＲ信号をプレゼンスサーバ７に転送することを要するか否かを分析する（ステップ１０３）。
【００４９】
受信したＲＥＧＩＳＴＥＲ信号をプレゼンスサーバ７に転送することが不要であれば、Ｓ−ＣＳＣＦ５は、ＲＥＧＩＳＴＥＲ情報を登録したことの応答処理を実行して、ＲＥＧＩＳＴＥＲ信号が到来したときの処理を完了する（ステップ１０４）。
【００５０】
これに対して、受信したＲＥＧＩＳＴＥＲ信号をプレゼンスサーバ７に転送することが必要であれば、Ｓ−ＣＳＣＦ５は、ＲＥＧＳＩＴＥＲ信号ルーチング管理テーブルＴＢＬ１の設定条件に従って、受信したＲＥＧＩＳＴＥＲ信号の各種ヘッダ（Ｃｏｎｔａｃｔヘッダ、Ｆｒｏｍヘッダ）を適宜編集した後、プレゼンスサーバ７にＲＥＧＳＩＴＥＲ信号を転送する（ステップ１０５、１０６）。
【００５１】
その後、プレゼンスサーバ７からの応答信号の受信を待って、Ｓ−ＣＳＣＦ５は、ＲＥＧＩＳＴＥＲ情報を登録したことの応答処理を実行して、ＲＥＧＩＳＴＥＲ信号が到来したときの処理を完了する（ステップ１０７、１０８）。
【００５２】
次に、プレゼンスサーバ７における転送ＲＥＧＩＳＴＥＲ信号の受信時の処理を、図７のフローチャートを参照しながら詳述する。
【００５３】
プレゼンスサーバ７は、Ｓ−ＣＳＣＦ５が転送したＲＥＧＩＳＴＥＲ信号（位置登録信号）を受信すると（ステップ２０１）、そのＲＥＧＩＳＴＥＲ信号に設定されているＣｏｎｔａｃｔヘッダ及びＰａｔｈヘッダの内容をそれぞれ、図５に示す信号送信アドレス管理テーブルＴＢＬ２の受信したＲＥＧＩＳＴＥＲ信号の送信元ＩＭＳ端末（１、２）に係る行の該当項目４２、４３に設定した後（ステップ２０２）、ＲＥＧＩＳＴＥＲ信号の受信応答を転送元のＳ−ＣＳＣＦ５に返送する（ステップ２０３）。
【００５４】
以上のようなＳ−ＣＳＣＦ５からプレゼンスサーバ７へのＲＥＧＩＳＴＥＲ信号の転送処理によって所定情報が設定された図５に示す信号送信アドレス管理テーブルＴＢＬ２に基づいて、プレゼンスサーバ７は、当該プレゼンスサーバ７からの信号のあて先や経路などを決定して信号を送信することができる。
【００５５】
図８は、ＩＭＳ端末１がウォッチャの場合におけるプレゼンスサービスのシーケンス例を示すシーケンス図である。なお、図８は、プレゼンティティＩＭＳ端末２について登録済みの状態から示している。また、図８は、ＩＭＳ端末１、２を認証するフローを省略して示している。
【００５６】
図８におけるステップ３０１は、プレゼンティティＩＭＳ端末２が状態変更通知を行う際のシーケンスを示している。
【００５７】
プレゼンティティＩＭＳ端末２は、状態変更通知内容を含むＰＵＢＬＩＳＨ信号をＰ−ＣＳＣＦ３に転送し（ステップ３０１−１）、Ｐ−ＣＳＣＦ３がそのＰＵＢＬＩＳＨ信号をＳ−ＣＳＣＦ５に転送し（ステップ３０１−２）、Ｓ−ＣＳＣＦ５がそのＰＵＢＬＩＳＨ信号をプレゼンスサーバ７に転送する（ステップ３０１−３）。
【００５８】
プレゼンスサーバ７は、送信元のプレゼンティティＩＭＳ端末２についての、プレゼンス情報管理部１３の格納内容を、到来したＰＵＢＬＩＳＨ信号に挿入されている内容に更新する。そして、プレゼンスサーバ７は、プレゼンス情報を変更したことを表す応答である２００ＯＫ信号をＳ−ＣＳＣＦ５に送信し（ステップ３０１−４）、Ｓ−ＣＳＣＦ５がその２００ＯＫ信号をＰ−ＣＳＣＦ３に転送し（ステップ３０１−５）、Ｐ−ＣＳＣＦ３がその２００ＯＫ信号をプレゼンティティＩＭＳ端末２に転送する（ステップ３０１−６）。
【００５９】
図８におけるステップ３０２は、ウォッチャＩＭＳ端末１が位置登録を行う際のシーケンスを示している。
【００６０】
ウォッチャＩＭＳ端末１は、電源がオンした場合など、当該端末の位置登録に係るＲＥＧＩＳＴＥＲ信号をＰ−ＣＳＣＦ３に転送し（ステップ３０２−１）、Ｐ−ＣＳＣＦ３がそのＲＥＧＩＳＴＥＲ信号をＩ−ＣＳＣＦ４に転送し（ステップ３０２−２）、Ｉ−ＣＳＣＦ４がそのＲＥＧＩＳＴＥＲ信号をＳ−ＣＳＣＦ５に転送する（ステップ３０２−３）。Ｓ−ＣＳＣＦ５は、送信元のウォッチャＩＭＳ端末１についての位置登録をＨＳＳ／ＳＬＦ６のＨＳＳに対して行った後、図４に示すＲＥＧＩＳＴＥＲ信号ルーチング管理テーブルＴＢＬ１の格納内容に基づき、プレゼンスサーバ７へのＲＥＧＩＳＴＥＲ信号の転送が必要かを判断する（ステップ３０２−４）。図８は、Ｓ−ＣＳＣＦ５からプレゼンスサーバ７へＲＥＧＩＳＴＥＲ信号を転送する場合を示している（ステップ３０２−５）。
【００６１】
プレゼンスサーバ７は、Ｓ−ＣＳＣＦ５からＲＥＧＩＳＴＥＲ信号が到来すると、ＲＥＧＩＳＴＥＲ信号に設定されているＣｏｎｔａｃｔヘッダ及びＰａｔｈヘッダの内容をそれぞれ、図５に示す信号送信アドレス管理テーブルＴＢＬ２の受信したＲＥＧＩＳＴＥＲ信号の送信元ＩＭＳ端末１に係る行の該当項目４２、４３に設定する。そして、プレゼンスサーバ７は、ＲＥＧＩＳＴＥＲ信号の受信応答である２００ＯＫ信号をＳ−ＣＳＣＦ５に送信し（ステップ３０２−６）、Ｓ−ＣＳＣＦ５がその２００ＯＫ信号をＩ−ＣＳＣＦ４に転送し（ステップ３０２−７）、Ｉ−ＣＳＣＦ４がその２００ＯＫ信号をＰ−ＣＳＣＦ３に転送し（ステップ３０２−８）、Ｐ−ＣＳＣＦ３がその２００ＯＫ信号をウォッチャＩＭＳ端末１に転送する（ステップ３０２−９）。
【００６２】
図８におけるステップ３０３は、ウォッチャＩＭＳ端末１が購買要求を行う際のシーケンスを示している。
【００６３】
ウォッチャＩＭＳ端末１は、定期的に、又は、ウォッチャの操作に応じて、所望のプレゼンティティについてのプレゼンス情報の購買要求に係るＳＵＢＳＣＲＩＢＥ信号をＰ−ＣＳＣＦ３に転送し（ステップ３０３−１）、Ｐ−ＣＳＣＦ３がそのＳＵＢＳＣＲＩＢＥ信号をＳ−ＣＳＣＦ５に転送し（ステップ３０３−２）、Ｓ−ＣＳＣＦ５がそのＳＵＢＳＣＲＩＢＥ信号をプレゼンスサーバ７に転送する（ステップ３０３−３）。プレゼンスサーバ７は、ＳＵＢＳＣＲＩＢＥ信号の受信応答である２００ＯＫ信号をＳ−ＣＳＣＦ５に送信し（ステップ３０３−４）、Ｓ−ＣＳＣＦ５がその２００ＯＫ信号をＰ−ＣＳＣＦ３に転送し（ステップ３０３−５）、Ｐ−ＣＳＣＦ３がその２００ＯＫ信号をウォッチャＩＭＳ端末１に転送する（ステップ３０３−６）。
【００６４】
図８におけるステップ３０４は、プレゼンスサーバ７からプレゼンス情報を通知する際のシーケンスを示している。
【００６５】
プレゼンスサーバ７は、ウォッチャＩＭＳ端末１が送信した、プレゼンス情報の購買要求に係るＳＵＢＳＣＲＩＢＥ信号を受信すると、図５に示す信号送信アドレス管理テーブルＴＢＬ２を参照し、ウォッチャＩＭＳ端末１に向けた所定経路を通過する、要求されたプレゼンス情報を通知するＮＯＴＩＦＹ信号を形成して送信する（ステップ３０４−１）。図８は、図５に示す信号送信アドレス管理テーブルＴＢＬ２の１行目に係るウォッチャＩＭＳ端末１が購買要求を送信してきた場合を示している。プレゼンスサーバ７は、プレゼンス情報を通知するＮＯＴＩＦＹ信号をＰ−ＣＳＣＦ３に送信し（ステップ３０４−１）、Ｐ−ＣＳＣＦ３がそのＮＯＴＩＦＹ信号をウォッチャＩＭＳ端末１に転送する（ステップ３０４−２）。
【００６６】
ウォッチャＩＭＳ端末１は、ＮＯＴＩＦＹ信号の受信応答である２００ＯＫ信号をＰ−ＣＳＣＦ３に送信し（ステップ３０４−３）、Ｐ−ＣＳＣＦ３がその２００ＯＫ信号をプレゼンスサーバ７に転送する（ステップ３０４−４）。
【００６７】
（Ａ−３）第１の実施形態の効果
上記第１の実施形態によれば、Ｓ−ＣＳＣＦ５とプレゼンスサーバ７とがＲＥＧＩＳＴＥＲ信号を含めて連携し、必要情報（図４及び図５参照）を管理するようにしたので、通信する上での経由サーバを削減することができ、ネットワークとしてのトータルパフォーマンスの向上を期待することができる。因みに、例えば、図８のステップ３０４−１の転送は、ＩＭＳの標準であれば、Ｓ−ＣＳＣＦ５を経由するものとなっている。
【００６８】
また、上記第１の実施形態によれば、管理情報の形式パターンを複数設定できるようにしていることから、ＩＭＳアーキテクチャベースでサービスを実現したい事業者システムにも対応可能（その場合は、経路削減は不可）な構成としているため、事業者ネットワーク要望に柔軟に対応することができる。
【００６９】
（Ｂ）第２の実施形態
次に、本発明によるサービングサーバ、プレゼンスサーバ、プレゼンスサービスシステム及びプレゼンス信号ルーチング方法の第２の実施形態を、図面を参照しながら詳述する。
【００７０】
第２の実施形態のプレゼンスサービスシステムも、ネットワーク的な構成は、第１の実施形態に係る図１で示すことができる。
【００７１】
上述した第１の実施形態は、ＩＭＳ端末１がウォッチャとして動作し得るものであったが、この第２の実施形態は、アプリケーションサーバ８がウォッチャとして動作し得るものである。
【００７２】
図９は、アプリケーションサーバ８がウォッチャの場合におけるプレゼンスサービスのシーケンス例を示すシーケンス図である。なお、図９は、ＩＭＳ端末２を認証するフローを省略して示している。
【００７３】
図９は、アプリケーションサーバ８がプレゼンティティＩＭＳ端末２からプレゼンス情報を直接取得する場合を示している。例えば、プレゼンスサーバ７に記憶されているプレゼンス情報を取得することも可能であるが、例えば、リアルタイムでの情報取得のような場合を図９は示している。
【００７４】
図９におけるステップ４０１は、プレゼンティティＩＭＳ端末２が位置登録を行う際のシーケンスを示している。
【００７５】
プレゼンティティＩＭＳ端末２は、電源がオンした場合など、当該端末の位置登録に係るＲＥＧＩＳＴＥＲ信号をＰ−ＣＳＣＦ３に転送し（ステップ４０１−１）、Ｐ−ＣＳＣＦ３がそのＲＥＧＩＳＴＥＲ信号をＩ−ＣＳＣＦ４に転送し（ステップ４０１−２）、Ｉ−ＣＳＣＦ４がそのＲＥＧＩＳＴＥＲ信号をＳ−ＣＳＣＦ５に転送する（ステップ４０１−３）。Ｓ−ＣＳＣＦ５は、送信元のプレゼンティティＩＭＳ端末２についての位置登録をＨＳＳ／ＳＬＦ６のＨＳＳに対して行った後、図４に示すＲＥＧＩＳＴＥＲ信号ルーチング管理テーブルＴＢＬ１の格納内容に基づき、プレゼンスサーバ７へのＲＥＧＩＳＴＥＲ信号の転送が必要かを判断する（ステップ４０１−４）。図９は、Ｓ−ＣＳＣＦ５からプレゼンスサーバ７へＲＥＧＩＳＴＥＲ信号を転送する場合を示している（ステップ４０１−５）。
【００７６】
プレゼンスサーバ７は、Ｓ−ＣＳＣＦ５からＲＥＧＩＳＴＥＲ信号が到来すると、ＲＥＧＩＳＴＥＲ信号に設定されているＣｏｎｔａｃｔヘッダ及びＰａｔｈヘッダの内容をそれぞれ、図５に示す信号送信アドレス管理テーブルＴＢＬ２の受信したＲＥＧＩＳＴＥＲ信号の送信元ＩＭＳ端末２に係る行の該当項目４２、４３に設定する。そして、プレゼンスサーバ７は、ＲＥＧＩＳＴＥＲ信号の受信応答である２００ＯＫ信号をＳ−ＣＳＣＦ５に送信し（ステップ４０１−６）、Ｓ−ＣＳＣＦ５がその２００ＯＫ信号をＩ−ＣＳＣＦ４に転送し（ステップ４０１−７）、Ｉ−ＣＳＣＦ４がその２００ＯＫ信号をＰ−ＣＳＣＦ３に転送し（ステップ４０１−８）、Ｐ−ＣＳＣＦ３がその２００ＯＫ信号をプレゼンティティＩＭＳ端末２に転送する（ステップ４０１−９）。
【００７７】
図９におけるステップ４０２は、ウォッチャであるアプリケーションサーバ８が購読要求する際のシーケンスである。
【００７８】
アプリケーションサーバ８が所定のアプリケーションを実行することにより、所定のプレゼンティティＩＭＳ端末２のプレゼンス情報を欲する場合には、そのプレゼンティティＩＭＳ端末２を宛先とした、購読要求に係るＳＵＢＳＣＲＩＢＥ信号をプレゼンスサーバ７に送信する（ステップ４０２−１）。このとき、プレゼンスサーバ７は、図５に示す信号送信アドレス管理テーブルＴＢＬ２を参照し、プレゼンティティＩＭＳ端末２に向けた所定経路を通過するようにＳＵＢＳＣＲＩＢＥ信号を編集し直して送信する（ステップ４０２−２）。図９は、図５に示す信号送信アドレス管理テーブルＴＢＬ２の１行目に係るプレゼンティティＩＭＳ端末２が購買要求の要求先の場合を示している。仮に、図５に示す２行目〜４行目が該当する場合、図９に示すようなＳＵＢＳＣＲＩＢＥ信号の送信元がアプリケーションサーバ８である状況は、ダイアログが確立されていない状態に該当する。
【００７９】
プレゼンスサーバ７は、購読要求に係るＳＵＢＳＣＲＩＢＥ信号をＰ−ＣＳＣＦ３に送信し（ステップ４０２−２）、Ｐ−ＣＳＣＦ３がそのＳＵＢＳＣＲＩＢＥ信号をプレゼンティティＩＭＳ端末２に転送する（ステップ４０２−３）。
【００８０】
プレゼンティティＩＭＳ端末２は、ＳＵＢＳＣＲＩＢＥ信号の受信応答である２００ＯＫ信号をＰ−ＣＳＣＦ３に送信し（ステップ４０２−４）、Ｐ−ＣＳＣＦ３がその２００ＯＫ信号をプレゼンスサーバ７に転送し（ステップ４０２−５）、プレゼンスサーバ７がその２００ＯＫ信号をアプリケーションサーバ８に転送する（ステップ４０２−６）。
【００８１】
図９におけるステップ４０３は、ウォッチャであるアプリケーションサーバ８へプレゼンス情報を通知する際のシーケンスである。
【００８２】
プレゼンティティＩＭＳ端末２は、購読要求に係るＳＵＢＳＣＲＩＢＥ信号を受信すると、プレゼンス情報を通知するためのＮＯＴＩＦＹ信号を生成してＰ−ＣＳＣＦ３に送信する（ステップ４０３−１）。ここで、ＮＯＴＩＦＹ信号は、購読要求に係るＳＵＢＳＣＲＩＢＥ信号に設定されている各種ルーチングヘッダに従って、各種のルーチングヘッダが設定される。言い換えると、ＳＵＢＳＣＲＩＢＥ信号の逆の経路を通るように各種のルーチングヘッダが設定される（２００ＯＫ信号の場合と同様である）。Ｐ−ＣＳＣＦ３は、到来したＮＯＴＩＦＹ信号をプレゼンスサーバ７に転送し（ステップ４０３−２）、プレゼンスサーバ７は、そのＮＯＴＩＦＹ信号をアプリケーションサーバ８に転送する（ステップ４０３−３）。
【００８３】
アプリケーションサーバ８は、ＮＯＴＩＦＹ信号の受信応答である２００ＯＫ信号をプレゼンスサーバ７に送信し（ステップ４０３−４）、プレゼンスサーバ７がその２００ＯＫ信号をＰ−ＣＳＣＦ３に転送し（ステップ４０３−５）、Ｐ−ＣＳＣＦ３がその２００ＯＫ信号をプレゼンティティＩＭＳ端末２に転送する（ステップ４０３−６）。
【００８４】
第２の実施形態では、上述のように、ウォッチャとしてアプリケーションサーバ８を想定している。一般的なＩＭＳアーキテクチャであれば、アプリケーションサーバ８は、ウォッチャがＩＭＳ端末１の場合と同様に、Ｉ−ＣＳＣＦ４やＳ−ＣＳＣＦ５経由で購読要求を送信し、その経路の延長でプレゼンティティＩＭＳ端末２へ購買要求を送信することになり、アプリケーションサーバ８がウォッチャの場合も、経路数は多くなる。
【００８５】
第２の実施形態によれば、アプリケーションサーバ８とプレゼンスサーバ７間もＳＩＰベースでインタワークし、かつ、ＲＥＧＩＳＴＥＲ情報等を含めたルーチング情報をプレゼンスサーバ７が管理していること（図５）により、大幅に経路数（経路サーバ）を削減したルーチングが可能になっている。また、第２の実施形態の連携方式では、プレゼンス情報を利用した第３者からのサービス（アプリケーション）等に柔軟に対応でき、サービスの拡大を期待することができる。
【００８６】
（Ｃ）他の実施形態
上記各実施形態では、Ｐ−ＣＳＣＦ及びプレゼンスサーバがＳ−ＣＳＣＦ非経由で通信し得るものを示したが、プレゼンスサーバの信号送信先管理テーブルに対する設定により、Ｐ−ＣＳＣＦを非経由でプレゼンスサーバと端末との間で直接信号を授受するようにしても良い。
【００８７】
また、上記第２の実施形態では、ウォッチャアプリケーションをアプリケーションサーバが具備するイメージで説明したが、ウォッチャアプリケーションをプレゼンスサーバに配置するようにしても良い。
【００８８】
上記第１の実施形態では、各種管理データを図４又は図５のテーブル構成で管理するものを示したが、各種管理データの構成や管理方法は図４や図５のものに限定されないことは勿論である。
【図面の簡単な説明】
【００８９】
【図１】第１の実施形態のプレゼンスサービスシステムに係るネットワークの機能的構成を示すブロック図である。
【図２】第１の実施形態のプレゼンスサーバの詳細構成を示すブロック図である
【図３】第１の実施形態のＨＳＳ機能をも担当するＳ−ＣＳＣＦの詳細構成を示すブロック図である。
【図４】第１の実施形態のＳ−ＣＳＣＦにおけるＲＥＧＩＳＴＥＲ信号ルーチング管理テーブルの構成を示す説明図である。
【図５】第１の実施形態のプレゼンスサーバにおける信号送信先管理テーブルの構成を示す説明図である。
【図６】第１の実施形態のＳ−ＣＳＣＦにおけるＲＥＧＩＳＴＥＲ信号が到来した際の動作を示すフローチャートである。
【図７】第１の実施形態のプレゼンスサーバにおけるＲＥＧＩＳＴＥＲ信号が到来した際の動作を示すフローチャートである。
【図８】第１の実施形態に係るプレゼンスサービスシステムのシーケンス例を示すシーケンス図である。
【図９】第２の実施形態に係るプレゼンスサービスシステムのシーケンス例を示すシーケンス図である。
【符号の説明】
【００９０】
１…ウォッチャＩＭＳ端末、２…プレゼンティティＩＭＳ端末、３…Ｐ−ＣＳＣＦ、４…Ｉ−ＣＳＣＦ、５…Ｓ−ＣＳＣＦ（サービングサーバ）、６…ＨＳＳ／ＳＬＦ、７…プレゼンスサーバ、８…アプリケーションサーバ、１０…プレゼンスサービスシステム、ＴＢＬ１…ＲＥＧＩＳＴＥＲ信号ルーチング管理テーブル、ＴＢＬ２…信号送信先管理テーブル。
【図１】
2008131590.tif 000003
【図２】
2008131590.tif 000004
【図３】
2008131590.tif 000005
【図４】
2008131590.tif 000006
【図５】
2008131590.tif 000007
【図６】
2008131590.tif 000008
【図７】
2008131590.tif 000009
【図８】
2008131590.tif 000010
【図９】
2008131590.tif 000011