JP2011517154A - Ｉｍｓネットワークにおける補助サービスのためのオンライン課金 - Google Patents

Abstract

セッションに対して補助サービス用のオンライン課金を可能にするＩＭＳネットワークおよび方法が開示されている。ＩＭＳネットワークは、セッション用に少なくとも１つの補助サービスを提供するように動作可能なアプリケーションサーバを備える。補助サービスが提供されることになった場合、セッションはアプリケーションサーバに経路指定される。アプリケーションサーバは、次に、補助サービスを提供し、さらにサービスに対する課金も提供する。課金を可能にするには、アプリケーションサーバは、補助サービス用に１つまたは複数の課金要求メッセージを生成し、補助サービス用の課金要求メッセージをＩＭＳネットワークのオンライン課金システム（ＯＣＳ）に送信する。ＯＣＳは、課金要求メッセージを処理し、それに応じて、セッションに加えて補助サービス用にも課金を可能にする。

Description

本発明は、ＩＭＳネットワークの分野、詳細には、ＩＭＳネットワーク内のセッション用に提供される補助サービスのオンライン課金の実行に関する。

ネットワーク事業者は、インターネットプロトコル（ＩＰ）ネットワークを介してＩＭＳ（ＩＰマルチメディアサブシステム）ユーザにマルチメディアサービスを提供するためにＩＭＳネットワークを共通のコアネットワークとして実装しつつある。ＩＭＳネットワークは、最初は３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）によって、後に３ＧＰＰ２によって設計された。適切に使用可能にされたＩＭＳデバイス（ＩＭＳユーザ機器（ＵＥ）とも呼ばれる）を使用して、ＩＭＳユーザは、ＩＭＳネットワークを介してセッションを確立することができる。セッションを確立するためには、一般的にはリアルタイムトランスポートプロトコル（ＲＴＰ：Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）であるベアラ接続をセットアップするためにシグナリングメッセージ（すなわち、ＳＩＰメッセージ）が交換される。その後、ベアラデータ（すなわち、音声会話）がセッションの通話者間で交換できるようになる。

セッションに加えて、ＩＭＳネットワークはセッション用の補助サービスを提供するようになされているが、これは、ＰＳＴＮのユーザが補助サービスを使用できるのと同様である。補助サービスは、テレフォニータイプの音声セッションまたはデータセッションを補完およびサポートする総合セットのサービスである。例えば、補助サービスには、発信者番号表示（ＯＩＰ：Ｏｒｉｇｉｎａｔｉｎｇ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｐｒｅｓｅｎｔａｔｉｏｎ）、発信者番号表示禁止（ＯＩＲ：Ｏｒｉｇｉｎａｔｉｎｇ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｒｅｓｔｒｉｃｔｉｏｎ）、接続先番号表示（ＴＩＰ：Ｔｅｒｍｉｎａｔｉｎｇ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｐｒｅｓｅｎｔａｔｉｏｎ）、接続先番号表示禁止（ＴＩＲ：Ｔｅｒｍｉｎａｔｉｎｇ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｒｅｓｔｒｉｃｔｉｏｎ）、呼の転送（ＣＤＩＶ：Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｄｉｖｅｒｓｉｏｎ）、呼保留（ＨＯＬＤ：Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｈｏｌｄ）、発着信の制限（ＣＢ：Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｂａｒｒｉｎｇ）、メッセージ受信インディケータ（ＭＷＩ：Ｍｅｓｓａｇｅ Ｗａｉｔｉｎｇ Ｉｎｄｉｃａｔｉｏｎ）、会議通話（ＣＯＮＦ：Ｃｏｎｆｅｒｅｎｃｅ）、特定呼転送（ＥＣＴ：Ｅｘｐｌｉｃｉｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｔｒａｎｓｆｅｒ）がある。

３ＧＰＰは、オフライン課金システムおよびオンライン課金システムを含む、ＩＭＳネットワーク用の課金アーキテクチャも定義している。オフライン課金システムは後払い課金を可能にする。つまり、最初にサービスが提供され、ＩＭＳユーザは後で請求される。オンライン課金システム（ＯＣＳ：Ｏｎｌｉｎｅ Ｃｈａｒｇｉｎｇ Ｓｙｓｔｅｍ）は前払い課金を可能にする。つまり、ＩＭＳユーザは、サービスが提供される前に口座残高を有している必要があり、口座残高は、サービスが提供される時にデビットされる。

ＯＣＳには、オンライン課金機能、口座残高管理機能（ＡＢＭＦ：Ａｃｃｏｕｎｔ Ｂａｌａｎｃｅ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）、レーティング機能（ＲＦ：ｒａｔｉｎｇ ｆｕｎｃｔｉｏｎ）がある。ＡＢＭＦは、ＩＭＳユーザの口座にサービスユニットの総量を維持する。レーティング機能は、ネットワーク事業者によって定義された課金率に従ってサービスの使用料金を決定する。オンライン課金機能は、オンライン課金を行うためにＡＢＭＦおよびレーティング機能を使用する。

ＩＭＳネットワーク内の、プロキシコールセッション制御機能（Ｐ−ＣＳＣＦ：Ｐｒｏｘｙ−Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）、セッションコールセッション制御機能（Ｓ−ＣＳＣＦ：Ｓｅｓｓｉｏｎ−Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）、アプリケーションサーバ（ＡＳ：Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）などのサービス要素は、課金トリガ機能（ＣＴＦ：Ｃｈａｒｇｉｎｇ Ｔｒｉｇｇｅｒ Ｆｕｎｃｔｉｏｎ）を含む。ＣＴＦは、サービスの使用を監視し、課金イベントに応答して課金メッセージを生成するようになされている。ＣＴＦは、次に、サービスの使用に対してオンライン課金を可能にするために課金メッセージをＯＣＳに送信する。

オンライン課金は、直接デビットまたはユニット予約として行うことができる。直接デビットの場合、オンライン課金機能は、個々のトランザクションに対してＩＭＳユーザの口座から直ちにユニットをデビットする。ユニット予約の場合、オンライン課金機能は、ＩＭＳユーザの口座のユニット割り当て量を許可し、そのユニット割り当て量を要求元サービス要素に提供する。要求元サービス要素は、次に、サービスの使用を監視し、割り当て量から適宜に差し引くことにより、予算管理を行う。ユニット割り当て量の期限が切れると、サービス要素は別のユニット割り当て量を要求し、プロセスは続行する。サービスが終了した後、ＩＭＳユーザの口座から差し引かれるユニットの合計総量が決済される。

以下に、ＩＭＳネットワーク内のセッションに対する課金の例を示す。ＩＭＳユーザは、セッションを開始するか、または適切なシグナリングメッセージ、例えば、ＳＩＰ ＩＮＶＩＴＥメッセージなどによってセッションを受信するようにインバイトされる。セッションを管理するためにＳ−ＣＳＣＦがＩＭＳユーザに割り当てられるので、シグナリングメッセージはＳ−ＣＳＣＦを介して送信される。ＩＭＳユーザ用のシグナリングメッセージを受信したことに応答して、Ｓ−ＣＳＣＦは、ホーム加入者サーバ（ＨＳＳ：Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）に、そのＩＭＳユーザの加入者プロファイルにアクセスするように連絡する。加入者プロファイルは、中でも、そのＩＭＳユーザが加入しているサービスのレベル、そのユーザが加入している任意の補助サービスなどを示す。加入者プロファイルは、ＩＭＳユーザが前払いユーザであることも示す。したがって、セッションの開始を検出したことに応答して、Ｓ−ＣＳＣＦ内（または３ＧＰＰ技術仕様の一部で提案されているＩＭＳゲートウェイ内）のＣＴＦがセッションのオンライン課金を開始する。オンライン課金を開始するには、ＣＴＦは、セッションの開始を示すＤｉａｍｅｔｅｒ Ｒｏクレジット制御要求（ＣＣＲ：Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ｒｅｑｕｅｓｔ）［ＩＮＩＴＩＡＬ］メッセージを生成し、そのＣＣＲ［ＩＮＩＴＩＡＬ］メッセージをＯＣＳに送信する。

ＯＣＳ内のオンライン課金機能は、次に、ＣＣＲ［ＩＮＩＴＩＡＬ］メッセージ内の情報を処理してＩＭＳユーザを識別する、セッションのメディアタイプを判定するなどし、この情報および他の情報を使用してレーティング機能にアクセスし、セッションのレーティングを決定する。オンライン課金機能はＡＢＭＦにもアクセスして、そのＩＭＳユーザがセッションを開始できるだけの十分な口座残高を有しているかを判定し、有している場合、セッションにいくつのサービスユニットを許可するかを決定する。オンライン課金機能は、次に、クレジット制御応答（ＣＣＡ：Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ａｎｓｗｅｒ）［ＩＮＩＴＩＡＬ］メッセージを生成し、ＣＣＡ［ＩＮＩＴＩＡＬ］メッセージをＳ−ＣＳＣＦに送信する。ＣＣＡ［ＩＮＩＴＩＡＬ］メッセージは、セッションが許可されたことを示し、またセッションに許可された割り当て数も示す。

