(57)【要約】  方法が開示される。ＩＰマルチメディアサブシステムＩＭＳのサービング呼セッション制御機能Ｓ−ＣＳＣＦが使用する方法であって、Ｓ−ＣＳＣＦがユーザへの提供を管理する複数のサービスのそれぞれに関して、サービスを提供するＩＭＳアプリケーションサーバＡＳの課金能力を判定する工程と、サービスに係わる課金情報の生成でＡＳと連携する工程とを備える方法。このようにして、Ｓ−ＣＳＣＦとＡＳとの課金情報の無用な重複を回避するために、Ｓ−ＣＳＣＦはＡＳと連携できる。Ｓ−ＣＳＣＦは、Ｓ−ＣＳＣＦとＡＳでの課金情報の無用な取り損ないを回避するためにも、ＡＳと連携できる。
2011505084.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰマルチメディアサブシステム（ＩＭＳ）におけるサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）によって使用される方法であって、
前記Ｓ−ＣＳＣＦによって管理され複数のユーザへ提供される複数のサービスのそれぞれについて、前記ＩＭＳにおいてサービスを提供するアプリケーションサーバ（ＡＳ）の課金能力を判別するステップと、
前記ＡＳと協働して前記サービスに関する課金情報を生成するステップと
を備えることを特徴とする方法。
【請求項２】
前記判別された課金能力を使用してどの装置で課金情報が生成されるべきかを決定するステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記ＡＳと協働し、前記Ｓ−ＣＳＣＦと前記ＡＳとの間において課金情報の不必要な複製を回避するステップをさらに備えることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記ＡＳと協働し、前記Ｓ−ＣＳＣＦと前記ＡＳとの間において課金情報の不必要な消失を回避するステップをさらに備えることを特徴とする請求項１ないし３のいずれか１項に記載の方法。
【請求項５】
前記ＡＳと課金能力を示す課金能力情報を交換するステップをさらに備えることを特徴とする請求項１ないし４のいずれか１項に記載の方法。
【請求項６】
各ＡＳを識別するための記録を維持管理するステップをさらに備えることを特徴とする請求項１ないし５のいずれか１項に記載の方法。
【請求項７】
各ＡＳごとの判別した前記課金情報を維持管理するステップをさらに備えることを特徴とする請求項１ないし６のいずれか１項に記載の方法。
【請求項８】
登録手順の一部において受信した初期フィルタ基準（ＩＦＣ）を使用するサービスを提供しているＡＳを判別するステップをさらに備えることを特徴とする請求項１ないし７のいずれか１項に記載の方法。
【請求項９】
登録手順の一部として、前記課金能力を判別するステップを実行することを特徴とする請求項１ないし８のいずれか１項に記載の方法。
【請求項１０】
インバイト手順の一部として、前記課金能力を判別するステップを実行することを特徴とする請求項１ないし９のいずれか１項に記載の方法。
【請求項１１】
前記手順は、セッション開始プロトコル（ＳＩＰ）手順であることを特徴とする請求項８ないし１０のいずれか１項に記載の方法。
【請求項１２】
前記ＡＳに対する最初のトラフィック送受信の際に、前記課金能力を判別するステップを実行することを特徴とする請求項１ないし１１のいずれか１項に記載の方法。
【請求項１３】
セッション開始プロトコル（ＳＩＰ）メソッドを使用して前記ＡＳの課金能力を判別するステップを備えることを特徴とする請求項１ないし１２のいずれか１項に記載の方法。
【請求項１４】
前記ＡＳの課金能力を判別するステップは、前記Ｓ−ＣＳＣＦと前記ＡＳとの間で実行されるセッション開始プロトコル（ＳＩＰ）のＯＰＴＩＯＮＳメソッドに対する応答に拡張記述言語（ＸＭＬ）のボディ部を使用するステップを含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記応答は、２００ ＯＫ 応答であることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記ＡＳの課金能力を判別するステップは、前記Ｓ−ＣＳＣＦと前記ＡＳとの間で実行されるセッション開始プロトコル（ＳＩＰ）のＯＰＴＩＯＮＳメソッドにおける課金能力の情報を含むセッション開始プロトコル（ＳＩＰ）のプライベートヘッダを使用するステップを含むことを特徴とする請求項１３に記載の方法。
【請求項１７】
前記ＡＳの課金能力を判別するステップは、前記ＡＳにおいて受信されるセッション開始プロトコル（ＳＩＰ）のＲＥＧＩＳＴＥＲメッセージに対する応答である２００ ＯＫ 応答に含まれている課金能力の情報を有したＳＩＰプライベートヘッダを使用するステップを含むことを特徴とする請求項１３に記載の方法。
【請求項１８】
前記ＡＳの課金能力を判別するステップは、ライトウエイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）における前記ＡＳへのリクエストまたはハイパーテキスト転送プロトコル（ＨＴＴＰ）における前記ＡＳへのリクエストを使用するステップを含むことを特徴とする請求項１３に記載の方法。
【請求項１９】
前記判別された課金能力に応じて課金情報を生成するステップを備えることを特徴とする請求項１ないし１８のいずれか１項に記載の方法。
【請求項２０】
ＩＰマルチメディアサブシステム（ＩＭＳ）におけるアプリケーションサーバ（ＡＳ）によって使用される方法であって、前記ＡＳは、少なくとも１つのユーザに対してサービスを提供するＡＳであり、
前記方法は、
前記ユーザに対して提供される前記サービスを管理しているサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）に対して、前記ＡＳの課金能力を通知するステップと、
前記Ｓ−ＣＳＣＦと協働して、前記サービスに関する課金情報を生成するステップと
を備えることを特徴とする方法。
【請求項２１】
セッション開始プロトコル（ＳＩＰ）を使用可能な第２ノードの課金能力を決定するために、ＳＩＰを使用可能な第１ノードによって使用される方法であって、
前記第１ノードと前記第２ノードとの間で実行されるＳＩＰ ＯＰＴＩＯＮＳ メソッドに対する応答において前記課金能力を示す情報を搬送するために、拡張記述言語（ＸＭＬ）のボディ部を使用するステップを備えることを特徴とする方法。
【請求項２２】
前記応答は、２００ ＯＫ 応答であることを特徴とする請求項２１に記載の方法。
【請求項２３】
前記第１ノードおよび前記第２ノードは、それぞれＩＰマルチメディアサブシステム（ＩＭＳ）のノードであることを特徴とする請求項２１または２２に記載の方法。
【請求項２４】
ＩＰマルチメディアサブシステム（ＩＭＳ）におけるサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）において使用されるかまたはＳ−ＣＳＣＦとして使用される装置であって、
前記Ｓ−ＣＳＣＦによって管理され複数のユーザへ提供される複数のサービスのそれぞれについて、前記ＩＭＳにおいてサービスを提供するアプリケーションサーバ（ＡＳ）の課金能力を判別する手段と、
前記ＡＳと協働して前記サービスに関する課金情報を生成する手段と
を備えることを特徴とする装置。
【請求項２５】
ＩＰマルチメディアサブシステム（ＩＭＳ）におけるアプリケーションサーバ（ＡＳ）において使用されるかまたはＡＳとして使用される装置であって、前記ＡＳは、少なくとも１つのユーザに対してサービスを提供するＡＳであり、
前記装置は、
前記ユーザに対して提供される前記サービスを管理しているサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）に対して、前記ＡＳの課金能力を通知する手段と、
前記Ｓ−ＣＳＣＦと協働して、前記サービスに関する課金情報を生成する手段と
を備えることを特徴とする装置。
【請求項２６】
セッション開始プロトコル（ＳＩＰ）を使用可能な第２ノードの課金能力を決定するために、ＳＩＰを使用可能な第１ノードにおいて使用されるかまたは前記第１ノードとして使用される装置であって、
前記第１ノードと前記第２ノードとの間で実行されるＳＩＰ ＯＰＴＩＯＮＳ メソッドに対する応答において前記課金能力を示す情報を搬送するために、拡張記述言語（ＸＭＬ）のボディ部を使用する手段を備えることを特徴とする装置。
【請求項２７】
装置に、請求項１ないし２３のいずれか１項に記載された方法を実行させることを特徴とするプログラム。
【請求項２８】
装置に対してロードされると、請求項２４ないし２６のいずれか１項に記載された前記装置として当該装置を機能させることを特徴とするプログラム。
【請求項２９】
搬送媒体により搬送されることを特徴とする請求項２７または２８に記載のプログラム。
【請求項３０】
前記搬送媒体は、記憶媒体であることを特徴とする請求項２９に記載のプログラム。
【請求項３１】
前記搬送媒体は、通信媒体であることを特徴とする請求項２９に記載のプログラム。
【請求項３２】
請求項２７ないし３１のいずれか１項に記載のプログラムによってプログラムされた装置。
【請求項３３】
請求項２７ないし３０のいずれか１項に記載のプログラムを記憶したことを特徴とする記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えばＩＰマルチメディアサブシステムを有するＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）などの通信ネットワークにおいて使用するための方法および装置に関する。
【背景技術】
【０００２】
ＩＰマルチメディアサービスは、同じセッション内で音声、映像、メッセージング、データ等の動的組み合わせを提供する。基本アプリケーション数の増加および組み合わせ可能なメディアの発展によって、エンドユーザに提供されるサービス数が増加し、対人通信のエクスペリエンス（体験）が豊かになるであろう。これは、いわゆる「コンビネーション型ＩＰマルチメディア」サービスを含む、パーソナルでリッチなマルチメディア通信サービスの新世代に導くであろう。
【０００３】
ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）は、加入者により高いデータレートおよび高度サービスを提供するように設計された第３世代の無線システムである。ＵＭＴＳは、ＧＳＭ（Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）の後継システムであり、ＧＳＭからＵＭＴＳへの重要な進歩はＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）である。ＧＰＲＳは、ＧＳＭコアネットワークにパケット交換を採用し、パケットデータネットワーク（ＰＤＮ）への直接アクセスを可能にする。これは、ＧＳＭ電話ネットワークを通じて、ＩＳＤＮの６４ｋｂｐｓの限界をはるかに超える高データレートパケット交換伝送を可能にするが、このことは、最高２ＭｂｐｓのＵＭＴＳデータ伝送レートのために不可欠である。ＵＭＴＳは、第３世代パートナーシッププロジェクト（３ＧＰＰ）によって標準化されているが、３ＧＰＰは、欧州電気通信標準化機構（ＥＴＳＩ）、社団法人電波産業会（ＡＲＩＢ）などのような地域標準化団体の集合である。詳細については、非特許文献１を参照されたい。
【０００４】
ＵＭＴＳアーキテクチャは、従来の電話および新しいＩＰマルチメディアサービスを利用可能にするＩＰマルチメディアサブシステム（ＩＭＳ）として知られるサブシステムを有する（非特許文献２、３、４、５、６、７、８）。ＩＭＳは、ＩＰベースのネットワーク上で新しい豊かな個人対個人（クライアント対クライアント）通信サービスおよび個人対コンテンツ（クライアント対サーバ）サービスを促進する標準ＩＭＳサービスイネーブラの使用によって、エンドユーザの個人対個人通信エクスペリエンスを豊かにするための重要な特徴を提供する。ＩＭＳは、ＰＳＴＮ／ＩＳＤＮ（公衆交換電話網／サービス総合デジタル網）にもインターネットにも接続できる。
【０００５】
ＩＭＳは、ユーザ端末間（またはユーザ端末とアプリケーションサーバとの間）の呼やセッションの設定および制御のために、セッション開始プロトコル（ＳＩＰ）を使用する。ＳＩＰシグナリングで運ばれるセッション記述プロトコル（ＳＤＰ）が、セッションのメディアコンポーネントを記述およびネゴシエートするために使用される。ＳＩＰはユーザ対ユーザのプロトコルとして作成されたが、ＩＭＳにより、オペレータおよびサービスプロバイダは、サービスへのユーザアクセスの制御およびそれに応じたユーザへの課金が可能になる。３ＧＰＰは、ユーザ装置（ＵＥ）とＩＭＳとの間およびＩＭＳ内のコンポーネント間のシグナリングにＳＩＰを選んだ。
【０００６】
ＵＭＴＳ通信ネットワークの動作およびそのネットワーク内における種々のコンポーネントの具体的詳細については、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手できるＵＭＴＳの技術仕様書の中に見つけることができる。ＵＭＴＳ内でのＳＩＰ使用のさらなる詳細については、非特許文献９の中に見つけることができる。
【０００７】
添付図面の図１は、ＧＰＲＳ／ＰＳアクセスネットワークの場合に、ＩＭＳがモバイルネットワークアーキテクチャにどのようにはめ込まれるかの概要を示す（ＩＭＳは、もちろん他のアクセスネットワーク上でも動作できる）。呼セッション制御機能（ＣＳＣＦ）はＩＭＳ内のＳＩＰプロキシとして動作する。３ＧＰＰのアーキテクチャは、３タイプのＣＳＣＦを規定し、それらは、ＳＩＰ端末に対するＩＭＳ内の最初のコンタクトポイントであるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）と、ユーザが契約しているサービスをユーザに提供するサービング（在圏）ＣＳＣＦ（Ｓ−ＣＳＣＦ）と、正しいＳ−ＣＳＣＦを識別し、ＳＩＰ端末からＰ−ＣＳＣＦ経由で受信した要求をそのＳ−ＣＳＣＦに転送する役割のインテロゲーティング（問い合せ側）ＣＳＣＦ（Ｉ−ＣＳＣＦ）とである。
【０００８】
ユーザは、仕様が定められているＳＩＰ  ＲＥＧＩＳＴＥＲメソッドを用いてＩＭＳに登録する。これは、ＩＭＳに接続し、ＳＩＰユーザアイデンティティに対して到達しうるアドレスをＩＭＳに通知するメカニズムである。３ＧＰＰでは、ＳＩＰ端末が登録を実行すると、ＩＭＳがユーザを認証し、利用可能なＳ−ＣＳＣＦのセットの中からそのユーザに１つのＳ−ＣＳＣＦを割り当てる。Ｓ−ＣＳＣＦを割り当てるための基準は、３ＧＰＰによって明示されていないが、これには負荷分散およびサービス要件を含んでもよい。Ｓ−ＣＳＣＦの割り当ては、ＩＭＳベースサービスへのユーザアクセスの制御（および課金）の要であることが知られている。オペレータは、ユーザ対ユーザの直接のＳＩＰセッションを防ぐメカニズムを設けてもよく、そうしないと、ユーザ対ユーザの直接のＳＩＰセッションはＳ−ＣＳＣＦを迂回するであろう。
【０００９】
登録プロセス中、Ｓ−ＣＳＣＦがまだ選択されていない場合にＳ−ＣＳＣＦを選択するのは、Ｉ−ＣＳＣＦの担当である。Ｉ−ＣＳＣＦは、ホームネットワークのホーム加入者サーバ（ＨＳＳ）から必要なＳ−ＣＳＣＦ能力を受信し、受信した能力に基づいて適切なＳ−ＣＳＣＦを選択する。（ユーザに別の発呼者から着信があり、ユーザが現在Ｓ−ＣＳＣＦを割り当てられていない場合も、Ｉ−ＣＳＣＦがそのユーザに対してＳ−ＣＳＣＦの割り当てを実行することが知られている）。登録されたユーザが続いてセッション要求をＩＭＳに送信すると、Ｐ−ＣＳＣＦは、登録プロセス中にＳ−ＣＳＣＦから受信した情報に基づいて、選択されたＳ−ＣＳＣＦに要求を転送できる。
【００１０】
ＩＭＳサービス機能を実施するために、ＩＭＳサービスネットワーク内にアプリケーションサーバ（ＡＳ）が設けられる。アプリケーションサーバは、ＩＭＳシステムのエンドユーザにサービスを提供し、３ＧＰＰ規定のＭｒインタフェースを通じてエンドポイントとして接続されるか、または３ＧＰＰ規定のＩＳＣインタフェースを通じてＳ−ＣＳＣＦによって「リンクイン」されてもよい。リンクインされる場合は、ＳＩＰセッション確立中にどのアプリケーションサーバを「リンクイン（linked in）」すべきかを決定するために、Ｓ−ＣＳＣＦは、初期フィルタ基準（ＩＦＣ）を使用する。呼が異なる場合には、異なるＩＦＣが適用されてもよい。ＩＦＣは、ＩＭＳ登録手順中にユーザのユーザプロファイルの一部として、Ｓ−ＣＳＣＦがＨＳＳから受信する。（アプリケーションサーバを制御するネットワークに「属する」被呼加入者かまたは発呼加入者のどちらかの）加入者アイデンティティ（識別情報）に依存して特定のアプリケーションサーバが、動作を実行することになる。例えば、呼転送の場合は、適切な（着信）アプリケーションサーバが、所与の加入者への呼をが転送される新しい着信相手を決定するであろう。ＩＦＣが、Ｓ−ＣＳＣＦで受信されたＳＩＰメッセージは特定のＳＩＰ  ＡＳに転送されるべきであると示す場合は、そのＡＳはメッセージパスに加えられる。ＡＳがＳＩＰメッセージをＳ−ＣＳＣＦに戻すと、そのメッセージは、その最終宛先に向けて転送されるか、またはＩＦＣに示されている場合、別のＡＳに転送される。
【００１１】
非特許文献１０は、ＩＭＳ課金のアーキテクチャおよび原理を規定し、それによって課金情報をいつ送信し、課金情報をいつ送信しないかを規定している。非特許文献３は、サービス実行ネットワーク要素であるアプリケーションサーバ（ＡＳ）とサービストリガ解析およびトラヒック課金機能を担当するコア要素としてのＳ−ＣＳＣＦとの間の相互作用のフレームワークを規定するアーキテクチャおよびインタフェースを明確に記載している。システムの主要要素について、添付図面の図２に概要が示されている。非特許文献３の４．２．４章では、Ｓ−ＣＳＣＦとサービスプラットフォーム（例えばＡＳ）との間のＩＰマルチメディアサービス制御（ＩＳＣ）インタフェースを記載している。ＳＩＰアプリケーションサーバは、サービスをホストし実行してもよい。ＳＩＰアプリケーションサーバは、サービスのためにＳＩＰセッションに作用し強い影響を与えてもよく、Ｓ−ＣＳＣＦと通信するためにＩＳＣインタフェースを使用する。
【００１２】
任意のサービスの実施状況において、この特定のサービスまたはセッションに関して（オフライン課金用の）課金記録の生成かまたは（オンライン課金用の）割当額／承認の要求のために、少なくとも１つの課金決定点が存在しなければならない。オフライン課金は後払いタイプの課金方式スキームであり、ユーザがサービスを消費した後に課金が行われ、例えばユーザは、前月の課金対象項目を示す月々の請求書を受け取るかもしれない。オンライン課金は前払いタイプの課金方式スキームであり、ユーザが要求したサービスへのアクセスを許可する前に、ネットワークエンティティが課金システムと情報を交換するであろう。
【００１３】
非特許文献１０および１１によれば、種々のＩＭＳノードがチャージングトリガ（課金契機）機能（ＣＴＦ、Charging Triggering Function）の役を務めてもよいが、特に、Ｓ−ＣＳＣＦまたはＡＳ（または両方）は、ほとんどのトラヒックイベントおよびすべてのサービス実施時にＣＴＦの役を務めることができる。
【先行技術文献】
【非特許文献】
【００１４】
【非特許文献１】３ＧＰＰ  ＴＳ  ２３．００２
【非特許文献２】３ＧＰＰ  ＴＳ  ２２．２２８  リリース５〜７
【非特許文献３】３ＧＰＰ  ＴＳ  ２３．２２８  リリース５〜７
【非特許文献４】３ＧＰＰ  ＴＳ  ２４．２２９  リリース５〜７
【非特許文献５】３ＧＰＰ  ＴＳ  ２９．２２８  リリース５〜７
【非特許文献６】３ＧＰＰ  ＴＳ  ２９．２２９  リリース５〜７
【非特許文献７】３ＧＰＰ  ＴＳ  ２９．３２８  リリース５〜７
【非特許文献８】３ＧＰＰ  ＴＳ  ２９．３２９  リリース５〜７
【非特許文献９】３ＧＰＰ  ＴＳ  ２４．２２８  Ｖ５．８．０（２００４年３月）
【非特許文献１０】３ＧＰＰ  ＴＳ  ３２．２６０
【非特許文献１１】３ＧＰＰ  ＴＳ  ３２．２９９
【非特許文献１２】ＩＥＴＦ  ＲＦＣ３２６１
【非特許文献１３】ＩＥＴＦ  ＲＦＣ３８４０
【非特許文献１４】ＩＥＴＦ  ＲＦＣ２７０３
【発明の概要】
【発明が解決しようとする課題】
【００１５】
本願の出願人者は、現在定められている状況について、以下の問題を認識している。
【００１６】
当該ＡＳにどのような能力が組み入れられているかを、ＡＳ毎または実行されるサービス毎に、Ｓ−ＣＳＣＦが区別できるメカニズムが現在のところない。特に課金能力となると、呼び出されるＡＳがＣＴＦの役を果たせるか否かを、Ｓ−ＣＳＣＦが前もって知ることは不可能である。その結果として、（Ｓ−ＣＳＣＦとＡＳの両方からの）二重の課金情報を避けるために、ＡＳが呼び出されるとき、Ｓ−ＣＳＣＦはなんとかして課金しないように設定可能でなければならない。
【００１７】
Ｓ−ＣＳＣＦが利用可能な唯一のＡＳ情報は、ありとあらゆるユーザに対して設定されるＩＦＣサービストリガデータの一部としてダウンロードされるＳＩＰ  ＵＲＩおよび場合により（通信サービス識別子としての）特性タグである。
【００１８】
Ｓ−ＣＳＣＦにおける設定オプションの使用は、すべてのＡＳに包括的な「全部かゼロか」の決定を意味する。そうしないと、Ｓ−ＣＳＣＦは、新しいＡＳがネットワークに導入されるたびに変更されなければならないであろうからである。言い換えると、ＡＳが呼び出されるときにありうるＳ−ＣＳＣＦの課金機能の無力化は、そのＡＳの能力に基づいておらず、ありうる二重の課金情報を受け入れるか否かのオペレータの広範囲の決定に基づいている。
【００１９】
本出願者本願の出願人が特定し説明した上記の問題に取り組むことが望ましい。
【課題を解決するための手段】
【００２０】
本発明の第１の態様によれば、ＩＰマルチメディアサブシステムＩＭＳのサービング呼セッション制御機能Ｓ−ＣＳＣＦが使用する方法が提供される。この方法は、Ｓ−ＣＳＣＦがユーザへの提供を管理する複数のサービスのそれぞれに関して、サービスを提供するＩＭＳアプリケーションサーバＡＳの課金能力を判定する工程と、サービスに係わる課金情報の生成においてＡＳと連携する工程とを備える。
【００２１】
判定された課金能力は、課金情報をどこで生成するかを決定するために使用されてもよく、例えば、課金情報をＳ−ＣＳＣＦだけで、またはＡＳだけで、または適切に連携して両方で生成するように決定できよう。これにより、判定された課金能力に基づいて選択された最も適切な場所で、課金情報を生成することが可能になる。
【００２２】
本発明を具体化する一方法は、Ｓ−ＣＳＣＦとＡＳとの課金情報の無用な重複を避けるために、Ｓ−ＣＳＣＦがＡＳと連携するのを都合よく可能にする。
【００２３】
本発明を具体化する一方法は、Ｓ−ＣＳＣＦとＡＳでの課金情報の無用な取り損ないを避けるために、Ｓ−ＣＳＣＦがＡＳと連携するのを都合よく可能にする。
【００２４】
課金能力情報はＡＳと交換されてもよく、そのような情報の二方向の流れによって、課金情報を生成するためのノード間での連携の基盤を形成してもよい。
【００２５】
各ＡＳを識別する記録が維持されてもよく、この記録には各ＡＳの判定された課金能力を組み入れてもよく、この記録は後での使用で参照する。
【００２６】
オプションとして、どのＡＳがサービスを提供するかは、登録手順の一部として受信した初期フィルタ基準ＩＦＣを使用して決定されてもよい。
【００２７】
本発明の一実施形態は、課金能力がいつ判定されるかに関して融通性を与え、この点に関して、課金能力判定工程は、例えば、登録手順の一部として、または招待手順の一部として実行されてもよい。登録手順および招待手順は、セッション開始プロトコルＳＩＰの登録手順および招待手順でもよい。あるいは、課金能力判定工程は、ＡＳとの最初のトラヒックインターアクション（送受信）交流で実行できよう。
【００２８】
ＡＳの課金能力を判定するために使用される方法に関しても融通性がある。オプションとして、ＡＳの課金能力は、セッション開始プロトコルＳＩＰメソッドを用いて判定されてもよい。
【００２９】
例えば、オプションとして、ＡＳの課金能力は、Ｓ−ＣＳＣＦとＡＳとの間で実行されたセッション開始プロトコルＳＩＰ  ＯＰＴＩＯＮＳメソッドに対する２００ＯＫ応答などの応答の中で、拡張可能なマークアップ言語ＸＭＬのボディ部を用いて判定されてもよい。
【００３０】
ＡＳの課金能力はまた、Ｓ−ＣＳＣＦとＡＳとの間で実行されるセッション開始プロトコルＳＩＰ  ＯＰＴＩＯＮＳメソッドにおいて、能力を含むセッション開始プロトコルＳＩＰのプライベートヘッダを用いて判定されてもよい。
【００３１】
さらなるオプションとして、ＡＳの課金能力は、ＡＳで受信したセッション開始プロトコルＳＩＰのＲＥＧＩＳＴＥＲメッセージに対する２００ＯＫ応答の中で、能力を含むＳＩＰプライベートヘッダを用いて判定されてもよい。
【００３２】
さらなるオプションとして、ＡＳの課金能力は、ＡＳへのライトウェイト・ディレクトリ・アクセス・プロトコルＬＤＡＰ要求またはハイパーテキスト転送プロトコルＨＴＴＰ要求を用いて判定されてもよい。
【００３３】
本発明の一実施形態では、判定された課金能力に基づいて課金情報を生成させることができるが、これは、これまでに提案されていない。
【００３４】
本発明の第２の態様によれば、ＩＰマルチメディアサブシステムＩＭＳのアプリケーションサーバＡＳで、かつ少なくとも１人のユーザにサービスを提供するＡＳが使用する方法が提供される。この方法は、ユーザへのサービスの提供を管理する、ＩＭＳのサービング呼セッション制御機能Ｓ−ＣＳＣＦへＡＳの課金能力を提供する工程を備える。次いでＡＳは、サービスに係わる課金情報の生成でＳ−ＣＳＣＦと提携する。
【００３５】
本発明の第３の態様によれば、ネットワークの第１のセッション開始プロトコルＳＩＰ使用可能ノードが、ネットワークの第２のＳＩＰ使用可能ノードの能力情報を判定するために使用する方法が提供される。この方法は、第１のノードと第２のノードとの間で実行されたＳＩＰ  ＯＰＴＩＯＮＳメソッドに応えて能力情報を伝えるために、拡張可能なマークアップ言語ＸＭＬのボディの使用を含む。
【００３６】
オプションとして、応答は２００ＯＫ応答である。この方法のＩＰマルチメディアサブシステムＩＭＳへの適用では第１のノードおよび第２のノードはＩＭＳノードであろうが、この方法は、ＩＭＳに適用されるととりわけ有利であるが、ＩＭＳだけに有利というわけではない。
【００３７】
本発明の第４の態様によれば、ＩＰマルチメディアサブシステムＩＭＳのサービング呼セッション制御機能Ｓ−ＣＳＣＦとしてかまたはその中で使用する装置が提供される。この装置は、Ｓ−ＣＳＣＦがユーザへの提供を管理する複数のサービスのそれぞれに関して、サービスを提供するＩＭＳアプリケーションサーバＡＳの課金能力を判定する手段を備える。装置は、サービスに係わる課金情報の生成でＡＳと連携する手段も備える。
【００３８】
本発明の第５の態様によれば、少なくとも１人のユーザにサービスを提供するＩＰマルチメディアサブシステムＩＭＳアプリケーションサーバＡＳとしてかまたはその中で使用する装置が提供される。この装置は、ユーザへのサービスの提供を管理する、ＩＭＳのサービング呼セッション制御機能Ｓ−ＣＳＣＦにＡＳの課金能力を提供する手段を備える。装置は、サービスに係わる課金情報の生成でＳ−ＣＳＣＦと連携する手段も備える。
【００３９】
本発明の第６の態様によれば、ネットワークの第１のセッション開始プロトコルＳＩＰ使用可能ノードとしてかまたはその中で使用する装置が提供される。この装置は、第１のノードと第２のノードとの間で実行されたＳＩＰ  ＯＰＴＩＯＮＳメソッドに対する応答の中の、能力情報を伝える拡張可能なマークアップ言語ＸＭＬのボディから、ネットワークの第２のＳＩＰ使用可能ノードの能力情報を判定する手段を備える。
【００４０】
本発明の第７の態様によれば、本発明の第１乃至第３のいずれかの態様による方法を実行するように装置を制御するか、または装置にロードされると装置を本発明の第４乃至第６のいずれかの態様による装置になるようにするプログラムが提供される。このプログラムは、運搬搬送媒体で運ばれてもよい。運搬搬送媒体は記憶媒体でもよい。運搬搬送媒体は伝送媒体でもよい。
【００４１】
本発明の第８の態様によれば、本発明の第７の態様によるプログラムによってプログラムされた装置が提供される。
【００４２】
本発明の第９の態様によれば、本発明の第７の態様によるプログラムを格納する記憶媒体が提供される。
【００４３】
本発明の別の態様は、ネットワークの第１のセッション開始プロトコルＳＩＰ使用可能ノードが、ネットワークの第２のＳＩＰ使用可能ノードの能力情報を判定するために使用する方法および装置を提供し、この方法は、第１のノードと第２のノードとの間で実行されるＳＩＰ  ＯＰＴＩＯＮＳメソッドにおいて、能力を伝えるためにＳＩＰプライベートヘッダの使用を含む。
【００４４】
本発明の別の態様は、ネットワークの第１のセッション開始プロトコルＳＩＰ使用可能ノードが、ネットワークの第２のＳＩＰ使用可能ノードの能力情報を判定するために使用する方法および装置を提供し、この方法は、第２のノードが受信したＳＩＰ  ＲＥＧＩＳＴＥＲメッセージに対する２００ＯＫ応答の中で、能力を伝えるＳＩＰプライベートヘッダの使用を含む。
【００４５】
本発明の別の態様は、ネットワークの第１のセッション開始プロトコルＳＩＰ使用可能ノードが、ネットワークの第２のＳＩＰ使用可能ノードの能力情報を判定するために使用する方法および装置を提供し、この方法は、第２のノードへのライトウェイト・ディレクトリ・アクセスライトウエイト・ディレクトリ・アクセス・プロトコルＬＤＡＰ要求またはハイパーテキスト転送プロトコルＨＴＴＰ要求の使用を含む。
【００４６】
本発明の技術的利点は、特定の呼／サービスに対して当該ＡＳの能力に応じて最適のＣＴＦを選択でき、それによってネットワークリソースの使用を最適化させることができ、課金情報の重複を確実に回避でき、課金情報を取り損なうことも全くなくなることである。
【図面の簡単な説明】
【００４７】
【図１】前述の、ＩＰマルチメディアサブシステムの３Ｇ移動通信システムへの統合を概略的に示す図である。
【図２】同様に前述の、本発明の背景の説明で使用するネットワークの主要要素の概念図である。
【図３】本発明を具体化する第１の例による動作を示すメッセージ交換図である。
【図４】本発明を具体化する第２の例による動作を示すメッセージ交換図である。
【図５】本発明を具体化する第３の例による動作を示すメッセージ交換図である。
【図６】本発明を具体化するＳ−ＣＳＣＦおよびＡＳの概念図である。
【発明を実施するための形態】
【００４８】
上記説明のように、当該ＡＳにどのような能力が組み入れられているかを、ＡＳ毎または実行されるサービス毎に、Ｓ−ＣＳＣＦが区別できるメカニズムは現在のところない。そこで、二重の課金情報を回避するために、現在のところＡＳが呼び出されるとき課金をやめるように、「全部かゼロか」の基準でオペレータが一元的に制御して設定可能でなければならない。
【００４９】
この制限を克服するために、ＩＭＳのＳ−ＣＳＣＦエンティティとＡＳエンティティの関連では、課金能力情報交換メカニズムが配備されなければならない。
【００５０】
他方では、非特許文献１２のＳＩＰで既に仕様が定められている既存のメカニズムがあり、ＯＰＴＩＯＮＳメソッドの使用ならびにＡｌｌｏｗ、Ａｃｃｅｐｔ、Ａｃｃｅｐｔ−ＬａｎｇｕａｇｅおよびＳｕｐｐｏｒｔｅｄのヘッダの使用に基づいて、ＳＩＰエンティティ間の能力情報の交換を促進している。
【００５１】
Ａｌｌｏｗ、Ａｃｃｅｐｔ、Ａｃｃｅｐｔ−ＬａｎｇｕａｇｅおよびＳｕｐｐｏｒｔｅｄのヘッダのフィールドは、ユーザエージェントの能力について幾らかの情報を伝える。しかし、これらのヘッダフィールドは、必要な情報の少しの部分しか伝えない。それらは、能力の表示に関して全体のフレームワークを提供しない。さらに、それらは能力を間接的に述べるにすぎず、ヘッダフィールドは、この要求に適用されるとき、実際にはＵＡの能力を示す。ＳＩＰは、特徴すなわちＵＡを描写する情報を伝える能力も持たない。
【００５２】
ＳＩＰ  ＯＰＴＩＯＮＳメソッドは、非特許文献１３にさらに仕様が定められており、ＵＡが他のＵＡまたはプロキシサーバにその能力を問い合わせるのを可能にする。これにより、クライアントは、相手に「電話すること」なしに、サポートされているメソッド、コンテンツタイプ、拡張、コーデック等の情報を発見できる。例えば、クライアントは、宛先のユーザエージェントサーバ（ＵＡＳ）がサポートしているかどうか確かでないオプションを載せているＲｅｑｕｉｒｅヘッダフィールドをＩＮＶＩＴＥに挿入する前に、このオプションがＳｕｐｐｏｒｔｅｄヘッダフィールドの中で返信されるかどうかを見るために、ＯＰＴＩＯＮＳで宛先のＵＡＳに問い合わせてもよい。すべてのＵＡは、ＩＭＳ関連のＡＳも含めて、ＯＰＴＩＯＮＳメソッドをサポートしなければならない。
【００５３】
従って、これは、ＳＩＰにおける能力および特徴の表示に関して、より一般的なフレームワークを提供すると考えられる。ＵＡについての能力および特徴の情報は、Ｃｏｎｔａｃｔヘッダフィールドのパラメータとして伝えられてもよい。これらのパラメータは、ＲＥＧＩＳＴＥＲ要求および応答、ＯＰＴＩＯＮＳ応答、ならびに（ＩＮＶＩＴＥなどの）対話を作り出す要求および応答の中で使用されてもよい。
【００５４】
以下に、ＲＦＣが何を「能力(capability)」および「特徴(characteristic)」と考えているかについて述べる。
【００５５】
非特許文献１４に定義されているように、「能力」は、特定のタイプのメッセージコンテンツを生成または処理する能力を示す送信機または受信機（たいていは受信機）の属性である。能力は任意の特定の呼で使用されてもよいし、また使用されなくてもよいのに対して、特徴が交渉の余地のないＵＡの属性であるという点で、能力は特徴と異なる。ＳＩＰ自体が、呼に対して能力を使用するか否かをたいていネゴシエートする。
【００５６】
「特徴」は能力のようであるが、交渉できないＵＡの一面を描写する。一例として、ＵＡが携帯電話機であるか否かは特徴であり、能力ではない。本明細書のセマンティックス(semantics)では、能力と特徴との間で違いが出てこないが、区別は説明目的に役立つ。
【００５７】
ＳＩＰレベルでは、これらのメカニズムは周知であり、スタンダードトラックのＲＦＣおよびＩＡＮＡ登録（ＩＡＮＡｒｅｇ）によって標準化されており、能力を登録するとき通常のプロセスに従うことも求めている。特性に関するそれらのメカニズム、メディア特性、ならびに特性タグおよびオプションタグは、前述の登録およびスタンダードトラックおよび情報のＲＦＣを用いた定義を必要とするだけでなく、ＩＥＴＦコミュニティで受け入れられる合意も必要とする。
【００５８】
いずれにしても、ＩＭＳエンティティの固有の本質および相互関係の取り方のために、これらの課金能力情報を交換するための特定のメカニズムを必要とし、ここで説明する。
【００５９】
本発明の一実施形態によれば、ＩＭＳネットワークに定義済みで、それ故そのＩＭＳネットワークユーザに設定された任意のＩＦＣに割り当てられたＡＳと、当該ユーザが登録されている対応するＳ−ＣＳＣＦとの間で、課金能力情報の交換を可能にするメカニズムが提供される。Ｓ−ＣＳＣＦは、ＩＦＣの中に見つけた新しいＡＳと通信し、応答の中に見つけたＡＳ能力情報を格納する。
【００６０】
ＡＳに係わる呼／サービスのそれぞれに関して、Ｓ−ＣＳＣＦは、そのＡＳの能力に基づいて課金情報を生成するか否かを選ぶ。これは、ネットワークが生成する課金情報の最適化を可能にし、こうすることにより、二重の課金情報および特定のサービス／ＡＳに関して課金情報を生成しないリスクを、回避することができる。
【００６１】
ＩＭＳネットワークに組み込まれるＡＳの数とタイプは、時間の経過とともに変わってもよく、それによって同様にＩＦＣトリガも変わってもよいが、Ｓ−ＣＳＣＦに対して付加される余分のシグナリングは、この処理が提案されている代替手段に関しては、Ｓ−ＣＳＣＦに保持されたＡＳリストに組み込まれる新しいＡＳにつき１回の処理だけに限られるであろう。
【００６２】
本発明を具体化する解決手段は、以下の異なる手順を使用する。
・首尾よく登録された各ユーザに関してダウンロードされる各ＩＦＣに割り当てられている種々のＡＳを識別するためのＳ−ＣＳＣＦのメカニズム。
・Ｓ−ＣＳＣＦのＩＭＳドメインに構成されるＡＳのリストを、当該Ｓ−ＣＳＣＦが動的に作り上げる手順。
・Ｓ−ＣＳＣＦが前述のリストに組み入れられている各ＡＳからその能力を取得するプロトコル相互作用。
【００６３】
ＡＳとＳ−ＣＳＣＦとの間の課金能力情報の交換に使用される実際のメカニズムは確立していないので、例証として、以下に３つの異なる可能な代替手段を説明する。
【００６４】
各ＡＳの課金能力を取得しているので、ＡＳを呼び出すときＳ−ＣＳＣＦで課金を行うか否かについての決定は、当該ＡＳの実際の課金能力基づくことができる。
【００６５】
ここで例証として、能力情報交換の３つの代替手段を順に説明する。
【００６６】
代替手段１：登録フェーズ中の能力情報の交換
Ｓ−ＣＳＣＦは、登録時にダウンロードしたＩＦＣからＡＳを取り出すと、ＡＳリストを作り上げてもよい。リストに組み入れられた新しいＡＳのそれぞれに対して、Ｓ−ＣＳＣＦは、その能力情報を要求するために当該ＡＳとプロトコル相互作用を実行する。
【００６７】
利用可能なプロトコルのいくつかの選択肢があり、例としてライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）クエリまたはＡＳのＵＲＩへのハイパーテキスト転送プロトコル（ＨＴＴＰ）クエリがある。
【００６８】
ＳＩＰも使用されてもよく、これは実装面での利点を示す。ＳＩＰを使用する場合、２つの基本的な代替手段を提案する。
・Ｓ−ＣＳＣＦとあらゆる新しいＡＳとの間で交換されるＯＰＴＩＯＮＳメソッドに対する応答（２００ＯＫ）の中での拡張可能なマークアップ言語（ＸＭＬ）のボディの使用。
・サードパーティ登録が実施されるとき、交換されたＯＰＴＩＯＮＳメソッドかまたはＡＳが受信したＲＥＧＩＳＴＥＲメソッドに対する２００ＯＫ応答の中での、ＡＳ能力を含む新しいＳＩＰプライベートヘッダの使用。
【００６９】
サードパーティ登録メカニズム使用でありうる１つの欠点は、当該ＡＳがメカニズムにサブスクライブしなければならないことであり、これは常に当てはまるわけではないかもしれない。
【００７０】
ＯＰＴＩＯＮＳメソッドは、非特許文献１２に規定されているように、ＳＩＰ  ＵＡ能力を取得する多くのやり方の中で使用されてもよい。たぶん最も直接的なアプローチで、同時に将来も使い続けられるアプローチは、ＯＰＴＩＯＮＳ要求に対する２００ＯＫ応答の中でのメッセージボディの交換によるものであり、これでは、ＡＳの能力は例としてＸＭＬ文書で表現される。これには、Ｓ−ＣＳＣＦが送信するＯＰＴＩＯＮＳ要求の「Ａｃｃｅｐｔ」ヘッダの中への「アプリケーション／ＸＭＬ」の包含を含むであろう。
【００７１】
ＩＭＳ  ＸＭＬボディの使用は、非特許文献４で既に思い描かれており、そこでは種々の目的のために非常に基本的なデータスキームが標準化されているが、それらの目的のどれも本発明の範囲を取り扱っていない。それ故、課金能力のサポートを標準化する場合、このＩＭＳ  ＸＭＬボディのメカニズムの拡張が必要であろう。理想的には、例えば続くデータがＩＭＳ自体で標準化されているか、それともオペレータもしくは他のエンティティ（例えばＥＴＳＩ／ＴＩＳＰＡＮ）が定義した能力のセット等に属するかなどの、範囲およびデータスキームを規定する具体的な「名前空間」を指定することによって、含まれるデータスキームがボディ自体の中で適格とされ宣伝されるように、このＩＭＳ  ＸＭＬボディは拡張されるべきである。
【００７２】
この代替手段のイベントのフロー例が、図３に反映されている。図３のステップ１〜９は、従来のＳＩＰ登録手順のステップでもよく、これらのステップをここで説明する必要はない。これらのステップについてのさらなる情報は、文献の中に見つけることができる。しかし、本発明の一実施形態では、追加のステップＳ１〜Ｓ４が実行され、ステップＳ２は追加のステップ１０および１１を組み入れている。これらのうち、ステップＳ１〜Ｓ３は、登録手順の一部を形成すると見なされてもよいし、また登録手順とは別であるが少なくとも関係があると見なされてもよい。
【００７３】
ステップＳ１では、Ｓ−ＣＳＣＦが登録手順の一部としてユーザプロファイルの中のＩＦＣから各ＡＳのアイデンティフィケーションを取得する。この実施形態では、アイデンティフィケーションはそれぞれのＡＳと関係があるＵＲＩである。新しいＡＳのそれぞれに関して、ＡＳの課金能力は、ステップＳ２でＳ−ＣＳＣＦによって判定され、ＡＳとそれぞれの能力のリストは、ステップＳ３で維持更新される。この例では、課金能力は、ステップ２で、ＡＳにＳＩＰ  ＯＰＴＩＯＮＳメッセージを送信し（ステップ１０）、ＡＳから返信された２００ＯＫ応答を処理する（ステップ１１）ことによって判定される。その後Ｓ−ＣＳＣＦは、ＡＳが提供し、Ｓ−ＣＳＣＦがユーザへの提供を管理するサービスに係わる課金情報の生成でＡＳと連携するが、この連携はステップＳ４に表わされている。
【００７４】
代替手段２：トラヒック時における能力情報の交換
上記の手段に対する一代替手段は、第１の代替手段と同じまたは類似のやり方で登録時にＡＳのリストを作り上げるが、能力情報の実際の交換を新しいＡＳとの第１のトラヒックインターアクション（データ送受信）交流時に行う。
【００７５】
この場合能力情報の交換は、Ｓ−ＣＳＣＦおよび当該ＡＳがＳＩＰ  ＩＮＶＩＴＥメソッドを用いて最初に通信しているとき、行われるであろう。
【００７６】
この事例では、ＡＳは、Ｓ−ＣＳＣＦへの最初の２００ＯＫの中でその能力情報を戻すであろう。この２００ＯＫは、能力情報の容器として使用されている。この場合もやはり、ＡＳ能力を伝えるために、２つの基本的方法を提案する。
・ＡＳに送信されたＳＩＰメソッドに対する２００ＯＫの中でのＡＳ能力情報を含むＸＭＬボディの交換。
・２００ＯＫの中へのＳＩＰプライベートヘッダの包含。
【００７７】
しかし、ＳＩＰプライベートヘッダの使用は、ＩＥＴＦと３ＧＰＰとの間で相互に合意した情報ＲＦＣの中に文書化される必要があろう。
【００７８】
あるいは、ＡＳでのＩＮＶＩＴＥの受信および２００ＯＫでのその返答に関連して、ＬＤＡＰクエリまたはＨＴＴＰ  ＰＯＳＴクエリのような他のプロトコル代替手段も可能であろうが、これらは最適ではないと見られている。
【００７９】
この代替手段の一般的な欠点は、ＩＮＶＩＴＥが伝えられる前の、自装置がＣＴＦであるか否かをＳ−ＣＳＣＦがまだ知らないときに、最初のクレジット制御要求が送信されると、３ＧＰＰが規定した呼フローが述べていることである。これは、新しいＡＳへの最初の呼に関して、Ｓ−ＣＳＣＦから無用なクレジット制御セッションが開始されるかもしれないことを意味する。実際的な見地からは、能力情報はあるＡＳとの最初のコンタクトだけで交換され格納されるだろうから、これは比較的重要でない欠点である。
【００８０】
イベントの１つのありうるフローは、図４の説明に役立つメッセージ交換図に反映されている。図４のステップ１〜１７は、大体はＳＩＰ登録手順とそれに続くＳＩＰ招待手順の従来のステップであり、従来の手順から逸脱している部分を除いて、これらのステップをここで説明する必要はない。これらのステップについてのさらなる情報は、文献の中に見つけることができる。
【００８１】
本発明の実施形態では、追加のステップＰ１〜Ｐ３が実行される。これらの中のステップＰ１は、登録手順の一部を形成すると見なされてもよいし、また登録手順とは別であるが少なくとも関係があると見なされてもよい。ステップＰ２は、招待手順の一部を形成すると見なされてもよいし、また招待手順とは別であるが少なくとも関係があると見なされてもよい。
【００８２】
ステップＰ１では、Ｓ−ＣＳＣＦは、登録手順の一部として取得したユーザプロファイルの中のＩＦＣから、各ＡＳのアイデンティフィケーションを取得する。この実施形態では、アイデンティフィケーションはＡＳに関係があるそれぞれのＵＲＩである。ＡＳとそれぞれの能力情報のリストが維持されており、ステップＰ１でＳ−ＣＳＣＦは、このリストをＡＳ  ＵＲＩで更新する（それぞれの能力情報は後で更新されることになる）。
【００８３】
続いて招待手順の一部としてＳ−ＣＳＣＦがＡＳの１つから２００ＯＫメッセージを受信すると、ＡＳの課金能力は、ステップＰ２で２００ＯＫからＳ−ＣＳＣＦによって判定され、ＡＳとそれぞれの能力のリストがこの情報で更新される。これに関して、２００ＯＫメッセージは、例えば前に提案の方法の１つを用いて、課金能力情報を含む。
【００８４】
その後、Ｓ−ＣＳＣＦは、ＡＳが提供し、Ｓ−ＣＳＣＦがユーザへの提供を管理するサービスに係わる課金情報の生成でＡＳと連携するが、この連携はステップＰ３に表わされている。
【００８５】
代替手段３：ＩＦＣの中のダウンロードされる各ＡＳデータへのＡＳ能力の添付
もう１つの代替手段は、ＳＩＰ登録手順中にＨＳＳからＣｘ  Ｐｕｌｌ  ＲｅｓｐｏｎｓｅでダウンロードされるＡＳ名に、関連するＡＳ能力を反映する追加情報を付加することである。
【００８６】
要するに、含まれる情報は、例えばＸＭＬボディまたはＳＩＰプライベートヘッダに関して規定されたものと同じであろう。
【００８７】
この解決手段は、簡単に見えるが、ＩＦＣの現在の構造のデータモデルの変更を行うことが必要であり、非特許文献３および対応するプロビジョニングワーク(provisioning work)を参照されたい。
【００８８】
ＩＦＣのデータモデルのあらゆる拡張の陰に在る相対的な欠点とは別に、この代替手段の追加の問題は、任意のＡＳのソフトウェア能力のどんな更新も、ありとあらゆるユーザに対するＩＦＣの追加のプロビジョニングサイクルを意味するであろうことから生じることができよう。
【００８９】
この代替手段のイベントのフロー例は図５に反映されている。図３のステップ１〜９は、ステップ６でＳ−ＣＳＣＦがＨＳＳから受信したＣｘ  Ｐｕｌｌ  Ｒｅｓｐｏｎｓｅの中に能力情報が含まれることを別にすると、概ね従来の登録手順のステップである。これは、ステップＲ１でＳ−ＣＳＣＦが、ＡＳの課金能力を判定し、ＡＳとそれぞれの能力のリストを維持するように処理する。その後Ｓ−ＣＳＣＦは、ＡＳが提供し、Ｓ−ＣＳＣＦがユーザへの提供を管理するサービスに係わる課金情報の生成でＡＳと連携するが、この連携はステップＲ２に表わされている。
【００９０】
図６は、図３〜５のいずれかを参照して上記した本発明を具体化する方法の実行に関して、本発明を具体化するＳ−ＣＳＣＦ１０およびＡＳ２０の概念図である。Ｓ−ＣＳＣＦ１０は、ＡＳ２０の課金能力を判定する課金情報判定部１２を備えるのに対して、ＡＳ２０は、要求に応じてその課金能力情報をＳ−ＣＳＣＦ１０に提供する課金情報提供部２２を備える。課金能力情報に基づいてそのように判定されると、Ｓ−ＣＳＣＦ１０の課金情報生成部１６およびＡＳ２０の対応する課金情報生成部２６は、ＡＳ２０が提供するサービスに係わる課金情報の生成で連携する。これは、Ｓ−ＣＳＣＦ１０の課金情報制御部１４およびＡＳ２０の対応する課金情報制御部２４の制御のもとで行われる。サービスに係わる課金情報のすべてがＳ−ＣＳＣＦ１０で生成されてもよいし、また課金情報のすべてがＡＳ２０で生成されてもよいし、また課金情報の一部がＳ−ＣＳＣＦ１０で生成され、残りがＡＳ２０で生成されてもよい。
【００９１】
上記のコンポーネントの１つ以上の動作がデバイスまたは装置で動作するプログラムによって制御されてもよいと分かるであろう。そのような動作プログラムは、コンピュータで読み取り可能な記憶媒体に格納されてもよいし、また例えばインターネットウェブサイトから提供されるダウンロード可能なデータ信号などの信号の中に具体化できよう。添付の特許請求の範囲は、それ自体で、または運搬搬送媒体上の記録として、または信号として、または任意の他の形態で動作プログラムを包含すると解釈されるものである。
【００９２】
添付の特許請求の範囲によって規定される本発明の範囲から逸脱することなしに、種々の変更が上記の実施形態に行われうることも当業者は理解するであろう。ＩＰマルチメディアサブシステムを有するＵＭＴＳとの関連で述べているが、本発明は他のタイプのネットワークの対応する部分にも適用可能であることは、とりわけ理解されるであろう。
【図１】
2011505084.tif 000003
【図２】
2011505084.tif 000004
【図３】
2011505084.tif 000005
【図４】
2011505084.tif 000006
【図５】
2011505084.tif 000007
【図６】
2011505084.tif 000008
【国際調査報告】
2011505084.tif 000009
2011505084.tif 000010
2011505084.tif 000011