JP2012517064A - 安全なプライベート・データ記憶装置を有する集中型の認証システム、および方法 - Google Patents

Abstract

サービス・プロバイダに対して、ユーザのサービス・プロバイダとの関係に関連付けられたユーザ情報へのアクセスを提供する、トークンに基づく集中型の認証方法は、ユーザＩＤを格納したユーザ・トークンをユーザ端末において提示するユーザを認証するステップと、ユーザのユーザＩＤと、サービス・プロバイダのサービス・プロバイダＩＤとを含む少なくとも２つのデータ入力要素を用いて資源識別子を導出するステップと、
を含む。ユーザ情報は記憶ネットワークに格納され、資源識別子はユーザ情報に関連付けられる。方法は、さらに、資源識別子を用いて記憶ネットワークからユーザ情報を取り出すステップと、取り出されたユーザ情報をサービス・プロバイダに供給するステップと、を含む。
【選択図】図１

Description

本発明は、一般的にはコンピュータ・システム、方法およびコンピュータ・プログラム（program products、プログラム製品）に関し、特に、コンピュータ・ネットワークを介して行われる電子商取引および認証に関する。

関連出願の参照
本願は、２００９年２月５日付けで出願した米国仮特許出願第６１／１５０，０８４号、名称“安全なプライベート・データ記憶装置を用いる集中型のインターネット認証および識別技術”（Centralized Internet Authentication and Identification Technology with Safe Private Data Storage）の優先権を主張するものであり、この出願全体を参照してここに組み込む。

認証（Authentication）は、ユーザによってまたはユーザに代わって行われる一連（一組）の認証情報（credentials、資格、信用証明物）の正当性を検証または確認する処理（プロセス）である。認証は、ユーザが知っていること、ユーザが持っている物、またはユーザに関する或る特徴の中の１つ以上のものを、種々の認証プロトコルを使用してチャレンジ（証明の要求）／応答の動作を通して検証することによって、達成または実現される。例えば、ユーザが知っていること（情報）の検証は、例えばユーザのパスワードのような共有の秘密、または例えばユーザの暗号鍵のような特定のユーザにだけ知られていることを用いて、達成または実現されてもよい。ユーザが所持している物の検証には、スマートカード、またはその他のハードウェア・トークンまたは有形物の形態のものが用いられてもよい。ユーザの特徴の検証には、スマートカード指紋または網膜マップ（図、地図）のような生体測定用入力（バイオメトリック入力）が用いられてもよいかもしれない。

インターネットは、財務的な口座（ファイナンシャル・アカウント）取引および製品注文取引を含む機密の（sensitive、敏感な、慎重に扱うべき）オンライン情報および取引に対する広範なアクセスを提供する。この情報へのアクセスは保護されなければならず、不正なまたは権限のない個人には取引（トランザクション）（例えば、無効な注文または命令の発行、銀行口座の引出しの実行）を実行させてはいけない。多くのオンライン電子商取引プロバイダは、そのような口座に対して単純なパスワード・レベルの保護だけを提供する。幾つかのプロバイダは、複数ファクタまたは２つのファクタの認証と一般的に称されるより高度な認証を提供する。例えば、プロバイダは、ユーザを認証するために、ディジタル証明書、またはトークンによって生成された１組の数字と組み合わせて、個人識別番号（ＰＩＮ）の使用を要求することがある。それにもかかわらず、“ユーザＩＤとパスワード”を組み合せたシステムでは、インターネットを介して幾つかの遠隔の資源（リソース）にアクセスしようとするユーザを認証するために、最も一般的な認証方式を維持している。便利さ（即ち、覚えやすい弱いパスワード）とセキュリティ（安全性）（即ち、複数英数字桁、大文字の規則、等、を有する強いパスワード）の間には周知の妥協が存在する。また、人々は、彼らが加入または契約する多数の資源に対する相異なるＩＤ／パスワードの組合せを管理しまたは覚えることが単にできないという理由だけで、複数の資源に対して同じユーザＩＤ／パスワードのペア（１対）をしばしば使用する。しかし、これらの組合せの再利用によって、この認証方式で達成可能なセキュリティのレベルが低下する。

ロイヤルティ（ポイント）カードの一般的な使用は、個々人が余りにも多くのロイヤルティカードを持ちすぎる、という関連する問題を生じさせる。個人が常に自己のロイヤルティカードを保持することは、不可能でないとしても、困難である。その結果、ユーザは、しばしば、ロイヤルティカードを使い損ない、その結果、ロイヤルティカードの地位（ステータス）が低くなったり失われたりし、または、ユーザは、認証のために店員に機密の（敏感な、慎重に扱うべき）個人情報を強制的に提示させられたりする。

これらの全てのサービス・プロバイダによって維持または保守される顧客／ユーザのプライベート（private、私的、非公開、秘密）データの相対的な安全性は、大きな関心事（懸念）でもある。原則として、全てのサービス・プロバイダは、登録の時点で、プライベートなユーザ・データ（例えば、ユーザ名、電話番号、住所（アドレス）、等）を取得し、この情報を自己のデータベースにおけるユーザ・プロファイルの下で格納する。これらのデータベースまたはその一部は、盗まれまたは破られて、犯罪目的で使用されることがある（およびかなり頻繁にそうされる）。また、異なる情報源からのデータを組み合わせることによって、ユーザの生活を詳細に調べることを可能にし、例えば識別情報、口座またはクレジット詐欺のような詐欺の機会を与える。

弱い認証およびプライベート・データの喪失に関連する問題は、電子商取引の将来に対する最大の脅威を提示している。

米国特許公開番号２００７／０２７１６０４Ａ１ 米国特許公開番号２００８／００６６１５６Ａ１ 米国特許公開番号２００７／０１６９１７５Ａ１ 米国特許公開番号２００７／０２２６４７９Ａ１ 米国特許公開番号２００８／０２８２３３４Ａ１

発明の概要
サービス・プロバイダに対して、ユーザの前記サービス・プロバイダとの関係に関連付けられたユーザ情報へのアクセスを提供する、トークンに基づく集中型の認証方法は、 ユーザＩＤを格納したユーザ・トークンをユーザ端末において提示する（示す、渡す）ユーザを認証するステップ（工程）と、 前記ユーザの前記ユーザＩＤと、前記サービス・プロバイダのサービス・プロバイダＩＤとを含む少なくとも２つのデータ入力要素（情報）を用いて、記憶（または記憶装置）ネットワークに格納された前記ユーザ情報に関係付けられた資源識別子を導出するステップと、 前記資源識別子を用いて前記記憶ネットワークから前記ユーザ情報を取り出す（検索する）ステップと、 前記取り出されたユーザ情報を前記サービス・プロバイダに供給するステップと、を含む。

本発明の上述のおよびその他の特徴は、添付の図面に関連して説明する以下の本発明の好ましい実施形態の詳細な説明からより良く理解されるであろう。

添付の図面は、本発明の好ましい実施形態、並びに開示に関連するその他の情報を例示している。

図１は、１つのコンピュータ・ネットワークが認証および分散型データ記憶管理システムを含むような、相互接続された複数のコンピュータ・ネットワークのシステムの定型化された概要図を示している。 図２は、サービス・プロバイダ・エージェント、ユーザ端末、および分散型データ記憶システムとインタフェースで接続する各接続と共に、より詳細な図１の認証および分散型データ記憶管理システムを示している。 図３は、図２のシステムにおいて使用するためのＩＤトークンのブロック図である。 図３Ａ〜３Ｄは、ＩＤトークンの種々の実施形態を示している。 図４は、認証および分散型データ記憶管理システムのユーザ・フロントエンド・コンポーネント（構成要素、部品）を、そのシステムのその他の部分との主要リンクと共に示している。 図５は、認証および分散型データ記憶管理システムのサービス・プロバイダ・フロントエンド・コンポーネントを、そのシステムのその他の部分との主要リンクと共に示している。 図６は、図２の分散型データ記憶システムを、より詳細に、そのシステムのその他の種々のコンポーネントへの各接続と共に示している。 図７Ａは、本発明の第１の実施形態による、サービス・プロバイダにおけるユーザ認証、およびユーザ・データ検索のための、メッセージ・シーケンス・チャートである。 図７Ｂは、本発明の第２の実施形態による、サービス・プロバイダにおけるユーザ認証、およびユーザ・データ検索のための、メッセージ・シーケンス・チャートである。 図７Ｃは、図７Ｂのメッセージ・シーケンス・チャートの代替的な実施形態を示している。 図７Ｄは、図７Ｂのメッセージ・シーケンス・チャートの代替的な実施形態を示している。 図８は、鍵（キー）管理システムの実施形態の各コンポーネント（構成要素）を示している。 図９は、ＩＤトークンを交換するための新しいＩＤトークンのペアを生成して発行する方法を例示するメッセージ・シーケンス・チャートである。

例示的な実施形態の説明は、明細書全体の一部と見なされる図面と関係で読まれるよう意図されている。例えば“接続された”（connected）および“相互接続された” （interconnected）のような取付け、結合、等に関する各用語は、別途明示的に説明しない限り、間に介在する構成物を通して直接的または間接的に各コンポーネントが互いに通信する関係のことを表している。

安全なプライベート（private、私的、非公開の、秘密）データ記憶（記憶装置）を有する集中型認証システム、および安全なプライベート・データ記憶（装置）を用いた集中型認証を提供する方法を、ここで、図面に関連して説明する。以下の説明において、均等なまたは類似の機能を有するシステム構成要素には、図面において同じ参照番号が付されている、と理解すべきである。さらに、本発明の側面（特徴）は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせの種々の形態で実装してもよいと、理解すべきである。特に、ここに記載した種々のシステム・モジュールは、好ましくは、例えば、汎用コンピュータ、または任意の適切なおよび好ましいマイクロプロセッサ・アーキテクチャを有する任意のマシンまたは装置によって実行可能なアプリケーション・プログラムとしてソフトウェアの形態で実装される。ここで説明する種々の機能は、好ましくは、例えば１つ以上の中央演算処理装置（ＣＰＵ）、ランダムアクセス・メモリ（ＲＡＭ）、および１つ以上の入力／出力（Ｉ／Ｏ）インタフェースのようなハードウェアを含むコンピュータ・プラットフォーム上に実装される。また、コンピュータ・プラットフォームには、オペレーティング・システム（ＯＳ）およびマイクロ命令コードが含まれる。ここに記載した種々の処理（プロセス）および機能は、オペレーティング・システムを介して実行されるマイクロ命令コードまたはアプリケーション・プログラムの一部であってもよい。さらに、コンピュータ・プラットフォームには、種々のその他の機能的ソフトウェア（例えば、ネットワーク・ドライバ、通信プロトコル、等）、並びに、追加的なデータ記憶装置のようなコンピュータ・プラットフォームに接続されるその他の周辺機器が含まれてもよい。

本発明の種々の特徴（側面）をそれらの方法を実施するための方法および装置の形態で実施形態化（実施化）することができる。本発明を実装するコードは、例えばシステム・メモリのような有形の媒体に動作可能状態で配置されたプログラム・コードの形態で、または例えば固定ディスク、フロッピ・ディスク、ＣＤ−ＲＯＭ、ハード・ドライブまたはその他の機械読取り可能な記憶媒体のような記憶媒体に格納されたプログラム・コードの形態で実施形態化してもよく、そのプログラム・コードが、例えばコンピュータのようなマシンにロードされてそのマシンによって実行されたとき、そのマシンは、本発明を実施するための装置となる。本発明の種々の特徴（側面）を実装するためのそのコードは、或る伝送媒体を介して、例えば、電気的な配線、または光ファイバを介したケーブル配線、または電磁放射を介して、送信してもよく、プログラム・コードが例えばコンピュータのようなマシンにロードされてそのマシンによって実行されたとき、そのマシンは本発明を実施するための装置となる。汎用プロセッサ上に実装されたとき、各プログラム・コード・セグメントは、そのプロセッサと組み合わされて、特定の論理回路と類似的に（アナロジー的に）動作する固有の機器を実現する。この開示において、用語“プロセッサ”を用いて、物理的なコンピュータまたは仮想マシンのことを表すことがある。

さらに、ここに記載された構成要素のシステム・コンポーネントの幾つかは好ましくはソフトウェア・モジュールとして実装されるので、図面に示された実際のシステム接続は、そのシステムがプログラムされる形態に応じて異なってもよい、と理解すべきである。特別な目的のマイクロプロセッサを用いて本発明の種々の特徴（観点）を実装してもよいことが分かる。関連分野の専門家の一人であれば、ここに記載した教示内容を考慮して、本発明におけるこれらのおよび類似の実装または構成を考え想定することができるであろう。

本発明の種々の特徴（観点）を詳しく説明する前に、図１に関連して本発明が展開され得る環境に関する一般的な導入的な説明を行う。

図１を参照すると、インターネット１１４は、複数のコンピュータ・ネットワークの世界的な広がりを有するシステムであり、複数のネットワークからなるネットワークであり、そのネットワークに接続される１つのコンピュータまたはその他の機器においてユーザが任意のその他のコンピュータから情報を取得でき、その他のコンピュータまたは機器のユーザと通信することができるものである。インターネットにおける最も広く使用される部分は、ワールドワイド・ウェブ（World Wide Web）（しばしば、短く“ＷＷＷ”または“ウェブ”と称される）である。

ウェブの最も目立った特徴の１つは、相互参照の方法であるハイパーテキストの使用である。ほとんどのウェブ・サイトでは、或る単語または句（フレーズ）が、周囲のテキストと異なる色のテキストで表示される。また、このテキストはしばしば下線が付される。時々、“クリック可能な”、例えば、ボタン、画像、または画像の各部分のようなホット・スポット（活動的な領域）が存在する。ハイパーテキストまたはホット・スポット上でのクリックによって、例えばハイパーテキスト転送プロトコル（ＨＴＴＰ）のようなプロトコルを介して別のウェブページのダウンロードが生じる。ウェブの使用によって、何百万ページもの情報へのアクセスが提供される。ウェブ“サーフィン”は、ウェブ・ブラウザ、例えば、アップル社（Apple）のサファリ（Safari（登録商標））およびマイクロソフト社（Microsoft）のインターネット・エクスプローラ（Internet Explorer（登録商標））のブラウザを使用して、行われる。特定のウェブ・サイトの外観は、使用される特定のブラウザに応じて僅かに異なることがある。各ブラウザのそれぞれのバージョンは、アニメーション、仮想現実、音および音楽を提供するそれぞれの“プラグイン”（plug-ins）を有する。読み込まれ翻訳または変換された（interepreted）プログラム（例えば、アプレット）が、ブラウザ内で実行されることがある。

図１は、相互接続された各コンピュータ・システム・ネットワーク１０２および各機器１１０を示している。より具体的には、ネットワーク１０２は、サービス・プロバイダによって稼働されるコンピュータ・システムのネットワークであってもよい。典型的なネットワーク化されたコンピューティング環境は、“ユーザ”および“サービス・プロバイダ”を含むものとして、広く表現することができる。サービス・プロバイダは、例えば図１に示すように、コンピュータ・システムおよびネットワークを介してユーザに対して電子的に、或る形態の情報、情報アクセスまたは資源へのアクセスを提供する。ユーザは、提供されるサービスの消費者とみなすことができる。一般的には、多くの異なるタイプのサービス・プロバイダは、例えば図１に示されたような所与のネットワーク化された環境に存在することがある。オンライン商業者は電子商取引サービス・プロバイダのクラスまたは集合を表す一方で、ウェブ・ポータル（入口）は情報サービス・プロバイダのクラスまたは集合を表している。インターネット・サービス・プロバイダは、サービスとして、インターネットへのネットワーク通信リンクを提供する事業体または存在である。これらのサービス・プロバイダの多くは、ユーザが適正に認証された後にだけ、その特定のサービスまたは資源へのアクセスを提供する。その際、サービス・プロバイダは、アクセスを許可されたユーザの識別情報の各側面を利用する。非限定的なサービス・プロバイダの例には、公共または企業のウェブ・サービスが含まれ、幾つか例を挙げると、例えば、電子商取引サイト（例えば、Amazon.com）、公共のメール・サーバ（例えば、mail.google.com）、ウィキ（wikies）、ソーシャル・ネットワーク・サービス（ＳＮＳ）（例えば、facebook.com）、伝統的なレンガとモルタルの商業者システム（例えば、メイシーズ（Macy's）またはホームデポ（Home Depot）における販売システム）および伝統的なおよびオンラインのバンキング（銀行）サービスが含まれる。

各サービス・プロバイダのコンピュータ・システム・ネットワーク１０２は、対応するローカル・データ記憶部１０６とローカル・ネットワーク・ユーザ端末１０８とに結合された対応するローカル・コンピュータ・プロセッサ・ユニット１０４を含んでいてもよい。コンピュータ・システム・ネットワーク１０２は、例えば、ローカルエリア・ネットワーク（ＬＡＮ）であるか、またはワイドエリア・ネットワーク（ＷＡＮ）の一部であってもよい。

また、例示された環境は、認証および分散型データ記憶管理システム２０４として識別される処理システムを含む第三者（サードパーティ）（即ち、上述の“ユーザ”でも“サービス・プロバイダ”でもない者）の認証システム２０２を含んでいる。或る実施形態では、認証および分散型データ記憶管理システム２０４は、取引（トランザクション）の期間中に相互認証を行うためのビヒクル（vehicle、実現手段、媒体）を提供する。即ち、システムの認証動作を用いて、サービス・プロバイダの安全に保護されたデータ記憶装置からデータが取り出される（公表される、開示される）前に、ユーザだけでなくサービス・プロバイダをも認証することができる。さらに、この認証プロセスの一部として、認証および分散型データ記憶管理システム２０４そのものが、後でより詳しく説明するように、ユーザおよびサービス・プロバイダに認証されるようにすることができる。システム２０４は、ローカル・コンピュータ処理ユニット２０８（例えば、管理動作を実行するためのもの）およびローカル記憶装置（ストレージ）２０６を含んでいる。システム２０２は、インターネット１１４を介してユーザのコンピュータ処理ユニット１１０およびネットワーク１０２に結合するよう示されているが、これらの機器とネットワークの間の通信は私的または民間のネットワークまたは専用接続によって行うこともできる、と理解すべきである。

