JP2010503319A - ネットワーク信用証明書を獲得するためのシステムおよび方法 - Google Patents

Abstract

【課題】 ネットワーク・アクセスについてのネットワーク信用証明書を獲得するための例示的な方法およびシステムが述べられる。この例示的な方法は、通信ネットワーク上のネットワーク・デバイスからネットワーク構成情報を受信すること、信用証明書要求を生成すること、信用証明書要求を信用証明書サーバに、ネットワーク・デバイスの標準プロトコルを介して送信すること、信用証明書要求応答を受信すること、および信用証明書要求応答からのネットワーク信用証明書を、通信ネットワークにアクセスするためにネットワーク・デバイスに提供することを包含する。

Description

本発明は、概して通信ネットワークへのアクセスに関する。より詳細に述べれば、本発明は、無線通信ネットワークの自動アクセスに関する。

情報にアクセスするためのネットワークの使用の増加は、多様な活動のための通信ネットワークへのより大きな依存を結果として招いた。この依存には、ネットワーク・アクセスが遍在することになろうという期待のふくらみが付属する。モバイル・ユーザのためのネットワーク・アクセスは、特に、無線テクノロジにおける改善によって強化されてきた。多様なセルラ（たとえば、ＧＳＭ、ＣＤＭＡ、およびそれらの類）、ワイファイ（Ｗｉ‐Ｆｉ）（すなわちＩＥＥＥ ８０２．１１）、ワイマックス（ＷｉＭＡＸ）（すなわちＩＥＥＥ ８０２．１６）、およびそのほかのテクノロジが、潜在的ネットワーク・ユーザのための広範なアクセス・オプションを可能にした。多くの無線アクセス・ポイントまたは『ホットスポット』は、局所的な地理的領域でのみアクセス可能であり、場合によっては、特定のビジネスまたはそのほかのアドレス程度にまで狭められる。加えて、戦略的に配置されたホットスポットは、人々の多様なグループのための公衆または専用ネットワーク・アクセスを提供することができる。

ホットスポットの所有者または管理者は、しばしば、ユーザのアクセスを可能にするためにパスワードおよびその類を要求する。その結果として、複数のホットスポットのユーザは、多数のパスワードをストアし、記憶し、またはそのほかの方法で管理しなければならないことがある。多くのユーザは、ホットスポットへのアクセスに使用するラップトップ・コンピュータ上に自分のパスワードをストアすることがある。しかしながら、ホットスポットにアクセスする能力のあるすべてのデバイスがラップトップ・コンピュータではなく、現在は、携帯電話、携帯情報端末（ＰＤＡ）、および多くのそのほかのデバイスが、無線アクセスの能力を有する。残念ながらしばしばユーザは、デバイス上にパスワードを入力すること、またはデバイス内にパスワードをストアすることを容易になし得ない。たとえば、無線アクセスの能力のあるいくつかのデバイスは、キーボードを有していないことがある。デバイスがキーボードを含む場合であっても、当該キーボードは、しばしば小さく、しかも機能の限られたものであることがあり、指先の器用さが限られたユーザにとっては特にそうなる。

ユーザがラップトップ・コンピュータ上にパスワードをストアするとき、そのユーザは最初にラップトップ・コンピュータに近づき、かつ当該コンピュータ内に正しいパスワードをストアしなければならない。パスワードの変更時には、そのユーザに、そのコンピュータ内におけるパスワードの更新が要求される。加えて、デバイス内にユーザ名およびパスワードをストアさせることは、当該デバイスの紛失または盗難があった場合にセキュリティ問題を呈示する。

さらに、ユーザは、通常、ネットワーク・アクセスを獲得するために、パスワード、ユーザ名を入力し、またウェブ・サイトを渡り歩くことが要求される。このプロセスは、時間を要し、かつユーザが誤った情報を入力することがあり、またデータの再入力が強要される。

ユーザがパスワードをマニュアル入力するときは、難しいパスワードをあまり記憶しようとしない。その結果、単純なパスワードアクセスおよび暗号化されないアクセスがハッキングを受けやすく、そのユーザのネットワーク・アクセス、ホットスポット、および／またはそのユーザの個人情報を危険にさらすことがある。さらに、ユーザの単純なパスワードがハッキングされるか、または単純に推測された場合には、そのユーザのネットワーク・アクセスが盗まれることもある。

ネットワーク・アクセスについてのネットワーク信用証明書を獲得するための例示的な方法およびシステムが述べられている。この例示的な方法は、通信ネットワーク上のネットワーク・デバイスからネットワーク構成情報を受信すること、信用証明書要求を生成すること、信用証明書要求を信用証明書サーバに、ネットワーク・デバイスの標準プロトコルを介して送信すること、信用証明書要求応答を受信すること、および信用証明書要求応答からのネットワーク信用証明書を、通信ネットワークにアクセスするためにネットワーク・デバイスに提供することを包含する。

