(57)【要約】  複数の加入者装置のうちの１つの加入者装置を、ネットワークに、複数のネットワークポータル装置のうちのそれぞれのネットワークポータル装置に接続するための、通信ネットワークにおける方法。本方法は、複数のネットワークポータル装置（１２，１３，１４）に関連付けられた複数のネットワークポータルアドレス及び、各々が複数の加入者装置のそれぞれの１つを識別する複数の加入者識別子を格納するポータル集約サーバ（７）を提供するステップを含む。本方法は、ポータル集約サーバで実施されるステップであって、ネットワークに接続するための接続要求を、加入者装置（２）から受信するステップを含む。該要求は、加入者装置に関連付けられた加入者識別子を備える。本方法は、受信した加入者識別子をネットワークポータルアドレスにマッピングすると共に、そのようにマッピングされたネットワークポータルアドレスに接続要求をリダイレクトするステップを含む。【選択図】図１
2019537176.tif 000002
【特許請求の範囲】
【請求項１】
複数の加入者装置のうちの１つの加入者装置を、ネットワークに、複数のネットワークポータル装置のうちのそれぞれのネットワークポータル装置に接続するための、通信ネットワークにおける方法であって、
前記方法は、
前記複数のネットワークポータル装置に関連付けられた複数のネットワークポータルアドレス及び、各々が前記複数の加入者装置のそれぞれの１つを識別する複数の加入者識別子を格納するポータル集約サーバを提供するステップと、
前記ポータル集約サーバにおいて、前記ネットワークに接続するための接続要求を前記加入者装置から受信するステップであって、前記接続要求は、前記加入者装置に関連付けられた前記加入者識別子を備える、ステップと、前記受信した加入者識別子を前記ネットワークポータルアドレスにマッピングすると共に、そのようにマッピングされた前記ネットワークポータルアドレスに前記接続要求をリダイレクトするステップと、
を含む、方法。
【請求項２】
請求項１に記載の方法であって、
前記ポータル集約サーバにおいて、
前記受信した加入者識別子を使用して、認証プロトコルを加入者装置に適用するステップを含み、前記リダイレクトするステップは、前記加入者装置がそのように認証されるという条件の下に行われる、方法。
【請求項３】
請求項１又は２に記載の方法であって、
前記ポータル集約サーバにおいて、
前記複数のネットワークポータルアドレス及び前記複数の加入者識別子を備えるポータルリダイレクトマップを格納するステップ、
を含み、
前記マッピングするステップは、前記受信した加入者識別子を、前記ポータルリダイレクトマップ内に格納された加入者識別子に一致させると共に、前記受信した加入者識別子に一致する前記加入者識別子に関連させて、前記ポータルリダイレクトマップ内に格納されたネットワークポータルアドレスを識別するステップを含む、方法。
【請求項４】
請求項１から３のいずれか一項に記載の方法であって、
前記ポータル集約サーバにおいて、
前記受信した加入者識別子を、前記複数のネットワークポータルアドレスにマッピングするステップと、
そのようにマッピングされた前記複数のネットワークポータルアドレスに、前記接続要求をリダイレクトするステップと、
を含む、方法。
【請求項５】
請求項１から４のいずれか一項に記載の方法であって、
前記ポータル集約サーバにおいて、
前記複数の加入者装置から、前記ネットワークに接続するための接続要求を受信するステップであって、各要求は、それぞれの加入者装置に関連付けられた前記加入者識別子を備える、ステップと、
受信した各加入者識別子を、共通のネットワークポータルアドレスにマッピングするステップと、
そのようにマッピングされた前記共通のネットワークポータルアドレスに、前記複数の接続要求をリダイレクトするステップと、
を含む、方法。
【請求項６】
複数の加入者装置のうちの１つの加入者装置を、複数のネットワークポータル装置のうちのそれぞれのネットワークポータル装置に接続するためのネットワーク通信装置であって、
前記装置は、
前記複数のネットワークポータル装置に関連付けられた複数のネットワークポータルアドレス及び、各々が前記複数の加入者装置のそれぞれの１つを識別する複数の加入者識別子を格納するように取り決められたポータル集約サーバ、
を含み、
前記ポータル集約サーバは、ネットワークに接続するための接続要求を、前記加入者装置から受信するように取り決められ、前記接続要求は、前記加入者装置に関連付けられた前記加入者識別子を備え、且つ、前記ポータル集約サーバは、前記受信した加入者識別子を前記ネットワークポータルアドレスにマッピングすると共に、そのようにマッピングされた前記ネットワークポータルアドレスに前記接続要求をリダイレクトすることによって、受信した接続要求に応答する、ネットワーク通信装置。
【請求項７】
請求項６に記載のネットワーク通信装置であって、
前記ポータル集約サーバは、前記受信した加入者識別子を使用して、認証プロトコルを加入者装置に適用するように取り決められると共に、加入者装置がそのように認証されるという条件の下に、前記接続要求を前記マッピングされたネットワークポータルアドレスにリダイレクトするように取り決められる、ネットワーク通信装置。
【請求項８】
請求項６又は７に記載のネットワーク通信装置であって、
前記ポータル集約サーバは、前記複数のネットワークポータルアドレス及び前記複数の加入者識別子を備えるポータルリダイレクトマップを格納するように取り決められ、
前記マッピングするステップは、前記受信した加入者識別子を前記ポータルリダイレクトマップ内に格納された加入者識別子に一致させると共に、前記受信した加入者識別子に一致する前記加入者識別子に関連させて、前記ポータルリダイレクトマップ内に格納されたネットワークポータルアドレスを識別するステップを含む、ネットワーク通信装置。
【請求項９】
請求項６から８のいずれか一項に記載のネットワーク通信装置であって、
前記ポータル集約サーバは、前記受信した加入者識別子を前記複数のネットワークポータルアドレスにマッピングするように取り決められると共に、そのようにマッピングされた前記複数のネットワークポータルアドレスに前記接続要求をリダイレクトするように取り決められる、ネットワーク通信装置。
【請求項１０】
請求項６から９のいずれか一項に記載のネットワーク通信装置であって、
前記ポータル集約サーバは、ネットワークに接続するための接続要求を前記複数の加入者装置から受信し、各要求は、それぞれの加入者装置に関連付けられた前記加入者識別子を備え、受信した各加入者識別子を共通のネットワークポータルアドレスにマッピングし、そのようにマッピングされた前記共通のネットワークポータルアドレスに前記複数の接続要求をリダイレクトするように取り決められる、ネットワーク通信装置。
【請求項１１】
請求項１から５のいずれか一項に記載の前記方法を履行するための、１つまたは複数のコンピュータ上で実行可能な命令を含むコンピュータプログラムを包含するコンピュータプログラム製品又はデータキャリア／データストア。
【請求項１２】
実行された場合、請求項１から５のいずれか一項に記載の前記方法を履行するように取り決められた命令を含むコンピュータプログラムでプログラムされた１つ以上のコンピュータ。
【請求項１３】
実行された場合、請求項１から５のいずれか一項に記載の前記方法を履行するように取り決められた命令を含むコンピュータプログラムでプログラムされたコンピュータのネットワーク。
【請求項１４】
添付図面を参照しながら、上記のいずれか１つの実施形態において実質的に開示されたネットワーク通信装置。
【請求項１５】
添付図面を参照しながら、上記のいずれか１つの実施形態において実質的に開示された方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ポータルを介した通信のためのネットワーク通信の方法及び装置に関する。
【背景技術】
【０００２】
ネットワークポータル（例えば、ウェブポータル）は、情報を得るためのアクセスのポイントとして働くウェブサイトである。それらは、ネットワークアクセスの制御及び手続きを提供することができ、且つ、多くの場合、携帯電話、ラップトップ、パーソナルコンピュータなどのような、複数のデバイスのタイプ／プラットフォームからアクセス可能である。例えば、ウェブポータルは、多くの場合、組織及び企業に対して、特別な外観及び操作感を提供する。それらは、ユーザがポータルに提示された情報をカスタマイズすることを可能にし、且つ、多くの場合、デーアクセスのポイント、公表されたコンテンツ、及び検索を提供するために使用される。ウェブポータルは、ユーザにより平易なネットワークナビゲーションを提供することが可能であり、且つ、同じページ上の他のウェブポータルと併せて、ネットワークユーザに提示されるであろう。
【０００３】
大規模なネットワーク運営業者は、ホームルータ、アクセスポイント、及びスイッチのようなユーザ機器（ＵＥ）デバイスを大量に供給できることを要求する。問題は、これらのデバイスが、大量生産される一方で、自身の位置及び自身が提供するサービスに対して、特有の構成を供給することを必要としている点であり、これは、ＴＲ−６９のような供給サービスを使用する場合にさえも当てはまる。異なる実施場所のブランドサービス（venue branded services）を提供するためには、そのエッジデバイス又はネットワークゲートウェイに対して、特有のＲＡＤＩＵＳ／キャプティブ（Ｃａｐｔｉｖｅ）ポータルサービスのリダイレクト構成を配備する必要がある。例えば、ネットワーク運営業者は、２つの別々の設定（establishment）にサービスを届けたいかもしれない。実施場所Ａ（Venue A）における第１の設定は、それ自身のＷｉ−Ｆｉのキャプティブポータル及びブランド独自性を有し、無料Ｗｉ−Ｆｉを提供する。実施場所Ｂにおける第２の設定はまた、それら自身の独自性及びサービスを有し、且つ、それらは、有料のＷｉ−Ｆｉを提供する。実施場所Ａにおいて、機器が故障する、又は交換が必要である状況では、ネットワーク運営業者は、実施場所Ａに出荷する前に、正しい構成を有する交換機器を事前に供給しなければならない。しかしながら、その供給が間違っている場合、その時は、可能なサイト訪問が、実施場所Ａに対して要求される。
【０００４】
本発明は、これらの問題に取り組む。
【発明の概要】
【０００５】
最も一般的には、本発明は、複数の加入者装置を別々に直接供給する必要性を回避するために、ポータル構成の遠隔的又は間接的な供給を加入者装置に提供するという概念にある。
【０００６】
第１の態様において、本発明は、複数の加入者装置のうちの１つの加入者装置を、ネットワークに、複数のネットワークポータル装置のうちのそれぞれのネットワークポータル装置に接続するための、通信ネットワークにおける方法を提供してもよい。本方法は、複数のネットワークポータル装置に関連付けられた複数のネットワークポータルアドレスと、各々が複数の加入者装置のそれぞれの１つを識別する複数の加入者識別子とを格納するポータル集約サーバ（portal aggregation server）を提供するステップを含んでもよい。本方法は、ポータル集約サーバで実施されるステップであって、ネットワークに接続するための接続要求を加入者装置から受信するステップを更に含む。該要求は、加入者装置に関連付けられた加入者識別子を備える。本方法は、受信した加入者識別子をネットワークポータルアドレスにマッピングすると共に、そのようにマッピングされたネットワークポータルアドレスに接続要求をリダイレクトするステップを含む。
【０００７】
このようにして、必要なポータル構成情報を加入者装置上に直接格納する代わりに、この情報は、中心的に（例えば、遠隔的に）保持され、且つ、望ましいネットワーク接続を行う場合に、加入者装置にとって利用可能とされる。本発明は、単一の構成されたユーザデバイスが、それのトラフィックを、中心的に構成された負荷均衡のとれた集約サービス（aggregation service）に送ることを可能にしてもよい。集約サービスは、ユーザが位置する実施場所（即ち、該実施場所から、ユーザトラフィックが生じる）を決定するためのサイト識別子を使用してもよく、且つ、その後、そのトラフィック及び／又はキャプティブポータルを正しいポータルにリダイレクトしてもよい。このことは、配備及びサービス回復の簡単さと速度のために、実施場所デバイス（例えば、加入者装置）が、単一の構成を共有することを可能にするかもしれない。
【０００８】
集約が履行される（implemented）特定のネットワークについては、単一の構成を加入者装置（複数可）上に適用してもよい。例えば、複数の加入者装置に対して、共通のＳＳＩＤ（サービスセット識別子）を共通に使用してもよく、各加入者装置の「ローカルな」ＳＳＩＤは、そのまま残してもよい。このようにして、ポータル集約サーバのアドレスを備えた加入者装置を構成し、その結果として、加入者から出ていく全ての通信は、集約サーバを通過することが可能である。
【０００９】
本方法は、ポータル集約サーバで実施されるステップであって、受信した加入者識別子を使用して、認証プロトコルを加入者装置に適用するステップを含んでもよく、加入者装置がそのように認証されるという条件の下に、リダイレクトが行われる。集約サーバは、ネットワークポータルアドレス上で認証を単に転送するように取り決められて（arranged）もよい（即ち、「アカウント」）。集約サーバによって認証が行われることは、要求されない。最も単純な形態では、集約サーバは、更に上流にある正しい認証サーバ（例えば、ＲＡＤＩＵＳサーバのようなＡＡＡサーバ）に対して加入者装置を一致させ、且つ、該正しい認証サーバの代理をして（proxies to that）もよい。
【００１０】
本方法は、ポータル集約サーバで実施されるステップであって、複数のネットワークポータルアドレス及び複数の加入者識別子を備えるポータルリダイレクトマップを格納するステップを含んでもよい。前述のマッピングするステップは、受信した加入者識別子を、リダイレクトマップ内に格納された加入者識別子に一致させると共に、受信した加入者識別子に一致する加入者識別子に関連させて、ポータルリダイレクトマップ内に格納されたネットワークポータルアドレスを識別するステップを含んでもよい。例えば、全ての加入者装置（例えば、図１のＤＳＬルータ、Ｗｉ−ＦｉのＡＰなどを参照）は、単一の集約サーバと通信してもよい。集約サーバの機能は、例えば、ローカルなルックアップテーブルに基づいて、正しい認証サーバ（例えば、ＲＡＤＩＵＳサーバのようなＡＡＡサーバ）への接続要求を代理処理することであってもよい。その利益は、全ての加入者装置が集団で構成され（mass-configured）得る、ということである。
【００１１】
本方法は、ポータル集約サーバで実施されるステップであって、受信した加入者識別子を複数のネットワークポータルアドレスにマッピングすると共に、そのようにマッピングされた複数のネットワークポータルアドレスに接続要求をリダイレクトするステップとを含んでもよい。本発明の利点は、以下の通りである。即ち、複数の／全ての加入者装置は単一の構成を有してもよく、且つ、リダイレクト／代理認証（proxy authentication）及びアカウンティング（例えば、ＲＡＤＩＵＳプロトコルのようなＡＡＡサーバ）通信は、該通信に関して集約された全ての加入者のための、集約サーバから正しいクライアント（及びそれの認証サーバ、例えば、ＲＡＤＩＵＳサーバのようなＡＡＡサーバ）までのものであってもよい。これによって、装置配備及び寿命内での修理の両方が合理化され、それと共に、通信事業者のＩＴ担当者にとっては、ネットワークアクセスゲートウェイ（例えば、無線アクセスゲートウェイ、ＷＡＧ）の設定が簡単になる。これは、次のことを意味する。即ち、担当者は、ＷＡＧが寿命内である間は、新しい構成をＷＡＧに追加する必要がなく、これによって、時間外に計画された作業ウィンドウ及び停止時間ウィンドウ（outage window）を持たなければならないというリスクを軽減する。
【００１２】
本方法は、ポータル集約サーバで実施されるステップであって、複数の加入者装置から、ネットワークに接続するための接続要求を受信するステップを含んでもよく、各要求は、それぞれの加入者装置に関連付けられた加入者識別子を備える。本方法は、受信した各加入者識別子を共通のネットワークポータルアドレスにマッピングすると共に、そのようにマッピングされた共通のネットワークポータルアドレスに、複数の接続要求をリダイレクトするステップを含んでもよい。
【００１３】
第２の態様において、本発明は、複数の加入者装置のうちの１つの加入者装置を、複数のネットワークポータル装置のうちのそれぞれのネットワークポータル装置に接続するための、ネットワーク通信装置を提供してもよく、該装置は、複数のネットワークポータル装置に関連付けられた複数のネットワークポータルアドレスと、各々が複数の加入者装置のそれぞれの１つを識別する複数の加入者識別子とを格納するように取り決められたポータル集約サーバを含み、ポータル集約サーバは、ネットワークに接続するための接続要求を加入者装置から受信するように取り決められ、該要求は、加入者装置に関連付けられた加入者識別子を備え、且つ、ポータル集約サーバは、受信した加入者識別子をネットワークポータルアドレスにマッピングすると共に、そのようにマッピングされたネットワークポータルアドレスに接続要求をリダイレクトすることによって、受信した接続要求に応答する。該装置は、集約が履行されるネットワーク上において、単一で共通の構成を使用して、複数の加入者装置を識別するように取り決められてもよい。例えば、複数の加入者装置に対して、共通のＳＳＩＤ（サービスセット識別子）を共通に使用してもよく、各加入者装置の「ローカルな」ＳＳＩＤは、そのまま残してもよい。このようにして、ポータル集約サーバのアドレスを備えた加入者装置を構成し、その結果として、加入者から出ていく全ての通信は、集約サーバを通過することが可能である。
【００１４】
ポータル集約サーバは、受信した加入者識別子を使用して、認証プロトコルを加入者装置に適用すると共に、加入者装置がそのように認証されるという条件の下に、接続要求をマッピングされたネットワークポータルアドレスにリダイレクトするように取り決められてもよい。ポータル集約サーバは、ネットワークポータルアドレス上での認証（即ち、「アカカウント」）を単に転送するように取り決められてもよい。集約サーバによって認証が行われることは、要求されない。最も単純な形態では、集約サーバは、更に上流にある正しい認証サーバ（例えば、ＲＡＤＩＵＳサーバのようなＡＡＡサーバ）に対して加入者装置を一致させ、且つ、該正しい認証サーバの代理をしてもよい。
【００１５】
ポータル集約サーバは、複数のネットワークポータルアドレス及び複数の加入者識別子を備えるポータルリダイレクトマップを格納するように取り決められてもよい。マッピングするステップは、受信した加入者識別子を、リダイレクトマップ内に格納された加入者識別子に一致させると共に、受信した加入者識別子に一致する加入者識別子に関連させて、ポータルリダイレクトマップ内に格納されたネットワークポータルアドレスを識別するステップを含んでもよい。例えば、全ての加入者装置（例えば、図１のＤＳＬルータ、Ｗｉ−ＦｉのＡＰなどを参照）は、単一の集約サーバと通信してもよい。集約サーバの機能は、例えば、ローカルなルックアップテーブルに基づいて、正しい認証サーバ（例えば、ＲＡＤＩＵＳサーバのようなＡＡＡサーバ）への接続要求を代理処理することであってもよい。その利益は、全ての加入者装置が集団で構成され得る、ということである。
【００１６】
ポータル集約サーバは、受信した加入者識別子を複数のネットワークポータルアドレスにマッピングすると共に、そのようにマッピングされた複数のネットワークポータルアドレスに接続要求をリダイレクトするように取り決められてもよい。
【００１７】
ポータル集約サーバは、ネットワークに接続するための接続要求を、複数の加入者装置から受信するように取り決められてもよく、各要求は、それぞれの加入者装置に関連付けられた加入者識別子を備える。ポータル集約サーバは、受信した各加入者識別子を、共通のネットワークポータルアドレスにマッピングすると共に、そのようにマッピングされた共通のネットワークポータルアドレスに、複数の接続要求をリダイレクトするように取り決めてられもよい。
【００１８】
任意の認証サーバ（複数可）のポータル集約サーバは、サーバクラスのコンピュータ（複数可）を備えてもよく、又は、ソフトウェアを実行するようにプログラムされたコンピュータ上で実行される場合、認証サーバの機能を履行するように適合されたソフトウェアを備えてもよい。ポータル集約サーバは、ネットワークポータルアドレスを格納するためのデータストア（複数可）を備えてもよく、そして該データストア（複数可）は、デジタルメモリデバイス（複数可）を含んでもよく、且つ、コンピュータ（複数可）と該コンピュータ（複数可）上に配置されたソフトウェアとを含んでもよい。又は、ポータル集約サーバは、デジタルメモリの中のコンテンツ及びエントリを管理して、そのようなコンテンツを望み通りに格納する／読み取る／引き出す／消去するべく、そのようなコンピュータ（複数可）上で履行／実行するように取り決められてもよい。データストアは、キャッシュであってもよく、又は、恒久的なメモリシステム／デバイスであってもよい。例えば、データストアのソフトウェアが走っている時、該ソフトウェアは、システムメモリ又はＲＡＭの中に、データをキャッシュする又は格納するように取り決められてもよい。例えば、ソフトウェアは、ＲＡＭ又は恒久的なメモリ（例えば、ハードドライブ）の中に、エントリ及びデータ項目をキャッシュする／格納するように取り決められてもよい。ＲＡＭは、ハードドライブよりも大幅に迅速にアクセスできるので、ＲＡＭは、ファイルをインポートする場合及びファイルを引き出す場合、遅延を減少させる。認証サーバは、この目的のために、それぞれのデータストアを備えてもよく、又は、それぞれのデータストアとの通信を制御してもよい。
【００１９】
別の態様において、本発明は、コンピュータプログラム製品を提供してもよく、又は、上で説明されたような方法を履行するべく、コンピュータ（複数可）上で実行可能な命令を含むコンピュータプログラムを包含するデータキャリア／データストアを提供してもよい。別の態様において、本発明は、実行された場合、上記で説明されるような方法を履行するように取り決められた命令を含むコンピュータプログラムによってプログラムされた、１つ以上のコンピュータを提供してもよい。別の態様において、本発明は、実行された場合、上記で説明されるような方法を履行するように取り決められた命令を含むコンピュータプログラムによってプログラムされた、コンピュータのネットワークを提供してもよい。
【図面の簡単な説明】
【００２０】
【図１】図１は、加入者装置及び、ポータル集約サーバを介した複数の遠隔ウェブポータルへのネットワーク接続の履行を概略的に例示する。
【図２−１】図２−１は、図１に例示されたネットワーク接続を履行する上での、加入者装置、ポータル集約サーバ、及び遠隔ウェブポータルの間で伝達される通信及びコマンドのフローチャートを概略的に例示する。
【図２−２】図２−２は、図１に例示されたネットワーク接続を履行する上での、加入者装置、ポータル集約サーバ、及び遠隔ウェブポータルの間で伝達される通信及びコマンドのフローチャートを概略的に例示する。
【図３】図３は、図１及び図２に示されるような、ポータル集約サーバを介した３つの遠隔ウェブポータルへのネットワーク接続を行った後での、加入者装置におけるポータル供給の結果を概略的に例示する。
【図４】図４Ａは、「キャプティブポータル（captive portal）」モデルによるネットワークアクセス認証のプロセスを概略的に例示する。  図４Ｂは、「キャプティブポータル」モデルによるネットワークアクセス認証のプロセスを概略的に例示する。  図４Ｃは、「キャプティブポータル」モデルによるネットワークアクセス認証のプロセスを概略的に例示する。
【図５】図５は、遠隔ＲＡＤＩＵＳサーバを介して認証を得るための、キャプティブポータル及びネットワークアクセスサーバに関連するプロキシＲＡＤＩＵＳサーバ（proxy RADIUS server）の使用法を概略的に例示する。
【発明を実施するための形態】
【００２１】
通信ネットワークは、通常、ネットワークアクセスポイント又はゲートウェイを介して、ユーザがそれにアクセスするのを許可する。パブリックネットワーク（例えば、インターネット）のような多くのネットワークでは、ユーザは、あるネットワークサービス／ウェブサイトなどにアクセスするのを許可される前に、アクセス資格証明書（access credentials）をネットワークアクセスポイントに提供することを要求されるであろう。これらの資格証明書が、アクセスポイントに接続された（又は、アクセスポイント内に提供された）認証サーバ／ソフトウェアによって検証された後でのみ、ネットワークアクセスがユーザに認められる。「キャプティブポータル」技術は、ネットワークアクセス制御のための認証プロセスを履行することを目的とした、一般的な仕組みである。
【００２２】
ネットワークアクセス要求は、キャプティブポータルを使用して、通常は以下のように進み、そしてそれは、図４Ａ、図４Ｂ、及び図４Ｃに概略的に例示される通りである。クライアント／ユーザは、自身のウェブブラウザを起動して、望ましいネットワークサービスにアクセスする（例えば、ｈｔｔｐ：／／ｗｅｂｐａｇｅ．ｃｏｍ／）。クライアント／ユーザは、キャプティブポータル（図４Ａ）へ案内されるが、資格証明書が要求される（例えば、パスワード、ユーザ名など）。入力された資格証明書は、ネットワークアクセスポイント（ＡＰ）又はゲートウェイに転送され、そこで証明書がチェックされる／検査される（図４Ｂ）。キャプティブポータル以外のどこかへのアクセスは、ユーザの資格証明書が検証されるまで／検証されなければ、妨げられる。資格証明書が、ＡＰによって、例えばＲＡＤＩＵＳプロトコルを使用したＡＡＡサーバによって検証された後、ユーザのコンピュータは、ＤＨＣＰ（動的ホスト構成プロトコル）リースを受信するが、これによって、要求された通りのネットワークへのアクセスが可能になる（図４Ｃ）。ユーザは、その後、望み通りのネットワーク（例えば、インターネット）にアクセスしてもよい。キャプティブポータルは、そのデバイスに対する特有の識別子として、クライアントデバイスのＩＰアドレスまたはＭＡＣを使用する。
【００２３】
ＲＡＤＩＵＳプロトコル
ＲＡＤＩＵＳ（遠隔認証ダイアルイン・ユーザ・サービス（Remote Authentication Dial In User Service））プロトコルは、認証、認可、及びアカウンティング（ＡＡＡ）のための産業標準プロトコルである。それは、ＡＡＡプロトコルを履行する。ＲＡＤＩＵＳは、多くの場合、８０２．１Ｘ認証に対するバックエンドとして選択されている。端末サーバ又はネットワークアクセスサーバ（ＮＡＳ)は、ＲＡＤＩＵＳプロトコルを使用して、顧客情報のデータベースにＡＡＡ要求を伝達し、且つ、顧客情報のデータベースからの結果を戻す。ＲＡＤＩＵＳプロトコルは、ＲＦＣ２０５８及びそれに続くＲＦＣ文書の任意の１つ以上のような、インターネット・エンジニアリング・タスクフォース（ＩＥＴＦ）の「ＲＦＣ」文書において定義されてもよい、又は、例えば、ＲＦＣ６６１４を使用してもよい。ここでＲＦＣ文書は、ＲＦＣ２０５８を既に廃止しており、且つ／又は、それ自身は、ＲＦＣ３５７９、ＲＦＣ２８６６、及びＲＦＣ３５８０の任意の１つ、又はＲＦＣ３５７９、ＲＦＣ２８６６、及びＲＦＣ３５８０の組み合わせのような、ＲＡＤＩＵＳプロトコル（又はそれの態様）を定義する継続的なＲＦＣ文書によって廃止されている。
【００２４】
ＲＡＤＩＵＳサーバは、ＲＡＤＩＵＳプロトコルを使用して、ＡＡＡサービスを提供する。ＲＡＤＩＵＳサーバは、顧客が端末サーバ又はネットワークアクセスサーバ（ＮＡＳ)を使用する場合に要求されるＡＡＡサービスを実施する。ＲＡＤＩＵＳサーバは、次のタスクを実施する。即ち、
・認証：ユーザ名及びパスワードをチェックすることによって、顧客の身元を検証する。
・認可：要求されたサービスにアクセスすることに対する顧客の特権を検証する。
・アカウンティング：顧客がいつログインし、いつログアウトするか、及びセッションの継続期間を追跡する。
「アカウンティング」という用語は、顧客の使用を追跡することを指す。
【００２５】
共通の認証ツールは、いわゆる「キャプティブポータル」を使用することである。キャプティブポータルは、標準のウェブブラウザを使用して、そのサービスへのアクセスが認められる前に、ログイン詳細や資格証明書をネットワークサービスに提示する機会をユーザに許可する。このようにウェブブラウザを使用することは、多くのパーソナルコンピュータのオペレーティングシステム（ラップトップ、ＰＣなど）がキャプティブポータルをサポートでき、且つ、特注のソフトウェアが必要とされない、ということを意味する。
【００２６】
ＲＡＤＩＵＳサーバが認証目的で使用される場合、ＲＡＤＩＵＳサーバは、２つの応答、即ち「アクセス拒否」応答、又は「アクセス承諾」応答、のうちの１つをネットワークアクセスポイントに戻しもよい。もしユーザが許容できる資格証明書を提供できなかった場合、要求されたネットワークリソースへのアクセスを拒むべく、「アクセス拒否」応答が発生する。ユーザがアクセスを認められる場合、「アクセス承諾」応答が生じる。
【００２７】
ＲＡＤＩＵＳプロトコル／サーバは、ＲＡＤＩＵＳプロトコルメッセージが、他のＲＡＤＩＵＳサーバで代理処理される（即ち、プロキシサーバ（proxy server）を介して送信される）ことを可能にする能力を有する。このことは、第１のネットワーク（ネットワークＡ）のユーザが、第２のネットワーク（ネットワークＢ）のＲＡＤＩＵＳサーバ上で認証することによって、第２のネットワーク（ネットワークＢ）へのアクセスを獲得することが可能となる、ということを意味する。即ち、第１のネットワークにおけるＲＡＤＩＵＳ認証要求は、ＲＡＤＩＵＳプロトコルを用いる別のネットワークで代理処理してもよく、これによって、ユーザは他のネットワークへのアクセスが可能となる。
【００２８】
第１のネットワーク（ネットワークＡ）のＲＡＤＩＵＳサーバが、第１のネットワークに接続された第２のネットワーク（ネットワークＢ）へのアクセスを望むユーザからのアクセス／認証要求を受信する場合、その要求は、（ネットワークＡで）ユーザの資格証明書をローカルに検証する代わりに、第２のネットワーク（ネットワークＢ）のＲＡＤＩＵＳサーバに転送してもよい（該ＲＡＤＩＵＳサーバで代理処理してもよい）。第２のネットワーク（ネットワークＢ）のＲＡＤＩＵＳサーバは、その後、ユーザの資格証明書を検証し、且つ、ユーザのアクセス要求に関する「アクセス承諾」メッセージを、第１のネットワークのＲＡＤＩＵＳサーバに送り返してもよく、それによって、第１のネットワークを介して、第２のネットワークへアクセスが可能になる。これは、「連合アクセス（federated access）」として知られている。
【００２９】
ＲＡＤＩＵＳプロキシサーバは、ＲＡＤＩＵＳクライアント（及びＲＡＤＩＵＳプロキシ）とＲＡＤＩＵＳサーバ（又はＲＡＤＩＵＳプロキシ）との間で、ＲＡＤＩＵＳ接続要求及びアカウンティングメッセージを転送するように、又はルーティングするように取り決められたデバイスである。ＲＡＤＩＵＳプロキシサーバは、ユーザ名又は被呼局ＩＤ（Ｃａｌｌｅｄ−Ｓｔａｔｉｏｎ−ＩＤ）ＲＡＤＩＵＳ属性のようなＲＡＤＩＵＳメッセージ内の情報を使用して、ＲＡＤＩＵＳメッセージを適切なＲＡＤＩＵＳサーバにルーティングする。認証、認可、及びアカウンティングが、異なるネットワーク、場所、又は組織の中の複数のＲＡＤＩＵＳサーバにおいて生じる必要がある場合、ＲＡＤＩＵＳプロキシサーバは、ＲＡＤＩＵＳメッセージのための転送ポイントとして使用することが可能である。ＲＡＤＩＵＳプロトコルは、一般に、インターネットサービスプロバイダ（ＩＳＰ)間のローミングを容易にするために使用されるが、このことは、例えば、多くのパブリックネットワーク上で使用可能な単一のグローバルな資格証明書のセットを提供する企業によって行われる。
【００３０】
図５は、キャプティブポータルに関連するＲＡＤＩＵＳプロキシサーバの使用法を概略的に例示するが、これは、インターネット接続を介してアクセス可能な遠隔ＲＡＤＩＵＳサーバを使用したＡＡＡサービスを提供するためのものである。キャプティブポータルは、無線ネットワークアクセスポイント（ＡＰ）を介したインターネットサービスへのアクセスを要求するＵＥに呼応して、ネットワークアクセスサーバ（ＮＡＳ)からユーザ機器（ＵＥ)に提供される。異なる場所へのＵＥローミングによって遭遇する、異なるネットワーク内の異なるＡＰを介したインターネットサービスへのアクセスを可能にするために、この配置は、ＵＥによるネットワークローミングを許可する。
【００３１】
図１は、ポータル集約サーバ７を介して複数の遠隔ウェブポータル（１２，１３，１４）へのネットワーク接続を履行するプロセスにおける、パーソナルコンピュータ、ラップトップコンピュータ、タッチパッドコンピュータ、又はスマートフォンのようなユーザ機器（ＵＥ）２を概略的に例示する。これらの構成要素は、ネットワーク１の少なくとも一部を集団的に形成するが、ここでネットワーク１は、プライベートなイントラネットであってもよい、又は、インターネットの一部を形成してもよい。
【００３２】
ユーザ装置２は、複数の同様なユーザ機器（図示せず）からの１つであってもよく、複数の同様なユーザ機器は、各々が、以下で説明される方法で、ポータル集約サーバ７と別々に対話してもよい。ポータル集約サーバは、複数のネットワークポータル装置（１２，１３，１４）のうちの１つ以上のネットワークポータル装置にユーザ装置２を接続するように取り決められる。この例では、以下で説明されるように、ポータル集約サーバは、３つのネットワークポータル装置にユーザ機器２を接続するように取り決められるが、しかし、この数は、純粋に例証目的のためであり、且つ、限定的であることを意図していない。
【００３３】
ユーザ機器２は、複数の遠隔ウェブポータル（１２，１３，１４）を介して提供されるウェブベースサービスの顧客の構内（in the premises）に設置され、且つ、顧客の構内に設置された顧客装置（顧客構内機器（customer premise equipment）−ＣＰＥ）と通信で接続される。例えば、顧客構内は空港であってもよく、且つ、ユーザ機器２は、インターネットにアクセスしたい空港（例えば、空港ラウンジ）内の旅行者のラップトップであってもよい。顧客は、ただ１つのあるウェブサービス及び／又は、顧客などによって指定された、ある望ましいブランド／外観を包含するあるサービスを、ユーザに提示したいかもしれない。例えば、顧客は、無料Ｗｉ−Ｆｉを提供する、顧客自身のＷｉ−Ｆｉキャプティブポータル及びブランド独自性を有してもよく、又は、有料Ｗｉ−Ｆｉだけを提供してもよい。この特注の供給は、予め決められた／望ましい遠隔ウェブポータル（１２，１３，１４）に加入するように取り決められた顧客機器３によって履行されるが、ここで遠隔ウェブポータル（１２，１３，１４）は、顧客機器３がそれのユーザ（ＵＥ）３に提示したいサービスを、顧客機器３に提供する。
【００３４】
インターネットへのアクセスは、無線アクセスゲートウェイ（ＷＡＧ）機器４を介して、顧客構内機器３に提供される。このＷＡＧ機器は、ポータル集約サーバ７と通信して、ユーザ（ＵＥ）への供給のために、そのトラフィックを提供する加入ＣＰＥ及び遠隔ウェブポータル（１２，１３，１４）への／からの加入者トラフィック（例えば、コンテンツ）を交換するように取り決められる。このトラフィックのために、ＨＴＴＰプロトコルが用いられる。ＷＡＧ機器はまた、ポータル集約サーバ７と通信して、遠隔認証ダイヤルイン・ユーザ・サービス（ＲＡＤＩＵＳ）がクライアント／サーバプロトコルであるということに従って、認証／認可トラフィックを交換するように取り決められる。遠隔認証ダイヤルイン・ユーザ・サービス（ＲＡＤＩＵＳ）は、クライアント／サーバプロトコルである。それは、ネットワークサービスに接続して使用するユーザのために、集中型の認証、認可、及びアカウンティング（ＡＡＡ）管理を提供するネットワークプロトコルである。ＲＡＤＩＵＳプロトコルは、多くの場合、インターネット又は内部ネットワークへのアクセスを管理するために、インターネットサービスプロバイダ及び、（例えば、組織内の）イントラネットユーザによって使用される。無線アクセスゲートウェイ（ＷＡＧ）は、ネットワーク１へのアクセスを制御するネットワークアクセスサーバを提供し、且つ、ポータル集約サーバ７の中のプロキシＲＡＤＩＵＳサーバ８と通信するＲＡＤＩＵＳクライアント構成要素を包含する。
【００３５】
プロキシＲＡＤＩＵＳサーバ８は、大規模ネットワーク（例えば、インターネット又はイントラネット）内の、ＷＡＧとネットワークポータル装置（１２，１３，１４）との間でゲートウェイとして働く。プロキシＲＡＤＩＵＳサーバ（例えば、コンピュータシステム又はアプリケーション）は、ネットワークポータル装置からリソースを捜すユーザ機器２からの要求に対する媒介手段として働く。ユーザ装置は、接続、ウェブページ、又はネットワークポータル装置から利用可能な他のリソースのようなサービス要求するべく、ＷＡＧ４を介して、プロキシサーバに接続することが可能である。プロキシサーバは、要求の複雑さを簡素化し且つ制御する方法としてＲＡＤＩＵＳプロトコルを適用することによって、要求を評価する。集約サーバは、単にネットワークポータルアドレス上で認証を転送する（即ち、「アカウント」）。
【００３６】
ポータル集約サーバは、複数のネットワークポータル装置（１２，１３，１４）に関連付けられた複数のネットワークポータルアドレスと、各々が複数の加入者装置（明確さのために、他は図示せず）のそれぞれの１つ（例えば、加入者３、ＣＰＥ）を識別する複数の加入者識別子とを格納する。ポータル集約サーバは、ネットワークに接続するために、ＲＡＤＩＵＳプロトコル５などを介して、加入者装置３から接続要求を受信するように取り決められる。要求は、加入者機器（即ち、ＣＰＥ）３に関連付けられた加入者識別子を備え、且つ、ポータル集約サーバは、受信した加入者識別子をネットワークポータルアドレスにマッピングすると共に、そのようにマッピングされたネットワークポータルアドレスに接続要求をリダイレクトすることによって、受信した接続要求に応答する。リダイレクトユニット９は、このマッピング及びリダイレクトを履行するために用いられる。リダイレクトユニット９は、ＲＡＤＩＵＳプロキシサーバと同じ方法で動作するが、リダイレクトユニット９が、再びローカルなルックアップに基づいて、ユーザ機器（ＵＥ）のＨＴＴＰ／ＨＴＴＰＳリダイレクトを扱っている、という違いがある。リダイレクトユニット９は、ＲＡＤＩＵＳメッセージが正しい上流のＲＡＤＩＵＳサーバで代理処理されるのとほぼ同じ方法で、ＵＥを正しいウェブポータル（例えば、ログインページ）にリダイレクトするように取り決められる。リダイレクトユニット９は、リダイレクトのウェブ構成要素を取り扱う。加入者機器は、現在の例では、ＣＰＥである。適切なポータルに関する供給を要求することになるのはＣＰＥであり、それに対して、ＵＥは、通常、ＣＰＥを介して利用可能なポータルサービスを使用したい過渡的なユーザである。
【００３７】
ポータル集約サーバは、３つのポータル装置（１２，１３，１４）のネットワークポータルアドレスと、ＣＰＥ３に対する識別子を含む複数の加入者識別子とを備えるポータルリダイレクトマップを格納するように取り決められる。加入者識別子の例は、以下に限定されるものではないが、加入者装置ＩＰアドレス、ＤＨＣＰオプション８２、ＲＡＤＩＵＳ属性のＷＡＧインジェクション（WAG injection）（例えば、加入者ＩＤ、家族ＩＤ（HouseHoldID）、ラインＩＤ、ＡＰＭＡＣ、ＭＡＣ）を含む。異なるキャリアは、異なるＷＡＧ構成を用いてもよく、且つ、これらは、異なる識別子を使用してもよい。本発明の好ましい実施形態によって、メモリキャッシュ内のメタデータ（META Data）に対して、ルックアップの任意の組み合わせが可能になる。
【００３８】
マッピングするステップは、受信した加入者識別子を、リダイレクトマップ内に格納された加入者識別子に一致させると共に、受信した加入者識別子に一致する加入者識別子に関連させて、ポータルリダイレクトマップ内に格納されたネットワークポータルアドレスを識別するステップを含む。ポータル集約サーバは、受信した加入者識別子を複数のネットワークポータルアドレスにマッピングすると共に、そのようにマッピングされた複数のネットワークポータルアドレスに接続要求をリダイレクトするように取り決められる。
【００３９】
ポータル集約サーバは、ネットワークに接続するための接続要求を、複数の加入者装置（即ち、ＣＰＥ３及びその他を含む）から受信するように取り決められてもよい。各要求は、それぞれの加入者装置に関連付けられた加入者識別子を備えてもよい。ポータル集約サーバは、受信した各加入者識別子を共通のネットワークポータルアドレスにマッピングすると共に、そのようにマッピングされた共通のネットワークポータルアドレスに複数の接続要求をリダイレクトするように取り決められてもよい。
【００４０】
要約すると、ＣＰＥの場所においてトラフィックを要求するエンドユーザデバイス（ＵＥ）は、このトラフィックをＷＡＧに渡す。ＷＡＧは、ポータル集約サーバにトラフィックをルーティングし、該ポータル集約サーバは、これがどの実施場所アカウント（Venue Account）（即ち、アカウント１、アカウント２、又はアカウント３）にリダイレクトされるべきかを決定する。これは、ＣＰＥ構成及びＷＡＧ構成の両方を簡素化する。
【００４１】
図２は、加入者のユーザ機器（ＵＥ）２、ユーザ機器が無線アクセスゲートウェイ（ＷＡＧ）４を介してネットワーク（インターネット又はイントラネット）にアクセスするその無線アクセスゲートウェイ（ＷＡＧ）４、ポータル集約サーバ７及びそれのプロキシＲＡＤＩＵＳサーバ８、並びにネットワークポータル装置（１２，１３，又は１４）の間での「コールフロー(Ｃａｌｌ  Ｆｌｏｗ)」を概略的に例示する。 これらの構成要素間の通信のシーケンスは、以下の通りである。
【００４２】
事象シーケンス
先ず、ステップＳ１において、ユーザ機器（ＵＥ）２は、ＤＨＣＰサーバによってＩＰアドレスを割り当てられる。そうするために、ＵＥは、「ＤＣＨＰ発見」メッセージをＷＡＧに送信し、且つ、それに呼応して、「ＤＨＣＰ提供」メッセージをＷＡＧから受信する。キャリアは、このステップを自身で取り扱ってもよく、且つ、このことは、様々な場所で履行することが可能である。例えば、ＷＡＧは、コアルータからのＤＨＣＰリレーを使用してもよいであろう。
【００４３】
次に、ステップＳ２において、顧客構内機器（ＣＰＥ）３は、ＤＨＣＰ「オプション８２」を「ＤＨＣＰ要求」に付加し、「ＤＨＣＰ要求」は、ＣＰＥに対する識別子（「ＣＰＥ−ＩＤ」）を含む。これは、アクセスポイント（ＡＰ）のＭＡＣアドレスであるか、又はＣＰＥに固有の任意の値であり得るであろう。ＣＰＥは、ＤＳＬルータ、ＡＰ、又はＷＬＡＮコントローラであってもよい。ＷＡＧは、その後、ステップＳ３において、ＲＡＤＩＵＳプロトコル「アクセス要求」をポータル集約サーバ７に送り、「アクセス要求」は、「被呼局ＩＤ（Ｃａｌｌｅｄ−Ｓｔａｔｉｏｎ−Ｉｄ）」ＲＡＤＩＵＳプロトコル属性の中にＤＨＣＰ「オプション８２」を含む（「Ｃａｌｌｅｄ−Ｓｔａｔｉｏｎ−Ｉｄ＝ＣＰＥ−ＩＤ」）。「被呼局ＩＤ・ＲＡＤＩＵＳ属性」は、標準のＲＡＤＩＵＳプロトコル属性であるが、しかし本発明は、上で説明されるような任意の識別子、即ち、ソースＩＰ、ＵＥＭＡＣ、ＬｉｎｅＩＤなどを使用してもよい。
【００４４】
ポータル集約サーバ７は、その後、ステップＳ４において、受信した「ＣＰＥ−ＩＤ」を特定のｖＲＡＤＩＵＳサーバにマッピングすることによって、集約マッピングに基づいて、アクセス要求をｖＲＡＤＩＵＳサーバに一致させることを試みる。この例では、「被呼局ＩＤ」属性は、マッピングのために使用され、且つ、ＣＰＥ識別子（「ＣＰＥ−ＩＤ」）を包含するＤＨＣＰオプション８２’値を包含する。例えば、「被呼局ＩＤ」のような識別子を、ＲＡＤＩＵＳメッセージ上で、確かめてもよい／識別してもよい。これを、メモリキャッシュにおいて、ローカルなルックアップの中でエントリと比較し、且つ、この要求が代理処理されるべきＲＡＤＩＵＳサーバを見つけ出すために、使用してもよい。
【００４５】
首尾よく一致した場合、ステップＳ４の間、集約サーバ７のＲＡＤＩＵＳプロキシサーバ８は、「アクセス要求」を、ステップＳ５において、それがマッピングされたＲＡＤＩＵＳサーバに送る。ｖＲＡＤＩＵＳという句は、本明細書では、元の集約ＲＡＤＩＵＳプロキシサーバ８が要求を代理処理させる上流のＲＡＤＩＵＤサーバ１５を指すと理解してもよい。
【００４６】
上流のｖＲＡＤＩＵＳサーバ１５は、ステップＳ６において、要求されているセッションのために、キャプティブポータルに対するＵＲＬをキャッシュし、且つ、それに続いて、ステップＳ７において、実際のキャプティブポータルＵＲＬを指定する「アクセス承諾」メッセージによって、（集約サーバ７のプロキシＲＡＤＩＵＳサーバ８を介して）ＷＡＧに更に応答するであろう。ここで該実際のキャプティブポータルＵＲＬは、壁に囲まれた庭（ｗａｌｌｅｄ  ｇａｒｄｅｎ）の外側にあるＨＴＴＰリソースにアクセスを試みる場合に、ＵＥがリダイレクトされる先のＵＲＬである。例は以下の通りである。
Ａｌｃ−ＳＬＡ−Ｐｒｏｆ−Ｓｔｒ＝“ｗａｌｌｅｄ−ｇａｒｄｅｎ”
Ｏｄｙｓｓｙｓ−Ａｇｇｒｅｇａｔｉｏｎ−Ｒｅｄｉｒｅｃｔ−Ｕｒｌ＝“ｈｔｔｐｓ：／／ｍａｎａｇｅｒ．ｏｄｙｓｓｙｓ．ｎｅｔ／ｃａｐｔｉｖｅＰｏｒｔａｌ／［Ｐｏｒｔａｌ−ｌｄ］”
これが、ステップＳ８において、「ＤＨＣＰ  ＡＣＫ」メッセージを介して、ＷＡＧによってＵＥに伝達される。例えば、ＵＥが認証される前に、それは、多くの場合、「キャプティブポータル」と呼ばれるウェブ・ログイン・ページにリダイレクトされるのが好ましい。これは、ＵＥが認証される前にアクセスできる、許可されたリソース、ページ、イメージ、ｅｓｓファイル、ｊｓなどの「壁に囲まれた庭」の中に存在する。ＷＡＧ上に加入者セッションを設定することを要求される付加的なＶＳＡは、「アクセス承諾」メッセージの中に包含される。
【００４７】
もし集約マッピングに対して一致が見られない場合、集約サーバ７は、集約サーバ７のプロキシＲＡＤＩＵＳサーバ８を介して、「アクセス拒否」メッセージによって、ＷＡＧに応答するであろう。
【００４８】
ＷＡＧは、ステップＳ９において、上流のＲＡＤＩＵＳサーバ１５を用いて、「アカウンティング開始」メッセージ及び「アカウンティング応答」メッセージを交換することによって、及び、ステップＳ１０において、ＷＡＧ  ＲＡＤＩＵＳ  ＶＳＡによって指定されるポリシーを適用する加入者セッションを設定することによって、「アクセス承諾」メッセージに応答する。「ＶＳＡ」という用語は、ベンダー固有の属性を意味するＲＡＤＩＵＳ用語である。ＷＡＧは、ステップＳ１０において、ＨＴＴＰリソースへの要求が、集約サーバ７によって識別されるエンドポイントＵＲＬにリダイレクトされる、ということを決定する。
【００４９】
ＵＥは、その後、ステップＳ１１において、壁に囲まれた庭の外側にあるＨＴＴＰリソース（例えば、ｈｔｔｐ：／／ｇｏｏｇｌｅ．ｃｏｍ）にアクセスする試みを行う。これはＷＡＧによって傍受され（intercepted）、ＷＡＧは、ステップＳ４において集約サーバ７によって行われたマッピングプロセスによって識別されるＡＡＡ集約エンドポイントＵＲＬを指し示す「ＨＴＴＰ／３０２リダイレクト」メッセージを用いてステップＳ１２において、応答する。例は、以下の通りである。
ｈｔｔｐｓ：／／ａｇｇｒｅｇａｔｉｏｎ．ｏｄｙｓｓｙｓ．ｎｅｔ／［ａｇｇｒｅｇａｔｉｏｎ−ｌｄ］
【００５０】
ＵＥは、ステップＳ１３において、集約サーバ７にＡＡＡエンドポイントＵＲＬ（ステップＳ４において、集約サーバ７によって行われたマッピングプロセスによって識別される）を要求し、ＡＡＡエンドポイントＵＲＬは、ＵＲＬのクエリ文字列フラグメント内に指定された「加入者セッションＩＤ」を含む。
【００５１】
ステップＳ１４において、集約サーバ７は、集約サーバ７のキャッシュ９内のセッションコンテキスト（「ポータルリダイレクト」）をルックアップし、且つ、実際のキャプティブポータルＵＲＬに「ＨＴＴＰ／３０２」リダイレクトで応答する。
【００５２】
ステップＳ１５からステップＳ１８において、ＵＥはキャプティブポータルに関して、アクションに対するコールを完了し、且つ、インターネットサービスに対して認可される。例は、以下の通りである。
ｈｔｔｐｓ：／／ｍａｎａｇｅｒ．ｏｄｙｓｓｙｓ．ｎｅｔ／ｃａｐｔｉｖｅＰｏｒｔａｌ／ｐｏｓｔＳｉｇｎｌｎＵｒｌ
これは、無料アクセスのための登録、承諾若しくは期間及び条件、接続に対する単なるクリックまたはサービスに対する支払を含み得るであろう。
【００５３】
キャプティブポータルは、ステップＳ１９において、ｖＲＡＤＩＵＳサーバからのＣｏＡ要求をトリガし、且つ、ステップＳ２０において、該ＣｏＡ要求は、その後、集約サーバ７で代理処理され、そしてその後、ＷＡＧで代理処理される。例は、以下の通りである。
Ｕｓｅｒ−Ｎａｍｅ＝［Ｓｕｂｓｃｒｉｂｅｒ  Ｕｓｅｒｎａｍｅ］
Ａｌｃ−Ｓｕｂｓｃ−ＩＤ−Ｓｔｒ＝［Ｓｕｂｓｃｒｉｂｅｒ−Ｉｄ］
Ａｌｃ−ＳＬＡ−Ｐｒｏｆ−Ｓｔｒ＝“ｏｐｅｎ−ｉｎｔｅｒｎｅｔ”
これは、加入者に関連付けられたユーザ名はもちろん、加入者セッションに適用するための新しい加入者ポリシーも含む。「ＣｏＡ」という用語は、権限の変化を指す。これは、ＷＡＧ上で「認証されていない」から「認証されている」へ、ＵＥを変化させるための方法として知られている。ＵＥは、ステップＳ２０において、キャプティブポータル成功ページＵＲＬにリダイレクトされる。例は、以下の通りである。
ｈｔｔｐｓ：／／ｍａｎａｇｅｒ．ｏｄｙｓｓｙｓ．ｎｅｔ／ｃａｐｔｉｖｅＰｏｒｔａｌ／ｓｕｃｃｅｓｓｐａｇｅ／［ｐｏｒｔａｌ−ｌｄ］
承認メッセージ及びアカウンティングメッセージは、その後、ＵＡと、ＵＥが今接続されているアカウントのポータル１６との間で、通常の方法で、交換してもよい。ＵＥからポータルへの接続メッセージの例は、以下の通りである。
ｈｔｔｐｓ：／／ｍａｎａｇｅｒ．ｏｄｙｓｓｙｓ．ｎｅｔ／ｃａｐｔｉｖｅＰｏｒｔａｌ／［Ｐｏｒｔａｌ−ｌｄ］
【００５４】
図３は、図１及び図２を参照しながら上で説明されたように、ポータル集約サーバ７を介して、３つの遠隔ウェブポータル（１２，１３，１４）にネットワーク接続した後の、加入者装置２におけるポータル供給の結果を概略的に例示する。ウェブポータルページは、ユーザによって要求されるような、ユーザが加入するウェブサービスアカウント１、２、及び３に対応するウェブポータルアドレスから、ユーザ装置２のディスプレイ３０に提供される。複数のウェブポータルページ又は複数のポートレット（portlet）は、図１及び図３に例示されたアカウント２のような、１つのアカウントから提供してもよい。
【００５５】
ポートレットは、複合ページのコンテキストの中に集約されるように設計されたウェブ構成要素である。複数のポートレットは、ポータルページに対する単一の要求の中で呼び出してもよい。各ポートレットは、ポータルページマークアップ内の全てで、他のポートレットのマークアップと組み合わされるマークアップのフラグメントを作り出す。図３は、これの例を、ユーザ装置２のディスプレイ３０上に一緒に表示されたアカウント２（図１）からの２つのポートレットの観点から概略的に示す。図１は、３つの異なるアカウント（アカウント１、２、及び３）にアクセスする１つの顧客構内機器（ＣＰＥ）３を示す。各アカウントはウェブポータルを提供する。各ポータルは、例えば、「ＣｏｆｆｅｅＣｏ」などのように、同じ方法でブランド化してもよい。例えば、ＣｏｆｆｅｅＣｏ（アカウント１）は、それらのウェブポータル上で一時的なパートナーブランドを有し、該ウェブポータルでは、ＣｏｆｆｅｅＣｏ（アカウント２）が会社の初期設定ブランドを有する、というようなことであってもよい。ユーザが、パートナーと関連させて、ＣｏｆｆｅｅＣｏサイトにアクセスする場合、ユーザは、アカウント１からポータルを見、そして別な方法では、ユーザは、アカウント２などのポータルを見るであろう。
【図１】
2019537176.tif 000003
【図２−１】
2019537176.tif 000004
【図２−２】
2019537176.tif 000005
【図３】
2019537176.tif 000006
【図４】
2019537176.tif 000007
【図５】
2019537176.tif 000008
【国際調査報告】
2019537176.tif 000009
2019537176.tif 000010
2019537176.tif 000011