特許 7000422 データストレージシステムおよびデータストレージを実行するための方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2021-12-27

(45)【発行日】2022-01-19

(54)【発明の名称】データストレージシステムおよびデータストレージを実行するための方法

(51)【国際特許分類】

   G06F 21/60 20130101AFI20220112BHJP

【ＦＩ】

G06F21/60 340

G06F21/60 320

【請求項の数】 22

(21)【出願番号】P 2019517127

(86)(22)【出願日】2017-06-09

(65)【公表番号】

(43)【公表日】2019-08-29

(86)【国際出願番号】 CA2017050708

(87)【国際公開番号】W WO2017210798

(87)【国際公開日】2017-12-14

【審査請求日】2020-06-09

(31)【優先権主張番号】62/347,883

(32)【優先日】2016-06-09

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】518435530

【氏名又は名称】アンフォルマティック・ホリステック・インコーポレーテッド

(74)【代理人】

【識別番号】100140109

【弁理士】

【氏名又は名称】小野 新次郎

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100106208

【弁理士】

【氏名又は名称】宮前 徹

(74)【代理人】

【識別番号】100120112

【氏名又は名称】中西 基晴

(74)【代理人】

【識別番号】100162846

【弁理士】

【氏名又は名称】大牧 綾子

(72)【発明者】

【氏名】サボラン，ギー

【審査官】岸野 徹

(56)【参考文献】

【文献】特表２００８－５３７２０９（ＪＰ，Ａ）

【文献】国際公開第２０１３／０６５５４５（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０１４／０２８９５３９（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０１５６１７４（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／６０

(57)【特許請求の範囲】

【請求項1】

データストレージを実行するためのコンピュータ実装方法であって、前記方法は、
データソースから、記憶されるべきデータを受信するステップと、
前記データを、記憶されるべきデータをそれぞれ含むコアオブジェクトにセグメント化するステップであって、前記コアオブジェクトの各々が、不変であり、前記コアオブジェクトの各々が、コレクション中に書き込まれ、一意のオブジェクトＩＤを割り当てられる、セグメント化するステップと、
前記コアオブジェクトを、前記コアオブジェクトのうちの少なくとも１つをそれぞれ含むブロブにグループ化するステップであって、前記ブロブの各々は、その中に含まれる前記コアオブジェクトのうちの前記少なくとも１つの前記コアオブジェクトのオブジェクトＩＤから導出された一意のブロブＩＤを割り当てられ、前記ブロブが前記コレクションに書き込まれるときに最後に書き込まれた前記ブロブに対応する前記コレクションの最後のブロブが、そのようなものとして識別可能である、グループ化するステップと、
前記コレクションの前記コアオブジェクトのサブセットを定義する少なくとも２つのコアオブジェクトを互いにツリー状の構造でリンクすることによって前記コレクションの状態を定義するステップであって、前記ブロブが前記コレクションに書き込まれたときに前記コレクションの前記サブセットのうち最新に作成されたコアオブジェクトに対応する前記サブセットの最後のコアオブジェクトが、対応するサブセットのヘッドオブジェクトである、定義するステップと、
前記ヘッドオブジェクトの識別情報を記憶するステップと、
前記ブロブの各々を少なくとも１つのバックエンド上に記憶するステップと
を含む、コンピュータ実装方法。

【請求項2】

前記ヘッドオブジェクトの識別情報を記憶する前記ステップが、前記ヘッドオブジェクトの識別情報を前記コレクションの前記最後のブロブに記憶するステップを含む、請求項１に記載の方法。

【請求項3】

前記記憶されたデータの要求時に、前記少なくとも１つのバックエンドのうちの１つから、対応するブロブを選択的に取り出すステップをさらに含む、請求項１または２に記載の方法。

【請求項4】

前記コアオブジェクトの各々がオブジェクトタイプを有し、前記コレクションの前記コアオブジェクトのサブセットを定義する少なくとも２つのコアオブジェクトを互いにツリー状の構造でリンクすることによって前記コレクションの前記状態を維持するステップであって、前記少なくとも１つのサブセットの各々の前記最後のコアオブジェクトが前記ヘッドオブジェクトである、維持するステップは、各オブジェクトタイプのコアオブジェクトをリンクするステップであって、各オブジェクトタイプの前記最後のコアオブジェクトが、対応するオブジェクトタイプについての前記ヘッドオブジェクトである、リンクするステップを含む、請求項１から３のいずれか一項に記載の方法。

【請求項5】

前記ブロブの各々を少なくとも１つのバックエンド上に記憶する前記ステップが、前記ブロブを分散されたバックエンド上に記憶するステップを含む、請求項１から４のいずれか一項に記載の方法。

【請求項6】

前記ブロブを前記少なくとも１つのバックエンド上に記憶する前記ステップより前に前記ブロブを暗号化するステップをさらに含む、請求項１から５のいずれか一項に記載の方法。

【請求項7】

前記ブロブを前記少なくとも１つのバックエンド上に記憶する前記ステップより前に前記ブロブを暗号化する前記ステップと、前記少なくとも１つのバックエンドのうちの１つから対応するブロブを取り出す前記ステップの後に前記ブロブを解読するステップとをさらに含む、請求項３に記載の方法。

【請求項8】

前記ブロブを暗号化する前記ステップより前に前記ブロブを圧縮するステップをさらに含む、請求項６に記載の方法。

【請求項9】

前記ブロブを解読する前記ステップの後に前記ブロブを圧縮解除するステップをさらに含む、請求項７に記載の方法。

【請求項10】

識別可能である複数の最後のブロブを、各フォークされたコレクションの最後のブロブとして導入することによって、前記コレクションをフォークするステップをさらに含む、請求項１から９のいずれか一項に記載の方法。

【請求項11】

フォークされたコレクションを、コレクションの１つとコレクションの別のフォークとにマージするステップをさらに含む、請求項１０に記載の方法。

【請求項12】

請求項１から１１のいずれか一項に記載の前記方法を行うためにコンピュータが実行するためのステートメントおよび命令をその上に記録しているコンピュータ可読メモリ。

【請求項13】

記憶されるべきデータを受信し、前記データを少なくとも１つのバックエンド上に記憶し、前記少なくとも１つのバックエンドから前記データを取り出すように構成されたコアエンジンモジュールを備える、データストレージシステムであって、前記コアエンジンモジュールが少なくとも１つのコレクションを生成し、管理し、前記少なくとも１つのコレクションは、
記憶されるべきデータをそれぞれ含むコアオブジェクトであって、前記コアオブジェクトの各々が、不変であり、一意のオブジェクトＩＤを割り当てられ、前記コアオブジェクトのサブセットを定義する少なくとも２つのコアオブジェクトが互いにツリー状の構造でリンクされ、前記コレクションの前記サブセットの最新に作成された前記コアオブジェクトに対応する前記サブセットの最後のコアオブジェクトが、前記対応するサブセットのヘッドオブジェクトである、コアオブジェクトと、
前記コアオブジェクトのうちの少なくとも１つをそれぞれ含むブロブであって、前記ブロブの各々が、含まれる前記コアオブジェクトのうちの前記少なくとも１つのコアオブジェクトの前記オブジェクトＩＤから導出された一意のブロブＩＤを割り当てられ、前記ブロブが前記コレクションに書き込まれたときに最後に書き込まれた前記ブロブに対応する前記コレクションの最後のブロブが、そのようなものとして識別可能であり、前記少なくとも１つのサブセットの各々の前記ヘッドオブジェクトの識別情報を含む、ブロブと、
前記ブロブをその上に記憶し、前記ブロブが、対応するブロブＩＤを使用して取り出されることを可能にする、バックエンドのうちの前記少なくとも１つと
を備える、データストレージシステム。

【請求項14】

前記コアエンジンモジュールが、コレクションを開き、コアオブジェクトを読み取り、書き込み、削除するように構成されたコアＡＰＩモジュールと、前記コアオブジェクトを生成し、管理するように構成されたコレクションマネージャモジュールと、前記ブロブを生成し、管理するように構成されたブロブマネージャモジュールとを備える、請求項１３に記載のデータストレージシステム。

【請求項15】

前記コアエンジンモジュールが、前記少なくとも１つのバックエンド上への記憶より前に前記ブロブを暗号化し、前記少なくとも１つのバックエンドからの取出しの後に前記ブロブを解読する暗号化器モジュールをさらに備える、請求項１４に記載のデータストレージシステム。

【請求項16】

前記コアエンジンモジュールが、前記暗号化器モジュールによる暗号化より前に前記ブロブを圧縮し、前記暗号化器モジュールによる解読の後に前記ブロブを圧縮解除する圧縮器モジュールをさらに備える、請求項１５に記載のデータストレージシステム。

【請求項17】

前記コアオブジェクトの前記サブセットの前記コアオブジェクト間の前記リンクを表すリンクデータが、コアオブジェクトの前記サブセットの前記コアオブジェクトの少なくとも一部分に記憶される、請求項１３から１６のいずれか一項に記載のデータストレージシステム。

【請求項18】

前記コアオブジェクトの各々の前記一意のオブジェクトＩＤが連続的に割り当てられる、請求項１３から１７のいずれか一項に記載のデータストレージシステム。

【請求項19】

前記ブロブの各々の前記一意のブロブＩＤが、前記ブロブの第１のコアオブジェクトの前記オブジェクトＩＤに対応する、請求項１８に記載のデータストレージシステム。

【請求項20】

前記コアオブジェクトの各々がオブジェクトエイリアスと仮想オブジェクトＩＤとのうちの１つをさらに備える、請求項１３から１９のいずれか一項に記載のデータストレージシステム。

【請求項21】

コレクションに記憶されたデータの編成および位置特定を容易にするためにインデックス付けサービスを実行するインデックスエンジンをさらに備える、請求項１３から２０のいずれか一項に記載のデータストレージシステム。

【請求項22】

各コレクションの前記少なくとも１つのバックエンドが、前記ブロブの分散されたストレージを与えるために複数の分散されたバックエンドを備える、請求項１３から２１のいずれか一項に記載のデータストレージシステム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
[0001]本出願は、２０１６年６月９日に出願された米国仮特許出願第６２／３４７，８８３号の米国特許法第１１９条（ｅ）項に基づく利益を主張する。上述の出願の全体は、参照により本明細書に組み込まれる。

【0002】

[0002]本発明は、データストレージの分野に関する。より詳細には、本発明は、データストレージを実行するためのシステム、およびデータストレージを実行するための方法に関する。

【背景技術】

【0003】

[0003]リモートの抽象的なロケーションにデータを記憶し、その後、ネットワークに接続された通信デバイスを使用してデータを取り出すために、クラウドデータストレージ技術を使用することは、当技術分野で知られている。データのストレージに進むために、クライアントは、一般に、アプリケーション、プラグイン、ＡＰＩ、ウェブブラウザなどを通して、通信デバイスを用いてクラウドストレージプロバイダに接続し、クラウドストレージプロバイダは、回復力を与えるために、（ミラーリング、ＳＡＮ、ＲＡＩＤなどの）知られているストレージ技術を使用してそれ自体のサーバまたはデータセンターに（通常のファイルシステムのファイル（たとえば、ＮＴＦＳ、ＥＸＴ３／４など）、データベースレコード、オブジェクトなどの）データを記憶する。クラウドデータストレージ技術を使用するとき、データのストレージおよび取出しは、たとえば、限定的ではないが、ハードウェア機器、物理的ロケーション、厳密なセキュリティ対策、あるいはデータが物理的に記憶されるサーバまたはデータセンターの他の要件など、データストレージの材料およびセキュリティ態様についてユーザが懸念を抱かないように、クラウドストレージプロバイダによって十分に扱われる。

【0004】

[0004]しかしながら、知られているクラウドデータストレージ技術は、いくつかの欠点がある傾向がある。たとえば、クライアントデータがクラウドストレージプロバイダのインフラストラクチャに直接記憶されることを仮定すれば、クラウドストレージプロバイダは、通常、データへのアクセスを有する。したがって、クライアントは、記憶されたデータの機密性に関してクラウドサービスプロバイダのセキュリティ実施、技術および人員を信用しなければならない。いくつかの場合には、セキュリティを改善するために暗号化を使用することが可能であるが、それでも、クラウドストレージプロバイダは、概して、少なくとも一部の情報にアクセスすることを必要とされる。たとえば、いくつかの事例では、クラウドストレージプロバイダは、データを暗号化および解読するために暗号化鍵へのアクセスを有することを必要とされる。プロバイダが、クライアントデータを保護する暗号化／解読鍵へのアクセスを理論的に決して有しない場合でも、プロバイダは、依然として、何らかの非暗号化メタデータ（たとえばファイル名、ディレクトリ構造、変更日付など）へのアクセスを有することを必要とされ、非暗号化メタデータは、要求時にデータの位置を特定し、データにアクセスするために、重要な特権的情報（たとえば、クライアントリスト、契約の種類、取り組んでいるプロジェクトなど）を含むことができる。したがって、暗号化が使用されるときでも、クライアントは、クラウドストレージプロバイダのセキュリティ実施において一定のレベルの信用を有しなければならない。

【0005】

[0005]その上、各クラウドデータストレージプロバイダの特殊性を仮定すれば、あるクラウドデータストレージプロバイダから別のクラウドデータストレージプロバイダに切り替わること、または複数のクラウドストレージデータプロバイダにわたってクライアントのデータを分散させることはクライアントにとって好都合でない。たとえば、複数のクラウドデータストレージプロバイダにわたってデータを分散させるために、概して、クライアントが、いくつかの知られている境界（たとえば、サブディレクトリ、データベースキーレンジなど）に沿ってデータを手動で区分し、個々のプロバイダに特定の部分を割り当てることが必要とされる。その上、クライアントが、（データの全体または一部分について）後でクラウドデータストレージプロバイダ間で切り替えることを望む場合、クライアントは、概して、対応するデータを一方のプロバイダから他方のプロバイダに手動でコピーし、そのデータに今アクセスしているすべてのユーザが新しいプロバイダを使用することを保証することを必要とされる。データのそのようなコピー中に、完全性を保証するために、更新は中断されるか、または２つのプロバイダのうちの一方のみを対象としなければならない。また、あるプロバイダから別のプロバイダにデータを移動させることは、特定のクラウドデータストレージプロバイダのサービスおよび制限を変えたことの結果として、失敗およびメタデータの損失を引き起こすことがある。

【0006】

[0006]当業者は、上述の短所のうちのいくつかを緩和するためにアグリゲータ（すなわち、クライアントとクラウドデータストレージプロバイダとの間で動作するエージェント）を使用することが可能であることを理解されよう。しかしながら、アグリゲータの使用は、アグリゲータが概してデータへのアクセスを必要とし、したがって、クラウドストレージプロバイダが信用されるであろうレベルと同じレベルで信用される必要があると仮定すれば、機密性の問題をもう一度提起することになる。さらに、そのような場合、クラウドベースストレージサービスの性能はアグリゲータのサービスに依存し、アグリゲータのサービスが失敗または性能に問題があれば、クラウドベースストレージサービスのすべてについての問題を生じることになる。

【0007】

[0007]上述の問題の多くがローカルデータストレージまたはネットワークデータストレージにも適用されることを理解されよう。たとえば、ユーザがパーソナルハードディスクから別のものに切り替えることを望むとき、ユーザは、更新が実行されていない間にすべてのデータを一方のディスクから他方のディスクにコピーすることが必要となる。複数のディスクが使用される場合、ユーザは、どのファイルまたはディレクトリがどのディスクに記憶されるべきであるかを手動で決定することが必要となる。さらに、プラットフォーム間で変わるファイルシステムサポートは、異なるファイルシステムからデータを移動／コピーするときに、しばしば、失敗を引き起こすか、またはメタデータの損失を生じることがある。

