JP4110154B2 - 情報処理装置、情報処理装置の制御方法、コンピュータプログラム、記憶媒体 - Google Patents

Description

本発明は文書情報を管理する技術に関する。

近年、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等のマークアップ言語の普及等に伴い、文書データの形態が多様化している。従来の文書データは、１文書を１ファイルで構成する形態が主流であった。しかしながら、近年においては、例えば、
（１）１文書を複数ファイルで構成する形態（ＸＭＬ，ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等）
（２）複数文書を１ファイルで構成する形態（ＸＭＬ，アーカイブファイル等）
のような、多様な形態で文書データが構成されている。

従来より、１つのファイルを１つの文書として管理する文書管理システムが知られている。このような文書管理システムでは、（１）のような形態の文書データについては、複数ファイルのそれぞれを別文書として格納・管理し、（２）のような形態の文書データについては、複数文書が含まれる１つのファイルをそのまま一つの文書として格納・管理する。但し、文書の管理とは、主に、アクセス権制御や属性付与、分類整理等を含むものとし、以下、特に断らない限り同様とする。

また、例えば、ＨＴＭＬ文書のように、本体のファイル（例えば、ＨＴＭＬファイル等）に付属ファイル（例えば、画像ファイル等）が関連づけられているような文書について、本体のファイルに対して何らかの処理の指示（例えば、移動、コピー、削除等）がなされた場合、自動的に付属ファイルについても同様の処理を行うように制御する文書管理システムが知られている。このような文書管理システムは、ユーザが、本体ファイルと付属ファイルとをまとめて１つの文書として管理することを容易にしている。

また、（２）のような形態の文書データのような、複数のエンティティ（文書の最小単位）を含む構造化文書を格納する場合、ファイルをエンティティ毎に分割して実データを格納し、分割したデータを文書として管理する文書管理システムも知られている（特許文献１）。

上記のような従来の文書管理システムにおいては、（１）のように１文書を複数ファイルで構成する形態の文書データと、（２）のように複数文書を１ファイルで構成する形態の文書データとの、いずれについても同一の管理単位、即ち、ファイル、又は、文書のどちらか一方を単位として画一的に管理がなされていた。
特開２００１−１６７０８６号公報

１つのファイルを１つの文書として管理するシステムにおいては、複数のファイルで１つの文書を構成するような文書データを管理するのに手間がかかっていた。

また、本体ファイルと付属ファイルとをまとめて１つの文書として管理可能とした文書管理システムにおいては、例えば、ＨＴＭＬ文書のように、拡張子等から予め定義された特定のフォーマットの文書については、複数ファイルを１文書として扱うことができるが、特定のフォーマットに即していない文書については、１文書として扱うことができなかった。

また、特許文献１に開示されたシステムのように、複数のエンティティを含む構造化文書を格納する場合、ファイルをエンティティ毎に分割して実データを格納し、分割したデータを文書として管理する文書管理システムにおいては、元の構造化文書ファイルが持っていた単一ファイルとしての属性を利用することができなかった。例えば、改竄検知を行うために、ファイル自体のバイナリ情報からハッシュ値を導出し、そのハッシュ値に対して署名を行うことで、改竄検知を行うシステムがあるが、この場合、元のファイルを分割してから格納してしまうと実ファイルそのもののバイナリ特性がくずれてしまい、文書管理システムに格納するだけで改竄されたことになってしまい、両システムの連携に不具合が生じていた。

また、従来の文書管理システムにおいては、内部的な構造が（１）と（２）の構造を複合しているような文書を容易に管理することができなかった。このことを図５を参照して説明する。図５は、複合的な構造を有する文書の一例を模式的に示した図である。

５０１はＢａｓｅ．ｘｍｌをメインファイル（本体のファイル）とする構造化ファイル群であり、５０２、５０３はそれぞれＢａｓｅ．ｘｍｌ、Ｓｐｅｃ．ｘｍｌのデータ内容を表している。

図５において、Ｓｐｅｃ．ｘｍｌやＤｅｔａｉｌ．ｘｍｌはＢａｓｅ．ｘｍｌのサブファイル（付属ファイル）であり、このことは、Ｂａｓｅ．ｘｍｌのデータ内容５０２においてＳｐｅｃ．ｘｍｌ、Ｄｅｔａｉｌ．ｘｍｌへの参照タグ５０６、５０７によって記述されている。このファイルの参照関係は、例えば、閲覧ソフトウェアを用いてＢａｓｅ．ｘｍｌを閲覧するときに、閲覧ソフトウェアが自動的にＳｐｅｃ．ｘｍｌやＤｅｔａｉｌ．ｘｍｌを自動的にロード・マージした上で一つの文書として表示することによって可視化される。これは、例えば、インターネット閲覧ソフトウェア（ウェブブラウザなど）が、ＨＴＭＬ文書について、画像ファイルを自動的に読み込んで画像を構成し、表示する仕組みと同様である。

Ｃｏｎｃｅｐｔ．ｘｍｌやＲｅｐｏｒｔ．ｘｍｌやその他ｊｐｅｇファイルに関してもそれぞれ、上位のファイルのサブファイルである。

このような文書について、ユーザとしては、Ｂａｓｅ．ｘｍｌは個々の＜Ｎｅｗｓ＞〜＜／Ｎｅｗｓ＞エンティティ５０８、５０９、５１０毎に文書として管理したく、また、Ｓｐｅｃ．ｘｍｌについてはサブファイルである、Ｃｏｎｃｅｐｔ．ｘｍｌ、Ｐａｃｋａｇｅ．ｊｐｇ、Ｍａｐ．ｊｐｇを含めた４ファイルで一つの文書として管理したい状況を考える。

