JP2015503303A - セキュリティで保護された通信システムおよび通信方法 - Google Patents

Abstract

実施形態において、制限された接続環境において通信ネットワークを介してユーザ端末装置から解読構成要素にデータを送信するための方法が、ユーザ端末装置において、ユーザ端末装置におけるユーザからデータを受け取ることを含む。そのデータが機密性のあるデータであると判定された場合、その機密性のあるデータが、セキュリティで保護された暗号化キーを使用して暗号化される。パケットが、トンネリング・プロトコルに基づいて生成され、そのパケットが、コマンド・データと、暗号化された機密性のあるデータとを含む。そのコマンド・データが、ネットワーク構成要素のアドレスと、コマンドと、コマンド識別子とを含む。そのコマンドが、セキュリティで保護された暗号化キーがその機密性のあるデータを暗号化するのに使用されていることを識別する。そのアドレスにおいて識別されるネットワーク構成要素において、第１のポートでそのパケットが受信され、そのコマンドが読み取られ、そのパケットが、解読のために第２のポート経由で解読構成要素に転送され、さらに応答と、そのコマンド識別子とを含む応答パケットがユーザ端末装置に転送される。

Description

本発明は、通信システムおよび通信方法に関する。

パケット・ベースの通信システムは、パーソナル・コンピュータなどのデバイスのユーザが、インターネットなどのコンピュータ・ネットワークを介して通信することを可能にする。パケット・ベースの通信システムは、「ＶｏＩＰ（Voice-Over-Internet-Protocol）」通信システムを含む。これらのシステムは、固定回線ネットワークまたはモバイル・ネットワークと比べて、しばしば、大幅に費用が安いので、ユーザに有益である。このことは、長距離通信に関して特に当てはまり得る。ＶｏＩＰシステムを使用するのに、ユーザは、ユーザのデバイス上にクライアント・ソフトウェアをインストールして、実行しなければならない。このクライアント・ソフトウェアが、ＶｏＩＰ接続を提供するとともに、登録および認証などの他の機能も提供する。音声通信に加えて、このクライアントは、ビデオ通話、インスタント・メッセージング（「ＩＭ」）、ＳＭＳメッセージング、およびボイスメールなどのさらなる特徴的機能も提供する。

パケット交換に基づく通信システムの一つのタイプは、独自のプロトコル上に構築されたピア・ツー・ピア（Ｐ２Ｐ（Peer-To-Peer））トポロジを使用する。ピア・ツー・ピア・システムへのアクセスを可能にするために、ユーザは、ユーザのコンピュータ上でＰ２Ｐソフトウェア提供元によって提供されるＰ２Ｐクライアント・ソフトウェアを実行して、そのＰ２Ｐシステムに登録しなければならない。ユーザがＰ２Ｐシステムに登録すると、クライアント・ソフトウェアにサーバからデジタル証明書が供給される。クライアント・ソフトウェアに証明書が供給されると、サーバをさらに使用することなしに、その後、Ｐ２Ｐシステムのユーザ間で通信がセットアップされ、ルーティングされることが可能である。詳細には、これらのユーザは、Ｐ２Ｐシステムへのアクセスを可能にする１つまたは複数のデジタル証明書（またはユーザ身元証明書：「ＵＩＣ」）の交換に基づいて、Ｐ２Ｐシステムを介してユーザ自らの通信経路を確立することができる。ユーザ間のデジタル証明書の交換は、ユーザの身元、およびユーザがＰ２Ｐシステムにおいて適切に許可され、認証されていることの証明をもたらす。したがって、デジタル証明書の提示は、ユーザの身元への信頼をもたらす。したがって、通信が、サーバを使用してルーティングされるのではなく、エンド・ユーザからエンド・ユーザに向けて通信が直接ルーティングされることがピア・ツー・ピア通信の特徴である。そのようなＰ２Ｐシステムに関するさらなる詳細は、国際公開第２００５／００９０１９号パンフレットにおいて開示される。

パケット交換に基づく通信システムの抱える問題は、十分な帯域幅でインターネットに確実に接続されることが必要とされることである。このことは、ユーザが既知の固定の場所（ユーザの自宅など）にいる場合には、一般に問題ではないが、ユーザが移動中である場合には、特に問題となり得る。無線ローカル・エリア・ネットワーク（ＷＬＡＮ）のアクセス・ポイントによって提供されるインターネット無線接続用ホットスポット、および適切なホットスポット・ソフトウェアが、移動中にユーザによって使用可能となるように広く利用可能である。そのようなホットスポットは、しばしば、空港、カフェ、および駅などの公共区域において、しばしば、利用可能である。しかし、これらのホットスポットは、往々にしてオープンではなく、アクセスが制限され、セキュリティで保護されている。これらのホットスポットは、ユーザが、利用料金の支払いと引き換えにホットスポット運用者からログイン資格証明を獲得することを要求する。

ＷＩＳＰｒ（Wireless-Internet-Service-Provider-Roaming）プロトコルなどのプロトコルが、ホットスポットにアクセスするために使用され得る。ＷＩＳＰｒプロトコルが使用される場合、アクセスが制限されたホットスポットを使用してインターネットに接続しようと試みるユーザは、そのホットスポットの運用者のログイン・サーバに接続要求をリダイレクトされる。このリダイレクトにより、ユーザに対するログイン・ページの表示がもたらされる。そのログイン・ページは、（例えば、ユーザ名およびパスワードがユーザによってあらかじめ購入されている、または事前に取り決められた料金請求の取り決めの一環として与えられている場合）ユーザ名およびパスワードを入力するよう、またはクレジット・カード（もしくは他の支払い）の詳細情報を入力するようユーザを促す。要求される情報を入力することによって、ユーザは、ホットスポットへのアクセスを得て、さらにインターネットに接続することができ、それに応じて課金される。

上記のような方法でホットスポットにアクセスすることには問題がある。第１に、ユーザがホットスポットのログイン・サーバに対して支払いに必要な詳細情報を入力することにはセキュリティ上の問題がある。ユーザは、ユーザの支払いに必要な詳細情報または個人情報データをホットスポット・プロバイダが漏洩しないことを十分に信頼していなければならない。第２に、ユーザがホットスポット・ログイン・サーバに支払いに必要な詳細情報を入力することは、そのようにするためには、ユーザの支払いに関する詳細情報がユーザの手元にあることを必要とするので、ユーザにとって不便である。第３に、手動でログインして、この情報を入力するのは、操作に時間を要する手順であり、このことは、ユーザがインターネットに迅速にアクセスして、パケット交換に基づく通信システムを使用することを所望する場合、非効率的である。

英国特許第２４６４５５３号明細書が開示する先行技術は、パケット交換に基づく通信システムにおいて使用するためにユーザが既に購入しているクレジットを使用して、ユーザがホットスポットへのアクセスの代金を支払うことを可能にすることによって、制限されたＷＬＡＮホットスポットにアクセスすることが抱える前述した問題のいくつかに対処する。これらのユーザは、パケット交換に基づく通信システムを既に使用しているので、パケット交換に基づく通信ソフトウェアのプロバイダを相手にした支払い関係を、往々にして既に有する。通常、この支払い関係は、例えば、インターネットと公衆交換電話網（「ＰＳＴＮ」）の間で通話を行うために、ユーザが購入している前払い制のクレジットの形態である。

これらのユーザは、これらのユーザが既存の料金請求の取り決めを有するので、パケット交換に基づく通信ソフトウェアのプロバイダを信頼している。したがって、これらのユーザにとって、個人データまたはログイン資格証明を、ホットスポットの運用者に供給するより、パケット交換に基づく通信ソフトウェアのプロバイダに供給することの方が、より安心できるものである。

前払い制のクレジットを使用していると、ユーザは、ユーザがホットスポットにアクセスすることを所望するたびに支払いに関する詳細情報を入力しなくてもよい。代わりに、ユーザは、既存の料金請求関係のため、パケット交換に基づく通信ネットワークに関するユーザのログイン資格証明を供給するだけでよい。ホットスポットにアクセスするための機構は、通信クライアント・ソフトウェアに緊密に組み込まれることが可能であり、このことにより、ユーザが、ホットスポット経由でパケット交換に基づく通信システムへのアクセスを得るプロセスが大幅にスピードアップされ得る。