複数のユーザ機器１１０およびローカル・ユーザ端末１０８（総称して、ユーザ端末）の各々が、ローカル・コンピュータ・システムに接続された種々の機器を有してもよく、例えば、スキャナ、バーコード・リーダ、プリンタ、指紋スキャナ、マウス・デバイス、キーボード、およびその他のインタフェース、以下でより詳しく説明する例えばトークン・インタフェース１１２を有していてもよい。

サービス・プロバイダのコンピュータ・システム・ネットワーク１０２のプロセッサ・ユニット１０４は、サーバの形態をとり、それに関連するサービス／資源をローカル・ユーザ端末１０８およびリモート・ユーザ端末１１０に提供するためのフロントエンド（前部）のグラフィカル・ユーザ・インタフェース（ＧＵＩ）を提供することができる。また、プロセッサ・ユニット１０４は、例えば、システム管理者によって使用されるバックエンド（後部）のＧＵＩを提供することもできる。ローカル端末１０８およびリモート端末１１０は、プロセッサ・ユニット１０４の“クライアント”であると言われる。“クライアント”は、有線または無線のネットワークを介してサーバ・コンピュータ（“ホスト”と称される）または機器に接続可能な任意のコンピュータまたは機器である。また、クライアントは、サーバを呼び出しサーバに接続するコンピュータのソフトウェアまたはファームウェアを参照することある。前述のＧＵＩは、例えば、ユーザ端末１０８、１１０にローカルに（局所的に）存在するブラウザ・プログラムを用いて表示されるウェブページの形態を取ることができる。フロントエンドおよびバックエンドのＧＵＩは、１つ以上のデータ記憶（ストレージ）装置１０６から取り出された種々の内容（コンテンツ）を含むポータル・ページであってもよい。本明細書中で使用される、“ポータル”は、例えばヤフー（ＹＡＨＯＯ!）またはグーグル（ＧＯＯＧＬＥ）のような汎用のインターネット・ポータルに限定されるものではなく、特定の限定された視聴者にとって関心のあるＧＵＩであって、以下で説明するような異なる複数種類の関連性あるまたは関連性のない情報、リンクおよびツールへのユーザ・アクセスを提供するＧＵＩをも含んでいる。

ユーザは、ウェブ・ブラウザまたはその他のソフトウェアを用いてプログラムされたユーザ機器１０８、１１０を使用することによって、コンピュータ・システム・ネットワーク１０２におけるサービス・プロバイダのコンピュータ・プロセッサ・ユニット１０４によって提供されるサービス／資源へのアクセスを行って、特定のウェブページ（またはローカルエリア・ネットワークを介してアクセス可能な“ページ”）の位置を求め選択してもよい（例えば、マウスでクリックすることによって）。ウェブページのコンテンツは、1つ以上のデータ記憶装置１０６上に位置する。ユーザ機器１０８、１１０は、インターネットプロトコル（ＩＰ）を用いてインターネットを介して通信できるマイクロプロセッサ・ベースのコンピュータ端末であってもよく、インターネット・アクセスを有するキオスク端末、接続されたパーソナル・ディジタル・アシスタントまたはＰＤＡ（例えば、パーム社（Palm, Inc.）製のパーム（ＰＡＬＭ（登録商標））機器、コンパック（Compaq）社から入手可能なアイパック（ＩＰＡＱ（登録商標））機器、アップル社（Apple, Inc）から入手可能なアイフォン（ｉＰＨＯＮＥ（登録商標））、リム（ＲＩＭ）社から入手可能なブラックベリ（ＢＬＡＣＫＢＥＲＲＹ（登録商標））機器）、または対話型のネットワーク通信可能なその他の機器であってもよい。ユーザ機器１０８、１１０は、無線アクセス・プロトコル（ＷＡＰ）またはその他のプロトコルを用いてインターネットに接続しインターネットを介して通信するハンドヘルド・ユニット（例えば、携帯電話機またはアイポッド（iPod（登録商標）機器）のような携帯音楽再生機）のような無線機器であってもよい。また、そのシステムにおいてユーザ機器１０８、１１０をその他のタイプの機器に置き換えてもよい。１つの非限定的な例は、プロセッサが組み込まれたドア・ロックであって、ユーザ・ディスプレイ用のＧＵＩを生成する視覚的ブラウザがなく、予め定められたウェブ・サーバに隠れた要求を行い、ウェブ・サーバからの応答に従って幾つかの操作を実行し、例えば、スイッチまたはリレーをトリガ（起動）し、返信で応答したりするドア・ロックであってもよい。ユーザは、安全な領域にアクセスするために、適切に構成されたリーダにＩＤトークンを提示する。この例では、サービス・プロバイダは、企業のＩＴまたはセキュリティ・システムとして見ることができる。

ここで説明するシステムおよび方法は、図１に関連して上述した環境の全てまたは一部を用いることによって実装されてもよい。そのシステムが、ＬＡＮにまたはＷＡＮに組み込まれ、またはインターネット１１４に基づく方法（アプローチ）を通して組み込まれ、例えばホストの処理を利用する（hosted）またはホストの処理を利用しない（non-hosted）アプリケーション・サービスを介して、またはそれらの組み合わせによって組み込まれてもよいことは、当業者には明らかである。

図２は、図１に例示されたコンピューティング環境を用いて実装され得る安全なプライベート・データ記憶装置を有する集中型認証システムの特定の実施形態を例示している。認証および分散型データ記憶管理システム２０４は、サービス・プロバイダ・エージェント２２０とインタフェースを形成するためのサービス・プロバイダ・フロントエンド・モジュール２０５、結合されたユーザ端末／トークン・インタフェース２２２とインタフェースを形成するためのユーザ・フロントエンド・モジュール２０８、分散型データ・システム管理モジュール２１０、および鍵管理モジュール２１２を含んでいる。ＩＤトークン２２４は、ユーザ端末／トークン・インタフェース２２２と通信し、ユーザ端末／トークン・インタフェース２２２がインターネット１１４を介して局所的にまたは遠隔的にサービス・プロバイダ・エージェント２２０と通信するように示されている。サービス・プロバイダ・エージェント２２０およびユーザ端末／トークン・インタフェース２２２は、例えばインターネット１１４のようなネットワークを介して、認証および分散型データ記憶管理システム２０４と通信する。

図２は単一のサービス・プロバイダＦＥ（フロントエンド）２０５および単一のユーザ・フロントエンド２０８を例示しているが、これは例示のために過ぎないと理解すべきである。即ち、実施形態において、そのシステムは、各々がそれぞれのアドレスを有するサービス・プロバイダＦＥ２０５とユーザ・フロントエンド２０８の双方の複数のインスタンス（例）を含むことができる。これらのフロントエンドは、単一のノードにまたは複数のノードに配置することができる。これには２つの利点がある。第１に、地理的に分散配置されたシステムでは、ユーザおよびサービス・プロバイダは、最寄りのフロントエンドに接続することができる。第２に、ノードで障害が発生した場合でも、サービス・プロバイダおよびユーザは、他のフロントエンドにアクセスすることができる。

上述したように、サービス・プロバイダは、例えば図１に示されているように、コンピュータ・システムおよびネットワークを介して電子的に、或る形態の情報、情報アクセスまたは他の資源またはサービス（総称的にまたは個々には“資源”）へのアクセスをユーザに提供する。ユーザは、その提供されるサービスの消費者とみなすことができる。サービス・プロバイダは、或るインターネット（またはその他のネットワーク化された）サービスを、直接的に消費者へ（例えば、電子商取引）または間接的に（例えば、ユーザが個人的にまたは遠隔的に使用するロイヤルティ（ポイント）プログラムを維持することによって）提供する事業体と考えることができる。第２の意味では、サービス・プロバイダを、このインターネット（またはその他のネットワーク化された）サービスの機能を実行する複数のコンピュータ・プログラム、複数のコンピュータ、複数のネットワーク・リンクの組合せ、と考えることができる。従って、この不確実性を解決するために、サービス・プロバイダのこの特徴（観点、側面）を、サービス・プロバイダ・エージェント（ＳＰＡ）と称する。かなり頻繁に、サービス・プロバイダ・エージェントを実現するためにサービス・プロバイダによって使用されるプログラムは、幾つか例を挙げると、ウェブ・サーバ、およびデータベース管理システムである。

認証および分散型データ記憶管理システム２０４は、例えばインターネット１１４のような公的ネットワークまたは私的ネットワークであり得るネットワーク２１４を介して分散型データ記憶装置２１６と通信する。分散型データ記憶装置２１６は、複数の、好ましくは地理的に分散配置された記憶ノード２１８を含んでいる。

図２に示されたシステムは、私的ユーザと公的サービス・プロバイダの間の安全な対話（インタラクション）のためのサービス・プロバイダとのユーザ認証を容易にし、並びに、サービス・プロバイダまたはユーザに代わってユーザのプライベート・データの安全なデータ記憶（装置）を提供するように設計されている。以下で説明する種々の実施形態において、ユーザ識別コード（ユーザＩＤ）およびサービス・プロバイダ識別コード（サービス・プロバイダＩＤ）は、分散型データ記憶装置２１６からユーザ・データを検索または取り出すのに使用される。これらのコードは、永久に、認証および分散型データ記憶管理システム２０４に知られていないことが好ましい。その代わりに、それらのコードは、ユーザが認証されている間に、（仮に知られるとしても）ユーザ認証段階（フェーズ）の期間中だけ知られる（開示される）ようになる。

実施形態において、全てのユーザ・データは、幾つかの予め定められた最小数以下の記憶ノード２１８からレコード全体またはその一部を再構成することが不可能な方法で、複数のネットワーク化された記憶ノード上の１つの選択された情報分散アルゴリズム（ＩＤＡ）に従って分散される。ＩＤＡアルゴリズムを以下でより詳しく説明する。ユーザ・プロファイル（profile）として格納されているユーザ・データには、特定のユーザに関連付けられた個人および財務データ、例えば、ユーザ名、ユーザ住所、電話番号、ユーザ電子メール・アドレス、クレジットカード番号、クレジットカード有効期限日、銀行口座番号、銀行支店番号、ユーザ社会保障番号、ユーザの運転免許証番号、ユーザ識別番号、ユーザの出生地、ユーザの生年月日、ユーザの母親の旧姓、およびユーザとサービス・プロバイダの関係に関連するその他の個人識別情報を含めることができる。また、ユーザ・データには、嗜好データ、例えば、少なくとも１つの購入プロフィール（profile）、少なくとも１つの音楽プロフィール、少なくとも１つの銀行のプロファイル、および、様々な種類の取引、ベンダー、製品またはサービスに関するユーザの嗜好を示すその他のデータ、並びに、ロイヤルティ（ポイント）プログラムにおけるユーザの状態（ステータス）を表す履歴データ、または所与のサービス・プロバイダとのユーザの以前の取引履歴を表す情報、を含ませることができる。

特定のユーザを認証するための１つの手段として、そのシステムは、前述のユーザＩＤおよび1つ以上のユーザ・データ暗号化鍵（キー）を保持するハードウェアの識別トークン（ＩＤトークン２２４）のような携帯または可搬機器またはデバイスを利用する。例示的な実施形態において、任意の暗号法計算が実行され、プロトコルは、ユーザ端末２２２にではなく、ＩＤトークン２２４自体に存在する。端末２２２は、ＩＤトークン２２４およびシステムにおけるその他の構成要素（コンポーネント）との間で（それへ／それから）メッセージを渡すまたはやりとりするのを支援するに過ぎない。この方法（アプローチ）によって、任意の適切に構成されたユーザ端末、必ずしも“信頼性ある”端末だけである必要のない端末が、システムにおいて使用可能になる。その理由は、全ての安全要素がＩＤトークン２２４中に存在するからであり、ＩＤトークン２２４がハードウェアとソフトウェアの双方についてこの技術分野で既知の確立されたセキュリティ手段に従って生成されるからである。従って、そのシステムは、非常に安全であり、移動可能であり、即ち、ＩＤトークンを広範囲の安全でないコンピュータ、支払い端末、等、と共に使用することができる。

サービス・プロバイダとユーザの双方の認証の結果として、そのシステムは、認証されたユーザ／サービス・プロバイダのペア（対、組）に関連付けられたデータ・コンテナ（容器）に格納されたユーザ・データに対応する、アクセス・コードを取得することができる。このアクセス・コードはそのシステムによって使用されて、そのシステムの安全な記憶装置からデータ・コンテナが取り出される。このアクセス・コードは、ここで“資源識別子”と称され、以下でより詳しく説明する。

そのシステムの１つの有利な特徴は、ユーザ／サービス・プロバイダの認証の全ての処理には、時間および空間において一意的な（固有の）一時的トランザクション識別子（例えば、チケット）の生成を伴うことである。チケットによって、そのシステムは、所与の取引期間中にユーザをサービス・プロバイダに関連付けることができる。そのシステムは、チケットを発行した相手（受取手）を知っており、そのシステムへチケットを返す者の識別（身元）知る。チケットの有効期間（ライフサイクル）は、いずれかの一方の側（ＩＤトークン２２４のユーザまたはサービス・プロバイダ・エージェント２２０）が新しいチケットを要求したときに開始し、他方側（サービス・プロバイダ・エージェントまたはユーザ）がそのシステムに対してこのチケットを生成し返したときに終了する。チケットがそのシステムを通して循環（巡回、移動）するときに、サービス・プロバイダとユーザの間の対応関係が確立される。例えば、ユーザが（ＩＤトークン２２４を介して）チケットを要求することによって取引を開始する場合、チケットは次の循環（circular）パス（経路）を辿る（横断する）。即ち、認証および分散型データ記憶管理システム２０４のユーザＦＥ２０８→ＩＤトークン２２４→サービス・プロバイダ・エージェント／ウェブ・サーバ２２０→システム２０４のサービス・プロバイダＦＥ２０５→システム２０４のユーザＦＥ２０５（２０８）。逆に、サービス・プロバイダが（サービス・プロバイダ・エージェント／ウェブ・サーバ２２０を介して）チケットを要求することによって取引を開始する場合、チケットは次の循環パスを辿る（横断する）。即ち、認証および分散型データ記憶管理システム２０４のサービス・プロバイダＦＥ２０５→サービス・プロバイダ・エージェント／ウェブ・サーバ２２０→ＩＤトークン２２４→システム２０４のユーザＦＥ２０８→システム２０４のサービス・プロバイダＦＥ２０５。

チケットは、種々の情報を担持してもよい。実施形態において、この情報は人間が読み取り可能なサービス・プロバイダ名、このチケットが発行された位置のネットワーク・ノード・アドレス、および乱数に基づく“一度使用される番号”（nonce、ノンス、ワンタイムパスワード）の組み合わせである。

ユーザのプライベート・データのセキュリティ（安全性）は多数の手段を介して確保される。第１に、実施形態において、必要なユーザ・アクセス鍵および暗号鍵が、可搬性ＩＤトークン２２４だけに保存される。この情報のほとんどは、いかなる永続性ででもシステム２０４に知られることはない（即ち、データがハード・ディスクまたはその他の種類の不揮発性メモリに格納されることはない）。ユーザ認証が成功するためには、相互認証（例えば、ＩＤトークン２２４とサービス・プロバイダ・エージェント２２０の認証、並びに、ＩＤトークン２２４およびサービス・プロバイダ・エージェント２２０への 認証および分散型データ記憶管理システム２０４の認証）が用いられる。

ＩＤトークン２２４は、例えば、コンピュータ・チップ、集積回路、スマート・カード・チップまたはソフトウェア、またはこれらの組合せを含むハードウェアのトークンまたは埋込み型トークンのような、物理的な物体（オブジェクト）であることが好ましい。ＩＤトークン２２４がハードウェアのトークンである場合、それは、指輪またはその他の宝石、ドングル（dongle）、電子鍵、カード、例えば、ＩＣカード、スマートカード、ＲＦ ＩＤまたは近接型カード、デビットカード、クレジットカード、ＩＤバッジ、セキュリティ・バッジ、駐車カードまたは交通カード、等の形態を取ることが好ましい。ＩＤトークン２２４が埋込み型トークンである場合、それは、携帯電話機、パーソナル・ディジタル・アシスタント（ＰＤＡ）、時計、コンピュータ、またはコンピュータ・ハードウェア、等の形態を取ることが好ましい。ＩＤトークン２２４には、それが使用される特定のアプリケーションに応じて、およびそれが対話（インタラクション）を行う機器のタイプ（種類）に応じて、任意の数の異なる装置の形態を取り得るＩ／Ｏ支援要素または機器インタフェースが含まれていることが好ましい。実施形態において、Ｉ／Ｏインタフェースは、例えば無線通信ポート（例えば、近距離無線通信（ＮＦＣ）インタフェース）、シリアル・ポート、ＵＳＢポート、パラレル・ポート、または赤外線ポートのようなポートか、または、接触または非接触方式のいずれかによる外部の電子装置と通信するためのその他の或る物理インタフェースを含んでいる。

第２に、実施形態において、各サービス・プロバイダは、プライべート・ユーザと同じ方法で認証および分散型データ記憶管理システム２０４に登録され、即ち、全てのサービス・プロバイダには、固有のサービス・プロバイダＩＤおよびそれに対応するアクセス鍵および暗号鍵が与えられる。サービス・プロバイダは、ユーザ・データへのアクセスの提供を受ける前に、相互認証手順を通過する（経る）必要がある。

第３に、実施形態において、認証処理期間中に知られたユーザＩＤとサービス・プロバイダＩＤのペアを用いて、記憶システム２１６におけるデータ・コンテナを識別するアクセス・コード（即ち、“資源識別子”）が形成される。このデータ・コンテナは、特定のサービス・プロバイダがアクセス、使用および／または修正を許可されたユーザのプライベート・データを保持する。データ・コンテナは、銀行に属する鍵とクライアントに属する鍵の合計２つの鍵が開くのに必要な貸金庫（safe deposit box）を類推させることができる。全てのサービス・プロバイダＩＤ／ユーザＩＤのペアは一意的なので、ユーザのサービス・プロバイダとの各関係は自己のデータ・コンテナに関連付けられる。

第４に、実施形態において、データ・コンテナの信頼性ある記憶を提供するために、そのシステムは、幾つかの冗長性情報を追加し、そのユーザ・データを複数のネットワーク記憶ノード２１８上に分散させる。データが読み出されるとき、特定の組の複数の記憶ノードと、データ・コンテナの完全性を回復（復元）する方法とを規定するのに、ユーザＩＤとサービス・プロバイダＩＤの組合せが用いられる。分散型データ記憶は、ほとんどのアプリケーションにおいて好ましいが、本発明の全ての実施形態における要件ではない。

