JP2005527895A - ライフサイクル管理エンジン - Google Patents

Abstract

【課題】電子レコードを管理する満足な管理システムを提供すること。
【解決手段】レコード・マネージャが、ホスト・アプリケーション・プログラムによって管理されるレコードのライフ・サイクル・フェーズを管理する。レコード・マネージャは、ネットワークを介してホスト・アプリケーション・プログラムと通信し、レコード・マネージャには、ファイル・プラン・データベース、レコード管理エンジン、およびアプリケーション・プログラム・インターフェースが含まれる。ファイル・プラン・データベースには、少なくとも１つのファイル・プラン・オブジェクトが含まれ、各ファイル・プラン・オブジェクトは、ライフ・サイクル・ルールを有する。レコード管理エンジンに、ファイリング手段および判定手段が含まれる。ファイリング手段は、ネットワークを介して受け取るレコード・プロファイル・データに従って、ファイル・プラン・オブジェクトにレコード識別子をファイリングする。判定手段は、ライフ・サイクル・ルールから、レコードのライフ・サイクル・フェーズの変更を追跡する。アプリケーション・プログラム・インターフェースは、レコード管理エンジンと通信し、ライフ・サイクル・フェーズの変化の表示をネットワークを介してホスト・アプリケーション・プログラムに送るように構成される。

Description

本発明は、電子レコードを管理するシステムに関する。具体的に言うと、本発明は、電子レコードの保存および処分を管理するエンジンに関する。

通常のレコード管理システムは、それぞれがめいめいの電子レコードに関連する項目を有するデータベースからなる。通常、各項目に、関連レコードのタイトル、作成者、公開日、主題、状況、および位置を識別するフィールドが含まれる。さらに、各項目に、その後にレコードをストレージにアーカイブしなければならない時間期間およびその後にアーカイブされたレコードを破棄しなければならない時間期間を識別するレコード保存データ・フィールドも含めることができる。

通常、レコード管理システムは、紙または他の有形の文書のライブラリを管理するのに使用されてきた。しかし、ワード・プロセッシング文書、スプレッドシート文書、ドローイング文書、および電子メールなどの電子文書の急増に対して、保存および処分を含む電子レコードを管理するソフトウェア解決策を提供する試みが行われてきた。

たとえば、１９９３年に、ムトウ（米国特許第５３７９４２３号）に、コンピュータベースの情報ライフ・サイクル管理システムが記載されており、このシステムには、情報管理プログラム、そこからユーザが処理要求を発行できる端末、特定のライフ・サイクル状態を有する情報オブジェクトを保管するデータ処理ストレージ空間、および情報オブジェクトに関連する情報が保管される記憶装置が含まれる。保管される情報には、各情報オブジェクトの所有者、各情報オブジェクトの使用を許可されるユーザ、各情報オブジェクトの親子情報オブジェクト階層、および各情報オブジェクトのライフ・サイクル・データ（ライフ・サイクル状態、状態の間のオブジェクトの変換の条件またはタイミング、およびライフ・サイクル状態シーケンスなど）が含まれる。開示されたライフ・サイクル状態には、承認済み状態（オブジェクトの内容が、承認されているが、オブジェクト内容の使用が、まだ許可されていない）、オープン状態（オブジェクト内容の使用が許可される）、封印状態（所有者以外によるオブジェクト内容の使用が禁止される）、および打切り状態（オブジェクトが削除される）が含まれる。

端末からの、オブジェクトを定義する要求などの処理要求の受取時に、情報管理プログラムは、ユーザに、オブジェクト・リストを提示し、これによって、ユーザが、情報オブジェクト階層、ライフ・サイクル情報、ユーザ、およびそのアクセス特権などの、生成されるオブジェクトに関する情報を指定できるようになる。その後、情報管理プログラムが、アクセス要求または状態変換要求を受け取る場合に、情報管理プログラムは、動作が所有者／ユーザ情報およびライフ・サイクル情報に従うものである場合に、要求された動作を実行する。情報管理プログラムが、端末からの状態変換要求に応答して情報オブジェクトに関する状態変換を実行する場合に、情報管理プログラムは、オブジェクトの親子階層によって決定される、子情報オブジェクトまたは親情報オブジェクトに対する必要なライフ・サイクル変換のすべても実行し、各情報オブジェクトを、その新しいライフ・スタイル状態に関連する記憶空間に移動する。情報オブジェクトが、打切り状態に変換された場合には、情報管理プログラムは、その情報オブジェクトの削除も行う。

１９９５年に、ジョンソン（米国特許第５８１３００９号）は、着信電子レコードを処理するデータ・フィルタ、レコードを保管する１つまたは複数の永久記憶装置（たとえばＷＯＲＭプラッタ）、レコードに関連する情報を含むデータベース、およびレコード・マネージャ・インターフェースを含むコンピュータベースの情報位置管理システムを記載した。この特許権所有者は、レコードの階層ファイリング構造を記述し、これには、物理記憶位置を表す「キャビネット」、ファイルのタイプ（たとえば契約）を表す「ケース・タイプ」、親ケース・タイプの特定のインスタンスを表す「ケース」、「ケース」内の論理ファイリング・ユニットを表す「フォルダ」、および「フォルダ」内の個々の文書を著す「ドキュメント」が含まれる。

データ・フィルタは、スキャンされたイメージ、ワード・プロセッシング・ファイル、および音声データを含む、電子レコードを受け取るように構成される。電子レコードの受取時に、データ・フィルタは、レコード・ヘッダに適当なファイリング・データおよびインデックス・データ（たとえば、物理記憶位置、日付／時刻、保存データ）が含まれることを検証する。データ・フィルタは、データベースが記憶位置を追跡するのに使用するタグと、レコードに関連する保存データを付加する。受け取られたレコードは、自動的にまたはオペレータ介入を介してのいずれかで、レコードを「永久」記憶装置の１つに保管し、保存データおよびファイリング構造内のレコードの位置を用いてデータベースを更新することによって、「証明」される。レコードの永久ストレージからの後続の削除を容易にするために、類似する保存期間を有するレコードは、同一の物理記憶装置に保管される。

周期的に、レコード・マネージャが、インターフェースを使用して、照会日に先立つ破棄の日付を有するすべてのレコードのリストについてデータベースに照会する。レコード・マネージャは、リストされたレコードのすべてについて保存データを変更し、リストされたレコードのいずれかまたはすべてを永久ストレージから削除することができる。レコードのいずれかが、オフサイトで保管されている場合に、レコード・マネージャは、指定された電子レコードを削除することを要求するコマンドをオフサイト・ストレージに発行する。指定されたレコードが削除されたことの確認の受取時に、レコード・マネージャは、データベースを更新してその削除を反映する。

ムトウおよびジョンソンは、始めから削除までの電子レコードの管理に関する完全な解決策を記述しているが、レコードは、作成された環境の外にコピーされなければならない。ムトウは、このステップが、レコードの効率的なデータ処理をもたらすために必要であると開示しているが、ジョンソンは、このステップは、法廷がレコードを保管した個人の知識および技量を査定できるようにし、これによって、保管されたレコードの許容性に関するルールを査定できるようにするのに必要であると開示している。その結果、ムトウおよびジョンソンの両方が、保管されたレコードへの許可されないアクセスを防ぐために、アクセス・プロトコルおよび対応するユーザ・インターフェースを実施しなければならない。レコードを作成するのに使用されるソフトウェア環境は、通常は、それ自体のアクセス・プロトコルおよびそれ自体のユーザ・インターフェースを有するので、これらの解決策では、必要なコンピューティング・リソースが不必要に増加する。

さらに、ジョンソンは、情報管理プログラムによってレコードを使用について自動的に証明できると開示しているが、自動証明は、レコードが、適当なファイリング・データおよびインデックス・データを既に担持するデータ・フィルタに達することを必要とする。ジョンソンは、レコードが階層ファイリング構造に保管されると開示しているので、ユーザは、少なくとも必須のファイリング・データを供給するために、情報管理プログラムの動作に精通しなければならない。この要件は、特に複数のユーザ・インターフェースを習得するのを嫌がるユーザによる、情報管理プログラムの採用を妨げる。
米国特許第５３７９４２３号 米国特許第５８１３００９号

したがって、電子レコードを管理する満足な管理システムに関する長年の必要が残っている。

本発明の第１の態様によれば、（１）アプリケーション・プログラムによって管理されるレコードに一意に関連するレコード識別子をネットワークを介して受け取るステップであって、前記レコード管理エンジンが、前記レコードのライフ・サイクル状態を管理するように構成され、前記レコード識別子が、前記関連するレコードのプロファイル・データを含む、ステップと、（２）前記関連するプロファイル・データに従ってファイル・プランのファイル・プラン・ノードに前記受け取ったレコード識別子をファイリングするステップであって、各前記ファイル・プラン・ノードが、関連する保存ルールを有する、ステップと、（３）前記保存ルールから、前記管理されるレコードのライフ・サイクル状態を判定するステップと、（４）前記アプリケーション・プログラムが前記管理されるレコードを前記めいめいのライフ・サイクル状態に遷移させることを要求するライフ・サイクル命令を前記ネットワークを介して送るステップとを含む、電子レコードを管理する方法が提供される。

コンピュータにロードされた時に、コンピュータに上で示したステップのシーケンスを実行させる、コンピュータ用の処理命令を担持するコンピュータ可読媒体も提供される。

本発明の第２の態様によれば、アプリケーション・プログラムによって管理されるレコードのライフ・サイクル管理を容易にするコンピュータベースの電子レコード管理エンジンが提供される。レコード管理エンジンには、受取手段、ファイリング手段、判定手段、および提供手段が含まれる。受取手段は、アプリケーション・プログラムによって管理されるレコードに関連するレコード識別子を受け取るように構成され、レコード識別子には、関連するレコードのプロファイル・データが含まれる。ファイリング手段は、関連するプロファイル・データに従って、ファイル・プランのファイル・プラン・ノード内に、受け取ったレコード識別子をファイリングするように構成され、各ファイル・プラン・ノードは、関連するライフ・サイクル・ルールを有する。判定手段は、ライフ・サイクル・ルールから、管理されるレコードのライフ・サイクル状態を判定するように構成される。提供手段は、アプリケーション・プログラムが管理されるレコードをめいめいのライフ・サイクル状態に遷移させることを要求するライフ・サイクル命令を供給するように構成される。

コンピュータにロードされた時に、コンピュータ内で、前述の受取手段、ファイリング手段、判定手段、および提供手段を定義する、コンピュータ用の処理命令を担持するコンピュータ可読媒体も提供される。

