JP2009527984A - 秘密鍵とのアカウントリンク - Google Patents

Abstract

コンピュータシステムは、第１のウェブサイトとのセキュアな通信用の第１の秘密鍵および第２のウェブサイトとのセキュアな通信用の第２の秘密鍵を生成するようにプログラムされたセキュリティモジュールを含み、第１の鍵および第２の鍵は異なっている。コンピュータシステムは、第１のウェブサイトに関連付けられた第１のユーザアカウントを、第２のウェブサイトに関連付けられた第２のユーザアカウントにリンクするための第１のウェブサイトからの要求を受け取るようにプログラムされた識別モジュールであって、識別モジュールは、ユーザに第１のユーザアカウントおよび第２のユーザアカウントをリンクするための選択肢を表示するようにプログラムされている。

Description

著作権の表示
本明細書の開示の一部は、著作権保護の対象である構成要素を含む。米国特許庁の特許ファイルまたは記録に現れるので、著作権の所有者は、特許文書または特許開示の任意の者による複写複製に意義を有さないが、さもなければ、すべての著作権を有する。

ユーザは、ビジネスおよび遊びを行なうためにオンラインリソースへのユーザの依存を増加し続けているので、プライバシーを保護することおよびセキュアな取引を容易にすることの重要性は上がる。情報の暗号化は、オンライン環境におけるプライバシーおよびセキュリティを提供する１つの方法である。１つの暗号化方法は、他者と自由に共有する公開鍵の使用を伴う。公開鍵は公開鍵の所有者に送られるメッセージを暗号化するのに使用される。所有者はその後、メッセージを復号化するのに機密鍵を使用する。公開鍵などの高度な暗号法の使用は、「フィッシング」攻撃に対抗するために機能し、オンラインユーザの新たなレベルの保護を提供する。

このタイプの暗号化の潜在的な不利点の１つは、公開鍵が多くのオンラインサイトで再利用されるとき、公開鍵は、個人の識別情報の新しい形式となる。公開鍵は、暗号化鍵であるのに加えて、「データベース鍵」としても使用できるバイト列として考えることができる。この中身において、複数のオンラインリソースにわたるユーザのオンラインアクティビティを相関(correlate)させ、追跡するために公開鍵を採用できる。たとえば、２つのウェブサイトはそれらのサイトで登録された公開鍵を比較することができ、一致を見つけることは、ユーザが熟考または、許可しない方法で、これらの鍵の所有者の購入プロフィールを相関できるであろう。

さらに、ユーザは一般に、オンライン取引を行なうとき、彼または彼女のプライバシーを守ることを望むだろうが、ユーザについての情報を共有することをウェブサイトに許可することをユーザが望むかもしれない状況がある。例えば、第１のウェブサイトは、第２のウェブサイトのメンバーに割引された商品またはサービスを提供する場合で、ユーザが第２のウェブサイトのメンバーである場合、ユーザは、ユーザがディスカウントを受け取ることができるように、ユーザについての情報を共有することを第１のウェブサイトおよび第２のウェブサイトに許可することを望むかもしれない。

米国特許出願第１１／０７４，８８５号明細書

したがって、プライバシーおよびセキュリティの関心が向けられ、オンラインリソースがいつおよびどうやってユーザ情報を共有するかを制御できるオンライン環境をユーザは望む。

この概要は、詳細な説明において以下でさらに説明される単純化された形式で概念の選択を紹介するために提供される。この概要は、鍵の特徴または特許請求された主題の重要な特徴を特定することを意図せず、また特許請求の範囲の主題を決定する助けとして使用されることになることを意図しない。

一態様によれば、コンピュータシステムは、第１のウェブサイトとのセキュアな通信用の第１の秘密鍵および第２のウェブサイトとのセキュアな通信用の第２の秘密鍵を生成するようにプログラムされたセキュリティモジュールであって、第１の鍵および第２の鍵は異なっているセキュリティモジュールを含む。コンピュータシステムは、第１のウェブサイトに関連付けられた第１のユーザアカウントを、第２のウェブサイトに関連付けられた第２のユーザアカウントにリンクするための第１のウェブサイトからの要求を受け取るようにプログラムされた識別モジュールであって、ユーザに第１のユーザアカウントおよび第２のユーザアカウントをリンクするための選択肢を表示する識別モジュールも含む。

別の態様によると、複数のウェブサイトと通信する方法は、第１のウェブサイトとのセキュアに通信するために第１の秘密鍵を生成するステップと、第２のウェブサイトとのセキュアに通信するために第２の秘密鍵を生成するステップと、ユーザ情報を前記第２のウェブサイトと共有するために、第１のウェブサイトからアカウントリンクの要求を受け取るステップと、アカウントリンクの許可または許可しないための選択肢をユーザに表示するステップとを含む。

