情報処理装置、情報処理システム、及びプログラム
【課題】階層構造を形成する複数の組織で利用される電子文書の管理において、組織階層に応じて、文書の流通経路ごとに、文書に対するアクセスを制御できる技術を提供する。
【解決手段】派生関係ＤＢ１１０は、操作結果の文書の管理ＩＤに対応づけて、その文書の操作前の管理ＩＤである親ＩＤ、及び、その操作者を記憶する。組織情報ＤＢ１２０は、複数の組織からなる組織階層の構造を表す情報と、各組織に所属する構成員と、を記憶する。アクセス制御部１４２は、要求対象文書の管理ＩＤと、要求者と、を特定する文書出力要求を受けた場合に、要求対象文書又は派生関係ＤＢ１１０内の派生関係群が表す木構造において要求対象文書の先祖に該当する文書の操作者と、要求者の所属組織又は当該所属組織の上位組織に所属する構成員と、を照合することで、要求対象文書の出力の可否を決定する。
【解決手段】派生関係ＤＢ１１０は、操作結果の文書の管理ＩＤに対応づけて、その文書の操作前の管理ＩＤである親ＩＤ、及び、その操作者を記憶する。組織情報ＤＢ１２０は、複数の組織からなる組織階層の構造を表す情報と、各組織に所属する構成員と、を記憶する。アクセス制御部１４２は、要求対象文書の管理ＩＤと、要求者と、を特定する文書出力要求を受けた場合に、要求対象文書又は派生関係ＤＢ１１０内の派生関係群が表す木構造において要求対象文書の先祖に該当する文書の操作者と、要求者の所属組織又は当該所属組織の上位組織に所属する構成員と、を照合することで、要求対象文書の出力の可否を決定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理システム、及びプログラムに関する。
【背景技術】
【０００２】
サーバに電子文書が登録されたシステムにおいて、一般に、電子文書に関してユーザに与えられる利用権限の管理は、電子文書（ファイル）ごとに、その文書に対する各ユーザ又は各グループの権限、例えば閲覧可能／不可、書込可能／不可など、のアクセス権を示す情報を設定登録することで行われる。電子文書の利用管理を行うシステムは、ユーザからある文書に対する操作の要求を受けた場合、その文書について設定登録されたアクセス権情報に基づいて、その操作がそのユーザの権限内のものであるかを判定し、その操作を許可するか否かを判定する。
【０００３】
文書ごとにアクセス権情報を設定登録する電子文書利用管理システムを用いて、例えば企業など、階層構造を形成する複数の組織からなる団体において利用される電子文書を管理する場合に、その団体における組織の階層構造及び組織の業務分担などの組織に関する情報を用いて、文書ごとのアクセス権の設定を行う技術がある。
【０００４】
特許文献１には、プログラム及び設計書などの文書について、会社組織及び業務分類に基づきアクセス権を設定する文書管理装置が開示されている。特許文献１に記載の技術では、各組織の構成員を表す情報と、各組織の業務を表す情報と、業務において用いられる文書を表す情報と、を設定しておき、文書に対するアクセス要求があった場合に、アクセス要求を行った個人が所属する組織の業務において用いられる文書として当該文書が設定されているか否かを判定することで、当該文書に対するアクセスの可否を決定する。
【０００５】
また、特許文献２には、文書アクセス管理システムにおいて、複数のグループを階層構造で定義した情報を保存するグループ階層構造情報記憶装置と、文書の更新や配布先設定を委ねられた管理元となるグループを示す情報及びアクセス許可グループを示す情報を文書ごとに保存する文書記憶装置と、を備え、これらの記憶装置に保存された情報を用いて、個々の文書の参照や、その他の取り扱いができるユーザの選別を行うシステムが開示されている。
【０００６】
特許文献３には、文書ごとのアクセス権を規定したアクセス権限リスト（ＡＣＬ，Access Control List）の中に、組織における操作者の属性及び役職の属性などに関する照合規則を定義しておくことで、組織に関する属性情報に従って文書のアクセス制御を行う技術が開示されている。
【０００７】
【特許文献１】特開平７−５６７９４号公報
【特許文献２】特開２０００−２０３７７号公報
【特許文献３】特許第３３４９９７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところで、例えば、企業などの複数の組織からなる団体において、１つの電子文書が複製されて複数の流通経路に沿って流通し、その電子文書に対し個々の流通経路でそれぞれ個別に更新が加えられる場合がある。このような場合、更新後の文書に対するアクセスは、組織の階層構造などに適合するように制御するだけでなく、異なる流通経路ごとに異なるアクセス権が実現されるように制御することが望まれる場合がある。
【０００９】
１つの電子文書が複数の流通経路に沿って流通する場合、例えば、１つの電子文書について複数の流通経路それぞれにおいて複数回の更新が行われると、電子文書ごとにアクセス権情報を設定登録すると、各流通経路における複数の更新版の文書に対してそれぞれアクセス権情報を設定登録する必要があるため、設定登録作業が煩雑となり管理負担が大きい。
【００１０】
本発明は、階層構造を形成する複数の組織において利用される電子文書の管理において、組織階層に応じて、文書の流通経路ごとに、文書に対してアクセスを制御できる情報処理装置、情報処理システム及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
請求項１に係る発明は、第１の文書を親とし当該第１の文書に対する操作の結果生成された第２の文書を子とする派生関係を記憶する文書情報記憶部であって、当該第１の文書に対する操作を行った操作者を示す情報を当該第２の文書と対応づけて記憶する文書情報記憶部と、複数の組織からなる組織階層の構造を表す情報と、前記組織のそれぞれに所属する構成員を示す情報と、を記憶する組織情報記憶部と、要求対象文書と、要求者と、を特定する文書出力要求を受けた場合に、前記要求対象文書に対応づけられた操作者を示す情報又は前記文書情報記憶部に記憶された前記派生関係群が表す木構造において前記要求対象文書の先祖に該当する文書に対応づけられた操作者を示す情報と、前記組織情報記憶部に記憶された情報のうち、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織に所属する構成員を示す情報と、を照合することで、前記要求者に対する前記要求対象文書の出力の可否を決定する文書出力可否決定部と、を備えることを特徴とする情報処理装置である。
【００１２】
請求項２に係る発明は、請求項１に係る発明において、前記文書出力可否決定部は、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織が、前記要求対象文書に対応づけられた操作者を前記構成員として含むか否かを判定し、当該判定の結果に基づいて、前記要求対象文書の出力の可否を決定する。
【００１３】
請求項３に係る発明は、請求項２に係る発明において、前記文書出力可否決定部は、前記要求対象の文書が前記組織階層において上位から下位の展開経路を経ずに更新登録された文書である場合には、前記要求対象の文書の出力を許可しない。
【００１４】
請求項４に係る発明は、請求項１から３のいずれか１項に係る発明において、前記文書出力可否決定部は、前記要求対象文書を起点として前記木構造を遡った経路上に含まれる文書のうち少なくとも１つの文書に対応づけられた操作者が前記要求者である場合に、前記要求対象文書の出力を許可する。
【００１５】
請求項５に係る発明は、請求項１から４のいずれか１項に係る発明において、前記組織情報記憶部は、さらに、前記組織のそれぞれに所属する構成員のうちの役職者を示す情報を記憶し、前記文書出力可否決定部は、前記要求対象文書に対応づけられた操作者が、前記構成員として当該操作者を含む組織の役職者でない場合であって、前記要求対象文書を起点として前記木構造を遡った経路上に含まれる文書のいずれに対応づけられた操作者も前記要求者でない場合は、前記要求対象文書の出力を許可しない。
【００１６】
請求項６に係る発明は、第１の文書を親とし当該第１の文書に対する操作の結果生成された第２の文書を子とする派生関係を文書情報記憶部に記憶するステップであって、当該第１の文書に対する操作を行った操作者を示す情報を当該第２の文書と対応づけて文書情報記憶部に記憶するステップと、複数の組織からなる組織階層の構造を表す情報と、前記組織のそれぞれに所属する構成員を示す情報と、を組織情報記憶部に記憶するステップと、要求対象文書と、要求者と、を特定する文書出力要求を受けた場合に、前記要求対象文書に対応づけられた操作者を示す情報又は前記文書情報記憶部に記憶された前記派生関係群が表す木構造において前記要求対象文書の先祖に該当する文書に対応づけられた操作者を示す情報と、前記組織情報記憶部に記憶された情報のうち、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織に所属する構成員を示す情報と、を照合することで、前記要求者に対する前記要求対象文書の出力の可否を決定するステップと、をコンピュータに実行させることを特徴とするプログラムである。
【００１７】
請求項７に係る発明は、第１の情報処理装置と第２の情報処理装置とを備え、前記第１の情報処理装置は、要求対象文書と、要求者と、を特定する文書出力要求を前記第２の情報処理装置に対して行う文書出力要求部を備え、前記第２の情報処理装置は、第１の文書を親とし当該第１の文書に対する操作の結果生成された第２の文書を子とする派生関係を記憶する文書情報記憶部であって、当該第１の文書に対する操作を行った操作者を示す情報を当該第２の文書と対応づけて記憶する文書情報記憶部と、複数の組織からなる組織階層の構造を表す情報と、前記組織のそれぞれに所属する構成員を示す情報と、を記憶する組織情報記憶部と、前記第１の情報処理装置から前記文書出力要求を受けた場合に、前記要求対象文書に対応づけられた操作者を示す情報又は前記文書情報記憶部に記憶された前記派生関係群が表す木構造において前記要求対象文書の先祖に該当する文書に対応づけられた操作者を示す情報と、前記組織情報記憶部に記憶された情報のうち、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織に所属する構成員を示す情報と、を照合することで、前記要求者に対する前記要求対象文書の出力の可否を決定する文書出力可否決定部と、を備えることを特徴とする情報処理システムである。
【発明の効果】
【００１８】
請求項１に係る発明によると、文書ごとにアクセス権情報を設定することなく、組織階層に応じて、文書の流通経路ごとに、文書に対するアクセスを制御できる。
【００１９】
請求項２に係る発明によると、要求対象文書の操作者の所属組織が要求者の所属組織に対して組織階層において直系の上位に該当するか否かによって文書に対するアクセスを制御することができる。
【００２０】
請求項３に係る発明によると、上位組織に所属するユーザから下位組織に所属するユーザの順に操作された文書でなければアクセスを許可しないようにできる。
【００２１】
請求項４に係る発明によると、要求者が操作した文書から派生した文書については、要求者にアクセスを許可するようにできる。
【００２２】
請求項５に係る発明によると、役職者が操作した文書以外の文書について、要求者が操作した文書から派生した文書でない限りは、要求者にアクセスを許可しないようにできる。
【００２３】
請求項６に係る発明によると、文書ごとにアクセス権情報を設定することなく、組織階層に応じて、文書の流通経路ごとに、文書に対するアクセスを制御できる。
【００２４】
請求項７に係る発明によると、文書ごとにアクセス権情報を設定することなく、組織階層に応じて、文書の流通経路ごとに、文書に対するアクセスを制御できる。
【発明を実施するための最良の形態】
【００２５】
以下、図面を参照して、本発明の実施の形態を説明する。
【００２６】
図１は、文書管理システムの概略構成を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク３０を介して接続された文書管理サーバ１０とクライアント端末２０−１，２０−２，・・・（以下、クライアント端末２０と総称する）から構成される。
【００２７】
クライアント端末２０について図２を用いて説明する。クライアント端末は、ユーザが文書を操作するために用いる端末であり、パーソナルコンピュータ、デジタル複写機などがその一例である。クライアント端末２０は、図２に示すように、文書操作部２００及び登録処理部２１０を備える。
【００２８】
文書操作部２００は、文書に対する操作を実行する手段である。文書に対する操作には、例えば、文書の表示（ユーザから見れば「閲覧」）、編集、印刷出力、紙文書の読み取り、紙文書の複写、等がある。図では、文書操作部２００を１つだけ示したが、それら個々の操作を別々の操作部（例えば、編集用のアプリケーション、読取制御用のアプリケーションなど）が担当してもよい。例えば、文書操作部２００がワードプロセッサ等の電子文書を作成・編集するためのソフトウエアであれば、文書操作部２００は、ユーザの指示に応じて電子文書を表示したり、電子文書に編集を加えたりする。文書操作部２００は、文書に対して操作を行った場合、その操作の結果を表すＩＤ付き文書３００を出力する。
【００２９】
ＩＤ付き文書３００は、図３に示すように、メタ情報３１０と文書内容３２０を含んだ電子文書である。文書内容３２０は、文書操作部２００の操作の結果生成された文書の内容データである。文書操作部２００が電子文書を作成・編集するためのソフトウエアであれば、文書内容３２０はそのソフトウエアによる編集の結果生成される文書ファイルである。また、文書操作部２００が電子文書を印刷する装置であれば、文書内容３２０は、例えば、印刷される電子文書の内容データとすればよい。また、文書操作部２００が紙文書をスキャンする装置又は紙文書を複写する装置であれば、文書内容３２０は、例えば、その紙文書を読み取って得られる画像データとすればよい。
【００３０】
メタ情報３１０は、文書管理のための情報であり、管理ＩＤ３１２，親ＩＤ３１４，及びログ情報３１６を含む。
【００３１】
管理ＩＤ３１２は、当該ＩＤ付き文書３００自体の一意な識別情報である。親ＩＤ３１４は、当該ＩＤ付き文書３００の親のＩＤ付き文書の管理ＩＤである。すなわち、本実施形態では、あるＩＤ付き文書と、このＩＤ付き文書に対して操作を加えた結果得られる新たなＩＤ付き文書とを、親と子の関係として取り扱う。第１のＩＤ付き文書を操作して第２のＩＤ付き文書が得られた場合、第１のＩＤ付き文書は第２のＩＤ付き文書の親であり、第２のＩＤ付き文書は第１のＩＤ付き文書の子である。したがって、例えば、管理ＩＤ「Ａ」のＩＤ付き文書を文書操作部２００で操作して、その結果得られた新たなＩＤ付き文書の管理ＩＤが「Ｂ」である場合、後者のメタ情報３１０における管理ＩＤ３１２は「Ｂ」であり、親ＩＤ３１４は「Ａ」である。このような親子の関係を、以下では「（管理ＩＤの）派生関係」という。
【００３２】
なお、本システムに未登録の電子文書を新たに登録する操作を実行した場合や、未登録の紙文書をスキャン又は複写する操作を実行した場合（この場合、紙文書を読み取った画像を文書内容とするＩＤ付き文書が生成され、本システムに登録される）に生成されるＩＤ付き文書３００では、親ＩＤ３１４は空（すなわち、親は存在しない）となる。
【００３３】
ログ情報３１６は、当該ＩＤ付き文書が生成された際の操作についての、各種のログ項目の情報である。ログ項目には、例えばその操作が行われた日時、その操作の種別、その操作を指示したユーザ（操作者）などがあるが、もちろんこれに限るものではない。操作の種別には、例えば登録（本システムに新規の文書を登録すること）、閲覧、編集、更新（更新版の登録）、印刷、スキャン、紙文書の複写、等がある。例えば、ユーザが文書操作部２００を用いて第１のＩＤ付き文書に対して編集を加え、編集完了の指示を行った場合、その結果生成される第２のＩＤ付き文書のログ情報３１６は、編集完了の日時と、その編集を指示したユーザの識別情報と、操作の種別として「編集」と、を含んだものとなる。
【００３４】
ここでログ情報３１６に組み込まれる操作の種別は、ログ記録の目的での分類に従った種別であり、文書操作部２００が実行する操作の種別そのものでなくてもよい。例えば、文書操作部２００が実行する複数の操作の種別を、同じ１つのログ記録目的の操作種別に対応づけてもよい。例えば、文書編集アプリケーション上でＩＤ付きの電子文書に編集を加え操作メニュー上で「更新版として登録」を指示した場合も、スキャナで管理ＩＤ付きの紙文書を読み取り読取制御用アプリケーションの操作メニュー上で「読み取った文書を承認版として登録」を指示した場合も、ログ情報３１６に組み込まれる操作種別の値は「更新」となる。
【００３５】
文書操作部２００が生成するメタ情報３１０の具体例を以下に示す。
【００３６】
[例１]
<metadata sid="Doc1" date="2006-10-01T10:00" method="register" filename="aaa.doc" user="user1"/>
【００３７】
ここでsid属性は管理ＩＤ、date属性は操作日時、method属性は操作種別である。また、filename属性は当該ＩＤ付き文書のファイル名であり、user属性は操作を指示したユーザのユーザ識別情報である。例１のmethod属性値"register"は（文書管理サーバ１００に未登録の）新規文書の登録操作を示す操作種別名である。新規文書の登録なので、親ＩＤを示すpid属性は省略されている。省略する代わりにpid="null"などと、親ＩＤがないことを示す属性を明示的に組み込んでもよい。
【００３８】
なお、文書操作部２００が、操作した文書を暗号化してもよい。この暗号化は、本システムに準拠した文書操作部２００ならば、復号できるようなものとする。この場合、文書操作部２００が出力するＩＤ付き文書３００の文書内容３２０は、暗号化されることにより、本システムに準拠した文書操作部２００でないと復号できなくなる。したがって、ＩＤ付き文書３００が操作される場合には文書操作部２００が用いられるので、文書操作部２００がその操作を検知し、その操作の内容が文書操作部２００から文書管理サーバ１０に通知される。なお、文書内容３２０だけでなく、後述するメタ情報３１０（またはその一部）に対しても暗号化を施してもよい。
【００３９】
図２の説明に戻り、文書操作部２００は、操作結果として上述のようなＩＤ付き文書３００を作成するために、ＩＤ割り当て部２０２及び派生関係組込部２０４を備える。ＩＤ割り当て部２０２は、操作結果のＩＤ付き文書３００に一意な管理ＩＤを付与する手段である。管理ＩＤは、少なくとも本システム内で一意な識別情報である必要がある。例えば、操作の結果生成するＩＤ付き文書３００（ただし管理ＩＤ３１２を除いたもの）のハッシュ値を求め、このハッシュ値をその文書３００のＩＤ付き文書とすればよい。ハッシュ関数としてSHA-256（SHA-256はNISTがFIPS180-2で定めた256ビットのハッシュ値を持つ暗号学的ハッシュ関数である）などのような耐衝突性を持つ暗号学的ハッシュ関数を用いれば、実用上十分な一意性を持つ管理ＩＤを生成することができる。もちろん、システム内で一意な管理ＩＤを各クライアント端末２０で生成する方法は、これに限らない。管理ＩＤを、クライアント端末２０固有の識別情報を含むものとすれば、システム内で一意な管理ＩＤを各クライアント端末２０で生成することができる。
【００４０】
派生関係組込部２０４は、操作結果の文書に対しＩＤ割り当て部２０２が割り当てた新たな管理ＩＤ３１２と、その操作の元になった親文書の管理ＩＤである親ＩＤ３１４（新規登録の場合は、親ＩＤは無し）と、その操作についてのログ情報３１６と、を含むメタ情報３１０を生成する。ここで、派生関係組込部２０４は、文書操作部２００が実行する個々の操作の種別が、ログ記録目的上の操作種別のどれに対応するかを表す対応関係の情報を保持しており、この情報を用いることでログ情報３１６に組み込む操作種別の値を求める。そして、派生関係組込部２０４は、そのメタ情報３１０を操作結果の文書内容に付加することにより、操作後のＩＤ付き文書３００を生成して出力する。
【００４１】
文書操作部２００がアプリケーションソフトウエアである場合、ＩＤ割り当て部２０２及び派生関係組込部２０４は、そのソフトウエアに対して追加される、いわゆるプラグイン(plug-in)プログラムとして実現してもよい。
【００４２】
登録処理部２１０は、文書操作部２００が出力したＩＤ付き文書３００を文書管理サーバ１０に登録するための処理を実行する。このように各クライアント端末２０が、自ら実行した操作の結果であるＩＤ付き文書３００を文書管理サーバ１０に登録することにより、文書管理サーバ１０は各ＩＤ付き文書３００間の派生関係を把握することができる。
【００４３】
文書操作部２００が操作の結果出力するＩＤ付き文書３００は、通常の文書ファイルと同様、電子的にコピーしたり、電子メールに添付するなどの方法で他の人宛に送信したりすることができる。電子メール送信用のソフトウエアは、この例では本システムに準拠していないので、この送信操作はＩＤ付き文書には反映されず、したがって文書管理サーバ１０にも記録されない。他の人からＩＤ付き文書３００を受け取った人が、自分のクライアント端末２０の文書操作部２００を用いてそのＩＤ付き文書３００を操作すると、その操作に応じて新たな管理ＩＤを付与されたＩＤ付き文書が生成されることになる。
【００４４】
また、文書操作部２００が電子文書を印刷する場合、管理ＩＤを生成し、その電子文書の印刷結果にその管理ＩＤを埋め込んでもよい。管理ＩＤの埋め込みは、例えば電子文書の印刷画像に、管理ＩＤを示すコード画像を重畳する等の方法で行うことができる。また、用紙がＲＦＩＤ(Radio Frequency Identifier)タグを備えている場合、そのＲＦＩＤタグに管理ＩＤを書き込んでもよい。このように印刷を行った場合、文書操作部２００は、その管理ＩＤや操作種別「印刷」等のメタ情報を含んだＩＤ付き文書を文書管理サーバ１０に登録する。なお、ＩＤ付き文書を印刷した場合には、そのＩＤ付き文書の管理ＩＤを親ＩＤ３１４として含んだＩＤ付き文書が生成される。印刷操作に対応するＩＤ付き文書には、印刷された画像を示すページ記述言語データやビットマップ画像データをなどの印刷データ、又は印刷された文書ファイルを、文書内容３２０として組み込んでもよい。
【００４５】
また、管理ＩＤが埋め込まれた紙文書を文書操作部２００が読み取った場合、文書操作部２００は、その読み取り操作に対して新たな管理ＩＤを付与し、読み取り結果の画像を文書内容３２０として含んだＩＤ付き文書を生成して文書管理サーバ１０に登録する。このＩＤ付き文書の親ＩＤ３１４には、紙文書から読み取った管理ＩＤがセットされる。管理ＩＤが埋め込まれた紙文書の複写の際には、上述した読み取り時と印刷時の処理が実行される。
【００４６】
次に、文書管理サーバ１０について説明する。文書管理サーバ１０は、システム内の複数のクライアント端末２０から送られてくるＩＤ付き文書３００を蓄積し、蓄積した情報に基づきユーザに各種のサービスを提供する。図４に示すように、文書管理サーバ１０は、文書ＤＢ（データベース）１００，派生関係ＤＢ１１０，組織情報ＤＢ１２０，文書登録部１３０，要求処理部１４０を備える。
【００４７】
文書ＤＢ１００は、クライアント端末２０から送られてきたＩＤ付き文書３００のうちの文書内容３２０を格納するデータベースである。文書ＤＢ１００に格納された各文書内容３２０は、一意な内容ＩＤにより管理してもよい。内容ＩＤとしては、例えば当該文書内容の暗号学的ハッシュ関数によるハッシュ値を用いてもよいが、これに限定されるものではない。クライアント端末２０が内容ＩＤを付与してもよく、この場合、内容ＩＤをメタ情報３２０に組み込んでもよい。また、内容ＩＤの代わりに、その文書内容３２０を、当該文書内容に対応するＩＤ付き文書３００の管理ＩＤと対応づけて文書ＤＢ１００に格納してもよい。
【００４８】
文書登録部１３０は、クライアント端末２０から受信したＩＤ付き文書の中の文書内容を文書ＤＢ１００に、メタ情報を派生関係ＤＢ１１０に、それぞれ登録する。そのうち、メタ情報の登録を担当するのが派生関係登録部１３２である。
【００４９】
派生関係ＤＢ１１０は、そのようなＩＤ付き文書３００のうち、派生関係の情報を主としたメタ情報を蓄積するデータベースである。図５に、派生関係ＤＢ１１０のデータ内容の一例を示す。図５に示した表における１行の情報が、１つのＩＤ付き文書３００に対応するメタ情報レコードである。この例では、各ＩＤ付き文書３００の管理ＩＤに対応づけて、親ＩＤ、ノードアドレス、操作種別、操作者、操作日時の各項目が登録されている。このうち、管理ＩＤと親ＩＤのペア以外の項目は、例示したものに限られない。管理目的上必要な項目を記録すればよい。また、操作種別、操作者、操作日時については既に説明した。
【００５０】
ノードアドレスは、ＩＤ付き文書間の派生関係が構成する木において、当該管理ＩＤ（ＩＤ付き文書）に対応するノードの位置を示している。ノードアドレスの表記において「／」が木の深さ階層の区切りを示し、番号が同じ親から派生した兄弟同士の間での順番を示す。例えばノード「／１」は新規文書登録の操作により登録された文書に対応する根ノードを示す。また、ノード「／１／１」は根ノード「／１」の１番目の子、ノード「／１／２」は根ノード「／１」の２番目の子を示す。なお、煩雑さを避けるため、図５には、１つの根ノード「／１」から派生した１つの木に属するメタ情報レコード群しか示していないが、文書管理サーバ１０には、例えば根「／１」から派生する木と根「／２」から派生する木のように、複数の木のメタ情報レコード群が登録され得る。
【００５１】
なお、図５に例示したメタ情報の項目は一例に過ぎない。例えば、この他にも、ＩＤ付き文書内の文書内容３２０を格納した、文書ＤＢ１００内での格納場所を示すパス名を派生関係ＤＢ１１０に登録してもよい。文書ＤＢ１００が、内容ＩＤで文書内容３２０を検索する機能を持つものであれば、文書格納パスの代わりに内容ＩＤをメタ情報レコードに登録してもよい。
【００５２】
なお、図５は派生関係ＤＢ１１０が管理するデータを内容の観点から表現したものにすぎず、具体的な表現形式或いはデータベース形式を規定するものではない。例えば、派生関係ＤＢ１１０は、一般的なリレーショナルデータベースとして構築することもできるし、管理ＩＤを除くメタ情報を記述したＸＭＬ(eXtensible Markup Language)文書を、管理ＩＤをキーとして登録したデータベースとして構築することもできる。
【００５３】
図５に示した派生関係ＤＢ１１０のデータ内容は、図６のような木構造を成す。これは、管理ＩＤをノードとし、管理ＩＤ間の親子関係をエッジとする木構造である。
【００５４】
以下、図５〜図６の例が示す文書のうち、管理ＩＤ"Doc1"の文書から管理ＩＤ"Doc7"の文書までの履歴について時系列順に説明する。
【００５５】
この例ではまず、文書（フォーム）の「登録」操作がuser1のクライアント端末で実行される。「登録」操作は、文書管理サーバ１０に未登録の文書（すなわち、管理ＩＤを有していない文書）を当該サーバ１０に登録するための操作である。この操作に応じて管理ＩＤが"Doc1"、親ＩＤが空、操作種別が「登録」であるメタ情報と、その文書の文書内容とを含むＩＤ付き文書"Doc1"がuser1のクライアント端末から文書管理サーバ１０に送られる。これに応じ、文書管理サーバ１０は、そのＩＤ付き文書"Doc1"中の文書内容を文書ＤＢ１００へ、メタ情報を派生関係ＤＢ１１０にそれぞれ登録する。ここで、文書管理サーバ１０は、操作種別が「登録」であり、親ＩＤが空なので、当該ＩＤ付き文書が、文書管理サーバ１０内に既に登録済みのＩＤ付き文書の子ではなく、新たな木の根（始祖）であると判断し、それに従ってノードアドレスの値（この例では「／１」）を設定する。なお、以下では、識別のために、登録された文書内容を"Content1"で表すことにする。その後、user1は、登録したＩＤ付き文書を他のユーザuser2に配布する。この配布は、例えば、電子メールにそのＩＤ付き文書を添付して各ユーザに送信することにより、行うことができる。
【００５６】
その後、他のユーザuser2が自分のクライアント端末の文書操作部２００でＩＤ付き文書"Doc1"を閲覧する。閲覧されるのは内容ＩＤ"Content1"の文書内容である。クライアント端末は、閲覧の結果としてＩＤ付き文書"Doc2"を生成し、このＩＤ付き文書"Doc2"が文書管理サーバ１０に登録される。このＩＤ付き文書のメタ情報における管理ＩＤは"Doc2"であり親ＩＤは"Doc1"である。また操作者はuser2であり、操作種別は「閲覧」である。また、「閲覧」操作では文書内容は変更されないので、文書内容は"Content1"のままである。このように文書内容が変更されない操作を行った場合、クライアント端末２０は、文書内容を省略したＩＤ付き文書を文書管理サーバ１０に送ってもよい。文書管理サーバ１０は、受け取ったＩＤ付き文書の親ＩＤの値から、当該文書"Doc2"が文書"Doc1"の子であることを認識し、しかも最初の子であるので、文書"Doc2"のノードアドレスを「／１／１」とする。
【００５７】
なお、この操作の前にuser2のクライアント端末２０内にあったＩＤ付き文書"Doc1"は、この操作に伴い、派生関係組込部２０４によりＩＤ付き文書"Doc2"に置き換えられる。この置き換え処理では、派生関係組込部２０４は、元のＩＤ付き文書"Doc1"のうち、メタ情報３１０の管理ＩＤ３１２を新たに発行したＩＤ"Doc2"へ変更すると共に、元の文書"Doc1"の管理ＩＤ"Doc1"を親ＩＤ３１４の値にセットする。また、派生関係組込部２０４は、ログ情報３１６中の操作種別の値を今回の操作の種別である「閲覧」に変更し、操作時刻の値をその閲覧の日時に変更し、操作者の値をuser2に変更する。なお、「閲覧」操作によっては文書の内容は変化しないので、文書内容３２０は、"Content1"のままである。
【００５８】
このようにＩＤ付き文書"Doc1"は、閲覧されると、閲覧後のＩＤ付き文書"Doc2"に置き換えられる。したがって、その置き換えの後は、ＩＤ付き文書"Doc1"自体はそのクライアント端末２０には存在せず、その代わりにＩＤ付き文書"Doc2"が存在することとなる。
【００５９】
その後、user2が自分のクライアント端末２０の文書操作部２００によってＩＤ付き文書"Doc2"に対して編集を加え、操作メニュー上で「更新版として登録」を指示すると、クライアント端末２０は、管理ＩＤ３１２の値が"Doc3"、親ＩＤ３１４の値が"Doc2"、操作種別の値が「更新」であるＩＤ付き文書"Doc3"を生成する。そして、クライアント端末２０は、生成したＩＤ付き文書"Doc3"を「更新」操作の前のＩＤ付き文書"Doc2"と置き換えると共に、ＩＤ付き文書"Doc3"を文書管理サーバ１０に登録する。編集により、文書内容は"Content1"から"Content2"に変化している。文書管理サーバ１０の派生関係ＤＢ１１０には、管理ＩＤ"Doc3"のレコードが登録される。
【００６０】
その後、user2は、電子メールなどによってＩＤ付き文書"Doc3"をuser3及びuser4に配布する。
【００６１】
次に、user2から配布されたＩＤ付き文書"Doc3"に対して、user3のクライアント端末２０の文書操作部２００によって「更新（更新版として登録）」操作が行われる。user3のクライアント端末２０は、その更新結果の文書内容"Content3"を含み、親ＩＤが"Doc3"であり、操作種別の値が「更新」である新たなＩＤ付き文書"Doc4"を生成し、文書管理サーバ１０に登録する。user3のクライアント端末２０のＩＤ付き文書"Doc3"は、このＩＤ付き文書"Doc4"に置き換えられる。同様に、user4のクライアント端末２０において、ＩＤ付き文書"Doc3"に対して文書操作部２００によって「更新」操作が行われ、文書内容"Content4"を含み、親ＩＤが"Doc3"であり、操作種別の値が「更新」である新たなＩＤ付き文書"Doc5"が文書管理サーバ１０に登録される。user4のクライアント端末２０のＩＤ付き文書"Doc3"は、ＩＤ付き文書"Doc5"に置き換えられる。
【００６２】
次に、user5が、自分のクライアント端末２０の文書操作部２００によって、管理ＩＤ"Doc4"の文書を文書管理サーバ１０から「取得」する操作を行う。ここで、「取得」操作とは、クライアント端末２０の文書操作部２００によって、文書管理サーバ１０の記憶装置及び他のクライアント端末２０の記憶装置などに記憶されたＩＤ付き文書をダウンロードしたり、複製したりする操作を表す。この「取得」操作によって、親ＩＤが"Doc4"であり、操作種別の値が「取得」であるＩＤ付き文書"Doc6"が生成され、文書管理サーバ１０に登録される。なお、「取得」操作によってＩＤ付き文書３００の文書内容に変化は生じないので、ＩＤ付き文書"Doc6"の文書内容は、操作前のＩＤ付き文書"Doc4"の文書内容と同じ"Content3"のままである。
【００６３】
その後、user5は、自分のクライアント端末２０によって、ＩＤ付き文書"Doc6"に対して「更新」操作を行い、user5のクライアント端末２０は、文書内容"Content5"を含み、親ＩＤが"Doc6"であり、操作種別の値が「更新」である新たなＩＤ付き文書"Doc7"を生成して文書管理サーバ１０に登録し、クライアント端末２０におけるＩＤ付き文書"Doc6"をＩＤ付き文書"Doc7"に置き換える。
【００６４】
以上、派生関係ＤＢ１１０のデータ内容を例に取り、本システムにおける文書操作の情報の登録の様子を説明した。
【００６５】
図４の説明に戻り、組織情報ＤＢ１２０は、文書管理サーバ１０が管理する文書を利用する企業などの団体を構成する組織についての情報を記憶するデータベースである。組織情報ＤＢ１２０は、複数の組織が形成する組織階層の構造を表す情報と、各組織に所属する構成員に関する情報と、を記憶する。
【００６６】
企業などの団体は、一般に、図７に例示するように、階層構造を形成する複数の組織から構成される。組織情報ＤＢ１２０は、例えば、図８の表のようなデータベースとして、図７に例示するような組織階層を表す情報を記憶する。図８を参照すると、団体を構成する各組織の組織名に対応づけて、当該組織に対して組織階層において一段階上位に位置する上位組織の組織名が記憶される。例えば、図７に例示する組織階層において、１Ｇ（グループ）に対して一段階上位に位置するＸ部は、図８の表において、組織名１Ｇの上位組織として対応づけて記憶されている。また、図７の例で１Ｇの下位に位置する組織である１Ｔ（チーム）及び２Ｔについては、図８の表において、組織名１Ｔ及び２Ｔのそれぞれの上位組織として１Ｇが対応づけられている。図８に例示する表は、組織階層の構造を表す情報の表現形式の一例であり、組織階層の構造を表すことができさえすれば、他の表現形式で組織情報ＤＢ１２０に記憶させておいてもよい。
【００６７】
さらに、組織情報ＤＢ１２０には、団体を構成する各組織に所属する構成員についての情報が記憶される。図９に、組織情報ＤＢ１２０に記憶される各組織の構成員についての情報の内容の例を示す。図９の表における１行の情報は、各組織に所属する１人の構成員に対応するレコードである。図９の例では、各構成員のユーザＩＤに対応づけて、所属組織、及び役職の各項目が登録されている。ユーザＩＤは、文書管理システムにおけるユーザの識別情報であり、文書管理システムを用いる団体の各構成員に、１つのユーザＩＤが割り当てられる。所属組織の項目には、団体を構成する複数の組織のうち、その構成員が所属する組織を表す情報が登録される。例えば企業などにおいて、１人の者が複数の組織の業務を兼任で行う場合がある。この場合は、その構成員が複数の組織に所属することを示す情報を所属組織の項目に登録しておけばよい。図９に示す例では、ユーザＩＤがuser8である構成員は、組織１Ｔの業務及び組織２Ｔの業務を兼任で行う者であり、user8のレコードの所属組織の項目には、「１Ｔ，２Ｔ」と登録されている。また、役職の項目は、組織における各構成員の役職の有無を示す。図９に例示する表では、各構成員のレコードの役職の項目に「○」が登録されている場合は、その構成員が組織のリーダなどの役職を有することを示し、「×」が登録されている場合は、その構成員が役職を有しないことを示す。
【００６８】
なお、組織情報ＤＢ１２０における各組織の構成員を表す情報の表現形式は、図９に例示する形式に限られない。例えば、構成員ごとのレコードを組織情報ＤＢ１２０に登録する代わりに、組織ごとのレコードを登録し、各組織に対応するレコードに、その組織の構成員のユーザＩＤ及び役職者のユーザＩＤを登録するようにしてもよい。
【００６９】
以上で説明した派生関係ＤＢ１１０及び組織情報ＤＢ１２０によると、文書管理サーバ１０において、派生関係ＤＢ１１０に登録された各ＩＤ付き文書の操作者を表す情報と、組織情報ＤＢ１２０に登録された各組織の構成員を表す情報と、を照合することで、各ＩＤ付き文書の操作者の所属組織が特定される。また、組織情報ＤＢ１２０に記憶される組織階層の構造を表す情報を用いると、そのＩＤ付き文書の操作者の所属組織の組織階層における位置が特定される。
【００７０】
図４の説明に戻り、要求処理部１４０は、クライアント端末２０からの管理ＩＤを含んだサービス要求に応じて、派生関係ＤＢ１１０を用いたサービスを提供する。要求処理部１４０が提供するサービスとしては、例えば、サービス要求中の管理ＩＤに対応する文書の最新版を検索するサービスがある。また別の例として、サービス要求中の管理ＩＤに対応する始祖（根）の文書又はその始祖についてのログ情報を提供するサービスを挙げることができる。また、別の例として、その管理ＩＤの来歴、すなわち始祖からその管理ＩＤまでに文書が経てきた操作の履歴（例えば誰がいつどんな操作をしたのかを示す情報のリスト）を提供するサービスもある。また、派生関係ＤＢ１１０に登録された属性項目についての検索条件の指定を受け付け、その検索条件を満足するＩＤ付き文書のリストを提供するサービスもある。このサービスに付随して、要求処理部１４０は、そのリストの中からユーザの所望するＩＤ付き文書の選択を受け付け、選択されたＩＤ付き文書を提供してもよい。なお、上述の最新版を検索するサービスは、「操作日時が最新である」という検索条件についての検索結果を提供するサービスと捉えることもできる。また、上述の始祖の文書の情報を提供するサービスは、「ノードアドレスが根を示す文書」という条件についての検索結果を提供するサービスと捉えることができる。また、別の例として、派生関係ＤＢ１１０に基づきＩＤ付き文書群の派生関係を表す木構造の表示画面を提供し、その表示画面上でユーザの所望するＩＤ付き文書の選択を受け付け、選択されたＩＤ付き文書を提供するサービスもある。
【００７１】
サービス要求は、クライアント端末２０に保持されたＩＤ付き文書に基づき発せられる。例えば、ユーザがクライアント端末２０の文書操作部２００によりＩＤ付き文書を開いた場合に、文書操作部２００が、派生関係を用いたサービスのメニューを提供し、そのメニューの中からユーザが所望するサービスの指定を受け付ける。そして、そのＩＤ付き文書の管理ＩＤと指定されたサービスを示すコードとを含むサービス要求を文書管理サーバ１０の要求処理部１４０に送信する。このとき、ユーザ識別情報や操作日時などの属性項目についての検索条件を指定するユーザインタフェース画面を提供し、この画面を介して入力された検索条件を併せて要求処理部１４０に送信してもよい。また、管理ＩＤと、サービスを示すコード、検索条件以外に、指示を行ったユーザの識別情報や、ユーザの入力した認証情報などといった他の情報を、クライアント端末２０から要求処理部１４０に送信するようにしてもよい。
【００７２】
また別の例として、ユーザによるサービスの指定を一つの「操作」と捉え、その「操作」に対して新たに管理ＩＤを付与することも考えられる。この場合、指定されたサービスのコードを操作種別として含み、指定の際に用いられた元のＩＤ付き文書の管理ＩＤを親ＩＤとして含んだＩＤ付き文書を生成し、このＩＤ付き文書をサービス要求として文書管理サーバ１０に送ってもよい。この場合、要求処理部１４０は、受け取ったＩＤ付き文書内の操作種別の情報に基づき提供すべきサービスを判定し、同じくＩＤ付き文書内の親ＩＤを、派生関係を遡る処理の起点とする。
【００７３】
要求処理部１４０は、クライアント端末２０からサービス要求を受けた場合、そのサービス要求中に指定された管理ＩＤを起点に、派生関係ＤＢ１１０に登録された管理ＩＤと親ＩＤとの派生関係が構成する木を走査（トラバース）し、その走査の結果得られた情報を用いて、ユーザから要求されたサービスを実行する。
【００７４】
また、本実施形態において、要求処理部１４０は、アクセス制御部１４２を含む。アクセス制御部１４２は、クライアント端末２０から特定の文書の提供を要求するサービス要求を受けた場合に、クライアント端末２０に対する文書の提供を許可するか否かを決定する。例えば、上述のような、指定された検索条件を満足するＩＤ付き文書のリスト又はＩＤ付き文書群の派生関係を表す木構造の表示画面を提供し、ユーザの所望するＩＤ付き文書の選択を受け付け、選択されたＩＤ付き文書を提供するサービスにおいて、アクセス制御部１４２は、当該ユーザに対して、選択されたＩＤ付き文書の提供を許可するか否かを決定する。
【００７５】
本実施形態では、例えば、組織階層における上位組織から下位組織に文書が配布され、それぞれの配布先において当該文書が更新される場合に、組織階層において、より下位に位置する組織に配布された文書ほど、アクセスを許可されるユーザが少なくなるように、文書に対するアクセス制御が行われる。このような状況の一例として、企業における人事考課で使用する活動評価文書などの文書の配布及び更新について説明する。このような文書は、まず、上位組織が決定した活動方針などを書き込んだ文書として上位組織の役職者によって作成され、各下位組織の役職者（リーダなど）に配布される。各組織の役職者は、配布された文書に対して、自身の組織の活動目標及び活動内容などを書き込むことでその文書を更新した後、更新後の文書を自身の組織の構成員（メンバ）に展開する。組織の各構成員は、自組織のリーダから展開された文書に対して、個人的な活動目標及び活動内容などを書き込む。このような場合、各組織の活動内容など、各組織のリーダによって文書に書き込まれる内容は、他の組織に対しては開示しない研究テーマなどの情報を含むことがある。また、各個人が文書に書き込む内容は、例えば個人のキャリア設計に関する情報など、その個人の上司に該当する者（その個人の所属組織のリーダなど）以外の者には開示しない情報を含むことがある。
【００７６】
以上で説明した例のような状況において、アクセス制御部１４２は、派生関係ＤＢ１１０及び組織情報ＤＢ１２０に記憶された情報を用いて、ＩＤ付き文書のアクセス制御を行う。具体的には、アクセス制御部１４２は、ＩＤ付き文書に対するアクセス要求が以下の（条件１）又は（条件２）に適合するか否かを判定することで、要求者に対してそのＩＤ付き文書へのアクセスを許可するか否かを決定する。
【００７７】
・（条件１）ＩＤ付き文書の派生関係群が示す木構造において、要求者自身の操作によって文書管理サーバ１０に登録されたＩＤ付き文書を根ノードとする部分木に含まれるＩＤ付き文書に対するアクセス要求は許可する。
・（条件２）要求者の所属組織から組織階層を遡った経路上に含まれる組織のいずれかに、要求対象のＩＤ付き文書の操作者が所属し、かつ、要求対象のＩＤ付き文書が、組織階層における上位組織の役職者から一段階ずつ下位に位置する組織の役職者によって順に更新登録された履歴を有する場合、アクセス要求を許可する。
【００７８】
（条件１）は、あるユーザが、自分自身の操作によって文書管理サーバ１０に登録されたＩＤ付き文書及び当該ＩＤ付き文書から派生したＩＤ付き文書に対してアクセスできるようにするための条件である。例えば、組織の役職者が更新登録したＩＤ付き文書に対して当該組織の構成員が書き込みを行って更新登録したＩＤ付き文書について、当該組織の役職者がアクセスできるようにする。
【００７９】
（条件２）の前半部の条件は、要求者の所属組織に所属するユーザ又は要求者の所属組織に対して組織階層において直系の上位に位置する組織に所属するユーザが更新登録したＩＤ付き文書でなければ、アクセスを許可しないようにするための条件である。この条件によると、例えば、図７に例示する組織階層の組織１Ｔに所属するユーザは、例えば組織２Ｔ及び組織Ｙ部など、組織１Ｔの直系の上位に位置しない組織に所属するユーザが更新登録したＩＤ付き文書に対してはアクセスを許可されない。
【００８０】
（条件２）の後半部の条件によると、組織階層における上位組織の役職者から下位組織の役職者へ順次配布及び更新されたＩＤ付き文書は正規の展開経路を経ているとみなされ、正規の展開経路を経ていないＩＤ付き文書に対するアクセスは許可されない。例えば、図７に例示する組織階層の組織Ｘ部の役職者が更新登録したＩＤ付き文書について、組織Ｘ部の一段階下位の組織１Ｇの役職者による更新登録を経ることなく、組織１Ｇの一段階下位の組織１Ｔの役職者が更新登録を行った結果のＩＤ付き文書は、正規の展開経路を経ていないとみなされる。
【００８１】
以下、アクセス制御部１４２が行う処理の詳細な手順について説明する。
【００８２】
図１０及び図１１に、アクセス制御部１４２において、指定されたＩＤ付き文書の提供を許可するか否かを決定する処理の手順の例を示す。
【００８３】
アクセス制御部１４２は、要求処理部１４０において、ユーザに対するＩＤ付き文書の提供の可否を決定する必要が生じた場合に、図１０に例示する手順の処理を開始する。
【００８４】
図１０を参照し、アクセス制御部１４２は、ステップＳ１０で初期化処理を行う。ステップＳ１０では、注目ユーザＩＤ（以下、「注目ユーザｕ」とも呼ぶ）として文書の提供を要求したユーザのユーザＩＤが設定され、注目管理ＩＤ（以下、「注目文書ｒ」とも呼ぶ）として要求対象のＩＤ付き文書の管理ＩＤが設定される。さらに、ステップＳ１０では、「順次性チェック」と呼ばれるフラグの値がtrueに設定される。順次性チェックフラグは、上述の（条件２）を満たすか否かを示すフラグである。
【００８５】
次に、ステップＳ１２で、アクセス制御部１４２は、派生関係ＤＢ１１０を参照し、管理ＩＤとして注目文書ｒが登録されたレコードを読み出し、当該レコードの操作者の項目に登録されたユーザＩＤ（すなわち、注目文書ｒの操作者のユーザＩＤ）を取得する。そして、取得したユーザＩＤと、ＩＤ付き文書の提供要求を行った要求者のユーザＩＤと、が一致するか否かを判定する。図１０に例示するフローチャートにおいては、派生関係ＤＢ１１０から取得される、注目文書ｒの操作者のユーザＩＤを「Ｏ（ｒ）」と記載し、以下の説明においても、この記載を用いる。ステップＳ１２で、Ｏ（ｒ）が要求者のユーザＩＤと一致する場合は、ステップＳ２４に進む。この場合、上述の（条件１）を満たすことになる。ステップＳ２４では、アクセス制御部１４２は、要求対象の文書に対するアクセスを許可することを決定し、処理を終了する。
【００８６】
ステップＳ１２で、Ｏ（ｒ）が要求者のユーザＩＤと一致しない場合、処理はステップＳ１４に進む。
【００８７】
ステップＳ１４では、アクセス制御部１４２は、組織情報ＤＢ１２０を参照し、注目文書ｒの操作者のユーザＩＤであるＯ（ｒ）に対応付けられた所属組織と、注目ユーザｕに対応付けられた所属組織と、を取得し、両者が一致するか否かを判定する。図１０に例示するフローチャートでは、組織情報ＤＢ１２０から取得される、特定のユーザＩＤ：ｕｉｄのユーザの所属組織をＧ（ｕｉｄ）と記載する。以下の説明においても、この記載を用いる。この記載に従って、注目文書ｒの操作者Ｏ（ｒ）の所属組織はＧ（Ｏ（ｒ））と表され、注目ユーザｕの所属組織はＧ（ｕ）と表される。
【００８８】
なお、ここで説明する処理の例において、ステップＳ１４における所属組織Ｇ（Ｏ（ｒ））とＧ（ｕ）とが一致するか否かの判定は、組織間の包含関係を考慮せずに行われる。例えば、図７に例示する構造を有する組織階層において、組織１Ｇは、組織１Ｔ及び組織２Ｔに対して一段階上位に位置し、組織１Ｇは、組織１Ｔ及び組織２Ｔを含んでいると捉えることもできる。しかしながら、ステップＳ１４での所属組織同士の照合においては、組織１Ｇと、組織１Ｔ又は組織２Ｔと、は一致しないと判定される。また、例えば図９の表におけるuser8のように複数の組織に所属するユーザについては、そのユーザの複数の所属組織のいずれかと、照合対象のユーザの所属組織と、が一致していれば、両ユーザの所属組織は一致すると判定するものとする。
【００８９】
ステップＳ１４で、注目文書ｒの操作者の所属組織Ｇ（Ｏ（ｒ））と注目ユーザｕの所属組織Ｇ（ｕ）とが一致すると判定された場合、処理はステップＳ１６に進む。
【００９０】
ステップＳ１６で、アクセス制御部１４２は、組織情報ＤＢ１２０を参照し、注目文書ｒの操作者Ｏ（ｒ）が役職を有する者であるか否かを判定する。例えば、組織情報ＤＢ１２０に図９に例示する表の内容の情報が記憶されている場合、Ｏ（ｒ）に対応するレコードの役職者の項目に「○」が登録されていれば、Ｏ（ｒ）が役職者であると判定し、「×」が登録されていれば、役職者でないと判定する。
【００９１】
ステップＳ１６で、注目文書ｒの操作者Ｏ（ｒ）が役職者であると判定されると、ステップＳ１７に進む。ステップＳ１７では、アクセス制御部１４２は、ＩＤ付き文書の派生関係群が表す木構造において、注目文書ｒを起点に１つずつＩＤ付き文書（ノード）を遡っていき、操作種別の値が「更新」又は「登録」であるノードを最初に発見した時点で、当該ノードの操作者を取得する。派生関係ＤＢ１１０において注目文書ｒのレコードに親ＩＤとして登録されている管理ＩＤのレコードを取得し、当該レコードに登録されている操作種別の値が「更新」又は「登録」であれば、当該レコードに含まれる操作者の項目に登録されたユーザＩＤを取得し、操作種別の値が「更新」及び「登録」以外の値であれば、当該レコードに登録されている親ＩＤの値を管理ＩＤとして含むレコードを取得し、そのレコードの操作種別の値が「更新」又は「登録」であるか否かを判定する。このような処理を繰り返すことで、アクセス制御部１４２は、注目文書ｒから木構造を遡って最初に発見された操作種別「更新」又は「登録」のノードの管理ＩＤ（図１０のフローチャートではＰ（ｒ）と表す）に対応づけられた操作者Ｏ（Ｐ（ｒ））を取得する。なお、注目文書ｒが木構造の根ノードに該当する文書である場合、つまり、注目文書ｒを管理ＩＤとして含むレコードの親ＩＤの値が「なし（null）」である場合、注目文書ｒを起点に木構造を遡ることはできないので、アクセス制御部１４２は、操作者Ｏ（Ｐ（ｒ））の値として、操作者Ｏ（Ｐ（ｒ））を取得できない旨を示す情報（例えば、「なし（null）」）を設定する。操作者Ｏ（Ｐ（ｒ））の値が決定されると、アクセス制御部１４２は、操作者Ｏ（Ｐ（ｒ））と、注目文書ｒの操作者Ｏ（ｒ）と、が一致するか否かを判定し、一致しなければステップＳ１８に進み、一致すれば、ステップＳ１９で、注目文書ｒから木構造を遡って最初に発見された操作種別「更新」又は「登録」のノードＰ（ｒ）を新たな注目文書ｒとして設定する。ステップＳ１９の後、再びステップＳ１７の判定が行われる。
【００９２】
ここで、Ｐ（ｒ）は、ＩＤ付き文書の派生関係群が表す木構造において、要求対象のＩＤ付き文書に対して先祖に該当するＩＤ付き文書であると言える。一般に、木構造において、ある注目ノードを起点に根ノードまで木構造を遡った経路上に含まれるノードは、その注目ノードの「先祖」と呼ばれる。
【００９３】
ステップＳ１８では、アクセス制御部１４２は、組織情報ＤＢ１２０を参照し、組織階層において注目ユーザｕの所属組織Ｇ（ｕ）が最上位に位置する組織であるか否かを判定する。例えば、図８に例示する表のようなデータ内容が組織情報ＤＢ１２０に格納されている場合、アクセス制御部１４２は、組織情報ＤＢ１２０においてＧ（ｕ）に対応づけられた上位組織を調べ、上位組織の組織名が登録されていれば、Ｇ（ｕ）は組織階層において最上位に位置しないと判定し、上位組織の組織名が登録されていなければ（例えば、図８の組織名「全社」に対応づけて上位組織「なし」が登録されている）、Ｇ（ｕ）は組織階層において最上位に位置すると判定する。Ｇ（ｕ）が最上位に位置する組織でなければ、ステップＳ２０に進み、最上位に位置する組織であれば、ステップＳ２２に進む。
【００９４】
ステップＳ２０では、アクセス制御部１４２は、組織情報ＤＢ１２０を参照し、注目ユーザｕの所属組織に対して組織階層において一段階上位に位置する組織に所属する構成員のうちのいずれかのユーザＩＤを、新たな注目ユーザｕとして設定する。例えば、図８及び図９に例示する表のデータ内容が組織情報ＤＢ１２０に登録されている場合、図９の表を参照して注目ユーザｕの所属組織を取得し、次に、図８の表を参照して注目ユーザｕの所属組織に対応付けられた上位組織を取得する。そして、再び図９の表を参照し、所属組織の項目に取得した上位組織を含むレコードのうちの１つに含まれるユーザＩＤを取得する。図１０に例示するフローチャートでは、この一連の処理によって得られる、注目ユーザｕの所属組織に対して組織階層において一段階上位の組織に所属する者をＳｐ（ｕ）と記載し、以下の説明においても、この記載を用いる。
【００９５】
ステップＳ１６で、注目文書ｒの操作者Ｏ（ｒ）が役職者でないと判定されると、アクセス制御部１４２は、図１１に例示する手順の処理を行う。図１１に示す処理については後述する。
【００９６】
ステップＳ２０の後、ステップＳ２１で、アクセス制御部１４２は、注目文書ｒが、ＩＤ付き文書の派生関係群によって表される木構造において根ノードに該当するか否かを判定する。派生関係ＤＢ１１０に記憶されたレコードのうち、注目文書ｒを管理ＩＤとして含むレコードの親ＩＤの値が「なし（null）」であれば、木構造の根ノードであると判定され、親ＩＤとして他の管理ＩＤの値が登録されていれば根ノードではないと判定される。例えば、図５に例示するデータ内容が派生関係ＤＢ１１０に登録されている場合、親ＩＤの値が「なし」である管理ＩＤ"Doc5"のノードが派生関係の木構造（図６）の根ノードに該当する。
【００９７】
ステップＳ２１で注目文書ｒが根ノードであると判定されると、ステップＳ２２で、順次性チェックフラグがfalseに設定されているか否かが判定される。順次性チェックフラグがfalseに設定されていなければ、アクセス許可（ステップＳ２４）され、falseに設定されていれば、アクセスは許可されず、エラー（ステップＳ２６）となる。
【００９８】
ステップＳ２１で、注目文書ｒが根ノードではないと判定されると、ステップＳ２８に進む。ステップＳ２８で、アクセス制御部１４２は、ステップＳ１７において説明したのと同様の処理を行って、ＩＤ付き文書の派生関係群が表す木構造を注目文書ｒから遡って最初に発見された操作種別「更新」又は「登録」のノードの管理ＩＤ（Ｐ（ｒ））を取得し、取得した管理ＩＤ（Ｐ（ｒ））を新たな注目文書ｒとする。その後、処理はステップＳ１２に戻る。
【００９９】
以上、ステップＳ１４で、注目文書ｒの操作者の所属組織Ｇ（Ｏ（ｒ））と注目ユーザｕの所属組織Ｇ（ｕ）とが一致すると判定された場合の処理手順の例について説明した。以下、ステップＳ１４で、Ｇ（Ｏ（ｒ））とＧ（ｕ）とが一致しないと判定された場合の処理手順の例について説明する。この場合、ステップＳ１４の判定の結果、処理はステップＳ３０に進む。
【０１００】
ステップＳ３０では、順次性チェックフラグの値がfalseに設定されているか否かを判定する。falseに設定されていれば、ステップＳ３８に進み、falseに設定されていなければ、ステップＳ３２に進む。ステップＳ１０の初期化処理において、順次性チェックフラグの値はtrueに設定されるので、図１０に例示するフローチャートの処理を開始してから、初めてステップＳ３０の判定が行われる場合は、Ｎｏ判定されてステップＳ３２に進む。
【０１０１】
ステップＳ３２では、注目文書ｒが要求対象のＩＤ付き文書の管理ＩＤであるか否かを判定する。注目文書ｒが要求対象のＩＤ付き文書の管理ＩＤであれば、ステップＳ３４に進み、注目文書ｒが要求対象のＩＤ付き文書の管理ＩＤでなければ、ステップＳ３８に進む。ステップＳ１０の初期化処理の後、ステップＳ１２、ステップＳ１４、及びステップＳ３０のすべてにおいてＮｏ判定されてステップＳ３２の判定が行われる場合、注目文書ｒの値は、初期化処理（ステップＳ１０）で要求対象のＩＤ付き文書の管理ＩＤに設定されたまま変更されないので、ステップＳ３２では、Ｙｅｓ判定されてステップＳ３４に進む。一方、図１０に例示する手順の処理が開始されてから、一度でもステップＳ２８において注目文書ｒの値が変更された後にステップＳ３２の判定が行われると、Ｎｏ判定されてステップＳ３８に進む。
【０１０２】
ステップＳ３４で、アクセス制御部１４２は、組織情報ＤＢ１２０を参照し、組織階層において注目ユーザｕの所属組織Ｇ（ｕ）が最上位に位置する組織であるか否かを判定する。ステップＳ３４の判定処理は、上記で説明したステップＳ１８の判定処理と同様である。Ｇ（ｕ）が最上位に位置する組織でなければ、ステップＳ３６に進み、最上位に位置する組織であれば、ステップＳ３８に進む。
【０１０３】
注目ユーザｕの所属組織に対して上位組織が存在する場合、ステップＳ３６で、アクセス制御部１４２は、注目ユーザｕの所属組織に対して組織階層において一段階上位の組織に所属する者のユーザＩＤを新たな注目ユーザｕとして設定する。ステップＳ３６の後、処理はステップＳ１４に戻る。
【０１０４】
ステップＳ３０でＹｅｓ判定、ステップＳ３２でＮｏ判定、又はステップＳ３４でＹｅｓ判定された場合、ステップＳ３８で、順次性チェックフラグの値がfalseに設定される。ステップＳ３８の後、処理はステップＳ２１に進む。
【０１０５】
ステップＳ１４，Ｓ３０，Ｓ３２，Ｓ３４，Ｓ３６を含む処理ループでは、要求者の所属組織を起点に最上位の組織まで組織階層を遡った経路上に含まれる組織のいずれかに、要求対象のＩＤ付き文書の操作者が所属するか否か、つまり、上述の（条件２）の前半部の条件を満たすか否かが判定される。
【０１０６】
以上で説明した図１０に例示する手順では、要求対象のＩＤ付き文書の管理ＩＤを起点にＩＤ付き文書の派生関係群が表す木構造を遡る（ステップＳ１９，Ｓ２８）ことで得られるＩＤ付き文書の操作者の情報と、要求者のユーザＩＤを用いて組織階層を遡る（ステップＳ２０，Ｓ３６）ことで得られる組織の構成員の情報と、を照合する（ステップＳ１４）ことで、組織階層における要求者の位置づけと要求対象のＩＤ付き文書の流通経路とが適合するか否かを確認する。
【０１０７】
図１１を参照し、図１０のステップＳ１６で、注目文書ｒの操作者が役職者でないと判定された場合に行われる処理手順の例について説明する。注目文書ｒの操作者が役職者でないと判定された場合、上述の（条件２）の後半部の条件（要求対象のＩＤ付き文書が、組織階層における上位組織の役職者から一段階ずつ下位に位置する組織の役職者によって順に更新登録された履歴を有すること）を満たさない。よって、図１１に例示する手順の処理では、上述の（条件１）を満たすか否かが判定される。
【０１０８】
図１０のステップＳ１６でＮｏ判定されると、図１１のステップＳ４０に進む。ステップＳ４０で、アクセス制御部１４２は、図１０を参照して説明したステップＳ２１の処理と同様に、注目文書ｒがＩＤ付き文書の派生関係群が表す木構造における根ノードに該当するか否かを判定する。注目文書ｒが根ノードである場合、ステップＳ４８のエラー処理が行われ、処理は終了する。
【０１０９】
注目文書ｒが根ノードでない場合、ステップＳ４２に進み、図１０を参照して説明したステップＳ２８の処理と同様に、注目文書ｒから派生関係群の木構造を遡って最初に発見される、操作種別の値が「更新」又は「登録」であるノードの管理ＩＤが新たな注目文書ｒとされる。次に、ステップＳ４４で、注目文書ｒの操作者Ｏ（ｒ）と、要求者のユーザＩＤと、が一致するか否かが判定され、一致すればステップＳ４６に進み、一致しなければステップＳ４０に戻る。ステップＳ４６で、アクセス制御部１４２は、要求対象のＩＤ付き文書に対するアクセスを許可し、処理を終了する。
【０１１０】
以上、図１０及び図１１に例示する手順の処理により、アクセス制御部１４２がアクセス許可した（ステップＳ２４，Ｓ４６）場合、要求処理部１４０は、要求対象のＩＤ付き文書に対応する文書内容を文書ＤＢ１００から取得し、取得した文書内容をクライアント端末２０に対して送信する。一方、図１０及び図１１に例示する手順の処理により、アクセス制御部１４２がエラーとした（ステップＳ２６，Ｓ４８）場合、要求処理部１４０は、要求対象のＩＤ付き文書に対応する文書内容をクライアント端末２０に送信しない。エラーの場合、例えば、ＩＤ付き文書に対するアクセスが許可されない旨を示すエラーメッセージをクライアント端末２０の表示部に表示させる。
【０１１１】
以下、図５に例示する表のデータ内容が派生関係ＤＢ１１０に登録され、図８及び図９に例示する表のデータ内容が組織情報ＤＢ１２０に登録されている場合に、図１０及び図１１に例示する手順の処理によるアクセス制御の具体例について説明する。
【０１１２】
＜具体例１＞
上述の（条件１）を満たす場合の例として、図５及び図６を参照し、ユーザＩＤ"user5"を有するユーザが、管理ＩＤ"Doc7"のＩＤ付き文書の提供を要求した場合のアクセス制御部１４２の処理について説明する。この場合、図１０のステップＳ１０で、注目ユーザｕはuser5、注目文書ｒは"Doc7"に設定される。図５の表において、管理ＩＤ"Doc7"のレコードには操作者としてuser5が登録されており、図１０のステップＳ１２で、注目文書ｒ"Doc7"の操作者はuser5であり、注目ユーザｕと一致するため、アクセスが許可される（ステップＳ２４）。
【０１１３】
＜具体例２＞
上述の（条件１）を満たす他の例として、図５及び図６を参照し、ユーザＩＤ"user3"のユーザが、管理ＩＤ"Doc7"のＩＤ付き文書の提供を要求した場合のアクセス制御部１４２の処理について説明する。この場合、図１０のステップＳ１０で、注目ユーザｕはuser3、注目文書ｒは"Doc7"に設定される。ステップＳ１２で、注目文書ｒ"Doc7"の操作者はuser5であり、注目ユーザｕであるuser3と一致しないので、ステップＳ１４に進む。ステップＳ１４で、組織情報ＤＢ１２０（図９）を参照すると、注目文書ｒ"Doc7"の操作者であるuser5の所属組織１Ｔと、注目ユーザｕであるuser3の所属組織１Ｔと、が一致するので、処理はステップＳ１６に進む。注目文書ｒ"Doc7"の操作者であるuser5は、役職者ではない（図９参照）ので、ステップＳ１６の判定の結果、処理は図１１のステップＳ４０に進む。図１１のステップＳ４０で、注目文書ｒ"Doc7"は文書の派生関係の木構造の根ノードではないので、ステップＳ４２に進み、注目文書ｒ"Doc7"を起点に木構造を遡って最初に発見される「更新」操作のノードの管理ＩＤ"Doc4"が新たな注目文書ｒとして設定される。次に、ステップＳ４４で、この新たな注目文書ｒ"Doc4"の操作者はuser3であり、要求者のユーザＩＤであるuser3と一致するので、アクセスが許可される（ステップＳ４６）。
【０１１４】
＜具体例３＞
（条件２）を満たす例として、ユーザＩＤ"user5"のユーザが、ＩＤ付き文書"Doc4"の提供を要求した場合について説明する。まず、図１０のステップＳ１０で、注目ユーザｕはuser5、注目文書ｒは"Doc4"に設定される。ステップＳ１２で、注目文書ｒ"Doc4"の操作者はuser3であり、注目ユーザｕであるuser5と一致しないので、ステップＳ１４に進む。ステップＳ１４で、組織情報ＤＢ１２０（図９）を参照すると、注目文書ｒ"Doc4"の操作者user3の所属組織１Ｔと、注目ユーザｕであるuser5の所属組織１Ｔと、が一致するので、処理はステップＳ１６に進む。注目文書ｒ"Doc4"の操作者であるuser3は、役職者である（図９参照）ので、ステップＳ１７に進む。注目文書ｒ"Doc4"の操作者であるuser3と、注目文書ｒ"Doc4"を起点に木構造を遡って最初に発見される「更新」ノード"Doc3"の操作者であるuser2と、は一致しないので、ステップＳ１７の判定の結果、ステップＳ１８に進む。注目ユーザｕであるuser5の所属組織１Ｔは最上位組織ではないので、ステップＳ１８の判定の結果、ステップＳ２０に進み、user5の所属組織１Ｔに対して組織階層において一段階上位に位置する組織１Ｇ（図７及び図８参照）に所属する者であるuser2（図９参照）が新たな注目ユーザｕとして設定される。注目文書ｒ"Doc4"は、文書の派生関係の木構造の根ノードではないので、ステップＳ２１の判定の結果、ステップＳ２８に進み、注目文書ｒ"Doc4"を起点に木構造を遡って最初に発見される「更新」ノードの管理ＩＤ"Doc3"が新たな注目文書ｒとして設定される。
【０１１５】
その後、ステップＳ１２で、注目文書ｒ"Doc3"の操作者であるuser2と、要求者であるuser5と、が一致しないので、再びステップＳ１４の判定が行われる。ステップＳ１４では、現在の注目文書ｒ"Doc3"の操作者であるuser2の所属組織１Ｇと、現在の注目ユーザｕであるuser2の所属組織１Ｇと、が一致するので、ステップＳ１６に進む。さらに、注目文書ｒ"Doc3"の操作者であるuser2は役職者であるので（図９参照）、ステップＳ１７に進む。user2は、注目文書ｒ"Doc3"を起点に木構造を遡って最初に発見される「登録」ノード"Doc1"の操作者であるuser1と一致しないので、ステップＳ１７の判定の結果、ステップＳ１８に進む。ステップＳ１８で、注目ユーザｕ（user2）の所属組織１Ｇは最上位組織ではないので、判定の結果ステップＳ２０に進み、組織１Ｇに対して組織階層において一段階上位の組織Ｘ部（図７及び図８参照）に所属する者であるuser1（図９参照）が新たな注目ユーザｕとして設定される。次に、現在の注目文書ｒ"Doc3"は、文書の派生関係の木構造の根ノードではないので（ステップＳ２１でＮｏ判定）、注目文書ｒ"Doc3"から木構造を遡って最初に発見される「登録」ノードの管理ＩＤ"Doc1"が新たな注目文書ｒとして設定される（ステップＳ２８）。
【０１１６】
さらに、ステップＳ１２で、注目文書ｒ"Doc1"の操作者であるuser1と、要求者であるuser5と、が一致しないのでステップＳ１４に進み、現在の注目文書ｒ"Doc1"の操作者であるuser1の所属組織Ｘ部と、現在の注目ユーザｕであるuser1の所属組織Ｘ部と、が一致するので、ステップＳ１６に進む。注目文書ｒ"Doc1"の操作者であるuser1は役職者であるので（図９参照）、ステップＳ１７に進む。注目文書ｒ"Doc1"は木構造の根ノードであり、注目文書ｒ"Doc1"を起点に遡って発見される「更新」又は「登録」ノードＰ（"Doc1"）は存在しないため、ステップＳ１７でＮｏ判定され、ステップＳ１８に進む。ステップＳ１８では、user1の所属組織Ｘ部は最上位組織ではないためＮｏ判定されてステップＳ２０に進み、user1の所属組織Ｘ部の上位組織に所属するユーザのユーザＩＤが注目ユーザｕとして設定され、ステップＳ２１に進む。ステップＳ２１で、現在の注目文書ｒ"Doc1"は根ノードであるのでステップＳ２２に進む。以上で説明した本例の処理では、順次性チェックフラグの値は、初期化処理（ステップＳ１０）でtrueに設定されたまま変更されないので、ステップＳ２２の判定の結果、ステップＳ２４に進み、要求対象のＩＤ付き文書"Doc4"に対するアクセスが許可される。
【０１１７】
＜具体例４＞
正規の展開経路を経ていないＩＤ付き文書に対するアクセス要求であることから上述の（条件２）を満たさない例として、ユーザＩＤ"user5"のユーザが、ＩＤ付き文書"Doc13"の提供を要求した場合について説明する。ＩＤ付き文書"Doc13"は、user3が、組織階層において自己の所属組織１Ｔに対して二段階上位に位置する組織Ｘ部に所属するuser1によって更新登録されたＩＤ付き文書"Doc1"を更新した結果の文書である。つまり、ＩＤ付き文書"Doc13"は、user3の所属組織１Ｔに対して一段階上位の組織１Ｇに所属するuser2による更新操作を経ることなく生成された文書である。このように、ＩＤ付き文書"Doc13"は、上述の（条件２）を満たさないので、ＩＤ付き文書"Doc13"に対するアクセス要求は許可されない。以下、この例の場合のアクセス制御部１４２の処理について説明する。
【０１１８】
図１０のステップＳ１０で、注目ユーザｕはuser5、注目文書ｒは"Doc13"に設定される。次に、ステップＳ１２で、注目文書ｒ"Doc13"の操作者はuser3であり、注目ユーザｕであるuser5と一致しないので、ステップＳ１４に進む。ステップＳ１４で、組織情報ＤＢ１２０（図９）を参照すると、注目文書ｒ"Doc13"の操作者であるuser3の所属組織１Ｔと、注目ユーザｕであるuser5の所属組織１Ｔと、が一致するので、処理はステップＳ１６に進み、注目文書ｒ"Doc13"の操作者user3は役職者であるので、ステップＳ１７に進む。注目文書ｒ"Doc13"の操作者user3と、注目文書ｒ"Doc13"を起点に木構造を遡って最初に発見される「登録」ノード"Doc1"の操作者であるuser1と、は一致しないため、ステップＳ１７の判定の結果、ステップＳ１８に進む。注目ユーザｕであるuser5の所属組織１Ｔは、最上位組織ではないので、ステップＳ１８の判定の結果ステップＳ２０に進み、user5の所属組織１Ｔに対して組織階層において一段階上位に位置する組織１Ｇ（図７及び図８参照）に所属する者であるuser2（図９参照）が新たな注目ユーザｕとして設定される。次に、注目文書ｒ"Doc13"は、文書の派生関係の木構造の根ノードではないので、ステップＳ２１の判定の結果、ステップＳ２８に進み、注目文書ｒ"Doc13"を起点に木構造を遡って最初に発見される「登録」ノードの管理ＩＤ"Doc1"が新たな注目文書ｒとして設定される。
【０１１９】
その後、ステップＳ１２で、注目文書ｒ"Doc1"の操作者であるuser1と、要求者であるuser5と、が一致しないので、再びステップＳ１４の判定が行われる。現在の注目文書ｒ"Doc1"の操作者であるuser1の所属組織Ｘ部と、現在の注目ユーザｕであるuser2の所属組織１Ｇと、が一致しないため、ステップＳ１４の判定の結果、ステップＳ３０に進む。この時点で、順次性チェックフラグの値は、ステップＳ１０でtrueに設定されたまま変更されていないので、ステップＳ３０の判定の結果、ステップＳ３２に進む。現在の注目文書ｒ"Doc1"は、要求対象のＩＤ付き文書の管理ＩＤ"Doc13"と一致しないので、処理は、ステップＳ３２からステップＳ３８に進み、順次性チェックフラグの値がfalseに設定される。その後、注目文書ｒ"Doc1"は、派生関係の木構造の根ノードであるので、ステップＳ２１からステップＳ２２に進む。順次性チェックフラグの値がfalseに設定されているため、ステップＳ２２の判定の結果ステップＳ２６のエラー処理が行われ、ＩＤ付き文書"Doc13"に対するアクセスは許可されない。
【０１２０】
＜具体例５＞
正規の展開経路を経ていない文書に対するアクセス要求であることから（条件２）を満たさない他の例として、ユーザＩＤ"user7"のユーザが、ＩＤ付き文書"Doc10"の提供を要求した場合について説明する。ＩＤ付き文書"Doc10"は、user4が、自己の所属組織２Ｔと異なる組織であって組織階層において同じ階層に位置する（上位下位の関係にない）組織１Ｔに所属するuser3によって更新登録されたＩＤ付き文書"Doc4"に対して更新操作を行った結果の文書である。よって、ＩＤ付き文書"Doc10"の操作者であるuser4は、組織２Ｔの役職者ではあるが、ＩＤ付き文書"Doc10"は、正規の展開経路を経ているとは言えない。したがって、user4と同じ組織２Ｔに所属するuser7が要求者であっても、ＩＤ付き文書"Doc10"に対するアクセスは許可されない。以下、この例のアクセス制御部１４２における処理を説明する。
【０１２１】
図１０のステップＳ１０で、注目ユーザｕはuser7、注目文書ｒは"Doc10"に設定される。次に、ステップＳ１２で、注目文書ｒ"Doc10"の操作者はuser4であり、注目ユーザｕであるuser7と一致しないので、ステップＳ１４に進む。ステップＳ１４で、組織情報ＤＢ１２０（図９）を参照すると、注目文書ｒ"Doc10"の操作者であるuser4の所属組織２Ｔと、注目ユーザｕであるuser7の所属組織２Ｔと、が一致するので、処理はステップＳ１６に進み、注目文書ｒ"Doc10"の操作者であるuser4は役職者であるので、ステップＳ１７に進む。注目文書ｒ"Doc10"の操作者であるuser4と、注目文書ｒ"Doc10"を起点に木構造を遡って最初に発見される「更新」ノード"Doc4"の操作者であるuser3と、は一致しないので、ステップＳ１７の判定の結果、ステップＳ１８に進む。注目ユーザｕであるuser7の所属組織２Ｔは最上位組織ではないので、ステップＳ１８の判定の結果、ステップＳ２０へ進み、user7の所属組織２Ｔに対して組織階層において一段階上位に位置する組織１Ｇ（図７及び図８参照）に所属する者であるuser2（図９参照）が新たな注目ユーザｕとして設定される。
【０１２２】
次に、注目文書ｒ"Doc10"は、文書の派生関係の木構造の根ノードではないので、ステップＳ２１の判定の結果、ステップＳ２８に進み、注目文書ｒ"Doc10"を起点に木構造を遡って最初に発見される「更新」ノードの管理ＩＤ"Doc4"が新たな注目文書ｒとして設定される。
【０１２３】
その後、ステップＳ１２で、注目文書ｒ"Doc4"の操作者であるuser3と、要求者であるuser7と、が一致しないので、再びステップＳ１４の判定が行われる。現在の注目文書ｒ"Doc4"の操作者であるuser3の所属組織１Ｔと、現在の注目ユーザｕであるuser2の所属組織１Ｇと、が一致しないため、ステップＳ１４の判定の結果、ステップＳ３０に進む。この時点で、順次性チェックフラグの値は、ステップＳ１０でtrueに設定されたまま変更されていないので、ステップＳ３０の判定の結果、ステップＳ３２に進む。現在の注目文書ｒ"Doc4"は、要求対象のＩＤ付き文書の管理ＩＤ"Doc10"と一致しないので、処理は、ステップＳ３２からステップＳ３８に進み、順次性チェックフラグの値がfalseに設定される。
【０１２４】
その後、注目文書ｒ"Doc4"は根ノードでないので、"Doc4"から木構造を遡って最初に発見される「更新」ノード"Doc3"が新たな注目文書ｒとして設定され（ステップＳ２１，Ｓ２８）、ステップＳ１２以降の処理が繰り返される。以降の繰り返し処理において、注目文書ｒ"Doc3"の操作者、及び、"Doc3"の次に注目文書ｒとして設定される"Doc1"の操作者は、それぞれ、user2及びuser1であり、要求者であるuser7とは一致しないので、ステップＳ１２でＹｅｓ判定されてアクセス許可（ステップＳ２４）されることはない。よって、派生関係の木構造の根ノードである"Doc1"が注目文書ｒとして設定された後、処理が進むと、ステップＳ２２で、順次性チェックフラグの値の判定が行われる。この時点で、順次性チェックフラグの値は、上述のように、ステップＳ３８でfalseに設定されているので、ステップＳ２２の判定の結果、ステップＳ２６のエラー処理に進み、ＩＤ付き文書"Doc10"に対するアクセスは許可されない。
【０１２５】
＜具体例６＞
要求者の所属組織と異なる組織であって要求者の所属組織と組織階層において同じ階層に位置する組織に所属するユーザによって更新登録されたＩＤ付き文書に対するアクセス制御の例について説明する。この場合、上述の（条件２）の前半部の条件（要求者の所属組織から組織階層を遡った経路上に含まれる組織のいずれかに、要求対象のＩＤ付き文書の操作者が所属すること）を満たさないので、アクセス許可されない。例えば、組織２Ｔに所属するuser7が、組織１Ｔに所属するuser3が更新登録したＩＤ付き文書"Doc4"の提供を要求した場合、要求者user7の所属組織２Ｔを起点に組織階層を遡った経路上に含まれる組織（２Ｔ，１Ｇ，Ｘ部，…，全社）の中に、要求対象の文書であるＩＤ付き文書"Doc4"の操作者user3の所属組織１Ｔが含まれないので、アクセス許可されない。以下、この例におけるアクセス制御部１４２の処理について説明する。
【０１２６】
まず、図１０のステップＳ１０で、注目ユーザｕはuser7、注目文書ｒは"Doc4"に設定される。次に、ステップＳ１２で、注目文書ｒ"Doc4"の操作者はuser3であり、注目ユーザｕであるuser7と一致しないので、ステップＳ１４に進む。ステップＳ１４で、組織情報ＤＢ１２０（図９）を参照すると、注目文書ｒ"Doc4"の操作者であるuser3の所属組織１Ｔと、注目ユーザｕであるuser7の所属組織２Ｔと、が一致しないので、判定の結果ステップＳ３０に進む。この時点で、順次性チェックフラグの値は、ステップＳ１０でtrueに設定されたまま変更されていないので、ステップＳ３０の判定の結果、ステップＳ３２に進む。また、注目文書ｒ"Doc4"は、要求対象のＩＤ付き文書"Doc4"であるので、ステップＳ３２の判定の結果、ステップＳ３４に進む。ステップＳ３４で、注目ユーザｕであるuser7の所属組織２Ｔは、組織階層における最上位の組織ではない（図７及び図８参照）ので、処理はステップＳ３６に進む。ステップＳ３６において、注目ユーザｕであるuser7の所属組織２Ｔに対して一段階上位の組織１Ｇに所属する者であるuser2（図９参照）が新たな注目ユーザｕとして設定される。
【０１２７】
ステップＳ３６の後、ステップＳ１４に戻り、ステップＳ１４で、注目文書ｒ"Doc4"の操作者であるuser3の所属組織１Ｔと、注目ユーザｕであるuser2の所属組織１Ｇと、が一致しないので、判定の結果、ステップＳ３０に進む。ステップＳ３０で、順次性チェックフラグの値はtrueであるので、ステップＳ３２に進む。注目文書ｒ"Doc4"は、要求対象のＩＤ付き文書"Doc4"と一致するので、ステップＳ３４に進む。ステップＳ３４で、注目ユーザｕであるuser2の所属組織１Ｇは、組織階層における最上位の組織ではない（図７及び図８参照）ので、ステップＳ３６に進み、注目ユーザｕであるuser2の所属組織１Ｇに対して一段階上位組織であるＸ部に所属するuser1が新たな注目ユーザｕとして設定される。その後、さらに、ステップＳ１４以降の処理を繰り返す。この繰り返し処理において、注目文書ｒ"Doc4"の操作者であるuser3の所属組織１Ｔと、注目ユーザｕであるuser1の所属組織Ｘ部から組織階層を遡った経路上に含まれる組織と、が一致することはないので、ステップＳ１４でＹｅｓに進むことはない。したがって、ステップＳ１４，Ｓ３０〜Ｓ３６の処理ループが繰り返されて、組織階層において注目ユーザｕの所属組織を遡っていき、組織階層における最上位組織に所属する者が注目ユーザｕとして設定された後、ステップＳ３４の判定が行われると、処理はステップＳ３８に進み、順次性チェックフラグの値がfalseに設定される。この間、注目文書ｒは、要求対象のＩＤ付き文書"Doc4"に設定されたまま変更されない。
【０１２８】
ステップＳ３８の後、ステップＳ２１に進み、注目文書ｒ"Doc4"は根ノードでないのでステップＳ２８に進み、ステップＳ１２以降の処理が繰り返される。そして、派生関係の木構造の根ノードである"Doc1"が注目文書ｒとして設定された後、ステップＳ２１の判定が行われると、ステップＳ２２において、順次性チェックフラグの値の判定が行われる。順次性チェックフラグの値は、上述のようにfalseに設定されているので、ステップＳ２２の判定の結果、ステップＳ２６のエラー処理に進み、user7によるＩＤ付き文書"Doc4"に対するアクセスは許可されない。
【０１２９】
＜具体例７＞
要求者と同じ組織に所属する他のユーザが更新登録した文書に対するアクセス要求があった場合のアクセス制御について説明する。上述の（条件１）及び（条件２）を考慮すると、役職者でない者が更新登録した文書については、要求者が更新登録した文書から派生した文書でない限りアクセス許可されない。例えば、組織１Ｔに所属するuser6が、同じ組織１Ｔに所属するuser5によって更新登録されたＩＤ付き文書"Doc7"の提供を要求した場合について説明する。
【０１３０】
図１０のステップＳ１０で、注目ユーザｕはuser6、注目文書ｒは"Doc7"に設定される。次に、ステップＳ１２で、注目文書ｒ"Doc7"の操作者はuser5であり、注目ユーザｕであるuser6と一致しないので、ステップＳ１４に進む。ステップＳ１４で、組織情報ＤＢ１２０（図９）を参照すると、注目文書ｒ"Doc7"の操作者であるuser5の所属組織１Ｔと、注目ユーザｕであるuser6の所属組織１Ｔと、が一致するので、処理はステップＳ１６に進み、注目文書ｒ"Doc7"の操作者user5は役職者ではないので、処理は、図１１のステップＳ４０に進む。図１１に例示する手順の処理では、注目文書ｒ"Doc7"を起点に、図６に示す派生関係の木構造を根ノードまで遡った経路に含まれる「更新」操作ノード（"Doc7"，"Doc4"，"Doc3"，"Doc1"）の中に、その操作者が要求者であるuser6と一致するノードが存在しないので、ステップＳ４８のエラー処理が行われ、文書に対するアクセスは許可されない。
【０１３１】
＜具体例８＞
最後の具体例として、複数の組織に所属するユーザが更新登録したＩＤ付き文書に関するアクセス制御について説明する。例えば、ＩＤ付き文書"Doc12"は、組織２Ｔの役職者であるuser4によって更新登録されたＩＤ付き文書"Doc5"に対して、組織１Ｔ及び２Ｔの業務を兼任するuser8が更新を行った結果の文書である。つまり、ＩＤ付き文書"Doc12"は、user8が、自己の一方の所属組織２Ｔにおける業務として更新登録を行った文書である。このＩＤ付き文書"Doc12"に対して、user8の他方の所属組織１Ｔの役職者であるuser3がアクセス要求を行った場合のアクセス制御部１４２の処理について説明する。
【０１３２】
まず、図１０のステップＳ１０において、注目ユーザｕはuser3、注目文書ｒは"Doc12"に設定される。次に、ステップＳ１２の判定では、注目文書ｒ"Doc12"の操作者はuser8で、要求者であるuser3と一致しないので、ステップＳ１４に進む。次に、注目文書ｒ"Doc12"の操作者であるuser8の所属組織１Ｔ，２Ｔの一方と、注目ユーザｕであるuser3の所属組織１Ｔと、が一致し（ステップＳ１４でＹｅｓ判定）、注目文書ｒ"Doc12"の操作者であるuser8は、役職者ではない（図９参照）ので、処理は図１１のステップＳ４０に進む。ここで、図６に示す派生関係を参照すると、要求対象のＩＤ付き文書"Doc12"は、要求者であるuser3が更新登録したＩＤ付き文書から派生した文書ではないので、図１１に例示する手順の処理を実行すると、ステップＳ４８のエラー処理が行われ、user3のＩＤ付き文書"Doc12"に対するアクセスは許可されない。
【０１３３】
また、例えば、user8が組織２Ｔにおいて役職者であった場合、図１１に例示する処理が行われることはなく、ステップＳ１６でＹｅｓ判定されてステップＳ１７以降の処理が行われるが、要求者user3の所属組織１Ｔを起点に組織階層を遡った経路上に含まれる組織（１Ｔ，１Ｇ，Ｘ部，…，全社）の中に、要求対象の文書であるＩＤ付き文書"Doc12"の操作者user8の所属組織２Ｔが含まれない。したがって、上述の＜具体例６＞の場合と同様、ステップＳ３０〜Ｓ３６を含む処理ループが繰り返された結果、ステップＳ３８において順次性チェックフラグの値がfalseに設定されるため、アクセス許可されない。
【０１３４】
以上より、user3は、user8に対して組織１Ｔにおいて上司に該当する者であるが、組織１Ｔと異なる組織２Ｔの業務に関してuser8が更新登録した文書についてはアクセス許可されない。
【０１３５】
以上、図１０，図１１及び＜具体例１＞−＜具体例８＞を参照して説明した処理の例において、文書の派生関係において、注目文書ｒとなり得るのは、操作種別の値が「登録」又は「更新」である文書だけである。したがって、クライアント端末２０は、ＩＤ付き文書が新たに作成された場合（初期登録）、又は、ＩＤ付き文書に対して「更新」操作（ＩＤ付き文書の文書内容に変更が生じるような操作）が行われた場合に、新たなＩＤ付き文書を生成して文書管理サーバ１０に登録し、「閲覧」操作又は「取得」操作など「更新」操作以外の操作（ＩＤ付き文書の文書内容に変更が生じない操作）が行われた場合は、新たなＩＤ付き文書の生成及び文書管理サーバ１０への登録を行わない構成としてもよい。この場合、派生関係ＤＢ１１０に登録されるレコードは、操作種別の値が「登録」又は「更新」であるレコードのみとなる。例えば、図５に示す表で表される時系列で文書に対して操作が行われた場合に、クライアント端末２０が「登録」操作又は「更新」操作のみについてＩＤ付き文書の生成及び登録を行う場合、図５に示す表から、管理ＩＤ"Doc2"のレコード（操作種別「閲覧」）、及び管理ＩＤ"Doc6"，"Doc8"のレコード（操作種別「取得」）を除いたレコードを含む表のデータ内容が派生関係ＤＢ１１０に登録される。そして、図５に示す表において、管理ＩＤ"Doc2"，"Doc6"，"Doc8"をそれぞれ親ＩＤとする操作種別「更新」のレコードである管理ＩＤ"Doc3"，"Doc7"，"Doc9"の親ＩＤの値としては、それぞれの「更新」操作において変更される前の文書内容を含むＩＤ付き文書の管理ＩＤの値が登録される。つまり、管理ＩＤ"Doc3"のレコードの親ＩＤは"Doc1"、管理ＩＤ"Doc7"及び"Doc9"のレコードの親ＩＤは"Doc4"となる。
【０１３６】
「登録」操作又は「更新」操作のみについてＩＤ付き文書の生成及び文書管理サーバ１０への登録が行われる場合、アクセス制御部１４２は、図１０及び図１１に例示する処理において、注目文書ｒから派生関係の木構造を遡って最初に発見した「更新」又は「登録」ノードの管理ＩＤ（Ｐ（ｒ））を取得する際（図１０のステップＳ１７，Ｓ２８及び図１１のステップＳ４２）、派生関係ＤＢ１１０内の注目文書ｒのレコードに登録された親ＩＤをＰ（ｒ）として取得すればよい。
【０１３７】
また、以上で説明した処理の例では、図１０のステップＳ２０又は図１１のステップＳ４０で、注目文書ｒが木構造の根ノードに該当するか否かの判定が行われる。他の処理の例では、このノードに到達したらそれ以上は木構造を遡らない、とするノードを予め設定しておき、図１０のステップＳ２０及び図１１のステップＳ４０の判定において、注目文書ｒが上述のように木構造を遡る終点として設定されたノードであるか否かを判定してもよい。この場合、例えば、派生関係ＤＢ１１０において、終点として設定されたノードの管理ＩＤに対応するレコードに、その旨を示す情報を登録しておけばよい。
【０１３８】
また、以上で説明した処理の例では、図１０のステップＳ３４で、注目ユーザｕの所属組織が組織階層において最上位に位置するか否かを判定する。他の処理の例では、この組織に到達したらそれ以上は組織階層を遡らない、とする組織を予め設定しておき、図１０のステップＳ４０の判定において、注目ユーザｕの所属組織が上述のように組織階層を遡る終点として設定された組織であるか否かを判定してもよい。この例の場合、ステップＳ３０，Ｓ３２，Ｓ３４，Ｓ３６を含む処理ループにおいて、要求者の所属組織から、終点として設定された組織まで組織階層を遡った経路上に含まれる組織のいずれかに、要求対象のＩＤ付き文書の操作者が所属するか否かを判定することになる。
【０１３９】
さらに他の処理の例として、ＩＤ付き文書のログ情報３１６の中に、当該ＩＤ付き文書３００が公開（共有）対象であるか否かを示す「公開」属性を組み込むこともできる。例えば公開対象とするＩＤ付き文書の「公開」属性値を「１」とし、公開対象としないＩＤ付き文書の「公開」属性値は「０」とし、文書管理サーバ１０の派生関係ＤＢ１１０の各管理ＩＤに対応するレコードに「公開」属性値を登録する。この「公開」属性値は、ユーザがクライアント端末２０においてＩＤ付き文書に対して操作を行う時に指定できるようにしておけばよい。「公開」属性値を用いる場合、アクセス制御部１４２は、例えば、図１０に例示する手順の処理を開始する前に、まず、派生関係ＤＢ１１０内の要求対象文書に対応するレコードに含まれる「公開」属性値を取得する。そして、取得した「公開」属性値が「１」であれば、図１０に例示する処理を開始してアクセスの可否を決定し、「公開」属性値が「０」であれば、図１０に例示する処理を行うことなく、当該文書を生成するための操作を行った操作者や管理者等の特権的なユーザ以外には、アクセスを許可しないようにすることができる。
【０１４０】
また、企業などの団体においては、人事異動などにより各組織の構成員及び役職者が変更されたり、企業組織改変などにより組織階層の構成が変更されたりする場合がある。このような組織の変動に対応するため、組織情報ＤＢ１２０に、組織において生じた変更についての情報を登録しておくことができる。例えば、各組織の構成員に変更があった場合、変更前及び変更後の構成員の情報（例えば、図９のようなデータ内容）を組織情報ＤＢ１２０に登録しておき、さらに、変更が行われた時刻を組織情報ＤＢ１２０に登録する。組織階層の構成が変更された場合は、変更前及び変更後の組織階層の構造を表す情報（例えば、図８のようなデータ内容）と、変更前及び変更後の組織構成それぞれにおける各組織の構成員の情報と、その変更が行われた時刻と、を組織情報ＤＢ１２０に登録しておく。そして、アクセス制御部１４２における処理では、処理対象のＩＤ付き文書の操作日時を派生関係ＤＢ１１０から取得し、取得した操作日時が、組織情報ＤＢ１２０に登録された変更時刻以前であれば、変更前の組織階層及び構成員の情報を用い、取得した操作日時が組織情報の変更時刻以後であれば、変更後の組織階層及び構成員の情報を用いるようにすればよい。組織階層又は構成員について複数回の変更が行われた場合、例えば、組織階層又は構成員の情報とその情報が有効であった期間とを対応づける情報を組織情報ＤＢ１２０に登録しておき、アクセス制御部１４２での処理において、処理対象のＩＤ付き文書の操作日時を含む期間に対応する組織階層又は構成員の情報を組織情報ＤＢ１２０から取得して用いるようにすればよい。
【０１４１】
以上に例示した例では、管理ＩＤの発行は各クライアント端末２０で行われていたが、この代わりに文書管理サーバ１０が管理ＩＤを発行してもよい。この場合、クライアント端末２０は、ＩＤ付き文書に対して操作を行った場合、操作前のＩＤ付き文書内の管理ＩＤを親ＩＤ３１４として含み、更にその操作についてのログ情報３１６と操作後の文書内容３２０とを含み、管理ＩＤ３１２は空欄の文書データを生成し、文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書データに対して新たな管理ＩＤを付与し、この管理ＩＤとその文書データとに含まれる情報を、文書ＤＢ１００及び派生関係ＤＢ１１０に登録する。また、文書管理サーバ１０は、付与した管理ＩＤを当該文書データにセットすることによりＩＤ付き文書を生成し、これをクライアント端末２０に返す。クライアント端末２０は、操作前のＩＤ付き文書を、受け取ったＩＤ付き文書に置き換える。このように、文書管理サーバ１０が管理ＩＤを付与する構成でも、上述の各例の処理は同様に実行できる。
【０１４２】
また以上の例では、管理ＩＤ３１２、親ＩＤ３１４、ログ情報３１６、及び文書内容３２０を含んだＩＤ付き文書３００がクライアント端末２０に保存されたが、この代わりに、クライアント端末２０は管理ＩＤしか持たず、その他の情報は文書管理サーバ１０に保存されるようにしてもよい。この場合、クライアント端末２０で文書を操作する場合、その文書に対応する管理ＩＤを文書管理サーバ１０に送り、文書管理サーバ１０からその文書を取得する。また、別の例として、クライアント端末２０が保持するＩＤ付き文書３００の中には管理ＩＤ３１２と文書内容３２０とが含まれ、親ＩＤ３１４及びログ情報３１６は含まれないようにしても良い。この場合、サーバがその管理ＩＤ３１２に対応づけて親ＩＤ３１４とログ情報３１６を持つようにすれば良い。
【０１４３】
ここで、文書管理サーバ１０が管理ＩＤを付与する場合は、その取得の操作に対応する管理ＩＤを文書管理サーバ１０が生成し、その管理ＩＤと文書とを対応づけてクライアント端末２０に提供するとともに、その取得操作についてのログ情報（操作時刻や操作者など）と、元の管理ＩＤ（すなわち親ＩＤ）と、付与した管理ＩＤとを派生関係ＤＢ１１０に記録する。クライアント端末２０は、文書管理サーバ１０に送信した管理ＩＤを、受け取った管理ＩＤに置き換えると共に、受け取った文書を開く。ユーザは、開かれた文書に対して閲覧や編集などの操作を行う。クライアント端末２０は、文書に対する操作が完了すると、操作後の文書を管理ＩＤ及び当該操作についてのログ情報と共に文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書に対して新たな管理ＩＤを付与して派生関係ＤＢ１１０に登録し、受け取った管理ＩＤを親ＩＤとして派生関係ＤＢ１１０に登録する。また、受け取ったログ情報及び操作後の文書を、派生関係ＤＢ１１０及び文書ＤＢ１００に登録する。そして、文書管理サーバ１０は、新たに付与した管理ＩＤをクライアント端末２０に返す。クライアント端末２０は、元の管理ＩＤを受け取った管理ＩＤで置き換える。以上のような処理により、操作間の派生関係が文書管理サーバ１０に蓄積されることになる。
【０１４４】
一方、クライアント端末２０が管理ＩＤを付与する構成の場合は、文書管理サーバ１０は、クライアント端末２０から受け取った管理ＩＤに対応する文書をクライアントに返せばよい。クライアント端末２０は受け取った文書を開き、ユーザがその文書を操作する。操作の完了後、クライアント端末２０はその操作結果の文書に対して新たな管理ＩＤを付与し、この管理ＩＤを含んだ前述のＩＤ付き文書と同様の情報を、文書管理サーバ１０に送る。そして、クライアント端末２０は、そのＩＤ付き文書のうち管理ＩＤのみを保存し、その他の情報を削除する。
【０１４５】
以上に例示したシステムにおける文書管理サーバ１０は、典型的には、汎用のコンピュータにて上述の文書管理サーバの各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図１２に示すように、ＣＰＵ（中央演算装置）４０、メモリ（一次記憶）４２、各種Ｉ／Ｏ（入出力）インタフェース４４等がバス４６を介して接続された回路構成を有する。また、そのバス４６に対し、例えばＩ／Ｏインタフェース４４経由で、ハードディスクドライブ（ＨＤＤ）４８やＣＤやＤＶＤ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ５０が接続される。このようなドライブ４８又は５０は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク経由で、ハードディスクドライブ４８等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されＣＰＵにより実行されることにより、実施形態の処理が実現される。クライアント端末２０についても同様である。
【図面の簡単な説明】
【０１４６】
【図１】文書管理システムの概略構成の例を示すブロック図である。
【図２】クライアント端末の内部構成の例を示すブロック図である。
【図３】ＩＤ付き文書のデータ構造の例を模式的に示す図である。
【図４】文書管理サーバの内部構成の例を示すブロック図である。
【図５】派生関係ＤＢのデータ内容の例を示す図である。
【図６】図５に例示したデータ内容における管理ＩＤ群がなす木構造を図式化して表す図である。
【図７】複数の組織からなる組織階層の構造の例を示す図である。
【図８】組織情報ＤＢのデータ内容の例を示す図である。
【図９】組織情報ＤＢのデータ内容の例を示す図である。
【図１０】ＩＤ付き文書に対するアクセスが要求された場合の文書管理サーバの処理手順の一部の例を示すフローチャートである。
【図１１】ＩＤ付き文書に対するアクセスが要求された場合の文書管理サーバの処理手順の一部の例を示すフローチャートである。
【図１２】コンピュータのハードウエア構成の一例を示す図である。
【符号の説明】
【０１４７】
１０ 文書管理サーバ、２０ クライアント端末、３０ ネットワーク、４０ ＣＰＵ、４２ メモリ、４４ Ｉ／Ｏインタフェース、４６ バス、４８ ハードディスクドライブ（ＨＤＤ）、５０ ディスクドライブ、１００ 文書ＤＢ、１１０ 派生関係ＤＢ、１２０ 組織情報ＤＢ、１３０ 文書登録部、１３２ 派生関係登録部、１４０ 要求処理部、１４２ アクセス制御部、２００ 文書操作部、２０２ ＩＤ割り当て部、２０４ 派生関係組込部、２１０ 登録処理部、３００ ＩＤ付き文書。
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理システム、及びプログラムに関する。
【背景技術】
【０００２】
サーバに電子文書が登録されたシステムにおいて、一般に、電子文書に関してユーザに与えられる利用権限の管理は、電子文書（ファイル）ごとに、その文書に対する各ユーザ又は各グループの権限、例えば閲覧可能／不可、書込可能／不可など、のアクセス権を示す情報を設定登録することで行われる。電子文書の利用管理を行うシステムは、ユーザからある文書に対する操作の要求を受けた場合、その文書について設定登録されたアクセス権情報に基づいて、その操作がそのユーザの権限内のものであるかを判定し、その操作を許可するか否かを判定する。
【０００３】
文書ごとにアクセス権情報を設定登録する電子文書利用管理システムを用いて、例えば企業など、階層構造を形成する複数の組織からなる団体において利用される電子文書を管理する場合に、その団体における組織の階層構造及び組織の業務分担などの組織に関する情報を用いて、文書ごとのアクセス権の設定を行う技術がある。
【０００４】
特許文献１には、プログラム及び設計書などの文書について、会社組織及び業務分類に基づきアクセス権を設定する文書管理装置が開示されている。特許文献１に記載の技術では、各組織の構成員を表す情報と、各組織の業務を表す情報と、業務において用いられる文書を表す情報と、を設定しておき、文書に対するアクセス要求があった場合に、アクセス要求を行った個人が所属する組織の業務において用いられる文書として当該文書が設定されているか否かを判定することで、当該文書に対するアクセスの可否を決定する。
【０００５】
また、特許文献２には、文書アクセス管理システムにおいて、複数のグループを階層構造で定義した情報を保存するグループ階層構造情報記憶装置と、文書の更新や配布先設定を委ねられた管理元となるグループを示す情報及びアクセス許可グループを示す情報を文書ごとに保存する文書記憶装置と、を備え、これらの記憶装置に保存された情報を用いて、個々の文書の参照や、その他の取り扱いができるユーザの選別を行うシステムが開示されている。
【０００６】
特許文献３には、文書ごとのアクセス権を規定したアクセス権限リスト（ＡＣＬ，Access Control List）の中に、組織における操作者の属性及び役職の属性などに関する照合規則を定義しておくことで、組織に関する属性情報に従って文書のアクセス制御を行う技術が開示されている。
【０００７】
【特許文献１】特開平７−５６７９４号公報
【特許文献２】特開２０００−２０３７７号公報
【特許文献３】特許第３３４９９７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところで、例えば、企業などの複数の組織からなる団体において、１つの電子文書が複製されて複数の流通経路に沿って流通し、その電子文書に対し個々の流通経路でそれぞれ個別に更新が加えられる場合がある。このような場合、更新後の文書に対するアクセスは、組織の階層構造などに適合するように制御するだけでなく、異なる流通経路ごとに異なるアクセス権が実現されるように制御することが望まれる場合がある。
【０００９】
１つの電子文書が複数の流通経路に沿って流通する場合、例えば、１つの電子文書について複数の流通経路それぞれにおいて複数回の更新が行われると、電子文書ごとにアクセス権情報を設定登録すると、各流通経路における複数の更新版の文書に対してそれぞれアクセス権情報を設定登録する必要があるため、設定登録作業が煩雑となり管理負担が大きい。
【００１０】
本発明は、階層構造を形成する複数の組織において利用される電子文書の管理において、組織階層に応じて、文書の流通経路ごとに、文書に対してアクセスを制御できる情報処理装置、情報処理システム及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
請求項１に係る発明は、第１の文書を親とし当該第１の文書に対する操作の結果生成された第２の文書を子とする派生関係を記憶する文書情報記憶部であって、当該第１の文書に対する操作を行った操作者を示す情報を当該第２の文書と対応づけて記憶する文書情報記憶部と、複数の組織からなる組織階層の構造を表す情報と、前記組織のそれぞれに所属する構成員を示す情報と、を記憶する組織情報記憶部と、要求対象文書と、要求者と、を特定する文書出力要求を受けた場合に、前記要求対象文書に対応づけられた操作者を示す情報又は前記文書情報記憶部に記憶された前記派生関係群が表す木構造において前記要求対象文書の先祖に該当する文書に対応づけられた操作者を示す情報と、前記組織情報記憶部に記憶された情報のうち、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織に所属する構成員を示す情報と、を照合することで、前記要求者に対する前記要求対象文書の出力の可否を決定する文書出力可否決定部と、を備えることを特徴とする情報処理装置である。
【００１２】
請求項２に係る発明は、請求項１に係る発明において、前記文書出力可否決定部は、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織が、前記要求対象文書に対応づけられた操作者を前記構成員として含むか否かを判定し、当該判定の結果に基づいて、前記要求対象文書の出力の可否を決定する。
【００１３】
請求項３に係る発明は、請求項２に係る発明において、前記文書出力可否決定部は、前記要求対象の文書が前記組織階層において上位から下位の展開経路を経ずに更新登録された文書である場合には、前記要求対象の文書の出力を許可しない。
【００１４】
請求項４に係る発明は、請求項１から３のいずれか１項に係る発明において、前記文書出力可否決定部は、前記要求対象文書を起点として前記木構造を遡った経路上に含まれる文書のうち少なくとも１つの文書に対応づけられた操作者が前記要求者である場合に、前記要求対象文書の出力を許可する。
【００１５】
請求項５に係る発明は、請求項１から４のいずれか１項に係る発明において、前記組織情報記憶部は、さらに、前記組織のそれぞれに所属する構成員のうちの役職者を示す情報を記憶し、前記文書出力可否決定部は、前記要求対象文書に対応づけられた操作者が、前記構成員として当該操作者を含む組織の役職者でない場合であって、前記要求対象文書を起点として前記木構造を遡った経路上に含まれる文書のいずれに対応づけられた操作者も前記要求者でない場合は、前記要求対象文書の出力を許可しない。
【００１６】
請求項６に係る発明は、第１の文書を親とし当該第１の文書に対する操作の結果生成された第２の文書を子とする派生関係を文書情報記憶部に記憶するステップであって、当該第１の文書に対する操作を行った操作者を示す情報を当該第２の文書と対応づけて文書情報記憶部に記憶するステップと、複数の組織からなる組織階層の構造を表す情報と、前記組織のそれぞれに所属する構成員を示す情報と、を組織情報記憶部に記憶するステップと、要求対象文書と、要求者と、を特定する文書出力要求を受けた場合に、前記要求対象文書に対応づけられた操作者を示す情報又は前記文書情報記憶部に記憶された前記派生関係群が表す木構造において前記要求対象文書の先祖に該当する文書に対応づけられた操作者を示す情報と、前記組織情報記憶部に記憶された情報のうち、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織に所属する構成員を示す情報と、を照合することで、前記要求者に対する前記要求対象文書の出力の可否を決定するステップと、をコンピュータに実行させることを特徴とするプログラムである。
【００１７】
請求項７に係る発明は、第１の情報処理装置と第２の情報処理装置とを備え、前記第１の情報処理装置は、要求対象文書と、要求者と、を特定する文書出力要求を前記第２の情報処理装置に対して行う文書出力要求部を備え、前記第２の情報処理装置は、第１の文書を親とし当該第１の文書に対する操作の結果生成された第２の文書を子とする派生関係を記憶する文書情報記憶部であって、当該第１の文書に対する操作を行った操作者を示す情報を当該第２の文書と対応づけて記憶する文書情報記憶部と、複数の組織からなる組織階層の構造を表す情報と、前記組織のそれぞれに所属する構成員を示す情報と、を記憶する組織情報記憶部と、前記第１の情報処理装置から前記文書出力要求を受けた場合に、前記要求対象文書に対応づけられた操作者を示す情報又は前記文書情報記憶部に記憶された前記派生関係群が表す木構造において前記要求対象文書の先祖に該当する文書に対応づけられた操作者を示す情報と、前記組織情報記憶部に記憶された情報のうち、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織に所属する構成員を示す情報と、を照合することで、前記要求者に対する前記要求対象文書の出力の可否を決定する文書出力可否決定部と、を備えることを特徴とする情報処理システムである。
【発明の効果】
【００１８】
請求項１に係る発明によると、文書ごとにアクセス権情報を設定することなく、組織階層に応じて、文書の流通経路ごとに、文書に対するアクセスを制御できる。
【００１９】
請求項２に係る発明によると、要求対象文書の操作者の所属組織が要求者の所属組織に対して組織階層において直系の上位に該当するか否かによって文書に対するアクセスを制御することができる。
【００２０】
請求項３に係る発明によると、上位組織に所属するユーザから下位組織に所属するユーザの順に操作された文書でなければアクセスを許可しないようにできる。
【００２１】
請求項４に係る発明によると、要求者が操作した文書から派生した文書については、要求者にアクセスを許可するようにできる。
【００２２】
請求項５に係る発明によると、役職者が操作した文書以外の文書について、要求者が操作した文書から派生した文書でない限りは、要求者にアクセスを許可しないようにできる。
【００２３】
請求項６に係る発明によると、文書ごとにアクセス権情報を設定することなく、組織階層に応じて、文書の流通経路ごとに、文書に対するアクセスを制御できる。
【００２４】
請求項７に係る発明によると、文書ごとにアクセス権情報を設定することなく、組織階層に応じて、文書の流通経路ごとに、文書に対するアクセスを制御できる。
【発明を実施するための最良の形態】
【００２５】
以下、図面を参照して、本発明の実施の形態を説明する。
【００２６】
図１は、文書管理システムの概略構成を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク３０を介して接続された文書管理サーバ１０とクライアント端末２０−１，２０−２，・・・（以下、クライアント端末２０と総称する）から構成される。
【００２７】
クライアント端末２０について図２を用いて説明する。クライアント端末は、ユーザが文書を操作するために用いる端末であり、パーソナルコンピュータ、デジタル複写機などがその一例である。クライアント端末２０は、図２に示すように、文書操作部２００及び登録処理部２１０を備える。
【００２８】
文書操作部２００は、文書に対する操作を実行する手段である。文書に対する操作には、例えば、文書の表示（ユーザから見れば「閲覧」）、編集、印刷出力、紙文書の読み取り、紙文書の複写、等がある。図では、文書操作部２００を１つだけ示したが、それら個々の操作を別々の操作部（例えば、編集用のアプリケーション、読取制御用のアプリケーションなど）が担当してもよい。例えば、文書操作部２００がワードプロセッサ等の電子文書を作成・編集するためのソフトウエアであれば、文書操作部２００は、ユーザの指示に応じて電子文書を表示したり、電子文書に編集を加えたりする。文書操作部２００は、文書に対して操作を行った場合、その操作の結果を表すＩＤ付き文書３００を出力する。
【００２９】
ＩＤ付き文書３００は、図３に示すように、メタ情報３１０と文書内容３２０を含んだ電子文書である。文書内容３２０は、文書操作部２００の操作の結果生成された文書の内容データである。文書操作部２００が電子文書を作成・編集するためのソフトウエアであれば、文書内容３２０はそのソフトウエアによる編集の結果生成される文書ファイルである。また、文書操作部２００が電子文書を印刷する装置であれば、文書内容３２０は、例えば、印刷される電子文書の内容データとすればよい。また、文書操作部２００が紙文書をスキャンする装置又は紙文書を複写する装置であれば、文書内容３２０は、例えば、その紙文書を読み取って得られる画像データとすればよい。
【００３０】
メタ情報３１０は、文書管理のための情報であり、管理ＩＤ３１２，親ＩＤ３１４，及びログ情報３１６を含む。
【００３１】
管理ＩＤ３１２は、当該ＩＤ付き文書３００自体の一意な識別情報である。親ＩＤ３１４は、当該ＩＤ付き文書３００の親のＩＤ付き文書の管理ＩＤである。すなわち、本実施形態では、あるＩＤ付き文書と、このＩＤ付き文書に対して操作を加えた結果得られる新たなＩＤ付き文書とを、親と子の関係として取り扱う。第１のＩＤ付き文書を操作して第２のＩＤ付き文書が得られた場合、第１のＩＤ付き文書は第２のＩＤ付き文書の親であり、第２のＩＤ付き文書は第１のＩＤ付き文書の子である。したがって、例えば、管理ＩＤ「Ａ」のＩＤ付き文書を文書操作部２００で操作して、その結果得られた新たなＩＤ付き文書の管理ＩＤが「Ｂ」である場合、後者のメタ情報３１０における管理ＩＤ３１２は「Ｂ」であり、親ＩＤ３１４は「Ａ」である。このような親子の関係を、以下では「（管理ＩＤの）派生関係」という。
【００３２】
なお、本システムに未登録の電子文書を新たに登録する操作を実行した場合や、未登録の紙文書をスキャン又は複写する操作を実行した場合（この場合、紙文書を読み取った画像を文書内容とするＩＤ付き文書が生成され、本システムに登録される）に生成されるＩＤ付き文書３００では、親ＩＤ３１４は空（すなわち、親は存在しない）となる。
【００３３】
ログ情報３１６は、当該ＩＤ付き文書が生成された際の操作についての、各種のログ項目の情報である。ログ項目には、例えばその操作が行われた日時、その操作の種別、その操作を指示したユーザ（操作者）などがあるが、もちろんこれに限るものではない。操作の種別には、例えば登録（本システムに新規の文書を登録すること）、閲覧、編集、更新（更新版の登録）、印刷、スキャン、紙文書の複写、等がある。例えば、ユーザが文書操作部２００を用いて第１のＩＤ付き文書に対して編集を加え、編集完了の指示を行った場合、その結果生成される第２のＩＤ付き文書のログ情報３１６は、編集完了の日時と、その編集を指示したユーザの識別情報と、操作の種別として「編集」と、を含んだものとなる。
【００３４】
ここでログ情報３１６に組み込まれる操作の種別は、ログ記録の目的での分類に従った種別であり、文書操作部２００が実行する操作の種別そのものでなくてもよい。例えば、文書操作部２００が実行する複数の操作の種別を、同じ１つのログ記録目的の操作種別に対応づけてもよい。例えば、文書編集アプリケーション上でＩＤ付きの電子文書に編集を加え操作メニュー上で「更新版として登録」を指示した場合も、スキャナで管理ＩＤ付きの紙文書を読み取り読取制御用アプリケーションの操作メニュー上で「読み取った文書を承認版として登録」を指示した場合も、ログ情報３１６に組み込まれる操作種別の値は「更新」となる。
【００３５】
文書操作部２００が生成するメタ情報３１０の具体例を以下に示す。
【００３６】
[例１]
<metadata sid="Doc1" date="2006-10-01T10:00" method="register" filename="aaa.doc" user="user1"/>
【００３７】
ここでsid属性は管理ＩＤ、date属性は操作日時、method属性は操作種別である。また、filename属性は当該ＩＤ付き文書のファイル名であり、user属性は操作を指示したユーザのユーザ識別情報である。例１のmethod属性値"register"は（文書管理サーバ１００に未登録の）新規文書の登録操作を示す操作種別名である。新規文書の登録なので、親ＩＤを示すpid属性は省略されている。省略する代わりにpid="null"などと、親ＩＤがないことを示す属性を明示的に組み込んでもよい。
【００３８】
なお、文書操作部２００が、操作した文書を暗号化してもよい。この暗号化は、本システムに準拠した文書操作部２００ならば、復号できるようなものとする。この場合、文書操作部２００が出力するＩＤ付き文書３００の文書内容３２０は、暗号化されることにより、本システムに準拠した文書操作部２００でないと復号できなくなる。したがって、ＩＤ付き文書３００が操作される場合には文書操作部２００が用いられるので、文書操作部２００がその操作を検知し、その操作の内容が文書操作部２００から文書管理サーバ１０に通知される。なお、文書内容３２０だけでなく、後述するメタ情報３１０（またはその一部）に対しても暗号化を施してもよい。
【００３９】
図２の説明に戻り、文書操作部２００は、操作結果として上述のようなＩＤ付き文書３００を作成するために、ＩＤ割り当て部２０２及び派生関係組込部２０４を備える。ＩＤ割り当て部２０２は、操作結果のＩＤ付き文書３００に一意な管理ＩＤを付与する手段である。管理ＩＤは、少なくとも本システム内で一意な識別情報である必要がある。例えば、操作の結果生成するＩＤ付き文書３００（ただし管理ＩＤ３１２を除いたもの）のハッシュ値を求め、このハッシュ値をその文書３００のＩＤ付き文書とすればよい。ハッシュ関数としてSHA-256（SHA-256はNISTがFIPS180-2で定めた256ビットのハッシュ値を持つ暗号学的ハッシュ関数である）などのような耐衝突性を持つ暗号学的ハッシュ関数を用いれば、実用上十分な一意性を持つ管理ＩＤを生成することができる。もちろん、システム内で一意な管理ＩＤを各クライアント端末２０で生成する方法は、これに限らない。管理ＩＤを、クライアント端末２０固有の識別情報を含むものとすれば、システム内で一意な管理ＩＤを各クライアント端末２０で生成することができる。
【００４０】
派生関係組込部２０４は、操作結果の文書に対しＩＤ割り当て部２０２が割り当てた新たな管理ＩＤ３１２と、その操作の元になった親文書の管理ＩＤである親ＩＤ３１４（新規登録の場合は、親ＩＤは無し）と、その操作についてのログ情報３１６と、を含むメタ情報３１０を生成する。ここで、派生関係組込部２０４は、文書操作部２００が実行する個々の操作の種別が、ログ記録目的上の操作種別のどれに対応するかを表す対応関係の情報を保持しており、この情報を用いることでログ情報３１６に組み込む操作種別の値を求める。そして、派生関係組込部２０４は、そのメタ情報３１０を操作結果の文書内容に付加することにより、操作後のＩＤ付き文書３００を生成して出力する。
【００４１】
文書操作部２００がアプリケーションソフトウエアである場合、ＩＤ割り当て部２０２及び派生関係組込部２０４は、そのソフトウエアに対して追加される、いわゆるプラグイン(plug-in)プログラムとして実現してもよい。
【００４２】
登録処理部２１０は、文書操作部２００が出力したＩＤ付き文書３００を文書管理サーバ１０に登録するための処理を実行する。このように各クライアント端末２０が、自ら実行した操作の結果であるＩＤ付き文書３００を文書管理サーバ１０に登録することにより、文書管理サーバ１０は各ＩＤ付き文書３００間の派生関係を把握することができる。
【００４３】
文書操作部２００が操作の結果出力するＩＤ付き文書３００は、通常の文書ファイルと同様、電子的にコピーしたり、電子メールに添付するなどの方法で他の人宛に送信したりすることができる。電子メール送信用のソフトウエアは、この例では本システムに準拠していないので、この送信操作はＩＤ付き文書には反映されず、したがって文書管理サーバ１０にも記録されない。他の人からＩＤ付き文書３００を受け取った人が、自分のクライアント端末２０の文書操作部２００を用いてそのＩＤ付き文書３００を操作すると、その操作に応じて新たな管理ＩＤを付与されたＩＤ付き文書が生成されることになる。
【００４４】
また、文書操作部２００が電子文書を印刷する場合、管理ＩＤを生成し、その電子文書の印刷結果にその管理ＩＤを埋め込んでもよい。管理ＩＤの埋め込みは、例えば電子文書の印刷画像に、管理ＩＤを示すコード画像を重畳する等の方法で行うことができる。また、用紙がＲＦＩＤ(Radio Frequency Identifier)タグを備えている場合、そのＲＦＩＤタグに管理ＩＤを書き込んでもよい。このように印刷を行った場合、文書操作部２００は、その管理ＩＤや操作種別「印刷」等のメタ情報を含んだＩＤ付き文書を文書管理サーバ１０に登録する。なお、ＩＤ付き文書を印刷した場合には、そのＩＤ付き文書の管理ＩＤを親ＩＤ３１４として含んだＩＤ付き文書が生成される。印刷操作に対応するＩＤ付き文書には、印刷された画像を示すページ記述言語データやビットマップ画像データをなどの印刷データ、又は印刷された文書ファイルを、文書内容３２０として組み込んでもよい。
【００４５】
また、管理ＩＤが埋め込まれた紙文書を文書操作部２００が読み取った場合、文書操作部２００は、その読み取り操作に対して新たな管理ＩＤを付与し、読み取り結果の画像を文書内容３２０として含んだＩＤ付き文書を生成して文書管理サーバ１０に登録する。このＩＤ付き文書の親ＩＤ３１４には、紙文書から読み取った管理ＩＤがセットされる。管理ＩＤが埋め込まれた紙文書の複写の際には、上述した読み取り時と印刷時の処理が実行される。
【００４６】
次に、文書管理サーバ１０について説明する。文書管理サーバ１０は、システム内の複数のクライアント端末２０から送られてくるＩＤ付き文書３００を蓄積し、蓄積した情報に基づきユーザに各種のサービスを提供する。図４に示すように、文書管理サーバ１０は、文書ＤＢ（データベース）１００，派生関係ＤＢ１１０，組織情報ＤＢ１２０，文書登録部１３０，要求処理部１４０を備える。
【００４７】
文書ＤＢ１００は、クライアント端末２０から送られてきたＩＤ付き文書３００のうちの文書内容３２０を格納するデータベースである。文書ＤＢ１００に格納された各文書内容３２０は、一意な内容ＩＤにより管理してもよい。内容ＩＤとしては、例えば当該文書内容の暗号学的ハッシュ関数によるハッシュ値を用いてもよいが、これに限定されるものではない。クライアント端末２０が内容ＩＤを付与してもよく、この場合、内容ＩＤをメタ情報３２０に組み込んでもよい。また、内容ＩＤの代わりに、その文書内容３２０を、当該文書内容に対応するＩＤ付き文書３００の管理ＩＤと対応づけて文書ＤＢ１００に格納してもよい。
【００４８】
文書登録部１３０は、クライアント端末２０から受信したＩＤ付き文書の中の文書内容を文書ＤＢ１００に、メタ情報を派生関係ＤＢ１１０に、それぞれ登録する。そのうち、メタ情報の登録を担当するのが派生関係登録部１３２である。
【００４９】
派生関係ＤＢ１１０は、そのようなＩＤ付き文書３００のうち、派生関係の情報を主としたメタ情報を蓄積するデータベースである。図５に、派生関係ＤＢ１１０のデータ内容の一例を示す。図５に示した表における１行の情報が、１つのＩＤ付き文書３００に対応するメタ情報レコードである。この例では、各ＩＤ付き文書３００の管理ＩＤに対応づけて、親ＩＤ、ノードアドレス、操作種別、操作者、操作日時の各項目が登録されている。このうち、管理ＩＤと親ＩＤのペア以外の項目は、例示したものに限られない。管理目的上必要な項目を記録すればよい。また、操作種別、操作者、操作日時については既に説明した。
【００５０】
ノードアドレスは、ＩＤ付き文書間の派生関係が構成する木において、当該管理ＩＤ（ＩＤ付き文書）に対応するノードの位置を示している。ノードアドレスの表記において「／」が木の深さ階層の区切りを示し、番号が同じ親から派生した兄弟同士の間での順番を示す。例えばノード「／１」は新規文書登録の操作により登録された文書に対応する根ノードを示す。また、ノード「／１／１」は根ノード「／１」の１番目の子、ノード「／１／２」は根ノード「／１」の２番目の子を示す。なお、煩雑さを避けるため、図５には、１つの根ノード「／１」から派生した１つの木に属するメタ情報レコード群しか示していないが、文書管理サーバ１０には、例えば根「／１」から派生する木と根「／２」から派生する木のように、複数の木のメタ情報レコード群が登録され得る。
【００５１】
なお、図５に例示したメタ情報の項目は一例に過ぎない。例えば、この他にも、ＩＤ付き文書内の文書内容３２０を格納した、文書ＤＢ１００内での格納場所を示すパス名を派生関係ＤＢ１１０に登録してもよい。文書ＤＢ１００が、内容ＩＤで文書内容３２０を検索する機能を持つものであれば、文書格納パスの代わりに内容ＩＤをメタ情報レコードに登録してもよい。
【００５２】
なお、図５は派生関係ＤＢ１１０が管理するデータを内容の観点から表現したものにすぎず、具体的な表現形式或いはデータベース形式を規定するものではない。例えば、派生関係ＤＢ１１０は、一般的なリレーショナルデータベースとして構築することもできるし、管理ＩＤを除くメタ情報を記述したＸＭＬ(eXtensible Markup Language)文書を、管理ＩＤをキーとして登録したデータベースとして構築することもできる。
【００５３】
図５に示した派生関係ＤＢ１１０のデータ内容は、図６のような木構造を成す。これは、管理ＩＤをノードとし、管理ＩＤ間の親子関係をエッジとする木構造である。
【００５４】
以下、図５〜図６の例が示す文書のうち、管理ＩＤ"Doc1"の文書から管理ＩＤ"Doc7"の文書までの履歴について時系列順に説明する。
【００５５】
この例ではまず、文書（フォーム）の「登録」操作がuser1のクライアント端末で実行される。「登録」操作は、文書管理サーバ１０に未登録の文書（すなわち、管理ＩＤを有していない文書）を当該サーバ１０に登録するための操作である。この操作に応じて管理ＩＤが"Doc1"、親ＩＤが空、操作種別が「登録」であるメタ情報と、その文書の文書内容とを含むＩＤ付き文書"Doc1"がuser1のクライアント端末から文書管理サーバ１０に送られる。これに応じ、文書管理サーバ１０は、そのＩＤ付き文書"Doc1"中の文書内容を文書ＤＢ１００へ、メタ情報を派生関係ＤＢ１１０にそれぞれ登録する。ここで、文書管理サーバ１０は、操作種別が「登録」であり、親ＩＤが空なので、当該ＩＤ付き文書が、文書管理サーバ１０内に既に登録済みのＩＤ付き文書の子ではなく、新たな木の根（始祖）であると判断し、それに従ってノードアドレスの値（この例では「／１」）を設定する。なお、以下では、識別のために、登録された文書内容を"Content1"で表すことにする。その後、user1は、登録したＩＤ付き文書を他のユーザuser2に配布する。この配布は、例えば、電子メールにそのＩＤ付き文書を添付して各ユーザに送信することにより、行うことができる。
【００５６】
その後、他のユーザuser2が自分のクライアント端末の文書操作部２００でＩＤ付き文書"Doc1"を閲覧する。閲覧されるのは内容ＩＤ"Content1"の文書内容である。クライアント端末は、閲覧の結果としてＩＤ付き文書"Doc2"を生成し、このＩＤ付き文書"Doc2"が文書管理サーバ１０に登録される。このＩＤ付き文書のメタ情報における管理ＩＤは"Doc2"であり親ＩＤは"Doc1"である。また操作者はuser2であり、操作種別は「閲覧」である。また、「閲覧」操作では文書内容は変更されないので、文書内容は"Content1"のままである。このように文書内容が変更されない操作を行った場合、クライアント端末２０は、文書内容を省略したＩＤ付き文書を文書管理サーバ１０に送ってもよい。文書管理サーバ１０は、受け取ったＩＤ付き文書の親ＩＤの値から、当該文書"Doc2"が文書"Doc1"の子であることを認識し、しかも最初の子であるので、文書"Doc2"のノードアドレスを「／１／１」とする。
【００５７】
なお、この操作の前にuser2のクライアント端末２０内にあったＩＤ付き文書"Doc1"は、この操作に伴い、派生関係組込部２０４によりＩＤ付き文書"Doc2"に置き換えられる。この置き換え処理では、派生関係組込部２０４は、元のＩＤ付き文書"Doc1"のうち、メタ情報３１０の管理ＩＤ３１２を新たに発行したＩＤ"Doc2"へ変更すると共に、元の文書"Doc1"の管理ＩＤ"Doc1"を親ＩＤ３１４の値にセットする。また、派生関係組込部２０４は、ログ情報３１６中の操作種別の値を今回の操作の種別である「閲覧」に変更し、操作時刻の値をその閲覧の日時に変更し、操作者の値をuser2に変更する。なお、「閲覧」操作によっては文書の内容は変化しないので、文書内容３２０は、"Content1"のままである。
【００５８】
このようにＩＤ付き文書"Doc1"は、閲覧されると、閲覧後のＩＤ付き文書"Doc2"に置き換えられる。したがって、その置き換えの後は、ＩＤ付き文書"Doc1"自体はそのクライアント端末２０には存在せず、その代わりにＩＤ付き文書"Doc2"が存在することとなる。
【００５９】
その後、user2が自分のクライアント端末２０の文書操作部２００によってＩＤ付き文書"Doc2"に対して編集を加え、操作メニュー上で「更新版として登録」を指示すると、クライアント端末２０は、管理ＩＤ３１２の値が"Doc3"、親ＩＤ３１４の値が"Doc2"、操作種別の値が「更新」であるＩＤ付き文書"Doc3"を生成する。そして、クライアント端末２０は、生成したＩＤ付き文書"Doc3"を「更新」操作の前のＩＤ付き文書"Doc2"と置き換えると共に、ＩＤ付き文書"Doc3"を文書管理サーバ１０に登録する。編集により、文書内容は"Content1"から"Content2"に変化している。文書管理サーバ１０の派生関係ＤＢ１１０には、管理ＩＤ"Doc3"のレコードが登録される。
【００６０】
その後、user2は、電子メールなどによってＩＤ付き文書"Doc3"をuser3及びuser4に配布する。
【００６１】
次に、user2から配布されたＩＤ付き文書"Doc3"に対して、user3のクライアント端末２０の文書操作部２００によって「更新（更新版として登録）」操作が行われる。user3のクライアント端末２０は、その更新結果の文書内容"Content3"を含み、親ＩＤが"Doc3"であり、操作種別の値が「更新」である新たなＩＤ付き文書"Doc4"を生成し、文書管理サーバ１０に登録する。user3のクライアント端末２０のＩＤ付き文書"Doc3"は、このＩＤ付き文書"Doc4"に置き換えられる。同様に、user4のクライアント端末２０において、ＩＤ付き文書"Doc3"に対して文書操作部２００によって「更新」操作が行われ、文書内容"Content4"を含み、親ＩＤが"Doc3"であり、操作種別の値が「更新」である新たなＩＤ付き文書"Doc5"が文書管理サーバ１０に登録される。user4のクライアント端末２０のＩＤ付き文書"Doc3"は、ＩＤ付き文書"Doc5"に置き換えられる。
【００６２】
次に、user5が、自分のクライアント端末２０の文書操作部２００によって、管理ＩＤ"Doc4"の文書を文書管理サーバ１０から「取得」する操作を行う。ここで、「取得」操作とは、クライアント端末２０の文書操作部２００によって、文書管理サーバ１０の記憶装置及び他のクライアント端末２０の記憶装置などに記憶されたＩＤ付き文書をダウンロードしたり、複製したりする操作を表す。この「取得」操作によって、親ＩＤが"Doc4"であり、操作種別の値が「取得」であるＩＤ付き文書"Doc6"が生成され、文書管理サーバ１０に登録される。なお、「取得」操作によってＩＤ付き文書３００の文書内容に変化は生じないので、ＩＤ付き文書"Doc6"の文書内容は、操作前のＩＤ付き文書"Doc4"の文書内容と同じ"Content3"のままである。
【００６３】
その後、user5は、自分のクライアント端末２０によって、ＩＤ付き文書"Doc6"に対して「更新」操作を行い、user5のクライアント端末２０は、文書内容"Content5"を含み、親ＩＤが"Doc6"であり、操作種別の値が「更新」である新たなＩＤ付き文書"Doc7"を生成して文書管理サーバ１０に登録し、クライアント端末２０におけるＩＤ付き文書"Doc6"をＩＤ付き文書"Doc7"に置き換える。
【００６４】
以上、派生関係ＤＢ１１０のデータ内容を例に取り、本システムにおける文書操作の情報の登録の様子を説明した。
【００６５】
図４の説明に戻り、組織情報ＤＢ１２０は、文書管理サーバ１０が管理する文書を利用する企業などの団体を構成する組織についての情報を記憶するデータベースである。組織情報ＤＢ１２０は、複数の組織が形成する組織階層の構造を表す情報と、各組織に所属する構成員に関する情報と、を記憶する。
【００６６】
企業などの団体は、一般に、図７に例示するように、階層構造を形成する複数の組織から構成される。組織情報ＤＢ１２０は、例えば、図８の表のようなデータベースとして、図７に例示するような組織階層を表す情報を記憶する。図８を参照すると、団体を構成する各組織の組織名に対応づけて、当該組織に対して組織階層において一段階上位に位置する上位組織の組織名が記憶される。例えば、図７に例示する組織階層において、１Ｇ（グループ）に対して一段階上位に位置するＸ部は、図８の表において、組織名１Ｇの上位組織として対応づけて記憶されている。また、図７の例で１Ｇの下位に位置する組織である１Ｔ（チーム）及び２Ｔについては、図８の表において、組織名１Ｔ及び２Ｔのそれぞれの上位組織として１Ｇが対応づけられている。図８に例示する表は、組織階層の構造を表す情報の表現形式の一例であり、組織階層の構造を表すことができさえすれば、他の表現形式で組織情報ＤＢ１２０に記憶させておいてもよい。
【００６７】
さらに、組織情報ＤＢ１２０には、団体を構成する各組織に所属する構成員についての情報が記憶される。図９に、組織情報ＤＢ１２０に記憶される各組織の構成員についての情報の内容の例を示す。図９の表における１行の情報は、各組織に所属する１人の構成員に対応するレコードである。図９の例では、各構成員のユーザＩＤに対応づけて、所属組織、及び役職の各項目が登録されている。ユーザＩＤは、文書管理システムにおけるユーザの識別情報であり、文書管理システムを用いる団体の各構成員に、１つのユーザＩＤが割り当てられる。所属組織の項目には、団体を構成する複数の組織のうち、その構成員が所属する組織を表す情報が登録される。例えば企業などにおいて、１人の者が複数の組織の業務を兼任で行う場合がある。この場合は、その構成員が複数の組織に所属することを示す情報を所属組織の項目に登録しておけばよい。図９に示す例では、ユーザＩＤがuser8である構成員は、組織１Ｔの業務及び組織２Ｔの業務を兼任で行う者であり、user8のレコードの所属組織の項目には、「１Ｔ，２Ｔ」と登録されている。また、役職の項目は、組織における各構成員の役職の有無を示す。図９に例示する表では、各構成員のレコードの役職の項目に「○」が登録されている場合は、その構成員が組織のリーダなどの役職を有することを示し、「×」が登録されている場合は、その構成員が役職を有しないことを示す。
【００６８】
なお、組織情報ＤＢ１２０における各組織の構成員を表す情報の表現形式は、図９に例示する形式に限られない。例えば、構成員ごとのレコードを組織情報ＤＢ１２０に登録する代わりに、組織ごとのレコードを登録し、各組織に対応するレコードに、その組織の構成員のユーザＩＤ及び役職者のユーザＩＤを登録するようにしてもよい。
【００６９】
以上で説明した派生関係ＤＢ１１０及び組織情報ＤＢ１２０によると、文書管理サーバ１０において、派生関係ＤＢ１１０に登録された各ＩＤ付き文書の操作者を表す情報と、組織情報ＤＢ１２０に登録された各組織の構成員を表す情報と、を照合することで、各ＩＤ付き文書の操作者の所属組織が特定される。また、組織情報ＤＢ１２０に記憶される組織階層の構造を表す情報を用いると、そのＩＤ付き文書の操作者の所属組織の組織階層における位置が特定される。
【００７０】
図４の説明に戻り、要求処理部１４０は、クライアント端末２０からの管理ＩＤを含んだサービス要求に応じて、派生関係ＤＢ１１０を用いたサービスを提供する。要求処理部１４０が提供するサービスとしては、例えば、サービス要求中の管理ＩＤに対応する文書の最新版を検索するサービスがある。また別の例として、サービス要求中の管理ＩＤに対応する始祖（根）の文書又はその始祖についてのログ情報を提供するサービスを挙げることができる。また、別の例として、その管理ＩＤの来歴、すなわち始祖からその管理ＩＤまでに文書が経てきた操作の履歴（例えば誰がいつどんな操作をしたのかを示す情報のリスト）を提供するサービスもある。また、派生関係ＤＢ１１０に登録された属性項目についての検索条件の指定を受け付け、その検索条件を満足するＩＤ付き文書のリストを提供するサービスもある。このサービスに付随して、要求処理部１４０は、そのリストの中からユーザの所望するＩＤ付き文書の選択を受け付け、選択されたＩＤ付き文書を提供してもよい。なお、上述の最新版を検索するサービスは、「操作日時が最新である」という検索条件についての検索結果を提供するサービスと捉えることもできる。また、上述の始祖の文書の情報を提供するサービスは、「ノードアドレスが根を示す文書」という条件についての検索結果を提供するサービスと捉えることができる。また、別の例として、派生関係ＤＢ１１０に基づきＩＤ付き文書群の派生関係を表す木構造の表示画面を提供し、その表示画面上でユーザの所望するＩＤ付き文書の選択を受け付け、選択されたＩＤ付き文書を提供するサービスもある。
【００７１】
サービス要求は、クライアント端末２０に保持されたＩＤ付き文書に基づき発せられる。例えば、ユーザがクライアント端末２０の文書操作部２００によりＩＤ付き文書を開いた場合に、文書操作部２００が、派生関係を用いたサービスのメニューを提供し、そのメニューの中からユーザが所望するサービスの指定を受け付ける。そして、そのＩＤ付き文書の管理ＩＤと指定されたサービスを示すコードとを含むサービス要求を文書管理サーバ１０の要求処理部１４０に送信する。このとき、ユーザ識別情報や操作日時などの属性項目についての検索条件を指定するユーザインタフェース画面を提供し、この画面を介して入力された検索条件を併せて要求処理部１４０に送信してもよい。また、管理ＩＤと、サービスを示すコード、検索条件以外に、指示を行ったユーザの識別情報や、ユーザの入力した認証情報などといった他の情報を、クライアント端末２０から要求処理部１４０に送信するようにしてもよい。
【００７２】
また別の例として、ユーザによるサービスの指定を一つの「操作」と捉え、その「操作」に対して新たに管理ＩＤを付与することも考えられる。この場合、指定されたサービスのコードを操作種別として含み、指定の際に用いられた元のＩＤ付き文書の管理ＩＤを親ＩＤとして含んだＩＤ付き文書を生成し、このＩＤ付き文書をサービス要求として文書管理サーバ１０に送ってもよい。この場合、要求処理部１４０は、受け取ったＩＤ付き文書内の操作種別の情報に基づき提供すべきサービスを判定し、同じくＩＤ付き文書内の親ＩＤを、派生関係を遡る処理の起点とする。
【００７３】
要求処理部１４０は、クライアント端末２０からサービス要求を受けた場合、そのサービス要求中に指定された管理ＩＤを起点に、派生関係ＤＢ１１０に登録された管理ＩＤと親ＩＤとの派生関係が構成する木を走査（トラバース）し、その走査の結果得られた情報を用いて、ユーザから要求されたサービスを実行する。
【００７４】
また、本実施形態において、要求処理部１４０は、アクセス制御部１４２を含む。アクセス制御部１４２は、クライアント端末２０から特定の文書の提供を要求するサービス要求を受けた場合に、クライアント端末２０に対する文書の提供を許可するか否かを決定する。例えば、上述のような、指定された検索条件を満足するＩＤ付き文書のリスト又はＩＤ付き文書群の派生関係を表す木構造の表示画面を提供し、ユーザの所望するＩＤ付き文書の選択を受け付け、選択されたＩＤ付き文書を提供するサービスにおいて、アクセス制御部１４２は、当該ユーザに対して、選択されたＩＤ付き文書の提供を許可するか否かを決定する。
【００７５】
本実施形態では、例えば、組織階層における上位組織から下位組織に文書が配布され、それぞれの配布先において当該文書が更新される場合に、組織階層において、より下位に位置する組織に配布された文書ほど、アクセスを許可されるユーザが少なくなるように、文書に対するアクセス制御が行われる。このような状況の一例として、企業における人事考課で使用する活動評価文書などの文書の配布及び更新について説明する。このような文書は、まず、上位組織が決定した活動方針などを書き込んだ文書として上位組織の役職者によって作成され、各下位組織の役職者（リーダなど）に配布される。各組織の役職者は、配布された文書に対して、自身の組織の活動目標及び活動内容などを書き込むことでその文書を更新した後、更新後の文書を自身の組織の構成員（メンバ）に展開する。組織の各構成員は、自組織のリーダから展開された文書に対して、個人的な活動目標及び活動内容などを書き込む。このような場合、各組織の活動内容など、各組織のリーダによって文書に書き込まれる内容は、他の組織に対しては開示しない研究テーマなどの情報を含むことがある。また、各個人が文書に書き込む内容は、例えば個人のキャリア設計に関する情報など、その個人の上司に該当する者（その個人の所属組織のリーダなど）以外の者には開示しない情報を含むことがある。
【００７６】
以上で説明した例のような状況において、アクセス制御部１４２は、派生関係ＤＢ１１０及び組織情報ＤＢ１２０に記憶された情報を用いて、ＩＤ付き文書のアクセス制御を行う。具体的には、アクセス制御部１４２は、ＩＤ付き文書に対するアクセス要求が以下の（条件１）又は（条件２）に適合するか否かを判定することで、要求者に対してそのＩＤ付き文書へのアクセスを許可するか否かを決定する。
【００７７】
・（条件１）ＩＤ付き文書の派生関係群が示す木構造において、要求者自身の操作によって文書管理サーバ１０に登録されたＩＤ付き文書を根ノードとする部分木に含まれるＩＤ付き文書に対するアクセス要求は許可する。
・（条件２）要求者の所属組織から組織階層を遡った経路上に含まれる組織のいずれかに、要求対象のＩＤ付き文書の操作者が所属し、かつ、要求対象のＩＤ付き文書が、組織階層における上位組織の役職者から一段階ずつ下位に位置する組織の役職者によって順に更新登録された履歴を有する場合、アクセス要求を許可する。
【００７８】
（条件１）は、あるユーザが、自分自身の操作によって文書管理サーバ１０に登録されたＩＤ付き文書及び当該ＩＤ付き文書から派生したＩＤ付き文書に対してアクセスできるようにするための条件である。例えば、組織の役職者が更新登録したＩＤ付き文書に対して当該組織の構成員が書き込みを行って更新登録したＩＤ付き文書について、当該組織の役職者がアクセスできるようにする。
【００７９】
（条件２）の前半部の条件は、要求者の所属組織に所属するユーザ又は要求者の所属組織に対して組織階層において直系の上位に位置する組織に所属するユーザが更新登録したＩＤ付き文書でなければ、アクセスを許可しないようにするための条件である。この条件によると、例えば、図７に例示する組織階層の組織１Ｔに所属するユーザは、例えば組織２Ｔ及び組織Ｙ部など、組織１Ｔの直系の上位に位置しない組織に所属するユーザが更新登録したＩＤ付き文書に対してはアクセスを許可されない。
【００８０】
（条件２）の後半部の条件によると、組織階層における上位組織の役職者から下位組織の役職者へ順次配布及び更新されたＩＤ付き文書は正規の展開経路を経ているとみなされ、正規の展開経路を経ていないＩＤ付き文書に対するアクセスは許可されない。例えば、図７に例示する組織階層の組織Ｘ部の役職者が更新登録したＩＤ付き文書について、組織Ｘ部の一段階下位の組織１Ｇの役職者による更新登録を経ることなく、組織１Ｇの一段階下位の組織１Ｔの役職者が更新登録を行った結果のＩＤ付き文書は、正規の展開経路を経ていないとみなされる。
【００８１】
以下、アクセス制御部１４２が行う処理の詳細な手順について説明する。
【００８２】
図１０及び図１１に、アクセス制御部１４２において、指定されたＩＤ付き文書の提供を許可するか否かを決定する処理の手順の例を示す。
【００８３】
アクセス制御部１４２は、要求処理部１４０において、ユーザに対するＩＤ付き文書の提供の可否を決定する必要が生じた場合に、図１０に例示する手順の処理を開始する。
【００８４】
図１０を参照し、アクセス制御部１４２は、ステップＳ１０で初期化処理を行う。ステップＳ１０では、注目ユーザＩＤ（以下、「注目ユーザｕ」とも呼ぶ）として文書の提供を要求したユーザのユーザＩＤが設定され、注目管理ＩＤ（以下、「注目文書ｒ」とも呼ぶ）として要求対象のＩＤ付き文書の管理ＩＤが設定される。さらに、ステップＳ１０では、「順次性チェック」と呼ばれるフラグの値がtrueに設定される。順次性チェックフラグは、上述の（条件２）を満たすか否かを示すフラグである。
【００８５】
次に、ステップＳ１２で、アクセス制御部１４２は、派生関係ＤＢ１１０を参照し、管理ＩＤとして注目文書ｒが登録されたレコードを読み出し、当該レコードの操作者の項目に登録されたユーザＩＤ（すなわち、注目文書ｒの操作者のユーザＩＤ）を取得する。そして、取得したユーザＩＤと、ＩＤ付き文書の提供要求を行った要求者のユーザＩＤと、が一致するか否かを判定する。図１０に例示するフローチャートにおいては、派生関係ＤＢ１１０から取得される、注目文書ｒの操作者のユーザＩＤを「Ｏ（ｒ）」と記載し、以下の説明においても、この記載を用いる。ステップＳ１２で、Ｏ（ｒ）が要求者のユーザＩＤと一致する場合は、ステップＳ２４に進む。この場合、上述の（条件１）を満たすことになる。ステップＳ２４では、アクセス制御部１４２は、要求対象の文書に対するアクセスを許可することを決定し、処理を終了する。
【００８６】
ステップＳ１２で、Ｏ（ｒ）が要求者のユーザＩＤと一致しない場合、処理はステップＳ１４に進む。
【００８７】
ステップＳ１４では、アクセス制御部１４２は、組織情報ＤＢ１２０を参照し、注目文書ｒの操作者のユーザＩＤであるＯ（ｒ）に対応付けられた所属組織と、注目ユーザｕに対応付けられた所属組織と、を取得し、両者が一致するか否かを判定する。図１０に例示するフローチャートでは、組織情報ＤＢ１２０から取得される、特定のユーザＩＤ：ｕｉｄのユーザの所属組織をＧ（ｕｉｄ）と記載する。以下の説明においても、この記載を用いる。この記載に従って、注目文書ｒの操作者Ｏ（ｒ）の所属組織はＧ（Ｏ（ｒ））と表され、注目ユーザｕの所属組織はＧ（ｕ）と表される。
【００８８】
なお、ここで説明する処理の例において、ステップＳ１４における所属組織Ｇ（Ｏ（ｒ））とＧ（ｕ）とが一致するか否かの判定は、組織間の包含関係を考慮せずに行われる。例えば、図７に例示する構造を有する組織階層において、組織１Ｇは、組織１Ｔ及び組織２Ｔに対して一段階上位に位置し、組織１Ｇは、組織１Ｔ及び組織２Ｔを含んでいると捉えることもできる。しかしながら、ステップＳ１４での所属組織同士の照合においては、組織１Ｇと、組織１Ｔ又は組織２Ｔと、は一致しないと判定される。また、例えば図９の表におけるuser8のように複数の組織に所属するユーザについては、そのユーザの複数の所属組織のいずれかと、照合対象のユーザの所属組織と、が一致していれば、両ユーザの所属組織は一致すると判定するものとする。
【００８９】
ステップＳ１４で、注目文書ｒの操作者の所属組織Ｇ（Ｏ（ｒ））と注目ユーザｕの所属組織Ｇ（ｕ）とが一致すると判定された場合、処理はステップＳ１６に進む。
【００９０】
ステップＳ１６で、アクセス制御部１４２は、組織情報ＤＢ１２０を参照し、注目文書ｒの操作者Ｏ（ｒ）が役職を有する者であるか否かを判定する。例えば、組織情報ＤＢ１２０に図９に例示する表の内容の情報が記憶されている場合、Ｏ（ｒ）に対応するレコードの役職者の項目に「○」が登録されていれば、Ｏ（ｒ）が役職者であると判定し、「×」が登録されていれば、役職者でないと判定する。
【００９１】
ステップＳ１６で、注目文書ｒの操作者Ｏ（ｒ）が役職者であると判定されると、ステップＳ１７に進む。ステップＳ１７では、アクセス制御部１４２は、ＩＤ付き文書の派生関係群が表す木構造において、注目文書ｒを起点に１つずつＩＤ付き文書（ノード）を遡っていき、操作種別の値が「更新」又は「登録」であるノードを最初に発見した時点で、当該ノードの操作者を取得する。派生関係ＤＢ１１０において注目文書ｒのレコードに親ＩＤとして登録されている管理ＩＤのレコードを取得し、当該レコードに登録されている操作種別の値が「更新」又は「登録」であれば、当該レコードに含まれる操作者の項目に登録されたユーザＩＤを取得し、操作種別の値が「更新」及び「登録」以外の値であれば、当該レコードに登録されている親ＩＤの値を管理ＩＤとして含むレコードを取得し、そのレコードの操作種別の値が「更新」又は「登録」であるか否かを判定する。このような処理を繰り返すことで、アクセス制御部１４２は、注目文書ｒから木構造を遡って最初に発見された操作種別「更新」又は「登録」のノードの管理ＩＤ（図１０のフローチャートではＰ（ｒ）と表す）に対応づけられた操作者Ｏ（Ｐ（ｒ））を取得する。なお、注目文書ｒが木構造の根ノードに該当する文書である場合、つまり、注目文書ｒを管理ＩＤとして含むレコードの親ＩＤの値が「なし（null）」である場合、注目文書ｒを起点に木構造を遡ることはできないので、アクセス制御部１４２は、操作者Ｏ（Ｐ（ｒ））の値として、操作者Ｏ（Ｐ（ｒ））を取得できない旨を示す情報（例えば、「なし（null）」）を設定する。操作者Ｏ（Ｐ（ｒ））の値が決定されると、アクセス制御部１４２は、操作者Ｏ（Ｐ（ｒ））と、注目文書ｒの操作者Ｏ（ｒ）と、が一致するか否かを判定し、一致しなければステップＳ１８に進み、一致すれば、ステップＳ１９で、注目文書ｒから木構造を遡って最初に発見された操作種別「更新」又は「登録」のノードＰ（ｒ）を新たな注目文書ｒとして設定する。ステップＳ１９の後、再びステップＳ１７の判定が行われる。
【００９２】
ここで、Ｐ（ｒ）は、ＩＤ付き文書の派生関係群が表す木構造において、要求対象のＩＤ付き文書に対して先祖に該当するＩＤ付き文書であると言える。一般に、木構造において、ある注目ノードを起点に根ノードまで木構造を遡った経路上に含まれるノードは、その注目ノードの「先祖」と呼ばれる。
【００９３】
ステップＳ１８では、アクセス制御部１４２は、組織情報ＤＢ１２０を参照し、組織階層において注目ユーザｕの所属組織Ｇ（ｕ）が最上位に位置する組織であるか否かを判定する。例えば、図８に例示する表のようなデータ内容が組織情報ＤＢ１２０に格納されている場合、アクセス制御部１４２は、組織情報ＤＢ１２０においてＧ（ｕ）に対応づけられた上位組織を調べ、上位組織の組織名が登録されていれば、Ｇ（ｕ）は組織階層において最上位に位置しないと判定し、上位組織の組織名が登録されていなければ（例えば、図８の組織名「全社」に対応づけて上位組織「なし」が登録されている）、Ｇ（ｕ）は組織階層において最上位に位置すると判定する。Ｇ（ｕ）が最上位に位置する組織でなければ、ステップＳ２０に進み、最上位に位置する組織であれば、ステップＳ２２に進む。
【００９４】
ステップＳ２０では、アクセス制御部１４２は、組織情報ＤＢ１２０を参照し、注目ユーザｕの所属組織に対して組織階層において一段階上位に位置する組織に所属する構成員のうちのいずれかのユーザＩＤを、新たな注目ユーザｕとして設定する。例えば、図８及び図９に例示する表のデータ内容が組織情報ＤＢ１２０に登録されている場合、図９の表を参照して注目ユーザｕの所属組織を取得し、次に、図８の表を参照して注目ユーザｕの所属組織に対応付けられた上位組織を取得する。そして、再び図９の表を参照し、所属組織の項目に取得した上位組織を含むレコードのうちの１つに含まれるユーザＩＤを取得する。図１０に例示するフローチャートでは、この一連の処理によって得られる、注目ユーザｕの所属組織に対して組織階層において一段階上位の組織に所属する者をＳｐ（ｕ）と記載し、以下の説明においても、この記載を用いる。
【００９５】
ステップＳ１６で、注目文書ｒの操作者Ｏ（ｒ）が役職者でないと判定されると、アクセス制御部１４２は、図１１に例示する手順の処理を行う。図１１に示す処理については後述する。
【００９６】
ステップＳ２０の後、ステップＳ２１で、アクセス制御部１４２は、注目文書ｒが、ＩＤ付き文書の派生関係群によって表される木構造において根ノードに該当するか否かを判定する。派生関係ＤＢ１１０に記憶されたレコードのうち、注目文書ｒを管理ＩＤとして含むレコードの親ＩＤの値が「なし（null）」であれば、木構造の根ノードであると判定され、親ＩＤとして他の管理ＩＤの値が登録されていれば根ノードではないと判定される。例えば、図５に例示するデータ内容が派生関係ＤＢ１１０に登録されている場合、親ＩＤの値が「なし」である管理ＩＤ"Doc5"のノードが派生関係の木構造（図６）の根ノードに該当する。
【００９７】
ステップＳ２１で注目文書ｒが根ノードであると判定されると、ステップＳ２２で、順次性チェックフラグがfalseに設定されているか否かが判定される。順次性チェックフラグがfalseに設定されていなければ、アクセス許可（ステップＳ２４）され、falseに設定されていれば、アクセスは許可されず、エラー（ステップＳ２６）となる。
【００９８】
ステップＳ２１で、注目文書ｒが根ノードではないと判定されると、ステップＳ２８に進む。ステップＳ２８で、アクセス制御部１４２は、ステップＳ１７において説明したのと同様の処理を行って、ＩＤ付き文書の派生関係群が表す木構造を注目文書ｒから遡って最初に発見された操作種別「更新」又は「登録」のノードの管理ＩＤ（Ｐ（ｒ））を取得し、取得した管理ＩＤ（Ｐ（ｒ））を新たな注目文書ｒとする。その後、処理はステップＳ１２に戻る。
【００９９】
以上、ステップＳ１４で、注目文書ｒの操作者の所属組織Ｇ（Ｏ（ｒ））と注目ユーザｕの所属組織Ｇ（ｕ）とが一致すると判定された場合の処理手順の例について説明した。以下、ステップＳ１４で、Ｇ（Ｏ（ｒ））とＧ（ｕ）とが一致しないと判定された場合の処理手順の例について説明する。この場合、ステップＳ１４の判定の結果、処理はステップＳ３０に進む。
【０１００】
ステップＳ３０では、順次性チェックフラグの値がfalseに設定されているか否かを判定する。falseに設定されていれば、ステップＳ３８に進み、falseに設定されていなければ、ステップＳ３２に進む。ステップＳ１０の初期化処理において、順次性チェックフラグの値はtrueに設定されるので、図１０に例示するフローチャートの処理を開始してから、初めてステップＳ３０の判定が行われる場合は、Ｎｏ判定されてステップＳ３２に進む。
【０１０１】
ステップＳ３２では、注目文書ｒが要求対象のＩＤ付き文書の管理ＩＤであるか否かを判定する。注目文書ｒが要求対象のＩＤ付き文書の管理ＩＤであれば、ステップＳ３４に進み、注目文書ｒが要求対象のＩＤ付き文書の管理ＩＤでなければ、ステップＳ３８に進む。ステップＳ１０の初期化処理の後、ステップＳ１２、ステップＳ１４、及びステップＳ３０のすべてにおいてＮｏ判定されてステップＳ３２の判定が行われる場合、注目文書ｒの値は、初期化処理（ステップＳ１０）で要求対象のＩＤ付き文書の管理ＩＤに設定されたまま変更されないので、ステップＳ３２では、Ｙｅｓ判定されてステップＳ３４に進む。一方、図１０に例示する手順の処理が開始されてから、一度でもステップＳ２８において注目文書ｒの値が変更された後にステップＳ３２の判定が行われると、Ｎｏ判定されてステップＳ３８に進む。
【０１０２】
ステップＳ３４で、アクセス制御部１４２は、組織情報ＤＢ１２０を参照し、組織階層において注目ユーザｕの所属組織Ｇ（ｕ）が最上位に位置する組織であるか否かを判定する。ステップＳ３４の判定処理は、上記で説明したステップＳ１８の判定処理と同様である。Ｇ（ｕ）が最上位に位置する組織でなければ、ステップＳ３６に進み、最上位に位置する組織であれば、ステップＳ３８に進む。
【０１０３】
注目ユーザｕの所属組織に対して上位組織が存在する場合、ステップＳ３６で、アクセス制御部１４２は、注目ユーザｕの所属組織に対して組織階層において一段階上位の組織に所属する者のユーザＩＤを新たな注目ユーザｕとして設定する。ステップＳ３６の後、処理はステップＳ１４に戻る。
【０１０４】
ステップＳ３０でＹｅｓ判定、ステップＳ３２でＮｏ判定、又はステップＳ３４でＹｅｓ判定された場合、ステップＳ３８で、順次性チェックフラグの値がfalseに設定される。ステップＳ３８の後、処理はステップＳ２１に進む。
【０１０５】
ステップＳ１４，Ｓ３０，Ｓ３２，Ｓ３４，Ｓ３６を含む処理ループでは、要求者の所属組織を起点に最上位の組織まで組織階層を遡った経路上に含まれる組織のいずれかに、要求対象のＩＤ付き文書の操作者が所属するか否か、つまり、上述の（条件２）の前半部の条件を満たすか否かが判定される。
【０１０６】
以上で説明した図１０に例示する手順では、要求対象のＩＤ付き文書の管理ＩＤを起点にＩＤ付き文書の派生関係群が表す木構造を遡る（ステップＳ１９，Ｓ２８）ことで得られるＩＤ付き文書の操作者の情報と、要求者のユーザＩＤを用いて組織階層を遡る（ステップＳ２０，Ｓ３６）ことで得られる組織の構成員の情報と、を照合する（ステップＳ１４）ことで、組織階層における要求者の位置づけと要求対象のＩＤ付き文書の流通経路とが適合するか否かを確認する。
【０１０７】
図１１を参照し、図１０のステップＳ１６で、注目文書ｒの操作者が役職者でないと判定された場合に行われる処理手順の例について説明する。注目文書ｒの操作者が役職者でないと判定された場合、上述の（条件２）の後半部の条件（要求対象のＩＤ付き文書が、組織階層における上位組織の役職者から一段階ずつ下位に位置する組織の役職者によって順に更新登録された履歴を有すること）を満たさない。よって、図１１に例示する手順の処理では、上述の（条件１）を満たすか否かが判定される。
【０１０８】
図１０のステップＳ１６でＮｏ判定されると、図１１のステップＳ４０に進む。ステップＳ４０で、アクセス制御部１４２は、図１０を参照して説明したステップＳ２１の処理と同様に、注目文書ｒがＩＤ付き文書の派生関係群が表す木構造における根ノードに該当するか否かを判定する。注目文書ｒが根ノードである場合、ステップＳ４８のエラー処理が行われ、処理は終了する。
【０１０９】
注目文書ｒが根ノードでない場合、ステップＳ４２に進み、図１０を参照して説明したステップＳ２８の処理と同様に、注目文書ｒから派生関係群の木構造を遡って最初に発見される、操作種別の値が「更新」又は「登録」であるノードの管理ＩＤが新たな注目文書ｒとされる。次に、ステップＳ４４で、注目文書ｒの操作者Ｏ（ｒ）と、要求者のユーザＩＤと、が一致するか否かが判定され、一致すればステップＳ４６に進み、一致しなければステップＳ４０に戻る。ステップＳ４６で、アクセス制御部１４２は、要求対象のＩＤ付き文書に対するアクセスを許可し、処理を終了する。
【０１１０】
以上、図１０及び図１１に例示する手順の処理により、アクセス制御部１４２がアクセス許可した（ステップＳ２４，Ｓ４６）場合、要求処理部１４０は、要求対象のＩＤ付き文書に対応する文書内容を文書ＤＢ１００から取得し、取得した文書内容をクライアント端末２０に対して送信する。一方、図１０及び図１１に例示する手順の処理により、アクセス制御部１４２がエラーとした（ステップＳ２６，Ｓ４８）場合、要求処理部１４０は、要求対象のＩＤ付き文書に対応する文書内容をクライアント端末２０に送信しない。エラーの場合、例えば、ＩＤ付き文書に対するアクセスが許可されない旨を示すエラーメッセージをクライアント端末２０の表示部に表示させる。
【０１１１】
以下、図５に例示する表のデータ内容が派生関係ＤＢ１１０に登録され、図８及び図９に例示する表のデータ内容が組織情報ＤＢ１２０に登録されている場合に、図１０及び図１１に例示する手順の処理によるアクセス制御の具体例について説明する。
【０１１２】
＜具体例１＞
上述の（条件１）を満たす場合の例として、図５及び図６を参照し、ユーザＩＤ"user5"を有するユーザが、管理ＩＤ"Doc7"のＩＤ付き文書の提供を要求した場合のアクセス制御部１４２の処理について説明する。この場合、図１０のステップＳ１０で、注目ユーザｕはuser5、注目文書ｒは"Doc7"に設定される。図５の表において、管理ＩＤ"Doc7"のレコードには操作者としてuser5が登録されており、図１０のステップＳ１２で、注目文書ｒ"Doc7"の操作者はuser5であり、注目ユーザｕと一致するため、アクセスが許可される（ステップＳ２４）。
【０１１３】
＜具体例２＞
上述の（条件１）を満たす他の例として、図５及び図６を参照し、ユーザＩＤ"user3"のユーザが、管理ＩＤ"Doc7"のＩＤ付き文書の提供を要求した場合のアクセス制御部１４２の処理について説明する。この場合、図１０のステップＳ１０で、注目ユーザｕはuser3、注目文書ｒは"Doc7"に設定される。ステップＳ１２で、注目文書ｒ"Doc7"の操作者はuser5であり、注目ユーザｕであるuser3と一致しないので、ステップＳ１４に進む。ステップＳ１４で、組織情報ＤＢ１２０（図９）を参照すると、注目文書ｒ"Doc7"の操作者であるuser5の所属組織１Ｔと、注目ユーザｕであるuser3の所属組織１Ｔと、が一致するので、処理はステップＳ１６に進む。注目文書ｒ"Doc7"の操作者であるuser5は、役職者ではない（図９参照）ので、ステップＳ１６の判定の結果、処理は図１１のステップＳ４０に進む。図１１のステップＳ４０で、注目文書ｒ"Doc7"は文書の派生関係の木構造の根ノードではないので、ステップＳ４２に進み、注目文書ｒ"Doc7"を起点に木構造を遡って最初に発見される「更新」操作のノードの管理ＩＤ"Doc4"が新たな注目文書ｒとして設定される。次に、ステップＳ４４で、この新たな注目文書ｒ"Doc4"の操作者はuser3であり、要求者のユーザＩＤであるuser3と一致するので、アクセスが許可される（ステップＳ４６）。
【０１１４】
＜具体例３＞
（条件２）を満たす例として、ユーザＩＤ"user5"のユーザが、ＩＤ付き文書"Doc4"の提供を要求した場合について説明する。まず、図１０のステップＳ１０で、注目ユーザｕはuser5、注目文書ｒは"Doc4"に設定される。ステップＳ１２で、注目文書ｒ"Doc4"の操作者はuser3であり、注目ユーザｕであるuser5と一致しないので、ステップＳ１４に進む。ステップＳ１４で、組織情報ＤＢ１２０（図９）を参照すると、注目文書ｒ"Doc4"の操作者user3の所属組織１Ｔと、注目ユーザｕであるuser5の所属組織１Ｔと、が一致するので、処理はステップＳ１６に進む。注目文書ｒ"Doc4"の操作者であるuser3は、役職者である（図９参照）ので、ステップＳ１７に進む。注目文書ｒ"Doc4"の操作者であるuser3と、注目文書ｒ"Doc4"を起点に木構造を遡って最初に発見される「更新」ノード"Doc3"の操作者であるuser2と、は一致しないので、ステップＳ１７の判定の結果、ステップＳ１８に進む。注目ユーザｕであるuser5の所属組織１Ｔは最上位組織ではないので、ステップＳ１８の判定の結果、ステップＳ２０に進み、user5の所属組織１Ｔに対して組織階層において一段階上位に位置する組織１Ｇ（図７及び図８参照）に所属する者であるuser2（図９参照）が新たな注目ユーザｕとして設定される。注目文書ｒ"Doc4"は、文書の派生関係の木構造の根ノードではないので、ステップＳ２１の判定の結果、ステップＳ２８に進み、注目文書ｒ"Doc4"を起点に木構造を遡って最初に発見される「更新」ノードの管理ＩＤ"Doc3"が新たな注目文書ｒとして設定される。
【０１１５】
その後、ステップＳ１２で、注目文書ｒ"Doc3"の操作者であるuser2と、要求者であるuser5と、が一致しないので、再びステップＳ１４の判定が行われる。ステップＳ１４では、現在の注目文書ｒ"Doc3"の操作者であるuser2の所属組織１Ｇと、現在の注目ユーザｕであるuser2の所属組織１Ｇと、が一致するので、ステップＳ１６に進む。さらに、注目文書ｒ"Doc3"の操作者であるuser2は役職者であるので（図９参照）、ステップＳ１７に進む。user2は、注目文書ｒ"Doc3"を起点に木構造を遡って最初に発見される「登録」ノード"Doc1"の操作者であるuser1と一致しないので、ステップＳ１７の判定の結果、ステップＳ１８に進む。ステップＳ１８で、注目ユーザｕ（user2）の所属組織１Ｇは最上位組織ではないので、判定の結果ステップＳ２０に進み、組織１Ｇに対して組織階層において一段階上位の組織Ｘ部（図７及び図８参照）に所属する者であるuser1（図９参照）が新たな注目ユーザｕとして設定される。次に、現在の注目文書ｒ"Doc3"は、文書の派生関係の木構造の根ノードではないので（ステップＳ２１でＮｏ判定）、注目文書ｒ"Doc3"から木構造を遡って最初に発見される「登録」ノードの管理ＩＤ"Doc1"が新たな注目文書ｒとして設定される（ステップＳ２８）。
【０１１６】
さらに、ステップＳ１２で、注目文書ｒ"Doc1"の操作者であるuser1と、要求者であるuser5と、が一致しないのでステップＳ１４に進み、現在の注目文書ｒ"Doc1"の操作者であるuser1の所属組織Ｘ部と、現在の注目ユーザｕであるuser1の所属組織Ｘ部と、が一致するので、ステップＳ１６に進む。注目文書ｒ"Doc1"の操作者であるuser1は役職者であるので（図９参照）、ステップＳ１７に進む。注目文書ｒ"Doc1"は木構造の根ノードであり、注目文書ｒ"Doc1"を起点に遡って発見される「更新」又は「登録」ノードＰ（"Doc1"）は存在しないため、ステップＳ１７でＮｏ判定され、ステップＳ１８に進む。ステップＳ１８では、user1の所属組織Ｘ部は最上位組織ではないためＮｏ判定されてステップＳ２０に進み、user1の所属組織Ｘ部の上位組織に所属するユーザのユーザＩＤが注目ユーザｕとして設定され、ステップＳ２１に進む。ステップＳ２１で、現在の注目文書ｒ"Doc1"は根ノードであるのでステップＳ２２に進む。以上で説明した本例の処理では、順次性チェックフラグの値は、初期化処理（ステップＳ１０）でtrueに設定されたまま変更されないので、ステップＳ２２の判定の結果、ステップＳ２４に進み、要求対象のＩＤ付き文書"Doc4"に対するアクセスが許可される。
【０１１７】
＜具体例４＞
正規の展開経路を経ていないＩＤ付き文書に対するアクセス要求であることから上述の（条件２）を満たさない例として、ユーザＩＤ"user5"のユーザが、ＩＤ付き文書"Doc13"の提供を要求した場合について説明する。ＩＤ付き文書"Doc13"は、user3が、組織階層において自己の所属組織１Ｔに対して二段階上位に位置する組織Ｘ部に所属するuser1によって更新登録されたＩＤ付き文書"Doc1"を更新した結果の文書である。つまり、ＩＤ付き文書"Doc13"は、user3の所属組織１Ｔに対して一段階上位の組織１Ｇに所属するuser2による更新操作を経ることなく生成された文書である。このように、ＩＤ付き文書"Doc13"は、上述の（条件２）を満たさないので、ＩＤ付き文書"Doc13"に対するアクセス要求は許可されない。以下、この例の場合のアクセス制御部１４２の処理について説明する。
【０１１８】
図１０のステップＳ１０で、注目ユーザｕはuser5、注目文書ｒは"Doc13"に設定される。次に、ステップＳ１２で、注目文書ｒ"Doc13"の操作者はuser3であり、注目ユーザｕであるuser5と一致しないので、ステップＳ１４に進む。ステップＳ１４で、組織情報ＤＢ１２０（図９）を参照すると、注目文書ｒ"Doc13"の操作者であるuser3の所属組織１Ｔと、注目ユーザｕであるuser5の所属組織１Ｔと、が一致するので、処理はステップＳ１６に進み、注目文書ｒ"Doc13"の操作者user3は役職者であるので、ステップＳ１７に進む。注目文書ｒ"Doc13"の操作者user3と、注目文書ｒ"Doc13"を起点に木構造を遡って最初に発見される「登録」ノード"Doc1"の操作者であるuser1と、は一致しないため、ステップＳ１７の判定の結果、ステップＳ１８に進む。注目ユーザｕであるuser5の所属組織１Ｔは、最上位組織ではないので、ステップＳ１８の判定の結果ステップＳ２０に進み、user5の所属組織１Ｔに対して組織階層において一段階上位に位置する組織１Ｇ（図７及び図８参照）に所属する者であるuser2（図９参照）が新たな注目ユーザｕとして設定される。次に、注目文書ｒ"Doc13"は、文書の派生関係の木構造の根ノードではないので、ステップＳ２１の判定の結果、ステップＳ２８に進み、注目文書ｒ"Doc13"を起点に木構造を遡って最初に発見される「登録」ノードの管理ＩＤ"Doc1"が新たな注目文書ｒとして設定される。
【０１１９】
その後、ステップＳ１２で、注目文書ｒ"Doc1"の操作者であるuser1と、要求者であるuser5と、が一致しないので、再びステップＳ１４の判定が行われる。現在の注目文書ｒ"Doc1"の操作者であるuser1の所属組織Ｘ部と、現在の注目ユーザｕであるuser2の所属組織１Ｇと、が一致しないため、ステップＳ１４の判定の結果、ステップＳ３０に進む。この時点で、順次性チェックフラグの値は、ステップＳ１０でtrueに設定されたまま変更されていないので、ステップＳ３０の判定の結果、ステップＳ３２に進む。現在の注目文書ｒ"Doc1"は、要求対象のＩＤ付き文書の管理ＩＤ"Doc13"と一致しないので、処理は、ステップＳ３２からステップＳ３８に進み、順次性チェックフラグの値がfalseに設定される。その後、注目文書ｒ"Doc1"は、派生関係の木構造の根ノードであるので、ステップＳ２１からステップＳ２２に進む。順次性チェックフラグの値がfalseに設定されているため、ステップＳ２２の判定の結果ステップＳ２６のエラー処理が行われ、ＩＤ付き文書"Doc13"に対するアクセスは許可されない。
【０１２０】
＜具体例５＞
正規の展開経路を経ていない文書に対するアクセス要求であることから（条件２）を満たさない他の例として、ユーザＩＤ"user7"のユーザが、ＩＤ付き文書"Doc10"の提供を要求した場合について説明する。ＩＤ付き文書"Doc10"は、user4が、自己の所属組織２Ｔと異なる組織であって組織階層において同じ階層に位置する（上位下位の関係にない）組織１Ｔに所属するuser3によって更新登録されたＩＤ付き文書"Doc4"に対して更新操作を行った結果の文書である。よって、ＩＤ付き文書"Doc10"の操作者であるuser4は、組織２Ｔの役職者ではあるが、ＩＤ付き文書"Doc10"は、正規の展開経路を経ているとは言えない。したがって、user4と同じ組織２Ｔに所属するuser7が要求者であっても、ＩＤ付き文書"Doc10"に対するアクセスは許可されない。以下、この例のアクセス制御部１４２における処理を説明する。
【０１２１】
図１０のステップＳ１０で、注目ユーザｕはuser7、注目文書ｒは"Doc10"に設定される。次に、ステップＳ１２で、注目文書ｒ"Doc10"の操作者はuser4であり、注目ユーザｕであるuser7と一致しないので、ステップＳ１４に進む。ステップＳ１４で、組織情報ＤＢ１２０（図９）を参照すると、注目文書ｒ"Doc10"の操作者であるuser4の所属組織２Ｔと、注目ユーザｕであるuser7の所属組織２Ｔと、が一致するので、処理はステップＳ１６に進み、注目文書ｒ"Doc10"の操作者であるuser4は役職者であるので、ステップＳ１７に進む。注目文書ｒ"Doc10"の操作者であるuser4と、注目文書ｒ"Doc10"を起点に木構造を遡って最初に発見される「更新」ノード"Doc4"の操作者であるuser3と、は一致しないので、ステップＳ１７の判定の結果、ステップＳ１８に進む。注目ユーザｕであるuser7の所属組織２Ｔは最上位組織ではないので、ステップＳ１８の判定の結果、ステップＳ２０へ進み、user7の所属組織２Ｔに対して組織階層において一段階上位に位置する組織１Ｇ（図７及び図８参照）に所属する者であるuser2（図９参照）が新たな注目ユーザｕとして設定される。
【０１２２】
次に、注目文書ｒ"Doc10"は、文書の派生関係の木構造の根ノードではないので、ステップＳ２１の判定の結果、ステップＳ２８に進み、注目文書ｒ"Doc10"を起点に木構造を遡って最初に発見される「更新」ノードの管理ＩＤ"Doc4"が新たな注目文書ｒとして設定される。
【０１２３】
その後、ステップＳ１２で、注目文書ｒ"Doc4"の操作者であるuser3と、要求者であるuser7と、が一致しないので、再びステップＳ１４の判定が行われる。現在の注目文書ｒ"Doc4"の操作者であるuser3の所属組織１Ｔと、現在の注目ユーザｕであるuser2の所属組織１Ｇと、が一致しないため、ステップＳ１４の判定の結果、ステップＳ３０に進む。この時点で、順次性チェックフラグの値は、ステップＳ１０でtrueに設定されたまま変更されていないので、ステップＳ３０の判定の結果、ステップＳ３２に進む。現在の注目文書ｒ"Doc4"は、要求対象のＩＤ付き文書の管理ＩＤ"Doc10"と一致しないので、処理は、ステップＳ３２からステップＳ３８に進み、順次性チェックフラグの値がfalseに設定される。
【０１２４】
その後、注目文書ｒ"Doc4"は根ノードでないので、"Doc4"から木構造を遡って最初に発見される「更新」ノード"Doc3"が新たな注目文書ｒとして設定され（ステップＳ２１，Ｓ２８）、ステップＳ１２以降の処理が繰り返される。以降の繰り返し処理において、注目文書ｒ"Doc3"の操作者、及び、"Doc3"の次に注目文書ｒとして設定される"Doc1"の操作者は、それぞれ、user2及びuser1であり、要求者であるuser7とは一致しないので、ステップＳ１２でＹｅｓ判定されてアクセス許可（ステップＳ２４）されることはない。よって、派生関係の木構造の根ノードである"Doc1"が注目文書ｒとして設定された後、処理が進むと、ステップＳ２２で、順次性チェックフラグの値の判定が行われる。この時点で、順次性チェックフラグの値は、上述のように、ステップＳ３８でfalseに設定されているので、ステップＳ２２の判定の結果、ステップＳ２６のエラー処理に進み、ＩＤ付き文書"Doc10"に対するアクセスは許可されない。
【０１２５】
＜具体例６＞
要求者の所属組織と異なる組織であって要求者の所属組織と組織階層において同じ階層に位置する組織に所属するユーザによって更新登録されたＩＤ付き文書に対するアクセス制御の例について説明する。この場合、上述の（条件２）の前半部の条件（要求者の所属組織から組織階層を遡った経路上に含まれる組織のいずれかに、要求対象のＩＤ付き文書の操作者が所属すること）を満たさないので、アクセス許可されない。例えば、組織２Ｔに所属するuser7が、組織１Ｔに所属するuser3が更新登録したＩＤ付き文書"Doc4"の提供を要求した場合、要求者user7の所属組織２Ｔを起点に組織階層を遡った経路上に含まれる組織（２Ｔ，１Ｇ，Ｘ部，…，全社）の中に、要求対象の文書であるＩＤ付き文書"Doc4"の操作者user3の所属組織１Ｔが含まれないので、アクセス許可されない。以下、この例におけるアクセス制御部１４２の処理について説明する。
【０１２６】
まず、図１０のステップＳ１０で、注目ユーザｕはuser7、注目文書ｒは"Doc4"に設定される。次に、ステップＳ１２で、注目文書ｒ"Doc4"の操作者はuser3であり、注目ユーザｕであるuser7と一致しないので、ステップＳ１４に進む。ステップＳ１４で、組織情報ＤＢ１２０（図９）を参照すると、注目文書ｒ"Doc4"の操作者であるuser3の所属組織１Ｔと、注目ユーザｕであるuser7の所属組織２Ｔと、が一致しないので、判定の結果ステップＳ３０に進む。この時点で、順次性チェックフラグの値は、ステップＳ１０でtrueに設定されたまま変更されていないので、ステップＳ３０の判定の結果、ステップＳ３２に進む。また、注目文書ｒ"Doc4"は、要求対象のＩＤ付き文書"Doc4"であるので、ステップＳ３２の判定の結果、ステップＳ３４に進む。ステップＳ３４で、注目ユーザｕであるuser7の所属組織２Ｔは、組織階層における最上位の組織ではない（図７及び図８参照）ので、処理はステップＳ３６に進む。ステップＳ３６において、注目ユーザｕであるuser7の所属組織２Ｔに対して一段階上位の組織１Ｇに所属する者であるuser2（図９参照）が新たな注目ユーザｕとして設定される。
【０１２７】
ステップＳ３６の後、ステップＳ１４に戻り、ステップＳ１４で、注目文書ｒ"Doc4"の操作者であるuser3の所属組織１Ｔと、注目ユーザｕであるuser2の所属組織１Ｇと、が一致しないので、判定の結果、ステップＳ３０に進む。ステップＳ３０で、順次性チェックフラグの値はtrueであるので、ステップＳ３２に進む。注目文書ｒ"Doc4"は、要求対象のＩＤ付き文書"Doc4"と一致するので、ステップＳ３４に進む。ステップＳ３４で、注目ユーザｕであるuser2の所属組織１Ｇは、組織階層における最上位の組織ではない（図７及び図８参照）ので、ステップＳ３６に進み、注目ユーザｕであるuser2の所属組織１Ｇに対して一段階上位組織であるＸ部に所属するuser1が新たな注目ユーザｕとして設定される。その後、さらに、ステップＳ１４以降の処理を繰り返す。この繰り返し処理において、注目文書ｒ"Doc4"の操作者であるuser3の所属組織１Ｔと、注目ユーザｕであるuser1の所属組織Ｘ部から組織階層を遡った経路上に含まれる組織と、が一致することはないので、ステップＳ１４でＹｅｓに進むことはない。したがって、ステップＳ１４，Ｓ３０〜Ｓ３６の処理ループが繰り返されて、組織階層において注目ユーザｕの所属組織を遡っていき、組織階層における最上位組織に所属する者が注目ユーザｕとして設定された後、ステップＳ３４の判定が行われると、処理はステップＳ３８に進み、順次性チェックフラグの値がfalseに設定される。この間、注目文書ｒは、要求対象のＩＤ付き文書"Doc4"に設定されたまま変更されない。
【０１２８】
ステップＳ３８の後、ステップＳ２１に進み、注目文書ｒ"Doc4"は根ノードでないのでステップＳ２８に進み、ステップＳ１２以降の処理が繰り返される。そして、派生関係の木構造の根ノードである"Doc1"が注目文書ｒとして設定された後、ステップＳ２１の判定が行われると、ステップＳ２２において、順次性チェックフラグの値の判定が行われる。順次性チェックフラグの値は、上述のようにfalseに設定されているので、ステップＳ２２の判定の結果、ステップＳ２６のエラー処理に進み、user7によるＩＤ付き文書"Doc4"に対するアクセスは許可されない。
【０１２９】
＜具体例７＞
要求者と同じ組織に所属する他のユーザが更新登録した文書に対するアクセス要求があった場合のアクセス制御について説明する。上述の（条件１）及び（条件２）を考慮すると、役職者でない者が更新登録した文書については、要求者が更新登録した文書から派生した文書でない限りアクセス許可されない。例えば、組織１Ｔに所属するuser6が、同じ組織１Ｔに所属するuser5によって更新登録されたＩＤ付き文書"Doc7"の提供を要求した場合について説明する。
【０１３０】
図１０のステップＳ１０で、注目ユーザｕはuser6、注目文書ｒは"Doc7"に設定される。次に、ステップＳ１２で、注目文書ｒ"Doc7"の操作者はuser5であり、注目ユーザｕであるuser6と一致しないので、ステップＳ１４に進む。ステップＳ１４で、組織情報ＤＢ１２０（図９）を参照すると、注目文書ｒ"Doc7"の操作者であるuser5の所属組織１Ｔと、注目ユーザｕであるuser6の所属組織１Ｔと、が一致するので、処理はステップＳ１６に進み、注目文書ｒ"Doc7"の操作者user5は役職者ではないので、処理は、図１１のステップＳ４０に進む。図１１に例示する手順の処理では、注目文書ｒ"Doc7"を起点に、図６に示す派生関係の木構造を根ノードまで遡った経路に含まれる「更新」操作ノード（"Doc7"，"Doc4"，"Doc3"，"Doc1"）の中に、その操作者が要求者であるuser6と一致するノードが存在しないので、ステップＳ４８のエラー処理が行われ、文書に対するアクセスは許可されない。
【０１３１】
＜具体例８＞
最後の具体例として、複数の組織に所属するユーザが更新登録したＩＤ付き文書に関するアクセス制御について説明する。例えば、ＩＤ付き文書"Doc12"は、組織２Ｔの役職者であるuser4によって更新登録されたＩＤ付き文書"Doc5"に対して、組織１Ｔ及び２Ｔの業務を兼任するuser8が更新を行った結果の文書である。つまり、ＩＤ付き文書"Doc12"は、user8が、自己の一方の所属組織２Ｔにおける業務として更新登録を行った文書である。このＩＤ付き文書"Doc12"に対して、user8の他方の所属組織１Ｔの役職者であるuser3がアクセス要求を行った場合のアクセス制御部１４２の処理について説明する。
【０１３２】
まず、図１０のステップＳ１０において、注目ユーザｕはuser3、注目文書ｒは"Doc12"に設定される。次に、ステップＳ１２の判定では、注目文書ｒ"Doc12"の操作者はuser8で、要求者であるuser3と一致しないので、ステップＳ１４に進む。次に、注目文書ｒ"Doc12"の操作者であるuser8の所属組織１Ｔ，２Ｔの一方と、注目ユーザｕであるuser3の所属組織１Ｔと、が一致し（ステップＳ１４でＹｅｓ判定）、注目文書ｒ"Doc12"の操作者であるuser8は、役職者ではない（図９参照）ので、処理は図１１のステップＳ４０に進む。ここで、図６に示す派生関係を参照すると、要求対象のＩＤ付き文書"Doc12"は、要求者であるuser3が更新登録したＩＤ付き文書から派生した文書ではないので、図１１に例示する手順の処理を実行すると、ステップＳ４８のエラー処理が行われ、user3のＩＤ付き文書"Doc12"に対するアクセスは許可されない。
【０１３３】
また、例えば、user8が組織２Ｔにおいて役職者であった場合、図１１に例示する処理が行われることはなく、ステップＳ１６でＹｅｓ判定されてステップＳ１７以降の処理が行われるが、要求者user3の所属組織１Ｔを起点に組織階層を遡った経路上に含まれる組織（１Ｔ，１Ｇ，Ｘ部，…，全社）の中に、要求対象の文書であるＩＤ付き文書"Doc12"の操作者user8の所属組織２Ｔが含まれない。したがって、上述の＜具体例６＞の場合と同様、ステップＳ３０〜Ｓ３６を含む処理ループが繰り返された結果、ステップＳ３８において順次性チェックフラグの値がfalseに設定されるため、アクセス許可されない。
【０１３４】
以上より、user3は、user8に対して組織１Ｔにおいて上司に該当する者であるが、組織１Ｔと異なる組織２Ｔの業務に関してuser8が更新登録した文書についてはアクセス許可されない。
【０１３５】
以上、図１０，図１１及び＜具体例１＞−＜具体例８＞を参照して説明した処理の例において、文書の派生関係において、注目文書ｒとなり得るのは、操作種別の値が「登録」又は「更新」である文書だけである。したがって、クライアント端末２０は、ＩＤ付き文書が新たに作成された場合（初期登録）、又は、ＩＤ付き文書に対して「更新」操作（ＩＤ付き文書の文書内容に変更が生じるような操作）が行われた場合に、新たなＩＤ付き文書を生成して文書管理サーバ１０に登録し、「閲覧」操作又は「取得」操作など「更新」操作以外の操作（ＩＤ付き文書の文書内容に変更が生じない操作）が行われた場合は、新たなＩＤ付き文書の生成及び文書管理サーバ１０への登録を行わない構成としてもよい。この場合、派生関係ＤＢ１１０に登録されるレコードは、操作種別の値が「登録」又は「更新」であるレコードのみとなる。例えば、図５に示す表で表される時系列で文書に対して操作が行われた場合に、クライアント端末２０が「登録」操作又は「更新」操作のみについてＩＤ付き文書の生成及び登録を行う場合、図５に示す表から、管理ＩＤ"Doc2"のレコード（操作種別「閲覧」）、及び管理ＩＤ"Doc6"，"Doc8"のレコード（操作種別「取得」）を除いたレコードを含む表のデータ内容が派生関係ＤＢ１１０に登録される。そして、図５に示す表において、管理ＩＤ"Doc2"，"Doc6"，"Doc8"をそれぞれ親ＩＤとする操作種別「更新」のレコードである管理ＩＤ"Doc3"，"Doc7"，"Doc9"の親ＩＤの値としては、それぞれの「更新」操作において変更される前の文書内容を含むＩＤ付き文書の管理ＩＤの値が登録される。つまり、管理ＩＤ"Doc3"のレコードの親ＩＤは"Doc1"、管理ＩＤ"Doc7"及び"Doc9"のレコードの親ＩＤは"Doc4"となる。
【０１３６】
「登録」操作又は「更新」操作のみについてＩＤ付き文書の生成及び文書管理サーバ１０への登録が行われる場合、アクセス制御部１４２は、図１０及び図１１に例示する処理において、注目文書ｒから派生関係の木構造を遡って最初に発見した「更新」又は「登録」ノードの管理ＩＤ（Ｐ（ｒ））を取得する際（図１０のステップＳ１７，Ｓ２８及び図１１のステップＳ４２）、派生関係ＤＢ１１０内の注目文書ｒのレコードに登録された親ＩＤをＰ（ｒ）として取得すればよい。
【０１３７】
また、以上で説明した処理の例では、図１０のステップＳ２０又は図１１のステップＳ４０で、注目文書ｒが木構造の根ノードに該当するか否かの判定が行われる。他の処理の例では、このノードに到達したらそれ以上は木構造を遡らない、とするノードを予め設定しておき、図１０のステップＳ２０及び図１１のステップＳ４０の判定において、注目文書ｒが上述のように木構造を遡る終点として設定されたノードであるか否かを判定してもよい。この場合、例えば、派生関係ＤＢ１１０において、終点として設定されたノードの管理ＩＤに対応するレコードに、その旨を示す情報を登録しておけばよい。
【０１３８】
また、以上で説明した処理の例では、図１０のステップＳ３４で、注目ユーザｕの所属組織が組織階層において最上位に位置するか否かを判定する。他の処理の例では、この組織に到達したらそれ以上は組織階層を遡らない、とする組織を予め設定しておき、図１０のステップＳ４０の判定において、注目ユーザｕの所属組織が上述のように組織階層を遡る終点として設定された組織であるか否かを判定してもよい。この例の場合、ステップＳ３０，Ｓ３２，Ｓ３４，Ｓ３６を含む処理ループにおいて、要求者の所属組織から、終点として設定された組織まで組織階層を遡った経路上に含まれる組織のいずれかに、要求対象のＩＤ付き文書の操作者が所属するか否かを判定することになる。
【０１３９】
さらに他の処理の例として、ＩＤ付き文書のログ情報３１６の中に、当該ＩＤ付き文書３００が公開（共有）対象であるか否かを示す「公開」属性を組み込むこともできる。例えば公開対象とするＩＤ付き文書の「公開」属性値を「１」とし、公開対象としないＩＤ付き文書の「公開」属性値は「０」とし、文書管理サーバ１０の派生関係ＤＢ１１０の各管理ＩＤに対応するレコードに「公開」属性値を登録する。この「公開」属性値は、ユーザがクライアント端末２０においてＩＤ付き文書に対して操作を行う時に指定できるようにしておけばよい。「公開」属性値を用いる場合、アクセス制御部１４２は、例えば、図１０に例示する手順の処理を開始する前に、まず、派生関係ＤＢ１１０内の要求対象文書に対応するレコードに含まれる「公開」属性値を取得する。そして、取得した「公開」属性値が「１」であれば、図１０に例示する処理を開始してアクセスの可否を決定し、「公開」属性値が「０」であれば、図１０に例示する処理を行うことなく、当該文書を生成するための操作を行った操作者や管理者等の特権的なユーザ以外には、アクセスを許可しないようにすることができる。
【０１４０】
また、企業などの団体においては、人事異動などにより各組織の構成員及び役職者が変更されたり、企業組織改変などにより組織階層の構成が変更されたりする場合がある。このような組織の変動に対応するため、組織情報ＤＢ１２０に、組織において生じた変更についての情報を登録しておくことができる。例えば、各組織の構成員に変更があった場合、変更前及び変更後の構成員の情報（例えば、図９のようなデータ内容）を組織情報ＤＢ１２０に登録しておき、さらに、変更が行われた時刻を組織情報ＤＢ１２０に登録する。組織階層の構成が変更された場合は、変更前及び変更後の組織階層の構造を表す情報（例えば、図８のようなデータ内容）と、変更前及び変更後の組織構成それぞれにおける各組織の構成員の情報と、その変更が行われた時刻と、を組織情報ＤＢ１２０に登録しておく。そして、アクセス制御部１４２における処理では、処理対象のＩＤ付き文書の操作日時を派生関係ＤＢ１１０から取得し、取得した操作日時が、組織情報ＤＢ１２０に登録された変更時刻以前であれば、変更前の組織階層及び構成員の情報を用い、取得した操作日時が組織情報の変更時刻以後であれば、変更後の組織階層及び構成員の情報を用いるようにすればよい。組織階層又は構成員について複数回の変更が行われた場合、例えば、組織階層又は構成員の情報とその情報が有効であった期間とを対応づける情報を組織情報ＤＢ１２０に登録しておき、アクセス制御部１４２での処理において、処理対象のＩＤ付き文書の操作日時を含む期間に対応する組織階層又は構成員の情報を組織情報ＤＢ１２０から取得して用いるようにすればよい。
【０１４１】
以上に例示した例では、管理ＩＤの発行は各クライアント端末２０で行われていたが、この代わりに文書管理サーバ１０が管理ＩＤを発行してもよい。この場合、クライアント端末２０は、ＩＤ付き文書に対して操作を行った場合、操作前のＩＤ付き文書内の管理ＩＤを親ＩＤ３１４として含み、更にその操作についてのログ情報３１６と操作後の文書内容３２０とを含み、管理ＩＤ３１２は空欄の文書データを生成し、文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書データに対して新たな管理ＩＤを付与し、この管理ＩＤとその文書データとに含まれる情報を、文書ＤＢ１００及び派生関係ＤＢ１１０に登録する。また、文書管理サーバ１０は、付与した管理ＩＤを当該文書データにセットすることによりＩＤ付き文書を生成し、これをクライアント端末２０に返す。クライアント端末２０は、操作前のＩＤ付き文書を、受け取ったＩＤ付き文書に置き換える。このように、文書管理サーバ１０が管理ＩＤを付与する構成でも、上述の各例の処理は同様に実行できる。
【０１４２】
また以上の例では、管理ＩＤ３１２、親ＩＤ３１４、ログ情報３１６、及び文書内容３２０を含んだＩＤ付き文書３００がクライアント端末２０に保存されたが、この代わりに、クライアント端末２０は管理ＩＤしか持たず、その他の情報は文書管理サーバ１０に保存されるようにしてもよい。この場合、クライアント端末２０で文書を操作する場合、その文書に対応する管理ＩＤを文書管理サーバ１０に送り、文書管理サーバ１０からその文書を取得する。また、別の例として、クライアント端末２０が保持するＩＤ付き文書３００の中には管理ＩＤ３１２と文書内容３２０とが含まれ、親ＩＤ３１４及びログ情報３１６は含まれないようにしても良い。この場合、サーバがその管理ＩＤ３１２に対応づけて親ＩＤ３１４とログ情報３１６を持つようにすれば良い。
【０１４３】
ここで、文書管理サーバ１０が管理ＩＤを付与する場合は、その取得の操作に対応する管理ＩＤを文書管理サーバ１０が生成し、その管理ＩＤと文書とを対応づけてクライアント端末２０に提供するとともに、その取得操作についてのログ情報（操作時刻や操作者など）と、元の管理ＩＤ（すなわち親ＩＤ）と、付与した管理ＩＤとを派生関係ＤＢ１１０に記録する。クライアント端末２０は、文書管理サーバ１０に送信した管理ＩＤを、受け取った管理ＩＤに置き換えると共に、受け取った文書を開く。ユーザは、開かれた文書に対して閲覧や編集などの操作を行う。クライアント端末２０は、文書に対する操作が完了すると、操作後の文書を管理ＩＤ及び当該操作についてのログ情報と共に文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書に対して新たな管理ＩＤを付与して派生関係ＤＢ１１０に登録し、受け取った管理ＩＤを親ＩＤとして派生関係ＤＢ１１０に登録する。また、受け取ったログ情報及び操作後の文書を、派生関係ＤＢ１１０及び文書ＤＢ１００に登録する。そして、文書管理サーバ１０は、新たに付与した管理ＩＤをクライアント端末２０に返す。クライアント端末２０は、元の管理ＩＤを受け取った管理ＩＤで置き換える。以上のような処理により、操作間の派生関係が文書管理サーバ１０に蓄積されることになる。
【０１４４】
一方、クライアント端末２０が管理ＩＤを付与する構成の場合は、文書管理サーバ１０は、クライアント端末２０から受け取った管理ＩＤに対応する文書をクライアントに返せばよい。クライアント端末２０は受け取った文書を開き、ユーザがその文書を操作する。操作の完了後、クライアント端末２０はその操作結果の文書に対して新たな管理ＩＤを付与し、この管理ＩＤを含んだ前述のＩＤ付き文書と同様の情報を、文書管理サーバ１０に送る。そして、クライアント端末２０は、そのＩＤ付き文書のうち管理ＩＤのみを保存し、その他の情報を削除する。
【０１４５】
以上に例示したシステムにおける文書管理サーバ１０は、典型的には、汎用のコンピュータにて上述の文書管理サーバの各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図１２に示すように、ＣＰＵ（中央演算装置）４０、メモリ（一次記憶）４２、各種Ｉ／Ｏ（入出力）インタフェース４４等がバス４６を介して接続された回路構成を有する。また、そのバス４６に対し、例えばＩ／Ｏインタフェース４４経由で、ハードディスクドライブ（ＨＤＤ）４８やＣＤやＤＶＤ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ５０が接続される。このようなドライブ４８又は５０は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク経由で、ハードディスクドライブ４８等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されＣＰＵにより実行されることにより、実施形態の処理が実現される。クライアント端末２０についても同様である。
【図面の簡単な説明】
【０１４６】
【図１】文書管理システムの概略構成の例を示すブロック図である。
【図２】クライアント端末の内部構成の例を示すブロック図である。
【図３】ＩＤ付き文書のデータ構造の例を模式的に示す図である。
【図４】文書管理サーバの内部構成の例を示すブロック図である。
【図５】派生関係ＤＢのデータ内容の例を示す図である。
【図６】図５に例示したデータ内容における管理ＩＤ群がなす木構造を図式化して表す図である。
【図７】複数の組織からなる組織階層の構造の例を示す図である。
【図８】組織情報ＤＢのデータ内容の例を示す図である。
【図９】組織情報ＤＢのデータ内容の例を示す図である。
【図１０】ＩＤ付き文書に対するアクセスが要求された場合の文書管理サーバの処理手順の一部の例を示すフローチャートである。
【図１１】ＩＤ付き文書に対するアクセスが要求された場合の文書管理サーバの処理手順の一部の例を示すフローチャートである。
【図１２】コンピュータのハードウエア構成の一例を示す図である。
【符号の説明】
【０１４７】
１０ 文書管理サーバ、２０ クライアント端末、３０ ネットワーク、４０ ＣＰＵ、４２ メモリ、４４ Ｉ／Ｏインタフェース、４６ バス、４８ ハードディスクドライブ（ＨＤＤ）、５０ ディスクドライブ、１００ 文書ＤＢ、１１０ 派生関係ＤＢ、１２０ 組織情報ＤＢ、１３０ 文書登録部、１３２ 派生関係登録部、１４０ 要求処理部、１４２ アクセス制御部、２００ 文書操作部、２０２ ＩＤ割り当て部、２０４ 派生関係組込部、２１０ 登録処理部、３００ ＩＤ付き文書。
【特許請求の範囲】
【請求項１】
第１の文書を親とし当該第１の文書に対する操作の結果生成された第２の文書を子とする派生関係を記憶する文書情報記憶部であって、当該第１の文書に対する操作を行った操作者を示す情報を当該第２の文書と対応づけて記憶する文書情報記憶部と、
複数の組織からなる組織階層の構造を表す情報と、前記組織のそれぞれに所属する構成員を示す情報と、を記憶する組織情報記憶部と、
要求対象文書と、要求者と、を特定する文書出力要求を受けた場合に、前記要求対象文書に対応づけられた操作者を示す情報又は前記文書情報記憶部に記憶された前記派生関係群が表す木構造において前記要求対象文書の先祖に該当する文書に対応づけられた操作者を示す情報と、前記組織情報記憶部に記憶された情報のうち、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織に所属する構成員を示す情報と、を照合することで、前記要求者に対する前記要求対象文書の出力の可否を決定する文書出力可否決定部と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記文書出力可否決定部は、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織が、前記要求対象文書に対応づけられた操作者を前記構成員として含むか否かを判定し、当該判定の結果に基づいて、前記要求対象文書の出力の可否を決定することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記文書出力可否決定部は、前記要求対象の文書が前記組織階層において上位から下位の展開経路を経ずに更新登録された文書である場合には、前記要求対象の文書の出力を許可しないことを特徴とする請求項２の記載の情報処理装置。
【請求項４】
前記文書出力可否決定部は、前記要求対象文書を起点として前記木構造を遡った経路上に含まれる文書のうち少なくとも１つの文書に対応づけられた操作者が前記要求者である場合に、前記要求対象文書の出力を許可することを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
【請求項５】
前記組織情報記憶部は、さらに、前記組織のそれぞれに所属する構成員のうちの役職者を示す情報を記憶し、
前記文書出力可否決定部は、前記要求対象文書に対応づけられた操作者が、前記構成員として当該操作者を含む組織の役職者でない場合であって、前記要求対象文書を起点として前記木構造を遡った経路上に含まれる文書のいずれに対応づけられた操作者も前記要求者でない場合は、前記要求対象文書の出力を許可しないことを特徴とする請求項１から４のいずれか１項に記載の情報処理装置。
【請求項６】
第１の文書を親とし当該第１の文書に対する操作の結果生成された第２の文書を子とする派生関係を文書情報記憶部に記憶するステップであって、当該第１の文書に対する操作を行った操作者を示す情報を当該第２の文書と対応づけて文書情報記憶部に記憶するステップと、
複数の組織からなる組織階層の構造を表す情報と、前記組織のそれぞれに所属する構成員を示す情報と、を組織情報記憶部に記憶するステップと、
要求対象文書と、要求者と、を特定する文書出力要求を受けた場合に、前記要求対象文書に対応づけられた操作者を示す情報又は前記文書情報記憶部に記憶された前記派生関係群が表す木構造において前記要求対象文書の先祖に該当する文書に対応づけられた操作者を示す情報と、前記組織情報記憶部に記憶された情報のうち、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織に所属する構成員を示す情報と、を照合することで、前記要求者に対する前記要求対象文書の出力の可否を決定するステップと、
をコンピュータに実行させることを特徴とするプログラム。
【請求項７】
第１の情報処理装置と第２の情報処理装置とを備え、
前記第１の情報処理装置は、
要求対象文書と、要求者と、を特定する文書出力要求を前記第２の情報処理装置に対して行う文書出力要求部を備え、
前記第２の情報処理装置は、
第１の文書を親とし当該第１の文書に対する操作の結果生成された第２の文書を子とする派生関係を記憶する文書情報記憶部であって、当該第１の文書に対する操作を行った操作者を示す情報を当該第２の文書と対応づけて記憶する文書情報記憶部と、
複数の組織からなる組織階層の構造を表す情報と、前記組織のそれぞれに所属する構成員を示す情報と、を記憶する組織情報記憶部と、
前記第１の情報処理装置から前記文書出力要求を受けた場合に、前記要求対象文書に対応づけられた操作者を示す情報又は前記文書情報記憶部に記憶された前記派生関係群が表す木構造において前記要求対象文書の先祖に該当する文書に対応づけられた操作者を示す情報と、前記組織情報記憶部に記憶された情報のうち、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織に所属する構成員を示す情報と、を照合することで、前記要求者に対する前記要求対象文書の出力の可否を決定する文書出力可否決定部と、
を備えることを特徴とする情報処理システム。
【請求項１】
第１の文書を親とし当該第１の文書に対する操作の結果生成された第２の文書を子とする派生関係を記憶する文書情報記憶部であって、当該第１の文書に対する操作を行った操作者を示す情報を当該第２の文書と対応づけて記憶する文書情報記憶部と、
複数の組織からなる組織階層の構造を表す情報と、前記組織のそれぞれに所属する構成員を示す情報と、を記憶する組織情報記憶部と、
要求対象文書と、要求者と、を特定する文書出力要求を受けた場合に、前記要求対象文書に対応づけられた操作者を示す情報又は前記文書情報記憶部に記憶された前記派生関係群が表す木構造において前記要求対象文書の先祖に該当する文書に対応づけられた操作者を示す情報と、前記組織情報記憶部に記憶された情報のうち、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織に所属する構成員を示す情報と、を照合することで、前記要求者に対する前記要求対象文書の出力の可否を決定する文書出力可否決定部と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記文書出力可否決定部は、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織が、前記要求対象文書に対応づけられた操作者を前記構成員として含むか否かを判定し、当該判定の結果に基づいて、前記要求対象文書の出力の可否を決定することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記文書出力可否決定部は、前記要求対象の文書が前記組織階層において上位から下位の展開経路を経ずに更新登録された文書である場合には、前記要求対象の文書の出力を許可しないことを特徴とする請求項２の記載の情報処理装置。
【請求項４】
前記文書出力可否決定部は、前記要求対象文書を起点として前記木構造を遡った経路上に含まれる文書のうち少なくとも１つの文書に対応づけられた操作者が前記要求者である場合に、前記要求対象文書の出力を許可することを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
【請求項５】
前記組織情報記憶部は、さらに、前記組織のそれぞれに所属する構成員のうちの役職者を示す情報を記憶し、
前記文書出力可否決定部は、前記要求対象文書に対応づけられた操作者が、前記構成員として当該操作者を含む組織の役職者でない場合であって、前記要求対象文書を起点として前記木構造を遡った経路上に含まれる文書のいずれに対応づけられた操作者も前記要求者でない場合は、前記要求対象文書の出力を許可しないことを特徴とする請求項１から４のいずれか１項に記載の情報処理装置。
【請求項６】
第１の文書を親とし当該第１の文書に対する操作の結果生成された第２の文書を子とする派生関係を文書情報記憶部に記憶するステップであって、当該第１の文書に対する操作を行った操作者を示す情報を当該第２の文書と対応づけて文書情報記憶部に記憶するステップと、
複数の組織からなる組織階層の構造を表す情報と、前記組織のそれぞれに所属する構成員を示す情報と、を組織情報記憶部に記憶するステップと、
要求対象文書と、要求者と、を特定する文書出力要求を受けた場合に、前記要求対象文書に対応づけられた操作者を示す情報又は前記文書情報記憶部に記憶された前記派生関係群が表す木構造において前記要求対象文書の先祖に該当する文書に対応づけられた操作者を示す情報と、前記組織情報記憶部に記憶された情報のうち、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織に所属する構成員を示す情報と、を照合することで、前記要求者に対する前記要求対象文書の出力の可否を決定するステップと、
をコンピュータに実行させることを特徴とするプログラム。
【請求項７】
第１の情報処理装置と第２の情報処理装置とを備え、
前記第１の情報処理装置は、
要求対象文書と、要求者と、を特定する文書出力要求を前記第２の情報処理装置に対して行う文書出力要求部を備え、
前記第２の情報処理装置は、
第１の文書を親とし当該第１の文書に対する操作の結果生成された第２の文書を子とする派生関係を記憶する文書情報記憶部であって、当該第１の文書に対する操作を行った操作者を示す情報を当該第２の文書と対応づけて記憶する文書情報記憶部と、
複数の組織からなる組織階層の構造を表す情報と、前記組織のそれぞれに所属する構成員を示す情報と、を記憶する組織情報記憶部と、
前記第１の情報処理装置から前記文書出力要求を受けた場合に、前記要求対象文書に対応づけられた操作者を示す情報又は前記文書情報記憶部に記憶された前記派生関係群が表す木構造において前記要求対象文書の先祖に該当する文書に対応づけられた操作者を示す情報と、前記組織情報記憶部に記憶された情報のうち、前記構成員として前記要求者を含む組織又は当該組織に対して前記組織階層において上位に位置する組織に所属する構成員を示す情報と、を照合することで、前記要求者に対する前記要求対象文書の出力の可否を決定する文書出力可否決定部と、
を備えることを特徴とする情報処理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００９−８７２３０（Ｐ２００９−８７２３０Ａ）
【公開日】平成２１年４月２３日（２００９．４．２３）
【国際特許分類】
【出願番号】特願２００７−２５８８５８（Ｐ２００７−２５８８５８）
【出願日】平成１９年１０月２日（２００７．１０．２）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
【公開日】平成２１年４月２３日（２００９．４．２３）
【国際特許分類】
【出願日】平成１９年１０月２日（２００７．１０．２）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
[ Back to top ]