しかし、このような構成のデータを上記従来の文書管理システム５０４へ取り込むと、一つのファイルが一つの文書として取り込まれるため、５０５のようにファイル別に別文書として登録されてしまう。また、従来の文書管理システムでは、一度システムへ５０５のような単位で格納すると、システム内で格納場所やステータスを変更させただけでは文書の管理単位は変更されない。

また、複数ユーザで構成されるチーム内で作成した文書を共有することを目的として、作成した文書を一時的に格納する文書作成領域と、作成した文書を公開して共有するための文書公開領域とを区別して備えた構成が考えられている。このような構成では、文書を作成する段階では個々の情報の機密性を高める必要もあり、各エンティティ（たとえば、章や節）ごとにアクセス権を設定したいという要求が存在する。しかし、文書を公開した場合には、各エンティティがばらばらで公開されたのでは統一した成果物として管理しづらい。このため、文書を「公開」した場合には、それらのエンティティをまとめて一文書として公開したいという要求も存在する。しかし、従来の文書管理システムでは、このような文書の格納場所やステータスの変更に伴って管理単位を変更することができないため、上記要求を満たすことができない。

本発明は上記問題に鑑みなされたものであり、多様な形態を持つ文書データを統一的に管理することが可能な文書管理の技術を提供することを目的とする。

上記目的を達成するため、本発明による情報処理装置は以下の構成を備える。即ち、
複数のスキーマと、各スキーマに対して予め設定された、文書ファイルの管理単位を示す管理単位情報とを保持するスキーマ保持手段と、
文書ファイルに対する操作を示す指示内容を受け取る文書操作制御手段と、
前記文書操作制御手段が受け取った指示内容に基づいて操作対象の文書ファイルを特定し、前記スキーマ保持手段に保持された複数のスキーマの中から、当該特定した操作対象の文書ファイルに適合するスキーマを判定するスキーマ解析手段と、
前記スキーマ解析手段で適合すると判定されたスキーマに対して予め設定されている管理単位情報を前記スキーマ保持手段から取得することによって、前記操作対象の文書ファイルの管理単位を、１ファイル１文書として扱うべきか、１ファイル複数文書として扱うべきか、複数ファイル１文書として扱うべきかを特定する管理単位特定手段と、
前記管理単位特定手段が特定した管理単位に基づいて、前記文書ファイルを前記特定された管理単位として扱うための文書管理データを作成または更新する管理単位更新手段と、
前記文書管理データを保持する保持手段と、
前記文書ファイルを扱う際に、前記保持手段に保持された前記文書管理データに基づいて、１ファイル１文書として扱うべきか、１ファイル複数文書として扱うべきか、複数ファイル１文書として扱うべきかを管理する制御手段と、を備える。

本発明によれば、多様な形態を持つ文書データを統一的に管理することが可能な文書管理の技術を提供することができる。

以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。

＜＜第１実施形態＞＞
（情報処理装置のハードウェア構成）
まず、本実施形態に対応する情報処理装置のハードウェア構成について、図９を参照して説明する。図９は、本実施形態に対応する情報処理装置のハードウェア構成を模式的に示したブロック図である。尚、本実施形態に対応する情報処理装置は、例えば、パーソナルコンピュータ（ＰＣ）やワークステーション（ＷＳ）、携帯情報端末（ＰＤＡ）等で実現される。

図９において、９００はＣＰＵであり、後述するハードディスク装置（以下、ＨＤと呼ぶ）９０５に格納されているアプリケーションプログラム、オペレーティングシステム（ＯＳ）や制御プログラム等を実行し、ＲＡＭ９０２にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。

９０１はＲＯＭであり、内部には基本Ｉ／Ｏプログラム等のプログラム、文書処理の際に使用するフォントデータ、テンプレート用データ等の各種データを記憶する。９０２は各種データを一時記憶するためのＲＡＭであり、ＣＰＵ９００の主メモリ、ワークエリア等として機能する。

９０３は記録媒体へのアクセスを実現するための外部記憶ドライブであり、メディア（記録媒体）９０４に記憶されたプログラム等を本コンピュータシステムにロードすることができる。尚、メディア９０４は、例えば、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＰＣカード、ＤＶＤ、ＩＣメモリカード、ＭＯ、メモリスティック等、任意である。

９０５は外部記憶装置であり、本実施形態では大容量メモリとして機能するＨＤを用いている。ＨＤ９０５には、アプリケーションプログラム、ＯＳ、制御プログラム、関連プログラム等が格納される。

９０６は指示入力装置であり、キーボードやポインティングデバイス（マウス等）、タッチパネル等がこれに相当する。指示入力装置９０６を用いて、ユーザは、本実施形態に対応する情報処理装置に対して、装置を制御するコマンド等を入力指示する。

９０７はディスプレイであり、指示入力装置９０６から入力したコマンドや、それに対する情報処理装置の応答出力等を表示したりするものである。

９０９はシステムバスであり、情報処理装置内のデータの流れを司るものである。９０８はインターフェイス（以下、Ｉ／Ｆという）であり、このＩ／Ｆ９０８を介して外部装置とのデータのやり取りを行う。

尚、以上の各装置と同等の機能を実現するソフトウェアにより、ハードウェア装置の代替として構成することもできる。

本実施形態では、メディア９０４から本実施形態に係るプログラム及び関連データを直接ＲＡＭ９０２にロードして実行させる例を示すが、これ以外にも、本実施形態に係るプログラムを動作させる度に、既にプログラムがインストールされているＨＤ９０５からＲＡＭ９０２にロードするようにしてもよい。また、本実施形態に係るプログラムをＲＯＭ９０１に記録しておき、これをメモリマップの一部をなすように構成し、直接ＣＰＵ９００で実行することも可能である。