しかし、ホットスポットにアクセスすることを所望する多くのユーザは、ユーザのアカウント上にクレジットを有さないため、前述した前払い制のクレジットに基づく方法を使用することができない。

前払い制のクレジットがあらかじめ獲得されていない場合にホットスポットへのアクセスの代金をユーザが支払うことができるようにすることには、いくつかの問題点がある。ユーザは、インターネット・アクセスがまだ利用できず、したがって、ウェブ・サイトにアクセスすることによる標準的な支払い方法を使用することができないため、差し当たり、クレジットを獲得することができない。

ホットスポットは、パケット交換に基づく通信ソフトウェアのプロバイダの管理下にはなく、代わりに、第三者によって運用されているので、セキュリティ上の問題が存在する。この第三者は、適法なホットスポットであるかのように見えるが、ユーザ資格証明および／または支払い手段の詳細を収集する目的でのみ存在するホットスポットをセットアップしている悪意のあるユーザかも知れない。したがって、第三者であるホットスポット運用者にパケット交換に基づく通信ネットワークにおけるユーザのログイン資格証明および支払いに関する詳細情報が晒されてしまうことは、適切ではない。

さらに、ユーザは、支払いを行うこと、または有効な資格証明を提示することなしに、クレジットを獲得するためにインターネットへのアクセスを得ることができない。

国際公開第２００５／００９０１９号パンフレット 英国特許第２４６４５５３号明細書

本発明の一態様によれば、制限された接続環境において通信ネットワークを介してユーザ端末装置から解読構成要素にデータを送信する方法が提供され、この方法は、
ユーザ端末装置において、
ユーザ端末装置におけるユーザからデータを受け取ること、
当該データが機密性のあるデータであると判定された場合、当該機密性のあるなデータを、セキュリティで保護された暗号化キーを使用して暗号化すること、および
トンネリング・プロトコルに準拠してパケットを生成し、当該パケットが、コマンド・データと、当該暗号化された機密性のあるデータとを含み、当該コマンド・データが、ネットワーク構成要素のアドレスと、コマンドと、コマンド識別子とを含み、セキュリティで保護された暗号化キーが当該機密性のあるデータを暗号化するのに使用されていることを、当該コマンドが識別することを備える。

本発明は、自身に割り当てられたアドレスによって識別されるネットワーク構成要素において、
第１の通信ポートで当該パケットを受信すること、
当該コマンドを読み取ること、
当該パケットを、解読のために第２の通信ポート経由で解読構成要素に転送すること、および
応答と、当該コマンド識別子とを含む応答パケットをユーザ端末装置に転送することを含み得る。

本発明の別の態様によれば、解読構成要素を備える通信システムが提供され、その解読構成要素は、
コマンド・データおよび暗号化された機密性のあるデータを有するパケットを受信するための入力と、セキュリティで保護されたキーを保持するためのメモリと、そのセキュリティで保護されたキーを使用して、暗号化された機密性のあるデータを包含する受信されたパケットを解読し、前記機密性のあるデータを検証し、さらに検証応答を生成するように構成されたプロセッサと、その解読構成要素に接続され、そのセキュリティで保護されたキーとは異なるセッション・キーを保持するメモリを有するとともに、受信された各パケットの中のコマンド・データを読み取り、そのコマンド・データから暗号化キーを識別し、その暗号化キーがそのセッション・キーであるパケットを解読し、さらにその暗号化キーがそのセッション・キーであるパケットをその解読構成要素に転送するように構成されたプロセッサを含むネットワーク構成要素とを備える。

その機密性のあるデータは、支払いデータであり得る。

セッション暗号化キーは、ペアにされたキーがネットワーク構成要素において保持されるキー・ペアのうちの１つであり得る。セキュリティで保護された暗号化キーは、ペアにされたキーが解読構成要素において保持され、ネットワーク構成要素に知られていないキー・ペアのうちの１つであり得る。

本発明の別の態様が、少なくとも機密性のあるデータまたはセッション・データを入力するようユーザを促すように構成されたユーザ・インターフェースと、
前記データを受信し、
そのデータが機密性のあるデータであるか、またはセッション・データであるかを判定し、
機密性のあるデータをセキュリティで保護された暗号化キーで暗号化し、またはセッション・データをセッション・キーで暗号化し、
コマンド・データと、当該暗号化されたデータとを備えるパケットを生成し、当該コマンド・データが、平文であり、さらにコマンドと、コマンド識別子とを備え、当該コマンドにおいて、セキュリティで保護されたキーが使用されているか、またはセッション・キーが使用されているかを識別する、コンピュータ・プログラムを実行するように構成されたプロセッサとを有するユーザ端末装置を提供する。

このコンピュータ・プログラムは、通信ネットワークにおいて通信イベントを確立する、Ｓｋｙｐｅ（商標）などの通信クライアントであり得る。しかし、その機能は、スタンドアロン型の支払いアプリケーションとして、またはＷｉｎｄｏｗｓ（登録商標）などのオペレーティング・システムの一部であるＷｉＦｉネットワーク・マネージャなどの他の任意の関連するアプリケーションの特徴的機能として実装されてもよい。

当該コマンド・データを平文で供給することによって、当該コマンドを受信するネットワーク構成要素が、解読構成要素を宛先とするデータを解読できない場合に、それでも、当該コマンドが当該解読構成要素に転送されるべきか否かを判定することができる。

本発明のさらなる態様は、
通信ネットワークを相手にパケットを交換するための第１の通信ポートと、
［セキュリティで保護された環境において］解読構成要素を相手にパケットを交換するための第２の通信ポートと、
第１の通信ポートからパケットを受信し、当該パケットが、暗号化されたデータと、コマンドおよびコマンド識別子を含むコマンド・データとを包含し、
当該コマンドを読み取り、当該データを暗号化するために、セキュリティで保護されたキーが使用されているのか、それともセッション・キーが使用されているのかを判定し、
セッション・キーが使用されている場合には、当該データを解読して、当該データに従って動作し、さらに
セキュリティで保護されたキーが使用されている場合には、
当該パケットを第２の通信ポートに転送し、
応答と、そのコマンドとを含む応答パケットを、第１の通信ポート経由で送信するコンピュータ・プログラムを実行するように構成されたプロセッサとを備える、通信ネットワークにおいて使用するためのネットワーク構成要素を提供する。

この文脈において、セキュリティで保護された環境とは、制限されたアクセス環境、および／またはクレジット・カード処理環境を包含する。

本発明の別の態様が、通信ネットワークにおいてネットワーク構成要素を動作させる方法であり、この方法は、
通信ネットワークでネットワーク構成要素の第１の通信ポートからパケットを受信し、当該パケットは、暗号化されたデータと、コマンドおよびコマンド識別子を含むコマンド・データとを包含しており、当該コマンドを読み取り、そのデータを暗号化するために、セキュリティで保護されたキーが使用されているのか、それともセッション・キーが使用されているのかを判定し、セッション・キーが使用されている場合には、当該データを解読して、当該データに従って動作し、さらにセキュリティで保護されたキーが使用されている場合には、当該パケットを、解読構成要素を相手としてパケットを交換するために第２の通信ポートに転送し、さらに応答と、そのコマンド識別子とを含む応答パケットを、第１の通信ポート経由で送信することを備える。

また、本発明は、プロセッサによって実行されると、前述の方法を実施するコンピュータ・プログラム製品をさらに提供する。

本発明をよりよく理解するために、さらに本発明がどのように実施され得るかを示すように、次に、例として、以下の図面が参照される。

パケット・ベースの通信システムを示す図である。 通信クライアントを実行するユーザ端末装置を示す図である。 通信システムにおける構成要素を示す概略ブロック図である。 セキュリティで保護されたデータを送信することに関するシグナリング・チャートである。 ＷＬＡＮホットスポットにログインするプロセスに関するシグナリング・チャートである。 ステータス・クエリに関するシグナリング・チャートである。