Ｓ−ＣＳＣＦ（またはＩＭＳゲートウェイ）はＣＣＡ［ＩＮＩＴＩＡＬ］メッセージを受信し、予算管理を行う。予算管理の場合、Ｓ−ＣＳＣＦはサービスユニットの割り当て量を識別し、セッションが進むにつれて割り当て量を減少させる。Ｓ−ＣＳＣＦ内のＣＴＦが別の課金イベントを識別すると、Ｓ−ＣＳＣＦはＣＣＲ［ＵＰＤＡＴＥ］メッセージを生成する。例えば、課金イベントは、ＳＩＰ ＩＮＶＩＴＥ、ＲＥ−ＩＮＶＩＴＥまたはＵＰＤＡＴＥメッセージへの肯定応答であるＳＩＰ ２００ ＯＫメッセージの受信を含むこともあるし、サービスユニット割り当て量の期限切れを含むこともあるし、有効性タイマの期限切れを含むことなどもある。Ｓ−ＣＳＣＦはＣＣＲ［ＵＰＤＡＴＥ］メッセージをＯＣＳに送信する。オンライン課金機能は、セッションに別のサービスユニット割り当て量（使用可能な場合）を許可するために同様のプロセスを実行し、ＣＣＡ［ＵＰＤＡＴＥ］メッセージを生成し、ＣＣＡ［ＵＰＤＡＴＥ］メッセージをＳ−ＣＳＣＦに送信する。ＣＣＡ［ＵＰＤＡＴＥ］メッセージは、セッションの続行が許可されたことを示し、さらにセッションに許可された追加サービスユニット割り当て量も示す。

Ｓ−ＣＳＣＦ（またはＩＭＳゲートウェイ）はＣＣＡ［ＵＰＤＡＴＥ］メッセージを受信し、再び、新しく許可された割り当て量で予算管理を行う。その後のいずれかの時点でセッションが終了するものとする。セッションの終了を識別したことに応答して、Ｓ−ＣＳＣＦ内のＣＴＦはＣＣＲ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージを生成し、ＣＣＲ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージをＯＣＳに送信する。ＣＣＲ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージは、そのセッションに（セッションの継続時間に、またはオンライン課金機能によって許可された割り当て量の最新のスライスに）使用されたサービスユニットの数を示す。オンライン課金機能は、次に、ＡＢＭＦ内のＩＭＳユーザの口座からセッションの合計デビットを決済する。

ＩＭＳユーザのセッション中、１つまたは複数の補助サービスを呼び出すことができる。補助サービスを呼び出すには、Ｓ−ＣＳＣＦはセッションを、補助サービスを提供するようになされた、テレフォニーアプリケーションサーバ（ＴＡＳ：Ｔｅｌｅｐｈｏｎｙ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）などのアプリケーションサーバに経路指定する。例えば、Ｓ−ＣＳＣＦは、ＳＩＰ ＩＮＶＩＴＥメッセージをアプリケーションサーバに送信してセッションをアプリケーションサーバに経路指定することができる。アプリケーションサーバは、次に、そのセッション用の補助サービスを提供し、セッションをＳ−ＣＳＣＦに経路指定して戻す。

現在のＩＭＳオンライン課金に関する１つの問題は、補助サービスが個別に課金されないことである。ＩＭＳユーザが１つまたは複数の補助サービスを含む前払いプランに加入している場合、ネットワーク事業者によって定義される課金率は、ＩＭＳユーザによってどの補助サービスが選択されたかに基づいて異なる可能性がある。例えば、ＩＭＳユーザによって選択された補助サービスが多ければ多いほど、ネットワーク事業者によってそのＩＭＳユーザに対して定義される課金率は高くなる可能性がある。したがって、そのＩＭＳユーザがセッションに関わる場合、セッションは、選択された補助サービスに応じた、より高い課金率で課金されている。セッション中にアプリケーションサーバによって１つまたは複数の補助サービスが提供される場合、これらの補助サービスは個別に課金されるのではなく、そのセッションの課金全体の一部でしかない。ネットワーク事業者は、補助サービスに対して個別に課金しないことで、残念なことに相当な収入を失っている可能性がある。

本発明の実施形態は、ＩＭＳネットワーク内の補助サービスに対して課金する機能をセッションとは切り離して提供することにより、上述の問題または他の関連の問題を解決する。アプリケーションサーバがセッション用の補助サービスを提供する時、アプリケーションサーバは課金要求メッセージ、例えば、Ｄｉａｍｅｔｅｒクレジット制御要求（ＣＣＲ：Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ｒｅｑｕｅｓｔ）メッセージなどを生成し、その課金要求メッセージをＯＣＳに送信する。ＯＣＳは、次に、セッションに対して行われるのと同様に、補助サービス用のオンライン課金を可能にするが、ＯＣＳは、同じＩＭＳ課金識別子を使用して補助サービスをセッションに相関させる。アプリケーションサーバは、補助サービスを提供したことに応答して課金要求メッセージをＯＣＳに送信するので、ネットワーク事業者は効果的に補助サービスに対して個別に課金することができ、またセッションに対しても課金することができる。ネットワーク事業者は、このように、補助サービスを提供することから収入を得ることができる。

本発明の１つの実施形態は、セッションに対する補助サービス用のオンライン課金を可能にするようになされたＩＭＳネットワークを含む。ＩＭＳネットワークは、少なくとも１つの補助サービスを提供するように動作可能なアプリケーションサーバ、およびセッションを管理するように動作可能なセッション制御システムを備える。動作中の時、セッション制御システムは、セッション用の１つまたは複数のシグナリングメッセージを受信し、セッション用に提供する補助サービスのトリガを識別する。セッション制御システムは、次に、セッションをアプリケーションサーバに経路指定する。セッションがアプリケーションサーバに経路指定されると、アプリケーションサーバは補助サービスを提供する。アプリケーションサーバは、補助サービス用の１つまたは複数の課金要求メッセージも生成し、補助サービス用の課金要求メッセージをＩＭＳネットワークのオンライン課金システム（ＯＣＳ）に送信する。課金要求メッセージは、セッションベースの課金またはイベントベースの課金に対するものであってよい。ＯＣＳは課金要求メッセージを処理し、それに応じて、セッションに加えて補助サービス用にも課金を可能にする。

別の実施形態では、１つまたは複数のＡＶＰが、課金要求メッセージ用に定義される。この課金要求メッセージは、Ｄｉａｍｅｔｅｒ Ｒｏメッセージであってよい。アプリケーションサーバは、補助サービス用の課金情報を識別し、補助サービス用の課金情報を課金要求メッセージのＡＶＰ（複数可）に挿入する。

本発明は、以下で説明される他の例示の実施形態を含むことができる。

同じ参照番号は、全図面上で同じ要素または同じタイプの要素を表す。

本発明の例示の実施形態における、ＩＭＳネットワークを示した図である。 本発明の例示の実施形態におけるセッション用のオンライン課金を行う方法を示したフローチャートである。 本発明の例示の実施形態における、補助サービス用のオンライン課金を行う方法を示したフローチャートである。 本発明の例示の実施形態における、補助サービス用の即時イベントサービス課金（ＩＥＣ：Ｉｍｍｅｄｉａｔｅ Ｅｖｅｎｔ Ｓｅｒｖｉｃｅ Ｃｈａｒｇｉｎｇ）の例を示したメッセージ図である。 本発明の例示の実施形態における、補助サービス用の、ユニット予約によるイベントベースの課金（ＥＣＵＲ：Ｅｖｅｎｔ−ｂａｓｅｄ Ｃｈａｒｇｉｎｇ ｗｉｔｈ Ｕｎｉｔ Ｒｅｓｅｒｖａｔｉｏｎ）の例を示したメッセージ図である。

図１−５および以下の説明は、当業者に本発明の作成方法および使用方法を教示するために本発明の具体的な実施形態の例を解説したものである。本発明の原理を教示する目的で、本発明の一部の従来の態様は簡略化または省略されている。当業者は、本発明の範囲内に分類される、これら実施形態の変形が理解できよう。当業者は、以下で説明される特徴は様々な方法で結合できて、本発明の複数の変形を形成できることが理解できよう。その結果、本発明は、以下で説明される具体的な実施形態に限定されることはなく、特許請求の範囲に記載される請求項およびその均等物によってのみ限定される。

図１は、本発明の例示の実施形態におけるＩＭＳネットワーク１００を示している。ＩＭＳネットワーク１００は、セッション制御システム１０２、アプリケーションサーバ１０４、およびオンライン課金システム（ＯＣＳ）１２０を備えている。ＩＭＳネットワーク１００は、簡潔にするために図１に示されていない他のサービス要素、例えば、オフライン課金システム、ホーム加入者サーバ（ＨＳＳ）なども備えることができる。

セッション制御システム１０２は、ＩＭＳデバイス１１０および他のＩＭＳデバイス（図示せず）に関わる音声セッションおよび／またはデータセッション（すなわち、ＳＵＰセッション）をセットアップ、管理および／またはテアダウンするように動作可能な任意のシステム、サーバまたは機能を備える。セッション制御システム１０２の１つの例は、サービングコールセッション制御機能（Ｓ−ＣＳＣＦ：Ｓｅｒｖｉｎｇ−Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）である。３ＧＰＰ技術仕様に精通している人は、Ｓ−ＣＳＣＦは、現在、ＯＣＳ １２０へのＩＳＣインターフェースを有すると定義されていることが理解できよう。したがって、ＩＳＣメッセージをＯＣＳ １２０へのＤｉａｍｅｔｅｒ Ｒｏメッセージに変換するためにＳ−ＣＳＣＦとＯＣＳ １２０の間にＩＭＳゲートウェイが導入される。セッション制御システム１０２は、したがって、適切な課金トリガ機能（ＣＴＦ）および課金インターフェース（すなわち、Ｄｉａｍｅｔｅｒ Ｒｏ）を有するＳ−ＣＳＣＦを含んでもよいし、Ｓ−ＣＳＣＦを３ＧＰＰによって提案されているＩＭＳゲートウェイと共に含んでもよい。