さらにこの方法は、信用証明書要求を暗号化すること、信用証明書要求応答を復号化（平文化）すること、および信用証明書要求をディジタル署名することを包含できる。標準プロトコルは、ＤＮＳオーバー・ユーザ・データグラム・プロトコル（ＵＤＰ）とすることができる。さらに、信用証明書要求は、ディジタル・デバイス識別子（ＤＤＩＤ）およびネットワーク構成情報のうちの少なくともいくつかに基づくことができる場所（ロケーション）識別子を包含できる。

信用証明書要求応答は、当該信用証明書要求応答をキャッシュさせないコマンドを包含できる。信用証明書要求応答からの信用証明書を提供することは、ネットワーク・アクセス・ページを分析すること、およびネットワーク・アクセス・ページ内のフォーム情報を書き込むことを包含できる。

ネットワーク信用証明書を獲得するための例示的なシステムは、ネットワーク・モジュール、信用証明書要求モジュール、信用証明書エンジン、およびネットワーク・アクセス・エンジンを包含できる。ネットワーク・モジュールは、通信ネットワーク上のネットワーク・デバイスからネットワーク構成情報を受信するべく、かつネットワーク・デバイスの標準プロトコルを介して信用証明書要求を信用証明書サーバに送信するべく構成できる。信用証明書要求モジュールは、信用証明書要求を生成するべく構成できる。信用証明書エンジンは、信用証明書要求応答を受信するべく構成できる。ネットワーク・アクセス・エンジンは、信用証明書要求応答からのネットワーク信用証明書を、通信ネットワークにアクセスするためにネットワーク・デバイスに提供するべく構成できる。

例示的なコンピュータ可読媒体は、その上にプログラムを収録しているものとすることができる。当該プログラムは、ネットワーク信用証明書を獲得するための方法を実行するためにプロセッサによって実行可能であるとすることができる。当該方法は、通信ネットワーク上のネットワーク・デバイスからネットワーク構成情報を受信すること、信用証明書要求を生成すること、信用証明書要求を信用証明書サーバに、ネットワーク・デバイスの標準プロトコルを介して送信すること、信用証明書要求応答を受信すること、および信用証明書要求応答からのネットワーク信用証明書を、通信ネットワークにアクセスするためにネットワーク・デバイスに提供することを包含できる。

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

本発明の実施態様は、ネットワーク信用証明書を獲得するためのシステムおよび方法を提供する。例示的な実施態様においては、ディジタル・デバイスがユーザに関連付けされる。アクセス・コントローラ（たとえば、ホットスポット・アクセス・ポイントに関連付けされる）が、ディジタル・デバイスに、ホットスポットを使用し、通信ネットワークにアクセスするために、認証、またはそのほかの方法でのネットワーク信用証明書（たとえば、ユーザ名およびパスワード）の提供を要求する。ディジタル・デバイスとネットワーク・デバイスの間における接続のネゴシエーションの後であるが、信用証明書が提供される前に、ディジタル・デバイスは、標準プロトコルを使用して信用証明書要求をネットワーク・デバイスに対して送信することができる。信用証明書サーバは、信用証明書要求を受信し、通信ネットワークにアクセスする正しい信用証明書を識別する。信用証明書サーバは、信用証明書要求応答とともにネットワーク信用証明書をディジタル・デバイスに返送することができ、続いてそれが、通信ネットワークへのアクセスを獲得するネットワーク信用証明書を提供する。１つの実施態様においては、通信ネットワークがインターネットを包含する。

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

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

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

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

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

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

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

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

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

ディジタル・デバイス１０２がネットワーク信用証明書応答を受信した後は、ディジタル・デバイス１０２が、（ネットワーク信用証明書応答から取得された）ネットワーク信用証明書を認証応答の中でネットワーク・デバイス１０４に提出できる。例示的な実施態様においては、認証応答が、検証のために認証サーバ１０８に転送されることがある。いくつかの実施態様においては、認証サーバ１０８が、ＡＡＡサーバまたはラディウス（ＲＡＤＩＵＳ）サーバを包含できる。ネットワーク・アクセスを獲得するためのプロセスに関するより詳細な内容が、参照によってこれに援用される、２００７年９月６日に出願された『システム・アンド・メソッド・フォア・オブテインニング・ネットワーク・アクセス（Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｏｂｔａｉｎｉｎｇ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ）』と題された同時係属の米国特許出願第＿＿号の中に提供されている。

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

図２は、例示的なディジタル・デバイスのブロック図である。ディジタル・デバイス１０２は、認証モジュール２００、ネットワーク・モジュール２０２、信用証明書要求モジュール２０４、信用証明書エンジン２０６、暗号化／復号化モジュール２０８、ＤＤＩＤ（ディジタル・データ・インターフェース・デバイス）ストレージ２１０、およびネットワーク・アクセス・エンジン２１２を包含する。モジュールは、個別に、または組み合わせでソフトウエア、ハードウエア、ファームウエア、または回路を包含できる。

認証モジュール２００は、信用証明書要求に対してセキュリティを提供し、信用証明書要求応答を認証し、かつディジタル・デバイス１０２と認証サーバ１０８の間における安全な通信を確立するべく構成できる。多様な実施態様においては、認証モジュール２００が、信用証明書要求をディジタル署名することによって信用証明書要求にセキュリティを提供する。１つの例では、信用証明書要求が、信用証明書サーバ１１６と共有される暗号鍵を使用して署名される。