前述したとおり、本発明の実施形態は、制限された接続環境において、より詳細には、インターネットへのアクセスがまだ許可されていない場合において、データ転送に関する問題を解決する技術的解決法を提供するのに役立つ。インターネット・アクセスが開かれる前でも、ＤＮＳトンネリングを使用してバックエンド・サーバを相手にデータを交換するアクセス・プロトコルが、英国特許第２４６４５５３号明細書において説明されている。本明細書で、このプロトコルが、クライアントからバックエンド・サーバに支払いに関する詳細情報を伝送して、ユーザが、クレジットを購入し、ホットスポットを介してインターネット・アクセスを得ることができるように拡張される。

最初に、パケット交換に基づく通信システム１００を例示する図１が参照される。この例示的な実施形態は、Ｐ２Ｐ通信システムに関連して説明されるが、非Ｐ２Ｐシステム、ＶｏＩＰシステム、またはＩＭシステムなどの他のタイプの通信システムが使用されることも可能であることに留意されたい。この通信システムの第１のユーザ（「トム・スミス」１０２と名付けられた）が、インターネットなどのネットワーク１０６に接続することができるユーザ端末装置１０４を操作する。ユーザ端末装置１０４は、例えば、パーソナル・コンピュータ（「ＰＣ」）（例えば、Ｗｉｎｄｏｗｓ（登録商標）ＰＣ、Ｍａｃ ＯＳ（商標）ＰＣ、およびＬｉｎｕｘ（登録商標）ＰＣ）、携帯情報端末（「ＰＤＡ」）、モバイル電話機、ゲーム・デバイス、またはネットワーク１０６に接続することができる他の組み込み型デバイスとすることが可能である。ユーザ端末装置１０４は、当該デバイスのユーザ１０２から情報を受け取るように、さらに当該デバイスのユーザ１０２に情報を出力するように構成される。本発明の好ましい実施形態において、ユーザ・デバイスは、スクリーンなどのディスプレイと、キーボード、マウス、ジョイスティック、および／またはタッチスクリーンなどの入力デバイスとを備える。

図１に示される例において、ユーザ端末装置１０４は、ＷＬＡＮアクセス・ノード１０７に接続することができるネットワーク・インターフェースを備える。このアクセス・ノードは、アクセス・ノード１０７に対する無線接続を提供するアクセス・ポイント（「ＡＰ」）１０８と、ユーザ端末装置がアクセス・ノード１０７に接続することができるか否かを制御するホットスポット・ポータル１０９とを備える。ＡＰ１０８とホットスポット・ポータル１０９は、単一のエンティティ内に並置されることも、別々の異なるエンティティ内に備えられることも可能である。しかし、構造上のレイアウトにかかわらず、この２つの構成要素の機能は、同一であり、したがって、ホットスポット・ポータル１０９は、ユーザ端末装置が、ＡＰ１０８経由でネットワーク１０６に（したがって、インターネットに）接続することができるかどうかを制御する。ホットスポット・ポータル１０９は、認証および支払いのために接続要求のリダイレクトするなどの機能を提供する。

ユーザ端末装置１０４は、ソフトウェア・プロバイダによって提供される通信クライアント１１０を実行している。通信クライアント１１０は、ユーザ端末装置１０４におけるローカルなプロセッサの上で実行されるソフトウェア・プログラムである。また、ユーザ端末装置１０４は、ユーザが音声通話において聞くこと、および話すことを可能にするスピーカおよびマイクを備えるハンドセット１１２にさらに接続される。このマイクおよびスピーカは、必ずしも従来の電話ハンドセットの形態である必要はなく、組み込まれたマイクロホンを有するヘッドホンもしくはイヤホン、またはユーザ端末装置１０４に独立して接続された別々のスピーカおよびマイクロホンの形態であること、あるいはユーザ端末装置１０４自体に組み込まれることも可能である。

ユーザ１０２が、ＷＬＡＮアクセス・ノード１０７経由でネットワーク１０６へのアクセスを得ることができるものと想定して、連絡先リストの中のユーザへのＶｏＩＰ通話は、連絡先を選択すること、およびマウスなどのポインティング・デバイスを使用してユーザ・インターフェース上の「通話」ボタンをクリックすることによって、通信システムを介して開始され得る。図１を再び参照すると、通話セットアップが、独自のプロトコルを使用して実行され、さらに発呼側ユーザと着呼側ユーザの間のネットワーク１０６上の経路が、サーバを使用することなしに、ピア・ツー・ピア・システムによって決定される。例えば、第１のユーザ「トム・スミス」１０２が、第２のユーザ「ケビン・ジャクソン」１１４を呼び出すことが可能である。

デジタル証明書の提示（国際公開第２００５／００９０１９号パンフレットにおいてより詳細に説明されるとおり、ユーザがその通信システムの真正の加入者であることを証明する）を介した認証の後に、その呼が、ＶｏＩＰを使用して行われることが可能である。クライアント１１０が、ＶｏＩＰパケットの符号化および復号化の処理を実行する。ユーザ端末装置１０４からのＶｏＩＰパケットが、アクセス・ノード１０７を介してネットワーク１０６に送信され、ネットワーク・インターフェース１１８経由で着呼側１１４のコンピュータ端末装置１１６にルーティングされる。着呼側ユーザ１１４のユーザ端末装置１１６上で実行されるクライアント１２０（クライアント１１０と同様）が、それらのＶｏＩＰパケットを復号して、ハンドセット１２２を使用する被呼側ユーザによって聞かれることが可能なオーディオ信号をもたらす。逆に、第２のユーザ１１４が、ハンドセット１２２に向かって話すと、ユーザ端末装置１１６上で実行されるクライアント１２０が、それらのオーディオ信号をＶｏＩＰパケットに符号化して、それらのＶｏＩＰパケットを、ネットワーク１０６を介してユーザ端末装置１０４に送信する。ユーザ端末装置１０４上で実行されるクライアント１１０が、それらのＶｏＩＰパケットを復号化し、ハンドセット１１２のユーザによって聞かれることが可能なオーディオ信号をもたらす。

前述したユーザ（１０２と１１４などの）間の呼に関するＶｏＩＰパケットは、専らネットワーク１０６を介して送られ、公衆交換電話網（「ＰＳＴＮ」）１２４は、関与しない。さらに、システムのＰ２Ｐに基づく性質のため、この通信システムのユーザ間の実際の音声通話は、中央サーバが全く使用されずに行われ得る。このことは、ネットワークが、容易に拡大縮小され、高い音声品質を維持し、さらに呼がユーザにとって無料で利用されることが可能であるという利点を有する。さらに、呼が、呼をＰＳＴＮネットワーク１２４にルーティングすることによって、パケット交換に基づく通信システムを使用するクライアント（１１０、１２２）から、固定回線電話機またはモバイル電話機１２６に行われることも可能である。同様に、固定回線電話機またはモバイル電話機１２６からの呼が、ＰＳＴＮ１２４を介してパケット交換に基づく通信システムに向けて行われることも可能である。

音声通話を行うことに加えて、クライアント１１０のユーザは、いくつかの他の様態で、例えば、インスタント・メッセージング（チャット・メッセージとしても知られる）、ファイル伝送、連絡先にボイスメールを送信すること、またはビデオ通話を確立することなどによって、それらのユーザと通信することもできる。

図２は、クライアント１１０が実行されるユーザ端末装置１０４の詳細な図を示す。このユーザ端末装置１０４は、ディスプレイ・インターフェース３０５を介してスクリーンなどのディスプレイ３０４が接続された中央処理装置（「ＣＰＵ」）３０２、ならびにＵＳＢなどのインターフェース３０９を介して接続されたキーボード３０６などの入力デバイスおよびマウス３０８などのポインティング・デバイスを備える。代替的な端末装置においては、キーパッド、タッチスクリーン、および／またはジョイスティックなどの入力デバイスおよびポインティング・デバイスが、端末装置にさらに組み込まれることも可能である。出力オーディオ・デバイス３１０（例えば、スピーカ）および入力オーディオ・デバイス３１２（例えば、マイク）が、オーディオ・インターフェース３１３を介して接続される。出力オーディオ・デバイス３１０と入力オーディオ・デバイス３１２は、ハンドセット１１２もしくはヘッドセットに組み込まれてもよく、別々であってもよい。ＣＰＵ３０２は、ＷＬＡＮ ＡＰに接続するためにネットワーク・インターフェース３１１に接続される。

