図面 (/)

この項目の情報は公開日時点(2019年7月25日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題・解決手段

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

概要

背景

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データの暗号化速度
現在、性能(データが暗号化可能な速度)を上げるいくつかのアプローチがある。1つのアプローチは、ハードウェアベースの高速化を用いることである。128ビットおよび256ビットのAESサイファを、AES−NIハードウェアの暗号化を通して、(IntelおよびAMDプロセッサ上で利用可能な場合)4から8倍加速可能である。セキュリティを犠牲にして、鍵のサイズを減少させることもまた可能である。256ビットの鍵のAESは、128ビットの鍵のAESより約40%遅い。他の戦略は、20%の速度改善が可能なBlowfishのような別の暗号化アルゴリズムを使用することである。

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

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

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

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

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

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

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

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

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

概要

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

目的

これらのツールは時間を節約し、予算作成などの効果的なツールを提供可能であるが、それらは、特定のフォーマットで、または特定のフォームなどにより個人情報、財務情報、予測、分類された出費などを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記第1のデータオブジェクトが、分解機能の適用により分解される、請求項1に記載の方法。

請求項3

1つまたは複数の可変的な格納パラメータの少なくとも一部に基づき前記分解機能を選択することをさらに含む、請求項2に記載の方法。

請求項4

前記1つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第1のデータオブジェクトのタイプ、前記第1のデータオブジェクトのサイズ、1つまたは複数のセキュリティ必要条件、および1つまたは複数の性能必要条件のうち少なくとも1つを含む、請求項3に記載の方法。

請求項5

トリガの検出に応え、前記1つまたは複数の可変的な格納パラメータを変えることをさらに含む、請求項2に記載の方法。

請求項6

前記トリガが、前記第1のデータオブジェクト、第2のデータオブジェクト、前記第1の複数の格納場所、および前記第2の複数の格納場所のうちの1つまたは複数に対するセキュリティ侵害を含む、請求項5に記載の方法。

請求項7

前記第1の本来のレコードロケータの少なくとも一部に基づき前記第1の暗号化鍵を決定し、前記第2の本来のレコードロケータの少なくとも一部に基づき前記第2の暗号化鍵を決定することをさらに含む、請求項1に記載の方法。

請求項8

前記第1の暗号化鍵および前記第2の暗号化鍵がさらに、1つまたは複数の可変的な格納パラメータの少なくとも一部に基づき決定される、請求項7に記載の方法。

請求項9

前記1つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第1のデータオブジェクトのタイプ、前記第1のデータオブジェクトのサイズ、1つまたは複数のセキュリティ必要条件、および1つまたは複数の性能必要条件のうち少なくとも1つを含む、請求項8に記載の方法。

請求項10

トリガの検出に応え、前記1つまたは複数の可変的な格納パラメータを変えることをさらに含む、請求項8に記載の方法。

請求項11

前記トリガが、前記第1のデータオブジェクト、第2のデータオブジェクト、前記第1の複数の格納場所、および前記第2の複数の格納場所のうち1つまたは複数に対するセキュリティ侵害を含む、請求項10に記載の方法。

請求項12

前記第1の断片および前記第2の断片の暗号化の前に、前記第1の断片および前記第2の断片のそれぞれを難読化することをさらに含む、請求項1に記載の方法。

請求項13

前記第1の断片が前記第1の暗号化鍵を用いて前記第2の暗号化鍵で暗号化され、前記第2の断片が前記第2の暗号化鍵を用いて第3の暗号化鍵で暗号化され、前記第3の暗号化鍵が前記第1のデータオブジェクトの第3の断片の暗号化に使用される、請求項1に記載の方法。

請求項14

前記第1の本来のレコードロケータおよび前記第2の本来のレコードロケータのそれぞれを難読化することが、前記第1の本来のレコードロケータおよび前記第2の本来のレコードロケータのそれぞれを変更することと、前記第1の本来のレコードロケータおよび前記第2の本来のレコードロケータのそれぞれに難読化機能を適用することとを含む、請求項1に記載の方法。

請求項15

前記第1の本来のレコードロケータおよび前記第2の本来のレコードロケータのそれぞれが、1つまたは複数の可変的な格納パラメータの少なくとも一部に基づき難読化される、請求項14に記載の方法。

請求項16

前記1つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第1のデータオブジェクトのタイプ、前記第1のデータオブジェクトのサイズ、1つまたは複数のセキュリティ必要条件、および1つまたは複数の性能必要条件のうち少なくとも1つを含む、請求項15に記載の方法。

請求項17

トリガの検出に応え、前記1つまたは複数の可変的な格納パラメータを変えることをさらに含む、請求項15に記載の方法。

請求項18

前記トリガが、前記第1のデータオブジェクト、第2のデータオブジェクト、前記第1の複数の格納場所、および前記第2の複数の格納場所のうち1つまたは複数に対するセキュリティ侵害を含む、請求項27に記載の方法。

請求項19

1つまたは複数の可変的な格納パラメータの少なくとも一部に基づき、前記第1の暗号化された断片と前記対応する第1の難読化されたレコードロケータ、および前記第2の暗号化された断片と前記第2の難読化されたレコードロケータを格納するよう少なくとも前記第1の複数の格納場所を識別することをさらに含む、請求項1に記載の方法。

請求項20

前記1つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第1のデータオブジェクトのタイプ、前記第1のデータオブジェクトのサイズ、1つまたは複数のセキュリティ必要条件、および1つまたは複数の性能必要条件のうち少なくとも1つを含む、請求項19に記載の方法。

請求項21

トリガの検出に応え、前記1つまたは複数の可変的な格納パラメータを変えることをさらに含む、請求項19に記載の方法。

請求項22

前記第1のデータオブジェクトの前記第1の断片および前記第2の断片のシーケンスインデックス、前記第1の暗号化鍵および前記第2の暗号化鍵、前記第1の難読化されたレコードロケータおよび前記第2の難読化されたレコードロケータ、および少なくとも前記第1の複数の格納場所のうちの1つまたは複数を含むデータマップを生成することをさらに含む、請求項1に記載の方法。

請求項23

前記データマップを暗号化すること、および前記暗号化されたデータマップを格納することをさらに含む、請求項22に記載の方法。

請求項24

1つまたは可変的な格納パラメータの少なくとも一部に基づき、前記データマップの内容を変えることをさらに含む、請求項22に記載の方法。

請求項25

前記1つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第1のデータオブジェクトのタイプ、前記第1のデータオブジェクトのサイズ、1つまたは複数のセキュリティ必要条件、および1つまたは複数の性能必要条件のうち少なくとも1つを含む、請求項24に記載の方法。

請求項26

複数の格納場所と、前記1つまたは複数のプロセッサを備えるセキュアプラットフォームと、第1のデータオブジェクトを、第1の本来のレコードロケータに関連する第1の断片、および第2の本来のレコードロケータに関連する第2の断片に分解し、前記第1の本来のレコードロケータを難読化して第1の難読化されたレコードロケータを生成し、前記第2の本来のレコードロケータを難読化して第2の難読化されたレコードロケータを生成し、第1の暗号化鍵を用いて前記第1の断片を暗号化し、第2の暗号化鍵を用いて前記第2の断片を暗号化し、少なくとも第1の複数の格納場所に、前記第1の暗号化された断片および対応する第1の難読化されたレコードロケータ、および、前記第2の暗号化された断片および前記第2の難読化されたレコードロケータを格納するよう構成された1つまたは複数のプロセッサを備えるクライアント装置とを備える、第1のデータオブジェクトの格納システム

請求項27

前記第1のデータオブジェクトを分解するため、前記1つまたは複数のプロセッサが分解機能を適用するよう構成された、請求項26に記載のシステム

請求項28

前記1つまたは複数のプロセッサが、1つまたは複数の可変的な格納パラメータの少なくとも一部に基づき前記分解機能を選択するようさらに構成された、請求項27に記載のシステム。

請求項29

前記1つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第1のデータオブジェクトのタイプ、前記第1のデータオブジェクトのサイズ、1つまたは複数のセキュリティ必要条件、および1つまたは複数の性能必要条件のうち少なくとも1つを含む、請求項28に記載のシステム。

請求項30

前記1つまたは複数のプロセッサが、トリガの検出に応え、前記1つまたは複数の可変的な格納パラメータを変えるようさらに構成された、請求項27に記載のシステム。

請求項31

前記トリガが、前記第1のデータオブジェクト、第2のデータオブジェクト、前記第1の複数の格納場所、および前記第2の複数の格納場所のうち1つまたは複数に対するセキュリティ侵害を含む、請求項30に記載のシステム。

請求項32

前記1つまたは複数のプロセッサが、前記第1の本来のレコードロケータの少なくとも一部に基づき前記第1の暗号化鍵を決定し、前記第2の本来のレコードロケータの少なくとも一部に基づき前記第2の暗号化鍵を決定するようさらに構成された、請求項26に記載のシステム。

請求項33

前記1つまたは複数のプロセッサが、さらに1つまたは複数の可変的な格納パラメータの少なくとも一部に基づき、前記第1の暗号化鍵および前記第2の暗号化鍵を決定するよう構成された、請求項32に記載のシステム。

請求項34

前記1つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第1のデータオブジェクトのタイプ、前記第1のデータオブジェクトのサイズ、1つまたは複数のセキュリティ必要条件、および1つまたは複数の性能必要条件のうち少なくとも1つを含む、請求項33に記載のシステム。

請求項35

前記1つまたは複数のプロセッサが、トリガの検出に応え、前記1つまたは複数の可変的な格納パラメータを変えるようさらに構成された、請求項33に記載のシステム。

請求項36

前記トリガが、前記第1のデータオブジェクト、第2のデータオブジェクト、前記第1の複数の格納場所、および前記第2の複数の格納場所のうち1つまたは複数に対するセキュリティ侵害を含む、請求項35に記載のシステム。

請求項37

前記1つまたは複数のプロセッサが、前記第1の断片および前記第2の断片の暗号化の前に、前記第1の断片および前記第2の断片のそれぞれを難読化するようさらに構成された、請求項26に記載のシステム。

請求項38

前記第1の断片が前記第1の暗号化鍵を用いて前記第2の暗号化鍵で暗号化され、前記第2の断片が前記第2の暗号化鍵を用いて第3の暗号化鍵で暗号化され、前記第3の暗号化鍵が前記第1のデータオブジェクトの第3の断片の暗号化に使用される、請求項26に記載のシステム。

請求項39

前記第1の本来のレコードロケータおよび前記第2の本来のレコードロケータのそれぞれを難読化するため、前記1つまたは複数のプロセッサが、前記第1の本来のレコードロケータおよび前記第2の本来のレコードロケータのそれぞれを変更し、前記第1の本来のレコードロケータおよび前記第2の本来のレコードロケータのそれぞれに難読化機能を適用するよう構成された、請求項26に記載のシステム。

請求項40

前記1つまたは複数のプロセッサが、前記第1の本来のレコードロケータおよび前記第2の本来のレコードロケータのそれぞれを、1つまたは複数の可変的な格納パラメータの少なくとも一部に基づき難読化するようさらに構成された、請求項39に記載のシステム。

請求項41

前記1つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第1のデータオブジェクトのタイプ、前記第1のデータオブジェクトのサイズ、1つまたは複数のセキュリティ必要条件、および1つまたは複数の性能必要条件のうち少なくとも1つを含む、請求項40に記載のシステム。

請求項42

前記1つまたは複数のプロセッサが、トリガの検出に応え、前記1つまたは複数の可変的な格納パラメータを変えるようさらに構成された、請求項50に記載のシステム。

請求項43

前記トリガが、前記第1のデータオブジェクト、第2のデータオブジェクト、前記第1の複数の格納場所、および前記第2の複数の格納場所のうち1つまたは複数に対するセキュリティ侵害を含む、請求項42に記載のシステム。

請求項44

前記1つまたは複数のプロセッサが、1つまたは複数の可変的な格納パラメータの少なくとも一部に基づき、前記第1の暗号化された断片と前記対応する第1の難読化されたレコードロケータ、および前記第2の暗号化された断片と前記第2の難読化されたレコードロケータを格納する少なくとも前記第1の複数の格納場所を識別するようさらに構成された、請求項26に記載のシステム。

請求項45

前記1つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第1のデータオブジェクトのタイプ、前記第1のデータオブジェクトのサイズ、1つまたは複数のセキュリティ必要条件、および1つまたは複数の性能必要条件のうち少なくとも1つを含む、請求項44に記載のシステム。

請求項46

前記1つまたは複数のプロセッサが、トリガの検出に応え、前記1つまたは複数の可変的な格納パラメータを変えるようさらに構成された、請求項44に記載のシステム。

請求項47

前記1つまたは複数のプロセッサが、前記第1のデータオブジェクトの前記第1の断片および前記第2の断片のシーケンスのインデックス、前記第1の暗号化鍵および前記第2の暗号化鍵、前記第1の難読化されたレコードロケータおよび前記第2の難読化されたレコードロケータ、および少なくとも前記第1の複数の格納場所のうち1つまたは複数を有するデータマップを生成するようさらに構成された、請求項26に記載のシステム。

請求項48

前記1つまたは複数のプロセッサが、前記データマップを暗号化し、前記暗号化されたデータマップを格納するようさらに構成された、 請求項47に記載のシステム。

請求項49

前記1つまたは複数のプロセッサが、1つまたは可変的な格納パラメータの少なくとも一部に基づき、前記データマップの内容を変えるようさらに構成された、請求項47に記載のシステム。

請求項50

前記1つまたは複数の可変的な格納パラメータが、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記第1のデータオブジェクトのタイプ、前記第1のデータオブジェクトのサイズ、1つまたは複数のセキュリティ必要条件、および1つまたは複数の性能必要条件のうち少なくとも1つを含む、請求項49に記載のシステム。

請求項51

前記データオブジェクトの取り出しおよび再構成に必要とされる情報の少なくとも第1の部分を含むデータマップを取り出すことと、前記データオブジェクトの取り出しおよび再構成に必要とされる前記情報の少なくとも第2の部分を動的に取り出すよう1つまたは複数の計算を実行することと、少なくとも第1の複数のデータ格納場所から前記データオブジェクトを取り出し、前記データマップ内に含まれる前記情報および1つまたは複数の計算を通して動的に得られる前記情報のうちの1つまたは複数に基づき前記データオブジェクトを再構成することとを含む、データオブジェクトを取り出す方法。

請求項52

前記データオブジェクトの取り出しおよび再構成に必要とされる前記情報が、前記データオブジェクトの複数の断片のシーケンスのインデックス、前記複数の断片のそれぞれの暗号化に使用される暗号化鍵、前記複数の断片のそれぞれに関連する難読化されたレコードロケータ、およびそれぞれの前記複数の断片が格納された少なくとも前記第1の複数の格納場所を含む、請求項51に記載の方法。

請求項53

前記データマップ内に含まれない前記データオブジェクトの取り出しおよび再構成に必要とされる前記情報の一部を動的に取り出すよう、前記1つまたは複数の計算が実行される、請求項51に記載の方法。

請求項54

前記1つまたは複数の計算が、前記データオブジェクトを複数の断片に分解するため適用される分解機能の決定、前記複数の断片のそれぞれに関連する難読化されたレコードロケータの決定、前記複数の断片のそれぞれの暗号化に使用される暗号化鍵の計算、およびそれぞれの前記複数の断片が格納される少なくとも前記第1の複数の格納場所の識別を含む、請求項51に記載の方法。

請求項55

前記データマップの内容の変更が、前記データオブジェクトの取り出しおよび再構成に必要とされる前記情報の前記第2の部分を動的に取得するため実行されるのに必要とされる計算の範囲を変え、前記データマップの前記内容が、ユーザ名、ユーザパスフレーズ、現在のセキュリティモデル、前記データオブジェクトのタイプ、前記データオブジェクトのサイズ、1つまたは複数のセキュリティ必要条件、および1つまたは複数の性能必要条件のうちの1つまたは複数に基づき変更される、請求項51に記載の方法。

請求項56

第1のデータストアおよび第2のデータストアと、前記第1のデータストア内に格納されたユーザのデータを取り出す要求を送信するよう構成されたクライアント装置と、前記第1のデータストア内に格納された前記ユーザのデータから分離した前記第2のデータストアにユーザ認証情報およびデータストア認証情報を格納し、前記クライアント装置から前記第1のデータストア内に格納されたユーザのデータを取り出す前記要求を受信し、ユーザのデータを取り出す前記要求に応え、前記第2のデータストアから、前記クライアント装置のユーザに関連するユーザ認証情報、および前記第1のデータストアに関連するデータストア認証情報を取り出し、前記クライアント装置の前記ユーザの前記ユーザ認証情報、および前記第1のデータストアのデータストア認証情報を使用して前記第1のデータストアからユーザのデータを取り出し、前記ユーザのデータを前記クライアント装置に提供するよう構成されたセキュア鍵プラットフォームとを備える、認証情報および暗号化鍵を格納および管理するシステム。

請求項57

前記セキュア鍵プラットフォームが、ブラウザのタイプ、プラグインハードウェア設定、および位置特定のうちの1つまたは複数を検証および記録することによることを含んで前記クライアント装置を登録するようさらに構成された、請求項1に記載のシステム。

請求項58

セキュア鍵プラットフォームが、1つまたは複数の困難な質問を出し、前記1つまたは複数の困難な質問への応答を格納することにより、前記クライアント装置を登録するようさらに構成された、請求項2に記載のシステム。

請求項59

前記クライアント装置が前記セキュア鍵プラットフォームにログインするよう試みるようにさらに構成され、前記セキュア鍵プラットフォームが、前記ユーザ認証情報および前記データストア認証情報を取り出し、前記ユーザ認証情報およびデータストア認証情報を用いて前記第1のデータストアからユーザのデータを取り出す前に、前記クライアント装置を認証するようさらに構成された、請求項1に記載のシステム。

請求項60

前記セキュア鍵プラットフォームが、前記クライアント装置の正常な認証に応え、前記ユーザ認証情報を自動的に取り出すよう構成された、請求項4に記載のシステム。

請求項61

前記セキュア鍵プラットフォームが、前記ユーザにより提供されるユーザ名、前記ユーザにより提供されるパスワード、前記ユーザにより提供される少なくとも1つの困難な質問への返答、前記クライアント装置のブラウザのタイプ、前記クライアント装置のプラグイン、前記クライアント装置のハードウェア設定、前記クライアント装置の位置特定、および前記クライアント装置が前記ログインを試みるインターネットプロトコル(IP)アドレスのうちの1つまたは複数に基づき前記クライアント装置を認証するよう構成された、請求項4に記載のシステム。

請求項62

前記ユーザ認証情報が第1のパスフレーズを有する、請求項1に記載のシステム。

請求項63

前記第1のデータストア内に格納された前記ユーザのデータが、前記第1のパスフレーズを用いて暗号化される、請求項7に記載のシステム。

請求項64

第1のパスフレーズが第2のパスフレーズへのアクセスを制御し、前記第1のデータストア内に格納された前記ユーザのデータが、前記第2のパスフレーズを用いて暗号化される、請求項7に記載のシステム。

請求項65

前記ユーザのデータを複数のセグメントに分解し、前記分解されたユーザのデータの前記複数のセグメントを、前記第1のデータストアを含む複数のデータストアにわたり格納するよう構成されたセキュアオブジェクトプラットフォームをさらに備える、請求項1に記載のシステム。

請求項66

第1の装置と第2の装置の間のデータストリーミングのため通信確立することと、共有鍵を確立することと、前記第1の装置と前記第2の装置の間で前記共有鍵を交換することと、前記共有鍵を用いて前記第1の装置によりデータセットを暗号化することと、前記共有鍵を用いて前記第2の装置により前記データセットを復号することと、前記共有鍵が再生成されるべきかどうかを判断するために鍵再生成基準を評価することと、前記共有鍵が再生成されるべきであるという判断に応え、新しい共有鍵を生成し、前記新しい共有鍵を用いて前記第1の装置により次のデータセットを暗号化することとを含む、装置間の認証された通信方法

請求項67

共有鍵の前記確立が、暗号化アルゴリズムパラメータおよび暗号化アルゴリズムについてのシードの提供を含む、請求項1に記載の方法。

請求項68

前記共有鍵の前記交換が、複数の鍵交換方法統合を含む、請求項1に記載の方法。

請求項69

鍵交換方法および鍵交換頻度のうちの少なくとも1つを動的に変えることをさらに含む、請求項3に記載の方法。

請求項70

鍵交換方法および鍵交換の頻度のうち少なくとも1つが、前記第1の装置または前記第2の装置の性能の必要条件およびセキュリティ脅威ベルに基づき動的に変えられる、請求項4に記載の方法。

請求項71

鍵再生成基準が、共有鍵が再生成されるべきかどうか判断するために評価される、請求項1に記載の方法。

請求項72

鍵再生成基準が、利用可能な暗号化アルゴリズムおよび前記暗号化アルゴリズムについての特定のパラメータを識別する、請求項6に記載の方法。

請求項73

鍵再生成基準が満たされるまで共有鍵が再生成されるべきときを示す状況の監視をさらに含む、請求項6に記載の方法。

請求項74

前記新しい共有鍵の生成が、前記共有鍵についての新しい暗号化アルゴリズムパラメータの提供を含む、請求項1に記載の方法。

請求項75

セキュア鍵の使用、およびデータセットの鍵ローテーションの割合の最大化により、高度なセキュリティを提供することをさらに含む、請求項1に記載の方法。

請求項76

通信インタフェースと、第1の装置と第2の装置の間のデータストリーミングのため通信を確立し、共有鍵を確立し、前記第1の装置と前記第2の装置の間で前記共有鍵を交換し、前記共有鍵を用いて前記第1の装置によりデータセットを暗号化し、前記第2の装置が前記共有鍵を用いて前記データセットを復号し、前記共有鍵が再生成されるべきかどうかを判断するために鍵再生成基準を評価し、前記共有鍵が再生成されるべきであるという判断に応え、新しい共有鍵を生成し、前記新しい共有鍵を用いて前記第1の装置により次のデータセットを暗号化するよう構成されたプロセッサとを備える、装置間の認証された通信システム。

請求項77

前記プロセッサが、暗号化アルゴリズムパラメータおよび暗号化アルゴリズムについてのシードの提供により共有鍵を確立するようさらに構成された、請求項11に記載のシステム。

請求項78

前記プロセッサが、前記共有鍵の交換のため複数の鍵交換方法を統合するようさらに構成された、請求項11に記載のシステム。

請求項79

前記プロセッサが、鍵交換方法および鍵交換の頻度のうち少なくとも1つを動的に変えるようさらに構成された、請求項13に記載のシステム。

請求項80

前記鍵交換方法および鍵交換の頻度のうち少なくとも1つが、前記第1の装置または前記第2の装置の性能の必要条件およびセキュリティ脅威レベルに基づき動的に変えられる、請求項14に記載のシステム。

請求項81

前記共有鍵が再生成されるべきかどうか判断するために、鍵再生成基準を評価するようさらに構成された、請求項11に記載のシステム。

請求項82

鍵再生成基準が、可能な暗号化アルゴリズムおよび前記暗号化アルゴリズムについての特定のパラメータを識別する、請求項16に記載のシステム。

請求項83

前記プロセッサが、鍵再生成基準が満たされるまで前記共有鍵が再生成されるべきときを示す状況を監視するようさらに構成された、請求項16に記載のシステム。

請求項84

前記プロセッサが、前記共有鍵の生成のための新しい暗号化アルゴリズムパラメータを提供するようさらに構成された、請求項11に記載のシステム。

請求項85

前記プロセッサが、セキュア鍵の使用、およびデータセットのための鍵ローテーションの割合の最大化により、高度なセキュリティを提供するようさらに構成される、ことをさらに含む、請求項11に記載のシステム。

技術分野

0001

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

背景技術

0002

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

0003

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

0004

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

0005

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

0006

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

0007

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

0008

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

0009

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

0010

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

0011

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

0012

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

0013

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

0014

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

0015

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

0016

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

0017

データの暗号化速度
現在、性能(データが暗号化可能な速度)を上げるいくつかのアプローチがある。1つのアプローチは、ハードウェアベースの高速化を用いることである。128ビットおよび256ビットのAESサイファを、AES−NIハードウェアの暗号化を通して、(IntelおよびAMDプロセッサ上で利用可能な場合)4から8倍加速可能である。セキュリティを犠牲にして、鍵のサイズを減少させることもまた可能である。256ビットの鍵のAESは、128ビットの鍵のAESより約40%遅い。他の戦略は、20%の速度改善が可能なBlowfishのような別の暗号化アルゴリズムを使用することである。

0018

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

0019

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

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

図面の簡単な説明

0033

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

実施例

0034

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

0035

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

0036

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

0037

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

0038

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

0039

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

0040

ユーザは、イメージビューア112a、インターネットブラウザアプリケーションに表示されるフォーム112b、またはポータブル電子装置110c上で実行するアプリケーション112cにより表示されるフォーム110cのような1つまたは複数のフォーム112a〜112cを完成する装置110を通して、通信インタフェース104と相互作用可能である。フォームをまた、HTML5−CSS3またはサーバ106とインタフェース接続するアプリケーション112cを介してブラウザウィンドウに直接、またはサーバ106により生成され装置110c上に表示される1つまたは複数のグラフィカルユーザインタフェース(GUI)114を通して表示することが可能である。本明細書で示されたように、フォームをユーザの装置上に直接、ブラウザ拡張、アドオンブラウザアプリケーション、またはサードパーティサービスまたはアプリケーションと相互作用するアプリケーションプログラミングインタフェースAPI)を介して取り込み可能である。