また、本実施形態では、説明の便宜のため、本実施形態に係る情報処理装置を１つの装置で実現した構成について述べるが、複数の装置にリソースを分散した構成によって実現してもよい。例えば、記憶や演算のリソースを複数の装置に分散した形に構成してもよい。或いは、情報処理装置上で仮想的に実現される構成要素毎にリソースを分散し、並列処理を行うようにしてもよい。

（情報処理装置の機能構成）
次に、上記の情報処理装置による文書管理のための機能構成について、図１を参照して説明する。図１は、本実施形態に係る情報処理装置の機能構成を示したブロック図である。

図１に示される各機能ブロックは、図９を参照して上述した情報処理装置のＣＰＵ９００がＲＡＭ９０２にロードされたプログラムを実行し、図９に示される各ハードウェアと協働することによって実現される。もちろん機能ブロックの一部或いは全てが専用のハードウェアで実現されてもよい。

図１において、１０１は文書管理システム上の文書操作を制御する文書操作制御部であり、文書データについての、ユーザによる指示入力装置９０６を介した操作の指示や、外部装置からのネットワークを介した操作の指示を受け取る。ここで、入力される指示には、文書ファイルを識別する識別情報と、この文書ファイルについての指示内容を記述した内容情報が含まれる。文書操作制御部１０１は文書データについての操作の指示を受け取ると、指示を受け取った旨の情報を後述の文書操作イベント発行部１０２に通知する。また、文書管理データ（文書についての管理データ）が格納された後述の文書管理データ保管部１０８、文書のファイルデータが格納された後述の実データ保管部１０９に対して、指示された操作に基づいた所定の処理を行う。

１０２は、文書操作イベント発行部であり、文書操作制御部１０１から指示を受け取った旨の情報を受け取ると、イベントを発行する。１０３は文書操作イベント検知部であり、文書操作イベント発行部１０２によりイベントが発行されると、それを検知し、適切な処理を呼び出す。

１０４はスキーマ解析部であり、操作対象のファイルを特定し、特定したファイルと、後述のスキーマ・設定保管部１０５に登録されているスキーマとを比較し、そのファイルのスキーママッチングを行う。即ち、スキーマ解析部１０４は、登録されたスキーマのいずれかに規定されたフォーマットに操作対象のファイルが即している（スキーマがマッチしている）か否かを判別する。ただし、スキーマとは、文書のとりうる構造（フォーマット）を記述したデータである。例えば、ＸＭＬ文書のスキーマを記述する言語としては、ＸＭＬ Ｓｃｈｅｍａ、ＤＴＤ（Ｄｏｃｕｍｅｎｔ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏｎ）、ＲＥＬＡＸ（ＲＥｇｕｌａｒ ＬＡｎｇｕａｇｅ ｄｅｓｃｒｉｐｔｉｏｎ ｆｏｒ ＸＭＬ）、ＸＭＬ Ｄａｔａ Ｒｅｄｕｃｅｄ等がある。

１０５はスキーマ・設定保管部（以下、スキーマ保管部と呼ぶ）であり、格納されるべきファイルのフォーマットに対応するスキーマと、そのスキーマに対応する管理単位についての管理情報とを設定・保管（定義）する。図１０は、スキーマ保管部１０５におけるデータの構造を模式的に示した図である。図１０において、１００１は、登録されたスキーマを記述したスキーマファイル、１００２は、スキーマファイルに対応した管理単位情報を記述した管理単位情報ファイルである。図１０のように、スキーマファイルと、管理単位情報ファイルとは１対１に対応しており、スキーマファイルの記述に即した文書に対しては、対応する管理単位情報ファイルの内容に基づいて管理するように制御する。尚、スキーマファイルや管理単位情報ファイルは、例えば、ユーザや外部装置からの指示に基づいて予め作成・設定されているものとする。

１０６は管理単位特定部であり、スキーマ解析部１０４でマッチしたスキーマに対応する管理単位情報をスキーマ保管部１０５から読み込み、操作対象ファイルに対する管理単位を特定する。

１０７は管理単位変更部であり、特定された管理単位に基づいて後述の文書管理データ保管部１０８に保管された文書管理データを適宜追加・変更する。ただし、文書管理データには、文書ファイルと文書の管理単位との対応関係を記述した情報が含まれる。文書管理データの具体例については後述する。

１０８は指定された管理単位で文書管理データを保管する文書管理データ保管部である。１０９は文書管理データとは別にファイル単位で文書の実データを保管する実データ保管部である。図１１は、実データ保管部１０９におけるデータ構造を模式的に示した図である。図１１のように、実データ保管部１０９は、通常のファイルシステムと同様に文書データを構成するファイルを保管する。

尚、本実施形態においては、文書操作制御部１０１、文書操作イベント発行部１０２、イベント検知部１０３、スキーマ解析部１０４、管理単位特定部１０６、管理単位変更部１０７は、図９のハードウェア構成においては、オブジェクトとして、即ち、アプリケーションプログラムに基づいて動作するＣＰＵ９００や、ＲＡＭ９０２上に展開されたデータ等によって、仮想的に実現されるものとする。また、スキーマ保管部１０５、文書管理データ保管部１０８、実データ保管部１０９は、ＲＡＭ９０２やＨＤ９０５等の記憶装置によって実現されるものとする。

（文書管理処理）
次に、本実施形態に係る情報処理装置が実行する文書管理処理について、図２を参照して説明する。図２は、文書管理処理の処理の流れを示したフローチャートである。尚、図２の処理は、本実施形態に係る情報処理装置のＣＰＵ９００の制御に基づいて、図１のスキーマ解析部１０４、スキーマ保管部１０５、管理単位特定部１０６、管理単位変更部１０７等のオブジェクト間通信等によって実現される。

