JPH07129447A - 文書情報管理システム - Google Patents

Abstract

(57)【要約】 【目的】 本体文書等に関連するひとまとまりのタスク
を一体的に管理することが可能な文書情報管理システム
を提供する。 【構成】 文書管理に必要な各種の補助データのディレ
クトリをデータベースとして管理する複数の管理部（Ｂ
ＯＸ）と、これら各管理部に付随して設けられ、文書フ
ァイルの選択に必要な補助データが、そのデータ内容に
応じた管理部に格納される補助データ格納領域（エリ
ア）と、アプリケーションからの要求内容を解釈する要
求解釈部（ＤＡＭ）と、この要求解釈部の解釈内容に応
じて、前記管理部を選択する選択部（ＪＤＭ）と、この
補助データ管理部で選択された補助データに対して、前
記要求解釈部の解釈内容に応じた各種の処理を選択して
実行するする処理選択実行部（ＩＤＳ）とを備える。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は文書情報管理システムに
係り、詳細には、文書管理に必要な各種の補助データに
基づいて文書を管理する文書情報管理システムに関す
る。

【０００２】

【従来の技術】パーソナルコンピュータがオフィスや工
場、研究所等に広く普及しており、必要に応じて文書作
成、図形処理、計算、データベース等のアプリケーショ
ンソフト（ＡＰＬ）が開発されている。このようなパー
ソナルコンピュータで各種の処理を行うためのアプリケ
ーションソフトは、一般にＯＳ（オペレーティング・シ
ステム）上で動作するようになっており、作成された文
書や図形等は、ＯＳの規定に従って格納されていた。そ
して、本体となる文書や図形等（以下この明細書におい
て、本体文書等という。）を管理するためのデータとし
て、他に履歴管理データや付箋管理データ等の管理情報
を保存することが可能になっている。また、本体文書等
を効率的に管理するために、ＯＳにおける管理情報に対
して、他の拡張した複数の管理情報を格納し、この拡張
した管理情報から必要な本体文書等を迅速、効率的に読
み出すようにした、アプリケーションソフトも存在して
いる。

【０００３】図１２は、従来のＯＳ、および文書管理ア
プリケーションソフトによる、本体文書等のファイル管
理システムを表したものである。この図に示すように、
ＯＳによるファイル管理の場合、アプリケーションＢに
よって作成された、本体文書等のファイルＢは、ディレ
クトリ名＋ファイル名（８文字）＋拡張子（３文字）で
管理され、ファイル作成日時／ファイルサイズ、およ
び、ファイル属性が格納されるようになっている。この
場合、ＯＳによるファイルシステム１２に従って、それ
ぞれ、ユーザ１１に対して一体的にファイル管理され
る。ここで、ファイル属性には、消去や更新が禁止され
ているリードオンリファイル、ＤＩＲコマンドでは表示
されずＤＥＬコマンドによる削除も無効になる隠しファ
イル、リードオンリでかつ隠しファイルのシステムファ
イル、ボリュームラベルであることを示すボリューム
名、サブディレクトリであることを示すディレクトリ、
ＢＡＣＫＵＰコマンドなどで利用され通常のファイルは
この属性をもつ未バックアップファイル（アーカイブフ
ァイル）、等の属性がある。

【０００４】一方、拡張した管理情報の保存が可能なア
プリケーションソフトＡによって作成された本体文書等
のファイルＡは、ＯＳのファイルシステム１２の規定に
従って独自のフォーマットで格納されると共に、このフ
ァイルＡとは別途に管理情報１３が、やはりＯＳのファ
イルシステム１２に従って格納されている。なお、ユー
ザ１１との関係では、ファイルＡを管理するための独自
のユーザインターフェイスが規定されている。

【０００５】

【発明が解決しようとする課題】しかし、従来のＯＳに
よる文書管理は、本体文書等を管理するための管理情報
が限定されており、本体文書等と共に、各種の管理情報
の内容が少ないという問題があった。特に、ネットワー
ク内のサーバ上で多くのファイルを多数のユーザが共有
している場合には、必要なファイルを捜すのに時間がか
かっていた。