認証モジュール２００は、信用証明書サーバ１１６から受信された信用証明書要求応答を、暗号鍵（たとえば、共有された暗号鍵）を用いて当該信用証明書要求応答を復号化（平文化）することによって認証できる。いくつかの実施態様においては、暗号化／復号化モジュール２０８が信用証明書要求応答を復号化する。

多様な実施態様においては、認証モジュール２００が、乱数値（すなわち、ナンス値）を生成すること、および信用証明書要求内にその値を含めることもできる。信用証明書要求応答が受信されたとき、当該信用証明書要求応答からナンスを取得し、信用証明書要求応答の追加の認証を行うべく信用証明書要求内に含められた乱数値と比較することができる。

ネットワーク・モジュール２０２は、通信ネットワーク１１４にアクセスするために動作を実行するべく構成できる。いくつかの実施態様においては、ネットワーク・モジュール２０２がホットスポットへのアクセスに関連付けされた通信の受信および送信ができる。１つの例では、ネットワーク・モジュール２０２が、ディジタル・デバイス１０２およびネットワーク・デバイス１０４を介した初期接続をネゴシエートする。

いくつかの実施態様においては、ネットワーク・モジュール２０２が、通信ネットワーク１１４のサーチを実行できる。たとえば、ディジタル・デバイス１０２がホットスポットに入るとき、ネットワーク・モジュール２１４が通信ネットワーク１１４との接続を試行できる。ディジタル・デバイス１０２が通信ネットワーク１１４にアクセスできない場合、ここで述べられている本発明の実施態様を実施できることがある。

信用証明書要求モジュール２０４は、信用証明書要求の生成および送信ができる。信用証明書要求は、標準プロトコルとすることができる。１つの例においては、信用証明書要求がＵＤＰプロトコルになる。

多様な実施態様において、信用証明書要求モジュール２０４が、ネットワーク・デバイス１０４からネットワーク・デバイス識別子を取得する。１つの例では、ネットワーク・デバイス識別子が、当該ネットワーク・デバイスのサービス・セット識別子（ＳＳＩＤ）である。ネットワーク・デバイス識別子は、その後、信用証明書要求内に含めることができる。代替として、信用証明書要求モジュール２０４は、ネットワーク・デバイス１０４によって提供されるネットワーク・アクセス・ページからサービス・プロバイダを識別できる。信用証明書要求モジュール２０４は、その後、当該サービス・プロバイダ識別子を信用証明書要求内に提供できる。

ネットワーク・アクセス・ページは、認証サーバ１０８から受信されたウェブ・ページまたは情報（たとえば、ＸＭＬタグ）を包含できる。ネットワーク・アクセス・ページに応答して、ディジタル・デバイス１０２は、ネットワーク・アクセスを獲得するべく情報（たとえば、ネットワーク信用証明書または応答）を認証サーバ１０８に提供できる。１つの例では、ネットワーク・アクセス・ページが、認証サーバ１０８および／またはネットワーク・デバイス１０４からディジタル・デバイス１０２によって受信されたいくつかのウェブ・ページを包含する。別の例においては、ネットワーク・アクセス・ページが、１つまたは複数のタグまたはウェブ・ページおよびタグの組み合わせを包含する。

信用証明書要求モジュール２０４は、また、ディジタル・デバイス識別子（ＤＤＩＤ）および／またはユーザ識別子を信用証明書要求内に含めることができる。多様な実施態様においては、ＤＤＩＤがＭＡＣアドレス、一意的な識別子、またはそのほかの、ディジタル・デバイス１０２を識別する任意の識別子を包含できる。ユーザ識別子は、ディジタル・デバイス１０２の所有者またはユーザを識別する任意の識別子（たとえば、ユーザ名またはパスコード）とすることが可能である。

例示的な信用証明書エンジン２０６は、信用証明書要求応答を受信すること、およびネットワーク信用証明書を取得することができる。いくつかの実施態様においては、信用証明書要求応答が暗号化／復号化モジュール２０８によって復号化され、認証モジュール２００によってナンス認証される。

上で論じたとおり、取得されたネットワーク信用証明書が、ログイン・プロシージャ情報を包含することがある。１つの例においては、信用証明書が、ユーザ名およびパスワードを含み、それらが、認証サーバ１０８から取得されたフォーム内に提供される。いくつかの実施態様においては、ログイン・プロシージャ情報が、信用証明書エンジン２０６に、完成されたフォームを認証サーバ１０８に提出する前に、正しい信用証明書を用いてフォーム内の特定のフィールドを埋めることを指示できる。当業者は認識するであろうが、認証サーバ１０８に信用証明書を提供する多くの方法がある。認証サーバに信用証明書を提供するプロセスは、２００７年９月６日に出願された『システムズ・アンド・メソッズ・フォア・オブテインニング・ネットワーク・アクセス（Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｏｂｔａｉｎｉｎｇ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ）』と題された同時係属の米国特許出願第＿＿号の中でさらに論じられている。

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