第５に、実施形態において、冗長性情報の使用によって、幾つかの記憶ノード（即ち、それらの或る予め定めた最小数以上の記憶ノード）が機能しなくなるイベント（事象）においても、データ・コンテナを再構成することがなお可能であることが、保証される。

第６に、実施形態において、データ・コンテナは、ユーザ認証の結果として知られるようになる秘密鍵によって暗号化される。さらに、データ・コンテナは、サービス・プロバイダの秘密鍵によって暗号化されてもよい。

第７に、実施形態において、上述したように、データ・コンテナは、ユーザＩＤとサービス・プロバイダＩＤの一意的な組合せによって識別することができる。しかし、識別子が（幾つかの場合では、単に“ファイル名”）が、それらのＩＤの単なる連結である場合には、潜在的な安全性の問題が発生することがある。例えば、利用可能なデータ・コンテナの完全なリストにアクセスできる人は、特定のユーザＩＤに関連付けられた全てのデータを見つけることができる。この可能性を回避するために、ユーザＩＤとサービス・プロバイダＩＤの組合せが、データ・コンテナの資源識別子を生成するための一方向関数によって変換されて、その結果として得られるアクセス・コードからユーザＩＤまたはサービス・プロバイダＩＤのいずれかを回復（復元）することが不可能であるようにする（任意の実用的な意味で）。

ユーザの観点でのシステム：
ユーザの観点からは、ユーザ認証は、少なくとも“誰かが持っているもの”（what somebody has）という原則に基づいており、ＩＤトークン２２４に基づいている。上述のように、ＩＤトークン２２４は、ユーザが自由に使える状態で持っている小型の電子機器（デバイス）であることが好ましい。図３Ａ〜３Ｄは、ＩＤトークン２２４の多数の可能性ある実施形態の幾つかを示しているに過ぎない。ユーザの観点からは、ＩＤトークン２２４は多くのドア（扉）を開く“ユニバーサル・キー”（汎用の鍵）である（即ち、それは多くの相異なるサービス・プロバイダに対してユーザを認証するために使用できる）。

高いセキュリティを必要とするＩＤトークン機器（デバイス）の複数のアプリケーションについて、その機器（デバイス）は、またはその機器はＩ／Ｏ支援要素と組み合わせで、次の各構成要素（コンポーネント）を含んでいてもよい。即ち、ユーザがメッセージを作成しまたは修正するのを可能にする、キーパッド（英数字）、対話型ディスプレイ、またはその他のタイプのユーザ・データ入力機構（総称して、“ユーザ・インタフェース”と称する）；秘密を表すデータを入力するためのユーザ・インタフェース（メッセージを生成しまたは修正するためのユーザ・インタフェースは、秘密を表すデータを入力するためのユーザ・インタフェースと同じであってもよいが、同じである必要はないことに、留意すべきである）；ユーザに対してメッセージおよび／または秘密を表示するためのディスプレイ；ユーザの生体的特徴に関する少なくとも１つのタイプの生体的データを受け入れまたは入力するためのスキャナまたはリーダ（読取り機）；認証されるユーザの秘密、認証されるユーザの生体的データ、および／またはその他のセキュリティ（安全）情報を格納するためのメモリ；秘密または生体的データの入力を、認証されるユーザの秘密または生体的データとして検証するためのプロセッサまたは回路；ディジタル署名を生成しまたは発生させるためのプロセッサまたは回路；および／または、その機器から出力し、そのためのメッセージおよびディジタル署名を含む情報を送信するための出力部。また、その機器は、１つまたは複数の暗号鍵、トークンＩＤ、ユーザＩＤおよびその他の情報を格納しエクスポート（他へ転送）するためのメモリを含んでいることが好ましい。より低いセキュリティ・レベルのアプリケーションでは、上述の要素の全てが必要になるわけではない。

或る複数の実施形態において、ＩＤトークンは、例えば、重要なアプリケーション用の“被認証者が知っていること”（what you know）の認証符号またはコード（例えば、ＰＩＮ）のような第２の種類の認証基準を要求するのに、および認証処理期間中にサービス・プロバイダ名を表示するのに充分な高い性能（スマートさ）を有する。

図３は、ＩＤトークン２２４の機能的構成要素（コンポーネント）のブロック図である。ＩＤトークンの心臓部は安全要素（素子）１０であり、その安全要素（素子）１０は、マイクロプロセッサ、命令処理およびデータ記憶用のメモリ（例えば、ＲＡＭおよびＲＯＭメモリ）、および入力／出力（Ｉ／Ｏ）インタフェースを含んでいる。マイクロプロセッサは、そのメモリ内のプログラムに従って動作する。以下のセクションで詳しく説明するように、全てのＩＤトークンは、そのメモリ内に、トークンＩＤ、トークン・キー（鍵）、ユーザＩＤ、および任意選択的にユーザ・データ暗号鍵を格納している。トークンＩＤは、このトークンに割り当てられ認証システムに知られている固有の（一意的な）番号である。それは、秘密のパラメータではなく、ＩＤトークンを認証するのに使用される。

トークン・キーは、秘密のパラメータである。また、このトークン・キーは認証システムに知られている。このトークン・キーは、トークンとシステムの間の相互認証、およびそのシステムとトークンの間の暗号化された通信チャネルの生成に使用される。

ユーザＩＤは、ＩＤトークンに格納される最も高い機密性の（センシティブな）パラメータである。このユーザＩＤは、ユーザの格納されたデータを取り出すまたは検索するのに使用される資源識別子（例えば、データ・コンテナ名）を導出するのに使用される。それがＩＤトークンの外部に送信される場合があるとすれば、それは暗号化されたチャネルを介して認証システムに送信される場合だけであるべきである。

ユーザ・データ暗号鍵は、任意選択的（オプション）であり、データがＩＤトークンによって符号化／復号され得る（好ましくは、符号化／復号される）幾つかのアプリケーションで使用される。例えば、ユーザは、パスワードの格納用またはその他の個人データの格納用の分散型データ記憶システムを使用することもできる。ユーザは、ユーザ端末を介してこのデータにアクセスする。データがその記憶システムから取り出されたとき、ユーザ端末は、その取り出されたデータを暗号解読用のＩＤトークンに渡し、ユーザ端末へと返させて（ユーザ端末で）そのデータを表示および／または編集させるようにし、そのデータを暗号化のためにＩＤトークンに渡し返してその後でその分散型データ記憶システムに送信し返して格納させるようにすることができる。

安全要素並びにそのソフトウェアのアーキテクチャによって、確実に、トークン・キー（および、場合によってユーザ・データ暗号化鍵）がトークン・メモリからエクスポート（転送）できないようにされる。また、それらは、確実に、ユーザＩＤが、暗号化されたチャネルを介してだけ送信され得るようにする。

安全要素の１つの可能な実装形態は、暗号カードである。利用可能なカードは、レガシーＩＳＯ−７８１６接触インタフェース、非接触インタフェース（例、ＩＳＯ１４４４３）またはＵＳＢインタフェース（またはこれらのインタフェースの任意の組合せ）によって通信することができる。幾つかの事例では、安全要素は、外部非接触送受信機との通信のためにＳＷＰ−インタフェースを有してもよい。この安全要素は、“ＩＤ−Ｉ”プラスチック本体（例えば、周知の銀行カード本体）内にパッケージ（収容）されていても、または携帯電話機で使用されているような安全なマイクロプロセッサおよびメモリを有するＳＩＭカードに含まれていてもよい。代替形態として、安全要素は、給電（電源）および通信用のインタフェース接続を有する適切に構成されたＩＤトークン本体にはんだ付けするための（またはその他の接続用の）複数のピンを有するパッケージされたダイ（die、半導体チップ、ダイス）の形態を取ってもよい。

最も単純な形態のＩＤトークンは、ＵＳＢインタフェースを介してまたはカード・リーダを介してコンピュータに接続するＩＤ−ｌスマートカードである。その場合、サービス・プロバイダ名を表示し認証のためにユーザの同意を受け取るのは、ユーザ端末におけるソフトウェアの担当である（以下の種々の実施形態で説明する）。

幾つかの実施形態において、安全要素は、自己のユーザ・インタフェース２０、即ち、ディスプレイ、ボタン、タッチ・スクリーン、等を有することが可能であってもよい。その解決法は、ユーザ端末におけるいかなるソフトウェアにも依存しないので、好ましい。

安全要素が自己のユーザ・インタフェース２０を持たない場合、それは、外部ユーザ端末（例えば、カード・リーダまたはコンピュータ）と通信するために自己のユーザ・インタフェース４０並びに自己の電子機器３０を提供するハウジング（例えば、ＭＰ３プレーヤ、ＰＤＡまたは携帯電話機）に組み込まれていてもよい。幾つかの携帯電話機、ＰＤＡ、等は、既に要素（コンポーネント）１０、３０および４０を含んでいるものがある。ＩＤトークンの機能は、その機器のアプリケーション中に実装することもできるであろう。安全要素は、第３世代（３Ｇ）のマルチアプリケーション（多用途）ＳＩＭカード、または特別にインストールされた第２の暗号要素であってもよい。任意の数のインタフェース（例えば、ブルートゥース（Bluetooth）またはＵＳＢ）を用いてその機器をユーザ端末に接続してもよい。

ユーザ端末は、必要な場合には、ユーザ端末上のブラウザと、ユーザ・フロントエンド２０８と、ＩＤトークン２２４との間の種々の通信をルーティング（経路指定）するためのソフトウェアを含んでいてもよい。このソフトウェアは、例えば、ブラウザのプラグインの形態で、またはサービス（デーモン）として実行されるプログラムを含めて実行可能なプログラムまたはドライバの形態で、ユーザ端末上に常駐することができる。ユーザ端末ソフトウェアの幾つかの部分は、例えばアプレット（applet）として各セッション毎にダウンロードされてもよい。サーブレット（servlet）ベースのアプローチ（方法）を使用してもよい。図３Ａは、基本的なスマートカードまたはフォブ（fob）タイプのＩＤトークン２２４Ａを示している。ＩＤトークン２２４Ａは、ユーザ端末／トークン・インタフェース２２２のＩ／Ｏインタフェースとインタフェースするための、例えばＵＳＢコネクタのようなＩ／Ｏ２２５を含み、それ（ユーザ端末／トークン・インタフェース２２２）は、サービス・プロバイダ構内にまたはインターネット・アクセスを有するユーザのコンピュータに位置する特殊なまたは専用の端末（例えば、商業者用のＰＯＳ端末）であってもよい。例えばＵＳＢのような有線インタフェースの代わりに、ＩＤトークン２２４Ａは、適切に構成されたユーザ端末／トークン・インタフェースとインタフェースするための無線インタフェースを有することができる。また、実施形態において、ＩＤトークン２２４Ａは、活動化（活性化）ボタン２２７（“同意”（consent）ボタン）を含んでいる。

図３Ｂは、ＩＤトークン２２４Ｂの代替的な実施形態を示している。ＩＤトークン２２４Ｂは、スクリーン（画面）またはディスプレイ２２９および入力ボタン２３１を含むユーザ・インタフェースを有する。また、ＩＤトークン２２４Ｂは、無線通信インタフェース（無線通信２３３で示される）、例えば、赤外線データ関連（アソシエーション）（IrDA）のインタフェース、非接触近距離無線通信（ＮＦＣ）インタフェース、またはブルートゥース（Bluetooth）インタフェースを含んでいる。図３Ｃおよび３Ｄは、ＩＤトークン機能が、携帯電話機２２４Ｃおよび２２４Ｄにその携帯電話機内にあるアプリケーションとして組み込まれていてもよいこと、を示している。図３Ｃの実施形態において、携帯電話機２２４Ｃは、ユーザ端末のＵＳＢポートに／有線接続２３５によってトークン・インタフェース２２２に、接続することができる。代替形態として、図３Ｄの実施形態において、携帯電話機２２４Ｄは、ユーザ端末／トークン・インタフェース２２２と無線で通信することができ（無線通信２３７で示される）、例えば、ＮＦＣ、ブルートゥース、ＳＭＳ／ＧＰＲＳ／３Ｇまたはその他の適切な技術で通信することができる。

特定のサービス・プロバイダのウェブ・サイトにアクセスするユーザを認証するために、またはサービス・プロバイダの設備（即ち、ＰＯＳ端末）においてユーザを認証するために、ユーザは、ユーザ端末／トークン・インタフェース２２２に自己のＩＤトークン２２４を接続する。それ（ユーザ端末／トークン・インタフェース）は、ユーザのパーソナル・コンピュータまたはサービス・プロバイダにおける端末であってもよい。ユーザは、トークン２２４上のボタンを押して、ユーザがサービス・プロバイダに対して認証されるように試みるまたは求めていることを確認する。実施形態において、同意ボタンは、ユーザ端末のディスプレイ上のソフト・ボタンとして実装することもできる。トークンの認証およびサービス・プロバイダの認証（以下、そのプロセスを詳しく説明する）の結果として、サービス・プロバイダには、ユーザとの対話（インタラクション）のためにサービス・プロバイダが必要とするユーザのデータへのアクセスが提供される。このデータ（例えば、顧客プロファイル）は、分散型データ記憶装置２１６から取り出されて組み立てられてサービス・プロバイダ・エージェント２２０に送信される。ユーザ・データによって、サービス・プロバイダは、例えば、ユーザに対処またはアドレスする方法、ユーザがどの程度のロイヤルティを有するか（利用度合を有する、ひいきにしているか、忠誠であるか）、およびどんな種類の割引を提供すべきか、を知ることができる。サービス・プロバイダは、ユーザのデータを修正または変更して、それを認証および分散型データ記憶管理システム２０４に送信し返して、分散型データ記憶装置２１６内に安全に格納されるようにすることができる。慎重に扱うべき（敏感な）データは、サービス・プロバイダ・エージェント／ウェブ・サーバまたは関連するデータ記憶装置において維持（保存）されず、従って不適切なアクセスに対して脆弱ではない。

上述したように、そのシステムの機能は、貸金庫の機能に類似している。ユーザによってサービス・プロバイダに供与または許可された個人データは、仮想的な貸金庫に格納される。その貸金庫を開くには、２つの鍵が必要であり、ユーザからの１つの鍵と、サービス・プロバイダからの１つの鍵が必要となる。貸金庫がいったん開くと、サービス・プロバイダは、そのデータを取得し、それをユーザとの現在のセッションにおいて使用する。そのセッションが終了したとき、サービス・プロバイダは、修正（変更）されたデータを貸金庫に戻すか、または修正（変更）されていない内容（コンテンツ）と共に貸金庫を返してもよい。

それぞれの“貸金庫”または“データ・コンテナ”が特定のユーザ／サービス・プロバイダのペアに関連するデータのみを含んでいることに留意することが重要である。このユーザ・データは、サービス・プロバイダのウェブ・サイトにおいてまたはロイヤルティカードの発行時にユーザの登録情報の一部として生成されてもよく、ユーザとの関係が進展するにしたがってそのプロバイダとのユーザの履歴を反映するように、更新されてもよい。“登録”とは、サービス・プロバイダとの永続的な関係を確立するために、ユーザが、サービス・プロバイダに識別情報を供与する操作を意味する。その後、サービス・プロバイダは、或る形態（フォーム）の認証情報（authentication credentials、信用証明書）を用いて、ユーザを認識する。別のサービス・プロバイダのユーザ・データは、別個のデータ・コンテナ（“ボックス”（箱））に格納され、その特定のサービス・プロバイダにだけ利用可能となる。

サービス・プロバイダの観点でのシステム：
第三者の識別／認証用におよび安全なプライベート・データ格納用に認証および分散型データ記憶システムを使用するために、サービス・プロバイダは、最初に、認証および分散型データ記憶管理システム２０４に登録を行う必要がある。サービス・プロバイダには、サービス・プロバイダＩＤと、認証およびトラフィック暗号化用の１つ以上の秘密鍵とが割り当てられる。これらの秘密鍵およびサービス・プロバイダＩＤは、サービス・プロバイダのサーバにおいてインストールされ、例えばサーバのＵＳＢポートなどにおいてインストールされるスマートＵＳＢトークンの形態で供給することができる。サービス・プロバイダがそのサービス・プロバイダ・エージェント２２０としてホスティング・サービス（ホスト・サービス）を使用する場合は、この情報を、ホスティング・サービスに例えばソフトウェア・トークンとして提供することができる。次いで、任意の必要なソフトウェアが、サービス・プロバイダ・エージェント／ウェブ・サーバ２２０にインストールされて、この種類の第三者の識別／認証が有効にまたはイネーブルされる。例えば、そのソフトウェアは、一般的に、それぞれの認証システムを使用するそれらウェブ上の存在（エンティティ、事業体）のためのＯｐｅｎＩＤファウンデーション（オープンＩＤ財団、協会）によって提供されるものに類似したライブラリを含んでいてもよい。そのライブラリはサーバ上にインストールされて、サービス・プロバイダのウェブ・ファイル／プログラムに、修正（変更）が行われて（施されて）、ユーザ認証／データベース要求に対してこのライブラリの手順を呼び出すようにされる。一例として、今日最も広く使用されているサーバであるアパッチ（Apache）ウェブ・サーバは、認証用の外部モジュールを使用できるように構成される。モジュール名は、ｍｏｄ＿ａｕｔｈ＿ＸＸＸで開始し、ここでＸＸＸは認証方法である。従って、このモジュールは、サービス・プロバイダのサーバによって使用するために提供することができる。サービス・プロバイダは、特定のユーザに関連付けられたユーザ・データを格納する認証および分散型データ記憶管理のシステム２０４を信頼するように選択してもよい。代替形態として、サービス・プロバイダが既に信頼できるデータベースに大規模な投資を行っていて、そのコア技術を設計し直すことを希望しない場合には、例えばサービス・プロバイダによってその提示されたユーザに関連付けられるサービス・プロバイダのローカル・ユーザＩＤのような複数の或る情報だけを、分散型データ記憶システム２１６内に格納することが可能である。この形態のユーザ・データは、必ずしも分散された形態で格納される必要はないが、分散された形態で格納されてもよい、と理解すべきである。いずれの種類サービスが選択されても、ユーザが経験することは同じである。

