JP2019521537A - ユーザプロファイル内にユーザ情報を安全に格納するシステムおよび方法 - Google Patents

Abstract

第１のデータオブジェクトの格納方法は、クライアント装置上で、第１のデータオブジェクトを、第１の本来のレコードロケータに関連する第１の断片、および第２の本来のレコードロケータに関連する第２の断片に分解することと、クライアント装置上で、第１の本来のレコードロケータを難読化して第１の難読化されたレコードロケータを生成し、第２の本来のレコードロケータを難読化して第２の難読化されたレコードロケータを生成することと、クライアント装置上で、第１の暗号化鍵を用いて第１の断片を暗号化し、第２の暗号化鍵を用いて第２の断片を暗号化することと、少なくとも第１の複数の格納場所に、第１の暗号化された断片および対応する第１の難読化されたレコードロケータ、および第２の暗号化された断片および第２の難読化されたレコードロケータを格納することを含む。【選択図】図２

Description

本明細書に記載された種々の実施形態は一般的に情報の電子管理の分野に関し、とりわけユーザプロファイル内のユーザ情報の安全な格納および保護に関する。さらに本明細書に記載された種々の実施形態は、一般的に電子データセキュリティの分野に関し、とりわけデータの安全な格納、管理、およびクライアントエンドポイントにおける、および伝送中のデータ、認証情報および暗号化鍵の伝送に関する。

ますます多くの通信、サービスおよびトランザクションがインターネットのようなネットワークを通じてデジタルで行われるにつれ、ペーパーレスの現代社会のビジョンは迅速に現実になりつつある。書状、金融証書、領収書、契約書および他の法的文書の紙のコピーは、これらの文書を安全に伝達、更新およびアクセスする電子的方法が増加するにつれて減少している。文書および書状の電子伝送およびアクセスに加え、情報の電子的な提出のプロセスもまた、オンラインショッピングまたはローン、クレジットカード、医療保険の申し込み、大学または職の応募などのように、よくあることになりつつある。

しかし、これらのフォームで必要とされる情報の多くは他のフォームと共通であり、さらにユーザは同一の情報でのフォーム入力の取り込みを何度も手動で繰り返す。これらの電子ドキュメント、フォームおよび申し込みで必要とされる入力情報を収集、編成、更新、使用および再適用する可能性は、非常に困難なままである。ユーザの名前、住所および財務情報のようなユーザについてのある基本情報を格納するためいくつかのアプリケーションが開発されたが、追加されたオンラインアクティビティに対しこの格納された情報を編成、アクセスおよび適用する能力は、特に大学出願および家族の法的申告のようなフォームを完成するのに詳細な入力情報および／または計算が必要とされるとき、非常に限定されたままである。

ユーザが財務情報、予算、予測、勘定支払口座などをたどることを可能にするいくつかのプログラムまたはアプリケーションがある。これらのツールは時間を節約し、予算作成などの効果的なツールを提供可能であるが、それらは、特定のフォーマットで、または特定のフォームなどにより個人情報、財務情報、予測、分類された出費などを提供するようユーザが求められる多くの状況に対処しない。

例えば誰かが離婚するとき、彼らは法廷に過去の記録とこれから必要になる両方の詳細な個人および財務情報を提供しなければならない。この情報は特定のフォームを用いて非常に特殊な州が命ずるフォーマットで提供しなければならず、それを離婚プロセス中の種々の時点で更新および法廷に提出しなければならず、それは長期間にわたり続くかもしれない。例えば、図１はカリフォルニア州の離婚訴訟での収入および支出申告書の１つのページを示し、申立人と被告の両方が記入しなければならない。このようなフォームに必要とされる情報の量および複雑さは、通常、離婚の関係者または弁護士のような個人がフォームを完成することを必要とし、全ての必要とされる情報の取得、および所望の価格を得るための情報の計算の実行でさえかなりの時間量を費やす。他の例で、ユーザが自動車ローンまたは住宅ローンのようなローンを望むとき、ローンを提供する組織はしばしば、特定のフォーマットで編成された特定の財務記録および情報を提供および更新するようユーザに求める。

現在利用可能な個人財務ソフトウェアツールを用いてうまく整理して財務に精通したユーザさえ、これらのフォームの完成および更新は厄介で時間がかかり、分かりにくく間違いやすいことがわかる。適用可能なフォームおよび他の適用可能な項目は、基本の財務情報より多くを必要とする。また、フォームは、経済援助、ローン、などについて申込者が適任であるかどうか、または離婚または他の法的手続で望ましい成果を受け取るのに重要な影響が明らかにありうるので、これらのフォームを正確に完成する重要なニーズがある。

これらの同一の困難は、大学出願および／または大学への支払のような他の重要なライフイベントにもかかる。大学出願プロセスは、学生、および多くの場合彼らの両親にとって非常に心配な時間である。大学出願および経済援助申込を完成するのに必要とされる多大な詳細情報があり、それは論文、成績証明書、推薦状、活動、写真などを含むが、それらに限定されない。また、大学出願および経済援助の機会は、多くの異なる締め切りを有する。情報、締め切りおよび提出した出願の全てを整理し、把握し続けることは非常に困難である。

さらに、電子データのセキュリティは、個人およびほぼ全ての考えられる事業体および政府機関にとって最高に重要である。おびただしい量の電子データが、一定の原則で生成、格納、および送信されている。また、電子データの範囲は今日必然的に個人情報および慎重に扱うべき情報におよび、必ず厄介者を引き寄せる。

従来のデータセキュリティ解決法は、比較的静的である。例えば、１つまたは複数のデータセキュリティメカニズム（例えば、パスワード保護、暗号化設定）を、特定のデータ格納場所に配置してもよい。同一のデータセキュリティメカニズムは、重要なセキュリティ侵害が検出されるまで所定の位置にとどまり、その時点でデータ格納場所全体がすでに不正アクセスされたかもしれない。

標準リレーショナルデータモデルに基づき格納されたデータは、特に未許可のアクセスに対して脆弱である。分離した格納場所に格納された個人のデータレコード（例えば、名前、住所、社会保障番号、クレジットカード番号および銀行口座番号）は、データレコード間の論理的関係を示す（例えば同一ユーザに関連付けられた）共用レコードロケータを通常ともなう。例えば、個人のデータレコードをそれぞれ同一のユーザ識別番号と関連付けてもよい。そのように、データレコードのいずれか１つへの未許可のアクセスは、データレコードの残りにアクセスするのに十分な情報（すなわちユーザ識別番号）を露出するかもしれない。

多数のデータセキュリティ方法が利用可能であるが、単一のデータ格納場所における途切れず統合され相補的なデータセキュリティ解決策の柔軟な名簿の実行は、非常に困難であり続ける。例えば、セキュリティ解決策の組み合わせはデータセキュリティを通常増大させるが、異なる解決策間の不適合が実際にさらなるセキュリティリスクを生じるかもしれない。

また、ユーザがデータを格納および取り出し可能であるために、そのユーザを識別し、彼らのデータが他のユーザからアクセスされないよう保護する方法がなければならない。従来、これは「フロントエンド」ソフトウェアにより実行され、ユーザはログインを通して認証され権限を与えられる。

従来のログインプロセスは、報告された多数の欠点に関連する。例えば、多くのシステムで、ログインステップはユーザ・インタフェース（ＵＩ）の一部と一般的にみなされ、セキュリティバブルから分離したエンティティである。問題は、セキュリティの知識に乏しい社内開発者が、カスタムログイン認証および許可システムを作ろうと試みるケースで拡大する。そのように、悪意のあるユーザが正常にログインプロセスを完了すると、そのユーザは潜在的に他のユーザのデータへのアクセスを有することが可能である。

しかし、これらの問題は、今日生成されるデータの多くが、クライアントのエンドポイント、例えば、コンピュータ、ラップトップ、スマートフォン、タブレット、モノのインターネット装置などで生成またはアクセスされる事実により、さらに悪化する。前述の問題がサーバにおいてデータを格納および取り出すことについて解決可能であっても、エンドポイントにおけるデータを保護のさらなる問題がある。よって、前述の問題のあらゆる解決策は、クライアントのエンドポイントもまた保護されなければならないという事実を考慮すべきである。

鍵交換方法
２つの装置間の信頼できる通信リンクを確立し、送信されたデータを暗号化／復号することについて、対称共有秘密鍵またはパブリック／プライベートの非対称鍵を通すような、現在の使用での多数の形態の鍵交換方法論がある。対称暗号化は、ＡＥＳ、Ｂｌｏｗｆｉｓｈ、ＤＥＳ、およびＳｋｉｐｊａｃｋのような多数のアルゴリズムを通してデータの暗号化および復号の両方に同一の鍵を使用し、通常は非対称暗号化より速い。それは、大容量データの暗号化、および高速のデータスループットが必要なときにしばしば使用される。対照的に非対称暗号化は、パブリックおよびプライベートの一対の鍵を使用し、パブリック鍵は通常データの暗号化に使用され、プライベート鍵はデータの復号に使用される。非対称鍵アルゴリズムは対称鍵アルゴリズムより１０００倍遅いことがありえ、従って、より一般的に、莫大なリソース能力を必要とするであろう鍵のペアの連続した交換がない鍵管理または最初の装置認証に適用される。

暗号化されたデータ伝送
大規模なオブジェクトを複数のクライアントの宛先に暗号化して送信する必要があり、それぞれのクライアントが一意的に暗号化されたコピーを持つべきである場合の一般的なシナリオで、従来のアプローチは、それぞれのクライアントに対し異なる鍵を用いて本来のオブジェクトを暗号化することである。Ｎ個のクライアントがあり、それがそれぞれのオブジェクトの暗号化に時間量Ｔをかける場合、合計の暗号化時間はＮ×Ｔである。

データの暗号化速度
現在、性能（データが暗号化可能な速度）を上げるいくつかのアプローチがある。１つのアプローチは、ハードウェアベースの高速化を用いることである。１２８ビットおよび２５６ビットのＡＥＳサイファを、ＡＥＳ−ＮＩハードウェアの暗号化を通して、（ＩｎｔｅｌおよびＡＭＤプロセッサ上で利用可能な場合）４から８倍加速可能である。セキュリティを犠牲にして、鍵のサイズを減少させることもまた可能である。２５６ビットの鍵のＡＥＳは、１２８ビットの鍵のＡＥＳより約４０％遅い。他の戦略は、２０％の速度改善が可能なＢｌｏｗｆｉｓｈのような別の暗号化アルゴリズムを使用することである。

暗号化鍵の管理
暗号化鍵は通常、データの暗号化または他の鍵の暗号化に使用され、他の鍵はその後でデータの暗号化に使用され、後者は一般的に鍵の暗号化鍵（ＫＥＫ）として知られる。鍵および鍵にアクセスする人の管理は、手ごわいタスクでありうる。鍵管理ソフトウェア（ＫＭＳ）は、必要がある鍵の全てにユーザおよび管理アクセスを提供することにより、この作業をより容易にするよう試みる。ＫＭＳはまた、壊滅的なサーバ故障の場合に鍵のコピーを保護するバックアップおよび重複性サービスを提供してもよい。ＫＭＳが常に作動している場合を除いて、暗号化されたデータへのアクセスが不可能なので、置換ＫＭＳが迅速に転回するときユーザの稼働時間は維持される。

複合セキュリティ鍵
複合鍵の概念は広く知られ、多くのシナリオで使用される。例えば、ファイルのロックを外すためのアリスとボブの複合鍵は、彼らにファイルのロックを外す能力を提供するが、彼らの両方がそれを同時にロックを外す場合のみである。ボブまたはアリスのどちらも、独立してファイルのロックを外すことは不可能である。これらの複合鍵は通常静的であるが、変更が必要とされるときは管理者によって書き換えなければならない。

データのアクセス制限
データへのアクセスを制限する必要があるとき、一般的に使用されるアプローチは、ユーザレベルでアクセス権を構成、および／またはそれぞれが割り当てられた異なる役割および許可を有するユーザのグループを設立することである。これは、ユーザＡが例えばユーザＢのデータへのアクセスを有さないことを確実にする。データベースに一般的に使用される他のアプローチは、データへのアクセスを可能にする前に任意の数の制限についてデータベース・クエリ・ステートメントを開発することである。全てのこれらの解決策での問題は、それらがデータ項目レベルで細かい制御を有するための簡単な方法を提供せず、これらの制限自体が広く暗号化されていないことである。

ハッキング
ハッカーは、彼らが発見される前にシステム内で平均２００日を費やしている。内部にいる間、彼らはトラフィックを観察し、追加の認証情報、ユーザ名、パスワード、などを特定する種々の試みをする。アクセスログおよび行動分析は、検出の努力が焦点をおくいくつかの方法である。また、「ハニーポット」ファイル、データベース、またはサーバが、ハッカーの速度を抑える試みで戦略的におかれる。

ランサムウェア
ランサムウェアは、ネットワーク接続されたドライブおよびクラウドフォルダ上のものを含むコンピュータに見える全てのファイルに適用される暗号化アルゴリズムを実行する
コンピュータ上にひそかに導入されたソフトウェアである。目的は、犠牲者が身代金を払うまで影響を受けたファイルを使用不可能にし、支払の時点で復号鍵が提供される。ランサムウェアソフトウェアまたは多数のファイル改名アクティビティによって生成されることで知られる拡張子を持つファイルの外見などの特徴に基づき、攻撃のサインを早く識別するよう試みる製品がある。他のアプローチは、ユーザが電子メールの添付物（攻撃の最大のソース）をクリックするのを防ぐクリックブロッキングソフトウェアを含む。最後に、感染しているサインでありうる異常なプロセス実行を監視する多くのマルウェア解決法がある。

ランサムウェアに対して保護する最も効果的な解決法は、全てのファイルのバックアップであり、数日分のバックアップがあることを定期的に確認する。自動スケジュールでバックアップを実行するさまざまな製品がある。しかし、多くのバックアップシステムは、バックアップのために据え付けられたドライブを使用する。ランサムウェアがファイルを見ることができれば、それはバックアップのために使用されるファイルを含む全てのドライブを見ることができる。適切なアクセス認証情報およびプロトコルの設定のような、バックアップドライブを保護する方法がいくつかある。ランサムウェアは継続的に発達および適応してきており、多くのこれらの解決法は、犯罪者への立場をなくしてきた。

暗号化データの検索
検索フィールドの事前の索引付け、または評価を可能にし、従って暗号化データの検索を可能にする準同形暗号化のような、暗号化データを検索する多数のアプローチがある。最大の困難は、検索プロセスを遅くするか、またはセキュリティの欠点をもたらすかどちらかのアクセス可能制限および全ての方法内で性能を維持することである。どのケースでも、これらの方法は実行で広範囲に変わり、標準に従うことはまれである。これらのカスタム実施が、サードパーティ検索ツールの利用を困難にする。

データの暗号化
データは、従来、任意の数の状態にある間に暗号化される。例えば、ハードドライブ全体を静止したデータのために暗号化してもよい。他の例では、動作中のデータがセキュアｈｔｔｐｓ接続を通して移動するときに暗号化してもよい。データベース内のデータを、個々のフィールド内のデータが所定の位置で暗号化しながら本来のテーブルフォーマットを保存する方法を用いて暗号化してもよい。他の特別なシナリオは、単一のデスクトップフォルダまたは据え付けられたディスクドライブの暗号化を含む。

全てのこれらのケースで、暗号化されるデータはフォーマット内で編成されず、それらの本来のフットプリントと大きく異なる。暗号化されたデータは単に所定の位置の元のデータを置き換え、または他の媒体に複製した場合、元のデータと同様のデータおよびファイル階層を用いて記憶装置に転送される。データシャーディングおよびイレージャーコーディングアルゴリズムのようなケースで、データ格納フォーマットを再編する他の技術が存在する。これらは元のデータを分配し、そのデータをまた暗号化してもよい。しかし、分配および格納フォーマットは基本的なアルゴリズムにより課される厳格なプロトコルに従い、それによってより高いレベルの機能、および既存のレガシーのフォーマットおよび／またはサードパーティ解決策との統合を加えることを困難にする。

本明細書中に開示されるのは、情報へのアクセスを防ぎ、セキュリティ侵害の間に公開される情報量を最小化する、ユーザの情報をユーザプロファイル内に安全に格納するシステムおよび方法である。ユーザに関係する情報が電子手段を通して１つまたは複数のソースから取得され、その後その情報がフィールドマッピングおよび他の技術を用いて特定のカテゴリへ分類され、その後それがユーザプロファイルに編成され、データベース内に安全に格納される。収集および編成された情報は、識別情報および連絡先情報、財務情報、健康情報、教育および職業情報、家族情報、事業情報、ライフスタイル情報、およびリストされたカテゴリのいずれかについての履歴情報を含んでもよい（しかし、それらに限定されない）。ユーザプロファイルを暗号化して、リモートサーバにおいてクラウドベースのシステム内で離れて格納してもよく、プロファイルの一部を個別に暗号化して分離した場所に格納し、情報の一部分への未許可のアクセスのリスクを最小化してもよい。ユーザプロファイル内のデータのフィールドもまた、個別の暗号化鍵で個別に暗号化し、個別のデータストア、データベース、または個別のデータベーステーブルに分離して格納し、単一の暗号化鍵または単一のデータベース、またはデータベーステーブルへの未許可のアクセスによって公開されうる情報の量を最小化してもよい。

本発明の１つの態様では、ユーザプロファイルからユーザ情報を安全に格納するシステムは、複数のフィールドおよび複数のフィールドについての複数の値を含むユーザ情報のユーザプロファイルを作成するプロファイル作成ユニットを備え、ユーザプロファイル内の情報が区画に分離され、区画は分離したデータストア、データベース、またはデータベーステーブル内に分離して格納される。