さらに別の態様によると、第２のウェブサイトとのユーザアカウントをリンクするための第１のウェブサイトのための方法は、第２のウェブサイトとユーザ情報を共有するために、第１のウェブサイトからアカウントリンクの要求を送るステップと、アカウントリンクを許可するユーザからの応答を受け取るステップと、アカウントリンクを初期化するために、第２のウェブサイトへクーポンを転送するステップであって、クーポンは、第１のウェブサイトに関連付けられた第１の秘密鍵および第２のウェブサイトに関連付けられた第２の秘密鍵を含むリンク合意を含み、第１の秘密鍵および第２の秘密鍵は異なっている、転送するステップとを含む。

ここで参照は添付の図面になされ、縮尺で描かれることは必要としていない。

例示の実施形態を、添付の図面を参照して以降でより完全にここで説明する。この開示が徹底的で完全になるように、これらの実施形態を提供する。似ている番号は、全体において似ている要素を指す。

ここで開示されている例示の実施形態は一般に、複数のウェブサイトとセキュアに通信するためのユーザのコンピュータシステムにより生成される複数の異なる秘密鍵に関する。各ウェブサイトと通信するのに使用される秘密鍵は異なるので、異なるウェブサイト上でのユーザのアクティビティを相関させるのに、秘密鍵の使用を使用することはできない。いくつかの実施形態において、ユーザは、２または複数のウェブサイトがウェブサイトで使用される異なる秘密鍵を含むユーザについての情報を共有することを可能にする。

図１および図２を参照して、例示的なコンピューティング環境１００は、コンピュータシステム１１０、インターネット１３０などのネットワーク、複数のウェブサイト１５２、１５４、１５６を含む。ユーザは、インターネット１３０を介して、ウェブサイト１５２、１５４、１５６と通信するようにコンピュータシステム１００をコントロールする。

コンピュータシステム１１０は、少なくとも１つのプロセッサおよびメモリを含むパーソナルコンピュータとして構成できる。コンピュータシステム１１０は、コンピュータ可読の命令、データ構造、プログラムモジュールまたは他のデータなどの情報の格納のために任意の方法または技術で実装される、揮発性および不揮発性のコンピュータストレージメディア、ならびにリムーバブルおよびリムーバブルでないメディアの１または複数を含む。コンピュータシステム１１０は、本願出願人からのＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムなどのオペレーティングシステム、およびコンピュータ可読記憶媒体上に格納された１または複数のプログラムを含む。

コンピュータシステム１１０は、入力および出力通信デバイスの１または複数も含み、これらはユーザがコンピュータシステム１１０と対話できるようにし、コンピュータシステム１１０がウェブサイト１５２、１５４、１５６などの他のデバイスを通信できるようにする。コンピュータシステム１１０のユーザは、ブラウザ２１４などのコンピュータシステム１１０上のプログラムを使用して、ウェブサイト１５２、１５４、１５６にアクセスできる。ブラウザの一例は、本願出願人により提供されるインターネットエクスプローラーブラウザである。一実施形態において、コンピュータシステム１１９上で実行中のブラウザ２１４は、他のプロトコルを使用できるが、ＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）を使用してウェブサイト１５２、１５４、１５６の１または複数と通信できる。

例示の実施形態において、システム１１０は、コンピュータのユーザと関連付けられた１または複数のデジタル識別を保持するようにプログラムされている識別モジュール２１６を含む。いくつかの実施形態において、これらのデジタル識別は、ワシントン州レッドモンドの本願出願人により開発されたＷＩＮＦＸアプリケーションプログラミングインターフェースにおいて提供されるＩｎｆｏＣａｒｄシステムの一部を形成するＩｎｆｏＣａｒｄである。ＩｎｆｏＣａｒｄシステムは、ユーザがＩｎｆｏＣａｒｄと呼ばれるユーザに関連付けられた複数のデジタル識別を管理できるようにする。ＩｎｆｏＣａｒｄシステムは、ＷＩＮＦＸアプリケーションプログラミングインターフェースにおいてＷＣＦ(Windows Communication Foundation)などのウェブサービスプラットフォームを利用する。さらに、ＩｎｆｏＣａｒｄシステムは、ワシントン州レッドモンド本願出願人により少なくとも一部が広められたウェブサービスセキュリティ仕様ＷＳＳＳ（Web Services Security Specification）を使用して構築される。これらの仕様は、メッセージセキュリティモデルであるＷＳ−Ｓｅｃｕｒｉｔｙ、エンドポイントポリシーであるＷＳ−ＳｅｃｕｒｉｔｙＰｏｌｉｃｙ、メタデータプロトコルであるＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅおよび信頼性モデルであるＷＳ−Ｔｒｕｓｔを含む。

