JP4629679B2

JP4629679B2 - 無料のインターネットプロトコル通信サービスのための方法及びシステム

Info

Publication number: JP4629679B2
Application number: JP2006543984A
Authority: JP
Inventors: ジャン、タオ; タウイル、ミリアム; マドハニ、スニル; アグラワル、プラシマ; 利一児玉
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2003-12-09
Filing date: 2004-12-09
Publication date: 2011-02-09
Anticipated expiration: 2024-12-09
Also published as: EP1695185A2; WO2005057370A3; EP1695185B1; WO2005057370A2; EP1695185A4; JP2007536605A; US7848312B2; CA2549112A1; CA2549112C; US20050147084A1

Description

本発明は、一般に、異なるネットワークオペレータによって操作されうるＩＰベースのアクセスネットワークによって、ユーザに課金しない（「無料の」）接続を提供することに関する。

ＩＥＥＥ８０２．１１を使用する無線ローカルエリア・ネットワークのようなＩＰベースのアクセスネットワークは、家庭、企業、及びパブリックホットスポット（例えば空港、ホテル、喫茶店、列車駅、ガソリンスタンド、公園、そして道路及び高速道路沿い）の中で急速に世界的に展開している。例えばＩＥＥＥ８０２．１６のようなより高速かつ広範囲の無線ＩＰアクセスネットワークが出現している。

今日、ユーザには、ＩＰアクセスネットワークを使用する許可を得るための２つの基本的な方法がある。第１のアプローチは、アクセスネットワーク又はサービスプロバイダへサービス加入をすることをユーザに要求する。ユーザがアクセスネットワークを使用することを認められる前に、ユーザは、自分の身元、信用証明、及びサービス要求を、ネットワーク内のポリシー判定ポイント（例えば、認証及び許可サーバ）へ通信するために、ネットワーク又はサービスプロバイダによって義務付けられた手順、アクセス制御インタフェース、ソフトウェア、及びプロトコルを使用する必要がある。ポリシー判定ポイントは、ユーザを認証し、特定のアクセスネットワークの使用を許可するために、ユーザのサービス加入情報を使用する。多くのプロバイダのネットワークを使用するために、ユーザは各ネットワークプロバイダとのサービス加入を維持する必要がある。加入者が、多数のサービス加入をすることなく、他のプロバイダのネットワークを使用できるように、サービスプロバイダは、他のサービス又はネットワークのプロバイダとローミング合意を確立することができる。しかしながら、それぞれが小さな受信地域（フットプリント）を提供している多くのネットワーク及びサービスプロバイダが存在しているパブリックホットスポットマーケット内で、それを行うのはしばしば困難である。

第２の既存のアプローチは、ユーザがネットワークの使用を試みる場合に、ネットワークが、ネットワーク利用に対する支払いをユーザに要求することである。それは、サービス加入をユーザに要求しない。代わりに、ネットワークを使用するというユーザの試み（例えば、ユーザの発信パケット）は、ネットワークによってインターセプト（トラップ）される。ネットワークは、このトラップされたトラフィックを、アクセスネットワークプロバイダから離れているサービスプロバイダによって操作されているかもしれないＡＡＡ（認証、許可、及びアカウンティング）サーバへ転送する。ＡＡＡサーバは、ユーザにネットワーク使用を許可する前に、ネットワーク利用に対する支払い、及びクレジットカード情報の提供に合意するようにユーザに促す。異なるアクセスネットワークは、ネットワークアクセスを制御するために、異なるプロトコル、ソフトウェア、ユーザインターフェース、及び認証手続きを使用するかもしれない（例えば、ウェブベースのアプローチ、ＩＥＥＥ８０２．１ｘ、及び適切な解決策）。異なるネットワークを使用するために、ユーザ端末は、これらの異なるプロトコル及びソフトウェアを装備しなければならない。また、ユーザは、これらの異なるインタフェース及び認証手続きに対処しなければならない。