0041

図3は、システムの1つの構成のセキュリティプロトコルを示すシステム系統図の例示である。ユーザ116は前述の種々の装置110を介してシステムにアクセス可能であり、それらはインターネット118により通信インタフェース104と接続される。プライバシーおよびセキュリティを確実にするようにユーザプロファイル情報の保護を高めるため、複数のタイプ、場所、装置、サーバ、などを種々のファイアウォール間に分離して使用可能である。ユーザに最初に通信インタフェース104のパブリック対面ホームサイト104aとみなされる基本情報を示すGUIを表示することが可能であり、それはまた最初のファイアウォール120aにより保護される。最初のファイアウォール120aはシステム全体のセキュリティを提供可能であり、インタフェースのユーザ・インタフェースおよび体験レベル(UI/UX)104bにアクセスするのを可能にする。UI/UX104bは、フォームおよびアプリケーション出力データストア108aと接続されたwebおよびインタフェースサーバ106fを含む。第2のファイアウォール120bは、データアクセス層104cとして知られる通信インタフェースの第3の区画を保護可能である。データアクセス層104cは、データストアサーバ106hと接続されたビジネスモデルロジックアプリケーションサーバ106gを有することが可能であり、ビジネスモデルロジックアプリケーションサーバ106gを、セキュアクライアントデータエレメントおよびヒストリカルアーカイブデータストア108bならびにマッピングされた入力フォームデータストア108cを管理するよう構成可能である。分離したIDおよび認証サーバ106iもまた、データアクセス層104c内に包含することが可能であり、サーバ106iは識別情報データストアサーバ106jに接続され、サーバ106jはセキュアクライアントIDエレメントデータストア108dを管理可能である。