図２の処理は、文書操作制御部１０１が、文書データについての、ユーザによる指示入力装置９０６を介した操作の指示や、外部装置からのネットワークを介した操作の指示を受け取り、文書操作イベント発行部１０２がイベントを発行して、文書操作イベント検知部１０３がイベントを検知したことを契機として実行される。本実施形態では、新たな文書ファイルを登録する旨の指示が入力された場合の処理について例示的に説明するが、後述するように、文書の削除や属性情報の変更等、他の処理の指示が入力された場合も図２のフローチャートに基づいて処理を実行する。

まず、ステップＳ２０１において入力された指示の内容を確認し、操作対象ファイルを特定する。即ち、受け取った識別情報と内容情報を解析し、文書ファイルを識別する識別情報から操作対象ファイルを特定し、文書ファイルについての指示内容を記述した内容情報から指示内容を確認する。

次に、ステップＳ２０２乃至Ｓ２０６の処理によって、操作対象ファイルに対応したスキーマ、即ち、操作対象ファイルのフォーマットを定義したスキーマを、スキーマ保管部１０５において検索する処理を行う。

ステップＳ２０２において、ステップＳ２０１の処理の後まだ参照していないスキーマ（を記述したスキーマファイル）が、スキーマ保管部１０５に保管されているか否かを判定する。保管されている場合（ステップＳ２０２でＹＥＳ）はステップＳ２０３へ進み、保管されていない場合（ステップＳ２０２でＮＯ）はステップＳ２０９へ進む。

ステップＳ２０３においては、保管されている未参照のスキーマファイル（スキーマデータ）をロードする。

次に、ステップＳ２０４において、ステップＳ２０４では対象ファイルが、ロードされたスキーマに適合（合致）しているか、即ち、ロードしたスキーマファイルの内容に対応しているか否かをチェックする（スキーマチェック）。適合している場合（ステップＳ２０５でＹＥＳ）はステップＳ２０７へ進み、適合していない場合はステップＳ２０６へ進む。

ステップＳ２０６においては、スキーマ保管部１０５に登録された次の未参照のスキーマファイルを参照するように、ＲＡＭ９０２等の記憶装置（メモリ）にフラグを設定し、ステップＳ２０２へ戻り、更に未参照のスキーマファイルを参照してスキーマチェックを行うようにする。

全てのスキーマファイルを参照して適合するものが存在しなかった場合（ステップＳ２０２でＮＯ）は、ステップＳ２０９へ進み、１ファイル１文書として対象文書を扱うようにするためのフラグを付与し、処理を終了する。

ステップＳ２０７では、適合したスキーマに対応する管理単位情報をスキーマ保管部１０５から取得する。この処理は、図１のような構成要素によって実現した場合は、管理単位特定部１０６が実行する。

説明の簡略化のため、本実施形態においては、管理単位情報は、次の３つのタイプのいずれかを示しているものとする。
Ａ． １ファイル１文書
Ｂ． １ファイル複数文書
Ｃ． 複数ファイル１文書
Ａの場合には、ステップＳ２０９において、通常の１ファイル１文書として対象文書を扱うようにメモリ上でフラグを立てて図２の処理を終了する。

Ｂの場合には、ステップＳ２１０へと進み、１ファイル複数文書フラグをメモリ上にセットした後、ステップＳ２１１において、ファイル内において文書として扱われるべきエンティティを特定するための指定子を作成する。この指定子は、例えば、ＸＭＬファイル内の要素を特定するＸＰａｔｈ式等によって記述する。

Ｃの場合には、ステップＳ２１２へと進み、対象ファイルに対してメモリ上に複数ファイル１文書扱いとするフラグをセットした後、ステップＳ２１３で操作対象ファイルをパースしてサブファイルを特定する。サブファイルが特定されると、ステップＳ２１４において、このサブファイルそれぞれに対して図２の処理を再帰的に実行し、サブファイルそれぞれの管理単位を決定する。

上記の処理を行った後、図１の管理単位変更部１０７にて実際の管理単位を変更する処理を実行し、文書管理データ保管部１０８の文書管理データを書き換える。

図３は、文書管理データ保管部１０８の文書管理データ（テーブルデータ）の一例を示した図である。３０１は、このシステムを利用するグループのＩＤ Ｔｅａｍ＿ＡとＴｅａｍ＿Ｂが登録されているだけの状態の文書管理データを例示的に示している。３０２は、図４に例示した２つのファイル、ａａ．ｘｍｌ４０１とｂｃｄ．ｊｐｇ４０２を格納した後の文書管理データの例を示している。

図３のように、本実施形態において、文書管理データは、ドキュメントテーブル３１０、ボリュームファイルテーブル３２０、サブファイルテーブル３３０、権利テーブル３４０、グループテーブル３５０から構成される。

ドキュメントテーブル３１０は、文書（ドキュメント）の識別子としてのＩＤ３１１、文書名を表す名前３１２、文書の管理単位の種別を示すタイプ３１３、文書が格納されたファイルの識別子としてのボリュームＩＤ３１４、１ファイル複数文書のファイルにおいて管理単位となる文書を特定するための指定子３１５、ロック情報３１６、文書について処理を行う場所を示したエリア３１７、権利情報の識別子としての権利情報３１８等の要素を保持する。文書の一覧等を表示する際はこのドキュメントテーブルのＩＤごとに別文書として表示される。

ボリュームファイルテーブル３２０は、実ファイル（ボリューム）の識別子としてのＩＤ３２１、実ファイルの格納されたディレクトリ情報を示すパス３２２、実ファイル名３２３、実ファイルの種類を示すタイプ３２４等の要素を保持する。