典型的な従来技術ＩＰネットワークアクセスシステムが図１に示されている。ユーザ１０２によって訪問されている訪問アクセスネットワーク１００内のアクセスサーバ１０１は、ユーザからトラフィックを受け取り、ユーザのトラフィックが、アクセスサーバ１０１の向こうのネットワークの部分に入ることを許可すべきかを判定する。アクセスサーバは一般に、ネットワークアクセスサーバー（ＮＡＳ）、アクセスゲートウェイ、あるいはアクセスルータとも呼ばれる。

アクセスサーバ１０１は、例えば認証、許可、アカウンティング（ＡＡＡ）のようなネットワークアクセス制御機能をサポートする際に重要な構成要素である。認証は、それによってネットワークが、ユーザ１０２の身元を確認し、時々、ユーザも、そのネットワークの身元を確認する処理である。許可は、ユーザがネットワーク又はネットワークサービスの使用が許可されるべきかをネットワークが判定する処理である。アカウンティングは、ネットワークが、ユーザによって使用されたリソースに関する情報を収集する処理である。

従来技術では、ユーザ１０２が、訪問ネットワーク１００を使用したい場合、第１に、アクセスサーバ１０１から、アクセスネットワーク１００からのローカルＩＰアドレスを得る必要があるだろう。ユーザ端末は、アクセスネットワーク１００によってサポートされた任意の方法でローカルＩＰアドレスを得ることができる。共通のアプローチは、ＩＥＴＦによって定義されたダイナミックホストコンフィギュレーションプロトコル（ＤＨＣＰ）のような標準的ＩＰ自動設定プロトコルを使用することである。次に、ネットワーク１００においてユーザ認証を行なわなければならないだろう。

ユーザ認証を行なうために、ユーザは、自分の認証情報（例えば、ユーザ身元、信用証明、及びこのネットワークを使用するための要求）をネットワークに通信するために要求されるプロトコルを使用する必要があるだろう。そのような認証情報は、一般に、ユーザ１０２によって、ネットワーク内のアクセスサーバ１０１へ送られる。今日、異なるネットワークは、ユーザ認証のために、異なるプロトコル及び手順を使用するかもしれない。例えば、ワールドワイドウェブ（ＷＷＷ）ブラウザは、ユーザがその人の認証情報を入力するためのインタフェースとして使用することができる。認証情報は次に、インターネット技術特別調査委員会（ＩＥＴＦ）によって定義されたハイパーテキスト転送プロトコル（ＨＴＴＰ）あるいは安全なＨＴＴＰ（Ｓ−ＨＴＴＰ）を使用して、ネットワークに通信されうる。あるいは、ユーザは、ポイントトゥポイントプロトコル（ＰＰＰ）のようなＩＰ層より下のリンクレイヤプロトコルを使用してもよい。それは、ネットワークへ認証情報を伝えるための認証パケットを持っている。ＩＥＴＦＰＡＮＡワーキンググループは、ネットワークにおいて、ユーザと制御エンティティ（例えば、アクセスサーバ）との間でユーザ認証情報を伝えるための標準的なＩＰ層プロトコルに関する作業をしている。

ユーザの認証情報を得ると、アクセスサーバ１０１は、ローカルＡＡＡサーバ１０３へユーザの認証情報を転送するＡＡＡクライアントとして動作するだろう。ローカルＡＡＡサーバ１０３は、ユーザを確証し、ネットワークアクセスを制御するために、アクセスサーバ１０１に必要とされた全ての設定情報を返信するだろう。ローカルＡＡＡサーバ１０３が、ユーザを確証するための十分な情報を持っていない場合、それらは、ユーザのホームネットワーク１０５内のＡＡＡサーバ１０４へ認証要求を転送するかもしれない。リモートサーバへ要求を転送するＡＡＡサーバは、一般にＡＡＡプロキシーと呼ばれる。

ＡＡＡクライアントとＡＡＡサーバとの間のシグナリングは、ＩＥＴＦによって定義されたあらゆるＡＡＡプロトコルを使用することができる。今日、ＲＡＤＩＵＳ（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４１０に応答してＴＩＰクライアント４２０にＴＩＰサーバ４３０によって送られる回答である。