0042

図4は、情報取込ユニット106cのようなデータストア管理ソフトウェアを通してセキュアクライアントIDエレメントデータストア108dおよびセキュアクライアントデータエレメントデータストア108b内に格納された情報にアクセスすることにより、フォーム404のフィールド402を取り込むステップの1つの実施形態を示し、そこでは、分離したクライアント識別情報データストアおよびクライアント情報データストアが、電子フォームに取り込むのに必要とされる情報を取得するのに使用される。

0043

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

0044

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

0045

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

0046

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

0047

図6は、データストアテーブル602とシステム内に入力されたフォームから収集されたフィールド情報の1つの実施形態を示す。情報がサーバ上で作動しているフォームから送信されるとき、情報はこのテーブル内に格納される。サーバから「引き出され」フォームに適用されるとき、情報はこのテーブルからくる。フォームは図1で示されるようなフォームであることが可能で、フォームフィールドがすでに入力された値を有するように、ユーザが完成しておくことが可能である。図6に示されるように、フォーム上のそれぞれのフィールド604には、他のフィールドから区別するための一意の数字識別子606(customerFieldDefaults_Id)が提供される。右の2列に示すように、それぞれのフィールドはさらに所定のフィールド名608(fieldName)およびフィールド値610(fieldValue)が与えられる。フィールド名はフォーム自体で暗号化された名であってもよく、ウェブサイト上または元のフォームを生成したプログラマに基づいたフィールド名をすでに識別したフィールド名メタデータを持つ電子フォーム上にあれば、フォームから抽出可能である。(利用可能であれば)フィールド値は、明瞭にフィールドの内容に対応する。(名−値のペアとして知られる)フィールド名およびフィールド値の間の関連は、内容の分類およびユーザプロファイルの形成に重要である。