サブファイルテーブル３３０は、サブファイルの識別子としてのＩＤ３３１、対応するボリューム（ファイル）の識別子としてのボリュームＩＤ３３２、親文書（ドキュメント）の識別子としてのドキュメントＩＤ３３３等の要素を保持する。

権利テーブル３４０は、権利の識別子としてのＩＤ３４１、アクセスするグループの識別子としてのグループＩＤ３４２、許可するアクセスの内容を記述した権利３４３等の要素を保持する。

グループテーブル３５０は、グループの識別子としてのＩＤ３５１、ユーザ（グループ）の名前としてのユーザ名３５２等の要素を保持する。

上記テーブルにおいて、ボリュームＩＤ３１４とＩＤ３２１、権利情報３１８とＩＤ３４１、グループＩＤ３４２とＩＤ３５１、ボリュームＩＤ３３２とＩＤ３２１、ドキュメントＩＤ３３３とＩＤ３１１は、それぞれ対応している。尚、上記の文書管理データの構成はあくまでも一例であり、文書管理データは用途や目的に応じてどのように構成してもよい。

また、図４は、文書ファイルの一例を示した図である。図４において、４０３はａａ．ｘｍｌ４０１のファイルの中身（内容）を示している。図４の例において、ａａ．ｘｍｌは、４０５と４０６の２つのＣｈａｐｔｅｒ要素をもち、２つ目のＣｈａｐｔｅｒ要素（Ｃｈａｐｔｅｒ２）４０６内では、４０４にあるようにｂｃｄ．ｊｐｇを取り込む旨が記述されている。従って、ａａ．ｘｍｌ４０１は、２つのＣｈａｐｔｅｒ要素という文書の単位を有している点において１ファイル複数文書の形式に当てはまる。一方、Ｃｈａｐｔｅｒ２（４０６）は、ｂｃｄ．ｊｐｇ４０２を取り込んでいることから、複数ファイル１文書の形式に当てはまる。

この文書に対するスキーマはあらかじめスキーマ保管部１０５に保管されているものとし、そのスキーマに対応する文書をシステムに格納する際にはＣｈａｐｔｅｒ要素を文書として扱う旨の管理単位についての情報が、スキーマに対応する管理単位情報に記述されている。本実施形態に係る情報処理装置は、この管理単位情報に基づいて同一文書ファイルに含まれる文書の管理単位ごとに別文書としてドキュメントテーブル３１０に登録する。

このようなａａ．ｘｍｌとｂｃｄ．ｊｐｇをシステムに格納すると３０２に示すように、ボリュームファイルテーブル３２０には実ファイルであるａａ．ｘｍｌとｂｃｄ．ｊｐｇの保管先パスなどと一緒に実データ情報を追加するように制御する。

ドキュメントテーブル３１０には、Ｃｈａｐｔｅｒ単位で２つのドキュメントを追加する。上記の例の場合、１つ目のＣｈａｐｔｅｒ要素（Ｃｈａｐｔｅｒ１）４０５と
２つ目のＣｈａｐｔｅｒ要素（Ｃｈａｐｔｅｒ２）４０６は、それぞれ同じボリュームのＩＤ３２１を持つので、ボリュームファイルテーブル３２０の同一行を指し示す、即ち、同一の実ファイルを示すように、ボリュームＩＤ３１４を設定する。また、指定子３１５にＸＰａｔｈ等の形式でファイル内でその文書が指し示している要素を指定する記述を追加する。ｂｃｄ．ｊｐｇに関しては、サブファイルテーブル３３０に、Ｃｈａｐｔｅｒ２の付属文書として、即ち、親文書の識別子（ドキュメントＩＤ３３３）を２番目のＩＤ３１１と同様の２として設定・管理する。

一方、権利テーブル３４０においては、ＩＤ３４１が１の権利情報には、グループＩＤが１、即ち、Ｔｅａｍ＿Ａは書くことができることが定義されている。同様に、ＩＤ３４１が２の権利情報には、グループＩＤが１、即ち、Ｔｅａｍ＿Ａは読むことができ、グループＩＤが２、即ち、Ｔｅａｍ＿Ｂは書くことができることが定義されている。そして、ＩＤ３１１が１の文書、即ち、Ｃｈａｐｔｅｒ１にはＩＤ３４１が１の権利情報３１８、ＩＤ３１１が２の文書、即ち、Ｃｈａｐｔｅｒ２にはＩＤ３４１が２の権利情報３１８が設定されている。

従って、Ｃｈａｐｔｅｒ１に対してはＴｅａｍ＿Ａのメンバーは書き込み権を持っているがＴｅａｍ＿Ｂのメンバーはアクセス権自体を持っていない。また、Ｃｈａｐｔｅｒ２に対しては、Ｔｅａｍ＿Ａのメンバーは読み取り権しか持っていないが、Ｔｅａｍ＿Ｂのメンバーは書き込み権を持っている。

このように、従来の１ファイル１文書として格納するシステムであればＣｈａｐｔｅｒ１もＣｈａｐｔｅｒ２も合わせて１つの文書として管理しなければならないところを、本実施形態の構成においては、それぞれ別々に管理する事ができる。即ち、ファイル毎ではなく、文書を単位としてアクセス権を制御することが可能である。

尚、ドキュメントテーブル３１０、ボリュームファイルテーブル３２０、サブファイルテーブル３３０は、文書データを格納する際に、対応するスキーマファイル、管理単位情報ファイル等に基づいて、本実施形態に係る情報処理装置が操作対象のファイルを解析し、設定する。ただし、権利情報３１８の値は、文書操作時に適宜指定される。権利テーブル３４０は、事前にアクセス権付与の全てのパターンを網羅して設定しておいてもよいし、文書に対する操作を契機として設定するようにしてもよい。グループテーブル３５０は、予め設定しておくものとする。