また、図２は、ＣＰＵ３０２上で実行されるオペレーティング・システム（「ＯＳ」）３１４をさらに例示する。ＯＳ３１４の上で実行されるものは、クライアント１１０のためのソフトウェア・スタック３１６である。図中において、このソフトウェア・スタックは、プロトコル層３１８、クライアント・エンジン層３２０、およびクライアント・ユーザ・インターフェース層（「ＵＩ」）３２２として示されている。各層は、特定の機能を担う。通常の場合、各層がその他の２つの層と通信するため、これらの層は、図３に示されるとおり、スタックに構成されているものと見なされる。オペレーティング・システム３１４が、コンピュータのハードウェア・リソースを管理し、ネットワーク・インターフェース１０８経由でネットワークに伝送される、またはネットワークから伝送されるデータを処理する。クライアント・ソフトウェアのクライアント・プロトコル層３１８は、オペレーティング・システム３１４と通信し、通信システムを介した接続を管理する。より高いレベルの処理を要求するプロセスは、クライアント・エンジン層３２０に送られる。クライアント・エンジン層３２０は、クライアント・ユーザ・インターフェース層３２２とさらに通信する。クライアント・エンジン層３２０は、クライアント・ユーザ・インターフェース層３２２を制御することにより、クライアントのユーザ・インターフェース（図２に示される）を介してユーザに情報を提示するように構成され、さらには、このユーザ・インターフェースを介してユーザから情報を受け取るように構成され得る。

同様に図に示され、クライアント１１０に組み込まれるものは、アクセス・マネージャ３２４である。アクセス・マネージャ３２４は、ＷＬＡＮホットスポットに対するアクセスを管理することを担う。本発明に係る好ましい実施形態においては、アクセス・マネージャ３２４は、クライアント１１０内に組み込まれ、クライアントＵＩ層３２２を利用してユーザに情報を表示し、クライアント・プロトコル層３１８を利用して通信システムに接続する。本発明に係る代替的な実施形態において、アクセス・マネージャ３２４は、ＯＳ３１４上で実行されるが、クライアント１１０と通信状態にあるスタンドアロン型のソフトウェアとしても実装され得る。

図３は、図１の通信システムにおいて使用するためのセキュリティで保護されたアクセス・システムの構成要素を例示する概略ブロック図である。図１に示される構成要素のうちのいくつかは、図２にも示されており、同様の参照符号で示される。図１に示される構成要素に加えて、図２は、ポータル１０９に接続されたワールドワイドウェブ・サーバ２００およびドメイン・ネーム・サーバ２０２を示す。

図１および図３は、通信クライアント・ソフトウェア・プロバイダのドメイン・ネーム・サーバ（ＤＮＳ）１２８をさらに示す。ＤＮＳトンネリングとして知られる技法を使用してホットスポット１０９のアクセス制限をバイパスするために、ＤＮＳプロトコルが使用される。通信クライアント・ソフトウェア・プロバイダのドメイン・サーバ（ＤＮＳ）１２８は、必ずしも実際のドメイン・ネーム・サーバではなく、ＤＮＳプロトコルを使用して通信するように構成された、特別に構成されたバックエンド・サーバとしても良いことに留意されたい。図１および図３にさらに示されるのが、英国特許第２４６４５５３号明細書で既に知られ、以降において簡単に説明される方法でホットスポットへのアクセスを提供するのに使用され得るアクセス・ルックアップ・データベース１３０である。

図３に示されるセキュリティで保護されたアクセス・システムは、セキュリティで保護された環境、例えば、ＤＮＳバックエンド・サーバ１２８をセキュリティで保護されたウェブ支払いＡＰＩ２１２に接続する暗号サービス構成要素２１４を備える支払い管理業界環境２１０を備える。支払いハンドラ統合サービス２１６が、暗号サービス構成要素２１４にやはり接続される、注文およびカード・データに関するデータベース２１８に接続される。暗号サービス構成要素２１４は、ＡＰＩ２１２を介してアクセス・データベース２２０に接続される。

データベース２２０は、本明細書で説明される支払いプロセスにおいてユーザ資格証明を検証する役割を果たす。

クレジット・カード番号処理は、ＰＣＩコンプライアンスに関する厳格な一連の規則に準拠しなければならず、主な要件は、カード番号および他の機密性のあるデータが、クライアント端末装置から、セキュリティで保護されていると考えられるＰＣＩ準拠の環境に至る終端間で暗号化されなければならないことである。

このことを実現するのに、セッション（後段で説明される）を確立するのに使用されるアクセス・プロトコルを拡張する新たなパケット・タイプが導入される。これらの新たなパケット・タイプは、この事例では、バックエンド・サーバが解読できない支払いトラフィックである、機密性のあるデータの暗号化されたペイロードを伝送する。サーバ１２８は、支払いトラフィックを暗号サービス構成要素２１４に転送する。

セキュリティは、セッション・パケットを暗号化するのと、セキュリティで保護された支払いパケットを暗号化するのに異なる公開キー／暗号化キー・ペアを使用することによって保たれる。

次に、インターネット・アクセスを確立していることなしに、支払いが行われ得るクライアントとＰＣＩ環境の間のセキュリティで保護された通信を実施するためのプロセスを説明する図４が参照される。

この支払い方法は、図４Ａに関連して後段で説明される、ステップＳ４１２からステップＳ４１４までのセッション確立プロセスとは無関係である。

以下において、支払いメッセージが、ＡＰＩ１０８のＤＮＳポータル経由でネットワーク１０６を介して通信クライアント・ソフトウェア・プロバイダのドメイン・ネーム・サーバ（「ＤＮＳ」）１２８に送られるＤＮＳクエリ（ＤＮＳ問い合わせ）として符号化される。ＤＮＳプロトコルは、ＤＮＳトンネリングとして知られる技法を使用してホットスポット１０９のアクセス制限をバイパスするのに使用される。

このことは、正規名（「ＣＮＡＭＥ」）レコードＤＮＳクエリを使用することによって実現される。このクエリ（問い合わせ）と応答形式はともに厳格な一連の規則に準拠しなければならない。完全修飾ドメイン名（「ＦＤＱＮ」）の全長は、６３文字までのラベルを長さバイトと混ぜる内部形式で表される場合、２５５バイトを超えることができない。最大限の長さのラベルを使用すると、ペイロードを伝送するために２５０文字が存在する。Ｂａｓｅ３２符号化が、辞書「ａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ０１２３４５６」と一緒に使用され得る。各文字は、５ビットのバイナリ・ペイロードを伝送することが可能であり、このことは、各応答および各クエリは、１２４８ビットを伝送することができることを意味する。１１５２ビットのリベスト・シャミア・エーデルマン（「ＲＳＡ」）キーが、暗号化のために使用される。読み取り可能な形態のクエリは、「ｄａｔａ．ｄａｔａ．ｄａｔａ．ａｃｃｅｓｓ．ｓｋｙｐｅ．ｃｏｍ」と類似した形態である。各ＤＮＳトンネリング・パケットは、バックエンドＤＮＳサーバなどの、パケットの宛先を識別するアドレスを有する。

Ｓ４４１において、支払い開始要求が、端末装置１０４におけるクライアント１１０から送信される。支払い開始要求は、以下の形態である。すなわち、

この場合、「Ｓｋｙｐｅｒ」および「Ｓｋｙｐｅ（商標）」という名前は、Ｓｋｙｐｅ通信システムに限定することを意図しておらず、つまり、任意のユーザ名またはログイン資格証明が使用され得ることに留意されたい。

