JP2010503317A - ネットワーク信用証明書を提供するシステムおよび方法 - Google Patents

Abstract

ネットワーク信用証明書を提供する例示的な方法およびシステムが述べられる。この例示的な方法は、ネットワーク・デバイスを介してディジタル・デバイスから信用証明書要求を受け取ること、その信用証明書要求の中にある少なくとも一部の情報に基づいて、ネットワーク・レコードを識別すること、このネットワーク・レコードに基づいて、複数のネットワーク信用証明書から１つのネットワーク信用証明書を取得すること、および、複数のネットワーク信用証明書から取得されたネットワーク信用証明書含む信用証明書要求応答を、上記ディジタル・デバイスに送ることを含む。

Description

本発明は、一般に、通信ネットワークにアクセスすることに関する。さらに具体的に言えば、本発明は、無線通信ネットワークへの自動アクセスに関する。

ネットワークを使用して情報にアクセスすることの高まりから、様々な活動に対して、ネットワーク通信への依存度がさらに大きくなってきた。このような依存度とともに、ネットワーク・アクセスが至る所に存在するという期待が大きくなってくる。モバイル・ユーザ用のネットワーク・アクセスは、無線テクノロジの向上により、とりわけ高まってきた。様々なセルラ（例えば、ＧＳＭ、ＣＤＭＡなど）、ワイファイ（Ｗｉ−Ｆｉ）（すなわち、ＩＥＥＥ８０２．１１）、ワイマックス（ＷｉＭＡＸ）（すなわち、ＩＥＥＥ８０２．１６）、および他のテクノロジにより、潜在的なネットワーク・ユーザに対して広範囲のアクセス・オプションが可能になってきた。多くの無線アクセス・ポイントすなわち「ホットスポット」は、現地の地理的区域（ときには、特定の勤務先住所または他の住所と同じくらい細かいこともある）とだけアクセス可能である。さらに、効果的に配置されたホットスポットは、種々のグループの人々に対して、公衆または専用ネットワーク・アクセスを実現できる。

ホットスポットの所有者または管理者は、ユーザ・アクセスが可能であるためには、パスワードなどを要求する。その結果、複数のホットスポットのユーザは、ストアしたり、覚えておくなどして、多数のパスワードを管理しなければならないことになる。多くのユーザは、ホットスポットにアクセスするのに用いるラップトップ・コンピュータ上に自分のパスワードをストアできる。しかしながら、ホットスポットにアクセスすることのできるデバイスがすべてラップトップ・コンピュータであるとは限らない。すなわち、携帯電話、携帯情報端末（ＰＤＡ）、および他の多くのデバイスは、今では、無線アクセスに対応している。あいにく、ユーザは容易に、上記デバイスにパスワードを入力したり、あるいは、上記デバイスの中にパスワードをストアすることができない場合が多い。例えば、無線アクセスに対応している一部のデバイスは、キーボードを持たないことがある。デバイスがキーボードを含むときでも、キーボードはしばしば小さく、また、特に指先の器用さが乏しいユーザでは、キーボードの機能が限られることがある。

ユーザがラップトップ・コンピュータ上に自分のパスワードをストアするときには、ユーザは、まず最初にラップトップ・コンピュータにアクセスして、正しいパスワードをラップトップ・コンピュータの中にストアしなければならない。パスワードが変わると、ユーザは、ラップトップ・コンピュータに入っているパスワードを更新しなければならない。さらに、ユーザ名とパスワードをデバイスにストアさせることは、万一、デバイスが紛失したり、盗まれることになれば、セキュリティの問題をもたらす。

さらに、ユーザは、一般に、パスワード、ユーザ名を入力し、かつｗｅｂサイトを渡り歩いて、ネットワーク・アクセスを得なければならない。このようなプロセスは時間がかかり、また、ユーザは、誤った情報を入力して、データを再入力せざるを得なくなることがある。

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

ネットワーク・アクセスに関してネットワーク信用証明書を提供する例示的な方法およびシステムが述べられる。この例示的な方法は、ネットワーク・デバイスを介してディジタル・デバイスから信用証明書要求を受け取ること、その信用証明書要求の中にある少なくとも一部の情報に基づいて、ネットワーク・レコードを識別すること、このネットワーク・レコードに基づいて、複数のネットワーク信用証明書から１つのネットワーク信用証明書を取得すること、および、複数のネットワーク信用証明書から取得されたネットワーク信用証明書含む信用証明書要求応答を、上記ディジタル・デバイスに送ることを含む。

この方法はさらに、信用証明書要求の復号化（平文化）、信用証明書要求の認証、および、信用証明書要求応答の暗号化を含み得る。この方法はさらに、ディジタル・デバイスに基づいて、暗号鍵の取得を含んでも良い。信用証明書要求は、ネットワーク・デバイスの標準プロトコルで受け取られる。この標準プロトコルはＤＮＳである。

信用証明書要求は、場所（ロケーション）識別子を含に得る。この方法はさらに、ディジタル・デバイスから確認アクセス応答を受けることも含み得る。

ネットワーク信用証明書を提供する例示的なシステムは、信用証明書要求モジュールと信用証明書要求応答モジュールを含み得る。信用証明書要求モジュールは、ディジタル・デバイスから信用証明書要求を、ネットワーク・デバイスを介して受けるように構成される。信用証明書要求応答モジュールは、その信用証明書要求中の少なくとも一部の情報に基づいて、ネットワーク・レコードを識別し、そのネットワーク・レコードに基づいて、複数のネットワーク信用証明書から１つのネットワーク信用証明書を取得し、そのネットワーク信用証明書が含まれる信用証明書要求応答を上記ディジタル・デバイスに送るように構成される。

コンピュータ可読媒体にプログラムが記憶されていても良い。そのプログラムは、ネットワーク信用証明書を提供する方法を、プロセッサで実行できる。その方法は、ネットワーク・デバイスを介してディジタル・デバイスから信用証明書要求を受けること、その信用証明書要求の中にある少なくとも一部の情報に基づいて、ネットワーク・レコードを識別すること、このネットワーク・レコードに基づいて、複数のネットワーク信用証明書から１つのネットワーク信用証明書を取得すること、および、複数のネットワーク信用証明書から取得されたネットワーク信用証明書が含まれる信用証明書要求応答を、上記ディジタル・デバイスに送ることを含む。

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

本発明の実施態様は、ネットワーク信用証明書を提供するシステムおよび方法を提供する。例示的な実施態様では、信用証明書サーバは、ホットスポットでのディジタル・デバイスからネットワーク信用証明書の要求を受ける。この要求は、ホットスポットから信用証明書サーバに中継される標準プロトコルとしてフォーマットされ得る。信用証明書サーバは、この要求の中に入っている少なくとも一部の情報に基づいて、ネットワーク・レコードを識別して、このネットワーク・レコードと関連づけられるネットワーク信用証明書を上記ディジタル・デバイスに送る。ディジタル・デバイスは、ネットワーク信用証明書を受け取って、それらのネットワーク信用証明書をネットワーク・デバイスに提供して、ネットワーク・アクセスを得る。

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

