(57)【特許請求の範囲】
【請求項１】
有限の耐久性および／または持続性を有する複数のメモリ装置からモニタ・データの情報を収集するステップであって、前記モニタ・データは、（１）既知の書き込みサイクルの数の専用メモリ・セルに格納された既知の内容のデータであり、且つ、（２）前記モニタ・データを有する少なくとも１つのブロックの少なくとも一部分がユーザ・データによって上書きされないように書き込み保護される、前記収集するステップと、
前記モニタ・データの情報を分析するステップと、
前記分析するステップに基づいて、前記メモリ装置の少なくとも１つに関してアクションを取るステップと
を含む方法。
【請求項２】
前記モニタ・データを生成するステップを更に含む、請求項１に記載の方法。
【請求項３】
前記モニタ・データの情報は、前記モニタ・データのデータ・エイジおよび前記書き込みサイクルの数の少なくとも一方に関するエラー率情報を含む、請求項１又は２に記載の方法。
【請求項４】
前記収集するステップおよび前記分析するステップを少なくとも２回行うステップと、
それに基づいて統計的傾向を生成するステップと
を更に含む、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記収集するステップおよび前記分析するステップを少なくとも２回行うステップと、
前記モニタ・データの時間依存度を追跡するステップと、
を更に含む、請求項１〜４のいずれか一項に記載の方法。
【請求項６】
前記アクションを取るステップは前記メモリ装置の少なくとも１つに関する動作目標を設定するステップを含む、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記動作目標は、データ書き込みサイクルの数に関する限界、又は、データ・エイジに関する限界である、請求項６に記載の方法。
【請求項８】
所定の期間が経過した後、前記メモリ装置の少なくとも１つに関する動作目標を更新するステップ
を更に含む、請求項６又は７に記載の方法。
【請求項９】
前記モニタ・データはウェアレベリングの影響を受けない、請求項１〜８のいずれか一項に記載の方法。
【請求項１０】
前記メモリ装置はＮＡＮＤ装置である、請求項１〜９のいずれか一項に記載の方法。
【請求項１１】
前記モニタ・データは前記メモリ装置の各々に関するメモリ容量の約１％よりも少ない、請求項１〜１０のいずれか一項に記載の方法。
【請求項１２】
前記メモリ装置の各々におけるモニタ・データは複数のブロック・グループに書き込まれ、各グループに対して行われる書き込みサイクルの数は異なる、請求項１〜１１のいずれか一項に記載の方法。
【請求項１３】
コンピュータに、請求項１〜１２のいずれか一項に記載の方法の各ステップを実行させる、コンピュータ・プログラム。
【請求項１４】
システムであって、
有限の耐久性および／または持続性を有する複数のメモリ装置であって、
前記メモリ装置の各々は、
複数のメモリ・ブロックであって、前記メモリ・ブロックの少なくとも１つがモニタ・データを書き込まれており、少なくとも１つのメモリ・ブロックが前記モニタ・データを書き込む前に複数回書き込まれており、前記モニタ・データは、（１）既知の書き込みサイクルの数の専用メモリ・セルに格納された既知の内容のデータであり、且つ、（２）前記モニタ・データを有する少なくとも１つのブロックの少なくとも一部分がユーザ・データによって上書きされないように書き込み保護される、前記複数のメモリ・ブロックと、
前記メモリ・ブロックをアドレスするための回路と
を備えている、前記メモリ装置と、
前記メモリ装置に接続されたプロセッサであって、前記メモリ装置から前記モニタ・データの情報を収集し、前記モニタ・データの情報を分析し、及び前記分析するステップに基づいて、前記メモリ装置の少なくとも１つに関してアクションを取るように構成されている前記プロセッサと
を備えている、前記システム。
【請求項１５】
前記モニタ・データのコピーを格納する第二メモリを更に含む、請求項１４に記載のシステム。
【請求項１６】
前記モニタ・データの情報は、前記モニタ・データのデータ・エイジおよび前記書き込みサイクルの数の少なくとも一方に関するエラー率情報を含む、請求項１４又は１５に記載のシステム。
【請求項１７】
前記モニタ・データはウェアレベリングの影響を受けない、請求項１４〜１６のいずれか一項に記載のシステム。
【請求項１８】
前記メモリ装置はＮＡＮＤ装置である、請求項１４〜１７のいずれか一項に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にはメモリ装置に関し、詳しく云えば、有限の耐久性および／または持続性を有するメモリ装置からのモニタ・データの情報の分析に関するものである。
【背景技術】
【０００２】
ＮＡＮＤフラッシュ・メモリ装置のような幾つかのメモリ装置は、有限の書き込み／消去耐久性および／または制限されたデータ持続性を有する。そのようなメモリの現在の有用性および信頼性を評価するためには、多くの場合、書き込み／消去の耐久性および／またはデータ持続性を追跡することが望ましい。しかし、提案されている解決策は、そのようなメモリ装置に関連したこれらのおよび／または他の問題点に対する満足すべき解決策は提供するものではない。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明の目的は、上記のようなメモリ装置に関連した問題点に対する満足すべき解決策を提供することにある。
【課題を解決するための手段】
【０００４】
１つの実施例による方法は、有限の耐久性および／または持続性を有する複数のメモリ装置からモニタ・データの情報を収集するステップであって、そのモニタ・データは既知の書き込みサイクルの数の専用メモリ・セルに格納された既知の内容のデータである、前記収集するステップと、そのモニタ・データの情報を分析するステップと、その分析するステップに基づいてメモリ装置の少なくとも１つに関してアクションを取るステップとを含む。
【０００５】
１つの実施例によるコンピュータ・プログラムは、コンピュータ使用可能プログラム・コードを組み込んだコンピュータ使用可能媒体に含まれる。コンピュータ使用可能プログラム・コードは、有限の耐久性および／または持続性を有する複数のメモリ装置から収集するように構成されたコンピュータ使用可能プログラム・コードであって、そのモニタ・データは既知の書き込みサイクルの数の専用メモリ・セルに格納された既知の内容のデータである、コンピュータ使用可能プログラム・コードと、そのモニタ・データの情報を分析するように構成されたコンピュータ使用可能プログラム・コードと、その分析するステップに基づいてそれらのメモリ装置の少なくとも１つに関してアクションを取るように構成されたコンピュータ使用可能プログラム・コードと、を含む。
【０００６】
別の実施例による方法は、有限の耐久性および／または持続性を有する複数のメモリ装置からモニタ・データの情報を収集するステップであって、そのモニタ・データは既知の書き込みサイクルの数の専用メモリ・セルに格納された既知の内容のデータである、ステップと、そのモニタ・データの情報を分析するステップと、その分析するステップに基づいてメモリ装置の少なくとも１つに関して動作目標を設定するステップと、を含む。
【０００７】
更に別の実施例によるシステムは、有限の耐久性および／または持続性を有する複数のメモリ装置を含み、そのメモリ装置の各々は、複数のメモリ・ブロックを有し、それらのメモリ・ブロックの少なくとも１つがそこにモニタ・データを書き込まれており、その少なくとも１つのメモリ・ブロックがモニタ・データを書き込む前に複数回も書き込まれており、更にそのメモリ装置の各々はそれらのメモリ・ブロックをアドレスするための回路を含む。そのシステムは、更に、メモリ装置とコミュニケーション状態にあるプロセッサおよびそのプロセッサとコミュニケーション状態にあるクロックを含む。
【０００８】
本発明の他の側面および利点が、以下の詳細な記述から明白になるであろう。それらの記述は、それが図面と関連して解釈されるとき、１つの例として本発明の原理を説明するものである。
【図面の簡単な説明】
【０００９】
【図１】１つの実施例に従って、フラッシュ・メモリ装置の少なくとも１つのブロックに関する持続動作を決定する方法のフローチャートである。
【図２】１つの実施例に従って、フラッシュ・エラー率面の形を示す代表的なプロット図を示す概略図である。
【図３】１つの実施例に従って、所与のブロックが、或るデータ・エイジにおける消滅により、セクタ・レベルのエラー訂正コード（ＥＣＣ）の訂正能力を超える可能性を表す例示的な累積分布関数（ＣＤＦ）を表わすグラフである。
【図４】１つの実施例に従って、或るデータ・エイジにおけるアクセス分布およびＣＤＦの間のオーバーラップを表わすグラフである。
【図５】１つの実施例に従って、或る時点におけるユーザ・データおよびモニタ・データに関する代表的なサイクルの数・ヒストグラムを示すグラフである。
【図６】モニタ・データ・システムからの１つの可能な測定セットを示すグラフである。
【図７】１つの実施例に従って、複数のフラッシュ・メモリ装置からのモニタ・データの情報を分析する方法を示すフローチャートである。
【図８】１つの実施例に従って、代表的なストレージ・システムを示すブロック図である。
【図９】１つの実施例に従って、結果を表わすグラフである。
【図１０】１つの実施例に従って、ネットワーク・アーキテクチャーを示す概略図である。
【図１１】１つの実施例に従って、図１０のサーバおよび／またはクライアントに関連付け得る代表的なハードウェア環境を示すブロック図である。
【発明を実施するための形態】
【００１０】
本明細書において開示される方法およびシステムは、有限の耐久性および／または持続性を有する任意のタイプのメモリ装置に関連して具現化され得るし、或いはそのようなメモリ・システムを含み得る。有限の書き込み／消去の耐久性または限定されたデータ持続性を有する説明上のタイプのメモリ装置は、フラッシュ・メモリ、相変化メモリ、強誘電体メモリ等を有する装置を含む。
【００１１】
本明細書に示された教示事項の理解を容易にするために、または、それらの教示事項を背景に置くために、説明の多くがフラッシュ・メモリに関して示され、これは単に例として行われるに過ぎず、限定事項として解釈されるべきではないことは当然である。
【００１２】
ＮＡＮＤフラッシュ・メモリ装置は、有限の書き込み／消去の耐久性および限定されたデータ持続性の両方を有する。破損（wearout）および持続を検知するための現在の技法は、情報技術（ＩＴ）および或る消費者アプリケーションにとって不十分な逃げ（escape）率を持つ。逃げという帰結が厳しいこともある。例えば、逃げによってデータが化ける（corrupt）ことがある。
【００１３】
フラッシュ・メモリにおけるエラー率は、それが書き込みサイクルの数およびデータのエイジの両方に依存するので、３Ｄ面となる。例えば、図２およびそれに関する説明を参照されたい。セルが完全な故障に追い込まれることがあるので、エラー率は、任意のセクタ・レベルのエラー訂正コード（ＥＣＣ）の検知能力を超えることがある。これは、化けた（corrupt）データがその後の読み取りオペレーションにおいて有効なものとして送られるという結果を生じ得る。
【００１４】
或る場合には、ＮＡＮＤ記憶装置は、最初の損耗事象に至るまでの時間を増加させるために或る形式のウェアレベリング（wear leveling，以下、損耗均等化又は損耗の均等化ともいう）を実施し得る。複数のブロックが同時に破損に近づくことがあるので、そのような方法の副次的影響はウェア・クラスタリング（wear clustering，以下、破損の群生化ともいう）を更に強めるということである。わずかなエラー率をモニタするためにセクタＥＣＣを使用することはエイリアシング（aliasing）効果に見舞われることがあり、破損の開始を検知する能力が制限されることがある。
【００１５】
破損を検知するための或る他の技術は同様に精度を欠いている。これらは、成功した消去および成功したプログラミングに関してテストすることを含む。これらの技法は、データ持続時間が１００ｎｓ以下のオペレーション検証時間よりも長いが、１５桁の大きさの広がりである状況を３ｘ１０１７ｎｓ（１０年以下の）という上記の耐久時間よりもかなり短い、という状況を検知し得ない。本明細書において提供される少なくともいくつかの実施例は、フラッシュ・メモリ装置の持続の具合（retention behavior）を決定するための技法を提供することによって、これらおよび他の制限に対処する。
【００１６】
図１は、１つの実施例に従って、フラッシュ・メモリ装置の少なくとも１つのブロックに関して持続の具合を決定する方法１００を示す。図示のように、モニタ・データがフラッシュ・メモリ装置の少なくとも１つのブロックに書き込まれる。オペレーション１０２を参照されたい。
【００１７】
フラッシュ・メモリ装置は、メモリのブロックを含む任意のフラッシュ・メモリ装置を含み得る。例えば、１つの実施例では、フラッシュ・メモリ装置はＮＡＮＤ装置であってもよい。
【００１８】
この説明に関連して、モニタ・データによって使用されるデータ・パターンは、知られている任意のデータまたはデータ・パターンを指し得る。例えば、１つの実施例では、モニタ・データは、メモリ・システム、メモリを含むシステム、または別のホスト・システムに知られている値全体を有するデータ・パターンを含み得る。この場合、数、ロケーション、およびパターンによってエラーを特徴づけることが可能である。
【００１９】
更に、１つの実施例では、モニタ・データは生成され得る。この場合、モニタ・データはユーザ・データとして送られるのではなく、ホスト・システムによって内部的に生成され得る。モニタ・データは、いずれの損耗の均等化も回避して、物理ブロックに書き込まれ得る。この方法では、モニタ・データは損耗の均等化を受け得ない。
【００２０】
更に、少なくともブロックの２つが、例えば、フラッシュ・メモリ装置の種々な領域の具合のサンプリングを行うために、相互に物理的に隣接しないというようなフラッシュ・メモリ装置の複数のブロックが、モニタ・データを格納するために選択されることがある。如何なる場合も、モニタ・データは複数のブロック・グループに書き込まれ得るし、その場合、各グループに対して行なわれる書き込みサイクルの数は異なる。
【００２１】
モニタ・データを書き込む前に、少なくとも１つのブロックは何回も書き込まれるかもしれないということに留意されたい。例えば、同じデータが連続的に再書き込みされ得るし、異なるデータが各再書き込み時にその２つ等の組み合わせで書き込まれ得る。従って、そのメモリ装置上に最終的に格納されるモニタ・データは、必ずしも書き込みの各サイクル中に使用されたモニタ・データではないこともあり得る。
【００２２】
或る期間の後、モニタ・データは読み取られる。オペレーション１０４を参照されたい。その期間は、モニタ・データが書き込まれる時点後の任意の長さの時間（例えば、秒、分、時間、日等）を含み得る。１つの実施例では、この期間は、ユーザまたはシステムが定義した期間を含み得る。オプションとして、その期間は設定可能であってもよい。いずれの方法も、データ・エイジ、期間等を測定するために、ラン・タイム・クロック、リアル・タイム・クロック、カレンダ等の出力が使用され得る。リアル・タイム・クロックの使用は、電源遮断、停電等の期間であっても、データ・エイジが容易に決定され得るという点で有利である。
【００２３】
一旦モニタ・データが読み取られると、その読み取りに基づいて少なくとも１つのブロックの持続具合が決定される。オペレーション１０６を参照されたい。モニタ・データがホスト・システムに知られている場合、持続具合の決定は、その読み取られたモニタ・データをそれの格納されたバージョンと比較することを含み得る。
【００２４】
更に、モニタ・データの読み取りおよび少なくとも１つのブロックの持続具合の決定は周期的な間隔で生じ得る。この場合、その周期的な間隔は、ユーザによって定義された間隔またはシステムによって自動的に定義された間隔を含み得る。
【００２５】
一旦持続具合が決定されると、その決定の結果が出力される。オペレーション１０８を参照されたい。１つの実施例では、フラッシュ・メモリ装置またはそれの一部分の操作上の制限が少なくとも１つのブロックにおける持続具合の決定の結果に基づいて決定され得る。オプションとして、動作限界に遭遇すると、書き込みはフラッシュ・メモリ装置またはそれの一部分には最早許可され得ない。
【００２６】
好ましくは、モニタ・データは、その分野で知られた任意の方法によって、例えば、利用可能なデータ・スペースのマッピングからそれを省くことによって、書き込み保護される。１つの実施例では、モニタ・データを有する少なくとも１つのブロックの少なくとも一部分が書き込み保護され得るということに留意されたい。例えば、モニタ・データを有する少なくとも１つのブロックの少なくとも一部分が、ユーザ・データによって上書きされないよう書き込み保護され得る。
【００２７】
１つの方法では、書き込み保護は、メモリ・コントローラにおいて書き込み不能としてブロックをマークすることにより達成され得る。別の方法では、保護されたブロックまたはそれの一部分がフラッシュ・メモリ装置上に格納され得る。更に、１つの実施例では、モニタ・データが、フラッシュ・メモリ装置のメモリ容量の約１%未満を含み得るし、更に好ましくは、約０.５%未満を含み得る。他の実施例では、メモリ容量の０.１%未満がモニタ・データの格納のために使用され得る。方法１００を使用すると、フラッシュ・メモリの破損および持続は、フラッシュ・メモリ装置へのモニタ・データの追加によって測定され得る。モニタ・データは、すべての値がホスト・システムに知られているデータ・パターンを含み得る。従って、エラーは、数、ロケーション、およびパターンによって特徴づけられ得る。
【００２８】
いずれかのユーザ・データが高いサイクルの数を得る前に、１セットのブロックがその高いサイクルの数に置かれることがある。このデータを使用して、エラー率面のサンプルが行われ得る。一旦高いサイクルの数に置かれると、モニタ・データは維持具合を測定するために周期的にチェックされ得る。オプションとして、測定された破損およびデータ持続の限界が、自己監視、分析、報告技術（Ｓ.Ｍ.Ａ.Ｒ.Ｔ.）によって報告され得る。
【００２９】
上記したように、ＮＡＮＤフラッシュ装置は、消去／書き込みサイクルに対する有限の耐久性および有限のデータ持続性に悩まされることがある。これは、絶縁物を通して電荷を駆動するデータ格納プロセスの可逆性が貧弱なためである。その結果、フラッシュ装置におけるわずかなエラー率が３Ｄ面として特徴付けられ得る。
【００３０】
図２は、１つの実施例に従って、フラッシュ・エラー率面の形状を示す代表的なプロット図２００を示す。図示のように、Ｘ軸は、１ミリ秒から１０年までのデータ・エイジを秒で示す。深さ軸は、１サイクルから１x１０６サイクルまでのサイクルの数を示す。垂直軸はエラー率乗数（error rate multiplier）である。ほとんどのフラッシュ装置のエラー率面は、図２に示されるような一般的な特性を有する。
【００３１】
セルが十分に高いサイクルの数に書かれる場合、それらは完全に（例えば、１／２のエラー率で）障害を生じる。従って、図２に示された面の左後方隅におけるエラー率は、或るサイクルの数で障害まで増加する。更に、データのエイジが増加するとき、低いサイクルの数で障害が生じる。従って、右後方隅におけるエラー率は一層速く障害に進む。ＥＣＣまたはＥＣＣプラス周期冗長検査（ＣＲＣ）の設計は、エラー率またはその面の形状を知ることに依存する。
【００３２】
多くのＮＡＮＤ装置は、データ保全性に影響を与え得る多くの問題を有する。これらは、チャージ・デトラッピング（chargedetrapping）、ストレス誘起漏洩電流（ＳＩＬＣ）、読み取り妨害及び書き込み妨害、および／または、他の問題を含む。
【００３３】
フラッシュ（例えば、ＪＥＤＥＣ、ＪＥＳＤ４７Ｆ等）に関する製造テストは、ＩＴデータ保全には不適切である。ＳＩＬＣテストは、５００時間の間に１つのロット当たりわずか３８個の装置しか使用しない。そのようなテストにおけるゼロ・エラーは９０%の信頼性に対して６%もの高い逃げ率を示す。更に、５００時間のテストは、（装置の残り部分が全くテストされないと仮定して）耐久性の限界に対してその装置の最大１０%を、わずか１００ｎＳのデータ・エイジでテストすることを可能にする。
【００３４】
ＩＴシステム対するデータ保全性の要件は非常に厳しいことがある。化けたデータを戻すことは一般に許容し得ないことである。１０Ｍ単位年当たり１つ事象というきつくない目標が設定されることがある。１０ｋのＩＯＰＳ率では、これは、代表的な４ｋＢのＩＯに対して転送された１ビット当たりの１x１０−２３の未修正エラー率を与える。従って、規定された耐久性仕様を使ってＩＴフラッシュ・システムを設計することは大きな危険を伴い得る。
【００３５】
損耗の均等化は、耐久性サイクルの数よりも低いフリー・ブロックが存在しなくなるまでの時間を増加させるために利用され得る。フリー・ブロックは、スペアを通して、または、例えば、静的なデータを移動させることによっても得ることが可能である。静的な損耗の均等化アルゴリズムの１つの目標は、耐久性の限界以下のフリー・ブロックまたはフリーになり得るブロックが存在しなくなるまで、サイクルの数を最大にすることである。
【００３６】
理想的な静的損耗均等化アルゴリズムは、いずれの時点でも最も狭い分布を生じるであろう。これは装置に対して最大のサイクルの数を与えるであろう。しかし、この場合、損耗の均等化は、ブロックが損耗していることを判断するためのロバストな技法の存在を仮定している。即ち、損耗の均等化は、破損に関する累積分布関数（ＣＤＦ）が、唐突の、しかも既知のサイクルの数における始まりを有するということを仮定している。更に、すべてのブロックが同じ破損の特性を有するということも仮定している。更に、持続性の影響は無視される。
【００３７】
図３は、１つの実施例に従って、或るデータ・エイジの時の損耗によって、所与のブロックがセクタ・レベルＥＣＣの訂正能力を超える確率を表わす例示的ＣＤＦ３００を示す。セクタ・レベルＥＣＣは、ソフト・エラーおよび他の影響から保護するために直ちに利用することが可能である。しかし、ＥＣＣの能力に対しては有限の限界があり、ブロック損耗によりこの限界が超えられてしまうことがある。これが起こると、化けたデータは返却され得る。ＣＲＣのような追加のセクタ・チェックは、これが起こるポイントを移動させるが、この問題点を排除することはあり得ない。
【００３８】
図３における曲線は、１つの実施例に従って、どのような実際のフィールドの具合が短いデータ・エイジのときにあり得るかを表わしている。１０５サイクルの耐久性仕様を有する装置を仮定すると、これは、ＪＥＤＥＣテスト結果を考慮すれば、６％の確率に割り当てられ得る。この例では、ブロックの９４％が１０８サイクルで機能しなくなるということが仮定された。長いデータ・エイジでは、その曲線は左にシフトするであろう。
【００３９】
図４では、信頼性のインパクトが分かるであろう。図４は、１つの実施例に従って、懸念領域を示す或るデータ・エイジにおけるアクセス分布とＣＤＦとの間のオーバーラップの表示４００を示す。
【００４０】
図４を使って、アクセス分布とＣＤＦとの間のオーバーラップを見ることができる。アクセス分布が狭ければ狭いほどブロックの割合が大きくなるということは、破損が注目される前の損耗ゾーンにおいてありそうである。従って、セクタＥＣＣの能力が超えられ、化けたデータが戻されるであろうということは大いにありそうである。
【００４１】
これらの問題点および他の問題点に対処するために、エラー率面がフラッシュ装置に関する耐久性および持続性の限界の決定を支援するためにサンプリングされ得る。１つの実施例では、これは損耗の均等化を受けない多くの物理ブロックを保存することによって達成され得る。これらのブロックは、ホスト・システムに知られているデータをその値が十分に検証されるように含み、ＥＣＣから決定されたエラー率を使用することに固有の如何なるエイリアシング問題も回避し得る。
【００４２】
更に、そのようなブロックは、データ保全性を損なわずにＥＣＣ能力を超えたエラー率で使用され得る。モニタ・データもエラー率対持続性を測定するために周期的に検査され得る。
【００４３】
１つの実施例では、ＣＤＦの予期された立ち上がりの近くに位置付けられた完全消去ブロックのセットは、それがデータ化けに結びつく前に損耗を決定することを支援するように利用され得る。例えば、フラッシュ装置は、１６,０００個の消去ブロックを持ち得る。モニタ・データとして１５個のブロックを使用することは、装置能力の０.１%未満しか必要としないであろう。
【００４４】
１つのオプションとして、３個のブロックから成る５つのグループとして配列された１５個のブロックが利用され得る。各グループは同じサイクルの数を持ち得る。この場合、１つのグループ内に複数のブロックを持つことは測定の質を改善し得る。各グループに対するロケーション（サイクルの数に関する）は、データ保全性に影響を与え得る大きさをＣＤＦが持ち始めると思われる領域に近くなるように選択され得る。
【００４５】
一例として、下記の表１は、１つの実施例に従って、フラッシュ装置を表す特性を示す。
【表１】
0005596123.tif 000002
【００４６】
この例では、ブロックを消去する／書き込む／読み取るための時間は１３８ミリ秒である。従って、５個のモニタ・グループのモニタ・データ目標レイアウトが選択され得る。下記の表２は、１つの実施例に従って、５個のモニタ・グループのモニタ・データ目標レイアウトを表示したものを示す。
【表２】
0005596123.tif 000003
【００４７】
この場合、損耗が対数正規の状況を有するということを仮定して、べき乗分布するようにサイクルの数が選ばれる。種々の実施例において、モニタ・データの有効性を最大にするために他の分布を選ぶことも可能である。この例では、すべてのモニタ・データを最後のカウントまで循環させるためには合計５０時間が必要であろう。
【００４８】
図５は、１つの実施例に従って、或る時点でユーザ・データおよびモニタ・データのための代表的なサイクルの数ヒストグラム５００を示す。この場合、ユーザ・データおよびモニタ・データのヒストグラムは書き込みサイクルの数の関数として示される。更に、データは損耗の均等化を含む。
【００４９】
図示のように、モニタ・データは予期される損耗サイクルの数の近くに置かれる。場合によっては、すべてのモニタ・データ・ブロックを循環させるために必要な時間は、出荷前に行ないたい時間よりも長いことがある。そのような場合、モニタ・データは、現場で生じる循環の残りを、出荷前に部分的に循環させてもよい。
【００５０】
一旦モニタ・データが最終のサイクルの数になれば、ブロックが周期的に読み取られ得るし、読み取られたデータは既知のデータと比較され得る。これは、エラーの完全な識別を可能にし、変化率を維持する能力を含む。
【００５１】
図６は、モニタ・データ・システムからの測定６００の１つの可能なセットを示す。各モニタ・グループはカラム・グループとして示され、そのグループにおける各カラムは異なるデータ・エイジを表わす。各カラムの高さは１つのセクタ当たりのエラーの数であり、「ＥＣＣ限界」と表示された下部領域は可能なＥＣＣ訂正の限界を表わす。図示されるように、いくつかの測定値はＥＣＣ能力を超過し、従って、データ保全性に関するリスクを提起し得る。
【００５２】
１つの実施例では、このデータから動作の限界を導出することが可能である。例えば、下記の表３は、１つの実施例に従って図６における例示的データに対して発生され得る動作の限界を示す。
【表３】
0005596123.tif 000004
【００５３】
モニタリング・データ・パターンを選することも可能である。種々の実施例において、これは静的なパターンであってもよく、特定のブロックに対して計算されてもよい。オプションとして、耐久性および／または持続性を重視するパターンを利用することも可能である。いずれの場合も、フラッシュ装置から何も読み取らなくても、各モニタ・ブロックの期待された内容を知ることができるように、システムが構成され得る。限界の１つに達するとき、システムは、Ｓ.Ｍ.Ａ.Ｒ.Ｔ.フラグによって、または最早書き込みを許容しない（例えば、書き込み時のエラーを戻す等の）ような別の手法によって通知され得る。
【００５４】
上記の説明の多くは、フラッシュ・ブロック全体を含むものとしてモニタ・データ・ユニットを説明したが、上記の技法はフラッシュ・ブロック全体を使用することに限定されない。例えば、１つの実施例では、モニタ・データ・ユニットはセクタ・サイズくらいに小さくてもよい。
【００５５】
セクタ・サイズのモニタ・データ・ユニットを使用することはモニタリング特性を保持するであろうが、場合によっては、これはエクスポージャをハード・エラーに委ねることになり得る。例えば、ページ・サイズのモニタがブロックの残りにおけるユーザ・データによって利用される場合、モニタ・ページがＥＣＣ限界に近いエラー率を示すと、そのユーザ・データは、失われたもの（即ち、ハード・エラー）としてマークされ得る。これは、セクタＥＣＣがそのような状況では信頼し得るものではないためである。しかし、この技法を使用すると、化け事象の可能性は、より低いオーバーヘッドで減少するであろう。
【００５６】
図７は、１つの実施例に従って、複数のフラッシュ・メモリ装置からのモニタ・データの情報を分析する方法７００を示す。図示のように、モニタ・データの情報は、複数のフラッシュ・メモリ装置から収集される。なお、モニタ・データは、既知の書き込みサイクルの数の専用メモリ・セルに格納された既知の内容のデータである。オペレーション７０２を参照されたい。
【００５７】
モニタ・データは、任意のデータまたは既知のデータ・パターンを含み得る。１つの実施例では、モニタ・データの情報は、モニタ・データのデータ・エイジおよび書き込みサイクルの数の少なくとも１つに関するエラー率情報を含み得る。更に、モニタ・データおよび／またはモニタ・データの情報は様々な技法を使って収集され得る。１つの実施例では、モニタ・データは生成されてもよい。
【００５８】
一旦モニタ・データの情報が収集されると、そのモニタ・データの情報は分析される。オペレーション７０４を参照されたい。更に、分析に基づいて、装置の少なくとも１つに関してアクションが取られる。オペレーション７０６を参照されたい。
【００５９】
そのアクションは種々のアクションを含み得る。１つの実施例では、アクションを取ることは、装置の少なくとも１つに対する動作目標を設定することを含み得る。この場合、動作目標は、データ書き込みサイクルの数に関する限界であってもよい。別のオプションとして、動作目標はデータ・エイジに対する限界であってもよい。
【００６０】
モニタ・データの情報の収集およびその情報の分析は何回も生じ得るということに留意されたい。例えば、収集するステップおよび分析するステップは少なくとも２回行なわれ得るし、統計上の傾向はそれに基づいて生じ得る。更に、収集するステップおよび分析するステップは少なくとも２回行なわれ得るし、モニタ・データの時間依存性が追跡され得る。
【００６１】
この技法を実施することによって、１セットの装置からモニタ・データの情報を収集すること、そのデータを分析すること、およびその装置に対する動作目標を設定することによって、フラッシュ・ベースのストレージ・システムの信頼性を高めるためのシステムおよび方法が提供され得る。モニタ・データは、各装置に対するサイクルの数およびデータ・エイジに関するエラー率情報を含み得る。更に、動作目標は、サイクルの数およびデータ・エイジに関して装置レベルの限界を設定することを含み得る。多数の装置からのデータを集約することは、サンプル・サイズが増加されることを可能にし、統計的傾向を識別するのを支援し得る。更に、その集約は、データの時間依存性も追跡し得る。
【００６２】
動作目標は所定期間の後に更新され得る。１つの方法では、モニタ・データは、最新の動作目標を作成するために、前の動作目標が設定された時から或る期間が経過した後、再び収集され、分析され得る。従って、これは、モニタ・データのより長いエイジの影響を考慮して動作目標を改善する可能性がある。別の方法では、動作の目標は、メモリ装置の故障事象、目標が設定されたので利用可能になった追加情報またはパラメータ等のような他の要素に少なくとも部分的に基づいて更新され得る。
【００６３】
１つの実施例では、モニタ・データの方法は、ストレージ・システムにおけるフラッシュ装置のセットにおいてエラー率面の測定を行うために利用され得る。更に、エラー率対サイクルの数、およびエラー率対データ・エイジの測定が所与のフラッシュ装置に提供され得る。
【００６４】
図８は、１つの実施例に従って、代表的なストレージ・システム８００を表わす。図示されるように、ストレージ・システム８００は、ストレージ・コントローラ８０２および複数のフラッシュ装置８０４を含み得る。システム８００の動作はモニタ・データの情報に応じて調節され得る。コントローラ８０２は、そのようなストレージ・システムからのフィールド・データを集める遠隔のデータ・リポジトリ８０６とコミュニケーションをとり得る。
【００６５】
コントローラ８０２は、このデータに基づいてまたは工場プリセットとして、ローカルのフラッシュ装置８０４のセットに対する初期サイクルの数目標を決定し得る。これらの値はフラッシュ装置８０４に送られ、フラッシュ装置は、所定のサイクルの数にそれを置くためにそれらのモニタ・データを循環させるであろう。しかる後、ストレージ・コントローラ８０２は、様々な時間にモニタ・データのエラー特性を収集し得る。
【００６６】
１つの実施例では、ストレージ・コントローラ８０２は、リアルタイム・クロックを含み得るし、或いはリアルタイム・クロックにアクセスし得る。このクロックは、モニタ・データの書き込み時間を（モニタ・データ内に、または別の保留領域に）記録するために、およびモニタ・データのエイジを決定するために使用され得る。
【００６７】
モニタ・データによって報告されたエラー特性は、Ｓ.Ｍ.Ａ.Ｒ.Ｔ.を介するというようなインターフェースを介してフラッシュ装置に集められ得る。ストレージ・システム８００は、統計を改善するためにフラッシュ・メモリ８０４からの収集されたデータを集約し、異常値を識別し得る。
【００６８】
例えば、ストレージ・システム８００は１６個のフラッシュ・ユニット（例えば、ＳＳＤ）を含み得るし、その各々は１６個のフラッシュ装置を含み得る。これは２５６個のフラッシュ装置を提供し、従って、（ポアソン統計を仮定すると）１６倍もサンプルの質を改善する。各フラッシュ装置が各データ・セット内に３個のブロックを持つ場合、システム・データ・セットのサイズは、各セットにつき７６８個のブロック・サンプルになるであろう。従って、良好の統計を得ることおよび異常値検出を行なうことが可能である。
【００６９】
モニタ・データは、各モニタ・データ・セットに関するエラー構成を報告し得る。各セットは異なるサイクルの数を有することがある。従って、ストレージ・コントローラ８０２は、人口に関するエラー率曲線を推定するためにそれらを使用し得る。エラー率曲線は耐久性および持続性の限界基準を選択するためにも使用され得る。
【００７０】
システム８００においてデータを使用する方法の一例として、各装置においてモニタ・データに関するエラー・カウント測定のセットを生成するために、モンテカルロ・シミュレーションが行なわれ得る。この場合、モニタ・データは、少なくとも、各モニタ・データ・ブロックに対する平均的なエラー・カウントを報告するものと仮定する。各サイクルの数に対するエラー・カウント値が中間および標準偏差を計算するためにマージされる。
【００７１】
ガウス拡散（Gaussian spread）を仮定すると、外部のＥＣＣが修正し得るエスケープ限界目標が計算され得る。更に、装置対装置の相関性が外部のＥＣＣを圧倒しないようにするに十分でなければならないエスケープの目標確率は１x１０−６である。これは、（ガウスの統計を仮定すれば）この例に関して４.８の標準偏差であるということになる。下記の表４は、この例に関するモンテカルロ・シミュレーションの結果を示す。
【表４】
0005596123.tif 000005
【００７２】
この場合、モニタ・データは５つの別個のサイクルの数でサンプリングされる。「中間」行は、セクタ当たり中間の数のエラーをリストし、「シグマ」行は、対応する標準偏差をリストする。「シグマ・クリップ曲線」行は、各サイクルの数時の４.８の標準偏差値である。最後の行は、４.８の標準偏差を超えるエラー・カウントを有する装置の数である。
【００７３】
この例では、クリップを超過する単一の装置だけが存在し、従って、これが特異値であると仮定する。更に、１つのセクタ当たり８つのエラーというエラー限界が選択されるものと仮定する。これは、セクタ・レベルのエラー訂正能力によって決定されるであろう。
【００７４】
そのような値を仮定すると、シグマ・クリップ曲線を挿入することによって非特異値に対するサイクルの数限界が推測され得る。この例に関して、その限界値は８５ｋの書き込みサイクルである。同様に、特異値の限界は、この例では６１ｋサイクルであると計算され得る。更に保守的な方法は、特異値によっても利用され得る。例えば、単一の挿入よりも低いサイクルの数が選択され得る。同様に、曲線適合法のような他の推測技法も使用され得る。
【００７５】
図９は、この例による結果のグラフ９００を示す。グラフ９００は、特異値が分布の端を十分に越えていることを示し、従って、正規のクリップ限界の適用は恐らくエラー・リスクを生じるであろう。一旦サイクルの数限界が計算されてしまうと、それらは、耐久性の限界に対して責任を負うフラッシュ装置またはコントローラにフィード・バックされ得る。これは様々な時間に繰り返され、従って、種々のデータ・エイジを反映し得る。そのため、ストレージ・システムに対する耐久性のおよび持続性の目標セットは、両方とも生成され得る。
【００７６】
この方法は、それが人口統計に有益であるので、各装置がそれ自身の限界を設定することを可能にすることを超えた改善であり、特異値をサンプリングの雑音から正確に区別することができる。各モニタ・データのセットは、各々が多くのデータ・セクタを含む複数の消去ブロックを含み得る。例えば、典型的なＮＡＮＤ装置は、５２８ｋＢの消去ブロックを持ち得るし、各々が５２８バイトを有する１０２４個のセクタを含む。各モニタ・セットが３つのデータ・ブロックを使用したと仮定すると、２５６個の装置のセット全体に関して１つのセット当たり３.３ｘ１０９ビットが存在する。従って、信頼性は強化され、行き過ぎが回避されるので、コストは減少する。
【００７７】
本発明が、全体的にハードウェアの実施例、全体的にソフトウェアの実施例、またはハードウェア要素およびソフトウェア要素の両方を含んだ実施例の形式を取り得るということを留意されたい。例えば、１つの実施例では、システムは、複数のメモリ・ブロックを有するフラッシュ・メモリ装置を含み得るし、それらのブロックの少なくとも１つはそこにモニタ・データを書き込まれ、少なくとも１つのブロックは、モニタ・データの書き込みの前に複数回も書き込まれている。システムは、更に、それらのブロックをアドレスするための回路、およびモニタ・データのコピーを格納する二次メモリも含み得る。更に、システムは、ストレージ・コントローラおよび複数のフラッシュ・メモリ装置を含み得る。
【００７８】
当業者には明らかなように、本発明は、システム、方法、またはコンピュータ・プログラムとして具現化され得る。従って、本発明は、全体的にハードウェアの実施例、全体的にソフトウェアの実施例（ファームウェア、駐在ソフトウェア、マイクロコード等を含む）または、本明細書では一般に「回路」、「モジュール」、もしくは「システム」と呼ばれ得るソフトウェアおよびハードウェアの側面を結合した実施例の形体を取り得る。更に、本発明は、有形の表現媒体において具体化され、コンピュータ使用可能プログラム・コードとして体現されたコンピュータ・プログラムの形体を取り得る。
【００７９】
１つまたは複数のコンピュータ使用可能媒体またはコンピュータ可読媒体の任意の組み合わせが利用され得る。例えば、コンピュータ使用可能媒体またはコンピュータ可読媒体は、例えば、電子的、磁気的、光学的、電磁気的、赤外線、もしくは半導体システム、装置、デバイス、または伝播媒体であってもよいが、それらに限定されない。コンピュータ可読媒体の更なる特殊な例（非限定的なリスト）は、以下のもの、即ち、１つまたは複数の配線を有する電気的接続体、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、光学的記憶装置、インターネットもしくはイントラネットをサポートするような伝送媒体、或いは磁気記憶装置を含むであろう。プログラムは、例えば、用紙または他の媒体の光学的スキャンによって電子的に捕捉され、しかる後、コンパイルされ、解釈され、或いは必要に応じて適切な方法で処理され、しかる後、コンピュータ・メモリに格納され得るので、コンピュータ使用可能またはコンピュータ可読媒体は、そのプログラムが印刷されている用紙または別の適切な媒体であってもよいということに留意されたい。本明細書に関して、コンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、装置、またはデバイスによる使用、或いはそのシステムに関連した使用のためにプログラムを含み、格納し、通信し、伝播し、または搬送することができる任意の媒体であってもよい。コンピュータ使用可能媒体は、搬送波のベースバンドでまたは搬送波の一部として具体化されたコンピュータ使用可能プログラム・コードを伴う伝播データ信号を含み得る。コンピュータ使用可能プログラム・コードは、無線接続、有線接続、光通信ケーブル、ＲＦ等を含むが、これらに限定されない任意の適切な媒体を使用して伝送され得る。
【００８０】
本発明のオペレーションを実行するためのコンピュータ・プログラム・コードは、Java、Smalltalk、C++等のようなオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語のような従来のプロシージャ型プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組み合わせで書かれてもよい。プログラム・コードは、ユーザのコンピュータにおいて全体的に、ユーザのコンピュータにおいて部分的に、独立型ソフトウェア・パッケージのようにユーザのコンピュータにおいて部分的におよび遠隔のコンピュータにおいて部分的に、または遠隔のコンピュータもしくはサーバにおいて全体的に実行され得る。下記の説明では、遠隔のコンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）あるいは広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続され得るし、または、その接続は、（例えば、インターネット・サービス・プロバイダを使ってインターネットを介して）外部コンピュータに行われ得る。
【００８１】
本発明は、本明細書では、本発明の実施例に従って、方法、装置（システム）およびコンピュータ・プログラムのフローチャートおよび／またはブロック図に関して説明されている。フローチャートおよび／またはブロック図の各ブロック、並びに、フローチャートおよび／またはブロック図におけるブロックの組み合わせがコンピュータ・プログラム命令によって具現化され得るということは当然である。これらのコンピュータ・プログラム命令は、マシンを製造するために汎用コンピュータ、特殊目的コンピュータ、または他のプログラム可能データ処理装置のプロセッサに提供され得るので、そのコンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行される命令が、フローチャートおよび／またはブロック図の１つまたは複数のブロックにおいて指定された機能／行為を具現化するための手段を作成する。
【００８２】
これらのコンピュータ・プログラム命令は、特定の方法で機能するようにコンピュータまたは他のプログラム可能データ処理装置に指示し得るコンピュータ可読媒体に格納され得るので、コンピュータ可読媒体に格納された命令は、フローチャートおよび／またはブロック図の１つまたは複数のブロックにおいて指定された機能／行為を具現化する命令手段を含む製品を作り出す。
【００８３】
コンピュータ・プログラム命令は、コンピュータまたは他のプログラム可能データ処理装置上にもロードされ、コンピュータまたは他のプログラム可能装置上で実行される命令が、フローチャートおよび／またはブロック図の１つまたは複数のブロックにおいて指定された機能／行為を具現化するためのプロセスを提供するようコンピュータ搭載のプロセスを生じさせるために、一連の動作ステップをコンピュータまたは他のプログラム可能データ処理装置において遂行させる。
【００８４】
図面におけるフローチャートおよびブロック図は、本発明の様々な実施例により、システム、方法およびコンピュータ・プログラムの可能な実施態様のアーキテクチャ、機能、およびオペレーションを示す。この点について、フローチャートまたはブロック図における各ブロックは、指定された論理的機能を具現化するための１つまたは複数の実行可能な命令を含むモジュール、セグメント、またはコード部分を表わし得る。いくつかの代替実施態様では、ブロックに記載された機能が図面に示された順序から外れて生じ得るということにも留意されたい。例えば、連続して示された２つのブロックが、実際には、同時に実行され得るし、或いは、それらのブロックは、時には、関連する機能次第で逆の順序で実行され得る。更に、ブロック図および／またはフローチャートの各ブロック、並びにブロック図および／またはフローチャートにおけるブロックの組み合わせが、指定された機能または行為を遂行する特殊目的のハードウェア・ベースのシステムによって、または特殊目的ハードウェアおよびコンピュータ命令の組み合わせによって具現化され得るということにも留意されたい。
【００８５】
プログラム・コードを格納および／または実行するに適したデータ処理システムは、システム・バスを介してメモリ素子に直接的にまたは間接的に結合された少なくとも１つのプロセッサを含むであろう。メモリ素子は、プログラム・コードの実際の実行中に使用されるローカル・メモリと、大容量記憶装置と、コードが実行中に大容量記憶装置から検索されなければならない回数を減らすために少なくとも幾つかのプログラム・コードの一時的記憶装置を提供するキャッシュ・メモリとを含み得る。
【００８６】
入出力またはＩ／Ｏ装置（キーボード、ディスプレイ、ポインティング装置等を含むがこれらに限定されない）は、システムに直接にまたは介在するＩ／Ｏコントローラを介して結合され得る。
【００８７】
ネットワーク・アダプタも、データ処理システムが、介在の専用または公衆ネットワークを介して他のデータ処理システムまたは遠隔のプリンタもしくは記憶装置に連結されることを可能にするために、そのシステムに結合され得る。モデム、ケーブル・モデム、およびイーサネット・カードは、数少ない現在利用可能なタイプのネットワーク・アダプタである。
【００８８】
図１０は、１つの実施例に従って、ネットワーク・アーキテクチャ１０００を示す。オプションとして、図１乃至図９の機能およびアーキテクチャがネットワーク・アーキテクチャ１０００に関連して実装され得る。しかし、図１乃至図９の機能およびアーキテクチャは任意の望ましい環境において実施され得る。前述の定義が当該説明にも適用し得ることに留意されたい。
【００８９】
図１０に示されるように、第１の遠隔ネットワーク（ネットワーク１）１００４および第２の遠隔ネットワーク（ネットワーク２）１００６を含む複数の遠隔ネットワーク１００２が設けられる。遠隔ネットワーク１００２と近接ネットワーク（ネットワーク３）１００８の間にゲートウェイ１００７が連結され得る。本ネットワーク・アーキテクチャー１０００に関連して、ネットワーク１００４および１００６は、それぞれ、ＬＡＮ、インターネットのようなＷＡＮ、ＰＳＴＮ、構内電話網等を含むがそれらに限定されない任意の形式を取り得る。
【００９０】
使用時には、ゲートウェイ１００７は、遠隔ネットワーク１００２から近接ネットワーク１００８への進入点として働く。そのように、ゲートウェイ１００７は、そのゲートウェイ１００７に到着する所与のデータ・パケットを方向付けることができるルータとして、および所与のパケットに対してゲートウェイ１００７の実際のパス入力およびパス出力を供給するスイッチとして機能し得る。
【００９１】
更に、近接ネットワーク１００８に結合された少なくとも１つのデータ・サーバ１０１４が含まれ、それは遠隔ネットワーク１００２からゲートウェイ１００７経由してアクセス可能である。データ・サーバ１０１４が任意のタイプのコンピューティング装置／グループウェアを含み得るということに留意されたい。各データ・サーバ１０１４には複数のユーザ装置１０１６が結合される。そのようなユーザ装置１０１６は、デスクトップ・コンピュータ、ラップトップ・コンピュータ、ハンドヘルド・コンピュータ、プリンタ、または他のタイプのロジックを含み得る。ユーザ装置１０１７も、１つの実施例では、それらのネットワークのいずれにも直接結合され得るということに留意されたい。
【００９２】
１つまたは複数のネットワーク１００４、１００６、１００８に１つのファクシミリ装置１０２０または一連のファクシミリ装置１０２０が結合され得る。データベースおよび／または更なるコンポーネントが、ネットワーク１００４、１００６、１００８に結合された任意のタイプのネットワーク素子によって利用され得るし、或いはそれらのネットワーク素子に統合され得るということに留意されたい。この説明に関連して、ネットワーク素子は、ネットワークの任意のコンポーネントを指してもよい。
【００９３】
図１１は、１つの実施例に従って、図１０のユーザ装置１０１６に関連した代表的なハードウェア環境を示す。その図は、マイクロプロセッサのような中央処理装置１１１０、およびシステム・バス１１１２を介して相互接続された多くの他のユニットを有するワークステーションの代表的なハードウェア構成を示す。
【００９４】
図１１に示されたワークステーションは、ランダム・アクセス・メモリ（ＲＡＭ）１１１４と、読み取り専用メモリ（ＲＯＭ）１１１６と、ディスク記憶ユニット１１２０のような周辺装置をバス１１１２に接続するためのＩ／Ｏアダプタ１１１８と、キーボード１１２４、マウス１１２６、スピーカ１１２８、マイクロホン１１３２、および／または、タッチ・スクリーンおよびディジタル・カメラ（図示されてない）のような他のユーザ・インターフェース装置をバス１１１２に接続するためのユーザ・インターフェース・アダプタ１１２２と、ワークステーションを通信ネットワーク１１３５（例えば、データ処理ネットワーク）に接続するための通信アダプタ１１３４と、バス１１１２をディスプレイ装置１１３８に接続するためのディスプレイ・アダプタ１１３６とを含む。
【００９５】
ワークステーションは、Microsoft Windows（商標）オペレーティング・システム（ＯＳ）、ＭＡＣＯＳ、またはＵＮＩＸオペレーティング・システムのようなオペレーティング・システムをその上に駐在させ得る。好適な実施例は、上記のオペレーティング・システム以外のオペレーティング・システムをプラットフォーム上に実装し得るということは明らかであろう。好適な実施例は、オブジェクト指向プログラミング方法と共に、ＪＡＶＡ、ＸＭＬ、Ｃ、および／またはＣ++言語、或いは、他のプログラミング言語を使用して書かれてもよい。複雑なアプリケーションを開発するために益々使用されるようになったオブジェクト指向プログラミング（ＯＯＰ）も使用可能である。
【００９６】
様々な実施例を説明したが、それらが、限定としてではなく、単なる例として示されたことは当然である。従って、好適な実施例の幅および範囲は、上記の実施例のいずれによっても限定されるべきではなく、「特許請求の範囲」の記載およびそれらの均等物のみに従って定義されるべきである。
【図１】
0005596123.tif 000006
【図２】
0005596123.tif 000007
【図３】
0005596123.tif 000008
【図４】
0005596123.tif 000009
【図５】
0005596123.tif 000010
【図６】
0005596123.tif 000011
【図７】
0005596123.tif 000012
【図８】
0005596123.tif 000013
【図９】
0005596123.tif 000014
【図１０】
0005596123.tif 000015
【図１１】
0005596123.tif 000016