本発明の第３の態様によれば、アプリケーション・プログラムによって管理されるレコードのライフ・サイクル・フェーズを管理するレコード・マネージャが提供される。レコード・マネージャは、ネットワークを介してホスト・アプリケーション・プログラムと通信し、レコード・マネージャには、ファイル・プラン・データベース、レコード管理エンジン、およびアプリケーション・プログラム・インターフェースが含まれる。ファイル・プラン・データベースには、少なくとも１つのファイル・プラン・ノードが含まれ、各ファイル・プラン・ノードは、ライフ・サイクル・ルールを有する。レコード管理エンジンには、ファイリング手段および判定手段が含まれる。ファイリング手段は、ネットワークを介して受け取るレコード・プロファイル・データに従って、ファイル・プラン・オブジェクト内にレコード識別子をファイリングする。判定手段は、ライフ・サイクル・ルールからレコードのライフ・サイクル・フェーズの変化を追跡するように構成される。アプリケーション・プログラム・インターフェースは、レコード管理エンジンと通信し、ライフ・サイクル・フェーズの変更の表示をネットワークを介してホスト・アプリケーション・プログラムに送信するように構成される。

本発明の第４の態様によれば、アプリケーション・プログラムによって管理されるレコードのライフ・サイクル管理を容易にする、コンピュータベースの電子レコード管理エンジンが提供される。レコード管理エンジンは、ネットワークを介してホスト・アプリケーション・プログラムと通信し、レコード管理エンジンには、データベース・インターフェース、データベース・インターフェースと通信するファイリング手段、データベース・インターフェースと通信する判定手段、ならびにファイリング手段および判定手段と通信するアプリケーション・プログラム・インターフェースが含まれる。データベース・インターフェースは、少なくとも１つのファイル・プラン・ノードを有するファイル・プラン・データベースにアクセスするのに使用され、各ファイル・プラン・ノードには、そのファイル・プラン・ノードに関連するオブジェクトのライフ・サイクル・フェーズ変化を決定するライフ・サイクル保存ルールが含まれる。ファイリング手段は、レコードのめいめいのプロファイルに従ってめいめいのファイル・プラン・ノード内にレコード識別子をファイリングし、プロファイルは、ネットワークを介して受け取られる。判定手段は、ライフ・サイクル・ルールから、レコードのライフ・サイクル・フェーズの変化を追跡する。アプリケーション・プログラム・インターフェースは、ライフ・サイクル・フェーズの変化の表示を、ネットワークを介してホスト・アプリケーション・プログラムに送信するように構成される。

コンピュータにロードされた時に、コンピュータ内で、前述のデータベース・インターフェース、ファイリング手段、判定手段、およびアプリケーション・プログラム・インターフェースを定義する、コンピュータ用の処理命令を担持するコンピュータ可読媒体も提供される。

本発明の第５の態様によれば、ホスト・アプリケーション・プログラムによって管理される電子レコードのライフ・サイクル・フェーズを管理する、コンピュータベースの管理エンジンが提供される。管理エンジンは、ネットワークを介してホスト・アプリケーション・プログラムと通信するように構成され、管理エンジンには、ファイル・プラン・データベースにアクセスするインターフェース、ファイリング手段、および判定手段が含まれ、ファイリング手段および判定手段の両方が、インターフェースと通信する。インターフェースは、少なくとも１つのファイル・プラン・ノードを有するファイル・プラン・データベースにアクセスするのに使用され、各ファイル・プラン・ノードには、そのファイル・プラン・ノードに関連するオブジェクトのライフ・サイクル・フェーズ変化を決定するライフ・サイクル保存ルールが含まれる。ファイリング手段は、ネットワークを介してアプリケーション・プログラムから受け取られるめいめいのレコード・プロファイルに従って、めいめいのファイル・プラン・ノードにレコード識別子をファイリングする。判定手段は、めいめいのライフ・サイクル・ルールによって、異なるライフ・サイクル・フェーズの間で、管理されるレコードを遷移させる。

コンピュータにロードされた時に、コンピュータ内で、前述のデータベース・インターフェース、ファイリング手段、判定手段、およびアプリケーション・プログラム・インターフェースを定義する、コンピュータ用の処理命令を担持するコンピュータ可読媒体も提供される。

本発明の第６の態様によれば、アプリケーション・プログラムによって管理されるレコードのライフ・サイクル管理を容易にする、コンピュータベースの電子レコード管理エンジンが提供される。レコード管理エンジンは、ネットワークを介してホスト・アプリケーション・プログラムと通信し、レコード管理エンジンには、データベース・インターフェース、データベース・インターフェースと通信する定義手段、データベース・インターフェースと通信するファイリング手段、データベースと通信する判定手段、ならびに、定義手段、ファイリング手段、および判定手段と通信するアプリケーション・プログラム・インターフェースが含まれる。データベース・インターフェースは、少なくとも１つのファイル・プラン・ノードを有するファイル・プラン・データベースにアクセスするのに使用され、各ファイル・プラン・ノードには、そのファイル・プラン・ノードに関連するオブジェクトのライフ・サイクル・フェーズ変化を決定するライフ・サイクル保存ルールが含まれる。定義手段には、親子ノード、ファイル・プラン・オブジェクト・クラス、少なくとも１つのファイル・プラン属性、およびライフ・サイクル保存ルールを含む、少なくとも１つのファイル・プラン・ノードを含むファイル・プランを定義する。ファイリング手段は、レコードのめいめいのプロファイルに従って、めいめいのファイル・プラン・ノードにレコード識別子をファイリングし、プロファイルは、ネットワークを介して受信される。判定手段は、ライフ・サイクル・ルールからレコードのライフ・サイクル・フェーズの変化を追跡する。アプリケーション・プログラム・インターフェースは、ライフ・サイクル・フェーズの変化の表示を、ネットワークを介してホスト・アプリケーション・プログラムに送信するように構成される。

コンピュータにロードされた時に、コンピュータ内で、前述のデータベース・インターフェース、ファイリング手段、判定手段、およびアプリケーション・プログラム・インターフェースを定義する、コンピュータ用の処理命令を担持するコンピュータ可読媒体も提供される。

本発明を、例示として、添付図面を参照してこれから説明する。

図１に移ると、全体的に１００で表される電子レコード管理システムが、少なくとも１つのコンピュータ端末１０２、ホスト・コンピュータ・サーバ１０４、ホスト・コンピュータ・サーバ１０４によって管理されるレコードのライフ・サイクルを管理するレコード管理サーバ２００、および通信ネットワーク１０８を含むものとして図示されている。通信ネットワーク１０８に、コンピュータ端末１０２とホスト・サーバ１０４の間、コンピュータ端末１０２とレコード管理サーバ２００の間、およびホスト・サーバ１０４とレコード管理サーバ２００の間の通信を容易にするネットワークが含まれることが好ましい。しかし、その代わりに、ホスト・サーバ１０４およびレコード管理サーバ２００の機能を、通信ネットワーク１０８と共に共通のコンピュータ・サーバ上で実施し、単にコンピュータ端末１０２とコンピュータ・サーバの間の通信を容易にすることができる。さらに、通信ネットワーク１０８を完全に省略することができ、コンピュータ端末１０２、ホスト・サーバ１０４、およびレコード管理サーバ２００の機能を、単一のコンピュータで実施することができる。

レコード管理システム１００には、レコード管理サーバ２００によってアクセス可能なファイル・プラン・データベース１１０も含まれる。通常、レコード管理サーバ２００は、通信ネットワーク１０８を介してファイル・プラン・データベース１１０にアクセスするが、安全性を強化するために、ファイル・プラン・データベース１１０を、レコード管理サーバ２００と同一のコンピュータ・サーバに設けることができる。

ホスト・サーバ１０４には、コンピュータ・レコードのセキュア・データベース１１２が含まれるが、レコード・データベース１１２を、ホスト・サーバ１０４によってアクセス可能な別々のセキュア・ファイル・サーバに設けることもできる。通常、コンピュータ・レコードには、ワード・プロセッシング文書、スプレッドシート文書、デスクトップ・パブリッシング文書、およびマルチメディア・ファイルが含まれるが、コンピュータ・レコードに、実行可能コンピュータ・コード、データベース、またはコンピュータ端末１０２によってアクセス可能な任意の電子データを含めることもできる。データベース１１２に、レコードごとに、タイトル、作成者、公開日、およびレコードの主題など、１つまたは複数のプロファイル・データ項目も含まれることが好ましい。

ホスト・サーバ１０４は、ホスト・サーバ・データベース１１２と通信するコンピュータ・アプリケーション・プログラム１１４と共に構成され、コンピュータ端末１０２のユーザに、ホスト・サーバ・データベース１１２のコンピュータ・レコードへのアクセスを提供する。拡張性のために、ホスト・アプリケーション・プログラム１１４が、ウェブベースまたはｎ層分散アプリケーションであり、各コンピュータ端末１０２は、ウェブ・ブラウザなど、コンピュータ端末１０２のユーザにホスト・サーバ１０４とのステートレス・インターフェースを提供するアプリケーション・ソフトウェアと共に構成されることが好ましい。

通常、ホスト・アプリケーション・プログラム１１４は、コンピュータ・レコードへの制御されたアクセスをコンピュータ端末ユーザに提供する、ユーザ・アカウント（ユーザ名およびパスワードを含む）およびグループ定義のデータベースを維持する。レコード管理サーバ２００は、ホスト・アプリケーション・プログラム１１４によって維持されるユーザおよびグループ・アカウント情報を使用して、コンピュータ端末１０２のユーザに、レコード管理サーバ２００への（ホスト・アプリケーション・プログラム１１４を介する）制御されたアクセスを提供する。しかし、１変形形態では、ホスト・アプリケーション・プログラム１１４が、個々のユーザ・アカウントまたはグループ・アカウントを維持せず、ホスト・アプリケーション・プログラム１１４は、「ゲスト」アカウントを介してレコード管理サーバ２００にアクセスし、この場合に、レコード管理サーバ２００は、ユーザごとの基礎でレコード管理サーバ２００への制限を課すことができない。

レコード管理サーバ２００が、ＣＯＭコンポーネントまたはシンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）コンポーネントを使用してホスト・アプリケーション・プログラム１１４と通信することが好ましい。その結果、ホスト・アプリケーション・プログラム１１４に、ＣＯＭオブジェクトまたはＳＯＡＰ準拠オブジェクトと対話できるインターフェース１１６が含まれることが好ましい。さらに、レコード管理サーバ２００が、Ｗｉｎｄｏｗｓ（Ｒ）２０００ベースのサーバであることが好ましく、この場合に、ホスト・アプリケーション・プログラム１１４が、Ｗｉｎｄｏｗｓ（Ｒ）２０００ Ｓｅｒｖｅｒ環境で動作可能でなければならない。