上記では、１ファイル複数文書の形式を持つ文書に対する操作に関して説明を行ったが、複数ファイル１文書の形式の文書に対する操作に関しても同様に図４の文書管理データの各テーブルを用いて管理される。即ち、サブファイルテーブル３３０に、ファイルの従属関係を記述し、情報処理装置はこの従属関係に基づいて、例えば、本体のファイルに対するコピー、削除、移動等の操作、アクセス権の設定等の操作がなされると、本実施形態に係る情報処理装置は、サブファイルについてもそれらの操作を適用するように制御する。これにより複数ファイル１文書の形式の文書についても同じ文書管理データでの管理を可能にする。

＜＜第２実施形態＞＞
第１実施形態では、文書をシステムへ格納することを契機として文書の管理単位を決定する場合について説明したが、文書をシステムへ格納した後に所定のイベントが発生したことや、文書のステータスが変更されたこと、文書が置かれている論理的な管理領域（文書作成領域）間を移動したこと等を契機としても、文書の管理単位を変更可能なように構成してもよい。本実施形態では、一例として、文書作成領域間を移動したことを契機として文書の管理単位を変更可能とする構成について説明する。

例えば、図６に示すような文書管理システムを想定する。図６は、グループ（チーム）で文書の共有を行う文書管理システムの一例を模式的に示した図である。

６０１乃至６０６は、それぞれシステムを利用するクライアントグループＴｅａｍ Ａ、Ｔｅａｍ Ｂ、・・・、Ｔｅａｍ Ｆである。また、６０７乃至６１０は、それぞれ文書作成領域を示しており、円で示した限定されたクライアントグループが各円に交差している文書作成領域にアクセスできるものとする。例えば、文書作成領域（Ｉ）６０７にはＴｅａｍ Ａ６０１とＴｅａｍ Ｂ６０２、文書作成領域（ＩＩ）６０８にはＴｅａｍ Ｃ６０３とＴｅａｍ Ｄ６０４、文書作成領域（ＩＩＩ）６０９にはＴｅａｍ Ｅ６０５、文書作成領域（ＩＶ）６１０にはＴｅａｍ Ｆ６０６が、それぞれアクセスできる。ここで、アクセスとは文書の共有、作成、更新、表示、一覧表示等を意味する。上記のように、この文書作成領域上では複数のグループやユーザがアクセス可能なため、個別のアクセス権制御が可能になっている。

６１１は文書公開領域６１１であり、作成した文書を成果物として全てのクライアントグループ、グループ・ユーザ、或いは、より多くのグループ・ユーザに公開するための領域である。本実施形態においては、全てのクライアントグループに属するユーザがアクセスできる領域とする。

文書作成領域６０７〜６１０、文書公開領域６１１は、それぞれ論理的に区切られた領域であり、物理的には同じシステムもしくは、同じデータベース上に存在してもよい。そこで本実施形態においては、文書作成領域６０７〜６１０、文書公開領域６１１が全て同一のデータベース６１２内に構成されているものとする。もちろん、文書作成領域６０７〜６１０、文書公開領域６１１をそれぞれ別個の装置に構成するようにしても構わない。

図７は、図６に例示した文書管理システムの物理的な構成例を示したブロック図である。図７において、７０１は、図１における文書管理データ保管部１０８、実データ保管部１０９、スキーマ保管部１０５としての役割を担うデータベースである。７０２は、データベース及び後述のネットワーク７０４に接続されたサーバである。７０３ａ乃至７０３ｃ（以下、まとめて７０３と称する）は、ユーザが操作しサーバ７０２にアクセスするクライアントである。７０４は、サーバ７０２とクライアント７０３を結ぶネットワークである。

サーバ７０２及びクライアント７０３は、それぞれ、例えば、パーソナルコンピュータ（ＰＣ）やワークステーション（ＷＳ）携帯情報端末（ＰＤＡ）等で実現される。ネットワーク７０４は、典型的には、ＬＡＮであるが、有線／無線を問わず、公衆回線（アナログ回線、ＩＳＤＮ等）やＷＡＮ、無線ＬＡＮ等のデータ送受信可能な回線であれば、どのような構成でもよい。ネットワークを用いた通信プロトコルは、例えば、ＴＣＰ／ＩＰ等を採用することができる。

図７の構成においては、サーバ７０２、データベース７０１、クライアント７０３が共同して図１の各要素を構成する。即ち、ネットワーク７０４を介したクライアント・サーバ型のシステムを想定し、一つ以上のデータベース７０１と接続されたサーバ７０２が一つ以上のクライアント７０３からのアクセスを受け付ける。図６における文書作成領域６０７〜６１０、文書公開領域６１１、及び、データは物理的には、図７におけるデータベース７０１上に存在するものとする。

このようなシステムにおいて、文書作成領域６０７に２つの文書Ｃｈａｐｔｅｒ１とＣｈａｐｔｅｒ２が存在し、文書公開領域６１１に対して「公開」という処理を行う場合を考える。