コンピュータシステム１００は、秘密鍵１１２、１１４、１１６を生成するようにプログラムされるセキュリティモジュール２１８も含む。たとえばシステム１１０は、ウェブサイト１５２で共有される秘密鍵１１２を生成する。例示の実施形態において、秘密鍵１１２は、システム１１０のユーザおよびウェブサイト１５２の間のペアワイズ鍵(pair-wise key)である。システム１１０のセキュリティモジュール２１８は、ウェブサイト１５２、１５４、１５６それぞれについての異なる秘密鍵を生成するようにプログラムされている。システム１１０およびウェブサイト１５２、１５４、１５６は、セキュアに通信するために順にそれぞれ秘密鍵１１２、１１４、１１６を使用できる。たとえばシステム１１０は、ウェブサイト１５２に送られる暗号化されたメッセージ２２０を生成するために秘密鍵を使用できる。ウェブサイト１５２は、以下に説明されるように、順にメッセージ２２０を復号化する。

秘密鍵１１２、１１４、１１６はシステム１１０のユーザとすべて関連付けられているが、各秘密鍵１１２、１１４、１１６は異なる。ペアワイズの性質のために、秘密鍵１１２、１１４、１１６は、ウェブサイト１５２、１５４、１５６の能力を最小化し、秘密鍵１１２、１１４、１１６の使用のみに基づいて異なるウェブサイト１５２、１５４、１５６に渡るコンピュータシステム１１０のユーザのアクティビティを相関させる。たとえば、ウェブサイト１５２と通信するのに使用される秘密鍵１１２がウェブサイト１５４と通信するのに使用される秘密鍵１１４と異なるので、ウェブサイト１５２、１５４を、ウェブサイト１５２、１５４と通信するのに使用される鍵にのみ基づいてウェブサイト１５２、１５４上のユーザのアクティビティに相関させることはできない。

例示実施形態において、秘密鍵１１２、１１４、１１６のそれぞれは、対称鍵または非対称鍵であることができる。秘密鍵が、対称鍵について４０から２５６ビットの長さを形成し、非対称鍵について５１２から４０９６ビットの長さを形成するなどの、特定の長さのバイナリ数であるという点において、例示の秘密鍵は、公開鍵と構造が似ている。秘密鍵と公開鍵の第１の違いは、秘密鍵は公開して広められないが、ウェブサイトの１または選択されたグループに送られる代わりである。ユーザは、ユーザが通信するウェブサイトのそれぞれ（またはウェブサイトのそれぞれのグループ）についての1つの秘密鍵と共に、複数の異なる秘密鍵を有する。

一実施形態において、秘密鍵１１２、１１４、１１６の１または複数は、例えばＤＥＳ（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）またはＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）などのアルゴリズムに基づく対称鍵である。例えば秘密鍵１１２などの対象秘密鍵は、コンピュータシステム１１０のユーザおよびウェブサイト１５２の両方により知られている。対称鍵は署名および暗号化で使用できるが、システム１１０およびウェブサイト１５２の間で共有されるため、どちらが特定の通信を署名または暗号化したかを決定することは不可能である。さらに、秘密鍵１１２は、第三者がユーザおよびウェブサイト１５２の一方または両方のふりができてしまうので、第三者と共有できない（たとえばウェブサイト１５４、１５６）。

代替の実施形態において、秘密鍵１１２、１１４、１１６の１または複数は、例えばＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ）アルゴリズムに基づく非対称鍵である。この実施形態において、システム１１０のユーザは、共有されてない秘密鍵を有し、ウェブサイト１５２はユーザに送られるメッセージを暗号化し、機密鍵を使用して作られる署名を検証するのに使用できる秘密鍵１１２を有する。システム１１０のユーザのみが秘密鍵で署名できるので、リソースはユーザが特定の署名を通信したことを証明することが可能となる。これは一般に否認不可性とよばれる。

秘密鍵の生成に関する追加の詳細は、２００５年３月７日に出願された米国特許出願番号１１／０７４，８８５に説明されており、この全体がここで参照により組み込まれる。

