(57)【要約】【課題】自立的な構成要素として機能し、中央のストレージ制御装置を要せずに分散ストレージシステムを形成することができ、よりインテリジェントなストレージデバイスを使用可能にする、ネットワーク内のノードを自動的に分類する方法および装置を提供する。【解決手段】少なくとも１つのデータクラスを検出し、データクラスに従いノードに格納されているデータを自動的に分類し、データクラスに従い分類されたデータの量を検出し、ここでファイルの数およびこのファイルの平均サイズを検出し、データクラスに分類されているデータの検出された量から優先値を計算し、この優先値はデータクラスに従いノードに格納されているデータの相対的な優先度に対する尺度であり、データクラスに従いデータタイプを表すリクエストを受信し、データクラスに従いデータの相対的な優先度に対する尺度である優先値をリクエストに応じて提供する。【選択図】図６
2007164794.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク内のノードを自動的に分類する方法において、
−少なくとも１つのデータクラス（ビデオ、オーディオ、テキスト）を検出するステップを有し、
−前記データクラスに従いノードに格納されているデータを自動的に分類するステップを有し、
−前記データクラスに従い分類されたデータの量を検出するステップを有し、ここでファイルの数および該ファイルの平均サイズを検出し、
−前記データクラスに分類されているデータの検出された量から優先値（Ｅdominant）を計算するステップを有し、該優先値（Ｅdominant）は前記データクラスに従いノードに格納されているデータの相対的な優先度に対する尺度であり、
−前記データクラスに従いデータタイプを表すリクエストを受信するステップを有し、
−前記データクラスに従いデータの相対的な優先度に対する尺度である前記優先値（Ｅdominant）を前記リクエストに応じて提供するステップを有することを特徴とする、ネットワーク内のノードを自動的に分類する方法。
【請求項２】
ファイルサイズとファイルの数の組み合わせに関してデータの量を検出する、請求項１記載の方法。
【請求項３】
ストレージデバイスの残りの潜在的な記憶容量を自動的に推定し、さらに、
−前記ストレージデバイスに既に格納されているデータのデータタイプを検出するステップを有し、
−前記データタイプの既に格納されているデータのファイルサイズ統計を検出するステップを有し、
−前記ストレージデバイスにおける残りの空き記憶容量を検出するステップを有し、
−前記データタイプのデータを格納するためのリクエストを受信するステップを有し、該リクエストはファイルサイズを表さず、
−検出された前記ファイルサイズ統計に従い、前記データタイプのデータの予測されるサイズを検出するステップを有し、
−前記ストレージデバイスの前記残りの空き記憶容量が、前記データタイプのデータの予測されるサイズよりも大きい場合には、前記データの記憶を受諾するステップを有する、請求項１または２記載の方法。
【請求項４】
データタイプに関連するノードの前記優先値（Ｅdominant）を次式により計算し、
Ｅdominant,type＝ＲＰＳＣ * Ａtotal * ｋ1
ここで、
Ａtotal＝Ｎtotal * Ｓtotal
ＲＰＳＣ＝ｋ2−ｋ3（ｋ4＋Ｓaverage＋Ｃused）／Ｃtotal
ここで、ｋ1，ｋ2，ｋ3，ｋ4は定数であり、Ｎtotalは前記データタイプのデータファイルの総数であり、Ｓtotalは前記データタイプのファイルの累算されたサイズであり、Ｓaverageは前記データタイプのファイルの平均サイズであり、Ｃusedは前記ノードの占有されている記憶容量であり、Ｃtotalは前記ノードの総記憶容量である、請求項１から３までのいずれか１項記載の方法。
【請求項５】
データクラスの分類および／または検出をデータに関連するメタデータに従い行う、請求項１から４までのいずれか１項記載の方法。
【請求項６】
前記ノードはピア・ツー・ピアネットワークにおけるピアである、請求項１から５までのいずれか１項記載の方法。
【請求項７】
ノードの選択はノードの相対的な空き記憶容量（ＲＦＳＣ）を基礎とし、該相対的な空き記憶容量を次式により計算し、
ＲＦＳＣ＝ｃ1−ｃ2（ｃ3＋Ｓin_data＋Ｃused）／Ｃtotal
ここでｃ1，ｃ2，ｃ3は定数であり、Ｓin_dataは格納すべきデータのサイズであり、Ｃusedは前記ノードの占有されている記憶容量であり、Ｃtotalは前記ノードの総記憶容量である、請求項１から６までのいずれか１項記載の方法。
【請求項８】
ネットワーク内のノードを自動的に分類する装置において、該装置は、
−少なくとも１つのデータクラス（ビデオ、オーディオ、テキスト）を検出する手段を有し、
−前記データクラスに従いノードに格納されているデータを自動的に分類する手段を有し、
−前記データクラスに従い分類されたデータの量を検出する手段を有し、ここでファイルの数および該ファイルの平均サイズが検出され、
−前記データクラスに分類されているデータの検出された量から優先値（Ｅdominant）を計算する手段を有し、該優先値（Ｅdominant）は前記データクラスに従いノードに格納されているデータの相対的な優先度に対する尺度であり、
−前記データクラスに従いデータタイプを表すリクエストを受信する手段を有し、
−前記データクラスに従いデータの相対的な優先度に対する尺度である前記優先値（Ｅdominant）を前記リクエストに応じて提供する手段を有することを特徴とする、ネットワーク内のノードを自動的に分類する装置。
【請求項９】
ファイルサイズとファイルの数の組み合わせに関してデータの量が検出される、請求項８記載の装置。
【請求項１０】
ストレージデバイスの残りの潜在的な記憶容量を自動的に推定し、さらに、
−前記ストレージデバイスに既に格納されているデータのデータタイプを検出する手段を有し、
−前記データタイプの既に格納されているデータのファイルサイズ統計を検出する手段を有し、
−前記ストレージデバイスにおける残りの空き記憶容量を検出する手段を有し、
−前記データタイプのデータを格納するためのリクエストを受信する手段を有し、該リクエストはファイルサイズを表さず、
−検出された前記ファイルサイズ統計に従い、前記データタイプのデータの予測されるサイズを検出する手段を有し、
−前記ストレージデバイスの前記残りの空き記憶容量が、前記データタイプのデータの予測されるサイズよりも大きい場合には、前記データの記憶を受諾する手段を有する、請求項８または９記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク内のノードを自動的に分類する方法および装置に関する。
【背景技術】
【０００２】
ストレージエリアネットワーク（ＳＡＮ）は、多数のサーバを集中型のディスクストレージプールに接続する、ストレージディスクのネットワークとして公知である。接続されている全てのストレージを単一のリソースとして処理することによって、システムの保守は容易になる。ＳＡＮは集中型か分散型が考えられる。集中型のＳＡＮは多数のサーバをディスクコレクションに接続し、これに対し分散型のＳＡＮは建物内のノードを接続するために典型的に１つまたは複数のスイッチを使用する。しかしながら両方のタイプとも集中型の制御構造、すなわちクライアントサーバ構造を使用する。
【０００３】
一般的な分散ストレージシステム（ＤＳＳ）においては、データが格納されるべきデバイスをアプリケーションが決定することができる。このようなデバイスを本明細書においては「要求されたストレージターゲット」と称する。ユーザは特定のストレージデバイスの選択を要求されることが多い。ＤＳＳ内の個々のストレージデバイスを自動的にする選択するインテリジェンスなやり方は存在しない。
【０００４】
ＤＳＳに依存せずに、改善されたデータの安全性、可用性、アクセス可能性のためにストレージデバイスを複製することができる。データをパーティションに区切り、そのパーティションを異なるストレージデバイスに記憶するコンセプトをＤＳＳの単一のノードにおいても適用することができる。
【０００５】
自立的な構成要素として機能し、中央のストレージ制御装置を要することなく分散ストレージシステムを形成することができる、よりインテリジェントなストレージデバイスを使用できるようにすることが所望される。
【０００６】
さらには、分散ストレージシステム全体が「モノリシックストレージブロック」のように振る舞うこと、すなわちアプリケーションおよびユーザには１つの（大きな）凝集したストレージファシリティとみなされるが、内部的には個々のデバイスを備えた構造を維持することが所望される。これは慣例のストレージクラスタとは異なるＤＳＳの直交的な振る舞いである。何故ならば、各ストレージデバイスはＤＳＳ内で別個のタスクを有する個々のデバイスのままであるが、外部からはＤＳＳをデータの格納の際に１つのユニットとしてアドレッシングすることができる、すなわち外部からでなくＤＳＳ内において個々のデバイスをアドレッシングする必要はないからである。その結果、ストレージデバイスを自由にＤＳＳに接続することができ、またＤＳＳから切断することができ、ストレージデバイスは有効データ、例えば映画のようなオーディオヴィジュアル（ＡＶ）データを持ち込むまたは受け取ることができる。有利には、ＤＳＳ内のデバイスはクライアントサーバ構造ではないが、例えばピア・ツー・ピア（Ｐ２Ｐ）ネットワークの場合のようにクライアントとサーバの両方の役割を果たすことができる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従って本発明の課題は、自立的な構成要素として機能し、中央のストレージ制御装置を要することなく分散ストレージシステムを形成することができ、よりインテリジェントなストレージデバイスを使用できるようにし、さらには、分散ストレージシステム全体が「モノリシックストレージブロック」のように振る舞うこと、すなわちアプリケーションおよびユーザには１つの（大きな）凝集したストレージファシリティとみなされるが、内部的には個々のデバイスを備えた構造を維持することができる、ネットワーク内のノードを自動的に分類する方法および装置を提供することである。
【課題を解決するための手段】
【０００８】
方法に関する課題は、この方法が、少なくとも１つのデータクラスを検出するステップを有し、データクラスに従いノードに格納されているデータを自動的に分類するステップを有し、データクラスに従い分類されたデータの量を検出するステップを有し、ここでファイルの数およびこのファイルの平均サイズを検出し、データクラスに分類されているデータの検出された量から優先値を計算するステップを有し、この優先値はデータクラスに従いノードに格納されているデータの相対的な優先度に対する尺度であり、データクラスに従いデータタイプを表すリクエストを受信するステップを有し、データクラスに従いデータの相対的な優先度に対する尺度である優先値をリクエストに応じて提供するステップを有することにより解決される。
【０００９】
装置に関する課題は、この装置が、少なくとも１つのデータクラスを検出する手段を有し、データクラスに従いノードに格納されているデータを自動的に分類する手段を有し、データクラスに従い分類されたデータの量を検出する手段を有し、ここでファイルの数およびこのファイルの平均サイズが検出され、データクラスに分類されているデータの検出された量から優先値を計算する手段を有し、この優先値はデータクラスに従いノードに格納されているデータの相対的な優先度に対する尺度であり、データクラスに従いデータタイプを表すリクエストを受信する手段を有し、データクラスに従いデータの相対的な優先度に対する尺度である優先値をリクエストに応じて提供する手段を有することにより解決される。
【発明を実施するための最良の形態】
【００１０】
本発明により構成されており、且つモノリシックストレージブロックのように振る舞うＤＳＳネットワークにおいては、ストレージデバイスに関連する優先的なデータタイプが求められる。この情報は特定のデータタイプのデータが格納されるべき場合にストレージデバイスを選択するために使用される。またこの情報は特定のデータタイプのデータがサーチされる場合にも使用することができる：このケースではそのような情報を特定のタイプのデータが大量に格納されているストレージデバイスにおいて優先的に／最初にサーチすることができる。
【００１１】
本発明はネットワーク内のノードを自動的に分類する方法を提供し、この方法は以下のステップを有する：
−少なくとも１つのデータクラス、例えばビデオ、オーディオまたはテキストを検出するステップ。
−前述のデータクラスに従いノードに格納されているデータを自動的に分類するステップ。
−前述のデータクラスに従い分類されたデータの量を検出するステップ。この際ファイルの数およびこのファイルの平均サイズが検出される。
−前述のデータクラスに分類されているデータの検出された量からデータタイプ優先値を計算するステップ。この優先値は前述のデータクラスに従いノードに格納されているデータの相対的な優先度に対する尺度である。
−前述のデータクラスに従いデータタイプを表すリクエストを受信するステップ。
−前述のデータクラスに従いデータの相対的な優先度に対する尺度である前述の優先値を前述のリクエストに応じて提供するステップ。
【００１２】
さらに本発明によれば、ネットワーク内のノードを自動的に編成する方法は以下のステップを有する：
−データを格納するためのリクエストを受信するステップ。ここでリクエストは所定のデータクラスに従いデータタイプを表す。
−複数のストレージノードにリクエストを伝送するステップ。
−ストレージノードからそれぞれの優先値を受信するステップ。この優先値は前述のデータクラスに従いそれぞれのノードに格納されているデータの相対的な優先度に対する尺度である。
−それぞれのノードの優先値を比較するステップ。
−データを格納するために最も高い優先値を有するノードを選択するステップ。
【００１３】
さらに本発明による方法を、ファイルサイズとファイルの数の組み合わせに関してデータの量が分類されることによりさらに特定することができる。
【００１４】
さらに本発明による方法を、データタイプに関連するノードの優先値が次式により計算されることによって特定することができる。
Ｅdominant,type＝ＲＰＳＣ * Ａtotal * ｋ1
ここで、
Ａtotal＝Ｎtotal * Ｓtotal
ＲＰＳＣ＝ｋ2−ｋ3（ｋ4＋Ｓaverage＋Ｃused）／Ｃtotal
ここで、ｋ1，ｋ2，ｋ3，ｋ4は定数であり、Ｎtotalは前述のデータタイプのデータファイルの総数であり、Ｓtotalはデータタイプのファイルの累算されたサイズであり、Ｓaverageはデータタイプのファイルの平均サイズであり、Ｃusedはノードの占有されている記憶容量であり、Ｃtotalはノードの総記憶容量である。
【００１５】
１つの実施形態においては、データクラスの分類および／または検出はデータに関連するメタデータに従い行われる。しかしながら別の実施形態においては、データクラスの分類および／または検出は他の指示、例えばファイル拡張またはファイルヘッダ分析に従い行われる。
【００１６】
１つの実施形態においては、ノードがピア・ツー・ピアネットワークにおけるピアである。
【００１７】
本発明の１つの実施形態においては、ノードの選択はノードの相対的な空き記憶容量（ＲＦＳＣ）を基礎としており、この相対的な空き記憶容量は次式により計算される。
ＲＦＳＣ＝ｃ1−ｃ2（ｃ3＋Ｓin_data＋Ｃused）／Ｃtotal
ここでｃ1，ｃ2，ｃ3は定数であり、Ｓin_dataは格納すべきデータのサイズであり、Ｃusedはノードの占有されている記憶容量であり、Ｃtotalはノードの総記憶容量である。
【００１８】
本発明によるネットワークプロトコルコマンドは優先値（Ｅdominant,type）の要求または提供に適しており、ここで要求または提供された優先値はデータタイプおよびネットワークノードに関し、またコマンドはデータタイプの指示を包含する。特定のノードの優先値は次式に従い計算される。
Ｅdominant,type＝ＲＰＳＣ * Ａtotal * ｋ1
ここで、
Ａtotal＝Ｎtotal * Ｓtotal
ＲＰＳＣ＝ｋ2−ｋ3（ｋ4＋Ｓaverage＋Ｃused）／Ｃtotal
ここで、ｋ1，ｋ2，ｋ3，ｋ4は定数であり、Ｎtotalはノードに格納された前述のデータタイプのデータファイルの総数であり、Ｓtotalはノードに格納されたデータタイプのファイルの累算されたサイズであり、Ｓaverageはノードに格納されたデータタイプのファイルの平均サイズであり、Ｃusedはノードの占有されている記憶容量であり、Ｃtotalはノードの総記憶容量である。単純なケースにおいて、定数はｋ1＝ｋ2＝ｋ3＝１且つｋ4＝０である。
【００１９】
ネットワーク内のノードを自動的に分類するための相応の装置は以下の手段を包含する：
−少なくとも１つのデータクラス（例えばビデオ、オーディオまたはテキスト）を検出する手段。
−前述のデータクラスに従いノードに格納されているデータを自動的に分類する手段。
−前述のデータクラスに従い分類されたデータの量を検出する手段。ここで、ファイルの数およびこのファイルの平均サイズが検出される。
−前述のデータクラスに分類されているデータの検出された量からデータタイプ優先値を計算する手段。この優先値は前述のデータクラスに従いノードに格納されているデータの相対的な優先度に対する尺度である。
−前述のデータクラスに従いデータタイプを表すリクエストを受信する手段。
−前述のデータクラスに従いデータの相対的な優先度に対する尺度である前述の優先値を前述のリクエストに応じて提供する手段。
【００２０】
さらに本発明によれば、ネットワーク内のノードを自動的に編成する装置は以下の手段を包含する：
−データを格納するためのリクエストを受信する手段。リクエストは所定のデータクラスに従いデータタイプを表す。
−複数のストレージノードにリクエストを伝送する手段。
−ストレージノードからそれぞれの優先値を受信する手段。この優先値は前述のデータクラスに従いそれぞれのノードに格納されているデータの相対的な優先度に対する尺度である。
−それぞれのノードの優先値を比較する手段。
−データを格納するために最も高い優先値を有するノードを選択する手段。
【００２１】
本発明の有利な実施形態は従属請求項、以下の説明ならびに図面に記載されている。
【実施例】
【００２２】
分散ストレージシステム（ＤＳＳ）が個々のストレージデバイスから構築される場合には、ＤＳＳの２つの異なる直交的な振る舞いを選択することができる。つまり、データが格納されるべきデバイスをアプリケーションが選択するか（要求されたストレージターゲット）、ＤＳＳ全体が１つの大きな凝集したストレージファシリティとみなされ、１つのユニットのように振る舞うかである。これを本明細書においては「モノリシックストレージブロック」と称する。
【００２３】
アプリケーションがデータを格納するために所定のストレージデバイスを選択することを意図している場合には、ＤＳＳ内のノードが先ず自身のノードの状態およびケイパビリティに関する情報をアプリケーションに提供し、それによりアプリケーションはデータを何処に格納するかを決定することができる。他方ユーザは何処にコンテントが記憶されるかには関心がないので、ユーザは便利な自動的な「記憶管理」に関心を持つ可能性がある。このケースにおいては、ＤＳＳがモノリシックストレージブロックのように振る舞えば有利である。
【００２４】
要求されたストレージターゲットのコンセプトにおいて、１つの明示的なノードがデータを格納するためのターゲットとして要求されると、ＤＳＳ内のノードは自身のリソースに関する適切な情報を供給する。この場合にはアプリケーションは適切なやり方で決定することができるが、他方ではＤＳＳ内のノードは適切なシステム状態およびケイパビリティデータを供給すべきである。
【００２５】
モノリシックブロックのコンセプトにおいて明示的なノードがデータを格納するためのターゲットとして要求されていない場合には、ＤＳＳは１つのユニットのようにアクセス可能である。アプリケーションはＤＳＳを記憶容量のモノリシックブロックとみなす。ＤＳＳ自体は自律的に、空き記憶容量および十分な伝送レートにマッチするストレージデバイスを探す。これはネットワーク上で実現されており、且つネットワーク内の各（記憶）ノードによって遵守されている規則のセットに基づき実現される。
【００２６】
アプリケーションはノードの中間制御層（ＩＣＬ）を介してＤＳＳにアクセスする。ＩＣＬはアプリケーションによって使用されるモードを収容し、また対応するアプリケーションインタフェースを提供する。ＩＣＬはそのインタラクションによってＤＳＳの論理シェルを形成する。図１はアプリケーションがどのようにＤＳＳを見るかを示す。モードは実際のところ制御メッセージシーケンスの明確なプロシージャである。以下では種々のモードを先ずは、選択されたノードに直接アクセスすることができる、いわゆる「要求されたストレージターゲット」に関して説明する。次に「ファイル分割」機能を説明する。このファイル分割機能は例えばレコーディング装置の容量が無い場合のレコーディングの実行を可能にする。
【００２７】
ノードおよびエッジの数が増すに連れネットワークの複雑性も急激に増すので、そのような着実に増していく複雑性を検討し続けることは非現実的であるか、それどころか不可能なタスクである。消費者に実際に付加される値を構成するために、ストレージネットワークは自身を編成すべきである。以下では、アプリケーションが単一の凝集されたストレージブロックとしてのストレージネットワークにアクセスすることができる「モノリシックストレージの振る舞い」の概略を述べる。「モノリシックストレージの振る舞い」は最も複雑なシステムモードであるが、ユーザに対しては最善の利便性を提供する。何故ならば、このモードにおいてはシステムが可能な限り自己管理的なやり方で動作するからである。このモードにおいてはアプリケーションがストレージネットワークを１つの凝集されたストレージブロックと「みなす」。２つの極端なケースを考慮することができる。つまり、システムは「無秩序な」システムとして振る舞うか、「良好にソートされた／自己ソート型の」システムとして振る舞う。前者の場合には、全てのコンテントが可能とされる場所であればどこでも格納されるが、後者の場合にはコンテントが以下例示的に定義するような規則に従いソートされて格納される。本発明は、単純性の原理に従い、これら両方の機能の態様を参照する。
【００２８】
「要求されたストレージターゲット」モードは直接的なアプローチであり、ここでは完備性についてのみ言及する。ユーザがＤＳＳに特定のストレージデバイスにデータを格納することを要求する場合には、所望のストレージデバイスに直接的にアドレッシングする手段を利用することができる。このモードが図２に示されており、ここではアプリケーション（またはユーザ）が特定のデバイスＡにデータを格納することを決定する。この非常に基本的なモードはユーザにストレージネットワークを管理することを要求し、したがって煩雑である。
【００２９】
以下では、モノリシックブロックアプリケーションを説明する。
【００３０】
ＤＳＳにおいてはストレージデバイスを管理するための集中サーバが存在しないと想定する。各ストレージデバイスはサーバに依存せずに機能する。デバイスは例えばピア・ツー・ピアネットワークの場合のようなメッセージ、通常はリクエストおよび応答を介して通信する。制御メッセージを交換することによって非集中ネットワークデバイスは相互に通信することができ、また自身を編成することができる。「モノリシックブロック」のコンセプトは論理的なグループを形成するストレージノードのグループを参照し、ここでＤＳＳの記憶容量は外部からは包括的なものとみなされ、また個々のノードは外部からは区別されない。その代わりに、ストレージは各ストレージデバイスが従う一定の規則に従い管理される。そのような規則は例示的に以下のように定義される。ストレージノードのグループが１つのユニット、すなわちモノリシックブロックのように振る舞うことによって、それらの規則をＤＳＳにおいてソフトウェアで（中間層として）実現することができる。
【００３１】
本発明はこのことをどのように実施することができるか、また記憶および検索を要求するアプリケーションとＤＳＳとの間の協働がどのように行われるかを表す。さらに本発明は、モノリシックブロックの外部から到来するストレージリクエストがどのように処理されるか、モノリシックブロックにおけるノードの内の１つから到来するストレージリクエストがどのように処理されるか、またどのメッセージおよび制御メタデータをこのコンセプトの実現のために使用することができるかを説明する。
【００３２】
本発明によれば、表１に示されている層を区別することができる。
【００３３】
【表１】
2007164794.tif 000003
【００３４】
ストレージリクエストはアプリケーション層（ＡＬ）から開始される。これらのストレージリクエストは制御メッセージを使用して制御言語層（ＣＬＬ）において実施される。モノリシックブロック層（ＭＢＬ）はこれらの層間のリンクを形成し、したがってノード間の通信を管理することによって、また制御メタデータを適切に使用することによってモノリシックブロックのコンセプトを実現する。インタフェースは適切に層間に存在すると想定する。例えばＡＬ−ＭＢＬインタフェースおよびＣＬＬ−ＰＰＬインタフェース。メッセージおよび制御メタデータはピア・ツー・ピア技術層（ＰＰＬ）に関連付けられている。
【００３５】
ＭＢＬは全ての関連するストレージデバイスを単一のストレージブロックとみなす仮想効果をユーザに提供する。事前定義されたデフォルトマッチングストラテジに基づき、ＭＢＬは到来するデータをストレージデバイスに自動的に割り当てるために保存する。
【００３６】
例えば、本発明の１つの実施形態においては、ネットワークに接続されている全てのストレージデバイスがモノリシックブロック（ＭＢ）を形成し、ストレージリクエストはネットワークにおけるノードの内の１つから到来する。ネットワークは例えば、欧州特許明細書EP1427149号に記載されているような、オーナーゾーン（OwnerZone）として実現されているホームネットワークでもよい。このケースにおいては、ネットワークまたはオーナーゾーンにおけるノードの内の１つにおいて実行されるアプリケーションがＭＢ上のコンテントの部分をレコードすることを要求する。すなわち要求を行うノード自体も含めて、オーナーゾーン内のどこかにコンテントの部分がレコードされ、この際アプリケーションはコンテントが何処に格納されるかを知らない。
【００３７】
外部からみるとホームネットワークでは、ホームネットワーク内のＤＳＳにコンテントの部分を記憶することが許可されているか否かという問題が生じる。この問題は例えば、携帯装置またはモバイル装置を介して遠隔地から家にアクセスする場合に解決する必要がある。遠隔装置またはノードを、少なくともホームネットワークにアクセスしている時間にわたり、許可されたものとして識別できる場合、例えばホームネットワークの一部として識別できる場合には、それらの遠隔装置またはノードはホームネットワーク内に存在し、またネットワークノード、したがってＤＳＳにアクセスすることができる。
【００３８】
以下では、ＭＢアプリケーションのストラテジの概略を述べる。
【００３９】
ＭＢアプリケーションに関する一般的なタスクはデータ記憶およびデータ検索である。すなわち到来するデータをモノリシックストレージブロックに保存し、モノリシックストレージブロックから保存されたデータを検索する。ＭＢアプリケーションのデータ記憶機能はデータ検索よりも高度なアルゴリズムを必要とする。
【００４０】
ＭＢシステムに到来するデータを保存している間に、理想的な場合にはデータを直接的に所定の宛先ストレージデバイス上に良好にソートして保存することができる。したがってこの保存を本明細書においては「ソートされた記憶」と称する。しかしながらユーザはむしろ「無秩序なストック管理」でデータを格納することを所望することもある。適切な時点において、またはユーザ取り決めに応じて、一時的な記憶データがより良い宛先デバイスへとさらにソートされる。
【００４１】
無秩序なストック管理および良好にソートされた記憶は例示的に事前定義された２つのモノリシックストレージストラテジである。両方のストラテジをシステム定義型のストレージデバイスマッチング判定基準によって実現することができる。
【００４２】
「無秩序な」ストック管理に関するデバイスのサーチは良好にソートされた記憶に関する場合よりも簡潔且つ迅速である。「無秩序な」ストック管理とはＭＢ内のデータがいずれかの判定基準、例えば論理的なマッチング判定基準によってソートされていないことを意味している。ストレージデバイスの幾つかの基本的で物理的な特性（例えば記憶容量、伝送レート）のみが考慮される。したがって、無秩序なストレージは何らかのやり方で決定されるが、良好にソートされるケースよりも構造化されていない。しかしながら術語「無秩序」はここでは単純性に対して使用される。無秩序なストック管理に関しては、ストレージデバイスがＭＢアプリケーションの物理的なマッチング判定基準を満たすことができる場合にはこのストレージデバイスを選択することができる。
【００４３】
良好にソートされた記憶に関するデバイスのサーチの場合、システムは例えばデータが付随するメタデータ（ＭＤ）を介して、格納されているデータを分析する。分析の結果に依存して、モノリシックな振る舞いを例えば「メタデータによりなされるソートされたストレージの振る舞い」に切り換えることができ、このことはＭＤ内で定義されているような異なるコンテントカテゴリが別個のデバイスに記憶されることを意味する。例えば全てのスポーツイベントはドライブＡに格納され、映画はドライブＢに格納される。続いて、システムはソートされたコンテントをその新たなシステム振る舞いに従い適切に再配置することができる。動作フェーズの間に、時々（例えばデータ記憶／検索統計に依存して）、システムはソートされたコンテントを分析し、実施されている振る舞いが良好にフィットしているか否かを判定する。
【００４４】
順応できていない振る舞い特性の場合には、システムがその動作モードを変更し、より適した動作モードを選択することができる。
【００４５】
良好にソートされた記憶とは、ＭＢ内のデータが物理的なマッチング判定基準および論理的なマッチング判定基準の両方によってソートされることを意味している。例えば、ストレージデバイスが所定のジャンルに関連付けられる、またはビデオデータをビデオにとって優先的なデバイス内に一緒に保存することができる、またはＭＰ３をオーディオ収集デバイスに保存することができる、など。
【００４６】
ストラテジをデフォルトによって、またはアプリケーションによって、またはユーザの代わりに、またはユーザによって選択することができる。ユーザが選択するケースは、（据え置き型の媒体か取り外し可能な媒体を装備している）所定の１つまたは複数のノードをユーザが関心のある所定の対象と関連付けることをユーザが所望する場合に生じる可能性がある。事前に割り当てられていないノードをデフォルトに従い、またはユーザの代わりにアプリケーションによって選択された他の規則に従い処理することができる。
【００４７】
２つのストラテジをシステム要求に従い相互に変換することができる。ＭＢシステムの無秩序なストック管理状態をメンテナンスプロセスによって良好にソートされた記憶状態に変換することができる。良好にソートされた記憶状態を、論理的なマッチングプロセスおよび特定の物理的なマッチングプロセスを放棄することによって無秩序なストック管理状態に変更することができる。
【００４８】
無秩序なストック管理および良好にソートされた記憶の両方に関して、デバイスサーチプロセスはＭＢシステムのコアタスクである。適切な宛先デバイスを発見するために、到来するデータとストレージデバイスの両方の物理的なパラメータおよび論理的なパラメータが評価される。無秩序なストック管理に関しては、単純化された物理的なマッチング判定基準のみが必要とされる。良好にソートされた記憶に関しては、物理的なマッチングプロセスと論理的なマッチングプロセスの両方が実行される。
【００４９】
以下では、図４に示されているような、到来するデータのために適切なストレージデバイスを評価するプロシージャを「デバイスマッチング」と称する。一般的にデバイスマッチングプロセスは物理的な判定と論理的な判定を含む。物理的な判定に関しては、到来するデータおよびストレージデバイスの物理的なパラメータが考慮される。論理的な判定に関しては、到来するデータ、ストレージデバイスのＭＤの特徴、また他のＭＤソースからのＭＤの特徴がデバイスサーチのために考慮される。
【００５０】
物理的な判定の適用時には以下の物理的なパラメータが評価される：ノードの空き記憶容量、ノードの自由に利用可能な伝送レートおよびノードの優先的なデータタイプ。ここでは、これらの全てのパラメータが物理的なパラメータとして処理される。
【００５１】
論理的な判定においては、記述的なメタデータが評価される。モノリシックなストレージシステムに関して割り当てられた記述的なＭＤカテゴリが規定され、またこのＭＤカテゴリを例えば以下詳細に説明するようにＡＬにおいて使用されるパラメータテンプレートに包含させることができる。
【００５２】
これら全ての実現は制御言語を用いることにより可能である。ＭＢＬソフトウェアは関連する全てのノード、すなわち（論理的な）ネットワーク、例えばオーナーゾーン内の全てのノードでは同一であると想定する。アプリケーションが動作を実行するノードにおけるＭＢＬソフトウェアは関連するプロセスを管理する。すなわち、ＭＢのコンセプトは各ノードのＭＢＬソフトウェアとして実現されている規則のセットによって実現され、また一般的に動作を実行するノードによって適用される。
【００５３】
モノリシックストレージシステム  ストレージプリファレンス
モノリシックストレージシステムは、無秩序なストック管理および良好にソートされた記憶の両方に関して、システムプリファレンスおよびユーザプリファレンスの制御下で動作する。
【００５４】
システムプリファレンスに従いシステムの振る舞いは事前に、例えば製造時または購入時に定義され、またシステムはデフォルトパラメータセッティングに基づき自動的に実行することができる。特定のシステムコンフィギュレーションの生存期間の間に、全体のシステムの振る舞い、つまり無秩序なストック管理か良好にソートされた記憶を制御するために、１つのシステムプリファレンスのみを適用することができる。システムプリファレンスをユーザプリファレンスに置き換えることができる。
【００５５】
システムのモノリシックな振る舞いに関する何らかのユーザプリファレンスが存在する場合には、プリファレンスを自動的なセッティングに可能なときに何時でも置き換える。システムの特徴的な振る舞いのユーザのプリファレンスを手動でＡＬに入力することができる。
【００５６】
モノリシックブロックアプリケーション  セットアップ
無秩序なストック管理に関しては、ＭＢアプリケーションのシステムセットアップがＡＬにおいて実施される。図５に示されているように、システムセットアップはユーザプリファレンスの入力から構成される。
【００５７】
良好にソートされた記憶に関しても、ＭＢアプリケーションのシステムセットアップがＡＬにおいて実施される。ここでシステムセットアップはユーザの好みの入力、デバイス定義およびシステムメンテナンスを包含する。システムセットアッププロシージャはユーザにモノリシックブロックシステムへのＡＰＩを提供する。初期システム状態はシステムセットアップ段階の間に定義される。システムのフィードバックに応じて、ＭＢアプリケーションの比較的長い生存期間を達成するために、規則的なシステムメンテナンスを実行する。
【００５８】
ユーザプリファレンス入力
ユーザプリファレンス入力は無秩序なストック管理においても良好にソートされた記憶においても行われる。ユーザプリファレンスを入力している間にパラメータ制御テンプレートがユーザに提示され、このテンプレートはユーザの入力に従い満たされる。テンプレートのカテゴリは目下のＭＢシステム規則に従い事前定義されている。テンプレートのパラメータカテゴリを用いることにより、ユーザは好みの物理的なパラメータを入力することができるか、（良好にソートされた記憶に関しては）論理的なパラメータ、例えば記憶場所、デバイスプロパティ、メディアデータのタイプおよび記述的なＭＤを、ユーザ自身の関心に従いデバイスマッチングプロシージャを制御するために入力することができる。ユーザの好みのパラメータが存在しない場合、または考慮されない場合には、テンプレートはシステム利用に関するデフォルトの物理的または論理的なパラメータのグループを使用することができる。テンプレートにおけるパラメータはシステムの物理的および論理的なマッチングプロセスによって使用される。
【００５９】
無秩序なストック管理に関しては、単純化されたパラメータ制御テンプレートが物理的なパラメータを入力するために使用される。良好にソートされた記憶に関しては、物理的なパラメータも論理的なパラメータも包含する完全なパラメータ制御テンプレートが使用される。
【００６０】
良好にソートされた記憶ストラテジに関してはユーザプリファレンスを入力している間に、ユーザは制御デバイス初期化プロシージャを決定することもできる。ユーザはデバイスラベルカテゴリを定義または変更することができ、また空のデバイスにラベルを付与することもできる。
【００６１】
デバイス初期化
デバイス初期化機能は良好にソートされた記憶ストラテジにおいてのみ存在する。システム初期化の間に、目下の分散しているデバイスの全てのデバイスプロパティが収集され、全てのデバイスにはデバイスプリファレンスＭＤ、例えばデータタイプおよび他の記述的なメタデータによってラベルが付与される。空のデバイスに関しては、デバイスプリファレンスラベルが目下のデバイスプロパティに従いユーザによって直接定義される。占有されているデバイスに関しては、デバイスプリファレンスがＭＢシステムによって計算される。
【００６２】
自動的なシステムストレージマッチングに関しては、ストレージデバイスの優先的なデータにはシステム初期化段階の間にラベルが付与される。目下のシステムに対して使用することができるラベルの全てのカテゴリは事前定義されるべきである。通常の場合、これらのラベルのカテゴリは記述的なＭＤであり、この記述的なＭＤはデバイスの優先的なデータの種類、例えばデータフォーマット、ジャンル、コンテントタイトルなどを表す。異なるＭＢシステムに関しては、異なる種類のラベルカテゴリを設計することができる。初期化段階の間に、各モノリシックブロックシステムはそのアプリケーションに対して１種類のラベルカテゴリを選択することができる。
【００６３】
１つの実施形態においては、システム内の目下の全てのストレージデバイスに少なくとも１つのラベルカテゴリに従いラベルが付与される。空のストレージデバイスに関しては、ユーザはデバイスの記憶容量、伝送レートおよび他の特性を分析し、続いてデバイスにラベルカテゴリにおいて定義されているラベルを付与することができる。マルチメディアシステムアプリケーションに関しては、重要なラベルカテゴリは「データタイプ」であり、したがってこのラベルカテゴリがデフォルトとして使用される。例えばデータはそのデータタイプ、例えばビデオ、オーディオ、テキストに従いストレージデバイスにおいてソートされ、そのようなデータタイプはさらにＤＶＤ（映画）、ＭＰ３（オーディオ）、ＸＭＬ（汎用）、ＤＯＣ（テキスト）などに細分化される。
【００６４】
占有されているデバイス、すなわちデータが格納されているデバイスに関しては、その優先的なデータタイプが計算される。占有されているデバイスにはその優先的なデータタイプを表すラベルが付与される。以下ではこのことを詳述する。
【００６５】
デバイス初期化段階はＭＢシステムの初期状態を形成する。後に、システムアプリケーションの間にシステム状態を変更し、システムメンテナンスプロセスによって操作することができる。
【００６６】
システムメンテナンス
ＤＳＳのメンテナンスはＭＢシステムの動作状態を維持するために良好にソートされた記憶ストラテジにおいて使用される。２種類のシステムメンテナンスが存在する、すなわち能動的なシステムメンテナンスと受動的なシステムメンテナンスである。能動的なシステムメンテナンスは事前定義された周期またはシステム状態に従い規則的に実行される。受動的なメンテナンスは、いずれかのシステム限界に達したときに、ＭＢシステムのリクエストによって起動される。
【００６７】
メンテナンスブロックがメンテナンスリクエストを受信すると、図６に示されているように、メンテナンスオーガナイザが全てのストレージデバイスを自動的に分析し、新たなデバイスラベルをストレージデバイスに割り当てる。デバイスの分析後に、メンテナンスオーガナイザはユーザに対するメンテナンス指示を形成することもでき、ユーザは例えば古いデータ、ソートされているデータを削除することによって、もしくは新たな記憶ディスクを購入することによってシステムを「手動で」改善することができる。
【００６８】
占有されているストレージデバイスにおける優先的なデータタイプ
良好にソートされた記憶に関するデバイス初期化の間の重要なタスクは占有されているストレージデバイスにおける優先的なデータタイプを発見することである。占有されているデバイスへのラベル付与は空のデバイスへのラベル付与とは異なり、そのデバイスの容量および特性に応じてユーザによってラベルを付与することができる。占有されているストレージデバイスが既に、ユーザ自身の関心に従いユーザによって最適に使用されていると想定する。システムが実施しなければならないことは占有されているデバイスにおける優先的なデータタイプを発見することである。本発明によれば、以下の優先付けストラテジが使用される。
【００６９】
ストレージデバイスが、例えばビデオ（例えばＤＶＤ）、オーディオ（例えばＭＰ３）、テキスト（ＤＯＣ）などのような１つ以上のデータタイプのデータを包含すると想定する。
【００７０】
ストレージデバイスの優先的なデータタイプとはストレージデバイスにおいて優先的なファイル総数またはファイル総サイズを有するデータタイプである。つまりこれらは両方とも優先度を表すものだからである。これら２つの値の積が計算され、また優先的なデータタイプはこの積の最も高い値を有するデータタイプと解される。優先的なデータタイプはそれぞれのデバイスの優先的なデータタイプとして定義され、またデバイスにはこのデータタイプを表すラベルが付与される。
【００７１】
新たに到来するデータは優先的なデータタイプおよびこのタイプに関連する潜在的な空き記憶容量に従い格納される。新たなデータが格納されるべき場合には、以下のプロセスを実施することができる：先ず、データタイプまた可能であれば新たなデータのデータサイズが検出され、メッセージがデータタイプおよびデータサイズ（または算出されたデータサイズ）を表す、接続されているストレージデバイスに送信され、これに基づき受信デバイスがリクエストを評価し、マッチングデバイス（すなわち、その優先的なデータタイプが要求されたデータタイプに等しいデバイス）が例えばその利用可能な容量および伝送帯域幅を用いて応答し、これらの応答から最高にマッチするデバイスが記憶のために選択される。
【００７２】
実際のアプリケーションである実施例においては、好みのデータタイプは次式に従い計算される：
Ａtotal＝Ｎtotal×Ｓtotal
Ｓaverage＝Ｓtotal／Ｎtotal
ＲＰＳＣ＝１−（Ｓaverage＋Ｃused）／Ｃtotal
Ｅdominant＝ＲＰＳＣ×Ａtotal
ここで、
Ｎtotalは所定のデータタイプのデータファイルの総数であり、
Ｓtotal［Ｇバイト］は所定のデータタイプの総ファイルサイズであり、
Ｓaverage［Ｇバイト］は所定のデータタイプの平均ファイルサイズであり、
Ｃused［Ｇバイト］はデバイスの占有されている記憶容量、すなわち全てのデータタイプの全てのＳtotalの合計であり、
Ｃtotal［Ｇバイト］はデバイスの総記憶容量であり、
Ａtotalはデータの優先的な「図表領域」（下記参照）であり、ファイル数とファイルサイズの上述の積であり、
ＲＰＳＣは所定のデータタイプのストレージデバイス相対的潜在的記憶容量であり、ここでの正の値は同一のデータタイプの別のファイルがデバイス内でフィットすることが期待されることを意味し、大きい値は同一のタイプの別のファイルのために多くの容量が残っていることを意味し、また、
Ｅdominantは優先的なデータタイプを検出するための所定のデータタイプの評価値であり、このデータタイプはＥdominantの最も高い値を有するタイプである。
【００７３】
より一般化された形態では上記の式は、
Ｅdominant,type−ＲＰＳＣtype * Ａtotal,type * Ｋ1
ＲＰＳＣtype＝ｋ2−ｋ3（ｋ４＋Ｓaverage＋Ｃused）／Ｃtotal
であり、ここで、ｋ1，ｋ2，ｋ3，ｋ4は定数である（または異なるノードのＥdominant,type値の評価時間にわたり準定数である）。上記の式の形において定数はｋ1＝ｋ2＝ｋ3＝１且つｋ4＝０である。
【００７４】
Ａtotalの値は、総ファイルサイズとファイル数の両方を考慮したデータタイプの量子化された量を表し、また図７に示されている矩形の領域に対応する。例示的に図７においてはストレージデバイスがビデオデータ、オーディオデータおよびテキストデータを有している。横軸はファイルサイズを表し、縦軸はそれぞれのデータタイプの全てのファイルの数を表す。総ファイルサイズは最大デバイスストレージ容量内にある。各データタイプ（ビデオ、オーディオ、テキスト）の総データ「領域」（Ａtotal）はこのストレージデバイスにおけるデータタイププリファレンスを表す。
【００７５】
Ｓaverageは目下のデバイスにおける各データタイプの単位データの平均ファイルサイズを表す。到来する未知のサイズのデータストリームに関しては、そのサイズを関連するＳaverageから推定することができる。ＲＰＳＣ（相対的潜在的記憶容量）は、既に格納されている同一のタイプのデータの平均ファイルサイズに従い、データタイプの予期すべき到来するデータのための目下のストレージデバイス潜在的記憶容量を評価することができる。一般的に、ＲＰＳＣはそれぞれのデータタイプのファイルサイズ統計、例えば平均ファイルサイズ、平均ファイルサイズ偏差などから計算され、また未知のサイズの到来するデータを格納できるか否かを評価するためにこのＲＰＳＣを使用することができる。到来するデータを評価できないことが判明すると、残りのデータを他のデバイスに保存するためにファイル分割を使用することができる。
【００７６】
最終的には、目下のデバイス内の優先的なデータタイプをＲＰＳＣとＡtotalの乗算によって評価することができる。結果として生じる値Ｅdominant,typeは、占有されているストレージデバイスにおける優先的なデータタイプが、データファイルの総数と総データサイズの両方の点において最大値を有するデータタイプであり、また目下のデバイスは新たに到来する同一タイプのデータを潜在的に受信できることを意味する。
【００７７】
ストレージデバイスには自身の優先的なデータタイプを表すラベルが付与される。このことは、そのデータタイプのデータがこのストレージデバイスに格納するには「歓迎すべき」ものであることを意味する。
【００７８】
【表２】
2007164794.tif 000004
【００７９】
表２は占有されているストレージデバイスにおける優先的なデータタイプに関する計算例を示す。この例においてデバイスＡは２００Ｇバイトの記憶容量を有する。この記憶容量は３つのデータタイプのグループ、すなわちビデオデータ、オーディオデータおよびテキストデータによって占有されている。「ビデオタイプ」がデバイスＡの最大Ｅdominant値を有するので、上述の式を使用してデバイスＡにおける優先的なデータタイプは「ビデオタイプ」であると評価することができる。
【００８０】
デバイスＢはデバイスＡと同じ総記憶容量を有するが、ビデオデータ、オーディオデータおよびテキストデータの数およびサイズは異なる。全てのデータタイプグループは図７によるグラフにおいては同一の「データ領域」を有する。このケースにおいては、優先的なデータタイプがＥdominantの値によって評価される。デバイスＢにおいては優先的なデータタイプは「テキスト」である。何故ならばその値Ｅdominant,textはビデオおよびオーディオに対する値Ｅdominant,video、Ｅdominant,audioよりも高いからである。他のタイプのデータが格納されていない場合、そのような他のタイプのデータの量がビデオ、オーディオおよびテキストに比べて少なければこの他のタイプのデータを無視することができるか、別個の評価値Ｅdominantが計算される。
【００８１】
この例において示したように、この章における上述の式は占有されているストレージデバイスにおける優先的なデータタイプの評価にとって有効である。
【００８２】
モノリシックブロックシステム
ストレージデバイスの検索がＭＢＬにおいて実施される。この検索はＡＬからの入力パラメータにより制御される。到来するデータをモノリシックなストレージブロックに保存する場合には、ユーザは関連するサーチストラテジおよびパラメータをＡＬを介して定義することができる。続いて、このストラテジおよびパラメータに従い、ＭＢＬは適切なストレージデバイスを自動的にサーチすることができる。ユーザ入力パラメータが存在しない場合には、ＭＢシステムは適切なストレージデバイスを探すためにデフォルトマッチングストラテジに従い実行されることになる。以下これをより詳細に説明する。
【００８３】
上述のシステム初期化プロセスの後に、ＭＢＬはさらにストレージデバイスサーチアクティビティを実施することができる。サーチアクティビティはデフォルトパラメータまたはユーザが割り当てたパラメータに基づき自動的に実行される。図８はモノリシックブロック（ＭＢ）システム全体の概観を示す。ＭＢシステムを上述した２つのストレージストラテジ、すなわち無秩序なストック管理および良好にソートされた記憶の内のいずれかに従い実現することができる。両方のストラテジ形態は「ストレージデバイスの物理的な決定」および「ユーザプリファレンスの決定」と称される類似する評価プロシージャを使用する。
【００８４】
ストレージデバイスの物理的な決定は、ＭＢアプリケーションのためのストレージデバイスの選択において最初の役割を果たす。このストレージデバイスの物理的な決定は基本的で物理的なパラメータを評価し、また以下のステップを含む：デバイスの空き記憶容量の計算、デバイス伝送レートの計算、（良好にソートされた記憶のケースにおいては）デバイスの優先的なデータタイプの問合せ、また必要に応じてファイル分割の起動。データの量が格納の前に未知である場合、またはいずれのストレージデバイスも十分な空き容量を有していない場合には、データを種々のストレージデバイスに分散させることができる。このいわゆる「ファイル分割」モードを、図３に示されているように、ＤＳＳによって支援することができる。
【００８５】
無秩序なストック管理と良好にソートされた記憶とではストレージデバイスの物理的な決定の異なるバージョンを使用する。つまり、無秩序なストック管理は良好にソートされた記憶に比べて単純化されたバージョンの物理的な決定を使用する。
【００８６】
ユーザプリファレンスの決定はアプリケーションに関する最終的な選択の役割を果たし、したがって最終的な決定はユーザプリファレンスに残される。最終的な選択を行うために、事前定義されたデフォルトパラメータまたはユーザアップデータの論理的なパラメータ（記述的なメタデータ）が使用される。このパラメータを物理的なストレージマッチングおよび（良好にソートされた記憶に関しては）論理的なストレージマッチングのステップから構成することができる。
【００８７】
物理的なストレージマッチングは事前定義された公式およびストラテジに基づき、デバイスの物理的なパラメータを評価する。「ストレージデバイスの物理的な決定」と「物理的なストレージマッチング」の主な相違点は、前者がデバイスの物理的なパラメータの絶対値を評価するのに対し、後者はデバイスの物理的なパラメータの相対値を評価することである。
【００８８】
物理的なストレージマッチングは以下のステップを含む：到来するデータのための相対的な記憶容量の計算、（良好にソートされた記憶に関しては）事前定義されたストラテジによるシステム平衡評価、および（ユーザによって起動される場合には、良好にソートされた記憶に関しては）セーフコピーアクションの起動。
【００８９】
良好にソートされた記憶に関して、論理的なストレージマッチングは（ＡＬから受信した）ユーザ入力メタデータのみに従いデバイスを評価する。論理的なストレージマッチングに基づき、モノリシックなストレージシステムはユーザの全ての種類のストレージ要求を満たすことができる。
【００９０】
モノリシックブロック層に関するさらなる詳細を以下説明する。
【００９１】
無秩序なストック管理
図８に示されているように、「無秩序なストック管理」状態のデバイスをサーチするプロシージャを以下の２つのステップに基づき実現することができる。すなわち、ストレージデバイスの物理的な決定およびユーザプリファレンスの決定。良好にソートされた記憶状態のデバイスに比べて、無秩序なストック管理状態のデバイスのサーチはこれらのステップに関する単純化されたプロセスのみを使用する。例えば、ストレージデバイスの物理的な決定プロセスにおいては、デバイスの絶対的な空き記憶容量および伝送レートのみが評価され、ユーザプリファレンスの決定においては、（サブカテゴリの物理的なマッチングのもとで）デバイスの相対的な空き記憶容量のみが評価される。
【００９２】
無秩序なストック管理のデバイスに関する基本的なタスクは到来するデータのための記憶空間を提供し、他方ではよりメタデータに依存する最適なデバイス評価およびデータソートは考慮されない。
【００９３】
一時的な無秩序なストック管理を適切な時点において、良好にソートされた記憶にさらに変形することができる。
【００９４】
良好にソートされた記憶
良好にソートされた記憶状態のデバイスのサーチをストレージデバイスの物理的な決定およびユーザプリファレンスの決定の２つのステップで実現することができる。オペレーションのステップは無秩序なストック管理のステップと類似するが、関連するプロセスの完全なバージョンを使用する。ストレージデバイスの物理的な決定プロセスにおいては、絶対的なデバイス空き記憶容量およびデバイスの伝送レートに加えて、デバイスの優先的なデータタイプが評価され、ユーザプリファレンスの決定プロセスにおいては、（サブカテゴリの物理的なマッチングのもとでの）相対的なデバイス空き記憶容量に加え、（物理的なマッチングにおける）システムパラメータ平衡評価および論理的なマッチングが実施される。論理的なマッチングにおいては、より記述的なメタデータの特徴が考慮される。「セーフコピー」プロセスは最終的に割り当てられるストレージに対しても可能である。
【００９５】
ストレージデバイスの物理的な決定
ストレージデバイスの物理的な決定は無秩序なストック管理および良好にソートされた記憶の両方の状態のデバイスに関する初期選択プロセスである。このプロセスは、図９に示されているように、４つのオペレーション、すなわちデバイス空き記憶容量の評価、デバイス伝送レートの評価、（良好にソートされた記憶に関しては）デバイスの優先的なデータタイプの評価、また必要に応じてファイル分割コマンドの形成により形成される。
【００９６】
全てのストレージストラテジはデバイス空き記憶容量の評価およびデバイス伝送レートの評価を使用することができる。絶対的な空き記憶容量および伝送レートという物理的なパラメータが計算される。
【００９７】
デバイスの優先的なデータタイプの評価は、そのデータタイプ、例えばビデオ、オーディオ（ＭＰ３）などに従い到来するデータを分類する、良好にソートされた記憶状態のデバイスをサーチする場合にのみ使用される。
【００９８】
到来するデータのサイズが単一のデバイスにロードするには過度に大きい場合には、ファイル分割コマンドが形成される。このプロセスをユーザ定義によりＡＬにおいて起動することができる。ファイル分割コマンドが形成されると、ＭＢシステムは残りのデータを保存するための他のストレージデバイスを検出する。
【００９９】
通常の場合、ファイル分割は自動的な機能である。しかしながら、場合によっては、ユーザがデータを分割するためのコマンドをトリガすることもできる。
【０１００】
ユーザプリファレンスの決定
ユーザプリファレンスの決定は無秩序なストック管理および良好にソートされた記憶状態のデバイスのサーチの両方に関する最終的な選択プロセスである。このプロセスが図１０に示されており、また物理的なストレージマッチングおよび（良好にソートされた記憶のための）論理的なストレージマッチングから構成することができる。
【０１０１】
これらのマッチングプロセスに対してデフォルトパラメータおよびアップデートされたユーザ入力パラメータの両方を適用することができる。デフォルトパラメータはＭＢアプリケーションによって事前定義されている。これらの事前定義されたパラメータをＡＬにおいて使用されるパラメータ制御テンプレートに含ませることができる。これらのデフォルトパラメータに基づき、ＭＢシステムはいかなるユーザコマンドを要することなくマッチングタスクを自動的に実行することができる。ユーザはパラメータテンプレートにおける関連付けられた値を変更することによりデフォルトパラメータをアップデートすることができる。目下のユーザ入力パラメータにより、ユーザはこのユーザの優先的なストレージデバイスを発見するためにシステムを制御することができる。
【０１０２】
物理的なストレージマッチング
物理的なストレージマッチングは、図１１に示されているように、以下の機能を含む。すなわち、相対的な空き記憶容量（ＲＦＳＣ）の評価、システムパラメータ平衡の評価、およびセーフコピーコマンドの形成。
【０１０３】
相対的な空き記憶容量（ＲＦＳＣ）の評価プロセスは、無秩序なストック管理および良好にソートされた記憶の両方によって使用される。上述のＲＰＳＣ（相対的潜在的記憶容量）と同様に、ＲＦＳＣは到来するデータのデータタイプに関する以下の式により計算される：
ＲＦＳＣ＝１−（Ｓin_data＋Ｃused）／Ｃtotal
ここで、
Ｃused［ＧＢ］はデバイスの使用されている記憶容量であり、
Ｃtotal［ＧＢ］はデバイスの総記憶容量であり、
Ｓin_data［ＧＢ］は所定のデータタイプを有する到来するデータのサイズであり、
ＲＦＳＣはこのデータタイプに対するストレージデバイスの相対的な空き記憶容量である。
【０１０４】
より一般化された形では上記の式は以下のようになる。
ＲＦＳＣ＝ｃ1−ｃ2（ｃ3＋Ｓin_data＋Ｃused）／Ｃtotal
ここで、ｃ1，ｃ2，ｃ3は定数である（または異なるノードのＲＦＳＣ値の評価時間にわたり準定数である）。
【０１０５】
上記の式の形においては、定数はｋ1＝ｋ2＝ｋ3＝１且つｋ4＝０である。
【０１０６】
システムパラメータ平衡の評価は良好にソートされた記憶によってのみ使用される。このシステムパラメータ平衡の評価は基本的なパラメータに基づき複雑なデバイスマッチングストラテジを定義することができる。例えば、上述の相対的な空き記憶容量の評価においては、最大のＲＦＳＣ値を有するデバイスが到来するデータに対して最高の伝送レートを提供しない可能性がある。このケースにおいては、より低いＲＦＳＣ値を有するが、適切な伝送レートを有する他のデバイスを到来するデータにとっての最善のストレージ候補として選択することができる。システムパラメータ平衡の評価においては、ユーザがＭＢアプリケーションに対して異なる実用的なストラテジを定義することができる。
【０１０７】
物理的なストレージマッチングの場合においてセーフコピー機能がユーザによってＡＬにおいて起動される場合には、このセーフコピー機能はセーフコピーコマンドを形成し、到来するデータを保存するための他のストレージデバイスを発見するために上述のデバイスサーチプロセスを再び実行する。この付加的なデータ記憶は、必要に応じて、後のディザスタリカバリに対して有効である。
【０１０８】
表３は相対的な空き記憶容量に従いデバイスを選択するための例を示す。デバイスＡは２００Ｇバイトの総記憶容量を有し、またその優先的なデータタイプは「ビデオ」である。デバイスＢは１００Ｇバイトの総記憶容量を有し、またその優先的なデータタイプはやはり「ビデオ」である。１０Ｇバイトの到来するデータをデバイスＡに保存する場合には、デバイスＡにおける到来するデータのＲＰＳＣ値は０．６７である。１０Ｇバイトの到来するデータをデバイスＢに保存する場合には、デバイスＢにおける到来するデータのＲＰＳＣ値は０．７２である。したがって、到来するデータに対してデバイスＢはデバイスＡよりも多くの相対的な空き記憶容量を提供するので、デバイスＢが選択されることになる。
【０１０９】
【表３】
2007164794.tif 000005
【０１１０】
上記の例は、上述の式があらゆる到来するデータに対するストレージデバイスの選択に関する量的な評価を提供することを示す。
【０１１１】
論理的なストレージマッチング
物理的なストレージマッチングの後に、候補ストレージデバイスを論理的なストレージマッチングプロセスによってさらにフィルタリングすることができる。論理的なストレージマッチングは、到来するデータを適切なデバイスに配置するための記述的なメタデータを使用するために設計されている。
【０１１２】
原理的にはＭＤベースの全ての種類のマッチングが許容される。事前定義されたＭＤマッチングストラテジおよびアップデートされたＭＤマッチングストラテジの両方を論理的なストレージマッチングに適用することができる。論理的なストレージマッチングストラテジの目的は、ユーザが良好にソートされた記憶状態のデバイスにデータを保存することができる最大限の機会を提供することにある。
【０１１３】
実際のシステムアプリケーションに関してはメタデータベースのマッチング方法が考えられ、これは図１２に示されている。システム初期化段階においては、ユーザは好みのＭＤを入力することができるか、好みのＭＤコンテナに直接リンクすることができ、その結果コンテナ内のＭＤコンテントはユーザの好みのＭＤとして読み取られることになる。アプリケーション層においては、ユーザは上述のＭＤコンテントを入力するためにパラメータ制御テンプレートを使用することができる。システムが許容できる全ての記述的なＭＤカテゴリをパラメータテンプレートにおいて事前定義することができる。パラメータテンプレートはデフォルトＭＤコンテントも含むことができる。アップデートされたユーザの好みのＭＤが設定されていない場合には、システムは論理的なストレージマッチングプロセスを実行するためにデフォルトＭＤを使用する。
【０１１４】
図１２に示されているように、ＭＢシステムはユーザプリファレンスと同じメタデータによってラベルが付与されているストレージデバイスをサーチする。最終的に、到来するデータは物理的なストレージ要求および論理的なストレージ要求の両方を満たすストレージデバイスに保存される。
【０１１５】
例示的なシナリオおよびそのメッセージ並びにメタデータの流れ
以下では、分散的なストレージ管理のために要求されるシステムモデルおよび制御言語の実現可能性を実証するためにＤＳＳの考えられるアプリケーションを表す幾つかの単純なシナリオを、例示的な関連するメッセージおよび制御メタデータも含めて説明する。このシナリオは、図１３に示されているように、分散型のストレージ用の例示的なネットワークを基礎としている。このネットワークは据え置き型のストレージデバイス／ノードＳ０，．．．，Ｓ（個人用ディジタルレコーダ、例えばＨＤＤ、光ディスク）およびポータブルなストレージデバイス／ノードＰを包含する。各ノードはアプリケーションを実行することができ、またこれらのノードはユーザインタフェース／遠隔制御部を有し、これらのユーザインタフェース／遠隔制御部を別個のデバイス／ノードとみなすこともできる。ホームネットワークに対して考えられる拡張として、チューナ／受信装置（例えばＤＶＢ−ＳまたはＤＶＢ−Ｃなど）、ＡＶディスプレイ／出力装置、インターネットアクセス用のＡＤＳＬモデムまたはゲートウェイ等を挙げることができる。ここで例示されているシナリオにおいては、ノードＳ０が一般的にＤＳＳと対話するために使用される。
【０１１６】
シナリオ１：容量が制限されているケースにおけるコンテントのコピーおよびネットワーク内の記憶容量のバランスの良い使用。
【０１１７】
ユーザはデバイスＰに格納されているコンテントを据え置き型のストレージデバイスＳ０，．．，Ｓ３のいずれかにコピーしようとする。コンテントは最も大きい空き記憶容量を提供する据え置き型のデバイスにコピーされる。他の実施形態においては、コンテントが空き記憶容量の最高のマッチング量を提供するデバイス、すなわち残りの容量が最も少ないデビスにコピーされ、ギャップが最適に使用される。
【０１１８】
シナリオ２：休止および再開ならびにトリックモード（早送り、スローモーション）
（例えば表示装置Ｐにおいてコンテントを見るために）デバイスＳ１〜Ｐに格納されているコンテントを伝送している間に、ユーザは（Ｓ０を介して）伝送（例えば再生）を休止し、数分後に再生を再開する。後に再び通常の速度で再生している間に、ユーザは早送りまたはスローモーションのような何らかのトリック再生（サムネイルのブラウズ、ビデオグループシーンのブラウズなども考えられる）を選択する。デバイスＳ１がトリックモードケイパビリティについて検査されて、そのケイパビリティが確認されると、デバイスＳ０が早送りリクエストメッセージをデバイスＳ１に送信し、所望の早送りモードおよび速度に変更される。
【０１１９】
シナリオ３：ストレージデバイスＳ１からの読み出しとストレージデバイスＳ１への書き込み（レコーディングと再生）を同時に行うマルチタスク
ノードＳ１は２つのタスク、すなわちノードＳ２から受信したコンテントの部分のレコーディング、およびノードＰについてコンテントの別の部分の再生を同時に実行する。
【０１２０】
シナリオ４：タスクの衝突および伝送遅延を伴う同時的な読み出しと書き込み
シナリオＳ２と同様に、ユーザはデバイスＳ２からＳ１へのレコード伝送を設定しようとし、またデバイスケイパビリティはこのレコード伝送の設定を実施することができる。しかしながら伝送を開始する前に、別のユーザがデバイスＳ１からＰへの別の再生伝送を開始すると、デバイスＳ１の自由に利用可能な伝送レートはデバイスＳ２からＳ１への伝送を容易にするにはもはや十分なものではなく、したがってこの伝送は拒否される。ユーザは伝送が後の時点に行われるようにスケジューリングすることを決定する。したがってデバイスＳ２からＳ１への伝送が設定される。
【０１２１】
シナリオ５：デバイスの接続および切断
ユーザは自身のポータブルデバイス（Ｐ）をデバイスＳ０，．．，Ｓ３から構成されている既存のネットワークに接続し、後の時点に切断する。ソフトウェアによってトリガされる「ソフト切断」と強制的に切断される「ハード切断」は区別される。
【０１２２】
シナリオ６：タスクの衝突および非リアルタイムの伝送を伴う同時的な読み出しと書き込み
伝送遅延の代わりに非リアルタイム伝送が実施される点を除いてシナリオ４に類似する。コンテントはファイルとして比較的低いビットレートで伝送され、したがって比較的長い時間にわたり伝送され、記憶空間である積は一定のままである。
【０１２３】
シナリオ７：コンテントの分割を伴うレコーディング
いずれのノードもコンテント全体を格納することができないので、コンテントの部分が種々のノードにわたりレコードおよび分散される。
【０１２４】
シナリオ８：分割されたコンテントの再生
種々のノードにわたり分散しているコンテントの部分がシームレスに再生される。
【０１２５】
シナリオ９：事後的なコンテントの分割を伴う瞬間的なレコーディング
記録は１つのノードにおいて開始されるが、いつ終了するかは分からず、デバイスがほぼ一杯になると、レコーディングは別のノードにおいて継続される。
【０１２６】
シナリオ１０：コンテントの消去
サーチおよび発見されたコンテントの一部が消去される。
【０１２７】
シナリオ１１：マルチキャスト／ブロードキャスト
コンテントの部分が種々のノードに伝送される（マルチキャスト）か、全てのノードに同時に伝送される（ブロードキャスト）。
【０１２８】
シナリオ１２：伝送の中断および再開
ソースまたは宛先がハード切断に起因して一時的に利用不能になるので、コンテントの部分の伝送が中断される。３と２のケースが区別され、これらの内の２においては伝送が中断された点から再開される。
【０１２９】
以下の構造は例示的に上述のピア・ツー・ピア技術層、または他の対応する層を参照する。上記のシナリオの実現にあたり、異なるメッセージまたはタスクが、メッセージパラメータまたは引き数として包含されている固有の制御メタデータと共に使用される。表記を容易にするために、メッセージはメッセージ名および引き数、例えばDeviceCapabilitiesInformation(Sender, Receiver, TaskID, DeviceType, DeviceServices, MaxBitRate, FreeStorageCapacity, ...)によって表される。全てのメッセージは自身の固有のメッセージＩＤ（MessageID）を有しているが、見やすくため上記の表記においてこのメッセージＩＤは省略されている。
【０１３０】
各シナリオに関して、先ずシナリオの初期条件、次にシナリオの詳細な説明、最後にメッセージフローが挙げられている。
【０１３１】
シナリオ１：容量が制限されている場合のコンテントのコピーおよびオーナーゾーン内の記憶容量のバランスの良い使用
初期条件：ノードＳ０，．．．，Ｓ３およびＰから成るネットワークが図１４に示されているように構成され実行される。コンテントの伝送は実施されず、全てのノードはアイドル状態にある。
【０１３２】
シナリオ：ユーザはデバイスＰに格納されているコンテントをストレージデバイスＳ１，Ｓ２またはＳ３のいずれかにコピーしようとする。最も大きい空き記憶容量を提供する据え置き型のストレージデバイスが検出され、そのストレージデバイスにコンテントがコピーされる。
【０１３３】
ユーザはコンテントの所望の部分をサーチするためにデバイスＳ０を使用する。したがって、デバイスＳ０はサーチリクエストメッセージをネットワーク／オーナーゾーン内の全てのデバイスに送信する。デバイスＰはコンテントを有し、したがってデバイスＳ０に応答する。ただしこのシナリオに対する変形実施形態「Ａ」として、コンテントのサーチおよびコピーのタスクを開始するためにデバイスＰをデバイスＳ０の代わりに使用することができる。このケースにおいては、ノードＰはリクエストに整合するコンテントに関する応答を自身には送信せず、ノードＰは相応の情報を自身のコンテントデータベースから受け取ることになる。
【０１３４】
ユーザはいずれかの据え置き型のストレージデバイスにコンテントを格納しようとするので、デバイスＳ０がデバイスＳ１，Ｓ２およびＳ３にそれらの記憶容量および伝送ケイパビリティを問い合わせるために使用される。Ｓ１，Ｓ２，Ｓ３はそれらのデバイスケイパビリティに関してＳ０に情報を提供し、それらの全てのデバイスは自由に利用可能である十分な伝送レートを有する。この場合、デバイスＳ１に対しては空き記憶容量の制限が観測されているのに対し、デバイスＳ３は最大空き容量を提供する。したがってデバイスＳ０はデバイスＰに対してコンテントをデバイスＳ３に伝送するようリクエストし、したがってこれによりネットワーク内でよくバランスのとれた形で記憶容量を利用できるようになる。関連するデータ伝送が終了すると、デバイスＰはＳ３にメッセージを通知する。コンテントのレコーディング後には、デバイスＳ３がうまく完了したことに関する情報をＳ０に通知する。
【０１３５】
オーナーゾーン内での記憶容量のバランスのとれた利用、すなわち各ノードの記憶空間の管理とは例えば、（このシナリオにおけるように）最大の絶対的な空き記憶容量または相対的な空き記憶容量または自由に利用できる最高の伝送レートを実施形態に依存して提供するノードにおいてコンテントの部分をレコーディングすることを意味する。しかしながら、バランスのとれた記憶容量の利用は、ネットワーク内の記憶容量を管理するための１つの可能なやり方にすぎない。例えば容量が制限されているケースにおいてコンテントをコピーする場合に、他のストラテジも同様に適用することができる。
【０１３６】
メッセージフロー：このシナリオにおいてはメッセージの以下のシーケンスが生じる。全てのメッセージは送信側（Sender）および受信側（Receiver）を含む。これらはまたそれぞれのメッセージタイプに固有のパラメータも包含する。
【０１３７】
ユーザはコンテントの所定の部分またはタイプをサーチしようとする。ユーザ入力の結果として、デバイスＳ０は以下のサーチリクエストを全てのデバイスに送信し、その際、Ｓ０はＳ２に関していくつかの事前の知識があるという理由から、あるいは殊にＳ２に関心があるという理由から、Ｓ０は特にＳ２に対しメッセージを送信する。
2007164794.tif 000006
【０１３８】
全てのデバイスは、タスクＩＤ（TaskID）の関係およびタスクに関連するパラメータを一時的に格納し、自身のデータベースをサーチする。Ｐは要求されたコンテントの部分を発見し、したがって以下のメッセージをデバイスＳ０に送り返す。
2007164794.tif 000007
【０１３９】
Ｓ０の代わりのデバイスＰがコンテントのサーチおよびコピーのタスクを開始するために使用される、このシナリオについての変形実施形態「Ａ」においては、このメッセージは発生せず、ノードＰは単にそのコンテントデータベースから発見されたコンテントに関する情報を取得しようとするに過ぎない。
【０１４０】
「全ての」受信側がContentInfoRequest（"search"）メッセージでアドレッシングされているので、受信側はリクエストに整合するコンテントが発見されるまでリクエストに応答する必要はない。しかしながらＳ２は明示的に受信側として挙げられているので、所望のコンテントを保持しているか否かというリクエストに対しては応答する必要がある。Ｓ２は時々自身のデータベースをサーチする必要があり、またサーチを開始するときに以下のメッセージをＳ０に送信する：
2007164794.tif 000008
【０１４１】
この場合デバイスＳ２は要求されたコンテントの部分を発見しない。デバイスＳ２は「応答しなければならない」受信側としてContentInfoRequest("search")メッセージでアドレッシングされているので、デバイスＳ２内で所望のコンテントが発見されなかったにもかかわらず、このデバイスは以下のメッセージをデバイスＳ０へ送り返す。
2007164794.tif 000009
【０１４２】
全てのデバイスのサーチプロセスが完了する前に、ユーザが所望の何らかのコンテントを発見した場合には、ユーザはＳ０に以下のメッセージを使用してサーチプロセスをキャンセルさせることができる。
2007164794.tif 000010
【０１４３】
このメッセージを受信した後に全てのデバイスは自身のサーチプロセスを停止する。デバイスＳ２は「応答しなければならない」受信側としてContentInfoRequest("search")メッセージでアドレッシングされているので、CancelTaskRequest("search")リクエストの受領確認としてデバイスＳ２は以下のメッセージをデバイスＳ０へ送り返す。
2007164794.tif 000011
【０１４４】
ContentInfoResponseメッセージをデバイスＳ０に送信した後に、ノードＰおよびＳ２はタスクＩＤおよび関連するパラメータを自身のテンポラリメモリから削除する。同じことはCancelTaskResponseメッセージを送信した全てのデバイスについてもあてはまる。
【０１４５】
この場合ユーザはサーチ結果に満足し、それらのデバイスの空き記憶容量および伝送レートを取得するために、デバイスＳ０はこのときリクエストメッセージをデバイスＳ１，Ｓ２，Ｓ３に送信し、それらのデバイスケイパビリティについて問い合わる。デバイスＳ１，Ｓ２，Ｓ３は、自身のデバイスケイパビリティに関する情報をデバイスＳ０に提供することによって応答する。
2007164794.tif 000012
【０１４６】
択一的に、デバイスＳ０は以下のようなRequestDeviceCapabilityメッセージをこれら３つの全てのノードに送信することができる。
2007164794.tif 000013
【０１４７】
デバイスＳ０はデバイスＳ１，Ｓ２，Ｓ３の空き記憶容量および伝送レートを評価する。デバイスＳ１は十分な空き記憶容量をもっていないのに対し、デバイスＳ３は最大記憶容量を提供する。ネットワーク内の据え置き型のストレージデバイスの記憶容量をバランスよく利用するために、デバイスＳ０はコンテントをデバイスＰからレコーディングするために、ユーザの対話を必要とすることなく自動的にデバイスＳ３を選択し、伝送を実行するようデバイスＳ３およびＰに要求する。
2007164794.tif 000014
【０１４８】
このシナリオに対する変形実施形態「Ａ」においては、１つの受信側が省略され、メッセージが即座にスタートすることである。
InitiateTransferRequest (Sender = NodeID(P), Receiver = NodeID(S3), TaskID = fgh, ...).このケースでは、ノードＰにおいて必要とされるリソースを利用できる場合にのみ、ノードＰに対しこのInitiateTransferRequestの送信が許可される。
【０１４９】
このメッセージはノードＰのロケーションにあるコンテントの部分をノードＳ３に伝送し、そこにレコードすることを要求する。コンテントＩＤ（ContentID）は、ノードＰにおけるデータのロケーションを特定するＵＵＩＤである。タスクＩＤ（TaskID）はＵＵＩＤであり、これは例えば関与するデバイスのノードＩＤ（NodeID）と、伝送すべきデータのロケーションと、タスクが開始された時点とに基づき定義することができる。デバイスＰおよび／またはデバイスＳ３がそれらのFreeTransferRate（自由に利用可能な伝送レート）によればその時点で過度にビジー状態である場合、それらはInitiateTransferResponse("denied"）メッセージ（伝送応答開始「拒否」）をデバイスＳ０に送信することになり、ついでＳ０によりCancelTaskRequestメッセージがデバイスＰとデバイスＳ３に送信されることによりタスクがキャンセルされ、それらのデバイスはCancelTaskResponseメッセージをデバイスＳ０に送ることにより返答するか、レコーディングが後の時点で再び試みられることになるか、またはDeviceCapabilitiesInformationメッセージから得られるUntil（いつまで）に従いAfter（以降）パラメータを使用してレコーディングがスケジューリングされることになる。
【０１５０】
上記のメッセージの受信後に、デバイスＳ３およびデバイスＰはリクエストに対し受領確認を行い、個々のリソースを割り当てる。このシナリオに対する変形実施形態「Ａ」においては、ノードＰが受領確認メッセージを自身とデバイスＳ３には送信しない。何故ならば、それらには十分なリソースを利用可能であることが暗黙的に既知であり、したがって第２の以下の２つのInitiateTransferResponseメッセージは発生しない。この場合、ユーザは自身が管理する所定の人員グループに、自身で定義した"John’s James Bond friends"というラベルでコンテントのコピーに対するアクセスの許可を与えたいと望んでおり、それ応じてＳ０に命令する。
2007164794.tif 000015
【０１５１】
TransferPurposeパラメータの値が「Record」であるので、宛先ノードＳ３はデータ転送プロセスを制御することになる。続いて（またはAfterパラメータに従い後の時点において）デバイスＳ３はデバイスＰに対してそれぞれのコンテントデータを自身に送信することを要求する。
2007164794.tif 000016
【０１５２】
デバイスＰはデバイスＳ３からのリクエストを受け取り、要求されたコンテントと共に以下の応答メッセージをデバイスＳ３に送信し、これによってデバイスＰからデバイスＳ３へのコンテントデータの伝送が開始される。
2007164794.tif 000017
【０１５３】
デバイスＳ３は次にＳ０に対しレコーディングプロセスの開始に関する情報を提供し、これによってユーザに対し以下のことを知らせることができる。
2007164794.tif 000018
【０１５４】
デバイスＳ３は（ForwardDataRequestメッセージにより開始される）伝送を制御するので、デバイスＳ３はTransferStatusInformation("starting")メッセージ（伝送ステータス情報「スタート」）をデバイスＳ０へ送信する。デバイスＰがデータ伝送を完了すると、このデバイスは以下の情報メッセージをデバイスＳ３に送信し、したがって全てのデータが伝送されたことが確認される（このメッセージを受け取らなかった場合には、デバイスＳ３はそのことを、例えば強制的にデバイスが切断されるなど何らかの理由で伝送が完了しなかったことの合図として用いることができる）：
2007164794.tif 000019
【０１５５】
デバイスＳ３はレコーディングを完了し、レコーディングがうまく完了したことに関する以下の情報メッセージをデバイスＳ０に送信し、これによりそのことをユーザに通知することができる。
2007164794.tif 000020
【０１５６】
デバイスＰおよびデバイスＳ３は自身のリソースの割り当て解除を行い、ここでデバイスＳ０はユーザに対して伝送タスクがうまく完了したことに関する通知を行う。
【０１５７】
これらのステップを図１５に示されているように、メッセージのシーケンス図によって表すことができる。
【０１５８】
本発明を有利には自己完結型のネットワークに適用することができ、このネットワークにおいてはネットワークデバイスがある程度の自律性を有する。殊に、ネットワークデバイスはクライアントサーバアーキテクチャにおけるクライアント以上のものであるとみなされる。例えば欧州特許明細書EP1427149号に記載されているように、有利にはネットワークデバイスはクライアントとサーバの役割を同時に果たすことができ、例えばＰ２Ｐアーキテクチャにおけるピアとして機能することができる。さらにネットワークを他のネットワークと接続することができるが、このコネクションは明示的に「内部」ネットワークと定義されない限り、一般的には「外部」ネットワークとみなされる。外部コネクションを介して接続されているストレージデバイスは外部デバイスとみなされ、また一般的にはモノリシックブロック（ＭＢ）に含まれるものではない。
【０１５９】
ネットワーク内の複数のストレージデバイスを１つのＭＢとみなし、そこではユーザがそれらのデバイスを区別する必要がない場合は考慮すべき問題である。１つの可能性は全てのネットワークデバイスがＭＢの部分であるということである。このことは、僅かな記憶容量しか有さない小さいデバイスも考慮されるということを意味する。
【０１６０】
１つの実施形態においては、自動的に検出されたストレージデバイスがプロポーザルとみなされ、ユーザによって確認されることが必要とされる。
【０１６１】
別の可能性はこれらのネットワークデバイスのみが、少なくとも最小限のリソース、例えば総記憶容量、データ伝送レート、または所定のサービスを提供するＭＢに含まれることである。そのようなデバイスに対する最小限の要求を局所的に定義することができ、またユーザによって修正することができ、さらにはこの要求はデバイスが接続されると自動的に検出される。
【０１６２】
例えば新たに接続されたデバイスには自身のケイパビリティを他のデバイスまたは特定のサービスに提供することが要求される。そのデバイスが例えば１Ｇバイトまたはそれ以上の総記憶容量を有し、そのコネクション帯域幅が他の目的のためには決して割り当てられない場合には、そのデバイスはＭＢに含まれることになる。そのデバイスが接続されたときに既にデータが格納されている場合には、（保護されていなければ）それらのデータをネットワーク内でＭＢアプリケーションを介して利用することができる。デバイスケイパビリティが十分でない場合には、このデバイスはＭＢに関してストレージノードとはみなされないが、例えば入力／出力ノードまたは他の特別な目的のノードとみなすことはできる。しかしながら、明示的にＭＢ内のデバイスを排除するか、ＭＢ内に包含させるため、および／または、どのデバイスがＭＢの一部として考慮されるかを定める規則を修正するために、ユーザは自身のネットワークをコンフィギュレートすることができる。
【図面の簡単な説明】
【０１６３】
【図１】アプリケーションが分散ストレージシステムをどのように見るかを示す。
【図２】「要求されたストレージターゲット」モードを示す。
【図３】ファイル分割の原理を示す。
【図４】モノリシックブロックシステムのコアタスクである適切なストレージデバイスの識別（「デバイスマッチング」）を示す。
【図５】無秩序なストック管理に関するモノリシックブロックＡＰＩを示す。
【図６】良好にソートされたストレージに関するモノリシックブロックのセットアップを示す。
【図７】ストレージデバイス内のデータタイプの総「領域」を示す。
【図８】モノリシックブロックシステムの概観を示す。
【図９】ストレージデバイスの物理的な決定を示す。
【図１０】ユーザプリファレンスの決定を示す。
【図１１】物理的なストレージマッチングを示す。
【図１２】論理的なストレージマッチングを示す。
【図１３】分散ストレージシナリオにおける例示的なホームネットワークを示す。
【図１４】容量が制限されているケースでのコンテントのコピーを示す。
【図１５】容量が制限されているケースでのコンテントのコピーに関するメッセージのシーケンス図を示す。
【図１】
2007164794.tif 000021
【図２】
2007164794.tif 000022
【図３】
2007164794.tif 000023
【図４】
2007164794.tif 000024
【図５】
2007164794.tif 000025
【図６】
2007164794.tif 000026
【図７】
2007164794.tif 000027
【図８】
2007164794.tif 000028
【図９】
2007164794.tif 000029
【図１０】
2007164794.tif 000030
【図１１】
2007164794.tif 000031
【図１２】
2007164794.tif 000032
【図１３】
2007164794.tif 000033
【図１４】
2007164794.tif 000034
【図１５】
2007164794.tif 000035