JP5208920B2 - 安全な伝送システム及び方法 - Google Patents

Description

本発明は、ピアツーピアの通信システムで特に利用されるが排他的に利用されるものではない、安全な伝送システム及び方法に関する。

ピアツーピアの通信システムにより、パソコンなどのデバイスのユーザは、インターネットなどのコンピュータネットワークにおいて電話を通話することができる。固定回線や携帯電話ネットワークなどの従来の電話網よりも、これらのシステムはコストが非常に低いことが多いので、これらのシステムはユーザにとって有益である。このことは特に遠距離通話に当てはまり得る。これらのシステムは、これらのサービスを為す（例えば、インターネットなどの）現存のネットワークにおいてボイスオーバーアイピープロトコル（“ＶｏＩＰ”）を利用する。但し、別のプロトコルも利用可能である。ピアツーピア電話サービスを利用するため、ユーザは、自分達のデバイスにクライアントソフトウエアをインストールし実行させなければならない。クライアントソフトウエアは、ＶｏＩＰ接続、及び、登録や認証などの他の機能を提供する。

同じピアツーピアシステムの他のユーザへの通話などの、ピアツーピア電話ネットワークでの通話は、ユーザが自由にできることがある。しかしながら、固定回線電話や携帯電話などへの他の通話では、ユーザはサービスに対して支払いを要求され得る。従って、このことは、ユーザがシステムに対して機密情報を与えることを要求し、それゆえにそのようなデータの伝送のための高レベルのセキュリティを要求する。多くのピアツーピア電話システムは、プリペイド式の課金システムを運営している。これらのシステムでは、ユーザは、口座に入金するために、支払いサービスプロバイダに機密情報を安全に伝送しなければならず、このクレジットは通話が為される間利用される。クレジットが無効になると、ユーザは、サービスを継続して利用するために、支払いサービスプロバイダに対して機密情報を再び安全に伝送してより多くの金を入金せねばならない。別のシステムでは、ユーザは、一定期間自分の為した通話の量に対して請求書を送られ、若しくは、為した通話の数に関わりなく、固定の支払いを為すように要求される。

現存のピアツーピア電話システムでは、ウエブブラウザプログラムを開き電話システムオペレータのサイトへナビゲートすることにより、ユーザは、支払いサービスプロバイダへ機密データを安全に伝送できる。このウエブページから、ユーザは口座へ支払いするリンクを選択できる。ユーザは、ウエブページへクレジットカード若しくは他の支払い情報を入力できる。ウエブブラウザは、支払いサービスプロバイダへ機密データを送るための周知の安全なプロトコルを利用できる。この方法の不便な点は、支払いをするためにユーザが自分達の端末上で独立のプログラム（例えば、ウエブブラウザ）を開くことを要求されることである。ユーザは、正しいページに到達するまでにウエブページの複数回のクリックを経由して進むことも要求され得る。更に、ユーザは、その支払いを為すために、ワールドワードウエブへアクセスしなければならない。じかしながら、ユーザが安全上の理由のためにウエブにアクセスすることを妨げられるが、依然別途ピアツーピア電話サービスを利用できるような状況もある。

有用性の観点から、電話システムのユーザがユーザの端末上で稼動するクライアントソフトウエアから直接に、サービスに対する支払いを安全に為しうることが望ましい。これは、ユーザがクライアントプログラムを電話サービスと直接に関連付けることになるからである。更に、クライアントプログラムの内部から安全な支払いができれば、サービスに対して機密情報を安全に伝送するために、ユーザが他のプログラムをオープンする必要が回避され得るからである。例えば、前述のように、ユーザがインターネットを介して機密情報を伝送する必要があれば、ユーザは自分の端末上でブラウザをオープンし、支払いの経路であるウエブサイトの正確なアドレスを支払いの詳細を入力する前に入力することを、要求され得る。この手続はユーザのエラーを招きがちであり、ユーザの側のフラストレーションと成り得る。更に、ウエブサイトページ上に機密情報を入力することに懐疑的であるため、電話サービスのオペレータに、クライアントソフトウエア内により高い信用レベルを与えさせる、ユーザもいる。しかしながら、クライアントはユーザの識別を既に知っており、従って更なるユーザ名及びパスワードをユーザに促すことなくこの情報は支払いプロバイダに渡され、ユーザのための支払い処理が簡単になされてしまう。

しかしながら、機密情報に関する、ネットワークにおいて伝送される情報は安全でなければならない。特に、機密情報は復号化されるべきではない。機密情報を送信する従来のやり方は、ＨＴＴＰセキュアなどの、ハイパーテキストトランスファプロトコル（“ＨＴＴＰ”）を利用するものであり、それは、セキュアソケットレイヤ（ＳＳＬ）若しくはトランスポートレイヤセキュリティ（ＴＬＳ）プロトコルのバージョンを利用してデータを暗号化するものである。しかしながら、クライアントソフトウエアから送られるＨＴＴＰメッセージは看破しブロックするのが容易であり、結局、ＨＴＴＰメッセージや暗号化データの配布は失敗してしまう。ＨＴＴＰメッセージや暗号化データメッセージの看破及びブロックは、サードパーティ若しくはファイヤウオールなどにより為され得る。例えば、セキュリティリスクとして任意のウエブページにアクセスしＨＴＴＰをブロックする可能性を見る会社もある。しかしながら、電話サービスプロバイダは、そのコンテンツが信用あるソースから取得されるので、セキュリティリスクを装うことはない。更に、ピアツーピア電話サービスそのものをブロックすることを望む会社やサードパーティも存在する。実際の電話トラフィックは看破が困難であり、クライアントはそのタスクを実施する特定のＨＴＴＰリクエストを作成し得る。そうすると、これらのリクエストは看破され、クライアントを稼動する端末が処理を終了し、リクエストはブロックされる。

従って、ローカルクライアントからウエブベースサービスプロバイダへの機密情報の伝送を可能にする、インターネットなどのネットワーク内の安全な伝送システム及び方法に対する要求が、存在する。

本発明の一つの形態によると、通信ネットワークにおいてユーザから第１のネットワークエンティティへ情報を伝送する方法が提示され、該方法は、
上記ユーザがユーザ端末で実行されるブラウザの中に情報を入力するステップと、
上記ブラウザがネットワークポートを介してネットワークにおいてディスパッチするため第１の通信プロトコルを用いて、上記情報を含み、上記第１のネットワークエンティティの識別子を含む第１のメッセージを生成するステップと、
上記第１のメッセージが上記ネットワークポートに到着する前に、上記ユーザ端末で実行されるクライアントにて上記第１のメッセージを受けるステップと、
上記クライアントと第２のネットワークエンティティの間で伝送するのに利用される第２の通信プロトコルの第２のメッセージに、上記第１のメッセージをラップするステップと、
上記通信ネットワークを渡って、上記第２のメッセージを上記第２のネットワークエンティティに伝送するステップと、
上記第２のネットワークエンティティにて上記第２のメッセージから上記第１のメッセージをアンラップし、上記第１のネットワークエンティティの上記識別子を上記第１のネットワークエンティティのネットワークアドレスに翻訳し、上記通信ネットワークを渡って上記第１のメッセージを上記第１のネットワークエンティティに伝送するステップと
を含む。