【０００６】一方、ＯＳと独立した別個の管理情報を格
納し、この管理情報から特定のファイルを指定するアプ
リケーションソフトＡを使用する場合には、ファイルを
色々な観点から読みだすことが可能となる。しかし、従
来のアプリケーションソフトＡによる管理システムで
は、特定の本体文書等と別個に管理情報のファイルを作
成しているため、ユーザにとってみると、管理情報の処
理はその本体文書等に一体化したタスクとして意識され
ることが多いにもかかわらず、複数のファイルを処理し
なければならないという問題があった。さらに、拡張し
た管理情報を、ファイルＡの内部に格納し、又は管理情
報１３に格納する処理は、アプリケーションＡに固有な
処理であるため、操作性について、各アプリケーション
ソフト間で統一されていなければならないという問題が
あった。従って、処理が統一されていない他のアプリケ
ーションソフト、例えばアプリケーションソフトＢで
は、管理情報１３の内容に従って文書ファイルＡを読み
出すことができなかった。また、統一させる場合には、
個々のアプリケーションソフトが操作性を意識してプロ
グラムを作成する必要があった。

【０００７】また、管理情報１３を作成することでファ
イルを管理する場合は、ファイルＡの内部に格納する場
合に比べて、管理情報の保全性の点で優れているが、フ
ァイルＡに対してコピー等の処理が行われると、整合性
が保てなくなるという問題があった。さらに、拡張した
管理情報を扱うために、アプリケーションソフトが共通
したユーザインタフェースをユーザ１３に提供するため
には、アプリケーションプログラマ間で、共通の認識が
必要になるという問題があった。

【０００８】そこで、本発明は、本体文書等に関連する
ひとまとまりのタスクを一体的に管理することが可能な
文書情報管理システムを提供することを目的とする。

【０００９】

【課題を解決するための手段】請求項１記載の発明で
は、計算機システム上のアプリケーションから処理対象
とするファイルを選択するための情報を管理するシステ
ムであって、文書管理に必要な各種の補助データを、デ
ィレクトリ構築のためのデータベースとして管理する複
数の管理部と、これら各管理部に付随して設けられ、文
書ファイルの選択に必要な補助データが、そのデータ内
容に応じた管理部に格納される補助データ格納領域と、
アプリケーションからの要求内容を解釈する要求解釈部
と、この要求解釈部の解釈内容に応じて、前記管理部を
選択する選択部と、この補助データ管理部で選択された
補助データに対して、前記要求解釈部の解釈内容に応じ
た各種の処理を選択して実行する処理選択実行部とを、
文書情報管理システムに具備させて、前記目的を達成す
る。

【００１０】

【実施例】以下、本発明の文書情報管理システムにおけ
る一実施例を図１ないし図１１を参照して詳細に説明す
る。図１は文書情報管理システムのシステム構成を表し
たものである。この図１に示すように、文書情報管理シ
ステムは、要求解釈部として機能するＤＡＭ２１、処理
選択実行部として機能するＩＤＳ２２、管理部として機
能するＢＯＸ２３、標準ＢＯＸ２３、選択部として機能
するＪＤＭ２５、ファイルＵＩ２６、およびＢＯＸファ
イル２７、を備えている。これら、各部２１〜２７は、
各種のアプリケーションソフト（ＡＰＬ）２８に対し
て、従来的なファイルアクセスの全てをカバーし、同様
に動作するようになっている。

【００１１】ＤＡＭ２１は、本体文書等に対するアクセ
スを標準化し、全てのＡＰＬ２８の文書アクセスに関与
する。この標準化、すなわち、文書および文書ファイル
に対するアプリケーションインターフェイス（ＡＰＩ）
を一式そろえることで、従来と同様なファイルアクセス
の全てがカバーされることになる。ここで、ＤＡＭ２１
が取り扱う文書には、ＡＰＬ２８が編集している文書で
あり、保存されていない新規文書も含まれる。また、Ｄ
ＡＭ２１は、ＡＰＬ２８の文書アクセスに論理性を持た
せるようになっている。すなわち、ＤＡＭ２１は、ユー
ザの文書に対する論理的アクセス、例えば、「文書の使
用開始」（新規／編集）、「文書の使用終了」、「文書
の保存」、「文書の名称変更」その他の論理的アクセス
を明示する。また、ＤＡＭ２１は、ＡＰＬ２８の文書ア
クセスイベントをＩＤＳ２２に配付するようになってい
る。