ＣＯＭＭＡＮＤフィールドおよびＣＭＤ ＩＤフィールド（平文である）は別として、この要求の中の残りのフィールドのそれぞれは、セキュリティで保護されたＲＳＡプライベート・キーで暗号化されることに留意されたい。支払いＲＳＡプライベート・キーは、本明細書では、専ら支払い目的で使用される１１５５２ビットのリベスト・シャミア・エーデルマン・キーである。後段で説明されるとおり、異なるＲＳＡキーが、セッションの確立のために使用される。ＤＮＳサーバ１２８は、セキュリティで保護された支払いＲＳＡキーへのアクセスを有さず、したがって、この要求を解読することができない。ＤＮＳサーバ１２８は、この要求を暗号サービス構成要素２１４に転送する。セキュリティで保護されたキーが使用されているという事実は、ＣＯＭＭＡＮＤフィールドで識別される。実際、サーバ１２８は、これらの暗号化されたフィールドをＢＬＯＢとして扱う。サーバ１２８は、この要求を、要求ペイロードとしてそのまま、セキュリティで保護されたウェブ支払いＡＰＩ２１２を介して暗号サービス構成要素２１４に転送する。

支払いＲＳＡキーのプライベート部分は、セキュリティで保護された環境内の暗号サービス構成要素だけに知られており、その暗号サービス構成要素が、キーのプライベート部分を使用してユーザを認証する。この実施形態において、認証は、セキュリティで保護されたｗｅｂ．ａｐｉを使用するが、認証方法は、異なるユーザ・タイプに関して異なることが可能である。トランザクション・レコードが、ランダムなトランザクションＩＤ番号でデータベース内に作成される。このことが、Ｓ４４２として記載される。暗号サービス構成要素２１４が、以下の形態のトランザクション継続メッセージを戻す（Ｓ４４３）。すなわち、

前述のメッセージにおいて、ｔｒａｎｓａｃｔｉｏｎ ＩＤは、ＭＤ５（ｃｌｉｅｎｔ＿ｃｈａｌｌｅｎｇｅ、「暗号化する」、ｉｎｉｔｉａｔｏｒ＿ｖｅｃｔｏｒ）に設定されたＲＣ４キーを使用して、ＲＣ４初期化ベクトルを包含するフィールドと一緒に暗号化される。その他の対称型暗号化アルゴリズム、例えば、ＡＥＳ、ＤＥＳなどが、本発明に係る異なる実施例において使用され得ることに留意されたい。ｃｍｄｉｄフィールドは、クライアントによって割り当てられたコマンドＩＤを包含する。ｒｅｓｕｌｔ ｃｏｄｅフィールドは、クライアントにステータス情報を供給する応答を保持する。このトランザクション継続メッセージは、サーバ１２８に戻され、その後、クライアント１１０に戻され、Ｓ４４４で、クライアント１１０が、以下の形式の製品詳細メッセージを戻す。

製品詳細が受け付けられた場合、Ｓ４４５で、サーバ１２８が、トランザクション継続メッセージで応答する。製品詳細メッセージの中で、ＣＯＭＭＡＮＤフィールドおよびＣＭＤ ＩＤフィールド以外のすべてのフィールドは、支払いＲＳＡキーを使用して暗号化される。このため、これらのフィールドは、解読および検証のために暗号サービス構成要素２１４に供給される。

そのトランザクション継続メッセージが、クライアント１０４において受信される。支払いに関する詳細情報は、クライアントによって、Ｓ４１６で暗号サービス構成要素２１４に送信される支払詳細メッセージとして形成される。コマンドおよび応答の流れ全体が、ユーザ・インターフェースにおいてユーザに表示された画面にユーザがすべての詳細を入力した後に生じることに留意されたい。次に、３つのコマンドのシーケンスが、クライアントによって自動的に発行される。

支払詳細メッセージの中のフィールドは、ＣＯＭＭＡＮＤフィールドおよびＣＭＤ ＩＤフィールド（平文である）以外、支払いＲＳＡキーを使用して暗号化される。支払いに関する詳細情報を受信すると、暗号サービス構成要素２１４は、支払いに関する詳細情報を解読し、トランザクションＩＤに基づいて、トランザクションに関するそれまでに格納されているデータを調べ、さらにＰＣＩデータベース２１８を使用して支払いを認証するウェブ支払いＡＰＩ２１２のための要求メッセージを生成する。Ｓ４４８で、好ましくは、乱数または他の何らかの予測不能なパラメータの形態で支払いＩＤを含む支払い応答が、セキュリティで保護されたウェブＡＰＩ２１２によって生成される。支払いＩＤは、暗号サービス構成要素２１４によって支払い応答に形成され、この応答が、ＤＮＳサーバ１２８に戻され、さらにＤＮＳサーバ１２８からクライアントに戻される。支払い応答の形式は、以下に示すとおりである。

次に、トランザクション開始メッセージＳ４４２に対してＳ４４３で、さらに製品詳細メッセージに対してＳ４４５で応答として供給されるトランザクション継続メッセージに戻る。これらの応答の両方において、ｒｅｓｕｌｔ ｃｏｄｅフィールドが、以下の可能な４つの応答のうちの１つを保持することが可能である。すなわち、
ＲＥＳＵＬＴ＿ＣＯＮＴＩＮＵＥ。
ＲＥＳＵＬＴ＿ＮＯＴ＿ＡＵＴＨＥＮＴＩＣＡＴＥＤ。
ＲＥＳＵＬＴ＿ＩＮＶＡＬＩＤ＿ＴＲＡＮＳＡＣＴＩＯＮ。
ＲＥＳＵＬＴ＿ＰＡＹＭＥＮＴ＿ＦＡＩＬＥＤ。

ほとんどの事例において、これらの結果オプションは、解読および認証の結果に応じて暗号サービス構成要素２１４によってＤＮＳサーバに供給される。しかし、ネットワーク構成要素は、暗号サービス構成要素２１４が応答しなかった場合、第４の結果オプション（ＲＥＳＵＬＴ＿ＰＡＹＭＥＮＴ＿ＦＡＩＬＥＤ）を自ら生成することができる。ＤＮＳサーバは、コマンド・コード、ＲＣ４初期化ベクトル・コード、コマンドＩＤ、および結果コードが平文で送り返される、表２に示す形式を有するメッセージを生成する。トランザクションＩＤは存在しないので、ペイロードのいずれの部分も暗号化されなくてもよい。さらに、暗号化される部分が存在しないので、ＲＣ４初期化ベクトル・コードは、関係がない。

クライアントが支払いＩＤ（Ｓ４４８で生成された支払い応答メッセージの中で供給される）を得ると、クライアントは、以下に示す形式を有する支払いステータス・クエリ・メッセージを使用して、支払いステータスに関してポーリングすることができる（図４Ｂ参照）。

このステータス・クエリ・メッセージは、ＤＮＳサーバ１２８に供給され、ＤＮＳサーバ１２８が、このメッセージを、解読のために暗号サービス構成要素２１４に送る。暗号サービス構成要素２１４が、セキュリティで保護されたウェブ支払いＡＰＩを使用してＰＣＩデータベース２１８にアクセスし、支払いのステータスを確認する。支払いステータスが、セキュリティで保護されたウェブＡＰＩ２１２によって、暗号サービス構成要素２１４に戻され、暗号サービス構成要素２１４が、ＤＮＳサーバ１２８から端末装置１０４におけるクライアント１１０に伝送される、以下に記載されるとおりの形式を有する支払いステータス結果メッセージを生成する。

前述の方法は、制限された接続環境においてセキュリティで保護されたデータのトランスポートの問題を解決する。支払いが行われると、ユーザは、クレジットを受け取ることができ、したがって、ユーザは、その後、例えば、英国特許第２４６４５５３号明細書において開示され、図４Ａに関連して後段でより完全に説明される技法を使用して、前払いのクレジットでホットスポットにアクセスすることができる。以下において、クエリ形式および応答形式もまた、前述したＤＮＳに関して記載される規則に準拠しなければならない。さらに、ＲＳＡキーが暗号化のために使用されるが、このＲＳＡキーは、支払いに関する詳細情報を交換するための暗号サービス構成要素を相手にしたセキュリティで保護された交換のために使用されるＲＳＡキーとは異なる。つまり、クレジットを使用してホットスポットにアクセスする目的でＤＮＳサーバにアクセスするためのパケットを暗号化する場合と、支払いを行う目的で暗号サービス構成要素にアクセスするためのパケットを暗号化する場合とでは、それぞれ異なる公開キー／暗号化キー・ペアが存在する。