アプリケーションサーバ１０４は、セッション用の補助サービスを提供するように動作可能な任意のシステム、サーバまたは機能を備える。補助サービスは、テレフォニータイプの音声セッションまたはデータセッションを補完およびサポートする任意のサービス・セットを備える。例えば、セッションをある１つの電話番号から別の電話番号に転送することは、セッション用の補助サービスであってよい。別の例では、３者またはｎ者会議は、セッションの補助サービスであってよい。当業者は、アプリケーションサーバ１０４が複数の補助サービスを提供することもできるし、または個別の補助サービスを提供する複数のアプリケーションサーバがあってもよいことが理解できよう。

ＯＣＳ １２０は、セッション用のオンライン課金を可能にするように動作可能な任意のシステム、サーバまたは機能を備える。本明細書で説明される実施形態によれば、ＯＣＳ １２０は、セッション用に提供される補助サービス用のオンライン課金を可能にするようにさらに動作可能である。この実施形態では、ＯＣＳ １２０は、オンライン課金機能（ＯＣＦ）１２２、口座残高管理機能（ＡＢＭＦ）１２４、およびレーティング機能（ＲＦ）１２６を備える。ＯＣＦ １２２は、ＡＢＭＦ １２４およびＲＦ １２６にアクセスし、課金メッセージをセッション制御システム１０２およびアプリケーションサーバ１０４などのサービス要素と交換し、他の機能を実行することによりＯＣＳ １２０内でオンライン課金を管理するように動作可能な任意のシステム、サーバまたは機能を備える。ＡＢＭＦ １２４は、ＩＭＳユーザの口座を維持するように、より詳細には、ＩＭＳユーザの口座内のサービスユニットの総量を維持するように動作可能な任意のシステム、サーバまたは機能を備える。ＲＦ １２６は、ネットワーク事業者によって定義された課金率に従ってサービスの使用料金を決定するように動作可能な任意のシステム、サーバまたは機能を備える。

セッション制御システム１０２はインターフェース１０７を介してＯＣＳ １２０に接続される。同様に、アプリケーションサーバ１０４はインターフェース１０８を介してＯＣＳ １２０に接続される。インターフェース１０７−１０８は、それぞれ、オンライン課金用にオンライン課金情報をＯＣＳ １２０に提供するために定義された課金インターフェースを備える。この実施形態では、インターフェース１０８（および、場合によってはインターフェース１０７）は、補助サービス用の新しい属性値ペア（ＡＶＰ：Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅ Ｐａｉｒ）で拡張されたＤｉａｍｅｔｅｒ Ｒｏインターフェースを備える。これについては、本明細書内で後述される。

ＩＭＳデバイス１１０は、ＩＭＳユーザ（図示せず）によって操作されている。そのＩＭＳユーザは、ＩＭＳネットワーク１００のネットワーク事業者によって提供される特定のサービスに加入している。サービス加入については、このＩＭＳユーザは、セッションに使用できる１つまたは複数の補助サービスを選択している。補助サービスは、ホーム加入者サーバ（ＨＳＳ）（図示せず）に保管されているＩＭＳユーザのサービスプロファイルに記録されている。

例えば、ＩＭＳユーザが、セッションを開始するか、または適切なシグナリングメッセージ、例えば、ＳＩＰ ＩＮＶＩＴＥメッセージなどによってＩＭＳネットワーク１００を介してセッションを受信するようにインバイトされたものとする。シグナリングメッセージは、セッション制御システム１０２がセッションを管理できるように、そのＩＭＳユーザに割り当てられたセッション制御システム１０２に経路指定される。ＩＭＳユーザ用のシグナリングメッセージを受信したことに応答して、セッション制御システム１０２は、ＨＳＳに、そのＩＭＳユーザのサービスプロファイルにアクセスするように連絡する。加入者プロファイルは、中でも、そのＩＭＳユーザが加入しているサービスのレベル、そのユーザが加入している任意の補助サービスなどを示す。加入者プロファイルは、ＩＭＳユーザが前払いユーザであることも示す。

セッション管理の一部として、セッション制御システム１０２は課金トリガ機能（ＣＴＦ）を実施してセッション用にオンライン課金を可能にする。図２は、本発明の例示の実施形態におけるセッション用のオンライン課金を行う方法２００を示したフローチャートである。方法２００は、セッション用のオンライン課金のいくつかの基本ステップを説明しているが、必要または所望に応じて他のステップも実行できる。

セッションが開始されると、ステップ２０２で、セッション制御システム１０２内のＣＴＦがセッション用の課金イベントを検出する。課金イベントは、この時点では、セッションの開始、例えば、ＳＩＰ ＩＮＶＩＴＥメッセージの受信を含む。ステップ２０４で、セッション制御システム１０２（またはセッション制御システム１０２内のＣＴＦ）はセッションに対する課金要求メッセージを生成する。セッションの開始時、課金要求メッセージは「初期」メッセージであり、セッションの開始を表す。初期課金要求メッセージの１つの例は、Ｄｉａｍｅｔｅｒ Ｒｏクレジット制御要求（ＣＣＲ）［ＩＮＩＴＩＡＬ］メッセージである。セッション制御システム１０２は、この課金要求メッセージをＯＣＳ １２０に送信する。

セッション用のオンライン課金は、イベントベースの課金と対立する（ユニット予約による）セッションベースの課金（ＳＢＣ：Ｓｅｓｓｉｏｎ−Ｂａｓｅｄ Ｃｈａｒｇｉｎｇ）を表す。セッションベースの課金では、初期課金要求メッセージは、セッションを接続する許可を要求し、また、予算管理が実行できるようにＯＣＳ １２０にサービスユニット割り当て量も要求する。

ＯＣＳ １２０内のＯＣＦ １２２が初期課金要求メッセージを処理して、ＩＭＳユーザの識別名、セッションのメディアタイプなど、セッションに関する情報を識別する。ステップ２０６で、ＯＣＦ １２２はそのセッション情報を使用してＲＦ １２６にアクセスし、そのセッション用のレーティングを決定する。ＯＣＦ １２２はＡＢＭＦ １２４にもアクセスして、そのＩＭＳユーザがセッションを開始できるだけの十分な口座残高を有しているかを判定し、有している場合、セッションにいくつのサービスユニットを許可するかを決定する。ステップ２０８で、ＯＣＦ １２６は次に、レーティング、口座残高などに基づいてＩＭＳユーザの口座のサービスユニット割り当て量を許可する。ＯＣＦ １２２は、次に、許可されたサービスユニット割り当て量を含む課金応答メッセージを生成する。課金応答メッセージは「初期」メッセージであり、セッションに許可された初期割り当て量を示す。初期課金応答メッセージの１つの例は、Ｄｉａｍｅｔｅｒ Ｒｏクレジット制御応答（ＣＣＡ）［ＩＮＩＴＩＡＬ］メッセージである。ＯＣＦ １２２は、次に、その課金応答メッセージをセッション制御システム１０２に送信する。

セッション制御システム１０２はＯＣＳ １２０から課金応答メッセージを受信し、その課金応答メッセージを処理して、許可された割り当て量およびいずれか他の関連情報を識別する。ステップ２１２で、セッション制御システム１０２は、許可されたユニット割り当て量に基づいてセッションの予算管理を行う。予算管理の場合、セッション制御システム１０２は、セッションが継続するにつれてサービスユニット割り当て量を減少させる。方法２００はそれでステップ２０２に戻る。

セッション制御システム１０２は、そのＣＴＦを介して、ステップ２０２でセッション中に別の課金イベントを検出する。課金イベントは、ＳＩＰ ＩＮＶＩＴＥ、ＲＥ−ＩＮＶＩＴＥまたはＵＰＤＡＴＥメッセージへの肯定応答であるＳＩＰ ２００ ＯＫメッセージの受信を含むこともあるし、許可されたサービスユニット割り当て量の期限切れを含むこともあるし、有効性タイマの期限切れを含むことなどもある。課金イベントを検出したことに応答して、セッション制御システム１０２は、ステップ２０４でセッションに対して別の課金要求メッセージを生成する。セッション中のこのポイントでは、課金要求メッセージは「更新」メッセージである。更新課金要求メッセージの１つの例は、ＣＣＲ［ＵＰＤＡＴＥ］メッセージである。セッション制御システム１０２はその課金要求メッセージをＯＣＳ １２０に送信する。

ＯＣＳ １２０内のＯＣＦ １２２が更新課金要求メッセージを処理して、セッションに関する情報を識別する。ステップ２０６で、ＯＣＦ １２２はそのセッション情報を使用してＲＦ １２６にアクセスし、そのセッション用のレーティングを決定する。このステップは更新メッセージには必要ないこともあるが、レーティングを変更する可能性のある、セッション用の１つまたは複数のセッション記述パラメータが変更されていることがある。ＯＣＦ １２２はＡＢＭＦ １２４にもアクセスして、そのＩＭＳユーザがセッションを続行できるだけの十分な口座残高を有しているかを判定し、有している場合、セッションにいくつのサービスユニットを許可するかを決定する。ステップ２０８で、ＯＣＦ １２６は、レーティング、口座残高などに基づいてＩＭＳユーザの口座のサービスユニット割り当て量を許可する。ＯＣＦ １２２は、次に、許可されたサービスユニット割り当て量を含み、セッションの続行が許可されたことを示す課金応答メッセージを生成する。この課金応答メッセージは「更新」メッセージであり、そのセッションに許可される次の割り当て量を示す。更新課金応答メッセージの１つの例は、ＣＣＡ［ＵＰＤＡＴＥ］メッセージである。ＯＣＦ １２２は、次に、その課金応答メッセージをセッション制御システム１０２に送信する。