【００１２】ＩＤＳ２２は、ユーザの指定により文書に
指定され、ＤＡＭ２１から配付された文書アクセスイベ
ントにより、文書に付加／付随した情報の管理／運用を
行うプログラムである。

【００１３】ＢＯＸ２３には、ＯＳで管理される物理的
なディレクトリを管理するプログラムが格納された標準
ＢＯＸ２３１と、論理的に拡張するディレクトリを管理
するプログラムが格納されている各種ＢＯＸ２３２で構
成されている。各種ＢＯＸ２３２には、例えば、本体文
書等の管理情報が管理される、例えば、ワープロソフト
で作成した文章における文書情報管理ＢＯＸ、メールシ
ステムにおける管理情報が管理されるメールＢＯＸ等の
各種ＢＯＸが存在する。これら標準ＢＯＸ２３１、各種
ＢＯＸ２３２は、補助データ格納領域として機能し、本
体文書等に付加、付随する各種の管理情報を記憶するた
めのエリアを備えている。このエリアは文書に付随して
可搬性を有している。各種ＢＯＸ２３２においては、適
時ＤＢ（データベース）を利用したエリアの管理が行わ
れ、一方、標準ＢＯＸ２３１（ＯＳディレクトリ）で
は、次に示すＣＤＦ構造によってエリアが実現されてい
る。

【００１４】図２は標準ＢＯＸ２３１における、ＣＤＦ
の構造を表したものである。ＣＤＦは、ファイルヘッダ
３１、アプリケーション管理ファイル部３２、ＩＤＳ管
理情報部３３で構成されている。具体的には、１個のフ
ァイルに複数のセグメントが配置され、例えば、ワープ
ロソフトによる文書や図形ソフトによる文書は、それぞ
れ別セグメントに書込まれる。また最初のセグメントは
ファイルヘッダ３１として使用される。すなわち、ファ
イルヘッダ３１には、作成アプリケーション名など、そ
のドキュメントに関する固有情報が書き込まれる。ファ
イルヘッダ３１の後のセグメントについては、ワープロ
ソフトによる文書は０１、図形ソフトによる文書は０２
というようにＩＤが付加される。アプリケーションは、
データをリード／ライトするときのこのＩＤを参照する
ようになっている。

【００１５】またＣＤＦのＩＤＳ管理情報部３３には、
文書のデータベース化やグループワーク支援で必要にな
る情報が格納され、ＩＤＳ２２のプログラムによってこ
の部分が管理されている。このように、標準ＢＯＸ２３
１をＣＤＦ構造にすることで、アプリケーション間のデ
ータ交換をスムーズに行うことが可能となる。つまりデ
ータを渡す側のアプリケーションは、渡される側のアプ
リケーションのデータ構造を考慮する必要がなくなる。

【００１６】ＪＤＭ２５は、ＤＡＭ２１に対してプリミ
ティブな文書アクセスのＡＰＩを公開している。ＪＤＭ
２５は、ＢＯＸ情報管理機能を備えており、ＢＯＸ２３
に対する環境情報を記憶し、ＤＢを用いて管理情報やエ
リアを管理する。ＪＤＭ２５のＢＯＸ情報管理機能は、
ＢＯＸファイル２７の管理テーブルに各種ＢＯＸ２３２
の識別ファイルを格納することで実現されている。すな
わち、ＪＤＭ２５は、論理ディレクトリを構成する各種
ＢＯＸ２３２に対して、ＯＳ上の実際のディレクトリを
割り当て、ＢＯＸファイル２７に識別ファイルを格納す
る。この識別ファイルには、論理ディレクトリを管理す
る各種ＢＯＸ２３２を呼び出すためのプログラム名が記
述されており、識別ファイルが置かれているディレクト
リは、論理ディレクトリであるとして各種ＢＯＸ２３２
がＪＤＭ２５から呼び出されるようになっている。呼び
出された各種ＢＯＸ２３２に、ファイル名等の必要な情
報が記述されている。一方、ＢＯＸファイル２７に識別
ファイルが記述されていない場合、標準ＢＯＸ２３１が
ＪＤＭ２５から呼び出されるようになっている。

