JP2010503318A - ネットワーク・アクセスを獲得するためのシステムおよび方法 - Google Patents

Abstract

通信ネットワークにアクセスするためにネットワーク信用証明書を提供するシステムおよび方法が開示される。例示的な実施態様においては、通信ネットワークへのアクセスを試みているデジタル・デバイスがネットワーク・デバイスから認証要求を受信する。認証要求に基づいて認証レコードが信用証明書サーバから取得される。ネットワーク信用証明書は、続いて認証レコード内に提供されて、認証応答としてネットワーク・デバイスに送信される。ネットワーク・デバイスによる認証に応答して、デジタル・デバイスに通信ネットワークへのアクセスが提供される。

Description

本発明の実施態様は、ネットワーキングに、より詳細に述べれば、通信ネットワークにアクセスするためにネットワーク・デバイスに信用証明書を提供することに指向されている。

従来から、あらかじめユーザがわかっていないエリア内にホットスポットが開設されることがある。ホットスポットの例は、ホテル、コーヒー・ショップ、大学構内、およびそのほかの、デジタル・デバイス・ユーザがインターネット等の通信ネットワークへの接続に関心を示すと見られる公的または私的な場所（ロケーション）を包含できる。通常、それらのホットスポットは無線である。

多くの実施態様において、ホットスポットは、ユーザが認証されることを求める。したがって、通常、ユーザのデジタル・デバイスにホットスポットへのアクセスが許可される前には、ユーザにログイン・プロセスを実行することが要求される。一般的なログイン・プロセスは、ウェブ・ブラウザを開くこと、およびユーザ名およびパスワードを入力することができる専用のポータル・ウェブ・サイトに接続することを包含する。別のプロセスは、ユーザに支払情報の提供を要求することがある。支払の確認の後にアクセス・ポイントが、ユーザのデジタル・デバイスにホットスポットへのアクセスを許可することになる。

残念ながら、すべてのデジタル・デバイスがブラウザ能力を有しているわけではない。その種のデジタル・デバイスは、たとえば、ワイファイ（Ｗｉ‐Ｆｉ）、ＶｏＩＰ電話、カメラ、およびＭＰ３プレーヤを含むことができる。これらのデジタル・デバイスは、通常、ウェブ・ブラウザまたは、信用証明書または支払情報を入力するメカニズムを含まない。その結果として、それらのデジタル・デバイスがホットスポットを使用することが困難になる。

この問題に対する１つの従来的な解決策は、前もってデジタル・デバイスに信用証明書を構成することである。しかしながらこれは、ユーザが使用を予定しているすべてのホットスポットのための信用証明書が、構成の時点において既知であることを要求することになる。また、ユーザがそれらすべてのホットスポットに登録されるか、または申し込むことを要求することもあり得る。さらに、新しいホットスポットがこのあらかじめ構成されたデジタル・デバイスによってアクセスされることは、そのデジタル・デバイスが更新（たとえば、完全に機能するネットワーク接続を介してデジタル・デバイスにダウンロード）されない限り不可能である。さらに別の欠点は、デジタル・デバイスが、すべての信用証明書情報をストアできる充分なメモリを包含していなければならないことである。

本発明の実施態様は、通信ネットワークにアクセスするためにネットワーク信用証明書を提供するためのシステムおよび方法を提供する。ネットワーク・デバイスが、通信ネットワークのためのアクセス・ポイントを構成できる。

例示的な実施態様においては、デジタル・デバイスが、ネットワーク・デバイスに提供するネットワーク信用証明書の獲得を必要とすることがある。したがって、デジタル・デバイスの信用証明書エンジンが、ネットワーク信用証明書を獲得するべく信用証明書要求を生成できる。この信用証明書要求は、信用証明書サーバに送信できる。その後、信用証明書エンジンが信用証明書要求応答を受信し、分析してネットワーク信用証明書を取得できる。いくつかの実施態様においては、信用証明書要求応答がログイン・プロシージャ情報も包含することがある。

通信ネットワークへのアクセスを試みているデジタル・デバイスは、通信ネットワークへのアクセスの試行時にネットワーク・デバイスから認証要求を受信することがある。当該認証要求に基づいて、認証レコードが、デジタル・デバイスの認証レコード・モジュールによって取得される。いくつかの実施態様においては、この取得が、信用証明書要求応答内で受信されたログイン・プロシージャ情報に基づくことができる。

その後、認証レコード内に信用証明書が提供され、認証応答としてネットワーク・デバイスに送信される。ネットワーク・デバイスによる認証に応答して、デジタル・デバイスに通信ネットワークへのアクセスが提供される。

本発明の実施態様が実施できる環境の概略図である。 例示的なデジタル・デバイスのブロック図である。 デジタル・デバイスにネットワーク・アクセスを提供するための例示的な方法のフローチャートである。 ネットワーク信用証明書を獲得するための例示的な方法のフローチャートである。 ネットワーク・デバイスを用いてデジタル・デバイスを認証するための例示的な方法のフローチャートである。 本発明の１つの実施態様に従った例示的なネットワーク・アクセス認証ページの表示である。 デジタル・デバイスにネットワーク・アクセスを提供するための例示的なプロセスのフローチャートである。 例示的な信用証明書要求のブロック図である。