ホスト・アプリケーション・プログラム１１４は、下記の関数呼出しを実装する。

Ａｃｃｅｓｓｉｏｎ（同意）：
レコード管理サーバ２００は、ホスト・サーバ１０４によって管理されるレコードのライフ・サイクルが使い果たされた時に、この関数を呼び出し、この時が、永久的アーカイブのためにレコードを外部オーソリティに転送する時である。それに応答して、ホスト・アプリケーション・プログラム１１４は、関数呼出しで指定されたレコード管理サーバ転送ディレクトリにレコードをコピーする。転送ディレクトリでの衝突がないことを保証するために、ホスト・アプリケーション・プログラム１１４は、転送ディレクトリ内でレコードをＨｏｓｔＩｄ．ＨｏｓｔＲｅｃｏｒｄＩｄ．ｅｘｔという名前で保管する。ここで、ＨｏｓｔＩｄは、ホスト・アプリケーション・プログラム１１４の一意のＨｏｓｔＩＤ、ＨｏｓｔＲｅｃｏｒｄＩｄは、ホスト・サーバ１０４内の項目の一意のｉｄ、ｅｘｔは、ホスト・レコードのネイティブ拡張子（たとえば、ｄｏｃ、ｅｍｌ、ｘｍｌなど）である。

ホスト・レコードが、転送ディレクトリにコピーされた後に、ホスト・アプリケーション・プログラム１１４は、そのレコードをホスト・サーバ１０４から削除する。ホスト・アプリケーション・プログラム１１４は、レコード管理サーバ２００に、転送ディレクトリ内のレコードへの完全なパスと、ホスト・アプリケーション・プログラム１１４がホスト・サーバ・データベース１１２内のレコードに最初に関連付けたプロファイル・データ項目を指定するＸＭＬデータ構造を供給する。

Ｄｅｌｅｔｅ（削除）：
レコード管理サーバ２００は、レコード管理サーバ２００が、この関数呼出しで指定されるレコードのライフ・サイクル状態をもはや追跡しないことをホスト・アプリケーション・プログラム１１４に通知するためにこの関数を呼び出す。それに応答して、ホスト・アプリケーション・プログラム１１４が、そのレコードをホスト・サーバ・データベース１１２から削除することが好ましいが、ホスト・アプリケーション・プログラム１１４は、これを行わないことを選択することができる。

Ｄｅｓｔｒｏｙ（破棄）：
レコード管理サーバ２００は、ホスト・サーバ１０４によって管理されるレコードのライフ・サイクルが使い果たされた時に、この関数を呼び出し、この時が、ホスト・サーバ・データベース１１２からレコードを永久的に削除する時である。これに応答して、ホスト・アプリケーション・プログラム１１４が、レコードをホスト・サーバ１０４から削除することが好ましいが、ホスト・アプリケーション・プログラム１１４は、これを行わないことを選択することができる。ホスト・アプリケーション・プログラム１１４は、レコード管理サーバ２００に、ホスト・サーバ・データベース１１２内のレコードへの完全なパスと、ホスト・アプリケーション・プログラム１１４がホスト・サーバ・データベース１１２内のレコードに最初に関連付けたプロファイル・データ項目を指定するＸＭＬデータ構造を供給する。

ＧｒｏｕｐＬｉｓｔ（グループリスト）：
レコード管理サーバ２００は、ホスト・アプリケーション・プログラム１１４によって使用されるユーザ・グループのＸＭＬリストを入手するために、この関数を呼び出す。レコード管理サーバ２００は、この情報を使用して、レコード管理サーバ２００内のグループ・セキュリティ・アクセスを確立する。

ＵｓｅｒＬｉｓｔ（ユーザリスト）：
レコード管理サーバ２００は、ホスト・アプリケーション・プログラム１１４を使用することを許可されるユーザのＸＭＬリストを入手するために、この関数を呼び出す。レコード管理サーバ２００は、この情報を使用して、レコード管理サーバ２００内のユーザ・セキュリティ・アクセスを確立する。

ＴｒａｎｓｉｔｉｏｎＴｏＰｈａｓｅ（フェーズへの遷移）：
レコード管理サーバ２００は、この関数呼出しで指定されるレコードが、あるライフ・サイクル・フェーズから別のライフ・サイクル・フェーズに遷移したことをホスト・アプリケーション・プログラム１１４に通知するために、この関数を呼び出す。この関数では、任意選択として、ホスト・アプリケーション・プログラム１１４が、指定されたレコードをこの関数呼出しで指定されたディレクトリにコピーしなければならないことを指定することができる。

ＵｎＲｅｇｉｓｔｅｒ（登録解除）：
レコード管理サーバ２００は、ユーザがファイル・プランからファイル・プラン・オブジェクト１２２を削除する時にこの関数を呼び出し、ホスト・アプリケーション・プログラム１１４が、もはや、関連するレコードのライフ・サイクルがレコード管理サーバ２００によって管理されると見なしてはならないことを指定する。

図２を参照すると、ファイル・プラン・データベース１１０は、ＳＱＬデータベースとして実施され、ファイル・プラン・データベース１１０には、レコード管理システム１００のファイル・プランを定義するレコードが含まれる。ファイル・プランは、ノードの階層配置であり、これは、ホスト・アプリケーション・プログラム１１４によって管理される電子レコードを、所望の判断基準を反映する配置に分類するのに使用される。管理者は、ファイル・プラン・ノード１２０、親子ノード１２０、ファイル・プラン・オブジェクト・クラス、およびファイル・プラン属性１２４ごとに、ライフ・サイクル・コード１２６および中断状況１２８を指定することによって、ファイル・プランを作成または実施することができる。たとえば、ノードを、主題ベースの階層（たとえば、主題、作成者、タイトル）で編成するか、位置ベースの階層（たとえば、倉庫、通路、ファイリング・キャビネット）で編成して、対応する物理レコードの物理的位置を反映することができる。

ファイル・プラン・データベース１１０でのファイル・プランの定義には、４つのステップがある。すなわち、（１）ファイル・プランの「ビュー」の定義、（２）ファイル・プランを含むコンポーネントまたはファイル・プラン・オブジェクト１２２、（３）これらのコンポーネントの間の関係、および（４）関連するコンポーネントが相互作用する形を決定するルールである。

ファイル・プラン・ビューによって、情報が編成される形が記述される。これは、ファイル・プランを含むコンポーネントの間の関係の集合である。たとえば、ＵＳ Ａｒｍｙ Ｍａｒｋｓ（米国陸軍階級章）ファイル・プランが、４タイプのコンポーネントすなわち、Ｒｅｃｏｒｄ Ｓｅｒｉｅｓ（レコード・シリーズ）、Ｒｅｃｏｒｄ Ｃａｔｅｇｏｒｉｅｓ（レコード・カテゴリ）、Ｆｏｌｄｅｒｓ（フォルダ）、およびＲｅｃｏｒｄｓ（レコード）からなり、このそれぞれによって、連続して狭まる情報のクラスが定義される。レコード・シリーズで始まり、フォルダで終わる単一の階層スレッドがある。これと同一の情報を、代替の形またはビューで編成することができる。たとえば、これを、レコードの物理的位置すなわち、Ｂｕｉｌｄｉｎｇ（建物）、Ｆｌｏｏｒ（階）、Ａｉｓｌｅ（通路）、Ｓｈｅｌｆ（棚）、およびＦｏｌｄｅｒ（フォルダ）に従って編成することができる。上の２つの例のフォルダは、階層ファイル・プランに保管される、すなわち、ファイル・プラン・コンポーネントまたはファイル・プラン・オブジェクト１２２は、互いに親子関係で関係している。エンジンは、複数階層ビューおよび非階層ビューをサポートするが、このビューは、その中に含まれるファイル・プラン・コンポーネントに関してオーバーラップするものまたは別々のものとすることができる。

ファイル・プランのコンポーネントによって、そのファイル・プランに保管される情報のクラスが定義される。各ファイル・プランに、少なくとも１つのコンポーネントが含まれる。ファイル・プランの作成者が定義できるコンポーネントの数には、制限がない。ファイル・プランを含むコンポーネントによって、情報のクラスが定義される。ファイル・プラン内の各コンポーネントは、異なる名前、プロパティ、および挙動を有する。ユーザは、ファイル・プランを含むファイル・プラン・コンポーネント定義を指定することができる。ファイル・プラン・コンポーネント定義は、ファイル・プラン・コンポーネントの挙動を決定するプロパティの組を有する。これらのプロパティに、名前およびプライマリ・ビューが含まれる。名前は、特定のタイプのファイル・プラン・コンポーネントを異なるタイプのコンポーネントから区別する一意の識別子である。ファイル・プラン・コンポーネント定義名の例にＲｅｃｏｒｄ Ｓｅｒｉｅｓ、Ｒｅｃｏｒｄ Ｃａｔｅｇｏｒｉｅｓ、Ｆｏｌｄｅｒｓ、およびＲｅｃｏｒｄｓが含まれる。プライマリ・ビューは、すべてのファイル・プラン・コンポーネントがその中に存在しなければならないファイル・プラン・ビューである。

異なるタイプのファイル・プラン・コンポーネントは、ファイル・プラン・コンポーネントに関する追加情報を提供するのに使用されるファイル・プラン属性１２４の異なる組を有する。たとえば、ファイル・プランに、「Ｆｏｌｄｅｒ」と呼ばれるファイル・プラン・オブジェクト１２２が含まれる場合に、１つのプランに無制限の数のフォルダを設けることができるが、すべてのフォルダが、ファイル・プラン属性１２４の共通の組を共用する。各フォルダに保管される値は、異なるものとすることができるが、属性自体は、ファイル・プラン内のすべてのフォルダに存在する。ファイル・プラン・コンポーネント「ｆｏｌｄｅｒ」の属性に、フォルダの一意識別子、位置などを含めることができる。各ファイル・プラン属性定義は、その挙動を決定するプロパティの組を有する。たとえば、属性は、特定のデータ型（整数、実数、日付、通貨など）でなければならない。ユーザは、所与の属性定義に保管されるデータのサイズまたは量を制限することもできる。

