JP2000090074A - ドキュメントの管理方法 - Google Patents

Abstract

(57)【要約】 【課題】 アプリケーションの非動作時においてもドキ
ュメントの状態および挙動を制御可能にする。 【解決手段】 ドキュメントに付加されたプロパティに
基づいて、ドキュメントを整理、保管、および検索する
ドキュメント管理システムを提供する。プロパティ付加
メカニズム１２５によって、アプリケーション１１５は
ドキュメント１１０に任意の静的プロパティおよび動的
プロパティ１４０を付加できる。この動的プロパティ１
４０は実行可能なコードを含み、このコードはドキュメ
ント管理機能１８５を実行して、トリガイベントに応答
してドキュメントの状態および挙動を制御する。このよ
うにして、ドキュメントの状態および挙動が、ユーザに
提供され、アプリケーションの動作／非動作に拘わらず
正確に維持される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ドキュメント管理
方法に関する。本発明は、ドキュメントのアプリケーシ
ョンが動作していない際においてドキュメントの状態お
よび挙動を制御するために、ドキュメントのアプリケー
ションがドキュメントにプロパティを付加できるように
するシステムおよび方法に対する特定のアプリケーショ
ンを見出すものであり、特定の参考文献を用いて本発明
を説明する。

【０００２】

【従来の技術および発明が解決しようとする課題】発明
者らは、ユーザとコンピュータとの間の多数の対話が、
非常に多くの電子ドキュメント（文書）からの情報の保
管、ファイリング、整理、および検索などのドキュメン
ト管理に関連することを認識している。これらのドキュ
メントは、ローカルディスク、ネットワークシステムの
ファイルサーバ、電子メールのファイルサーバ、ワール
ドワイドウェブ、または他の様々な場所に存在する。現
代の通信配布システムは、ユーザのドキュメント空間内
に組み込むことができるドキュメントの流れを大いに増
大させる効果を有しているため、蓄積されたドキュメン
トを見たり対話したりするための一層優れたツールに対
する要求が増大している。

【０００３】ドキュメント空間を整理する最も一般的な
ツールは、階層保管システムとして知られる単一の基本
的なメカニズムに依存している。この階層保管システム
では、ドキュメントはディレクトリまたはフォルダ内に
存在するファイルとして取り扱われており、これらのデ
ィレクトリまたはフォルダ自体は他のディレクトリ内に
含まれており、これによりドキュメント空間の対話のた
めの構造を提供する階層が形成されている。ディレクト
リ階層内のそれぞれのディレクトリは、一般に多数の個
別のファイルを含むことになる。一般的に、ファイルや
ディレクトリは、ネットワークを経由して共有化される
大きな保管容量の中で、英数字の呼び名が与えられる。
そのようなネットワークでは、個々のユーザには、特別
なディレクトリが割り当てられる。

【０００４】サブディレクトリ内に配置されたファイル
は、複合のパスネームが割り当てられる。例えば、文字
列D:\TREE\LIMB\BRANCH\TWIG\LEAF.FILは、ファイルLEA
F.FILの位置を記述することができ、このファイルLEAF.
FILの直接のディレクトリはTWIGであり、文字Ｄで識別
されるドライブ上の深いファイル階層に位置している。
それぞれのディレクトリ自体は、ファイル名、サイズ、
位置データ、およびファイル作成または更新の日時を含
むファイルである。

【０００５】ファイルシステムにおけるナビゲーション
は、大きくとらえると、ファイル階層上にマップされて
いる語義構造（semantic structures）におけるナビゲ
ーションとして考えることができる。そのようなナビゲ
ーションは、通常はブラウザやダイアログボックスを用
いて達成される。このため、ユーザがファイルシステム
内を動き回ってファイル（LEAF.FIL）を得る場合、この
動きは、１つのファイルまたはフォルダから他への動き
としてだけではなく、徐々に小さな位置に集束するドキ
ュメントの特徴を利用した検索手順として、見ることが
できる。階層はファイル整理に利用可能なほぼ唯一のメ
カニズムであるため、検索の構造はファイルシステムに
より提供される階層上にマップされる。しかしながら、
ドキュメントとファイルは同じものではない。

【０００６】ファイルはディレクトリによってグループ
化されるので、単一のドキュメントを内容の異なるいく
つかのグルーピングで関連付けることは厄介である。デ
ィレクトリ階層は、階層の各ノードに配置されたアクセ
スコントロールによって、ドキュメントへのアクセスを
コントロールするためにも使用される。このことはファ
イルアクセスを一人または数人にのみ許可することを困
難にする。本発明では、種々のドキュメントの集合にお
ける帰属関係を含むドキュメント固有の識別をそのプロ
パティ（特性）から分離することによって、これらの問
題を解消する。

【０００７】従来の他の欠点として、現存の階層ファイ
ルシステムが「単一の相続」構造を有する点があげられ
る。特に、ファイルは一度に一つの場所にのみ存在可能
とされるため、語義構造の中では一つの場所のみしか占
有できない。リンクおよびエイリアスの使用は、そのよ
うな制限を改良するための試行である。従って、ファイ
ルの整理が必要な構造についてのユーザの構想が時間の
経過につれて変化する間に、上述した階層は固定され強
固になってしまう。個々のファイルをそのような構造内
に移動することはかなり簡単な仕事ではあるが、ファイ
ルの大きなセットの再整理は、非常に複雑で、効率が悪
く、かつ時間がかかる。上述したことから、現存のシス
テムは、時間と共に変化するカテゴリーに基づいてファ
イル構造を変化させるというユーザの要求に指向してい
ないことが分かる。ある時点では、ユーザはプロジェク
トに関してドキュメント空間を整理したいと思うことが
あり、一方将来のある時期には、このユーザは時間およ
び／またはドキュメント内容に従って構成を生成したい
と希望することがあるかもしれない。厳密な階層構造で
は、シームレスな手法による複数の観点に対するドキュ
メント管理が実施されないため、ドキュメント検索の効
率が悪化してしまう。