本発明の実施態様は、ホットスポットを介して通信ネットワークにアクセスするためのシステムおよび方法を提供する。例示的な実施態様においては、デジタル・デバイスがユーザと関連付けされる。ネットワーク・デバイス（たとえば、ホットスポット・アクセス・ポイント）が、デジタル・デバイスに、それ自体を、ホットスポットを使用するためにネットワーク・デバイスに対して認証することを要求する。通常、認証は、アクセスを許可する前にネットワーク・デバイスによって検証されるデジタル・デバイスからのネットワーク信用証明書の要求を包含できる。１つの実施態様においては、通信ネットワークがインターネットを包含する。

図１は、本発明の実施態様が実施されることのある環境１００の概略図を図解している。例示的な実施態様においては、ユーザが、デジタル・デバイス１０２を伴ってホットスポットに入る。デジタル・デバイス１０２は、ネットワーク・デバイス１０４を介した標準プロトコルとして信用証明書要求を自動的に送信できる。その信用証明書要求は、信用証明書サーバ１１６に転送されることがあり、それが、その信用証明書要求の中に含められている情報に基づいて、デジタル・デバイス１０２に信用証明書要求応答を返送する。この信用証明書要求応答は、デジタル・デバイス１０２が、通信ネットワーク１１４へのアクセスを獲得するべくネットワーク・デバイス１０４、認証サーバ１０８、またはアクセス・コントローラ１１２に提供することができるネットワーク信用証明書を含む。

多様な実施態様においては、ホットスポットが、ネットワーク・デバイス１０４、認証サーバ１０８、ＤＮＳサーバ１１０、およびアクセス・コントローラ１１２を含み、それらはローカル・エリア・ネットワーク１０６（たとえば『ウォールド・ガーデン』）に結合される。ネットワーク・デバイス１０４は、デジタル・デバイス１０２が、ローカル・エリア・ネットワーク１０６を介して認証サーバ１０８、ＤＮＳサーバ１１０、およびアクセス・コントローラ１１２と通信することを可能にするアクセス・ポイントを包含できる。デジタル・デバイス１０２は、ラップトップ、携帯電話、カメラ、携帯情報端末、またはそのほかの任意のコンピューティング・デバイスを包含できる。認証サーバ１０８は、通信ネットワーク１１４にわたる通信にアクセスすることをデジタル・デバイス１０２に許可する前にデジタル・デバイス１０２にネットワーク信用証明書を要求するサーバである。ネットワーク信用証明書は、ユーザ名、パスワード、およびログイン・プロシージャ情報を包含する。ＤＮＳサーバ１１０は、ローカル・エリア・ネットワーク１０６にわたってＤＮＳサービスを提供し、かつ通信ネットワーク１１４を横切ってほかのＤＮＳサーバ（図示せず）に要求を中継することができる。アクセス・コントローラ１１２は、ネットワーク・デバイス１０４に機能的に結合されたデバイスと通信ネットワーク１１４に結合されたデバイスの間における通信を可能にするルータまたはブリッジ等のアクセス・デバイスである。

図１内のホットスポットは、ローカル・エリア・ネットワーク１０６に結合された別々のサーバを図示しているが、当業者は、ローカル・エリア・ネットワーク１０６に結合される任意数のデバイス（たとえば、サーバ、デジタル・デバイス、アクセス・コントローラ、およびネットワーク・デバイス）が存在できることを認識するであろう。いくつかの実施態様においては、ローカル・エリア・ネットワーク１０６がオプションとなる。１つの例においては、認証サーバ１０８、ＤＮＳサーバ１１０、およびアクセス・コントローラ１１２が、ネットワーク・デバイス１０４に直接結合される。多様な実施態様においては、認証サーバ１０８、ＤＮＳサーバ１１０、およびアクセス・コントローラ１１２が、１つまたは複数のサーバまたは１つまたは複数のデジタル・デバイス内に結合されることもある。さらに、図１は、無線アクセスを図示しているが、デジタル・デバイス１０２が無線または有線（テン・ベース・ティ（１０ｂａｓｅＴ）等）を介してネットワーク・デバイス１０４に結合されることもある。

通信ネットワーク１１４にアクセスするために、認証サーバ１０８が、ホットスポットへのアクセスのための１つまたは複数のネットワーク信用証明書の提供をデジタル・デバイス１０２に要求することがある。ネットワーク信用証明書は、たとえば、当該ホットスポットに関連付けされたアカウントのためのユーザ名およびパスワードを包含できる。代替実施態様においては、ユーザ名およびパスワードのほかのネットワーク信用証明書が利用されることがある。

例示的な実施態様によれば、デジタル・デバイス１０２が信用証明書サーバ１１６から動的にネットワーク信用証明書を獲得できる。デジタル・デバイス１０２は、デジタル・デバイス１０２の（またはデジタル・デバイス１０２のユーザの）アイデンティティおよびネットワーク・デバイス１０４についての詳細（たとえば、ネットワーク・デバイス１０４またはワイファイ（Ｗｉ‐Ｆｉ）サービス・プロバイダの名前）を包含する信用証明書要求を、信用証明書サーバ１１６に送信できる。