【発明の概要】

【発明が解決しようとする課題】

【0008】

[0008]上記に鑑みて、上記で説明された従来技術の懸念のうちのいくつかを克服するかまたは少なくとも最小限に抑えることが可能になるであろう、分散環境においてデータを構造化および記憶するための改善されたシステムおよび方法が必要である。

【課題を解決するための手段】

【0009】

[0009]第１の一般的態様によれば、データストレージを実行するためのコンピュータ実装方法が提供される。本方法は、データソースから、記憶されるべきデータを受信するステップと、データを不変（ｉｍｍｕｔａｂｌｅ）コアオブジェクトにセグメント化するステップであって、コアオブジェクトの各々がコレクション中に書き込まれ、一意のオブジェクトＩＤを割り当てられるセグメント化するステップと、不変オブジェクトをブロブ（ｂｌｏｂ）にグループ化するステップであって、各ブロブが、オブジェクトのうちの少なくとも１つを含み、ブロブの各々が、その中に含まれるオブジェクトのうちの少なくとも１つのオブジェクトＩＤから導出された一意のブロブＩＤを割り当てられ、コレクションの最後のブロブがそのようなものとして識別可能である、グループ化するステップと、コレクションのコアオブジェクトの少なくとも１つのサブセットを互いにリンクすることによってコレクションの状態を定義するステップであって、少なくとも１つのサブセットの各々の最後のオブジェクトが、対応するサブセットのオブジェクトヘッドである、定義するステップと、ヘッドオブジェクトの識別情報を記憶するステップと、ブロブの各々を少なくとも１つのバックエンド上に記憶するステップとを含む。

【0010】

[0010]一実施形態では、ヘッドオブジェクトの識別情報を記憶するステップは、ヘッドオブジェクトの識別情報をコレクションの最後のブロブに記憶するステップを含む。
[0011]一実施形態では、本方法は、記憶されたデータの要求時に、少なくとも１つのバックエンドのうちの１つから、対応するブロブを選択的に取り出すステップをさらに含む。

【0011】

[0012]一実施形態では、コアオブジェクトの各々はオブジェクトタイプを有し、コレクションのコアオブジェクトの少なくとも１つのサブセットを互いにリンクすることによってコレクションの状態を維持するステップであって、少なくとも１つのサブセットの各々の最後のオブジェクトがオブジェクトヘッドである、維持するステップは、各オブジェクトタイプのアクティブオブジェクトをリンクするステップであって、各オブジェクトタイプの最後のオブジェクトが、対応するオブジェクトタイプについてのヘッドオブジェクトである、リンクするステップを含む。

【0012】

[0013]一実施形態では、ブロブの各々を少なくとも１つのバックエンド上に記憶するステップは、ブロブを分散されたバックエンド上に記憶するステップを含む。
[0014]一実施形態では、本方法は、ブロブを少なくとも１つのバックエンド上に記憶するステップより前にブロブを暗号化するステップをさらに含む。

【0013】

[0015]一実施形態では、本方法は、ブロブを少なくとも１つのバックエンド上に記憶するステップより前にブロブを暗号化するステップと、少なくとも１つのバックエンドのうちの１つから対応するブロブを取り出すステップの後にブロブを解読するステップとをさらに含む。

【0014】

[0016]一実施形態では、本方法は、ブロブを暗号化するステップより前にブロブを圧縮するステップをさらに含む。
[0017]一実施形態では、本方法は、ブロブを解読するステップの後にブロブを圧縮解除するステップをさらに含む。

【0015】

[0018]一実施形態では、本方法は、識別可能である複数の最後のブロブを、各フォーク（fork）されたコレクションの最後のブロブとして導入することによって、コレクションをフォークするステップをさらに含む。

【0016】

[0019]一実施形態では、本方法は、フォークされたコレクションを、コレクションのあるフォークとコレクションの別のフォークとにマージするステップをさらに含む。
[0020]別の一般的態様によれば、上記で説明された方法を行うためにコンピュータが実行するためのステートメントおよび命令をその上に記録しているコンピュータ可読メモリをも提供される。

【0017】

[0021]別の一般的態様によれば、記憶されるべきデータを受信し、データを少なくとも１つのバックエンド上に記憶し、少なくとも１つのバックエンドからデータを取り出すように構成されたコアエンジンモジュールを備えるデータストレージシステムをも提供される。コアエンジンモジュールは、記憶されるべきデータをそれぞれ含むコアオブジェクトと、オブジェクトのうちの少なくとも１つをそれぞれ含むブロブと、バックエンドのうちの少なくとも１つとを備える、少なくとも１つのコレクションを生成し、管理する。コアオブジェクトの各々は不変であり、一意のオブジェクトＩＤを割り当てられる。コアオブジェクトの少なくとも１つのサブセットは互いにリンクされ、少なくとも１つのサブセットの各々の最後のオブジェクトは、対応するサブセットのオブジェクトヘッドである。ブロブの各々は、含まれるオブジェクトのうちの少なくとも１つのオブジェクトＩＤから導出された一意のブロブＩＤを割り当てられる。コレクションの最後のブロブは、そのようなものとして識別可能であり、少なくとも１つのサブセットの各々のヘッドオブジェクトの識別情報を含む。少なくとも１つのバックエンドはブロブをその上に記憶し、ブロブが、対応するブロブＩＤを使用して取り出されることを可能にする。

【0018】

[0022]一実施形態では、コアエンジンモジュールは、コレクションを開き、コアオブジェクトを読み取り、書き込み、削除するように構成されたコアＡＰＩモジュールと、コアオブジェクトを生成し、管理するように構成されたコレクションマネージャモジュールと、ブロブを生成し、管理するように構成されたブロブマネージャモジュールとを備える。

【0019】

[0023]一実施形態では、コアエンジンモジュールは、少なくとも１つのバックエンド上への記憶より前にブロブを暗号化し、少なくとも１つのバックエンドからの取出しの後にブロブを解読する暗号化器モジュールをさらに備える。

【0020】

[0024]一実施形態では、コアエンジンモジュールは、暗号化器モジュールによる暗号化より前にブロブを圧縮し、暗号化器モジュールによる解読の後にブロブを圧縮解除する圧縮器モジュールをさらに備える。

【0021】

[0025]一実施形態では、コアオブジェクトの少なくとも１つのサブセットの各々のコアオブジェクト間のリンクを表すリンクデータは、コアオブジェクトの少なくとも一部分に記憶される。

【0022】

[0026]一実施形態では、コアオブジェクトの各々の一意のオブジェクトＩＤは連続的に割り当てられる。
[0027]一実施形態では、ブロブの各々の一意のブロブＩＤは、ブロブの第１のコアオブジェクトのオブジェクトＩＤに対応する。

【0023】

[0028]一実施形態では、コアオブジェクトの各々はオブジェクトエイリアスと仮想オブジェクトＩＤとのうちの１つをさらに備える。
[0029]一実施形態では、データストレージシステムは、コレクションに記憶されたデータの編成および位置特定を容易にするためにインデックス付けサービスを実行するインデックスエンジンをさらに備える。

【0024】

[0030]一実施形態では、各コレクションの少なくとも１つのバックエンドは、ブロブの分散されたストレージを与えるために複数の分散されたバックエンドを備える。
[0031]他の目的、利点および特徴は、添付の図面を参照しながら、例示の目的でのみ与えられる、それの実施形態の以下の非制限的説明を読めばより明らかになろう。

【図面の簡単な説明】

【0025】

【図1】[0032]一実施形態による、データストレージを実行するためのコンピュータ実装方法のステップのフローチャート表現の図である。

【図1a】一実施形態による、データストレージを実行するためのコンピュータ実装方法のステップのフローチャート表現の図である。

【図1b】一実施形態による、データストレージを実行するためのコンピュータ実装方法のステップのフローチャート表現の図である。

【図2】[0033]図１の方法による、データストレージのために使用されるオブジェクトの一実施形態の概略表現の図である。

【図3】[0034]図１の方法による、データストレージのために使用されるブロブの一実施形態の概略表現の図である。

【図4】[0035]各々がブロブの第１のオブジェクトのオブジェクトＩＤに対応するブロブＩＤを有し、オブジェクトが連続的に番号を付けられる、複数のブロブを含むコレクションの例示的な実施形態の概略表現の図である。

【図5】[0036]図１の方法を使用するファイルのストレージの例示的な実施形態の概略表現の図である。

【図6】[0037]最後のオブジェクトタイプおよびオブジェクトリンキングを使用するコレクション管理と、ガベージコレクションに対する影響との例示的な実施形態の概略表現の図である。

【図7a】[0038]コレクションをフォークすることの例示的な実施形態の概略表現の図である。

【図7b】コレクションをフォークすることの例示的な実施形態の概略表現の図である。

【図7c】コレクションをフォークすることの例示的な実施形態の概略表現の図である。

【図7d】コレクションをフォークすることの例示的な実施形態の概略表現の図である。

【図8】[0039]一実施形態による、データストレージを実行するためのシステムの概略表現の図である。

【図9】[0040]アプリケーションが、コアエンジンモジュールと通信するためにファイルシステムエンジンモジュールおよび／またはデータベースエンジンモジュールを使用する一実施形態による、図８のデータストレージを実行するためのシステムの概略表現の図である。

【発明を実施するための形態】

【0026】

[0041]以下の説明では、同じ参照番号は同様の要素を指す。その上、データの分散されたストレージのためのシステムおよび方法の実施形態は、本明細書で説明および例示されるいくつかの構成要素からなるが、これらの構成要素のすべてが必須であるとは限らず、したがってそれらの限定的な意味にとるべきではない。また、当業者にとって明らかなように、本明細書で手短に説明されるように、および当業者によって本明細書から容易に推論することができるように、データの分散されたストレージのためのシステムおよび方法のために、他の好適な構成要素およびそれらの間の協働を使用してもよいことを理解されたい。

【0027】

[0042]一般論として、データのストレージのための本システムおよび方法は、本明細書で「コアオブジェクト」と呼ばれる小さい個別の独立したストレージユニットに依拠し、コアオブジェクトは、本明細書で「ブロブ」と呼ばれる、より大きいエンティティに凝集（ａｇｇｌｏｍｅｒａｔｅ）され、ブロブは、異なるファイルシステム、データベース、またはデータの他のタイプが複数の、異種および／またはさもなければ潜在的に互換性のないストレージ媒体にわたって記憶および分散することができるオープンエンドの、ログのようなストレージ構造に記憶される。一実施形態では、セキュリティを高めるために、ブロブは、記憶される前に圧縮および暗号化され、取り出されるときに解読および圧縮解除される。代替の実施形態では、ブロブ自体を圧縮／圧縮解除および暗号化／解読することに加えて、コアオブジェクトを、対応するブロブ内に個々に圧縮および暗号化（その後解読および圧縮解除）することもできる。当業者は、本明細書でブロブと呼ばれるストレージユニットを指すために「ポッド」などの他の用語を使用することができたであろうことを理解されよう。

【0028】

[0043]以下の説明に鑑みて明らかになるように、データのストレージのためのシステムおよび方法は、ブロブが、同時更新が進行中である間でも、中央調整、トラッキングまたは同期を必要とすることなしに、様々な、および場合によっては潜在的に互換性のないストレージプロバイダおよび／またはデバイス間で自由に移動、コピー、および共有されることを可能にする。

【0029】

[0044]本文書の過程において、「コアオブジェクト」という用語は、たとえば、限定的ではないが、データベースレコード、ファイルフラグメント、メタデータ、ディレクトリインデックスなど、任意の論理データを含むことができる基本ストレージユニットを指すために使用される。「ブロブ」という用語は、複数のコアオブジェクトを含み、「バックエンド」（または「ストレージノード」）として知られるストレージ容器（ｓｔｏｒａｇｅ ｖｅｓｓｅｌ）に記憶される、コンテナを指すために使用される。「バックエンド」という用語は、自律型ストレージ容器を指すために使用され、たとえば、限定的ではないが、ローカルハードディスク、フラッシュメモリ、クラウドストレージプロバイダ、およびゾーン、バケットまたはそれの他の隔離ユニット、ネットワーク接続ドライブ、あるいは任意のストレージ媒体（またはそれのパーティション）またはデータを記憶することが可能なサービスを含む。「コレクション」という用語は、全体として管理することができるコヒーレントユニット（ｃｏｈｅｒｅｎｔ ｕｎｉｔ）を形成する、コアオブジェクト、ブロブおよびバックエンドのグループを指すために使用される。コレクションは、１つまたは複数のユーザが見ることのできるファイルシステム、データベース、オブジェクトストア、または関係するデータを一緒に保つために必要とされる任意の他の形態のグループ化を表すことができる。コヒーレントユニットを形成するコアオブジェクト、ブロブおよびバックエンドのグループを指すために、「コスモス（ｃｏｓｍｏｓ）」などの他の指定する用語を使用することができる。

【0030】

[0045]図１を全体的に参照すると、高いフレキシビリティおよびセキュリティをもつ様々なデバイスおよびサービス上でデータを自由に分散およびホストすることを可能にする、データストレージを実行するための方法１０の一実施形態が提供される。図示の実施形態では、データストレージを実行するための方法１０は、データソースから記憶されるべきデータを受信するステップ（ステップ１１）と、データをコアオブジェクトにセグメント化するステップ（ステップ１２）と、コアオブジェクトをブロブにグループ化するステップ（ステップ１４）と、ブロブを圧縮するステップ（ステップ１６）と、ブロブを暗号化するステップ（ステップ１８）と、ブロブを少なくとも１つのバックエンドに記憶するステップ（ステップ２０）と、記憶されたデータの要求時に少なくとも１つのバックエンドのうちの１つから対応するブロブを選択的に取り出すステップ（ステップ２６）とを含む。

【0031】

[0046]図１および図２を参照すると、上述のように、ステップ１２において生成されるコアオブジェクト５０中に保持されるデータは、何らかの形態の任意の２値データであってもよい。一実施形態では、各コアオブジェクト５０は、コアオブジェクト５０のコンテンツを記述するヘッダ５２と、コアオブジェクトのための実際のデータを含んでいるペイロード５４とを含む。たとえば、限定的ではないが、ヘッダ５２は、オブジェクトＩＤ（ＯＩＤ）５２ａ、オブジェクトタイプ（ＯＴｙｐｅ）５２ｂ、仮想ＩＤ（ＶＩＤ）５２ｃ、名前（またはエイリアス）５２ｄ、ユニバーサルユニークＩＤ（ＵＵＩＤ）５２ｅ、オブジェクトがそれのタイプの最後のオブジェクトとして追跡されているかどうかを示すフラグ（ＩｓＬａｓｔＴｒａｃｋｅｄ）５２ｆ、関係するオブジェクトへのリンク（リンク）５２ｇ、現在のオブジェクトによって置換されるオブジェクトのＩＤ（置換）５２ｈ、および／または現在のオブジェクトによって削除される他のオブジェクトのＩＤ（削除）５２ｉなどの情報を含むことができる。以下でより詳細に説明されるように、ＯＩＤ５２ａはオブジェクトの識別子であり、ＯＴｙｐｅは、ペイロードを復号するのに役立つ、コアオブジェクト５０のコンテンツの目的およびフォーマットを識別する。仮想ＩＤ（ＶＩＤ）５２ｃ、名前５２ｄ、ユニバーサルユニークＩＤ（ＵＵＩＤ）５２ｅ、または他のタイプの識別子を、オブジェクト５０が公式ＯＩＤ５２ａ以外の代替識別子を使用して位置を特定されることを可能にするオブジェクト識別情報と呼ぶことができる。オブジェクトがそれのタイプの最後のオブジェクトとして追跡されているかどうかを示すフラグ（ＩｓＬａｓｔＴｒａｃｋｅｄ）５２ｆ、関係するオブジェクトへのリンク（リンク）５２ｇ、現在のオブジェクトによって置換されるオブジェクトのＩＤ（置換）５２ｈ、および／または現在のオブジェクトによって削除される他のオブジェクトのＩＤ（削除）５２ｉは、以下でより詳細に説明されるように、コレクション管理のために使用することができるコレクション管理情報である。しかしながら、代替の実施形態では、コアオブジェクト５０を別様に構成することができ、および／またはコアオブジェクト５０が図示の実施形態におけるものとは異なる情報を含んでいることがあることを当業者は理解されよう。