ここで図３を参照して、秘密鍵を使用する例示の方法が示される。動作３１０において、ユーザのシステムは第１の秘密鍵を生成する。第１の秘密鍵は動作３２０で第１のウェブサイトに送られる。たとえばいくつかの実施形態において、第１の秘密鍵を含むメッセージを暗号化するために第１のウェブサイトに関連付けられた公開鍵を使用することにより、第１の秘密鍵を第１のウェブサイトにセキュアに送ることができる。ユーザはその後、（第１の鍵が対象ならば第１の秘密鍵、または第１の鍵が非対称ならば機密鍵を用いて、）動作３３０において、第１の秘密鍵を使用して第１のウェブサイトに署名されたメッセージを送ることができる。次に、動作３４０において、ユーザのシステムは第２の秘密鍵を生成し、第２の秘密鍵は、動作３５０において第２のウェブサイトに送信される。次にユーザはその後、（第２の鍵が対象ならば第２の秘密鍵、または第２の鍵が非対称ならば機密鍵を用いて、）動作３６０において第２のウェブサイトに署名されたメッセージを送ることができる。例示の実施形態において、第１のウェブサイトおよび第２のウェブサイトは、第１の秘密鍵と第２の秘密鍵が異なるので、ユーザならびに第１のウェブサイトおよび第２のウェブサイトの間の通信において使用される秘密鍵のみに基づいて、第１のウェブサイトおよび第２のウェブサイトの間のユーザによる取引を相関させることができない。

図１をもう一度参照して、ユーザおよびウェブサイト１５２、１５４、１５６の間の通信に関連付けられた鍵に基づいてシステム１１０のユーザについての情報を相関させるために、ウェブサイト１５２、１５４、１５６の能力を制限するようにコンピューティング環境１００を構成するが、いくつかの状況においてユーザが相関できるように設計することもできる。

たとえば、ウェブサイト１５２が航空券予約ウェブサイトであり、ウェブサイト１５４が航空券予約ウェブサイトの顧客のために割引価格を提供するレンタカーのウェブサイトである場合、ユーザが割引価格を受け取ることができるように、ユーザはウェブサイト１５２、１５４がユーザ情報を共有することを許可することを望むかもしれない。

このような状況において、ユーザはウェブサイト１５２，１５４の間のアカウントリンク１５８を許可できる。アカウントリンクは、ウェブサイト１５２上のユーザについての情報がいつウェブサイト１５４で共有されるかをユーザが決定できるようにし、またその逆もしかるべきである。共有されたユーザ情報は、名前、住所および電話番号などのプロフィール情報、ならびにユーザにより購入された商品および／またはサービスについての情報などの取引の情報を含むことができる。示された例において、アカウントリンク１５８は、ウェブサイト１５２がプロフィールおよび取引情報などのユーザについての情報をウェブサイト１５４と共有することを可能とする。例示の実施形態において、秘密鍵１１２、１１４を、アカウントリンク１５８を容易にするために使用できる。

例えば、一実施形態において、２つのペアワイズ非対称秘密鍵「Ｋ₁」および「Ｋ₂」は、ウェブサイトＲ₁およびＲ₂で使用される。アカウントリンクを定義する人が読むことができるポリシー「Ｐ」は、検討のためにユーザに提供される。ポリシー「Ｐ」は、情報がウェブサイトＲ₁およびウェブサイトＲ₂の間で共有されることになる方法で定義する。たとえば、ポリシー「Ｐ」は、何の情報が共有されるか、どのくらいの長さで情報がアップデート／共有されるか、共有が一方向または双方向かどうか、および共有情報で何ができるかを定義できる。「S _K(L)」は、鍵Ｋを使用するコンテンツＬ上での署名を表し、「Ｔ」はタイムスタンプを表す。この情報に基づいて、セキュリティモジュール２１８は、
L = { P, R₁, K_i, R₂, K₂, T }および
C = L + S _K1(L) + S_K2(L)
のように、アカウントのリンク合意(linkinig agreement)「Ｌ」に従って、クーポンＣを作るようプログラムされる。以下で説明されるように、２つのウェブサイトの間のユーザ情報の共有を容易にするためにクーポン「Ｃ」を使用できる。例示の実施形態において、リンク合意「Ｌ」は、ポリシー、サイト識別子、関連秘密鍵を組み込むＸＭＬフラグメントを使用して、ＩｎｆｏＣａｒｄシステムの一部として実装される。

ここで図１および図４を参照して、例示のクーポン４１０が示される。クーポン４１０は、リンク合意４２０およびウェブサイト１５２、１５４で採用された秘密鍵１１２、１１４のそれぞれを使用するリンク合意４２０上でエンコードされた署名４３０、４４０を含む３つのパートのＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ドキュメントである。いくつかの実施形態において、ＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）またはＸｒＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｒｉｇｈｔｓ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によって、セキュリティトークンとしてクーポン４１０をエンコードできるが、他の言語を使用できる。