本発明の別の態様では、ユーザプロファイルからユーザの情報を安全に格納する方法は、複数のフィールドおよび複数のフィールドについての複数の値を含むユーザ情報のユーザプロファイルを作成するステップと、ユーザプロファイル内の情報を分離した区画に分離するステップと、分離した区画を分離したデータストア、データベースまたはデータベーステーブル内に格納するステップを含む。

また本明細書中に開示されるのは、クライアントのエンドポイントからおよびクライアントのエンドポイントを含む開示されたデータ、認証情報および暗号化鍵の安全な格納、伝送および管理のためのシステムおよび方法である。１つの態様によると、第１のデータオブジェクトの格納システムは、複数の格納場所と、１つまたは複数のプロセッサを備えるセキュアプラットフォームと、第１のデータオブジェクトを、第１の本来のレコードロケータに関連する第１の断片、および第２の本来のレコードロケータに関連する第２の断片に分解し、第１の本来のレコードロケータを難読化して第１の難読化されたレコードロケータを生成し、第２の本来のレコードロケータを難読化して第２の難読化されたレコードロケータを生成し、第１の暗号化鍵を用いて第１の断片を暗号化し、第２の暗号化鍵を用いて第２の断片を暗号化し、少なくとも第１の複数の格納場所に、第１の暗号化された断片および対応する第１の難読化されたレコードロケータ、および、第２の暗号化された断片および第２の難読化されたレコードロケータを格納するように構成された１つまたは複数のプロセッサを備えるクライアント装置を備える。

他の機能および利点は、添付の図と併せて望ましい実施形態の後述の記載から明らかになるはずである。

本明細書中に開示される種々の実施形態を、後述の図を参照して詳細に記載する。図は説明の目的のみで提供され、単に典型的または例示的な実施形態を示すだけである。これらの図は読者の理解を容易にするため提供され、その実施形態の広がり、範囲、または適用性を限定すると考えるべきではない。説明の明確さおよび容易さのために、これらの図は必ずしも縮尺通りに作成されていないことに留意すべきである。

離婚手続で使用される収入および支出の申告フォームの画像である。 本開示の種々の態様による、電子フォーム上に個人情報を取得、分類および取り込むシステムを示すブロック図である。 本開示の種々の態様による、種々の態様による、電子フォーム上に個人情報を取得、分類および取り込むシステムをさらに示す図である。 本開示の種々の態様による、ドキュメントのフィールド取り込みに関与する動作の例示である。 本開示の種々の態様による、本発明のシステムを実行するブラウザ拡張を示すグラフィカルユーザインタフェースのスクリーンショットである。 本開示の種々の態様による、フィールド識別番号、フィールド名およびフィールド値をリストするデータベーステーブルの画像である。 本開示の種々の態様による、自動完成システム内に格納されたフォームのデータベーステーブルの画像である。 本開示の種々の態様による、システム内に格納されたそれぞれのフォームドキュメント上にフィールド名およびフィールド値をリストするデータベーステーブルの画像である。 本開示の種々の態様による、ユーザ情報を予め取り込むドキュメントのカテゴリを選択するｗｅｂインタフェースを示すグラフィカルユーザインタフェースのスクリーンショットである。 本開示の種々の態様による、ユーザ情報を予め取り込む特定のドキュメントを選択するｗｅｂインタフェースを示すグラフィカルユーザインタフェースのスクリーンショットである。 本開示の種々の態様による、自動的に識別され、システムデータベース内に格納されることが可能な一意のフィールド名を持つフォームのグラフィカルユーザインタフェースを示す。 本開示の種々の態様による、フィールド内に取り込まれたシステムデータベース内に格納された一意のフィールドの値を持つ図１０Ａのフォームのグラフィカルユーザインタフェースを示す。 本開示の種々の態様による、図１０Ａおよび図１０Ｂで示されるフォーム内の一意のフィールドについてフィールド識別子、フィールド名およびフィールド値を格納するデータベーステーブルの画像である。 本開示の種々の態様による、電子フォーム上に個人情報を取得、分類および取り込む方法を示すフローチャートである。 その上で本開示の種々の態様による実施形態を実行しうる、コンピュータ／サーバシステムの実施形態を示すブロック図である。 米国出願第１４／８６３，２９４号の図１の複製であり、その出願の開示はその全体が参照により本明細書に組み込まれる。 米国出願第１４／９７０，４６６号の図１の複製であり、その出願の開示はその全体が参照により本明細書に組み込まれる。 米国仮出願第６２／２８１，０９７号の図１の複製であり、その出願の開示はその全体が参照により本明細書に組み込まれる。 米国仮出願第６２／２８１，０９７号の図４の複製である。 本開示の種々の態様による、鍵交換方法を示すフローチャートである。 本開示の種々の態様による、暗号化されたデータ伝送シーケンスを示すシーケンス図である。 本開示の種々の態様による、暗号化の速度を上げるためデータを予めスライスする方法を示すフローチャートである。 本開示の種々の態様による、データファイルを再結合する方法を示すフローチャートである。 本開示の種々の態様による、暗号化鍵を管理する方法を示すフローチャートである。 本開示の種々の態様による、複合鍵の評価方法を示すフローチャートである。 本開示の種々の態様による、データアクセスの制限方法を示すフローチャートである。 本開示の種々の態様による、ハッキング攻撃の検出および反応方法を示すフローチャートである。 本開示の種々の態様による、ランサムウェア攻撃の検出および反応方法を示すフローチャートである。 本開示の種々の態様による、暗号化されたデータ上の検索を可能にする方法を示すフローチャートである。 本開示の種々の態様による、暗号化されたデータを格納する仮想暗号解読コンテナの使用方法を示すフローチャートである。

前述の種々の実施形態を、例示的な実施形態の前述の図および例示的な実施形態の後述の詳細な記載に関連してさらに詳述する。

本明細書に記載された実施形態は、オンラインショッピング勘定フォーム、ローン、クレジットカード、医療保険、大学または職の申込、（離婚または破産のような）法的手続に必要とされる政府が命ずるドキュメント、および事業および事業オーナに対し、またはそれらにより必要とされるフォームのような複雑な電子ドキュメントおよびオンラインフォームを自動的に完成、更新および提出するための情報の収集、編成および使用を提供する。情報は、複数の異なるソースから取得され、フィールドマッピングおよび他の情報分類技術を通して分類され、情報安全区域として知られるユーザに関連する情報の編成されたデータベースを形成する。情報のセキュリティを確実にするよう、情報は、暗号化および分離技術により、１つまたは複数のユーザデータストアまたはデータベース内に安全に格納される。フォームデータベースが、電子フォームおよびドキュメント、ならびにそのフォームまたはドキュメントを完成するのに必要とされるフィールド情報の格納に使用される。ユーザは、フォームデータベースからドキュメントを選択することにより、またはｗｅｂブラウザ内に表示されるオンラインフォームを取り込むブラウザプラグインを使用することにより、ユーザの情報をオンラインフォームまたは電子ドキュメントのフィールドに自動的に取り込むようにアクセス可能である。システムはまた、サードパーティサービスおよびウェブサイトと統合して、ユーザデータベースへのセキュア接続を介してサードパーティサイトに情報を取り込と同時に、ユーザが高度なセキュアデータベース内に情報を保持するのを可能にしてもよい。

ユーザのデータベースが例えば、高い正確性で分類されフォームが正しい情報で取り込まれることを確実にする識別情報、財務情報、健康情報、連絡先情報および過去のユーザ情報を含むユーザプロファイルを形成するとき、本明細書に記載された技術は、あらゆるタイプの計算装置上のあらゆるタイプのフォームを迅速および正確に完成、更新および送信する能力を提供する。ユーザは、ユーザの情報のあらゆるダウンロード、伝送、編集または削除の完全な制御を維持し、同一のプロセスを何度も繰り返すのではなくユーザの情報を一度入力および確認する必要があるのみである。

本明細書に記載されたシステムおよび方法を、種々のタイプの情報収集、管理および入力のため、個人、グループ、団体、政府、または事業体が使用してもよい。個人ユーザは、ユーザのデスクトップ、タブレット、スマートフォン、などでオンラインフォームを取り込んでもよく、即座にそのフォームを完成可能である。１つの実施形態では、システムを、スマートフォン、タブレットまたは他のポータブル電子装置上で実行するモバイルアプリケーションとして提供してもよく、それはユーザがフォームまたは他のドキュメントを完成するのを可能にするであろう。小さい表示画面およびタッチスクリーン装置を用いて情報を入力する困難さにおいては、ポータブル電子装置で情報を容易に取り込む能力が特に好都合である。事業体は、種々の管轄などで人的資源フォーム、建設許可フォーム、エレベータライセンスフォームなどのようなフォームを完成するための情報を編成および格納してもよい。本明細書で提供される例は主として個人ユーザのためのシステムおよび方法の使用に関するが、受益および適用はあらゆるサイズおよびタイプのユーザのグループ、団体、政府、または事業体にも及ぶ。

ユーザが一度情報を入力すると、その情報がユーザの情報安全区域内に格納され、その後ユーザは情報の供給、または同一の情報の繰り返しを必要とするあらゆるフォームを完成するのにそれを永遠に使用可能であるので、この解決策は比類のないものである。非限定的な例は、健康管理についての新しい患者のフォーム、大学入学出願、奨学金申込、経済援助申込、ローン申込、医療質問表、職の応募、保険フォーム、法的申告または手続きドキュメント、政府の給付金またはサービス要求、個人の健康記録、ｅコマース勘定フォーム、入会申込などを含む。

図２は、本発明の１つの実施形態による、情報を電子フォーム上に取得、分類および取り込むシステム１００の１つの実施形態を示す。情報は、既存のフォーム１０２ａ、サードパーティアプリケーションインタフェース１０２ｂまたは手動のユーザ入力１０２ｃのような１つまたは複数の情報ソース１０２ａ〜１０２ｃから取得される。情報はその後通信インタフェース１０４へ伝送され、その後サーバ１０６により分類され、ユーザの情報のユーザプロファイルとして１つまたは複数のデータ記憶装置、場所またはシステムデータストア１０８内に格納される。通信インタフェース１０４は、情報ソース１０２と共にローカルエリアネットワーク（ＬＡＮ）内にあることが可能であり、またはインターネットまたは他の広域ネットワーク（ＷＡＮ）を介した接続を通して情報ソース１０２から離れた場所にあることが可能である。通信インタフェース１０４はまた、情報に適用可能なフィールドおよびフィールドの値を識別する情報を分類する分類ユニット１０６ａ、分類された情報でユーザプロファイルを作成するプロファイル作成ユニット１０６ｂ、および少なくとも１つのフォームフィールドを分類された情報とマッチングすることにより電子フォームの少なくとも１つのフォームフィールドまたはデータベースを取り込む情報取込ユニット１０６ｃを含む、収集された情報を処理するサーバ１０６内の１つまたは複数の情報処理ユニットを有する。フィールド比較ユニット１０６ｄおよびユーザアクティビティ収集ユニット１０６ｅ １０４をさらに有することが可能であり、それらの機能はさらに後述する。システム全体の設計によって、前述のユニット１０４のいずれも、分離したサーバ内または単一のサーバ内に位置付けることが可能である。その後ユーザは、装置１１０ａ〜１１０ｃのいずれかのタイプを通して、ユーザのプロファイル内の情報を用いて１つまたは複数のフォーム１１２を完成するよう要求可能である。ラップトップコンピュータ１１０ａ、デスクトップコンピュータ１１０ｂ、またはタブレットもしくはスマートフォンのようなポータブル電子装置１１０ｃを含むあらゆるタイプの装置を、ユーザが使用可能である。

ユーザは、イメージビューア１１２ａ、インターネットブラウザアプリケーションに表示されるフォーム１１２ｂ、またはポータブル電子装置１１０ｃ上で実行するアプリケーション１１２ｃにより表示されるフォーム１１０ｃのような１つまたは複数のフォーム１１２ａ〜１１２ｃを完成する装置１１０を通して、通信インタフェース１０４と相互作用可能である。フォームをまた、ＨＴＭＬ５−ＣＳＳ３またはサーバ１０６とインタフェース接続するアプリケーション１１２ｃを介してブラウザウィンドウに直接、またはサーバ１０６により生成され装置１１０ｃ上に表示される１つまたは複数のグラフィカルユーザインタフェース（ＧＵＩ）１１４を通して表示することが可能である。本明細書で示されたように、フォームをユーザの装置上に直接、ブラウザ拡張、アドオンブラウザアプリケーション、またはサードパーティサービスまたはアプリケーションと相互作用するアプリケーションプログラミングインタフェース（ＡＰＩ）を介して取り込み可能である。

図３は、システムの１つの構成のセキュリティプロトコルを示すシステム系統図の例示である。ユーザ１１６は前述の種々の装置１１０を介してシステムにアクセス可能であり、それらはインターネット１１８により通信インタフェース１０４と接続される。プライバシーおよびセキュリティを確実にするようにユーザプロファイル情報の保護を高めるため、複数のタイプ、場所、装置、サーバ、などを種々のファイアウォール間に分離して使用可能である。ユーザに最初に通信インタフェース１０４のパブリック対面ホームサイト１０４ａとみなされる基本情報を示すＧＵＩを表示することが可能であり、それはまた最初のファイアウォール１２０ａにより保護される。最初のファイアウォール１２０ａはシステム全体のセキュリティを提供可能であり、インタフェースのユーザ・インタフェースおよび体験レベル（ＵＩ／ＵＸ）１０４ｂにアクセスするのを可能にする。ＵＩ／ＵＸ１０４ｂは、フォームおよびアプリケーション出力データストア１０８ａと接続されたｗｅｂおよびインタフェースサーバ１０６ｆを含む。第２のファイアウォール１２０ｂは、データアクセス層１０４ｃとして知られる通信インタフェースの第３の区画を保護可能である。データアクセス層１０４ｃは、データストアサーバ１０６ｈと接続されたビジネスモデルロジックアプリケーションサーバ１０６ｇを有することが可能であり、ビジネスモデルロジックアプリケーションサーバ１０６ｇを、セキュアクライアントデータエレメントおよびヒストリカルアーカイブデータストア１０８ｂならびにマッピングされた入力フォームデータストア１０８ｃを管理するよう構成可能である。分離したＩＤおよび認証サーバ１０６ｉもまた、データアクセス層１０４ｃ内に包含することが可能であり、サーバ１０６ｉは識別情報データストアサーバ１０６ｊに接続され、サーバ１０６ｊはセキュアクライアントＩＤエレメントデータストア１０８ｄを管理可能である。

図４は、情報取込ユニット１０６ｃのようなデータストア管理ソフトウェアを通してセキュアクライアントＩＤエレメントデータストア１０８ｄおよびセキュアクライアントデータエレメントデータストア１０８ｂ内に格納された情報にアクセスすることにより、フォーム４０４のフィールド４０２を取り込むステップの１つの実施形態を示し、そこでは、分離したクライアント識別情報データストアおよびクライアント情報データストアが、電子フォームに取り込むのに必要とされる情報を取得するのに使用される。

システムおよび方法の詳細は、特定の構成要素および機能に関連して本明細書内でさらに提供する。

Ｉ．情報およびフォームの収集
ユーザの情報の完全なセットを取得するため、情報を複数の異なるソースおよび複数の異なるフォーマットから取得可能である。例えば、多くのフォームがさまざまなカテゴリ（すなわち、ローン申し込み、オンラインショッピング、大学出願、離婚手続など）で必要とする情報を収集するよう特別に設計された「マスタフォーム」をユーザに完成させることにより、ユーザ情報を取得可能である。ユーザ情報をまた、金融機関データベース、電子健康記録、サードパーティ情報アグリゲーションサービス（Ｍｉｎｔ．ｃｏｍ（登録商標）など）のような既存の電子記録または非電子記録から、またはユーザがシステムのｗｅｂベースのユーザ・インタフェース内で簡単な命令に従うことにより、収集可能である。関連の情報が取得可能であり、システムがフィールドおよび内容情報を取得するためにサードパーティのサイトと通信するよう特定のアプリケーションプログラミングインタフェース（ＡＰＩ）を使用可能なように、ユーザはこれらの既存の電子記録の１つまたは複数にアクセスするのを許諾する必要があってよい。既存の電子記録については、実質的に追加の情報の分類が必要ないように、情報が特定のフィールド名または識別情報により例えばデータベース内ですでに分類されていることが十分に考えられる。しかし、離婚調停書および金銭スケジュールのような多くのフォームの複雑性によって、システムは追加の計算を重ね、フォームの必要とされる出力に一致するよう分類を再編成することが可能である。非電子記録については、ユーザは非電子書類をスキャンまたは写真に撮り、画像処理およびコンテンツ抽出ソフトウェアのような種々の技術を通して抽出されたフィールドおよびフィールド値を有することが可能でありうる。

１つの実施形態では、ユーザが手動で電子フォームまたはドキュメントを完成するとき、情報を取得可能である。例えば、図５に示されるように、ユーザがインターネットブラウザアプリケーション上に表示されたフォーム１１２ｂを完成すると、アプリケーションは、同一のまたは他のフォームでの将来の使用のため、ユーザのデータベースにフォーム１１２ｂ、フィールド５０４およびフィールドの内容５０６を捕捉、抽出、編成、分類および更新するのを可能にするブラウザ拡張５０２を有することが可能である。ブラウザ拡張５０２は、ポップアップメニュー５０８とフィールドをユーザプロファイルにコピーするコピーボタン５１０、ならびにユーザプロファイルからフォーム１１２ｂへデータを取り込むフィールド入力ボタン５１２を提供可能である。多数のページにわたるフォームを完成する目的にも情報の抽出および取り込みが可能である。空白のフォームおよびドキュメントおよび他のユーザ情報もまたシステムに直接アップロード可能であり、そこでフォームまたはドキュメントおよびそのフィールドを、テンプレートとして捕捉、マッピングおよび格納可能である。例えば、クレジットカード申込フォームをシステムにアップロードして識別されたフォームフィールドと共にドキュメントライブラリデータストアに格納してもよく、これにより、手動または自動マッピング技術の使用のどちらかで、それらをデータストア内の対応するユーザフィールドにマッピング可能である。

