(57)【要約】  データを処理する方法は、少なくとも１つのプロセッサが、少なくとも１つの入力データオブジェクトと、少なくとも１つの入力データオブジェクトに対して実施されるべき少なくとも１つの変成コマンドとを与えるデータストレージユニットにアクセスすることを含む。少なくとも１つの変成コマンドは、データストレージユニットに記憶されるべき少なくとも１つの出力データオブジェクトを生成するために、少なくとも１つの入力データオブジェクトに対して順方向モードで動作する。
2019537769.tif 000002
【特許請求の範囲】
【請求項１】
データを処理する方法であって、
少なくとも１つのプロセッサが、少なくとも１つの入力データオブジェクトと、前記少なくとも１つの入力データオブジェクト上で実施されるべき少なくとも１つの変成コマンドとを与えるデータストレージユニットにアクセスすることと、
前記データストレージユニットに記憶されるべき少なくとも１つの出力データオブジェクトを生成するために、前記少なくとも１つの入力データオブジェクトに対して順方向モードで前記少なくとも１つの変成コマンドを動作させることと
を備える方法。
【請求項２】
前記少なくとも１つの入力データオブジェクトを生成するために、前記少なくとも１つの出力データオブジェクトに対して逆方向モードで前記少なくとも１つの変成コマンドを動作させることをさらに備える、請求項１に記載の方法。
【請求項３】
前記逆方向モードで動作する前記少なくとも１つの変成コマンドが、第２の少なくとも１つの出力データオブジェクトを生成するために、前記順方向モードで前記少なくとも１つの入力データオブジェクトを処理することと、検証結果を生成するために、前記第１の前述の少なくとも１つの出力データオブジェクトを前記第２の少なくとも１つの出力データオブジェクトと比較することとを備える、請求項１に記載の方法。
【請求項４】
前記順方向モードで動作する前記少なくとも１つの変成コマンドが、少なくとも１つの出力データオブジェクトを生成するために、前記少なくとも１つの入力データオブジェクトを処理するための少なくとも１つの属性を要求する、請求項１に記載の方法。
【請求項５】
前記逆方向モードで動作する前記少なくとも１つの変成コマンドが、前記少なくとも１つの入力データオブジェクトを生成するために、前記少なくとも１つの出力データオブジェクトを処理するための前記少なくとも１つの属性を要求する、請求項４に記載の方法。
【請求項６】
前記少なくとも１つのプロセッサが、少なくとも１つの出力データオブジェクトを生成するために、前記少なくとも１つの入力データオブジェクトを処理するための、前記順方向モードで動作する前記少なくとも１つの変成コマンドによって要求される少なくとも１つの属性を発生する、請求項４に記載の方法。
【請求項７】
前記逆方向モードで動作する前記少なくとも１つの変成コマンドが、検証結果を備える少なくとも１つの出力データオブジェクトを生成するために、前記少なくとも１つの入力データオブジェクトを処理するための前記少なくとも１つの属性を要求する、請求項５に記載の方法。
【請求項８】
前記少なくとも１つのプロセッサが、前記少なくとも１つの出力データオブジェクトを生成するために、前記少なくとも１つの入力データオブジェクトを処理するための特定の形式の前記少なくとも１つの属性を要求する前記順方向モードで動作する前記少なくとも１つの変成コマンドによる使用のために提示された、前記少なくとも１つの属性の前記形式を妥当性確認することをさらに備える、請求項４に記載の方法。
【請求項９】
前記少なくとも１つのプロセッサが、前記少なくとも１つの入力データオブジェクトを生成するために、前記少なくとも１つの出力データオブジェクトを処理するための特定の形式の少なくとも１つの属性を要求する前記逆方向モードで動作する前記少なくとも１つの変成コマンドによる使用のために提示された、前記少なくとも１つの属性の前記形式を妥当性確認することをさらに備える、請求項８に記載の方法。
【請求項１０】
前記少なくとも１つの変成コマンドが、前記データストレージユニットを、前記第１のデータストレージユニットとは異なる構造を有する第２のデータストレージユニットにコンバートする、請求項１に記載の方法。
【請求項１１】
前記少なくとも１つの変成コマンドがｍｏｂｉｕｓ変成である、請求項１０に記載の方法。
【請求項１２】
前記データストレージユニットが、前記データストレージユニットに記憶されるべき前記少なくとも１つの出力データオブジェクトを生成するために、前記少なくとも１つの入力データオブジェクトに対して順方向モードで動作する論理順序で複数の変成コマンドを与えることをさらに備える、請求項１に記載の方法。
【請求項１３】
前記少なくとも１つの入力データオブジェクトを生成するために、前記少なくとも１つの出力データオブジェクトに対して逆方向モードでの論理順序で前記複数の変成コマンドを動作させることをさらに備える、請求項１２に記載の方法。
【請求項１４】
前記データストレージユニットが、第２のデータストレージユニット中の少なくとも１つの入力データオブジェクトとして与えられ、
少なくとも１つのプロセッサが、前記第２のデータストレージユニットを処理するために前記第２のデータストレージユニットにアクセスする、
請求項１に記載の方法。
【請求項１５】
論理順序での前記複数の変成コマンド内の２つまたはそれ以上の変成コマンドが依存グループを形成し、
前記依存グループ内の各変成コマンドが、同じ順序で処理され、前記順方向モードまたは前記逆方向モードで動作する、
請求項１２に記載の方法。
【請求項１６】
前記順方向モードで動作する、論理順序での前記複数の変成コマンド内の１つまたは複数の変成コマンドが、前記少なくとも１つの出力データオブジェクトを生成するために、前記少なくとも１つの入力データオブジェクトを処理するための１つまたは複数の対応する属性を要求する、請求項１２に記載の方法。
【請求項１７】
前記逆方向モードで動作する、論理順序での前記複数の変成コマンド内の前記１つまたは複数の変成コマンドが、前記少なくとも１つの入力データオブジェクトを生成するために、前記少なくとも１つの出力データオブジェクトを処理するための前記１つまたは複数の対応する属性を要求する、請求項１６に記載の方法。
【請求項１８】
前記少なくとも１つのプロセッサが、前記少なくとも１つの出力データオブジェクトを生成するために、前記順方向モードで動作し、前記少なくとも１つの入力データオブジェクトを処理するための１つまたは複数の対応する属性を要求する前記１つまたは複数の変成コマンドによる使用のための前記１つまたは複数の対応する属性を生成することをさらに備える、請求項１２に記載の方法。
【請求項１９】
前記少なくとも１つのプロセッサが、前記少なくとも１つの出力データオブジェクトを生成するために、前記少なくとも１つの入力データオブジェクトを処理するための各々特定の形式の前記１つまたは複数の属性を要求する前記順方向モードで動作する前記１つまたは複数の変成コマンドによる使用のために提示された、前記１つまたは複数の対応する属性の前記形式を妥当性確認することをさらに備える、請求項１６に記載の方法。
【請求項２０】
前記少なくとも１つのプロセッサが、前記少なくとも１つの入力データオブジェクトを生成するために、前記少なくとも１つの出力データオブジェクトを処理するための各々特定の形式の前記１つまたは複数の対応する属性を要求する前記逆方向モードで動作する前記１つまたは複数の変成コマンドによる使用のために提示された、前記１つまたは複数の対応する属性の形式を妥当性確認することをさらに備える、請求項１９に記載の方法。
【請求項２１】
論理順序での前記複数の変成コマンド内の少なくとも１つの変成コマンドが、前記第１のデータストレージユニットを、前記第１のデータストレージユニットとは異なる構造を有する第２のデータストレージユニットにコンバートする、請求項１２に記載の方法。
【請求項２２】
論理順序での前記複数の変成コマンド内の最後の変成コマンドがｍｏｂｉｕｓ変成である、請求項２１に記載の方法。
【請求項２３】
前記データストレージユニットが、第２のデータストレージユニット中の少なくとも１つの入力データオブジェクトとして与えられ、
少なくとも１つのプロセッサが、前記第２のデータストレージユニットを処理するために前記第２のデータストレージユニットにアクセスする、
請求項１２に記載の方法。
【請求項２４】
前記逆方向モードで動作する論理順序での前記複数の変成コマンド内の少なくとも１つの変成コマンドが、検証結果を備える少なくとも１つの出力データオブジェクトを生成するために、前記少なくとも１つの入力データオブジェクトを処理する、請求項１２に記載の方法。
【請求項２５】
前記逆方向モードで動作する論理順序での前記複数の変成コマンド内の少なくとも１つの変成コマンドが、検証失敗を生成し、論理順序での前記複数の変成コマンドの処理を終了する、請求項２４に記載の方法。
【請求項２６】
ネットワークを介して結合された複数のコンピュータの間の通信の方法であって、
前記複数のコンピュータの各々が請求項１２に記載の方法を使用してメッセージを処理すること
を備える方法。
【請求項２７】
第１のメッセージ内の論理順序での前記複数の変成コマンドが、第２のメッセージ内の論理順序での前記複数の変成コマンドとは異なる、請求項２６に記載の方法。
【請求項２８】
データを処理する方法であって、
少なくとも１つのプロセッサが、少なくとも１つの入力クリアテキストデータオブジェクトと０個以上の入力鍵とを備えた、１つまたは複数の鍵を要求する暗号関数を動作させること
を備え、ここにおいて、
入力鍵を備えていない前記暗号関数が、暗号化モードで動作し、少なくとも１つの出力サイファテキストデータと、要求される適切に形成された鍵の発生されたセットとを生成するために、前記少なくとも１つの入力クリアテキストデータを暗号化するための前記適切に形成された鍵の前記要求されるセットを発生し、
入力鍵の部分セットを備えた前記暗号関数が、暗号化モードで動作し、少なくとも１つの出力サイファテキストデータと、鍵の組み合わせられたセットとを生成するために、適切に形成された鍵の要求される欠落したセットを発生し、前記少なくとも１つの入力クリアテキストデータを暗号化するためにそれらを論理順序で入力鍵の前記部分セットと組み合わせ、
入力鍵の要求されるセットを備えた前記暗号関数が、暗号化モードで動作し、少なくとも１つの出力サイファテキストデータを生成するために、要求される入力鍵の前記妥当性確認されたセットを用いて前記少なくとも１つの入力クリアテキストデータを暗号化するための各入力鍵の構造を妥当性確認し、
入力鍵の前記要求されるセットを備えた、前記暗号関数が、解読モードで動作し、前記少なくとも１つの入力クリアテキストデータを生成するために、要求される入力鍵の前記妥当性確認されたセットを用いて前記少なくとも１つの出力サイファテキストデータを解読するための各要求される入力鍵の前記構造を妥当性確認する、
方法。
【請求項２９】
前記暗号関数が、少なくとも１つの暗号ライブラリからの１つまたは複数の鍵を要求する少なくとも１つのプリミティブ暗号関数にアクセスするラッパー関数である、請求項２８に記載の方法。
【請求項３０】
鍵発生サービスまたは関数にアクセスすることによって、適切に形成された鍵の前記要求されるセットを発生することをさらに備える、請求項２８に記載の方法。
【請求項３１】
少なくとも１つのデータオブジェクトに対して動作するための１つまたは複数の鍵を要求する特定の暗号方法およびモードの選好を示すことをさらに備える、請求項２９に記載の方法。
【請求項３２】
データを折り畳む方法であって、
少なくとも１つのプロセッサが、少なくとも１つの論理演算を使用して少なくとも１つの出力データオブジェクトを生成するために少なくとも１つの入力データオブジェクトを処理することと、ここで、前記少なくとも１つの論理演算が前記少なくとも１つの出力データオブジェクト内に前記少なくとも１つの論理演算の少なくとも１つのエッセンスをカプセル化し、
少なくとも１つのプロセッサが、前記少なくとも１つの出力データオブジェクト内にカプセル化された前記少なくとも１つの論理演算の前記少なくとも１つのエッセンスを使用して、前記少なくとも１つの入力データオブジェクトを生成するために、前記少なくとも１つの出力データオブジェクトを処理することと
を備える方法。
【請求項３３】
前記少なくとも１つの論理演算が変成である、請求項３２に記載の方法。
【請求項３４】
前記少なくとも１つの出力データオブジェクトがコンピューティング環境において記憶可能である、請求項３２に記載の方法。
【請求項３５】
前記少なくとも１つの出力データオブジェクトが別のコンピュータプロセスに送信可能である、請求項３２に記載の方法。
【請求項３６】
少なくとも１つの入力データオブジェクトとして、前記少なくとも１つの出力データオブジェクトを、データを折り畳む少なくとも１つのプロセッサに与えることをさらに備える、請求項３２に記載の方法。
【請求項３７】
ネットワークを介して結合された複数のコンピュータの間の通信の方法であって、
前記複数のコンピュータの各々が請求項３２に記載の方法を使用してメッセージを処理すること
を備える方法。
【請求項３８】
第１のメッセージ内の前記少なくとも１つの論理演算の前記少なくとも１つのエッセンスが、第２のメッセージ内の前記少なくとも１つの論理演算の前記少なくとも１つのエッセンスとは異なる、請求項３７に記載の方法。
【請求項３９】
データを記憶するためのロックノードであって、
各々が複数の１次鍵のうちの１つに対応する、複数の鍵マップを与える入力セクションと、前記複数の１次鍵が、それぞれ、前記入力セクションに適用され、各鍵マップが少なくとも１つのメイン鍵を含み、
前記入力セクションに適用された前記１次鍵に対応する前記メイン鍵に対する論理演算から、導出された鍵を生成する変数ロックセクションと、
前記導出された鍵に応答して前記データを生成する出力セクションと
を備えるロックノード。
【請求項４０】
保護されたデータストレージユニットであって、
データを記憶するための複数のロックノードであって、
各々が複数の１次鍵のうちの１つに対応する、複数の鍵マップを与える入力セクションと、前記複数の１次鍵が、それぞれ、前記入力セクションに適用され、各鍵マップが少なくとも１つのメイン鍵を含み、
前記入力セクションに適用された前記１次鍵に対応する前記メイン鍵に対する論理演算から、導出された鍵を生成する変数ロックセクションと、
前記導出された鍵に応答して前記データを生成する出力セクションと
を備える、データを記憶するための複数のロックノードと、
少なくとも１つのアクセス属性鍵をさらに含み得る指定された１次鍵の各々のための鍵マップを有する前記複数のロックノードの鍵穴ロックノードであって、前記属性鍵が、前記保護されたデータストレージユニット内の前記対応する１次鍵に基づいてロールベース暗号アクセス制御を与える、鍵穴ロックノードと、および、
前記ロックノードのうちの別のもののための指定された１次鍵として働き得る出力鍵を与える前記ロックノードのうちの少なくとも１つと
を備える保護されたストレージユニット。
【請求項４１】
各鍵マップが少なくとも１つのアクセス鍵を含み、前記入力セクションが、さらに、前記データに対する演算許可を定義する少なくとも１つのアクセスロール鍵を与えるために前記少なくとも１つのアクセス鍵を利用し、ここにおいて、前記アクセスロール鍵が、前記特定の鍵マップを生じる前記指定された１次鍵に関連する許可に基づく、請求項３９に記載のロックノード。
【請求項４２】
前記入力セクションが別のロックノードのための少なくとも１つのアクセス鍵をも与える、請求項４０に記載のロックノード。
【請求項４３】
少なくとも１つの鍵マップが少なくとも１つの階層鍵を含み、前記鍵マップを含む前記ロックノードとは異なる少なくとも１つのロックノードの前記入力セクションは、前記少なくとも１つの階層鍵が前記少なくとも１つの異なるロックノードのための異なる鍵マップを与えることを可能にする、請求項４０に記載のストレージユニット。
【請求項４４】
前記少なくとも１つの階層鍵と、前記ストレージユニット中の前記ロックノードの前記入力セクションとは、前記ストレージユニット内のどのロックノードが前記特定の指定された１次鍵のためにアクセス可能であるかを制御する、請求項４３に記載のストレージユニット。
【請求項４５】
前記ストレージユニットが、前記ストレージユニットを伴うイベントのログを記憶する、請求項４０に記載のストレージユニット。
【請求項４６】
前記ログが、暗号化された形式で記憶される、請求項４５に記載のストレージユニット。
【請求項４７】
パラメータが、どのイベントがロギングされ、どのイベントがロギングされないかを制御する、請求項４５に記載のストレージユニット。
【請求項４８】
パラメータが、前記ログにおいて与えられたイベントの詳細のレベルを制御する、請求項４５に記載のストレージユニット。
【請求項４９】
前記ストレージユニットが、前記データストレージユニット中の前記データのリビジョンの履歴を記憶する、請求項４０に記載のストレージユニット。
【請求項５０】
前記履歴が、暗号化された形式で記憶される、請求項４９に記載のストレージユニット。
【請求項５１】
パラメータは、リビジョンが前記履歴においてどのように与えられるかを制御する、請求項４９に記載のストレージユニット。
【請求項５２】
前記履歴が各リビジョンのソースをも含む、請求項４９に記載のストレージユニット。
【請求項５３】
データを処理する方法であって、
少なくとも１つのプロセッサが、データストレージユニット中の前記データに対して動作する少なくとも１つのアプリケーションの識別情報を与える前記データストレージユニットにアクセスすることと、
前記少なくとも１つのプロセッサが、アプリケーションのコレクションから前記少なくとも１つのアプリケーションを取り出すことと、
前記少なくとも１つのプロセッサが、前記データストレージユニット中の前記データに対して動作するために前記少なくとも１つのアプリケーションを使用することと
を備える方法。
【請求項５４】
前記少なくとも１つのアプリケーションが前記データストレージユニット中の前記データを読み取る、請求項５３に記載の方法。
【請求項５５】
前記少なくとも１つのアプリケーションが、前記データを、前記データストレージユニットにまたは異なるデータストレージユニットに書き込む、請求項５３に記載の方法。
【請求項５６】
前記少なくとも１つのアプリケーションが前記データを表示させる、請求項５３に記載の方法。
【請求項５７】
前記少なくとも１つのアプリケーションが前記データをあるバージョンから別のバージョンにコンバートする、請求項５３に記載の方法。
【請求項５８】
前記少なくとも１つのアプリケーションが、前記データストレージユニット中の前記データに関連する情報に対して動作する、請求項５３に記載の方法。
【請求項５９】
ネットワークを介して結合された複数のコンピュータの間のセキュアな通信の方法であって、
前記複数のコンピュータの各々が、通信がそこから受信されることになる他のコンピュータの各々のための異なる公開鍵／非公開鍵ペアを作成することと、
前記複数のコンピュータの各々が、前記作成された公開鍵を前記公開鍵に対応するコンピュータに内密に送ることと、
前記複数のコンピュータの各々が、通信を暗号化するために、前記通信がそこに送られるべきである前記コンピュータの前記公開鍵を使用することと
を備える方法。
【請求項６０】
前記コンピュータの各々が、受信された公開鍵を、認可されたコンピュータにとってのみアクセス可能な個人情報マネージャに記憶すること
をさらに備える、請求項５９に記載の方法。
【請求項６１】
前記個人情報マネージャが鍵管理機能を与えることをさらに備え、
前記個人情報マネージャがストレージ管理機能を与える、
請求項６０に記載の方法。
【請求項６２】
前記個人情報マネージャが、それのデータを少なくとも１つの保護されたデータストレージユニットに記憶することをさらに備える、請求項６０に記載の方法。
【請求項６３】
前記少なくとも１つの保護されたデータストレージユニットがロックノードを備え、前記ロックノードは、
各々が複数の１次鍵のうちの１つに対応する、複数の鍵マップを与える入力セクションと、前記複数の１次鍵が、それぞれ、前記入力セクションに適用され、各鍵マップが少なくとも１つのメイン鍵を含む、
前記入力セクションに適用された前記１次鍵に対応する前記メイン鍵に対する論理演算から、導出された鍵を生成する変数ロックセクションと、
前記導出された鍵に応答して前記データを生成する出力セクションと
を備える、請求項６２に記載の方法。
【請求項６４】
前記少なくとも１つの保護されたデータストレージユニットが、データを記憶するための複数のロックノードであって、
各々が複数の１次鍵のうちの１つに対応する、複数の鍵マップを与える入力セクションと、前記複数の１次鍵が、それぞれ、前記入力セクションに適用され、各鍵マップが少なくとも１つのメイン鍵を含み、
前記入力セクションに適用された前記１次鍵に対応する前記メイン鍵に対する論理演算から、導出された鍵を生成する変数ロックセクションと、
前記導出された鍵に応答して前記データを生成する出力セクションと
を備える、データを記憶するための複数のロックノードと、
少なくとも１つのアクセス属性鍵をさらに含み得る指定された１次鍵の各々のための鍵マップを有する前記複数のロックノードの鍵穴ロックノードと、前記属性鍵が、前記保護されたデータストレージユニット内の前記対応する１次鍵に基づいてロールベース暗号アクセス制御を与え、および、
前記ロックノードのうちの別のもののための指定された１次鍵として働き得る出力鍵を与える前記ロックノードのうちの少なくとも１つと
を備える、請求項６２に記載の方法。
【請求項６５】
前記複数のコンピュータのうちの１つが通信を受信したとき、前記１つのコンピュータは、前記通信がそこから受信された前記コンピュータを決定し、前記通信を送る前記コンピュータに送られた前記公開鍵に対応する前記非公開鍵を使用して前記通信を解読する、請求項５９に記載の方法。
【請求項６６】
データを記憶する方法であって、
データを保護されたデータストレージユニットに記憶することと、前記ストレージユニットが、前記ストレージユニット中のデータのリビジョンの履歴または前記ストレージユニットを伴うイベントのログまたはその両方をも記憶し、
前記データの更新バージョンが保護されたデータストレージユニットに記憶されたとき、前記データの以前のバージョンのストレージユニットを削除することと、
前記データの以前のバージョンを再作成するために、前記更新バージョンを記憶する前記ストレージユニットの前記履歴またはイベントの前記ログまたはその両方を使用することと
を備える方法。
【請求項６７】
複数の保護されたデータストレージユニットであって、各々が、
データを記憶するように構築され、構成されたデータストレージセクションと、
その個々のストレージユニットにアクセスするアプリケーションにわたる、その個々のストレージユニットを伴うイベントのログを記憶するログセクションと
を備える複数の保護されたストレージユニット。
【請求項６８】
各ログが、暗号化された形式で記憶される、請求項６７に記載のストレージユニット。
【請求項６９】
パラメータが、どのイベントがロギングされ、どのイベントがロギングされないかを制御する、請求項６７に記載のストレージユニット。
【請求項７０】
パラメータが、前記ログにおいて与えられたイベントの詳細のレベルを制御する、請求項６７に記載のストレージユニット。
【請求項７１】
保護されたデータストレージユニットであって、
データを記憶するように構築され、構成されたデータストレージセクションと、
前記ストレージユニットにアクセスするアプリケーションにわたる、前記ストレージユニットに記憶された前記データのリビジョンの履歴を記憶する履歴セクションと
を備える保護されたストレージユニット。
【請求項７２】
前記履歴が、暗号化された形式で記憶される、請求項７１に記載のストレージユニット。
【請求項７３】
パラメータは、リビジョンが前記履歴においてどのように与えられるかを制御する、請求項７１に記載のストレージユニット。
【請求項７４】
前記履歴が各リビジョンのソースをも含む、請求項７１に記載のストレージユニット。
【請求項７５】
データを処理する方法であって、
少なくとも１つのプロセッサが、少なくとも１つの入力鍵を使用したデータへのアクセス制御関数を動作させることと、
前記少なくとも１つの入力鍵が、各々、前記データへの特定のアクセス属性を暗号で付与する対応する少なくとも１つのアクセス鍵を曝露することと、
各曝露された対応する少なくとも１つのアクセス鍵が、前記データへのすべての前記暗号で付与された特定のアクセス属性のユニオンを形成するために利用可能および前記データに適用可能な他の曝露された対応する少なくとも１つのアクセス鍵と、論理演算において組み合わされることと
を備える方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
[0001]本出願は、その内容全体が参照により本明細書に組み込まれる、２０１６年９月１５日に出願された米国仮特許出願第６２／３９５，０８４号に基づき、その出願から優先権を得るものである。
【発明の概要】
【０００２】
[0002]コンピュータソフトウェア設計のデータ中心モデルは、ユーザデータがアプリケーションよりも優先され得るものである。データ中心ソフトウェア設計は、データがストレージの際にセキュアにされることを可能にし得る。データのコンテナ化が、データ中心設計の一実施形態であり得る。様々な概念が本開示内でどのように実装され得るかを示すために、異なる観点からの一連の図面が、検討されている特定の概念を強調し、一体をなす図面が、これらのプロセスおよび構造のうちのいくつかがどのように一緒に働き得るかを示す。
【０００３】
[0003]データのコンテナ化は、レイヤ化手法において提示され得、選好される場合、各レイヤは、部分的または全体的に前のレイヤ上に築かれるか、あるいはそれらとともに働き得る。第１のレイヤのための本明細書で説明される概念、方法、装置、実施形態および／または仕様は、総称して、変成を用いた構造化データ折り畳み（Structured Data Folding with Transmutations）またはＳＤＦＴと呼ばれることがある。第１のレイヤを含み得る第２のレイヤのための本明細書で説明される概念、方法、装置、実施形態および／または仕様は、総称して、暗号化されたユーザデータの移動および記憶（eNcrypted Userdata Transit & Storage）またはＮＵＴＳと呼ばれることがある。Ｎｕｔと呼ばれるデータのためのコンテナを構築するために、各レイヤの任意の組合せが部分的または全体的に配備され得、各レイヤは、部分的または全体的に独立して配備され得る。これらの２つのレイヤの相互作用および／または混交（interweaving）は、有意および／または複雑であり得、そのようなレイヤの明瞭な分画についての課題を提起し得る。したがって、本明細書では、これらのレイヤは一緒に提示される。その場合、Ｎｕｔコンテナは、その中に含まれているデータに対する論理演算（operation）を可能にし得る様々なデータ中心特性で満たされ得る。Ｎｕｔと呼ばれるストレージのユニットに関して、様々な実施形態が、プライバシー、セキュリティ、利便性および／または能力（capability）をユーザに提供するために、いくつかの共通データ指向論理演算がどのように再定義および再構造化され得るかを示すために説明され得る。
【０００４】
[0004]様々な実施形態が、以下の発明を実施するための形態および添付の図面において開示され得る。
【図面の簡単な説明】
【０００５】
【図１】異なるサイファ（cipher）鍵タイプを表すために使用されるシンボルの表を示す図。
【図２】一般に異なるサイファ方法によって実施され得るデータ入力、データ出力および論理演算を示す簡略フローチャートのセットを示す図。
【図３】本開示の実施形態が機能し得る一般的なネットワークレイアウトの図。
【図４】本開示の実施形態が機能し得るコンピューティングデバイスの図。
【図５】順方向モードまたは通常演算での変成（transmutation）の図。
【図６】共通データ演算およびそれらの変成分類の表を示す図。
【図７】逆方向モードでの変成の図。
【図８】不可逆変成の図。
【図９】条件付き可逆変成の図。
【図１０】変成タイプによってグループ化された共通データ演算および関数の表を示す図。
【図１１】Ｐｙｔｈｏｎ  ｖ３において定義されているコーデックの表。
【図１２】追加の変成定義をリストする表を示す図。
【図１３】変成可逆性行列を示す図。
【図１４】変成モードアクション行列を示す図。
【図１５】ｓｅｒｉａｌｉｚｅ変成の詳細な例を示す図。
【図１６】ｄｉｇｅｓｔ変成の詳細な例を示す図。
【図１７】ｖｅｒｉｆｉｃａｔｉｏｎとしても知られる、逆方向モードでのｄｉｇｅｓｔ変成の詳細な例を示す図。
【図１８】ｓｃｉｐｈｅｒ変成の図。
【図１９】ｓａｌｓａ２０（ｓｃｉｐｈｅｒ）変成の図。
【図２０】ｓａｌｓａ２０（ｓｃｉｐｈｅｒ）変成の詳細な例を示す図。
【図２１】ｓｅｒｉａｌｉｚｅ変成およびｃｏｍｐｒｅｓｓ変成のためのコマンド仕様の表と、それの使用法を示すサンプル変成コマンドのセットとを示す図。
【図２２】ｅｎｃｏｄｅ変成のためのコマンド仕様の表と、それの使用法を示すサンプル変成コマンドのセットとを示す図。
【図２３】ｄｉｇｅｓｔ変成のためのコマンド仕様の表と、それの使用法を示すサンプル変成コマンドのセットとを示す図。
【図２４】ａｃｉｐｈｅｒ変成およびｄｉｇｎ変成のためのコマンド仕様の表と、それの使用法を示すサンプル変成コマンドのセットとを示す図。
【図２５】ｄｅｒｉｖｅ変成のためのコマンド仕様の表と、それの使用法を示すサンプル変成コマンドのセットとを示す図。
【図２６】ｓｃｉｐｈｅｒ変成のためのコマンド仕様の表２６０２と、それの使用法を示すサンプル変成コマンドのセット２６０４とを示す図。
【図２７】ステップ１が入力フォーマットを示し、ステップ２が出力フォーマットを示す２つのステップのシーケンスにおけるｓｃｉｐｈｅｒ出力ストリングのための出力構造フォーマットを示す図。「ヘッダ」は、出力メッセージに対するｓｃｉｐｈｅｒ変成の可変長鍵値ｕｔｆ８符号化パラメータストリングである。
【図２８】ｓｃｉｐｈｅｒ変成の出力構造フォーマットにおけるヘッダストリングのためのパラメータキーワードおよび仕様の表を示す図。
【図２９】ＡＥＡＤモードｓｃｉｐｈｅｒ変成のための反復的埋込みメッセージカプセル化の図。
【図３０】ｌｏｃｋ変成のためのコマンド仕様の表３００２と、それの使用法を示すサンプル変成コマンドのセット３０１０とを示す図。
【図３１】表フォーマットにおける様々な変成構造の仕様を示す図。
【図３２】ｍｏｂｉｕｓ変成のためのコマンド仕様の表を示す図。それの使用法が示され、グラフィックは、それが様々な構造に対して遂行することができる構造的変更を示す。行列は、ｍｏｂｉｕｓ変成がそれに対して演算することができる構造タイプ／モード有効演算を示す。
【図３３】ｐｒｅｓｓ変成およびｃｌｅａｎ変成のためのコマンド仕様の表３３０２ならびにｋｅｙ変成のためのコマンド仕様の表３３０４と、それの使用法を示すサンプル変成コマンドのセット３３１０とを示す図。
【図３４】鍵交換仕様構造（Key Interchange Specification Structure）またはＫＩＳＳのための表を示す図。
【図３５】ＫＩＳＳ演算モードのための表３５０２と、鍵タイプ／フィールド発生マッピングを示す行列のための表３５０４と、鍵タイプ定義のための表３５０６とを示す図。
【図３６】ＴＡＲの構造とＴＡＲ定義の例とを示す図。
【図３７】変成関係属性が持続される場合を示すブロック図と、属性のタイプおよびロケーションをリストする表とを示す図。
【図３８】ＳＤＦＴ演算ラヴェル（ravel）およびアンラヴェル（unravel）（またはラヴェルの逆転）のブロック図。
【図３９】ＳＤＦＴラヴェル演算のフローチャート。
【図４０】ＳＤＦＴアンラヴェル演算のフローチャート。
【図４１】ＴＡＲ逆転が一般的なＴＡＲに対してどのように実施されるかを示す図。
【図４２】ＴＡＲ逆転の例を示す図。
【図４３】ＴＡＲ処理中に変成が発生するかまたは要求し得る鍵タイプテンプレートにマッピングされた変成の表を示す図。
【図４４】ＴＡＲ例と、各々から発生された鍵テンプレートとを示す図。
【図４５】ＴＡＲ例と、各々から発生された鍵テンプレートと、入力（ｐｕｔ）または発生（ｇｅｎ）されることになるＫＩＳＳ構造の予想されるリストとを示す図。ＫＩＳＳのリストは鍵スタック（keystack）とも呼ばれる。
【図４６】ＳＤＦＴ  ＴＡＲ処理内の鍵スタック演算の３つのモード、すなわち、発生（ｇｅｎ）、入力（ｐｕｔ）および注入（ｍｉｘｅｄ）を示す図。
【図４７】鍵スタックがデータおよびそれのＴＡＲのライフサイクルにおいてどのように発生および使用され得るかの図。
【図４８】ＮＳｓｔｒ構造に記憶されたデータに対して行われ得る演算の図。
【図４９】データを反復的に折り畳む（fold）ためのＳＤＦＴ使用法の流れ図。
【図５０】データを反復的に展開する（unfold）ためのＳＤＦＴ使用法の流れ図。
【図５１】ＳＤＦＴ  ＡＰＩ／ライブラリおよびそれがアクセスを有し得る様々なタイプのＴＡＲ定義ファイルの図。
【図５２】手動データ折り畳みを実施するための例示的なＰｙｔｈｏｎスクリプトを示す図。
【図５３】ＰｙｔｈｏｎスクリプトにおけるＴＡＲ定義のＳＤＦＴ例およびそれの使用法を示す図。
【図５４】単一の通信セッション内の動的ＴＡＲ切替えのブロック図。
【図５５】Ｎｕｔ  ＩＤを発生するための例示的なプロセスのフローチャート。
【図５６】Ｎｕｔ  ＩＤとロックＩＤとがＮｕｔ内で使用され得る場合を示すブロック図。
【図５７】Ｎｕｔ  ＩＤと経路名とペイロードデータとの間の例示的な関係を示す図。
【図５８】論理セクション、すなわち、ＮｕｔロックおよびＮｕｔパートを備えるＮｕｔまたはロックグラフの実施形態のブロック図。
【図５９】３つの鍵穴ロックノードを備えるＮｕｔにおけるＮｕｔロックの代替実施形態のブロック図。
【図６０】ロックノードの内部データ構造のブロック図。
【図６１】図６０に示されているロックノードの入力セクションの内部データ構造のブロック図。
【図６２】有効１次鍵が鍵穴に挿入され得るときの図６１に示されている入力セクションの１次鍵穴の内部データ構造の関係を示すデータフロー図。
【図６３】任意のロックノードのためのおよび任意のサイファ鍵のための鍵挿入プロセスのフローチャート。
【図６４】３つの１次鍵が１次鍵穴に挿入され得る一例を示す図。
【図６５】図６４に示されている例から続く変数ロック（Variable Lock）解読（decrypt）演算のデータフロー図。
【図６６】図６４に示されている例から続く変数ロック暗号化（encrypt）演算のデータフロー図。
【図６７】任意のロックノードにおいて利用可能な変数ロックタイプおよびそれらの特性の表を示す図。
【図６８】ＯＲＬＯＣＫ解読（decryption）演算のデータフロー図。
【図６９】Ｎｕｔ所有者によるＯＲＬＯＣＫ暗号化（encryption）演算のデータフロー図。
【図７０】ＭＡＴＬＯＣＫ解読演算のデータフロー図。
【図７１】Ｎｕｔ所有者によるＭＡＴＬＯＣＫ暗号化演算のデータフロー図。
【図７２】ＸＯＲＬＯＣＫ解読演算のデータフロー図。
【図７３】Ｎｕｔ所有者によるＸＯＲＬＯＣＫ暗号化演算のデータフロー図。
【図７４】ＨＡＳＨＬＯＣＫ解読演算のデータフロー図。
【図７５】Ｎｕｔ所有者によるＨＡＳＨＬＯＣＫ暗号化演算のデータフロー図。
【図７６】ＳＳＬＯＣＫ解読演算のデータフロー図。
【図７７】Ｎｕｔ所有者によるＳＳＬＯＣＫ暗号化演算のデータフロー図。
【図７８】階層鍵（Stratum Key）を強調するＮｕｔのブロック図。
【図７９】階層鍵がＮｕｔ内でどのように挿入され得るかのフローチャート。
【図８０】２つのロール（role）および４つのロールプレイヤー（role player）のための鍵ベース許可（Key Based Permission）の表を示す図。
【図８１】各パートがロックノードによって表され得る例示的なＮｕｔにおける様々なＮｕｔパートをリストする表を示す図。
【図８２】一般的なＮｕｔについて定義された鍵ベース許可アクセスロールをリストする表を示す図。
【図８３】アクセス属性鍵セットロック解除鍵（ＡＡＫＳＵＫ：Access Attribute Key Set Unlock Key）と呼ばれるＮｕｔアクセス制御アクセス鍵の初期セットが、各有効１次鍵のためのアクセス鍵穴にどのように挿入され得るかのブロック図。
【図８４】外部ロックノードから内部ロックノードへのＮＡＣアクセス属性の伝搬のブロック図。
【図８５】外部ロックノードから内部ロックノードへのＮＡＣアクセス属性の伝搬と、リンクされたロックノードの１次鍵穴への出力リンク鍵の挿入とのブロック図。
【図８６】鍵をアクセス鍵穴に挿入するためのフローチャート。
【図８７】代替実施形態のための鍵ベース許可の表を示す図。
【図８８】ロックノードの内部解読データフローのデータフロー図。
【図８９】Ｎｕｔをロック解除するためのフローチャート。
【図９０】ＮＵＴＳベースシステムの実施形態と、Ｎｕｔに記憶されたドキュメントがどのようにロック解除され得るかとのブロック図。
【図９１】それを保持するＮｕｔのＮｕｔ  ＩＤによってＮｕｔのペイロードを参照するためのＮＵＴＳ用語における共通使用法の図。ここで、サイファ鍵が、それを保持するＮｕｔのＮｕｔ  ＩＤによって参照され得る。
【図９２】受信側ロッキングモデルのリストの簡略化された実施形態を示す図。
【図９３】順序付きロッキングモデルの簡略化された実施形態を示す図。
【図９４】マスタ鍵を用いた順序付きロッキングモデルの簡略化された実施形態を示す図。
【図９５】マスタ鍵を用いたロッキングモデルの簡略化された実施形態を示す図。
【図９６】マスタ鍵を用いたロッキングモデルの簡略化された実施形態を示す図。
【図９７】セーフデポジットボックスロッキングモデルの簡略化された実施形態を示す図。
【図９８】マスタ鍵を用いた秘密共有ロッキングモデルの簡略化された実施形態を示す図。
【図９９】「ＰｒｉｖａＴｅｇｒｉｔｙ」タイプロッキングモデルの簡略化された実施形態を示す図。
【図１００】複数のペイロードが単一のＮｕｔ内に記憶され得るマルチＮｕｔ構成の簡略化された実施形態を示す図。
【図１０１】複数のペイロードが単一のＮｕｔ内に記憶され得るマルチＮｕｔ構成の簡略化された実施形態を示す図。
【図１０２】複数のペイロードを用いた直接ロッキングモデルの簡略化された実施形態を示す図。
【図１０３】共謀抵抗（collusion resistant）設計を呈する順序付きメッセージパッシングの簡略化された実施形態を示す図。
【図１０４】モジュラーＩ／Ｏの一般的な構成要素のブロック図。
【図１０５】ＭＩＯＲを使用する単純な読取りおよび書込み演算の図。
【図１０６】一般的なＭＩＯファイル読取り演算に関与し得るデータ変換および転送を示す図。
【図１０７】ファイルフォーマットの後方互換性がモジュラーＩ／Ｏを使用してどのように容易にされ得るかを示す図。
【図１０８】ファイルフォーマットの前方互換性がモジュラーＩ／Ｏを使用してどのように容易にされ得るかを示す図。
【図１０９】モジュラーディスプレイがモジュラーＩ／Ｏを使用してどのように容易にされ得るかを示す図。
【図１１０】モジュラーアプリケーションがモジュラーＩ／Ｏを使用してどのように容易にされ得るかを示す図。
【図１１１】２度の編集を介したおよび３つの時点におけるＮｕｔ履歴の漸進的変更を示す図。
【図１１２】図１１１からのイベントの過程にわたるＮｕｔログの漸進的変更を示す図。
【図１１３】関係ベース鍵がアリスおよびボブの連絡先カード中にどのように表され得るかを示す図。
【図１１４】よく知られている電子メールアドレスおよび／またはＲＢＫを使用してスパムがどのように検出され得るかのフローチャート。
【図１１５】匿名電子メールアドレスおよび／またはＲＢＫを使用してスパムがどのように検出され得るかのフローチャート。
【図１１６】アリス−ボブＲＢＫ通信チャネルの決定論的コンテキストベースステータス行列（Deterministic Context Based Status Matrix）を示す図。
【図１１７】アリス−ベンダーＲＢＫ通信チャネルの決定論的コンテキストベースステータス行列を示す図。
【図１１８】ベンダー−アリスＲＢＫ通信チャネルの決定論的コンテキストベースステータス行列を示す図。
【図１１９】ボブについての危殆化されたシステムにおけるＲＢＫ関係の隔離を示す図。
【図１２０】事前パッケージ化されたデータＮｕｔのブロック図。
【図１２１】ＲＢＫを使用する自動化された登録プロセスにおけるイベントのシーケンスをチャートで示す図。
【図１２２】ＲＢＫと匿名電子メールアドレスとを使用する自動化された登録プロセスにおけるイベントのシーケンスをチャートで示す図。
【図１２３】ＮＵＴＳコアアプリケーションおよびそれらの説明をリストする表を示す図。
【図１２４】コンピュータデバイス中で動作しているＮＵＴＳコアアプリケーションのブロック図。
【図１２５】ユーザデバイス中で動作しているＮＵＴｓｅｒｖｅｒのブロック図。
【図１２６】ＮＵＴｓｅｒｖｅｒを備える内部構成要素と、ユーザデバイスの環境へのそれらの機能的接続とのブロック図。
【図１２７】キャッシング機構としてＮｏＳＱＬデータベースを使用する図１２６に示されているＮＵＴｓｅｒｖｅｒの代替実施形態を示す図。
【図１２８】ＭＩＯＲサーバネットワークレイアウトのブロック図。
【図１２９】ＭＩＯＲサーバアプリケーションレイアウトのブロック図。
【図１３０】ＭＩＯＲサーバからＭＩＯモジュールをフェッチするためのフローチャート。
【図１３１】ＭＩＯＲキャッシュの編成を示すブロック図。
【図１３２】ユーザデバイス環境におけるＮＵＴｂｒｏｗｓｅｒアプリケーションのブロック図。
【図１３３】ユーザデバイス環境におけるＮＵＴｂｏｏｋアプリケーションのブロック図。
【図１３４】ユーザデバイス環境におけるＮｕｔ処理アプリケーションフレームワークのブロック図。
【図１３５】ＮＵＴｂｏｏｋを備える内部構成要素を示すブロック図。
【図１３６】図１３５からのＮＵＴｂｏｏｋカタログキャッシュの内部編成を示すブロック図。
【図１３７】ハイアラーキ（Hierarchical）パスワードの編成を示す図。
【図１３８】メインパスワードが図１３７のハイアラーキパスワードに従ってどのように個人ドキュメントを開くかを示す図。
【図１３９】マスタパスワードが図１３７のハイアラーキパスワードおよび図１３８中のドキュメントに従ってどのように個人ドキュメントを開くかを示す図。
【図１４０】メインパスワードと作業（Work）パスワードとが図１３７のハイアラーキパスワードに従ってどのように作業ドキュメントを開くかを示す図。
【図１４１】マスタパスワードが図１３７のハイアラーキパスワードおよび図１４０中のドキュメントに従ってどのように作業ドキュメントを開くかを示す図。
【図１４２】図１３５からのＮＵＴｂｏｏｋ鍵キャッシュの内部編成を示すブロック図。
【図１４３】ＮＵＴｂｏｏｋがカードカタログをどのように閲覧し得るかについてのフローチャート。
【図１４４】ＮＵＴＳベースサービスの表を示す図。
【図１４５】ＮＵＴＳベースサービスのネットワークレイアウトの図。
【図１４６】ＮＵＴｍａｉｌサーバのネットワークレイアウトの図。
【図１４７】ＲＢＫを使用する、ＮＵＴｍａｉｌなど、匿名電子メールサービスへの自動化された登録プロセスにおけるイベントのシーケンスをチャートで示す図。
【図１４８】ＮＵＴｍａｉｌサーバ中で通信チャネルを追加するときのイベントのシーケンスをチャートで示す図。
【図１４９】アリスとボブとがＮＵＴｍａｉｌを介して互いに電子メールを送るときのイベントのシーケンスをチャートで示す図。
【図１５０】ＮＵＴｃｈａｔサーバのネットワークレイアウトの図。
【図１５１】ＮＵＴｃｈａｔサーバによってホストされる３つのチャットセッションのデータフロー図。
【図１５２】ＮＵＴｓｅｒｖｅｒにわたるチャット履歴持続および複製のデータフロー図。
【図１５３】異なるチャットＩＤまたはチャットサービスを使用する３つの別個のチャットセッションのためのデータフロー図。
【図１５４】図１５３からの３つの異なるチャット経路を使用するＮＵＴｃｈａｔクライアントによって管理される経路アグノスティック（path agnostic）ダイアログのためのデータフロー図。
【図１５５】ＮＵＴｃｌｏｕｄサーバのネットワークレイアウトの図。
【図１５６】ＮＵＴｎｅｔサーバのネットワークレイアウトの図。
【図１５７】ＮＵＴＳのインターネット（ＩｏＮ：Internet of NUTS）のためのＮＵＴｈｕｂサーバのネットワークレイアウトの図。
【図１５８】直接ＩｏＮネットワークトポロジーの図。
【図１５９】間接ＩｏＮネットワークトポロジーの図。
【図１６０】ＮＵＴｓｅｒｖｅｒハブと、図１５９からのＮＵＴｈｕｂおよびＩｏＮデバイスへのそれの接続との図。
【図１６１】図１６０からのＮＵＴｓｅｒｖｅｒハブ中のＮＵＴｈｕｂ／ＩｏＮインターフェースのブロック図。
【図１６２】図１６０からのＩｏＮデバイス中のＮＵＴｈｕｂ／ＮＵＴｓｅｒｖｅｒ／ＩｏＴインターフェースのブロック図。
【図１６３】ＩｏＮ／ＩｏＴデバイスのための登録および構成プロセスのフローチャート。
【図１６４】遠隔制御インターフェースが図１６１および図１６２からのコマンドＮｕｔをどのように処理し得るかのフローチャート。
【図１６５】ＮＵＴＳ証明サーバのネットワークレイアウトの図。
【図１６６】図１６５からのＮＵＴＳ証明サーバの機能を強調するブロック図。
【図１６７】ＮＵＴＳベースＷｉＦｉ（登録商標）／イーサネット（登録商標）ルータのネットワークレイアウトの図。
【図１６８】メッセージが図１６７からのＮＵＴＳベースＷｉＦｉ／イーサネットルータ中でどのように処理され得るかのフローチャート。
【図１６９】ＮＵＴＳベースＷｉＦｉ／イーサネットルータのためのデバイスカテゴリーの表を示す図。
【図１７０】ＮＵＴＳベースＷｉＦｉ／イーサネットルータに関する例示的なデバイスカテゴリー属性の表を示す図。
【図１７１】アプリケーションラッピング（Application Wrapping）が自動でのデバイスバックアップおよび複写をどのように可能にするかのブロック図。
【図１７２】２つのデバイス中のイベント処理サービス（ＥＰＳ：Event Processing Service）のブロック図。
【図１７３】トラッキングクッキーと、ビッグデータサーバに記憶されたセッション履歴とを使用し得る一般的なベンダーネットワークセットアップのブロック図。
【図１７４】ローカルに、ならびに図１７３からのビッグデータサーバに記憶されているセッション履歴のコピーを記録するためにアプリＮｕｔを使用し得るベンダーネットワークセットアップのブロック図。
【図１７５】図１７３および図１７４からのアプリＮｕｔを利用してローカルに行われ得るコンテキスト算出のブロック図。
【図１７６】ＩｏＴデバイスとサービスプロバイダとを備える個人ホームネットワークトポロジーの図。
【図１７７】ベンダーへ向かうデータのフローを制御するための、間接ＩｏＮネットワークトポロジーにおける２つのＩｏＮデバイスと、それらのそれぞれのサービスプロバイダとを備える個人ホームネットワークの図。
【図１７８】コンテキスト分析アプリが、図１７７からのＮＵＴｓｅｒｖｅｒ中のユーザのプライバシーを保護するために発信ＩｏＮメッセージをどのように自動的にフィルタ処理し得るかのブロック図。
【発明を実施するための形態】
【０００６】
目次
●  シンボルおよび略語
●  サイファおよび一方向ハッシュ
●  ネットワーク図
●  デバイス図
●  変成
●  変成タイプ
●  変成構造
●  変成監査記録（ＴＡＲ：Transmutation Audit Record）
●  変成を用いた構造化データ折り畳み（ＳＤＦＴ）
●  Ｎｕｔ  ＩＤ
●  ロックグラフおよびロックノード
〇  鍵穴
〇  変数ロック
〇  階層
〇  Ｎｕｔアクセス制御（ＮＡＣ）
〇  ロックノードトラバーサル（Lock Node Traversal）
●  モジュラーＩ／Ｏ
〇  読取りおよび書込み
〇  後方互換性
〇  前方互換性
〇  ディスプレイ
〇  アプリケーション
●  Ｎｕｔ履歴
●  Ｎｕｔログ
●  関係ベース鍵（ＲＢＫ）
●  匿名関係
●  ＮＵＴＳコアアプリケーション
〇  ＮＵＴｓｅｒｖｅｒ
〇  ＭＩＯＲサーバ
〇  ＮＵＴｂｒｏｗｓｅｒ／ＮＵＴｓｈｅｌｌ
〇  ＮＵＴｂｏｏｋ
●  ＮＵＴＳベースサービス
〇  ＮＵＴｍａｉｌ
〇  ＮＵＴｃｈａｔ
〇  ＮＵＴｃｌｏｕｄ
〇  ＮＵＴｎｅｔ
〇  ＮＵＴｈｕｂ
〇  ＮＵＴＳ証明サーバ
●  ＮＵＴＳベースＷｉＦｉ／イーサネットルータ
●  アプリケーションラッピング
●  イベント処理サービス
●  コンテキスト算出
●  結論および理念
【０００７】
シンボルおよび略語
[0005]以下のシンボルおよび略語が、説明および図面全体にわたって使用され得る。（＊）でマークされたものは、ＮＵＴＳ固有であり得る。  
●  ＡＡＫＳ  ＊アクセス属性鍵セット（Access Attribute Key Set）
●  ＡＡＫＳＵＫ  ＊アクセス属性鍵セットロック解除鍵
●  ＡＡＰＫ  ＊アクセス属性伝搬鍵（Access Attribute Propagation Key）
●  ａｃｉｐｈｅｒ  非対称サイファ
●  ＡＥＡＤ  関連データを用いた認証される暗号化（Authenticated Encryption with Associated Data）
●  ＡＥＳ  高度暗号化標準、また、Ｒｉｊｎｄａｅｌ
●  ＡＰＩ  アプリケーションプログラミングインターフェース
●  ＡＫＳ  ＊アクセス鍵セット（Access Key Set）
●  ＡＲＫ  ＊アクセスロール鍵（Access Role Key）
●  ＢＩＯＳ  基本入出力システム
●  ｂｚ２  ｂｚｉｐ２、Ｂｕｒｒｏｗｓ−Ｗｈｅｅｌｅｒ圧縮アルゴリズム
●  ＣＡ  証明局（Certificate Authority）
●  ＣＡＣ  暗号（cryptographic）アクセス制御
●  ＣｈａＣｈａ２０  Ｂｅｒｎｓｔｅｉｎによる対称鍵ベースストリームサイファ
●  ＣＬＩ  コマンドラインインターフェース
●  ＣＭＡＣ  サイファベースメッセージ認証コード
●  ＣＯＤＥＣ  コーダ／デコーダ、文字データのための符号化方式
●  ＣＯＭ  コンポーネントオブジェクトモデル
●  ＣＯＲ  ＊リーダーのクラス（Class of Readers）、またはリーダー
●  ＣＯＲＢＡ  共通オブジェクトリクエストブローカーアーキテクチャ
●  ＣＯＷ  ＊ライター（Writer）のクラス、またはライター
●  ＣＰＵ  中央処理ユニット
●  ＣＲＣ  巡回冗長検査
●  ｄｉｇｎ  ＊（名詞）非対称非公開（private）鍵を使用して発生されたデジタル署名
●  ｄｉｇｎ  ＊（動詞）非対称非公開鍵を使用してデジタル署名を作成すること
●  ＤＫ  ＊導出された鍵（Derived Key）
●  ＤＲＭ  デジタル権利管理
●  ＤＶＤ  デジタルビデオディスク
●  ＤＳＡ  デジタル署名アルゴリズム
●  ＥＣＣ  楕円曲線暗号（cryptography）
●  ｅＤＫ  ＊暗号化された（encrypted）導出された鍵
●  ＥＰＳ  ＊イベント処理サービス
●  ＦＩＰＳ  連邦情報処理標準
●  ＨＭＡＣ  ハッシュベースメッセージ認証コード
●  ＧＰＳ  全地球測位システム
●  ＧＰＵ  グラフィックス処理ユニット
●  ＧＵＩ  グラフィカルユーザインターフェース
●  ＧＵＩＤ  グローバル一意識別子
●  ｇｚｉｐ  ＧＮＵ  ｚｉｐ圧縮
●  ＨＫＤＦ  ＨＭＡＣベース鍵導出関数
●  ｉｋｍ  初期鍵材料（Initial key material）
●  ＩＭＥＩ  国際移動局機器識別情報
●  ＩｏＮ  ＊Ｎｕｔｓのインターネット
●  ＩｏＴ  モノのインターネット
●  ＩＰＣ  プロセス間通信
●  ＩＰｖ４  インターネットプロトコルバージョン４
●  ＩＰｖ６  インターネットプロトコルバージョン６
●  Ｉ／Ｏ  入出力
●  ｉｍａ  ＊「Ｉ  ａｍ  ａ」または「Ｉ’ｍ  ａ」の省略であるＫＩＳＳフィールド名：ＫＩＳＳモードを決定する
●  ｉｖ  初期化ベクトル：暗号使用のためのランダム数
●  ＪＳＯＮ  Ｊａｖａ（登録商標）Ｓｃｒｉｐｔオブジェクト表記法
●  ＫＢＰ  ＊鍵ベース許可
●  Ｋｅｃｃａｋ  ＳＨＡ３ハッシュファミリー
●  ＫＩＳＳ  ＊鍵交換仕様構造
●  ＬＡＮ  ローカルエリアネットワーク
●  ｌｏｃｋ  ＊変成のクラスとしての変数ロックの実装形態
●  ｌｚｍａ  Ｌｅｍｐｅｌ−Ｚｉｖ−Ｍａｒｋｏｖ連鎖アルゴリズム（Lempel-Ziv-Markov chain Algorithm）
●  ＭＡＣ  （イーサネットに関する）メディアアクセス制御
●  ＭＡＣ  メッセージ認証コード
●  ＭＤ５  Ｒｉｖｅｓｔによるメッセージダイジェスト＃５
●  ＭＩＯ  ＊モジュラーＩ／Ｏ
●  ＭＩＯＲ  ＊モジュラーＩ／Ｏリポジトリ
●  ＭＭＳ  マルチメディアメッセージングサービス
●  ＮＡＣ  ＊Ｎｕｔアクセス制御
●  ＮＣＳ  ＊ＮＵＴＳ証明サーバ
●  ＮＦＣ  ニアフィールド通信
●  ＮＩＳＴ  米国標準技術局
●  ＮｏＳＱＬ  非標準照会言語（Non Standard Query Language）、また、非リレーショナル標準照会言語
●  ｎｏｎｃｅ  １回のみ使用される数（Number only used ONCE）：暗号使用のためのランダム数
●  ＮＴＦＳ  ニューテクノロジーファイルシステム（マイクロソフト）
●  ＮＵＴＳ  ＊暗号化されたユーザデータの移動および記憶
●  ＯＡＥＰ  ＢｅｌｌａｒｅおよびＲｏｇａｗａｙによる最適非対称暗号化パディング（Optimal Asymmetric Encryption Padding by Bellare and Rogaway）
●  ＯＳ  オペレーティングシステム
●  ＰＢＫＤＦ２  ＲＳＡによるパスワードベース鍵導出関数＃２（ＰＫＣＳ）
●  ＰＧＰ  プリティグッドプライバシー
●  ＰＩＭ  個人情報マネージャ
●  ＰＫＣＳ  ＲＳＡラボラトリによる公開鍵暗号標準
●  ＰＫＣＳ１＿Ｖ１．５  ＰＫＣＳ＃１のバージョン１．５
●  ＰＫＩ  公開鍵インフラストラクチャ
●  ＰＳＳ  確率的署名方式（Probabilistic Signature Scheme）
●  ＰＵＩＤ  事実上一意のＩＤ（Practically Unique ID）
●  ＱＡ  品質保証
●  ＱＵＯＰＲＩ  Ｑｕｏｔｅｄ−ＰｒｉｎｔａｂｌｅまたはＱＰ符号化
●  ＲＡＭ  ランダムアクセスメモリ
●  ＲＡＴ  ＊ルートアクセスティア（Root Access Tier）、Ｎｕｔの所有者／作成者、また、ＲＡＴライター、所有者
●  ＲＢＡＣ  ロールベースアクセス制御
●  ＲＢＣＡＣ  ロールベース暗号アクセス制御
●  ＲＢＫ  ＊関係ベース鍵
●  ＲＯＭ  読取り専用メモリ
●  ＲＳＡ  Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ公開鍵暗号システム
●  ＳＡＣ  ＊階層アクセス制御
●  Ｓａｌｓａ２０  Ｂｅｒｎｓｔｅｉｎによる対称鍵ベースストリームサイファ
●  ｓａｌｔ  暗号使用のためのランダム数
●  ｓｃｉｐｈｅｒ  対称サイファ
●  ＳＣＰ  ＊構造化暗号プログラミング（Structured Cryptographic Programming）
●  ＳＣＲＹＰＴ  Ｐｅｒｃｉｖａｌによるパスワードベース鍵導出関数
●  ＳＤＦ  ＊構造化データ折り畳み
●  ＳＤＦＴ  ＊変成を用いた構造化データ折り畳み
●  ＳＨＡ  セキュアハッシュアルゴリズム−Ｋｅｃｃａｋハッシュバリアント（variant）
●  Ｓｈａｋｅ  Ｋｅｃｃａｋハッシュバリアント
●  ＳＭＳ  ショートメッセージサービス
●  ＳＯＡＰ  簡易オブジェクトアクセスプロトコル
●  ＳＰＡＭ  非送信請求大量電子メール（unsolicited bulk email）、また、ジャンク電子メール
●  ＳＳＤ  ソリッドステートドライブ
●  ＳＳＩＤ  サービスセット識別子
●  ＳＳＯ  シングルサインオン
●  ｔａｒ  テープアーカイブ：テープまたはディスク上にデータを記憶するためのＵｎｉｘ（登録商標）コマンド
●  ＴＡＲ  ＊変成監査記録
●  ＴＯＰ  ＊変成編成原理（Transmutations Organizing Principle）
●  ｔｉｎｅ  ＊フォークの歯（tine）のような、Ｓｈａｍｉｒの秘密共有シェア（Secret Sharing share）
●  ＴＭＸ  ＊変成
●  ＴＯＰ  ＊変成編成原理
●  ＵＲＬ  ユニフォームリソースロケータ
●  ＵＴＦ  ユニコード変換フォーマット
●  ＵＴＩ  ユニフォームタイ（登録商標）プ識別子（Uniform Type Identifier）
●  ＵＵＩＤ  汎用一意識別子
●  ＶＰＮ  仮想プライベートネットワーク（Virtual Private Network）
●  ＷＡＮ  ワイドエリアネットワーク
●  ＷｉＦｉ  ＷＬＡＮプロトコル
●  ＷＬＡＮ  ワイヤレスＬＡＮ
●  ＸＭＬ  拡張可能マークアップ言語
●  Ｚｌｉｂ  ｚｌｉｂ圧縮アルゴリズム
【０００８】
[0006]図１は、本開示の説明および図面全体にわたって使用され得るサイファ鍵タイプおよびそれらのそれぞれのシンボルの表を示す。可変長テキストベースパスワードまたはパスフレーズが、シンボル１０２によって表され得る。シンボル１０４は、ＡＥＳ−２５６または代替サイファを備える対称サイファのための鍵を表す。シンボル１０６は、ＲＳＡ−２０４８または代替サイファを備える非対称サイファのための鍵ペアを表す。非対称鍵ペア１０６の公開部分はシンボル１０８として示され得、非公開部分はシンボル１１０として示され得る。当業者は、これらのサイファが、よく知られている、およびよくテストされたアルゴリズムであり得ることと、標準変更または代替が望まれ得るとき、他の好適な方法が本開示において指定され得る場合、これらの方法が代わりに使用され得ることとを容易に認識し得る。
【０００９】
サイファおよび一方向ハッシュ
[0007]図２は、様々なタイプのサイファによって実施され得る基本演算を示す。暗号化モード（encrypting mode）での対称サイファ２０８は、暗号化されたデータ２０６またはサイファテキスト（ciphertext）を生成するために、対称鍵２０２とデータ２０４とを受け付け得る。解読モード（decrypting mode）での対称サイファ２０８は、元のデータ２０４を生成するために、同じ対称鍵２０２とサイファテキスト２０６とを受け付け得る。対称サイファの実装形態では、暗号化方法と解読方法とは、２つの別々に命名された関数コール（function call）であり得るか、または、入力のパートとしてのモードパラメータをもつ特異コールであり得る。対称サイファの特性は、暗号化プロセスと解読プロセスの両方が同じ秘密鍵２０２を利用し得ることであり得る。
【００１０】
[0008]暗号化モードでの非対称サイファ２１４は、暗号化されたデータ２１２またはサイファテキストを生成するために、非対称鍵ペアの公開部分２１０とデータ２０４とを受け付け得る。解読モードでの非対称サイファ２１４は、元のデータ２０４を生成するために、非対称鍵の非公開部分２１６とサイファテキスト２１２とを受け付け得る。非対称サイファの実装形態では、暗号化方法と解読方法とは、２つの別々に命名された関数コールであり得るか、または、入力のパートとしてのモードパラメータをもつ特異コールであり得る。非対称サイファの特性は、暗号化プロセスと解読プロセスとが鍵ペアの異なるパートを利用し得ることであり得る。ＲＳＡ−２０４８などの実装形態では、数学的関係を使用して非公開鍵から公開鍵が導出され得、したがって、ＲＳＡ−２０４８非公開鍵が鍵ペアと同義であり得、公開鍵は、ＲＳＡ−２０４８非公開鍵から抽出され得る。
【００１１】
[0009]署名（signing）モードでのデジタル署名方法２２２が、デジタル署名２２０を生成するために、非対称鍵ペアの非公開部分２１６とサイファテキスト２１８とを受け付け得る。認証モードでのデジタル署名方法２２２は、サイファテキスト２１８と非対称鍵ペアの非公開部分２１６とを使用してデジタル署名が作成されたかどうかを認証する２２４ために、非対称鍵ペアの公開部分２１０と、デジタル署名２２０と、前記サイファテキスト２１８とを受け付け得る。デジタル署名方法の実装形態では、署名方法と認証方法とは、２つの別々に命名された関数コールであり得るか、または、入力のパートとしてのモードパラメータをもつ特異コールであり得る。デジタル署名方法の特性は、署名プロセスと認証プロセスとが鍵ペアの異なるパートを利用し得ることであり得る。ＲＳＡ−２０４８鍵ペアに基づくデジタル署名方法などの実装形態では、数学的関係を使用して非公開鍵から公開鍵が導出され得、したがって、ＲＳＡ−２０４８非公開鍵が鍵ペアと同義であり得、公開鍵は、ＲＳＡ−２０４８非公開鍵から抽出され得る。簡潔および簡明のために、本明細書は、デジタル署名を互換的にｄｉｇｎと呼ぶことがあり、１つのデータにデジタル署名する行為は、互換的にｄｉｇｎｉｎｇと呼ばれることがあり、１つのデータにデジタル署名したことは、互換的にｄｉｇｎｅｄと呼ばれることがある。
【００１２】
[0010]デジタル署名方法は、あるタイプのメッセージ認証コードまたはＭＡＣであり得る。ＭＡＣは、データに対する一方向ハッシュアルゴリズムを用いて作成され得る。ＳＨＡ−５１２などのハッシュ方法は、長さが最高５１２ビットであり得るデータコンテンツのメッセージダイジェストを生成するために、データコンテンツを受け付け得る。ＳＨＡ−５１２などの方法を使用するＭＡＣの認証は、前記１つのデータに関するＭＡＣを再計算することと、与えられたＭＡＣと計算されたＭＡＣとを相等性について比較することとを伴う。鍵付きハッシュメッセージ認証コードまたはＨＭＡＣとして知られる技法は、ＨＭＡＣ値を生成するために、データコンテンツとともに暗号鍵の追加の入力をとり入れ得る。
【００１３】
[0011]デジタル署名方法および／またはハッシング方法は、それぞれのデータを表し得るメッセージダイジェストを生成するために、本開示の様々なパートにおいて使用され得る。
【００１４】
ネットワーク図
[0012]図３は、本開示の様々な実施形態が部分的または全体的に適用され得る簡略化されたネットワーク図を表す。ワイドエリアネットワークＷＡＮ３０２は、簡略化されたネットワーククラウドビューをユーザまたは会社に与えるために一緒に働く、様々な電気通信センターにおける多くのサーバとルータと切替えシステムとを備え得るネットワーククラウドとして表され得る。クラウドサービス３０４も、クラウドストレージおよびクラウド処理などのネットワークサービスを与え得る様々な商業システムを表すクラウドとして図式的に簡略化され得、これらのサービスは、それら自体の仕様に合わせて実装され得るが、サーバファーム、ストレージアレイおよびルータの多くのインスタンスを備え得る。個人ルータ３０６は、ユーザが有し得る複数のネットワーク接続可能デバイス３０８〜３１８の間で個人ユーザにインターネットへのアクセスを与え得るＷＡＮ３０２に接続され得る。ユーザは、同じネットワーク上のまたはインターネットにわたる他のデバイスにアクセスするために、図に示されたデバイスに限定されないことがあり、ルータを利用し得る任意のデバイスを使用し得る。ルータ３０６は、インターネットサービスプロバイダの専用ルーティングデバイスであり得るか、あるいは、それは、ルーティングおよび／またはＬＡＮおよび／またはＷＬＡＮ能力を与える組合せデバイスであり得、ゲートウェイと呼ばれることがある。企業ルータ３２０は、会社が有し得る複数のネットワーク接続可能デバイス３２２〜３３０の間で組織ユーザにインターネットへのアクセスを与え得るＷＡＮ３０２に接続され得る。会社は、同じネットワーク上のまたはインターネットにわたる他のデバイスにアクセスするために、図に示されたデバイスに限定されないことがあり、ルータを利用し得る任意のデバイスを使用し得る。ルータ３２０は、インターネットサービスプロバイダの専用ルーティングデバイスであり得るか、あるいは、それは、ルーティングおよび／またはＬＡＮおよび／またはＷＬＡＮ能力を与える、相互接続および管理されたルータのセットであり得、ゲートウェイおよび／またはイントラネットと呼ばれることがある。様々な実施形態における本明細書で説明されるシステムおよび方法は、このネットワーク図の一部または全部のパートに使用および適用され得る。
【００１５】
デバイス図
[0013]一般的なコンピューティングデバイス４００が図４に示されている。処理ユニット４０４が、デバイス内の一部または全部の内部通信およびデータ転送を容易にし得るシステムバス４０２に接続され得る。いくつかの異なるタイプの利用可能なシステムバスがあり得るが、簡単のために、それらはシステムバス４０２と総称され得る。処理ユニットは、ＧＰＵボードおよびブレードサーバなどの様々な特殊な処理ボードにおいて見られるものなど、シングルまたはマルチコアプロセッサならびにプロセッサのアレイを表し得る。システムバスによってサービスされる他の構成要素は、ネットワークアダプタ４１２と、Ｉ／Ｏインターフェース４１０と、ディスプレイインターフェース４１４と、ＢＩＯＳプログラム４０８を記憶し得る読取り専用メモリＲＯＭ４０６と、実行中のオペレーティングシステム４１８、実行中のアプリケーション４２０および／またはアプリケーションデータ４２２を短い間記憶し得る揮発性メモリＲＡＭ４１６と、インストールされたオペレーティングシステム４２８、アプリケーション４３０、および／またはデータファイル４３２をまとめて永続的に記憶し得るハードドライブ、ＳＳＤおよびフラッシュドライブ４２６などの不揮発性メモリ４２４とであり得る。
【００１６】
[0014]本開示の一部または全部の実施形態が適用可能および機能的であるために、図示されたコンピューティングデバイスのすべての構成要素が必要であるとは限らない。たとえば、デバイスは、いくつかのＩｏＴデバイス上で見られるもののようないかなる物理ディスプレイもＩ／Ｏインターフェースも有しないことがあり、ルータおよびゲートウェイは、ほとんど物理ハードディスクの妨げにならないことがある。ＮＵＴＳサポートおよび互換性のための必要な要件は、処理ユニットと、何らかの形態のストレージと、システムバスとを備え得るＮＵＴＳ互換ソフトウェアを実行するアビリティ（ability）であり得る。
【００１７】
変成
[0015]変成は、コンピュータプログラミングにおいて見られる多くの知られているデータ操作演算を編成する好ましい方法であり得る。ＮＵＴＳは、これを変成編成原理またはＴＯＰとして指定し得る。さらに、任意の系統的データ操作演算が、ＴＯＰを使用して分析され得、あるタイプの変成として分類され得る。次いで、変成は、変成を用いた構造化データ折り畳みまたはＳＤＦＴと呼ばれることがある、ＴＯＰのフレームワーク内で協働的に働くように、カテゴリー分類され、正規化され、構造化され、統合され、および／または適応され得る。ＴＯＰおよび／またはＳＤＦＴを用いてデータに対して動作することの見識ある観点は、より良いおよび／または複雑なデータ設計が、概念的により単純におよび／またはプログラム的に効率的に実装されることを可能にし得る。ＴＯＰおよびＳＤＦＴは、ＮＵＴＳ構成要素のための好ましい下位レベル実装機構であり得る。
【００１８】
[0016]データの変成に基づく分析、方法および／または構造は、そのような概念をレイヤ化し、それらの関連する方法を設計することが、モジュラーの、可搬の、記憶可能なおよび／または自己記述的な（self-describing）やり方でのデータの容易で系統的な変成を可能にし得る統合データ構造およびアルゴリズム方法の実装可能なセットをどのように定義し得るかを示し得る。そのような分析のレイヤ化および交互絡合性質により、変成の説明は、前方参照および後方参照を有し得、読み手が、いくつかの特性のより良い諒解を獲得するために異なるセクションを参照すること要求し得る。変成を用いた構造化データ折り畳み（ＳＤＦＴ）は、データ構造および方法論を使用する変成上に築かれ、変成された（transmute）データの記憶可能性（storability）、送信可能性（transmissibility）、モジュラリティ、可搬性、カプセル化可能性（encapsulability）および／または時間互換性を可能にするのを助け得る。
【００１９】
[0017]ＮＵＴＳ設計内では、ＳＤＦＴは、低レベル演算のセットであり、Ｎｕｔをより容易に構築するための基本的なビルディングブロックと考えられ得る。しかしながら、ＳＤＦＴは、アプリケーション内のいくつかの退屈なおよび／または繰返しのデータ変成を簡略化するために、部分的または全体的に、独立して使用され得る。ＳＤＦＴは、コンピュータ通信プロトコルが、２つの異なるアプリケーション間の同じセッション内の変成シーケンスおよび／または変成パラメトリック分散を動的に切り替えることを可能にし得る。現在、そのような単一セッション動的切替えは、重要なプログラム的運動であり得る。Ｎｕｔを築くためにＳＤＦＴを使用することは必要な要件でないことがあるが、それの特徴は、より好都合に、明らかにおよびフレキシブルにＮｕｔを築くのを助け得る。ＳＤＦＴは、状態遷移シーケンスの可逆性に関する明確に定義された挙動に伴う遷移イベントの無限変動を可能にするデータ状態遷移方法論としてさらに説明され得、単純なコンテキストに応じたやり方で必要な属性およびデータを持続させるための反復的カプセル化技法を与え得る。ＳＤＦＴは、日常的なプログラミング問題の混乱を受け付け、受け入れ、理論的証明が経験的証明に従属し得る編成原理の実際的なセットを提示し得る。
【００２０】
[0018]図５は、変成編成原理が、どのようにデータ演算をデータ変成５１０として見なし得るかを示し、データ変成５１０は、入力データソース５０２と属性５０４とを要求し得、変成されたデータ５１２と、関連する属性５１４とを出力し得る。データの明確に定義された操作、演算、コンバージョンおよび／または変換は、あるタイプの変成５１０として分類され得る。ＴＯＰは、モジュラーの、可搬のおよび／または自己記述的なやり方でデータを変成する方法の無矛盾なセットを系統的に構築することを可能にし得る。
【００２１】
[0019]図６中の表は、共通データ演算のサンプルセットと、ＴＯＰを使用してそれらがどのように分類され得るかとを示す。変成は、知覚においておよび実際に、旧来分離されていることがある基本的なデータ演算のクラスを包含し得る。そのようなことは、プログラマーが暗号およびデータ圧縮について説明するとき、そうであり得、データ演算のこれらの２つのクラスは、一般に、データに対する２つの極めて別個の異なった演算と考えられ得る。各演算のアルゴリズム差以外に、ＴＯＰの観点を通して、これらの演算は、あるタイプのサイファ化（ciphering）変成および圧縮変成と見なされ得る。表において、「ＪＳＯＮシリアル化」は「ｊｓｏｎ」の演算を用いた「ｓｅｒｉａｌｉｚｅ」変成として分類され得、したがって、実行可能変成コマンドは、「ｓｅｒｉａｌｉｚｅ  ｊｓｏｎ」として述べられ得る。１つのデータに対するＡＥＳ対称サイファ暗号化コールは、「ａｅｓ」の演算を用いた「ｓｃｉｐｈｅｒ」変成として分類され得、したがって、実行可能変成コマンドは、「ｓｃｉｐｈｅｒ  ａｅｓ」として述べられ得る。当業者は、表にリストされているすべての他のタイプのデータ演算を容易に認識し、変成分類および演算カテゴリー分類の編成パターンに従い得る。
【００２２】
[0020]図７は、逆方向モードまたは逆転演算での変成の図を示す。この図は、反対方向に流れるデータフロー矢印を除いて、図５と同等である。変成５１０は、ブロック７１０によって示されている明確に定義された可逆アルゴリズムを有し得る。可逆変成７１０は、変成されたデータソース７１２と属性７１４とを入力として要求し得、元のデータ７０２と関連する属性７０４とを出力し得る。可逆変成と同様の概念を呈し得る可逆算出と呼ばれる算出のフィールドが存在し得る。各編成原理の目標のいくつかの差があり得る。可逆算出は、演算が一般的な算出の可能なエネルギー効率のためにシリコンレイヤまで実装され得る一般化された可逆算出言語の存在を理論化し得る。可逆変成は、限定はしないが、書き込まれるコードを最小限に抑えること、プログラム的エラーを最小限に抑えること、好都合な鍵管理、鍵発生を簡略化すること、可搬自己記述的データを構造化すること、データ操作概念を正規化すること、変成を実施するプログラミング言語非依存の方法を導入すること、および／または複雑な暗号データ構造を築くことを簡略化することなど、利益のためにＴＯＰを具体的に実装することを目的とし得る。
【００２３】
[0021]図８は、不可逆変成の図式表現を示す。順方向モードでの変成８１０は、データ８０２および属性８０４に対する変成を実施し得、これは、変成されたデータ８１２と属性８１４とを生成し得るが、これらの出力は、その変成が入力に対して実施し得るタイプの操作とともに、不可逆性質のものであり得る。そのような不可逆変成は、ハッシュ、ＭＡＣ、ロッシー（lossy）データ圧縮および他の一方向関数またはデータ操作によって例示され得る。ＴＯＰは、そのような不可逆変成の特性を周囲にオーグメントし得る分析技法を導入し得、それらの逆方向変成特性を定義し得る演算を生成し得る。
【００２４】
[0022]図９は、条件付き可逆変成のブロック図を示す。そのような変成９１０は、明確に定義された可逆アルゴリズムを有し得るが、逆転演算が成功するための追加の入力および／または属性９１４を要求し得る。条件付き可逆変成９１０は、変成されたデータソース９１２および／または属性９１４を入力として要求し得、必須の条件９１６が満たされた場合および満たされたとき、元のデータ９０２および／または関連する属性９０４を出力し得、他の場合、それは、エラー条件９２０で失敗し得る。正しい鍵（属性）の不在がサイファテキストの解読を妨害し得るので、鍵を要求し得るサイファは条件付き可逆変成として分類され得る。
【００２５】
[0023]図１０は、共通データ演算および関数ならびにそれらのそれぞれの変成分類をリストする表である。当業者は、表にリストされているデータ演算および／または関数の一部または全部を認識し得る。例示の目的で、本明細書で提示される材料は、Ｐｙｔｈｏｎバージョン３．６と呼ばれるプログラミング言語およびそれのシンタックス、概念、関数および／または方法を参照し得る。本開示で参照される暗号関数の多くは、Ｐｙｔｈｏｎ標準、ｐｙＣｒｙｐｔｏｄｏｍｅ、ｓｅｃｒｅｔｓｈａｒｉｎｇおよび／またはｐｙＣｒｙｐｔｏライブラリにおいて見られ得る。当業者は、たいていの現代のプログラミング言語およびそれらのそれぞれのライブラリにおいて等価なシンタックス、概念、関数および／または方法を見つけ得る。「ｄｉｇｎ」がデジタル署名のための変成であり、他のニーモニックが本明細書のシンボルおよび略語セクションにリストされ得ることに留意されたい。各変成のさらなる詳細な説明が、図１２中の表において見られ得る。
【００２６】
[0024]図１１は、Ｐｙｔｈｏｎ  ｖ３．６において定義されているコーデックの表である。このリストは、存在している多数のコーデック、新しいコーデックの急増および／またはＰｙｔｈｏｎ  ｖ３．６において定義されているものの制限により、完全でないことがある。「コーデック」は、コード／デコードの省略であり、算出における文字セットのためのマッピングである。文字は、単一のコーデック内の任意であるが一意のバイナリ値を割り当てられ、したがって、文字の完全セットは単一のコーデックを定義し得る。所与のコーデック内のすべての文字が、人間に読取り可能または印刷可能であるとは限らない。コーデックの共通使用法は、異なる言語の異なる文字セットの適切な表現のためのものである。「ｅｎｃｏｄｅ」変成は、所与のデータストリングに対してこれらのコーデック符号化演算のうちのいずれかを実施することが可能であり得る。「ｕｔｆ＿」で開始する名前をもつコーデックは、多くのインターネットベース標準のための国際文字セットの編成原理であり得るユニコード変換フォーマット（ＵＴＦ）に準拠するものを指定し得る。
【００２７】
[0025]図１２は、ここまで説明された変成をそれらの詳細な説明とともにリストする表である。追加の変成は、表中の最後の６つの変成、すなわち、ｋｅｙ、ｃｌｅａｎ、ＴＡＲ  ｇｒｏｕｐ、ｐｒｅｓｓ、ｌｏｃｋおよびｍｏｂｉｕｓによって示されているように、ＴＯＰを使用してフレームワーク内で定義され得る。これらの追加の変成のうちのいくつかは、変成を用いた構造化データ折り畳み（ＳＤＦＴ）ライブラリに固有であり得、いくつかは言語固有であり得、および／または、いくつかはＮＵＴＳに関係する演算であり得る。これは、新しい変成タイプがそれのレパートリーを拡大するように定義および分類されることを可能にすることによるＴＯＰのフレキシブルな性質を示し得る。このフレキシブルな拡大特徴は、ＳＤＦＴライブラリが将来において新しい変成演算に適応し得るような設計によるものである。拡大特徴は、変成演算のより古いバージョンが後方互換性のために遡及的に追加されることをも可能にし得る。そのようなフレキシビリティの利益は、より良い時間互換性の特性を入手する、ＳＤＦＴ処理されたデータのアビリティであり得る。データの時間互換性は、記憶されたデータが、将来のある時点において同じまたは異なるアプリケーションによって容易に処理されることを可能にし得るそれらの特性として定義され得る。時間非互換性は、限定はしないが、アプリケーションファイルフォーマットバージョンの差、異なる文字符号化、使われていないアプリケーションファイルフォーマット、データ演算方法の差、データ演算順番付けの差および／またはデータ演算固有パラメトリック分散から起こり得る。
【００２８】
[0026]図１３は、変成可逆性行列を示す。各変成は、可逆、不可逆および／または条件付き可逆であるものとして指定され得る。そのような指定を行うための基準は、実際の変成の実装されたおよび／または理論的な不足ではなく、変成の理想的な意図に基づき得る。他の場合には、指定は任意であり得る。これは、ソースデータの１２８ビット長ハッシュを生成し得るＭＤ４と呼ばれるｄｉｇｅｓｔ演算によって示され得る。ＭＤ４ハッシュは、ハッシングアルゴリズムにおける望ましくない特徴であり得る衝突に対するそれの感受性により、５１２ビットＳＨＡ２などのハッシュ演算と比較して著しく弱いハッシングアルゴリズムと考えられ得る。ＴＯＰ観点は、ＭＤ４の元の意図のうちの１つを不可逆の一意のハッシュであると認識し、それをそのようにカテゴリー分類することであり得る。そのようなカテゴリー分類は、このタイプの変成を、後のセクションに示されるように追加のＴＯＰ分析を通して、明確に定義され計画された可逆性特性を獲得することから除外しないことがある。ｃｏｍｐｒｅｓｓ変成は、特定の圧縮演算が実施されたことに基づいて可逆指定と不可逆指定の両方に該当し得る。多くの画像および／またはオーディオ圧縮技法は、それらのサンプリング性質により不可逆性を呈し得、１２ＭＢデジタル画像は、チャットアプリケーションを介した効率的な送信のために３６０ＫＢまで圧縮され得るが、人間視覚認知の性質により、画像の一般的な印象は、永続的データ損失にもかかわらず適切に伝達され得る。そのような圧縮された画像は、変換中に廃棄されていることがある多大な量の元のデータにより、不可逆的に修正され得る。
【００２９】
[0027]可逆圧縮変成はｇｚｉｐ圧縮によって例示され得、それは、バイナリデータ内の繰返しビットパターンを識別および低減する原理で動作し得るが、それは、プロセスを逆転させ、元のデータを全体として再生成するのに十分な情報を維持し得る。条件付き可逆変成はＡＥＳ対称サイファによって例示され得、それは、クリアテキスト（cleartext）および対称鍵をとり入れ、サイファテキストを生成する原理で動作し得る。解読プロセスは、元のクリアテキストを生成するために鍵とサイファテキストとをとり得る。したがって、サイファテキストのための正しい対称鍵の提示は、サイファテキストを解読するかまたは暗号化プロセスを逆転させるために満たされなければならない必要な条件であり得る。
【００３０】
[0028]ＴＯＰは、所与の変成演算の方向を示し得る変成モードを、順方向または逆方向のいずれかとして定義し得る。変成の順方向モードは、それの通常プロセスおよび／またはそれの計画された順方向プロセスを実施し得る。変成の逆方向モードは、それの固有の逆方向プロセスおよび／またはそれの計画された逆方向プロセスを実施し得る。図１４中の表は、変成がそれの変成モードに基づいて内部的に実施し得る演算のタイプを示す行列を示す。参照として、表は、「ｓｅｒｉａｌｉｚｅ」および「ｄｅｓｅｒｉａｌｉｚｅ」、または「ｅｎｃｒｙｐｔ」および「ｄｅｃｒｙｐｔ」など、一般に知られている演算名をリストする。ｄｉｇｅｓｔおよびｄｉｇｎの計画された逆方向プロセス、すなわち、「ｄｉｇｅｓｔ」および「ｖｅｒｉｆｉｃａｔｉｏｎ」、「ｓｉｇｎ」および「ａｕｔｈｅｎｔｉｃａｔｉｏｎ」に留意されたい。「ｃｌｅａｎ」変成がそれの変成データ構造に関連する様々な内部データを削除し得る「ｃｌｅａｎ」変成では、削除された過渡的データを再生成するために、適切な追加のデータ、および／または元のデータに対する順方向変成プロセスの再実行なしに、そのような削除されたデータを復帰させることは不可能であり得る。「ｋｅｙ」変成は、変成を実施することに関係する鍵発生および／または管理演算を実施し得る。したがって、鍵発生の固有のランダム性質により、有限時間において決定論的な様式でそのようなプロセスを理論的におよび／またはアルゴリズム的に逆転させることは不可能であり得る。「ｋｅｙ」変成の鍵管理態様（aspect）は、変成が構造化データ折り畳み（ＳＤＦ）のコンテキスト内でどのように働き得るかに対処するとき、後のセクションにおいて詳細に説明され、ｋｅｙ変成の鍵管理態様は、ＳＤＦコンテキストにおいて成功した処理のための適切な鍵構造をセットアップするそれの特性により、可逆カウンターパートを計画することは困難であり得る。
【００３１】
[0029]図１５は、一連の３つの図を示し、それらの各々が、可逆変成を指定され得るｓｅｒｉａｌｉｚｅ変成１５０４例をさらに詳述する。コンピュータプログラミングでは、シリアル化および／またはマーシャリング技法は、複雑な言語固有内部データ構造をとり得、それのコンテンツを、等価なデータストリングまたはデータストリングのセット（これ以降データストリングと呼ばれる）を生成するために系統的に分解し、および／または線形に編成し得る。データストリング形式は、永続的なストレージ、データ送信および／またはさらなる変成に、より好適であり得る。定義によるシリアル化は、それが、発信言語中の元のコンテンツまたはそれの等価物を再構築するために論理的に完全に可逆であることを要求し得る。Ｐｙｔｈｏｎ構造１５１２は、等価なＪＳＯＮストリング１５１６を生成するためにＪＳＯＮ演算１５１４を使用して変成され得、逆方向プロセスは、双方向プロセスフロー矢印によって示されているように可能であり得る。複雑なＰｙｔｈｏｎデータ構造を例示し得る単純なツリーデータ構造が１５２２に示されている。ｓｅｒｉａｌｉｚｅ変成１５２４は、１５２２から等価なストリング１５２６を生成し得る。この出力ストリング１５２６は、次に、プログラムが進むにつれて、記憶、送信および／または変成され得る。
【００３２】
[0030]図１６は、一連の３つの図を示し、それらの各々が、不可逆変成を指定され得るｄｉｇｅｓｔ変成１６０６例をさらに詳述する。この例は、データ１６１２と属性１６０４としてのｄｉｇｅｓｔ長１６１４とを入力として要求し得るｄｉｇｅｓｔ変成としてのＳＨＡ２ハッシュ演算１６１６を示す。ＳＨＡ２ハッシュｄｉｇｅｓｔ変成１６１６は、指定された長さのハッシュ１６１８を生成し得る。Ｐｙｔｈｏｎデータストリング１６２２と２５６ビットの所望のｄｉｇｅｓｔ長１６２４とは、２５６ビット長ハッシュストリング１６２８を生成するためのＳＨＡ２ハッシュ変成１６２６への入力であり得る。
【００３３】
[0031]図１７は、ｖｅｒｉｆｉｃａｔｉｏｎとしても知られる、逆方向モードでのｄｉｇｅｓｔ変成の詳細な例を示す。ＴＯＰでは、これは、変成の計画された逆転と呼ばれることがある。ｄｉｇｅｓｔ変成１７１０は、ｄｉｇｅｓｔストリングＤＧ１  １７１２を出力１７０８として生成し得る順方向モードｄｉｇｅｓｔ変成１７１０を実施するために、データＤ１  １７０２と属性Ａ１  １７０４とを入力として受け付け得る。この変成の逆方向モード１７２０は、ｄｉｇｅｓｔストリングＤＧ１  １７２８が検証された１７３２のか検証に失敗した１７３４のかを示すフラグおよび／または値を出力１７３８として生成し得る逆方向モードｄｉｇｅｓｔ変成１７２０を実施するために、データＤ１  １７２２と、属性Ａ１  １７２４と、ｄｉｇｅｓｔストリングＤＧ１  １７２８とを入力１７３６として受け付け得る。検証のプロセス１７４０は、入力Ｄ１  １７２２および入力Ａ１  １７２４に対して順方向モードｄｉｇｅｓｔ変成１７２０を実施することによって、ｄｉｇｅｓｔストリングＤＧ２  １７２２を生成し得る。出力ｄｉｇｅｓｔストリングＤＧ２  １７２２は、次いで、入力ｄｉｇｅｓｔストリングＤＧ１  １７２８に対して相等性について比較され得る１７３０。比較の結果１７３８は、逆方向ｄｉｇｅｓｔ変成が成功したか否かを示すために何らかの形式で提示され得る。このようにして、このｄｉｇｅｓｔ逆転を計画することは、変成の順方向モードが再処理されることと、困難で時間がかかるおよび／または達成不可能であり得るそのような演算の論理可逆性を見つけることの次善策に依拠するのではなく出力を比較することとを要求し得る。
【００３４】
[0032]図１８、図１９および図２０は、対称サイファとしても知られる、順方向モードおよび逆方向モードでのｓｃｉｐｈｅｒ変成の詳細な例を示す。順方向モードでのｓｃｉｐｈｅｒ変成１８０６は、サイファテキスト１８１０および／または属性１８１２を出力として生成するために、クリアテキスト１８０２と属性１８０４とを入力として受け付け得る。逆方向モードでのｓｃｉｐｈｅｒ変成１８２６は、クリアテキスト１８２２および／または属性１８２４を出力として生成するために、サイファテキスト１８３０と属性１８３２とを入力として受け付け得る。図１９は、ｓａｌｓａ２０対称サイファがｓｃｉｐｈｅｒ変成としてどのように動作し得るかを示す。順方向モードでのｓｃｉｐｈｅｒ  ｓａｌｓａ２０変成１９０６は、サイファテキスト１９１０を出力として生成するために、クリアテキスト１９０２と属性１９０４とを入力として受け付け得る。順方向モードでのこの特定のサイファのための属性は、バイナリ対称鍵、鍵の長さおよび／またはｓａｌｔ値を備え得る。このｓａｌｓａ２０順方向（暗号化）実装形態は、ストリーミングサイファであり得、関数がそれ自体の出力ストリング内に埋め込み得るどんな隠れ属性をも除いて、追加の出力属性が暗号化プロセス中に発生されないことがある。逆方向モードでのｓｃｉｐｈｅｒ  ｓａｌｓａ２０変成１９２６は、クリアテキスト１９２２を出力として生成するために、サイファテキスト１９３０と属性１９３２とを入力として受け付け得る。逆方向モードでのこの特定のサイファのための属性は、バイナリ対称鍵、鍵の長さおよび／またはｓａｌｔ値を備え得る。このｓａｌｓａ２０逆方向実装形態（解読）は、ストリーミングサイファであり得、追加の出力属性が解読プロセス中に発生されないことがある。図２０は、ｓａｌｓａ２０対称サイファが、Ｐｙｔｈｏｎ  ｖ３．６およびＰｙＣｒｙｐｔｏｄｏｍｅライブラリ関数内で表され得るようにサンプルデータに対する変成としてどのように演算し得るかを示す。順方向モードでのｓｃｉｐｈｅｒ  ｓａｌｓａ２０変成２００６は、サイファテキスト２０１０を出力として生成するために、データストリング２００２と、２５６ビット対称秘密鍵および（ｓａｌｔとしての）ｎｏｎｃｅを備える属性２００４とを入力として受け付け得る。Ｐｙｔｈｏｎでは、対称鍵は「バイト」データタイプストリングとして表され得、したがって、鍵長属性は、鍵バイトストリングに対するｌｅｎ（）関数によって容易に導出され得る。逆方向モードでのｓｃｉｐｈｅｒ  ｓａｌｓａ２０変成２０２６は、クリアテキスト２０２２を出力として生成するために、サイファテキスト２０３０と、２５６ビット対称秘密鍵およびｎｏｎｃｅを備える属性２０３２とを入力として受け付け得る。Ｐｙｔｈｏｎでは、対称鍵は「バイト」データタイプストリングとして表され得、したがって、鍵長属性は、鍵バイトストリングに対するｌｅｎ（）関数によって容易に導出され得る。属性２０３２は、元のクリアテキスト２００２を復元するためにこの条件付き可逆変成が逆方向モード（解読）でサイファテキスト２０３０を適切に処理するように属性２００４と等価であることを要求され得る。
【００３５】
変成タイプ
[0033]図２１〜図３５に提示される以下の表および例では、各変成は、この表において指定されている演算に限定されないことがあり、任意の好適な演算が、ＴＯＰを通して分析され得、次いで、特定の変成の演算能力を拡張するためにフレームワークに統合され得る。より詳細に例を示すために、Ｐｙｔｈｏｎ  ｖ３．６シンタックスおよび構成体が使用され得る。等価なデータタイプ、構造、シンタックスおよび／または方法が、当業者によって異なるプログラミング言語において見つけられ、代わりに使用され得る。いくつかの場合には、鍵／値オプションは特定の言語またはライブラリに関連しないことがあり、それは、処理が等価な結果を生成し得る限り、必要に応じて無視または修正され得る。
【００３６】
ｓｅｒｉａｌｉｚｅ／ｃｏｍｐｒｅｓｓ変成
[0034]図２１は、ｓｅｒｉａｌｉｚｅ変成およびｃｏｍｐｒｅｓｓ変成のためのコマンド仕様の表２１０２と、それの使用法を示すサンプル変成コマンドのセット２１０４とを示す。表２１０２は、各変成についての変成名および受付け可能な演算タイプをリストする。末尾の「＝」をもつ列ヘッダは、それの下に提示された値がコマンドシンタックス構築における鍵／値フォーマットにおいて提示され得ることを示す。「入力」列と「出力」列とは、Ｐｙｔｈｏｎ  ｖ３．６のコンテキスト内で変成／演算のための予想されるデータタイプ／構造を指定し得る。たとえば、コマンド「ｓｅｒｉａｌｉｚｅ  ｊｓｏｎ  ｓｏｒｔｋｅｙｓ＝ｔ」は、以下のデータ操作シーケンスを実施し、すなわち、Ｐｙｔｈｏｎデータ構造を入力としてとり、それに対して、真に設定された「ｓｏｒｔ＿ｋｅｙｓ」フラグを用いてｊｓｏｎ．ｄｕｍｐｓ（）を実施し、次いで、データのシリアル化バージョンをもつＰｙｔｈｏｎストリングを出力し得る。このコマンドの逆方向モードは、入力としてのＪＳＯＮフォーマットされたＰｙｔｈｏｎストリングを予想し、それに対してｊｓｏｎ．ｌｏａｄｓ（）を実施し、次いで、Ｐｙｔｈｏｎデータ構造を出力し得る。「ｓｏｒｔ＿ｋｅｙｓ」フラグは、昇順でＰｙｔｈｏｎ辞書構造の鍵を処理するようにｊｓｏｎ．ｄｕｍｐｓ（）関数に知らせる。Ｐｙｔｈｏｎ  ｖ３．６は、鍵によって処理するとき、辞書構造のための無矛盾な処理順序を保証しないことがあり、したがって、得られたＪＳＯＮストリングは、同じデータ構造に対するこの変成の複数の実行間で矛盾し得る。シリアル化変成内で特定の順序で鍵をソートすることは、同じデータ構造に対する複数の実行間の出力としての同等のＪＳＯＮストリングを生じる処理シーケンスの無矛盾性を与え得る。これは、２つのＪＳＯＮストリングが等価であるかどうかを決定する目的で極めて重要になり得、したがって、２つの等価な事前シリアル化データ構造を表し得る。
【００３７】
[0035]表２１０２中のｃｏｍｐｒｅｓｓ変成は、いくつかの異なるロスレス圧縮演算または可逆圧縮を示す。不可逆またはロッシー圧縮演算は、圧縮変成レパートリーを拡張し得るが、可逆変成について説明する目的で、データサイズ低減以上の暗号目的をほとんど与えない一方向関数について説明することは、興味深くも建設的でもないことがある。ＴＯＰ観点から、ロッシー圧縮は、後のセクションにおいて説明されるｄｉｇｅｓｔ変成と同様に分析され、扱われ得る。２１０４中の例では、コマンド「ｃｏｍｐｒｅｓｓ  ｂｚ２」は、バイナリストリング入力に対してｂｚ２圧縮を実施し得、入力ストリングよりもサイズが小さいことも小さくないこともあるバイナリストリング出力を生成し得る。一部のデータは特定の圧縮方式を使用してもはや圧縮可能でなく、これの一例は、ｂｚ２圧縮されたストリングが再び処理され得、さらなるデータサイズ低減が達成されないことがある場合であり得る。
【００３８】
ｅｎｃｏｄｅ変成
[0036]図２２は、ｅｎｃｏｄｅ変成のためのコマンド仕様の表２２０２と、それの使用法を示すサンプル変成コマンドのセット２２０４とを示す。コンピュータサイエンスには多数の符号化方式があり得、この表における参照がすべての知られている符号化方式を表すとは限らない。「ｅｎｃｏｄｉｎｇ＝」列の下にリストされた符号化方式は、Ｐｙｔｈｏｎ  ｖ３．６およびそれの関連する標準ライブラリにおいて見られ得る。当業者は、データを操作し得るアプリケーションに関係する問題を解決することに向かう、すべてのこれらのタイプの符号化へのアクセスを有することの効用を認識し得る。「Ｃｏｄｅｃｓ（９８）」は、本明細書作成の時点における、および図１１中の表において前にリストされた、Ｐｙｔｈｏｎ  ｖ３．６におけるサポートされるコーデックのリストを指す。変成コマンド「ｅｎｃｏｄｅ  ｓｔｒｂｉｎ  ｕｔｆ＿８」は、Ｐｙｔｈｏｎストリングを入力としてとり、それに対してｕｔｆ＿８ユニコード符号化を実施し、その結果をＰｙｔｈｏｎバイトストリングとして出力し得る。変成コマンド「ｅｎｃｏｄｅ  ｕｔｆ  ｕｔｆ＿１６」は、Ｐｙｔｈｏｎストリングを入力としてとり、それに対してｕｔｆ＿１６ユニコード符号化を実施し、その結果をＰｙｔｈｏｎストリングとして出力し得る。変成コマンド「ｅｎｃｏｄｅ  ｂｉｎａｓｃｉｉ  ｈｅｘ」は、Ｐｙｔｈｏｎバイトストリングを入力としてとり、それに対して１６進符号化を実施し、その結果をＰｙｔｈｏｎストリングとして出力し得る。変成コマンド「ｅｎｃｏｄｅ  ｂａｓｅ  ６４」は、Ｐｙｔｈｏｎバイトストリングを入力としてとり、それに対してｂａｓｅ６４バイナリ符号化を実施し、その結果をＰｙｔｈｏｎストリングとして出力し得る。変成コマンド「ｅｎｃｏｄｅ  ｕｔｆ＿８」は、「ｅｎｃｏｄｅ  ｕｔｆ  ｕｔｆ＿８」と等価である。これらの説明は、ｅｎｃｏｄｅ変成コマンドシンタックスにおいて可能にされる転置（permutation）の無矛盾性およびタイプを示し得る。
【００３９】
ｄｉｇｅｓｔ変成
[0037]図２３は、ｄｉｇｅｓｔ変成のためのコマンド仕様の表２３０２と、それの使用法を示すサンプル変成コマンドのセット２３０４とを示す。表２３０２に示されているｄｉｇｅｓｔ変成は、３つのタイプの演算、すなわち、限定はしないが、ｈａｓｈ、ｈｍａｃおよび／またはｃｍａｃを定義する。変成コマンド「ｄｉｇｅｓｔ  ｈａｓｈ  ｍｄ５  １２８」は、ソースデータストリングを入力としてとり、それに対してＭＤ５ハッシュ関数を実施し、長さが１２８ビットである出力ｄｉｇｅｓｔバイトストリングを生成し得る。入力ソースデータストリングがｄｉｇｅｓｔ変成コール中に修正されず、上書きされないことがあり、出力ｄｉｇｅｓｔバイトストリングが、ｄｉｇｅｓｔ変成コールから発生される追加のデータであり得、別個のメモリスペースを与えられ得ることに留意されたい。変成コマンド「ｄｉｇｅｓｔ  ｈａｓｈ  ｓｈａ２  ５１２」は、ソースデータストリングを入力としてとり、それに対してＳＨＡ２ハッシュ関数を実施し、長さが５１２ビットである出力ｄｉｇｅｓｔバイトストリングを生成し得る。変成コマンド「ｄｉｇｅｓｔ  ｈａｓｈ  ｓｈａｋｅ２５６  ｄｉｇｅｓｔｌｅｎ＝３３２」は、ソースデータストリングを入力としてとり、それに対してＳＨＡＫＥ２５６ハッシュ関数を実施し、長さが３３２ビットである出力ｄｉｇｅｓｔバイトストリングを生成し得る。変成コマンド「ｄｉｇｅｓｔ  ｈｍａｃ  ｓｈａ２  ２５６」は、ソースデータストリングを入力としてとり、それに対して、ＳＨＡ２ハッシュを使用してＨＭＡＣ関数を実施し、長さが２５６ビットである出力ｄｉｇｅｓｔバイトストリングを生成し得る。変成コマンド「ｄｉｇｅｓｔ  ｃｍａｃ  ａｅｓ  ２５６」は、ソースデータストリングと２５６ビット対称鍵とを入力としてとり、それに対して、ＡＥＳ２５６サイファを使用してＣＭＡＣ関数を実施し、長さが１２８ビットである出力ｄｉｇｅｓｔバイトストリングを生成し得る。これらのｄｉｇｅｓｔ変成の例示的演算およびタイプのすべては、標準Ｐｙｔｈｏｎライブラリおよび／またはＰｙＣｒｙｐｔｏｄｏｍｅライブラリにおいて見られ得、理論的なおよび／または実装される意味でこれらのサンプルライブラリの外部に存在し得る演算、タイプ、ｄｉｇｅｓｔ長、鍵長および／または他のパラメータのすべての多様性を表すとは限らない。追加の変形態が、ＴＯＰを通して適切に分析され、変成形式に統合され得る。変成形式についてのそのような統合は、既存の変成演算のリファクタリングおよび再テストを要求し得る。
【００４０】
ａｃｉｐｈｅｒ／ｄｉｇｎ変成
[0038]図２４は、ａｃｉｐｈｅｒ変成のためのコマンド仕様の表２４０２およびｄｉｇｎ変成のためのコマンド仕様の表２４０４、２４０６と、それの使用法を示すサンプル変成コマンドのセット２４１０とを示す。変成コマンド「ａｃｉｐｈｅｒ  ｐｋｃｓ１＿ｏａｅｐ  ２０４８」は、バイトストリングと２０４８ビット長ＲＳＡ非対称公開鍵とを入力としてとり、それに対して、５１２ビットＳＨＡ２ハッシュを利用してＲＳＡ  ＰＫＣＳ＃１  ＯＡＥＰサイファ演算を実施し得、長さが２０４８ビットであるサイファ化された（ciphered）バイトストリングを出力として生成し得る。変成コマンド「ａｃｉｐｈｅｒ  ｐｋｃｓ１＿ｖ１＿５  ３０７２」は、バイトストリングと３０７２ビット長ＲＳＡ非対称公開鍵とを入力としてとり、それに対してＲＳＡ  ＰＫＣＳ＃１  ｖ１．５サイファ演算を実施し得、長さが３０７２ビットであるサイファ化されたバイトストリングを出力として生成し得る。これらのａｃｉｐｈｅｒ変成の逆方向モードは、元のクリアテキストを生成するために、バイトストリングとしてのサイファテキストと、適切なＲＳＡ鍵の非公開部分とを入力として要求し得る。
【００４１】
[0039]変成コマンド「ｄｉｇｎ  ｐｋｃｓ１＿ｖ１＿５  ２０４８」は、バイトソースストリングと２０４８ビット長ＲＳＡ非対称非公開鍵とを入力としてとり、それに対して、５１２ビットＳＨＡ２ハッシュを利用してＲＳＡ  ＰＫＣＳ＃１  ｖ１．５デジタル署名演算を実施し得、長さが２０４８ビットであるｄｉｇｅｓｔバイトストリングを出力として生成し得る。「ｄｉｇｅｓｔバイトストリング」という用語は「デジタル署名バイトストリング」と互換的に使用され得、これは、ＴＯＰが、これらの出力を同様の機能を与えるものと見なし得、したがって「ｄｉｇｅｓｔ」変数名で呼ばれるそのようなバイトストリングを記憶し得るからであることに留意されたい。変成コマンド「ｄｉｇｎ  ｄｓｓ  １０２４  ｈａｓｈｔｙｐ＝ｓｈａ２」は、バイトソースストリングと１０２４ビット長ＤＳＡ非対称非公開鍵とを入力としてとり、それに対して、５１２ビットＳＨＡ２ハッシュを利用してＦＩＰＳ−１８６−３モードでＤＳＳデジタル署名演算を実施し得、長さが１０２４ビットであるｄｉｇｅｓｔバイトストリングを出力として生成し得る。変成コマンド「ｄｉｇｎ  ｄｓｓ  ２５６」は、バイトソースストリングと２５６ビット長ＥＣＣ非対称非公開鍵とを入力としてとり、それに対して、５１２ビットＳＨＡ２ハッシュを利用してＦＩＰＳ−１８６−３モードでＤＳＳデジタル署名演算を実施し得、長さが２５６ビットであるｄｉｇｅｓｔバイトストリングを出力として生成し得る。これらのｄｉｇｎ変成の逆方向モードは、それを認証するために、ｄｉｇｅｓｔバイトストリング（デジタル署名）と、ソースバイトストリングと、適切な非対称鍵の公開部分とを入力として要求し得る。
【００４２】
ｄｅｒｉｖｅ変成
[0040]図２５は、ｄｅｒｉｖｅ変成のためのコマンド仕様の表２５０２、２５０４、２５０６と、それの使用法を示すサンプル変成コマンドのセット２５１０とを示す。サンプル演算ｐｂｋｄｆ２、ｈｋｄｆおよびｓｃｒｙｐｔは、鍵導出関数および／または鍵伸張関数（key stretching function）としても知られ得る。ｄｅｒｉｖｅ変成の基本機能は、ユーザに知られ得るバイナリまたは文字データストリングから所望の長さの１つまたは複数の対称鍵を導出することであり得、鍵導出関数の共通使用法は、パスワードまたはパスフレーズから（１つまたは複数の）適切に形成された対称暗号鍵を導出することであり得る。変成コマンド「ｄｅｒｉｖｅ  ｐｂｋｄｆ２  ｋｅｙｌｅｎ＝２５６  ｉｔｅｒａｔｉｏｎｓ＝１０００００」は、文字データストリング（パスワードまたはパスフレーズ）を入力としてとり、それに対して、ＳＨＡ２  ５１２ビットハッシュ関数と、ｓａｌｔとしてのランダムに発生された５１２ビット初期化ベクトルと、１００，０００に設定された反復カウントパラメータとを使用してＰＢＫＤＦ２演算を実施し得、２５６ビット長バイトデータストリングである対応する対称鍵を生成し得る。変成コマンド「ｄｅｒｉｖｅ  ｈｋｄｆ  ｋｅｙｌｅｎ＝２５６  ｎｕｍｋｅｙｓ＝４」は、バイトデータストリングを入力としてとり、それに対して、ＳＨＡ２  ５１２ビットハッシュ関数と、ｓａｌｔとしてのランダムに発生された５１２ビット初期化ベクトルとを使用してＨＫＤＦ演算を実施し得、その各々が２５６ビット長バイトデータストリングである４つの関係する対称鍵の対応するセットを生成し得る。変成コマンド「ｄｅｒｉｖｅ  ｓｃｒｙｐｔ  ｋｅｙｌｅｎ＝１２８  ｍｏｄｅ＝ｌｏｇｉｎ」は、データストリングを入力としてとり、それに対して、ｓａｌｔとしてのランダムに発生された５１２ビット初期化ベクトルを使用してログインモードＳＣＲＹＰＴ演算を実施し得、２５６ビット長バイトデータストリングであり得る対応する対称鍵を生成し得る。ｄｅｒｉｖｅ  ｓｃｒｙｐｔ変成のログインモードは、３つのパラメータｎ、ｒおよびｐを表２５０６中に示された値に設定することの省略表現であり得る。これらのパラメータ値は、ＳＣＲＹＰＴアルゴリズムのオーサーの示唆された設定であり得る。
【００４３】
[0041]ｄｅｒｉｖｅ変成のＴＯＰ手法は、バイモーダル演算を示唆し得る。データモード：変成が（後のセクションにおいて詳細に説明されることになる）どの鍵スタックとも関わらず、あるタイプのデータソースストリングのみと関わり得る場合、それは、この入力データソースストリングを変成し、それを、（１つまたは複数の）対称鍵の形態であり得る変成の出力と置き換え得る。鍵モード：変成が鍵スタックおよびあるタイプのデータソースと関わり得る場合、それは、鍵スタック中に存在する対応する鍵ソース材料を変成し得、その鍵ソース材料を置き換え、それにより、暗号で使用可能な（１つまたは複数の）対称鍵を導出し、それを鍵スタック中に配置し得る。これらの文は、鍵スタックと鍵管理とが変成監査記録またはＴＡＲおよび依存変成のコンテキスト内で説明されるとき、後のセクションにおいてさらに明瞭にされ得る。
【００４４】
ｓｃｉｐｈｅｒ変成
[0042]ＴＯＰを使用して、対称サイファ演算はｓｃｉｐｈｅｒ変成として、およびグループとして分類され得、これらの変成は、数および／または多様性の両方において広範であり得る関連する属性のセットを提示し得る。次の３つの図は、ＴＯＰが、すべてのそれの属性を用いて各ｓｃｉｐｈｅｒ変成をどのように系統的に正規化し、同じ出力ストリングにカプセル化し得るかを示す。このタイプの属性埋込み技法は、多くのタイプの演算のための様々な関数およびライブラリにおいて見られ得る。しかしながら、そのような埋込み技法のための広く受け入れられた標準は極めて少ないことがある。ＴＯＰは、変成を用いた構造化データ折り畳みまたはＳＤＦＴと呼ばれる特徴をサポートする異なった目的のためにすべてのｓｃｉｐｈｅｒ変成に適用され得る無矛盾な方法論を提案し得る。そのような方法論が広く使用されている標準になり得るかどうかは、本明細書の範囲外であり得るが、特に、ＴＡＲおよびＳＤＦＴ構成体および方法について後で説明するとき、リーダーは、ＴＯＰフレームワーク内のそれの使用法の考えられる利益を認識し得る。
【００４５】
[0043]図２６は、ｓｃｉｐｈｅｒ変成のためのコマンド仕様の表２６０２と、それの使用法を示すサンプル変成コマンドのセット２６０４とを示す。表は、３つのタイプのｓｃｉｐｈｅｒ演算、すなわち、ａｅｓ、ｃｈａｃｈａ２０およびｓａｌｓａ２０を示す。これは、知られている対称サイファの完全なリストではないが、それは、ＴＯＰがどのようにそれらを編成し、それらの使用法を提案し得るかを示すために、それらの関連する多様性を提示し得る。対称サイファは、多かれ少なかれそれらに関連する以下の属性、すなわち、鍵長（ｋｅｙｌｅｎ）、演算モード（モード）、ｓａｌｔタイプ（ｓａｌｔｔｙｐ）、ｓａｌｔ長（ｓａｌｔｌｅｎ）、ブロックサイズ（ブロック）、サイファ演算タイプ（タイプ）、および／またはパディング（ｐａｄ）を有し得る。鍵長は、クリアテキストからサイファテキストを生成するためにサイファにおいて使用され得る秘密対称鍵の長さを指定し得る。ＡＥＳサイファでは、それらは、表に示されているように少なくとも１０個の異なる演算モードを有し得る。たいていの対称サイファは、その使用がより良いセマンティックセキュリティを促進し得る特定のタイプ（ｉｖまたはｎｏｎｃｅ）および特定のｓａｌｔ長のｓａｌｔ（ランダム値）の入力を要求し得る。対称サイファは、少なくとも３つの異なる演算タイプ、すなわち、ブロックサイファ、ストリームサイファおよび／またはＡＥＡＤサイファを与え得る。より新しいモードが提案され得、それらは、追加の変成バリアントとしてＴＯＰを使用して統合され得る。ブロックモードサイファは、パディング方法論、ｐａｄ測位、ｐａｄタイプおよび／またはｐａｄ長を備える追加の属性を要求し得る。
【００４６】
[0044]セクション２６０４中の例では、変成コマンド「ｓｃｉｐｈｅｒ  ａｅｓ  ２５６  ｍｏｄｅ＝ｏｆｂ」は、バイトデータストリングと２５６ビット対称鍵とを入力としてとり、提示された鍵とランダムに発生された１２８ビット初期化ベクトルとを用いたＡＥＳ−２５６  ＯＦＢモードストリーミングサイファを使用して入力データストリングを暗号化し、（後のセクションにおいて説明されることになる）図２７において指定されているように無矛盾な鍵／値フォーマットにおいてフォーマットされた出力バイトストリングのヘッダ中に埋め込まれた、プロセスに関与するサイファテキストおよびすべての関連する属性から構成され得る、出力ストリングを生成し得る。変成コマンド「ｓｃｉｐｈｅｒ  ａｅｓ  １２８  ｍｏｄｅ＝ｇｃｍ」は、バイトデータストリングと１２８ビット対称鍵とを入力としてとり、提示された鍵と１２８ビットｎｏｎｃｅとを用いたＡＥＳ−２５６  ＧＣＭモードＡＥＡＤストリーミングサイファを使用して入力ストリングを暗号化し、図２７において指定されているように無矛盾な鍵／値フォーマットにおいてフォーマットされた出力ストリングのヘッダ中に埋め込まれた、プロセスに関与するサイファテキストおよびすべての関連する属性から構成され得る、出力バイトストリングを生成し得る。ＡＥＡＤは、関連データを用いた認証される暗号化の頭字語であり、単一の関数コール内に対称サイファのサイファ能力とともに認証機能を埋め込むことの標準化されたまたはよく知られている方法であり得る。変成コマンド「ｓｃｉｐｈｅｒ  ｃｈａｃｈａ２０  ２５６」は、バイトデータストリングと２５６ビット対称鍵とを入力としてとり、提示された鍵と６４ビットｎｏｎｃｅとを用いたＣＨＡＣＨＡ２０ストリーミングサイファを使用して入力ストリングを暗号化し、図２７において指定されているように無矛盾な鍵／値フォーマットにおいてフォーマットされた出力ストリングのヘッダ中に埋め込まれた、プロセスに関与するサイファテキストおよびすべての関連する属性から構成され得る、出力ストリングを生成し得る。変成コマンド「ｓｃｉｐｈｅｒ  ｓａｌｓａ２０  １２８」は、バイトデータストリングと１２８ビット対称鍵とを入力としてとり、提示された鍵と６４ビットｎｏｎｃｅとを用いたＳＡＬＳＡ２０ストリーミングサイファを使用して入力ストリングを暗号化し、図２７において指定されているように無矛盾な鍵／値フォーマットにおいてフォーマットされた出力バイトストリングのヘッダ中に埋め込まれた、プロセスに関与するサイファテキストおよびすべての関連する属性から構成され得る、出力バイトストリングを生成し得る。
【００４７】
[0045]図２７は、ステップ１が入力フォーマットを示し、ステップ２が出力フォーマットを示す２つのステップのシーケンスにおけるｓｃｉｐｈｅｒ出力ストリングのための出力構造フォーマットを示す。「ヘッダ」は、出力メッセージに対するｓｃｉｐｈｅｒ変成の可変長鍵値ｕｔｆ８符号化パラメータストリングである。ステップ１において、ｓｃｉｐｈｅｒは、ｐａｄ長の随意のパディングが必要に応じてメッセージの最後に通常配置された可変長のメッセージバイトストリング「メッセージ」を入力として受け付け得る。メッセージは、選定されたサイファによって推奨され得るようなｓａｌｔ値が前に付加されていることがある。パディングは、ブロックモード対称サイファの必要な要件であり得る。特定のパディング方法論がプログラマーによって指定されない場合、デフォルトパディング方法論が使用され、メッセージの最後に付加され得る。このメッセージおよびパディングは、プレーンテキストと呼ばれることがある。選定されたサイファは、次に、ステップ２に示されているように、入力プレーンテキストを処理し、暗号化されたメッセージと呼ばれることがある出力を生成し得る。選定されたｓｃｉｐｈｅｒ変成は、次に、埋め込まれたヘッダを、文字ストリングフォーマットにおける印刷可能な鍵／値ペアとして準備し得、ここで、鍵はパラメータタイプを表し得、値はそれらのそれぞれの設定を表す。鍵／値の詳細は、次のセクションにおいて説明される。ヘッダストリングが生成され得ると、変成は、ヘッダサイズと呼ばれるこのヘッダストリングの長さを計算し得、２バイト長の符号なしビッグエンディアン整数としてフォーマットされ得る。２バイトは、０から２16（６５，５３６）までの値に及び得、この特定のフォーマットにおいて予見可能な将来についての対称サイファのためのすべての属性を記述するのに十分であり得る。次いで、ステップ２は、ヘッダサイズと、ヘッダと、暗号化されたメッセージとを備えるパックされたメッセージを作成することに進み得る。このパックされたメッセージは、ｓｃｉｐｈｅｒ変成からの実際の出力ストリングであり得、したがって、それは、変成されたデータに関連するすべての属性を成功裡にカプセル化し、埋め込んでいると考えられ得る。逆方向ｓｃｉｐｈｅｒ変成のデータフローは、逆方向でこのプロセスに従い得、すなわち、変成コマンドは、実施すべき正確なｓｃｉｐｈｅｒ変成を指定し得、一致する対称鍵とパックされたメッセージとが入力として与えられ得る。ｓｃｉｐｈｅｒ変成は、次いで、パックされたメッセージをアンパックし、ヘッダ中で見つけられるすべての属性を読み取り、記憶し、次いで、暗号化されたメッセージを非サイファ化する（decipher）準備をし得る。対称サイファは、成功した解読を伝達するための決定論的方法を有しないことがある。そのような結果を決定するために重なるようにして検証方法が使用され得る。初歩的方法の一例は、解読されたメッセージから前に付加されたｓａｌｔ値を抽出し、それをヘッダからの保存されたｓａｌｔ値と比較することであり得る。一致するｓａｌｔ値は、成功した解読を示すことがあるが、それを保証しないことがある。ＡＥＡＤモード対称サイファは、暗号化された��ッセージ内に（暗号化の前または後に）データストリングのＭＡＣ（ＣＭＡＣ、ＨＡＳＨまたはＨＭＡＣ）を埋め込み、比較を実施することによって、ある程度うまくこの問題に対処し得る。より洗練された方法は、異なる鍵を使用する、ある形式のメッセージのデジタル署名付きハッシュの認証を要求し得る。後のセクションにおいて示され得るように、ＳＤＦＴおよびＴＡＲの使用は、手続き的に単純で論理的なやり方でのそのような洗練を可能にし得る。これらのハッシュベース方法論のすべてにおいて、データを普遍的に一意に識別するためのハッシング方式に固有の弱点により、解読試みの条件を十分に述べることは、決定論的に不可能であり得る。１つの決定論的方法は、相等性について解読されたメッセージを元のメッセージと比較することであり得るが、長々しいメッセージについて効率のトレードオフがあり得る。
【００４８】
[0046]図２８は、ｓｃｉｐｈｅｒ変成の出力構造フォーマットにおけるヘッダストリングのためのパラメータキーワードおよび仕様の表を示す。この属性表のために選定されたキーワードは、当業者に十分に自己記述的および／または自己説明的（self-explanatory）であり得る。属性値の例が右側の列に示されている。リストされた最初の属性、すなわち、ヘッダサイズは、１６ビットバイナリ符号なしビッグエンディアン整数値として提示され得る唯一の属性であり得、ヘッダ中に存在する最初のフィールドであり得る。このヘッダサイズは、印刷可能なフォーマットにおいてこの特定のｓｃｉｐｈｅｒ変成の属性を記述し得る、後続するバイト数を示し得る。属性フォーマットは、属性値の範囲および長さの変動性を可能にするために印刷可能であるように選定されていることがある。ｓａｌｔ値（ｓａｌｔ＿ｖａｌ）とＭＡＣストリング（ｍａｃ＿ｖａｌ）とを備える、実行中のプログラムにおけるバイナリストリングとして当然存在し得るすべての属性値が、印刷可能な文字の選好を満たすためにｂａｓｅ６４に符号化され得る。
【００４９】
[0047]このようにして、ｓｃｉｐｈｅｒ変成の出力ストリングは、選定されたｓｃｉｐｈｅｒの委細に応じて属性の１つまたは複数のカプセル化レイヤを備え得る。図２９は、ＡＥＡＤモードｓｃｉｐｈｅｒ変成のための反復的埋込みメッセージカプセル化の図を示す。ＡＥＡＤモードＡＥＳサイファは、リストされた後続のレイヤを内側レイヤから外側レイヤに出力し得る。メッセージ準備レイヤ２９１０が、適切なｓａｌｔ値２９１２と組み合わせられたサイファ化されるべきクリアテキストメッセージ２９１４を備え得る。この準備されたメッセージ２９１０は、選定されたＡＥＡＤサイファで暗号化され得、選定されたＡＥＡＤサイファは、次いで、サイファプロセスの一部として、ＭＡＣ値および追加のデータ２９２２を追加として生成し得、この組み合わせられたメッセージをＡＥＡＤサイファ出力２９２０と呼ぶことがある。このＡＥＡＤサイファ出力２９２０は、暗号化されたメッセージ２９３４と呼ばれることもある。暗号化されたメッセージ２９３４は、ヘッダ２９３２を生成するために図２８からのキーワード／値ヘッダ方法を使用してパラメータ化され得る、ｓｃｉｐｈｅｒプロセスからの関連する属性を有し得、この組合せは、ｓｃｉｐｈｅｒパックされたメッセージ（scipher Packed Message）２９３０と呼ばれることがある。このｓｃｉｐｈｅｒパックされたメッセージ２９３０は、ｓｃｉｐｈｅｒ変成をコールしたＴＡＲに関連し得るＮＳｓｔｒ構造２９４０のｏｂｊポインタまたは変数２９４４に記憶され得る、選定されたｓｃｉｐｈｅｒ変成の出力であり得る。ＮＳｓｔｒの構造は、後のセクションにおいてより十分に説明される。また、他の属性２９４２が、ＴＡＲ、鍵スタック、ダイジェストおよび／またはステータスフラグを備えるＮＳｓｔｒ構造と呼ばれるこのデータストレージユニットに記憶され得る。ＮＳｓｔｒ構造２９４０中のｏｂｊポインタまたは変数２９４４は、クリアテキストメッセージ２９１４の開始点であったことがあり、したがって、反復的経路２９５０が、可能であり得、オブジェクト２９４４について、それが処理中であり得るＴＡＲによって要求される数のネスト化（nested）カプセル化だけ存在し得、それ自体がＮＳｓｔｒ構造２９４０の属性２９４２に記憶され得る。
【００５０】
[0048]ｓｃｉｐｈｅｒパックされたメッセージ２９３０のヘッダ２９３２中で、対称サイファ、それのモードおよび使用される属性値の記述を備えるパラメータが、図２８にリストされているキーワードによって完全におよび正確に記述され得る。この点について、ＴＯＰ手法は、データをセキュアにするための非暗号プロセスおよび手続きの不明瞭化および隠蔽に依拠せず、むしろ、変成として使用されているサイファの理論的なおよび実装されたセキュリティにのみ依拠し得る。これは、初期観測に関して有意であるように見えないことがあるが、それ自体で変換の出力に埋め込まれたデータ変換の関連する詳細のそのような明快さが、それを適切に処理するためにハードワイヤードプログラムよりも自己記述的データにより多く依拠し得る新規の方法論および設計に最終的に役立ち得ることが、後で示され得る。この手法は、データストレージサイエンスの最下位レイヤのうちのいくつかにおいてデータに対して動作するデータ中心設計およびデータ中心モデルにおける基本的なプリミティブのうちの１つを系統立てるのを助け得る。ＮＵＴＳは、後のセクションにおいて示され得るように、データ中心設計およびモデルに大きく依拠し得る。
【００５１】
[0049]図３０は、ｌｏｃｋ変成のためのコマンド仕様の表３００２と、それの使用法を示すサンプル変成コマンドのセット３０１０とを示す。ｌｏｃｋ変成は、図１２中の表にリストされている追加の変成のうちの１つであり、それは、図６５〜図７７で詳細に説明されるようにＮＵＴＳからの変数ロックの実施形態であり得る。変数ロックは、ｓｓｌｏｃｋと、ｏｒｌｏｃｋと、ｍａｔｌｏｃｋと、ｘｏｒｌｏｃｋと、ｈａｓｈｌｏｃｋとを備える、秘密メッセージを暗号でロックするいくつかの異なる方法を提示し得る。変数ロックの特徴は、正規化された系統的で理路整然としたやり方で秘密メッセージをサイファ化するプロセスにおいていくつかの暗号鍵を入力し、使用するアビリティであり得る。ＴＯＰ手法は、単純で好都合な様式でそのようなロッキング技法を実装する簡潔な方法を可能にし得る。セクション３０１０の例では、変成コマンド「ｌｏｃｋ  ｏｒｌｏｃｋ  １２８  ｎｕｍｋｅｙｓ＝１０  ｓｃｉｐｈｅｒｋｅｙｌｅｎ＝１２８」は、バイトデータストリングと、最高１０個の１２８ビットの同等の対称鍵とを入力としてとり、「ｓｃｉｐｈｅｒ  ａｅｓ  １２８  ｍｏｄｅ＝ｅａｘ」変成コマンドを使用して入力ストリングを暗号化し、サイファテキストと、関連する埋込み属性とを備える出力ストリングを生成し得る。変成コマンド「ｌｏｃｋ  ｍａｔｌｏｃｋ  ２５６  ｎｕｍｋｅｙｓ＝５」は、バイトデータストリングと、５つの２５６ビット対称鍵とを入力としてとり、各鍵についての「ｓｃｉｐｈｅｒ  ａｅｓ  ２５６  ｍｏｄｅ＝ｅａｘ」変成コマンドを使用して入力ストリングを反復的に暗号化し、サイファテキストと、関連する埋込み属性とを備える出力ストリングを生成し得る。変成コマンド「ｌｏｃｋ  ｓｓｌｏｃｋ  ２５６  ｎｕｍｋｅｙｓ＝４  ｔｈｒｅｓｈｏｌｄ＝２」は、バイトデータストリングと、少なくとも２つの２５６ビットｔｉｎｅｓ２５６秘密共有鍵とを入力としてとり、供給された秘密シェアを用いたＳｈａｍｉｒの秘密共有方法の実装形態を使用して入力ストリングを暗号化し、サイファテキストと、関連する埋込み属性とを備える出力ストリングを生成し得る。変成コマンド「ｌｏｃｋ  ｓｓｌｏｃｋ＿ｂ  ２５６  ｎｕｍｋｅｙｓ＝６  ｔｈｒｅｓｈｏｌｄ＝３」は、バイトデータストリングと、少なくとも３つの２５６ビットｔｉｎｅｓｉｄｘ１２８秘密共有鍵とを入力としてとり、供給された秘密シェアを用いたＳｈａｍｉｒの秘密共有方法の実装形態を使用して入力ストリングを暗号化し、サイファテキストと、関連する埋込み属性とを備える出力ストリングを生成し得る。変成コマンド「ｌｏｃｋ  ｘｏｒｌｏｃｋ  １２８  ｎｕｍｋｅｙｓ＝６」は、バイトデータストリングと、６つの１２８ビット対称鍵とを入力としてとり、供給された鍵に対してＸＯＲ演算を反復的に実施することによって、計算された鍵を導出し、「ｓｃｉｐｈｅｒ  ａｅｓ  １２８  ｍｏｄｅ＝ｅａｘ」変成コマンドを使用して入力ストリングを暗号化し、サイファテキストと、関連する埋込み属性とを備える出力ストリングを生成し得る。変成コマンド「ｌｏｃｋ  ｈａｓｈｌｏｃｋ  １９２  ｎｕｍｋｅｙｓ＝７」は、バイトデータストリングと、７つの１９２ビット対称鍵とを入力としてとり、供給された鍵の順序付き連結に対してハッシュを実施することによって、計算された鍵を導出し、「ｓｃｉｐｈｅｒ  ａｅｓ  １９２  ｍｏｄｅ＝ｅａｘ」変成コマンドを使用して入力ストリングを暗号化し、サイファテキストと、関連する埋込み属性とを備える出力ストリングを生成し得る。
【００５２】
[0050]各変数ロックタイプの説明および演算モードは、図６０で開始する、変数ロックに関する後のセクションにおいて見られ得る。ＴＯＰ分析および方法は、複数の暗号鍵を潜在的に利用する複雑な反復的ロッキング変形態が簡明で論理的な様式で行われることを可能にし得、将来における異なるタイプのロッキングアルゴリズムの容易な拡張を可能にし得る。また、ＳＤＦＴの鍵管理態様が、プログラマーが比較的容易にそのような複数の暗号鍵を好都合に発生および管理することを可能にし得ることが、後で示され得る。
【００５３】
[0051]図１２、図１３および図１４に提示されているように、ＴＯＰ分析および方法は、当業者が、所与のデータ操作関数をとり、変成演算およびタイプへの正規化に対するそれの適合性を決定することを可能にし得る。図１２中の表は、極めてよく知られているデータ操作のサンプリングを示し得、開発者の幅広いオーディエンスによる使用のために十分であると極めてよく考えられ得る。しかしながら、データ操作関数がこの表において見られないことがあるような場合、その関数を分析し、それを、ＴＯＰ方法、限定はしないが、ロッシー圧縮、ビット分散（bit scattering）、メッセージ分散（message dispersal）、イレージャーコーディング（ＥＣＣ：erasure coding）ならびにメッセージレベルＲＡＩＤ符号化および構造化など、関数を使用してＳＤＦＴフレームワーク内で動作するように手を加えることが可能であり得る。そのような変成拡張のたいていの場合、実際のデータ操作関数を再コーディングすることまたは書き直すことは不要であり得る。事実上、たいていの状況においてそれを行うことは、逆効果であり、手続き的に弱いことがある。データ操作関数を含んでいるライブラリは、変成ライブラリによってアクセスされ得、ＴＯＰ方法は、開発者が、ＳＤＦＴフレームワーク内でうまく挙動するために特定のデータ操作関数の周りに正規化ラッパー関数を与えることを可能にし得る。
【００５４】
変成構造、変成監査記録（ＴＡＲ）および変成を用いた構造化データ折り畳み（ＳＤＦＴ）
[0052]図３１は、表フォーマットにおける様々な変成構造の仕様を示す。構造定義は、構造がＪａｖａｓｃｒｉｐｔ内でどのように定義されるかと同様のネスト化鍵ベース手法に依拠し、これは、それの表現が多種多様なプログラミング言語において容易に複写され得、特定の言語の特色に依拠しないことがあるような、意図的な設計選択であり得る。たとえば、Ｐｙｔｈｏｎ  ｖ３．６は、クラスが定義されることを可能にするが、Ｊａｖａｓｃｒｉｐｔなどのいくつかの言語は、それを可能にしないことがあり、したがって、変成データ構造は、より広い適用可能性のために、それを定義するためにクラスに依拠しないことがある。変成構造は、明確に定義された作業メモリ領域を与え得、それにより、変成の入力および出力が、準備され、処理され、および／または記憶され得る。すべてではないにしてもたいていの変成演算において使用され得るメインデータストレージユニットまたは構造は、ＮＳｓｔｒ構造３１０８と呼ばれる。変成コールに関連するＮＳｓｔｒの少なくとも１つのインスタンスがあり得る。すべての変成構造は、それがどんな構造を表すかを指定する「ｔｙｐ」または構造タイプフィールドを有し得る。ＮＳｓｔｒ構造は、構造および／またはそれのデータの状態を指定する「状態」フィールドをさらに定義し得る。「ｏｂｊ」またはオブジェクトフィールドが単一の値を保持するか、あるいは、それがメモリの別の領域を参照するポインタであるか、のいずれかであり得る。ｏｂｊフィールドは、たいていの変成への入力データが見つけられ得るところであり得る。また、ｏｂｊフィールドは、たいていの変成の出力データが見つけられ得るところであり得る。「ダイジェスト」フィールドは、それが存在する場合、ｏｂｊフィールドによって記憶または参照されたデータのダイジェストを記憶し得る。ダイジェストが生成されていることがある様式は、特定のｄｉｇｎまたはｄｉｇｅｓｔ変成、ならびにその変成コマンドへの供給されたパラメータおよび／または属性に依存し得る。「鍵スタック」は、それが存在する場合、ＫＩＳＳ（後のセクションにおいて説明されることになる、鍵交換仕様構造）構造の単一のインスタンスであり得るか、または、それは、それの演算ＴＡＲに対応する所定の順序でのＫＩＳＳ構造のリストであり得る。鍵スタックは、基本的に、いくつかの変成によって要求され得る様々なタイプの（１つまたは複数の）秘密鍵を保持する。「ｔａｒ」フィールドは、ＮＳｔａｒ構造３１０６のインスタンスを指し得る。
【００５５】
[0053]ＮＳｔａｒ構造３１０６は、ＮＳｓｔｒ構造のｏｂｊフィールドに記憶された入力データに適用され得る特定の変成監査記録（ＴＡＲ）を指定し得る。ＴＡＲは、ＮＳｓｔｒデータの単一の「折り畳み」を生成するために、理路整然とした、および正常に動作する様式でＮＳｓｔｒ中のデータを処理するために十分な知識に裏付けされて順番付けられていることがある論理順序での変成コマンドのコレクションであり得る。ＮＳｓｔｒデータ構造に対してＴＡＲを実施するこのプロセスを、「ラヴェル」関数コールと呼ぶことがある。逆に、「アンラヴェル」関数コールが、可逆変成の固有の特性に依拠する同じＴＡＲを使用してＮＳｓｔｒ構造内で１つの折り畳まれたデータを「展開」し得る。したがって、変成の可逆性は、変成を用いた構造化データ折り畳み（ＳＤＦＴ）における中心特徴になり得る。ＳＤＦＴ方法論は、データに対するよく似たアセンブリライン演算内でオブジェクトを反復的に変成するために、ＮＳｓｔｒ構造に対してＴＡＲを使用し得る。分析は、ＴＡＲにおける各変成コマンドの可逆挙動に対して行われていることがあるので、したがって、ＴＡＲが、逆方向モードまたはアンラヴェル関数コールにおいて求められ得る。このトピックは、そのような動作を可能にし得る追加の必要な成分が以下のセクションにおいて提示され得るように、より深く説明され得る。
【００５６】
[0054]ＮＳｂｉｎ構造３１０２は、Ｐｙｔｈｏｎ  ｖ３．６にのみ関連していることも関連していないこともある特定の関数をサービスし得る。Ｐｙｔｈｏｎ  ｖ３．６では、データのストリングが内部的に記憶され得る様式で区別が行われ得る。それは、「バイト」ストリングまたは文字ストリングとして記憶され得る。バイトストリングデータタイプは、変数内に保持された情報が一連のバイナリバイトデータであり得ることを示し得る。文字ストリングは、変数内に保持された情報が、あるタイプの符号化方式で符号化された文字を表す一連のビットであり得ることを示し得る。Ｐｙｔｈｏｎ  ｖ３．６は、異なる符号化が「文字」ごとの異なるストレージ要件を要求し得るので、特定の文字ストリングをどのように記憶すべきかを最もうまく決定するために、洗練された内部管理方式を採用し得る。一例は、ＵＴＦ−８は、各文字を表すために８ビット長コードユニットを使用し得、ＵＴＦ−１６は、各文字を表すために１６ビット長コードユニットを使用し得ることであり得、これらの変形態は、言語における文字数が英語のアルファベットとはまったく異なり得、したがって、データの８ビットの転置に適合しないことがある、異なる国際文字セットを伝達するために必要であり得る。変成、ＴＡＲおよびＳＤＦＴの好ましい内部シリアル化方法は、ＪＳＯＮであり得、ＪＳＯＮは、Ｐｙｔｈｏｎ「バイト」データタイプをそれ自体のうちの１つにマッピングするためのネイティブサポートを有しないことがある。コンバージョンが試みられた場合、ＪＳＯＮ関数コールは、特定のデータタイプがサポートされないことがあるという何らかの指示をもって急に失敗し得る。ＮＳｂｉｎ構造は、このタイプの状況のために特別に設計され得、「バイト」データストリングと置換され得、したがって、Ｐｙｔｈｏｎ変数をＪＳＯＮ互換にし得る。「バイト」ストリングは、ｂａｓｅ６４文字ストリングに符号化され、ＮＳｂｉｎ構造の「ｂ６４」フィールド内に記憶され得る。バイトストリング変数は、次に、このＮＳｂｉｎ構造を指すようにされ、元のバイトデータを上書きし得る。これらは等価なデータを表し得るが、それらは異なる符号化および構造にあり得る。しかしながら、最終結果は、ＮＳｂｉｎ構造が完全にＪＳＯＮ互換であり得、次に、互換性のないデータタイプによるエラーなしにＪＳＯＮ関数を使用して安全にシリアル化され得ることであり得る。
【００５７】
[0055]ＴＯＰ手法では、この「バイト」データからＮＳｂｉｎ構造へのコンバージョンおよび置換は、図１２および図３３から「ｐｒｅｓｓ」変成と呼ばれることがある。Ｐｙｔｈｏｎ  ｖ３．６では、表３３０２にリストされているｐｒｅｓｓ変成は、有効なＰｙｔｈｏｎ構造または変数をとり、あらゆるバイトストリングを、バイトデータタイプを欠いたＰｙｔｈｏｎ構造を生じ得る等価なＮＳｂｉｎ構造に反復的に変成し得る。当業者は、データシリアル化エラーのそのようなソースを除去するために、Ｐｙｔｈｏｎ  ｖ３．６以外の言語のための適切なｐｒｅｓｓ変成およびそれのＪＳＯＮ関数コールをカスタマイズし得る。「ｐｒｅｓｓ」の逆方向モードは、「ｄｅｐｒｅｓｓ」と呼ばれることがあり、それの元のデータタイプを含むデータ構造が復旧され得るように、コンバージョンおよび置換を反復的に元に戻し得る。
【００５８】
[0056]ＮＳｊｓｏｎ構造３１０４は、完全にＪＳＯＮ互換であり得るデータのみを保持する特に有用な関数をサービスし得る。ＮＳｓｔｒ３１０８について定義されたフィールドを一目見ることは、構造が、それのダイジェストフィールドがＰｙｔｈｏｎ  ｖ３．６におけるバイナリストリング形式またはバイトデータストリングにおいてソースｏｂｊのダイジェスト値を潜在的に保持することにより、ＪＳＯＮシリアル化のために直接サブミットされた場合の、潜在的問題について注意喚起し得る。再び図１２を参照し、この特定の問題のために「ｍｏｂｉｕｓ」変成を再導入する。この説明のこの点より前のｍｏｂｉｕｓ変成の妥当な定義が、変成およびＴＯＰ手法の交互絡合性質により、リーダーにとって完全に明らかに行われるとは限らないことがあることに留意されたい。図３２中のｍｏｂｉｕｓ変成は、所与の構造を、ある形式から別の形式に、環状に、ただしメビウスの帯の場合のようにわずかなねじれを伴って、変成し得る。ｍｏｂｉｕｓ変成は、ＮＳｓｔｒ構造をＮＳｊｓｏｎなどのＪＳＯＮシリアル化可能構造に系統的にコンバートすることによって、変成を用いた構造化データ折り畳みの重要なイネーブラになり得、コンバージョンのプロセスは、変成されたデータとともにＮＳｓｔｒのための演算ＴＡＲを全体として埋め込み、それにより、得られた記憶可能なオブジェクトの自己記述的特性をもたらし得る。ｍｏｂｉｕｓ変成は、好都合なやり方でＳＤＦＴライブラリにおいて構造化データ折り畳みのエッセンス（essence）を実施する一実施形態であり得る。開発者は、ｍｏｂｉｕｓコマンドを除く変成コマンドの論理的組合せを使用して手動でＳＤＦを実施することを選択し得るが、ｍｏｂｉｕｓコマンドは、開発者がＳＤＦＴライブラリの外部でそのステップを実施することを要求し得る、少なくとも１つのエクストラ論理ステップ、すなわち、ｍｏｂｉｕｓコマンドがそれに対しておよびそれから動作しているＮＳｓｔｒデータ構造をＮＳｊｓｏｎなどの別の構造にシリアル化するアビリティを追加する。ｍｏｂｉｕｓ変成は、ＴＡＲにおける最後の変成コマンドであり得る。それの機能のために、これは、ｍｏｂｉｕｓ変成が配置され得る唯一の論理的な場所であり得る。ｍｏｂｉｕｓ変成が処理されるとき、ｍｏｂｉｕｓ変成は、ｍｏｂｉｕｓ変成がそれからおよびそれに対して動作中であることがあるＮＳｓｔｒ構造をとり、それをＮＳｊｓｏｎ構造に変成し得る。ＮＳｓｔｒ構造中に埋め込まれたＴＡＲは、有用なまたはアクセス可能な形式ではもはや存在しないことがあり、したがって、ｍｏｂｉｕｓ変成は、処理されるべき所与のＴＡＲの最後の変成コマンドであり得る。単に、ｍｏｂｉｕｓ変成は、ＮＳｓｔｒ構造をプレスし、それをＪＳＯＮシリアル化し、次いで、それをＮＳｊｓｏｎ構造に記憶し得、それは、記憶され、送信され、ＪＳＯＮシリアル化され、折り畳まれるか、またはそのような構造に対して実施され得る他の有効データ演算が施される。ｍｏｂｉｕｓ変成に対する逆方向モードがあり得るが、この変成を観察するための別のやり方は、それが環状変成であると述べることであり得、順方向モードか逆方向モードかにかかわらず、それは、入力データ構造タイプに応じて特定のデータ変換を実施する。表３２０４は、ＮＳｊｓｏｎがそのバリアントであり得るＮＳｘ構造を示す。図３１において定義されているもの以外の追加の変成構造の必要が将来において生じ、それらがｍｏｂｉｕｓ変成に適応される必要があり得る場合、この表は、ｍｏｂｉｕｓ変成がＮＳｓｔｒ以外の変成構造のためにどのように挙動し得るかを示す。それは、ＳＤＦＴを用いて実際にプログラムすることがなければ完全に明白であるとは限らないことがあるが、ｍｏｂｉｕｓ変成は、復元されたＮＳｊｓｏｎ構造を、それを折り畳んでいることがあるＴＡＲを保持し得るそれの元のＮＳｓｔｒ構造にコンバートするために、復元されたＮＳｊｓｏｎ構造に対してｍｏｂｉｕｓ変成が動作されない限り、復元されたＮＳｊｓｏｎ構造から可能なＴＡＲ処理がないことがあることを論理的に暗示し得る。ＮＳｊｓｏｎ構造を用いたこのｍｏｂｉｕｓスピンサイクルを始動するために、ｍｏｂｉｕｓ（逆転）は、ＮＳｓｔｒ構造を生成し、埋込みＴＡＲにアクセスし、逆方向で埋込みＴＡＲを処理するためにＳＤＦＴライブラリからのｍｏｂｉｕｓ関数コールでキックスタートされ得る。これは、定義によれば逆方向モードで処理されるべき最初のコマンドである、ＴＡＲにおけるｍｏｂｉｕｓ変成コマンドが、それが、キックスタート関数コールによってすでに実施されていることがあり、それにより、それが、そのような逆転中に２回以上ｍｏｂｉｕｓ機能を実施しないことがあるので、処理中に安全に無視され得ることをさらに暗示し得る。この順番付けでは、逆方向モードでのｍｏｂｉｕｓ変成を無視することに失敗することは、ＮＳｓｔｒからＮＳｊｓｏｎおよびその逆に連続的にコンバートするｍｏｂｉｕｓコールの無限発振を潜在的に生成し得る。それは、そのような演算を表す遠回しなやり方であるように見え得るが、それは、出力変成されたデータ中に系統的に埋め込まれ得るかなりコンパクトな双方向ＴＡＲを生成し、それにより、折り畳まれたデータに自己記述的特性をもたらし得る。この特性は、それが、ＳＤＦＴライブラリの実装形態をサポートし得る任意の言語および／またはオペレーティングシステムにわたって無矛盾な再生成可能なやり方でデータに対して演算を実施するために、よく似た解釈されたスクリプトに対して、ただし、順方向モードまたは逆方向モードの両方において作用され得るという点で、新規であり得る。
【００５９】
[0057]図３３は、ｐｒｅｓｓ変成およびｃｌｅａｎ変成のためのコマンド仕様の表３３０２ならびにｋｅｙ変成のためのコマンド仕様の表３３０４と、それの使用法を示すサンプル変成コマンドのセット３３１０とを示す。ｃｌｅａｎ変成は、ＮＳｓｔｒ構造内から過渡的または一時的フィールドを削除するハウスキーピング関数であり得る。いくつかの変成は、処理中に追加の一時的フィールドの必要を有し得、それらを記憶し、それらにアクセスするために、ＮＳｓｔｒ構造内に追加のフィールドを作成し得る。ＮＳｓｔｒ内のそのような過渡的フィールドの作成および使用は、ＴＯＰ手法内でのそれの共存を分析し、他の変成の適切な機能に対するそれの干渉を最小限に抑えた後に、思慮深い様式で行われ得る。ｃｌｅａｎ変成の機能により、ｃｌｅａｎ変成のための逆転モードがないことがあり、したがって、それは安全に無視され得る。この逆転暗示は、ＮＳｓｔｒ構造内の新しい過渡的フィールドを提案するときに考慮に入れられ得、そのフィールドは、変成の逆転モード処理において存在しないことがあり、したがって、逆方向での変成は、それが適切に機能するためにそのフィールドの存在に依存しないことがある。ｃｌｅａｎ変成の重要な関数は、ＴＡＲの処理において使用される完全な鍵スタックの内部コピーを削除することであり得るか、または、それは、鍵スタック内の秘密鍵のみを削除し、ＫＩＳＳ構造を鍵穴にコンバートし得る。これは、ＮＳｓｔｒを記憶のために準備するより前にＮＳｓｔｒを適切にクリーンにすることに失敗することが、特定のＴＡＲ処理において使用されていることがあるいずれかのおよびすべての暗号鍵の記憶を生じ得、それが、折り畳まれたデータとともにクリアテキストに不注意に記憶され得るので、ＳＤＦＴ  ＴＡＲ処理における１つの最も重要な変成であり得る。この状況は、秘密鍵を曝露し（reveal）、折り畳まれたデータ内のいくつかまたはすべてのサイファ化されたデータを危殆化し（compromise）得、これは、データをサイファ化することの意図された目的でないことがある。
【００６０】
[0058]表３３０４では、ｋｅｙ変成が、それの演算のうちのいくつかとともに示されている。この変成は、ＳＤＦＴの鍵管理機能の一部であり得、ＮＳｓｔｒ構造のｔａｒフィールドを参照することによって、主に鍵スタックフィールドに対して動作し得る。ｋｅｙ  ｃｈｅｃｋ変成が、記憶されたＴＡＲを検査し得、鍵テンプレートのリストを発生し得る。鍵スタックが入力された場合、それは、適切なシーケンスにおける正しい鍵タイプが、入力された鍵スタック中に与えられたかどうかを決定するために、そのような鍵テンプレートと比較され得る。たとえば、ＴＡＲが、鍵を要求し得る２つの鍵変成のための２つの異なる２５６ビット対称鍵を要求する場合、それは、リスト中で「ｓｙｍｍｅｔｒｉｃ  ２５６」の２つの鍵テンプレートを発生し、鍵スタックが、そのような鍵を、それが存在し得る場合に含んでいることをＴＡＲが予想することを示し得る。表３５０４は、様々な鍵タイプのうちのいくつかをリストする。空の鍵スタックまたは部分的に埋められた入力鍵スタックも、適切に処理され得る。ＴＡＲがいくつかの鍵を要求する場合に鍵スタックが入力されないことがあるとき、それは、「ｋｅｙ  ｇｅｎｅｒａｔｅ」変成を示し得る。ＳＤＦＴは、鍵発生モードに関わり得、それにより、導出された鍵テンプレートに従う鍵の適切なタイプが作成され、ｏｂｊフィールドに記憶されたデータに対するＴＡＲ処理より前の演算ＮＳｓｔｒ構造へのサブミッションのために鍵スタックに構成され得る。部分的に埋められた鍵スタックが入力され得るとき、部分「鍵発生」モードが関わり得る。ｋｅｙ  ｃｈｅｃｋ変成とｋｅｙ  ｇｅｎｅｒａｔｅ変成とは、鍵スタック中の部分的に供給された鍵が適切なタイプのものであり、適切なシーケンスにあり得るかどうかを協働的に決定し得る。次いで、それは、欠落した鍵のために適切な鍵を発生することに進み得る。このプロセスは、ＳＤＦＴ鍵スタック管理の「欠落した歯」シナリオと呼ばれることがある。鍵変成コマンドを用いたＴＡＲの例は、それが、ＴＡＲを利用したＮＳｓｔｒ構造に対するＳＤＦＴライブラリの適切な演算にとって非常に基本的であると考えられ得、したがって、それが、プログラマーにあらゆるＴＡＲにおいてそれを配置させるのではなく、ラヴェル／アンラヴェル演算に対するあらゆるコールにおいてデフォルトで暗黙的に実施され得るので、あるとしてもごく少数であり得る。ただ、暗号鍵を要求し得るＴＡＲを処理する可能性を有することによって、矛盾なく、暗黙的に、および／または自動的に適切な鍵スタック管理のためのチェックを暗黙的に行うための十分な原因になり得ることがわかり得る。ＴＡＲ逆転プロセスは、適宜に逆順で鍵スタックを処理し得る。鍵スタックモードでのｄｅｒｉｖｅ変成の特色により、厄介な問題が起こり得、それは、依存変成のためのＴＡＲグループ化と呼ばれるそのような状況をＳＤＦＴがどのように扱うかに関して後のセクションにおいて説明される。
【００６１】
[0059]図３４は、鍵交換仕様構造またはＫＩＳＳのための表を示す。この構造は、少なくとも２つの演算モード、すなわち、鍵または鍵穴を有し得る。鍵の属性は、表において定義されているフィールドの一部または全部によって指定され得、他の鍵属性をサポートするために構造を拡張するために、必要に応じて追加のフィールドが追加され得る。暗号演算のＴＯＰ手法は、各暗号変成のために要求される鍵の正確なタイプを指定する一致する鍵穴を要求するためにその変成のビューをアサートすることであり得る。属性は、限定はしないが、鍵自体のための事実上一意のＩＤ、パスフレーズまたはパスワードについての質問またはヒント、鍵の説明などを含み得る。鍵値がＫＩＳＳ構造中に存在し得る場合、それは、単に鍵と呼ばれることがある。鍵値がＫＩＳＳ構造中で欠落していることがある場合、それは、鍵穴と呼ばれることがある。これは、「ｉｍａ」フィールド中の値によって示され得る。フィールド名は、「Ｉ’ｍ  ａ」鍵／鍵穴の短縮形であり得、明快のためにそのように読み取られ得る。「Ｉｎ」と題する列は、ブランクＫＩＳＳ構造を作成し、鍵をＮＳｓｔｒ構造の入力鍵スタックに配置する目的で鍵をブランクＫＩＳＳ構造に挿入するための要求される値を示し得る。「Ｇｅｎ」と題する列は、ＳＤＦＴライブラリ内からのｋｅｙ  ｇｅｎｅｒａｔｅ変成中に自動的に作成され、埋められ得るフィールドを示し得る。ＴＡＲを伴うＳＤＦＴ説明全体にわたって、すべての鍵参照が、適切なタイプのＫＩＳＳ構造と同義であり得る。鍵スタックが、処理されているＴＡＲの特性に厳密に対応し得ることと、変成コマンドをスタックし、特定の形式およびシーケンスにおいて必要な暗号鍵をスタックするこの方法が、無限個の変成変形態、変成のパラメトリック分散および／または連続データ折り畳みを通して入力データが反復的に処理されることを可能にし得ることとは、明らかであり得る。ＴＯＰの説明のこの点において、ＳＤＦＴの様々な構成要素の交互絡合性質と、特定のパートの完全な諒解が完全に線形的に曝露されるとは限らないこととを理解し始め得る。
【００６２】
[0060]図３５は、ＫＩＳＳ演算モードのための表３５０２と、鍵タイプ／フィールド発生マッピングを示す行列のための表３５０４と、鍵タイプ定義のための表３５０６とを示す。表３５０６は、ＳＤＦＴによって認識されるいくつかのタイプの鍵をリストするが、それは、新しい鍵タイプが必要に応じて追加され、統合され得るように、これらに限定されないことがある。少なくとも３つの鍵タイプが、よく知られているベース鍵タイプを使用してＳＤＦＴライブラリのために特別に構造化され得るので、これらは何らかの説明を必要とし得る。鍵タイプ「ｓｙｍｍｅｔｒｉｃｌｉｓｔ」は、対称鍵のアレイまたはリストであり得、単一のＫＩＳＳ構造内に鍵値として記憶され得る。この鍵タイプは、限定はしないが、ｌｏｃｋおよびｄｅｒｉｖｅのような変成をサポートし得る。ｓｓｌｏｃｋおよびｓｓｌｏｃｋ＿ｂと呼ばれる秘密共有ｌｏｃｋ変成は、それぞれ、Ｓｈａｍｉｒの秘密共有アルゴリズムの２つの異なる実装形態を表し得る。ｌｏｃｋ  ｓｓｌｏｃｋ変成は、２５６ビット長鍵における内部インデックス番号および鍵シェアを備える特定のフォーマットにおける秘密シェアを予想し得る。これは、ＳＤＦＴライブラリ内では「ｔｉｎｅｓ２５６」鍵タイプと呼ばれることがある。ｌｏｃｋ  ｓｓｌｏｃｋ＿ｂ変成は、２５６ビット長鍵における内部インデックス番号および鍵シェアを備える特定のフォーマットにおける秘密シェアを予想し得る。これは、ＳＤＦＴライブラリ内では「ｔｉｎｅｓｉｄｘ２５６」鍵タイプと呼ばれることがある。
【００６３】
[0061]表３５０２は、ＫＩＳＳ構造が存在することができる２つのモード、すなわち、鍵（または変成）または鍵穴で、どんな特性がＫＩＳＳ構造に適用され得るかを示す行列である。変成（鍵）モードでは、ＫＩＳＳ構造は、鍵付きダイジェストおよび／またはｄｉｇｎを含み得るあるバージョンのサイファテキストを生成するために実際の暗号鍵を記憶することが予想され得る。したがって、それの記憶は、情報的に使用され得るが、セキュアな様式で永続的にそれを記憶するために、さらに暗号関数を使用して埋め込まれる必要がある。鍵穴モードでは、ＫＩＳＳ構造は、鍵付きダイジェスト、ｄｉｇｎおよび／または導出された鍵を含み得るあるバージョンのサイファテキストを生成するために、適切な暗号鍵をそれの値として受け付けるのに十分な詳細を有することが予想され得る。したがって、それの記憶は必須であり得、それが鍵穴としての鍵値を含んでいないことがあるので、埋込み方法論によってさらにセキュアにされる必要がないことがある。
【００６４】
[0062]表３５０４は、どのフィールドが必須であり、関連し、入力され、および／または発生され得るかを鍵タイプによって示す行列である。表を検査すると、ＫＩＳＳ構造が、様々な暗号演算に関係するｓａｌｔを保持し得ることは、明らかであり得る。これは、ｓｃｉｐｈｅｒ埋込みヘッダに関する説明に照らして冗長であるように見え得るが、ｓａｌｔのその説明は、ｓａｌｔに関する全体像を提示しないことがある。図３７に示されているように、変成に関連する属性３７０４、３７１４の持続性は、いくつかのデータストレージ領域３７３２、３７３４、３７３６および３７３８の間で分散され得る。ＴＯＰ手法は、得られた出力データが、生成されたサイファテキストに関する追加情報を曝露しないことがあるので、得られた出力データとともに、ｓａｌｔがいくつかの暗号演算中に埋め込まれ得ることを示していることがある。しかしながら、鍵スタックモードで処理され鍵導出変成を検査すると、関連するｓａｌｔ値をＫＩＳＳ構造に記憶することが好都合で論理的であり得ると気づき得る。鍵導出関数の一般的な使用方法は、入力としてパスフレーズを受け付け、それをあるｓａｌｔ値と組み合わせ、限定はしないが対称鍵などの適宜に形成された暗号鍵を生成することであり得る。この場合のｓａｌｔの使用法は、セマンティックセキュリティのためのものであり得る。したがって、同じパスフレーズを受け付け得るあらゆる鍵穴が、どんな合理的な理由があり得るとしても、得られた秘密暗号鍵が互いとは異なり得る順序で異なるｓａｌｔを有し得ることは、完全に可能であり得る。この導出された鍵は、一時的な様式で使用され、使用の後に廃棄され、それにより、それの存在の証拠として鍵穴が残るにすぎないことがある。鍵導出の生成物は秘密鍵として使用され得るので、それは一般に永続的にセーブされないことがあるため、それは、どこにそれを記憶し得るか？という質問の論点をぼかし得る。ＴＯＰは、それを、対応する鍵穴に記憶し得、ＳＤＦＴが折り畳まれたデータとともにこの鍵穴を記憶し、それにより、同じパスフレーズを受け付け得る各鍵穴がその記憶をｓａｌｔ値のそれ自体のインスタンスのために充て得ることを選好し得る。プログラマーは、完全に異なるやり方で外部的にＫＩＳＳ鍵穴を記憶し得る。図５の場合と同じである図３７の上部の簡略化された変成図は、ＴＯＰおよびＳＤＦＴの様々な構成要素が導入され得るとき、図３７の下部の図のようになる。表３７２０は、属性の配置を要約する。
【００６５】
[0063]大部分は、ＴＯＰおよびＳＤＦＴを介して分析され、利用可能な変成コマンドのシンタックスおよび多様性に関して前に説明されたが、実際には、ＴＡＲは実はどのようなものなのか？図３６は、ＴＡＲの構造を示し、ＴＡＲのいくつかの例をリストする。セクション３６０２は、変成監査記録またはＴＡＲの一般的な構造を指定する。「ｔａｒ  ｌａｂｅｌ０１」宣言は、それのすぐ下に定義されているＴＡＲの名前またはラベル（label）を示す。すべてのＴＡＲコマンドがＴＡＲラベル宣言に続き、ブランク行が現在のＴＡＲ定義の終了を示す。したがって、多くのＴＡＲが単一のテキストファイルにおいて宣言され得る。ＴＡＲ定義セクションは、それ自体または変成コマンドによる一行のＴＡＲラベルを含み得る。これは、プログラミング言語コンパイラのマクロ特徴と同様であり得、それは、定義をＴＡＲ自体に実際にコピーする必要なしに、よく知られているＴＡＲ構成体を新しいＴＡＲになるように組み合わせるための便利な特徴として使用され得る。変成コマンドは、所望のやり方でターゲットＮＳｓｔｒ構造を処理するために特定のシーケンスにおいて挿入され得る。ＴＡＲ「ｔｅｓｔ＿ａ０１」は、ただ、ＰｙｔｈｏｎデータオブジェクトをＰｙｔｈｏｎバイトデータタイプを欠いた等価構造にプレスし得、他の言語では、それは、「ｐｒｅｓｓ」が言語および／または環境固有であり得るので、同じ関数を実施することも実施しないこともある。ＴＡＲ「ｔｅｓｔ＿ａ０２」は、連続して２回ｐｒｅｓｓ変成を実施する。２回目のｐｒｅｓｓ変成は、データの関数変更を達成しないことがある。これは、ＴＡＲ拡大が働いていることを示す。ＴＡＲ「ｔｅｓｔ＿ａ０７」は、データをプレスし、それをＪＳＯＮストリングにシリアル化し、次いで、ｕｔｆ＿３２符号化を使用してそれをバイトタイプバイナリストリングにコンバートし得る。ＴＡＲ「ｔｅｓｔ＿ａ１７」は、終了ｍｏｂｉｕｓ変成がどのようなものであり得るかを示す。ＴＡＲ「ｔｅｓｔ＿ａ２０」は、データをプレスし、それをＪＳＯＮストリングにシリアル化し、それをｕｔｆ＿８符号化バイナリストリングにコンバートし、２５６ビット対称鍵を用いたｃｈａｃｈａ２０を使用してそれをサイファ化し、次いで、得られたバイナリサイファテキストストリングをｂａｓｅ６４符号化文字ストリングにコンバートする。ｓｃｉｐｈｅｒ変成のための対称鍵は、２５６ビット対称鍵値を保持する単一のＫＩＳＳ構造を含んでいることがあるＮＳｓｔｒの鍵スタック中で予想され得る。代替は、鍵スタックが与えられないことがあり、ラヴェル関数が、適切に発生されたランダム２５６ビット対称鍵をもつ有効な鍵スタックを発生することに進み、ｓｃｉｐｈｅｒ変成を実施するためにそれを使用し、プログラマーが完了時に鍵スタック（したがって、その内部の鍵）のコピーをフェッチすることを可能にすることである。ＴＡＲ「ｔｅｓｔ＿ａ４２」は、ＴＡＲグループおよび依存変成の一例を示し、すなわち、それは、データをプレスし、ＪＳＯＮストリングにシリアル化し、それをｕｔｆ＿８において符号化されたバイナリストリングにコンバートし、鍵スタック中で供給されたパスフレーズから２５６ビット対称鍵を導出し、次い��、導出された対称鍵を使用してデータに対してｃｈａｃｈａ２０暗号化を実施する。最後の２つの変成は、サイファが、導出された鍵に依拠するので、永続的依存性を有し得、したがって、この依存性は、ＴＡＲ内でグループ化され得、先頭＜タグ＞がそのようなものとしてマークされる。順方向モードでは、そのような依存性を視覚的に強調することを除いて、ＴＡＲ定義内でのＴＡＲグループ化の明らかな影響はないことがある。しかしながら、ＴＡＲグループは、ＴＡＲ逆転に関しては有意なロールを果たし得る。ＴＡＲがＴＡＲ逆転プロセスのために準備されているとき、ＴＡＲグループはユニットとしてそのまま保たれ得、それの成分は逆転されないことがある。図４１および図４２は、ＴＡＲ逆転のいくつかの例を示す。ＴＡＲ「ｔｅｓｔ＿ａ６４」は、５つのｓｃｉｐｈｅｒ変成とＤＳＳ  ｄｉｇｎ変成とを実施し得る。このＴＡＲは、特定の順序の様々なタイプおよび長さの６つの鍵で埋められた鍵スタックを予想し得る。ＴＡＲ「ｔｅｓｔ＿ａ６４」に対応し得る鍵テンプレートの簡略表現がセクション３６１０に示され得る。この鍵テンプレートは、入力鍵スタックを妥当性確認（validate）し、および／またはＴＡＲの適切な処理のための有効な鍵スタックを発生するために、暗黙的ｋｅｙ  ｃｈｅｃｋおよび／またはｇｅｎｅｒａｔｅ変成によって使用され得る。
【００６６】
[0064]図３８は、ＳＤＦＴ演算ラヴェルおよびアンラヴェル（またはラヴェルの逆転）のブロック図を示す。ＳＤＦＴにおける２つの中心演算は、「ラヴェル」およびそれの逆、「アンラヴェル」であり得る。ラヴェル演算は、以下の項目、すなわち、データ、ＴＡＲ、鍵スタックおよび／または他の属性の一部または全部を備え得る所与のＮＳｓｔｒを処理し得る。ラヴェル演算は、３８０２内のＴＡＲにおいてリストされている変成のシーケンスに従って３８０２内のソースデータを「ラヴェルする」かまたは折り畳み得３８１０、最終的に、ＮＳｓｔｒ構造３８０４またはＮＳｊｓｏｎ構造３８０６内の構成要素としての出力を生成し得る。アンラヴェル演算は、埋込みＴＡＲにおいてリストされている変成の逆転されたシーケンスに従ってソースＮＳｓｔｒ３８０４またはＮＳｊｓｏｎ３８０６構造を「アンラヴェルする」かまたは展開し得３８２０、最終的に、ＮＳｓｔｒ構造３８０２としての出力を生成し得る。示されるように、ラヴェル／アンラヴェルの対称性が、この設計の興味深い態様であり得る。ＴＯＰ全体にわたって使用され得る用語および観点の無矛盾性に留意されたい。逆方向でのラヴェル演算は、アンラヴェルと等価であり得る。この可逆性原理は、そのような関数の分析を簡略化し得るだけでなく、それは、データの変成に関係するより高次の概念につながり得るモジュラー編成方法に浸透し得る。
【００６７】
[0065]図３９は、ＳＤＦＴラヴェル演算のフローチャートを示す。ＮＳｘ構造を仮定すれば、ラヴェル関数または方法コールは、コールを備えたパラメータ、および／またはＮＳｘ内に埋め込まれたＴＡＲのいずれかを利用して、内部に含まれているデータに対して以下の演算を実施し得、ここで、この場合「ｘ」は任意の変成構造を表す。ｋｅｙ  ｃｈｅｃｋ／ｇｅｎｅｒａｔｅ変成と同様に、ｍｏｂｉｕｓ変成はこのアルゴリズムにとって非常に基本的であると考えられ得、したがって、条件が満たされた場合にｍｏｂｉｕｓ変成が入力データ構造に対して暗黙的に実施され得る３９０６。ラヴェルは、ＮＳｓｔｒ構造に対するそれのコア演算を適切に実施し得るにすぎず、したがって、ＮＳｓｔｒでないＮＳｘ構造が受け渡され得る場合、ＮＳｘ構造は、ＮＳｓｔｒ構造へのコンバージョンを試み得る３９１８。有効なＮＳｓｔｒ３９２４を生成することに失敗することは、適切なエラーコードを引き起こし３９７８、プロセスを急に終了し得る３９８４。内部のデータがラヴェルされるかまたは折り畳まれ得る少なくとも３つの異なる方法があり得、すなわち、第１に、有効なＮＳｓｔｒ内に、ＮＳｓｔｒ構造内のデータに対して実施すべき変成シーケンスを示すＴＡＲが含まれていることがあり、第２に、ＴＡＲラベルの名前が、パラメータとしてラヴェルコールに受け渡され、それにより、ＮＳｓｔｒ構造内のデータに対して実施すべき変成の好ましいセットを示し得、第３に、カスタマイズされたＴＡＲリストが、ラヴェルコールにおいてそれの所与の名前とともにパラメータとして受け渡され、それにより、ＮＳｓｔｒ構造内のデータに対して実施すべき変成の好ましいセットを示し得る。ＴＡＲの準備３９１２は、他のＴＡＲラベル参照を拡大すること、および／または、それを順方向または逆方向のいずれかであり得るトラバーサルモードのために適切に順序付けることを備え得る。図４１および図４２は、ＴＡＲ逆転のいくつかの例を示す。次いで、ｋｅｙ  ｃｈｅｃｋ変成が、ＴＡＲとＮＳｓｔｒ構造とに対して効果的に実施され得る。ｋｅｙ  ｃｈｅｃｋ変成の構成要素は、ＴＡＲを検査することによって鍵テンプレートのリストを導出すること３９３０であり得る。ＴＡＲ、（空であるかまたは部分的にポピュレートされ得る）入力鍵スタックおよび／または鍵テンプレートを使用して、プロセスは、ＴＡＲの適切なトラバーサルのために鍵スタックを構成し得る３９３６。これは、正しいタイプの欠落した鍵を発生すること、適切な順序で鍵を順番付けること、ならびに／または、適切な構造およびタイプについて入力鍵をチェックすることを備え得る。入力鍵タイプと、対応する導出された鍵テンプレートとの不一致は、エラー条件３９４２を生成し、適切なエラーコードを引き起こすこと３９７８につながり、プロセスを急に終了し得る３９８４。プロセスは、次に、適切なシーケンスにおいてＴＡＲにおける各変成コマンドにわたって反復し３９４８、ＮＳｓｔｒ内に含まれているデータに対して指定された変成を実施し得る３９５４。変成コマンド実行中に遭遇され得るエラー３９６０は、適切なエラーコードを引き起こし３９７８、プロセスを急に終了し得る３９８４。ＴＡＲシーケンスの最後が到達されたとき３９４８、エラーがなければ、ラヴェル演算は成功３９６６と見なされ得、プロセスはうまく終わり得る３９７２。
【００６８】
[0066]図４０は、ＳＤＦＴアンラヴェル演算のフローチャートを示す。詳細にアンラヴェルプロセスを指定するのではなく、図３９中のフローチャートと図４０中のフローチャートとを比較することによって、変成の可逆性の対称性を示し得る。２つのフローチャート間の唯一の差は、ＴＡＲ準備ステップ３９１２および４０１２であり得る。あらゆる変成は、双方向で正常に動作する様式で実施するためにＴＯＰを使用して分析および構造化されていることがあるので、アンラヴェルプロセスは、ＴＡＲがどのように提示され得るかを除いて、ラヴェルプロセスと大きく異なる必要がないことがある。アンラヴェルプロセスは、同じコードとして実装されるが、逆方向フラグが示され得るときにわずかな偏差を有し、遭遇されるときにＴＡＲの適切な逆方向順番付けを実施し得る。Ｐｙｔｈｏｎ  ｖ３．６におけるそのようなコールは、「ｏｂｊ．ｒａｖｅｌ（．．．，ｒｅｖｅｒｓｅ＝Ｔｒｕｅ）」という形式をとり得る。対称性は、実際の実装されるコードがはるかに小さくなることを可能にし得、および／または、エラーをプログラムするためのより少数の機会を提示し得る。概念上の利益は、特定の目的のために新しいＴＡＲを構築するときの思考の明快さおよび単純さであり得、すなわち、プログラマーは、その制限内で完全に可逆であるべき適切なＴＡＲシーケンスに依拠し得、アプリケーションのその部分について熟慮する必要がないことがある。利益は、プログラマーがもはやそのようなデータ操作の逆転コードを作成する必要がないことがあるので、データ変成の特定のセットを作成するためのプログラマーの作業量が少なくとも１／２だけ効果的に低減され得ることであり得る。複雑なサイファ化およびロッキング機構を築くことは、多数の暗号鍵を利用する莫大な数のデータ操作を要求し得る。変成編成原理（ＴＯＰ）方法は、個別の、よりエラーを起こしにくいやり方でそのような複雑さにアプローチする、よりまとまりのあるユニット化された方法を達成するのを助け得、したがって、それは、限定はしないが、より無矛盾な、信頼できる、セキュアな、可搬の、理解可能な、包括的な、フレキシブルな、拡張可能なおよび／または複雑なコードおよび／またはデータを可能にし得る。
【００６９】
[0067]図４３は、ＴＡＲ処理中に変成が発生するかまたは要求し得る鍵タイプテンプレートにマッピングされた変成の表を示す。再び鍵管理に関する説明を参照すると、鍵管理のメイン演算のうちの１つは、所与のＴＡＲを分析し、所与のＴＡＲの成功した処理において必要であり得る各鍵のタイプおよび仕様を詳述し得る鍵タイプテンプレートの対応するリストを生成することであり得る。表３５０６は、ＳＤＦＴ内で定義される鍵タイプのうちの少なくとも９つのタイプをリストする。表４３００は、各変成演算のマッピングを示し、各変成演算のマッピングは、それがラヴェル／アンラヴェルプロセスによって要求し得る鍵および対応する鍵タイプまたは「ｋｅｙｔｙｐ」を要求し得る。鍵テンプレートは、限定はしないが、鍵長または「ｋｅｙｌｅｎ」など、各鍵タイプに関連するいくつかの属性を有し得る。簡潔および簡略化された説明のために、２５６ビット長対称鍵を「ｓｙｍｍｅｔｒｉｃ  ｋｅｙｌｅｎ＝２５６」または「ｓｙｍｍｅｔｒｉｃ  ２５６」として表され得る鍵テンプレートを有するものとして示し得るが、実際の実装では、編成された様式でそのような値を記憶するためにプログラミング言語における利用可能なデータ構造機構を利用し得る。Ｐｙｔｈｏｎ  ｖ３．６では、鍵テンプレートのための可能な構造が辞書のアレイによって表され得、ここで、アレイ中の各辞書エントリが、辞書鍵に対応する各属性、および辞書中のその鍵に関連する値に対応する属性値とともに、単一の鍵テンプレートを記憶する。ＳＤＦＴ内では、すべての鍵テンプレートは一時的構造であり得、ｋｅｙ  ｃｈｅｃｋ変成を介した繰返し再発生を受け得、そのような鍵テンプレートを永続的に記憶することは、必要でないことがある。このようにして、ＳＤＦＴは、鍵タイプ／構造非互換性により、暗号変成をあからさまに失敗させてしまうより前に、処理のために、鍵スタックに挿入された鍵を適切に分析し得る。ＴＯＰおよびＳＤＦＴにおける主要なテーマは、データ操作シーケンスの不明瞭化が、機密のペイロードをセキュアにする際の信頼できる構成要素でないことがあり、むしろ、選定されたサイファおよびそれの演算属性および／または特性の強度を求められ得るという見方であり得る。
【００７０】
[0068]図４４は、ＴＡＲ例と、各々から発生された鍵テンプレートとを示す。表４４０２における左列は、ＴＡＲ例「Ａ」をリストする。右列は、属性入力として暗号鍵を要求し得る各変成コマンドについて発生された鍵タイプテンプレートを示す。この例では、ＴＡＲ「Ａ」は、示されたシーケンスにおいて２つの暗号鍵を要求し得る。表４４０４における左列は、ＴＡＲ例「Ｂ」をリストする。右列は、入力として暗号鍵を要求する各変成コマンドについて発生された鍵タイプテンプレートを示す。この例では、ＴＡＲ「Ｂ」は、示されたシーケンスにおいて４つの暗号鍵を要求し得る。このプロセスは、ＴＡＲからの鍵テンプレート発生として知られ得る。
【００７１】
[0069]図４５は、ＴＡＲ例と、各々から発生された鍵テンプレートと、入力（ｐｕｔ）または発生（ｇｅｎ）されることになるＫＩＳＳ構造の予想されるリストとを示す。ＫＩＳＳのリストは鍵スタックとも呼ばれる。図４４から２つの例をとり、ラヴェル／アンラヴェルコールの鍵管理態様における次のステップを示すことができる。鍵スタックは、４５１０によって示されているように各鍵タイプテンプレートに対応するＫＩＳＳ構造のリストの形式で予想または発生され得る。ＴＡＲ「Ａ」処理が「ｓｃｉｐｈｅｒ  ｓａｌｓａ２０  ２５６」変成コマンドに到達するとき、プロセスは、ＫＩＳＳ  Ａ１によって示されるように鍵スタック中で入力２５６ビット長対称鍵を見つけることを予想し得る。ＴＡＲ「Ａ」処理が「ｄｉｇｎ  ｄｓｓ  １０２４  ｄｉｇｅｓｔｌｅｎ＝５１２」変成コマンドに到達するとき、プロセスは、ＫＩＳＳ  Ａ２によって示されるように鍵スタック中で入力１０２４ビットｄｓａ鍵を見つけることを予想し得る。ＴＡＲ「Ｂ」のためのＫＩＳＳリストは、同様に行われることが読み取られ、理解され得る。そのような予想される鍵が鍵スタック中で見つけられないことがある場合、ＴＡＲ処理は、代わりに、発生された鍵が見つけられることを予想し得る。この暗黙的鍵発生は、所与の鍵付き変成のために任意のタイプの受付け可能な鍵を発生するための唯一の要件が、ＴＡＲ内でそれを宣言することが可能であることであるので、プログラマーにとって有益であり得る。特定の暗号関数のための特定の鍵を発生するために要求される追加のステップがないことがある。空の鍵スタックでラヴェルをコールすることにより、出力ＮＳｓｔｒ構造が、ＴＡＲに一致し、内部のデータを折り畳むことが可能であるような、適宜に発生された鍵をもつ完全に準拠した鍵スタックを保持し得る。ＫＩＳＳ構造から構成されたこの鍵スタックが、次いで、折り畳まれたデータから離れてセキュアな様式で別々に記憶され得、および／または、それが、何らかのやり方でさらに修正され、再び折り畳まれ、暗号変成を用いたＴＡＲを使用してセキュアにされ、したがって、それをさらに暗号化し得ることが、強く推奨され、賢明である。鍵スタックの繰返し暗号化およびカプセル化は、管理し、セキュアにすべき多くの暗号鍵を扱うとき、有用であり得る。ＴＡＲ「Ｂ」は、４つのＫＩＳＳの鍵スタックを生成し得、それは、鍵リポジトリに鍵スタック全体をセキュアに記憶するために好都合であり得るが、プログラマーは、利便性のために単一の鍵を使用して４つの鍵の鍵スタックを暗号化することを希望し得る。これは、新しいＮＳｓｔｒを作成し、４つの鍵の鍵スタックをデータｏｂｊフィールドに挿入し、適切な暗号ＴＡＲを選び、ＮＳｓｔｒ構造に対してラヴェルコールを実施することによって、達成され得る。この一連のステップは、４つの鍵の鍵スタックを保持する折り畳まれたＮＳｓｔｒ構造に対するロッキング鍵を含んでいる単一のＫＩＳＳ構造をもつ鍵スタックを生成し得る。
【００７２】
[0070]図４６は、ＳＤＦＴ  ＴＡＲ処理内の鍵スタック演算の３つのモード、すなわち、発生（ｇｅｎ）、入力（ｐｕｔ）および注入（ｍｉｘｅｄ）を示す。セクション４６００は、鍵スタック４６０２がＴＡＲ例「Ｂ」の処理において空であるときに何が行われ得るかを示す。ラヴェルプロセスは、ＴＡＲ「Ｂ」のための鍵タイプテンプレート４５０８をとり、４６０４に示されている鍵タイプテンプレート中で見つけられるものと同じタイプのおよび同じ順序での適切な数のランダムに発生された暗号鍵を発生する４６０６。セクション４６１０は、鍵スタック４６１２がＴＡＲ例「Ｂ」の処理に入力（ｐｕｔ）される４６１６ときに何が行われ得るかを示す。ラヴェルプロセスは、ＴＡＲ「Ｂ」のための鍵タイプテンプレート４５０８をとり得、鍵の数、タイプおよび順序付けを妥当性確認するために、それを、与えられた鍵スタック４６１２に対してチェックし得、次いで、それは、４６１４に示されているように、ＴＡＲ「Ｂ」の処理中のそれの使用を可能にし得る。セクション４６２０は、鍵スタック４６２２が、１つの鍵、すなわちＫＩＳＳ  Ｂ３のみが与えられてＴＡＲ例「Ｂ」の処理に提示されるか、あるいは、部分的に埋められた鍵スタックまたは「欠落した歯」シナリオとも呼ばれるとき、何が行われ得るかを示す。ラヴェルプロセスは、ＴＡＲ「Ｂ」のための鍵タイプテンプレート４５０８をとり得、鍵の数、タイプおよび順序付けを妥当性確認するために、それを、与えられた鍵スタック４６２２に対してチェックし得る。鍵スタックエントリに対する各鍵タイプテンプレートの反復的妥当性確認（validation）中に、空のＫＩＳＳ構造は、特殊なタイプの妥当性確認失敗であると見なされ得、さらに、その鍵タイプテンプレートのための暗黙的ｋｅｙ  ｇｅｎｅｒａｔｅ変成として解釈され得る。ラヴェルプロセスは、次いで、適切なタイプの新たに発生された鍵を鍵スタックの空の位置に注入し４６２６、鍵妥当性確認反復において続き得る。このステップを完了すると、（入力された鍵と発生された鍵との混合、欠落した歯シナリオ、または鍵注入と呼ばれることがある）混合された鍵スタックは、４６２４に示されているように、ＴＡＲ「Ｂ」の処理中に提示され、使用され得る。
【００７３】
[0071]図４７は、鍵スタックがデータおよびそれのＴＡＲのライフサイクルにおいてどのように発生および使用され得るかの図を示す。データに対するＳＤＦＴの使用４７００は、それが、特定のＴＡＲ４７０２によって定義された変成の可変セットに従って理路整然とした様式で反復的に変成されることを可能にし得る。ＴＡＲは、暗号鍵タイプ分析を可能にし、したがって、ＴＡＲによって要求される鍵の数およびタイプを詳述する鍵テンプレートを生成するようなやり方で構造化され得る。鍵テンプレートは、次いで、必要な鍵がすべて存在し得るのかいくつか存在し得るのかまったく存在しないことがあるのかにかかわらず、入力鍵スタックの構成４７０４において参照され得る。要求される暗号鍵が欠落していることがあるとき、構成プロセスは、使用のために新しい鍵を発生し得る。ＴＡＲ、データおよび鍵スタックは、次いで、ＴＡＲに従って構造化データの折り畳みを実施するためにラヴェルコール４７０６に受け渡され得る。折り畳まれたデータは、次いで、任意の手段によって記憶され得る４７０８。鍵スタック中の鍵は、別個のセキュアなロケーションに記憶され得る４７１０。折り畳まれたデータが参照される必要があるとき、アプリケーションは、それを、それのストレージ場所から取り出し４７１２、鍵または鍵スタックをそれのセキュアなストレージから取り出し４７１４、折り畳まれたデータおよび鍵スタックをアンラヴェルコール４７１６に受け渡し、アンラヴェル出力構造からのそれの元の形式のデータ４７０２にアクセスし得る。これは、変成を用いた構造化データ折り畳みの１つの完全なサイクルを示し得る。変成され、折り畳まれるべきデータ構造のための多くの他の経路があり得るが、本質的に、何らかの形式のこのサイクルが、ＳＤＦＴ内の元のデータを完全に取り出すために完全であるために必要であり得る。
【００７４】
[0072]鍵および／または鍵スタックの記憶４７１０は、それを、より少数の鍵、ただ１つの鍵および／または異なる鍵を用いて保護するために、暗号ＴＡＲを利用する鍵スタックの折り畳みを伴い得る。折り畳まれた鍵スタックデータは、それ自体で最終的に折り畳まれ得る別の構造の一部になり得る。データは、内部データ構造を築くためにカスケード様式で反復的に折り畳まれ得、ここで、正確で断片的な折り畳みが正確で断片的な暗号化につながり得る。正確な、編成されたおよび／または体系的なやり方で複雑な暗号データ変成をダイレクトするこのアビリティは、より洗練された変成方式を使用する機密データの保護のためのより良いおよび／またはより単純な設計につながり得る。ＴＡＲシンタックスの単純さおよび明快さは、他のものによってターゲットデータに対して行われている演算のより良い理解につながり得る。
【００７５】
[0073]ＳＤＦＴの重要な利益は、４７０４および４７１４の場合のように所与の１つのデータに対する様々な暗号演算を組み合わせることのコンテキスト内での鍵管理の系統的扱いであり得る。プログラマーは、各鍵を発生すること、ならびにそれの記憶および／または順番付けをそのようなプロセス中に手動で操作することの細かい点からやや解放され得る。暗号関数のアプリケーションでは、これらの細かい点が急速に合わさり、アプリケーション（したがってプログラマー）が追跡し、分析し、記憶し、および／または使用しなければならない大量の小さい詳細または属性になり得る。ＳＤＦＴ方法は、所与のアプリケーションが暗号関数のより少数の個々の属性を追跡し、分析し、記憶し、および／または使用することを可能にし得、これは、それにより、それらの属性が、それが動作し、出力として生成した、データおよび／または鍵スタックのコンテキスト内に埋め込まれることが可能になり得、それにより、それが、データを折り畳んでいることがある変成との折り畳まれたデータのペアワイズ結合を与え得るからである。データ操作命令をアプリケーションからデータに移植することは、より単純なアプリケーション、および／または、暗号関数のより洗練された使用をもつアプリケーションを可能にし得る。ＳＤＦＴは、ＮＵＴＳセクションにおいて説明されるように構造化暗号プログラミング（ＳＣＰ）方法を表すためのより良い代替を可能にし得る。
【００７６】
[0074]図４８は、ＮＳｓｔｒ構造に記憶されたデータに対して行われ得る演算の図を示す。ポインタによって参照され、および／または変数に記憶されたデータ４８０２が、インスタンス化方法を使用しておよび／または方法／関数コールを使用して４８０４、ＮＳｓｔｒ構造に直接カプセル化され得る４８１２。次いで、ＮＳｓｔｒ構造４８１０は、ＴＡＲ４８１４と、必要な場合それの関連する属性４８１６とをカプセル化し得る。属性は、鍵スタック、ダイジェスト、変成パラメータおよび／または一時的変数を備え得る。これは、与えられていることがある属性を使用して内部に含まれているデータに対してＴＡＲを実施するためにＳＤＦＴラヴェル／アンラヴェル演算を通してＮＳｓｔｒを処理するのに必要な情報の最小の完全セットを与え得る４８１０。ＴＯＰ用語では、これをデータの折り畳みと呼ぶことがある。ＳＤＦＴの出力は、同じＮＳｓｔｒ構造４８１０、またはＮＳｊｓｏｎなどのＮＳｘ構造として返され得る。この出力は、次いで、何らかの永続的なおよびアクセス可能なやり方で記憶され４８２０、プロセス間通信（ＩＰＣ）方法を使用して別のコンピューティングデバイスに送信され４８４０、および／または別の内部データ構造に記憶され得る４８３０。サイクルは、アプリケーションにおいて後の時点において、記憶されたデータ４８２０および４８３０について新たに始まり得る。送信されたデータ４８４０について、サイクルは、そのようなデータパケットの受信によって始動され得る４８００。
【００７７】
[0075]図４９は、データを反復的に折り畳むためのＳＤＦＴ使用法の流れ図を示す。一連の簡略図は、Ｎ回の連続データ折り畳みのためにＳＤＦＴラヴェルコールを使用する、データの系統的折り畳みを示す。少なくともデータ４９０２とＴＡＲ４９０４とを含んでいるＮＳｓｔｒ構造４９００は、出力データ４９０８を生成するためにラヴェル４９０６をコールすることによって折り畳まれ得、出力データ４９０８は、修正され、および／または、さらに、少なくともデータ４９２２とＴＡＲ４９２４とを含んでいるＮＳｓｔｒ構造４９２０にカプセル化され得、ＮＳｓｔｒ構造４９２０は、出力データ４９２８を生成するためにラヴェル４９２６をコールすることによって折り畳まれ得、出力データ４９２８は、修正され、および／または、さらに、少なくともデータ４９４２とＴＡＲ４９４４とを含んでいるＮＳｓｔｒ構造４９４０にカプセル化され得、ＮＳｓｔｒ構造４９４０は、出力データ４９４８を生成するためにラヴェル４９４６をコールすることによって折り畳まれ得、出力データ４９４８は、修正され、および／またはさらにカプセル化され得、．．．このプロセスは、必要に応じて反復され得る４９５０。この複雑な一連の構造化データ折り畳みでは、任意のステップにおける任意のＴＡＲが、何らかのテキストファイルまたはそれの等価物に記憶されたＴＡＲ命令を単に修正することによって、アプリケーションコードとは別々に修正され得ることに留意されたい。各ステップのための変成シーケンスおよび／またはパラメトリック分散の可能性をもつそのような反復的カプセル化の、ＳＤＦＴを用いない等価なプログラム的表現は、比較的長く、エラーを起こしやすく、および／または理解することが困難であり得る。
【００７８】
[0076]図５０は、データを反復的に展開するためのＳＤＦＴ使用法の流れ図を示す。一連の簡略図は、Ｎ回の連続データ展開のためにＳＤＦＴアンラヴェルコールを使用する、データの系統的展開を示す。それは、図４９のフローの完全な逆シーケンスであり、したがって、そのようなものとして理解され得る。図３９および図４０に前に示されたように、アンラヴェルコールは、ＴＡＲの準備とそれに供給されているデータの状態とを除いて、ラヴェルコールと同等であり得る。この複雑な一連の構造化データ展開では、展開を達成するために追加の逆方向ＴＡＲが必要でないことがあることに留意されたい。各折り畳まれたデータをアンラヴェルするのに必要なすべての必要なＴＡＲが、折り畳まれた構成体内に埋め込まれると見られ得る。ＮＳｔａｒ構造３１０６のより綿密な検査は、「ＴＡＲコマンドのリスト−拡大形式」として定義される「ｅｘｐｄ」フィールドを示す。これは、ＳＤＦＴにおける可逆性の重要な特徴であり得、ＴＡＲ準備ステップ３９１２および４０１２の出力は、ラベル参照および他の外部参照を欠いた演算可能な変成コマンドのフルセットを生成し得、変成されたデータがそれを受けさせられていることがある変成の完全な説明と考えられ得る。これは、折り畳まれたデータのためのＴＡＲセットの静的スナップショットと見なされ、それにより、外部ロケーションにおけるＴＡＲ定義のいかなる変更にもかかわらず、折り畳まれたデータに対して適切な展開が実施され得ることを保証し得る。それは、ＴＡＲ定義ファイルが多数のＴＡＲ定義とともに経時的に増大し得るが、（推奨される慣習でないことがある）そのような外部定義ファイルの変更にかかわらずそれの可逆性を保存するようなやり方で、演算ＴＡＲ定義の記憶がＳＤＦＴプロセスによってセーブされ得ることを暗示し得る。この設計は、記憶されたデータの時間互換性により良いやり方で対処するための系統的やり方を促進し得る。
【００７９】
[0077]図５１は、ＳＤＦＴ  ＡＰＩ／ライブラリおよびそれがアクセスを有し得る様々なタイプのＴＡＲ定義ファイルの図を示す。ＴＡＲ定義は、限定はしないが、テキストファイル、Ｎｕｔ、暗号化ファイル、データベース、サーバプロセス、および／または実行中のメモリ中など、多くの形式で存在し得る。ＴＡＲは、ラヴェルコールにおけるカスタマイズされたＴＡＲ定義としてプログラマーによって任意の時間に定義され得、したがって、一時的ＴＡＲであり得る。永続的に記憶され得るＴＡＲ定義について、図５１００は、これらの様々な形式を示し得るが、示されているこれらによって限定されないことがある。標準ＴＡＲ５１０２は、ＯＳ／言語ペアリングのためにＳＤＦＴライブラリインストールとともにパッケージとして与えられ得るＴＡＲ定義であり得る。隠れＴＡＲ５１０４は、アクセス制限された、および／または明示された許可によってアクセスされるロケーションにおいてのみ存在し得るカスタマイズされたＴＡＲ定義であり得るＴＡＲ定義であり得る。これらは、プライベートネットワークまたはカスタムアプリケーションインストール内のＴＡＲ定義の好ましい方法であり得る。隠れＴＡＲの使用は、ラヴェルの出力内でさえ隠されるように保たれ得、ＴＡＲの拡大形式が、そのような折り畳まれたデータ中にあると見られず、ただ、ＴＡＲラベルによるそれへの参照があることがある。隠れＴＡＲを用いて折り畳まれたデータは、必ずしも、それを展開するために要求される変成セットを含んでいるとは限らないので、隠れＴＡＲを維持する義務は、そのようなグループのアドミニストレータに属し得る。隠れＴＡＲは、プログラム内のデータ操作シーケンスを不明瞭にする等価な方法としてよく知られているように見え得る。ローカルユーザＴＡＲ５１０６は、ユーザのまたはプログラマーのアカウント特権の下でのみアクセスされ得るカスタマイズされたＴＡＲ定義であり得るＴＡＲ定義であり得る。これらは、プログラマーが後でＴＡＲ定義記憶形式のうちの１つへの永続的追加のために系統立てつつあることがある一時的または開発的ＴＡＲであり得る。リモートＴＡＲ５１０８は、リモートサーバまたはストレージサイトからの許可アクセスを用いてまたは用いずにアクセスされ得るＴＡＲ定義であり得る。そのようなトポロジーは、限られたローカルストレージによりまたは鍵ＴＡＲ定義を中央管理エリアに集中することのポリシーにより、必要であり得る。これはまた、標準ＴＡＲ定義が最新バージョンであり得るかどうかを見るために常にチェックする方法であり得る。保護されたＴＡＲ５１１０は、適切でアクセス可能な場所にあり得るが、認可されたアクセスのみのために暗号化され得る、ＴＡＲ定義であり得る。別個の認証および／または認可プロセスが、保護されたＴＡＲへのアクセスを獲得するために成功裡にトラバースされる必要があり得る。保護されたＴＡＲの別の形式が、Ｎｕｔコンテナへのアクセスを獲得するために適切な（１つまたは複数の）鍵を要求し得るＮｕｔコンテナ内に記憶され得る。埋め込まれ折り畳まれたＴＡＲ５１１２は、ラヴェルコールからの折り畳まれたデータとともに保存された拡大ＴＡＲ定義であり得る。
【００８０】
[0078]図５２は、手動データ折り畳みを実施するための例示的なＰｙｔｈｏｎスクリプトを示す。図５３は、ＰｙｔｈｏｎスクリプトにおけるＴＡＲ定義のＳＤＦＴ例およびそれの使用法を示す。図５２および図５３はともに、Ｐｙｔｈｏｎ  ｖ３．６を使用してより簡単なプログラム的手法とはＳＤＦＴがどのように異なるかの一例を示し得る。これらの例示的なＰｙｔｈｏｎスクリプトは、各方法論を使用する手元の各タスクのための基本コーリングシーケンスの大きい差を示し得る。サンプルデータセット５２１０で開始し得る。データに対して実施すべき演算は、行０２〜０６に示されているように平易な言語で表されたタスク５２２０において指定され得る。通常、これらは、読みやすさのためにコメント行としてプログラム自体に入力され得る。セクション５２５０は、タスクを実施するための実際のＰｙｔｈｏｎコードを示し、セクション５２６０は、元のデータ５２１０を復元するためのタスクの逆方向処理を示す。
【００８１】
[0079]ＳＤＦＴを使用して、データセット５３１０は５２１０と同じである。セクション５３２０は、「ｔｅｓｔ＿ａ７０」とラベリングされたＴＡＲ定義としてのタスク５２２０を表す。セクション５３５０は、データをラヴェルし、折り畳まれたデータをファイルに書き込む。セクション５３６０は、ファイルから、折り畳まれたデータを読み取り、それをアンラヴェルする。
【００８２】
[0080]図５２では１８行のＰｙｔｈｏｎコードがあり、図５３には８行のコードのみがある。データ変成のタイプおよび数の変更がセクション５２５０とセクション５２６０の両方に影響を及ぼし得ることは、明らかであり得る。図５２中の方法は、プログラマーが、各関数または方法のいくつかの変数、タスクのシーケンスおよび／または適切なコーリングを維持することを要求する。５２６０における逆方向プロセスは、プログラマーが、すべての演算が正しい逆順でコールされ、パラメータが各関数または方法コールのための正しいやり方で供給したことを確かめることを要求する。５２２０におけるタスクの変更が、セクション５２５０および５２６０のプログラミング変更を生じ得る。５２２０における追加のタスクが、セクション５２５０および５２６０への追加のプログラム行を生じ得る。より多くの一時的変数が、タスクへのこれらの追加またはタスクのこれらの変更のために、必要に応じて作成され、使用され得る。
【００８３】
[0081]図５３中のＳＤＦＴ方法では、タスクの変更が、ＴＡＲ５３２０において直接反映され得る。したがって、追加の変成修正は、このセクションの長さを変化させ得るにすぎない。ラヴェルコーリング行１０とアンラヴェルコーリング行１４とは、変更されないままである。ＴＡＲ５３２０の、５３６０における逆転プロセスは、５３２０における元のＴＡＲ定義を超えて指定される必要がない。事実上、セクション５３５０および５３６０は、ＴＡＲ定義ラベルがラヴェル方法コールにおいて指定される行１０を除いて選定されたＴＡＲ定義についてそのままであり得る。
【００８４】
[0082]実施されているタスクの読みやすさおよびわかりやすさに関して、リーダーは、セクション５２５０および５２６０における実際のプログラムコードよりＴＡＲ５３２０を選好し得る。５２２０において指定されたタスクは、コードではなく、通常、Ｐｙｔｈｏｎコード内のコメントとして表され得る。セクション５２５０および５２６０におけるプログラムコードの変更は、プログラマーによってコメントと手動で協調されなければならず、さもなければ、別のプログラマーが不正確なコメントを用いてコードを理解することを試みることになった場合、混乱が結果として起こり得、その逆も同様である。ＴＡＲ５３２０は、明瞭でコンパクトなやり方で自己記述的であると考えられ得る。
【００８５】
[0083]セクション５２５０における行１５〜１６によって記憶されたデータは、それがどのように変成されていることがあるかを記述する埋込みメタデータを有しない。変成方法は、実際のコードとしてセクション５２５０および５２６０においてハードワイヤードである。このようにして書き込まれたいかなるそのようなデータも、それの適切な取出しおよび復元のために、同じまたは同様のコードの存在に完全に依存し得る。これらのコードセクションまたはそれの等価物は、それが変成したデータが永久に復元可能であるように、永久に維持されなければならない。それは、隠れＴＡＲ方法の等価物であり得る。
【００８６】
[0084]セクション５３５０における行１１によって記憶されたデータは、折り畳まれたデータを変成していることがある、埋込み拡大ＴＡＲ定義を含んでいることがある。変成方法は、折り畳まれたデータとペアリングされ、それにより、それをトランスポート可能にし得る。折り畳まれたデータの復元可能性は、それを作成したコード５３５０および５３６０に依存しないと考えられ得る。折り畳まれたデータ中の埋込みＴＡＲ定義を適切に処理し得るコードが、元のデータを復元し得る。このタイプの機能は、より古い折り畳まれたデータが、それがどのように復元され得るかを自己記述し、したがって自己規定し得るように、経時的に変成シーケンスを変更するためのより良い時間互換性を可能にし得る。
【００８７】
[0085]図５４は、単一の通信セッション内の動的ＴＡＲ切替えのブロック図を示す。ＴＯＰ手法では、より高いレベルの通信プロトコルは、ある算出プロセスから別の算出プロセスへの変成されたデータの受け渡しと見なされ得る。変成は最も頻繁に使用される暗号関数の多くを可能にし得るので、それは、ＩＰＣのためのセキュアメッセージを作成するために使用され得る。理論的には、各メッセージは、異なるＴＡＲを使用して変成され、折り畳まれ得る。各異なるＴＡＲ定義は、プロトコル定義の現代の標準によって、それ自体のプロトコルと考えられ得る。ＳＤＦＴを使用して、ＴＡＲは、図５４に示されているように２つのアプリケーション間で折り畳まれたメッセージごとに動的に切り替えられ得る。図５１において示され、説明されたＴＡＲソースの混合物は、各アプリケーションがそれらのＴＡＲ定義ソースへのアクセスを有し得る限り、使用され得る。限定はしないが、埋込み暗号変成において要求される各鍵のための正確な鍵識別子を指定する鍵穴としてのＫＩＳＳ構造など、埋め込まれ、折り畳まれたメタデータのリッチなセットは、ＳＤＦＴベース通信プロトコルが、より洗練された潜在的によりセキュアなレベルでセキュリティを提供することを可能にし得る。
【００８８】
[0086]ＳＤＦＴと呼ばれるフレームワークを生じ得るＴＯＰ分析および方法は、記憶されたデータが、それを生成していることがあるそれ自体の可搬命令セットを含んでいることを可能にし得る。このフレームワークは、データ折り畳みを定義し得、記憶されたデータ内に編成された様式で埋め込まれ得る変成監査記録（ＴＡＲ）として表現可能な、概念的および論理的に無矛盾な可逆変成処理方法を使用してデータを折り畳むための方法論および／または実施形態を与え得る。得られた折り畳まれたデータは、次いで、何らかのやり方で修正され得、次いで、所望のアプリケーションまたはデータ形式結果を達成するために、必要に応じて繰り返し折り畳まれ得る。プログラミング言語としてＴＡＲを記述することを除いて、それは、変成シーケンスの無限変動ならびに／あるいは所与のＴＡＲおよび／または属性内の変成属性の無限変動を可能にし得る簡明な形式で、協働データ操作のセットを表す。ＳＤＦＴは、スコーピング概念および技法を使用してプログラミング言語が局所変数を隔離するやり方と同様の、データセットのための可変スコーピングを可能にし得る。ＴＯＰを通して、プロトコル分散は、より高い概念上の構成体において観察され得、これは、自己記述的であり得、場合によっては、多種多様なアプリケーションからアクセス可能および読取り可能であり得る、データにつながり得、多種多様なアプリケーションは、それの方法論に、それらのプログラミング環境に適応された利用可能なＳＤＦＴライブラリを介してアクセスし得る。さらに、折り畳まれたデータにもたらされ得るこれらの特性は、単一の通信セッションまたは単一の記憶されたデータオブジェクト内のプロトコルの動的切替えを可能にし得る。ＴＯＰ手法は、ＮＵＴＳエコシステムのための、およびＮｕｔの構成における基本的なビルディングブロックとして利用され得る。ＮＵＴＳは、ＳＤＦＴに依存しないで完全に実装され得るが、それは、賢明でないことがある。
【００８９】
Ｎｕｔ  ＩＤ
[0087]ＮＵＴＳ設計は、ロケーションにかかわらずデータの識別可能性を可能にし得る。これは、汎用一意ＩＤ（ＵＵＩＤ）を要求し得るが、それは、何らかの形式の集中化なしに、保証された様式で達成可能でないことがあり、したがって、ＩＤ衝突の低い確率を与えるのに十分な長さおよびエントロピープロパティをもつ事実上一意のＩＤの概念に落ち着き得る。図５５は、Ｎｕｔ  ＩＤを発生するためのプロセスの一例のフローチャート５５００を示す。ここで、ローカルデバイス５５０２は、限定はしないが、ユーザ属性５５０４、環境属性５５０６および／またはランダム属性５５０８など、データ片から事実上一意のＩＤを発生するための関数を呼び出し得るアプリケーションを実行中であることがある。ユーザ属性５５０４は、限定はしないが、ユーザログイン情報、グループＩＤ、会社ＩＤ、ユーザＩＤおよび／またはユーザパスワードハッシュなど、データ項目を含み得る。環境属性５５０６は、限定はしないが、ＭＡＣアドレス、ＩＰアドレス、デバイス情報、システム時間、ＯＳ情報、ディレクトリ経路および／またはファイル、原子クロック同期時間値、ＧＰＳ同期時間値、宣言された環境変数、スレッドＩＤ、ＣＰＵランタイム、ＩＭＥＩ番号、電話番号、アプリケーション名、ならびに／あるいはプロセスＩＤなど、データ項目を含み得る。ランダム属性５５０８は、限定はしないが、セッションカウンタ、ＵＵＩＤ、クロックサイクルカウント、ランダムに発生された数、マウス移動、キーボードアクティビティ、ファイルシステム状態、部分的なまたは完全なスクリーンエリアハッシュ、プロセスアップタイム、ＯＳアップタイム、および／あるいはセッション持続時間など、データ項目を含み得る。これらのデータ片は、集められ、ＩＤ構造５５１０に記憶され得、ＩＤ構造５５１０は、次いで、ＪＳＯＮまたは代替マーシャリング技法を使用してシリアル化され得る。次いで、得られたバイナリストリングは、（２００１年にＮＩＳＴによってＦＩＰＳ  ＰＵＢ１８０−２において公開されたハッシュアルゴリズムのＳＨＡ−２ファミリーからの）ＳＨＡ−５１２などのハッシングアルゴリズムを使用して、またはＩＤ衝突の確率を低下させるために５１２ビットの示唆された最小長をもつ事実上の一意性を生成し得る代替ハッシング方法を使用してハッシングされ得る５５２０。バイナリハッシュは、可搬性および読みやすさのために、ほぼ８６文字長のテキストストリングを生成し得るｂａｓｅ６４（または代替符号化方式）テキストストリングに符号化され得る５５１４。符号化方式は、印刷可能で人間に読取り可能な形式を生じ得、複数のプログラミング言語およびソフトウェアシステムによってテキストストリングとして受け付けられ得る、方法を備え得る。関数がコールされていることがあるモダリティに応じて、得られた符号化ハッシュストリングは、アクセス可能なＮｕｔ  ＩＤキャッシュに対して複写についてチェックされ得る５５１６。ＩＤ値の衝突があり得る場合、プロセスは、衝突しないＩＤが発生され得るまで新しいランダム属性５５０８で繰り返され得、衝突は、まれな出来事であることが予想され得る。この論理演算の出力ストリングは、Ｎｕｔ  ＩＤ５５１８と呼���れることがある。
【００９０】
[0088]このプロセスは、実行中のプログラム内でローカルにコールされ得るか、あるいは、新しいＮｕｔ  ＩＤについてのクライアントアプリケーション要求をサービスする、ローカルにまたはリモートで存在するサーバアプリケーション内で実装され得る。サーバモデル実装の考えられる利益は、それに対してチェックすべき既存のＮｕｔ  ＩＤのより大きいキャッシュにアクセスするそれのアビリティであり得、衝突の確率がより低いＮｕｔ  ＩＤを生成し得る。ＩＤ構造５５１０中のハッシュ長および適切に集められたデータ構成要素は十分なエントロピーを与え得るので、Ｎｕｔ  ＩＤ複写チェックは必須でない。ＩＰｖ４／ＩＰｖ６アドレス、ドメイン、ディレクトリハイアラーキおよびアクセス制御グループをもつインターネットなど、一部または全部のデジタルインフラストラクチャ全体にわたるコンパートメント化の一般的な概念があり得る。同様にして、Ｎｕｔ  ＩＤは、事実上一意であり得るが、それは、外部システムまたは関係によって構築されたコンパートメントのコンテキスト内で使用される可能性があり得、したがって、衝突の見込みは、Ｎｕｔ  ＩＤのビットの所与の長さにおいて、転置によって提供される数学的確率よりも、はるかに小さくなり得る。異なる長さが望まれ得る場合には、それは、当業者によってモジュラーパラメータ化様式でＳＨＡ−５１２ハッシュを代替ハッシュアルゴリズムと置換することによって達成され得る。
【００９１】
[0089]事実上一意のＩＤがＮｕｔ  ＩＤの形式で発生され得るプロセスを仮定すれば、Ｎｕｔ  ＩＤによって何が識別され得るのか？ＮＵＴＳ用語では、これは、Ｎｕｔ  ＩＤスタンピングとして知られ得る。Ｎｕｔ  ＩＤで矛盾なくスタンプされ得るＮＵＴＳ内の少なくとも２つの構造、すなわち、ロックノードおよびＮｕｔがあり得る。ロックノードに割り当てられたＮｕｔ  ＩＤは、ロックＩＤと呼ばれることがある。Ｎｕｔに割り当てられたＮｕｔ  ＩＤは、Ｎｕｔ  ＩＤと呼ばれることがある。ロックノードは、Ｎｕｔの内部ビルディングブロックであり得る。ロックノードは、バッグとして知られる、それのペイロードを保護し得る自蔵式のスタンドアロンロッキング機構であり得る。Ｎｕｔは、１つまたは複数のロックノードから構成されたデータ構造であり得る。したがって、Ｎｕｔは、データの１つまたは複数のパーセルを、全体的にまたはその一部を保持し得る。Ｎｕｔは、バイナリ形式で表される一部または全部の関連するソフトウェア、データおよび／またはハードウェアを事実上一意のやり方で識別するために、ＮＵＴＳ環境全体にわたって使用され得る。Ｎｕｔ  ＩＤスタンピングの帰結は、あらゆるＮｕｔが一意に識別され得、Ｎｕｔが物理的にどこに位置し得るかにかかわらず、Ｎｕｔ内に記憶されたあらゆるデータパーセルがそのＮｕｔ  ＩＤによって一意に識別され得ることを暗示する。
【００９２】
[0090]図５６は、Ｎｕｔデータ構造の簡略図を示す。この図は、Ｎｕｔデータ構造内のロックＩＤおよびＮｕｔ  ＩＤの使用法および相対配置を強調し得る。特定のロックＩＤ５６１４〜５６２２がこのＮｕｔにおいて割り当てられ得、それらは異なる値であり得る。ロックノード５６０４〜５６１２は、ロックＩＤ５６１４〜５６２２によってそれぞれ識別され得る。この例など、一般的なＮｕｔデータ構造形成では、Ｎｕｔ５６０２は、ロックグラフと呼ばれるデータ構造のようなグラフに編成されたロックノードのグループであり得る。特定のＮｕｔ５６０２は、ロックノード５６０６のバッグ５６２６に記憶され得るそれのＮｕｔ  ＩＤ５６３４によって識別され得、Ｎｕｔ  ＩＤは、他のロックノードバッグのうちの１つまたは複数に記憶され得るＮｕｔのペイロードとは異なり得るこのロックノードのペイロードと考えられ得る。あらゆるロックノード５６０４〜５６１２構造は、バッグ５６２４〜５６３２と呼ばれるペイロードエリアを含んでいることがある。これは、ＮｕｔとそれのＮｕｔ  ＩＤとの間の関係を示し、そこで、一般的なＮｕｔコンテナに記憶されたこれらの項目が見つけられ得る。
【００９３】
[0091]図５７は、Ｎｕｔ  ＩＤ、経路名および／またはペイロードデータの間の関係の例を示す。Ｎｕｔのメタデータ、Ｎｕｔペイロードに関するメタデータおよび／またはＮｕｔペイロードを記憶するために使用され得る、Ｎｕｔにおけるいくつかのロックノードがあり得る。メタデータ部分は、Ｎｕｔにおける様々なロックノードのバッグに記憶され得る。５７０２は、それぞれＮｕｔ  ＩＤ  Ａ３およびＮｕｔ  ＩＤ  Ｂ１によって識別される異なったＮｕｔに各々が記憶された２つの異なったＮｕｔペイロードＤ１およびＤ２があり得るシナリオを示す。説明の目的で２文字のＮｕｔ  ＩＤが使用されるが、Ｎｕｔ  ＩＤが、最高で８６文字長のテキストストリングを生成し得る５１２ビットハッシュのｂａｓｅ６４符号化であり得ることは、前に指定されていることがある。Ｎｕｔ  Ａ３とＮｕｔ  Ｂ１とはまた、ＮＴＦＳファイルシステムにおいて異なった経路名を有する。５７０４は、同じファイル名を有するが異なる経路名を有する２つの異なったＮｕｔを示す。５７０６は、異なるディレクトリ中の同じファイル名をもつ同じＮｕｔの２つのコピーを示す。５７０８は、同じディレクトリ中に位置する異なるファイル名をもつＮｕｔの２つのコピーを示す。これは、これらの属性の一部のまたは全部の転置の網羅的なリスティングでないことがあるが、それは、Ｎｕｔ  ＩＤなど、各ペイロードに関連するメタデータ項目を永続的に有することのフレキシビリティを示し得る。
【００９４】
[0092]関連するＮｕｔ  ＩＤによって識別され得るＮｕｔファイル内に埋め込まれたデータは、この方法論の新規の特徴、すなわち、メタデータにおけるパラメータ化ルールに基づいて動的ファイル名を自動的に作成するアビリティを生じ得る。ファイル名は、ファイルについての通常の識別ストリング、ならびに、限定はしないが、修正日付および時間および／またはその日についての書込みの数など、それの他の属性の系統立てられた概要を表し得る。これは、ディレクトリブラウジングアプリケーションにおいてファイルプロパティを見なければならないような、通常隠れた属性を調べる必要なしに、ファイルおよび時間的なそれの状態を識別する、より正確で好都合なやり方を与え得る。それはまた、ファイルシステムごとに変動し得るファイルシステムの属性キャプチャ能力に依拠するのではなく、ファイルおよびデータ属性の、ファイルを保持するコンテナへの埋込みを可能にし得る。一例：ユーザは、テキストドキュメントを記憶し得るＮｕｔ  ＩＤ＃２３４をもつＮｕｔを作成し得、テキストドキュメントは、Ｎｕｔ  ＩＤ＃２３４によって常に識別され得るが、ユーザは、「ｄｉａｒｙ＿２０１５１１１５＿１．ｔｘｔ」など、ベース名＋最後の修正の日付＋その日についての書込みのカウントを備える動的ファイル名をセットアップし得る。同じ日に、それを少し修正した後にディスクにセーブするとき、ファイル名は「ｄｉａｒｙ＿２０１５１１１５＿２．ｔｘｔ」を示し得、古いファイル名はディレクトリ中にもはや存在しないことがある。この方法論は、記憶されたデータの何らかの状態情報を示し得る新しいファイル名を自動的に作成し得る。事実上一意であり得、経路名＋ファイル名指定とは別個であり得るＮｕｔ  ＩＤのプロパティは、そのような特徴がいかなる外部参照もなしに実装されることを可能にし得る。そのような特徴の利益のうちの１つは、作業ドキュメントの前の状態をコピーし、日付スタンプを用いてアーカイブする、しばしば使用される方法であり得る。オーサーは、オーサーがオーサーのドキュメントに手を加えていることがある各日についてのファイルでいっぱいのディレクトリを見つけ得る。動的ファイル名方法を使用すると、オーサーは、オーサーがそれに書き込んだ最後の時の日付スタンプをもつ１つのＮｕｔファイルのみをオーサーのディレクトリ中に有し得る。手動方法の履歴（状態）セービング態様は、後のセクションにおいて提示されるＮｕｔ履歴特徴を使用してＮｕｔ自体内に保存され得る。Ｎｕｔ  ＩＤがコンテンツのメイン識別情報であるというこの概念は、分散したＮｕｔに対して複製および同期演算を実施するためにＮＵＴｓｅｒｖｅｒによって後で使用され得る。
【００９５】
ロックグラフおよびロックノード
[0093]ＮＵＴＳ技術は、構造化暗号プログラミング（ＳＣＰ）として定義され得る、レイヤ化、統合、モジュラーおよび／または反復的手法で、データの記憶、保護およびアクセス制御に対処し得る。Ｎｕｔの内部の全体的設計が説明され、定義され得、次いで、各定義された構造が、その後詳細に説明され得る。いくつかの特徴がレイヤ化様式で説明され得、次いで、統合の説明が、個々の特徴がどのように一緒に働き得るかを示すために与えられ得る。ＳＤＦＴは、複雑な暗号構造の編成と、各折り畳まれたデータ構造に関連する属性の系統的な埋込みとを改善するために、ＮＵＴＳ設計全体にわたって利用され得る。ＳＣＰ設計が等価な手動方法と比較して比較的容易に実装されることをＳＤＦＴがどのように可能にするかが、様々な実施形態において示され得る。
【００９６】
[0094]Ｎｕｔのアクセスを制御し得る４つの異なる方法論、すなわち、鍵穴、変数ロック、階層アクセス制御（ＳＡＣ）および／またはＮｕｔアクセス制御（ＮＡＣ）があり得る。これらの方法論の一部または全部は、部分的または全体的に、Ｎｕｔ内で新規のやり方で一緒にレイヤ化され、および／または統合され得、それは、内面化されたおよび／または依存しない様式で参照モニタリングシステムの完全な機能を与え得る。これらの４つのレイヤは、モジュラーであり、孤立しており、および／またはリンク可能であるように設計され得る、ロックノードと呼ばれる複雑なデータ構造において具現され得る。
【００９７】
[0095]鍵穴は、各々が関連する暗号化された鍵マップを有し得る任意の数のサイファ鍵を受け付け得るデータ構造であり得る。実施形態は、それが現在認識し、受け付け得るサイファ鍵タイプ、すなわち、パスフレーズ、対称鍵および非対称鍵のペアに限定されない。いかなる単純なまたは複雑な方法も、またはビットのシーケンスを秘密鍵として指定し得るいかなるプロセスも、鍵穴に統合され得る。暗号化された鍵マップは、１つのセットがＮｕｔ内のアクセス制御の各レイヤ、すなわち、変数ロック、ＳＡＣおよび／またはＮＡＣのためのものである、鍵のいくつかのセットを含んでいることがある。
【００９８】
[0096]変数ロックは、ロックノード中のデータを保護し得る正規化された構造において異なるタイプのロッキング機構を与え得る。これらの変数ロックは、ＯＲＬＯＣＫと、ＭＡＴＬＯＣＫと、ＳＳＬＯＣＫと、ＸＯＲＬＯＣＫと、ＨＡＳＨＬＯＣＫとを備え得る。本開示は、これらのあらかじめ定義されたロックタイプに限定されず、それの構造に正規化され得る適切なロッキング方式に適応するように拡大または縮小され得る。
【００９９】
[0097]階層アクセス制御は、ロックグラフ中の個々のロックノードへの進入アクセスを調節し得る。この特徴は、Ｎｕｔが、適切なアクセス属性が与えられれば様々なレベルのメタデータが閲覧されることを可能にするアビリティであり得る、勾配不透明度（Gradient Opacity）と呼ばれるＮｕｔにおけるプロパティを生じ得る。
【０１００】
[0098]ＮＵＴアクセス制御またはＮＡＣは、Ｎｕｔの内部の修正および認証を細かく制御するためにロールベース暗号アクセス制御（ＲＢＣＡＣ）技法を採用し得る。
【０１０１】
[0099]構造化暗号プログラミングは、様々なアクセスモデルを表すために異なる方法論間の容易でフレキシブルな対話を可能にし得るデータ構造の設計であり得る。セキュリティ機構は、サイファ化されたデータおよびそれらの関連するサイファにおいて完全に具現され得、したがって、参照モニタなど、Ｎｕｔのアクセス制御への外部アプリケーション依存がないことがある。いくつかの実施形態では、ロックノードは、ペイロードの任意の部分においてフィールドレベルデータを保護するために、個々に使用され得る。Ｎｕｔコンテナの内部は、特定のセキュリティモデルを具現するために、複数のサイファ鍵を潜在的に利用し得る。
【０１０２】
[0100]Ｎｕｔは、ロックノードと呼ばれるノードから構成された、ロックグラフと呼ばれる有向グラフデータ構造であり得る。各ロックノードは、Ｎｕｔ  ＩＤを発生するための同じ関数によって作成され得るロックＩＤによって識別され得、したがって、それらは両方とも同じ特性を有し得る。ロックノードは、それらのロックＩＤによって参照され得るハッシングされたアレイに記憶され得る。各ロックノードは、他のロックＩＤにリンクするポインタまたはヌルポインタを有し得る。よく確立されたプログラム的グラフ抽出およびトラバーサル技法を使用して、ロックノードのハッシングされたアレイからロックグラフが導出され得る。それを指す他のロックノードを有しないロックノードは、鍵穴ロックノード（エントリまたは外部ロックノード）であり得る。ヌルポインタを有し得るロックノードは、ロックグラフの末端ロックノードであり得、Ｎｕｔのペイロードまたはペイロードへの参照を記憶し得る。ロックノードは、それにリンクする複数のロックノードを有し得る。たいていの状況下で、ロックノードは、ロックグラフまたはそれ自体中の以前のロックノードにリンクしない。環状リンク参照は、異例であり得るが、そのような構造が保証される場合、カスタムＮｕｔのためのカスタマイズされたプログラミングを通して適応され得る。
【０１０３】
[0101]Ｎｕｔの機能をサポートするための本明細書で説明されるすべてのデータ構造ではないにしてもいくつかは、選定されたプログラミング言語内で複雑なデータ構造を使用して実装され得る。ＳＤＦＴ関数ライブラリが、選定されたプログラミング言語のために利用可能である場合、それは、データ操作コードを最小限に抑え、データ操作方法を明瞭にし、コーディングエラーの確率を低減し、あらゆる折り畳まれたデータ構造中に埋め込まれた暗示されたＳＤＦＴ特徴を利用するために、いずれかのおよびすべての適用可能な複雑なデータ構造またはそれのサブパートを折り畳み、カプセル化するために、容易に適用され得る。
【０１０４】
[0102]本開示のデータ中心性質により、たいていのフローチャートタイプ図が、データフロー図またはデータフローチャートと呼ばれることがある、データ構成要素と混合された旧来のフローチャート要素の混合であり得ることに留意されたい。また、ロックノード設計レイヤの交互絡合性質は、前方参照ステートメントを作ることなしに完全に線形的にそれの構成要素の論理演算を露出することを困難にし得、したがって、何らかの再読取りが、リーダーのパートで要求され得る。
【０１０５】
[0103]図５８は、モジュラーロックノードの複数の目的態様を採用する２つの論理セクション、すなわち、Ｎｕｔロック５８０２およびＮｕｔパート５８０４を備えるＮｕｔまたはロックグラフ５８００の実施形態である。ロックグラフのＮｕｔロック５８０２セクションは、暗号でリンクされた複雑なロックが１つまたは複数のロックノードを使用して所与のＮｕｔのために構築されることを可能にし得る。現在、述べられた５つのタイプの変数ロック、すなわち、ＯＲＬＯＣＫ、ＭＡＴＬＯＣＫ、ＳＳＬＯＣＫ、ＸＯＲＬＯＣＫおよびＨＡＳＨＬＯＣＫに対応する、本開示において定義されている５つのタイプのロックノードがある。各ロックノードタイプは、ストレージ領域ならびに他のロックノードメタデータおよびパラメータへの暗号化鍵（encryption key）を保護するために、特定のロックノードの中心において利用され得る変数ロック内部ロッキング機構のタイプを指していることがある。図３０に開示されているｌｏｃｋ変成は、変数ロックの一実施形態であり得、ロックノードを築く際に使用され得る。ロックグラフのＮｕｔロック５８０２部分を成功裡にロック解除し、トラバースすることは、ロックグラフ５８００のＮｕｔパート５８０４セクションにつながり得る。Ｎｕｔパート５８０４を備えるいくつかのロックノード、すなわち、ｈａｉｒ５８２０、ｔｉｃｋ５８２２、ｓｅａｌ５８２４、ｖｉｔａ５８２６、ｂａｌｅ５８２８、および／またはｔａｌｅ５８３０があり得る。Ｎｕｔパート５８０４は、Ｎｕｔペイロード５８３０および／またはメタデータ５８２０〜５８２８を含んでいることがある。ロックグラフのためのＮｕｔパートの数およびタイプは、Ｎｕｔが記憶しつつあることがあるデータのタイプ、ならびに／またはいくつかの所望の挙動および特性のためのＮｕｔの設計に応じて変動し得る。この例では、鍵穴ロックノード５８０６をロック解除すること（５８１６）は、リンクされた５８１８、ロックノード５８２０の１次鍵穴に挿入され得る適切なサイファ鍵を生じ得る。ロックノード５８２０をロック解除することは、リンクされたロックノード５８２２の１次鍵穴に挿入され得る適切なサイファ鍵を生じ得る。ロックノード５８２２をロック解除することは、リンクされたロックノード５８２４の１次鍵穴に挿入され得る適切なサイファ鍵を生じ得る。ロックノード５８２４をロック解除することは、リンクされたロックノード５８２６の１次鍵穴に挿入され得る適切なサイファ鍵を生じ得る。ロックノード５８２６をロック解除することは、リンクされたロックノード５８２８の１次鍵穴に挿入され得る適切なサイファ鍵を生じ得る。ロックノード５８２８をロック解除することは、リンクされたロックノード５８３０の１次鍵穴に挿入され得る適切なサイファ鍵を生じ得る。ロックノード５８３０はヌルポインタにリンクし得、したがって、それは、このロックグラフまたはＮｕｔの末端ロックノードまたは最内レイヤであり得る。ロックノードのロック解除は、ＳＤＦＴ方法を使用したロックノードを表す折り畳まれたデータ構造のアンラヴェル（展開）を備え得る。各ロックノードは複数の折り畳まれたデータ構造を含んでいることがあり、ここで、ロックノードをロック解���するアクションは、適用可能なデータ構造の展開と等価であり得る。
【０１０６】
[0104]図５９は、論理セクション、すなわち、Ｎｕｔロック５９０２およびＮｕｔパート５９０４を備えるロックグラフ実施形態の簡略化されたＮｕｔ概略図５９００を示す。この例は、４つのロックノード５９０８、５９１０、５９１２および５９１６を備えるＮｕｔロック５９０２を検討する。ロックノード５９０８〜５９１２は、それらの一部または全部が外向きノードであり得、１次鍵と呼ばれる外部サイファ鍵を受け付け得るので、このＮｕｔの鍵穴ロックノード５９０６であり得る。ユーザは、これらの鍵穴ロックノードのうちの１つまたは複数に関連する１次鍵を有し得る。１次鍵をそれのペイロードとして記憶するＮｕｔのＮｕｔ  ＩＤは、鍵穴ロックノード５９０６の中のそれが属する鍵穴をマークする識別子と自動的に一致され得る鍵ＩＤとして働き得る。パスフレーズ鍵は、鍵ＩＤ、または質問をそれの識別子として保持することも保持しないこともあるテキストストリングによって識別され得る。複雑なマルチレベルパスフレーズは、適切な鍵穴識別子と、適切な質問リストをもつクリアテキストＮｕｔメタデータ部分とを使用して構築され得る。５９１４および５９１８など、ロックノード間のリンケージは、成功裡にロック解除されたロックノードが、識別子をもつ（１つまたは複数の）出力鍵を生成し得る場合と同様にして開かれ得る。この特定の例では、鍵穴ロックノードのうちのいずれか１つをロック解除することは、リンクされた５９１４、ロックノード５９１６の鍵穴に挿入され得る適切なサイファ鍵を曝露し得る。この時点以後、Ｎｕｔパート５９０４を備えるノードのロック解除は、Ｎｕｔパート５８０４について説明されたプロセスと同様に進み得る。このＮｕｔロック５９０２構築は、Ｎｕｔ５９００のペイロードをロック解除するために３つの異なった経路が存在し得、各経路が、ロック解除プロセスを進めるために異なる条件が満たされることを要求することを示すことによって、ロックノードのビルディングブロック性質と、それの組合せのフレキシビリティとを伝達し得る。
【０１０７】
[0105]図６０では、ロックノード６０００は、以下のセクション、すなわち、パラメータ６００２、入力６００６、鍵マップ６００８、変数ロック６０１２、導出された鍵６０１６、鍵セット６０２０、バッグ６０２４および／または出力６０２６を備えるデータ構造であり得る。パラメータセクション６００２は、ロックノードのメタデータ、ロックＩＤ６０３０と、鍵マップ６０１０、導出された鍵６０１４、鍵セット６０１８、バッグ６０２２の暗号化されたストリングと、ロックノードのための適切なアクセスロール鍵（前方参照が図８３の要素８３３４についての説明において説明され得る）によって作成された、前記暗号化されたストリングのｄｉｇｎとを保持し得る。設計原理は、次のセクションを開くのを助け得る鍵につながり得る各セクションのロック解除を伴うロックグラフ中のフローと同様であり得るが、その場合、ロックノード内の各構成要素は特定の関数を与え得る。暗号化されたストリングに関するｄｉｇｎは、解読試みより前に特定のセクションを認証するためにリーダー（アクセスロール）によって使用され得る。ｄｉｇｎは、保存すべきいくつかの修正があり得るとき、または適切なライターのアクセス鍵の保持者がｄｉｇｎを発生したことを示すために、セクションの暗号化されたストリングを使用して特定のセクションのライター（アクセスロール）によって作成され得る。さらに、上述の暗号化されたストリングの各々は、暗号変成を含んでいるＴＡＲを使用してデータ構造を折り畳むためのＳＤＦＴ方法の使用によって具現され得る。このセクションにおいて説明されたいくつかのおよび様々な暗号化されたストリングが与えられれば、ＳＤＦＴ方法は、コーディングするとき、プログラマーによって関係する属性を暗号で管理することの負担を大幅に低減し得る。
【０１０８】
鍵穴
[0106]図６１では、ロックノードの入力セクション６００６は、２つの異なる鍵穴、すなわち、１次鍵穴６１０２およびアクセス鍵穴６１０４を与え得る。構造的に、１次鍵穴６１０２は、４つの異なる鍵タイプ、すなわち、対称、非対称公開、非対称非公開、およびパスフレーズを備える、任意の数の暗号鍵を受け付け得る。アクセス鍵穴６１０４は、対称鍵タイプおよび／またはパスフレーズ鍵タイプを受け付け得る。１次鍵穴とアクセス鍵穴とは、それが受け付け得る各一意の鍵のための鍵穴を表すために各々が鍵穴モード（ｉｍａ＝「鍵穴」）で動作する、図３４に示されている１つまたは複数のＫＩＳＳデータ構造を内部的に利用し得る。
【０１０９】
[0107]図６２は、関連する鍵ＩＤ、鍵タイプおよび鍵属性６２０６を有し得、１次鍵としても指定され得る、単一の暗号鍵６２０２を示す。鍵ＩＤは、任意の識別ストリングであり得る。１次鍵および本開示において述べられる他の鍵は、各々、鍵−＞値フィールドが鍵でポピュレートされ、他の一致する属性フィールドが必要に応じて埋められた、鍵モード（ｉｍａ＝「鍵」）で動作する、図３４に示されているＫＩＳＳデータ構造によって内部的に表され得る。１次鍵穴６２０４は、暗号化された鍵マップ６２０８を解読し得る１次鍵６２０２を受け付け得る。解読された鍵マップ６２４０は、３つのセクション、すなわち、メイン鍵６２１０、階層鍵６２１２およびアクセス鍵セット（ＡＫＳ）６２１４を備え得る、構造であり得る。メイン鍵構造６２１０は、メイン鍵と呼ばれることがある対称鍵またはｔｉｎｅ、１次鍵６２０２についての満了日／時間、１次鍵のためのカウントダウンタイマー、および／または１次鍵の満了時のアクション命令を含んでいることがある。対称鍵またはｔｉｎｅは、ロックノードの変数ロックによって使用され得る。鍵穴ロックノードでは、鍵マップ構造は、階層鍵６２１２および／またはＡＫＳ６２１４を追加として保持し得る。階層鍵６２１２は、ロックグラフの階層ロックノード（Strata Lock Node）、すなわち、それの階層指定によって識別され得るロックノードに挿入されるべき鍵のセットを保持し得る。ＡＫＳ６２１４は、鍵穴ロックノードのためのそれ自体のアクセス鍵穴６１０４に挿入されるべき鍵のセットを保持し得る。暗号化された鍵マップ６２０８は、メイン鍵６２１０、階層鍵６２１２およびアクセス鍵セット（ＡＫＳ）６２１４構造を含んでいることがある、ＳＤＦＴの折り畳まれたデータ構造であり得る。
【０１１０】
[0108]図６３は、任意のロックノードのためのおよび任意のサイファ鍵のための鍵挿入プロセスのフローチャートを示す。ステップ６３０４は、所与のサイファ鍵およびそれの関連する鍵ＩＤについて、Ｎｕｔにおける一部のまたは全部のリストされたロックノードにわたる探索であり得る。サイファ鍵が適切な鍵穴に挿入されると６３０４、ステップ６３０６は、その鍵についての暗号化された鍵マップを解読し、広げることを試み得る。暗号化された鍵マップを解読し、広げることは、そのような実施形態では、ＳＤＦＴの折り畳まれた暗号化された鍵マップのアンラヴェルと等価であり得る。
【０１１１】
[0109]鍵穴ロックノードについての暗号化された鍵マップ６２０８を成功裡にロック解除し、広げると、１）階層鍵は、各ロックノードのパラメータセクションにおいて見つけられる階層指定に一致する各ロックノードの１次鍵穴に挿入され得、２）アクセス鍵セット（ＡＫＳ）のアクセス属性鍵セットロック解除鍵（ＡＡＫＳＵＫ）は、ロックノードのアクセス鍵穴に挿入され得る。この１次鍵ロック解除（またはアンラヴェル）は、多くの１次鍵がロックノードに挿入されていることがあるのでのために行われ得、その後に、ロックノードの変数ロックによる考えられる使用のためのメイン鍵のセットをまとめて構成する解読された（または展開された）鍵マップのセットを有し得る。
【０１１２】
[0110]図６４は、３つの１次鍵６４０２〜６４０６が１次鍵穴６４００に挿入され得る一例を示す。各鍵（→）は、それの識別鍵ＩＤと一致され得、ハッシングされたアレイまたはＫＩＳＳ鍵穴構造中のスロットに挿入され得る。鍵タイプは、限定はしないが、対称、非対称公開、非対称非公開およびパスフレーズなど、鍵タイプを示し得る。Ｎｕｔのいくつかの実施形態では、ユーザは、ＮＵＴＳ統合のために適切にモジュール化された対応するサイファ方法論を有し得る任意のタイプの鍵を指定し得る。これらの鍵サイファ方法論は、指紋スキャン、虹彩スキャン、掌紋、声紋、筆跡パターン、顔認識、ＤＮＡ特性、物理鍵デバイス、ハードウェアでセキュアにされた鍵、ソフトウェア／ハードウェアベースゼロ知識プロトコル鍵、および／またはＮＦＣ鍵を含み得る。ＲＳＡ−２０４８において使用され得るような非対称非公開鍵が挿入された場合、それは、公開部分と非公開部分の両方を表し得、公開部分は、非公開部分から抽出され得、１次鍵の暗号化された鍵マップを暗号化するために使用され得、したがって、解読演算は、非公開非対称鍵が提示されることを要求し得る。１つの鍵穴６４０２に挿入される１つの鍵（→）について明らかに示されているように、それの暗号化された鍵マップ６４１２は、鍵６４３２、６４３４および６４３６の３つの異なったセットを含んでいることがある鍵マップ構造６４３０を曝露するために、鍵タイプサイファ方法論を使用して解読され得る。この解読ステップは、それぞれの対応する鍵マップセット６４４０および６４５０を生成するために、各鍵６４０４および６４０６について行われ得る。各解読ステップはまた、そのような実施形態では、ＳＤＦＴの折り畳まれた構造をアンラヴェルすることと等価であり得る。パスフレーズ鍵タイプでは、鍵はパスフレーズであり得、鍵属性は、使用すべきパスフレーズ導出関数と、暗号化された鍵マップを解読し得る対称鍵を生成するために実施すべき反復の数を備える、その関数のための適切なパラメータとを示し得る。ＳＤＦＴを利用する実施形態では、そのようなパスフレーズ属性はまた、一致する属性をもつ適切なｄｅｒｉｖｅ変成にアクセスするために、対応するＴＡＲと一致され得る。ロックノード図６０００とともにその例を大局的に見ると、入力セクション６００６は１次鍵穴６４００を含んでいることがあり、暗号化された鍵マップ６０１０は６４１０によって表され得、鍵マップ６００８セクションは６４２０によって表され得る。
【０１１３】
変数ロック
[0111]ロックノードの次のパートは、図６０の要素６０１２に示されているように、変数ロックであり得る。変数ロックは、バッグ６０２４に記憶されたロックノードのコンテンツを保護するのを助け得るロッキング機構であり得る。変数ロックは、ロックノードが、当業者によく知られているいくつかの異なるタイプの暗号ロッキング技法のうちのいずれか１つを利用することを可能にし得る。たとえば、これらの異なるロックタイプは、ＯＲＬＯＣＫ、ＭＡＴＬＯＣＫ、ＸＯＲＬＯＣＫ、ＨＡＳＨＬＯＣＫおよび／またはＳＳＬＯＣＫを備え得る。これは、共通データフローモデルに適合するように各ロッキング方法の入力および／または出力を正規化することによって達成され得、それにより、各ロッキング方法は、シームレスに互いと置き換えられ得る。同様に、１次鍵穴構造と鍵マップ構造とは、変数ロックに流れる鍵の数および鍵タイプのためのデータ正規化器として働き得る。ロックノードは、どんなタイプの変数ロックをそれが実装しつつあることがあるか６０３０を示すパラメータのセット６００２を転写され得る。この値が設定されると、ロックノードはこの設定をめったに変更しないが、ＲＡＴ（Ｎｕｔの所有者）によってロックノードを再キーイングし（rekey）、および／またはリセットすることが可能であり得る。ＳＤＦＴライブラリは、図３０にリストされている変数ロックの一実施形態と、利便性のためにこのセクションにおいて使用され得るそれの添付の仕様とを記述するが、ｌｏｃｋ変成の使用は、ロックノードのこの機能を満たすための必要な要件ではない。
【０１１４】
[0112]３つのメイン鍵６４３２、６４４２および６４５２で終わった図６４中のロックノードのトラバーサルを続けること。それの変数ロックが図６５中でどのように動作し得るかを検討し得る。変数ロック６５０２は、導出された鍵（ＤＫ）６５０６を、暗号化された導出された鍵（ｅＤＫ）６５０４として暗号化することによって、ＤＫ６５０６を保護し得る。一部または全部のメイン鍵６４３２、６４４２および６４５２は、対称鍵タイプまたはｔｉｎｅ鍵タイプであり得、変数ロック６５０２中に収まり得る。ロックノードパラメータセクション６００２および６０３０において指定され得る変数ロックタイプに応じて、適切な変数ロック関数は、ＤＫまたはｅＤＫに対してサイファ／非サイファ（decipher）演算を実施するためにコールされ得る。図６５は、メイン鍵６４３２、６４４２および６４５２を使用し得る、変数ロック６５０２による、ｅＤＫ６５０４の、ＤＫ６５０６への解読演算を示す。図６６は、メイン鍵６４３２、６４４２および６４５２を使用する、変数ロック６５０２による、ＤＫ６５０６の、ｅＤＫ６５０４への暗号化演算を示す。ＳＤＦＴを使用する一実施形態では、ＤＫは、データ折り畳みによるｌｏｃｋ変成を採用してＴＡＲによって保護されるデータであり得、したがって、そのような構造を展開することが、内部に含まれている導出された鍵を曝露する。
【０１１５】
[0113]図６７中の表は、変数ロックが述べた鍵特性のうちのいくつかを要約する。変数ロックという用語が暗示し得るように、このモデルに正規化され得る任意のロッキング技法が、追加の変数ロックタイプとして追加され得る。代替的に、任意のロッキング技法が除外され得る。図３０中の表は、図６７中の表に対応し得、ＳＤＦＴがそれのｌｏｃｋ変成においてどのように変数ロック設計を具現し得るかを示す。
【０１１６】
[0114]ロックノードのメタデータセクション６０３０は、一部または全部の変数ロックに関与し得る共通構成要素であり得る。６０４０〜６０４８（前方参照）など、適切なアクセスロール鍵（ＡＲＫ）によって作成されていることがある、ロックノードセクションの様々なｄｉｇｎ（デジタル署名）があり得る。これらのｄｉｇｎのすべてのうちのいくつかは、それのＡＫＳを通してルートアクセスティア（ＲＡＴ）アクセスロール鍵、特にＲＡＴ非公開鍵を保持する誰かであり得るＮｕｔ所有者によって作成され得る。有効な１次鍵をもつ誰もが、Ｎｕｔ構成要素が危殆化されていないことがあることを確かめるために、誰もがロックノード全体にわたって様々なＲＡＴ  ｄｉｇｎを認証することを可能にし得るＲＡＴ公開鍵を有し得る。図では、時々、ＲＡＴ公開鍵はＲＡＴリーダー鍵と呼ばれることがあり、非公開鍵はＲＡＴライター鍵と呼ばれることがある。本明細書において後で、Ｎｕｔアクセス制御レイヤに関するさらなる説明が、これらの特徴をより深く検討し、指定し、および／または明瞭にし得る。ＳＤＦＴおよびＴＡＲに関するセクションにおいて前に述べられたように、暗号化されたデータのｄｉｇｎは、保護されたデータ、それのｄｉｇｎ、およびそれを作成したＴＡＲを埋め込み得る、折り畳まれたデータ構造のＴＡＲ仕様の一部であり得る。それは、ロックノード内のＳＤＦＴの系統的な使用がプログラマーの作業量に有利であり得ることを、明らかに暗示する。
【０１１７】
[0115]ＯＲロックとしても知られる、図６８中のＯＲＬＯＣＫは、メイン鍵６８０８と呼ばれる任意の数の対称サイファ鍵を受け付け得、ＡＥＳ−２５６または代替サイファなど、対称暗号サイファを使用してｅＤＫ６８０６を解読すること６８１４を系統的に試み得る、変数ロックである。パラメータセクション６００２は、この論理演算のために使用すべきサイファ方法、またはＳＤＦＴ方法を使用するときの好ましいＴＡＲを示し得る。ｅＤＫの最初の成功した解読は、導出された鍵（ＤＫ）６８１６を生成し得、ＯＲＬＯＣＫの成功したロック解除を生じ得る。変数ロックにおける解読試みより前に、ｅＤＫのｄｉｇｎ６８０４は、ｅＤＫ６８０６とＲＡＴリーダー鍵６８０２とを使用して認証され得る。認証が成功した場合６８１０、解読プロセスは続き得、他の場合、エラー６８３０が引き起こされ得、試みは休止され得る。メイン鍵６８０８は、限定はしないが、対称２５６ビット鍵など、同等の鍵であり得る。この構成では、ＯＲロックのエッセンスは、それをモジュラーにするために、隔離され、鍵穴および変数ロック構造に正規化され得る。折り畳まれた構造では、認証ステップは、ＴＡＲの一部であり得、アンラヴェルの行為によって暗黙的に試みられ得る。
【０１１８】
[0116]図６９は、ＲＡＴライターまたはＮｕｔ所有者の視点からのＯＲＬＯＣＫの暗号化演算を示す。それは、メイン鍵６９０２をとり得、ｅＤＫ６９０８を生成するために適切なサイファを使用してＤＫ６９０６に対して暗号化演算６９２０を実施し得る。次いで、それのＲＡＴライター鍵６９０４と、ｅＤＫ６９０８と、適切なｄｉｇｎｉｎｇアルゴリズム６９２２とを使用して、それは、ロックノードパラメータセクション６０４４に記憶され得るｅＤＫのｄｉｇｎ６９１０を作成し得る。ＳＤＦＴ方法は、これらの属性の多くを、ｅＤＫとともにコンパクトなやり方で、パラメータセクションに記憶されるべき単一のデータオブジェクトに折り畳み得る。ロックノードの非ＲＡＴメンバーのための暗号化プロセスは単純であり得、すなわち、それらは、ロックノードのアプリケーションメモリコンテンツを、それらが何に関しても真正のｄｉｇｎを作成しないことがあり、これが、それらがそれのコンテンツを成功裡に変更し、それをｄｉｇｎしないことがあることを暗示するので、消去するか、または、それらは、すでに解読されたＤＫ６９０８を使用することがあり、それらは、ロックノードの関連するコンテンツを暗号化するが、ｅＤＫ  ｄｉｇｎに関連し得ることは何も変更されないことがあるのでｅＤＫ６９１０を触れられないままにするかのいずれかであり得る。これは、ＲＡＴライターのみが、ＤＫ６９０６の値を置き換えるかまたはそれを再キーイングすることが可能であり得ることを示し得る。ＳＤＦＴ方法を使用するとき、ロックノードの非ＲＡＴメンバーは、ｅＤＫを含んでいる元の折り畳まれたデータをパラメータセクションに残し、ＤＫを保持する展開された構造を消去することを選択し得る。
【０１１９】
[0117]ｍａｔｒｏｙｓｈｋａロック、カスケードロックまたはＡＮＤロックとしても知られる、図７０中のＭＡＴＬＯＣＫは、メイン鍵７００６と呼ばれる固定数の対称サイファ鍵を受け付け得、ＡＥＳ−２５６または代替サイファなど、適切な暗号サイファ７０１４を使用して、昇順の各メイン鍵７００８を使用してｅＤＫ７０２２を連続的に解読し得る、変数ロックである。パラメータセクションは、この論理演算のために使用すべき正確なサイファ、および要求され得るメイン鍵の数、またはＳＤＦＴ方法を使用するときの好ましいＴＡＲを示し得る。ｅＤＫ７０２２の成功した順序付き反復的解読は、ＤＫ７０２４を生成し得、ＭＡＴＬＯＣＫの成功したロック解除を生じ得る。変数ロックにおける解読試みより前に、ｅＤＫのｄｉｇｎ７００４は、ｅＤＫ７０２２とＲＡＴリーダー鍵７００２とを使用して認証され得る。認証が成功した場合７０１０、解読プロセスは続き得、他の場合、エラー７０３０が引き起こされ得、試みは休止され得る。この構成では、ｍａｔｒｏｙｓｈｋａロックのエッセンスは、それをモジュラーにするために、隔離され、鍵穴および変数ロック構造に正規化されていることがある。折り畳まれた構造では、認証ステップは、ＴＡＲの一部であり得、アンラヴェルの行為によって暗黙的に試みられ得る。
【０１２０】
[0118]図７１は、ＲＡＴライターまたはＮｕｔ所有者の視点からのＭＡＴＬＯＣＫの暗号化演算を示す。それは、提示されたメイン鍵７１０２の一部または全部をとり得、それらを降順でソートし得る７１１０。次いで、それは、ｅＤＫ７１２２を生成するために適切なサイファを使用してＤＫ７１２０に対して暗号化演算７１１２を反復的に実施し得る。次いで、それのＲＡＴライター鍵７１２４と、ｅＤＫ７１２２と、適切なｄｉｇｎｉｎｇアルゴリズム７１１８とを使用して、それは、ロックノードパラメータセクション６０４４に記憶され得るｅＤＫのｄｉｇｎ７１２６を作成し得る。ＳＤＦＴ方法は、これらの属性の多くを、ｅＤＫとともにコンパクトなやり方で、パラメータセクションに記憶されるべき単一のデータオブジェクトに折り畳み得る。ロックノードの非ＲＡＴメンバーのための暗号化プロセスは単純であり得、すなわち、それらは、ロックノードのアプリケーションメモリコンテンツを、それらが何に関しても真正のｄｉｇｎを作成しないことがあり、これが、それらがそれのコンテンツを成功裡に変更し、それをｄｉｇｎしないことがあることを暗示するので、消去するか、または、それらは、すでに解読されたＤＫ７１２０を使用することがあり、それらは、ロックノードの関連するコンテンツを暗号化するが、ｅＤＫ  ｄｉｇｎに関連し得ることは何も変更されないことがあるのでｅＤＫ７１２６を触れられないままにするかのいずれかであり得る。これは、ＲＡＴライターのみが、ＤＫ７１２０の値を置き換えるかまたはそれを再キーイングすることが可能であり得ることを示し得る。ＳＤＦＴ方法を使用するとき、ロックノードの非ＲＡＴメンバーは、ｅＤＫを含んでいる元の折り畳まれたデータをパラメータセクションに残し、ＤＫを保持する展開された構造を消去することを選択し得る。
【０１２１】
[0119]ＸＯＲロックとしても知られる、図７２中のＸＯＲＬＯＣＫは、メイン鍵７２０６と呼ばれる固定数（＞１）の対称サイファ鍵を受け付け得、昇順７２２２の各メイン鍵７２０８に対してＸＯＲ演算７２２４を連続的に適用することによって、計算された鍵を生成し得る、変数ロックである。次いで、それは、ＡＥＳ−２５６または代替サイファなど、適切なサイファを用いて、７２２４からの計算された鍵を使用してｅＤＫ７２１０を解読すること７２２８を試み得る。パラメータセクション６０３０は、この論理演算のために使用すべき正確なサイファ、および２つ以上の鍵であり得る要求され得るメイン鍵の数、またはＳＤＦＴ方法を使用するときの好ましいＴＡＲを示し得る。ｅＤＫ７２１０の成功した解読は、ＤＫ７２１２を生成し得、ＸＯＲＬＯＣＫの成功したロック解除を生じ得る。変数ロックにおける解読試みより前に、ｅＤＫのｄｉｇｎ７２０４は、ｅＤＫ７２１０とＲＡＴリーダー鍵７２０２とを使用して認証され得る。認証が成功した場合７２２０、解読プロセスは続き得、他の場合、エラー７２３０が引き起こされ得、試みは休止され得る。この構成では、ＸＯＲロックのエッセンスは、それをモジュラーにするために、隔離され、鍵穴および変数ロック構造に正規化されていることがある。折り畳まれた構造では、認証ステップは、ＴＡＲの一部であり得、アンラヴェルの行為によって暗黙的に試みられ得る。
【０１２２】
[0120]図７３は、ＲＡＴライターまたはＮｕｔ所有者の視点からのＸＯＲＬＯＣＫの暗号化演算を示す。それは、提示された一部または全部のメイン鍵７３０２をとり得、それらを昇順でソートし得る７３２０。次いで、それは、計算された鍵を生成するためにメイン鍵７３０４に対してＸＯＲ演算７３２２を反復的に実施し得、計算された鍵は、ｅＤＫ７３０８を生成するためにＤＫ７３０６を暗号化する７３２６ために使用され得る。ＲＡＴライター鍵７３１０と、ｅＤＫ７３０８と、適切なｄｉｇｎアルゴリズム７３２８とは、ロックノードパラメータセクション６０４４に記憶され得るｅＤＫのｄｉｇｎ７３１２を作成するために使用され得る。ＳＤＦＴ方法は、これらの属性の多くを、ｅＤＫとともにコンパクトなやり方で、パラメータセクションに記憶されるべき単一のデータオブジェクトに折り畳み得る。ロックノードの非ＲＡＴメンバーのための暗号化プロセスは単純であり得、すなわち、それらは、ロックノードのアプリケーションメモリコンテンツを、それらが何に関しても真正のｄｉｇｎを作成しないことがあり、これが、それらがそれのコンテンツを成功裡に変更しないことがあることを暗示するので、消去するか、または、それらは、すでに解読されたＤＫ７３０６を使用することがあり、それらは、ロックノードの関連するコンテンツを暗号化するが、ｅＤＫ  ｄｉｇｎに関連し得ることは何も変更されないことがあるのでｅＤＫ７３１２が触れられないままにするかのいずれかであり得る。これは、ＲＡＴライターのみが、ＤＫ７３０６を再キーイングすることが可能であり得ることを示し得る。ＳＤＦＴ方法を使用するとき、ロックノードの非ＲＡＴメンバーは、ｅＤＫを含んでいる元の折り畳まれたデータをパラメータセクションに残し、ＤＫを保持する展開された構造を消去することを選択し得る。
【０１２３】
[0121]ハッシュロックとしても知られる、図７４中のＨＡＳＨＬＯＣＫは、メイン鍵７４０６と呼ばれる固定数の対称サイファ鍵を受け付け得、特定の順序７４２２で提示された一部または全部のメイン鍵を連結すること７４２４によって、計算された鍵を作成し得る、変数ロックであり、次いで、それは、ストリングに対してハッシングアルゴリズム７４２６を適用し得る。次いで、それは、ＡＥＳ−２５６または代替サイファなど、適切な暗号サイファを用いて、計算された鍵を使用してｅＤＫ７４１０を解読すること７４２８を試み得る。パラメータセクション６０３０は、これらの論理演算のために使用すべき正確なサイファおよびハッシュ、要求されるメイン鍵の数、および／またはメイン鍵のソート順序、あるいはＳＤＦＴ方法を使用するときの好ましいＴＡＲを示し得る。ｅＤＫ７４１０の成功した解読は、ＤＫ７４１２を生成し得、ＨＡＳＨＬＯＣＫの成功したロック解除を生じ得る。変数ロックにおける解読試みより前に、ｅＤＫのｄｉｇｎ７４０４は、ｅＤＫ７４１０とＲＡＴリーダー鍵７４０２とを使用して認証され得る。認証が成功した場合７４２０、解読プロセスは続き得、他の場合、エラー７４３０が引き起こされ得、試みは休止され得る。この構成では、ハッシングロックのエッセンスは、それをモジュラーにするために、隔離され、鍵穴および変数ロック構造に正規化されていることがある。折り畳まれた構造では、認証ステップは、ＴＡＲの一部であり得、アンラヴェルの行為によって暗黙的に試みられ得る。
【０１２４】
[0122]図７５は、ＲＡＴライターまたはＮｕｔ所有者の視点からのＨＡＳＨＬＯＣＫの暗号化演算を示す。それは、提示されたメイン鍵７５０２をとり得、それらを昇順でソートし得７５２０、次いで、それらを連結し得７５２２、次いで、それに対してハッシュ演算７５２４を実施することによって、計算された鍵を生成し得る。この計算された鍵は、ＤＫ７５０６を暗号化する７５２６ために使用され得、ｅＤＫ７５１０を生成し得る。ＲＡＴライター鍵７５０８と、ｅＤＫ７５１０と、適切なｄｉｇｎアルゴリズム７５２８とは、ロックノードパラメータセクション６０４４に記憶され得るｅＤＫのｄｉｇｎ７５１２を作成するために使用され得る。ＳＤＦＴ方法は、これらの属性の多くを、ｅＤＫとともにコンパクトなやり方で、パラメータセクションに記憶されるべき単一のデータオブジェクトに折り畳み得る。ロックノードの非ＲＡＴメンバーのための暗号化プロセスは単純であり得、すなわち、それらは、ロックノードのアプリケーションメモリコンテンツを、それらが何に関しても真正のｄｉｇｎを作成しないことがあり、これが、それらがそれのコンテンツを成功裡に変更しないことがあることを暗示するので、消去するか、または、それらは、すでに解読されたＤＫ７５０６を使用することがあり、それらは、ロックノードの関連するコンテンツを暗号化するが、ｅＤＫ  ｄｉｇｎに関連し得ることは何も変更されないことがあるのでｅＤＫ７５１２が触れられないままにするかのいずれかであり得る。これは、ＲＡＴライターのみが、ＤＫ７５０６を再キーイングすることが可能であり得ることを示し得る。ＳＤＦＴ方法を使用するとき、ロックノードの非ＲＡＴメンバーは、ｅＤＫを含んでいる元の折り畳まれたデータをパラメータセクションに残し、ＤＫを保持する展開された構造を消去することを選択し得る。
【０１２５】
[0123]秘密共有ロックまたはＳｈａｍｉｒの秘密共有方式としても知られる、図７６中のＳＳＬＯＣＫは、各々が異なったｔｉｎｅまたは秘密共有シェアであり得るｎ個のメイン鍵７６０６のうちのｋ個を受け付け得る変数ロックであり、ここで、１＞ｐ＋１≦ｋ≦ｎであり、ｐ＋１が、しきい値と呼ばれる要求される鍵の最小数であり得る。秘密鍵を復元するために、解読された鍵マップ７６０６からの一部または全部のｔｉｎｅは、Ｓｈａｍｉｒの秘密共有方式または代替サイファなど、適切な秘密共有サイファに与えられ得る７６２２。復元は、一部または全部のｔｉｎｅが有効であり得、十分な数のｔｉｎｅがあり得る場合、成功し得る。次いで、それは、ＡＥＳ−２５６または代替サイファなど、適切な暗号サイファを用いて、復元された秘密鍵を使用してｅＤＫ７６０８を解読すること７６２４を試み得る。パラメータセクション６０３０は、秘密共有およびサイファ化演算のために使用すべき正確なサイファ、ならびに、秘密共有サイファについてのシェアの数（ｎ）およびしきい値カウント（ｐ＋１）、および／またはＳＤＦＴ方法を使用するときの好ましいＴＡＲを示し得る。ｅＤＫ７６０８の成功した解読は、ＤＫ７６１０を生成し得、ＳＳＬＯＣＫの成功したロック解除を生じ得る。変数ロックにおける解読試みより前に、ｅＤＫのｄｉｇｎ７６０４は、ｅＤＫ７６０８とＲＡＴリーダー鍵７６０２とを使用して認証され得る。認証が成功した場合７６２０、解読プロセスは続き得、他の場合、エラー７６３０が引き起こされ得、試みは休止され得る。この構成では、秘密共有ロックのエッセンスは、それをモジュラーにするために、隔離され、鍵穴および変数ロック構造に正規化されていることがある。折り畳まれた構造では、認証ステップは、ＴＡＲの一部であり得、アンラヴェルの行為によって暗黙的に試みられ得る。
【０１２６】
[0124]図７７は、初めてロックノードを暗号化中であることがあるか、または変数ロックを再キーイングするプロセス中であり得るＲＡＴライターまたはＮｕｔ所有者の視点からのＳＳＬＯＣＫの暗号化演算を示す。新しい秘密サイファ鍵Ｋが発生され得７７２０、次いで、パラメータ６０３０において指定され得る適切な秘密共有方法論を使用してＫから所望の数のシェア（ｔｉｎｅ）が作成され得る。これらのｔｉｎｅは、次いで、メイン鍵７７０２として記憶され得る。ステップ７７２４において、鍵Ｋは、ＤＫ７７０４を暗号化し、ｅＤＫ７７０６を生成し得る。ＲＡＴライター鍵７７０８と、ｅＤＫ７７０６と、適切なｄｉｇｎアルゴリズム７７２６とは、ロックノードパラメータセクション６０４４に記憶され得るｅＤＫのｄｉｇｎ７７１０を作成するために使用され得る。ＳＤＦＴ方法は、これらの属性の多くを、ｅＤＫとともにコンパクトなやり方で、パラメータセクションに記憶されるべき単一のデータオブジェクトに折り畳み得る。ロックノードの非ＲＡＴメンバーのための暗号化プロセスは単純であり得、すなわち、それらは、ロックノードのアプリケーションメモリコンテンツを、それらが何に関しても真正のｄｉｇｎを作成しないことがあり、これが、それらがそれのコンテンツを成功裡に変更しないことがあることを暗示するので、消去するか、または、それらは、すでに解読されたＤＫ７７０４を使用することがあり、それらは、ロックノードの関連するコンテンツを暗号化するが、ｅＤＫ  ｄｉｇｎに関連し得ることは何も変更されないことがあるのでｅＤＫ７７０６が触れられないままにし得るかのいずれかであり得る。これは、ＲＡＴライターのみが、ＤＫ７７０４を再キーイングすることが可能であり得ることを示し得る。ＳＤＦＴ方法を使用するとき、ロックノードの非ＲＡＴメンバーは、ｅＤＫを含んでいる元の折り畳まれたデータをパラメータセクションに残し、ＤＫを保持する展開された構造を消去することを選択し得る。
【０１２７】
[0125]変数ロックの説明とそれらの様々な論理演算の例示とは、あるもので別のものを置換することが何らかのパラメータ６０３０の変更および／または再キーイングを要求し得るように、異なるロッキング技法が正規化され、モジュール化されることを可能にし得るロバストなデータ構造を作成するために、ロックノードが、入力セクション６００６中の１次鍵穴６１０２、暗号化された鍵マップ６０１０、鍵マップ６００８、変数ロック６０１２、暗号化された導出された鍵６０１４、および／または導出された鍵６０１６をどのように採用し得るかを示し得る。異なるロッキング方法の正規化は、Ｎｕｔのためのユーザ１次鍵が触れられないことがあることと、単一のユーザ１次鍵が、ユーザに気づかれずに異なるＮｕｔにおける多くの異なるロッキング技法において採用され得、そのロッキング技法が特定のＮｕｔペイロードの保護に適していると見なされ得ることとを保証し得る。ＳＤＦＴ方法がこれらの複雑なデータ構造のうちのいくつかの実施形態において有利であると判明し得るセクションが強調された。ここにいくつかの例がある。ＯＲＬＯＣＫは、複数のユーザがロックノードのバッグへのアクセスを獲得することを可能にし得、これはグループアクセスの形式であり得るか、または、鍵のうちの１つがマスタ鍵を表し得る。ＭＡＴＬＯＣＫ、ＸＯＲＬＯＣＫまたはＨＡＳＨＬＯＣＫは、それのバッグをアンラヴェルするために一定数の鍵が存在し得ることを保証し得、機密性が高い企業秘密は、それのコンテンツを閲覧するために、特定の２人の重役が、その２人の重役のそれぞれの秘密鍵を供給することを要求し得る。ＳＳＬＯＣＫは、それのバッグへのアクセスを獲得するために最小数の秘密鍵が存在し得ることを要求し得、企業支払システムは、最小数の認可された人員によってアクセスされ得るが、それは、単独で動作させられないことがある。
【０１２８】
[0126]各１次鍵穴をそれの対応する鍵マップを用いて区分することによって、鍵マップは、限定はしないが、満了日／時間、カウントダウンタイマー、および／または満了アクションなど、１次鍵についての属性を含んでいることがある。満了属性のうちのいずれかが作動させられた場合、対応する満了アクションが、１次鍵満了時に実施されるように設定され得る。たとえば、一般的な満了アクションは、１次鍵の鍵マップを削除することであり得る。鍵マップの削除は、それの区分された設計により、鍵穴ロックノードの他の登録された１次鍵に干渉しないことがある。満了した１次鍵を再挿入することは、それのための一致する鍵マップがないことがあるので、もはや有効な鍵として認識されないことがある。もちろん、そのような１次鍵削除は、採用されている変数ロックのタイプに関して慎重に行われるべきであり、削除はＯＲＬＯＣＫといくつかのＳＳＬＯＣＫとについては許容でき得るが、削除は、それがそのロックノードのためのロックアウト状況を作成し得るので、ＭＡＴＬＯＣＫ、ＸＯＲＬＯＣＫおよびＨＡＳＨＬＯＣＫにとっては逆効果であり得る。
【０１２９】
[0127]様々なやり方およびレイヤでそれのコンテンツを保護する目的で複数の暗号技法を利用し得る複雑なデータ構造の相互作用は、暗号演算ごとに要求されるおよび／または生成される並外れて多数の変数属性により、実装の詳細において大きな課題を提起し得る。それは、ＳＤＦＴの効用および精密さが際立ち、そのような実装の課題を克服するのを支援するために好都合な編成方法および構造を与え得るような状況にある。たとえば、データの単一の認証されたサイファ化は、以下の属性、すなわち、鍵タイプ、鍵長、サイファタイプ、サイファモード、初期化ベクトル、鍵ＩＤ、パディング、パディングタイプ、パディング長、ブロック長、デジタル署名または鍵付きＭＡＣストリング（ｄｉｇｅｓｔ）、ｄｉｇｅｓｔのための一致する鍵ＩＤ、ｄｉｇｅｓｔ長、ｄｉｇｅｓｔ鍵長、ｄｉｇｅｓｔ方法がどこかに記憶されることを要求し得る。ここまでに提示されたロックノード仕様において説明された各サイファ化演算をこれに乗算すれば（ロックノードは、後のセクションにおいて説明されることになるいくつかのより多くの構成要素を有する）、それは、追跡すべき膨大な数の属性になり得る。多くの事例では、アプリケーションプログラマーおよび設計者は、そのような苦境および課題に気づいていることがあり、少数のサイファ化方法と、関連する属性値とを選択し、それらを、グローバル様式でそれらの実装全体にわたって使用することによって、コーディングプロセスを簡略化することを選択し得る。そのような簡略化は、限定はしないが、より小さいセキュリティ、より小さいフレキシビリティ、より少ない特徴、より大きい非互換性、および維持または修正することがより難しいことがあるコンピュータコードなど、望ましくない帰結につながり得る。
【０１３０】
階層
[0128]図７８は、階層鍵使用法を強調するＮｕｔ（ロックグラフ）７８００のブロック図を示す。Ｎｕｔパート７８０４セクション中の各ロックノードは、階層ＩＤを割り当てられ得る。ロックノード７８２０〜７８２４は階層ＩＤ「Ａ」であり、ロックノード７８２６は階層ＩＤ「Ｂ」であり、ロックノード７８２８は階層ＩＤ「Ｃ」であり、ロックノード７８３０は階層ＩＤ「Ｄ」である。階層の指定は任意であり得るが、プライバシーの機密性の高さによって様々なＮｕｔパートを一緒にグループ化するパターンに従い得、階層が深いほど、ロックノード中に含まれているデータは、より機密性が高くなり得る。階層アクセス制御（ＳＡＣ）の正確な使用によって、Ｎｕｔの勾配不透明度を実装し得る。説明の目的で、図７８に示されている階層ＩＤは単純な文字であるが、実際には、限定はしないが、（図５５からの事実上一意のＩＤの場合のように）Ｎｕｔ  ＩＤなど、識別可能なストリングの任意のセットであり得る。
【０１３１】
[0129]Ｎｕｔロック７８０２を備える任意のロックノードが階層を割り当てられ得る。Ｎｕｔの鍵穴ロックノード７８０６が適切にロック解除またはアンラヴェルされると、それは、（図６２と同様に）最高３つの鍵セット７８４２を備え得る鍵マップ７８４０を曝露し得る。このセクションは、階層鍵７８５０（６２１２）と、それらがどのようにロックグラフ内で機能し得るかとに焦点を当て得る。この例では、それぞれ階層「Ａ、Ｂ、Ｃ、Ｄ」に対応し得る４つの階層鍵７８５２、７８５４、７８５６、７８５８があり得る。各階層鍵は、関連する階層ＩＤとともに階層鍵７８５０セクションに記憶され得る。各階層鍵がどのように使用され得るかを示す、図７９に提示されるフローチャートに従い得る。一部または全部の階層鍵が、それらの一致するロックノードの１次鍵穴に挿入されていることがあると、プロセスは終了され得、Ｎｕｔロックセクション７８０２を越えてロックグラフのトラバーサルが続くのを待ち得る。
【０１３２】
[0130]階層鍵は、Ｎｕｔパート７８０４セクション中の一部または全部のロックノードに示されているように、ＭＡＴＬＯＣＫ変数ロックとともに働き得る。ＳＤＦＴ方法を使用するとき、ＭＡＴＬＯＣＫは、関与するセクションの好ましいＴＡＲにおいて「ｌｏｃｋ  ｍａｔｌｏｃｋ」変成によって示され得る。各階層鍵は、当該のロックノードのためのＭＡＴＬＯＣＫにおける必須の鍵であり得る（図７９中の＊）。ロックノード出力リンク鍵または階層鍵のいずれかが欠落していることがある場合、特定のロックノードが、ＭＡＴＬＯＣＫの定義に従ってロック解除されないことがある。したがって、そのレベルを超えた一部または全部のより深い階層も開かれないことがある。どの階層鍵が１次鍵の鍵マップ７８４０に記憶され得るかを制御することによって、Ｎｕｔ所有者は、誰かが正確にどの程度までロックグラフに進入し得るかを明示的に制御し得る７８６０。階層アクセス制御レイヤは、Ｎｕｔアクセス制御レイヤから独立して働き得、それは、変数ロック方法とともに働き得る。
【０１３３】
[0131]ＳＡＣと鍵穴とが働き得る方法は、複数の鍵が７８０６などの鍵穴ロックノードに提示され得る場合、曝露されている複数の鍵マップ７８４０と、場合によっては、様々なロックノードに挿入され得る複数の階層鍵セット７８５０とがあり得ることを暗示し得る。単一の階層ＩＤの階層鍵は同等の鍵であり得、したがって、ＭＡＴＬＯＣＫを利用し得るロックノードに同じ鍵を挿入すると、そのＩＤの下で１つの鍵が挿入されることになり得、基本的に、同じ鍵は鍵穴中で数回上書きされ得る。これは、階層鍵の加法的アクセス属性プロパティであり得る。
【０１３４】
[0132]階層鍵と（次のセクションにおいて説明される）Ｎｕｔアクセス制御は両方とも、加法的アクセス属性プロパティまたは特性を呈し得る。異なるアクセスレベルの１次鍵の、ロックグラフの１次鍵穴への挿入は、すべての有効な挿入された１次鍵のアクセスレベルの組合せまたはユニオンを表し得る、ロックグラフのアクセスレベルを生じ得る。このプロパティの１つの強力な用途は、ロックグラフへのアクセスの極めて特定のレベルを獲得するために１次鍵の組合せが要求され得る、セグメント化された様式での所与のロックグラフのための鍵の分配においてのものであり得る。これは、１次鍵がその鍵保持者のための所与のアクセスの完全な像を提示し得る演算モードと対照をなし得る。
【０１３５】
Ｎｕｔアクセス制御
[0133]Ｎｕｔアクセス制御またはＮＡＣは、変数ロックおよび階層アクセス制御から独立して働き得る暗号データ構造を使用するアクセス制御方法である。ＮＡＣは、ロールベースアクセス制御（ＲＢＡＣ）と暗号アクセス制御（ＣＡＣ）との組合せを使用し得、それを、ロールベース暗号アクセス制御（ＲＢＣＡＣ）または鍵ベース許可（ＫＢＰ）と呼ぶことがある。ＮＡＣ属性鍵セットは単一のロックノードの内部に局所化され得るが、関連するロックノード全体にわたるアクセシビリティの無矛盾なレベルを鍵保持者に与え得る、ロックグラフの残部に沿ってＮＡＣ属性を伝搬するための機構がロックノード中にあり得る。これらのＮＡＣ属性は、外部ソースから挿入されていることがある１次鍵のためのロック解除またはアンラヴェルされた鍵穴ロックノード中で見つけられ得る。階層鍵と同様に、ＮＡＣ鍵は加法的アクセス属性プロパティを呈し得る。
【０１３６】
[0134]ＫＢＰは、デジタル署名（ｄｉｇｎ）を作成し、それらを、ＲＳＡＳＳＡ−ＰＳＳ（元はＢｅｌｌａｒｅおよびＲｏｇａｗａｙによって発明された確率的署名方式に基づく付属物をもつＲＳＡ確率的署名方式）または代替アルゴリズムなど、アルゴリズムを使用して、データのストリングに関して非対称的に認証することなど、公開鍵暗号のよく知られているプロパティを使用して配備され得る。ＫＢＰの基本前提は、非公開／公開鍵ペアが与えられれば、非公開鍵保持者（ライター）がライターの非公開鍵を使用してデータのパーセルに関するデジタル署名（ｄｉｇｎ）を作成し得、次いで、公開鍵保持者（リーダー）が、データのパーセルに関してｄｉｇｎがライターによって作成されたことを認証するために、リーダーによって所持されるライターの公開鍵を使用し得ることであり得る。認証が失敗した場合、公開鍵、データのパーセルまたはｄｉｇｎ、あるいはそれらの一部または全部など、何かが危殆化されていることがある。ライターは、ｄｉｇｎの毎回の修正時にターゲットデータパーセルに関する更新されたｄｉｇｎを作成することを担当し得、リーダーは、データパーセルを「読み取る」かまたは解読するより前にｄｉｇｎとターゲットデータパーセルとを認証することを担当し得る。このプロセスは、リーダーに、カウンターパート非公開鍵を有し得る誰か（ライター）によって作成または修正されていることがある何かをリーダーが読み取り中であることがあることを合理的に保証し得る。ロールベース暗号アクセス制御（ＲＢＣＡＣ）では、各定義されたアクセスロールのための非対称鍵ペアがあり得、ロールの「ライター」が鍵の非公開パートを得ることがあり、ロールの「リーダー」が鍵のそれぞれの公開パートを得ることがある。関数によってデータセットを分離し、異なる鍵ペアを使用して各関数データセットをｄｉｇｎすることによって、アクセスロールが正確に定義され得、適切な鍵パートを分配することによって様々な鍵保持者に割り当てられ得る。ＮＵＴＳのＲＢＣＡＣは、１つまたは複数の対称鍵の、定義されたロールの非対称鍵ペアとの結合が、ターゲットデータセットの制御の追加のレイヤを与えることを可能にし得る。結合された対称鍵の保持者は、そのロールのためのターゲットデータセットを解読し、読み取り得る。この結合された対称鍵は、変数ロックのロック解除によって曝露された対称鍵とｅＫＳ中の後続の鍵とによる暗号化に加えて、ターゲットデータセットを暗号化し得る。代替的に、結合された対称鍵の存在は、ｅＫＳからの曝露された暗号化鍵（encrypting key）の使用をオーバーライドし得、ターゲットデータセットを対称的にサイファ化するための唯一の鍵であり得る。この代替は、大きいターゲットデータセットについて、それが２回以上暗号化されないので、好ましいことがある。結合された対称鍵は、ターゲットデータセットへの読取りアクセスを制御するために使用され得る。
【０１３７】
[0135]ＮＡＣの一実施形態におけるＳＤＦＴの使用は、コーディングをはなはだ著しく簡略化し得る。暗号化とｄｉｇｎとは、実施されるべき関数に適した論理的にまとまりのあるＴＡＲに埋め込まれ得、ＳＤＦＴのアンラヴェルプロセスは、そのような演算の詳細な処理の大部分を自動化し得る。ＴＡＲに関連するいかなる局所化された属性も、それの保護および記憶を簡略化するために、ターゲットデータとともに折り畳まれるか、または別のＴＡＲを用いてさらに折り畳まれ得る。
【０１３８】
[0136]図８０中の表は、鍵ベース許可が、３つの定義されたロール、すなわち、リーダー、ライターおよびベリファイア（Verifier）、ならびに５つのロールプレイヤー、すなわち、Ａ、Ｂ、Ｖ、ＸおよびＹとともにどのように働き得るかの一例を示す。結合された対称鍵Ｓを所持するすべてのロールプレイヤーが、対称鍵Ｓを使用してデータを暗号化または解読するアビリティを有し得る。ライターのクラス（ＣＯＷ）、すなわち、ＸおよびＹは、非対称非公開鍵Ｒを使用して、暗号化されたデータに関するｄｉｇｎを作成するアビリティを有し得る。非対称公開鍵Ｕを使用して、リーダーのクラス（ＣＯＲ）、すなわち、ＡおよびＢは、対応するデジタル署名が、暗号化されたデータに関してライターのクラスからの誰かによって作成されたことを検証するアビリティを有し得、ＡおよびＢは、対称鍵Ｓを使用してデータを解読するアビリティを有し得る。したがって、有効なｄｉｇｎを作成するアビリティは、その人がデータを修正するアビリティを有し得、すべての他のリーダーが、有効なライターによってｄｉｇｎが作成されていることがあることを認証し得ることを暗示し得る。定義されるロールの数は、所有者によって望まれるアクセス制御グラニュラリティ（granularity）に依存するが、一部または全部の定義されたロールが、図８０について説明される方法論を利用し得る。非対称公開鍵Ｕを所持するにすぎないロールプレイヤーは、ベリファイアとして知られ得、ベリファイアは、Ｎｕｔ全体をトラバースする能力を有し得るが、ロールクラスに対応するターゲットデータを解読することができないことがある。たとえば、ＣＯＲベリファイアが、ｄｉｇｎに対してＣＯＷ公開鍵を使用することによって適切なＣＯＷロールプレイヤーによってＮｕｔのペイロードが適切に修正されていることがあることを認証するにすぎないことがあるが、ＣＯＲベリファイアは解読鍵Ｓのコピーを有しないので、ペイロードを解読することができない。
【０１３９】
[0137]ＮＡＣは、正確に、コンテンツの閲覧可能なおよび修正可能な態様に影響を及ぼし、それを制御し、それによりロックノードの態様に影響を及ぼし、それを制御し、それによりＮｕｔの態様に影響を及ぼし、それを制御し得る。図８１に示されている表は、Ｎｕｔのいくつかのパート、すなわち、ｈａｉｒ、ｔｉｃｋ、ｓｅａｌ、ｖｉｔａ、ｆａｃｅ、ｔａｌｅおよび／またはｂａｌｅをリストするが、必要に応じてより多いまたはより少ないパートを含んでいることがある。本明細書で後で詳細に説明され得るＮｕｔログおよびＮｕｔ履歴のいくつかの前方参照が表中にあり得る。各行はロックノードを表し得、Ｎｕｔパートを定義するデータは、そのロックノードのバッグ中に保持され得る。バッグ不透明度（Bag Opacity）と題する列は、ロックノードのメタデータによって制御され得る、ロックノードのバッグのサイファモードを示し得る。バッグは、メタデータ設定に基づいて暗号化されることも暗号化されない（クリア）こともあり、これは、バッグ不透明度と呼ばれることがある。図８１中の表におけるＮｕｔパートの一部または全部が所与のＮｕｔにおいて存在する場合、ロックノードによって表され得る各Ｎｕｔパートは、ロックノードリンクポインタとリンク鍵とを使用して、上から下へのシーケンスにおいてリンクされ得る。各Ｎｕｔパートのバッグ不透明度に関するこの表の列の下へのトラバーサルは、Ｎｕｔの勾配不透明度と呼ばれることがある。適切な外部１次鍵の保持者は、ロックノードの変数ロックを最終的にロック解除することによってＮｕｔへのアクセスを獲得し得る。１次鍵のＳＡＣ設定に応じて、鍵保持者は、それらがどの程度までＮｕｔにトラバースし得るかに制限され得る。ＮＡＣは、どの１次鍵が、結合された対称サイファ鍵の慎重な配置と、非対称鍵ペアの正確な使用と、デジタル署名方法を使用することとによって、各Ｎｕｔパートを読み取り、修正し、および／または認証するアビリティを可能にされ得るかに影響を及ぼし得る。
【０１４０】
[0138]図８２は、一般的なＮｕｔについて定義され、それのために利用可能であり得る鍵ベース許可アクセスロールをリストする表を示す。アクセスロールは、Ｎｕｔ所有者の必要に応じて定義された、より多いまたはより少ないアクセスロールがあり得るので、このリストによって限定されないことがある。表は、識別され得るＮｕｔの４つのセクション、すなわち、Ｂａｌｅ、Ｖｉｔａ、ＴａｌｅおよびＡｌｌをリストするが、それに限定されない。Ａｌｌセクションは、別のアクセスロールによって明示的にカバーされないものに言及し得る。これは、限定はしないが、別個のアクセスロールを表す鍵ペアによって指定されない鍵マップ、ｅＤＫおよび／または暗号化されたバッグに関するｄｉｇｎなど、ロックノードの一部または全部の内部作業を伴い得る。この説明のために、鍵ペアは、非対称鍵ペアと、結合された対称鍵とを備え得る。結合された対称鍵の存在は、アクセスクラスベリファイアロールの存在に依存し得る。Ａｌｌ非公開鍵の保持者は、ＲＡＴ（ルートアクセスティア）またはＮｕｔの所有者と呼ばれることがある。各１次鍵は、認証の目的でＲＡＴリーダー公開鍵のコピーを含んでいることがある鍵マップを有し得る。Ｂａｌｅは、ドキュメントなど、Ｎｕｔのペイロードを保持するロックノードのバッグ中に保持され得る。この鍵ペアは、それの頻繁な使用により、詳細にはライターのクラス（ＣＯＷ）およびリーダーのクラス（ＣＯＲ）と称され得る。この鍵ペアは、どの１次鍵がＮｕｔのペイロードを修正するアビリティを有し得るかを制御し得る。同様の様式で、Ｎｕｔログは、ＮｕｔのＶｉｔａパートのバッグ中に保持され得、ロガー／ログリーダー鍵ペアによって制御され得る。Ｎｕｔ履歴は、ＮｕｔのＴａｌｅパートのバッグ中に保持され得、ヒストリアン（Historian）／履歴リーダー鍵ペアによって制御され得る。各アクセスロールクラスのためのベリファイアロールは、それに関連するｄｉｇｎを認証するために、そのロールに関連する少なくとも１つの公開鍵へのアクセスを有し得る。ベリファイアロールは、それがアクセスを有しない、アクセスロールクラスに関連する結合された対称鍵があり得ることを暗示し得る。保守プロセスは、Ｎｕｔパートの妥当性、無矛盾性および／または真正性をチェックするために、Ｎｕｔ内の定義されたベリファイアロールの組合せへのアクセスを与えられるが、保護されたデータのコンテンツを読み取ることが可能でないことがある。鍵ペアリングは、これらのセットに限定されず、要件に基づいて拡大または縮小され得る。ロックノードのいかなる暗号化されたおよび／または暗号化されていないストリングも、それ自体の特定の鍵ペアによってそれに関して作成されたｄｉｇｎを有し得、ロックグラフ中のすべてのロックノードがこのレベルの特定性を採用し得、これは極端なレベルのアクセス制御グラニュラリティにつながり得るが、そのような極端なレベルのアクセス制御グラニュラリティは、そのようなＮｕｔに関するアクセス制御の有効性を弱め得る。
【０１４１】
[0139]ロックノードのパラメータセクションは、適用されるべきデジタル署名アルゴリズムと（ＲＳＡ−２０４８について最小２，０４８ビットにデフォルト設定される）非対称鍵の長さとを指定し得る。代替的に、ＳＤＦＴ使用法は、特定のＴＡＲがそのような選好を表すことを可能にし得、ＴＡＲラベルは、代わりにパラメータセクションに記憶され得る。Ｎｕｔのペイロードを保持中であることがあるロックノードの暗号化されたバッグは、ＲＡＴライター鍵を使用するＲＡＴライターによってデジタル署名されず、むしろ、ＲＡＴライターを含み得る、ＣＯＷアクセスを有する鍵保持者によってデジタル署名され得る。１次鍵保持者は、鍵穴ロックノードのそれらの鍵マップ中のそれらのアクセス鍵セットと、対応するアクセス属性伝搬鍵（ＡＡＰＫ）とを介したＲＡＴリーダー鍵へのアクセスを与えられ得、このＲＡＴリーダー鍵は、合法的な１次鍵保持者が、（ＲＡＴライター鍵へのアクセスを有し得る１次鍵保持者によって例示される）ＲＡＴ権限の管轄内にあり得るロックノード内のｄｉｇｎを認証することを可能にし得る。ＲＡＴ  ｄｉｇｎを認証することに失敗することは、対応するストリングまたは折り畳まれたデータが危殆化されていることがあること、またはＲＡＴリーダー鍵が無効であり得ること、または１次鍵がもはや有効でないことがあること、あるいは述べられた理由の一部または全部を暗示し得る。適用例は、この警告を示し得、Ｎｕｔの完全性が危殆化されていることがあり、さらなる解読試みが、成功する可能性が低いことがあるかまたは危殆化されたデータを示すことになり得るので、それ以上進まないことがある。
【０１４２】
[0140]図８３は、ＮｕｔがＮＡＣアクセス鍵のそれの初期セットをどのように達成するかを示す。鍵穴ロックノード８３００で開始すると、１次鍵８３０４が、１次鍵穴８３０６に挿入され得、暗号化された鍵マップを解読または展開し得、これは鍵マップ構造８３１０を曝露し得、対称であり得るアクセス属性鍵セットロック解除鍵（ＡＡＫＳＵＫ）８３１４から構成された鍵のセットを含んでいることがあるアクセス鍵セット（ＡＫＳ）８３１２があり得る。各個々のＡＡＫＳＵＫ対称鍵は、図８２中の表に示されているアクセスロールに対応し得る。ＡＫＳ中の各ＡＡＫＳＵＫは、次いで、初期１次鍵穴８３０６と同じロックノード８３００の同じ入力セクション８３０２におけるアクセス鍵穴８３２０に挿入され得、したがって、鍵マップ８３１０は、それ自体のアクセス鍵穴８３２０に収まり得る鍵のセットをＡＫＳ８３１２中に保持し得る。これは、鍵穴ロックノード（外向きロックノード）の特殊なプロパティであり得、たいていの場合、内部ロックノードに適用可能でないことがある。アクセス鍵穴８３２０において、各適切に挿入されたＡＡＫＳＵＫ８３１４が、アクセスロール説明８３３２、アクセスロール鍵（ＡＲＫ）８３３４および／またはアクセス属性伝搬鍵（ＡＡＰＫ）８３３６を備える、対応するアクセス属性鍵セット（ＡＡＫＳ）８３３０を曝露するために、解読または展開し得る。ＡＲＫ８３３４は、与えられているロールに対応する鍵ペアパート、すなわち、公開（リーダー）または非公開（ライター）を指定し得る。ＡＡＰＫ８３３６は、次のリンクされたロックノードのアクセス鍵穴へのＡＡＫＳＵＫとして働き得る対称鍵であり得る。ＡＡＫＳＵＫのセットは、１次鍵のＮＡＣアクセス属性と、究極的にはロックノードにおけるそれのアクセスとを定義し得るＡＡＫＳのセットを構成し得る。この図では、ＡＡＫＳ８３３０は、それがＲＡＴ非公開鍵とＣＯＷ鍵とを含んでいるので、Ｎｕｔ所有者のアクセス属性を指定し得る。ＡＡＫＳＵＫの加法的属性プロパティ（それにより、ＮＡＣの加法的属性プロパティ）がこの図に示され得、１次鍵穴８３０６に挿入され得る各１次鍵８３０４のためのＡＫＳ８３１２があり得、したがって、ＡＡＫＳＵＫ８３１４の、アクセス鍵穴８３２０へのあらゆる挿入が加法的であり得る。同等のＡＡＫＳＵＫは、ただ、アクセス鍵穴によって既存のものを上書きし得、これは、一部または全部の提示された１次鍵が処理されていることがあるとき、一意のＡＡＫＳのユニオンにつながり得る。これは、異なるアクセス属性の１次鍵が同時に挿入され得るとき、累積アクセス属性効果を生じ得る。
【０１４３】
[0141]図８４は、ロックグラフ中のロックノードの残部全体にわたってＮＡＣ属性を伝搬するためにＡＡＰＫがどのように使用され得るかを示す。鍵穴ロックノード８４００が適切にロック解除されていることがあり、一部または全部のＡＫＳ８４０２がアクセス鍵穴８４０４に挿入されていることがあり、これはＡＡＫＳ８４２０を生じ得る。次いで、アクセス属性伝搬鍵（ＡＡＰＫ）８４２４が、次のリンクされたロックノードのアクセス鍵穴８４３２に挿入され得る。これは、鍵穴ロックノードのアクセス鍵穴がポピュレートされていることがあるやり方と同様であり得るが、鍵は、それ自体の１次鍵穴において見られることも見られないこともある、ＡＫＳからではなくリンクされたロックノードから来ることに留意されたい。内部ロックノード８４３０の１次鍵穴（図示せず）は、ＲＡＴアクセスレベル鍵を除いて、それの鍵マップ中に空のＡＫＳを有し得る。この伝搬方法論に従うことによって、１次鍵のアクセス属性は、ロックグラフ中のあらゆる開いたロックノードにおいて存在し得る。ロックノードは、アクセスロールがＣＯＷなどと同じであり得るにもかかわらず、ＡＡＫＳの異なるセットをロックノード内でそれ自体の使用のために発生させることなど、一部または全部のまたはそれの内部制御機構を隔離し、局所化し得る。ＡＡＫＳＵＫおよびＡＡＰＫ対称鍵でさえ、それらが適切にマッピングされ得る限り、異なり得る。ロックノード全体のためにＡＡＫＳの完全セットをもつＲＡＴを割り当てることと、それがそれのロックグラフ全体にわたって適切に伝搬されることとは、明確に定義されたＮｕｔの前提であり得る。参照のために、ＲＡＴ公開鍵によって暗号化され得、ロックノードのパラメータセクションに記憶され得るＡＡＰＫおよびＡＲＫの完全セットがあり得、したがって、ＲＡＴのみが、それがロックノードを再キーイングする必要があり得るときにそれを曝露し得る。
【０１４４】
[0142]図８５は、外部ロックノード８５００から内部ロックノード８５３０への、ＡＡＰＫを使用したアクセス属性の伝搬を示す。図は、リンクされたノードの１次鍵穴８５５０およびアクセス鍵穴８５６０に収まるべき様々な鍵がどこから来得るかを示す。出力セクション８５１０は、リンクされたロックノード８５３０の１次鍵穴８５５０のためのリンク対称鍵８５１２を曝露し得る。ＡＡＰＫ８５２２は、リンクされたロックノード８５３０のアクセス鍵穴８５６０に挿入され得る８５２４。
【０１４５】
[0143]図８６は、鍵をアクセス鍵穴に挿入するためのフローチャートを示し、これは、前のセクションにおける例を使用して詳細にカバーされていることがある。
【０１４６】
[0144]図８７は、代替実施形態のための鍵ベース許可の表を示す。この表は、書込み非対称鍵ペア（ＵW、ＲW）と、インスタンスごとのデータサイファ化対称鍵Ｓnとをさらに定義することによって、図８０に提示された表を拡大し得る。図８０からの３つの鍵は、代替的に、Ｄｉｇｎ非対称鍵ペア（ＵD、ＲD）およびデフォルトデータサイファ化対称鍵Ｓ0として表され得る。追加の鍵は、ＡＲＫが、ロックノードのバッグに書き込み得るが、バッグの他のパートを読み取らないことがある、書込み専用（WriteOnly）アクセスロールを定義することを可能にし得る。書込み専用ロールは、鍵ＲD、ＵD、ＵWおよびＳnへのアクセスを有し得る。書込み専用ロールがメッセージＴnをロックノードのバッグにセーブすることを希望するとき、それは、Ｔnを暗号化し、暗号化されたメッセージＥnを生成するために、単一インスタンス対称暗号化鍵Ｓnを作成し得る。次いで、単一インスタンス対称暗号化鍵Ｓnは、暗号化された鍵Ｋnを生成するために、鍵ＵWを用いた非対称サイファを使用して暗号化され得る。次に、ＥnとＫnの両方がロックノードのバッグ内にセーブされ得る。書込み専用ロールはまた、ＲD鍵を使用してｄｉｇｎを作成し、それをセーブし得る。メッセージ認証は、代替または追加として、コンパクトさおよび編成の単純さのためにそのような情報を埋め込み、自動的に折り畳み得る、認証ＳＤＦＴ  ＴＡＲシーケンスの適切な適用によって実施され得る。そのようなＴＡＲシーケンスは、任意の鍵付きＭＡＣ変成を使用するメッセージ認証の代替方法を可能にし得る。書込み専用ロールプレイヤーが書込みを終え得、Ｓnのメモリ内インスタンスが破壊され得ると、ロールプレイヤーは、書込み専用ロールが非対称非公開鍵ＲWを所持しないことがあるので、メッセージＥnを解読するためのＳn鍵へのアクセスをもはや有しないことがある。リーダーロールおよびライターロールなど、非対称非公開鍵ＲWのコピーを所持し得るアクセスロールのみが、Ｓnを取得するために暗号化された鍵Ｋnを解読し得、それを、元のメッセージＴnを取得するために暗号化されたメッセージＥnに対して動作するためにＳnを使用し得る。認証方法論は、認証するプロセスを、多数の個々のメッセージを備えるペイロードに対してより効率的にするために、追加として、マークルツリーが働くやり方と同様のハッシュまたはｄｉｇｎチェイニングを含み得る。書込み専用ロールアクセスは、ローカルシステムによって動作しているロックノード上の前のメッセージの無認可のトランケーションまたは上書きを防がないことがあるが、ＮＵＴＳエコシステムは、様々な協働的やり方でそれのＮｕｔ履歴、複製および同期特徴を関わらせることによって、そのようなことの発生を防ぐかまたは強調するのを助け得る。これは、ＮｕｔＳｅｒｖｅｒおよびリビジョン制御モジュールに関するセクションにおいて後で説明される。
【０１４７】
[0145]図８７中の表によって提示される書込み専用およびベリファイアの限られたロール能力は、コンピュータシステムセキュリティ内の蔓延している「神の鍵（God Key）」の難問に関連する問題のうちのいくつかを緩和するのを助け得る。これは、よく知られているクラスの問題であり得、ここで、ある場合には、システムアドミニストレータが、手元の（１つまたは複数の）システムを保守し、アップグレードし、修復し、インストールし、および／またはトラブルシューティングするために、「神の鍵」、あるいはシステムまたはシステムのセットへのすべてのアクセス証明を与えられ得る。適切なセキュリティクリアランスチェックをもつ、比較的少数の極めて有能で経験を積んだシステムアドミニストレータにより、技術的アビリティを高いセキュリティクリアランスと自動的に相関させる傾向が当業界においてあり得る。このタイプの慣習は、信頼関係の動的性質に対処することができないことがあり、ここで、２つの当事者間の信頼レベルが、他方によって検出可能でないことがあるかまたは他方から意図的に隠され得る単方向様式で経時的に変化し得る。書込み専用アクセスロールとベリファイアアクセスロールとの慎重な使用によって、ペイロードは、移動しているかまたは静止しているデータについて常に、無認可のアクセスから保護され得る。これらの２つのアクセスロールの適用は、組織が、より適宜におよび独立して各態様を完全に管理するために、技術的アビリティとセキュリティクリアランスとの複合性質を切り離すことを可能にし得る。書込み専用ロールは、人およびプロセスが、扱いの証拠としてＮｕｔのログ構成要素を増やすことを可能にし得るが、人およびプロセスが、ペイロードを読み取るかまたはログを編集することを可能にしないことがある。追加として、書込み専用ロールは、両方のＤｉｇｎ鍵へのアクセスを有し得、認証ストリングを作成し、それらを検証し得る。ベリファイアロールは、人およびプロセスが、ペイロードへのいかなるアクセスをも可能にすることなしに内部無矛盾性および真正性についてＮｕｔをチェックすることを可能にし得る。ロックノードは、フィールド、記録、表および／またはデータベースのレベルにおけるアクセス制御のそのようなグラニュラリティを遂行するために、限定はしないが、ｎｏＳＱＬまたはＲＤＢＭＳなど、任意のデータベースシステム内で、系統的に修正され、適応され、挿入され得る。コンパクトさ、フレキシビリティ、特徴および／または独立性は、ロックノードが、コンピュータ化されたアプライアンス中に、アプライアンス自体への埋め込まれたアクセスゲートウェイとして存在することを可能にし得る。これは、Ｎｕｔｓのインターネットに関する後のセクションにおいてより詳細に説明され得る。
【０１４８】
[0146]ＮＡＣ特徴は、ターゲットペイロードに対してとられ得るアクションに関する転置の完全セットを包含し得る。許可されたアクションの単純な相互参照行列が、それのＮＡＣ実装とともに、以下のように示され得る。
【０１４９】
【表１】
2019537769.tif 000003
リーダーロールとライターロールとは、ロックノードのバッグ内に含まれているｄｉｇｎを検証または認証する暗黙的アビリティを有し得る。
【０１５０】
[0147]ロックノードの保護の３つの方法を要約すると、変数ロック、階層アクセス制御および／またはＮｕｔアクセス制御である。変数ロックは、主に、何らかのデータコンテンツを搬送するために使用され得るロックノードのバッグを保護し得る。階層アクセス制御は、ユーザがロックグラフ階層にどのくらい深く進入し得るかを定義し得る。Ｎｕｔアクセス制御は、Ｎｕｔのどのパートがユーザによって修正され、閲覧され、書き込まれ、デジタル署名され得るかを指定し得る。これらのレイヤの一部または全部は、ロックノードの鍵穴機構内の埋め込まれたまたは折り畳まれた鍵セットによって制御され得る。鍵穴機構は、多種多様なサイファ鍵が様々な関数のために挿入され、処理されることを可能にし得るフレキシブルな出入口であり得る。これらの構成要素の一部または全部は、保護されるべきコンテンツのために望まれ得るロッキング挙動を呈するようにＮｕｔごとにカスタマイズされ得、モジュール式に構築され得るアクセス制御のリッチなセットを提供するために、一緒におよび／または別々に働き得る。ロックノードのモジュラリティはまた、それの反復的でコンパクトなモジュラー設計のために、多くの複雑なロッキング構造を築くことの単純さを与え得る。Ｎｕｔを完全にロック解除し、利用するために多くの異なるアルゴリズムが使用され得るが、機構を始動するための情報は、Ｎｕｔのロックノード内に完全に記憶され得るサイファ化されたデータ部分によって表され得、したがって、それのアクセス制御機構は、可搬であり得、任意の外部参照モニタに依存しないでそれのペイロードとともに進み得る。これらの機構は、さらに、実装を簡略化し、内部コーディングおよび／またはデータ詳細の複雑さをより良く管理するのを助けるために、様々なＳＤＦＴ方法および構造によって具現され得る。
【０１５１】
[0148]Ｎｕｔのアクセス制御モデルは、必須のアクセス制御（集中型）、任意のアクセス制御（ユーザ中心）などの組合せであり得る。Ｎｕｔのアクセス制御モデルは、それが、それ自体内にそれのアクセス属性の一部または全部を記憶し得るやり方と、トランスポート可能性を容易にするために所有者がＮｕｔごとにアクセスレベルを直接設定し得る方法とにおいて、任意のアクセス制御モデルに似ていることがある。それはまた、一部または全部の必須のアクセス制御モデルに適応し得、それの鍵穴、変数ロックおよび他の機構によって与えられるそれのフレキシビリティにより、一部または全部のそのような環境に統合し得る。さらに、それは、限定はしないが、ＮＵＴＳにとって新規であり得る勾配不透明度、加法的アクセス属性および／またはモジュラーロックノードリンクなど、他の特性を呈し得る。
【０１５２】
ロックノードトラバーサル
[0149]次に、ロックノード全体をトラバースし、物が途中でどのように明らかにされ得るかを見得る。図８８は、ロックノード８８００内の解読データフローを示す簡略図を示す。図６２、図７８、図８３、図８４、図８５および図８８など、ロックノードロック解除プロセスの混交され統合された描写に関与する他の図の要素への参照が行われ得る。異なる要素番号によって番号付けされた同じロックノードセクションへの参照が行われ得るが、同じセクションの異なる図がドリルダウンタイプの手法で検査されることを表し得る。ロックノードロック解除プロセスにおいて要求され得る論理演算の順番付けは、効率および／または他の目的のためにさらに最適化され得る。ロックノードをロック解除し、それにより、最終的にロックグラフまたはＮｕｔをロック解除するプロセスは、限定はしないが、ロックノードへのアクセス特権および解読鍵を得るための１次鍵の使用、ロックノードの認証、ロックグラフ全体にわたるアクセス特権の伝搬、変数ロックの論理演算、ならびに／または記憶されたデータの解読など、この例において説明され得るこれらのステップを伴い得、これらのステップは、要求され得るように拡大されるか、縮小されるか、または並べ替えられ得る。適切な場合、ロックグラフおよびロックノード内のいくつかの機構が、ＳＤＦＴ方法の適切な適用から恩恵を受け得る。
【０１５３】
[0150]１次鍵８８０４が入力セクション８８０６に挿入され得、各１次鍵は、それの一致する暗号化された鍵マップ８８１０を解読し、それを鍵マップ８８０８構造に広げることを試みるために、それの関連するサイファ方法を使用し得る。各鍵マップ６２４０は、変数ロック８８１２によって使用され得るメイン鍵６２１０を生成し得る。（６２４０と等価な）各鍵マップ７８４０内に階層鍵のセット７８５０があり得、（７８５２〜７８５８などの）各階層鍵が、それぞれの入力セクション８３０２の１次鍵穴８３０６においてロックグラフの（７８２０〜７８３０などの）一致する階層ロックノードに挿入され得（この例では、７８５２〜７８５８などの階層鍵は８３０４における１次鍵と等価であり得る）、７８２０〜７８３０などの階層指定されたロックノードがＭＡＴＬＯＣＫを採用し得、ＭＡＴＬＯＣＫは、それを開くために最小２つの鍵、すなわち、７８５２などの階層鍵、および出力セクション８５１０または８８２６において見つけられ得る８５１２などの出力リンク鍵を要求し得る。鍵穴ロックノード８３００では、各鍵マップ８３１０内に、アクセス鍵セット（ＡＫＳ）８３１２と呼ばれるアクセス属性鍵セットロック解除鍵（ＡＡＫＳＵＫ）８３１４のセットがあり得、各ＡＡＫＳＵＫ鍵は、現在の鍵穴ロックノード８３００の入力セクション８３０２のアクセス鍵穴８３２０に挿入され得る。アクセス属性伝搬鍵（ＡＡＰＫ）８３３６のセットがこのようにして達成されていることがあると、（８３３６と等価な）ＡＡＰＫ８５２２は、次のリンクされたロックノード８５４０のアクセス鍵穴８５６０に挿入され得る。次に、アクセスロール鍵（ＡＲＫ）８３３４を含んでいることがあるアクセス属性鍵セット（ＡＡＫＳ）８３３２を有し得る。ＡＲＫは、ロックグラフ全体のための１次鍵８３０４のアクセスロールを定義し得る。８８４０〜８８４８など、様々なロックノードセクションのｄｉｇｎが、これらのＡＲＫを使用して認証され得る。ロックＩＤおよびメタデータのＤｉｇｎ８８４０は、ＲＡＴ公開ＡＲＫ８３４４（これは、ＮＡＣ仕様において説明されていることがあるように、ＲＡＴ非対称鍵ペアの公開部分であり得る）とセクション８８３０において指定された認証アルゴリズムとを使用して認証され得る。認証するために、セクション８８３０は、対応するｄｉｇｎ８８４０およびＲＡＴ公開ＡＲＫ８３４４とともに認証アルゴリズムにサブミットされ得る。認証が失敗した場合、セクション８８３０は危殆化されていることがあり、ロックノードロック解除プロセスは、エラーを引き起こし得、処理することを停止し得る。成功裡に認証された場合、暗号化された鍵マップの各Ｄｉｇｎ８８４２は、有効な挿入された１次鍵に対応する各暗号化された鍵マップについて認証され得る。認証するために、各ｅＫＭ８８１０ストリングが、対応するｄｉｇｎ８８４２およびＲＡＴ公開ＡＲＫ８３４４とともに認証アルゴリズムにサブミットされ得る。認証が失敗した場合、ｅＫＭは危殆化されていることがあり、ロックノードロック解除プロセスは、エラーを引き起こし得、処理することを停止し得る。すべての適切なｅＫＭが成功裡に認証された場合、暗号化された導出された鍵の各Ｄｉｇｎ８８４４が認証され得る。認証するために、各ｅＤＫ８８１４が、対応するｄｉｇｎ８８４４およびＲＡＴ公開ＡＲＫ８３４４とともに認証アルゴリズムにサブミットされ得る。認証が失敗した場合、ｅＤＫは危殆化されていることがあり、ロックノードロック解除プロセスは、エラーを引き起こし得、処理することを停止し得る。すべての適切なｅＤＫが成功裡に認証された場合、暗号化された鍵セットの各Ｄｉｇｎ８８４６が認証され得る。認証するために、各ｅＫＳ８８１８が、対応するｄｉｇｎ８８４６およびＲＡＴ公開ＡＲＫ８３４４とともに認証アルゴリズムにサブミットされ得る。認証が失敗した場合、ｅＫＳは危殆化されていることがあり、ロックノードロック解除プロセスは、エラーを引き起こし得、処理することを停止し得る。すべての適切なｅＫＳが成功裡に認証された場合、暗号化されたバッグの各Ｄｉｇｎ８８４８が認証され得る。認証するために、各ｅＢａｇ８８２２が、対応するｄｉｇｎ８８４８およびＣＯＲ  ＡＲＫ８３４８とともに認証アルゴリズムにサブミットされ得る。認証が失敗した場合、ｅＢａｇは危殆化されていることがあり、ロックノードロック解除プロセスは、エラーを引き起こし得、処理することを停止し得る。すべての適切なｅＢａｇが成功裡に認証された場合、このロックノードは、完全に認証されたと見なされ得る。ｅＢａｇは、リーダーのクラス（ＣＯＲ）アクセスロール鍵８３４８を使用して認証され得ることに留意されたい。これは、Ｎｕｔのペイロードを保持するロックノードについては当てはまり得るが、それらのバッグ中にＮｕｔメタデータを保持するロックノードについては、それを認証するためにＲＡＴ公開ＡＲＫが代わりに使用され得る。その場合、ロックノードのパラメータセクション８８３０において示される変数ロックタイプに基づいて、適切な変数ロックアルゴリズム８８１２が、鍵マップ８８０８からメイン鍵のセット７８４４を使用して、各暗号化された導出された鍵ストリング（ｅＤＫ）８８１４に対して試みられ得る。ｅＤＫ８８１４を解読することによって変数ロック８８１２を成功裡にロック解除することは、１つまたは複数の導出された鍵（ＤＫ）８８１６を生じ得る。各導出された鍵は、パラメータ８８０２に記憶され得る対応する暗号化された鍵セットストリング（ｅＫＳ）８８１８を解読し得る。ｅＫＳを解読することは、出力セクション８８２６構造とバッグ鍵とを保持し得る対応する鍵セット８８２０構造を生成し得る。鍵セット８８２０構造中で見つけられ得る（１つまたは複数の）出力リンク鍵は、出力セクション８８２６に記憶され得、それは、もしあればリンクされたロックノード８５３０の１次鍵穴に挿入され得る鍵として機能し得る。バッグ鍵は、適切なサイファを使用してパラメータセクションに記憶され得る暗号化されたバッグストリング（ｅＢａｇ）８８２２を解読し得る。解読されたバッグは、限定はしないが、Ｎｕｔ（ロックグラフ）のペイロード、ペイロードに関するメタデータ、Ｎｕｔのメタデータ、バッグのメタデータ、これらの任意の組合せ、および／または他のデータなど、データを保持し得る。バッグメタデータは、バッグ８８２４がＮｕｔパートを保持するのかＮｕｔ���イロードを保持するのかを示し得る。バッグがＮｕｔパートを保持する場合、それは、それがどのＮｕｔパートを表し得るか、ならびに、他の適切なＮｕｔパートメタデータおよび／または他のデータを示し得る。バッグがＮｕｔのペイロードを保持する場合、それは、記憶されたデータが実際のデータであり得るのかそれへの参照であり得るのか、ならびに、それへの参照であり得る場合、それがどのタイプの参照であり得るか、参照が何であり得るかおよび／またはそれがどこにあり得るかを示し得る。
【０１５４】
[0151]この一連のステップは、Ｎｕｔをロック解除するためにロックグラフ中の各ロックノードについて繰り返され得る。図８９は、Ｎｕｔロック解除の一般的なフローチャートを示す。ステップの大部分は、前の例において詳述されていることがあるが、いくつかのステップは、さらなる明確化を要求し得る。ステップ８９０２−ロックノードを適切なトラバーサルレベルに編成する。ロックノードはリストタイプ構造に行ベース形式で記憶され得るので、ロックグラフの実際のトポロジーは、各ロックノード内に記憶され得るリンケージ情報を使用して抽出され、構築され得る。グラフが構築され得ると、ロックノードが適切なシーケンスにおいてトラバースされ得るようにグラフレベルを適切に割り当てるために、１つまたは複数の追加のパスが行われ得る。ステップ８９０８−一部または全部のパスフレーズベース鍵穴についてプロンプトする。入力セクションの処理中に、パスフレーズベース鍵穴が空の鍵（パスフレーズ）と遭遇された場合、それは、パスフレーズについてプロンプトし得る。このデフォルト挙動は、別の関数をコールするかまたは空のパスフレーズ鍵穴をバイパスするために修正され得る。フローチャート中のいずれかの論理ステップまたはプロセスは、引き起こされ得、プロセスが休止されることにつながり得るエラーを有し得、これらは、これがより高いレベルのフローチャートであるので詳細に指定されず、たとえば、演算を試みるプロセスは、失敗し得、アルゴリズムを休止させ得る。フローチャートの残りは、前の例の経路に沿って続き得る。
【０１５５】
[0152]図９０は、ＮＵＴＳベースシステムが、Ｎｕｔ中に含まれているドキュメントをどのように開き得るかを示す。前方参照が導入され、すなわち、ＮＵＴｂｏｏｋ９０００は、Ｎｕｔを使用し得、パスワード、サイファ鍵および／または証明書のコレクションを記憶および編成することに関しては本質的に個人ＰＫＩとして働き得るデータコレクション編成アプリケーションであり得る。９００２および９００４などのファイルシンボルは、Ｎｕｔファイルを表すために図全体にわたって使用され得る。ＮＵＴｂｏｏｋシステム内に、アプリケーションから何らかの最小機能を得るためにロック解除され得るメインＮＵＴｂｏｏｋアクセス鍵Ｎｕｔ９００２が存在し得る。鍵は、Ｎｕｔ９００２内に記憶され得、メインＮＵＴｂｏｏｋ鍵と呼ばれることがあり、Ｎｕｔ９００２へのロック解除機構自体がパスフレーズを備え得る。メインＮＵＴｂｏｏｋ鍵９００２およびドキュメントアクセス鍵９００４とのハイアラーキ鍵関係があり得、したがって、この構成においてＮｕｔを保持するドキュメントにアクセスするために、ドキュメントアクセス鍵が要求され得る。したがって、ハイアラーキは、ドキュメントアクセス鍵９００４を開き、それにアクセスするために、メインＮＵＴｂｏｏｋ鍵９００２を要求するものとして設定され得る。ドキュメントアクセス鍵を保持するＮｕｔは、Ｎｕｔ  ＩＤ＃３３  ９０１６を有し得る。したがって、ペイロードに記憶され得る鍵９０２０は、鍵ＩＤ＃３３と呼ばれることがあり、ドキュメントアクセス鍵と、それを保持するＮｕｔのＮｕｔ  ＩＤの両方は、同じＩＤ、この場合は＃３３によって参照され得る。ドキュメント９０４０は、Ｎｕｔ  ＩＤ＃４４  ９０３６とともにＮｕｔ９０３０に記憶され得る。同様に、ドキュメントは、ドキュメント＃４４と呼ばれることがある。ユーザがドキュメント＃４４を開くことを決定したとき、１次鍵穴９０３２中の鍵穴のうちの１つは、ドキュメント＃４４を開くためにそれが鍵ＩＤ＃３３を要求し得ることを指定し得る。Ｎｕｔ＃３３  ９００４がＮＵＴｂｏｏｋから要求され得、Ｎｕｔ＃３３  ９００４を開くために、ＮＵＴｂｏｏｋは、Ｎｕｔ９００４が開かれることを要求し得る。そのＮｕｔが開かれるために、Ｎｕｔ９００２が開かれる必要があり得る。ユーザがＮｕｔ９００２へのパスフレーズを用いてユーザのＮＵＴｂｏｏｋをすでに初期化していることがあり、ＮＵＴｂｏｏｋがメモリ中のメインＮＵＴｂｏｏｋ鍵をキャッシュしていることがあると仮定する。その場合、Ｎｕｔ９００４を開くことは、ＮＵＴｂｏｏｋのドキュメントレベルアクセスのための追加のパスフレーズを要求するにすぎないことがあり、それが開かれ得ると、解読されたドキュメント＃４４  ９０５０を最終的に曝露するためにＮｕｔロック解除のカスケードが行われ得る。ＮＵＴｂｏｏｋは、セッション中のドキュメントフェッチングを促進するために有限時間量の間ドキュメントアクセス鍵をキャッシュし得るが、非アクティビティ、ハイバネーション、スクリーンロック、タイムアウト、および／または明示的ロッキングなど、いくつかのイベントは、ドキュメントアクセスのためにパスフレーズが再び入力されることを要求し得る。このセ��ションは、後のセクションにおいてさらに説明され得るＮＵＴｂｏｏｋアプリケーションおよびハイアラーキパスワード概念を紹介した。単一のドキュメントを開くために要求され得る一連のステップは多いことがあるが、採用される一部または全部の論理は、ロックノードとそれの反復的プロセスとに基づき得、その大部分はユーザから隠され得る。最終結果は、１つのデータが９０３０のようなＮｕｔに記憶され得、それのセキュリティが一部または全部の環境において無矛盾であり得ることであり得る。
【０１５６】
[0153]図９１は、それを保持するＮｕｔのＮｕｔ  ＩＤによってＮｕｔのペイロードを参照するためのＮＵＴＳ用語における共通使用法を示す。ここで、それは、鍵＃３３のためのタグ付けされた鍵穴９１２４が、Ｎｕｔ  ＩＤ＃３３  ９１１２をもつＮｕｔ９１１０を実際にどのように探していることがあるかを示し、それは、Ｎｕｔ＃３３が、鍵穴９１２４に挿入され得る単一の鍵９１１４を保持していることを予想し得ることを示す。これらの図および例の多くでは、Ｎｕｔファイルのファイル名が、Ｎｕｔがファイルに記憶され得る場合、たいていの演算においてめったに参照されないことがあることに留意することは、興味深いものであり得る。
【０１５７】
[0154]図の次のセットは、変数ロックとロックノードリンクとを使用するロックノードおよびロックグラフモデルのフレキシビリティおよび表現性を強調し得るロックグラフの様々な例示的な実施形態を示す。
【０１５８】
[0155]図９２は、受信側ロッキングモデルのリストの簡略化された実施形態を示し、いずれか１つの鍵９２１０がＯＲＬＯＣＫロックノード９２２０をロック解除し得、これにより、Ｎｕｔのペイロード９２９０を搬送するロックノードに達し得る。簡単のために、ロックノードはパッドロックとして図式的に表され得るが、実際には、ロックノードは、Ｎｕｔについての何らかのメタデータを記憶しつつあることがある、十分に機能するロックノードであることに留意されたい。
【０１５９】
[0156]図９３は、順序付きロッキングモデルの簡略化された実施形態を示し、鍵９３１０が第１に提示され、次いで鍵９３２０が第２に提示され得、これはＮｕｔのペイロード９３９０へのアクセスを可能にし得る。ＭＡＴＬＯＣＫロックノード９３１２は単一の鍵を要求し得、ＭＡＴＬＯＣＫロックノード９３２２は、鍵９３２０とロックノード９３１２からのリンク鍵の両方を要求し得る。
【０１６０】
[0157]図９４は、マスタ鍵を用いた順序付きロッキングモデルの簡略化された実施形態を示し、鍵９４１０が第１に提示され、次いで鍵９４２０が第２に提示され得、これはＮｕｔのペイロード９４９０へのアクセスを可能にし得る。または、マスタ鍵９４３０がＯＲＬＯＣＫロックノード９４３２に直接提示され得、これはペイロード９４９０へのアクセスを可能にし得る。ＯＲＬＯＣＫロックノード９４３２は、リンク鍵またはマスタ鍵のいずれかがそれをロック解除することを可能にし得る。
【０１６１】
[0158]図９５は、マスタ鍵を用いたロッキングモデルの簡略化された実施形態を示し、鍵９５１０またはマスタ鍵９５２０が一緒にまたは別々に提示され得、これはＮｕｔのペイロード９５９０へのアクセスを可能にし得る。
【０１６２】
[0159]図９６は、マスタ鍵を用いたロッキングモデルの簡略化された実施形態を示し、鍵９６１０またはマスタ鍵９６２０が一緒にまたは別々に提示され得、これはＮｕｔのペイロード９６９０へのアクセスを可能にし得る。ロックグラフ中のＭＡＴＬＯＣＫ配置９６３２は、このＮｕｔのためのいくつかの階層制御が所定の位置にあり得、それが、何らかのＮｕｔメタデータを記憶するＮｕｔパートであり得ることを示し得る。
【０１６３】
[0160]図９７は、セーフデポジットボックスロッキングモデルの簡略化された実施形態を示し、鍵９７１０と銀行鍵９７１２とが一緒に提示され得、これはＮｕｔのペイロード９７９０へのアクセスを可能にし得る。
【０１６４】
[0161]図９８は、マスタ鍵を用いた秘密共有ロッキングモデルの簡略化された実施形態を示し、鍵のセット９８１０から、秘密共有しきい値を満たすかまたは超える数の鍵が一緒に提示され得、これはＮｕｔのペイロード９８９０へのアクセスを可能にし得る。または、マスタ鍵９８２０がＯＲＬＯＣＫロックノード９８２２に直接提示され得、これはペイロード９８９０へのアクセスを可能にし得る。鍵９８１０は、鍵穴／鍵マップ構造が、秘密共有方式がＳＳＬＯＣＫロックノード９８１２において利用されることによって要求され得るｔｉｎｅを隠し得るので、パスフレーズ、対称鍵および／または非対称鍵の任意の組合せであり得る。
【０１６５】
[0162]図９９は、「ＰｒｉｖａＴｅｇｒｉｔｙ」タイプロッキングモデルの簡略化された実施形態を示し、ユーザ鍵９９２０がＯＲＬＯＣＫ９９２２に提示され得、これはペイロード９９９０へのアクセスを可能にし得る。または、９つの鍵９９１０がＭＡＴＬＯＣＫ９９１２に一緒に提示され得、これはＮｕｔのペイロード９９９０へのアクセスを可能にし得る。「ＰｒｉｖａＴｅｇｒｉｔｙ」モデルは、それのユーザに知られている鍵を使用してメッセージをセキュアに送信し得るテキストメッセージングシステムを実装するために、Ｄａｖｉｄ  Ｃｈａｕｍによって２０１６年の初めに提案されていたことがあるが、それは、９つの国際管轄区域すべてが、特定のメッセージへの法執行アクセスが極めて重要であり得、法的に保証され得ることに同意し得る場合のみ、そのアクセスを与えるために、最高９つの異なる鍵が９つの管轄区域によって保持されることを伴い得る、共謀（collusionary）バックドアシステムを有し得る。
【０１６６】
[0163]図１００は、複数のペイロードが単一のＮｕｔ内に記憶され得るマルチＮｕｔ構成の簡略化された実施形態を示し、ユーザ鍵１００１０またはマスタ鍵１００１２が、一方のペイロードまたは両方のペイロードにアクセスし得、これは、それらの階層アクセス制御に依存し得る。マスタ鍵１００２０は、ロックグラフを通るそれのトラバーサル経路により、ペイロード１００９２のみにアクセスし得る。このロックグラフは、モジュラーロックノードとそれのアクセス制御レイヤとが一緒に働くことのフレキシビリティを表示し得る。別個のデータパーセルは、この単一のＮｕｔ内で一部または全部、異なるやり方で保護され得る。マスタ鍵１００１２および１００２０が同じであり得る場合、それは、両方のペイロードへの鍵保持者アクセスを可能にし得る。
【０１６７】
[0164]図１０１は、マルチＮｕｔ構成の簡略化された実施形態を示し、ユーザ鍵１０１１０のうちのいずれかが一部または全部の３つのペイロードにアクセスし得、これは、それらの階層アクセス制御に依存し得る。ＳＳＬＯＣＫ１０１２２のための鍵１０１２０は、それのロックノードリンクにより、ペイロード１０１９４のみにアクセスし得る。このロックグラフは、モジュラーロックノードとそれのアクセス制御レイヤとが一緒におよび／または個々に働くことのフレキシビリティを表示し得る。別個のデータパーセルは、この単一のＮｕｔ内で異なるやり方で保護され得る。本開示のフレキシブルな性質は、ロッキング構成の無限変動を許可し得る。
【０１６８】
[0165]図１０２は、複数のペイロードを用いた直接ロッキングモデルの簡略化された実施形態を示し、このロックグラフが、通常の線形トポロジーではなく、Ｎｕｔのためのフラットなトポロジーを示し得る。ＯＲＬＯＣＫ１０２１２は、それを５つの異なるロックノードに接続するために要求される複数のリンク鍵を実装するためのいくつかのやり方があり得るという点で、興味深いノードであり得る。一実施形態では、ＯＲＬＯＣＫノード１０２１２の出力セクションが、５つの出力鍵を含んでいることがある。別の実施形態では、出力リンク鍵マップが、鍵穴中の鍵マップとして埋め込まれ得、次いで、出力セクションに伝搬され得る。さらに、階層鍵は、どの鍵が様々なノードにアクセスし得るかに関するロールをも果たし得る。
【０１６９】
[0166]図１０３は、順序付きメッセージパッシング例の簡略化された実施形態を示し、それが、Ｎｕｔと関係ベース鍵（ＲＢＫ。前方参照）とを使用する共謀抵抗設計であり得る。ミスターデータ（Mr. Data）１０３１０は、アリス、ボブ、チャーリーおよびダニー各々との関係を有し得る。一部または全部の参加者が、知り合いであり得る。ミスターデータの関係は、各人との関係ベース鍵を有することによって象徴され得る。ミスターデータは、秘密命令のセットを各人に送ることを希望し得るが、ミスターデータは、メッセージが、参加者の間の共謀による事前の覗き見の可能性なしに、あるシーケンスにおいて読み取られることを希望し得る。したがって、ミスターデータは、各々において特定のコンテンツをもつこれらの４つのＮｕｔを構築し得る。アリスに送られたＮｕｔ１０３２０は、それがアリスとミスターデータとの間で設定されたＲＢＫを使用してロックされ得るので、アリスによってのみ開かれ得る。１０３２０の内側に、アリスのためのメッセージとボブのための鍵、ＫBobとがあり得る。アリスは、アリスのメッセージを読み取り得、ボブに鍵ＫBobを送り得る。ボブに送られたＮｕｔ１０３３０は、２つの鍵、すなわち、ボブとミスターデータとの間のボブのＲＢＫ鍵と、アリスからの鍵ＫBobとを同時に使用してのみ開かれ得るＭＡＴＬＯＣＫを採用し得る。１０３３０の内側に、ボブのためのメッセージとチャーリーのための鍵、ＫCharlieとがあり得る。ボブは、メッセージを読み取り得、チャーリーに鍵ＫCharlieを送り得る。チャーリーに送られたＮｕｔ１０３４０は、２つの鍵、すなわち、チャーリーとミスターデータとの間のチャーリーのＲＢＫ鍵と、ボブからの鍵ＫCharlieとを同時に使用してのみ開かれ得るＭＡＴＬＯＣＫを採用し得る。１０３４０の内側に、チャーリーのためのメッセージとダニーのための鍵、ＫDannyとがあり得る。チャーリーは、メッセージを読み取り得、ダニーに鍵ＫDannyを送り得る。ダニーに送られたＮｕｔ１０３５０は、２つの鍵、すなわち、ダニーとミスターデータとの間のダニーのＲＢＫ鍵と、チャーリーからの鍵ＫDannyとを同時に使用してのみ開かれ得るＭＡＴＬＯＣＫを採用し得る。１０３５０の内側に、ダニーのためのメッセージがあり得る。ダニーはメッセージを読み取り得、メッセージを順序付けるためのミスターデータのプランがうまくいっていることがある。
【０１７０】
[0167]サイバーセキュリティの分野では、「バックドア」特徴は、そのトピックにまつわる様々なダイアログにおいて否定的な言外の意味を生み出し得る。旧来、バックドア機構は、アプリケーションレベルにおいて実装されていることがあり、これは、そのアプリケーションによって処理されているデータへの束縛されないアクセスを可能にしていることがある。このタイプのアプリケーションレベルアクセスは、どの当事者がそのバックドアエントリへのアクセスを獲得したかに応じて、そのアプリケーションによって処理されるデータのセキュリティに対する深刻な危殆化として解釈されていることがある。そのような状況における危殆化の知覚は、たいてい、それ自体のアプリケーションメモリ内の暗号化されていないデータを扱い、それにより、クリアテキストデータへのアクセスをバックドアユーザに潜在的に付与するそのようなアプリケーションの普及により、根拠が十分であることがある。ＮＵＴＳでは、特にＮｕｔのロッキングモデルでは、マスタ鍵の使用をＮｕｔへのあるタイプのバックドアと見なすものがいることがあるが、技術的に、それは、Ｎｕｔのすべてのロッキングモデルにおいて、すべてのドア（鍵穴）がフロントドアであり、Ｎｕｔへのアクセスを獲得するために適切な暗号鍵を要求するので、まったく異なり得る。ＮＵＴＳ  ＡＰＩまたは任意のＮＵＴＳ関係アプリケーション実施形態は、アプリケーションレベルにおいて設計された、意図されたバックドアを有しないことがある。Ｎｕｔにとって利用可能なマスタ鍵エントリを有するための多数の合法的に妥当な理由があり得るが、すべてのそのようなエントリは、秘密鍵によって定義され得るにすぎず、ロックノードの入力セクションのざっとの検査によって直接それとわかり得る。したがって、ＮＵＴＳ関係アプリケーション内にバックドアタイプ機能をインストールすることを試みる任意のアプリケーションは、Ｎｕｔのターゲットセットのためのマスタ鍵へのアクセスを最初に獲得した後にのみそれを行い得、それは、そのマスタ鍵が有効であるＮｕｔにのみ適用可能であり得る。これは、Ｎｕｔのセキュリティに対するデータ中心手法のフレキシビリティ、コンパートメント化、保護および／またはレジリエンシーを示し得る。
【０１７１】
[0168]ＮＵＴＳにおけるアクセス制御の一部または全部の方法では、カプセル化されたデータ構造内に暗号鍵を隠すパターンが伴われ得、その展開が、ターゲットデータセットへのアクセスを可能にし得る他の鍵を曝露し得る。本開示に示されている実施形態では、これらの鍵隠蔽方法の大部分は、データカプセル化方法および／またはデータ折り畳み方法を使用し得る。アクセス鍵を隠す方法は実装者によって行われる選好であり得るか、または、それは各ｎｕｔ内のパラメータ化設定であり得る。これらの方法は、データ折り畳み、データカプセル化、属性ベース暗号化、関数暗号化、参照モニタからの認可トークン、あるいは、それの暗号機構を解読またはロック解除するアクセス材料を与えられたときに後続のアクセス鍵の選択的暗号曝露を与え得る任意の他の方法を備え得る。本開示における論証的な実施形態は、それらの単純で簡単な仕組みおよびそれらのよく知られている特性のために選定されていることがある。他の等価な機構は、実施形態のいくつかの態様を合理化するかまたはより効率的にし得るが、それらは、依然として、同じ機能、すなわち、正確にターゲットデータセットへのアクセスを付与し得、デフォルトで参照モニタに依存しないことがある、アクセス属性へのアクセスを制御する機能を本質的に与え得る。任意の等価なアクセス属性曝露方法論が、ｎｕｔのコンテンツの保護の同じレベルを与えるために、ここまで示された方法の代わりに使用され得る。
【０１７２】
[0169]これにより、Ｎｕｔコンテナとそれの内部作業とに関するセクションを終え得る。内部機構は、直接、または、そのような実施形態のコーディングおよび管理を簡単にし得るＳＤＦＴ方法の使用法によって具現され得る。Ｎｕｔのペイロードは、限定はしないが、テキストファイル、バイナリアプリケーション、画像ファイル、リモートシステムへのアクセス鍵、実行可能スクリプト、コンピュータ間接続をセキュアに確立するための証明、データベース全体、オペレーティングシステム、他のＮｕｔへのリンク、ストリーミングデータ、および／またはテキストメッセージなど、任意の記憶可能なデジタルデータであり得る、Ｎｕｔが究極的に保護し得るものであり得る。Ｎｕｔのリッチな構成可能メタデータを通してＮｕｔが何を保持中であることがあるかを記述する、Ｎｕｔのアビリティにより、共通ファイルタイプの標準リストは、それの保持能力とは程遠くなり得る。ロックノードアーキテクチャは、ペイロードがＮｕｔをスパンすることを可能にし得、したがって、それは、無制限論理コンテナサイズを生じ得る。固体ＮＵＴＳ互換チップまたは回路が利用可能であり得る場合、物理デバイスをＮｕｔ自体に変えることが可能であり得、したがって、デバイスは、鍵保持者によってのみアクセスされ得る。一連のそのようなデバイスは、適切な認証を用いてのみ動作可能であり得るネットワークおよびイントラネット全体を構成し得る。モジュラーロックノード設計のフレキシブルな性質は、Ｎｕｔのためのロッキング構成の無限変動を許可し得る。以下のセクションでは、いくつかの共通サービスおよび方法論が、平均的ユーザの手が届かないように見えていることがある能力を提供するようにどのように拡大され、改善され、再設計され得るかを示すためにセキュアなストレージの基礎としてＮｕｔを使用し得る様々なシステムおよび／または方法が紹介され得る。
【０１７３】
モジュラーＩ／Ｏ
[0170]データがプログラムに適切にもたらされ、それの実行中のメモリスペースにおいて変換され、計算および／または編集され得、次いで、永続的に適切に記憶され得ることを確かめることに、著しい量のプログラマーの労力が費やされ得る。このモードのアプリケーション開発の不快な副産物は、ファイルフォーマットの最終的な旧式化およびそれらの様々なバージョンのものであり得る。自分自身のデータを所有し、所持し、制御することは、有用で賞賛に値する目標であり得るが、そのデータを適切に読み取らないことがある場合、それは何に役立つのか？フォーマットを読み取り、フォーマットを書き込み、読み取られたデータに作用し、および／または読み取られたデータを表示するアビリティは、一般的なプログラムの基本的な構成要素のうちのいくつかを構成し得る。モジュラーＩ／Ｏ（ＭＩＯ）は、これらの論理演算を、モジュラー構成要素のリポジトリにモジュール化するシステムおよび／または方法であり得、そのリポジトリは、それにアクセスし得る誰によっても使用され得る。ＭＩＯの副産物は、ユーザが過去のバージョンのファイル読取りおよび書込みルーチンにアクセスすることを可能にし得、それにより、それらのより古いデータが可読になり得る、ファイルフォーマットコンバージョンモジュールを作成するアビリティであり得る。これは、後方互換性と呼ばれることがある。前方互換性の概念も提供され得るが、この特徴の効用は、アプリケーションモジュールを設計し得るプログラマーの腕の良さに依存し得る。一部または全部のモジュールがＮｕｔにおいてカプセル化され得、したがって、各モジュールの認証、保護および／またはアクセス制御がデフォルトで存在し得ることは、ＭＩＯシステムの好ましい実施形態であり得る。図１０４は、モジュラーＩ／Ｏにおける一般的な構成要素を示す。要素１０４５０は、ＭＩＯ構成要素を記憶し得、編成するサーバプロセスであり得る、モジュラーＩ／Ｏリポジトリ（ＭＩＯＲ）であり得る。ＭＩＯＲは、そのようなモジュールのためのインテリジェントキャッシュとして働き得るローカルおよび／またはリモートサーバタイプアプリケーションとして具現され得る。他の実施形態では、ＭＩＯＲは、ローカルデバイス上でローカルキャッシュを有し得、したがって、それは、通常要求されるＭＩＯモジュールをより良く容易にし得る。ファイル１０４０４を読み取りおよび／またはそれに書き込み得る一般的なアプリケーション１０４０２は、ファイルを読み取り１０４０６、書き込む１０４０８ために、概念的におよびプログラム的にモジュールに分解され得る。ファイル１０４０４は、アプリケーション１０４０２に固有であり得る特定のフォーマット「Ａ」においてフォーマットされ得る。同様に、この図は、それらが「Ｂ」および「Ｃ」にあり得るという特定のフォーマットについての、対応するデータファイル１０４１２および１０４２０をもつ２つの他のアプリケーション１０４１０および１０４１８と、ＭＩＯＲ１０４５０に記憶され得るそれらのそれぞれの読取りおよび書込みモジュール１０４１４、１０４２２、１０４１６および１０４２４とを示す。ＭＩＯＲは、アプリケーションのための異なるタスクまたは手続きを実施し得る他のモジュールを含んでいることがある。１０４２６〜１０４３２によって、それのそれぞれのラベルによって指定されているように、あるファイルフォーマットから別のファイルフォーマットへの変換を実施し得るファイルコンバージョンモジュールが示され得、モジュールＣｏｎｖｅｒｔ＿Ａ＿Ｂ１０４２６は、ファイル読取りモジュール１０４０６によるファイルフォーマット「Ａ」からのアプリケーションのメモリへのデータ読取りをとり得、次いで、それは、メモリ構造を、ファイル読取りモジュールＦｉｌｅ＿Ｒｅａｄ＿Ｂ１０４１４によって作成され得るメモリ構造に似ているものに変換し得る。
【０１７４】
モジュラーＩ／Ｏ：読取りおよび書込み
[0171]図１０５は、ＭＩＯＲ１０５００を使用する単純な読取りおよび書込み演算を示す。ファイルフォーマット「Ａ」において記憶され得るファイルを処理し得るアプリケーション１０５０２は、ファイル読取りモジュールＦｉｌｅ＿Ｒｅａｄ＿Ａ１０５０６をＭＩＯＲ１０５００に要求することによって、フォーマット「Ａ」においてフォーマットされたファイルＦ＿Ａ１０５０４を読み取り得る。モジュール１０５０６は、見つけられた場合、Ａｐｐ＿Ａ１０５０２に送信され得１０５１０、その時点において、Ａｐｐ＿Ａ１０５０２は、ファイル読取りモジュールＦｉｌｅ＿Ｒｅａｄ＿Ａ１０５０６をインストールし得、それをファイルＦ＿Ａ１０５０４に対して実行し得る。モジュールＦｉｌｅ＿Ｒｅａｄ＿Ａ１０５０６は、ファイルＦ＿Ａ１０５０４に対してファイル読取りを実施し得、ファイルＦ＿Ａ１０５０４のコンテンツを表し得る内部メモリ構造を構築し得る。ファイルＦ＿Ａ１０５０４のコンテンツを表し得るこのメモリ構造は、次いで、コーリングアプリケーションＡｐｐ＿Ａ１０５０２に転送され得る。成功裡に転送されると、Ａｐｐ＿Ａ１０５０２は、それの実行中のメモリスペースにおいて存在し得るファイルＦ＿Ａ１０５０４のコンテンツを用いてそれの関数を実施し続け得る。他の実施形態では、ファイル読取りモジュール１０５０６とアプリケーションモジュール１０５０２の両方がそれにより同じメモリスペースを共有し得る設備があり得る場合、ファイルコンテンツがファイル読取りモジュールＦｉｌｅ＿Ｒｅａｄ＿Ａ１０５０６によって読み取られていることがあると、メモリ構造をＡｐｐ＿Ａ１０５０２に転送する必要がないことがある。
【０１７５】
[0172]アプリケーションＡｐｐ＿Ａ１０５０２が、ファイル形式に戻る、ファイルＦ＿Ａ１０５０４の修正されたコンテンツを記憶する準備ができているとき、それは、ＭＩＯＲに接触し得、Ｆｉｌｅ＿Ｗｒｉｔｅ＿Ａ１０５０８と呼ばれる、ファイルフォーマット「Ａ」のためのファイル書込みモジュールを要求し得る。モジュール１０５０８を受信する１０５１２と、Ａｐｐ＿Ａは、読取りプロセスと同じ、アプリケーションメモリ構造を転送するための方法論を使用してそれをインストールし得、実行し得る。書込みモジュール１０５０８は、永続ストレージへの書込み演算を実施し得、これは修正されたファイルＦ＿Ａ１０５２０を作成し得る。読取りモジュール１０５０６および書込みモジュール１０５０８についてのＭＩＯＲへの要求は、アプリケーション開発者によって適切であると見なされ得る任意のシーケンスにおいて行われ得る。一実施形態では、アプリケーションは、一部または全部の必要なＩ／Ｏ演算がアプリケーションによって実施され得、これが、後で望ましくない障害を防ぎ得ることを確信するために、進む前に前もって一部または全部の関連するＩ／Ｏモジュールを要求し得る。別の実施形態では、要求およびフェッチング手続きを促進するために保守され得る、前に実行されたアプリケーションによる前にフェッチされたモジュールのローカルにキャッシュされたＭＩＯＲがあり得る。
【０１７６】
[0173]限定はしないが、共有メモリセグメント、メモリマップトファイル、データベース、プロセス間メッセージ、バイナリメモリダンプファイル、および／またはコンバートされたメモリダンプなど、２つまたはそれ以上の論理プロセス間のメモリ構造を当業者に転送し、および／または共有する多くの方法があり得る。ＭＩＯシステムにおけるアプリケーションメモリ転送の好ましい方法は、プロセス間で、コンバートされたメモリダンプを使用することであり得る。ＪＳＯＮ読取りおよび書込み関数は、バイナリデータを認識するために修正され得、それらを、ｂａｓｅ６４符号化方式または他のバイナリ−テキスト符号化方式との間で自動的にコンバートし得る。図１０６は、一般的なＭＩＯファイル読取り演算に関与し得るデータ変換および転送を示す。ＭＩＯ読取りモジュールＦｉｌｅ＿Ｒｅａｄ＿Ａ１０６０４は、フォーマット「Ａ」におけるＦ＿Ａと称するファイル１０６０２をそれの実行中のメモリ１０６０６に読み取り得る１０６２０。したがって、ファイル１０６０２の関連するコンテンツは、アプリケーションメモリ構造１０６０６において表され得る１０６３０。アプリケーションメモリは、ＪＳＯＮ互換データ構造１０６０６に記憶され得、ＪＳＯＮ書込み関数コールを使用してテキスト形式１０６１０にマーシャリングされ得る。随意に、ＪＳＯＮ出力は、追加されたセキュリティのためにＮｕｔコンテナ１０６０８に埋め込まれ得る。したがって、アプリケーションメモリ１０６０６は、コンバートされ、読取りモジュール１０６０４の外部１０６０８に記憶されていることがある。次いで、Ｎｕｔ１０６０８は、Ａｐｐ＿Ａ１０６１２によって開かれ、メモリに読み取られ得、ＪＳＯＮ読取りがデータパーセル１０６１０に対して実施され得る。このようにしてデータをＡｐｐ＿Ａ１０６１４の実行中のメモリに再構築すること。データ転送方法１０６２２および１０６２４は、限定はしないが、コマンドライン引数、プロセス間メッセージ、および／または（１つまたは複数の）データファイルを含み得る。読取りアプリケーションおよび／またはデータ処理アプリケーションは、異なるマシン、同じマシン、別個のスレッドまたは別個のコア上の別個のプロセスであり得るか、あるいは、アプリケーションは、それの実行中のコードをオンザフライで修正する動的能力をもつローカルまたはリモートマシン上の単一の論理プロセスであり得る。
【０１７７】
モジュラーＩ／Ｏ：後方互換性
[0174]アプリケーションは、それの有効期間全体にわたる強化をもつバージョン変更を発行することによって経時的に漸進的変更を受け得る。これらのバージョン変更の多くは、ユーザの作業をセーブするために使用されるストレージファイルのフォーマット変更を含み得る。歴史的に、これは、２つの問題、すなわち、係累（encumbrance）および旧式化につながり得る。係累は、製品ラインの寿命の間のあらゆるフォーマット変更についてあらゆるバージョンに後方互換性能力を追加することによりソフトウェアが肥大化されるときであり得る。これは、非常にたくさんのフォーマットバージョン変更を伴い得る。さらに、アプリケーションが扱うことを希望し得る他のサードパーティまたはオープンフォーマットがあり得る場合、それは、さらなるソフトウェア肥大化を生じ得る。図１０５は、アプリケーションが利用し得る任意のバージョンの任意のフォーマットについて、モジュラー読取りおよび書込みモジュールがＭＩＯＲにおいて利用可能であり得る場合、過度の肥大化なしにファイルがどのように読み取られ、処理され得るかを示す。さらに、図１０５は、より新しい読取りおよび書込みモジュールがどのように独立してＭＩＯＲに追加され得、次に、ＭＩＯＲと通信し得るあらゆるアプリケーションがプログラム修正なしにどのように追加のフォーマッティングモジュールへのアクセスを有し得るかを示す。これらのより新しいモジュールは、同じアプリケーション製品ラインのための異なるバージョンのファイルフォーマットを読み取るアビリティであり得るか、または、それは、アプリケーション開発者を含む誰かによって書き込まれたサードパーティファイルフォーマットを読み取り、書き込むための互換モジュールであり得る。
【０１７８】
[0175]図１０７は、アプリケーションＡｐｐ＿Ｂ１０７０２のバージョンがより最近のものであり得、対応するより新しいフォーマットバージョン「Ｂ」のデータファイルを使用し得るが、ユーザがより古いバージョン「Ａ」のファイルフォーマット１０７０４を読み取り、書き込むことを望み得る、後方互換性例を示す。そのような場合に、１０７０８および１０７１０などのデータコンバージョンモジュールが作成され、ＭＩＯＲ１０７００に記憶され得る。コンバージョンモジュールは、１つのフォーマットを読み込み、別のフォーマットを生成することを担当し得、この例では、コンバージョンモジュール１０７０８は、「Ａ」のフォーマットされたファイルを読み込み得、それを、「Ｂ」のフォーマットされたファイルにコンバートし得、コンバージョンモジュール１０７１０は、「Ｂ」のフォーマットされたファイルを読み込み得、それを、「Ａ」のフォーマットされたファイルにコンバートし得る。ファイルＦ＿Ａ１０７０４はＡｐｐ＿Ｂ１０７０２に提示され得、ここで、それは、ファイルのメタデータから、ファイルが互換性のないフォーマットにあり得ると決定し得、「Ａ」を読み取るために要求され得る読取りモジュールシーケンスについてＭＩＯＲ１０７００への要求を行うことに進み得、「Ｂ」ファイルを生成し得る。ＭＩＯＲ１０７００は、以下のモジュール、すなわち、Ｆｉｌｅ＿Ｒｅａｄ＿Ａ１０７０６、Ｆｉｌｅ＿Ｗｒｉｔｅ＿Ａ１０７１２、Ｃｏｎｖｅｒｔ＿Ａ＿Ｂ１０７０８およびＣｏｎｖｅｒｔ＿Ｂ＿Ａ１０７１０をＡｐｐ＿Ｂ１０７０２に送ることによって応答し得る。Ａｐｐ＿Ｂ１０７０２は、ファイルＦ＿Ａ１０７０４上でＦｉｌｅ＿Ｒｅａｄ＿Ａ１０７０６を呼び出し得、Ｆｉｌｅ＿Ｒｅａｄ＿Ａ１０７０６は、次いで、Ｃｏｎｖｅｒｔ＿Ａ＿Ｂ１０７０８を呼び出し得、「Ａ」形式のそれのメモリ構造をモジュール１０７０８に転送し得、次いで、モジュール１０７０８は、受信されたデータを「Ｂ」形式にコンバートし得、それをＡｐｐ＿Ｂ１０７０２に転送し得る。Ａｐｐ＿Ｂが、修正されたデータを「Ａ」フォーマットにおけるファイルＦ＿Ａに再びセーブする準備ができているとき、それは、Ｃｏｎｖｅｒｔ＿Ｂ＿Ａ１０７１０を呼び出し、形式「Ｂ」のそれのメモリ構造をモジュール１０７１０に転送し得、次いで、Ｃｏｎｖｅｒｔ＿Ｂ＿Ａ１０７１０は、それのメモリ構造を形式「Ａ」にコンバートし得、Ｆｉｌｅ＿Ｗｒｉｔｅ＿Ａ１０７１２を呼び出し得、「Ａ」形式のそれのメモリ構造を転送し得、次いで、Ｆｉｌｅ＿Ｗｒｉｔｅ＿Ａ１０７１２は、形式「Ａ」のそれの修正されたコンテンツでファイルＦ＿Ａ１０７１４に上書きし得、ファイルフォーマット「Ａ」においてファイル書込みをフォーマットし得る。より複雑な例は、いくつかのコンバージョンモジュールが、適切なより古いフォーマットバージョンへの反復的コンバージョンプロセスを実施するためにシーケンスにおいてコールされ得るか、または、開発者が、そのような要求を合理化するために、Ｃｏｎｖｅｒｔ＿Ｂ＿ＦおよびＣｏｎｖｅｒｔ＿Ｆ＿Ｂなど、頻繁に使用されるバージョン変更コンバータモジュールを追加していることがある場合であり得る。
【０１７９】
[0176]ソフトウェア肥大化は単純な計算を用いて示され得、すなわち、普及しているアプリケーションが、各々１０年にわたる、５つの大きいリビジョン、３つの大きいバージョン変更を伴う３つのオペレーションシステムにわたる３つのファイルフォーマットバージョンを受けていることがあると仮定する。また、これらの変更のうちのあらゆるものがアプリケーションのための異なるバージョンのＩ／Ｏルーチンを要求していることがあると仮定する。これは、最も最近のバージョンのアプリケーションが、それ自体内で最高１３５個のバージョンのそれのＩ／Ｏ関数を搬送することに潜在的につながり得る。仮にこれが極端な場合であり得るとしても、経時的にアプリケーションにおける後方互換性を維持するために発生され得るプログラムコードの急増を理解し得る。この特性は、ソフトウェアの係累プロパティと呼ばれることがある。
【０１８０】
[0177]矛盾なく更新されたモジュールがそれのリポジトリに追加されている、適切に保守されるＭＩＯＲ１０７００は、履歴Ｉ／Ｏフォーマットライブラリとして働き得、ユーザが、将来における任意の時間にそれらのデータファイルのより古いバージョンにアクセスすることを可能にし得、これは、ソフトウェアおよびデータフォーマット旧式化の問題に対処し得る。アプリケーションがもはや生産されず、販売されず、および／または保守されないことがあるとき、そのアプリケーションの耐用寿命は、それがより新しいオペレーティングシステムバージョン上で実行することを可能にし得るより新しいバージョンが出現しないことがあるので、大幅に短縮され得る。アプリケーションが、非互換性により、現代のコンピュータ上でもはや実行されないことがあるとき、そのアプリケーションによってフォーマットされたデータファイルは、アクセスすることが困難であり得る。賢いユーザおよび開発者はこれらの問題の様々なソリューションを見つけていることがあるが、それは、それらのパートに関する多くの労力および／または特殊な知識を要求し得る。ＭＩＯＲを使用することは、少なくとも１人の開発者が、今や現存しないアプリケーションに関連し得るモジュールを保守し得、その開発者が、より新しいバージョンの様々なオペレーティングシステムとの互換性があり得る、周期的に追加されるべきより新しいバージョンのモジュールを作り得ることを要求し得る。このタイプのルーチン保守は、自動ユニットテストツールを使用して自動化され得、ＯＳタイプおよびバージョンの適切なモジュールを適時に自動発生していることがある。更新されたモジュールはＭＩＯＲに挿入され得、ＭＩＯＲへのアクセスを有し得る誰もが開発者の作業から恩恵を受け得、特定のＭＩＯＲがインターネット上の誰によってもアクセス可能であり得る場合、インターネット上の一部または全部のユーザは、下位レベル問題とそれらを自動的に解決するために呼び出され得るプロセスとについてユーザがよく知っていることを要求することなしに、自動的にそのＭＩＯＲから恩恵を受け得る。ソフトウェア後方および前方互換性問題は、ソフトウェアの旧式化プロパティと呼ばれることがある。
【０１８１】
モジュラーＩ／Ｏ：前方互換性
[0178]ユーザは、時々、ユーザが何年も前にアプリケーションを買い、インストールし、および／または使用していることがあるが、ユーザが長年にわたってそれの後続のアップグレードを購入していないことがある、状況を経験し得る。ただし、アプリケーションは依然としてユーザにとって機能的であり得るが、それは、ユーザのより古いバージョンのアプリケーションとの互換性があり得るファイルフォーマットを読み取り、書き込み得るにすぎない。最も新しいバージョンのアプリケーションは、過去のある時点において、追加の特徴をもつより新しいファイルフォーマットを導入していることがある。この状況は、ユーザに対して２つの問題を提示し得、すなわち、１）ユーザのバージョンのアプリケーションは最新のフォーマットバージョンにおいてフォーマットされたファイルを読み取らないことがあり、２）このアプリケーションから最新のフォーマットを読み取り得る他のプログラムは、ユーザのより古いフォーマットされたデータにアクセスすることが可能でないことがある。第１の問題のソリューションは前方互換性読取り演算と呼ばれることがあり、それにより、ユーザのより古いアプリケーションは、ユーザがユーザのより古いプログラムを使用してより新しいバージョンにおいてフォーマットされたファイルを読み取ることを可能にし得る漸進的コンバージョンをデータに対して実施し得るモジュールのセットをＭＩＯＲから直接ロードし得る。第２の問題のソリューションは前方互換性書込み演算と呼ばれることがあり、それにより、ユーザのより古いアプリケーションは、ユーザがユーザのより古いプログラムを使用してより新しいバージョンにおいてフォーマットされたファイルを書き込むことを可能にし得る漸進的コンバージョンをデータに対して実施し得るモジュールのセットをＭＩＯＲから直接ロードし得る。前方互換性を念頭に置いて築かれたプログラムは、このタイプの遷移を、ほとんどまたはまったく機能の損失なしに、ＭＩＯＲを使用してより容易でシームレスにし得る。より最近のフォーマットバージョンにおいて提供されたより新しい特徴は、あまり洗練されていないアプリケーション構成体に最適にマッピングされ得るか、または、ただ生データと置換され、ユーザが後でそれを修正することを可能にし得る。図１０８は、これらの２つの異なる論理演算を例とともに示す。
【０１８２】
[0179]前方互換性読取り演算：Ａｐｐ＿Ａ１０８０２はバージョン「Ａ」においてフォーマットされたファイルとの互換性があり得るが、ユーザはより新しいファイルフォーマット「Ｃ」を読み取ることを希望し得る。この要求はＭＩＯＲ１０８００に伝達され得、それは、これらの回帰的コンバージョンを実施し得るモジュールのシーケンス、すなわち、Ｆｉｌｅ＿Ｒｅａｄ＿Ｃ１０８０６、Ｃｏｎｖｅｒｔ＿Ｃ＿Ｂ１０８０８およびＣｏｎｖｅｒｔ＿Ｂ＿Ａ１０８１０で返答し得る。モジュールＦｉｌｅ＿Ｒｅａｄ＿Ｃ１０８０６は、バージョン「Ｃ」においてフォーマットされ得るファイルＦ＿Ｃ１０８０４を読み取り得る。モジュール１０８０６は、次いで、回帰的コンバージョン関数Ｃｏｎｖｅｒｔ＿Ｃ＿Ｂ１０８０８を呼び出し得、モジュール１０８０６のメモリ構造をそれに転送し得る。モジュールＣｏｎｖｅｒｔ＿Ｃ＿Ｂ１０８０８は、メモリ中のデータに対してコンバージョンを実施し得、フォーマット「Ｂ」、すなわち、アプリケーションの前のファイルフォーマットバージョンとの互換性があるメモリ構造を生成し得る。モジュール１０８０８は、次いで、回帰的コンバージョン関数Ｃｏｎｖｅｒｔ＿Ｂ＿Ａ１０８１０を呼び出し得、モジュール１０８０８のメモリ構造をそれに転送し得る。モジュールＣｏｎｖｅｒｔ＿Ｂ＿Ａ１０８１０は、メモリ中のデータに対してコンバージョンを実施し得、フォーマット「Ａ」、すなわち、より古いアプリケーションＡｐｐ＿Ａとの互換性がある所望のファイルフォーマットバージョンとの互換性があるメモリ構造を生成し得る。モジュール１０８１０は、フォーマット「Ａ」におけるそれのメモリ構造をコーリングアプリケーションＡｐｐ＿Ａ１０８０２に転送し得、Ａｐｐ＿Ａはそれを処理し得る。したがって、より新しいバージョンのファイルフォーマットは、アプリケーションへの修正なしにより古いバージョンのアプリケーションによって読み取られ得る。
【０１８３】
[0180]前方互換性書込み演算：Ａｐｐ＿Ａ１０８４０はバージョン「Ａ」においてフォーマットされたファイルとの互換性があり得るが、ユーザはより新しいファイルフォーマット「Ｃ」を書き込むことを希望し得、これは、それの元の能力を超えていることがある。この要求はＭＩＯＲ１０８００に伝達され得、それは、これらの漸進的コンバージョンを実施し得るモジュールのシーケンス、すなわち、Ｆｉｌｅ＿Ｗｒｉｔｅ＿Ｃ１０８１６、Ｃｏｎｖｅｒｔ＿Ｂ＿Ｃ１０８１４およびＣｏｎｖｅｒｔ＿Ａ＿Ｂ１０８１２で返答し得る。Ａｐｐ＿Ａ１０８４０は、Ｃｏｎｖｅｒｔ＿Ａ＿Ｂ１０８１２を呼び出し得、Ａｐｐ＿Ａ１０８４０のメモリ構造をそれに転送し得る。モジュールＣｏｎｖｅｒｔ＿Ａ＿Ｂ１０８１２は、メモリ中のデータに対してコンバージョンを実施し得、フォーマット「Ｂ」との互換性があるメモリ構造を生成し得る。モジュール１０８１２は、次いで、漸進的コンバージョン関数Ｃｏｎｖｅｒｔ＿Ｂ＿Ｃ１０８１４を呼び出し得、モジュール１０８１２のメモリ構造をそれに転送し得る。モジュールＣｏｎｖｅｒｔ＿Ｂ＿Ｃ１０８１４は、メモリ中のデータに対してコンバージョンを実施し得、フォーマット「Ｃ」との互換性があるメモリ構造を生成し得る。モジュール１０８１４は、次いで、ファイル書込み関数Ｆｉｌｅ＿Ｗｒｉｔｅ＿Ｃ１０８１６を呼び出し得、モジュール１０８１４のメモリ構造をそれに転送し得る。モジュールＦｉｌｅ＿Ｗｒｉｔｅ＿Ｃ１０８１６は、バージョン「Ｃ」、すなわち、所望のファイルフォーマットバージョンにおいてフォーマットされ得るファイルＦ＿Ｃ１０８１８を書き込み得る。したがって、より新しいバージョンのファイルフォーマットは、アプリケーションへの修正なしにより古いバージョンのアプリケーションによって書き込まれ得る。
【０１８４】
[0181]本開示は、示されている２つの例によって限定されない。コンバージョンモジュールは、任意のオペレーティングシステム上のアプリケーションのための一部または全部のバージョンのファイルフォーマットにアクセスするために生成され得る。コンバージョンモジュールは、それのアプリケーション製品ライン内のコンバージョンに限定されないことがあり、異なるアプリケーション製品ラインにわたってコンバージョンを実施するように書き込まれ得る。コンバージョンモジュールは、限定はしないが、ファイル−データベース、データベース−ファイル、ファイル−データストリーム、データストリーム−ファイル、ファイル−ウェブページ、ウェブページ−ファイル、ファイル−クラウドストレージ、クラウドストレージ−ファイルなど、データの、異なるフォーマットへのコンバージョンを含み得る。
【０１８５】
モジュラーＩ／Ｏ：ディスプレイ
[0182]図１０９は、動作中のＭＩＯＲディスプレイモジュールの図を示す。アプリケーションＡｐｐ＿Ａ１０９０２がファイルＦ＿Ａ１０９０４からのデータをそれのメモリに成功裡に読み取っていることがあると、それは、ファイルＦ＿Ａ１０９０４のコンテンツをユーザに表示するためにモジュールＤｉｓｐｌａｙ＿Ａ１０９０８の機能を使用することに進み得る。ディスプレイモジュールでは、モジュールの機能的態様は、アプリケーション、データコンテンツ、および／または開発者の設計に応じて、大幅に変動し得る。いくつかのモジュールは、ディスプレイモジュールがアプリケーションメモリ中のデータに直接アクセスすることを可能にし得る共有メモリ方法を使用するように設計され得、他のものは、データをディスプレイモジュールに転送し得、これはディスプレイモジュールがデータを示すことを可能にし得る。ディスプレイモジュールの他の実施形態は、示されるべきデータのタイプのための命令および／またはテンプレートをスクリーンフォーマットしていることがあり、場合によっては編集され得る。ディスプレイ機能のこのモジュール化は、コーリングプログラムが相対的に変更されないままであることを可能にしながら、カスタムディスプレイモジュールが様々なハードウェアおよびＯＳプラットフォームのために作成されることを可能にし得る。
【０１８６】
[0183]ＮＵＴｂｏｏｋセクションにおいて後で説明されたコレクションアーキテクチャのカタログは、モジュラーディスプレイの軽量態様を利用し得る。データセットの異なるコレクションを扱い、表示し、および／または編集するために一層大きいモノリシックアプリケーションを築く代わりに、ＮＵＴｂｏｏｋは、ＭＩＯＲアーキテクチャを広範に利用し得、これは、検査されているＮｕｔにおけるペイロードのタイプに基づいてＮＵＴｂｏｏｋに断片的なカスタマイゼーションを与え得る。
【０１８７】
モジュラーＩ／Ｏ：アプリケーション
[0184]図１１０では、ＭＩＯＲ１１０００は、１１０２２などのモジュラーアプリケーションモジュールを記憶し得る。ＮＵＴｂｒｏｗｓｅｒ１１０２０（前方参照）は、外観および挙動においてたいていのファイルおよびディレクトリブラウザと同様であり得るアプリケーションであり得るが、それは、Ｎｕｔを認識し得、Ｎｕｔの広範なメタデータを見ることによってそれらに作用し得る。Ｎｕｔ１１０３０のメタデータ１１００２内に、それが保護し、記憶しつつあることがあるペイロードのタイプに関係する情報があり得る。ユーザがＮＵＴｂｒｏｗｓｅｒ１１０２０からＮｕｔを選択し、それを開くためにダブルクリックしたとき、ＮＵＴｂｒｏｗｓｅｒは、Ｎｕｔを開き得、ファイルを開くためにどのモジュールが要求され得るかを解明するためにメタデータを読み取り得る。メタデータは、限定はしないが、アプリケーションバージョン、ファイルフォーマットバージョンおよび／またはディスプレイバージョンなど、データを含み得る。次いで、ＮＵＴｂｒｏｗｓｅｒは、アプリケーションＡｐｐ＿Ａ１１０２２とＦｉｌｅ＿Ｒｅａｄ＿Ａ１１０２４とＤｉｓｐｌａｙ＿Ａ１１０２６とを探す要求をＭＩＯＲ１１０００に対して行い得る１１００４。ＭＩＯＲ１１０００は一部または全部のモジュールを返し得、アプリケーションＡｐｐ＿Ａ１１０２２はＮＵＴｂｒｏｗｓｅｒ１１０２０によって呼び出され得る。Ａｐｐ＿Ａが実行中であると、それは、Ｎｕｔ１１０３０に記憶され得るＮｕｔペイロードＦ＿Ａ１１０２８のコンテンツを読み取るために、Ｆｉｌｅ＿Ｒｅａｄ＿Ａ１１０２４を呼び出し得る。メモリ構造を１１０２４からコーリングモジュールＡｐｐ＿Ａ１１０２２に転送した後に、それは、データＦ＿Ａ１１０２８をユーザに示すためにディスプレイモジュールＤｉｓｐｌａｙ＿Ａ１１０２６を呼び出し得る。
【０１８８】
[0185]モジュラーＩ／Ｏアプリケーションモジュールは、それらが何を保持し、何を行い得るかにおいて大幅に変動し得、いくつかの実施形態では、それは複雑な論理計算モジュールであり得、別の実施形態では、それは、ソフトウェアインストールパッケージ全体を記憶し得、別の実施形態では、それは、Ｉ／Ｏ、ディスプレイおよび／またはアプリケーション関数の一部または全部の態様を含んでいることがあり、別の実施形態では、それは、起源（Genesis）Ｎｕｔを含んでいる情報を含んでいることがあり、これはリモート様式でユーザの環境の再生（reincarnation）をキックスタートし得る。モジュラーＩ／Ｏアプリケーションモジュールの機能は、これらの場合に限定されない。
【０１８９】
[0186]読取り、書込み、ディスプレイおよび／またはアプリケーションなど、モジュラーＩ／Ｏ特徴は、適切に認可されたユーザのみがそれにアクセスし得るように、ＭＩＯＲまたはコンテナレベルにおいてアクセス制御機構でオーバーレイされ得る。これらのアクセス制御機構は、有利になる目的で、限定はしないが、アクセス制御ポリシー、所有権要件、および／またはＤＲＭ機構を含み得る。アクセス制御の大部分は、モジュールが記憶され得るＮｕｔコンテナのプロパティから生ずることがある。本開示がさらに詳細に説明されるにつれて、それは、これらのＭＩＯＲ要求が導出され得る機構に関して明瞭にされ得る。データファイルまたはそれのコンテンツがセキュアなＮｕｔコンテナ内にカプセル化され得るとき、Ｎｕｔのコンテンツに関して利用可能なメタデータの多くのレベルがあり得、このメタデータは、限定はしないが、それを作成したアプリケーションバージョン、ディスプレイバージョン、ファイルフォーマットバージョン、サイズ、作成時間、最終修正時間、オーサー、ファイルのタイプ、および／または概要など、データフォーマットの詳細を指定し得る。限定はしないが、ＯＳバージョン、アプリケーションバージョン、ハードウェア種類および／またはバージョンなど、環境属性が、Ｎｕｔを開くアプリケーションによって与えられ得る。環境、データコンテンツおよび／または要求された演算に関するこれらのいくつかの情報を用いて、ＭＩＯＲは、適切なモジュールをルックアップし得、演算を満たすためのモジュールのセットまたはエラーメッセージのいずれかで返答し得る。これらのモジュラーＩ／Ｏモジュールは、同じマシン上の、異なるマシンにわたる、異なるチップまたはコアにわたる、ネットワークにわたる単一または別個のプロセスとして、およびコンピューティングデバイス上で（１つまたは複数の）論理プロセスを実行する他のモードとして動作し得る。これらのモジュールを通して、旧式化、係累、適応性、互換性および／またはフレキシビリティの問題が、部分的または全体的に対処され得る。
【０１９０】
Ｎｕｔ履歴
[0187]Ｎｕｔコンテナは、ペイロードの履歴を記憶するように構造化され得る。履歴の形式は、周期スナップショット、漸進的デルタ、完全イベントシーケンス、またはその３つの任意の組合せ、あるいは任意の他のアーカイブ方法を備え得る。履歴の形式は、記憶されているデータのタイプと、アプリケーションおよび／またはデータの選好および設計とに応じて変動し得る。ＮＵＴＳエコシステムは、データ履歴アーカイブのこれらのモードをサポートするための方法およびシステムを含み得る。アーカイブのこれらの３つの方法は、当業者に知られているよく確立された方法であり得る。Ｎｕｔ履歴の物理的ロケーションは、Ｔａｌｅ（図８１）と呼ばれるＮｕｔパートにあり得、それの不透明度はＮｕｔ  ＲＡＴによって制御され得る。
【０１９１】
[0188]図１１１は、簡略化されたＮｕｔ概略図を示し、その図は、ドキュメントの２つの編集セッションをカバーする、３つの時点にわたるそれの履歴構造の漸進的変更を示す。時間Ｔ１において、Ｎｕｔ１１１０２はデータＤ１  １１１１０を保持し得、それの履歴は空であり得る１１１１２。ユーザは、時間Ｔ２においてデータＤ１  １１１１０を編集し得１１１２６、新しいバージョンＤ２  １１１１４を生成し得る。アプリケーションは、スナップショットアーカイブ方法を採用し得、データＤ１のオリジナルバージョン１１１１０を、Ｎｕｔの履歴セクション１１１１６中の時間Ｔ１におけるデータのスナップショット１１１１８として記憶し得る。その後、ユーザは、時間Ｔ３においてデータＤ２  １１１１４を編集し得１１１２８、新しいバージョンＤ３  １１１２０を生成し得る。アプリケーションは、スナップショットアーカイブ方法を採用し得、データＤ２のより古いバージョン１１１１４を、Ｎｕｔの履歴セクション１１１２２中の時間Ｔ２におけるデータのスナップショット１１１２４として記憶し得る。時間Ｔ３において、履歴セクション１１１２２は、今度は、データＤ３の前のバージョン１１１２０の２つの異なったスナップショット１１１１８および１１１２４を保持し得る。Ｎｕｔの履歴１１１２２は、任意の時間に単純な履歴抽出方法を使用して随意にユーザによってブラウズおよび抽出され、リバージョン（reversion）を可能にするか、またはそれらから完全に新しいドキュメントを作成し得る。手元でデータについての妥当な履歴増大を設定するために、履歴セクションのタイプ、頻度および／または寿命を制御し得るＮｕｔメタデータパラメータがあり得る。いくつかのテキストドキュメントでは、一部または全部の変更を永遠にセーブすることは、アーカイブのデルタ方法を使用するとき、それのサイズが比較的小さいことがあるので、実際的であり得る。これは、Ｎｕｔが、その後任意の時間に、ドキュメントの一部または全部のセーブされたバージョンを生成することを可能にし得る。バイナリドキュメントは、アプリケーションに応じてスナップショットまたはデルタとしてアーカイブされ得る。いくつかのイベント駆動型アプリケーションは、それの履歴としてイベントシーケンスの完全セットをアーカイブし得る。Ｎｕｔ履歴がＮｕｔ自体内にアーカイブされ得、外部プログラムおよび／またはストレージシステムに依存しないことがあることに留意されたい。ＮＵＴＳ環境においてペイロードタイプのために利用可能なアーカイバル方法であり得る限り、ペイロードは、このようにして履歴的にアーカイブされ得る。
【０１９２】
Ｎｕｔログ
[0189]Ｎｕｔコンテナは、Ｎｕｔのイベントログを記憶するように構造化され得る。コンピュータプロセスがＮｕｔを読み取り、操作し、および／または書き込み得るとき、それらは、Ｎｕｔに対して行われた論理演算の監査証跡を発生し、それをＮｕｔ自体内に残し得る。監査証跡は、本質的に、オブジェクトの観点からオブジェクトごとに存在し得る。したがって、Ｎｕｔ履歴とＮｕｔログとの間に、データオブジェクト上での初めからのイベントのクロニクルが、後でのさらなるレビューのために単一のコンテナに記憶され得る。Ｎｕｔアーカイブの精度、コンテンツおよび／またはグラニュラリティは、Ｎｕｔに対して演算するアプリケーションの開発者によるこれらの特徴の規律正しい体系的な使用法に依存し得る。Ｎｕｔログの物理的ロケーションは、Ｖｉｔａ（図８１）と呼ばれるＮｕｔパートにあり得、それの不透明度はＮｕｔ  ＲＡＴによって制御され得る。
【０１９３】
[0190]図１１２は、簡略化されたＮｕｔ概略図を示し、その図は、Ｎｕｔ上で起こる２つのイベントをカバーする、３つの時点にわたるそれのイベントログ構造の漸進的変更を示す。この例は、Ｎｕｔ履歴についての図１１１からのシナリオを続け得る。時間Ｔ１において、Ｎｕｔ１１１０２はデータＤ１  １１１１０を保持し得、それのログ１１２１２は、Ｎｕｔ１１１０２が時間Ｔ１において作成されたことを示し得る、イベントＥ１のための１つのログエントリ１１２１８を保持し得る。ユーザは、時間Ｔ２においてデータＤ１を編集し得１１２２６、これは、Ｎｕｔ１１１０４においてデータＤ２の新しいバージョン１１１１４を作成し得る。編集アプリケーションは、要素１１２２２によって示され得るように、Ｔ２におけるイベントログエントリをＮｕｔログ１１２１６にロギングし得る。その後、ユーザは、時間Ｔ３においてデータＤ２  １１１１４を編集し得１１２２８、新しいバージョンＤ３  １１１２０を生成し得る。編集アプリケーションは、要素１１２２４によって示され得るように、Ｔ３におけるイベントログエントリをＮｕｔログ１１２３０にロギングし得る。時間Ｔ３において、ログセクション１１２３０は、今度は、３つの異なったイベントログエントリ１１２１８、１１２２２および１１２２４を保持し得る。Ｎｕｔのログ１１２３０は、任意の時間に単純なログ抽出方法を使用して随意にユーザによってブラウズおよび抽出され得、これは、Ｎｕｔに対する監査を可能にし得る。Ｎｕｔについての妥当で適切なログ増大を設定するために、ログセクションのタイプ、頻度および／または寿命を制御するためのＮｕｔメタデータパラメータがあり得る。
【０１９４】
[0191]システムアドミニストレータおよびアプリケーション開発者は、彼らが、一部または全部の、原因となるアプリケーションのイベントログを（彼らが仮にこれらへのアクセスを有することがある場合）調べなければならないことがあり、当該のオブジェクトに関係するイベントログエントリをフィルタ除去し、次いで、場合によっては、イベントがオブジェクト上で生じていたことがあるシーケンスにおいて手動でそれらのイベントを再構築し得るので、２つ以上のアプリケーションがデータオブジェクトを修正することに関与し得るとき、彼らのシステム上のバグおよびエラーを見つけ出すことに関与し得る作業および労力を知り得る。Ｎｕｔログを使用すると、この、イベントログを集めることとフィルタ処理と再構築とは、オブジェクトの観点からオブジェクトレベルにおいてすでに行われていることがある。さらに、Ｎｕｔのメタデータは、作業アプリケーションに対して、オブジェクト所有者によって望まれ得るイベントログメッセージ詳細のグラニュラリティのレベルを指定し得る。このグラニュラリティは、様々な調査方針を見つけ出すために簡潔なデバッグレベルからの詳細なデバッグレベルに及び得る。機密性が高い極秘ペイロードは、それのアクセス履歴に対して監査証跡を実施するために、最もグラニュラリティの細かい（granular）レベルのイベントログ詳細を要求し得る。要するに、これは、オブジェクトによって要請されるグラニュラリティレベルに従ってオブジェクトごとに任意のアプリケーションによって前記オブジェクトの監査可能な過去を制御する無矛盾でカスタマイズされた方法であり得る。無矛盾なという用語は、利用可能なロギング特徴の無矛盾な設計および動作を指し得、カスタマイズされたという用語は、設計が適応し得るオブジェクトごとの選好を指し得る。
【０１９５】
関係ベース鍵（ＲＢＫ）
[0192]関係ベース鍵（ＲＢＫ）がどのように確立され得るかの説明は、手動で暗号化ツールを使用していることがある誰にとっても聞き覚えがあるものであるべきであり、すなわち、ボブおよびアリスが非公開で通信することを希望し得、したがって、ボブおよびアリスは、ランダムに発生された非対称サイファ鍵（公開パートのみ）を互いにトレードし得、それを、サイファ化されたメッセージおよびドキュメントを交換するためにＰＧＰなどのツールまたはそれの等価物において使用し得る。ボブおよびアリスによる鍵ペアの保護および管理は、完全にボブおよびアリスに委ねられ得る。これは、各関係が確立され、維持され、適切に利用されるための慎重で面倒なタスクになる傾向があり得、場合によっては、アリスおよびボブが、サイファ、それらの適切な使用法、および／または鍵の保護に関する入門書（primer）または２つを有することを要求し得る。このタイプの鍵交換（key exchange）は、集中型ディレクトリまたは信頼の輪を介して、ボブまたはアリスのいずれも、確立された公開鍵証明書を有しないときに行われ得る。それは、完全に非公開の通信チャネルを作成することによって、プライバシーの追加レイヤが要求され得るといずれかの参加者が感じる場合にも起こり得る。
【０１９６】
[0193]ＲＢＫがアリスおよびボブのような人々のためのデフォルト通信方法であった場合、何が起こり得るか？どんな帰結になり得るか、および痛みを伴わないやり方でそれを起こすために何が必要とされ得るか？ＲＢＫの確立、維持および／または使用法の系統的な態様は、自動化され得る。それがどのように系統的に達成され得るかの詳細を調べるより前にＲＢＫの無矛盾な適用のプロパティおよび帰結のうちのいくつかを検討することは、建設的であり得る。  
関係ベース鍵の特性  
●  ２つの当事者間の信頼レベルは、動的調整可能パラメータであり得る。これは、任意の２つの当事者間の実生活関係の観測であり得、信頼は相対的であり得る。それは、イベントおよび通信に基づいて経時的に盛衰し得る。  
●  信頼レベルの単方向調整。関係があるいずれかの当事者が、他方の当事者に知らせてまたは知らせずに、随意に関係の当事者の信頼レベルを単方向に変更し得る。  
●  関係チャネル健全性（health）は、メッセージコンテキストから決定され得る。システムおよび鍵は、誰についても時々危殆化され得る。ＲＢＫのデフォルト使用法は、いずれかの当事者が通信のコンテンツを検査することを可能にし得、他方の人のシステムまたは鍵が危殆化されたことの見込みを決定し得る。最も単純な場合には、ＲＢＫサイファ化なしにボブから来るメッセージは、場合によっては、危殆化されることのサインであり得る。  
●  関係の真の性質は、経時的に査定され得る。異常な性質のメッセージがＲＢＫを介して送信され、送信側当事者の鍵が危殆化されていないことがある場合、送信側当事者は、関係の性質を変更していることがある。  
●  関係を失うことは永続的であり得、関係の一部または全部の履歴は、商業的および／または有意味な価値を失い得る。単方向に、いずれかの当事者が、それのメッセージをブロックすることまたはそれらのＲＢＫセットを消去することによって、関係を断ち得る。関係チャネルのこの論理演算は、各ユーザに決定論的単方向メッセージブロッキングアビリティを提示し得る。  
●  当事者は、相互に従う義務のある基本原則または関係を失うリスク、すなわち、経時的に変動し得る基本原則に厳密に従い得る。暗黙的基本原則の違反は、デジタル的に言えば、永続的なやり方で関係を単方向に断つことを生じ得る。  
●  それは、デジタル暗号形式での実世界関係のより綿密な表現を可能にし得る。それの最も広く使用されている形式での公開鍵暗号は、人々がどのように関係を形成するかに反し得る集中型モデルであり得る。ＲＢＫは非集中型であり得、非公開のやり方で公開鍵暗号を使用し得る。  
●  転覆（subversion）の隔離。ボブの環境上のＲＢＫの転覆は、ボブと、ボブが確立していることがある、ボブの連絡先、すなわちアリスとのＲＢＫチャネルとに対して隔離され得る。アリスの環境への被害は、アリスのボブとのチャネルと、彼らの相互履歴コミュニケとに対して隔離され得る。アリスのための一部または全部の他の関係チャネルは、セキュアであり得、ボブの環境を転覆させた（subvert）ハッカーによって突破されないことがある。
【０１９７】
[0194]個人情報マネージャまたはＰＩＭは、コンピュータソフトウェアにおけるよく知られているアプリケーション概念であり得る。それは、個人の使用のための生産性および編成ツールを与え得る様々な機能の合成物（amalgam）として広く定義され得る。ＰＩＭは、限定はしないが、カレンダー、アドレス帳、連絡先管理、パスワードキーパー、メモ、電子メールマネージャ、チャット機能、プロジェクト管理、鍵マネージャ、計算器、タスクリストおよび／またはアクティビティロガーのようなツールを提供し得る。ＰＩＭは、これらの機能のうちのいずれかの組合せであり得るか、または、それは、ただ単一の機能を提供し得る。ＰＩＭは、隔離された様式で、またはＰＩＭウェブサーバのみにおいて、あるいはそれらの任意の組合せでローカルに動作するように設計され得る。以降の説明では、アドレス帳またはチャットまたは電子メールマネージャなど、ＰＩＭのそのような機能への参照は、ＰＩＭの提供するものの一部としてそれらの機能のうちのいずれかを提供するＰＩＭであると理解され得るか、または、それはＰＩＭの唯一の機能であり得る。
【０１９８】
[0195]図１１３は、アリスとボブとの間のデジタルアドレス帳エントリが、アドレス帳中の一部または全部の関係について無矛盾な様式でＲＢＫをサポートするために、どのように構造化され得るかを示す。アリスのＰＩＭによって提供される機能であり得るアリスのアドレス帳１１３１０は、２つのエントリ、すなわち、アリス自身のためのエントリ１１３２０およびボブの情報のためのエントリ１１３３０を有し得る。アリス自身のエントリ１１３２０中に、アリスは、アリス自身の基本連絡先データ１１３２２と何らかの個人データ１１３２４とをリストしていることがある。アリスのアドレス帳エントリ１１３２０は、アリスのシステム上のＮｕｔファイルにペイロードとして記憶され得、セキュアにされ得る。ボブの連絡先カード１１３３０上に、アリスは、ボブの名前および電子メールアドレスなど、ボブについての何らかの連絡先情報１１３３２を有し得る。ボブのアドレス帳エントリ１１３３０は、アリスのシステム上のＮｕｔファイルにペイロードとして記憶され得、セキュアにされ得る。ボブのＰＩＭによって提供される機能であり得るボブのアドレス帳１１３５０は、２つのエントリ、すなわち、ボブ自身のためのエントリ１１３６０およびアリスの情報のためのエントリ１１３７０を有し得る。ボブ自身のエントリ１１３６０中に、ボブは、ボブ自身の基本連絡先データ１１３５２と何らかの個人データ１１３５４とをリストしていることがある。ボブのアドレス帳エントリ１１３６０は、ボブのシステム上のＮｕｔファイルにペイロードとして記憶され得、セキュアにされ得る。アリスの連絡先カード１１３７０上に、ボブは、アリスの名前および電子メールアドレスなど、アリスについての何らかの連絡先情報１１３７２を有し得る。アリスのアドレス帳エントリ１１３７０は、ボブのシステム上のＮｕｔファイルにペイロードとして記憶され得、セキュアにされ得る。アリスおよびボブが互いにＲＢＫをセットアップすることを決定したとき、アリスおよびボブは、彼ら自身の間の非公開双方向通信チャネルをセットアップすることを決定し得る。アリスは、非対称鍵ペア１１３３４および１１３３６を発生し、それらをボブのアドレスカード１１３３０下に記憶し、鍵１１３３４の公開部分をボブに送信すること１１３４４によってプロセスを始め得る。送信プロセス１１３４４は、パスフレーズでセキュアにされたＮｕｔ、紙に書き込まれたメッセージ、ボブへの電話、世界に知られているボブの公開鍵を使用したメッセージ、または当業者によく知られている任意のバージョンのセキュアな鍵交換プロトコルによって達成され得る。ボブが内部の鍵１１３３４とともにこのメッセージを受信したとき、ボブは、それを、メッセージを非公開でアリスに送るための鍵１１３３４としてアリスのアドレスカードエントリ１１３７０に記憶し得る。ボブは、次いで、非対称鍵ペア１１３７４および１１３７６を発生し、それらをアリスのアドレスカード１１３７０下に記憶し、メッセージを暗号化するために、アリスがボブに送った公開鍵１１３３４を使用して鍵１１３７４の公開部分をアリスに送信し得る１１３４６。アリスがこのメッセージを受信したとき、アリスは、ボブのメッセージのためのアリスの非公開鍵１１３３６を使用してボブからのメッセージを解読し得る。アリスは内部の鍵１１３７４を抽出し得、アリスは、それを、メッセージを非公開でボブに送るための鍵１１３７４としてボブのアドレスカードエントリ１１３３０に記憶し得る。アリスは、カード１１３３０から鍵１１３７４で暗号化されたボブのための確認メッセージを作成し得、それを任意の作業通信媒体を通してボブに送り得る。ボブはメッセージを受信し得、次いで、ボブは、それをカード１１３７０からの鍵１１３７６を用いて解読し得、ボブのＲＢＫセットを、アリスに関して確立され、アクティブであるとマークし得る。
【０１９９】
[0196]アリスとボブとの間のこのＲＢＫセットアップにおけるステップは、自動化され得、単一のアクションボタンまたはコマンドを用いて始動され得る。これは、ＮＵＴｂｏｏｋがそれの連絡先コレクションをどのように管理するかの動作基礎であり得、本明細書の後のＮＵＴｂｏｏｋセクションにおいて説明され得る。プロセスは、ボブまたはアリスのいずれかによって、ボブまたはアリスのＰＩＭにおいてボブまたはアリスのそれぞれのアドレス帳中の一部または全部の連絡先カードについて独立して繰り返され得る。最後に、各人は、各人の関係の各々のための非公開通信チャネルと見なされ得る、各人の連絡先の各々のためのＲＢＫチャネルを確立し得る。キャシーがアリスとボブとの間の共通の友人である場合、キャシーのボブとのＲＢＫ関係は、キャシーのアリスとのＲＢＫ関係とは異なり得、ＲＢＫ構成は、その現実を反映し得る。
【０２００】
[0197]今やＲＢＫと、それの系統的な使用のコンテキストとを定義していることがあるので、それはアリスまたはボブのために何を行い得るか？２つのエンティティ間でメッセージを送るためのＲＢＫの無矛盾な使用は、それらの通信チャネルの健全性のモニタリングを可能にし得る。実際的使用の一例は、スパム電子メールの低減であり得る。著しい量のグローバルインターネット帯域幅およびデータストレージが、悪意のある類いおよび／または商業的類いの両方によるスパム電子メールによって占められ得ることが推定され得る。思い切って、そのような量のスパムを歓迎し得る人々は多くないと仮定してもよい。スパムの低減の通常の方法のうちのいくつかは、コンテンツパターン認識、ドメイン例外、アドレス例外に基づくフィルタ処理技術を使用すること、および／または、大量に発信する（prolific）スパムサーバを法執行によって実際に停止させることによるものであり得る。ＲＢＫ暗号化が、通信するデフォルトのやり方であり得るモードでは、スパムは、より決定論的なやり方で検出され得る。
【０２０１】
[0198]ＲＢＫなど、プロセスを自動化するやり方における主な障害物のうちの１つは、ユーザフレンドリーな、ユーザアクセス可能な、および／またはユーザ制御可能な個人公開鍵インフラストラクチャ（ＰＫＩ）アプリケーションの著しい欠如であることがある。ＮＵＴｂｏｏｋは、Ｎｕｔの使用法とともに、ＰＫＩギャップを埋めることを試み得る。それは、シームレスなやり方でそのような情報を記憶し、操作し、およびそれにアクセスするためのフレキシブルな、セキュアな、および／またはユーザ制御可能な方法を提供し得る。
【０２０２】
[0199]図１１４は、ＲＢＫ通信チャネルを今や確立していることがあるアリスとボブとの間のスパムを低減するためのフローチャートを示し、それは、アリスおよびボブの、通信するデフォルト方法であり得、アリスおよびボブは、よく知られている公開電子メールアドレスを使用中であることがある。電子メールがアリスとボブとの間のＲＢＫを介して暗号化された場合、それは、おそらく、アリスからボブへのまたはその逆の有効な電子メールであり得る１１４１４。いずれかの人が、ＲＢＫで暗号化されていない他方からの電子メールを受信した場合、それは、たいがいスパムであり得、フィルタ除去され得、スパムごみ箱に記憶され得る１１４１２。
【０２０３】
[0200]図１１５は、ＲＢＫ通信チャネルを今や確立していることがあるアリスとボブとの間のスパムを低減するためのフローチャートを示し、それは、アリスおよびボブの、通信するデフォルト方法であり得、アリスおよびボブは、公にされていない非公開電子メールアドレス、すなわち、匿名電子メールアドレスを使用中であることがある。電子メールがアリスとボブとの間のＲＢＫを介して暗号化された場合、それは、おそらく、アリスからボブへのまたはその逆の有効な電子メールであり得る１１５１４。いずれかの人が、ＲＢＫで暗号化されていない他方からの電子メールを受信した場合、それは、たいがいスパムであり得、フィルタ除去され得、スパムごみ箱に記憶され得る１１５１２。この例は、ＲＢＫ暗号化されたメッセージを互いに送り、したがってＲＢＫチャネル概念を電子メールアドレスレベルにも拡大するために、非公開電子メールアドレスのセットがアリスとボブとの間でのみ使用され得ると仮定していることがある。このタイプの通信チャネル指向電子メールアドレスを匿名電子メールアドレスとして定義し得る。
【０２０４】
[0201]匿名電子メールアドレスを介してＲＢＫを矛盾なく使用し得るアリスとボブとの間の通信チャネルは、関係自体の健全性を決定するために分析され得るいくつかの特性を呈し得る。図１１５において説明され得るように、一部または全部の暗号化されていないスパムメッセージを、デフォルトでチャネルからすでに除去していることがある。次に、適切なＲＢＫ暗号化されたメッセージのコンテキストを検査し得る。図１１６中の表は、アリス−ボブ通信チャネルの健全性の決定論的コンテキストベースステータス行列をリストする。それは、アリスとボブの関係に何が起こっていることがあるかを解明するために、アリスによるコンテンツの定性的査定を要求し得る。これは、アリスへのボブのメッセージによって証明され得るように、ボブの挙動に基づき得る、アリスによる単方向アクション行列を示す。
【０２０５】
[0202]図１１６にリストされている最後の症状は、ボブのロールがウェブベンダーによって置換され得るときの興味深いシナリオを提起し得、すなわち、アリスは、ベンダーとの匿名ＲＢＫ通信チャネルを確立していることがある。図１１７中の表は、アリス−ベンダー通信チャネルの健全性の決定論的コンテキストベースステータス行列を示す。今や、アリスは、このベンダーが、匿名電子メールアドレスとＲＢＫセットとのチャネル識別可能な態様を通して、アリスの情報をスパマーに販売していることがあるかどうかを見つけ出すアビリティを有し得る。それは、明瞭な監査証跡とともに、ベンダーのマーケティング部門の内部作業へのあるレベルの透明性を与え得る。このタイプのベンダー説明責任は、平均的ユーザによるそのような系統的に詳細なやり方において前例がないことがある。ベンダーによる、アリスの信頼を踏みにじることに対する帰結は、ベンダーがアリスに接触するための手段を永遠に失い得るので、悲惨であり得る。事実上、匿名電子メールアドレスおよび／またはＲＢＫの適切で無矛盾な使用法は、アリスのデジタル等価物がストアから出て決して戻らないことを可能にし得、これは、ベンダーがベンダーのクライアントの個人情報を悪用しないための抑止力として役立ち得る。
【０２０６】
[0203]図１１８は、ベンダーの視点からのアリス−ベンダー通信チャネルの健全性の決定論的コンテキストベースステータス行列を示す。チャネル特性は、ベンダーのビジネスを保護し、場合によってはベンダーのクライアントを保護するためにベンダーがとり得る同じタイプの単方向アクションをベンダーに与え得る。ベンダーによるこの方法論の使用は、場合によっては、プライバシーおよびデータセキュリティについてのベンダーの評判を向上させ得る。それはまた、クライアントデータを大規模に無差別に再販売することにベンダーが関わらないことがあることを暗黙的に述べ得る。
【０２０７】
[0204]図１１９は、ＲＢＫの使用が、ユーザのシステム上で機密データの危殆化を隔離するのをどのように助け得るかのグラフィック表現を示す。ボブ１１９００は、アリス１１９１０とのＲＢＫチャネルとデイブ１１９２０とのＲＢＫチャネルとを有し得る。ボブは、トロイの木馬ウェブサイトをクリックしていることがあり、鍵ロガーまたは等価な悪意のあるプログラムに感染していることがあり、その後、ハッカーが、ボブのＮＵＴｂｏｏｋなど、ＲＢＫのためのボブのセキュアなデータストアに侵入することが可能であることがある。その結果、一部または全部のボブの連絡先をもつボブのＲＢＫセットが危殆化されていることがある１１９００。ボブは一部または全部のボブの友人に接触し得、ボブはこの突破を友人に通知し得るか、あるいは、ボブの友人のうちの何人かは、ボブとの友人の非公開チャネルを使用して友人に送られていたことがあるスパムメッセージから、ボブまたはボブのシステムに何か異常があったとすでに推論していることがある。アリスが一部または全部のアリスのＲＢＫセットを記憶し得るアリスのＮＵＴｂｏｏｋ１１９１０を見る場合、アリスは、ボブとのアリスのＲＢＫセット１１９１２を、危殆化されたものとしてマークし得、ボブがボブのシステム上のウイルスを除去するための準備を整えたときはいつでも、新しいＲＢＫセットを発生し得る。それが、アリスへの被害の程度であり得、それは、アリスが確立していることがある他のＲＢＫ関係に拡散しない。これは、アリスが同様にアリスの連絡先とともに匿名電子メールアドレスを矛盾なく使用した場合、特に当てはまり得る。アリスはハッカーからスパムを受信し得るが、スパムは、アリスがチャネルを危殆化されたかまたは削除されたものとしてマークするとき、自動的に無視され得る。ボブが準備ができていることがあるとき、アリスは、ＲＢＫの新しいセットと新しい匿名電子メールチャネルとを発生し得、ボブおよびアリスは、非公開で彼らのデジタルダイアログを続け得る。デイブのためのプロセスは、デイブのＲＢＫストア１１９２０について同じであり得る。
【０２０８】
匿名関係
[0205]ここ数十年間でインターネット上で起こり、固まっていることがあるデジタル関係トポロジーおよびコンベンションは、不自然で非現実的であり得る。匿名性は、強力な関係構成体であり得、限定はしないが、個人的製品を買うためにドラッグストアに行くこと、食事を買うためにレストランに行くこと、乗るために営業許可のあるタクシー（medallion cab）を呼び止めること、および／または抗議集会に現れることなど、たいていのその場限りの対話を伴って毎日享受し得るレベルの関係であり得る。この物理的現実に反して、インターネット上のほとんどあらゆるベンダーは、ベンダーがアリスから得ることがある一部または全部の個人情報を含む、アリスが誰であり得るかを正確に知ることを希望し得る。多くのベンダー自身が、直通電話番号を公開しないことによって比較的匿名のままであり得、電子メール、トランザクションシステム、および／またはリモートコールセンターにおけるリモートでアウトソーシングされた顧客サービス担当者を通して顧客にサービスし得る。匿名性の最も普及した使用は、ハッカーなど、隠れることを希望し得る人々によるものであり得る。現在、インターネット上で匿名のままでいることを希望し得る人々のための多くの偽人格発生ウェブサイトがあり得るが、それらは、極めて面倒な様式で匿名性を追跡しなければならないことがあり、意図的に二面性をもつために用心深い決定を行わなければならないことがある。ＲＢＫおよび匿名電子メールアドレスの使用は、平均的ユーザのためにインターネット上の匿名性のこの不平衡にいくらかの平衡をもたらし得、それらのユーザが、偽人格およびその場限りの二面性に頼る必要なしにベンダーおよび互いとのより有意味な双方向関係を有することを可能にし得る。
【０２０９】
[0206]図１２０は、事前パッケージ化された個人データＮｕｔの簡略図を示す。Ｎｕｔは、人に関する詳細な個人情報１２０００を記憶し得る。それは、異なる目的のためのこの個人情報の異なるサブセットの事前パッケージ化を自動化し得る。１２０１０は、ただ名前および電子メールアドレスを含んでいることがある、単純な個人データＮｕｔであり得る。匿名個人データＮｕｔ１２０２０は、代替電子メールアドレスのみを示し得る。ショッピング個人データＮｕｔ１２０３０は、品物を購入するためのショッピングウェブサイトのために一般に必要とされる情報フィールドを含み得る。マスタ情報１２０００からのこれらのデータサブセットの生成は、単純なルールおよびフィルタを介して行われ得、インターネット上の登録プロセス中に要請に応じて生成され得る。ベンダーまたはサービスがデータＮｕｔを受け付け得るかどうかにかかわらず、情報は、他の手段によって必要とされるとき、正しいフィールドへの挿入のために利用可能にされ得る。ユーザが匿名電子メールサービス（前方参照）を利用する場合、１２０２０のようなデータＮｕｔは、確立されている特定の関係のための動的に作成された匿名電子メールアドレスを提供し得る。
【０２１０】
[0207]図１２１は、Ｎｕｔを使用し得る自動化された登録プロセスにおけるイベントのシーケンスをチャートで示す。インターネット上のベンダーは、個人データＮｕｔを使用し、受け付け得、それの顧客とのＲＢＫチャネルが自動で確立されることを可能にし得る。ユーザは、ベンダーのウェブサイトを訪問し得、登録することを希望し得る１２１００。ユーザは、ベンダーのウェブサイトに自動的に登録するようにユーザのＮＵＴｂｏｏｋに命令することによってプロセスを開始し得、登録サイトのＵＲＬを入力し得る。ＮＵＴｂｏｏｋは、ユーザに登録してもらうためにベンダーが必要とし得る情報をフェッチするためにベンダーに照会し得る１２１０２。ＮＵＴｂｏｏｋは、ベンダーが要求中であることがあるユーザの個人情報のサブセットを構成し得、ユーザにプレビューを示し得る。ユーザは、登録のために要求された情報が許容でき得ることと、ＮＵＴｂｏｏｋが関連情報を集めていることがあり、プロセスを続け得ることとを決定し得る１２１０４。ＮＵＴｂｏｏｋは、プレビューされた情報を含んでいる事前パッケージ化されたＮｕｔを抽出し得、作成し得、それをベンダーのサイトに送り得る。ベンダーは、登録要求を受け付け得、事前パッケージ化されたＮｕｔにおいて指定されたユーザの電子メールアドレスに照会を送り得る１２１０６。ユーザは、ｃａｐｔｃｈａを入力するか１２１０８または他の形式の可能な検証を入力するために特定のＵＲＬに進むようにユーザに依頼することによって、ユーザが、分別のない登録に関わっていることがあるウェブボットでないことがあるという証拠を与えるようにユーザに依頼する、ベンダーの照会をユーザの電子メール上で受信し得る。ｃａｐｔｃｈａが成功裡に入力されると、ベンダーは、要求が人からであり得ることに満足し得、自動発生されたログイン証明、ログイン鍵および／またはＲＢＫセットをユーザとともに確立することに進み得る。ユーザのＮＵＴｂｏｏｋは、ベンダーのためのエントリカード、それの関連ウェブ情報、ログイン証明、ログイン鍵および／またはＲＢＫセットを自動的に作成し得る１２１１２。登録プロセスは、プロセスにおける数個のポイント、すなわち、始動、個人データパッケージレビュー／編集、および／または人間検証において、ユーザが対話することで行われ得る。ログイン名、パスワードを選ぶ、個人情報をタイピングする、および／またはベンダーのためのパスワードキーパーにおけるエントリを作成するというわずらわしい事は、必要とされないことがあり、自動化されていることがある。ユーザのＮＵＴｂｏｏｋがアクティブにされたとき、ユーザは、ＮＵＴｂｏｏｋが、そうするように命じられたときにユーザを自動的にログインさせ得るので、シームレスに、完全に認証されたモードでのベンダーへの瞬時アクセスを有し得る。このプロセスは、ユーザとベンダーの両方の考えられる利益のために任意のベンダーがこの方法論を採用することで行われ得ることに留意されたい。ユーザおよびベンダーのためのわずらわしい事が少なくなることにより、ユーザおよびベンダーのデータベースについてのユーザからのより正確な情報と、場合によっては、ユーザとベンダーとの間のより多くのトランザクションの可能性とを得ることがある。
【０２１１】
[0208]図１２２は、Ｎｕｔと匿名電子メールアドレスとを使用する自動化された登録プロセスにおけるイベントのシーケンスをチャートで示す。インターネット上のベンダーは、Ｎｕｔを使用し得、受け付け得、それの顧客とのＲＢＫチャネルが、匿名電子メールアドレスを使用して自動で確立されることを可能にし得る。ユーザは、ベンダーのウェブサイトを訪問し得、登録することを希望し得る１２２００。ユーザは、ベンダーのウェブサイトに自動的に登録するようにユーザのＮＵＴｂｏｏｋに命令することによってプロセスを開始し得、登録サイトのＵＲＬを入力し得る。ＮＵＴｂｏｏｋは、ユーザに登録してもらうためにベンダーが必要とし得る情報をフェッチするためにベンダーに照会し得る１２２０２。ベンダーは匿名登録を受け付け得、したがって、ＮＵＴｂｏｏｋは、ＮＵＴｍａｉｌサービスに接触し得、ユーザのアカウント下で匿名電子メールアドレスのペアを要求し得る。ＮＵＴｂｏｏｋは、新たに作成された匿名電子メールアドレスを含み得る、ベンダー登録に送られるべきデータのプレビューを構成し得、示し得る。ユーザは、登録のために要求された情報が許容でき得ることと、ＮＵＴｂｏｏｋがプロセスを続け得ることとを決定し得る１２２０４。ＮＵＴｂｏｏｋは、プレビューされた情報を含んでいる事前パッケージ化されたＮｕｔを作成し得、それをベンダーのサイトに送り得る。ベンダーは、登録要求を受け付け得、事前パッケージ化されたＮｕｔにおいて指定されたユーザの新しい匿名電子メールアドレスに照会を送り得る１２２０６。ユーザは、ｃａｐｔｃｈａを入力するか１２２０８または他の形式の可能な検証を入力するために特定のＵＲＬに進むようにユーザに依頼することによって、ユーザが、分別のない登録に関わっていることがあるウェブボットでないことがあるという証拠を与えるようにユーザに依頼する、ベンダーの照会をユーザの匿名電子メールアドレス上で受信し得る。ｃａｐｔｃｈａが成功裡に入力されると、ベンダーは、要求が人からであり得ることに満足し得、自動発生されたログイン証明、ログイン鍵および／またはＲＢＫセットをユーザとともに確立することに進み得る。ユーザのＮＵＴｂｏｏｋは、ベンダーのためのエントリカード、それの関連ウェブ情報、ログイン証明、ログイン鍵、匿名電子メールアドレスおよび／またはＲＢＫセットを自動的に作成し得る１２２１２。登録プロセスは、プロセスにおける数個のポイント、すなわち、始動、個人データパッケージレビュー／編集、および／または人間検証において、ユーザが対話することで行われ得る。ログイン名、パスワードを選ぶ、個人情報をタイピングする、電子メールアドレスを作成する、および／またはベンダーのためのパスワードキーパーにおける新しいエントリを作成するというわずらわしい事は、必要とされないことがあり、自動化されていることがある。ユーザのＮＵＴｂｏｏｋがアクティブにされたとき、ユーザは、ＮＵＴｂｏｏｋが、そうするように命じられたときにユーザを自動的にログインさせ得るので、完全に認証されたモードでのベンダーへのシームレスアクセスを有し得る。このプロセスは、個人ユーザ情報を必要としないことがあり、作成されていることがある電子メールアドレスは、特にこの関係のためのものであり、これは、ユーザとベンダーとの間の関連する電子メールのみがこれらの匿名電子メールアドレスに到着し得ることを暗示する。様々なＮＵＴベースサービスが後で説明され得るように、それらの一部または全部が匿名登録を提供する。
【０２１２】
[0209]ＲＢＫと匿名電子メールアドレスとを使用して確立され得る通信チャネルは、ＲＢＫを介してあらゆるものをサイファ化するそれのデフォルトモードにより、決定論的な様式でスパムを最小限に抑え得る。さらに、それは、関係に対する相互尊重およびそれの暗示された限界があり得るように、関与し得る当事者にチャネルの双方向制御を与え得る。これらの暗示された関係境界からの逸脱は、関係変更イベントを特定し得、調査から関係を決定論的なやり方で完全に断つことに及ぶ、単方向反応を招き得る。サードパーティがボブまたはアリスのデータを転覆させることを試みることについて、匿名電子メールアドレスの正しいペアの取出し以外に、サードパーティは、同様に、サイファ化されたメッセージおよびドキュメントを分解しなければならないことがある。
【０２１３】
[0210]自動化された登録を受け付け得、処理し得るウェブサイトは、限定はしないが、年齢フィルタ処理など、追加のサービスを追加し得る。親は、限定はしないが、性別、年齢および／または概略的なロケーションなど、いくつかの一般的な識別特徴を示すために、自分達の子供のデバイスのＮＵＴｓｅｒｖｅｒ上に、事前パッケージ化されたＮｕｔを堆積させ得る。この事前パッケージ化されたＮｕｔは、Ｎｕｔを受け付け得る任意の子供向けのまたは親によって事前承認されたウェブサイト上に子供を登録するために自動的に使用され得る。ベンダーは、この情報に基づくアクセス試みと、限定はしないが、酒類のサイト、タバコのサイト、ムービープレビューのサイト、アダルトコンテンツのサイト、および／または銃のサイトなど、それらが与え得るサービスとを受け付けるかまたは拒否し得る。さらに、インターネットアクティビティロギングＮｕｔは、子供のアクティビティおよびデジタル所在をモニタするように子供のデバイスのＮＵＴｓｅｒｖｅｒ上で構成され得る。また、インターネット使用に対する制限は、デバイス切替えが日ごとの子供の累積インターネット使用状況にとって重要でなくなり得るように、自宅の一部または全部のデバイスにわたってそのようなＮｕｔを使用することによって、親によって統制され得る。いくつかのウェブサイトのブロッキング、およびそれらへのアドミッションは、デバイス自体上のそのような子供識別Ｎｕｔを使用することによって、および／またはＮＵＴＳベースＷｉＦｉルータ（前方参照）上の特定の構成設定とともに達成され得る。
【０２１４】
ＮＵＴＳコアアプリケーション
[0211]図１２３中の表は、ＮＵＴＳコアアプリケーションセットを備え得るアプリケーションをリストする。これらのアプリケーションは、ＮＵＴＳ技術を利用し得るたいていのシステム中に常駐し得、それらは、図１２４中の動作コンピューティングデバイスのこの簡略図に示されているようにＮｕｔファイルを扱い得る。前記のように、これらのアプリケーションの一部または全部は、本開示において前に説明された材料によって、すでに参照されていることがある。これらのアプリケーションは、限定はしないが、ロックノード、ロックグラフ、Ｎｕｔパート、Ｎｕｔ履歴、Ｎｕｔログ、ＭＩＯ、ＭＩＯＲ、Ｎｕｔ  ＩＤ、ＲＢＫ、勾配不透明度、および／または匿名関係など、ＮＵＴＳの一部または全部のコア基礎機能および能力へのそれらの依存性により、本開示の前において詳述され得ない。これらのコアアプリケーションの一部または全部は、通常のファイルによって具現され得るストレージの基本ユニットとしてＮｕｔを利用することを選好し得るが、それに限定されない。これは、これらのシステムが触れ、記憶し、および／または操作する一部または全部のデータが、デフォルトで高度のセキュリティおよびアクセス制御を伴い得ることを暗示し得る。リーダーがこれらのコアアプリケーションをより十分に理解するのを支援し得る、ロックノード設計において使用されていることがある設計理念は、反復、統合、独立性および／または識別可能性の概念であり得る。
【０２１５】
ＮＵＴＳコアアプリケーション：ＮＵＴｓｅｒｖｅｒ
[0212]ＮＵＴｓｅｒｖｅｒは、図１２５中のユーザデバイスの簡略図において概略的に示され得る。ＮＵＴｓｅｒｖｅｒがＮＵＴＳ互換環境を編成し、維持するためにバックグラウンドにおいて実施し得るいくつかの鍵機能があり得る。ＮＵＴｓｅｒｖｅｒ１２５１０は、ユーザコンピューティングデバイス１２５００のアプリケーションスペースにおいて動作し得る。デバイスは、Ｎｕｔファイル１２５２２が保たれ得る何らかのストレージ１２５２０を有し得る。ＮＵＴｓｅｒｖｅｒはＡＰＩを与えることを担当し得、通信チャネルは、ＮＵＴｂｏｏｋ１２５１２、ＮＵＴｂｒｏｗｓｅｒ１２５１４、および／またはデバイスＯＳを含む他のアプリケーション１２５１６を備える、様々なアプリケーションで開く。ＮＵＴｓｅｒｖｅｒは、ＮＵＴｓｅｒｖｅｒを実行中であることがあり１２５３０、場合によってはＮＵＴｃｌｏｕｄ１２５４０と会話していることがあるユーザに属し得る他のデバイスとの外部接続を維持することをも担当し得る。ＮＵＴｓｅｒｖｅｒは、ユーザデバイス１２５００のファイルシステムの代わりでないことがあり、むしろ、Ｎｕｔファイルにアクセスし、それを処理するためにローカルオペレーティングシステムおよびファイルシステムを通して働き得る。
【０２１６】
[0213]図１２６は、ＮＵＴｓｅｒｖｅｒの主要な内部パートおよびそれの機能の簡略図を示す。ユーザデバイスは、ハードウェアとソフトウェアとを管理するオペレーティングシステム１２６００を有し得る。デバイスは、ネットワークインターフェース１２６０２によってサービスされる外部通信と、ＯＳ１２６００を通して動作するそれの関連するドライバとを有し得る。デバイスは、ＯＳ１２６００によってアタッチされ得、管理され得るファイルシステム１２６０４をも有し得る。ファイルシステムにＭＩＯＲ１２６１０のためのデータストアが記憶され得、ユーザデータがＮｕｔ１２６０６および１２６０８中に含まれていることがある。ＯＳ１２６００は、図に示されたアプリケーション、すなわち、ＮＵＴｓｅｒｖｅｒ１２６２０、ＮＵＴｂｏｏｋ１２６４２、ＮＵＴｂｒｏｗｓｅｒ１２６４４、ＭＩＯＲサーバ１２６４６、および他のアプリ１２６４８を備える多くのアプリケーションが実行され得るアプリケーション環境としても働き得る。ＮＵＴｓｅｒｖｅｒ１２６４０は別のデバイス上で動作中であることがあるが、アプリケーションインターフェース１２６３６もそれらの通信を扱い得る。
【０２１７】
[0214]ＮＵＴｓｅｒｖｅｒ１２６２０内に、ＮＵＴｓｅｒｖｅｒへの認証を実施し得、鍵キャッシュを維持し得るモジュール１２６２２があり得る。ＮＵＴｓｅｒｖｅｒが開始したとき、それは、Ｎｕｔにおけるセキュアにされたレイヤをのぞき込むいかなる権限をも有しないことがある。ユーザおよび／またはハードウェアは、ＮＵＴｓｅｒｖｅｒ認証モジュール１２６２２がいくつかの鍵セットへのアクセスを獲得することを可能にし得る必要な認証を与え得る。これは、鍵セットを保持する、パスフレーズで保護されたＮｕｔを有し、パスフレーズを与えるようにユーザに依頼し、Ｎｕｔを開き、保護された／保護されていないメモリにそれのペイロード中の鍵セットをキャッシュするのと同じくらい単純であり得るか、または、それは、多くのコンピューティングデバイス中で見つけられるような、セキュアな、ハードウェアで与えられた鍵であり得るか、または、それは、限定はしないが、ユーザが与え得るＵＳＢ鍵など、ハードウェアトークンであり得る。鍵セットは、最低でも、ＮＵＴｓｅｒｖｅｒ認証鍵、および／またはローカルデバイス上にインストールされ得る各ＮＵＴＳコアアプリケーションのための鍵を含んでいることがある。編成の目的および効率のためにＮＵＴｓｅｒｖｅｒによって維持され得るキャッシュ１２６２４があり得る。キャッシュのパートは、Ｎｕｔ  ＩＤのインデックス１２６２６であり得る。このインデックスは、ユーザがローカルにおよびリモートで追跡することを希望し得る一部または全部のＮｕｔ  ＩＤを含んでいることがある。インデックス中のＮｕｔ  ＩＤをルックアップすることは、Ｎｕｔ  ＩＤがどこで見つけられ得るかを示し得る。キャッシュ１２６２４の別のパートは、頻繁にアクセスされるＮｕｔのためにメモリ中にＮｕｔキャッシュ１２６２８を保つことを求められ得る。
【０２１８】
[0215]ＮＵＴｓｅｒｖｅｒは、同じＮｕｔ  ＩＤをもつ２つまたはそれ以上のＮｕｔのコンテンツを同期させること１２６３０を担当し得る。ＮＵＴｓｅｒｖｅｒが適切に認証され得、それが、ユーザによって所有される一部または全部のＮｕｔにアクセスするのに十分な鍵を有し得ると、ＮＵＴｓｅｒｖｅｒは、Ｎｕｔのコンテンツを検査し、Ｎｕｔを管理するために様々なＮｕｔを開き得る。各Ｎｕｔは、最後の更新または修正のバージョン番号およびタイムスタンプを保持し得る。更新がＮｕｔ上で行われ、ＮＵＴｓｅｒｖｅｒがそれを通知され得るかまたはＮＵＴｓｅｒｖｅｒがそれに気づき得る場合、ＮＵＴｓｅｒｖｅｒは、その更新に言及し得、この更新されたＮｕｔのコピーがローカルにまたはリモートで存在し得る一部または全部のロケーションを見るためにインデックス１２６２６をルックアップし得る。ＮＵＴｓｅｒｖｅｒは、次いで、系統的に、影響を受けたＮｕｔの変更を伝搬し、同期させること１２６３０を始め得る。このプロセスは、限定はしないが、Ｎｕｔ  ＩＤ、バージョン番号、内部ｄｉｇｎ、履歴、および／またはログなど、各Ｎｕｔ内に埋め込まれたメタデータにより、幾分単純であり得る。様々な修正基準が満たされ得る場合、最も新しいバージョンが単に既存のバージョンを上書きし得る。ＮＵＴｓｅｒｖｅｒがＮｕｔを部分的または全体的にのぞき込むことが可能であることは必要でないことがあり、これは、それが、同期更新が行われ得るかどうかに関してＮｕｔの勾配不透明度によって可能にされ得るように閲覧可能なメタデータに依存し得るからである。十分なクリアテキストメタデータは、いくつかのＮｕｔが、当該のＮｕｔへの鍵なしでＮＵＴｓｅｒｖｅｒによって同期されることを可能にし得る。それらがバージョンフォーキング（forking）またはブランチングの可能性であり得る場合、ユーザは、どのバージョンを現在のものにすべきかを決定することに関与し得る。複製機能１２６３０は、ピアＮＵＴｓｅｒｖｅｒが、自動的にユーザ制御デバイスにわたってこれらのタイプの変更を伝搬することを可能にし得る。１２６３０によって与えられる機能は、ユーザがユーザのデバイス上に複数のＮＵＴｓｅｒｖｅｒをインストールし、接続し得るとき、ユーザのための個人ＮＵＴｃｌｏｕｄを構成し得る。ユーザは、自動化された様式でユーザのデバイスのうちのいずれかの上で、同期および／または複製されたＮｕｔを享受し得る。より複雑なバージョン問題が起こるかまたはＮｕｔのある履歴バージョンが要求され得るとき、リビジョン制御モジュール１２６３２がそれらの要求を扱い得る。リビジョン制御モジュール１２６３２は、Ｎｕｔによって採用される固有バージョンデルタ方法を利用し得、Ｎｕｔの所望のバージョンを生成するために、より細かいグラニュラリティのバージョン制御を実施し得る。これらのＮｕｔ固有バージョンデルタ方法と、Ｎｕｔのコンテンツ読取り／書込み方法とは、ローカルＭＩＯＲ中に存在することも存在しないこともあり、したがって、それらの機能をそれらが必要とされ得るときに供給するためにＭＩＯＲインターフェース１２６３４があり得る。
【０２１９】
[0216]アクセスＮｕｔは、限定はしないが、ウェブサイトログイン、データベースログイン、企業システム、個人デバイス、ソフトウェアシステム、他のＮｕｔ、ＮＵＴｓｅｒｖｅｒ、電子メールシステム、チャットシステム、ならびに／あるいは秘密パスキーおよび／またはログインＩＤを要求する任意のデジタルシステムなど、他のシステムまたはコンテナのための認証証明を含んでいることがあるセキュアにされたＮｕｔとして定義され得る。ＮＵＴｓｅｒｖｅｒは、他のアプリケーションがそれの機能にアクセスするためのアプリケーションインターフェース１２６３６を提示し得る。ＮＵＴｓｅｒｖｅｒは、それのアプリケーションタイプおよびインストール委細によって識別され得、追加として、それは、同様にＮｕｔ  ＩＤを割り当てられ得る。ユーザデバイスのためのＮＵＴＳ構成ファイルは、ファイルシステム１２６０４中の構成ディレクトリまたはエリアを指し得、ここで、それは、限定はしないがリモートおよび／またはローカルＮＵＴｓｅｒｖｅｒなど、それが知っている必要があり得る各アプリケーションについての情報を保持するアクセスＮｕｔを見つけ得る。たとえば、ローカルＮＵＴｓｅｒｖｅｒ１２６２０構成ディレクトリは、リモートＮＵＴｓｅｒｖｅｒ１２６４０のためのＮｕｔ  ＩＤ、タイプおよび／またはアクセス鍵を含んでいるアクセスＮｕｔを保持し得る。そのようなアクセスＮｕｔを成功裡に開くことは、ＮＵＴｓｅｒｖｅｒが信頼できる通信チャネルを開き、互いにＮｕｔを送り得るように、リモートＮＵＴｓｅｒｖｅｒ１２６４０に接触することを試み、それで認証するのに十分な情報をローカルＮＵＴｓｅｒｖｅｒ１２６２０に与え得る。同様の様式で、ＮＵＴｓｅｒｖｅｒがそれと対話中であることがある様々なアプリケーションのための構成Ｎｕｔがあり得る。アクセスＮｕｔはＮｕｔであるので、アクセスＮｕｔは、同期され、複製され、および／またはピアＮＵＴｓｅｒｖｅｒの間で伝搬されるように保たれ得る。
【０２２０】
[0217]ＮＵＴｓｅｒｖｅｒがどのように機能し得るかのこの説明から、Ｎｕｔ内部の反復的設計手法は、アプリケーションと、それらを構成し、認証するために関連付けられたデータとが、どのように記憶され、アクセスされ得るかに拡張し得る。機密データは、できる限りＮｕｔに記憶され得る。そのような単純なステートメントの帰結は、Ｎｕｔの組込み機能および特徴と、ＮＵＴｓｅｒｖｅｒによって与えられる機能とを考慮するとき、広範囲にわたることになる。認証されていないＮＵＴｓｅｒｖｅｒは、それが内部アクセスを有しないことがあるＮｕｔを複製し、伝搬し、および／または同期させるのに十分な機能を与え得る。これはＮｕｔの勾配不透明度プロパティに起因し得、非曝露メタデータを構成する多くのＮｕｔパートが、クリアテキストとしてセーブされ得、ＮＵＴｓｅｒｖｅｒによってＮｕｔ上で実施されるべき多くの通常の維持アクションのための十分な情報を与え得る。Ｎｕｔに組み込まれ得るセキュリティ特徴により、ＷＡＮまたはイントラネット上でアプリケーション間でＮｕｔをトランスポートするための通信チャネルのセキュリティは、あまり有意性を有しないことがある。
【０２２１】
[0218]アクセスＮｕｔを使用するこの方法は、ソフトウェア設計、プログラミングおよび／または使用に関連する多数の問題を解決し得る。たとえば、ソフトウェア開発者の悩みの種は、テストデータベースまたはテストアプリサーバなど、テストシステムへのエントリを促進するために彼らのコードを開発するプロセス中であるときに、ソフトウェア開発者がいつログインおよびパスワードを彼らのコードにハードコード化するかであり得る。テストおよび開発のＱＡおよび本番モード（QA and Production modes）への遷移は、最小限にテストされていることがある段階の直前に、コードにエクストラ認証手続きを追加することによって行われ得る。アクセスＮｕｔを使用すると、最も早い段階においてそれを開発中のプログラムに統合することが可能であり得、プロセスは決して変化する必要がないことがあり、アクセスＮｕｔのみが変化し得る。マネージャは、開発者、ＱＡエンジニアおよび／または本番ユーザ（production user）のための適切なアクセスＮｕｔを割り当て、作成し得る。これらのアクセスＮｕｔは、彼らのそれぞれのＮＵＴｂｏｏｋコレクションにシームレスに統合し得、彼らが、決して別々にサインオンすることなしにそれらのアプリケーションリソースに接続することを可能にし得る。マネージャは、実際に、アクセスＮｕｔの所有権を維持し、必要に応じてそれを変更し得、ＮＵＴｓｅｒｖｅｒは、エンドユーザが決してそれに悩まされる必要がなくなり得るように、それを最終的に複製し、および／または同期させ得、それにより、プロジェクトマネージャは、ユーザと彼らのアプリケーションとの間の関係をリモートでセキュアに管理し得る。アクセスＮｕｔの効果的な使用は、ユーザが彼らのシステムをシングルサインオン（ＳＳＯ）のために構成することを可能にし得、ユーザのローカルＮＵＴｓｅｒｖｅｒおよび他のあらゆるものへのＳＳＯは、必要とされるとき、自動的に認証され得る。ハイアラーキパスワード（前方参照）は、アクセスおよび情報のいくつかのサブセットのための追加セキュリティを可能にし得る。
【０２２２】
[0219]図１２７は、Ｎｕｔキャッシュ１２６２８がＮｏＳＱＬデータベース１２７２８の機能によって置き換えられ得るＮＵＴｓｅｒｖｅｒの代替実施形態である。ＮｏＳＱＬデータベースは、一部では、オブジェクト指向データベースのサブセットであると考えられ得、それらの多くは、非テーブル構造であり得るＮｕｔのようなコンテナを扱う際に極めて有効であり得る。ＣｏｕｃｈＢａｓｅなど、いくつかのＮｏＳＱＬデータベースは、組込み複製および他の特徴を提供し得、これは、ＮＵＴｓｅｒｖｅｒによって、それの任務のうちのいくつかを行うために採用され得る。
【０２２３】
ＮＵＴＳコアアプリケーション：ＭＩＯＲサーバ
[0220]モジュラーＩ／ＯリポジトリまたはＭＩＯＲは、図１２８に示されているように、サーバベースサービスであり得る。これは、ＭＩＯシステムおよび方法の典型的な実施形態であり得る。コンピューティングデバイス１２８１０は、それ自体のローカルＭＩＯＲキャッシュ１２８１２とともにデバイス上で動作しているローカルＭＩＯＲサーバを有し得る。要求がローカルＭＩＯＲサーバによって満たされないことがある場合、それは、よく知られているインターネットベースＭＩＯＲサーバ１２８２０またはそれらのミラー１２８３０への接触を図り得る。それらのそれぞれのキャッシュ１２８２２および１２８３２は、要求中のＭＩＯモジュールについて探索され得る。見つけられた場合、それは、ユーザのコンピューティングデバイス上の発信ＭＩＯＲサーバにそのＭＩＯモジュールを送り得る。要求されたモジュールがインターネット上の第１のＭＩＯＲサーバ１２８２０において見つけられないことがある場合、ＭＩＯＲサーバ１２８２０は、それを探すためにインターネット上の他のＭＩＯＲサーバへの接触を図り得る。元の要求は、タイムアウト、または、それが全体的に行い得るカスケード要求の数に対するカスケード限界を有し得る。いくつかの実施形態では、要求は、適切な場合、ブロッキングモードでではなく非同期的に行われ得る。
【０２２４】
[0221]このプロセスのより綿密な点検が、図１２９に示され得る。アプリケーション１２９１８は、Ｎｕｔファイル１２９０８をそれのメモリに読み取る必要があり得るローカルデバイス１２９１０上で動作中であることがある。Ｎｕｔ１２９０８は、それが、ＭＩＯＲサーバ１２９１４からのそれのペイロードのための読取りおよび書込みモジュールのあるセットを必要とし得ることを示し得る。アプリケーションは、それのローカルＭＩＯＲサーバ１２９１４に接触し得、このＮｕｔのための読取りおよび書込みモジュールを要求し得る。ＭＩＯＲサーバ１２９１４は、それのローカルＭＩＯＲキャッシュ１２９１６がそれらのモジュールを有し得るかどうかを見るために、ローカルＭＩＯＲキャッシュ１２９１６の中を見得る。見つけられた場合、ＭＩＯＲサーバ１２９１４は、モジュールで、あるいはローカルシステムまたはネットワーク上のモジュールのロケーションの情報で、アプリケーションに返答し得る。見つけられなかった場合、ＭＩＯＲサーバ１２９１４は、それを１２９２０などのより大きいＭＩＯリポジトリに要求するために、ＷＡＮ１２９００、またはＭＩＯＲサーバの他のネットワークを越えて接触を図り得る。ＭＩＯＲサーバ１２９２０は、様々なモジュールについてのインターネットからの要求をサービスするために最適化された専用サーバであり得る。ＭＩＯＲサーバ１２９２２がＭＩＯＲサーバ１２９１４からの要求を受信すると、それは、それらのモジュールについてそれのローカルＭＩＯＲキャッシュ１２９２４をチェックし得る。見つけられた場合、ＭＩＯＲサーバ１２９２２は、要求中のモジュールでＭＩＯＲサーバ１２９１４に返答し得る。見つけられなかった場合、ＭＩＯＲサーバ１２９２２は、これらのモジュールを探し求めてそれのピアグループ中の他のＭＩＯＲサーバに接触し得る。その間に、ＭＩＯＲサーバ１２９２２は、「見つけることに失敗したが探索を続ける」メッセージをＭＩＯＲサーバ１２９１４に送り得る。リモート要求が、要求されたモジュールとともに戻ったとき、ローカルＭＩＯＲサーバ１２９１４は、要求されたモジュールをそれのローカルＭＩＯＲキャッシュ１２９１６に記憶することより前に、それを認証し得る。いつものように、アプリケーション１２９１８がモジュールをインスタンス化し、使用するときが来たとき、アプリケーション１２９１８も、通常のＮＵＴＳ内部機構を使用してコンテンツを認証し得る。
【０２２５】
[0222]図１３０は、ＭＩＯＲサーバからＭＩＯモジュールをフェッチするためのフローチャートを示す。
【０２２６】
[0223]リモートＭＩＯＲサーバとローカルＭＩＯＲサーバとの間の認証は、セッション鍵、またはそれが望ましい場合は匿名アカウントを介して確立され得る。より高いレベルのサービスは、カスタム鍵付きＮｕｔを用いた専用のモジュールへのアクセスを含み得、会社が、カスタム開発されたソフトウェアを使用する会社の従業員のためのＭＩＯＲネットワークの広い分布を使用することを望み得るが、従業員は、彼らが場合によっては会社からのアクセスＮｕｔ中にあるアクセス鍵を有する場合にカスタムモジュールを開き、認証し得るにすぎず、したがって、プロプライエタリ情報が比較的オープンなサービスプラットフォーム上で矛盾なくセキュアにされ得る、など。
【０２２７】
[0224]ＭＩＯＲキャッシュの内部編成の典型的な実施形態が図１３１に示されている。キャッシュ１３１００は、相互参照され、インデックス付けされ得る様々なモジュールへの参照を含んでいることがあるインデックスのセット１３１１０を有し得る。ＭＩＯＲの構造は、この実施形態に限定されず、これらの編成構造および技法の一部または全部を含んでいることがある。あらゆるモジュールがＮｕｔに記憶され得るので、マスタＮｕｔ  ＩＤインデックス１３１１２は、モジュールの一部または全部のＮｕｔ  ＩＤと、キャッシュ中のそれらのロケーションとを含んでいることがある。ファイルＩ／Ｏモジュールインデックス１３１１４は、そのタイプの一部または全部のモジュールを説明およびＮｕｔ  ＩＤによってリストし得る。ファイルアプリケーションモジュールインデックス１３１１８は、そのタイプの一部または全部のモジュールを説明およびＮｕｔ  ＩＤによってリストし得る。ファイルディスプレイモジュールインデックス１３１２０は、そのタイプの一部または全部のモジュールを説明およびＮｕｔ  ＩＤによってリストし得る。コレクションモジュールインデックス１３１１６は、コレクションに属する一部または全部のモジュールを説明およびＮｕｔ  ＩＤによってリストし得る。キャッシュの効率的な探索を可能にするために築かれた他のインデックスがあり得る。コレクショングループ（前方参照）１３１３０〜１３１５０は、関係するモジュールがどのように一緒にグループ化され得るかを視覚的に示すために、図に示されている。コレクショングループ化方法は、ＮＵＴｂｏｏｋの動作において重要なロールを果たし得る。
【０２２８】
ＮＵＴＳコアアプリケーション：ＮＵＴｂｒｏｗｓｅｒ／ＮＵＴｓｈｅｌｌ
[0225]図１３２は、ＮＵＴｂｒｏｗｓｅｒアプリケーションの図を示す。ＮＵＴｂｒｏｗｓｅｒは、本質的に、ＮＵＴｓｈｅｌｌコマンドラインインターフェース（ＣＬＩ）アプリケーションの機能の上で動作し得るグラフィカルユーザインターフェース（ＧＵＩ）であり得る。通常知られているシェルプログラムは、特に、ｂａｓｈシェル、ｃｓｈ、ｃｍｄ．ｅｘｅ、ＤＯＳシェルであり得る。通常知られているファイルマネージャプログラムは、Ｗｉｎｄｏｗｓ（登録商標）  Ｅｘｐｌｏｒｅｒ、アップルのＦｉｎｄｅｒなどであり得る。これらの２つのプログラムの、ユーザが直面する挙動は、それらの一般に知られているカウンターパートとまったく同様であり得るが、差は、ＮＵＴｂｒｏｗｓｅｒおよびＮＵＴｓｈｅｌｌが、Ｎｕｔを認識し得、あらゆるＮｕｔファイルに記憶され得るリッチなメタデータを利用するためにＮｕｔをより十分に処理し得ることであり得る。あらゆるＮｕｔファイルは、２つの方法、すなわち、表面的な「＊．ｎｕｔ」ファイル名拡張子および／またはＮｕｔとしてのコンテンツのより深いプロービングによって識別され得る。たいていのファイルシステムは、ファイル名拡張子方法に適応し得る。Ｎｕｔ読取り試みは、＊．ｎｕｔファイルが実際にＮｕｔであり得ることを確認することを試みるとき、または、信頼できないソースからローカルシステムに新しいファイルを導入するとき、使用され得る。
【０２２９】
[0226]Ｍａｃ  ＯＳ、Ｗｉｎｄｏｗｓおよび／またはＬｉｎｕｘ（登録商標）など、最も普及しているオペレーティングシステムは、ファイル名拡張子、マジックナンバー、ユニフォームタイプ識別子（ＵＴＩ）、ファイルシステム属性などを備えるファイルのタイプを識別するために、いくつかの方法を使用し得る。ファイル名拡張子は、ファイル名が変更され得るとき、それのコンテンツタイプと認識との間のリンクが断たれ得るので、最も表面的な方法であり得る。マジックナンバーとＵＴＩとは、ファイルのヘッドにおいて埋め込まれたメタデータの、コンパクトであるが制限された形式であり得、コンテンツがどんな形式であり得るかを相互参照させるためにファイルタイプのインデックスへのアクセスを要求し得る。ファイルタイプのこのインデックスは、ＯＳ、ファイルシステム、または他の外部システム中に存在し得る。ファイルシステム属性は、ファイルシステムのインデックス付け機構内でそれのインスタンスにアタッチされ得るファイルオブジェクトの属性として表され得る。この情報は、それを記録し、認識し得るファイルシステム／オペレーティングシステム組合せのドメイン内でのみ有効であり得る。Ｎｕｔメタデータは、ペイロードのタイプだけでなく、それがどのように読み取られ、書き込まれ、表示され、および／またはそれを実行し得るかを指定し得る。Ｎｕｔメタデータは、コンテンツを成功裡に処理するのに必要であり得る様々なモジュールの一部または全部のバージョンを指定し得る。事実上、それは、限定はしないが、Ｗｉｎｄｏｗｓレジストリエントリおよび／またはＭａｃ  ＯＳプロパティリストなど、コンテンツを処理するためのいずれかのおよびすべての外部参照テーブルへの一部または全部の依存性を除去し得る。これは、Ｎｕｔが、それのコンテンツにアクセスするために必要とされ得る必要な構成要素を自己記述し、規定することを可能にし得、ＭＩＯＲサーバが、それがアクセスのときに欠くことがある構成要素を自動インストールすることを可能にし得る。
【０２３０】
[0227]ＮＵＴｂｒｏｗｓｅｒ／ＮＵＴｓｈｅｌｌは、選択されたＮｕｔのメタデータを読み取り得、ＭＩＯＲサーバ１３２５０にアクセスすること１３２３２によってＮｕｔのコンテンツ上の適切なアプリケーションを開き、表示し、および／または実行することを試みるために、様々な他のＮＵＴコアアプリケーションと通信し得る。ユーザがＮＵＴｓｅｒｖｅｒ１３２４０中に適切に認証した場合、ＮＵＴｂｒｏｗｓｅｒ／ＮＵＴｓｈｅｌｌは、なお一層Ｎｕｔを適切に開くために一部または全部の必要なアクセスＮｕｔへのアクセス１３２３４を有し得る。事実上、ＮＵＴｂｒｏｗｓｅｒ／ＮＵＴｓｈｅｌｌは、Ｎｕｔを適切に処理し得るアプリケーションとまったく同じように働き得る。
【０２３１】
[0228]ローカルシステム上で使用され得る永続的ストアに応じて、ＮＵＴｂｒｏｗｓｅｒ／ＮＵＴｓｈｅｌｌは、同じファイル名の複数のＮｕｔが、Ｎｕｔ  ＩＤが異なり得る限り同じストレージ領域中に存在することを可能にし得る。データベースおよびオブジェクトファイルシステムなど、いくつかのストレージシステムは、ファイル名に敏感でないことがある。たいていのクラウドベースストレージシステムでは、Ｎｕｔ  ＩＤ識別方法は、旧来の経路名方法よりもネイティブに適合し得る。
【０２３２】
ＮＵＴＳコアアプリケーション：ＮＵＴｂｏｏｋ
[0229]ＮＵＴｂｏｏｋの概略図が図１３３に示されている。今では、一般的なＮｕｔ処理アプリケーションは、同様の構成要素をよく知っているように見えることがあり、すなわち、それは、図１３４中のより一般化されたＮｕｔ処理フレームワークの基礎を形成し得、図１３２中の、ＮＵＴｂｒｏｗｓｅｒアプリケーションがどのように働き得るかと同様に機能し得る。ＮＵＴｂｏｏｋは、ＮＵＴｓｅｒｖｅｒへの必須のインターフェース１３３３４とＭＩＯＲサーバへの必須のインターフェース１３３３２とを有し得る。ＮＵＴｂｏｏｋは、１３３２２および１３３２４によって示されるように、ＭＩＯＲモジュール１３３２６〜１３３３０によって与えられる機能を与えるために、必要に応じてＭＩＯＲモジュール１３３２６〜１３３３０を処理し得る。ＮＵＴｂｏｏｋの主な機能は、カードカタログと呼ばれるキャッシュ１３３３６の編成されたセットを維持することであり得る。ＮＵＴｂｏｏｋは、図１３５に示されているように、データのコレクションから構成された電子カードカタログであり得る。ＮＵＴｂｏｏｋは、一般的な個人情報マネージャにおいて見られる機能のうちのいくつかを提供し得る。なぜＮＵＴｂｏｏｋはカードカタログであるか？ここに、それが理解でき得る様々な理由のリストがある。  
●  ユーザは、データの任意のセットを収集し、処理し、編成する容易なやり方を有しない。  
●  通常、それは、スプレッドシート、テキストファイルまたは単純なデータベースにおいて非公式に行われ得る。  
●  リポジトリがコレクションにおいて項目ごとにデータファイルを備え得るセキュアなやり方でデータの異なるコレクションを入手し、編成し、および／またはカタログ化するための、容易にアクセス可能な一般的な効用がないことがある。  
●  ＰＫＩ証明書、連絡先カード、ＲＢＫセット、ウェブログイン、野球統計、ＶＰＮログインおよび証明、自動車履歴、ＤＶＤコレクション、スタンプコレクション、書籍コレクション、子供の医療記録など。これらは、データまたはカードの異なるコレクションと考えられ得る。  
●  Ｎｕｔは、使用およびトランスポートするのが容易であり得るセキュアなやり方で各タイプの項目をセキュアに記憶し得る。  
●  したがって、同様に、ＮＵＴＳをＮｕｔへシームレスに働かせるために必要とされ得る一部または全部の暗号化鍵を記憶し得る。  
●  これらのカードコレクションのＮｕｔ  ＩＤをインデックス付けすることと、ＮＵＴｂｏｏｋアプリケーション内の随意の探索インデックスメタデータとによって、これらのカードコレクションにアクセスし得る。  
●  ＮＵＴｓｅｒｖｅｒは、いくつかの重要なカードタイプに気づいていることがあり、それのタスクの多くにおいてそれらの処理に優先度を付け得る。  
●  マルチＮＵＴｓｅｒｖｅｒ環境において存在し得るＮｕｔは、デフォルトで容易なトランスポート可能性のために項目ごとに単一のファイルにパッケージ化される、複製、同期、ロギング、完全な履歴、暗号化および／またはアクセス制御を有し得る。
【０２３３】
[0230]ＮＵＴｂｏｏｋは、利用可能なハードウェアに応じて、保護されたまたは保護されていないメモリの形態であり得る鍵キャッシュ１３５２０を含んでいることがある。鍵キャッシュは、限定はしないが、満了の前にそれが使用され得る回数、満了時間および／または満了イベントなど、適切な属性がアタッチされた頻繁に使用されるアクセス鍵を記憶し得る。ＮＵＴｂｏｏｋのメインカタログキャッシュ１３５５０は、それが追跡中であることがあるＮｕｔのマスタＮｕｔ  ＩＤインデックスを有し得る。キャッシュは、限定はしないが、ＰＫＩ証明書１３５６２、連絡先カード１３５６４、ＮＵＴｓｅｒｖｅｒアクセスカード１３５６６、ドキュメント制御カード１３５６８、および／または任意の他の定義されたコレクション１３５７０など、データの異なるコレクションから構成され得る。これらのコレクションは、ＮＵＴｂｏｏｋおよび利用可能なハードウェアの構成に応じて、メモリに、データベースに、ファイルシステムに、または他のストレージ機構に記憶され得る。データベースとファイルシステムストレージとは、それらがネットワークインターフェースを介してローカルにアクセス可能であり得る限り、リモートに位置し得る。図１３６は、ＮＵＴｂｏｏｋカタログキャッシュがどのように編成され得るかのレイアウトの一例であり得る。
【０２３４】
[0231]ＮＵＴｂｏｏｋに記憶されたデータは、ＰＩＭ、パスワードキーパー、ＰＫＩ証明書マネージャ、鍵リング、アドレス帳、メモ取りアプリ、レシピブック、ＣＤコレクションインデックス、スタンプコレクションインデックス、書籍コレクションインデックス、医療記録、および／またはコレクションとして表され得る任意の他のデータセットの塊であり得る。平均的ユーザのための現況技術は、ユーザが彼らの生活の異種部分を、機能的なデジタル形式にデジタル的に編成するための多くの選択肢を提供しないことがある。アドレス帳アプリは多数あるがシームレスであり得、労力を要しない相互互換性を欠いていることがある。たいていの賢明なユーザは、機密性が高いパスワードを彼らのアドレス帳に記憶しないことがあり、その特定の目的のためにパスワードキーパーアプリを評価し、利用し得る。ただこれらの２つの単純なアプリ、アドレス帳およびパスワードキーパーについてでさえ、ユーザが、特に、オペレーティングシステム互換性、同期、クラウドフットプリント、バックアップ、ウェブブラウザ統合などの特徴を考慮した場合、意思決定行列は、いくつかの次元によって拡大していることがある。また、パスワードキーパーとアドレス帳との間の良好な統合の保証がないことがある。ユーザが、ユーザの家族メンバーの医療記録、自動車修理記録、住宅保守スケジュール、子供の授業に関係する学校ログイン、ペットの獣医記録、デジタルデバイス情報、および／またはデータの他のコレクションを追跡することを希望する場合、ユーザは、データの各タイプについて異なるアプリを使用して様々な異なるフォーマットにおいてそれを行わなければならないことがある。スプレッドシートの一般的な使用は、データのそのような異種セットを編成することであり得、ユーザのための汎用データベースとして働き得る。ＮＵＴｂｏｏｋは、ユーザが、情報の一部または全部のタイプをＮｕｔ形式に系統的に記憶することを可能にし得、データの使用を任意のＮｕｔ準拠アプリケーションに統合し得る。適切に形成され、識別され得るデータは、それの定義された構造を利用し得るアプリによって機能的にされ得る。ＮＵＴＳ環境の特徴の一部または全部は、限定はしないが、セキュリティ、同期、複製、バックアップおよび／または非旧式化など、ＮＵＴｂｏｏｋ中のあらゆるＮｕｔのために利用可能であり得る。
【０２３５】
[0232]非旧式化および／または時間互換性は、ＭＩＯＲを使用することの重要な特性であり得る。ＭＩＯＲとともにＮＵＴｂｏｏｋ内のコレクションを使用することによって、ユーザは、いくつかの利点を獲得し得、すなわち、ユーザが生成し得るデータはユーザのものであり得、データはセキュアであり得、ユーザは、ユーザのデータに無期限に（またはＮＵＴＳがアクティブであり、サポートされ得る限り）アクセスすることが可能であるとの妥当な予想を有し得る。ＮＵＴｂｏｏｋはまた、データベースユーザの世界とファイルユーザの世界との間の橋渡しとして働き得る。ＮＵＴｂｏｏｋは、ファイルフォーマットに記憶された記録の形態のデータベースの利益を与え得る。特定のコレクションについての読取り／書込み機能のためのＭＩＯモジュールは、ユーザが念頭に置くことがある特定のコレクションの詳細をキャプチャすることに関係するフィールドの編成された仕様セットであり得るが、それは、このモデルに限定されないことがある。いくつかの実施形態では、読取り／書込みモジュールは、様々なデータベースへのインターフェースであり得、コーリングアプリケーションのためのフィールドマッピングおよびコンバージョン機能を与え得る。他の実施形態では、それは、ソフトウェア会社からのライセンス鍵を使用してペイロードのプロプライエタリバイナリフォーマットを非サイファ化する読取り／書込みモジュールであり得る。データにアクセスするためにモジュールが使用され得る様々なやり方は、極めて多様であり得、アプリケーション開発者の目標に応じて多くの転置を有し得る。特定のコレクションの基本構造は、ほとんどプログラミング知識をもたないユーザが単純な既存のテンプレートから開始することによってカスタマイズされ得る。新しく有用なコレクションは、それらの個人使用のためにそれらのローカルＭＩＯＲに追加され、Ｎｕｔファイルを介して他者と共有され得る。それはまた、何らかの承認プロセスの後の誰かによる使用のためにインターネットＭＩＯＲサーバにサブミットされ得る。
【０２３６】
[0233]今やＮＵＴｂｏｏｋの動機づけおよび設計目標のうちのいくつかをカバーしていることがあるので、ＮＵＴｂｏｏｋが、どのように、ＰＫＩとして働き得、最終的に、平均的ユーザのためのサービスのＳＳＯレベルを提供し得るかに焦点を当て得る。図１３７は、ハイアラーキパスワードの概念を概説する。ＮＵＴＳ用語では、パスワードは、Ｎｕｔが両方の形式を受け付け得るので、パスフレーズと等価であり得、パスワードの代わりに、ユーザは、ハードウェアトークン、符号化バイナリ鍵、または秘密鍵を与え得る任意の他の方法を使用し得る。パスワードと、限定はしないが、２ファクタ認証、ログインルール、カスタムパスワードルール、カスタムウェブページおよび／またはハードトークンなど、それらの関連する差別化との雑草のような急増は、急速に手に負えなくなり得、ユーザを、多くのウェブサイトにわたって、覚えているのが極めて容易なパスワードにユーザが頼り得る精神状態にし得、それにより、ユーザは、個々のベンダーのクライアントのためにベンダーのシステムをよりセキュアにするためのベンダーの労力を打ち消していることがある。ＮＵＴＳのための好ましいソリューションは、効果的なＳＳＯアクセスを可能にするためにできるだけ少数のパスワードを使用することであり得、ハイアラーキパスワードはこの手法を具現し得る。ＮＵＴｓｅｒｖｅｒおよびＮＵＴｂｏｏｋへの基本認証を可能にし得るメインパスワード１３７１０があり得る。メインパスワードは、鍵キャッシュ１３５２０中でキャッシュされ得る鍵を含んでいるＮｕｔを開き得、セッションまたは所定のイベントの終了の後に自動削除するように構成され得る。このメイン鍵は、たいていのＮＵＴｓｅｒｖｅｒおよびＮＵＴｂｏｏｋ機能を効果的に使用するのに十分であり得る。限定はしないが、ショッピング１３７１４、作業１３７１６、ファイナンス１３７１８および／または通信１３７１２など、第２のレベルのパスワードがあり得る。これらのパスワードは有効なメインパスワードを成功裡に入力した後にのみ入力され得、したがって、それらはパスワードのハイアラーキを尊重し得る。この第２のレベルは、ユーザが、データの異なるグループのためのセキュリティの異なるレベルを分離し、隔離することを可能にし得る。第２のレベルにおける各パスワードは、ユーザがそれらの露出を制御し得るように、鍵キャッシュ１３５２０中で異なる有効期間を有するように構成され得る。たとえば、ユーザは、銀行コレクションカードにおいてインターネット銀行アカウントログイン情報を有し得、単一の使用の有効期間を有し得るファイナンス鍵を用いてそれをセキュアにし得る。その場合、ユーザは、銀行カードに記憶されたログインおよびパスワードにアクセスすることによってユーザが銀行ウェブサイトにアクセスすることを希望し得るたびにファイナンスパスワードを入力しなければならないことがある。各銀行カード内で、ウェブサイトパスワードは、エントロピーを最大にするためにランダムに作成され、ＮＵＴｂｏｏｋによるオートログイン使用のために記憶され得る。追加されるより多くのレベルがあり得るが、それは、ユーザの情報の複雑さと、ユーザがどのくらい暗記することを希望し得るかとに依存する。一部または全部のハイアラーキパスワードをバイパスし得るマスタパスワード１３７２０があり得る。マスタパスワードは、慎重に選定されるかまたは最大保護のためにランダムに発生され得、安全な場所において保たれ得る。このハイアラーキパスワード方法論を使用すると、ユーザは、推測することが難しいことがあるが、ただユーザが暗記する必要があり得るパスワードの数の低減により、ユーザによってより容易に暗記され得る、パスワードのセットを慎重に選定する必要があり得るにすぎず、これは、ユーザのＳＳＯアクセスの基礎を形成し得る。
【０２３７】
[0234]図１３８は、個人ドキュメントＮｕｔ１３８０６を開くためのパスワード入力プロセスについて一通り説明するものである。このドキュメントは、メインレベル鍵のみによって保護され得、したがって、ＮＵＴｓｅｒｖｅｒへ認証するためにメイン鍵にアクセスするためにメインパスワード１３７１０を入力すること１３８０４は、個人ドキュメント１３８０６を保持するＮｕｔを開くのに十分であり得る。図１３９では、マスタパスワード１３７２０のルートは、メインパスワードのルートとまったく同じであり得る。
【０２３８】
[0235]図１４０は、第２のレベルの作業パスワード１３７１６によって保護される作業ドキュメントがどのように開かれ得るかを示す。メイン鍵にアクセスするためにメインパスワード１３７１０が供給され得、次いで、作業ドキュメントＮｕｔ１４０１０をロック解除し得る作業レベル鍵へのアクセスを獲得するために、作業パスワードが入力され得る１４００８。図１４１では、マスタパスワード１３７２０のロック解除ルートは、図１３９中のものと同じのままであり得、それは依然として単一ステップアクセスであり得、したがって、マスタパスワードは、よりセキュアな様式で作成され得る。
【０２３９】
[0236]図１４２は、ＮＵＴｂｏｏｋ鍵キャッシュ１３５２０のより詳細な図を示す。それは、ＮＵＴｓｅｒｖｅｒに関連する鍵について区分されたセクション１４２１０を有し得、それは、それの様々なカードコレクションで使用するために区分されたセクション１４２３０を有し得る。
【０２４０】
[0237]図１４３は、ＮＵＴｂｏｏｋがカタログカードをどのように閲覧し得るかのプロセスフローチャートを示す。
【０２４１】
[0238]保有される所有権は、異なる所有者のＮｕｔを混ぜることに関係する概念である。アリスがＡｃｍｅ社での新しい仕事を得、アリスとＡｃｍｅ社が両方とも、彼らのそれぞれの連絡先および／またはデジタル鍵を編成することの細かい点を管理するためにＮＵＴＳベースアプリケーションを使用し得ると仮定する。追加として、Ａｃｍｅは、部門によっておよび／または従業員アクセスレベルによってアクセスＮｕｔを制御し、企業ドキュメントを慎重にロックするためにＮｕｔを使用し得る。アリスが雇用されたとき、ＡｃｍｅのＨＲ部門は、全体的な企業アクセスＮｕｔをアリスに支給し得、それは、内部企業連絡先リスト、クライアントリスト、および／または様々な企業ドキュメントなど、情報をアリスがルックアップすることを可能にし得るアクセスＮｕｔであり得る。ＡｃｍｅのＮＵＴＳシステムは、従業員の特定のアクセスＮｕｔと企業マスタ鍵とによってロックされたラッピングＮｕｔにペイロードのコピーをラッピングすることによって、Ｎｕｔに記憶され得る機密性が高いドキュメントへのアクセスを与えるようにカスタマイズされ、および／または構成されていることがある。これらの企業Ｎｕｔの所有権（ＲＡＴ）は、常にＡｃｍｅであり得る。同様に、アリスの個人Ｎｕｔは、常に、アリスをＲＡＴとして有し得る。暗号のやり方で所有者を明瞭に定義するアビリティは、各Ｎｕｔが、それらのＮＵＴＳ環境内で各それぞれの所有者によって適宜に扱われることを可能にし得る。Ｎｕｔのこの保有される所有権特性は、アリスが、アリスが使用し得る任意のデバイス上でアリスのＮｕｔをＡｃｍｅのＮｕｔと混ぜ合わせ、それらの制御を維持することを可能にし得る。同じことが、アリスのデバイス上のＡｃｍｅのＮｕｔに適用され得る。アリスとＡｃｍｅの両方が、彼らのそれぞれのアクセスＮｕｔの有効期間を比較的短い期間となるように設定し得る。たとえば、有効期間は、外部システムに記憶されたＮｕｔ上で６０日に設定され得る。したがって、６０日ごとに、鍵は、それらによって所有されるＮｕｔの各所有者によって一新され得るか、または、鍵は、それらを管理する外部ＮＵＴｓｅｒｖｅｒによって自動的に削除され得る。削除は、適切なＮＵＴｓｅｒｖｅｒが適切なアクセスＮｕｔにおいて削除コマンドを送られ得、それが、所有者の一部または全部の影響を受けるＮｕｔを系統的に削除するように符号化され得る場合、強制的に行われ得る。それにより、各当事者は、直接的にまたは間接的にのいずれかで外部システムにおいてそれらのＮｕｔの制御を維持するアビリティを有し得る。したがって、アリスが新しい仕事のために辞める場合、アリスは、アリスがアリスの企業デスクトップ上にそのコピーを残していることがあるアリスの個人連絡先情報が、６０日以内に自動的に削除され得ることを知っていることがある。同じことが、アリスの個人デバイス上に残されたＡｃｍｅ所有のＮｕｔについて適用され得、一新されたアクセスＮｕｔがない場合、システム上にはそれ以上関連Ｎｕｔがない。このタイプの、Ｎｕｔを混ぜることは、２つまたはそれ以上の別個の連絡先リスト、および作業を家に持ち帰るためのセキュリティ対策の異なるセットを上手にやりくりすることの長年の問題を解決するように意図され得る。今や、アリスは、アリスの個人ＮＵＴｂｏｏｋをアリスの個人生活および職業生活における連絡先のアリスのメインソースとして常に使用し得、アリスは、それがセキュアであり得ると合理的に確信し得る。
【０２４２】
[0239]別の実施形態では、ＮＵＴｂｏｏｋ連絡先カードは、知人についての個人情報を含んでいる外部Ｎｕｔへの参照を搬送するか、またはその外部Ｎｕｔを埋め込み得る。ボブからの外部Ｎｕｔは、アリスによって所有されず、ボブによって所有され得る。ボブは、ボブ自身に関する、事前パッケージ化された、詳細の限られた連絡先Ｎｕｔをアリスに送り得、アリスのＮＵＴＳ環境においてそれの所有権を維持し得る。ボブのためのアリスのＮＵＴｂｏｏｋエントリは、このＮｕｔを、直接的にまたは参照によってのいずれかでボブのためのアリスの連絡先エントリに埋め込み得る。ボブが新しいメーリングアドレス、新しい作業アドレス、電話番号、または他の影響を受ける情報など、ボブ自身に関する一部または全部の情報を変更するときはいつでも、ボブは、ボブの事前パッケージ化された連絡先Ｎｕｔへの更新を、任意の利用可能な手段によってアリスに送り得、アリスのＮＵＴｓｅｒｖｅｒがそれを認識すると、それは、アリスのＮＵＴｂｏｏｋ中のボブのためのカードにおける適切な埋め込まれた外部Ｎｕｔを自動的に更新し得る。次いで、アリスのＮＵＴｂｏｏｋは、更新されたカードを処理するために連絡先アプリケーションを実行し得、これは、ボブのためのアリスのカードにおける更新につながり得る。この最後のステップは、ボブのためのアリスのカードエントリがボブの情報に関するそれの過去の履歴を決して失わないことがあり、アリスがそのように望み得るとき、アリスがボブの情報の様々な履歴変更を見つけ出し得ることを保証し得る。これらのステップの一部または全部は、よく確立された信頼できるＲＢＫ関係への介入なしに自動的に行われ得る。これは、アリスの信頼できるＲＢＫ関係の一部または全部が、ほとんどまたはまったく手動介入なしに連絡先情報を更新していることがあり、これが、アリスおよびアリスの友人の各々に関する時間および労力の大きい節約につながり得ることを意味し得る。アリスが９９個のＲＢＫ連絡先を有し、５０個の更新が行われ得る場合、５０個の変更のみが、影響を受ける人々自身によって始動されなければならないことがあり、残りは、各影響を受ける人のＮＵＴｓｅｒｖｅｒによって自動的に扱われ得る。旧来のアドレス帳設定では、５０個の更新は、影響を受ける個人による５０個の更新になり得、９９人の友人への５０個の通知が彼らに変更を知らせ、９９人の友人の各々が彼ら自身のアドレス帳に最高５０個の更新を行い、これは、関与し得る１００人の人々によって費やされる全体的な時間はおろか、５０個の更新が生まれ得るというほぼ１０，０００個のイベント内の、あるレベルの転写エラーを伴う。この実施形態は、集中型サービスを有することによって代替的に解決され得るが、そのようなサービスは、制限付きプライバシー、アクセス、所有権および／または制御を与え得る。ＮＵＴＳソリューションは、高いレベルのプライバシー、履歴、監査証跡および／または所有権を矛盾なく維持することを試みながら、できる限り非集中化を重要視し得る。
【０２４３】
ＮＵＴＳベースサービス
[0240]ＮＵＴＳベースサービスは、Ｎｕｔが複数のリモート当事者間で利用され得るように、Ｎｕｔ使用法をインターネットなどのより広いネットワークに拡張し得る。図１４４中の表は、ＮＵＴＳがサポートし、提供し得る様々なウェブベースサービスの例をリストし、図１４５は、これらのサービスのための簡略化されたネットワークレイアウトを示す。一部または全部のサービスが、マルチティア化サービスパッケージを提供し、最も低いレベルが制約を伴って無料で提供され得る。上位ティア化パッケージのための支払いは、別々に購入されたサービスクレジットバウチャーを介して、直接的にまたは匿名で行われ得る。サービスの一部または全部は、異なる程度に匿名で使用され得る。
【０２４４】
ＮＵＴＳベースサービス：ＮＵＴｍａｉｌ
[0241]図１４６に示されているＮＵＴｍａｉｌサーバは、それの登録されたユーザの間でＮｕｔを介して一部または全部のそれのメッセージを受け渡すウェブベース電子メールサービスを示す。さらに、それは、自動登録、匿名登録、匿名チャネル、および／またはＲＢＫベース通信をサポートし得る。サーバは、ＮＵＴｂｏｏｋアプリおよび／またはＮＵＴｓｅｒｖｅｒアプリと対話し得る。ＮＵＴｍａｉｌは、ユーザが電子メールを管理し、編集し、表示し、構成し、送り、および／または受信することを可能にするためにユーザのデバイス上で動作し得るクライアント構成要素を有し得る。
【０２４５】
[0242]図１４７は、自動でＮＵＴｍａｉｌサーバ上で匿名登録を確立するためのプロセスを示す。ユーザは、限定はしないが、電子メールアドレス、テキスト対応電話番号、および／またはウェブブラウザなど、好ましい既存の連絡方法を含んでいることがある事前パッケージ化されたＮｕｔを用いてサーバに接触し得る１４７００。サーバは、要求を受け付け得１４７０２、好ましい連絡方法を使用してユーザに要求を送り得る１４７０４。ユーザは、要求から必要とされる情報を入力し得、サーバは、１４７０６において、サイファ方法の最大エントロピーを採用し得るランダムに発生されたログインＩＤおよびパスワードを作成し得る。サーバはまた、ユーザとサーバ／アドミニストレータとの間の一部または全部の通信において採用され得る、ユーザとのＲＢＫペアを発生し得る。ユーザは、ユーザ自身の連絡先情報のためのカードにおいて、ユーザのＮＵＴｂｏｏｋにログイン証明およびＲＢＫペアを記憶し得る１４７０８。したがって、ユーザは、大部分が自動化されたやり方でＮＵＴｍａｉｌサーバに匿名で登録していることがある１４７１０。
【０２４６】
[0243]登録プロセス中に作成されていることがあるログインＩＤおよびＲＢＫは、ＮＵＴｍａｉｌサーバに通信するためにユーザによってのみ使用され得、ある点では、それは、ユーザとサーバとの間の非公開チャネルと考えられ得る。ユーザが、同じくＮＵＴｍａｉｌを使用し得る別の人と通信することを希望するとき、図１４８に示されているように、ＮＵＴｍａｉｌサーバ上のその人との通信チャネルが確立される必要があり得る。通信チャネルは、各ユーザの登録されたアカウントにエイリアスとしてアタッチされ得るランダムに発生された電子メールエイリアスのペアを備え得る。ＮＵＴｍａｉｌサーバは、関係の匿名性をより良く保存するために、通信チャネルが確立され、検証されていることがあると、これらのエイリアスペアを追跡しないことがある。これらのエイリアスは、ＲＢＫがチャネルにおける２人の参加者によってのみ使用され得るという点で、機能がＲＢＫと同様であり得る。エイリアス発生のランダム性質は、インターネットにわたる電子メール移動中に参加者の識別情報へのヒントを漏らさないことがある。電子メールコンテンツ自体が、ＲＢＫ方法によって保護されたＮｕｔに入れられ、ペイロードをさらに保護し得る。これは、一部または全部の不要なスパムおよび／またはサードパーティ電子メールスニッフィングを最小限に抑え得る関係ベース方法および不明瞭化の２つの別個のレイヤを与え得る。通信チャネルが適切に確立され得ると、電子メールの交換は、図１４９に示されているように、かなり標準的であり得る。
【０２４７】
[0244]ＮＵＴｍａｉｌサーバの背後のセキュリティ論拠は、以下のように要約され得る。  
●  匿名登録は、危殆化されたサーバが、登録されたユーザおよび／または彼らの電子メールコンテンツに関して曝露するものがほとんどないことがあることを意味し得る。  
●  ＲＢＫ暗号化されたＮｕｔ内での電子メールのカプセル化は、コンテンツセキュリティの別の依存しないレイヤを与え得る。ハッキングされたサーバは、Ｎｕｔによってセキュアにされたメッセージのみを曝露し得る。  
●  エイリアスペアを使用するＮＵＴｍａｉｌ通信チャネルは、電子メールメタデータを不明瞭にし得る。  
●  サーバは、エイリアスペアリングデータを永続的にではなく、チャネルが検証されるのに十分に長く記憶するにすぎないことがある。  
●  サーバは、極めて短い時間期間の間電子メールメッセージを記憶し得る。サーバはユーザによって構成可能であり得るが、デフォルトは、少なくとも２つのコピーがサーバの外部に存在し得るという情報をサーバがユーザのＮＵＴｍａｉｌクライアントまたはＮＵＴｓｅｒｖｅｒから受信し得る後に、あるいは事前構成された持続時間の後に、メッセージが抹消され得ることであり得る。  
●  電子メールの短い履歴は、サーバが、極めて小さい長期データストレージ要件を有することを可能にし得る。  
●  ランダムに発生されたログイン、エイリアス、パスワードおよび／またはＲＢＫは、利用可能なデータエントロピーを十分に利用し得、これは追加セキュリティにつながり得る。
【０２４８】
[0245]ＮＵＴｂｏｏｋの統合された容易化なしにＮＵＴｍａｉｌサーバを使用することは容易でないことがあるが、それは可能であり得る。ログインＩＤ、パスワードおよび／またはエイリアスは、最大エントロピー法を使用して発生され得、ランダムな文字の長いストリングの寄せ集め（jumble）のように見え得る。関係とエイリアスペアとの間の１：１の対応があり得、したがって、ユーザが追跡しなければならないことがあるエイリアスの数が極めて急速に多数になり得る。この通信方法論の利益は、参加者によって発生されたデータがそれ自体としては無用であり得、ターゲットにされるデータ監視および／または洗練された再構築技法を介してのみ、何らかの意味が抽出され得ることであり得る。
【０２４９】
[0246]ＮＵＴｍａｉｌサーバのデータストレージ要件は、通常の電子メールサーバとは異なり得、それは、継続的にユーザごとのはるかに小さいスペースを使用し得る。ユーザのＮＵＴｓｅｒｖｅｒまたはＮＵＴｍａｉｌクライアントが、電子メールの少なくとも２つのコピーがＮＵＴｍａｉｌサーバの外部に存在し得ることを示し得るとき、ＮＵＴｍａｉｌサーバは、その電子メールＮｕｔを永続的に削除し得る。このタイプの単純なルールは、チャネルにおける各参加者が、各々最低でも彼らのコミュニケの２つまたはそれ以上のコピーを確立することを可能にし得る。ＮＵＴｍａｉｌサーバは、できるだけ多くの長期ストレージをオフロードし、それにより、ユーザごとのそれ自体の継続中のストレージ要件を低減するために、各登録されたクライアントのＮＵＴｓｅｒｖｅｒを活用し得る。ＮＵＴｍａｉｌサーバは、各ユーザが彼ら自身のＮＵＴｍａｉｌクライアント／ＮＵＴｓｅｒｖｅｒシステム上で前の電子メールをダウンロードし、複製していることがあるので、登録されたユーザのための新しい電子メールメッセージのみを有し得る。
【０２５０】
ＮＵＴＳベースサービス：ＮＵＴｃｈａｔ
[0247]ＮＵＴｃｈａｔは、Ｎｕｔに基づく匿名チャットサービスであり得る。それは、以下のチャット特徴を提供し得る。  
●  それは、匿名登録、ペアワイズランダムエイリアス、および／またはＲＢＫをサポートし得る。  
●  それは、匿名性のためにローカルＮＵＴｃｈａｔハブ電話番号を与えることが可能であり得る。  
●  それは、同時セルフォンおよび非セルフォンチャットをサポートし得る。  
●  それは、ＳＭＳ／ＭＭＳおよびインターネットベースチャットセッションを同時にサポートし得る。  
●  それは、ＮＵＴｍａｉｌサーバと同様の履歴特徴をサポートし得る。  
●  チャット履歴は、各連絡先エントリストレージ内にセーブされ得るか、あるいは、それはＮｕｔに記憶され得、それは、ただ電話番号またはチャットアドレスによってではなく、ターゲット連絡先エントリによって参照され得る。  
●  チャット履歴は、ＮＵＴｃｈａｔサービスの必要なしに個人使用のために永続的にセーブされ得る。  
●  ＮＵＴｃｈａｔは、Ｎｕｔ中に含まれていることがあるチャットメッセージのための特殊なサービスであり得る。  
●  ランダムに発生されたログイン、エイリアス、パスワードおよび／またはＲＢＫは、利用可能なデータエントロピーを十分に利用し得、これは追加セキュリティにつながり得る。  
●  それは、メッセージの配信を保証し、仮想チャットセッションを示すために、通信ルートを多重化し得る。
【０２５１】
[0248]ＮＵＴｃｈａｔサーバについてのネットワーク図の一例が、図１５０に示されている。それの登録手続きは、ＮＵＴｍａｉｌサーバによって採用される方法と同様であり得、それのユーザのための一部または全部の匿名特徴を提供し得る。ユーザデバイス上で動作しているＮｕｔベースＮＵＴｃｈａｔクライアントがあり得、３人の参加者間のチャットセッションについての基本データフロー構成が、図１５１に示されている。これは、中間でコーディネータとして働くＮＵＴｃｈａｔサーバ１５１００をもつ標準テキストメッセージパッシングトポロジーであり得る。ＮＵＴｃｈａｔはＮｕｔに基づき得るので、セッションのチャット履歴全体が、Ｎｕｔにおいてセーブされ得、したがって、適切に構成された場合、自動的にＮＵＴｓｅｒｖｅｒ複製／伝搬／同期特徴を利用し得る。ＮＵＴｓｅｒｖｅｒは、ＮＵＴｃｈａｔ  Ｎｕｔが、チャットセッションにおけるリアルタイム対話性の性質により、よりタイムリーな様式で扱われ得るように、ＮＵＴｃｈａｔ  Ｎｕｔに優先度を付けるように構成され得る。図１５１を詳しく見ることは、同じチャットＮｕｔが複数のロケーションにおいて存在することを示し、それは、チャットトポロジーが複数の物理的ロケーションにおけるデータ状態の合理的同期と等価であり得ることを示す。図１５２は、ユーザのＮＵＴｓｅｒｖｅｒを使用してＮＵＴｃｈａｔセッションを複製し得るプロセスのデータフローの一例である。各チャット参加者がＮｕｔ１５１２２〜１５１２６にチャットセッション履歴の一部または全部を記憶し得るので、ＮＵＴｓｅｒｖｅｒ１５２３８は、１５２４２など、それのピアＮＵＴｓｅｒｖｅｒにわたってそれらのＮｕｔの変更を伝搬し得る。この体系的な様式でデータを適切に同期させることによって、ユーザがユーザのデバイス＃４  １５２４０上のＮＵＴｃｈａｔクライアント１５２６０を立ち上げたとき、ユーザは、ユーザがデバイス＃２上に同じセッション履歴を残していることがあるので、そのセッション履歴を見得、ＮＵＴｃｈａｔサーバは、決して、ユーザのデバイス＃４を最新にすることに関与していなかった。チャットセッションが始動されたとき、およびそれぞれのＮＵＴｃｈａｔクライアントによるチャネルの両側でのチャットＮｕｔの検査が、それを非同期であると決定し得るとき、そのセッションを最新バージョンに更新させるために強制同期手続きが自動的に始動され得る（チャット履歴の分類が、基本的に、Ｎｕｔ履歴としても知られているペイロードのより新しい状態と見なされ得ることに留意されたい）。たとえば、アリスは、ボブとの長く続いている匿名ＮＵＴｃｈａｔチャネルを有し得るが、どういうわけか、アリスは、アリスのスマートフォンでこのセッション履歴を記憶したアリスのチャットＮｕｔを失うか、または削除していることがある。アリスがボブとのこのＮＵＴｃｈａｔセッションを再開し、ＮＵＴｃｈａｔサーバを通して接触を行い得るとき、サーバは、アリスとボブの両方からセッションのバージョン番号を受信し得、それは、ボブがアリスよりも後のバージョンのセッションを有し得ることを示し得る。その時点において、ボブのチャットＮｕｔのコピーが自動的に要求され得、ＮＵＴｃｈａｔサーバを介してアリスに送られ得、アリスのＮＵＴｃｈａｔクライアントは、ボブのセッション履歴をそれ自体として受け付け得、チャットセッションは、それの履歴およびそれによりそれのコンテキストの共通のビューで続き得る。ＮＵＴｃｈａｔサーバによってこのシナリオにおいて使用されているストレージがほとんどないことがあり、一部または全部のセッション情報が、エンドユーザの制御下でエンドユーザによって記憶され得る。チャットセッションバージョンが同期されていることがあると、その後互いに送られたチャットメッセージは、履歴全体ではなくセッションにおける新しいチャットメッセージのみを保持するＮｕｔ中に含まれていることがあり、各端部上のＮＵＴｃｈａｔクライアントは、それの累積チャットセッションをそれぞれ更新することを担当し得、それにより、それは、継続中のチャットセッションにおいてデータ転送のサイズを低減し得る。
【０２５２】
[0249]さらに、アリスのＮＵＴｂｏｏｋは、チャットＮｕｔと電子メールＮｕｔとを参照するかまたはそれを指すために、ボブのためのアリスの連絡先エントリにおいて参照を行い得、それにより、ボブとの一部または全部の関連する履歴通信がボブの情報の下でインデックス付けされ得、これが、アリスの制御下で記憶された関係におけるコンテキストの系統的な照合を生じ得る。
【０２５３】
[0250]ＮＵＴｃｈａｔクライアントは、信頼性、冗長性および／または不明瞭化のために経路アグノスティックチャットセッションを伴い得るダイアログに関わり得る。図１５３は、最高３つの異なるチャットサービスおよび／またはチャットＩＤを使用中であることがあるボブとアリスとの間の３つの別個のチャットセッションのための一般的なデータフローパターンを示す。時々、このタイプの切り離しおよび分離が望まれ、関与し得る当事者に好都合であり得る。またあるときには、それは、他の参加者によって行われた選定によってユーザに強制され得、たとえば、ボブはチャットサービスＢに関するアカウントのみを求め得、したがって、アリスは、ボブとチャットするためにサービスＢに関するログインを作成することを強制され得る。しかしながら、ＮＵＴｃｈａｔクライアントが他のチャットサービスとインターフェースし得る限り、それは、同じ２人の人の間の複数の別個のチャットセッションが、ダイアログと呼ばれることがある、図１５４に示されている経路アグノスティックチャットセッションになるように塊にされることを可能にし得る。チャットＮｕｔは、一部または全部がバージョン番号を有し得、Ｎｕｔのコピーが同時に一部または全部の３つのチャットセッション経路上で送られ得るような、メッセージの基本媒体であり得る。他方のＮＵＴｃｈａｔクライアントに達し得るどちらのチャットＮｕｔでも最初に処理され得、他方が無視され得る（または、ＮＵＴｓｅｒｖｅｒ  Ｎｕｔマージによってマージされ、次いで廃棄され得る）。時々、トランスポート制限の性質により、チャットＮｕｔは、トランスポートプラットフォームに適した、簡明なセキュアにされたテキストメッセージにコンバートされ得る。本方法では、会話は複数の経路にわたって保存され得、最も最近のバージョンのみが常に各参加者に示され得、プロセスは、個々のチャットサービスプロバイダのストレージおよび／または編成機能に依拠しないことがあり、それらのトランスポート機構のみに依拠し得る。冗長経路は、ダイアログについてのトランスポート失敗を最小限に抑えるかまたはほぼなくし得る。各トランスポートサービスが記憶し得る履歴はメッセージごとにＮｕｔによって保護され得、したがってコンテンツは不透明であり得るので、その履歴は無用であり得る。トランスポート機構は、限定はしないが、電子メールサーバ、ＦＴＰサーバ、ネットワーク化されたファイルシステム、ポイントツーポイント接続、Ｗｉ−Ｆｉ（登録商標）プロトコル、Ｂｌｕｅｔｏｏｔｈ（登録商標）プロトコル、および／または任意の他のデジタル送信方法など、Ｎｕｔが受け渡されることを可能にし得る任意のチャネルであり得る。Ｎｕｔの同期プロパティは、チャットセッションが、少なくとも２人のライターを有するように構成された共有可能なＮｕｔと、ユーザがそのＮｕｔにアクセスするための共通方法とを使用することによってのみ関わられることを可能にし得る。この実施形態は、サービスに依存せずにユーザのデータを保護し、ユーザによって送信機構の全体的信頼性を強固にしながらチャットシステムの機能の仲介を排除する（disintermediate）ことが、どのくらい比較的単純であり得るかを示し得る。
【０２５４】
ＮＵＴＳベースサービス：ＮＵＴｃｌｏｕｄ
[0251]ＮＵＴｃｌｏｕｄは、図１５５に示されているように、どんなＮＵＴＳユーザにとっても利用可能なインターネットベースストレージサーバであり得る。ＮＵＴｃｌｏｕｄは、匿名登録、ペアワイズランダムエイリアス、および／またはＲＢＫをサポートし得る。それは、個人ＮＵＴＳネットワークの範囲および利用可能性を拡張するために個人ＮＵＴｓｅｒｖｅｒとシームレスに統合し得る。ＮＵＴｃｌｏｕｄはＮｕｔを記憶し得、それのストレージおよび帯域幅限界は、サービスティアレベルとユーザ構成可能なポリシーとの影響を受け得る。ＮＵＴｃｌｏｕｄアカウントは、より永続的なおよび／またはアクセス可能なストレージを供給するために他のＮＵＴＳベースサービスと相互動作し得、すなわち、それは、ＮＵＴｍａｉｌおよび／またはＮＵＴｃｈａｔメッセージをバックアップし得る。
【０２５５】
[0252]サービスのベースレベルにおいて、それは、一般的な個人使用のための十分なレベルのストレージおよび帯域幅を提供し得る。それの主な目的は、インターネット上の任意のアクセスポイントからＮｕｔに記憶されたデータにアクセスすることを容易にすることであり得る。それは、自宅でおよび路上でアリスのデータの一部または全部を同期させるためにＮＵＴｓｅｒｖｅｒとシームレスに統合し得る。
【０２５６】
[0253]個人ＮＵＴｓｅｒｖｅｒとともにＮＵＴｃｌｏｕｄは、任意のインターネットベース中央管理クラウドサービスとして、同じまたはより良いレベルの同期を提供し得るが、普及している自由に利用可能なクラウド同期サービスとは異なり、ＮＵＴｃｌｏｕｄは、完全な匿名性、ユーザ制御プライバシー、完全な履歴、完全な監査証跡、および／またはセキュアにされたデータ所有権を提供し得る。
【０２５７】
ＮＵＴＳベースサービス：ＮＵＴｎｅｔ
[0254]ＮＵＴｎｅｔは、図１５６に示されているように、ＮＵＴＳユーザにとって利用可能なＮｕｔベースウェブサーバであり得る。ＮＵＴｎｅｔは、匿名登録、ペアワイズランダムエイリアス、および／またはＲＢＫをサポートし得る。ＮＵＴｎｅｔはＮｕｔを記憶し得、それのストレージおよび帯域幅限界は、サービスティアレベルとユーザ構成可能なポリシー設定との影響を受け得る。ＮＵＴｎｅｔアカウントは、より永続的なおよび／またはアクセス可能なストレージにアクセスするために他のＮＵＴＳベースサービスと相互動作し得、たとえば、それは、ＮＵＴｃｌｏｕｄおよび／またはＮＵＴｓｅｒｖｅｒからＮｕｔをフェッチし得る。
【０２５８】
[0255]Ｎｕｔに記憶された共有ウェブページコンテンツは、ユーザが、誰がコンテンツを閲覧し得るかを制御することを可能にし得、それは、暗号レベルで行われ得る。人は、ポスティングされたページを閲覧するためにコンテンツ所有者とのＲＢＫペアを有し得る。これは反社会的ソーシャルネットワーク、非公開ソーシャルネットワークおよび／または認証されたソーシャルネットワークであり得ると言うことができる。コンテンツのいずれも、ＮＵＴｎｅｔサーバまたは他の無認可のサードパーティがコンテンツのための鍵のいずれをも有しないことがあるので、ＮＵＴｎｅｔサーバまたは他の無認可のサードパーティによってマイニングされないことがある。コンテンツがＮｕｔに記憶され、セキュアにされ得る限り、所有者は、それの制御を保有し得る。所有者はまた、所有者のローカルＮｕｔストレージが同様にローカルにＮｕｔを複製し、同期させるように構成され得る場合、所有者のローカルＮｕｔストレージ中の、所有者のポスティングに関連する一部または全部の履歴を閲覧し得る。人は、親しい友人および家族の間で画像およびビデオを共有することがプライベートな事柄であり得、いかなるサードパーティも、発信者の知識および／または許可なしにそれらの使用のためにそれのコピーを所有する権利を有し得ないと感じるときがあり得る。ＮＵＴｎｅｔは、ユーザのグループ内のプライバシーを要求する状況のために作成され得る。
【０２５９】
[0256]プロ写真家は、莫大な量の詳細とともに、著作権のある写真を潜在的クライアントが閲覧するための非公開ウェブページをセットアップし、誰が鍵を発行され得るかと、どのくらいの時間の間かとを制御し得る。ウェブページＮｕｔは、写真家のための監査証跡を作成するために写真上の一部または全部のアクティビティをロギングし得る。プロジェクトマネージャは、プロジェクトのメンバーの間のアクティビティを協調させるために非公開ウェブページをセットアップし得る。セキュリティの観点から、登録プロセスは、Ｎｕｔに組み込まれたアクセス制御により、不要であり得るが、登録プロセスは、ＮＵＴｎｅｔサーバにおいて編成およびコンパートメント化機能として役立ち得る。
【０２６０】
ＮＵＴＳベースサービス：ＮＵＴｈｕｂ
[0257]現在、モノのインターネット（ＩｏＴ）がどのように通信し、および／または機能し得るかに関する普遍的に許容される標準がないことがある。ＩｏＴは、組込みネットワーキング能力を有し得るハードウェア製品の成長している領域であり得、ユーザが、様々な個人コンピューティングデバイスからリモートで製品の機能を制御し、モニタすることを可能にし得る。多くのＩｏＴ製品は、時々、製品のユーザ所有者に気づかれずに、製造ベンダーが収集し、分析するために、ＩｏＴ製品のセンサーからのデータの一定のストリームを製造ベンダーに送り得る。これらのＩｏＴデバイスの一部または全部の動作モードは、製品が人の自宅の最もプライベートな領域を対象とし得るので、それらのデータコレクション範囲および方法に基づいて多くのプライバシー侵害問題を引き起こし得る。何らかの使用を獲得するためのＩｏＴフレームワークが、それらの製品ファミリーについてＩｏＴハードウェアベンダーによって供給され得る。ＮＵＴｈｕｂは、Ｎｕｔｓのインターネット（ＩｏＮ）と呼ばれるＮＵＴＳ互換ＩｏＴタイプデバイスによって作成され得るＮｕｔベースメッセージの扱いを容易にするためのパケットフォワーディングサービスであり得る。図１５７上のネットワーク図に示されているように、ＩｏＮは、自宅でユーザのＩｏＮ互換デバイスとセキュアにおよび非公開で通信するためのＮＵＴＳベース標準であり得る。ＮＵＴｈｕｂ上のサービスの最も低いティアは、ＮＵＴＳベースサービスとの登録されたアカウントを有し得る誰にとっても利用可能であり得る。アカウントは匿名であり得る。ＮＵＴｈｕｂはＮｕｔとともに働き得、それは、ある量のメッセージをキューイングし得る。ＮＵＴｈｕｂは、追加のストレージにアクセスするためにＮＵＴｃｌｏｕｄおよび／またはＮＵＴｓｅｒｖｅｒとシームレスにインターフェースし得る。
【０２６１】
[0258]ＮＵＴｈｕｂトポロジーは、いくつかのやり方で働くように構成され得る。ユーザの自宅のあらゆるＩｏＮデバイスが、ＩｏＮベンダーサーバ１５８０４、ＮＵＴｈｕｂ１５８０２、ならびに／またはユーザ制御デバイス１５８０６、１５８２２および１５８２４への依存しない接続を行っていることがある直接トポロジーが図１５８に示されている。このトポロジーは、ベンダーが、ユーザの自宅のデバイスへのより直接的なアクセスを有することを可能にし得、ユーザは、各デバイスのフィルタ処理能力の範囲においてのみ、発信Ｎｕｔパケットをフィルタ処理し得、これは、今日ＩｏＴデバイスによって使用される通信の優勢な方法であり得る。
【０２６２】
[0259]好ましいＮＵＴｈｕｂトポロジーは、図１５９に示されているように間接的なトポロジーであり得る。一部または全部のＩｏＮデバイスが、ＬＡＮ１５９２０を出て、次いでＮＵＴｈｕｂ１５９０２をトラバースする前に、指定されたＮＵＴｓｅｒｖｅｒハブ１５９３０を通して通信し得る。このトポロジーは、アリスの快適レベルに基づいて、アリスの自宅を出たＩｏＮメッセージに関するフィルタ処理ルールの微調整を可能にし得る。ＮＵＴｓｅｒｖｅｒハブデバイス１５９３０は、デスクトップＰＣ、すなわち、専用アプライアンスを備えるか、さらには、ＷｉＦｉルータ１５９２０の一部であり得る。指定されたＮＵＴｓｅｒｖｅｒハブ１５９３０がオフであるかまたは利用不可能である場合、ＩｏＮデバイスは、外界と通信しないことがある。
【０２６３】
[0260]ＮＵＴｓｅｒｖｅｒハブの構成が図１６０に示されている。よく知っているＮＵＴｓｅｒｖｅｒ１５９３０内に、ＮＵＴｈｕｂ／ＩｏＮインターフェース１６０３２と呼ばれる構成要素があり得る。このモジュールは、ＮＵＴｈｕｂ１５９０２、ＩｏＮデバイス１５９２２および／または他のＮＵＴｓｅｒｖｅｒハブ１６０５２と通信することを担当し得る。インターフェースモジュール１６０３２は、ＩｏＮアプライアンスとＩｏＮ制御デバイスの両方からＩｏＮ  Ｎｕｔメッセージをロギングし、キューイングし、フォワーディングし、中継し、処理し、および／またはフィルタ処理し得る。
【０２６４】
[0261]ＮＵＴｈｕｂ／ＩｏＮインターフェースのより綿密な図が図１６１によって示されている。インターフェース１６０３２は、これらの７つの機能の一部または全部あるいは他の追加の機能を備え得る。ＩｏＮデバイスインデックス１６１１２は、ユーザによって登録された一部または全部のＩｏＮデバイスを追跡し得る。ＩｏＮデバイス認証１６１１４は、ＩｏＮデバイスへのおよびＩｏＮデバイスからのメッセージを認証し得、サイファ化し得る。インターフェースは、ユーザのメッセージフィルタおよびルール１６１１６を追跡し得る。メッセージロガー１６１１８は、一部または全部のＩｏＮメッセージを永続的なストレージにロギングし得る。メッセージキュー１６１２０は、配達不能メッセージを一時的に記憶し得る。デバイス鍵キャッシュ１６１２２は、ＩｏＮメッセージを認証し、サイファ化するための一部または全部のアクセス鍵を記憶し得、それは、利用可能な場合、保護されたメモリハードウェア内で具現され得る。遠隔制御インターフェース１６１２４は、ＩｏＮデバイス固有の機能がリモートでアクティブにされることを可能にし得るモジュールであり得る。
【０２６５】
[0262]任意のＩｏＮデバイス上のＮＵＴｈｕｂ／ＮＵＴｓｅｒｖｅｒ／ＩｏＴインターフェースのより綿密な図が図１６２によって示されている。インターフェース１６２１０は、一部または全部のこれらの７つの機能あるいは他の追加の機能を備え得る。Ｎｕｔインデックス１６２１２は、ＩｏＮデバイスを統制および管理することに関連するデバイスに記憶された一部または全部のＮｕｔを追跡し得る。認証モジュール１６２１４は、デバイスへの、ならびに／あるいはデバイスからベンダー、ＮＵＴｈｕｂおよび／またはＮＵＴｓｅｒｖｅｒハブへのメッセージを認証し得、サイファ化し得る。インターフェースは、ユーザのメッセージフィルタおよびルール１６２１６を追跡し得る。メッセージロガー１６２１８は、一部または全部のＩｏＮメッセージを永続的なストレージにロギングし得る。メッセージキュー１６２２０は、配達不能メッセージを一時的に記憶し得る。デバイス鍵キャッシュ１６２２２は、ＩｏＮメッセージを認証し、サイファ化するための一部または全部のアクセス鍵を記憶し得、それは、利用可能な場合、保護されたメモリハードウェア内で具現され得る。遠隔制御インターフェース１６２２４は、ＩｏＮデバイス固有の機能がリモートでアクティブにされることを可能にし得るモジュールであり得る。ＩｏＮデバイスは、それのハードウェア制限により、カスタムフィルタ処理のための機能の限られたセットを有し得る。ＩｏＮデバイスは、それがロギングし、キューイングし得るメッセージの量を制限し得るストレージ制限をも有し得る。したがって、履歴と監査証跡とが重要であり得る場合、ユーザは、図１５９に示されている間接ＩｏＮトポロジーを使用するように強く忠告され得、これは、ユーザが、ＮＵＴｓｅｒｖｅｒハブによって与えられ得る強化機能にアクセスすることを可能にし得る。このインターフェース１５９２２は、ＩｏＮ／ＩｏＴ固有デバイスに限定されず、任意のコンピューティングデバイスが、開発者がそれのためのインターフェースを作成し、ＩｏＮデバイスの動作モードに従い得る場合、同様のインターフェースを有し得、追加として、それの上で動作しているＮＵＴｓｅｒｖｅｒのバージョンを有し得る任意のデバイスが、ＩｏＮデバイス自体として働くことが可能であり得る。
【０２６６】
[0263]アリスがアリスの新しいＩｏＮデバイスを買ったとき、アリスは、それをアリスのネットワークに追加し、それを構成する必要があり得る。図１６３上のフローチャートは、アリスの新しいＩｏＮデバイスをアリスのＮＵＴＳベースネットワークに適切に登録するためにアリスがとり得るステップを示す。ＩｏＮデバイスを構成する方法は、アリスのＮＵＴｂｏｏｋを通してそれとのＲＢＫ関係を確立することであり得る。ステップ１６３０２および１６３０４は、ＮＵＴｓｅｒｖｅｒハブが、デバイス固有情報をアリスのＮＵＴｂｏｏｋに中継することを可能にし得、ＮＵＴｂｏｏｋは、ＩｏＮ／ＩｏＴデバイスカタログカードを作成し、モデル、バージョンおよび／または通し番号を埋め、ＲＢＫペアを発生し、それを、ＮＵＴｓｅｒｖｅｒハブを介してＩｏＮデバイスに送り得る。ＩｏＮデバイスのためのカタログカードを作成する行為は、Ｎｕｔを作成し得、これはそのＮｕｔのためのＮｕｔ  ＩＤを作成し得、したがって、ＩｏＮデバイスは、後で、それのカタログカードＮｕｔのＮｕｔ  ＩＤを転写され得る。このステップは、ユーザのホームネットワーク上の新しいデバイスのためのＩＰアドレスを選ぶことに似ていることがあるが、Ｎｕｔ  ＩＤを使用することの潜在的な利点は、広範囲にわたり得る。ＩｏＮデバイスのための割り当てられたＮｕｔ  ＩＤは、それの実際のＩＰアドレスおよび／またはロケーションにかかわらずデバイスを参照する永続的なやり方としても役立ち得る。ＩｏＮデバイスは、新しいＮｕｔ  ＩＤが新しいまたは同じ所有者によってそれの上に転写され得るように、工場状態にリセットされ得る。
【０２６７】
[0264]ＩｏＮカタログカードがアリスのＮＵＴｂｏｏｋ中にセーブされると、構成プロセスはステップ１６３０６に進み得、それは、デバイスの構成データを非サイファ化し、それを表示し、および／またはそれを設定するのに必要なＭＩＯ構成要素があり得るかどうかをチェックし得る。適切な設定が構成スクリーン上で行われると、アリスは、その設定をデバイスのためのアリスのＩｏＮカタログカードにセーブし得、それを、ＩｏＮデバイスに送られる１６３１４ようにＮＵＴｓｅｒｖｅｒハブインターフェースにサブミットし得る。デバイスは、構成Ｎｕｔを受信し得、それを認証し得、それを復号し得、それを妥当性確認し得、次いで、デバイスの内部システムに変更を適用し得る。完了すると、デバイスは、それのステータスを示すＮｕｔをＮＵＴｓｅｒｖｅｒハブに返送し得る。アリスはこのデバイスをモニタしていることがあり、アリスは、それからのメッセージを自動的に見得る。
【０２６８】
[0265]ＩｏＮデバイスは、一部または全部のメッセージがＮｕｔであり得、したがって、Ｎｕｔの同じレベルのプライバシーおよび制御をデフォルトで与えられ得るモードで動作し得る。ＮｕｔはＭＩＯ構成要素を利用し得るので、ソフトウェア構成、デバイスへのファームウェアおよび／またはソフトウェア更新は、同じＭＩＯＲ機構を通してサブミットされ得、旧式である潜在性が低くなり得る。ＮＵＴｈｕｂは、あらゆるものが、必要な場合、ユーザによってモニタされ、ロギングされ、および／または制御され得ることと、ＩｏＮデバイスによって収集され得る一部または全部の発信情報が、ユーザのプライバシー選好を受け取るためにフィルタ処理され得ることとをユーザに保証するように構成され得る。この実施形態では、ＮＵＴＳコア理念は、ユーザが所有するデバイスが一部または全部の時間においてユーザの制御下にあり得、それが発生し得る一部または全部のデータが同様にユーザのものであり得るように、物理デバイス中に拡張し得る。このシナリオにおいて、ＭＩＯおよびそれの機能のパワーは、適切なＭＩＯ構成要素をもつ任意のデータフォーマットが、多くのプロプライエタリプロトコルとは異なりユーザによって点検され得るので、明らかであり得る。
【０２６９】
[0266]これは、１６１２４および１６２２４に示されている遠隔制御インターフェースと呼ばれる重要なモジュールに導き得る。これは、ユーザまたはベンダーがＩｏＮ／ＩｏＴデバイスと会話し得、それを、コマンドＮｕｔと呼ぶコマンドにリモートで作用させ得る方法であり得る。ＲＢＫ認証されたコマンドＮｕｔが処理され得、デバイス所有者（ＲＡＴ）は、それの上で利用可能な任意のコマンドを実行し得る。この認証要件は、ユーザが、ベンダーのアクセス権利を調整することによって、ベンダーとのそれの関係を完全に制御することを可能にし得る。ユーザは、デバイスベンダーが、それへのフルアクセス、それのサブセットを有すること、および／またはアクセスを有しないことを可能にし得る。これは、ＩｏＮ／ＩｏＴデバイスをエントリポイントとして使用したアリスのホームネットワークへの無認可のアクセスを防ぎ得、各ＩｏＮ／ＩｏＴアクセスポイントは、今や、ＮＵＴＳベースセキュリティによって堅固にされ得る。Ｎｕｔがイントラネットおよび／またはインターネットに沿ってどのように伝搬され得、送られ得るかの広範な性質を述べていることがあるように、基本的に、ＩｏＮコマンドＮｕｔは、ＩｏＮデバイスへの適切なルートがあり得るどこからでも送られ得る。図１６４中のフローチャートは、遠隔制御インターフェースがコマンドＮｕｔをどのように処理し得るかを示す。
【０２７０】
[0267]ＮＵＴｈｕｂおよびそれの遠隔制御インターフェースの性質は、接続性があり得るどこからでも一部または全部のアリスのＮＵＴＳ互換デバイスを完全に制御するアリスのアビリティを生じ得る。それは、ＲＢＫペアによって表されるアリスのＮＵＴｂｏｏｋ関係によって制御されながらカスタムメッセージが送られ得るセキュアなプロトコルを提示し得る。それは、すべてのアリスのＩｏＮデバイスについてのアリスのための集中型ビューを提示し得るが、それは、非集中型様式でインストールされ、構成され、および／または保守され得る。アリスがアリスのＮｕｔを制御する場合、アリスは、一部または全部のアリスのデバイスを制御し得る。これは、アリスがＮＵＴＳのＳＳＯ能力を使用することを決定し得るとき、アリスが極めて慎重にアリスのパスフレーズを選定するかまたはハードウェアベース鍵を使用するべきである、別の理由であり得る。そのような実施形態では、ベンダーのロールは、ハードウェア製造業者のロールに抑えられ得、アリスに属し、アリスの自宅のプライベートな領域中に位置し得る個人デバイスの招かれていないリモートアドミニストレータのロールに抑えられないことがある。ＮＵＴＳ環境のセキュリティは、製造業者の（開発者の）選好および／または利点のほうへバイアスされ得る現在のＩｏＴプロトコルよりも、統一された、堅固にされた、および／またはユーザ制御可能なバリアを提示し得る。
【０２７１】
ＮＵＴＳベースサービス：ＮＵＴＳ証明サーバ
[0268]ＮＵＴｓｅｒｖｅｒプロセスおよびプロトコルの完全性は、それが予想されるように挙動し得ることを信頼することにとって不可欠であり得るので、継続的にＮＵＴｓｅｒｖｅｒインストールを妥当性確認するためのＮＵＴＳ証明サーバ（ＮＣＳ）があり得る。図１６５に描かれているように、ＮＣＳは、どんなＮＵＴＳユーザにとっても利用可能であり得、匿名登録、ペアワイズランダムエイリアス、および／またはＲＢＫをサポートし得る。それはティア化レベルのサービスを有し得、最も高いレベルが、「ＮＵＴＳ証明済み」であるものとしてのＮＣＳ会社による公式証明である。ＮＣＳの主な機能は、Ｎｕｔの適切な削除についてＮＵＴｓｅｒｖｅｒをモニタし、ならびに／あるいは、ＮＵＴｓｅｒｖｅｒプロトコル、挙動および／またはプロセスの無認可の検出することであり得る。賢いプログラマーはプローブを識別し得、それを迂回し得るので、匿名登録がどのように働くかのアーキテクチャは、ＮＵＴｓｅｒｖｅｒへのＮＣＳプローブがほぼ検出不可能であることを可能にし得る。それは、ユーザが彼らのＮＵＴｓｅｒｖｅｒ上でアクティブにすることを選定し得る自発的レベルのサービスであり得る。ターゲットＮＵＴｓｅｒｖｅｒにテストＮｕｔを注入し、ＮＵＴｓｅｒｖｅｒプロトコルに従っていくつかのアクションがそれらに適用されていることがあるかどうかを検出するためにＮＣＳによって始動される自動化された手続きがあり得る。より高いレベルのサービスにおいて、テスターによるアクティブな参加が、リモートＮＵＴｓｅｒｖｅｒの状態に関するさらにより周到な査定を可能にし得る。
【０２７２】
[0269]ベンダーは、ベンダーの顧客層に知らされ得るＮＵＴｓｅｒｖｅｒコンプライアンスのレベルを常に維持し、彼らのＮｕｔが相応に扱われていることがあることを彼らに保証するために、ＮＵＴＳ証明レベルテストにサブスクライブし得る。テストプロセスはまた、クライアントに気づかれていないクライアントのＮＵＴＳ環境の無認可の修正を強調し得る。クライアント側から、ＮＵＴＳシステムおよび方法論を使用中であることがあるが「ＮＵＴＳ証明済み」でないことがあるベンダーは、Ｎｕｔを扱うための彼らのポリシーに関するより多くの調査を必要とし得る。ユーザは、オンラインベンダーに関わるより前にそれらの証明ステータスまたはそれの欠如を査定するために、公的に入手可能なＮＣＳデータベース上のルックアップテーブルとインターフェースするように彼らのＮＵＴｓｅｒｖｅｒおよび／またはＮＵＴｂｏｏｋを構成し得る。
【０２７３】
[0270]図１６６では、ＮＣＳ１６５２０は、それが、リモートベンダーＮＵＴｓｅｒｖｅｒ（または個人ＮＵＴｓｅｒｖｅｒ）１６６２０〜１６６２４の挙動を査定することを可能にし得る機能を実施し得る。満了完全性プロービング１６６０２は、Ｎｕｔがシステムに注入され得１６６０４、満了時間の後のそのシステム上での存在について遠隔制御インターフェース１６６１０によってプローブされ得る方法であり得る。たとえば、満了したＮｕｔがリモートＮＵＴｓｅｒｖｅｒ上で見つけられた場合、ＮＵＴｓｅｒｖｅｒは、コンプライアンスに従っていないことがあり、「ＮＵＴＳ証明済み」でないことがある。長持続時間注入テスト１６６０８は、より長い時間量の間および継続的にＮＵＴｓｅｒｖｅｒをテストし得る。結果分析および証明１６６０６は、リモートＮＵＴｓｅｒｖｅｒの、様々な注入テストの順守を査定し得、ＮＵＴｓｅｒｖｅｒインストールに等級をつけ得る。インストールされたＮＵＴｓｅｒｖｅｒのバージョンとパッチバージョンとをチェックすることは、ＮＵＴｓｅｒｖｅｒが更新され、コンプライアンスに従い得ることを確かめることと一体であり得る。長く旧式のバージョンは、ＮＵＴＳセキュリティプロトコルおよび／または無認可のカスタム修正のいい加減な保守が行われていることがあり、したがって、採用がより遅くなり得ることを示し得る。また、テストは、限定はしないが、様々な機密性が高いバイナリコードセグメントのハッシュ署名をチェックすることおよび／または匿名インターネットアドレスから注入することを含み得る。ＮＵＴｓｅｒｖｅｒをＮＣＳサービスに匿名で登録することは、ＲＢＫがよりセキュアなやり方でのより深いテストのために設定され得ることを保証し得る。
【０２７４】
[0271]ＮＣＳは、十分な知識およびリソースをもつ人またはグループがＮＣＳによるテストを最終的に迂回し得るので、ＮＵＴｓｅｒｖｅｒが危殆化されていないことがあることを保証しないことがある。オンサイト点検は、より高いレベルのＮＵＴＳ証明を生じ得る。平均的ユーザの場合、最も高いレベルにおいて証明されていないことがある商業ＮＵＴｓｅｒｖｅｒと関わらないことが、良いポリシーであり得る。個人ＮＵＴｓｅｒｖｅｒと関わる場合、ＮＣＳからの自動無料テストのベースレベルが、それと関わるより前の最小要件であり得る。
【０２７５】
ＷｉＦｉ／イーサネットルータのためのＮＵＴＳベースネットワーキング
[0272]図１６７は、個人ＮＵＴＳベースＷｉＦｉ／イーサネットルータ１６７１０のためのネットワークレイアウトの一実施形態を示す。ルータは、ＷｉＦｉ通信に関与し得る通常プロトコルを使用して動作し、ならびに、Ｎｕｔベースメッセージングを代替プロトコルとして使用し得る。ＮＵＴＳ  ＷｉＦｉルータが、インストールされ、ＩｏＮデバイスのように構成され得、それにより、所有者は、それとのＲＢＫ関係を確立し、所有者のＮＵＴｂｏｏｋを介して所有者のＩｏＮカタログカードに情報を記憶し得る。構成プロセス中に、ユーザは、ユーザのデバイスの大部分がカタログカードエントリによって表され得るので、ユーザは、Ｎｕｔ  ＩＤによってルータ上に、ユーザがそれへのアクセスを可能にすることを希望し得る一部または全部のデバイスを登録することが可能であり得る。発信Ｎｕｔメッセージは、送信側デバイスのＮｕｔ  ＩＤを含んでいることがあり、したがって、アクセスのために登録リストに対して適切に吟味され得る。次いで、ルータは、様々なデバイスとそれ自体との間の関係を確立するように命令され得、したがって、ルータは、Ｎｕｔメッセージのコンテンツのためのセキュアな通信を可能にし得る。ＮＵＴＳ  ＷｉＦｉルータにおいてメッセージを処理するためのフローチャートが図１６８に示されている。登録されたデバイスによってルータを通過し得る一部または全部のメッセージが認証され得る。ステップ１６８１８は、ＮＵＴＳベースルータ上で利用可能であり得る興味深い特徴を示す。登録されていないデバイスが、ＲＢＫを使用しないアクセスのためにルータに接触し得る。これが行われたとき、それは、ＷｉＦｉアクセスの異なるカテゴリーについての帯域幅割振りおよび制限について所有者指定の構成設定、すなわち、登録された、ＩｏＴおよび／またはゲストをルックアップし得る。登録されたデバイスは、要求された使用法および帯域幅のタイプに対する制限なしで設定され得る。ＩｏＴ／ＩｏＮデバイスは、それら自体のカテゴリーを有し得、登録されたデバイスと同じレベルの認証を要求し得るが、グループとして別々に管理され得る。図１６９上の表は、定義されたカテゴリーと、ルータを通してそれらが有し得るアクセスのタイプとを示す。ゲストデバイスは、通常プロトコルを使用するが制約を伴うアクセスを与えられ得る。カテゴリーベース属性限界のための例示的な構成が図１７０に示されている。所有者は、限定はしないが、満期、帯域幅、アグリゲート帯域幅、カテゴリータイプの最大接続、宛先および／またはメッセージモードなど、デバイスごとの限界を指定し得る。このようにして、ゲストデバイスは、いくつかの限界内で未知のＮＵＴＳ  ＷｉＦｉルータを通したインターネットアクセスを有し得、認証されたＮＵＴＳイントラネットは、ＮＵＴＳレベルのセキュアな方法によって保護され得る。この方法論は、ＷｉＦｉ通信のフレームワーク内に別々に管理可能なチャネルカテゴリーを効果的に作成し得る。
【０２７６】
[0273]ユーザの一部または全部の登録されたデバイスは、今や、識別のために内部的に割り当てられたＩＰアドレスに依存しないことがあり、むしろ、カタログカードにおけるＮｕｔ  ＩＤによるものであり得る。これは、データおよびハードウェアをより普遍的な様式で一部または全部のネットワークにわたってより有形で機能的にするＮＵＴＳのプロパティであり得る。ルータは、登録されたデバイスのＮｕｔ  ＩＤに対してマッピングされた動的ＩＰアドレス割当てを追跡し得る。将来の反復および他の実施形態では、ハードウェア製造品は、Ｎｕｔ  ＩＤが、様々なデバイス上でイーサネットインターフェースにアクセスするためにＩＰアドレスおよび／またはＭＡＣアドレスと一緒に使用されることを可能にし得る。デバイスがＮｕｔ  ＩＤを識別することは、ＰＣ上のＯＳインストールにシステム名を割り当てることの等価物として考えられ得るが、それは、系統的で事実上一意であり得、したがって、イーサネットカードを変更することまたはそれをシステムに追加することは、新しいＩＰアドレスおよび／またはＭＡＣアドレスを提示し得るが、それは、デバイスに関連するＮｕｔ  ＩＤを変更しないことがある。
【０２７７】
[0274]子供のインターネットアクセスの親の監督は、デバイスレベルおよびユーザレベルにおいてではなく、またはそれらに加えて、ＮＵＴＳベースＷｉＦｉルータを使用するルータレベルにおいてモニタされ、制限され得る。登録されたデバイストラフィックを包み得るメッセージＮｕｔは、親の選好によってさらにトラフィックをフィルタ処理するために使用され得るユーザ識別情報を含み得る。
【０２７８】
Ｎｕｔを用いたアプリケーションラッピング
[0275]クラウドサービス、アプリストアおよび／またはそれの関連するアプリの出現および開発は、多様なデバイスにわたるアプリの何らかの形式のモジュール化および／または転送可能性を可能にしていることがある。しかしながら、これは、デスクトップまたはラップトップコンピュータには当てはまらないことがある。それらの上で動作し得るたいていのアプリケーションは、手動インストールおよび／または保守を要求し得る。これはまた、あらかじめ選択されたアプリパッケージの混合がマシンセットアップの容易さのためにシステムアドミニストレータによってカスタムインストールパックにロールアップされ得る、うまく維持された組織環境について当てはまり得る。または、それらは、コンピュータにスワップされ得るディスク上に、クローニングされたプレインストールされたアプリケーションを作成し得る。実行中の環境の場合、個人および／またはアドミニストレータが、特定のデバイス上にインストールされ得るあらゆるプログラムをモニタし、認可することは、極めて困難であり、難しいことがある。極めて厳しいアカウントルールは、ユーザについての減少された生産性またはシステム部門についての増加された人員要件につながり得る。
【０２７９】
[0276]うまく構築されたＮｕｔにおいてラッピングされたアプリケーションは、これらの問題の多くを解決し得る。ローカルオペレーティングシステムは、Ｎｕｔラッピングされたアプリケーションが動作することを可能にするためにのみ修正され得る。暗示は、多いことがあり得る。これは、承認されていないおよび吟味されていないアプリケーションの一部または全部の無認可のインストールおよび実行を防ぎ得る。ポリシーは、管理された組織環境におけるアクセス鍵の集中型アドミニストレーションによって執行され得る。むき出しの（naked）バイナリの実行を伴い得るウイルス感染ベクターは、大幅に低減され得る。ＮＵＴｓｅｒｖｅｒ複製および同期特徴は、一部または全部のデバイスにわたる、より新しいバージョンのインストールされたソフトウェアの容易な伝搬を可能にし得る。適切にラッピングされたＮｕｔは、同期が成功すると遠隔制御インターフェースを使用して自己インストールするようにリモートで指令され得る。デバイス環境バックアップおよび複写は、図１７１に示されているように、ＮＵＴｓｅｒｖｅｒを使用して自動化され得る。コンピューティングデバイス１７１００は、故障していることがあるデバイスのためのＮｕｔのバックアップを記憶し得る。新しいデバイス１７１４０をインストールの準備ができた状態にすると、適切にインストールされる必要があり得るアプリケーションは、ＮＵＴｓｅｒｖｅｒ１７１４４およびそれのアクセス鍵であり得る。次いで、正しい鍵をもついずれかのコンピューティングデバイスからの複写コマンドは、デバイス１からデバイス２に一部または全部の関連するＮｕｔをコピーすることを始動し得、次いで、一部または全部のＮｕｔラッピングされたアプリケーションの必要なインストールを実施し得る。
【０２８０】
[0277]表面的に、この方法は、ハードドライブをクローニングすることまたはうまく調達されたインストールスクリプトを有することとは異なるように見えないことがあるが、いくつかの著しい差があり得る。Ｎｕｔラッピングされたアプリケーションは、アプリケーションの仕様であり、特定のバイナリ自体でないことがある。バイナリは組織ＭＩＯＲに記憶され得、次いで、ＭＩＯ機構は、それが置き換えつつあることがある元のデバイスと同じであることも同じでないこともあるデバイスの現在のオペレーティングシステムのための正しいバージョンのアプリケーションをフェッチするために、Ｎｕｔラッピングされたアプリケーション仕様の開くプロセス中に引き継ぎ得る。ＭＩＯＲのこの使用は、異種オペレーティングシステムおよび／またはハードウェアを備えるコンピューティング環境内のアプリケーションバージョンを制御するやり方であり得る。ＮＵＴＳ技術の使用は、これらのプロセスの一部または全部がインターネットのどこからでも行われることを実際に可能にし得、したがって、新しいマシンが、リモート様式で組織に代わってインストールされ、保守され得る。
【０２８１】
[0278]これの一例は、１週間にわたる出張中のセールスパーソンが、自分がクライアント会議において使用することを希望していることがある２０個のカスタムプレゼンテーションおよび内密のクライアント報告を含んでいることがある自分のラップトップが盗まれていることがあることであり得る。その会社がＮＵＴＳを利用していたと仮定すると、セールスパーソンは、最も近いコンピュータストアに行き、システムアドミニストレータの案内の下で代わりのラップトップを買い得る。セールスパーソンは、次いで、そのラップトップ上にインターネットからダウンロードされた標準ＮＵＴｓｅｒｖｅｒをインストールし得る。アドミニストレータは、起源Ｎｕｔと呼ばれる特別に符号化されたアクセス／インストールＮｕｔを電子メールを介してセールスパーソンに送り得、セールスマンは、ウェブブラウザベース企業電子メールページから自分の新しいラップトップ上にこの起源Ｎｕｔをダウンロードし得る。アドミニストレータは、セールスマンに電話をかけ、起源Ｎｕｔをロック解除し得る秘密パスフレーズをセールスマンに告げ得る。ローカルＮＵＴｓｅｒｖｅｒ／ＮＵＴｂｒｏｗｓｅｒを使用してロック解除されると、起源Ｎｕｔは、企業サーバとのそれの直近の同期から、セールスマンの紛失したラップトップからのアプリケーションおよびデータを複写するために、インターネットにわたって必要な一部または全部のプロセスを始動し得る。バックアップにおけるデータの量に応じて、およそ数分から数時間で、セールスマンは、自分の新しいラップトップ上に再インストールされた一部または全部の自分の連絡先、アプリおよび／またはデータＮｕｔを用いて完全に活動可能であり得、それは、企業ＭＩＯＲが適切にシードされ、保守され得る限り、異なるブランドのラップトップおよび異なるオペレーションシステム上で行われ得る。この複写の労力に並行して、アドミニストレータは、万一窃盗犯がラップトップを起動してインターネットへの接続があった場合に、それに記憶された一部または全部の会社所有のＮｕｔについて自己削除コマンドを盗まれたラップトップに送り得る。これは、ラップトップ上のＮｕｔが企業Ｎｕｔ満了ポリシーを用いてすでに個々にセキュアにされ得るので、予防策であり得る。
【０２８２】
[0279]別の実施形態では、ハードウェア埋込みＮＵＴｓｅｒｖｅｒは、アクセス可能なソースＮＵＴｓｅｒｖｅｒおよびＭＩＯＲサーバを内部にもつネットワークへの接続を有し得る初期化されていないコンピューティングデバイスに統合され得る。起源Ｎｕｔは、デバイス上にロードされ、アクセスされ得、これは、ＯＳ、ドライバ、アプリケーション、アプリケーション構成データおよび／またはユーザデータを含むこの初期化されていないコンピューティングデバイス上へのコンピューティング環境の完全なインストールにつながり得るプロセスを始動し得る。ＯＳの選定は、デバイスと、アクセス可能なＭＩＯＲキャッシュのコンテンツとの検査時にユーザに委ねられ得る。アプリケーションは、ユーザのＮｕｔにアクセスするための要求されるアプリケーションの完全なリストについてソースＮＵＴｓｅｒｖｅｒを照会することによってユーザが異なるＮｕｔにアクセスするかまたは一度にすべてにアクセスするにつれて増分的にインストールされ得る。
【０２８３】
イベント処理サービス（ＥＰＳ）
[0280]ＮＵＴｈｕｂは、ＩｏＮ／ＩｏＴデバイスおよびＮＵＴｓｅｒｖｅｒとのＮｕｔベース通信を可能にし得る。イベント処理サービス（ＥＰＳ）は、図１７２に示されているように、イベントを発生するかまたはそれに反応することを希望し得るＩｏＮデバイスおよびアプリケーションによって生成され得るイベントをアーカイブするためのコーディネータとして機能し得る。一部または全部のイベントがＮｕｔ内に含まれていることがあるので、イベントは、トラバース可能なルートがデバイス間にあり得る限り、ネットワークにわたって通信され得る。これは、ユーザが、ローカルおよびリモートＩｏＮ／ＩｏＴデバイスならびに／またはＮＵＴｓｅｒｖｅｒシステムにおいて所望のイベントをモニタすることを可能にし得る。それは、ユーザが、ローカルおよび／またはリモートデバイス上で、スケジュールされたイベントまたはアドホックなイベントをトリガすることを可能にし得る。イベントは、それが望ましい場合、ユーザのデバイスの一部または全部にわたって複製され得る。ＥＰＳは、デバイス固有コマンドがイベントに基づいて始動されることを可能にするために遠隔制御インターフェースとともに働き得る。図１７２は、デバイス１７２００上のローカルカレンダーアプリケーション１７２０８が、デバイス１７２１０上のＮＵＴｓｅｒｖｅｒ１７２１２によって到達可能であり得るＩｏＮデバイス１７２２０上で実行されるようにローカルＥＰＳ１７２０４を通して時限イベントをトリガし得るシナリオを具現する。ローカルＥＰＳ１７２０４は、そのイベントを、ターゲットＩｏＮデバイス１７２２０へのアクセスを有し得る別のＥＰＳ１７２１４に中継し得る。次いで、ＥＰＳ１７２１４は、イベント／コマンドをそれのローカルＮＵＴｓｅｒｖｅｒ１７２１２に中継し得、次いで、ＮＵＴｓｅｒｖｅｒ１７２１２は、そのイベント／コマンドＮｕｔをＩｏＮデバイス１７２２０に受け渡すためにそれのＩｏＮ／ＩｏＴインターフェースを使用し得る。イベント／コマンドＮｕｔの受信時に、ＩｏＮデバイス１７２２０は、そのコマンドを認証し得、次いで、それをそれの遠隔制御インターフェースを介して実行し得る。そのようなイベントの例は、限定はしないが、スケジュール通りにリモートサーバを起動すること、スケジュール通りに電子メールを送ること、システムステータスに関するチャットメッセージを送ること、ＩｏＮ互換コーヒーマシン上で朝にコーヒーを入れること、スマートサーモスタット上の温度設定を変更すること、および／または、コーヒーが入れ終わっていることがある２０分後に寒い冬の朝に車の暖機運転を行うことと同じくらい変化に富むものであり得る。
【０２８４】
[0281]ＥＰＳは、それが実行中であることがある各デバイス上でそれが受信し、発生していることがある過去のイベントを、イベントＮｕｔストレージ領域１７２１６および１７２０６に記憶し得る。これは、通信およびデバイス故障のためのイベントリポジトリならびにイベントキューとして働き得る。ユーザまたはアドミニストレータは、後でこれらのイベントをブラウズし得、それを、その後の使用のために分析し得る。また、ＮＵＴｃｌｏｕｄアカウントをもつユーザは、イベントがどんなインターネットアクセスからも閲覧され得るように、ユーザのイベントをそれに複製されるようにし得る。一部または全部のイベントが、Ｎｕｔで保護され得、ユーザによって所有され得る。ＮＵＴｈｕｂは、ＥＰＳのキューイング能力を利用するためにそれとシームレスにインターフェースし得る。
【０２８５】
[0282]ＥＰＳおよびそれのリポジトリを利用する適用例の一例は、住宅警報システムが、それのバッテリー式センサーのうちのいくつかがバッテリー充電が低いことがあることを警告することを開始するときであり得る。住宅警報システムは、関与し得るユニットを指定する低バッテリーイベントを発生し得、警報保守会社とのサービスコールを要求し得る。警報会社は、それが問題に対応し得る様々な時間を電子メールを介してユーザに示唆し得、ユーザは、異なる時間示唆を行うか、またはそれらの示唆された時間を受け入れ得る。受入れ時に、警報会社上のカレンダーとユーザデバイス上のカレンダーの両方が、アポイントメント情報を用いて自動的に更新され得る。警報システムは、警報会社との限られたＲＢＫ関係を有し得、したがって、それは、セキュアな様式での住宅所有者の暗黙的承認を用いて診断を行い得る。
【０２８６】
アプリＮｕｔを用いたコンテキスト算出
[0283]限定はしないが、探索習慣、探索履歴、デバイス仕様、ウェブ閲覧習慣、ショッピング傾向、ブログコンテンツ、ソーシャルネットワーク、ビジネスネットワーク、電子メールコンテンツ、テクスティングメッセージ、写真、および／または、さらにはユーザのＤＮＡのデジタル分析など、ウェブ会社によるユーザのデジタル破片（detritus）の一部または全部の面についての平然とした強奪（land grab）があり得る。このユーザ発生されたデータの圧倒的大部分は、それを発生していることがあるユーザによって所有され、アクセスされ、レビューされ、変更され、削除され、および／または制御されないことがある。ＮＵＴＳ技術は、アプリ開発者がユーザ発生されたデータを記憶することをより容易にし得、それら自体の使用およびアーカイブのためにユーザにコピーを与えることをより容易にし得る。それは、カスタマイゼーションを可能にするためにＭＩＯを介してコンテンツフォーマット上で変動し得る共通のセキュアにされたコンテナを与え得る。ユーザのデジタルフットプリントのたいていの態様をカバーするのに十分に汎用的なウェブサービスベンダーはほとんどないことがあり、たとえば、Ａｍａｚｏｎはユーザのショッピング選好の一部のみを知り得、Ｇｏｏｇｌｅはユーザの探索履歴の一部のみを知り得る。したがって、ウェブベンダーは、一般に、彼らが与えるサービスに基づいて人の習慣の部分的スライスをアセンブルし得る。ユーザの一部または全部のデジタル所在およびアクティビティを収集する最良のバンテージポイントは、ユーザによる、ユーザのためのものであり得る。ベンダーが、ユーザまたはユーザの現在のセッションをタグ付けするためにローカルブラウザベースクッキーを使用し得、アプリからのおよびアプリ上の一部または全部のアクティビティを記録するために、ビッグデータを集めるサーバを使用し得る、ベンダーおよびユーザアプリのための一般的なネットワークレイアウトが図１７３に示されている。
【０２８７】
[0284]ユーザが、アプリ自体のアーカイブおよび使用のためにＮｕｔにおけるアプリのセッションの完全な記録を与え得るアプリとインターフェースする場合、ユーザは、図１７４に示されているように、ユーザのデジタル偏差の様々な面を集めることが最終的に可能であり得る。これらのセッション履歴は、図１７５に示されているように、ユーザにより多くの利便性を与えるためにコンテキスト依存（context sensitive）アプリによって分析が行われ得るコンテキストを与え得る。アプリケーションは、アプリＮｕｔ１７４１４中にそれのセッション履歴をセーブし得、これは、次には、適宜にユーザに利益を与えるために、ユーザがインストールしていることがある一部または全部の他のアプリによって使用され得る。コンテキストの適切な分析は、ユーザが達成することを希望し得るタスクのエッセンスを導出し得る。会計アプリ１７５２４は、ユーザが行っていることがある一部または全部の請求書支払いおよびアカウントチェックアクティビティについて、アプリＮｕｔ１７４１４にそれのセッションを記録し得る。そのようなセッション履歴を読み取り得るパターン認識アプリ１７５２０は、それを分析し、毎月の請求書を支払うためにとられる履歴ステップを推奨し得、それがユーザに代わってとり得るアクションのプレビューを提示し得る。ユーザがそれの分析に同意した場合、それは、ユーザの名前の下で様々なアカウントを使用して自動的に一部または全部の関連する請求書を支払うためにこれらのステップを実行し得る。このアプリＮｕｔは、ユーザがＮＵＴｃｌｏｕｄ１７５００を介してユーザのＮｕｔを同期させる場合、インターネットにわたってユーザにとって利用可能であり得る。
【０２８８】
[0285]アプリＮｕｔによってセーブされたコンテキストの別の有用な態様は、繰返し可能な手続きの態様であり得る。これは、要請に応じた随意の再実行のために前のコマンドがセーブされ得る場合に開発者が好み得るコマンドラインインターフェースの間の共通特徴であり得る。アプリＮｕｔは、ほぼすべての互換アプリ上でユーザについての要請に応じて同じタイプの手続き的呼び戻しを与え得る。コンテキスト記憶トラベルアプリが、ユーザによるウェブ上の初期探索の後にアプリＮｕｔにおいて、提案された旅行についての要件のエッセンスを与え得る。後で、ユーザは、一部または全部のユーザの好ましいトラベルコンセントに対するこの探索を、自動的に、コンテキスト依存トラベル探索アプリを使用して、それらに対して、抜き出された要件を再実行することによって再開し得る。これは、各トラベルウェブサイト上で異なるフォームに再び入力することに費やされる時間を緩和し得、一部または全部のユーザのオプションの自動概要を生成し得る。さらに、プロセスがユーザによって完全に制御され得、一部または全部の機密情報がユーザのＮＵＴｂｏｏｋによって記憶され得るので、ユーザがマイレージ特権および／またはメンバーシップを有し得るベンダーへの照会は、ユーザに対する最も個人化された有意味な結果を取得するためにコンテキスト依存トラベル探索アプリによって適切に適用され得る。このタイプの深いコンテキスト依存探索は、ユーザが、全面的に、一部または全部の時間において一部または全部のユーザの機密デジタル情報への束縛されないアクセスを単一のベンダーに与え得、そのベンダーを完全に信頼しない限り、単一のベンダーによって達成することがほぼ不可能であり得、これは、平均的なデジタル的に賢明なユーザにとって大いに疑わしい提案であり得る。
【０２８９】
[0286]別の実施形態では、図１７６は、ユーザのＩｏＮ／ＩｏＴデバイスと、自宅でのユーザの日常生活のためにユーザがサブスクライブし得る様々な効用およびサービスとのためのネットワークレイアウトを示す。単一の会社が、デジタル様式でユーザの自宅生活全体を収集することが可能でないことがある。しかしながら、ユーザは、一部または全部のユーザのデバイスがアプリＮｕｔを生成し、ユーザの様々なデジタルコンテキストを分析し得るアプリをユーザが有する場合、これを達成し得る。エネルギーを節約するコンテキスト依存アプリは、ユーザの自宅の様々な電子アプライアンスによる電気使用を分析し得、それを、ユーザに代わってアプリによって自動的に遂行され得るエネルギー節約測度を示唆するために電気会社のピークおよびオフピークレートとマージし得る。それは、それが過去からの状況のセットを認識するとき、ユーザのための好都合な組合せを協調させるために、各デバイスのユーザの個人使用習慣を分析し得る。ＩｏＮ／ＩｏＴデバイスは、周期的に実行される自己診断が、不合格になった部分または準最適な動作示度を曝露する場合、ユーザに保守要件を知らせ得る。
【０２９０】
[0287]ＩｏＴデバイスが、デバイスの所有者によって完全に制御されないことがあり、むしろ製造業者および／または潜在的違法行為ハッカーによって制御され得る、様々な環境センサーを含んでいることに関するセキュリティ懸念があり得る。図１７７は、２つのＩｏＮデバイスと、それらのそれぞれの製造業者とのネットワークレイアウトの一例を示す。アプリＮｕｔ１７７３４および１７７４４が各ＩｏＮデバイス１７７３０および１７７４０によって生成され得るとき、それは、ローカルストレージ１７７２４においてＮＵＴｓｅｒｖｅｒ１７７２２によってローカルにアーカイブされ得る。これらのアーカイブされたアプリＮｕｔは、サードパーティが収集するには不適切であるとユーザが見なす機密情報を除去するために、製造業者上にそれらを送る前に、ユーザによって後でレビューされ、フィルタ処理され得る。図１７８では、コンテキスト分析アプリ１７８０８は、サードパーティにユーザのプライバシーを知らずに露出することを最小限に抑えるために、一部または全部のユーザのＩｏＮ／ＩｏＴ生成されたメッセージの特殊なルーチンフィルタ処理を提供し得る。このようにして、サードパーティは、依然として、各所有者が可能にし得る範囲のみにおいて、販売された各デバイスから何らかのデータを集め得、したがって、サードパーティは、平均的買い手がどんな個人情報をサードパーティに与える意思があり得るかを推論し得る。
【０２９１】
結論および理念
[0288]詳述された様々な実施形態およびシナリオ例は、データが、データを発生したユーザに属し、ユーザが、正確にデータの露出を制御するための手段を有し得るという、コアＮＵＴＳ理念に基づき得る。設計は、限定はしないが、代替サイファ方法、異なる長さの鍵、異なるデータ変成、および／または異なるロッキング機構など、変形形態および／または代替形態に適応するのに十分にフレキシブルであり得る。ＳＤＦＴは、最も低いレベルにおいてデータを変成するための、プログラマーのための有用なツールセットを与え、ＮＵＴＳ構造と他の複雑な暗号構造とを構築するために構造化暗号プログラミングを可能にすることに役立ち得る。ＳＤＦＴは、フレキシブルで一般化されたやり方でそれの変成コマンドとペアリングされたデータの可搬性を可能にする。ＮＵＴＳの様々な実施形態は、既存の編成およびセキュリティインフラストラクチャに適合するようにカスタマイズされ得るか、または、それは、単一のユーザのためのスタンドアロンインストールであり得る。データの有形性は、ＮＵＴＳが提案し、実装し得る重要な理念、すなわち、最も洗練された管理されたシステムに適する特徴を提供しながら単純なやり方でユーザが発生し得るデータをユーザが記憶し、操作し、および／またはレビューするアビリティであり得る。結論として、ＮＵＴＳは、ユーザのデジタル作業およびデータを編成する現在の方法の代替を個人ユーザに与え得る。
【図１】
2019537769.tif 000004
【図２】
2019537769.tif 000005
【図３】
2019537769.tif 000006
【図４】
2019537769.tif 000007
【図５】
2019537769.tif 000008
【図６】
2019537769.tif 000009
【図７】
2019537769.tif 000010
【図８】
2019537769.tif 000011
【図９】
2019537769.tif 000012
【図１０】
2019537769.tif 000013
【図１１】
2019537769.tif 000014
【図１２】
2019537769.tif 000015
【図１３】
2019537769.tif 000016
【図１４】
2019537769.tif 000017
【図１５】
2019537769.tif 000018
【図１６】
2019537769.tif 000019
【図１７】
2019537769.tif 000020
【図１８】
2019537769.tif 000021
【図１９】
2019537769.tif 000022
【図２０】
2019537769.tif 000023
【図２１】
2019537769.tif 000024
【図２２】
2019537769.tif 000025
【図２３】
2019537769.tif 000026
【図２４】
2019537769.tif 000027
【図２５】
2019537769.tif 000028
【図２６】
2019537769.tif 000029
【図２７】
2019537769.tif 000030
【図２８】
2019537769.tif 000031
【図２９】
2019537769.tif 000032
【図３０】
2019537769.tif 000033
【図３１】
2019537769.tif 000034
【図３２】
2019537769.tif 000035
【図３３】
2019537769.tif 000036
【図３４】
2019537769.tif 000037
【図３５】
2019537769.tif 000038
【図３６】
2019537769.tif 000039
【図３７】
2019537769.tif 000040
【図３８】
2019537769.tif 000041
【図３９】
2019537769.tif 000042
【図４０】
2019537769.tif 000043
【図４１】
2019537769.tif 000044
【図４２】
2019537769.tif 000045
【図４３】
2019537769.tif 000046
【図４４】
2019537769.tif 000047
【図４５】
2019537769.tif 000048
【図４６】
2019537769.tif 000049
【図４７】
2019537769.tif 000050
【図４８】
2019537769.tif 000051
【図４９】
2019537769.tif 000052
【図５０】
2019537769.tif 000053
【図５１】
2019537769.tif 000054
【図５２】
2019537769.tif 000055
【図５３】
2019537769.tif 000056
【図５４】
2019537769.tif 000057
【図５５】
2019537769.tif 000058
【図５６】
2019537769.tif 000059
【図５７】
2019537769.tif 000060
【図５８】
2019537769.tif 000061
【図５９】
2019537769.tif 000062
【図６０】
2019537769.tif 000063
【図６１】
2019537769.tif 000064
【図６２】
2019537769.tif 000065
【図６３】
2019537769.tif 000066
【図６４】
2019537769.tif 000067
【図６５】
2019537769.tif 000068
【図６６】
2019537769.tif 000069
【図６７】
2019537769.tif 000070
【図６８】
2019537769.tif 000071
【図６９】
2019537769.tif 000072
【図７０】
2019537769.tif 000073
【図７１】
2019537769.tif 000074
【図７２】
2019537769.tif 000075
【図７３】
2019537769.tif 000076
【図７４】
2019537769.tif 000077
【図７５】
2019537769.tif 000078
【図７６】
2019537769.tif 000079
【図７７】
2019537769.tif 000080
【図７８】
2019537769.tif 000081
【図７９】
2019537769.tif 000082
【図８０】
2019537769.tif 000083
【図８１】
2019537769.tif 000084
【図８２】
2019537769.tif 000085
【図８３】
2019537769.tif 000086
【図８４】
2019537769.tif 000087
【図８５】
2019537769.tif 000088
【図８６】
2019537769.tif 000089
【図８７】
2019537769.tif 000090
【図８８】
2019537769.tif 000091
【図８９】
2019537769.tif 000092
【図９０】
2019537769.tif 000093
【図９１】
2019537769.tif 000094
【図９２】
2019537769.tif 000095
【図９３】
2019537769.tif 000096
【図９４】
2019537769.tif 000097
【図９５】
2019537769.tif 000098
【図９６】
2019537769.tif 000099
【図９７】
2019537769.tif 000100
【図９８】
2019537769.tif 000101
【図９９】
2019537769.tif 000102
【図１００】
2019537769.tif 000103
【図１０１】
2019537769.tif 000104
【図１０２】
2019537769.tif 000105
【図１０３】
2019537769.tif 000106
【図１０４】
2019537769.tif 000107
【図１０５】
2019537769.tif 000108
【図１０６】
2019537769.tif 000109
【図１０７】
2019537769.tif 000110
【図１０８】
2019537769.tif 000111
【図１０９】
2019537769.tif 000112
【図１１０】
2019537769.tif 000113
【図１１１】
2019537769.tif 000114
【図１１２】
2019537769.tif 000115
【図１１３】
2019537769.tif 000116
【図１１４】
2019537769.tif 000117
【図１１５】
2019537769.tif 000118
【図１１６】
2019537769.tif 000119
【図１１７】
2019537769.tif 000120
【図１１８】
2019537769.tif 000121
【図１１９】
2019537769.tif 000122
【図１２０】
2019537769.tif 000123
【図１２１】
2019537769.tif 000124
【図１２２】
2019537769.tif 000125
【図１２３】
2019537769.tif 000126
【図１２４】
2019537769.tif 000127
【図１２５】
2019537769.tif 000128
【図１２６】
2019537769.tif 000129
【図１２７】
2019537769.tif 000130
【図１２８】
2019537769.tif 000131
【図１２９】
2019537769.tif 000132
【図１３０】
2019537769.tif 000133
【図１３１】
2019537769.tif 000134
【図１３２】
2019537769.tif 000135
【図１３３】
2019537769.tif 000136
【図１３４】
2019537769.tif 000137
【図１３５】
2019537769.tif 000138
【図１３６】
2019537769.tif 000139
【図１３７】
2019537769.tif 000140
【図１３８】
2019537769.tif 000141
【図１３９】
2019537769.tif 000142
【図１４０】
2019537769.tif 000143
【図１４１】
2019537769.tif 000144
【図１４２】
2019537769.tif 000145
【図１４３】
2019537769.tif 000146
【図１４４】
2019537769.tif 000147
【図１４５】
2019537769.tif 000148
【図１４６】
2019537769.tif 000149
【図１４７】
2019537769.tif 000150
【図１４８】
2019537769.tif 000151
【図１４９】
2019537769.tif 000152
【図１５０】
2019537769.tif 000153
【図１５１】
2019537769.tif 000154
【図１５２】
2019537769.tif 000155
【図１５３】
2019537769.tif 000156
【図１５４】
2019537769.tif 000157
【図１５５】
2019537769.tif 000158
【図１５６】
2019537769.tif 000159
【図１５７】
2019537769.tif 000160
【図１５８】
2019537769.tif 000161
【図１５９】
2019537769.tif 000162
【図１６０】
2019537769.tif 000163
【図１６１】
2019537769.tif 000164
【図１６２】
2019537769.tif 000165
【図１６３】
2019537769.tif 000166
【図１６４】
2019537769.tif 000167
【図１６５】
2019537769.tif 000168
【図１６６】
2019537769.tif 000169
【図１６７】
2019537769.tif 000170
【図１６８】
2019537769.tif 000171
【図１６９】
2019537769.tif 000172
【図１７０】
2019537769.tif 000173
【図１７１】
2019537769.tif 000174
【図１７２】
2019537769.tif 000175
【図１７３】
2019537769.tif 000176
【図１７４】
2019537769.tif 000177
【図１７５】
2019537769.tif 000178
【図１７６】
2019537769.tif 000179
【図１７７】
2019537769.tif 000180
【図１７８】
2019537769.tif 000181
【国際調査報告】
2019537769.tif 000182
2019537769.tif 000183
2019537769.tif 000184