様々な実施態様では、ホットスポットは、ネットワーク・デバイス１０４、認証サーバ１０８、ＤＮＳサーバ１１０、アクセス・コントローラ１１２を含み、それらはローカル・エリア・ネットワーク１０６（例えば、『ウォールド・ガーデン』）に結合される。ネットワーク・デバイス１０４は、デジタル・デバイス１０２が、ローカル・エリア・ネットワーク１０６を介して認証サーバ１０８、ＤＮＳサーバ１１０、およびアクセス・コントローラ１１２と通信することを可能にするアクセス・ポイントを包含できる。ディジタル・デバイス１０２は、ラップトップ、携帯電話、カメラ、携帯情報端末（ＰＤＡ）、または他の任意のコンピューティング・デバイスを含み得る。認証サーバ１０８は、ディジタル・デバイス１０２が通信ネットワーク１１４にアクセスする前に、ディジタル・デバイス１０２に対してネットワーク信用証明書を求めるサーバである。ＤＮＳサーバ１１０は、ローカル・エリア・ネットワーク１０６を介して、ＤＮＳサービスを提供する。ＤＮＳサーバ１１０は、通信ネットワーク１１４を横切って、他のＤＮＳサーバ（図示されてない）に要求を中継することができる。アクセス・コントローラ１１２は、ネットワーク・デバイス１０４に動作可能に結合されたデバイスが、通信ネットワーク１１４に結合されたデバイスと通信できるようにするルーターまたはブリッジなどのアクセス・デバイスである。

図１中のホットスポットは、ローカル・エリア・ネットワーク１０６に結合された別々のサーバを示しているが、当業者であれば、ローカル・エリア・ネットワーク１０６に結合されたデバイス（例えば、サーバ、ディジタル・デバイス、アクセス・コントローラ、ネットワーク・デバイス）はいくつあってもよいことが理解されよう。いくつかの実施態様では、ローカル・エリア・ネットワーク１０６は省略可能である。一例では、認証サーバ１０８、ＤＮＳサーバ１１０、アクセス・コントローラ１１２は、ネットワーク・デバイス１０４にじかに結合される。様々な実施態様では、認証サーバ１０８、ＤＮＳサーバ１１０、アクセス・コントローラ１１２は、１つないし複数のサーバ中において又は１つないし複数のディジタル・デバイス中において組み合わされる。さらに、図１は無線アクセスを示しているが、ディジタル・デバイス１０２は、無線または有線（テン・ベース・ティ（１０ｂａｓｅＴ）など）を介してネットワーク・デバイス１０４に結合され得る。

通信ネットワーク１１４にアクセスするためには、認証サーバ１０８は、ホットスポットにアクセスするための１つまたは複数のネットワーク信用証明書を提供するようにディジタル・デバイス１０２に対して求め得る。このネットワーク信用証明書は、例えば、このホットスポットと関連づけられるアカウント用のユーザ名とパスワードを含む。代替実施態様では、ユーザ名およびパスワード以外のネットワーク信用証明書が利用され得る。

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

一例では、ディジタル・デバイス１０２がホットスポットに入るときに、ネットワーク・デバイス１０４は、ＤＮＳクエリが提出されるＩＰアドレスを、例えばＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を介して提供し得る。この信用証明書要求は標準プロトコルとしてフォーマットされる。一例では、信用証明書要求はＤＮＳ要求としてフォーマットされ得る。この信用証明書要求は、ネットワーク・インフラ（例えば、アクセス・コントローラ１１２）によりブロック（阻止）されないように、標準のレコード・タイプを含むテキスト・レコード要求（例えば、ＴＸＴ）である。ネットワーク信用証明書を得るプロセスに関するさらに詳細な説明が、２００７年９月６日に出願された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ａｃｑｕｉｒｉｎｇ Ｎｅｔｗｏｒｋ Ｃｒｅｄｅｎｔｉａｌｓ（ネットワーク信用証明書を得るシステムおよび方法）」と称する同時係属中の米国特許出願第＿＿＿＿号に与えられており、これは、参照によって本明細書中に組み入れられている。

いくつかの実施態様では、信用証明書要求がＤＮＳサーバ１１０で受け取られる。ＤＮＳサーバ１１０は、この信用証明書要求を信用証明書サーバ１１６に転送して、ネットワーク信用証明書を獲得し得る。例示的な実施態様では、信用証明書サーバ１１６は、ルックアップ（探索）を実施して、適正なネットワーク信用証明書（１つまたは複数）を決定し、そのネットワーク信用証明書をＤＮＳサーバ１１０に送り返し得る。ＤＮＳサーバ１１０は、そのネットワーク信用証明書を、要求側のディジタル・デバイス１０２に転送して返す。様々な実施態様では、この適正なネットワーク信用証明書（１つまたは複数）は、信用証明書要求の伝送と同一の経路を介して、信用証明書サーバ１１６からディジタル・デバイス１０２に送られる。

図１中にはただ１つのＤＮＳサーバ１１０が示されているが、信用証明書要求は、それが信用証明書サーバ１１６で受け取られる前に、ＤＮＳサーバを含む（ただし、ＤＮＳサーバには限定されない）任意の数のサーバを介して転送され得る。他の実施態様では、信用証明書要求は、ネットワーク・デバイス１０４から信用証明書サーバ１１６に直接に転送される。

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

ディジタル・デバイス１０２がネットワーク信用証明書応答を受け取ると、ディジタル・デバイス１０２は、認証応答において、ネットワーク信用証明書（ネットワーク信用証明書応答から取得される）を、ネットワーク・デバイス１０４に提出（提示）する。例示的な実施態様では、認証応答は、認証サーバ１０８に転送されて、検証される。いくつかの実施態様では、認証サーバ１０８は、ＡＡＡサーバまたはＲＡＤＩＵＳサーバを含む。ネットワーク・アクセスを得るプロセスに関するさらに詳細な説明が、２００７年９月６日に出願された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｏｂｔａｉｎｉｎｇ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ（ネットワーク・アクセスを得るシステムおよび方法）」と称する同時係属中の米国特許出願第＿＿＿＿号に与えられており、これは、参照によって本明細書中に組み入れられている。

図１は例示的なものであることに留意すべきである。代替実施態様は、さらに多いか、さらに少ないか、あるいは機能的に同等な構成要素を含み得るが、それでも、本実施態様の範囲内にある。例えば、前に説明されたように、様々なサーバ（例えば、ＤＮＳサーバ１１０、信用証明書サーバ１１６、認証サーバ１０８）の機能が組み合わされて、１つまたは２つのサーバとなり得る。すなわち、例えば、認証サーバ１０８とＤＮＳサーバ１１０が同一サーバを含むか、あるいは、認証サーバ１０８、ＤＮＳサーバ１１０、アクセス・コントローラ１１２の機能が組み合わされて、単一のデバイスとされて良い。