異なるタイプのファイル・プラン・コンポーネントの間に存在することができる関係は、任意の２つのファイル・プラン・コンポーネントが互いに特定の形で関係できることの宣言である。関係定義は、３つのプロパティすなわち、関係の一端（ソース）でのファイル・プラン・コンポーネントまたはファイル・プラン・オブジェクト１２２のタイプ、関係の他端（ターゲット）でのファイル・プラン・コンポーネントまたはファイル・プラン・オブジェクト１２２のタイプ、および関係が属するファイル・プラン・ビューからなる。たとえば、ファイル・プランが階層式である場合に、ファイル・プラン・コンポーネントの間の関係を、親子として特性を表すことができる。

ファイル・プラン・データベース１１０の構造を、図２に示す。図からわかるように、ファイル・プラン・データベース１１０には、複数のファイル・プラン・レコード１１８が含まれ、ファイル・プラン・レコード１１８のそれぞれが、ファイル・プラン・ノードに関連し、ファイル・プラン・ノードの親ノード１２０ａおよび子ノード１２０ｂを識別する。また、各ファイル・プラン・レコード１１８に、ファイル・プラン・オブジェクト１２２が含まれ、ファイル・プラン・オブジェクト１２２ごとに、属性フィールド１２４、ライフ・サイクル・コード・フィールド１２６、中断状況フィールド１２８、および処分オーソリティ・フィールド１３０が含まれる。

ファイル・プラン・オブジェクト１２２は、「ファイル」オブジェクト、「フォルダ」オブジェクト、または「レコード」オブジェクトとして、対応するノード１２０の特性を表すことができる。ファイル・プランの階層的な性質と一貫して、ファイル・オブジェクトに、ファイル・オブジェクト、フォルダ・オブジェクト、およびレコード・オブジェクトを含めることができる。フォルダ・オブジェクトに、複数の関連するレコード・オブジェクトを含めることができる。フォルダ・オブジェクトに保管されたレコード・オブジェクトは、たとえば、主題または原作者あるいはその両方によって関連するものとすることができる。レコード・オブジェクトは、ホスト・アプリケーション・プログラム１１４によって管理されるホスト・レコードに一意に関連する識別子を保持する。その結果、レコード・オブジェクトは、ワード・プロセッシング・レコード、スプレッドシート・レコード、デスクトップ・パブリッシング・レコード、マルチメディア・ファイル、実行可能コンピュータ・プログラム、データベース、またはホスト・アプリケーション・プログラム１１４によって管理される他の電子データに一意に関連する識別子を有することができる。

属性フィールド１２４によって、「ａｕｔｈｏｒ（作成者）」、「ｓｕｂｊｅｃｔ ｍａｔｔｅｒ（主題）」、および「ｐｒｏｊｅｃｔ ｃｏｄｅ（プロジェクト・コード）」など、各オブジェクトの１つまたは複数のプロファイル・データ項目が指定される。レコード管理サーバ２００の管理者が、ファイル・プランの属性１２４を定義する時に、管理者が、属性１２４の値を事前に定義し、ユーザがレコード管理システム１００にホスト・レコードを登録する（下で説明する）時に属性１２４の事前定義の値から選択できるようにする「ピックリスト」を定義することが好ましい。管理者は、「カスタム・プロファイル」（下で説明する）を定義することによって、ピックリストを１つまたは複数のユーザに関連付けることができる。したがって、たとえば、ファイル・プラン・オブジェクト属性１２４で、部署プロジェクト・コードが指定された場合に、管理者は、ピックリストにすべての有効なプロジェクト・コードを取り込み、そのピックリストを、ファイル・プラン内の適当なノード１２０に関連付けることができる。ユーザが、新しいホスト・レコードをそのファイル・プランに挿入しようとする時に、レコード管理サーバ２００は、そのユーザに、選択のために有効なプロジェクト・コードを提示する。

ライフ・サイクル・コード・フィールド１２６は、関連するファイル・プラン・オブジェクト１２２のライフ・サイクル・フェーズを識別する必須フィールドである。レコード管理サーバ２００が、ライフ・サイクル管理を実施できるようにするために、レコード管理サーバ２００の管理者は、ファイル・プラン・オブジェクト１２２のさまざまなライフ・サイクル・フェーズ（たとえば、カットオフ、同意、または破棄）と、レコード管理サーバ２００に登録された各レコードが通過するシーケンスを識別する。管理者は、次に、ライフ・サイクル・フェーズごとにライフ・サイクル・コード（ＬＣＣ）１２６を割り当て、ライフ・サイクル・フェーズの間でのファイル・プラン・オブジェクト１２２の遷移を決定するパラメータを定義する保存ルールを定義する。ユーザが、レコードをレコード管理サーバ２００に登録する時に、そのユーザは、定義されたライフ・サイクル・コード１２６の１つを、ライフ・サイクル・コード・フィールド１２６に挿入しなければならない。

ライフ・サイクル・コード・フィールド１２６には、名前サブフィールド、処分タイプ・サブフィールド、およびフェーズ・サブフィールドが含まれる。名前サブフィールドには、ライフ・サイクル・コード１２６を一意に識別する識別子が含まれる。処分タイプ・フィールドによって、関連するファイル・プラン・オブジェクト１２２が保存期間の終りに達した時にホスト・アプリケーション・プログラム１１４によって実行されるアクティビティが指定される。たとえば、処分タイプ・フィールドによって、ファイル・プラン・オブジェクト１２２を、保存期間の終りに破棄するか、外部倉庫に転送しなければならないことを指定することができる。

フェーズ・サブフィールドによって、ファイル・プラン・オブジェクト１２２がライフ・サイクル状態のそれぞれで過ごす時間の期間と、各ライフ・サイクル状態に入った時にオブジェクトが受け取るセキュリティ・レベル（下で説明する）が指定される。フェーズ・サブフィールドに、ファイル・プラン・オブジェクト１２２のカットオフ情報も含めることができる。通常、ファイル・プラン・オブジェクト１２２がカットオフ・フェーズに入る時に、そのファイル・プラン・オブジェクト１２２へのアクセスが制限される。たとえば、ファイル・プラン・オブジェクト１２２がファイル・オブジェクトである場合に、ファイル・プラン・オブジェクト１２２がカットオフ・フェーズに留まる間にユーザがファイル・プラン・オブジェクト１２２にレコード・オブジェクトを追加できなくするようにレコード管理サーバ２００を構成することができる。

カットオフ情報には、ファイル・プラン・オブジェクト１２２がカットオフ・フェーズに入ったかどうかを示すカットオフ・フラグ、カットオフ・フェーズの開始日付を識別するカットオフ・サイクル日付、およびカットオフが１年の途中に適用される頻度を指定するカットオフ頻度が含まれる。ファイル・プラン・オブジェクト１２２がカットオフ・フェーズに入る場合に、そのオブジェクトの保存期間は、次のカットオフ期間が始まるまで開始されず、これによって、オブジェクトの有効保存期間が延長される。

たとえば、ファイル・プラン・オブジェクト１２２のカットオフ・サイクル日付が、１月１日であり、カットオフ頻度が、半年ごとである場合に、カットオフは、毎年の１月１日および７月１日として判定される。ファイル・プラン・オブジェクト１２２が、レコード管理サーバ２００に１２月１４日に登録され（ライフ・サイクル日付）、カットオフ・フェーズのシーケンスを定義する保存ルール、１年のアクティブ保存フェーズ、および２年の休止保存フェーズを割り当てられ、ライフ・サイクル・コード１２６で指定される現在のライフ・サイクル・フェーズが、カットオフ・フェーズである場合に、このライフ・サイクル・コード１２６を有するすべてのファイル・プラン・オブジェクト１２２が、１月１日までカットオフ・フェーズに入る。その後、ファイル・プラン・オブジェクト１２２に関連するホスト・レコードは、ファイル・プラン・オブジェクト１２２がカットオフ・フェーズを完了した日から３年のライフ・スパンを有し（１２月１４日から３年ではなく）、その後に、ホスト・レコードは、ホスト・サーバによって削除される（ライフ・サイクル・コード１２６が、削除の処分タイプを有する場合）か、ファイル・プラン・オブジェクト１２２に関して指定される処分オーソリティ１３０に転送される（ライフ・サイクル・コード１２６が、同意の削除タイプを有する場合）。

レコード管理サーバ２００は、中断状況フィールド１２８を使用して、ファイル・プラン・オブジェクト１２２が次のライフ・サイクル・フェーズに遷移できるかどうかを判定する。中断状況フィールド１２８には、中断名、およびオブジェクトを中断したユーザの名前が含まれる。オブジェクトが中断される場合に、オブジェクト１２２は、その現在のライフ・サイクル・フェーズで凍結され、これによって、オブジェクト１２２が、中断が除去されるまで、次のライフ・サイクル・フェーズに遷移しなくなり、対応するホスト・レコードが処分されなくなる。オブジェクト１２２は、任意の所与の時に複数の中断を有することができ、その場合に、すべての中断が解除されるまで、対応するホスト・レコードを処分することはできない。

図２からわかるように、ファイル・プラン・レコード１１８のほかに、ファイル・プラン・データベース１１０には、セキュリティ・テーブル１３２、グローバル・アクセス・テーブル１３４、オブジェクト・アクセス・テーブル１３６、およびファイル・プラン・ビュー・テーブル１３８が含まれ、カスタム・プロファイル・テーブル１４０も含めることができる。レコード管理サーバ２００は、セキュリティ・テーブル１３２を使用して、レコード管理サーバ２００へのアクセスを、識別されたユーザに制限し、そのユーザがレコード管理サーバ２００にログ・インしている間に実行を許可される機能を制御する。

セキュリティ・テーブル１３２には、ホスト・サーバ１０４の認証データと、ローカル・アカウントおよびホスト・アカウントの認証データおよび機能許可データが含まれる。ホスト・サーバ認証データは、ＨｏｓｔＩＤファイル、ホスト／エイリアス・ファイル、およびエイリアス／ＤＳＮファイルからなる。ＨｏｓｔＩＤファイルには、それぞれがホストＩＤ、ホスト名、およびホスト・パスワードを識別する項目が含まれる。ホストＩＤは、レコード管理サーバ２００によって割り当てられる、ホスト・サーバ１０４を一意に識別する番号である。ホスト名は、ファイル・プラン・レコード１１８がどこから発したかを示す、ホスト・サーバ１０４の一意の説明的な名前である。ホスト・パスワードは、ホスト・ユーザの代わりにレコード・サーバにアクセスするためにホスト・サーバ１０４がレコード管理サーバ２００に供給しなければならない暗号化された項目である。