１つの例においては、デジタル・デバイス１０２がホットスポットに入るとき、ネットワーク・デバイス１０４は、たとえばＤＨＣＰ（ダイナミック・ホスト・コンフィグレーション・プロトコル）を介してＤＮＳクエリの提出ができる提出先のＩＰアドレスを提供できる。信用証明書要求は、標準プロトコルとしてフォーマットできる。ある例においては、信用証明書要求をＤＮＳ要求としてフォーマットできる。信用証明書要求は、ネットワーク・インフラストラクチャ（たとえばアクセス・コントローラ１１２）が要求をブロックすることがないように、標準レコード型を包含するテキスト・レコード要求（たとえば、ＴＸＴ）とすることができる。

いくつかの実施態様においては、信用証明書要求がＤＮＳサーバ１１０によって受信され、それがその信用証明書要求を、ネットワーク信用証明書のための信用証明書サーバ１１６に転送することができる。例示的な実施態様においては、信用証明書サーバ１１６が、ルックアップを実行して適正なネットワーク信用証明書（１つまたは複数）を決定し、ＤＮＳサーバ１１０に返送することができ、それが当該ネットワーク信用証明書を転送して要求しているデジタル・デバイス１０２に返す。多様な実施態様においては、適正なネットワーク信用証明書（１つまたは複数）が、信用証明書要求の送信と同じ経路を介して信用証明書サーバ１１６からデジタル・デバイス１０２に送信される。

信用証明書サーバ１１６におけるネットワーク信用証明書の決定および提供のためのプロセスに関するより詳細は、２００７年９月６日に出願された『システム・アンド・メソッド・フォア・プロバイディング・ネットワーク・クレデンシャルズ（Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｐｒｏｖｉｄｉｎｇ Ｎｅｔｗｏｒｋ Ｃｒｅｄｅｎｔｉａｌｓ）』と題された同時係属の米国特許出願第＿＿号の中に提供されている。図１の中では１つのＤＮＳサーバ１１０だけが図示されているが、信用証明書要求が信用証明書サーバ１１６によって受信される前に、限定ではないがＤＮＳサーバを含む任意数のサーバを通って転送されることがある。ほかの実施態様においては、信用証明書要求が、ネットワーク・デバイス１０４から信用証明書サーバ１１６に直接転送される。

いくつかの実施態様においては、信用証明書サーバ１１６からの信用証明書要求応答が、ユーザ名、パスワード、および／またはログイン・プロシージャ情報を包含できる。ログイン・プロシージャ情報は、たとえば、ＨＴＭＬのフォーム要素名、提出ＵＲＬ、または提出プロトコルを包含できる。いくつかの実施態様においては、ネットワーク信用証明書応答が、デジタル・デバイス１０２に返送される前に信用証明書サーバ１１６によって、デジタル・デバイス１０２に関連付けされた暗号鍵を使用して暗号化されることがある。

デジタル・デバイス１０２がネットワーク信用証明書応答を受信した後は、デジタル・デバイス１０２が、（ネットワーク信用証明書応答から取得された）ネットワーク信用証明書を認証応答の中でネットワーク・デバイス１０４に提出できる。例示的な実施態様においては、認証応答が、検証のために認証サーバ１０８に転送されることがある。いくつかの実施態様においては、認証サーバ１０８が、ＡＡＡサーバまたはラディウス（ＲＡＤＩＵＳ）サーバを包含できる。

注意される必要があるが、図１は例示である。代替実施態様が、より多くの、より少ない、または機能的に等価の構成要素を包含することがあるが、それもこの実施態様の範囲内である。たとえば、手前で論じたとおり、多様なサーバ（たとえば、ＤＮＳサーバ１１０、信用証明書サーバ１１６、および認証サーバ１０８）の機能が、１つまたは２つのサーバに結合されることがある。つまり仮に、たとえば、認証サーバ１０８およびＤＮＳサーバ１１０が同一のサーバを構成できるとすれば、認証サーバ１０８、ＤＮＳサーバ１１０、およびアクセス・コントローラ１１２の機能性を単一のデバイスに結合することができる。

ここで図２を参照すると、例示的なデジタル・デバイス１０２がより詳細に示されている。例示的な実施態様においては、デジタル・デバイス１０２が、プロセッサ２０２、入力／出力（Ｉ／Ｏ）インターフェース（１つまたは複数）２０４、通信ネットワーク・インターフェース２０６、メモリ・システム２０８、およびストレージ・システム２１０を包含する。Ｉ／Ｏインターフェース２０４は、たとえばキーボード、マウス、およびディスプレイ・デバイス等の多様なＩ／Ｏデバイスのためのインターフェースを包含することができる。例示的な通信ネットワーク・インターフェース２０６は、デジタル・デバイス１０２が通信ネットワーク１１４および／またはローカル・エリア・ネットワーク１０６と通信することを可能にするべく構成される。ストレージ・システム２１０は、たとえばデジタル・デバイス１０２のためのデジタル・デバイス識別子をストアしたＤＤＩＤストレージ２１２等の多様なデータベースまたはストレージを包含できる。

ストレージ・システム２１０は、本発明の実施態様によってホットスポットへのアクセスに使用される複数のモジュールを包含する。１つの実施態様においては、ストレージ・システム２１０がネットワーク・モジュール２１４、信用証明書エンジン２１、ネットワーク・アクセス・エンジン２１８、および暗号化／復号化モジュール２２０を包含する。デジタル・デバイス１０２および／またはメモリ・システム２０８の代替実施態様は、より多くの、より少ない、または機能的に等価の構成要素およびモジュールを包含することがある。