【0032】

[0047]生成されるあらゆるコアオブジェクト５０は不変であり、すなわち、コアオブジェクトのコンテンツは、永続的であり、オブジェクトが作成され、コレクションにコミットされ、書き込まれると、コンテンツを変更することができない。上記に鑑みて、オブジェクトのコンテンツを更新することができない。したがって、オブジェクトのコンテンツが更新される必要がある場合、新しいコアオブジェクト５０が作成されなければならない。一実施形態では、古いオブジェクトは、「置換される」ものとしてフラグを付けることができ、したがって、ガベージコレクションに関して以下でより詳細に説明されるように、それをコレクションからその後除去してもよい。一実施形態では、オブジェクト全体を置換する代わりに、更新されるコアオブジェクトのコンテンツは、元のコアオブジェクトに関する差分情報のみを含んでいる第２のコアオブジェクトを作成することによって、反映してもよいことをも当業者は理解されよう。

【0033】

[0048]その上、コアオブジェクト５０の各々は、オブジェクトＩＤ（ＯＩＤ）５２ａと呼ばれる１次識別子によって識別可能である。ＯＩＤ５２ａは、コアオブジェクト５０が作成されたときにそれに割り当てられたコレクション一意の不変な任意長識別子である。ＯＩＤ５２ａのコレクション一意文字は、各ＯＩＤ５２ａが所与のコアオブジェクト５０に１回のみ割り当てられ、コアオブジェクト５０が削除された後でも、コレクションの存続期間の間、決して再利用されないことを意味する。不変性と組み合わせられたとき、コレクション一意ＯＩＤ５２ａは、所与の不変なコアオブジェクト５０の事実上のシグネチャになる。言い換えれば、ＯＩＤ５２ａのコレクション一意文字は、所与のＯＩＤ５２ａとコアオブジェクト５０の厳密な不変コンテンツとの間の永続的および非分離的関係を生じる。コアオブジェクト５０が不変であり、ＯＩＤ５２ａがコレクション一意であることを仮定すれば、特定のコアオブジェクト５０に関連するデータが更新され、更新されたデータに関連する少なくとも１つの新しいコアオブジェクト５０が作成され、それ自体の新しい一意ＯＩＤ５２ａを割り当てられるとき、オブジェクトを更新することができない。データ更新を管理するためのコレクション管理は、以下でより詳細に説明される。

【0034】

[0049]一実施形態では、コレクション一意ＯＩＤ５２ａは、ＯＩＤ５２ａとして絶えず増大する任意長の連続する整数を使用して、生成されたコアオブジェクト５０に割り当てられ、すなわち、各新たに作成されたコアオブジェクト５０は、最後属性（ａｔｔｒｉｂｕｔｅｄ）ＯＩＤ＋１に対応する整数値を有するＯＩＤ５２ａを割り当てられる。しかしながら、代替の実施形態では、各新たに生成されたＯＩＤにコレクション一意ＯＩＤを割り当てるために他のＯＩＤ割当て実施を使用することができることを当業者は理解されよう。

【0035】

[0050]図１、図３および図４を参照すると、一実施形態では、ステップ１４において、圧縮および暗号化が適用される前に、コアオブジェクト５０が、図３のブロブの未加工コンテンツに対応する未加工ブロブ６０ａ中にアセンブルされる。上述のように、一実施形態（図示せず）では、コアオブジェクト５０を個々に圧縮および暗号化することができる。図示の実施形態では、未加工ブロブ６０ａは、ブロブ６０中に含まれているすべてのコアオブジェクト５０のストリームを含む。一実施形態では、未加工ブロブ６０ａは、ブロブ６０が書き込まれたときのコレクションの最後のコアオブジェクト５０（または最新のコアオブジェクト）に関する情報（最後のオブジェクト状態）をも含む。たとえば、限定的ではないが、そのような情報は、ブロブ６０が書き込まれたときのそれらのタイプ（最後のオブジェクトタイプ）の最後のコアオブジェクト５０としてタグ付けされるオブジェクトについてのコアオブジェクトタイプ（Ｏｔｙｐｅ）５２ｂとＯＩＤ５２ａとのリストを含むことができる。ここでも、ブロブ６０が書き込まれたときのコレクションの最後のオブジェクト５０に関する情報（最後のオブジェクト状態）は、コレクション管理のために使用されるコレクション管理情報であり、もう一度以下でより詳細に説明される。

【0036】

[0051]一実施形態では、未加工ブロブ６０ａが、圧縮されたブロブ６０ｂに圧縮され（ステップ１６）、圧縮されたブロブ６０ｂが暗号化され（ステップ１８）、それにより、暗号化されたブロブ６０ｃを生じる。一実施形態では、ブロブのサイズを低減するために使用され、ストレージ中にそれのセキュリティを高める圧縮／暗号化なしに、未加工ブロブ６０ａまたは圧縮されたブロブ６０ｂをブロブ６０として直接使用することができることを当業者は理解されよう。

【0037】

[0052]上記に鑑みて、未加工ブロブ６０ａが暗号化される一実施形態では、ブロブ６０は、データとメタデータ情報の両方を含んでおり、それらのＢＩＤによってのみ識別される。したがって、データおよびメタデータは、それがバックエンド（ローカルメディア、クラウドストレージプロバイダなど）に記憶される前に完全に暗号化される。一実施形態では、各ブロブ６０は、使用される暗号化アルゴリズムに関して個々にタグ付けされ、それは、ブロブ６０が、様々な暗号化アルゴリズムおよび鍵を使用して個々におよび自律的に暗号化されることを可能にする。そのような個々の暗号化は、データストレージを実行するための本方法を使用して記憶されるデータの機密性を高める。

【0038】

[0053]データを他のユーザとセキュアに共有することができるように、本方法を使用して記憶される前に、コアオブジェクト５０に記憶されるべきディレクトリ、ファイル、または他のデータ自体を、個々に秘密暗号化鍵で暗号化することができることを当業者は理解されよう。言い換えれば、コレクションを読み取るためにブロブ解読鍵へのアクセスを有するユーザであっても、そのユーザが適切なデータ解読鍵を有しない限り、データ自体を読み取ることを防止することができる。これは、コレクションが、完全なセキュリティを用いて、中央サーバまたはソフトウェアベースの保護に依拠することなしに複数のユーザと共有されることを効果的に可能にする。

【0039】

[0054]一実施形態では、すべてのブロブ６０は初期チェーンチェックサム（チェーンチェックサム、Chain checksum）６１ｃを含み、チェーンチェックサム６１ｃは、ブロブ６０が作成されたときにブロブ６０から計算されるチェックサム値＋前のブロブ６０のチェーンチェックサムである。このチェーンチェックサム６１ｃは、コレクション中でこれまでに作成されたすべてのブロブの一意のチェーン値を作成する。たとえば、限定的ではないが、動作中、すべてのバックエンドの最後のブロブが、一致するチェーンチェックサム６１ｃを有するという検証は、すべてのブロブ６０が同じコレクションに属することを保証することができる。すべてのブロブ６０は、ブロブ６０が許可されたユーザによって作り出されており、偽造されていなかったことを暗号で確認するように設計された鍵付きハッシュメッセージ認証コード（ＨＭＡＣ）（認証ダイジェスト）６１ｅと、ブロブ６０の送信またはストレージ中に生じる場合があるエラーを迅速に検出するのを助ける完全性チェックサム値（チェックサム）６１ｂとをも含むことができる。

【0040】

[0055]一実施形態では、ブロブ６０は、知られているブロックチェーン検証原理、方法およびプロセスに従って、ピアネットワークによって、コレクションのブロブのチェーンを検証するために使用することができるブロックチェーン検証ハッシュ構造（ブロックチェーン検証）６１ｄをも含むことができる。たとえば、一実施形態では、ネットワークに、ブロブ自体の代わりにブロブの認証ダイジェストを検証させることによって、ブロブのコンテンツを送信または開示することなしに、ブロックチェーン検証を実行することができる。認証ダイジェストが、上記で説明されたように、ブロックチェーン検証のために使用される場合、認証ダイジェストによってハッシングされるペイロードが前のブロブのダイジェストをも含むべきであることを理解されよう。

【0041】

[0056]ブロブ６０の各々はコレクション一意ブロブＩＤ（ＢＩＤ）６１ａによって識別される。インデックスまたはマップを使用せずに、求められるコアオブジェクト５０のＯＩＤ５２ａから直接、所与のオブジェクト５０を含んでいるブロブ６０の識別を可能にするために、コレクション一意ＢＩＤ６１ａは、特定のブロブ６０中に含まれているオブジェクト５０のＯＩＤ５２ａの導関数である。たとえば、限定的ではないが、一実施形態では、ブロブ６０中の第１のオブジェクト５０の絶えず増大する任意長の連続する整数属性ＯＩＤ５２ａは、ブロブ６０についてのＢＩＤ６１ａとして使用される。この実装形態を使用して、求められるＯＩＤよりも低いか、またはそれに等しい最高のＢＩＤ６１ａをもつブロブ６０として、特定のオブジェクト５０を含むブロブ６０を容易に識別することができる。代替の実施形態では、コレクション一意ＢＩＤ６１ａが、ブロブ６０中に含まれているオブジェクト５０のＯＩＤ５２ａの導関数である他の実装形態を使用できることを当業者は理解されよう。ＯＩＤ５２ａと同様に、ＢＩＤ６１ａはまた、概して、所与のブロブ６０に１回のみ割り当てられ、コレクションの存続期間の間、一意のままである。一実施形態では、ブロブの実際のシーケンスを開示することを回避するために、ＢＩＤ６１ａを暗号化することができる。

【0042】

[0057]一実施形態では、ＢＩＤ６１ａはまた、コレクション中に書き込まれることになる次のＢＩＤ６１ａを予測し、コレクションの最後のブロブを識別することが可能であるように予測可能である。ブロブ６０中の第１のオブジェクト５０の絶えず増大する任意長の連続する整数属性ＯＩＤ５２ａが、ブロブ６０（図４を参照）についてのＢＩＤ６１ａとして使用される実施形態では、ＢＩＤ６１ａは暗黙的に予測可能である。図４では、４つのブロブ６０は、ＯＩＤ＃１～＃１３を有するオブジェクトを含むＢＩＤ＃１を有するブロブと、ＯＩＤ＃１４～＃４４を有するオブジェクトを含むＢＩＤ＃１４を有するブロブと、ＯＩＤ＃４５～＃４６を有するオブジェクトを含むＢＩＤ＃４５を有するブロブと、ＯＩＤ＃４７～＃６３を有するオブジェクトを含むＢＩＤ＃４７を有するブロブとを備える。そのような実施形態では、次のＢＩＤは、最後のブロブ６０の最後のオブジェクト５０のＯＩＤ＋１に対応し、コレクションの最後のブロブは、最高ＢＩＤをもつブロブ６０にすぎない。ここでも、代替の実施形態では、コレクションの予測可能なＢＩＤおよび識別可能な最後のブロブを作り出すための代替実装形態をも使用することができることを当業者は理解されよう。

【0043】

[0058]一実施形態では、生成されたブロブ６０をその後分割することができ、分割されたブロブは、それぞれ、特定のブロブ６０に現在含まれているコアオブジェクト５０のＯＩＤ５２ａの導関数である新しいコレクション一意ＢＩＤ６１ａを割り当てられる。ブロブが分割されたとき、割り当てられたＢＩＤ６１ａが、依然として、求められるコアオブジェクト５０のＯＩＤ５２ａから直接、所与のオブジェクト５０を含んでいるブロブ６０の識別を可能にしなければならないことを理解されよう。たとえば、ブロブ６０中の第１のオブジェクト５０の絶えず増大する任意長の連続する整数属性ＯＩＤがブロブ６０についてのＢＩＤ６１ａとして使用される実施形態では、分割は、隣接するＯＩＤが、対応するブロブ６０中にグループ化され、コアオブジェクト５０のＯＩＤ５２ａが、各新しいブロブ６０についてのＢＩＤ６１ａとして使用されている最低ＯＩＤ５２ａを有する、コアオブジェクト５０を常に生じるべきである。

【0044】

[0059]その上、一実施形態では、隣接するブロブ６０（すなわち、コレクション８０中の隣接するＢＩＤ６１ａを有するブロブ６０）を一緒に融合することもでき、融合されたブロブは、特定のブロブ６０に現在含まれているコアオブジェクト５０のＯＩＤ５２ａの導関数である新しいコレクション一意ＢＩＤ６１ａを割り当てられる。ここでも、割り当てられたＢＩＤ６１ａは、依然として、求められるコアオブジェクト５０のＯＩＤ５２ａから直接、所与のオブジェクト５０を含んでいるブロブ６０の識別を可能にしなければならない。たとえば、ブロブ６０中の第１のオブジェクト５０の絶えず増大する任意長の連続する整数属性ＯＩＤがブロブ６０についてのＢＩＤ６１ａとして使用される実施形態では、融合は、融合から生じる新しいブロブ６０についてのＢＩＤ６１ａとして使用されている最低ＯＩＤ５２ａを有する、コアオブジェクト５０のＯＩＤ５２ａを常に生じるべきである。

【0045】

[0060]一実施形態では、所与のタイプ（Ｏｔｙｐｅ）５２ｂのコアオブジェクト５０を、異なるＯｔｙｐｅ５２ｂのコアオブジェクト５０とは別個のブロブ６０にグループ化することができる。したがって、そのような実施形態では、ブロブ６０はまた、タイプ（すなわち、本明細書では、グループ化されるコアオブジェクト５０のタイプ）に関連し、異なるタイプのブロブ６０を異なるバックエンド７０に記憶することができる。これは、たとえば、メタデータ読取り性能を改善するために、データオブジェクトからメタデータを分離すること、Ｏｔｙｐｅ５２ｂなどに基づいて異なるオブジェクト暗号化アルゴリズム／鍵を実装することなどのために使用することができる。そのような実施形態では、タイプ分けされたコアオブジェクト５０と、ブロブ６０と、バックエンド７０とをサポートするために、コレクションレベルにおいてではなく、バックエンドレベルにおいて、対応するコアオブジェクト５０のＯＩＤ５２ａから所与のブロブ６０のＢＩＤ６１ａを導出することができ、ブロブ６０は、不連続ＯＩＤ５２ａを有するコアオブジェクト５０を記憶する。言い換えれば、すべての生成されたコアオブジェクトのＯＩＤ５２ａからではなく、特定のＯｔｙｐｅ５２ｂの対応するコアオブジェクトのＯＩＤ５２ａから、所与のブロブ６０のＢＩＤ６１ａを導出することができ、それにより、不連続ＯＩＤ５２ａを有するコアオブジェクト５０をブロブ６０に記憶することになる。したがって、コアオブジェクト５０を取り出すようにとの後続の要求が、取り出されるべきコアオブジェクト５０のＯｔｙｐｅ５２ｂを考慮に入れて、たとえば、取り出されるべきコアオブジェクト５０の特定のＯｔｙｐｅ５２ｂに関連する（１つまたは複数の）バックエンド７０のみに問い合わせることによって扱われるべきである。