完成したフォームおよびドキュメントをさらに、システムに直接アップロード可能であり、そこでフォームまたはドキュメント、フィールドおよびフィールドの内容を捕捉および抽出可能である。例えば、クレジットカード明細書または住宅ローン明細書をシステムにアップロード可能であり、フィールドおよびフィールドの内容がユーザのデータストア内に抽出および格納可能であるが、その文書自体はフォームではないので不可能である。しかし、クレジットカード申込または住宅ローン申込がアップロードされていれば、ユーザおよび他のユーザが将来フォームに記入するのを補助するため、フィールドおよび内容に加えてそのドキュメント自体を抽出および格納してもよい。

図６は、データストアテーブル６０２とシステム内に入力されたフォームから収集されたフィールド情報の１つの実施形態を示す。情報がサーバ上で作動しているフォームから送信されるとき、情報はこのテーブル内に格納される。サーバから「引き出され」フォームに適用されるとき、情報はこのテーブルからくる。フォームは図１で示されるようなフォームであることが可能で、フォームフィールドがすでに入力された値を有するように、ユーザが完成しておくことが可能である。図６に示されるように、フォーム上のそれぞれのフィールド６０４には、他のフィールドから区別するための一意の数字識別子６０６（ｃｕｓｔｏｍｅｒＦｉｅｌｄＤｅｆａｕｌｔｓ＿Ｉｄ）が提供される。右の２列に示すように、それぞれのフィールドはさらに所定のフィールド名６０８（ｆｉｅｌｄＮａｍｅ）およびフィールド値６１０（ｆｉｅｌｄＶａｌｕｅ）が与えられる。フィールド名はフォーム自体で暗号化された名であってもよく、ウェブサイト上または元のフォームを生成したプログラマに基づいたフィールド名をすでに識別したフィールド名メタデータを持つ電子フォーム上にあれば、フォームから抽出可能である。（利用可能であれば）フィールド値は、明瞭にフィールドの内容に対応する。（名−値のペアとして知られる）フィールド名およびフィールド値の間の関連は、内容の分類およびユーザプロファイルの形成に重要である。

図７はドキュメントライブラリテーブル７０２を示し、システム内に格納されたドキュメント７０４のリストを格納する。ドキュメントのそれぞれには、ドキュメント識別情報７０６（ｄｏｃｕｍｅｎ＿ｉｄ）、ドキュメントタイトル７０８、および関連するデータベース内のドキュメントへのパス７１０が提供されている。図８はデータベーステーブル８０２を示し、図７のドキュメントライブラリテーブル内のそれぞれのドキュメントのフィールド名８０４（ｆｉｅｌｄＮａｍｅ）を格納する。それぞれのフィールドにデフォルト値を設定する選択肢があることに留意されたい。例えば、今年の税金フォームは２０１３年のデフォルト記入を有してもよい。ｃｏｍｍｏｎＦｉｅｌｄＮａｍｅ８０６は、ｆｉｅｌｄＮａｍｅが不明瞭または元のフォーム設計者がうまく名付けていないケースのｆｉｅｌｄＮａｍｅ８０４の人間が可読なバージョンである。ｃｏｍｍｏｎＦｉｅｌｄＮａｍｅ８０６は、システムがそのフィールドを一般的な顧客の保管場所で見出されるフィールド名と迅速にマッチングするのを可能にする。ｃｏｍｍｏｎＦｉｅｌｄＮａｍｅ８０６は、より信頼性のある決定的なフィールドのマッピングとユーザプロファイルで見出されるフィールド名を提供する。

将来の使用のため、システム内で一意のフィールド名および値が格納および編成される。図１０Ａおよび図１０Ｂは「請求書送付」区画１００６内の一意の請求書送付コードフィールド１００４を有するオンラインフォーム１００２の例示であり、コードフィールドは一意の３３桁のコードである必要がある。ユーザがシステムにコードを予め入力しなかった場合（特定のフォームのための一意のコードであることを考えると可能性は低い）、図１０Ｂに示されるように、ユーザは、初めてフォーム１００２を完成するときにフィールド１００４内にフィールド値１００８を手動で入力する必要がある。図１１のテーブルで示されるように、システムは、フィールド１００４上の情報（およびそのフィールド内にユーザが入力した値１００８）をシステム内に引き込み、データベーステーブル１１００内にそれらをリストする。図１１に示されるように、このフィールドに対し生成された２つの入力があり、１つがフィールド名１１０２（数字）に対応し、１つがフィールド値１１０４（３３桁の数字）に対応する。１つの実施形態では、フィールドの隣のラジオボタンをフィールドおよびフィールド値と関連させるよう追加のライン入力（図示せず）が生成される。これは、フォームが将来取り込まれときに、フィールド値を入力するときにシステムがラジオボタンを作動する／選択することを認識するので有用である。

別の実施形態では、サードパーティサービスおよびウェブサイトが、フィールド名および他のドキュメントまたはフォーム識別情報のような、システムに格納するため自身のサイト上で提供されるフォームおよびドキュメントについての情報を提供可能である。よって、ユーザがサードパーティサービスを使用中でサードパーティサービスのフォームまたはドキュメントを完成する必要がある場合、ユーザはサードパーティのサイトでそのフォームまたはドキュメント内に取り込むため、サードパーティサービスにユーザデータストアからユーザの情報を取得するよう要求可能である。その後サードパーティサービスは、それらのウェブサイトまたはアプリケーション上にそれらのカスタマイズされたフォームまたはドキュメントを保持可能であり、サードパーティサービスがフィールド情報をシステムに提供するため、ユーザはフォームまたはドキュメント内に取り込まれた内容が正確にそれぞれのフィールドが必要とする内容に対応することを確実にできる。また、情報がサードパーティサービスのデータストアではなくシステムのデータストアに格納されるので、ユーザには情報の付加的なセキュリティが提供され、情報がサードパーティサービスまたはサイトから盗まれうる機会を減少させる。

別の実施形態では、フォームおよび他のドキュメントを完成するため、アプリケーション内またはサードパーティサーバにおいて格納された情報がシステムと共有および使用されるように、サードパーティサービスはそれらのウェブサイトまたはアプリケーション内で実現されたシステムを統合可能である。同様に統合は、サードパーティのサイトにおいてフォームまたはドキュメントを完成するための、ユーザの情報のサードパーティサイトまたはアプリケーションとの共有を提供する。

当業者に明らかであろうように、情報の他のソースを使用されるか、または想定されうる。さらに後述するように、種々のソースからユーザの情報を収集すること、およびその情報を、あらゆるフォーム上のあらゆるタイプのフィールドまたは補足情報を取り込むのに使用可能な情報の編成されたリストにコンパイルすることにより、それぞれのユーザプロファイルを形成するため、情報ソースが使用される。

ＩＩ．情報の編成および格納
前述の種々の情報ソースから取得された情報は、個人のユーザのユーザプロファイルの形成に使用され、それは理想的にはユーザの財務状態、連絡先情報、健康情報および履歴情報についての総合的な情報を有する。ユーザプロファイルは、ユーザの名前、誕生日、年齢、現在および過去の住所、電話番号、電子メールアドレス、社会保障または政府の識別番号、雇用情報（現在および履歴）、収入、身長、体重、人種、銀行の口座番号、預金残高、ユーザ名、パスワード、教育情報、健康上のリスク、アレルギー、薬剤などを含むことが可能である。このリストは決して包括的ではない。ユーザプロファイルはまた、緊急時連絡先の名前および電話番号、家族の名前および関係、サービスプロバイダ連絡先情報および注記、勤務先連絡情報、ビジネス展望、ＣＲＭなどのようなユーザに直接関連しない情報もまた有することが可能である。ユーザプロファイルは、その情報へ選択された他のメタデータ、または格納された日付もまた格納可能である。

システムへのアクセスは、デスクトップまたはラップトップのような計算装置上で実行するソフトウェアを通して、またはタブレットもしくはスマートフォンのようなポータブル電子装置上で実行するアプリケーションを通してアプリケーションインタフェースにより提供可能である。また、システムはｗｅｂベースのアプリケーションインタフェースを通ってアクセス可能であり、そこでは全てのユーザの情報が、例えばクラウドベースのネットワーク内のセキュアサーバ設備内に安全に格納される。

１つの実施形態では、データストアの場所のうちの１つへのハッキングのリスクを最小化することによりセキュリティを強化するため、意図的に分断した少なくとも２つまたは３つの分離したデータストアの場所内に情報を格納可能である。データストアは、例えばフォームおよびドキュメントテンプレート、フィールド情報および他のフォーム特性を格納するドキュメントライブラリデータストア、例えばそれぞれの特定のユーザについてのフィールドおよびフィールド値を含む情報を格納する顧客の個人保管場所のデータストア、例えば（セキュリティ上の理由で他の情報と分離した）ユーザの識別情報およびカスタマオーダに関する情報を格納するユーザ識別情報データストア、およびかつて完成したフィールドおよび値に関して予め完成したフォームを格納する完成したドキュメントのデータストアに分割可能である。

直前に記載したように、情報がフォームの適切なフィールド内へ正確に取り込まれまたは捕捉されるように、情報が異なるカテゴリに分類されることはありうる。さらに後述するように、豊富な個人情報が盗まれる潜在的なリスクは情報が盗まれるのを防ぎ、それが盗まれた場合でも有用であるよう特殊化した専用暗号化および格納技術により軽減される。

フィールドマッピング
フォーム内のどのフィールドにどの情報が属するかを識別するのは、フォームの取込に関して最も困難なことの１つである。多くの情報フィールドがその特定のフィールド内に属する値を容易におよび直ちに識別する名前を収容するが、いくつかの名前は紛らわしく名付けられ、いくつかのフィールドは異なるフォーム間でわずかに異なる名前を持ち、いくつかのフィールドは同一のドキュメント内で同一の名前を持ち、いくつかのフィールドは同一のフィールドに関連する複数の値を持つ。

続くフィールドマッピング技術を動作させる、情報が入力されるべき少なくとも３つの主要な状況がある。第１の状況で、ドキュメントライブラリは標準ドキュメントテンプレートを格納し、それはユーザの作業領域内にコピーされ、オンデマンドで入力されることが可能である。このケースでは、ドキュメントライブラリは「Ｆｉｅｌｄｓ」テーブル内にそのドキュメントの記入可能なフィールドおよび可能なデフォルト値を格納するであろう。第２の状況で、フィールドおよびそれぞれのユーザに一意の値が空白のドキュメントに適用およびマッピングされる。この一意のユーザ情報のセットは、経時的に大規模な情報の保管場所になる。第３の状況で、値が完成したドキュメントに固定されるように、ドキュメントに割り当てられる実際のフィールドおよび値がユーザにより入力および保存される。これらの問題を解決するいくつかの技術を後述する。

第１の解決法は、ドキュメントのフィールドを調べることと「最も適合する」フィールド名に関連付けおよび推定することを含む。１つの実施形態では、これはフォームラベルとページ上のフィールドボックスを関連付けるウェブサイトフィールドコードの「ｆｏｒ」属性の使用により完成される。例えば、紛らわしい名前およびフィールドを「Ｆｉｒｓｔ Ｎａｍｅ」に対するラベルと関連付けが可能なように、不明瞭な名前の「ｂｏｘ００４５５ｘ」のフィールドボックスを「ｌａｂｅｌｆｏｒ＝「ｆｉｒｓｔｎａｍｅ」と暗号化してもよい。

ドキュメントまたはフォーム内に同一のまたは類似のフィールド名を持つ複数フィールドがある状況については、それぞれのフィールドが出現するドキュメントの欄を使用してそれぞれのフィールドの値が異なるべきかどうか確認可能である。従って、システムデータストアは、どの欄にあるかに基づき同一の名前があるフィールドを明確にすることが可能なように、それぞれのフィールドについてのデータストア内のカテゴリとして「ｆｉｅｌｄ ｓｅｃｔｉｏｎ」入力を格納可能である。

一部のケースで、フィールド名は完全に無作為で、それが他のフィールドまたは特定のフィールド値にどのようにマッピングするかに関して何も示さない。フィールド名を、コンピュータおよび特殊化した数字または文字の鍵コードで特定のコードを読む他のシステムに対しコード化してもよい。例えば、「Ｆｉｒｓｔ Ｎａｍｅ」フィールドを「ｆｎ００４５５８６」と名付けてもよい。ドキュメントライブラリ内に格納されたＰＤＦドキュメントについて、フィールドレコードに「ｃｏｍｍｏｎＦｉｅｌｄＮａｍｅ」と呼ばれる付加的な「補助」属性を追加可能である。ドキュメントが入力されるとき、うまく名付けていないフィールドを容易にマッピングされる何かに手動で変換可能である。この「Ｆｉｒｓｔ Ｎａｍｅ」の例で、システムは、ＦｉｅｌｄＮａｍｅレコードを「ｆｎ００４５５８６」として、「ｃｏｍｍｏｎＦｉｅｌｄＮａｍｅ」を「Ｆｉｒｓｔ Ｎａｍｅ」として記録可能である。ユーザがこのドキュメントを選択するとき、最新の技術は「ｃｏｍｍｏｎＦｉｅｌｄＮａｍｅ」を認識し、それを「Ｆｉｒｓｔ Ｎａｍｅ」に最も適合するユーザのフィールド名のうちの１つに容易にマッピングする。

ユーザが同一のフィールド名に関連する複数の値を持つ状況で、特定のフィールド内へどの値を入力するかユーザが選択可能なドロップダウンメニューまたは他の選択方法を提供するよう、システムを構成可能である。別の実施形態で、フィールドは直近で使用された値または最も頻繁に使用された値で取り込まれる。

別の実施形態では、異なるフォームは同一のユーザフィールド名を参照する異なる方法を有することが可能である。ドキュメントは１つの方法でフィールドを名付けることが可能であるが、他のドキュメントは同一のフィールドを他の方法で名付けることが可能である。例えば、第１のドキュメントは「Ｆｉｒｓｔ Ｎａｍｅ」と名付けられたフィールドを持つことができる一方で、第２のドキュメントは「ｆｎａｍｅ」と名付けられたフィールドを持ってもよく、さらに第３のドキュメントは「ｆｉｒｓｔｎａｍｅ」と名付けられたフィールドを持ち、これらの全ては同一のフィールドを指し、同一の値または内容を有するはずである。この関連を可能にするよう、システムデータストア内のユーザのＦｉｅｌｄＤｅｆａｕｌｔｓテーブルに、「ｕｓｅｒＦｉｅｌｄＣｏｌｌｅｃｔｉｏｎｓ」レコードが提供され、それは同義の種々のフィールド名をリストする。

例えば、経時的にそれぞれ同一の値を持つデータストア内に格納された複数のフィールドがある。例えば、これらの３つの「ｆｉｒｓｔｎａｍｅ」フィールドが全て「Ａｒｔｈｕｒ」の値を持つと仮定する。図２のフィールド比較ユニット１０６ｄにより実行されるバックグラウンドプロセスは、「Ａｒｔｈｕｒ」の値を持つ他のフィールドについてデータストアを周期的に調べ、それらのフィールドを重複として「ｕｓｅｒＦｉｅｌｄＣｏｌｌｅｃｔｉｏｎｓ」テーブル内で識別することが可能である。このテーブルは、それらの共通の内容に基づき同義の種々のフィールド名を捕捉する。これらのフィールドのいずれか１つがその後のフォームに遭遇するとき、適切な値の「Ａｒｔｈｕｒ」が使用される。

第２のアプローチで、システムは「ｕｓｅｒＦｉｅｌｄＣｏｌｌｅｃｔｉｏｎｓ」テーブルを一般的にグループ化したフィールド値で予めセット可能である。例えば、「ｆｉｒｓｔｎａｍｅ」と呼ばれるフィールドに最初に遭遇するとき、「ｆｉｒｓｔｎａｍｅ」および「ＦｉｒｓｔＮａｍｅ」がそのテーブル内に格納される。「ＦｉｒｓｔＮａｍｅ」と呼ばれるその後のフィールドに遭遇するとき、その値はすでに格納され、「ｕｓｅｒＦｉｅｌｄＣｏｌｌｅｃｔｉｏｎｓ」テーブルを通して容易に位置付けられるであろう。

１つの例では、一般的にラベル付けされたフィールド名、例えば「ｍｙＦｉｒｓｔＮａｍｅ」とラベル付けされたフィールド名および「ｃｕｓｔｏｍｅｒＦｉｒｓｔＮａｍｅ」とラベル付けされた（他のフォームでありそうな）他のフィールドがあるとき、問題が起こる。これらのフィールド名は同一の情報（ユーザのファーストネーム）に明らかに対応するので、「ｍｙＦｉｒｓｔＮａｍｅ」を「ｃｕｓｔｏｍｅｒＦｉｒｓｔＮａｍｅ」にマッピングするため、他のユーザからマッピングされた既存のフィールドを学習し、その後ユーザのフィールドとドキュメントのフィールドの間で推奨されるマッピングを割り当てるよう、機械学習分類ドキュメントを適用可能である。