サービス・プロバイダがウェブページを通してユーザと対話する場合は、サービス・プロバイダは、適切なグラフィカル（図形）シンボル、テキスト・プロンプト（ＯｐｅｎＩＤまたはマイクロソフトＬｉｖｅＩＤのシングル・サインオン・サービス・シンボルに類似したもの）、または、ユーザのＩＤトークン２２４を使用してユーザが自己を認証するのを可能にするボタンを、追加するように、そのログイン・ページを修正することが好ましい。ユーザがボタンを押しまたはグラフィカル・シンボルをポイントして（指して）クリックした場合に、新しいグラフィカル・ユーザ・インタフェース（例えば、ウェブページ）がユーザに対して表示されてもよい。この新しいグラフィカル・ユーザ・インタフェースは、自己のＩＤトークン２２４を（有線または無線接続で）プラグインして、ユーザのＩＤトークン２２４を活動化する（例えば、図３Ａの実施形態における“同意”ボタンを押下する）よう、ユーザに指示する。ユーザがＩＤトークン２２４を活動化すると、新しい認証トランザクションが開始する。ユーザおよび／またはサービス・プロバイダを認証する認証処理（プロセス）において、一時的なトランザクション識別子（例えば、“チケット”）が、生成（作成）されて使用される（以下でより詳しく説明する）。チケットは、認証および分散型データ記憶管理システム２０４によって発行され、ユーザ端末／トークン・インタフェース２２２とサービス・プロバイダ・エージェント２２０との間で渡される。認証が成功した場合、サービス・プロバイダ・エージェント２２０は、認証および分散型データ記憶管理システム２０４から、格納されたユーザ・データを受信する。例えば、サービス・プロバイダ・エージェント２２０は、サービス・プロバイダによってそれまでに収集された特定のユーザに関する全ての情報、即ち、サービス・プロバイダへの初期ユーザ登録の期間に収集されたユーザ情報を過去履歴データ（例えば、購入またはその他の取引履歴、等）と共に、受信できる。サービス・プロバイダが、自己のデータベースに全てのユーザ・データを保持（保存）することを選択した場合は、その取り出されたデータは、ユーザ・レコードへのポインタ（または参照またはキー）だけを、例えば、サービス・プロバイダ・エージェント２２０にアクセス可能なデータベース・システムにおいて使用されるユーザ識別子の形態で、担持してもよい。

図４は、認証および分散型データ記憶管理システム２０４のユーザ・フロントエンド・モジュールまたはエンジン２０８の概略図である。ユーザ・フロントエンド（ユーザＦＥ）２０８は、ネットワーク接続されたコンピュータ上で実行されるコンピュータ・プログラムの形態を取ることが好ましい。このコンピュータは、プロセッサ、ランダムアクセス・メモリ、複数のネットワーク・インタフェース、大容量記憶装置（例えば、ハードディスク・ドライブ）を有する。このコンピュータがユーザＦＥ機能のためだけに使用される場合、ハード・ディスク上に格納されたデータは、主にＯＳ（オペレーティング・システム）ファイルおよびユーザＦＥプログラムを含んでいる。また、ユーザＦＥ２０８はコンフィギュレーション（装置構成）データを含んでおり、そのコンフィギュレーション・データを用いて、認証および分散型データ記憶管理システム２０４の他のコンポーネント（構成要素）（例えば、分散型データ記憶管理エンジン２１０、サービス・プロバイダ・フロントエンド・エンジン２０６および鍵（キー）管理エンジン２１２）が発見され（検出され）、その発見は、その他のコンポーネントが、認証および分散型データ記憶管理システム２０４を形成するその他のネットワーク接続されたコンピュータ／プロセッサ上にまたは（仮想的またはそれ以外の）ネットワーク内のその他のＩＰアドレスに存在する範囲で、行われる。ネットワークの観点では、ユーザＦＥ２０８は、他の機器との通信にインターネット・プロトコル（ＩＰ）を使用し、３つの主要な接続点を有する。関心ある第１の接続は、ユーザ端末／トークン・インタフェース２２２からトークン・サーバとしてのユーザＦＥ２０８への接続２３９である。このトークン・サーバは、パブリック（公衆、公開）ＩＰアドレスを有し、ユーザ端末／トークン・インタフェース２２４からの全ての認証要求のための入口点（位置）である。これらの要求は世界中から到着してもよい。ユーザＦＥ２０８は、分散型データ管理エンジン２１０への接続点である別の（第２の）ＩＰ接続２４１を有する。ユーザＦＥ２０８は、この接続２４１を使用して、相互のユーザＦＥ ／ＩＤトークン認証用のＩＤトークン対称鍵を含むデータを読み取る。この接続は、システム内接続であり、内部システムＩＰアドレス（例えば、仮想プライベート・ネットワーク（ＶＰＮ）内のアドレス）を有してもよい。最後に、ユーザＦＥ ２０８は、サービス・プロバイダ・フロントエンド２０５との間でデータ（例えば、チケット、ユーザＩＤまたはその他の情報）を交換するための接続２４３を有する。また、この接続は、例えばＶＰＮを介して、システム内ネットワーク接続を使用してもよい。

ユーザ・フロントエンド２０８は、ＩＤトークン２２４を使用したユーザの認証を担当する。認証は、一意的な固有のトークン番号と、ユーザＦＥのトークン秘密鍵の知識に基づく。トークン秘密鍵（並びに、イネーブル／ディセーブル状態、およびその他の可能なパラメータ）は、例えば分散型データ記憶管理エンジン２１０によって管理される分散型データ記憶システム２１６のような外部記憶システムに格納されてもよい。このオプション（任意選択）によって、ユーザＦＥ２０８は、トークンを記述するレコードをそのメモリまたは取り付けられた大容量記憶機器（装置）に保持しないようにすることができる。認証に成功した後、ＩＤトークン２２４は、その本当の秘密データであるユーザＩＤを送信する。そのユーザＩＤは、システムにおいてＩＤトークン２２４に格納され分散型データ記憶システム２１６からのデータ取り出しに使用される一意的な固有のユーザ番号である。ユーザＩＤは、ＩＤトークンに格納される別のＩＤであるトークンＩＤで確認されるべきではない。そのトークンＩＤは、データ・コンテナの取り出し（検索）のためのサービス・プロバイダＩＤとの関係（接続）では使用されない別のＩＤである。ユーザＦＥ２０８は、このユーザＩＤを受信すると、そのランダムアクセス・メモリに一時的なデータ構造２４５を生成する。このデータ構造２４５は、次のような新しく生成されたトランザクションに関する情報を保持する。
（ｉ）トランザクションの一意的な固有の識別子（ここで、“一時的なトランザクション識別子”または“チケット”と称する）。これは、乱数と、ユーザＦＥ２０８のネットワーク・アドレスとを含むことが好ましい。
（ii）ユーザＩＤ、および
（iii）ユーザ・データ暗号化鍵（任意選択的）。

全ての各トランザクションには“存続時間”（time-to-live）パラメータが割り当てられ、そのパラメータは、トランザクションがユーザＦＥ２０８のメモリに保持され得る最大の時間期間を表す。その存続時間パラメータに関係なく、データ構造２４５を、そこに含まれているデータをサービス・プロバイダ・フロントエンド２０５に供給する手段として使用することができる。

図５は、認証および分散型データ記憶管理システム２０４のサービス・プロバイダ・フロントエンド・モジュールまたはエンジン２０６の概略図である。サービス・プロバイダ・フロントエンド２０５は、ネットワーク接続されたコンピュータ上で実行されるコンピュータ・プログラムの形態を取ることが好ましい。このコンピュータは、プロセッサ、ランダムアクセス・メモリ、複数のネットワーク・インタフェース、および大容量記憶装置（例えば、ハードディスク・ドライブ）を有する。このコンピュータがサービス・プロバイダＦＥ機能のためだけに使用される場合、ハード・ディスクに格納されるデータは、主にオペレーティング・システム・ファイルおよびサービス・プロバイダＦＥプログラムを含んでいる。また、サービス・プロバイダＦＥ２０８はコンフィギュレーション（装置構成）データを含んでおり、そのコンフィギュレーション・データを用いて、認証および分散型データ記憶管理システム２０４の他のコンポーネント（例えば、分散型データ記憶管理エンジン２１０、ユーザ・フロントエンド・エンジン２０８）が発見され、その発見は、その他のコンポーネントが、認証および分散型データ記憶管理システム２０４を形成するその他のネットワーク接続されたコンピュータ／プロセッサ上に存在しまたは別のＩＰアドレスに位置する範囲で、行われる。ネットワークの観点では、サービス・プロバイダ・フロントエンド２０５は、インターネット・プロトコル（ＩＰ）通信を支援し、３つの接続点を有する。第１の接続点２４７は、サービス・プロバイダ・エージェント２２０用のアクセス・ポイントである。このアクセス・ポイント２４７は、好ましくはパブリックＩＰアドレスによって、サービス・プロバイダ・エージェント２２０との全ての交換に使用される。サービス・プロバイダ・フロントエンド２０５は、分散型データ記憶管理エンジン２１０と通信するための第２のＩＰ接続点２５１を有する。サービス・プロバイダ・フロントエンド２０５は、この接続を使用して、ユーザ・データを含むデータ・コンテナを分散型データ記憶管理エンジン２１０との間で（に）受信／送信する。システム内接続であるこの接続は、例えば、ＶＰＮ内アドレスのような内部システムＩＰアドレスを有してもよい。最後に、サービス・プロバイダ・フロントエンド２０５は、ユーザ・フロントエンド２０８との間でデータ（チケット、ユーザＩＤ、またはその他の情報）を交換するための第３の接続２４９を有することが好ましい。また、この接続は、システム内ネットワーク・アドレス、例えばＶＰＮ内のアドレス、を使用する。

サービス・プロバイダ・フロントエンド２０５は、サービス・プロバイダ・エージェント２２０が、システム（認証および分散型データ記憶管理システム２０４）からユーザ・データを取得するために接続する、認証および分散型データ記憶管理システム２０４における“ソケット”と見なすことができる。サービス・プロバイダ・フロントエンド２０８は、サービス・プロバイダ・エージェント２２０の認証、トランザクション識別子（“チケット”）転送、および認証および分散型データ記憶管理システム２０４とサービス・プロバイダ・エージェント２２０の間でのユーザ・データ交換、を担当する。以下でより充分に説明する実施形態において、サービス・プロバイダ・フロントエンド２０５は、サービス・プロバイダ・エージェント２２０から“チケット”を受信したとき、そのチケットを発行したユーザＦＥ２０８のネットワーク・アドレスを計算して、ユーザＩＤおよび（任意選択的に）要求ユーザＦＥ２０８に対してユーザ・データ暗号鍵を要求する。次に、サービス・プロバイダＦＥ２０５は、サービス・プロバイダＩＤとユーザＩＤを組み合わせて、データ・コンテナを識別する資源識別子を取得するためにこの組合せを難読化する（obfuscate）。サービス・プロバイダ・エージェント２２０は、分散型データ記憶管理システム２０４に、データ・コンテナ上の特定の動作または操作（生成（作成）、読取り、書込み、削除）を実行するよう要求する。“生成”（create）動作の場合、空のデータ・コンテナが生成されてもよい。“読取り”（read）動作の場合、データ・コンテナは、ＤＤＳ管理システム２１０によってサービス・プロバイダＦＥ２０５へ供給され、任意選択的にユーザ・データ暗号鍵で復号され、サービス・プロバイダ・エージェント２２０に送信される。

“書込み”（write）動作において、サービス・プロバイダＦＥ２０５は、サービス・プロバイダ・エージェント２２０からデータを受信して信頼性ある格納（記憶）を行う。サービス・プロバイダＦＥ２０５は、任意選択的にユーザ・データ暗号鍵を用いてこのデータを暗号化し、分散型データ記憶管理システム２１０にデータ・コンテナを送信して格納させる。“削除”（delete）動作は、分散型データ記憶管理システム２１０がデータ・コンテナを破壊することを要求する。

図６は、分散型データ記憶装置（ＤＤＳ）２１６およびその各接続をより詳しく示している。ＤＤＳ２１６は、２種類のシステム資源：（ｉ）ＩＤトークン秘密鍵とＩＤトークン状態（ステータス）を有するデータ・コンテナ、および（ii）プライベート・ユーザ・データを有するデータ・コンテナ、を保持するために、そのシステムにおいて使用される。全てのデータ・コンテナは、そのシステムにおける一意的な固有の複数の識別子の組合せ即ち（ユーザ・データを有するデータ・コンテナの場合）ユーザＩＤとサービス・プロバイダＩＤに基づいたアルゴリズムを用いて導出された資源識別子（即ち、ファイル名）によって識別される。また、その他の値がその組合せに関与（寄与）してもよい。この組合せは、一方向関数によって難読化される。“一方向関数”は、計算しやすい関数であるが、その逆関数は計算が非常に困難なものである。一方向関数の結果が、ＤＤＳ２１６からデータ・コンテナを取り出すのに使用される資源の識別子を与える。難読化の目的は、資源識別子からユーザＩＤおよび／またはサービス・プロバイダＩＤを復元（回復）することを不可能する（実際的な意味で）ことである。

１つの例示的な実施形態において、その難読化は、既知の公開鍵を用いたＲＳＡ符号化手順を使用する。暗号法において、ＲＳＡ（Rivest, Shamir and Adleman）は、公開鍵暗号法のアルゴリズムである。ＲＳＡは、広く電子商取引プロトコルにおいて使用され、安全な所与の充分に長い鍵であると信じられている。ＲＳＡは公開鍵および秘密鍵（private key）を使用する。公開鍵は誰にでも知られることができ、メッセージを暗号化するのに使用することができる。公開鍵で暗号化されたメッセージは、秘密鍵を用いて復号することができる。公開鍵は、モジュロ（法）“ｎ”と、公開（または暗号）指数“ｅ”とで構成される。秘密鍵は、モジュロ（法）“ｎ”と、秘密に保持されるべき秘密（または復号）指数“ｄ”とで構成される。認証システムは、公開／秘密鍵ペア（対）を生成する。公開鍵は、資源識別子（例えば、実施形態に応じて、ＩＤトークン２２４または認証および分散型データ記憶管理システム２０４）の生成を担当するそのシステムにおけるノードに格納される。秘密鍵は、破壊／削除されるか、または災害の場合のデータ復元（回復）のために高い安全性の記憶装置に確保または保存される。資源識別子を導出するために、ユーザＩＤおよびサービス・プロバイダＩＤが最初に連結される。即ち、例示のみのために説明すると、ユーザＩＤが０１１０（２進法）でありサービス・プロバイダＩＤが１１１０である場合、その連結（ユーザＩＤ｜サービス・プロバイダＩＤ）は０１１０１１１０である。この連結は、公開鍵、即ち、資源識別子＝（（ユーザＩＤ｜サービス・プロバイダＩＤ）＊＊ｅ）ｍｏｄ ｎで暗号化される。公開鍵暗号法は一方向関数として機能する。その理由は、ユーザＩＤおよびサービス・プロバイダＩＤを明らかにするために資源識別子を復号するのに秘密鍵（プライベート・キー）を利用できないからである。

ＤＤＳは、複数の記憶ノード２１８を含んでいる。ＤＤＳ管理エンジン２１０は、１つ以上のデータ・コレクタ（データ収集器）２１１を含んでいることが好ましい。記憶ノード２１８は、ハード・ディスク（例えば、固体ディスク・ドライブ）を備えた、ネットワーク接続されたコンピュータである。それらの主な機能（タスク、仕事）は、ユーザ・データを永続的に格納することである。各データ・コレクタ２１１は、ユーザＦＥ２０８、サービス・プロバイダＦＥ２０５および鍵管理２１２のエンジンから要求を受け取ることである。これらの要求は、名称が付された資源を、“生成し”（CREATE）、“読み取り”（READ）、“書き込み”（ERITE）、または“削除する”（DELETE）ことの要求である。各要求の基本的（本質的）部分は、資源識別子である。或る実施形態において、資源は、情報分散アルゴリズム（ＩＤＡ）に従って分散形態で格納される。資源がそのシステムに格納された（書き込み動作）とき、データ・コレクタ２１１はＩＤＡを実行して、資源データを複数（例えば、１０〜２０個）のデータ・セグメントとその計算された派生物（derivatives、派生値、導関数、微分係数）（冗長化のため）とに変換し、各セグメントを別個の記憶ノード２１８に送信する。読取り要求を実行するために、データ・コレクタ２１１は、最初に、最も近い記憶ノード２１８からその対応するセグメントを収集し、１つ以上のノード２１８が失敗した場合、データ・コレクタ２１１は、その他のノード２１８から（を）それらのセグメントを（について）取得する。ＩＤＡの固有の（本質的な）冗長性を用いてデータが保持（保存）され、また、それを用いてデータ・エラーをチェックすることもできる。

種々のＩＤＡは、例えば使用されるマトリックスおよび演算、およびＩＤＡがエラーをそれ自体でまたは幾つかのその他のデータに依存して識別することを試みるかどうか、といった特定の細部について、異なってもよい。しかし、各ＩＤＡＳは同様の形態で動作する傾向がある。ＩＤＡの動作は、次の例によって例示することができる。例えば１２３４５６７８のような長い数を分散形態で格納すると仮定する。この数値を安全に格納するために、それを１２３４と５６７８の２つの半部に分割する。前半部（１２３４）は第１の記憶ノード（ノード＃１）（例えば、第１のデータ・サーバ）に格納される。後半部（５６７８）は、第２の記憶ノード（ノード＃２）に格納される。次に、それらの半部の或る派生値が、例えばそれら半部の総和、即ち６９１２として、計算される。この派生値は、第３のデータ記憶ノード（ノード＃３）に格納される。このアプローチでは、３つの記憶ノードの中のいずれかが失われ／壊れている／利用できないことがあっても、元のデータは、残りの２つのノードから回復または復元することができる。例えば、ノード＃１がダウン（停止）している場合、元のデータはノード＃２と＃３の値を用いて回復（復元）することができる。即ち、ノード＃１におけるデータは、ノード＃３におけるデータからノード＃２におけるデータを減算することによって回復（復元）される。同様に、ノード＃２が使用できない場合、そのデータは、ノード＃２における値からノード＃１における値を減算することによって導出することができる。