【0046】

[0061]別の実施形態では、ブロブ６０は、それらのオブジェクトタイプ（Ｏｔｙｐｅ）５２ｂに基づいて分離することもでき、したがって、好ましくは、いくつかのＯｔｙｐｅ５２ｂが同じブロブに書き込まれない。たとえば、大きいデータオブジェクトは、メタデータおよびインデックスオブジェクトから分離することが要求され、それにより、メタデータまたはインデックス情報が取り出されるのと同時に、大量のデータが取り出されるのを防ぐことによって性能を改善することができる。したがって、一実施形態では、ブロブ６０へのコアオブジェクト５０のアセンブリを実行する前に、オブジェクトが既存のブロブ６０に追加されるべきであるのかまたは新しいブロブ６０中に作成されるべきであるのかを決定するために、ブロブ６０にアセンブルされるべきコアオブジェクト５０のＯｔｙｐｅ５２ｂを考えることができる。

【0047】

[0062]次に図５を参照すると、データを記憶する方法１０のための上記で説明された構造を使用するファイル３０のストレージの一例が示されている。図５に示されている実施形態では、ファイル３０は、上記で説明された方法１０を使用してクラウドに記憶される。図示の実施形態では、ファイル３０は３つのオブジェクト５０にセグメント化され、１つは、ファイル名、作成日付など、メタデータを含んでおり、２つは、データフラグメントとしてファイルのコンテンツを含んでいる。最初の２つのオブジェクト５０は第１のブロブ６０にアセンブルされ、３つ目のオブジェクトは別のブロブ６０に入れられる。ブロブ６０は圧縮され、暗号化され、バックエンド７０として働くクラウドストレージプロバイダに、インターネット上のセキュア接続を通して送信され、ここで、ブロブ６０はファイル、データベースレコード、オブジェクト、または未加工ストレージとして記憶することができる。図示の実施形態では、ブロブ６０のコピーが、直接ストレージ媒体としても使用することができる（バックエンド７０としても動作する）ローカルキャッシュ中にも保たれる。記憶されたデータを取り出すために、ブロブ６０が読み取られ、解読され、圧縮解除され、ファイルがそれのセグメントから再アセンブルされる逆プロセスを実行するためにブロブ６０の任意のコピーを使用することができることを理解されよう。

【0048】

[0063]上記に鑑みて、ステップ２０において、少なくとも１つのバックエンドにブロブ６０を記憶するステップ（ステップ２０）が、ブロブをストレージ媒体上に記憶するために実行されることを理解されよう。上述のように、バックエンド７０は自律型ストレージ容器であり、サポートされるサービスまたはデバイスに適した形態で（たとえば、ファイル、データベースレコード、クラウドオブジェクト、物理デバイスブロックなどとして）ブロブを、それらのＢＩＤ６１ａを使用して、問い合わせ、記憶し、取り出すことが可能であることを必要とされるにすぎない。バックエンド７０は、メタデータ、構造をサポートすること、オブジェクトまたはブロブがどのように編成されるか、それらの目的などを知ることを必要とされない。バックエンド７０は、本来、ブロブ６０を、それらのＢＩＤ６１ａに基づいて、ブラインドで記憶し、取り出す、完全に一般的で単純なストレージアペンデージ（ａｐｐｅｎｄａｇｅ）である。図示の実施形態では、バックエンド７０はクラウドストレージプロバイダおよびローカルキャッシュによって実施されるが、代替の実施形態では、バックエンド７０がデータを記憶することが可能な任意のストレージ媒体またはサービスであってもよいことを当業者は理解されよう。上記で説明された構造に鑑みて、バックエンドストレージの能力および特徴の差分は、実質的に影響がない。ブロブを異なる分散されたバックエンド７０に記憶することによって、分散されたデータストレージを実行することができるように、複数の分散されたバックエンド７０を使用することができることを理解されよう。その上、ブロブ６０を、複数のバックエンド７０にわたって自由に点在させ、その後、データの完全性に対する影響なしにバックエンド７０間で移動させることができる。

【0049】

[0064]上述のように、ブロブ６０、コアオブジェクト５０およびバックエンド７０は、全体として管理することができ、本明細書でコレクション８０と呼ぶことができる、コヒーレントユニットに一緒にグループ化される。特に、コレクション８０は、ＯＩＤ５２ａおよびＢＩＤ６１ａがコレクション８０について常に一意であることを保証する。一実施形態では、各コレクション８０について、コアオブジェクト５０およびブロブ６０に記憶され、上記で定義されたコレクション管理情報は、コレクション全体をコヒーレントおよび最新の状態に保時するための１次機構として使用される。

【0050】

[0065]図１～図４を参照すると、一実施形態では、方法１０は、ブロブ６０が書き込まれる特定の時間におけるコレクションの状態を反映するコレクション状態２２を維持する、さらなるステップを含む。動作中、コレクション状態を維持することを可能にするために、各ブロブ６０のコレクション管理情報は、ブロブ６０が書き込まれたときのコレクションの状態およびそれのコアオブジェクト５０を含む。一実施形態では、コレクションの状態は、ブロブ６０が書き込まれたとき最後のオブジェクト（最後のオブジェクトタイプ６１ｆ）としてタグ付けされる各Ｏｔｙｐｅ５２ｂの最後のコアオブジェクト５０についてのオブジェクトタイプ（Ｏｔｙｐｅ）５２ｂとＯＩＤ５２ａとのリストを含む。実際、上述のように、一実施形態では、コアオブジェクト５０は、各コアオブジェクト５０の一般的な性質を示すように（たとえば、限定的ではないが、ディレクトリインデックスオブジェクトとファイルデータフラグメントオブジェクトとを区別し、それに応じて各オブジェクトをパースするように）設計された所与のタイプ（ＯＴｙｐｅ）５２ｂを有する。コアオブジェクト５０が作成されたとき、コアオブジェクト５０に、それのＯｔｙｐｅ５２ｂの「最後の」（すなわち、最新のまたは直近に作成された）コアオブジェクトとしてフラグを付けることができる。一実施形態では、各Ｏｔｙｐｅ５２ｂについての各最後のコアオブジェクト５０のＯＩＤ５２ａは、所与のＯｔｙｐｅ５２ｂの最後のコアオブジェクト５０を、それのＯＩＤ５２ａを知る必要なしに、その後取り出すことができるように、最後のブロブ６０のコレクションの状態で記録される。明らかに、所与のＯｔｙｐｅ５２ｂの最後のコアオブジェクト５０の位置を特定するために、コレクションの最後のブロブ６０の識別も必要とされる。

【0051】

[0066]その上、コレクション管理情報は、コアオブジェクト５０が互いに参照することを可能にするオブジェクトリンキング情報（すなわち、オブジェクトがＯＩＤ５２ａまたは他のオブジェクト識別情報を使用して互いにリンクされる）を含む。特定のコアオブジェクト５０のオブジェクトリンキング情報は、対応するコアオブジェクト５０に直接記憶され、コアオブジェクト５０と、ブロブ６０と、コレクション８０とが、互いにリンクされるコアオブジェクト５０のツリー状の構造で一緒に保持される構造のバルクを定義する。一実施形態では、コレクション８０は、各オブジェクトタイプの最後としてフラグを付けられているコアオブジェクト５０に対応する「ヘッド」オブジェクト５０によって定義され、次いで、他のコアオブジェクト５０に連続的にリンクされ、コアオブジェクト５０のツリー状のチェーンとしてオブジェクト５０をグループ化する。そのような実施形態では、コレクション８０の「末尾」（すなわち、そのコレクション状態での最後のブロブおよび最後のオブジェクトタイプ）は、コレクション８０内のすべてのオブジェクト５０の「ヘッド」として働く。代替の実施形態では、オブジェクトを識別し、リンクする代替のやり方を使用することもできることを理解されよう。その上、代替の実施形態では、コアオブジェクト５０を互いにリンクするために、コアオブジェクトタイプ（Ｏｔｙｐｅ）５２ｂとは異なるサブセットを使用することができ、最後のオブジェクトはヘッドオブジェクトである。

【0052】

[0067]データ更新（更新されたデータに関連する新しいコアオブジェクト５０が作成され、それ自体の新しい一意のＯＩＤ５２ａを割り当てられる）の場合、コアオブジェクト５０間のリンクは、新しいコアオブジェクト５０が現在、古いコアオブジェクト５０を置換することを反映するために更新される必要がある。言い換えれば、ＯＩＤ５２ａによって古いコアオブジェクト５０に前にリンクしたコアオブジェクト５０は、次に、ＯＩＤ５２ａによって新しいコアオブジェクト５０にリンクする必要がある。オブジェクト５０のツリー構造の複雑さに応じて、これは、連続的に更新される必要があるコアオブジェクト５０を参照する長いカスケードをもたらすことがある。必要とされるカスケード影響を低減するために、このようなカスケードを制限する既知のデータ構造に従って、コアオブジェクト５０を構造化することができ、これは、たとえば、限定的ではないが、親オブジェクト自体を実際に更新することなしに、親オブジェクトに適用される必要があるＯＩＤリンク更新に関する情報を更新されたコアオブジェクト５０内に含めることによって、またはＯＩＤリンク更新がツリーの上部にカスケードするのを防ぐために、オブジェクトツリー中の戦略的ポイントにおいて、代替の実施形態として以下で説明されるように非ＯＩＤリンクを使用することによってなされる。代替の実施形態では、エイリアス、仮想ＩＤ、プライベートインデックスなどの、オブジェクト識別情報を使用することもでき、このオブジェクト識別情報は、オブジェクトのＯＩＤ５２ａに加えて、オブジェクトをそれによって参照する場合もある代替識別子であり、より新しいコアオブジェクト５０上に後で再割り当てすることができる。たとえば、限定的ではないが、一実施形態では、各コアオブジェクト５０は、最初にＯＩＤ５２ａと同等である仮想ＩＤ（ＶＩＤ）５２ｃを含むことができる。新しいコアオブジェクト５０が作成され、より古いコアオブジェクト５０を置換するものとしてフラグを付けられるとき、新しいコアオブジェクト５０は、より古いコアオブジェクト５０のＶＩＤ５２ｃを自動的に継承することができる。内部的には、ＶＩＤ／ＯＩＤ関連付けを可能にするために、ＶＩＤ５２ｃをＶＩＤ／ＯＩＤペアに記憶することができる。したがって、オブジェクト自体が更新され、置換されるとき、自動的に最新に保たれる識別子を使用してコアオブジェクト５０を一緒にリンクするためにＶＩＤ５２ｃを使用することができる。別の代替の実施形態では、オブジェクト内のリンクを記憶する代わりに、オブジェクト５０を、それらのＯＩＤ５２ａによって外部で追跡し、リンクするためにプライベートインデックスを使用することができる。

【0053】

[0068]一実施形態では、データストレージを実行するための方法１０は、もはや有効でないコアオブジェクト５０によって占有されたストレージスペースをリクレームするために、ガベージコレクション２４を実行するステップをさらに含むことができる。なぜならば、コアオブジェクト５０が、より新しいコアオブジェクト５０によって（すなわちデータ更新の結果として）置換され、削除されたか、またはそれらが他のコアオブジェクト５０によってもはや参照されていない（他のコアオブジェクト５０にリンクされていない）かのいずれかだからである。一実施形態では、ガベージコレクションを実行するステップ２４は、暗黙的または明示的であってもよい、クリーンアップされるべきオブジェクトを識別する（またはフラグを付ける）ステップ２４ａと、コレクションおよびブロブからオブジェクトを物理的に除去する（パージする、purge）ステップ２４ｂとを含む。

【0054】

[0069]一実施形態では、フラグを付けるステップ２４ａ中に、コアオブジェクト５０が他のコアオブジェクト５０からのすべての参照を失ったとき、もはや必要とされないものとして、コアオブジェクト５０に暗黙的にフラグを付けることができる。もはや参照されないものとしてオブジェクトにフラグを付けるためのいくつかの方法を使用することができることを当業者は理解されよう。たとえば、限定的ではないが、一実施形態では、パージするステップ２４ｂ中に処理されるパージ候補リストに、参照されないものとしてフラグを付けられているコアオブジェクト５０を追加することができる。コレクションに書き込まれる最後のコアオブジェクト５０は、アクティブに更新されているコレクションを保護するために、それらが参照されない場合でも、パージ候補リストには決して追加されない。その上、代替の実施形態では、コアオブジェクト５０に、ガベージコレクションの対象となるものとして明示的にフラグを付けることもできる。このことは、新しいコアオブジェクト５０がそれらを置換するために作成されたとき「置換される」ものとして、またはそれらを明示的に削除するコアオブジェクト５０によって「削除される」ものとして、フラグを付けることによってなされる。そのような場合、置換／削除されたコアオブジェクト５０のＯＩＤ５２ａを、それらを置換／削除したオブジェクトのＯＩＤ５２ａとともに、内部インデックスに追加することができ、インデックスはパージ候補リストとして使用される。

【0055】

[0070]パージするステップ２４ｂ中に、パージ候補リストにリストされたコアオブジェクト５０およびブロブ６０は、物理的に除去される。パージプロセスを最適化するために、ブロブ使用しきい値、パージされるべきであるオブジェクトの最小寿命など、様々なパージパラメータを設定することができることを当業者は理解されよう。パージパラメータは、たとえば、限定的ではないが、以下でより詳細に説明されるように、アーカイブする目的のためにオブジェクトのパージを制限するために有用である。ブロブ６０を完全にまたは部分的にパージすることができることを理解されよう。ブロブ６０内のすべてのオブジェクト５０が物理的に除去されるべきである場合、（１つまたは複数の）バックエンド７０からブロブ６０を完全に削除することができる。しかしながら、ブロブ６０のいくつかのオブジェクト５０のみが物理的に除去されるべき場合、ブロブ６０を開く（すなわち、取り出し、解読し、圧縮解除する）ことができ、特定のオブジェクト５０を削除することができ、ブロブ６０を再圧縮し、再暗号化し、同じＢＩＤ６１ａの下で対応する（１つまたは複数の）バックエンド７０に書き込むことができる。

【0056】

[0071]ガベージコレクションは、各バックエンド７０について同等であることを必要とされないことを当業者は理解されよう。言い換えれば、部分的にまたは完全にパージされたブロブは、バックエンド７０にわたって同期させられる必要がない。いくつかのバックエンド７０は、それらの中の元のオブジェクト５０のすべてをもつブロブ６０をホストし続けることができるが、他のバックエンド７０は、コレクション８０の完全性に影響を及ぼすことなしに、クリーンアップされたブロブ６０のみを有することができる。すべてのブロブバージョンが、アクティブな不変オブジェクト５０のまったく同じコピーを含んでいるので、コレクション８０の現在状態を反映するためにブロブ６０の任意のバージョンを使用することができることを当業者は理解されよう。ブロブ６０のバージョン間のばらつきは、使用されるストレージの量と、履歴データ（参照されないコアオブジェクト５０）の利用可能性とに影響を及ぼすにすぎない。この非対称性は、アーカイバル目的のために有用であることができることを当業者は理解されよう。

【0057】

[0072]たとえば、限定的ではないが、一実施形態では、直近のオブジェクト５０のみを含んでいる完全にパージされたブロブ６０をホストするために、ローカルハードディスク、ＳＳＤドライブ、ＳＡＮ、およびキャッシュされたクラウドストレージなどの高性能なバックエンド７０を指定することができるが、元の（参照されない）オブジェクト５０のより大きい量をもつブロブをホストするために、ＷＯＲＭデバイス（すなわち、ＤＶＤ、ブルーレイディスクなどの追記型（Ｗｒｉｔｅ Ｏｎｃｅ Ｒｅａｄ Ｍａｎｙ）媒体）、低いコストおよび性能のハードディスク、および長期間アーカイバルクラウドストレージサービスなど、他のより低い性能またはより低いコストのバックエンド７０を指定することができる。