ネットワーク・モジュール２１４は、ローカル・エリア・ネットワーク１０６にアクセスするための動作を実行するべく構成できる。いくつかの実施態様においては、ネットワーク・モジュール２１４が、ホットスポットへのアクセスに関連付けされた通信の受信および送信を行うことができる。またネットワーク・モジュール２１４は、通信ネットワーク１１４のサーチを実行することもできる。たとえば、ネットワーク・モジュール２１４が通信ネットワーク１１４へのアクセスがまったく存在しないと決定した場合に、ここでの本発明の実施態様を実施することができる。

例示的な信用証明書エンジン２１６は、ネットワーク信用証明書を獲得するべく構成される。例示的な実施態様においては、信用証明書エンジン２１６が、要求モジュール２２２、検証モジュール２２４、および取得モジュール２２６を包含できる。例示的な要求モジュール２２２は、ネットワーク信用証明書のための信用証明書要求を生成するべく構成される。また信用証明書エンジン２１６は、（ネットワーク・モジュール２１４を介して）信用証明書要求応答を受信し、かつ検証モジュール２２４を介して、当該信用証明書要求応答が信用証明書サーバ１１６からであることを検証できる。例示的な取得モジュール２２６は、信用証明書要求応答を分析してネットワーク信用証明書を獲得するべく構成される。ネットワーク信用証明書を獲得するためのプロセスは、以下に図４との関連でより詳細に論じられることになる。

例示的なネットワーク・アクセス・エンジン２１８は、認証要求を受信し、かつネットワーク信用証明書を構成する認証応答をネットワーク・デバイス１０４に提供するべく構成される。ネットワーク・アクセス・エンジン２１８は、認証レコード・モジュール２２８、フィールド・モジュール２３０、および提出モジュール２３２を包含できる。例示的な認証レコード・モジュール２２８は、デジタル・デバイス１０２に関連付けされた認証レコードを識別するべく構成される。フィールド・モジュール２３０は、認証レコード内のフィールドまたは要素を識別して、適正な要素入力（たとえばネットワーク信用証明書）をフィールド内に提供する。提出モジュール２３２は、認証レコードを認証応答としてネットワーク・デバイス１０４に自動的に提出するべく構成される。認証応答を提供するためのプロセスは、以下に図５との関連でより詳細に論じられることになる。

暗号化／復号化モジュール２２０は、デジタル・デバイス１０２によって送信／受信された通信を暗号化または復号（平文化）するように構成される。いくつかの実施態様においては、信用証明書要求応答が信用証明書サーバ１１６によって暗号化されることがある。それらの実施態様においては、暗号化／復号化モジュール２２０が当該信用証明書要求応答を復号化（平文化）することになる。いくつかの実施態様では、暗号化／復号化モジュール２０８が、ＳＳＬおよび／またはｈｔｔｐｓを介して、デジタル・デバイス１０２と認証サーバ１０８の間に安全な通信を確立できる。注意される必要があるが、いくつかの実施態様によれば、暗号化／復号化モジュール２２０がオプションとなること、または必要とされないことがある。

ここで図３を参照すると、デジタル・デバイス１０２に通信ネットワーク・アクセスを提供する例示的な方法のフローチャート３００が示されている。ステップ３０２においてデジタル・デバイス１０２がホットスポットに入る。たとえば、ユーザが、通信ネットワーク・アクセス（たとえばホットスポット）が利用できるコーヒー・ショップまたはホテル内でデジタル・デバイス１０２をオンにすることができる。アクティベートされたデジタル・デバイス１０２がホットスポットに入ると、当該デジタル・デバイス１０２がホットスポットを検知できる。たとえば、ネットワーク・モジュール２１４が、通信ネットワーク１１４へのアクセスを自動的に試行できる。

ホットスポット内において動作可能になると、デジタル・デバイス１０２のネットワーク・モジュール２１４は、ステップ３０４において、ホットスポットのネットワーク・デバイス１０４にクエリを行うことができる。例示的な実施態様においては、ネットワーク・デバイス１０４がホットスポットのアクセス・ポイントを構成する。ネットワーク・デバイス１０４にクエリを行うことによって、ネットワーク・モジュール２１４は、サービス・プロバイダとの関連付けができる中央サーバ（たとえば、ＤＮＳサーバ１１０）に関連付けされた１つまたは複数のＩＰアドレスを受け取ることができる。そのほかの、ＤＮＳレコードおよびゲートウェイ・レコード等の情報が受信されることもある。例示的な実施態様においては、ＤＨＣＰを介してＩＰアドレスを提供できる。１つの実施態様では、ネットワーク・モジュール２１４が、通信ネットワーク１１４に対する生きた接続が存在するか否かを決定するべく既知のサーバへのアクセスを試行できる。

ステップ３０６においては、デジタル・デバイス１０２がＤＮＳサーバ１１０にネットワーク信用証明書を要求し、それを獲得する。ステップ３０６のプロセスについては、より詳細が図４に関連して以下に論じられることになる。

デジタル・デバイス１０２がネットワーク信用証明書を獲得した後は、ステップ３０８においてデジタル・デバイス１０２が、ネットワーク・デバイス１０４を介して通信ネットワーク１１４にアクセスするためにネットワーク・デバイス１０４に認証応答を提供できる。ステップ３０８のプロセスについては、より詳細が図５に関連して以下に論じられることになる。