２つの記憶ノードが利用可能な場合は、その記憶容量を１．５倍に（単に２つのノードで１２３４と５６７８を保存する場合と比較して）増加させることによって、元の情報が回復（復元）可能である。また、導出された冗長セグメントのユーザは記憶容量の要求を削減させることに留意されたい。即ち、純粋なミラーリングの冗長性が使用される場合には、４つの記憶ノード（即ち、１２３４を格納するための２つのノードと、５６７８を格納するための２つのノード）が必要になるであろう。さらに、より多くの記憶ノードを（３つではなく４つ）を使用しながら、それぞれのノードの全ての組合せを用いて元のデータを回復（復元）することができる。例えば、元のデータは、５６７８が格納された２つのノードからは回復（復元）することはできない。

上述の３つのノードの冗長方式は、（ｍ，ｋ）＝（２、１）、ｍ＋ｋ＝ｎ＝３としてモデル化することができる。ここで、ｍは元のデータのサイズ（セグメント単位）および情報を回復（復元）するのに必要な絶対的最小数のセグメントを表し、ｋは冗長データ（即ち、失うことができるデータのセグメント数）を表し、ｎはチャンク（塊）の総数を表す。

第４の記憶ノードが第２のノードと第１のノードのデータの間の差、即ち４４４４（５６７８−１２３４）を格納するために追加された場合に、良好な結果を得ることができる。元の（即ち、非派生の）データ部分（例えば、１２３４と５６７８）を含むセグメントが利用可能でなかったとしても、記憶容量は２倍である（単に２つのノードにデータを格納する場合と比較して）が、任意の２つのセグメントのデータを用いて、元の情報は回復（復元）することができる。例えば、ノード＃１とノード＃２の双方が利用不可能でない場合、これらのノードの内容、従って元のデータの内容は、ノード＃３とノード＃４から回復（復元）でき、即ちノード＃２の内容の値は（ノード＃４＋ノード＃３）／２であり、ノード＃１の内容の値は（ノード＃３−ノード＃４）／２である。

さらに、個々のノードが、まだ応答するが、実在のデータの代わりに壊れたデータを返す場合には、これを検出して元のデータを回復（復元）することができる。

この冗長性方式は、（２，２）としてモデル化することができ、ここで、ｍ＝２、ｋ＝２、ｎ＝４である。４つの記憶ノードを使用すれば、任意の２つを失うことができ、残りの２つを用いて元のデータを回復（復元）することができる。

例示的な実施形態において、分散形態でユーザ・データを格納（記憶）するためにシステムによって使用されるＩＤＡは、リード−ソロモン・アルゴリズムである。非常に高いレベルおよび単純化の観点から、リード−ソロモン（Reed-Solomon）アルゴリズムは、ガロア体（Galua fields）と多項式代数学（polynomial algebra）を使用するが、前述の説明に従って動作する。即ち、そのアルゴリズムは、元のデータを複数の部分またはチャンク（塊）に分け、データの冗長性を与える。これは、単に元のデータをミラーリングする（即ち、同じチャンクのデータを複数倍または複数回だけ格納する）のと対比をなす。そのアルゴリズムは、上述の（ｍ，ｋ）、ｍ＋ｋ＝ｎの方式に準拠する。即ち、“ｎ”個のノードが存在し、その中の少なくとも任意の“ｍ”個を用いて元の情報を回復（回復）することができる。冗長データ用の追加的な“ｋ”個のノードが存在する。また、ｋ／２個のノードが一見すると機能はするが壊れたデータを実際に供給するときに、エラー（合計ｋ／２個）を検出することもでき、修正することができる。

例示的な実施形態において、ＩＤＡは１２個のノードを有し、（６，６）方式に準拠する。しかし、より大きい（または小さい）冗長性、例えば（６，１２）および（８，１６）の方式を構築することもできる。

ユーザ・データを保護するための別の方法は、対称鍵を用いてそれらを暗号することである。その鍵は、連結されたユーザＩＤおよびサービス・プロバイダＩＤのハッシュとして計算されてもよい。

複数の記憶ノード２１８は、単一のゾーン３３０に属する複数のノード２１８からデータを回復（復元）することが不可能である形態で、予め定められた地理的ゾーン２４０ｉ〜２４０ｎに分散されることが好ましく、ここで、ｎは好ましくは３以上である。一方、記憶ノードのゾーン２４０全体が機能しない場合であっても、データを回復（復元）することができるべきである。（１２，６）ＩＤＡ方式の場合、後者の条件は、各々が４つのノードを有する３つのゾーン２４０によって満たしてもよい。（１６，８）ＩＤＡ方式の場合、６、５および５（個）の記憶ノード２１８が３つの異なるゾーンにおいて必要となる。

図７Ａは、一時的なトランザクション識別子（“チケット”）がユーザＦＥ２０８によって発行される場合の、特定のサービス・プロバイダ・エージェント２２０におけるユーザ認証のためのメッセージ・シーケンス図である。図７Ａのシーケンス図によって例示された認証方法において、ＩＤトークン２２４が、ユーザＦＥ２０８に対して新しいチケットを要求する処理を開始する。ユーザＦＥ２０８は、そのチケットとユーザＩＤを論理的にリンク（結合）させる。ＩＤトークン２２４は、サービス・プロバイダ・エージェント２２０にそのチケットを送信する。次いで、そのチケットがサービス・プロバイダＦＥ２０５に対して生成される。サービス・プロバイダＦＥ２０５は、チケット発行者の（即ち、ユーザ・フロントＦＥ２０８の）ノード・アドレスを取得する。次いで、サービス・プロバイダＦＥ２０５はユーザＩＤを取得する。その時、対応するユーザ・データを取り出すことができるようになる。サービス・プロバイダＦＥ２０８（２０５）はユーザＩＤとサービス・プロバイダ・エージェントＩＤの双方をリンクさせ、分散型データ記憶管理エンジン２１０に対して、このペアに対応するユーザ・データを要求する。最後に、ユーザ・データは、データ・コレクタ２１１によって収集されて、サービス・プロバイダ・エージェント２２０に送信される。

図７Ａを具体的に参照すると、ユーザが自己をサービス・プロバイダに提示したとき、例えば、ユーザがサービス・プロバイダ・エージェント２２０のウェブページにアクセスしたときに、処理が開始する。ユーザは、ユーザのＩＤトークン２２４を用いて自己を認証するよう指示（促）される。例えば、ユーザに指示する１つの方法は、中にＨＴＭＬフォーム有するウェブページをユーザ端末／トークン・インタフェース２２２に送信することである。ユーザは、ＩＤトークン２２４を、ユーザ端末／トークン・インタフェース２２２に接続し（例えば、ＵＳＢポート、非接触型リーダ、またはユーザの携帯電話機で適切なステップ（手順）を踏むことによって）、ソフトまたはハードの“同意”ボタンを押す。次いで、ＩＤトークン２２４は、ユーザＦＥ２０８との間で相互認証の処理を開始する。ＩＤトークン２２４は、ユーザ端末２２２を介してＦＥ２０８との間で（へ／から）メッセージを送受信する。その認証およびデータ取り出しのシーケンスを以下で説明する。

ＩＤトークン２２４とユーザＦＥ２０８の間の通信に、任意の数の標準の相互認証アルゴリズムを用いて、例えば、ＩＳＯ／ＩＥＣ−９７９８規格仕様書に説明されているものを使用してもよく、その全体を参照によりここに組み込む。この相互認証の詳細は、不必要に本発明の詳細を不明瞭にしないようにするために、ここでは説明しない。この認証手順の唯一の非常に高いレベルの例示をメッセージ７０１〜７０９に関して以下で説明し、このシステムに固有の（特有の）或る各特徴を、それ（メッセージ）に関連して説明する。

全てのＩＤトークン２２４は、認証システムに既知の自己の認証鍵を使用する。任意の認証における重要部分は、ＩＤトークン２２４から認証システムへのトークンＩＤの送信である。これが示されているメッセージ７０１において、ＩＤトークン２２４がそのトークンＩＤを（これはユーザＩＤと混同すべきでない）をユーザＦＥ２０８に送信する。

認証および分散型データ記憶管理システム２０４は、それが生成した各トークンに関する或る情報を格納する。この情報は、少なくとも、トークン状態（イネーブルまたはブロックされた状態）、およびトークン認証で使用するためのトークン対称鍵を含んでいる。この情報は、ユーザ・データ（即ち、ユーザ／サービス・プロバイダのペアに関連付けられた各データ・コンテナ）の場合と同じ分散型データ記憶システム２１６におけるデータ・コンテナに格納される。従って、資源識別子を用いて、その記憶システムからこの情報が取り出される。ユーザＦＥ２０８は、（メッセージ７０１からの）トークンＩＤと、仮想ＳＰ ＩＤとして機能する或る予め定められた番号（ＴＳＰＩＤ）とを有する。基本的に、ＴＳＰＩＤは、データ・コンテナ名を導出するために、任意の所与のトークンＩＤと組み合わせて使用されるシステムＩＤである。ユーザＦＥ２０８は、双方の識別子を用いて、提示されたＩＤトークン２２４用の上述のトークン情報を有するデータ・コンテナ用のデータ・コンテナ名（即ち、資源識別子）を計算する。例示的な実施形態において、この資源識別子は、一方向関数Ｏｂｆ（ＴＳＰＩＤ，トークンＩＤ）への入力としてＴＳＰＩＤおよびトークンＩＤを用いることによって、導出される。メッセージ７０３において、ユーザＦＥ２０８は、ＤＤＳシステム２１０に、この資源識別子を読取り要求（これはＲＥＡＤ（ＤＣ名）で示される、即ちＲＥＡＤ（Ｏｂｆ（ＴＳＰＩＤ，トークンＩＤ））と共に（で）送信する。資源識別子を渡すことによって、（ｉ）このトークンＩＤがそのシステムに登録されていて活動状態にあるか（即ち、ブロックされずまたは非活動化されていないか）どうか、および（ii）そのトークンに関連付けられ各暗号鍵、についての情報を求めて、ＤＤＳ管理エンジン２１０に問い合わせが行われる。

そのシステムは、全てのトークンに対して単一の“マスタ・キー（鍵）”を使用することはない。従って、盗まれてそのシステムのセキュリティ侵害を行うのに使用できるマスタ・キーは存在しない。別々の対称鍵が、そのシステムによって発行された各ＩＤトークン２２４に使用される。その時でも、これらの鍵は、単一の場所に保管されることはない。むしろ、それらの鍵は、ユーザ・データ（即ち、ユーザ・データを格納するデータ・コンテナ）がそのシステムに格納されるのと同じ方法で、ＤＤＳシステム上で分散配置される。

ＤＤＳ管理エンジン２１０は、そのデータ・コンテナ名を用いて、ＤＤＳシステム２１６から、そのトークンの秘密鍵および状態を含むデータ・コンテナを取り出す。メッセージ７０５において、データ・コンテナはユーザＦＥ２０８に送信される。“鍵”の使用は、単一の鍵を用いてユーザＦＥ２０８とＩＤトークン２２４の間の双方向の通信を暗号化することができること、または別々の鍵を用いてユーザＦＥ２０８へのおよびユーザＦＥ２０８からの通信を暗号化することができること、を示している。

この時点で、ユーザＦＥ２０８は、認証処理を継続し、通常はその結果として１つまたは複数のセッション鍵が生成され、そのセッション鍵を用いてそのセッション期間中にＩＤトークン２２４とユーザＦＥ２０８の間の全ての後続のメッセージが暗号化される。使用された認証アルゴリズムによって決定されると、ＩＤトークン２２４とユーザＦＥ２０８は、相互認証を完了するよう交信する。相互認証を完了するためのこの交信は、図７Ａにメッセージ７０７として示されている。セッション鍵は、対称な認証鍵と、認証期間中に交換されたランダムなチャレンジ（文字列、ビット列、乱数）から導出される。任意のセッション鍵が、ＤＤＳシステム２１０から取り出された鍵を用いて暗号化されて、ＩＤトークン２２４に送信されてもよい。

メッセージ７０９において、ＩＤトークン２２４はセッション鍵を使用して、それが安全な記憶装置に格納したユーザＩＤと、（任意選択的に）ユーザ・データ暗号鍵とを暗号化して、それらをユーザＦＥ２０８に送信する。ＦＥ２０８は、このメッセージを復号し、この認証処理を記述するデータ構造（体）２４５を生成してランダムアクセス・メモリに格納する。このデータ構造は、ユーザＩＤおよび任意のユーザ・データ暗号鍵を一時的トランザクション識別子（“チケット”）と共に保持する。実施形態において、チケットは、トランザクションの時間および空間に一意的な固有の識別子である。例えば、チケットは、一時的にこのユーザＦＥ用の一意的な固有の（unique-for-this-user FE）乱数、ユーザＦＥネットワーク・アドレス（可能性としてローカルＶＰＮアドレス）および任意に或るその他のヘルパー（支援）情報を含むＡＳＣＩＩまたはＵＴＦ符号化シンボルのストリング（文字列）とすることができる。

メッセージ・シーケンス７０１〜７０９は、ＩＤトークン２２４と認証および分散型データ記憶管理システム２０４の間の相互認証のための１つの可能なメッセージ・シーケンスを例示しているに過ぎないと理解されるべきである。例えば市場で利用可能な種々のスマートカードによって使用される手順のような、その他の手順を用いることができる。

メッセージ７１１において、ユーザＦＥ２０８は、暗号化されたチャネル（Ｅ（チケット）、Ｅ（ｔｉｃｋｅｔ））を介してＩＤトークン２２４にそのチケットを送信する。

メッセージ７１３において、ＩＤトークンはチケットを復号して、それをユーザ端末２２２に渡し、ユーザ端末２２２は、単なる一例としてサービス・プロバイダ・エージェントのＨＴＭＬフォームを完成させることによって、それをサービス・プロバイダ・エージェント２２０に送信する。

メッセージ７１５において、サービス・プロバイダ・エージェント２２０は、サービス・プロバイダＦＥ２０５に接続し、サービス・プロバイダＦＥ２０５にチケットを送信する。サービス・プロバイダは、認証および分散型データ記憶管理システム２０４に対して多かれ少なかれ永続的な接続を有すると考えることができる。その結果、サービス・プロバイダＦＥ２０５は、既にサービス・プロバイダＩＤを有する。そのような永続的接続が存在しない場合、サービス・プロバイダ・エージェント２２０およびサービス・プロバイダＦＥ２０５は、ＩＤトークン２２４およびユーザＦＥ２０８の認証に関連して前述したように相互認証およびセッション鍵生成を行う。このようにして、サービス・プロバイダＩＤは、サービス・プロバイダＦＥ２０５に知られる。

メッセージ７１７において、サービス・プロバイダＦＥ２０５は、チケットを受信し、そのチケットから、発行者のユーザＦＥ２０８のネットワーク・アドレスを取得する。次いで、サービス・プロバイダＦＥ２０５は、いわゆる識別されたユーザＦＥ２０８にそのチケットを送信して、ユーザＩＤおよび任意にユーザ・データ暗号鍵を要求する。

メッセージ７１９において、ユーザＦＥ２０８は、ユーザ・プロバイダＦＥ２０５から受信したチケットに関連付けられたデータ構造（体）２４５を見つけ出し、ユーザＩＤおよびユーザ・データ暗号鍵でユーザ・プロバイダＦＥ２０５に応答する。このデータがサービス・プロバイダ・フロントエンド２０５に送信された後、データ構造（体）２４５は、ユーザＦＥ２０８のランダムアクセス・メモリから削除することができる。

メッセージ７２１において、サービス・プロバイダＦＥ２０５は、ユーザＩＤ（メッセージ７１９からのもの）とサービス・プロバイダＩＤの双方を有し、双方の識別子を用いて、資源識別子（即ち、サービス・プロバイダ／ユーザＩＤのペアに関連付けられたデータ・コンテナのファイル名）を導出する。例示的な実施形態において、この資源識別子は、上述したような一方向関数（Ｏｂｆ（ユーザＩＤ，ＳＰ ＩＤ））への入力としてのユーザＩＤおよびサービス・プロバイダＩＤを使用することによって、導出される。この資源識別子は、メッセージ読取り（ＤＣ名）（READ(DC Name)）としてＤＤＳ管理エンジン２１０に送信される。

メッセージ７２３において、ＤＤＳ管理エンジン２１０のデータ・コレクタ２２１は、情報分散アルゴリズムおよび資源識別子を用いて、分散型データ記憶システム２１６からその格納された資源の充分なセグメント（即ち、データ・コンテナ）を収集し、そのデータを組み立て、そのユーザ・データをサービス・プロバイダＦＥ２０５に送信する。サービス・プロバイダＦＥ２０５は、データ・コンテナ（ＤＣ）を受信し、それが暗号化されている場合には、メッセージ７１９においてそれがユーザＦＥ２０５から受信したユーザ・データ暗号鍵を使用してそのデータを復号する。

メッセージ７２５において、サービス・プロバイダＦＥ２０５は、データ・コンテナをサービス・プロバイダ・エージェント２２０に、それがサービス・プロバイダ・エージェント２２０から受信したのと同じ形態（フォーム）で送信する。そのデータは、サービス・プロバイダ・エージェント２２０とサービス・プロバイダＦＥ２０５によってそれらの相互認証セッション期間中に確立されたセッション鍵を使用して暗号化されることが好ましい。

図７Ｂは、一時的なトランザクション識別子が（“チケット”）がサービス・プロバイダＦＥ２０５によって発行される場合の（これに対して、図７Ａのシーケンス図ではユーザＦＥ２０８によって発行される）、特定のサービス・プロバイダ・エージェント２２０におけるユーザ認証のためのメッセージ・シーケンス図である。このアプローチ（方法）では、サービス・プロバイダ・エージェント２２０は、サービス・プロバイダＦＥ２０５に対して新しいチケットを要求する。サービス・プロバイダＦＥ２０５は、新しいチケットを生成し、それをこの特定のサービス・プロバイダ・エージェント２２０に割り当てる。サービス・プロバイダ・エージェント２２０は、このチケットをＩＤトークン２２４に供給する。次に、ＩＤトークン２２４は、認証手順に従って自己を認証し、ユーザＦＥ２０８に対してチケットを生成する。ユーザＦＥ２０８は、このチケットをユーザＩＤとリンク（結合）させて、このリンクされたチケットを、チケットを発行したサービス・プロバイダＦＥ２０５に送信する。次いで、サービス・プロバイダＦＥ２０５は、ユーザＩＤとサービス・プロバイダ・エージェントＩＤの双方をリンクさせて、ＤＤＳ管理エンジン２１０に、このＩＤのペアに対応するユーザ・データを要求する。最後に、データが取り出されて、サービス・プロバイダ・エージェント２２０に送信される。

