(57)【特許請求の範囲】
【請求項１】
ユーザ端末の通信セッションを制御するためにポリシー及び課金実行機能を動作させる方法であって、
第１の決定機能から、前記ユーザ端末のユーザインタフェースを前記第１の決定機能に関連するプライマリアドレスへリダイレクトすることを要求する最初の決定を受信するステップと、
第２の決定機能に対して前記最初の決定を通知するステップと、
前記第２の決定機能から、前記第１の決定機能が前記第２の決定機能に関連するセカンダリアドレスと通信することを要求する補足的決定を受信するステップと、
前記ユーザ端末へ、前記ユーザインタフェースを前記プライマリアドレスへリダイレクトするリダイレクト指示であって、前記セカンダリアドレスを含む前記リダイレクト指示を送信するステップと、
を備えることを特徴とする方法。
【請求項２】
前記最初の決定は、前記プライマリアドレスを含む
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記最初の決定は、前記最初の決定に関する１以上の理由を示し、
前記方法は、前記１以上の理由を用いて、前記リダイレクトが要求されていることを判断し、前記プライマリアドレスを選択するステップを更に備える
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記補足的決定は、前記セカンダリアドレスを含む
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記補足的決定は、前記補足的決定に関する１以上の理由を示し、
前記方法は、前記１以上の理由を用いて、前記第１の決定機能が前記セカンダリアドレスと通信しなければならないことを判断し、前記セカンダリアドレスを選択するステップを更に備える
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項６】
前記リダイレクト指示は、前記最初の決定及び前記補足的決定を識別するためのパラメータを含む
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記第１の決定機能は、ポリシー及び課金ルール機能、及びオンライン課金システムのうちの一方によって提供され、前記第２の決定機能は、ポリシー及び課金ルール機能、及びオンライン課金システムのうちのもう一方によって提供される
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
ユーザ端末の通信セッションを制御するために決定機能を動作させる方法であって、
１以上の事前定義されたルールを用いて、前記通信セッションの制御に関連する最初の決定であって、前記ユーザ端末のユーザインタフェースのリダイレクトを要求する前記最初の決定を行うステップと、
前記最初の決定をポリシー及び課金実行機能へ送信するステップと、
前記ユーザ端末の前記ユーザインタフェースから、他の決定機能に関連するアドレスを含むデータ要求を受信するステップと、
内部データを取得するステップと、
前記アドレスを用いることにより前記他の決定機能から補足的データを取得するステップと、
前記内部データ及び前記補足的データを組み合わせるステップと、
前記組み合わされたデータを前記ユーザ端末の前記ユーザインタフェースへ送信するステップと、
を備えることを特徴とする方法。
【請求項９】
前記最初の決定は、前記決定機能に関連するアドレスを含む
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記最初の決定は、前記最初の決定に関する１以上の理由を示す
ことを特徴とする請求項８に記載の方法。
【請求項１１】
前記データ要求は、前記内部データ及び前記補足的データを識別するためのパラメータも含む
ことを特徴とする請求項８乃至１０のいずれか１項に記載の方法。
【請求項１２】
ユーザ端末の通信セッションを制御するために決定機能を動作させる方法であって、
ポリシー及び課金実行機能から、他の決定機能によって行われた最初の決定であって、前記ユーザ端末のユーザインタフェースのリダイレクトを要求する前記最初の決定に関する通知を受信するステップと、
１以上の事前定義されたルールを用いて、前記通信セッションの制御に関連する補足的決定を行うステップと、
前記ポリシー及び課金実行機能へ、前記補足的決定を送信するステップと、
を備えることを特徴とする方法。
【請求項１３】
前記補足的決定は、前記決定機能に関連するアドレスを含む
ことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記補足的決定は、前記補足的決定に関する１以上の理由を示す
ことを特徴とする請求項１２に記載の方法。
【請求項１５】
ポリシー及び課金実行機能として動作するように構成された装置であって、
第１の決定機能から最初の決定を受信する受信機と、
前記最初の決定がユーザ端末のユーザインタフェースを前記第１の決定機能に関連するプライマリアドレスへリダイレクトすることを要求しているか否かを判定する処理ユニットと、
第２の決定機能に対して前記最初の決定を通知する送信機と、
前記第２の決定機能から補足的決定を受信する受信機と、
前記第１の決定機能が前記第２の決定機能に関連するセカンダリアドレスと通信することを前記補足的決定が要求しているか否かを判定し、前記ユーザインタフェースを前記プライマリアドレスへリダイレクトするリダイレクト指示を生成し、前記第１の決定機能が前記セカンダリアドレスと通信することを前記補足的決定が要求している場合、前記リダイレクト指示の中に前記セカンダリアドレスを含める処理ユニットと、
前記リダイレクト指示を前記ユーザ端末へ送信する送信機と、
を備えることを特徴とする装置。
【請求項１６】
前記処理ユニットは更に、前記最初の決定が前記プライマリアドレスを含むか否かを判定する
ことを特徴とする請求項１５に記載の装置。
【請求項１７】
前記処理ユニットは更に、前記最初の決定が前記最初の決定に関する１以上の理由を示すか否かを判定し、示す場合、前記１以上の理由を用いて、前記リダイレクトが要求されているか否かを判定し、前記プライマリアドレスを選択する
ことを特徴とする請求項１５に記載の装置。
【請求項１８】
前記処理ユニットは更に、前記補足的決定が前記セカンダリアドレスを含むか否かを判定する
ことを特徴とする請求項１５乃至１７のいずれか１項に記載の装置。
【請求項１９】
前記処理ユニットは更に、前記補足的決定が前記補足的決定に関する１以上の理由を示すか否かを判定し、示す場合、前記１以上の理由を用いて、前記第１の決定機能が前記セカンダリアドレスと通信しなければならないか否かを判定し、前記セカンダリアドレスを選択する
ことを特徴とする請求項１５乃至１７のいずれか１項に記載の装置。
【請求項２０】
前記処理ユニットは更に、前記最初の決定及び前記補足的決定を識別するためのパラメータを前記リダイレクト指示に含める
ことを特徴とする請求項１５乃至１９のいずれか１項に記載の装置。
【請求項２１】
ユーザ端末の通信セッションを制御するために決定機能として動作するように構成された装置であって、
１以上の事前定義されたルールを格納するメモリユニットと、
前記１以上の事前定義されたルールを用いて、前記通信セッションの制御に関連する最初の決定を行う処理ユニットと、
前記最初の決定に関連する内部データを格納するメモリユニットと、
前記最初の決定をポリシー及び課金実行機能へ送信する送信機と、
前記ユーザ端末のユーザインタフェースから、他の決定機能に関連するアドレスを含むデータ要求を受信する受信機と、
前記メモリユニットから前記内部データを取得する処理ユニットと、
前記アドレスを用いて前記他の決定機能から補足的データを取得する送受信機と、
前記内部データ及び前記補足的データを組み合わせる処理ユニットと、
前記組み合わされたデータを前記ユーザ端末の前記ユーザインタフェースへ送信する送信機と、
を備えることを特徴とする装置。
【請求項２２】
ユーザ端末の通信セッションを制御するために決定機能として動作するように構成された装置であって、
ポリシー及び課金実行機能から、他の決定機能によって行われた最初の決定であって、前記ユーザ端末のユーザインタフェースのリダイレクトを要求する前記最初の決定に関する通知を受信する受信機と、
１以上の事前定義されたルールを格納するメモリユニットと、
前記１以上の事前定義されたルールを用いて、前記通信セッションの制御に関連する補足的決定を行う処理ユニットと、
前記補足的決定を前記ポリシー及び課金実行機能へ送信する送信機と、
を備えることを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信セッションの制御に関する。より具体的には、本発明は、オンラインの課金及びポリシー決定(online charging and policy decisions)に応えて通信セッションをリダイレクトすることに関する。
【背景技術】
【０００２】
ＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）を介して提供される通信サービスは、オンラインの課金及び／又はポリシー制御のメカニズムに従属することができる。従って、通信システムの中には、この制御を提供するためにポリシー及び課金制御（ＰＣＣ）アーキテクチャを組み込んだものもある。3GPP TS 23.203 V7.9.0は、ユーザ端末によって３Ｇ通信システムを介して確立されたＩＰ−ＣＡＮセッションにおけるパケットフローに関して、そのようなＰＣＣアーキテクチャを記述している。3GPP TS 23.203に記述されるＰＣＣアーキテクチャは、ポリシー及び課金実行機能（ＰＣＥＦ）、ポリシー及び課金ルール機能（ＰＣＲＦ）、及びオンライン課金システム（ＯＣＳ）を含む。図１は、汎用パケット無線サービス（ＧＰＲＳ）ＩＰ−ＣＡＮにおいて採用されるＰＣＣアーキテクチャの例を概略的に示す。図１は、ＵＴＲＡＮ(UMTS Terrestrial Radio Access Network)の無線ネットワーク制御装置（ＲＮＣ）を描いている。しかしながら、これは他の何らかの無線アクセスネットワーク（例えば、ＧＥＲＡＮ(GSM EDGE Radio Access Network)）の基地局サブシステム（ＢＳＳ）であっても同様によい。
【０００３】
ＰＣＥＦは、ＰＣＲＦ及びＯＣＳによって指示された決定を実行に移すポリシー実行ポイント（ＰＥＦ）として振る舞う機能エンティティである。ＰＣＥＦは、あらゆるユーザトラヒック及びシグナリングトラヒックを捕捉し、ユーザを識別して使用されている（単数又は複数の）サービスの詳細を捕捉するためにこのトラヒックを分析する。次いでＰＣＥＦは、この情報を、Ｇｘインタフェースを介してＰＣＲＦに対して通信し、Ｇｙインタフェースを介してＯＣＳに対して通信することができる。ＰＣＥＦは、好ましくは、ＰＤＮに対するＩＰアクセスを実装するゲートウェイノードの中に一緒に配置される。そのようなものとして、ＧＰＲＳコアネットワークにおいては、ＰＣＥＦはＧＰＲＳゲートウェイサポートノード（ＧＧＳＮ）の中に配置され、他方、ＣＤＭＡ２０００ネットワークの場合、ＰＣＥＦはパケットデータサービングノード（ＰＤＳＮ）の中に配置され得る。
【０００４】
ＰＣＲＦは、スタンドアロンノードとして実装可能であり、ＱｏＳの実行に関するユーザデータやアクセス制御リストなどを格納するポリシー決定ポイント（ＰＤＰ）（或いは、ポリシーサーバ（ＰＳ））として振る舞う。ＰＣＲＦは、プロビジョニングされたデータ(provisioned data)、及びＰＣＥＦから受信したユーザ活動情報に基づき、決定を行う。ＰＣＲＦにおいてひとたび決定が行われると、この決定は、Ｇｘインタフェースを用いてＰＣＥＦに対して示される。
【０００５】
ＯＣＳは、プロビジョニングされたデータ(provisioned data)、及びＰＣＥＦから受信したユーザ活動情報に基づき、ネットワークリソースの使用に関する許可を提供する。この許可は、リソースの実際の使用に先立って、ＯＣＳによって認められなければならない。ネットワークリソース使用要求を受信すると、ネットワークは、関連性のある課金情報を収集し、ＯＣＳに対する課金イベントをリアルタイムに生成する。次いでＯＣＳは、Ｇｙインタフェースを介して、適当なリソース使用許可を返す。リソース使用許可はその範囲（例えば、データ容量又は継続期間）が限られていてもよく、それゆえ、ユーザのリソース使用が持続している限り、この許可が時々更新されなければならない場合もある。ＯＣＳは、時間ベース、容量ベース、及びイベントベースの課金をサポートすることができる。
【０００６】
ＰＣＲＦ及びＯＣＳから受信した決定を実行に移す際に、ＰＣＥＦは、ＩＰ−ＣＡＮセッションを終了又は修正する必要がある場合がある。セッションの終了又は修正の代わりとして、或いはこれに加えて、ＰＣＥＦは、アプリケーション固有のウェブポータルに対してユーザを向かわせる(direct)こともできる。これらのウェブポータルは、ユーザに対して追加的サービスを提供するために使用することもできるし、単に更なる情報を提供するために使用することもできる。例えば、そのようなウェブポータルは、ユーザに対してＱｏＳにおける課金を通知することもできるし、或いは、ユーザのクレジット(credit)が使い果たされた場合は、ウェブポータルは、ユーザが更なるクレジットを購入するためのメカニズムを提供することもできる。
【０００７】
図２は、ＯＣＳがユーザ端末をウェブポータルへ向かわせることに関するシグナリングフロー図の例である。この例において、何らかのネットワークリソースの使用中に、ＯＣＳは、ユーザのクレジットが使い果たされたと判断し、更なるクレジットを購入するオプションをユーザに提供するウェブポータルに対してユーザ端末を向かわせる。このステップは、以下のように実行される。
【０００８】
Ａ１．  ＰＣＥＦは、特定のサービスにアクセスしようとするユーザの最初の試みを検出する。例えば、ＰＣＥＦは、ユーザ端末からＨＴＴＰ  Ｇｅｔ要求を受信する。
【０００９】
Ａ２．  （IETF RFC 4006に規定されるような）Diameter Credit-Control Applicationに従い、ＰＣＥＦは、サービスのための最初のクレジット許可を要求するＣＣＲ(Credit-Control-Request)メッセージをＯＣＳに対して送信する。
【００１０】
Ａ３．  ユーザが十分なクレジットを持っている場合、ＯＣＳは、ユーザに対して認められたクオータ(quota)を示すＣＣＡ(Credit-Control-Answer)メッセージにより、ＣＣＲに対して応答する。このクオータは、サービス及びユーザの加入契約に応じて、任意の単位（例えば、時刻、データ、お金、など）で提供することができる。この最初のＣＣＡメッセージの中でＯＣＳによって返されるクオータは、通常、ユーザが現在利用可能な全量(total units)の一部（例えば、ユーザアカウント中のクレジットの一部）に等しいだけである。
【００１１】
Ａ４．  次いでＰＣＥＦは、認められたクオータが消費されるまでユーザがサービスにアクセスすることを許可する。このクオータが使用されると、ＰＣＥＦは別のＣＣＲをＯＣＳへ送信する。最初のＣＣＡメッセージの中でＯＣＳによって返されたクオータが利用可能量の一部だけであった場合は、ＯＣＳがＰＣＥＦから別のＣＣＲを受信すると、ＯＣＳは更なるクオータにより応答することにより、ユーザがサービスの使用を継続することを可能にする。ＣＣＲメッセージ及びＣＣＡメッセージに関するこれらの繰り返し(rounds)は、ＯＣＳがセッションを終了すると決定する（例えば、ユーザが利用可能な全量が使い果たされたり、ユーザの加入契約が満了したりした場合）まで、継続する。
【００１２】
Ａ５．  この時点で、ＰＣＥＦが別のクオータを要求すると、ＯＣＳは、ＰＣＥＦがユーザ端末をウェブポータルへリダイレクトするべきであることを示すＣＣＡメッセージをＰＣＥＦに対して送信することができ、このメッセージはウェブポータルのＵＲＬを含む。或いは、ＯＣＳは単に、セッションを終了するべきであるということ及びこの決定の理由を示すＣＣＡメッセージをＰＣＥＦに対して送信することもできる。
【００１３】
Ａ６．  ＯＣＳからのＣＣＡメッセージがウェブポータルのＵＲＬを含んでいた場合、その後ユーザ端末がサービスの使用を継続しようとする次の試みを実行すると、ＰＣＥＦは、ユーザ端末をウェブポータルのＵＲＬへリダイレクトするメッセージにより応答する。或いは、ＯＣＳから受信したＣＣＡメッセージがＵＲＬを含んでいないものの、セッションを終了するべきであるということ及びこの決定の理由をＣＣＡメッセージが示している場合は、ＰＣＥＦは、ＰＣＥＦにおいてローカルに設定されているＵＲＬへとユーザ端末をリダイレクトするメッセージにより、ユーザ端末に対して応答することができる。
【００１４】
Ａ７．  次いでユーザ端末は、ＰＣＥＦによって示されたＵＲＬに対してＨＴＴＰ  Ｇｅｔ要求を送信する。この例では、このＵＲＬは、別のアプリケーションサーバにおいてホストされている、ＯＣＳのウェブポータルへと、ユーザ端末をリダイレクトする。その後アプリケーションサーバは、ユーザが更なるクレジットを購入したり加入契約を更新したりすることを可能にするために、ＯＣＳ及びユーザ端末の双方と通信する。
【００１５】
Ａ８．  このプロセスが完了すると、ＯＣＳは、ＰＡＲ(Re-Auth-Request)メッセージをＰＣＥＦに対して送信することにより、セッションの再許可を開始することができる。ＰＣＥＦは、ＲＡＡ(Re-Auth-Answer)メッセージにより応答した後、新たなクオータを要求するＣＣＲメッセージをＯＣＳに対して送信する。その後ＯＣＳは、ユーザによって購入された追加のクレジットからのクオータを提供するＣＣＡメッセージにより応答する。或いは、図２に示すように、リダイレクトの前にステップ５においてＯＣＳから送信される最後のＣＣＡメッセージは、「有効期間(validity time)」を含むことができる。その後ＰＣＥＦはタイマーを走らせ、このタイマーは、「有効期間(validity time)」が満了すると、クレジット許可プロセスを再開するために、ＯＣＳに対するＣＣＲメッセージの送信をトリガーする。
【００１６】
上述のように、ＰＣＲＦも、サービスにアクセスしているユーザ端末がウェブポータルへとリダイレクトされることを必要とする場合がある。例えば、国によっては、法律上の理由により、ネットワークオペレータは、サービスの低下(degradation)の前にユーザに対して通知することを要求される。この通知は、Ｅメール又はＳＭＳをユーザへ送信することにより、達成可能である。しかしながら、ユーザに対して関連する情報を表示するウェブポータルへとユーザ端末が向けられることが好ましい場合もある。そのようなものとして、ネットワークオペレータがユーザに提供される帯域幅又はサービス品質（ＱｏＳ）を低下させようとした場合に、このことは、サービスの低下の前にユーザが通知を受けることを必要とし、この通知は、関連する情報を表示するウェブポータルへとユーザ端末を向けることによって達成可能である。
【発明の概要】
【００１７】
本発明の第１の態様によれば、ユーザ端末の通信セッションを制御するためにポリシー及び課金実行機能を動作させる方法が提供される。前記方法は、第１の決定機能から、前記ユーザ端末のユーザインタフェースを前記第１の決定機能に関連するプライマリアドレスへリダイレクトすることを要求する最初の決定を受信するステップと、第２の決定機能に対して前記最初の決定を通知するステップと、前記第２の決定機能から、前記第１の決定機能が前記第２の決定機能に関連するセカンダリアドレスと通信することを要求する補足的決定を受信するステップと、前記ユーザ端末へ、前記ユーザインタフェースを前記プライマリアドレスへリダイレクトするリダイレクト指示であって、前記セカンダリアドレスを含む前記リダイレクト指示を送信するステップと、を備える。
【００１８】
前記最初の決定は、前記プライマリアドレスを含んでもよい。或いは、前記最初の決定は、前記最初の決定に関する１以上の理由を示してもよく、前記方法は、前記１以上の理由を用いて、前記リダイレクトが要求されていることを判断し、前記プライマリアドレスを選択するステップを更に備えてもよい。前記プライマリアドレスは、前記ポリシー及び課金実行機能において事前定義されている１以上のアドレスのセットから選択可能である。
【００１９】
前記補足的決定は、前記セカンダリアドレスを含んでもよい。或いは、前記補足的決定は、前記補足的決定に関する１以上の理由を示してもよく、前記方法は、前記１以上の理由を用いて、前記第１の決定機能が前記セカンダリアドレスと通信しなければならないことを判断し、前記セカンダリアドレスを選択するステップを更に備えてもよい。前記セカンダリアドレスは、前記ポリシー及び課金実行機能において事前定義されている１以上のアドレスのセットから選択可能である。
【００２０】
前記リダイレクト指示は、前記最初の決定及び前記補足的決定を識別するためのパラメータを含んでもよい。前記プライマリアドレス及び前記セカンダリアドレスは、それぞれ、プライマリ・ユニフォーム・リソース・ロケータ、及びセカンダリ・ユニフォーム・リソース・ロケータであってもよい。前記通信セッションは、ウェブブラウジングセッションであってもよく、前記ユーザインタフェースは、ウェブブラウザであってもよい。
【００２１】
前記第１の決定機能は、ポリシー及び課金ルール機能、及びオンライン課金システムのうちの一方によって提供されてもよく、前記第２の決定機能は、ポリシー及び課金ルール機能、及びオンライン課金システムのうちのもう一方によって提供されてもよい。
【００２２】
本発明の第２の態様によれば、ユーザ端末の通信セッションを制御するために決定機能を動作させる方法が提供される。前記方法は、１以上の事前定義されたルールを用いて、前記通信セッションの制御に関連する最初の決定であって、前記ユーザ端末のユーザインタフェースのリダイレクトを要求する前記最初の決定を行うステップと、前記最初の決定をポリシー及び課金実行機能へ送信するステップと、前記ユーザ端末の前記ユーザインタフェースから、他の決定機能に関連するアドレスを含むデータ要求を受信するステップと、内部データを取得するステップと、前記アドレスを用いることにより前記他の決定機能から補足的データを取得するステップと、前記内部データ及び前記補足的データを組み合わせるステップと、前記組み合わされたデータを前記ユーザ端末の前記ユーザインタフェースへ送信するステップと、を備える。
【００２３】
前記最初の決定は、前記決定機能に関連するアドレスを含んでもよい。前記最初の決定は、前記最初の決定に関する１以上の理由を示してもよい。前記データ要求は、前記内部データ及び前記補足的データを識別するためのパラメータも含んでもよい。
【００２４】
本発明の第３の態様によれば、ユーザ端末の通信セッションを制御するために決定機能を動作させる方法が提供される。前記方法は、ポリシー及び課金実行機能から、他の決定機能によって行われた最初の決定であって、前記ユーザ端末のユーザインタフェースのリダイレクトを要求する前記最初の決定に関する通知を受信するステップと、１以上の事前定義されたルールを用いて、前記通信セッションの制御に関連する補足的決定を行うステップと、前記ポリシー及び課金実行機能へ、前記補足的決定を送信するステップと、を備える。
【００２５】
前記補足的決定は、前記決定機能に関連するアドレスを含んでもよい。前記補足的決定は、前記補足的決定に関する１以上の理由を示してもよい。
【００２６】
前記決定機能は、ポリシー及び課金ルール機能、及びオンライン課金システムのうちの一方によって提供されてもよく、前記他の決定機能は、ポリシー及び課金ルール機能、及びオンライン課金システムのうちのもう一方によって提供されてもよい。
【００２７】
本発明の第４の態様によれば、ポリシー及び課金実行機能として動作するように構成された装置が提供される。前記装置は、第１の決定機能から最初の決定を受信する受信機と、前記最初の決定がユーザ端末のユーザインタフェースを前記第１の決定機能に関連するプライマリアドレスへリダイレクトすることを要求しているか否かを判定する処理ユニットと、第２の決定機能に対して前記最初の決定を通知する送信機と、前記第２の決定機能から補足的決定を受信する受信機と、前記第１の決定機能が前記第２の決定機能に関連するセカンダリアドレスと通信することを前記補足的決定が要求しているか否かを判定し、前記ユーザインタフェースを前記プライマリアドレスへリダイレクトするリダイレクト指示を生成し、前記第１の決定機能が前記セカンダリアドレスと通信することを前記補足的決定が要求している場合、前記リダイレクト指示の中に前記セカンダリアドレスを含める処理ユニットと、前記リダイレクト指示を前記ユーザ端末へ送信する送信機と、を備える。前記ポリシー及び課金実行機能は、ゲートウェイＧＰＲＳサポートノードの中の機能エンティティであってもよい。
【００２８】
前記処理ユニットは、前記最初の決定が前記プライマリアドレスを含むか否かを判定するように構成されてもよい。前記処理ユニットは、前記最初の決定が前記最初の決定に関する１以上の理由を示すか否かを判定し、示す場合、前記１以上の理由を用いて、前記リダイレクトが要求されているか否かを判定し、前記プライマリアドレスを選択するように構成されてもよい。加えて、前記処理ユニットは、前記ポリシー及び課金実行機能のメモリの中に事前定義された１以上のアドレスのセットから前記プライマリアドレスを選択するように構成されてもよい。
【００２９】
前記処理ユニットは、前記補足的決定が前記セカンダリアドレスを含むか否かを判定するように構成されてもよい。前記処理ユニットは、前記補足的決定が前記補足的決定に関する１以上の理由を示すか否かを判定し、示す場合、前記１以上の理由を用いて、前記第１の決定機能が前記セカンダリアドレスと通信しなければならないか否かを判定し、前記セカンダリアドレスを選択するように構成されてもよい。加えて、前記処理ユニットは、前記ポリシー及び課金実行機能のメモリの中に事前定義された１以上のアドレスのセットから前記セカンダリアドレスを選択するように構成されてもよい。前記処理ユニットはまた、前記最初の決定及び前記補足的決定を識別するためのパラメータを前記リダイレクト指示に含めるように構成されてもよい。
【００３０】
本発明の第５の態様によれば、ユーザ端末の通信セッションを制御するために決定機能として動作するように構成された装置が提供される。前記装置は、１以上の事前定義されたルールを格納するメモリユニットと、前記１以上の事前定義されたルールを用いて、前記通信セッションの制御に関連する最初の決定を行う処理ユニットと、前記最初の決定に関連する内部データを格納するメモリユニットと、前記最初の決定をポリシー及び課金実行機能へ送信する送信機と、前記ユーザ端末のユーザインタフェースから、他の決定機能に関連するアドレスを含むデータ要求を受信する受信機と、前記メモリユニットから前記内部データを取得する処理ユニットと、前記アドレスを用いて前記他の決定機能から補足的データを取得する送受信機と、前記内部データ及び前記補足的データを組み合わせる処理ユニットと、前記組み合わされたデータを前記ユーザ端末の前記ユーザインタフェースへ送信する送信機と、を備える。前記決定機能は、ポリシー及び課金ルール機能、及びオンライン課金システムのうちの一方であってもよく、前記他の決定機能は、ポリシー及び課金ルール機能、及びオンライン課金システムのうちのもう一方であってもよい。
【００３１】
本発明の第６の態様によれば、ユーザ端末の通信セッションを制御するために決定機能として動作するように構成された装置が提供される。前記装置は、ポリシー及び課金実行機能から、他の決定機能によって行われた最初の決定であって、前記ユーザ端末のユーザインタフェースのリダイレクトを要求する前記最初の決定に関する通知を受信する受信機と、１以上の事前定義されたルールを格納するメモリユニットと、前記１以上の事前定義されたルールを用いて、前記通信セッションの制御に関連する補足的決定を行う処理ユニットと、前記補足的決定を前記ポリシー及び課金実行機能へ送信する送信機と、を備える。前記装置は、前記補足的決定に関連するデータを格納するメモリユニットを更に備えてもよい。前記決定機能は、ポリシー及び課金ルール機能、及びオンライン課金システムのうちの一方であってもよく、前記他の決定機能は、ポリシー及び課金ルール機能、及びオンライン課金システムのうちのもう一方であってもよい。
【図面の簡単な説明】
【００３２】
【図１】汎用パケット無線サービス（ＧＰＲＳ）ＩＰ−ＣＡＮにおいて採用されるＰＣＣアーキテクチャの例を概略的に示す。
【図２】ＯＣＳがユーザ端末をウェブポータルへ向かわせることに関するシグナリングフロー図の例である。
【図３】第１のリダイレクトを第２のリダイレクトと統合するプロセスの例を概略的に示す。
【図４】統合されたリダイレクトをサポートするＰＣＥＦによって実装されるプロセスの例を示す。
【図５】統合されたリダイレクトをサポートする第１の決定機能によって実装されるプロセスの例を示す。
【図６】統合されたリダイレクトをサポートする第２の決定機能によって実装されるプロセスの例を示す。
【図７】統合されたリダイレクトを実装するのに適したＰＣＥＦの例を概略的に示す。
【図８】統合されたリダイレクトを実装するのに適した第１の決定機能の例を概略的に示す。
【図９】統合されたリダイレクトを実装するのに適した第２の決定機能の例を概略的に示す。
【発明を実施するための形態】
【００３３】
ここで認識されることとして、ＰＣＲＦ及びＯＣＳによって指示された決定を実行に移す際に、単一のセッションの間にユーザ端末を何度もリダイレクトする必要がある場合がある。上述のように、ユーザのクレジットが使い果たされるとＯＣＳはユーザ端末をウェブポータルへリダイレクトすることができ、ＰＣＲＦは、ネットワークが提供しているＱｏＳの変更をユーザに通知するために、別のウェブポータルに対する別のリダイレクトを行うことができる。
【００３４】
これらの複数のリダイレクトには、多数の欠点がある。第１に、そのようなリダイレクトによって引き起こされる一定のサービス中断は、ユーザエクスペリエンスに対して否定的影響を与えがちである。第２に、様々なウェブポータル（即ち、ＯＣＳのために提供されるウェブポータル、及びＰＣＲＦのために提供されるウェブポータル）が、様々な部門によって、様々な目的(aims and objectives)を持って開発されてきたという傾向もある。そのようなものとして、これら様々なウェブポータルがそれぞれ異なるルック＆フィールを持つことがよくあり、ユーザに対して混乱を引き起こし、オペレータのブランドイメージに否定的影響を与える可能性がある。それゆえ、発生する個別のリダイレクトの数を最小限にしつつ、ユーザ端末をリダイレクトする際に供給される情報及びサービスを依然として提供することが望まれる。
【００３５】
ここで、ＯＣＳ及びＰＣＲＦによって別個に指示される別々のリダイレクトを統合可能であって、それによりセッション中に発生するリダイレクトの数を最小限にすると共に、これらのリダイレクトのための単一の組み合わされたウェブポータルをネットワークオペレータが使用することを確実にする方法について説明する。
【００３６】
この方法は、第１の決定機能（即ち、ＰＣＲＦ又はＯＣＳのいずれか）がユーザ端末のリダイレクトを必要とする最初の決定を行った際に、ＰＣＥＦがこの決定を第２の決定機能（即ち、ＰＣＲＦ又はＯＣＳのもう一方）に対して通知することを伴う。第２の決定機能が、ユーザ端末のリダイレクトをやはり必要とする補足的決定を行った場合、又は、そのような決定が差し迫っていると判断した場合、第２の決定機能はその旨をＰＣＥＦに対して報告する。次いでＰＣＥＦは、最初の決定によって必要とされる場所へとユーザ端末をリダイレクトすることを確実にするが、このリダイレクトは第２の決定機能の補足的決定によって必要とされる情報及び／又はサービスをも提供する。
【００３７】
図３は、ＯＣＳによって要求される第１のリダイレクトをＰＣＲＦによって要求される第２のリダイレクトと統合するプロセスの例を示す。この例では、簡略化のために、ＰＣＥＦ機能はパケットゲートウェイ（例えば、ＧＧＳＮ）の中に埋め込まれているものとする。実行されるステップは以下の通りである。
【００３８】
Ｂ１．  ユーザは、インターネットをブラウジングするなどのサービスにアクセスし、トラヒックはＰＣＥＦ経由でユーザ端末へと、そしてユーザ端末から、流れる。
【００３９】
Ｂ２．  ＰＣＥＦは、（クレジット制御に関しては）ＯＣＳ及び（ポリシー制御に関しては）ＰＣＲＦに対して、サービスの使用に関連する詳細を報告する。
【００４０】
Ｂ３．  次いでＯＣＳは、ユーザがクレジットを使い果たしたと判断し、ＰＣＥＦに対してユーザ端末をリダイレクトするように促す。
【００４１】
Ｂ４．  ＰＣＥＦは、ＰＣＲＦに対して、ＯＣＳによってトリガーされたリダイレクトを通知する。
【００４２】
Ｂ５．  ＰＣＲＦは、ユーザに対して通知を提供するためにユーザ端末をリダイレクトすることが間もなく必要になると判断し、ＰＣＥＦに通知する。
【００４３】
Ｂ６．  ＰＣＥＦは、ユーザ端末に対して、ウェブブラウザをＯＣＳのウェブポータルへリダイレクトする指示を送信する。この指示は、ウェブポータルのＵＲＬと、ＯＣＳに対してユーザ及びセッションを識別するためのパラメータセットとを含む。この指示は、ＰＣＲＦのＵＲＬとＰＣＲＦに対してユーザ及びセッションを識別するためのパラメータセットとを含む追加的情報のセットも提供する。
【００４４】
Ｂ７．  ユーザ端末は、ウェブポータルへとリダイレクトされる。ユーザ端末はまた、ＰＣＥＦから受信した指示に含まれる追加的情報と共に、ＯＣＳに対してユーザ及びセッションを識別するためのパラメータを、ＯＣＳのウェブポータルへと転送する。
【００４５】
Ｂ８．  ウェブポータルは、ユーザ及びユーザセッションに関する情報をＯＣＳから取得する。ウェブポータルはまた、追加的情報を使用してＰＣＲＦにコンタクトし、次いでＰＣＲＦは、ユーザに対して提供する必要のある通知に関するデータを供給する。次いでＯＣＳのウェブポータルは、ユーザが自分のアカウントのために更なるクレジットを購入することを可能にし、また、必要な通知も表示する。
【００４６】
この方法は、２以上のリダイレクトを１つに結合するメカニズムを提供する。ここで、リダイレクトを要求する第１の決定機能は、例えばＰＣＥＦから、他の決定機能にコンタクトするための情報を取得する。
【００４７】
ユーザ端末のリダイレクトは、２つの方法のうちの１つによってトリガー可能である。決定機能は、ＰＣＥＦに対する応答の中にウェブポータルのＵＲＬを含めることもできるし、ＰＣＥＦに対して単に決定を示すこともできる（後者の場合、次いでＰＣＥＦは、ＰＣＥＦにおいて設定されているＵＲＬへとユーザ端末をリダイレクトすることを開始することができる）。加えて、ＰＣＥＦは、統合されたリダイレクトが何らかの状況において要求されるか否かをチェックするだけのように構成されてもよい。例えば、ＰＣＥＦは、第１の決定機能によって或るＵＲＬが提供された際に第２の決定機能に対して通知を行うだけのように構成されてもよいし、或いは、或るサービスを使用している場合にだけ統合されたリダイレクトが要求されてもよい。加えて、オペレータの中には、ユーザがローミングしている場合にのみＱｏＳの低下を要求するものもある。そのようなものとして、ユーザがローミングしていない場合は統合されたリダイレクトを実行する必要がないかもしれない。というのも、ユーザに通知する必要のあるサービスの低下が発生しないからである。
【００４８】
ユーザ端末のリダイレクトは、ＰＣＥＦからユーザ端末へＨＴＴＰ  ３ｘｘ応答を送信することにより、達成可能である。例えば、この応答は下記のフォーマットを持つことができる。
HTTP/1.1 301 Moved Permanently
Location: http://www.operatorportal.com/refill.html
【００４９】
３０１ステータスコード及び場所フィールドはIETF RFC 2616に定義されている。しかしながら、ＰＣＥＦは、第１の決定機能が第２の決定機能にコンタクトすることを可能にするためにユーザ端末が第１の決定機能に対して提供する追加的情報も含めなければならない。ＰＣＥＦはまた、第１の決定機能及び第２の決定機能の両方がユーザ及びセッションを識別できるようにするパラメータも含める必要がある。例えば、ＨＴＴＰ応答は、以下の一部又は全部を含む必要があるかもしれない。
・ＯＣＳのウェブポータルに対するＵＲＬ
・ＯＣＳに対してユーザを識別するための、ＩＭＳＩ、ＭＳＩＳＤＮ、又は他のユーザ識別情報
・ＯＣＳに対してセッションを識別するための、Rating Group及びSession ID
・ＰＣＲＦのウェブポータルに対するＵＲＬ
・ＰＣＲＦに対してユーザを識別するための、ＩＭＳＩ、ＭＳＩＳＤＮ、又は他のユーザ識別情報
・ＰＣＲＦに対してセッションを識別するための、Reporting Group及びSession ID（注意すべきこととして、このReporting Group及びSession IDは、ＯＣＳのRating Group及びSession IDから独立している）
・受動的リダイレクト部(passive redirector)のＵＲＬ（この場合、ＰＣＲＦポータルのＵＲＬ）
【００５０】
この情報を含めることは、ＨＴＴＰ  ３ｘｘ応答の中で（RFC 2616において定義されているような）追加的な標準ヘッダを使用することにより、或いは、応答の中で非標準の又はプロプライエタリなヘッダを使用することにより（ユーザ端末及び第１及び第２の決定機能がこれらのヘッダを理解可能であるならば）、達成可能である。例えば、ＨＴＴＰ応答は、この情報を提供するために所謂「Ｘ−ヘッダ」を含めることで、ＰＣＥＦによってユーザ端末へと送信されるＨＴＴＰ応答が以下のフォーマットを持つようにすることができる。
HTTP/1.1 301 Moved Permanently
Location: http://www.prepaidportal.com/refill.html
X-activeredir-MSISDN: +34699738495
X-activeredir-RatingG: 5
X-activeredir-SessionlD: 5584
X-passiveredir-URL: http://www.qosportal.com/notif.html
X-passiveredir-MSISDN: +34699738495
X-passiveredir-ReportingG: 14
X-passiveredir-SessionlD: 778
【００５１】
"activedir"ヘッダは、能動的リダイレクト部(active redirector)としての第１の決定機能に関連するパラメータを提供し、他方、"passiveredir"ヘッダは、受動的リダイレクト部(passive redirector)としての第２の決定機能に関連するパラメータを提供する。ユーザ端末はまた、第１の決定機能のウェブポータルに対してリダイレクトされるＨＴＴＰ要求の中にこれらのヘッダを挿入することを確実にすることを要求される。
【００５２】
上述の方法は、統合されたリダイレクトが要求された際に、ＰＣＥＦがユーザ端末を第１の決定機能のウェブポータルへとリダイレクトすることを提供する。このリダイレクトはまた、この方法でなければ２つの別々のリダイレクトによって提供されていた情報及び／又はサービスを組み合わせるために、第１の決定機能が第２の決定機能にコンタクトすることを引き起こす。この機能を実行するために、既存のＯＣＳ及びＰＣＲＦは両方とも、協働して組み合わされたウェブポータルを提供することを可能にする「プラグイン」を必要とする。そうする際に、この統合されたリダイレクトは、セッションの間に発生するリダイレクトの数を最小限にし、別々の課金機能及びポリシー制御機能のためのウェブポータルが統合された態様で管理されることを確実にし、これにより、ユーザエクスペリエンス及びネットワークオペレータのブランドイメージを改善する。
【００５３】
図４は、統合されたリダイレクトをサポートするＰＣＥＦによって実装されるプロセスの例を示す。実行されるステップは以下の通りである。
【００５４】
Ｃ１．  ＰＣＥＦは、第１の決定機能（即ち、ＰＣＲＦ又はＯＣＳ）から、ユーザセッションに関連する最初の決定を受信する。
【００５５】
Ｃ２．  次いでＰＣＥＦは、この最初の決定が、ユーザのユーザ端末をプライマリアドレスへリダイレクトすることを要求するか否かを判定する。例えば、最初の決定はプライマリアドレスを含むことができ、これにより、ＰＣＥＦがユーザ端末をこのアドレスへとリダイレクトしなければならないということを示すことができる。或いは、ＰＣＥＦは、第１の決定機能から受信した決定及び／又は決定の理由に応じて、ユーザ端末をＰＣＥＦにおいて設定されているアドレスへとリダイレクトするように構成されてもよい。
【００５６】
Ｃ３．  最初の決定がユーザ端末のリダイレクトを要求しない場合、ＰＣＥＦはユーザ端末をリダイレクトせずに続行する。
【００５７】
Ｃ４．  最初の決定がユーザ端末のリダイレクトを要求する場合、ＰＣＥＦは、統合されたリダイレクトのためのチェックを行う必要があるか否かを判定する。前述のように、ネットワークオペレータは、何らかの状況（例えば、何らかのサービスを使用している時）においてのみ、ＰＣＥＦが統合されたリダイレクトのためのチェックを行うことを要求するかもしれない。
【００５８】
Ｃ５．  統合されたリダイレクトのためのチェックが必要とされない場合、ＰＣＥＦは、第２の決定機能にコンタクトすることなく、リダイレクト指示をユーザ端末へ送信することを続行する。
【００５９】
Ｃ６．  統合されたリダイレクトのためのチェックが必要とされる場合、ＰＣＥＦは、第２の決定機能に対してこの決定を通知する。
【００６０】
Ｃ７．  ＰＣＥＦは、第２の決定機能から補足的決定を受信する。
【００６１】
Ｃ８．  次いでＰＣＥＦは、補足的決定が統合されたリダイレクトを必要とするか否かを判定する。例えば、補足的決定は、第１の決定機能がユーザ端末によってコンタクトされた際に通信すべきセカンダリアドレスを含む場合がある。或いは、ＰＣＥＦは、第２の決定機能から受信した補足的決定及び／又は決定の理由に応じて、統合されたリダイレクトが要求されていること、及びその統合されたリダイレクトのためのセカンダリアドレスを判断するように構成されてもよい。
【００６２】
補足的決定が統合されたリダイレクトを要求しない場合、ＰＣＥＦは、ユーザ端末に対して、ユーザ端末をプライマリアドレスへリダイレクトするために必要な情報を含むリダイレクト指示を送信することを続行する。
【００６３】
Ｃ１０．  補足的決定が統合されたリダイレクトを要求する場合、ＰＣＥＦは、リダイレクト指示をユーザ端末へ送信する。しかしながら、この指示は、ユーザ端末をプライマリアドレスへリダイレクトするために必要な情報を含むが、第１の決定機能がユーザ端末によってコンタクトされた際に第１の決定機能をセカンダリアドレスへ向かわせるために、追加的情報も含む。
【００６４】
図５は、統合されたリダイレクトをサポートする第１の決定機能によって実装されるプロセスの例を示す。実行されるステップは以下の通りである。
【００６５】
Ｄ１．  第１の決定機能は、１以上の事前定義されたルールを用いて、ユーザのセッションに関連する最初の決定を行う。
【００６６】
Ｄ２．  第１の決定機能は、この最初の決定をＰＣＥＦへ送信する。最初の決定はまた、決定の理由も含むことができる。或いは、最初の決定は、プライマリアドレスを含むことにより、ＰＣＥＦがユーザ端末をこのアドレスへリダイレクトするべきであるということを示すことができる。
【００６７】
Ｄ３．  次いで第１の決定機能は、ユーザのユーザ端末から要求を受信する。例えば、この要求は、ＨＴＴＰ  Ｇｅｔ要求であってもよい。この要求はまた、第１の決定機能に対してユーザ及びセッションを識別するパラメータも含んでもよい。
【００６８】
Ｄ４．  次いで第１の決定機能は、要求が他の決定機能に関連するアドレスを含むか否かを判定する。
【００６９】
Ｄ５．  他の決定機能に関連するアドレスを要求が含んでいない場合、第１の決定機能は、最初の決定に関連する内部データを取得する。
【００７０】
Ｄ６．  次いで第１の決定機能は、この内部データをユーザ端末へ送信することにより、要求に対して応答する。例えば、この内部データは、ユーザ端末に対して、クレジット又はアカウント状態に関連する情報を提供し、更なるクレジットを購入する機会を提供したり、セッションの変化に関する情報を提供したりすることができる。
【００７１】
Ｄ７．  他の決定機能に関連するアドレスを要求が含んでいる場合、第１の決定機能は、最初の決定に関連する内部データを取得する。
【００７２】
Ｄ８．  次いで第１の決定機能は、他の決定機能のアドレスから補足的データを取得する。
【００７３】
Ｄ９．  次いで第１の決定機能は、内部データと補足的データとを組み合わせる。
【００７４】
Ｄ１０．  次いで第１の決定機能は、この組み合わされたデータをユーザ端末へ送信することにより、要求に対して応答する。
【００７５】
その後、最初の決定及び補足的決定の性質に応じて、また、ユーザが利用可能なオプションに応じて、ユーザ端末と第１の決定機能との間、及び第１の決定機能と第２の決定機能との間で、更なる通信が発生する場合もある。
【００７６】
図６は、統合されたリダイレクトをサポートする第２の決定機能によって実装されるプロセスの例を示す。実行されるステップは以下の通りである。
【００７７】
Ｅ１．  第２の決定機能は、ＰＣＥＦから、第１の決定機能によって行われた、ユーザのセッションに関連する最初の決定に関する通知を受信する。
【００７８】
Ｅ２．  次いで第２の決定機能は、１以上の事前定義されたルールを用いて、ユーザのセッションに関する補足的決定を行い、或いは、補足的決定が差し迫っていると判断する。
【００７９】
Ｅ３．  次いで第２の決定機能は、この補足的決定によりＰＣＥＦに対して応答する。補足的決定はまた、決定の理由も含んでもよい。或いは、補足的決定は、アドレスを含むことにより、第２の決定機能が統合されたリダイレクトを要求するということをＰＣＥＦに対して示してもよい。
【００８０】
図７は、上述の方法を実装するのに適したＰＣＥＦ１の例を概略的に示す。ＰＣＥＦ１は、コンピュータのハードウェア及びソフトウェアの組み合わせとして実装可能である。ＰＣＥＦ１は、受信機２、送信機３、及び処理ユニット４を備える。受信機２は、第１の決定機能から最初の決定を受信し、第２の決定機能から補足的決定を受信するのに適している。送信機３は、第２の決定機能に対して最初の決定を通知し、リダイレクト指示をユーザ端末へ送信するのに適している。処理ユニット４は、最初の決定がユーザ端末のユーザインタフェースをプライマリアドレスへリダイレクトすることを要求しているか否かを判定し、ユーザインタフェースをプライマリアドレスへリダイレクトするリダイレクト指示を生成し、第１の決定機能が第２の決定機能に関連するセカンダリアドレスと通信することを補足的決定が要求しているか否かを判定するのに適している。第１の決定機能がセカンダリアドレスと通信することを補足的決定が要求している場合、処理ユニット４はまた、ユーザ端末へ送信される指示の中にセカンダリアドレスも含める。
【００８１】
図８は、上述の方法を実装するのに適した第１の決定機能５の例を概略的に示す。第１の決定機能５は、コンピュータのハードウェア及びソフトウェアの組み合わせとして実装可能である。第１の決定機能５は、メモリユニット６、処理ユニット７、送信機８、及び受信機９を備える。メモリユニット６は、１以上の事前定義されたルールを格納し、最初の決定に関連する内部データを格納するのに適している。処理ユニット７は、１以上の事前定義されたルールを使用して最初の決定を行い、メモリユニットから内部データを取得し、内部データ及び補足的データを組み合わせるのに適している。送信機８は、最初の決定をＰＣＥＦへ送信し、組み合わされたデータをユーザ端末のユーザインタフェースへ送信するのに適している。受信機９は、ユーザ端末のユーザインタフェースからデータ要求を受信するのに適している。送信機８及び受信機９はまた、第２の決定機能から補足的データを取得するのにも適している。
【００８２】
図９は、上述の方法を実装するのに適した第２の決定機能１０の例を概略的に示す。第２の決定機能１０は、コンピュータのハードウェア及びソフトウェアの組み合わせとして実装可能である。第２の決定機能１０は、受信機１１、メモリユニット１２、処理ユニット１３、及び送信機１４を備える。受信機１１は、ＰＣＥＦから、第１の決定機能によって行われた最初の決定に関する通知を受信するのに適している。メモリユニット１２は、１以上の事前定義されたルールを格納するのに適している。処理ユニット１３は、１以上の事前定義されたルールを使用して通信セッションの制御に関連する補足的決定を行うのに適している。送信機１４は、補足的決定をＰＣＥＦへ送信するのに適している。
【００８３】
現在、通信システムにおけるノード及びサーバの多くは、コンピュータベースの装置によって実装されている。例として、前述した実行機能及び／又は決定機能（即ち、ＰＣＥＦ、ＰＣＲＦ、及びＯＣＳ）として動作するように構成可能なノード及び／又はサーバがある。従って、上述した実施形態は、コンピュータベースの装置において実行されるプロセス、及び、コンピュータベースの装置のためのプログラムを含み得る。プログラムは、プログラムを搬送可能な任意のキャリアに格納可能である。それゆえ、本発明の更なる実施形態は、プログラム可能なコンピュータに前述の任意の方法を実行させるためのコンピュータ解釈可能な命令を格納する、コンピュータプログラム製品又は記録媒体を含む。
【００８４】
当業者によって理解されるであろうこととして、本発明の範囲から逸脱することなく、上述の実施形態に対して多様な修正を行うことができる。
【要約】  本発明の第１の態様によれば、ユーザ端末の通信セッションを制御するためにポリシー及び課金実行機能を動作させる方法が提供される。前記方法は、第１の決定機能から、前記ユーザ端末のユーザインタフェースを前記第１の決定機能に関連するプライマリアドレスへリダイレクトすることを要求する最初の決定を受信するステップ（Ｃ１）と、第２の決定機能に対して前記最初の決定を通知するステップ（Ｃ６）と、前記第２の決定機能から、前記第１の決定機能が前記第２の決定機能に関連するセカンダリアドレスと通信することを要求する補足的決定を受信するステップ（Ｃ７）と、前記ユーザ端末へ、前記ユーザインタフェースを前記プライマリアドレスへリダイレクトするリダイレクト指示であって、前記セカンダリアドレスを含む前記リダイレクト指示を送信するステップ（Ｃ１０）と、を備える。【図１】
0004965752.tif 000002
【図２】
0004965752.tif 000003
【図３】
0004965752.tif 000004
【図４】
0004965752.tif 000005
【図５】
0004965752.tif 000006
【図６】
0004965752.tif 000007
【図７】
0004965752.tif 000008
【図８】
0004965752.tif 000009
【図９】
0004965752.tif 000010