一つの実施形態では、上記方法は、更に、上記クライアントにて上記第１のメッセージを受けるステップの後に、上記第１のメッセージ内の上記情報を暗号化するステップを含む。別の実施形態では、上記方法は、更に、上記第２のネットワークエンティティにより伝送される上記第１のメッセージを上記第１のネットワークエンティティにて受けるステップを含む。別の実施形態では、上記方法は、更に、上記第１のメッセージが上記第１のネットワークエンティティにて受けられた後に、上記第１のメッセージ内の上記情報を復号化するステップを含む。別の実施形態では、上記暗号化するステップは、上記第１のネットワークエンティティにより与えられる暗号化キーを用いて実施される。別の実施形態では、上記方法は、更に、上記第１のネットワークエンティティが、上記暗号化キーを上記第２のネットワークエンティティに周期的に伝送するステップを含む。

別の実施形態では、上記方法は、更に、
上記第１のメッセージを受けたことに応じて、上記第１のネットワークエンティティから上記第２のネットワークエンティティに第３のメッセージを伝送するステップと、
上記第２のネットワークエンティティにて上記第３のメッセージを受け、このことに応じて、サーバからウエブページをフェッチするステップと、
上記ウエブページを上記第２の通信プロトコルの第４のメッセージ内にラップするステップと、
上記通信ネットワークを渡って上記第４のメッセージを上記クライアントに伝送するステップと、
上記クライアントにて上記第４のメッセージから上記ウエブページをアンラップして上記ウエブページを上記ブラウザに通すステップと、
上記ウエブページを上記ブラウザ内で上記ユーザに表示するステップと
を含む。上記第３のメッセージがリダイレクトメッセージであってもよい。

別の実施形態では、第２の通信プロトコルの第２のメッセージに、上記第１のメッセージをラップする上記ステップが、上記第１のメッセージにヘッダ及びフッタを付加するステップを含む。

上記第１の通信プロトコルが、ハイパーテキストトランスファプロトコルであってもよい。上記第１のネットワークエンティティが、支払いサービスプロバイダであってもよい。上記通信ネットワークが、インターネットであってもよい。上記第２のネットワークエンティティが、スカイプバックエンドサーバであってもよい。上記情報が支払い情報であってもよい。

本発明の別の形態によると、通信ネットワークを渡ってユーザから第１のネットワークへ情報を伝送するシステムが提示される。該システムは、
ユーザ端末で実行されるブラウザであって、上記ユーザにより入力される情報を受ける手段と、ネットワークポートを介してネットワークを渡ってディスパッチするため第１の通信プロトコルを用いて、上記情報を含み、上記第１のネットワークエンティティの識別子を含む第１のメッセージを生成する手段を含む、ブラウザと、
上記ユーザ端末で実行されるクライアントであって、上記第１のメッセージが上記ネットワークポートに到着する前に上記クライアントにて上記第１のメッセージを受ける手段と、上記クライアントと第２のネットワークエンティティの間で伝送するのに利用される第２の通信プロトコルの第２のメッセージ内に上記第１のメッセージをラップする手段と、上記通信ネットワークを渡って上記第２のメッセージを上記第２のネットワークエンティティに伝送する手段とを含む、クライアントと、
上記第２のネットワークエンティティにて上記第２のメッセージから上記第１のメッセージをアンラップする手段と、上記第１のネットワークエンティティの上記識別子を上記第１のネットワークエンティティのネットワークアドレスに翻訳する手段と、上記通信ネットワークを渡って上記第１のメッセージを上記第１のネットワークエンティティに伝送する手段とを含む、上記第２のネットワークエンティティと
を含む。

一つの実施形態では、上記クライアントが、更に、上記クライアントにて上記第１のメッセージを受けた後に、上記第１のメッセージ内の上記情報を暗号化する手段を含む。別の実施形態では、上記第１のネットワークエンティティが、更に、上記第２のネットワークエンティティにより伝送される上記第１のメッセージを受ける手段を含む。別の実施形態では、上記第１のネットワークエンティティが、更に、上記第１のメッセージが上記第１のネットワークエンティティにて受けられた後に、上記第１のメッセージ内の上記情報を復号化する手段を含む。別の実施形態では、上記暗号化は、上記第１のネットワークエンティティにより与えられる暗号化キーを用いて実施される。別の実施形態では、上記第１のネットワークエンティティは、更に、上記暗号化キーを上記第２のネットワークエンティティに周期的に伝送する手段を含む。

別の実施形態では、更に、上記第１のネットワークエンティティは、上記第１のメッセージを受けたことに応じて、上記第２のネットワークエンティティに第３のメッセージを伝送する手段を含む。別の実施形態では、更に、上記第２のネットワークエンティティは、上記第３のメッセージを受け、このことに応じて、サーバからウエブページをフェッチする手段と、上記ウエブページを上記第２の通信プロトコルの第４のメッセージ内にラップする手段と、上記通信ネットワークを渡って上記第４のメッセージを上記クライアントに伝送する手段とを含む。別の実施形態では、更に、上記クライアントは、上記第４のメッセージから上記ウエブページをアンラップして上記ウエブページを上記ブラウザに通す手段を含む。別の実施形態では、更に、上記ブラウザは、上記ウエブページを上記ユーザに表示する手段を含む。上記第３のメッセージがリダイレクトメッセージであってもよい。

別の実施形態では、第２の通信プロトコルの第２のメッセージに、上記第１のメッセージをラップする上記手段が、上記第１のメッセージにヘッダ及びフッタを付加する手段を含む。

上記第１の通信プロトコルが、ハイパーテキストトランスファプロトコルであってもよい。上記第１のネットワークエンティティが、支払いサービスプロバイダであってもよい。上記通信ネットワークが、インターネットであってもよい。上記第２のネットワークエンティティが、スカイプバックエンドサーバであってもよい。上記情報が支払い情報であってもよい。

本発明の別の形態によると、ユーザ端末が提示される。該ユーザ端末は、
上記ユーザ端末で実行されるブラウザであって、上記ユーザにより入力される情報を受ける手段と、ネットワークポートを介してネットワークを渡ってディスパッチするため第１の通信プロトコルを用いて、上記情報を含み、第１のネットワークエンティティの識別子を含む第１のメッセージを生成する手段を含む、ブラウザと、
上記ユーザ端末で実行されるクライアントであって、上記第１のメッセージが上記ネットワークポートに到着する前に上記クライアントにて上記第１のメッセージを受ける手段と、上記クライアントと第２のネットワークエンティティの間で伝送するのに利用される第２の通信プロトコルの第２のメッセージ内に上記第１のメッセージをラップする手段と、上記通信ネットワークを渡って上記第２のメッセージを上記第２のネットワークエンティティに伝送する手段とを含む。

本発明の別の形態によると、ネットワークエンティティが提示される。該ネットワークエンティティは、
ユーザ端末にて実行されるクライアントにより通信ネットワークを渡って上記ネットワークエンティティに伝送された第２の通信プロトコルの第２のメッセージから、更なるネットワークエンティティの識別子を含む、第１の通信プロトコルの第１のメッセージをアンラップする手段と、
上記の更なるネットワークエンティティの上記識別子を上記の更なるネットワークエンティティのネットワークアドレスに翻訳する手段と、
上記通信ネットワークを渡って上記第１のメッセージを上記の更なるネットワークエンティティに伝送する手段と
を含む。