ネットワーク・デバイス１０４は、その後、認証応答内で受信したネットワーク信用証明書を比較することによってデジタル・デバイス１０２の認証を試行することになる。１つの実施態様によれば、ネットワーク・デバイス１０４は、認証サーバ１０８を利用してネットワーク信用証明書を認証できる。たとえばネットワーク信用証明書を、認証サーバ１０８にストアされているか、または関連付けされたネットワーク信用証明書のデータベースに対して比較することができる。

ネットワーク信用証明書が認証された場合には、ステップ３１０においてデジタル・デバイス１０２に通信ネットワークへのアクセスが許可されることになる。１つの実施態様においては、認証サーバ１０８がデジタル・デバイス１０２に、通信ネットワーク１１４へのアクセスを与えるべくアクセス・コントローラ１１２に指示することができる。

ここで図４を参照すると、ネットワーク信用証明書を獲得する（ステップ３０６）ための例示的な方法のフローチャートが示されている。ステップ４０２においてネットワーク信用証明書要求が生成される。１つの実施態様によれば、要求モジュール２２２が、デジタル・デバイス１０２のプラットフォーム上にすでに存在していることがあるＤＮＳ構造を使用して文字列を構成できる。要求モジュール２２２によって生成される例示的なＤＮＳ文字列については、より詳細が図８に関連して以下に論じられることになる。

ステップ４０４においては、生成された信用証明書要求がデジタル・デバイス１０２によって送信される。例示的な実施態様では、デジタル・デバイス１０２がネットワーク・デバイス１０４から受信した（ＤＮＳサーバ１１０の）ＩＰアドレスのうちの１つを利用する。ＤＮＳ文字列は、その後、ネットワーク・モジュール２１４によって受信された選択されたＤＮＳ ＩＰアドレスに送信される。

ステップ４０６においては、デジタル・デバイス１０２が、信用証明書要求応答を受信する。例示的な実施態様では、信用証明書要求応答が信用証明書サーバ１１６からＤＮＳサーバ１１０を介して受信される。信用証明書要求応答は、暗号化されていることがある。それらの実施態様においては、暗号化／復号化モジュール２２０が信用証明書要求応答を復号化する。

その後ステップ４０８において、信用証明書要求応答が検証される。例示的な実施態様では、信用証明書要求応答が暗号化される。デジタル・デバイス１０２（たとえば検証モジュール２２４）は、その信用証明書要求応答を復号化できる。いくつかの実施態様では信用証明書要求応答がデジタル署名される。デジタル・デバイス１０２（たとえば検証モジュール２２４）は、デジタル署名を復号化することによって、または信用証明書要求応答を復号化することによって信用証明書要求応答の真正を検証できる。代替実施態様においては、このほかのメカニズムが検証モジュール２２４によって信用証明書要求応答の認証に使用されることがある。

ネットワーク信用証明書は、その後ステップ４１０において取得できる。例示的な実施態様では、取得モジュール２２６が信用証明書要求応答を分析してその中に埋め込まれたネットワーク信用証明書を獲得する。１つの例においては、取得モジュール２２６内が取得モジュール２２６内のデータを（たとえば、区切られたフィールドを介して）識別し、暗号鍵、ユーザ名、パスワード、フォーム識別子、またはこれらの類を取得できる。

次に図５を参照すると、ネットワーク・デバイス１０４に対してデジタル・デバイス１０２を認証（たとえば、ステップ３０８の認証応答の提供）するための例示的な方法のフローチャートが示されている。ステップ５０２においては、ネットワーク・モジュール２１４によってネットワーク・デバイス１０４から認証要求が受信される。

その後ステップ５０４において、認証レコード・モジュール２２８が、認証レコードを識別して取得する。例示的な実施態様においては、ネットワーク・デバイス１０４からの認証要求が、ネットワーク信用証明書が中に提供され得る認証レコードに関連付けされたＨＴＭＬフォームの要素名を包含できる。認証レコード・モジュール２２８は、たとえば、名前または識別子を介してネットワーク・デバイス１０４にログインするために必要なフォーム（１つまたは複数）／認証レコード（１つまたは複数）（たとえば、ログイン・フォーム）を構文解析できる。

ステップ５０６においては、フィールド・モジュール２３０が、認証入力（たとえば、ネットワーク信用証明書）を必要とする認証レコード内のフィールド（１つまたは複数）または要素（１つまたは複数）を決定する。例示的な実施態様によれば、フィールド・モジュール２３０が、ステップ５０４において識別され、取得された認証レコードを、入力フィールドを探し出すべく分析することになる。それによって、それらの入力フィールドのリスト（たとえば、フォームおよび入力フィールドのリンク付きリスト）を生成できる。

ステップ５０８においては、ネットワーク信用証明書が、決定されたフィールド（１つまたは複数）または要素（１つまたは複数）と関連付けされる。例示的な実施態様では、フィールド・モジュール２３０が、それぞれの入力要素に適正なネットワーク信用証明書を関連付けする。この関連付けは、認証要求のＨＴＭＬのスクリプト内で見つかった入力名または識別子に基づくことができる。たとえば、認証レコードは、ユーザ名または電子メール・アドレスを要求する入力要素を包含できる。

