(57)【要約】【解決手段】無料ＩＰ（ＴＩＰ）、ビジネスモデル、及び異なるネットワークオペレータによって操作されうるＩＰベースのアクセスネットワークによってユーザに課金しない無料の接続の提供を可能にする方法を説明する。ＴＩＰを用いることによって、無料ＩＰ宛先と通信するネットワークの使用は、無料ＩＰ宛先の所有者によって支払われる。無料ＩＰ宛先は、例えば無料ＩＰアドレス、無料インターネットドメインネーム、無料ＵＲＩ又はＵＲＬのような方法で識別できる。ＴＩＰによってユーザは、ネットワーク又はサービスプロバイダとの事前のサービス加入が無くても、及びネットワークを使用する許可を得るための特別な端末ソフトウェア又はハードウェアが無くても、ネットワークを使用することが可能となる。これによってユーザは、個々のネットワークオペレータが提供できるものよりも多くのアクセスネットワークを使用できる。ＴＩＰによって、サービスプロバイダは、個々のネットワークオペレータとビジネス取り決めを行う必要なく、ＩＰベースのアクセスネットワークによってサービスを提供できる。ＴＩＰは、例えばプリペイドＩＰ、コレクトＩＰ、選択的課金、及び複数オペレータを介したアクセス、及び無線ＬＡＮ及び携帯ネットワークによるアクセスを介したシングルプリペイドアカウントのような付加価値サービスを可能にするために使用することができる。【選択図】      図２
2007536605.tif 000002
【特許請求の範囲】
【請求項１】
無料ネットワークアクセスのインターネットプロトコルネットワークであって、
アクセスネットワークに関連した無料のクライアントと、
前記無料のクライアントに関連した無料のサーバとを備え、
前記サーバは、前記クライアントからの問い合わせに応じて、前記無料のクライアントのＩＰアドレスを無料の宛先として識別するネットワーク。
【請求項２】
請求項１のネットワークにおいて、
前記無料のサーバは、ＩＰ宛先に関する情報を含んでいる無料のＩＰ宛先データベースを更に備え、前記ＩＰ宛先の所有者は、前記ＩＰ宛先へ送られた任意のパケットについて課金されるネットワーク。
【請求項３】
請求項２のネットワークにおいて、前記アクセスネットワークは更に、
ローカルＩＰネットワークへのユーザアクセスを調整するアクセスサーバを備え、
前記アクセスサーバは、前記無料のクライアントを用いて、前記無料のサーバに対して、ユーザからのパケットに含まれているＩＰアドレスが無料のアドレスであるかを判定するように問い合わせるネットワーク。
【請求項４】
請求項１のネットワークにおいて、
前記無料の宛先ネットワークに関連した第２の無料のクライアントアプリケーションを更に備え、前記第２の無料のクライアントアプリケーションは、前記アクセスネットワークにおいてユーザが前記ＩＰ宛先ネットワークに誰を接続することができるかを管理するポリシーを格納するネットワーク。
【請求項５】
請求項４のネットワークにおいて、
前記無料のサーバは更に、前記格納されたポリシーを要求し、このポリシーを、前記第２の無料のクライアントアプリケーションから受け取る手段を備えたネットワーク。
【請求項６】
請求項５のネットワークにおいて、
前記無料のサーバは更に、前記第２の無料のクライアントアプリケーションから受け取った前記ポリシーを、前記アクセスネットワークに関連する前記無料のクライアントへ送る手段を備え、前記アクセスネットワークに関連する前記無料のクライアントは更に、前記ポリシーを用いて、前記無料の宛先ネットワークへのユーザアクセスを制御する手段を備えたネットワーク。
【請求項７】
ＩＰベースのネットワークへの無料のアクセスを提供する方法であって、
アクセスネットワークへのアクセスを試みるユーザから受け取ったパケットが、無料の宛先であると識別されたアドレスを含んでいるかを判定することと、
前記アドレスが無料の宛先であれば、前記識別された無料の宛先と、前記ユーザパケットの受け送りを行うことと
の各ステップを含む方法。
【請求項８】
請求項７の方法において、前記判定するステップは更に、
無料のサーバのもとへ、前記アクセスネットワークに関連したクライアントアプリケーションから、ユーザパケットからのＩＰアドレスを含む問い合わせを送ることと、
前記問い合わせに応答して、前記無料のサーバにおいて、前記ＩＰアドレスが無料の宛先であるかを確認することと、
前記アクセスネットワークに関連した前記クライアントアプリケーションに、前記無料のサーバから応答メッセージを送り返すことであって、前記応答メッセージは、前記ＩＰアドレスが無料の宛先かどうか示すことと、
前記ＩＰアドレスが無料の宛先であると前記応答メッセージが示すのであれば、前記無料の宛先へ前記ユーザから前記アクセスネットワークを通って後の全てのパケットを転送することと
の各ステップを含む方法。
【請求項９】
請求項８の方法において、
前記無料の宛先の所有者ネットワークにおいて、無料のクライアントアプリケーションからポリシー情報を得るステップを更に含む方法。
【請求項１０】
請求項９の方法において、
前記アクセスネットワークへ前記ポリシー情報を送り、前記アクセスネットワークにおいて前記ポリシーを実行し、前記宛先ネットワークへのユーザ通信を制御するステップを更に含む方法。
【請求項１１】
無料のアクセス管理を提供するサーバであって、
データベース内に無料アクセス情報を格納する手段であって、前記格納する手段は、アクセスネットワークから論理的に分かれて位置している手段と、
前記アクセスネットワークにおいて受け取られたＩＰパケットが、無料の宛先アドレスを含んでいるかを判定する手段と、
前記ＩＰパケットが無料の宛先アドレスを含んでいる場合、前記サーバから前記アクセスネットワークへメッセージを送り、前記アクセスネットワークに通知する手段と
を備えたサーバ。
【請求項１２】
請求項１１のサーバにおいて、
前記アクセスネットワークにおいて受け取られた前記ＩＰパケットに対する無料アクセスが、無料の宛先かを問い合わせるために、前記無料の宛先ネットワークに配置されたクライアントアプリケーションにアクセスする手段を更に備えたサーバ。
【請求項１３】
請求項１２のサーバにおいて、
前記アクセスする手段は更に、前記クライアントアプリケーションから受け取った情報を、前記アクセスネットワークに配置されたクライアントアプリケーションへ転送する手段を備えたサーバ。
【請求項１４】
請求項１３のサーバにおいて、
前記アクセスする手段は更に、前記無料の宛先ネットワークにおいて、前記クライアントアプリケーションからポリシー情報にアクセスする手段を備えたサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、異なるネットワークオペレータによって操作されうるＩＰベースのアクセスネットワークによって、ユーザに課金しない（「無料の」）接続を提供することに関する。
【背景技術】
【０００２】
ＩＥＥＥ  ８０２．１１を使用する無線ローカルエリア・ネットワークのようなＩＰベースのアクセスネットワークは、家庭、企業、及びパブリックホットスポット（例えば空港、ホテル、喫茶店、列車駅、ガソリンスタンド、公園、そして道路及び高速道路沿い）の中で急速に世界的に展開している。例えばＩＥＥＥ  ８０２．１６のようなより高速かつ広範囲の無線ＩＰアクセスネットワークが出現している。
【０００３】
今日、ユーザには、ＩＰアクセスネットワークを使用する許可を得るための２つの基本的な方法がある。第１のアプローチは、アクセスネットワーク又はサービスプロバイダへサービス加入をすることをユーザに要求する。ユーザがアクセスネットワークを使用することを認められる前に、ユーザは、自分の身元、信用証明、及びサービス要求を、ネットワーク内のポリシー判定ポイント（例えば、認証及び許可サーバ）へ通信するために、ネットワーク又はサービスプロバイダによって義務付けられた手順、アクセス制御インタフェース、ソフトウェア、及びプロトコルを使用する必要がある。ポリシー判定ポイントは、ユーザを認証し、特定のアクセスネットワークの使用を許可するために、ユーザのサービス加入情報を使用する。多くのプロバイダのネットワークを使用するために、ユーザは各ネットワークプロバイダとのサービス加入を維持する必要がある。加入者が、多数のサービス加入をすることなく、他のプロバイダのネットワークを使用できるように、サービスプロバイダは、他のサービス又はネットワークのプロバイダとローミング合意を確立することができる。しかしながら、それぞれが小さな受信地域（フットプリント）を提供している多くのネットワーク及びサービスプロバイダが存在しているパブリックホットスポットマーケット内で、それを行うのはしばしば困難である。
【０００４】
第２の既存のアプローチは、ユーザがネットワークの使用を試みる場合に、ネットワークが、ネットワーク利用に対する支払いをユーザに要求することである。それは、サービス加入をユーザに要求しない。代わりに、ネットワークを使用するというユーザの試み（例えば、ユーザの発信パケット）は、ネットワークによってインターセプト（トラップ）される。ネットワークは、このトラップされたトラフィックを、アクセスネットワークプロバイダから離れているサービスプロバイダによって操作されているかもしれないＡＡＡ（認証、許可、及びアカウンティング）サーバへ転送する。ＡＡＡサーバは、ユーザにネットワーク使用を許可する前に、ネットワーク利用に対する支払い、及びクレジットカード情報の提供に合意するようにユーザに促す。異なるアクセスネットワークは、ネットワークアクセスを制御するために、異なるプロトコル、ソフトウェア、ユーザインターフェース、及び認証手続きを使用するかもしれない（例えば、ウェブベースのアプローチ、ＩＥＥＥ  ８０２．１ｘ、及び適切な解決策）。異なるネットワークを使用するために、ユーザ端末は、これらの異なるプロトコル及びソフトウェアを装備しなければならない。また、ユーザは、これらの異なるインタフェース及び認証手続きに対処しなければならない。
【０００５】
典型的な従来技術ＩＰネットワークアクセスシステムが図１に示されている。ユーザ１０２によって訪問されている訪問アクセスネットワーク１００内のアクセスサーバ１０１は、ユーザからトラフィックを受け取り、ユーザのトラフィックが、アクセスサーバ１０１の向こうのネットワークの部分に入ることを許可すべきかを判定する。アクセスサーバは一般に、ネットワークアクセスサーバー（ＮＡＳ）、アクセスゲートウェイ、あるいはアクセスルータとも呼ばれる。
【０００６】
アクセスサーバ１０１は、例えば認証、許可、アカウンティング（ＡＡＡ）のようなネットワークアクセス制御機能をサポートする際に重要な構成要素である。認証は、それによってネットワークが、ユーザ１０２の身元を確認し、時々、ユーザも、そのネットワークの身元を確認する処理である。許可は、ユーザがネットワーク又はネットワークサービスの使用が許可されるべきかをネットワークが判定する処理である。アカウンティングは、ネットワークが、ユーザによって使用されたリソースに関する情報を収集する処理である。
【０００７】
従来技術では、ユーザ１０２が、訪問ネットワーク１００を使用したい場合、第１に、アクセスサーバ１０１から、アクセスネットワーク１００からのローカルＩＰアドレスを得る必要があるだろう。ユーザ端末は、アクセスネットワーク１００によってサポートされた任意の方法でローカルＩＰアドレスを得ることができる。共通のアプローチは、ＩＥＴＦによって定義されたダイナミックホストコンフィギュレーションプロトコル（ＤＨＣＰ）のような標準的ＩＰ自動設定プロトコルを使用することである。次に、ネットワーク１００においてユーザ認証を行なわなければならないだろう。
【０００８】
ユーザ認証を行なうために、ユーザは、自分の認証情報（例えば、ユーザ身元、信用証明、及びこのネットワークを使用するための要求）をネットワークに通信するために要求されるプロトコルを使用する必要があるだろう。そのような認証情報は、一般に、ユーザ１０２によって、ネットワーク内のアクセスサーバ１０１へ送られる。今日、異なるネットワークは、ユーザ認証のために、異なるプロトコル及び手順を使用するかもしれない。例えば、ワールドワイドウェブ（ＷＷＷ）ブラウザは、ユーザがその人の認証情報を入力するためのインタフェースとして使用することができる。認証情報は次に、インターネット技術特別調査委員会（ＩＥＴＦ）によって定義されたハイパーテキスト転送プロトコル（ＨＴＴＰ）あるいは安全なＨＴＴＰ（Ｓ−ＨＴＴＰ）を使用して、ネットワークに通信されうる。あるいは、ユーザは、ポイントトゥポイントプロトコル（ＰＰＰ）のようなＩＰ層より下のリンクレイヤプロトコルを使用してもよい。それは、ネットワークへ認証情報を伝えるための認証パケットを持っている。ＩＥＴＦ  ＰＡＮＡワーキンググループは、ネットワークにおいて、ユーザと制御エンティティ（例えば、アクセスサーバ）との間でユーザ認証情報を伝えるための標準的なＩＰ層プロトコルに関する作業をしている。
【０００９】
ユーザの認証情報を得ると、アクセスサーバ１０１は、ローカルＡＡＡサーバ１０３へユーザの認証情報を転送するＡＡＡクライアントとして動作するだろう。ローカルＡＡＡサーバ１０３は、ユーザを確証し、ネットワークアクセスを制御するために、アクセスサーバ１０１に必要とされた全ての設定情報を返信するだろう。ローカルＡＡＡサーバ１０３が、ユーザを確証するための十分な情報を持っていない場合、それらは、ユーザのホームネットワーク１０５内のＡＡＡサーバ１０４へ認証要求を転送するかもしれない。リモートサーバへ要求を転送するＡＡＡサーバは、一般にＡＡＡプロキシーと呼ばれる。
【００１０】
ＡＡＡクライアントとＡＡＡサーバとの間のシグナリングは、ＩＥＴＦによって定義されたあらゆるＡＡＡプロトコルを使用することができる。今日、ＲＡＤＩＵＳ（Remote Authentication Dial In User Service：ユーザサービスにおける遠隔認証ダイヤル）は、この目的のために最も広く展開されたＡＡＡプロトコルである。DIAMETERは、ＲＡＤＩＵＳの制限のうちのいくつかを克服するためにＩＥＴＦによって定義された新しいプロトコルである。ＲＡＤＩＵＳ及びDIAMETERはともにクライアント／サーバプロトコルである。例えば、ＲＡＤＩＵＳが使用される時、アクセスサーバは、ＲＡＤＩＵＳクライアントとして動作し、ＡＡＡサーバは、ＲＡＤＩＵＳサーバとして動作するだろう。
【００１１】
これらの既存の方法は、”caller pay”モデルに属する。ここでは、ネットワーク接続を開始するユーザが、ネットワークの使用に対する代価を払う。従って、ネットワークへのユーザによるアクセスは、ネットワーク毎に変わるかもしれない認証処理を必要とし、時間を費やし、完了までに複雑である。ＩＰ環境内におけるネットワークアクセスに対する簡単なモデルについて、当該技術分野においてニーズがある。電話通信の領域では、呼出者は、呼び出しサービスの認証又は許可を受ける必要が無い被呼者支払いモデルを、回路交換型の公衆交換電話網（ＰＳＴＮ）が提供することによって、無料電話が世界的に成功を収めた。しかしながら、無料のＩＰ（「ＴＩＰ」）ネットワークの概念は、当該技術においてよく開発されていない。したがって、本発明の目的は、パーティが、サービス要求及びネットワークアクセスが許可されるために必要な手続き一式に従うための通信セッションを開始する必要性を取り除くＴＩＰネットワークのためのシステム、方法、及びアーキテクチャを提供することにある。
【非特許文献１】P. Calhoun, "Diameter Base Protocol" IETF RFC 3588, September 2003
【発明の開示】
【００１２】
本出願は、"System and Method for Toll-Free Internet Protocol"と題され、２００３年１２月９日に出願された米国仮出願番号６０／５２８，１６７号の優先権の利益を主張する。
【００１３】
本発明は、ユーザが、ＩＰアクセスネットワーク、無料のＩＰ（ＴＩＰ）によって、ユーザに課金しない（「無料」）のアクセスを得ることを可能にする新しい方法、システム、及びネットワークアーキテクチャである。ＴＩＰによって、ネットワーク接続を開始するユーザは、アクセスネットワークの自分の使用の代価を払わない。
【００１４】
我々の発明の重要な概念はＴＩＰ宛先である。ＴＩＰ宛先は、無料のＩＰアドレス、無料のインターネットドメインネーム、無料のユニバーサルリソース識別子（ＵＲＩ）、又はユニバーサルリソースロケーター（ＵＲＬ）を含む異なる形式で表現することができる。我々の発明を記述するために、我々は実証的な例として無料のＩＰアドレスを使用する。しかしながら、ここで説明する方法、システム、及びアーキテクチャは、他のＴＩＰ宛先システムにも当てはまる。
【００１５】
我々の発明では、ＩＰアドレスを、宛先ＩＰアドレスとして伝えるＩＰパケットが、このパケットの送信者がアクセスネットワーク又はサービスプロバイダによって初めに認証される必要なくアクセスネットワークを通過することが許可されれば、ＩＰアドレスは無料ＩＰアドレス、すなわちＴＩＰアドレスである。
【００１６】
ＴＩＰアドレスと通信するためのアクセスネットワークの使用は、ＴＩＰ所有者と呼ばれるＴＩＰアドレス所有者によって支払われる。ＴＩＰ所有者は、ＴＩＰアドレスを含むＩＰアドレシング空間を所有する会社か個人である。アクセスネットワーク又はサービスプロバイダとのいかなる事前取り決めも無く、アクセスネットワーク又はサービスプロバイダによって認証される必要もないユーザは、アクセスネットワークへの無線又は有線の接続を確立するとすぐにＩＰパケットをＴＩＰアドレスに送ることができる。
【００１７】
ＴＩＰサーバ（機能エンティティ）は、ＴＩＰアドレスデータベースを保持し、かつ要求があると、ＩＰアドレスがＴＩＰアドレスであるかを検証するために使用される。ＴＩＰサーバは、集中又は分散される。ＴＩＰサーバを展開する会社はＴＩＰ管理者と呼ばれる。ＴＩＰ管理者は、ネットワーク又はサービスプロバイダ又はアグリゲータ、あるいはＩＳＰ、あるいは企業ネットワーキングかもしれない。
【００１８】
例えば８００又は８８８のようなユニークなプレフィックスを持っている無料電話番号と異なり、ＩＰアドレスは、それをＴＩＰアドレスとしてＴＩＰ管理者に登録することによってＴＩＰアドレスになることができる。この登録によって、このアドレスの所有者は、ＴＩＰアドレスと通信するために、アクセスネットワークの使用に対し、ポリシーに従って支払うことに合意する。ＴＩＰアドレスは、ＴＩＰネットワークプレフィックスによって識別されたネットワークの内部の任意のＩＰアドレスへの無料のアクセスを可能にするＩＰネットワークプレフィックスになりえる。
【００１９】
アクセスネットワークが無許可のＩＰソースあるいは宛先アドレスを持つＩＰパケットを受け取ると、宛先ＩＰアドレスがＴＩＰアドレスかどうかを尋ねるために、アクセスネットワークはＴＩＰサーバのもとへＴＩＰクエリメッセージを送る。ＴＩＰサーバからの応答は、ＴＩＰ応答メッセージと呼ばれる。宛先ＩＰアドレスがＴＩＰアドレスではない場合、アクセスネットワークはパケットを廃棄する。次に、アクセスネットワーク又はユーザは、ユーザを認証し許可する従来の手続きを始めるかもしれない。宛先アドレスがＴＩＰアドレスである場合、アクセスネットワークは、ユーザとＴＩＰアドレスとの間で、パケットが、ユーザとその人の端末を認証せずに通過することを許可する。
【００２０】
ＴＩＰ所有者は、アクセスネットワークあるいはサービスプロバイダとの直接的なビジネス関係を必要としない。ＴＩＰ所有者、そしてアクセスネットワーク／サービスプロバイダは、ＴＩＰ管理者とビジネス関係を確立する。ＴＩＰ管理者は、ＴＩＰ所有者の要求とのネットワークサービスを仲介する。
【発明を実施するための最良の形態】
【００２１】
図２は、我々の発明をサポートするための基本的な論理システムアーキテクチャを示す。我々の発明を実現するネットワークの基本要素は、アクセスネットワーク２１０、ＴＩＰ所有者のネットワーク２２０、及びＴＩＰ管理者機能２３０である。図２中に示すネットワーク内で、我々の発明的な方法を実現するための主要機能は、ＴＩＰ管理者２３０によって実施される。ＴＩＰ管理者機能２３０は、以下に示す２つの主要な論理構成要素、すなわちＴＩＰデータベース２３２とＴＩＰサーバ２３１とによって実現される。ＴＩＰデータベース２３２は、ＴＩＰ宛先及びそれらの関連するＴＩＰポリシーを格納する。ＴＩＰサーバ２３１は、ＴＩＰをサポートするためにＴＩＰ管理者によって必要とされる主なトランザクション処理を行なうために使用される。これらの機能は次のものを含んでいる。Ａ）ＩＰ宛先がＴＩＰ宛先であるかについての問い合わせをアクセスネットワーク２１０から受け取り、答えること。Ｂ）アクセスネットワーク２１０へＴＩＰポリシー情報を提供すること。Ｃ）ＴＩＰ所有者ネットワークからＴＩＰポリシーを動的に得るために、ＴＩＰ所有者ネットワーク２２０と対話すること。それは、利用及び課金情報もまた生成するかもしれない。第１に、ＴＩＰサーバ２３１は、アクセスネットワークとの、及びＴＩＰ所有者ネットワークとのＴＩＰ管理者のインタフェースである（そのようなインタフェースが実装される場合）。ＴＩＰサーバ２３１は、例えばディレクトリサービスのようなその他の付加価値サービスをサポートするためにも用いられる。
【００２２】
アクセスネットワーク内では、ＴＩＰをサポートするために必要とされる機能は、ＴＩＰクライアント内に実装される。具体的には、ＴＩＰクライアント２１１は以下のような主な機能を持っている。Ａ）ＴＩＰ宛先へ潜在的に向けられているパケットを、アクセスネットワーク２１０から受け取ること。Ｂ）宛先がＴＩＰ宛先であるかを判定するためにＴＩＰサーバ２３１に問い合わせること。Ｃ）ＴＩＰ宛先へ向けられたパケットを、ＴＩＰ宛先２２１の方へ転送すること。さらに、それは、ＴＩＰサーバへ送られる問い合わせの頻度を低減するために、ＴＩＰ管理者から学んだＴＩＰ宛先の一時的なキャッシュを保持するかもしれない。そして、任意の外部ＴＩＰ管理者とは独立しているＴＩＰポリシー、及びＴＩＰ宛先のローカルデータベースを保持するかもしれない。
【００２３】
ＴＩＰクライアント２１１及びＴＩＰサーバ２３１は何れも論理的なエンティティである。それらは、他のネットワークエンティティと同一場所に配置されているか、又は統合されているか、或いは他のネットワークエンティティと離れている新たなネットワークエンティティとして実現されるかもしれない。ＴＩＰクライアント２１１及びＴＩＰサーバ２３１も、統合されたエンティティとして実現されるかもしれない。システムスケーラビリティを増加し、システム性能を改善するために、ＴＩＰデータベース２３２とＴＩＰサーバ２３１とは、異なる地理的位置内に多くの物理的プラットフォームによって分散された方式で、潜在的に実現されるかもしれない。
【００２４】
ＴＩＰサーバ２３１は、階層的に実現されるかもしれない。例えば、局地的なＴＩＰサーバは、その地域に最も適切であるＴＩＰ宛先のサブセットを管理するために使用されるかもしれない。宛先がＴＩＰ宛先かどうかを局地的ＴＩＰサーバが知っていないのであれば、局地的ＴＩＰサーバは、ＴＩＰサーバ階層において次に高いレベルにおいて、その宛先がＴＩＰ宛先かどうかを判定することを助けるようＴＩＰサーバに依頼することができる。
【００２５】
図２では、我々の発明の基本動作も例証される。ユーザ２０１がＩＰアクセスネットワーク２１０に最初に到着した時、ユーザ２０１は、このアクセスネットワークからパケットを受け取るためにローカルのＩＰアドレスを取得する。ネットワークは、端末又はそのユーザを認証せずに、モバイル端末にＩＰアドレスを割り当てることができる。ＩＰアドレス割り当ては、例えば、インターネット技術特別調査委員会（ＩＥＴＦ）によって定義された動的なホスト設定プロトコル（ＤＨＣＰ）を用いてサポートされる。ローカルＩＰアドレスを得た後に、ユーザ２０１は、アクセスネットワークかサービスプロバイダを用いて、任意のネットワークへのユーザ認証及び許可手続きを最初に経る必要なく、ＴＩＰ宛先２２１へローカルアクセスネットワーク２１０によってパケットを送ることができる。
【００２６】
我々の発明の１つの実施例は、パケットがＩＰアクセスネットワーク内でどのように取り扱われるか（例えば、アクセスネットワークを横断することが許可され、廃棄され、別のネットワークエンティティに転送される）を決定するＩＰアクセスネットワーク２１０とともに配置されたポリシー施行ポイント（ＰＥＰ）２１２である。現在の当該技術におけるＰＥＰの例は、ＩＰアクセスサーバ、アクセスゲートウェイ、アクセスルータ、セキュリティプロキシ、無線アクセスポイント、ＧＰＲＳ（汎用パケット無線サービス）ネットワーク又は３ＧＰＰ（第３世代パートナシッププロジェクト）ネットワークにおけるゲートウエイＧＰＲＳサポートノード（ＧＧＳＮ）、３ＧＰＰ２（第３世代パートナシッププロジェクト２）ネットワークにおけるパケットデータサービングノード（ＰＤＳＮ）を含む。ＰＥＰ２１２がユーザ２０１からパケットを受け取り、そのソース及び／又は宛先ＩＰアドレスが許可されていないことを発見すると、ＰＥＰ２１２はこのパケットをＴＩＰクライアント２１１に転送する。あるいは、ＰＥＰ２１２は、このパケットをキャッシュし、ＴＩＰクライアント２１１にシグナリングパケットを送るかもしれない。ユーザパケットの宛先アドレスがＴＩＰアドレスかどうか確認するために、ＰＥＰ２１２上で配列することができるか、別個のエンティティとして実現することができるＴＩＰクライアント２１１は、ＴＩＰサーバ２３１にＴＩＰクエリメッセージに２１３を送る。
【００２７】
ＩＰアドレスがＴＩＰアドレスであることをＴＩＰ応答メッセージ２１４が示す場合、ＴＩＰクライアント２１１は、ユーザのローカルアドレス２０１とＴＩＰ宛先２２１との間をパケットが通過することを許可するようにＰＥＰ２１２に命じる。ＰＥＰ２１２が、そのパケットキャッシュ内に、このＴＩＰ宛先２２１に向けられたパケットをまだ持っているのであれば、ＰＥＰ２１２は、ネットワークへこれらのパケットを送る。このポイント以降、パケットは、任意のＴＩＰクライアント２１１あるいはＴＩＰサーバ２３１を通過する必要なしに、ユーザ２１２とＴＩＰ宛先２２１との間を直接通るだろう。
【００２８】
また、ユーザは、非ＴＩＰ宛先と通信するためにＴＩＰアドレスを使用してもよい。これを遂行するために２つの基本的な方法がある。
【００２９】
第１のアプローチは、非ＴＩＰ宛先と通信するためにユーザがＴＩＰ所有者のネットワークを使用することである。これは、ユーザの企業ネットワークあるいは公共サービスプロバイダネットワークに遠隔ダイアルアップし、次に、他の宛先へ行くためにそのネットワークを使用することに類似している。例えば、サービスプロバイダネットワーク中のセキュリティゲートウェイは、ＴＩＰアドレスによってアドレスされうる。ユーザは、ゲートウエイへのトンネル（例えば、ＩＰｓｅｃトンネル）を確立するためにＴＩＰアドレスを使用し、次に、サービスプロバイダのネットワークの内部又は外部の任意の宛先との間とパケットを送り受けするためにＴＩＰアドレスを使用することができる。
【００３０】
第２のアプローチは、サービスプロバイダと通信するために、ユーザが先ずＴＩＰアドレスを使用することである。サービスプロバイダはユーザを認証し、次に、ＴＩＰ管理者によって、任意の又は指定された非ＴＩＰ宛先との通信のためにユーザがこのアクセスネットワークを使用することを許可する。
【００３１】
ＴＩＰ所有者は、そのＴＩＰ宛先がどのように動的にアクセスされるかを動的に制御することができる。どのようにＴＩＰアドレスにアクセスすることができるかに対するより精巧な制御は、ポリシーベースの制御メカニズムを用いて達成することができ、例えばプリペイドＩＰ又はコレクトＩＰサービスのようなその他の付加価値サービスを可能にすることができる。ＴＩＰアドレスがどのようにしてアクセスされるべきかに関するポリシーはＴＩＰポリシーと呼ばれる。例えば、ＴＩＰポリシーは、ユーザがＴＩＰアドレスにアクセスできる時間の量、与えられた時間内にＴＩＰアドレスと通信するためのアクセスネットワークの使用に対してＴＩＰ所有者が支払う金額の量を指定する。
【００３２】
ＴＩＰポリシーを実施するために２つの基本的な方法がある。すなわち、ＴＩＰ管理者によってなされるアプローチと、ＴＩＰ所有者によってなされるアプローチである。ＴＩＰ管理者によってなされるアプローチでは、ＴＩＰ管理者はＴＩＰ所有者からの動的な情報に依存せずに、ポリシーに基づいた制御を行なう。ＴＩＰ所有者によってなされるアプローチによって、ＴＩＰ所有者はＴＩＰポリシーを動的に提供する。
【００３３】
ＴＩＰ管理者によってなされるポリシーベースの制御を用いて、ＴＩＰ所有者及びＴＩＰ管理者は、ＴＩＰポリシーに合意する。それは、ＴＩＰ管理者のデータベースにおいて設定される。ＴＩＰ管理者は、ＴＩＰクエリメッセージに回答し、かつＴＩＰアドレスへ向けられたパケットをどのように取り扱うかについてアクセスネットワークに指示するために、データベース内の情報を使用する。そのような予め設定されたＴＩＰポリシーは、例えば、任意のユーザに一様に適用することができる場合に使用される。
【００３４】
ＴＩＰ所有者によってなされるポリシー制御は、ＴＩＰ所有者にそのＴＩＰアドレスがどのようにアクセスされるかに対する更なる制御を与える。例えば、企業ネットワークは、そのネットワークにアクセスするためにその従業員がＴＩＰアドレスを使用することのみを許可するかもしれない。インターネットサービス又はアプリケーションプロバイダは、その支払い加入者だけにネットワークとサービスにアクセスすることを許可するためにＴＩＰアドレスを使用したいかもしれない。これらの場合では、ＴＩＰアドレスは、ＴＩＰ所有者のネットワーク内のゲートウエイを識別するかもしれない。そのようなゲートウエイは、例えば、ファイアウォールあるいはＡＡＡサーバかもしれない。ＴＩＰアドレスは、ユーザが、ゲートウエイと通信するためにアクセスネットワークを通ることを許可する。これは、その人のトラフィックがＴＩＰ所有者のイントラネットに入ることを許可すべきかを判定するためにユーザを認証するだろう。次に、ＴＩＰ所有者は、許可されたユーザのトラフィックを取り扱い、無許可のユーザからのトラフィックを拒否する方法について、ＴＩＰ管理者に動的に指示することができる。ＴＩＰ所有者は、許可チケットを発行することによりそうすることができる。これは、ユーザ認証と許可の結果に基づいた具体的なユーザのためのＴＩＰアドレスへのアクセスを制御するために、ＴＩＰ管理者及びＩＰアクセスネットワークによって必要とされるＴＩＰポリシー情報を含んでいる。
【００３５】
許可チケットを使用する実施例における我々の発明の基本動作が、図３中に示される。ＴＩＰ管理者３３０がアクセスネットワークからＴＩＰクエリメッセージ３１３を受け取る場合、先ず、初めのＴＩＰ応答メッセージ３１４を用いて応答し、予め定めた一時的で短い無料アクセス時間（例えば、ユーザがＴＩＰ所有者によって認証された時間）の間、ネットワークアクセスを許可し、かつ、更なるＴＩＰ応答メッセージを待つようにＴＩＰクライアント３１１に通知する。同時に、ＴＩＰ管理者３３０は、ユーザ３０１のための許可チケットを、ＴＩＰ所有者３２０に求める。ユーザ３０１は、一時的な無料アクセス時間の間、アクセスネットワーク３１０からＴＩＰ宛先３２１までの無料アクセスを得る。一旦ユーザ３０１がＴＩＰ所有者３２０と接触すれば、ＴＩＰ所有者３２０はユーザ３０１を認証する。肯定的な認証により、ＴＩＰ所有者ネットワーク３２０内のＴＩＰ所有者クライアント３２２は、ＴＩＰポリシー情報を伝える許可チケット３２３をＴＩＰ管理者３１０に発行する。ＴＩＰ管理者３１０は、ＴＩＰ応答メッセージ３２４内のアクセスネットワーク３１０へ、許可チケット内のＴＩＰポリシー情報を転送する。アクセスネットワークプロバイダのネットワーク内のＴＩＰクライアント３１１は、ＴＩＰ管理者３３０からのＴＩＰポリシー情報を記録し、ユーザ３０１のトラフィックがアクセスネットワーク３１０内でどのように取り扱われるべきかを判定するためにそれを使用する。ネットワークの悪意のある使用を防ぐために、許可が終了する場合、アクセスネットワークはユーザのパケット流れを阻止する。ＴＩＰシステムは、ＴＩＰ所有者が、ＴＩＰ宛先に配信されたパケットをどのように処理するかについていかなる制約も課さない。例えば、企業ネットワークは、ユーザを認証するために、そのファイアウォールと、仮想プライベートネットワーク手順及びプロトコルを使用するかもしれない。
【００３６】
（プロトコルインプリメント）  
我々のＴＩＰ発明をサポートするために、ＴＩＰクライアントとＴＩＰサーバとの間のインタフェースのためのシグナリングプロトコルが必要である。ＴＩＰサーバとＴＩＰ所有者ネットワークとの間のシグナリングプロトコルも、動的なＴＩＰ所有者によってなされるポリシー制御をサポートするために必要である。これらシグナリングプロトコルは、主として、認証と許可の目的のために使用される。そのような１つのプロトコルは、Diameterベースプロトコル（P. Calhoun, "Diameter Base Protocol" IETF RFC 3588, September 2003）（非特許文献１）として当該技術において知られており、これらのインタフェースを介したシグナリングのためのベースラインプロトコルとして使用することができる。Diameterは、ＩＰネットワークにおける将来のＡＡＡプロトコルと構想されている。Diameterを用いてサービスをサポートするために、この無料サービスのためにDiameterアプリケーションを開発する必要がある。
【００３７】
我々の発明は、Diameterクライアントとして動作するＴＩＰクライアント１８、及びDiameterサーバとして動作するＴＩＰサーバ上で動作するDiameter  ＴＩＰアクセスネットワークアプリケーション（ＴＡＮＡ）の使用を含む。
【００３８】
図４は、ＴＡＮＡのサンプルシグナリングフローを示す。Diameterは、回答メッセージとともに返答するDiameterサーバへ、Diameterクライアントが要求メッセージを送る要求及び回答モデルを使用する。ＴＡＮＡは、以下に示す新しい要求メッセージを使用する。第１に、AA-TIP-client-Request４１０は、ＩＰアドレスがＴＩＰアドレスかどうかを問い合わせ、かつＴＩＰポリシー情報を得るために、ＴＩＰサーバ４３０のもとへＴＩＰクライアント４２０によって送られる要求である。このメッセージは、図４における「ＴＩＰクエリ」メッセージの一例である。第２に、AA-TIP-client-Answer４４０は、AA-TIP-client-Request４１０に応答して、ＴＩＰクライアント４２０にＴＩＰサーバ４３０によって送られる回答である。このメッセージは、図４中で示される「ＴＩＰ応答」メッセージの一例である。第３に、Re-Auth-TIP-Client-Request４４１は、ＴＩＰアドレスのための許可の寿命を延長し、かつその他の許可パラメータを更新するための許可を求めるために、ＴＩＰサーバ４３０のもとへＴＩＰクライアント４２０によって送られる要求である。最後に、Re-Auth-TIP-Client-Answer４４３は、Re-Auth-TIP-Client-Request４１０に応答してＴＩＰクライアント４２０にＴＩＰサーバ４３０によって送られる回答である。
【数１】
2007536605.tif 000003
【００３９】
＜＊＞はそれぞれ、存在するに違いなく、メッセージ内に固定位置を持つ固定属性値ペア（ＡＶＰ）を示す。｛＊｝はそれぞれ、存在するに違いなく、メッセージ内のいかなる場所にも現われることができる要求されたＡＶＰを示す。また、［＊］はそれぞれ、メッセージ内のいかなる場所にも現われるかもしれないオプションのＡＶＰを示す。Diameter Heatherは、異なるDiameterメッセージを識別するために使用される情報を含んでいる。
【００４０】
属性は、ＴＩＰをサポートするために使用される。また、他の属性は標準的なDiameter属性である。Auth-Request-Typeは、ＴＩＰアプリケーションのために、１つの標準的なDiameter属性値AUTHORIZE-ONLYを備えた標準的なDiameter属性である。MH-IP-Addressは、Diameterセッションがそのために確立されることになっているモバイルのソースＩＰアドレスを伝えるために使用される新しい属性である。Access-Networkは、アクセスネットワークの識別子を伝えるために使用される新しい属性である。Target-IP-Addressは、それがＴＩＰアドレスかどうか確かめるためにＴＩＰサーバによって確認されるＩＰアドレスを伝える新しい属性である。
【００４１】
AA-TIP-client-Requestを処理した後、ＴＩＰサーバは、AA-TIP-client-Answerを返し、ＴＩＰクライアントに、AA-TIP-client-Requestの結果と、必要であれば、更にどの処理が、ＴＩＰクライアントによって講じられる必要があるのかを通知する。AA-TIP-client-Answerは、ＴＩＰをサポートするために必要な新しい属性とDiameterベースのプロトコルとの組み合わせによって要求される全ての属性を含んでいる。サンプルメッセージ形式は以下の通りである。
【数２】
2007536605.tif 000004
【００４２】
AA-TIP-client-Answerは、AA-TIP-client-Requestの結果のＴＩＰクライアントと、このＴＩＰクライアントが講じるべき更なる動作を伝えるためにResult-Codeを使用する。時々、ＴＩＰサーバは、AA-TIP-client-Requestを受け取ったとき、必要な全てのＴＩＰポリシー情報を持っているとは限らないかもしれない。例えば、ＴＩＰサーバがＴＩＰ所有者から許可チケットを動的に取得する必要がある場合、これが生じるかもしれない。そのような場合、ＴＩＰサーバは、目標ＩＰアドレスがＴＩＰアドレスであるとＴＩＰクライアントに伝えるための特別なResult-Code値を伝えるAA-TIP-client-Answerを用いて直ちにAA-TIP-client-Requestを回答するが、ＴＩＰクライアントは更なるＴＩＰポリシー情報を期待するべきである。下記は、AA-TIP-client-AnswerにおけるResult-Codeのサンプル値である。
【００４３】
2001 DIAMETER_SUCCESS：ＩＰアドレスはＴＩＰアドレスである。また、アクセスネットワークは、回答メッセージ内のＴＩＰポリシー属性に従ってユーザのトラフィックが通過することを許可すべきである。サンプルメッセージ形式におけるＴＩＰのポリシー属性は、次のものを含んでいる（他の属性が加えられるかもしれない）。１）Authorization-Lifetime：目標ＩＰアドレスへの無料アクセスが許可される期間を伝える標準的なDiameter属性。２）Auth-Grace-Period：Authorization-Lifetimeに対する延長を得るためにアクセスネットワークによって使用することができる、Authorization-Lifetime後の、延長期間を伝えるために使用される標準的なDiameter属性。３）Target-IP-Address：対応するAA-TIP-client-Requestメッセージ内のTarget-IP-Address属性からコピーされたTarget-IP-Addressを伝えるために使用される新たな属性。４）TIP-Network-Prefix：ＴＩＰ所有者ネットワーク内のＴＩＰネットワークプレフィックスを指定するネットワークプレフィクスを伝えるために使用される新たな属性。
【００４４】
2002 DIAMETER_LIMITED_SUCCESS：目標ＩＰアドレスはＴＩＰアドレスである。また、アクセスネットワークは、Authorization-Lifetime属性内で指定された制限時間に、Auth-Grace-Period内で指定された時間を加えた期間、ユーザのパケットが通過することを許可すべきである。ＴＩＰクライアントは、ＴＩＰサーバから新しいＴＩＰポリシー情報を期待するべきである。
【００４５】
5003 DIAMETER_AUTHENTICATION_REJECTED：目標ＩＰアドレスはＴＩＰアドレスではない。AA-TIP-client-Answerメッセージはまた、ＴＩＰ管理者にAA-TIP-client-Requestメッセージを拒否させる特定の理由を提供するために、「ＩＰアドレスはＴＩＰアドレスではない」というテキストError-Messageを伝える。
【００４６】
Authorization-Lifetimeが期限切れになった直後に、ユーザがＴＩＰアドレスへパケットを送り続ければ、Authorization-Lifetimeを延長することをＴＩＰサーバに要求するために、ＴＩＰクライアントはＴＩＰサーバのもとへRe-Auth-TIP-Client-Requestメッセージを送るだろう。このメッセージは、以下の例外を除いて、AA-TTP-Client-Requestメッセージと、同じ属性及び属性値を含んでいる。Auth-Request-Type属性は、Re-Auth-Request-Type属性と交換される。Re-Auth-Request-Type属性の値は、AUTHORIZE ONLYに設定される。Re-Auth-TIP-Client-Requestに対する回答メッセージ内のResult-Codeは、”2001”又は”5003”のみである。ＴＩＰクライアント又はサーバは、このセッションの別の終端へSession-Termination-Requestメッセージを送ることにより、Diameterセッションを終了することができる。
【００４７】
我々の発明の別の実施例では、我々は、Diameter  ＴＩＰ所有者アプリケーションを定義する。この実施例では、ＴＩＰサーバは、ＴＩＰポリシー情報を、ＴＩＰ所有者から動的に検索するために、Diameter  ＴＩＰ所有者アプリケーション（ＴＯＡ：Tip Owner Application）を使用する。ＴＩＰサーバは、Diameterクライアントとして動作し、ＴＩＰ所有者ネットワークは、Diameterサーバとして動作するだろう。図５は、ＴＡＮＡとＴＯＡの両方が、ＴＩＰアドレスへのアクセスを許可するために使用される場合におけるサンプルシグナリングフローを示す。ＴＩＰサーバ５１０は、ＴＩＰ所有者ネットワーク５３０にAA-TIP-admin-Requestメッセージ５１１を送ることにより、ＴＩＰ所有者５３０ネットワークとのDiameterセッションを開始する。この要求は、ＴＩＰ動作をサポートするために使用される新たな属性と、Diameterベースプロトコルとによって要求される属性を全て含んでいる。AA-TIP-admin-Requestメッセージのサンプル形式は以下の通りである。
【数３】
2007536605.tif 000005
【００４８】
AA-TIP-admin-Requestメッセージ５１１を受け取ると、ＴＩＰ所有者ネットワーク５３０は、ソースアドレス"MH-IP-Address"を持つ何れかのユーザが許可されたかを確認する。答えがＹｅｓである場合、ＴＩＰ所有者ネットワーク５３０は、そのようなユーザが、Authorization-Timeout期間の間に現れるかを確認するために待つ。そのようなユーザを検知するか、あるいは、Authorization-Timeout期間が終了すると、ＴＩＰ所有者ネットワーク５３０は、ＴＩＰサーバ５１０にAA-TIP-admin-Answerメッセージ５３１を返すだろう。このメッセージは、AA-TIP-admin-Requestメッセージ５１１の結果、及び特定のユーザのためのＴＩＰポリシーを含むだろう。AA-TIP-admin-Answerのサンプル形式は以下の通りである。
【数４】
2007536605.tif 000006
【００４９】
Result-Codeのサンプル値は以下を含む。１）2001 DIAMETER_SUCCESS：このユーザは許可され、ＴＩＰアドレスへのそのアクセスは、AA-TIP-admin-Answer messageメッセージ内のＴＩＰポリシー属性に基づいて制御されるべきである。２）5004 DIAMETER_AUTHENTICATION_REJBCTED：ＴＩＰ所有者又は許可失敗による拒否。
【００５０】
ＴＩＰ許可チケットをサポートするために、ＴＡＮＡに、更に以下に示す２つの追加メッセージを加える必要がある。第１に、AA-TIP-admin-Answer messageを受け取ると、ＴＩＰサーバは、アクセスネットワーク内のＴＩＰクライアントに追加のＴＩＰポリシー情報を提供するAccess-Granted-Messageを送る。Access-Granted-Messageサンプル形式は以下の通りである。
【数５】
2007536605.tif 000007
【００５１】
第２に、ＴＩＰクライアントは、Access-Granted-AckメッセージとともにAccess-Granted-Messageに応答する。Access-Granted-Ackメッセージのサンプル形式は以下の通りである。
【数６】
2007536605.tif 000008
【００５２】
Access-Granted-Ackメッセージは、Access-Granted-Messageの処理が成功するとResult-Code値２００１を伝える。Access-Granted-Messageの処理においてエラーが生じれば、Access-Granted-Ackメッセージは、エラーを示すためのResult-Code値を伝える。Error-Message及びFailed-AVPフィールドは、さらに追加のエラーメッセージを含んでいるかもしれない。
【００５３】
先の詳細な記述は、提供された無料のＩＰネットワークサービスのための方法及びアーキテクチャを示し、提案された使用可能なプロトコルについて記述している。本発明の上述された実施例は、実例となるようにのみ意図されている。多数の代替実施例が、特許請求の範囲の精神及び範囲から逸脱することなく、当該技術分野における熟練者によって考案されるかもしれない。一例として、ＩＰベースのアクセスネットワークによって他の新たな付加価値サービスをサポートするために、ここに記述された発明が使用されるかもしれない。限定されていないが、そのような他のサービスも、以下を含むかもしれない。
【００５４】
選択的な請求：選択的な請求によって、ユーザは、選択された宛先の集合と通信する場合のみ、請求が発生する。そのような宛先は、例えば、付加価値コンテンツ又はサービスを提供するかもしれない。選択された宛先の集合と通信するためのネットワークの使用は、これら宛先によって支払われる。ユーザは、他の宛先と無料で通信するために、このネットワークを使用することを許可されるかもしれない。選択的な請求もまた、「発呼者支払い」モデルと共に使用されてもよい。そのような場合、ユーザは、選択された宛先の集合における何れかの宛先と通信する場合にのみ課金されるだろう。ユーザは、他の宛先と無料で通信するためにアクセスネットワークを使用してもよい。
【００５５】
プイペイドＩＰ：ユーザは、アクセスネットワークオペレータから独立しているかもしれないプリペイドＩＰサービスプロバイダへの無料アクセスを得るために先ずＴＩＰを使用してもよい。プリペイドＩＰサービスプロバイダは、ユーザを認証し、その人のプリペイドアカウントを確認し、次に、ユーザがアクセスネットワークを与えられた期間の間使用することを許可するためにアクセスネットワークを許可する。この許可された時間の間、ユーザも、非ＴＩＰ宛先と通信することが認められるかもしれない。ＴＩＰによって、プリペイドＩＰサービスプロバイダは、このアクセスネットワークのユーザによる使用を許可するためには、必ずしもこのアクセスネットワークと直接に対話する必要はない。
【００５６】
コレクトＩＰ呼び：ユーザは、まず、アクセスネットワークオペレータから独立しているかもしれないコレクトＩＰ呼び出しサービスプロバイダへの無料アクセスを得るためにＴＩＰを使用する。その後、もしも最終的な宛先が、この接続に対する支払いに合意するのであれば、コレクトＩＰ呼び出しサービスプロバイダは、最終的な宛先へユーザトラフィックを転送するか、あるいはアクセスネットワークを許可して、このユーザが、最終的な宛先へ直接接続できるようにする。ＴＩＰを用いて、サービスプロバイダは、このアクセスネットワークのユーザによる使用を許可するために、このアクセスネットワークと必ずしも直接的に対話する必要はない。
【００５７】
ＴＩＰは、コンテンツプロバイダ（例えば、オンライン販売）が、誰でもそのＷＷＷサイトに無料でアクセスする便利な方法を提供することを可能にする。
【００５８】
我々の発明は、ローミングしているユーザ又は端末が、異なるオペレータ／アグリゲータによって使用される異種混合のユーザトゥネットワーク許可プロトコル及び異種混合の請求計画を扱う必要を無くすことによって、異なるオペレータ／アグリゲータのホットスポット、及びホットスポットと携帯ネットワークとを横切るシームレスなローミングをサポートするために使用することができる。ＴＩＰによって、ユーザは、異なるアクセスネットワークオペレータのローミング料金、又は可変料金プランを心配する必要がなくなるであろう。
【００５９】
我々の発明は、ビジネス旅行者のための高速アクセスのコストを潜在的に低減しうる。今日、ビジネス旅行者は、一般に、ホテルにおけるインターネット接続に対して毎日料金を払う。ＴＩＰは、旅行者がネットワークを使用する場合に限り、企業に対してコストを発生させることを可能にする。
【図面の簡単な説明】
【００６０】
【図１】図１は、アクセス制御を備えた従来技術ＩＰネットワークを示す。
【図２】図２は、我々の発明に従った１つの実施例である無料ＩＰネットワークを示す。
【図３】図３は、第２の実施例、すなわち動的に支援された制御を備えた無料ＩＰネットワークを示す。
【図４】図４は、我々の発明の１つの実施例に従うサンプルシグナリングフローとして示す。
【図５】図５は、我々の発明の別の実施例に従う第２の例示的なシグナリングフローである。
【図１】
2007536605.tif 000009
【図２】
2007536605.tif 000010
【図３】
2007536605.tif 000011
【図４】
2007536605.tif 000012
【図５】
2007536605.tif 000013