図７Ｂの情報シーケンス図を具体的に参照すると、メッセージ７３０において、ユーザは、ＨＴＴＰ要求を送信することによって（例えば、サービス・プロバイダ・エージェントのウェブページのウェブページ上のＨＴＭＬ認証ボタンの画像を押すことによって）、サービス・プロバイダ・エージェントとの対話を開始する。

メッセージ７３２において、サービス・プロバイダ・エージェント２２０は、そのサービス・プロバイダＦＥ２０５に対してチケットを要求する。サービス・プロバイダ・エージェント２２０は既にサービス・プロバイダＦＥ２０５において認証されていると仮定する。サービス・プロバイダＦＥ２０５は、サービス・プロバイダＩＤを知っており、従って（任意に）サービス・プロバイダ名の人間に読み取り可能な表現、例えば“ｂｏｏｋｓｔｏｒｅ”（書店）を知っている。この人間読み取り可能な表現は、サービス・プロバイダＦＥ２０５によって発行されるチケットに含まれてもよい。サービス・プロバイダＦＥ２０５によって発行されたチケットは、例えば、次のＵＲＩ（Universal Resource Identifier、ユニバーサル資源識別子）の形態：ｓｐｎａｍｅ：ｎｏｎｃｅ＠ｈｏｓｔ：ｐｏｒｔを有する。ここで、“ｓｐｎａｍｅ”はサービス・プロバイダの人間読み取り可能な表現であり（例えば、銀行名、航空会社名、等）、“ｎｏｎｃｅ”は一度だけ使用される番号であり（例えば、チケットを一意的なものにする任意のシーケンス番号）、“ｈｏｓｔ：ｐｏｒｔ”はサービス・プロバイダＦＥ２０５のインターネット・アドレスを示す。従って、この例では、チケットは、ｂｏｏｋｓｔｏｒｅ：６８７＠ｓｐｆｅ．ｎｅｔ：４５６７である。

メッセージ７３４において、サービス・プロバイダＦＥ２０５は、チケットをサービス・プロバイダ・エージェント２２０に送信する。

メッセージ７３６において、サービス・プロバイダ・エージェント２２０は、チケットをユーザ端末２２２へと中継し、ユーザ端末２２２はそのチケットをＩＤトークン２２４に提示する。ＩＤトークン２２４がディスプレイを備えている場合（図３Ｂ、３Ｃ、３Ｄを参照）、そのＩＤトークンはそのチケット中からサービス・プロバイダの名称を抽出して、この名称（例えば、“ｂｏｏｋｓｔｏｒｅ”）をユーザに示すことができる。このステップは、サービス・プロバイダがチェックされ、認証システムによって検証されたことをユーザに確信させる（保証する）のを支援し、いわゆる“フィッシング”（phishing）の可能性を減少させる。

次いで、ユーザは、ＩＤトークン２２４上の“同意”ボタンを押して、ＩＤトークン認証手順を開始する。ＩＤトークン２２４の認証は、図７Ａのメッセージ７０１〜７０９に関連して説明したのと同じ手順（単純に認証メッセージ７３８として図７Ｂにおいて例示したもの）であってもよい。１つの相違点は、いったん認証が完了すると、そのチケットがＩＤトークン２２４からユーザＦＥ２０８へ転送されることであり（メッセージ７４０）、それに対して（図７Ａでは）その逆である。

メッセージ７４２において、ユーザＦＥ２０８は、チケットの“ｈｏｓｔ：ｐｏｒｔ”部分を用いて、対応するサービス・プロバイダＦＥ２０５をアドレスして（に宛てて）、次に、チケットを発行したサービス・プロバイダＦＥ２０５に、チケットおよびユーザＩＤ（認証ステップ７３８の期間中にＩＤトークン２２４から受信されたもの）を送信する。

メッセージ７４４において、ユーザＦＥ２０８は、ＳＰ ＦＥ２０５からの成功したチケット受信の確認を受信する。メッセージ７４６において、ユーザＦＥ２０８は、この確認をユーザ端末２２２を介してＩＤトークン２２４へと中継する。ＩＤトークン２２４は、ユーザ端末２２２を介してその確認をサービス・プロバイダ・エージェント２２０に送信する。

メッセージ７５０において、サービス・プロバイダ・エージェント２２０は、要求（ＧｅｔＤａｔａ（ｔｉｃｋｅｔ））をユーザ・データ用のサービス・プロバイダＦＥ２０５に送信する。その要求は、メッセージ７３４で受信したチケットを含んでいる。

サービス・プロバイダＦＥ２０５はそのデータ要求を受信する。サービス・プロバイダＦＥ２０５は、ユーザＩＤ（メッセージ７４２からのもの）およびサービス・プロバイダＩＤ（サービス・プロバイダ・エージェント２２０との間のその認証手順の期間中に受信されたもの）を有する。サービス・プロバイダＦＥ２０５は、双方のＩＤを組み合わせて、データ・コンテナ・ファイル名を取得することができる。上述したように、データ・コンテナ名は、ユーザＩＤおよびサービス・プロバイダＩＤ（またはその連結または派生物）を一方向関数（即ち、Ｏｂｆ（ＵｓｅｒＩｄ，ＳＰＩＤ））に入力することによって得られる。メッセージ７５２において、サービス・プロバイダＦＥは、読取り要求の一部としてデータ・コンテナ名をＤＤＳ２１０（即ち、ＲＥＡＤ（ＤＣ Ｎａｍｅ））に送信する。

メッセージ７５４において、ＤＤＳ２１０は、データ・コレクタ２１１を使用して、データ・コンテナの複数のセグメントを収集して組み立て、その組み立てられたユーザ・データをサービス・プロバイダＦＥ２０５に送信し返す。

メッセージ７５６において、サービス・プロバイダＦＥ２０５は、サービス・プロバイダ・エージェント２２０にデータ・コンテナを、サービス・プロバイダ・エージェント２２０から受信したのと同じ形態（フォームで）（例えば、暗号化形態または暗号解読（復号）形態で）送信する。

前述の説明から分かるように、ＩＤトークンのメモリに格納されたユーザＩＤパラメータは、分散型データ記憶システム２１６からデータを取り出すのに使用されるというセキュリティの観点から、非常に機密性があるもの（センシティブな、敏感な、慎重に扱うべきもの）である。図７Ｃおよび７Ｄに関連して以下で説明する代替実施形態では、ユーザＩＤがＩＤトークンから決して離れないようにすることができる。一般的には、サービス・プロバイダＩＤは、セキュリティの観点では、機密性がない。

図７Ｃは、図７Ｂのメッセージ・シーケンス図の代替的な実施形態を例示している。この実施形態は、分散型データ記憶管理システム２１０によってユーザ・データの取り出しに使用される資源識別子を導出する際に使用されるユーザＩＤとサービス・プロバイダＩＤの双方の増強された保護を与える。この実施形態は、以下で説明するように、特殊な方法でチケットの“ノンス”（nonce）部分（図７Ｂで数値“６７８”として、図７Ｃで上位概念的に“Ｋ”として示されている）を使用する。図７Ｂにおけるメッセージと同じ図７Ｃにおけるメッセージが同じ参照番号で識別され、修正されたメッセージが、図７Ｂの対応する参照番号に末尾に“ａ”を付して識別される。

図７Ｃの情報シーケンス図を具体的に参照すると、メッセージ７３０、７３２および７３４には変更がない。しかし、サービス・プロバイダＦＥ２０５は、チケット・メッセージ７３４を送信する前に、１つの数だけでなく、１対（ペア）のノンス数ＫおよびＭを生成する。数Ｍの値は、数Ｋの値に依存する。Ｋの値は乱数である。Ｋは、チケット・メッセージ７３４（ｂｏｏｋｓｔｏｒｅ：ｎｏｎｃｅ．ｋ＠ｓｐｆｅ．ｎｅｔ：４５６７）においてサービス・プロバイダ・エージェント２２０に送信されるが、Ｍは、サービス・プロバイダＦＥメモリにおける秘密情報として保持される。

チケット・メッセージ７３４を受信した後、サービス・プロバイダ・エージェント２２０は、（図７Ｂのように）ユーザ端末にチケットを単純に転送することはない。むしろ、サービス・プロバイダ・エージェント２２０は、式：ＳｐＫ＝Ｆｌ（ＳｐＩＤ，Ｋ）に従って、ノンス（即ち、Ｋ）を修正または変更する。次いで、サービス・プロバイダ・エージェント２２０は、その修正されたチケット“ｔｉｃｋｅｔ．ＳＰ”をメッセージ７３６ａで送信する（即ち、ｂｏｏｋｓｔｏｒｅ：ｎｏｎｃｅ．ＳｐＫ＠ｓｐｆｅ．ｎｅｔ：４５６７、またはｂｏｏｋｓｔｏｒｅ：ｎｏｎｃｅ．Ｆｌ（ＳｐＩＤ，Ｋ）＠ｓｐｆｅ．ｎｅｔ：４５６７）。

ユーザ端末２２２は、ｔｉｃｋｅｔ．ＳＰを受信し、それをＩＤトークン２２４に提示する。ＩＤトークン２２４は、ＳｐＫ値を修正して、ＴｏｋｅｎＫ値を導出する。ここで、ＴｏｋｅｎＫ値は、Ｆ２（ＵｓｅｒＩＤ，ＳｐＫ）と等しい。ＩＤトークン２２４は、新しいチケット“ｔｉｃｋｅｔ．Ｔ”（即ち、ｂｏｏｋｓｔｏｒｅ：ｎｏｎｃｅ．ＴｏｋｅｎＫ＠ｓｐｆｅ．ｎｅｔ：４５６７またはｂｏｏｋｓｔｏｒｅ：ｎｏｎｃｅ．Ｆ２（ＵｓｅｒＩＤ，Ｆｌ（ＳｐＩＤ，Ｋ））＠ｓｐｆｅ．ｎｅｔ：４５６７）をユーザ端末２２２に転送し、ユーザ端末２２２は、チケット・メッセージ７４０ａでこのチケットをユーザＦＥ２０８に転送する。

ユーザＦＥ２０８は、メッセージ７４２ａでこのｔｉｃｋｅｔ．Ｔをサービス・プロバイダＦＥ２０５に転送する。サービス・プロバイダＦＥ２０５が ｔｉｃｋｅｔ．Ｔを受信したとき、最後の計算：Ｄａｔａ Ｃｏｎｔａｉｎｅｒ Ｎａｍｅ＝Ｆ３（Ｍ，ＴｏｋｅｎＫ，）が実行される。関数Ｆ１、Ｆ２およびＦ３は、Ｋ、Ｍのペアの値と共に、次のこと、即ち、データ・コンテナ名（即ち、資源識別子）がユーザＩＤ／サービス・プロバイダＩＤのペアにだけ依存し、ＫまたはＭに依存しないこと、また、データ・コンテナ名が全てのサービス・プロバイダＩＤ／ユーザＩＤのペアに対して一意的であること、を確実にする（保証する）。Ｍの値は、Ｆ３の出力においてＫの影響をなくすのに役立つ。

上述のプロトコルの可能性ある１つの実装形態は、パイエ暗号法（Paillier Cryptosystem）に基づく。このアルゴリズムを使用するには、２つの定数パラメータが必要である。その第１の定数パラメータは、パイエ暗号法の公開鍵（全ての参加者に知られる鍵）および或る定数Ｃである。定数Ｃが使用されるのは、パイエ暗号法では負数を符号化できないからである。定数Ｃは、データ・コンテナの名称（即ち、ＳｐＩＤ｜ＵｓｅｒＩＤ＋Ｃ）にオフセットを導入し、従って、一意的な固有のデータ・コンテナ名をそのまま残しつつパイエの特徴を表す（説明する）。この場合、サービス・プロバイダＦＥ２０５は、乱数Ｍを取得しまたは生成し、それをパイエ暗号法の公開鍵（乱数Ｋを形成するためのもの）で暗号化し、メッセージ７３４においてサービス・プロバイダ・エージェント２２０にその数値を送信する。サービス・プロバイダＦＥ２０５は、後で使用するために乱数Ｍを記録する。乱数Ｋは、Ｍの暗号化バージョン（Ｍを暗号化したもの）、即ちＥ（Ｍ）に対応する。復号用の公開鍵は、手順に参加する各ノードに知られている。サービス・プロバイダ・エージェント２２０は、ＳｐＩＤのビットシフトしたバージョン（もの）を使用する。具体的には、サービス・プロバイダ・エージェント２２０は、ＳｐＩＤ’＋ＵｓｅｒＩＤ ＝ＳｐＩＤとＵｓｅｒＩＤの連結（即ち ＳｐＩＤ｜ＵｓｅｒＩＤ）となる形態で、ＳｐＩＤをシフトする（即ち、ＳｐＩＤ’）。サービス・プロバイダ・エージェントは、ユーザＩＤを知らないが、ユーザＩＤにおけるビット数を知っている。即ち、ＳＰＩＤが１１００１１であり、ユーザＩＤが０１０１０１であると仮定する。これらのＩＤを連結するために、ＳｐＩＤを６ビット桁だけ（即ち、ユーザＩＤのビット数）左シフトして、ＳｐＩＤ’：１１００１１００００００を与える。次いで、ＳｐＩＤ’にユーザＩＤを加えて、ＳｐＩＤ’とユーザＩＤの連結：１１００１１０１０１０１を与える。次に、サービス・プロバイダ・エージェント２２０は、そのビットシフトの結果にＫを乗算して、Ｆｌ（ＳｐＩＤ，Ｋ）＝Ｅ（ＳｐＩＤ’）＊Ｋ＝Ｅ（ＳｐＩＤ’）＊Ｅ（Ｍ）＝ＳＰ＿ｔｒａｎｓｆｏｒｍ＝ＳｐＫ＝Ｅ（Ｍ＋ＳｐＩＤ’）を得る（ｔｒａｎｓｆｏｒｍは変換）。全ての乗算は、モジュロ（法）演算である。次いで、ＩＤトークン２２４は、ＵｓｅｒＩＤ（ユーザＩＤ）を公開鍵で暗号化し、その結果にＳｐＫを乗算し、Ｆ２（ＵｓｅｒＩＤ，ＳｐＫ）＝Ｅ（ＵｓｅｒＩＤ）＊ＳＰ＿ｔｒａｎｓｆｏｒｍ＝ｔｏｋｅｎ＿ｔｒａｎｓｆｏｒｍ＝ＴｏｋｅｎＫ＝Ｅ（Ｍ＋ＳｐＩＤ’＋ＵｓｅｒＩＤ）＝Ｅ（Ｍ＋ＳｐＩＤ ｜ＵｓｅｒＩＤ）を得る。次いで、サービス・プロバイダＦＥ２０５は、最終的な変換を実行することができる。ＳｐＦＥは、差（Ｃ−Ｍ）を暗号化し、その結果にＩＤトークン２２４から受信した値を乗算し、従って、データ・コンテナ名（即ち、Ｏｂｆ（Ｃ＋ＳｐＩＤ｜ＵｓｅｒＩＤ）：Ｆ３（Ｃ−Ｍ，ＴｏｋｅｎＫ）＝Ｅ（Ｃ−Ｍ）＊ＴｏｋｅｎＫ＝Ｅ（Ｃ−Ｍ＋Ｍ＋ＳｐＩＤ｜ＵｓｅｒＩＤ）＝Ｅ（Ｃ＋ＳｐＩＤ｜ＵｓｅｒＩＤ）)を得る。

上述の説明について、サービス・プロバイダＦＥ２０５は、システムを介して送信されるユーザＩＤを用いずに、データ・コンテナ名を導出することができる。データ・コンテナ名（即ち、資源識別子）は、メッセージ７４２ａの受信後、サービス・プロバイダＦＥ２０５によって導出することができる。

メッセージ７４４〜７５０は、ユーザ端末２２２（即ち、ブラウザ）およびサービス・プロバイダ・エージェント２２０（即ち、ＨＴＴＰサーバ）を同期させるためにだけ使用される。メッセージ７４４〜７４８および７４６〜７５６は、図７Ｂに関連して上述したのと同じである。メッセージ７５０ａは、チケットを必要としないので、単なるＧｅｔＤａｔａ（データ取得）要求である。

図７Ｄは、図７Ｂのメッセージ・シーケンス図の第２の代替的な実施形態を例示している。この実施形態において、ＩＤトークン２２４は、サービス・プロバイダＩＤおよびユーザＩＤを用いて資源識別子を計算する。このように、ユーザＩＤは、ＩＤトークン２２４の外部に送信される必要がない。図７Ｂにおけるメッセージと同じ図７Ｄにおけるメッセージは、同じ参照番号で識別され、修正されたメッセージは、図７Ｂにおける対応の参照番号の末尾に“ｂ”を付して識別される。また、追加的なメッセージ７４７および７４９も示されている。

図７Ｄの情報シーケンス図を具体的に参照すると、メッセージ７３０、７３２、７３４および７３６には変更がない。ユーザＩＤがＩＤトークン２２４からユーザＦＥ２０８に送信されないことを除いて、メッセージ７３８ｂで示されたトークン認証処理は、図７Ｂのメッセージ７３８について上述したのもと同じである。メッセージ７４０には変更がない。但し、チケット（ユーザＩＤでなく）がメッセージ７４２ｂにおいてユーザＦＥ２０８からサービス・プロバイダＦＥ２０５に送信される。

メッセージ７４４ｂにおいて、サービス・プロバイダＦＥ２０５は、サービス・プロバイダＩＤをユーザＦＥ２０８に送信する。

メッセージ７４６ｂにおいて、ユーザＦＥ２０８は、このサービス・プロバイダＩＤをユーザ端末２２２を介してＩＤトークン２２４に送信する。

その方法は、図７Ｂの方法と同様に、メッセージ７４８および７５０を送信する。しかし、それと並行して、ＩＤトークン２２４は、受信したサービス・プロバイダＩＤおよびその内部に格納されたユーザＩＤを使用して資源識別子、即ちＯｂｆ（ＵｓｅｒＩＤ，ＳｐＩＤ）、を計算する。ＩＤトークン２２４は、そのように計算された資源の識別子を、メッセージ７４７においてサービス・プロバイダＦＥ２０８に送信し、次いでユーザＦＥ２０８はメッセージ７４９においてその資源識別子をチケットと共にサービス・プロバイダＦＥ２０５に送信する。