認証レコードを包含する認証応答が、ステップ５１０において送信される。１つの実施態様によれば、フィールド・モジュール２３０によってネットワーク信用証明書（１つまたは複数）が認証レコードと関連付けされると書き込みが生成される。いくつかの実施態様においては、認証レコードが、ネットワーク・アクセス信用証明書に加えて、セッション情報およびデジタル・デバイス１０２の識別に使用される複数の隠された値を包含できる。その種の情報および値は、たとえば、ネットワーク・デバイスのＭＡＣアドレス、セッション識別子、およびそのほかの、隠されたフォーム要素内にストアできる値を含むことができる。

注意される必要があるが、いくつかの実施態様においては、認証要求が、ネットワーク・デバイス１０４によって呈示される最初のウェブ・ページとならないことがある。たとえば、ユーザがコーヒー・ショップにおいてサインオンを試みているとき、最初のウェブ・ページが、当該コーヒー・ショップからのウェルカム・ウェブ・ページとなることがある。このウェルカム・ウェブ・ページが、複数のログイン・オプションを提供することがある。それらの実施態様においては、認証要求に関連付けされたＵＲＬの一意的な断片を当該最初のウェブ・ページ上に埋め込むことができる。その結果、デジタル・デバイス１０２（たとえば、ネットワーク・モジュール２１４）が当該ウェブ・ページをスキミングしてそれらの断片を見つけ出すことができる。断片が見つかると、デジタル・デバイス１０２は、それの後に続くウェブ・ページ（たとえば、認証要求）に移動する。

次に図６を参照すると、例示的な認証ページ６００（たとえば、認証レコード）が示されている。認証ページ６００は、ユーザ名フィールド６０２およびパスワード・フィールド６０４を包含できる。いくつかの実施態様では、ユーザ名フィールド６０２が電子メール・フィールド、またはデジタル・デバイス１０２または関連するユーザに関連付けされた一意的な識別子を提供するための任意のほかのフィールドに置き換えられることがある。本発明の例示的な実施態様によれば、フィールド・モジュール２３０が、ネットワーク信用証明書を用いてユーザ名フィールド６０２およびパスワード・フィールド６０４を自動的に埋めることができる。

また認証ページ６００は、認証セレクタ６０６（たとえば、提出セレクタまたはボタン）も包含できる。認証セレクタ６０６は、ネットワーク信用証明書（たとえば、ユーザ名およびパスワード）をネットワーク・デバイス１０４に提出する。いくつかの実施態様では、ネットワーク信用証明書がそれぞれのフィールド６０２および６０４に関連付けされた後に、提出モジュール２３２が認証セレクタ６０６を自動的にアクティベートできる。

図７は、デジタル・デバイス１０２にネットワーク・アクセスを提供するための例示的なプロセスのフローチャートを図解している。デジタル・デバイス１０２が最初にホットスポット内に入るとき、デジタル・デバイス１０２（たとえばネットワーク・モジュール２１４）が、ステップ７００において通信ネットワーク１１４についてのスキャンを行うことができる。そのスキャンの結果として、ネットワーク・デバイス１０４は、ステップ７０２においてネットワーク構成情報を提供できる。ネットワーク構成情報は、ＤＮＳサーバ１１０にアクセスするための１つまたは複数のＩＰアドレスを包含できる。

ステップ７０４においては、信用証明書要求がデジタル・デバイス１０２によって生成される。図４に関連して上で論じたとおり、要求モジュール２２２が信用証明書要求を生成できる。その後に続き、信用証明書要求が、手前でネットワーク・デバイス１０４から受信したＩＰアドレスのうちの１つを使用して、ステップ７０６においてＤＮＳサーバ１１０に送信される。

その信用証明書要求に基づいて、ステップ７０８において、信用証明書サーバ１１６がＤＮＳサーバ１１０によって識別される。

信用証明書サーバ１１６は、その後ステップ７１２において、必要とされているネットワーク信用証明書を信用証明書要求に基づいて識別する。たとえば、信用証明書要求は、デジタル・デバイス１０２についての一意的な識別子を包含できる。この一意的な識別子は、場所識別子とともに、適正なネットワーク信用証明書を決定するべく信用証明書サーバ１１６においてその種の識別子のテーブルと比較できる。その後ステップ７１４において信用証明書要求応答が生成され、ステップ７１６においてＤＮＳサーバ１１０に返送される。ＤＮＳサーバ１１０は、ステップ７１８において、この信用証明書要求応答をデジタル・デバイスに転送する。

デジタル・デバイス１０２は、その後ステップ７２０において、信用証明書要求応答からネットワーク信用証明書を取得できる。例示的な実施態様においては、取得モジュール２２６が、信用証明書要求応答を分析して、それの中に埋め込まれているネットワーク信用証明書を取得することになる。

その後ステップ７２２において、ネットワーク・デバイス１０４にネットワーク信用証明書を提供できる。ネットワーク・デバイス１０４にネットワーク信用証明書を提供するための例示的な方法については、図５に関連して上で論じた。ネットワーク・デバイス１０４は、ネットワーク信用証明書を検証すると、ステップ７２４においてデジタル・デバイス１０２にネットワーク・アクセスを提供する。