本発明の別の形態によると、コンピュータの中にロードされると、上述の方法を実行するように上記コンピュータを制御するプログラムコード手段を含むコンピュータプログラムプロダクトが提示される。

ローカルクライアントからウエブベースサービスプロバイダへの機密情報の伝送を可能にする、インターネットなどのネットワーク内の安全な伝送システム及び方法が実現される。

まず、図１を参照すると、支払いサービスプロバイダへの情報の安全な伝送を伴うピアツーピア電話システム１００が示される。

ユーザ端末１０２は、ネットワーク１０４に接続して示される。ユーザ端末は、例えば、パーソナルコンピュータ、パーソナルデジタルアシスタント、適宜利用可能な携帯電話、若しくはネットワーク１０４に接続可能な他のデバイスであればよい。ユーザ端末１０２は、ネットワークポート１０５を介してネットワーク１０４に接続されるが、ケーブル（有線）接続でも無線接続を介してもよい。ネットワーク１０４はインターネットなどのネットワークであればよい。

ユーザ端末１０２のユーザ１０６は、ネットワーク１０４を渡って、第２のユーザ端末１１０の第２のユーザ１０８に電話を掛け得る。ユーザ端末は、ピアツーピア電話システムのオペレータにより与えられるクライアント１１２を稼動する。クライアント１１２は、ユーザ端末１０２内のローカルプロセッサで実行されるソフトウエアプログラムである。通話を開始するにあたり、ユーザ１０６は、クライアント１１２内に表示された、第２のユーザ１０８のためにリストされるコンタクトをクリックし得る。又は、ユーザ１０６は、第２のユーザ１０８の電話番号又はユーザ名をタイプし得る。するとクライアント１１２は第２のユーザ１０８への通話を設定する。通話は、特許文献１（ＷＯ２００５／００９０１９）に開示されるような周知の方法により、ＶｏＩＰを用いて為され得る。通話は、音声、映像、インスタントメッセージ（ＩＭ）、若しくはそれらの組み合わせを含み得る。

第２のユーザ端末１１０は、（図１に示すように）ネットワーク１０４に直接接続してもよく、公衆交換電話網（ＰＳＴＮ）や（図１に示されない）携帯電話ネットワークなどの異なるネットワークに接続してもよい。第２のユーザ端末がネットワーク１０４に接続していれば、第２のユーザ端末は、第１のユーザ端末１０２で稼動するクライアント１１２と同様に、電話システムのオペレータにより与えられるクライアントプログラム１１４を稼動し得る。ＰＳＴＮに接続していれば、第２のユーザ端末は固定回線電話であり、携帯電話ネットワークに接続していれば、第２のユーザ端末は携帯電話である。

通話ができるようにするために、ユーザ１０６は適切に登録され認証されなければならない。更に、ユーザ１０６は、電話サービスに対しても支払いができなければならない。従って、機密支払い情報は、ネットワーク１０４を渡って、ユーザ１０６から支払いサービスプロバイダ（ＰＳＰ）に伝送される必要がある。支払い情報は機密の性質を有するから、支払いシステムは非常に安全である必要がある。電話システムサーバを介して機密情報が流れれば、システムは、クレジットカード会社により強制される支払いカード業界（ＰＣＩ）のルールに適合しなければならない。これらのルールに適合することは、費用がかかり時間もかかる。更に、電話システムのサーバが機密支払い情報を格納していれば、それらはハッカによる攻撃のターゲットに成り得る。それゆえ、機密情報に曝されＰＣＩ遵守の必要があるシステムのエンティティの数を減少することには、大変な利益がある。更に、機密情報の安全な伝送は、ユーザの見地からは、できるだけ簡素で有用である必要がある。

前述のように、ユーザ端末１０２上で稼動するクライアント１１２を直接利用してサービスのための支払いを安全にできることは、電話システムのユーザにとって非常に容易なことである。更に、こうすることで、クライアントは、ＰＣＩ遵守する必要がある電話システムの唯一の部分となる。後で説明するように、システムの残部は暗号化された情報を見るのみであり、情報内容についての知覚はない。従って、システムの残部は、機密情報を直接に取り扱うものではなくＰＣＩ遵守する必要もない。クライアントをＰＣＩ遵守させる費用は、安全なサーバ環境を維持するよりも、桁違いに低くなる。図１は、ユーザ１０６がクライアント１１２を介して電話サービスに対して安全に支払いできるシステム１００内のエンティティを示す。ユーザ１０６は、支払いサービスプロバイダ１１６に支払いを為す。ＰＳＰ１１６は、ネットワーク１０４に接続されるプライベートネットワークであり、ＰＳＰプロキシ１１８とＰＳＰウエブアプリケーション１２０を含み得る。ＰＳＰプロキシ１１８はサーバ内のプロセッサで稼動するソフトウエアプログラムであり、ＰＳＰウエブアプリケーション１２０とネットワーク１０４の間を接続し、情報がＰＳＰウエブアプリケーション１２０に示される前の情報の復号化に関与する。ＰＳＰウエブアプリケーション１２０はサーバ内のプロセッサで実行されるソフトウエアアプリケーションである。ＰＳＰプロキシ１１８及びＰＳＰウエブアプリケーション１２０は、別のサーバに配置されてもよく、同じサーバで稼動してもよい。ＰＳＰ１１６は、電話サービスとは異なるオペレータにより動作されてもよい。

スカイプ（Ｓｋｙｐｅ）バックエンドサーバ１２２とスカイプ（Ｓｋｙｐｅ）ウエブアプリケーション１２４が、ネットワーク１０４に接続されてもよい。スカイプバックエンドサーバ１２２とスカイプウエブアプリケーション１２４は、電話システムのオペレータのプライベートネットワーク１２８の内部に配置され得る。スカイプバックエンドサーバ１２２とスカイプウエブアプリケーション１２４は、地理的に同一場所に配置されてもよく、地理的に分離されてもよい。スカイプバックエンドサーバ１２２は、スカイプウエブアプリケーション１２４とネットワーク１０４の間に配置され、スカイプウエブアプリケーション１２４とクライアント１１２との間のメッセージ交換に関与する。スカイプバックエンド１２２とクライアント１１２は、著作権のあるスカイププロトコルを利用して通信し、ＨＴＴＰを使わない。これは、前述のように、サードパーティやファイヤウオールによるＨＴＴＰメッセージや暗号化データメッセージの看破及びブロックを回避するためである。更に、スカイプバックエンド１２２は、ＨＴＴＰをブロックもする。

ユーザ端末１０２は、クライアント１１２に加えて、ウエブブラウズソフトウエア１３０をインストールしている。ウエブブラウザ１３０は、クライアント１１２のユーザインターフェースの一部として利用可能であり、ハイパーテキストマークアップラングエージ（ＨＴＭＬ）ウエブページをユーザ１０６に表示するように、クライアント１１２により制御され得る。