クーポン４１０は、ウェブサイト１５２またはウェブサイト１５４のいずれかで使用でき、任意の順でウェブサイト１５２、１５４に表示できる。システム１１０のユーザは、各ウェブサイト１５２、１５４に直接クーポン４１０を与えることができ、あるいはウェブサイト１５２、１５４はアカウントリンク１５８を作成するために他方へクーポン４１０を転送できる。この実施形態において、否認不可は可能であり、システム１１０のユーザは、ユーザがアカウントリンクを許可した元でポリシーを示すために、クーポン４１０のコピーを持ち続けることができる。

対称秘密鍵「Ｋ₁」および「Ｋ₂」を採用する代替の実施形態において、機密鍵は第三者に開示できないので、第２のペアワイズ鍵は、識別子の役割のウェブサイトＲ₁およびウェブサイトＲ₂のそれぞれで紹介され、対象秘密鍵と同様に選択された第三者に共有できる。たとえば、識別鍵「Ｉ」を使用できる。クーポン４１０などのクーポン「Ｃ」を、
L = { P, R₁, I₁, R₂, I₂, T }および
C = L + S _K1(L) + S_K2(L)
のようなリンク合意「Ｌ」から作ることができる。この対称秘密鍵の中身において、クーポン４１０は、ウェブサイト１５２、１５４で働くか、または任意の順でウェブサイト１５２、１５４に表示できる。システム１１０のユーザは各ウェブサイト１５２、１５４に直接にクーポン４１０を与えることができるか、またはウェブサイト１５２、１５４は他方にクーポン４１０を表示することができる。しかし、消費者が他のウェブサイトで採用された識別を所有するウェブサイト１５２、１５４のいずれにも、証明書は提供されない。この保証を手に入れるために、ウェブサイト１５２は、２つのウェブサイトでアカウントをリンクする前に、ウェブサイト１５４へクーポン４１０を表示する。ウェブサイト１５４はその後、アカウントの署名および存在を検証できる。ウェブサイト１５２、１５４はユーザ同様に関連署名を適用可能なので、否認不可は可能ではない。

ここで図５を参照して、アカウントリンクを実施するための例示の方法５００が示されている。動作５１０で開始して、ユーザは、第２のウェブサイトとのアカウントリンクに関する第１のウェブサイトからポリシーを受け取る。次に動作５２０において、ユーザはポリシーに基づいてアカウントリンクを許すかどうかを決定する。ユーザがアカウントリンクを許可することを選ぶ場合、制御は動作５３０に渡され、ユーザはアカウントリンクを許可する第１のウェブサイトに応答を送る。例示の実施形態において、ユーザのコンピュータは、上述のようにクーポンを生成でき、アカウントリンクを許可するために第１のウェブサイトにクーポンを転送する。代替として、ユーザが動作５２０においてアカウントリンクを許さないことを決定する場合、制御は動作５４０へ渡され、アカウントリンクを許可しないウェブサイトに応答を送る。

ここで図６を参照して、いくつかの実施形態において、例示の方法６００は、ウェブサイトが複数の他のウェブサイトとのアカウントリンクを要求することを可能にする。たとえば、動作６１０で開始して、ウェブサイトは、ユーザのコンピュータに、ポリシーおよびウェブサイトがアカウントリンクを望むウェブサイトに関連付けられた複数の識別子を転送する。例示の実施形態において、識別子はウェブサイトに関連付けられた公開鍵であるが、ドメイン名などの他の一意の識別子を使用できる。

次に、動作６２０において、ユーザのコンピュータは、ユーザが任意の識別子がリスト内の任意のウェブサイトに一致するかどうかを決定するために存在する関係性を有するウェブサイトのリストを検索する。次に、動作６３０において、ポリシーおよび任意の一致するウェブサイトのリストがユーザに表示される。ユーザはその後、動作６４０において、一致したリスト内の任意のウェブサイトにアカウントリンクを許すかどうかを決定することを許される。ユーザがリストされた任意のウェブサイトについてのアカウントリンクを許すことを決定する場合、制御は動作６５０に渡され、選択されたウェブサイトのリンク合意および双方向署名を含んでクーポンを生成する。代替として、ユーザが動作６４０においてリストされた任意のウェブサイトについてのアカウントリンクを許さない場合、制御は動作６６０に渡され、これらのウェブサイトについてのアカウントリンクは許されない。