ＤＤＩＤストレージ２１０は、ＤＤＩＤをストアする。ＤＤＩＤは、ＤＤＩＤストレージ２１０から、信用証明書要求が生成されるときに信用証明書要求モジュール２０４によって取得されることがある。ＤＤＩＤストレージ２１０は、オプションにできる（たとえば、ＤＤＩＤがディジタル・デバイス１０２のＭＡＣアドレスのとき）。ＤＤＩＤストレージ２１０は、また、ディジタル・デバイス１０２の所有者またはユーザ、または信用証明書サーバ１１６に関連付けされたアカウントの所有者を識別するユーザ識別子も包含できる。いくつかの実施態様においては、ユーザ識別子が、信用証明書サーバ１１６上のアカウントに関連付けされたユーザの識別子を包含する。

例示的なネットワーク・アクセス・エンジン２１２は、認証要求を受信し、ネットワーク・デバイス１０４に認証応答を提供してネットワーク信用証明書を包含するべく構成できる。

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

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

その信用証明書要求に基づいて、ステップ３０８において、信用証明書サーバ１１６がＤＮＳサーバ１１０によって識別される。ＤＮＳサーバ１１０は、信用証明書要求を信用証明書サーバ１１６に転送する。ＤＮＳサーバ１１０が、ローカルでＤＮＳ要求を解決できないときは、その信用証明書要求が通信ネットワーク１１４上の別のＤＮＳサーバに転送され、その後それが信用証明書サーバ１１６にその信用証明書要求を転送することができる。信用証明書要求は、ステップ３１０において、直接または通信ネットワーク１１４上のほかの１つまたは複数のＤＮＳサーバを通じて間接的に信用証明書サーバ１１６に転送される。

信用証明書サーバ１１６は、ステップ３１２において、必要とされているネットワーク信用証明書を信用証明書要求に基づいて識別する。たとえば、信用証明書要求は、ディジタル・デバイス１０２についての識別子（すなわち、ＤＤＩＤ）をはじめ、ホットスポットについての識別子（たとえば、オペレータ等のサービス・プロバイダ）を包含できる。識別子は、信用証明書サーバ１１６において、適正なネットワーク信用証明書を決定するべくその種の識別子のテーブルと比較できる。その後ステップ３１４において信用証明書要求応答が生成され、ステップ３１６においてＤＮＳサーバ１１０に中継される。ＤＮＳサーバ１１０は、この信用証明書要求応答を、ステップ３１８においてディジタル・デバイスに転送する。

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

その後ステップ３２２において、ネットワーク・デバイス１０４にネットワーク信用証明書を提供できる。ネットワーク・デバイスに（およびその後に続いて認証サーバ１０８に）ネットワーク信用証明書を提供するための例示的な方法は、２００７年９月６日に出願された『システムズ・アンド・メソッズ・フォア・オブテインニング・ネットワーク・アクセス（Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｏｂｔａｉｎｉｎｇ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ）』と題された同時係属の米国特許出願第＿＿号の中で論じられている。ネットワーク信用証明書を検証すると、ネットワーク・デバイス１０４がステップ３２４においてディジタル・デバイス１０２にネットワーク・アクセスを提供する。

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

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

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

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

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

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

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

図５は、ネットワーク信用証明書を獲得するための例示的な方法のフローチャートである。ステップ５０２においては、ディジタル・デバイス１０２が、ネットワーク構成情報を受信する。１つの例では、ネットワーク・モジュール２０２が、ネットワーク・デバイス１０４を介して利用可能な無線ネットワークをサーチし、かつ探し出す。ネットワーク・モジュール２０２が、ネットワーク・デバイス１０４との接続をネゴシエートする。ネゴシエーションの間、ネットワーク・モジュール２０２がネットワーク構成情報を受信することがある。ネットワーク構成情報は、ネットワーク・デバイス１０４およびＤＮＳサーバ１１０についての識別子を包含できる。１つの例においては、ネゴシエーションの間にネットワーク・モジュール２０２が、（たとえば、ＤＮＳサーバ１１０についての）ＤＮＳサーバＩＰアドレスを受信する。ネットワーク・モジュール２０２は、認証サーバ１０８に関連付けされたサービス・プロバイダの識別子も受信することがある（たとえば、Ｔモバイル（Ｔ‐ｍｏｂｉｌｅ））。

ステップ５０４においては、ディジタル・デバイス１０２が信用証明書要求を生成する。多様な実施態様において、信用証明書要求モジュール２０４が信用証明書要求を生成する。信用証明書要求は、シーケンス識別子、ＤＤＩＤ、およびＳＳＩＤを包含できる。多様な実施態様において、信用証明書要求モジュール２０４がナンスを生成し、暗号鍵を用いて信用証明書要求をディジタル署名する。

ステップ５０６においては、ディジタル・デバイス１０２が、標準プロトコルを使用して信用証明書要求を送信する。ネットワーク・デバイス１０４は、その信用証明書要求を受信し、かつ通信ネットワーク１１４に転送できる。多様な実施態様においては、ネットワーク・デバイス１０４が、認証サーバ１０８、ＤＮＳサーバ１１０、またはアクセス・コントローラ１１２に信用証明書要求を提供でき、それもまた当該信用証明書要求を転送できる。