セッション制御システム１０２は、ＯＣＳ １２０から課金応答メッセージを受信し、その課金応答メッセージを処理して、許可された割り当て量およびいずれか他の関連情報を識別する。ステップ２１２で、セッション制御システム１０２は、許可されたユニット割り当て量に基づいてセッションの予算管理を行う。方法２００はそれでステップ２０２に戻る。

セッション制御システム１０２は、セッション中に、更新課金要求メッセージをトリガする１つまたは複数の追加課金イベントを検出することがある。しかし、いずれかのポイントでセッションは終了する。ステップ２０２で、セッション制御システム１０２は、そのＣＴＦを介して、セッション中に別の課金イベントを検出する。課金イベントは、この時点では、セッションの終了、例えば、ＳＩＰ ＥＮＤメッセージの受信を含む。ステップ２０４で、セッション制御システム１０２はセッションに対する別の課金要求メッセージを生成する。セッション中のこのポイントでは、課金要求メッセージは「終了」メッセージである。終了課金要求メッセージの１つの例は、ＣＣＲ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージである。終了課金要求メッセージは、セッション中に消費されたサービスユニットの合計数の表示を含むか、最新の割り当て量からの残余サービスユニットの数の表示を含むことができる。セッション制御システム１０２は、この課金要求メッセージをＯＣＳ １２０に送信する。

ＯＣＦ １２２が、セッションが終了したことを判定するので、ＯＣＦ １２２が終了課金要求メッセージを処理して、そのセッションにいくつのサービスユニットが消費されたかを識別する。ステップ２１４で、ＯＣＦ １１２は、ＩＭＳユーザの口座でセッションの課金を決済する。口座から決済する際、セッションの期間に基づいて正しいユニット総量がＩＭＳユーザの口座から差し引かれる。方法２００はそれで終了する。

上述のＩＭＳユーザのセッション中、１つまたは複数の補助サービスを呼び出すことができる。補助サービスを呼び出すには、セッション制御システム１０２がセッションを、その補助サービスを提供するようになされたアプリケーションサーバ１０４に経路指定する。例えば、セッション制御システム１０２は、ＳＩＰ ＩＮＶＩＴＥメッセージをアプリケーションサーバ１０４に送信してセッションをアプリケーションサーバ１０４に経路指定することができる。アプリケーションサーバ１０４は次にそのセッション用に補助サービスを提供し、セッションをセッション制御システム１０２に経路指定し直す。

本明細書で説明される実施形態によれば、補助サービス（１つまたは複数）はセッションとは別個に課金される。図３は、本発明の例示の実施形態における、補助サービス用のオンライン課金を行う方法３００を示したフローチャートである。方法３００は、補助サービス用のオンライン課金のいくつかの基本ステップを説明しているが、必要または所望に応じて他のステップも実行できる。

セッションがアプリケーションサーバ１０４に経路指定されると、アプリケーションサーバ１０４はステップ３０２で補助サービスを提供する。アプリケーションサーバ１０４は、アプリケーションサーバ１０４が補助サービスを提供する時に課金イベントを検出するように動作可能な、補助サービス用のＣＴＦを含む。ステップ３０４で、アプリケーションサーバ１０４は補助サービス用の課金要求メッセージを生成する。補助サービス用のオンライン課金は、直接デビットとして行われる（例えば、即時イベントサービス課金（ＩＥＣ））またはユニット予約（例えば、セッションベースの課金（ＳＢＣ）、またはユニット予約によるイベントベースの課金（ＥＣＵＲ））。直接デビットの場合、課金要求メッセージは補助サービスの許可を要求し、その補助サービスが単一のトランザクションとして課金される。ユニット予約の場合、課金要求メッセージは補助サービスの許可を要求し、さらにそのサービス用のサービスユニット割り当て量を要求する。ステップ３０６で、アプリケーションサーバ１０４は補助サービスに対する課金要求メッセージをＯＣＳ １２０に送信する。

ＯＣＦ １２２が課金要求メッセージを受信し、その課金要求メッセージが直接デビット課金を求めるものか、ユニット予約課金を求めるものかを判定する。課金要求メッセージが直接デビット課金を求めるものの場合、ＯＣＦ １２２はＲＦ １２６にアクセスして、ステップ３０８で補助サービスのレーティングを決定する。ＯＣＦ １２２は、ステップ３１０で、その補助サービス用に決定されたレーティングに基づいてＩＭＳユーザの口座からデビットするためにＡＢＭＦ １２４にもアクセスする。ＯＣＦ １２２は、同じＩＭＳ課金識別子を使用して補助サービスをセッションに相関させる際にＲＦ １２６およびＡＢＭＦ １２４の両方を呼び出す。ＯＣＦ １２２は、補助サービスの提供が許可されたことを示す課金応答メッセージもアプリケーションサーバ１０４に送信する。

課金要求メッセージがユニット予約を求めるものの場合、ＯＣＦ １２２はＲＦ １２６にアクセスして、ステップ３１２で補助サービスのレーティングを決定する。レーティングは、補助サービスをセッションに相関させる場合、セッションにもよっても変わることがある。ステップ３１４で、ＯＣＦ １２２は、その補助サービス用のレーティングに基づいてサービスユニット割り当て量を許可するためにＡＢＭＦ １２４にアクセスする。ステップ３１６で、ＯＣＦ １２２は、補助サービス用の許可されたサービスユニット割り当て量を示し、補助サービスの提供が許可されたことも示す課金応答メッセージを生成する。課金応答メッセージは「初期」メッセージであり、補助サービス用に許可された初期割り当て量を示す。初期課金応答メッセージの１つの例は、Ｄｉａｍｅｔｅｒ ＣＣＡ［ＩＮＩＴＩＡＬ］メッセージである。ＯＣＦ １２２は、次に、課金応答メッセージをアプリケーションサーバ１０４に送信する。

アプリケーションサーバ１０４はＯＣＳ １２０から課金応答メッセージを受信し、その課金応答メッセージを処理して、許可された割り当て量およびいずれか他の関連情報を識別する。ステップ３１８で、アプリケーションサーバ１０４は、許可されたユニット割り当て量に基づいて補助サービスの予算管理を行う。予算管理の場合、アプリケーションサーバ１０４は、補助サービスが提供されるにつれてサービスユニット割り当て量を減少させる。方法３００はそれでステップ３０２に戻る。方法３００は、補助サービスが提供されている間、方法２００と同様に続行される。

アプリケーションサーバ１０４は、そのＣＴＦを介して、ステップ３０２で補助サービス中に別の課金イベントを検出する。課金イベントは、許可されたサービスユニット割り当て量の期限切れを含むこともあるし、有効性タイマの期限切れを含むことなどもある。課金イベントを検出したことに応答して、アプリケーションサーバ１０４は、ステップ３０４で補助サービスに対して別の課金要求メッセージを生成する。このポイントでは、課金要求メッセージは「更新」メッセージである。更新課金要求メッセージの１つの例は、ＣＣＲ［ＵＰＤＡＴＥ］メッセージである。アプリケーションサーバ１０４は、ステップ３０６で、その課金要求メッセージをＯＣＳ １２０に送信する。

ＯＣＳ １２０内のＯＣＦ １２２が更新課金要求メッセージを処理して、補助サービスに関する情報を識別する。ステップ３１２で、ＯＣＦ １２２はＲＦ １２６にアクセスし、その補助サービス用のレーティングを決定する。このステップは更新メッセージには必要ないこともあるが、レーティングを変更する可能性のある何かが変更されていることがある。ＯＣＦ １２２はＡＢＭＦ １２４にもアクセスして、そのＩＭＳユーザが補助サービスを続行できるだけの十分な口座残高を有しているかを判定し、有している場合、補助サービスにいくつのサービスユニットを許可するかを決定する。ステップ３１４で、ＯＣＦ １２６は、レーティング、口座残高などに基づいてＩＭＳユーザの口座のサービスユニット割り当て量を許可する。ＯＣＦ １２２は、次に、許可されたサービスユニット割り当て量を含み、補助サービスの続行が許可されたことを示す課金応答メッセージを生成する。この課金応答メッセージは「更新」メッセージであり、その補助サービスに許可される次の割り当て量を示す。更新課金応答メッセージの１つの例は、ＣＣＡ［ＵＰＤＡＴＥ］メッセージである。ＯＣＦ １２２は、次に、その課金応答メッセージをアプリケーションサーバ１０４に送信する。

アプリケーションサーバ１０４は、ＯＣＳ １２０から課金応答メッセージを受信し、その課金応答メッセージを処理して、許可された割り当て量およびいずれか他の関連情報を識別する。ステップ３１８で、アプリケーションサーバ１０４は、許可されたユニット割り当て量に基づいてセッションの予算管理を行う。方法３００はそれでステップ３０２に戻る。

アプリケーションサーバ１０４は、補助サービス中に、更新課金要求メッセージをトリガする１つまたは複数の追加課金イベントを検出することがある。しかし、いずれかのポイントで補助サービスは終了する。ステップ３０２で、アプリケーションサーバ１０４は、そのＣＴＦを介して、補助サービス中に別の課金イベントを検出する。課金イベントは、この時点では、補助サービスの終了を含む。ステップ３０４で、アプリケーションサーバ１０４は補助サービスに対する別の課金要求メッセージを生成する。補助サービス中のこのポイントでは、課金要求メッセージは「終了」メッセージである。終了課金要求メッセージの１つの例は、ＣＣＲ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージである。終了課金要求メッセージは、補助サービス中に消費されたサービスユニットの合計数の表示を含むか、最新の割り当て量からの残余サービスユニットの数の表示を含むことができる。アプリケーションサーバ１０４は、ステップ３０６で、この課金要求メッセージをＯＣＳ １２０に送信する。