ここで図８を参照すると、例示的な信用証明書要求８００がより詳細に示されている。例示的な実施態様によれば、要求モジュール２２２が、信用証明書要求８００を生成できる。１つの実施態様においては、信用証明書要求８００を、場所識別子８０２、シーケンス識別子８０４、署名８０６、デジタル・デバイス識別子（ＤＤＩＤ）８０８、サービス・セット識別子（ＳＳＩＤ）８１０、およびバージョン識別子８１２を包含する構造を有するＤＮＳ文字列とすることができる。

オプションの場所識別子８０２は、デジタル・デバイス１０２、ネットワーク・デバイス１０４、認証サーバ１０８、またはアクセス・コントローラ１１２の物理的、または地理上の場所を示すことができる。多様な実施態様において場所識別子４０２は、信用証明書サーバ１１６によって、ホットスポットの使用量、デジタル・デバイス１０２のユーザをはじめ、デジタル・デバイス１０２を追跡するべく使用されることがある。

シーケンス識別子８０４は、ログインが成功であるか否かを決定するべく、その後に続く信用証明書サーバ１１６への要求との対応に使用される任意の番号または番号のセットを包含できる。すなわちシーケンス識別子８０４は、相関メカニズムを提供し、それによって信用証明書サーバ１１６によるログイン・プロセスの検証ができる。

例示的な実施態様においては、署名８０６が、なりすましの防止に使用される暗号署名を包含する。デジタル・デバイス１０２からの要求の署名４０６は、信用証明書サーバ１１６によって検証される。署名４０６が有効でなければ、信用証明書サーバ１１６によってその要求が退けられる。

ＤＤＩＤ ８０８は、デジタル・デバイス１０２の一意的な識別子を包含する。たとえばＤＤＩＤ ８０８は、デジタル・デバイス１０２のＭＡＣアドレスまたはそのほかの任意の普遍的に一意的な識別子を包含できる。例示的な実施態様においては、ＤＤＩＤが、ＤＤＩＤストレージ２１２から検索される。

ＳＳＩＤ ８１０は、ネットワーク・アクセス・ポイントまたはワイファイ（Ｗｉ‐Ｆｉ）サービス・プロバイダの識別子を包含する。たとえばＳＳＩＤ ８１０は、サービス・プロバイダの名前またはネットワーク・デバイス１０４を操作する場所の名前を包含できる。

バージョン識別子８１２は、信用証明書要求８００のプロトコルまたはフォーマットを識別できる。たとえばデジタル・デバイスが信用証明書要求８００を生成し、かつ多数の異なるフォーマットでデータを組織化できる。それぞれの異なるフォーマットは、異なるバージョン識別子と関連付けできる。いくつかの実施態様においては、信用証明書エンジン２１６およびネットワーク・アクセス・エンジン２１８の構成要素が、更新され、再構成され、または時間を経て変更されることがあり、それが信用証明書要求８００の構造に影響を及ぼすことがある。結果として信用証明書サーバ１１６が、異なってフォーマットされた複数の信用証明書要求８００を受信することがあり得る。信用証明書サーバ１１６は、それぞれのバージョン識別子に基づいて、それぞれの信用証明書要求からの必要な情報にアクセスできる。

上で述べた機能および構成要素は、ストレージ媒体上にストアされるインストラクションからなるとすることができる。それらのインストラクションは、プロセッサによって取得され、実行されることが可能である。インストラクションのいくつかの例は、ソフトウエア、プログラム・コード、およびファームウエアである。ストレージ媒体のいくつかの例は、メモリ・デバイス、テープ、ディスク、集積回路、およびサーバである。インストラクションは、プロセッサによって実行されるとき、当該プロセッサに、本発明の実施態様と調和して動作することを指示するべく機能する。当業者は、インストラクション、プロセッサ（１つまたは複数）、およびストレージ媒体について熟知している。

以上、例示的な実施態様を参照して本発明を述べてきた。当業者には明らかとなろうが、より広い本発明の範囲から逸脱することなしに多様な修正が許され、かつそのほかの実施態様を使用することが可能である。したがって、例示的な実施態様に対するそれらの、およびそのほかの変形は、本発明によって保護されるべく意図されている。

１０２ デジタル・デバイス、１０４ ネットワーク・デバイス、１０６ ローカル・エリア・ネットワーク、１０８ 認証サーバ、１１０ ＤＮＳサーバ、１１２ アクセス・コントローラ、１１４ 通信ネットワーク、１１６ 信用証明書サーバ、２０２ プロセッサ、２０４ Ｉ／Ｏインターフェース、２０６ 通信ネットワーク・インターフェース、２０８ メモリ・システム、２１０ ストレージ・システム、２１２ ＤＤＩＤストレージ、２１４ ネットワーク・モジュール、２１６ 証明書エンジン、２１８ ネットワーク・アクセス・エンジン、２２０ 暗号化／復号化モジュール、２２２ 要求モジュール、２２４ 検証モジュール、２２６ 取得モジュール、２２８ 認証レコード・モジュール、２３０ フィールド・モジュール、２３２ 提出モジュール。

Claims (25)

1. ネットワーク・デバイスから認証要求を受信するステップと、
   前記認証要求に基づいて認証レコードを識別するステップと、
   前記認証レコードに基づいて認証応答内において信用証明書サーバからのネットワーク信用証明書を提供するステップと、
   ネットワーク・アクセスを獲得するべくネットワーク・デバイスに認証応答を送信するステップと、
   を含む方法。