信用証明書サーバ１１６は、信用証明書要求を受信できる。多様な実施態様においては、信用証明書サーバ１１６が、暗号鍵を用いてディジタル署名を復号化し、ディジタル署名を認証する。信用証明書サーバ１１６は、続いてその信用証明書要求内に含められた情報に基づいて適正なネットワーク信用証明書を識別できる。ネットワーク信用証明書は、信用証明書要求応答内に組み込むことができ、ディジタル・デバイス１０２に返送される。

ステップ５０８においては、ディジタル・デバイス１０２が、信用証明書要求応答を受信し、ネットワーク信用証明書を取得する。１つの例では、信用証明書エンジン２０６が信用証明書要求応答を受信し、かつ認証する。信用証明書要求応答が認証された場合には、ネットワーク信用証明書が、当該信用証明書要求応答から取得される。

ステップ５１０においては、ディジタル・デバイス１０２が、通信ネットワーク１１４に対するネットワーク・アクセスを獲得するべくネットワーク信用証明書をネットワーク・デバイス１０４に提供する。１つの例では、信用証明書エンジン２０６が認証サーバ１０８から１つまたは複数のフォームを取得し、１つまたは複数の信用証明書を用いて当該フォームを埋め、完成されたフォームを認証サーバ１０８に提供する。別の例においては、信用証明書エンジン２０６が必要時にネットワーク信用証明書を認証サーバ１０８に提供する。認証サーバ１０８によってネットワーク信用証明書が受信されると、認証サーバ１０８は、ディジタル・デバイス１０２と通信ネットワーク１１４の間の通信を許可できる。１つの例では、認証サーバ１０８がアクセス・コントローラ１１２に、通信の許可を命令する。

図６は、ネットワーク信用証明書を獲得するための例示的な方法の別のフローチャートである。ステップ６０２においては、ディジタル・デバイス１０２がネットワーク構成情報を受信する。ステップ６０４においては、ディジタル・デバイス１０２が、ネットワークの連結性をテストする。たとえば、ネットワーク・デバイス１０４を通じて接続がネゴシエートされた後に、ネットワーク・モジュール２０２が、ウェブ・サイトへの接続を試行できる。それに応答して、認証サーバ１０８またはアクセス・コントローラ１１２が、試行された接続を、ネットワーク信用証明書を要求するネットワーク・アクセス・ページにリダイレクトできる。多様な実施態様において、信用証明書要求モジュール２０４が、認証サーバ１０８に関連付けされたサービス・プロバイダを、ネットワーク・アクセス・ページを通じて識別できる。

ステップ６０６においては、ディジタル・デバイス１０２が信用証明書要求を生成する。多様な実施態様において、信用証明書要求は、ディジタル・デバイス１０２に関連付けされたユーザを識別するＤＤＩＤおよびネットワーク・アクセス・ポイント（たとえばネットワーク・デバイス１０４、認証サーバ１０８、またはサービス・プロバイダ）を識別するＳＳＩＤを包含する。信用証明書要求は、また、シーケンス識別子およびバージョン識別子も包含できる。

ステップ６０８においては、ディジタル・デバイス１０２が、信用証明書要求にディジタル署名する。多様な実施態様では、ナンスが生成されてディジタル署名の中に含められる。１つの例においては、信用証明書要求が暗号鍵（たとえば、ペアの鍵のうちの１つまたは信用証明書サーバ１１６と共有される暗号鍵）を用いて暗号化される。

ステップ６１０においては、ディジタル・デバイス１０２が、信用証明書要求を信用証明書サーバ１１６に標準プロトコルを介して送信する。１つの例では、信用証明書要求が、ネットワーク構成情報の中で受信されたＤＮＳサーバＩＰアドレスによって識別されたＤＮＳサーバ１１０に送信される。いくつかの実施態様では、ＤＮＳサーバ１１０が、当該信用証明書要求をローカルに解決できないＤＮＳ要求として扱い、その信用証明書要求を別のＤＮＳサーバに通信ネットワーク１１４を介して転送する。最終的に、信用証明書サーバ１１６が転送された信用証明書要求を受信できる。

信用証明書サーバ１１６は、信用証明書要求内のディジタル署名の認証およびナンスの取得を行うことができる。信用証明書サーバ１１６は、その後、信用証明書サーバ１１６内に含められているＤＤＩＤおよびＳＳＩＤを使用して信用証明書サーバ１１６内に含められているレコードから正しいネットワーク信用証明書の決定および検索を行うことができる。その後に続いて、信用証明書サーバ１１６が、ナンスおよびネットワーク信用証明書を含む信用証明書要求応答を生成する。当該信用証明書要求応答は、暗号鍵（たとえば、鍵ペアのうちの１つの暗号鍵または共有された暗号鍵）を使用して暗号化される。多様な実施態様では、暗号化された信用証明書要求応答が、信用証明書要求内においてディジタル・デバイス１０２から受信されたナンスを含む。その後、信用証明書要求応答がディジタル・デバイス１０２に返送される。

