(57)【特許請求の範囲】
【請求項１】
ユーザ端末にサービスを提供するための処理を行い、ネットワークを介して該ユーザ端末に提供するサービスに対して課金を行う課金システムにおいて、
料金と関連付けられたサービス情報を記述した1以上のサーバ課金プロファイルを保存するサーバ課金プロファイル登録部と、ユーザ課金プロファイルと前記各サーバ課金プロファイルを照合することによりユーザ端末に提供するサービスに対する課金条件を決定する課金条件生成部を備えたサービス提供サーバ、
ユーザ端末が収容されたルータ、
サービス種別およびユーザ端末単位のユーザ課金プロファイルを保持するユーザ課金プロファイル登録部を備え、ユーザ端末の位置登録時に該ルータより受信する認証要求メッセージに基づいて端末認証処理を実行すると共に、該認証要求メッセージにサービス要求情報が含まれていれば、当該ユーザ端末及びサービス種別に応じたユーザ課金プロファイルを取得して前記課金条件生成部に転送する認証サーバ、
前記生成された課金条件に基づいてユーザ端末毎に前記サービス提供サーバがユーザ端末に提供するサービスに対する課金処理を実行する課金部、
該課金部に前記生成された課金条件を設定する課金条件設定部、
を備え、前記ユーザ課金プロファイルにユーザの支払い許容条件を記述し、前記課金条件生成部は、ユーザ端末がサービス実行要求メッセージを送出した時点で前記ユーザ課金プロファイルと各サーバ課金プロファイルを照合することにより、提供するサービスに対する課金条件を決定する、
ことを特徴とする課金システム。
【請求項２】
前記課金条件生成部は、
ユーザ課金プロファイルにより規定される条件とサーバ課金プロファイルにより規定される条件の照合を行い、ユーザ課金プロファイルに含まれる各条件を満足するサーバ課金プロファイルを求め、該サーバ課金プロファイルに基づいて課金条件を生成する、
ことを特徴とする請求項１記載の課金システム。
【請求項３】
所定のサービス実行要求に対して予め生成された課金条件を前記認証サーバ内に保存しておき、認証サーバはユーザ端末よりサービス実行要求があったとき、該サービス実行要求に対応して保存している課金条件を前記課金条件生成部に転送する、
ことを特徴とする請求項２記載の課金システム。
【請求項４】
ユーザ端末は、サービス実行要求を含めて位置登録メッセージを送出し、前記位置登録手順と並行して、ユーザ端末毎に且つ要求されたサービス毎に、課金条件の生成処理、前記課金部の起動処理を行わせ、サービス実行前に課金条件の生成、該課金部の起動を完了させる手段、
を備えることを特徴とする請求項１記載の課金システム。
【請求項５】
前記課金部は、
前記課金条件設定部により課金条件が設定されると、ユーザ端末が要求するサービス内容に合致するパケットの到着を監視し、該パケットが到着すれば前記課金条件に従って課金を開始する手段、
前記課金条件設定部は課金条件設定後、一定時間経過しても前記パケットが観測されなければ課金条件の設定を解除する手段、
を有することを特徴とする請求項１記載の課金システム。
【請求項６】
ネットワークを介してユーザ端末に提供されるサービスに対して課金する課金システムにおいて、
ユーザ端末にサービスを提供するサービス提供ノード、
サービス提供ノードが許容するサービス提供条件を記録したサーバ課金プロファイルを登録するサーバ課金プロファイル登録部を備え、ユーザ端末が希望するサービス提供条件を記録したユーザ課金プロファイルと該サーバ課金プロファイルを比較してユーザに提供するサービスに関する課金条件を生成する課金制御ノード、
ユーザ端末の正当性の認証を行なうと共に、該ユーザ端末のユーザ課金プロファイルを管理する認証ノード、
ユーザ端末からのアドレス割当要求により該ユーザ端末にアドレスを割り当てると共にユーザ端末の正当性の認証を認証ノードに要求し、認証応答時に、該認証ノードより受信する前記ユーザ端末のユーザ課金プロファイルを保持し、ユーザ端末からのサービス提供要求に基いて通過するメッセージを検出し、該メッセージに前記ユーザ端末のユーザ課金プロファイルを付加し、該メッセージを前記課金制御ノードに直接あるいはサービス提供ノードを介して送達するエッジノード、
サービス提供ノードに代わって該サービス提供ノードがユーザ端末に提供するサービスに関して前記課金条件に従って課金する代行課金部、
を備えたことを特徴とする課金システム。
【請求項７】
前記課金制御ノードは、
サービス提供ノードからの課金条件生成要求に基づいて、前記ユーザ課金プロファイルと前記サーバ課金プロファイルを比較してユーザに提供するサービスに関する課金条件を生成する課金条件生成部、
該生成した課金条件に課金条件識別子を付加してサービス提供ノードに返信する手段、
ユーザ端末とサービス提供ノードとの交渉により決定された課金条件にサービス提供ノードの識別子情報、ユーザ端末の識別子情報を付加して登録する手段、
を備えたことを特徴とする請求項６記載の課金システム。
【請求項８】
前記サービス提供ノードは、
ユーザ端末からサービス提供要求があったとき、前記課金制御ノードに課金条件の生成を要求する手段、
課金制御ノードにより生成された1以上の課金条件を受信したとき、ユーザ端末と交渉して課金条件を決定する課金条件決定部、
該決定した課金条件を代行課金部に通知すると共に、該課金条件に従ってサービスを提供する手段、
を備えたことを特徴とする請求項６記載の課金システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は課金システムに係わり、特にユーザ端末にサービスを提供するための処理を行い、ネットワークを介して該ユーザ端末に提供するサービスに対して課金を行う課金システムに関する。
インターネットの急速な発展によりIPパケットトラヒックが急増している。さらに、携帯電話の普及に伴い、International Mobile Telecommunications 2000(IMT-2000)での標準化もあり、モバイル環境での高速IP通信が普及すると考えられる。このような急速な技術革新にも関わらず、IP通信の高度化、即ち、端末毎のQoS、WWWサーバのネットワークワイドな負荷分散といったサービスを実現する技術は、需要が見込まれる中で十分に成熟しているとは言えない。
本発明は、端末（加入者）単位でのサービスの管理、実行を可能とするモバイル環境を含むIPネットワークにおけるIPサービス制御機構において、サービスの内容に沿った課金を行うために必要となる課金技術を提供する。すなわち、本発明は、インターネットに接続する端末毎に、また、該端末に提供されるサービス単位で課金する課金技術を提供する。
また、本発明は、複数サーバより情報を連続して提供するサービスに課金する課金技術を提供する。ネットワークを利用した新たな情報配信サービスの一形態として、地理的に分散されたサーバ群を利用して統一されたサービスを提供するビジネスが立ち上がりつつある。具体的には、地図情報を車載装置内の記憶装置に保存する既存のカーナビゲーションシステムと異なり、現在地周辺等必要地域の地図情報の供給をネットワーク経由で配信するサービスである。この種のサービスは、地図情報提供業者としては１つでありながら、サービスを提供するサーバ装置等の配置を地理的に分散し、各サーバに配信すべき地図情報を分割して保持させることにより行われる。言い換えれば、各地域に関連した情報配信を担当するサーバが存在するものである。この構成は、データサイズの拡大が予測される地図等の情報配信に対して、ユーザに対する応答時間と、ネットワークトラヒックの緩和、地図サーバ負荷の分散を狙ったものである。かかる複数サーバより情報を連続して提供するサービスに課金する課金技術を確立する必要があり、本発明はかかる課金技術を対象とする。
【０００２】
【従来の技術】
・PBN (Policy-Based Networking)
Cisco、3com等の米ベンダが中心にPBN (Policy-Based Networking)という概念でIPネットワークを制御する枠組みを提案している。PBNでは、ポリシーサーバがネットワークの運用ポリシーをルータなどのネットワーク機器群に設定し、ネットワーク機器群が、本ポリシーを参照することでQoS等のサービスを実現する。しかし、移動端末毎のポリシー設定を考えると、ポリシー追加／変更時、移動端末を収容する可能性のあるすべてのネットワーク機器群へのポリシーの設定が必要となり、ネットワーク全体でのポリシー設定処理量が増加する。さらに、PBNで通知される情報をモバイルIP等の個々に規定される基本サービスに適用するためには、それぞれのサービスに適用させるための仕様化と実装検討が必要であった。すなわち、PBNでは、ユーザ／端末毎に異なるサービス制御、例えばQoS制御を提供することが困難である。そこで、本願出願人は、インターネットにおいてユーザ／端末毎にカスタマイズされたIPサービスを提供する「統合IPサービス制御アーキテクチャ」を提案している。
【０００３】
・統合IPサービス制御アーキテクチャ
インターネットへの要求の一つとして、アプリケーション、端末能力等の多様化が進むことで、ユーザ毎にきめ細かなサービス制御機能が必要になると予想される。しかし、現在あるいは上記PBNのインターネットは、ユーザ毎にカスタマイズされたIPサービスを提供する機能が十分とは言えない。本願出願人が提案する上記「統合IPサービス制御アーキテクチャ」の特徴は、(1)ユーザ毎にカスタマイズされたIPサービスを提供できる点、(2)移動通信をベースに固定端末を移動度0の移動端末とみなし、移動通信に必須な位置登録機能を高度化することで固定端末と移動端末の双方へのサービス制御を行なう点、(3)位置登録時にサービス制御に必要な手続きやデータ（サービス制御情報）を網内の必要装置にのみキャッシュ設定し、パケット転送時に本キャッシュを用いてサービス制御する点にある。さらに、本アーキテクチャ実装について、IETF(Internet Engineering Task Force)で検討中のMobile IPを適用することでインターネットへの配備を可能とする。
【０００４】
すなわち、「統合IPサービス制御アーキテクチャ」は、固定/移動の区別なく、ユーザ/端末毎にカスタマイズされたIPサービスを提供できるようにするものであり、
(1)固定/移動を統合した制御技術、
(2)配備の容易性を考慮した機能分離技術、
(3)位置登録、位置問い合わせ手順を応用した制御情報の配布技術、
(4)サービスプロファイルのオープン化の技術、
を特徴とするものである。
【０００５】
(1)の固定／移動を統合した制御技術とは、固定端末を「移動度＝0」の移動端末とみなし、IPネットワーク種別（パケット転送方式、固定／移動等）に依存しない制御を行う技術である。(2)の配備の容易性を考慮した機能分離技術とは、レイヤをサービス制御レイヤとIPパケット転送レイヤに分離し、各々のレイヤを独立に開発、配備を可能にする技術である。(3)の制御情報の配布技術とは、ネットワーク上の端末の位置登録を契機に、パケット転送に関わる機器のみにサービス制御情報（サービスプロファイルや位置情報）を配布する技術である。(4)のサービスプロファイルのオープン化技術は、ポリシーベースネットワーク管理システムと連携し、ユーザ自身に編集機能を提供することである。
【０００６】
・統合IPサービス制御アーキテクチャの基盤
以下において、本発明の基盤になっている「統合IPサービス制御アーキテクチャ」における(1)レイヤ構造、(2)サービス制御方式、(3)Mobile IPの原理、(4)Mobile IPへの適用(サービスプロファイル配布手順)、(5)Mobile IPへの適用(サービス実行手順)について説明する。
【０００７】
(1)レイヤ構造
図9１は統合IPサービス制御アーキテクチャのレイヤ構造説明図であり、レイヤはサービス制御レイヤSCLとIPパケット転送レイヤPTLに分離されている。サービス制御レイヤSCLには、サービスプロファイルデータべース(サービス制御データべースともいう)SPDB、位置情報データべースPIDB、IPサービス制御機能を実行するサーバSVが設けられている。サービスプロファイルデータべースSPDBには、個々の加入者(端末)のサービス制御情報たとえば品質制御情報QoSなどが契約時に登録されており、また、位置情報データべースPIDBにはユーザ端末からの位置登録により各加入者の所在位置を示す位置情報が登録されている。サーバSVは各データべースの情報を管理すると共に、必要に応じて位置情報及びサービスプロファイル情報をIPパケット転送レイヤPTLのエッジルータERT1,ERT2,ERT3に配布する。IPパケット転送レイヤPTLは、コアネットワークNW、コアネットワークの周辺に配置され、多数のユーザ端末を収容し、特定のサービス制御、例えば品質制御サービスを実行するエッジルータERT１〜ERT3を備えている。
【０００８】
サービス制御レイヤSCLのサーバSVは、(a)端末の位置(どのルータに収容されているか)及び端末に設定されているサービスプロファイルを管理すると共に、(b)着目している端末に設定されているサービスプロファイルに基づいてサービス制御を実行し、さらには、(c)所定の端末の位置情報やサービスプロファイルをエッジルータに配布する。IPパケット転送レイヤPTLのエッジルータERTは、(a)サービス制御レイヤSCLに位置登録要求すると共に、(b) サービス制御レイヤSCLから配布される通信先端末の位置情報やサービスプロファイルをキャッシュメモリに保存し、(c)保存後、サービス制御レイヤSCLを介さずキャッシュメモリに保存されているサービスプロファイルのルールに基づいてサービス制御を実行して通信先端末と通信する（キャッシュ実行機能）。
【０００９】
(2)サービス制御方式
図9２は統合IPサービス制御アーキテクチャにおけるサービス制御方式の説明図である。
▲１▼端末MN１（IPアドレス:IP＃M1）は、エッジルータERT1を介してIPサービス制御レイヤSCLのサーバSVに位置登録要求メッセージを発行する。これにより、サーバSVは位置情報データべースPIDBに端末MN1（IP＃M1）に対応させて該端末を収容するルータERT1のIPアドレス（IP＃F1）を登録する。なお、既にサービスプロファイルデータべースSPDBには、端末MN1（IP＃M1）に対応させて、宛先ポート番号、品質制御情報QoSが登録されている。例では、ポート番号80はHTTP(Hyper Text Transfer Protocol)用のポートであり、高QoS（例えば、高い優先度）が設定され、ポート番号２５はSMTP（Simple Mail Transfer Protocol）用のポートであり、低QoS(例えば、低い優先度)が設定されている。
【００１０】
▲２▼かかる状態において、端末MN2（IP＃M2）が端末MN1（IP＃M1）に初めてデータパケットを送信する場合、該データパケットはサーバSVのサービス制御機能を経由してサービス実行され、端末MN1（IP＃M1）に送達される。すなわち、端末MN2を収容するエッジルータERT2はサーバSVに端末MN1の位置及びサービスプロファイルを問い合わせ、サーバSVは得られた位置情報/サービス制御情報に基づいて端末MN1（IP＃M1）に端末MN2（IP＃M2）からのパケットを送達する。
【００１１】
▲３▼ついで、サーバSVは、前述のように端末MN2（IP＃M2）を収容するエッジルータERT2に端末MN1（IP＃M1）の位置情報とサービスプロファイルを送達する。エッジルータERT2は送達された情報を内蔵のキャッシュメモリに保存し、以後、キャッシュメモリに保存した位置情報及びサービスプロファイルを参照して端末MN1（IP＃M1）と通信する。
▲４▼サーバSVよりエッジルータERT2にサービスプロファイル配布後、エッジルータERT2は、端末MN2（IP＃M2）から端末ＭＮ1（IP＃M1）宛てのパケットが発生すると、サーバSVを介さず単独で端末ＭＮ1のサービス制御を実行して送信する。
【００１２】
(3)Mobile IPの原理
図9３はMobile IPの原理説明図であり、NWはコアネットワーク、ISP-1は端末MN1のホームネットワーク、HAは端末MN1のホームネットワークISP-1を統括管理するエッジルータ(ホームエージェント：Home Agentという)、ISP-2はコアネットワークNWに接続するホームネットワーク以外の外部ネットワーク、FAは外部ネットワークISP-2を統括管理するエッジルータ(フォーリンエージェント)、AAASは認証、許可、及び課金処理(Authentication Authorization Accounting)を実行するAAAサーバである。Mobile IPはIPネットワークにおいて端末の移動をサポートするプロトコルである。Mobile IP以前のIPネットワークでは、端末毎に割り当てられたIPアドレスは特定ネットワーク内の番号体系において固定であり、そのネットワークにおいてのみ有効で、別のネットワークに持って行くことは基本的に不可能であった。Mobile IPはこれを可能にするものである。
【００１３】
すなわち、
▲１▼端末MN1はホームネットワークISP-１から外部ネットワークISP-2に移動する。
▲２▼端末MN1は外部ネットワークISP-2に移動すると、フォーリンエージェントFAに対して位置登録要求メッセージを送出する。これにより、フォーリンエージェントFAは端末MN1の認証をAAAサーバに依頼する。
▲３▼AAAサーバは端末MN1の認証を完了すれば、端末MN1のホームネットワークISP-1上で端末MN1を管理するホームエージェントHAに移動先位置の登録を依頼する。
【００１４】
▲４▼登録要求メッセージを受信したホームエージェントHAは、端末MN1の移動先（位置）として、移動先ネットワークISP-2を管理するエッジルータ(フォーリンエージェントFA)のIPアドレス（IP#f.a）を認識し、同時に、端末MN1の位置情報として内部に移動性結合テーブルMCTBを作成し、以後このテーブルで端末MN1の位置を管理する。位置登録が完了すればホームエージェントHAは登録応答メッセージをAAAサーバに対して返信する。
▲５▼AAAサーバは登録応答メッセージをフォーリンエージェントFAを宛先として中継し、フォーリンエージェントFAは端末MN1に位置登録が完了したことを通知する。以後、端末MN１に送信されるデータパケットはHA／FAを経由して訪問先ネットワークISP−2上の端末MN1に送還される。すなわち、端末MN1へのパケットは通常のルーチングによりホームネットワークISP-1のホームエージェントHAに到達する。ホームエージェントHAは移動性結合テーブルMCTBを参照し、端末MN1の位置を認識し、ＩＰトンネリング技術により強制的にパケットをフォーリンエージェントFAに転送し、フォーリンエージェントFAは該パケットを端末MN1に送達する。
【００１５】
(4)Mobile IPへの適用例(サービスプロファイル配布手順)
図9４はMobile IPへの適用例(サービスプロファイル配布手順)の説明図であり、AAAサーバにIPサービス制御機能を持たせ、位置登録時にサービスプロファイルをAAAサーバよりホームエージェントHAとフォーリンエージェントFAに配布する。なお、AAAサーバはホームエージェントHAに位置情報も配布する。サービスプロファイルの概略的な配布手順は以下の通りである。
▲１▼移動端末MN(MobileNode)は移動によりフォーリンエージェントFAに位置登録要求を送信する。フォーリンエージェントFAはこの位置登録要求を、AAAサーバに中継する。
【００１６】
▲２▼AAAサーバは位置登録要求を受信すると位置情報データべースPIDBに登録すると共に、移動端末MNのサービスプロファイルをサービスプロファイルデータべースSPDBから検索する。
▲３▼AAAサーバは検索したサービスプロファイルを位置情報と共にホームエージェントHAに送信する。ホームエージェントHAはこれらを内蔵のキャッシュメモリに保持する。以上により、ホームエージェントHAは以後AAAサーバに問い合わせること無く、キャッシュメモリを参照することにより配下の移動端末MNの位置情報及びサービスプロファイルの取得が可能となる。
▲４▼位置登録が完了すればホームエージェントHAはAAAサーバに登録応答メッセージを返す。
【００１７】
▲５▼これにより、AAAサーバは移動端末MNのサービスプロファイルをフォーリンエージェントFAに配布し、フォーリンFAは該サービスプロファイルを内蔵のキャッシュメモリに格納する。
▲６▼又、フォーリンエージェントFAは移動端末MNに位置登録の完了を通知する。以上により、以後AAAサーバにサービスプロファイルや位置情報を問い合わせること無く、フォーリンエージェントFAは端末MNからのパケットに所定のサービスを実行して他の端末へ送信することができる。又、ホームエージェントHAは該移動端末MN宛てのパケットに所定のサービスを施して送信することができる。
【００１８】
(5)Mobile IPへの適用例(サービス実行手順)
図95はMobile IPへの適用例(サービス実行手順)説明図である。サービス実行の概要は、ホームエージェントHAが、移動端末宛てのパケットに対するサービスを実行し、フォーリンエージェントFAが移動端末が発するパケットに対するサービスを実行する。すなわち、
▲１▼所定通信ノード(Correspondent Node)CNから移動端末MNへ送信するデータパケットは、エッジルータERT3を経由して移動端末MNのホームエージェントHAに至り、ここで所定のサービスを施され、コアネットワークNWを介してフォーリンエージェントFAに到達する。すなわち、ホームエージェントHAが持っているサービスプロファイルに基づき移動端末MN宛てのパケットにサービスが施される。
【００１９】
▲２▼移動端末MNから所定の通信ノードCNへ送信するパケットは、移動端末MNのフォーリンエージェントFAを通過する際に、サービスプロファイルに基づい所定のサービス制御が施され、しかる後エッジルータERT3を介して通信ノードCNへ送信される。
以上、提案されている「統合IPサービス制御アーキテクチャ」によれば、固定/移動の端末毎にサービス制御の契約条件を設定してIPサービス(例えば帯域保証、QoS制御)等を提供できる。この結果、ネットワーク資源の使用料と契約条件を関連つけることで設備投資に見合った収益を得ることが期待できる。
【００２０】
・現状の課金技術
現在、固定/移動を含めたインターネット接続サービスにおいて、加入者が支払う料金体系は定額課金以外に以下の２つのカテゴリ、
(1) パケット流量や回線接続時間に対する課金
(2) 情報/コンテンツサービスに対する課金
に分類される。しかし、現状のサービスプロバイダのサービス契約条件は、期間契約等による定額課金制が主である。従量課金等の新規の課金メカニズム導入は、サービス利用料（例：消費パケット数）の計測機能をネットワーク内のルータ等に分散配備する必要があり、単独のサービスプロバイダ、特に小規模、新規のサービスプロバイダが適正な投資効果のうえに従量課金メカニズムを構築することは難しい環境にある。
・ASP(Application Service Provider)の台頭
現在，InternetのサービスとしてASP(Application Service Provider)事業が各所で立ちあがりつつあり、各種のソリューションを提供されつつある。ASPの基本的な考えの一つは、従来端末個別に売りきりで販売していたパッケージソフト、もしくはサービスをネットワーク経由で提供し、ユーザの利用量（利用時間 and/orデータ）に応じて料金徴収するビジネスである。ASPが提供するサービスは多岐に渡り、グループウエアから通常のパッケージソフトまで各種提案されている。ASPを利用するユーザの目的は「購入するほど使用頻度が高くないため、使った分だけ支払って節約したい」という動機が多いと考えられるため、従量課金等多様な課金方式の需要があると予想される。
・モバイルにおける料金に関する現状
移動端末、特に携帯電話における音声通話以外のデータサービスの普及が著しい。これらのデータサービスは具体的にはインターネットへの接続であるが、この通信基盤を利用したサービスは現状、月極め契約の情報サービス、もしくは物品の決済（モバイル・コマース）がほとんどである。これらの特徴は、ネットワーク上の情報使用量などと関係なく、一定額の支払いの合意を契機としてサービス提供が行われるもので、ユーザごとのニーズ、ネットワーク上での配信状況等を含めたコンテンツに対して支払われるものにはなっていない。
【００２１】
以上より、従量課金等の新規の課金メカニズムをネットワークオペレータが導入し、汎用機能としてサービスプロバイダに提供する運用形態が現実的である。このようにすれば多彩な課金方式の適用が可能となり、サービス提供者間の競争を活性化できる。また、代金回収をネットワーク運用者が代行するようにすれば、ユーザは個々のサービスプロバイダとの固定的な個別契約を必要とせず、安心して利用することがきるようになり、コンテンツプロバイダの参入を容易にできる。
・戦略的な課金の必要性
あらゆる情報通信手段がIP（Internet Protocol）への統合を試みられている現状において、今後のIPサービス事業の隆盛により業者間での競争の活発化が予想されるが、その差別化の要素としては，(1)サービス内容の差別化（カスタマイズ、特殊機能等）、(2) 戦略的な料金プランの提供、が考えられる。特に、従量課金制が有効なASPサービスでは(2)は重要で、同種のサービスを提供する複数業者間での競争の活性化に寄与できる。
【００２２】
・優良な新サービスの出現を促進する条件
今後、広帯域化が進むインタネット上で独自性の高いサービスが出現するためには以下の(a)、(b)、
(a)多彩な課金方式の選択肢を提供し、サービス提供者間の競争を活性化する、
(b)課金業者が代金回収することで、コンテンツプロバイダの参入を容易にする、
の基盤を確立することである。すなわち、これらの基盤は、独自性の高いサービスが出現するために必要であると考えられる。ｉモードの勝因の１つは、簡便ながらコンテンツへの課金を代行した点にあるといわれている。これら2つの基盤を満足する課金技術を確立できれば、該課金技術を端末単位の契約サービス制御技術に連携することにより、端末毎はもとより、さらにサービス種別毎に多様な料金設定の提供が可能となり、ネットワーク運用業者に対して効果的な設備投資を可能とし、又、サービス提供者間の競争を活発化させることができる。
【００２３】
【発明が解決しようとする課題】
音声とデータ通信が統合された、多様な種類の端末が接続されるIPネットワークでは、遅延に敏感なトラフィックやビジネス上優先度の高いトラフィックを保護するためQoS機能の実現は必須である。QoSを実現する手段としてInt-ServやDiff-Servといった方式が提案されているが、キャリア網やバックボーン網としてはオーバヘッドが少ないDiff-servサポートが有力視されている。
【００２４】
しかしDiff-servは、経路上のネットワーク機器へのポリシー設定を必要とし、Diff-Serv単独ではネットワーク管理が煩雑になるといった問題がある。そのためネットワーク機器へのポリシー設定をポリシーサーバと呼ばれるサーバから一括設定するPBN （Policy-Based Networking）という概念が提案された。しかし移動端末をサポートした様々なプロバイダ、キャリアから構成されるシームレスなグローバルネットワークでは、全てのローカルネットワークが接続可能性のあるユーザに対するポリシーの決定とネットワーク機器への情報設定が可能でなければならない。PBNでこれを行うためには、全てのユーザのポリシ情報をローカルに保持するか、可能性のある全てのネットワーク機器に対して情報をあらかじめ設定するしかない。これは億単位にものぼるユーザに対して実行するのは極めて非効率的であり、現実的ではない。又、全てのユーザのポリシー情報を常時、ネットワーク機器に保持するのは、ネットワーク機器のメモリ量増加を招き、処理能力を劣化させる。逆に、常にポリシーサーバへ尋ねるような処理方式とした場合は、問い合わせのオーバヘッドが発生し、SLA (Service Level Agreement)を遵守できない可能性が増大するといった問題もある。
【００２５】
既述の「統合IPサービス制御アーキテクチャ」におけるIPサービスは、加入者個別のサービス制御方式を実現するものであるが、加入者単位の個別条件に基づくサービスを提供するにあたっては、提供したサービスに応じた料金体系により適切に課金を行う必要がある。そこで、本発明は、上記アーキテクチャと連携することを前提に、端末単位および端末が利用するサービス単位の課金条件の設定を可能とする課金技術を提案する。この課金技術における具体的な課題１〜3を以下に列挙する。
【００２６】
課題１：柔軟な課金機能の導入
現在の移動端末において提供されるサービスの課金単位は、月額固定もしくは、特定の物品に対する支払い決裁、といった形式であり、ユーザ単位ではなくサービス提供業者の決定する固定的な条件のみで課金されていた。
今後、広帯域化の進むモバイルインターネットにおいて、高品質コンテンツの提供が進むと予想されるが、これらは高精度なコアネットワークのIPサービスに対する品質制御のうえに成り立つと考えられる。このため、高品質なアプリケーションに対しては、それに見合う料金プランの設定が必要になり、コンテンツ提供業者間の競争を生むためにユーザ単位、サービス種別単位に多彩な課金方式を提供する必要がある。基本的な市場原理の一つとして、企業間で活発な競争を生むためには、顧客に対して、課金方式に関して多彩な選択肢を与えることが重要である。
【００２７】
端末単位（ユーザ単位）に個別サービスを提供しようとする場合、端末単位で課金のための規則（課金条件）が異なるはずである。
又、移動端末単位に個別の課金条件を設定し、この課金条件を移動先のネットワークで適用可能にするためには、ネットワーク内の全ての課金装置(課金エンジン)に、当該移動端末の課金条件を設定する必要がある。かかる場合、工夫しないと課金装置１台につき、当該ネットワークに収容される莫大な数の全端末分の課金条件を予め設定することが必要になり、ネットワーク制御機構の大規模ネットワークへの適用性の点で現実的ではない。
【００２８】
また、多彩なサービスの出現を促進させるためには、サービス提供業者に対して、特色を出しやすくするように多彩な課金条件を提供することが有望な一方法である。このためには、端末単位で課金サービスの許容条件を規定するとともに、サービス提供業者に対して多彩な課金条件を提供する。このようにすれば、提供可能なサービス条件のパターンを飛躍的に拡大することができ、ユーザのニーズに合ったサービスを提供できるようになる。
【００２９】
課題２：移動端末への課金の適用
現在の移動端末における品質制御技術の主なものに、スムースハンドオフ(smooth hand off)技術がある。これは、移動端末の基地局間の移動に際して、データの通信を継続することを目的とする技術である。ただし、現状のハンドオーバ技術はレイヤ３（IPレイヤ）におけるパケット単位の転送制御であり、上位アプリケーションレベルの認証セッション情報とは連携しない。一方、有料サービスではネットワーク内部の課金機能部がサービスに関するセッション情報を認識する必要がある。このため、高品質かつ有料なアプリケーションの導入において、移動端末へのサービス提供時の課金情報をハンドオーバ後にも厳密に把握、継承することが必要となってくる。例えば、一旦、サーバと移動端末間で開始された有料アプリケーションの供給において、ハンドオーバの前後で有料アプリケーションに関する課金情報を新旧基地局間で交換して、移動後に即座に課金を継続する機能が必要になる。
【００３０】
・課題３：代行課金の実現
現状のインターネット上の有料サービスの多くは、大規模な事業体がデータセンタを始めとする高度な設備を駆使して展開しつつある。この業態の先駆けとしては米国のamazon.com などがあり、既存の店舗ベースの書店を駆逐しつつあると伝えられる。ただし、同社は売上自体が伸びているものの、収益率は決してよいとはいえない。この原因としては、非常に高額なインフラ（サーバ、回線）の導入、維持に多大な費用がかかるためであり、これが反面小規模事業者の参入の障害となる。
今後あらゆる業種、規模の事業者がIPサービスの提供業者として参入する上で必要なものは、低廉かつ信頼性の高い商取引のインフラであり、必要十分な回線容量、サーバはもとよりASP(Application Service Provider)サービスを提供するために柔軟な課金機能を提供することが必要である。
このため、IPサービスを提供しようとする事業者に対して、ネットワーク運用者が課金機能を提供して代行課金することで、新規かつ小規模な事業体の参入を容易にする。代行課金するには、ネットワーク内部に課金装置を配備し、これにより課金対象となるサービスに関するパケットを観測、情報抽出する必要がある。
【００３１】
課題４：IPv4, IPv6それぞれに適用できる課金技術
IPv4/Mobile IPをべースとしたネットワーク構成において上記課題１〜３を満足する課金技術及び今後の商用インタネットプロトコルの主体と見られるIPv6をべースとしたネットワーク構成において上記課題１〜３を満足する課金技術をそれぞれ提供する必要がある。
【００３２】
以上より、本発明の目的は、ユーザ毎に提供するサービスに応じた課金ができるようにすることである。、
本発明の別の目的は、サービス種別単位に多彩な課金方式を提供できるようにすることである。
本発明の別の目的は、ユーザおよびサービス提供者双方に課金に関する許容条件を用意してサービス開始時に双方の許容条件を照合し、サービス提供に対する課金条件を動的に生成し、該課金条件にしたがって課金できるようにすることである。
本発明の別の目的は、有料サービスに対するネットワーク内の代行課金を可能にすることである。
本発明の別の目的は、端末が移動しても該端末に対する課金制御をサポートできるようにすることである。すなわち、端末移動によりハンドオーバが発生しても、サービス開始時にユーザ・サービス提供者間の交渉手順により動的に生成した課金条件を引き継いでサービスの提供、課金の継続をサポートすることである。
本発明の別の目的は、価格交渉／課金条件設定の手順を位置登録手順を利用して実行できるようにすることである。
本発明の別の目的は、IPv4/Mobile IPをべースとしたネットワークにおいて適用できる課金技術及びIPv6をべースとしたネットワークにおいて適用できる課金技術を提供することである。
【００３３】
【課題を解決するための手段】
第1の発明はIPv4/Mobile IPをべースとしたネットワーク構成において利用できる課金技術であり、第２，第３の発明はIPv6をべースとしたネットワーク構成において利用できる課金技術である。
第1の発明は、ユーザ端末にサービスを提供するための処理を行い、ネットワークを介して該ユーザ端末に提供するサービスに対して課金を行う課金システであり、(1)料金と関連付けられたサービス情報を記述した1以上のサーバ課金プロファイルを保存するサーバ課金プロファイル登録部と、ユーザ課金プロファイルと前記各サーバ課金プロファイルを照合することによりユーザ端末に提供するサービスに対する課金条件を決定する課金条件生成部を備えたサービス提供サーバ、(2)ユーザ端末が収容されたルータ、(3)サービス種別およびユーザ端末単位のユーザ課金プロファイルを保持するユーザ課金プロファイル登録部を備え、ユーザ端末の位置登録時に該ルータより受信する認証要求メッセージに基づいて端末認証処理を実行すると共に、該認証要求メッセージにサービス要求情報が含まれていれば、当該ユーザ端末及びサービス種別に応じたユーザ課金プロファイルを取得して前記課金条件生成部に転送する認証サーバ、(5)前記生成された課金条件に基づいてユーザ端末毎に前記サービス提供サーバがユーザ端末に提供するサービスに対する課金処理を実行する課金部、(6)該課金部に前記生成された課金条件を設定する課金条件設定部を備え、前記ユーザ課金プロファイルにユーザの支払い許容条件を記述し、前記課金条件生成部は、ユーザ端末がサービス実行要求メッセージを送出した時点で前記ユーザ課金プロファイルと各サーバ課金プロファイルを照合することにより、提供するサービスに対する課金条件を決定する。
かかる課金システムによれば、ユーザ、サービス提供者双方に課金に関する許容条件を用意してサービス開始時に双方の許容条件を照合し、サービス提供に対する課金条件を動的に生成し、該課金条件にしたがって課金することができる。また、ネットワーク内の課金部により有料サービスに対する代行課金を行うことができる。
また、ネットワークは、位置登録手順と並行して、ユーザ端末毎に且つ要求されたサービス毎に、課金条件の生成処理、課金部の起動処理を行い、サービス実行前に課金条件の生成、課金部の起動を完了することができる。
【００３６】
第２の発明は、ネットワークを介してユーザ端末に提供されるサービスに対して課金する課金システムであり、(1)ユーザ端末にサービスを提供するサービス提供ノード、(2)サービス提供ノードが許容するサービス提供条件を記録したサーバ課金プロファイルを登録するサーバ課金プロファイル登録部を備え、ユーザ端末が希望するサービス提供条件を記録したユーザ課金プロファイルと該サーバ課金プロファイルを比較してユーザに提供するサービスに関する課金条件を生成する課金制御ノード、(3)ユーザ端末の正当性の認証を行なうと共に、該ユーザ端末のユーザ課金プロファイルを管理する認証ノード、(4)ユーザ端末からのアドレス割当要求により該ユーザ端末にアドレスを割り当てると共にユーザ端末の正当性の認証を認証ノードに要求し、認証応答時に、該認証ノードより受信する前記ユーザ端末のユーザ課金プロファイルを保持し、ユーザ端末からのサービス提供要求に基いて通過するメッセージを検出し、該メッセージに前記ユーザ端末のユーザ課金プロファイルを付加し、該メッセージを前記課金制御ノードに直接あるいはサービス提供ノードを介して送達するエッジノード、(5)サービス提供ノードに代わって該サービス提供ノードがユーザ端末に提供するサービスに関して前記課金条件に従って課金する代行課金部を備えている。
第２の発明によれば、第1発明の課金技術と同等機能を実現しながら、網および端末への機能追加を不要にすることができる。また、第２発明の課金技術によれば、第１発明の課金技術に比較して、課金制御メッセージの転送経路を最適化することができる。又、第２発明の課金技術によれば、サービス提供者側装置としてのサービス提供ノードXSPNと課金制御ノードBCNを分離したことで、１サービスを複数に分散されたサーバで提供するサービス提供形態であっても課金することができる。
【００３７】
【発明の実施の形態】
（Ａ）本発明の第1課金技術の概略
端末単位の契約サービスは大別すると、
(1)基本サービス、
(2)付加サービス(有料サービス)
の２つがある。基本サービスは契約時点で端末に提供されるサービスとして決定されるものであり、契約時のサービスプロファイルに従うものである。付加サービスは、サービス提供者の設定する条件により提供される有料サービスである。本発明は付加サービスを提供するにあたって必要な課金機能に関する課題を解決する手段を提供する。
【００３８】
・ユーザとサービスプロバイダ間の価格交渉
付加サービスとして、サービス提供者自身が一定範囲で自由に料金・課金条件を設定し、ユーザが価格を考慮して所定のサービスを選択できるようにすることが望まれる。又、ここで収集された料金はネットワーク運用者(キャリア)が代行課金し、サービス提供者の参入を容易にすることが望ましい。
そこで、本発明では、(1)ユーザ側、サービス提供者側の双方に、個々の料金条件を記述した課金プロファイル(ユーザ課金プロファイル、サーバ課金プロファイル)を配置し、サービス実行前に両者の課金プロファイルを照合し、自動的に提供可能な課金条件を抽出、生成する。(2)また、代行課金を行うために、課金情報をネットワーク内装置(課金エンジン)で収集する。
【００３９】
・移動端末の課金サポート
移動端末が基地局間移動する場合であっても移動端末に対する課金をサポートする必要がある。すなわち、一度、料金交渉の成立した有料サービスをハンドオーバが発生しても品質を保持したまま途切れないように、かつ、同一の課金条件で課金を継続する必要がある。
そこで、本発明では、ハンドオフ時に新旧基地局間で交換される結合情報を利用して課金情報を伝達する。課金情報及びアプリケーションレベルのセッション情報を新旧基地局間で交換、照合する。これにより、初期登録時に発行されたアプリケーションセッション情報及び課金条件を基地局間移動時に引継ぎ可能とする。
【００４０】
・価格交渉、課金準備手順の実行契機
付加サービスの課金を可能にするためには以下の動作の実行契機を決める必要がある。すなわち、
(1)ユーザとサービスプロバイダ間の価格交渉手順を実行する契機、
(2)既存の電話網と同様に、課金情報はもとより呼情報に相当する利用履歴を厳密に収集する必要があるがその設定契機、
を決める必要がある。これらは、サービス実行前に完了することが必要であり、サービスパケットを検出してからでは遅い。
【００４１】
そこで、本発明の第1課金技術では上記手順を移動端末の位置登録手順に含める。一般に、移動端末のユーザの関心はサービス実行そのものであり、ネットワークレイヤの動作である端末の位置登録は意識しない。有料の付加サービスを提供するために必要な上記２つの手順はユーザに意識させないタイミングで実行されることが望ましい。
【００４２】
（B）ネットワークの構成
（ａ）全体の構成
図1は本発明の第1課金技術を適用できるIPv4/Mobile IPをべースとしたネットワークの全体の構成図であり、移動ノード(MN:Mobile Node)11のサービスプロバイダにより管理されるホームネットワーク1、他のサービスプロバイダによりそれぞれ管理される外部ネットワーク２~4がIP中継網5を介して接続されている。
【００４３】
移動ノード(移動端末)11のホームネットワーク1には、ホームエージェント(HA: Home Agent)21、AAAH (Authentication, Authorization, Accounting Home)サーバ22が設けられている。ホームエージェント21は、RF2002において定義されている機能エンティティであり、例えば、ルータ装置により実現される。又、ホームエージェント21は、移動ノード11に割り当てられているホームアドレスを所有・管理し、また、移動ノードの位置を管理する。AAAHサーバ22は、移動ノードの認証、許可、及び課金に係わる処理を実行するサーバ装置であり、AAAHはIETFにおいて用いられている名称である。ホームネットワーク1には複数のAAAHサーバ、複数のホームエージェントHAを設けることができるが、図ではそれぞれ1つのみ示している。
【００４４】
サービスプロファイルデータべース(SPDB)23は、各移動ノードに通信サービスを提供するためのサービス制御情報(サービスプロファイル)を格納するもので、AAAHサーバ22のみがアクセス可能である。サービスプロファイルデータべース(SPDB)23の検索プロトコルは、特に限定されるものではないが、例えばLDAP(LightWeight Directory Access Protocol)が用いられる。更に、各ホームエージェント21には、基地局（BS:Base Station）2４が接続されている。基地局24は、無線インターフェースを備え、端末装置(移動ノードを含む)との間に無線伝走路を確立する。無線アクセス方式は、例えば、MC-CDMA(Multicarrier Code Division Multi Access)が採用される。
【００４５】
外部ネットワーク2〜4には、外部エージェント(FA:Foreign Agent) 31-1, 31-2,、AAAF(Authentication,Authorization,Accounting Foeign)サーバ32-1, 32-2、サービスプロファイルデータべース(SPDB)33-1,33-2、基地局35-1,35-2、固定端末(SN:Stationary Node)36等が設けられている。外部エージェント31は、RF2002において定義されている機能エンティティであり、ルータ装置により実現される。この外部エージェント31は、契約により自己のホームアドレスが付与されている移動ノード(管理対象の移動ノード)に対してはホームエージェントHAの機能を提供し、その他の移動ノードに対しては外部エージェントFAの機能を提供する。
【００４６】
AAAFサーバ32はAAAHサーバ22と同様に、移動ノードの認証、許可、及び課金に係わる処理を実行する。ただし、AAAHサーバ、AAAFサーバ(総称してAAAサーバ)はそれぞれ管理対象の移動ノードについてのみ認証、許可、及び課金に係わる処理を実行する。従って、各AAAサーバは、管理対象でない移動ノードからアクセス要求(例えば認証要求)を受信したときは、その移動ノードを管理するAAAサーバに対してその要求に係わる処理を依頼し、その依頼を受けたAAAサーバが上記アクセス要求を処理する。依頼を送出したAAAサーバはアクセス要求した移動ノードにとってAAAFサーバであり、一方、依頼を受けたAAAサーバは該移動ノードのAAAHサーバである。
【００４７】
移動ノード11は移動しなければホームエージェントHA 2１に収容され、移動により任意のエッジルータ(外部エージェント)31-1に収容されて他の端末装置と通信する。移動ノード11と通信を行う端末装置を通信ノード(CN:Correspondent Node)という。この通信ノードCN 41は例えば外部ネットワーク4内に存在する。移動ノード11は、無線伝走路を利用して通信する場合は図示するように基地局35-1を介してエッジルータ(外部エージェント)31-1に収容される。
【００４８】
（ｂ）要部の詳細構成図
図2は図1におけるがホームネットワーク１、外部ネットワーク２、４の要部詳細図である。ホームネットワーク(サービスプロバイダ)1はホームエージェント21、AAAHサーバ22、サービス制御データべース(サービスプロファイルデータべース)23を含み、AAAHサーバ22と少なくとも１つのホームエージェント21との間はAAAプロトコル等により接続されている。AAAプロトコルとしては現在IETFで検討中のDIAMETERプロトコルを使用することができる。AAAHサーバ22とサービス制御データべース23との間は、データべース検索プロトコルLDAPにより接続され、このサービス制御データべース23には、▲１▼移動端末、固定端末、又はこれら端末の利用者に関する情報、▲２▼QoS情報(サービス品質情報)、▲３▼パケットの優先転送順位、▲４▼有害WWW情報などへのアクセスを禁止するパケットフィルタリング情報、▲５▼セキュリティ情報、▲６▼Diff-Serv関連情報などが登録されている。AAAHサーバ22は、データベース検索プロトコルLDAPを利用してサービス制御データべース23から所定の端末のサービスプロファイル情報を取得することができる。
【００４９】
外部ネットワーク(アクセスプロバイダ)２は、外部エージェント31、AAAFサーバ32を含み、外部エージェント31には移動端末(移動ノードMN)11、固定端末(固定ノードSN)３６が接続されている。AAAFサーバ32と外部エージェント31との間は、AAAプロトコルにより接続され、移動端末11及び固定端末36はMIP(Mobile IP)を介して外部エージェント３１と接続されている。なお、移動端末11は契約しているサービスプロバイダ（ホームネットワーク）１の通信可能範囲外であって、アクセスプロバイダ(外部ネットワーク)2の通信可能範囲内に位置しており、MIPプロトコルを介して外部エージェント31に接続している。
AAAHサーバ22は、外部ネットワークであるアクセスプロバイダ2のAAAFサーバ32とAAAプロトコルを介して接続されているが、これらの間は、IPネットワーク5を介して接続されてもよい。
【００５０】
（ｃ）エージェント
・エージェントの機能
移動ノードのIPアドレスはそれぞれ対応するホームエージェントHAにより管理され、そのIPアドレスに基づいてパケットの転送が行われる。すなわち、移動ノード11宛てのパケットは一旦ホームエージェント21へ転送される。移動ノード11がホームネットワーク内に存在する場合には、ホームエージェント21は該パケットを移動ノード11に転送する。
【００５１】
しかし、移動ノード11が図示するようにホームネットワーク1から外部ネットワーク2に移動していると、移動端末11からの登録要求により、外部エージェント31はホームエージェント21に対して位置登録する。これにより、ホームエージェント21は、移動ノード１１宛てのパケットを受信すると、上述の位置登録通知に従ってそのパケットをカプセル化して(転送先として外部エージェント３１が設定された新たなIPヘッダを受信パケットに付加すること)、外部エージェント31に転送する。外部エージェント31は受信したパケットから新たに付加されたIPヘッダを削除することによりそのパケットをデカプセル化し、元のヘッダが示すアドレス、すなわち、移動ノード11のアドレスにパケットを転送する。これにより、移動ノード11が移動した場合であっても、その移動ノード11に上記パケットが送信される。尚、パケットを転送する際、移動ノード11のホームアドレスに対応したリンクレイヤアドレスを使用してパケットを転送することもできる。IPアドレスとリンクレイヤアドレスとの対応は訪問者リスト呼ばれるテーブル(後述)に管理される。
【００５２】
・エージェントの機能ブロック図
図3はホームエージェント21及び外部エージェント31の両方に適用できる機能ブロック図である。すなわち、ホームエージェント21及び外部エージェント31は、基本的に互いに同じ構成を有している。移動ノードが契約しているサービスプロバイダ1に接続した場合、該サービスプロバイダのエージェント装置は、その移動ノードに対してホームエージェントHAとして動作し、移動ノードが契約していないサービスプロバイダに接続した場合、該サービスプロバイダのエージェント装置は、その移動ノードに対して外部エージェントFAとして動作する。以下では、ホームエージェント21及び外部エージェント31は同じ機能を持った装置として説明する。
【００５３】
ホームエージェント21(外部エージェント31)は、それぞれルータ制御部RTC、サービス制御部SVC、サービス制御トランザクションSCTを有している。ルータ制御部RTCは、サービス制御部SVCとの通信を制御するルータ通信制御部RTCCとルータ制御テーブル群RTTGを有している。ルータ制御テーブル群RTTGは、受信したパケットの転送先方路を決定するときに参照されるルーチングテーブルRT、一時的なルーチングテーブルである結合キャッシュCNC及び特定のパケットのみ通過させるためのサービス制御フィルタSFLを有している。
【００５４】
サービス制御部SVCは、ルータ制御部RTCとサービス制御トランザクションSCTとの間の通信を制御するサービス通信制御部SCC及びanycastアドレス結合テーブルADCTを有している。anycastアドレス結合テーブルADCTは、ホームエージェントHA/外部エージェントFAがパケットの転送先を決定・管理するためのテーブルとして設定/参照される。
サービス制御トランザクションSCTは、制御テーブルであり、外部エージェントFAとホームエージェントHAとではそのフォーマットが異なっている。図4に外部エージェントFA 31のサービス制御トランザクションSCTの制御テーブルを示し、図5にホームエージェントHA ２１のサービス制御トランザクションSCTの制御テーブルを示す。
【００５５】
・サービス制御トランザクションの制御テーブル
図4の外部エージェントFA 31におけるサービス制御トランザクションSCTの制御テーブルは、階層構造になっており、最上位層には制御ブロック１〜ｎの先頭アドレスを示すポインタが記入されている。1つの制御ブロック、例えば、制御ブロック1には、移動ノード１１が外部エージェント31に接続したものとすると、▲１▼セッションID、▲２▼移動ノードMNに与えられているネットワークアクセス識別子NAI（Network Access Identifier）, ▲３▼セッショントランザクションテーブルTA1の先頭アドレス,▲４▼訪問者リストテーブルTA2の先頭アドレス、▲５▼サービスプロファイルテーブルTA3の先頭アドレスが設定される。セッションIDは移動ノードMN 11から登録要求メッセージを受信したときの一意な値であり、訪問者リストテーブルは移動ノードMN 11が外部エージェント31に接続されたときにその移動ノードを管理するためのテーブルである。
【００５６】
セッショントランザクションテーブルTA1には、他のエンティティ(外部エージェントFA、ホームエージェントHA、AAAサーバ)との関係が記録される。ここでは、外部エージェント31から送出されるＡＭＲ(認証要求)メッセージの宛先としてのAAAFサーバ32のAAAアドレス(AAAFサーバアドレス)が設定される。
訪問者リストテーブルTA2には、▲１▼ホームネットワーク1により割り当てられている移動ノード11のIP送信元アドレス(ホームアドレス)、▲２▼登録応答メッセージを移動ノードMN(Mobile Node)または固定ノードSN(Stationary Node)に送出するときに使用されるMNまたはSNのリンクレイヤアドレス(例えばMACアドレスなど),▲３▼UBP送信元のポート、▲４▼移動ノード11が属するホームエージェントHA 21のアドレス、▲５▼移動ノードMN 11から送出される登録要求メッセージに含まれる登録要求識別子フィールドの値、▲６▼移動ノードや利用者に関するネットワーク情報及びサービスプロファイル情報などについての有効期限(ライフタイム)に相当する情報が設定される。
【００５７】
サービスプロファイルテーブルTA3には、▲１▼提供すべきサービスのタイプ、▲２▼Diff-Serv適用ポリシー、▲３▼パケットの送信先アドレス、▲４▼パケットの送信先ポート、▲５▼送信先アドレスに送出するIPヘッダのTOS（Type of Service）に関する情報、が設定される。▲１▼のサービスのタイプとしては、例えば、QoS(Quality of Service)を想定する。QoSを実現する方法としては、Int-ServやDiff-Servが提案されている。この実施例では、QoS処理のオーバヘッドが少ないDiff-Servを採用するものとする。▲２▼のDiff-Serv適用ポリシーの設定では、例えば、「FTP (File Transfer Protocol)に係わるデータを格納するパケットを低い優先度で転送する」というようなポリシーが設定される。この時、パケットの転送先アドレス及びポートの組み合わせ毎に異なるポリシーを設定することができる。Diff-ServではTOSの値に基づいて優先制御が行われる。
【００５８】
次に、図5を参照しながらホームエージェントHAのサービス制御トランザクションSCTについて説明するが、外部エージェント31のサービス制御トランザクションとして説明したものはその説明を省略する。
1つの制御ブロック、例えば、制御ブロック1には、移動ノード１１が外部エージェント31に接続したものとすると、▲１▼セッションID、▲２▼セッショントランザクションテーブルTB1の先頭アドレス,▲３▼移動結合テーブルTB2の先頭アドレス、▲４▼サービスプロファイルテーブルTB3の先頭アドレスが設定される。
セッショントランザクションテーブルTB1には、他のエンティティとの関係が記録される。ここでは、ホームネットワーク1のAAAHサーバ22のAAAアドレス(AAAHサーバアドレス)が設定される。
【００５９】
結合テーブルTB2には、▲１▼移動ノードのホームアドレス、▲２▼移動ノードの気付アドレス（care-of address)、▲３▼登録要求識別子フィールドの値、▲４▼有効期限(ライフタイム)情報が設定される。ホームエージェント21は移動ノード11のホームアドレスを転送先とするパケットを受信すると、気付アドレス(care-of address)を用いてそのパケットをカプセル化することにより、該移動ノード11を収容する外部エージェント31に対して受信パケットを転送する。
【００６０】
サービスプロファイルテーブルTB3には、サービスタイプ(パケットフィルタリング)、規制運用ポリシー、規制アドレス、適用条件などが設定される。サービスタイプは、サービスの種類を指定する情報であり、図5の例では、指定された規制条件により該当するパケットを破棄するパケットフィルタリングを指定する情報が設定される。規制運用ポリシー、規制アドレス、適用条件は、規制適用ポリシーの種類、例えば、有害コンテンツを含むパケット、特定のサーバアドレスへのアクセス、特定のネットワークドメインへのアクセス及び特定ポートの使用などを規制するために必要な情報が設定される。
【００６１】
・anycastアドレス結合テーブル
図6はサービス制御部SVCに設けられたanycastアドレス結合テーブルADCTの説明図であり、複数の結合ブロックと各結合ブロックの先頭アドレスを示すポインタ一を含んでいる。各結合ブロックには、▲１▼anycastアドレス、▲２▼anycastアドレス選択ポリシー、▲３▼NAI1〜NAIn、▲４▼NAIに関する状態が設定される。anycastアドレスは送信先アドレスであり、NAI1〜NAInはanycastサービスの提供を受けるユーザにより予め指定されている端末装置対応のNAI(Network Access Identifier)である。anycastアドレス選択ポリシーは、NAI1〜NAInの中から1または複数のNAIを選択するための手順または条件である。ホームエージェント21または外部エージェント31は、受信したパケットの送信先アドレスがanycastアドレス結合テーブルADCTに登録されているanycastアドレスと一致すれば、anycastアドレス選択ポリシーにしたがって1または複数のNAIを選択し、上記パケットを選択したNAIに対応する端末装置に転送する。
【００６２】
・ルーチングテーブル
ルーチングテーブルRTは、受信先アドレスに基づいて次の転送先(ルータなど)にパケットを転送するために必要な次ホップアドレスを求めるためのものであり、図7に示すように受信先アドレスと次ホップアドレスの対応関係を記憶している。
【００６３】
・結合キャッシュ
結合キャッシュCNCは一時的なルーチングテーブルとして使用され、図7のルーチングテーブルより優先的に参照される。パケットの転送を効率よく行うために必要な情報、すなわち、▲１▼送信元アドレス、▲２▼送信元ポート、▲３▼受信先アドレス、▲４▼受信先ポート、▲５▼カプセル化情報、▲６▼気付アドレス(care-of address)、▲７▼TOSを含んでいる。
【００６４】
・サービス制御フィルタ
サービス制御フィルタSFLは、指定された規制条件を満足するパケット(対象パケット)を特定するための情報、すなわち、▲１▼送信元アドレス、▲２▼送信元ポート、▲３▼受信先アドレス、▲４▼受信先ポートを格納する。ホームエージェントHA、外部エージェントFAはこのテーブルに設定されている条件にしたがって受信パケットに中から対象パケットを抽出し、所定のフィルタリング処理を行う。
【００６５】
（ｄ）AAAサーバ
・AAAFサーバ
外部エージェントFA31は、移動ノード11から登録要求メッセージを受信すると、その登録要求メッセージを解析し、AAAFサーバ32に対してその登録要求メッセージに格納されている情報を含むAMR(認証要求)メッセージを送出する。AAAFサーバ32は、その認証要求メッセージを受信すると、所定のホームエージェント21の割付を行う必要があるか否か、及び既に割付済みの旧ホームエージェントHAのサービス制御情報の削除が必要かどうかを判定を行い、必要とされるプロトコルメッセージをAAAHサーバ21に送出する。
【００６６】
図10はAAAFサーバ32の機能ブロック図であり、サービス制御部SVC1、サービス制御トランザクションSCT1を含んでいる。サービス制御部SVC1は、サービス制御トランザクションSCT1との通信を制御するサービス通信制御部SCC1及びHA割付テーブルALT1を有している。HA割付テーブルALT１には、AAAFサーバ32により割り付けられたホームエージェントHAのアドレスやHAネットワーク機器情報などが設定される。
サービス制御部SVC１は、受信したプロトコルメッセージにしたがって、サービス制御トランザクションSCT１及びHA割付テーブルALT１の設定、検索、更新、削除を行う。又、サービス制御部SVC１は、DIAMETERプロトコルにしたがって動作する機能を備え、メッセージ受信バッファ及びメッセージ送信バッファを用いた一般的なプロトコル処理機能も有する。
【００６７】
サービス制御トランザクションSCT１の制御テーブルは図１１に示すようにエージェント２１，３１のサービス制御トランザクションSCTと同様の構成を備えている。異なる点は、▲１▼制御ブロックに外部エージェントFAのNAIが設定されている点、▲２▼セッショントランザクションテーブルTC1にFAアドレス、AAAHサーバアドレス、HAアドレス、セッションタイマーが設定されている点、▲３▼サービスプロファイルテーブルTC2に複数のサービスタイプが設定されている点、である。
【００６８】
・AAAHサーバ
図1２はAAAHサーバ22の機能ブロック図であり、サービス制御部SVC２、サービス制御トランザクションSCT２を含んでいる。サービス制御部SVC2は、サービス制御トランザクションSCT２との通信を制御するサービス通信制御部SCC２及びサービス制御テーブル群SCTG２を有している。サービス制御テーブル群SCTG２は、HA割付テーブルALT２及びanycastアドレス管理テーブルADCT2を有している。サービス制御部SVC２は、受信したプロトコルメッセージに従い、サービス制御トランザクションSCT２及びサービス制御テーブル群SCTG2の設定、検索、更新、削除を行う。又、サービス制御部SVC2は、DIAMETERプロトコルにしたがって動作する機能を備え、メッセージ受信バッファ及びメッセージ送信バッファを用いた一般的なプロトコル処理機能も有する。Anycastアドレス管理テーブルADCTは、anycastアドレス単位の管理ブロック1〜ｎから構成されており、各管理ブロックには、▲１▼サービスタイプ(anycast)、▲２▼anycastアドレス選択ポリシー、▲３▼anycastアドレスを使用する1つ以上のNAI、▲４▼気付アドレス（care-of address）及び▲５▼状態(オンライン、オフライン、障害、輻輳等)が設定される
【００６９】
サービス制御トランザクションSTC2の制御テーブルは図１3に示すようにエージェント２１，３１のサービス制御トランザクションと同様の構成を備えている。異なる点は、▲１▼制御ブロックに移動ノードMNのNAIが設定されている点、▲２▼セッショントランザクションテーブルTD1にHAアドレス、AAAFサーバアドレス、セッションタイマーが設定されている点, ▲３▼サービスプロファイルテーブルTD2に複数のサービスタイプが設定されている点、である。
【００７０】
（ｅ）サービス制御データべース
サービス制御データべース(サービスプロファイルデータべース)23は、図14に示すように、加入者毎にユーザプロファイルが用意され、該プロファイルに各種情報を格納し、加入者にサービスを提供するために利用される。ユーザプロファイルは、加入者を識別するNAI(移動ノード識別子)をキーワードとして構成されるが、付加サービスとして、セキュリティサービス、ローミングサービス、QoSサービス、マルチキャストサービスを含む多様なサービスの提供が可能であるが、図ではDiff-Servサービス,ANYCASTサービス,パケットフィルタリングサービスを付加サービスの例として示している。
【００７１】
（ｆ）通信ノード
通信ノード41は、Mobile IP(MIP)機能をサポートするノードであり、MIPを利用してアクセスプロバイダ(外部ネットワーク)4を介してIPネットワーク5に接続されている。図15は通信ノード41の機能ブロック図であり、サービス制御部SVC３及びIPパケット制御部PKC３を有している。このIPパケット制御部PKC３は、一時的にパケット編集情報を保持する結合キャッシュCNC、ワークステーション等に装着されるLANカードなどである伝送機器TRD、アプリケーションレイヤALY、サービス制御部SVC３との通信を制御する通信制御部CCTを有している。サービス制御部SVC３は、MIPプロトコルにしたがって動作する機能を備えると共に、メッセージ受信バッファ及びメッセージ送信バッファを用いた一般的なプロトコル処理機能も有する。
【００７２】
（C）各種処理シーケンス
（ａ）初期位置登録シーケンス
図16は移動ノードMN 11から送出される登録要求メッセージに基づいて、AAAHサーバ22がホームエージェントHA 21を割り付ける場合の初期位置登録シーケンス説明図である。
▲１▼移動ノード11は、外部エージェント31から定期的に送出されるエージェント広告(Mobile IPメッセージ)を受信することにより、自分が外部エージェント31の通信エリア内に存在すると認識する。
▲２▼移動ノード11は、その移動ノードと契約しているプロバイダが管轄するホームエージェント21の通信可能範囲の外に移動した場合、その位置から通信可能範囲にあるプロバイダの外部エージェント31に対して登録要求メッセージを送出する。
【００７３】
▲３▼移動ノード11から登録要求メッセージを受信した外部エージェント31は、一意なセッションIDを取得すると共に、その登録要求メッセージから必要な情報(移動ノード11のホームアドレス、送信元リンクレイヤアドレス、UBP送信元ポート、ホームエージェントアドレス、登録要求の識別子フィールド及びライフタイム)を抽出する。そして、取得したセッションID及び登録要求メッセージから抽出した情報に基づいて図4に示すサービス制御トランザクションSCT等を作成する。又、AAAプロトコルにしたがって、登録要求メッセージをカプセル化したAMR(認証要求)メッセージをAAAFサーバ32に送出する。
【００７４】
▲４▼AAAFサーバ32は、外部エージェント31からAMRメッセージを受信すると、そのAMRメッセージから必要な情報を抽出し、図11に示すサービス制御トランザクションSCT１などを含むサービス制御情報を生成する。更に、受信したAMRメッセージに含まれるユーザNAIに対応するアドレスを求め、移動ノード11の認証について責任を持つAAAHサーバ22を決定する。そして、AAAFサーバ32は、上記AMRメッセージをAAAHサーバ22に送出する。
▲５▼AAAHサーバ22は、AMRメッセージを受信すると、AMRメッセージの認証手順に従って移動ノード11の認証を行う。そして、この認証が正常終了したときは、以降の処理を継続する。一方、この認証が失敗したときは、適切な理由コードを設定したAMA(認証応答)メッセージをAAAF32に返信する。
【００７５】
AAAHサーバ22は、AAAFサーバ32から受信した認証要求(AMR)メッセージに格納されている移動ノード11のNAIをキーとして図14に示すサービス制御データべース23を検索し、対応するユーザプロファイルを抽出する。又、認証要求(AMR)メッセージから抽出したセッションID及びAMRメッセージの送信元アドレス、更にサービス制御データべース23から取得したユーザプロファイルからサービス制御トランザクションSCT2(図13)を生成すると共に、HA割付手順に従ってHA21を特定する。
【００７６】
AAAHサーバ22は、上記ユーザプロファイルからホームエージェントHA21にとって必要な情報のみを取り出してHAR(HA登録要求)メッセージをホームエージェントHA 21に送出する。
ホームエージェントHA 21は、HARメッセージを受信すると、そのメッセージから必要な情報(セッションID、HAR送信元アドレス、気付アドレス、登録要求の識別子フィールド、ライフタイム、サービスプロファイル)を抽出し、それらに基づいて制御情報として図5に示すサービス制御トランザクションSCTなどを作成する。そして、図3のサービス制御フィルタSFLに受信先アドレス(ホームアドレス)を設定する。
【００７７】
▲６▼ホームエージェント21は、AAAHサーバ22へHA登録応答メッセージ(HAAメッセージ)を返信する。
▲７▼AAAHサーバ22はHAAメッセージを受信すると、外部エージェント31が必要とする情報のみを取り出し、認証応答(AMA)メッセージを作成し、図13に示すセッショントランザクションテーブルに登録されている認証要求アドレス(AAAFアドレス)へそのAMAメッセージを送出する。、
▲８▼AAAFサーバ32は、AMAメッセージを受信するとそのメッセージに設定されているセッションIDをキーとして図11に示すセッショントランザクションテーブルを検索または索引し、取得したFAアドレスへAMAメッセージを転送する。
【００７８】
▲９▼外部エージェントFA 31は、AAAFサーバ32から認証応答(AMA)メッセージを受信すると、該AMAメッセージにより配布されたホームアドレス、HAアドレス、サービスプロファイルを図4に示すようにサービス制御トランザクションSCTに設定する。また、ルータ制御部RTCのサービス制御フィルタSFLには、送信元アドレス(ホームアドレス)が設定される。そして、外部エージェントFA31は、サービス制御トランザクションSCTが示す移動ノードMNのリンクレイヤアドレスへ登録応答メッセージを送出する。
【００７９】
（ｂ）データパケット配信シーケンス
図17は、移動ノードMN11から通信ノード41にデータパケットを配信するシーケンス説明図である。ここでは、前述の手順により初期位置登録が完了した移動ノードMN 11がIPネットワークに接続される通信ノード41と通信する場合を想定する。また、付加サービスとしてDiff-Servが提供されるものとする。
▲１▼移動ノードMN 11は、通信ノードCN 41へデータパケットの送出を開始する。このパケットはまず移動ノード11を収容する外部エージェントFA 31により受信される。
【００８０】
▲２▼外部エージェントFA 31は、位置登録完了した移動ノードMN 11からパケットを受信すると、このパケットの発信元アドレスは外部エージェントFA 31のサービス制御フィルタSFLに登録されているので、そのパケットのIPヘッダの送信元アドレスを用いて図4に示す訪問者リストを検索する。そして、上記送信元アドレスと同じアドレスが設定されている訪問者リストにリンクするサービスプロファイルテーブルのサービスタイプ(Diff-Serv発信)を索引し、そこに設定されている関連情報を参照する。この実施例では移動ノードMN 11から送出される全てのパケットに対してTOS値として「Assured Forwardingクラス1(最優先)」を付与するポリシーが設定されているものとする。従って、外部エージェントFA 31は、受信パケットのIPヘッダのTOS値として上記の値を設定し、そのパケットをそのIPヘッダが示す送信先アドレスへ送出する。このとき、外部エージェントFA 31は、このパケットの編集情報に基づいて結合キャッシュCNCを作成する。
【００８１】
▲３▼通信ノードCN 41は、上記データパケットを受信すると、そのパケットに格納されている送信元アドレスへパケットを送出する。通信ノードCN 41は、例えば、移動ノードMN 11により指定された情報(例えば、Webページ)をそのパケットに格納して送出する。この時、通信ノードCN 41から送出されるパケットの送信先アドレスとしては移動ノードMN 11のアドレスが設定されている。ここで、移動ノードMN 11のアドレスは、ホームエージェントHA 21により管理されている。従って、通信ノードCN 41から送出されるパケットは、一旦ホームエージェントHA 21へ転送される。尚、この段階では、移動ノードMN 11には、対応するQoS(優先転送制御)は適用されていない。
【００８２】
▲４▼ホームエージェントHA ２１は、通信ノードCN 41からパケットを受信すると、そのパケットの受信先アドレスがホームエージェントHA 21のサービス制御フィルタSFLに登録されているので、そのパケットのヘッダに格納されている受信先アドレスを用いて図5に示すサービス制御トランザクションSCTを検索する。そして、その受信先アドレスが登録されているサービス制御トランザクションのサービスタイプ(Diff-Serv着信)を索引し、関連する設定情報を参照する。この実施例では、移動ノードMN 11宛ての全てのパケットに「Assured Forwardingクラス1」を提供するポリシーが設定されているものとする。この場合、ホームエージェントHA 21は、移動ノードMN 11宛ての全てのパケットのTOS値としてクラス1に対応する値を付与することになる。具体的には、ホームエージェントHA 21は、サービス制御トランザクションSCTから抽出した移動ノードMN 11の気付アドレス(care-of-address)を用いて通信ノードCN ４１から受信したパケットをカプセル化した後にそのカプセル化したパケットのヘッダに上記TOS値を付与し、そのパケットをその気付アドレスへ送出する。この場合、移動ノードＭＮ 11の気付アドレスは、その移動ノード11を直接的に収容している外部エージェントFA 31のアドレスである。尚、移動ノードMN 11を収容している外部エージェントFA 31のアドレスは、移動ノードMN 11の位置登録手順において、AMRメッセージ及びHARメッセージによりホームエージェントHA 21に通知されている。
この後、ホームエージェントHA 21は、このパケットのヘッダ編集情報を設定した結合キャッシュCNCを作成する。
【００８３】
▲５▼外部エージェントFA 31は、ホームエージェントHA 21によってカプセル化されたデータパケットを受信すると、それをデカプセル化する。
▲６▼続いて、そのデカプセル化したパケットのヘッダ情報から抽出した送信先アドレスを用いてサービス制御トランザクションSCTから対応するリンクレイヤアドレスを索引する。そして、デカプセル化したデータパケットを抽出したリンクレイヤアドレスへ転送する。
▲７▼ホームエージェントHA 21は、移動ノードMN 11宛てのデータパケットをカプセル化して外部エージェンFA31に転送しはじめると、転送ルートを最適化するために、結合更新メッセージを用いて移動ノードMN 11の気付アドレスを通信ノードCN 41に通知する。これにより、通信ノードCNは以後、ホームエージェントHA 21を介さずデータパケットを直接的に移動ノードMN 11の気付アドレスへカプセル化して送出できるようになる。
尚、結合更新メッセージを拡張することにより、現在適用されているTOS値も合わせて通信ノードCNに通知される。
【００８４】
▲８▼通信ノードCN 41は、結合更新メッセージを受信すると、そのメッセージにより通知された移動ノードMN 11のホームアドレス、気付アドレス、TOS値を格納する結合キャッシュCNCを作成する。そして、通信ノードCN 41は、パケットを送出する際にこの結合キャッシュCNCを検索し、そのパケットのヘッダに設定されている送信先アドレスと一致するホームアドレスが登録されている場合には、ホームエージェントHA 21と同様に、その結合キャッシュCNCに登録されている気付アドレスを用いてそのパケットをカプセル化すると共に、登録されているTOS値をそのパケットに付与する。この後、通信ノードCN 41は、そのパケットをその気付アドレスに送出する。
これにより、以降、通信ノードCN 41から移動ノードMN 11宛てのパケットは、移動ノードMN 11の気付アドレスにしたがって、その移動ノードMNを収容する外部エージェントFA 31へ直接的に転送されることになる。又、この時、通信ノードCN 41から移動ノードMN 11宛てのパケットにも上記ToS値が付与されているので、移動ノードMN １１から通信ノードCN 41へのパケットだけでなく、通信ノードCNから移動ノードMN 11へのパケットに対してもDiff-Servサービスが提供される。
【００８５】
▲９▼外部エージェントFA 31は、通信ノードCN 41によってカプセル化されたデータパケットを受信すると、それをデカプセル化する。
(10) また、外部エージェントFA 31は、そのデカプセル化したパケットのヘッダ情報から送信先アドレスを抽出し、サービス制御トランザクションSCTから対応するリンクレイヤアドレスを抽出する。そして、その抽出したリンクレイヤアドレスへデカプセル化したデータパケットを回送する。
【００８６】
（ｃ）移動ノードが同一AAAFサーバ内の外部エージェントの通信エリアから他の外部エージェントの通信エリアへ移動した場合のシーケンス
図18は移動ノードMN 11が、AAAFサーバ32内の外部エージェントFA 31の通信エリアから他の外部エージェントFA 31′の通信エリアへ移動した場合の位置登録手順の説明図である。以下では、旧FA 31は、移動ノードMN 11が移動する前にその移動ノードMN 11を収容していた外部エージェントを意味する。また新FA31′は、移動ノードMN 11が移動した後のその移動ノードMNを収容することとなった外部エージェントを意味する。
【００８７】
図19は、移動ノードMN 11が旧FA31の通信エリアから新FA31′の通信エリアへ移動したときのシーケンスである。尚、図20は外部エージェントFAにより使用されるNAI登録テーブル例であり、図21はエージェントのIPアドレスをNAIプレフィックスに変換するテーブル例である。
▲１▼移動ノードMN 11は、旧FA31の通信エリアから新FA31′の通信エリアに移動し、新FA 31′からモバイルIP広告を受け取ると、該新FA31′に対して登録要求メッセージを送出する。この時、登録要求メッセージの中には、旧FA 31のIPアドレス及び移動ノードMN 11のNAI(Nework Access Identifier)が含まれている。
【００８８】
▲２▼登録要求メッセージを受信した新FA 31′は、そのメッセージから必要な情報を抽出し、図４に示すサービス制御トランザクションSCTなどを生成する。又、新FA 31′は、旧FA ３１のIPアドレスを用いて図21に示すNAIプレフィックステーブルを参照することにより旧FA 31のNAIプレフィックスを求める。ここで、NAIプレフィックスは、例えば、ドメインを識別することができる。続いて、,新FA 31′は移動ノードMN 11から受信した登録要求メッセージをカプセル化し、それを認証要求(AMR)メッセージとしてAAAFサーバ32に送出する。その際、そのAMRメッセージの中には、旧FA 31のNAIプレフィックスと移動ノードMN 11のNAIが含まれる。
【００８９】
▲３▼AMRメッセージを受信したAAAFサーバ32は、移動ノードMN 11のNAIをインデックスとする仮のセッショントランザクションテーブルを作成する。そして、NAI登録テーブルを参照することにより、AAAHサーバ22のアドレスを求め、上記AMRメッセージをAAAHサーバ22に送出する。
▲４▼AMRメッセージを受信したAAAHサーバ22は、そのメッセージの中に含まれている移動ノードMN 11のNAIをインデックスとしてサービス制御トランザクションSCT2の制御ブロックを検索し、対応するサービスプロファイル(及びセッションID)が見つかった場合は、そのサービスプロファイル(及びセッションID)を含む登録要求(HAR)メッセージをホームエージェントHA 21に送出する。
【００９０】
▲５▼HARメッセージを受信したホームエージェントHA 21は、セッションIDをインデックスとして移動ノーMN ド11のセッショントランザクション(図5参照)を検索する。この時、この検索がヒットすれば、そこに新FA 31′のアドレスを気付アドレス(care-of-address)として登録する。そして、移動ノードMN 11の位置登録処理が終了すると、ホームエージェントHA 21は、新FA 31′が必要とする情報のみを編集し、登録応答(HAA)メッセージをAAAHサーバ22に対して送出する。この時、ホームエージェントHA 21は、新FA 31′が必要とする情報をHAAメッセージに格納してもよい。
【００９１】
▲６▼HAAメッセージを受信したAAAHサーバ22は、そのメッセージに含まれているセッションIDを用いてセッショントランザクションを検索し、その検索により抽出される新FA 31′のアドレスへ認証応答(AMA)メッセージを送出する。この時、AAAHサーバ22は、新FA 31′が必要とする情報をAMAメッセージに格納してもよい。
▲７▼AMAメッセージを受信したAAAFサーバ32は、そのメッセージから必要なサービスプロファイル情報を等を抽出し、サービストランザクション情報に基づいてそのAMAメッセージを新FA 31′に中継する。この時、新FAに送出されるAMAメッセージには、新FA 31′必要とする情報が格納されていてもよい。
【００９２】
▲８▼AMAメッセージを受信した新FA 31′は、そのメッセージから必要な情報を取得すると共に、結合更新（MBU:MIP Binding Update）メッセージを旧FA 31に送出する。
▲９▼MBUメッセージを受信した旧FA 31は、そのメッセージに格納されているセッションIDに対応するサービス制御情報を削除する。また、移動ノードMN 11宛てのメッセージを新FA 31′に転送するルーチングテーブルを設定すると共に、MBA(MBA:MIP Binding Acknowledge)メッセージを新FA 31′に送出する。
【００９３】
(10) MBAメッセージを受信した新FA 31′は、旧FA 31においてサービス制御情報が削除されたことを認識する。
(11) 新FA 31′は、DIAMTER要素部分をデカプセル化し、登録応答メッセージを移動ノードMN 11に送出する。
(12) 登録応答メッセージを受信した移動ノードMN 11は、登録要求メッセージの処理が終わったことを認識し、位置登録に係わる一連の処理を終了する。
【００９４】
（D）課金機能を配備した場合の第1のネットワーク構成
（ａ）構成
図22は本発明の第課金技術に関係する課金機能及びその配備先を説明するためのネットワーク構成図であり、図1〜図21で説明した構成、機能を踏襲するが、課金機能に重点を置いて示している。
移動端末MN 11はサービスプロバイダ１と契約しており、該サービスプロバイダがホームネットワークとなっている。図では、移動端末MN 11はホームネットワークからアクセスネットワークである外部ネットワーク2のエリアに移動し、外部エージェントFA31と通信可能になっている。外部ネットワーク４にはエッジルータERT42を介して通信ノード(サービス提供サーバ)CN 41が接続されている。このサービス提供サーバCN 41は、移動端末MN 11より要求された情報(例えば、Webページ)を提供するサービス提供機能SVSFと課金条件を生成する課金条件生成機能BCGFと後述する課金装置制御機能BECF等を有している。サービス提供サーバCN 41にはサーバ課金プロファイルSBP（Server Billing Profile）を格納する格納部43、課金条件管理テーブル44が設けられている。
【００９５】
ホームネットワーク1には、ホームエージェントHA 21、AAAHサーバ（以後、単にAAAサーバあるいは認証サーバという）22、サービス制御データべースSPDB 23、課金情報データべースBIDB 24が設けられている。サービス制御データべースSPDB２３には、契約端末毎のサービス制御情報たとえば品質制御情報QoSなどのサービスが契約時に登録されている。課金情報データべースBIDB 24にはユーザ課金プロファイルUBP(User Billing Profile)が登録されている。ホームネットワーク1及び他のサービスプロバイダによりそれぞれ管理される外部ネットワーク２〜4はIP中継網5を介して互いに接続されている。
【００９６】
（b）課金機能
課金機能としては、▲１▼サービス要求機能（SRQF :Service Request Function）、▲２▼課金情報サーバ機能（BISF :Billing Information Server Function）、▲３▼課金条件生成機能（BCGF :Billing Condition Generation Function）、▲４▼課金装置制御機能（BECF :Billing Engine Control Function）、▲５▼ハンドオーバ対応機能（HOF :Handoff Function）、がある。
▲１▼サービス要求機能（SRQF :Service Request Function）
このサービス要求機能SRQFは、本発明における課金対象サービスを起動するための契機を与える機能である。サービス要求機能SRQFに従って、ユーザ端末上のアプリケーションは、サービス実行に必要とするネットワーク資源等の条件、サービス提供サーバ等のサービスに関する情報をネットワークへの端末位置登録手順に含め、接続先のサーバはこれを理解し、サービス開始に必要な条件（料金条件等）を作成する。
【００９７】
加えて、サービス要求機能SRQFに従って、サービスを提供するサーバは発行した課金条件識別子を、サービス契約の鍵情報として保持し、周期的なサービス継続確認動作、サービス変更および中止動作、ハンドオーバ時のアプリケーションセッション保持の認証情報として使用する。
サービス要求機能SRQFの実装位置は、移動端末MN 11およびサービス提供サーバCN 41である。また、移動端末のアプリケーションが要求するサービスの提供に必要な課金条件等のメッセージをサーバCNと移動端末MN間で送受する機能を実装する。具体的には、サービス実行に必要な「サービス要求」メッセージや「課金条件」等の情報をMobile IP等の位置登録メッセージに含めて相互に送受する。
▲２▼課金情報サーバ機能（BISF:Billing Information Server Function）
【００９８】
課金情報サーバ機能（BISF）はAAAサーバ22に実装される。この課金情報サーバ機能（BISF）により、AAAサーバ22は認証要求されたユーザ端末に関する課金プロファイル（サービスの許容条件）を課金情報データべース（BIDB）24から抽出する。すなわち、課金情報データべース（BIDB）24に当該ユーザ端末に関する課金条件 (ユーザ課金プロファイルUBP)が設定されていれば、AAAサーバ２２は認証要求を契機に該ユーザ端末の課金プロファイルUBPを抽出する。本機能の実装位置は、AAAサーバ22の内部、あるいはAAAサーバ２２と連携可能な位置である。
【００９９】
▲３▼課金条件生成機能（BCGF:Billing Condition Generation Function）
課金条件生成機能（BCGF）は、ユーザ側とサービス提供者側双方が持つユーザ課金プロファイルUBPとサーバ課金プロファイルSBPを照合したうえで、提供可能な課金条件を合成出力する機能である。本機能は、各移動端末がサービス起動毎に、また接続先サービス業者毎に課金条件を決定するための主要機能である。本機能の実装位置は、多くの場合はサービス提供者のサーバCN 41と連携して配備される。ただし、需要の多いサービスに関する提供業者については、ネットワーク内に配備して、本機能をネットワーク運用者が代行運用する形態も考えられる。
【０１００】
▲４▼課金装置制御機能（BECF:Billing Engine Control Function）
課金装置制御機能（BECF）は、課金条件生成機能に基づいてサービス提供サーバCN 41が決定した課金条件を、課金装置(課金エンジン)に設定（通知）し、これにより、課金装置が当該課金処理を初期化、実行する機能である。本機能の実現手段（課金装置制御機能部）は、ネットワーク内に配備される課金装置と連携可能な位置(例えば外部エージェントFA及びサービス提供サーバＣＮ内)に配備される。ただし、課金装置制御機能（BECF）は、端末毎に定められたポリシーに従って課金対象パケットの情報を収集する課金装置自体には関連しない。又、課金装置BENはネットワーク内部の課金が必要な位置、例えば外部エージェントFA内に配備される。
【０１０１】
▲５▼ハンドオーバ対応機能（HOF:Handoff Function）
ハンドオーバ対応機能（HOF）は、移動端末MNのハンドオーバ前後で課金データを課金装置間で送受すると共に、移動先ネットワークの課金装置BENへ課金条件を送達する機能である。ハンドオーバ対応機能HOFを実現する手段（ハンドオーバ対応機能部）は、移動端末MNのハンドオーバ制御を実行する装置(例えば外部エージェントFA)に配備され、課金装置と連携する。
【０１０２】
（ｃ）基本シーケンス
(1)移動端末NM 11は、発行する位置登録要求メッセージにサービス要求情報(サーバ名、サービス条件)を含める。
(2)位置登録要求を転送する装置(外部エージェントFA 31、ホームエージェントHA 21)は,位置登録要求メッセージ内に含まれるサービス要求情報を検索し、AAAサーバ22に通知する。AAAサーバ２２は当該ユーザの課金プロファイルUBPを課金情報データべースBIDB 24から抽出し、ホームエージェントHA 21、エッジルータERT 42を介してサービス提供サーバCN 41へ転送する。
【０１０３】
(3) サービス提供サーバCN 41は、ユーザ課金プロファイルUBPとサーバ課金プロファイルSBPを照合して課金条件を決定する。
(4)決定された課金条件は、位置登録応答処理によりネットワーク内の課金装置BENに設定され、課金処理が実行される。
以上要約すれば、ユーザとサービス提供者(サーバ）間で、サービス種別およびユーザ単位に、あらかじめ規定された条件（課金プロファイル）に基づき、課金条件合成機能により、動的にサービス料金条件を決定し、この課金条件を解釈可能なネットワーク内の課金装置BENに設定し、以後の当該ユーザに対して提供されるパケットに関して課金装置において課金を可能とする。
【０１０４】
(d)ユーザ課金プロファイル／サーバ課金プロファイル
端末単位に、かつサービス単位に課金を行うためには、課金情報を記述したファイルが必要である。本発明では多数の選択肢を設けて柔軟な課金機能を実現するために、ユーザ端末側とサービス提供側にユーザ課金プロファイルUBP、サーバ課金プロファイルSBPをそれぞれ用意し、照合することにより課金条件を決定する。
【０１０５】
図2３はQoSサービスについてのユーザ課金プロファイルUBP、サーバ課金プロファイルSBPの一例であり、他のサービスについても規定されるが説明は省略する。ユーザ課金プロファイルUBPには、ユーザ端末毎に該ユーザが許容するサービスに関する条件（パラメータ）が記述される。例えば、(a)に示すように所定のユーザに対して、▲１▼QoSサービスの伝送速度として、64Kbps、512Kbpsが、▲２▼サービス時間帯として8:00〜17:00が、▲３▼許容する課金方式として、パケット従量、AAA認証セッション単位、時間単位が、▲４▼許容情報量として月額2000円が、それぞれ設定されている。このユーザ課金プロファイルUBPはサービスプロファイルとあわせて使用され、端末単位に契約時点で内容を決定し（契約後もカスタマイズ可能）、サービスを受ける際にサービス提供業者CNへこれを提示する。
【０１０６】
サーバ課金プロファイルSBPには、サービス提供サーバ41がサービスを提供するに当たっての課金条件が記述される。例えば、(b)に示すようにQoSサービスについて、可能伝送速度として、▲１▼64Kbps、▲２▼128Kbps、▲３▼256Kbps、▲４▼512Kbpsが設定され、それぞれについて、提供可能時間帯、課金方式、単位料金が設定されている。
【０１０７】
本発明では、個々の端末が受けるサービスについて、品質条件とこれに関連させた課金条件をサービス実行前に動的に決定するために、サービス提供サーバCN 41が両者の課金プロファイルUBP ,SBPを一定の規則に基づき照合して課金条件を決定し、この課金条件を課金装置に通知すると共に端末単位のサービスを実行し、課金装置は該課金条件に基づいて課金を行う。図2３の例では、伝送速度512Kbpsがユーザの許容条件を満足するから、サービスID=0004が課金条件として決定される。
以上、要約すると、ユーザとサービス提供者間のサービス料金交渉を行うために、ユーザ側には、支払いの許容条件を記述したユーザ課金プロファイルUBPを、またサービス提供者側には料金と関連付けられた提供可能なサービス情報を記述したサーバ課金プロファイルSBPをそれぞれネットワーク上に保持し、移動端末MNがサービス実行要求メッセージを送出した時点で双方の条件を合成することで、移動端末とサービス提供業者間の料金条件を決定可能とする。
【０１０８】
（ｅ）課金プロファイルサーバ機能
課金プロファイルサーバ機能は、端末単位の課金プロファイルUBPを格納する課金情報データべースBIDBおよび端末認証処理を行う認証（AAA）サーバ22との連携機能である。
端末認証を完了したAAAサーバ22は、当該端末に関する課金情報を課金情報データべースBIDB 24に問い合わせる。このときの問い合わせキーとして、例えば端末のNAI (Network Access Identifier)を使用する。課金情報データべースＲ２DB24から、当該ユーザに関するユーザ課金プロファイルUBPを受領したAAAサーバ22は、課金条件を決定する外部装置(サービス提供サーバCN 41)に伝達するために、当該ユーザ課金プロファイルUBPを、端末認証において生成された認証鍵等の情報と合わせて、外部装置へ送信可能な形式に変換する。
【０１０９】
図２４はAAAサーバが管理する端末認証データとユーザ課金プロファイルUBPの関連説明図、図２５はAAAサーバにおける端末認証処理と課金プロファイル抽出処理フローである。
AAAサーバ22はサービス接続要求を含む認証要求を受信すると(ステップ100)、まず、端末認証手順を実行する(ステップ101)。ついで、端末認証処理が完了すれば、AAAサーバ22は端末(加入者)毎に管理されている端末認証データADT1〜ADTnの拡張部を参照し(ステップ102)、着目している端末のユーザ課金プロファイルUBP1〜UBPnが設定されているかチェックする(ステップ10３)。ユーザ課金プロファイルが設定されていれば、AAAサーバ22は、課金情報データべースBIDB 24より位置登録要求を出した端末のユーザ課金プロファイルを読み出し、必要なサービスカテゴリーのエントリだけを抽出してこれを認証結果に付与する(ステップ104)。ついで、認証結果の一部としてユーザ課金プロファイルを課金開始要求メッセージ(Mobile IPべースの実装では端末の位置登録メッセージ)に含め(ステップ105)、ホームエージェントHA 21に転送する(ステップ106)。以後、ホームエージェントHA 21は課金開始要求メッセージを端末が接続要求するサービス提供サーバCN 41にエッジルータERT 42を介して転送する。なお、ステップ103において、ユーザ課金プロファイルUBPが設定されていなければ、ユーザ課金プロファイルを認証結果に付加せず位置登録メッセージを外部装置に転送する。
【０１１０】
以上要約すれば、AAAサーバ２２は、受信した端末認証要求メッセージ内にサービス要求情報が含まれていれば、これを検出して課金情報データべースBIDB ２４に対し、当該ユーザに関する課金プロファイルUBPの検索を要求し、また、検索結果として当該ユーザに関する課金プロファイルを受領した場合、これを課金条件を決定する装置(サービス提供サーバCN)に転送する。
【０１１１】
（ｆ）課金条件合成機能
サービス提供サーバCN 41は課金開始要求メッセージ、すなわち、位置登録メッセージを受信すれば、自身が保有するサーバ課金プロファイルSBPとメッセージに含まれるユーザ課金プロファイルUBPとを照合して提供可能なサービス条件(課金条件)を生成して課金装置BENに通知する。
【０１１２】
図25は課金条件生成処理フローである。
サービス提供サーバCN 41は、移動端末が送信した位置登録要求に基づいた認証結果とユーザ課金プロファイルを含む結合更新メッセージを受信する(ステップ151)。ついで、受信メッセージから、メッセージ内容の構成要素を検出し(ステップ152)、構成要素として、結合情報（端末の位置情報）を抽出して、端末に対する最適経路を設定する(ステップ153)。
次に、サーバCNは、受信メッセージに当該端末のユーザ課金プロファイルUBPが含まれているかチェックし(ステップ154)、含まれていなければ課金条件生成処理をすることなく始めに戻り次のメッセージの受信を待つ。
【０１１３】
一方、メッセージにユーザ課金プロファイルUBP(図23(a)参照)が含まれている場合には、サーバ課金プロファイルSBP(図23(b)参照)を読み出し(ステップ155)、両方の課金プロファイルを照合する(ステップ156)。このとき、条件比較に使用される項目を１つずつ比較する。全てのサービスIDのサーバ課金プロファイルSBPがユーザ課金プロファイルUBPと条件が合致しないか判断し(ステップ157)、全てのサービスIDのサーバ課金プロファイルSBPがユーザ課金プロファイルUBPと条件が合致しなければ、サービス提供サーバCN 41はサービス提供が不可能と判断して、エラー情報と課金条件のデフォルト値を含む応答メッセージ（結合応答）を要求元（ホームエージェントHA）に対して返答する(ステップ158)。これにより、全てのサービスIDのサーバ課金プロファイルSBPがユーザ課金プロファイルUBPと条件が合致せず、サービス提供が不可能な場合であっても、エラー発生を通知できき、しかも、デフォルト値をユーザに対して提示することができ、ユーザの利便性を向上することができる。
【０１１４】
一方、少なくとも1つのサービスIDのサーバ課金プロファイルSBPがユーザ課金プロファイルUBPと条件が合致すれば、このサービスIDのサーバ課金プロファイルをサービス提供条件(課金条件)として決定し、応答メッセージ（結合応答）に含め(ステップ159)、課金条件生成処理を終了する。
【０１１５】
図27は図26のステップ155〜159の詳細処理フローである。
ユーザ課金プロファイルUBPが入力されると、サーバCNはサーバ課金プロファイルSBPのサービス種別IDを１に初期化し(ｎ＝１、ステップ161)、ついで、比較対照のユーザ課金プロファイルの条件IDを１に初期化する(ｍ＝１、ステップ162)。ついで、ユーザ課金プロファイルUBPの第m条件項目の内容と第nサーバ課金プロファイルSBPの第m条件項目の内容を比較する(ステップ163)。当該第m条件において合致する内容があるかチェックし(ステップ164)、合致する内容があれば、全ての条件IDについて比較が完了したかチェックし(ステップ165)、「NO」であればmを歩進して(ステップ166)、ステップ163以降の処理を繰り返す。
【０１１６】
ステップ165において、全ての条件IDについて比較が完了していれば第ｎサーバ課金プロファイルをユーザへのサービス提供条件(課金条件)の推奨候補として記録する(ステップ1６７)。
ついで、サーバ課金プロファイルSBP内に、同一サービスカテゴリーのエントリが他に存在するかチェックする(ステップ168)。存在すれば、ｎを歩進し(ステップ169)、ステップ162以降の処理を繰り返す。一方、ステップ168において、全てのサービス種別IDについて比較処理を終了すれば、記録してある課金条件をユーザへの推奨条件として出力し(ステップ170)、課金条件生成処理を終了する。
【０１１７】
又、ステップ164において、全サービス種別IDのサーバ課金プロファイルについて、全ての項目においてユーザ課金プロファイルと条件が合致するものが無ければ、サーバ側で独自に事前設定してある推奨条件を提示するか判断し(ステップ171)、提示する設定になっていればサーバ側の推奨条件を抽出して出力する(ステップ172)。しかし、提示する設定になっていなければ、当該ユーザの提示条件ではサービス提供は不可能であるとするメッセージを生成して(ステップ173)、処理を終了する。
【０１１８】
（ｇ）高頻度サービスの課金条件のキャッシュ機能
ユーザ課金プロファイルUBPとサーバ課金プロファイルSBPの照合比較による課金条件生成手順は、端末毎、サービス毎に実施されるのが基本であるが、有料サービスとして利用頻度が極めて高くまた、両者の課金プロファイルの照合すべき点が少なく、課金条件についてサービスを要求する端末毎の差異が出ない場合がある。言いかえれば、多くの端末に対する課金条件生成の結果、同一の課金条件が生成される場合がある。
【０１１９】
一方、サービスが比較的大規模な業者によって提供されるため、サービス提供者側のサーバにおける課金条件生成の負荷を軽減して、サービス起動の応答時間を短縮することが望まれている。
そこで、課金条件についてサービスを要求する端末毎の差異が出ない場合、あらかじめ当該サービスに関する課金条件(サービス提供条件)を生成して、課金情報データべースBIDB24内に保持（キャッシュ）しておく。すなわち、サービス提供サーバ及びサービスタイプに対応させて課金条件及び課金条件を特定するサービスIDを登録しておく。かかる状態において、ユーザから所定サーバに対してサービス要求があった場合、課金情報データべースBIDB24内で保持（キャッシュ）している課金条件、すなわち、サービスIDを提示することで、サービス提供サーバCN 41における課金条件生成の負荷を軽減して、サービス起動の応答時間を短縮する。
【０１２０】
図２８はキャッシュされた課金条件を適用する場合のネットワーク全体のシーケンス説明図である。
▲１▼ユーザ又はアプリケーションAPLからのサービス提供要求を移動端末MN 11内のMIP制御部が検出する。
▲２▼移動端末(MN)11はサービス要求を含む位置登録要求メッセージを外部エージェントFA 31に送出する。
▲３▼外部エージェントFA 31は登録要求メッセージを受信すれば、AAAサーバ22に対してサービス要求を含む認証要求メッセージを送出する。
▲４▼AAAサーバ22は認証要求メッセージより認証要求及びサーバ情報(サービス要求先のサーバ名、サービスタイプ)を抽出する。ついで、抽出したサーバ情報とAAAサーバ22が保持しているサーバ情報(サーバ名、サービスタイプ)とを比較し、一致した場合、サービス要求を削除する。
【０１２１】
▲５▼ついで、AAAサーバ22はホームエージェントHA 21に対してサービス要求が削除された位置登録要求メッセージを送出する。
▲６▼ホームエージェントHA 21は位置登録処理後、AAAサーバ22に対して登録応答メッセージを送出する。
▲７▼ついで、AAAサーバ22はサービス提供サーバCN 41に対して結合更新メッセージを送出する。なお、AAAサーバ22はこの結合更新メッセージに自分が保持しているサーバ情報から抽出したサービス要求(課金条件を特定するサービスID)含める。
【０１２２】
▲８▼サービス提供サーバCN 41は結合情報を処理すると共にサービスIDを抽出し、該サービスIDより課金条件を識別し、課金条件識別子を生成する。
▲９▼ついで、サービス提供サーバCN 41は課金条件識別子を結合応答に付加してAAAサーバ22に送出する。
(10) AAAサーバ22は結合応答を受信すれば、外部エージェントFA 31に対し、保持しているサーバ情報から抽出した課金条件を付加した登録応答メッセージを送出する。
(11) 外部エージェントFA 31の課金装置制御機能部BECFは登録応答メッセージに付加された課金条件を抽出し、該課金条件を課金装置BENに設定する。
(12)しかる後、外部エージェントFA 31は移動端末MN 11に対して登録応答メッセージを送出し、MIP制御部は交渉結果をアプリケーションに通知する。
(13) 以後、移動端末MN 11は課金条件識別子をサービス提供サーバCN 41に送出してサービス条件受諾を通知すれば、該サーバはサービス対象パケットを移動端末宛に送出することになる。
【０１２３】
図29はキャッシュされた課金条件を適用する場合のAAAサーバ22における処理フローである。
AAAサーバ22はパケット待ちの状態において(ステップ200)、パケットを受信すると(ステップ201)、該パケットが認証要求メッセージを含んでいるかチェックし(ステップ202)、含んでいれば認証処理を実行すると共に(ステップ203)、前記パケットにサービス要求が含まれているかチェックする(ステップ204)。
【０１２４】
サービス要求が含まれていれば、該サービス要求に含まれるサーバ情報(サーバ名、サービスタイプ)が、保持しているサーバ情報と一致するかチェックし(ステップ205)、一致すれば、認証要求中のサービス要求を削除し(ステップ206)、ホームエージェントHA 21に位置登録要求メッセージを送出する(ステップ207)。しかし、ステップ205において、サーバ情報が一致しなければ、サービス要求に応じたユーザ課金プロファイルUBPを課金情報データべースBIDB 24より抽出し(ステップ208)、該ユーザ課金プロファイルUBPを認証結果に付加してホームエージェントHA 21に登録要求メッセージを送出する(ステップ207)。
【０１２５】
一方、ステップ204において、パケットがサービス要求を含んでいなければ、ホームエージェントHA 21に位置登録要求メッセージを送出する(ステップ209)。又、ステップ202において、パケットに認証要求が含まれていなければ、結合応答が含まれているかチェックし(ステップ210)、結合応答が含まれていれば外部エージェントFA 31に登録応答メッセージを送出する(ステップ211)。しかし、結合応答が含まれていなければ、登録応答が含まれているかチェックし(ステップ212)、 登録応答が含まれていればサーバCNに結合更新メッセージを送出し(ステップ213)、登録応答が含まれていなければ、その他の処理を行って次のパケットの受信待ちになる。
【０１２６】
（ｈ）課金条件識別子の付与
課金条件生成機能により生成された課金条件データは、ユーザ、サービス提供者双方の条件を満足するものであるが、最終的に実行可否は料金支払者（端末ユーザ）の判断が必要である。このため、サービス提供者側では、一旦生成された課金条件データに対して、実行承認時を始めとして当該サービスとユーザ情報を関連付けるために一意の課金条件識別子を生成する。すなわち、サービス提供者は、課金条件生成後、この課金条件データを一意に識別する情報(課金条件識別子)を生成し（図28の▲８▼)、課金条件識別子を課金条件データとともにサービス要求元への応答メッセージに含める。
【０１２７】
生成された課金条件識別子は、サービス提供サーバCN 41が管理している課金条件管理テーブル44(図22参照)に格納する。この格納時点では、当該課金条件が、ユーザに承認されたものではないため、「仮登録」の状態を併せて記録する。図３０は課金条件管理テーブル44が保持する情報の説明図であり、▲１▼サービスを要求している端末の識別情報（IPアドレス、NAI:Network Access Identifierなど）、▲２▼課金条件、▲３▼課金条件の識別子（課金条件識別子）、▲４▼課金条件の許諾状況（仮登録か、ユーザ承認済みかを示す登録状態）を含む。
【０１２８】
図３１は課金条件識別子付与処理フローである。
サービス提供サーバCN41は課金条件を特定するサービスIDを受領すると課金条件を識別すると共に、識別子生成機能部に課金条件識別子の生成を要求し(ステップ251)、識別子生成機能部より課金条件識別子を取得すれば、課金条件管理テーブル44に課金条件、課金条件識別子等を仮登録する(ステップ252)。ついで、当該課金条件の仮登録タイマーを起動する(ステップ253)。又、ユーザ識別データ、課金条件、識別子を含む結合応答メッセージを作成する(ステップ254)。しかる後、メッセージ内に矛盾点があるかチェックし(ステップ255)、矛盾点がなければメッセージを整形して送出し(ステップ256)、矛盾点があれば課金条件のデフォルト値(エラー情報を含む)をメッセージに含めて送出する(ステップ257)。これにより、矛盾点があれば、エラー発生を通知できき、しかも、デフォルト値をユーザに対して提示することができ利便性を向上することができる。
【０１２９】
（ｉ）課金装置制御機能
課金情報を収集する課金装置BENは、外部エージェントFAなど適当な課金情報設定点に設けられる。この課金装置BENは課金情報収集にあたって課金対象パケットの課金条件を知らなくてはならない。そこで、課金条件データは予め、課金装置に転送されて設定され、これにより課金装置は課金対象となるパケットを観測し、課金処理を実行する準備が完了する。
【０１３０】
課金装置制御機能部BECF（サービス提供サーバCN及び外部エージェントFAに設けられる）は、課金条件を課金装置BENに転送、設定するために、全体的に以下の処理を行う。すなわち、
(1) ユーザ単位の課金条件管理テーブル44に当該端末の課金条件を登録する、
(2) 課金条件を課金装置が解釈可能な形式に変換する、
(3) 課金装置へ課金条件を転送、設定する。
(4) 課金条件の有効期限を設定し、タイマーで経過時間を監視し、有効期限経過前にパケットが到着すれば、当該課金条件は有効として扱う。有効期限経過しても、パケットが到着しない場合には、当該課金条件を無効として課金条件管理テーブル44からエントリを削除する。すなわち、一旦有効になり、課金動作を始めた課金条件は、所定期間連続してパケットが到来しないことにより課金条件管理テーブル44から削除される。
【０１３１】
図３２は課金装置制御機能部BECFにおける課金条件の仮設定処理フロー、図３３は実行中サービスに関する課金条件の更新処理フローである。
外部エージェントFAの課金装置制御機能部BECFは受信メッセージ内に課金条件識別子が含まれているかチェックし(ステップ301)、含まれていなければ課金対象外のため無視し(ステップ302)、次のメッセージの受信を待つ。
【０１３２】
課金条件識別子が含まれていれば、登録応答であるかチェックする(ステップ303)。登録応答メッセージを受信した場合には、本メッセージにサービス提供サーバCNが課金条件と課金条件識別子を付与して送信していると判断される。
登録応答であれば、課金条件が含まれているか調べ（ステップ304)、含まれていなければ課金対象外のため無視し(ステップ302)、次のメッセージの受信を待つ。
課金条件が含まれていれば、課金条件を課金装置BENに設定する(ステップ305)。ついで、課金条件設定が正常終了したか監視し(ステップ30６)、課金装置BENへの設定に失敗した場合には、課金不可能なためエラーメッセージを作成して登録応答メッセージに含ませて移動端末MNに送出する(ステップ307)。
【０１３３】
一方、課金装置BENへの設定が正常終了すれば、サービス提供サーバCN内の課金装置制御機能部BECFは当該課金条件、課金条件識別子などを課金条件管理テーブル44に追加する(ステップ308)。このとき、登録状態は「仮登録」として設定される。
課金条件管理テーブル44への登録が正常終了した時点で、課金装置制御機能部BECFは当該エントリについて、有効期限を示すタイマーを起動し、減算を開始する。(ステップ309)。このタイマーの目的は、仮設定された当該課金条件に有効期限を設ける為であり、一定時間、端末ユーザからのサービス料金条件の承諾を待つ。このタイマ期間内に端末ユーザからの課金条件への承諾情報が来ない場合、当該課金条件のエントリを自律的に削除する。
【０１３４】
ついで、外部エージェントFAの課金装置制御機能部BECF課金情報識別子を登録応答メッセージに含ませて移動端末MNに送出する(ステップ310)。
ステップ303において、位置登録応答でなければ、位置登録要求であって、同時に課金識別子を含むか調べ(ステップ321)、登録要求でなく、あるいは、課金識別子を含んでいなければ、課金非関連メッセージであるから始めに戻り(ステップ322)、次のメッセージの受信を待つ。
一方、登録要求であって、同時に課金識別子を含めば、課金識別子をキーワードにして当該課金条件を課金条件管理テーブル44より読み出す(ステップ323)。ついで、課金条件の登録状態が仮登録であるか承認済みであるかチェックし(ステップ324)、仮登録であれば登録状態を承認済みに更新し(ステップ325)、承認済みの場合には、実行中サービスの本登録を継続する(ステップ326)。以後、課金条件管理テーブルの有効期限を更新し(ステップ327)、応答メッセージを生成して、移動端末MNに送出する(ステップ328)。
【０１３５】
以上要約すれば、課金条件を課金装置BENに設定し、課金装置は当該ユーザの要求サービス内容に合致するパケットの到着を監視し、到着した場合には課金を開始する。また、課金装置BENへの設定後一定時間経過しても、パケットが観測されない場合は課金条件が破棄されたものとして設定を解除する。
【０１３６】
（ｊ）課金条件の承認
サービス提供サーバＣＮから課金条件がユーザ端末に提示されるが、複数の課金条件が提示される場合がある。この場合、ユーザは提示された課金条件のいずれかを選択し、これをサービス提供サーバCNに通知する必要がある。また、１つの課金条件が提示される場合であっても、ユーザは提示された課金条件の承諾をサービス提供サーバCNに通知する必要がある。ただし、ユーザとサービス提供者間の信頼関係が保証されていない為、ユーザは課金条件の承諾情報を、課金そのものを実行するネットワーク内の課金装置に直接通知する必要がある。
【０１３７】
図34は課金条件承認のシーケンス説明図である。
移動端末MNは、位置登録応答メッセージにより、サービス提供サーバCNで生成された1以上の課金条件の情報（料金等）を通知される。登録応答メッセージに含まれる情報は (a) 1以上の課金条件、(b) 課金条件識別子、の二点である。移動端末MNのアプリケーションAPLはユーザに課金条件の選択肢を提示し、これによりユーザは１つの課金条件に同意、あるいは、所定の課金条件を選択する。
【０１３８】
▲２▼しかる後、MIP制御部は任意のタイミングで周期登録メッセージを発行し、このメッセージ中に先に受信した課金条件識別子を含めて送信する。なお、ネットワークで該周期登録メッセージを解釈する必要があるのは、外部エージェントFA内の課金装置制御機能部BECFである。
外部エージェントFA内の課金装置制御機能部BECFは周期登録メッセージに含まれる課金条件識別子を課金装置BENに入力する。課金装置BENは、課金条件識別子が示す課金条件を有効として内部的に設定し、課金可能状態になる。
【０１３９】
▲３▼また、当該周期登録メッセージはサービス提供サーバCNに到達すれば、該サーバCNはネットワークにおいて課金条件が承諾され、課金準備が完了したと認識する。
▲４▼以後、すなわち、メッセージ受領を契機に、サービス提供サーバCNはサービスを開始する。
課金条件承諾の他の通知方法として、上述のメッセージがサービス提供サーバCNに到達するまでの伝播遅延を考慮し、あらかじめ、アプリケーションレベル（例：HTTPS）でサーバCNにサービス開始の旨を通知しておき、サーバ側でサービス開始に必要な準備動作を完了しておくことも可能である。
【０１４０】
図３５は課金装置制御機能部BECFの課金条件承認処理フローである。
外部メッセージを受信すると、周期登録要求メッセージであると同時に課金条件識別子が含まれているかチェックし(ステップ351)、「NO」であれば課金対象外のメッセージであるため無視し(ステップ352)、次のメッセージの受信を待つ。
ステップ351において、周期登録要求メッセージであると同時に課金条件識別子が含まれていれば、課金条件識別子をキーワードにして課金条件管理テーブル44における該当する課金条件を仮登録から本登録(有効)に変更する(ステップ353)。ついで、課金条件設定が正常に終了したかチェックし(ステップ354)、設定に失敗した場合には、課金不可能なためエラーメッセージを作成し(ステップ355)、課金条件管理テーブル44と課金装置BENから当該課金条件を削除し(ステップ356)、エラーメッセージを登録応答メッセージに含ませて移動端末MNに送出する(ステップ357)。
【０１４１】
一方、課金条件の設定が正常終了すれば、課金条件承認待ちタイマーを起動し、減算を開始する。(ステップ358)。ついで、課金条件識別子を登録応答メッセージに含ませ(ステップ359)、移動端末MNに送出する。
以上より、ユーザ端末がサービス提供者から発行された課金条件識別子を登録メッセージに含めて送出することによりネットワークに対して該ユーザがこの課金条件を承諾したことを通知することができる。
【０１４２】
（ｋ）サービス継続確認機能
一旦サービスを開始したあと、定期的に当該ユーザのサービス継続の意思を確認する必要がある。この手段としては、移動端末MNの位置登録手順のひとつである「周期登録」手順を利用する。具体的には、以下の手順を踏む。すなわち、
(1)移動端末MNは周期登録手順を開始する際に、周期登録メッセージに接続先サーバCNのアドレスと課金条件識別子を付加して送出する。
(2)登録要求メッセージを受信した装置（例えば、移動端末を収容し、課金装置を制御する外部エージェントFA）は、上記の付加情報を検出する。
(3)前記付加情報の検出を受けて、課金装置制御機能部BECF、当該移動端末MNがサービス提供の継続を希望しているものと判断し、課金条件有効期限を更新する。
(4) もし、ユーザ端末MNの不具合等が発生した場合には、周期登録が発生しないため、当該ユーザ端末に関する課金動作が中断する。このとき、課金対象のパケット送信は、最終の周期登録の確認時点までとなる。
【０１４３】
図３６は、移動端末のＡＡＡ（位置登録認証）セッションが残っていない場合における課金継続シーケンス説明図である。
▲１▼移動端末(MN)は課金条件識別子を含む登録要求(周期登録メッセージ)を送出する。
▲２▼登録要求を受信した装置(移動端末を収容し課金装置を制御するルータであり、例えば、外部エージェントFA)は、受信メッセージより課金条件識別子を検出する。
▲３▼検出された課金条件識別子を外部エージェントFAの課金装置制御機能部BEFCが確認し、当該ユーザがサービスの継続を希望しているものとして課金条件の有効期限を延長する。
【０１４４】
▲４▼外部エージェントFA 31はAAAサーバ22に対して認証要求を送出する。
▲５▼AAAサーバ22は認証後、ホームエージェントHA 21に対して登録要求を送出する。
▲６▼ホームエージェントHA 21は登録処理終了後、AAAサーバ22に対して登録応答を送出する。
▲７▼AAAサーバ22は外部エージェントFA 31に対して登録応答を送出する。
▲８▼外部エージェントFA 31は移動端末MNに対して登録応答を送出する。
【０１４５】
図３７は、移動端末のＡＡＡセッションが残っていない場合において、課金継続するときの外部エージェントFAの処理フローである。
パケットを受信すれば(ステップ401)、外部エージェントFAは登録要求パケットであるか調べ(ステップ402)、登録要求パケットでなければ、課金継続処理以外のパケット処理を実行し(ステップ403)、次のパケットの受信を待つ。
一方、登録要求パケットであれば、該パケットに課金条件識別子が含まれているかチェックし(ステップ404)、含まれていれば該課金条件識別子を確認し、識別子が正しいかチェックし(ステップ405,406)、正しければ、対応する課金条件の有効期限を延長し(ステップ407)、AAAサーバ22に認証要求を送出し(ステップ408)、以後、始めに戻って以降の処理を繰り返す。尚、課金条件識別子が含まれていない場合および識別子が正しくない場合には、課金条件の有効期限を延長することなくAAAサーバ22に認証要求を送出する(ステップ408)。
【０１４６】
図３８は、移動端末のＡＡＡセッションが残っている場合における課金継続シーケンス説明図である。
▲１▼移動端末(MN)は課金条件の識別子を含む登録要求(周期登録メッセージ)を外部エージェントFA31に送出する。
▲２▼登録要求を受信した外部エージェントFA 31は、受信メッセージより課金条件識別子を検出する。
▲３▼検出された課金条件識別子を外部エージェントFAの課金装置制御機能部BECFが確認し、当該ユーザがサービスの継続を希望しているものとして課金条件の有効期限を延長する。
【０１４７】
▲４▼ついで、外部エージェントFA31はホームエージェントHA 21に対して登録要求を送出する。
▲５▼ホームエージェントHA 21は登録処理終了後、外部エージェントFA 31に対して登録応答を送出する。
▲６▼外部エージェントFA31は移動端末MN 11に対して登録応答を送出する。
【０１４８】
図３９は移動端末のＡＡＡセッションが残っている場合において、課金継続するときの外部エージェントFAの処理フローであり、図37と同一ステップには同一番号を付している。異なる点は、課金条件の有効期限を延長した後、ホームエージェントHA 21に対して認証要求を送出し(ステップ408′)、以後、始めに戻って以降の処理を繰り返す点である。
以上、課金装置BENにサービスの継続の意志を通知するために、移動端末の周期登録手順によりサービス提供者が発行した課金条件識別子を付与した登録要求を送出し、この識別子を外部エージェントFAの課金装置制御機能部BECFが検出して当該ユーザの課金サービス継続を課金装置BENに通知する。しかし、周期登録メッセージ自体が発行されない場合、もしくは周期登録メッセージ内に課金条件識別子が含まれていない場合は、サービス継続の意志が無いものと判断し、課金装置BENに課金収集動作終了を指示し、ネットワーク内装置でサービス継続の有無を確認する。
【０１４９】
（ｍ）サービス実行中の課金条件の再設定
サービス実行のための課金条件(料金条件)が、移動端末MNとサービス提供サーバCN間で合意され、サービスが開始して実行中の状態において、ユーザが自らの意思でサービス条件(課金条件)を変更したいと希望する場合がある。このような場合、サービス実行中に適用中の課金条件を再設定できるようにする必要がある。また、サービスの正常終了を待たずにユーザ端末の意思で、明示的にサービス中断を要求し、これを契機にサービス中断、課金動作の中断を行えるようにすることも必要である。
かかる制御を行うために移動端末MNの周期登録動作を利用する。以下に、サービス条件変更、およびサービス中断する場合における機能を示す。
【０１５０】
(1)サービス条件を変更する場合
サービス利用中の端末MNが発行する周期位置登録にデフォルトで以下の情報▲１▼接続先サーバ情報、▲２▼課金条件識別子が付与されている。これに対して、サービス条件変更の場合は、新たな情報として▲３▼サービス要求情報（利用資源等）を付与する。この情報を含むことで、ネットワーク中の課金動作に関連する装置類は、サービス変更が要求されていることを認識する。
【０１５１】
(2)サービスを中断する場合
サービス中断要求を行う場合は、上記情報▲３▼の中に、サービス中断を識別可能なフラグ情報を入れる。これにより、ネットワーク上の課金関連装置は、当該端末のサービス中断を認識する。課金装置BENを制御する課金装置制御機能部BECFが該フラグ情報を検出した場合、即座に課金装置BENに当該端末の課金動作の中断を指示し、課金条件管理テーブル44から当該サービスに関する情報を削除する。また、サービスを提供するサーバCN 41は、サービス提供動作を中断する。
【０１５２】
図４０は課金条件変更シーケンス説明図である。
▲１▼ユーザ又はアプリケーションからのサービス変更要求をMIP制御部が検出する。
▲２▼移動端末(MN)はサービス提供サーバ名、課金条件識別子、サービス要求を含む登録要求（周期登録要求）を外部エージェントFA31に送出する。
▲３▼外部エージェントF 31は課金条件識別子、サービス要求よりサービスの変更を検出する。
▲４▼ついで、外部エージェントFA31はAAAサーバ22に対して課金条件識別子、サービス要求を含む認証要求を送出する。
【０１５３】
▲５▼AAAサーバ22は認証処理すると共に、ユーザ課金プロファイルUBPを課金情報データべースBIDB24より抽出する。
▲６▼AAAサーバ22はホームエージェントHA 21に対してサービス提供サーバ名、課金条件識別子、ユーザ課金プロファイルUBPを含む登録要求を送出する。
▲７▼ホームエージェントHA 21は登録処理終了後、サービス提供サーバCN 41に対して課金条件識別子、ユーザ課金プロファイルUBPを含む結合更新メッセージを送出する。
【０１５４】
▲８▼サービス提供サーバCN 41は結合情報を処理するとともに、ユーザ課金プロファイルUBPとサーバ課金プロファイルSBPを照合して課金条件を生成する。
▲９▼しかる後、サービス提供サーバCN 41は生成した新たな課金条件の識別子を再生成し、その情報を結合応答に付加してホームエージェントHA 21に送出する。
(10)ホームエージェントHA 21はAAAサーバ22に対して登録応答を送出する。
【０１５５】
(11)AAAサーバ22は外部エージェントFA 31に対して登録応答を送出する。
(12)外部エージェントFA 31の課金装置制御機能部BECFは登録応答に付加された課金条件、課金条件識別子を抽出し、課金装置BENに設定する。
(13)外部エージェントFA 31は移動端末MN 11に対して登録応答を送出する。MIP制御部は交渉結果をアプリケーションに通知する。
(14)以後、移動端末MN 11は課金条件識別子をサービス提供サーバCN 41に送出してサービス条件受諾を通知すれば、該サーバはサービス対象パケットを移動端末宛に送出し、課金装置は新たな課金条件にしたがって課金処理を行う。
【０１５６】
図４１は課金条件を変更する場合における外部エージェントFAの処理フローである。パケットを受信すれば(ステップ501)、外部エージェントFAは登録応答パケットであるか調べ(ステップ502)、登録応答パケットでなければ、登録要求パケットであるか調べ(ステップ503)、登録要求パケットでなければ、課金条件変更処理以外のパケット処理を実行し(ステップ504)、次のパケットの受信を待つ。一方、登録要求パケットであれば、該パケットにサービス要求が含まれているかチェックし(ステップ50５)、サービス要求が含まれていれば課金条件識別子も含まれているかチェックし(ステップ506)、含まれていればAAAサーバ22にサービス要求及び課金条件識別子を含んだ認証要求を送出する(ステップ507)。
【０１５７】
又、ステップ50５において、サービス要求を含んでいなければ、AAAサーバ22に認証要求を送出し(ステップ508)、ステップ506において課金条件識別子を含んでいなければ、AAAサーバ22にサービス要求を含んだ認証要求を送出する(ステップ50９)。更に、ステップ502において、登録応答であれば、課金条件を含んでいるかチェックし(ステップ510)、含んでいれば課金装置BENに課金条件を設定する(ステップ511)。
【０１５８】
図４２は課金条件を変更する場合におけるサービス提供サーバCNの処理フローである。
パケットを受信すれば(ステップ551)、サーバCNはパケットが結合更新パケットであるか調べ(ステップ552)、結合更新パケットでなければ、課金条件変更以外のパケット処理を実行し(ステップ553)、次のパケットの受信を待つ。
一方、結合更新パケットであれば、該パケットにサービス要求(ユーザ課金プロファイルUBP)が含まれているかチェックし(ステップ554)、サービス要求が含まれていれば課金条件識別子も含まれているかチェックし(ステップ555)、課金条件識別子も含まれていれば該課金条件識別子を確認し、識別子が正しいかチェックし(ステップ556,557)、正しければ、それまでの課金条件を課金条件管理テーブル44より破棄する(ステップ558)。ついで、サーバCNは、ユーザ課金プロファイルUBPとサーバ課金プロファイルSBPを照合して新たな課金条件を再生成する(ステップ559)。しかる後、サーバCN 41は生成した新たな課金条件の識別子を再生成し(ステップ560)、その情報を結合応答に付加してホームエージェントHA 21に送出する(ステップ561)。
【０１５９】
一方、ステップ555において、課金条件の識別子が含まれていなければ、課金条件の変更でないから、サーバCNは、ユーザ課金プロファイルUBPとサーバ課金プロファイルSBPを照合して課金条件を生成する(ステップ562)。しかる後、サーバCN 41は生成した課金条件の識別子を生成し(ステップ563)、その情報を結合応答に付加してホームエージェントHA 21に送出する(ステップ561)。
また、ステップ554において、パケットにサービス要求(ユーザ課金プロファイル)が含まれていなければ、サーバCNは結合情報を処理し(ステップ564)、ホームエージェントHAに対して結合応答を送出する(ステップ561)。
【０１６０】
（ｎ）ハンドオーバ対応機能（課金条件の転送）
有料サービスを受けているユーザ端末が、スムースハンドオフの能力を備えているものとする。かかる場合、外部エージェントFA間の端末移動にともなう認証時、実行中サービスに関する課金情報等を新旧FA間で送受することで、パケットの廃棄を防止すると共に、課金条件も移動後の新FAに引き継がせることでより正確な課金情報の収集を可能とする。尚、以下においてネットワーク構成としては図18の構成を念頭に入れて説明している。
具体的には、端末移動によるスムースハンドオフ発生時点で、移動端末MN(図18参照)は移動後の外部エージェントFA（以下新FAという）に対して登録要求メッセージを送出する。この登録要求メッセージを受けた新FA 31′は、該移動端末MNを移動前に収容していた外部エージェントFA 31（旧FAという）に対して、結合更新と呼ばれるメッセージを送出して、旧FAに到着する当該端末宛のパケットを、新FAに転送するように依頼する。
【０１６１】
結合更新メッセージを受けた旧FAはこの結合情報に基づいて、当該移動端末宛のパケットを新FAへ転送する設定を行い、設定完了後に結合応答メッセージを新FAに対して送出し、結合情報を受理したことを通知する。ただし、当該移動端末MNが、有料サービスを実行中であれば、旧FA 31は自装置内の課金機能に適用されていた課金条件を抽出して新FAに転送するために、該課金条件を結合応答メッセージに含める操作を行う。
【０１６２】
新FAは旧FAが送出した課金情報メッセージを検出し、即座にこれを新FAと連携する新課金装置に設定する。新FAにおける登録が完了すれば、当該サービスのパケットは新FA宛に送出されるため、旧FAは最終となるパケットを一定期間監視して後続パケットが来ないことを検出して、旧FAにおける課金動作を終了する。
【０１６３】
図４３は移動後の課金のためのシーケンス説明図である。
▲１▼移動端末(MN)は移動検知後、smooth handoff拡張情報、課金条件識別子を含む登録要求を新FA 31′に送出する。
▲２▼新FA 31′は課金条件識別子を含んだ結合要求メッセージを旧FA 31に送出する。
▲３▼旧FAは受信した結合要求メッセージに含まれる課金条件識別子をチェックし、正しければユーザの課金情報を含む結合応答メッセージを新FAに送出する。
▲４▼新FAは受信した結合応答メッセージに含まれる課金情報(課金条件)を新課金装置に設定する。
【０１６４】
▲５▼以後、新FAはAAAサーバ22に認証要求を送出する。
▲６▼AAAサーバ22は認証処理を行い、ホームエージェントHA21に対して登録要求を送出する。
▲７▼ホームエージェントHA21は登録処理後、AAAサーバ22に対して登録応答を送出する。
▲８▼AAAサーバ22は新FAに登録応答を送出する。
▲９▼新FAは移動端末MNに登録応答を送出する。
尚、シーケンス▲２▼〜▲４▼、シーケンス▲５▼〜▲９▼を並行して処理するパターンもある。
【０１６５】
図４４は移動後の課金のための新FAの処理フローである。
新FA31′はパケットを受信すれば(ステップ601)、該パケットが結合応答パケットであるかチェックし(ステップ602)、結合応答パケットでなければ、登録要求パケットであるかチェックし(ステップ603)、登録要求パケットでなければハンドオフ課金処理以外の処理を実行し(ステップ604)、次のパケットの受信を待つ。一方、登録要求パケットであれば、smooth handoff拡張情報を含んでいるかチェックし(ステップ605)、含んでいれば更に課金条件識別子を含んでいるかチェックし(ステップ606)、含んでいれば、旧FA31に課金条件識別子を含む結合更新メッセージを送出する(ステップ607)。これにより、旧FAは移動端末宛のパケットを新FAへ転送する設定を行い、設定完了後に結合応答メッセージを新FAに対して送出し、結合情報を受理したことを通知する。また、移動端末MNが、有料サービスを実行中であれば、旧FAは自装置内の課金機能に適用されていた課金条件を抽出、該課金条件を結合応答メッセージに含める。
【０１６６】
一方、ステップ606において、課金条件識別子を含んでいなければ、新FA31′は旧FA31に結合更新メッセージを送出する(ステップ608)。これにより、旧FAは移動端末宛のパケットを新FAへ転送する設定を行い、設定完了後に結合応答メッセージを新FAに対して送出し、結合情報を受理したことを通知する。尚、旧FAは自装置内の課金機能に適用されていた課金条件を結合応答メッセージに含めない。
【０１６７】
以後、新FAはAAAサーバ22に対して認証要求を送出する(ステップ609)。 又、ステップ605において、smooth handoff拡張情報を含んでいなければ、直ちに、新FAはAAAサーバ22に対して認証要求を送出する。
また、ステップ602において結合応答メッセージを受信すれば、課金情報が含まれているかチェックし(ステップ610)、含まれていれば新課金装置に課金条件を設定する(ステップ610,611)。
【０１６８】
図 45は移動後の課金のための旧FAの処理フローである。
旧FA31はパケットを受信すれば(ステップ651)、該パケットが結合更新パケットであるかチェックし(ステップ652)、結合更新パケットでなければ、ハンドオフ課金処理以外の処理を実行し(ステップ653)、次のパケットの受信を待つ。一方、結合更新パケットであれば、課金条件識別子を含んでいるかチェックする(ステップ654)。課金条件識別子を含んでいれば、該当移動端末MN、サーバCNに対する課金条件識別子と比較し、その正当性をチェックする(ステップ655)。受信した課金条件識別子が正しければ(ステップ656)、課金情報(課金条件)を含んだ結合応答パケットを新FA31′に送信する(ステップ657)。
【０１６９】
一方、ステップ654において課金情報識別子が含まれていなければ、あるいは、ステップ656において受信した課金条件識別子が正しくなければ、課金情報を含まない結合応答パケットを新FA31′に送信する(ステップ658)。
以上、スムースハンドオフ機能が導入されたネットワークにおいて、移動端末が旧ＦAから新ＦＡに移動した際、旧ＦＡは当該端末の料金条件を結合応答メッセージに含めて新ＦＡに通知するから、新ＦＡは旧ＦＡと同一料金条件でサービス提供を継続することができる。
【０１７０】
（ｐ）ハンドオーバ対応機能（サービスセッション情報の認証）
端末移動によるハンドオーバ前後において、登録要求を出すユーザが利用中サービスに関する正当なユーザであるか否かを確認する必要がある。そこで、有料サービス利用中に端末移動によりFA間移動した場合、新FAを介して位置登録を実施しようとする端末は、課金条件識別子を提示して当該サービスのセッションを保持することを可能とする。仮に、不正なユーザが登録要求を行っても、サービス開始時に端末が保持している課金条件識別子を提示させることで、正当なユーザであるか否かを確認できる。
【０１７１】
具体的に図43のシーケンスを参照して説明すると、▲１▼新FAへ登録要求を発行する際、このメッセージ中に課金条件識別子を含める。▲２▼新FAは、スムースハンドオフ手順において送出する結合要求メッセージ中に当該端末が提示した課金条件識別子を含めて旧FAに送達する。▲３▼旧FAの課金装置制御機能部は受信した結合要求メッセージ中に含まれる課金条件識別子と、課金条件管理テーブル４４に保持されている課金条件識別子とを照合し、合致すれば正当なユーザであると確認し、照合結果を結合応答メッセージ含めて新FAに応答する。▲４▼新FAは、結合応答メッセージ中に含まれる課金条件識別子の照合結果を見て、これが合致することが判明すれば、同メッセージに乗せられた課金条件データを課金装置制御機能部により新課金装置に設定する。課金条件識別子の照合結果が不一致の場合、当該端末に関するサービスを中断する。
【０１７２】
以上より、課金動作の継続にあたり、新ＦＡに位置登録要求を出した端末の正当性を移動後のルータ（新FA）から移動前ルータ(旧FA)に問い合わせることで確認することができる。
【０１７３】
（ｑ）課金条件設定の契機
課金条件の生成および課金装置への課金条件の設定については、課金対象のパケットがサーバ等から送出される以前に完了することが望ましい。このため、課金動作の準備に関わる手順を、移動端末の位置登録手順と並行して実施する。
具体的には、端末の位置登録はネットワークレイヤにおいて移動端末宛のパケット転送の設定を行うことが目的であるが、この登録手順に課金に関する情報設定と配布処理を連携させることで、個別のメッセージを追加することなく課金情報の事前設定を可能にする。
【０１７４】
図46は、位置登録手順を利用してサービス課金条件交渉手順を実行する基本シーケンス説明図である。
▲１▼端末ユーザは、アプリケーション上で接続しようとするサービス（業者）への接続を試みる。このとき、アプリケーションAPLは、自端末の位置登録管理機能部(MIP制御部)に対して、接続先（サービス提供サーバCN）へ位置登録要求メッセージを利用してサービス要求情報を送出するよう指示する。サービス要求情報は、
・接続先サーバの特定情報（例：IPアドレス、 URLなど）
・要求資源情報（当該アプリケーションAPLがサービスの実行に必要とする資源、例えば伝送速度など）、
を含んでいる。
【０１７５】
▲２▼移動端末内のMIP制御部は、アプリケーションAPLからのサービス要求情報を位置登録要求メッセージに埋め込み、ネットワークに該位置登録要求メッセージを発行する。Mobile IPの場合は、Vendor/Organization-Specific Extension 内に上述のデータを埋め込む。
▲３▼移動端末MNからの位置登録要求を受けた外部エージェントFA 31は、AAAサーバ22へ本要求を回送する。
▲４▼登録要求を受けたAAAサーバ22は、移動端末MNの端末認証を実施すると同時に、課金情報データべースBIDB 24にも照会をかけ、当該移動端末MN 11のユーザ課金プロファイルUBPを抽出する。
【０１７６】
▲５▼AAAサーバ22は、ホームエージェントHA 21に対して位置登録を行うと同時に、サービス提供サーバCN 41に対して移動端末MN 11に関する情報を結合メッセージとして送出する。この結合メッセージには、当該ユーザの課金プロファイルUBPと位置情報が含まれている。
▲６▼結合メッセージを受けたサーバCN 41は、当該移動端末MN 11のユーザ課金プロファイルUBPと自分のサービス提供条件(サーバ課金プロファイルSBP)を照合して、可能な課金条件を割り出し課金対象機器が理解可能な表現形式で生成する。また、当該移動端末MNに対する接続時の課金条件識別子を生成し、課金条件や課金条件識別子を埋め込んだ結合応答メッセージをホームエージェントHA 21に向けて送出する。この後、サーバCNは、移動端末MNを収容する外部エージェントFAへのトンネルを設定し、パケット送出の準備をする。また、先に設定した識別子に関して有効期間のタイマーを起動させる。
【０１７７】
▲７▼結合応答メッセージを受信したホームエージェントHA ２１は、これをAAAサーバ22に回送する。
▲８▼AAAサーバ22は当該メッセージを外部エージェントFA 31へ認証応答として返す。
▲９▼結合応答メッセージを受信した外部エージェントFA ３１の課金装置制御機能部BECFは、該メッセージより課金条件を抽出して、自装置内の課金装置BENに新規に設定する。この時点で、外部エージェントFA 31を経由する当該ユーザ端末のアプリケーション宛パケットに対する課金が可能となる。ただし、課金実行条件が成立していない場合は、登録応答にその旨を示す内容を含める。
【０１７８】
(10)外部エージェントFA 31より登録応答を受信し、IPレイヤで問題がなければ、MIP制御部はアプリケーションAPLに対して当該メッセージに含まれる課金折衝の結果と課金情報識別子を伝達し、アプリケーションはこれをサービス実行期間中保持する。
(11)移動端末上のアプリケーションAPLは、上記結果をユーザにメッセージ表示等で伝達する。ユーザが承認する場合には、何らかの入力操作をするから、これにより課金情報識別子を含んだ周期位置登録メッセージを送出する。この課金条件承諾を示すメッセージ（周期位置登録要求）は外部エージェントFAに到達し、その課金装置制御機能部BECFはこれを認識して課金装置に通知し、当該サービスに対する課金を開始させる。
(12)前記課金条件承諾メッセージはさらにサービス提供サーバCN 41に転送され、該サーバは要求元ユーザに対してサービスを開始する。
【０１７９】
（ｒ）位置登録済み端末のユーザ課金プロファイルの抽出法
移動端末MNが、サービス開始契機以前に一旦位置登録を完了していれば、初期位置登録のAAAサーバ認証時に既にユーザ課金プロファイルUBPは抽出されている。かかる位置登録完了後に新たな有料サービスの提供を受けるために移動端末がサービス要求情報を含む位置登録メッセージを送出することがある。このような場合、端末の認証処理は認証セッション期間が有効であれば不要であり、ユーザ課金プロファイルUBPも初期位置登録時と同じである。それにもかかわらず、新たな有料サービスの提供を受けるために、初期位置登録時と同じ内容のユーザ課金プロファイルUBPを課金情報データべースBIDBにアクセスして取得するのは、AAAサーバ22に余分な負荷を強いる結果となり、回避することが望まれる。
【０１８０】
このため、初期位置登録において、AAAサーバ22に認証要求し、この応答として課金情報データべースBIDB 24より抽出した当該ユーザ端末のユーザ課金プロファイルUBPのコピーを、サーバへの転送経路上に存在するホームエージェントHA 21に保存(キャッシュ)する。以後、AAAサーバ22の端末認証セッションの有効期間内に新規サービス要求(サーバ切替)があった場合、外部エージェントFAを通過した登録メッセージは、AAAサーバ22を経由せずにホームエージェントHA 21に到達し、ホームエージェントHA 21がキャッシュしているユーザ課金プロファイルUBPを新規接続先のサーバに転送し、当該サーバ内で課金条件を生成する。以後の処理は初期位置登録時の料金交渉と同様である。
【０１８１】
図４７はホームエージェントHAのユーザ課金プロファイルキャッシュ処理及びそのキャッシュ利用処理フローであり、以下の２つの処理
▲１▼初期交渉時のユーザ課金プロファイルUBPのキャッシュ処理、
▲２▼接続先サーバ切替時のホームエージェントHA内のキャッシュ参照によるAAAサーバへのアクセス回避処理、
に大別される。
【０１８２】
ユーザ端末がネットワークに対して新規サービス要求を含む登録要求パケットを送出すると、ホームエージェントHAは、外部エージェントFA、AAAサーバ22を介して、該パケットを受信し、その内容を分析する(ステップ701)。ついで、登録要求パケットの送信元を判別し(ステップ702)、送信元がAAAサーバ22であれば、端末認証セッションの新規設定時における登録要求パケットであると認識する。しかる後、該パケットにサービス要求メッセージ及びユーザ課金プロファイルUBPが含まれているかチェックし(ステップ703)、含まれていれば、ユーザ課金プロファイルUBPのコピーを内蔵のメモリに保存(キャッシュ)する(ステップ704)。又、該コピーの有効期間監視タイマーを起動し(ステップ705)、以後、次のパケットの受信を待つ。ステップ703において、登録要求パケットにサービス要求メッセージまたはユーザ課金プロファイルUBPが含まれていなければ、キャッシュ処理対象外のパケットであるから所定の処理を行って(ステップ706)、以後、次のパケットの受信を待つ。……以上、ユーザ課金プロファイルキャッシュ処理
【０１８３】
ステップ702において、送信元が外部エージェントFAであれば、ホームエージェントHAは端末認証セッション有効時における登録要求パケットであると認識する。ついで、ホームエージェントHAは、該登録要求パケットがサービス要求メッセージを含み、同時に、当該端末に関するユーザ課金プロファイルUBPのコピーがホームエージェント内部にキャッシュ(保存)されているかチェックする(ステップ707)。尚、ホームエージェントHAは登録要求パケットにサービス要求メッセージが含まれることで、課金開始要求であることを検知する。
【０１８４】
これにより、ホームエージェントHAは該ユーザ課金プロファイルUBPのコピーを読み出し、該ユーザ課金プロファイルUBPを含む課金開始要求メッセージを形成し(ステップ708)、該メッセージをユーザが新たに接続しようとするサーバに向けて送信し(ステップ709)、以後、次のパケットの受信を待つ。……以上、キャッシュ利用処理
【０１８５】
以上のように、一旦、端末MNの認証処理が完了後、あるサービスを利用しているユーザが、そのサービスの利用を中断して別のコンテンツサーバに接続する場合に効果がある。すなわち、新規サーバへ接続開始する際に、当該端末に関するAAAサーバによる端末認証セッション期間が残っていれば、端末認証手順をする必要がなく、AAAサーバ22へのアクセスは不要である。そこで、ユーザ課金プロファイルのコピーをホームエージェントHAで保存（キャッシュ）し、参照/利用することで、FA→AAA→HAの経路の装置間メッセージ数とAAAサーバ22で実行される課金プロファイル抽出の処理を削減することができる。
【０１８６】
（Ｅ）課金機能を配備した場合の第2のネットワーク構成
（ａ）課題
図22のネットワーク構成における課金技術(第1の課金技術という)は、ユーザとサービス提供者双方に対してサービスの課金条件を実行前に整合させ、必要に応じて端末ユーザに課金条件を提示してユーザの希望する条件を選択させるものである。しかし、この第1課金技術は汎用性の点で以下の3つの課題がある。
【０１８７】
第1の課題は、機能実現のために、ユーザとサービス提供者間の課金条件交渉手順としてMobile IPを拡張利用していることに起因して発生する。Mobile IPの利用は、IPv4, IPv4版EaseNet (Environment Adaptive Services Network)に対する親和性高いという利点を有するが、ネットワーク、端末双方が共にMobile IP機能の実装を必須とする制約がある。このため、Mobile IP等の個別プロトコルを利用せず、これらプロトコルを実装する必要のない課金制御技術が望まれる。
第2の課題も、課金条件交渉の手順としてMobile IPを拡張利用していることに起因して発生するもので、以下の問題点、
(1)ホームエージェントHAに課金制御メッセージ制御機能を追加しなければならない、
(2)課金交渉手順は、無条件にホームエージェントHAを経由するため、ユーザホストからサービス提供ノードまでの経路が冗長になる、
がある。このため、制御メッセージの経路を最適化できる課金技術が望まれている。
第3の課題は、１つのサービスを提供するサービス提供サーバは物理的に１台であり、しかも課金制御機能の内蔵を前提としている。かかる構成は、サービス提供サーバが地域的に分散され、かつ、課金制御を一括集中させたシステム形態に適さない。なお、このようなシステム形態としては、例えば、ネットワークカーナビゲーションシステム等が考えられ、今後、これらのシステム形態は商用化の可能性が大きい。このため、分散したサービス提供ノードが共通のサービスを行なう場合における課金技術が望まれている。
【０１８８】
本発明の課金技術(第２課金技術という)は、第１課金技術の上記課題を解決するものであり、第1課金技術の基本コンセプトである以下の三点
(1) ユーザ側、サーバ側のそれぞれに課金プロファイルを規定する、
(2) ユーザ毎に提供されるサービスに応じて、サービス起動要求ごとに料金条件を動的決定する、
(3)ユーザがサービス実行前に課金条件を確認することを可能とする、
をより汎用的かつ効率的に実現する。併せて、第２課金技術は、今後の商用インターネットプロトコルの主体と見られるIPv6への親和性も確保する。
【０１８９】
（ｂ）ネットワーク構成
図４８は本発明のIPv6をべースとした第2の課金技術を適用できるネットワークの構成図であり、コアネットワークとしてIPv6ネットワーク51を備え、該ネットワークにAAAサーバ52、IPv6ネットワークを構成する通信ノードとしてのエッジルータ501、502が接続され、アクセス網551、552を介して端末装置としてのIPv6ホスト581、582がIPv6ネットワーク51と接続されている。図４８のネットワークは、単一のドメインから構成されており、このドメインは、あるサービスプロバイダにより管理されている。このドメインに属するIPv6ホスト581、582はAAAサーバ52により認証される。
さらに、IPv6ホスト581、582はそれぞれIPv6プロトコルに従って通信を行なう機能を備えた端末装置であり、それぞれこのドメインに属している。尚、IPv6ホスト581、582のユーザは、このドメインを管理するサービスプロバイダとの間で加入者契約をしている。そして、IPv6ホスト581、582は、それぞれ、エッジルータ501、502に収容されている。
【０１９０】
図４９はサービスプロファイル情報及び課金プロファイル情報をAAAサーバ52よりエッジノード501に配布する基本シーケンスである。なお、サービスプロファイル情報はAAAサーバ52がアクセス可能なサービスプロファイルデータべースSPDB に格納されており、課金プロファイル情報は課金プロファイルデータべースBPDB に格納されている。
IPv6ホスト581は、ネットワークから定期的にICMP広告を受信する。ここで、ICＭＰ広告は、例えばエッジノードENより各端末に送出されるメッセージであり、ここでは、エッジノード501からIPv6ホスト581にICMP広告が送られる。
【０１９１】
IPv6ホスト581はICMP広告を受信すると、必要に応じてエッジノード501に対してアドレスの割り当てを要求するアドレス割当要求(ICMP-AAA要求)を送出する。尚、IPv6ホスト581は、▲１▼IPアドレスを保持していない場合、▲２▼先に割り当てられていたIPアドレスが消滅した場合、▲３▼あるエッジノードの通信エリアから他のエッジノードの通信エリアに移動した場合、などにアドレス割当要求を出力する。
【０１９２】
エッジノード501は、アドレス割当要求を受信すると、IPv6ホスト581に割り当てるべきIPアドレスを決定すると共に、IPv6ホスト581の正当性の認証を要求する認証要求メッセージをAAAサーバ52に送出する。AAAサーバ52は認証要求を受信するとそのIPv6ホスト581の正当性を認証すると共に、データべースSPDB,BPDBよりそれぞれサービスプロファイル情報SP及び課金プロファイル情報BPを抽出する。そして、AAAサーバ52は、認証応答と共にIPv6ホスト581のサービスプロファイルSP及び課金プロファイルBPを、エッジノード501に送出する。エッジノード501は、認証応答及びIPv6ホスト581のサービスプロファイルSP及び課金プロファイルBPを受信すると、サービスプロファイル及び課金プロファイルを内蔵のキャッシュメモリに格納する。また、エッジノード501は、IPv6ホスト581が正当な端末であれば、アドレス割当要求に対する応答として、既に決定してあるアドレスを含めてアドレス割当応答(ICMP-AAA応答)をIPv6ホスト581に返送する。
【０１９３】
以上の手順により、IPv6ホスト581に新たなIPv6アドレスが割り当てられる。そして、このアドレス割当手順と連携して、IPv6ホスト581がAAAサーバ52により認証されると共に、IPv6ホスト581のサービスプロファイルSP及び課金プロファイルBPがそのIPv6ホスト581を収容しているエッジノード501に配布される。このように、図４８のネットワーク形態では、ICMPv6とAAAプロトコルとが互いに連携している。
【０１９４】
（ｃ）課金機能を装備した場合のネットワーク構成
図５０は図４８のネットワークに課金機能を装備した場合のネットワーク構成図であり、IPv6ネットワークとしてのコアネットワーク51の周縁部にエッジノード（EN-1〜EN-3）501〜503が設けられている。エッジノードEN-1〜EN-3は、ルータ機能を基本として構成され、
▲１▼ユーザ端末にアドレスを割り当て、該アドレスの認証をAAAサーバ52に要求  する機能、
▲２▼AAAサーバ52からダウンロードされたユーザ課金プロファイルを保持、管理  する機能、
▲３▼ユーザホストのパケットから、有料サイトへの接続を検出する機能、
▲４▼上記有料サイトへの接続要求を検出後、当該ユーザの課金プロファイルを該接続要求に付加する機能、
▲５▼課金制御メッセージを送受信する機能（課金制御メッセージ制御機能）
▲６▼配布された課金制御識別子を管理する機能（課金条件識別子管理機能）、
▲７▼課金装置(課金エンジン)BENを制御する課金装置制御機能BECF、
等を有している。
【０１９５】
又、コアネットワーク51にはAAAサーバ52が接続されている。AAAサーバは本来のAuthentication（認証）、Authorization（認可）、Accounting（課金）制御を行なうと共に、サービスプロファイルを管理するデータベース(図示せず)から、認証対象ホスト(ユーザ)のサービスプロファイルSPを抽出し、認証結果等に付して通知する機能を有している。又、AAAサーバ52は課金プロファイル管理機能を備え、各ユーザの課金プロファイル記憶する課金情報データべース53からユーザの課金プロファイルBPを抽出してエッジノードにダウンロードする。
【０１９６】
サービス提供ノードXSPN-1、XSPN-2（X-Service Provider Node） 541，542はサービスをユーザに提供するサーバであり、それぞれアクセスネットワーク55,56に接続されている。なお、アクセスネットワーク55,56とコアネットワーク51間にエッジノードEN-1，EN-2が設けられている。XSPは、ASP (Application Service Provider) , CSP (Content Service Provider), ISP ( Internet Service Provider) 等のインターネット上での各種レベル、形態のサービス提供業者の総称である。サービス提供ノードXSPNは以下の４つの機能、
▲１▼サービスを提供する機能、
▲２▼課金制御メッセージを送受信する課金制御メッセージ制御機能、
▲３▼課金条件のユーザへの確認手段として機能するユーザインタラクション機能  (課金条件決定機能)、
▲４▼配布された課金識別子を管理する機能（課金条件識別子管理機能）、
等を有している。
【０１９７】
課金制御ノードBCN（Billing Control Node）57は課金条件を生成するサーバであり、ユーザおよびサービス提供者双方の課金プロファイルを参照することにより、当該ユーザがサービス提供に際して利用可能なサービス形態（品質等）を含む課金条件を生成する。課金制御ノードBCNはサービス提供者の管理下にあり、提供されるサービス種別に対して最低１つ存在する。また、サービスの提供形態によっては、１台の課金制御ノードBCN 57で複数のXSPNを制御することも可能である。この課金制御ノードBCN 57には以下の６つの機能、
(1)サーバ課金プロファイルを登録管理する機能、
(2)ユーザ個別の課金条件を算出する課金条件生成機能、
(3)生成された課金条件に課金条件識別子を付与する課金条件識別子生成機能、(4)複数に分散されたサービス提供ノードXSPNを管理してユーザのローミングをサポートするサービス提供ノード制御機能、
(5)課金制御メッセージを送受信する課金制御メッセージ制御機能、
(6)ユーザ端末とサービス提供ノードXSPNとの間の交渉で決定された課金条件を登録管理する機能
等を有している。
【０１９８】
ユーザ端末58は例えばIPネットワークに接続可能なモバイルホスト(ユーザホスト)MHであり、課金装置(課金エンジン)は図示しないがユーザ側のエッジノード（EN-1）内に配備され、課金は該エッジノード（EN-1）に到達したパケットについて実施される。又、課金エンジン制御機能部も、課金エンジンと連動する必要があるためユーザ側エッジノード（EN-1）に配備される。以下ではユーザ端末はモバイルホストあるいはユーザホストあるいは移動端末という場合がある。
詳細な課金制御は後述するが、EaseNet-v6のサービス制御手順を利用して概略以下の(1)〜(3)に従って課金条件を生成し、該課金条件に従った課金する。
(1) 準備段階：EaseNet-v6のサービス制御手順で、ユーザ側の課金プロファイルを、当該ユーザ端末58を収容するエッジノードEN-1にダウンロードしておく。
(2) 起動段階：ユーザ端末58のXSPサーバに対する接続要求が特定の課金サービス提供要求であることをエッジノードＥＮ-1が検出して、保持している当該ユーザ端末の課金プロファイルを該要求に付してサービス提供ノードXSPN-2に対して送付する。
(3) 課金条件生成：有料サービスノード、すなわち、サービス提供ノードXSPN-2は、課金条件整合要求メッセージにより課金制御ノードBCNに課金条件の整合を依頼し、該課金制御ノードBCNよりユーザに提供するサービスの課金条件候補を取得すれば、これをユーザに提示し、ユーザが課金条件候補を承認すればサービス提供を開始し、課金エンジンは該課金条件に従って課金を開始する。
【０１９９】
第2課金技術では、ユーザとの間で料金条件を調整する課金制御機能と実際にユーザに対して有料サービスを提供する機能を分離し、それぞれの機能を課金制御ノードBCNとサービス提供ノードXSPNに行なわせている。図22の第1課金技術の構成では、両者が一体となっているが、かかる構成では、ネットワーク上で広域に複数のサーバを用いて展開されるサービス、例えばネットワーク経由で地理的に離れた複数のサーバより順次地理情報を提供するネットワークカーナビゲーションサービスなどに課金することができない。第2課金技術では、かかるサービスに対して課金を行なうことができる。しかし、課金制御ノードとサービス提供ノードを分離したため、これらの間で課金条件を一元管理する機構が必要である。その実現の手段として、第2課金技術では両者の間で課金制御メッセージを用いて課金条件等の情報を送受を可能としている。具体的には、以下に示す4つの課金制御メッセージがある。
【０２００】
(1) 課金条件整合要求メッセージ（XSPN→BCN）：課金条件の整合(生成)を要求するメッセージであり、ユーザ端末(ユーザホストMH)の課金プロファイルを含めて送達される。又、このメッセージは、サービス開始時だけでなく、サービス実行中の課金条件変更時にも使用される。
(2)課金条件整合応答メッセージ（BCN→XSPN）：上記課金条件整合要求メッセージに対する応答メッセージであり、課金条件整合結果である課金条件候補が含まれる。課金制御ノードBCNはユーザ個別の課金条件を参照し、当該サービスに関して提供可能な課金条件候補を抽出してこれを本メッセージで要求元のサービス提供ノードXSPNに返信する。また、当該ユーザホストMHがすでにこの課金制御ノードBCN上で条件の整合が済んでいる場合は、その旨を示す課金条件識別子が課金条件に替わって含まれる。
【０２０１】
(3) 課金条件決定通知メッセージ（XSPN→BCN）：条件整合の結果（課金条件候補）をユーザホストに提示したのち、課金条件候補より、ユーザが所望の一つを決定しこれをサービス提供ノードXSPNが認識した際、その内容を課金制御ノードBCNに通知するためのメッセージである。このメッセージを受けた課金制御ノードBCNは、決定された課金条件を課金条件識別子、移動端末の識別子（NAI）、サービス提供ノードXSPNの識別子等と共に課金条件登録テーブルに記録し、他の候補を消去する。
(4) 課金条件変更通知メッセージ（BCN→XSPN）：サービス提供条件に従ってサービス提供ノードXSPNがサービス提供中に、課金制御ノードBCNが課金条件を更新したたとき、新課金条件をサービス提供ノードXSPNに配布するためのメッセージである。
【０２０２】
（ｄ-1）課金制御手順
(c-1)MHとXSPNが別サブネットに存在する場合
図５１はユーザ端末(ユーザホストMH)とサービス提供サーバXSPNが別サブネットに存在する場合において、ユーザホストMHが有料サービスを利用する際の課金制御説明図、図５２は課金制御手順図である。なお、前提条件として、課金情報データべース53よりユーザホストMHを収容するエッジノードEN-1に該ユーザホストMHの課金プロファイルがダウンロードされ、該エッジノードEN-1に保持されているものとする。
【０２０３】
ユーザホストMHが有料サービスへの接続を希望する場合、所望のサイトへ接続要求を出す。この接続要求プロトコルとしては各種のプロトコルがあり得るが、一例としてサービス提供サーバXSPN-2内の、有料サービス受付用WEBサイトへアクセスする際のHTTP要求がある。したがって、ユーザホストMHは利用を希望する有料サイトに対して（WWWブラウザのURL指定等により）アクセスする。このHTTPパケットは、接続先サイトに到達する過程において、ユーザホストMHを収容するエッジノード（EN-1）に到達し、該エッジノードEN-1は通常のルータ機能により該HTTPパケットを転送する。この転送に際して、エッジノードEN-1はその有料サービス検出機能により、当該パケットの宛先アドレス等の情報から、有料サービスへの接続要求であることを認識する。具体例としては、HTTP要求パケットヘッダのあて先アドレスが、予めエッジノードEN-1が保持している有料サービスサイトの一覧と比較することで、この一覧のいずれかと一致した場合に、有料サービスへの接続要求であると判定する(URLフィルタリング)。
【０２０４】
前提条件で述べたように、エッジノードEN-1は当該ユーザホストMHに関する課金プロファイルを配布されて保持しているから、HTTP要求パケットの検出を契機に、この課金プロファイルを抽出して該パケットに付加してサービス提供ノードXSPN-2に対して送達する。以後、サービス提供ノードおよび、課金制御ノードで課金条件候補が算出され、ユーザホストに提示される。
全体の概略手順を説明すると以下のようになる。
(1)ユーザホストMHは、有料サイトであるXSPN-2にアクセスする。この際、このパケットを経由するエッジノードEN-1は、当該アクセスを検出し、MHの課金プロファイルを抽出し、該課金プロファイルを例えば、同メッセージの終点オプションヘッダに含めてサービス提供ノードXSPN-2に送達する。
【０２０５】
(2) サービス提供ノードXSPN-2は、ユーザホストMNの課金プロファイルを受信すれば、該課金プロファイルを、課金条件整合要求メッセージを使用して課金制御ノードBCNに送達する。
(3) 課金制御ノードBCNは、課金条件を算出し、又、課金条件識別子を生成し、これら課金条件及び課金条件識別子を課金条件整合応答メッセージに含めてサービス提供ノードXSPN-2に返す。
(4)サービス提供ノードXSPN-2は、課金条件識別子を抽出して保持すると共に、課金条件をユーザに提示するためにCGI等でユーザ承認操作画面を生成し、これと課金条件識別子をHTTP応答パケットに含ませてユーザホストMHに送信する。尚、エッジノードEN-1の課金エンジン制御機能部BECFは課金条件識別子を抽出して仮登録する。
【０２０６】
(5)ユーザホストＭＨは提示された課金条件でよければ、承諾をHTTP要求パケットに含ませてサービス提供ノードXSPN-2に送信する。エッジノードEN-1の課金エンジン制御機能部BECFは承諾を検出して課金条件識別子を本登録する。又、サービス提供ノードXSPN-2は課金条件識別子を抽出し、該課金条件識別子を含む課金条件決定メッセージを課金制御ノードBCNに送信する。これにより、課金制御ノードBCNは決定された課金条件を課金条件識別子、移動端末の識別子（NAI）、サービス提供ノードXSPNの識別子等と共に課金条件登録テーブルに記録し、他の候補を消去する。
ついで、サービス提供ノードXSPN-2は課金条件を所定の課金エンジンBENに通知し、ユーザホストMHに決定した課金条件に基づいてサービスを提供する。エッジノードEN-1内の課金エンジンBENは通知された課金条件に従って課金を行なう。
【０２０７】
(d-2) MHとXSPNが同一サブネットに存在する場合
図５３はユーザ端末(ユーザホストMH)とサービス提供サーバXSPN-1が同一サブネット55に存在する場合において、ユーザホストMHが有料サービスを利用する際の課金制御説明図、図５４は課金制御手順図である。図５１の課金制御と異なる点は、ユーザホストMHから有料サービスへの接続要求（MH→XSPN）が、該ユーザホストMHを収容するエッジノードEN-1を経由しない点である。これは、ユーザホストMHとサービス提供サーバXSPN-1が同一サブネット55に位置するためである。
以下において、制御手順を説明するが、前提条件として、課金情報データべース53よりユーザホストMHを収容するエッジノードEN-1へ該ユーザホストの課金プロファイルがダウンロードされて保持されているものとする。
【０２０８】
ユーザホストMHから見たサービス利用手順は、図5の場合と変わらない。すなわち、ユーザホストMHは、利用を希望する有料サービス受付用WEBサイトに対してWWWブラウザのURL指定等によりアクセスする。ユーザホストMHからサービス提供サーバXSPN-1へ送信されたサービス起動要求パケットHTTPの転送経路には、両者が同一サブネット55内に位置するため、ユーザホストMHを収容するエッジノードEN-1が存在しない。すなわち、サービス起動要求パケットHTTPはエッジノードEN-1を経由せず直接サービス提供サーバXSPN-1に到達する。
サービス提供サーバXSPN-1はサービス起動要求パケットを有料サービスの要求と認識するが、図５１の場合と異なり該要求パケットに要求元のユーザホストMHに関する課金プロファイルが含まれていない。
【０２０９】
ついで、サービス提供サーバXSPN-1はユーザホストMHのアドレス等から、要求元MHが同一サブネットワークに位置していると判断し、当該ユーザホストMHの課金プロファイル無しに、課金制御ノードBCNに課金条件整合要求メッセージを発行する。
この課金条件整合要求メッセージは、課金制御ノードBCNに到達する経路において、ユーザホストMHを収容するエッジノードEN-1によって中継される。このとき、エッジノードEN-1は、宛先が課金制御ノードBCNであることを判断して、サービス要求元のユーザホストMNに関する課金プロファイルを抽出し、これを該要求メッセージに付加して課金制御ノードBCNに送出する。以後、図５１の課金制御と同様の制御が行なわれる。
【０２１０】
全体の概略手順を説明すると以下のようになる。
(1)移動ホストMHは、有料サイトであるサービス提供ノードXSPN-1にアクセスする。この際、アクセスで発生するパケットは、エッジノードEN-1を経由せずにサービス提供ノードXSPN-1に到達する。
(2)サービス提供ノードXSPN-1はアクセス要求があれば、課金プロファイルが添付されているか調べ、添付されていなければ、課金プロファイルを含まない課金条件整合要求メッセージを課金制御ノードBCNに送出する。このとき経路上のエッジノードEN-1は、該メッセージの宛先が課金制御ノードBCNであることを判断して、サービス要求元のユーザホストMNに関する課金プロファイルを抽出し、これを該要求メッセージに付加して課金制御ノードBCNに送出する。
【０２１１】
(3) 課金制御ノードBCNは、1以上の課金条件を算出し、又、課金条件識別子を生成し、これら課金条件及び課金条件識別子を課金条件整合応答メッセージに含めてサービス提供ノードXSPN-1に返す。エッジノードEN-1の課金エンジン制御部BECFは課金条件整合応答メッセージに含まれる課金条件識別子を抽出して仮登録する。
(4)サービス提供ノードXSPN-1は、課金条件識別子を抽出して保持すると共に、課金条件をユーザに提示するためにCGI等でユーザ承認操作画面を生成し、これをHTTP応答パケットに含ませてせてユーザホストMHに送信する。
(5)ユーザホストＭＨは提示された課金条件でよければ、承諾をHTTP要求パケットに含ませてサービス提供ノードXSPN-1に送信する。サービス提供ノードXSPN-1は承諾された課金条件の課金条件識別子を含む課金条件決定メッセージを課金制御ノードBCNに送信する。
これにより、エッジノードEN-1の課金エンジン制御部BECFは課金条件識別子を本登録する。また、課金制御ノードBCNは決定された課金条件を課金条件識別子、移動端末の識別子（NAI）、サービス提供ノードXSPNの識別子等と共に課金条件登録テーブルに記録し、他の候補を消去する。
ついで、サービス提供ノードXSPN-1は課金条件を所定の課金エンジンBENに通知し、ユーザホストMHに決定した課金条件に基づいてサービスを提供する。エッジノードEN-1内の課金エンジンBENは通知された課金条件に従って課金を行なう。
以上、第2の課金技術によれば、端末に固有機能の実装を不要とし、固有メッセージの廃止が可能とるなる。又、ユーザのサービス要求は、直接XSPサーバへ到達するため、メッセージ経路は最短になる。又、複数のサービス提供ノードを１台の課金制御ノードで制御することができる。
【０２１２】
(d-3) 課金制御ノードBCNがユーザ課金プロファイルを取得する場合
(d-1)、(d-2)欄で説明した課金条件制御手順(基本方式という)では、エッジノードEN-1の負荷が大きくなる問題(サービス対象となるパケットの検出処理等)がある。そこで、課金制御ノードBCNが課金情報データべース(DB)より直接必要なユーザの課金プロファイルを取得できるようにする。これにより、エッジノードEN-1に以下の2つの機能、すなわち、
▲１▼ユーザ課金プロファイルの保持機能
▲２▼サービス提供ノードXSPNへのユーザ端末からのアクセスを検出して課金プロファイルを付加する機能
が不要となる。
本方式は、上述の基本方式に比べて、エッジノードEN-1の機能が軽減できるが、サービス提供ノードXSPＮに対するサービス起動毎に、課金情報ＤＢへのアクセスが必要となり、課金情報ＤＢへのアクセス負荷が大きいという特性がある。そこで、ユーザのサービス利用時における傾向（同一のXSPNを利用するか、多数のXSPＮを頻繁に使い分けるかかの傾向）及びサービスの普及度によって、本方式と基本方式とを使い分けることで、ネットワーク資源の有効利用を図ることが出来る。
【０２１３】
図５５は課金制御ノードBCNが課金情報DBより直接必要なユーザの課金プロファイルを取得するためのネットワーク構成および、動作シーケンス説明図、図56は、課金プロファイルの受け渡しの際に課金情報DB 53と課金制御ノードＢＣＮとの間で送受されるメッセージ種別説明図である。
課金制御ノードBCNにはユーザ課金プロファイル取得機能部が付加され、課金情報ＤＢ 53にはユーザ課金プロファイル提供機能部が設けられている。
▲１▼ユーザホストMHは、サービス提供を要求するために有料サイトであるサービス提供ノードXSPNにアクセスする。
▲２▼サービス提供ノードXSPNは、ユーザホストMHがアクセスした旨の情報を課金制御ノードBCNに転送する。
▲３▼課金制御ノードBCNは、当該ユーザホストMHのユーザ課金プロファイルを取得するために、課金情報DB 53にコアネットワーク51を介してアクセスする。このときのユーザ課金プロファイルの検索キーの例としては、ユーザホストMHのNAI（Network Access Identifier）あるいはユーザホストMHのIPアドレス等である。
▲４▼課金情報DB ５３は、NAIに基づいて当該ユーザ端末に関する課金プロファイルを抽出して、これを課金制御ノードBCNへの応答メッセージに含めて送信する。
▲５▼課金制御ノードBCNは、ユーザ課金プロファイルとサーバ課金プロファイルを用いて当該ユーザ端末に提供可能な課金条件候補を算出及び生成し、これをサービス提供ノードXSPNに返す。
▲６▼サービス提供ノードXSPNは、課金条件候補をユーザ端末MHに提示して、ユーザ端末の課金条件を決定する。
▲７▼サービス提供ノードXSPNは、決定された課金条件を課金エンジン（ここでは一例としてエッジノードEN-1内にあるとする。）BENに通知し、当該サービスに対する課金機能の動作準備が完了する。以後、サービス提供ノードXSPNとユーザ端末MH間でサービスデータの送受が開始する。
【０２１４】
以上では、課金制御ノードBCNが無条件に課金情報DB ５３よりユーザ課金プロファイルを取得する例であるが、サービス提供ノードXSPNからの課金条件整合要求メッセージにユーザ課金プロファイルが含まれていない場合に課金制御ノードBCNが課金情報DB ５３よりユーザ課金プロファイルを取得するように構成することもできる。図57はかかる場合の処理フローである。
課金制御ノードBCNはサービス提供ノードXSPNから送信される「課金条件整合要求メッセージ」を待っている(ステップ721)。課金制御ノードBCNは課金条件整合要求メッセージを受信する（ステップ722）と、同メッセージ内にユーザ端末のユーザ課金プロファイルが含まれているか判断する(ステップ723)。
課金プロファイルが含まれていれば、基本方式と同一手順に従って課金条件整合処理を実施する(ステップ724)。しかし、課金プロファイルが含まれていなければ、課金制御ノードBCNは自身がユーザ課金プロファイルを課金情報ＤＢ 53から取得する必要があると判断する。課金制御ノードBCNは課金情報ＤＢ 53に対して、「課金プロファイル要求メッセージ」を送出する(ステップ725)。同メッセージは、要求元ユーザを識別するための情報として、NAI を含んでいる。
課金情報ＤＢ 53は、要求されたユーザのNAIに対応するユーザ課金プロファイルを抽出してこれを課金制御ノードBCNに返信する(ステップ726)。
課金制御ノードBCNは、課金情報ＤＢ 53から受領した「課金プロファイル応答メッセージ」の内容を参照して検索結果が正常であるか異常であるかをチェックする(ステップ727)。検索結果が「異常」であれば、たとえば、当該ユーザ端末が、課金条件整合手順の利用者として課金情報ＤＢ 53に登録されていなければ、課金制御ノードBCNはユーザ端末に推奨する課金条件候補を課金条件整合応答メッセージに含める (ステップ728)。この課金条件候補は後でサービス提供ノードXSPNによりユーザ端末に提示されるが、ユーザ端末MHが該課金条件候補を受け入れた場合はその条件でサービス提供することになる。
一方、要求したNAIに対応するユーザの課金プロファイルが検索できれば、当該メッセージフォーマットの正常性を確認のうえ、基本方式と同一の課金条件整合手順を実施する(ステップ724)。以後、課金条件整合応答メッセージを作成してサービス提供ノードXSPNへ送る(ステップ729)。
【０２１５】
(d-4) サービス提供ノードXSPNがユーザ課金プロファイルを取得する場合
(d-3)欄で説明した課金制御手順では、課金制御ノードBCNが課金情報DB 53へアクセスしてユーザ課金プロファイルを取得するのに対して、本方式ではサービス提供ノードXSPNが課金情報DB 53からユーザ課金プロファイルを取得する。
ユーザ端末が送出したサービス提供要求時（サービス提供サーバXSPへのアクセス時）、サービス提供ノードXSPNはユーザ端末の課金プロファイルを課金情報DB 53に対して直接要求する。サービス提供ノードXSPNはこの入手したユーザ課金プロファイルを含む課金条件整合要求メッセージを課金制御ノードBCNへ送信し、課金制御ノードBCNはこのユーザ課金プロファイルとサーバ課金プロファイルを用いて該ユーザ端末に提供するサービスの課金条件整合処理を実施する。以上により、ユーザホストMHを収容するエッジノードEN-1から以下の2点の機能、すなわち、
▲１▼ユーザ課金プロファイルの保持機能
▲２▼サービス提供ノードXSPNへのユーザ端末からのアクセスを検出して課金プロファイルを付加する機能
が不要となる。
本方式は、上述の基本方式に比べて、エッジノードEN-1の機能が軽減できるが、サービス提供ノードXSPＮに対するサービス起動毎に、課金情報ＤＢへのアクセスが必要となり、課金情報ＤＢへのアクセス負荷が大きいという特性がある。そこで、ユーザのサービス利用時における傾向（同一のXSPNを利用するか、多数のXSPＮを頻繁に使い分けるかの傾向）、及びサービスの普及度によって本方式と基本方式とを使い分けることで、ネットワーク資源の有効利用を図ることが出来る。
【０２１６】
図５８はサービス提供ノードXSPＮが情報DB 53より直接必要なユーザ端末の課金プロファイルを取得するためのネットワーク構成および、動作シーケンス説明図、図５９は、課金プロファイル受け渡しの際に課金情報ＤＢ 53とサービス提供ノードXSPＮの間で送受されるメッセージ種別説明図である。サービス提供ノードXSPＮにはユーザ課金プロファイル取得機能部が付加され、課金情報ＤＢ 53にはユーザ課金プロファイル提供機能部が設けられている。
(1)ユーザホストMHは、有料サイトであるサービス提供ノードXSPNにサービス提供を要求するためにアクセスする。このときに、アクセスメッセージ（アプリケーションによって異なるが例えばHTTP要求）には、要求元端末を特定する情報（NAIあるいはユーザホストMHのIPアドレス等）が含まれている必要がある。
(2)サービス提供ノードXSPNは、ユーザ端末MHからのアクセスメッセージ（サービス提供要求メッセージ）を受信すれば、当該ユーザ端末MHの課金プロファイルを課金情報DB 53に要求する。すなわち、サービス提供ノードXSPNは、当該ユーザ端末MHの課金プロファイルを入手するために、課金情報DBにアクセスする。このときの課金プロファイルの検索キーは、ユーザ端末のNAI（Network Access Identifier）である。
(3)課金情報DB 53は、当該ユーザ端末に関する課金プロファイルを抽出して、これをサービス提供ノードXSPNへの応答メッセージ含めて送達する。
(4)サービス提供ノードXSPNは、ユーザ課金プロファイルを受信してこれを課金条件整合要求メッセージに含めて課金制御ノードBCNに送信する。
(5)課金制御ノードBCNは、ユーザ課金プロファイルとサーバ課金ププロファイルとを用いて当該ユーザ端末に提供可能な課金条件候補を算出及び生成し、該課金条件候補を課金条件整合応答メッセージに含めてサービス提供ノードXSPNに返す。
(6)サービス提供ノードXSPNは、課金条件候補をユーザ端末に提示して課金条件を決定する。
(7) サービス提供ノードXSPNは、決定された課金条件を課金エンジン（ここでは一例としてエッジノードEN-1内に存在することとする）に通知し、当該サービスに対する課金機能の動作準備が完了する。以後、サービス提供ノードXSPNとユーザ端末MH間でサービスデータの送受が開始する。
【０２１７】
以上はサービス提供ノードXSPNが、ユーザ端末MHからのサービス提供要求により無条件に課金情報DB よりユーザ課金プロファイルを取得した例であるが、アクセスメッセージ（サービス提供要求メッセージ）にユーザ課金プロファイルが含まれていない場合のみ課金情報DB よりユーザ課金プロファイルを取得するように構成することもできる。図60はかかる場合におけるユーザ課金プロファイルの取得処理フローである。
サービス提供ノードXSPNはユーザ端末ＭＨから送達されるアクセスメッセージ（アプリケーションにより異なる。例えば、HTTP要求）を待っている(ステップ751)。サービス提供ノードXSPNは、アクセスメッセージを受信すれば(ステップ752)、該メッセージ内に当該ユーザ端末に関する「ユーザ課金プロファイル」が含まれているか判断する(ステップ753)。
アクセスメッセージが課金プロファイルを含んでいる場合は、基本方式と同一手順により課金条件整合要求メッセージを作成して課金制御ノードBCNに送信する(ステップ754)。
一方、アクセスメッセージが課金プロファイルを含まない場合、サービス提供ノードXSPN自身が課金情報ＤＢ 53からユーザ課金プロファイルを取得する必要があると判断する。サービス提供ノードXSPNは課金情報DB 53に対して、「課金プロファイル要求メッセージ」を送出する(ステップ755)。同メッセージ内には、要求元ユーザを識別するための情報として、NAI が含まれている。
課金情報ＤＢ 53は、要求されたユーザのNAIに対応する課金プロファイルを抽出してこれをサービス提供ノードXSPNに返信する。サービス提供ノードXSPNは、課金情報ＤＢ 53から受領した「課金プロファイル応答メッセージ」の内容を参照し、検索結果が正常であるか異常であるかチェックする(ステップ757)。検索結果が「正常」であればステップ754の処理を行い、「異常」を示せば、たとえば、当該ユーザ端末が課金条件整合手順の利用者として、課金情報ＤＢ 53に登録されていなければ、推奨するユーザ課金プロファイルを作成し(ステップ758)、基本方式と同一手順により課金条件整合要求メッセージを作成して課金制御ノードBCNに送信する(ステップ754)。以後の処理は基本方式と同じである。
【０２１８】
(d-5)課金情報DBの処理
図61はユーザ課金プロファイルが要求された時の課金情報DBの処理フローである。課金情報DBに対して課金プロファイルを要求する装置（XSPNおよびBCN）を「要求元装置」と呼ぶ。
課金情報データベース（DB）53に内蔵されるメッセージ制御機能部は、要求元装置が送信した課金プロファイル要求メッセージを受信し、これを解析して要求元装置が要求したユーザ課金プロファイルをデータベースから抽出して課金プロファイル応答メッセージに含めて要求元装置に返信する。なお、メッセージ制御機能部は必ずしも課金情報ＤＢと同一装置に内蔵する必要はない。
詳細に説明すると、課金情報ＤＢ 53のメッセージ制御機能部は、要求元装置からの課金プロファイル要求メッセージの待ち状態にある(ステップ771)。何らかのメッセージを受信すれば、メッセージ制御機能部は、メッセージフォーマットが「課金プロファイル要求メッセージ」であるかチェックし(ステップ772)、課金プロファイル要求メッセージでなければ、パラメータ値として検索結果＝「異常」、理由値＝「メッセージフォーマット異常」を応答メッセージに設定して返信する(ステップ773)。
一方、メッセージフォーマットが「課金プロファイル要求メッセージ」であれば、メッセージ制御機能部は、当該メッセージに含まれるユーザ識別情報（NAI）を抽出する(ステップ774)。ついで、抽出したNAIを検索キーとして、課金情報DB本体部53aに検索要求する。検索により当該ユーザ端末の課金プロファイルが見つかったかチェックし(ステップ776)、見つからない場合には、パラメタ値として検索結果＝「異常」、理由値＝「当該ユーザ端末の登録無し」を応答メッセージに設定して要求元装置に返信する(ステップ777)。
一方、当該ユーザ端末の課金プロファイルが検索された場合には、パラメタ値として検索結果＝「正常」を応答メッセージに設定する(ステップ778)。ついで、課金プロファイルを含む課金プロファイル応答メッセージを作成し(ステップ779)、該課金プロファイル応答メッセージを要求元装置に送信する(ステップ780)。
【０２１９】
（ｅ）課金条件生成応答機能
課金制御ノードBCNは課金条件整合要求メッセージをサービス提供ノードXSPNより受信すれば、課金条件を生成して応答する必要がある。課金条件整合要求メッセージは、サービス要求元MHのユーザ課金プロファイルを含んでいる。課金制御ノードBCNは、受信したユーザ課金プロファイルを、BCN内部で管理するサービス提供者側の課金プロファイルとの照合を試みる。この照合の結果、１つ以上の提供可能なサービス提供条件(課金条件)が成立すれば、各々の課金条件候補に対して一意の識別子を付与し、これら候補の条件を要求元のサービス提供ノードXSPNに返信する。
【０２２０】
この時点において課金制御ノードBCNは、未確定である課金条件候補を１つ以上持つ。又、これら課金条件候補に、課金条件整合要求メッセージがどのサービス提供サーバXSPNから発せられたものかを識別するために、サービス提供ノードXSPNの識別情報と課金条件識別子とを連携させて内部テーブルに保持する。この識別情報により、１つのサービスを複数のサーバで分散配置の形式にて提供する場合、現在サービス提供中のXSPNを把握することが可能になる。
課金条件整合処理終了後、生成した課金条件データ群および各々に対応する課金条件識別子を課金条件整合応答メッセージに含めてサービス提供サーバXSPNに送信する。
【０２２１】
(e-1)ユーザ課金プロファイルの定義例
図6２にユーザ課金プロファイルの基本構成例を示す。本ユーザ課金プロファイルの特徴は以下の通りである。
(1)ユーザ課金プロファイルは、課金条件とそれに対応する値を一組としてこれを必要な数だけまとめたデータのセットである。
(2) 課金プロファイルの条件文の表現形式は、代行課金するキャリアとサービス提供するサービス提供サーバXSPの２者の間で共通化される。さらに、キャリア間で連携する場合はキャリアの間で共通化される。
(3)課金プロファイルの比較内容は図6２の3種類(基本部、サービス依存部、XSP独自定義部)に分類される。
【０２２２】
具体的な課金プロファイルの条件記述を図6３に示す。この例では、条件ID:000〜004が「基本部」、005〜010が「サービス依存部」、011がXSP独自定義部なっている。基本部は、事業者コード、アプリケーションタイプ、XSP事業者識別コード、サービス名称、優先される条件、を特定する。サービス依存部は、サービス提供時の伝送品質、時間、課金対象、課金単位、課金積算額上限、優先パラメータ、を特定する。個別定義部は、コンテンツ配信方法などXSP独自に定義する部分である。
【０２２３】
(e-2)サーバ課金プロファイルの定義例
図6４はサーバ課金プロファイルの基本構造例であり、１つのサービス提供サーバXSPは図より明らかなように自社が提供しているサービス内容単位に課金プロファイルを用意している。ユーザ側からサービス開始要求にあたって提示される「ユーザ課金プロファイル」は、サービス提供サーバXSPの持つ複数サービスの課金プロファイルと照合され、所定のサーバ課金プロファイルが候補課金条件として検出される。サーバ課金プロファイルは図6３のユーザ課金プロファイルと類似した構成を持っている。異なる点は、(1)条件の合致状態を規定する「条件式」を特定できる点である。これにより、完全一致、もしくは一定範囲等の合致を判定する条件式、閾値を規定することができる。もう1つの異なる点は、(2)サービス提供者側が「XSP指定値」により課金条件の各項目の具体的な数値、時刻等を指定できる点である。
【０２２４】
(e-3)課金条件整合手順の一例
図6５は課金条件整合手順を示す処理フローである。課金条件整合手順は、一般にサービス提供ノードXSPN毎に個別であり、一意には存在しない。しかし、ここでは一般的な手順を実施例として説明する。
ユーザ課金プロファイルが入力されると、課金制御ノードBCNはサーバ課金プロファイルのサービス種別IDを１に初期化し(ｎ＝１、ステップ801)、ついで、比較対照のユーザ課金プロファイルの条件IDを１に初期化する(ｍ＝１、ステップ802)。ついで、ユーザ課金プロファイルの第m条件項目の内容と、サービス種別ＩＤ＝ｎのサーバ課金プロファイルの第m条件項目の内容を比較する(ステップ803)。当該第m条件において条件が完全に一致するかチェックし(ステップ804)、完全一致すれば第m条件の評価値を0にする(ステップ805)。しかし、完全一致しなければ、代替可能な条件、もしくはサービス提供ノードXSPNが推奨する候補があるかチェックし(ステップ806)、YESであれば第m条件の評価値を所定値に設定する(ステップ807)。しかし、NOであれば、サーバ側の最小限の基本条件を推奨条件として抽出して出力し(ステップ808)、処理を終了する。
【０２２５】
ステップ805,807の処理後、第m条件における評価値を確定して保管すると共に(ステップ809)、全ての条件IDについて比較が完了したかチェックし(ステップ810)、「NO」であればmを歩進して(ステップ811)、ステップ803以降の処理を繰り返す。
ステップ810において、全ての条件IDについて比較が完了していれば、全サービス種別IDのサーバ課金プロファイルについて照合処理を完了したかチェックし(ステップ812)、照合処理の済んでいないサーバ課金プロファイルが存在すれば、ｎを歩進し(ステップステップ813)、ステップ802以降の処理を繰り返す。一方、ステップ812において、全てのサービス種別IDについて比較処理を終了すれば、記憶してある条件整合結果の評価値の合計を各サービス種別ID毎に計算し(ステップ814)、評価値の高い順に課金条件の候補を選出する。尚、選出数はサービス提供ノードXSPNから個々に指定される。
【０２２６】
以後、各課金条件候補の課金条件識別子を作成し、該課金条件識別子及び課金条件を含む課金条件整合応答メッセージを作成し、該メッセージをサービス提供ノードXSPNに送出する。
課金条件整合処理の一例として、図6６の(a)〜(b)にユーザ課金プロファイルとサーバ課金プロファイルの例を示し、図67の(a)〜(b)に比較結果及びユーザに提示される課金条件の候補例を示す。本発明の第2課金技術における課金条件整合処理の特徴は、ユーザ、サーバの課金プロファイルの各条件について、両者の一致／不一致の照合結果を数値で表現し、総合評価値に基いてサーバ側、ユーザ側両者の希望に沿った課金条件候補を選出し、ユーザに対して提示する点である。
【０２２７】
課金条件整合処理の別の例として、図6８、図69にユーザ課金プロファイルとサーバ課金プロファイルの例を示し、図７０にユーザに提示される課金条件の候補例を示す。この例はストリーミングで下り方向の帯域確保を利用する場合である。またXSP事業者識別コードは一致しているため、サービス提供サーバXSPはB社となる。
具体的な課金条件決定の手順を以下に示す。
(1)課金制御部BCNは課金条件整合プログラムに従って、ユーザ課金プロファイル(図68)とサーバ課金プロファイル(図69)の条件ID 000〜0004を比較する。
▲１▼ユーザが指定する事業者コード(A社)はサーバの指定する対応キャリア(A社、C社)に含まれているので、提供キャリアはユーザの指定したA社となる。
▲２▼優先条件はユーザ指定とサーバ指定で異なるので、次のサービスの比較時に考慮される。
(2)ついで、課金制御部BCNは課金条件整合プログラムに従って、ユーザ課金プロファイルとサーバ課金プロファイルの条件ID 005〜010を比較する。
▲１▼ユーザが料金条件(低額)優先としているので、以下料金条件を前提として処理する。
▲２▼ユーザの課金単位の指定は0.0001円/パケットなので、評価値は
0.0001円/パケット： 0
0.0003円/パケット： −1
0.001 円/パケット： −2
とする。
なお１パケットを128バイトとして換算してもよい。即ち例えば1280バケットは10パケットとして課金してもよい。
▲３▼ユーザの伝送品質の指定は1Mbpsなので、評価値は
300Kbps： −1
1Mbps： 0
3Mbps： 0 (指定品質以上のため)
とする。
▲４▼他の項目はユーザ指定・サーバ指定とも一致している。
（3）最後に、料金条件と伝送品質の全組み合わせについてポイントを集計し、まず優先する条件を満たすものから推奨条件として提示する(図70参照)。それ以降の条件は、ポイントが高いものから表示する。
【０２２８】
課金制御ノードBCNは課金条件整合プログラムに従って、ユーザ課金プロファイル(図6６の(a))とサーバ課金プロファイル(図6６の(b))の対応する各条件を個々に比較する。サービスの比較に際してはサーバ課金プロファイルが規定する全ての条件に対して、ユーザ課金プロファイルの該当する条件を参照する。すなわち、図6６の(a)におけるユーザ課金プロファイルの条件U1, U2, U3と図6６の(b)におけるサーバ課金プロファイルのS1, S2, S3を各々比較する。
比較の結果、ユーザ課金プロファイルの指定値とサーバ課金プロファイルの条件が一意に一致した場合は、その結果を数値の０として評価する。この数値を条件整合の「評価値」とする。一方、両者が一致しなかった項目の評価値として、ユーザ課金プロファイルの値に対して近い（もしくはXSPが推奨する）ものから順に、０より小さい数値として −i, −j, −k, …（例：−1、−2、−3）が与えられる。なお、 i, j, k の数列は、サービス提供者XSPの戦略によって決定され、この値付けが料金上の特徴の一つとなりうる。上記比較結果を図67の(ａ)に示す。
【０２２９】
サーバ課金プロファイルの全条件についての比較が完了し、条件毎の比較結果が出ると課金制御ノードBCNは、ユーザの要望と自社の戦略を加味して最も適切と思われる課金条件を導く。具体的には、前出の整合評価値が最も高い課金条件（およびそれに次ぐ幾つかの課金条件）をユーザに対して提示する。具体的には図67の(a)に基づいて、ユーザおよびサービス提供ノードXSPN双方の条件の整合結果として図67の(b)の内容がユーザに提示される。図67の(b)は、ユーザ課金プロファイルの条件に完全には一致しないが、ユーザとXSP双方の希望を点数化し、提供可能な条件を提示している。
【０２３０】
（ｆ）課金プロファイルの準備機能
有料サービス起動の際に、ユーザホストMHを収容するエッジノード上で参照されるユーザ課金プロファイルは、原本を管理元のAAAサーバ52からMHのホスト認証を契機にサービスプロファイルなど共にダウンロードされる。認証時におけるこれらプロファイルのダウンロード手順は図49に従って説明済みである。ユーザホストMHのユーザ課金プロファイルの例を図７１に示す。
【０２３１】
MH課金プロファイルにおいて、ユーザホストMHを識別する情報としては各種考えられるが、一例としてIETFで規定されるNAI（Network Access Identifier）を利用し、一意にユーザホストを識別する。一般的に、IPネットワーク上で端末を識別可能な情報としてIPアドレスがあるが、IPｖ６においては、プラグアンドプレイの思想により、ネットワーク接続の度にIPアドレスを自動構成して付与するため、接続の度に異なるアドレス値となり、定常的にホストを識別する手段としては利用できない。このため、本発明における課金プロファイルにおける端末識別情報として固定で割り当てられるNAIを利用する。ただし、端末固定に一意に付与される情報であればNAIに限定しない。
【０２３２】
上述のように、個々のホストアドレスは、ネットワーク接続毎に与えられるが、課金対象のパケット等を検出する課金エンジンは課金対象ホストをIPアドレスにより認識する。一方、課金制御ノードBCNにおける課金条件の整合判定処理では、ユーザホストMHを定常的に変化しないNAIで表現することが必要である。これは、同一ホストが同一課金制御ノードBCNの管理下にある別のサービス提供ノードXSPNに移動して（新たに異なるアドレス付与を受け）、移動前のサービス提供ノードXSPN経由で一旦合意された課金条件を引き続き利用する為に必要である。
以上のように課金プロファイルにおけるホストの表現形式としては、ネットワーク内のAAAサーバで管理されている状態ではNAI等の固定値で表現されるが、課金制御手順においては、IPアドレス情報も必要となる。よって、課金プロファイルがエッジノードENにダウンロードされると同時に、該エッジノードENはユーザホストMHが現在付与されているIPアドレス情報を取得して図７１に示すように前記課金プロファイルに付与して管理する。尚、ユーザ課金プロファイルは、サービス毎に課金条件AAA, BBB, CCCを含んでいる。
【０２３３】
図７２はエッジノードによるユーザ課金プロファイル格納手順処理フローである。
ユーザホストMHはアクセスネットワーク55に接続されると、エッジノードEN-1にアドレス割手要求を出す。これにより、エッジノードEN-1はアドレスを割り当てると共にアドレス認証をAAAサーバ52に要求する。AAAサーバ52は認証要求によりユーザホストの認証処理を実行すると共に、ユーザホストMHの課金プロファイルを課金情報データべース53より読み取って認証応答パケットに付加してエッジノードEN-1に返す。エッジノードEN-1は認証応答パケットの受信を待ち(ステップ901)、該メッセージを受信すれば、認証応答がOKであるかNGであるかをチェックし(ステップ902)、OKであれば該メッセージ内にユーザホストＭＨに関する課金プロファイルが含まれているから、認証終了と同時にユーザ課金プロファイルを保存すると共に該ユーザプロファイルに対する認証セッションの監視タイマを起動させる (ステップ90３)。ついで、ユーザホストMHのIPアドレスをユーザ課金プロファイルに追加する。一方。ステップ902において、NGであればパケットを破棄し(ステップ90５)、以後、次のパケット受信待ちになる。
【０２３４】
（ｇ）課金条件識別子の管理機能
生成された課金条件には課金条件識別子が付与されるが、この識別子はユーザ、サービス提供業者間で合意された課金条件データの参照キーとなるだけでなく、サービス提供中に、一定周期でサービス利用継続の意思確認の為に課金制御ノードBCNに対して送信される。課金制御ノードBCNは課金条件識別子を受信すれば、該識別子を参照してユーザがサービス利用中であることを確認してサービスを継続する。言い換えれば、課金条件識別子は伝票番号に似た機能を持つ。
ユーザホストMHを収容するエッジノードEN-1は、サービスを受けるユーザホストMHに替わって課金条件識別子を代行保管する。これにより、ユーザホストMHに固有機能を具備させることなく、サービス中の課金条件データの維持管理が可能となる。
【０２３５】
本発明の第1課金技術では、サービス中の課金セッションを維持する手段として、課金条件識別子を端末に保存させていたが、第２課金技術では該識別子をネットワーク内（端末を収容するエッジノード）で管理しながら、端末と該識別子を関連付けることで課金セッションの認識を可能としている（図４６参照）。
図７３はエッジノードEN内の課金条件識別子管理テーブル例、図７４はエッジノードENによる課金条件識別子の管理処理フローである。課金条件識別子管理テーブルにおいて、課金条件識別子の候補群毎に付与されるグループ識別子、個々の課金条件を一意に示す課金条件識別子、仮登録中／利用中／その他の状態を示す課金状態フラグ、残有効期間が管理される。
【０２３６】
図７４においてエッジノードENはパケット（課金制御関連メッセージ）受信待ち状態にあり(ステップ1000)、この状態でパケットを受信すれば、受信メッセージの種別(メッセージタイプ1〜3)を識別し(ステップ1011,1021,1031)、該メッセージタイプに応じて以下の動作を行う。
メッセージタイプ１は、課金制御ノードBCNで整合された課金条件データの候補群をユーザに選択させるためのWEB画面ページを構成するhttpプロトコルメッセージである。このメッセージパケットには、課金条件候補群に応じた課金条件識別子群が記入されたIPv6オプションヘッダが含まれている。エッジノードENはこのhttpプロトコルメッセージをユーザホストMHに転送する際、このオプションヘッダを取り出し(ステップ1012)、エッジノードEN内部で保持している課金条件識別子管理テーブル（図７３）に格納する(ステップ1013)。このとき、課金条件識別子は全ての候補が格納される。ただし、格納される個々の課金条件識別子には管理状態フラグがあり、この時点では該フラグを「仮登録」とする(ステップ1014)。しかる後、エッジノードはユーザによる候補選択結果（後述のメッセージタイプ３）を待つ状態となる(ステップ1015)。
【０２３７】
メッセージタイプ２は、課金制御ノードBCNで整合された料金条件が単一であり、ユーザに選択の余地がない場合、あるいはユーザに対して確認を必要としない場合のメッセージである。かかる場合、サービス提供ノードXSPNからエッジノードENに対して、課金条件が一意に決定されたことを示す「課金条件決定通知」メッセージが送達される。このメッセージはメッセージタイプ１と同様に、IPv6オプションヘッダを含むが、ただ1つの課金条件識別子が記入されているだけである。エッジノードＥＮは課金条件決定通知メッセージを受信すれば、課金条件識別子を抽出し(ステップ1022)、EN内部の識別子管理テーブルに格納し(ステップ1023)、状態を「利用中」とする(ステップ1024)。利用中とは、この条件に基づく課金サービスが提供されていることを示す。以後、別のパケット受信待ちになる。
【０２３８】
メッセージタイプ３は、同図のメッセージタイプ１によってユーザに提示された複数条件候補から所望の１つを決定する際に、ユーザホストMHからサービス提供ノードXSPN (兼Webサーバ) に向けて送達されるhttp応答メッセージである。エッジノードENはこのメッセージをサービス提供ノードXSPNに転送する際、httpプロトコルメッセージの内容から、ユーザが選択した候補の課金条件識別子を判定する(ステップ1032)。しかる後、エッジノードENは該選択された候補の識別子管理テーブル(図７３)における管理状態を「仮登録」から「利用中」に変更すると同時に、選択されなかった候補を管理テーブルから削除する(ステップ1033)。以後、別のパケット受信待ちになる。
【０２３９】
（ｈ）ユーザ端末の課金条件承認
本発明が対象とする有料サービスの課金条件整合手順では、必要に応じて、課金制御ノードＢＣＮで生成された提供可能な複数の課金条件候補をユーザホスト（MH）に対して提示して選択させることを可能としている。この課金条件候補の提示に対してユーザホストMHはどの課金条件候補を採用するか決定して応答しなければならない。具体例としては、ユーザホストMHからのサービス提供要求がWWW（HTTP）によるアクセスであった場合、サービス提供ノードXSPNは、課金条件呈示用画面のWEBページを動的に生成し、これをユーザホストMHからの有料サービス起動要求に関する応答として送付する。これを受信したユーザホストMHは自ホストのWWWブラウザ画面上にて、提示されたサービス提供条件を検討して応答(承認)を返す。
【０２４０】
図７５はユーザ端末に課金条件承認を行なわせる際のサービス提供ノードXSPNの処理フローである。
課金制御ノードBCNにおいて候補となる課金条件データが生成され、これをユーザホスト（MH）に対して提示し、ユーザの選択を待つ手順である。
サービス提供ノードXSPNは、課金制御ノードBCNからユーザホストMHに関する課金条件候補が課金条件整合応答メッセージにより送付されるのを待つ(ステップ1101)。課金条件整合応答メッセージを受信すると(ステップ1102)、該メッセージに付与されている課金条件識別子を抽出すると共に(ステップ1103)、課金条件候補をサービス要求元に送付準備する。すなわち、ユーザホストMHのサービス提供ノードXSPNに対するアクセス手段（例：携帯電話I-mode-TEXT、パソコンWebブラウザ、他のコマンドライン）を認識し(ステップ1104)、このインタフェース種別によりユーザホストMHに対する応答メッセージを編集する(ステップ1105〜1107)。例えば、携帯電話I-mode-TEXTでアクセスした場合には、携帯電話番号ボタンとサービス条件識別子を連携させたTEXTを作成し、又、Webブラウザでアクセスした場合には、CGIによる動的に条件承諾用のWEBページを作成する。しかる後、作成したTEXTあるいはWEBページを含むパケットをユーザホストMHに送達し(ステップ1108〜1110)、ユーザからの承認パケットの受信待ちになる(ステップ1111)。
【０２４１】
（ｉ）第1のサービス継続確認
有料サービスの料金条件交渉が成立し、サービス提供中の状態において、ユーザホストMHの電源切断（電池切れ等）もしくは、圏外への移動等、ユーザホストMHの使用者が意図しない形で、サービスが受けられない状況が発生する。具体例としては、ストリーミング等の放送型アプリケーションがある。この種のネットワーク側から一方的に放送形式で提供されるようなサービスにおいては、ネットワーク内で課金処理（該当パケットをカウントするなど）されている。このため、ユーザホストMHが課金対象データを受信できるか否かに関わらずデータパケットを送信しつづけることになり、本来受けていないサービス分にまで課金される問題がある。
【０２４２】
このため、ユーザホストMH自身による応答により、サービス提供中において、一定周期でサービスを受けているか（課金対象パケットを受信しているか否か）を確認する手段が必要である。具体的には、ユーザホストＭＨは、ネットワーク接続時の認証機構を利用して認証の有効期限（認証セッション期間）が設定されており、一定周期において認証登録を繰り返している。
この周期的な認証登録がエッジノードEN-1で確認がなされた際に、エッジノードEN-1は当該ユーザホストMHのサービス継続意思があると判断して、引き続き当該条件におけるサービス提供を継続する。一方、前述のユーザホストＭＨの電源もしくはネットワーク接続切断、他のネットワークへの移動等により、認証セッションが更新されない場合、当該ユーザホストＭＨを収容するエッジノードEN-1は、サービスの中断が必要と判断して、課金エンジンに対して当該ユーザホストＭＨに関する課金動作を停止させる。
【０２４３】
図７６はサービス継続確認説明図、図７７はホスト認証（セッション時間との連携）に基づくサービス確認手順の例である。
(1)ユーザホストMHは、移動に伴いホスト認証を行う。認証には有効期限（セッション期間：life time）があり、ユーザホストMHは周期的に認証を行っている。
(2)エッジノードEN-1は、ユーザホストMHからの周期的な認証要求を契機に、課金プロファイルのlifetimeを更新すると共に、課金制御ノードBCNに対して課金条件識別子を含むサービス状態更新の要求メッセージを送出する。一方、エッジノードEN-1は、保有する課金プロファイルのlifetimeを監視しており、これがタイムアウトすれば、ユーザホストMHがサービス受信不可状態にあると判断し、課金制御ノードBCNへ課金条件識別子を含む状態変更(中断)の要求メッセージを送出する。
(3)課金制御ノードBCNはエッジノードEN-1からサービス状態更新要求が周期的に通知されるとこれを契機に、該当する課金条件のlifetimeを更新する。また、、課金制御ノードBCNは中断状態への状態変更要求を受信すれば、課金サーバ及びサービス提供ノードXSPN-1にサービス中断を通知する。
【０２４４】
（ｊ）第２のサービス継続確認
ユーザホストMHが、ある時点で明示的に利用中の有料サービスの中断を希望する場合がある。この場合、ユーザホストＭＨの所定の操作により即座に課金セッションが中断され、課金対象パケットの積算を終了しなければならない。そこで、本発明では、ユーザホストMHからサービス提供ノードXSPNの所定のアドレス（URL等）にアクセスすることで、当該課金セッションを直ちに終了せる。
第1のサービス継続確認との差異は、ユーザの明示的なサービス（課金セッション）終了である。第1課金技術では、端末が送出するMobile IP位置登録メッセージに課金条件識別子などの個別情報を挿入する機能が必要とされたが、第2課金技術ではサービスの受付を行うフロントエンドサーバ（例: wwwサーバ）にアクセスし所定の操作によって、サービス提供ノードXSPNがサービス終了を認識するもので、汎用プロトコルのみで実現できる。
【０２４５】
図７８は実行中課金サービスのユーザ起動による動作停止処理説明図、図７９は実行中課金サービスのユーザ起動による動作停止手順である。
(1)ユーザホストMHは、サービスを中止するために、サービス提供中のサービス提供ノードXSPN-1のサービス変更ページにWebアクセスする。
(2) これによりサービス提供ノードXSPN-1は、対象ユーザの課金条件識別子を抽出し、中断確認をユーザに提示するための承認画面をCGI等で生成してユーザホストMHに返す。
(3)ユーザホストMHは中止を選択し、サービス提供ノードXSPN-1に通知する。
(4) これによりサービス提供ノードXSPN-1は、課金エンジンBENに課金中止を通知し、ユーザホストMHへのサービスを中止する。
(5) サービス提供ノードXSPN-1は、課金制御ノードBCNに状態変更(中止)を通知し、登録データの削除を促す。また、エッジノードEN-1は同メッセージを検出し、課金条件識別子管理テーブルより識別子を削除すると共に、ユーザホストMHの課金条件データを削除する。
【０２４６】
（ｋ）実行中の条件再設定
実行中の課金サービスに対して、ユーザの必要に応じてサービスを一旦終了することなく課金条件を再設定する手段が必要になる。具体的には、一旦契約が成立し、提供が開始されたサービス品質に不満があり、より良い品質のサービス条件への移行をユーザホストMHが希望する場合である。このため、本発明では、ユーザホストMHからの要求により再度課金条件を設定すると共に、課金制御ノードBCN, サービス提供ノードXSPN双方にユーザホストMHの料金条件を再交渉する過程のデータ群を一時的に保持するバッファ装置を用意する。料金条件の再交渉の結果、ユーザホストMHが新たな料金条件によるサービス提供を受諾すればこの課金条件データを、現在提供中のものと即座に入れ替える。
【０２４７】
図８０はユーザの意思によりサービス実行中に課金条件を変更する場合の課金条件再設定説明図、図８１はサービス実行中に課金条件を変更する場合の課金条件再設定手順である。
(1)ユーザホストMHは、より良い品質のサービス条件への移行をするために、サービス提供中のサービス提供ノードXSPN-1のサービス変更ページにWebアクセスする。
(2) サービス提供ノードXSPN-1は、当該ユーザホストＭＨの料金条件を再交渉する過程のデータ群を一時的に保持するバッファ装置を持っている。サービス提供ノードXSPN-1は、該データ群を参照してユーザのサービス変更画面を動的に作成する。この処理は課金制御ノードBCNから課金条件整合応答を受信したときの処理と同じである。サービス提供ノードXSPN-1は、料金条件をユーザに提示するため、CGI等で生成した承認画面をMHに返す。
(3)MHは条件を選択し、サービス提供ノードXSPN-1に通知する。
(4) サービス提供ノードXSPN-1は、変更された課金条件を課金制御ノードBCNに通知し、課金制御ノードBCNは課金条件登録テーブルに記憶してある課金条件データを更新する。また、エッジノードEN-1の課金装置制御機能部BECFは課金制御ノードBCNへの通知メッセージを検出し、新課金条件に応じた課金条件識別子を本登録する。
(5)以後、サービス提供ノードXSPN-1は課金エンジンBENに新課金条件を通知し、ユーザホストMHに新課金条件に従ってサービスを提供する。また、課金エンジンBENは新課金条件に従って課金する。
【０２４８】
（ｍ）複数XSP間の移動制御
ネットワーク経由で各種のコンテンツ、サービスを提供する業態には、単一のサーバにて１サービスを構成する基本的なものの他に、地域単位など、複数サーバに分割されたコンテンツを提供し、このサーバ群で１つのサービスを構成する業態がある。具体例としては、ネットワーク経由で地図情報を配信するサービスなどである。この種のサービスの提供形態としては、各地に分散されたサービス提供ノードXSPNを課金制御ノードBCN１台で集中的に管理する形態がある。この形態をとる理由として、地図等のコンテンツデータのサイズは、課金制御メッセージのサイズと比較して一般的に大きいと想定される。このため、地図等のデータサイズの大きいコンテンツは地域的に分散され、ユーザホストMHの常に近隣に位置するほうが応答速度およびネットワークトラヒック、コンテンツサーバへの負荷軽減等の点で望ましい。
【０２４９】
図８２は同一ユーザが移動に従って複数のサービス提供ノードXSPN-1、XSPN-2より同一サービスを連続して受ける場合の課金条件設定説明図、図73は課金条件設定手順である。この課金条件設定手順は、一つのサービスを複数のサービス提供ノードXSPNより提供するサービス形態を例として、ユーザホストＭＨが最初に課金条件を確定したサービス提供ノードXSPN-2配下から、別サブネットへ移動し、同様のサービスを移動先サブネットに帰属するサービス提供ノードXSPN-1から受ける場合に、最初のサービス提供ノードXSPN-2で合意された課金条件を移動先のサービス提供ノードXSPN-1でも（通常の料金条件交渉を経ることなく）適用するための手順である。
【０２５０】
(1)ユーザホストMHは有料サービスを受けていたサブネットワーク56から、別のサブネットワーク55に移動すると、ネットワーク接続手順(図４９参照)を起動する。AAAサーバ52はホスト認証が成功すると、認証応答にユーザホストMHの課金プロファイルを付してエッジノードEN-1に送付し、該エッジノードEN-1はユーザホストMHの課金プロファイルを格納する。また、同時にエッジノードEN-1は、当該ユーザホストMHが取得したIPアドレスを保持している課金プロファイルに記入する。
(2)ついで、ユーザホストMHは、ユーザ手動もしくはアプリケーション自動処理によって、移動後のサブネット55において、移動前と同一のサービスを提供しているサービス提供ノードXSPN-1にURL等にてアクセスする。
(3)アクセスを受けたサービス提供ノードXSPN-1は、図５２又は図５４に示す手順に従い、連携する課金制御ノードBCNに対して課金条件整合要求を送出する。この動作は当該サービス提供ノードXSPN-1に最初にアクセスする場合と同一である。
(4)課金条件整合要求を受けた課金制御ノードBCNは課金条件登録テーブルを参照して、当該ユーザホストMHが既に他のサブネットに在圏中にサービス提供ノードXSPN-2と当該サービスについて課金条件を交渉済みであることを認識する。この場合、当該課金セッションが有効期限内なら、すでに、課金制御ノードBCN内に保持されている課金条件を利用する。よってこの場合課金条件整合処理は起動されない。
【０２５１】
(5) 課金制御ノードBCNは、すでに旧サービス提供ノードXSPN-2との間で合意された課金条件を前記課金条件整合要求メッセージに対する応答メッセージに含めて新サービス提供ノードXSPN-1に送信する。同時に、課金制御ノードBCNは課金条件登録テーブルに登録されている課金情報に含まれているXSPN識別情報を、新サービス提供ノードXSPN-1の識別情報に書き換える。
(6)応答メッセージを受けた新サービス提供ノードXSPN-1は、通常のユーザホストに対する課金条件の確認手順を省略して、当該課金条件によるサービス提供を開始する。なお、新サービス提供ノードXSPN-1又は課金制御ノードBCNは、課金条件を新課金エンジンに通知して課金を行なわせる。
以上により、端末移動時によりIPv6アドレスが変わる場合でも、課金制御ノードBCNが当該端末のセッション情報を集中的に管理することで、端末が別のエッジノードに移動してIPアドレスが変更された場合でもセッション情報を維持することができる。また、網内で一括して課金セッションの管理を行うため、導入容易性の確保と、複数サーバで１サービスを提供する形態に適している。
【０２５２】
（ｎ）ネットワーク側からの課金条件変更
ユーザホストMHとサービス提供ノードXSPNの間で合意された料金条件においてサービス提供中に、サービス提供者（XSPN、BCN）側の運用方針によりネットワーク側から課金条件を変更する場合がある。具体的には時間帯により課金条件が変更される様な場合である。
上記の変更要求はユーザホストMHやサービス提供ノードXSPNではなく、課金制御ノードBCNから起動される。課金制御ノードBCNは、すでに提供中のサービスに関して課金条件(課金プロファイル)を保持しているが、この中に時刻等のパラメタを含んでいる場合には時間帯による課金条件の変化を検出し、課金条件を変更する。
【０２５３】
図８４はネットワーク側からの課金条件変更説明図、図８５は課金条件変更手順絶図である。
(1) 課金制御ノードBCNは、保持している課金プロファイルに関する課金条件が、時刻条件等により変更が必要となった場合、自律的にユーザホストMHに関する課金条件を再計算してサービス条件変更要求メッセージを作成し、該メッセージをサービス提供ノードXSPN-1に送付する。
(2) サービス条件変更要求メッセージを受信したサービス提供ノードXSPN-1は、ユーザホストＭＨに対してhttpパケットで課金条件変更を通知し、ユーザホストから承諾のhttpパケットを受信すれば、以後、新たな課金条件に従ってサービスを提供する。
(3)また、サービス提供に先立って課金制御ノードBCNあるいはサービス提供ノードXSPNは、エッジノードEN-1内の課金エンジンに変更後の課金条件通知し、課金エンジンは通知された新たな課金条件に従って課金を行なう。
【０２５４】
本機能は、時刻等の条件によりダイナミックに条件を変更し、これを反映させることを可能としている。IPv4/ Mobile IPをベースとした第1課金技術では、課金条件の鍵となる課金条件識別子を端末にまで送達する必要があるため、ネットワーク処理上で制約となる。IPv6をべースとした第2の課金技術では課金条件識別子の配布範囲がコアネットワーク内部のみであるため、より軽い負荷で動作可能である。
【０２５５】
（ｏ）確定済み課金条件の課金エンジンへの送付
課金条件は課金制御ノードBCNにより生成され、サービス提供ノードXSPNに送達される。課金条件の最終的な用途は、これをネットワーク内に配備された課金エンジンBEN（パケット流量等のネットワーク資源監視機能）に送達し、課金動作時のパラメタとして参照、解釈して課金動作を行なえるようにすることである。課金条件を課金エンジンBENに送付するために各部は以下の機能を備えている。
(1)課金制御ノード（サービス提供業者）BCNは、ネットワーク運用者(キャリア)との契約により、提供される課金手段のパラメタの一つとして、利用可能な課金エンジンを指定することができる。
(2) 課金制御ノードBCNにより生成された課金条件データは、課金条件整合応答メッセージによりサービスをユーザホストMHに提供するサービス提供ノードXSPNに送達される。
【０２５６】
(3) サービス提供ノードXSPNは、課金条件整合応答メッセージに含まれる、課金条件データより課金エンジンIDを参照して、当該サービスの課金ポイントを認識する。
(4) サービス提供ノードXSPNは、ユーザホストMHとの交渉で課金条件が決定されると前記課金エンジンIDにて指定された課金エンジン宛に、決定された課金条件データを含むメッセージ「課金条件通知メッセージ」を送達する。
(5)課金条件通知メッセージを受信した課金装置制御機能部BECFは、課金エンジンBENに当該課金条件データを設定し、課金エンジンBENは以後課金対象パケットが通過した際にはこれをカウントすることが可能となる。
【０２５７】
図８６は上記機能の実現のためのメッセージ例、図８７は課金エンジンBENへの課金条件データ送付手順である。なお、図８７においてキャリアで代行課金する概略手順が課金条件データ送付手順の後に示されている。すなわち、キャリアで代行課金するために決済情報サーバSISを導入し、該決済情報サーバSISが課金エンジンで収集した課金データを蓄積整理し、ユーザへの請求額の計算を行う手順が示されている。又、図８６には、課金エンジンBENとサービス提供ノードXSPNとの間で交換される▲１▼〜▲４▼のメッセージに加えて、▲５▼〜▲６▼の課金エンジンBEN→決済情報サーバSIS→サービス提供ノードXSPNへのメッセージ、▲７▼のサービス提供ノードXSPN→決済情報サーバSIS→課金エンジンBENへのメッセージも示されている。
【０２５８】
(1)ユーザホストMHとサービス提供ノードXSPNとの間で課金条件交渉が完了し、当該サービスを提供するサービス提供ノードXSPNが課金条件を保持しているとする。
(2) サービス提供ノードXSPNは保持している課金条件データを、課金を担当する課金エンジンBEN(エッジノードEN内に存在)に対して課金開始要求メッセージで送達する。
(3) 課金開始要求メッセージを受信した課金エンジンは、当該課金条件データを設定して課金開始応答をサービス提供ノードXSPNに返すと共に、課金動作を開始する。
(4)課金サービス実行中に、ユーザホストの操作等何らかの要因にて課金動作の中断を認識すれば、サービス提供ノードXSPN は課金エンジンに対して課金停止要求メッセージを送信する。
(5)課金停止要求メッセージを受領した課金エンジンBENは、現在までに収集した課金データを決済情報サーバSISに送信するために、一括決済情報提示メッセージもしくは逐次決済情報提示メッセージを送信する。
(6) 一括決済情報提示メッセージを受領した決済情報サーバSISは、受領した課金情報を仮登録し、サービス提供ノードXSPN に回送して承認依頼する。
(7) サービス提供ノードXSPNは上記承認依頼について内容検証をおこない、決済承認結果を含む応答メッセージを決済情報サーバSISに返す。
(8)決済情報サーバSISは正常な承認応答を受領した場合、(6)で仮登録した課金データを正式登録し、その後登録結果を含めて課金エンジンBENに対して応答メッセージを回送する。
(9)課金エンジンBENは応答メッセージによって承認を確認したのち、この結果を含めた課金停止応答メッセージをサービス提供ノードXSPN に対して応答する。
【０２５９】
（ｐ）利用者毎の課金情報収集と、課金エンジンとの連携
課金条件を設定された課金エンジンBENと、キャリアの代行課金システムの連携について説明する。すなわち、課金エンジンBENにより収集された課金データを、代行課金情報を管理する決済情報サーバSISに対して送達する連携手順を示す。尚、以下の3つの前提条件がある。
第1の前提条件：課金エンジンの配備位置は、代行課金するキャリアのコアネットワーク内で、課金対象パケットが転送される経路上にあり、これを捕捉できることが条件である。配備位置の例としては、前述の経路上にあれば任意だが、エンドユーザに提供されるサービス品質を監視する等の目的でエンドユーザを収容するエッジノードENが一般的と想定される。
【０２６０】
第2の前提条件：図８６のメッセージを使用して、ユーザホストMHとサービス提供ノードXSPNの間で合意された課金条件データが課金エンジンBENに送達されて設定される。以後,課金エンジンは課金対象パケットを観測し、これをカウントする。
第3の前提条件：キャリアで代行課金するにあたり、課金エンジンBENで収集された課金データを蓄積整理し、ユーザへの請求額の計算を行う決済情報サーバSIS(図８７参照)を導入する。決済情報サーバSISは課金エンジンとのインタフェースを持つ(図８６における▲５▼〜▲７▼の3つのメッセージを参照)。
【０２６１】
(p-1)課金エンジンにおける課金条件の収集／管理
本発明では課金エンジン自体の構造には関与せず、収集中の課金条件は課金エンジンBENを制御する課金装置制御機能部BECFによって保持管理される。課金装置制御機能部BECFにより収集された課金条件データは、課金条件管理テーブルBCAT(図８８)内に保持される。このテーブルは、契約者単位の識別子(NAI)に基づき管理される。
図８８はエッジノードENにおける課金装置制御機能部BECFの課金条件収集／管理処理フローである。
【０２６２】
エッジノードENの課金装置制御機能部BECFは受信メッセージ内に課金条件識別子が含まれているかチェックし(ステップ2001)、含まれていなければ課金対象外のため無視し(ステップ2002)、次のメッセージの受信を待つ。
課金条件識別子が含まれていれば、受信メッセージが課金開始要求メッセージ(図８７の▲２▼参照)であるかチェックする(ステップ2003)。課金開始要求メッセージを受信すれば、本メッセージにサービス提供ノードXSPNが課金条件と課金条件識別子を付与して送信していると判断される。
【０２６３】
課金開始要求メッセージであれば、課金条件が含まれているか調べ（ステップ2004)、含まれていなければ課金対象外のため無視し(ステップ2002)、次のメッセージの受信を待つ。
課金条件が含まれていれば、課金条件を課金エンジンBENに設定する(ステップ2005)。ついで、課金条件設定が正常終了したか監視し(ステップ200６)、課金エンジンBENへの設定に失敗した場合には、課金不可能なためエラーメッセージを作成し(ステップ2007)、課金開始応答メッセージ(図８７の▲３▼参照)に含ませてサービス提供ノードXSPNに送出する(ステップ2008)。
一方、課金エンジンBENへの設定が正常終了すれば、課金装置制御機能部BECFは当該課金条件、課金条件識別子などを課金条件管理テーブルBCATに追加する(ステップ2009)。このとき、登録状態は「仮登録」として設定される。
【０２６４】
課金条件管理テーブルBCATへの登録が正常終了した時点で、課金装置制御機能部は当該エントリについて、有効期限を示すタイマーを起動し、減算を開始する。(ステップ2010)。このタイマーの目的は、仮設定された当該課金条件に有効期限を設ける為であり、一定時間、端末ユーザからのサービス料金条件の承諾を待つ。このタイマ期間内に端末ユーザからの課金条件への承諾情報が来ない場合、当該課金条件のエントリを自律的に削除する。
ついで、課金装置制御機能部BECFは課金条件識別子を課金開始応答メッセージ(図８７の▲３▼参照)に含ませてサービス提供ノードXSPNに送出する(ステップ2011、2008)。
ステップ2003において、メッセージが課金開始要求メッセージでなければ、図７４の課金条件識別子格納手順を実行する(ステップ2012)。
【０２６５】
(p-2)課金エンジンから決済情報サーバへの課金条件データの送達
課金エンジンBENは上記で設定された課金条件に従い、利用者およびアプリケーション単位でカウントする。収集された料金データは課金セッション（有料サービス）が終了もしくは、課金セッション継続中に課金データの送付を要求された場合に、課金エンジンBENはキャリアの管理下にある決済情報サーバSISに対して課金データを送信する。課金エンジンが収集可能なもっとも下位レベルの情報は、通過したパケット数であり、これに加えて単位時間あたりの通過パケット数、セッション単位の通過パケット数がある。
【０２６６】
課金エンジンBENが収集した課金データの決済情報サーバSISへの送達タイミングには一括送信方式と逐次送信方式の二種類がある。
一括送信方式は、当該課金セッション終了後に課金エンジンBENから決済情報サーバSISに対してまとめて送信する方式であり、課金情報は課金動作終了応答メッセージ(一括決済情報提示メッセージ)に付与される。
逐次送信方式は、ユーザに対して一定周期で課金情報を提供するために、課金セッション有効期間内に一定の周期で各周期内に収集された課金情報を決済情報サーバSISに送達する方式である。課金情報は中間課金情報送付用のメッセージ(逐次決済情報提示メッセージ)に付与される。
【０２６７】
一括決済情報提示メッセージ、逐次決済情報提示メッセージが含む情報要素は同一であり、以下の構成となる。
(1) 課金データ本体：送信時点で課金エンジンが収集した課金データ
(2) 付加価値データ：契約条件によってキャリアからサービス提供ノードXSPに付加価値情報（サービス品質のフィードバック等）提示するために付加される汎用的なデータフィールド。
(3) 連続識別子：最終、継続のいずれかが設定される。
一括決済情報提示メッセージの場合及び逐次決済情報提示メッセージであって最終の課金情報である場合に「最終」が設定される。また、逐次決済情報提示メッセージであって最終でない場合に「継続」が設定される。
【０２６８】
図８９は決済手順説明図である。前提条件として、課金データの決済情報サーバSISへの送信方式は逐次送信方式であり、また決済方式は完全代行課金方式(後述)であるとする。
(1)決定された課金条件に従ってサービスが開始する。
(2)課金エンジン制御機能部BECFは、決済情報サーバSISへの送信方法を課金条件データから検出する。尚、送信方法が一括決済情報提示方式である場合は、サービス終了を待って課金データを送信する。
(3)送信方法が逐次決済情報提示方式である場合は、課金条件データに含まれる送信周期に基づき、サービス終了まで継続的に課金データを決済情報サーバSISへ送付する。
(4)サービス終了を課金エンジンBENが検出すれば、最後の課金データを決済情報サーバSISに送信する。
(5) 決済情報サーバSISは最後の課金データを受信すればサービス提供ノードXSPNの確認要否に基いて代行課金処理を行なう。
【０２６９】
(p-3) サービス提供ノードXSPNとキャリア間の決済情報の交換
キャリア代行課金において、サービス提供ノードXSPNはサービスを提供するが、料金カウントに関与しない。一方、キャリアは課金エンジンBENにより、個々のユーザの課金データを集計し、この内容に基づきユーザに対して料金請求する。具体的には、毎月の基本通信料金に加え、課金対象サービスの提供に対する付加使用料を請求する。
【０２７０】
かかるキャリア代行課金業務の契約形態は、基本的に完全代行課金方式と個別承認課金方式の二種類に分類される。
完全代行課金方式は、サービス（課金セッション）単位の課金情報の蓄積、積算をすべてキャリア側に一任し、サービス提供ノードXSPNは個々のサービスの決済に関与しない方式である。ただし、サービス提供ノード（サービス提供業者)XSPN は自社に関する決済情報の参照は可能である。完全代行課金方式における決済データの交換契機は、サービス提供ノードXSPNとキャリア間であらかじめ規定した一定周期であり、例えば１ヶ月に１度、決済データの交換を行なう。完全代行課金方式は、サービス提供ノードXSPNに対するサービス品質保証を伴わない、比較的単純なサービスに適切であり、基本機能のみを提供するベーシック課金代行プランとしての契約形態が可能である。
【０２７１】
個別承認課金方式は、各サービス（課金セッション）終了時にキャリアがサービス提供ノードXSPN に対して課金データを提示し、サービス提供ノードXSPN から該課金データについて承認及び課金依頼を待つ方式である。サービス提供ノードXSPNがこの課金データを承認し、これをキャリアが確認した時点で決済情報サーバSISは、決済情報として登録する。個別承認課金方式は、以下の2つの用途に適切である。第1の用途は、サービス提供ノードXSPNが課金データを参照/確認するほかに、当該課金セッションにおいて測定されたサービス品質データ（例：各種QoSデータ）等を合わせて受信することで、サービス運用、提供に対するフィードバックデータとする場合である。第2の用途は、サービス提供ノードXSPNが受領した課金データを、ユーザインタラクション（料金確認等）に利用する場合である。XSPに対する付加価値情報のフィードバックを伴うプレミアム課金代行プランとしての契約形態が可能である。
【０２７２】
キャリアによる代行課金を行うためには、サービス提供ノードXSPNとキャリア間で決済情報について交換を行なう必要がある。図9０は、課金代行キャリアとサービスプロバイダ間の決済情報の交換手順説明図である。なお、課金データの決済情報サーバSISへの送信方式は、課金セッション終了後に一括して送信する一括送信方式であり、決済方式は、課金データをサービス提供ノードによる承認を要する個別承認課金方式であるとする。
(1) サービス提供ノードXSPNからユーザホストＭＨへ課金対象サービスが提供されているとする。この課金条件は既に課金条件交渉手順によって、課金エンジンBEN（エッジノードENに内蔵される）に設定され、課金エンジンはこの課金条件に従って課金する。
(2) 課金対象のサービスが終了する。この終了は、ユーザからの明示的な中断要求により、あるいは、サービス提供中においてユーザホストMHの電源切断（電池切れ等）もしくは圏外への移動等によりユーザが意図しない形で発生する中断によるものである。サービス終了により、課金エンジンBENはサービス提供ノードXSPNから課金停止要求メッセージを受ける。
【０２７３】
(3) 課金エンジンBENは、収集した課金データを、キャリアが管理する決済情報サーバSISに送達する。このとき、サービス提供ノードXSPNとキャリア間の代行課金契約が個別承認課金の形態であれば、付加価値情報（品質データ等）を合わせて送付する。
(4)決済情報サーバSISは、課金データを受領し、これを仮登録の形態で保管する。ついで、決済情報サーバSISは、代行課金の契約条件(決済方式)が完全代行課金方式であるか、個別承認課金方式であるかチェックする。完全代行課金方式であれば、仮登録された課金データを正式登録する。
(5) 一方、個別承認課金方式であれば、決済情報サーバSISは課金データと付加価値情報データをサービス提供ノードXSPNに送達して、応答を待つ。
(6) サービス提供ノードXSPNは、決済情報サーバSISから上記課金データ等を受信すれば、受信した課金データの内容をチェックし、問題なければ承認の応答を決済情報サーバSISに返す。ただし、オプションとしてユーザに対して課金データを提示し、これに対する承諾応答を得てから、決済情報サーバSISに承認応答を返すことも可能とする。
(7) 決済情報サーバSISは、サービス提供ノードXSPNから課金データに対する承認応答を受領して、当該課金データを正式に登録する。すなわち、今回の課金額を当該ユーザの合計請求額に加算する。
【０２７４】
以上、本発明のIPv6をべースとした第2の課金技術によれば、IPv4/ Mobile IPをベースとした第1課金技術と同等機能を実現でき、しかも、網および端末への機能追加を不要にすることができる。
又、本発明のIPv6をべースとした第2課金技術によれば、IPv4/ Mobile IPをベースとした第1課金技術の課金制御手順に比較して、課金制御メッセージの転送経路を最適化することができる。
又、本発明のIPv6をべースとした第2課金技術によれば、サービス提供者側装置を、サービス提供ノードXSPNと課金制御ノードBCNとに分離したことで、１サービスを複数に分散したサーバで提供するサービス提供形態に対応可能な課金制御を行なうことができる。
以上、本発明の第１課金技術を、IPv4/Mobile IPをべースにしたネットワーク構成で説明したが、同様のプロトコルをべースとしたネットワーク構成における課金にも適用できるものである。
又、本発明の第２課金技術を、IPv6をべースにしたネットワーク構成で説明したが、同様のプロトコルをべースとしたネットワーク構成における課金にも適用できるものである。
【０２７５】
(付記１）  ユーザ端末にサービスを提供するための処理を行い、ユーザ端末に提供するサービスに対して課金を行う課金システムにおいて、
サービス種別およびユーザ端末単位のユーザ課金プロファイルを保持するユーザ課金プロファイル登録部、
特定されたサービス種別およびユーザ端末に応じたユーザ課金プロファイルに基づいて課金条件を生成する課金条件生成部、
ネットワーク内に設けられ、前記生成された課金条件に基づいてユーザ端末毎に課金処理を実行する課金部、
課金部に前記生成された課金条件を設定する課金条件設定部、
を備え、課金部はユーザ端末に対して提供されるサービスに応じて課金を実行することを特徴とする課金システム。
【０２７６】
(付記２）  サービス提供ノード側に、料金と関連付けられたサービス情報を記述した1以上のサーバ課金プロファイルを保存するサーバ課金プロファイル登録部を設けると共に、前記ユーザ課金プロファイルにユーザの支払い許容条件を記述し、
前記課金条件生成部は、ユーザ端末がサービス実行要求メッセージを送出した時点で前記ユーザ課金プロファイルと各サーバ課金プロファイルを照合することにより、提供するサービスに対する課金条件を決定する、
ことを特徴とする付記1記載の課金システム。
【０２７７】
(付記３）  ユーザ端末が収容されたルータ、
位置登録時に該ルータより受信する認証要求メッセージに基づいて端末認証処理を実行すると共に、該認証要求メッセージにサービス要求情報が含まれていれば、前記ユーザ課金プロファイル登録部より、当該ユーザ端末及びサービス種別に応じたユーザ課金プロファイルを取得して前記課金条件生成部に転送する認証サーバ、
を備えたことを特徴とする付記1記載の課金システム。
【０２７８】
(付記４）  前記課金条件生成部は、
ユーザ課金プロファイルにより規定される条件とサーバ課金プロファイルにより規定される条件の照合を行い、ユーザ課金プロファイルに含まれる各条件を満足するサーバ課金プロファイルを求め、該サーバ課金プロファイルに基づいて課金条件を生成する、
ことを特徴とする付記2記載の課金システム。
【０２７９】
(付記５）  所定のサービス要求に対して予め生成された課金条件を前記認証サーバ内に保存しておき、認証サーバはユーザ端末よりサービス要求があったとき、該サービス要求に対応して保存している課金条件を前記課金条件生成部に転送する、
ことを特徴とする付記3記載の課金システム。
(付記６）  前記課金条件生成部は、
課金条件を特定する課金条件識別子を生成し、該課金条件識別子をユーザ端末に通知する、
ことを特徴とする付記１記載の課金システム。
(付記７)  課金部は、前記課金条件設定部により課金条件が設定されると、ユーザ端末が要求するサービス内容に合致するパケットの到着を監視し、該パケットが到着すれば前記課金条件に従って課金を開始し、
前記課金条件設定部は課金条件設定後、一定時間経過しても前記パケットが観測されなければ課金条件の設定を解除する、
ことを特徴とする付記1記載の課金システム。
【０２８０】
(付記８）  課金条件識別子を位置登録メッセージに含めて送出することにより課金条件生成部から提示された課金条件をユーザ端末が承諾したことをネットワークに通知する承諾通知手段、
を備えたことを特徴とする付記6記載の課金システム。
(付記９）  ユーザ端末は、課金条件識別子が付与された位置登録メッセージを周期的に送出し、
前記課金条件設定部は前記登録メッセージより課金条件識別子を検出すれば課金部に当該ユーザ端末の課金処理を継続実行させ、
周期的に位置登録メッセージが送出されない場合、もしくは周期的に送出される位置登録メッセージ内に課金条件識別子が含まれていない場合、課金部に課金収集動作の終了を指示する、
ことを特徴とする付記6記載の課金システム。
【０２８１】
(付記１０）  ユーザ端末は、位置登録メッセージに課金条件識別子と共にサービス要求またはサービス中断を示す情報を含めて送出することで、実行中のサービスに対する課金条件の変更あるいはサービス実行中止を依頼する、
ことを特徴とする付記1記載の課金システム。
(付記１１）  移動によるハンドオーバ後、設定された課金条件に従って課金処理を実行する新課金部、
新課金部に前記課金条件を設定する新課金条件設定部を備え、
新課金条件設定部は旧課金部で適用されていた課金条件を取得して新課金部に設定し、新課金部は旧課金部と同一課金条件で課金処理を実行する、
ことを特徴とする請求項1記載の課金システムス。
【０２８２】
(付記１２）  課金動作の継続に際してユーザ端末は課金条件識別子を含む位置登録メッセージを送出し、
新課金条件設定部は課金条件識別子を抽出し、移動前の旧課金条件設定部に旧課金部で適用されていた課金条件を、該課金条件識別子を付して要求し、
旧課金条件設定部は、受信した課金条件識別子と課金条件管理テーブルで保持しているユーザ端末の課金条件識別子とを照合することによりユーザ端末の正当性を判断し、正当なユーザ端末であれば旧課金部で適用されていた課金条件を新課金条件設定部に送出する、
ことを特徴とする付記11記載の課金システム。
(付記１３）  課金条件生成の動作をユーザ端末の位置登録手順に含め、位置登録手順と並行して課金条件の生成処理、課金部の起動処理を行い、サービス実行前に課金条件の生成、課金部の起動を完了する、
ことを特徴とする付記1記載の課金システム。
(付記１４）  特定されたサービス種別およびユーザ端末に応じたユーザ課金プロファイルを前記ユーザ課金プロファイル登録部から読み出してサービス提供ノードの課金条件生成部に送出すると共に、該ユーザ課金プロファイルを保存手段に保存し、
別のサービス提供サーバに新規サービス要求を行う場合、前記保存手段に保存されているユーザ課金プロファイルを該別のサーバの課金条件生成部に送出する、
ことを特徴とする付記1記載の課金システム。
【０２８３】
(付記１５)  ユーザ端末の位置登録処理に連携して該ユーザ端末にサービスを提供するための処理を行い、ユーザ端末に提供するサービスに対して課金を行う課金システムにおける課金条件決定サーバにおいて、
料金と関連付けられたサービス情報を記述した1以上のサーバ課金プロファイルを保存するサーバ課金プロファイル登録部、
特定されたサービス種別およびユーザ端末に応じたユーザ課金プロファイルと各サーバ課金プロファイルを照合することにより、提供されるサービスに対する課金条件を決定するに課金条件生成部、
決定した課金条件を課金部に通知する手段、
を備えたことを特徴とする課金条件決定サーバ。
【０２８４】
(付記１６)    前記課金条件生成部は、
ユーザ課金プロファイルにより規定される条件とサーバ課金プロファイルにより規定される条件の照合を行い、ユーザ課金プロファイルに含まれる各条件を満足するサーバ課金プロファイルを求め、該サーバ課金プロファイルに基づいて課金条件を生成する、ことを特徴とする付記1５記載の課金条件決定サーバ。
（付記１７）  課金条件を特定する課金条件識別子を生成し、該課金条件識別子をユーザ端末に通知する手段、
を備えたことを特徴とする付記１５記載の課金条件決定サーバ。
【０２８５】
（付記１８）  移動端末の位置登録処理に連携して該移動端末にサービスを提供するための処理を行い、移動端末に対するサービス提供に対して課金を行う課金システムにおける移動端末において、
サービス要求を含めて位置登録メッセージをネットワークに送出し、ネットワークをして位置登録手順と並行して、ユーザ端末毎に且つ要求されたサービス毎に、課金条件の生成処理、課金部の起動処理を行わせ、サービス実行前に課金条件の生成、課金部の起動を完了させる手段、
を備えることを特徴とする移動端末。
【０２８６】
（付記１９）  課金条件を特定する課金条件識別子をネットワークより受信して保持する手段、
課金条件識別子が付与された位置登録メッセージを周期的に送出して当該ユーザ端末の課金処理を継続実行させる手段、
を備えたことを特徴とする付記１８記載の移動端末。
(付記２０）  周期的に送出する位置登録メッセージに課金条件識別子と共にサービス要求またはサービス中断を示す情報を含めることで、実行中のサービスに対する課金条件の変更あるいはサービス実行中止を依頼する手段、
を有することを特徴とする付記１８記載の移動端末。
(付記２１）  移動によるハンドオーバ後の課金動作を継続する際、ユーザ端末の正当性を判断させるために課金条件識別子を含む位置登録メッセージを送出する手段、
を備えたことを特徴とする請求項18記載の移動端末。
【０２８７】
(付記２２）  ユーザ端末にサービスを提供するための処理を行い、ユーザ端末に提供するサービスに対して課金を行う課金システムにおけるルータ装置において、
課金条件生成部で生成された課金条件に基づいてユーザ端末毎に課金処理を実行する課金部、
課金部に前記生成された課金条件を設定する課金条件設定部、
を備え、課金部はユーザ端末に対して提供されるサービスに応じた課金を実行することを特徴とするルータ装置。
【０２８８】
(付記２３）  課金部は、前記課金条件設定部により課金条件が設定されると、ユーザ端末が要求するサービス内容に合致するパケットの到着を監視し、該パケットが到着すれば前記課金条件に従って課金を開始し、
前記課金条件設定部は課金条件設定後、一定時間経過しても前記パケットが観測されなければ課金条件の設定を解除する、
ことを特徴とする付記２２記載のルータ装置。
(付記２４）  前記課金条件設定部はユーザ端末より送出される位置登録メッセージに課金条件識別子が含まれていれば、課金部に当該ユーザ端末の課金処理を継続実行させ、周期的に位置登録メッセージが送出されない場合、もしくは周期的に送出される位置登録メッセージ内に課金条件識別子が含まれていない場合、課金部に課金収集動作の終了を指示する、
ことを特徴とする付記２２記載のルータ装置。
【０２８９】
（付記２５）ネットワークを介してユーザ端末に提供されるサービスに対して課金する課金システムにおいて、
ユーザ端末にサービスを提供するサービス提供ノード、
ユーザ端末が希望するサービス提供条件を記録したユーザ課金プロファイルとサービス提供ノードが許容するサービス提供条件を記録したサーバ課金プロファイルを比較してユーザに提供するサービスに関する課金条件を生成する課金制御ノード、
ユーザ端末からのサービス提供要求に基いて通過するメッセージに前記ユーザ課金プロファイルを付加することにより、該課金プロファイルを前記課金制御ノードに直接あるいはサービス提供ノードを介して間接的に送達するエッジノード、
サービス提供ノードに代わって該サービス提供ノードがユーザ端末に提供するサービスに関して前記課金条件に従って課金する代行課金部、
を備えた課金システム。
【０２９０】
（付記２６）ユーザ端末の正当性の認証を行なうと共に、該ユーザ端末の課金プロファイルを管理するAAAサーバを備え、
ユーザ端末からアドレス割当要求があったとき、前記エッジノードは割当アドレスを決定すると共にAAAサーバにユーザ端末の認証要求を送り、該AAAサーバは認証応答にユーザ端末の課金プロファイルを付してエッジノードに送付し、エッジノードは該ユーザ課金プロファイルを保持し、前記サービス提供要求をしたユーザ端末に応じたユーザ課金プロファイルを前記メッセージに付加する、
ことを特徴とする付記25記載の課金システム。
（付記２７）前記エッジノードは、ユーザ端末からサービス提供ノード宛のサービス提供要求メッセージを検出したとき、該メッセージに該ユーザ端末のユーザ課金プロファイルを付加してサービス提供ノードに送達し、
サービス提供ノードは該サービス提供要求メッセージを受信したとき、課金条件生成を要求するメッセージに前記ユーザ課金プロファイルを含めて前記課金制御ノードに送付する、
ことを特徴とする付記２５記載の課金システム。
【０２９１】
（付記２８）前記サービス提供ノードは、ユーザ端末からユーザ課金プロファイルが付加されていないサービス提供要求メッセージを受信したとき、前記課金制御ノードに対して課金条件生成を要求するメッセージを送信し、
エッジノードは前記課金制御ノード宛の前記メッセージを検出したとき、該メッセージに前記ユーザ端末のユーザ課金プロファイルを付加して課金制御ノードに送達する、
ことを特徴とする付記２５記載の課金システム。
（付記２９）前記課金制御ノードは、生成した1以上の課金条件のそれぞれに識別子を付して前記サービス提供ノードに返信することで課金条件の一元管理を行なう、
ことを特徴とする付記２7又は２８記載の課金システム。
（付記３０）前記サービス提供ノードは、前記課金制御ノードで生成された課金条件をユーザ端末に承認させるための画面あるはテキストを作成し、該画面あるはテキストにより課金条件をユーザ端末に提示し、ユーザ端末から課金条件を承諾するメッセージを受信して該課金条件に従ってサービス提供を開始する、
ことを特徴とする付記29記載の課金システム。
【０２９２】
（付記３１）前記エッジノードは、前記課金条件承認用の画面あるはテキストの提示の過程で取得した前記課金条件識別子に対応させて、該識別子により特定される課金条件が仮登録中であるか、利用中であるか、及び該課金条件の有効期間を管理する、
ことを特徴とする付記３０記載の課金システム。
（付記３２）前記エッジノードは、課金条件の有効期間満了前にユーザ端末から認証要求が送出されたか監視し、認証要求が有効期間満了前に送出されたならばユーザ端末はサービス継続を要求していると判断し、有効期間を更新し、有効期間満了前に送出されなければサービス継続を要求していないと判断する、
ことを特徴とする付記３１記載の課金システム。
（付記３３）前記サービス提供ノードは、ユーザ端末より明示的なサービス中断要求メッセージを受信すれば、サービス提供を停止すると共に、代行課金部による課金動作を終了させる、
ことを特徴とする付記２５記載の課金システム。
（付記３４）前記サービス提供ノードは、前記課金制御ノードで生成された複数の課金条件を保存し、サービス実行中にユーザ端末より課金条件変更要求メッセージを受信すれば、保存してある課金条件をユーザ端末に承認させるための画面あるはテキストを作成し、該画面あるはテキストにより新課金条件をユーザ端末に提示し、ユーザ端末から新課金条件を承諾するメッセージを受信して新課金条件に従ってサービスを提供する、
ことを特徴とする付記３０記載の課金システム。
【０２９３】
（付記３５）サービス提供ノードは、ユーザ端末が承諾した課金条件を課金制御ノードに通知し、課金制御ノードは該課金条件に該サービス提供ノードの識別情報とユーザ端末の識別情報を含めて保存し、該サービス提供ノードとは別の第2のサービス提供ノードより該ユーザ端末に対する課金条件生成要求メッセージを受信したとき、前記保存してある課金条件を第2のサービス提供ノードに返信し、第2のサービス提供ノードは該課金条件に従ってサービスを提供し、代行課金部は該課金条件に従って課金する、
ことを特徴とする付記３０記載の課金システム。
（付記３６）サービス提供ノードは、ユーザ端末が承諾した課金条件を課金制御ノードに通知し、課金制御ノードは該課金条件を保存し、該課金条件に課金条件変更パラメータが含まれていれば、該パラメータに基いて課金条件を変更し、変更後の課金条件をサービス提供ノードに通知し、サービス提供ノードは該課金条件に従ってサービスを提供し、代行課金部は該課金条件に従って課金する、
ことを特徴とする付記３０記載の課金システム。
（付記３７）前記代行課金部は、課金条件にしたがって課金する課金エンジンを含み、サービス提供ノードは、ユーザ端末が承諾した課金条件を所定の課金エンジンに通知し、該課金エンジンは該課金条件にしたがって課金する、
ことを特徴とする付記30記載の課金システム。
（付記３８）前記代行課金部は、所定のエッジノードに実装され、かつ、課金条件にしたがって課金する課金エンジンと、該課金エンジンの課金結果を収集してユーザ端末に対する請求額の決済処理を行なう決済サーバを有する、
ことを特徴とする付記３０記載の課金システム。
【０２９４】
（付記３９）ユーザ端末にサービスを提供するサービス提供ノード、ユーザ端末が希望するサービス提供条件を記録したユーザ課金プロファイルとサービス提供ノードが許容するサービス提供条件を記録したサーバ課金プロファイルを比較してユーザに提供するサービスに関する課金条件を生成する課金制御ノード、サービス提供ノードに代わって該サービス提供ノードがユーザ端末に提供するサービスに関して前記課金条件に従って課金する代行課金部を備えた課金システムのエッジノードにおいて、
ユーザ端末からのアドレス割当要求により該ユーザ端末にアドレスを割り当てると共にユーザ端末の正当性の認証を認証部に要求する認証要求部、
認証応答時に、該認証部よりダウンロードされる前記ユーザ端末の課金プロファイルを保持するユーザ課金ファイル保持部、
ユーザ端末からのサービス提供要求に基いて通過するメッセージを検出し、該メッセージに前記ユーザ端末のユーザ課金プロファイルを付加する課金プロファイル付加部、
該メッセージを前記課金制御ノードに直接あるいはサービス提供ノードを介して送達するメッセージ送出部、
を備えたことを特徴とするエッジノード。
【０２９５】
（付記４０）ユーザ端末にサービスを提供するサービス提供ノード、課金条件を生成する課金制御ノード、サービス提供ノードに代わって課金する代行課金部を備えた課金システムにおける課金制御ノードにおいて、
サービス提供ノードが許容するサービス提供条件を記録したサーバ課金プロファイルを登録するサーバ課金プロファイル登録部、
サービス提供ノードからの課金条件生成要求に基づいて、ユーザ課金プロファイルと前記サーバ課金プロファイルを比較してユーザに提供するサービスに関する課金条件を生成する課金条件生成部、
該生成した課金条件に課金条件識別子を付加してサービス提供ノードに返信する手段、
ユーザ端末とサービス提供ノードとの交渉により決定された課金条件にサービス提供ノードの識別子情報、ユーザ端末の識別子情報を付加して登録する手段、
を備えたことを特徴とする課金制御ノード。
【０２９６】
（付記４１）ユーザ端末にサービスを提供するサービス提供ノード、課金条件を生成する課金制御ノード、サービス提供ノードに代わって課金する代行課金部を備えた課金システムにおけるサービス提供ノードにおいて、
ユーザ端末からサービス提供要求があったとき、前記課金制御ノードに課金条件の生成を要求する手段、
課金制御ノードにより生成された1以上の課金条件を受信したとき、ユーザ端末と交渉して課金条件を決定する課金条件決定部、
該決定した課金条件を代行課金部に通知すると共に、該課金条件に従ってサービスを提供する手段、
を備えたことを特徴とするサービス提供ノード。
【０２９７】
（付記４２）ユーザ端末にサービスを提供するサービス提供ノード、課金条件を生成する課金制御ノード、サービス提供ノードに代わって課金する代行課金部を備えた課金システムにおける代行課金装置において、
サービス提供ノードから課金開始を指示されてから課金終了を指示されるまで、指示された課金条件に従ってユーザ端末に提供するサービスに対する課金を行なう課金エンジン、
逐次あるいは課金終了指示により一括して課金エンジンから課金結果を受信すると共に、サービス提供ノードとの間の契約に基づいて該サービスに対する決済処理を行なう決済情報サーバ、
を備えたことを特徴とする代行課金装置。
【０２９８】
（付記４３）  ネットワークを介してユーザ端末に提供されるサービスに対して課金する課金システムにおいて、
ユーザ端末にサービスを提供するサービス提供ノード、
ユーザ端末が希望するサービス提供条件を記録したユーザ課金プロファイルとサービス提供ノードが許容するサービス提供条件を記録したサーバ課金プロファイルを比較してユーザに提供するサービスに関する課金条件を生成する課金制御ノード、
サービス提供ノードがユーザ端末に提供するサービスに関して前記課金条件に従って課金する代行課金部、
を備えた課金システム。
（付記４４）  前記ユーザ課金プロファイルを格納するデータべースを備え、
前記課金制御ノードは、ユーザ端末からのサービス提供要求に基いて、前記データべースよりユーザ課金プロファイルを取得する課金プロファイル取得手段、
を有することを特徴とする付記43記載の課金システム。
（付記４５）  前記ユーザ課金プロファイルを格納するデータべースを備え、
前記課金制御ノードは、サービス提供ノードより課金条件整合要求を受信した時、該課金条件整合要求にユーザ課金プロファイルが付加されているかチェックし、付加されていない場合に前記データべースよりユーザ課金プロファイルを取得する、
ことを特徴とする付記43記載の課金システム。
（付記４６）  前記ユーザ課金プロファイルを格納するデータべースを備え、
サービス提供ノードは、ユーザ端末からのサービス提供要求に基いてを前記データべースよりユーザ課金プロファイルを取得する課金プロファイル取得手段、該ユーザ課金プロファイルを課金条件整合要求に付加して課金制御ノードに送信する課金条件整合要求手段、
を有することを特徴とする付記43記載の課金システム。
（付記４７）  前記ユーザ課金プロファイルを格納するデータべースを備え、
前記サービス提供ノードは、ユーザ端末よりサービス提供要求を受信した時、該サービス提供要求にユーザ課金プロファイルが付加されているかチェックし、付加されていない場合に前記データべースよりユーザ課金プロファイルを取得する、
ことを特徴とする付記4３記載の課金システム。
（付記４８）  前記データべースは、ユーザ課金プロファイル要求を受信すれば、該要求に含まれる端末識別子に応じたをユーザ課金プロファイル検索して要求元に送信する手段、
を有することを特徴とする付記44乃至４７記載の課金システム。
【０２９９】
【発明の効果】
以上本発明のIPv4/ Mobile IPをベースとした第1課金技術によれば、ユーザ、サービス提供者双方に課金に関する許容条件を用意してサービス開始時に双方の許容条件を照合することにより、サービス提供に対する課金条件を動的に生成し、該課金条件にしたがって課金することができる。
又、本発明の第1課金技術によれば、有料サービスに対してネットワーク内の課金部による代行課金が可能になる。
【０３００】
又、本発明の第1課金技術によれば、端末が移動しても該端末に対する課金をサポートすることができる。すなわち、端末移動によりハンドオーバが発生しても、サービス開始時にユーザ・サービス提供者間の交渉手順により動的に生成した課金条件を引き継いでサービスの提供、課金の継続をサポートすることができる。
又、本発明の第1課金技術によれば、価格交渉／課金条件設定の手順を位置登録手順を利用して実行することができる。
又、本発明のIPv6をべースとした第2課金技術によれば、第1課金技術と同等機能を実現でき、しかも、網および端末への機能追加を不要にすることができる。
又、本発明の第2課金技術によれば、第1課金技術の課金制御手順に比較して、課金制御メッセージの転送経路を最適化することができる。
又、本発明の第2課金技術によれば、サービス提供者側装置を、サービス提供ノードXSPNと課金制御ノードBCNとに分離したことで、１サービスを複数に分散したサーバで提供するサービス提供形態であっても課金制御を行なうことができる。
【０３０１】
又、本発明の第2課金技術によれば、サービス提供ノードXSPNまたは課金制御ノードBCNが直接、課金情報データべースよりユーザ課金ファイルを取得することにより、エッジノードの負荷を軽減することができる。
【図面の簡単な説明】
【図１】本発明を適用できるネットワークの全体の構成図である。
【図２】図1の要部詳細図である。
【図３】ホームエージェント及び外部エージェントの機能ブロック図である。
【図４】  FAのサービス制御トランザクションの制御テーブル例である。
【図５】  HAのサービス制御トランザクションの制御テーブル例である。
【図６】  anycastアドレス結合テーブル例である。
【図７】ルーチングテーブル例である。
【図８】結合キャッシュ例である。
【図９】サービス制御フィルタ例である。
【図１０】  AAAFサーバの機能ブロック図である。
【図１１】  AAAFサーバのサービス制御トランザクションの制御テーブル例である。
【図１２】  AAAHサーバの機能ブロック図である。
【図１３】  AAAHサーバのサービス制御トランザクションの制御テーブル例である。
【図１４】サービス制御データべース例である。
【図１５】通信ノードの機能ブロック図である。
【図１６】  AAAHサーバがホームエージェントHAを割り付ける場合の初期位置登録シーケンス例である。
【図１７】移動端末と通信ノードとの間でパケットを送受信する配信シーケンス例である。
【図１８】移動端末の移動の例を示す説明図である。
【図１９】移動端末が移動した際のシーケンス例である。
【図２０】外部エージェントFAが保持する移動端末のNAI登録テーブル例である。
【図２１】  NAIのプレフィックステーブル例ある。
【図２２】本発明の課金機能及びその配備先を説明するネットワーク構成図である。
【図２３】本発明で使用するユーザ課金プロファイル、サーバ課金プロファイルの例である。
【図２４】端末認証データとユーザ課金プロファイルの関連説明図である。
【図２５】  AAAサーバにおける端末認証処理と、課金プロファイル抽出処理フローある。
【図２６】サービス提供条件(課金条件)生成処理フローである。
【図２７】課金条件生成処理の一部詳細フローである。
【図２８】キャッシュされた課金条件を適用する場合のシーケンス例である。
【図２９】キャッシュされた課金条件を適用する場合のAAAサーバでの処理フローである。
【図３０】課金条件管理テーブルの例である。
【図３１】課金条件識別子付与処理フローである。
【図３２】課金装置制御機能部の処理フロー(課金条件の仮設定)である。
【図３３】課金装置制御機能部の処理フロー(実行中サービスに関する課金条件の更新)である。
【図３４】課金条件承認シーケンス例である。
【図３５】課金条件承認処理フローである。
【図３６】課金を継続する場合のシーケンス例(AAAセッションが残っていない場合)である。
【図３７】課金を継続する場合のシーケンス(AAAセッションが残っていない場合)におけるFAでの処理フローである。
【図３８】課金を継続する場合のシーケンス例(AAAセッションが残っている場合)である。
【図３９】課金を継続する場合のシーケンス(AAAのセッションが残っている場合)におけるFAでの処理フローである。
【図４０】課金条件を変更する場合のシーケンス例である。
【図４１】課金条件を変更する場合のFAでの処理フローである。
【図４２】課金条件を変更する場合におけるCN（サーバ）での処理フローである。
【図４３】移動後(ハンドオーバ時)の課金のためのシーケンス例である。
【図４４】移動後の課金のための新FAでの処理フローである。
【図４５】移動後の課金のための旧FAでの処理フローである。
【図４６】位置登録手順を利用してサービス課金条件交渉手順を実行する基本シーケンス例である。
【図４７】ホームエージェントHAのユーザ課金プロファイルキャッシュ処理及びキャッシュ利用処理フローである。
【図４８】本発明の第2の課金技術を適用できるネットワークの構成図である。
【図４９】サービスプロファイル情報及び課金プロファイル情報をAAAサーバよりエッジルノードに配布する基本シーケンスである。
【図５０】課金機能を装備した場合のネットワーク構成図である。
【図５１】ユーザホストとサービス提供ノードXSPNが別サブネットに存在する場合の課金制御説明図である。
【図５２】図51の課金制御手順図である。
【図５３】ユーザホストMHとサービス提供ノードXSPN-1が同一サブネットに存在する場合の課金制御説明図である。
【図５４】図53の課金制御手順図である。
【図５５】課金情報データべースとBCNとの直接連携時におけるネットワーク構成及び連携方式説明図である。
【図５６】  BCNと課金条件データべース間のメッセージ種別説明図表である。
【図５７】  BCNが直接ユーザ課金プロファイルを取得する場合の処理フローである。
【図５８】課金情報データべースとXSPNとの直接連携時におけるネットワーク構成及び連携方式説明図である。
【図５９】  XSPNと課金条件データべース間のメッセージ種別説明図表である。
【図６０】  XSPNが直接ユーザ課金プロファイルを取得する場合の処理フローである。
【図６１】ユーザ課金プロファイルが要求された時の課金情報データべースの処理フローである。
【図６２】ユーザ課金プロファイルの基本構成例である。
【図６３】具体的な課金プロファイルの条件記述例である。
【図６４】サーバ課金プロファイルの基本構造例である。
【図６５】課金条件整合手順を示す処理フローである。
【図６６】ユーザ課金プロファイルとサーバ課金プロファイルの例である。
【図６７】比較結果及びユーザに提示される課金条件の候補例である。
【図６８】ユーザ課金プロファイルの別の例である。
【図６９】サーバ課金プロファイルの別の例である。
【図７０】ユーザに提示される課金条件説明図である。
【図７１】ユーザホストMHのユーザ課金プロファイルの例である。
【図７２】エッジノードによる課金プロファイル格納手順処理フローである。
【図７３】エッジノード内の課金条件識別子管理テーブル例である。
【図７４】エッジノードによる課金条件識別子の管理処理フローである。
【図７５】ユーザ端末に課金条件承認を行なわせる際のサービス提供ノードXSPNの処理フローである。
【図７６】サービス継続確認説明図である。
【図７７】ホスト認証（セッション時間との連携）に基づくサービス確認手順の例である。
【図７８】実行中課金サービスのユーザ起動による動作停止処理説明図である。
【図７９】実行中課金サービスのユーザ起動による動作停止手順である。
【図８０】ユーザの意思によりサービス実行中に課金条件を変更する場合の課金条件再設定説明図である。
【図８１】サービス実行中に課金条件を変更する場合の課金条件再設定手順である。
【図８２】同一ユーザが移動に従って複数のサービス提供ノードXSPNより同一サービスを連続して受ける場合の課金条件設定説明図である。
【図８３】同一ユーザが移動に従って複数のサービス提供ノードXSPNより同一サービスを連続して受ける場合の課金条件設定手順である。
【図８４】ネットワーク側からの課金条件変更説明図である。
【図８５】ネットワーク側から課金条件を変更する場合における課金条件設定手順である。
【図８６】メッセージ例である。
【図８７】課金エンジンへの課金条件データ送付手順である。
【図８８】エッジノードENにおける課金エンジン制御機能部の課金条件収集／管理処理フローである。
【図８９】決済手順説明図である。
【図９０】課金代行キャリアとサービスプロバイダ間の決済情報の交換手順説明図である。
【図９１】統合IPサービス制御アーキテクチャのレイヤ構造説明図である。
【図９２】統合IPサービス制御アーキテクチャのサービス制御方式の説明図である。
【図９３】  Mobile IPの原理説明図である。
【図９４】  Mobile IPへの適用例(サービスプロファイル配布手順)説明図である。
【図９５】  Mobile IPへの適用例(サービス実行手順)説明図である。
【符号の説明】
１  ホームネットワーク
２，４  外部ネットワーク
５  IPネットワーク
１１  移動ノードMN
２１  ホームエージェントHA
２２  AAAHサーバ（AAAサーバあるいは認証サーバという）
２３  サービス制御データべースSPDB
２４  課金情報データべースBIDB
３１  外部エージェントFA
４１  サービス提供サーバCN
４２  エッジルータERT
４３  課金プロファイルSBP（Server Billing Profile）
４４  課金条件管理テーブル
501〜503  エッジノードEN-1〜EN-3
５２  AAAサーバ
５３  課金情報データべース
541，542  サービス提供ノードXSPN-1、XSPN-2
55,56  アクセスネットワーク
５７  課金制御ノードBCN
５８  ユーザ端末
【図１】
0004009136.tif 000002
【図２】
0004009136.tif 000003
【図３】
0004009136.tif 000004
【図４】
0004009136.tif 000005
【図５】
0004009136.tif 000006
【図６】
0004009136.tif 000007
【図７】
0004009136.tif 000008
【図８】
0004009136.tif 000009
【図９】
0004009136.tif 000010
【図１０】
0004009136.tif 000011
【図１１】
0004009136.tif 000012
【図１２】
0004009136.tif 000013
【図１３】
0004009136.tif 000014
【図１４】
0004009136.tif 000015
【図１５】
0004009136.tif 000016
【図１６】
0004009136.tif 000017
【図１７】
0004009136.tif 000018
【図１８】
0004009136.tif 000019
【図１９】
0004009136.tif 000020
【図２０】
0004009136.tif 000021
【図２１】
0004009136.tif 000022
【図２２】
0004009136.tif 000023
【図２３】
0004009136.tif 000024
【図２４】
0004009136.tif 000025
【図２５】
0004009136.tif 000026
【図２６】
0004009136.tif 000027
【図２７】
0004009136.tif 000028
【図２８】
0004009136.tif 000029
【図２９】
0004009136.tif 000030
【図３０】
0004009136.tif 000031
【図３１】
0004009136.tif 000032
【図３２】
0004009136.tif 000033
【図３３】
0004009136.tif 000034
【図３４】
0004009136.tif 000035
【図３５】
0004009136.tif 000036
【図３６】
0004009136.tif 000037
【図３７】
0004009136.tif 000038
【図３８】
0004009136.tif 000039
【図３９】
0004009136.tif 000040
【図４０】
0004009136.tif 000041
【図４１】
0004009136.tif 000042
【図４２】
0004009136.tif 000043
【図４３】
0004009136.tif 000044
【図４４】
0004009136.tif 000045
【図４５】
0004009136.tif 000046
【図４６】
0004009136.tif 000047
【図４７】
0004009136.tif 000048
【図４８】
0004009136.tif 000049
【図４９】
0004009136.tif 000050
【図５０】
0004009136.tif 000051
【図５１】
0004009136.tif 000052
【図５２】
0004009136.tif 000053
【図５３】
0004009136.tif 000054
【図５４】
0004009136.tif 000055
【図５５】
0004009136.tif 000056
【図５６】
0004009136.tif 000057
【図５７】
0004009136.tif 000058
【図５８】
0004009136.tif 000059
【図５９】
0004009136.tif 000060
【図６０】
0004009136.tif 000061
【図６１】
0004009136.tif 000062
【図６２】
0004009136.tif 000063
【図６３】
0004009136.tif 000064
【図６４】
0004009136.tif 000065
【図６５】
0004009136.tif 000066
【図６６】
0004009136.tif 000067
【図６７】
0004009136.tif 000068
【図６８】
0004009136.tif 000069
【図６９】
0004009136.tif 000070
【図７０】
0004009136.tif 000071
【図７１】
0004009136.tif 000072
【図７２】
0004009136.tif 000073
【図７３】
0004009136.tif 000074
【図７４】
0004009136.tif 000075
【図７５】
0004009136.tif 000076
【図７６】
0004009136.tif 000077
【図７７】
0004009136.tif 000078
【図７８】
0004009136.tif 000079
【図７９】
0004009136.tif 000080
【図８０】
0004009136.tif 000081
【図８１】
0004009136.tif 000082
【図８２】
0004009136.tif 000083
【図８３】
0004009136.tif 000084
【図８４】
0004009136.tif 000085
【図８５】
0004009136.tif 000086
【図８６】
0004009136.tif 000087
【図８７】
0004009136.tif 000088
【図８８】
0004009136.tif 000089
【図８９】
0004009136.tif 000090
【図９０】
0004009136.tif 000091
【図９１】
0004009136.tif 000092
【図９２】
0004009136.tif 000093
【図９３】
0004009136.tif 000094
【図９４】
0004009136.tif 000095
【図９５】
0004009136.tif 000096