0048

図7はドキュメントライブラリテーブル702を示し、システム内に格納されたドキュメント704のリストを格納する。ドキュメントのそれぞれには、ドキュメント識別情報706(documen_id)、ドキュメントタイトル708、および関連するデータベース内のドキュメントへのパス710が提供されている。図8はデータベーステーブル802を示し、図7のドキュメントライブラリテーブル内のそれぞれのドキュメントのフィールド名804(fieldName)を格納する。それぞれのフィールドにデフォルト値を設定する選択肢があることに留意されたい。例えば、今年の税金フォームは2013年のデフォルト記入を有してもよい。commonFieldName806は、fieldNameが不明瞭または元のフォーム設計者がうまく名付けていないケースのfieldName804の人間が可読なバージョンである。commonFieldName806は、システムがそのフィールドを一般的な顧客の保管場所で見出されるフィールド名と迅速にマッチングするのを可能にする。commonFieldName806は、より信頼性のある決定的なフィールドのマッピングとユーザプロファイルで見出されるフィールド名を提供する。

0049

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

0050

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

0051

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

0052

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

0053

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

0054

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

0055

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

0056

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

0057

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

0058

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

0059

第1の解決法は、ドキュメントのフィールドを調べることと「最も適合する」フィールド名に関連付けおよび推定することを含む。1つの実施形態では、これはフォームラベルとページ上のフィールドボックスを関連付けるウェブサイトフィールドコードの「for」属性の使用により完成される。例えば、紛らわしい名前およびフィールドを「First Name」に対するラベルと関連付けが可能なように、不明瞭な名前の「box00455x」のフィールドボックスを「labelfor=「firstname」と暗号化してもよい。