信用証明書サーバ１１６は、シーケンス識別子をストアできる。多様な実施態様では、シーケンス識別子を使用して、ディジタル・デバイス１０２が通信ネットワーク１１４へのアクセスの獲得に成功したか否かを決定できる。さらに、信用証明書要求応答は、信用証明書要求応答をキャッシュ不用とするコマンドを包含できる。このキャッシュ不用コマンドに応答して、中間ＤＮＳサーバ（すなわち、信用証明書サーバ１１６とディジタル・デバイス１０２の間において信用証明書要求応答を中継するＤＮＳサーバ）は、当該信用証明書要求応答をキャッシュしない。いくつかの実施態様においては、このコマンドに応答して、ディジタル・デバイス１０２が、信用証明書要求応答のキャッシュまたはＤＮＳライブラリの更新を行わないことがある。

信用証明書サーバ１１６が信用証明書要求応答を生成するプロセスは、２００７年９月６日に出願された『システムズ・アンド・メソッズ・フォア・オブテインニング・ネットワーク・アクセス（Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｏｂｔａｉｎｉｎｇ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ）』と題された同時係属の米国特許出願第＿＿号の中でさらに論じられている。

ステップ６１２においては、ディジタル・デバイス１０２が信用証明書サーバ１１６から信用証明書要求応答を受信する。ステップ６１４においては、ディジタル・デバイス１０２が当該信用証明書要求応答を復号化する。１つの例では、ディジタル・デバイス１０２が、暗号鍵を使用して信用証明書要求応答を復号化し、その信用証明書要求応答からナンスを取得する。

ステップ６１６においては、ディジタル・デバイス１０２が信用証明書要求応答を認証する。多様な実施態様においてディジタル・デバイス１０２は、信用証明書要求応答の復号化の成功に基づいて真正を決定する。いくつかの実施態様では、信用証明書要求応答から取得されたナンスが、生成されて信用証明書要求内に含められたナンスと比較され、信用証明書要求応答の追加の認証が行われる。

信用証明書要求応答が認証されると、ディジタル・デバイス１０２は、ステップ６１８において信用証明書要求応答からネットワーク信用証明書を取得する。ステップ６２０においては、ディジタル・デバイス１０２が、ネットワーク・アクセスと関連付けされた認証要件を識別する。

多様な実施態様では、ディジタル・デバイス１０２が、正しい情報およびネットワーク信用証明書を決定して認証サーバ１０８に提供する。１つの例においてディジタル・デバイス１０２は、認証サーバ１０８から１つまたは複数のネットワーク・アクセス・ページを検索する。ディジタル・デバイス１０２は、認証サーバからの正しいネットワーク・アクセス・ページにアクセスし、かつ自動的に選択を行うことができる。１つの例では、ディジタル・デバイス１０２が自動的に選択をアクティベートできる（たとえば、ネットワーク・アクセス・ページ内のボタン、チェック・ボックス、および選択ラジオ・ボタンをアクティベートする）。自動選択は、信用証明書エンジンによる選択に基づくことができる。たとえば信用証明書エンジンは、認証サーバから検索されたフォーム（１つまたは複数）の識別および自動選択のための実行可能インストラクションの提供を行うことができるフォーム・ライブラリ（図示せず）にアクセスできる。信用証明書エンジンは、また、信用証明書要求応答から取得されたネットワーク信用証明書内に含められていたインストラクションに基づいて選択をアクティベートすることもある。当業者は認識するであろうが、選択を自動的に行うことができる多くの方法が存在し得る。

ほかの実施態様においては、ディジタル・デバイス１０２が、最初にネットワーク・アクセス・ページを取得することなく、認証サーバ１０８に送信する適正な情報を決定できる。認証サーバ１０８に送信する適正な情報の決定は、ネットワーク・デバイス１０４、認証サーバ１０８、またはサービス・プロバイダを識別するインストラクションを基礎にできる。

ステップ６２２においては、ディジタル・デバイス１０２が、認証要件に従ってネットワーク・アクセスのためのネットワーク信用証明書を提供する。多様な実施態様では、ディジタル・デバイス１０２が、ネットワーク信用証明書からのユーザ名、パスワード、アカウント番号、またはそれらの類を認証サーバ１０８に提供する。認証サーバ１０８がディジタル・デバイス１０２を認証した後は、認証サーバ１０８が、アクセス・コントローラ１１２に、ディジタル・デバイス１０２と通信ネットワーク１１４の間の通信アクセスを許可するべく命令できる。