識別情報の分離
盗難および誤用の可能性からユーザの情報を保護するため、システムはユーザの他の情報からユーザの識別可能な情報を分離する。例えばユーザの名前、社会保障番号、誕生日、雇用者識別情報などが、ユーザのクレジットカード番号、銀行口座、教育、評価などのようなユーザの他の情報から分離したデータストア内に格納される。識別可能な情報はまた、それぞれの識別情報フィールドがデータストア内のそれ自体の安全な区域に効果的に格納されるように、同一のユーザの他の識別可能な情報へのいずれの論理接続を伴うことなく格納される。ユーザ情報のそれぞれの項目を、さらに個別に暗号化し、その後、テーブルがそれ自体でユーザについてあらゆる有益な情報を提供不可能なように、テーブルのインデックス作成、編成または分類を伴うことなく他の情報とともに匿名でテーブル内に格納することが可能である。

暗号化された情報は鍵でのみ復号可能であり、任意選択的に一部のケースで、鍵が他の項目のロックを外すよう誤用されることができないように、鍵が情報のそれぞれの分離した項目に対し個別に生成される。鍵は分離したデータストア内に格納され、ユーザが正しいパスワードでログインしたときのみ取得可能である。よって、ユーザの識別情報を構成する情報を分離することによって、単にデータベースおよびその中にリストされたテーブルにアクセスすることで識別情報の盗み出しを達成するのに十分なユーザの情報を判断することは不可能である。１つの例として、それ自体で格納され（ユーザの名前のような）他の情報から切り離されたユーザの社会保障番号（ＳＳＮ）は、識別情報の盗み出しを長続きさせるのに有用でない。ＳＳＮがさらに認識不可能な一連の文字および数字に暗号化されると考えると、システムはデータストア内に格納された情報を保護する２つの高度に安全な方法を提供する。１つの実施形態では、情報を取得するのに３つの分離したデータストアの場所が使用され、それぞれの場所は異なるサーバを用いてネットワークへ接続可能であり、サーバは異なるファイアウォールの後方にあることが可能である。第１のデータストアを、ユーザのユーザ名およびパスワードを格納するよう構成可能である。ユーザ名およびパスワードの入力が成功した場合、秘密鍵が生成され、その後それが第２の場所に供給され、第２の場所はそれぞれのユーザが秘密鍵を格納するため単に使用される。第３の場所が実際の情報を保持可能で、情報の安全な区域を再び関連付けるように暗号化されたマッピングを通して読み出すためには、第２の場所からの秘密鍵でロックを外さなければならない。

自動ユーザプロファイル更新
このタイプの分離、すなわち前述のようにデータを複数の細片に分けることは、情報のそれぞれの細片に同様に起こる。言い換えれば、情報のそれぞれの細片は下位細片に分けることが可能であり、それぞれが一意の鍵で個々に暗号化され、および／または他の下位細片への論理接続なしに分離した場所に格納される。１つの実施形態では、ユーザからの特定の指示のなしに、あらゆる入力された情報をユーザプロファイル内に自動的に分類および格納するようシステムを構成可能である。また、ユーザの通常のアクティビティ中にユーザ情報が取得され続けるにつれ、新しく入力された情報は既存の情報を更新するよう作用するか、その後フォームで取り込むときにユーザが選択可能な同一の情報フィールドの値のリストに追加される。

ユーザの情報を、個人情報安全区域として知られるそれ自体のデータストアの場所、およびその場所の「ｃｕｓｔｏｍｅｒＦｉｅｌｄＤｅｆａｕｌｔｓ」と呼ばれるテーブル内に格納可能である。ｃｕｓｔｏｍｅｒＦｉｅｌｄＤｅｆａｕｌｔｓテーブルは、通常ユーザの最新の情報を有する。

ユーザ情報の入手
１つの実施形態では、付加的な関連する情報を得るため、既存のユーザプロファイルデータを分析可能である。付加的な関連する情報を、定収および通常の支出の予算を決定するのに財務データを分析することのような既存のデータの比較または計算の実行により、得ることが可能である。また、ユーザプロファイルの特定の面のより完全なイメージをユーザに提供するため、付加的な関連する情報を外部のソースから得ることが可能である。例えば、ユーザが車両年数、形式およびモデルを含む資産のリストをユーザのユーザプロファイルに入力すると、システムは外部のデータストアまたはサードパーティサービスから車両の推定価値を取得可能である。他の例では、ユーザが収集可能な芸術作品のタイトルを入力すると、システムは芸術家、作成年および推定価値のようなその芸術作品の付加的な情報を取得可能である。この情報を、品物の保険申込または損失の場合の請求書を記入するのに使用可能である。

ユーザ情報の分析
１つの実施形態では、図２のユーザアクティビティ収集ユニット１０６ｅは、システムの使用中（情報入力、フォーム記入などのような）ユーザアクティビティを監視し、ユーザのアクティビティおよび情報に基づき予め定められた説明コードを生成、収集および分離したデータストアの場所に格納する。コードは、ユーザの現在の生活のステータス、人口統計学上のプロファイル、好み、財務バランス、およびユーザの口座に関連付けられる他のパラメータに対応してもよいが、ユーザの特定の情報を収集、開示または漏洩しない。これらのコードをその後、サードパーティの製品の売り込みおよびサービスの提供のためそのユーザについて対象とするマーケティングおよび他の戦略を決定するのに使用可能であり、それはそれらの製品またはサービスへのユーザのニーズおよび希望によりよく効果的に照準する。コードにまた、フォームのタイプ、他の関連するフォームの使用などに関する因子に基づき、コードがユーザに適応する可能性に関する信頼値を提供可能である。

例えば、大学出願を完成中のユーザは、ユーザが大学に入学しようとしている可能性に関するコードを生成し、それがその後大学関連の製品またはサービスをユーザに売り込む機会を提供する。ユーザが大学出願および経済援助申込を完成すると、ユーザが大学に入学しようとしていることを示すコードに関する信頼値はより高く跳ね上がってもよい。これを、大学の宣伝のようなユーザの生活ステータスに照準した広告をグラフィカルユーザインタフェース内でユーザに表示するよう使用可能である。

取り込まれた情報のアーカイブ保管
ユーザがフォーム内に情報を取り込む毎に、システムはｃｕｓｔｏｍｅｒＦｉｅｌｄＣｏｎｔｅｎｔとして知られる特定のデータストアの場所のテーブル内にフォームの最終版への参照を保存可能である。特に、フォームはそれ全体で単一のデータストアの場所に格納されない。そうではなく、フォームへの参照またはレコードロケータが格納される。フォーム内に格納された情報は、ロックをかけることが可能であり、ユーザが特に予め完成したフォームにアクセスしフォーム自体を編集および新しい版を生成する場合を除いて、他のユーザ情報が更新されるときには更新されない。システム内のユーザのアクティビティの完成したアーカイブを生成するよう、格納された完成したフォームに時間および日付をスタンプ可能である。

家族情報およびグループプラン／企業プラン情報の共有
１つの実施形態では、ユーザの情報を、ユーザのプロファイルの一部が共有されることを望むだろう他の関連するグループと共有可能である。例えば、配偶者、子、両親、兄弟および姉妹および他の家族は、住所、電話番号、家族履歴などのような、項目のうちの１つが変更されるとさらに広く更新される同様の情報を共有可能である。これは家族のメンバ間で情報を繰り返し入力するのを避けることで利便性を提供し、共有される情報の包括的な更新を可能にし、家族のメンバがＦＡＦＳＡ（連邦学資援助無料申込）のような申込で協働することを可能にする。ＦＡＦＳＡ申込は、学生が完成する特定の欄と両親が完成する必要がある他の欄を有する。他の例は、大学に出願する子が、住所、両親の名、職業などのような他の兄弟姉妹が兄弟姉妹のユーザプロファイルにすでに入力した共有される家族情報にアクセス可能である。さらに家族が引っ越した場合、家族メンバの１人が更新した家の住所が、以前にリストされた同一の家庭住所をさらに持つ同一のグループ内の他の家族メンバにわたり更新され、または更新に提供される。同様に、企業の種々の従業員は、企業の体制または他の記入またはレポートを完成するため、協働可能である。他の例では、家族の１世代についての健康記録のデータベースを第２の世代に転送し、第２の世代に可能性がある遺伝的健康情報について情報を提供可能である。

家族または企業の共有オプションを効果的にするため、それぞれの家族／企業メンバからの情報をデータベースの分離した安全区域内に格納可能であり、それぞれのメンバが彼らの分離した情報のプライバシーを維持可能なように、データベースは、家族／企業メンバ間の共用情報の間のリンクを形成するであろう。

ＩＩＩ．電子フォームへの取込
格納されたフォームの選択
ユーザがフォームまたはドキュメントを完成する用意があるとき、ユーザはいくつかの方法のうちの１つを選択可能である。フォームまたはドキュメントがシステムサーバにおけるフォームデータベース内に格納されている場合、図９Ａおよび図９Ｂのｗｅｂベースのアプリケーションインタフェース９００の付加されたグラフィカルユーザインタフェースに示されるように、ユーザはドキュメントカテゴリ９０２または特定のドキュメント９０４のリストからフォームを選択可能である。また、ユーザは検索ツールを用いてフォームを検索、またはカテゴリ９０２を通してブラウズし、フォームのタイプ（財務、学業、健康管理など）に基づきフォームを見つけることが可能である。

アプリケーション拡張部
図５のブラウザ拡張ドロップダウンメニューのグラフィカルユーザインタフェースの添付された例示に示すように、１つの実施形態では、アプリケーションウィンドウ内に見ているフォームを取り込むよう迅速にアクセスするためのアプリケーション拡張部が提供される。拡張部をアイコン、メニューアイテム、補完またはアプリケーションメニューもしくは他のどこかの別の方法で表示可能であり、アイコンを選択すると、ユーザプロファイルからアプリケーションウィンドウ内に表示されたフィールドへ情報を取り込む選択肢があるウィンドウが開く。アプリケーションは、インターネットブラウザ、ワードプロセッサ、イメージビューア、スプレッドシートまたはプレゼンテーションソフトウェアであることが可能であるが、これらの例ならびに本明細書の全ての例および実施形態はこれらに限定されない。

セクションＩで前述したように、別の実施形態では、アプリケーション拡張部をまた、アプリケーションウィンドウ内に表示されているフォーム、ドキュメントまたはウェブページから情報を抽出または補完するのに使用可能である。この抽出された情報で、ユーザの個人情報データベースをアップロードしてもよい。

別の実施形態では、アプリケーション拡張部はまた、ＬｉｎｋｅｄＩｎ（登録商標）、Ｆａｃｅｂｏｏｋ（登録商標）またはＺｉｌｌｏｗ（登録商標）ウェブサイトのようなサードパーティウェブサイトを見ている間、ユーザが格納した連絡先、ＣＲＭおよび／またはシステムが認識したフォームフィールドに関する連絡先関連情報を表示、および修正を可能にするのに使用可能である。この実施形態の１つの例では、ユーザに、彼らのＬｉｎｋｅｄＩｎ（登録商標）の連絡先の１つを見ている間、その情報をＬｉｎｋｅｄＩｎ（登録商標）またはＬｉｎｋｅｄＩｎ（登録商標）の他のユーザと必ずしも共有することなく、彼らのパーソナルユーザデータベース内に戻る特別な連絡先ついての一意のおよびプライベートな情報を見る、変更するまたは直接追加することを可能にするポップアップまたはドロップダウンウィンドウが示される。基本的にユーザはその連絡先上でユーザの個人的注記でＬｉｎｋｅｄＩｎ情報を増加させ、個人的使用のため自分の情報データベース内にその情報を安全に格納している。他の例では、不動産ビジネスを運営しているとみなされたユーザに、Ｚｉｌｌｏｗ．ｃｏｍ（登録商標）の特定のリストを見る間ポップアップまたはドロップダウンウィンドウが示され、それは彼らがその特定の不動産物件についての一意のおよびプライベートな情報を見る、変更する、または彼らのパーソナルユーザデータベース内へ直接追加することを可能にする。これは不動産ビジネスユーザが、有益なビジネス情報（例えば特定の不動産物件の表示、詳細のリスト、スケジュールが表示されるクライアントのリスト）を収集することを可能にし、それは彼らが自身のビジネスをより効果的にするのを可能にする。

サードパーティアプリケーションの統合
サードパーティサービスプロバイダもまた、ｗｅｂベースのアプリケーションまたはポータブル電子装置上で実行するモバイルアプリケーションのようなそれら自体のアプリケーション内へのシステムへのアクセスを包含することが可能である。例えば教育機関が実施するウェブサイトは、入学申込をロードすると、ユーザがログインし、その後彼らの情報にアクセスしてウェブサイトを通して直接入学申込を取り込むことができるように、入学への申込のためシステムへのアクセスをそれらのアプリケーションへ統合することが可能である。また、インターネットショッピングウェブサイトは、ユーザがウェブサイトから商品またはサービスを調べて購入する準備ができたとき、支払画面上で彼らの情報を選択しその後取り込むようボタン、リンクまたは認証ダイアログがユーザに利用可能なように、システムデータベースへのアクセスを統合することが可能である。

サードパーティアプリケーションとの統合は、サードパーティサービスプロバイダがユーザの情報を見るまたは格納することができず、代わりにトランザクションが完了するとチェックアウト時にシステムデータベースからそれを要求し、その後それを削除するだけとなるように構成可能であるので、さらなるセキュリティをユーザに提供可能である。

アプリケーションを、スタンドアロンの製品またはｗｅｂベースの製品およびサービスとして提供可能である。１つの実施形態では、アプリケーションを、ポータブルドキュメントフォーマット（ＰＤＦ）記入アプリケーションとして提供可能であり、アプリケーションは情報をＰＤＦドキュメントに取り込むよう作動する。ＰＤＦ記入部は、ｗｅｂベースのアプリケーションであることが可能であり、または前述したようにブラウザ拡張部として統合可能である。アプリケーションはまた、オンラインで見出されたフォームおよびドキュメントを完成するよう設計されたｗｅｂベースのフォーム記入部として提供可能である。またシステムを、ユーザがフォームまたは他のドキュメントを完成するのを可能にするだろうスマートフォン、タブレットまたは他のポータブル電子装置上で実行するモバイルアプリケーションとして提供可能である。小さい表示画面およびタッチスクリーン装置を用いて情報を入力する困難さでは、ポータブル電子装置で情報を容易に取り込む能力が特に好都合である。例えば、買い物をするのに自身のモバイル装置を使用するユーザは、小さい画面上に彼らの連絡先情報および支払情報のすべてを入力するのがしばしば困難だと分かる（加えてそれを思い出す必要がある）。これらのｅコマースフォームフィールドを即座に完成する能力は、特にモバイルユーザに好都合である。他の例では、応急手当または救急処置室に来たユーザはいくつかのフォームを記入する必要がありえ、代わりにフォームにアクセスするためウェブサイトを提供し、本発明のシステムを使用してフォームフィールドを取り込み、フォームをオンラインで提出することが可能である。モバイルベースのアプリケーションは、スタンドアロンであることが可能であり、または他のモバイルアプリケーションまたは本来の装置のアプリケーション内へ統合することが可能である。例えば１つの実施形態では、ユーザが空白のフォームまたはドキュメントの写真を撮り、完成したドキュメントを送信する前にフォームフィールドを取り込むようシステムを使用するのが可能なように、システムをポータブル電子装置のカメラと統合可能である。

別の実施形態では、ユーザがサードパーティユーザプロファイル内のフィールドでフォームを見る必要なしに、システムからサードパーティユーザプロファイルへのユーザプロファイルデータの部分的または完全な転送を提供するよう、サードパーティアプリケーションはシステムおよびユーザプロファイルと統合可能である。例えば、ソーシャルメディアサービスまたはｅコマースサービスのようなサードパーティサービスに参加するユーザは、システム上で生成された彼らのユーザプロファイルをサードパーティアプリケーションおよび対応するサーバおよびデータベースに転送するよう単に要求することにより、ユーザプロファイルを完成するよう求められうる。ユーザは、ユーザプロファイルに対応するｗｅｂベースのフォームを見る必要なく、全ての彼らのユーザプロファイル情報をサードパーティユーザプロファイルに即座に転送する選択肢を選択する必要がありうるのみである。即座の転送は、サードパーティアプリケーションにフィールド名のリストをサーバに送信させ、サーバがその後データベーステーブルにアクセスしてユーザプロファイル内に格納された値またはマッチするフィールド名に対応する値を識別することにより完了可能である。マッチするフィールド値はその後、サードパーティのユーザプロファイルを完成するため、サードパーティアプリケーションサーバおよびデータベースに転送し戻される。

選択されたユーザプロファイル情報を、他のフォーム、データベース、装置または宛先へ自動的に転送するさらなる転送方法が提供可能であり、ユーザがフォームフィールドおよび内容を、それが記入されまたは他の場所へ転送されるとき、手動で見直す必要をなくすであろう。

フォーム完成標識
１つの実施形態では、ユーザにフォーム完成標識を提供可能であり、それはユーザプロファイル内の情報からいくつのフォームが記入可能であるかを示す。フォーム完成標識に基づきユーザがどのフォームが取り込むのに最も容易かを判断可能なように、フォーム完成標識を、ユーザが選択可能なフォームのリストと並んで表示可能である。標識は、ユーザプロファイル内に格納された情報から記入される形態のフィールドのパーセンテージを示すシンボル、色または単に数値でありうる。フォーム完成標識はリアルタイムで更新され、ユーザが自動的に取り込むのが最も容易でほとんど手動の入力がないフォームデータベースまたはオンラインｗｅｂフォームを選択するのを補助する。完成標識はまた、所定のカテゴリのいくつがマッピングされたか、または未記入のフィールドを完成するのにどれぐらいの作業が必要とされるかの指標も、ユーザに提供可能である。