【００１７】ファイルＵＩ２６は、ユーザによってファ
イル名が入力され、また、選択画面が表示されるユーザ
インターフェイスである。ＢＯＸ２３の考えを導入する
に当たり、従来的なＡＰＬ２８作成における影響を最小
限にするために、ユーザインタフェース（ＵＩ）をＡＰ
Ｌ２８から切り放した。ＡＰＬ２８とのＡＰＩを「パス
名」にすることにより、従来と同様に作成することを可
能にした。現状のＵＩは、標準的なものと、ＢＯＸ２３
独自のＵＩを持てる仕組みになっているが、ＵＩを切り
放す際にファイル名入力／選択画面ＵＩ管理機構（ＤＰ
Ｍ）を導入したことで、今後開発されていく可能性のあ
る未知のＢＯＸ２３に対応する全く新しいＵＩの採用／
共存が可能になる。なお、ファイルＵＩ２６によって、
ユーザは、文書を保存する際に、文書情報からファイル
を識別でき、ファイル名を付ける必要がない場合に、フ
ァイル名発行サービスを選択することができる。この選
択が選択されると、ＢＯＸ２３でのファイル名発行サー
ビスが実行され、ＯＳに対して自動的にファイル名が発
行されるようになっている。

【００１８】ファイルＵＩ２６から論理パス名がＡＰＬ
２８に渡され、ＡＰＬ２８のファイルコマンドによっ
て、文書情報管理ＢＯＸ２３２で管理される本体文書等
のアクセスが可能になる。また、ファイルコマンドのみ
ならず、本体文書等のファイル選択の全ての局面にわた
って文書情報管理ＢＯＸ２３２へのアクセスが可能とな
っている。ファイルの指定は従来通りのパス形式で行う
ので、ユーザは、従来的な操作性と、パス形式を意識し
ない文書情報管理ＢＯＸ２３２の操作性とを併用するこ
とができる。ディスクユーティリティでは、文書ファイ
ルのコピー、移動、削除などのメンテナンスをＯＳディ
レクトリ、ＢＯＸ２３にまたがって、従来的な操作感の
ままに行うことができる。

【００１９】次に、このように構成された実施例の各部
の具体的構成とその動作について説明する。 （１）ＪＤＭ２５、ＢＯＸ２３ ＪＤＭ２５の動作は、ユーザ側で認識できず、ユーザは
従来と同様のパス形式による指定を行うことで、自動的
に論理ＢＯＸ２３２にアクセスすることができる。パス
形式での指定の採用により、組込リンクなどの、文書間
でのリンク関係など、全てのファイルアクセスが、ユー
ザ／ＡＰＬ２８共に従来と全く同様に行うことができ
る。ユーザがパス名を必要としない場合には、ファイル
ＵＩ２６により、ファイル名を意識しない文書アクセス
も可能になる。ここで、ＯＳのディレクトリで解決され
ない論理ディレクトリによる各種ＢＯＸ２３２が指定さ
れる可能性があるパスを論理パスといい、ＤＡＭ２１か
ら上（ユーザ側）には、全てこの論理パスのみが認識さ
れるようになっている。本体文書等の管理は、ＢＯＸ２
３に一任されているが、ＢＯＸ２３の汎用性を考慮し
て、他のＢＯＸ２３の間の管理機能を利用（管理を委
任）できる仕組みになっている。

【００２０】図３は、他のＢＯＸ間における管理機能の
利用（委任）状態を表したものである。この図に示すよ
うに、例えば、文書情報管理ＢＯＸ２３２において、従
来のファイルの管理については、標準ＢＯＸ２３１に委
任する形をとっている。この仕組みにより、文書情報管
理ＢＯＸ２３２ａで簡単に従来のファイルが管理できる
ようになった。同様に、例えばメールＢＯＸ２３２ｂを
作成する際に文書情報管理ＢＯＸ２３２ａの管理機能を
利用することができ、将来的に各種ＢＯＸ２３２を容易
に作成することができるようになる。

