(57)【要約】【課題】  本発明は、記憶されたファイルに対応したメタデータを含んだスケーラブルな高容量記憶システム及び方法を提供する。【解決手段】  メタデータ管理システム（ＭＤＳ）は区画化された移動可能なメタデータを含む。メタデータは複数のメタデータ区画（１０２−０乃至１０２−１１）内に記憶される。各メタデータ区画は特定のシステム資源（１０４−０乃至１０４−５）に割当てられる。メタデータの古さなどの所定のポリシーに従い、１つのメタデータ区画に記憶されているメタデータは、異なるメタデータ区画へ移動される。転送オブジェクトが移動されたメタデータの新しい場所を示すために古いメタデータ区画中に置かれる。メタデータ区画（１０２−０乃至１０２−１１）は、記憶システムの必要性を満たす柔軟性及び高度のスケーラビリティを可能にするため、異なる資源に再割当、分割及び／又は融合される。
2005530242.tif 000002
【特許請求の範囲】
【請求項１】
データファイルを記憶する方法であって、
記憶サービス・システム中にファイルを記憶するステップと、
ファイルに対応するメタデータを記憶サービス・システムから分離された複数のメタデータ区画上に記憶するステップと、
を含む方法。
【請求項２】
各メタデータ区画を資源へ割当て、各資源はその資源に割当てられたメタデータ区分中のメタデータへのアクセスを提供するステップ、
をさらに含む請求項１に記載の方法。
【請求項３】
資源が少なくとも１つの第１クラス資源及び少なくとも１つの第２クラス資源を含み、第２クラス資源は第１クラス資源がメタデータ区画にアクセスするのとは異なる態様でメタデータ区画へのアクセスを提供する請求項２に記載の方法。
【請求項４】
第２クラス資源は第１クラス資源よりも少ない計算資源を持つ請求項３に記載の方法。
【請求項５】
所定のポリシーに従い、１つのメタデータ区画から別のメタデータ区画へメタデータを移動することをさらに含む請求項１に記載の方法。
【請求項６】
所定のポリシーが、メタデータが最後にアクセスされてからの時間量を含む請求項５に記載の方法。
【請求項７】
所定のポリシーが、利用可能なメタデータの空間を含む請求項５に記載の方法。
【請求項８】
所定のポリシーが、サービスの品質値を含む請求項５に記載の方法。
【請求項９】
各ファイルが対応するファイル名を有し、さらに、
ファイル名が変更される時、もし、新しいファイル名がファイル・システムによると第２メタデータ区画内に入る場合、第１メタデータ区画から第２メタデータ区画へメタデータを移動することを含む請求項１に記載の方法。
【請求項１０】
１つのメタデータ区画から別のメタデータ区画へメタデータを移動させることが、
メタデータを別のメタデータ区画へ移動し、
移動されたメタデータの別のメタデータ区画内の新しい位置を示す転送オブジェクトを１つのメタデータ区画中に置くことを含む請求項５に記載の方法。
【請求項１１】
転送オブジェクトのリストを維持し、そして、所定のポリシーに従い選択された転送オブジェクトを破壊することをさらに含む請求項１０に記載の方法。
【請求項１２】
所定のポリシーが、転送オブジェクトにアクセスした最後の時間を含む請求項１１に記載の方法。
【請求項１３】
メタデータ区画を少なくとも２つの異なるメタデータ区画へ分割することをさらに含む請求項１に記載の方法。
【請求項１４】
複数のファイルを記憶する記憶サービスと、
複数のメタデータ計算資源、及び
各メタデータ計算資源に少なくとも１つが割当てられており、ファイルに対応したメタデータを記憶する複数のメタデータ区画、を含むメタデータ管理システムと、
を備えるシステム。
【請求項１５】
各メタデータ計算資源が、計算マシーン、記憶媒体、及び計算プロセスからなるグループから選択される請求項１４に記載のシステム。
【請求項１６】
メタデータ管理システムがさらに、少なくとも２つのメタデータ区画上に記憶されたメタデータを索引するファイル・システムを含む請求項１４に記載のシステム。
【請求項１７】
記憶サービスはさらに、各々がメタデータ計算資源とは異なる記憶計算資源に割当てられた複数のファイル記憶区画を含む請求項１４に記載のシステム。
【請求項１８】
各メタデータ区画が、ファイル記憶区画に対応し、そして対応するファイル記憶区画に記憶されたファイルについてのメタデータを記憶する請求項１７に記載のシステム。
【請求項１９】
記憶システム内でメタデータを移動する方法であって、
メタデータを、複数のメタデータ区画上に記憶するステップと、
各メタデータ区画へ、第１クラス資源及び第２クラス資源を含む計算資源を割当てるステップと、
メタデータを、所定のポリシーに基づき、第１クラス資源に割当てられた区画から第２クラス資源に割当てられた区画へ移動するステップと、
を含む方法。
【請求項２０】
所定のポリシーが、メタデータに最後にアクセスした時間を含む請求項１９に記載の方法。
【請求項２１】
メタデータが、対応するファイルに関連したファイルハンドルを含み、
メタデータを移動するステップが、古いメタデータ区画から新しいメタデータ区画へ選ばれたメタデータを移動し、そして、選択されたメタデータの新しいメタデータ区画中の場所を示す転送オブジェクトを古いメタデータ区画内に置くことを含む請求項１９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、データ記憶システムに関し、より詳細には、記憶されたファイルに対応したメタデータを含んだ高容量記憶システムに関する。
【背景技術】
【０００２】
高容量データ記憶システムに対する需要は絶えず上昇している。データ・ネットワークの相互接続が続くにつれて、ファイル数が増加するにつれてこのような記憶システムが同時に成長することが可能な効率的な方法で、非常に多数のファイルを記憶する要求が増大している。
【０００３】
さまざまな従来のデータ記憶システムが知られているが、このような手法は常に効率的で、費用効果的で、規模をスケールするのに容易なものではない。通常は、データ記憶システムは、モノリシック・サーバー上に存在している。モノリシック・サーバーは、さまざまな媒体上に記憶できるファイルにアクセスするために専用化された単一の大変強力な計算資源を含むものとして観念化できる。このようなモノリシック・サーバーは記憶されたファイルに対するメタデータの収集を維持できる。
【０００４】
メタデータは、ファイル名、ファイルが置かれたディレクトリ、物理的位置（オフセット）、ファイルの大きさ、ファイルのタイプを含む雑多なファイル情報を含む。通常、メタデータは、高速なルックアップ及び／又はメタデータへのアクセスを可能にするため、プロセスによりアクセスされる単一の区画に存在する。
【０００５】
モノリシック・サーバーの手法の欠点は、このようなシステムを変化する需要に対応させる際に困難性を含む。例えば、記憶されたファイル数、従って、メタデータの量及びメタデータのアクセスは時間と共に増加する。このような需要を満足するために、モノリシック・サーバーはアップグレードされる。処理スピードは計算資源（中央処理ユニット（ＣＰＵ）の数など）及び関連するランダムアクセスメモリ（ＲＡＭ）の増加により改良できるが、このような資源の増加は、ハードウェアのアップグレードがある期間にわたりシステムの非動作を必要とするために、実現が困難となる。
【０００６】
モノリシック・サーバーの手法は、使用の要求が大きくなりすぎる時、好ましくない。２つの例のように、記憶されたデータ量又は要求されるサービス量が、既存のモノリシック・サーバーの応答が非常に遅くなるか又はユーザの要求に合うことができなくなる点まで達する。
【０００７】
増大する要求を満足するための従来の１つの手法は、サーバーを追加することである。このような手法の欠点は、ユーザに複雑性を与えることである。ユーザは、このようなサーバーが典型的に可視的であり、ユーザ・アプリケーションについて別のエンティテイのように複数のサーバーの記録を残さなければならない。さらに、複数のサーバーでは、一つのサーバーが別のよりもよりアクセスされ／記憶する時に負荷のバランスがくずれる。この結果、システム管理者は、使用が変化する時、手動でファイルを移動し及び／又は要求ルーチンを設定しなければならない。これはシステム管理者にとり大変な重荷となる。
【０００８】
複数のサーバーの管理は、１年間、３６５日、２４時間、運転されるミッション・クリティカル又はインターネット・アプリケーションについては、このようなシステムはシステムを再構成又はアップグレードするために利用可能な時間窓を典型的に持たないため、特に困難である。
【０００９】
また、メタデータの大きさの増加は収容することが困難である。より大きい容量のシステムに対する需要が増大するにつれて（例えば、ペタバイト又はより大きいサイズのシステム）、メタデータの量が同様に増加する。しかし、もし、メタデータがモノリシック・サーバーの記憶容量を越える場合、より大きい記憶容量にするためにシステムの変更が行われなければならない。さらに、メタデータの操作（ファイルの削除、名前の変更、移動等など）は、サーバーが管理プロセス中でより大きいメタデータにアクセスできなければならないため、より複雑となる。
【００１０】
多数のファイルを記憶するための１つの手法は、記憶されたファイルを「移動」させることであった。記憶されたファイルの移動は、１つの記憶媒体から別へファイルを移動することを含む。典型的に、「古い」ファイル（ある期間の間、アクセスされていないもの）を、相対的に高速なアクセスで提供できる（従って、より高価であろう）第１記憶媒体から、より遅いアクセスで提供する（従って、より安価であろう）第２記憶媒体へ移動することができる。
【００１１】
ファイルの移動は、多数のデータファイルの解決を与えるが、メタデータの大きさの増大を解決する必要がある。多数のファイルを記憶するデータ記憶システムに対して、メタデータの構成の高度のスケーリング、及び／又は、スケーリングの容易さ、及び／又は柔軟性を可能にし、及び／又はメタデータのより費用効率的な記憶を可能にするメタデータ記憶手法が必要である。
【発明の開示】
【００１２】
１つの実施の形態によると、データ記憶システムは、いくつかの異なるメタデータ区画上にメタデータを記憶するメタデータ管理システムを含む。各区画は特定のシステム資源へ割当てられる。システム資源はその対応するメタデータ区画にアクセスできる。システム資源は、異なるクラスに構成でき、１つのクラスは別のクラスよりも遅いアクセスを与え及び／又は安価であることができる。このような構成は、必要に応じて新しい区画及び／又は資源がメタデータ管理システムに追加できるため、スケーリングを可能にする。
【００１３】
実施の形態の１つの観点によると、１つの資源に割当てられた第１区画上にあるメタデータは第２資源に割当てられた第２区画へ移動できる。
【００１４】
実施の形態の別の観点によると、メタデータは確立されたポリシーに従い移動できる。１つのポリシーでは、あまり使用されないメタデータは、より高価な資源に割当てられた区画から安価な資源に割当てられた別の区画へ移動される。
【００１５】
実施の形態の別の観点によると、メタデータはその対応するファイルが名前を変更される時に移動できる。データ記憶システムは、メタデータを組織するためのファイル・システムなどの組織システムを含むことができる。ファイルが名前を変更される時、そのメタデータは新しいメタデータ区画へ移動される。
【００１６】
実施の形態の別の観点によると、第１区画から第２区画へのメタデータの移動は、メタデータを第２区画へ移動し、そして移動されたメタデータの新しい場所を示す転送オブジェクトを第１区画内に置くことを含む。
【００１７】
〔実施の形態の詳細な説明〕
添付図面を参照して、本発明のさまざまな実施の形態を説明する。さまざまな実施の形態は、異なる区画上に記憶されたメタデータを管理するためのシステムを含む。このようなシステムは、容易且つ費用効率的なスケーリングを可能にし、及び／又は、加齢又は他の基準に従い、メタデータの移動を可能にする。さらに、本発明は、必要により区画が追加、分割、又は融合される時、大量のメタデータのより簡単でより効率的な管理が可能である。
【００１８】
上述したように、従来のファイル記憶システムは、典型的に単一区画上にファイル・メタデータを記憶していた。本発明によると、メタデータ管理システムは、複数の区間にわたって分散できるメタデータを含むことができる。
【００１９】
ＭＤＳブロック図表示
図１を参照すると、本発明によるメタデータ管理システムのさまざまな長所がより良く理解できる。図１は、メタデータ管理システム（ＭＤＳ）１００のブロック図表示を示す。ＭＤＳ１００は、特定のシステム資源１０４−０乃至１０４−５に割当てられた、１０２−０乃至１０２−１１として示すようなさまざまなメタデータ区画を含む。図１は、資源にどれだけ複数の区画が割当てられるかを示す。特に、１つの区画１０２−２がシステム資源１０４−１に割当てられている。２つの区画１０２−０と１０２−１とがシステム資源１０４−０に割当てられている。そして、３つの区画１０２−５乃至１０２−７がシステム資源１０４−３に割当てられている。もちろん、システム資源の特定の数及びシステム資源当たりの区画は、例示のために与えられたものであり、限定するものと解釈すべきではない。
【００２０】
システム資源（１０４−０乃至１０４−５）は、１つ又は複数のクラスに分けることができる。システム資源のクラスは、特定の記憶媒体、マシーンの異なるクラス、及び／又は、異なる実行プロセスを示す。この結果、システム資源の１つのクラスは、別のクラスと較べて、その対応するメタデータ区画へのより高速なアクセスを提供する。追加的に、又は、代替的に、１つのクラスは別のクラスと較べてより低いコストの解決を提供する（すなわち、システム資源の部品コスト及び／又は維持コストが他のシステム資源のそれらと比較して安価である）。
【００２１】
図１に示されるような構成は、資源を記憶された特定のメタデータに対して最適化することができる。例えば、１つの資源が過度に使用されることを防止するために、メタデータがアクセスされる確率に基づいて区画はシステム資源に割当てられることができる。このような利用可能なシステム資源の最適化は増大した性能を与えるだろう。これは、１つのメタデータ区画に適用される単一の高い計算能力資源として観念化できる従来のモノリシック・サーバー手法と対照的である。このような従来の手法では、性能の増強はモノリシック・サーバー・システムへの高価なハードウェア・アップグレードが必要である。
【００２２】
ＭＤＳファイル・システム表示
図１は、ＭＤＳの区画−資源関係の一例を示すが、また、ＭＤＳはファイル・システムに基づいて観念化できる。図２に、このような例が示されている。
【００２３】
図２は、複数の区画（２０２−０乃至２０２−３）にわたり分散されたＭＤＳ２００ファイル・システムを示す。区画２０２−０は、ファイル・システムのより高いレベル部分（例えば、ファイル・システム・ツリーの頂上）を含むことができる。一方、区画２０２−１乃至２０２−３はファイル・システムのより低いレベル部分を含むことができる。
【００２４】
区画（２０２−０乃至２０２−３）の１つ又は複数は特定の資源に割当てることができることが理解される。従来のファイル・システムは、典型的に、互いに関連したさまざまなノードを含む。対照的に、本発明によるＭＤＳ区画（２０２−０乃至２０２−３）は、ノード及び「転送オブジェクト」を含むことができる。
【００２５】
図２では、ノードは円で示されるが、転送オブジェクトは四角形で示されている。ノードは従来のファイル・システムと同じ機能のいくつかを提供する。すなわち、ファイル情報の提供と組織化である。転送オブジェクトはメタデータが複数の区画にわたることを可能にする。
【００２６】
ファイル・システム・ルックアップでアクセスされる転送オブジェクトの一例が、以下に説明される。図２を参照すると、デイレクトリィ・ルックアップなどのルックアップがノード２０４−４にあるファイル情報を検索するために実行されると仮定する。ルックアップはクライアントのために実行される。１つの構成によると、クライアント・メタデータ関連要求は、ＭＤＳシステム要求に翻訳できる。このようなＭＤＳシステム要求は、ＭＤＳ２００との通信を制御するＭＤＳクライアントにより発せられる。
【００２７】
図示された例では、ルックアップは、最高レベルの区画、区画２０２−０中のノード２０４−０で開始される。ルックアップは、ノード２０４−１に進む。しかし、所望のファイル情報が区画２０２−１上に記憶されているため、ルックアップは転送オブジェクト２０６−０へ進むことができる。
【００２８】
転送オブジェクト２０６−０は、区画２０２−１中のノード２０４−２をポイントすることができる。このようにして、本発明によるシステムは複数の区画に広がるファイル・システムを含むことができる。
【００２９】
そして、ルックアップは区画２０２−１中のノード２０４−２で再開されて、ノード２０４−３へ進み、そして、最終的に所望のノード２０４−４へ到達する。
【００３０】
ＭＤＳクライアント等がＭＤＳ２００とインターフェイスするような構成中では、異なる区画へのさまざまなアクセス、及び、複数のＭＤＳ区画の存在は実際にクライアントから完全に隠すことができる。
【００３１】
もちろん、示された特定のデイレクトリィ構造は、本発明を限定するものと解すべきではなく、例示のためにのみ提供されたものであることが理解される。さらに、このようなファイル・システム中のノードはさまざまな形を取ることができる。２つの可能な例として、各ノードはファイルハンドルと対応するファイル属性を含むことができる及び／又は各ノードはファイルハンドルをその対応する属性へのポインタと共に含むことができる。
【００３２】
複数のメタデータ区画にわたって分散されたファイル・システムは、さまざまな形を取ることができる。多くの可能な例の第１として、クライアントはこのようなファイルに対するメタデータを検索するためにファイル名を転送できる。メタデータはさまざまな方法で構成できる。これは、単純なものでは、ファイル名によるアルファベット順に記憶するファイルである。多くの可能な例の第２として、メタデータはファイル属性に基づく機能に従って記憶できる。これは、ハッシュ関数により１つ又は複数のフィールド（例えば、ファイルハンドル）をハッシュし、そして得られた値をどのメタデータ区画にメタデータが記憶されるべきかを決定するために使用する。もちろん、これらの２つの例は本発明を限定するものとして解すべきではない。数多くの他のファイル・システム手法も当業者には明らかである。
【００３３】
ＭＤＳ操作
図３Ａ−３Ｃは、ＭＤＳ１００中で実行できるさまざまな操作の一般的な表示である。図３Ａ−３Ｃは、図１と同じ一般的な項目をいくつか含む。同様な項目には同じ参照符号を付している。
【００３４】
従来は、ファイル・システム・メタデータは単一の区画上に記憶されていた。この結果、このようなファイル・システムのスケーラビリティには限界があった。もし、メタデータの量が利用可能な区画の空間を越えると、現在の区画をより大きな区画と置き換えるために高価及び／又は時間のかかるアップグレード操作が必要である。
【００３５】
従来は、ファイル・システム・メタデータは単一の資源に割当てられていた。この結果、このようなシステムは故障に弱く又は高価な冗長性手法を必要とする。より詳細には、もし、メタデータに割当てられていた単一資源が故障すると、ファイル・システムは故障が解決するまで、動作できない。さらに、このような故障に弱い点を解決するために、全ての現在のメタデータを再生する１つ又は複数の並列バックアップ資源を設けなければならない。このような、従来の構成は故障の場合に管理及び実現するためにより困難となる。
【００３６】
本発明の１つの手法によると、ＭＤＳサーバーは冗長プロセス対で運転される。従って、１つのＭＤＳサーバー・プロセスの故障は別のもので置き換えることができる。さらに、複数のＭＤＳサーバーを含む状態では、このような冗長ＭＤＳサーバー比は、１：１である必要は無い。１つの例としては、第１ＭＤＳサーバーは、アルファベット順に字Ａ−Ｃのメタデータをアクセスする。第２ＭＤＳサーバーは、アルファベット順に字Ｄ−Ｆのメタデータをアクセスする。冗長ＭＤＳサーバーは、字Ａ−Ｆのメタデータをアクセスする。この結果、第１及び／又は第２ＭＤＳサーバーの故障は、冗長ＭＤＳサーバーにより対応できる。
【００３７】
メタデータ資源及び／又はメタデータ区画の追加
本発明によると、区画及び／又は資源が追加できる。このような能力を与えることにより、ＭＤＳはより大きな量のメタデータ及び／又は異なるメタデータ構成／配列を収容するためにスケールできる。モノリシック・サーバー手法では、メタデータのための追加の記憶を収容するためにはサーバー全体を停止しなければならないだろう。さらに、異なるメタデータ構成／配列に対しては、モノリシック・サーバーのソフトウェアはアップグレード及び／又はカスタマイズされる必要があり、また、サーバーの「停止」時間を必要とする。
【００３８】
図３Ａは、区画及び／又はシステム資源がどのようにして追加できるかを示す例を提供する。図３Ａは、２つの新区画１０２−Ｘ及び１０２−Ｙと、新資源１０４−Ｙが追加された後の図１のＭＤＳを示す。
【００３９】
新資源１０４−Ｙは新区画１０２−Ｘに割当てられる。図３Ａの特定の例では、新資源１０４−Ｙはクラス１資源である。さらに、新区画１０２−Ｙは既存の資源１０４−５に割当てられる。これは、もし、システム資源１０４−５が十分に利用されていない場合、特に有利である。図３Ａに示すように、システム資源１０４−５はクラス２資源である。
【００４０】
メタデータ区画の融合及び分割
本発明によるＭＤＳは、メタデータ区画の融合及び／又は分割を可能にすることにより、追加のフレキシビリティを提供する。図３Ｂは、区画１０２−２が２つの区画１０２−２０及び１０２−２１に分割され、そして、区画１０２−７及び１０２−９が融合されて区画１０２−７／９を形成した後の図３Ａのシステムを示す。このような能力は、既存の資源は予期されないファイル活動を解決することができず及び／又は資源を追加するためには停止時間を必要とするために低下した性能をこうむるモノリシック・サーバーの手法とは対照的である。
【００４１】
図３Ｂの例では、区画１０２−２は前に資源１０４−１に割当てられていた。区画は２つの区画１０２−２０及び１０２−２１に分割されて、それぞれ資源１０４−１及び１０４−Ｙに割当てることができる。このような区画分割はさまざまな理由のため発生できる。１つの例としては、区画１０２−２中のメタデータの量及び／又はタイプの大きさが成長し及び／又はより頻繁にアクセスされる。このような大きな大きさ又は増大した資源の需要を収容するために、区画１０２−２０及び１０２−２１が、区画１０２−２の分割により形成される。
【００４２】
もちろん、区画の分割はいつも異なる資源へ分割された区画を割当てることを含むものではない。他の操作は、区画を１つの資源のために分割し、そして、新区画の１つを同じ資源へ割当てることを含む。
【００４３】
図３Ｂの例では、区画１０２−７及び１０２−９はそれぞれ、資源１０４−３及び１０４−４に割当てられていた。区画はさまざまな理由のために、単一の区画１０２−７／９へ融合できる。１つの例では、区画１０２−７及び１０２−９中のメタデータの量及び／又はタイプが、異なる区画であること及び／又は複数の資源を区画に割当てることを正当化しないであろう。区画（１０２−７及び１０２−９）の融合は、資源１０４−３がシステム性能を最適化するその残りの区画へ適用されることを可能にする。
【００４４】
このように、メタデータ区画分割及び融合は、ＭＤＳにフレキシビリティ、スケーラビリティ、及び／又は最適化をさらに提供できる。
【００４５】
メタデータ移動
本発明によるＭＤＳ１００は、所定のポリシーに基づいて、メタデータを異なるシステム資源クラスに移動させることにより、従来手法に較べて資源を最適化できる。このような所定のポリシーは、限定的ではなく、ファイルのアクセス時間、サービスのクライアント品質、区画中のメタデータ・ノードの数、区間中の残余の利用可能な空間の量等を含む。もちろん、このような特定のポリシーは例にすぎず、本発明を限定するために解釈されるべきではない。
【００４６】
特定の１つの例として、ある時間間隔の間にアクセスされなかったメタデータは、より遅くて及び／又はより安価なシステム資源へ移動できる（すなわち、メタデータは「古い」）。これは、同じ資源へ割当てられた単一の成長するメタデータ収集を維持する従来のモノリシック・サーバー手法とは対照的である。図３Ｂ及び図３Ｃは、メタデータ移動操作を示す。
【００４７】
システム資源１０４−０乃至１０４−３及び１０４−Ｙは第１クラス（クラス１）であるが、システム資源１０４−４及び１０４−５は第２クラス（クラス２）である。この例では、第１クラス資源は第２クラス資源よりも高速及び／又は高価であると仮定されている。１つの大変限定された例では、第２クラス資源はより遅い計算マシーンを含み、及び／又は、より遅いプロセスを実行し、及び／又は、動作ではより小さな量のメモリを使用し、及び／又は、データをより遅い又は安価な媒体に記憶する。
【００４８】
図３Ｂは、区画１０２−３中に位置する特定のメタデータ１０６を示す。区画１０２−３は第１クラス資源１０４−２に割当てられている。所定のポリシーに基づいて、特定のメタデータ１０６はより低いクラス資源へ移動される。
【００４９】
図３Ｃでは、特定のメタデータ１０６が第２クラス資源１０４−５に割当てられた区画１０２−１１へ移動されている。さらに、特定のメタデータ１０６の区分１０２−１１中における新しい（移動された）位置へアクセスするための情報を提供する転送オブジェクト１０８を、区画１０２−３内に置くことができる。
【００５０】
もちろん、図３Ｂ及び図３Ｃのメタデータの移動の例は、２つのクラスの資源のみを示している。２つ以上のクラスの資源を含むことができ、さまざまなクラスの資源の中でポリシーに基づいたメタデータの移動が可能である。さらに、典型的な操作では、複数のノードがシステム資源のより効率的な使用のために移動できる。
【００５１】
本発明によるメタデータの移動は、実際のファイルの移動とは独立であることに注意する。より詳細には、ファイルは一組の基準及び／又はポリシーに従いある種の記憶システム中で移動されるが、異なる基準／ポリシーがＭＤＳ１００中のメタデータを移動するために使用できる。
【００５２】
ファイルハンドル進展
区画及びシステム資源に関して、メタデータ・サービス及びさまざまな操作が説明されたが、メタデータを含むファイル・システムについて、本発明を以下に説明する。
【００５３】
前述の通り、メタデータはファイルについての情報を含む。このような情報はファイルに特有な寄せ集められた情報を含む。さらに、各ファイルについてのメタデータは、対応する独特な識別子：ファイルハンドルを持つ。１つの特定の実施の形態では、ファイルハンドルは、不変部分と可変部分とを含む。不変部分は、メタデータが移動及び／又は名前変更を含むいかなる数の理由で移動される時に変化しない独特な識別子を含むことができる。しかし、ファイルハンドルは可変部分も含んでよい。このような可変部分はメタデータが１つのメタデータ区画から別へ移動される時に変化する。
【００５４】
ファイルハンドル進展の言葉は、ここでは、メタデータが移動される時にメタデータ・ファイルハンドルが変化されるプロセスを記述するために使用される。ファイルハンドル進展のさまざまな例を以下に説明する。
【００５５】
メタデータの動き−移動
図４Ａ、図４Ｂ、及び図５を参照すると、メタデータ移動の例が示されている。メタデータ移動の場合、メタデータが異なる区画（例えば、より低いクラス資源へ割当てられた区画）へ移動される間及び後に、ファイルのメタデータがアクセス可能であることを保証することが望ましい。
【００５６】
図４Ａ及び図４Ｂの例は、ファイル・システム・ノード４０２に対するメタデータの１つのクラス（クラス１）の１つの区画４００−１から別のクラス（クラス２）の異なる区画４００−４への移動を表す。ファイル・システム・ノード４０２に対応する情報は、移動された後でも対応するファイル・メタデータがアクセスできるようにするため、変化される。
【００５７】
ノード４０２に対応するメタデータの１つの例が、項目４０４として示されている。メタデータ４０４は、一般にファイルハンドル及び１つ又は複数の関連するファイル属性を含むものとして示されている。特定のメタデータ４０４は、“ｆｉｌｅｈａｎｄｌｅ＿０”のファイルハンドル及び“ａｔｔｒｉｂｕｔｅｓ＿０”の属性を持つ。
【００５８】
図４Ｂを参照すると、ファイルハンドル進展の操作では、ノード４０２に対応するメタデータは区画４００−４へ移動されて、新しいノード４０６へ対応する。さらに、転送オブジェクト４１０は、今、区画４００−１内の前のメタデータ位置に対応する。図４Ｂは「古い」ノードでの転送オブジェクト４１０の１つの例、及び、「新しい」ノード４０６に対応する新しいメタデータ４０８を示す。
【００５９】
図４Ｂの例では、新たに移動されたメタデータ４０８は、新しいファイルハンドル“ｆｉｌｅｈａｎｄｌｅ＿１”を含み、そしてそのファイル属性情報を維持する。新しいファイルハンドル（ｆｉｌｅｈａｎｄｌｅ＿１）はメタデータ４０８の新しい位置を反映することができる。
【００６０】
転送オブジェクト４１０は、いくつかの機能を提供する。図４Ｂの特定の例では、転送オブジェクトは、新しいファイルハンドル（ｆｉｌｅｈａｎｄｌｅ＿１）を戻して、これによりサービスが新しいメタデータ位置にアクセスすることができる。さらに、転送オブジェクトは、メタデータが移動されたことを示す特定のメッセージ（例えば、エラー・メッセージ）を戻すことができる。１つの特定の例では、ＭＤＳクライアントは転送オブジェクト・エラーを取扱うことができ、複数区画へアクセスして、クライアントに複数のアクセスを見えることなく所望のメタデータを提供する。
【００６１】
図５は、ファイルハンドル進展の特定の例を与える。図５は、区間の間の動き（例えば、移動に起因する）の前のメタデータに対応する第１ファイルハンドル５００を含む。第２ファイルハンドル５０２は区間の間の対応するメタデータの動きの後のファイルハンドルに対応する。
【００６２】
ファイルハンドル（５００及び５０２）は、特定のフィールドを持つが、本発明を限定するものとして解すべきではない。ファイルハンドルのフィールドは、ファイルハンドル・タイプ・フィールド（ｆｔｙｐｅ）、ファイル・システムｉｄフィールド（ｆｉｌｅｓｙｓ＿ｉｄ）、システム割当て識別子フィールド（ｓｙｓｔｅｍ＿ｉｄ）、ファイル識別子フィールド（ｆｉｌｅ＿ｉｄ）、区画識別子（ｐａｒｔ＿ｉｄ）、及び、デイレクトリィ識別子（ｄｉｒ＿ｉｄ）を示す。
【００６３】
ｆｔｙｐｅフィールドは、メタデータに対応するファイルの特定のタイプを示す（例えば、標準、デイレクトリィ等）。ｓｙｓｔｅｍ＿ｉｄフィールドは、システムによりファイルに割当てられた独特な値を示す。ｆｉｌｅ＿ｉｄは、特定のファイルを識別するための独特な値を示す。ｆｉｌｅｓｙｓ＿ｉｄフィールドは、特定のファイル・システム・タイプ（例えば、Ｕｎｉｘ又はＮＦＳ）を識別する。ｆｉｌｅｓｙｓ＿ｉｄ及びｆｉｌｅ＿ｉｄフィールドは、ファイルハンドルの不変部分である。
【００６４】
また、ファイルハンドル５００及び５０２は、可変部分を持つ。図５に示された特定の例では、可変部分は、ｐａｒｔ＿ｉｄ、ｄｉｒ＿ｉｄ、及び、ｆｔｙｐｅフィルードデアル。図５の特定のファイルハンドル進展は、図４Ａ及び４Ｂに示される操作に対応する。すなわち、メタデータの動きで、ｐａｒｔ＿ｉｄは、０００１（区画４００−１に対応する）から０００４（区画４００−４に対応する）に変化する。メタデータ（５００及び５０２）はファイル・システムと同じ論理的関係を維持するため、ｄｉｒ＿ｉｄ値は不変のままである。
【００６５】
メタデータ動き−名前変更
図６Ａ及び図６Ｂの例は、特定のファイルの名前変更を示し、ファイル・システム・ノード６０２が１つの区画６００−１から他の区画６００−４へ移動される結果を生ずる。ファイル・システム・ノード６０２と関連したデータは、ファイルが名前を変更された後でも対応するファイル・メタデータがアクセスできるようにするため、変化される。図４Ａ及び図４Ｂに示される移動の例のように、ファイルハンドルは、名前変更の前に１つの値（ｆｉｌｅｈａｎｄｌｅ＿０）、及び名前変更の後に別の値（ｆｉｌｅｈａｎｄｌｅ＿ｎ）を持つ。さらに、「古い」ノードに対応する転送オブジェクト６１０が生成される。
【００６６】
図７は、名前変更前の古いファイルハンドル７００及び名前変更後の新しいファイルハンドル７０２の特定の詳細な例を提供する。ファイルハンドル７００及び７０２は、図５に示されるものと類似している。しかし、図５と異なり、新ファイルハンドル７０２は、ファイル・システム中での新メタデータの論理的位置を反映して、１つのデイレクトリィ値（０００Ｃ２３１Ａ）から別（０００Ｃ８ＤＦ９）へ変化するｄｉｒ＿ｉｄフィールドを含む。
【００６７】
１つの実施の形態では、転送オブジェクト（図６Ｂの６１０など）は、一時的である。すなわち、特定の所定のポリシーによる転送オブジェクトは破壊できる。
【００６８】
図８には、転送オブジェクトの破壊を達成するための多くの可能な方法の１つが示されている。図８は、転送オブジェクト・テーブルの１つの例を示す。このようなテーブルは現在の全ての転送オブジェクトを監視し、そして、所定のポリシーに従い、転送オブジェクトを破壊する。図８の１つの例は、転送オブジェクトｉｄ欄と監視欄とを示す。監視欄は、転送オブジェクトが破壊できるかどうか／何時破壊できるかを決定するために監視されるデータを含む。
【００６９】
転送オブジェクトが破壊できるかどうかを決定するために使用される多くのポリシーの内の１つは、転送オブジェクトの「古さ」である。もし、転送オブジェクトがある時間量よりも長く存在する場合、転送オブジェクトは破壊される。もちろん、さまざまな他のポリシーが古さに代えて又は加えて使用できる。いくつかの例では、転送オブジェクトはアクセスが頻繁でないことに基づいて破壊され、全ての転送オブジェクトは周期的態様で破壊でき、又は、転送オブジェクトは区画ごとに基づいて同時に破壊できる。これらの同じ線に沿って、転送オブジェクト中の情報を所定の基準と比較できる機能が呼出されて、そして、比較結果に依存してオブジェクトを破壊する。
【００７０】
上記の例は、区画間のメタデータの移動に起因した単一ファイルハンドルの進展を説明しているが、当業者には明らかなように複数のファイルに対応するメタデータは一緒に動く。図９Ａ及び図９Ｂは、メタデータのグループの動きの１つの表示を示す。
【００７１】
図９Ａ及び図９Ｂは、各々が特定のメタデータに対応したさまざまなノードを持つファイル・システムの表示である。ノードは、さまざまな区画（９００−１乃至９００−３）にわたって分散されるものとして観念化できる。図９Ａでは、ノード９０２のグループに対するメタデータは、区画９００−２内にある。図９Ｂでは、グループ９０２に対するメタデータは、新しいグループ９０２’を形成するために、区画９００−２から区画９００−３へ移動される。また、転送オブジェクト９０４は、古いグループ９０２に対応する最高のデイレクトリィ位置と関連付けられる。
【００７２】
前の例で示されたように、転送オブジェクト９０４は、移動されたグループ９０２’のメタデータをアクセスできる情報を含む。これは論理パス９０６により表示されている。
【００７３】
また、図９Ｂは、名前変更の場合を表す新しい論理パス９０８を含み、ここでは、新グループ９０２’はファイル・システム内で新しい関係を持つ。移動操作の場合は、このような新論理パス９０８は存在しない。新グループ９０２’のノードに対応したファイルハンドルは、新区画（９００−３）を表すために変化される。名前変更操作の場合は、ファイルハンドルは新デイレクトリィ情報を反映するために変化される。
【００７４】
ＭＤＳインターフェイス及び機能
図１０は、ＭＤＳ１００の１つの実施の形態のブロック図を示す。ＭＤＳ１００は、さまざまな資源と区画１００２を含む。資源と区画１００２は、記憶システムのためのファイル・システム１００４とメタデータ１００６を含む。メタデータ１００６は、ファイル属性とファイルハンドルを含む。
【００７５】
また、ＭＤＳ１０００は、メタデータの要求／アクセスに応答して、１つ又は複数の機能を呼出すインターフェイス１００８を含む。インターフェイスが従来の手法と異なる態様の１つは、さまざまな機能が特定の区画値を含む入力値としてファイルハンドルを受取ることである。さらに、機能の実行は所望の区画にアクセスして、そして特定のメタデータ操作を実行することを含む。これは、メタデータの単一区画をアクセスしそして複数のメタデータ区画から１つのメタデータをアクセスすることにより動作する機能を含まない従来のモノリシック・サーバーの手法とは対照的である。
【００７６】
インターフェイス１０８により実行される機能の特定の例は、図１１Ａ、図１１Ｂ及び図１２中に示されている。図１１Ａ及び図１１Ｂは、区画ｉｄデータを含む入力値を利用する機能を示す。特に、特定のファイルに対するファイルハンドル値又はデイレクトリィ値は、機能への入力となることができる。そして、機能はこれらの値を特定の区画をアクセスして、特定の操作を実行するために使用する。図１１Ａ、図１１Ｂ及び図１２は、擬似コードを示している。
【００７７】
図１１Ａに示すように、ＧｅｔＡｔｔｒｉｂｕｔｅｓ機能は、ファイルハンドル値を入力してファイルハンドルに対応した属性を出力する。このような機能は、入力ファイルハンドルにより示された区画をアクセスして、その区画に位置するファイルハンドルに対応するメタデータへアクセスする。そして、属性は返却値として出力される。ＳｅｔＡｔｔｒｉｂｕｔｅｓ機能はファイルハンドル値及び一組の属性（ｎｅｗ＿ａｔｔｒｉｂｕｔｅｓ）を入力する。ファイルハンドルに対するメタデータを含んだ区画がアクセスでき、そしてメタデータは新しい組の属性を含むために変化される。そして、新属性は対応するファイルハンドル及びファイル名と一緒に出力される。
【００７８】
ＣｒｅａｔｅＭｅｔａｄａｔａ機能は、新しいファイルに対する親デイレクトリィ、ファイル名、及び属性を入力する。新メタデータは、親デイレクトリィ中の新ファイル名の位置に従って生成できる。ファイルハンドルが、メタデータのために生成できる。このようなファイルハンドルは、メタデータのための位置を示すメタデータ区画情報を含む。そして、新ファイルハンドル及び属性は新ファイル名と一緒に出力できる。
【００７９】
ＲｅｍｏｖｅＭｅｔａｄａｔａ機能は、システムからメタデータを除去するために使用できる。メタデータは、入力ファイルハンドルに従いその区画上に位置する。そして、対応する属性が読み出される。そして、メタデータが削除されて、ファイル・システムがこのような削除を反映するために改訂される。フラグがメタデータの削除を示すために設定される。フラグ及び読み出された属性が出力される。ＲｅｍｏｖｅＭｅｔａｄａｔａ機能は実際には最初にメタデータを削除しないことに注意する。１つの例では、ＲｅｍｏｖｅＭｅｔａｄａｔａ機能は、削除されるべきメタデータのリストを維持する。メッセージ（すなわち、別の機能等により）がメタデータに対応したファイルが削除されたことを示す時、対応するメタデータはそのメタデータ区画から削除される。
【００８０】
ＲｅｍｏｖｅＮａｍｅ機能は、複数のリンクを含むファイルに対するメタデータを削除するために使用できる。ＲｅｍｏｖｅＮａｍｅ機能は、入力としてデイレクトリィ値及びファイル名を受取ることができる。削除されるべきファイルに対するメタデータは、デイレクトリィ及びファイル名情報と共に位置することができる。もし、メタデータが除去されると、操作が完了したことを示すフラグが戻される。それ以外は、属性、ファイルハンドル、及びファイル名が戻される。
【００８１】
図１１Ｂを参照すると、ＲｅｎａｍｅＦｉｌｅ機能が、ファイルの名前が変更された時にメタデータを変えるために使用できる。名前変更（ｏｌｄ＿ｆｉｌｅｈａｎｄｌｅ）及び古いファイル名（ｏｌｄ＿ｆｉｌｅｎａｍｅ）の前のファイルのファイルハンドルは、名前変更されるべきファイルのメタデータにアクセスするために使用できる。新ファイル名（ｎｅｗ＿ｆｉｌｅｎａｍｅ）及び新親デイレクトリィ（ｎｅｗ＿ｐａｒｅｎｔ＿ｄｉｒｅｃｔｏｒｙ）は、新しい名前の下でのメタデータのための新位置を決定するために入力できる。そして、新ファイルハンドルが新しい名前に基づいて生成される。上述したように、ファイル名の変化は、区画ｉｄ値に変更を持つファイルハンドルを生ずる。そして、新ファイルハンドルが対応する属性と一緒に出力されることができる。
【００８２】
ＣｒｅａｔｅＬｉｎｋ機能は、ファイルとデイレクトリィ（ｎｅｗ＿ｐａｒｅｎｔ＿ｄｉｒｅｃｔｏｒｙ）の間のハード・リンクを確立するために使用できる。リンクはデイレクトリィ中にファイル名（ｌｉｎｋ＿ｆｉｌｅｎａｍｅ）の下で生成される。そして、リンクされたファイルのためのメタデータは、対応するファイル名及びファイルハンドルと一緒に出力される。
【００８３】
このように、入力値に従いさまざまな機能が特定の区画をアクセスして、区画のメタデータ上の操作を実行する。
【００８４】
図１２を参照すると、ＲｅａｄＤｉｒｅｃｔｏｒｙ機能が、識別されたデイレクトリィ中に含まれるメタデータを読み出すために使用できる。デイレクトリィ値はデイレクトリィを識別するための入力である。さらに、カウント値及び最終エントリイ値（ｌａｓｔ＿ｅｎｔｒｙ＿ｒｅａｄ）も入力である。カウント値は、検索されるメタデータ・エントリイの数を示す。カウント値は最初に１であるが、デイレクトリィが単一機能では読み出すことができず、そして機能が一度よりも多く呼出される場合は、異なる値である。
【００８５】
デイレクトリィは、入力デイレクトリィ値に従いアクセスされる。機能が最初に呼出されている場合、カウント値に等しい長さを持つメタデータ属性リストが形成できる。デイレクトリィ中の全てのエントリイに対する属性がリストに適合する場合、フラグ（ｃａｌｌ＿ｆｕｎｃｔｉｏｎ＿ａｇａｉｎ）は、機能が二度呼ばれる必要がないことを示す値に設定される。もし、カウント値よりも多くの属性が存在する場合、フラグは機能が再び呼出されなければならないことを示す別の値に設定できる。さらに、最終エントリイ値（ｌａｓｔ＿ｅｎｔｒｙ＿ｒｅａｄ）は、前の機能の呼出しが停止した所からその後の機能呼出しが開始できるように戻される。
【００８６】
ルックアップ及びマルチルックアップ機能は、特定のファイル名又は複数のファイル名に対応した属性を検索するために使用される。親デイレクトリィ値はファイル名又は複数ファイル名と一緒に入力される。そして、ファイル名に対応した属性が出力される。
【００８７】
このようにして、ファイル・システムが特定ファイルのためのメタデータを検索するためにアクセスされる（例えば、デイレクトリィ構造を経由して）。従来の手法とは異なり、メタデータは異なるメタデータ区画から検索できる。
【００８８】
もちろん、上述の機能は、ＭＤＳインターフェイスにより提供される１つの特定の組の機能及び特定の例を表す。
【００８９】
ＭＤＳを含むシステムの例
図１３を参照すると、１つの実施の形態によるメタデータ管理システム（ＭＤＳ）を含むデータ記憶システムの一例を表すブロック図が示されている。データ記憶システムは、一般的に参照符号１３００により示され、ゲートウェイ・サービス１３０２、ＭＤＳ１３０４、及び記憶サービス１３０６を含むいくつかのサブシステムに分割されている。記憶サービス１３０６は、さらに、ビットファイル管理サービス（ＢＭＳ）１３０６−０、及び、ビット記憶サービス（ＢＳＳ）１３０６−１を含む。
【００９０】
ファイルは、ＢＳＳ１３０６−１により記憶される。ＢＭＳ１３０６−０は、ファイルへのアクセスを管理する。ＭＤＳ１３０４は、ＢＳＳ１３０６−１中に記憶されたファイル対応するメタデータを記憶する。このようなメタデータは、限定的ではなく、ファイルハンドルなどの独特なファイル識別情報を含む。さらに、このようなメタデータはまた、データファイルの位置を識別するために他のシステムにより使用できる他の情報を含む。上述の通り、このような情報は、ファイルが移動され、名前が変更され、又は、それ以外の操作をされる場合に変更できる。
【００９１】
前述のように、ＭＤＳ１３０４は、複数の区画又はメタデータの複数の区画を収容する能力を含む。さらに、特定の実施の形態では、ＭＤＳ１３０４は、データファイルを生成し、削除し、そして名前変更すること、及び、データ記憶システム１３００全体に記憶されているデータファイルのさまざまな属性をアクセスすることを含むさまざまなファイル関連機能を実行するためのインターフェイスを含む。従来のモノリシック・サーバー手法とは異なり、ＭＤＳ１３０４はメタデータ要求及び機能をサービスする緩やかに結合されたサーバーの集まりを含み、ＭＤＳ中のサーバーはメタデータに対応するファイルへのアクセスを提供する記憶サービス１３０６中に位置するこれらのサーバーからは分離されている。
【００９２】
前述したように、ＭＤＳ１３０４は、複数の区画にわたり分散されたメタデータを含む。複数区画は、図１３中に、項目１３０８−０乃至１３０８−４により図式的に表示されている。区画は、データブロック、ファイル、及び、さまざまに異なるタイプの媒体上のデータベースとして存在することが理解できる。長所として、システム資源はさまざまな区画へ割当てられて、そして、また、さまざまである。システム資源は、物理的マシーン、記憶媒体空間、及び、特定のプロセスを含む。このようなプロセスは、メタデータにアクセスし及び／又は操作するためのさまざまな機能を含む。
【００９３】
１つの実施の形態によると、ゲートウェイ・サービス１３０２は、クライアントからさまざまな要求を受取る。メタデータ関連要求は、それ自身のサーバーと複数の区画との組を含むＭＤＳ１３０４によりサービスされることができる。実際のファイル関連サービス（例えば、読出し、書込み等）は、ＭＤＳ１３０４のそれらから分離されたサーバーと区画とを含む、記憶サービス１３０６によりサービスされる。図１３の例では、ゲートウェイ・サービス１３０２は、１つの例として、インターネットなどのネットワーク１３１０を介してクライアント要求を受取る。
【００９４】
図１３の例は、独立の記憶サービスから本質的に「切離された」メタデータ管理システム（ＭＤＳ）を説明したが、代替的な実施の形態ではメタデータとメタデータに対応するファイルとの間のより詳細な通信を含むことができる。図１４にこのような例が示されている。
【００９５】
図１４は、メタデータ及び対応するファイルが、同じ「粒状性」で管理される代替的な実施の形態を示す。図１４は、メタデータ管理システム（ＭＤＳ）１４０２及び対応する記憶サービス１４０４を持つシステム１４００を含む。他のシステム・コンポーネント（ゲートウェイなど）は、図面が混雑するのを避けるために除かれている。ＭＤＳ１４０２及び記憶サービス１４０４は、対応する区画へさまざまなシステム資源を提供する独立なサーバーであることができる。メタデータ区画は、図１４中に、項目１４０６−０乃至１４０６−４により表される。ファイル記憶区画は、項目１４０８−０乃至１４０８−４により表される。各メタデータ区画について、対応するファイル記憶区画が存在するため、同一の粒状性が存在する。メタデータ区画とファイル記憶区画との間の対応は、点線１４１０−０乃至１４１０−４により示される。
【００９６】
図１４のような構成では、１つのメタデータ区画から別へのメタデータ移動は、対応するファイル記憶区画間で移動される対応するファイルを必要とする。
もちろん、図１４は、本発明による多くの可能な変形の１つのみを表している。
【００９７】
好適な実施の形態について詳細に説明したが、本発明の精神と範囲を逸脱することなく本発明はさまざまな変形、置換、及び修正が可能である。従って、本発明は特許請求の範囲のみにより定義されて限定されることを意図している。
【図面の簡単な説明】
【００９８】
【図１】本発明の１つの実施の形態によるメタデータ管理システム（ＭＤＳ）を示すブロック図。
【図２】本発明の１つの実施の形態によるファイル・システムを示す図。
【図３Ａ】図１の実施の形態のＭＤＳ中で実行されるさまざまな操作を示すブロック図。
【図３Ｂ】図１の実施の形態のＭＤＳ中で実行されるさまざまな操作を示すブロック図。
【図３Ｃ】図１の実施の形態のＭＤＳ中で実行されるさまざまな操作を示すブロック図。
【図４Ａ】メタデータ移動操作を示す図。
【図４Ｂ】メタデータ移動操作を示す図。
【図５】メタデータ移動操作のためのファイルハンドルの進展を示す図。
【図６Ａ】ファイル名前変更操作を示す図。
【図６Ｂ】ファイル名前変更操作を示す図。
【図７】ファイル名前変更操作のファイルハンドルの進展を示す図。
【図８】１つの実施の形態による転送オブジェクト・テーブルのブロック図。
【図９Ａ】メタデータのグループの区画間の移動を表す図。
【図９Ｂ】メタデータのグループの区画間の移動を表す図。
【図１０】別の実施の形態によるＭＤＳのブロック図。
【図１１Ａ】ＭＤＳインターフェイス中に含まれるある機能の例を示す図。
【図１１Ｂ】ＭＤＳインターフェイス中に含まれるある機能の例を示す図。
【図１２】ＭＤＳインターフェイス中に含まれる他の機能の例を示す図。
【図１３】１つの実施の形態によるＭＤＳを含むシステムの例を示す図。
【図１４】１つの実施の形態によるＭＤＳを含む代替的なシステムの例を示す図。
【図１】
2005530242.tif 000003
【図２】
2005530242.tif 000004
【図３Ａ】
2005530242.tif 000005
【図３Ｂ】
2005530242.tif 000006
【図３Ｃ】
2005530242.tif 000007
【図４Ａ】
2005530242.tif 000008
【図４Ｂ】
2005530242.tif 000009
【図５】
2005530242.tif 000010
【図６Ａ】
2005530242.tif 000011
【図６Ｂ】
2005530242.tif 000012
【図７】
2005530242.tif 000013
【図８】
2005530242.tif 000014
2005530242.tif 000015
【図１０】
2005530242.tif 000016
2005530242.tif 000017
2005530242.tif 000018
【図１２】
2005530242.tif 000019
【図１３】
2005530242.tif 000020
【図１４】
2005530242.tif 000021
【国際調査報告】
2005530242.tif 000022