手動の入力インタフェース
システムはそれについて情報を有するあらゆるフィールドを取り込むが、あるフィールドは値を持たないまたは複数の値を持つことがありえ、その場合フィールドは自動的に記入されない。この状況で、ユーザはフィールドを取り込むため、いくつかのアクションをとらなければならない。フォームフィールドを取り込む１つの実施形態を、音声、タッチ、ジェスチャまたは入力装置、または３つのいずれかの組み合わせにより補助可能である。音声およびタッチ入力は、フォーム内に入力されるあらゆる情報のあらゆる手動のタイピングの必要をなくす。計算装置上のマイクロホンを通して音声入力を利用可能であり、一方でタッチスクリーン、タッチパッド、画像取込装置または運動捕捉装置を通してタッチおよびジェスチャ入力が可能である。入力装置は、マウス、スタイラスまたはグラフィカルユーザインタフェース上で選択を可能にする計算装置と接続された他の周辺装置を含む。

１つの実施形態では、フィールドに対する値の手動の入力は、ユーザが発話、タッチまたは入力装置で選択する値の選択肢がある、ポップアップまたはドロップダウンメニューのような分離したウィンドウを表示することにより完成可能である。相互作用は、タッチスクリーン上のフィールドをタッチしてウィンドウを生成し、その後フィールド値のリストから所望の値の名前を発話するといった、１つまたは複数の分離した入力タイプを含むことが可能である。フォーム入力フィールドはまた、フォームの完成においてユーザを補助するよう、システムデータベースに関連するヒントまたは注記を持つウィンドウを表示可能である。１つの実施形態では、フィールド上のタッチ入力は音声により入力を開始し、一方で「タッチアンドホールド」入力が複数の利用可能な値を持つ分離したウィンドウの表示を開始する。

ユーザプロファイルにフィールドの値が欠けているときはいつでも、またはシステムが１つまたは複数の基準に基づき複数の利用可能な値から最も適合する値を選択するよう設計されたときでさえも、手動の入力の必要が生じる。値が存在しない場合、または自動的に記入された値をオーバーライドするため、ユーザに特定のフィールドに手動で値を入力するオプションを提供可能である。例えば、「食物アレルギー」とラベル付けされたフォームフィールドが、リストされるアレルギーのどの値を自動的に入力すべきか判断するのがシステムにとって特殊過ぎる場合のように、ユーザは彼らのユーザプロファイル内に複数の異なるアレルギー（すなわち卵、ハチおよびネコ）をリスト可能である。システムは他のユーザによる以前のユーザ入力からデータを使用して、「卵」が最もありうる候補だと判断することが可能である。しかし、その後ユーザに分離したウィンドウを生成するフィールドを選択するオプションが提供され、その後例えばユーザが蜂蜜で作られた食品にアレルギーがある場合、リストに「ハチ」または「蜂蜜」を追加することにより、選択を修正するようアレルギーのリストから選択する。ユーザがフィールド名「アレルギー」に対し格納されたフィールド値を持たない場合、カテゴリを選択して１つまたは複数のドリルダウンメニュー内に選択肢のリストを提供することを通して、または単に所望の値を発話し音声認識ソフトウェアに音声命令を解釈し適切な値を入力させることにより、ユーザに物理的なキーボードまたはタッチスクリーンキーボードインタフェースでフィールド値を手動で入力するよう促すことが可能である。ユーザはまた、フォームフィールドについて部分的なキーワードを発話し、それがその後部分的なキーワードを含む利用可能な値を持つ分離したウィンドウを表示する。キーワードを利用可能な関連する値と関連付けるよう、検索アルゴリズムを提供可能である。

前述のように、タッチおよび音声入力の１つの適用は、特定のフォームフィールドをタッチし、その後フィールド内に入力されるべき値を発話する能力であろう。代わりに、システムがフィールド名を識別できない場合、ユーザはフィールドの名前をまず発話することが可能であり、それがシステムにユーザプロファイルから発話されたフィールド名に対する値を取り込ませる。フィールド名に対するフィールド値が存在しない場合、ユーザはまたその後フィールドに対する値を発話可能である。入力された値が新しい値であれば、システムは将来の使用のためユーザのプロファイル内に値を格納する。１つの例では、自動車保険請求を記入中で車両識別番号（ＶＩＮ）を入力する必要があるユーザは、「ＶＩＮ」とラベル付けされたフィールドボックスをタッチし、その後「ＶＩＮ番号」または同様の命令を言うことが可能であり、その後システムデータベースは格納されたＶＩＮ番号をフィールドに取り込む。別の実施形態では、１つのフィールド内に取り込む値の選択が、関連するフィールド内の値も取り込み可能である。例えば、ｅコマースの勘定段階中、オンライン業者はユーザに、そのような名前を持つフィールドを表示することによりクレジットカードを入力するよう促す。ユーザは彼らのモバイルタッチ装置上でフィールドをタッチし、「Ｃｈａｓｅ Ｖｉｓａ」の単語を発話し、ユーザのＣｈａｓｅ Ｖｉｓａカード番号、そのカード上の名前、カード有効期限およびカードセキュリティコード（ＣＳＶ）が全て勘定フォーム上の関連したフィールド内へ記入される。ユーザの利点は、あらゆるオンライン業者にいずれの個人のクレジットカード番号も格納する必要がなく、それにもかかわらず迅速で安全なショッピングの勘定を経験可能であることである。また、ユーザのクレジットカードが失効、交換または更新されたとき、カードの変更はシステムデータベースの１つの場所に安全に全て格納されているので、ユーザはそれらを更新するためだけにそれぞれの業者サイトを訪問するのを覚えておく必要がない。

別の実施形態では、フィールドが複数の利用可能な値を持つ場合、ユーザはフィールド名をタッチまたは発話し、その後ドロップダウンメニューなどに表示された値のリストのうちの１つをタッチ、発話またはマウス入力で選択可能である。同様に、複数のフィールドが同一の名前を有するがフォームの異なる欄にある場合、所望の特定のフィールドに対する値を選択するため、ユーザは欄の名前、その後フィールドの名前を発話可能である。付加的な機能は、フォームフィールドをタッチまたは発話し、その後キーワードを用いて値を検索する能力を含む。

ジェスチャ、タッチおよび音声入力に加え、方向移動および速度を検出可能なジャイロスコープまたは加速度計で構成された装置内の特定のタイプの動きを通してフィールド値の手動入力もまた可能である。１つの実施形態では、ユーザ・インタフェースに特定のフィールドを見つけまたは取り込ませるため、ユーザは（スマートフォンまたはタブレットのような）装置を振ることが可能である。例えば、ユーザは空白のフォームを取り込むのに装置を振ることが可能であり、垂直傾斜のようなより具体的なジェスチャが、特定のフィールド名を見出し、ウィンドウ、および（クレジットカードフィールド名およびユーザが電子取引のために選択可能な異なるクレジットカードのリストのような）フィールド名内に取り込むフィールド値のいくつかの選択肢をユーザに提供する。

別の実施形態では、フォーム全体またはフォーム内の１つまたは複数のフィールドがシステム内に完全にマッピングおよび／または格納されていなかった場合、その後ユーザはそれぞれのマッピングされていなかったフィールド名をタッチまたは発話し、その後カテゴリ、下位カテゴリ、および特定のカテゴリデータベースフィールドをタッチまたは発話して、このフォームフィールドをデータベースフィールドへ関連付けることが可能である。システムはまた、機械知能アルゴリズムを用いてフォームフィールドの複数ユーザのマッピングを収集してデータベースフィールドに関連付け、その後関連付けられたフィールドマッピングをフォームと共にフォームデータベース内に格納し、それによってシステムの全てのユーザが使用する正確にマッピングされた新しいフォームを提供可能である。この実施形態は、全てのシステムユーザの利点のために、システムユーザが独立して現在システム内にない新しいフォームを追加およびマッピングすることを可能にする。また、それは、全てのシステムユーザの利点のために、システムユーザが独立してｗｅｂフォームフィールドを、まだそれらのフィールドをシステム内でマッピング（関連付け）させていないｗｅｂフォームについて、データベースカテゴリフィールドにマッピングすることを可能にする。

修正の格納
１つの実施形態では、システムがフィールドを取り込んだ後にユーザが特定のフィールドに対するフィールド値を手動で変更する場合、システムは変更された値を示し、新しく入力された値をシステムデータベース、望ましくはユーザプロファイルの情報安全区域内へ格納する。従ってユーザは、情報がフォーム内に入力される間、彼らのプロファイルを自動的に更新可能である。

方法および適用
システムおよび方法についていくつかの適用を前述したが、システムおよび方法について適用することはそれらに限定されると考えるべきではない。システムおよび方法を、さまざまなフォームフィールドを有する、かなりの量の情報を必要とする、または類似または紛らわしい名前およびフィールド識別子を有する複雑なフォームおよびドキュメントの完成に特に適用してもよい。大学出願、ローン申込、家族の法律問題に関する収入支出申告、健康管理フォームおよびスモールビジネスオーナにおよび彼らによって必要とされる多くのフォームは、本明細書に記載された例示的なシステムの使用により、時間の節約および情報の正確性にかなりの改善をもたら可能性がある（フラストレーションを低減するまたは重複性を減少させることは言うまでもない）適用である。

電子フォームを取得、分類および取り込む方法の１つの実施形態が、図１２のフローチャートで示される。第１のステップ２０２で、情報が、既存のフォーム、サードパーティのＡＰＩなどのような１つまたは複数の情報ソースから取得される。その後ステップ２０４で情報は、情報が属する少なくとも１つのフィールドを決定し、その情報を少なくとも１つのフィールドに関連付けるため分類される。その後ステップ２０６で、複数の関連付けられた情報がユーザプロファイル内へ集められ、１つまたは複数のデータベース内へ安全に格納される。ステップ２０８で、ユーザがクライアントインタフェースのうちの１つを通してフォームを完成するよう要求すると、ユーザプロファイル内の情報がフォーム上のフォームフィールドとマッチングされ、情報がフォーム上に取り込まれる。ステップ２１０で、ユーザがいずれかのフォームフィールド内へ値を手動で入力し、これらの値が彼らのセキュアデータベースに現在格納されたユーザの情報と異なる場合、その後これらの新しい値がユーザのセキュアデータベース内に保存される。ユーザプロファイルを、フィールドのデフォルトまたは一次的な値として新しい値を反映するよう任意選択的に更新可能である。

ＩＶ．コンピュータで実行される実施形態
図１３は、本発明の方法論を実行可能な実施形態のコンピュータ／サーバシステム１３００の実施形態を示すブロック図である。当業者に公知のように、システム１３００は、命令を実行するよう作動するプロセッサ１３０２およびメモリ１３０３を含むコンピュータ／サーバプラットフォーム１３０１を有する。本明細書で使用される「コンピュータ可読記憶媒体」の語は、プロセッサ１３０２に実行のための命令を提供するのに関わるディスクまたは半導体メモリのようなあらゆる有形の媒体をいう。また、コンピュータプラットフォーム１３０１は、キーボード、マウス、タッチ装置または言語命令のような複数の入力装置１３０４からの入力を受信する。コンピュータプラットフォーム１３０１をまた、ポータブルハードドライブ、光学媒体（ＣＤまたはＤＶＤ）、ディスク媒体またはコンピュータが実行可能コードを読み取り可能なあらゆる他の有形の媒体のような着脱可能な記憶装置１３０５に接続することが可能である。コンピュータプラットフォームはさらに、インターネットまたはローカル、公衆またはプライベートネットワークの他の構成要素に接続するネットワークリソース１３０６に接続することが可能である。ネットワークリソース１３０６は、ネットワーク１３０７上の遠隔位置から命令および情報をコンピュータプラットフォームへ提供可能である。ネットワークリソース１３０６への接続は、８０２．１１規格、Ｂｌｕｅｔｏｏｔｈ（登録商標）またはセルラープロトコルのようなワイヤレスプロトコルによる、またはケーブルまたはファイバーオプティックスのような物理的伝送媒体によることが可能である。ネットワークリソースは、コンピュータプラットフォーム１３０１から分離した場所で情報および実行可能な命令を格納する記憶装置を有することが可能である。コンピュータはディスプレイ１３０８と相互作用してユーザに情報を出力、ならびにユーザからの追加の命令および入力を要求する。従ってディスプレイ１３０８は、ユーザと相互作用する入力装置１３０４として機能することが可能である。

Ｖ．付加的な機能
本明細書中に開示される特定の実施形態は、特にクライアントのエンドポイント保護を含むデータ、認証情報および暗号化鍵の安全な格納および管理を行う方法およびシステムを提供する。この記載を読むと、記載された実施形態を種々の代替的な実施で実行する方法が明らかになる。さらに、種々の実施形態が本明細書に記載されるが、これらの実施形態は例として示されたのみであり、限定ではないことが理解される。そのように、種々の代替的な実施形態のこの詳細な記載は、添付の請求項の範囲を限定するものと解釈されるべきではない。

同時係属中の米国特許出願シリアル番号第１４／８６３，２９４号（’２９４出願）の開示は、参照により全体を記載したように本明細書に組み込まれる。’２９４出願は、その中に記載のように、データの断片化、個別の暗号化および分散を含む安全な高速のデータ格納、アクセス、復旧および伝送システムおよび方法を記載する。例えば’２９４出願に記載のように、例えば種々のフィールドが論理的に関連しないように、まず医療記録内のデータを分離可能である。その後分離されたフィールドを、下位フィールドまたは部分（断片）に分解可能である。その後下位フィールドの内容を傍受またはアクセスしようとしていた場合でもそれらの内容を容易に判断できないように、これらの下位フィールドを難読化することが可能である。その後これらの下位フィールドを、例えばそれぞれの下位フィールドまたは断片について異なる暗号化鍵を用いて個々に暗号化可能である。その後個々に暗号化された下位フィールドを、「破片化」し、異なる記憶装置または場所に格納可能である。

図１４は’２９４出願の図１の複製であり、記載されたプロセスが実行可能であるシステム例を示す。しかし図１４を参照して記載のように、クライアント装置またはエンドポイント１１０上で開始された命令または要求に応え、プロセスが通常セキュアプラットフォーム１２０で起こる。セキュアプラットフォーム１２０はその後、暗号化された断片を種々の記憶装置または場所１４０〜１７０に格納する。場所１４０はローカル、または装置１４０にローカル接続されていることが可能であるが、’２９４出願に記載されたプロセスは、エンドポイント１１０からプラットフォーム１２０へのリンクを必ずしも取り扱わない。

同時係属中の米国特許出願シリアル番号第１４／９７０，４６６号（’４６６出願）の開示は参照により全体を記載し、’２９４出願のプロセスを通った回折されたデータ回復システムおよび方法を説明したように本明細書に組み込まれる。図１５は’４６６出願の図１の複製であり、その中に記載された回折されたデータ回復を実行するシステムを示す。図１５を参照して記載のように、回折されたデータ回復は、ローカル、またはエンドポイント１１０にローカル接続されている記憶装置または場所１４０を含むことができるが、その中に記載されたプロセスは通常、エンドポイント１１０とサーバ１２０および１８０の間にリンクを適用しない。

米国仮特許出願シリアル番号第６２／２８１，０９７号（’０９７出願）（現在は失効）の開示は、参照により全体を記載したように本明細書に組み込まれる。’０９７出願は、認証情報および暗号化鍵の安全な格納および管理システムおよび方法を記載する。図１６は’０９７出願の図１の複製であり、その中に記載されたプロセスが実行可能であるシステムを示す。図１６を参照して記載のように、認証情報および暗号化鍵の安全な格納および管理は、ローカル、またはエンドポイント１１０にローカル接続されている記憶装置または場所１４０を含むことができるが、その中に記載されたプロセスは通常、エンドポイント１１０とサーバ１２０および１８０の間にリンクを適用しない。

本明細書に記載されたシステムおよび方法で、図１４〜図１６に示されるような’２９４出願、’４６６出願および’０９７出願に記載されたプロセスを、先端、すなわちクライアントのエンドポイント１１０において実行可能である。例えば、添付に記載のように、データをローカル、またはローカル接続されている記憶装置１４０の異なる部分に保存および取り出し可能なように、またはデータが複数の記憶装置１４０〜１７０に保存および格納可能なように、アプリケーションを装置１１０にロード可能である。よって、装置１１０のユーザがドキュメント、ビデオ、写真などを作成する場合、ユーザはドキュメントまたはファイルを格納するようアプリケーションを呼び出すことが可能である。これは断片を分散した方法で、記憶装置１４０内の異なる場所に、または前述および例えば’２９４出願に記載のようにメモリ１４０〜１７０上の異なる場所に格納する前述または添付に記載の全てのステップの実行を含みうる。同様に、’４６６出願に記載のようにアプリケーションはデータまたはファイルの回折取出を実行可能であり、’０９７出願に記載のように認証情報および暗号化鍵の管理を強化可能である。

よって、データが複数の記憶装置に保存されるとき、そのデータのそれらの装置への伝送は、プロセスが格納のための伝送前に全ての断片を分離して暗号化した事実によっても保護される。言い換えれば、データエレメントは全て、それらが送信される前に装置において断片化および保護される。この主要な利点は、通信チャネルを保護する必要がなく、通常の「オープン」接続が使用可能であることである。例えば、低速で高価なＴＬＳ保護ブラウザ伝送を使用する代わりに、より速い非暗号化チャネルを使用してもよい。データパケットは、保護された断片を包含する。これはブラウザベースのみでなく、全てのタイプの伝送に適用し、無線、ＦＴＰ、ブルートゥース（登録商標）などであることが可能である。