【００２１】図４は、ＪＤＭ２５による処理の流れを表
したものである。この図４に示すように、ＪＤＭ２５
は、目的とする本体文書等のファイルがどのＢＯＸ２３
に格納されているかを、論理パスから調べる。具体的に
は、処理の高速化のため、「・・・．ＢＯＸ」という拡
張子を仮定したうえで、ＢＯＸファイル２７から、該当
するＢＯＸ２３を調べる。そして、そのＢＯＸ２３が、
標準ＢＯＸ２３１である場合、ＣＤＦまたはＯＳファイ
ルシステムによって、実ファイルアクセスを行う。一
方、ＢＯＸファイル２７から調べたＢＯＸ２３が、標準
ＢＯＸ２３１でない場合、すなわち各種ＢＯＸ２３２で
ある場合、該当する各種ＢＯＸ２３２が作成しているデ
ータベース（ＤＢ）の位置を知る。そして、目的とする
本体文書等のファイルの、位置（物理パス）を知る。そ
して、目的文書ファイルのアクセスを標準ＢＯＸ２３１
に委任する。委任されると、委任されたファイルがどの
ＢＯＸ２３に管理されているか再び判断される。ここで
は、委任された内容である表示ＢＯＸ２３１が認識さ
れ、その後、ＣＤＦ又は、ＯＳシステムファイルによっ
て実ファイルアクセスが行われる。ここで、委任内容に
従って、再びどのＢＯＸ２３に管理されているかを判断
するのは、委任の内容によっては、各種ＢＯＸ２３２間
で委任される場合があるためである。

【００２２】（２）ＤＡＭ２１ ＤＡＭ２１の規定するＡＰＩで、従来通りのファイルア
クセスを行うことにより、ユーザやＡＰＬ２８の認識と
は別に、予め指定された各種ＩＤＳ２２のサービスがユ
ーザに提供される。例えば、ユーザの認識できるものと
して管理情報等があり、ユーザが認識できないものとし
てログ情報等がある。複数存在するＩＤＳのなかから、
ユーザによって、ファイルＵＩで指定されたＩＤＳ２
２、例えば管理情報ＩＤＳによって処理されたデータ
（自動設定された主題やキーワード等）は、本体文書等
に付随した（関連付けられた）ＢＯＸ２３に確保されて
いるエリアに保存される。文書情報管理ＢＯＸ２３で
は、エリアは文書ファイルとは別の箇所に管理されるの
で、どのような形式のファイルであっても、ＩＤＳ２２
を指定することが可能である。標準ＢＯＸ２３１におい
ても図２に示したＣＤＦの構造により、本体文書等に付
随しているＩＤＳ２２のデータを維持することができ
る。このことと、ファイルアクセスを標準化したこと
で、ユーザは、この実施例における文書情報管理システ
ム上では、ＢＯＸ２３と、ＯＳディレクトリとの区別を
意識することなく文書情報管理が可能になる。

【００２３】ＩＤＳ２２サービスで特に重要なものに文
書情報ＩＤＳ２２がある。文書情報ＩＤＳ２２は、文書
を管理するうえでの情報付加をサービスする。文書情報
は、システム項目として作成者、作成日などが提供され
ているが、基本的にはユーザの必要に合わせて設計する
仕組みを提供するものである。この文書情報の設計によ
り、ユーザは都合に合わせた文書情報管理システム（文
書管理アプリケーション）を構築するためのベースを設
計することになる。すなわち、ユーザは、新たに開発さ
れたＩＤＳがあっても、従来のＩＤＳと同様に、ファイ
ルＵＩ２６で選択することで、新たなＩＤＳのサービス
を利用することが可能となる。例えば、履歴管理や付箋
管理などのＩＤＳがある。