0060

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

0061

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

0062

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

0063

別の実施形態では、異なるフォームは同一のユーザフィールド名を参照する異なる方法を有することが可能である。ドキュメントは1つの方法でフィールドを名付けることが可能であるが、他のドキュメントは同一のフィールドを他の方法で名付けることが可能である。例えば、第1のドキュメントは「First Name」と名付けられたフィールドを持つことができる一方で、第2のドキュメントは「fname」と名付けられたフィールドを持ってもよく、さらに第3のドキュメントは「firstname」と名付けられたフィールドを持ち、これらの全ては同一のフィールドを指し、同一の値または内容を有するはずである。この関連を可能にするよう、システムデータストア内のユーザのFieldDefaultsテーブルに、「userFieldCollections」レコードが提供され、それは同義の種々のフィールド名をリストする。

0064

例えば、経時的にそれぞれ同一の値を持つデータストア内に格納された複数のフィールドがある。例えば、これらの3つの「firstname」フィールドが全て「Arthur」の値を持つと仮定する。図2のフィールド比較ユニット106dにより実行されるバックグラウンドプロセスは、「Arthur」の値を持つ他のフィールドについてデータストアを周期的に調べ、それらのフィールドを重複として「userFieldCollections」テーブル内で識別することが可能である。このテーブルは、それらの共通の内容に基づき同義の種々のフィールド名を捕捉する。これらのフィールドのいずれか1つがその後のフォームに遭遇するとき、適切な値の「Arthur」が使用される。