Ｃｈａｐｔｅｒ１、Ｃｈａｐｔｅｒ２のデータベース上でのデータ構成は、第１実施形態で説明した図３の３０２と同様であり、図８の８０１で示される。図８は、この文書管理システムにおける文書管理データの一例を示した図である。ここで、Ｃｈａｐｔｅｒ１、Ｃｈａｐｔｅｒ２をそれぞれ、Ｔｅａｍ＿Ａ、Ｔｅａｍ＿Ｂが編集・更新を行ってきたが、文書が完成したため、それぞれのＣｈａｐｔｅｒを章として元々のファイルのデータ構造と同じように、一つの文書に統合し、文書公開領域に公開する状況を考える。ここで、スキーマ保管部１０５に保管された、操作対象の文書のスキーマファイルに対応する管理単位情報には、文書作成領域６０７ではＣｈａｐｔｅｒ要素を単位とした（１ファイル複数文書）形式で扱う旨が、文書公開領域では（複数ファイル１文書）形式で扱う旨が記述されていたとする。

この場合、「公開」のプロセスを行う事で、公開操作イベントが文書操作制御部１０１に対して発行され、本実施形態に係る情報処理装置は、このイベントを契機として図２の処理フローを開始する。

その処理において、本実施形態に係る情報処理装置は、データベース７０１のトランザクションを開始し、ドキュメントテーブル３１０に対して、文書公開領域に作成する旨が指示された文書のための新たな行８０３を追加し、それとともに、サブファイルテーブル３３０に格納していた、付属ファイルｂｃｄ．ｊｐｇのドキュメントＩＤ３３３（親文書のＩＤ）を公開文書のＩＤ（３）に変更するように制御する。更に、公開する文書の元となる文書（Ｃｈａｐｔｅｒ１、Ｃｈａｐｔｅｒ２）に対応する行８０４、８０５をドキュメントテーブル３１０から削除するように制御する。このような処理の後、トランザクションをコミットする。

尚、サブファイルテーブル３３０の変更は、例えば、別の行を追加することによって変更するようにしてもよい。同様に、Ｃｈａｐｔｅｒ１、Ｃｈａｐｔｅｒ２に対応する行８０４、８０５は、ドキュメントテーブル３１０に残したままにするようにしてもよい。

以上のように、本実施形態の構成によれば、一度システムへ格納し、文書の管理単位を決定した文書について、文書のステータスや文書が置かれている論理的領域の変更を契機として、文書の管理単位を変更することが可能となる。これによりユーザは文書を容易に管理することができる。

尚、上記構成において、文書の管理単位を変更して複数文書を一つの文書へと変換する場合に、変換前の文書それぞれの属性やインデックス情報等の文書管理データを合成・統合するように構成してもよい。文書管理データの合成・統合は例えば以下のように実現することができる。即ち、まず、複数の文書管理データについて、値が同一の情報と、同一ではない情報とに分類する。次に、値が同一の情報については変換後の文書にそのまま適用し、値が同一でない情報については予め設定されたポリシーに基づいて適切な情報を選択し、変換後の文書に適用する。また、ファイルのリンク情報が含まれるファイルを、新たに別のファイルから参照するように変換する場合は、ファイルの参照関係を反映するように文書管理データを階層化する。そして、変換された文書データを並列的に列挙する。以上のような処理を行うことにより、ユーザは複数文書の統合を容易に行うことができる。

また、上記の構成において、文書の管理単位を変更して複数文書を一つの文書へと変換する場合に、特に、変更前の文書群のアクセス権一覧もしくはアクセス権を指し示すＩＤ列をメモリ上に読み出し、読み出された情報に基づいてそれらのアクセス権を合成し、合成したアクセス権限を変更後の文書に付与するように制御してもよい。ただし、アクセス権の合成は、用途や目的に応じて、例えば、変換前の文書に付与された権利のうち最も低いもの、又は、高いもの等に設定するように構成することができる。例えば、読み取り権が付与された文書の管理単位と、書き込み権が付与された文書の管理単位とを合成する場合、合成後の文書に、読み取り権、又は、書き込み権を付与するように構成することができる。このような処理を行うことにより、変更前にアクセス可能だったユーザに対して変更後の文書に対するアクセスを可能にする事ができる。

また、上記の構成において、スキーマ保管部１０５は、スキーマファイルと管理単位情報に加えて、ユーザ（又はグループ）の識別情報をも関連づけて保持するように構成してもよい。さらに、ユーザが文書ファイルについて指示入力を行った際に、操作ユーザを特定し、そのユーザの識別情報に関連づけて管理単位情報を取得し、この管理単位情報に基づいて文書管理データを作成・更新するように構成してもよい。これにより、システムを利用するユーザ（又はグループ）に応じて、同一スキーマに対応する文書について、それぞれの文書の管理単位を変更することができる。

また、上記構成において、文書の管理単位を変更して一つの文書を複数の文書へと変換する場合に、論理的な格納場所やアクセス権等の設定を促すＵＩをディスプレイ９０７に表示し、当該ＵＩを介してユーザにより入力された設定に基づいて文書管理データを作成・更新するように構成してもよい。これにより、ユーザは、変換後の文書についてアクセス権限を容易に設定することができる。

尚、以上述べた処理を開始するタイミングは、用途や目的に応じて所定のイベントの発生に基づくことができる。例えば、文書をシステムへ格納すること、文書の論理的な保管場所を変更すること、文書の属性、ステータスを変更すること、文書ファイルをシステムから外部へ出力すること、文書を印刷すること等を契機として、処理を開始するように構成することができる。

＜＜その他の実施形態＞＞
以上、本発明の実施形態例について詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様を取ることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

尚、本発明は、前述した実施形態の機能を実現するプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含む。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。 また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。

本実施形態に係る情報処理装置の機能構成を示したブロック図である。 文書管理処理の処理の流れを示したフローチャートである。 文書管理データの一例を示した図である。 文書ファイルの一例を示した図である。 複合的な構造を有する文書の一例を模式的に示した図である。 グループで文書の共有を行う文書管理システムの一例を模式的に示した図である。 グループで文書の共有を行う文書管理システムの物理的な構成例を示したブロック図である。 文書管理データの一例を示した図である。 本実施形態に係る情報処理装置のハードウェア構成を模式的に示したブロック図である。 スキーマ保管部におけるデータの構造を模式的に示した図である。 実データ保管部におけるデータ構造を模式的に示した図である。