ＯＣＦ １２２が、補助サービスが終了したことを判定するので、ＯＣＦ １２２が終了課金要求メッセージを処理して、その補助サービスにいくつのサービスユニットが消費されたかを識別する。図２のステップ２１４と同様に、ＯＣＦ １１２は、ＩＭＳユーザの口座で補助サービスの課金を決済する。口座から決済する際、補助サービスの期間に基づいて正しいユニット総量がＩＭＳユーザの口座から差し引かれる。

上述の実施形態では、アプリケーションサーバ１０４は、セッション制御システム１０２がセッション用の課金要求メッセージをＯＣＳ １２０に送信するのと同様に、補助サービスを提供するための課金要求メッセージをＯＣＳ １２０に送信する。その結果、補助サービスはセッションと切り離して課金することができる。ネットワーク事業者は、このように、補助サービスに対して個別に課金する柔軟性を有し、その結果、ネットワーク事業者の収入が増加する可能性がある。

図１において、インターフェース１０８は、補助サービス用の新しい属性値ペア（ＡＶＰ）で拡張されたＤｉａｍｅｔｅｒ Ｒｏインターフェースを含む。ＯＣＳ １２０が、アプリケーションサーバ１０４から、新しく導入された補助サービスＡＶＰを含む課金要求メッセージを受信すると、ＯＣＦ １２２が、どのような補助サービスが関わるかを理解し、補助サービス課金用に新しく導入された仕組みを使用することになる。Ｒｏインターフェースに補助サービスＡＶＰがない場合、ＯＣＦ １２２は、通常セッションとしてセッションに課金することになる。

導入されたＳｕｐｐｌｅｍｅｎｔａｌ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ により、ＯＣＦ １２２は、この実施形態では補助サービス用の以下の課金モードをサポートするように拡張される。１つの課金モードは、補助サービスを差異のあるレートで通常のセッションとして課金することである。別のモードは、異なる補助サービスを異なるレートで課金することである。例えば、着信転送課金レートは、コールスクリーニング課金レートとは異なる。別のモードは、補助サービスを通話時間、通信量、イベント数などに基づいて再発課金、非再発課金または従量課金として課金することである。別のモードは、補助サービスの追加通話者を異なるレートで課金することである。別のモードは、セッションに関わる異なる通話者用のクレジットスライスをセッション制御システム１０２およびアプリケーションサーバ１０４に割り振ることである。例えば、着信転送の呼び出し中、通話者Ａが呼を開始し、アプリケーションサーバ１０４が、通話者Ｂは呼を自分のリモートの携帯番号（通話者Ｃ）に転送することを希望していると判定したりする。ＯＣＳ １２０はアプリケーションサーバ１０４から補助サービスＡＶＰを受信し、通話者Ａは前払い加入者であって、レグＩ（ＡからＢへ）の課金を負担し、通話者Ｂは固定回線加入者であって、レグＩＩ（ＢからＣへ）の課金を負担し、通話者Ｃは前払い携帯電話であって、その無線通信時間の課金を負担すると判定する。ＯＣＳ １２０はＡＢＭＦ １２４から通話者Ａ、ＢおよびＣの口座情報を識別し、これら３人の通話者の呼のレートを算出するためにレーティングエンジン１２６に課金情報を送信する。次に、ＯＣＳ １２０は、課金率および残高に基づいて３人の通話者のクレジットをアプリケーションサーバ１０４に発行する。

拡張Ｒｏインターフェース１０８の場合、新しい補助サービスＡＶＰは「サービス情報」ＡＶＰの一部として定義される。この新しいＡＶＰは「Ｓｕｐｐｌｅｍｅｎｔａｌ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ」と呼ばれることがあるが、他の名前を使用してもよい。Ｓｕｐｐｌｅｍｅｎｔａｌ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰは、セッション用に提供される補助サービスに課金するための情報を含む。Ｓｕｐｐｌｅｍｅｎｔａｌ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰはタイプ「グループ型」であり、以下のＡＢＮＦ文法を有することができる：
Ｓｕｐｐｌｅｍｅｎｔａｒｙ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ：：＝
｛Ｓｅｒｖｉｃｅ−Ｔｙｐｅ｝
［Ｓｅｒｖｉｃｅ−Ａｃｔｉｏｎ]
［Ｓｅｒｖｉｃｅ−Ｍｏｄｅ]
［Ｓｅｒｖｉｃｅ−ＩＤ]
［Ａｓｓｏｃｉａｔｅｄ−Ｎｕｍｂｅｒ]
［ＳＳ−Ｓｔａｒｔ−Ｔｉｍｅ]
［ＳＳ−Ｓｔｏｐ−Ｔｉｍｅ]

Ｓｅｒｖｉｃｅ−Ｔｙｐｅ ＡＶＰはタイプ「列挙型」であり、補助サービスのタイプを示す。これは、Ｓｕｐｐｌｅｍｅｎｔａｌ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰの副ＡＶＰであり、例えば、以下の列挙型値を定義する：
− 自動コールバック（ＡＣＢ：Ａｕｔｏｍａｔｉｃ Ｃａｌｌ Ｂａｃｋ）
− 自動再呼び出し（ＡＲ：Ａｕｔｏｍａｔｉｃ Ｒｅｃａｌｌ）
− 選択呼受け付け（ＳＣＡ：Ｓｅｌｅｃｔ Ｃａｌｌ Ａｃｃｅｐｔａｎｃｅ）
− 呼転送（ＴＲＡＮＳ：Ｃａｌｌ Ｔｒａｎｓｆｅｒ）
− 同時呼び出し（ＳＩＭ：Ｓｉｍｕｌｔａｎｅｏｕｓ Ｒｉｎｇｉｎｇ）
− ｎ者通話（ｎ−ＷＡＹ：ｎ−Ｗａｙ Ｃａｌｌ）
− 通話終了時自動コールバック（ＲＢｗＦ：Ｒｉｎｇ Ｂａｃｋ ｗｈｅｎ Ｆｒｅｅ）
− 発信呼トレース（ＣＯＴ：Ｃｕｓｔｏｍｅｒ Ｏｒｉｇｉｎａｔｉｎｇ Ｃａｌｌ Ｔｒａｃｅ）
− コールパーク（ＰＡＲＫ：Ｃａｌｌ Ｐａｒｋ）
− コールピックアップ（ＰＩＣＫＵＰ：Ｃａｌｌ ＰｉｃｋＵｐ）
− 許可コード（ＡＵＴＨ：Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ）
− アカウントコード（ＡＣＣＴ：Ａｃｃｏｕｎｔ Ｃｏｄｅ）
− フレキシブルコールＩＤ（ＦＬＸＩＤ：Ｆｌｅｘｉｂｌｅ Ｃａｌｌ ＩＤ）
− 順次呼び出し（ＳＥＱ：Ｓｅｑｕｅｎｔｉａｌ Ｒｉｎｇｉｎｇ）
− キャリア事前選択（ＣＰＳ：Ｃａｒｒｉｅｒ Ｐｒｅ−Ｓｅｌｅｃｔｉｏｎ）
− ＭｉＲｉｎｇＢａｃｋ（ＭＲＢ）
− 保留音（ＭＯＨ：Ｍｕｓｉｃ Ｏｎ Ｈｏｌｄ）
− 自動再呼び出し（ＣＣＢＳ：Ｃａｌｌ Ｃｏｍｐｌｅｔｉｏｎ ｔｏ Ｂｕｓｙ Ｓｕｂｓｃｒｉｂｅｒ）
− マルチレベル優先および先取り（ＭＬＰＰ：Ｍｕｌｔｉ−Ｌｅｖｅｌ Ｐｒｅｃｅｄｅｎｃｅ ａｎｄ Ｐｒｅｅｍｐｔｉｏｎ）
− カスタマイズされた呼び出し音（ＣＲＢＴ：Ｃｕｓｔｏｍｉｚｅｄ Ｒｉｎｇ Ｂａｃｋ Ｔｏｎｅ）
− 短縮ダイヤル（Ａｂｂｒｅｖｉａｔｅ Ｄｉａｌｉｎｇ）

Ｓｅｒｖｉｃｅ−Ａｃｔｉｏｎ ＡＶＰはタイプ「列挙型」であり、Ｓｕｐｐｌｅｍｅｎｔａｌ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰの副ＡＶＰである。Ｓｅｒｖｉｃｅ−Ａｃｔｉｏｎ ＡＶＰは、例えば、以下の列挙型値を定義する：
− 活動化（Ａｃｔｉｖａｔｉｏｎ）
− 非活動化（Ｄｅａｃｔｉｖａｔｉｏｎ）
− 起動（Ｉｎｖｏｃａｔｉｏｎ）
− 取り消し（Ｃａｎｃｅｌｌａｔｉｏｎ）