図２は、例示的な信用証明書サーバ１１６のブロック図である。信用証明書サーバ１１６は、認証モジュール２００、ネットワーク・モジュール２０２、信用証明書要求モジュール２０４、信用証明書要求応答モジュール２０６、暗号化／復号化モジュール２０８、ネットワーク・レコード記憶装置２１０、暗号鍵記憶装置２１２を含む。モジュールは、個々に、または組み合わせて、ソフトウェア、ハードウェア、ファームウェア、または回路を含む。

認証モジュール２００は、信用証明書要求を認証して、信用証明書要求応答にセキュリティを与えるように構成される。様々な実施態様では、ディジタル・デバイス１０２は、暗号鍵（例えば、共用暗号鍵、または鍵ペアの一部である暗号鍵）を用いて、信用証明書要求を暗号化するか、あるいは信用証明書要求にディジタル署名をし得る。認証モジュール２００は、暗号鍵記憶装置２１２から取得された適正な暗号鍵を用いて信用証明書要求を暗号化することで、信用証明書要求を認証する。一例では、ディジタル・デバイス１０２は、信用証明書要求のハッシュを生成して、このハッシュを、信用証明書要求の暗号化部分の中にストアする。認証モジュール２００は、この信用証明書要求を復号化（平文化）して、信用証明書要求応答のハッシュを生成し、この生成されたハッシュを、信用証明書要求の中に入っているハッシュと比較することで、認証を行う。

他の実施態様では、ディジタル・デバイス１０２は、ナンス（nonce）（すなわち、ランダム値）を生成して、ナンスを、ディジタル署名された信用証明書要求の一部の中にストアできる。認証モジュール２００は、ディジタル署名を復号化して、信用証明書要求を認証し、かつナンスを取得する。様々な実施態様では、信用証明書要求応答モジュール２０６が信用証明書要求応答（以下に述べられる）を生成するときに、認証モジュール２００は、ナンスを、信用証明書要求応答の中に組み込む。次に、認証モジュール２００または暗号化／復号化モジュール２０８は、信用証明書要求応答を暗号化する。ディジタル・デバイス１０２が、この信用証明書要求応答を復号化するときに、ディジタル・デバイス１０２は、この信用証明書要求応答からナンスを取得して、そのナンスを、信用証明書要求の中に送られたナンスと比較することで、さらなる認証を行う。

ネットワーク・モジュール２０２は、通信ネットワーク１１４を介して、信用証明書要求を受け取って、信用証明書要求応答を送るように構成される。

信用証明書要求モジュール２０４は、ネットワーク・モジュール２０２から信用証明書要求を受ける。この信用証明書要求は、標準プロトコルである。一例では、信用証明書要求は、ＵＤＰプロトコル（例えば、ＤＮＳ）である。

例示的な実施態様では、信用証明書要求モジュール２０４は、信用証明書要求からＤＤＩＤおよびＳＳＩＤを取得する。ＤＤＩＤは、ディジタル・デバイス１０２、ディジタル・デバイス１０２のユーザ、および／または、ネットワーク・レコードと関連づけられるユーザを識別（特定）する。ＳＳＩＤは、ホットスポット、またはホットスポットのサービス・プロバイダ（すなわち、運営業者）を識別する。

信用証明書要求モジュール２０４または信用証明書要求応答モジュール２０６は、ＤＤＩＤおよびＳＳＩＤに基づいて、ネットワーク・レコードを識別する。ネットワーク・レコードは、ＤＤＩＤおよびＳＳＩＤと関連づけられる（直接または間接に（例えば、リレーショナル・データベース））レコードである。一例では、ネットワーク・レコードは、ＳＳＩＤと関連づけられるホットスポットにて、ＤＤＩＤと関連づけられるディジタル・デバイス１０２にネットワーク・アクセスを提供するのに必要なネットワーク信用証明書を含む。ネットワーク・レコードは、ネットワーク・レコード記憶装置２１０の中にストアされる。

信用証明書要求応答モジュール２０６は、信用証明書要求応答を生成できる。様々な実施態様では、信用証明書要求応答モジュール２０６は、ＤＤＩＤおよびＳＳＩＤと関連づけられるネットワーク信用証明書をネットワーク・レコードから受け取る。いくつかの実施態様では、このネットワーク信用証明書は、クレジットカード番号を含む。一例では、ディジタル・デバイス１０２は、ネットワーク信用証明書を受け取って、クレジットカード番号を取得し、このクレジットカード番号を認証サーバ１０８に提供する。次に、いくつかの例では、認証サーバ１０８は、このクレジットカード番号と関連づけられるクレジットカードに料金をつけるか、あるいは、この情報を利用して、ネットワーク・アクセスを許す前にユーザの識別子を確認する。

さらに、様々な実施態様では、上記ネットワーク信用証明書は、ログイン・プロシージャ情報を含む。一例では、これらのネットワーク信用証明書は、ディジタル・デバイス１０２により認証サーバ１０８から取得されたフォーム（例えば、認証フォーム）の中に与えられることになっているユーザ名とパスワードを含む。いくつかの実施態様では、ログイン・プロシージャ情報は、このフォーム中の識別フィールドにネットワーク信用証明書を入れてから、この完成したフォームを認証サーバ１０８に提出するよう、ディジタル・デバイス１０２に指示する。当業者であれば、認証サーバ１０８に信用証明書を提供する方法は多数あることが理解されよう。認証サーバに信用証明書を提供するプロセスはさらに、２００７年９月６日に出願された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｏｂｔａｉｎｉｎｇ Ｎｅｔｗｏｒｋ Ｃｒｅｄｅｎｔｉａｌｓ（ネットワーク信用証明書を得るシステムおよび方法）」と称する同時係属中の米国特許出願第＿＿＿＿号に説明されている。

信用証明書要求応答モジュール２０６または暗号化／復号化モジュール２０８は、ＤＤＩＤまたは信用証明書要求と関連づけられる暗号鍵を用いて、信用証明書要求応答を暗号化する。一例では、信用証明書サーバ１１６は、１つまたは複数の共用暗号鍵をストアしている。それぞれの共用暗号鍵は、少なくとも１つのディジタル・デバイス１０２により共用される。信用証明書要求応答モジュール２０６は、ディジタル・デバイス１０２と関連づけられる共用暗号鍵を用いて、信用証明書要求応答を暗号化する（例えば、この共用暗号鍵は、ＤＤＩＤと関連づけられる）。信用証明書要求応答モジュール２０６または暗号化／復号化モジュール２０８はまた、鍵ペアの一部である暗号鍵を用いて、信用証明書要求を暗号化することもある。暗号化／復号化モジュール２０８が信用証明書要求を暗号化する方法は多数ある。

暗号化／復号化モジュール２０８は、信用証明書要求を復号化し、また、信用証明書要求応答を暗号化する。前に説明されたように、暗号化／復号化モジュール２０８は、信用証明書要求へのディジタル署名を復号化する。一例では、暗号化／復号化モジュール２０８は、信用証明書要求の中に入っているＤＤＩＤと関連づけられる暗号鍵に基づいて、ディジタル署名を復号化する。暗号化／復号化モジュール２０８はまた、信用証明書要求応答を暗号化することもある。一例では、暗号化／復号化モジュール２０８は、ＤＤＩＤと関連づけられる暗号鍵（例えば、共用暗号鍵、または鍵ペアの一部である暗号鍵）に基づいて、信用証明書要求応答を暗号化する。