＜＊＞はそれぞれ、存在するに違いなく、メッセージ内に固定位置を持つ固定属性値ペア（ＡＶＰ）を示す。｛＊｝はそれぞれ、存在するに違いなく、メッセージ内のいかなる場所にも現われることができる要求されたＡＶＰを示す。また、［＊］はそれぞれ、メッセージ内のいかなる場所にも現われるかもしれないオプションのＡＶＰを示す。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ベースのプロトコルとの組み合わせによって要求される全ての属性を含んでいる。サンプルメッセージ形式は以下の通りである。

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メッセージのサンプル形式は以下の通りである。

AA-TIP-admin-Requestメッセージ５１１を受け取ると、ＴＩＰ所有者ネットワーク５３０は、ソースアドレス"MH-IP-Address"を持つ何れかのユーザが許可されたかを確認する。答えがＹｅｓである場合、ＴＩＰ所有者ネットワーク５３０は、そのようなユーザが、Authorization-Timeout期間の間に現れるかを確認するために待つ。そのようなユーザを検知するか、あるいは、Authorization-Timeout期間が終了すると、ＴＩＰ所有者ネットワーク５３０は、ＴＩＰサーバ５１０にAA-TIP-admin-Answerメッセージ５３１を返すだろう。このメッセージは、AA-TIP-admin-Requestメッセージ５１１の結果、及び特定のユーザのためのＴＩＰポリシーを含むだろう。AA-TIP-admin-Answerのサンプル形式は以下の通りである。

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サンプル形式は以下の通りである。

第２に、ＴＩＰクライアントは、Access-Granted-AckメッセージとともにAccess-Granted-Messageに応答する。Access-Granted-Ackメッセージのサンプル形式は以下の通りである。

Access-Granted-Ackメッセージは、Access-Granted-Messageの処理が成功するとResult-Code値２００１を伝える。Access-Granted-Messageの処理においてエラーが生じれば、Access-Granted-Ackメッセージは、エラーを示すためのResult-Code値を伝える。Error-Message及びFailed-AVPフィールドは、さらに追加のエラーメッセージを含んでいるかもしれない。

先の詳細な記述は、提供された無料のＩＰネットワークサービスのための方法及びアーキテクチャを示し、提案された使用可能なプロトコルについて記述している。本発明の上述された実施例は、実例となるようにのみ意図されている。多数の代替実施例が、特許請求の範囲の精神及び範囲から逸脱することなく、当該技術分野における熟練者によって考案されるかもしれない。一例として、ＩＰベースのアクセスネットワークによって他の新たな付加価値サービスをサポートするために、ここに記述された発明が使用されるかもしれない。限定されていないが、そのような他のサービスも、以下を含むかもしれない。

選択的な請求：選択的な請求によって、ユーザは、選択された宛先の集合と通信する場合のみ、請求が発生する。そのような宛先は、例えば、付加価値コンテンツ又はサービスを提供するかもしれない。選択された宛先の集合と通信するためのネットワークの使用は、これら宛先によって支払われる。ユーザは、他の宛先と無料で通信するために、このネットワークを使用することを許可されるかもしれない。選択的な請求もまた、「発呼者支払い」モデルと共に使用されてもよい。そのような場合、ユーザは、選択された宛先の集合における何れかの宛先と通信する場合にのみ課金されるだろう。ユーザは、他の宛先と無料で通信するためにアクセスネットワークを使用してもよい。

プイペイドＩＰ：ユーザは、アクセスネットワークオペレータから独立しているかもしれないプリペイドＩＰサービスプロバイダへの無料アクセスを得るために先ずＴＩＰを使用してもよい。プリペイドＩＰサービスプロバイダは、ユーザを認証し、その人のプリペイドアカウントを確認し、次に、ユーザがアクセスネットワークを与えられた期間の間使用することを許可するためにアクセスネットワークを許可する。この許可された時間の間、ユーザも、非ＴＩＰ宛先と通信することが認められるかもしれない。ＴＩＰによって、プリペイドＩＰサービスプロバイダは、このアクセスネットワークのユーザによる使用を許可するためには、必ずしもこのアクセスネットワークと直接に対話する必要はない。