0065

第2のアプローチで、システムは「userFieldCollections」テーブルを一般的にグループ化したフィールド値で予めセット可能である。例えば、「firstname」と呼ばれるフィールドに最初に遭遇するとき、「firstname」および「FirstName」がそのテーブル内に格納される。「FirstName」と呼ばれるその後のフィールドに遭遇するとき、その値はすでに格納され、「userFieldCollections」テーブルを通して容易に位置付けられるであろう。

0066

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

0067

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

0068

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

0069

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

0070

ユーザの情報を、個人情報安全区域として知られるそれ自体のデータストアの場所、およびその場所の「customerFieldDefaults」と呼ばれるテーブル内に格納可能である。customerFieldDefaultsテーブルは、通常ユーザの最新の情報を有する。

0071

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

0072

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

0073

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

0074

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

0075

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

0076

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

0077

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

0078

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

0079

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

0080

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

0081

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

0082

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

0083

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

0084

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

0085

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

0086

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

0087

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

0088

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

0089

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

0090

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

0091

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

0092

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

0093

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

0094

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

0095

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

0096

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

0097

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

0098

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

0099

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

0100

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

0101

同時係属中の米国特許出願シリアル番号第14/970,466号(’466出願)の開示は参照により全体を記載し、’294出願のプロセスを通った回折されたデータ回復システムおよび方法を説明したように本明細書に組み込まれる。図15は’466出願の図1の複製であり、その中に記載された回折されたデータ回復を実行するシステムを示す。図15を参照して記載のように、回折されたデータ回復は、ローカル、またはエンドポイント110にローカル接続されている記憶装置または場所140を含むことができるが、その中に記載されたプロセスは通常、エンドポイント110とサーバ120および180の間にリンクを適用しない。