様々な実施態様では、暗号化／復号化モジュール２０８は、ネットワーク・レコード記憶装置２１０の中に入っているネットワーク・レコードを暗号化して、暗号鍵記憶装置２１２を管理できる。暗号化／復号化モジュール２０８はまた、ネットワーク信用証明書をストアしながら、ディジタル・デバイスとのセキュアな通信（例えば、ＳＳＬやＨＴＴＰＳを介して）を確立することもある。このようなプロセスはさらに図７に述べられる。いくつかの実施態様により、暗号化／復号化モジュール２０８は、省略可能なこともある。

ネットワーク・レコード記憶装置２１０と暗号鍵記憶装置２１２はそれぞれ、ネットワーク・レコードと暗号鍵をストアする。ネットワーク・レコード記憶装置２１０と暗号鍵記憶装置２１２は、１つまたは複数のデータベースを含む。一例では、ネットワーク・レコード記憶装置２１０は、ネットワーク・レコードをストアする。ネットワーク・レコードは、ＤＤＩＤ、ＳＳＩＤ、ネットワーク信用証明書を含む。ネットワーク・レコードはまた、ユーザがネットワーク・レコードにアクセスするか、ネットワーク・レコードを変更、更新するか、あるいは、ネットワーク・レコードを信用証明書サーバ１１６の中にストアするために、ユーザ名とパスワードを含む。

様々な実施態様では、ネットワーク・レコードにより、複数のディジタル・デバイス１０２が同一のネットワーク信用証明書を使用できることもある。一例では、ユーザは、複数のディジタル・デバイス１０２を所有する。それぞれが異なるディジタル・デバイス１０２と関連づけられる複数のＤＤＩＤは、同一のネットワーク・レコードに含まれる。いくつかの実施態様では、複数のデバイスが、１つまたは複数のネットワーク・レコードと関連づけられる場合があり、また、このような１つまたは複数のネットワーク・レコードが一人のユーザと関連づけられる。その結果、このユーザは、ディジタル・デバイス１０２をいくつでも使用して、ホットスポットに対してネットワーク信用証明書を取得する。当業者であれば、ネットワーク・レコード、および／または、ネットワーク・レコードに入っている情報をストアし、編成する（例えば、異なるデータ構造、データベース、レコード、編成方式、および／または、技法にて）ことのできる方法が多数あることが理解されよう。

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

ステップ３０４において、ディジタル・デバイス１０２により信用証明書要求が生成される。次に、ステップ３０６において、前にネットワーク・デバイス１０４から受け取ったＩＰアドレスの１つを用いて、上記信用証明書要求をＤＮＳサーバ１１０に送る。

ステップ３０８において、信用証明書要求に基づいて、ＤＮＳサーバ１１０により信用証明書サーバ１１６が識別される。他の実施態様では、ＤＮＳサーバ１１０は、信用証明書要求を信用証明書サーバ１１６に転送する。ＤＮＳサーバ１１０が、ＤＮＳ要求をローカルで解決できないときには、信用証明書要求が通信ネットワーク１１４上の別のＤＮＳサーバに転送される（例えば、ポート５３を介して）。次に、その別のＤＮＳサーバは、信用証明書要求を信用証明書サーバ１１６に転送する。ステップ３１０において、この信用証明書要求は、通信ネットワーク１１４上の１つまたは複数の他のＤＮＳサーバを通じて、直接に、または間接に信用証明書サーバ１１６に転送される。

ステップ３１２において、信用証明書サーバ１１６は、信用証明書要求に基づいて、必要とされるネットワーク信用証明書を識別する。例えば、この信用証明書要求は、ホットスポットＳＳＩＤ用の識別子（例えば、運営業者などのサービス・プロバイダ）だけでなく、ディジタル・デバイス１０２用の識別子（すなわち、ＤＤＩＤ）も含む。これらの識別子は、信用証明書要求モジュール２０４または信用証明書要求応答モジュール２０６により、このような識別子のテーブル（例えば、ネットワーク・レコード）と比較されて、適正なネットワーク信用証明書を決定する。次に、ステップ３１４において、信用証明書要求応答モジュール２０６により信用証明書要求応答が生成され、ステップ３１６において、その信用証明書要求応答がＤＮＳサーバ１１０に中継で返される。ステップ３１８において、ＤＮＳサーバ１１０は、信用証明書要求応答をディジタル・デバイスに転送して返す。

次に、ステップ３２０において、ディジタル・デバイス１０２は、信用証明書要求応答からネットワーク信用証明書を取得する。次に、ステップ３２２において、ネットワーク・デバイス１０４にネットワーク信用証明書を提供する。ステップ３２４において、ネットワーク信用証明書を検証した上で、ネットワーク・デバイス１０４は、ディジタル・デバイス１０２にネットワーク・アクセスを提供する。

次に、図４を参照すると、例示的な信用証明書要求４００がさらに詳しく示されている。例示的な実施態様により、信用証明書要求モジュール２０４は、信用証明書要求４００を生成する。一実施態様では、信用証明書要求４００は、場所識別子４０２、シーケンス識別子４０４，署名４０６、ＤＤＩＤ４０８，ＳＳＩＤ（ｓｅｒｖｉｃｅ ｓｅｔ ｉｄｅｎｔｉｆｉｅｒ）４１０、バージョン識別子４１２を含む構造を持っているＤＮＳ文字列であることもある。

オプションの場所識別子４０２は、ディジタル・デバイス１０２、ネットワーク・デバイス１０４、認証サーバ１０８、またはアクセス・コントローラ１１２の物理的または地理的な位置を示す。様々な実施態様では、場所識別子４０２は、ホットスポットの使用度、ディジタル・デバイス１０２だけでなくディジタル・デバイス１０２のユーザも追跡するために、信用証明書サーバ１１６で使用され得る。

シーケンス識別子４０４は、ログインがうまくいったかどうか判定するために、信用証明書サーバ１１６への次の要求に対応するのに用いられる任意の数または任意の組の数を含む。すなわち、シーケンス識別子４０４は、ログインのプロセスの検証を信用証明書サーバ１１６に行わせる相関機構を提供する。

例示的な実施態様では、署名４０６は、なりすましを防止するのに利用される暗号署名（すなわち、ディジタル署名）を含む。ディジタル・デバイス１０２からの要求への署名４０６は、信用証明書サーバ１１６により検証される。署名４０６が有効でない場合には、この要求は、信用証明書サーバ１１６により拒否される。

ＤＤＩＤ４０８は、ディジタル・デバイス１０２の識別子を含む。例えば、ＤＤＩＤ４０８は、ＭＡＣアドレス、あるいは、ディジタル・デバイス１０２の他の任意の識別子を含む。

ＳＳＩＤ４１０は、ネットワーク・アクセス・ポイントまたはワイファイ（Ｗｉ−Ｆｉ）サービス・プロバイダの識別子を含む。例えば、ＳＳＩＤ４１０は、ワイファイ（Ｗｉ−Ｆｉ）サービス・プロバイダの名前、あるいは、ネットワーク・デバイス１０４を運営する現場（venue）の名前を含むことがある。