図１に示すシステム１００の動作を、図２Ａ−図２Ｅを参照して記載する。図２Ａを参照して、この図は、クライアント１１２における暗号キー情報の維持を示す。ステップＳ１では、スカイプウエブアプリケーション１２４は、新しいバージョンの公開キーのためにＰＳＰウエブアプリケーション１２０に周期的に問い合わせる。ステップＳ１のメッセージは、ＰＳＰウエブアプリケーションに配置されるキーのユーアールエル（ＵＲＬ）を特定するＨＴＴＰゲットリクエストのフォームである。このリクエストに応答して、ＰＳＰウエブアプリケーション１２０は、ステップＳ２で公開キーをスカイプウエブアプリケーション１２４に戻す。上記２ステップは、周期的に、他の動作から独立して実施され、スカイプウエブアプリケーション１２４が常時公開キーの最新コピーを有することを保証する。

クライアント１１２は、ステップＳ３で、新しいバージョンの公開キーのためにスカイププロトコルを用いてスカイプバックエンド１２２を周期的にポーリングする。スカイプバックエンドサーバ１２２は、ステップＳ４にて、スカイプウエブアプリケーション１２４に格納されたキーのＵＲＬを特定するＨＴＴＰゲットリクエストのフォームで、リクエストをスカイプアプリケーション１２４に進める。スカイプアプリケーション１２４は、ステップＳ５にて、キーをスカイプバックエンドサーバ１２２に戻し、これはステップＳ６にて、スカイププロトコルを利用してクライアント１１２に渡される。上記４ステップは、キー情報がクライアント１１２内で常時最新のものになるように、その動作をユーザに気付かれることなく、周期的に実施される。

従って、図２Ａのステップの結果として、クライアント１１２は、以下でより詳細に説明するように、支払いのプロセスで利用するＰＳＰウエブアプリケーション１２０の公開キーの最新のコピーを有する。

図２Ｂは、支払いプロセスを開始するユーザ１０６を示す。ステップＳ７では、ユーザ１０６は、クライアント１１２で表示された、（他のラベリングも可能であるが）“スカイプクレジット購入”とラベルされたボタンをクリックし、支払いプロセスが開始されたことをクライアント１１２に示す。ステップＳ８では、クライアント１１２は、ウエブブラウザ１３０制御を開始し、そこではクライアントはクライアントユーザインターフェース内部のウエブブラウザをオープンし、完了すると、ステップＳ９にて信号がクライアントに戻される。

“スカイプクレジット購入”ボタンと関連して、例えば、ＵＲＬは“ｎｏｎｓｅｃｕｒｅ：／／ｓｋｙｐｅ／ｂｕｙｃｒｅｄｉｔ．ｈｔｍｌ”のフォームとなる。これは、ページ“ｂｕｙｃｒｅｄｉｔ．ｈｔｍｌ”がウエブブラウザ１３０内でユーザ１０６に表示される、サーバ“ｓｋｙｐｅ”からページ“ｂｕｙｃｒｅｄｉｔ．ｈｔｍｌ”を検索するリクエストである。このリクエストは、標準的な“ｈｔｔｐ：／／”では始まらず、マーカストリング“ｎｏｎｓｅｃｕｒｅ”を利用する。“ｎｏｎｓｅｃｕｒｅ：／／ｓｋｙｐｅ／ｂｕｙｃｒｅｄｉｔ．ｈｔｍｌ”などのリクエストは、標準的なＨＴＴＰリクエストと同じ機能を有するが、ストリング“ｎｏｎｓｅｃｕｒｅ”により、クライアント１１２はリクエストをインターセプトし為されるべきアクションを判定できる。換言すると、“ｎｏｎｓｅｃｕｒｅ”は、クライアント１１２がリクエストをインターセプトするときに利用するマーカとして、作用する。クライアント１１２が“ｎｏｎｓｅｃｕｒｅ”を利用するリクエストを作成する試みを見るときは、クライアント１１２は、リクエストが機密情報を含んでいないこと、及び、リクエストはスカイプバックエンドサーバ１２２に送られ得ること（後で説明するように、更なるマーカ“ｓｅｃｕｒｅ”も利用される）、を知っている。

ステップＳ１０にて、クライアント１１２は、“ｎｏｎｓｅｃｕｒｅ”リクエストメッセージをスカイプ専用通信プロトコルメッセージの中にラップし、これはスカイプバックエンドサーバ１２２に送られる。メッセージを受けると、スカイプバックエンドサーバ１２２は、スカイプ専用通信プロトコルメッセージから“ｎｏｎｓｅｃｕｒｅ”リクエストをアンラップする。安全及び維持管理上の理由のために、リクエストは任意のサーバへのレファレンスのみ含み、実際のサーバアドレス及びポートを含まない。例えば、リクエスト“ｎｏｎｓｅｃｕｒｅ：／／ｓｋｙｐｅ／ｂｕｙｃｒｅｄｉｔ．ｈｔｍｌ”はサーバ“ｓｋｙｐｅ”へのレファレンスのみ含み、実際のサーバアドレスを含まない。従ってスカイプバックエンドサーバ１２２は、サービス名への任意のレファレンスを解明してウエブサーバアドレスとする必要がある。このことは、サーバとサーバアドレス間の対応テーブルを維持することにより、達成される。スカイプバックエンドサーバ１２２のみが、レファレンスとサーバアドレス間のマッピングテーブルを維持する。スカイプバックエンドサーバ１２２は、クライアント１１２からのメッセージを解明してウエブサーバアドレスを取得する。例えば、“ｎｏｎｓｅｃｕｒｅ：／／ｓｋｙｐｅ／ｂｕｙｃｒｅｄｉｔ．ｈｔｍｌ”内の“ｓｋｙｐｅ”へのレファレンスは解明されて、“ｈｔｔｐ：／／ｗｅｂｓｔｏｒｅ．ｓｋｙｐｅ．ｃｏｍ”となる。続いてスカイプバックエンドサーバ１２２は、解明されたアドレスと“ｎｏｎｓｅｃｕｒｅ”リクエストの残部とを用いて、新しいＨＴＴＰリクエストを構築する。その結果、例えば、“ｈｔｔｐ：／／ｗｅｂｓｔｏｒｅ．ｓｋｙｐｅ．ｃｏｍ／ｂｕｙｃｒｅｄｉｔ．ｈｔｍｌ”となる。

このＨＴＴＰリクエストは、ステップＳ１１にて、上記ＨＴＴＰゲットリクエストのフォームでスカイプウエブアプリケーション１２４の解明されたロケーションに進められ、リクエストされたページは、ステップＳ１２にて、ＨＴＭＬのフォームでスカイプウエブアプリケーションにより戻される。スカイプバックエンド１２２は、ステップＳ１３にて、スカイプウエブアプリケーションからのＨＴＭＬレスポンスをスカイププロトコル内にラップして、ページをクライアント１１２に進める。これは、ステップＳ１４にて、スカイププロトコルからアンラップされウエブブラウザ１３０に送られ、続いてステップＳ１５にて、ユーザ１０６に表示される。