コレクトＩＰ呼び：ユーザは、まず、アクセスネットワークオペレータから独立しているかもしれないコレクトＩＰ呼び出しサービスプロバイダへの無料アクセスを得るためにＴＩＰを使用する。その後、もしも最終的な宛先が、この接続に対する支払いに合意するのであれば、コレクトＩＰ呼び出しサービスプロバイダは、最終的な宛先へユーザトラフィックを転送するか、あるいはアクセスネットワークを許可して、このユーザが、最終的な宛先へ直接接続できるようにする。ＴＩＰを用いて、サービスプロバイダは、このアクセスネットワークのユーザによる使用を許可するために、このアクセスネットワークと必ずしも直接的に対話する必要はない。

ＴＩＰは、コンテンツプロバイダ（例えば、オンライン販売）が、誰でもそのＷＷＷサイトに無料でアクセスする便利な方法を提供することを可能にする。

我々の発明は、ローミングしているユーザ又は端末が、異なるオペレータ／アグリゲータによって使用される異種混合のユーザトゥネットワーク許可プロトコル及び異種混合の請求計画を扱う必要を無くすことによって、異なるオペレータ／アグリゲータのホットスポット、及びホットスポットと携帯ネットワークとを横切るシームレスなローミングをサポートするために使用することができる。ＴＩＰによって、ユーザは、異なるアクセスネットワークオペレータのローミング料金、又は可変料金プランを心配する必要がなくなるであろう。

我々の発明は、ビジネス旅行者のための高速アクセスのコストを潜在的に低減しうる。今日、ビジネス旅行者は、一般に、ホテルにおけるインターネット接続に対して毎日料金を払う。ＴＩＰは、旅行者がネットワークを使用する場合に限り、企業に対してコストを発生させることを可能にする。

図１は、アクセス制御を備えた従来技術ＩＰネットワークを示す。図２は、我々の発明に従った１つの実施例である無料ＩＰネットワークを示す。図３は、第２の実施例、すなわち動的に支援された制御を備えた無料ＩＰネットワークを示す。図４は、我々の発明の１つの実施例に従うサンプルシグナリングフローとして示す。図５は、我々の発明の別の実施例に従う第２の例示的なシグナリングフローである。

Claims