バージョン識別子４１２は、信用証明書要求４００のプロトコルまたはフォーマットを識別できる。例えば、ディジタル・デバイス１０２は、信用証明書要求４００を生成して、そのデータをいくつかの異なるフォーマットで編成する。異なるフォーマットはそれぞれ、異なるバージョン識別子と関連づけられる。いくつかの実施態様では、信用証明書要求応答モジュール２０６の構成要素は、更新されるか、再構成されるか、あるいは、徐々に変更されることがあり、このことは、信用証明書要求４００の構造に影響を及ぼす。その結果、信用証明書サーバ１１６は、様々にフォーマットされている複数の信用証明書要求４００を受け取る。信用証明書サーバ１１６は、それぞれのバージョン識別子に基づいて、それぞれの信用証明書要求からの所要の情報にアクセスする。

図５は、例示的な信用証明書要求応答のブロック図である。例示的な実施態様により、信用証明書要求応答モジュール２０６は、信用証明書要求応答５００を生成できる。一実施態様では、信用証明書要求応答５００は、暗号化テキスト５０２を含む。暗号化テキスト５０２は、オプションのナンス５０４と信用証明書情報５０６を含む。信用証明書情報５０６は、鍵／値ペア（５０８〜５１０）を含む。

前に説明されたように、信用証明書要求応答は、暗号化テキスト５０２を含むＤＮＳ応答としてフォーマットされ得る。暗号化テキスト５０２は、ネットワーク信用証明書（例えば、ユーザ名、パスワード、ログイン・プロシージャ情報）を含む。信用証明書要求応答５００は、暗号化テキスト５０２を含むものとして示されているが、信用証明書要求応答５００の中にあるテキストは、暗号化する必要はない。

暗号化テキスト５０２はナンスを含むことがある。ナンスは、前に説明されたように、信用証明書要求から取得される。信用証明書要求応答５００がディジタル・デバイス１０２で受け取られると、ディジタル・デバイス１０２は、信用証明書要求応答５００の中にあるナンスを、信用証明書要求の中で送られたナンスと比較して、認証を行う。図５では、ナンスは信用証明書要求応答５００の中にあるものとして示されているが、ナンスは任意である。

信用証明書情報５０６は、ユーザ名、パスワード、ログイン・プロシージャ情報、または、これらを組み合わせたものを含む。信用証明書情報５０６は、鍵／値ペア（５０８〜５１０）を含む。信用証明書情報５０６の中には、鍵／値ペアがいくつあってもよい。鍵／値ペアは、ディジタル・デバイス１０２で受け取られて、変換される信用証明書情報を表す。信用証明書情報５０６は、例示目的でのみ、鍵／値ペアとして示されている。信用証明書情報５０６は、必ずしも鍵／値ペアには限定されない任意フォーマットの範囲内にあることもある。

図６は、ネットワーク信用証明書を提供する例示的な方法のフローチャートである。ステップ６０２において、信用証明書サーバ１１６は、ディジタル・デバイス１０２から信用証明書要求を受け取る。

様々な実施態様では、信用証明書サーバ１１６は、暗号鍵を用いてディジタル署名を暗号化し、認証する。次に、ステップ６０４において、信用証明書サーバ１１６は、ネットワーク・レコードの中に入っているＤＤＩＤおよびＳＳＩＤに基づいて、このネットワーク・レコードを識別する。一例では、信用証明書要求応答モジュール２０６は、信用証明書要求の中にあるＤＤＩＤと関連づけられる１つまたは複数のネットワーク・レコードを取得する。次に、信用証明書要求応答モジュール２０６は、取得されたネットワーク・レコード（１つまたは複数）の中にあるＳＳＩＤと関連づけられる少なくとも１つのネットワーク信用証明書を識別する。

ステップ６０６において、信用証明書要求応答モジュール２０６は、識別されたネットワーク信用証明書（１つまたは複数）を、上記選択されたネットワーク・レコードから取得する。一例では、信用証明書要求応答モジュール２０６は、ディジタル・デバイス１０２のユーザがネットワーク・アクセスを得るために認証サーバ１０８に提供しなければならないユーザ名とパスワードを識別する。ステップ６０８において、信用証明書要求応答モジュール２０６は、ディジタル・デバイス１０２に対して、ネットワーク信用証明書（例えば、ユーザ名、パスワード）を含む信用証明書要求応答を生成する。

いくつかの実施態様では、信用証明書要求応答モジュール２０６は、ネットワーク信用証明書の一部として、ログイン・プロシージャ情報を識別する。信用証明書要求応答モジュール２０６は、ネットワーク・レコード（例えば、ＳＳＩＤと関連づけられるパスワードを含む同一ネットワーク・レコード）から、上記ログイン・プロシージャ情報を取得する。このログイン・プロシージャ情報は、ネットワーク・アクセスを得るためにディジタル・デバイス１０２が従うフォーム識別子と指示（例えば、パラメータ）を含む。一例では、ディジタル・デバイス１０２は、信用証明書要求応答の中にあるネットワーク信用証明書から、フォーム識別子と指示を取得する。ディジタル・デバイス１０２は、これらのフォーム識別子と指示に基づいて、認証サーバ１０８と入力データから受け取られたフォームを識別する。別の例では、ディジタル・デバイス１０２は、信用証明書要求応答の中に含まれるログイン・プロシージャ情報に基づいて、ネットワーク・アクセスを得るために、認証サーバ１０８に情報を提供する。認証サーバ１０８に情報を提供するプロセスはさらに、２００７年９月６日に出願された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｏｂｔａｉｎｉｎｇ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ（ネットワーク・アクセスを得るシステムおよび方法）」と称する米国特許出願第＿＿＿＿号に記載されている。

図７は、ネットワーク信用証明書を提供する例示的な方法の別のフローチャートである。ディジタル・デバイス１０２は、ネットワーク・デバイス１０４を介して、利用可能な無線ネットワークを探索し、見つけ出す。ステップ７０２において、ディジタル・デバイス１０２は、ホットスポットに接続している間に、ネットワーク構成情報を受け取る。ネットワーク構成情報は、ネットワーク・デバイス１０４またはＤＮＳサーバ１１０用の識別子を含む。一例では、ディジタル・デバイス１０２は、接続プロセス中に、ＤＮＳサーバＩＰアドレス（例えば、ＤＮＳサーバ１１０用のもの）を受ける。

ステップ７０４において、ディジタル・デバイス１０２は、信用証明書要求を生成する。この信用証明書要求は、シーケンス識別子、ＤＤＩＤ、ＳＳＩＤを含む。ステップ７０６において、ディジタル・デバイス１０２は、随意にナンスを生成し、暗号鍵を用いて信用証明書要求にディジタル署名する。ステップ７０８において、ディジタル・デバイス１０２は、標準プロトコルとして、信用証明書要求を送る。ネットワーク・デバイス１０４は、信用証明書要求を受け取って、この信用証明書要求を通信ネットワーク１１４に転送する。様々な実施態様では、ネットワーク・デバイス１０４は、信用証明書要求をＤＮＳサーバ１１０に提供することがあり、また、ＤＮＳサーバ１１０は、この信用証明書要求を信用証明書サーバ１１６に転送する。