Claims (7)

1. 文書構造を規定する複数のスキーマと、各スキーマに対して予め設定された、文書ファイルの管理単位を示す管理単位情報とを保持するスキーマ保持手段と、
   文書ファイルに対する操作を示す指示内容を受け取る文書操作制御手段と、
   前記文書操作制御手段が受け取った指示内容に基づいて操作対象の文書ファイルを特定し、前記スキーマ保持手段に保持された複数のスキーマの中から、当該特定した操作対象の文書ファイルに適合するスキーマを判定するスキーマ解析手段と、
   前記スキーマ解析手段で適合すると判定されたスキーマに対して予め設定されている管理単位情報を前記スキーマ保持手段から取得することによって、前記操作対象の文書ファイルの管理単位を、１ファイル１文書として扱うべきか、１ファイル複数文書として扱うべきか、複数ファイル１文書として扱うべきかを特定する管理単位特定手段と、
   前記管理単位特定手段が特定した管理単位に基づいて、前記文書ファイルを前記特定された管理単位として扱うための文書管理データを作成または更新する管理単位更新手段と、
   前記文書管理データを保持する保持手段と、
   前記文書ファイルを扱う際に、前記保持手段に保持された前記文書管理データに基づいて、１ファイル１文書として扱うべきか、１ファイル複数文書として扱うべきか、複数ファイル１文書として扱うべきかを管理する制御手段と、を備えることを特徴とする情報処理装置。
2. 前記文書ファイルに対する操作を示す指示内容は、予め定めたユーザがアクセス可能な管理領域と全てのユーザがアクセス可能な管理領域とを含む複数の管理領域の間で、前記文書ファイルを移動させる指示内容であり、
   前記管理単位情報は、前記管理領域ごとに文書ファイルの管理単位を示し、
   前記管理単位特定手段は、前記指示内容と、前記スキーマ解析手段で適合すると判定したスキーマに対応して前記スキーマ保持手段から取得する管理単位情報とに基づいて、前記文書ファイルの管理単位をどのように扱うべきかを特定する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記スキーマ解析手段で、前記文書ファイルに対応するスキーマが前記スキーマ保持手段に保持されていないと判定された場合、前記管理単位特定手段は、前記文書ファイルの管理単位を、１ファイル１文書として扱うとして特定することを特徴とする請求項１または２に記載の情報処理装置。
4. 前記文書管理データは、前記文書ファイルの前記管理単位ごとのアクセス権限を示す権限情報を含むことを特徴とする請求項１に記載の情報処理装置。
5. 文書ファイルに対する操作を示す指示内容を受け取る文書操作制御工程と、
   前記文書操作制御工程で受け取った指示内容に基づいて操作対象の文書ファイルを特定し、文書構造を規定する複数のスキーマと各スキーマに対して予め設定された文書ファイルの管理単位を示す管理単位情報とを保持するスキーマ保持手段に保持された複数のスキーマの中から、当該特定した操作対象の文書ファイルに適合するスキーマを判定するスキーマ解析工程と、
   前記スキーマ解析工程で適合すると判定されたスキーマに対して予め設定されている管理単位情報を前記スキーマ保持手段から取得することによって、前記操作対象の文書ファイルの管理単位を、１ファイル１文書として扱うべきか、１ファイル複数文書として扱うべきか、複数ファイル１文書として扱うべきかを特定する管理単位特定工程と、
   前記管理単位特定工程で特定した管理単位に基づいて、前記文書ファイルを前記特定された管理単位として扱うための文書管理データを作成または更新する管理単位更新工程と、
   前記文書管理データを保持手段に保持する保持工程と、
   前記文書ファイルを扱う際に、前記保持手段に保持された前記文書管理データに基づいて、１ファイル１文書として扱うべきか、１ファイル複数文書として扱うべきか、複数ファイル１文書として扱うべきかを管理する制御工程と、を備えることを特徴とする情報処理装置の制御方法。
6. コンピュータを、
   文書ファイルに対する操作を示す指示内容を受け取る文書操作制御手段、
   前記文書操作制御手段で受け取った指示内容に基づいて操作対象の文書ファイルを特定し、文書構造を規定する複数のスキーマと各スキーマに対して予め設定された文書ファイルの管理単位を示す管理単位情報とを保持するスキーマ保持手段に保持された複数のスキーマの中から、当該特定した操作対象の文書ファイルに適合するスキーマを判定するスキーマ解析手段、
   前記スキーマ解析手段で適合すると判定されたスキーマに対して予め設定されている管理単位情報を前記スキーマ保持手段から取得することによって、前記操作対象の文書ファイルの管理単位を、１ファイル１文書として扱うべきか、１ファイル複数文書として扱うべきか、複数ファイル１文書として扱うべきかを特定する管理単位特定手段、
   前記管理単位特定手段で特定された管理単位に基づいて、前記文書ファイルを前記特定された管理単位として扱うための文書管理データを作成または更新して、前記文書管理データを保持手段に保持させる管理単位更新手段、
   前記文書ファイルを扱う際に、前記保持手段に保持された前記文書管理データに基づいて、１ファイル１文書として扱うべきか、１ファイル複数文書として扱うべきか、複数ファイル１文書として扱うべきかを管理する制御手段、
   として機能させるためのコンピュータプログラム。
7. 請求項６に記載のコンピュータプログラムを格納したコンピュータで読み取り可能な記憶媒体。

Images