知財求人 - 知財ポータルサイト「IP Force」
特表2024-527556完全性保護のためのハッシュツリーを使用した階層データ構造中のデータの符号化
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-07-25
(54)【発明の名称】完全性保護のためのハッシュツリーを使用した階層データ構造中のデータの符号化
(51)【国際特許分類】
H04L 9/32 20060101AFI20240718BHJP
G06F 16/28 20190101ALI20240718BHJP
【ＦＩ】
H04L9/32 200A
H04L9/32 200E
G06F16/28
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023580769
(86)(22)【出願日】2022-07-01
(85)【翻訳文提出日】2023-12-28
(86)【国際出願番号】 EP2022068316
(87)【国際公開番号】W WO2023280721
(87)【国際公開日】2023-01-12
(31)【優先権主張番号】63/218,525
(32)【優先日】2021-07-06
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】21207844.8
(32)【優先日】2021-11-11
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＶＥＲＩＬＯＧ
(71)【出願人】
【識別番号】590000248
【氏名又は名称】コーニンクレッカ フィリップス エヌ ヴェ
【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ．
【住所又は居所原語表記】Ｈｉｇｈ Ｔｅｃｈ Ｃａｍｐｕｓ ５２， ５６５６ ＡＧ Ｅｉｎｄｈｏｖｅｎ，Ｎｅｔｈｅｒｌａｎｄｓ
(74)【代理人】
【識別番号】110001690
【氏名又は名称】弁理士法人Ｍ＆Ｓパートナーズ
(72)【発明者】
【氏名】ガルシア モーション オスカー
(72)【発明者】
【氏名】チャン イー ヒム
【テーマコード（参考）】
5B175
【Ｆターム（参考）】
5B175KA04
5B175KA11
(57)【要約】
いくつかの実施形態はデータ構造を対象とする。データ構造は複数のブロックと第１のハッシュツリーの一部とを含む。ハッシュツリーは複数のゲノムブロックの複数のハッシュ値から計算される。第１のハッシュツリーの一部は、第１のハッシュツリーの少なくとも最初の２つの最も高いレベルを含むが、第１のハッシュツリーの１つ又は複数のより低いレベルを含まない。
【特許請求の範囲】
【請求項1】
データ構造中のデータを符号化するための符号化システムであって、前記符号化システムは、前記データを受信するための入力インターフェースと、
プロセッサシステムとを備え、前記プロセッサシステムが、
前記データを複数のデータブロックとして取得することと、
前記複数のデータブロックにハッシュ関数を適用することによって、前記複数のデータブロックのための複数のハッシュ値を計算することと、
前記複数のハッシュ値についての第１のハッシュツリーを計算することであって、前記複数のハッシュ値が前記第１のハッシュツリーのリーフに割り当てられ、前記第１のハッシュツリーの１つ又は複数のより高いレベルが生成される、第１のハッシュツリーを計算することと、
前記データ構造中に前記複数のデータブロックと前記第１のハッシュツリーの全部又は一部とを含めることであって、前記第１のハッシュツリーの前記一部が前記第１のハッシュツリーの前記リーフの少なくとも一部を含まない、前記データ構造中に前記複数のデータブロックと前記第１のハッシュツリーの全部又は一部とを含めることと
を行う、符号化システム。
【請求項2】
前記プロセッサシステムが第２のハッシュツリーを計算することであって、前記第１のハッシュツリーのルートが前記第２のハッシュツリーのリーフに割り当てられ、複数のさらなるハッシュ値が前記第２のハッシュツリーの複数のさらなるリーフに割り当てられ、さらなるハッシュ値が、さらなるハッシュツリーのルートとして生成される及び／又はさらなるデータブロック上でのハッシングによって生成される、第２のハッシュツリーを計算することと、前記プロセッサシステムが前記データ構造中に前記第２のハッシュツリーの少なくとも前記ルートを含めることとを行う、請求項１に記載の符号化システム。
【請求項3】
前記データ構造が、コンテナの階層中に編成されたデータブロックを含み、前記プロセッサシステムが前記階層中の各コンテナのためのハッシュツリーを計算し、ハッシュツリーの各リーフが、前記コンテナ内のデータブロックの前記ハッシュ値、又は下位のコンテナに対応するハッシュツリーの前記ルートのいずれかである、請求項１又は２に記載の符号化システム。
【請求項4】
前記プロセッサシステムが、ハッシュツリーのルート、特に、ハッシュツリーのリーフの間のハッシュツリールートを有するハッシュツリーの前記ルートにわたるデジタル署名を計算することと、前記デジタル署名を前記データ構造中に含めることとを行う、請求項１から３のいずれか一項に記載の符号化システム。
【請求項5】
前記プロセッサシステムが、前記データ構造を記憶すること及び／又は前記データ構造若しくは前記データ構造の一部をストリーミングすることを行い、前記データ構造の前記一部が、前記データブロックの少なくとも一部と、前記データブロックに対応するハッシュツリーの少なくとも一部とを含む、請求項１から４のいずれか一項に記載の符号化システム。
【請求項6】
前記複数のデータブロック及び／又はデータコンテナのサブセットが完全性保護付きと標示され、前記複数のデータブロック及び／又はデータコンテナの残りが、完全性保護なしと標示され、完全性保護付きと標示された部分のみがハッシュツリー中に含まれる、請求項１から５のいずれか一項に記載の符号化システム。
【請求項7】
前記入力インターフェースが１つ又は複数のツリーパラメータを受信し、前記プロセッサシステムが、前記１つ又は複数のツリーパラメータに応じて、１つのハッシュツリー又はハッシュツリーの階層から選択されたノードのセットを前記データ構造中に含める、請求項１から６のいずれか一項に記載の符号化システム。
【請求項8】
前記入力インターフェースが前記データに対する修正を受信し、前記修正が、追加、削除、及び／又は変更のうちの１つ又は複数を含み、前記プロセッサシステムが、前記修正を適用することと、前記データの修正された前記一部に対応するハッシュツリーの一部を選択的に再計算し、更新することとを行う、請求項１から７のいずれか一項に記載の符号化システム。
【請求項9】
ハッシュツリーのリーフが、非圧縮形態のデータブロックのハッシュと、圧縮形態の前記データブロックのハッシュとをさらに含み、前記データブロックが圧縮形態で前記データ構造中に含まれるか、又は、ハッシュツリーのリーフが、非圧縮及び非暗号化形態のデータブロックのハッシュと、圧縮及び非暗号化形態の前記データブロックのハッシュと、圧縮及び暗号化形態のデータブロックのハッシュとをさらに含み、前記データブロックが圧縮及び暗号化形態で前記データ構造中に含まれる、
請求項１から８のいずれか一項に記載の符号化システム。
【請求項10】
データ構造中の選択されたデータを検証するための検証システムであって、前記検証システムは、前記データ構造の少なくとも一部を受信するための入力インターフェースであって、前記データ構造が、複数のデータブロックとハッシュツリーの一部とを含み、第１のハッシュツリーのリーフの少なくとも一部を含まない、入力インターフェースと、
プロセッサシステムとを備え、前記プロセッサシステムが、
データ完全性検証のために選択された前記データ構造中のデータブロックにハッシュ関数を適用することによって、選択された前記データブロックのための複数のハッシュ値を計算することと、
検証のために選択されたデータブロックから始まる、対応するハッシュツリーのルートまでの経路を特定することと、
前記データ構造中で利用可能な場合に、前記経路に沿った前記ハッシュツリーのための前記ハッシュ値を取り出すこと、又はそのような前記ハッシュ値を計算することと、
少なくとも計算された前記複数のハッシュ値から前記ハッシュツリーの前記ルートを検証することと
を行う、検証システム。
【請求項11】
前記データ構造がハッシュツリーの階層を含み、前記プロセッサシステムが、リーフから始まる、ハッシュツリーの前記階層のルート全体までの経路を特定する、請求項１０に記載の検証システム。
【請求項12】
前記符号化及び／又は検証システムがデバイスである、請求項１から１１のいずれか一項に記載の符号化及び／又は検証システム。
【請求項13】
前記複数のデータブロックがゲノムデータを含む、請求項１から１２のいずれか一項に記載の符号化及び／又は検証システム。
【請求項14】
データ構造中のデータを符号化するための符号化方法であって、前記符号化方法は、前記データを複数のデータブロックとして取得するステップと、
前記複数のデータブロックにハッシュ関数を適用することによって、前記複数のデータブロックのための複数のハッシュ値を計算するステップと、
前記複数のハッシュ値についての第１のハッシュツリーを計算するステップであって、前記複数のハッシュ値が前記第１のハッシュツリーのリーフに割り当てられ、前記第１のハッシュツリーの１つ又は複数のより高いレベルが生成される、第１のハッシュツリーを計算するステップと、
前記データ構造中に前記複数のデータブロックと前記第１のハッシュツリーの一部とを含めるステップであって、前記第１のハッシュツリーの前記一部が前記第１のハッシュツリーの前記リーフの少なくとも一部を含まない、前記データ構造中に前記複数のデータブロックと前記第１のハッシュツリーの一部とを含めるステップと
を有する、符号化方法。
【請求項15】
データ構造中の選択されたデータを検証するための検証方法であって、前記検証方法は、前記データ構造の少なくとも一部を受信するステップであって、前記データ構造が、複数のデータブロックとハッシュツリーの一部とを含み、第１のハッシュツリーのリーフの少なくとも一部を含まない、前記データ構造の少なくとも一部を受信するステップと、
データ完全性検証のために選択された前記データ構造中のデータブロックにハッシュ関数を適用することによって、選択された前記データブロックのための複数のハッシュ値を計算するステップと、
検証のために選択されたデータブロックから始まる、対応するハッシュツリーのルートまでの経路を特定するステップと、
前記データ構造中で利用可能な場合に、前記経路に沿った前記ハッシュツリーのための前記ハッシュ値を取り出すステップ、又はそのような前記ハッシュ値を計算するステップと、
少なくとも計算された前記複数のハッシュ値から前記ハッシュツリーの前記ルートを検証するステップと
を有する、検証方法。
【請求項16】
前記データ構造がハッシュツリーの階層を含み、前記検証方法は、リーフから始まる、ハッシュツリーの前記階層のルート全体までの経路を特定するステップを有する、請求項１５に記載の検証方法。
【請求項17】
プロセッサシステムによって実行されたときに、前記プロセッサシステムに請求項１４及び／又は１５に記載の方法を実行させる命令を表すデータを含む、一時的又は非一時的コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
開示されている本主題は、デジタルデータ構造中のゲノムデータを符号化するための符号化システムと、デジタルデータ構造中の選択されたゲノムデータを検証するための検証システムと、デジタルデータ構造中のゲノムデータを符号化するための符号化方法と、デジタルデータ構造中の選択されたゲノムデータを検証するための検証方法と、コンピュータ可読媒体とに関する。
【背景技術】
【0002】
ゲノムデータの量は絶えず増加しているので、そのような情報が適切なデータ構造中に記憶されることが重要である。参照によって本明細書中に含まれるＩＳＯ／ＩＥＣ２３０９２は、ゲノムデータを符号化し、圧縮し、保護するための規格を定義している。特に、同様に参照によって本明細書中に含まれるＩＳＯ／ＩＥＣ ＤＩＳ２３０９２－１、「Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ－Ｇｅｎｏｍｉｃ ｉｎｆｏｒｍａｔｉｏｎ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ－Ｐａｒｔ １：Ｔｒａｎｓｐｏｒｔ ａｎｄ ｓｔｏｒａｇｅ ｏｆ ｇｅｎｏｍｉｃ ｉｎｆｏｒｍａｔｉｏｎ」は、ゲノム情報を記憶及び／又はストリーミングするためのデータ構造を定義している。
【0003】
知られているデータ構造は、ゲノムデータ、例えばシーケンスデータを記憶し、そのゲノムデータに関係する他の情報に関連付けることができる階層データ構造を開示している。例えば、ＩＳＯ／ＩＥＣ ＤＩＳ２３０９２－１の表４はフォーマット構造と階層カプセル化レベルとを開示している。表４は、様々なタイプのデータのためのボックスと、それらの可能な格納とを示している。
【0004】
ゲノムデータについてのファイルは非常に大きくなり得る。サイズは、数百ギガバイト、又はテラバイトにもなり得る。従来の完全性測定は、そのように多くのデータにわたって計算するのに長い時間がかかる。
【発明の概要】
【発明が解決しようとする課題】
【0005】
より良い完全性制御を可能にする、ゲノムデータのための改善されたデータ構造を有することが有利である。例えば、上述のＩＳＯ／ＩＥＣ２３０９２は、特にファイル全体について、ファイルの完全性の証拠を効率的に与えるすべてのデータ構造を一緒にグループ化するやり方について説明していない。また、完全性を考慮に入れながら、データ構造をファイルに追加すること又はファイルから削除すること、或いはゲノムファイルを更新することは実現不可能である。ファイルがどのように更新されるか、又はそれらの変更について誰が責任を負うのかを追跡することはない。ゲノムデータは、ユーザのヘルスケアデータだけでなく、彼／彼女の子孫のヘルスケアデータにも関係するので、長期間にわたってゲノムデータの完全性を保護することが有利である。選択的なデータ構成要素上の個々のデジタル署名を使用することは、この目的のためには十分でない。例えば、そのことはデータ構造間の関係を保護しない。攻撃者は、構成要素を削除すること、又はそれらの順序を変更することがある。これらの問題のいずれも個々に対処するに値する。他の問題について、本明細書で特定し、対処する。
【課題を解決するための手段】
【0006】
いくつかの実施形態はデジタルデータ構造を対象とする。データ構造は複数のゲノムブロックと第１のハッシュツリーの一部とを含む。ハッシュツリーは複数のゲノムブロックの複数のハッシュ値から計算される。第１のハッシュツリーの含められた一部はノードの選択されたサブセットを含み、ノードの選択されたサブセットは、ノードの最も高い１つ又は複数のレベルと、第１のハッシュツリーの選択された数のリーフとの組合せであり得る。第１のハッシュツリーは、データ構造中に現れる第１のハッシュツリーである必要はないことを理解されたい。
【0007】
ゲノムデータは、一般に大きく、階層的でもあるので、特に有利な適用例である。しかしながら、実施形態は、任意のタイプのデータ、特に階層的に編成されたデータに適用することができる。多くの実施形態についてゲノムデータのコンテキストにおいて説明するが、本発明はゲノムデータに限定されない。
【0008】
一般に、ハッシュツリー又はマークルツリー（Ｍｅｒｋｌｅ Ｔｒｅｅ）は、リーフノードの各々が、データのデータブロックのハッシュ、又は下位コンテナのハッシュツリーのルートを含み、非リーフノードが、次に低いレベルにあるノードにわたるハッシュを含み、後者のノードがリーフノード又は非リーフノードであり得る、ツリー構造である。ハッシュツリーの特殊なタイプはＶｅｒｋｌｅツリーであり、内部ノード（非リーフノード）をそれの子ノードから計算するために使用されるハッシュ関数は正則ハッシュではなく、ベクトルコミットメントである。実施形態は、正則ハッシュ、特に、ＳＨＡファミリー、例えばＳＨＡ－３など、マークル－ダンガード（Ｍｅｒｋｌｅ－Ｄａｍｇａｒｄ）タイプのハッシュ関数（ＭＤ－タイプ）を使用することがある。Ｖｅｒｋｌｅタイプツリーのリーフは、例えばＭＤ－タイプの正則ハッシュ関数を使用する。Ｖｅｒｋｌｅツリーのさらなる説明は、Ｋｕｓｚｍａｕｌによる文書「Ｖｅｒｋｌｅ Ｔｒｅｅｓ」、Ｔｅｃｈｎｉｃａｌ ｒｅｐｏｒｔ； Ｍａｓｓａｃｈｕｓｅｔｔｓ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｔｅｃｈｎｏｌｏｇｙ： Ｃａｍｂｒｉｄｇｅ、ＭＡ、ＵＳＡ、２０１８中に見つけることができる。複数のゲノムデータブロックが、例えばゲノムデータのパーティションとして受信されていることがある。例えば、一実施形態では、ゲノムシーケンス及び／又は他のゲノムデータなど、ゲノムデータが受信される。ゲノムデータは、すでにブロックに区分されていることもあり、符号化システムによってブロックに分割されることもある。
【0009】
トップレベル部分を含めることによって、迅速な検証又は更新が維持されるが、より低いレベル部分を含めないことによって、ストレージサイズが低減される。含められなかったより低いレベル部分は、リーフの一部、すべてのリーフ、又はいくつかのより低いレベルでさえあり得る。
【0010】
一実施形態では、データ構造は階層データ構造である。より高いレベルにあるブロックは、より低いレベルにある複数のブロックを指すことがある。より高いレベルのブロックは、より低いレベルにわたって計算されたハッシュツリーの一部を含み得る。このことは２回以上起こり得る。例えば、第１のレベルは、第２のより低いレベルにあるブロックにわたって計算されたハッシュツリーの一部を含む。第２のレベルは、第３のより低いレベルにあるブロックにわたって計算されたハッシュツリーの一部を含み、以下同様である。第１のレベルは、第２のより低いレベルにある他のブロックにわたって計算された別のハッシュツリーの一部を含み得る。
【0011】
データ構造又はそれの一部は、記憶され、取り出され、ストリーミングされ、受信され、符号化され、検証される。データ構造をストリーミングするときに、含められなかった一部が再計算され、ストリーミング中に含められることがある。データ構造をストリーミングするとき、ストリーミングは、選択されたゲノムデータブロックと、ストリーミングされないデータにアクセスすることなしにハッシュツリーのルートを再計算するために必要とされるハッシュツリーの一部とのみを含み得る。
【0012】
一実施形態では、ハッシュツリーが全部記憶されない。このことはまた、複数のレベルにわたって起こり得る。興味深いことに、第１のレベルは第２のより低いレベルのための部分的なハッシュツリーを含み、第２のレベルも、より低い第３のレベルのための部分的なハッシュツリーを含んでいる。部分的に含められたハッシュツリーの階層が構築される。一実施形態では、ツリーパラメータが受信される。含められているハッシュツリーの一部のサイズはツリーパラメータから決定される。例えば、ツリーパラメータは、含めるべきレベルの数である。一実施形態では、ツリーパラメータは２以上である。
【0013】
ハッシュツリーの他の態様、例えば、ノードごとの子ノードの数、すなわちｋ進性（ｋ－ａｒｙｎｅｓｓ）もツリーパラメータによって設定される。
【0014】
一態様は、例えば、符号化システムの一実施形態によって符号化される、データ構造中の選択されたデータを検証するための検証システムである。検証は、ハッシュツリーのルートを検証することによって行われる。これは、一般に、ルートを再計算することによって行われる。とはいえ、より高度のタイプのハッシュツリー、例えばＶｅｒｋｌｅツリーの場合、非対称アルゴリズムが使用される。ハッシュを再計算するか、さもなければ検証するために、ハッシュツリーの一部がデータ構造から取り出されるか、又は再計算されるかのいずれかである。例えば、リーフ値はないことがあり、再計算されることがある。より低いレベル（又はそれの一部）のうちのいくつかは、データ構造中にないこともあり、再計算されることもある。しかしながら、いくつかのハッシュ値は、データ構造中に存在することがあり、取り出すことができる。どの値が必要とされるかを決定するために、検証のために選択されたデータブロックから始まる、対応するハッシュツリーのルートまでの経路が特定される。ルートの事前計算、及び／又は検証のために必要とされる、経路に沿ったハッシュツリーのためのハッシュ値は、経路上のノードの値を含むだけでなく、経路上のノードの子ノードをも含む。興味深いことに、ルートは、検証されるデータブロックに直接関連付けられたハッシュツリー、例えば、それのリーフ中のデータブロックのハッシュ値を含むハッシュツリー、例えば第１のハッシュツリーのルートであり得るが、代わりに（又は同様に）階層的により高いハッシュツリー、例えば第２のハッシュツリーのルートであり得る。ルートが再計算されると、それをデータ構造中のルートと比較することができる。他のタイプの検証は、ルートにわたって署名を検証すること、又はＶｅｒｋｌｅツリーの場合と同様に、ベクトルコミットメント検証を実行することを含む。
【0015】
符号化システムは、場合によっては、１つ又は複数の電子デバイス中に実装される電子システムであり得る。検証システムは、場合によっては、１つ又は複数の電子デバイス中に実装される電子システムであり得る。
【0016】
さらなる態様は符号化方法及び検証方法である。本方法の一実施形態は、コンピュータ実装方法としてコンピュータ上に実装されるか、又は専用のハードウェアにおいて、又は両方の組合せにおいて実装される。本方法の一実施形態のための実行可能コードはコンピュータプログラム製品上に記憶される。コンピュータプログラム製品の例としては、メモリデバイス、光記憶デバイス、集積回路、サーバ、オンラインソフトウェアなどがある。好ましくは、コンピュータプログラム製品は、前記プログラム製品がコンピュータ上で実行されたときに、本方法の一実施形態を実行するためのコンピュータ可読媒体上に記憶された非一時的プログラムコードを含む。
【0017】
一実施形態では、コンピュータプログラムは、そのコンピュータプログラムがコンピュータ上で実行されたときに本方法の一実施形態のステップの全部又は一部を実行するように適応されたコンピュータプログラムコードを含む。好ましくは、コンピュータプログラムはコンピュータ可読媒体上で実施される。
【0018】
さらなる詳細、態様、及び実施形態について、単に例として、図面を参照しながら説明する。図中の要素は、簡単及び明快のために示されており、必ずしも一定の縮尺で描かれているとは限らない。図において、すでに説明した要素に対応する要素は同じ参照番号を有することがある。
【図面の簡単な説明】
【0019】
【図1a】符号化システムの一実施形態の一例を概略的に示す図である。
【図1b】検証システムの一実施形態の一例を概略的に示す図である。
【図2a】記憶のための符号化されたデータフォーマットの一実施形態の一例を概略的に示す図である。
【図2b】記憶のための符号化されたデータフォーマットの一実施形態の一例を概略的に示す図である。
【図2c】記憶のための符号化されたデータフォーマットの一実施形態の一例を概略的に示す図である。
【図3】階層ハッシュツリーの一実施形態の一例を概略的に示す図である。
【図4】ハッシュツリーの一実施形態の一例を概略的に示す図である。
【図5a】ハッシュツリーの一実施形態の一例を概略的に示す図である。
【図5b】ハッシュツリーの一実施形態の一例を概略的に示す図である。
【図6】ストリーミング又はトランスポートのための符号化されたメッセージの一実施形態の一例を概略的に示す図である。
【図7a】符号化方法の一実施形態の一例を概略的に示す図である。
【図7b】検証方法の一実施形態の一例を概略的に示す図である。
【図8a】一実施形態による、コンピュータプログラムを含む書込み可能部分を有するコンピュータ可読媒体を概略的に示す図である。
【図8b】一実施形態による、プロセッサシステムの表現を概略的に示す図である。
【0020】
参照符号リスト
参照符号及び省略形の以下のリストは図１ａから図３に対応し、図面の解釈を容易にするために与えられており、特許請求の範囲を限定するものとして解釈されるべきでない。
１１０ 符号化システム
１３０ プロセッサシステム
１４０ ストレージ
１５０ 通信インターフェース
１６０ 検証システム
１７０ プロセッサシステム
１８０ ストレージ
１９０ 通信インターフェース
２００ 符号化システム
２１０ ハッシュツリーユニット
２１１～２１３ ハッシュツリー符号化
Ａ、Ａ１、…、Ａ３４ 階層データ
２２０ 記憶ユニット
２３０ ストリーミングユニット
２４０ 検証ユニット
３００ ハッシュツリー
３１０ 最も高いレベル
３１１ ２番目に最も高いレベル
３１３ ３番目に最も高いレベル
３２０ リーフレベル
３３０ 選択された一部
１０００ コンピュータ可読媒体
１０１０ 書込み可能部分
１０２０ コンピュータプログラム
１１１０ 集積回路
１１２０ 処理ユニット
１１２２ メモリ
１１２４ 専用集積回路
１１２６ 通信要素
１１３０ 相互接続
１１４０ プロセッサシステム
参照符号及び省略形の以下のリストは図１ａから図３に対応し、図面の解釈を容易にするために与えられており、特許請求の範囲を限定するものとして解釈されるべきでない。
１１０ 符号化システム
１３０ プロセッサシステム
１４０ ストレージ
１５０ 通信インターフェース
１６０ 検証システム
１７０ プロセッサシステム
１８０ ストレージ
１９０ 通信インターフェース
２００ 符号化システム
２１０ ハッシュツリーユニット
２１１～２１３ ハッシュツリー符号化
Ａ、Ａ１、…、Ａ３４ 階層データ
２２０ 記憶ユニット
２３０ ストリーミングユニット
２４０ 検証ユニット
３００ ハッシュツリー
３１０ 最も高いレベル
３１１ ２番目に最も高いレベル
３１３ ３番目に最も高いレベル
３２０ リーフレベル
３３０ 選択された一部
１０００ コンピュータ可読媒体
１０１０ 書込み可能部分
１０２０ コンピュータプログラム
１１１０ 集積回路
１１２０ 処理ユニット
１１２２ メモリ
１１２４ 専用集積回路
１１２６ 通信要素
１１３０ 相互接続
１１４０ プロセッサシステム
【発明を実施するための形態】
【0021】
開示されている本主題は多くの異なる形式の実施形態を受け容れる余地があるが、本開示は、開示されている本主題の原理の例示として考えられるべきであり、図示し、説明する特定の実施形態にそれを限定するものではないという理解とともに、１つ又は複数の特定の実施形態が図面に示されており、それについて本明細書で詳細に説明する。
【0022】
以下では、理解のために、動作中の実施形態の要素について説明する。しかしながら、それぞれの要素は、それらによって実行される説明される機能を実行するように構成されることが明らかになろう。
【0023】
さらに、開示されている本主題は、実施形態のみに限定されず、本明細書で説明するか又は相互に異なる従属請求項において具陳される特徴のあらゆる他の組合せをも含む。
【0024】
図１ａは、符号化システム１１０の一実施形態の一例を概略的に示している。図１ｂは、検証システム１６０の一実施形態の一例を概略的に示している。符号化システム１１０は、プロセッサシステム１３０と、ストレージ１４０と、通信インターフェース１５０とを備える。検証システム１６０は、プロセッサシステム１７０と、ストレージ１８０と、通信インターフェース１９０とを備える。
【0025】
例えば、通信インターフェース１５０は、ゲノムデータ、例えばゲノムシーケンス及び／又は他のゲノムデータを受信するために構成された入力インターフェースを備える。プロセッサシステム１３０は、例えば、データ構造を生成するために、ストレージ１４０に記憶されたソフトウェアによって構成される。データ構造は、複数のゲノムブロックと、第１のハッシュツリーの一部とを含む。ゲノムデータの代わりに、他のタイプのデータ、特に他の階層データが使用され得ることに留意されたい。
【0026】
例えば、通信インターフェース１９０は、データ構造を受信するために構成された入力インターフェースを備える。プロセッサシステム１７０は、取得されたデータ構造中の第１のハッシュツリーの最も高いレベルを用いて、第１のハッシュツリーの再計算されたルートを検証するように構成される。
【0027】
ストレージ１４０及び／又は１８０は電子メモリ中に含まれる。ストレージは不揮発性ストレージを含み得る。ストレージ１４０及び／又は１８０は、非ローカルストレージ、例えばクラウドストレージを含み得る。後者の場合、ストレージは非ローカルストレージへのストレージインターフェースとして実装され得る。
【0028】
システム１１０及び／又は１６０は、コンピュータネットワークを介して、互いと、外部ストレージ、入力デバイス、出力デバイス、及び／又は１つ又は複数のセンサーと通信する。コンピュータネットワークは、インターネット、イントラネット、ＬＡＮ、ＷＬＡＮなどであり得る。コンピュータネットワークはインターネットであり得る。本システムは、本システム内で、又は必要に応じて本システム外で通信するように構成された接続インターフェースを備える。例えば、接続インターフェースは、コネクタ、例えばワイヤードコネクタ、例えば、イーサネットコネクタ、光コネクタなど、又はワイヤレスコネクタ、例えばアンテナ、例えば、Ｗｉ－Ｆｉ、４Ｇ若しくは５Ｇアンテナを備える。センサーは、サンプルからゲノムシーケンシングデータを取得するためのシーケンシングデバイスであり得る。
【0029】
本システムはデジタル通信のために構成され、デジタル通信は、例えば、ゲノムデータを受信すること、データ構造を記憶すること、データ構造をストリーミングすること、例えば検証のためにデータ構造を取得すること、例えば、データ構造を受信すること又は取り出すことを含む。
【0030】
システム１１０及び１６０の実行は、本明細書中にそれらの例が示されている、プロセッサシステム、例えば１つ又は複数のプロセッサ回路、例えば、マイクロプロセッサにおいて実施される。図及び説明では、プロセッサシステムの機能ユニットであり得る機能ユニットについて説明している。例えば、図２ａは、プロセッサシステムの可能な機能的組織の青写真として使用される。プロセッサ回路はこれらの図中のユニットとは別個に図示されていない。例えば、図示されている機能ユニットは、システム１１０及び１６０において、例えばシステム１１０及び１６０の電子メモリに記憶されたコンピュータ命令に全体的に又は部分的に実装され、システム１１０及び１６０のマイクロプロセッサによって実行可能である。ハイブリッド実施形態では、機能ユニットは、一部はハードウェアにおいて、例えばコプロセッサ、例えば暗号コプロセッサとして実装され、一部は、システム１１０及び１６０上で記憶され、実行されるソフトウェアにおいて実装される。
【0031】
システム１１０及び１６０の様々な実施形態では、通信インターフェースは様々な選択肢から選択される。例えば、インターフェースは、ローカル又はワイドエリアネットワーク、例えばインターネットへのネットワークインターフェース、内部又は外部データストレージへのストレージインターフェース、キーボード、アプリケーションインターフェース（ＡＰＩ）などである。
【0032】
システム１１０及び１６０はユーザインターフェースを有し、ユーザインターフェースは、１つ又は複数のボタン、キーボード、ディスプレイ、タッチスクリーンなど、よく知られている要素を含む。ユーザインターフェースは、本システムを構成すること、ゲノムデータを取り出すこと、ゲノムデータを表示すること、ゲノムデータを検証することなどのためにユーザ対話を提供するために構成される。
【0033】
ストレージは、電子メモリ、例えばフラッシュメモリ、又は磁気メモリ、例えばハードディスクなどとして実装される。ストレージは、ストレージ１４０、１８０を一緒に構成する複数のディスクリートメモリを含み得る。ストレージは、一時メモリ、例えばＲＡＭを含み得る。ストレージはクラウドストレージであり得る。
【0034】
システム１１０は単一のデバイス中に実装され得る。システム１６０は単一のデバイス中に実装され得る。一般に、システム１１０及び１６０は、それぞれ、システムに記憶された適切なソフトウェアを実行するマイクロプロセッサを備え、例えば、そのソフトウェアは、対応するメモリ、例えばＲＡＭなどの揮発性メモリ、又はＦｌａｓｈなどの不揮発性メモリにダウンロード及び／又は記憶される。代替的に、本システムは、例えばフィールドプログラマブルゲートアレイ（ＦＰＧＡ）として、プログラマブル論理に全体的に又は部分的に実装される。本システムは、いわゆる特定用途向け集積回路（ＡＳＩＣ）、例えば、それらの特定の用途のためにカスタマイズされた集積回路（ＩＣ）として全体的に又は部分的に実装され得る。例えば、回路は、例えば、Ｖｅｒｉｌｏｇ、ＶＨＤＬなど、ハードウェア記述言語を使用してＣＭＯＳに実装される。特に、システム１１０及び１６０は、ハッシュ関数又は署名など、暗号関数のための回路を備える。
【0035】
プロセッサ回路は、例えば複数のサブプロセッサ回路として、分散様式で実装され得る。ストレージは複数の分散型サブストレージにわたって分散され得る。メモリの一部又は全部は、電子メモリ、磁気メモリなどであり得る。例えば、ストレージは揮発性部分と不揮発性部分とを有する。ストレージの一部は読取り専用であり得る。
【0036】
符号化システム１１０は、単一のデバイスとして、又は複数のデバイスとして実装される。検証システム１６０は、単一のデバイスとして、又は複数のデバイスとして実装される。
【0037】
図２ａは、符号化システム２００の一実施形態の一例を概略的に示している。図２ａに示されているのは、複数のレベルを有する階層データ構造である。最も高いレベルには、Ａと標示された単一のデータブロックが示されている。２番目に最も高いレベルには、複数のブロックが示されており、この例では、Ａ１、Ａ２、及びＡ３と標示された３つのデータブロックが示されている。２番目に最も高いレベルにあるデータブロックのうちの２つは、それの下にさらなる階層レベルをも有する。３番目に最も高いレベルには、２つのデータブロックシーケンスが示されており、データブロックＡ１１、Ａ１２からＡ１４まではデータブロックＡ１に従属し、データブロックＡ３１、Ａ３２からＡ３４まではデータブロックＡ３に従属する。階層データ構造中には４つ以上のレベルがあり得る。どのデータブロックの下にも、５つ以上の下位ブロック、例えば、８つ以上、２０個以上などの下位ブロックがあり得る。
【0038】
シーケンス中の複数のブロックのために、ハッシュツリーが構築される。図２はハッシュツリーユニット２１０を示している。ハッシュツリーユニットは符号化システム２００の関数ユニットであり得る。ハッシュツリーユニット２１０は、データブロックのシーケンスのためのハッシュツリーを構築するように構成される。ハッシュツリーはマークルツリーとしても知られる。ハッシュツリーはバイナリハッシュツリーであり得る。ハッシュツリーの例について、例えば、図３、図４、及び図５を参照しながら、本明細書でさらに示す。
【0039】
例えば、ゲノムデータなどのデータは複数のゲノムデータブロック２１４のシーケンスに分割される。シーケンス２１４は３つのブロックとともに示されているが、しばしば、４つ以上のブロック、例えば、一層多くのブロック、例えば、１０個を超えるブロック、１００個を超えるブロックなどを有する。ゲノムデータに加えて、複数のブロックは、追加のデータ、例えばゲノムデータに関連する情報、例えば、それの起源、意味、目的などをもつ追加のデータブロックを含み得る。図２には、追加のブロックＡ１１、Ａ１２及びゲノムデータブロックＡ１３からＡ１４までが示されている。図２には、追加のブロックＡ３１、Ａ３２及びゲノムデータブロックＡ３３からＡ３４までが示されている。
【0040】
入力インターフェースは、例えばデータブロックの形態のゲノムデータを受信するために構成されるが、さらなるデータ項目を受信するようにも構成され得る。例えば、さらなるデータ項目及び／又はゲノムデータは、データ構造中で組み合わせられた複数のファイルから取り出される。さらなるデータ項目は第１のハッシュツリーのさらなるリーフに割り当てられ得、例えば、それらのハッシュ値はハッシュツリーのリーフ中に含められる。
【0041】
マークルツリーとしても知られているハッシュツリーは、リーフノードがデータブロックの暗号ハッシュを用いて標示され、あらゆる非リーフノードがそれの子ノードのラベルの暗号ハッシュを用いて標示されるツリーである。この場合、２１１において構築されたハッシュツリーはそれのリーフのためのブロックＡ１１からＡ１４までのハッシュを有する。大部分のノードは一般に２つの子ノードを有するが、１つ又は複数のノードは、例えば、２のべき乗でないブロックの数を考慮するために、１つの子ノードのみを有することがある。変形態として、ハッシュツリーは、４つ以上の子ノードを有するノードを有する。
【0042】
シーケンスＡ１１～Ａ１４の上方のデータ構造の階層部分には、ハッシュツリーの一部が含められる。例えば、ハッシュツリーユニット２１０は、少なくとも複数のゲノムデータブロック中のゲノムデータにハッシュ関数を適用することによって、複数のゲノムブロックＡ１３からＡ１４までのための複数のハッシュ値を計算する。ハッシュ関数は、好ましくは、暗号学的に強いハッシュ関数、例えばＳＨＡ－３である。随意には、追加のデータブロック、例えばブロックＡ１１及びＡ１２のための追加のハッシュが計算される。ハッシュツリーユニット２１０は、複数のハッシュ値のための第１のハッシュツリーを計算し、それにより、複数のハッシュ値を第１のハッシュツリーのリーフに割り当てる。一実施形態では、第１のハッシュツリーは少なくとも３つのレベルを有する。一実施形態では、第１のハッシュツリーは少なくとも４つのリーフを有する。
【0043】
ハッシュ関数は、特に、一方向圧縮関数を含むマークル－ダンガード構成の正則ハッシュ関数である。ハッシュツリー又はマークルツリー中のノードは、必ずしもそのようなハッシュ関数を適用することによって計算されるとは限らない。例えば、Ｖｅｒｋｌｅツリー又は他の認証タグのためのベクトルコミットメントなど、他のタイプのフィンガープリントアルゴリズムが使用される。ゲノムデータブロックの複数のシーケンスを含む、データブロックの複数のシーケンスがあり得る。図２は、そのようなシーケンスの第２の例であるブロックＡ３１～Ａ３４を示している。シーケンスＡ１１～Ａ１３の場合と同様に、これらのブロックのためにも、ハッシュ値が計算され、ハッシュツリーが構築される。
【0044】
興味深いことに、データブロックのシーケンスのために計算されたハッシュツリーについて取得されたハッシュツリー情報は、階層的にそれの上方にあるブロック中に含められる。例えば、ブロックＡ１はブロックＡ１１～Ａ１４の上方の階層にある。ハッシュツリー情報は、より高いレベルの１つ又は複数のブロック中に含められる。その例では、ブロックＡ１はハッシュツリー情報ＨＴＡ１を含む。同様に、この例では、ブロックＡ３は、シーケンスＡ３１～Ａ３４のためのハッシュツリーユニット２１０によって計算されたハッシュツリーから取得されたハッシュツリー情報ＨＴＡ３を含む。
【0045】
一実施形態では、ハッシュツリー情報は、少なくともハッシュツリーのルートを含み、好ましくは、それのすぐ下のレベルをも含む。例えば、ハッシュツリー情報はハッシュツリーの２つの最も高いレベルを含む。興味深いことに、完全なハッシュツリーはハッシュツリー情報中に含められない。ハッシュツリーのより大きい又はより小さい部分は除外される。例えば、一実施形態では、リーフから始まる最も低いレベルのうちの１つ又は複数がハッシュツリー情報から除外される。ハッシュツリーの一部を除外することにより、データ構造のためのストレージ又はストリーミング要件が低減される。除外された情報は、例えば検証のために、それらが必要とされる場合に、後で再計算することができるが、これらのレベルはリーフに近いので、それらは比較的少ない情報にわたって計算される。例えば、リーフ中のハッシュ値を再計算するためには、単一のデータブロックにわたるハッシュのみを計算すればよい。しかしながら、例えば、ハッシュツリーのルートに近いノードを再計算するためには、はるかに多いブロックを計算中に含める必要がある。
【0046】
一実施形態では、より低いレベルのハッシュツリーがデータ構造中に全部含められるが、より低いハッシュツリーのルートがさらなるハッシュツリーのリーフ中で使用される。さらなるハッシュツリーは部分的に含められることがあり、特に、より低いハッシュツリーのルートを含むリーフは省略されることがある。また、さらなるハッシュツリーの他の部分、特に、より低い又は最も低いレベルのうちの１つ又は複数は省略されることがある。
【0047】
最上位に近いレベル、例えば、より多くのレベルが可能であるが、少なくとも最初の２つのレベルを含めることによって、計算時間が最も低減され、最下位に近いレベルを除外することによって、ストレージ要件が最も低減される。
【0048】
ハッシュツリーを構築することは２回以上行うことができる。例えば、図２ａは、ブロックＡ３１～Ａ３４のシーケンスの別の例を示している。ハッシュツリーユニット２１０は、ブロックのためのハッシュ値を計算し、ハッシュツリーを計算し、ツリーの一部、例えば最初のいくつかのレベル、例えば最初の２つのレベルを含めるが、ツリーの少なくとも一部、例えば、階層的により高いブロックについてのハッシュツリー情報、この場合はＨＴＡ３中の最も低い又はより低いレベルを除外するように構成される。
【0049】
ハッシュツリー情報を含むブロック、この場合はブロックＡ１及びＡ３は、ハッシュツリー情報を記憶することに専用であり得る。ハッシュツリー情報は、他の情報、例えば、階層的により低い及び／又は階層レベル中のデータに関する情報とともに含められることがある。
【0050】
ハッシュツリーを構築することは複数のレベルにおいて行うことができる。例えば、図２ａは、ブロックのシーケンスの別の例であるＡ１～Ａ３を示している。ブロックＡ１～Ａ３は、ブロックＡ１１～Ａ１４及びＡ３１～Ａ３４よりも階層的に高いレベルにある。これらのブロックのうちの１つ又は２つ以上、或いはこれらのブロックのすべては、より低い階層レベル、この場合はブロックＡ１及びＡ３におけるハッシュツリーのハッシュツリー情報を含んでいる。ハッシュツリーユニット２１３は、このシーケンス中のブロックのためのハッシュ値を計算し、ハッシュツリーを構築し、ハッシュツリーの一部、例えば最上位部分を、階層的により高いブロック、この場合はブロックＡ中に含める。ハッシュツリー情報はＨＴＡと標示されている。このレベル２には、複数のシーケンス、例えば、（図２ａに示されていない）シーケンスＢ１、Ｂ２などがあり得る。ブロックＡのレベルには、複数のブロック、例えば、（図２ａに示されていない）ブロックＢ、Ｃがあり得る。
【0051】
ハッシュツリー情報は、ハッシュツリー情報を計算するために使用された情報の完全性を検証するために、検証において使用され得る。概して、より多くのデータを検証することができるように、１つ又は複数のハッシュツリー中により多くのデータを含めることが有利であり、好ましくは、１つ又は複数のハッシュツリーを計算するために、すべてのゲノム情報が使用される。しかしながら、例えば、参照データ、命令データなど、他のデータほど敏感でないデータが含められることが起こり得る。ゲノムのいくつかの部分は、他の部分、例えばいわゆるジャンクＤＮＡよりもかなり敏感である。ゲノムデータは非常に大きくなり得るので、完全性保護からデータを除外することにより、データ構造の検証を著しくスピードアップすることができる。一実施形態では、複数のゲノムブロックのある部分は完全性保護付きと標示され、複数のゲノムブロックのある部分は完全性保護なしと標示されており、完全性保護付きと標示された部分のみが第１のハッシュツリー中に含められる。
【0052】
ハッシュツリーは、そのハッシュツリーがそれにわたって計算されたデータの変更の検出を可能にする。興味深いことに、ハッシュツリーはデータの選択的な検証を可能にする。例えば、部分的な検証の場合、ハッシュツリーは、それが、再計算のために選択されたブロックに依存する限りにおいて、及びハッシュツリー中のハッシュ値がストレージから除外されたが、選択されなかったデータブロックのみに依存するハッシュツリー中の記憶されたハッシュ値を使用する限りにおいて、再計算される。
【0053】
ハッシュツリー単独では、しかしながら、悪意のある変更を防がない。例えば、悪意のある変更は、データを変更し、すべてのハッシュツリーを再計算し、置き換える。これを回避するために、符号化システムは、ハッシュツリーのルートにわたってデジタル署名を計算し、デジタル署名をデータ構造中に含めるように構成される。図２ａはこれの一例を示している。ブロックＡは、ブロックＡ１～Ａ３のためのハッシュツリー情報を含み、ハッシュツリー情報にわたる署名をも含む。計算を低減するために、署名は、ハッシュツリー情報全体にわたってではなく、ハッシュツリーのルートのみにわたって計算される。
【0054】
一実施形態では、１つ又は複数の或いはすべてのゲノムブロックが圧縮形態で記憶される。例えば、ブロックＡ１３～Ａ１４のうちの又はブロックＡ３３～Ａ３４のうちの１つ又は複数、或いはブロックＡ１３～Ａ１４の又はブロックＡ３３～Ａ３４のすべてが圧縮される。完全性保護を助けるために、ハッシュツリーは、追加のハッシュ値、すなわち、非圧縮ブロックにわたって計算されたハッシュ値、並びに圧縮ブロックにわたって計算されたハッシュ値にわたって計算される。
【0055】
一実施形態では、１つ又は複数の或いはすべてのゲノムブロックが圧縮及び暗号化された形態で記憶される。一般に、ブロックは暗号化される前に圧縮される。例えば、ブロックＡ１３～Ａ１４のうちの又はブロックＡ３３～Ａ３４のうちの１つ又は複数、或いはブロックＡ１３～Ａ１４の又はブロックＡ３３～Ａ３４のすべてが圧縮され、次いで暗号化される。完全性保護を助けるために、ハッシュツリーは、追加のハッシュ値、すなわち、非圧縮及び非暗号化ブロックにわたって計算されたハッシュ値と、圧縮及び非暗号化ブロックにわたって計算されたハッシュ値と、圧縮及び暗号化ブロックにわたって計算されたハッシュ値とにわたって計算される。これらは随意の拡張であり、一実施形態は、例えば、圧縮及び暗号化ブロックにわたるハッシュ値のみを含むこともあり、例えば、非圧縮及び非暗号化ブロックにわたるハッシュ値のみを含むこともある。
【0056】
ハッシュツリーの別の利点は、選択されたブロックのみが変更された、例えば修正された場合に、修正されなかったブロックのために計算され、記憶されたハッシュツリー中のハッシュ値を使用することによって、ハッシュツリーを迅速に再計算することができることである。１つ又は複数の署名が使用される場合、それらは同様に再計算される。
【0057】
一実施形態では、デバイスはそのような修正を追跡する。例えば、ゲノムデータについての修正、例えば、追加、削除、及び／又は変更のうちの１つ又は複数を含む修正が受信される。１つ又は複数のハッシュツリーが全体的に又は部分的に再計算され、ツリーは、例えばストレージ中で更新される。興味深いことに、修正は追加のブロックとして記憶され得る。ゲノムデータを使用するときに、修正が適用され得る。修正は、新しいハッシュツリー中で使用されるか又は既存のハッシュツリー中に含められる追加のブロック中に含めることができる。このことは、ゲノムデータに対する修正を追跡することができるという利点を有する。
【0058】
ゲノムデータに対する修正は、例えば、メタデータに対する修正を含む。ゲノムデータに対する修正は、例えば、ゲノムシーケンスデータに対する修正を含む。ゲノムデータに対する修正は、例えば、新しいメタデータを含む、新しいデータを含む。データ構造に対する修正が適用され、それらに依拠する、例えば修正された部分から計算されたハッシュツリーの任意の部分が再計算される。追加又は代替として、例えばアカウンタビリティを助けるために、修正自体がデータ構造中に記録される。修正は新しいデータブロック中に記憶され得る。リーフレベルにある新しいデータブロックはまた、ハッシュツリーの大部分が再計算されることを回避する。例えば、修正前にブロック１～１００があった場合、修正はブロック１０１中に配置される。有利には、修正は、ハッシュツリーの大部分を再計算なしに再利用することができるように、末尾のブロック中に配置される。この場合、ブロック１及び２にわたるハッシュ、ブロック３及び４にわたるハッシュなどを再利用することができる。このことはより高いレベルにおいても働き、次のレベルのブロック１～４に依拠するハッシュもこの例などにおいて再利用することができる。データを読み出すときに、ブロック１０１中の修正は、データ中で必要とされる場合に適用される。
【0059】
システム２００中に構築されたデータ構造は様々なやり方で使用される。
【0060】
例えば、システム２００は記憶ユニット２２０を備える。記憶ユニット２２０は、データ構造をコンピュータ可読媒体、例えば非一時的コンピュータ可読媒体に書き込むように構成される。
【0061】
例えば、システム２００はストリーミングユニット２３０を備える。ストリーミングユニット２３０は、コンピュータ可読媒体、例えば一時的コンピュータ可読媒体上のデータ構造又はそれの一部をストリーミングするように構成される。例えば、ストリーミングはコンピュータネットワークを介して行われる。
【0062】
図２ｂ及び図２ｃは、記憶された符号化の一実施形態の一例を概略的に示している。これらの例はまた、ストリーミングのために使用され得るが、ストリーミングにおいて、データ構造の一部を除外することが選択され得る。例えば、ストリーミングにおいて、符号化デバイスは、データ構造の選択された部分を示すパラメータを受信する。符号化デバイスは、次いで、選択された部分だけをストリーミングし、随意に、選択された部分の階層的に上方にあるブロックをもストリーミングすることがある。例えば、ストリーミングにおいて、符号化デバイスは、記憶されていないハッシュツリーのその部分を計算し、それらをストリーミング中に含める。例えば、送信デバイスが計算的により強力である場合、これにより受信デバイスにおける検証がスピードアップする。
【0063】
階層データ構造を記憶及び／又はストリーミングのために線形化することができる多くのやり方がある。例えば、階層関係は、ポインタ、又はラベルなどを用いてブロック中に示される。ブロックは様々な順序で書き込むことができる。図２ｂは、ブロックが深さ優先で書き出される一例を示している。図２ｃは、ブロックが幅優先で書き出される一例を示している。
【0064】
一実施形態では、符号化システムは、データ構造又はそれの一部をストリーミングするために構成される。完全性保護付きデータブロックをストリーミングする際に、例えばストリームの開始時に、トランスポートメッセージがストリーム中に含められ得る。トランスポートメッセージは、
ハッシュツリーのうちの１つ又はハッシュツリーの階層の署名全体と、
受信端上でのトランスポートされたデータブロックの受信後直ちに完全性検証を実行することができるように、トランスポートされた１つ又は複数のノードから始まる、ルート全体までの１つ又は複数の経路中のノードを計算するために必要とされるすべてのハッシュノードと
を含む。
ハッシュツリーのうちの１つ又はハッシュツリーの階層の署名全体と、
受信端上でのトランスポートされたデータブロックの受信後直ちに完全性検証を実行することができるように、トランスポートされた１つ又は複数のノードから始まる、ルート全体までの１つ又は複数の経路中のノードを計算するために必要とされるすべてのハッシュノードと
を含む。
【0065】
図２ａに戻る。例えば、システム２００は検証ユニット２４０を備える。検証ユニット２４０は、データ構造又はそれの一部を検証するように構成される。例えば、検証ユニット２４０は、図２ｂ又は図２ｃ中の記憶又はストリーミングされたものなど、データ構造を検証する。検証はすべての完全性データの検証を伴い得る。例えば、記憶されたハッシュツリーのすべての部分が再計算され、再計算された部分は、記憶された部分と比較される。完全性検証は署名の検証をも含み得る。興味深いことに、検証はデータ構造の選択された部分にも適用され得る。例えば、検証ユニットは、少なくとも選択されたゲノムデータブロック中のゲノムデータにハッシュ関数を適用することによって、データ構造中の複数のゲノムブロックの選択された部分のための複数のハッシュ値を再計算し、複数のゲノムブロックの選択された部分のための第１のハッシュツリーの再計算された複数のハッシュ値と、複数のゲノムブロックの選択されていない部分のための第１のハッシュツリーの含められたレベルとから、第１のハッシュツリーのルートを再計算する。
【0066】
ハッシュツリーは、それが、検証のために選択されたブロックに依存する限りにおいて、及びハッシュツリー中のハッシュ値がストレージから除外された限りにおいて、再計算される。選択されなかったが、それのためのハッシュ値が利用可能であるブロックの部分の場合、記憶／ストリーミングされたハッシュツリーからのハッシュ値が使用され得る。
【0067】
検証は、サーバに記憶されたデータ構造全体と、検証がそこで実行されるクライアントにおいて利用可能な検証されるべきデータブロックとを用いて、クライアントサーバ検証システムにおいて行われる。例えば、一実施形態では、以下の検証プロセスが使用される。順序は異なることがあることに留意されたい。
１．クライアントは、検証されるべきデータ構造中のデータブロックのＩＤをサーバに通知する。
２．サーバは、検証されるデータブロックに関連付けられたノードから始まる、ハッシュツリーのうちの１つ又はハッシュツリーの階層のルート全体までの経路を特定する。
３．サーバは、第２項において特定された経路中のノードを計算するために必要とされるデータブロック又はコンテナを特定する。
４．サーバは、利用可能な場合、第３項において特定されたデータブロック又はコンテナに関連付けられたハッシュノードを取り出すか又は計算する。
５．サーバは、第４項において計算された取り出された／計算されたハッシュノードをクライアントに送信する。
６．クライアントは、選択されたデータブロックにハッシュ関数を適用することによって、データ完全性検証のために選択されたデータ構造中のデータブロックのための複数のハッシュ値を計算する。
７．クライアントは、ルート全体につながる経路に沿ってノードを計算するために必要とされる、検証されるデータブロックの計算された複数のハッシュ値（第６項）と、サーバから受信された計算された／取り出されたハッシュノード（第５項）とから、ハッシュツリーの階層のルート全体を再計算する。
８．クライアントは、取得されたデータ構造中のハッシュツリーのうちの１つ又はハッシュツリーの階層の最上位における再計算されたルート全体を検証する。
１．クライアントは、検証されるべきデータ構造中のデータブロックのＩＤをサーバに通知する。
２．サーバは、検証されるデータブロックに関連付けられたノードから始まる、ハッシュツリーのうちの１つ又はハッシュツリーの階層のルート全体までの経路を特定する。
３．サーバは、第２項において特定された経路中のノードを計算するために必要とされるデータブロック又はコンテナを特定する。
４．サーバは、利用可能な場合、第３項において特定されたデータブロック又はコンテナに関連付けられたハッシュノードを取り出すか又は計算する。
５．サーバは、第４項において計算された取り出された／計算されたハッシュノードをクライアントに送信する。
６．クライアントは、選択されたデータブロックにハッシュ関数を適用することによって、データ完全性検証のために選択されたデータ構造中のデータブロックのための複数のハッシュ値を計算する。
７．クライアントは、ルート全体につながる経路に沿ってノードを計算するために必要とされる、検証されるデータブロックの計算された複数のハッシュ値（第６項）と、サーバから受信された計算された／取り出されたハッシュノード（第５項）とから、ハッシュツリーの階層のルート全体を再計算する。
８．クライアントは、取得されたデータ構造中のハッシュツリーのうちの１つ又はハッシュツリーの階層の最上位における再計算されたルート全体を検証する。
【0068】
図３は、ハッシュツリー３００の一実施形態の一例を概略的に示している。図３中のものなど、ハッシュツリーはハッシュツリー計算２１１、２１２、２１３などにおいて使用される。ハッシュツリーは複数のレベルを有する。最も高いレベル３１０は、単一のノードである、ハッシュツリーのルートを有する。２番目に最も高いレベル３１１は少なくとも２つのノードを含んでいる。一実施形態では、レベル３１１の２つのノードがストレージ中に含まれる。また、図３には、３番目に最も高いレベル３１２と、リーフレベル３２０、例えば最も低いレベルとが示されている。ツリーの選択された部分はデータ構造中に記憶される。図３は、ストレージのための選択された部分３３０を示している。選択された部分３３０は最初の２つのレベルを含み得る。選択された部分３３０は、最も高い３つ以上のレベルを含み得る。選択された部分３３０はレベルの一部を含み得る。例えば、３番目に最も高いレベルの一部である。
【0069】
一実施形態では、ツリーパラメータ、例えば、ツリーサイズパラメータが符号化中に使用され、例えば、入力インターフェースにおいて受信される。ツリーサイズパラメータは、ハッシュツリーのどのくらいがデータ構造中に記憶されるべきであるかを示す。ツリーサイズパラメータは、ハッシュツリーのより大きい部分が記憶されるべきであることを示すことがある。ツリーサイズパラメータは、ハッシュツリーのより小さい部分が記憶されるべきであることを示すことがある。このようにして、ユーザは、選択された部分についてのファイルサイズ又は検証速度が最適化されるべきであるかどうかを示すことができる。
【0070】
対応する検証システム、例えば検証システム１６０は、符号化システム１１０及び／又は符号化システム２００に類似して働き得る。検証システムは、エンドユーザのレベルで働くだけでなく、中間のレベル、例えば、データ構造のソースとデータ構造のエンドユーザとの間のサーバのレベルにおいても働き得る。検証は、サーバにおいて、並びにエンドユーザのデバイスにおいて行われ得る。
【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】
バイナリマークルツリーを構築するときに、特定のレベルに奇数個のリーフ又はノードがある場合、最後のリーフ又はノードをそれ自体と連結することができる。リーフＡ、Ｂ、Ｃ、Ｄ、及びＥをもつ５ノードの例について考える。プロセスは以下のとおりである。
リーフレベル：５つのリーフがあり、Ａ及びＢはノードＡＢにつながり、Ｃ及びＤはノードＣＤにつながる。Ｅは単独であり、したがってノードＥＥにつながる。
レベル１：３つのノードがあり、ＡＢ及びＣＤはノードＡＢＣＤにつながり、ＥＥは単体であり、したがってＥＥＥＥになる。
レベル２：最後に、ルートノードＡＢＣＤＥＥＥＥを与える２つのノードＡＢＣＤ及びＥＥＥＥがある。
リーフレベル：５つのリーフがあり、Ａ及びＢはノードＡＢにつながり、Ｃ及びＤはノードＣＤにつながる。Ｅは単独であり、したがってノードＥＥにつながる。
レベル１：３つのノードがあり、ＡＢ及びＣＤはノードＡＢＣＤにつながり、ＥＥは単体であり、したがってＥＥＥＥになる。
レベル２：最後に、ルートノードＡＢＣＤＥＥＥＥを与える２つのノードＡＢＣＤ及びＥＥＥＥがある。
【0098】
実施形態２：
この実施形態は問題２に対処する。それは、実施形態１においてレベル０を導入することを含み、レベル０はレベル１よりも低い。これは以下のように行われる。
各アクセスユニット又はディスクリプタストリームのためのマークルツリー中のリーフとして使用されるＨａｓｈ（Ｂｌｏｃｋ）は、そのブロックのための（最大）３つの値、
Ｈａｓｈ（ＥＣＤ）、圧縮及び暗号化ブロックのハッシュ
Ｈａｓｈ（ＰＣＤ）、圧縮ブロックのハッシュ
Ｈａｓｈ（ＰＤＤ）、圧縮解除した後のブロックのハッシュ
から計算されたブロックＭＴＲ＿ｂｌｏｃｋのＭＴルートに置き換えられる。
この実施形態は問題２に対処する。それは、実施形態１においてレベル０を導入することを含み、レベル０はレベル１よりも低い。これは以下のように行われる。
各アクセスユニット又はディスクリプタストリームのためのマークルツリー中のリーフとして使用されるＨａｓｈ（Ｂｌｏｃｋ）は、そのブロックのための（最大）３つの値、
Ｈａｓｈ（ＥＣＤ）、圧縮及び暗号化ブロックのハッシュ
Ｈａｓｈ（ＰＣＤ）、圧縮ブロックのハッシュ
Ｈａｓｈ（ＰＤＤ）、圧縮解除した後のブロックのハッシュ
から計算されたブロックＭＴＲ＿ｂｌｏｃｋのＭＴルートに置き換えられる。
【0099】
３つの値すべてが常に必要とされるとは限らない。含められ、検証される値に応じて、完全性欠如の理由をより高い又は低い精度で検査することが可能になる。
【0100】
上記のハッシュ値はそれぞれリーフに割り当てられる。これにより、エラーを、例えば圧縮のエラーなどとしてピンポイントで特定することが可能になる。完全性は異なる場所において検査され得ることに留意されたい。サーバは、それが復号鍵へのアクセスを有しない場合、復号されたデータを検査することができないが、サーバは、暗号化されたデータを検査することができる。
【0101】
さらに、一例では、マークルツリーのルートは、
ＭＴＲ＿Ｂｌｏｃｋ＝Ｈａｓｈ（Ｈａｓｈ（Ｈａｓｈ（ＥＣＤ）｜Ｈａｓｈ（ＰＣＤ））｜Ｈａｓｈ（ＰＤＤ））である。この場合、例えば３進ツリー構造に従うルートのための異なる計算、例えばＨａｓｈ（Ｈａｓｈ（ＥＣＤ）｜Ｈａｓｈ（ＰＣＤ）｜Ｈａｓｈ（ＰＤＤ））も妥当であることに留意されたい。
これにより、復号及び圧縮解除プロセスの異なる段階において、また、規格の分散型実装における異なるロケーション（例えば、クライアントとクラウド）においてデータの完全性を検査することが可能になる。
ＭＴＲ＿Ｂｌｏｃｋ＝Ｈａｓｈ（Ｈａｓｈ（Ｈａｓｈ（ＥＣＤ）｜Ｈａｓｈ（ＰＣＤ））｜Ｈａｓｈ（ＰＤＤ））である。この場合、例えば３進ツリー構造に従うルートのための異なる計算、例えばＨａｓｈ（Ｈａｓｈ（ＥＣＤ）｜Ｈａｓｈ（ＰＣＤ）｜Ｈａｓｈ（ＰＤＤ））も妥当であることに留意されたい。
これにより、復号及び圧縮解除プロセスの異なる段階において、また、規格の分散型実装における異なるロケーション（例えば、クライアントとクラウド）においてデータの完全性を検査することが可能になる。
【0102】
例えば、ＭＰＥＧ－Ｇクライアントが、クラウドに記憶されたＭＰＥＧ－Ｇファイルからのデータを要求すると仮定する。クラウドは、暗号化及び圧縮されたデータが変更されていないことを検査するために、ユーザの認証情報（ｃｒｅｄｅｎｔｉａｌ）を検査し、マークルツリー中の情報、すなわちＨａｓｈ（ＥＣＤ）を使用し得る。クラウドは、次いで、（ｉ）帯域幅を節約するために圧縮され、（ｉｉ）クラウド自体はユーザデータへのアクセスを有しないので暗号化された、暗号化及び圧縮されたデータをＭＰＥＧ－Ｇクライアントに送る。ＭＰＥＧ－Ｇクライアントがデータを受信したとき、ＭＰＥＧ－Ｇクライアントは、最初にデータの完全性を検査するために、Ｈａｓｈ（ＥＣＤ）を使用することができる。次いで、ＭＰＥＧ－Ｇクライアントは、データを復号し、復号及び圧縮されたデータの完全性を検査するためにＨａｓｈ（ＰＣＤ）を使用することができる。最後に、ＭＰＥＧ－Ｇクライアントは、データを圧縮解除し、復号及び圧縮解除されたデータの完全性を検査するためにＨａｓｈ（ＰＤＤ）を使用することができる。
【0103】
実施形態３：
この実施形態は問題３に対処する。この目的のために、レベル０、１、２、３又は４にあるデータ構造中のデータが追加及び／又は変更されたとき、
レベルｉにあるその新しいデータ構造のための新しい／更新されたＭＴが計算される。
ＭＴＲ＿ＭＰＥＧＧ、したがって、ＭＴＲ＿ＭＰＥＧＧ上の署名がレベル５において更新されるまで、以下のプロセスが実行される。
新しい（又は更新された）リーフが次の上位レベルＭＴに追加されることになる。新しい（又は更新された）リーフの値は、現在のレベルｉにあるＭＴのＭＴＲの値である。
次の上位レベルにあるＭＴは新しい／更新されたリーフを有するので、それのルートも更新される。
この実施形態は問題３に対処する。この目的のために、レベル０、１、２、３又は４にあるデータ構造中のデータが追加及び／又は変更されたとき、
レベルｉにあるその新しいデータ構造のための新しい／更新されたＭＴが計算される。
ＭＴＲ＿ＭＰＥＧＧ、したがって、ＭＴＲ＿ＭＰＥＧＧ上の署名がレベル５において更新されるまで、以下のプロセスが実行される。
新しい（又は更新された）リーフが次の上位レベルＭＴに追加されることになる。新しい（又は更新された）リーフの値は、現在のレベルｉにあるＭＴのＭＴＲの値である。
次の上位レベルにあるＭＴは新しい／更新されたリーフを有するので、それのルートも更新される。
【0104】
実施形態４：
この実施形態は問題４に対処する。この目的のために、１つの選択肢は、ＭＰＥＧ－Ｇファイル中の変更／更新（＊＊）を追跡するために、実施形態１に記載されているｍｔｉｄボックス中に追跡テーブルを含めることである。ファイルの作成以後、ｉ＝０、１、２、…である、ｉ番目に生成された署名に対応する、テーブル中のｉ番目のエントリは以下を含んでいる。
効率的な検証及び記憶を可能にするための、すべての又は選択されたルート値ＭＴＲ＿ＤＧ、ＭＴＲ＿ＤＴ、ＭＴＲ＿ＡＴ、ＭＴＲ＿ＡＧ、ＭＴＲ＿ＡＵ、ＭＴＲ＿ＤＳ及びマークルツリーノード。さらなる詳細については、実施形態６～８を参照されたい。
Ｓｉｇｎ（ＰｒｉｖＫ、ｉ｜ＭＴＲ＿ＭＰＥＧＧ｜ＳＩＧＮＡＴＵＲＥ＿ＭＴＲ＿ＭＰＥＧＧ（ｉ－１））として計算されたＳＩＧＮＡＴＵＲＥ＿ＭＴＲ＿ＭＰＥＧＧ（ｉ）と示された現在のＭＴＲ＿ＭＰＥＧＧ上の署名、ここで、
ＳＩＧＮＡＴＵＲＥ＿ＭＴＲ＿ＭＰＥＧＧ（－１）＝“”であり、
ＰｒｉｖＫは、識別情報の証拠として認証局（ＣＡ）によって署名された関連付けられた公開鍵証明書をもつ署名者の秘密鍵である。
長期的な完全性保護を目的とするとき、ＬＭＳなど、ハッシュベースの署名アルゴリズム、すなわち、例えば、ＲＦＣ８５５４、又は耐量子アルゴリズムのうちの１つ、例えば、Ｆａｌｃｏｎ、ＳＰＨＩＮＣＳ（現在ＮＩＳＴによる規格化中）が好ましい。特に、いくつかのエントリにおいてプレ量子（ｐｒｅ－ｑｕａｎｔｕｍ）署名アルゴリズム（例えばＥＣＤＳＡ）が使用される場合、この場合、ＥＣＤＳＡが、例えば量子コンピュータにより解読されるとすぐに、それらのエントリを検証することが不可能であることがある。
署名者のＩＤ
ｉ＝１、２、…である、時間ｉにおいてファイルが変更されたとき、
ＭＴＲ＿ＭＰＥＧＧは、実施形態３に記載されているように更新される。
ｍｔｉｄ中の追跡テーブル中に新しいエントリが含められる。追跡することを容易にするために、追跡データは以下を含み得る。
ＳＩＧＮＡＴＵＲＥ＿ＭＴＲ＿ＭＰＥＧＧ（ｉ）
新しい追加データ（データ追加の場合）、又は前のデータと比較した変更されたデータの差。
変更又は追加されたリーフ。
さらに、
現在のマークルツリールートまでの経路を通過することによって、リーフのデータにアクセスするときに、データのそのピースについてのファイル完全性及びすべての関係する変更を検査することができる。
ｍｔｉｄ中の追跡テーブル中の特定のデータ項目を検索するときに、データのそのピースの追加／変更についてのすべての情報が見つけられる。
この実施形態は問題４に対処する。この目的のために、１つの選択肢は、ＭＰＥＧ－Ｇファイル中の変更／更新（＊＊）を追跡するために、実施形態１に記載されているｍｔｉｄボックス中に追跡テーブルを含めることである。ファイルの作成以後、ｉ＝０、１、２、…である、ｉ番目に生成された署名に対応する、テーブル中のｉ番目のエントリは以下を含んでいる。
効率的な検証及び記憶を可能にするための、すべての又は選択されたルート値ＭＴＲ＿ＤＧ、ＭＴＲ＿ＤＴ、ＭＴＲ＿ＡＴ、ＭＴＲ＿ＡＧ、ＭＴＲ＿ＡＵ、ＭＴＲ＿ＤＳ及びマークルツリーノード。さらなる詳細については、実施形態６～８を参照されたい。
Ｓｉｇｎ（ＰｒｉｖＫ、ｉ｜ＭＴＲ＿ＭＰＥＧＧ｜ＳＩＧＮＡＴＵＲＥ＿ＭＴＲ＿ＭＰＥＧＧ（ｉ－１））として計算されたＳＩＧＮＡＴＵＲＥ＿ＭＴＲ＿ＭＰＥＧＧ（ｉ）と示された現在のＭＴＲ＿ＭＰＥＧＧ上の署名、ここで、
ＳＩＧＮＡＴＵＲＥ＿ＭＴＲ＿ＭＰＥＧＧ（－１）＝“”であり、
ＰｒｉｖＫは、識別情報の証拠として認証局（ＣＡ）によって署名された関連付けられた公開鍵証明書をもつ署名者の秘密鍵である。
長期的な完全性保護を目的とするとき、ＬＭＳなど、ハッシュベースの署名アルゴリズム、すなわち、例えば、ＲＦＣ８５５４、又は耐量子アルゴリズムのうちの１つ、例えば、Ｆａｌｃｏｎ、ＳＰＨＩＮＣＳ（現在ＮＩＳＴによる規格化中）が好ましい。特に、いくつかのエントリにおいてプレ量子（ｐｒｅ－ｑｕａｎｔｕｍ）署名アルゴリズム（例えばＥＣＤＳＡ）が使用される場合、この場合、ＥＣＤＳＡが、例えば量子コンピュータにより解読されるとすぐに、それらのエントリを検証することが不可能であることがある。
署名者のＩＤ
ｉ＝１、２、…である、時間ｉにおいてファイルが変更されたとき、
ＭＴＲ＿ＭＰＥＧＧは、実施形態３に記載されているように更新される。
ｍｔｉｄ中の追跡テーブル中に新しいエントリが含められる。追跡することを容易にするために、追跡データは以下を含み得る。
ＳＩＧＮＡＴＵＲＥ＿ＭＴＲ＿ＭＰＥＧＧ（ｉ）
新しい追加データ（データ追加の場合）、又は前のデータと比較した変更されたデータの差。
変更又は追加されたリーフ。
さらに、
現在のマークルツリールートまでの経路を通過することによって、リーフのデータにアクセスするときに、データのそのピースについてのファイル完全性及びすべての関係する変更を検査することができる。
ｍｔｉｄ中の追跡テーブル中の特定のデータ項目を検索するときに、データのそのピースの追加／変更についてのすべての情報が見つけられる。
【0105】
実施形態５：
この実施形態は問題５に対処する。このことは、以下によって行われる。
ｄａｔａｓｅｔＧｒｏｕｐＩＤを十分な長さ（例えば２５６ビット長）にし、それをランダムに生成すること。
特に、ｄａｔａｓｅｔＧｒｏｕｐＩＤをＭＴＲ＿ＤＧと置き換えること。ｄａｔａｓｅｔＧｒｏｕｐＩＤが一意であることを保証するために、ＭＴＲ＿ＤＧの計算中の追加の入力、すなわち、十分に長いランダムナンス（ｒａｎｄｏｍ ｎｏｎｃｅ）Ｎ＿ＭＴＲ＿ＤＧが含められる。
同様に、ｄａｔａｓｅｔＩＤをＭＴＲ＿ＤＳと置き換えることができる。ｄａｔａｓｅｔＧｒｏｕｐＩＤが一意であることを保証するために、ＭＴＲ＿ＤＧの計算中の追加の入力、すなわち、十分に長いランダムナンスＮ＿ＭＴＲ＿ＤＧが含められる。
この実施形態は問題５に対処する。このことは、以下によって行われる。
ｄａｔａｓｅｔＧｒｏｕｐＩＤを十分な長さ（例えば２５６ビット長）にし、それをランダムに生成すること。
特に、ｄａｔａｓｅｔＧｒｏｕｐＩＤをＭＴＲ＿ＤＧと置き換えること。ｄａｔａｓｅｔＧｒｏｕｐＩＤが一意であることを保証するために、ＭＴＲ＿ＤＧの計算中の追加の入力、すなわち、十分に長いランダムナンス（ｒａｎｄｏｍ ｎｏｎｃｅ）Ｎ＿ＭＴＲ＿ＤＧが含められる。
同様に、ｄａｔａｓｅｔＩＤをＭＴＲ＿ＤＳと置き換えることができる。ｄａｔａｓｅｔＧｒｏｕｐＩＤが一意であることを保証するために、ＭＴＲ＿ＤＧの計算中の追加の入力、すなわち、十分に長いランダムナンスＮ＿ＭＴＲ＿ＤＧが含められる。
【0106】
この変更の利点は、各データセット又はデータセットグループに一意識別子が割り当てられることである。このことは、現在のＭＰＥＧ－Ｇ規格が、これらの識別子に基づいてエントリを取り出すためにファイルとＡＰＩとをマージすることについての使用事例を含むので、利点である。識別子範囲が８ビットしかない場合、２つのデータセットグループをマージするには、識別子をリネームする必要があることがある。識別子がリネームされなかった場合、ＡＰＩに対するコールは、間違った結果を戻すことがある。ＭＴＲ＿ＤＧ及びＭＴＲ＿ＤＳをｄａｔａｓｅｔＧｒｏｕｐＩＤ及びｄａｔａｓｅｔＩＤとして使用することにより、これらの２つの問題が解決される。
【0107】
実施形態６：ＭＴ記憶オーバーヘッド及び計算性能トレードオフ及び最適化：
一般に、小数で存在するデータ構造の場合、大きい記憶オーバーヘッドを負うことなしに完全性検証の効率を改善するためにマークルツリー（ＭＴ）全体を記憶することができる。一方、通常、多数で存在するデータ構造の場合、記憶オーバーヘッドと計算リソースとの間のトレードオフが好ましい。２ｎ個のリーフをもつバイナリＭＴの場合、２ｎ個のリーフのすべてが利用可能である場合に、ＭＴノード及びルートの計算は（２ｎ－１）回のハッシュ演算を要する。バイナリＭＴ中に、すべての中間ノード及びルートを含む、合計２ｎ－１個のノードがある。
一般に、小数で存在するデータ構造の場合、大きい記憶オーバーヘッドを負うことなしに完全性検証の効率を改善するためにマークルツリー（ＭＴ）全体を記憶することができる。一方、通常、多数で存在するデータ構造の場合、記憶オーバーヘッドと計算リソースとの間のトレードオフが好ましい。２ｎ個のリーフをもつバイナリＭＴの場合、２ｎ個のリーフのすべてが利用可能である場合に、ＭＴノード及びルートの計算は（２ｎ－１）回のハッシュ演算を要する。バイナリＭＴ中に、すべての中間ノード及びルートを含む、合計２ｎ－１個のノードがある。
【0108】
この実施形態は、バイナリＭＴのルートから数えて、１≦ｍ≦ｎである、ノードの最上位ｍ個のレベルを記憶するための最適化を提案する。ノードのこのセットがすべてのリーフと一緒に記憶された場合、リーフを検証するための計算上の負担は、ノードのペア上の［２（ｎ－ｍ＋１）－１＋（ｍ－１）］回のハッシュ演算まで低減される。リーフの記憶により、特に、データ構造が大きい場合、データ構造上のハッシングの費用がかかる演算が回避される。
【0109】
この最適化は、点描されている三角形が部分的なマークルツリーを表す、図５ａに示されている。図５ａには、最も高いレベル５１０、例えばレベルｎにあるルートノード５１１が示されている。また、５２０にはレベルｎ－（ｍ－１）、５３０にはレベルｎ－ｍ、５４０にはレベル１、５５０にはリーフレベル（レベル０）が示されている。５２２にはｍ個のレベル、５２１にはｎ個のレベルが示されている。レベル５２０は２ｎ－（ｍ－１）個のノードを含む。レベル５３０は２ｎ－ｍ個のノードを含む。点描されている三角形部分は２ｍ－１個のノードを含む。レベル１は２ｎ－１個のノードを有する。レベル０は２ｎ個のノードを有する。
【0110】
三角形５６０は、必要とされるときにオンザフライで生成されるノードを示している。三角形５６０は２ｎ－ｍ＋１－１個のノードを含む。ツリー５００の点描されていない部分、例えばレベル５３０以下は記憶されていない。最上位レベル、例えばレベル５２０以上は記憶されている。
【0111】
マークルツリー全体は、この例では、２ｎ個のリーフを有する。ルートを含む、最上位ｍ個のレベルにあるリーフとノードの両方が記憶されている。最下位（ｎ－ｍ＋１）個のレベルにある三角形５６０は、特定のリーフを検証する必要があるときに、オンザフライで再計算される。
【0112】
多数のリーフ、例えば２３２個ものリーフがあり得る。必要とされる場合、さらに多くのリーフがあり得る。ブロックサイズも様々であり得る。ブロックサイズが小さいほど、小さいオーバーヘッドでよりきめ細かい完全性検査が可能になるが、ハッシュツリーのサイズは増加することがある。例えば、ブロックサイズを決定するためにツリーサイズパラメータが使用される。
【0113】
記憶されているＭＴの部分はファイルの一部であり得る。別個のファイルとして記憶され得る。これはデータ構造の一部として記憶することができる。
【0114】
例えば、ｎ＝３２、ｍ＝２４である場合、３２バイトのハッシュコードサイズを仮定すると、それは、ツリーの最上位部分のための（２２４－１）回のハッシュ（約２２４＊３２バイト）と、２３２個のリーフとを記憶している。リーフを検証することは、最下位にある部分的なＭＴの再計算のための（２９－１）回のハッシュ演算に加えて、ルートに達するための２３回のハッシュを要する。（２９＋２２）回の演算は非常に速い。メモリオーバーヘッドはデータ構造のリーフの数に大きく依存する。
【0115】
代替として、２ｎ個のリーフが記憶されていない場合、ただノードの最上位ｍ個のレベルを記憶することによって、依然として、完全性検証のために計算される必要があるリーフの数を２（ｎ－ｍ＋１）個に低減することができる。この場合、記憶オーバーヘッドは（２ｍ－１）回のハッシュによって与えられ、マークルツリールートを再計算するための時間は、
Ｔｂｉｎａｒｙ＿ＭＴ＝［２（ｎ－ｍ＋１）－１＋（ｍ－１）］＊ｔｎｏｄｅ＋２（ｎ－ｍ＋１）＊ｔｌｅａｆ
によって与えられ、
ここで、ｔｎｏｄｅは、２つのノード上でのハッシングのための時間であり、ｔｌｅａｆは、データ構造上でのハッシングによってリーフを生成するための時間である。
リーフ又はノードの記憶がない場合、計算時間は、
Ｔｂｉｎａｒｙ＿ＭＴ＝［２ｎ－１］＊ｔｎｏｄｅ＋２ｎ＊ｔｌｅａｆ
になる。
Ｔｂｉｎａｒｙ＿ＭＴ＝［２（ｎ－ｍ＋１）－１＋（ｍ－１）］＊ｔｎｏｄｅ＋２（ｎ－ｍ＋１）＊ｔｌｅａｆ
によって与えられ、
ここで、ｔｎｏｄｅは、２つのノード上でのハッシングのための時間であり、ｔｌｅａｆは、データ構造上でのハッシングによってリーフを生成するための時間である。
リーフ又はノードの記憶がない場合、計算時間は、
Ｔｂｉｎａｒｙ＿ＭＴ＝［２ｎ－１］＊ｔｎｏｄｅ＋２ｎ＊ｔｌｅａｆ
になる。
【0116】
ファイルがサーバに常駐し、検証がクライアントにおいて行われる、クライアントサーバ設定におけるバイナリＭＴの演算について、ｎ＝４及びｍ＝２である、図５ｂに示されている例を使用してさらに説明する。図５ｂは、レベル４～１とリーフレベルとをもつハッシュツリーを示している。レベル４にはノードＲがあり、レベル３にはノードＮ３１及びＮ３２があり、レベル２にはノードＮ２１、Ｎ２２、Ｎ２３及びＮ２４があり、レベル１にはノードＮ１１～Ｎ１８があり、リーフレベルには、データＤ１～Ｄ１６に対応するノードＬ１～Ｌ１６がある。
【0117】
レベル３及び４にあるすべてのノードと、すべてのリーフとが事前計算され、例えばデータブロック中に記憶されていると仮定する。（ハイライトされている）Ｄ１２を検証するために、以下のステップが取られる。
１．サーバが、（ハイライトされている）ノード｛Ｎ１５、Ｎ１７、Ｎ１８、Ｎ２４｝を生成する。一般に、サーバにおけるハッシュ演算の回数は｛［２（ｎ－ｍ＋１）－１］－（ｎ－ｍ＋１）｝によって与えられる。
２．サーバがハッシュ｛Ｌ１１、Ｎ１５、Ｎ２４、Ｎ３１｝をルートの署名と一緒にクライアントに送る。一般に、送る必要があるハッシュの数はｎである。
３．クライアントが、
データ構成要素Ｄ１２上でのハッシングによってリーフＬ１２
を生成し、
サーバから受信されたハッシュを使用して、（ハイライトされている）ノード｛Ｎ１６、Ｎ２３、Ｎ３２、Ｒ｝を生成する。一般に、クライアントにおけるハッシュのペア上でのハッシュ演算の回数はｎ回である。
４．クライアントが、関連付けられた公開鍵を使用して、受信された署名を復号し、復号されたハッシュコードを生成されたルートＲと比較する。それらが互いに一致すれば、検証は成功である。
１．サーバが、（ハイライトされている）ノード｛Ｎ１５、Ｎ１７、Ｎ１８、Ｎ２４｝を生成する。一般に、サーバにおけるハッシュ演算の回数は｛［２（ｎ－ｍ＋１）－１］－（ｎ－ｍ＋１）｝によって与えられる。
２．サーバがハッシュ｛Ｌ１１、Ｎ１５、Ｎ２４、Ｎ３１｝をルートの署名と一緒にクライアントに送る。一般に、送る必要があるハッシュの数はｎである。
３．クライアントが、
データ構成要素Ｄ１２上でのハッシングによってリーフＬ１２
を生成し、
サーバから受信されたハッシュを使用して、（ハイライトされている）ノード｛Ｎ１６、Ｎ２３、Ｎ３２、Ｒ｝を生成する。一般に、クライアントにおけるハッシュのペア上でのハッシュ演算の回数はｎ回である。
４．クライアントが、関連付けられた公開鍵を使用して、受信された署名を復号し、復号されたハッシュコードを生成されたルートＲと比較する。それらが互いに一致すれば、検証は成功である。
【0118】
この手法のコストを、完全性について保護されているデータ構造ごとに１つのデジタル署名を必要とする現在のＭＰＥＧ－Ｇと比較すると、この手法では、
２つのデータ構造を検証する必要があるとすぐに、計算オーバーヘッドが減少する。その理由は、デジタル署名検証のコストがハッシュ計算よりもはるかに費用がかかるためである。ＭＴ手法はファイルのＭＴルートのための単一の署名検証を伴う。
同じデータ構造が完全性保護付きであると仮定すると、記憶オーバーヘッドが減少する。その理由は、現在のＭＰＥＧ－Ｇがデータ構造ごとにデジタル署名を必要とし、また、特に耐量子署名が使用される場合、署名サイズがハッシュ値よりも大きくなるためである。
２つのデータ構造を検証する必要があるとすぐに、計算オーバーヘッドが減少する。その理由は、デジタル署名検証のコストがハッシュ計算よりもはるかに費用がかかるためである。ＭＴ手法はファイルのＭＴルートのための単一の署名検証を伴う。
同じデータ構造が完全性保護付きであると仮定すると、記憶オーバーヘッドが減少する。その理由は、現在のＭＰＥＧ－Ｇがデータ構造ごとにデジタル署名を必要とし、また、特に耐量子署名が使用される場合、署名サイズがハッシュ値よりも大きくなるためである。
【0119】
下表は、ツリー名と、リーフの最大数と、ストレージのニーズと、リーフを検証するためのハッシュ演算の回数と、バイナリツリー中の内部レベルの数とを含む、マークルツリーの異なるレベルの特性を要約している。
【0120】
【表1】
【0121】
実施形態７：暗号化データコンテナのためのハッシュコードに代わる認証タグの使用
ＭＰＥＧ－Ｇは、ＧＣＭモードにおけるＡＥＳを使用することによって、対称鍵を用いて異なるコンテナを保護することを可能にすることに留意されたい。このことは、対応する対称鍵を使用することによって、データコンテナを暗号化し、認証することもできることを意味する。認証は、データコンテナ全体に依存する記憶された認証タグを検査することによって実行される。既存のＭＰＥＧ－Ｇソリューション中の認証タグは、ＣＰＵ及びメモリ要件を低減するために、データコンテナのフィンガープリントとして再利用され得る。特に、ＡＥＳ－ＣＣＭ認証タグは、例えば、実施形態１のレベル１にあるＨａｓｈ（ｂｌｏｃｋ）、又は、実施形態２におけるＨａｓｈ（ＥＣＤ）に取って代わることができる。認証タグがフィンガープリントとして再利用される場合、データコンテナ（ＭＴリーフ）のハッシュは再計算又は記憶する必要がない。
ＭＰＥＧ－Ｇは、ＧＣＭモードにおけるＡＥＳを使用することによって、対称鍵を用いて異なるコンテナを保護することを可能にすることに留意されたい。このことは、対応する対称鍵を使用することによって、データコンテナを暗号化し、認証することもできることを意味する。認証は、データコンテナ全体に依存する記憶された認証タグを検査することによって実行される。既存のＭＰＥＧ－Ｇソリューション中の認証タグは、ＣＰＵ及びメモリ要件を低減するために、データコンテナのフィンガープリントとして再利用され得る。特に、ＡＥＳ－ＣＣＭ認証タグは、例えば、実施形態１のレベル１にあるＨａｓｈ（ｂｌｏｃｋ）、又は、実施形態２におけるＨａｓｈ（ＥＣＤ）に取って代わることができる。認証タグがフィンガープリントとして再利用される場合、データコンテナ（ＭＴリーフ）のハッシュは再計算又は記憶する必要がない。
【0122】
実施形態８：選択的な完全性保護
一実施形態では、すべてのデータ構造、又はコンテナが保護される。しかしながら、いくつかの状況では、ユーザは部分的な保護を選択し得る。この実施形態では、データ構造の選択的な保護をどのように実現することができるかについて説明する。
一実施形態では、すべてのデータ構造、又はコンテナが保護される。しかしながら、いくつかの状況では、ユーザは部分的な保護を選択し得る。この実施形態では、データ構造の選択的な保護をどのように実現することができるかについて説明する。
【0123】
この目的のために、各コンテナタイプは、そのコンテナタイプのデータ構造が一般にどのように選択されるかを示すためのフィールドを有する。例えば、フィールドの値は以下であり得る。
０－いずれも選択されていない（マークルツリーは、このコンテナレベル以下にあるすべてのデータ構造を除外する）
１－すべてが選択されている
２－ＩＤによってデータ構造を選択する
３－例えば、上位レベルコンテナ中のそれらの位置によってデータ構造の選択を示すために、ビットのシーケンスを使用して、フラグによってデータ構造を選択する
０－いずれも選択されていない（マークルツリーは、このコンテナレベル以下にあるすべてのデータ構造を除外する）
１－すべてが選択されている
２－ＩＤによってデータ構造を選択する
３－例えば、上位レベルコンテナ中のそれらの位置によってデータ構造の選択を示すために、ビットのシーケンスを使用して、フラグによってデータ構造を選択する
【0124】
以下は、ＭＴ検証中にそれらを含めるためのデータセットグループコンテナ、データセットコンテナ、注釈テーブルコンテナ、アクセスユニットコンテナ及びブロックコンテナの一般的な選択モードのための例示的な設定である。
ｍｔ＿ｓｅｌｅｃｔ＿ｄｇ＝１（すべてのデータセットグループを選択する）
ｍｔ＿ｓｅｌｅｃｔ＿ｄｔ＝２（ＩＤによってデータセットを選択する）
ｍｔ＿ｓｅｌｅｃｔ＿ａｔ＝２（ＩＤによって注釈テーブルを選択する）
ｍｔ＿ｓｅｌｅｃｔ＿ａｕ＝２（ＩＤによってアクセスユニットを選択する）
ｍｔ＿ｓｅｌｅｃｔ＿ｂｌ＝１（すべてのペイロードブロックを選択する）
ｍｔ＿ｓｅｌｅｃｔ＿ｄｇ＝１（すべてのデータセットグループを選択する）
ｍｔ＿ｓｅｌｅｃｔ＿ｄｔ＝２（ＩＤによってデータセットを選択する）
ｍｔ＿ｓｅｌｅｃｔ＿ａｔ＝２（ＩＤによって注釈テーブルを選択する）
ｍｔ＿ｓｅｌｅｃｔ＿ａｕ＝２（ＩＤによってアクセスユニットを選択する）
ｍｔ＿ｓｅｌｅｃｔ＿ｂｌ＝１（すべてのペイロードブロックを選択する）
【0125】
各コンテナタイプのためのこれらの一般的な選択設定は個々のコンテナごとにオーバーライドすることができる。コンテナが除外されると、すべてのそれの下位データ構造は、それらの選択設定にかかわらず除外されることに留意されたい。
【0126】
実施形態９：完全性検証の速度を向上させるためのハッシュコードの選択的な記憶
ハッシュコードの記憶は署名検証の速度を改善することができるが、記憶オーバーヘッドが犠牲になる。実施形態６に記載されているように、コンテナレベルがルートに近くなる（ハッシュコードの数が少なくなる）ほど、記憶コストは軽くなり、計算速度を改善することの利益が大きくなる（各ハッシュコードはデータのより大きい塊を表す）。この実施形態では、ＭＴハッシュコード（又はノード）をどのように選択的に記憶することができるかについて説明する。
ハッシュコードの記憶は署名検証の速度を改善することができるが、記憶オーバーヘッドが犠牲になる。実施形態６に記載されているように、コンテナレベルがルートに近くなる（ハッシュコードの数が少なくなる）ほど、記憶コストは軽くなり、計算速度を改善することの利益が大きくなる（各ハッシュコードはデータのより大きい塊を表す）。この実施形態では、ＭＴハッシュコード（又はノード）をどのように選択的に記憶することができるかについて説明する。
【0127】
この目的のために、各コンテナタイプは、バイナリツリー中のリーフと他のノードの両方（実施形態６参照）を含む、それの対応するＭＴハッシュコードが一般に記憶のためにどのように選択されるべきであるかを示すためのフィールドを有する。例えば、フィールドの値は以下であり得る。
０－いずれのノードもない
１－すべてのリーフと中間ノードとを含む、バイナリＭＴ中のすべてのノード
２－すべてのリーフのみ
３－バイナリＭＴの最上位ｍ個のレベルにあるノード
４－最初のｎ個のリーフ
５－バイナリＭＴの最上位ｍ個のレベルにあるすべてのリーフ及びノード
６－バイナリＭＴの最上位ｍ個のレベルにある最初のｎ個のリーフ及びノード
０－いずれのノードもない
１－すべてのリーフと中間ノードとを含む、バイナリＭＴ中のすべてのノード
２－すべてのリーフのみ
３－バイナリＭＴの最上位ｍ個のレベルにあるノード
４－最初のｎ個のリーフ
５－バイナリＭＴの最上位ｍ個のレベルにあるすべてのリーフ及びノード
６－バイナリＭＴの最上位ｍ個のレベルにある最初のｎ個のリーフ及びノード
【0128】
以下は、ファイル（ＭＰＥＧＧ）レベル、データセットグループ（ＤＧ）レベル、データセット（ＤＴ）レベル、注釈テーブル（ＡＴ）レベル及びアクセスユニット（ＡＵ）レベルにおけるＭＴの一般的な記憶モードのための例示的な設定である。
ｍｔ＿ｓｔｏｒｅ＿ｍｐｅｇｇ＝１（ファイルレベル全体にあるすべてのＭＴノードを、ＭＴＲ＿ＤＧであるリーフとともに記憶する）
ｍｔ＿ｓｔｏｒｅ＿ｄｇ＝１（データセットグループレベルにあるすべてのＭＴノードを、ＭＴＲ＿ＤＴであるリーフとともに記憶する）
ｍｔ＿ｓｔｏｒｅ＿ｄｔ＝１（データセットレベルにあるすべてのＭＴノードを、ＭＴＲ＿ＡＴであるリーフとともに記憶する）
ｍｔ＿ｓｔｏｒｅ＿ａｔ＝１（注釈テーブルレベルにあるすべてのＭＴノードを、ＭＴＲ＿ＡＵであるリーフとともに記憶する）
ｍｔ＿ｓｔｏｒｅ＿ａｕ＝０（アクセスユニットレベルにあるＭＴノードは記憶されない）
ｍｔ＿ｓｔｏｒｅ＿ｍｐｅｇｇ＝１（ファイルレベル全体にあるすべてのＭＴノードを、ＭＴＲ＿ＤＧであるリーフとともに記憶する）
ｍｔ＿ｓｔｏｒｅ＿ｄｇ＝１（データセットグループレベルにあるすべてのＭＴノードを、ＭＴＲ＿ＤＴであるリーフとともに記憶する）
ｍｔ＿ｓｔｏｒｅ＿ｄｔ＝１（データセットレベルにあるすべてのＭＴノードを、ＭＴＲ＿ＡＴであるリーフとともに記憶する）
ｍｔ＿ｓｔｏｒｅ＿ａｔ＝１（注釈テーブルレベルにあるすべてのＭＴノードを、ＭＴＲ＿ＡＵであるリーフとともに記憶する）
ｍｔ＿ｓｔｏｒｅ＿ａｕ＝０（アクセスユニットレベルにあるＭＴノードは記憶されない）
【0129】
記憶モード３～６の場合、記憶されるべきバイナリＭＴ中の最上位レベルの数（ｍ）及びリーフの数（ｎ）を指定するために、追加のフィールドが必要とされる。各コンテナタイプのためのこれらの一般的なＭＴ記憶設定は個々のコンテナごとにオーバーライドすることができる。
【0130】
実施形態１０：全面的な又は的を絞った完全性検証
特定の構成要素の完全性を検証するためにマークルツリー上のハッシュコードの一部又は全部が記憶されている場合は、問題の構成要素を対象とするハッシュコードのみを再生成するだけでよい。次いで、問題の構成要素からツリーのルートまで遡るすべてのハッシュコードが検証され、最後に署名が検査される。
特定の構成要素の完全性を検証するためにマークルツリー上のハッシュコードの一部又は全部が記憶されている場合は、問題の構成要素を対象とするハッシュコードのみを再生成するだけでよい。次いで、問題の構成要素からツリーのルートまで遡るすべてのハッシュコードが検証され、最後に署名が検査される。
【0131】
実施形態１１：柔軟なマークルツリー編成－バイナリツリー対Ｋ進ツリー、単一のツリー階層対複数のツリー階層
上記実施形態中の説明は、ＭＰＥＧ－Ｇファイルデータ構造の場合と同様に編成されたマークルツリーの階層に焦点を当てている。各保護されているデータ構造は独立したマークルツリーに関連付けられる。実施形態は一般にバイナリマークルツリーを仮定しており、例えば、ツリー中の各ノードは高々２つの子ノードを有する。したがって、ＭＰＥＦ－Ｇファイルなど、データファイルは、各々がデータコンテナに対応するバイナリマークルツリーの階層を有する。バイナリツリー構成の代替として、Ｋ進マークルツリーは、それぞれがｋ個の下位ノード上での同時のハッシングによって計算されたノードを含む。極端な場合、ｋはリーフの総数に等しく、それによりツリー深さは１になり得る。言い換えれば、ルートは、Ｎ個のリーフすべての連結上での直接ハッシングによって計算される。ハッシュ関数がＯ（Ｎ）の線形時間計算量（ｌｉｎｅａｒ ｔｉｍｅ ｃｏｍｐｌｅｘｉｔｙ）を有し、バイナリモデルとの比較の容易さのために、Ｎ＝２ｎであると仮定すると、Ｎ進マークルツリーのルートを再計算するための時間は、
ＴＮ－ａｒｙ＿ＭＴ＝２（ｎ－１）＊ｔｎｏｄｅ＋２ｎ＊ｔｌｅａｆ
によって与えられ、ここで、ｔｎｏｄｅは、２つのノード上でのハッシングのための時間であり、ｔｌｅａｆは、データ構造上でのハッシングによってリーフを生成するための時間である。
上記実施形態中の説明は、ＭＰＥＧ－Ｇファイルデータ構造の場合と同様に編成されたマークルツリーの階層に焦点を当てている。各保護されているデータ構造は独立したマークルツリーに関連付けられる。実施形態は一般にバイナリマークルツリーを仮定しており、例えば、ツリー中の各ノードは高々２つの子ノードを有する。したがって、ＭＰＥＦ－Ｇファイルなど、データファイルは、各々がデータコンテナに対応するバイナリマークルツリーの階層を有する。バイナリツリー構成の代替として、Ｋ進マークルツリーは、それぞれがｋ個の下位ノード上での同時のハッシングによって計算されたノードを含む。極端な場合、ｋはリーフの総数に等しく、それによりツリー深さは１になり得る。言い換えれば、ルートは、Ｎ個のリーフすべての連結上での直接ハッシングによって計算される。ハッシュ関数がＯ（Ｎ）の線形時間計算量（ｌｉｎｅａｒ ｔｉｍｅ ｃｏｍｐｌｅｘｉｔｙ）を有し、バイナリモデルとの比較の容易さのために、Ｎ＝２ｎであると仮定すると、Ｎ進マークルツリーのルートを再計算するための時間は、
ＴＮ－ａｒｙ＿ＭＴ＝２（ｎ－１）＊ｔｎｏｄｅ＋２ｎ＊ｔｌｅａｆ
によって与えられ、ここで、ｔｎｏｄｅは、２つのノード上でのハッシングのための時間であり、ｔｌｅａｆは、データ構造上でのハッシングによってリーフを生成するための時間である。
【0132】
実施形態６に記載されているように、ノードの最上位ｍ個のレベルが記憶されている、バイナリマークルツリーのルートを再計算するための時間は、
Ｔｂｉｎａｒｙ＿ＭＴ＝［２（ｎ－ｍ＋１）－１＋（ｍ－１）］＊ｔｎｏｄｅ＋２（ｎ－ｍ＋１）＊ｔｌｅａｆ
によって与えられる。
Ｔｂｉｎａｒｙ＿ＭＴ＝［２（ｎ－ｍ＋１）－１＋（ｍ－１）］＊ｔｎｏｄｅ＋２（ｎ－ｍ＋１）＊ｔｌｅａｆ
によって与えられる。
【0133】
１≦ｍ≦ｎである、（２ｍ－１）個のハッシュコードの記憶オーバーヘッドを用いて、２つの手法を比較すると、（１）ｔｌｅａｆ＞＞ｔｎｏｄｅであり、（２）例えば、リーフの最大数が２５６個であるＭＴ＿ＡＵの場合に、リーフの数が比較的小さく、（３）バイナリマークルツリー手法のためのノードとリーフとの混合記憶がないと仮定すると、
ＴＮ－ａｒｙ＿ＭＴ≒（２ｎ－２ｍ＋１）＊ｔｌｅａｆ
Ｔｂｉｎａｒｙ＿ＭＴ≒２（ｎ－ｍ＋１）＊ｔｌｅａｆ
ｍ＝ｎであるとき、ＴＮ－ａｒｙ＿ＭＴ≒ｔｌｅａｆであるが、Ｔｂｉｎａｒｙ＿ＭＴ≒２＊ｔｌｅａｆである。
ｍ＝ｎ－ｌであり、１≦ｌ≦（ｎ－１）であるとき、
Ｔｂｉｎａｒｙ＿ＭＴ≒２（ｎ－ｍ＋１）＊ｔｌｅａｆ＝２（ｌ＋１）＊ｔｌｅａｆ
ＴＮ－ａｒｙ＿ＭＴ≒［２ｎ－２（ｎ－ｌ）＋１］＊ｔｌｅａｆ＞２（ｌ＋１）＊ｔｌｅａｆ ＊｛２［ｎ－（ｌ＋１）］－２［ｎ－２（ｌ＋１）］｝＞２（ｌ＋１）＊ｔｌｅａｆ≒Ｔｂｉｎａｒｙ＿ＭＴ
である。
ＴＮ－ａｒｙ＿ＭＴ≒（２ｎ－２ｍ＋１）＊ｔｌｅａｆ
Ｔｂｉｎａｒｙ＿ＭＴ≒２（ｎ－ｍ＋１）＊ｔｌｅａｆ
ｍ＝ｎであるとき、ＴＮ－ａｒｙ＿ＭＴ≒ｔｌｅａｆであるが、Ｔｂｉｎａｒｙ＿ＭＴ≒２＊ｔｌｅａｆである。
ｍ＝ｎ－ｌであり、１≦ｌ≦（ｎ－１）であるとき、
Ｔｂｉｎａｒｙ＿ＭＴ≒２（ｎ－ｍ＋１）＊ｔｌｅａｆ＝２（ｌ＋１）＊ｔｌｅａｆ
ＴＮ－ａｒｙ＿ＭＴ≒［２ｎ－２（ｎ－ｌ）＋１］＊ｔｌｅａｆ＞２（ｌ＋１）＊ｔｌｅａｆ ＊｛２［ｎ－（ｌ＋１）］－２［ｎ－２（ｌ＋１）］｝＞２（ｌ＋１）＊ｔｌｅａｆ≒Ｔｂｉｎａｒｙ＿ＭＴ
である。
【0134】
完全性検証の速度に関する上記の計算に基づいて、リーフを生成することと比較して、ノード上でのハッシングの計算時間は無視できるという仮定の下で、以下のことを結論付けることができる。
記憶オーバーヘッドが（２ｎ－４）回のハッシュ以下であるとき、バイナリＭＴ手法はより速くなる。その理由は、ｍ＝（ｎ－１）又は記憶オーバーヘッドが［２（ｎ－１）－１］であるとき、Ｔｂｉｎａｒｙ＿ＭＴ≒４ｔｌｅａｆであるためである。この計算時間は、記憶オーバーヘッドが、次のレベルをカバーするのに十分に大きくなるまで、例えば、ｍ＝ｎ又は記憶オーバーヘッドが（２ｎ－１）になるまで同じままである。一方、Ｎ進手法の場合、記憶オーバーヘッドが（２ｎ－４）回のハッシュ以下であるとき、ＴＮ－ａｒｙ＿ＭＴ≧４ｔｌｅａｆである。
Ｎ進ツリー手法は、記憶オーバーヘッドが（２ｎ－３）回のハッシュと２ｎ回のハッシュとの間にあるときにより速くなる。
バイナリＭＴ手法では、記憶オーバーヘッドが２ｎ回のハッシュを超えるとき、２ｎ個のリーフが最初に記憶され得、残りのオーバーヘッドは、内部ＭＴノードを記憶するために使用され得、それにより検証速度のさらなる向上につながる。
記憶オーバーヘッドが（２ｎ－４）回のハッシュ以下であるとき、バイナリＭＴ手法はより速くなる。その理由は、ｍ＝（ｎ－１）又は記憶オーバーヘッドが［２（ｎ－１）－１］であるとき、Ｔｂｉｎａｒｙ＿ＭＴ≒４ｔｌｅａｆであるためである。この計算時間は、記憶オーバーヘッドが、次のレベルをカバーするのに十分に大きくなるまで、例えば、ｍ＝ｎ又は記憶オーバーヘッドが（２ｎ－１）になるまで同じままである。一方、Ｎ進手法の場合、記憶オーバーヘッドが（２ｎ－４）回のハッシュ以下であるとき、ＴＮ－ａｒｙ＿ＭＴ≧４ｔｌｅａｆである。
Ｎ進ツリー手法は、記憶オーバーヘッドが（２ｎ－３）回のハッシュと２ｎ回のハッシュとの間にあるときにより速くなる。
バイナリＭＴ手法では、記憶オーバーヘッドが２ｎ回のハッシュを超えるとき、２ｎ個のリーフが最初に記憶され得、残りのオーバーヘッドは、内部ＭＴノードを記憶するために使用され得、それにより検証速度のさらなる向上につながる。
【0135】
ノード上でのハッシングの計算時間のみを考えると、
Ｔｂｉｎａｒｙ＿ＭＴ＿ｎｏｄｅｓ＿ｏｎｌｙ＝［２（ｎ－ｍ＋１）－１＋（ｍ－１）］＊ｔｎｏｄｅ＜２（ｎ－１）＊ｔｎｏｄｅ＜ＴＮ－ａｒｙ＿ＭＴ＿ｎｏｄｅｓ ｏｎｌｙ
であるので、バイナリ手法は、ｍ＞１であるとき、常にＮ進手法よりも優れている。
Ｔｂｉｎａｒｙ＿ＭＴ＿ｎｏｄｅｓ＿ｏｎｌｙ＝［２（ｎ－ｍ＋１）－１＋（ｍ－１）］＊ｔｎｏｄｅ＜２（ｎ－１）＊ｔｎｏｄｅ＜ＴＮ－ａｒｙ＿ＭＴ＿ｎｏｄｅｓ ｏｎｌｙ
であるので、バイナリ手法は、ｍ＞１であるとき、常にＮ進手法よりも優れている。
【0136】
したがって、全体として、バイナリＭＴ手法は、ノードの最上位ｍ≧（ｎ－１）個のレベルのみを記憶する事例、又はすべてのリーフ＋ルートを記憶する事例（ｍ＝１）に対応する、（２ｎ－３）回のハッシュから（２ｎ＋２）回のハッシュまでの記憶オーバーヘッドの狭い範囲内を除いて、Ｎ進手法よりも良い性能を有する。そのような特定の記憶オーバーヘッドの制約の下では、検証速度における明らかな勝者はいない。
【0137】
これらの分析結果は、選択されたリーフの数（実施形態８）と、記憶モード設定（実施形態９）とに基づいて、バイナリマークルツリー手法かＮ進マークルツリー手法かの選定のための指針を与えることができる。ファイルがサーバに常駐し、検証がクライアントにおいて行われる、クライアントサーバ設定においては、バイナリ手法ではｎ個のノードのみを受信機に送り、一方、Ｎ進手法では、（２ｎ－１）個のリーフノードを送る必要があることに留意されたい。
【0138】
また、より柔軟なマークルツリー編成を可能にすることに利点があり得る。１つの柔軟性は、ファイルごとに複数のマークルツリーを有すること、例えば、各マークルツリーが、独立して完全な全体として保護されるべき完全性をもつ同じコホート（ｃｏｈｏｒｔ）に属するデータを含むか、又は、各マークルツリーが特定の完全性保護要件のためのパラメータの異なるセットをもつ、ＭＴ＿１、ＭＴ＿２、…を有することを可能にすることである。また、例えば、ｋ個のマークルツリーをマージして、１レベル深いｋ個のマークルツリーのルートのハッシュとして計算されたＭＴ全体のルート、ＭＴＲ＿Ｏｖｅｒａｌｌ＝Ｈａｓｈ（ＭＴＲ＿１｜ＭＴＲ＿２｜…｜ＭＴＲ＿ｋ）をもつ１つの大きいツリーにすることによって、ネストされたマークルツリーをサポートすることが可能である。
【0139】
実施形態１２：関数構成要素とデータ構成要素とのためのマークルツリーへの分割
実施形態１０に関係する代替実施形態は、関数構成要素とデータ構成要素とを別個のマークルツリー階層に編成し、次いで、それらのマークルツリー階層を結合して新しいルート全体を形成することである。関数構成要素は、異なるコンテナレベルにある、ヘッダ構造と、メタデータ構造と、保護構造とを含み、データ構成要素は、ペイロードブロックデータを含んでいる構造に対応する。関数構成要素は、一般に重要であり、サイズが小さいので、データ構成要素の選択的な保護を可能にしながら、すべての機能構成要素が、選択なしにマークルツリーによって保護されるようにすることが妥当であると思われる。そのような構成の１つの潜在的な利点は関数構成要素のより速い検証である。例えば、データセットのメタデータを検証するために、データセット中の個々のアクセスユニットのハッシュコードは検証に関与しない。データ構成要素のためのマークルツリーのルートにあるハッシュコードのみが検証のために使用される。以下の例は、関数構成要素とデータ構成要素とを２つの別個のマークルツリーに分割し、次いで、それらを結合して単一のルート全体にするアイデアを示している。
ＭＴＲ＿ＭＰＥＧＧ
ＭＴＲ＿Ｆｕｎｃｔｉｏｎａｌ
ＭＴＲ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＧ＿１＝Ｈａｓｈ（Ｈｅａｄｅｒ＿ＤＧ＿１｜Ｍｅｔａｄａｔａ＿ＤＧ＿１｜Ｐｒｏｔｅｃｔｉｏｎ＿ＤＧ＿１｜ＭＴ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＴ＿１１｜ＭＴ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＴ＿１２｜…）
ＭＴＲ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＧ＿２＝Ｈａｓｈ（Ｈｅａｄｅｒ＿ＤＧ＿２｜Ｍｅｔａｄａｔａ＿ＤＧ＿２｜Ｐｒｏｔｅｃｔｉｏｎ＿ＤＧ＿２｜ＭＴ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＴ＿２１｜ＭＴ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＴ＿２２｜…）
…
ＭＴＲ＿Ｄａｔａ
ＭＴＲ＿Ｄａｔａ＿ＤＧ＿１
ＭＴＲ＿Ｄａｔａ＿ＤＧ＿２
…
実施形態１０に関係する代替実施形態は、関数構成要素とデータ構成要素とを別個のマークルツリー階層に編成し、次いで、それらのマークルツリー階層を結合して新しいルート全体を形成することである。関数構成要素は、異なるコンテナレベルにある、ヘッダ構造と、メタデータ構造と、保護構造とを含み、データ構成要素は、ペイロードブロックデータを含んでいる構造に対応する。関数構成要素は、一般に重要であり、サイズが小さいので、データ構成要素の選択的な保護を可能にしながら、すべての機能構成要素が、選択なしにマークルツリーによって保護されるようにすることが妥当であると思われる。そのような構成の１つの潜在的な利点は関数構成要素のより速い検証である。例えば、データセットのメタデータを検証するために、データセット中の個々のアクセスユニットのハッシュコードは検証に関与しない。データ構成要素のためのマークルツリーのルートにあるハッシュコードのみが検証のために使用される。以下の例は、関数構成要素とデータ構成要素とを２つの別個のマークルツリーに分割し、次いで、それらを結合して単一のルート全体にするアイデアを示している。
ＭＴＲ＿ＭＰＥＧＧ
ＭＴＲ＿Ｆｕｎｃｔｉｏｎａｌ
ＭＴＲ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＧ＿１＝Ｈａｓｈ（Ｈｅａｄｅｒ＿ＤＧ＿１｜Ｍｅｔａｄａｔａ＿ＤＧ＿１｜Ｐｒｏｔｅｃｔｉｏｎ＿ＤＧ＿１｜ＭＴ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＴ＿１１｜ＭＴ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＴ＿１２｜…）
ＭＴＲ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＧ＿２＝Ｈａｓｈ（Ｈｅａｄｅｒ＿ＤＧ＿２｜Ｍｅｔａｄａｔａ＿ＤＧ＿２｜Ｐｒｏｔｅｃｔｉｏｎ＿ＤＧ＿２｜ＭＴ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＴ＿２１｜ＭＴ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＴ＿２２｜…）
…
ＭＴＲ＿Ｄａｔａ
ＭＴＲ＿Ｄａｔａ＿ＤＧ＿１
ＭＴＲ＿Ｄａｔａ＿ＤＧ＿２
…
【0140】
この例では、ルート全体ＭＴＲ＿ＭＰＥＧＧはＨａｓｈ（ＭＴＲ＿Ｆｕｎｃｔｉｏｎａｌ｜ＭＴＲ＿Ｄａｔａ）としての関数マークルツリーとデータマークルツリーとのルートに依存する。ＭＴＲ＿Ｆｕｎｃｔｉｏｎａｌは、Ｄａｔａｓｅｔ Ｇｒｏｕｐレベルにある関数ＭＴルートの連結上でのハッシングによって取得される。ＭＴＲ＿Ｆｕｎｃｔｉｏｎａｌ＿ＤＧによってプレフィックスされているそのようなルートは、Ｄａｔａｓｅｔ Ｇｒｏｕｐ Ｈｅａｄｅｒと、Ｍｅｔａｄａｔａと、Ｐｒｏｔｅｃｔｉｏｎと、Ｄａｔａｓｅｔレベルにある下位関数ＭＴルートとの連結上でのハッシングによって生成される。ルート値を生成する際に、ハッシュ関数は、複数の入力と同じレベルにあるデータ構成要素を取るので、これはＫ進マークルツリーに似ている。
【0141】
実施形態１３：タイムスタンプ
マークルツリーによる完全性保護の鮮度を示すために各マークルツリーデータ構造中にタイムスタンプを含めることができる。タイムスタンプは、最上位マークルツリーのルートＭＴＲ＿ＭＰＥＧＧとともに記憶され、署名される。さらに、ＭＴデータの期限切れ前に、更新されたタイムスタンプを用いてＭＴルート全体上の署名が自動的に再生成されるように、鮮度周期を課すことができる。期限切れタイムスタンプは、ファイルが最新でないことがあり、現行バージョンになりすまし、最近の変更を取り消すために侵入者によって使用されたより古いバージョンであり得ることを示す。
マークルツリーによる完全性保護の鮮度を示すために各マークルツリーデータ構造中にタイムスタンプを含めることができる。タイムスタンプは、最上位マークルツリーのルートＭＴＲ＿ＭＰＥＧＧとともに記憶され、署名される。さらに、ＭＴデータの期限切れ前に、更新されたタイムスタンプを用いてＭＴルート全体上の署名が自動的に再生成されるように、鮮度周期を課すことができる。期限切れタイムスタンプは、ファイルが最新でないことがあり、現行バージョンになりすまし、最近の変更を取り消すために侵入者によって使用されたより古いバージョンであり得ることを示す。
【0142】
代替として、いくつかのデータ構造が特定の日付によって特徴付けられているとき、その日付はそれらのデータ構造中の入力として（例えば追加のリーフとして）使用される。例えば、ユーザが数日の間に患者のゲノムデータに関するいくつかの分析を実行したと仮定する。時間の異なる瞬間（異なる時、異なる日）に変更された複数のデータ構造中に分析が反映されている場合、データ構造の各々は、マークルツリーの新しい階層全体を構築するときに異なるタイムスタンプを有することがある。ユーザは、ＭＴＲ＿ＭＰＥＧＧに署名するときにタイムスタンプを含め得る。署名のタイムスタンプは、好ましくは最新のタイムスタンプである。
【0143】
実施形態１４：トランスポートモードのための使用
ＭＰＥＧ－Ｇはデータの記憶及びトランスポートのための選択肢を定義している。一実施形態では、データをトランスポートするとき、メッセージも完全性保護することができる。
ＭＰＥＧ－Ｇはデータの記憶及びトランスポートのための選択肢を定義している。一実施形態では、データをトランスポートするとき、メッセージも完全性保護することができる。
【0144】
データ構造、例えばデータのブロックが送られるときに、メッセージは以下から始まり得る。
データ構造／データのブロックの完全性を検証するために必要とされるマークルツリー中のノード、及び
ファイル署名。
データ構造／データのブロックの完全性を検証するために必要とされるマークルツリー中のノード、及び
ファイル署名。
【0145】
これにより、最初にファイル全体を受信する必要なしに、ファイルの一部である、データのブロックの完全性とデータのブロックとを検証することが可能になる。
【0146】
メッセージは、例えば、これが最初のメッセージである場合、ＭＴＲ＿ＭＰＥＧＧ上の署名を含み得る。より後のメッセージは、再びこの署名を含むことは冗長であるので、その必要がない。この署名はまた、最初のメッセージについて検証されるだけでよい。このことは、データのｎ個のブロックがクライアントによってサーバから取り出される、図６に示されている。データのこのｎ個のブロックはｎ個のメッセージ中で交換される。最初のメッセージは、ファイル署名と、（受信機においてまだ利用可能でない場合）署名者の公開鍵と、データの最初のブロックを検証するために必要とされるマークルツリー経路に関与するノードと、データのブロック自体とを含む。クライアントがこの情報を受信すると、クライアントは、受信されたデータ（ブロック１）上のハッシュを計算し、生成されたハッシュと経路中の必要とされるノードとを使用してツリーのルートを計算し、生成されたルートと署名者の公開鍵とを使用して署名を検証する。
【0147】
図６にはクライアント６１０とサーバ６２０とが示されている。メッセージ１（６３０）は、署名（６３１）と、ブロック１を検証するために必要とされるマークルツリー経路に関与するノード（６３１）と、ブロック１（６３３）とを含む。メッセージ２（６４０）は、ブロック２を検証するために必要とされるマークルツリー経路に関与するノード（６４１）と、ブロック２（６４２）とを含む。メッセージ３（６５０）は、ブロック３を検証するために必要とされるマークルツリー経路に関与するノード（６５１）と、ブロック３（６５２）とを含む。
【0148】
後で受信されたメッセージの処理は同様であるが、署名はファイル全体について一意であるので、それ以上署名を含める／検査する必要がない点が異なる。
【0149】
代替ソリューションベースとの比較
上記の実施形態は、ＭＰＥＧ－Ｇファイルの長期的な完全性保護を達成するために、それらのデータ構造中のマークルツリーを使用する。代替ソリューションは、２３０９２－３：２０１９－３、７．４中の現在のＭＰＥＧ－Ｇソリューションを変更／拡張することを含む。
上記の実施形態は、ＭＰＥＧ－Ｇファイルの長期的な完全性保護を達成するために、それらのデータ構造中のマークルツリーを使用する。代替ソリューションは、２３０９２－３：２０１９－３、７．４中の現在のＭＰＥＧ－Ｇソリューションを変更／拡張することを含む。
【0150】
例えば、代替ソリューションは、長期的な署名アルゴリズムの使用、及び署名されたコンテナを結合することを可能にするプロシージャを定義することという２つの変更を含み得る。
【0151】
第１の点は、ＥＣＤＳＡの代わりに、耐量子アルゴリズム、例えば、ＬＭＳ、ＸＭＳＳ又はＳＰＨＩＮＣＳなど、ハッシュベースの署名アルゴリズムを使用することによって対処することができる。
【0152】
第２の点に関しては、異なる手法を検討することができる。以下では、３つの選択肢について説明する。
１．第１の手法は、ファイルヘッダ中に、一意のファイル識別子、例えばランダムに生成された２５６ビット長の識別子を含めることを含む。このファイルヘッダはシステム管理者によって署名される。ファイル中のすべてのデータコンテナを結び付けるために、ＭＰＥＧ－Ｇ仕様は、コンテナが署名されると、この署名されたコンテナが一意のファイル識別子を含むようなやり方で更新される。これが行われた場合、ユーザがファイルからデータコンテナを取り出すときに、ユーザは以下を行う必要がある。
署名メインファイルヘッダを取り出し、検証し、ファイル識別子ＩＤ＿ｆｉｌｅを抽出する。
データコンテナを取り出し、それの署名を検証し、データコンテナ中のＩＤがＩＤ＿ｆｉｌｅに等しいことを検査する。
２．前の手法は、異なるＭＰＥＧ Ｇファイル中のデータがマージされ得るものである。２つのファイルがマージされると、新しいファイル識別子を含む新しいファイルヘッダが作成される。ファイルヘッダは、前のファイルの識別子を含むマージング履歴を含み得る。これが行われた場合、ユーザがファイルからデータコンテナを取り出すときに、ユーザは以下を行う必要がある。
署名メインファイルヘッダを取り出し、検証し、ファイル識別子ＩＤ＿ｆｉｌｅ、並びに前のマージされていないファイルからの前のファイル識別子を抽出する。
データコンテナを取り出し、それの署名を検証し、データコンテナ中のＩＤが、ＩＤ＿ｆｉｌｅ、又は、前のマージされていないファイルからのＩＤ＿ｆｉｌｅのうちの１つに等しいことを検査する。
３．別の代替手法は、各コンテナ中に一意の長い識別子（例えば、ランダムに生成された２５６ビット長の識別子）を有することを含む。コンテナが署名されたとき、署名は親コンテナの識別子を含み得る。コンテナの署名が検証されるべきである場合、以下のプロセスに従う。
コンテナの署名を検査し、親コンテナのＩＤを取り出す
親コンテナのＩＤがＭＰＥＧ－Ｇヘッダファイルに対応するまで、以下を繰り返す
署名を検査する
親コンテナのＩＤを取り出す
４．別の選択肢は、セクション７．４中のＭＰＥＧ－Ｇ Ｐａｒｔ ３において指定されている保護ボックスを使用し、それらを結合するプロセスを定義することである。例えば、アクセスユニット中のデータのブロックが検証されるべきであるとき、以下のステップのうちの１つ又は複数或いはすべてが実行され得る。
１．所与のブロックのためのアクセスユニット保護中にデジタル署名が存在しなければならない。
２．この第１の署名の検証が成功しなければならない。
３．データセット保護ボックス中のデータセットレベルにある所与のアクセスユニットのためのアクセスユニット保護の署名がなければならない。
４．この第２の署名の検証が成功しなければならない。
５．データセットグループ保護ボックス中のデータセットグループレベルにある所与のデータセットのためのデータセット保護ボックスの署名がなければならない。
６．この第３の署名の検証が成功しなければならない。
１．第１の手法は、ファイルヘッダ中に、一意のファイル識別子、例えばランダムに生成された２５６ビット長の識別子を含めることを含む。このファイルヘッダはシステム管理者によって署名される。ファイル中のすべてのデータコンテナを結び付けるために、ＭＰＥＧ－Ｇ仕様は、コンテナが署名されると、この署名されたコンテナが一意のファイル識別子を含むようなやり方で更新される。これが行われた場合、ユーザがファイルからデータコンテナを取り出すときに、ユーザは以下を行う必要がある。
署名メインファイルヘッダを取り出し、検証し、ファイル識別子ＩＤ＿ｆｉｌｅを抽出する。
データコンテナを取り出し、それの署名を検証し、データコンテナ中のＩＤがＩＤ＿ｆｉｌｅに等しいことを検査する。
２．前の手法は、異なるＭＰＥＧ Ｇファイル中のデータがマージされ得るものである。２つのファイルがマージされると、新しいファイル識別子を含む新しいファイルヘッダが作成される。ファイルヘッダは、前のファイルの識別子を含むマージング履歴を含み得る。これが行われた場合、ユーザがファイルからデータコンテナを取り出すときに、ユーザは以下を行う必要がある。
署名メインファイルヘッダを取り出し、検証し、ファイル識別子ＩＤ＿ｆｉｌｅ、並びに前のマージされていないファイルからの前のファイル識別子を抽出する。
データコンテナを取り出し、それの署名を検証し、データコンテナ中のＩＤが、ＩＤ＿ｆｉｌｅ、又は、前のマージされていないファイルからのＩＤ＿ｆｉｌｅのうちの１つに等しいことを検査する。
３．別の代替手法は、各コンテナ中に一意の長い識別子（例えば、ランダムに生成された２５６ビット長の識別子）を有することを含む。コンテナが署名されたとき、署名は親コンテナの識別子を含み得る。コンテナの署名が検証されるべきである場合、以下のプロセスに従う。
コンテナの署名を検査し、親コンテナのＩＤを取り出す
親コンテナのＩＤがＭＰＥＧ－Ｇヘッダファイルに対応するまで、以下を繰り返す
署名を検査する
親コンテナのＩＤを取り出す
４．別の選択肢は、セクション７．４中のＭＰＥＧ－Ｇ Ｐａｒｔ ３において指定されている保護ボックスを使用し、それらを結合するプロセスを定義することである。例えば、アクセスユニット中のデータのブロックが検証されるべきであるとき、以下のステップのうちの１つ又は複数或いはすべてが実行され得る。
１．所与のブロックのためのアクセスユニット保護中にデジタル署名が存在しなければならない。
２．この第１の署名の検証が成功しなければならない。
３．データセット保護ボックス中のデータセットレベルにある所与のアクセスユニットのためのアクセスユニット保護の署名がなければならない。
４．この第２の署名の検証が成功しなければならない。
５．データセットグループ保護ボックス中のデータセットグループレベルにある所与のデータセットのためのデータセット保護ボックスの署名がなければならない。
６．この第３の署名の検証が成功しなければならない。
【0153】
ステップのいずれかが失敗した場合、完全性検証プロセスは失敗する。ステップが成功した場合、次のステップが評価される。
【0154】
すべての上記のステップが個々に実行される場合でも、現在のＭＰＥＧ－Ｇ規格には、それらを結合するこの検証プロセスが欠けている。さらに、すべてのデータセットグループを結合するファイル全体上の署名の定義はない。
【0155】
上記の方法を、マークルツリーを使用する実施形態と比較すると、マークルツリーを使用する実施形態がより効率的で包括的である。それにはいくつかの理由がある。
ａ）ＭＴベースのソリューションにより、個々の構成要素の完全性だけでなく、それらがＭＰＥＧ－Ｇファイル全体の一部として一緒に属することをも検証することが可能になる。それはファイル中のデータ構造の不正な追加、削除又は並べ替えを防ぐ。
ｂ）これの第１の理由は、ＭＰＥＧ－Ｇ手法が、コンテナごとに署名を記憶することを必要とし、ハッシュベースの署名（例えば、ＳＰＨＩＮＣＳ）が大きいためである。例えば、Ｂｅｒｎｓｔｅｉｎらによる論文「ＳＰＨＩＮＣＳ：ｐｒａｃｔｉｃａｌ ｓｔａｔｅｌｅｓｓ ｈａｓｈ－ｂａｓｅｄ ｓｉｇｎａｔｕｒｅｓ」を参照されたい。
ｃ）各コンテナのためのハッシュベースの署名は単独で検証される必要があるので、計算オーバーヘッドははるかに大きくなる。
ａ）ＭＴベースのソリューションにより、個々の構成要素の完全性だけでなく、それらがＭＰＥＧ－Ｇファイル全体の一部として一緒に属することをも検証することが可能になる。それはファイル中のデータ構造の不正な追加、削除又は並べ替えを防ぐ。
ｂ）これの第１の理由は、ＭＰＥＧ－Ｇ手法が、コンテナごとに署名を記憶することを必要とし、ハッシュベースの署名（例えば、ＳＰＨＩＮＣＳ）が大きいためである。例えば、Ｂｅｒｎｓｔｅｉｎらによる論文「ＳＰＨＩＮＣＳ：ｐｒａｃｔｉｃａｌ ｓｔａｔｅｌｅｓｓ ｈａｓｈ－ｂａｓｅｄ ｓｉｇｎａｔｕｒｅｓ」を参照されたい。
ｃ）各コンテナのためのハッシュベースの署名は単独で検証される必要があるので、計算オーバーヘッドははるかに大きくなる。
【0156】
ＧＡ４ＧＨファイル中の完全性保護を保証するための適用例
Ｇｌｏｂａｌ Ａｌｌｉａｎｃｅ ｆｏｒ Ｇｅｎｏｍｉｃｓ ａｎｄ Ｈｅａｌｔｈ（ＧＡ４ＧＨ）は、それの論文（「ＧＡ４ＧＨ Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ」、２０１９年１０月２１日）において、その後に交換される６４キロバイトの個々のブロックをどのように暗号化し、完全性保護するかについて説明している。ブロックの各々が暗号化され、メッセージ認証コード（ＭＡＣ）が追加される。しかしながら、そのソリューションは、攻撃者が通信中にブロック全体を挿入し、削除し、又は並べ替えることを防がない（このことはＣｒｙｐｔ４ＧＨ、セクション１．１に述べられている）。
Ｇｌｏｂａｌ Ａｌｌｉａｎｃｅ ｆｏｒ Ｇｅｎｏｍｉｃｓ ａｎｄ Ｈｅａｌｔｈ（ＧＡ４ＧＨ）は、それの論文（「ＧＡ４ＧＨ Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ」、２０１９年１０月２１日）において、その後に交換される６４キロバイトの個々のブロックをどのように暗号化し、完全性保護するかについて説明している。ブロックの各々が暗号化され、メッセージ認証コード（ＭＡＣ）が追加される。しかしながら、そのソリューションは、攻撃者が通信中にブロック全体を挿入し、削除し、又は並べ替えることを防がない（このことはＣｒｙｐｔ４ＧＨ、セクション１．１に述べられている）。
【0157】
この問題を処理するための手法は、６４キロバイトのそれらのブロックの各々がリーフである、マークルツリーを定義することを含む。これは実施形態１中のレベル１と等価である。データのブロックはまた、実施形態２の場合と同様に、個々の小さいマークルツリーであり得る。
【0158】
マークルツリーのルートは署名され得るか、又は代替的に、Ｃｒｙｐｔ４ＧＨの場合と同様に、同じ鍵とＭＡＣアルゴリズムとを使用してＭＡＣを計算することができる。
【0159】
６４キロバイトのｎ個のブロックがあると仮定する。データのブロックが送信されるべきであるとき、以下の情報が送られるべきである。
ａ）マークルツリールート上の署名（又はＭＡＣ）、及び
ｂ）データのブロックを検査することを可能にする、バイナリマークルツリー中の対応するｌｏｇ（ｎ）個のノード（これはブロックインデックスとマークルツリーのノードＩＤとを含む）、
ｃ）データの暗号化され、ＭＡＣ保護されたブロック（Ｃｒｙｐｔ４ｇｈによれば、最大６４キロバイトのサイズ）。
ａ）マークルツリールート上の署名（又はＭＡＣ）、及び
ｂ）データのブロックを検査することを可能にする、バイナリマークルツリー中の対応するｌｏｇ（ｎ）個のノード（これはブロックインデックスとマークルツリーのノードＩＤとを含む）、
ｃ）データの暗号化され、ＭＡＣ保護されたブロック（Ｃｒｙｐｔ４ｇｈによれば、最大６４キロバイトのサイズ）。
【0160】
データをトランスポートするときの潜在的な断片化問題により、ブロックサイズがＢ＝６４キロバイトになるように選定される場合、上記のポイントａ）及びｂ）中の追加の完全性データが考慮され得ることに留意されたい。このことは、ブロックの合計サイズが最大でＢ＝６４キロバイトになり得、データブロックは、ａ）及びｂ）によって生じるオーバーヘッドにより幾分小さくなり得ることを意味する。
【0161】
メッセージを受信すると、受信当事者は、マークルツリー中の受信されたｌｏｇ（ｎ）個のノードを使用して、マークルツリーのルートを再計算し、データのブロックの位置を特定する。次いで、受信当事者はマークルツリー上の署名を検査する。最後に、受信当事者はデータの受信されたブロックを検査する。ルート署名は最初のメッセージについて検証するだけでよいことに留意されたい。これは実施形態１４の場合と同様である。
【0162】
Ｃｒｙｐｔ４ＧＨ、セクション１．１中の記述にもかかわらず、Ｃｒｙｐｔ４ＧＨの現在の規格はまた、例えば、データのブロック中にインデックスが含められる場合に、データブロックの不正な挿入、削除又は並べ替えを防ぐために、何らかの完全性保護を提供し得ることを確認されたい。この特徴は独立して重要である。このインデックスはブロックの相対位置を特定する。このインデックスがＣｒｙｐｔ４ＧＨにおける各交換ブロック中に含められた場合、それ以上ブロックを並べ替えることは不可能になる。受信機は、このインデックスに基づいて重複がないことを検査することもできる。受信機が、インデックスｋをもつブロックを受信した場合、受信機は、それが、ブロックインデックス１、２、…、（ｋ－１）をもつすべてのブロックを受信したかどうかをも検査し得る。
【0163】
この最後の「インデックスベースの」手法はＭＴベースの手法とは異なる。１つの利点は、「インデックスベースの」手法は、データがどのように送られるかについてのものであるが、ＭＴ手法は、データがどのように記憶されるかについての情報をも与えることである。このことは、攻撃者が、パケットを送るプロセスに影響を及ぼすことができる場合、攻撃者は、インデックスを正しい順序で配置しても、ブロックを入れ替え得ることを意味する。受信当事者は、その場合、間違った順序でファイルをアセンブルすることがある。ＭＴは、ブロックがどのように編成され、ファイル中に記憶されるかについての情報を与えるので、ＭＴベースの手法ではこのことは実行不可能である。
【0164】
図７ａは、デジタルデータ構造中のデータを符号化するための符号化方法７００の一実施形態の一例を概略的に示している。本符号化方法は、
データを複数のデータブロックとして取得するステップ（７０５）と、
複数のデータブロックにハッシュ関数を適用することによって、複数のデータブロックのための複数のハッシュ値を計算するステップ（７１０）と、
複数のハッシュ値についての第１のハッシュツリーを計算するステップ（７１５）であって、複数のハッシュ値が第１のハッシュツリーのリーフに割り当てられ、第１のハッシュツリーの１つ又は複数のより高いレベルが生成される、第１のハッシュツリーを計算するステップ（７１５）と、
データ構造中に複数のデータブロックと第１のハッシュツリーの一部とを含めるステップ（７２０）であって、第１のハッシュツリーの前記一部が第１のハッシュツリーのリーフの少なくとも一部を含まない、データ構造中に複数のデータブロックと第１のハッシュツリーの一部とを含めるステップ（７２０）と
を有する。
複数のゲノムデータブロックを取得するステップは、ゲノムデータブロックを直接受信するステップを有し得る。
データを複数のデータブロックとして取得するステップ（７０５）と、
複数のデータブロックにハッシュ関数を適用することによって、複数のデータブロックのための複数のハッシュ値を計算するステップ（７１０）と、
複数のハッシュ値についての第１のハッシュツリーを計算するステップ（７１５）であって、複数のハッシュ値が第１のハッシュツリーのリーフに割り当てられ、第１のハッシュツリーの１つ又は複数のより高いレベルが生成される、第１のハッシュツリーを計算するステップ（７１５）と、
データ構造中に複数のデータブロックと第１のハッシュツリーの一部とを含めるステップ（７２０）であって、第１のハッシュツリーの前記一部が第１のハッシュツリーのリーフの少なくとも一部を含まない、データ構造中に複数のデータブロックと第１のハッシュツリーの一部とを含めるステップ（７２０）と
を有する。
複数のゲノムデータブロックを取得するステップは、ゲノムデータブロックを直接受信するステップを有し得る。
【0165】
図７ｂは、デジタルデータ構造中の選択されたゲノムデータを検証するための検証方法７５０の一実施形態の一例を概略的に示している。検証方法７５０は、
データ構造の少なくとも一部を受信するステップ（７５５）であって、データ構造が、複数のデータブロックとハッシュツリーの一部とを含み、第１のハッシュツリーのリーフの少なくとも一部を含まない、データ構造の少なくとも一部を受信するステップ（７５５）と、
データ完全性検証のために選択されたデータ構造中のデータブロックにハッシュ関数を適用することによって、選択されたデータブロックのための複数のハッシュ値を計算するステップ（７６０）と、
検証のために選択されたデータブロックから始まる、対応するハッシュツリーのルートまでの経路を特定するステップ（７６５）と、
データ構造中で利用可能な場合に、経路に沿ったハッシュツリーのためのハッシュ値を取り出すステップ（７７０）、又はそのようなハッシュ値を計算するステップと、
少なくとも計算された複数のハッシュ値からハッシュツリーのルートを検証するステップ（７７５）と
を有する。
データ構造の少なくとも一部を受信するステップ（７５５）であって、データ構造が、複数のデータブロックとハッシュツリーの一部とを含み、第１のハッシュツリーのリーフの少なくとも一部を含まない、データ構造の少なくとも一部を受信するステップ（７５５）と、
データ完全性検証のために選択されたデータ構造中のデータブロックにハッシュ関数を適用することによって、選択されたデータブロックのための複数のハッシュ値を計算するステップ（７６０）と、
検証のために選択されたデータブロックから始まる、対応するハッシュツリーのルートまでの経路を特定するステップ（７６５）と、
データ構造中で利用可能な場合に、経路に沿ったハッシュツリーのためのハッシュ値を取り出すステップ（７７０）、又はそのようなハッシュ値を計算するステップと、
少なくとも計算された複数のハッシュ値からハッシュツリーのルートを検証するステップ（７７５）と
を有する。
【0166】
当業者に明らかになるように、本方法を実行する多くの異なるやり方が可能である。例えば、ステップの順序は、示されている順序で実行することができるが、ステップの順序は変更することができるか、又は、いくつかのステップは並行して実行され得る。その上、ステップ間に他の方法のステップが挿入され得る。挿入されたステップは、本明細書で説明するような本方法の改良を表すこともあり、本方法に関係しないこともある。例えば、いくつかのステップは、少なくとも部分的に並行して実行され得る。その上、所与のステップは、次のステップが開始される前に完全に完了していないことがある。
【0167】
本方法の実施形態は、プロセッサシステムに方法７００及び／又は７５０を実行させるための命令を含む、ソフトウェアを使用して実行され得る。ソフトウェアは、システムの特定のサブエンティティによって取られるステップのみを含み得る。ソフトウェアは、ハードディスク、フロッピー、メモリ、光ディスクなど、好適な記憶媒体に記憶され得る。ソフトウェアは、ワイヤを通して、又はワイヤレスで、又はデータネットワーク、例えばインターネットを使用して、信号として送られ得る。ソフトウェアは、ダウンロードのために及び／又はサーバ上での遠隔使用のために利用可能にされ得る。本方法の実施形態は、本方法を実行するために、プログラマブル論理、例えばフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を構成するように構成されたビットストリームを使用して実行され得る。
【0168】
現在開示している主題はまた、コンピュータプログラム、特に、開示されている本主題を実践するために適応させられた、キャリア上の又はキャリア中のコンピュータプログラムにまで及ぶことが諒解されよう。プログラムは、ソースコード、オブジェクトコード、コード中間ソース、及び部分的にコンパイルされた形態などのオブジェクトコードの形態であるか、又は、本方法の一実施形態の実装において使用するために好適な任意の他の形態であり得る。コンピュータプログラム製品に関する一実施形態は、記載されている方法のうちの少なくとも１つの処理ステップの各々に対応するコンピュータ実行可能命令を含む。これらの命令は、サブルーチンに再区分され、及び／又は、静的に若しくは動的にリンクされる１つ若しくは複数のファイル中に記憶され得る。コンピュータプログラム製品に関する別の実施形態は、記載されているシステム及び／又は製品のうちの少なくとも１つのデバイス、ユニット及び／又は部品の各々に対応するコンピュータ実行可能命令を含む。
【0169】
図８ａは、書込み可能な部分１０１０を有するコンピュータ可読媒体１０００と、同じく書込み可能な部分を有するコンピュータ可読媒体１００１とを示している。コンピュータ可読媒体１０００は光可読媒体の形態で示されている。コンピュータ可読媒体１００１は、電子メモリ、この場合はメモリカードの形態で示されている。コンピュータ可読媒体１０００及び１００１はデータ１０２０を記憶し、そのデータは、プロセッサシステムによって実行されたときに、プロセッサシステムに、一実施形態による、ゲノムデータを符号化又は検証するための方法の一実施形態を実行させる命令を示す。コンピュータプログラム１０２０は、コンピュータ可読媒体１０００の物理的マークとして、又はコンピュータ可読媒体１０００の磁化によって、コンピュータ可読媒体１０００上で実施される。しかしながら、任意の他の好適な実施形態も想到できる。さらに、コンピュータ可読媒体１０００は本明細書では光ディスクとして示されているが、コンピュータ可読媒体１０００は、ハードディスク、ソリッドステートメモリ、フラッシュメモリなど、任意の好適なコンピュータ可読媒体であり得、記録不可能又は記録可能であり得ることが諒解されよう。コンピュータプログラム１０２０は、データを符号化及び／又は検証する前記方法をプロセッサシステムに実行させるための命令を含む。
【0170】
図８ｂは、符号化システム及び／又は検証システムの一実施形態による、プロセッサシステム１１４０の概略表現を示している。プロセッサシステムは１つ又は複数の集積回路１１１０を備える。図８ｂには、１つ又は複数の集積回路１１１０のアーキテクチャが概略的に示されている。回路１１１０は、一実施形態による方法を実行するための及び／又はそれのモジュール又はユニットを実装するためのコンピュータプログラム構成要素を動作させるための処理ユニット１１２０、例えば、ＣＰＵを備える。回路１１１０は、プログラミングコード、データなどを記憶するためのメモリ１１２２を備える。メモリ１１２２の一部は読取り専用であり得る。回路１１１０は、通信要素１１２６、例えば、アンテナ、コネクタ又は両方などを備える。回路１１１０は、本方法において定義する処理の一部又は全部を実行するための専用集積回路１１２４を備える。プロセッサ１１２０、メモリ１１２２、専用ＩＣ１１２４及び通信要素１１２６は相互接続１１３０、例えばバスを介して互いに接続される。プロセッサシステム１１１０は、それぞれアンテナ及び／又はコネクタを使用する、接触型及び／又は非接触型通信のために構成され得る。
【0171】
例えば、一実施形態では、プロセッサシステム１１４０、例えば符号化又は検証システムは、プロセッサ回路とメモリ回路とを備え、プロセッサは、メモリ回路に記憶されたソフトウェアを実行するように構成される。メモリ回路は、ＲＯＭ回路、又は不揮発性メモリ、例えばフラッシュメモリであり得る。メモリ回路は、揮発性メモリ、例えばＳＲＡＭメモリであり得る。後者の場合、デバイスは、ソフトウェアを与えるために構成された、不揮発性ソフトウェアインターフェース、例えば、ハードドライブ、ネットワークインターフェースなどを備え得る。
【0172】
デバイス１１４０は、各説明された構成要素のうちの１つを含むものとして示されているが、様々な構成要素は様々な実施形態において重複し得る。例えば、プロセッサは、本明細書で説明する方法を単独で実行するように構成された複数のマイクロプロセッサを含むか、或いは、複数のプロセッサが本明細書で説明する機能を達成するように協働するように、本明細書で説明する方法のステップ又はサブルーチンを実行するように構成された複数のマイクロプロセッサを含む。さらに、デバイス１１４０がクラウドコンピューティングシステム中に実装される場合、様々なハードウェア構成要素は別個の物理システムに属し得る。例えば、プロセッサは、第１のサーバ中の第１のプロセッサと、第２のサーバ中の第２のプロセッサとを含む。
【0173】
本発明は以下のさらなる実施形態を含む。
【0174】
実施形態１．データ構造中のデータを符号化するための符号化システムであって、本符号化システムは、
データを受信するための入力インターフェースと、
プロセッサシステムと
を備え、プロセッサシステムが、
データを複数のデータブロックとして取得することと、
複数のデータブロックにハッシュ関数を適用することによって、複数のデータブロックのための複数のハッシュ値を計算することと、
複数のハッシュ値についての第１のハッシュツリーを計算することであって、複数のハッシュ値が第１のハッシュツリーのリーフに割り当てられ、第１のハッシュツリーの１つ又は複数のより高いレベルが生成される、第１のハッシュツリーを計算することと、
データ構造中に複数のデータブロックと第１のハッシュツリーの全部又は一部とを含めることであって、第１のハッシュツリーの前記一部が第１のハッシュツリーのリーフの少なくとも一部を含まない、データ構造中に複数のデータブロックと第１のハッシュツリーの全部又は一部とを含めることと
を行う、符号化システム。
データを受信するための入力インターフェースと、
プロセッサシステムと
を備え、プロセッサシステムが、
データを複数のデータブロックとして取得することと、
複数のデータブロックにハッシュ関数を適用することによって、複数のデータブロックのための複数のハッシュ値を計算することと、
複数のハッシュ値についての第１のハッシュツリーを計算することであって、複数のハッシュ値が第１のハッシュツリーのリーフに割り当てられ、第１のハッシュツリーの１つ又は複数のより高いレベルが生成される、第１のハッシュツリーを計算することと、
データ構造中に複数のデータブロックと第１のハッシュツリーの全部又は一部とを含めることであって、第１のハッシュツリーの前記一部が第１のハッシュツリーのリーフの少なくとも一部を含まない、データ構造中に複数のデータブロックと第１のハッシュツリーの全部又は一部とを含めることと
を行う、符号化システム。
【0175】
実施形態２．プロセッサシステムが、第２のハッシュツリーを計算することであって、第１のハッシュツリーのルートが第２のハッシュツリーのリーフに割り当てられ、複数のさらなるハッシュ値が第２のハッシュツリーの複数のさらなるリーフに割り当てられ、さらなるハッシュ値が、さらなるハッシュツリーのルートとして生成される及び／又はさらなるデータブロック上でのハッシングによって生成される、第２のハッシュツリーを計算することと、データ構造中に第２のハッシュツリーの少なくともルートを含めることとを行う、実施形態１に記載の符号化システム。
【0176】
実施形態３．データ構造が、コンテナの階層中に編成されたデータブロックを含み、プロセッサシステムが階層中の各コンテナのためのハッシュツリーを計算し、ハッシュツリーの各リーフが、コンテナ内のデータブロックのハッシュ値、又は下位のコンテナに対応するハッシュツリーのルートのいずれかである、実施形態１又は２に記載の符号化システム。
【0177】
実施形態４．プロセッサシステムが、ハッシュツリーのルート、特に、ハッシュツリーのリーフの間のハッシュツリールートを有するハッシュツリーのルートにわたるデジタル署名を計算することと、デジタル署名をデータ構造中に含めることとを行う、実施形態１から３のいずれか１つに記載の符号化システム。
【0178】
実施形態５．プロセッサシステムが、データ構造を記憶すること及び／又はデータ構造若しくはデータ構造の一部をストリーミングすることを行い、データ構造の前記一部が、データブロックの少なくとも一部と、前記データブロックに対応するハッシュツリーの少なくとも一部とを含む、実施形態１から４のいずれか１つに記載の符号化システム。
【0179】
実施形態６．複数のデータブロック及び／又はデータコンテナのサブセットが完全性保護付きと標示され、複数のデータブロック及び／又はデータコンテナの残りが、完全性保護なしと標示され、完全性保護付きと標示された部分のみがハッシュツリー中に含まれる、実施形態１から５のいずれか１つに記載の符号化システム。
【0180】
実施形態７．入力インターフェースが１つ又は複数のツリーパラメータを受信し、プロセッサシステムが、１つ又は複数のツリーパラメータに応じて、１つのハッシュツリー又はハッシュツリーの階層から選択されたノードのセットをデータ構造中に含める、実施形態１から６のいずれか１つに記載の符号化システム。
【0181】
実施形態８．入力インターフェースがデータに対する修正を受信し、修正が、追加、削除、及び／又は変更のうちの１つ又は複数を含み、プロセッサシステムが、修正を適用することと、データの修正された一部に対応するハッシュツリーの一部を選択的に再計算し、更新することとを行う、実施形態１から７のいずれか１つに記載の符号化システム。
【0182】
実施形態９．ハッシュツリーのリーフが、非圧縮形態のデータブロックのハッシュと、圧縮形態のデータブロックのハッシュとをさらに含み、データブロックが圧縮形態でデータ構造中に含まれるか、又は、
ハッシュツリーのリーフが、非圧縮及び非暗号化形態のデータブロックのハッシュと、圧縮及び非暗号化形態のデータブロックのハッシュと、圧縮及び暗号化形態のデータブロックのハッシュとをさらに含み、データブロックが圧縮及び暗号化形態でデータ構造中に含まれる、実施形態１から８のいずれか１つに記載の符号化システム。
ハッシュツリーのリーフが、非圧縮及び非暗号化形態のデータブロックのハッシュと、圧縮及び非暗号化形態のデータブロックのハッシュと、圧縮及び暗号化形態のデータブロックのハッシュとをさらに含み、データブロックが圧縮及び暗号化形態でデータ構造中に含まれる、実施形態１から８のいずれか１つに記載の符号化システム。
【0183】
実施形態１０．データ構造中の選択されたデータを検証するための検証システムであって、本検証システムは、
データ構造の少なくとも一部を受信するための入力インターフェースであって、データ構造が、複数のデータブロックとハッシュツリーの一部とを含み、第１のハッシュツリーのリーフの少なくとも一部を含まない、入力インターフェースと、
プロセッサシステムと
を備え、プロセッサシステムが、
データ完全性検証のために選択されたデータ構造中のデータブロックにハッシュ関数を適用することによって、選択されたデータブロックのための複数のハッシュ値を計算することと、
検証のために選択されたデータブロックから始まる、対応するハッシュツリーのルートまでの経路を特定することと、
データ構造中で利用可能な場合に、経路に沿ったハッシュツリーのためのハッシュ値を取り出すこと、又はそのようなハッシュ値を計算することと、
少なくとも計算された複数のハッシュ値からハッシュツリーのルートを検証することと
を行う、検証システム。
データ構造の少なくとも一部を受信するための入力インターフェースであって、データ構造が、複数のデータブロックとハッシュツリーの一部とを含み、第１のハッシュツリーのリーフの少なくとも一部を含まない、入力インターフェースと、
プロセッサシステムと
を備え、プロセッサシステムが、
データ完全性検証のために選択されたデータ構造中のデータブロックにハッシュ関数を適用することによって、選択されたデータブロックのための複数のハッシュ値を計算することと、
検証のために選択されたデータブロックから始まる、対応するハッシュツリーのルートまでの経路を特定することと、
データ構造中で利用可能な場合に、経路に沿ったハッシュツリーのためのハッシュ値を取り出すこと、又はそのようなハッシュ値を計算することと、
少なくとも計算された複数のハッシュ値からハッシュツリーのルートを検証することと
を行う、検証システム。
【0184】
実施形態１１．データ構造がハッシュツリーの階層を含み、プロセッサシステムが、リーフから始まる、ハッシュツリーの階層のルート全体までの経路を特定する、実施形態１０に記載の検証システム。
【0185】
実施形態１２．符号化及び／又は検証システムがデバイスである、実施形態１から１１のいずれか１つに記載の符号化及び／又は検証システム。
【0186】
実施形態１３．複数のデータブロックがゲノムデータを含む、実施形態１から１２のいずれか１つに記載の符号化及び／又は検証システム。
【0187】
実施形態１４．データ構造中のデータを符号化するための符号化方法であって、本符号化方法は、
データを複数のデータブロックとして取得するステップと、
複数のデータブロックにハッシュ関数を適用することによって、複数のデータブロックのための複数のハッシュ値を計算するステップと、
複数のハッシュ値についての第１のハッシュツリーを計算するステップであって、複数のハッシュ値が第１のハッシュツリーのリーフに割り当てられ、第１のハッシュツリーの１つ又は複数のより高いレベルが生成される、第１のハッシュツリーを計算するステップと、
データ構造中に複数のデータブロックと第１のハッシュツリーの一部とを含めるステップであって、第１のハッシュツリーの前記一部が第１のハッシュツリーのリーフの少なくとも一部を含まない、データ構造中に複数のデータブロックと第１のハッシュツリーの一部とを含めるステップと
を有する、符号化方法。
データを複数のデータブロックとして取得するステップと、
複数のデータブロックにハッシュ関数を適用することによって、複数のデータブロックのための複数のハッシュ値を計算するステップと、
複数のハッシュ値についての第１のハッシュツリーを計算するステップであって、複数のハッシュ値が第１のハッシュツリーのリーフに割り当てられ、第１のハッシュツリーの１つ又は複数のより高いレベルが生成される、第１のハッシュツリーを計算するステップと、
データ構造中に複数のデータブロックと第１のハッシュツリーの一部とを含めるステップであって、第１のハッシュツリーの前記一部が第１のハッシュツリーのリーフの少なくとも一部を含まない、データ構造中に複数のデータブロックと第１のハッシュツリーの一部とを含めるステップと
を有する、符号化方法。
【0188】
実施形態１５．データ構造中の選択されたデータを検証するための検証方法であって、本検証方法は、
データ構造の少なくとも一部を受信するステップであって、データ構造が、複数のデータブロックとハッシュツリーの一部とを含み、第１のハッシュツリーのリーフの少なくとも一部を含まない、データ構造の少なくとも一部を受信するステップと、
データ完全性検証のために選択されたデータ構造中のデータブロックにハッシュ関数を適用することによって、選択されたデータブロックのための複数のハッシュ値を計算するステップと、
検証のために選択されたデータブロックから始まる、対応するハッシュツリーのルートまでの経路を特定するステップと、
データ構造中で利用可能な場合に、経路に沿ったハッシュツリーのためのハッシュ値を取り出すステップ、又はそのようなハッシュ値を計算するステップと、
少なくとも計算された複数のハッシュ値からハッシュツリーのルートを検証するステップと
を有する、検証方法。
データ構造の少なくとも一部を受信するステップであって、データ構造が、複数のデータブロックとハッシュツリーの一部とを含み、第１のハッシュツリーのリーフの少なくとも一部を含まない、データ構造の少なくとも一部を受信するステップと、
データ完全性検証のために選択されたデータ構造中のデータブロックにハッシュ関数を適用することによって、選択されたデータブロックのための複数のハッシュ値を計算するステップと、
検証のために選択されたデータブロックから始まる、対応するハッシュツリーのルートまでの経路を特定するステップと、
データ構造中で利用可能な場合に、経路に沿ったハッシュツリーのためのハッシュ値を取り出すステップ、又はそのようなハッシュ値を計算するステップと、
少なくとも計算された複数のハッシュ値からハッシュツリーのルートを検証するステップと
を有する、検証方法。
【0189】
実施形態１６．デジタルデータ構造中のゲノムデータを符号化するための符号化システムであって、本符号化システムは、
ゲノムデータを受信するための入力インターフェースと、
プロセッサシステムと
を備え、プロセッサシステムが、
ゲノムデータを複数のデータブロックとして取得することと、
複数のゲノムデータブロック中の少なくともゲノムデータにハッシュ関数を適用することによって、複数のゲノムブロックのための複数のハッシュ値を計算することと、
複数のハッシュ値についての第１のハッシュツリーを計算することであって、複数のハッシュ値が第１のハッシュツリーのリーフに割り当てられ、第１のハッシュツリーが少なくとも３つのレベルを有する、第１のハッシュツリーを計算することと、
データ構造中に複数のゲノムブロックと第１のハッシュツリーの一部とを含めることであって、第１のハッシュツリーの前記一部が、第１のハッシュツリーの最初の２つの最も高いレベルを含むが、第１のハッシュツリーの１つ又は複数のより低いレベルを含まない、データ構造中に複数のゲノムブロックと第１のハッシュツリーの一部とを含めることと
を行う、符号化システム。
ゲノムデータを受信するための入力インターフェースと、
プロセッサシステムと
を備え、プロセッサシステムが、
ゲノムデータを複数のデータブロックとして取得することと、
複数のゲノムデータブロック中の少なくともゲノムデータにハッシュ関数を適用することによって、複数のゲノムブロックのための複数のハッシュ値を計算することと、
複数のハッシュ値についての第１のハッシュツリーを計算することであって、複数のハッシュ値が第１のハッシュツリーのリーフに割り当てられ、第１のハッシュツリーが少なくとも３つのレベルを有する、第１のハッシュツリーを計算することと、
データ構造中に複数のゲノムブロックと第１のハッシュツリーの一部とを含めることであって、第１のハッシュツリーの前記一部が、第１のハッシュツリーの最初の２つの最も高いレベルを含むが、第１のハッシュツリーの１つ又は複数のより低いレベルを含まない、データ構造中に複数のゲノムブロックと第１のハッシュツリーの一部とを含めることと
を行う、符号化システム。
【0190】
実施形態１７．プロセッサシステムが、第２のハッシュツリーを計算することであって、第１のハッシュツリーのルートが第２のハッシュツリーのリーフに割り当てられ、複数のさらなるデータ項目が第２のハッシュツリーの複数のさらなるリーフに割り当てられる、第２のハッシュツリーを計算することと、データ構造中に第２のハッシュツリーの少なくともルートを含めることとを行う、実施形態１から１６のいずれか１つに記載の符号化システム。
【0191】
実施形態１８．データ構造が、複数のレベルを有する階層データ構造であり、プロセッサシステムが、階層データ構造の各レベルのためのハッシュツリーを計算することと、最も低いレベルの上のレベルのためのハッシュツリー中に、階層データ構造のより低いレベルのために計算されたハッシュツリーのルートを含めることとを行う、実施形態１から１７のいずれか１つに記載の符号化システム。
【0192】
実施形態１９．入力インターフェースがツリーパラメータを受信し、プロセッサシステムが、ツリーパラメータに応じて、データ構造中に第１のハッシュツリーのより大きい又はより小さい一部を含める、実施形態１から１８のいずれか１つに記載の符号化システム。
【0193】
上述の実施形態は、開示されている本主題を限定するのではなく、例示するものであることと、当業者は、多くの代替実施形態を設計することが可能であろうこととに留意されたい。
【0194】
特許請求の範囲において、丸括弧に入れられた参照符号は、請求項を限定するものとして解釈されないものとする。「備える」及び「有する」という動詞並びにそれらの活用形の使用は、特許請求の範囲に記述された要素又はステップ以外の要素又はステップの存在を除外しない。単数形の要素は複数のそのような要素の存在を除外しない。「のうちの少なくとも１つ」などの表現は、要素のリストの後に付いているとき、リストからのすべての要素又は要素の任意のサブセットの選択を表す。例えば、「Ａ、Ｂ、及びＣのうちの少なくとも１つ」という表現は、Ａのみ、Ｂのみ、Ｃのみ、ＡとＢの両方、ＡとＣの両方、ＢとＣの両方、又はＡ、Ｂ、及びＣのすべてを含むものとして理解されるべきである。開示されている本主題は、いくつかの別個の要素を含むハードウェアと、好適にプログラムされたコンピュータとによって実施され得る。いくつかの部分を列挙するデバイスクレームでは、これらの部分のうちのいくつかは同一のハードウェアによって実施され得る。相互に異なる従属クレームにおいていくつかの手段が具陳されているという単なる事実は、これらの手段の組合せを有利に使用することができないことを示さない。
【0195】
特許請求の範囲において、丸括弧内の参照符号は、例示的な実施形態の図面中の参照符号又は実施形態の公式を指し、それによりクレームの了解度が高まる。これらの参照符号は、クレームを限定するものとして解釈されないものとする。
【図1a】
【図1b】
【図2a】
【図2b】
【図2c】
【図3】
【図4】
【図5a】
【図5b】
【図6】
【図7a】
【図7b】
【図8a】
【図8b】
【国際調査報告】