(57)【要約】  少なくとも１つのデータソースから受信された、データと多数のデータ変更との情報を使用して、少なくとも１つのデータ代理を生成する、多次元代理システムおよび方法が提供される。多次元代理は、各データ代理のデータを、データ源のフォーマットから少なくとも１つの代替フォーマットに変換する。元のメタデータが、各データ代理から抽出される。新しいメタデータが、元のメタデータの部分と各データ代理の要素とを組み合わせることによって生成される。多次元代理は、データ代理と新しいメタデータとを含む拡張データ代理を生成する。
2008530658.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのデータソースから受信された、受信データと複数のデータ変更との情報を使用して、少なくとも１つのデータ代理を生成するステップと、
各データ代理の元のメタデータを抽出するステップと、
前記データ代理と前記元のメタデータの少なくとも一方を含む拡張データ代理を生成するステップと、
アプリケーションとサーバの少なくとも一方による、前記データ代理と前記拡張データ代理の少なくとも一方のデータへのアクセスを制御するステップと、を含む方法。
【請求項２】
少なくとも１つのデータソースから受信された、少なくとも１つの追加データ変更の情報を使用して、前記少なくとも１つのデータ代理を更新するステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記更新するステップが、前記少なくとも１つの追加データ変更の受信時と、複数の追加データ変更の受信後と、前記少なくとも１つの追加データ変更後の動作の少なくとも１つにおいて実行される、請求項２に記載の方法。
【請求項４】
前記データ代理と前記拡張データ代理の少なくとも一方のデータを、複数の密度フォーマット間で変換するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記元のメタデータの部分と各データ代理の要素とを組み合わせることによって、新しいメタデータを生成するステップをさらに含む、請求項１に記載の方法。
【請求項６】
前記拡張データ代理が、前記新しいメタデータを含む、請求項５に記載の方法。
【請求項７】
少なくとも１つの前記アプリケーションのデータフォーマットを検出するステップと、
検出されたデータフォーマットに従って、前記データ代理と前記拡張データ代理の少なくとも一方のデータを変換するステップと、をさらに含む、請求項１に記載の方法。
【請求項８】
少なくとも１つの前記アプリケーションのデータの内容を検出するステップと、
検出されたデータの内容に従って、前記データ代理と前記拡張データ代理の少なくとも一方のデータを変換するステップと、をさらに含む、請求項１に記載の方法。
【請求項９】
前記データ代理と前記拡張データ代理の少なくとも一方の少なくとも１つのインスタンスを、少なくとも１つのストレージサイトにアーカイブするステップをさらに含む、請求項１に記載の方法。
【請求項１０】
前記少なくとも１つのストレージサイトが、複数のストレージサイトを含む、請求項９に記載の方法。
【請求項１１】
前記データ代理と前記拡張データ代理の少なくとも一方で行われた変更の差分情報をアーカイブするステップをさらに含む、請求項９に記載の方法。
【請求項１２】
前記アーカイブするステップが、アクティブアーカイビングを含み、アクティブアーカイビングが、前記データ代理に対して少なくとも１つの動作を実行するステップと、前記データ代理と前記拡張データ代理の少なくとも一方を、対応アプリケーションに適するように、少なくとも１つのストレージサイトに配置するステップとの少なくとも一方を含む、請求項９に記載の方法。
【請求項１３】
前記アーカイブするステップが、パッシブアーカイビングを含み、パッシブアーカイビングが、前記データ代理と前記拡張データ代理の少なくとも一方の少なくとも１つのインスタンスを、参照データとして、少なくとも１つのストレージサイトにアーカイブするステップを含む、請求項９に記載の方法。
【請求項１４】
前記アーカイブするステップが、ディープアーカイビングを含み、ディープアーカイビングが、前記データ代理と前記拡張データ代理の少なくとも一方の複数のインスタンスを、少なくとも１つのストレージサイトにアーカイブするステップを含み、ディープアーカイビングによってアーカイブされたデータが、少なくとも１つの特権に従ってアクセスされる、請求項９に記載の方法。
【請求項１５】
前記データ代理と前記拡張データ代理の少なくとも一方を、少なくとも１つの前記アプリケーションと統合するステップをさらに含む、請求項１に記載の方法。
【請求項１６】
前記アプリケーションが、認証アプリケーションと、権限付与アプリケーションと、アクセス制御アプリケーションと、改ざん検出アプリケーションと、改ざん予防アプリケーションと、監査アプリケーションとを含む、請求項１５に記載の方法。
【請求項１７】
少なくとも１つの前記アプリケーションが、ユーザと、管理者と、監査人と、方針マネージャの少なくとも１つによる、前記データ代理へのアクセスを規制する、請求項１５に記載の方法。
【請求項１８】
前記データ代理と前記拡張データ代理の少なくとも一方のデータの一部を、少なくとも１つのサーバに転送するステップをさらに含む、請求項１に記載の方法。
【請求項１９】
前記転送するステップが、サービス品質メカニズムと、リモート変更検出メカニズムと、データ転送のバッチングと、転送スケジュールの最適化の少なくとも１つを含み、前記転送するステップが、帯域幅を保ち、待ち時間を最適化する、請求項１８に記載の方法。
【請求項２０】
前記転送するステップが、プライバシメカニズムを適用するステップと、耐改ざん性メカニズムを適用するステップとの少なくとも一方を含む、請求項１８に記載の方法。
【請求項２１】
前記転送するステップが、前記データ代理と前記拡張データ代理の少なくとも一方の複数のコピーが前記転送するステップから生じる場合、法的要件と、保存、処分、監視、および監督の遵守要件との少なくとも一方に従う、請求項１８に記載の方法。
【請求項２２】
前記少なくとも１つのサーバが、ローカルサーバと、リモートサーバと、メッセージングサーバと、電子メールサーバと、インスタント・メッセージング・サーバと、ボイスオーバーインターネット・プロトコル・サーバと、コラボレーションサーバと、ポータルと、顧客関係管理（ＣＲＭ）サーバと、企業資源計画（ＥＲＰ）サーバと、企業間サーバと、コンテンツ管理サーバと、データベースサーバの少なくとも１つを含む、請求項１８に記載の方法。
【請求項２３】
前記データ代理と前記拡張データ代理の少なくとも一方のデータの一部を、少なくとも１つのクライアントアプリケーションに転送するステップをさらに含み、前記少なくとも１つのクライアントアプリケーションが、ローカル・クライアント・アプリケーションと、リモート・クライアント・アプリケーションとを含む、請求項１に記載の方法。
【請求項２４】
少なくとも１つの結合された企業と統合される方式で、認証と、権限付与と、アクセス制御と、否認防止の少なくとも１つを介する、前記データ代理と拡張データ代理の少なくとも一方へのアクセスを強制するステップをさらに含む、請求項２３に記載の方法。
【請求項２５】
前記データ代理と前記拡張データ代理の少なくとも一方へのアクセスを制御するステップと、前記転送中および停止中に前記データのプライバシおよび耐改ざん性を維持するステップと、をさらに含む、請求項２３に記載の方法。
【請求項２６】
前記データ代理と前記拡張データ代理の少なくとも一方を、前記データ代理と前記拡張データ代理が関連付けられた少なくとも１つのアプリケーションに従って、少なくとも１つのストレージサイトに保存するステップをさらに含む、請求項１に記載の方法。
【請求項２７】
前記データ代理と前記拡張データ代理の少なくとも一方への、少なくとも１つのユーザによるアクセスを制御するステップをさらに含む、請求項１に記載の方法。
【請求項２８】
前記データ代理と前記拡張データ代理の少なくとも一方を、ソース、内容、キーワード、エイジ、サイズ、ユーザ、方針、およびアクセス頻度を含む少なくとも１つのパラメータに従って、複数のストレージ装置にわたって移動させるステップをさらに含む、請求項１に記載の方法。
【請求項２９】
前記データ代理のデータをターゲットサーバ上にリストアするステップをさらに含み、前記ターゲットサーバが、前記受信データのソースサーバである、請求項１に記載の方法。
【請求項３０】
前記データ代理のデータをターゲットサーバにリダイレクトするステップをさらに含み、リストアされた前記ターゲットサーバが、前記受信データの前記ソースサーバとは異なるサーバである、請求項１に記載の方法。
【請求項３１】
前記ターゲットサーバが、異なるネットワーク上および前記ソースサーバとは異なるサイトの少なくとも一方に配置される、請求項３０に記載の方法。
【請求項３２】
前記データ代理と前記拡張データ代理の少なくとも一方を生成するステップが、自動トリガと、タイマ通知と、イベント通知と、ポーリングと、リクエストの少なくとも１つに応答したものである、請求項１に記載の方法。
【請求項３３】
前記自動トリガが、少なくとも１つの事前指定パラメータに応答して自動的に開始されるトリガを含む、請求項３２に記載の方法。
【請求項３４】
前記自動トリガが、前記データ代理と前記拡張データ代理の少なくとも一方の内容を含む、請求項３３に記載の方法。
【請求項３５】
前記タイマ通知が、保守動作と、ユーザ活動と、サーバ活動と、データ投入動作の少なくとも１つを含むスケジュールされたイベントに対応する通知を含む、請求項３２に記載の方法。
【請求項３６】
前記イベント通知が、前記データソースのデータへの変更に対応する通知を含む、請求項３２に記載の方法。
【請求項３７】
前記リクエストが、前記ユーザ、サーバ、またはアプリケーションによる、アクセスの試みとコンフィグレーションの試みの少なくとも一方を含む、請求項３２に記載の方法。
【請求項３８】
前記受信データの少なくとも１つのパラメータを決定するステップであって、前記少なくとも１つのパラメータが、前記受信データのサイズと、エイジと、アクセス頻度と、最終アクセス時間の少なくとも１つを含むステップと、
前記受信データを、前記パラメータに従って、前記データ代理内の前記受信データの少なくとも１つのコピーへの少なくとも１つのポインタで置き換えるステップと、をさらに含む、請求項１に記載の方法。
【請求項３９】
前記少なくとも１つのポインタを使用する、アプリケーションと、サーバと、ユーザの少なくとも１つによる受信データへのその後のアクセスを傍受するステップと、
前記データ代理と前記拡張データ代理の少なくとも一方からのデータを結合することによって、前記その後のアクセスを提供するステップと、をさらに含む、請求項３８に記載の方法。
【請求項４０】
データと複数のデータ変更とを受信するＤＳＳサーバと、
前記データとデータ変更との情報を使用して、少なくとも１つのデータ代理を生成する、前記ＤＳＳサーバに結合されたエンジンと、
各データ代理の元のメタデータを抽出し、前記データ代理と前記元のメタデータの少なくとも一方を含む拡張データ代理を生成する、前記エンジンに結合されたエクストラクタと、を備え、
前記ＤＳＳサーバが、アプリケーションとサーバの少なくとも一方による、前記データ代理と前記拡張データ代理の少なくとも一方のデータへのアクセスを制御する、データ代理システム（ＤＳＳ）。
【請求項４１】
前記ＤＳＳサーバに結合された変換器をさらに備え、前記変換器が、前記データ代理と前記拡張データ代理の少なくとも一方のデータを、前記データのフォーマットから少なくとも１つの代替フォーマットに変換する、請求項４０に記載のシステム。
【請求項４２】
前記ＤＳＳサーバに結合された少なくとも１つのリポジトリをさらに備え、前記リポジトリが、前記データと、データ変更ファイルと、前記データ代理と、前記拡張データ代理と、前記元のメタデータと、新しいメタデータの少なくとも１つを保存する、請求項４０に記載のシステム。
【請求項４３】
前記ＤＳＳサーバが、少なくとも１つのデータソースから受信された、少なくとも１つの追加データ変更の情報を使用して、前記少なくとも１つのデータ代理を更新する、請求項４０に記載のシステム。
【請求項４４】
前記ＤＳＳサーバが、前記元のメタデータの部分と各データ代理の要素とを組み合わせることによって、新しいメタデータを生成する、請求項４０に記載のシステム。
【請求項４５】
前記ＤＳＳサーバが、少なくとも１つの前記アプリケーションのデータフォーマットと内容の少なくとも一方を検出し、前記検出されたデータフォーマットと検出された内容の少なくとも一方に従って、前記データ代理と前記拡張データ代理の少なくとも一方のデータを変換する、請求項４０に記載のシステム。
【請求項４６】
前記ＤＳＳサーバが、前記データ代理と前記拡張データ代理の少なくとも一方のデータの一部を、少なくとも１つの他のサーバに転送する、請求項４０に記載のシステム。
【請求項４７】
前記ＤＳＳサーバが、前記データ代理と前記拡張データ代理の少なくとも一方のデータの一部を、少なくとも１つのクライアントアプリケーションに転送し、前記少なくとも１つのクライアントアプリケーションが、ローカル・クライアント・アプリケーションと、リモート・クライアント・アプリケーションとを含む、請求項４０に記載のシステム。
【請求項４８】
前記ＤＳＳサーバが、少なくとも１人のユーザによる、前記データ代理と前記拡張データ代理の少なくとも一方へのアクセスを制御する、請求項４０に記載のシステム。
【請求項４９】
前記ＤＳＳサーバが、前記データ代理と前記拡張データ代理の少なくとも一方を、ソース、内容、キーワード、エイジ、サイズ、ユーザ、方針、およびアクセス頻度を含む少なくとも１つのパラメータに従って、複数のストレージ装置にわたって移動させる、請求項４０に記載のシステム。
【請求項５０】
前記ＤＳＳサーバが、前記データ代理のデータをターゲットサーバ上にリストアし、前記ターゲットサーバが、前記受信データのソースサーバである、請求項４０に記載のシステム。
【請求項５１】
前記ＤＳＳサーバが、前記データ代理のデータをターゲットサーバにリダイレクトし、リストアされた前記ターゲットサーバが、前記受信データの前記ソースサーバとは異なるサーバである、請求項４０に記載のシステム。
【請求項５２】
前記ＤＳＳサーバに結合された少なくとも１つの企業サーバをさらに備える、請求項４０に記載のシステム。
【請求項５３】
前記少なくとも１つの企業サーバが、ローカルサーバと、リモートサーバと、メッセージングサーバと、電子メールサーバと、インスタント・メッセージング・サーバと、ボイスオーバーインターネット・プロトコル・サーバと、コラボレーションサーバと、ポータルと、顧客関係管理（ＣＲＭ）サーバと、企業資源計画（ＥＲＰ）サーバと、企業間サーバと、コンテンツ管理サーバと、データベースサーバの少なくとも１つを含む、請求項５２に記載のシステム。
【請求項５４】
前記ＤＳＳサーバに結合された少なくとも１つのネットワークをさらに備える、請求項４０に記載のシステム。
【請求項５５】
前記少なくとも１つのネットワークが、ローカルエリアネットワーク（ＬＡＮ）と、メトロポリタンエリアネットワーク（ＭＡＮ）と、ワイドエリアネットワーク（ＷＡＮ）と、ストレージエリアネットワーク（ＳＡＮ）とを含む、請求項５４に記載のシステム。
【請求項５６】
前記元のメタデータをフィルタリングするために、前記エクストラクタに結合された少なくとも１つのフィルタをさらに備える、請求項４０に記載のシステム。
【請求項５７】
前記エクストラクタが、前記元のメタデータの部分と各データ代理の要素の間の関係を識別する、請求項４０に記載のシステム。
【請求項５８】
前記エクストラクタが、前記関係に従って、前記元のメタデータの部分と各データ代理の前記要素とを選択的に組み合わせることによって、新しいメタデータを生成する、請求項５７に記載のシステム。
【請求項５９】
前記拡張データ代理が、前記新しいメタデータを含む、請求項５８に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００５年２月７日に出願された、出願番号が未決定の、「Ｍｕｌｔｉ−ｄｉｍｅｎｓｉｏｎａｌ  Ｓｕｒｒｏｇａｔｅｓ  ｆｏｒ  Ｄａｔａ  Ｍａｎａｇｅｍｅｎｔ」と題する米国特許出願の恩典を主張する。
【０００２】
本明細書の開示は一般に、データ管理に関する。
【背景技術】
【０００３】
企業サーバは、重要なプロダクションデータをストレージシステムでホストするが、媒体障害からデータセンタ障害にわたり得る様々な障害に対して、このデータを回復力のあるものにする必要があることがある。加えて、この同じ重要なデータに他の企業サーバが同時にアクセスする必要があることもある。これらのアプリケーションは、検索、開示、分析、監視、および監督を含むことができる。前者の必要は、テープベースのバックアップを含み得る、多様なデータ保護方式によって対処されることができ、後者の必要は、その重要なプロダクションデータのレプリカで専門分析サーバを設定することを含み得る、多様なデータ管理方式によって対処されることができる。典型的なデータ保護および管理方式は、いくつかのよく知られた難点を含むことがある。そのような難点は、企業サーバへの直接アクセスが、企業サーバにおいて不安定性および性能負荷をもたらし得る状況を含むことができる。その他の難点は、テープ記憶の順次的かつオフラインの特質に関係することができる。
【発明の開示】
【０００４】
本明細書で言及される各刊行物および特許出願は、各個々の刊行物または特許出願が、参照により組み込まれることを特別かつ個別に指摘された場合と同程度に、その全体が参照により本明細書に組み込まれる。
【発明を実施するための最良の形態】
【０００５】
開放型データ管理アプリケーションのホストを可能にする一方で、ワンパス保護（ｏｎｅ−ｐａｓｓ  ｐｒｏｔｅｃｔｉｏｎ）を利用することによって、データ移動、待ち時間、および後処理を最低限に抑える、多次元データ代理（ｍｕｌｔｉ−ｄｉｍｅｎｓｉｏｎａｌ  ｄａｔａ  ｓｕｒｒｏｇａｔｉｏｎ）ならびに対応するシステムおよび方法が、本明細書で提供される。これらの規模の効率性は、以下のものを含む多様なアプリケーションで利用可能である。
【０００６】
・データ保護（Ｄａｔａ  Ｐｒｏｔｅｃｔｉｏｎ）：データ代理は、アプリケーションフォーマットを認識することができ、任意選択でプロダクションサーバのアプリケーションデータ変換を実施することもできる。これは、サーバ、ネットワーキング、ストレージ、およびその他の企業リソースの効率的利用を最大化する方式で実施されて、劇的に低減された目標復旧時間（ＲＴＯ：ｒｅｃｏｖｅｒｙ  ｔｉｍｅ  ｏｂｊｅｃｔｉｖｅ）および目標復旧ポイント（ＲＰＯ：ｒｅｃｏｖｅｒｙ  ｐｏｉｎｔ  ｏｂｊｅｃｔｉｖｅ）を促進することができる。
【０００７】
・アーカイバル：フォーマットおよびリポジトリ横断的な代理内でデータを配置し、変換する能力は、アクティブ、パッシブ、およびディープアーカイバルを含む多様なアーカイビング機能の実施を促進する。データは、複数の階層をまたいでシングルインスタンス化されることができるが、ビジネス上の必要性を支援して、選択的な複製が維持されることもできる。
【０００８】
・セルフサービス：データ代理は、企業の認証、権限付与、アクセス制御、および監査機能と統合するために実施されることができる。したがって、エンドユーザは、権限をもつアーカイブデータに、信頼できる方式で直接アクセスする権利を与えられることができる。これは、ヘルプデスク負荷を著しく低減することができ、即座の満足を通してエンドユーザの満足感を最大化することができる。
【０００９】
・ライフサイクル管理：データ代理は、ローカルまたはリモートとし得る複数のサーバにまたがることができる。これらのいくつかは、ソースプロダクションサーバ（ｓｏｕｒｃｅ  ｐｒｏｄｕｃｔｉｏｎ  ｓｅｒｖｅｒ）とすることができ、その他は、ニアラインサーバ（ｎｅａｒｌｉｎｅ  ｓｅｒｖｅｒ）とすることができる。データ代理は、オンライン、ミッドライン、ニアライン、およびオフラインを含む、ストレージの複数の階層を利用することができる。したがって、データ代理は、アプリケーションの挙動および企業の必要にとって最適化された、データ配置および移動を実施するために、ストレージの複数のクラスを利用することができる。
【００１０】
・データ拡張およびＨＳＭ：データ代理は、費用対効率の良いストレージ利用などの最適化を達成するために、エイジ（ａｇｅ）、サイズ、またはアクセス頻度などの基準に基づいて、典型的にはオンラインからミッドラインまたはオンラインからニアラインへの階層をまたいだアクティブプロダクションデータのシームレスな移動を促進する一方で、このデータへのシームレスアクセスをユーザに提供し続けることができる。
【００１１】
・保存および処分：ワンパスデータ移動およびシングルインスタンス化保存は、すべてのデータがデータ管理アプリケーションの制御下にあるので、処分方針の正確でタイムリかつ効率的な実施を促進することができる。これは、保存および処分方針が正確に施行されている企業および規制者内の信頼性を向上させる。
【００１２】
・加工流通過程管理（Ｃｈａｉｎ  ｏｆ  Ｃｕｓｔｏｄｙ）検証：データをプロダクションからデータ代理に集約する際に利用されるワンパスデータ移動は、このデータの獲得中に否認防止を実施する能力を簡素化する。これは、単一のデータ管理アプリケーション、単一のデータ移動パス、および単一の統一データリポジトリの存在のため、最適化される。暗号メカニズムが、信頼を満たすために導入されることができる。
【００１３】
・方針マネージャロール：企業は、法令を遵守した方式での企業データの保存および処理に関する方針を定める主体、おそらくは最高法務責任者を指定するように要求されることがある。データ代理における統一されたシングルインスタンス化リポジトリへのワンパスデータ移動の存在は、企業全体にわたりながらも下部組織または個人の必要に選択的に特殊化される方針を定める際の簡潔性および効率性を促進する。
【００１４】
・監査人ロール：企業は、組織の方針が企業データの移動および保存中ならびに企業データへのアクセス中に完全に実施されていることを監視し、検証する監査人として働く、特定の主体を指定する必要があることがある。ワンパスデータ移動、統一されたシングルインスタンス化データリポジトリ、および統合セルフサービス機能の存在はすべて、監査プロセスを簡素化するために否認防止および監査証跡の実施を容易にする。
【００１５】
・監視および監督：電子メッセージングなどのコラボレーションメカニズムの増大する採用およびそれへの依存は、ビジネス効率を促進するが、リスクも助長する。これらのリスクは、企業の知識および知的財産の消失または漏えいを含む。企業資産を保護するため、および規制方針を実施するため、協力を規制する監視および監督メカニズムを組織が実施することが必要なことがある。アーカイブ、統一されたシングルインスタンス化ストレージ、および規制されたセルフサービスへのワンパスデータ移動によるデータ代理は、監視および監督を実施する際の効率性を促進する。
【００１６】
・法的開示：協力およびメッセージングから生成されたデータは、企業にとっての重要なビジネス記録である。内部調査の支援のため、または対外訴訟もしくは防衛の遂行のため、企業はこれらの記録を生成することが必要になることがある。
【００１７】
・訴訟支援：データ代理においてホストされる企業の集約アーカイブへのアクセスの容易さは、訴訟または防衛を支援する証拠の容易な検索を促進する。データ代理は多次元であるので、構成データの適切な部分が、訴訟支援の準備を促進する方式で、準備および維持されることを可能にすることができる。
【００１８】
・災害防護：データ代理は、複数のシステムおよびサイトにまたがる、統一された一貫性のあるアーカイバルストレージを提供することができる。その結果、データ代理は、大規模なサーバおよびサイト障害が存在しても、アーカイブのコピーを保存し、その後、そのデータをシステムまたはサイト復旧のために利用可能にすることが可能である。データ代理は統一されたビューおよび統合された実施を有するので、災害防護用のこの方法は、ストレージにおいてより効率的であり、データ回復力およびプライバシを助長する。
【００１９】
・サービス保全：データ代理は、アプリケーションアウェア（ａｐｐｌｉｃａｔｉｏｎ  ａｗａｒｅ）な方法で、サーバまたはサイト障害をまたいで企業データを保存することができるので、１次サーバまたはサイトが障害をこうむったときに、データ代理が、リダイレクトされたサービスを復旧することは比較的容易である。元のサイトおよびサーバの復旧後、このサービスは、フェイルバックされることができる。
【００２０】
・事業継続：災害防護およびサービス保全によって、データ代理は、大規模な障害および復旧の間わたって、企業プロダクションおよびアーカイブデータへの比較的シームレスなアクセスを保全することができるので、企業における事業継続を最適化することができる。
【００２１】
・異種データソース：データ代理は、データを稠密アプリケーションフォーマットから複数の代替統一フォーマットへマッピングすることができるという点で、多次元であることができる。データ代理は、メッセージングおよびコラボレーションシステムからポータルおよび文書管理システムにわたり得る多様な入力アプリケーションのために、これを行うことができる。このデータはすべて、正規化され、共通リポジトリビューにシングルインスタンス化されることができるので、これは、検索および監査を促進および簡潔化し、処分される必要のあるコピーが制御できる数だけ存在するに過ぎないので、処分を簡潔化する。
【００２２】
・企業検索最適化：複数の異種データソースを調停および集約し、その後、プロアクティブにメタデータを追加する、データ代理の能力のため、これは、より効果的かつ効率的な企業検索機能の実施を促進する。これらの検索は、複数の連合データ代理にわたって組織化されることができる。
【００２３】
図１は、一実施形態による、多次元データ代理システム１００（本明細書では「データ代理システム１００」または「代理システム１００」とも呼ばれる）のブロック図である。データ代理は、データ保護、アーカイバル、メールボックス拡張、セルフサービス、方針管理および監査ロール、法令遵守、キーワードアラート、法的開示、訴訟支援、ライフサイクル管理、階層化ストレージ、災害防護、事業継続、サービス保全、ならびにサービスプロキシを含むデータ管理目的で、アプリケーション一貫性のあるプロダクションデータの一時的レプリカを実施および維持する。
【００２４】
一実施形態のデータ代理システム１００は、１つまたは複数の以下の構成要素を含む。
【００２５】
１．企業サーバ：これらは、メッセージング、コラボレーション、ポータル、またはデータベースを含む、多様なサーバである。これらは、様々な構造化、半構造化、および非構造化データをホストする。これらのサーバは、個別であること、クラスタ化されること、複製化されること、グリッドの構成要素であること、仮想化されること、またはそれらの任意の組み合わせもしくは変形であることができる。一例は、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ  Ｓｅｒｖｅｒであるが、本明細書で説明される実施形態は、そのようには限定されない。
【００２６】
２．企業クライアント：これらは、企業サーバへのエンドユーザアクセスを提供する、多様なクライアントである。一例は、Ｍｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋであるが、本明細書で説明される実施形態は、そのようには限定されない。
【００２７】
３．通常アクセス：これは、企業のクライアントとサーバの間の通常の対話を表す。Ｍｉｃｒｏｓｏｆｔ  ＥｘｃｈａｎｇｅおよびＯｕｔｌｏｏｋの場合、プロトコルは、ＭＡＰＩとすることができるが、本明細書で説明される実施形態は、そのようには限定されない。その他の可能なプロトコルは、ＩＭＡＰ４およびＰＯＰ３を含む。
【００２８】
４．データ代理：これは、企業サーバ用の多様なデータ管理ソリューションおよび企業クライアント用の増強機能を可能にする、これから説明されるシステムおよび方法である。
【００２９】
５．シャドウイング：これは、データ代理においてプロダクション企業データの相対的に最近のコピーを維持するための操作である。このデータは、任意選択的に複数の代替フォーマットに変換されることができ、またメタデータを用いて増強されることができる。
【００３０】
６．リダイレクション：これは、企業サーバがデータ関連の不正行為または損失をこうむった後、データ代理内のシャドウにおいてホストされるデータを使用して、企業サーバを回復させるための機能である。「リダイレクト」という用語は、より具体的には、ターゲットサーバがオリジナルと異なる場合に使用され、ターゲットとオリジナルが同じ場合の一般的用語は、典型的には「復旧」である。
【００３１】
７．代替代理：これは、壊滅的サイト災害からプロダクションデータを保護するためにソースから孤立させられた、任意のデータ代理のおそらくは複数のリモートコピーの１つである。
【００３２】
８．災害防護：これは、壊滅的サイト災害が起きた場合、事業活動を支援するためにデータまたはサービスを復旧する能力である。
【００３３】
９．セルフサービスおよび監査人アクセス：これは、企業クライアントがデータ代理に直接だが安全なアクセスを有するための機能である。これの典型的な使用は、履歴アーカイブへのエンドユーザアクセス、または履歴メッセージング情報を処理する必要がある監査人を含むことができる。
【００３４】
１０．サービスプロキシおよび保全：データ代理または代替代理の１つにおけるアプリケーション一貫性のあるプロダクションデータのコピーの存在は、信頼性、規模、または効率性を増強するために、シャドウ、プロキシ、または置換サーバの元のサービスまたは業務の提供を促進する。
【００３５】
データ代理システム１００の様々な構成要素間の結合は、ホストシステム構成に適するように、無線結合、有線結合、ハイブリッド有線／無線結合、およびその他のネットワーク結合タイプを含むことができる。クライアント（例えば、企業クライアント）ならびにサーバ（例えば、企業サーバおよび代理サーバ）は、プロセッサベース装置の任意のタイプおよび／または組み合わせとすることができる。データ代理システム１００の構成要素間のネットワーク結合は、ワイドエリアネットワーク（ＷＡＮ）として示されているが、ネットワークおよびネットワーク構成要素は、いくつかの名前を挙げれば、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、プロプライエタリネットワーク、バックエンドネットワーク、およびインターネットを含むが、これらに限定されない、任意のタイプ、数、および／または組み合わせのネットワークおよび対応するネットワーク構成要素とすることができる。
【００３６】
図２は、一実施形態による、データ代理の方法２００（「データ代理方法２００」または「代理方法２００」とも呼ばれる）についてのフローチャートである。データ代理の方法２００の流れの一例は、以下のように進行する。
【００３７】
・開始：データ代理は、タイマ、イベント、またはリクエストによってトリガされる動作を通して、維持またはアクセスされる。
【００３８】
・分類１：タイマ、イベント、またはリクエストのどれを処理するのかを決定する。
【００３９】
・タイマ：これらは、スケジュールされたイベント用に構成され、いくつかの保守またはデータ投入動作が、データ代理用に実行されることを示す。
【００４０】
・イベント：これらは、処理される必要がある、プロダクションまたはニアラインサーバ上での注目すべき変更を示す。
【００４１】
・リクエスト：これらは、ユーザまたは管理者からのアクセスまたはコンフィグレーションの試みである。
【００４２】
・全コピー：これは、ターゲットプロダクションサーバ上のすべての企業データの全ベースラインコピーを獲得する。ローカルまたはリモートの複数のそのようなプロダクションサーバが存在することがある。全コピー動作は、相対的に低頻度で実行される。
【００４３】
・ログシップ（ｌｏｇ  ｓｈｉｐ）：これは、最終ログシップ以降に、プロダクションサーバ上で発生した変更を獲得する。
【００４４】
・動的ログシッピング（ｄｙｎａｍｉｃ  ｌｏｇ  ｓｈｉｐｐｉｎｇ）：これは、プロダクションサーバ上でのデータ変更の通知に動的に応答し、その変更データをプロアクティブにコピーする、ログシップの補助動作である。
【００４５】
・分類２：これは、データ代理に送られるリクエストのタイプを分類する。
【００４６】
・クエリまたはブラウズ：これは、アーカイブデータの検索またはブラウズを試みている監査人またはユーザとすることができる。
【００４７】
・添付ファイル検索：これは、ユーザが拡張データにアクセスしたために結合される添付ファイルなどのデータアイテムを獲得するための、データ代理へのリクエストである。
【００４８】
・停止：データ代理方法の終了。
【００４９】
一実施形態の多次元データ代理は、データ保護および管理に増強機能を提供することによって、ニアラインシステムにおけるディスクストレージコストを減少させるために使用されることができる。これらのシナリオでは、ニアラインサーバは、プロダクションデータの最近または準リアルタイムのコピーをホストすることができる。ニアラインサーバは、任意選択的に、データ保護および管理メカニズムおよびプロセスにおいて、アクティブな仲介者として機能することができる。ニアラインサーバはまた、任意選択的に、企業サーバによって提供されるサービスの保全において、アクティブな関与者として機能することもできる。このデータ代理機能は、企業サーバ自体によって提供されるデータのスーパーセットであるデータの集約ビューを提供するために、複数の次元で拡張されることもできる。そのような次元の１つは、企業サーバのデータの時間横断的なビューとすることができ、別の次元は、複数の異種の企業サーバの統合ビューとすることができる。また別の次元は、後続のデータ管理アプリケーションの効率性を促進する、メタデータの追加、集約、およびカスケーディングとすることができる。複数のそのような次元およびそれらの組み合わせが可能である。
【００５０】
多次元代理の実施のいくつかは、高位レイヤによって再利用可能な方式で、データ移動および管理機能の低位レイヤを実施することによって、集約の効率性を促進することもできる。これらのワンパスメカニズムは、企業サーバ、ネットワーキング、およびその他の企業リソースの使用における節減を助長することができる。データ代理は、別個のニアラインサーバ上に存在することができ、またはオンラインもしくはオフラインサーバ上でホストされることができ、またはそれらの何らかの組み合わせでホストされることができる。これらのサーバ自体は、ＡＳＩＣまたはＦＰＧＡから、マイクロプロセッサベースのシステム、さらにメインフレームサーバにまでわたり得る、任意の適切なコンピューティング装置から構成されることができる。ニアラインおよび企業サーバは、単一システムとすることができ、またはクラスタ化、複製化、仮想化、分散化、グリッドの部分、ピアツーピア、またはそれらの何らかの組み合わせとすることもできる。データ代理ストレージは、元のデータと同じストレージ装置を共用することができ、データ代理は、元の企業サーバと同じサーバを共用することもできる。
【００５１】
このソリューションは、例えば、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ  Ｓｅｒｖｅｒなどの、電子メッセージングサーバの文脈で説明される。しかし、本明細書で説明されるアイデアは、インスタントメッセージングおよびコラボレーションを含むメッセージングのより大きなクラスに等価なサービスを提供するために、容易に拡張されることができる。さらに、本明細書で説明される実施形態は、ディレクトリサーバおよび文書管理システムなどのその他の企業サーバにも等しく関連し、一般に、構造化、半構造化、または非構造化データ上で動作する任意の企業サーバに等しく関連する。
【００５２】
本明細書では、転送、相互接続、またはネットワークについての言及はどれも、従来のＥｔｈｅｒｎｅｔ（登録商標）、ストレージエリアネットワーク、またはその他のタイプのネットワークを考慮に入れている。プロトコルは、ＴＣＰ／ＩＰおよび階層化プロトコル、ｉＳＣＳＩ、ＦｉｂｒｅＣｈａｎｎｅｌ、Ｉｎｆｉｎｉｂａｎｄ、ＶＩ、ＲＤＭＡ、ならびに多様なその他のプロトコルを含むことができる。接続性は、データセンタ内の局所的なものとすることができ、またはメトロポリタンもしくはワイドエリアネットワークにわたる分散化されたものとすることもできる。また本明細書では、システムまたはサーバについての単数形での言及は、そのシステムまたはサーバの複数の実例も包含する。
【００５３】
以下の説明では、多次元データ代理の実施形態についての完全な理解および実施可能な説明（ｅｎａｂｌｉｎｇ  ｄｅｓｃｒｉｐｔｉｏｎ）を提供するために、多数の具体的な細部が導入される。しかし、当業者であれば、これらの実施形態が、１つまたは複数の具体的な細部を用いずに、またはその他の構成要素、システムなどを用いて、実施され得ることを理解されよう。その他の場合には、開示される実施形態の態様を不明瞭にすることを避けるため、よく知られた構造または動作は示されず、または詳細に説明されない。
概念および用語
管理者ロール：これは、何らかの組み合わせまたは変形が行われた、サーバ、ネットワーク、ストレージ、ＳＡＮ、およびその他の企業の構成要素に関連する、計画、設置、保守、増強、トラブルシューティング、およびその他の活動におそらく責任を負う、１つまたは複数の主体である。
【００５４】
方針マネージャロール：これらは、データセンタ、デスクトップ、ストレージ、およびデータセンタのその他のエリアで実施される方針の定義におそらく責任を負う、１つまたは複数の主体である。複数の責任の１つは、その組織用のデータ保存および処分方針の定義を含むことができる。これは、最高法務責任者とすることができ、または指定することができる。この責任は、先に説明された管理者ロールに委嘱されることができる。
【００５５】
監査人ロール：これらは、方針マネージャによって定義された方針の実施の監視におそらく責任を負う、１つまたは複数の主体である。いくつかの組織では、方針マネージャと監査人のロールは、同じ個人または個人の組をもつことが可能である。これは、最高情報責任者とすることができ、または指定することができる。この責任は、先に説明された管理者ロールに委嘱されることができる。
【００５６】
エンドユーザロール：これらの主体は、企業のＩＴ部門によって提供されるサーバ、デスクトップ、モバイルシステム、およびサービスのエンドユーザである。これらは、これらのシステムおよびサービスに合法的な認可されたアクセスを行える従業員、契約者、訪問者、その他を含むことができる。
【００５７】
ニアラインサーバ：これらは、データ代理用の実施環境候補である。しかし、そのようなサーバを用いずにデータ代理を実施することも可能とすることができる。代替策は、既存のサーバまたはストレージサブシステムまたはデータ管理メカニズムとの共存を含むことができる。サーバが使用される場合、これらは、複数のシステムから構成されることができ、クラスタ化、複製化、分散化、仮想化されること、またはグリッドの部分であることができる。
【００５８】
ワンパスデータ保護（または単に「ワンパス」）：これらは、データ移動および処理を、重複活動を排除でき、その後、結果をこのデータの１つまたは複数の消費者またはポストプロセッサから利用可能にし得る方式で、おそらくは複数の消費者にわたる実施のコストを償却する方式で、利用するメカニズムであり、削減されたコスト、削減された負荷、短縮された処理時間、より高い性能、より高いスケーラビリティ、改善されたセキュリティ、改善されたアクセサビリティ、その他を含み得る効率性を達成できる方式でおそらく実施される。
【００５９】
プロダクション、企業、またはアプリケーションサーバ：本明細書では、企業または組織は交換可能に使用されることができ、本明細書では交換可能にプロダクション、企業、またはアプリケーションサーバと呼ばれ得る、単一の、複数の、クラスタ化、分散化、複製化、仮想化された、またはその他の任意のやり方で増強および接続された、計算能力がある任意の構成要素から構成されるサーバを利用する、おそらくは１つの場所内のまたは地理的に分散された、個人または個人のグループを指すことができる。
【００６０】
その他のロールが企業または組織に存在することが可能である。これらのロールが、何らかの所定の手法で、変更され、拡張され、または組み合わされることも可能である。
データ管理のためのメカニズム
このセクションは、データ管理アプリケーションの４つの主要なカテゴリについて説明する。これらは、「バックアップ」、「レプリケーション」、「スナップショット」、および「アーカイバル」である。以下のセクションは、これらのメカニズムが、データ代理によって促進される効率性の多くを達成し得る方法について説明する。加えて、これらのセクションは、データ代理によって促進される新しいデータ管理アプリケーションについても説明する。
バックアップ：
図３は、完全および増分バックアップを保存するのにテープまたはディスクを使用するバックアップアプリケーションによって保護されるメッセージングサーバを含む、システム３００である。人為的と考えられるエラー、動作エラー、またはメッセージングサーバ障害のためにテープまたはディスクから回復する必要がある場合に、メッセージングストアを再構成するためにテープまたはディスクから読み取りを行うデュアル回復アプリケーションが存在する。
【００６１】
バックアップおよび回復ソリューションの構成要素は、以下を含むことができる。
【００６２】
１．メッセージングサーバからデータの全コピーまたはデータ内の増分変化を獲得するためのＡＰＩまたは等価メカニズム。
【００６３】
２．完全および増分バックアップを保存するためのテープなどの持続性媒体。
【００６４】
３．サーバ障害が発生したときの、この持続性媒体へのアクセス。
【００６５】
４．最後の完全バックアップを復旧し、それに以後のすべての増分バックアップを適用することによって、メッセージングサーバにデータを復旧し直すためのＡＰＩまたは等価メカニズム。
【００６６】
バックアップは、その機能をデータ回復力および分析について制限されたものにする、複数の不具合をもつことがある。これらは、以下のものを含む。
【００６７】
・バックアップアプリケーションが動作しているときに、長いバックアップウィンドウが存在することがあり、これは、メッセージングサーバおよびネットワークに負荷をかけ得る。これは、テープの低速性および順次性と、復旧時間を最短化し、信頼性を向上させる必要から、頻繁な完全バックアップを行う必要があることが原因である。
【００６８】
・このバックアップウィンドウの結果として、企業の管理者は、相対的に低頻度でサーバ上でのバックアップを実行する。また、その結果として、企業サーバ上でデータの喪失が発生した場合、データ喪失のウィンドウは、最後のバックアップ段階まで及ぶことがある。１日のこの目標復旧ポイント（ＲＰＯ）は、一般に貧弱であると考えられる。
【００６９】
・テープのオフライン性および順次性のせいで、データアクセスおよび分析などのアプリケーションを支援するためにデータを再構成することは、厄介であり、時間を浪費し、費用がかかり、スピードが遅い。時間または空間横断的など複数の次元でビューを再構成する必要がある場合、この負担は著しく高まり得る。
【００７０】
・テープのオフライン性および順次性と、最後の完全バックアップに増分バックアップを適用するのにかかり得る時間のせいで、障害後に企業サーバにデータを復旧し直すことは、厄介であり、スピードが遅いことがある。サービス喪失のウィンドウまたは目標復旧時間（ＲＴＯ）も、貧弱であることがある。
【００７１】
・テープ媒体上でデータの破壊もしくは喪失、またはその他の種類の障害が発生した場合、これは、企業サーバにデータを復旧する試みが行われるまで、発見されないことがある。
【００７２】
・テープの代わりにディスクが使用される多くのケースでは、完全および増分セットは、「消費」されることなく、ディスク上に配置される。これは、テープに関連する複雑さおよび待ち時間を排除することができるが、復旧時に増分バックアップが最後の完全バックアップに適用される必要があるという限界を依然として有する。これは、ディスク空間の非効率的な使用をもたらすことがあり、したがって、ディスク上に保存され、回復され得る、時間的に幅のあるバックアップを制限する。
【００７３】
・テープおよびテープ／ディスクバックアップに伴う別の課題は、（データストア全体を復旧するのではなく）粒度の細かいアイテムまたはオブジェクトレベルでデータを復旧するために、複数のバックアップパスがおそらく使用されることである。（メッセージングおよびｅメールデータ保護コミュニティにおいてブリックバックアップとしても一般に知られる）セカンドパスは、非常に低速で、著しい企業サーバ負荷がそれを魅力のない選択肢にする原因となり得る、アイテムレベルにある。
【００７４】
・テープの物理的管理は、サイト内におけるものも、オフサイトの保管所とのテープの引き渡し／受け取りも、同様に復旧プロセスに著しいオーバーヘッドを追加し得る。
【００７５】
・テープ媒体は、障害を起こしやすいことがある。これらの障害は通常、データを復旧する試みが行われたときにだけ検出される。そのような障害は潜在的に、目標復旧ポイントを著しく低下させ得る。
レプリケーション：
レプリケーションは、企業サーバデータのコピーを代替ロケーションに作成するためのメカニズムである。これは、その企業サーバの通常運用中に発生している。このレプリケーションは、同期または非同期とすることができる。前者のケースでは、複製されたコピーは、元となる書き込みが承認される前に、代替媒体上のディスクにコミットされる。これは、障害に対してより回復力があり得るが、企業サーバへの待ち時間の影響に関してかなり高価となり得る。非同期レプリケーションは、潜在的にコストおよび複雑さを低下させ得る、バッチ化およびキャッシングなどの最適化を利用する。
【００７６】
図４は、レプリケーションを使用して保護されるメッセージングサーバを含む、システム４００である。レプリケーションは、この図に示されるように、ボリュームレベルを含む、Ｉ／Ｏスタックにおける複数のレベルで実施されることができる。ボリュームレベルレプリケーションは、ホスト上、ＳＡＮ内、バックエンドＲＡＩＤストレージ内、またはそれらの何らかの変形もしくは組み合わせにおいて、実施されることができる。
【００７７】
レプリケーションの限界として考えられることとしては、生成されるリモートコピーが一貫性のあるイメージをもたないことである。言い換えると、それは「クラッシュコンシステント（ｃｒａｓｈ  ｃｏｎｓｉｓｔｅｎｔ）」であるに過ぎない。したがって、複製されたコピーは、アプリケーション一貫性を実施するための追加メカニズムおよび処理なしに、必ずしも使用可能であるとは限らない。アプリケーションの複雑さのため、このタイプのレプリケーションは、制限された障害および回復シナリオを取り扱う。
スナップショット：
このメカニズムは、企業サーバデータのポイントインタイム（ｐｏｉｎｔ−ｉｎ−ｔｉｍｅ）ビューを取得し、任意選択的に、それをおそらく異なるサーバ上の代替媒体に取り込む。このメカニズムは、ポイントインタイム・スナップショットを生成するために、ボリュームマネージャ、ストレージエリアネットワーク（ＳＡＮ）、またはストレージ内のメカニズムを利用することができ、ポイントインタイム・スナップショットは、その後、代替サーバまたは持続性のあるバックアップ媒体にコピーされる。スナップショットメカニズムは、データの一貫性のあるポイントインタイム・ビューを生成するために、システムソフトウェアもしくはアプリケーションまたはその両方による任意選択的な関与を含むことができる。そのようなメカニズムの一例は、データ管理アプリケーションが使用するためのアプリケーション一貫性のあるスナップショットを提供するために準拠アプリケーションを利用することができる、Ｍｉｃｒｏｓｏｆｔ製のＶｏｌｕｍｅ  Ｓｈａｄｏｗ  Ｃｏｐｙ  Ｓｅｒｖｉｃｅ（ＶＳＳ）である。
【００７８】
図５は、スナップショットメカニズムを含む、システム５００である。このスナップショットは、ホストベースのボリュームマネージャを利用することによってホスト上で直接に実施されることができ、または専用ＳＡＮもしくはＲＡＩＤストレージハードウェアを使用して実施されることができる。スナップショットとレプリケーションの相違は、スナップショットが、通常はアプリケーションの観点から一貫性があることである。
【００７９】
スナップショットには以下を含む複数の課題が存在することが知られている。
【００８０】
１．これらのスナップショットは、データの離散的なポイントインタイム・イメージであり、連続的ではない。
【００８１】
２．（下位にあるコピーオンライト（ｃｏｐｙ−ｏｎ−ｗｒｉｔｅ）動作のせいで）プロダクションサーバに有限のおそらくは破壊的な負荷影響がかかることがある。
【００８２】
３．完全スナップショットの効率を改善する増分スナップショットは、増分バックアップと同じ問題を有することがある。
【００８３】
４．データへのきめ細かなアクセスが行えない。稠密なアプリケーションデータのスナップショットは、細部へのアクセスを行うために、これらのフォーマットの詳細な知識をもつことをスナップショットの消費者に要求することがある。
【００８４】
５．これらのスナップショットは、準拠「ライタ」および「プロバイダ」のアベイラビリティに応じて、常に一貫性があるとは限らないことがある。言い換えると、「アプリケーション一貫性のある」スナップショットを取得する能力は、スナップショットがとられる前に、そのアプリケーションの関与が適切に休止状態になることを必要とする可能性が高い。
【００８５】
６．先の問題の結果として、アプリケーション一貫性のために既存アプリケーションをスナップショットアウェア（ｓｎａｐｓｈｏｔ−ａｗａｒｅ）にするように、既存アプリケーションに設計変更を施すことが必要なことがある。
【００８６】
７．時間経過に伴う企業サーバ上のデータの変更を取り込むために、複数のスナップショットを生成することが必要になることがある。これらの複数のスナップショットの効率的保存のための任意選択的なメカニズムが存在するとしても、保存され得るスナップショットの数には上限が存在することがある。
アーカイバル：
アーカイビングは、メッセージングサーバ上で生成された、またはメッセージングサーバに到着した、すべてのメッセージアイテムのコピーを生成することを試みる。同様のメカニズムは、その他のタイプのサーバ用にも存在する。メッセージングサーバの場合、アーカイバル動作は、メッセージアイテムの到着、生成、または変更などのイベントによってトリガされることができる。アーカイバル動作はまた、事前構成されスケジュールまたはユーザリクエストによってもトリガされることができる。必要の応じておよびユーザコンフィグレーションに応じて、元のデータは、アーカイブにコピーされ、または徐々に出力されることができる。
【００８７】
アーカイビングの共通目的は、通常は監視および法令遵守のため、すべてのトランザクションの記録を生成することである。メッセージングサーバは、アーカイバルを実施するために、少なくとも３つの共通メカニズムを有する。これらは、ＳＭＴＰに接続し、ＭＡＰＩなどのクライアント通信プロトコルを使用してメッセージアイテムに到達するためにｅメールクライアントになりすまし、または「ジャーナリング」と呼ばれる機能を利用する。アイテムを抽出するためのこのメカニズムは、「ブリック」抽出としても知られている。このメカニズムは、効率性の欠如および獲得されたデータの忠実度の欠如を含み得る、複数の課題および制限を有することがある。
【００８８】
図６は、ＳＭＴＰを介して送信されるｅメールを傍受することを含む、アーカイバル６００を示している。図は、明示的なＳＭＴＰプロキシの使用を示しているが、ｅメールメッセージを複製し獲得するという同じ目的を達成するために、ＳＭＴＰサーバに直接アクセスし、ＳＭＴＰサーバからコールバックを受信することも可能である。この例は、メッセージングサーバに特化されているが、等価かつ／または代替メカニズムが、その他のタイプの企業サーバ用に存在することができる。
【００８９】
先の図は、アーカイバル目的で、アーカイバルシステムがｅメールクライアントになりすまして、すべてのメッセージングデータにアクセスすることによって、ｅメールが複製され、獲得される、アーカイバルの複数の可能な変形の１つを記述している。以下の構成要素が説明されている。
【００９０】
１．インバウンドまたはアウトバウンドｅメールは、ＳＭＴＰリレーまたはプロキシにおいて傍受されることができる。メッセージングサーバ内を出発点および終着点とするメッセージングサーバ内のすべてのｅメールも、ＳＭＴＰリレーまたはプロキシに転送される。
【００９１】
２．傍受されたｅメールは、コピーされ、アーカイブリポジトリに転送されることができる。
【００９２】
図７は、特定のメールボックスに到着する、または特定のメールボックスを出発したすべてのｅメールが、ｅメールクライアントなりすましたプロキシによってアクセスされ、複製される、なりすましを使用するメカニズムを介して、ｅメールが獲得される、アーカイバル７００を示している。
【００９３】
１．アプリケーションは、ｅメールクライアントになりすまし、メッセージングサーバにアクセスすることができる。このアプリケーションは、アーカイブされるすべてのメールボックスにアクセスするのに十分な特権を有する。
【００９４】
２．その後、アプリケーションは、アーカイブされるメッセージを複製し、アーカイブリポジトリに転送する。
【００９５】
図８は、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ  Ｓｅｒｖｅｒジャーナリングを使用する、アーカイバル８００を示している。しかし、その他のシステムは、同様の方式で使用され得る、システムに固有なまたはアドオン機能によって導入された等価な機能を提供することができる。この図では、以下のフェーズが説明される。同様の目的を達成するために、その他の代替策も可能である。
【００９６】
１．ジャーナルメールボックスへの取り込み：Ｅｘｃｈａｎｇｅ内の特定のメールボックスが、「ジャーナルメールボックス」として特別に構成される。これは、その他の特定のメールボックスを出発した、またはその他の特定のメールボックスに配送されるすべてのｅメールのシンク（ｓｉｎｋ）である。
【００９７】
２．ｅメールなりすましによる任意選択的な抽出：ジャーナルメールボックスに到着するｅメールは、ジャーナルメールボックスへのアクセス許可を有するｅメールなりすましクライアントによって、任意選択的に抽出または複製されることができる。
【００９８】
３．アーカイブへの任意選択的な保存：ｅメールなりすましは、任意選択的にすべてのメッセージをジャーナルメールボックスからアーカイブに保存することができ、任意選択的にジャーナルメールボックスを空にすることができる。
【００９９】
これらのアーカイバルメカニズムは、以下を含み得るよく知られた制限を有することがある。
【０１００】
・メッセージアイテムを獲得する方法は、ｅメールクライアントまたはＳＭＴＰサーバ／リレーになりすますので、本質的に低速になることがある。これは、プロダクションサーバおよびネットワーキング資源をそれが使用するせいで、通常の動作にとっての障害となり得る、許容できないほど長い「アーカイバルウィンドウ」をもたらし得る。
【０１０１】
・ＳＭＴＰサーバ／リレーなりすましメカニズムが使用される場合、これは、おそらくすべてのアイテムにアクセスし複製する必要のせいで、ｅメールの着信および発信のスピードを低下させ得る。
【０１０２】
・ＳＭＴＰなりすましが使用される場合、これは、（同じメッセージングサーバ上のメールボックス間の内部メッセージであっても）すべてのｅメールがＳＭＴＰリレーを介してリダイレクトされることが余儀なくされ得る。
【０１０３】
・ジャーナルアーカイビングまたはクライアントなりすましメカニズムが使用される場合（これは「ブリック抽出」としても知られる）、これは、プロダクションサーバにかけられる過度の負荷をもたらし得る。
【０１０４】
・どのような形式のアーカイバルの場合でも、アイテムが転送されるので、企業ネットワークに著しい負荷がかかり得る。
【０１０５】
・ＳＭＴＰなりすましメカニズムは、カレンダアイテム、予約、契約、ジャーナル入力、ノート、タスク、ルール、およびその他のカスタムタイプのメッセージングアイテムなど、非ｅメールアイテムを獲得する能力を妨げ得る。
【０１０６】
・ＳＭＴＰなりすましメカニズムは、アーカイブフレンドリなＳＭＴＰフォーマットでのメッセージ内容の獲得を可能にするために、（メッセージのリッチテキストフォーマッティングなど）いくつかのメッセージングサーバ機能の使用に制約を課し得る。
【０１０７】
・データ内容忠実度の程度は、（主題、本文、およびｅメールメッセージの添付ファイルなどの必須内容の獲得にだけ重点が置かれるＳＭＴＰなりすましの場合の低忠実度から、データ忠実度がプロダクションメッセージングサーバにかけるサーバ性能負荷のせいで、データ忠実度について妥協が行われ得る、ＭＡＰＩなどのプロトコルを使用するクライアントなりすましの場合の多様な忠実度まで）様々であり得る。
【０１０８】
・メールボックスマッピング忠実度の程度は、様々であり得る（複数のメールボックスによって送信および受信されたメッセージの単一コピーが獲得される、ＳＭＴＰなりすましおよびジャーナリングベースのシステムの場合、忠実度は通常は低いが、これらのメッセージを送信および受信する際に関連するすべてのメールボックスを高い信頼性で識別することを難しくすることがあり、これは、ＢＣＣおよび配布先リストなどの機能の使用のせいでさらに複雑にされ得る）。
【０１０９】
・ＳＭＴＰまたはジャーナリングまたはｅメールなりすまし抽出は、データがアーカイブに到着する前にデータが暗号化されずに存在することのある既存および追加配備システムの中を流れることがある共通アーカイビングチャネルを介した、すべてのメールボックスについてのブリックレベル情報のフローのために、通常は追加のセキュリティを必要とするので、アーカイバルは、追加のセキュリティインフラストラクチャを要求する。
低コストディスク（およびニアラインサーバ）に向かう傾向：
ディスクは、テープのより廉価な代替に着実になっており、そのことは、このセクションで説明されるニアラインサーバの形態での採用を促進し得る。データ管理アプリケーションの効用の例として、ニアラインストレージおよび／またはサーバをますます有効利用させるものであるが、離散的であるため、利用可能な効率向上策のすべてを必ずしも有効利用できるわけではない。
【０１１０】
図９は、データ管理機能を提供するニアラインサーバを含む、システム９００である。システム９００は、テープベースのバックアップ／アーカイバルメカニズムと並列して、それの代わりに、またはそれのパス内で、機能することができる。
【０１１１】
先の図では、以下のデータパスが説明される。
【０１１２】
１．プロダクションからニアラインサーバ：データは、企業プロダクションサーバ上で獲得され、データ管理の目的でニアラインサーバに転送される。
【０１１３】
２．ニアラインサーバからテープストレージ：ニアラインサーバからのデータは、媒体障害またはデータ破壊などの壊滅的エラーからニアラインサーバを保護するために、任意選択的にテープベースのリポジトリに複製される。
【０１１４】
３．プロダクションサーバからテープストレージ：プロダクションサーバは、従来のテープベースのバックアップ／アーカイバルを使用して、任意選択的に保護され続けることができ、このメカニズムは、任意選択的にニアラインサーバベースのデータ管理機能と共存する。
ニアラインサーバ：ディスクキャッシュ
ニアラインストレージの様々な可能な配備の１つは、従来のテープベースのバックアップまたはアーカイバルメカニズムのデータパス内に、ニアラインサーバを「ディスクキャッシュ」として導入することである。これは、テープへの転送をスピードアップする能力、およびディスクキャッシュ内にまだ存在するアイテムにアクセスする場合にテープを媒体パスする任意選択的な能力を含む、複数の利点を提供することができる。図１０は、ニアラインサーバをテープ用のディスクキャッシュとして含む、システム１０００である。
【０１１５】
先の図では、概念を社会化（ｓｏｃｉａｌｉｚｅ）する目的で以下のデータパスが説明されるが、その他の実施も可能である。
【０１１６】
１．バックアップアプリケーションへの転送：データは、企業サーバから獲得され、バックアップアプリケーションによって転送される。
【０１１７】
２．ディスクキャッシュへのバックアップアプリケーションアクセス：バックアップアプリケーションは、ディスクキャッシュとして機能するニアラインサーバに、データをストリーム転送する。
【０１１８】
３．バックエンド・テープ・ストレージを用いたディスクキャッシュ統合：ディスクキャッシュにステージされたデータは、テープに転送される。
【０１１９】
４．ディスクキャッシュへの回復アプリケーションアクセス：回復アプリケーションは、データを必要とする場合、ディスクキャッシュを介してテープにアクセスし、したがって、いくつかのケースでは、回復アプリケーションは、それが必要とするデータを、テープまで取りに行く必要なく、ディスクキャッシュ内に見出す。
【０１２０】
５．企業サーバへの回復アプリケーション転送：回復アプリケーションは、リクエストされたデータを企業サーバに提供する。
ニアラインサーバ：仮想テープライブラリ
従来のテープベースのデータ管理を増強するために、低コストディスクストレージをおそらくニアラインサーバの形態で導入するのに利用可能であり得る別のメカニズムは、仮想テープライブラリである。この方式では、ニアラインサーバが、テープライブラリになりすます。それが提供するインタフェースは、ディスクが有するテープを上回る機能および性能を下位にあるニアラインストレージが提供することを除いて、テープと共に動作するように設計された企業ソフトウェアおよびメカニズムの再利用を促進する。
【０１２１】
図１１は、ニアラインストレージを使用する仮想テープライブラリを含む、システム１１００である。ストレージエリアネットワークおよびより複雑なトポロジを含むその他の変形も可能である。この例では、単一のメッセージングサーバが、企業サーバの代表として例示されているが、等価の機能を任意の数の異なるタイプのサーバに提供することを可能にすることもできる。
【０１２２】
先の図では、以下のデータパスが、例として示されている。
【０１２３】
１．バックアップアプリケーションへの転送：バックアップアプリケーションは、企業サーバからバックアップされたデータのコピーを抽出する。
【０１２４】
２．テープになりすましたニアラインへの転送：バックアップアプリケーションは、テープまたはテープライブラリになりすまし得るディスクにデータを保存する。
【０１２５】
３．回復アプリケーションによるアクセス：回復アプリケーションは、テープまたはテープライブラリになりすましたディスク上のデータにアクセスする。
【０１２６】
４．企業メッセージングサーバへの転送：回復アプリケーションは、企業サーバにデータを転送する。
ログシッピング：
ハイエンドのデータベース管理システムに通常は限定されるこの機能は、使用中のデータベースから別のホット・スタンバイ・データベースへの、変更の低コスト伝播を容易にする。ログは、このターゲットデータベース上で適用される。
【０１２７】
この機能は、データベースシステムに通常は制限され、あるケースでは、ホット・スタンバイ・データベースが同時にアクセスおよび使用されることを妨げることがある。ターゲットデータベースは、データセンタに対してローカルとすることができ、またはリモートとすることもできる。
【０１２８】
図１２は、ログシッピングを含む、システム１２００である。この例では、左側の企業アプリケーションが、プライマリデータベースに対して変更をかける。データベース管理システムは、これらのログを周期的にターゲットデータベース管理サーバに転送し、ログはそこで、ホット・スタンバイ・レプリカに適用されて、それを最新状態にする。
【０１２９】
先の図では、以下のデータパスが示されている。
【０１３０】
１．おそらくアプリケーションまたはクライアントの書き込みによって、変更がプロダクションシステム上で発生する。これらの変更は、ライトアヘッドロギングまたは類似の方式を生じさせる。
【０１３１】
２．これらの変更は、おそらくはライトアヘッドログの形式で、ホット・スタンバイ・データベース・サーバに転送される。
【０１３２】
３．これらの変更は、ホット・スタンバイ・データベースに適用されて、プロダクションサーバと共にそれらを最新状態にする。
サーバクラスタリング：
サーバクラスタリングは、フォールトトレランスまたはスケーラビリティ（あるいは両方）を提供するために、複数のコンピューティングシステムが協力するためのメカニズムである。２つ以上のコンピュータノードが、リモートのネットワークアクセス可能なエンティティに対して、単一エンティティとして現れる。これらのコンピュータノードは、アクティブ（処理中）またはスタンバイ（アクティブで障害が発生するのを待機中）が組み合わされた状態にある。
【０１３３】
図１３は、サーバクラスタリングを含む、システム１３００である。負荷バランシングなど、その他のタイプのクラスタリングも存在する。この特定の例は、ストレージエリアネットワークおよび調整のための共有クォーラムディスクを使用する、双方向クラスタ「無共有」アクティブ／パッシブ・クラスタである。
【０１３４】
サーバクラスタは、コンピュータシステムを拡大し、それらを限られた障害に対して回復力のあるものにするための、効果的なメカニズムである。しかし、これらは、限界を有し、したがって、データ管理アプリケーションに対する制限された適用性を有する傾向にある。
【０１３５】
・クラスタは、システムをシステム障害に対して耐性のあるものにするが、データ破壊は含まない。その結果、データ破壊が存在する場合、これは、その他のノードに伝播されることができ、障害は、クラスタによって緩和されることができない。
【０１３６】
・クラスタは、１つのノードをプロダクションメッセージング用に、別のノードをデータ管理および分析用にするなど、クラスタ内の個々のノードを異なる目的に充てることを容易に可能にしない。
【０１３７】
先の図は、「ストレージエリアネットワーキング」に言及している。これは、Ｆｉｂｒｅｃｈａｎｎｅｌ、ｉＳＣＳＩ、Ｉｎｆｉｎｉｂａｎｄ、またはその他の多様な技術などの技術の組み合わせを使用するネットワークである。このネットワークは、地理的に異なるロケーション間の接続性を提供するために、仲介メカニズムによって任意選択的にブリッジされることができる。本明細書では、ストレージエリアネットワーキング（または「ＳＡＮ」）に対する言及はすべて、プロトコル、技術、および実装のすべての変形および組み合わせを包含することが意図されている。
ジオクラスタリング：
これは、ＭＡＮもしくはＷＡＮなどの長距離ネットワークまたはその他の任意のタイプのネットワークを介して、ローカルサーバのリモート・ホット・スタンバイ・レプリカをほとんど連続的に生成する方式である。壊滅的なサイト障害が発生した場合、リモートレプリカが引き継ぎ、データアクセスおよびサービスを回復することができる。図１４は、ジオクラスタリングを含む、システム１４００である。
【０１３８】
以下の例では、以下のパスが示されている。
【０１３９】
１．インターセプタ：これは、プロダクションサーバサイト上のデータに発生するすべての変更を獲得するためのメカニズムである。このプロダクションサーバ自体は、従来通りクラスタ化されることができる。傍受メカニズムは、先に説明されたレプリケーションにおけるものと同様である。
【０１４０】
２．トランスファ：獲得された変更は、ＭＡＮもしくはＷＡＮ、またはＡＴＭからＳＯＮＥＴにわたる技術を使用し得る等価のネットワークを介して輸送される。変更は、おそらく長いネットワーク待ち時間のせいで非同期に転送されることがあるが、これらを同期させることは技術的に可能である。
【０１４１】
３．アップデータ：リモートサイトにおいて、変更は、データのコピーに適用されて、それを最新状態に維持する。更新が非同期である場合、ある状況下では、いくつかの有限なデータ喪失が発生する。このリンクも、リモート・スタンバイ・サイトがプライマリサイトにおける障害を検出するためのメカニズムである。その他のメカニズムも可能である。
【０１４２】
４．フェイルオーバ：プロダクションサイトにおける障害が検出された場合、スタンバイサーバが動き出し、サービスおよびデータアクセス復旧を提供することができる。いくつかのシナリオでは、元のアプリケーションは、フェイルオーバされて、復旧されたリモートサービスにアクセスすることができる。データおよびサービスを元のサーバまたは置換サーバに戻すために、相補的なフェイルバックメカニズムが通常は存在する。
データおよびサービスプロキシ
エッジ上（ｏｎ  ｔｈｅ  ｅｄｇｅ）でのデータのキャッシングと同様に、エッジ上でサービスをキャッシュすることも可能である。このメカニズムは、任意選択的に、ニアラインサーバおよびデータ管理技法を利用することができる。図１５は、サービス最適化およびサービス継続性をリモートサイトに提供するメッセージングサーバをキャッシュすることを含む、システム１５００である。
【０１４３】
サービスプロキシングは、プライマリサイトおよびすべてのリモートサイトが同時に動作できる点で、ジオクラスタリングとは異なる。データおよびサービスプロキシの以下の構成要素が、先の図で略述されている。
【０１４４】
１．インターセプタ：このメカニズムは、プライマリサーバ内のデータへの変更を認識し、それらをリモートサーバに伝播する。このメカニズムはまた、伝播され戻すリモートサーバ内のデータへの変更を受け取り、それらとプライマリサーバ内のデータとを一致させる。
【０１４５】
２．トランスポート：このメカニズムは、インターセプタとアップデータの間で十分に信頼性のあるリンクを維持するために必要な、十分な待ち時間、帯域幅、セキュリティ、およびその他の要件を提供する、適切なトランスポートおよびプロトコルを利用する、ＬＡＮ、ＭＡＮ、ＷＡＮ、またはその他のネットワークを使用することができる。
【０１４６】
３．アップデータ：このメカニズムは、プライマリサーバに関連するエッジサーバ内のデータへの変更を認識し、これらをプライマリサーバに伝播し戻す。このメカニズムはまた、インターセプタからプライマリサーバ内のデータへの変更を受け取り、これらとエッジサーバ内のデータとを一致させる。
【０１４７】
先の図は、メッセージングサーバ用のデータおよびサービスプロキシについて説明しているが、その他のサーバも、このメカニズムから利益を得ることができる。２つのリモートサーバと１つの集中サーバが示されているが、その他の組み合わせも可能である。ローカルおよびリモートサーバは、アベイラビリティまたはスケーラビリティの理由で、クラスタ化および特別にその他の方法で構成されることができる。接続性は汎用的に示されているが、そのような接続性は、ＭＡＮもしくはＷＡＮ、ＬＡＮベース構成、またはそれらの任意の組み合わせを含むことができる。加えて、その他の方式も可能である。
多次元データ代理
データ代理プラットフォーム：
図１６は、一実施形態によるデータ代理を含む、システム１６００である。複数の代替および／または変形が存在し得る。これらの代替は、等価の機能またはスーパーセットもしくはサブセットを提供することができる。以下の図（図Ｏ）は、４つの企業メッセージングサーバのためのデータ代理を示している。メッセージングサーバの正確な数は、適切な容量計画と、顧客のＲＴＯおよびＲＰＯ目標とに依存する。ストレージエリアネットワークは任意選択である。
【０１４８】
図１７は、一代替実施形態によるデータ代理を含む、システム１７００である。この実施形態は、サーバアベイラビリティ、サーバスケーラビリティ、または両方の目的で、クラスタリングを含む。従来のサーバクラスタリングから専門のアプリケーションアウェアクラスタリングまで、多様なクラスタリング実装が存在する。機能を追加または削除したこの例の変形が可能であり、そのような変形の１つは、ＳＡＮを省略することができる。
【０１４９】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形が可能であることに留意されたい。
【０１５０】
先の例では、データ代理を実施するサーバは、ＳＡＮ対応の単純な双方向アクティブ／パッシブ・クラスタとして示されている。クラスタベース実装のその他の変形も可能である。一般に、データ代理がニアラインサーバを使用して実施される場合、そのニアラインサーバは、必ずしも単一マシンである必要のないことがあり、スケーラビリティおよびフォールトトレランスのために機能専門化および負荷バランシングの様々な組み合わせを提供する複数のマシンを含む分散システムから構成されることができる。さらに、ニアラインシステム用のストレージは、必ずしも単一ストリームシステムである必要のないことがあり、（データ管理、データ分析、ブリック抽出、インデックス付きオブジェクトリポジトリ、全文インデクシング、データマイニングなど）同種および異種機能のための、おそらくはＳＡＮを使用する、ストレージ装置の集まりから構成されることができる。
【０１５１】
クラスタリングに加えて、ニアラインサーバの回復力と、ニアラインサーバがホストするデータのアベイラビリティとを促進するために、ニアラインサーバはローカルで複製されることができる。これは、クラスタリングよりも緩いサーバの結合であり、データ保全のより高い効率性を促進することができる。このローカルレプリケーションも、クラスタリングを用いて組み合わされることができる。例えば、ローカルで複製されたニアラインサーバについて説明する以下の図は、実際には、やはりローカルで複製された２つのクラスタ化ニアラインサーバを表すことができる。このクラスタリングおよびレプリケーションは、当然のこととして、直交（ｏｒｔｈｏｇｏｎａｌ）し、相補的であることができる。
【０１５２】
この図の残りの構成要素は、本明細書において先に説明されている。
【０１５３】
図１８は、一実施形態による、ローカルで複製されたデータ代理を含む、システム１８００である。レプリケーションは、一方向または双方向とすることができる。トランスポートは、従来のＥｔｈｅｒｎｅｔ（登録商標）またはＳＡＮとすることができる。ＳＡＮは、ＦｉｂｒｅＣｈａｎｎｅｌ、ｉＳＣＳＩ、またはその他とすることができる。それは、ＩｎｆｉｎｉｂａｎｄまたはＨｙｐｅｒｔｒａｎｓｐｏｒｔなどの任意の実用的な代替トランスポートとすることもできる。それは、ＶＩおよびＲＤＭＡを含む多様な最適化を使用することもできる。
【０１５４】
先の図では、ニアラインサーバの一方が障害を起こした場合、それをシャドウイングする他方のニアラインサーバが、データ管理アプリケーションによってアクセスされることができる。この例は、単純な１：１レプリケーションについて説明しているが、１つのニアラインサーバがそれ自体を２つ以上のニアラインサーバに複製し、これらのサーバがすべて、何らかの所定のトポロジで組織されることができる、その他の複雑なレプリケーションも可能である。
【０１５５】
データ代理の実施形態を複製する補完的な方法は、レプリケーションのターゲットを、メトロポリタンエリアネットワーク（ＭＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、またはその他のタイプのネットワークを介して接続されるリモートロケーションに配置する。トランスポートは、Ｔ１からＡＴＭまたはＳＯＮＥＴにわたることができる。プロトコルは、ＴＣＰ／ＩＰおよびＦＣＩＰを含むことができる。図１９は、一実施形態による、リモートデータ代理を含む、システム１９００である。
【０１５６】
先の図では、ストレージエリアネットワークは、任意選択であり、メッセージングサーバの正確な数は、顧客の必要性および適切な容量計画に依存する。
【０１５７】
ニアラインサーバの実装のその他の変形も可能である。それらは、実システム、またはＶＭＷａｒｅもしくはＶｉｒｔｕａｌ  Ｓｅｒｖｅｒまたはその他のソフトウェアを使用する仮想システムから構成されることができる。それらは、集中化または分散化されることができる。ニアラインサーバの１つの実装は、Ｇｌｏｂｕｓなどのグリッド技術を利用することができる。
データ代理を生成するためにログシッピングをニアラインサーバと組み合わせる：
先のセクションは、下位にあるプラットフォームと、ニアラインサーバの実装の可能な変形とについて説明した。このセクションは、データ代理を達成するためにプロトコルおよびアルゴリズムの形式で実施される様々な技法に焦点を当てる。本明細書で提供される例示的な説明は、Ｗｉｎｄｏｗｓ（登録商標）サーバソフトウェアおよびＩｎｔｅｌベースのハードウェアプラットフォームを使用し得る従来のコンピューティングシステムに焦点を当てるが、しかし、ハードウェアおよびソフトウェアプラットフォームの代替選択、ならびにファームウェアまたはハードウェアによるプロトコルおよびアルゴリズムのいくつかまたはいずれかの実施を含み得る、その他の変形も可能である。
【０１５８】
ニアラインサーバのログシッピングとの組み合わせが、データ代理を生成する。このデータ代理は、アプリケーション一貫性があり、アプリケーションの元のフォーマットで直接に動作させられ得る。このデータ代理は、この時点では、データ代理のアプリケーション使用を促進する、以下で説明される多次元ビューを追加せずに、元のアプリケーションデータフォーマットをサポートするだけなので、まだ単次元である。データ代理は多様なその他の技法を使用して実施され得るので、ニアラインサーバまたはログシッピングを使用するデータ代理の実施の説明は、単なる一例であることに留意されたい。
【０１５９】
図２０は、一実施形態による、単次元データ代理を含む、システム２０００である。この例は、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅサーバの使用を詳述しているが、使用は、僅かな変更を通して、その他のメッセージングおよびコラボレーションサーバに拡張され得る。それは、構造化、半構造化、または非構造化され得るネイティブフォーマットを有する企業アプリケーションのより大きなクラスにも適用可能である。
【０１６０】
先の図では、何らかのイベントまたは事前定義されたスケジュールに基づいて、最新状態に保たれるシャドウコピーを生成および維持するために、ログシッピングが利用される。従来のログシッピングのいくつかの形態とは異なり、データ管理アプリケーションは、このシャドウコピーを最新状態に保ちながら、その上で同時に動作することができる。図における適切なネットワークトランスポートは、ＬＡＮ、ＳＡＮ、ＭＡＮ、ＷＡＮ、またはその他のトランスポートとすることができる。
【０１６１】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
【０１６２】
図２１は、一実施形態による、ワンパスを介するメッセージングライフサイクル管理を含む、システム２１００である。以下の図は、ニアラインサーバへのログシッピングによるデータ代理の生成に対するさらなる洞察を提供する。左側のサーバは、メッセージングもしくはコラボレーションサーバまたは企業サーバ（例えば、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ  Ｓｅｒｖｅｒ）とすることができる。それは、ライトアヘッドログを生成する。右側のニアラインサーバは、プロダクションメッセージングデータベースのベースラインコピーを獲得する。その後、それは、ログを受け取り、それらをデータベースのコピーに適用する。最新のシャドウデータベースは、データ管理アプリケーションから同時に利用可能である。
【０１６３】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。ただ１つの単純なサーバが示されているが、２つ以上のサーバが存在することも可能であり、その各々は、複数のシステムを含むことができ、複製化、クラスタ化、分散化、仮想化されること、グリッドの部分であること、またはその他の任意の方法で構成されることができる。さらに、任意の数の同種または異種のメッセージングサーバ（またはその他の企業サーバ）が、この方式の１つまたは複数のニアラインサーバによって、この方式で管理され得ることも可能である。
【０１６４】
先の図は以下のフェーズを示している。
【０１６５】
１．データベースおよびログの転送：これは、１組の離散イベントであり、バッチ化されることができ、または連続的とすることができる。連続的である場合、非同期または同期とすることができる。
【０１６６】
２．ログのシャドウデータベースへの適用：この任意選択的な適用は、イーガー（ｅａｇｅｒｌｙ）もしくはレイジー（ｌａｚｉｌｙ）に、または何らかのその他の組み合わせで、発生することができる。
【０１６７】
３．データ管理アプリケーションからのシャドウデータベースの任意選択的な同時利用可能性：この利用可能性は、その上で動作が行われる実際のコピーに対するものとすることができ、またはレプリカに対するものとすることができる。
【０１６８】
この例および実装は、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ  Ｓｅｒｖｅｒを指向したものである。しかし、この概念および実装は、等価の機能を、その他のメッセージングおよびコラボレーションサーバ、および構造化、半構造化、または非構造化データを使用する任意のアプリケーションに提供するために容易に拡張可能である。
【０１６９】
この例では、シッピングされるログは、即座にシャドウデータベースに適用されて、それを最新状態にする。これは、ニアラインウィンドウ、すなわち、メッセージングサーバ上で変更が発生してから、それらがニアラインサーバ上で見えるようになるまでの時間差を短縮する。おそらくはニアラインサーバの性能最適化のため、これらのログを一括化（ｂａｔｃｈｉｎｇ  ｕｐ）することと、バッチングおよびレイジーアプリケーションについて決定を下すこととを含み得る、その他の代替も存在する。ログが適用される前に、関連性に関してフィルタリングをかけ、または望ましくない内容をフィルタで取り除くという方式で、ログを後処理することも可能である。
【０１７０】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
固有のデータベースサポートなしに機能するようにログシッピングを拡張する：
データ代理保守メカニズムは、このログシッピング機能を本来はサポートしないデータベース用のログシッピングを実施する能力によって、さらに増強されることができる。Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ  Ｓｅｒｖｅｒは、この機能をもたないシステムの一例である。Ｅｘｃｈａｎｇｅは、単一適用だけをサポートするＪｅｔ  Ｂｌｕｅデータベース管理システムを利用する。これは、１組のログがターゲットデータベースに一度に適用され得るに過ぎないことを意味する。その単一適用の後、ターゲットデータベースは、新しい状態に返り、さらなるログ適用はどれも受け入れることができない。
【０１７１】
例示的な一実施形態のデータ代理プラットフォームは、ログシッピング機能を、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ  Ｓｅｒｖｅｒの下位にあるデータベース管理システムに組み込むことができる。これは、ログの最初の組が適用された後でさえも、ターゲットデータベースを「オープン」状態に保つことによって、達成されることができる。したがって、ターゲットデータベース管理システムの観点からは、単一の終わりのないログ適用プロセスが進行中の状態で存在する。データ代理はさらに、この連続的なログシッピングプロセスが進行している間、データ管理アプリケーションに同時アクセスを提供することができる。連続的なログ適用プロセスを中断させずに、必要ならば、完全に機能可能なデータベースを「完成」し、Ｅｘｃｈａｎｇｅサーバに返すことも可能である。
【０１７２】
図２２は、一実施形態による、連続的なログ適用プロセスを含む、システム２２００である。その他の技法も可能である。左側は、プロセスの論理ビューである。ログは、リモートのＥｘｃｈａｎｇｅ  Ｓｅｒｖｅｒからニアラインサーバに輸送される。ログシッピングの頻度は、スケジュールによって事前定義される。適用モジュールは、ログを消費し、それらをデータベースに適用して、データベースを最新状態にする。右側は、適用モジュールおよび技法をより詳細に説明している。
【０１７３】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。１つのシステムおよび１つの活動だけが示されている。しかし、実際には、複数の複雑なシステムおよびインスタンスが存在することができ、またはこの活動の変形が発生することができる。
【０１７４】
先の図では、適用プロセスの３つのステージが説明されている。
【０１７５】
１．新しいログセットを導入し、ログ適用を停止（ｓｔａｌｌ）する方式で、最新のログを変更する。ログ適用を停止するための複数の可能なメカニズムが存在し得る。この例は、適用プロセスによって捕らえられ、後処理される、変更ログファイルへのアクセス中に発生する、例外を導入する。
【０１７６】
２．最新のログ適用サイクルからのログの適用を再開するようにＪｅｔ  Ｂｌｕｅ  Ｅｎｇｉｎｅに命令する。Ｊｅｔ  Ｂｌｕｅ  Ｅｎｇｉｎｅは、より大きな集約システムの一部として動作することができ、または単独で動作することができ、またはＪｅｔ  Ｂｌｕｅ  Ｅｎｇｉｎｅのログ適用が達成されるように再構成された必須構成要素だけを有することができる。加えて、適用プロセスを達成するためにＪｅｔ  Ｂｌｕｅ  Ｅｎｇｉｎｅの必要な機能を複製できる置換システムを有することを可能にすることもできる。
【０１７７】
３．Ｊｅｔ  Ｂｌｕｅは、変更ログに達するまで、ログをデータベースに適用し、したがって、Ｊｅｔ  Ｂｌｕｅ  Ｅｎｇｉｎｅを凍結する。この時点で、プロセスは、ログの後続の組および結果のログ適用サイクルの準備を整える。
【０１７８】
上で説明されたプロセスは、ログの新しい組がＥｘｃｈａｎｇｅから受信されるたびに、再開され、再現されることができる。
【０１７９】
この技法は、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅとの関連で説明されている。この技法は、その他のメッセージングおよびコラボレーションサーバにも適用可能とすることができる。この技法はまた、構造化、半構造化、または非構造化データを使用し得る汎用アプリケーションにも拡張可能とすることができる。
【０１８０】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
ログシッピングを動的ログシッピングに拡張する：
動的ログシッピングは、目標復旧ポイント（ＲＰＯ）を改善するために、ログシッピングのさらなる増強を実施する。先の説明では、従来のログシッピングメカニズムが利用されたが、ログシッピングがサポートされない場合のために適切に修正された。しかし、ログシッピングの頻度は、スケジュールによって事前定義されていた。
【０１８１】
一実施形態では、データ代理は、企業のＥｘｃｈａｎｇｅサーバ内で新しいログファイルが満たされると常に、通知を受けることができる。その後、データ代理は、後続のアプリケーションに対して、このファイルのニアラインサーバへの転送を調整する。プロダクションサーバ上のすべてのログが失われる結果をもたらすＥｘｃｈａｎｇｅ上での壊滅的な障害の場合、データ喪失のウィンドウは単一または部分ログファイルの内容によって括られるので、ＲＰＯは最適化される。
【０１８２】
図２３は、一実施形態による、動的ログシッピングを含む、システム２３００である。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０１８３】
１．変更通知：モニタは、変更通知を取得し、次のステップを開始する。これは、ユーザ介入による手動方式で、またはより高い可能性としては自動通知を介して、達成されることができる。この自動通知は、イベントドリブンとすることができ、または何らかの方式でスケジュールおよびバッチ化されることができる。
【０１８４】
２．データベースおよびログの転送：この転送は、データ代理メカニズムがプロダクションサーバ上に共存することができ、したがって、データベースおよびログに直接アクセスし得る状況では、任意選択である。この任意選択的な転送は、ネットワークまたは等価なメカニズムの何らかの形式を介して、発生することができる。
【０１８５】
３．ログのシャドウデータベースへの適用：この任意選択的なプロセスは、レイジーもしくはイーガーに、または何らかのバッチ化された組み合わせで、発生することができる。
【０１８６】
４．データ管理アプリケーションからのシャドウデータベースの同時利用可能性：この利用可能性は、プロセスによって変更される実際のデータに対するものとすることができ、またはそのデータのコピーに対するものとすることができ、またはそれらの何らかの組み合わせとすることができる。これは、ＡＰＩもしくはＷｅｂ  Ｓｅｒｖｉｃｅの形式または等価な形式で利用可能とすることができる。
【０１８７】
この例では、輸送されるログは、即座にシャドウデータベースに適用されて、それを最新状態にする。メッセージングサーバ上で発生した変更がより迅速にニアライン上で見えるようになるので、これはニアラインウィンドウを小さくする。おそらくはニアラインサーバの性能最適化のため、これらのログを一括化することと、バッチングおよびレイジーアプリケーションについて決定を下すこととを含み得る、その他の代替も存在する。ログが適用される前に、関連性に関してフィルタリングをかけ、または望ましくない内容をフィルタで取り除くという方式で、ログを後処理することも可能である。
【０１８８】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
ログシッピングをログトレイリングに拡張する：
動的ログシッピングは、ＲＰＯを単一ログファイルの内容まで、またはそれより小さく引き下げる。ログトレイリングも、ログは企業のメッセージングサーバに書き込まれるときに連続して獲得され、その後、輸送されて、ニアラインサーバ上で適用されるので、ＲＰＯをさらに引き下げるために使用されることができる。図２４は、一実施形態による、ログトレイリングを含む、システム２４００である。現在のトランザクションログに発生する変更は、即座に獲得され、適用のためにニアラインサーバに輸送される。これは、データ代理の維持を準リアルタイムからリアルタイムに改善することができる。この例では、ログは非同期に伝播および適用される。同期適用などのその他の代替も可能である。加えて、変更をニアライン上で即座に適用するのではなく、バッチ化し、レイジーに適用することも可能である。
【０１８９】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０１９０】
１．個々のトランザクションが、左側のプロダクションサーバ内のライトアヘッドログに書き込まれるとき、それらは、捕捉され、右側のニアラインサーバに転送され、任意選択的に再構成されることができる。
【０１９１】
２．適用プロセスは、スケジュールに従って動作することができ、イベントドリブンとすることができ、または連続的に動作することができ、トランザクションまたは再構成ログをシャドウデータベースに任意選択的に適用し、それを最新状態にする。
【０１９２】
３．データ管理アプリケーションは、シャドウデータベースの最近のコピーに同時にアクセスすることができることがある。
【０１９３】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この実施形態は、データ代理の一例として単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
サーバベースエージェントを用いてログ転送を実施する：
ログシッピングと、動的ログシッピングおよびログトレイリングを含む、それのファミリの最適化とは、メッセージングサーバ上にインストールされたエージェントなしに実施されることができる。複数のベンダから出された企業サーバ上の追加ソフトウェアは、性能、機能性、またはアベイラビリティを低下させる傾向を有するので、エンドユーザは、これを非常に好意的に見る。さらに、プロダクションサーバ上へのエージェントのインストールは、プラットフォームの認定および認可、ならびにシステムベンダからのサポート／保証に影響することもでき、追加の認定を必要とすることがある。しかし、ターゲットサーバ上に存在するエージェントの代替は、増強されたプロダクション機能を提供する。これらの増強機能は、（エージェントがローカルであるので）よりプロアクティブな通知と、より良い効率性（エージェントは、発起エンドポイントとしてアクティブに関与できるので、データ管理の観点からのデータの関連性および情報が輸送される最適なタイミングについて知的な決定を下すことができる）とを含む。
多次元代理ビューを生成するために稠密アプリケーションデータをデハイドレート（ｄｅｈｙｄｒａｔｅ）する（データ提示フォーマット次元を拡張する）：
以下の例は、発起アプリケーションの稠密なアプリケーションフォーマットのデータを、データ管理アプリケーションによるデータ管理および消費にとってより扱いやすい代替フォーマットに変換する、抽出メカニズムについて説明している。ただ１つの変換が示されているに過ぎないが、複数のデータ管理アプリケーションの要求を満たすために、任意の数の同時および／または順次変換を有することが可能である。抽出プロセス中、データ管理アプリケーションが抽出ルールを設定することが任意選択的に可能である。任意選択的に、これらのルールは、ルールベース、入力データセット、およびインデックス付きオブジェクトリポジトリ内に存在するデータに基づいて、「自己学習」されることができる。
【０１９４】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０１９５】
先の例は、シャドウリポジトリおよびインデックス付きオブジェクトリポジトリの両方をホストする単一マシンについて説明しているが、その他の構成も可能であることに留意されたい。例えば、２つのリポジトリが統一されているのと同じビューを得るアプリケーションにサービス提供するためのＡＰＩまたはＷｅｂ  Ｓｅｒｖｉｃｅの目的で、これら２つのリポジトリを、別個としながらも、共に連合させて有することが可能である。
【０１９６】
図２５は、一実施形態による、多次元データ提示フォーマットを含む、システム２５００である。同じ目的を達成するためのその他の代替および変形が存在する。
【０１９７】
１．シャドウリポジトリからの抽出モジュール：このモジュールおよび／またはプロセスは、スケジュールドリブン、イベントドリブン、または連続的である。それは、シャドウリポジトリ内のデータの稠密アプリケーションデータフォーマットの知識を有する。それは、シャドウリポジトリからデータのコピーを抽出し、それをインデックス付きオブジェクトリポジトリ内の１つまたは複数の代替フォーマットに変換する。抽出中、このプロセスは、インデックス付きオブジェクトリポジトリ内の既存データについての知識を有し、重複排除、効率的配置、および高速抽出を含む、多数の最適化を行うことができる。これらは、後で本明細書において「シングルインスタンス最適化」および「デルタ変更検出最適化」として説明される。抽出モジュール用のその他の多様な最適化も可能である。
【０１９８】
２．任意選択フィルタリング：これは、ベンダによって実施されるルールベースエンジンと等価とすることができ、ＡＰＩまたはＷｅｂ  Ｓｅｒｖｉｃｅを介してデータ管理アプリケーションによって任意選択的にプログラムが可能である。加えて、それは、動作中に学習し、最適化することができる。これは、抽出プロセスが、さらにその動作を最適化し、またはニアラインサーバの効率を高め、もしくは関連性およびデータ管理アプリケーションによるデータへのアクセスのスピードを改善するような方式で、結果を選択的にフィルタリングすることができるように、ルール、ガイダンス、またはヒントを抽出プロセスに提供する。この構成要素は任意選択であり、ニアラインに局所化された、またはリモートの、または分散化されたその他の実装も可能である。複数のそのような最適化メカニズムが、順次的または同時的に存在することができる。この任意選択メカニズムは、抽出中に「インバンド（ｉｎ  ｂａｎｄ）」で発生することができ、または抽出がデータを配置した後、バッチモードで発生することができる。
【０１９９】
３．インデックス付きオブジェクトリポジトリの更新：抽出プロセスは、関連性のあるデータをインデックス付きオブジェクトリポジトリ内に配置する。これは、後続のデータ管理に適用可能な１つまたは複数のフォーマットをとる。この例では、リポジトリは、データとメタデータに分離されるが、両方を組み合わせることも可能である。データは、ファイルシステム内に存在し、メタデータは、関係データベース内に存在する。しかし、ファイルシステムまたは関係データベースのどちらかに共存することも可能である。データはニアライン上でホストされるとして論理的に説明されたが、データは、おそらくはＳＡＮまたはその他のタイプのネットワークを介して、その他のサーバからアクセス可能とすることができ、または複数のニアラインサーバにわたって分散されることもできる。
【０２００】
４．フレキシブルなデータ管理アプリケーションアクセス：これらは、シャドウリポジトリ内もしくはインデックス付きオブジェクトリポジトリ内または両方のデータ上で同時に動作するために、ＡＰＩまたはＷｅｂ  Ｓｅｒｖｉｃｅを使用する、１つまたは複数のデータ管理アプリケーションである。任意選択的に、それらは、変換、フォーマット、配置、または後処理についての何らかの選択を行うために、ＡＰＩまたはＷｅｂ  Ｓｅｒｖｉｃｅを使用することができることがある。
【０２０１】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
サーバ横断的なビューを生成するために多次元代理を利用する：
プロダクションサーバは独自のプロダクションデータを保存する。企業は、複数のプロダクションサーバを配備することができる。これらのサーバは、同じデータセンタ内にローカルに、または複数の異なるデータセンタ内に存在することができる。データ管理アプリケーションが、一群のプロダクションサーバに対して横断的な、このデータすべての集約ビューを獲得することは、通常は有利である。以下の図は、データ代理メカニズムが、どのように複数のサーバ「次元」にわたって拡張されて、この次元を横断するシームレスなアクセスを有するためのデータ管理アプリケーションの必要を軽減するか（また新しいデータ管理アプリケーションを促進するか）を示している。
【０２０２】
図２６は、一実施形態による、多次元サーバ集約を含む、システム２６００である。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０２０３】
上記の実施形態は、３つのメッセージングサーバを含むが、代替実施形態は、適切な容量計画に従って、任意の数のこれらのサーバを含むことができる。これらは、構造化、半構造化、または非構造化データ上で動作する、その他のタイプのサーバとすることができる。さらに、これらのサーバは、複数の異なるタイプとすることもできる（その場合、サーバの各カテゴリは、独自のシャドウリポジトリに供給し、複数の抽出プロセスは、このデータすべてを、おそらくはマルチフォーマットのインデックス付きオブジェクトリポジトリに集約し、それによって、「複数のサーバ」と「複数のアクセスフォーマット」の２つの次元を任意選択的に連結する）。
【０２０４】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
【０２０５】
図２７は、一実施形態による、２つのタイプのプロダクションサーバ（例えば、ｅメールおよびＣＲＭ）を統合する、システム２７００である。提示次元は、インデックス付きオブジェクトリポジトリ内に、マイニング、ＯＬＡＰ、およびコンプライアンスアプリケーションを同時に促進することができる３つのフォーマットを有する。
【０２０６】
先の例では、マイニングアプリケーションは、おそらくセキュリティまたはサービス品質評価目的で、顧客、従業員、およびそれらの相互関係の間にパターンを探す。ＯＬＡＰアプリケーションは、アカウンティングを取り扱う。コンプライアンスアプリケーションは、顧客およびメッセージングデータが指定された方式で保持および配置されているかを確認する。これらのアプリケーションはすべて、インデックス付きオブジェクトリポジトリ内の同じデータおよびメタデータにアクセスすることができる。または、これらのアプリケーションは、それらから利用可能な独自のアプリケーション関連データおよび／またはメタデータを有することができる。
【０２０７】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
時間横断的なビューを生成するために多次元変換を利用する：
プロダクションサーバは、プロダクションデータの最新のコピーをオンラインストレージに保持する。いくつかのケースでは、プロダクションサーバは、おそらくコピーオンライト（ｃｏｐｙ−ｏｎ−ｗｒｉｔｅ）メカニズムを使用して、このデータの少数の追加コピーを維持することを可能にすることができる。いくつかのＭｉｃｒｏｓｏｆｔ  Ｓｅｒｖｅｒ上で利用可能なＶｏｌｕｍｅ  Ｓｈａｄｏｗ  Ｃｏｐｙ  Ｓｅｒｖｉｃｅは、サーバが複数の履歴コピーを維持することを容易にするそのような機能の一例である。そのようなコピーの数は制限される。オンラインストレージの量も、古いコピーをおそらく廃棄しなければならなくなる前に取ることができる「コピーオンライトストレス（ｃｏｐｙ−ｏｎ−ｗｒｉｔｅ  ｓｔｒｅｓｓ）」の量を制限する。図２８は、一実施形態による、時間、サーバ、および提示次元を統合する、システム２８００である。システム２８００は、プロダクションデータの複数の履歴スナップショットを獲得し、その後、それらを効率的な方式で保存するために、適用および抽出メカニズムを使用する、ニアラインサーバを含む。データ管理アプリケーションによるリポジトリのその後のアクセスは、時間横断的なビューを促進する。この「時間次元」は、所定の数のプロダクションサーバからの時点の所定の組が、所定の数のフォーマットで、１つまたは複数のおそらくは同時に動作可能なデータ管理アプリケーションに提示され得るように、先に説明された「サーバ次元」および「提示次元」と所定の組み合わせとすることができる。
【０２０８】
これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。この例は少数のサーバを示しているが、等価なサービスを複数の異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
【０２０９】
先の実施形態では、抽出プロセスに関連付けられ得るトリガが存在し、トリガは、抽出プロセスに、シャドウリポジトリからデータを抽出させ、それをインデックス付きオブジェクトリポジトリ内で効率的にオーバーレイさせる。これらのトリガは、互いに独立とすることができ、または互いに協力して働くことができる。これらのトリガは、時間ドリブンとすることができ、またはイベントドリブンとすることができる。それらがイベントドリブンである場合、それらは任意選択的に、シャドウリポジトリの内容、適用プロセスによって、またはプロダクションサーバのリモート内容もしくは健全性によってすら、伝達されることができる。この最後の情報は、図示されていないエージェントベースまたはエージェントなしのメカニズムによって取得されることができる。その他の実装、最適化、代替、または縮小も可能である。この例は、少数のｅメールおよびＣＲＭサーバを示しているが、任意の数の任意のタイプのサーバが可能である。同様に、データ管理アプリケーションの３つのカテゴリが説明されているが、任意の組み合わせが可能である。ニアラインサーバは、単一かつ集中化されて示されている。しかし、クラスタ化、分散化、グリッド、またはニアラインサーバのその他の組み合わせの複数の実装が可能である。
シングルインスタンス化およびバージョニングにより多次元ビューの保存を最適化する：
ニアラインサーバは、シリアルＡＴＡまたはＩＤＥドライブなどの低コスト媒体を使用することができる。しかし、サーバ、時間、提示の複数の次元をインデックス付きオブジェクトリポジトリに統合する場合、保存要件が、問題のあるサイズになることがある。データ代理の例は、ニアラインサーバ上での重複および過剰保存を制限するために、企業データにおけるある傾向を利用する、シングルインスタンス化およびバージョニングを利用するストレージ最適化を実施することができる。利用される様々な傾向は、（ａ）データの同一コピーが、サーバの複数のロケーションまたは複数のサーバに同時に存在し得ること、および（ｂ）アイテムが、同じまたは異なるサーバ上の別のアイテムの変形であり得ることである。図２９は、一実施形態による、ストレージ最適化を使用して、時間、サーバ、提示次元を統合する、システム２９００である。その他の最適化も可能であり、そのいくつかは、企業のプロダクションサーバのクラスに固有とすることができる。
【０２１０】
先の図は、シングルインスタンス化およびバージョニングによるニアラインサーバ上でのストレージ最適化の１つの方法の一例である。これを達成するため、抽出されるアイテムの適切に一意のフィンガープリントを生成するメカニズムを用いて、抽出が拡張される。その後、このアイテムが既存アイテムと同じフィンガープリントを有するかどうか、またはインデックス付きオブジェクトリポジトリ内の既存アイテムの変形であるかどうかを決定する別のメカニズムを、抽出は利用することができる。ヒットがあった場合、配置メカニズムは、正確な一致があったならば参照カウントをインクリメントすることができ、またはインデックス付きオブジェクトリポジトリ内の既存アイテムに対する新しいアイテムのデルタだけを計算し、保存することができ、または何らかの組み合わせもしくは代替を実行することができる。新しいアイテムは、エンドユーザがそれを望むならば、全体として別個に保存されることができる。複数の代替実施が可能である。例えば、この図は、抽出モジュールの動作中に「インバンド」で発生するこの最適化を示しているが、この機能を「アウトオブバンド（ｏｕｔ  ｏｆ  ｂａｎｄ）」で実施するオフラインバッチプロセスを有することも可能である。その他の増強、代替、または縮小も可能である。この図は単一のメッセージングサーバについて説明しているが、任意の数の同種および異種の企業サーバが、抽出中にそれらに適用されるこの最適化を有することもできる。このストレージ最適化は、本明細書で説明されるデータ代理の先の次元のすべてと統合されることができる。ニアラインサーバ自体は、単独とすること、クラスタ化されること、分散化されること、またはグリッドの部分とすることができる。
【０２１１】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
インデックス付けによって多次元ビューを動的に拡張する：
データ代理は、時間および空間（複数のサーバの複数の時点）を含み得る複数の次元でデータを獲得する場合、このデータ上で、相関、分類、全文インデックス付け、デジタル署名追加、およびその他の動作を含み得る動作を実行する能力を有することができる。これは、データ代理の部分として保存され、最終的な消費者から任意選択的に利用可能にされ得るメタデータをもたらす。加えて、このメタデータは、配置および重複排除についての決定、何を保存し、何を廃棄するかについての決定、到来データの抽出および処理の頻度についての決定、検索、データ改ざんの検出、およびその他の最適化についての観察されるデータ生成パターンに基づいて、これらの動作を企業サーバ用にどのように構成するかの決定を含み得る、動作および保存における効率性を達成するために、任意選択的に利用されることができる。これは、システムによって任意選択的に使用され、消費者から任意選択的に利用可能にされる、新しいデータ次元をもたらすことができる。
【０２１２】
図３０は、一実施形態による、多次元サーバ集約を含む、システム３０００である。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。先の例示的な図では、以下の３つの構成要素が説明されている。
【０２１３】
１．任意選択的なフィルタ：これは、データ管理アプリケーションに、抽出プロセスを調整およびパラメータ化するためのＡＰＩ（またはＷｅｂ  Ｓｅｒｖｉｃｅ）機能を提供する、任意選択的なメカニズムである。
【０２１４】
２．任意選択的なインデックス付け：これは、パターンおよび関係を探して、インデックス付きオブジェクトリポジトリ内のデータおよびメタデータ上で動作する、任意選択的なメカニズムである。関連する情報を見つけた場合、それは、この新しい情報を用いてメタデータを増強する。任意選択的に、それは、フィルタを介してデータ管理アプリケーションによってガイドされることができる。
【０２１５】
３．任意選択的なデータ管理アクセス：これは、集約データが意味的にインデックス付けされている場合に、データ管理アプリケーションが集約データにＡＰＩ（またはＷｅｂ  Ｓｅｒｖｉｃｅ）アクセスするための、任意選択的な手段である。任意選択的に、データ管理アプリケーションは、関連する追加データまたはメタデータがインデックス付きオブジェクトリポジトリに追加された場合、プロアクティブな通知およびコールバックを得ることができる。任意選択的に、データ代理は、プロダクションサーバの機能に影響し、ガイドし、関与し、または拡張することにプロアクティブに携わることができる。これらのアプリケーションは、正または負のフィードバックループを通るプロダクションサーバワークフローに対する、および既存の問題点の解決または価値付加による生産性の向上のためのプロダクションサーバ機能の増強に対する、アクティブまたはパッシブな関与者となることができる。
【０２１６】
この例は、３つのメッセージングサーバと１つのニアラインサーバを有する単純な構成について説明している。可変の数の同種または異種のプロダクションサーバ、クラスタ化されること、分散化されること、グリッドの部分であること、または仮想化されることができる複雑なニアラインサーバを含む、その他の配備変形も可能である。
【０２１７】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の任意の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
エンドユーザのデータ代理へのシームレスなアクセスを促進するために標準的な企業の認証、権限付与、およびアクセス制御と統合する：
データ代理メカニズムは、元のアクセス制御情報が獲得され、データと共存させるような方式で、動作することができる。加えて、ＡＰＩまたはＷｅｂ  Ｓｅｒｖｉｃｅによって提供されるアクセスレイヤは、企業のデータセンタと統合される認証および権限付与チェックを実施することができる。一例としてＷｉｎｄｏｗｓ（登録商標）環境の場合、認証および権限付与は、Ｗｉｎｄｏｗｓ（登録商標）  Ｄｏｍａｉｎ認証および権限付与との統合を含むことができる。一例としてＭｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ  Ｓｅｒｖｅｒの場合、Ｅｘｃｈａｎｇｅ  Ｄａｔａｂａｓｅ内またはＡｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙ内に保存されるアクセス制御情報は、獲得され、データと共存させることができる。
【０２１８】
図３１は、一実施形態による、認証、権限付与、および監査を統合する、システム３１００である。システム３１００は、企業の認証および権限付与との、ならびにアプリケーションアクセス制御とのこの統合の一例である。この図では、アクセス制御情報は、抽出を越えて保存され、インデックス付きオブジェクトリポジトリに投入される。ＡＰＩまたはＷｅｂ  Ｓｅｒｖｉｃｅアクセスレイヤは、Ｗｉｎｄｏｗｓ（登録商標）認証および権限付与と統合される。稠密アプリケーションデータへのアクセスは一般に、アクセスユーザまたはアプリケーションの信用証明が管理者の信用証明と等価であることのチェックを含む。一例としてＭｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅの場合、信用証明は、アクセスされるＥＤＢの管理グループ内のＥｘｃｈａｎｇｅ管理者の信用証明と一致しなければならない。
【０２１９】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０２２０】
１．ニアラインは、最新のセキュリティ情報を獲得し、おそらくはキャッシュするために、企業のセキュリティサブシステムと任意選択的に通信する。
【０２２１】
２．抽出中、関連するアクセス制御情報が、任意選択的に抽出され、インデックス付きオブジェクトリポジトリの関連データと共存させられる。
【０２２２】
３．アクセス中、任意選択フィルタが、リクエストされたデータをデータ管理アプリケーションから利用可能にする前に、セキュリティ信用証明および認証をチェックする。
【０２２３】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
【０２２４】
先の図には、増強された認証、権限付与、アクセス制御、および否認防止が、企業との基本統合の上に、どのようにレイヤ化され得るかの一例が存在している。これは、データ管理アプリケーションとインデックス付きオブジェクトリポジトリの間のアクセスパス内で、任意選択フィルタをレイヤ化することを含む。このレイヤは、より高いレベルのロール、認証、アクセス制御、およびアクセスロギングを課すことができる。アクセスロギングは、侵入監視および検出システムとなるように拡張されることすらできる。これは一例に過ぎず、その他の変形、増強、縮小、および代替が可能である。
【０２２５】
履歴データおよび企業に統合されるアクセス制御および認証は、データが生成されるときに実施されるアクセス方針を実施するように構成されることができ、またはデータがアクセスされるときに実施される方針を実施するように構成されることができる。
その他の変形、増強、および縮小が可能である。
プログラム可能な階層的方針管理を提供する：
データ代理は、そのプラットフォーム上でＷｉｎｄｏｗｓ（登録商標）  ＷＭＩを利用する、ＣＩＭベース（または等価）の階層的方針管理メカニズムを実施することができる。データ代理は、データ代理ホスト・オブジェクト・マネージャ内で、階層的な資産および主体、ならびに関連する属性を反映することができる。これは、企業方針を捕捉し、管理するための自然な方法とすることができる。この管理可能性階層は、顧客の必要に固有の、または連合施行組織のルールおよびガイドラインに最適化された方針の特化を実施する、アフター・マーケット・プログラム可能レイヤ（ａｆｔｅｒ  ｍａｒｋｅｔ  ｐｒｏｇｒａｍｍａｂｌｅ  ｌａｙｅｒ）を促進するために、ＡＰＩまたはＷｅｂ  Ｓｅｒｖｉｃｅを介して提示されることもできる。このようにして、データ代理は、ニアラインシステムが配備された後、特化またはプログラムされることができるので、不完全または曖昧な方針ガイドラインに対処することができる。
【０２２６】
図３２は、一実施形態による、プログラム可能な階層的方針管理を含む、システム３２００である。この図では、抽出プロセスは、ＣＩＭ−ＯＭ内に保存された階層的方針によって駆動される。抽出中、抽出プロセスは、グローバルフォルダ除外方針を実施することができる。抽出プロセスは、特定ユーザメールボックスまたはフォルダ除外方針を実施することもできる。このタイプの方針ベースのアクションはデータ代理の動作の全体にわたって発生するので、これは一例に過ぎない。
【０２２７】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０２２８】
１．方針は、何が獲得されるかを決定する：この方針は、階層的であり、（一例としてＥｘｃｈａｎｇｅを使用する、組織、管理グループ、Ｅｘｃｈａｎｇｅ  Ｓｅｒｖｅｒ、ストレージグループ、メールボックスストア、メールボックス、フォルダ、およびアイテムなど）複数の粒度で資産に、または（企業、サイト、部門、および個人など）複数の粒度で主体に適用されることができる。
【０２２９】
２．方針は、データ管理アプリケーションに見えるものをフィルタで除外することができる。
【０２３０】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
【０２３１】
先の図では、単一のメッセージングサーバおよび単一のニアラインサーバが示されている。これは、複数の同種または異種のプロダクションサーバに拡張されることができ、ニアラインサーバは任意に、複合とすること、クラスタ化されること、分散化されること、グリッドの部分であること、または仮想化されることができる。加えて、ニアラインサーバは、増強、代替、または縮小を有することができる。
保証された保存および処分方針の施行を促進する：
データ代理の統合化およびワンパスという特質のせいで、複雑な保存および処分方針を実施し、その後、施行し、施行を監視することは、相対的に容易である。これは、データ用に１つの入口と、１つの保存場所と、１つの出口があるに過ぎないためである。これは、保存および処分方針における変更のロギングを促進する、別の場所で説明される、管理否認防止と結合される。これはまた、方針を逃れるデータの無権限の保存および処分に対する付加的な保護を導入する、別の場所で説明される、改ざん検出および耐改ざん性とも結合される。図３３は、一実施形態による、保証された保存および処分方針施行を含む、システム３３００である。システム３３００は、周期的または連続的に動作し、シャドウリポジトリまたはインデックス付きオブジェクトリポジトリ内のデータが処分候補になったときにそれを獲得し続けるサービスを含む。加えて、出されるデータが期限切れでないことの任意選択的チェックを実施する任意選択フィルタにおいて２次的なチェックが存在する。
【０２３２】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０２３３】
１．任意選択の処分サービスは、ニアラインサーバ上のすべてのリポジトリ内でデータを探して、保存期間を超えたデータを見出し、処分するために、スケジュールに従って機能し、またはイベントドリブンであり、または連続的に機能する。
【０２３４】
２．任意選択のフィルタメカニズムは、データ管理アプリケーションからアクセス可能とされているデータが指定された保存期間を超えていないことを確認する補助、または安全策、または代替である。
【０２３５】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
固有ＲＡＩＤサーバＩＬＭ技法と統合する：
オンライン・ストレージ・システムは、データ代理によって達成される機能と部分的にオーバーラップする機能を含むことができる。この場合、これらの機能と統合し、それらを利用し、拡張することができる。そのような場合、ハイエンドＲＡＩＤサーバを含み得るオンライン・ストレージ・システムは、ヒントおよび合図、ならびにデータへのアクセスを提供することができる。代替として、データ代理は、これらのヒントおよび合図を推測し、自主的にそのデータへのアクセスを獲得することができる。統合のこのクラスは、データ移動および保存の態様を含み得るデータ代理の構成要素のいくつかを簡素化することができる。動作の効率性および使用の簡易性を提供する方式で、オンラインストレージをニアラインストレージと、またおそらくはオフラインストレージと、シームレスに統合することが可能なことがある。
連想記憶ストレージ（ＣＡＳ）を実施する、またはＣＡＳと統合する：
データ代理は本質的に、オブジェクトを挿入し、その後、ディスクリプタによって連想的にそれにアクセスする能力を促進する、ＣＡＳメカニズムを含むことができる。この基本ＣＡＳメカニズムはさらに、シングルインスタンス化またはデルタバージョニングなどのストレージ最適化、ならびに認証、権限付与、アクセス制御、プライバシ、および否認防止などのセキュリティ増強によって、増強されることができる。この固有機能の組み込みの代替として、データ代理が統合を通して外部ＣＡＳ機能を利用することも可能なことがある。
データセンタ内のニアライン回復力のために「アプリケーションクラスタリング」を実施する：
クラスタリングを使用することによってデータ代理の部分を実施することが可能なことがある。１次的目的が代理である状況では、より低コストおよび低オーバーヘッドであり得るアプリケーションクラスタリング機能を達成するために、より効率的なメカニズムが利用可能であり得ることが可能である。アプリケーションクラスタリングのこの形態は、従来のサーバクラスタリングにとっての必要を不要にし得ることが可能である。しかし、その場合は依然として、（どのような多次元増強もなく）データは元のフォーマットでのみ利用可能である。さらに、１次コピー上でのデータ破壊は、２次コピーに伝播され得る。
「ローカルまたはリモートサービス保全」を実施する：
データ代理の一実施形態は、最新のアプリケーション一貫性のあるデータコピーを有することができ、したがって、壊滅的なサーバまたはサイト障害が起きたときに、サービスを復旧することができる。サーバ障害が起きた場合、データ代理をホストするそれらは、置換サーバへのデータアクセスを直接提供することができる。または、それは、フェールオーバクライアントアプリケーションにサービスを直接提供することによって、置換サーバになりすますことができる。壊滅的なサイト障害が起きた場合、クライアントアプリケーションは、リモートの災害回復サイトに配置された置換サーバ（またはデータ代理に直接）フェイルオーバされることができる。
【０２３６】
図３４は、一実施形態による、ローカルまたはリモートサービス保全を含む、システム３４００である。以下の図では、これらのフェイルオーバ／データ復旧／サービス復旧／フェイルバック機能の一例として、メッセージングサーバが使用されている。等価の機能をその他のタイプの企業サーバに提供することも可能である。この図では、データ代理は、生産障害が起こったことを検出する（または通知される）。データ代理は、そのような障害をプロアクティブに計画することさえできる。障害時、データ代理は、最新かつ利用可能なアプリケーションデータのコピーを有形化（ｍａｔｅｒｉａｌｉｚｅ）することができる。これは、その後、クライアントアプリケーションがフェイルオーバされ得るホットスタンバイサーバにコピーされることができる。任意選択的に、ＮＡＳまたはＳＡＮデータサービスプロトコルを使用して、スタンバイサーバにデータを直接提供することも可能である。ニアラインも、ＭＡＰＩ、ＩＭＡＰ４、もしくはＰＯＰ３、またはその他を含み得るアプリケーションプロトコルを直接提供することによって、スタンバイサーバになりすますことができる。
【０２３７】
障害中、データ代理は、任意選択のリハイドレータ（ｒｅ−ｈｙｄｒａｔｏｒ）モジュールによって、データの履歴スナップショットを有形化することも可能である。これは、最新のデータコピーがＳＰＡＭまたはウイルスに侵されることがある場合、または何らかの理由で信用できない場合に、必要なことがある。監査目的で、ニアラインは、監査アプリケーションが、複数の時点における複数のプロダクションサーバの状態の時間的および空間的ビューを獲得できるように、時間的に複数のスナップショットを監査アプリケーションに同時に提供することが可能である。時間的なスナップショットは、データおよびメタデータで構成される特定のパターンに合致するデータの細かさで、提供されることができる。手の込んだ基準を使用して、データの部分に対して選択的なロールバックおよび／またはロールフォワードを提供することを可能にすることができる。
【０２３８】
以下の例示的な図では、クライアントおよびその他の企業構成要素は、１次サーバおよびデータ代理の存在を、別個の実体として、直接認識することができる。クライアントおよび／またはその他の関連する企業構成要素の間に、それらがリソースまたはサービスの単一のシステムビューをもち続けるように、プロキシエンティティの介在を含み得る、その他の変形も可能である。このプロキシは、１つまたは複数のサーバおよび１つまたは複数のフェイルオーバエンティティを集約する。障害が起こった場合、プロキシは、クライアントおよび／または企業からのリクエストを代替リソースにフェイルオーバすることができる。１次リソースが復旧された場合、プロキシは、リクエストを１次リソースにフェイルバックすることができる。プロキシ自体（ならびに企業サーバおよびデータ代理）は、クラスタ化、複製化、仮想化、もしくは分散化されることができ、またはグリッドの部分とすることができる。プロキシの部分は、クライアント、企業サーバ、データ代理、その他の企業コンポーネント、または何らかの変形もしくは組み合わせにまたがることが可能である。
データ代理およびデータセンタ回復力のためにアプリケーションジオクラスタリングを実施する：
サーバクラスタリングの場合と同様に、データ代理を必要とする状況の場合、先のセクションで説明されたデータ移動メカニズムの利用を通してより効率的になり得るジオクラスタリングの変形を実施することが可能なことがある。効果は、おそらく何らかの状況で従来のジオクラスタリングを実施する必要を不要にして、ストレージおよび転送帯域幅の使用を極度に倹約し得る、分散データ代理を生成することである。
否認防止を実施する：
否認防止は、企業において、「送信否認防止」、「管理否認防止」、「変更否認防止」、および「アクセス否認防止」を含む、複数の態様を有する。これらは、以下では、ニアラインサーバ上でデータ代理が行われるメッセージングサーバの文脈で説明される。しかし、その他のタイプのサーバについても同等物が存在する。
【０２３９】
・送信否認防止：何らかの主体がアイテムの発信者であることを証明する能力。
【０２４０】
・管理否認防止：管理者がニアラインサーバ上で何らかのシステムまたは方針またはその他のコンフィグレーション変更を行ったことを証明する能力。
【０２４１】
・変更否認防止：ニアラインサーバ上に保存されたアイテムがそれ以降変更されていないことを証明する能力。
【０２４２】
・アクセス否認防止：ある主体がセルフサービスを介してニアラインサーバからのアイテムにアクセスし、それを見たことを証明する能力。
【０２４３】
図３５は、一実施形態による、ニアラインサーバ上での否認防止を含む、システム３５００である。この例は、強力な暗号技法に依存する。その他の暗号および非暗号技法も可能である。
【０２４４】
この例では、データがインデックス付きオブジェクトリポジトリに挿入されるときにデジタル署名およびデジタルタイムスタンプを生成またはチェックするための、先に説明されたフィンガープリントメカニズムを増強することによって、否認防止が導入される。これらの署名およびタイムスタンプは、インデックス付きオブジェクトリポジトリ内のメタデータに追加される。データがアクセスまたは変更される場合、これらのアイテムが、受信されて以降、改ざんされていないことを確認するため、また送信否認防止を促進し、変更否認防止を実施するため、インデックス付きオブジェクトリポジトリ内に存在するデジタル署名およびタイムスタンプがデータとクロスチェックされる。
【０２４５】
アクセス主体またはアプリケーションの信用証明も、権限付与チェックし、このアクセスをロギングするため、インデックス付きオブジェクトリポジトリのメタデータにおいてチェックされ、おそらくは確認されることができる。同様に、ニアラインサーバ上で開始された管理変更が存在する場合、管理否認防止を実施するために、管理者のデジタル信用証明が、チェックされ、おそらく変更の記録と共にロギングされる。強力な暗号方式は、信用できるタイムサーバおよびＰＫＩなどのその他のセキュリティメカニズムの存在に依存することができる。等価の機能を実施するために、様々な暗号および非暗号メカニズムも可能である。
改ざん検出および耐改ざん性：
ニアラインサーバの改ざん検出および耐改ざん性は、管理者がこれらのサーバに対する完全な管理を有し、管理者自身が防がれる必要のある不慮または悪意ある行為の犯人になり得るという事実によって困難に見舞われる。図３６は、一実施形態による、否認防止を含む、システム３６００である。このシステム３６００は、少なくとも１つがローカル、１つがリモートの、複数のニアラインサーバが、管理上の改ざんを防ぐ方式で、どのように協力して機能し得るかの一例である。ローカル管理者の管理領域の外にリモートサーバが存在することが仮定されている。
【０２４６】
このメカニズムは、すべての標準的なサーバ強化耐改ざん性および改ざんロギングメカニズムが、ニアラインサーバ上で実施された後、導入される。先の例では、インデックス付きオブジェクトリポジトリ内のデータがロギングされ、リモート・ニアライン・サーバに複製される前に、そのデータをアクセスメカニズムが確認するように、アクセスメカニズムが増強される。ローカルおよびリモート・ニアライン・サーバは、互いの間に信用を築き、通信媒体の信用およびプライバシを増強するために、標準的な暗号技法を使用することができる。１対のローカルおよびリモート・ニアライン・サーバが示されているだけだが、任意のトポロジに接続され、様々なトランスポートおよびプロトコルを利用する、任意の数のローカルおよびリモート・ニアライン・サーバが可能である。
多次元ワンパス代理の生成：
データ代理メカニズムは、企業メッセージングサーバデータのコピーを、任意選択的にシングルパスで効率的に獲得し、シャドウイングすることができ、その後、それがデータ管理から利用可能になるようにそれを処理するメカニズムを利用することができる。図３７は、一実施形態による、多次元ワンパス代理を含む、システム３７００である。
【０２４７】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０２４８】
先の図は、ワンパスデータ代理の構成要素を示している。
【０２４９】
１．シャドウイング：これは、ワンパス保護の基盤であり、アプリケーション一貫性のある方式で、企業アプリケーションデータのレプリカを生成し、維持することを含む。これは、従来のレプリケーションより優れており、はるかに効率的である。これはまた、ＭＡＰＩまたはＳＭＴＰなどのメカニズムを使用する従来の獲得よりもはるかに効率的である。シャドウイングされるアプリケーションデータは、元のアプリケーションのフォーマットでニアラインサーバ上に保存され、データ破壊または回復不能な媒体障害が起こったときに、即座にまたは準リアルタイムで、企業サーバ（または置換サーバ）から利用可能である。
【０２５０】
２．変換：このプロセスは、アプリケーションの稠密アプリケーションフォーマットから、データ管理または分析サーバによる処理においてより使用しやすい、よりフレキシブルな粒度の細かいフォーマットへのデータ変換を含む。この変換は、アーカイバルウィンドウに起因するスピード欠如の関連する制限、および企業サーバ上で生成される過剰な負荷の制限なしに、従来のアーカイビングのすべての機能を提供する。新しいデータフォーマットは、データおよびメタデータからなる。メタデータは、データをカテゴライズおよび分類し、内部関係を生成し、その後のアクセスおよび分析をより容易にするために使用される。
【０２５１】
３．インデックス付け：このプロセスは、変換されたデータを分析し、付加的な処理およびより手の込んだアルゴリズムを利用する付加的なメタデータを生成することを含む。これらのアルゴリズムは、（限定することなく）マイニングおよび意味インデックス付けを含む。それらは、時間、空間、主体、および個人の階層などの追加を含むことができる。変換されたデータは、連続的にインデックス付けされ、新しいデータがニアラインサーバに到着した場合、それと相関させられ、またはレイジープロセスとして、インデックス付けされ、相関させられることができる。目標は、その後の検索および分析をより効率的または機能豊富（ｆｅａｔｕｒｅ−ｆｕｌｌ）にする試みを含むことができる。
【０２５２】
４．ストレージ最適化：これは、フットプリント（すなわち、セーブ空間）を削減する一方でアクセス待ち時間を最適化する方式で、ニアラインサーバ上にデータを組織し、保存するために、アプリケーションおよびメタデータの知識を利用することを含む。
【０２５３】
アプリケーションデータを抽出し、変換し、インデックス付けし、保存するメカニズムは、多くの中でもとりわけ、後のセクションで説明されるアプリケーションなど、多様なデータ管理アプリケーションを今では促進することができる。
複数のデータ管理アプリケーションの使用可能性：
増強データ代理は、多様なデータ管理アプリケーションを可能にする、より高いレベルのフレームワークを実施することができる。
【０２５４】
これらのデータ管理アプリケーションは、プロダクションサーバシステムの機能（例えば、監視、監督、プロアクティブなデータマイニングおよびパターンマッチング、ならびに統合ワークフローおよび拡張コラボレーション）を補足および／または増強する、複雑かつ価値付加的な相互関係およびフィードバックループを有することができる。
【０２５５】
図３８は、一実施形態による、複数のデータ管理アプリケーションを含む、システム３８００である。このシステム３８００は、多様なアプリケーションを実施するために、安全かつスケーラブルな方式での、メーカまたはサードパーティアプリケーションによるデータへのアクセスを容易にする、（Ｗｅｂ  Ｓｅｒｖｉｃｅによって代用可能でもある）ＡＰＩを含む。
【０２５６】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０２５７】
１．おそらく複数の同種または異種のサーバからの関連する企業データニアラインに導入され、最新状態に保たれる。
【０２５８】
２．ニアラインにホストされるデータのビューへのアクセスを得るために、モジュール化アプリケーションが、このニアライン上に直接存在するか、またはネットワークを介してそれにアクセスできるように、ＡＰＩもしくはＷｅｂ  Ｓｅｒｖｉｃｅまたは同等物が提供される。
【０２５９】
３．これらのデータ管理アプリケーションは、プロダクションサーバに直接アクセスしているように振舞うが、実際には同じＡＰＩおよびプロトコルを介してニアラインにアクセスしている、既存アプリケーションとすることができる。代替として、それらは、実装提供（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ−ｐｒｏｖｉｄｅｄ）のＡＰＩまたはＷｅｂ  Ｓｅｒｖｉｃｅを使用するように設計および実装された、新しいアプリケーションとすることもできる。
【０２６０】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
配備構成
図３９は、一実施形態による、企業環境（ｅｎｔｅｒｐｒｉｓｅ  ｓｅｔｔｉｎｇ）における増強データ代理の例示的な配備を含む、システム３９００である。それは、ニアラインサーバが、企業サーバ、データ管理アプリケーション、およびクライアントと関係しながら、どのように機能するかについて説明している。
【０２６１】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０２６２】
１．プロダクションサーバへの通常のクライアントアクセス。
【０２６３】
２．アプリケーションデータシャドウのニアラインサーバへの取り込み。
【０２６４】
３．アプリケーションデータの元または置換企業サーバへのオンデマンドの戻し。
【０２６５】
４．稠密アプリケーションデータの、空間的および時間的集約ならびにストレージ効率性の導入を有する代替フォーマットへの変換。
【０２６６】
５．クライアントは、信用できる方式で、ニアライン上の最新または履歴データへの直接セルフサービスアクセスを提供される。クライアントはまた、１次企業サーバが障害を起こした場合、ニアラインサーバからサービス保全も提供される。
【０２６７】
６．データ管理アプリケーションは、ニアラインサーバ上に集約され、任意選択的に後処理を施された企業アプリケーションデータへのアクセスを提供される。
【０２６８】
７．ニアラインサーバ上のデータは、災害防護の目的で、任意選択的にリモートサイトに配置され得るコピーに複製される。
【０２６９】
８．１次データセンタで壊滅的障害が起きた場合、置換企業サーバは、災害防護サイトから元のデータのコピーを獲得することができる。
【０２７０】
９．１次データセンタで使用不能が起きた場合、クライアントは、災害防護サイトでホストとされるニアラインレプリカからのニアラインホストデータおよび置換サーバへのアクセスを獲得することができる。
【０２７１】
１０．１次データセンタで使用不能が起きた場合、データ管理アプリケーションは、災害防護サイトにあるデータのコピーへの無中断アクセスを獲得することができる。
【０２７２】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
ニアラインサーバ構成および実装：
図４０は、一実施形態による、ニアライン構成要素の構成を含む、システム４０００である。このシステム４０００は、データ代理の一実施形態としての例示的なニアライン構成および実装の構成要素レベル図を示している。
【０２７３】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０２７４】
この図の残りの構成要素は、本明細書で先に説明されている。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
適用構成および実装：
図４１は、一実施形態による、適用構成を含む、システム４１００である。
【０２７５】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０２７６】
多次元データ代理の例示的なアプリケーション
このセクションは、とりわけ多次元データ代理を生成および維持することによって促進され得る少数のデータ管理アプリケーションを列挙する。これらのアプリケーションは、内在的である（または製品に組み込まれる）ことができ、その他は、外在的である（またはＡＰＩもしくはＷｅｂ  Ｓｅｒｖｉｃｅによって促進される）ことができる。その他のアプリケーションも可能である。これらのアプリケーションは、一般にメッセージングおよびコラボレーションサーバの文脈で説明され、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ  Ｓｅｒｖｅｒが一例である。しかし、概念および応用は、構造化、半構造化、または非構造化データを生成および消費する全クラスのアプリケーションに拡張可能である。
メッセージングライフサイクル管理を可能にする：
メールボックス拡張は、メッセージングサーバにおいてメッセージのライフサイクルを管理するためのメカニズムである。アクセスされる可能性の低いデータ、またはプロダクションサーバ上に保存するのが難しく思われるデータは、データ代理に転送される。図４２は、一実施形態による、メッセージングライフサイクル管理を含む、システム４２００である。図４３は、一実施形態による、ワンパスを介する拡張メッセージの傍受を含む、システム４３００である。これらのシステム４２００および４３００は、非常に大きく頻繁にはアクセスされないアイテムが、どのようにシームレスにニアラインサーバに転送され、クライアントによってアクセスされるときにフォールトバック（ｆａｕｌｔ  ｂａｃｋ）されるかを示している。このフォールトバックプロセスは、オンデマンドとすることができ、または観察もしくは事前プログラムされたパターンもしくはアクセスに基づいたプロアクティブなものとすることができる。このフォールトバックは、単一またはバッチとすることができ、何らかの形式のリファレンスの局在性のパターンを利用しようと試みることができる。
【０２７７】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０２７８】
１．メールボックス・エクステンダ・アプリケーションは、拡張の候補を決定するためにデータ代理にアクセスする。
【０２７９】
２．アプリケーションは、その後、リモートサーバにアクセスし、先のステップで識別されたアイテムを、データ代理内に存在するそのアイテムのコピーの軽量な表現であり得るスタブで置き換える。
【０２８０】
言及はメッセージングサーバおよびｅメールクライアントについてなされたが、概念は、任意のタイプの企業アプリケーションに拡張することができる。この例は単一の企業サーバについての動作を示しているが、同時機能を複数の同種または異種の企業サーバに提供することが可能なこともある。これらのサーバ自体は、カスケードされること、クラスタ化されること、複製化されること、仮想化されること、グリッドの部分であること、またはそれらの何らかのその他の組み合わせもしくは変形であることができる。この図の残りの構成要素は、本明細書で先に説明されている。
【０２８１】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。言及はメッセージングサーバおよびｅメールクライアントについてなされたが、概念は、任意のタイプの企業アプリケーションに拡張することができる。この例は単一の企業サーバについての動作を示しているが、同時機能を複数の同種または異種の企業サーバに提供することが可能なこともある。これらのサーバ自体は、カスケードされること、クラスタ化されること、複製化されること、仮想化されること、グリッドの部分であること、またはそれらの何らかのその他の組み合わせもしくは変形であることができる。
【０２８２】
１．ユーザが、先に拡張されたアイテムにアクセスしようと試みる。
【０２８３】
２．メールボックス傍受アプリケーションは、このアクセスを傍受し、データ代理からの必要とされるアイテムに結合することができる。
【０２８４】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
データ保護を可能にする：
図４４は、一実施形態による、ワンパスを介するデータ保護を提供する、システム４４００である。システム４４００は、増強データ代理を利用し、既存のデータ保護ソリューションよりも優れたＲＰＯおよびＲＴＯ機能を提供するデータ保護を実施する。
【０２８５】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０２８６】
１．通常のｅメールクライアント対話（またはＳＭＴＰリレー）が、メッセージングデータベースにデータ投入し、変更し、または拡張する。
【０２８７】
２．シャドウイングメカニズムは、このメッセージングデータベースのコピーを元のアプリケーションフォーマットでニアラインサーバ上に維持する。
【０２８８】
３．シャドウイングされたデータベースは、元のメッセージングサーバから利用可能であり、壊滅的なデータならびにサーバ喪失が起きた場合、置換から利用可能である。
【０２８９】
４．置換サーバは、壊滅的なデータならびにサーバ喪失が起きた場合、ニアラインサーバからクライアントに直接利用可能である。
【０２９０】
５．抽出メカニズムは、アプリケーションフォーマットから、後処理および異種のデータ管理アプリケーションアクセスの必要にとって都合の良い代替フォーマットに変換する。
【０２９１】
６．インデックス付けメカニズムは、データ分類および検索を容易にするより高いレベルのメタデータを継続的に追加するために、スケジュールもしくは要求によって、または連続的に動作する。
【０２９２】
７．検索プロセスは、履歴データベース（またはその部分）を時間的に、または分析、データ復旧、サービス復旧、もしくはその他の目的に必要とされる特定の属性を用いて、再構成することができる。
【０２９３】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
災害防護を可能にする：
データ代理は、複数の地理的に異なるサイトにまたがることができる。これは、ニアラインサーバなどの複数のメカニズムを含むことができ、データ保護アプリケーションにおいてデータを転送し、保存し、後処理するために使用されるメカニズムを含み、拡張することができる。データ代理の分散の結果として、データ代理は、サーバ、データセンタ、およびサイト障害を含み得る壊滅的な障害に対して回復力をもつ。そのような障害の存在下で、データ代理は、データの最新のコピーを戻し、または置換サーバの配備を促進し、またはクライアントおよびアプリケーションに直接向けたサービス保全さえも促進することが可能なことがある。このサービス保全は、その他のサーバ構成要素の協力を含むことができ、またはこれらのフェイルオーバおよびフェイルバック動作をトランスペアレントにするプロキシの導入を含むことができ、または何らかの変形もしくは組み合わせを含むことができる。
【０２９４】
図４５は、一実施形態による、災害防護を含む、システム４５００である。メッセージングサーバは、一例として使用されているが、概念は、その他のタイプのアプリケーションサーバにも拡張されることができる。単一のクライアントおよび単一のサーバだけが示されている。しかし、この機能をより多数のクライアントおよびサーバに拡張することが可能なことがある。データ代理は、代替サイトにまたがるように拡張される。この図では、一例として、適切なネットワークを介するレプリケーションによって実施されるデータ代理が示されている。データ代理は、２つの同位データ代理サーバが災害防護のために互いを利用するように、双方向レプリケーションを実施することも可能であることがある。これは、ｎを任意の数として、さらにｎ方向に拡張することができ、相互接続性は、メッシュ、ツリー、グラフ、ならびにその他の変形および組み合わせの任意的な組み合わせを含み得る、何らかの適切なトポロジを利用することができる。
【０２９５】
フェイルオーバおよびフェイルバックを、クライアント、サーバ、その他の関連する企業構成要素、または何らかの変形もしくは組み合わせに対してトランスペアレントにし得る、任意選択のプロキシが存在することができる。シャドウリポジトリだけが複製され、その後、デハイドレートされることができる。または、インデックス付きオブジェクトリポジトリだけが複製され、その後、シャドウがリハイドレートされることができる。または、これらの何らかの変形もしくは組み合わせが存在することができる。
任意選択のワンパスを介したアーカイバルを可能にする：
図４６は、一実施形態による、アーカイバルを含む、システム４６００である。システム４６００は、従来のアーカイビングのどのような短所も有することなく従来のアーカイビングの機能を超えるアーカイバルアプリケーションを実施する、増強データ代理を利用する、データ管理アプリケーションを含む。
【０２９６】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０２９７】
１．方針マネージャは、任意選択的にアーカイバルフィルタリング規則を定義することができる。
【０２９８】
２．インバンド抽出プロセスは、任意選択的にこれらの規則に直接従って動作することができる。
【０２９９】
３．方針マネージャは、任意選択的に保存および処分規則を設定することができる。
【０３００】
４．アウトオブバンド・インデックス・プロセスは、保存および処分規則を適用することができ、任意選択的にアーカイバルフィルタリング規則を適用することができる。
【０３０１】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
増強データ代理を用いて監査および法的開示を可能にする：
図４７は、一実施形態による、監査および法的開示メカニズムを含む、システム４７００である。一般に従来のアーカイバルシステムによって促進される監査および法的開示メカニズムは、増強データ代理ＡＰＩを介して存在するアプリケーションとして実施されることができる。
【０３０２】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０３０３】
１．方針マネージャが、データパターンを選択的に合致させるシステムの任意選択的な能力を増強する、包含、排除、獲得規則などを定義する任意選択的な能力。
【０３０４】
２．インバンド抽出プロセスが、これらの規則を適用する任意選択的な能力。
【０３０５】
３．方針マネージャが、後処理規則を定義する任意選択的な能力。
【０３０６】
４．インデックスプロセスが、包含、排除、および獲得規則、または後処理規則をアウトオブバンドで適用する任意選択的な能力。
【０３０７】
５．監査人が、プロアクティブに問い合わせを行い、または規則がトリガされたときに通知される任意選択的な能力。
【０３０８】
この図の残りの構成要素は、本明細書で先に説明されている。この例はメッセージングサーバを示しているが、等価なサービスを複数の同種または異種のサーバに提供することが可能である。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
ワンパスを介した監視および監督を可能にする：
図４８は、一実施形態による、ワンパスを介する監視および監督を含む、システム４８００である。システム４８００は、これが増強データ代理を介するアプリケーションとして実施され、従来のアーカイビングのどのような短所も有さない点を除いて、一般に従来のアーカイビングによって促進される監視および監督アプリケーションを示している。
【０３０９】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０３１０】
１．ＡＰＩまたはＷｅｂ  Ｓｅｒｖｉｃｅを使用するルールベースの任意選択的な更新。
【０３１１】
２．これらの規則に基づいたインバンド抽出プロセスの任意選択的な最適化。
【０３１２】
３．合致規則を探すための任意選択的なアウトオブバンドバッチ処理。
【０３１３】
４．プロアクティブに問い合わせを行い、合致を探す任意選択的な能力。
【０３１４】
５．ニアラインがプロアクティブに合致エンティティを通知する任意選択的な能力。
【０３１５】
この図の残りの構成要素は、本明細書で先に説明されている。この例は単一のニアラインサーバを示しているが、それは実際には、クラスタ化、分散化、複製化、仮想化されることができ、また複数のマシンまたはサイトにまたがることができる。
ワンパスを介するウイルス、ＳＰＡＭ、および侵入防護を可能にする：
図４９は、一実施形態による、ウイルス、ＳＰＡＭ、および侵入防護を含む、システム４９００である。システム４９００は、増強データ代理によって効率的に転送され、保存され、後処理されたデータ上で動作できる、セキュリティアプリケーションのクラスを含む。アプリケーションのこのクラスは、ゲートウェイに存在することができ、かつ／または企業サーバ上に直接存在することができる。ワンパスデータ代理メカニズムは、この「多層防御（ｄｅｆｅｎｓｅ  ｉｎ  ｄｅｐｔｈ）」を実施するための第３のロケーションを提供する。ニアラインサーバ上で実行される利点は、（ホストベースのシステムのせいで）プロダクションサーバに負の影響を与えることなく、または（ゲートウェイベースのシステムのせいで）メールのスループットを過度に引き延ばすことなく、問題（この場合は侵入の検出）を解決することに相当な計算能力を割くことができることである。
【０３１６】
先の図では、以下のフェーズが説明されている。これは一例であり、同様の目的を達成するために、その他の変形も可能であることに留意されたい。
【０３１７】
１．ＡＰＩまたはＷｅｂ  Ｓｅｒｖｉｃｅを使用する署名および／またはルールベースの任意選択的な更新。これらは、ウイルスもしくはＳＰＡＭ署名、または侵入予防規則を更新することを含むことができる。
【０３１８】
２．これらの規則または署名に基づいたインバンド抽出プロセスの任意選択的な最適化。
【０３１９】
３．合致規則および署名を探すための任意選択的なアウトオブバンドバッチ処理。
【０３２０】
４．プロアクティブに問い合わせを行い、合致を探す任意選択的な能力。
【０３２１】
５．ニアラインがプロアクティブに合致エンティティを通知する任意選択的な能力。
【０３２２】
この図の残りの構成要素は、本明細書で先に説明されている。この例は単一のニアラインサーバを示しているが、代替実施形態は、複数の装置および／または複数のサイトを含むが、これらに限定されない、クラスタ化、分散化、複製化、および仮想化されたプロセッサベースの装置を含むことができる。
【０３２３】
一実施形態の多次元代理は、少なくとも１つのデータソースから受信された、受信データと複数のデータ変更との情報を使用して、少なくとも１つのデータ代理を生成するステップと、各データ代理の元のメタデータを抽出するステップと、データ代理と元のメタデータの少なくとも一方を含む拡張データ代理を生成するステップと、アプリケーションとサーバの少なくとも一方による、データ代理と拡張データ代理の少なくとも一方のデータへのアクセスを制御するステップの少なくとも１つを含む方法を含む。
【０３２４】
一実施形態の方法は、少なくとも１つのデータソースから受信された、少なくとも１つの追加データ変更の情報を使用して、少なくとも１つのデータ代理を更新するステップをさらに含む。一実施形態の更新するステップは、少なくとも１つの追加データ変更の受信時と、複数の追加データ変更の受信後と、少なくとも１つの追加データ変更に対する処理動作後の少なくとも１つにおいて実行される。
【０３２５】
一実施形態の方法は、データ代理と拡張データ代理の少なくとも一方のデータを、複数の密度フォーマット間で変換するステップをさらに含む。
【０３２６】
一実施形態の方法は、元のメタデータの部分と各データ代理の要素とを組み合わせることによって、新しいメタデータを生成するステップをさらに含む。一実施形態の拡張データ代理は、新しいメタデータを含む。
【０３２７】
一実施形態の方法は、少なくとも１つのアプリケーションのデータフォーマットを検出するステップと、検出されたデータフォーマットに従って、データ代理と拡張データ代理の少なくとも一方のデータを変換するステップとをさらに含む。
【０３２８】
一実施形態の方法は、少なくとも１つのアプリケーションのデータ内容を検出するステップと、検出されたデータ内容に従って、データ代理と拡張データ代理の少なくとも一方のデータを変換するステップとをさらに含む。
【０３２９】
一実施形態の方法は、データ代理と拡張データ代理の少なくとも一方の少なくとも１つのインスタンスを、少なくとも１つのストレージサイトにアーカイブするステップをさらに含む。一実施形態のストレージサイトは、複数のストレージサイトを含む。一実施形態の方法は、データ代理と拡張データ代理の少なくとも一方で行われた変更の差分情報をアーカイブするステップをさらに含む。一実施形態のアーカイブするステップは、アクティブアーカイビングを含み、アクティブアーカイビングは、データ代理に対して少なくとも１つの動作を実行するステップと、データ代理と拡張データ代理の少なくとも一方を、対応アプリケーションに適したように、少なくとも１つのストレージサイトに配置するステップとの少なくとも一方を含む。一実施形態のアーカイブするステップは、パッシブアーカイビングを含み、パッシブアーカイビングは、データ代理と拡張データ代理の少なくとも一方の少なくとも１つのインスタンスを、参照データとして、少なくとも１つのストレージサイトにアーカイブするステップを含む。一実施形態のアーカイブするステップは、ディープアーカイビングを含み、ディープアーカイビングは、データ代理と拡張データ代理の少なくとも一方の複数のインスタンスを、少なくとも１つのストレージサイトにアーカイブするステップを含み、ディープアーカイビングによってアーカイブされたデータは、少なくとも１つの特権に従ってアクセスされる。
【０３３０】
一実施形態の方法は、データ代理と拡張データ代理の少なくとも一方を、少なくとも１つのアプリケーションと統合するステップをさらに含む。一実施形態のアプリケーションは、認証アプリケーションと、権限付与アプリケーションと、アクセス制御アプリケーションと、改ざん検出アプリケーションと、改ざん予防アプリケーションと、監査アプリケーションとを含む。一実施形態の少なくとも１つのアプリケーションは、ユーザと、管理者と、監査人と、方針マネージャの少なくとも１つによるデータ代理へのアクセスを規制する。
【０３３１】
一実施形態の方法は、データ代理と拡張データ代理の少なくとも一方のデータの一部を、少なくとも１つのサーバに転送するステップをさらに含む。一実施形態の転送するステップは、サービス品質メカニズムと、リモート変更検出メカニズムと、データ転送のハッチング（ｈａｔｃｈｉｎｇ）と、転送スケジュールの最適化の少なくとも１つを含み、転送するステップは、帯域幅を保ち、待ち時間を最適化する。一実施形態の転送するステップは、プライバシメカニズムを適用するステップと、耐改ざん性メカニズムを適用するステップとの少なくとも一方を含む。一実施形態の転送するステップは、データ代理と拡張データ代理の少なくとも一方の複数のコピーが転送するステップから生じる場合、法的要件と、保存、処分、監視、および監督の遵守要件との少なくとも一方に従う。少なくとも１つのサーバは、ローカルサーバと、リモートサーバと、メッセージングサーバと、電子メールサーバと、インスタント・メッセージング・サーバと、ボイスオーバーインターネット・プロトコル・サーバと、コラボレーションサーバと、ポータルと、顧客関係管理（ＣＲＭ）サーバと、企業資源計画（ＥＲＰ）サーバと、企業間サーバと、コンテンツ管理サーバと、データベースサーバの少なくとも１つを含む。
【０３３２】
一実施形態の方法は、データ代理と拡張データ代理の少なくとも一方のデータの一部を、少なくとも１つのクライアントアプリケーションに転送するステップをさらに含み、少なくとも１つのクライアントアプリケーションは、ローカル・クライアント・アプリケーションと、リモート・クライアント・アプリケーションとを含む。一実施形態の方法は、少なくとも１つの結合された企業と統合される方式で、認証と、権限付与と、アクセス制御と、否認防止の少なくとも１つを介する、データ代理と拡張データ代理の少なくとも一方へのアクセスを強制するステップをさらに含む。一実施形態の方法は、データ代理と拡張データ代理の少なくとも一方へのアクセスを制御するステップと、転送中および停止中にデータのプライバシおよび耐改ざん性を維持するステップとをさらに含む。
【０３３３】
一実施形態の方法は、データ代理と拡張データ代理の少なくとも一方を、データ代理と拡張データ代理が関連付けられた少なくとも１つのアプリケーションに従って、少なくとも１つのストレージサイトに保存するステップをさらに含む。
【０３３４】
一実施形態の方法は、データ代理と拡張データ代理の少なくとも一方への、少なくとも１つのユーザによるアクセスを制御するステップをさらに含む。
【０３３５】
一実施形態の方法は、データ代理と拡張データ代理の少なくとも一方を、ソース、内容、キーワード、エイジ、サイズ、ユーザ、方針、およびアクセス頻度を含む少なくとも１つのパラメータに従って、複数のストレージ装置にわたって移動させるステップをさらに含む。
【０３３６】
一実施形態の方法は、データ代理のデータをターゲットサーバ上にリストアするステップをさらに含み、ターゲットサーバは、受信データのソースサーバである。
【０３３７】
一実施形態の方法は、データ代理のデータをターゲットサーバにリダイレクトするステップをさらに含み、リストアされるターゲットサーバは、受信データのソースサーバとは異なるサーバである。一実施形態のターゲットサーバは、異なるネットワーク上およびソースサーバとは異なるサイトの少なくとも一方に配置される。
【０３３８】
一実施形態のデータ代理と拡張データ代理の少なくとも一方を生成するステップは、自動トリガと、タイマ通知と、イベント通知と、ポーリングと、リクエストの少なくとも１つに応答したものである。一実施形態の自動トリガは、少なくとも１つの事前指定パラメータに応答して自動的に開始されるトリガを含む。一実施形態の自動トリガは、データ代理と拡張データ代理の少なくとも一方の内容を含む。一実施形態のタイマ通知が、保守動作と、ユーザ活動と、サーバ活動と、データ投入動作の少なくとも１つを含むスケジュールされたイベントに対応する通知を含む。一実施形態のイベント通知は、データソースのデータへの変更に対応する通知を含む。一実施形態のリクエストが、ユーザ、サーバ、またはアプリケーションによる、アクセスの試みとコンフィグレーションの試みの少なくとも一方を含む。
【０３３９】
一実施形態の方法は、受信データの少なくとも１つのパラメータを決定するステップであって、少なくとも１つのパラメータが、受信データのサイズと、エイジと、アクセス頻度と、最終アクセス時間の少なくとも１つを含むステップと、受信データを、パラメータに従って、データ代理内の受信データの少なくとも１つのコピーへの少なくとも１つのポインタで置き換えるステップとをさらに含む。一実施形態の方法は、少なくとも１つのポインタを使用する、アプリケーションと、サーバと、ユーザの少なくとも１つによる受信データへのその後のアクセスを傍受するステップと、データ代理と拡張データ代理の少なくとも一方からのデータを結合することによって、その後のアクセスを提供するステップとをさらに含む。
【０３４０】
一実施形態の多次元代理は、データと複数のデータ変更とを受信するＤＳＳサーバと、データとデータ変更との情報を使用して、少なくとも１つのデータ代理を生成する、ＤＳＳサーバに結合されるエンジンと、各データ代理の元のメタデータを抽出し、データ代理と元のメタデータの少なくとも一方を含む拡張データ代理を生成する、エンジンに結合されるエクストラクタとの少なくとも１つを備える、データ代理システム（ＤＳＳ）を含み、ＤＳＳサーバは、アプリケーションとサーバの少なくとも一方による、データ代理と拡張データ代理の少なくとも一方のデータへのアクセスを制御する。
【０３４１】
一実施形態のシステムは、ＤＳＳサーバに結合される変換器をさらに備え、変換器は、データ代理と拡張データ代理の少なくとも一方のデータを、データのフォーマットから少なくとも１つの代替フォーマットに変換する。
【０３４２】
一実施形態のシステムは、ＤＳＳサーバに結合される少なくとも１つのリポジトリをさらに備え、リポジトリは、データと、データ変更ファイルと、データ代理と、拡張データ代理と、元のメタデータと、新しいメタデータの少なくとも１つを保存する。
【０３４３】
一実施形態のＤＳＳサーバは、少なくとも１つのデータソースから受信された、少なくとも１つの追加データ変更の情報を使用して、少なくとも１つのデータ代理を更新する。
【０３４４】
一実施形態のＤＳＳサーバは、元のメタデータの部分と各データ代理の要素とを組み合わせることによって、新しいメタデータを生成する。
【０３４５】
一実施形態のＤＳＳサーバは、少なくとも１つのアプリケーションのデータフォーマットと内容の少なくとも一方を検出し、検出されたデータフォーマットと検出された内容の少なくとも一方に従って、データ代理と拡張データ代理の少なくとも一方のデータを変換する。
【０３４６】
一実施形態のＤＳＳサーバは、データ代理と拡張データ代理の少なくとも一方のデータの一部を、少なくとも１つの他のサーバに転送する。
【０３４７】
一実施形態のＤＳＳサーバは、データ代理と拡張データ代理の少なくとも一方のデータの一部を、少なくとも１つのクライアントアプリケーションに転送し、少なくとも１つのクライアントアプリケーションは、ローカル・クライアント・アプリケーションと、リモート・クライアント・アプリケーションとを含む。
【０３４８】
一実施形態のＤＳＳサーバは、少なくとも１つのユーザによる、データ代理と拡張データ代理の少なくとも一方へのアクセスを制御する。
【０３４９】
一実施形態のＤＳＳサーバは、データ代理と拡張データ代理の少なくとも一方を、ソース、内容、キーワード、エイジ、サイズ、ユーザ、方針、およびアクセス頻度を含む少なくとも１つのパラメータに従って、複数のストレージ装置にわたって移動させる。
【０３５０】
一実施形態のＤＳＳサーバは、データ代理のデータをターゲットサーバ上にリストアし、ターゲットサーバは、受信データのソースサーバである。
【０３５１】
一実施形態のＤＳＳサーバは、データ代理のデータをターゲットサーバにリダイレクトし、リストアされるターゲットサーバは、受信データのソースサーバとは異なるサーバである。
【０３５２】
一実施形態のシステムは、ＤＳＳサーバに結合される少なくとも１つの企業サーバをさらに備える。一実施形態の企業サーバは、ローカルサーバと、リモートサーバと、メッセージングサーバと、電子メールサーバと、インスタント・メッセージング・サーバと、ボイスオーバーインターネット・プロトコル・サーバと、コラボレーションサーバと、ポータルと、顧客関係管理（ＣＲＭ）サーバと、企業資源計画（ＥＲＰ）サーバと、企業間サーバと、コンテンツ管理サーバと、データベースサーバの少なくとも１つを含む。
【０３５３】
一実施形態のシステムは、ＤＳＳサーバに結合される少なくとも１つのネットワークをさらに備える。一実施形態のネットワークは、ローカルエリアネットワーク（ＬＡＮ）と、メトロポリタンエリアネットワーク（ＭＡＮ）と、ワイドエリアネットワーク（ＷＡＮ）と、ストレージエリアネットワーク（ＳＡＮ）とを含む。
【０３５４】
一実施形態のシステムは、元のメタデータをフィルタリングするために、エクストラクタに結合される少なくとも１つのフィルタをさらに備える。
【０３５５】
一実施形態のエクストラクタは、元のメタデータの部分と各データ代理の要素の間の関係を識別する。
【０３５６】
一実施形態のエクストラクタは、関係に従って、元のメタデータの部分と各データ代理の要素とを選択的に組み合わせることによって、新しいメタデータを生成する。一実施形態の拡張データ代理は、新しいメタデータを含む。
【０３５７】
上で説明された多次元代理の構成要素は、一緒に動作するコンピューティング構成要素および装置の集まりを含むことができる。多次元代理の構成要素は、より大きなコンピュータシステムまたはネットワーク内の構成要素またはサブシステムとすることもできる。多次元代理の構成要素は、任意の数の構成要素（図示されず）、例えば、その他のバス、コントローラ、メモリ装置、およびデータ入力／出力（Ｉ／Ｏ）装置の間で、任意の数の組み合わせで、結合されることもできる。さらに、多次元代理の機能は、任意の数／組み合わせのその他のプロセッサベースの構成要素の間に分散させることができる。
【０３５８】
本明細書で説明された多次元代理の態様は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブルアレイロジック（ＰＡＬ）デバイス、電気的プログラム可能ロジックおよびメモリデバイス、ならびに標準セルベースデバイスなどのプログラマブル論理回路（ＰＬＤ）と、特定用途向け集積回路（ＩＣ）とを含む、様々な回路のいずれかにプログラムされる機能として実施されることができる。多次元代理の態様を実施するためのいくつかの他の可能性は、（電気的消去可能なプログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）などの）メモリを備えるマイクロコントローラ、埋め込みマイクロプロセッサ、ファームウェア、ソフトウェアなどを含む。さらに、多次元代理の態様は、ソフトウェアベースの回路エミュレータを有するマイクロプロセッサ、ディスクリートロジック（順次および組み合わせ）、カスタムデバイス、ファジー（ニューラル）ロジック、量子デバイス、および上記デバイスタイプのいずれかの混成で実施されることができる。基盤をなすデバイス技術は、例えば、相補形金属酸化物半導体（ＣＭＯＳ）のような金属酸化物半導体電界効果トランジスタ（ＭＯＳＦＥＴ）技術、エミッタ結合論理（ＥＣＬ）のようなバイポーラ技術、ポリマー技術（例えば、シリコン共役ポリマーおよび金属共役ポリマー金属構造）、混合アナログおよびデジタルなど、様々な構成要素タイプで提供されることができる。
【０３５９】
本明細書で開示された多次元代理の様々な構成要素は、様々なコンピュータ可読媒体内に実施されるデータおよび／または命令を使用して記述され得ることに留意されたい。そのようなフォーマットデータおよび／または命令が実施され得るコンピュータ可読媒体は、様々な形態の不揮発性記憶媒体（例えば、光、磁気、または半導体記憶媒体）、ならびにそのようなフォーマットデータおよび／または命令を、無線、光、もしくは有線信号媒体、またはそれらの組み合わせを介して、転送するために使用され得る搬送波を含むが、これらに限定されない。搬送波によるそのようなフォーマットデータおよび／または命令の転送の例は、１つまたは複数のデータ転送プロトコル（例えば、ＨＴＴＰ、ＦＴＰ、ＳＭＴＰなど）によるインターネットおよび／またはその他のコンピュータネットワークを介した転送（アップロード、ダウンロード、ｅメールなど）を含むが、これらに限定されない。１つまたは複数のコンピュータ可読媒体を介してコンピュータシステム内で受け取られると、多次元代理のそのようなデータおよび／または命令ベースの表現は、１つまたは複数のその他のコンピュータプログラムの実行と連動して、コンピュータシステム内で処理エンティティ（例えば、１つまたは複数のプロセッサ）によって処理されることができる。
【０３６０】
文脈が明らかに別のことを必要としない限り、説明および特許請求の範囲の全体にわたって、「含む」および同様の語は、排他的または網羅的意味ではなく包含的意味に、すなわち、「含むが、それらに限定されない」という意味に解釈されるべきである。単数または複数を使用する語は、それぞれ、複数または単数も含む。加えて、「本明細書で」、「これ以降で」、「上で」、「以下で」、および同様の趣旨の語は、本出願を全体として指しており、本出願の特定の部分を指すものではない。「または」という語が２つ以上のアイテムからなるリストに関連して使用される場合、その語は、その語の以下の解釈のすべて、すなわち、リスト内のアイテムのどれか、リスト内のアイテムのすべて、およびリスト内のアイテムの任意の組み合わせを含む。
【０３６１】
多次元代理の例示された実施形態の上の説明は、網羅的であること、または開示された通りの形に多次元代理を限定することは意図されていない。多次元代理の特定の実施形態および例が、本明細書において例示的な目的で説明されたが、当業者であれば理解されるように、多次元代理の範囲内で様々な等価な変更が可能である。本明細書において提供された多次元代理についての教示は、上で説明されたシステムおよび方法ばかりでなく、その他の処理システムおよび方法にも適用されることができる。
【０３６２】
上で説明された様々な実施形態の要素および動作は、さらなる実施形態を提供するために組み合わされることができる。これらおよびその他の変更が、上の詳細な説明に照らして、多次元代理および方法に施されることができる。
【０３６３】
一般に、以下の特許請求の範囲において、使用される用語は、多次元代理および方法を明細書および特許請求の範囲で開示された特定の実施形態に限定すると解釈されるべきでなく、特許請求の範囲の下で動作するすべての処理システムを含むと解釈されるべきである。したがって、多次元代理は、本開示によって限定されず、代わりに、多次元代理の範囲は、特許請求の範囲によって完全に決定される。
【０３６４】
多次元代理のある態様が、以下である請求項の形で提示されるが、発明者らは、任意の数の請求項の形で多次元代理の様々な態様を企図している。例えば、多次元代理のただ１つの態様が、マシン可読媒体内で実施されるとして述べられているが、その他の態様も同様に、マシン可読媒体内で実施されることができる。したがって、発明者らは、多次元代理のその他の態様のための追加の請求項の形を追求するために、本出願を出願した後も、そのような追加の請求項を追加する権利を保有する。
【図面の簡単な説明】
【０３６５】
【図１】一実施形態による、多次元データ代理システムのブロック図である。
【図２】一実施形態による、データ代理の方法のフローチャートである。
【図３】完全および増分バックアップを保存するためにテープまたはディスクを使用するバックアップアプリケーションによって保護されるメッセージングサーバを含むシステムの図である。
【図４】レプリケーションを使用して保護されるメッセージングサーバを含むシステムの図である。
【図５】スナップショットメカニズムを含むシステムの図である。
【図６】ＳＭＴＰを介して送信されるｅメールを傍受することを含むアーカイバルを示す図である。
【図７】特定のメールボックスに到着する、または特定のメールボックスを出発したすべてのｅメールが、ｅメールクライアントになりすましたプロキシによってアクセスされ、複製される、なりすましを使用するメカニズムを介してｅメールが獲得されるアーカイバルを示す図である。
【図８】Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ  Ｓｅｒｖｅｒジャーナリングを使用するアーカイバルを示す図である。
【図９】データ管理機能を提供するニアラインサーバを含むシステムの図である。
【図１０】ニアラインサーバをテープ用のディスクキャッシュとして含むシステムの図である。
【図１１】ニアラインストレージを使用する仮想テープライブラリを含むシステムの図である。
【図１２】ログシッピングを含むシステムの図である。
【図１３】サーバクラスタリングを含むシステムの図である。
【図１４】ジオクラスタリングを含むシステムの図である。
【図１５】サービス最適化およびサービス継続性をリモートサイトに提供するメッセージングサーバをキャッシュすることを含むシステムの図である。
【図１６】一実施形態による、データ代理を含むシステムの図である。
【図１７】一代替実施形態による、データ代理を含むシステムの図である。
【図１８】一実施形態による、ローカルで複製されたデータ代理を含むシステムの図である。
【図１９】一実施形態による、リモートデータ代理を含むシステムの図である。
【図２０】一実施形態による、単次元データ代理を含むシステムの図である。
【図２１】一実施形態による、ワンパスを介するメッセージングライフサイクル管理を含むシステムの図である。
【図２２】一実施形態による、連続的なログ適用プロセスを含むシステムの図である。
【図２３】一実施形態による、動的ログシッピングを含むシステムの図である。
【図２４】一実施形態による、ログトレイリングを含むシステムの図である。
【図２５】一実施形態による、多次元データ提示フォーマットを含むシステムの図である。
【図２６】一実施形態による、多次元サーバ集約を含むシステムの図である。
【図２７】一実施形態による、２つのタイプのプロダクションサーバ（例えば、ｅメールおよびＣＲＭ）を統合するシステムの図である。
【図２８】一実施形態による、時間、サーバ、および提示次元を統合するシステムの図である。
【図２９】一実施形態による、ストレージ最適化を使用して、時間、サーバ、提示次元を統合するシステムの図である。
【図３０】一実施形態による、多次元サーバ集約を含むシステムの図である。
【図３１】一実施形態による、認証、権限付与、および監査を統合するシステムの図である。
【図３２】一実施形態による、プログラム可能な階層的方針管理を含むシステムの図である。
【図３３】一実施形態による、保証された保存および処分方針施行を含むシステムの図である。
【図３４】一実施形態による、ローカルまたはリモートサービス保全を含むシステムの図である。
【図３５】一実施形態による、ニアラインサーバ上での否認防止を含むシステムの図である。
【図３６】一実施形態による、否認防止を含むシステムの図である。
【図３７】一実施形態による、多次元ワンパス代理を含むシステムの図である。
【図３８】一実施形態による、複数のデータ管理アプリケーションを含むシステムの図である。
【図３９】一実施形態による、企業環境における増強データ代理の例示的な配備を含むシステムの図である。
【図４０】一実施形態による、ニアライン構成要素の構成を含むシステムの図である。
【図４１】一実施形態による、適用構成を含むシステムの図である。
【図４２】一実施形態による、メッセージングライフサイクル管理を含むシステムの図である。
【図４３】一実施形態による、ワンパスを介する拡張メッセージの傍受を含むシステムの図である。
【図４４】一実施形態による、ワンパスを介するデータ保護を提供するシステムの図である。
【図４５】一実施形態による、災害防護を含むシステムの図である。
【図４６】一実施形態による、アーカイバルを含むシステムの図である。
【図４７】一実施形態による、監査および法的開示メカニズムを含むシステムの図である。
【図４８】一実施形態による、ワンパスを介する監視および監督を含むシステムの図である。
【図４９】一実施形態による、ウイルス、ＳＰＡＭ、および侵入防護を含むシステムの図である。
【図１】
2008530658.tif 000003
【図２】
2008530658.tif 000004
【図３】
2008530658.tif 000005
【図４】
2008530658.tif 000006
【図５】
2008530658.tif 000007
【図６】
2008530658.tif 000008
【図７】
2008530658.tif 000009
【図８】
2008530658.tif 000010
【図９】
2008530658.tif 000011
【図１０】
2008530658.tif 000012
【図１１】
2008530658.tif 000013
【図１２】
2008530658.tif 000014
【図１３】
2008530658.tif 000015
【図１４】
2008530658.tif 000016
【図１５】
2008530658.tif 000017
【図１６】
2008530658.tif 000018
【図１７】
2008530658.tif 000019
【図１８】
2008530658.tif 000020
【図１９】
2008530658.tif 000021
【図２０】
2008530658.tif 000022
【図２１】
2008530658.tif 000023
【図２２】
2008530658.tif 000024
【図２３】
2008530658.tif 000025
【図２４】
2008530658.tif 000026
【図２５】
2008530658.tif 000027
【図２６】
2008530658.tif 000028
【図２７】
2008530658.tif 000029
【図２８】
2008530658.tif 000030
【図２９】
2008530658.tif 000031
【図３０】
2008530658.tif 000032
【図３１】
2008530658.tif 000033
【図３２】
2008530658.tif 000034
【図３３】
2008530658.tif 000035
【図３４】
2008530658.tif 000036
【図３５】
2008530658.tif 000037
【図３６】
2008530658.tif 000038
【図３７】
2008530658.tif 000039
【図３８】
2008530658.tif 000040
【図３９】
2008530658.tif 000041
【図４０】
2008530658.tif 000042
【図４１】
2008530658.tif 000043
【図４２】
2008530658.tif 000044
【図４３】
2008530658.tif 000045
【図４４】
2008530658.tif 000046
【図４５】
2008530658.tif 000047
【図４６】
2008530658.tif 000048
【図４７】
2008530658.tif 000049
【図４８】
2008530658.tif 000050
【図４９】
2008530658.tif 000051
【国際調査報告】
2008530658.tif 000052