【0058】

[0073]次に図６を参照すると、一実施形態による、最後のオブジェクトタイプ、リンキングを使用するコレクション管理と、ガベージコレクションに対するそれらの影響との一例が示されている。図６の例では、ブロブ６０ごとにコレクション８０の展開が続く。

【0059】

[0074]最初に、ステップ１において、（ＯＩＤ＃１および＃２を割り当てられた）２つのコアオブジェクト５０がブロブ＃１に書き込まれる。この初期段階において、いずれのコアオブジェクト５０も、そのタイプ（Ｏｔｙｐｅ）５２ｂの最後のオブジェクトとして追跡されない。コアオブジェクト５０はリンクを含んでおらず、リンクされない。この時点で、オブジェクト＃１およびオブジェクト＃２は、参照されないオブジェクトと見なされるが、それらがコレクションのまさに最後のオブジェクトであるので、パージ可能なコアオブジェクト５０と見なされない。

【0060】

[0075]ステップ２において、（ＯＩＤ＃３および＃４を割り当てられた）２つのさらなるコアオブジェクト５０が追加され、ブロブ＃３に書き込まれる。コアオブジェクト＃４は、それのタイプ（Ｏｔｙｐｅ）５２ｂの最後のコアオブジェクト５０として追跡され、コアオブジェクト＃１、＃２および＃３へのリンクを含んでおり、それにより、コアオブジェクト＃４をヘッドとしてもつオブジェクトのツリーを生成し、ブロブ＃１に書き込まれるものを含むすべての他のオブジェクトをリンクする。ヘッドは、ブロブ＃３のコレクション状態では、タイプ＃１の最後のオブジェクト（この例では、オブジェクト＃４のオブジェクトタイプ）として記録される。

【0061】

[0076]ステップ３において、（ＯＩＤ＃５および＃６を割り当てられた）２つのさらなるコアオブジェクト５０が追加され、ブロブ＃５に書き込まれる。コアオブジェクト＃５は、オブジェクト＃４にリンクし、Ｏｔｙｐｅ＃１の最後のオブジェクトとして追跡される（すなわち、オブジェクト＃５は現在、オブジェクトのツリーのヘッドである）。オブジェクト＃６は、この段階で、他のコアオブジェクト５０に関係せず、したがって、参照されない状態にあるが、それがコレクションの最後のオブジェクトであるので、パージ可能なオブジェクトと見なされない。

【0062】

[0077]ステップ４において、（ＯＩＤ＃７、＃８および＃９を割り当てられた）３つのさらなるコアオブジェクトが追加され、ブロブ＃７に書き込まれる。コアオブジェクト＃７、＃８および＃９は、それらのＯｔｙｐｅの最後のオブジェクトとして追跡されない。コアオブジェクト＃７、＃８および＃９はリンクを含んでおらず、リンクされない。同じく、これらのオブジェクトは、参照されないものと見なされるが、それらがコレクションの最後のコアオブジェクト５０であるので、パージ可能なコアオブジェクト５０とは見なされない。

【0063】

[0078]ステップ５において、（ＯＩＤ＃１０を割り当てられた）コアオブジェクト５０が追加され、ブロブ＃１０に書き込まれる。コアオブジェクト＃１０はオブジェクト＃５を置換する。オブジェクト＃１０は、それのＯｔｙｐｅ（タイプ＃１）の最後のコアオブジェクトとして追跡され、オブジェクト＃４、＃６、＃７および＃８にリンクされる。これは、オブジェクト＃１０が現在ヘッドであるオブジェクトのツリーを再構成する。オブジェクト＃１０とオブジェクト＃９とによって置換され、現在、孤立（ｏｒｐｈａｎｅｄ）している、オブジェクト＃５は、参照されず、使われていないものと見なされ、パージ候補リストに追加することができる。

【0064】

[0079]ステップ６において、（ＯＩＤ＃１１および＃１２を割り当てられた）２つのさらなるコアオブジェクト５０が追加され、ブロブ＃１１に書き込まれる。オブジェクト＃１２はオブジェクト＃１０を置換する。オブジェクト＃１２は、それのＯｔｙｐｅ（タイプ＃１）の最後のオブジェクトとして追跡され、オブジェクト＃４、＃６、および＃１１にリンクされる。これは、同じく、コアオブジェクト＃１２が現在ヘッドであるオブジェクトのツリーを再構成する。コアオブジェクト＃７、＃８および＃１０は、使われなくなり、パージ候補リストに追加することができる。

【0065】

[0080]図６の例は、コアオブジェクト５０が追加、リンク、置換または廃棄されるとき、各ブロブ６０中のコレクション状態が、ステップの各々においてコレクション８０中のすべてのアクティブコアオブジェクト５０の厳密な状態を反映することを示している。そのような例はまた、以下でより詳細に説明されるように、時間移動（ｔｉｍｅ ｔｒａｖｅｌ）（または連続探査（ｃｏｎｔｉｎｕｕｍ ｅｘｐｌｏｒａｔｉｏｎ））のために、データストレージを実行するための方法１０を使用して作り出される構造をどのように容易に使用することができるかの容易な理解を可能にする。本明細書の過程において、「時間移動」という用語は、時間的に戻り、記憶されたデータを、それが前の状態で存在したとして、検査する能力を指す。上記で説明された構造を使用して、時間的に移動し（または連続探査を実行し）、コレクションの状態を、コレクションが過去のある時点において存在したとして、検討するために、コレクション８０の「末尾」のビューは、所与のＢＩＤ６１ａまたはＯＩＤ５２ａにあるように再定義される（すなわち、所与のＢＩＤ６１ａをもつブロブ６０、または所与のＯＩＤ５２ａに関連するブロブ６０が、最後のブロブ６０であった時点に、最後のブロブ６０を手動で再定義する）。したがって、すべてのオブジェクトツリーおよびコアオブジェクト５０のビューはまた、所与のＢＩＤ６１ａをもつブロブ６０が最後のブロブ６０であった厳密な時点において、それらがどのように存在したかを反映する。したがって、記憶されたデータの厳密なアーカイブプロセスまたは「スナップショット」がとられることを必要とすることなしに、時間移動を実行することができ、過去のオブジェクトがまだパージされていない限り、記憶されたデータ内の時間移動に対する制限または限界がないことを当業者は理解されよう。コレクションの末尾ＢＩＤまたはＯＩＤビューを再定義することが、コレクション自体を変更せず、複数のユーザが、コレクションの異なるビューを同時に保持してもよいことをも当業者は認識されよう。

【0066】

[0081]上記に鑑みて、時間移動と最適化されたブロブパージパラメータとの組合せは、実質的に低減されたストレージリソースを使用する高度アーカイブストラテジーを可能にすることができる。たとえば、限定的ではないが、一実施形態（図示せず）では、従来技術のアーカイバル「スナップショット」機能の挙動をエミュレートするためにバックエンド７０の連続性を使用することもできるが、コレクション８０を、データがアーカイバルバックエンド上で凍結されるより前のいかなる単一の時点においても連続的に時間移動することを可能にする。そのような実施形態では、元のブロブがすべてコレクションの１次バックエンド（アーカイバルバックエンド）中で凍結され、より新しいまたは部分的にパージされたブロブのみが２次バックエンドに記録されるように、１次バックエンドと２次バックエンドとを階層化することができる。したがって、１次バックエンドと２次バックエンドの両方を、コレクションのための可能なバックエンド７０として使用することができる（すなわち、データを取り出すために１次バックエンドと２次バックエンドの両方を使用することができる）が、更新および削除は、２次バックエンド上に記録されるにすぎない。同様のストラテジーを、３次バックエンドに関して１次および２次バックエンド（アーカイバルバックエンド）のために後で使用することができる（すなわち、２次バックエンドのコンテンツも凍結され、３次バックエンドが導入され、より新しいまたは部分的にパージされたブロブは３次バックエンドに記録される）。この時点で、１次、２次および３次バックエンドはコレクションのための可能なバックエンドとして使用されるが、３次バックエンドのみがオブジェクト／ブロブ追加および／または削除を受ける。

【0067】

[0082]上記で説明されたブロブ６０およびバックエンド７０を使用して、たとえば、ブロブ６０を２つまたはそれ以上のロケーションに同時に書き込むミラーリングされた階層化バックエンド７０を使用して、完全および増分バックアップストラテジーを容易に実装することもできることをも当業者は理解されよう。代替的に、ライブバックエンド７０からスタンバイバックエンド７０に外部でブロブ６０をコピーすることができる。コアオブジェクト５０が不変であり、ブロブ６０がログ構造化されることを仮定すれば、ブロブ６０を同期させるか、またはどのブロブ６０が最後のバックアップから変更されたかの検証に進む必要がなく、バックアップまたはコピーされる必要があるブロブ６０のみが新しいブロブ６０であることを理解されよう。

【0068】

[0083]上記に鑑みて、上記で説明された構造が、特定の損失または損傷したブロブ６０のデータ以外に、データ損失を生じることなしに、概して、ブロブ６０に対する損失または損傷を復元することができるロバストな構成を与えることを理解されよう。実際、各ブロブ６０のコレクション管理情報が、ブロブ６０が書き込まれたときのコレクションの状態とそれのコアオブジェクト５０とを含むことを仮定すれば、損傷または損失したブロブが重要な構造的情報を含んでいた場合でも、要求を処理し続けるために、概して、先行するブロブ６０（すなわち、特定の損失または損傷したブロブの前に作成されたブロブ）を使用することができる。

【0069】

[0084]前のブロブ６０が、依然として、必要なコレクション管理情報のすべてを含んでいる場合、情報のそのような復元を容易に実行することができる。しかしながら、ガベージコレクションが実行され、情報をクリーンアップし始めた場合、前のブロブ６０は、コレクション８０を探査することを再開するために必要なすべての情報を確実に含んでいるとは限らない。したがって、一実施形態では、ディレクトリインデックスなどの重要なオブジェクトが技術的に使われていない場合でも、ブロブ６０の損傷または損失に続く情報の復元の場合に、後で関係する場合がある情報を削除することを回避するために、重要なオブジェクトを保持するようにガベージコレクションを構成することができる。その上、ガベージコレクションが実行され、コレクションを探査することを再開するのに必要な情報が削除された場合、他のコアオブジェクト５０へのリンクを含んでいる重要なコアオブジェクト５０を、参照されるオブジェクトから再構成することができる。

【0070】

[0085]一実施形態では、データストレージを実行するための方法１０は、コレクションを２つまたはそれ以上の別個のサブコレクション２５にフォークする（またはクローニングする）ステップをさらに含むことができ、各サブコレクション８０は、それらが共通に有する過去のオブジェクトおよびブロブのための同じ物理的ブロブおよびバックエンドを依然として共有しながら、個々に展開することができる。コレクション８０がフォークされるとき、コレクション８０は、実際のスナップショットまたはコピーがないということよりはむしろ、フォークされたコレクション８０間の単純な共有部分があるということを除いて、実質的に、従来技術の「スナップショット」をとること、またはコレクション８０全体をコピーし、次いでコピーを変更することと同等の物である。一実施形態では、コレクションをフォークするステップ２５を進めるために、分散されたデータストレージを実行するための方法１０は、複数の「最後のブロブ」を導入する（すなわち、コレクションの「末尾」を分割する）ステップを含む。

【0071】

[0086]複数の最後のブロブ６０から、各フォークは、オブジェクトのそれ自体のツリーを定義する。したがって、「最後のブロブ」が、コレクションの状態とコレクションのすべてのコアオブジェクト５０とを一緒に保持する鍵である、上記で説明された構造を仮定すれば、各フォークは、コレクション８０の一意のビュー（一意のサブコレクション）を表し、他のフォークまたはベースコレクション８０のオブジェクトまたは状態に影響を及ぼすことなしに、この特定のサブコレクション中でコアオブジェクト５０を作成／更新することができる。方法１０は、対応するフォークによって生成された各サブコレクション中で個々に実行される更新を、コアオブジェクト５０およびブロブ６０の一意のチェーンを含んでいる単一のコレクション８０中に再結合することができるように、フォークを合成および／またはマージする後続のステップをさらに含むことができることを理解されよう。

【0072】

[0087]一実施形態では、時間移動は、各個々のフォーク上で並行して実行することができる。
[0088]実施形態によっては、フォークが論理的または物理的のいずれかであってもよいことを理解されよう。以下でより詳細に説明されるように、論理的フォークは、同じバックエンドの範囲内に作成され、他のフォークと同じブロブ、ＯＩＤおよびＢＩＤ名前空間を共有する。物理的フォークは、別個のバックエンド中に実装され、各々、それら自体の一意のブロブ、ＯＩＤおよびＢＩＤ名前空間を維持する。本方法１０のコレクションを複数のサブコレクションにフォークするステップを実装するために、いずれかのフォークタイプ（すなわち、論理的フォークまたは物理的フォークのいずれか）を使用することができることを当業者は理解されよう。

【0073】

[0089]物理的フォークが別個のバックエンドおよび名前空間を使用するので、作成された物理的フォークが、同じＯＩＤ５２ａおよびＢＩＤ６１ａを、生成されたオブジェクトおよびブロブに割り当てることが可能であることを当業者は理解されよう。したがって、物理的フォークをマージするとき、新しい一意のＯＩＤ５２ａをもつターゲットフォーク上に、マージされたオブジェクトを再作成することが必要になる。言い換えれば、論理的フォークでは可能であるが、生成されたフォーク間のオブジェクトを単純にリンクすることは可能でない。上記に鑑みて、２つまたはそれ以上の物理的フォークは、物理的フォークが完全に分離され（ただし、各フォークのブロブに記録される一意フォーク識別子（ＦＩＤ）を通して区別される）、互いとは無関係に展開することを仮定すれば、衝突するＢＩＤ６１ａ ＯＩＤ５２ａ（すなわち同様のＢＩＤ６１ａおよび／またはＯＩＤ５２ａ）を有することができる。したがって、動作中、２つまたはそれ以上の物理的フォークは、共有部分（すなわち、物理的フォークの作成の前に生成された部分）のみを有する異なるコレクションと同様に動作する。２つの物理的フォークをマージするために、マージヘルパーは、他の物理的フォーク上で作成されたオブジェクトに対応するターゲットフォーク上で新しいオブジェクトを作成し、したがって、別の物理的フォークに対して適用される変更を再統合する（以下で詳述される図７ｄおよび対応する例を参照）ことが必要とされる。

【0074】

[0090]一実施形態では、チェーンチェックサムによって物理的フォークをさらに保護することができる。そのようなチェックサム値は、物理的フォークの合成またはマージに関与する前に、物理的フォークが同じ共通ブロブに基づくことを検証するために使用することができる。

【0075】

[0091]図７ａを参照すると、論理的フォークが開かれ、更新され、その後ベースコレクションに合成される、一実施形態による、コレクションをフォークすることの一例が表されている。ここでも、図７ａの例では、ブロブ６０ごとにコレクション８０およびサブコレクションの展開が続く。図７ａの例では、コレクションのコアオブジェクトのための２つのオブジェクトタイプ（Ｏｔｙｐｅ）５２ｂ、すなわち、通常コアオブジェクトのためのＯｔｙｐｅ＃１と、論理的フォークコアオブジェクトを表すＯｔｙｐｅ＃－５とがある。

【0076】