【０００８】また、現存のファイルシステムは、ドキュ
メントの保管および検索に対して単一のモデルしかサポ
ートしていない。このことは、ドキュメントはその作成
者がドキュメントに与えた構造または構想に従って検索
されることを意味する。他方、作成者ではないユーザ
は、ドキュメントが保管された方法とは異なる構想すな
わちグルーピングに従って、ドキュメントを検索するこ
とを希望することがある。

【０００９】さらに、ドキュメント管理は演算力を有す
る装置上で行われるので、ドキュメントの整理を支援す
るためにこの演算力を利用できるという利点がある。例
えば、ドキュメントにスペルチェッカのプロパティを付
けることによって、ドキュメントは、要求しているアプ
リケーションに戻される内容が正確に書かれるように、
ドキュメントの読取り動作が拡張される。

【００１０】

【課題を解決するための手段】本発明は、アプリケーシ
ョンによってドキュメントを管理する方法を企図してい
る。この方法は、アプリケーションに従ってドキュメン
トに対してドキュメント管理機能を実行する実行可能な
コードを含む動的プロパティを、アプリケーションによ
って前記ドキュメントに付加するステップと、トリガイ
ベントに応答して、前記ドキュメントに対する前記ドキ
ュメント管理機能を実行するために動的プロパティの実
行可能なコードを呼び出すステップと、を備える。

【００１１】本発明の別の態様によれば、状態および挙
動を有するドキュメントを管理する方法が示されてい
る。この方法は、ドキュメントアプリケーションに従っ
て前記ドキュメントの状態および挙動を制御するための
少なくとも一つの管理機能をドキュメントアプリケーシ
ョンによって維持するステップと、前記ドキュメントの
状態および挙動を制御するための実行可能なコードを含
むドキュメントに対する管理機能を前記ドキュメントア
プリケーションによって付加するステップと、トリガイ
ベントに応答して、前記管理機能の実行可能なコードが
実行されるように、トリガイベントを管理機能に割り当
てるステップと、前記ドキュメントアプリケーションが
実行されていない場合、前記トリガイベントに応答し
て、ドキュメントの状態および挙動を制御するために前
記管理機能を起動するステップと、を備えている。

【００１２】この方法の一層限定された態様に注目する
と、一つの前記ドキュメントと他の前記ドキュメントと
の間の関係を作るステップと、前記実行可能なコードが
前記関係の状態および挙動を制御するようにそのドキュ
メントに対して前記管理機能が付加された前記関係を管
理するステップと、がさらに含まれている。

【００１３】

【発明の実施の形態】本発明を一層詳細に説明する前
に、説明の中で使用する用語をここにまとめる。以下に
定義を示す。

【００１４】動作（Action）：プロパティの挙動部分。

【００１５】動的プロパティ（Active Property）：ド
キュメント管理システム内でドキュメントを変更するた
めあるいは別の変更を行うためのいずれかのために、そ
のコードが演算力の使用を許されるプロパティ（特
性）。

【００１６】任意の（Arbitrary）：ドキュメントに何
らかのプロパティを提供する能力。

【００１７】基本ドキュメント（Base Document）：ド
キュメントの本質的なビットに対応する。ドキュメント
ごとに基本ドキュメントは一つのみである。ドキュメン
トの内容を決定し、ドキュメントのプロパティを含むこ
とができ、またドキュメントに対する全プリンシパル
（後述）の見解の一部である。

【００１８】基本プロパティ（Base Properties）：基
本ドキュメントに関連する固有のドキュメントプロパテ
ィ（特性）。

【００１９】ビットプロバイダ（Bit Provider）：基本
ドキュメントの特別なプロパティ。読取り動作や書込み
動作を行って、ドキュメントに内容を提供する。ドキュ
メントの種々のバージョンまたは内容を暗号化したバー
ジョンの読み込み（fetching）など別の動作を行うこと
もできる。

【００２０】ブラウザ（Browser）：ユーザがドキュメ
ントを配置したり整理することを許可するユーザインタ
ーフェース。

【００２１】群（Collection）：他のドキュメントをそ
の内容として含むドキュメントの形式。

【００２２】合成ドキュメント（Combined Documen
t）：群および内容を含むドキュメント。

【００２３】内容（Content）：手紙の中の文字あるい
は電子メールのメッセージの本文など、ドキュメント内
に含まれる核心情報。

【００２４】内容ドキュメント（Content Document）：
内容を有するドキュメント。

【００２５】分散型（Distributed）：異なるシステム
（すなわち、ファイルシステム、ＷＷＷ、電子メールサ
ービスなど）内のドキュメントの保管をユーザには分か
らない方法でコントロールするシステムの能力。システ
ムは複数の保管場所に配置されたドキュメントを、ドキ
ュメントの内容が保管されている場所についての知識を
持っていることをプリンシパルに要求せずに、プリンシ
パルに提供することを許可する。

【００２６】ＤＭＳ：ドキュメント管理システム。

【００２７】ドキュメント（Document）：これは特定の
内容およびこの内容に付加された何らかのプロパティを
参照する。参照された内容は、直接参照でも間接参照で
も良い。ＤＭＳの最小要素である。４つのタイプのドキ
ュメント、即ち、群、内容ドキュメント、内容なしのド
キュメント、および合成ドキュメントがある。

【００２８】ドキュメントハンドル（Document Handl
e）：全てに共通の表示態様（view）またはあるプリン
シパルの表示態様のいずれかの、ドキュメント上の特定
の表示態様に対応する。