Ｓｅｒｖｉｃｅ−Ｍｏｄｅ ＡＶＰはタイプ「列挙型」であり、補助サービスのモードを示す。これは、Ｓｕｐｐｌｅｍｅｎｔａｌ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰの副ＡＶＰであり、例えば、以下の列挙型値を定義する：
− 無条件着信転送（Ｃａｌｌ Ｆｏｒｗａｒｄｉｎｇ Ｕｎｃｏｎｄｉｔｉｏｎａｌ）
− 省略時着信転送（Ｃａｌｌ Ｆｏｒｗａｒｄｉｎｇ Ｄｅｆａｕｌｔ）
− 話中着信転送（Ｃａｌｌ Ｆｏｒｗａｒｄｉｎｇ Ｂｕｓｙ）
− 無応答時着信転送（Ｃａｌｌ Ｆｏｒｗａｒｄｉｎｇ Ｄｏｎ’ｔ Ａｎｓｗｅｒ）
− 無登録ユーザ着信転送（Ｃａｌｌ Ｆｏｒｗａｒｄｉｎｇ Ｕｎｒｅｇｉｓｔｅｒｅｄ Ｕｓｅｒ）
− 選択着信転送（Ｃａｌｌ Ｆｏｒｗａｒｄｉｎｇ Ｓｅｌｅｃｔｉｖｅ（ＳＣＡおよびＳＣＦの場合））
− 同時呼び出し着信転送（Ｃａｌｌ Ｆｏｒｗａｒｄｉｎｇ Ｓｉｍ Ｒｉｎｇ）
− ローカル着信転送（Ｃａｌｌ Ｆｏｒｗａｒｄｉｎｇ Ｌｏｃａｌ）（例えば、ＳｌＰ ３０２）
− ブラインド呼転送（Ｃａｌｌ Ｔｒａｎｓｆｅｒ Ｂｌｉｎｄ）
− 相談型呼転送（Ｃａｌｌ Ｔｒａｎｓｆｅｒ ｗｉｔｈ Ｃｏｎｓｕｌｔａｔｉｏｎ）
− Ｎ者からの呼転送（Ｃａｌｌ Ｔｒａｎｓｆｅｒ ｆｒｏｍ Ｎ−ｗａｙ）
− ローカル（例えば、ＳＩＰ参照）ユーザ呼転送（Ｃａｌｌ Ｔｒａｎｓｆｅｒ Ｌｏｃａｌ Ｕｓｅｒ）
− コールパーク −パーク（Ｃａｌｌ Ｐａｒｋ − Ｐａｒｋ）
− コールパーク − 取得（Ｃａｌｌ Ｐａｒｋ − Ｒｅｔｒｉｅｖｅ）
− コールパーク −保留（Ｃａｌｌ Ｐａｒｋ − Ｈｏｌｄ）
− コールパーク − ピックアップ（Ｃａｌｌ Ｐｉｃｋｕｐ − Ｐｉｃｋｕｐ）
− コールピックアップ − 指示されたピックアップ（Ｃａｌｌ Ｐｉｃｋｕｐ − Ｄｉｒｅｃｔｅｄ Ｐｉｃｋｕｐ）
− コールピックアップ − バージイン（Ｃａｌｌ Ｐｉｃｋｕｐ − Ｂａｒｇｅ−Ｉｎ）
− Ｎ者 − ３者通話（Ｎ−Ｗａｙ − ３ ｗａｙ ｃａｌｌ）
− Ｎ者 − ４者通話（Ｎ−Ｗａｙ − ４ ｗａｙ ｃａｌｌ）
− Ｎ者 − ５者通話（Ｎ−Ｗａｙ − ５ ｗａｙ ｃａｌｌ）
− Ｎ者 − ６者通話（Ｎ−Ｗａｙ − ６ ｗａｙ ｃａｌｌ）
− 順次呼び出し着信転送（Ｃａｌｌ Ｆｏｒｗａｒｄｉｎｇ Ｓｅｑｕｅｎｔｉａｌ Ｒｉｎｇｉｎｇ）

Ｓｅｒｖｉｃｅ−ＩＤ ＡＶＰはタイプ「ＵＴＦ８Ｓｔｒｉｎｇ」であり、補助サービスの一意の識別子である。Ａｓｓｏｃｉａｔｅｄ−Ｎｕｍｂｅｒ ＡＶＰはタイプ「ＵＴＦ８Ｓｔｒｉｎｇ」であり、補助サービスを呼び出すための番号を表す。ＳＳ−Ｓｔａｒｔ−Ｔｉｍｅ ＡＶＰはタイプ「時間」であり、補助サービスの開始時刻を表す。ＳＳ−Ｓｔｏｐ−Ｔｉｍｅ ＡＶＰはタイプ「時間」であり、補助サービスの停止時刻を表す。

Ｓｕｐｐｌｅｍｅｎｔａｌ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰは、補助サービスに対して柔軟な課金率を考慮している。一例では、補助サービスのタイプに基づいて異なる課金率が適用できる。例えば、着信転送（ｃａｌｌ ｆｏｒｗａｒｄｉｎｇ）の課金率は、呼転送（ｃａｌｌ ｔｒａｎｓｆｅｒ）の課金率と異なってよい。別の例では、異なるサービスモードに基づいて異なる課金率が適用できる。例えば、着信転送補助サービスの場合、無条件着信転送（ｃａｌｌ ｆｏｒｗａｒｄｉｎｇ ｕｎｃｏｎｄｉｔｉｏｎａｌ）の課金率は、話中着信転送（ｃａｌｌ ｆｏｒｗａｒｄｉｎｇ ｂｕｓｙ）の課金率と異なってよい。別の例では、異なるサービスアクションに基づいて異なる課金率が適用できる。例えば、通常の補助サービス使用量に加えて（例えば、着信転送されたセッションの場合、５セント／分）、補助サービスの活動化または非活動化に対して追加非再発課金（例えば、着信転送補助サービスを活動化または非活動化するには＄３）がかかる。別の例では、補助サービスの開始時刻と補助サービスの停止時刻に基づいて異なる課金率が適用できる。例えば、補助サービスの開始時刻から補助サービスの停止時刻まで、ＯＣＳ １２０は再発課金を適用することができる（例えば、発着信の制限（ｃａｌｌ ｂａｒｒｉｎｇ）補助サービスに対して１ヶ月ごとに＄２など）。

Ｓｕｐｐｌｅｍｅｎｔａｌ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰは、ネットワーク事業者が、ＡＶＰの組み合わせおよび他の課金データに基づいて課金率を定義して、より柔軟な補助サービス課金を実施できるようにしている。例えば、課金は、上述の任意のＡＶＰの組み合わせに基づかせてもよい。例えば、ネットワーク事業者Ａの場合、補助サービス１は、補助サービス使用量レート（２セント／分）および追加再発課金（＄２／月再発課金）で課金される。通信事業者Ｂの場合、補助サービスは再発課金のみ（＄５／月再発課金）課金されるが、毎日の活動における通常の補助サービスの使用は無料である。別の例では、課金は、ＡＶＰおよびアカウントプロファイル販売促進ポリシに基づかせてもよい。例えば、毎月１５回までの発着信の制限サービスは１０セント／１サービスで課金される。１６回目以降の発着信の制限サービスは、発着信の制限サービスごとに５セントが課金される。

Ｓｕｐｐｌｅｍｅｎｔａｌ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰは、ＯＣＳが一部の補助サービスに追加課金通話者を割り振ることも可能にしている。例えば、Ａｓｓｏｃｉａｔｅｄ−Ｎｕｍｂｅｒ ＡＶＰおよびサービスモードについては、ＯＣＳ １２０は、課金を負担する他の通話者を見つけて、その通話者の口座の有効性をチェックすることができる。ＯＣＳ １２０は、補助サービス内で、複数の通話者に対する課金率をチェックすることもできる。ＯＣＳ １２０は、アプリケーションサーバ１０４に対して、口座残高から複数の通話者への割り当て量も許可することができる。１人または複数の通話者が許可できない場合（例えば、口座が無効、または残高がしきい値未満）、ＯＣＳ １２０は、アプリケーションサーバ１０４にその補助サービスまたはセッションを拒否するように通知することができる。

図４および図５は、ＩＭＳネットワーク１００での補助サービスに対する課金の例を示している。図４は、本発明の例示の実施形態における、補助サービス用の即時イベントサービス課金（ＩＥＣ：Ｉｍｍｅｄｉａｔｅ Ｅｖｅｎｔ Ｓｅｒｖｉｃｅ Ｃｈａｒｇｉｎｇ）の例を示したメッセージ図である。図４では、ＩＭＳデバイス１１０のユーザは、アプリケーションサーバ１０４によって提供される短縮ダイヤル（ＡＢＤ）サービスに加入しているものとする。ＩＭＳデバイス１１０のユーザは、短縮ダイヤル番号を設定できるローカル番号を有するＴｅｌ ＵＲＩを作成する。ボイスセッションを開始するには、ＩＭＳデバイス１１０は、作成したＴｅｌ ＵＲＩに要求ＵＲＩを設定してＳＩＰ ＩＮＶＩＴＥメッセージを生成する。ＩＭＳデバイス１１０は、次に、そのＩＮＶＩＴＥメッセージをセッション制御システム１０２に送信する。ＩＮＶＩＴＥメッセージに応答して、セッション制御システム１０２内のＣＴＦは、ユーザの口座残高に基づいてサービスユニット割り当て量を予約するためにＤｉａｍｅｔｅｒ Ｒｏ ＣＣＲ［ＩＮＩＴＩＡＬ］メッセージをＯＣＳ １２０に送信する。ＯＣＳ １２０は、ＩＭＳデバイス１１０のユーザは口座にそのボイスセッション用に十分なサービスユニットを有しているかを判定する。ユーザの残高が十分な場合、ＯＣＳ １２０は、セッション制御システム１０２に、ＣＣＡ［ＩＮＩＴＩＡＬ］メッセージの許可された割り当て量で応答する。

