(57)【要約】  データの定期的なアーカイブ、削除または、１つのデータ・ストレージ・システムから別のデータ・ストレージ・システムへの移動に対する基準を構成可能にアーティキュレートする方法及びシステムを提供する。特定のデータを管理するプログラムを実行する一貫した処理は、アーティキュレートされた基準を用いて、プログラムによって処理されるデータ・エンティティと関連するデータ・セット及びルールを識別する。データ・エンティティは、異なる国家、カンパニーまたは契約上の協定によって必要とされるような異なる制御ルール及びポリシーを有することができる。データ・エンティティは、ストレージ期間、アーカイブ頻度、保存期間などを定義するルール及びポリシーと関連付けられる。結果として、組織の保存ポリシーを獲得し、様々なアプリケーション・システムを介して管理される一貫した処理を達成することができる。
2008518295.tif 000002
【特許請求の範囲】
【請求項１】
データを制御する方法であって、
１つ以上のデータ・オブジェクトのデータ保存ポリシーと関連する１つ以上のデータ管理ルールを定義し、前記データ管理ルールの各々について、前記データ・オブジェクトに関連するアプリケーション・プログラム・システムと、前記データ・オブジェクトを識別するパラメータと、前記データ・オブジェクトのアーカイブ管理を実行するソフトウェア・モジュールとを指定するステップと、
あるイベントに応答して前記ソフトウェア・モジュールを実行し、前記イベントが、前記アーカイブ管理を前記パラメータと、前記指定したアプリケーション・システムとに基づいて制御するために前記データ管理ルールの少なくとも１つを識別し、前記指定したアプリケーション・システムが、前記データ管理ルールによって識別された前記データ・オブジェクトに対してアーカイブ管理動作を実行するステップとを
含む方法。
【請求項２】
前記データ保存ポリシーと関連する１つ以上のデータ管理ルール・タイプを定義するステップを更に含み、前記データ管理ルールが各々前記データ管理ルール・タイプのインスタンスを定義し、
前記データ・ルール・タイプが、エンティティ・タイプのデータ保存ポリシーを記述する名前付きルール・タイプを指定し、
前記データ・ルール・タイプが、前記アーカイブ管理を制御するのに用いる以下の属性、すなわち、
ｖｉｉｉ）  アプリケーションＩＤ
ｉｘ）  アプリケーション・システムＩＤ
ｘ）  コーポレーションＩＤ
ｘｉ）  管理対象エンティティ名
ｘｉｉ）  制御エンティティ名
ｘｉｉｉ）  役割ＣＤ
ｘｉｖ）  制御日付カラムＩＤ、または、
ｖｉｉｉ）  データ保存ポリシーＩＤ
の１つ以上を有する、請求項１に記載の方法。
【請求項３】
前記エンティティ・タイプが、一意的に識別される人、場所、事柄、概念またはイベントを定義し、名前属性及び記述属性の少なくとも１つを有し、前記エンティティ・タイプに対して完全なキーを構成する属性を定義する関連のエンティティ・キー属性を有する、請求項２に記載の方法。
【請求項４】
前記アーカイブ管理を制御するのに用いる以下の属性、すなわち、
ｉｘ）  インストール済みアプリケーションＩＤ
ｘ）  エンティティ・キー
ｘｉ）  アクション前の時間
ｘｉｉ）  測定の時間単位
ｘｉｉｉ）  コミット数
ｘｉｖ）  最大反復
ｘｖ）  データ保存タイプ、または、
ｘｖｉ）  イベント名
の１つ以上を定義し、前記データ管理ルールと関連付けるステップを更に含む、請求項１に記載の方法。
【請求項５】
前記データ管理ルールが、インストール済みアプリケーションＩＤと、ビジネス機能コード、アプリケーション・システムＩＤ及びインストール済みアプリケーション記述の少なくともいずれか１つとを有するインストール済みアプリケーション・エンティティに関連する、請求項４に記載の方法。
【請求項６】
前記データ・オブジェクトを識別し、エンティティ名及びエンティティ記述を含む属性を有する１つ以上のエンティティ・タイプと、エンティティ・キー属性とを定義するステップを更に含む、請求項１に記載の方法。
【請求項７】
前記エンティティ・キー属性が、エンティティ名、エンティティ・キー・シーケンス及びキー属性名を含む属性を有する、請求項６に記載の方法。
【請求項８】
前記エンティティ・タイプの１つのインスタンスを生成することによって呼び出されることに応答して固有の識別子を構成する連続するアルゴリズム・セットを各々定義する１つ以上のエンティティ・ビルダを定義するステップを更に含む、請求項６または７に記載の方法。
【請求項９】
１つ以上のコンピュータ・ジョブ・エンティティを含む１つ以上の属性を有する作業単位エンティティを定義するステップを更に含む、請求項１〜８のいずれか一項に記載の方法。
【請求項１０】
前記エンティティ・キーによって識別された前記データ・オブジェクトの少なくとも１つの前記アーカイブ管理を制御するため、インストール済みアプリケーションＩＤ、データ管理ルール名、エンティティ・キー、作業単位開始日付、作業単位終了日付及び作業単位状態の少なくともいずれか１つを含む前記作業単位エンティティの１つ以上の属性を定義するステップを更に含む、請求項９に記載の方法。
【請求項１１】
１つ以上のデータ管理ログ・エンティティを、実行されると前記アーカイブ管理の活動をロギングする前記コンピュータ・ジョブ・エンティティと関連付けるステップを更に含み、前記データ管理ログ・エンティティが、インストール済みアプリケーションＩＤ、データ管理ルール名、エンティティ・キー、作業単位開始日付、作業単位終了日付、ジョブ番号、ログ・タイムスタンプ、活動状態、ログ済みメッセージ及び取引数の少なくともいずれか１つを含む属性を有する、請求項９に記載の方法。
【請求項１２】
前記実行するステップを開始するため、前記イベントが定期的に生じ、イベント名を前記データ管理ルールに供給する、請求項１〜１１のいずれか一項に記載の方法。
【請求項１３】
データ管理を制御する方法であって、
コントローラのインスタンスを生成し、イベント名を前記コントローラに供給するステップと、
前記イベント名と関連するルールにアクセスするステップと、
前記ルールと関連するルール・タイプと関連する制御データを獲得するステップと、
少なくとも作業単位定義を含む前記制御データによって定義された１つ以上のデータ・オブジェクトについてアーカイブ機能を実行するプログラムを実行するステップと
を含む方法。
【請求項１４】
前記作業単位定義が開始日付及び終了日付のパラメータを含む、請求項１３に記載の方法。
【請求項１５】
前記制御データが、アプリケーション・システム、前記データ・オブジェクトと関連するエンティティ名、制御エンティティ名及び最大反復の少なくともいずれか１つを定義する、請求項１３または１４に記載の方法。
【請求項１６】
前記アーカイブ機能が、データの削除、データのパージ、及び、ストレージ用の１つのシステムから別のシステムへのデータの移動の少なくともいずれか１つを含む、請求項１３〜１５のいずれか一項に記載の方法。
【請求項１７】
データを管理するシステムであって、
コントローラのインスタンスを生成し、イベント名を前記コントローラに供給する手段と、
前記イベント名によって識別されたルール・タイプと関連する制御データを獲得する手段と、
少なくとも作業単位定義を含む前記制御データによって定義された１つ以上のデータ・オブジェクトについてアーカイブ機能を実行するプログラムを実行する手段と
を含むシステム。
【請求項１８】
前記作業単位定義が開始日付及び終了日付のパラメータを含む、請求項１７に記載のシステム。
【請求項１９】
前記制御データが、アプリケーション・システム、前記データ・オブジェクトと関連するエンティティ名、制御エンティティ名及び最大反復の少なくともいずれか１つを定義する、請求項１７または１８に記載のシステム。
【請求項２０】
前記アーカイブ機能が、データの削除、データのパージ、及び、ストレージ用の１つのシステムから別のシステムへのデータの移動の少なくともいずれか１つを含む、請求項１７〜１９のいずれか一項に記載のシステム。
【請求項２１】
前記アーカイブ機能を制御するのに用いる以下の属性、すなわち、
ｉｘ）  インストール済みアプリケーションＩＤ
ｘ）  エンティティ・キー
ｘｉ）  アクション前の時間
ｘｉｉ）  測定の時間単位
ｘｉｉｉ）  コミット数
ｘｉｖ）  最大反復
ｘｖ）  データ保存タイプ、及び、
ｘｖｉ）  イベント名
の１つ以上を有する前記ルール・タイプのインスタンスを生成し供給する手段を更に含む、請求項１７〜２０のいずれか一項に記載のシステム。
【請求項２２】
前記ルール・タイプが、インストール済みアプリケーションＩＤと、ビジネス機能コード、アプリケーション・システムＩＤ及びインストール済みアプリケーション記述の少なくともいずれか１つとを含む属性を有するインストール済みアプリケーション・エンティティに関連する、請求項１７〜２１のいずれか一項に記載のシステム。
【請求項２３】
前記作業単位定義のインスタンスが生成され、前記作業単位定義が、前記ルール・タイプと関連する前記オブジェクトを識別するために制御パラメータを前記プログラムに供給する、請求項１７〜２２のいずれか一項に記載のシステム。
【請求項２４】
前記イベント名によって開始された前記プログラムの前記実行と関連する情報をロギングする手段を更に含む、請求項１７〜２３のいずれか一項に記載のシステム。
【請求項２５】
コンピュータ使用可能媒体を含むコンピュータ・プログラム製品であって、前記媒体内には、可読プログラム・コードが統合され、
１つ以上のデータ・オブジェクトのデータ保存ポリシーと関連する１つ以上のデータ管理ルールを定義し、前記データ管理ルールの各々が、前記複数のデータ・オブジェクトに関連するアプリケーション・プログラム・システムと、前記データ・オブジェクトを識別するパラメータと、前記データ・オブジェクトのアーカイブ管理を実行するソフトウェア・モジュールとを指定し、
イベントが生じると前記ソフトウェア・モジュールを実行し、前記イベントが、前記アーカイブ管理を前記パラメータと、前記指定したアプリケーション・システムとに基づいて制御するために前記データ管理ルールの少なくとも１つを識別する
少なくとも１つの構成要素を含むコンピュータ・プログラム製品。
【請求項２６】
請求項１〜１２のいずれか一項に記載の方法を実行する手段を含むシステム。
【請求項２７】
請求項１〜１６のいずれか一項に記載の方法を実行するのに適するプログラム・コード手段を含むコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、データをアーカイブするシステム及び方法に関し、特に、高度に構成可能なデータ保存ポリシーに基づいてデータをアーカイブするシステム及び方法に関する。
【背景技術】
【０００２】
コンピュータ・システムに格納されたデータは、種々の理由のため、削除または、別のストレージ装置への移動を含む定期的なアーカイブを典型的に必要とする。定期的なアーカイブを、任意の指定された時間期間にすることができる。この期間管理の基準は、カンパニーのデータ保存ポリシー、エンド・ユーザ要件、システム容量及び性能を含む様々な要因によってしばしば影響を及ぼされる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
あるカンパニーが多くのその他のカンパニーまたは組織（例えば、政府機関、部門、部署、異なるカスタマなど）の代わりにデータを制御または管理する状況では、適切なデータ・オブジェクトの識別及びデータ・オブジェクトのアーカイブの管理は問題となる。同様に、例えば、場合によって多様なカスタマ・ベースのため、カンパニーが、別個の異なったオブジェクトとしてデータを分離し管理するためのビジネス上の理由を有する状況では、異なる定期的なアーカイブのすべてを考慮する一貫したアーカイブ・ポリシーを計画し実行すること、並びに、アーカイブのデータ・オブジェクトを識別することは、かなり難問であって複雑になることがある。
【０００４】
この複雑性を組み立てることを、ビジネス関係または政府の政策のために生じることが多い契約上の協定または義務によって課される要件とすることがある。これら要件は、他のものとかなり異なることがある。カンパニーが、このような関係または政策の代わりに、またはその結果としてデータを管理することに従事している場合、多くの異なるアーカイブ要件は、定期的なアーカイブを実行する義務があるカンパニーを容易に圧倒することがある。異なる要件のすべてが満足される準拠を追跡し保証することは、困難な作業となることがある。
【０００５】
更に、今日の大部分のアーカイブ・プログラムは、共通の機能に対処するため、一貫性なく追加費用で典型的に開発されている。すなわち、各アーカイブ・プログラムは、特定の開発目的によるアーカイブまたは削除などの候補であるデータ・セットを識別することに典型的に対処し、異なるデータ・セットに対してもアーカイブ機能を実行しようとすることがあるその他のいかなるアーカイブ・プログラムに関係なく一方的に関連の性能問題に対処する。各々が特定タイプまたはカテゴリのデータを典型的にターゲットにしている多くの異なるアーカイブ・プログラムを含むことがあるこの一方的なアーカイブ状況は、コンピュータ・システムの処理能力及び性能を酷使し、主要な非アーカイブ・アプリケーションの有効性または適時性に影響を及ぼすことがある。これらプログラムの大部分は、（構成を高価にする）内部にコード化された管理ルール、または、構成制御用に開発された独自手段を有する。
【課題を解決するための手段】
【０００６】
本発明の一側面では、データを制御する方法を提供する。この方法は、１つ以上のデータ・オブジェクトのデータ保存ポリシーと関連する１つ以上のデータ管理ルールを定義し、１つ以上のデータ管理ルールの各々が、１つ以上のデータ・オブジェクトに関連するアプリケーション・プログラム・システムと、１つ以上のデータ・オブジェクトを識別するパラメータと、１つ以上のデータ・オブジェクトのアーカイブ管理を実行するソフトウェア・モジュールとを指定するステップを含む。この方法は、イベントが生じるとソフトウェア・モジュールを実行し、イベントが、アーカイブ管理をパラメータと、指定したアプリケーション・システムとに基づいて制御するために１つ以上のデータ管理ルールの少なくとも１つを識別し、指定したアプリケーション・システムが、１つ以上のデータ管理ルールによって識別された１つ以上のデータ・オブジェクトに対してアーカイブ管理動作を実行するステップを更に含む。
【０００７】
一実施形態では、この方法は、データ保存ポリシーと関連する１つ以上のデータ管理ルール・タイプを定義するステップを含み、１つ以上のデータ管理ルールは各々データ管理ルール・タイプのインスタンスを定義し、１つ以上のデータ・ルール・タイプは、エンティティ・タイプのデータ保存ポリシーを記述する名前付きルール・タイプを指定し、１つ以上のデータ・ルール・タイプは、アーカイブ管理を制御するのに用いる以下の属性、すなわち、
ｉ）  アプリケーションＩＤ
ｉｉ）  アプリケーション・システムＩＤ
ｉｉｉ）  コーポレーションＩＤ
ｉｖ）  管理対象エンティティ名
ｖ）  制御エンティティ名
ｖｉ）  役割ＣＤ
ｖｉｉ）  制御日付カラムＩＤ、または、
ｖｉｉｉ）  データ保存ポリシーＩＤ
の１つ以上を有する。
【０００８】
一実施形態では、エンティティ・タイプは、一意的に識別される人、場所、事柄、概念またはイベントを定義し、名前属性及び記述属性の少なくとも１つを有し、エンティティ・タイプに対して完全なキーを構成する属性を定義する関連のエンティティ・キー属性を有する。
【０００９】
一実施形態では、この方法は、アーカイブ管理を制御するのに用いる以下の属性、すなわち、
ｉ）  インストール済みアプリケーションＩＤ
ｉｉ）  エンティティ・キー
ｉｉｉ）  アクション前の時間
ｉｖ）  測定の時間単位
ｖ）  コミット数
ｖｉ）  最大反復
ｖｉｉ）  データ保存タイプ、または、
ｖｉｉｉ）  イベント名
の１つ以上を定義し、１つ以上のデータ管理ルールと関連付ける。
【００１０】
一例として、１つ以上のデータ管理ルールを、インストール済みアプリケーションＩＤと、ビジネス機能コード、アプリケーション・システムＩＤ及びインストール済みアプリケーション記述の少なくともいずれか１つとを有するインストール済みアプリケーション・エンティティに関連付けることができる。
【００１１】
一実施形態では、この方法は、１つ以上のデータ・オブジェクトを識別し、エンティティ名及びエンティティ記述を含む属性を有する１つ以上のエンティティ・タイプと、エンティティ・キー属性とを定義するステップを含む。
【００１２】
エンティティ・キー属性は、エンティティ名、エンティティ・キー・シーケンス及びキー属性名を含む属性を有することができる。
【００１３】
一実施形態では、１つ以上のエンティティ・タイプの１つのインスタンスを生成することによって呼び出されるときに固有の識別子を構成する連続するアルゴリズム・セットを各々定義する１つ以上のエンティティ・ビルダを定義することができる。
【００１４】
一実施形態では、１つ以上のコンピュータ・ジョブ・エンティティを含む１つ以上の属性を有する作業単位エンティティを定義する。
【００１５】
一実施形態では、この方法は、エンティティ・キーによって識別された１つ以上のデータ・オブジェクトの少なくとも１つのアーカイブ管理を制御するため、インストール済みアプリケーションＩＤ、データ管理ルール名、エンティティ・キー、作業単位開始日付、作業単位終了日付及び作業単位状態の少なくともいずれか１つを含む作業単位エンティティの１つ以上の属性を定義するステップを含む。
【００１６】
一実施形態では、この方法は、１つ以上のデータ管理ログ・エンティティを、実行されるとアーカイブ管理の活動をロギングする１つ以上のコンピュータ・ジョブ・エンティティと関連付けるステップを含み、１つ以上のデータ管理ログ・エンティティは、インストール済みアプリケーションＩＤ、データ管理ルール名、エンティティ・キー、作業単位開始日付、作業単位終了日付、ジョブ番号、ログ・タイムスタンプ、活動状態、ログ済みメッセージ及び取引数の少なくともいずれか１つを含む属性を有する。
【００１７】
一実施形態では、実行するステップを開始するため、イベントが定期的に生じ、イベント名を１つ以上のデータ管理ルールに供給する。
【００１８】
本発明の別の側面では、データ管理を制御する方法を提供する。この方法は、コントローラのインスタンスを生成し、イベント名をコントローラに供給するステップと、イベント名と関連するルールにアクセスするステップとを含む。この方法は、ルールと関連するルール・タイプと関連する制御データを獲得するステップと、少なくとも作業単位定義を含む制御データによって定義された１つ以上のデータ・オブジェクトについてアーカイブ機能を実行するプログラムを実行するステップとを更に含む。
【００１９】
一実施形態では、作業単位定義は、開始日付及び終了日付のパラメータを含む。
【００２０】
一実施形態では、制御データは、アプリケーション・システム、１つ以上のデータ・オブジェクトと関連するエンティティ名、制御エンティティ名及び最大反復の少なくともいずれか１つを定義する。
【００２１】
一実施形態では、アーカイブ機能は、データの削除、データのパージ、及び、ストレージ用の１つのシステムから別のシステムへのデータの移動の少なくともいずれか１つを含む。
【００２２】
本発明の別の側面では、データを管理するシステムを提供する。このシステムは、コントローラのインスタンスを生成し、イベント名をコントローラに供給する手段と、イベント名によって識別されたルール・タイプと関連する制御データを獲得する手段とを含む。このシステムは、少なくとも作業単位定義を含む制御データによって定義された１つ以上のデータ・オブジェクトについてアーカイブ機能を実行するプログラムを実行する手段を更に含む。
【００２３】
一実施形態では、作業単位定義は、開始日付及び終了日付のパラメータを含む。
【００２４】
一実施形態では、制御データは、アプリケーション・システム、１つ以上のデータ・オブジェクトと関連するエンティティ名、制御エンティティ名及び最大反復の少なくともいずれか１つを定義する。
【００２５】
一実施形態では、アーカイブ機能は、データの削除、データのパージ、及び、ストレージ用の１つのシステムから別のシステムへのデータの移動の少なくともいずれか１つを含む。
【００２６】
一実施形態では、このシステムは、アーカイブ機能を制御するのに用いる以下の属性、すなわち、
ｉ）  インストール済みアプリケーションＩＤ
ｉｉ）  エンティティ・キー
ｉｉｉ）  アクション前の時間
ｉｖ）  測定の時間単位
ｖ）  コミット数
ｖｉ）  最大反復
ｖｉｉ）  データ保存タイプ、及び、
ｖｉｉｉ）  イベント名
の１つ以上を有するルール・タイプのインスタンスを生成し供給する手段を含む。
【００２７】
一実施形態では、ルール・タイプは、インストール済みアプリケーションＩＤと、ビジネス機能コード、アプリケーション・システムＩＤ及びインストール済みアプリケーション記述の少なくともいずれか１つとを含む属性を有するインストール済みアプリケーション・エンティティに関連する。
【００２８】
一実施形態では、作業単位定義のインスタンスは生成され、作業単位定義は、ルール・タイプと関連する１つ以上のオブジェクトを識別するために制御パラメータをプログラムに供給する。
【００２９】
一実施形態では、このシステムは、イベント名によって開始されたプログラムの実行と関連する情報をロギングする手段を含む。
【００３０】
本発明の別の側面では、コンピュータ使用可能媒体を含むコンピュータ・プログラム製品であって、媒体内には、可読プログラム・コードが統合されているコンピュータ・プログラム製品を提供し、このコンピュータ・プログラム製品は、１つ以上のデータ・オブジェクトのデータ保存ポリシーと関連する１つ以上のデータ管理ルールを定義し、１つ以上のデータ管理ルールの各々が、複数のデータ・オブジェクトに関連するアプリケーション・プログラム・システムと、１つ以上のデータ・オブジェクトを識別するパラメータと、１つ以上のデータ・オブジェクトのアーカイブ管理を実行するソフトウェア・モジュールとを指定する少なくとも１つの構成要素を含む。少なくとも１つの構成要素は、イベントが生じるとソフトウェア・モジュールを実行し、イベントが、アーカイブ管理をパラメータと、指定したアプリケーション・システムとに基づいて制御するために１つ以上のデータ管理ルールの少なくとも１つを識別するようにも構成されている。
【００３１】
添付図面を参照して例示の目的のみで本発明の好適な実施形態を次に説明する。
【発明を実施するための最良の形態】
【００３２】
好適な実施形態によれば、本発明は、概して、アーカイブ・ルール基準の高度に構成可能なアーティキュレーションを行うシステム及び方法であって、アーティキュレートされたアーカイブ・ルール基準を用いて特定のデータを管理するプログラムを実行する一貫した処理のためのシステム及び方法に関する。コンピュータ媒体に格納されたデータは、ほとんどの場合、保存期間周期を有し、典型的に、無期限に格納されるものと期待されていない。この保存期間は、組織のデータ保存ポリシー・ステートメントまたは計画によって記述されることが多く、アプリケーション・システムによって様々な方法で典型的に実装される。好適な実施形態によれば、開示されたシステム及び方法は、少なくとも、
−  組織の保存ポリシーを獲得することと、
−  これらポリシーをどのように特定タイプのデータに適用することができるかを定義することと、
−  定義したデータ・セットに対して特定の保存ルールを定義することと、
−  これらルールを様々なアプリケーション・システムにおいて管理することと
を達成する一貫した処理を提供する。
【００３３】
データ管理に対して責務を有する組織によって実装された後、継続している一貫した高信頼性のアーカイブ結果を実現することができ、広範囲のデータ・タイプ及びシステム環境に対処するように柔軟に構成可能である。このことは、１つ以上のポリシー設定組織によって必要とされるポリシーまたは契約によって定義されたアーカイブ目標が満足される高度の信頼性を可能にする。
【００３４】
図１〜４は、本発明の好適な実施形態によって提供、管理または使用される様々なタイプのエンティティ（データ）を示し、符号１００で広く示された論理ブロック図である。図１は上位の様々なエンティティを示すのに対して、図２〜４は、エンティティ及び関連の属性の更なる詳細を提供する。３つの一般的な分類、すなわち、データのポリシー及びルール・タイプ１０５、特定ルール１１５及び実行管理１２５に組織化されたデータ管理の論理エンティティを示す。これらエンティティを定義しインスタンスを生成してデータ管理処理を達成することができる。あるいはまた、図１〜４を、図示の様々なエンティティを定義し、または生成し、あるいはその両方を行うステップとすることもできる。
【００３５】
データ保存ポリシー１０８は、異なる組織ごとに保存ポリシーを必要とすることができる組織の保存ポリシーを記述する。例えば、組織「Ａ」は、短期、中期及び長期ストレージを必要とするとデータを定義することができるのに対して、組織「Ｂ」は、処分可能及び不可欠であるとデータを定義することができる。これら定義は通常、関連または特定あるいはその両方の「年齢」を含む。例えば、「短期」を、「このデータを６ヶ月間格納する」と定義することができるのに対して、「不可欠なデータ」を、「７年間格納すべきである」と定義することができる。
【００３６】
データ管理ルール・タイプ・エンティティ１１０Ａ〜１１０Ｆは全体として、データ保存ポリシー１０８を、アプリケーション・システム内で検出された特定のエンティティと関連付けるデータである。一例として、データ管理ルール・タイプ１１０Ａを、「ウェブ支払い要求」（ＷＰＲ）と称されるアプリケーション・システム１１０Ｃによって管理することができる「サプライヤ入力のインボイス」とすることができる。このルール・タイプは「サプライヤ・インボイス」エンティティ・タイプ１１０Ｂの管理を記述し、これらインボイスは、エンティティ・キー属性１１０Ｄ、例えば、「インボイスＩＤ」によって識別される。このルール・タイプは、エンティティ・タイプ１１０Ｂ、すなわち、特定のデータ管理ルールを記述する際に別の粒度レベルを定義することに用いられる「制御エンティティ」をも定義する。様々な論理構成要素及び関連の属性を以下に更に記述する。
【００３７】
エンティティ・タイプ１１０Ｂ
このエンティティは、ビジネス活動をサポートするためにビジネス組織が情報を必要とする人、場所、事柄、概念またはイベントを定義する。このエンティティを、エンティティ・タイプ１１０Ｂの属性であって、例えば、ＥＭＰＬＯＹＥＥ、ＷＯＲＫ  ＬＯＣＡＴＩＯＮ、ＩＴＥＭ、ＰＵＲＣＨＡＳＥ  ＯＲＤＥＲまたはＰＲＯＣＥＳＳ  ＨＩＳＴＯＲＹのような、エンティティのタイプに与えられた固有の名前を定義するエンティティ・タイプ名によって一意的に識別することができる。
【００３８】
エンティティ・キー属性１１０Ｄ
このエンティティは、エンティティ・タイプに対して、完全なキーまたは固有の識別子を構成する属性を定義する。この情報によって、システムは、構成に基づいてエンティティ識別子の種類を自動的に構成することができ、この情報は、以下の属性を有することができる。
【００３９】
エンティティ・タイプ名
この属性は、宣言された属性を識別するエンティティ・タイプの名前を定義する。
【００４０】
エンティティ・キー・シーケンス番号
この属性は、エンティティ・タイプのインスタンスを一意的に識別するため、キー属性タイプが用いられることになっている順序を定義する。
【００４１】
キー属性タイプ名
この属性は、エンティティ・タイプの固有の識別子を構成する属性タイプに与えられた名前を定義する。システムは、このデータを用いて、エンティティの識別子のインスタンスを動的に獲得するためにオブジェクトと通信する。これら属性の例として以下の例が挙げられる。
【００４２】
エンティティ・タイプ「ＥＭＰＬＯＹＥＥ」（エンティティ・タイプ名）を、属性タイプ「ＨＲ  ＳＹＳＴＥＭ  ＩＤ」及び「ＥＭＰＬＯＹＥＥ  ＩＤ」の順序でこれらによって一意的に識別することができ、これらは、それぞれ１及び２のエンティティ・キー・シーケンス番号を有するキー属性タイプ名である。
【００４３】
エンティティ・タイプ「ＣＯＭＰＡＮＹ」を、属性タイプ「ＣＯＵＮＴＲＹ  ＣＤ」及び「ＣＯＭＰＡＮＹ  ＣＤ」の順序でこれらによって一意的に識別することができる。
【００４４】
エンティティ・タイプ「ＣＯＭＰＡＮＹ  ＣＯＭＭＯＤＩＴＹ」を、属性タイプ「ＣＯＵＮＴＲＹ  ＣＤ」、「ＣＯＭＰＡＮＹ  ＣＤ」及び「ＣＯＭＭ  ＣＤ」の順序でこれらによって一意的に識別することができる。
【００４５】
エンティティ・ビルダ１１０Ｅ
このエンティティは、エンティティ・タイプのインスタンスを生成する際、固有の識別子を正確かつ完全に構成するために呼び出すことができる連続するアルゴリズム・セットを定義することができる。これらアルゴリズムは、固有キーを構成するのに用いられるデータを既存のソースから取り出し、これによって、参照整合性のフォームを実装する。参照整合性は、エンティティ間の関係が完全かつ正確であることを確実にする。例えば、ＣＯＭＰＡＮＹは、親エンティティに存在するＣＯＲＰＯＲＡＴＩＯＮを意味する場合に限り、関係「ＣＯＭＰＡＮＹは、１つのＣＯＲＰＯＲＡＴＩＯＮにのみ属する」は、「良好な整合性」を有する。
【００４６】
データ管理ルール・タイプ１１０Ａ
このエンティティは、単一タイプのエンティティに対して、コーポレーションのデータ保存ポリシーを記述する名前付きルール・タイプを定義する。このルール・タイプは、同じエンティティ・タイプに対して特定ルールの確立を管理し、以下の属性の１つ以上を有することができる。
【００４７】
データ管理ルール名
この属性は、ルール・タイプを一意的に識別するのに用いられる名前を定義する。
【００４８】
アプリケーションＩＤ
この属性は、ビジネス・データ・セットを削除、移動または要約するような実際のデータ管理アクションを自動化する任意のプログラミング言語で書かれたアプリケーション・プログラムを一意的に識別する名前を定義する。データ管理ルール・タイプは、このプログラムによって実装される。
【００４９】
アプリケーション・システムＩＤ
この属性は、管理すべきビジネス・データについて動作し、これを格納するアプリケーション・システムのタイプの名前を定義する。このタイプのアプリケーション・システムのインスタンスは２つ以上存在しうる。例えば、ＣＡＡＰＳは、ラテンアメリカ、ヨーロッパ及びアジア太平洋で１つずつ実行する３つのインスタンスを有する調達システムに与えられた名前である。各インスタンスは、同じフォーマットで、かつ同じ種類のビジネス・データについて動作し、これを格納する。アプリケーション・システムＩＤを有するこのアプリケーション・システムに対してデータ管理ルール・タイプが確立される。
【００５０】
コーポレーションＩＤ
この属性は、幾つかの小規模な法律上のエンティティ（すなわち、カンパニー）から成ることができる法律上のビジネス・エンティティの名前を定義する。データ管理ルール・タイプは、このコーポレーションによって定義される。
【００５１】
管理対象エンティティ・タイプ名
この属性は、このデータ管理ルール・タイプによってビジネス・データが管理されていることを定義する。例えば、エンティティ・タイプ「ＦＩＮＡＮＣＩＡＬ  ＩＮＶＯＩＣＥ  ＰＯＳＴＩＮＧ」を、所定のルール・タイプの対象とすることができる。
【００５２】
制御エンティティ・タイプ名
この属性は、ビジネス・データをセグメント化し、もっと具体的なポリシー要件を適用できるようにエンティティ・タイプが用いられることを定義する。例えば、フランスのビジネス・データ・ポリシーは、アメリカ合衆国（すなわち、エンティティ・タイプ「ＣＯＵＮＴＲＹ」）のビジネス・データ・ポリシーと異なることができる。この属性を、ルールに選択することができるエンティティを管理するため特定のデータ管理ルールを構成する際に用いることができる。
【００５３】
制御カラム名
この属性は、幾つかのアクション（例えば、削除、要約など）に対する適格性を決定するのに用いられるように（管理対象エンティティ・タイプ名によって名付けられた）ビジネス・データ内に存在する日付またはタイムスタンプ・データの名前を定義する。
【００５４】
役割ＣＤ
この属性は、ルール・タイプに対して生成された特定ルールの構成を変更するために人に割り当てなければならない役割を定義する。
【００５５】
アプリケーション・システム１１０Ｃ
このエンティティは、カンパニー・ポリシーに従って管理すべきデータを「所有する」アプリケーション・システムのタイプを定義する。
【００５６】
パラメータ・タイプ１１０Ｆ
このエンティティは、必要ならば、「アーカイバ」（アーカイブ機能を実行するプログラム）アプリケーションが、データ管理アクションに対してビジネス文書（例えば、取引）の適格性を確立するために必要とするパラメータのタイプを定義する。
【００５７】
図１〜４に関して、更に、特定ルール１１５は、制御エンティティに対する特定のデータ管理ルールを全体として記述する構成要素である。例えば、「ビジネス単位」（例えば、「カンパニーＡ一般調達」または「カンパニーＢパーソナル・システム部門」）を、制御エンティティの一例とすることができる。制御エンティティを、「北アメリカ」（地理的領域）のような上位にすることができ、または、エンタープライズ・リソース・プランニング（ＥＲＰ）システムの特定のインストールとすることができる「ＣＡＡＰＳ６３１０３」のような全く異なるエンティティとすることができる。特定ルール１１５の構成要素は以下のエンティティを含むことができる。
【００５８】
イベント１２０Ａ
このエンティティは、時間起動イベントまたは別のコンピュータ・ジョブの完了のような名前付きイベントを定義する。
【００５９】
データ管理ルール１２０Ｂ
このエンティティは、アーカイブまたはパージなどされる適格なビジネス文書を識別する実行中に用いられるデータ管理ルール・タイプ１１０Ａのインスタンスを定義する。このエンティティは、ファミリーであるデータを収容する特定のアプリケーション・インスタンス、アクションがとられる前に、含まれるビジネス文書の日付またはタイムスタンプに関連する経過しなければならない日数（または、その他の時間期間）、この「アクション前の時間」属性の測定単位、作業単位内（すなわち、アクションがデータベースにコミットされる前）で処理すべき文書の最大数、または、適格な文書をルールの単一実行中にシークすることができる回数の最大数のような制御属性を含む。
【００６０】
インストール済みアプリケーション１２０Ｃ
このエンティティは、管理されるデータを「所有する」アプリケーション・システムの特定のインスタンスを定義する。例えば、インストール済みアプリケーションＩＢＭＳＡＰＧＰ０及びＩＢＭＳＡＰＧＰ１は、アプリケーション・システム（タイプ）「ＳＡＰ」の２つのインスタンスである。
【００６１】
パラメータ１２０Ｄ
このエンティティは、データ管理に関してビジネス文書の適格性を決定するために「アーカイバ」によって用いられるデータの特定のタグ付き部分を定義する。
【００６２】
図１〜４に関して、更に、実行管理１２５は全体として、定義済みルールの管理を可能にするデータである。これによって、中央制御構成要素は、特定の作業単位の状態及び完全性を追跡することができる。実行管理１２５の構成要素を以下で更に詳細に説明する。
【００６３】
作用単位１３０Ａ
このエンティティは、データ管理アクションに対して適格であるビジネス文書セットを定義する。この文書セットを、特に文書の年齢によって識別することができる。
【００６４】
コンピュータ・ジョブ１３０Ｂ
このエンティティは、プログラムまたはプログラム群の識別可能な単一実行を定義する。
【００６５】
データ管理ログ１３０Ｃ
このエンティティは、ロギングまたは監査目的のデータベースを定義する。
【００６６】
図５は、符号２００で広く示された本発明の一実施形態の機能ブロック図である。この実施形態は、データ管理コントローラ（ＤＭＣ）２０５、１つ以上の「ブラック・ボックス」プログラム２１０Ａ〜２１０Ｃ（その中には、これらプログラムの複数の反復１〜Ｎがある）、及び、場合によって特定のシステム例えば「システムＡ」と関連するアーカイブ処理を必要とするデータ（例えば、インボイス・データ、金融データ、企業データ、レジューム・データなどのいずれか１つまたは任意の組み合わせ）を有するデータベース２１５を含む。構成及びロギング用のデータベース２２０、及び、別の特定のシステム例えば「システムＢ」と関連付けることができるアーカイブを必要とするその他のデータを有するデータベース２２５も含まれる。
【００６７】
ＤＭＣ２０５は、
ｉ）  処理を起動した名前付きイベントと関連する特定のデータ管理ルールを検出することと、
ｉｉ）  「作業単位」を決定することと（「ＵＯＷ（作業単位）幅」は、処理すべきデータの開始日付と終了日付との範囲の年齢である）、
ｉｉｉ）  「アーカイバ」プログラムを呼び出し、この時点で作用すべき取引または「オブジェクト」の最大数（作業量）、ＵＯＷ日付、及び、処理すべきデータを更に限定する任意のパラメータを受け渡すことと、
ｉｖ）  定義された反復回数に従って作業量が最大数を超えた場合、「アーカイバ」プログラムを再び呼び出すことと、
ｖ）  各ＵＯＷの状態を追跡することと、
ｖｉ）  「コンピュータ・ジョブ」に関する一般統計（例えば、所要時間、実行履歴）をロギングすることと、
を含む１つ以上の活動に対して責務を有する。
【００６８】
引き続き図２に関して、機能構成要素２３０Ａ〜２３０Ｃは、様々なソフトウェア・ルーチンによって達成することができるＤＭＣ２０５が実行する前述の機能ステップ及びその他の機能ステップを示す。例えば、機能ブロック２３０Ａは、ＤＭＣが１つ以上のプログラム（例えば、２１５、２２０または２２５）、システム（例えば、システムＡ）、制御エンティティ、及び、管理されるデータを定義または識別あるいはその両方を行うことを示す。機能ブロック２３０Ｂは、特定の制御エンティティに対して、ＤＭＣ２０５が作業単位（ＵＯＷ）幅、作業量、反復回数、及び、アーカイブ処理を起動するイベントを識別または定義することを示す。機能ブロック２３０Ｃは、（イベント２３５のような）特定のイベントによって起動される適切な「アーカイバ」プログラム（例えば、２１０Ａ〜２１０Ｃ）を呼び出すことと、ＵＯＷ状態を追跡することと、一般統計をロギングすることとを含む、ＤＭＣ２０５によってとることができる例示的なアクションを示す。イベント２３５は、例えば月に２度のような予め決定された頻度で生じることができる。
【００６９】
この実施形態２００は、例えば、データベース２１５に常駐することができるインボイス・データのような、プログラムＡと関連するデータのアーカイブ処理に「アーカイバ」プログラムＡ  ２１０Ａを用いることができることも示す。プログラムＢ  ２１０Ｂは、一例としてレジューム・データとすることができ、この場合もデータベース２１５に常駐することができる関連のデータを処理することを例示的に示す。しかし、一実施形態では、プログラムＢ  ２１０Ｂは、データベース２２０に活動を直接にロギングすることもできる。その他の実施形態では、ＤＭＣ２０５は、符号２１７によって示されるように「アーカイバ」プログラムの代わりにロギング機能を実行することができる。例えば、プログラムＣ  ２１０Ｃは、符号２２５によって示されるようにシステムＢと関連するデータを処理することができ、符号２１７によって示されるようにデータベース２２０の代わりにログオンすることをＤＭＣ２０５に任せる。
【００７０】
一般に、「アーカイバ」プログラムは、以下の責務を有する。例えば、
ｉ）  ＵＯＷ日付、パラメータとして受け渡された基準、及び、受け渡される作業量（例えば、取引数）への制限に基づいてプログラムが書かれたデータに作用する。
ｉｉ）  監査目的のビジネス制御数（例えば、データ管理ログ）をロギングする。
【００７１】
しかし、当然のことながら、「アーカイバ」プログラムは、追加の責務を含むことができる。
【００７２】
システムの活動を調整するため、データ管理アーキテクチャの共通のアーカイブ・フレームワーク及び実装（アーキテクチャの一例のプロトタイプは表１、２及び３を参照して以下に提示する）は典型的に以下の基本ルールを含む。すなわち、
ｉ）  「アーカイバ」アプリケーションは、（以下に示すように）アーカイバ・インターフェースを実装する必要がある。このインターフェースで定義される典型的に１つのメソッドは、ルールが呼び出される際にＤＭＣによって呼び出される。
ｉｉ）  「アーカイバ」アプリケーションは、（以下で定義する）ＲｅｓｕｌｔＤａｔａクラスのインスタンスを介してコントローラに返信する。
ｉｉｉ）  「アーカイバ」アプリケーションは、（以下で定義する）パラメータ・インターフェースを実装することによって構成情報を獲得することができる。
ｉｖ）  すべての「アーカイバ」アプリケーションは、ａｒｃｈｉｖｅｒｓ．ｘｍｌファイルを介してコントローラで登録する必要がある。エントリは「アーカイバ」アプリケーションごとに存在する。また、このファイルは、パラメータ・インターフェースの任意の実装のクラス名をコントローラに提供する。
ｖ）  コントローラは、前の作業単位（以後、ＵＯＷと称する）が未完了であるかどうかを（ルールごとに）検査する。未完了のＵＯＷが存在する場合、このＵＯＷに、完了したとマークすることができ、新たなＵＯＷを前の実行と同じ日付範囲で生成することができる。
ｖｉ）  コントローラは、「アーカイバ」アプリケーションによって必要とされる任意の追加のデータを収集することができるようにａｒｃｈｉｖｅｒｓ．ｘｍｌファイルに定義されたパラメータ・インターフェースの実装を呼び出す。
ｖｉｉ）  コントローラは、アーカイブ動作を次に実行する関連の「アーカイバ」アプリケーションの「ｐｅｒｆｏｒｍＡｒｃｈｉｖａｌ」メソッドを呼び出す。
ｖｉｉｉ）  「アーカイバ」から返還されたＲｅｓｕｌｔＤａｔａオブジェクトを、状態について「アーカイバ」からクエリーすることができる。失敗状態が返信された場合、「アーカイバ」アプリケーションは、ルール表に構成された反復回数だけ呼び出される。
ｉｘ）  成功状態が獲得された場合、ＵＯＷに、完了したとマークすることができる。
【００７３】
アーカイバ・インターフェースの一例を表１に示す。このインターフェースを、すべての「アーカイバ」アプリケーションによって実装することができる。この例では、ＤＭＣは、「ｐｅｒｆｏｒｍＡｒｃｈｉｖａｌ」メソッドを介して制御を、処理される特定ルールを処理する「アーカイバ」アプリケーションに受け渡す。
【００７４】
【表１】
2008518295.tif 000003
【００７５】
表２は、「アーカイバ」アプリケーションとＤＭＣとの間でメッセージを送信するのに用いることができる「ＲｅｓｕｌｔＤａｔａ」クラスの一例である。
【００７６】
【表２】
2008518295.tif 000004
【００７７】
この例では、すべての「アーカイバ」プログラムは、このタイプのオブジェクトを返信し、プログラムがすべてのデータに対してアーカイブを首尾良く実行したかどうかを示す状態を最小限度に設定することができる。また、このクラスは、ロギング及びメッセージ送信を高めるために用いることができるタイプ「ＥｘｅｃｕｔｉｏｎＲｅｓｕｌｔ」のオブジェクトを返信する機能を提供することができる。複数の実施形態では、このオブジェクトを用いて、ロギングをＤＭＣ自体によって行うことができる。
【００７８】
表３は、構成を「アーカイバ」アプリケーションに受け渡すパラメータ・インターフェースの一例である。
【００７９】
【表３】
2008518295.tif 000005
【００８０】
この例示的なインターフェースを用いて構成を「アーカイバ」アプリケーションに受け渡すことができる。また、インストール済みアプリケーションＩＤ、エンティティ、コミット数及び関連日付を受け渡すことができるデフォルト実装が提供される。「アーカイバ」アプリケーションは、このインターフェースをも実装して、必要に応じて適切に変更されるその他の「構成」データをも受け渡すことができる。
【００８１】
図６は、本発明を用い、ステップ３００から開始するステップを示す本発明の一実施形態の流れ図である。図６〜９は、本発明のステップを実装する好適な実施形態の構成要素のブロック図を等しく示すことができる。図６〜９を、適切なハードウェアと組み合わせてコンピュータ・プログラム・コードに実装することができる。このコンピュータ・プログラム・コードを、読み取り専用メモリ（ＲＯＭ）またはランダム・アクセス・メモリ（ＲＡＭ）のような１つのメモリ・ストレージ装置またはメモリ・ストレージ装置の集合と同様に、ディスケット、ハード・ディスク、ＣＤ‐ＲＯＭ、ＤＶＤ‐ＲＯＭまたはテープのようなストレージ媒体に格納することができる。更に、コンピュータ・プログラム・コードを、インターネットまたはその他の何らかのタイプのネットワークを介してワークステーションに転送することができる。
【００８２】
引き続き図６に関して、ステップ３０５において、複数のデータ・オブジェクトに対して１つ以上のルールを定義することができる。ステップ３１０において、ルールごとに制御エンティティを指定することができる。ステップ３１５において、アプリケーションを指定し、各データ・オブジェクトと関連付けることができる。ステップ３２０において、アーカイブ、別のストレージ・システムへのデータ・オブジェクトの移動などの管理機能を実行するソフトウェア・モジュールを指定することができる。ステップ３２５において、作用されるべき適格性を有するデータ・オブジェクトを更に正確に識別するパラメータを指定することができる。例えば、金融文書は「パージされる準備ができている」ことを示す状態コードのリストを列挙することができる。
【００８３】
ステップ３３０において、例えば、保存期間、ストレージ・サイズまたはその他の処理限度のようにルールごとに１つまたは複数の基準を定義することができる。ステップ３３５において、ルールごとにイベントを指定することができる。ステップ３４０において、イベントが生じる際にアプリケーション（例えば、「アーカイバ」）を呼び出すことができる。ステップ３４５において、データの移動、データの削除、新たなストレージ装置へのデータの格納のいずれか１つまたは任意の組み合わせのようなアーカイブ管理機能をルールごとに実行し、ルール及びルール・タイプに対して定義されたパラメータを用いてエンティティを関連付けることができる。処理はステップ３５０において終了する。
【００８４】
図７〜９は、本発明を用い、ステップ４００から開始する例示的なステップを示す一実施形態の流れ図である。ステップ４０５において、コントローラがインスタンスを生成したかどうか検査を行う。コントローラがインスタンスを生成した場合、ステップ４１５において、アーカイブまたはデータ保存処理を開始するためのイベント名を有するコントローラにメッセージを供給する。処理はステップ４２０に続く。しかし、コントローラにインスタンスが生成されていない場合、ステップ４１０において、コントローラを開始し、アーカイブまたはデータ保存処理を開始するイベント名をコントローラに供給する。ステップ４２０において、名前付きイベントと関連するルールにアクセスする。ステップ４２５において、関連のルール・タイプ表からルールに対する制御を獲得する。
【００８５】
ステップ４３０において、前の作業単位（ＵＯＷ）がルールに対して完了したかどうか検査を行う。完了した場合、ステップ４６０において、新たなＵＯＷパラメータを、残りのデータに対して適切であるように計算することができる。ステップ４６５において、ルールと関連する適切な「アーカイバ」プログラムを、新たなパラメータを用いて開始する。しかし、ステップ４３０において、前のＵＯＷが完了していない場合、ステップ４３５において、ルールに対して適切な「アーカイバ」プログラムを、前のＵＯＷパラメータを用いて開始する。ステップ４４０において、「アーカイバ」からインターフェース・パラメータごとに実行結果をロギングするため、ログ・エントリを入力することができる。ステップ４４５において、最大量のデータまたはデータ行（すなわち、処理すべき最大数のビジネス文書）が処理されたかどうか検査を行う。処理された場合、ステップ４５０において、ＵＯＷに「完了」とマークし、処理はステップ４５５を続ける。処理されていない場合、処理はステップ４５５を続ける。
【００８６】
ステップ４５５において、現在の名前付きイベントに対して最大反復が行われたかどうか検査を行う。最大反復が行われていない場合、ステップ４６５において、この反復に対してパラメータ（例えば、ＵＯＷパラメータ、処理すべき最大文書など）を用いて「アーカイバ」プログラムを開始し、処理はステップ４４０を続ける。しかし、反復の最大数が達成された場合、ステップ４７０において、名前付きイベントに対するルールがこれ以上存在するかどうか検査を行う。ルールが存在する場合、処理は、ステップ４２５において新たなルールを用いて再開する。そうでなければ、名前付きイベントに対して更なるルールがない場合、処理はステップ４８０において終了する。
【００８７】
使用例
具体的な例として、以下の場合を仮定する。ＨＡＬＣＯは、世界中で３２の異なるカンパニーから成る。これらカンパニーの３つは、「ＣＡＡＰＳ」システムの２つのインスタンスを用いて、アメリカ合衆国及びドイツにおける買掛金取引を処理する（サプライヤ・インボイスを支払う）。これら２つのシステム「ＣＡＡＰＳＵＳ」及び「ＣＡＡＰＳＤＥ」は、支払いがクリアされた２０日後にプロダクション・システムからアーカイブ・データベースに移動された取引データを必要とする。アーカイブ・データベースは、「ＡＰＢＤＷ」データ・ウェアハウス・システムと称される。これら支払い文書を、アメリカ合衆国のカンパニーに対して支払いがアーカイブされた２年後に、かつ、ドイツのカンパニーに対しては３年後に「ＡＰＢＤＷ」システムから削除する必要がある。「クリアされた」という定義は、２国家間でわずかに異なることができる。この差は、文書上で検出される２つの交わる状態コード・セットとして表される。
【００８８】
企業に関わる役割のグローバル管理者はルール・タイプを以下のように確立することができる。すなわち、
ｉ）  論理エンティティＣＡＡＰＳ＿ＣＯＭＰＡＮＹは、システムに対して、Ｃｏｕｎｔｒｙ＿Ｃｏｄｅ及びＣｏｍｐａｎｙ＿Ｃｏｄｅの２つのパーティ・キーを有すると定義される。
ｉｉ）  ＡＰ．ＴＣＯＭＰＡＮＹ＿ＴＢＬ  ＤＢ２（登録商標）表を、カンパニーをインストール済みアプリケーション・システムと関連付けるシステム・インターフェース制御表と結合することによってＡＰ．ＴＣＯＭＰＡＮＹ＿ＴＢＬ  ＤＢ２（登録商標）表からＣｏｕｎｔｒｙ＿Ｃｏｄｅのサブセットを最初に識別するエンティティ「ビルド」ロジックが生成される。この関係は、「ＣＡＡＰＳ」インストールのみを含む。ビルド・ロジックの第２部分は、「ＣＡＡＰＳ」インストールを用いるカンパニーに、（エンド・ユーザによって典型的に与えられる）指定国家内のカンパニーのリストを提供する。
ａ．  第１ビルド・ロジックの結果は、関係データ・セットすなわち、
１．  ＵＳ‐アメリカ合衆国
２．  ＤＥ‐ドイツ
である。
ｂ．  第２ビルド・ロジックの結果は、セットすなわち、
１．  ＵＳ‐ＣＯ０１‐アメリカ合衆国商業部門
２．  ＤＥ‐ＣＯ０２‐ドイツ商業部門
３．  ＤＥ‐ＣＯ０３‐ドイツ住宅部門
である。
ｉｉｉ）  これら例示的な３カンパニーに対して、以下の事を示す２つのデータ管理ルール・タイプを生成することができる。すなわち、
ａ．  アーカイブ・アクションに対して、
１．  ルール・タイプ名（例えば、「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴＳ＿ＡＲＣＨＩＶＥ」）
２．  アーカイブを処理するプログラム（例えば、「ＣＰ１３４Ａ１００」）
３．  これは「ＣＡＡＰＳ」システム・ルールであるという事実
４．  このルールはＨＡＬＣＯコーポレーションのカンパニーに対するものであるという事実
５．  「ＰＡＹＭＥＮＴ」文書は管理されているという事実
６．  制御エンティティとしてのＣＡＡＰＳ＿ＣＯＭＰＡＮＹの使用
７．  管理者のルールは、実際のルール（例えば、国家管理）を生成し維持する必要がある。
ｂ．  削除アクションに対して、
１．  ルール・タイプ名（例えば、「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＰＵＲＧＥ」）
２．  パージを処理するプログラム（例えば、「ＰＡＹＰＵＲＧＥ」）
３．  これは「ＡＰＢＤＷ」システム・ルールであるという事実
４．  このルールはＨＡＬＣＯコーポレーションのカンパニーに対するものであるという事実
５．  「ＰＡＹＭＥＮＴ」文書は管理されているという事実
６．  制御エンティティとしてのＣＡＡＰＳ＿ＣＯＭＰＡＮＹの使用
７．  管理者のルールは、実際のルール（例えば、「国家管理」）を生成し維持する必要がある。「国家管理」のルールは、管理者が、認定された（複数の）国家内のこれらのカンパニーのみにルールを定義することができるということを暗に示す。
ｉｖ）  国家管理者が、「クリアされた」支払いを表す状態コードを記述することができるように単一パラメータ・タイプを定義することができる。「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ」ルール・タイプに対する支払い文書「ヘッダ」を収容するＤＢ２（登録商標）表「ＡＰ．ＴＰＡＹ＿ＨＤＲ」に対してパラメータ・タイプ「ＰＡＹ＿ＳＴ＿ＣＤ」は生成される。
【００８９】
次に、国家管理者は、国家管理者の制御範囲内でカンパニーに必要な数だけ特定ルールを生成することできる。例えば、管理者は、ルール・タイプに指定されたアプリケーション・システムに基づいてルールが生成されているインストール済みアプリケーション・システムを選択することができ、次に、ルールを適用する国家及びカンパニーを選択する（エンティティ・ビルド・ロジックは、有効な国家及びカンパニー・セットを動的に生成する）。「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ」及び「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴＳ＿ＰＵＲＧＥ」ルール・タイプに対して、３つのルールがある。
【００９０】
ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ
１．  アメリカ合衆国商業部門（ＵＳ‐ＣＯ０１）の「ＣＡＡＰＳＵＳ」システムに関する「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ」
ｉ）  アクション前の時間：２０
ｉｉ）  測定単位：日
ｉｉｉ）  コミット数：５０００（５０００文書ごとに、より多くの同時アクセスを可能にするためデータベースに作業をコミットする。プログラムが少数の適格な文書に遭遇する場合、コミットが実行され、作業単位が完了する。）
ｉｖ）  反復の最大数：４（アーカイブすべき５０００文書の４セットまで可能とする。）
ｖ）  データ保存タイプ：「不可欠」（このカンパニーはデータの２つの分類を可能にさせる。処分可能なデータよりも長い期間、不可欠なデータを保持する必要がある。このことは、典型的に文書のみである。）
ｖｉ）  イベント名：「２×／Ｍｏｎｔｈ」（この名前は、ルール及び関連のプログラムが月に２度ファイルされるということを暗に示す。特定のスケジュールを実装しこの名前を適切なときに受け渡すのはスケジューリング・ソフトウェア次第である。）
ｖｉｉ）  頻度ＳＱＬロジック：この例では、適用できない
２．  ドイツ商業部門（ＤＥ‐ＣＯ０２）の「ＣＡＡＰＳＵＳ」システムに関する「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ」
ｉ）  アクション前の時間：２０
ｉｉ）  測定単位：日
ｉｉｉ）  コミット数：２０００
ｉｖ）  反復の最大数：１０
ｖ）  データ保存タイプ：「不可欠」
ｖｉ）  イベント名：「Ｗｅｅｋｌｙ」
３．  ドイツ住宅部門（ＤＥ‐ＣＯ０３）の「ＣＡＡＰＳＵＳ」システムに関する「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ」
ｉ）  アクション前の時間：２０
ｉｉ）  測定単位：日
ｉｉｉ）  コミット数：１０００（このカンパニーは、少数の文書を有する。）
ｉｖ）  反復の最大数：５
ｖ）  データ保存タイプ：「不可欠」
ｖｉ）  イベント名：「Ｗｅｅｋｌｙ」
【００９１】
ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＰＵＲＧＥ
１．  アメリカ合衆国商業部門（ＵＳ‐ＣＯ０１）の「ＡＰＢＤＷ」システムに関する「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＰＵＲＧＥ」
ｉ）  アクション前の時間：２
ｉｉ）  測定単位：年
ｉｉｉ）  コミット数：１００００
ｉｖ）  反復の最大数：２０
ｖ）  データ保存タイプ：「不可欠」
ｖｉ）  イベント名：「Ｍｏｎｔｈｌｙ」
２．  ドイツ商業部門（ＤＥ‐ＣＯ０２）の「ＡＰＢＤＷ」システムに関する「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＰＵＲＧＥ」
ｉ）  アクション前の時間：２
ｉｉ）  測定単位：年
ｉｉｉ）  コミット数：１００００
ｉｖ）  反復の最大数：２０
ｖ）  データ保存タイプ：「不可欠」
ｖｉ）  イベント名：「Ｍｏｎｔｈｌｙ」
３．  ドイツ住宅部門（ＤＥ‐ＣＯ０３）の「ＡＰＢＤＷ」システムに関する「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＰＵＲＧＥ」
ｉ）  アクション前の時間：２
ｉｉ）  測定単位：年
ｉｉｉ）  コミット数：１００００
ｉｖ）  反復の最大数：２０
ｖ）  データ保存タイプ：「不可欠」
ｖｉ）  イベント名：「Ｍｏｎｔｈｌｙ」
【００９２】
更に、定義済みルールごとに、「クリアされた」支払いを区別するパラメータを、ルール・タイプに対して定義したＰＡＹ＿ＳＴ＿ＣＤについて生成することができる。「ＣＡＡＰＳ＿ＰＡＹＭＥＮＴ＿ＡＲＣＨＩＶＥ」アメリカ合衆国ルールに対してパラメータ・リストを「ＣＬ」及び「ＰＳ」とすることができ、ドイツに対してリストを「ＣＬ」、「ＢＬ」及び「ＡＣ」とすることができる。これら変数は、パージされる適格性を有するビジネス文書セット（例えば、支払い）を更に記述するために「アーカイバ」アーカイブ及びパージ・プログラムによって用いられる。パージすべき支払い文書のみが、「クリアされた」支払い文書である。状態コードのこのリストは、アーカイバ・プログラムに「クリアされた」定義を行う。
【００９３】
複数の実施形態に関して本発明を説明したが、当業者は、請求項の意図及び範囲内で変更を加えて本発明を実施することができることを認識するであろう。
【図面の簡単な説明】
【００９４】
【図１】本発明の好適な実施形態によって提供、管理または使用される様々なタイプのエンティティを示す論理ブロック図である。
【図２】本発明の好適な実施形態によって提供、管理または使用される様々なタイプのエンティティを示す論理ブロック図である。
【図３】本発明の好適な実施形態によって提供、管理または使用される様々なタイプのエンティティを示す論理ブロック図である。
【図４】本発明の好適な実施形態によって提供、管理または使用される様々なタイプのエンティティを示す論理ブロック図である。
【図５】本発明の一実施形態の機能ブロック図である。
【図６】本発明を用いるステップを示す本発明の一実施形態の流れ図である。
【図７】本発明を用いるステップを示す一実施形態の流れ図である。
【図８】本発明を用いるステップを示す一実施形態の流れ図である。
【図９】本発明を用いるステップを示す一実施形態の流れ図である。
【図１】
2008518295.tif 000006
【図２】
2008518295.tif 000007
【図３】
2008518295.tif 000008
【図４】
2008518295.tif 000009
【図５】
2008518295.tif 000010
【図６】
2008518295.tif 000011
【図７】
2008518295.tif 000012
【図８】
2008518295.tif 000013
【図９】
2008518295.tif 000014
【国際調査報告】
2008518295.tif 000015
2008518295.tif 000016
2008518295.tif 000017