(57)【要約】【課題】文書のライフサイクル間の関係を管理する。【解決手段】ライフサイクル定義ＤＢ２０は、文書が取り得る複数の状態と文書の状態遷移の条件とを定義するライフサイクル定義を記憶する。文書管理装置１０のライフサイクル定義処理部１２の生成登録部１２０は、ライフサイクル定義ＤＢ２０中の指定されたライフサイクル定義における複数の状態のうち少なくとも１つについて、当該状態に含まれる複数の下位状態を定義する情報と、これらの複数の下位状態の状態遷移条件を表す情報と、を生成する。さらに、生成登録部１２０は、指定されたライフサイクル定義に含まれる情報とともに生成した下位状態に関する情報を含む新たなライフサイクル定義を生成し、指定されたライフサイクル定義の下位ライフサイクル定義としてライフサイクル定義ＤＢ２０に登録する。【選択図】図１
2010061345.tif 000002
【特許請求の範囲】
【請求項１】
記憶手段に記憶された、電子文書が取り得る複数の状態を定義する情報と、電子文書の状態が前記複数の状態のうちの１つの状態から他の状態へ遷移する条件を定義する情報と、を含む文書状態定義情報を参照可能なコンピュータに、
前記記憶手段に記憶された第１の文書状態定義情報で定義される前記複数の状態のうち少なくとも１つについて、当該状態に含まれる複数の下位状態を定義する情報と、文書の状態が前記複数の下位状態のうちの１つの下位状態から他の１つの下位状態へ遷移する条件を定義する情報と、を生成し、当該生成した情報と、前記第１の文書状態定義情報に含まれる情報と、を含む第２の文書状態定義情報を生成する生成ステップと、
前記第２の文書状態定義情報と、前記第２の文書状態定義情報が前記第１の文書状態定義情報に対して下位の文書状態定義情報であることを示す情報と、を前記記憶手段に記憶させるステップと、
を実行させることを特徴とする文書管理プログラム。
【請求項２】
変更対象の文書状態定義情報と変更の内容とを特定した変更要求に応じて、前記変更対象の文書状態定義情報を前記記憶手段から取得し、前記変更要求で特定される変更の内容に基づいて、前記変更対象の文書状態定義情報における前記複数の状態の定義及び前記遷移する条件の少なくとも一部を変更する第１の変更ステップと、
前記変更対象の文書状態定義情報に対して下位の文書状態定義情報が前記記憶手段に記憶されている場合に、当該下位の文書状態定義情報について、前記第１の変更ステップにおける変更の内容に基づいて変更を行う第２の変更ステップと、
をさらに前記コンピュータに実行させることを特徴とする請求項１に記載の文書管理プログラム。
【請求項３】
前記文書状態定義情報に含まれる前記遷移する条件は、前記１つの状態から他の状態へ遷移する時期を表す条件であり、
前記第１の変更ステップにおいて、前記変更対象の文書状態定義情報における前記遷移する条件が表す時期を変更し、
前記第２の変更ステップにおいて、前記下位の文書状態定義情報における前記遷移する条件が表す時期を、前記第１の変更ステップにおける変更後の時期に変更する、
ことを特徴とする請求項２に記載の文書管理プログラム。
【請求項４】
前記第２の変更ステップにおいて、さらに、前記時期の変更に関連する状態が複数の下位状態を含む場合に、当該複数の下位状態のうちの１つの下位状態から他の１つの下位状態へ遷移する時期を変更する、
ことを特徴とする請求項３に記載の文書管理プログラム。
【請求項５】
前記文書状態定義情報に含まれる前記遷移する条件は、電子文書の属性情報に関する条件であり、
前記第１の変更ステップにおいて、前記変更対象の文書状態定義情報における前記遷移する条件が表す前記電子文書の属性情報に関する条件を変更し、
前記第２の変更ステップにおいて、前記下位の文書状態定義情報における前記遷移する条件が表す前記電子文書の属性情報の変化に関する条件を、前記第１の変更ステップにおける変更後の条件に変更する、
ことを特徴とする請求項２に記載の文書管理プログラム。
【請求項６】
前記第１の変更ステップにおいて、前記変更対象の文書状態定義情報に対して、電子文書が取り得る状態を追加し、追加した状態を定義する情報と追加した状態から他の状態へ遷移する条件を定義する情報とをさらに含む文書状態定義情報とする変更を行い、
前記第２の変更ステップにおいて、前記下位の文書状態定義情報に対して、前記第１の変更ステップにおいて前記変更対象の文書状態定義情報に対して追加された情報をさらに含む文書状態定義情報とする変更を行う、
ことを特徴とする請求項２に記載の文書管理プログラム。
【請求項７】
前記文書状態定義情報に含まれる前記複数の状態を定義する情報は、各状態における文書の利用権限を表す情報を含み、
前記記憶手段に記憶された文書状態定義情報のうちの１つに関連づけられた電子文書の利用要求に応じて、要求対象の電子文書に関連づけられた文書状態定義情報と、当該文書状態定義情報に対して前記記憶手段に記憶された複数の文書状態定義情報が構成する階層構造において上位に位置する文書状態定義情報と、を前記記憶手段から取得し、取得した文書状態定義情報それぞれにおける前記要求対象の電子文書の状態を特定する特定ステップと、
前記特定ステップにおいて特定された各状態における前記利用権限を参照して、前記要求対象文書の利用の可否を決定する決定ステップと、
をさらに前記コンピュータに実行させることを特徴とする請求項１から６のいずれか１項に記載の文書管理プログラム。
【請求項８】
記憶手段に記憶された、電子文書が取り得る複数の状態を定義する情報と、電子文書の状態が前記複数の状態のうちの１つの状態から他の状態へ遷移する条件を定義する情報と、を含む第１の文書状態定義情報を参照し、当該第１の文書状態定義情報で定義される前記複数の状態のうち少なくとも１つの状態について、当該状態に含まれる複数の下位状態を定義する情報と、文書の状態が前記複数の下位状態のうちの１つの下位状態から他の１つの下位状態へ遷移する条件を定義する情報と、を生成し、当該生成した情報と、前記第１の文書状態定義情報に含まれる情報と、を含む第２の文書状態定義情報を生成する生成手段と、
前記第２の文書状態定義情報と、前記第２の文書状態定義情報が前記第１の文書状態定義情報に対して下位の文書状態定義情報であることを示す情報と、を前記記憶手段に記憶させる手段と、
を備えることを特徴とする文書管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書管理プログラム及び文書管理装置に関する。
【背景技術】
【０００２】
文書の作成から廃棄までの間に文書が取り得る状態（例えば、作成、編集、公開、保管など）の遷移を文書の「ライフサイクル」として捉え、そのライフサイクルに従って文書を管理する技術がある。
【０００３】
例えば、特許文献１に記載の技術では、電子文書が印刷されて紙文書となり、その紙文書がスキャンされて電子文書になり、さらにその電子文書の複製の電子文書が生成されるなどの順で状態遷移するドキュメントのライフサイクルにおいて、各世代の文書に対するアクセス権を表すアクセス制限情報と、その文書の世代を表す世代情報と、を含む統合化文書を生成し、各世代におけるアクセス権を管理する。
【０００４】
【特許文献１】特開２００６−２６０４８１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、互いに関連する複数の電子文書が１つの共通のライフサイクルに従って管理されることがある。このように共通のライフサイクルに従って管理される複数の電子文書のうちの一部の電子文書について、その共通のライフサイクルに含まれる状態よりもきめ細かい状態を含むライフサイクルに従った管理が望まれることがある。
【０００６】
本発明の目的は、電子文書のライフサイクルを定義する情報とそのライフサイクルよりも詳細な状態を含むライフサイクルを定義する情報との間の関係を管理する文書管理プログラム及び文書管理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
請求項１に係る発明は、記憶手段に記憶された、電子文書が取り得る複数の状態を定義する情報と、電子文書の状態が前記複数の状態のうちの１つの状態から他の状態へ遷移する条件を定義する情報と、を含む文書状態定義情報を参照可能なコンピュータに、前記記憶手段に記憶された第１の文書状態定義情報で定義される前記複数の状態のうち少なくとも１つについて、当該状態に含まれる複数の下位状態を定義する情報と、文書の状態が前記複数の下位状態のうちの１つの下位状態から他の１つの下位状態へ遷移する条件を定義する情報と、を生成し、当該生成した情報と、前記第１の文書状態定義情報に含まれる情報と、を含む第２の文書状態定義情報を生成する生成ステップと、前記第２の文書状態定義情報と、前記第２の文書状態定義情報が前記第１の文書状態定義情報に対して下位の文書状態定義情報であることを示す情報と、を前記記憶手段に記憶させるステップと、を実行させることを特徴とする文書管理プログラムである。
【０００８】
請求項２に係る発明は、請求項１に係る発明において、変更対象の文書状態定義情報と変更の内容とを特定した変更要求に応じて、前記変更対象の文書状態定義情報を前記記憶手段から取得し、前記変更要求で特定される変更の内容に基づいて、前記変更対象の文書状態定義情報における前記複数の状態の定義及び前記遷移する条件の少なくとも一部を変更する第１の変更ステップと、前記変更対象の文書状態定義情報に対して下位の文書状態定義情報が前記記憶手段に記憶されている場合に、当該下位の文書状態定義情報について、前記第１の変更ステップにおける変更の内容に基づいて変更を行う第２の変更ステップと、をさらに前記コンピュータに実行させる。
【０００９】
請求項３に係る発明は、請求項２に係る発明において、前記文書状態定義情報に含まれる前記遷移する条件は、前記１つの状態から他の状態へ遷移する時期を表す条件であり、前記第１の変更ステップにおいて、前記変更対象の文書状態定義情報における前記遷移する条件が表す時期を変更し、前記第２の変更ステップにおいて、前記下位の文書状態定義情報における前記遷移する条件が表す時期を、前記第１の変更ステップにおける変更後の時期に変更する。
【００１０】
請求項４に係る発明は、請求項３に係る発明において、前記第２の変更ステップにおいて、さらに、前記時期の変更に関連する状態が複数の下位状態を含む場合に、当該複数の下位状態のうちの１つの下位状態から他の１つの下位状態へ遷移する時期を変更する。
【００１１】
請求項５に係る発明は、請求項２に係る発明において、前記文書状態定義情報に含まれる前記遷移する条件は、電子文書の属性情報に関する条件であり、前記第１の変更ステップにおいて、前記変更対象の文書状態定義情報における前記遷移する条件が表す前記電子文書の属性情報に関する条件を変更し、前記第２の変更ステップにおいて、前記下位の文書状態定義情報における前記遷移する条件が表す前記電子文書の属性情報の変化に関する条件を、前記第１の変更ステップにおける変更後の条件に変更する。
【００１２】
請求項６に係る発明は、請求項２に係る発明において、前記第１の変更ステップにおいて、前記変更対象の文書状態定義情報に対して、電子文書が取り得る状態を追加し、追加した状態を定義する情報と追加した状態から他の状態へ遷移する条件を定義する情報とをさらに含む文書状態定義情報とする変更を行い、前記第２の変更ステップにおいて、前記下位の文書状態定義情報に対して、前記第１の変更ステップにおいて前記変更対象の文書状態定義情報に対して追加された情報をさらに含む文書状態定義情報とする変更を行う。
【００１３】
請求項７に係る発明は、請求項１から６のいずれか１項に係る発明において、前記文書状態定義情報に含まれる前記複数の状態を定義する情報は、各状態における文書の利用権限を表す情報を含み、前記記憶手段に記憶された文書状態定義情報のうちの１つに関連づけられた電子文書の利用要求に応じて、要求対象の電子文書に関連づけられた文書状態定義情報と、当該文書状態定義情報に対して前記記憶手段中の複数の文書状態定義情報が構成する階層構造において上位に位置する文書状態定義情報と、を前記記憶手段から取得し、取得した文書状態定義情報それぞれにおける前記要求対象の電子文書の状態を特定する特定ステップと、前記特定ステップにおいて特定された各状態における前記利用権限を参照して、前記要求対象文書の利用の可否を決定する決定ステップと、をさらに前記コンピュータに実行させる。
【００１４】
請求項８に係る発明は、記憶手段に記憶された、電子文書が取り得る複数の状態を定義する情報と、電子文書の状態が前記複数の状態のうちの１つの状態から他の状態へ遷移する条件を定義する情報と、を含む第１の文書状態定義情報を参照し、当該第１の文書状態定義情報で定義される前記複数の状態のうち少なくとも１つの状態について、当該状態に含まれる複数の下位状態を定義する情報と、文書の状態が前記複数の下位状態のうちの１つの下位状態から他の１つの下位状態へ遷移する条件を定義する情報と、を生成し、当該生成した情報と、前記第１の文書状態定義情報に含まれる情報と、を含む第２の文書状態定義情報を生成する生成手段と、前記第２の文書状態定義情報と、前記第２の文書状態定義情報が前記第１の文書状態定義情報に対して下位の文書状態定義情報であることを示す情報と、を前記記憶手段に記憶させる手段と、を備えることを特徴とする文書管理装置である。
【発明の効果】
【００１５】
請求項１又は８に係る発明によると、電子文書のライフサイクルを定義する情報とそのライフサイクルよりも詳細な状態を含むライフサイクルを定義する情報との間の関係を管理できる。
【００１６】
請求項２に係る発明によると、文書状態定義情報を変更する場合に、当該文書状態定義情報の変更の内容と整合するように、当該文書状態定義情報の下位である文書状態定義情報を変更できる。
【００１７】
請求項３に係る発明によると、文書状態定義情報で表される電子文書の状態遷移の時期を変更する場合に、当該文書状態定義情報の下位である文書状態定義情報で表される文書の状態遷移の時期を、当該文書状態定義情報についての変更後の時期に変更できる。
【００１８】
請求項４に係る発明によると、文書状態定義情報で表される電子文書の状態遷移の時期を変更する場合に、当該文書状態定義情報の下位である文書状態定義情報に含まれる下位状態についてさらに状態遷移の時期を変更できる。
【００１９】
請求項５に係る発明によると、文書状態定義情報で表される電子文書の属性情報に関する条件を変更する場合に、当該文書状態定義情報の下位である文書状態定義情報で表される電子文書の属性情報に関する条件を、当該文書状態定義情報についての変更後の条件に変更できる。
【００２０】
請求項６に係る発明によると、文書状態定義情報が表すライフサイクルにおいて電子文書の状態が追加された場合に、当該文書状態定義情報の下位である文書状態定義情報について、上述の追加された状態を含むライフサイクルを表すように変更できる。
【００２１】
請求項７に係る発明によると、文書状態定義情報に関連づけられた電子文書について、その電子文書に関連づけられた文書状態定義情報で表される利用権限とともに当該文書状態定義情報に対して上位の文書状態定義情報で表される利用権限を参照して、その電子文書の利用の可否を決定できる。
【発明を実施するための最良の形態】
【００２２】
図１に、本発明の１つの実施形態の文書管理装置１０の構成の例を示す。文書管理装置１０は、ライフサイクル定義ＤＢ（データベース）２０及びユーザ情報ＤＢ４０を参照し、文書ＤＢ３０に格納された文書を管理する。文書管理装置１０は、ライフサイクル定義処理部１２及び文書処理部１４を備える。
【００２３】
ライフサイクル定義処理部１２は、ライフサイクル定義ＤＢ２０に格納されるデータに関する処理を実行する。ライフサイクル定義ＤＢ２０は、文書のライフサイクルを定義する情報（以下、「ライフサイクル定義」と呼ぶ）を格納するデータベースである。ライフサイクル定義は、文書のライフサイクルにおいて文書が取り得る状態を定義する情報と、文書の状態が１つの状態から他の状態へ遷移する条件を定義する情報と、を含む。
【００２４】
図２を参照し、本実施形態におけるライフサイクル定義の例を説明する。図２は、ライフサイクル定義ＤＢ２０のデータ内容の一例を示す。図２の例の表のレコードｒ１，ｒ２，ｒ３，ｒ４のそれぞれは、１つのライフサイクル定義の内容を表す情報レコードである。図２の例のライフサイクル定義ＤＢ２０には、ライフサイクル定義ＩＤ（識別子）に関連づけて、ライフサイクル定義名、状態、アクセス権、状態遷移条件、管理者、及び上位ライフサイクル定義ＩＤの各項目が登録されている。
【００２５】
ライフサイクル定義ＩＤは、ライフサイクル定義ＤＢ２０中で一意なライフサイクル定義の識別情報である。ライフサイクル定義名は、そのライフサイクル定義に対して付与された名称である。ライフサイクル定義名は、例えば、そのライフサイクル定義の登録を指示したユーザが付与する。あるいは、例えば、ライフサイクル定義処理部１２がライフサイクル定義をライフサイクル定義ＤＢ２０に登録するときに、予め設定された規則に従って自動的にライフサイクル定義名を付与してもよい。
【００２６】
状態は、当該ライフサイクル定義が表す文書のライフサイクルにおいて文書が取り得る状態を表す。例えば、図２の例の表において、ライフサイクル定義ＩＤ：ＬＳ１の「状態」の項目には、“作成”、“レビュー”、“公開”、及び“保管”の各状態が登録されている。これは、ライフサイクル定義ＩＤ：ＬＳ１のライフサイクル定義が表すライフサイクルにおいて、文書が“作成”、“レビュー”、“公開”、及び“保管”のいずれかの状態を取り得ることを表す。さらに、図２の例の表における「状態」の項目は、文書の状態遷移の順番を表す。図２の例では、１つのライフサイクル定義に対応するレコードの「状態」の項目において、上方の行に記載された状態から下方の行に記載された状態の順に、文書の状態が遷移するものとする。
【００２７】
アクセス権は、文書のライフサイクルにおける各状態と対応づけて設定され、その状態の文書に対する利用権限を表す。アクセス権は、例えば、文書に対する操作の種類（閲覧、更新、印刷、削除など）と、その種類の操作の実行を許可されたユーザ又はグループの識別情報と、の組によって表される。
【００２８】
状態遷移条件は、文書のライフサイクルにおいて文書の状態が１つの状態から他の状態へ遷移する条件である。図２の例の表では、状態遷移条件の項目には、各状態に対応づけて、当該状態から次の状態へ遷移する日付が登録されている。例えば、ライフサイクル定義ＬＳ１の“作成”状態に対応づけられた状態遷移条件「2008/6/15」は、２００８年６月１５日になると、文書の状態が“作成”から“レビュー”へ遷移することを表す。以下の説明では、第１の状態から第２の状態へ遷移する日付を第１の状態の「期日」と呼ぶこともある。例えば、「ライフサイクル定義ＬＳ１の“作成”状態の期日は2008/6/15である」と言うことがある。なお、図２の例の表のライフサイクル定義ＬＳ１において文書が最後に取る状態“保管”に対応づけられた状態遷移条件「2008/12/31」は、その文書が廃棄される日付を表すものとする。また、図２の例では、状態遷移条件は、第１の状態から第２の状態へ遷移する日付を表すが、日付に加えて時刻も表す状態遷移条件を設定してもよい。
【００２９】
管理者の項目には、対応するライフサイクル定義の管理者であるユーザの識別情報が登録される。ここで、ライフサイクル定義の管理者とは、そのライフサイクル定義に対して変更を加える権限を有するユーザを表す。例えば、ライフサイクル定義の登録を指示したユーザが当該ライフサイクル定義の管理者として設定される。
【００３０】
なお、本実施形態において、ライフサイクル定義は、他のライフサイクル定義に含まれる状態及び状態遷移条件を含むとともに、その状態の少なくとも一部について、より詳細な状態を表す下位状態を含む場合がある。以下の説明では、このようなライフサイクル定義を、当該他のライフサイクル定義に対して「下位」のライフサイクル定義であると言う。逆に、当該他のライフサイクル定義を、その下位のライフサイクル定義に対して「上位」のライフサイクル定義であると言う。図２の例のライフサイクル定義ＤＢ２０において、上位ライフサイクル定義ＩＤの項目には、対応するレコードのライフサイクル定義に対して上位のライフサイクル定義のライフサイクル定義ＩＤが登録される。図２の例では、ライフサイクル定義ＬＳ１は、ライフサイクル定義ＬＳ２，ＬＳ４に対して上位であり、ライフサイクル定義ＬＳ２は、ライフサイクル定義ＬＳ３に対して上位である。
【００３１】
さらに図３を参照し、本実施形態におけるライフサイクル定義間の上位／下位の関係の例を説明する。図３は、ライフサイクル定義ＤＢ２０が図２の例のデータ内容を有する場合の、ライフサイクル定義ＤＢ２０中の各ライフサイクル定義を図式的に表す図である。図３に示すように、互いに上位／下位の関係にある複数のライフサイクル定義は階層構造を成す。なお、図２の例の表における上位ライフサイクル定義の項目は、対応するレコードのライフサイクル定義に対し、図３に例示するようなライフサイクル定義の階層構造において直接の上位に位置するライフサイクル定義のＩＤを表すものである。以下の説明では、「上位ライフサイクル定義」の用語は、あるライフサイクル定義に対して階層構造において直接の上位に位置するライフサイクル定義を表す。また、「下位ライフサイクル定義」の用語は、あるライフサイクル定義に対して階層構造において直接の下位に位置するライフサイクル定義を表す。
【００３２】
図２及び図３を参照すると、ライフサイクル定義ＬＳ１「製品Ａ仕様書用」は、上位ライフサイクル定義を有しない。一方、「製品Ａ仕様書用」は、ライフサイクル定義ＬＳ２「コンポーネントＡ仕様書用」及びライフサイクル定義ＬＳ４「コンポーネントＢ仕様書用」の上位ライフサイクル定義である。「コンポーネントＡ仕様書用」及び「コンポーネントＢ仕様書用」は、「製品Ａ仕様書用」に含まれる状態（“作成”、“レビュー”、“公開”、及び“保管”）と同様の状態及び状態遷移条件を含むが、“作成”状態について、それぞれ独自の下位状態及び下位状態の状態遷移条件を有する。具体的には、「コンポーネントＡ仕様書用」において、“作成”状態の下位状態として“草案作成”及び“修正”を含み、“草案作成”状態から“修正”状態へ遷移する状態遷移条件（期日）は「2008/5/1」に設定されている。また、「コンポーネントＢ仕様書用」において、“作成”状態の下位状態は“前半作成”及び“後半作成”であり、“前半作成”状態から“後半作成”状態へ遷移する状態遷移条件（期日）は「2008/5/10」である。なお、「コンポーネントＡ仕様書用」における“修正”状態の期日及び「コンポーネントＢ仕様書用」における“後半作成”状態の期日は、上位ライフサイクル定義「製品Ａ仕様書用」における“作成”状態の期日「2008/6/15」と同じ日付に設定される。このように、下位ライフサイクル定義は、その上位ライフサイクル定義の状態及び状態遷移条件をそのまま継承した上で、その状態のうちの少なくとも一部の下位状態を含むものである。
【００３３】
また、ライフサイクル定義ＬＳ３「部品Ａ仕様書用」は、「コンポーネントＡ仕様書用」の下位ライフサイクル定義である。「部品Ａ仕様書用」は、「コンポーネントＡ仕様書用」と同様の状態（“草案作成”、“修正”、“レビュー”、“公開”、及び“保管”）及び状態遷移条件を含み、さらに、“修正”状態の下位状態として“本人修正”及び“上長修正”を含む。「部品Ａ仕様書用」は、「コンポーネントＡ仕様書用」の下位ライフサイクル定義であるとともに、「コンポーネントＡ仕様書用」の上位ライフサイクル定義である「製品Ａ仕様書用」に対しても下位のライフサイクル定義であると言える。
【００３４】
なお、図３には、各ライフサイクル定義に従って管理される文書（関連づけ文書）の例も示す。例えば、文書Ｄｏｃ１，Ｄｏｃ２は、ライフサイクル定義「コンポーネントＡ仕様書用」に関連づけられ、文書Ｄｏｃ１４は、ライフサイクル定義「部品Ａ仕様書用」に関連づけられ、文書Ｄｏｃ２１は、ライフサイクル定義「コンポーネントＢ仕様書用」に関連づけられる。「コンポーネントＡ仕様書用」、「部品Ａ仕様書用」、及び「コンポーネントＢ仕様書用」は、互いに異なるライフサイクル定義ではあるが、すべて、「製品Ａ仕様書用」に対して下位のライフサイクル定義である。したがって、これら３つのライフサイクル定義は、それぞれ、「製品Ａ仕様書用」と同様の状態及び状態遷移条件を含む。このため、これら３つのライフサイクル定義のそれぞれに関連づけられる文書は、関連づけられた各ライフサイクル定義で定義されるライフサイクルに従って状態遷移するとともに、上位のライフサイクル定義「製品Ａ仕様書用」で定義されるライフサイクルに従って状態遷移することにもなる。
【００３５】
なお、図２の例の表は、ライフサイクル定義ＤＢ２０のデータ内容の一例にすぎない。各項目に設定される値の表現の態様は図２に例示する態様に限られないし、登録される項目も図２の表に例示する項目に限られない。ライフサイクル定義ＤＢ２０には、少なくとも、ライフサイクル定義の識別情報、ライフサイクルに含まれる状態を定義する情報、状態遷移の条件を定義する情報、及びライフサイクル定義間の上位／下位の関係を表す情報を登録しておけばよい。また例えば、ライフサイクル定義が登録又は変更された日時など、管理目的上必要な項目があれば図２の例の表の各項目と異なる項目を登録してもよい。
【００３６】
図１の説明に戻り、ライフサイクル定義処理部１２は、生成登録部１２０及び変更部１２２を備える。生成登録部１２０は、ユーザの指示に従ってライフサイクル定義を生成してライフサイクル定義ＤＢ２０に登録する。例えば、生成登録部１２０は、他のライフサイクル定義に対して下位でない新規なライフサイクル定義を生成してライフサイクル定義ＤＢ２０に登録する。このとき、対応するライフサイクル定義ＤＢ２０のレコードの上位ライフサイクル定義ＩＤの項目は「Ｎｕｌｌ（なし）」に設定される。また例えば、生成登録部１２０は、ライフサイクル定義ＤＢ２０に登録済みのライフサイクル定義を基に、このライフサイクル定義に含まれる状態の一部を複数の下位状態に置換したライフサイクル定義、すなわち下位ライフサイクル定義を生成し、ライフサイクル定義ＤＢ２０に登録することもある。このとき、生成登録部１２０は、生成した下位ライフサイクル定義に対応するライフサイクル定義ＤＢ２０のレコードにおいて、上位ライフサイクル定義ＩＤの項目に前述の登録済みのライフサイクル定義のＩＤを設定する。
【００３７】
変更部１２２は、ユーザの指示に従って、ライフサイクル定義ＤＢ２０に登録済みのライフサイクル定義に対して変更を加える。変更対象のライフサイクル定義が下位ライフサイクル定義を有する場合、変更部１２２は、さらに、下位ライフサイクル定義に対して、変更対象のライフサイクル定義に対して加えた変更と整合性を保つように変更を加える。
【００３８】
文書処理部１４は、文書ＤＢ３０に格納された文書に対し、ライフサイクル定義ＤＢ２０に格納されたライフサイクル定義に従った処理を行う。文書処理部１４は、ライフサイクル制御部１４０を備える。ライフサイクル制御部１４０は、処理対象の文書のライフサイクルに関する処理を行う。例えば、ライフサイクル制御部１４０は、処理対象の文書に関連づけられたライフサイクル定義をライフサイクル定義ＤＢ２０から取得し、取得したライフサイクル定義における処理対象の文書の状態を特定する。そして、処理対象の文書について、その状態に応じた処理を行う。例えば、ライフサイクル定義ＤＢ２０が図２に例示する表のデータ内容を有する場合、文書処理部１４は、特定した文書の状態に対応づけられたアクセス権に従って、文書に対する処理の実行の可否を決定する。
【００３９】
文書ＤＢ３０は、電子文書ファイルを格納するデータベースであり、一般的なファイルシステムによって構成されるものであってよい。また、本実施形態では、文書ＤＢ３０は、各文書と当該文書の属性情報とを関連づける文書属性テーブルを記憶する。図４は、文書ＤＢ３０に記憶される文書属性テーブルの一例を示す図である。図４の例の文書属性テーブルでは、各文書の文書ＩＤに対応づけて、各文書の属性情報である文書属性が登録される。文書ＩＤは、文書管理装置１０の管理対象である各文書に一意な識別情報である。図４の例では、文書属性として、ライフサイクル定義ＩＤ及びファイルパス名の各項目が登録されている。ライフサイクル定義ＩＤの項目には、その文書に関連づけられたライフサイクル定義のライフサイクル定義ＩＤが登録される。各文書は、当該文書に関連づけられたライフサイクル定義に従って管理される。ファイルパス名は、その文書の電子ファイルの文書ＤＢ３０における格納位置を表す。なお、図４の例の表中のライフサイクル定義ＩＤの値は、図２及び図３に例示する各ライフサイクル定義のライフサイクル定義ＩＤを表す。
【００４０】
ユーザ情報ＤＢ４０は、文書ＤＢ３０中の文書を利用するユーザとして予め登録されたユーザの情報を格納するデータベースである。ユーザ情報ＤＢ４０は、例えば、各ユーザの識別情報に関連づけて、そのユーザの名前やパスワードなどを記憶する。また、ユーザ情報ＤＢ４０は、ユーザのグループに関する情報を記憶する。例えば、ユーザ情報ＤＢ４０は、各グループの識別情報に関連づけて、当該グループに所属するユーザの識別情報を記憶する。文書処理部１４は、ユーザ情報ＤＢ４０を参照して文書に対するアクセスの可否を決定する。例えば、特定のユーザグループに対してある処理の実行を許可するアクセス権が設定されている場合、文書処理部１４は、ユーザ情報ＤＢ４０を参照し、文書の処理要求を行ったユーザが当該グループに所属するか否かを判定して処理の実行の可否を決定する。
【００４１】
なお、ライフサイクル定義ＤＢ２０、ユーザ情報ＤＢ４０、及び文書ＤＢ３０の各データベースは、文書管理装置１０が備えていてもよいし、文書管理装置１０とネットワークを介して接続される他の情報処理装置が備えていてもよい。
【００４２】
以下、文書管理装置１０で行われる処理の例を説明する。
【００４３】
図５は、ライフサイクル定義処理部１２の生成登録部１２０が行うライフサイクル定義登録処理の手順の例を示すフローチャートである。生成登録部１２０は、例えば、図示しない入力装置を介してユーザからライフサイクル定義の登録要求を受けた場合に、図５に例示する手順の処理を開始する。
【００４４】
図５を参照し、まず、生成登録部１２０は、ユーザからの登録要求が、ライフサイクル定義ＤＢ２０に登録済みのライフサイクル定義の下位ライフサイクル定義の登録を要求するものであるか否かを判定する（ステップＳ１０）。
【００４５】
下位ライフサイクル定義の登録要求でない場合（ステップＳ１０でＮＯ）、生成登録部１２０は、新規なライフサイクル定義の内容を特定する情報の入力を受け付け、受け付けた入力情報に従って新規なライフサイクル定義を生成し、ライフサイクル定義ＤＢ２０に登録する（ステップＳ２０）。ステップＳ２０では、生成登録部１２０は、ライフサイクル定義の内容を特定する情報として、例えば、図２の例の表の「ライフサイクル定義名」、「状態」、「アクセス権」、及び「状態遷移条件」の各項目の内容を特定する情報の入力を受け付ける。そして、ライフサイクル定義ＤＢ２０において、受け付けた入力情報が表す各項目の値を含むレコードを新たに生成する。さらに、生成登録部１２０は、新たに生成したライフサイクル定義に対して新たなライフサイクル定義ＩＤを付与し、対応するライフサイクル定義ＤＢ２０のレコードのライフサイクル定義ＩＤの項目の値として設定する。ここでは、上位ライフサイクル定義ＩＤの項目の値は「Ｎｕｌｌ」に設定される。他のライフサイクル定義に対して下位でない新規なライフサイクル定義の登録であるからである。管理者の項目の値は、登録要求を行ったユーザの識別情報を設定する。ステップＳ２０の後、図５の例の手順の処理は終了する。
【００４６】
一方、登録要求が下位ライフサイクル定義の登録要求である場合（ステップＳ１０でＹＥＳ）、生成登録部１２０は、登録済みのライフサイクル定義のＩＤの指定を受け付け、当該指定されたＩＤのライフサイクル定義をライフサイクル定義ＤＢ２０から取得する（ステップＳ１２）。次に、取得したライフサイクル定義に含まれる状態のうちの１つの指定を受け付け、当該指定された状態に含まれる下位状態を生成する（ステップＳ１４）。この下位状態の内容を特定する情報は、図示しない入力装置を介したユーザの入力から取得される。例えば、生成登録部１２０は、下位状態の数、各下位状態の名称、各下位状態に対応づけられるアクセス権、及び下位状態間の状態遷移条件の入力を受け付ける。
【００４７】
指定された状態について下位状態を生成すると、生成登録部１２０は、ステップＳ１２で取得したライフサイクル定義に含まれる他の状態について下位状態を生成するか否かを判定する（ステップＳ１６）。この判定は、例えば、他の状態について下位状態の生成を指示するユーザ入力を受け付けたか否かによって行う。
【００４８】
他の状態について下位状態の生成を行う場合（ステップＳ１６でＹＥＳ）、当該他の状態について下位状態を生成し（ステップＳ１４）、再びステップＳ１６の判定を行う。
【００４９】
他の状態について下位状態の生成を行わない場合（ステップＳ１６でＮＯ）、生成登録部１２０は、ステップＳ１４で生成した下位状態についての情報を含む下位ライフサイクル定義に対応するレコードをライフサイクル定義ＤＢ２０に登録する（ステップＳ１８）。ここで、例えば、生成登録部１２０は、ステップＳ１２で指定されたライフサイクル定義の状態、アクセス権、及び状態遷移条件を複製した上で、その状態のうちステップＳ１４で下位状態を生成した状態について、生成した下位状態で置換したライフサイクル定義のレコードを生成する。そして、新たなライフサイクル定義ＩＤを付与してこのレコードをライフサイクル定義ＤＢ２０に登録する。このレコードの上位ライフサイクル定義ＩＤの項目には、ステップＳ１２で指定されたライフサイクル定義のライフサイクル定義ＩＤが設定される。ステップＳ１８が終了すると、図５の例の手順の処理は終了する。
【００５０】
図２の例のラフサイクル定義ＤＢは、各ライフサイクル定義の管理者による登録要求に応じて、ライフサイクル定義処理部１２の生成登録部１２０が図５の例の手順の処理を行うことで構築される。例えば、図２の例では、まず、製品Ａの仕様書の作成に係るプロジェクトのリーダーであるuser1による「製品Ａ仕様書用」のライフサイクル定義の登録要求に応じて図５の例の手順の処理が実行され、ライフサイクル定義ＤＢ２０にライフサイクル定義ＩＤ：ＬＳ１のレコードが登録される。その後、製品Ａの仕様書のうちコンポーネントＡ及びコンポーネントＢそれぞれの仕様書の作成に携わるユーザグループの各リーダーuser2，user4による下位ライフサイクル定義の登録要求に応じた図５の例の手順の処理により、「製品Ａ仕様書用」の下位ライフサイクル定義「コンポーネントＡ仕様書用」及び「コンポーネントＢ仕様書用」がそれぞれライフサイクル定義ＤＢ２０に登録される。また、コンポーネントＡに含まれる部品Ａの仕様書を作成するユーザグループのリーダーuser3の登録要求に応じた図５の例の手順の処理により、「コンポーネントＡ仕様書用」の下位ライフサイクル定義「部品Ａ仕様書用」が登録される。
【００５１】
上述のようにライフサイクル定義ＤＢ２０へライフサイクル定義が登録されると、文書管理装置１０の文書処理部１４は、ユーザの文書生成要求に従って、各ライフサイクル定義に従って管理される文書を生成する。そして、生成した文書ファイルを文書ＤＢ３０に登録するとともに、文書ＤＢ３０の文書属性テーブル（図４参照）に、生成した文書の文書属性を登録する。この文書属性は、ユーザの文書生成要求で特定されたライフサイクル定義ＩＤを含む。例えば、コンポーネントＡの仕様書の作成を担当するユーザが、ライフサイクル定義「コンポーネントＡ仕様書用」を指定し、これに従う文書の新規作成を要求すると、この要求に従って文書処理部１４は、文書「Ｄｏｃ１」を新規に生成して文書ＤＢ３０に登録する。このとき、文書処理部１４は、文書ＤＢ３０の文書属性テーブル（図４参照）において、新規作成した文書の文書ＩＤ：Ｄｏｃ１と関連づけて、指定されたライフサイクル定義「コンポーネントＡ仕様書用」のライフサイクル定義ＩＤを含む文書属性を登録する。
【００５２】
以下、図６を参照し、ライフサイクル定義と関連づけられた文書について文書処理部１４が行う処理の例を説明する。以下の説明では、図２の例のデータ内容がライフサイクル定義ＤＢ２０に登録され、図４の例の文書属性テーブルが文書ＤＢ３０に登録されているとする。
【００５３】
文書処理部１４は、例えば、文書管理装置１０が、図示しない入力装置を介して、要求対象の文書の文書ＩＤ及び処理の内容を特定する文書処理要求をユーザから受けた場合に、図６の例の手順の処理を開始する。
【００５４】
まず、文書処理部１４のライフサイクル制御部１４０は、文書ＤＢ３０の文書属性テーブルを参照し、要求対象の文書の文書ＩＤに関連づけられたライフサイクル定義ＩＤを注目ライフサイクル定義ＩＤとする（ステップＳ３０）。次に、ライフサイクル制御部１４０は、注目ライフサイクル定義ＩＤのレコードをライフサイクル定義ＤＢ２０から取得し（ステップＳ３２）、取得したレコードをライフサイクル定義リストに追加する（ステップＳ３４）。ライフサイクル定義リストは、後の処理で用いるライフサイクル定義を一時的に保存しておくリストである。次に、注目ライフサイクル定義ＩＤのライフサイクル定義が上位ライフサイクル定義を有するか否かを判定する（ステップＳ３６）。この判定は、例えば、ステップＳ３２で取得したレコードの上位ライフサイクル定義ＩＤの項目に「Ｎｕｌｌ」でない値が設定されているか否かによって行う。上位ライフサイクル定義が存在する場合（ステップＳ３６でＹＥＳ）、上位ライフサイクル定義ＩＤを新たな注目ライフサイクル定義ＩＤとし（ステップＳ４６）、ステップＳ３２以下の処理を繰り返す。
【００５５】
ステップＳ３２，Ｓ３４，Ｓ３６，Ｓ４６を含むループ処理により、要求対象の文書に関連づけられたライフサイクル定義を起点として、ライフサイクル定義が構成する階層構造を最上位階層まで遡った経路上に含まれるライフサイクル定義がライフサイクル定義リストに保存される。例えば、図２の例のライフサイクル定義ＤＢ２０中のライフサイクル定義ＬＳ３「部品Ａ仕様書用」に関連づけられている文書「Ｄｏｃ１４」（図４参照）が要求対象の文書である場合、当該ループ処理によって、「部品Ａ仕様書用」を起点として図３に例示するライフサイクル定義の階層構造を最上位階層の「製品Ａ仕様書用」まで遡り、ライフサイクル定義リストには、「部品Ａ仕様書用」、「コンポーネントＡ仕様書用」、及び「製品Ａ仕様書用」の３つのライフサイクル定義が保存される。
【００５６】
図６のフローチャートの説明に戻り、注目ライフサイクル定義ＩＤのライフサイクル定義の上位ライフサイクル定義が存在しない場合（ステップＳ３６でＮＯ）、処理はステップＳ３８に進む。この時点で、ライフサイクル定義リストには、要求対象の文書に関連づけられたライフサイクル定義と、そのライフサイクル定義に対して直系の上位に相当するすべてのライフサイクル定義と、が含まれている。ステップＳ３８では、ライフサイクル制御部１４０は、ライフサイクル定義リスト中の各ライフサイクル定義における要求対象の文書の状態を特定する。例えば、リスト中のライフサイクル定義の状態遷移条件を参照して当該ライフサイクル定義における各状態の期日を取得し、現在の日時と比較することで、要求対象の文書の状態を特定する。
【００５７】
要求対象の文書が文書「Ｄｏｃ１４」である上述の例の場合のステップＳ３８の処理の具体例を説明する。例えば現在の日時が2008/5/7であるとき、これを要求対象の文書に関連づけられたライフサイクル定義「部品Ａ仕様書用」の各状態の期日と比較すると、“草案作成”状態の期日「2008/5/1」の後であって“本人修正”状態の期日「2008/5/15」の前である。このとき、ライフサイクル制御部１４０は、要求対象の文書「Ｄｏｃ１４」のライフサイクル定義「部品Ａ仕様書用」における状態は“本人修正”状態であると特定する。さらに、ライフサイクル制御部１４０は、リスト中の他のライフサイクル定義「コンポーネントＡ仕様書用」、及び「製品Ａ仕様書用」における要求対象の文書の状態を特定する。「部品Ａ仕様書用」における“本人修正”状態は、上位ライフサイクル定義「コンポーネントＡ仕様書用」における“修正”状態の下位状態であり、この“修正”状態は、さらなる上位ライフサイクル定義「製品Ａ仕様書用」における“作成”状態の下位状態である。よって、ライフサイクル制御部１４０は、要求対象の文書「Ｄｏｃ１４」の「コンポーネントＡ仕様書用」における状態は“修正”状態であり、「製品Ａ仕様書用」における状態は“作成”状態であると特定する。
【００５８】
ステップＳ３８の後、特定した各状態に対応づけられたアクセス権の論理積を求める（ステップＳ４０）。そして、求めたアクセス権の論理積において、処理要求を行ったユーザに対して要求された処理の実行が許可されているか否かを判定する（ステップＳ４２）。許可されていれば（ステップＳ４２でＹＥＳ）、文書処理部１４は、要求対象の文書に対して要求された処理を実行する（ステップＳ４４）。許可されていなければ（ステップＳ４２でＮＯ）、要求された処理は実行が許可されていないことを示す情報を出力する（ステップＳ４８）。ステップＳ４８では、例えば、処理の実行不可を示す情報を図示しない表示装置に表示させる。
【００５９】
ステップＳ４４又はステップＳ４８の後、図６に例示する手順の処理は終了する。
【００６０】
図６の例の手順の処理によると、要求対象の文書に関連づけられたライフサイクル定義自体だけでなく、その上位のライフサイクル定義において設定されたアクセス権も参照して、処理の実行の可否が決定される。また、アクセス権の論理積に基づいて処理の実行の可否を決定するため、例えば、要求対象の文書に関連づけられたライフサイクル定義における状態のアクセス権では、処理要求を行ったユーザに対して許可されている処理であっても、その上位のライフサイクル定義において許可されていなければ、当該処理の実行は許可されない。言い換えると、図６の例の手順では、上位のライフサイクル定義におけるアクセス権の範囲を超えるアクセス権が下位のライフサイクル定義において設定されている場合でも、上位のライフサイクル定義におけるアクセス権の範囲内でしか処理の実行は許可されない。
【００６１】
以上、ライフサイクル定義の登録処理及び登録されたライフサイクル定義に従った文書の処理の例を説明した。以下、登録済みのライフサイクル定義に対する変更処理の例を説明する。
【００６２】
図７は、ライフサイクル定義処理部１２の変更部１２２が行うライフサイクル定義変更処理の手順の例を表すフローチャートである。変更部１２２は、例えば、図示しない入力装置を介して、変更対象のライフサイクル定義のライフサイクル定義ＩＤを特定する変更要求をユーザから文書管理装置１０が受け付けた場合に、図７の例の手順の処理を開始する。
【００６３】
図７を参照し、まず、変更部１２２は、変更要求で特定された変更対象のライフサイクル定義をライフサイクル定義ＤＢ２０から取得する（ステップＳ７０）。次に、変更部１２２は、変更対象のライフサイクル定義の内容を変更する（ステップＳ７２）。ステップＳ７２の処理の詳細は後述する。
【００６４】
変更対象のライフサイクル定義の内容を変更すると、変更部１２２は、変更後のライフサイクル定義の内容をライフサイクル定義ＤＢ２０に上書き保存する（ステップＳ７４）。つまり、ライフサイクル定義ＤＢ２０において、変更対象のライフサイクル定義に対応するレコードの内容を変更後の内容に書き換える。その後、ライフサイクル定義の階層構造において変更対象のライフサイクル定義に対して直近の下位にあるライフサイクル定義を検索する（ステップＳ７６）。この検索は、例えば、変更対象のライフサイクル定義のライフサイクル定義ＩＤの値を上位ライフサイクル定義ＩＤの項目の値として有するレコードをライフサイクル定義ＤＢ２０から抽出することで行う。
【００６５】
ステップＳ７６の検索の結果、変更対象のライフサイクル定義に直近の下位のライフサイクル定義が存在する場合、変更部１２２は、検索結果の下位ライフサイクル定義のうちの１つを新たな変更対象とする（ステップＳ７８，Ｓ８０）。そして、この新たな変更対象のライフサイクル定義について図７の例の手順の処理を再帰的に呼び出して実行する（ステップＳ８２）。ステップＳ８２の後、変更部１２２は、ステップＳ７６の検索結果の下位ライフサイクル定義のすべてについて処理済みであるか否かを判定する（ステップＳ８４）。未処理の下位ライフサイクル定義があれば（ステップＳ８４でＮＯ）、未処理の下位ライフサイクル定義のうちから１つを新たな変更対象とし（ステップＳ８０）、ステップＳ８２以下の処理を繰り返す。
【００６６】
ステップＳ７６の検索結果の下位ライフサイクル定義のすべてについて処理済みである場合（ステップＳ８４でＹＥＳ）、あるいは、ステップＳ７６の検索において下位ライフサイクル定義が存在しない場合（ステップＳ７８でＮＯ）、変更部１２２は、図７の例の手順の処理を終了する。
【００６７】
図７の例の手順の処理では、ステップＳ８２の再帰処理により、１つのライフサイクル定義に対して変更が加えられると、そのライフサイクル定義に対して直系の下位であるすべてのライフサイクル定義に対しても変更が加えられる。
【００６８】
図８に、図７のステップＳ７２の詳細手順の例を示す。
【００６９】
図８を参照し、図７のステップＳ７２が開始されると、まず、変更部１２２は、変更対象のライフサイクル定義がユーザからの変更要求で特定されたものであるか否かを判定する（ステップＳ７２０）。ユーザからの変更要求で特定されたものであれば（ステップＳ７２０でＹＥＳ）、ユーザからの指示に従って、変更対象のライフサイクル定義の内容を変更する（ステップＳ７２２）。ユーザからの変更要求で特定されたものでなければ（ステップＳ７２０でＮＯ）、現在の変更対象のライフサイクル定義は、図７のステップＳ８０で新たに設定された変更対象である。このとき、ステップＳ７２４で、変更部１２２は、現在の変更対象のライフサイクル定義の上位ライフサイクル定義に対して行われた変更内容に従って、変更対象のライフサイクル定義の内容を変更する。ステップＳ７２４では、変更部１２２は、上位ライフサイクル定義の変更の内容と整合するように、ライフサイクル定義の変更を行う。ステップＳ７２２又はステップＳ７２４の後、処理は図７のステップＳ７４へ進む。
【００７０】
図７及び図８に例示するライフサイクル定義変更処理により、下位ライフサイクル定義を有するライフサイクル定義が変更されると、その変更の内容と整合するように、下位ライフサイクル定義が自動的に変更される。
【００７１】
なお、変更部１２２は、図７の例の手順の処理の実行を開始する前に、変更要求を行ったユーザが変更対象のライフサイクル定義の管理者であるか否かを判定し、管理者である場合にのみ図７の例の手順の処理を開始してもよい。
【００７２】
図９及び図１０を参照し、ライフサイクル定義変更処理の具体例を説明する。図９及び図１０を参照する以下の説明では、図２の例のデータ内容がライフサイクル定義ＤＢ２０に登録されているとする。
【００７３】
まず、図９を参照し、図２の例のライフサイクル定義ＬＳ２「コンポーネントＡ仕様書用」を変更対象として、ユーザが図示しない入力装置を用いてライフサイクル定義の変更要求を行った場合の具体例を説明する。変更部１２２は、まず、図７の例の手順の処理を開始してライフサイクル定義ＬＳ２のレコードｒ２（図２参照）をライフサイクル定義ＤＢ２０から取得する（ステップＳ７０）。この変更対象のライフサイクル定義ＬＳ２は、ユーザによる変更要求で特定されたものであることから、変更部１２２は、当該ユーザの指示に従ってその内容を変更する（図７のステップＳ７２、図８のステップＳ７２０，Ｓ７２２）。本例では、ライフサイクル定義ＬＳ２において、“草案作成”状態の期日（状態遷移条件）を「2008/5/1」から「2008/5/20」に変更することを、ユーザが図示しない入力装置を介して指示したとする。この指示に従って、変更部１２２は、対応するライフサイクル定義ＤＢ２０中のレコードｒ２において、「状態遷移条件」の項目の値のうち、“草案作成”状態の期日「2008/5/1」を「2008/5/20」に変更する（図９の矢印ａ）。
【００７４】
ライフサイクル定義ＬＳ２は、下位ライフサイクル定義ＬＳ３「部品Ａ仕様書用」を有するため、ライフサイクル定義ＬＳ２に対して変更を加えた後、変更部１２２は、下位ライフサイクル定義ＬＳ３を新たな変更対象として図７の例の手順の処理を再帰的に呼び出して実行する（ステップＳ７８、Ｓ８０，Ｓ８２）。この再帰処理では、変更対象のライフサイクル定義ＬＳ３は、ユーザの変更要求において特定されたものではない。よって、変更部１２２は、その上位ライフサイクル定義ＬＳ２の変更の内容に従って、変更対象のライフサイクル定義ＬＳ３の変更を行う（図７のステップＳ７２、図８のステップＳ７２０，Ｓ７２４）。本例では、上位ライフサイクル定義ＬＳ２において“草案作成”状態の期日の変更に従って、変更対象のライフサイクル定義ＬＳ３の“草案作成”状態の期日を同様に「2008/5/1」から「2008/5/20」に変更する（図９の矢印ａ）。“草案作成”状態の新たな期日「2008/5/20」は、その次の状態である“本人修正”状態の期日「2008/5/15」の後であり、このままでは、ライフサイクル定義ＬＳ３の各状態の期日の定義に矛盾がある。したがって変更部１２２は、さらに、ライフサイクル定義ＬＳ３において“草案作成”状態の次の“本人修正”状態（上位ライフサイクル定義ＬＳ２における“修正”状態の１つの下位状態である）の期日も変更する。このとき、“本人修正”状態の期間と“上長修正”状態（“修正”状態のもう１つの下位状態である）の期間との比について、変更前の比を概ね維持するように、“本人修正”の期日を「2008/5/15」から「2008/5/28」に変更する（図９の矢印ｂ）。
【００７５】
さらに他の具体例として、図１０を参照し、図２のライフサイクル定義ＬＳ１「製品Ａ仕様書用」を変更対象として、ユーザがライフサイクル定義の変更要求を行った場合の具体例を説明する。本例では、ユーザは、ライフサイクル定義ＬＳ１において、“作成”状態の期日を「2008/6/15」から「2008/7/3」に変更することを指示したとする。まず、ユーザによる変更要求で特定された変更対象のライフサイクル定義ＬＳ１についてのライフサイクル定義変更処理（図７及び図８）により、ライフサイクル定義ＤＢ２０の対応するレコードｒ１において、“作成”状態の期日が「2008/7/3」に変更される（図１０の矢印ｃ）。そして、ライフサイクル定義ＬＳ１の下位ライフサイクル定義ＬＳ２を変更対象として再帰的に呼び出されるライフサイクル定義変更処理により、ライフサイクル定義ＬＳ２において“レビュー”状態へ遷移する日付が同様に変更される。すなわち、ライフサイクル定義ＤＢ２０の対応するレコードｒ２において、“作成”状態の下位状態のうちの最後の状態である“修正”状態の期日が「2008/7/3」に書き換えられる（図１０の矢印ｃ）。これに伴って、“作成”状態の下位状態のうち最初の状態である“草案作成”状態の期日についても、変更前の“草案作成”状態の期間と“修正”状態の期間との比を概ね維持するように変更される。図１０の例では、変更部１２２は、“草案作成”状態から“修正”状態へ遷移する日付を「2008/5/1」から「2008/5/8」に変更する（図１０の矢印ｄ）。
【００７６】
さらに、ライフサイクル定義ＬＳ２は下位ライフサイクル定義ＬＳ３「部品Ａ仕様書用」を有するので、これを変更対象として変更部１２２はライフサイクル定義変更処理（図７及び図８）を再帰的に実行する。ライフサイクル定義ＬＳ３については、その上位ライフサイクル定義ＬＳ２における変更内容と同様に、“レビュー”状態へ遷移する日付を「2008/7/3」に変更し（図１０の矢印ｃ）、“草案作成”状態の期日を「2008/5/8」に変更する（図１０の矢印ｄ）。さらに、これらの変更に伴って、“本人修正”状態の期日を「2008/5/15」から「2008/5/27」に変更する（図１０の矢印ｅ）。“本人修正”状態の期日を変更することで、“本人修正”状態の期間と“上長修正”状態の期間との比を変更処理の前の比に（概ね）維持する。また、ライフサイクル定義ＬＳ１のもう１つの下位ライフサイクル定義であるライフサイクル定義ＬＳ４「コンポーネントＢ仕様書用」についても、変更部１２２はライフサイクル定義変更処理（図７及び図８）を再帰的に呼び出して実行する。ライフサイクル定義ＬＳ４に対する変更処理では、まず、上位ライフサイクル定義ＬＳ１における“作成”状態の期日の変更と同様の変更（“レビュー”状態への遷移の日付を「2008/7/3」とする）を行う（図１０の矢印ｃ）。そして、“作成”状態の下位状態“前半作成”から“後半作成”への遷移する日付を「2008/5/10」から「2008/5/20」に変更することで（図１０の矢印ｆ）、“前半作成”状態の期間と“後半作成”状態の期間との比が変更前の比と概ね同じになるようにする。
【００７７】
図９及び図１０を参照して説明した以上の具体例では、上位ライフサイクル定義の変更に従ってライフサイクル定義の変更を行う（図８のステップＳ７２０）ときに、変更部１２２は、まず上位ライフサイクル定義における各状態の期日の変更と同様の変更を行い、それに伴って下位状態を含む状態の期間が短縮又は延長されると、その変更前の各下位状態の期間の比を概ね維持するように下位状態の期日を変更する。これにより、上位ライフサイクル定義における変更と整合するように下位ライフサイクル定義の内容が変更されることになる。
【００７８】
なお、図９及び図１０を参照する具体例は、上位ライフサイクル定義における変更と整合する下位ライフサイクル定義の変更の一例に過ぎない。変更後の下位ライフサイクル定義が変更後の上位ライフサイクル定義と同様の状態及び状態遷移条件を含んでいれば、下位ライフサイクル定義について上述の具体例と異なる方法で変更してもよい。例えば、下位ライフサイクル定義の変更処理において、上位ライフサイクル定義における期日の変更と同様の変更を行うだけで、変更前の各下位状態の期間の比を維持するための下位状態の期日の変更は行わないものとしてもよい。
【００７９】
ライフサイクル定義の変更の他の例では、ライフサイクル定義における状態を追加する場合がある。例えば上位ライフサイクル定義において状態が追加された場合、下位ライフサイクル定義についての再帰的な変更処理において、上位ライフサイクルで追加された状態と同様の状態及び状態遷移条件を追加する。例えば、各ライフサイクル定義の内容の他の一例を図式的に示した図１１を参照し、図２及び図３に例示するライフサイクル定義「コンポーネントＡ仕様書用」に対して、上位ライフサイクル定義における“作成”状態の下位状態として、“草案作成”状態及び“修正”状態に加えて、“修正”状態の後に“予備”状態を追加する変更が行われたとする。このとき、下位ライフサイクル定義「部品Ａ仕様書用」について、上位ライフサイクル定義において追加された“予備”状態を追加する。なお、図１１の例では、“予備”状態の追加によって期間が短縮された“修正”状態について、下位状態“本人修正”の期日は変更されていないが、各下位状態“本人修正”，“上長修正”の期間の比を変更の前後で維持するようにしてもよい。
【００８０】
以上で説明した実施形態の例では、ライフサイクル定義における状態遷移条件として、各状態の期日が設定される。状態遷移条件の他の例では、文書属性に基づく条件を定めてもよい。例えば、文書属性の特定の項目の値の変化を文書の状態が遷移する条件としてよい。例えば、文書属性は、文書に対して特定のユーザによる承認の有無を表す情報を含む場合がある。この場合、例えば、そのライフサイクル定義に従う文書に対して承認を与える役職者のユーザ識別情報を指定し、当該識別情報のユーザによる承認が与えられることを状態遷移条件として設定してもよい。文書処理部１４において、本例のライフサイクル定義に従う文書の状態の特定（例えば、図６のステップＳ３８）は、例えば、文書属性において状態遷移条件で指定された識別情報のユーザによる承認の有無を判定することで行う。また、本例のライフサイクル定義の変更において、例えば、承認を与えるユーザを変更することが考えられる。この場合、上位ライフサイクル定義の状態遷移条件における承認者の識別情報を書き換える変更を行う。そして、下位ライフサイクル定義についても同様に承認者の識別情報の変更を行うことで、上位ライフサイクル定義における変更との整合性を保つ。
【００８１】
なお、以上で説明した各種の処理の例では、文書ＤＢ３０に格納された文書属性テーブルを参照して、各文書に関連づけられたライフサイクル定義ＩＤを取得する。他の処理の例では、各文書の格納位置の指定を受けて文書ＤＢ３０中の各電子文書ファイルを取得し、その電子文書ファイル中に属性情報として含まれるライフサイクル定義ＩＤを取得してもよい。さらに他の例では、文書とライフサイクル定義とを関連づける情報をライフサイクル定義ＤＢ２０に記憶させておき、この情報を参照して各文書に関連づけられるライフサイクル定義を特定してもよい。
【００８２】
以上に例示した文書管理装置１０は、典型的には、汎用のコンピュータにて上述の文書管理装置１０の各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図１２に示すように、ＣＰＵ（中央演算装置）８０、メモリ（一次記憶）８２、各種Ｉ／Ｏ（入出力）インタフェース８４等がバス８６を介して接続された回路構成を有する。また、そのバス８６に対し、例えばＩ／Ｏインタフェース８４経由で、ＨＤＤ（ハードディスクドライブ）８８やＣＤやＤＶＤ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ９０が接続される。このようなドライブ８８又は９０は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク経由で、ＨＤＤ８８等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されＣＰＵにより実行されることにより、実施形態の処理が実現される。
【図面の簡単な説明】
【００８３】
【図１】文書管理装置の構成例を示す図である。
【図２】ライフサイクル定義ＤＢのデータ内容の例を示す図である。
【図３】図２に例示するライフサイクル定義ＤＢのデータ内容の一例を図式的に示した図である。
【図４】文書ＤＢに記憶される文書属性テーブルの一例を示す図である。
【図５】ライフサイクル定義処理部の生成登録部が行う処理の手順の例を示すフローチャートである。
【図６】文書処理部が行う処理の手順の例を示すフローチャートである。
【図７】ライフサイクル定義処理部の変更部が行う処理の手順の例を示すフローチャートである。
【図８】ライフサイクル定義処理部の変更部が行う処理の部分的な手順の例を示すフローチャートである。
【図９】ライフサイクル定義変更処理の１つの具体例を説明するための図である。
【図１０】ライフサイクル定義変更処理の他の１つの具体例を説明するための図である。
【図１１】ライフサイクル定義変更処理の他の１つの具体例を説明するための図である。
【図１２】コンピュータのハードウエア構成の例を示す図である。
【符号の説明】
【００８４】
１０  文書管理装置、１２  ライフサイクル定義処理部、１４  文書処理部、２０  ライフサイクル定義ＤＢ、３０  文書ＤＢ、４０  ユーザ情報ＤＢ、８０  ＣＰＵ、８２  メモリ、８４  Ｉ／Ｏインタフェース、８６  バス、８８  ＨＤＤ、９０  ディスクドライブ、１２０  生成登録部、１２２  変更部、１４０  ライフサイクル制御部。
【図１】
2010061345.tif 000003
【図２】
2010061345.tif 000004
【図３】
2010061345.tif 000005
【図４】
2010061345.tif 000006
【図５】
2010061345.tif 000007
【図６】
2010061345.tif 000008
【図７】
2010061345.tif 000009
【図８】
2010061345.tif 000010
【図９】
2010061345.tif 000011
【図１０】
2010061345.tif 000012
【図１１】
2010061345.tif 000013
【図１２】
2010061345.tif 000014