ホスト／エイリアス・ファイルは、それぞれがホスト名およびホスト・エイリアスを識別する項目を含むＸＭＬファイルである。レコード管理サーバ２００は、ホスト／エイリアス・ファイルを使用して、ホスト名をデータベース・エイリアスにマッピングする。エイリアス／ＤＳＮファイルは、それぞれがホスト・エイリアス、データベース接続ストリング、およびデータベース・パスワードを識別する項目を含むＸＭＬファイルである。データベース接続ストリングには、ホスト・サーバ１０４のために正しいファイル・プラン・データベース１１０をアドレッシングするのにレコード管理サーバ２００が必要とするＡＤＯ情報が含まれる。データベース・パスワードは、ファイル・プラン・データベース１１０にアクセスするのに使用される暗号化された項目である。

ローカル・アカウントは、通常は管理ユーザのために予約され、コンピュータ端末１０２の１つから直接にレコード管理サーバ２００にログ・インすることによってアクセスされる。ローカル・ユーザは、サーバにログ・インするまでレコード管理サーバ２００に未知なので、各ローカル・アカウント・セキュリティ・テーブル・レコードの認証データには、各ローカル・ユーザを認証するための、ユーザＩＤ項目と、対応するパスワード項目の両方が含まれる。その一方で、ホスト・アカウントは、非管理ユーザのために予約され、ホスト・アプリケーション・プログラム１１４を介してのみアクセス可能である。ホスト・ユーザは、ホスト・サーバ１０４に既にログ・インしているので、各ホスト・アカウント・セキュリティ・テーブル・レコードの認証データには、ユーザＩＤ項目だけが含まれ、パスワード項目は含まれない。

レコード管理サーバ２００は、ローカル・アカウントおよびホスト・アカウントの機能許可データを使用して、各ユーザがレコード管理サーバ２００に関して実行することを許可される機能を指定する。通常の機能権利には、レポート生成、処分オーソリティ指定、ファイル・プラン設計、ライフ・サイクル設計、ピック・リスト管理、プロファイル設計、およびセキュリティ管理が含まれる。

ローカル・アカウントおよびホスト・アカウントの認証データおよび機能許可データのほかに、セキュリティ・テーブル１３２には、ローカル・グループおよびホスト・グループの両方の認証データおよび機能許可データも含まれる。レコード管理サーバ２００は、グループ認証データおよびグループ機能許可データを使用して、ユーザのクラスを認識し、許可される機能をクラスのすべてのメンバに割り当てる。

レコード管理サーバ２００の管理者は、ローカル・グループを明示的に作成しなければならない。対照的に、ホスト・ユーザが、レコード管理サーバ２００へのアクセスを要求する時には、ホスト・アプリケーション・プログラム１１４が、ホスト・サーバ１０４にログ・インしたユーザのホストＩＤ、ホスト・パスワード、およびユーザＩＤならびにホスト・ユーザが属するすべてのグループのリストを、レコード管理サーバ２００に供給する。レコード管理サーバ２００は、ホストＩＤおよびホスト・パスワードを、ホストＩＤファイル内の対応する項目と比較して、ホスト・サーバ１０４が、レコード管理サーバ２００へのログ・インを許可されるかどうかを検証する。次に、レコード管理サーバ２００は、ホスト／エイリアス・ファイルからホスト・サーバ１０４のホスト・エイリアスを判定し、エイリアス／ＤＳＮファイルからデータベース接続ストリングを判定し、その後、関連するデータベース・パスワードを使用して、ファイル・プラン・データベース１１０にログ・インする。ホスト・アプリケーション・プログラム１１４が、ファイル・プラン・データベース１１０に成功裡にログ・インしたならば、レコード管理サーバ２００は、グループ・リストをセキュリティ・テーブル１３２に保管し、各ホスト・ユーザがファイル・プラン・データベース１１０にログ・インする時に、識別されたメンバを用いてグループ・リストを更新する。

グローバル・アクセス・テーブル１３４には、ファイル・プランで実施されるすべてのオブジェクト・タイプに関するアクセス・データを含むレコードが含まれる。レコード管理サーバ２００は、グローバル・アクセス・テーブル１３４のデータを使用して、各ユーザまたはグループあるいはその両方が、各ファイル・プラン・オブジェクト・クラス（たとえば、ファイル、フォルダ、レコード）に関して実行を許可される動作をグローバルに制御する。各アクセス・テーブル１３４のレコードは、セキュリティ・テーブル１３２のレコードにリンクされ、ユーザまたはグループあるいはその両方ごとに、ユーザまたはグループが実行を許可されるファイル・プラン・オブジェクト動作を識別する。通常、ファイル・プラン・オブジェクト動作には、追加、削除、および許可変更が含まれる。

オブジェクト・アクセス・テーブル１３６には、ファイル・プランの個々のオブジェクトのアクセス・データを含むレコードが含まれる。レコード管理サーバ２００は、オブジェクト・アクセス・テーブル１３６のデータを使用して、各ユーザまたはグループあるいはその両方が各ファイル・プラン・オブジェクト１２２に関して実行を許可される動作を制御し、これによって、グローバル・アクセス・テーブル１３４でセットされたグローバル許可をオーバーライドする。各オブジェクト・アクセス・テーブル１３６レコードは、めいめいのファイル・プラン・レコード１１８にリンクされ、ファイル・プラン・オブジェクト１２２ごとに、各ユーザまたはグループがそのオブジェクトに対して実行することを許可される動作を識別する。ファイル・プランの階層的な性質と一貫して、ファイル・プラン・オブジェクト１２２に適用される許可は、ファイル・プラン・オブジェクト１２２のすべての子孫にも適用される。

ファイル・プラン・ビュー・テーブル１３８には、ファイル・プラン・オブジェクト１２２のサブセットがリストされ、ファイル・プラン・ビュー・テーブル１３８は、ファイル・プラン・オブジェクトのサブセットのファイル・プラン・オブジェクト１２２の間の関係を識別する。識別される関係は、階層的、２項、または単項とすることができる。階層ビューでは、ファイル・プラン・オブジェクト１２２の属性値が指定されていない場合に、ファイル・プラン・オブジェクト１２２は、ファイル・プラン・オブジェクト１２２の親オブジェクト（または、親オブジェクトの属性値も指定されていない場合には、親オブジェクトの親オブジェクト）から属性値を継承する。継承可能な属性１２４に、ライフ・サイクル・コード１２６、中断状況１２８、処分オーソリティ１３０、およびセキュリティが含まれる。

単項ビューおよび２項ビューは、それぞれ、そのビューのすべてのファイル・プラン・オブジェクト１２２の間の単一方向関係および両方向関係を定義する。属性１２４は、単項ビューまたは２項ビューでは継承されない。この２つのビュー・タイプでは、「相互参照」関係または「分類」関係など、ファイル・プランのオブジェクトの間の非階層関係が定義される。

レコード管理サーバ２００は、ファイル・プラン・ビュー・テーブル１３８を使用して、ファイル・プランのオブジェクトおよび属性１２４の表示に関する異なる機構をユーザに提供する。たとえば、レコード管理サーバ２００の管理者は、コンピュータ端末１０２のユーザのために、「英数」論理ビューおよび「倉庫」物理ビューを定義することができる。「英数」ビューでは、レコード管理サーバ２００が、ファイル・オブジェクト、フォルダ・オブジェクト、およびレコード・オブジェクトを描写する。「倉庫」ビューでは、レコード管理サーバ２００が、倉庫オブジェクト、通路オブジェクト、棚オブジェクト、箱オブジェクト、およびフォルダ・オブジェクトを描写する。

カスタム・プロファイル・テーブル１４０は、ファイル・プラン・オブジェクト１２２の少なくとも１つの属性１２４のサブセットを定義し、属性サブセットを表示することを許可されるユーザをリストする。さらに、カスタム・プロファイル・テーブル１４０では、属性１２４ごとに、属性１２４が読取専用であるかどうか、属性１２４が必須であるかどうかが指定され、属性１２４に割り当てられるデフォルト値またはピック・リストが識別される。レコード管理サーバ２００は、カスタム・プロファイル・テーブル１４０を使用して、ユーザがファイル・プランのオブジェクトについてデータの入力を許可される形を制御する。たとえば、ファイル・プランに、管理職だけがアクセスを許可される属性「プロジェクト状況」を有するファイル・プラン・オブジェクト１２２が含まれる場合に、レコード管理サーバ２００の管理者は、「プロジェクト状況」を除外した「汎用」プロファイルと、「プロジェクト状況」属性を含む「管理職」プロファイルを定義し、ユーザ・アクセスに一方または他方のプロファイルを割り当てることができる。その結果、ファイル・プラン・オブジェクト１２２が表示される時に、必ず、適当な属性１２４が、めいめいの管理状況に従って表示される。

レコード管理サーバ２００は、Ｗｉｎｄｏｗｓ（Ｒ）２０００ベースのサーバであることが好ましいコンピュータ・サーバで実施される。図３からわかるように、レコード管理サーバ２００には、レコード管理サーバ２００を通信ネットワーク１０８にインターフェースするネットワーク・インターフェース・アダプタ２０２、ネットワーク・インターフェース２０２と通信する中央処理装置（ＣＰＵ）２０４、ならびにＣＰＵ２０４と通信する不揮発性メモリ（ＲＯＭ）２０６および揮発性メモリ（ＲＡＭ）２０８が含まれる。ＲＯＭ２０６は、磁気ディスク・メモリ、光ディスク・メモリ、または電子メモリなどのコンピュータ可読媒体であり、ウェブ管理者オブジェクト２１０、アプリケーション・プログラム・インターフェース（ＡＰＩ）２１２、およびホスト・アプリケーション・プログラム１１４によって管理されるホスト・レコードのライフ・サイクルを管理するレコード管理エンジン２１４をＲＡＭ２０８内で確立する、ＣＰＵ２０４用のプロセッサ命令を担持する。その代わりに、ウェブ管理者オブジェクト２１０、ＡＰＩ２１２、およびレコード管理エンジン２１４を、別々のサーバで実施して、負荷平衡化を提供することができる。

ウェブ管理者オブジェクト２１０は、インターネット・ブラウザベースのプログラムであり、コンピュータ端末１０２の管理ユーザに、ＡＰＩ２１２への単純化されたインターフェースを提供し、これによって、管理ユーザが、ホスト・サーバ１０４によって管理されるレコードの会社保存ポリシを開発し、管理できるようにする。ウェブ管理者オブジェクト２１０は、ＩＩＳ ５．０およびＡｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ（ＡＳＰ）３．０を使用して実施されることが好ましい。