ステップＳ１６にて、ユーザ１０６は、ウエブブラウザ１３０ウインドウ内のページを見て、“開始”とラベルされたリンクをクリックする。このリンクは、例えば、ＵＲＬ“ｎｏｎｓｅｃｕｒｅ：／／ｓｋｙｐｅ／ｇｅｔｓｔａｒｔｅｄ．ｈｔｍｌ”へのリンクである。クライアント１１２は、ステップＳ１７にて、“ｎｏｎｓｅｃｕｒｅ”リクエスト（ＨＴＴＰゲットリクエストのタイプ）を作成するウエブブラウザの試みをインターセプトし、リンクされたウエブページへ進む。クライアント１１２は、ステップＳ１８にて、“ｎｏｎｓｅｃｕｒｅ”リクエストメッセージをラップしてスカイプ専用通信プロトコルメッセージの中に入れ、これはスカイプバックエンド１２２に送られる。スカイプバックエンド１２２は、ステップＳ１０を参照して前述したのと同様にして、メッセージをアンラップし、クライアント１１２からのメッセージを解明しウエブサーバアドレスを取得する。続いてスカイプバックエンド１２２は、解明されたウエブサーバアドレスとアンラップされた“ｎｏｎｓｅｃｕｒｅ”リクエストから、ＨＴＴＰリクエスト、例えば、“ｈｔｔｐ：／／ｗｅｂｓｔｏｒｅ．ｓｋｙｐｅ．ｃｏｍ／ｇｅｔｓｔａｒｔｅｄ．ｈｔｍｌ”を作成する。ＨＴＴＰリクエストは、ステップＳ１９内で、スカイプウエブアプリケーション１２４の解明されたアドレスに進められる。スカイプウエブアプリケーション１２４は、ステップＳ２０にて、ウエブページ“ｇｅｔｓｔａｒｔｅｄ．ｈｔｍｌ”をスカイプバックエンド１２２に戻し、該スカイプバックエンド１２４は、ステップＳ２１にて、レスポンスをスカイププロトコル内にラップし、それをクライアント１１２に進める。これは、ステップＳ２２内で、アンラップされウエブブラウザ１３０ウインドウに渡され、ステップＳ２３内でユーザ１０６に表示される。

ユーザ１６に表示されるページは、初期の支払い情報を入力するフォームを含む。ステップＳ２４では、ユーザ１０６は、ページを見て、請求先アドレス、電子メールアドレス及び支払い方法などの、初期の支払い情報を埋め、“次”をクリックする。“次”ボタンは、ＵＲＬと関連付いており、例えば、それは“ｎｏｎｓｅｃｕｒｅ：／／ｓｋｙｐｅ／ｉｎｉｔｉａｌｆｏｒｍ．ｈｔｍｌ”である。ウエブブラウザは、ステップＳ２５にて、“ｎｏｎｓｅｃｕｒｅ：／／ｓｋｙｐｅ／ｉｎｉｔｉａｌｆｏｒｍ．ｈｔｍｌ？ａｄｄｒｅｓｓ＝ｘ＆ｍｅｔｈｏｄ＝ｙ”（ここで、“ａｄｄｒｅｓｓ＝ｘ”及び“ｍｅｔｈｏｄ＝ｙ”は、ユーザがフォームに入力する情報の例を示す）などの、フォームに入力される情報を含む或るタイプのＨＴＴＰポストリクエストを生成し、ネットワークポート１０５を介してメッセージをネットワーク１０４に伝送する。ウエブブラウザ１３０からのＨＴＴＰポストリクエストは、ネットワークポート１０５に着く前に、（“ｎｏｎｓｅｃｕｒｅ”マーカの利用を検知する）クライアント１１２に、受信される。クライアントは、ステップＳ２６にて、ＨＴＴＰポストリクエストをスカイププロトコルメッセージの中にラップし、このメッセージはスカイプバックエンドサーバ１２２に進められる。図３を参照して後でより詳細に説明するが、スカイププロトコル内にラップされると、メッセージ内に他の情報をクライアント１１２は含み得ることを、留意されたい。

スカイプバックエンドサーバ１２２はアンラップし、ＨＴＴＰポストリクエストメッセージを解明する。例えば、“ｎｏｎｓｅｃｕｒｅ：／／ｓｋｙｐｅ／ｉｎｉｔｉａｌｆｏｒｍ．ｈｔｍｌ？ａｄｄｒｅｓｓ＝ｘ＆ｍｅｔｈｏｄ＝ｙ”は解明されると、“ｈｔｔｐ：／／ｗｅｂｓｔｏｒｅ．ｓｋｙｐｅ．ｃｏｍ／ｉｎｉｔｉａｌｆｏｒｍ．ｈｔｍｌ？ａｄｄｒｅｓｓ＝ｘ＆ｍｅｔｈｏｄ＝ｙ”のフォームのＨＴＴＰメッセージとなる。続いてスカイプバックエンドサーバ１２２は、ステップＳ２７にて、支払いを開始するために、スカイプウエブアプリケーション１２４へ解明されたリクエストを送る。スカイプウエブアプリケーション１２４は、ステップＳ２８にて、ＰＳＰでの支払いを開始するために、初期支払い情報を含むメッセージをＰＳＰウエブアプリケーション１２０へ送る。ステップＳ２９にて、ＰＳＰウエブアプリケーション１２０は、情報を処理し、クレジットカード情報フォームなどの、支払い方法のための適切なフォームを含むウエブページのＵＲＬを戻す。スカイプウエブアプリケーション１２４はＵＲＬを受けてリダイレクトヘッダを作成する。リダイレクトヘッダは、ステップＳ３０にて、スカイプバックエンド１２２に送られる。

スカイプバックエンドサーバ１２２は、ステップＳ３１にて、リダイレクトヘッダからアドレスを解明しＰＳＰウエブアプリケーション１２０にリクエストを送り要求されたウエブページを取得する。続いてＰＳＰウエブアプリケーション１２０は、ステップＳ３２にて、（クレジットカード情報などの）支払い詳細のためのフォームを含むウエブページを戻す。このウエブページは、ステップＳ３３にて、続いてスカイププロトコルを用いてクライアント１１２に進められ、ステップＳ３４にてアンラップされてウエブブラウザ１３０に渡され、ステップＳ３５にてユーザ１０６に表示される。

図２Ｂに示される手続の結果として、ユーザ１０６はウエブブラウザ１３０内のフォームを提示されるが、ユーザはこのフォームの中にクレジットカード支払い情報を入力できる。この支払い情報は機密であり、従って安全に扱われなければならない。このことが為される方法は、図２Ｃを参照して見ることができる。