【００２９】ドキュメントＩＤ（DocumentID）：各基本
ドキュメントに対する独特な識別子。参照ドキュメント
は、その指示物からドキュメントＩＤを引く継ぐ。ドキ
ュメントの同一性は、このように参照ドキュメントの参
照物と基本ドキュメントとの間を接続することによって
確立される。論理的に、単一のドキュメントは基本ドキ
ュメントであると共にそれを参照する参照ドキュメント
である。

【００３０】カーネル（Kernel）：ドキュメント上のす
べての動作を管理する。プリンシパルは１つ以上のカー
ネルを持つことができる。

【００３１】マルチプリンシパル（Multi-Principa
l）：各プリンシパルのプロパティが異なる基本ドキュ
メント上に自分自身のプロパティのセットを持つための
複数のプリンシパルについての能力。

【００３２】通知（Notification）：プロパティおよび
外部装置が、ＤＭＳ内の他の場所で発生する動作および
イベントを発見することを可能にする。

【００３３】内容なしのドキュメント（No Content Doc
ument）：プロパティのみを含むドキュメント。

【００３４】既製のアプリケーション（Off-the-Shelf
Applications）：現在存在するオペレーティングシステ
ムが供給するプロトコルおよびドキュメント保管メカニ
ズムを利用する現存のアプリケーション。

【００３５】プリンシパル（Principal）：ドキュメン
ト管理システムの「ユーザ」。ドキュメント管理システ
ムを利用するそれぞれの人または物はプリンシパルであ
る。人のグループもプリンシパルになり得る。ドキュメ
ント上の各プロパティをプリンシパルに関係付けること
ができるので、プリンシパルが中心となる。これにより
異なるプリンシパルが、同じドキュメント上で異なる配
景を持つことができる。

【００３６】プロパティ（Property）：内容に付加でき
る情報または挙動のビット。内容にプロパティを加えて
も、内容の同一性は変化しない。プロパティはドキュメ
ント上に配置できるタグであり、各プロパティは名前と
値（および任意に呼び出し可能な一組の方法）とを有す
る。

【００３７】プロパティ発生器（Property Generato
r）：プロパティをドキュメントの内容から引き出すた
めの特別な場合のアプリケーション。

【００３８】参照ドキュメント（Reference Documen
t）：ドキュメントの１つのプリンシパルの表示態様に
対応する。基本ドキュメントを参照する（参照ドキュメ
ントＡは基本ドキュメントＢを参照する）と共に、一般
に別のプロパティも含む。参照ドキュメントにより付加
されたプロパティは、その参照のみに属し、別のプリン
シパルがこれ等のプロパティを見るためには、はっきり
とそれらのプロパティを要求する必要がある。従って、
プリンシパルがその参照ドキュメントを通して見る表示
態様は、（基本ドキュメントを通る）ドキュメントの内
容であり、また（参照および基本ドキュメントの両方
の）プロパティのセットである。基本ドキュメントの所
有者でさえ、その基本ドキュメントに対して参照ドキュ
メントを持つこともでき、所有者はこの基本ドキュメン
トにドキュメントの個人的なプロパティを配置する。こ
の個人的なプロパティはドキュメントの本質的な部分と
考えるべきではなく、また他のすべてのプリンシパルの
表示態様の中に配置すべきではない。

【００３９】空間（Space）：プリンシパルが所用する
ドキュメント（基本または参照）のセット。

【００４０】静的プロパティ（Static Property）：ド
キュメントに関係する名前−値の対。動的プロパティと
は異なり、静的プロパティには挙動がない。ドキュメン
トについての検索可能なメタ−データ（meta-data）情
報を提供する。

【００４１】序文従来の技術の部分で説明したように、
ファイルシステムがファイルを管理するために提供する
構造は、それによってユーザがドキュメントを整理しま
たドキュメントと対話する構造になる。しかしながら、
ドキュメントとファイルは同じものではない。本発明
は、ドキュメントに関連するプロパティの管理を、ドキ
ュメントの内容の管理から分離するという直接的な目標
を有している。このため、ユーザ指定のドキュメントの
プロパティは、このドキュメントが保管されている場所
ではなく、ドキュメントの消費者すなわちドキュメント
のユーザの近くで管理される。ユーザプロパティの管理
をドキュメントコントロール自体から分離することによ
り、ドキュメント管理のコントロールを、閉鎖したファ
イルシステムという概念からユーザ中心の方法論に移す
ことができる。

【００４２】図１は、ドキュメントが階層構造によって
記載されたそれらの位置に従って整理される階層保管シ
ステムと、ドキュメントがそれらのプロパティ（例え
ば、作成者＝dourish、タイプ＝paper、ステータス＝dr
aft、など）に従って整理される本発明との間の差異を
示している。これは、ドキュメントが例えある位置から
他の位置に移動したとしても、プロパティを保持してお
り、またプロパティの割り当ては良好な細分性を持つこ
とができることを意味している。

【００４３】プロパティを本発明のドキュメント管理シ
ステム内に統合するためには、プロパティは、動作の結
果を変更する能力ならびに別の動作を行う能力の両方を
備えて、内容および／またはプロパティのコンピュータ
システムの読取り／書込み経路の中に存在させる必要が
ある。この構想の概要を図２に示す。図２では、ひとた
びユーザ（Ｕ）が動作要求（Ｏ）を発行すると、その動
作をオペレーティングシステム（ＯＳ）が実行する前
に、コールが本発明のドキュメント管理システム（ＤＭ
Ｓ）Ａに対してなされる。このためＤＭＳ（Ａ）は、本
発明の意図した構想を達成するように機能することがで
きる。これには、それ自身の動作要求（Ｏ'）を通して
オペレーティングシステム（ＯＳ）と対話するＤＭＳ
（Ａ）が含まれる。ひとたび動作要求（Ｏ'）が完了す
ると、結果（Ｒ）がＤＭＳ（Ａ）に戻され、今度はＤＭ
Ｓ（Ａ）が結果（Ｒ'）をユーザ（Ｕ）に渡す。