ユーザが図１４〜図１６に示されるような彼らの装置１１０上のドキュメントまたはファイルにいるとき、彼らが単純にボタン、アイコンなどを押すことができるように、アプリケーションを、関連したアプリケーションまたはｗｅｂブラウザ内のツールバーまたはドロップダウンメニュー内のボタンとして表示可能であり、これによってドキュメントを格納可能である。ドキュメントまたはファイルをその後、前述および’２９４出願、’４６６出願および／または’０９７出願に記載のプロセスを用いて格納されたことを示す方法で装置１１０上に示すことが可能である。ユーザがドキュメントまたはファイルに再度アクセスするとき、前述および’２９４出願、’４６６出願および／または’０９７出願に記載の取出プロセスを自動的に実行可能である。ある実施形態で、ユーザはまた、断片の全てまたはいくつかが格納される場所に関して種々の分散の好みを選択可能である。

他の実施形態では、例えばファイル上の右クリックを、記載された格納プロセスの選択に使用可能である。さらに他の実施形態で、アプリケーションは、そのようなプロセスを用いてファイルを格納すべきであると自動的に判断可能である。さらに他の実施形態で、そのようなプロセスを使用するよう、全てのファイル、特定のファイル、特定のタイプのファイルなどに対しデフォルトを設定可能である。

しばしば、図１４〜図１６に示される装置１１０のユーザは、装置１１０上で生成されたファイルのうち少なくともいくつかを格納するため、しばしばクラウドストレージと呼ばれるいくつかの形態の遠隔記憶装置を最終的に使用したいと思う。そのようなクラウドストレージサービスに関連するサーバ（１つまたは複数）上で実行するアプリケーション（１つまたは複数）を、例えば’２９４出願に記載されたのと同様の方法で、’２９４出願、’４６６出願および／または’０９７出願に記載されたプロセスを実行するよう構成可能である。しかし前述のように、装置１１０とそのようなサーバの間のリンクは必ずしも安全ではないであろう。しかし、本明細書に記載されたように、データをクラウドまたは中間エンドポイントに転送する前に記載されたプロセスを内容にまずローカルで実行することが可能である。それを例えばクラウドに最終的にする前に、多数の中間「エンドポイント」がありうる。クラウドへの単一のクライアントは、ただ１つのトポロジである。例えば、伝送前のデータを安全にするため、それぞれが記載されたシステムおよび方法を用いて全てがそれぞれ互いに通信するノードのネットワークがありうる。その後断片を、クラウドサービス上に分散して格納可能である。よって、データが移送の際に遮断された場合でも、それは使い物にならないであろう。

ある実施形態で、ユーザがクラウドストレージサービスにデータを格納または取り出すよう試みるとき、アプリケーションが自動的に記載されたプロセスを実行するように、アプリケーションを構成可能である。また、ドキュメントまたはファイルが停止、すなわち特定の時間にわたりドキュメントまたはファイルと相互作用がないことが検出され、その後記載されたプロセスが自動的に実行されてドキュメントを保護するように、アプリケーションを構成可能である。その後ユーザがドキュメントまたはファイルに再接続するとき、そのドキュメントまたはファイルへのアクセスを可能にする適切なプロセスを実行可能である。

ある実施形態で、記載されたプロセスを例えばファイル上でローカルに実行し、その後ファイルが例えばクラウドおよび／または中間装置へ転送されるときに再度実行可能である。

ある実施形態で、記載されたプロセスを用いて格納されたドキュメントの共有および共同作成が、例えば’０９７出願に記載された認証および認証情報管理プロセスを用いて可能にできる。よって、特定の個人がアクセスを許可されることが可能であり、その後それが例えばそれらの個人に割り当てられた認証情報に基づき生成されたセキュア鍵を用いて管理されるであろう。

ローカルの記憶装置がＵＳＢドライブのような安全でない記憶装置であるとき、記載されたプロセスから他の重要な利点が効力を生じる。そのようなケースでは、データが邪悪な個人または機関にアクセスされた場合でも、記載されたプロセスを用いてデータを装置に格納することを確実にすることが可能であり、データは使用できない。ある実施形態で、ローカルのレベルで記載されたプロセスを実行するよう構成されたローカルのアプリケーションは、そのようなローカルの記憶装置、例えば、ＵＳＢ記憶装置上にあることが可能であることに注目すべきである。

ある実施形態で、ローカルのアプリケーションをまた、電子メールの添付物の保護を提供するよう構成可能である。添付のドキュメントは十分な知識があるあらゆるハッカーが傍受および読取可能なので、電子メールによる添付物の送信は危険である。本明細書に記載されたプロセスは、そのような添付物に対して、それらを意図された受信者以外の誰からも読まれないよう保護するような方法で実行可能である。一般的にローカルのアプリケーションは、電子メールの往来または電子メール自体の本体の暗号化と相互作用しない。そうではなく、ローカルのアプリケーションでの添付物の送信者が、彼らが添付するよう意図したドキュメントに記載されたプロセスを実行（それによってそれをパブリッククラウドサーバに送信）可能である。その後アプリケーションは、そのドキュメントリンクへのアクセスリンクを生成することが可能である。その後アクセスリンクを、実際のドキュメントの代わりに受信者に電子メールで送ることが可能である。受信者はその後、彼らが受信したアクセスリンクをクリックし、本来のドキュメントをダウンロードおよび復号可能である。これはもちろん、受信者の装置が記載されたプロセスにより添付物を取り込むのを可能にするそのようなローカルのアプリケーションを、受信者もまた有することを必要としうる。

他の実施形態では、前述のようなローカルのアプリケーションはまた、デジタル媒体（ドキュメント、本、オーディオ、ビデオなど）のフレームまたは区間を制御して連続して「見る」または「再生する」ことを可能にできる。そのような実施形態で、図１４〜図１６に示されるような装置１１０の許可および認証された加入者、またはユーザは、媒体が表示され（または実行され）るとき、彼らに送信された分離した連続的なフレームまたは区間を取り出して見ることができるだけである。また、加入者が次のフレームまたは区間に進んだ後、前に実行されたフレームまたは区間は、記載されたプロセスを用いて自動的に再格納するか永久に削除するかされる。従って、いずれの１つのインスタンスでも加入者の消費のためにデジタル媒体の最小の量のみが復号および組み立てられ、それによって侵害または許可されない消費を最小化する。これを任意選択的に、送信ソースから認証および許可された加入者に、送信ソースへ戻る消費フィードバックメカニズムを通してさらに送信を許可された連続的なフレームまたは区間の量も、また制限するよう拡張可能である。その価値は、消費者から最機密データまで全てのタイプのデジタル媒体をより安全に分配することである。

よって、伝送前に、そのようなデジタル媒体を自己完結型区画またはフレームに分割し、その後それらの区画またはフレームのそれぞれの断片化／暗号化／分散の記載されたプロセスが、図１４〜図１６に示される先端の装置１１０への伝送前に適用される。取り出し後、それぞれの区画またはフレームを、区画またはフレームを作り上げる下層の断片を再構成する連続的技術で一度に送信可能である。

’０９７出願の図４で記したように、本明細書で図１７として再製したのは、図１４〜図１６に示されるクライアント装置１１０を実行するのに使用可能な、種々の実施形態による有線または無線システム５５０を示すブロック図である。従って、このシステム５５０はここでは詳細に記載しない。

ＶＩ．鍵交換方法
（ＩｏＴ装置のような）新しい装置がネットワークに追加されるとき、その装置を認証する方法が必要である。本開示の種々の態様は、この動作を容易にするための装置の組込み鍵交換プロセスを含む任意の数の鍵交換方法を統合した方法を提供する。この機能は、例えば２つの装置間のデータストリーミングの場合、それらの装置の間の認証された通信を可能にする。その２つの装置間に通信が確立されると、性能の必要条件に基づき、および幾つもの条件（例えばデータセキュリティ脅威レベルだがそれに限定されない）に応え鍵交換方法および交換の頻度を動的に変更してもよい。暗号化エンジンは動的に、プライベート／パブリック交換を含む他の鍵交換解決法（例えば装置間のＴＬＳで使用されるＤｉｆｆｉｅ−Ｈｅｌｌｍａｎプロトコルだがそれに限定されない）と相互運用または層状運用してもよい。与えられたデータのセットに対するセキュア鍵の使用および鍵ローテーション率の最大化により、より高いレベルのセキュリティを得てもよい。

図１８は、本開示の種々の態様による鍵交換の方法１８００を示すフローチャートである。図１８を参照すると、ブロック１８１０で、現在の暗号化アルゴリズムパラメータおよびシードに基づき、それぞれの装置、例えば、第１の装置および第２の装置が共有鍵を確立してもよい。当業者は、本開示の範囲から逸脱することなく３つ以上の装置を使用してもよいことを理解するだろう。

ブロック１８１５で第１の装置上のデータセットを、共有鍵を用いて暗号化してもよく、ブロック１８２０で第１の装置はその暗号化されたデータを第２の装置へ送信してもよい。ブロック１８２５で第２の装置は、共有鍵を用いてデータセットを復号してもよい。ブロック１８３０で、鍵が再生成されるべきどうかを示す鍵再生成基準を決定してもよい。ブロック１８３５で、鍵再生成基準をそれぞれのデータセットについて評価してもよい。ブロック１８４０で、鍵再生成基準を満たすかどうか判断してもよい。鍵再生成基準が満たされないという判断（１８４０−Ｎ）に応え、ブロック１８４５で鍵が再生成されるべきときを示す状況を、ブロック１８４０で鍵再生成基準を満たすまで監視してもよい。鍵再生成基準が満たされるという判断（１８４０−Ｙ）に応え、ブロック１８５０で次の鍵のための新しい暗号化アルゴリズムパラメータを生成してもよく、ブロック１８１０で方法を続けてもよい。鍵再生成基準は、利用可能な暗号化アルゴリズムおよびその暗号化アルゴリズムについての特定のパラメータを識別してもよい。

ＶＩＩ．暗号化されたデータ伝送
本開示の種々の態様によると、暗号化されたデータを、ストリーム、ファイルシステムおよび／またはクラウドを含むがそれらに限定されない同時に複数のクライアントの送り先を通して一意の暗号化で送信してもよい。暗号化されたデータを、ビデオプレーヤーに復号されたストリームフォーマット、またはファイルシステムまたはクラウド上に安全に格納された断片のセットのような任意の数の送り先に移動させてもよい。暗号化される項目は、ファイル（例えば、Ｗｏｒｄドキュメント、写真ファイル、仮想マシンファイル、など）、鍵値のペア（例えばＪＳＯＮのような単純な文字列、またはフォームデータ、アプリケーションの設定および好みを格納するのに適切な他のフォーマット）およびストリーム（例えば、ビデオまたはデータフィード）を含むがそれらに限定されない任意の数のデータフォーマットにすることが可能である。

本開示の種々の態様によると、それぞれのオブジェクトを、それぞれのオブジェクトの総伝送時間、Ｔの減少を可能にするより小さい断片に分解してもよく、一部のケースで従来可能なよりも８〜１５倍まで速い伝送時間を可能にする。オブジェクトの断片を一回のみ暗号化し、一方でそれぞれのクライアントについて一意の鍵を使用することによりセキュリティを増してもよい。このアプローチは、暗号化されたデータを複数クライアントの送り先に送信中であっても性能上の利点を提供しうる。それぞれの送り先は、データにアクセスするため一意の復号鍵を有してもよい。複数の送り先への複数のセキュア出力ストリームを生成し、一方でハードウェアリソース要求を最小化してもよい。計算装置間のデータの断片化、暗号化および伝達は、待ち時間の短さと完全なデータ暗号化を達成可能である。本開示の種々の態様によると、アプローチを、複数のクライアントがそれぞれのクライアント間で一意の秘密鍵を保持し、それぞれの意図されるクライアントについてマニフェストを異なるように暗号化するのを補助するよう調整してもよい。

図１９は、本開示の種々の態様による暗号化されたデータの伝送シーケンス１９００を示すシーケンス図である。図１９を参照すると、ブロック１９１０で、それぞれのクライアント１９０２、１９０３上で実行するクライアントソフトウェアはサーバ１９０１と通信し、鍵交換プロセスを開始する。ブロック１９１５で、サーバ１９０１は、カメラ、ビデオ、および／またはオーディオセンサを含むがそれらに限定されないファイルまたはデータセンサでありうるソースから、データのブロック、例えばビデオストリームの１つのフレーム、オーディオのサンプルなどを読み込む。ブロック１９２０で、サーバ１９０１はデータを分解してデータ断片を作成する。ブロック１９２５で、サーバはクライアント１９０２、１９０３のそれぞれのマニフェストを生成し、それは他のデータの中でデータ断片のそれぞれについての一意の暗号化鍵を含む。ブロック１９３０で、サーバ１９０１は、それぞれのクライアント１９０２、１９０３からの鍵交換情報を使用し、それぞれのクライアント１９０２、１９０３について一意の秘密鍵を作成する。ブロック１９３５で、サーバ１９０１は、それぞれのクライアント１９０２、１９０３についての一意の秘密鍵を用いてマニフェストを暗号化する。

ブロック１９４０で、サーバ１９０１は暗号化されたマニフェストをクライアント１９０２、１９０３のそれぞれに送信する。異なるデータをそれぞれのクライアント１９０２、１９０３に送信してもよく、従ってサーバ１９０１により異なるマニフェストを生成しクライアント１９０２、１９０３のそれぞれに送信してもよいことを、当業者は理解するだろう。ブロック１９４５でサーバ１９０１はデータ断片を暗号化し、暗号化されたデータ断片を意図されたクライアント１９０２、１９０３に送信する。ブロック１９５０で、クライアント１９０２、１９０３上で実行するクライアントソフトウェアは、マニフェストの受信を待ち、一意の秘密鍵を用いてマニフェストを復号する。ブロック１９５５で、それぞれのクライアント１９０２、１９０３は、マニフェストの受信承認をサーバ１９０１へ応答する。ブロック１９６０でそれぞれのクライアント１９０２、１９０３は、暗号化されたデータ断片を待ち、マニフェスト内に含まれるデータを用いてそれぞれのデータ断片を復号する。ブロック１９６５で、それぞれのクライアント１９０２、１９０３は、次のマニフェストについての秘密鍵シードをサーバ１９０１へ送信する。

図１９のシーケンスを、クライアントから読み込まれたデータのそれぞれのブロックについて繰り返してもよい。データ断片を、クライアントがどんな順番で受信してもよく、正しい順番に並び直され処理される。ブロック１９２０での全ての開始時、サーバはデータの次のブロックについてシーケンスを繰り返してもよい。データのそれぞれのブロックについて、クライアントは対応するマニフェストの受信を待つ。サーバがクライアントからマニフェスト受信承認応答を受信しない場合、サーバは、応答が受信されるまで、またはタイムアウト間隔が満了するまでデータの次のブロックを保留する。クライアントが不完全または不正確なマニフェストを受信する場合、サーバに新しい秘密鍵で暗号化された現在のマニフェストを再送するよう通知してもよい。クライアントが不完全または不正確なデータ断片を受信する場合、サーバに現在のデータのブロックを再送するよう通知してもよい。

ＶＩＩＩ．データ暗号化の速度
本開示の種々の態様によると、プリプロセッサは、断片化および暗号化プロセスの前に、大規模なファイルを小さい細片に予めスライスまたは分割してもよい。コンパニオンポストプロセッサが、復号およびデフラグメンテーションの後のファイルを再結合してもよい。データオブジェクトをより小さい断片に分解し、それらの個々の断片を複数のプロセッサスレッドにわたり暗号化することにより、鍵のサイズを減少するまたはそうでなければセキュリティレベルで妥協することなく、速度上の利点（例えば５倍〜１５倍）を得られうる。「スライシング」、すなわち断片化および暗号化の前に大規模なファイルを小さい細片に分割し、デフラグメンテーションおよび復号後にそれらを再結合することは、性能を上げることが可能で、非常に大規模なデータオブジェクトを限定されたメモリを有する装置上で処理することを可能にする。

図２０Ａは、本開示の種々の態様による、暗号化速度を上げるためデータを予めスライスする方法２０００を示すフローチャートである。図２０Ａを参照すると、ブロック２０１０でデータスライシング基準を決定してもよい。ブロック２０１５で、決定されたスライシング基準に基づきスライシングについてデータオブジェクトを評価してもよい。ブロック２０２０で、データオブジェクトがスライス可能かどうか判断してもよい。データオブジェクトがスライス可能であるという判断（２０２０−Ｙ）に応え、ブロック２０２５でサーバは、データオブジェクトをデータの小さい細片に分割または「スライス」してもよく、ブロック２０３０でそれぞれのデータスライスを暗号化送信してもよい。ブロック２０３５で、サーバはそれぞれのデータスライスをデータ断片に分解してもよく、データ断片を暗号化してもよい。データを、１つまたは複数の格納場所での格納のため分離および分散してもよい。

図２０Ｂは、本開示の種々の態様によるデータファイルの再結合方法２０５０を示すフローチャートである。図２０Ｂを参照すると、ブロック２０６０で、暗号化されたデータ断片を復号してもよい。ブロック２０６５で、復号されたデータ断片をデフラグメンテーションし、データスライスに再結合してもよい。ブロック２０７０で、スライスをデータオブジェクトに再結合してもよい。

ＩＸ．暗号化鍵の管理
本開示の種々の態様によると、システムは鍵をローカルのオペレーティングシステム内にある鍵ストアに分配してもよい。一部のケースで、例えば、ネットワークの機能停止の場合、装置はリモートユーザおよび鍵または同様のライセンスサービスにアクセスすることが不可能かもしれない。リモートサービスを、ログイン時にユーザ名およびパスワードのようなユーザのライセンス認証情報の確認に使用してもよい。リモートサービスが利用不可能なケースでは、クライアントソフトウェアは、ローカルの装置上の暗号化鍵ストアにアクセスすることによりローカルでユーザ認証情報を有効にしてもよい。システムは、ネットワーク機能停止に対する復元性のためのバックアップとしてこのローカルの鍵ストアを取り込み、管理してもよい。