例示的な実施態様では、信用証明書サーバ１１６の信用証明書要求モジュール２０４は信用証明書要求を受ける。信用証明書要求モジュール２０４は、信用証明書サーバ１１６の中にあるＤＤＩＤと関連づけられる暗号鍵を、暗号鍵記憶装置２１２から取得する。次に、信用証明書要求モジュール２０４は、信用証明書要求へのディジタル署名を復号化して、認証を行う。さらに、信用証明書要求モジュール２０４は、その信用証明書要求から、ナンスとシーケンス識別子を取得する。

次に、信用証明書サーバ１１６の信用証明書要求応答モジュール２０６は、ＤＤＩＤおよびＳＳＩＤと関連づけられるネットワーク・レコードを、ネットワーク・レコード記憶装置２１０から取得できる。信用証明書要求応答モジュール２０６は、このネットワーク・レコードからネットワーク信用証明書を取得して、信用証明書要求応答を生成する。この信用証明書要求応答は、ネットワーク信用証明書とナンスを含む。暗号化／復号化モジュール２０８は、暗号鍵記憶装置２１２から取得されたＤＤＩＤと関連づけられる暗号鍵を用いて、その信用証明書要求応答を暗号化する。いくつかの実施態様では、この信用証明書要求応答は、標準プロトコル（例えば、ＤＮＳ）としてフォーマットされる。

ステップ７１０において、ディジタル・デバイス１０２は、信用証明書要求応答を受け取る。次に、ステップ７１２において、ディジタル・デバイス１０２は、この信用証明書要求応答を認証する。一例では、ディジタル・デバイス１０２は、信用証明書要求にディジタル署名するのに使用されるものと同一の鍵を用いて、信用証明書要求応答を復号化する。ディジタル・デバイス１０２はさらに、信用証明書要求応答の中にあるナンスを取得して、そのナンスを、信用証明書要求の中で送られたナンスと比較して、さらなる認証を行う。ステップ７１４において、この信用証明書要求応答が本物であると判明した場合には、ディジタル・デバイス１０２は、信用証明書要求応答からネットワーク信用証明書を取得する。

ステップ７１６において、ディジタル・デバイス１０２は、ネットワーク・アクセスと関連づけられる認証要件を識別する。様々な実施態様では、ディジタル・デバイス１０２は、認証サーバ１０８に提供するのに適正な情報およびネットワーク信用証明書を決定する。一例では、ディジタル・デバイス１０２は、認証サーバ１０８から、１つまたは複数のネットワーク・アクセス・ページを取得する。ディジタル・デバイス１０２は、認証サーバ１０８からの適正なネットワーク・アクセス・ページにアクセスして、自動的に選択を行う。一例では、ディジタル・デバイス１０２は、その「選択」を自動的に行うようにできる（例えば、ネットワーク・アクセス・ページ内のボタンの起動、セレクト・ボックスのチェック、ラジオ・ボタンの選択）。

例えば、信用証明書要求応答モジュール２０６は、ネットワーク・アクセス・ページ内での自動選択のために、ディジタル・デバイス１０２に指示を与える。ここに説明されるように、ネットワーク・アクセス・ページは、認証サーバ１０８から取得された１つまたは複数のｗｅｂページ、１つまたは複数のタグ、あるいは、双方を組み合わせたものを含む。一例では、ディジタル・デバイス１０２に入っているソフトウェアは、ネットワーク・アクセス・ページ内のすべてのセレクト・ボックスを自動的にチェックする。次に、ディジタル・デバイス１０２は、ログイン・プロシージャ情報に基づいて、セレクト・ボックスのチェックを外す。当業者であれば、セレクトを自動的に行わせる方法が多数あるかもしれないことが理解されよう。他の実施態様では、ディジタル・デバイス１０２は、認証サーバ１０８からＸＭＬタグを受け取る。ディジタル・デバイス１０２は、ログイン・プロシージャ情報の中にあるＸＭＬタグおよび指示に基づく情報を認証サーバ１０８に提供して、ネットワーク・アクセスを得る。

ステップ７１８において、ディジタル・デバイス１０２は、ネットワーク信用証明書をネットワーク・デバイス１０４に提供して、通信ネットワーク１１４へのネットワーク・アクセスを得る。一例では、信用証明書要求応答モジュール２０６は、認証サーバ１０８から１つまたは複数のフォームを取得して、そのようなフォームに１つまたは複数のネットワーク信用証明書を入れ、これらの完成したフォームを認証サーバ１０８に提供する。別の例では、信用証明書要求応答モジュール２０６は、必要に応じて、ネットワーク信用証明書を認証サーバ１０８に提供する。ネットワーク信用証明書が認証サーバ１０８で受け取られると、認証サーバ１０８は、ディジタル・デバイス１０２と通信ネットワーク１１４との間で通信できるようにできる。一例では、認証サーバ１０８は、ディジタル・デバイス１０２が通信ネットワーク１１４にアクセスできるように、アクセス・コントローラ１１２に命じる。

次に、ディジタル・デバイス１０２は、ネットワークのコネクティビティ（接続性）をテストして、ネットワーク・アクセスを確かめ得る。一例では、ディジタル・デバイス１０２は、通信ネットワーク１１４が利用できるかどうか判定するために、信用証明書サーバ１１６に要求を送る。いくつかの実施態様では、そのクエリまたはコマンドは、前に信用証明書要求の中に提出されたシーケンス識別子を含む。ネットワーク・アクセスがうまくいった場合には、信用証明書サーバ１１６は、上記要求を受け取って、シーケンス識別子を取得することがある。次に、信用証明書サーバ１１６は、ネットワーク・アクセスがうまくいったことを確かめる。

図８は、ネットワーク信用証明書を受け取って、ストアする例示的な方法のフローチャートである。様々な実施態様では、ユーザは、ネットワーク・レコードを生成して、ネットワーク・レコードを信用証明書サーバ１１６の中にストアできる。例えば、信用証明書サーバ１１６は、ユーザがネットワーク・レコードを生成でき、ストアでき、更新でき、除去でき、変更できるようにするグラフィカル・ユーザ・インターフェース（ＧＵＩ）を提供する信用証明書記憶モジュール（図示されてない）を含む。

ステップ８０２において、信用証明書サーバ１１６は、ユーザにネットワーク信用証明書要求フォームを提供する。一例では、信用証明書サーバ１１６は、インターネットを介して、１つまたは複数のｗｅｂページとして、ネットワーク信用証明書要求フォームをユーザに提供する。このネットワーク信用証明書要求フォームは、サービス・プロバイダの名前（例えば、運営業者の名前）および／またはＳＳＩＤと、ネットワーク信用証明書を受け取るように構成されている。