ステップＳ３６にて、ユーザ１０６は、（例えば、クレジットカード番号、有効期限若しくは他の情報などの）支払い情報を、ウエブブラウザ内に示されるＨＴＭＬフォーム内に入力し、“提出”ボタンをクリックする。“提出”ボタンはＵＲＬと関連付けられる。例えば、それは“ｓｅｃｕｒｅ：／／ｓｏｍｅｐｓｐ／ｃｒｅｄｉｔｃａｒｄｆｏｒｍ．ｈｔｍｌ”である。続いてウエブブラウザ１３０は、ステップＳ３７にて、マーカ“ｓｅｃｕｒｅ”を用いて（ポストＤａｔａのフォームの）支払い情報と上記ＵＲＬを含む或るタイプのＨＴＴＰポストリクエストを生成する。このＨＴＴＰポストリクエストは、例えば、“ｓｅｃｕｒｅ：／／ｓｏｍｅｐｓｐ／ｃｒｅｄｉｔｃａｒｄｆｏｒｍ．ｈｔｍｌ？ｃａｒｄｎｏ＝１２３４＆ｅｘｐｉｒｙｄａｔｅ＝０１０１２０１０”である（ここで、ｃａｒｄｎｏ＝１２３４、及びｅｘｐｉｒｙｄａｔｅ＝０１０１２０１０は、フォームに入力されたクレジットカード情報の例を示す。これは、読み取り易いようにゲット表記内に示されたポストリクエストであることに、留意されたい）。ウエブブラウザ１３０からのＨＴＴＰポストリクエストは、クライアント１１２によりインターセプトされ、ネットワーク１０４の中に送信されることが防がれる。特に、クライアントはマーカ“ｓｅｃｕｒｅ”を検知する。これは、（“ｎｏｎｓｅｃｕｒｅ”と同様に）クライアントがインターセプトすべきことだけでなく、メッセージ内の情報が暗号化されるべきことをクライアントに示す。

ステップＳ３８にて、ＨＴＴＰポストリクエストからのポストＤａｔａのフォームで、支払い情報が、（図２Ａに関して上述したようにクライアントに与えられる）ＰＳＰの公開キーを用いて、暗号化される。暗号化は、周知のように、標準的暗号化アルゴリズムを用いて為される。例えば、仮にポストＤａｔａが“ｃａｒｄｎｏ＝１２３４”や“ｅｘｐｉｒｙｄａｔｅ＝０１０１２０１０”などの情報を含むならば、これは暗号化されて、例えば、“ｐａｙｌｏａｄ＝３４２１４１２３ｄｄａｓｄａｓ”を伴う新しいＨＴＴＰポストリクエストのフォームとなる。続いてクライアントは、例えば、“ｓｅｃｕｒｅ：／／ｓｏｍｅｐｓｐ／ｃｒｅｄｉｔｃａｒｄｆｏｒｍ．ｈｔｍｌ？ｐａｙｌｏａｄ＝３４２１４１２３ｄｄａｓｄａｓ”などの暗号化されたペイロードを伴う新しいＨＴＴＰポストリクエストを形成する。続いてクライアント１１２は、暗号化された支払い情報を含むＨＴＴＰポストリクエストをスカイププロトコルフォーマットの中にラップする。更に、クライアント１１２は、スカイププロトコルメッセージ内に更なる情報を含む。更なる情報は、ユーザのスカイプ名や稼動するクライアント１１２のバージョンなどの、ユーザ情報や、端末及びユーザの識別などの、リクエストコンテクストに関する不正関連情報を含むコンテクスト情報を、含み得る。スカイププロトコルメッセージは、ステップＳ３９にて、クライアント１１２からスカイプバックエンドサーバ１２２に進められる。

スカイププロトコルメッセージ内にユーザ情報とコンテクスト情報を備えることには、更なる安全上の利点がある。これは、通常のウエブアクセスの場合、リクエストが生じる実際の端末の識別を隠すことは容易であるからであり、このことは（プロキシの利用により）ユーザの側で意図せず発生する。しかしながら、スカイププロトコルメッセージ内の情報は、リクエストを特定の端末と結ぶ（関連付ける）のであり、このことによりより大きな不正検知機構の利用が可能になる。更に、クライアント１１２はユーザの識別を既に知っており、従ってこの情報は、ＰＳＰウエブアプリケーションに渡され得るのであるが、このとき更なるユーザ名及びパスワードをユーザに促す必要がない。

スカイプバックエンド１２２は、暗号化された支払い情報を含むスカイププロトコルメッセージを受ける。スカイプバックエンド１２２は、スカイププロトコルメッセージをアンラップし、暗号化された支払い情報を含むＨＴＴＰポストリクエストを残す。スカイプバックエンド１２２は、ＰＳＰプロキシ１１８のサーバアドレスへのリクエスト内に含まれるレファレンスを解明する。例えば、“ｈｔｔｐ：／／ｗｗｗ．ｐｓｐ．ｃｏｍ”への“ｓｏｍｅｐｓｐ”のレファレンスを解明する。続いてスカイプバックエンド１２２は、ＰＳＰプロキシ１１８の解明されたサーバアドレスを、“ｓｅｃｕｒｅ”メッセージからの暗号化されたペイロードと組み合わせることによって、新しいＨＴＴＰポストリクエストメッセージを作成する。例えば、このことにより、“ｈｔｔｐ：／／ｗｗｗ．ｐｓｐ．ｃｏｍ／ｃｒｅｄｉｔｃａｒｄｆｏｒｍ．ｈｔｍｌ？ｐａｙｌｏａｄ＝３４２１４１２３ｄｄａｓｄａｓ”などの、ＨＴＴＰポストリクエストが作成され得る。ステップＳ４０にて、このＨＴＴＰポストリクエストは、スカイプバックエンド１２２からＰＳＰプロキシ１１８に送られる。スカイプバックエンド１２２はリクエストメッセージの実際の内容を全く承知していないことに、留意すべきである。それは情報を解読するのでなく、単に“再パッケージ”するに過ぎない。従ってスカイプバックエンド１２２は、ＰＣＩ遵守を要求しない。更に、スカイプバックエンド１２２は支払い情報を格納せず、従ってハッカのターゲットではない。

ステップＳ３７、Ｓ３９及びＳ４０内で実施される動作は図３に示されるが、図３はこれらステップ内で送受信されるメッセージの構造の例を示す。これは、“ｓｅｃｕｒｅ”マーカを用いるウエブブラウザ１３０からのＨＴＴＰポストリクエスト３０２を示し、クライアント１１２で受けられる際の、ＰＳＰのレファレンス３０４と非暗号化ポストＤａｔａ３０６を含む。ポストＤａｔａ（支払い情報）は暗号化され、暗号化された支払い情報３０８を生成する。暗号化された支払い情報３０８、ＰＳＰのレファレンス３０４、ユーザ情報３１０、及びコンテクスト３１２は、スカイププロトコルヘッダ３１４とスカイププロトコルフッタ３１６の間にラップされ、スカイププロトコルメッセージ３１８を作成する。スカイププロトコルメッセージ３１８はスカイプバックエンド１２２に送られ、そこでアンラップされ、ＰＳＰレファレンス３０４は解明されてＰＳＰのサーバアドレス３２２と暗号化支払い情報３０８を含むＨＴＴＰポストリクエスト３２０を作成する。

図２Ｃを再び参照して、ステップＳ４１にて、ＨＴＴＰポストリクエスト内の暗号化支払い情報はＰＳＰプロキシ１１８により復号化され、ユーザ１０６により入力された元の支払い情報を取得する。続いて復号化支払い情報は、ステップＳ４２にて、ポストＤａｔａとしての復号化支払い情報とＰＳＰウエブアプリケーションのＵＲＬとを含む、ＨＴＴＰポストリクエストのフォームで、ＰＳＰウエブアプリケーション１２０に送られる。

ＰＳＰウエブアプリケーション１２０は、ユーザ１０６からの支払い情報を処理する。支払い情報の処理に続いて、支払いが完了すると、図２Ｄに示す動作が実施される。一方で、支払いが完了しないと、図２Ｅに示す動作が実施される。