【００４４】以上、基本的な構想を説明したので、本発
明の一層詳細な説明を以下に記載する。

【００４５】ドキュメント管理システム（ＤＭＳ）の構
成 図３は、本発明のドキュメント管理システム（ＤＭＳ）
Ａの構成を一層詳細に記載している。

【００４６】フロントエンド（front-end）コンポーネ
ントＢおよびバックエンド（back-end）コンポーネント
Ｃを備えて動作するように構成されたドキュメント管理
システム（ＤＭＳ）Ａが示されている。フロントエンド
コンポーネントＢには、ワードプロセッサアプリケーシ
ョン、メールアプリケーションその他等のようなアプリ
ケーション１０ａ〜１０ｎおよび１１ａ〜１１ｎが含ま
れる。いくつかのアプリケーションは、ＤＭＳ認識のア
プリケーション１０ａ〜１０ｎである。ＤＭＳ認識と
は、これらのアプリケーションが、保管、検索、および
ＤＭＳ（Ａ）と対話するためのＤＭＳプロトコルを理解
することを意味する。他のコンポーネントはＤＭＳ非認
識のコンポーネント１１ａ〜１１ｎである。ブラウザ１
２ａ（ＤＭＳ認識）および１２ｂ（ＤＭＳ非認識）は、
アプリケーションの特徴的な形態である。ＤＭＳ非認識
アプリケーション１１ａ〜１１ｎおよび１２ｂをＤＭＳ
（Ａ）と通信できるようにするために、フロントエンド
トランスレータ（翻訳機）１３が設けられる。

【００４７】同様に、バックエンドコンポーネントＣ
は、複数の保管場所１４ａ〜１４ｎを備えることがで
き、この保管場所においてドキュメントの内容が保管さ
れる。このような保管場所には、プリンシパルのコンピ
ュータのハードディスク、ファイルシステムのサーバ、
ウェブページ、動的なリアルタイムのデータ転送源、な
らびに他のデータ保管場所などを含めることができる。
保管場所１４ａ〜１４ｎからデータの内容を検索するに
は、例えばビットプロバイダ１６の様なビットプロバイ
ダを用いる。これらのビットプロバイダは、適切な保管
プロトコルを解釈する能力を備えている。

【００４８】プリンシパル１〜ｎはそれぞれ、例えばド
キュメント２０ａ〜２０ｎのようなドキュメントを管理
するための自分自身のカーネル１８ａ〜１８ｎを有す
る。ドキュメント２０ａ〜２０ｎは、対応するプリンシ
パル１〜ｎがそのドキュメント管理空間にもたらしたド
キュメントである。特に、それらは、プリンシパルが価
値があると見なしており、このため、そのプリンシパル
のドキュメントとして何らかの方法でマークされたドキ
ュメントである。このドキュメントは、例えば、プリン
シパルが作成したドキュメントであったり、プリンシパ
ルが送信または受信した電子メール、プリンシパルが見
つけたウェブページ、画像の連続した流れを発生する電
子カメラなどのリアルタイムの入力データ、またはＤＭ
Ｓのドキュメント空間にもたらされた他の何らかの形態
の（ビデオ、オーディオ、テキストなどを含む）電子デ
ータである。各ドキュメント２０ａ〜２０ｎは、配置さ
れた静的プロパティ２２および／または動的プロパティ
２４を有する。

【００４９】ドキュメント２０ａは、基本ドキュメント
であり、参照ドキュメント２０ｂ〜２０ｃによって参照
される。以下に一層詳細に説明するが、基本ドキュメン
ト２０ａは静的プロパティ２２および／または動的プロ
パティ２４を有すると共に基本プロパティ２６をも備え
ている。但しこの基本プロパティ２６は静的プロパティ
２２および／または動的プロパティ２４であってもよ
い。静的プロパティは「−」を付して示されており、動
的プロパティは「−○」を付して示されている。

【００５０】参照ドキュメント２０ｂ〜２０ｃは、基本
ドキュメント２０ａと対話するように構成されている。
基本ドキュメントおよび参照ドキュメントは両方とも、
静的プロパティ２２および／または動的プロパティ２４
を保持することができる。プリンシパル２，３が初めて
基本ドキュメント２０ａにアクセスする場合、対応する
参照ドキュメント２０ｂ〜２０ｃがカーネル１８ｂ〜１
８ｃのもとでそれぞれ作成される。参照ドキュメント２
０ｂ〜２０ｃは、それらの基本ドキュメント２０ａをは
っきりと識別するためにリンク２８および３０を記憶す
る。特に、本発明では、各基本ドキュメントはドキュメ
ントＩＤを付けて記憶される。このドキュメントＩＤは
そのドキュメント固有の識別子である。参照ドキュメン
ト２０ｂ〜２０ｃが作成される場合、それらは基本ドキ
ュメントの特定ドキュメントＩＤへのリンクを発生す
る。あるいはまた、プリンシパルｎが参照ドキュメント
２０ｃを参照する場合、プリンシパル３の参照ドキュメ
ント２０ｃへのリンク３２を備えた参照ドキュメント２
０ｎが作成される。このリンクによって（すなわち、そ
のドキュメントハンドル）、プリンシパルｎは、基本ド
キュメント２０ａの基本プロパティおよび共用参照プロ
パティは無論のこと、プリンシパル３がその参照ドキュ
メント２０ｃに付加した共用プロパティを見ることがで
きる。このことは連鎖形成の概念を説明している。