ＡＰＩ２１２は、レコード管理エンジン２１４へのアクセスをコンピュータ端末１０２に提供し、ＸＭＬを使用してクライアント・アプリケーション（コンピュータ端末１０２で実施される）との間でデータを受け渡す。ＡＰＩ２１２は、ＣＯＭ＋アプリケーションでホスティングされるＣＯＭオブジェクトを使用して実施され、ウェブ管理者オブジェクト２１０およびホスト・アプリケーション・プログラム１１４にＣＯＭインターフェースを提供することが好ましい。さらに、ＡＰＩ２１２は、たとえばホスト・アプリケーション・プログラム１１４内で実施されるＣＯＭまたはシンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）インターフェース１１６を介して、ホスト・アプリケーション・プログラム１１４に組み込まれて、ホスト・アプリケーション・プログラム１１４に対するかなりの再構成を必要とせずにレコード管理エンジン２１４にアクセスできるようになることが好ましい。

レコード管理エンジン２１４は、ホスト・アプリケーション・プログラム１１４によって管理されるレコードのライフ・サイクル遷移を管理する。レコード管理エンジン２１４は、ファイル・プラン・データベース１１０と通信し、ＡＰＩ２１２を介してホスト・アプリケーション・プログラム１１４に公開され、ウェブ管理者オブジェクト２１０およびＡＰＩ２１２の組合せを介してコンピュータ端末１０２に公開される。レコード管理エンジン２１４が、ＣＯＭインターフェースを介してすべてのＳＱＬ ＤＢＭＳアクセスをカプセル化し、ＯｒａｃｌｅおよびＳＱＬ Ｓｅｒｖｅｒの両方をサポートするＣＯＭ＋アプリケーションとして実施されることが好ましい。このＣＯＭ＋アプリケーションは、下記の管理機能を実行する（ウェブ管理者オブジェクト２１０を使用して）ように構成される。

ファイル・プラン設計：
ホスト・サーバ１０４によって管理されるレコードの編成を決定するルールを定義する
ファイル・プラン実施：
オブジェクトに対するセキュリティ・ルールの指定を含めて、ファイル・プランに挿入されるファイル・プラン・オブジェクト１２２を定義する
ライフ・サイクル管理：
ファイル・プラン・オブジェクト１２２の保存を決定する保存ルールを定義する
ライフ・サイクル処理：
ライフ・サイクル状態の間でファイル・プラン・オブジェクト１２２を遷移させる
レポート作成：
ファイル・プラン内のオブジェクトに関するレポートを生成する
セキュリティ：
ユーザ・アクセス、グループ・アクセス、ユーザ機能許可、およびグループ機能許可を定義する

前述の機能を実行するように構成されるほかに、このＣＯＭ＋アプリケーションには、レコード識別子レシーバ２１６、ファイル・プラン・ファイリング手段２１８を定義するオブジェクト、ライフ・サイクル状態を判定する手段２２０を定義するオブジェクト、およびライフ・サイクル命令を提供する手段２２２を定義するオブジェクトが含まれる。その代わりに、ＣＯＭ＋アプリケーションを含むオブジェクトを、別々のサーバで実施して、負荷平衡化を提供することができる。さらに、ＣＯＭ＋アプリケーションを、ソフトウェア・アプリケーションとして実施されるものとして説明したが、これを、専用電子ハードウェア、またはハードウェアおよびソフトウェアの組合せとして実施することもできることを理解されたい。

レコード識別子レシーバ２１６は、ホスト・アプリケーション・プログラム１１４によって管理されるレコードに関連するレコード識別子をホスト・アプリケーション・プログラム１１４から受け取るように構成される。このレコード識別子は、ホスト・アプリケーション・プログラム１１４にログ・インしたユーザが、ライフ・サイクル追跡のためにレコード管理サーバ２００に登録することを望むレコードに関連する。レコード識別子には、ホスト・アプリケーション・プログラム１１４がレコードを一意に識別するのに使用する識別子フィールドと、レコードの分類プロパティ（たとえば、「作成者」、「主題」、および「プロジェクト・コード」など）を識別するプロファイル・メタデータが含まれる。

上で述べたように、レコード管理サーバ２００の管理者が、ファイル・プランの属性１２４を定義する時に、管理者は、ファイル・プランの属性１２４の事前定義の値のピックリスト（またはメニュー）も定義して、ユーザが、レコード管理サーバ２００に前述のプロファイル・メタデータを簡単に供給できるようにすることができる。したがって、本発明の１実施形態では、レコード識別子レシーバ２１６が、ユーザに関連するカスタム・プロファイル１４０を突き止め、ユーザに、カスタム・プロファイル１４０で定義されたデフォルト属性値およびピックリストのすべてを提供するように構成される。ユーザは、ピックリスト（またはメニュー）から属性値を選択し、追加属性値のすべてをカスタム・プロファイル１４０の適当なフィールドに入力し、その後、必要なプロファイル・メタデータをレコード識別子レシーバ２１６に送り返す。

その代わりに、本発明のもう１つの実施形態では、ホスト・アプリケーション・プログラム１１４がホスト・サーバ・データベース１１２内のレコードに関連付けるプロファイル・データのコピーをホスト・アプリケーション・プログラム１１４が、レコード識別子レシーバ２１６に供給し、レコード識別子レシーバ２１６は、必要なプロファイル・メタデータについて、受け取ったプロファイル・データを解析するように構成される。その結果、ホスト・アプリケーション・プログラム１１４にログ・インしたユーザが、レコードをレコード管理システム１００の適当なファイル・プラン・ノード１２０に分類することを望む時に、レコード識別子レシーバ２１６が、手動介入なしで、必要なプロファイル・メタデータを自動的に抽出する。

ファイル・プラン・ファイリング手段２１８は、ホスト・アプリケーション・プログラム１１４から受け取ったレコード識別子を、ファイル・プランの適当なノード１２０にファイリングするように構成される。それを行うために、ファイル・プラン・ファイリング手段２１８は、レコード識別子に含まれるプロファイル・データを、ファイル・プラン・オブジェクト定義と比較し、プロファイル・メタデータに従って、レコード識別子を適当なファイル・プラン・ノード１２０に挿入する。

ライフ・サイクル判定手段２２０は、レコード管理サーバ２００に登録された選択されたレコードのライフ・サイクル状態を判定するように構成される。それを行うために、管理者は、ファイル・プラン・レコード１１８に関する照会を実行し、ライフ・サイクルの次のフェーズに移動されるか処分される資格があるファイル・プラン・オブジェクト１２２のリストを要求する。指定された照会に一致するファイル・プラン・オブジェクト１２２ごとに、ライフ・サイクル判定手段２２０は、めいめいのライフ・サイクル・コード１２６に対して保存ルールを評価して、めいめいの保存期間が満了したファイル・プラン・オブジェクト１２２を識別する。

ライフ・サイクル命令提供手段２２２は、識別されたレコードを新しいライフ・サイクル状態に遷移させるようにアプリケーション・プログラムに要求する命令をホスト・アプリケーション・プログラム１１４に供給するように構成される。それを行うために、ライフ・サイクル命令提供手段２２２は、満了したファイル・プラン・オブジェクト１２２のめいめいのライフ・サイクル・コードを更新し、これによって、ファイル・プラン・オブジェクト１２２を次のライフ・サイクル・フェーズに遷移させる。また、ライフ・サイクル命令提供手段２２２は、ホスト・アプリケーション・プログラム１１４が、残りのファイル・プラン・オブジェクト１２２に関連するレコードをそのめいめいの新しいライフ・サイクル・フェーズに移行させることを要求するコマンドをホスト・アプリケーション・プログラム１１４に発行する。

レコード管理システム１００によって行われるライフ・サイクル管理プロセスを、図４を参照して詳細に説明する。当初に、レコード管理システム１００の管理者が、コンピュータ端末１０２の１つを使用して、ウェブ管理者オブジェクト２１０にユーザＩＤおよびパスワードを供給することによって、レコード管理エンジン２１４にログ・インする。ユーザＩＤおよびパスワードが、セキュリティ・テーブル１３２に含まれるユーザＩＤおよび対応するパスワードと一致する場合に、ＡＰＩ２１２は、管理者がレコード管理エンジン２１４を使用することを許可する。

管理者は、レコード管理エンジン２１４に成功裡にログ・インしたならば、ステップ５００で、ファイル・プラン・ノード１２０、親子ノード１２０、ファイル・プラン・オブジェクト・クラス、およびファイル・プラン属性１２４ごとに、ライフ・サイクル・コード１２６および中断状況１２８を指定することによって、ファイル・プランを定義する。管理者は、ホスト・アプリケーション・プログラム１１４のホスト認証データ、ファイル・プランを表示／編集することを許可される管理ユーザのローカル・ユーザ認証データ、レコード管理エンジン２１４へのアクセスを許可されるホスト・ユーザのホスト・ユーザ認証データ、および各ユーザ／グループがレコード管理サーバ２００に関する実行を許可される機能を識別する機能許可データを、セキュリティ・テーブル１３２に取り込む。さらに、管理者は、グローバル・アクセス・テーブル１３４およびオブジェクト・アクセス・テーブル１３６に、ファイル・プラン・オブジェクト１２２に関して許可される動作を識別するアクセス・データを取り込み、ファイル・プラン・ビュー・テーブル１３８に、ファイル・プランに関して許可されるビューを取り込み、所望のすべてのカスタム・プロファイル・テーブル１４０を作成する。レコード管理エンジン２１４は、そのように定義されたファイル・プランを、ファイル・プラン・データベース１１０内で維持する。

ファイル・プランを定義した後に、ステップ５０２で、ホスト・アプリケーション・プログラム１１４にログ・インしたユーザが、レコード管理サーバ２００がホスト・レコードのライフ・サイクルを管理しなければならないことを宣言する。通常、ユーザは、ホスト・レコードを作成したか編集しており、レコード管理が、作成フェーズまたは編集フェーズの完了時にホスト・レコードのライフ・サイクルを管理しなければならないことを宣言する。ユーザは、ホスト・サーバ１０４でホスト・レコードをクローズすることによるなど、自動的に、またはホスト・アプリケーション・プログラム１１４によって生成される電子プロファイル・フォームで適当なボックスを選択することによるなど、手動で、ホスト・レコードを宣言することができる。