メッセージ７５２、７５４および７５６は、図７Ｂの説明と変わらない。

鍵管理：
鍵管理エンジン２１２は、新しいＩＤトークン２２４の生成と、システムにおけるこれらのトークンの初期登録とを担当する。また、鍵管理エンジン２１２は、ＩＤトークンの非活動化（解除）と、ＩＤトークン置換とを担当する。

複数の実施形態において、鍵管理エンジン２１２は、図８のブロック図に例示されているように、マルチパート（複数部分）システムである。鍵管理エンジン２１２は、スマートカード・パーソナライゼーション（個人化）装置２１２ａを含んでいる。複数の実施形態において、スマートカード・パーソナライゼーション装置は、スマートカードを生成しスマートカード・メモリにデータを書き込む特別に設計されたコンピュータ化された装置（マシン）である。この装置２１２ａは、操作者（オペレータ）のコンソール２１２ｄからのコマンド（例えば、新しいバッチのトークンを生成するための要求）を扱いまたは供給する鍵管理コア・プログラム２１２ｃによって制御される。新しいトークンを生成するための要求の別の供給源は、鍵管理ウェブ・サービス・サイト２１２ｂ（例えば、トークン置換要求）から来る（由来の）ものである。

セキュリティ（安全性）上の理由から、ユーザＩＤはシステムに格納されてないことが好ましい。従って、マスタ・トークンを用いて、失われたまたはセキュリティ侵害（危険に晒）されたＩＤトークン２２４が置換される。マスタ・トークンは、置換するのに必要な情報および古いＩＤトークン２２４（例えば、トークンＩＤ、ユーザＩＤ、および最適の各ユーザ・データ暗号鍵）を保持する。ユーザがシステムにおいてユーザのマスタ・トークンで認証されたとき、新しいＩＤトークン／マスタ・トークンのペアが生成されてユーザに送信されてもよい。同時に、以前使用された各作業トークンは、非活動化（deactivated、無効化、解除）される（例えば、そのトークンに関連付けられたデータ・コンテナにおけるトークンＩＤ用の“非活動化”（無効化）フラグをトリガすることによる）。

図９は、ＩＤトークン２２４を置換するためのメッセージ・シーケンスである。手順は、図７Ａに示されたものに非常に近い。失われたまたは盗まれたＩＤトークン２２４を非活動化（無効化）するために、ユーザは、ユーザ端末２２２のブラウザを、鍵管理エンジン２１２の鍵管理ウェブ・サービス・コンポーネント２１２ｂによって供給される鍵管理ウェブ・サービス・ページに向かわせ（direct、移動させ）て、ユーザのマスタ・トークン２４３を用いて自己を認証する。図７Ａのメッセージ７０１と同様に、メッセージ９０５において、マスタ・トークン２４３は、端末２２２を介してユーザ・フロントエンド２０８にマスタ・トークンＩＤを供給する。

図７Ａのメッセージ７０３のように、メッセージ９１０において、ユーザＦＥ２０８は、資源識別子（即ち、Ｏｂｆ（ＴＳＰＩＤ，Ｍａｓｔｅｒ Ｔｏｋｅｎ ＩＤ））を計算し、この資源識別子を、読取り要求（即ち、ＲＥＡＤ（ＤＣ Ｎａｍｅ））と共に（読取り要求で）ＤＤＳシステム２１０に送信する。

ＤＤＳ管理エンジン２１０は、データ・コンテナ名を使用して、ＤＤＳシステム２１６からのマスタ・トークンの秘密鍵および状態（ステータス）を含むデータ・コンテナを取り出す。メッセージ９１５において（図７Ａのメッセージ７０５のように）、この情報は、データ・コンテナの一部としてユーザＦＥ２０８に送信される。

次いで、認証のメッセージ９２０（図７Ａのメッセージ７０７のようなもの）は、ユーザＦＥ２０８からＩＤトークン２２４に送信される。

メッセージ７０９（図７Ａ）と比較すると、メッセージ９２５は、追加的な情報を、即ち置換されるＩＤトークン２２４のトークンＩＤを、担持または搬送する。この追加情報は、ユーザＦＥトランザクション記述９２７に格納されており、そのユーザＦＥトランザクション記述９２７は、（ｉ）一時的なトランザクション識別子（“チケット”）、（ii）ユーザＩＤ、（iii）ユーザ・データ暗号鍵（任意）、（iv）古いトークンＩＤ、および（ｖ）マスタ・トークンＩＤを含んでいる。

メッセージ９３０〜９４５は、システムを介した“チケット”のパス（経路）を示すものであり、鍵管理コア２１２ｃがサービス・プロバイダＦＥ２０５に置き換わることを除いて、図７Ａのメッセージ７１１〜７１７と完全に同等（均等、等価）である。実際に、鍵管理コア２１２ｃは、鍵管理ウェブ・サービス２１２ｂ用の“特別な”サービス・プロバイダＦＥの役割を果たすことができ、そのサービス・プロバイダＦＥは一種のサービス・プロバイダと見なことができる。しかし、その差異は、チケットの生成後に、鍵管理コア２１２ｃが、ユーザＦＥ２０８から、ユーザＩＤおよび任意選択的にユーザ・データ暗号鍵だけでなく、置換されるＩＤトークン２２４のＩＤをも受信することである（メッセージ９５０ ）。

そのシーケンス中のこの点（時点、段階）において、鍵管理エンジン２１２は、同じユーザＩＤを指す新しいペア（１対）のトークン（通常の日常（毎日）のトークンおよびマスタ・トークン）を生成するのに必要な全ての情報を有する。新しいトークンＩＤおよび各秘密鍵が生成され、この情報は、スマートカード・パーソナライゼーション装置２１２ａによって新しいトークンに書き込まれる。メッセージ９５５で示されているように、新しいトークン・レコード（記録）がＤＤＳ管理エンジン２１０に供給されて、任意の古いトークンが“非活動化”（無効化）されたものとしてマークされる（マークまたは標識が付けられる）。メッセージ９６０は、鍵管理ウェブ・サービス２１２ｂに、動作の成功／失敗状態を報告して、メッセージ９６５においてそれをユーザ端末２２２に通信し返すようにする。

セキュリティ対策：
認証の秘密情報およびユーザ・データ・プライベート（私的、非公開、秘密）情報をできるだけ安全に保持するために、システムにおいて複数の対策が取られる。第１に、システムで使用されている識別子（即ち、トークンＩＤ、サービス・プロバイダＩＤ、ユーザＩＤ）は、例えば長さが少なくとも６４ビットのような、長い整数であるべきである。これらの数は、乱数発生器によって生成される。これによって、徹底的な検索方法によって既存の（現在の）識別子を見つけることが困難になる。第２に、全てのデータ交換は、少なくとも１２８ビット長の秘密鍵で安全に保護されていることが好ましい。さらに、データ・コンテナ識別子は、一方向に暗号化され、その結果得られる名称の長さは５１２ビットより長い。データ・コンテナ名からユーザＩＤおよび／またはサービス・プロバイダＩＤを回復（復元）することは（いかなる実際的な方法でも）不可能である。ユーザ・データ自体は、ユーザがシステムと通信する活動（有効）期間においてだけシステムに知られるＳｐＩＤおよびユーザＩＤの各ハッシュである各秘密鍵で暗号化された形態で、格納されてもよい。さらに、サービス・プロバイダのオプション（任意選択）として、各データ・コンテナは、それらが記憶システムに送信される前に、サービス・プロバイダによって暗号化されてもよい。最後に、複数の実施形態において、認証システムは、所与のサービス・プロバイダに割り当てるサービス・プロバイダＩＤ、またはＩＤトークンに割り当てるユーザＩＤを（いかなる永続性でも）格納することはない。このように、認証システムは、それ自体が、サービス・プロバイダおよびＩＤトークンが必要な認証手順を経ずに、サービス・プロバイダＩＤ／ユーザＩＤのペアに関連付けられたデータ・コンテナにアクセスすることができない。即ち、認証システムは、ユーザＩＤおよびサービス・プロバイダＩＤの各リストを別々に維持（保持）することはないので、認証システムも悪意あるその他の者も、データ・コンテナを回復（復元）または取り出すのに必要な資源識別子を導出することができない。

ここで説明する認証およびデータ記憶システムの例示的な使用は、サービス・プロバイダ／ユーザ・トランザクション（取引）において第三者認証サービスを提供するため、およびサービス・プロバイダに代わってユーザのプロファイル・データを安全に格納するためのものでる。典型的なサービス・プロバイダ／ユーザ・インタラクション（対話）は、ベンダー（例えば、オンライン書店）と、そのベンダーにアカウントを有するユーザとの間で行われる。ユーザはベンダーのウェブ・サイトにアクセスし、ユーザのＩＤトークンを提示し、認証手順が実行され、ユーザが認証された場合に、ユーザのプロファイル・データ（例えば、氏名、アカウント情報、顧客ロイヤルティ情報、課金情報、等）を含むデータ・コンテナは、ベンダーによって使用されるために取り出される。そのトランザクションが完了したとき、ユーザ・データは更新することができ、ベンダーは、安全記憶用の記憶システムにデータ・コンテナを送信し返す。そのシステムの別の典型的な使用では、ユーザは、ベンダーの物理的なストア（店）において適切な端末にＩＤトークンを提示することができる。認証手順が再び実行されて、認証が成功した場合、ユーザのプロファイル情報を含むデータ・コンテナが取り出される。トランザクションが完了したとき、ユーザ・データは更新でき、ベンダーは、安全記憶用の記憶システムにデータ・コンテナを送信し返す。このアプリケーションは、複数のベンダー用の複数のロイヤルティカードを携帯する必要性からユーザを解放する。

オンライン小売業者の例：
次に、オンライン小売環境におけるシステムの適用について説明する。この例では、システムにおいて次の３種の参加者が存在する。それは、（１）オンライン小売業者（以下、オンライン書店と称する）、（２）顧客（例えば、オンライン書店で買い物する個人）、および（３）第三者の認証システム／データ記憶事業体（即ち、認証および分散データ記憶管理システム２０４を運営または稼働する事業者）（以下、“第三者認証機関”（第三者認証者）と称する）。

顧客は、第三者認証機関にアカウントを設定し、第三者認証機関は、顧客に対する１つ以上のＩＤトークン２２４と、１つのマスタ・トークン２４３とを発行する。例えば、ハードウェア・トークンの場合、これらのトークンは顧客に郵送される。そのトークンが顧客のスマートフォンまたはＰＤＡ上で実行されるアプリケーションである場合、トークン・アプリケーションが顧客によってその機器にダウンロードされる。トークンＩＤ２２４は上述のユーザＩＤおよび暗号鍵（複数可）を含み、マスタ・トークン２４３は、上述のユーザＩＤ、マスタ・トークンＩＤおよび暗号鍵（複数可）を含んでいる。データ・コンテナは、トークン認証用の鍵（複数可）およびトークン状態を含めて、各トークンに対応するシステムに格納される。このデータ・コンテナは、トークンＩＤおよび別のデータ要素（例えば、第三者認証機関のＩＤ）を使用してアクセスされる。

また、オンライン書店は、オンライン書店用の、第三者認証サービスおよび第三者データ記憶装置を提供する第三者認証機関との関係を確立する。第三者認証機関は、認証システムとの通信に必要な任意のソフトウェアおよびトークンと、サービス・プロバイダＩＤとを、オンライン書店に提供する。次いで、オンライン書店は、そのウェブ・サイト上にアイコンまたはその他の選択可能なリンクを追加する。

この例では、顧客がオンライン書店との関係を確立している（即ち、オンライン書店に登録されている）と仮定する。即ち、顧客は、或る時点で、オンライン書店にユーザ情報を提供していて、オンライン書店はそのユーザ情報を用いて顧客に関連（対応）付けらた顧客プロファイルを生成（作成）する。この顧客プロファイルには、例えば、顧客名、住所、顧客アカウント番号、金融契約（instrument）情報（例えば、クレジットカード番号および請求先住所）、アカウント・ユーザ名、顧客の嗜好、等の情報を含ませることができる。ユーザが既に認証されたときは、ユーザ・パスワードを必要としないことに留意されたい。時間の経過とともに、オンライン書店は、この情報を（に）、例えば、顧客の購入履歴、傾向、嗜好、ロイヤルティ（利用度）状態、等の履歴情報で補完（を追加）することができる。オンライン書店は、この情報を、分散型データ記憶システム２１６における記憶用のデータ・コンテナとしての第三者認証機関に提供する。このデータ・コンテナは、オンライン書店（サービス・プロバイダ１０）に割り当てられた固有のＩＤと、顧客に対して発行されＩＤトークン２２４に格納された固有のユーザＩＤとから導出された資源識別子を用いて、識別され取り出される。データ・コンテナの初期生成（作成）のための処理は、メッセージ７２１（図７Ａ）およびメッセージ７５２（図７Ｂ、７Ｃおよび７Ｄ）が、読取り（READ）要求でなく生成（CREATE）要求と共に資源識別子を送信するであろうことを除いて、データ・コンテナ（即ち、読取りコマンド）の要求と同じである。生成要求に応答して、資源識別子名によってデータ・コンテナが生成される。また、データ・コンテナにおける初期記憶用のデータは、生成要求を伴うことができる。

顧客は、オンライン書店のウェブ・サイトにアクセスして、ウェブページ上に表示された認証アイコン（またはリンク）上でクリックする。任意選択的に（オプションとして）、新しいウェブページが表示されて、例えば顧客の自宅のコンピュータのＵＳＢインタフェースにＩＤトークンを接続することによって、顧客のＩＤトークンを提示するよう顧客に指示する。オンライン書店名は、顧客のＩＤトークン上に表示されてもよく、顧客はＩＤトークン上の“同意”ボタンを押す。ＩＤトークン（従ってユーザ）およびサービス・プロバイダを認証するための上述の認証手順は、顧客のＩＤトークン、オンライン書店のサービス・プロバイダ・エージェント、および第三者認証機関によって運営される認証システムの間で実行される。オンライン書店および顧客が適正に認証されたと仮定すると、第三者認証機関は、資源識別子（顧客のＩＤトークンのユーザＩＤと、オンライン書店に割り当てられたサービス・プロバイダＩＤとを用いて導出されたもの）を使用して、その記憶システムから、オンライン書店／顧客のペアに関連付けられたデータ・コンテナを取り出しおよび／または再構成（再形成）して、このデータ・コンテナをオンライン書店に送信する。データ・コンテナは、顧客のユーザ・プロファイルを含んでいる。このように、顧客の識別およびユーザ情報は、オンライン書店に開示され、顧客との対話および取引（例えば、購入）の実行に使用できる。使用データが変更されない場合、セッションは終了でき（分散型データ記憶システムにおけるデータ・コンテナへの変更なしで）、または、受信したデータは、書込み要求で、分散型データ記憶システムに書き込み返す（write back）ことができる。

ＰＯＳ小売業者の例：
システムは、非電子商取引アプリケーションで（即ち顧客がサービス・プロバイダの小売場所（位置）を訪問する場合）ほぼ同じ方法で動作しまたは運営する。この例では、サービス・プロバイダが小売書店（Retail Bookstore）であると仮定する。顧客がウェブ・サイトにログインするのでなく、顧客は、小売書店のＰＯＳ（Point-Of-Sale、店舗販売時点情報管理）端末に接続されまたは場合によってキオスク（kiosk）に接続されているトークン・インタフェースに顧客のＩＤトークンを提示する。ＰＯＳ端末は、顧客のユーザ端末（即ち、自宅のコンピュータ）として動作し、ＩＤトークンと第三者認証機関のシステムのユーザ・フロントエンド２０８との間の通信を行う。顧客および小売書店の認証は、上述のように行われ、成功した場合は、第三者認証機関は小売書店／顧客のペアに関連付けられたデータ・コンテナを取り出し、小売書店にデータ・コンテナを供給する。例えば、データ・コンテナは、小売書店のシステムに供給されて、ＰＯＳ端末で小売関係者に表示される。このように、顧客の識別情報、請求情報、ロイヤルティ状態、等は、小売関係者に利用可能である。

資源にアクセスする従業員の権利の例：
サービス・プロバイダは、特定のユーザに関連付けられたユーザ・データを格納する認証および分散型データ記憶管理システム２０４を信頼することを選択してもよい。代替形態として、サービス・プロバイダが信頼性あるデータベースに既に大きな投資を行い、そのコア技術を再設計したくない場合には、例えば提示されたユーザにサービス・プロバイダが関係付けるサービス・プロバイダのローカル・ユーザＩＤのような、或る複数の情報だけを、分散型データ記憶システム２１６内に格納することが可能である。この形態のユーザ・データは、必ずしも分散型フォーマットで格納する必要はないが、分散型フォーマットで格納してもよいと、理解されるべきである。この特定のアプローチ（方法）を用いて、雇用者が従業員を認証できるようになり、安全な企業資源にアクセスできるようになる。雇用者／企業の事業体はサービス・プロバイダと見なされ、従業員はユーザである。従業員は、仕事で、従業員が他のサービス・プロバイダ（例えば、オンライン小売業者）に使用する同じＩＤトークン２２４を使用することができる。従業員が未だＩＤトークンを持っていない場合は、（ボーナスの一種として）１つを提供することができる。ＩＤトークンを用いて、安全な（セキュリティのある）領域にアクセスする（例えば、建物、制限されたフロア、等へアクセスする）ことができ、企業ネットワークへログインすることができる。

ユーザがＩＤトークンを仕事用コンピュータへ差し込むまたはプラグインする（そうでなければそれとインタフェースする）とき、上述の処理が実行される。従業員に割り当てられたユーザＩＤおよび雇用者（雇用主）のサービス・プロバイダＩＤを用いて導出された資源識別子を使用して、第三者認証機関の記憶システムから、雇用者のシステム用の従業員のローカル・ユーザＩＤが取り出される。雇用者のシステムは、この従業員がアクセスできる資源を決定するために従う認証手順を組み込んでいる。