【００５１】前述した構成により、プリンシパル間のド
キュメントの共有および転送が可能になり、ドキュメン
トを整理するために必要な柔軟性が提供される。引き続
き図３を参照して、この点において、リンク２８〜３０
は一つのドキュメントから他へのリンクとして示されて
いるが、ＤＭＳ（Ａ）内の通信は一般にカーネル１８ａ
〜１８ｎ間の通信によって達成されることに注意すべき
である。このため、ＤＭＳ（Ａ）とフロントエンドコン
ポーネントＢまたはバックエンドコンポーネントＣのい
ずれかとの間の通信、あるいはＤＭＳ（Ａ）内のプリン
シパル間の通信が行われる場合、この通信はカーネル１
８ａ〜１８ｎを介して行われる。しかしながら、本発明
は他の通信構成とも同様に動作することを理解された
い。

【００５２】上述した構成を用いる場合、本発明のＤＭ
Ｓ（Ａ）は、ファイルまたはフォルダタイプの環境内の
ような厳密な階層内で操作することをプリンシパルに要
求しない。むしろ、ドキュメントに付加されたプロパテ
ィ２２，２４によって、プリンシパルが最も有効である
ことが分かる方法に従って、プリンシパルがドキュメン
トを検索し整理することを可能にする。

【００５３】例えば、プリンシパル１（カーネル１８ａ
の所有者）が内容付き基本ドキュメントを作成してＤＭ
Ｓ（Ａ）内に保管し、プリンシパル２（カーネル１８ｂ
の所有者）が自分自身の必要性のためにそのドキュメン
トを使用し整理したいと思う場合、プリンシパル２は参
照ドキュメント２０ｂ上にプロパティを配置できる。こ
れらのプロパティを配置することによって、プリンシパ
ル２は、プリンシパル１が考えるのとは異なる手法によ
り基本ドキュメントを検索できる。

【００５４】さらに、ブラウザ１２と対話することによ
って、プリンシパルは、選択されたプロパティを持つす
べてのドキュメントを要求するクエリを実行できる。よ
り具体的には、ユーザは存在するプロパティに対して要
求を行うクエリ言語を実行することができる。

【００５５】従って、本発明のポイントは、特定のプリ
ンシパルに対して適切な動作であってドキュメントの大
元の作成者の整理構造やさらに他のプリンシパルとは必
ずしも同等である必要がない動作が行われるように、異
なるプリンシパルによってプロパティが付加されるドキ
ュメント空間を、ＤＭＳ（Ａ）が管理することである。

【００５６】本発明の別の注目すべき態様は、プロパテ
ィを使用すると、ドキュメントに単一のマシン上に存在
するように要求する代わりに、ドキュメントの固有の同
一性をそのプロパティからすなわちプリンシパルの見方
から分離するので、ドキュメントは本質的に複数のマシ
ン上に存在できることである（基本ドキュメント２０ａ
はカーネル１８ａ〜１８ｎのすべてまたはいずれか１つ
に存在できる）。さらに、ドキュメントに関連するプロ
パティはプリンシパルが作成したドキュメントに従うの
で（例えば、カーネル１８ｂのドキュメント２０ｂ上の
プロパティは基本ドキュメント２０ａを参照できる）、
ドキュメント２０ｂのプロパティが論理的に基本ドキュ
メント２０ａに関連していたとしても、ドキュメント２
０ｂのプロパティはカーネル１８ｂ上で実行できる。す
なわち、ドキュメント２０ｂに関連する（基本ドキュメ
ント２０ａを参照する）プロパティがその動作によるい
かなる費用をも負担する場合、プロパティをドキュメン
ト上に配置したプリンシパルがプロパティを維持するの
で、これらの費用はカーネル１８ｂ（すなわち、プリン
シパル２）が負担する。

【００５７】本来のアプリケーションに対する支援 ＤＭＳドキュメントインターフェースは、Ｊａｖａオブ
ジェクトとしてドキュメントへのアクセスを提供する。
アプリケーションは、関連したパッケージをそれらのＪ
ａｖａコードにインポートし、また、ドキュメント、
群、およびプロパティにアクセスするために設けられた
ＡＰＩ（アプリケーションプログラムインターフェー
ス）にコーディングすることにより、このインターフェ
ースを利用することができる。これは、新しいＤＭＳ認
識アプリケーションを構築し、新しい対話モデルの実験
をするための標準的な手段である。（図３の）ＤＭＳの
ブラウザ１２は、ＤＭＳアプリケーションと見なすこと
ができ、このレベルにおいて構築される。ＤＭＳのドキ
ュメントインターフェースは、本願で説明する機能性
（例えば、群、ＷＷＷドキュメントへのアクセスなど）
を支援する特定のサブクラスを有して、ドキュメントお
よびプロパティのクラスを提供する。アプリケーション
は、例えば内容特定の可視化を用いて、ＤＭＳドキュメ
ントの直接視を可能とし、またはプロパティベースのド
キュメントサービスのバックエンドとしてＤＭＳを利用
する全体的に異なるインターフェースの提供を可能とす
る。

【００５８】既製のアプリケーションに対する支援 別のレベルのアクセスは、（図３のトランスレータ１３
などの）トランスレータを経由する。現在の実施形態に
おいては、ＮＦＳ（商標）プロトコルを実行するサーバ
は、トランスレータとして使用される。これは、純粋な
Ｊａｖａにおける本来のＮＦＳサーバの実行である。こ
のトランスレータ（すなわち、ＤＭＳＮＦＳサーバ）
は、すべてのＮＦＳのクライアントに対してＤＭＳのド
キュメント空間へのアクセスを提供する。すなわち、サ
ーバは例えばマイクロソフト ワード（商標）など現在
市販されているアプリケーションがＤＭＳドキュメント
を利用できるようにすること、またＰＣ上では、ＤＭＳ
はこれらのアプリケーションにとっては単に別のディス
クのように見えるが、ＵＮＩＸ（商標）のマシン上で
は、ＤＭＳ（Ａ）は標準的なネットワークのファイルシ
ステムのように見える。