ＩＭＳデバイス１１０のユーザに定義された初期フィルタ基準（ｉＦＣ）に基づいて、セッション制御システム１０２はＩＮＶＩＴＥメッセージをアプリケーションサーバ１０４に経路指定する。ローカル番号、およびホームネットワークドメイン名に等しい「電話コンテキスト」パラメータを有するＴｅｌ ＵＲＩを含むＩＮＶＩＴＥメッセージを受信すると、アプリケーションサーバ１０４は、そのボイスセッションは短縮番号宛てであると判定する。アプリケーションサーバ１０４が短縮番号を通常の電話番号に変換しようとする前に、アプリケーションサーバ１０４は、ＩＭＳデバイス１１０のユーザがＡＢＤサービスに対する追加課金用に十分なサービスユニットを口座に有しているかを判定するためにＣＣＲ［ＥＶＥＮＴ］メッセージをＯＣＳ １２０に送信する。ＯＣＳ １２０内のユーザの残高がＡＢＤ追加課金用に不足している場合、ＯＣＳ １２０は、失敗した旨の結果をＣＣＡ［ＥＶＥＮＴ］メッセージに入れてセッション制御システム１０２に送り返し、ボイスセッションは拒否されることになる。ＣＣＡ［ＥＶＥＮＴ］メッセージからの終了理由に基づいて、アプリケーションサーバ１０４は、対応するエラーコードと共にＳＩＰ ３ｘｘｌ４ｘｘ／５ｘｘをＩＭＳデバイス１１０に送信する。

ユーザの残高がＡＢＤ追加課金用に十分な場合、ＯＣＳ １２０は、ＡＢＭＦ １２４内で口座から追加課金を差し引くようにユーザの口座を更新する。ＯＣＳ １２０は、ＣＣＡ［ＥＶＥＮＴ］メッセージの成功した旨の結果をセッション制御システム１０２に送り返す。正常に戻った旨の結果を受信した後、アプリケーションサーバ１０４は、受信した要求ＵＲＩ内のローカル番号を、意図された宛先の一般ユーザ識別情報にマッピングすることにより、ＡＢＤサービスを提供する。アプリケーションサーバ１０４は、また、受信したＩＮＶＩＴＥ内の要求ＵＲＩをマッピング結果で置き換えることもする。アプリケーションサーバ１０４は、次に、ＩＮＶＩＴＥメッセージをセッション制御システム１０２に送信する。

ＩＮＶＩＴＥメッセージに応答して、セッション制御システム１０２は、着信側通話者番号が変更されている（すなわち、ＡＢＤ番号が通常の電話番号に変換されている）と判定する。セッション制御システム１０２は、また、ＩＭＳデバイス１１０に対して許可されたサービスユニットを再許可するためにＤｉａｍｅｔｅｒ Ｒｏ ＣＣＲ［ＵＰＤＡＴＥ］メッセージもＯＣＳ １２０に送信する。ＯＣＳ １２０は、受信したＣＣＲ［ＵＰＤＡＴＥ］メッセージに基づいてＩＭＳデバイス１１０に対してクレジット制御を再許可し、許可されたサービスユニットをＣＣＡ［ＵＰＤＡＴＥ］メッセージに入れてセッション制御システム１０２に送信する。

セッション制御システム１０２は、次に、ＵＥ−２として示される意図された宛先にＩＮＶＩＴＥメッセージを転送する。ＩＭＳデバイス１１０およびＵＥ−２は、通常のセッションセットアップメッセージングに従ってボイスセッションを確立する。ボイスセッションが確立されると、セッション制御システム１０２は、ボイスセッションに対して通常のオンライン課金機能も実行することになる。

ＩＭＳデバイス１１０がボイスセッションを終了すると、ＩＭＳデバイス１１０は、ＳＩＰ ＢＹＥメッセージをセッション制御システム１０２に送信してボイスセッションを解放する。ＢＹＥメッセージに応答して、セッション制御システム１０２は、Ｄｉａｍｅｔｅｒ Ｒｏ ＣＣＲ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージをＯＣＳ １２０に送信してボイスセッションに対する現在の課金を送信する。ＯＣＳ １２０はユーザの口座から課金を差し引いて、ＣＣＡ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージの許可されたサービスユニットをセッション制御システム１０２に返す。セッション制御システム１０２もＢＹＥメッセージをアプリケーションサーバ１０４およびＵＥ−２に送信する。

セッション制御システム１０２およびアプリケーションサーバ１０４の両方がＣＣＲメッセージをＯＣＳ １２０に送信するので、このボイスセッションに対して２つの課金がある。第１に、ＡＢＤサービスに対する課金がある（ＩＥＣ）。第２に、ボイスセッションに対する課金がある（ＳＢＣ）。このように、有利なことには、ＡＢＤサービスはボイスセッションから切り離されて課金される。

図５は、本発明の例示の実施形態における、補助サービス用の、ユニット予約によるイベントベースの課金（ＥＣＵＲ：Ｅｖｅｎｔ−ｂａｓｅｄ Ｃｈａｒｇｉｎｇ ｗｉｔｈ Ｕｎｉｔ Ｒｅｓｅｒｖａｔｉｏｎ）の例を示したメッセージ図である。発信側通話者（ＵＥ−２）がＩＭＳデバイス１１０とのボイスセッションを開始したがっているが、ＩＭＳデバイス１１０は別のセッションで話中であるとする。ボイスセッションを開始するには、ＵＥ−２はＳＩＰ ＩＮＶＩＴＥメッセージを生成し、ＩＮＶＩＴＥメッセージをセッション制御システム１０２に送信する。ＩＭＳデバイス１１０のユーザ用に定義された初期フィルタ基準（ｉＦＣ）に基づいて、セッション制御システム１０２はＩＮＶＩＴＥメッセージをアプリケーションサーバ１０４に経路指定する。セッション制御システム１０２内のＣＴＦは、ユーザの口座の残高に基づいてサービスユニット割り当て量を予約するために、Ｄｉａｍｅｔｅｒ Ｒｏ ＣＣＲ［ＩＮＩＴＩＡＬ］メッセージもＯＣＳ １２０に送信する。ＯＣＳ １２０は、ＩＭＳデバイス１１０のユーザがボイスセッション用に十分なサービスユニットを口座に有しているかを判定する。ユーザの残高が十分な場合、ＯＣＳ １２０は、許可された割り当て量をＣＣＡ［ＩＮＩＴＩＡＬ］メッセージに入れてセッション制御システム１０２に応答する。

セッション制御システム１０２は、次に、ボイスセッションを確立するためにＩＮＶＩＴＥメッセージをＩＭＳデバイス１１０に送信する。ＩＮＶＩＴＥメッセージに応答して、ＩＭＳデバイス１１０は、話中であることを示すＳＩＰ ４８６ Ｂｕｓｙ Ｈｅｒｅメッセージをセッション制御システム１０２に送信する。セッション制御システム１０２は、４８６ Ｂｕｓｙ Ｈｅｒｅメッセージをアプリケーションサーバ１０４に転送する。アプリケーションサーバ１０４は、次に、ＩＭＳデバイス１１０にＳＩＰ ＡＣＫメッセージで応答する。４８６ Ｂｕｓｙ Ｈｅｒｅメッセージに応答して、セッション制御システム１０２は、ユーザの口座で課金を決済するためにＣＣＲ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージをＯＣＳ １２０に送信する。ＯＣＳ １２０はＣＣＡ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージで応答する。

アプリケーションサーバ１０４は、ＩＭＳデバイス１１０のユーザがボイスメールデポジットサービスに加入していると判定する。アプリケーションサーバ１０４は、次に、ＣＣＲ［ＩＮＩＴＩＡＬ］メッセージをＯＣＳ １２０に送信し、Ｓｕｐｐｌｅｍｅｎｔａｌ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰをボイスメールデポジットとして設定する。ＯＣＳ １２０はボイスメールデポジットに対してＥＣＵＲを実行し、ユーザの口座にボイスメールデポジット追加料金を予約する。ＯＣＳ １２０は、次に、Ｄｉａｍｅｔｅｒ ＣＣＡ［ＩＮＩＴＩＡＬ］メッセージの成功した旨の結果をアプリケーションサーバ１０４に送り返す。

アプリケーションサーバ１０４は、オプションで、ＳＩＰ １８１ Ｃａｌｌ ｉｓ Ｂｅｉｎｇ Ｆｏｒｗａｒｄｅｄメッセージを送信して、ボイスセッションが転送中であることをＵＥ−２に通知する。アプリケーションサーバはＩＮＶＩＴＥメッセージもボイスメールアプリケーションサーバ（ＶＭＳ）に送信する。ＵＥ−２とＶＭＳはそれ以降のメッセージを交換して、ボイスメッセージをデポジットするための通話を確立する。ＵＥ−２のユーザは、次に、ＩＭＳデバイス１１０のボイスメールボックスにボイスメールメッセージを録音することができる。

ＵＥ−２がボイスメールメッセージの録音を終了すると、ＵＥ−２は、ＳＩＰ ＢＹＥメッセージをセッション制御システム１０２に送信してボイスセッションを解放する。セッション制御システム１０２はＢＹＥメッセージをアプリケーションサーバ１０４に転送する。ＢＹＥメッセージに応答して、アプリケーションサーバ１０４はＣＣＲ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージをＯＣＳ １２０に送信してＯＣＳ １２０にメールデポジットが終了したことを通知する。ＯＣＳ １２０は、予約されたＶＭデポジット追加料金をユーザの口座から差し引いて、Ｄｉａｍｅｔｅｒ ＣＣＡ［ＴＥＲＭＩＮＡＴＩＯＮ］をアプリケーションサーバ１０４に返す。アプリケーションサーバ１０４はＢＹＥメッセージをＶＭＳに転送し、ＶＭＳは、ＳＩＰ ２００ ＯＫメッセージで応答し、ＳＩＰ ２００ ＯＫメッセージが最終的にＵＥ−２に経路指定されて戻される。