サービス・プロバイダの名前は、ホットスポット、ホットスポットに関係した１つまたは複数の構成要素（例えば、ネットワーク・デバイス１０４）、あるいは、ローカル・エリア・ネットワーク１０６のインフラを運営するエンティティ（実体）の名前を含む。いくつかの実施態様では、サービス・プロバイダの名前は、別のサービス・プロバイダ用の１つまたは複数のホットスポットを管理する組織体の名前を含む。一例では、ホットスポットが異なるサービス・プロバイダを持っていても、コーヒーショップや本屋は双方とも、第三者の管理者（third-party manager）を利用して、これらのホットスポットを管理できる。いくつかの実施態様では、ネットワーク信用証明書要求フォームは、この第三者の管理者の名前を受け取るように構成される。いくつかの実施態様では、サービス・プロバイダの名前は、ホットスポット・ネットワークへのアクセスを再販する組織体（例えば、アグリゲータ）の名前を含む。

ネットワーク信用証明書要求フォームはまた、ネットワーク・サービス選択として、ＳＳＩＤも受け取り得る。一例では、ネットワーク信用証明書要求フォームは、ユーザが選択できる異なるサービス・プロバイダおよび／またはホットスポットのプルダウン・メニューを含む。例えば、ユーザは、ホットスポットとして、「スターバックス」、または「サンフランシスコ国際空港」を選択できる。ユーザには、このホットスポットの地理的位置などにさらなるオプションが与えられる。ユーザはまた、サービス・プロバイダも選択する。例えば、ユーザは、サービス・プロバイダとして、「Ｔ−Ｍｏｂｉｌｅ」を選択する。次に、ネットワーク信用証明書要求フォームは、Ｔ−Ｍｏｂｉｌｅと関連づけられる１つまたは複数の様々なホットスポットの中からユーザが選択できるようにする。次に、このような「選択」（１つまたは複数）は、ネットワーク・レコードとしてストアされる。別法として、このような「選択」（１つまたは複数）と関連づけられるネットワーク・サービス識別子は、ＳＳＩＤとして生成される。

さらに、ネットワーク信用証明書要求フォームは、ユーザからネットワーク信用証明書を受け取る。例えば、ユーザは、ネットワーク信用証明書要求フォームの中にあるネットワーク信用証明書として、ユーザ名、パスワード、パスコードを入力する。いくつかの実施態様では、ネットワーク信用証明書要求フォームがＳＳＩＤを受け取った後で、ネットワーク信用証明書要求フォームは、求められるタイプのネットワーク信用証明書を決定する。例えば、ネットワーク信用証明書要求フォームは、前にユーザにより選択された「サンフランシスコ国際空港」のホットスポットにてネットワークにアクセスするのに必要な情報を識別する。次に、ネットワーク信用証明書要求フォームは、このホットスポットにてネットワーク・アクセスを得るのに必要な情報（例えば、ユーザ名、パスワード）だけをユーザが入力できるようにするために、フィールドまたは選択を生成する。

信用証明書サーバ１１６はまた、ネットワーク信用証明書要求フォームを受け取る前に登録するよう、ユーザに求めることもある。登録中、ユーザは、サービス条件に同意して、カスタマー情報を入力しなければならない。カスタマー情報は、信用証明書サーバ１１６にアクセスして、ネットワーク信用証明書をストアするために、ユーザ名とパスワードを含む。オプションとして、カスタマー情報は、ユーザのアドレス、連絡先情報、および、信用証明書サーバ１１６が提供するサービスをユーザが利用するための支払いオプションを含む。

ステップ８０４において、信用証明書サーバ１１６は、ネットワーク信用証明書要求フォームを介して、カスタマー情報およびネットワーク・サービス選択を受け取る。ステップ８０６において、信用証明書サーバ１１６は、ネットワーク信用証明書を取得する。ステップ８０８において、信用証明書サーバ１１６は、カスタマー情報を受け取る。ステップ８１０において、信用証明書サーバ１１６は、上記ネットワーク信用証明書を、カスタマー情報、ネットワーク・サービス選択、ネットワーク信用証明書（１つまたは複数）と関連づけて、ネットワーク・レコードを生成する。次に、ステップ８１２において、このネットワーク・レコードをストアする。

いくつかの実施態様では、ユーザは、インターネットを介して、手動で信用証明書サーバ１１６にアクセスする。他の実施態様では、ユーザは、ネットワーク信用証明書ソフトウェアをダウンロードして、そのソフトウェアをディジタル・デバイス１０２にインストールする。ネットワーク信用証明書ソフトウェアは、ディジタル・デバイス１０２のＤＤＩＤを識別して、そのＤＤＩＤを信用証明書サーバ１１６に送る。他の実施態様では、ネットワーク信用証明書ソフトウェアは、ディジタル・デバイス１０２にプリインストールされる。ディジタル・デバイス１０２が最初に、ネットワーク信用証明書ソフトウェアを起動するときには、ネットワーク信用証明書ソフトウェアは、ディジタル・デバイス１０２のＤＤＩＤを識別して、そのＤＤＩＤを信用証明書サーバ１１６に送る。

ユーザは、ＳＳＩＤをネットワーク信用証明書ソフトウェアに入力できる（例えば、サービス・プロバイダまたはホットスポットを識別する）。ユーザはまた、ネットワーク信用証明書もネットワーク信用証明書ソフトウェアの中に入力できる。ネットワーク信用証明書ソフトウェアがＤＤＩＤ、ＳＳＩＤ、ネットワーク信用証明書を得た後で、ネットワーク信用証明書ソフトウェアは、その情報を信用証明書サーバ１１６にアップロードし、また、信用証明書サーバ１１６は、その情報をネットワーク・レコードの中にストアする。様々な実施態様では、ネットワーク信用証明書ソフトウェアは、信用証明書サーバ１１６からダウンロードされ得る。

図９は、例示的なディジタル・デバイスのブロック図である。信用証明書サーバ１１６は、プロセッサ９００、メモリ・システム９０２、ストレージ・システム９０４、Ｉ／Ｏインターフェース９０６、通信ネットワーク・インターフェース９０８、ディスプレイ・インターフェース９１０を含む。プロセッサ９００は、実行命令（例えば、プログラム）を実行するように構成されている。いくつかの実施態様では、プロセッサ９００は、実行命令を処理できる回路または任意のプロセッサを含む。

メモリ・システム９０２は、データをストアするように構成された任意のメモリである。メモリ・システム９０２のいくつかの例として、ＲＡＭまたはＲＯＭなどの記憶素子がある。メモリ・システム９０２は、ＲＡＭキャッシュを含むこともある。様々な実施態様では、データは、メモリ・システム９０２の中にストアされる。メモリ・システム９０２の中にあるデータは、クリア（消去）されるか、あるいは、最終的にストレージ・システム９０４に移され得る。

ストレージ・システム９０４は、データを取得して、ストアするように構成された任意のストレージ（記憶装置）である。ストレージ・システム９０４のいくつかの例として、フラッシュ・ドライブ、ハード・ドライブ、光ドライブ、および／または磁気テープがある。いくつかの実施態様では、信用証明書サーバ１１６は、ＲＡＭの形式を取るメモリ・システム９０２と、フラッシュ・データの形式を取るストレージ・システム９０４とを含む。メモリ・システム９０２とストレージ・システム９０４は両方とも、プロセッサ９００を含むコンピュータ・プロセッサにより実行できる命令またはプログラムをストアできるコンピュータ可読媒体を含む。