【００５９】大事なことであるが、このトランスレータ
を経由して達成されることは、ＤＭＳ（Ａ）が既存また
は既製のアプリケーションに対して、内容およびプロパ
ティの読取り／書込み経路内に直接存在することであ
る。別の方法は、ワード（商標）などのアプリケーショ
ンによって、ＤＭＳ（Ａ）に適応するために変更できな
いような従来のファイルシステムに書き込まれたファイ
ルを後処理しようとすることである。そのかわり、これ
らのアプリケーションに対してファイルシステムのイン
ターフェースを直接的に提供することにより、内容およ
びプロパティの読取り／書込み経路上で関連するプロパ
ティを実行することができる。さらに、関連するプロパ
ティ（ドキュメントがいつ最後に使用または変更された
かを記録するプロパティ）は、継続して更新されること
が保証されている。アプリケーションがファイルシステ
ムの情報を使用するように書き込まれた場合にあって
も、ＤＭＳ（Ａ）はファイルシステムであるため、ＤＭ
Ｓのデータベースは更新される。

【００６０】ＤＭＳのデータベース層に対するそのイン
ターフェースの部分として、ＮＦＳはクエリメカニズム
へのアクセスを提供する。適切にフォーマットされたデ
ィレクトリ名は、クエリとして解釈され、これらのディ
レクトリ名はクエリによって戻されたドキュメントを
「含んでいる」ように見える。ＤＭＳはこのＮＦＳサー
ビスを提供するが、ＤＭＳは保管層ではない。ドキュメ
ントは実際に別の保管場所にある。しかしながら、ＮＦ
Ｓ層の使用により、各種の他の保管場所へのアクセスが
均一になる（そのため、ウェブ上で利用可能なドキュメ
ントは、ネットワーク化されたファイルシステム内のド
キュメントと同じ空間内にあるように見える）。この均
一性ならびに読取りおよび書込み経路内における存在に
よるドキュメントプロパティ随時更新能力の組み合わせ
により、ＮＦＳサービスは、公知のアプリケーションと
の統合の所望のレベルに対して価値のあるコンポーネン
トとなる。ＮＦＳプロトコルを実行するサーバ以外に他
のサーバも使用できることは理解されよう。

【００６１】プロパティの付加 図４は、選択したドキュメントにプロパティを付加する
ためのシステム全体を示す説明図である。具体例を示す
ために、２つのドキュメント１１０，１１２、およびこ
れらのドキュメントを処理するアプリケーション１１５
が示されている。ドキュメント管理システムＡは、管理
システムのプロトコルに基づいてドキュメントを配置し
検索する。好適な実施形態においては、ドキュメントは
階層上のパスやファイル名ではなく、ドキュメントのプ
ロパティに基づいて管理される。

【００６２】ドキュメント管理システムＡは、プロパテ
ィ付与メカニズム１２５を備える。このプロパティ付与
メカニズム１２５は、ドキュメント１１０に対して関連
リンク１３５により対応付けされるドキュメント参照１
３０内にプロパティを生成し、構成し、また付加する。
好適な実施形態においては、ドキュメント１１０は固有
のＩＤによって識別され、またドキュメント参照１３０
はこのドキュメントを同じ固有のＩＤを用いて参照す
る。プロパティ１５０は（横線によって示された）静的
プロパティと（円によって示された）動的プロパティと
を含む。静的プロパティは、ユーザに関連するドキュメ
ント上の単純な名前−値のペアであり、例えば、「発送
者＝Joe」または「題目＝特許応用」といった、アプリ
ケーションの状態を表すために使用できる。動的プロパ
ティ１４０は、名前−値を有し、またユーザが介入する
ことなしに動作またはサービスを自動的に実行する実行
可能なプログラムコードおよび／または命令を含み、ア
プリケーションの挙動を拡張するために使用できる。ド
キュメントは、静的プロパティおよび／または動的プロ
パティに基づいて、収集、探索、および検索することが
できる。プロパティは、１ドキュメント１ユーザごとに
別々に保持できる。

【００６３】動的プロパティ１４０は、ユーザが定義す
るトリガイベント（きっかけとなる事象）によって起動
されるように構成する。このトリガイベントは、システ
ム内の何らかの機能またはタイマによって開始される割
り当てられた如何なる動作またはイベントでも良い。例
えば、トリガイベントは、アプリケーション、システ
ム、別のドキュメント、別の動的プロパティ、タイマ、
またはユーザが望むあらゆるメカニズムによって開始可
能である。動的プロパティ１４０のドキュメント１１０
への付加により、このプロパティとドキュメントとの間
の関連が形成される。この関連は、ドキュメント１１０
の内容を表すデータの外部にある。従って、この関連
は、内容のタイプ、ドキュメントを生成するために使用
するアプリケーションのフォーマット、およびドキュメ
ント１１０の他の特性とは無関係である。

【００６４】ドキュメント１１０の内容は、ビットプロ
バイダ１６０によって制御される。このビットプロバイ
ダ１６０は、データの位置（例えば、ローカルディス
ク、ワールドワイドウェブ、カメラ、またはすべてのデ
ータ供給源）を識別する。この場合、内容は画像ファイ
ル１７０である。このビットプロバイダ１６０は、デー
タ源からのデータが合成されてドキュメント１１０の内
容が形成される方法を示し、このデータ源と通信するた
めの変換インターフェース、および内容を定義する他の
選択されたパラメータを含む。ドキュメント１１２はビ
ットプロバイダ１６２を含み、このビットプロバイダ１
６２は、テキスト１６５としてドキュメント１１２の内
容を形成するローカルディスクとインターフェースす
る。