0102

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

0103

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

0104

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

0105

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

0106

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

0107

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

0108

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

0109

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

0110

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

0111

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

0112

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

0113

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

0114

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

0115

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

0116

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

0117

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

0118

ブロック1815で第1の装置上のデータセットを、共有鍵を用いて暗号化してもよく、ブロック1820で第1の装置はその暗号化されたデータを第2の装置へ送信してもよい。ブロック1825で第2の装置は、共有鍵を用いてデータセットを復号してもよい。ブロック1830で、鍵が再生成されるべきどうかを示す鍵再生成基準を決定してもよい。ブロック1835で、鍵再生成基準をそれぞれのデータセットについて評価してもよい。ブロック1840で、鍵再生成基準を満たすかどうか判断してもよい。鍵再生成基準が満たされないという判断(1840−N)に応え、ブロック1845で鍵が再生成されるべきときを示す状況を、ブロック1840で鍵再生成基準を満たすまで監視してもよい。鍵再生成基準が満たされるという判断(1840−Y)に応え、ブロック1850で次の鍵のための新しい暗号化アルゴリズムパラメータを生成してもよく、ブロック1810で方法を続けてもよい。鍵再生成基準は、利用可能な暗号化アルゴリズムおよびその暗号化アルゴリズムについての特定のパラメータを識別してもよい。