多様な実施態様においては、ネットワーク信用証明書が、ネットワーク・アクセス・ページ内のオプションを単純にアクティベートするべくディジタル・デバイス１０２に指示するログイン・プロシージャ情報を包含する。１つの例では、ネットワーク・アクセス・ページが、単純にサービスの期間および条件からなるとすることができる。ディジタル・デバイス１０２がネットワーク・アクセスを獲得するためには、ネットワーク・アクセス・ページ内における単一の選択がアクティベートされなければならない（『提出』ボタンまたはユーザが期間および条件に合意したことの表示等）。少なくとも部分的にログイン・プロシージャ情報に準じてディジタル・デバイス１０２は、自動的に正しい選択を行い、かつパスワードまたはユーザ名等の信用証明書をさらに提供することなくネットワーク・アクセスを獲得できる。当業者によって認識されるであろうが、ログイン・プロシージャ情報に基づいて１つまたは複数の選択が自動的に行われるようにできる。

さらに、１つまたは複数のユーザ名、１つまたは複数のパスワード、および１つまたは複数のログイン・プロシージャ情報の任意の組み合わせがネットワーク信用証明書内に含められることがある。いくつかの実施態様では、ネットワーク信用証明書がユーザ名を含むことができる。ほかの実施態様では、ネットワーク信用証明書がパスワードを含むことができる。

ステップ６２４においては、ディジタル・デバイス１０２がネットワークの連結性をテストしてネットワーク・アクセスを確認する。１つの例では、ディジタル・デバイス１０２が信用証明書サーバ１１６に関連付けされたウェブ・サイト（たとえば、信用証明書サーバ１１６がウェブ・サーバとして機能できる）への接続を試行する。いくつかの実施態様では、クエリまたはコマンドが、以前に信用証明書要求内において提出されたシーケンス識別子を含む。ネットワーク・アクセスが成功した場合には、信用証明書サーバ１１６が、当該クエリまたはコマンドを受信し、シーケンス識別子を取得できる。信用証明書サーバ１１６は、その後、そのネットワーク・アクセスが成功したことを確認できる。

図７は、例示的なディジタル・デバイスのブロック図である。ディジタル・デバイス１０２は、プロセッサ７００、メモリ・システム７０２、ストレージ・システム７０４、Ｉ／Ｏインターフェース７０６、通信ネットワーク・インターフェース７０８、およびディスプレイ・インターフェース７１０を包含する。プロセッサ７００は、実行可能インストラクション（たとえばプログラム）を実行するべく構成される。いくつかの実施態様ではプロセッサ７００が、実行可能インストラクションを処理する能力のある回路または任意のプロセッサを包含する。

メモリ・システム７０２は、データをストアするべく構成された任意のメモリである。メモリ・システム７０２のいくつかの例は、ＲＡＭまたはＲＯＭ等のストレージ・デバイスである。メモリ・システム７０２は、ＲＡＭキャッシュを包含することが可能である。多様な実施態様においては、データがメモリ・システム７０２内にストアされる。メモリ・システム７０２内のデータは、クリアされるか、または最終的にストレージ・システム７０４に転送されることがある。

ストレージ・システム７０４は、データの取得およびストアを行うべく構成された任意のストレージである。ストレージ・システム７０４のいくつかの例は、フラッシュ・ドライブ、ハード・ドライブ、光学ドライブ、および／または磁気テープである。いくつかの実施態様においては、ディジタル・デバイス１０２が、ＲＡＭの形でメモリ・システム７０２を、かつフラッシュ・データの形でストレージ・システム７０４を含む。メモリ・システム７０２およびストレージ・システム７０４は、ともに、プロセッサ７００を含むコンピュータ・プロセッサによって実行可能なインストラクションまたはプログラムをストアできるコンピュータ可読媒体を構成する。

オプションの入力／出力（Ｉ／Ｏ）インターフェース７０６は、ユーザから入力を受け取り、データを出力する任意のデバイスである。オプションのディスプレイ・インターフェース７１０は、グラフィクスおよびデータをディスプレイに出力するべく構成された任意のデバイスである。１つの例においては、ディスプレイ・インターフェース７１０がグラフィック・アダプタになる。認識されるであろうが、すべてのディジタル・デバイス１０２が、Ｉ／Ｏインターフェース８０６またはディスプレイ・インターフェース８１０のうちのいずれも包含するわけではない。

通信ネットワーク・インターフェース（コム・ネットワーク・インターフェース）７０８は、リンク７１２を介してネットワーク（たとえば、ローカル・エリア・ネットワーク１０６および通信ネットワーク１１４）に結合することが可能である。通信ネットワーク・インターフェース７０８は、たとえばイーサネット接続、シリアル接続、パラレル接続、またはＡＴＡ接続を介した通信をサポートできる。また通信ネットワーク・インターフェース７０８は、無線通信（たとえば、８０２．１１ａ／ｂ／ｇ／ｎ、ワイマックス（ＷｉＭａｘ））もサポートできる。当業者には明らかとなろうが、通信ネットワーク・インターフェース７０８は、多くの有線および無線標準をサポートすることが可能である。

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

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

１０２ ディジタル・デバイス、１０４ ネットワーク・デバイス、１０６ ローカル・エリア・ネットワーク、１０８ 認証サーバ、１１０ ＤＮＳサーバ、１１２ アクセス・コントローラ、１１４ 通信ネットワーク、１１６ 信用証明書サーバ、２００ 認証モジュール、２０２ ネットワーク・モジュール、２０４ 信用証明書要求モジュール、２０６ 信用証明書エンジン、２０８ 暗号化／復号化モジュール、２１０ ＤＤＩＤストレージ、２１２ ネットワーク・アクセス・エンジン。