【００６５】図４をさらに参照すると、アプリケーショ
ン１１５は、ドキュメントに付加できる動的プロパティ
になるように設計された１つ以上のファンクション（機
能）１８０を含む。これらのファンクション１８０は、
ドキュメントに対して管理機能を実行する実行可能なプ
ログラムまたはルーチンである。アプリケーションが動
作していないときに、このドキュメントにファンクショ
ン１８０が付加される。換言すると、アプリケーション
１１５は、ドキュメント１１０に対する動的プロパティ
として、ファンクション１８０の組から選択された管理
ファンクション（管理機能）１８５を付加する。この方
法においては、アプリケーション１１５がドキュメント
１１０を処理していない場合でも、アプリケーション１
１５は、ドキュメント１１０の状態および／または挙動
を制御する能力を有することになる。

【００６６】管理ファンクション１８５は動的プロパテ
ィ１４０として付加される。前述したように、トリガイ
ベントが発生すると、動的プロパティ１４０は管理ファ
ンクション１８５のコードを実行する。これらの管理プ
ロパティはアプリケーションが扱うドキュメントに限定
されることはなく、関連するどのような他のドキュメン
トにも付加できることに注意されたい。

【００６７】アプリケーション挙動の拡張 図５を参照する。具体例を示すために、テキスト１６５
が画像１７０をその本体にインポートするように、アプ
リケーション１１５がドキュメント１１０とドキュメン
ト１１２との間の関係を作成すると仮定する。アプリケ
ーション１１５がドキュメント１１２を生成して画像１
７０との関係を作成するので、アプリケーション１１５
が動作していない場合においてもこの関係を管理するた
めに、この関係の状態と挙動とは管理ファンクション１
８５へと伝達される。例えばオペレーション（操作）／
イベント２００のような割り当てられたトリガイベント
が発生すると、動的プロパティ１４０は管理ファンクシ
ョン１８５を開始させる。この場合、アプリケーション
１１５が動作していないときは、ドキュメント管理シス
テムＡはこのオペレーション／イベント２００を検出す
るために、システムをモニタする。ひとたびそれが検出
されると、ドキュメント管理システムＡはこのイベント
２００をドキュメント１１０に付加された動的プロパテ
ィと比較して、このイベント２００がトリガイベントで
あるかどうかを決定する。この場合は、イベント２００
は動的プロパティ１４０に対するトリガイベントである
ため、管理ファンクション１８５が実行される。管理フ
ァンクション１８５はドキュメント管理システムＡに対
して命令を与える。このドキュメント管理システムＡ
は、オペレーション／イベント２００がドキュメント１
１０に付加される手法を制御したり、トリガイベントに
応答して実行される命令の順序を制御したりする。言い
換えると、オペレーション／イベント２００はドキュメ
ント１１０に単に付加されるのではなく、管理ファンク
ション１８５のドキュメント管理ルールに従って付加さ
れる。これらのドキュメント管理ルールは、ドキュメン
ト１１０がアプリケーション１１５の希望あるいはそれ
がドキュメント１１２に対して有する要求に従って確実
に処理されるようにする。

【００６８】例えば、オペレーション／イベント２００
はユーザが実行する削除オペレーションであって、管理
ファンクション１８５がドキュメント１１０に加えられ
る削除オペレーションに応答してトリガされると仮定す
る。ユーザは、ドキュメント管理システムＡを介してフ
ァイルを検索しながら、画像ドキュメント１１０を捜し
出して、画像１７０がドキュメント１１２の一部を形成
することを知らずに削除オペレーションを開始する。ド
キュメント管理システムＡはこの削除オペレーションを
検出し、このオペレーションを行う前に、この削除オペ
レーションがドキュメント１１０に付加された動的プロ
パティに対するトリガイベントであるかどうかを決定す
る。この場合、この削除オペレーション２００はトリガ
イベントであり、管理ファンクション１８５が起動され
る。

【００６９】ひとたびトリガされると、管理ファンクシ
ョン１８５は、事前に定義された命令のセットに従っ
て、ドキュメント１１０に対する削除オペレーション２
００を実行しまたそれを行うことに関連するようにな
る。例えば、「それらの命令が他のドキュメントの一部
のファイルを削除している」，「この削除オペレーショ
ンは禁止されることがある」，あるいは「ドキュメント
１１０は元のファイルが削除される間にドキュメント１
１２に対してコピーされることがある」といった警告
が、ユーザに与えられることがある。当業者は、生成す
るアプリケーションが動作してない場合にあっても、管
理ファンクション１８５がプログラムされトリガイベン
トに基づいてドキュメントを制御するいかなる管理機能
も提供可能とされることを、理解できるであろう。言う
までもなく、必要に応じて、この管理ファンクションは
アプリケーションが動作している場合においても実行さ
れるようにプログラムされ得る。

【００７０】他の例の場合、ドキュメント１１２のテキ
スト１６５は、画像ドキュメント１１０のＯＣＲ（オブ
ジェクト文字認識）バージョンであることを意図すると
仮定する。管理ファンクション１８５はドキュメント１
１０に付加されて、編集操作によってトリガされるよう
に構成される。編集操作に応答して、管理ファンクショ
ン１８５は、画像１７０に対してなされた変更に基づい
てテキスト１６５の内容を更新することにより、ドキュ
メント１１２の状態が確実に正しくなるようにする。無
論、アプリケーション１１５が動作している場合は、こ
の管理はアプリケーション１１５が実行できる。しかし
ながら、アプリケーションは動作していないので、管理
ファンクション１８５はアプリケーション１１５に対し
て特定の機能性を発揮するように構成される。即ち、編
集操作２００が行われると、管理ファンクション１８５
は編集の制御を起動する。逆に、もし管理ファンクショ
ン１８５が存在しない状態で画像ドキュメント１１０に
編集操作が行われると、テキスト１６５への依存関係に
おいてこの操作によりエラーが発生することをユーザは
知らないまま、画像１７０の内容が修正されてしまうこ
とになる。上述したように、管理ファンクション１８５
は、選択されたイベントに応答してドキュメントの状態
および／または挙動を制御するどのような機能も実行す
るようにプログラムされ得る。