オプションの入出力（Ｉ／Ｏ）インターフェース９０６は、ユーザから入力を受け取って、データを出力する任意のデバイスである。オプションのディスプレイ・インターフェース９１０は、グラフィックスおよびデータをディスプレイに出力するように構成された任意のデバイスである。一例では、ディスプレイ・インターフェース９１０は、グラフィックス・アダプタである。すべてのディジタル・デバイス１０２が、Ｉ／Ｏインターフェース９０６か、ディスプレイ・インターフェース９１０のいずれかを含むとは限らないことが理解されよう。

通信ネットワーク・インターフェース（ｃｏｍ．ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ）９０８は、リンク９１２を介して、ネットワーク（例えば、ローカル・エリア・ネットワーク１０６や通信ネットワーク１１４）に結合されることもある。通信ネットワーク・インターフェース９０８は、例えばＥｔｈｅｒｎｅｔ接続、シリアル接続、パラレル接続、またはＡＴＡ接続を介して、通信をサポートする。通信ネットワーク・インターフェース９０８はまた、無線通信（例えば、８０２．１１ ａ／ｂ／ｇ／ｎ、ワイマックス（ＷｉＭＡＸ））もサポートする。通信ネットワーク・インターフェース９０８が、多数の有線標準や無線標準をサポートできることが、当業者には明らかになろう。

上述の機能および構成要素は、ストレージ媒体にストアされている命令から成ることもある。これらの命令は、プロセッサにより取得されて、実行される。命令のいくつかの例として、ソフトウェア、プログラム・コード、ファームウェアがある。ストレージ媒体のいくつかの例として、メモリ素子、テープ、ディスク、集積回路、サーバがある。これらの命令は、プロセッサにより実行されるときに機能を果たして、このプロセッサに本発明の実施態様に合わせて動作するよう指示する。当業者は、命令、プロセッサ（１つまたは複数）、ストレージ媒体に精通している。

本発明は、例示的な実施態様を参照して、上で説明されてきた。本発明のさらに広い範囲から逸脱しなければ、様々な変更を行うことができ、また、他の実施態様を利用できることが当業者には明らかになろう。それゆえ、例示的な実施態様における上記および他の変形例は、本発明の適用範囲に入ることになっている。

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

Claims (23)

1. ネットワーク信用証明書を提供する方法であって、
   ネットワーク・デバイスを介してディジタル・デバイスから信用証明書要求を受け取るステップと、
   前記信用証明書要求の中にある少なくとも一部の情報に基づいて、ネットワーク・レコードを識別するステップと、
   前記ネットワーク・レコードに基づいて、複数のネットワーク信用証明書から１つのネットワーク信用証明書を取得するステップと、
   前記複数のネットワーク信用証明書から取得されたネットワーク信用証明書含む信用証明書要求応答を、前記ディジタル・デバイスに送るステップと、
   を含む方法。
2. 前記信用証明書要求を復号化するステップをさらに含む請求項１に記載の方法。
3. 前記信用証明書要求を認証するステップをさらに含む請求項１に記載の方法。
4. 前記信用証明書要求応答を暗号化するステップをさらに含む請求項１に記載の方法。
5. 前記ディジタル・デバイスに基づいて、暗号鍵を取得するステップをさらに含む請求項４に記載の方法。
6. 前記信用証明書要求が、前記ネットワーク・デバイスの標準プロトコルを使って受け取られる請求項１に記載の方法。
7. 前記標準プロトコルがＤＮＳである請求項６に記載の方法。
8. 前記信用証明書要求を受け取るステップが、前記ネットワーク・デバイスのポート５３を介して前記信用証明書要求を受け取るステップを含む請求項１に記載の方法。
9. 前記信用証明書要求が場所識別子を含む請求項１に記載の方法。
10. 前記ディジタル・デバイスから確認アクセス応答を受け取るステップをさらに含む請求項１に記載の方法。
11. ネットワーク信用証明書を提供するシステムであって、
    ネットワーク・デバイスを介してディジタル・デバイスから信用証明書要求を受け取るように構成された信用証明書要求モジュールと、
    前記信用証明書要求の中にある少なくとも一部の情報に基づいて、ネットワーク・レコードを識別し、前記ネットワーク・レコードに基づいて、複数のネットワーク信用証明書から１つのネットワーク信用証明書を取得し、前記ネットワーク信用証明書含む信用証明書要求応答を前記ディジタル・デバイスに送るように構成された信用証明書要求応答モジュールと、
    を備えるシステム。
12. 前記信用証明書要求を復号化するように構成された暗号化／復号化モジュールをさらに備える請求項１１に記載のシステム。
13. 前記信用証明書要求を認証するように構成された認証モジュールをさらに備える請求項１１に記載のシステム。
14. 前記信用証明書要求応答を暗号化するように構成された暗号化／復号化モジュールをさらに備える請求項１１に記載のシステム。
15. 前記プロセッサが、前記ディジタル・デバイスに基づいて、暗号鍵記憶装置から暗号鍵を取得する請求項１４に記載のシステム。
16. 前記信用証明書要求が、前記ネットワーク・デバイスの標準プロトコルを使って受け取られる請求項１１に記載のシステム。
17. 前記標準プロトコルがＤＮＳである請求項１６に記載のシステム。
18. 前記信用証明書要求を受け取るように構成された信用証明書要求モジュールが、前記ネットワーク・デバイスのポート５３を介して前記信用証明書要求を受け取るように構成された信用証明書要求モジュールを含む請求項１６に記載のシステム。
19. 前記信用証明書要求が場所識別子を含む請求項１１に記載のシステム。
20. プロセッサにより実行をできるプログラムであって、その実行をされると、ネットワーク信用証明書を提供する次の方法、すなわち：
    ネットワーク・デバイスを介してディジタル・デバイスから信用証明書要求を受け取るステップと、
    前記信用証明書要求の中にある少なくとも一部の情報に基づいて、ネットワーク・レコードを識別するステップと、
    前記ネットワーク・レコードに基づいて、複数のネットワーク信用証明書から１つのネットワーク信用証明書を取得するステップと、
    前記複数のネットワーク信用証明書から取得されたネットワーク信用証明書含む信用証明書要求応答を、前記ディジタル・デバイスに送るステップと、
    を含む方法
    が実施されるプログラムを記憶したコンピュータ可読媒体。
21. 前記信用証明書要求が、前記ネットワーク・デバイスの標準プロトコルを使って受け取られる請求項２０に記載のコンピュータ可読媒体。
22. 前記標準プロトコルがＤＮＳである請求項２１に記載のコンピュータ可読媒体。
23. 前記信用証明書要求を受け取るステップが、前記ネットワーク・デバイスのポート５３を介して前記信用証明書要求を受け取るステップを含む請求項２１に記載のコンピュータ可読媒体。

Images