Claims (24)

1. ネットワーク信用証明書を獲得するための方法であって、
   通信ネットワーク上のネットワーク・デバイスからネットワーク構成情報を受信するステップと、
   信用証明書要求を生成するステップと、
   前記信用証明書要求を信用証明書サーバに、前記ネットワーク・デバイスの標準プロトコルを介して送信するステップと、
   信用証明書要求応答を受信するステップと、
   前記通信ネットワークにアクセスするために前記ネットワーク・デバイスに、前記信用証明書要求応答からのネットワーク信用証明書を提供するステップと、
   を包含する方法。
2. さらに、前記信用証明書要求を暗号化するステップとを包含する、請求項１に記載の方法。
3. さらに、前記信用証明書要求応答を復号化するステップとを包含する、請求項１に記載の方法。
4. さらに、前記信用証明書要求をディジタル署名するステップとを包含する、請求項１に記載の方法。
5. 前記標準プロトコルはＤＮＳである、請求項１に記載の方法。
6. 前記信用証明書要求は場所識別子を包含する、請求項１に記載の方法。
7. 前記場所識別子は、前記ネットワーク構成情報のうちの少なくともいくつかに基づく、請求項６に記載の方法。
8. 前記信用証明書要求応答は、前記信用証明書要求応答をキャッシュさせないコマンドを包含する、請求項１に記載の方法。
9. 前記信用証明書要求応答からの前記信用証明書を提供する前記ステップは、ネットワーク・アクセス・ページを分析すること、および前記ネットワーク・アクセス・ページ内のフォーム情報を書き込むことを包含する、請求項１に記載の方法。
10. 前記ネットワーク・デバイスの前記標準プロトコルは、ユーザ・データグラム・プロトコル（ＵＤＰ）である、請求項１に記載の方法。
11. 前記信用証明書要求は、ディジタル・デバイス識別子を包含する、請求項１に記載の方法。
12. ネットワーク信用証明書を獲得するためのシステムであって、
    通信ネットワーク上のネットワーク・デバイスからネットワーク構成情報を受信するべく、かつ前記ネットワーク・デバイスの標準プロトコルを介して信用証明書要求を信用証明書サーバに送信するべく構成されたネットワーク・モジュール、
    前記信用証明書要求を生成するべく構成された信用証明書要求モジュール、
    信用証明書要求応答を受信するべく構成された信用証明書エンジン、および
    前記通信ネットワークにアクセスするために前記ネットワーク・デバイスに、前記信用証明書要求応答からのネットワーク信用証明書の提供をするべく構成されたネットワーク・アクセス・エンジン、
    を包含するシステム。
13. さらに、前記信用証明書要求を暗号化するべく構成された暗号化／復号化モジュールを包含する、請求項１２に記載のシステム。
14. さらに、前記信用証明書要求応答を復号化するべく構成された暗号化／復号化モジュールを包含する、請求項１２に記載のシステム。
15. さらに、前記信用証明書要求をディジタル署名するべく構成された暗号化／復号化モジュールを包含する、請求項１２に記載のシステム。
16. 前記標準プロトコルはＤＮＳである、請求項１２に記載のシステム。
17. 前記信用証明書要求は場所識別子を包含する、請求項１２に記載のシステム。
18. 前記場所識別子は、前記ネットワーク構成情報のうちの少なくともいくつかに基づく、請求項１７に記載のシステム。
19. 前記信用証明書要求応答は、前記信用証明書要求応答をキャッシュさせないコマンドを包含する、請求項１２に記載のシステム。
20. 前記信用証明書要求応答からの前記信用証明書の提供は、ネットワーク・アクセス・ページを分析するべく、かつ前記ネットワーク・アクセス・ページ内のフォーム情報を書き込むべく構成された前記ネットワーク・アクセス・エンジンを包含する、請求項１２に記載のシステム。
21. 前記ネットワーク・デバイスの前記標準プロトコルは、ユーザ・データグラム・プロトコル（ＵＤＰ）である、請求項１２に記載のシステム。
22. 前記信用証明書要求は、ディジタル・デバイス識別子を包含する、請求項１２に記載のシステム。
23. プロセッサにより実行をできるプログラムであって、その実行をされると、ネットワーク信用証明書を獲得する次の方法、すなわち：
    通信ネットワーク上のネットワーク・デバイスからネットワーク構成情報を受信するステップと、
    信用証明書要求を生成するステップと、
    前記信用証明書要求を信用証明書サーバに標準プロトコルを介して送信するステップと、
    信用証明書要求応答を受信するステップと、
    前記信用証明書要求応答からのネットワーク信用証明書を、前記通信ネットワークにアクセスするために前記ネットワーク・デバイスに提供するステップと
    を含む方法
    が実施されるプログラムを記憶したコンピュータ可読媒体。
24. 前記標準プロトコルはＤＮＳである、請求項２３に記載のコンピュータ可読媒体。

Images