2. 前記認証レコードに基づいて認証応答内において前記ネットワーク信用証明書を提供するステップとは、
   前記識別された認証レコードを取得すること、
   前記ネットワーク信用証明書を入力する前記認証要求内の入力要素を決定すること、
   前記ネットワーク信用証明書に基づいて前記入力要素内に入力応答を提供すること
   を含む、請求項１に記載の方法。
3. 前記認証レコードを識別するステップは、さらに、信用証明書要求応答に関連付けされたログイン・プロシージャ情報に基づいてフォームを識別することを包含する、請求項１に記載の方法。
4. さらに、
   前記ネットワーク・デバイスの標準プロトコルを介して信用証明書サーバに信用証明書要求を送信するステップと、
   前記信用証明書サーバから信用証明書要求応答を受信するステップと、
   前記信用証明書要求応答から前記ネットワーク信用証明書を取得するステップと、
   を包含する請求項１に記載の方法。
5. さらに、前記信用証明書要求応答を検証するステップを含む、請求項４に記載の方法。
6. さらに、前記信用証明書要求応答を復号化するステップを含む、請求項４に記載の方法。
7. さらに、前記ネットワーク・デバイスの真正を検証するステップを含む、請求項１に記載の方法。
8. 前記信用証明書は、ユーザ名を包含する、請求項１に記載の方法。
9. さらに、
   前記ネットワーク・デバイスからウェブ・ページを受信するステップと、
   前記ウェブ・ページに基づいて前記認証レコードを識別するステップと、
   をすむ、請求項１に記載の方法。
10. 前記認証要求は、ウェブ・ページを包含する、請求項１に記載の方法。
11. ネットワーク・デバイスから認証要求を受信するべく構成されたネットワーク・モジュールと、
    前記認証要求に基づいて認証レコードを識別するべく、かつ前記ネットワーク・デバイスに認証応答を送信するべく構成されたネットワーク・アクセス・エンジンと
    を含むシステム。
12. 前記ネットワーク・アクセス・エンジンは、さらに、前記認証レコードに基づいて認証応答内において信用証明書サーバからのネットワーク信用証明書を提供するべく構成される、請求項１１に記載のシステム。
13. 前記ネットワーク・アクセス・エンジンは、前記識別された認証レコードを取得するべく構成された認証レコード・モジュールを含む、請求項１１に記載のシステム。
14. 前記認証レコード・モジュールは、さらに、信用証明書要求応答に関連付けされたログイン・プロシージャ情報に基づいてフォームを識別するべく構成される、請求項１３に記載のシステム。
15. 前記ネットワーク・アクセス・エンジンは、前記認証レコードに基づいて前記ネットワーク信用証明書を入力する前記認証要求内の入力要素を決定するべく構成され、かつ前記ネットワーク信用証明書に基づいて前記入力要素内に少なくとも１つの入力応答を提供するべく構成されたフィールド・モジュールを含む、請求項１１に記載のシステム。
16. さらに、前記ネットワーク・デバイスの標準プロトコルを介して信用証明書サーバに信用証明書要求を送信するべく構成され、かつ前記信用証明書サーバから信用証明書要求応答を受信するべく構成された信用証明書エンジンを含む、請求項１１に記載のシステム。
17. 前記信用証明書エンジンは、さらに、前記信用証明書要求応答を認証するべく構成された検証モジュールを含む、請求項１６に記載のシステム。
18. さらに、前記信用証明書要求応答を復号化するべく構成された暗号化／復号化モジュールを含む、請求項１１に記載のシステム。
19. 前記ネットワーク・モジュールは、さらに、前記ネットワーク・デバイスの真正を検証するべく構成される、請求項１１に記載のシステム。
20. 前記信用証明書は、ユーザ名を含む、請求項１１に記載のシステム。
21. 前記ネットワーク・モジュールは、さらに、前記ネットワーク・デバイスからウェブ・ページを受信するべく構成され、かつ前記ネットワーク・アクセス・エンジンは、さらに、前記ウェブ・ページに基づいて前記認証レコードを識別するべく構成される、請求項１１に記載のシステム。
22. プロセッサにより実行をできるプログラムであって、その実行をされると、次の方法、すなわち：
    ネットワーク・デバイスから認証要求を受信すること、
    前記認証要求に基づいて認証レコードを識別すること、
    前記ネットワーク・デバイスに認証応答を送信すること
    を含む方法
    が実施されるプログラムを記憶したコンピュータ可読媒体。
23. 前記方法は、さらに、前記認証レコードに基づいて認証応答内において信用証明書サーバからのネットワーク信用証明書を提供することを包含する、請求項２２に記載のコンピュータ可読媒体。
24. 前記方法は、さらに、信用証明書要求応答に関連付けされたログイン・プロシージャ情報に基づいてフォームを識別することを包含する、請求項２２に記載のコンピュータ可読媒体。
25. 前記方法は、さらに、
    前記ネットワーク・デバイスの標準プロトコルを介して信用証明書サーバに信用証明書要求を送信すること、
    前記信用証明書サーバから信用証明書要求応答を受信すること、
    前記信用証明書要求応答から前記ネットワーク信用証明書を取得すること、
    を含む、請求項２２に記載のコンピュータ可読媒体。

Images