例示の実施形態において、ワシントン州レッドモンドの本願出願人により開発されたＷＩＮＦＸアプリケーションプログラムインターフェースにおいて提供されるＩｎｆｏＣａｒｄシステムの一部として、方法６００を実装できる。ユーザが要求における任意のウェブサイとの存在するアカウントを有するかどうかを決定するために、ウェブサイトがアカウントリンクを要求するとき、コンピュータシステム１１０上に識別モジュール２１６により格納された複数のデジタル識別を検索できる。

例えば、複数のウェブサイトとのアカウントリンクのウェブサイトからの要求を受け取ることに応答して、ユーザのコンピュータシステムは、ユーザと関連付けられたＩｎｆｏＣａｒｄを検索するようにプログラムされ、ＩｎｆｏＣａｒｄはユーザのシステム上に格納され、ＩｎｆｏＣａｒｄは要求において任意のウェブサイトでアカウントを確立するために使用された。要求におけるウェブサイトに一致するＩｎｆｏＣａｒｄは、ユーザに表示される。ユーザは、ウェブサイトについてのポリシーおよび一致したＩｎｆｏＣａｒｄを検討することにより、アカウントリンクを許すか否かを決定できる。

いくつかの実施形態において、ウェブサイト１５２などのウェブサイトのための登録処理の一部として、アカウントリンクを実施する。たとえば、ユーザがウェブサイト１５２で登録するとき、ウェブサイトのポリシーは、他の登録情報に加えて、アカウントリンク情報を求める。このアカウントリンク情報は、ウェブサイト１５４などのアカウントリンクを望むウェブサイトの識別子（例えば公開鍵またはドメイン名）を含むことができる。ユーザがウェブサイト１５４との存在するアカウントを有する場合、ユーザは、ウェブサイト１５２の登録処理の間、ウェブサイト１５４とのアカウントリンクのための選択肢を表示され、ユーザはウェブサイト１５２、１５４の間のアカウントリンクを許可する／許可しないことができる。さらに、識別モジュール２１６は、どのサイトをユーザがアカウントリンクを許可したかをユーザがトラックすることを可能にするようにプログラムできる。

たとえば、ここで図７を参照して、ウェブサイト１５２との登録処理の間、ユーザはＧＵＩ７００を表示される。ユーザインターフェース７００を、ブラウザ２１４内で、またはコンピュータシステム１１０上の別個のインターフェースとして表示できる。インターフェース７００は、ウェブサイト１５２がアカウントリンクを要求し、ユーザが存在する関係を有するすべてのウェブサイトのリストと共に、ウィンドウ６１０を提供する。例えば、ウィンドウ６１０は、アカウントリンクがウェブサイト１５２により要求され、ユーザが存在するアカウントを有するウェブサイト１５４をリストする。ユーザはチェックボックス６２０によりウェブサイト１５２、１５４についてのアカウントリンクを承認できる。代替として、ユーザはチェックされていないボックス６２０を解放し、ウェブサイト１５２の登録プロセスを続けることにより、アカウントリンクを許可しないことができる。複数のウェブサイトがウィンドウ６１０にリストされる場合、もしウェブサイトがあれば、ウェブサイトがアカウントリンクを許可できるようにユーザが選択できるように、複数のチェックボックスを提供できる。

ここで図８を参照して、第１のウェブサイトがアカウントリンクを要求し実施するための例示の方法９００が示されている。動作９１０において、第１のウェブサイトがアカウントリンクの要求をユーザに送信する。次に、動作９２０において、ウェブサイトはユーザからの応答を受け取る。動作９３０において、ユーザがアカウントリンクを許したかどうかをウェブサイトは決定する。アカウントリンクが許可されていなかった場合、制御は９５０に渡され、アカウントリンクは実施されない。

代替として、アカウントリンクがユーザにより許可される場合、制御は９４０へ渡され、第１のウェブサイトは、上述のクーポン４１０などのユーザから受け取ったクーポンを評価し、クーポン中の署名を検証する。次に、動作９６０において、第１のウェブサイトは、第２のウェブサイトとクーポンを交換し、アカウントリンクを実施し、第２のウェブサイトからユーザについてのプロフィール情報を取得する。

例示の実施形態において、ワシントン州レッドモンドの本願出願人により開発されたＷＩＮＦＸアプリケーションプログラミングインターフェースにおいて提供されるＷＣＦ(Windows Communication Foundation)などのウェブサービスプラットフォームにおいて定義されるプロトコルを使用して、第１のウェブサイトは第２のウェブサイトとクーポンを交換する。たとえば、ＷＳ−Ｔｒｕｓｔにおいて提供された保証メカニズムに従って、ＲＳＴ（Ｒｅｑｕｅｓｔ Ｓｅｃｕｒｉｔｙ Ｔｏｋｅｎ）を送ることにより、第１のウェブサイトは、第二のウェブサイトにクーポンおよびプロフィール情報を転送できる。クーポンを含むＲＳＴの例が以下で示される。
<RequestSecurityToken>
<TokenType>
urn: ... :TokenType:AccountLinking
</TokenType>
<Claims>
<Claim URI="http://.../account-linking/claims/AccountId"/>
<Claim URI="http ://.../account-linking/claims/MembershipLever 7>
<Claim URI="http://.../account-linking/claims/Membership Status "/>
</Claims>
<AccountLinkingAuthorizationToken>
[Coupon from user that authorizes account linking is inserted here]
</AccountLinlcingAuthorizationToken>
</RequestS ecurityToken>