支払いフローは、セッション確立とは無関係であるものの、セッション確立の方法について、次に説明する。一実施形態において、ＳＳＩＤ要求およびトークン要求（後段で説明される）が実行されてから、ユーザに支払い画面が提示され、したがって、支払いコマンド・フローは、図４Ａに示されるステップの後に続き、その後、トークンがしばらくタイムアウトしているため、セッション確立プロセスが繰り返される。

次に図４Ａを参照すると、第１のステップ（図示せず）として、クライアントがインストールされているデバイスのオペレーティング・システム（ＯＳ）３１４が、利用可能なワイヤレス・ネットワークがないか走査する。オペレーティング・システム（ＯＳ）は、記憶されているアクセス・ポイントに自動的に接続すること、またはアクセス・ポイントを選択するようユーザを促すことができる。ＯＳ３１４によって実行される走査の動作は、使用中のユーザ端末装置１０４、およびユーザ端末装置１０４が実行しているＯＳに依存する。

アクセス・マネージャ３２４（図２）が、ネットワーク・インターフェース３１１において生じる変化を検出する。このことは、アクセス・マネージャ３２４がネットワーク・インターフェース・イベントについて通知を受けること、またはアクセス・マネージャによる周期的なポーリングによって実現され得る。このために使用される機構は、当該のユーザ端末装置１０４に依存する。

ネットワーク・インターフェースにおける変化が検出されると、アクセス・マネージャ３２４が、ＯＳ３１４の走査によって検出されたＡＰ１０８のサービス・セット識別子（「ＳＳＩＤ」）を読み取る。このことに応答して、アクセス・マネージャ３２４は、ＳＳＩＤ情報クエリを生成する。このクエリは、アクセス・マネージャが、当該のホットスポット１０９にログインすることが可能であるかどうかを明らかにし、さらに既存の支払いクレジットを使用してアクセスの代金を支払うのに使用される。これを行うのに、アクセス・マネージャ３２４は、ネットワーク１０６を介して、容認できるＳＳＩＤのデータベースを保持するサーバにＳＳＩＤ情報クエリを送信する必要がある。しかし、ネットワーク１０６に対する一般的なアクセスは、ホットスポット１０９によって制限される。代替の実施形態において、容認できるＳＳＩＤのデータベースが、ユーザ端末装置において保持されることも可能であるが、そのようにすることは、対処するのがより困難である。支払いメッセージとして、ＳＳＩＤ情報クエリは、ＤＮＳクエリとして符号化される。

アクセス・マネージャ３２４から通信クライアント・ソフトウェア・プロバイダのＤＮＳサーバ１２８に送信されるＳＳＩＤ情報クエリは、ワイヤレスＬＡＮ ＡＰ１０８を識別するＳＳＩＤと、媒体アクセス制御（「ＭＡＣ」）アドレス（ＡＰ１０８の物理ネットワーク・インターフェースを識別する）と、オプションとして、クライアント１１０にログインしているユーザ１０２のユーザ名（Ｓｋｙｐｅｎａｍｅ）とを備える。

より詳細には、ＳＳＩＤ情報クエリのペイロードは、以下のデータを備える。すなわち、
コマンド： １バイト長、ペイロードがＳＳＩＤ情報要求であることを示す。
ｃｍｄｉｄ： １バイト長、クライアントによって割り当てられたコマンドＩＤ。ＤＮＳサーバが、応答の中でこのＩＤを送り返して、コマンドと応答を一致させることを可能にする。
ユーザ名： ３２バイト長、文字列、ユーザ名が厳密に３２バイト長である場合、０で終わらないことが可能である。
アクセス・ポイントＳＳＩＤ： ３２バイト長、文字列、ＳＳＩＤが厳密に３２バイト長である場合、０で終わらないことが可能である。
アクセス・ポイントＭＡＣ： ６バイト長、バイナリ形式、利用可能でない場合、すべて０。
ランダムなクライアント・チャレンジ： １６バイト、バイナリ形式。
３２文字より長いユーザ名に関するユーザ名ハッシュ： バイナリ形式 ２０バイト（ＳＨＡ１）（ユーザ名ハッシュは、ユーザ名が０で終わらない場合に限って意味がある）

ペイロードのコマンド部分は、暗号化されずに送信される。残りのペイロードは、セキュリティのためにＲＳＡ暗号化される。その後、ペイロードは、ｂａｓｅ３２符号化され、その結果が、パケット・ベースの通信システム・プロバイダがＤＮＳサービスを実行するドメイン名、例えば、「．ａｃｃｅｓｓ．ｓｋｙｐｅ．ｃｏｍ」が追加された、別々のラベルに細分される。

次に、クライアント１１０におけるアクセス・マネージャ３２４が、再帰的ＣＮＡＭＥクエリを行う。前述したとおり、このクエリは、ＤＮＳクエリ（ＤＮＳトンネリングを使用する）であるため、このメッセージは、ホットスポット１０９がネットワーク１０６へのアクセスを制限するものの、送信されることが可能である。

ＳＳＩＤクエリを受信すると、通信クライアント・ソフトウェア・プロバイダのＤＮＳサーバ１２８が、バイナリ・ペイロードを、結果が２３１文字長になるまで、辞書の中にない文字を除外して、すべてのラベルを連結し、２３１文字長になった時点で、ｂａｓｅ３２符号化が除去され、１４４バイトのバイナリ・ペイロードがもたらされるようにすることによって抽出する。次に、このバイナリ・ペイロードが、ＲＳＡ解読される。

通信クライアント・ソフトウェア・プロバイダのＤＮＳサーバ１２８が、ホットスポット１０９の運用者と支払いパートナ（すなわち、料金請求の取り決めが存在する信頼されるパートナ）の間に合意が存在するかどうかを判定する。このことは、ＳＳＩＤでアクセス・データベース１３０にクエリを行うことによって判定される。応答が、アクセスＤＢ１３０から受信される。また、このホットスポット１０９に関する価格設定情報も取り出される。ユーザの場所（ユーザのプロファイル情報の中に設定されている）が、オプションとして、ユーザ名でユーザ・データベース１３２にクエリを行い、応答を受信することによって特定され得る。このデータを使用して、価格設定情報が、ユーザの現地通貨で与えられることが可能である。

図１のデータベースは、オプションのＤＢアクセス・ノード１２９経由でアクセスされることに留意されたい。

ＳＳＩＤ情報クエリが、ＭＡＣアドレスを含まない場合、ＤＮＳサーバ１２８は、ＭＡＣを無視して、ＳＳＩＤだけを探す。このクエリが、或るＭＡＣを指定する場合、サーバは、一致を見つけ出そうと試みる。一致が見つからなかった場合、サーバは、それに応答してＭＡＣアドレスを０で埋め、汎用のＳＳＩＤ情報で応答する。

通信クライアント・ソフトウェア・プロバイダのＤＮＳサーバ１２８が、ＤＮＳ応答として符号化されたＳＳＩＤ応答を生成する。ユーザ１０２が、ユーザのクレジット（パケット・ベースの通信システムにおいて使用されるように購入された）を使用して、ＡＰ１０８経由でのインターネットへのアクセスの代金を支払うことができると判定された場合、ＳＳＩＤ応答は、クライアント１１０が、アクセス・マネージャ３２４を使用して、ホットスポットにアクセスするための代金を支払うことができることを示す。詳細には、ＳＳＩＤ応答は、ユーザの現地通貨におけるホットスポット１０９に関する価格設定情報を含み得る。

ユーザがクレジットを有さない場合、ユーザには、ユーザがクレジットを購入できることを示すポップアップ・メッセージが示され、図４の支払い手順が開始する。一実施形態において、クレジットの利用可能性は、失敗したトークン要求クエリによって判定されるが、この情報は、他の手段で供給されることも可能である。