図２Ｄをまず参照すると、前述のように、図２Ｄは支払いが完了したケースを示す。ステップＳ４３にて、ＰＳＰウエブアプリケーション１２０は、完了した支払いに応じて、リダイレクトヘッダを発行する。リダイレクトヘッダは、ステップＳ４４にて、ＰＳＰプロキシで受けられ変更無くスカイプバックエンド１２２に進められる。スカイプバックエンド１２２はリダイレクトヘッダを処理し、ステップＳ４５にて、ＨＴＴＰゲットリクエストを、リダイレクトヘッダ内で参照されるスカイプウエブアプリケーション１２４のＵＲＬに送る。スカイプウエブアプリケーション１２４は、ステップＳ４６にて、応答して、ＨＴＭＬウエブページをスカイプバックエンド１２２に戻す。続いてＨＴＭＬウエブページは、ステップＳ４７にてクライアント１１２に進められ、ステップ４８にてウエブブラウザ１３０上に進められる。最後に、ステップＳ４９にて、ユーザ１０６に対してウエブブラウザウインドウ内にトランザクション結果が表示される。

今度は図２Ｅを参照すると、前述のように、図２Ｅは支払いが未だ完了しないケースを示す。ユーザがクレジットカードの詳細を不正確に入力した場合に、若しくはＰＳＰが不正制御のために更なる情報を要求する場合に、このことが生じ得る。この場合、ＰＳＰウエブアプリケーション１２０は、ユーザ１０６に表示されるＨＴＭＬウエブページを生成する。ＨＴＭＬページは、ステップ５０にて、ＰＳＰプロキシ１１８に送られ、ステップＳ５１にて、スカイプバックエンド１２２に変更無く進められる。スカイプバックエンド１２２は、ステップＳ５２にて、ＨＴＭＬウエブページをクライアント１１２に進め、ステップＳ５３にて、ウエブブラウザ１３０上に進める。最後に、ステップＳ５４にて、ユーザ１０６に対して、ウエブブラウザウインドウ内でＰＳＰウエブアプリケーションからのＨＴＭＬページが表示される。

図４は、ユーザ端末１０２で為される動作を要約するフローチャートを示す。ステップＳ４０２にて、ユーザ１０６は、クライアントプログラム１１２内部から支払いを為すことを選択する。これに応じて、クライアント１１２は、ステップＳ４０４にて、クライアントユーザインターフェース内部でウエブブラウザ１３０をオープンする。支払い詳細フォームがＰＳＰ１１６から取られて、Ｓ４０６にて、ウエブブラウザ１３０内でユーザに示される。Ｓ４０８にて、ユーザ１０６はウエブブラウザ１３０のフォーム内に支払い情報を入力する。Ｓ４１０にて、ウエブブラウザ１３０は、（図３に示す）支払い情報（３０２）を含む“ｓｅｃｕｒｅ”マーカを伴うＨＴＴＰポストリクエストを作成し、ネットワークポート１０５を介してネットワーク１０４内に送ることを試みる。Ｓ４１２にて、クライアント１１２は“ｓｅｃｕｒｅ”マーカを検知してウエブブラウザ１３０からＨＴＴＰポストリクエストをインターセプトし、このことにより、ネットワーク１０４内に送信されることを防ぐ。Ｓ４１４にて、クライアント１１２は、ＨＴＴＰポストリクエストから支払い情報を暗号化する。続いて、Ｓ４１６にて、クライアントは（図３の）スカイプ専用プロトコルメッセージ（３１８）内でＨＴＴＰポストリクエストを暗号化ペイロードでラップする。最後に、Ｓ４１８にて、クライアントは暗号化された支払い情報を含むスカイププロトコルメッセージをスカイプバックエンドサーバ１２２に伝送する。

図５は、図２Ｂ−図２Ｄに示す動作のためのページフローを示す。図５に示すステップの番号は、図２Ｂ−図２Ｄに示すものに対応する。図５では、“ＩＥ”は“インターネットエクスプローラ”を示すが、これは一つのタイプのウエブブラウザ１３０の例である。

本発明を好適な実施形態を参照して示して記述したが、当業者には当然のことながら、添付の請求項にて規定される発明の範囲から乖離することなく、形態及び詳細における種々の変更が可能である。

本発明をより良く理解するため、及び、同じものが以下に実施され得るか示すために、例示として、以下の図面を参照する。
支払いサービスプロバイダへの情報の安全な伝送を伴うピアツーピア電話システムを示す。 キー情報の維持のために図１のシステム内で交換されるメッセージを示す。 支払いの開始のために図１のシステム内で交換されるメッセージを示す。 支払い情報の安全な伝送のために図１のシステム内で交換されるメッセージを示す。 完了した支払い結果の伝送のために図１のシステム内で交換されるメッセージを示す。 完了していない支払い結果の伝送のために図１のシステム内で交換されるメッセージを示す。 支払い情報の安全な伝送の中で送られるメッセージの構造を示す。 ユーザ端末で実施される操作の概略を表すフローチャートを示す。 図２Ｂ−図２Ｄで実施される操作のためのページフローを示す。

符号の説明

１００・・・ピアツーピア電話システム、
１０２・・・ユーザ端末、
１０４・・・ネットワーク、
１０６・・・ユーザ、
１０８・・・第２のユーザ、
１１０・・・第２のユーザ端末、
１１２・・・クライアント、
１１６・・・支払いサービスプロバイダ、
１１８・・・ＰＳＰプロキシ、
１２０・・・ＰＳＰウエブアプリケーション、
１２２・・・スカイプ（Ｓｋｙｐｅ）バックエンドサーバ、
１２４・・・スカイプ（Ｓｋｙｐｅ）ウエブアプリケーション、
１３０・・・ウエブブラウザ。

Claims (15)

1. 通信ネットワークにおいてユーザから第１のネットワークエンティティへ情報を伝送する方法において、
   上記ユーザがユーザ端末で実行されるブラウザの中に情報を入力するステップと、
   上記ブラウザがネットワークポートを介してネットワークにおいてディスパッチするため第１の通信プロトコルを用いて、上記情報を含み、上記第１のネットワークエンティティの識別子を含む第１のメッセージを生成するステップと、
   上記第１のメッセージが上記ネットワークポートに到着する前に、上記ユーザ端末で実行されるクライアントにて上記第１のメッセージを受けるステップと、
   上記クライアントが、上記クライアントと第２のネットワークエンティティの間でメッセージを伝送するのに利用される第２の通信プロトコルの第２のメッセージに、上記第１のメッセージをラップするステップと、
   上記通信ネットワークにおいて、上記第２のメッセージを上記クライアントから上記第２のネットワークエンティティに伝送するステップと、
   上記第２のネットワークエンティティにて上記第２のメッセージをアンラップして上記第１の通信プロトコル内に上記第１のメッセージ残し、上記第１のネットワークエンティティの上記識別子を上記第１のネットワークエンティティのネットワークアドレスに翻訳し、上記第１の通信プロトコルを用いて上記通信ネットワークにおいて上記第１のメッセージを上記第１のネットワークエンティティに伝送するステップと
   を含む方法。