【００７１】本発明では、アプリケーションはそれ自体
の一部を１つのドキュメントおよび任意の数の従属する
ドキュメントの中に挿入するメカニズムを備えており、
このことは、アプリケーションが存在しない際において
ドキュメントやその要求を管理するために、互いに各種
の関係を持つことができる。このように、アプリケーシ
ョンを実行させずに、ドキュメントの状態と挙動に対し
てユーザはアクセスすることができる。さらに、ドキュ
メントの状態と挙動を、アプリケーションによって作成
されドキュメントに対して動的プロパティとして付加さ
れた事前に定義されたルールに基づいて、正確に維持お
よび変更することができる。

【００７２】好ましい実施形態を参照して本発明を説明
してきた。この明細書を読みかつ理解すれば、修正や変
更が他に生ずることは明白である。添付した特許請求の
範囲またはそれと同等なものの範囲にある限り、本発明
にはそのようなすべての修正や変更が含まれる。

【００７３】

【発明の効果】以上、説明したように、本発明によれ
ば、ドキュメントに対する動的プロパティの付加によ
り、ドキュメントのアプリケーションの非動作時におい
てもドキュメントの状態および挙動を制御することがで
きるので、容易，迅速かつ正確にドキュメントの管理を
行うことができる。

【図面の簡単な説明】

【図１】 本発明のプロパティの構想と比較した階層保
管メカニズムを示す説明図である。

【図２】 ユーザとオペレーティングシステムとの間の
通信チャネル内に挿入された本発明にかかるドキュメン
ト管理システムのブロック図である。

【図３】 コンピュータシステムで実行される本発明に
かかるドキュメント管理システムの説明図である。

【図４】 本発明にかかるドキュメント管理方法に基づ
いてドキュメントを管理するプロパティがアプリケーシ
ョンにより付加されるシステム概略構成を示す説明図で
ある。

【図５】 トリガイベントに応答した本発明にかかるド
キュメント管理方法の概略を示す説明図である。

【符号の説明】

Ａ ドキュメント管理システム、Ｂ フロントエンドコ
ンポーネント、Ｃ バックエンドコンポーネント、１０
ａ〜１０ｎ，１１ａ〜１１ｎ アプリケーション、１２
ブラウザ、１３ フロントエンドトランスレータ、１
４ａ〜１４ｎ保管場所、１６ ビットプロバイダ、１８
ａ〜１８ｎ カーネル、２０ａ〜２０ｎ ドキュメン
ト、２２ 静的プロパティ、２４ 動的プロパティ、２
６ 基本プロパティ、２８，３０，３２ リンク、１１
０，１１２ ドキュメント、１１５ アプリケーショ
ン、１２５ プロパティ付加メカニズム、１３０ ドキ
ュメント参照、１３５ 関連リンク、１４０ 動的プロ
パティ、１５０ プロパティ、１６０，１６２ ビット
プロバイダ、１６５ テキスト、１７０ 画像、１８０
ファンクション、１８５ 管理ファンクション、２０
０ オペレーション／イベント。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジェームズ ピー ドーリッシュ アメリカ合衆国 カリフォルニア州 サン フランシスコ ドロレス ストリート 1040 ＃105 (72)発明者 ワレン ケイ エドワーズ アメリカ合衆国 カリフォルニア州 サン フランシスコ グエレロ ストリート 1527 (72)発明者 アンソニー ジー ラマルカ アメリカ合衆国 カリフォルニア州 レッ ドウッド シティ コネティカット ディ アール 1727 (72)発明者 ジョン オー ランピング アメリカ合衆国 カリフォルニア州 ロス アルトス エバ アベニュー 1299 (72)発明者 マイケル ピー サリスブリー アメリカ合衆国 カリフォルニア州 マウ ンテン ビュー シャワーズ ドライブ イー254 49 (72)発明者 ダグラス ビー テリー アメリカ合衆国 カリフォルニア州 サン カルロス タスカー レーン 23 (72)発明者 ジェームズ ディー ソーントン アメリカ合衆国 カリフォルニア州 レッ ドウッド シティー ベイ ロード 3312

Claims (3)

【特許請求の範囲】
1. 【請求項１】 アプリケーションによるドキュメントの
   管理方法であって、 アプリケーションに従ってドキュメントに対してドキュ
   メント管理機能を実行する実行可能なコードを含む動的
   プロパティを、アプリケーションによって前記ドキュメ
   ントに付加するステップと、 トリガイベントに応答して、前記ドキュメントに対する
   前記ドキュメント管理機能を実行するために動的プロパ
   ティの実行可能なコードを呼び出すステップと、を備え
   ることを特徴とするアプリケーションによるドキュメン
   トの管理方法。
2. 【請求項２】 状態および挙動を有するドキュメントの
   管理方法であって、 ドキュメントアプリケーションに従って前記ドキュメン
   トの状態および挙動を制御するための少なくとも一つの
   管理機能をドキュメントアプリケーションによって維持
   するステップと、 前記ドキュメントの状態および挙動を制御するための実
   行可能なコードを含むドキュメントに対する管理機能を
   前記ドキュメントアプリケーションによって付加するス
   テップと、 トリガイベントに応答して、前記管理機能の実行可能な
   コードが実行されるように、トリガイベントを管理機能
   に割り当てるステップと、 前記ドキュメントアプリケーションが実行されていない
   場合、前記トリガイベントに応答して、ドキュメントの
   状態および挙動を制御するために前記管理機能を起動す
   るステップと、を備えることを特徴とするドキュメント
   の管理方法。
3. 【請求項３】 一つの前記ドキュメントと他の前記ドキ
   ュメントとの間の関係を作るステップと、 前記実行可能なコードが前記関係の状態および挙動を制
   御するようにそのドキュメントに対して前記管理機能が
   付加された前記関係を管理するステップと、をさらに含
   むことを特徴とする請求項２に記載のドキュメントの管
   理方法。