セッション制御システム１０２およびアプリケーションサーバ１０４の両方がＣＣＲメッセージをＯＣＳ １２０に送信するので、このボイスセッションに対して２つの課金がある。第１に、ボイスメールデポジットサービスに対する課金がある。第２に、ボイスセッションに対する課金がある。このように、有利なことには、ボイスメールデポジットサービスはボイスセッションから切り離されて課金される。

本明細書では具体的な実施形態が説明されているが、本発明の範囲は、これらの具体的な実施形態に限定されることはない。本発明の範囲は、以下の特許請求の範囲およびその均等物によって定義されるものとする。

Claims (20)

1. セッションに対して補助サービス用のオンライン課金を可能にするようになされ、セッション用の少なくとも１つのシグナリングメッセージを受信するように、およびセッション用に提供する補助サービスのトリガを識別するように動作可能なセッション制御システムを備えたＩＭＳネットワークであって、
   セッション用に補助サービスを提供するように、補助サービス用に少なくとも１つの課金要求メッセージを生成するように、および補助サービス用の少なくとも１つの課金要求メッセージをＩＭＳネットワークのオンライン課金システム（ＯＣＳ）に送信するように動作可能なアプリケーションサーバ
   をさらに備える、ＩＭＳネットワーク。
2. オンライン課金機能と、
   セッションに関わるＩＭＳユーザの口座を維持するように動作可能な口座残高管理システムと、
   補助サービスの料金を決定するように動作可能なレーティング機能と
   を備えたＯＣＳを
   さらに備える、請求項１に記載のＩＭＳネットワーク。
3. アプリケーションサーバからＯＣＳへの少なくとも１つの課金要求メッセージがイベントベースの課金要求メッセージを含み、
   レーティング機能が同じＩＭＳ課金識別子を使用して補助サービスをセッションに相関させる時、レーティング機能が、セッションに対して提供される補助サービスのレーティングを決定するようにさらに動作可能であり、
   口座残高管理システムが、補助サービス用に決定されたレーティングに基づいてＩＭＳユーザの口座にデビットするようにさらに動作可能である、
   請求項２に記載のＩＭＳネットワーク。
4. 少なくとも１つの課金要求メッセージがセッションベースの課金要求メッセージを含み、
   レーティング機能が同じＩＭＳ課金識別子を使用して補助サービスをセッションに相関させる時、レーティング機能が、セッション用に提供される補助サービスのレーティングを決定するようにさらに動作可能であり、
   口座残高管理システムが、補助サービス用のレーティングに基づいてサービスユニット割り当て量を許可するようにさらに動作可能であり、
   オンライン課金機能が、補助サービス用の許可されたサービスユニット割り当て量を示す課金応答メッセージを生成するように、および課金応答メッセージをアプリケーションサーバに送信するように動作可能である、
   請求項２に記載のＩＭＳネットワーク。
5. アプリケーションサーバが、
   課金応答メッセージを受信し、
   補助サービスを提供する際に許可されたサービスユニット割り当て量の使用を監視し、および
   許可されたサービスユニット割り当て量が期限切れになった場合、別の課金要求メッセージをＯＣＳに送信するように
   さらに動作可能である、
   請求項４に記載のＩＭＳネットワーク。
6. 課金要求メッセージがＤｉａｍｅｔｅｒメッセージを含み、
   アプリケーションサーバが、
   補助サービス用の課金情報を識別し、および
   補助サービス用の課金情報をＤｉａｍｅｔｅｒメッセージの少なくとも１つの新しい属性値ペア（ＡＶＰ）に挿入するように
   さらに動作可能である、
   請求項１に記載のＩＭＳネットワーク。
7. Ｄｉａｍｅｔｅｒメッセージの少なくとも１つの新しいＡＶＰが、アプリケーションサーバによって提供される補助サービスのタイプを示す、請求項６に記載にＩＭＳネットワーク。
8. Ｄｉａｍｅｔｅｒメッセージの少なくとも１つの新しいＡＶＰが、アプリケーションサーバによって提供される補助サービス用のタイムスタンプを示す、請求項６に記載のＩＭＳネットワーク。
9. ＩＭＳネットワーク内でセッションに対して補助サービス用のオンライン課金を可能にする方法であって、
   ＩＭＳネットワークのアプリケーションサーバ内でセッション用に補助サービスを提供するステップと、
   アプリケーションサーバ内で補助サービス用に少なくとも１つの課金要求メッセージを生成するステップと、
   補助サービス用の少なくとも１つの課金要求メッセージをＩＭＳネットワークのアプリケーションサーバからオンライン課金システム（ＯＣＳ）に送信するステップと
   を含む、方法。
10. アプリケーションサーバからＯＣＳへの少なくとも１つの課金要求メッセージがイベントベースの課金要求メッセージを含み、さらに
    ＯＣＳ内でレーティング機能が同じＩＭＳ課金識別子を使用して補助サービスをセッションに相関させる時、セッションに対して提供される補助サービスのレーティングを決定するステップと、
    補助サービス用に決定されたレーティングに基づいてＩＭＳユーザの口座にデビットするステップと
    を含む、請求項９に記載の方法。
11. 少なくとも１つの課金要求メッセージがセッションベースの課金要求メッセージを含み、さらに
    レーティング機能が同じＩＭＳ課金識別子を使用して補助サービスをセッションに相関させる時、セッションに対して提供される補助サービスのレーティングを決定するステップと、
    補助サービス用のレーティングに基づいてサービスユニット割り当て量を許可するステップと、
    補助サービス用の許可されたサービスユニット割り当て量を示す課金応答メッセージを生成するステップと、
    課金応答メッセージをＯＣＳからアプリケーションサーバに送信するステップと
    を含む、請求項９に記載の方法。
12. アプリケーションサーバ内で課金応答メッセージを受信するステップと、
    補助サービスを提供する際に許可されたサービスユニット割り当て量の使用を監視するステップと、
    許可されたサービスユニット割り当て量が期限切れになった場合、別の課金要求メッセージをアプリケーションサーバからＯＣＳに送信するステップと
    をさらに含む、請求項１１に記載の方法。
13. 課金要求メッセージがＤｉａｍｅｔｅｒメッセージを含み、さらに
    補助サービス用の課金情報を識別するステップと、
    補助サービス用の課金情報をＤｉａｍｅｔｅｒメッセージの少なくとも１つの新しい属性値ペア（ＡＶＰ）に挿入するステップと
    を含む、請求項９に記載の方法。
14. Ｄｉａｍｅｔｅｒメッセージの少なくとも１つの新しいＡＶＰが、アプリケーションサーバによって提供される補助サービスのタイプを示す、請求項１３に記載の方法。
15. Ｄｉａｍｅｔｅｒメッセージの少なくとも１つの新しいＡＶＰが、アプリケーションサーバによって提供される補助サービス用のタイムスタンプを示す、請求項１３に記載の方法。
16. セッションに対して補助サービス用のオンライン課金を可能にするようになされたＩＭＳネットワークであって、
    セッションに対してオンライン課金およびセッションに対して少なくとも１つの補助サービスを提供するように動作可能なオンライン課金システム（ＯＣＳ）と、
    セッション用に補助サービスを提供するように、補助サービス用に少なくとも１つの課金要求メッセージを生成するように、および補助サービス用の少なくとも１つの課金要求メッセージをＯＣＳに送信するように動作可能なアプリケーションサーバと
    を備える、ＩＭＳネットワーク。
17. アプリケーションサーバからＯＣＳへの少なくとも１つの課金要求メッセージがイベントベースの課金要求メッセージを含み、
    ＯＣＳが、レーティング機能が同じＩＭＳ課金識別子を使用して補助サービスをセッションに相関させる時、セッションに対して提供される補助サービスのレーティングを決定するように、および補助サービス用に決定されたレーティングに基づいてＩＭＳユーザの口座からデビットするようにさらに動作可能である、
    請求項１６に記載のＩＭＳネットワーク。
18. 少なくとも１つの課金要求メッセージがセッションベースの課金要求メッセージを含み、
    ＯＣＳが、レーティング機能が同じＩＭＳ課金識別子を使用して補助サービスをセッションに相関させる時、セッション用に提供される補助サービスのレーティングを決定し、補助サービス用のレーティングに基づいてサービスユニット割り当て量を許可し、補助サービス用の許可されたサービスユニット割り当て量を示す課金応答メッセージを生成し、および課金応答メッセージをアプリケーションサーバに送信するようにさらに動作可能である、
    請求項１６に記載のＩＭＳネットワーク。
19. アプリケーションサーバが、
    課金応答メッセージを受信するように、
    補助サービスを提供する際に許可されたサービスユニット割り当て量の使用を監視するように、および
    許可されたサービスユニット割り当て量が期限切れになった場合、別の課金要求メッセージをＯＣＳに送信するように
    さらに動作可能である、
    請求項１８に記載のＩＭＳネットワーク。
20. 課金要求メッセージがＤｉａｍｅｔｅｒメッセージを含み、
    アプリケーションサーバが、
    補助サービス用の課金情報を識別し、および
    補助サービス用の課金情報をＤｉａｍｅｔｅｒメッセージの少なくとも１つの新しい属性値ペア（ＡＶＰ）に挿入するように
    さらに動作可能である、
    請求項１６に記載のＩＭＳネットワーク。

Images