通信クライアント・ソフトウェア・プロバイダのＤＮＳサーバによって生成されるＳＳＩＤ情報応答ペイロードは、以下を備える。すなわち、
ｃｍｄｉｄ： １バイト長、この応答が対応するＳＳＩＤ要求コマンドのコマンドＩＤ。
アクセス・ポイントＳＳＩＤ： ３２バイト長、文字列、ＳＳＩＤが厳密に３２バイト長である場合、０で終わらないことが可能である。
アクセス・ポイントＭＡＣ： ６バイト長、バイナリ、利用可能でない場合、すべて０。
価格： ４バイト長、ビッグエンディアンの符号なし整数。
ｐｒｉｃｅ＿ｐｒｅｃｉｓｉｏｎ： ４バイト長、価格の１０進数の精度、ビッグエンディアンの符号なし整数。
通貨： ４バイト長、０で終わる３文字の通貨コード。
プロバイダＩＤ： ２バイト長、ビッグエンディアンの整数。

通信クライアント・ソフトウェア・プロバイダのＤＮＳサーバ１２８は、クエリの中で供給される「クライアント・チャレンジ」から導き出された暗号化キーを使用してＳＳＩＤ情報応答を暗号化する。暗号化の後、そのペイロードが、ｂａｓｅ３２符号化される。

ＳＳＩＤ情報応答は、ステップＳ４１２で、ＤＮＳトンネリングを使用してクライアント１１０に送信される。

ＳＳＩＤ情報クエリに対する肯定的な応答を受信したことに応答して、ステップＳ４１４で、アクセス・マネージャ３２４は、トークン要求を生成し、さらにそのトークン要求を、ＤＮＳプロトコル（トンネリング）を使用して通信クライアント・ソフトウェア・プロバイダのＤＮＳサーバ１２８に送信するように構成される。

トークン要求メッセージのペイロードは、以下を備える。すなわち、
コマンド： １バイト長。ｃｍｄｉｄ： １バイト長、クライアントによって割り当てられたコマンドＩＤ。
ユーザ名： ３２バイト長、テキスト文字列形式、ユーザ名が厳密に３２バイト長である場合、０で終わらないことが可能である。
アクセス・ポイントＳＳＩＤ： ３２バイト長、テキスト文字列形式、ＳＳＩＤが厳密に３２バイト長である場合、０で終わらないことが可能である。
パスワード・ハッシュ： １６バイト長（ＭＤ５）、バイナリ形式。
ランダムなクライアント・チャレンジ： １６バイト長、バイナリ形式。
３２文字より長いユーザ名に関するユーザ名ハッシュ： バイナリ形式の２０バイト長（ＳＨＡ１）（ユーザ名ハッシュは、ユーザ名が０で終わらない場合に限って意味がある）。

この１バイトのコマンドは、暗号化されずに送信され、１１７バイトの残りの全ペイロードは、ＲＳＡ暗号化される。パスワード・ハッシュは、公開ＲＳＡキーの最初の１６バイトがさらにハッシュされているユーザ名／パスワード・ハッシュである。このことは、ＲＳＡキーがそのパケットを暗号化するのに使用されている間だけ、ハッシュを使用可能にし、ＲＳＡキーが無効にされている場合はそれまでに送信されたすべてのハッシュ値を無効にする。

次に、もたらされる１１６０ビットが、ｂａｓｅ３２符号化され、その結果が、別々のラベルに細分され、パケット・ベースの通信システム・プロバイダがＤＮＳサービスを実行するドメイン名、例えば、「．ａｃｃｅｓｓ．ｓｋｙｐｅ．ｃｏｍ」が追加される。次に、ステップＳ４１４で、クライアント１１０が、通信クライアント・ソフトウェア・プロバイダのＤＮＳサーバ１２８に対してＩＮクラスにおいて再帰的ＣＮＡＭＥクエリを行う。各クエリは異なるので、各クエリは、指定されたドメインに関して信頼できる回答を与えるＤＮＳサーバに到達する。

「クライアント・チャレンジ」は、応答パケットを暗号化するためのキーを生成するため、およびトークンからセッションＩＤ値を生成する（後段で説明される）ために使用される。例えば、ＲＣ４ドロップ（７６８）対称暗号化アルゴリズムが、使用されることが可能であり、ただし、ストリーム・モードにおける任意の対称暗号が使用されることも可能である。

トークン要求を受信したことに応答して、通信クライアント・ソフトウェア・プロバイダのＤＮＳサーバは、そのトークン要求を解読し、ユーザ名およびパスワード・ハッシュを抽出するように構成される。ステップＳ４１６およびＳ４１８で、ＤＮＳサーバが、そのユーザ名およびパスワードを、ユーザ・データベース１３２の中にリストされる資格証明に照らして検証する。ステップＳ４２０で、ユーザのクレジット残高が、アカウントＤＢ１３４から要求され、Ｓ４２２で、応答が受信されて、ユーザが、ホットスポット１０９へのアクセスの代金を支払うのに十分なクレジットを有することが確実にされる。

ユーザが検証され、十分なクレジットを有する場合、通信クライアント・ソフトウェア・プロバイダのＤＮＳサーバ１２８は、ランダムな１６バイトのトークンを生成し、ｂａｓｅ３２符号化された応答でクライアント１１０に応答する。

トークン応答メッセージのペイロードは、以下を備える。すなわち、
コマンド： １バイト長。
ｒｃ４初期化ベクトル： ４バイト長、バイナリ形式。
結果コード： １バイト長。
ｃｍｄｉｄ： １バイト長、この応答が対応するトークン要求コマンドのコマンドＩＤ。
トークン： ８バイト長：
ティック・サーバ・アドレス： ８バイト長、好ましくは、ティックを送信すべき宛先の２つのＩＰアドレス（後段で説明される）。
ログイン名形式指定子： ８３バイトまでの長さ。

結果コードから始めてペイロード全体が、クライアント・チャレンジから生成されたキーを使用して暗号化される。暗号化の後、ペイロードは、ｂａｓｅ３２符号化される。次に、ステップＳ４２４で、トークン応答メッセージが、ＤＮＳトンネリングを使用してクライアント１１０に送信される。次に、クライアント１１０が、その応答を復号し、その後、解読する。

ステップＳ４２５で、通信クライアント・ソフトウェア・プロバイダのＤＮＳサーバ１２８は、ユーザ名およびクライアント・チャレンジを用いてＤＮＳサーバ１２８が生成したトークンをアクセスＤＢ１３０の中にさらに格納する。通信クライアント・ソフトウェア・プロバイダのＤＮＳサーバ１２８は、トークンから一時ユーザ名をさらに生成し（後段で説明される）、この一時ユーザ名をセッションＩＤとして格納する。このトークンは、使用されない場合、所定の時間の後にサーバから期限切れになる。

ステップＳ４２４でトークンおよび形式指定子を受信したことに応答して、アクセス・マネージャ３２４は、応答を復号化し、解読する。次に、アクセス・マネージャ３２４は、ユーザに、ユーザのパケット・ベースの通信システムのクレジットを使用して接続の代金を支払うオプションを与えるようクライアントＵＩ３２２を制御する。例示的なユーザ・インターフェース・メッセージが、図５に示される。ユーザ１０２は、「開始」ボタン５０２を選択することによってＡＰ１０８に接続することを選択すること、または「取り消し」ボタンを選択することによって接続しないことを選択することができる。

ユーザがＡＰ１０８に接続することを所望することを示す選択信号をユーザから受け取ったことに応答して、ステップＳ４２６で、アクセス・マネージャは、一時ユーザ名（トークンおよびクライアント・チャレンジから導き出された）および一時パスワード（ユーザのパスワードのハッシュ関数およびクライアント・チャレンジから導き出された）を使用してホットスポット１０９にサインインする。

この一時ユーザ名は、トークン応答に含められた形式指定子に応じて形式指定される。一時ユーザ名の形式は、ホットスポット１０９のプロバイダが、料金請求相手の身元を特定することを可能にする。