第２のウェブサイトは、第１のウェブサイトに戻ってＲＳＴＲ（Ｒｅｑｕｅｓｔ Ｓｅｃｕｒｉｔｙ Ｔｏｋｅｎ Ｒｅｓｐｏｎｓｅ）を送ることにより、このような要求に応答でき、以下でこの例を提供する。
<RequestSecurityTokeriResponse>
<TokenType>
urn: ... :TokenType: AccountLinking
</TokenType>
<RequestedSecurityToken>
<AccountLinkingToken>
[Custom token containing account linking information is inserted here]
</AccountLinkingToken>
</RequestedS ecurityToken>
</RequestS ecurityTokenResponse>

この実施形態において、第１のウェブサイトおよび第２のウェブサイトにより発行されるセキュリティトークンは、Ｘ５０９、Ｋｅｒｖｅｒｏｓ、ＳＡＭＬ（バージョン１．０およびバージョン１．２）、ＳＸＩＰ（Ｓｉｍｐｌｅ ｅＸｔｅｎｓｉｂｌｅ Ｉｄｅｎｔｉｔｙ Ｐｒｏｔｏｃｏｌ）を含むがこれらに限定されない、複数のフォーマットの１または複数において生成できる。

１または複数の利点がここで説明されるシステムおよび方法に関連付けられる。たとえば、秘密鍵の使用は、オンライン環境におけるユーザのプライバシーを高めることができる。さらに、アカウントリンクの使用は、いつおよびどのようにユーザに関連付けられた情報がウェブサイト間で共有されるかをユーザが決定できるようにする。

ここで説明された例ではウェブサイトを参照するが、代替の実施形態において、秘密鍵およびアカウントリンクを他のオンラインリソースでも使用できる。例えば、代替の実施形態において、ＷＳ−＊一式で定義されるウェブサービスの標準プロトコルを使用して、インターネット上でウェブサービスにアクセスするリッチなクライアントアプリケーションは、秘密鍵およびアカウントリンクを利用できる。例えば、代替の一実施形態において、ユーザが証券会社で株を取引し、ポートフォリオを管理することを可能にする専用のリッチなクライアントアプリケーションは、証券会社の口座およびユーザの銀行口座の間でアカウントリンクを開始することができる。他の代替も可能である。

上述された様々な実施形態は、例示としてのみ提供され、限定として構成されるべきではない。当業者は、開示または添付の特許請求の範囲の真の精神および範囲から逸脱することなく、上述の実施形態になされうる様々な修正および変更を読んで認識することとなる。

コンピュータシステムが複数の秘密鍵を使用して複数のウェブサイトと通信するためにプログラムされた例示的なコンピューティング環境を示す図である。 図１のコンピュータシステムおよびウェブサイトのうちの１つの間での例示的な通信を示す図である。 秘密鍵を使用する例示的な方法を示す図である。 ２つのウェブサイトの間でユーザ情報を交換するように使用される例示的なクーポンを示す図である。 ２つのウェブサイトの間でアカウントリンクを実施するための例示的な方法を示す図である。 ウェブサイトが、複数の他のウェブサイトとのアカウントリンクを要求するための例示的な方法を示す図である。 ユーザにアカウントリンク情報を表示するための例示的なＧＵＩを示す図である。 ウェブサイトが、アカウントリンクを要求し、実施するための例示的な方法を示す図である。

Claims (16)

1. 第１のウェブサイトとのセキュアな通信用の第１の秘密鍵および第２のウェブサイトとのセキュアな通信用の第２の秘密鍵を生成するようにプログラムされたセキュリティモジュールであって、前記第１の鍵および前記第２の鍵は異なっているセキュリティモジュールと、
   前記第１のウェブサイトに関連付けられた第１のユーザアカウントを、前記第２のウェブサイトに関連付けられた第２のユーザアカウントにリンクするための前記第１のウェブサイトからの要求を受け取るようにプログラムされた識別モジュールであって、ユーザに前記第１のユーザアカウントおよび前記第２のユーザアカウントをリンクするための選択肢を表示する識別モジュールと
   を備えたことを特徴とするコンピュータシステム。