[0092]ステップ１において、（ＯＩＤ＃１および＃２を割り当てられた）２つのコアオブジェクト５０が作成され、ブロブ＃１に書き込まれる。オブジェクト＃２は、オブジェクト＃１にリンクし、Ｏｔｙｐｅ＃１の最後のオブジェクトとしてフラグを付ける。オブジェクト＃１および＃２をもつオブジェクトツリーは、Ｏｔｙｐｅ＃１の最後のオブジェクトとしてのオブジェクト＃２を伴って、ブロブ＃１に記憶されたコレクションの状態に反映される。

【0077】

[0093]ステップ２において、論理的フォークコアオブジェクトが作成され（ＦＩＤ＃３を割り当てられ、それ自体の使用のために１９までのオブジェクトＯＩＤを予約し）、（ＯＩＤ＃４を割り当てられた）オブジェクトが作成され、ブロブ＃３に書き込まれる。オブジェクト＃４は、フォーク＃３のサブコレクション中のコレクションに追加され、オブジェクト＃２にリンクされる。ブロブ＃３に記憶されたコレクション状態は、ブロブ＃３がフォーク＃３のサブコレクションに属し、オブジェクトのツリーがオブジェクト＃４から開始することを反映する。ブロブ＃３に記憶されたコレクション状態は、最後のフォークオブジェクト（ＯＴｙｐｅ＃－５）がフォーク＃３であることをも反映する。この時点で、コレクション８０は、２つのサブコレクション（元のコレクションのサブコレクション、およびフォーク＃３のサブコレクション）を含み、その両方はオブジェクト＃１および＃２を共有するが、フォーク＃３のサブコレクションは、より大きいオブジェクトツリーを有する（すなわち、オブジェクト＃４をも含む）。

【0078】

[0094]ステップ３において、（ＯＩＤ＃５および＃６を割り当てられた）２つの新しいコアオブジェクト５０がフォーク＃３のサブコレクション中で作成され、ブロブ＃５に記憶される。オブジェクト＃６は、オブジェクト＃４および＃５にリンクされ、それのＯｔｙｐｅ（タイプ＃１）の最後のオブジェクトとしてフラグを付けられる。これは、オブジェクト＃１および＃２を依然として共有するヘッド（すなわち最後のオブジェクト）としてオブジェクト＃６をもつオブジェクトのツリーを作成し、サブコレクションはベースコレクションに対応する。ステップ３において、フォーク＃３を参照すると、フォーク＃３は、フォーククローズオブジェクト＃７の書込みによって閉じられる。ブロブ＃５は、フォーク＃３の下に書き込まれ、フォークおよびそれのオブジェクトの最新の状態を反映する。

【0079】

[0095]この時点で、コレクションは２つのフォークを有し、ベースコレクションであるフォーク＃０（ＦＩＤ＃０）は、Ｏｔｙｐｅ＃１の最後のオブジェクトがオブジェクト＃２（ＯＩＤ＃２）であることを示す状態を有し、それは２つのオブジェクト（オブジェクト＃１および＃２）のツリーを形成し、閉じられた論理的フォークのサブコレクションであるフォーク＃３（ＦＩＤ＃３）は、それのヘッドとして（およびオブジェクト＃５、＃４、＃２および＃１にリンクする）オブジェクト＃６（ＯＩＤ＃６）をもつオブジェクトのツリーを有する。フォーク＃３のサブコレクション中のコレクション状態はまた、最後のフォークオブジェクト（Ｏｔｙｐｅ＃－５）がＯＩＤ＃７を有することを示し、それにより、フォーク＃３が閉じられたことを示す。

【0080】

[0096]ステップ４において、論理的フォーク＃３のサブコレクションは、（＃１９までのＯＩＤがフォーク＃３に予約されたことを仮定すれば）ベースコレクションのための次の予約されていないＯＩＤである（ＯＩＤ＃２０を割り当てられたフォークベース合成コアオブジェクト５０を作成することによってベースコレクションに合成され、ブロブ＃２０に書き込まれる。合成は、フォーク＃３のサブコレクションの状態を反映するためにコレクション状態を更新することによって実行され、それにより、フォーク＃３のサブコレクションのオブジェクトツリーからのすべてのオブジェクトをメインコレクション（ＦＩＤ＃０）中に自動的に統合する。合成がベースコレクションに対して行われるので、ブロブ＃２０もベースコレクションに属し、ＦＩＤ＃０を有する。この時点で、フォークオブジェクト＃２０（Ｏｔｙｐｅ＃－５の最後のオブジェクト）を通してフォーク履歴を検査することができるが、場合によっては、コレクションは、フォークを有しないと見なされ、他の標準コレクションのように動作する。

【0081】

[0097]図７ｂを参照すると、２つの論理的フォークが開かれ、更新され、その後ベースコレクションにマージされる、一実施形態による、コレクションをフォークすることの一例が表されている。ここでも、図７ｂの例では、ブロブ６０ごとにコレクション８０およびサブコレクションの展開が続く。図７ｂの例では、ここでも、コレクションのコアオブジェクトのための２つのオブジェクトタイプ、すなわち、通常コアオブジェクトのためのＯｔｙｐｅ＃１と、論理的フォークコアオブジェクトを表すＯｔｙｐｅ＃－５とがある。

【0082】

[0098]ステップ１において、（ＯＩＤ＃１および＃２を割り当てられた）２つのコアオブジェクト５０が作成され、ブロブ＃１に書き込まれる。オブジェクト＃２は、オブジェクト＃１にリンクし、Ｏｔｙｐｅ＃１の最後のオブジェクトとしてフラグを付けられる。オブジェクト＃１および＃２をもつオブジェクトツリーは、Ｏｔｙｐｅ＃１の最後のオブジェクトとしてのオブジェクト＃２を伴って、ブロブ＃１に記憶されたコレクションの状態に反映される。

【0083】

[0099]ステップ２において、論理的フォークコアオブジェクトが作成され（ＦＩＤ＃３を割り当てられ、それ自体の使用のために＃１９までのオブジェクトＯＩＤを予約し）、（ＯＩＤ＃４を割り当てられた）コアオブジェクトが作成され、ブロブ＃３に書き込まれる。オブジェクト＃４は、フォーク＃３のサブコレクション中のコレクションに追加され、オブジェクト＃２にリンクされる。ブロブ＃３に記憶されたコレクション状態は、ブロブ＃３がフォーク＃３のサブコレクションに属し、オブジェクトのツリーがオブジェクト＃４から開始することを反映する。ブロブ＃３に記憶されたコレクション状態は、最後のフォークオブジェクト（ＯＴｙｐｅ＃－５）がフォーク＃３であることをも反映する。この時点で、コレクション８０は、２つのサブコレクション（元のコレクションのサブコレクション、およびフォーク＃３のサブコレクション）を含み、その両方はオブジェクト＃１および＃２を共有するが、フォーク＃３のサブコレクションは、より大きいオブジェクトツリーを有する（すなわち、オブジェクト＃４をも含む）。

【0084】

[00100]ステップ３において、第２の論理的フォークコアオブジェクトが作成され（ＦＩＤ＃２０（利用可能な次のＯＩＤ）を割り当てられ、それ自体の使用のために＃３９までのオブジェクトＯＩＤを予約し）、（ＯＩＤ＃２１を割り当てられた）コアオブジェクトが作成され、ブロブ＃２０に書き込まれる。オブジェクト＃２１は、フォーク＃２０のサブコレクション中のコレクションに追加され、オブジェクト＃２にリンクされる。ブロブ＃２０に記憶されたコレクション状態は、ブロブ＃２０がフォーク＃２０のサブコレクションに属し、オブジェクトのツリーがオブジェクト＃２１から開始することを反映する。ブロブ＃２０に記憶されたコレクション状態は、最後のフォークオブジェクト（ＯＴｙｐｅ＃－５）がフォーク＃２０であることをも反映する。フォークオブジェクト＃２０は、フォーク＃３がこの時点でもアクティブであることを示す。この時点で、コレクション８０は、３つのサブコレクション（元のコレクションのサブコレクション、フォーク＃３のサブコレクション、およびフォーク＃２０のサブコレクション）を含み、すべてがオブジェクト＃１および＃２を共有するが、それ以外は異なるオブジェクトヘッドおよびツリーを有する。

【0085】

[00101]ステップ４において、フォーク＃３はフォーク＃２０と並行して展開する。（ＯＩＤ＃５および＃６を割り当てられた）２つのコアオブジェクト５０が作成される。オブジェクト＃６は、オブジェクト＃４および＃５にリンクされ、それのＯｔｙｐｅ（タイプ＃１）の最後のオブジェクトとしてフラグを付けられる。これは、ヘッド（すなわち最後のオブジェクト）としてオブジェクト＃６をもつ、フォーク＃３中のオブジェクトのツリーを作成する。ステップ４において、フォーク＃３を参照すると、フォーク＃３は、（ＦＩＤ＃７を割り当てられた）フォーククローズオブジェクト＃７の書込みによって閉じられる。ブロブ＃５は、フォーク＃３の下に書き込まれ、フォークおよびそれのオブジェクトの最新の状態を反映する。

【0086】

[00102]ステップ５において、フォーク＃２０はフォーク＃３と並行して展開する。（ＯＩＤ＃２２、＃２３および＃２４を割り当てられた）３つのコアオブジェクト５０が作成され、ブロブ＃２２に書き込まれる。オブジェクト＃２４はオブジェクト＃２１および＃２３にリンクされる。オブジェクト＃２４は、それのＯｔｙｐｅ（タイプ＃１）の最後のオブジェクトとしてフラグを付けられる。オブジェクト＃２３はオブジェクト＃２２にリンクされる。これは、ヘッド（すなわち最後のオブジェクト）としてオブジェクト＃２４をもつ、フォーク＃２０中のオブジェクトのツリーを作成する。ステップ５において、フォーク＃２０を参照すると、フォーク＃２０は、（ＦＩＤ＃２５を割り当てられた）フォーククローズオブジェクトの書込みによって閉じられ、同じくブロブ＃２２に書き込まれる。ブロブ＃２２は、フォーク＃２０の下に書き込まれ、フォークおよびそれのオブジェクトの最新の状態を反映する。

【0087】

[00103]ステップ６において、論理的フォーク＃３のサブコレクションは、（ＦＩＤ＃４０（最後のＯＩＤがフォーク＃２０に予約された後に、利用可能な次のＯＩＤ）を割り当てられた）マスタフォークコアオブジェクトを作成することによってベースコレクションに合成され、ブロブ＃４０に書き込まれる。合成は、フォーク＃３のサブコレクションの状態を反映するためにコレクション状態を更新することによって実行され、それにより、フォーク＃３のサブコレクションのオブジェクトツリーからのすべてのオブジェクトをメインコレクション中に自動的に統合する。マスタフォークオブジェクト＃４０は、合成されたフォーク（ＦＩＤ＃３）と、この時点で依然としてアクティブである他のフォーク（ＦＩＤ＃２０）と、マスタフォーク（ＦＩＤ＃４０）とを識別する。

【0088】

[00104]マスタフォーク（ＦＩＤ＃４０）およびフォークオブジェクト＃２０がコレクション８０の異なる展開を反映するので、（フォーク＃３の場合に行われたように）これらの２つのフォークのコンテンツを単純に合成することができない。したがって、両方のフォークの展開を単一のフォーク中に統合するために、２つのフォークはマージされなければならない。したがって、ステップ７において、フォーク＃２０とフォーク＃４０とをマージする目的で、新しい論理的フォークが作成される（ＦＩＤ＃４１を割り当てられ、それ自体の使用のために＃５０までのオブジェクトＯＩＤを予約する）。（ＯＩＤ＃４２を割り当てられた）コアオブジェクト５０が作成される。オブジェクト＃４２はマスタフォーク＃４０のオブジェクト＃５を置換し、フォーク＃２０のオブジェクト＃２１を削除する。（ＯＩＤ＃４３を割り当てられた）追加のコアオブジェクト５０が作成され、３つのオブジェクトツリーに属するオブジェクト、すなわち、１）マージフォーク＃４１の新たに作成されたオブジェクト＃４２、２）マスタフォーク＃４０のオブジェクト＃４（およびしたがって、マスタフォーク＃４０からのオブジェクトのチェーン＃４－＃２－＃１）、ならびに３）フォーク＃２０のオブジェクト＃２３にリンクする。オブジェクト４３は、現在、マージフォーク＃４１のＯｔｙｐｅ＃１の新しいヘッドオブジェクトである。ステップ７において、フォーク＃４１を参照すると、フォーク＃４１は、（ＦＩＤ＃４４を割り当てられた）フォーククローズコアオブジェクトの書込みによって最終的に閉じられ、ブロブ＃４１に書き込まれる。ブロブ＃４１はフォーク＃４０の下に書き込まれ、コレクション状態は、フォーク＃２０および＃４０からのすべての要素をマージするオブジェクトのツリーを反映する。

【0089】

[00105]現在、マージフォーク＃４０が、すべての他のフォークが１つのフォーク（フォーク＃４１）中にマージされたコレクションの状態を表すと仮定すれば、論理的フォーク＃４１のサブコレクションは、（ＦＩＤ＃５１（利用可能な次のＯＩＤ）を割り当てられた）フォークベース合成コアオブジェクトでベースコレクションに合成される。この合成は、フォーク＃４１のサブコレクションの状態を反映するためにコレクション状態を更新することによって実行され、それにより、フォーク＃４１のサブコレクションのオブジェクトツリーからのすべてのオブジェクトをメインコレクション（ＦＩＤ＃０）中に自動的に統合する。合成がベースコレクションに対して行われるので、ブロブ＃５１もベースコレクションに属し、ＦＩＤ＃０を有する。この時点で、コレクションは、フォークを有しないと見なされ、他の標準コレクションのように動作する。

【0090】

[00106]図７ｃを参照すると、物理的フォークが開かれ、更新され、その後ベースコレクションに合成される、一実施形態による、コレクションをフォークすることの一例が表されている。ここでも、図７ｃの例では、ブロブ６０ごとにコレクション８０およびサブコレクションの展開が続く。図７ｃの例では、コレクションのコアオブジェクトのための２つのオブジェクトタイプ、すなわち、通常コアオブジェクトのためのＯｔｙｐｅ＃１と、物理的フォークコアオブジェクトを表すＯｔｙｐｅ＃－６とがある。

【0091】

[00107]ステップ１において、（ＯＩＤ＃１および＃２を割り当てられた）２つのコアオブジェクト５０が作成され、ブロブ＃１に書き込まれる。オブジェクト＃１および＃２をもつオブジェクトツリーは、Ｏｔｙｐｅ＃１の最後のオブジェクトとしてのオブジェクト＃２を伴って、ブロブ＃１に記憶されたコレクションの状態に反映される。さらに、（ＦＩＤ＃３を割り当てられた）物理的フォークコアオブジェクトが作成される。各Ｏｔｙｐｅについての最後のオブジェクト（Ｏｔｙｐｅ＃１についてのＯＩＤ＃２、およびＯｔｙｐｅ＃－６についてのＯＩＤ＃３）は、ブロブ＃３中のコレクション状態に記録される。ブロブ＃１がこの時点でベースコレクションに属することを仮定すれば、それはＦＩＤ＃０を用いて書き込まれる。

【0092】

[00108]新しい物理的フォーク（フォーク＃３）のすべてのブロブ６０を保存するために、新しいバックエンドが割り当てられる。新しい物理的フォークに関連するブロブを保存するために、任意のバックエンドタイプおよび／または構成を使用することができることを理解されよう。一実施形態では、バックエンドは、一時メモリベースフォークであってもよい。

【0093】