2. 更に、
   上記クライアントにて上記第１のメッセージを受けるステップの後に、上記第１のメッセージ内の上記情報を暗号化するステップ
   を含むことを特徴とする請求項１に記載の方法。
3. 更に、
   上記第２のネットワークエンティティにより伝送される上記第１のメッセージを上記第１のネットワークエンティティにて受けるステップ
   を含むことを特徴とする請求項２に記載の方法。
4. 更に、
   上記第１のメッセージが上記第１のネットワークエンティティにて受けられた後に、上記第１のメッセージ内の上記情報を復号化するステップ
   を含むことを特徴とする請求項３に記載の方法。
5. 更に、
   上記第１のメッセージを受けたことに応じて、上記第１のネットワークエンティティから上記第２のネットワークエンティティに第３のメッセージを伝送するステップと、
   上記第２のネットワークエンティティにて上記第３のメッセージを受け、このことに応じて、サーバからウエブページをフェッチするステップと、
   上記ウエブページを上記第２の通信プロトコルの第４のメッセージ内にラップするステップと、
   上記通信ネットワークにおいて上記第４のメッセージを上記クライアントに伝送するステップと、
   上記クライアントにて上記第４のメッセージから上記ウエブページをアンラップして上記ウエブページを上記ブラウザに通すステップと、
   上記ウエブページを上記ブラウザ内で上記ユーザに表示するステップと
   を含むことを特徴とする請求項１乃至４のうちのいずれか一に記載の方法。
6. 通信ネットワークにおいてユーザから第１のネットワークエンティティへ情報を伝送するシステムにおいて、
   ユーザ端末で実行されるブラウザであって、上記ユーザにより入力される情報を受ける手段と、ネットワークポートを介してネットワークにおいてディスパッチするため第１の通信プロトコルを用いて、上記情報を含み、上記第１のネットワークエンティティの識別子を含む第１のメッセージを生成する手段を含む、ブラウザと、
   上記ユーザ端末で実行されるクライアントであって、上記第１のメッセージが上記ネットワークポートに到着する前に上記クライアントにて上記第１のメッセージを受ける手段と、上記クライアントと第２のネットワークエンティティの間でメッセージを伝送するのに利用される第２の通信プロトコルの第２のメッセージ内に上記第１のメッセージをラップする手段と、上記通信ネットワークにおいて上記第２のメッセージを上記第２のネットワークエンティティに伝送する手段とを含む、クライアントと、
   上記第２のネットワークエンティティにて上記第２のメッセージをアンラップして上記第１の通信プロトコル内に上記第１のメッセージ残す手段と、上記第１のネットワークエンティティの上記識別子を上記第１のネットワークエンティティのネットワークアドレスに翻訳する手段と、上記第１の通信プロトコルを用いて上記通信ネットワークを渡って上記第１のメッセージを上記第１のネットワークエンティティに伝送する手段とを含む、上記第２のネットワークエンティティと
   を含むシステム。
7. 更に、
   上記クライアントが、上記クライアントにて上記第１のメッセージを受けた後に、上記第１のメッセージ内の上記情報を暗号化する手段
   を含むことを特徴とする請求項６に記載のシステム。
8. 更に、
   上記第１のネットワークエンティティが、上記第２のネットワークエンティティにより伝送される上記第１のメッセージを受ける手段
   を含むことを特徴とする請求項７に記載のシステム。
9. 更に、
   上記第１のネットワークエンティティが、上記第１のメッセージが上記第１のネットワークエンティティにて受けられた後に、上記第１のメッセージ内の上記情報を復号化する手段
   を含むことを特徴とする請求項８に記載のシステム。
10. 更に、
    上記第１のネットワークエンティティは、上記第１のメッセージを受けたことに応じて、上記第２のネットワークエンティティに第３のメッセージを伝送する手段
    を含むことを特徴とする請求項６乃至９のうちのいずれか一に記載のシステム。
11. 更に、
    上記第２のネットワークエンティティは、
    上記第３のメッセージを受け、このことに応じて、サーバからウエブページをフェッチする手段と、
    上記ウエブページを上記第２の通信プロトコルの第４のメッセージ内にラップする手段と、
    上記通信ネットワークにおいて上記第４のメッセージを上記クライアントに伝送する手段と
    を含むことを特徴とする請求項１０に記載のシステム。
12. ユーザ端末において、
    上記ユーザ端末で実行されるブラウザであって、ユーザにより入力される情報を受ける手段と、ネットワークポートを介して通信ネットワークにおいてディスパッチするため第１の通信プロトコルを用いて、上記情報を含み、第１のネットワークエンティティの識別子を含む第１のメッセージを生成する手段を含む、ブラウザと、
    上記ユーザ端末で実行されるクライアントであって、上記第１のメッセージが上記ネットワークポートに到着する前に上記クライアントにて上記第１のメッセージを受ける手段と、上記クライアントと第２のネットワークエンティティの間でメッセージを伝送するのに利用される第２の通信プロトコルの第２のメッセージ内に上記第１のメッセージをラップする手段と、上記通信ネットワークにおいて上記第２のメッセージを上記第２のネットワークエンティティに伝送する手段とを含む、クライアントと
    を含むユーザ端末。
13. ネットワークエンティティにおいて、
    ユーザ端末にて実行されるクライアントにより通信ネットワークにおいて上記ネットワークエンティティに伝送された第２の通信プロトコルの第２のメッセージを受ける手段と、
    上記第２のメッセージをアンラップして、更なるネットワークエンティティの識別子を含む、第１の通信プロトコルの第１のメッセージを残す手段と、
    上記の更なるネットワークエンティティの上記識別子を上記の更なるネットワークエンティティのネットワークアドレスに翻訳する手段と、
    上記第１の通信プロトコルを用いて上記通信ネットワークにおいて上記第１のメッセージを上記の更なるネットワークエンティティに伝送する手段と
    を含むネットワークエンティティ。
14. コンピュータを、
    ブラウザがユーザにより入力される情報を受け、ネットワークポートを介して通信ネットワークにおいてディスパッチするため第１の通信プロトコルを用いて、上記情報を含み、第１のネットワークエンティティの識別子を含む第１のメッセージを生成した場合、
    上記第１のメッセージが上記ネットワークポートに到着する前にクライアントにて上記第１のメッセージを受ける手段、
    上記クライアントと第２のネットワークエンティティの間でメッセージを伝送するのに利用される第２の通信プロトコルの第２のメッセージ内に上記第１のメッセージをラップする手段、及び
    上記通信ネットワークにおいて上記第２のメッセージを上記第２のネットワークエンティティに伝送する手段
    として機能させるためのプログラム。
15. コンピュータを、
    ユーザ端末にて実行されるクライアントにより通信ネットワークにおいてネットワークエンティティに伝送された第２の通信プロトコルの第２のメッセージを受ける手段、
    上記第２のメッセージをアンラップして、更なるネットワークエンティティの識別子を含む、第１の通信プロトコルの第１のメッセージを残す手段、
    上記の更なるネットワークエンティティの上記識別子を上記の更なるネットワークエンティティのネットワークアドレスに翻訳する手段、及び
    上記第１の通信プロトコルを用いて上記通信ネットワークにおいて上記第１のメッセージを上記の更なるネットワークエンティティに伝送する手段
    として機能させるためのプログラム。

Images