システムは、その分野の機能の全ての予測される状態を含む鍵管理（ＫＭ）ソフトウェアを供給してもよい。しかし、鍵管理サーバへの通信が失われたときは、鍵管理サーバがダウンしたからではなく、ネットワーク機能停止またはいくつかの他の接続問題の結果としてリモート装置がそれに接続できないからである。システムクライアントソフトウェアがラップトップまたは他のネットワークが可能な計算装置のような装置上で実行していて、鍵管理サーバへの接続が失われた仮定を考えると、クライアントソフトウェアはその装置上でデータの暗号化／復号を続ける。クライアントソフトウェアは、リモート鍵管理サーバが失われたケースで、バックアップとして作動中の装置上にローカルの鍵ストアを生成する。ローカルの鍵ストアを、必要とされるあらゆる付加的なユーザ認証情報を含むユーザが必要とする特定の鍵または鍵暗号化鍵を保持するよう構成可能である。鍵ストア自体を暗号化し、認証されたユーザのみが利用可能であってもよい。

図２１は、本開示の種々の態様による暗号化鍵の管理方法２１００を示すフローチャートである。図２１を参照すると、ブロック２１１０で、鍵管理サーバへの接続が可能かどうか判断してもよい。鍵管理サーバへの接続が可能であるという判断（２１１０−Ｙ）に応え、ブロック２１１５でクライアントは、暗号化鍵にアクセスするため鍵管理サーバと通信してもよい。

鍵管理サーバへの接続が可能でないという判断（２１１０−Ｎ）に応え、ブロック２１２０で、クライアントがローカルの鍵ストアを使用する許可を有するかどうか判断してもよい。クライアントがローカルの鍵ストアを使用する許可を有するという判断（２１２０−Ｙ）に応え、クライアントはローカルの鍵ストアから暗号化鍵にアクセスしてもよい。クライアントがローカルの鍵ストアを使用する許可を有していないという判断（２１２０−Ｎ）に応え、ブロック２１３０でデータの暗号化を停止してもよい。

Ｘ．複合セキュリティ鍵
本開示の種々の態様によると、ユーザおよび鍵技術はＡＮＤ／ＯＲのブール論理を用いて複合鍵を補助してもよい。システムは、鍵のアクセス要求を制御するために動的表現を導入することにより、複合鍵の概念を拡張する。複合鍵を、幾つもの下位鍵を用いて形成可能である。複合鍵を有効にするためには、下位鍵全体が全て存在して正（ブールＡＮＤ）であるべきで、または下位鍵のうち少なくとも１つが存在して正（ブールＯＲ）であるべきである。有効な鍵を形成するよう使用される、ブール構成のあらゆる組み合わせがあってもよい。

本開示の種々の態様によると、鍵のアクセス要求を制御するのに動的表現を使用してもよい。鍵は、鍵の機能を制限または制御するためのブール表現のあらゆる組み合わせを有してもよい。例えば鍵のアクセス表現を、（Ａｌｉｃｅ ＡＮＤ（Ｂｏｂ ＯＲ Ｃａｒｌ））と記載し、ＢｏｂまたはＣａｒｌのどちらかと協調してなされる場合だけ、Ａｌｉｃｅがファイルのロックを外すのを可能にしてもよい。複合鍵はまた、ユーザ名だけではなく地理位置、時刻およびハッシュチェックサムを含む種類に制限がない他の条件を含んでもよい。例えば、（Ａｌｉｃｅ ＡＮＤ（Ｂｏｂ ＯＲ Ｃａｒｌ）ＡＮＤ ＡＣＣＥＳＳＴＩＭＥ ＩＳ ＥＱＵＡＬ ＢＵＳＩＮＥＳＳＨＯＵＲＳ）は、営業時間のみの制限を追加してもよい。さらに、鍵アクセスの表現は動的条件を包含してもよく、それは（例えば脅威レベルが高いかどうかだがそれらに限定されない）外部の状況に基づき変化しうる。例えば、（Ａｌｉｃｅ ＡＮＤ（Ｂｏｂ ＯＲ Ｃａｒｌ）ＡＮＤ ＳＥＣＵＲＩＴＹＬＥＶＥＬ ＩＳ ＥＱＵＡＬ（ＮＯＲＭＡＬ ＯＲ ＬＯＷ））は、セキュリティ状況が正常または低レベルであるときのみアクセスを可能にする。これらの表現は、ハッカーアタック中のときのように迅速な状況の変化でさえ、データを自動的に安全に保つよう高精度の反応アクセス制御を可能にする。本開示の範囲から逸脱することなく他の組み合わせを使用しうることを、当業者は理解するだろう。

図２２は、本開示の種々の態様による複合鍵の評価方法２２００を示すフローチャートである。図２２を参照すると、ブロック２２１０で、それぞれのデータアクセスの試みについて、セキュリティ鍵のアクセス表現を決定してもよい。例えばアクセス表現は、ブール表現および／または外部の状況のあらゆる組み合わせを含んでもよい。ブロック２２１５で、あらゆる必要とされる外部の状況を含むセキュリティ鍵のアクセス表現を評価してもよい。ブロック２２２０で、アクセス表現および／または外部の状況が満たされているかどうか判断してもよい。

ブロック２２２５で、アクセス表現および／または外部の状況が満たされていない（２２２０−Ｎ）という判断に応え、セキュリティ鍵を拒絶し、データアクセスを拒否してもよい。ブロック２２３０で、アクセス表現および／または外部の状況が満たされている（２２２０−Ｙ）という判断に応え、アクセス鍵を承認し、データアクセスを許可してもよい。

ＸＩ．データアクセス制限
本開示の種々の態様によると、暗号化されたデータは、ユーザの役割、複合鍵、位置特定、アクセス時間、アクセス時間の長さ、他の鍵に対するアクセスの順序を含むがそれらに限定されない幾つものアクセス制限を有してもよい。その他に、有効なユーザセッションを、特定の条件が満たされないときデータのアクセスを制限してもよい。これらの条件を、任意に形成しあらゆるデータ項目に割り当て可能である。例えば、特定のデータ項目を特定の地理的領域内および特定の時刻にのみユーザがアクセスすべきである場合、それらの条件が満たされない場合、システムはユーザがこのデータファイルにアクセスするのを可能にしない。システムは便宜上ある「あらかじめ準備された」タイプの制限を提供してもよいが、付加的な制限を追加してもよい。

システムは、データエレメントレベルにアクセス制限を加えてもよい。このアプローチは柔軟性を最大化することが可能であり、例えば社会保障番号といったそれぞれのデータ項目が他の社会保障番号と異なることが可能なそれ自体のアクセス制限のセットを有することが可能である。また、アクセス制限は任意であることが可能で、ブール表現として表現およびメタデータとして格納してもよい。ハッカーが制限を発見または変更するのを防ぐため、全てのアクセス制限は断片化、暗号化、分離および分散される。

図２３は、本開示の種々の態様によるデータアクセス制限方法２３００を示すフローチャートである。図２３を参照すると、ブロック２３１０で、データアクセス要求を開始してもよい。ブロック２３１５で、アクセス制限および／またはデータのアクセス状況を決定してもよい。アクセス制限／状況は、ユーザの役割、複合鍵、位置特定、アクセス時間、アクセス時間の長さ、他の鍵に対するアクセスの順序を含んでもよいが、それらに限定されない。ブロック２３２０で、アクセス制限および／または状況を評価してもよい。ブロック２３２５で、アクセス制限／状況が満たされているかどうか判断してもよい。

ブロック２３３０で、アクセス制限／状況が満たされないという判断（２３２５−Ｎ）に応え、データへのアクセスを拒否してもよい。ブロック２３３５で、アクセス制限／状況が満たされるという判断（２３２５−Ｙ）に応え、データへのアクセスを許可してもよい。

ＸＩＩ．ハッキング
本開示の種々の態様によると、迅速な検出技術は、使用されるとき、例えば警告、鍵ローテーションなど（それらに限定されない）といった特定のアクションを始動させる「ハニーポット鍵」を補助する。ハニーポット鍵は、ハッカーに残された露出された鍵および／または見つけるための不正なソフトウェアである。

有効なアクセス鍵および認証情報は、ユーザがシステムに保護されたデータを適切にアクセスするのに必要である。高速検出アルゴリズムは、いずれかのデータのアクセスに不正な鍵が使用される場合、例外イベントを始動させる。鍵は、強制で正規のユーザが入力する「強要鍵」と同様に、ハッカーが見つけ使用を試みるようハッカーに残された「ハニーポット」鍵を含んでもよい。不正または誤った鍵により引き起こされる例外イベントを、自動的に鍵をローテーションする、ユーザをシャットアウトする、およびセキュリティ職員に警告するのに使用可能である。

図２４は、本開示の種々の態様によるハッキング攻撃の検出および反応方法２４００を示すフローチャートである。図２４を参照すると、ブロック２４１０で、データアクセス要求を開始しシステムにより受信してもよい。ブロック２４２０で、データアクセス要求とともに提供されたアクセス鍵を有効化してもよい。例えば、高速検出アルゴリズムをアクセス鍵に適用してもよい。ブロック２４３０で、アクセス鍵が要求されたデータに有効かどうかを判断してもよい。ブロック２４４０で、アクセス鍵が有効であるという判断（２４３０−Ｙ）に応え、要求されたデータへのアクセスを許可してもよい。

ブロック２４５０で、アクセス鍵が有効でないという判断（２４３０−Ｎ）に応え、
要求されたデータへのアクセスを拒否してもよい。ブロック２４６０で、反応プロトコルを開始してもよい。例えば反応プロトコルは、データアクセス要求を開始したユーザを完全にログアウトさせてもよく、要求されたデータ項目へのアクセスのみを拒否してもよく、または限定されたデータのセットへのアクセスのみを可能にしてもよい。代わりにまたは加えて、プロトコルは、アクセスを試みたシステムの管理者に、アクセス鍵の無効および／または暗号化鍵のローテーションおよび／またはシステムの運転停止を通知してもよい。

ＸＩＩＩ．ランサムウェア
本開示の種々の態様によると、抗ランサム暗号化保護は、例えばバックアップアーカイブの作成のようにデータが操作される前にシステムが予測せずに変更されたかどうかを判断するのにシステムが使用する「カナリアファイル」を含んでもよい。システムはランサムウェア攻撃が起きると推測し、従って復旧のため通常のバックアップを行う。しかし、ランサムウェアウィルスに感染した損傷したファイルはバックアップすべきではない。ユーザのハードドライブをネットワーク上にアーカイブするシステムを使用する企業について、ユーザのハードドライブ中に散乱した小さなファイルである「カナリアファイル」が使用される。これらのカナリアファイルのいずれかが紛失または変更されると、それはドライブが不正アクセスされた指標である。バックアップの実行前、システムはカナリアファイルをチェックし、それによって感染したドライブのバックアップ（および最後の正常なバックアップを上書きする可能性）を防ぐ。攻撃から復旧するため、最後の正常なアーカイブを復号し、感染したハードドライブの内容を置き換えることが可能である。

図２５は、本開示の種々の態様によるランサムウェア攻撃の検出および反応方法２５００を示すフローチャートである。図２５を参照すると、ブロック２５１０で、システムによるディスクドライブの最初のアクセスで、システムは１つまたは複数のカナリアファイルを設置してもよい。例えば、小さな公知のファイルをディスクドライブ中に散乱させてもよい。ブロック２５２０で、カナリアファイルが有効かどうかを確認することにより、ディスクドライブのステータスチェックを実行してもよい。例えば設置されたカナリアファイルを、カナリアファイルの予測される数および内容と比較してもよい。紛失または変更されたカナリアファイルは、ディスクドライブが不正アクセスされた指標でありうる。

ブロック２５３０で、ディスクドライブがランサムウェアに感染したかどうか判断してもよい。例えばシステムは、カナリアファイルのいずれかが紛失または変更されたかどうかを判断してもよい。ブロック２５４０で、ディスクドライブが感染しなかったという判断（２５３０−Ｎ）に応え、ディスクドライブの内容を暗号化し他のディスクドライブにバックアップしてもよい。

ブロック２５５０で、ディスクドライブが感染したという判断（２５３０−Ｙ）に応え、ディスクドライブのバックアップを見合わせてもよい。ディスクドライブバックアップの見合わせは、ディスクドライブ内容の最後に認識された正常なコピーを上書きすることを防ぐ。ブロック２５６０で、管理者にディスクドライブの感染を通知するよう警告を始動させてもよい。ブロック２５７０で、ディスクドライブの内容を、予めバックアップしたバージョンから復元してもよい。

ＸＩＶ．暗号化されたデータの検索
本開示の種々の態様によると、データの事前索引付けのための加速アクセスレコード（ＡＡＲ）が、索引付けされるデータから分離して格納され、分析およびレポートを提供するようサードパーティのソフトウェアにより利用してもよい。ＡＡＲは最適化された検索レコードで、高度な分析およびレポートを提供するサードパーティ検索ツールに統合可能である。これらの検索レコードを、セキュリティの目的でシステムが他のサーバに分離して格納してもよい。システムセキュリティソフトウェアも実行するこの第２のサーバは、サードパーティのアクセスおよび／またはサードパーティの検索ツールを可能にする分離した認証層を有することが可能である。

図２６は、本開示の種々の態様による、暗号化されたデータの検索を可能にする方法２６００を示すフローチャートである。図２６を参照すると、ブロック２６１０で、データがシステム内のディスクに格納される。ブロック２６２０で、データが検索可能であるべきかどうか決定するためデータをチェックしてもよい。ブロック２６４０で、データが検索可能であるべきではないという判断（２６３０−Ｎ）に応え、システムはディスク内容を暗号化およびバックアップしてもよい。

ブロック２６５０で、データが検索可能であるべきであるという判断（２６３０−Ｙ）に応え、システムはシステム上のリモートサーバドライブに加速アクセスレコード（ＡＡＲ）を追加してもよい。ブロック２６６０で、データが検索されるとき、暗号化された内容の検索のためＡＡＲにアクセスしてもよい。

ＸＶ．データの暗号化
本開示の種々の態様によると、システムにより暗号化された全てのデータを、仮想暗号解読コンテナ（ＶＣＣ）と呼ばれるユーザが形成可能な場所のセット内へ格納および編成してもよい。暗号化されたデータを、ＶＣＣ内の複数のデータストアにわたり分散してもよい。これらのＶＣＣは、単一の装置、例えばＵＳＢスティック（それに限定されない）から複数のデータセンタまでの範囲に及んでもよく、動的に形成可能な場所を有してもよい。これらのＶＣＣの他の装置への許可されない移転はシステムにより検出可能であり、アクセスおよび鍵ローテーションを不可能にすることを含む幾つものアクションを始動可能である。

ＶＣＣが単一のドライブ上全体に、または複数のデータセンタにわたる複数のドライブおよびフォーマット上に存在するように、それを構成してもよい。このアプローチの柔軟性は、アプリケーションがどのようにまたはどこに暗号化されたデータを格納するかに関知しないように記憶装置を仮想化するシステムの能力から生じる。アプリケーションは、暗号化のためのデータ送信およびそのデータの復号のための取り出しのためシステムのみと相互作用する。システムは、１つまたは複数の記憶装置の場所を管理してもよい。このアプローチのいくつかの利点は以下を含みうる。
・ＶＣＣは単一のハードドライブ内全体に存在して、他のハードドライブへの安全な伝送をしやすくしうる。例えば、ＶＣＣをＵＳＢスティック上におき、システムがそのＶＣＣにアクセスするため使用されるような時まで完全に暗号化された状態を保つことが可能である。
・ＶＣＣは、特定の環境でその使用を制限するマーカーを有してもよい。例えばＶＣＣを、特定のドライブまたはハードウェアＭＡＣアドレスまたはいくつかの署名ＩＤにおかれたときのみ作動するよう符号化することが可能である。ＶＣＣを、特定の場所からまたはある時刻または日にアクセスされるときのみ作動するよう制限可能である。システムは、これらのＶＣＣの状況が満たされた場合を除いて、データを暗号化または復号することが不可能である。
・ＶＣＣは、下層の記憶媒体が何か、およびその媒体についての特定のＡＰＩが何かをアプリケーションが認識する必要をなくす。例えば、Ａｍａｚｏｎ Ｓ３およびＭＳ Ａｚｕｒｅのサービスが使用可能である前に、アプリケーション内へ統合しなければならない一意のＡＰＩを全てが持つ、Ａｍａｚｏｎ Ｓ３およびＭＳ Ａｚｕｒｅのような多数のクラウドデータストアがある。システムは、直接的な装置格納を含むそれらの全ての格納の選択肢に単一のＡＰＩを提供してもよい。
・複製およびバックアップの選択肢はＶＣＣの使用を通して容易にされ、さまざまな選択肢があってもよい。例えば、ＶＣＣがタブレットコンピュータのような単一の装置全体に格納された場合、バックアップとしてＶＣＣを周期的に複製し装置から離して格納してもよい。ＶＣＣが複数の記憶装置の箇所にわたる場合、リアルタイムでパラレルＶＣＣにそれぞれの格納要求を複製するようシステムを構成してもよい。下層のデータストア（例えば、Ａｍａｚｏｎ Ｓ３クラウド）もまた、利用可能にされたそれら自体のバックアッププロセスを有してもよく、それがシステムとともに途切れることなく作動する。