レコード宣言ステップの完了時に、ステップ５０４で、ホスト・アプリケーション・プログラム１１４が、レコード管理サーバ２００によるライフ・サイクル管理について、宣言されたレコードを登録する。それを行うために、まず、ホスト・アプリケーション・プログラム１１４は、ホストＩＤおよびパスワードをＡＰＩ２１２に供給し、受け取られたパラメータがホストＩＤファイルの項目と一致する場合に、ＡＰＩ２１２は、レコード管理エンジン２１４へのアクセス権をホスト・アプリケーション・プログラム１１４に与える。ホスト・アプリケーション・プログラム１１４は、ホスト・サーバ１０４にログ・インしたユーザのユーザＩＤおよびホスト・ユーザが属するすべてのグループのリストも、ＡＰＩ２１２に与える。レコード管理エンジン２１４は、この後者のパラメータを使用して、データベース・パスワードを求めてホスト／エイリアス・ファイルおよびエイリアス／ＤＳＮファイルにアクセスし、そのデータベース・パスワードを用いて適当なファイル・プラン・データベース１１０にログ・インする。

ステップ５０６で、ホスト・アプリケーション・プログラム１１４が、レコード管理エンジン２１４にプロファイル・メタデータを供給することによって、ファイル・プランの適当なノード１２０に含めるために、宣言されたレコードを分類する。ユーザは、宣言されたレコードを、自動的にまたは手動でのいずれかで分類することができる。

前者の手法（自動的なレコード分類）では、ホスト・アプリケーション・プログラム１１４が、レコード・レシーバ２１６に、ホスト・アプリケーション・プログラム１１４が宣言されたレコードに関連付けるプロファイル・データ（たとえば、タイトル、作成者、公表日、および主題）を供給し、レコード・レシーバ２１６は、必要なプロファイル・メタデータに関して、受け取ったプロファイル・データを解析する。レコード識別子レシーバ２１６は、ユーザＩＤを用いてカスタム・プロファイル・テーブル１４０に照会して、プロファイル・メタデータに含めるデフォルト属性値を突き止める。この手法は、ホスト・ユーザが別々のユーザ・インターフェースまたは新しいソフトウェア・プログラムを習得する必要なしに、レコード管理エンジン２１４が、宣言されたレコードのライフ・サイクル・フェーズを管理できるようになるので、有利である。

後者の手法（手動レコード分類）では、レコード・レシーバ２１６が、受け取ったユーザＩＤを用いてカスタム・プロファイル・テーブル１４０に照会して、ユーザのカスタム・プロファイルを突き止め、ユーザに、そのカスタム・プロファイルでユーザが表示を許可されるすべての属性フィールド１２４を提示する。レコード・レシーバ２１６は、ユーザに、カスタム・プロファイルで定義されたデフォルト属性値およびピックリストも提供する。ユーザは、ピックリストから属性値を選択し、適当なフィールドに追加属性値を入力し、結果の情報を、必要なプロファイル・メタデータとしてレコード管理エンジン２１４に送る。自動分類手法ほどユーザフレンドリではないが、手動分類手法は、ホスト・ユーザが新しいソフトウェア・プログラムを習得する必要なしに、レコード管理エンジン２１４が、宣言されたレコードのライフ・サイクル・フェーズを管理できるようになるので、有利である。

宣言されたレコードが分類された後に、ステップ５０８で、レコード管理エンジン２１４が、プロファイル・メタデータを使用して、プロファイル・メタデータに関する、ファイル・プラン内の適当な位置を提供する。それを行うために、ファイル・プラン・ファイリング手段２１８が、受け取ったプロファイル・メタデータを、ファイル・プラン・オブジェクト定義と比較し、ファイル・プラン・データベース１１０内に適当なファイル・プラン・オブジェクト１２２を作成する。ファイル・プラン・ファイリング手段２１８は、プロファイル・メタデータを新しいファイル・プラン・オブジェクト１２２に割り当て、ライフ・サイクル日付をファイル・プラン・オブジェクト１２２に割り当てる。ライフ・サイクル日付は、通常は、ファイル・プラン・オブジェクト１２２がファイル・プラン・データベース１１０に追加された日付であるが、管理ユーザが、その後、ライフ・サイクル日付の代替日付を指定することができる。

ステップ５１０で、ファイル・プラン・ファイリング手段２１８が、ファイル・プラン・オブジェクト１２２に、ファイル・プラン階層内でのファイル・プラン・オブジェクト１２２の位置に矛盾しないライフ・サイクル・コード（ＬＣＣ）１２６を割り当て、セキュリティ・テーブル１３２を更新して、ファイル・プラン・オブジェクト１２２に対する実行を許可された機能を反映する。明白なように、ホスト・ユーザがファイル・プラン・オブジェクト１２２に対して実行できる機能は、ホスト・アプリケーション・プログラム１１４に課せられるセキュリティ・レベルによって指定される。

ファイル・プラン・ファイリング手段２１８は、宣言されたレコードがレコード管理エンジン２１４に登録されたこともホスト・アプリケーション・プログラム１１４に通知する。ホスト・アプリケーション・プログラム１１４は、レコードの所有権を管理グループに割り当て、管理グループのメンバでないすべてのユーザについて、レコードへのアクセス権を読取専用に制限することが好ましい。レコード管理サーバ２００は、ホスト・アプリケーション・プログラム１１４によって管理されるレコードのコピーを保存しないので、レコード管理サーバ２００は、ホスト・アプリケーション・プログラム１１４によって既に実施されているセキュリティ機能およびアクセス機能を複製せず、ホスト・レコードに関する別々の記憶空間を必要としない。さらに、ファイル・プラン・ファイリング手段２１８は、ホスト・アプリケーション・プログラム１１４と別々に実施されるので、ファイル・プラン内のファイル・プラン・オブジェクト１２２をファイリングする処理は、ホスト・アプリケーション・プログラム１１４によって普通に使用されるコンピューティング・リソースを抜き取ることによってホスト・アプリケーション・プログラム１１４に干渉することがない。

ホスト・レコードが、レコード管理エンジン２１４に登録された後に、管理ユーザは、最初の登録からめいめいの保存期間を通り、最終的な処分までの、めいめいのライフ・サイクル状態の間でのホスト・レコードの遷移を管理することができる。それを行うために、管理ユーザは、ウェブ管理者オブジェクト２１０にユーザＩＤおよびパスワードを供給することによって、レコード管理エンジン２１４にログ・インする。ユーザＩＤおよびパスワードが、セキュリティ・テーブル１３２に含まれるユーザＩＤおよび対応するパスワードと一致する場合に、ＡＰＩ２１２が、管理者にレコード管理エンジン２１４の使用を許可する。

管理者が、レコード管理エンジン２１４に成功裡にログ・インした後に、ステップ５１２で、管理者は、ライフ・サイクルの次のフェーズに移動されるか処分される資格を有するファイル・プラン・オブジェクト１２２のリストについて、レコード管理エンジン２１４に照会する。通常の照会パラメータに、検査されるファイル・プランの分岐およびライフ・サイクル計算に使用される基準日付が含まれる。管理者は、カットオフ・フラグの状態およびファイル・プラン・オブジェクト１２２に望まれる次のライフ・サイクル・フェーズも指定することができる。

照会結果から、ライフ・サイクル判定手段２２０は、割り当てられたライフ・サイクル日付を有しないファイル・プラン・オブジェクト１２２またはそのめいめいのライフ・サイクル日付が基準日付の後であるファイル・プラン・オブジェクト１２２を、考慮から除外する。さらに、残りのファイル・プラン・オブジェクト１２２のそれぞれについて、ライフ・サイクル判定手段２２０は、中断されているファイル・プラン・オブジェクト１２２をさらなる検査から除外し、関連するライフ・サイクル・コード１２６を判定する。

ファイル・プラン・オブジェクト１２２の１つが、ライフ・サイクル・コード１２６を割り当てられていない場合には、ライフ・サイクル判定手段２２０は、ライフ・サイクル・コード１２６を突き止めるまで、再帰的にオブジェクトの親オブジェクトを調べる。ライフ・サイクル判定手段２２０は、ステップ５１４で、ライフ・サイクル・コード１２６に対して保存ルールを評価して、めいめいの保存期間が満了したファイル・プラン・オブジェクト１２２を識別する。

満了したファイル・プラン・オブジェクト１２２が識別された後に、ライフ・サイクル命令提供手段２２２は、管理者に、めいめいの保存期間が満了したファイル・プラン・オブジェクト１２２のリストを供給する。そのリストから、管理者は、処理を望まないオブジェクトを除去するか中断する。レコード管理エンジン２１４は、ステップ５１６で、残りのファイル・プラン・オブジェクト１２２のめいめいのライフ・サイクル・コード１２６を更新し、これによって、ファイル・プラン・オブジェクト１２２を次のライフ・サイクル・フェーズに遷移させる。また、ライフ・サイクル命令提供手段２２２は、ステップ５１８で、ホスト・アプリケーション・プログラム１１４にコマンドを発行し、ホスト・アプリケーション・プログラム１１４が、残りのファイル・プラン・オブジェクト１２２に関連するレコードをそのめいめいの新しいライフ・サイクル・フェーズに遷移させることを要求する。

ファイル・プラン・オブジェクト１２２のいずれかの新しいライフ・サイクル・フェーズが「削除」である場合に、ライフ・サイクル命令提供手段２２２は、破棄されるファイル・プラン・オブジェクト１２２をファイル・プラン・データベース１１０から除去し、ホスト・アプリケーション・プログラム１１４が識別されたファイル・プラン・オブジェクト１２２に関連するレコードを除去することを要求するコマンドをホスト・アプリケーション・プログラム１１４に発行する。ホスト・アプリケーション・プログラム１１４が、指定されたレコードを削除する必要があるのではなく、その代わりに、ホスト・サーバ・データベース１１２を更新して、レコード管理サーバ２００が、もはや指定されたレコードのライフ・サイクル・フェーズを管理しなくなることを指定するだけでよいことに留意されたい。

同様に、ファイル・プラン・オブジェクト１２２のいずれかの新しいライフ・サイクル・フェーズが「同意」である場合には、ライフ・サイクル命令提供手段２２２は、同意されたファイル・プラン・オブジェクト１２２をファイル・プラン・データベース１１０から除去し、ホスト・アプリケーション・プログラム１１４が識別されたファイル・プラン・オブジェクト１２２に関連するレコードを指定された転送ディレクトリに移動することを要求するコマンドをホスト・アプリケーション・プログラム１１４に発行する。転送ディレクトリへのホスト・レコードの転送の後に、レコード管理エンジン２１４は、転送ディレクトリから対応するファイル・プラン・オブジェクト１２２について指定された処分オーソリティ１３０にホスト・レコードを転送すること、または処分オーソリティ１３０に、転送ディレクトリから処分オーソリティ１３０によって管理されるストレージ・サイトへレコードを転送しなければならないことを知らせることのいずれかを行うことができる。