【００２４】図５は、文書情報ＩＤＳ２２の内容およ
び、ＢＯＸ２３の概念を表したものである。この図に示
すように、文書情報ＩＤＳ２２には、ファイル名、見出
し、作成者、作成年月日、キーワード、版番号、主題、
分類、ラベル、コメント、保存期限、用紙サイズ、テン
プレート名、最終更新日時、最終更新者、更新回数、最
終アクセス日時、最終アクセス者、総編集時間、最終印
刷日時、最終印刷者名、総ページ数、等の情報が格納さ
れる。これらは、標準的に付加されるものと、ユーザが
拡張的に設定するものとに分けられている。そして、こ
の文書情報ＩＤＳ２２によって、管理される内容は、Ｂ
ＯＸ２３のエリアに格納保存される。このように、多数
の情報を管理することで、ユーザが本体文書等を選択す
る場合の選択肢が増え、また、本体文書等を忘れたとし
ても、内容を思い出すきっかけが多く提供されることに
なる。例えば文書内キーワード検索では、例えば「パソ
コン」、「出荷代数」の２個のキーワードを含む本体文
書等のリストを画面表示することが可能となり、そのな
かから、ユーザは自由に本体文書等を選択することがで
きる。

【００２５】図６は、ＤＡＭ２１およびＩＤＳ２２にお
ける本体文書等に対する論理的アクセスの流れを表した
ものである。論理的アクセスとしては、「Ｏｐｅｎ」、
「Ｌｏａｄ」、「Ｓａｖｅ」、「Ｐｒｉｎｔ」、「Ｒｅ
ｎａｍｅ」等がある。ここで、ＤＡＭ２１でいう文書
は、ＡＰＬ２８が使用している文書をいい、新規文書／
読込文書共に、文書という意味では同一に扱われる。従
って、「Ｏｐｅｎ」の形式には、「新規」、「読込」…
等がある。図６に示すように、ＤＡＭ２１は、本体文書
等に対する論理的アクセスがあると、ＩＤＳ２２に通知
する。ＩＤＳ２２は、本体文書等に指定されているＩＤ
Ｓの内容を知ると、ＩＤＳ群を呼び出し、ＩＤＳ２２を
特定する。一方、ＤＡＭ２１は、特定されたＩＤＳ２２
から本体文書等のエリアをアクセスすると共に、本体文
書等のアクセスに対する、トランザクションや自動バッ
クアップ等のサービスを制御し、その後、ＪＤＭ２５を
呼び出す。

【００２６】次に、新規作成、読み込み、保存時の動作
について説明する。図７は、新規作成時の流れを表した
ものである。ＡＰＬ２８から、「Ｏｐｅｎ；新規」が通
知されると、ＤＡＭ２１は、メモリ上に管理資源を確保
し、文書情報ＩＤＳ２２に、「Ｏｐｅｎ；新規」を通知
し、ＡＰＬ２８に文書ハンドルを発行する。一方、ＤＡ
Ｍ２１から「Ｏｐｅｎ；新規」の通知を受けると、ＩＤ
Ｓ２２は、メモリ上に管理資源を確保し、文書情報項目
を初期化する。ここで、項目の種類や初期化の仕方は、
ユーザが例えばマクロで記述する。なお、「Ｏｐｅｎ；
新規」時には、テンプレートを指定することができ、こ
の場合、文書情報やその他のＩＤＳの指定は、テンプレ
ートから行われる。

【００２７】次に、本体文書等のファイルの読み込みに
ついて説明する。ファイルの読み込みについては、必要
な情報を入力し、データベースを直接操作して該当ファ
イルの絞り込みを行う。また、次に示すように、画面に
ファイル選択用のツリー構造とそのファイル名を表示、
それから選択するようにしてもよい。図８は、ＡＰＬ２
８側から、本体文書等のファイルを読み込む際のファイ
ル選択画面を表したものである。図８に示したファイル
選択画面では、文書情報ＩＤＳ２２によって自動的に管
理されている情報に従って、本体文書等を捜すためのツ
リーが表示され、また、「ビュー」機能により、画面に
は、ツリーの元（ルート）となる決裁書類に対応する各
種の本体文書等が表示されている。この、ツリーを使う
とＤＢの上で絞り込んだりする必要がなく、目的のツリ
ーの枝にカーソルを移動し、クリックやリターン等をす
るとツリーに与えられていた情報を用いて、ＤＢの絞り
込みがなされる。また、図上の決裁、見積、企画をアイ
コンでクリックすると絞り込みされる。従来は、ファイ
ル読み込み画面ではＯＳのディレクトリ階層を移りなが
ら、希望するファイルを少ない情報でしか捜し出せなか
ったのに対し、本実施例によれは、ＡＰＬ２８のファイ
ル選択画面上にＤＢを反映させることで、希望ファイル
が楽に選択できるようになる。