0119

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

0120

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

0121

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

0122

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

0123

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

0124

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

0125

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

0126

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

0127

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

0128

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

0129

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

0130

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

0131

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

0132

本開示の種々の態様によると、鍵のアクセス要求を制御するのに動的表現を使用してもよい。鍵は、鍵の機能を制限または制御するためのブール表現のあらゆる組み合わせを有してもよい。例えば鍵のアクセス表現を、(Alice AND(Bob OR Carl))と記載し、BobまたはCarlのどちらかと協調してなされる場合だけ、Aliceがファイルのロックを外すのを可能にしてもよい。複合鍵はまた、ユーザ名だけではなく地理位置時刻およびハッシュチェックサムを含む種類に制限がない他の条件を含んでもよい。例えば、(Alice AND(Bob OR Carl)ANDACCESSTIME ISEQUAL BUSINESSHOURS)は、営業時間のみの制限を追加してもよい。さらに、鍵アクセスの表現は動的条件を包含してもよく、それは(例えば脅威レベルが高いかどうかだがそれらに限定されない)外部の状況に基づき変化しうる。例えば、(Alice AND(Bob OR Carl)AND SECURITYLEVEL IS EQUAL(NORMAL OR LOW))は、セキュリティ状況が正常または低レベルであるときのみアクセスを可能にする。これらの表現は、ハッカーアタック中のときのように迅速な状況の変化でさえ、データを自動的に安全に保つよう高精度の反応アクセス制御を可能にする。本開示の範囲から逸脱することなく他の組み合わせを使用しうることを、当業者は理解するだろう。

0133

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

0134

ブロック2225で、アクセス表現および/または外部の状況が満たされていない(2220−N)という判断に応え、セキュリティ鍵を拒絶し、データアクセスを拒否してもよい。ブロック2230で、アクセス表現および/または外部の状況が満たされている(2220−Y)という判断に応え、アクセス鍵を承認し、データアクセスを許可してもよい。

0135

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

0136

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

0137

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

0138

ブロック2330で、アクセス制限/状況が満たされないという判断(2325−N)に応え、データへのアクセスを拒否してもよい。ブロック2335で、アクセス制限/状況が満たされるという判断(2325−Y)に応え、データへのアクセスを許可してもよい。

0139

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

0140

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

0141

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

0142

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

0143

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

0144

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

0145

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

0146

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

0147

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

0148

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

0149

ブロック2650で、データが検索可能であるべきであるという判断(2630−Y)に応え、システムはシステム上のリモートサーバドライブに加速アクセスレコード(AAR)を追加してもよい。ブロック2660で、データが検索されるとき、暗号化された内容の検索のためAARにアクセスしてもよい。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