課金不要なアクセスをユーザに提供することを可能にするネットワークアーキテクチャシステムであって、
前記ユーザがアクセスするアクセスネットワークに含まれるＴＩＰ（Toll Free IP）クライアントと、
前記ＴＩＰクライアントに接続されたＴＩＰサーバと、
前記アクセスネットワークに含まれ、前記ユーザからパケットを受け取るアクセスサーバとを備え、
前記アクセスサーバは、前記ＴＩＰクライアントを介して、前記ＴＩＰサーバに対して、前記パケットに含まれているＩＰアドレスが、ＴＩＰアドレスであるかを判定するように問い合わせ、
前記ＴＩＰサーバは、ＴＩＰ宛先に関する情報を含んでいるＴＩＰＩＰ宛先データベースを更に備え、前記ＴＩＰクライアントからの問い合わせに応じて、前記ＴＩＰＩＰ宛先データベースを参照することと、前記ユーザが前記アクセスネットワークによって認証される必要なく、前記パケットをＴＩＰ宛先との間で授受することとによって、前記パケットに含まれているＩＰアドレスが、ＴＩＰ宛先であるかを判定するネットワークアーキテクチャシステム。
請求項１のネットワークアーキテクチャシステムにおいて、
前記パケットに含まれているＩＰアドレスが、ＴＩＰ宛先であると判定された場合、前記ＴＩＰ宛先の所有者は、前記ＴＩＰ宛先へ送られた任意のパケットについて課金されるネットワークアーキテクチャシステム。
請求項１のネットワークアーキテクチャシステムにおいて、
ＴＩＰ宛先を含むＴＩＰ宛先ネットワークに、どのユーザが接続することができるかを管理するポリシーを、前記ＴＩＰＩＰ宛先データベースに格納するネットワークアーキテクチャシステム。
請求項３のネットワークアーキテクチャシステムにおいて、
前記ＴＩＰサーバは更に、前記ポリシーを、前記ＴＩＰＩＰ宛先データベースから受け取る手段を備えたネットワークアーキテクチャシステム。
請求項４のネットワークアーキテクチャシステムにおいて、
前記ＴＩＰサーバは更に、前記受け取ったポリシーを、前記ＴＩＰクライアントへ送る手段を備え、前記ＴＩＰクライアントは更に、前記ポリシーにしたがって、前記ユーザの前記ＴＩＰ宛先ネットワークへのアクセスを制御する手段を備えたネットワークアーキテクチャシステム。
ＩＰベースのネットワークへのＴＩＰ（Toll Free Internet Protocol）アクセスを提供する方法であって、
アクセスネットワークへのアクセスを試みるユーザから、前記アクセスネットワークに含まれるアクセスサーバが受け取ったパケットが、ＴＩＰ宛先であると識別されたＩＰアドレスを含んでいるかを判定することと、
前記ＩＰアドレスがＴＩＰ宛先であれば、前記ユーザが前記アクセスネットワークによって認証される必要なく、前記アクセスサーバが、前記識別されたＴＩＰ宛先との間で前記パケットを授受することと
の各ステップを含み、
前記判定するステップは更に、
前記アクセスサーバが、前記アクセスネットワークに含まれるＴＩＰクライアントからＴＩＰサーバへ、前記パケットのＩＰアドレスを含む問い合わせを送ることと、
前記問い合わせに応答して、前記ＴＩＰサーバにおいて、ＴＩＰ宛先に関する情報を含むＴＩＰＩＰ宛先データベースが参照されることによって、前記ＩＰアドレスがＴＩＰ宛先であるかを確認することと、
前記ＴＩＰクライアントに、前記ＴＩＰサーバから応答メッセージを送り返すことであって、前記応答メッセージは、前記ＩＰアドレスがＴＩＰ宛先かどうか示すことと、
前記ＩＰアドレスがＴＩＰ宛先であると前記応答メッセージが示すのであれば、前記アクセスサーバが、前記ユーザから前記アクセスネットワークを通って前記ＴＩＰ宛先へと、後の全てのパケットを転送することと
の各ステップを含む方法。
請求項６の方法において、
前記ＴＩＰクライアントが、前記ＴＩＰサーバを介してポリシー情報を得るステップを更に含む方法。
請求項７の方法において、
前記ＴＩＰサーバは、前記ＴＩＰクライアントへ前記ポリシー情報を送り、前記ＴＩＰクライアントは、前記アクセスネットワークにおいて前記ポリシーを実行し、前記ユーザの前記ＴＩＰ宛先へのアクセスを制御するステップを更に含む方法。
ＴＩＰ（Toll Free Internet Protocol）アクセス管理を提供するサーバであって、
データベース内にＴＩＰ宛先アドレスを格納する手段であって、前記格納する手段は、アクセスネットワークから論理的に独立している手段と、
前記データベースを参照することによって、前記アクセスネットワークにおいてユーザから受け取られたＩＰパケットが、ＴＩＰ宛先アドレスを含んでいるかを判定する手段と、
前記ＩＰパケットを送信したユーザが、前記アクセスネットワークによって認証される必要なく、前記パケットをＴＩＰ宛先との間で授受することを可能にするために、前記ＩＰパケットがＴＩＰ宛先アドレスを含んでいる場合、前記ＩＰパケットが前記ＴＩＰ宛先アドレスを含んでいることを示すメッセージを、前記サーバから前記アクセスネットワークへ送り、前記アクセスネットワークに通知する手段と
を備えたサーバ。
請求項９のサーバにおいて、
前記アクセスネットワークにおいて受け取られた前記ＩＰパケットが、ＴＩＰ宛先アドレスに向けられたものであるかを問い合わせるために、前記格納する手段にアクセスする手段を更に備えたサーバ。
請求項１０のサーバにおいて、
前記アクセスする手段は更に、前記格納する手段から受け取った情報を、前記アクセスネットワークに配置されたＴＩＰクライアントへ転送する手段を備えたサーバ。
請求項１１のサーバにおいて、
前記アクセスする手段は更に、前記格納する手段に格納されたポリシー情報にアクセスする手段を備えたサーバ。