コンピュータ端末、ホスト・コンピュータ・サーバ、およびレコード管理サーバを示す、レコード管理システムを示す概略図である。 ファイル・プラン・データベースの構造を示す図である。 図１に示されたレコード管理サーバを示す概略図である。 レコード管理システムの動作を示す流れ図である。

Claims (21)

1. アプリケーション・プログラムによって管理されるレコードに一意に関連するレコード識別子をネットワークを介して受け取るステップであって、前記レコード管理エンジンが、前記レコードのライフ・サイクル状態を管理するように構成され、前記レコード識別子が、前記関連するレコードのプロファイル・データを含む、ステップと、
   前記関連するプロファイル・データに従ってファイル・プランのファイル・プラン・ノードに前記受け取ったレコード識別子をファイリングするステップであって、各前記ファイル・プラン・ノードが、関連する保存ルールを有する、ステップと、
   前記保存ルールから、前記管理されるレコードのライフ・サイクル状態を判定するステップと、
   前記アプリケーション・プログラムが前記管理されるレコードを前記めいめいのライフ・サイクル状態に遷移させることを要求するライフ・サイクル命令を前記ネットワークを介して送るステップと
   を含む、電子レコードを管理する方法。
2. ファイル・プラン・データベース内でファイル・プランを定義するステップであって、前記ファイル・プランが、少なくとも１つのファイル・プラン・ノードを指定する、ステップ
   をさらに含み、各ファイル・プラン・ノードに関連する前記保存ルールが、ライフ・サイクル保存ルールである
   請求項１に記載の方法。
3. 前記アプリケーション・プログラムが、前記管理されるレコードのそれぞれのレコード・プロファイルを維持し、前記レコード識別子を受け取るステップが、前記アプリケーション・プログラムから前記関連するレコードの前記レコード・プロファイルを受け取るステップと、前記関連するプロファイル・データの前記レコード・プロファイルを解析するステップとを含む、請求項１または２に記載の方法。
4. 前記レコード識別子を受け取るステップが、前記ファイル・プラン・ノードのメニューを提供するステップと、前記ノード・メニューのメニュー選択から前記関連するプロファイル・データを判定するステップとを含む、請求項１または２に記載の方法。
5. 前記ファイル・プラン・ノードが、関連するレコードの前記ライフ・サイクル状態を識別するライフ・サイクル・コードと、前記関連するレコードが前記ライフ・サイクル状態の異なるライフ・サイクル状態の間で遷移しなければならないことを識別する中断状況フラグとを含み、前記ライフ・サイクル状態判定ステップが、前記ライフ・サイクル・コード、基準日付、および前記状況フラグの状態に対して前記保存ルールを評価することを含む、請求項１または２に記載の方法。
6. 前記ファイル・プランが、前記ファイル・プラン・ノードの階層配置を含み、前記ファイル・プラン・ノードの少なくとも１つが、ライフ・サイクル・コードを含まず、前記ライフ・サイクル状態判定ステップが、前記少なくとも１つのファイル・プラン・ノードの前記保存ルールを、前記少なくとも１つのファイル・プラン・ノードの親に関連する前記ライフ・サイクル・コードに対して評価することを含む、請求項１または２に記載の方法。
7. 前記ファイル・プランが、前記ファイル・プラン・ノードの非階層配置を含み、前記ファイル・プラン・ノードの少なくとも１つが、ライフ・サイクル・コードを含まず、前記ライフ・サイクル状態判定ステップが、前記少なくとも１つのファイル・プラン・ノードの前記保存ルールを、前記少なくとも１つのファイル・プラン・ノードの親に関連する前記ライフ・サイクル・コードに対して評価することを含む、請求項１または２に記載の方法。
8. アプリケーション・プログラムによって管理されるレコードのライフ・サイクル管理を容易にするレコード管理エンジンであって、
   前記アプリケーション・プログラムによって管理されるレコードに関連するレコード識別子をネットワークを介して受け取る受取手段であって、前記レコード識別子が、前記関連するレコードのプロファイル・データを含む、受取手段と、
   前記関連するプロファイル・データに従ってファイル・プランのファイル・プラン・ノードに前記受け取ったレコード識別子をファイリングするファイリング手段であって、各前記ファイル・プラン・ノードが、関連するライフ・サイクル・ルールを有する、ファイリング手段と、
   前記ライフ・サイクル・ルールから、前記管理されるレコードのライフ・サイクル状態を判定する判定手段と、
   前記アプリケーション・プログラムが前記管理されるレコードを前記めいめいのライフ・サイクル状態に遷移させることを要求するライフ・サイクル命令を前記ネットワークを介して送る提供手段と
   を含む、レコード管理エンジン。
9. ファイル・プラン・データベースにアクセスするデータベース・インターフェースであって、前記ファイル・プラン・データベースは、少なくとも１つのファイル・プラン・ノードを含み、各前記ファイル・プラン・ノードは、前記ファイル・プラン・ノードに関連するオブジェクトのライフ・サイクル・フェーズ変化を決定するライフ・サイクル保存ルールを含む、データベース・インターフェースと、
   前記ファイリング手段および前記判定手段と通信し、前記ライフ・サイクル・フェーズの前記変化の表示を前記ネットワークを介してホスト・アプリケーション・プログラムに送るように構成されたアプリケーション・プログラム・インターフェースと
   をさらに含み、前記ファイリング手段および前記判定手段が、前記データベース・インターフェースと通信する
   請求項８に記載のレコード管理エンジン。
10. ファイル・プラン・データベース内でファイル・プランを定義するファイル・プラン定義手段であって、前記ファイル・プランが、少なくとも１つのファイル・プラン・ノードを含み、各前記ファイル・プラン・ノードが、前記ファイル・プラン・ノードに関連するオブジェクトのライフ・サイクル・フェーズ変化を決定するライフ・サイクル保存ルールを含む、ファイル・プラン定義手段
    をさらに含む、請求項８に記載のレコード管理エンジン。
11. 前記アプリケーション・プログラムが、前記管理されるレコードのそれぞれのレコード・プロファイルを維持し、前記受取手段が、前記関連するレコードの前記レコード・プロファイルを前記アプリケーション・プログラムから受け取り、前記関連するプロファイル・データについて前記レコード・プロファイルを解析するように構成される、請求項８ないし１０のいずれか一項に記載のレコード管理エンジン。
12. 前記受取手段が、前記ファイル・プラン・ノードのメニューを提供し、前記ノード・メニューのメニュー選択から前記関連するプロファイル・データを判定するように構成される、請求項８ないし１０のいずれか一項に記載のレコード管理エンジン。
13. 前記ファイル・プラン・ノードが、関連するレコードの前記ライフ・サイクル状態を識別するライフ・サイクル・コードと、前記関連するレコードが前記ライフ・サイクル状態の異なるライフ・サイクル状態の間で遷移しなければならないことを識別する中断状況フラグとを含み、前記判定手段が、前記ライフ・サイクル・コード、基準日付、および前記状況フラグの状態に対して前記保存ルールを評価するように構成される、請求項８ないし１０のいずれか一項に記載のレコード管理エンジン。
14. 前記ファイル・プランが、前記ファイル・プラン・ノードの階層配置を含み、前記ファイル・プラン・ノードの少なくとも１つが、ライフ・サイクル・コードを含まず、前記判定手段が、前記少なくとも１つのファイル・プラン・ノードの前記保存ルールを、前記少なくとも１つのファイル・プラン・ノードの親に関連する前記ライフ・サイクル・コードに対して評価するように構成される、請求項１３に記載のレコード管理エンジン。
15. 前記ファイル・プランが、前記ファイル・プラン・ノードの非階層配置を含み、前記ファイル・プラン・ノードの少なくとも１つが、ライフ・サイクル・コードを含まず、前記判定手段が、前記少なくとも１つのファイル・プラン・ノードの前記保存ルールを、前記少なくとも１つのファイル・プラン・ノードの親に関連する前記ライフ・サイクル・コードに対して評価するように構成される、請求項１３に記載のレコード管理エンジン。
16. ホスト・アプリケーション・プログラムによって管理されるレコードのライフ・サイクル・フェーズを管理するレコード・マネージャであって、前記レコード・マネージャが、ネットワークを介して前記ホスト・アプリケーション・プログラムと通信し、
    少なくとも１つのファイル・プラン・オブジェクトを含むファイル・プラン・データベースであって、各前記ファイル・プラン・オブジェクトが、ライフ・サイクル・ルールを有する、ファイル・プラン・データベースと、
    請求項８ないし１５のいずれか一項に記載のレコード管理エンジンと、
    前記レコード管理エンジンと通信するアプリケーション・プログラム・インターフェースであって、前記アプリケーション・プログラム・インターフェースが、前記ネットワークを介して、前記ライフ・サイクル・フェーズの変化の表示を前記ホスト・アプリケーション・プログラムに送るように構成される、アプリケーション・プログラム・インターフェースと
    を含む、レコード・マネージャ。
17. 前記ファイル・プラン・データベースが、ファイル・プラン・オブジェクトごとに、前記関連するレコードのレコード・タイプ・フィールドおよび前記プロファイル・データを定義する属性フィールドを含む、請求項１６に記載のレコード・マネージャ。
18. 前記ファイル・プラン・データベースが、前記ファイル・プラン・オブジェクトのサブセットを定義する少なくとも１つのファイル・プラン・ビュー・テーブル、および前記ファイル・プラン・オブジェクト・サブセットの前記ファイル・プラン・オブジェクトの間の関係を含む、請求項１６に記載のレコード・マネージャ。
19. 前記ファイル・プラン・データベースが、前記ファイル・プラン・オブジェクトの少なくとも１つの前記属性のサブセットを識別する少なくとも１つのカスタム・プロファイル・テーブル、および前記属性サブセットを表示することを許可される前記アプリケーション・プログラムの少なくとも１つのユーザを含む、請求項１６に記載のレコード・マネージャ。
20. 前記ファイル・プラン・データベースが、前記ファイル・プラン・オブジェクトの少なくとも１つのための少なくとも１つのアクセス動作を定義するアクセス制御リスト、および前記アクセス動作を実行することを許可される前記アプリケーション・プログラムの少なくとも１つのユーザを含む、請求項１６に記載のレコード・マネージャ。
21. 請求項１ないし７のいずれか一項に記載のステップを実行するように適合されたコンピュータ・プログラム・コード手段を含むコンピュータ・プログラム。

Images