図２７は、本開示の種々の態様による暗号化されたデータの格納のため仮想暗号解読コンテナを使用する方法２７００を示すフローチャートである。図２７を参照すると、ブロック２７１０で、利用可能な格納場所のそれぞれへのパス名を含むセットアップ構成ファイルを規定してもよい。格納場所はその装置のハードディスクドライブであってもよく、ＬＡＮ内またはクラウドサービスエンドポイントから離れたＷＡＮにわたり据え付けられたドライブであってもよく、またはそれらの組み合わせであってもよい。セットアップ構成ファイルはまた、他のシステムの選択肢を規定してもよい。

ブロック２７２０で、システムを開始してもよく、ブロック２７４０でＶＣＣを確立してもよい。例えばシステムは、セットアップ構成ファイルを読み出し、その後のアクセスのためＶＣＣを確立してもよい。ブロック２７５０で、データの暗号化または復号のためシステムにアクセスしてもよい。例えば、データの暗号化または復号が必要なアプリケーションは、システムへのＡＰＩコールを作成してもよい。ブロック２７６０で、データを、ＶＣＣによりアプリケーションによって要求されたように暗号化または復号してもよい。例えばシステムは、データを暗号化しＶＣＣ内に格納、またはＶＣＣ内に格納されたデータを取り出し復号することによってアプリケーションの要求を実行してもよい。

ＸＶＩ．さらなる機能
本開示の種々の態様によると、システムは、規制する制限に適合する能力を持つセキュリティエンジンを有してもよい。システムを、エクスポートしない制限されたＡＥＳ−１２８または低位のサイファで構成してもよい。代わりにシステムを、ＦＩＰＳ １４０−２ライブラリまたは外部の暗号化ハードウェア製品を使用するよう構成してもよい。システムはいずれの暗号化サイファにも結び付けられず、従ってユーザのニーズおよび要求に適合し、それとともに増大する。例えば、強力な暗号ライブラリをシステムにエクスポート不可能な国々のユーザのため、システムをＵＳ輸出法で許可されたライブラリで構成してもよい。

さらにシステムは、集中型サーバまたは暗号化装置として作動してもよく、ならびに保存するとデータの保護のためエンドポイント装置上で実行する能力を有してもよい。本開示によると、データ断片は、通過の際にハッカーがデータを変更する可能性をなくすよう、受信される際の改ざん検出を有してもよい。システムは、個々の断片が受信されているときにそれらを認証する。ＧＣＭベースのＡＥＳ−２５６暗号化を含むがそれらに限定されないいくつかの方法を、この認証の実行に使用してもよい。この認証に通らない断片は、改ざんされたと識別され拒絶される。構成により、ＦＨＯＯＳＨは、鍵ローテーション、接続停止、または断片の再送のようなさまざまな方法で反応する。

種々の実施形態を前述したが、それらは例としてのみ提示され、限定ではないことを理解するべきである。範囲は、前述の例示的な実施形態のいずれによっても限定されるべきではない。この文書が当業者に明らかまたは公知の技術を指す場合、そのような技術は現在または将来のいつでも当業者に明らかまたは公知のそれらを含む。また、記載された実施形態は示された例の基本設計概念または構成に制限されず、所望の機能を、さまざまな代替的な基本設計概念および構成を用いて実行可能である。この文書を読んだ後当業者に明らかになるように、示された実施形態およびそれらの代替手段を、示された例へ限定することなく実行可能である。当業者はまた、記載された実施形態の所望の機能を実行するのにどのように代替的な機能的、論理的または物理的パーティション分割および構成を使用可能であるかを理解するであろう。

さらに、品目、成分または構成要素が単数形で記載または主張されることがありうるが、単数への限定が明確に述べられた場合を除いて、複数がその範囲内であると考えられる。「１つまたは複数の」、「少なくとも」、が、「それらに限定されない」または一部のケースの他の同様の語句のような範囲を広める言葉および語句の存在は、そのような範囲を広める語句が欠けていることがありうる場合、そのより狭い範囲のケースが意図または必要とされることを意味すると読むべきではない。

Claims (85)

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. 前記第１の断片が前記第１の暗号化鍵を用いて前記第２の暗号化鍵で暗号化され、前記第２の断片が前記第２の暗号化鍵を用いて第３の暗号化鍵で暗号化され、前記第３の暗号化鍵が前記第１のデータオブジェクトの第３の断片の暗号化に使用される、請求項２６に記載のシステム。
39. 前記第１の本来のレコードロケータおよび前記第２の本来のレコードロケータのそれぞれを難読化するため、前記１つまたは複数のプロセッサが、
    前記第１の本来のレコードロケータおよび前記第２の本来のレコードロケータのそれぞれを変更し、
    前記第１の本来のレコードロケータおよび前記第２の本来のレコードロケータのそれぞれに難読化機能を適用する
    よう構成された、請求項２６に記載のシステム。
40. 前記１つまたは複数のプロセッサが、前記第１の本来のレコードロケータおよび前記第２の本来のレコードロケータのそれぞれを、１つまたは複数の可変的な格納パラメータの少なくとも一部に基づき難読化するようさらに構成された、請求項３９に記載のシステム。
41. 前記１つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第１のデータオブジェクトのタイプ、前記第１のデータオブジェクトのサイズ、１つまたは複数のセキュリティ必要条件、および１つまたは複数の性能必要条件のうち少なくとも１つを含む、請求項４０に記載のシステム。
42. 前記１つまたは複数のプロセッサが、トリガの検出に応え、前記１つまたは複数の可変的な格納パラメータを変えるようさらに構成された、請求項５０に記載のシステム。
43. 前記トリガが、前記第１のデータオブジェクト、第２のデータオブジェクト、前記第１の複数の格納場所、および前記第２の複数の格納場所のうち１つまたは複数に対するセキュリティ侵害を含む、請求項４２に記載のシステム。
44. 前記１つまたは複数のプロセッサが、１つまたは複数の可変的な格納パラメータの少なくとも一部に基づき、前記第１の暗号化された断片と前記対応する第１の難読化されたレコードロケータ、および前記第２の暗号化された断片と前記第２の難読化されたレコードロケータを格納する少なくとも前記第１の複数の格納場所を識別するようさらに構成された、請求項２６に記載のシステム。
45. 前記１つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第１のデータオブジェクトのタイプ、前記第１のデータオブジェクトのサイズ、１つまたは複数のセキュリティ必要条件、および１つまたは複数の性能必要条件のうち少なくとも１つを含む、請求項４４に記載のシステム。
46. 前記１つまたは複数のプロセッサが、トリガの検出に応え、前記１つまたは複数の可変的な格納パラメータを変えるようさらに構成された、請求項４４に記載のシステム。
47. 前記１つまたは複数のプロセッサが、前記第１のデータオブジェクトの前記第１の断片および前記第２の断片のシーケンスのインデックス、前記第１の暗号化鍵および前記第２の暗号化鍵、前記第１の難読化されたレコードロケータおよび前記第２の難読化されたレコードロケータ、および少なくとも前記第１の複数の格納場所のうち１つまたは複数を有するデータマップを生成するようさらに構成された、請求項２６に記載のシステム。
48. 前記１つまたは複数のプロセッサが、前記データマップを暗号化し、前記暗号化されたデータマップを格納するようさらに構成された、 請求項４７に記載のシステム。
49. 前記１つまたは複数のプロセッサが、１つまたは可変的な格納パラメータの少なくとも一部に基づき、前記データマップの内容を変えるようさらに構成された、請求項４７に記載のシステム。
50. 前記１つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第１のデータオブジェクトのタイプ、前記第１のデータオブジェクトのサイズ、１つまたは複数のセキュリティ必要条件、および１つまたは複数の性能必要条件のうち少なくとも１つを含む、請求項４９に記載のシステム。
51. 前記データオブジェクトの取り出しおよび再構成に必要とされる情報の少なくとも第１の部分を含むデータマップを取り出すことと、
    前記データオブジェクトの取り出しおよび再構成に必要とされる前記情報の少なくとも第２の部分を動的に取り出すよう１つまたは複数の計算を実行することと、
    少なくとも第１の複数のデータ格納場所から前記データオブジェクトを取り出し、前記データマップ内に含まれる前記情報および１つまたは複数の計算を通して動的に得られる前記情報のうちの１つまたは複数に基づき前記データオブジェクトを再構成することと
    を含む、データオブジェクトを取り出す方法。
52. 前記データオブジェクトの取り出しおよび再構成に必要とされる前記情報が、前記データオブジェクトの複数の断片のシーケンスのインデックス、前記複数の断片のそれぞれの暗号化に使用される暗号化鍵、前記複数の断片のそれぞれに関連する難読化されたレコードロケータ、およびそれぞれの前記複数の断片が格納された少なくとも前記第１の複数の格納場所を含む、請求項５１に記載の方法。
53. 前記データマップ内に含まれない前記データオブジェクトの取り出しおよび再構成に必要とされる前記情報の一部を動的に取り出すよう、前記１つまたは複数の計算が実行される、請求項５１に記載の方法。
54. 前記１つまたは複数の計算が、前記データオブジェクトを複数の断片に分解するため適用される分解機能の決定、前記複数の断片のそれぞれに関連する難読化されたレコードロケータの決定、前記複数の断片のそれぞれの暗号化に使用される暗号化鍵の計算、およびそれぞれの前記複数の断片が格納される少なくとも前記第１の複数の格納場所の識別を含む、請求項５１に記載の方法。
55. 前記データマップの内容の変更が、前記データオブジェクトの取り出しおよび再構成に必要とされる前記情報の前記第２の部分を動的に取得するため実行されるのに必要とされる計算の範囲を変え、前記データマップの前記内容が、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記データオブジェクトのタイプ、前記データオブジェクトのサイズ、１つまたは複数のセキュリティ必要条件、および１つまたは複数の性能必要条件のうちの１つまたは複数に基づき変更される、請求項５１に記載の方法。
56. 第１のデータストアおよび第２のデータストアと、
    前記第１のデータストア内に格納されたユーザのデータを取り出す要求を送信するよう構成されたクライアント装置と、
    前記第１のデータストア内に格納された前記ユーザのデータから分離した前記第２のデータストアにユーザ認証情報およびデータストア認証情報を格納し、
    前記クライアント装置から前記第１のデータストア内に格納されたユーザのデータを取り出す前記要求を受信し、
    ユーザのデータを取り出す前記要求に応え、前記第２のデータストアから、前記クライアント装置のユーザに関連するユーザ認証情報、および前記第１のデータストアに関連するデータストア認証情報を取り出し、
    前記クライアント装置の前記ユーザの前記ユーザ認証情報、および前記第１のデータストアのデータストア認証情報を使用して前記第１のデータストアからユーザのデータを取り出し、
    前記ユーザのデータを前記クライアント装置に提供する
    よう構成されたセキュア鍵プラットフォームと
    を備える、認証情報および暗号化鍵を格納および管理するシステム。
57. 前記セキュア鍵プラットフォームが、ブラウザのタイプ、プラグイン、ハードウェア設定、および位置特定のうちの１つまたは複数を検証および記録することによることを含んで前記クライアント装置を登録するようさらに構成された、請求項１に記載のシステム。
58. セキュア鍵プラットフォームが、１つまたは複数の困難な質問を出し、前記１つまたは複数の困難な質問への応答を格納することにより、前記クライアント装置を登録するようさらに構成された、請求項２に記載のシステム。
59. 前記クライアント装置が前記セキュア鍵プラットフォームにログインするよう試みるようにさらに構成され、前記セキュア鍵プラットフォームが、前記ユーザ認証情報および前記データストア認証情報を取り出し、前記ユーザ認証情報およびデータストア認証情報を用いて前記第１のデータストアからユーザのデータを取り出す前に、前記クライアント装置を認証するようさらに構成された、請求項１に記載のシステム。
60. 前記セキュア鍵プラットフォームが、前記クライアント装置の正常な認証に応え、前記ユーザ認証情報を自動的に取り出すよう構成された、請求項４に記載のシステム。
61. 前記セキュア鍵プラットフォームが、前記ユーザにより提供されるユーザ名、前記ユーザにより提供されるパスワード、前記ユーザにより提供される少なくとも１つの困難な質問への返答、前記クライアント装置のブラウザのタイプ、前記クライアント装置のプラグイン、前記クライアント装置のハードウェア設定、前記クライアント装置の位置特定、および前記クライアント装置が前記ログインを試みるインターネットプロトコル（ＩＰ）アドレスのうちの１つまたは複数に基づき前記クライアント装置を認証するよう構成された、請求項４に記載のシステム。
62. 前記ユーザ認証情報が第１のパスフレーズを有する、請求項１に記載のシステム。
63. 前記第１のデータストア内に格納された前記ユーザのデータが、前記第１のパスフレーズを用いて暗号化される、請求項７に記載のシステム。
64. 第１のパスフレーズが第２のパスフレーズへのアクセスを制御し、前記第１のデータストア内に格納された前記ユーザのデータが、前記第２のパスフレーズを用いて暗号化される、請求項７に記載のシステム。
65. 前記ユーザのデータを複数のセグメントに分解し、
    前記分解されたユーザのデータの前記複数のセグメントを、前記第１のデータストアを含む複数のデータストアにわたり格納する
    よう構成されたセキュアオブジェクトプラットフォームをさらに備える、請求項１に記載のシステム。
66. 第１の装置と第２の装置の間のデータストリーミングのため通信を確立することと、
    共有鍵を確立することと、
    前記第１の装置と前記第２の装置の間で前記共有鍵を交換することと、
    前記共有鍵を用いて前記第１の装置によりデータセットを暗号化することと、
    前記共有鍵を用いて前記第２の装置により前記データセットを復号することと、
    前記共有鍵が再生成されるべきかどうかを判断するために鍵再生成基準を評価することと、
    前記共有鍵が再生成されるべきであるという判断に応え、
    新しい共有鍵を生成し、
    前記新しい共有鍵を用いて前記第１の装置により次のデータセットを暗号化することと
    を含む、装置間の認証された通信方法。
67. 共有鍵の前記確立が、暗号化アルゴリズムパラメータおよび暗号化アルゴリズムについてのシードの提供を含む、請求項１に記載の方法。
68. 前記共有鍵の前記交換が、複数の鍵交換方法の統合を含む、請求項１に記載の方法。
69. 鍵交換方法および鍵交換の頻度のうちの少なくとも１つを動的に変えることをさらに含む、請求項３に記載の方法。
70. 鍵交換方法および鍵交換の頻度のうち少なくとも１つが、前記第１の装置または前記第２の装置の性能の必要条件およびセキュリティ脅威レベルに基づき動的に変えられる、請求項４に記載の方法。
71. 鍵再生成基準が、共有鍵が再生成されるべきかどうか判断するために評価される、請求項１に記載の方法。
72. 鍵再生成基準が、利用可能な暗号化アルゴリズムおよび前記暗号化アルゴリズムについての特定のパラメータを識別する、請求項６に記載の方法。
73. 鍵再生成基準が満たされるまで共有鍵が再生成されるべきときを示す状況の監視をさらに含む、請求項６に記載の方法。
74. 前記新しい共有鍵の生成が、前記共有鍵についての新しい暗号化アルゴリズムパラメータの提供を含む、請求項１に記載の方法。
75. セキュア鍵の使用、およびデータセットの鍵ローテーションの割合の最大化により、高度なセキュリティを提供することをさらに含む、請求項１に記載の方法。
76. 通信インタフェースと、
    第１の装置と第２の装置の間のデータストリーミングのため通信を確立し、
    共有鍵を確立し、
    前記第１の装置と前記第２の装置の間で前記共有鍵を交換し、
    前記共有鍵を用いて前記第１の装置によりデータセットを暗号化し、前記第２の装置が前記共有鍵を用いて前記データセットを復号し、
    前記共有鍵が再生成されるべきかどうかを判断するために鍵再生成基準を評価し、
    前記共有鍵が再生成されるべきであるという判断に応え、
    新しい共有鍵を生成し、
    前記新しい共有鍵を用いて前記第１の装置により次のデータセットを暗号化する
    よう構成されたプロセッサと
    を備える、装置間の認証された通信システム。
77. 前記プロセッサが、暗号化アルゴリズムパラメータおよび暗号化アルゴリズムについてのシードの提供により共有鍵を確立するようさらに構成された、請求項１１に記載のシステム。
78. 前記プロセッサが、前記共有鍵の交換のため複数の鍵交換方法を統合するようさらに構成された、請求項１１に記載のシステム。
79. 前記プロセッサが、鍵交換方法および鍵交換の頻度のうち少なくとも１つを動的に変えるようさらに構成された、請求項１３に記載のシステム。
80. 前記鍵交換方法および鍵交換の頻度のうち少なくとも１つが、前記第１の装置または前記第２の装置の性能の必要条件およびセキュリティ脅威レベルに基づき動的に変えられる、請求項１４に記載のシステム。
81. 前記共有鍵が再生成されるべきかどうか判断するために、鍵再生成基準を評価するようさらに構成された、請求項１１に記載のシステム。
82. 鍵再生成基準が、可能な暗号化アルゴリズムおよび前記暗号化アルゴリズムについての特定のパラメータを識別する、請求項１６に記載のシステム。
83. 前記プロセッサが、鍵再生成基準が満たされるまで前記共有鍵が再生成されるべきときを示す状況を監視するようさらに構成された、請求項１６に記載のシステム。
84. 前記プロセッサが、前記共有鍵の生成のための新しい暗号化アルゴリズムパラメータを提供するようさらに構成された、請求項１１に記載のシステム。
85. 前記プロセッサが、セキュア鍵の使用、およびデータセットのための鍵ローテーションの割合の最大化により、高度なセキュリティを提供するようさらに構成される、
    ことをさらに含む、請求項１１に記載のシステム。

Images