[00109]ステップ２において、（ＯＩＤ＃４を割り当てられた）コアオブジェクトが作成され、ブロブ＃４に書き込まれる。オブジェクト＃４は、ＦＩＤ＃３をもつコレクションに追加され、物理的フォーク（フォーク＃３）は、現在、ヘッドとしてのＯＩＤ＃４が物理的フォークに記憶され、ベースコレクションに記憶されたＯＩＤ＃２および＃１にチェーン結合された、オブジェクトのチェーンを表す。ブロブ＃３に記憶されたコレクション状態は、ブロブ＃３がフォーク＃３（ＦＩＤ＃３）のサブコレクションに属し、オブジェクトのツリーがオブジェクト＃４から開始することを反映する。この時点で、コレクション８０は、２つのサブコレクション（元のコレクションのサブコレクション、およびフォーク＃３のサブコレクション）を含み、その両方はオブジェクト＃１および＃２を共有するが、フォーク＃３のサブコレクションは、より大きいオブジェクトツリーを有する（すなわち、オブジェクト＃４をも含む）。物理的フォーク（フォーク＃３）が、ヘッドとしてＯＩＤ＃２をもつオブジェクトツリーを依然として含むベースコレクションに影響を及ぼさないことを理解されよう。

【0094】

[00110]ステップ３において、（ＯＩＤ＃５および＃６を割り当てられた）２つの新しいコアオブジェクト５０がフォーク＃３のサブコレクション中で作成され、ブロブ＃５に記憶される。オブジェクト＃６は、オブジェクト＃４および＃５にリンクされ、それのＯｔｙｐｅ（タイプ＃１）の最後のオブジェクトとしてフラグを付けられる。これは、オブジェクト＃１および＃２を依然として共有するヘッド（すなわち最後のオブジェクト）としてオブジェクト＃６をもつオブジェクトのツリーを作成し、サブコレクションはベースコレクションに対応する。ステップ３において、フォーク＃３を参照すると、フォーク＃３は、（ＦＩＤ＃７を割り当てられた）フォーククローズオブジェクト＃７の作成によって閉じられ、ブロブ＃５に書き込まれる。ブロブ＃５は、フォーク＃３の下に書き込まれ、フォークおよびそれのオブジェクトの最新の状態を反映する。現在、フォーク＃３が閉じられたものとしてマークされるので、いかなる他のコアオブジェクトをもこの物理的フォークに書き込むことができず、それにより、フォークがその後更新されないことを保証する。

【0095】

[00111]図７ｃの例では、物理的フォーク（フォーク＃３）が作成されて以来ベースコレクションが更新されなかったと仮定すれば、物理的フォーク中で行われた変更を、単純な合成を用いてメインコレクション中に再統合することができる。図示の実施形態では、これは、ステップ４および５において、物理的フォーク（フォーク＃３）に関連するブロブをメインコレクションバックエンド中にコピーすることによって達成される。代替の実施形態（図示せず）では、メインコレクションへの、物理的フォークにおいて行われた変更の再統合を、メインコレクションの一部であるものとして物理的フォーク（フォーク＃３）のバックエンドを再構成することによって達成することもできる。そのような再構成は、ブロブ移動なしに、物理的フォーク（フォーク＃３）に関連するブロブをメインコレクションバックエンド中に再コピーすることと同じことを達成するであろう。

【0096】

[00112]最終的に、ステップ６において、メインコレクション中で、（ＦＩＤ＃８を割り当てられた）フォーク合成コアオブジェクトが作成され、ブロブ＃８に書き込まれる。ベースコレクション中のフォーク合成コアオブジェクトの作成は、ＦＩＤ＃０（メインコレクションのＦＩＤ）を用いて将来のブロブが書き込まれることになることを保証する。

【0097】

[00113]図７ｄを参照すると、物理的フォークが開かれ、ベースコレクションと同時に更新され、その後ベースコレクションとマージされる、一実施形態による、コレクションをフォークすることの一例が示される。ここでも、図７ｄの例では、ブロブ６０ごとにコレクション８０およびサブコレクションの展開が続く。図７ｄの例では、コレクションのコアオブジェクトのための２つのオブジェクトタイプ、すなわち、通常コアオブジェクトのためのＯｔｙｐｅ＃１と、物理的フォークコアオブジェクトを表すＯｔｙｐｅ＃－６とがある。

【0098】

[00114]ステップ１において、（ＯＩＤ＃１および＃２を割り当てられた）２つのコアオブジェクト５０が作成され、ブロブ＃１に書き込まれる。オブジェクト＃２は、オブジェクト＃１にリンクし、Ｏｔｙｐｅ＃１の最後のオブジェクトとしてフラグを付けられる。オブジェクト＃１および＃２をもつオブジェクトツリーは、Ｏｔｙｐｅ＃１の最後のオブジェクトとしてのオブジェクト＃２を伴って、ブロブ＃１に記憶されたコレクションの状態に反映される。さらに、（ＦＩＤ＃３を割り当てられた）物理的フォークコアオブジェクトが作成される。各Ｏｔｙｐｅについての最後のオブジェクト（Ｏｔｙｐｅ＃１についてのＯＩＤ＃２、およびＯｔｙｐｅ＃－６についてのＯＩＤ＃３）は、ブロブ＃３中のコレクション状態に記録される。ブロブ＃１がこの時点でベースコレクションに属することを仮定すれば、それはＦＩＤ＃０を用いて書き込まれる。

【0099】

[00115]ここでも、新しい物理的フォーク（フォーク＃３）のすべてのブロブ６０を保存するために、新しいバックエンドが割り当てられる。上述のように、新しい物理的フォークに関連するブロブを保存するために、任意のバックエンドタイプおよび／または構成を使用することができることを理解されよう。

【0100】

[00116]ステップ２において、（ＯＩＤ＃４を割り当てられた）コアオブジェクトが作成され、ブロブ＃４に書き込まれる。オブジェクト＃４は、ＦＩＤ＃３をもつコレクションに追加され、物理的フォーク（フォーク＃３）は、現在、ヘッドとしてのＯＩＤ＃４が物理的フォークに記憶され、ベースコレクションに記憶されたＯＩＤ＃１にチェーン結合された、オブジェクトのチェーンを表す。ブロブ＃３に記憶されたコレクション状態は、ブロブ＃３がフォーク＃３（ＦＩＤ＃３）のサブコレクションに属し、オブジェクトのツリーがオブジェクト＃４から開始することを反映する。この時点で、コレクション８０は、２つのサブコレクション（元のコレクションのサブコレクション、およびフォーク＃３のサブコレクション）を含む。フォーク＃３のサブコレクションは、オブジェクト＃１にリンクされたオブジェクト＃４を含むオブジェクトツリーを有する）。物理的フォーク（フォーク＃３）が、ヘッドとしてＯＩＤ＃２をもつオブジェクトツリーを依然として含むベースコレクションに影響を及ぼさないことを理解されよう。

【0101】

[00117]ステップ３において、（ＯＩＤ＃４および＃５を割り当てられた）２つのコアオブジェクトがベースコレクション中で作成され、ベースコレクションのブロブ＃４に書き込まれる。新たに作成されたコアオブジェクトおよびブロブは、物理的フォークおよびベースコレクションが現在、完全に分岐した（すなわち、異なるコレクションと同様に動作する）ことを仮定すれば、物理的フォーク（フォーク＃３）中のものとは異なることを理解されよう。ベースコレクションは、現在、ＯＩＤ＃５をもつコアオブジェクトのツリーを有し、ＯＩＤ＃４は、物理的フォーク（フォーク＃３）中でオブジェクトＯＩＤ＃４を有するコアオブジェクトとは異なる。２つのフォーク（すなわち、物理的フォーク、およびベースコレクションのフォーク）は異なるＦＩＤを有し、異なるバックエンドを使用し、したがって、互いから分離されるが、コレクションがフォークされる前に存在した共通コアオブジェクト＃１を依然として共有する。

【0102】

[00118]ステップ４において、（ＯＩＤ＃５および＃６を割り当てられた）２つのコアオブジェクトが物理的フォーク中で作成され、物理的フォーク（すなわち、ＦＩＤ＃３をもつ）のブロブ＃５に記憶される。ここでも、物理的フォーク＃３のオブジェクト＃５がベースコレクションのオブジェクト＃５とは異なることが理解されなければならない。フォーク＃３のオブジェクト＃６は、オブジェクト＃４および＃５にリンクされ、それのＯｔｙｐｅ（タイプ＃１）の最後のオブジェクトとしてフラグを付けられる。ステップ４において、フォーク＃３を参照すると、フォーク＃３は、（ＦＩＤ＃７を割り当てられた）フォーククローズオブジェクトの書込みによって閉じられ、ブロブ＃５に書き込まれる。ブロブ＃５は、フォーク＃３の下に書き込まれ、フォークおよびそれのオブジェクトの最新の状態を反映する。ブロブ＃５中のコレクション状態は、オブジェクトＯＩＤ＃６（Ｏｔｙｐｅ＃１）と、フォーククローズオブジェクト＃７（Ｏｔｙｐｅ＃－６）とをそれらのＯｔｙｐｅの最後のオブジェクトとして反映する。現在、フォーク＃３が閉じられたものとしてマークされるので、いかなる他のコアオブジェクトをもこの物理的フォークに書き込まれず、それにより、フォークがその後更新されないことを保証する。

【0103】

[00119]ベースコレクションと物理的フォーク（フォーク＃３）とが同時に更新され、フォークは単純に合成することができないので、物理的フォーク中で行われた変更をベースコレクション中に再統合するために、フォークはマージされる必要がある。ステップ５において、ベースコレクションと物理的フォーク（フォーク＃３）とは、ヘルパー（図示せず）を使用してマージされる。ヘルパーは、新たに作成されたコアオブジェクト中のベースコレクション中の物理的フォーク（フォーク＃３）のコアオブジェクト（すなわちコアオブジェクト＃４、＃５および＃６）のペイロードを再構成する。図示の実施形態では、フォーク＃３のコアオブジェクト＃４は、ベースコレクションのコアオブジェクト＃６の下に再作成され、フォーク＃３のコアオブジェクト＃５は、ベースコレクションのコアオブジェクト＃７の下に再作成され、フォーク＃３のコアオブジェクト＃６は、ベースコレクションのコアオブジェクト＃８の下に再作成され、各新たに作成されたコアオブジェクトは、ベースコレクションの対応する既存のオブジェクトにリンクされるか、または必要に応じて置換／削除される。マージの後に、オブジェクト＃１は２つの親（オブジェクト＃２およびオブジェクト＃６）を有する。これは有効な構成体であり、オブジェクトがそれの子であってもよいリンクの数に対する理論的な限界がない。（ＦＩＤ＃９を割り当てられた）物理的フォークマージは、物理的フォーク＃３がベースコレクション中にマージされ、もはや使用されていないという事実を記録するためにベースコレクションに書き込まれる。すべてのマージされたコアオブジェクトを含むブロブは、それらのブロブが現在ベースコレクションに属するように、ＦＩＤ＃０の下に書き込まれる。

【0104】

[00120]マージが複雑であり、多くのブロブを伴う一実施形態（図示せず）では、論理的フォークは、最初にメインコレクション中で作成し、メインコレクションに合成する前にマージプロセスを記録するために使用することができる。論理的フォークの使用は、すべての更新が統合されるまで、マージ操作がオブジェクトのメインコレクションのビューに影響を及ぼすのを防ぐのを助ける。

【0105】

[00121]上記に鑑みて、不変性と、それが含んでいるコアオブジェクト５０のＯＩＤ５２ａの導関数であるＢＩＤ６１ａをもつコアオブジェクト５０の一意のＯＩＤ５２ａとの組合せは、ブロブ６０が、中央制御、追跡、インデックスまたはマップを必要としない、高度に安定した、自律型で自由なモバイルデータコンテナであることを可能にする。

【0106】

[00122]コアオブジェクト５０がそれら自体不変であり、ＯＩＤ５２ａが永続的に一意であるので、拡大すると、ブロブ６０は本質的に不変である。したがって、ブロブ６０中のコアオブジェクト５０が、コンテンツまたはＯＩＤ５２ａのいずれによっても変化することができないことを仮定すれば、別のロケーションにコピーまたは複製されたブロブ６０のどの「バージョン」が、所与のコアオブジェクト５０の最新バージョンを含んでいるかを定義または記憶する必要がなく、所与のＢＩＤ６１ａをもつすべてのブロブ６０は、等価である。

【0107】

[00123]ＢＩＤ６１ａがブロブ６０のコアオブジェクト５０のＯＩＤ５２ａから導出されるので、求められるコアオブジェクト５０のＯＩＤ５２ａのみを使用して、どのブロブ６０が所与のコアオブジェクト５０を含んでいるかを決定し、それにより、どのブロブ６０がどのコアオブジェクト５０を含んでいるかに関するインデックスまたはマップを維持しなければならないという負担を削除することができる。

【0108】

[00124]ＢＩＤ６１ａは、ブロブ６０の識別情報だけでなく、拡大すると、ブロブ６０内のすべてのオブジェクト５０の識別情報、状態およびコンテンツをも伝達するので、これは、バックエンド７０をもつブロブ６０のコンテンツに関する情報を共有する必要を防ぎ、制御情報または他のメタデータを含むブロブ全体が、暗号化され、完全に隠されることを可能にする。ブロブ６０が、データの、完全に密閉され、暗号化されたコンテナであるので、ブロブ６０のコンテンツまたは性質に関して何も知る必要がなく、任意の機構またはエージェントによってそれらをセキュアにコピーすることができる。したがって、バックエンド７０は、バックエンド７０のインフラストラクチャが異なる場合でも、ブロブ６０のコンテンツを理解または確認すること（あるいはそれらが含んでいるものを理解するために中央の権限者（ｃｅｎｔｒａｌ ａｕｔｈｏｒｉｔｙ）に確認すること）なしに、ブロブを、あるバックエンドから別のバックエンドに自由に移動およびコピーすることができる。交換される必要がある唯一の物は、ブロブ６０のＢＩＤ６１ａおよびコンテンツである。

【0109】

[00125]最終的に、求められるコアオブジェクト５０のＯＩＤ５２ａからＢＩＤ６１ａが導出され、ストレージバックエンド７０によって保持されるＢＩＤ６１ａのショートリストを使用してＢＩＤ６１ａの位置を特定することができるので、コアオブジェクト５０の正確なロケーションは、ＢＩＤ導出を通してリアルタイムで自動的に開示される。ブロブ６０の追跡またはインデックス付けは、必要とされない。これは、中央ユニットへの通知なしに、バックエンド７０間のブロブ６０の自由な移動または点在を可能にする。ストレージバックエンド７０は、それらがどのブロブ６０を含んでいるかを知ることが必要とされる唯一の構成要素である。所与のＢＩＤ６１ａをもつブロブ６０がどこかで利用可能である限り、データは容易に利用可能である。その上、データの利用可能性および完全性を高めるために、ブロブ６０を、中央調整なしに、任意のストレージ媒体またはサービスに自由に複製することができる。ブロブのコピーがどこに位置しても、それを使用することができる。

【0110】