【００２８】次に、このようなファイル読み込み画面
で、所定の本体文書等が選択された場合の、ファイル読
み込み時の動作について説明する。図９は、読み込み時
の流れを表したものである。ＡＰＬ２８から、「Ｏｐｅ
ｎ；読込」が通知されると、ＤＡＭ２１は、メモリ上に
管理資源を確保し、文書ファイルを「Ｏｐｅｎ」するた
めに、ＪＤＭ２５が呼び出されると共に、本体文書等に
設定されているＩＤＳ全てに「Ｏｐｅｎ；読込」を通知
し、ＡＰＬ２８に文書ハンドルを発行する。ＪＤＭ２５
では、ＢＯＸファイル２７に記述されている識別ファイ
ルから、論理パスを解析し、ＢＯＸ２３の実ファイルが
開かれる。ＩＤＳ２２では、ＤＡＭ２１からの「Ｏｐｅ
ｎ；読込」の通知を受けると、メモリ上に管理資源を確
保し、ＢＯＸ２３で読み出された文書エリアに従って、
自身のデータを読み込み、必要な処理が実行される。例
えば、本体文書等に対して、文書情報ＩＤＳが設定され
ている場合には、文書情報を読み出し、アクセス日時の
設定等の処理が行われる。また、セキュリティＩＤＳが
設定されている場合には、セキュリティ情報を読み出
し、読込パーミッションの判断等を行う。ＩＤＳによる
処理の実行のときに、ＤＡＭ２１、ＪＤＭ２５を介し
て、ＢＯＸ２３における文書エリアの読み出しが行われ
る。

【００２９】図１０は保存の開始（ＲｅａｄｙＳａｖ
ｅ）の流れを表したものである。ＡＰＬ２８から「Ｒｅ
ａｄｙＳａｖｅ」が通知されると、ＤＡＭ２１は、本体
文書等のファイルが保存可能か否かを確認するために、
ＪＤＭ２５を呼び出すと共に、内部状態のトランザクシ
ョンの用意をした後、本体文書等に設定されているＩＤ
Ｓ全てに「ＲｅａｄｙＳａｖｅ」を通知し、ＡＰＬ２８
にＳＡＶＥハンドルを発行する。ＪＤＭ２５では、ＢＯ
Ｘファイル２７に記述されている識別ファイルから、論
理パスを解析し、ＢＯＸ２３における実ファイルの保存
可能状態を確認し、実ファイルのトランザクションを用
意する。

【００３０】ＩＤＳ２２では、ＤＡＭ２１からの「Ｒｅ
ａｄｙＳａｖｅ」の通知を受けると、エリア／内部状態
のトランザクションを用意すると共に、必要な処理を実
行を行う。例えば、文書情報ＩＤＳの場合は総編集時間
を計算し、ログＩＤＳの場合には保存開始ログを記録す
る。ＩＤＳによる処理にの実行結果は、ＤＡＭ２１、Ｊ
ＤＭ２５を介して、本体文書等に対応するＢＯＸ２３に
保存される。すなわち、ＢＯＸ２３では、文書エリアの
トランザクションを用意し、文書エリアの保存を行う。
保存の実行については、ＡＰＬ２８による実ファイルア
クセスが行われ、次の保存の終了が行われる。