2. 前記セキュリティモジュールは、前記リンクの前記ユーザの許可に応答して、前記第１のウェブサイトへのクーポンを生成および転送するようにさらにプログラムされており、前記クーポンは、前記第１のユーザアカウントおよび前記第２のユーザアカウントのリンクを容易にすることを特徴とする請求項１に記載のコンピュータシステム。
3. 前記クーポンは、前記第１の秘密鍵および前記第２の秘密鍵を含むリンク合意を含むことを特徴とする請求項２に記載のコンピュータシステム。
4. 前記第１のウェブサイトからの前記第１のユーザアカウントおよび前記第２のユーザアカウントの前記リンクの要求は、前記第１のユーザアカウントおよび前記第２のユーザアカウントにおける情報をどのように前記第１のウェブサイトおよび前記第２のウェブサイトの間で共有するかを定義するポリシーを含むことを特徴とする請求項１に記載のコンピュータシステム。
5. 前記第１のウェブサイトからの前記要求は、複数のウェブサイトからのリンクアカウントの要求を含み、前記識別モジュールは、前記複数のウェブサイトの１または複数に一致する前記コンピュータシステム上でデジタル識別を検索するためにさらにプログラムされていることを特徴とする請求項１に記載のコンピュータシステム。
6. 前記識別モジュールは、一致するデジタル識別に関連付けられたユーザアカウントをリンクするための選択肢を前記ユーザに表示するようさらにプログラムされていることを特徴とする請求項５に記載のコンピュータシステム。
7. 複数のウェブサイトと通信する方法であって、
   第１のウェブサイトとのセキュアに通信するために第１の秘密鍵を生成するステップと、
   第２のウェブサイトとのセキュアに通信するために第２の秘密鍵を生成するステップと、
   ユーザ情報を前記第２のウェブサイトと共有するために、前記第１のウェブサイトからアカウントリンクの要求を受け取るステップと、
   前記アカウントリンクの許可または許可しないための選択肢をユーザに表示するステップと
   を備えたことを特徴とする方法。
8. 前記アカウントリンクの前記ユーザの承認に応答してクーポンを生成するステップであって、前記クーポンは前記アカウントリンクを容易にする、生成するステップと
   前記第１のウェブサイトに前記クーポンを転送するステップと
   をさらに備えたことを特徴とする請求項７に記載の方法。
9. 前記第１のウェブサイトからの前記要求は、複数のウェブサイトのためのアカウントリンクの要求を含み、
   前記複数のウェブサイトの１または複数と一致する前記ユーザに関連付けられたデジタル識別を検索するステップと、
   一致するデジタル識別と共にウェブサイトについての前記アカウントリンクを許可または許可しないための選択肢をユーザに表示するステップと
   をさらに備えたことを特徴とする請求項７に記載の方法。
10. 請求項７に記載のステップを実行するためのコンピュータ実行可能命令を有するコンピュータ可読記憶媒体。
11. 第２のウェブサイトとのユーザアカウントをリンクするための第１のウェブサイトのための方法であって、
    前記第２のウェブサイトとユーザ情報を共有するために、前記第１のウェブサイトからアカウントリンクの要求を送るステップと、
    前記アカウントリンクを許可する前記ユーザからの応答を受け取るステップと、
    前記アカウントリンクを初期化するために、前記第２のウェブサイトへクーポンを転送するステップであって、前記クーポンは、前記第１のウェブサイトに関連付けられた第１の秘密鍵および前記第２のウェブサイトに関連付けられた第２の秘密鍵を含むリンク合意を含み、前記第１の秘密鍵および前記第２の秘密鍵は異なっている、転送するステップと
    を備えたことを特徴とする方法。
12. 前記クーポンを前記ユーザから受け取るステップをさらに備えたことを特徴とする請求項１１に記載の方法。
13. 前記クーポンを検証するステップをさらに備えたことを特徴とする請求項１１に記載の方法。
14. 前記要求を送るステップは、前記ユーザのために前記第１のウェブサイトの登録処理の間、前記アカウントリンクの要求を送るステップをさらに備えたことを特徴とする請求項１１に記載の方法。
15. 前記要求を送るステップは、どのように前記ユーザ情報が前記第２のウェブサイトで共有されるかを定義するポリシーを、前記ユーザに送るステップをさらに備えたことを特徴とする請求項１１に記載の方法。
16. 請求項１１に記載のステップを実行するためのコンピュータ実行可能命令を有するコンピュータ可読記憶媒体。

Images