[00126]上記に鑑みて、説明される構造はまた、更新のためにさえ、中央サーバなどの中央調整ユニットの使用を必要とすることなしに、コレクション８０がピアツーピアモードでユーザ間で共有されることを可能にする。コレクション共有は、衝突完全性原理の適用によって、ブロブ６０の構造とログ構成されたコアオブジェクト５０とに鑑みて可能である。たとえば、コレクションのピアツーピア共有が２つまたはそれ以上のユーザ間で実行される一実施形態では、２つまたはそれ以上のユーザがオブジェクトを追加し、同じブロブ６０に同時に書き込むことを試みる場合、衝突が検出され、ユーザのうちの１つのみがブロブ６０を書き込むことに成功し、他は、衝突の結果として失敗することになる。ブロブ６０の書込みのそのような失敗は、コレクション８０が更新されたことを暗示する。したがって、ブロブの書込みが失敗したユーザの各々は、コレクションの新しい状態でコレクションのそれのビューをリフレッシュし、新しいブロブ６０の下にオブジェクトを再構成する必要がある。その後、それは、次いで（新しいＢＩＤ６１ａの下に書き込まれた）新しいブロブ中で更新を再サブミットすることができる。もちろん、衝突が再び検出された場合、プロセスは、それが当のユーザについて成功するまで繰り返される。代替の実施形態では、衝突の発生を制限または緩和するために、衝突完全性原理に関して、またはそれとは別に、追加の機構を使用することができる。たとえば、限定的ではないが、各ユーザが衝突の危険および頻度を低減するために、論理的フォークを使用することができる。衝突検出が機能するために、場合によっては衝突するブロブは、すべてのユーザによって共有される同じバックエンドに記憶されなければならないことを当業者は認識されよう。しかしながら、物理的フォークに関連するブロブ、または衝突することができない、論理的フォーク中の予約されるＯＩＤ範囲を、すべてのユーザによって必ずしも使用または共有されるとは限らない任意のバックエンドに記憶してもよい。また、一実施形態では、完全性を共有することを保証するために、衝突検出の代わりにロックサーバを使用することができることを、当業者は認識されよう。別の代替の実施形態では、共有される共通バックエンド７０を使用することも、衝突検出に依拠することもなしに、ピアツーピア共有を行うこともできる。これは、コレクションが、各ユーザがブロブ６０のプライベートコピーをもつそれ自体の物理的バックエンド７０を有し、したがって、コレクション８０のそれら自体のコピーを別々に読み取り、更新することができるように単に構成された、デタッチされたバックエンド共有として知られている。クライアントが再接続するとき、それらのデタッチされたコレクションを、それらがデタッチされていた間に実行された変更を再統合するために、それらが物理的フォークであったかのように、合成／マージすることができる。

【0111】

[00127]データストレージを実行するための方法１０が上記で説明されており、次に、上記で説明された分散されたデータストレージを実行するためのシステム１００について説明する。

【0112】

[00128]図８および図９に関して、一実施形態では、システム１００は、（ファイルシステムエンジンモジュール１３２、データベースエンジンモジュール１３４、インデックスエンジンモジュール１３０など）エンジンモジュール１０４など、データソースとデータ通信しているコアエンジンモジュール１１０、および／またはデータストレージを要求するアプリケーション１０６を含む。大まかに言えば、コアエンジンモジュール１１０は、分散されたデータストレージを実行するために、すべての他のサービスが依拠する基本サービスを与えるエンジンである。言い換えれば、コアエンジンモジュール１１０は、システム１００の主要なモジュールであり、それは、オブジェクト、ブロブ、コレクションおよびバックエンドの作成、更新、コレクションからの削除を管理すること、ブロブ圧縮／圧縮解除（必要な場合）を実行すること、ブロブ暗号化／解読（必要な場合）を実行すること、コレクション管理を実行することなどを行う。

【0113】

[00129]コアエンジンモジュール１１０、エンジンモジュール１０４、および／またはアプリケーション１０６、ならびに／あるいはそれの副構成要素は、ローカルコンピューティングシステムの一部（すなわち、各構成要素／副構成要素が、それ自体のメモリおよびプロセッサを有する同じコンピューティングユニット上にインストールされる）であってよい。ただし、一実施形態では、コアエンジンモジュール１１０、エンジン１０４、および／またはアプリケーション１０６、ならびに／あるいはそれの副構成要素を、たとえば、ネットワークを介して互いとデータ通信している別個のコンピューティングユニット上に分散させることができることを当業者は理解されよう。

【0114】

[00130]一実施形態では、コアエンジンモジュール１１０は、それを通して追加のエンジンモジュール１０４およびアプリケーション１０６がストレージサービスを要求することができる、コアアプリケーションプログラミングインターフェース（ＡＰＩ）モジュール１１２を含む。アプリケーション１０６は、データを記憶するためにシステム１００を使用する外部プログラムである。一実施形態では、アプリケーション１０６は、それらのデータを個別オブジェクトとして構造化するためにコアエンジンＡＰＩモジュール１１２を使用する。代替の実施形態（図９を参照）では、アプリケーション１０６はまた、テーブルレコードとしてそれのデータを記憶するために、以下でより詳細に説明されるデータベースエンジンモジュール１３４を使用するか、あるいはファイルとともに動作するために、直接または間接的に、同じく以下でより詳細に説明されるファイルシステムエンジンモジュール１３２を使用することができる。一実施形態では、コアＡＰＩモジュール１１２は、コレクションを開き、コアオブジェクトなどを読み取り、書き込み、削除するように動作可能である。

【0115】

[00131]一実施形態では、コアエンジンモジュール１１０はまた、コアＡＰＩモジュール１１２と通信しているコレクションマネージャモジュール１１４を含む。コレクションマネージャモジュール１１４は、すべての高レベル要求を扱い、コアオブジェクトを管理する。たとえば、コレクションマネージャモジュール１１４は、作成されたオブジェクトに準拠ＯＩＤを割り当て、一実施形態では、上記で説明されたように、オブジェクトに適切なオブジェクト識別情報（エイリアス、ＶＩＤなど）を割り当てる。コレクションマネージャモジュール１１４はまた、対応する方法に関して上記で説明されたように、使われていないオブジェクト、すなわち、参照されず、定義されたパージパラメータに従ってパージ可能であるオブジェクトを識別し、パージするように動作可能なガベージコレクタを含む。

【0116】

[00132]コレクションマネージャモジュール１１４は、ブロブを生成し、管理するためのブロブマネージャモジュール１１６と通信する。ブロブマネージャモジュール１１６はブロブを生成し（すなわち、オブジェクトをブロブ中にアセンブルし）、ＢＩＤを割り当て、ブロブの位置を特定し、複数のバックエンドへのアクセスを協調させ、バックエンドとの非同期入力／出力（ｌ／Ｏ）を実装する。

【0117】

[00133]コレクションマネージャモジュール１１４およびブロブマネージャモジュール１１６は、オブジェクトおよびブロブの上記で説明された中心的特徴、すなわち、オブジェクト不変性と、永続的に一意のオブジェクトＩＤ（ＯＩＤ）と、導出されたブロブＩＤ（ＢＩＤ）と、予測可能なＢＩＤとを実装し、それらは、容量がその後、インデックス、中央制御、追跡または同期を使用せずにデータをあるバックエンド１７０（または記憶ロケーション）から別のものに自由に記憶し、移動し、コピーし、点在させることと、ロックまたは中央調整サーバを使用しない更新を用いてピアツーピアモードでそのデータを共有することとを可能にする。

【0118】

[00134]ブロブマネージャモジュール１１６は、ブロブのコンテンツを圧縮および圧縮解除するために、独立した圧縮機モジュール１１８と通信する。一実施形態では、圧縮機モジュール１１８は、複数の圧縮アルゴリズムを実装することができ（それは、異なるブロブのために異なる圧縮アルゴリズムを使用することができ）、ブロブがそれの圧縮解除のために読み取られるとき、後続の圧縮解除のために使用される圧縮アルゴリズムを識別するために、圧縮タグとともに各ブロブをカプセル化する。ブロブに圧縮が適用されない一実施形態では、コアエンジンモジュール１１０には圧縮機モジュール１１８がなくてもよいことを当業者は理解されよう。

【0119】

[00135]コアエンジンモジュール１１０はまた、圧縮機モジュール１１８と通信する暗号化器モジュール１２０を含む。圧縮機モジュール１１８と同様に、暗号化器モジュール１２０は複数の暗号化アルゴリズムを実装することができ、したがって、異なるブロブに異なる暗号化を適用し、それにより、システム１００全体のセキュリティを向上させることができる。暗号化器モジュール１２０はまた、バックエンドから読み取られるとき、各特定のブロブをどのように解読することができるかを示す暗号化タグとともにブロブをカプセル化することができる。ここでも、ブロブに暗号化が適用されない一実施形態では、コアエンジンモジュール１１０には暗号化器モジュール１２０がなくてもよいことを当業者は理解されよう。

【0120】

[00136]図示の実施形態では、暗号化器モジュール１２０は、バックエンド１７０とデータ通信している。上述のように、複数のバックエンドを各コレクションに関連付けることができ、記憶されたデータの分散されたデータストレージを実行するために、ブロブがそれのストレージのための複数のバックエンドにわたって自律的に分散および／または点在させることができる。コアエンジンモジュール１１０に暗号化器モジュール１２０および／または圧縮機モジュール１１８がない一実施形態では、バックエンド１７０は、ブロブマネージャモジュール１１６と直接データ通信していてもよい。

【0121】

[00137]図示の実施形態では、圧縮機モジュール１１８、暗号化器モジュール１２０およびバックエンド１７０はストリームハンドラとして動作し、ブロブを読み取り、書き込むために、それら自体との間でデータを自由に受け渡す。容易に理解されるように、ストリームの最後に、バックエンド１７０は、ブロブがクラウド中のおよび／またはローカル物理ストレージデバイス上の実際に物理的に記憶されるところである。

【0122】

[00138]まだ図８および図９を参照すると、一実施形態では、システム１００は、以下でより詳細に説明される、インデックスエンジンモジュール１３０、ファイルシステムエンジンモジュール１３２、およびデータベースエンジンモジュール１３４などの追加のエンジンモジュールを含む。インデックスエンジンモジュール１３０、ファイルシステムエンジンモジュール１３２およびデータベースエンジンモジュール１３４は、ユーザ、オペレーティングシステムおよびアプリケーションにファイルおよびデータベースサービスを与えるように動作可能である。

【0123】

[00139]インデックスエンジンモジュール１３０は、コレクションに記憶されたデータを、容易に編成し、そのデータの位置を特定することができるように、ファイルシステムエンジンモジュール１３２およびデータベースエンジンモジュール１３４などの他のエンジンモジュールに、およびアプリケーション１０６にインデックス付けサービスを与える。言い換えれば、インデックスエンジンモジュール１３０は、値が鍵によって効率的に記憶され、取り出されることを可能にするために鍵／値ペアを記憶する。たとえば、限定的ではないが、一実施形態では、インデックスエンジンモジュール１３０の場合、インデックス（すなわち、バイナリ鍵／値ペアからなる単純な汎用辞書）を、ＯＩＤによって互いにリンクされ、ヘッドオブジェクトが所与のインデックスについてのすべてのオブジェクトのツリーを保持する、通常コアエンジンオブジェクトとして保存することができる。一実施形態では、インデックスは、ログ構成されたＢ＋ツリーとして内部に記憶されるが、代替の実施形態では、高速探索、シーケンシャルアクセス、挿入および削除を可能にする他のデータ構造を、インデックスを記憶するために使用することもできることを当業者は理解されよう。たとえば、限定的ではないが、一実施形態では、インデックスエンジンモジュール１３０は、それのオブジェクトのためのオブジェクトエイリアスおよび仮想ＩＤを管理するために、特に、コアエンジンモジュール１１０によって使用される。インデックスエンジンモジュール１３０は、任意の形式の鍵／値ペアを含んでいることができるプライベートインデックスを維持するために使用することもできる。たとえば、限定的ではないが、一実施形態では、プライベートインデックスは、鍵／値ペアを効率的に管理するために、たとえば、動的辞書、名前付き項目のリストなどを保持するために、（以下でより詳細に説明される、ファイルシステムエンジンモジュール１３２およびデータベースエンジンモジュール１３４などの）エンジンモジュールによって使用することができる。

【0124】

[00140]ファイルシステムエンジンモジュール１３２は、オブジェクトおよびブロブの上記で説明された構造を使用してファイルストレージを実装する。一実施形態では、ファイルシステムエンジンモジュール１３２は、コアエンジンモジュール１１０とデータ通信しており、ＡＰＩを含み、ＡＰＩを通して、ファイル、ディレクトリ、メタデータおよび関連する構造を記憶し、取り出すために、アプリケーション、ユーザコンピューティングデバイスなどによって、ｒｅａｄｄｉｒ、ｏｐｅｎ、ｒｅａｄ／ｗｒｉｔｅおよびｃｌｏｓｅなど、よく知られているファイルシステムプリミティブを使用することができる。たとえば、限定的ではないが、一実施形態では、ファイルがローカルファイルであるかのように、ユーザによるファイルのストレージを可能にするために、ファイルシステムエンジンモジュール１３２をオペレーティングシステムインターフェース（たとえば、ＦＵＳＥ）に直接接続することができる。したがって、ファイルシステムエンジンモジュール１３２は、ユーザが、コアエンジンモジュール１１０を使用して、クラウドストレージプロバイダ、または中央調整のない他の媒体など、複数のバックエンド上にそれらのファイルを記憶し、セキュアに点在させることを可能にする。上記のことに鑑みて、コアエンジンモジュール１１０のバックエンド１７０が物理的ディスクまたは他のローカルストレージ媒体である実施形態では、システム１００を、ユーザのコンピューティングデバイスのための真のエンドツーエンドファイルシステムとして直接使用することができ、分散されたストレージのすべての特徴および利点がシステム１００によって与えられることを当業者は理解されよう。

【0125】

[00141]データベースエンジンモジュール１３４は、公開されたインターフェース（たとえば、ＳＱＬ、ＣＬＩ、ＯＤＢＣなど）を通してアプリケーションにデータベースサービスを与え、対応する構造（たとえば、スキーマ、フィールド、インデックス、レコードなど）をコアオブジェクトおよびインデックスエンジンプライベートインデックスとして記憶する。したがって、データベースエンジンモジュール１３４は、データベースのためのデータストレージを実行するために、インデックスエンジンモジュール１３０およびコアエンジンモジュール１１０と共同する。本システム１００のインデックスエンジンモジュール１３０およびコアエンジンモジュール１１０の使用は、データベースが、上記で説明されたシステム１００のすべての利益をもつ、複数のクラウドストレージプロバイダ、共有ストレージシステムおよびローカルメディアなど、異なるバックエンド１７０上に完全に分散および点在されることを可能にする。

【0126】

[00142]データの分散された記憶のための上記で説明された方法およびシステムは、インデックス、中央制御、追跡または同期を使用せずに、あるストレージロケーション（クラウドストレージプロバイダ、ネットワークディスク、ローカルメディアなど）から別のストレージロケーションにデータを自由に記憶し、移動し、コピーし、点在させることと、ロックまたは中央調整サーバを使用しない更新を用いてピアツーピアモードでそのデータを共有することとを可能にする。そのような特性は、データがローカルディスクとクラウドストレージとに同時に記憶され、リアルタイムで更新され、中央システムへの通知なしにある媒体から別の媒体に移動またはコピーされ、コアエンジンに自動的に、高い完全性で任意の時間に、必要とされる情報の位置を特定し、その情報を取り出させることを可能にする。

【0127】

[00143]いくつかの代替の実施形態および例について、本明細書で説明および図示した。上記で説明された本発明の実施形態は、例にすぎないものとする。当業者は、個々の実施形態の特徴、ならびに構成要素の可能な組合せおよび変形形態を諒解されよう。当業者は、実施形態のいずれかを、本明細書で開示された他の実施形態との任意の組合せで与えることができることをさらに諒解されよう。本発明は、それの中心的特性から逸脱することなく他の特定の形態で実施されてもよいことを理解されたい。したがって、本例および実施形態は、あらゆる点で、限定的ではなく例示的と見なされるべきであり、本発明は、本明細書で与えられる詳細に限定されるべきではない。したがって、特定の実施形態が例示され、説明されたが、添付の特許請求の範囲において規定される本発明の範囲から著しく逸脱することなく、多数の変更が思い浮かぶ。

【図1】

【図1a】

【図1b】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7a】

【図7b】

【図7c】

【図7d】

【図8】

【図9】