【００３１】図１１は保存の終了の流れを表したもので
ある。ＡＰＬ２８から「ＦｉｎｉｓｈＳａｖｅ」が通知
されると、ＤＡＭ２１は、本体文書等のファイルの保存
終了のために、ＪＤＭ２５を呼び出すと共に、内部状態
のトランザクションを終了すると共に、本体文書等に設
定されているＩＤＳ全てに「ＦｉｎｉｓｈＳａｖｅ」を
通知する。ＪＤＭ２５では、ＢＯＸファイル２７に記述
されている識別ファイルから、論理パスを解析し、ＢＯ
Ｘ２３における実ファイルのトランザクションを終了す
る。ＩＤＳ２２では、ＤＡＭ２１からの「Ｆｉｎｉｓｈ
Ｓａｖｅ」の通知を受けると、エリア／内部状態のトラ
ンザクションを終了する。これにより、ＤＡＭ２１、Ｊ
ＤＭ２５を介して、ＢＯＸ２３でも、文書エリアのトラ
ンザクションを終了する。

【００３２】以上説明したように、本実施例では、ＡＰ
Ｌ２８からの本体文書等の取り出しを管理するＤＡＭ２
１と、ＢＯＸ２３へのデータ格納、取り出しを管理する
ＪＤＭ２５と、ファイルの選択情報を管理するＩＤＳと
を、ＡＰＬ２８から分離したので、ＤＡＭ２１、ＩＤＳ
２２、ＪＤＭ２５を、複数の異なるＡＰＬ２８で共通し
て利用することができる。また、ＢＯＸ２３からのデー
タの格納と取り出しを管理するＪＤＭ２５を設けたの
で、ＯＳのファイルシステムにより規定される物理的な
ディレクトリ構造やファイル名に制約されることなく、
ユーザは論理的なディレクトリ構造、ファイル名を利用
することができる。さらに、本体文書等のファイルの選
択条件を管理するＩＤＳ２２、およびアプリケーション
ＵＩ２６を設けたので、ＡＰＬ２８がファイルの選択条
件を規定するのではなくユーザによる自由な指定が可能
になる。

【００３３】

【発明の効果】本発明の文書情報管理システムによれ
ば、本体文書等に関連するひとまとまりのタスクを一体
的に管理することが可能になる。

【図面の簡単な説明】

【図１】本発明の文書情報管理システムにおける一実施
例のシステム構成図である。

【図２】標準ＢＯＸに付加されるＣＤＦの構造図であ
る。

【図３】各ＢＯＸ間の管理機能の利用状態の説明図であ
る。

【図４】ＪＤＭによる処理の流れを示す説明図である。

【図５】文書情報ＩＤＳとＢＯＸを説明する説明図であ
る。

【図６】ＤＡＭによる処理の流れを示す説明図である。

【図７】本体文書等の新規作成時の流れを示す説明図で
ある。

【図８】ＡＰＬ側から、ファイルを読み込む際のファイ
ル選択画面を示す説明図である。

【図９】本体文書等の読み込み時の流れを示す説明図で
ある。

【図１０】本体文書等の保存開始時の流れを示す説明図
である。

【図１１】本体文書等の保存終了時の流れを示す説明図
である。

【図１２】従来のＯＳ、および文書管理アプリケーショ
ンソフトによる、本体文書等のファイル管理システム構
成を示す説明図である。

【符号の説明】

２１ ＤＡＭ ２２ ＩＤＳ ２３ ＢＯＸ ２３１ 標準ＢＯＸ ２３２ 各種ＢＯＸ ２５ ＪＤＭ ２６ ファイルＵＩ ２７ ＢＯＸファイル ２８ ＡＰＬ

Claims (1)

【特許請求の範囲】
1. 【請求項１】 計算機システム上のアプリケーションか
   ら処理対象とするファイルを選択するための情報を管理
   するシステムであって、 文書管理に必要な各種の補助データを、ディレクトリ構
   築のためのデータベースとして管理する複数の管理部
   と、 これら各管理部に付随して設けられ、文書ファイルの選
   択に必要な補助データが、そのデータ内容に応じた管理
   部に格納される補助データ格納領域と、 アプリケーションからの要求内容を解釈する要求解釈部
   と、 この要求解釈部の解釈内容に応じて、前記管理部を選択
   する選択部と、 この補助データ管理部で選択された補助データに対し
   て、前記要求解釈部の解釈内容に応じた各種の処理を選
   択して実行するする処理選択実行部とを具備することを
   特徴とする文書情報管理システム。