クライアント１１０が、ＷＩＳＰｒの推奨事項に準拠してホットスポット１０９にサインインする。アクセス・マネージャ３２４が、知られているコンテンツの所定のファイルを取り出すために、ＡＰ１０８経由でｈｔｔｐ要求を送信しようと試みる。ホットスポット１０９が、その要求をホットスポット・プロバイダのログイン・サーバ（図示せず）にリダイレクトする。ログイン・サーバにリダイレクトされたことに応答して、アクセス・マネージャ３２４は、ログイン・サーバにサインインするために一時ユーザ名および一時パスワードを供給するように構成される。

ステップＳ４２８で、ホットスポット１０９が、その一時ユーザ名の形式（例えば、その一時ユーザ名が、料金請求相手を示すプレフィックスを有する）から、そのログイン要求がパケット・ベースの通信システムの料金請求相手に関連することを特定し、料金請求要求をホットスポットのリモート・オーセンティケーション・ダイヤル・イン・ユーザ・サービス（「ＲＡＤＩＵＳ」）サーバ１３６に転送する。

ホットスポットのＲＡＤＩＵＳサーバ１３６においてログイン要求を受信したことに応答して、ホットスポットのＲＡＤＩＵＳサーバ１３６は、その一時ユーザ名の形式から、そのログイン要求がパケット・ベースの通信ネットワークに関連することを特定する。ステップＳ４３０で、ホットスポットのＲＡＤＩＵＳサーバ１３６が、その一時ユーザ名と、その一時パスワードとを備える許可クエリを通信クライアント・ソフトウェア・プロバイダのＲＡＤＩＵＳサーバ１３８に送信する。

通信クライアント・ソフトウェア・プロバイダのＲＡＤＩＵＳサーバ１３８が、その一時ユーザ名および一時パスワードを受信する。ステップＳ４３１およびＳ４３２で、通信クライアント・ソフトウェア・プロバイダのＲＡＤＩＵＳサーバ１３８が、アクセスＤＢ１３０の中に格納された資格証明を検証すると、ステップＳ４３３で、サーバ１３８は、「アクセス受け付け」メッセージまたは「アクセス拒否」メッセージでホットスポットのＲＡＤＩＵＳサーバ１３６に応答する。「アクセス受け付け」メッセージは、その一時ユーザ名を使用してセッションを識別し、また、最短値３０分間から計算される、またはクレジットを１分当たりの費用で割った値から計算される許可セッション時間の長さを定義することが可能である。

「アクセス受け付け」メッセージが受信されたものと想定すると、ステップＳ４３４で、ホットスポットのＲＡＤＩＵＳサーバ１３６は、ホットスポット１０９に許可メッセージを送信する。許可メッセージを受信したことに応答して、ステップＳ４３６で、ホットスポット１０９は、クライアント１１０がインターネットにアクセスすることを許可し、ログインが成功したことをクライアント１１０に知らせる。

アクセス・マネージャ３２４が、ログインが成功したことをクライアント１１０（の他の要素）に知らせる。ＡＰ１０８との接続中、アクセス・マネージャ３２４は、端末装置がネットワークに接続されていることをユーザに知らせるようクライアント３２２ＵＩを制御する。

前述の説明において、支払いパケットは、以下のいくつの重要な違いを伴って、セッション作成パケットと同一のパターンに従う。すなわち、
（１）異なるＲＳＡキーが使用される。
（２）コマンドに加えて、ｃｍｄｉｄも平文で送信される。
（３）応答は、暗号構成要素が応答しない場合、ｃｏｍｍａｎｄフィールド、ｃｍｄｉｄフィールド、およびｒｅｓｕｌｔ ｃｏｄｅフィールドだけが埋められて着信する可能性がある。

パスワード・ハッシュは、トークン要求において使用されるのと同一のハッシング・スキームを使用する。パスワード・ハッシュは、公開ＲＳＡキーの最初の１６バイトがさらにハッシュされる、二重ハッシュされたユーザ名／Ｓｋｙｐｅｒ／パスワード・ハッシュである。このことは、そのハッシュを、使用されているＲＳＡキーが有効である間だけしか使用可能でないようにする。

他の要求の場合と同様に、支払いメッセージの中で、コマンド・コード、初期化ベクトル、コマンドＩＤ、および結果コードが、平文で送り返される一方、応答の残りの部分は、暗号化される。

Claims (10)

1. 制限された接続環境において通信ネットワークを介してユーザ端末装置から解読構成要素にデータを送信する方法であって、
   前記ユーザ端末装置において、
   前記ユーザ端末装置におけるユーザからデータを受け取るステップと、
   前記データが機密性のあるデータであると判定された場合、前記機密性のあるデータを、セキュリティで保護された暗号化キーを使用して暗号化するステップと、
   トンネリング・プロトコルに準拠してパケットを生成するステップであって、前記パケットが、ネットワーク構成要素のアドレスと、コマンド・データと、前記暗号化された機密性のあるデータとを含み、前記コマンド・データが、コマンドと、コマンド識別子とを含み、前記コマンドが、前記セキュリティで保護された暗号化キーが前記機密性のあるデータを暗号化するのに使用されていることを識別する、ステップと
   を備える方法。
2. 前記データがセッション・データであると判定された場合、前記セッション・データが、セッション暗号化キーを使用して暗号化され、さらに前記コマンドが、前記セッション・データを暗号化するのに前記セッション暗号化キーが使用されていることを識別する請求項１に記載の方法。
3. 前記コマンド・データが平文である請求項１または請求項２に記載の方法。
4. 前記機密性のあるデータが、アクセス・データまたは支払いデータを備える請求項１から３のいずれかに記載の方法。
5. 少なくともセキュリティで保護されたデータまたはセッション・データを入力するようユーザを促すように構成されたユーザ・インターフェースを有するユーザ端末装置であって、
   前記データを受信するステップと、
   前記データがセキュリティで保護されたデータであるか、またはセッション・データであるかを判定するステップと、
   前記セキュリティで保護されたデータをセキュリティで保護された暗号化キーで暗号化し、または前記セッション・データをセッション・キーで暗号化するステップと、
   平文のコマンド・データと、前記暗号化されたデータとを備えるパケットを生成するステップであって、前記コマンド・データが、コマンドと、コマンド識別子とを備え、前記コマンドが、前記セキュリティで保護されたキーが使用されているか、または前記セッション・キーが使用されているかを識別する、生成するステップと
   を実行する命令コードを含むコンピュータ・プログラムを実行するように構成されたプロセッサを備えるユーザ端末装置。
6. 通信ネットワークにおいて使用するためのネットワーク構成要素であって、
   通信ネットワークを相手にパケットを交換するための第１のポートと、
   セキュリティで保護された環境において、解読構成要素を相手にパケットを交換するための第２のポートと、
   前記第１のポートからパケットを受信することであって、前記パケットが、暗号化されたデータと、コマンドおよびコマンド識別子を含むコマンド・データとを包含する、受信すること、
   前記コマンドを読み取り、前記データを暗号化するのにセキュリティで保護されたキーが使用されているか、またはセッション・キーが使用されているかを判定すること、
   前記セッション・キーが使用されている場合、前記データを解読して、前記データに従って動作すること、および、
   前記セキュリティで保護されたキーが使用されている場合、前記パケットを前記第２のポートに転送し、応答と、前記コマンド識別子とを含む応答パケットを、前記第１のポート経由で送信すること
   を行うコンピュータ・プログラムを実行するように構成されたプロセッサと
   を備えるネットワーク構成要素。
7. 前記プロセッサが、解読構成要素から応答を受信し、さらに前記受信された応答を前記応答パケットに含めるように構成される請求項６に記載のネットワーク構成要素。
8. 前記プロセッサが、前記ネットワーク構成要素によって生成された応答を含む応答パケットを生成するように構成される請求項６に記載のネットワーク構成要素。
9. 前記プロセッサが、解読構成要素から応答が全く受信されない場合、前記ネットワーク構成要素において前記応答を生成するように構成される請求項８に記載のネットワーク構成要素。
10. プロセッサによって実行されると、請求項１から４のいずれか一項に記載の方法のステップを実行するプログラム・コード手段を備えるコンピュータ・プログラム製品。

Images