雇用者は、多数の方法または形態で利益を受ける。例えば、従業員が従業員の私生活でも（例えば、オンラインおよびＰＯＳ取引で）ＩＤトークンを使用すると仮定すると、ＩＤのトークンは、典型的な企業のアクセス・デバイス（例えば、キーフォブ）よりも、従業員にとってより高い価値を有する。従って、従業員は、昼食等の間に自己のコンピュータに接続されているトークンを置き忘れないように注意するようになる。さらに、従業員が既にＩＤのトークンを持っている度合いに応じて、ＩＤトークンを与えるための費用が雇用主に掛からない。また、雇用者に関するもの（権利）がトークン自体には存在しないので、従業員が会社を出るまたは立ち去るときに、トークンを返す必要がない。従業員が会社を退職するとき、システム管理者は、単に従業員の内部ＩＤに関連付けられた権限（authority）レベルを変更する。従業員を効果的にロックアウトする（締め出す）ために、認証および分散型データ記憶管理システム２０４によって格納されているデータを変更する必要はない。

システムの記憶または格納の特徴（側面）をプライベートなユーザ・データの安全な記憶との関係で主に上述したが、システムはそれに限定されない、と理解すべきである。むしろ、システムを用いて、任意の保護された資源が格納され、任意の保護された資源との関係で認証サービスが提供される。資源は、ユーザおよびサービス・プロバイダが共に認証された場合のみアクセスされまたは取り出される、ソフトウェア・アプリケーション、オブジェクト（対象物）または場所、文書、ページ、ファイル、実行可能なコード、またはその他の計算資源、通信タイプの資源、等であってもよい。また、ここに記載した技術の可能な適用例には、次のものが含まれるが、これに限定されるわけではない。
（１）インターネットの資源の利用、（２）ソフトウェア・プログラムまたはハードウェアを使用するための認証、（例えば、プログラムへのアクセス、またはサービスとしての特別な機能へのアクセス）、（３）ロイヤルティカード、および店舗、レストラン、等におけるその他の顧客識別手段、（４）交通機関カード（例えば、公共交通、スキーリフト、等）、（５）クレジット／デビット・カードのアカウント情報の安全な記憶の利用、および／または安全なインターネット決済またはその他の安全な金融取引（例えば、証券会社の仲介業務取引）の促進、（６）建物への入構、仕事へのログイン、等のための安全なアクセス識別システム、（７）郵便金融取引、例えば、搭乗券、電子バッジ、チケット（例えば、映画またはコンサートのチケット）用のプロキシ、（８）個人健康管理（医療）情報管理およびアクセス、（９）バックエンド記憶システムの、既存の認証および識別システムとの統合、（１０）安全で匿名式の電子選挙、投票、等、（１１）運転免許証およびその他の個人データ用の中央集中型の文書記憶（蓄積）、（１２）ディジタル署名およびセキュリティ証明書、（１３）少額決済用の認証、“ペイ・アズ・ユー・ゴー”（pay as you go、利用時払い）または“ペイ・パー・ユース”（pay-per-use、利用回数に応じた支払い）、（１４）ユーザ間のコネクション（関係）、例えば、名刺交換、（１５）特定のユーザの件に使われたサービス・プロバイダ（例えば、弁護士）の時間の第２の登録までの、例えば正確な、課金システム、（１６）電子メールのスパム（spam、迷惑電子メール）の削除、即ち、認証された者（エンティティ）（サービス・プロバイダまたは顧客）だけが、電子メール・メッセージをその他の認証された者（エンティティ）に送信できることを意味する、または、（１７）企業ネットワークとワークステーションにおける認証、および（１８）ユーザがメール・エージェントを使用するのを可能にするメール証明書（例えば、任意のコンピュータ上でのMozilla THUNDERBIRD^TM（モジラ・サンダーバード）エージェント、またはMicrosoft Outlook（マイクロソフト・アウトルック）（登録商標）エージェント）の格納（記憶）。

本発明を例示的な実施形態に関して説明したが、本発明はこれらに限定されるものではない。むしろ、特許請求の範囲は、本発明の範囲および均等物の範囲から逸脱することなくこの分野の専門家によってなされ得る本発明のその他の変形および実施形態を含むように広く解釈されるべきである。

Claims (38)

1. サービス・プロバイダに対して、ユーザの前記サービス・プロバイダとの関係に関連付けられたユーザ情報へのアクセスを提供する、トークンに基づく集中型認証方法であって、
   ユーザＩＤを格納したユーザ・トークンをユーザ端末において提示するユーザを認証するステップと、
   前記ユーザの前記ユーザＩＤと、前記サービス・プロバイダのサービス・プロバイダＩＤとを含む少なくとも２つのデータ入力要素を用いて資源識別子を導出するステップと、
   を含み、
   前記ユーザ情報は記憶ネットワークに格納され、前記資源識別子は前記ユーザ情報に関連付けられ、
   さらに、前記資源識別子を用いて前記記憶ネットワークから前記ユーザ情報を取り出すステップと、
   前記取り出されたユーザ情報を前記サービス・プロバイダに供給するステップと、
   を含む方法。
2. 前記記憶ネットワークは複数の記憶ノードを含む分散型記憶ネットワークであり、前記ユーザ情報は情報分散アルゴリズム（ＩＤＡ）に従って前記記憶ネットワークに格納されるものである、請求項１に記載の方法。
3. 前記記憶ネットワークは、各ユーザ・トークン用に、前記ユーザ・トークンの状態と、前記ユーザ・トークンに固有の１つ以上の暗号鍵とを含むデータ・コンテナを格納しているものである、請求項２に記載の方法。
4. さらに、少なくとも、前記ユーザ・トークンに固有のＩＤと、前記ユーザ・トークンに固有でない第２のデータ要素とを用いて、第２の資源識別子を導出するステップと、
   前記第２の資源識別子を用いて前記データ・コンテナを取り出すステップと、
   を含む、請求項２に記載の方法。
5. 前記ユーザ情報を取り出すステップは、前記複数の記憶ノードから前記ユーザ情報を再構成するステップを含み、前記再構成されたユーザ情報は前記サービス・プロバイダに供給されるものである、請求項２に記載の方法。
6. 前記導出するステップは、一方向関数を用いて前記資源識別子を導出するステップを含むものである、請求項１に記載の方法。
7. 前記ユーザＩＤおよび前記サービス・プロバイダＩＤは、別々に、前記記憶ネットワークと通信する認証システムによって受信され、
   前記認証システムは、前記ユーザＩＤおよび前記サービス・プロバイダＩＤを用いて前記資源識別子を導出するステップを実行するものである、請求項１に記載の方法。
8. さらに、前記認証システムから、アクセスまたは認証要求に関連付けられた一時的トランザクション識別子を、前記ユーザ端末とサービス・プロバイダ・エージェントの一方に対して発行するステップと、
   前記ユーザ端末と前記サービス・プロバイダ・エージェントの他方から前記一時的トランザクション識別子を受信するステップと、を含み、
   前記認証システムにおいて前記一時的トランザクション識別子を受信した後で、前記資源識別子を導出する前記ステップを実行する、請求項７に記載の方法。
9. さらに、前記ユーザ端末と前記サービス・プロバイダ・エージェントの前記一方が、前記一時的トランザクション識別子を、前記ユーザ端末と前記サービス・プロバイダ・エージェントの前記他方に供給するステップを含む、請求項８に記載の方法。
10. 前記認証システムは、前記一時的トランザクション識別子を前記ユーザ端末に対して発行するものであり、
    さらに、前記ユーザ端末が前記一時的トランザクション識別子を前記サービス・プロバイダ・エージェントに送信した後で、前記サービス・プロバイダを認証するステップを含む、請求項９に記載の方法。
11. 前記認証システムは、前記一時的トランザクション識別子を前記サービス・プロバイダ・エージェントに対して発行するものであり、
    さらに、前記ユーザを認証する前に、前記サービス・プロバイダを認証するステップを含む、請求項９に記載の方法。
12. 前記資源識別子を導出するステップは前記トークンによって実行され、
    前記方法は、さらに、認証システムにおいて、前記ユーザ端末から前記資源識別子を受信するステップを含み、
    前記取り出すステップを実行する際に前記受信した資源識別子を使用する、請求項１に記載の方法。
13. さらに、前記認証システムから、アクセスまたは認証要求に関連付けられた一時的トランザクション識別子を、前記サービス・プロバイダ・エージェントに対して発行するステップと、
    その後、前記ユーザ端末から、前記一時的トランザクション識別子を前記認証システムにおいて受信するステップと、
    を含む、請求項１２に記載の方法。
14. さらに、前記サービス・プロバイダ・エージェントが、前記一時的トランザクション識別子を前記ユーザ端末に送信するステップを含み、
    前記トークンは、前記一時的トランザクション識別子を受信した後で、前記資源識別子を導出するステップを実行するものである、請求項１３に記載の方法。
15. さらに、認証システムから、アクセスまたは認証要求に関連付けられた一時的トランザクション識別子であって前記サービス・プロバイダと関連付けられた名称識別子を含む一時的トランザクション識別子を、サービス・プロバイダ・エージェントに対して発行するステップと、
    前記トークンを使用する前記ユーザに対して前記名称識別子を表示するために、前記サービス・プロバイダ・エージェントから前記一時的トランザクション識別子を前記ユーザ端末に送信するステップと、
    前記ユーザから同意表示を受信するステップと、
    前記同意表示を受信した後で、前記ユーザ端末から前記一時的トランザクション識別子を受信するステップと、を含み、
    前記認証システムにおいて前記一時的トランザクション識別子を受信した後で、前記資源識別子を導出するステップを実行する、請求項１に記載の方法。
16. 前記記憶ネットワークは、前記ユーザに関連付けられたユーザ情報の別々の複数の組を格納し、各組はそれぞれのユーザ／サービス・プロバイダのペアと関連付けられ、各組のユーザ情報は、前記ユーザＩＤおよび対応するサービス・プロバイダＩＤを用いて導出された対応する資源識別子を用いて取り出し可能である、請求項１に記載の方法。
17. 前記ユーザ・トークンがハードウェア・トークンである、請求項１に記載の方法。
18. さらに、前記取り出されたユーザ情報を前記サービス・プロバイダに供給した後で、前記資源識別子に関連付けて前記記憶ネットワークに格納するために前記ユーザ用の１組のユーザ・データを前記サービス・プロバイダから受信するステップを含み、
    前記記憶ネットワークは、前記サービス・プロバイダの、前記受信されたユーザ・データの永続的な記憶装置として機能するものである、請求項１に記載の方法。
19. 前記ユーザ・データは、前記サービス・プロバイダとの前記ユーザの顧客プロファイルの全てまたは一部である、請求項１に記載の方法。
20. 前記資源識別子を導出するステップは、
    前記ユーザＩＤと前記サービス・プロバイダＩＤを組み合わせて１つのデータ要素を供給するステップと、
    公開／秘密鍵暗号ペアの公開鍵で前記データ要素を暗号化するステップと、
    を含むものである、請求項１に記載の方法。
21. 安全なデータ格納と、格納されたデータへのアクセスとを提供する方法であって、
    ユーザ情報を受信するステップと、
    情報分散アルゴリズム（ＩＤＡ）に従って複数の記憶ノードを含む分散型記憶ネットワークに前記ユーザ情報を格納するステップと、
    前記分散型記憶ネットワークから前記ユーザ情報を取り出すのに使用するための資源識別子に前記ユーザ情報を関連付けるステップと、
    少なくとも２つのデータ入力要素を用いて一方向関数の出力から導出された前記資源識別子を受信し、前記資源識別情報を用いて前記分散型記憶ネットワークから前記ユーザ情報を取り出すステップと、
    を含む方法。
22. 前記ユーザ情報を取り出すステップは、前記複数の記憶ノードから前記ユーザ情報を再構成するステップを含むものである、請求項２１に記載の方法。
23. 前記少なくとも２つのデータ入力要素は、ユーザＩＤおよびサービス・プロバイダＩＤを含み、前記ユーザ情報は、ユーザのサービス・プロバイダとの関係に関連付けられるものであり、
    さらに、前記取り出されたユーザ情報を前記サービス・プロバイダに供給するステップを含む、請求項２１に記載の方法。
24. さらに、認証システムにおいて前記ユーザＩＤおよび前記サービス・プロバイダＩＤを受信するステップと、
    前記認証システムを用いて前記資源識別子を導出するステップと、
    を含む、請求項２３に記載の方法。
25. さらに、ユーザ端末から前記資源識別子を認証システムにおいて受信するステップを含む、請求項２３に記載の方法。
26. さらに、前記ユーザ端末においてサービス・プロバイダＩＤを受信するステップと、
    前記ユーザ端末と通信するトークンを用いて前記資源識別子を導出するステップと、
    前記ユーザ端末から前記資源識別子を前記認証システムに送信するステップと、
    を含む、請求項２５に記載の方法。
27. さらに、認証システムから、ユーザ端末とサービス・プロバイダ・エージェントの一方に対して、アクセスまたは認証要求に関連付けられた一時的トランザクション識別子を発行するステップと、
    前記ユーザ端末と前記サービス・プロバイダ・エージェントの他方から前記一時的トランザクション識別子を受信するステップと、
    を含む、請求項２１に記載の方法。
28. サービス・プロバイダに対して、ユーザの前記サービス・プロバイダとの関係に関連付けられたユーザ情報へのアクセスを提供する、トークンに基づく集中型認証システムであって、
    前記認証システムは、サービス・プロバイダ・エージェントおよびユーザ端末とのネットワーク通信における認証およびデータ記憶管理ネットワークを含み、
    前記認証およびデータ記憶管理ネットワークは、
    ユーザを認証するために、前記ユーザ端末を介して、ユーザＩＤを格納したユーザ・トークンと通信するよう構成されたユーザ・フロントエンドと、
    サービス・プロバイダを認証するために、前記サービス・プロバイダ・エージェント・プロセッサと通信するよう構成されたサービス・プロバイダ・フロントエンドと、
    前記ユーザ・フロントエンド、前記サービス・プロバイダ・フロントエンド、および前記ユーザ情報が格納された記憶ネットワークと通信するデータ記憶管理エンジンと、
    を含み、
    前記データ記憶管理エンジは、資源識別子を受信し、前記資源識別子を用いて前記記憶ネットワークから前記ユーザ情報を取り出し、前記サービス・プロバイダ・エージェントに、通信のために前記取り出されたユーザ情報を供給するよう構成されており、
    前記資源識別子は、少なくとも２つのデータ入力要素を有する関数を用いて導出され、
    前記少なくとも２つのデータ入力要素は、前記ユーザＩＤと、前記サービス・プロバイダのサービス・プロバイダＩＤとを含むものである、
    システム。
29. 前記記憶ネットワークは、複数の記憶ノードを含む分散型記憶ネットワークであり、
    前記ユーザ情報は情報分散アルゴリズム（ＩＤＡ）に従って前記記憶ネットワークに格納され、
    前記データ記憶管理エンジンは、前記複数の記憶ノードから前記ユーザ情報を取り出して再構成するよう構成されたデータ・コレクタを含み、
    前記再構成されたユーザ情報は前記サービス・プロバイダに供給されるものである、請求項２８に記載のシステム。
30. 前記データ記憶管理エンジンは、一方向関数を用いて前記資源識別子を導出するよう構成されたものである、請求項２８に記載のシステム。
31. 前記ユーザ・フロントエンドは、アクセスまたは認証要求に関連付けられた一時的トランザクション識別子を前記ユーザ端末に対して発行するよう構成され、前記サービス・プロバイダ・フロントエンドは、前記サービス・プロバイダ・エージェントから前記一時的トランザクション識別子を受信し、前記一時的トランザクション識別子の受信後に前記サービス・プロバイダを認証するよう構成されたものである、または、
    前記サービス・プロバイダ・フロントエンドは、前記サービス・プロバイダ・エージェントに対して前記一時的トランザクション識別子を発行するよう構成され、前記ユーザ・フロントエンドは、前記ユーザ端末から前記一時的トランザクション識別子を受信し、前記一時的トランザクション識別子の受信後に前記ユーザを認証するよう構成されたものである、
    請求項２８に記載のシステム。
32. 前記データ記憶管理エンジンは、前記ユーザ端末から前記資源識別子を受信するよう構成されたものである、請求項２８に記載のシステム。
33. 前記記憶ネットワークは、前記ユーザに関連付けられたユーザ情報の別々の複数の組を格納し、各組はそれぞれのユーザ／サービス・プロバイダのペアと関連付けられ、各組のユーザ情報は、前記ユーザＩＤおよび対応するサービス・プロバイダＩＤを用いて導出されたそれぞれの資源識別子を用いて取り出し可能である、請求項２８に記載のシステム。
34. 前記関数は、前記少なくとも２つのデータ入力要素を組み合わせて１つのデータ要素にし、公開／秘密鍵暗号ペアの公開鍵で前記データ要素を暗号化するものである、請求項２８に記載のシステム。
35. 安全なデータ格納と、格納されたデータへのアクセスとを提供するシステムであって、
    複数の記憶ノードを含む分散型記憶ネットワークと、
    ユーザ情報を受信し、情報分散アルゴリズム（ＩＤＡ）に従って前記分散型記憶ネットワークに前記ユーザ情報を格納するよう構成されたデータ記憶管理システムと、
    を含み、
    前記ユーザ情報は、前記分散型記憶ネットワークから前記ユーザ情報を取り出すのに使用するための資源識別子に関連付けられ、
    前記資源識別子は、少なくとも２つのデータ入力要素を用いて一方向関数の出力から導出され、
    前記データ記憶管理システムは、前記複数の記憶ノードから前記ユーザ情報を再構成することによって、前記資源識別子を用いて前記分散型記憶ネットワークから前記ユーザ情報を取り出すためのデータ・コレクタを含むものである、システム。
36. 前記少なくとも２つのデータ入力要素は、ユーザＩＤおよびサービス・プロバイダＩＤを含み、前記ユーザ情報はユーザのサービス・プロバイダとの関係に関連付けられ、
    前記データ記憶管理システムは、さらに、サービス・プロバイダ・エージェントに、通信のために前記取り出されたユーザ情報を供給するよう構成されているものである、請求項３５に記載のシステム。
37. 前記データ記憶管理システムは、さらに、前記ユーザＩＤおよび前記サービス・プロバイダＩＤを受信し前記認証システムを用いて前記資源識別子を導出するよう構成されたものである、請求項３６に記載のシステム。
38. 前記データ記憶管理システムは認証システムを含み、
    前記認証システムは、ユーザ端末とサービス・プロバイダ・エージェントの一方に対して、アクセスまたは認証要求に関連付けられた一時的トランザクション識別子を発行し、前記ユーザ端末と前記サービス・プロバイダ・エージェントの他方から前記一時的トランザクション識別子を受信するよう構成されたものである、請求項３５に記載のシステム。

Images