JP2004086893A - ファイル・プレースホルダーを備えた電子ファイリングシステム - Google Patents

Abstract

【課題】見込みファイルを電子ファイリングシステムで処理する場合、予約やファイルの入れ換えを大量の紙文書に対して実行するには不都合がある。
【解決手段】電子文書ファイリングシステムにおいて、プレースホルダー・オブジェクトを用いて、まだ存在していないが、システムにより明らかに見込まれる文書ファイルの明示的な表現を提供する。プレースホルダー・オブジェクトは実ファイリングシステム・オブジェクトであってよく、他の任意のファイリングシステムのファイリング・オブジェクトと同じ方法、ファイルメタデータ等のファイリングシステムデータを含んでいてよい。メタデータは、ファイリングシステム、メッセージ交換システム、ワークフローシステム、および文書スキャン・システム等、文書ファイル用に見込まれるデータ源に関連付けることができる。
【選択図】図１

Description

　本発明は電子ファイリングシステムおよびその運用方法に関し、より具体的にはテキスト文書、グラフィカル文書、または文書のキャプチャ画像等、文書を電子的に表現するファイリングシステムに関する。

　コンピュータ利用による、または電子的なファイリングシステムにおいて、ファイルが将来到着（又は挿入）することが見込まれるが、現時点では目的のために（書類の到着遅れにより）利用できない状況が多々ある。

　一例として、例えば抵当申請書類の取り扱いを処理システムがある。資産の抵当申請に際して通常、申請用紙の処理が行なわれ、次いで他の書類も求められるが、それらが届くのは後になる場合がある。このような書類には例えば、資産の調査書類、申請者の雇用者への照会、給与明細の写し、与信審査書類、または保証人からの書面による保証が含まれよう。さらに後になるが、同じく不可欠な書類として、資産取引の写し、または資産の権利証書の写しが含まれていてもよい。

　別の例として、月次報告等、定期的な文書の作成が求められるケースが挙げられる。

　さらに別の例として、返信を要求するメールやメッセージが送られるケースが挙げられる。送信メッセージ文書を電子形式で保存し、メッセージへの返信を明示的に求める場合がある。これは文書を取り扱うシステム、または電子メールシステム等、電子メッセージ交換システムにあてはまるであろう。

　さらに別の例として、ペンディング中の仕事の状態を監視するワークフローシステムがある。結果的に生じたファイルは、ペンディング中の仕事が完了したならば、仕事の状態を更新すべくワークフローシステムへの入力が見込まれる。

　従来、ファイリングシステムは自動スケジューリングシステムに備忘項目を設定することにより、見込作業、例えば将来作成される文書や返信を取り扱う。例えば、備忘項目は、文書やタスクの完了が見込まれるカレンダ備忘であってもよい。従ってこのようなシステムは、見込ファイルの督促手段としてカレンダースケジュールを利用する典型的な手操作によるオフィスシステムと同等のものである。

米国特許第５９３０８０１号明細書 米国特許第６２６６６８２号明細書 米国特許第６３０８１７９号明細書 米国特許第６３２４５５１号明細書 米国特許第６２６６６７０号明細書 米国特許第６２４０４２９号明細書 米国特許第６２６９３８０号明細書 米国特許第６２５３２１７号明細書 欧州特許出願０９８６００９　Ａ２

　関連分野において、ユーザーが紙文書をスキャナで読み込んで文書ファイリングシステムへ入力する際に通常利用せざるを得ない、単純な現行方式にはさらに問題がある。これは一般に、紙文書のデジタル画像を取り込むためにユーザーが手操作でスキャン・アプリケーションを実行し、次いで手操作で（取り込まれた画像をテキストに変換する光学式文字認識（ＯＣＲ）等の）任意の変換ユーティリティを制御して、取得された画像を変換する。これが完了したならば、ユーザーは手操作でファイルを文書ファイリングシステムに保存またはアップロードする必要がある。スキャン入力した後で、文書ファイルには特定のファイル名が割り当てられる。しかし事前（すなわちスキャン入力以前）に特定のファイル名を割り当てることは通常不可能である。従って従来技術では相当なユーザー入力作業と時間を要し、大量の紙文書に対して繰り返し実行するには不都合である。

　従って、見込ファイルを電子ファイリングシステムで処理する方法の改良が望まれる。

　本発明に基づき、プレースホルダー（空ファイル入れ）を用いて、現時点では存在が認識されていないが、将来は明らかに見込まれるファイルの明示的な表現を提供する。

　一実施の形態において、プレースホルダーは他の任意のファイルやフォルダーと同様に、ファイリングシステム内のファイリングシステム・オブジェクトである。ファイリングシステムは、例えばオブジェクトが階層的に構成されている階層型であっても、あるいはオブジェクトが１個以上のオブジェクト属性に従って編成されている属性のタイプであってもよい。さらに別のタイプでは、ファイルが一意なファイル編成識別子に従って割当てられ、編成されている。

　プレースホルダーをファイル管理システム内のオブジェクトとして定義する利点の一つは、プレースホルダー・オブジェクトがファイル管理システムにより認識される実在のオブジェクトであり、たとえプレースホルダーが表わす見込ファイルが実際にはまだ存在しなくても、他の任意の（既存）ファイルと同様に編成（例えば階層的、あるいは属性や識別子を利用）できる点である。

　別の利点は、ファイリングシステム・オブジェクトがそれらのオブジェクトに関連付けられたアクション起動用の目印を提供できる点である。例えば、オブジェクトがファイルである場合、グラフィカル・ディスプレイのオブジェクト上で単にポインタやカーソルを“クリックする”だけで開くことができる。オブジェクトに関連付けられたコマンドやオプションのサブメニュー（文脈的メニュー等）の提供も従来技術による。同じことが、見込ファイルに関する動作を起動するための目印を提供できるプレースホルダー・オブジェクトにあてはまる。

　プレースホルダー（見込ファイルや状態を表わす）を既存のファイルと区別する特徴は、見込ファイルが到着または提示された際にこれでプレースホルダーを“充当”する点である。“充当”という用語は、プレースホルダーが見込ファイル用の“入口”または“場所”を提供するという意味で広義に解釈されるよう意図している。多くの場合、プレースホルダーは見込ファイルが到着または提示された際に削除される。しかし、プレースホルダーを残してよい場合もある。

　別の実施の形態において、プレースホルダーは１個の見込ファイルを表現するオブジェクトである。

　さらに別の実施の形態において、プレースホルダーはスキャナやデジタルカメラ等の文書画像処理装置を介して入力される紙形式で見込文書を表現するものとして記述されている。プレースホルダーは好適には、文書のスキャン入力およびファイル記憶システムへのアップロードを少なくとも部分的に自動化すべく利用できるスキャン制御情報を含んでいる（または参照する）。

　さらに別の実施の形態において、ファイルの最終バージョンが到着してプレースホルダーの充当が完了するまで、見込ファイルの複数のバージョン（例：ドラフト）を収容可能なプレースホルダーについて述べる。

　本発明の一態様に基づき、電子的に記録された文書を処理するための電子文書処理システムおよびその方法を提供する。本システムは電子ファイリングシステム、プレースホルダー・オブジェクト・ジェネレータ、およびプレースホルダー・コントローラを含む。電子ファイリングシステムはファイリングシステム・オブジェクトを管理する。電子ファイリングシステムにより管理されたファイリングシステム・オブジェクトは、電子文書ファイルに関連付けられたファイリングシステム・オブジェクトの電子文書ファイルクラスを含む。プレースホルダー・オブジェクト・ジェネレータは、ファイリングシステム・オブジェクトの電子文書ファイルクラスとは別個のファイリングシステム・オブジェクトのプレースホルダークラスを電子ファイリングシステム内で作成する。プレースホルダー・ジェネレータにより作成された各プレースホルダーは、（ａ）電子ファイリングシステム内で作成されるべき見込文書ファイルを識別するメタデータと共に電子ファイリングシステムに保存され、（ｂ）現時点では電子ファイリングシステムに存在しているとは認識されていないが、電子ファイリングシステムへ保存されることが明らかに見込まれる、見込文書ファイルを表わす。プレースホルダー・コントローラは充当動作を行ない、見込文書ファイルが提示された際にプレースホルダー・オブジェクトを充当し、プレースホルダー・コントローラがプレースホルダー・オブジェクトを充当した後で見込文書ファイルが電子ファイリングシステムに存在していると認識される。

　以上述べたように本発明によれば、プレースホルダー・オブジェクトをファイル管理システム内の実際のオブジェクトとして用いることにより、見込ファイルがまだ存在しなくても、（プレースホルダー・オブジェクトの特定の充当における）オブジェクトに関するイベントを受容することができる。好都合なことに、文書が既に存在している場合でも、そのプレースホルダーを利用して他の文書および／またはプレースホルダーに関する依存関係をわかりやすくすることができる。

Ａ．プレースホルダー・オブジェクトおよび動作環境。
　図１を参照するに、ネットワークベースの文書リポジトリ・システム１０の第一の実施の形態について述べる。本システムは一般に、ファイル管理システム１４に接続された１個以上の大容量記憶装置１２（例えば半導体、磁気または光記憶装置）を含む。ファイル管理システム１４は保存された文書ファイルを階層構造内のオブジェクトとして編成する。ファイルは一般に文書ファイルであり、（例えば一意なファイル名拡張子により指定される）異なるファイル種別であってよい。

　ファイル管理システム１４はネットワーク１６（例えばインターネットやイントラネット）を介して１個以上のユーザー端末に接続されている。ユーザー端末は１個以上のデスクトップ型コンピュータ１８を含み、オプションとしてプリンタおよび／またはスキャナ装置２０が付加されていてもよい。各コンピュータ端末１８はリポジトリ・システム１０から文書を取出して閲覧し、オプションとして印刷することができる。新規文書もまたコンピュータ端末１８内へスキャン入力されて（あるいはコンピュータ１８側で電子的に受信されて）文書リポジトリ・システム１０へ転送できる。

　さらに、ユーザー端末は１個以上の多機能文書プロセッサ２２を含み、通常は印刷、複写、スキャン入力、またはファックス機能の１個以上の組み合わせである。文書は多機能文書プロセッサ２２で直接取出して印刷したり、あるいは紙文書を文書リポジトリ１０内へ直接スキャン入力してもよい。

　そのようなリポジトリの設定および利用は当業者には公知であるため、ここでより詳しく述べる必要はない。上記のものを実装するための適当なシステム、例えばＤｏｃｕＳｈａｒｅ（登録商標）およびＦｌｏｗＰｏｒｔ（登録商標）がゼロックス株式会社から発売中である。

　デスクトップコンピュータ１８、プリンタおよび／またはスキャナ装置２０、および多機能文書プロセッサ２２はプレース要素２であり、ファイル管理システム１４と直接または間接的に通信したり、および／またはその一部または全体を構成する。プレースホルダー要素２は、プレースホルダー・コントローラ４、オブジェクト・ジェネレータ６、およびバージョンデータ・ジェネレータ８を含み、その各々について以下により詳しく述べ、以下に述べる実施の形態の１個以上を実施すべく利用可能である。

　一般に、プレースホルダー・コントローラ４は、ファイル／スキャン／バージョン／プレースホルダーの作成、削除、および充当に関する制御動作を実行するための機能を含む。オブジェクト・ジェネレータ６は、ファイル（またはファイリング）、スキャン、およびバージョンの各プレースホルダー・オブジェクトのクラスを含むプレースホルダー・オブジェクトの異なるクラスを作成する機能を含む。バージョンデータ・ジェネレータ８は、プレースホルダー・オブジェクトに関連付けられたバージョンデータを作成する機能を提供する。

　図２に例を用いて、ファイル管理システム１４の論理ファイリング構造内のファイリングシステム・オブジェクト２４の階層構造を示す。階層ファイル管理システムの例としてマイクロソフト社のＷｉｎｄｏｗｓ（登録商標）がある。しかし、本発明が階層ファイル管理システムに限定されておらず、例えばオブジェクトを編成するために１個以上のオブジェクト属性や識別子を用いる他のタイプと共に用いてもよいことは理解されよう。

　本構造は、“ケースフォルダー”と呼ばれる階層フォルダー２６（実際にはサブフォルダー）を含み、これは“Ｊｏｎへのメール”と呼ばれる文書ファイル・オブジェクト２８を含んでいる。各端末１８または多機能文書プロセッサ２２のディスプレイ上で文書ファイル・オブジェクト２８を選択することにより、任意の端末１８または多機能文書プロセッサ２２によりリポジトリ・システム１０からファイルを“取出す”ことができる。

　実在するファイル以外に、本実施の形態では、現時点では存在していないが将来明らかに見込まれるファイルを新たに受入れる。言い換えれば、現時点ではファイルは存在しないかもしれないが、明らかに存在が見込まれるか、または将来提示されることが見込まれる。本実施の形態において、ファイル管理システム１４がファイルまたは状態の明示的表現であると認識され、明示的に将来見込まれるプレースホルダー・オブジェクト３０（実際にはファイル）を定義することによりこのようなファイルが受入れられる。そのようなプレースホルダー・オブジェクト３０は、ファイル管理システム１４が識別可能な、例えば異なるファイル名拡張子により指定することができる。本システムは異なるタイプのプレースホルダーを提供することにより、見込ファイルの異なるタイプ（異なるタイプの文書ファイル等）を表現したり、および／または異なる機能（後述の説明で明らかにな）を有する、異なるプレースホルダー・カテゴリを表現すること可能な点を理解されたい。

　図３に、例を用いて、“Ｊｏｎへのメール”と呼ぶ第一の文書ファイル・オブジェクト２８を含む階層フォルダー２６“ケースフォルダー”、およびが“Ｊｏｎからの返信”と呼ぶ第二のプレースホルダー・オブジェクト３０のディスプレイを示す。この場合、プレースホルダー・オブジェクト３０は、処理可能オブジェクト３０の形式で、Ｊｏｎからの返信が見込まれるという明示的な表現を提供する。“返信”文書ファイル自体はまだ存在しないにもかかわらず、見込“返信”文書ファイルは他の既存ファイルと同様に、管理システム１４内の実オブジェクト３０で表現されている点を理解されたい。

　プレースホルダーをファイル管理システム１４内のオブジェクト３０として定義する利点の一つは、プレースホルダー・オブジェクト３０がファイル管理システム１４により認識される実オブジェクトであり、上述のように、プレースホルダーにより表現された見込ファイルがまだ存在しないにもかかわらず、他の任意の（既存）ファイルと同様に編成（例えば階層的に）できる点である。

　別の利点は、ファイル管理システム１４内の各オブジェクトに１個以上の情報パラメータ（メタデータ）を関連付けることができる点である。これは既存文書ファイル・オブジェクト２８にあてはまるが、（他の任意のオブジェクトと同様に）プレースホルダー・オブジェクト３０にもあてはまる。従って、プレースホルダー・オブジェクトは、プレースホルダーの作成日、見込ファイルの到着予定日、ファイル要求者（例えばプレースホルダーの作成者）、見込ファイルの出典、見込ファイルのタイプ、システム内へ文書を入力するための入力機器が使用するパラメータ（以下に別の実施の形態で詳細に述べる）、およびファイルが提示された際に文書リポジトリ内で保存すべき目標位置（ファイル名、および／またはディレクトリ）のうち１個以上の情報を含んでいてよい。

　さらに別の利点は、各オブジェクトはそのオブジェクトに関する動作を実行するための“目印”を提供できる点である。例えば、オブジェクトが文書ファイルである場合、ユーザーは単に端末ディスプレイのオブジェクト上のポインタやカーソルを“クリック”するだけでファイルを開くことができる。プレースホルダー・オブジェクト３０の場合、オブジェクトを“クリック”した際の既定アクションは、プレースホルダーを充当することであるかもしれない。

　これ以外または代替的に、ユーザーからの要求により表示可能なオブジェクト（オブジェクトの各タイプ）に関連付けられたコマンドやオプションのサブメニューを提供することは従来技術の範疇である。同じことがプレースホルダー・オブジェクト３０にあてはまり、プレースホルダーに関する動作の目印を提供することができる。特に、コマンドの少なくとも一つがプレースホルダーを見込ファイルで充当することであるサブメニューを提供することができる。別のコマンドを与えてプレースホルダー・オブジェクトのコピーを作成することができ、関連または類似の見込ファイル向けにプレースホルダーを設定するために役立つ。

　プレースホルダー・オブジェクトの利用を紹介する各種の例を以下に挙げる。すべての例で同一のプレースホルダー原理を利用しているが、アプリケーションと特定の細部が異なる。従って、一つの例からの考案を他の例と組み合わせた際に完全に互換性を有することを理解されたいが、これは明らかに予想できることである。

Ａ．１　ファイル−プレースホルダー・オブジェクト
　ファイル・プレースホルダーについて以下に述べる。プレースホルダー・オブジェクト３０は１個の見込ファイルを表わすオブジェクト・ジェネレータ６によりファイル管理システム１４内に作成される。ファイルがプレースホルダーの見込ファイルに対応している場合、プレースホルダー・コントローラ４はファイル管理システム１４内に作成されたプレースホルダー・オブジェクトを削除する。

　本実施の形態において、プレースホルダー・オブジェクト３０はオブジェクト・ジェネレータ６を用いて自動的にまたは手操作で作成可能である。例えば、（抵当処理アプリケーション等の）アプリケーション・プログラムがある文書の受信を見込んでいる場合、そのアプリケーション・プログラムの一部をなすオブジェクト・ジェネレータ６は見込文書ファイルを表わすプレースホルダー・オブジェクト３０を自動的に作成することができよう。１個以上の文書が見込まれる場合、各々が文書ファイル群の対応する1個を表わす複数のプレースホルダー・オブジェクト３０を作成することは無論可能である。

　別の例として、例えば月次報告のように文書が定期的に見込まれる、スケジュールシステムのケースがある。報告が見込まれる時点でプレースホルダー・オブジェクト３０が自動的に作成可能である。あるいは、先の報告用のプレースホルダー・オブジェクトが充当された際に、次の報告用のプレースホルダー・オブジェクト３０を自動的に作成することができる。

　別の例として、メールへの返信が見込まれる、または電話での会話に対する返事が見込まれることを手操作でアプリケーション・プログラムに示す場合がある。アプリケーション・プログラムは見込返信用にプレースホルダー・オブジェクト３０を作成することができる。

　アプリケーション・プログラムは図４に示すステップを実行することができ、ステップ３２でどの文書が明らかに見込まれるかを判定する。結果が“ｙｅｓ”である場合、プログラムはステップ３４へ進み、ファイル管理システム１４内で見込ファイル用のプレースホルダー・オブジェクト３０が作成される。ステップ３２における結果“ｎｏ”である場合、プログラムは経路３６で分岐してステップ３４を回避する。

　上記は例に過ぎず、見込ファイル用にアプリケーション・プログラムが自動プレースホルダー・オブジェクト３０を作成できる他のさまざまな状況がある。

　図３、５、および６を参照するに、代替手段として、プレースホルダー・オブジェクト３０の手操作による作成がある。より具体的には、ユーザーの手操作による要求に対してファイル管理システム１４がプレースホルダー・オブジェクト３０を挿入する。図５に必要とされる処理ステップを示す。図５は、ファイル管理システム１４、およびユーザーのコンピュータまたは端末１８の両方における処理を組み合わせようと試みる模式的な表現である点を理解されたい。図５において、（図３のように）現在の（例えば階層的な）文書フォルダーの表示を作成し、例えばユーザーがプルダウン・メニュー４２、４４から選択することによりユーザー・コマンドを入力するステップ４０を示す。

　図３に示す実施の形態において、ユーザーは“追加”プルダウン・メニュー４４でコマンドを選択することにより手操作でプレースホルダー・オブジェクト３０を追加するか、または“編集”プルダウン・メニュー４２内のコマンドを選択ことにより既存のプレースホルダーを編集することができる。代わりにマイクロソフト（登録商標） Ｗｉｎｄｏｗｓ（登録商標）式のインタフェースを用いた場合、新規プレースホルダー用のコマンドは、“ファイル”メニュー内の従来の“新規”項目（すなわち、ファイル→新規→プレースホルダー）に現われる。

　追加または新規コマンドは、ユーザーを図６に例示する手操作入力画面が表示されるステップ４６（図５）へ誘導する。ユーザーは、プレースホルダーおよびプレースホルダーが表現する見込ファイルに関する情報（メタデータ）を入力することができる。この例で、情報は件名４８、およびオプションとして１個以上の要約５０、本文５２、（検索用）キーワード５４のリスト、および（プレースホルダーの作成者を識別するための）作成者セクション５６を含む。情報はまた、ファイル管理システム１４により自動的に付加される（従って図６でユーザー入力可能なパラメータではない）作成日付（修正日付）を含む。ユーザーが画面下部にある“ＯＫ”ボタン５８をクリックした場合、プロセスはステップ６０（図５）へ進み、（先に図２を参照しつつ説明したように）階層ファイリング構造内に対応するプレースホルダー・オブジェクト３０が作成される。

　プレースホルダー・オブジェクト３０を他のファイル・オブジェクト２８から区別する特徴は、プレースホルダー・オブジェクト３０が見込ファイルにより“充当可能”である点である。この例において、見込ファイルが到着するか、または提示された場合、プレースホルダー・オブジェクト３０は実際のファイルにより置き換えられ、プレースホルダー・オブジェクト３０からパラメータ情報（メタデータ）を継承することができる。

　図３、５、および７を参照するに、プレースホルダー・オブジェクト３０を充当するために、ユーザーはまず画面上のプレースホルダーを選択し、次いでステップ４０（図５）においてプルダウン・メニュー４２内の“充当”コマンドを選択する。これによりユーザーをステップ６２へ誘導し、そこで“充当”画面（図７）が表示されて、プレースホルダー・オブジェクト３０を置き換えるべく、どのカレント・ファイルがＪｏｎからの返信であるかをユーザーが指示できるようにする。これは見込ファイルが現在ユーザー端末に到着していて、文書リポジトリ・システム１０への提示待ち状態であると仮定している。

　図７を参照するに、“充当”画面は図６のプレースホルダー入力画面に類似しており、プレースホルダー・オブジェクトを置き換える文書のファイル名をユーザーが入力するための文書ファイル名ボックス６４を含む点が異なる。画面はまた、公知のタイプのファイル・リスター（ブラウザ）を起動すべくユーザーが選択できる“閲覧”ボタン６６を含み、ユーザーに開示されているファイル群から当該ファイルを選択できる。この例で図７に示すメタデータは、プレースホルダー・オブジェクト３０用に入力されたものと同じデータである。他の例では、アプリケーション・プログラムに応じて、アプリケーション・プログラムがメタデータの一部または全部を更新することも、あるいは新規メタデータを作成することもできる。

　必要ならば、ユーザーは任意のメタデータを、それが新たに提示された文書ファイルに継承される以前に編集することができる。ユーザーが画面下部の“充当” ボタン６８をクリックした場合、プロセスはステップ７０（図５）へ進み、そこでプレースホルダー・オブジェクト３０は削除され、文書ファイルがプレースホルダー３０の代わりにファイル管理システム１４にアップロードされる。

　図８に、プレースホルダー・オブジェクトが“Ｊｏｎからの返信”を含む実際の文書ファイル７２により置き換えられた後の、ファイル管理システム１４の論理ファイリング構造内のオブジェクトの階層構造を模式的に示す。本例で、ファイル・オブジェクト７２は、それが置き換えたプレースホルダー・オブジェクト３０と同じ論理フォルダー２６（“ケースフォルダー”と呼ぶ）に配置される。言い換えれば、プレースホルダー・オブジェクトはファイルが保存される“場所”を正確に表現している。しかし、必要ならばプレースホルダー・オブジェクトは、プレースホルダー・オブジェクト３０を充当すべくファイル７２が提示された際にそれを保存する別の場所（目標場所）を示す情報を含むことができる点を理解されたい。

　本例では手操作による充当動作は、ユーザーが手操作でファイルを各プレースホルダー・オブジェクトに対応付け可能なように実行されるものと仮定している。しかし、自動的な対応付けが可能である場合が多くある。例えば、見込文書ファイルが、文書の参照番号、あるいはプレースホルダーの参照番号等、一意な識別子を含んでいる場合、これを自動的に処理して文書をプレースホルダー・オブジェクト３０に対応付けることができよう。本例で、ユーザーの“Ｊｏｎへのメール”文書ファイル２８は一意な文書識別子を引用することができ、これはまたプレースホルダー・オブジェクト３０用にメタデータとして保存することができる。一意な識別子とプレースホルダー・オブジェクトは、返信が見込まれる元のメールが書かれた際に作成することができる。

　文書ファイルが（手操作の充当動作無しで）リポジトリ・システム１０にアップロードされた場合、自動“マッチング”動作を実行（図５のステップ８０）して、入来する文書ファイルと合致するプレースホルダー・オブジェクトを、例えば一意な識別子を参照することにより特定することができる。ステップ８０において、対応するプレースホルダー・オブジェクトが識別されたならば、上述のようにプロセスはプレースホルダー・オブジェクトを充当するステップ７０へ分岐する。ステップ８０において、対応するプレースホルダー・オブジェクトが識別されなかった場合、プロセスは経路８２に沿って継続して充当動作を回避する。

　本例で、プレースホルダー・オブジェクト３０用のメタデータはまた、文書が到着した際に通知される１人以上の受信者の名前を含んでいてよい。例えば、通知メッセージはネットワーク１６経由で電子メール、または他のメッセージ交換システムにより送ることができる。図５を参照するに、このプロセスはさらに、プレースホルダー・オブジェクト３０が充当された際に任意の指定された受信者に通知を送るステップ８４を含んでいてよい。これはプレースホルダー・オブジェクト３０が自動的に充当された場合、自動充当技術（ステップ８０）と組み合わせると特に有用である（しかしそのような自動充当技術に限定はされない）。

　図３０に、ユーザーがプレースホルダー・オブジェクトに関するイベントに“申込み”可能にする入力画面３５０を示す。サービス申込みとはユーザーが、選択可能なイベントの発生に関する通知を受けるべく“申込み”できる公知の技術である。

　図３０において、サブメニュー３５２はユーザーがプレースホルダー・オブジェクト（項目３５４）の充当等、適切なイベントを選択できるようにする。入力セレクタ３５６はイベント発生時にユーザーが通知を受けたいか否かを指定できるようにする。

　別の重要な特徴として、プレースホルダー・オブジェクトが特定の予定日付および／または時刻までに充当されなかった場合に通知を発行する機能がある。従って、サービス加入に対する新たな改良として、別の入力セレクタ３５８は事前設定可能な日付および／または時刻までにイベントが発生しなかった場合にユーザーが通知を受けたいか否かを指定できるようにする。

　さらに、通知は予定日付または時刻の経過以外の理由で発行することもできる。あるいは、プレースホルダーのコンテンツまたは引用が欠落している場合に通知を作成してもよい。例えば、一組の文書がプレースホルダーにより見込まれていたが文書の到着時に１個が欠落していた場合、未完了イベントが発生してもよい。また、ある文書が充当されたもの、充当済み文書が依存するかまたは充当済み文書の利用が必要な別の文書が充当されていない場合にも未完了イベントが発生してもよい。

　より一般的には、未完了イベントは潜在的な問題に注意を向け、受信に応答して肯定的アクションが求められないイベントとは異なり、処置が必要な問題の通知を行なうため、未完了イベントはイベントと区別される。

　従って、プレースホルダー・オブジェクトをファイル管理システム内の実際のオブジェクトとして用いることにより、見込ファイルがまだ存在しなくても、（プレースホルダー・オブジェクトの特定の充当における）オブジェクトに関するイベントを受容することができる。好都合なことに、文書が既に存在している場合でも、そのプレースホルダーを利用して他の文書および／またはプレースホルダーに関する依存関係をわかりやすくすることができる。

Ａ．２　バージョン付きファイル・プレースホルダー・オブジェクト
　第一の例では、プレースホルダー・オブジェクト３０はファイルが提示された際に実際のファイルにより置き換えられた。第二の例において、見込文書ファイルの１個以上のバージョンを受容可能にする技術について述べる。同じ文書の異なるバージョンが見込まれるさまざまな状況（例：異なる言語のバージョン、印刷または表示用の異なるバージョン、更新文書のバージョン、あるいは多く人々からのコメントを含むバージョン）がある。

　ある特定の例では、見込文書の最終版の到着がペンディング状態であり、見込文書のドラフト・バージョンが提示可能または利用可能であるかもしれない。例えば、報告書が見込まれるが、まだ完成していない場合、報告書作成者から送信された報告書のドラフトでも特定の情報が利用可能であるかもしれない。このような場合、プレースホルダー・オブジェクト３０は、プレースホルダーに関連付けられたリポジトリに文書のドラフト・バージョンを送信可能にする極めて便利な仕組みを提供し、しかもシステムが文書の最終版を明らかに見込んでいることを示す表示を提供することができる。

　図９を参照するに、プレースホルダー・オブジェクトを文書ファイルのドラフト・バージョンで充当するステップは、既に図５を参照しつつ述べた充当ステップに類似している。図５と同様の仕方で、ドラフトファイルがユーザーのコンピュータ１８に既に存在するものと想定されている。図９において、プロセスは図５を参照しつつ先に述べたステップ６２、７０と同様にステップ６２Ａ、７０Ａを実行する。

　ステップ６２Ａにおいてユーザーに対し、見込ファイルのドラフト・バージョンとしてローカルファイルをリポジトリ・システム１０にアップロードすべくユーザー選択可能な入力画面（図７）が提示される。ステップ７０Ａにおいて、選択されたファイルがアップロードされて、既存のプレースホルダー・オブジェクト３０と共に保存されて関連付けられる。先の例とは対照的に、プレースホルダー・オブジェクト３０は削除されずに残されて、文書の最終バージョンが依然として到着待ちである（かつ依然として明らかに見込まれる）ことを明示的に示す。

　図９のステップは、例えばステップ４０（図５）でユーザーがプルダウン・メニュー４４から“ドラフトを充当”コマンドを選択した場合、独立プロセスとして実行できる。プルダウン・メニュー４４は次いで、少なくとも２個の異なるコマンド“充当”（最初の例でステップ６２と７０で実行される）および“ドラフトを充当”（同様にステップ６２Ａと７０Ａで実行される）を含む。

　あるいは、図７の充当画面を修正して“ドラフトを充当”とラベル付けられた（図７に破線で示す）第二の入力ボタン７３を提供し、プログラムに（文書の最終バージョン用の）ステップ７０の代わりに（文書のドラフト・バージョン用の）ステップ ７０Ａを実行させることができる。

　図１０に、プレースホルダー・オブジェクト３０に対するドラフト文書としてドラフト文書ファイル７４で充当した後のファイル管理システム１４の論理ファイリング構造内のオブジェクト２４の階層構造を模式的に示す。本例で、見込文書はプレースホルダー・オブジェクト３０で表現された報告書である。

　図１０を参照するに、ドラフト報告書を表わすドラフト文書ファイル７４がアップロードされた（図９のステップ７０Ａ）際に、文書ファイル・オブジェクト７４がプレースホルダー３０と同じフォルダー−６（“ケースフォルダー”）に保存される。ドラフト文書の後続バージョンが利用可能になって、ドラフトとして文書リポジトリ１０にアップロードされたならば、初稿を上書き（最新のドラフトだけが残る）するか、または第二のドラフト文書ファイル７６として保存（破線で示す）することができる。後者ではドラフトの全履歴が保存されて、後で見ることができる。プレースホルダー・オブジェクト３０は文書の最終バージョンが充当されるまで保持される。

　図１１を参照するに、文書の最終バージョンがプレースホルダーに対して充当された（図５のステップ７０）際に、プレースホルダー・オブジェクトは削除され、第一の例のように、実際の最終文書ファイル・オブジェクト７２に置き換えられる。ファイルの任意のドラフト・バージョンは、後でドラフトの履歴を見ることができるように（７４、７６に示すように）残してもよく、または（図５にオプションのステップ７８として示すように）ドラフト・バージョンを削除してもよい。

　プレースホルダーが何らかの通知情報を含む場合、図５のステップ８４と同様に、文書のドラフトのバージョンがプレースホルダー・オブジェクトを充当したならば、通知は受信者にも送信することができる。

　本例で、文書のドラフト・バージョンは、それらが関連付けられているプレースホルダー・オブジェクト３０と同じフォルダーに保存されるように記述されている。しかしプレースホルダーは、別の場所（目標位置）を示す情報を含んでいてよく、このようなドラフト・バージョンがプレースホルダー・オブジェクト３０を用いてリポジトリ・システム１０に提示された際に保存すべきである点を理解されたい。

　上述の“ドラフト”の例は、同一文書の異なるバージョン（恐らく異なる見込バージョン）を受容する、より一般的な“バージョン”プレースホルダーの例に過ぎない点を理解されたい。好適には、バージョンプレースホルダー・オブジェクトは文書バージョンの履歴を追跡するためのメタデータを含むことにより、（各バージョンを個別に追跡することなく）プレースホルダー・オブジェクトから履歴が利用可能になる。例えばバージョン番号等のパラメータを用いてバージョンを追跡することにより、次の見込バージョンのためにプレースホルダーを修正することができる。自身のメタデータを更新することによりプレースホルダーを修正して、異なる文書（バージョン）を見込むことができる。

　プレースホルダーに保存された情報はまた、ユーザーインタフェースで履歴をどのように表示するか（例えば、最新バージョンだけを表示、または直近の“ｎ個の”バージョン、または全バージョン）を決定するためにも利用できる。

Ａ．３　スキャン・プレースホルダー・オブジェクト
　上述の例では、見込文書は文書リポジトリ１０にアップロード可能なファイル・オブジェクトとして電子形式で既に利用可能であると仮定されている。このようにプレースホルダー・オブジェクト３０を“ファイル・プレースホルダー”として分類することができる。文書を紙形式で受信した場合、例えばデジタルカメラやスキャナ（例えば図１のユニット２０または２２）等のデジタル画像キャプチャ装置を用いて文書を電子形式に変換することも無論可能である。

　しかし、この種の技術は技術的（または自動化）観点からは非効率である。すなわち、ユーザー側端末１８で手操作によりスキャナ・パラメータを設定し、手操作で文書をファイルとしてユーザー側コンピュータ端末１８に入力し、次いで手操作で文書リポジトリ１０内のプレースホルダー・オブジェクトにファイルを関連付けることが必要である。

　従って図１２を参照するに、本実施の形態はまた、特に紙形式で来ることが見込まれる文書用のプレースホルダー・オブジェクトのタイプをも提供する。このようなプレースホルダー・オブジェクトを以後スキャン・プレースホルダー・オブジェクト９０と呼ぶ。これは、到来する文書のデータ源が見込電子ファイルではなく、文書入力装置（例えば、スキャナ、デジタルカメラ等）として明示的に指定されている点でファイル・プレースホルダー・オブジェクト３０とは異なる。

　スキャン・プレースホルダー９０の機能は、プレースホルダー指向アプローチを提供することにより、文書リポジトリの所定の場所に保存すべく見込紙文書を適当なデジタル形式に変換することである。そのようなプレースホルダー・オブジェクトは、ファイル・プレースホルダー・オブジェクト３０について先に述べたのと同じ仕方で手操作または自動的に作成することができる（例えば図４を参照）。

　ファイル・プレースホルダー・オブジェクト３０に関連付けられた通常のメタデータに加え、スキャン・プレースホルダー・オブジェクトは文書のスキャニングに関する情報をも含む（少なくともそれを示す）。図１３を参照するに、そのような情報は以下のうち１個以上を含んでいてよい。
　（ａ）見込文書用の識別子９２。
　（ｂ）使用するスキャナの属性を示す識別子９４。
　（ｃ）スキャン解像度、文書をカラー、グレースケール、白黒のいずれでスキャン入力か、文書はグラフィカル画像かテキストか、等のスキャナ属性９６。
　（ｄ）文書に光文字認識（ＯＣＲ）等の何らかの変換、あるいはスキャン入力されたビットマップフォーマットからＪＰＥＧ、ＰＤＦ、またはＴＩＦＦフォーマットへの変換や　圧縮等のグラフィカル変換等を施すべきか、等もポスト・スキャニング属性９８。
　（ｅ）スキャン入力された文書がどのような経路を通って文書リポジトリ・システムに保存されるか（すなわち、宛先位置および／またはファイル名）等の保存属性１００。
　（ｆ）文書をネットワーク１６上の他のユーザーへ転送すべきか否か、あるいは何らかの通知を他のユーザーへ送るべきかを示す通知属性１０２。
　（ｇ）スキャン・プレースホルダー・オブジェクト９０が紙文書で充当された際に削除すべきであるか否かを示すフラグ１０４。

　例えばスキャン入力された画像の複数のバージョン（例えば、印刷用バージョン、画面／Ｗｅｂページに表示するバージョン、またはブラウズ用のサムネイル・バージョン）を入力するために付加的な情報を提供することもできる。

　文書をリポジトリ１０内へスキャン入力するために、ユーザーはまずグラフィカル選択画面で各々のスキャン・プレースホルダー・オブジェクト９０を選択する。図１４〜１６に例を用いて、多機能文書プロセッサ２２（図１）のタッチセンシティブ・ディスプレイに表示可能な選択画面１１０を示す。選択画面は、ＤＦＣ（デジタル・ファイリング・キャビネット）と名付けられた表示タブ１１２を含む。ディスプレイは上下方向の選択／スクロールボタン１１６を備えたスクロール可能ファイル・リスター１１４を含む。ファイル・リスター１１４は、ファイル管理システム１４の階層構造から、フォルダー名、ファイル・オブジェクト名、およびプレースホルダー・オブジェクト名を含むオブジェクトのリストを表示可能である。ユーザーに対し表示する情報量を減らすために、リスト可能なオブジェクトは例えば、（そのユーザーが関心を持つ情報だけを表示するように）現在のユーザー、またはファイル種別、あるいはスキャナ属性に応じてフィルタをかけてもよい。

　ファイル・リスター１１４の左側に３個のボタン１１８、１２０、および１２２がある。第一のボタン１１８は現在表示中のフォルダーに何らかの変更があれば表示を更新するための“更新”ボタンである。第二のボタン１２０はユーザーが階層ファイル構造を逆向きに辿れるようにするための“戻る”ボタンである。第三のボタン１２２は、ファイル・リスター ディスプレイ１１４で現在ハイライト表示されている種類のオブジェクトに応じて変化する（可変凡例１２４を備えた）多機能ボタンである。ファイル・リスター１１４の右側に、ファイル・リスター１１４内で現在ハイライト表示されているオブジェクトに関連付けられたメタデータの一般的な情報表示域１２６がある。

　図１４を参照するに、現在のオブジェクトがサブフォルダーである場合、ボタン１２２の動作は、サブフォルダーに入る（そしてファイル・リスター１１４内のコンテンツをリストする）ことである。従って、凡例１２４は“フォルダー”と表示されている。

　図１５を参照するに、現在のオブジェクトが文書ファイルである場合、ボタン１２２の動作は選択された文書ファイルを取出して印刷することであり、従って凡例１２４は“印刷”と表示されている。

　図１６を参照するに、現在のオブジェクトがスキャン・プレースホルダーである場合、ボタン１２２の動作はスキャン・プレースホルダーに関連付けられたスキャン制御情報に基づいて文書スキャン動作を開始してプレースホルダーを充当させることである。従って凡例１２４は“スキャン”と表示されている。再び図１２を参照するに、ユーザーが充当のためにスキャン・プレースホルダー・オブジェクト９０を選択した場合、第一の処理ステップ１３０は見込文書用の多機能文書プロセッサ２２の内部パラメータを設定するために制御情報（図１３）を取出す。本例で、制御情報はプレースホルダー・オブジェクト９０に関連付けられたメタデータとして保存され、プレースホルダー・オブジェクトから取出される。

　ステップ１３２において、スキャン制御情報９６（図１３）に基づいてスキャン動作が実行されて紙文書のデジタル画像を取り込む。スキャン入力された画像はまた任意のポスト・スキャニング制御情報９８（図１３）に基づいて処理される。これをステップ１３２と同じ方法の一部として示すが、このようなポスト・スキャニング処理は多機能文書プロセッサ２２または文書リポジトリ１０内のプロセッサのいずれかにより実行することができる。

　ステップ１３４において、デジタルファイルはスキャン・プレースホルダー・オブジェクト９０により指定された宛先場所に、および／またはファイル名１００の下に保存すべく文書リポジトリ１０にアップロードされる。配信または通知情報１０２も指定されている場合、指定された受取者にコピーが転送されるか、または通知が送られる。

　ステップ１３６において、削除フラグ１０４に基づいてスキャン・プレースホルダー・オブジェクト９０を削除すべきか否かについて決定がなされる。本例で、スキャン・プレースホルダー・オブジェクト９０は単一の見込紙文書を表わすが、一旦充当されたならば、削除すべきである。しかし、後述するようにスキャン・プレースホルダー・オブジェクトを残した方がよい状況もある。

　上述の例で、スキャン制御情報はスキャン・プレースホルダー・オブジェクト９０のメタデータの一部として保存される。しかし他の形式で、スキャン制御情報の一部またはすべてを文書リポジトリ・システム１０のどこかに、またはローカル端末１８あるいは多機能文書プロセッサ２２のスキャン装置に保存してもよい。このような場合、スキャン・プレースホルダー・オブジェクト９０は各々のスキャン制御データを“指す”ためのメタデータを含んでいてよい。

　ある方式では、多機能文書プロセッサ２２のスキャン装置はスキャン・テンプレートを収容することができ、それらは多機能文書プロセッサ２２のスキャン装置にローカルに保存することも、またはネットワーク１６経由でアクセス可能な１個以上の共有プールに保存することも可能な制御パラメータの組である。必要ならば、スキャン・プレースホルダー・オブジェクト９０を、例えば１台のコンピュータ端末１８上のグラフィカル画面内で選択して、スキャンジョブ用に多機能文書プロセッサ２２のスキャナ装置上のローカル・テンプレートを作成することができる。テンプレートは、図１３に示す情報の少なくとも一部を含んでいてもよく、あるいはプレースホルダー識別子を含むことにより、画像ファイルが文書リポジトリ１０にアップロードされた際に、スキャン入力画像とテンプレートを作成したプレースホルダー・オブジェクト９０とをマッチングさせることができる。多機能文書プロセッサ２２のスキャナ装置で、図１４のものと同様のディスプレイを用いてスキャン・テンプレートを選択してもよい。

Ａ．４　カバーシートを用いたスキャン・プレースホルダー・オブジェクトへのアクセス
　上述の例において、ユーザーは充当対象のスキャン・プレースホルダーを選択するように求められ、それによりスキャニングおよびプロセスのアップロードが起動される（あるいはスキャン・ジョブ用にテンプレートの作成が起動され、多機能文書プロセッサ２２のスキャン装置においてユーザーにより再び選択される必要がある）。

　本例における代替技術として図１７に示すように、スキャン入力時にスキャン・プレースホルダー・オブジェクトを画面上で選択する必要なく情報を入力する方法としてコンピュータ可読なカバーシート１４０の利用がある。これは、異なる見込文書に対して極めて多数の異なるスキャン・プレースホルダーが存在して、画面上での選択に時間がかかる場合に特に有用である。

　カバーシート１４０はスキャン入力されている文書に関する情報を含んでいて、通常はスキャン・プレースホルダー・オブジェクトが作成される際に印刷することができる。これは、返信の発送が見込まれる元メールが送信された際に自動的に／プログラム制御により実行できる。カバーシート１４０は、例えば、バーコードや象形データ等の機械可読域１４２、および判読可能テキストを含むユーザー可読域１４４を含む。例えば、判読可能部分は“Ｊｏｎからの返信”と読めるかもしれず、コンピュータ可読域はファイル管理システム１４内で対応するスキャン・プレースホルダー・オブジェクトを識別する一意な識別子コードを含んでいてもよい。カバーシート１４０はまた、ユーザーがスキャン・プレースホルダー・オブジェクト９０から選択できるコマンドの１個として随時印刷することができる。

　カバーシートが読み込まれて復号されたならば、ステップ１４６（図１２）においてカバーシート１４０に合致するスキャン・プレースホルダー・オブジェクトを特定する処理が開始される。処理は上述のステップ１３０から１３６へ続く。

　変更された方式ではコンピュータ可読域１４２はまた、文書のスキャン入力を制御するためのスキャン制御情報（図１３）の一部または全部を含んでいてよい。これによりスキャン制御情報を文書管理システム１４から、または別の記憶場所から取出す必要なしに、スキャン時に紙文書から直接読んで復号することができる。

　図１８に、マッチング用スキャン・プレースホルダー・オブジェクトを識別しやすくするカバーシート１５０の別の方式を示す。各スキャン・プレースホルダー毎に専用のカバーシートを作成するのではなく、現在利用可能なスキャン・プレースホルダーのすべて（または選択されたもの）をリストにした汎用カバーシートを印刷することができる。これは汎用コマンドを用いて随時作成（印刷）可能である。カバーシート１５０は、例えば選択されたフォルダー内のスキャン・プレースホルダー・オブジェクトだけに限定することができる。

　図１９を参照するに、抵当申請を処理するシステムの場合、抵当申請を支援すべく見込（必須）紙文書用のスキャン・プレースホルダー・オブジェクト１５４〜１６０を含む“ケースフォルダー”と呼ばれる階層フォルダー１６２を用意してもよい。この例で、文書は抵当申請用紙（スキャン・プレースホルダー１５４）、書面による財産調査（スキャン・プレースホルダー１５６）、雇用者照会（スキャン・プレースホルダー１５８）および与信審査（スキャン・プレースホルダー１６０）からなる。

　文書リポジトリ内へ紙文書を入力するために、フォルダー１５２内の未処理（ペンディング中の）スキャン・プレースホルダー・オブジェクト１５４、１５６、１５８、および１６０のすべてがリストされた汎用カバーシート１５０を印刷する。カバーシートは、リスト内の各アイテムの隣にユーザーがマーク付け可能なボックス１６２を含んでいて、どの文書をスキャンすべきかをユーザーがマーク付け（例えばチェックまたは×印）できるようにする。カバーシート１５０が多機能文書プロセッサ２２のスキャナ装置によりスキャンされた場合、スキャナはマーク付けされたカバーシートを復号して、どのスキャン・プレースホルダーがスキャン対象の文書を表わしているかを判定することができる（図１２のステップ１６４）。上述のように、プロセスは次いでステップ１３０〜１３６へ進む。

Ａ．５　多目的プレースホルダー・オブジェクト
　先の例で、各プレースホルダー・オブジェクトは１個の見込文書ファイルを表わす。しかし、特に紙文書をスキャン入力する場合、１個の“汎用”プレースホルダー・オブジェクトで複数の見込文書を表現する方がより便利な状況がある。

　本例で、一般的なスキャン・プレースホルダー・オブジェクトは単一文書用のプレースホルダーと同様の情報（図１３）で構成されている。しかし、文書をスキャン入力することによりプレースホルダー・オブジェクトが充当された際に削除されないように“使用後に削除”フラグ１０４は無効に設定されている。その代わりに、プレースホルダー・オブジェクトは、将来同じプレースホルダー・オブジェクトを“介して”文書をスキャン入力できるように残される。

　記憶／ファイル名情報１００の特性にさらに相違がある。単一文書用のプレースホルダーの場合、ファイル名は特定ファイル用の特定のファイル名であってよい。しかし、多目的スキャン・プレースホルダーの場合、記憶／ファイル名情報１００はファイル命名規則を指定するのが好適である。そのような規則は英数字コンポーネントの組み合わせであって、アルファベット部分は各ファイルを通じて変わらず、各充当動作ごとに数字部分が加算されることにより、一連のファイル名を提供する。あるいはファイル名は、文書が保存されるフォルダー／場所に既に存在する名前を利用して作成することができる。また、単純な機構では既に存在する名前をアルファベットおよび数字コンポーネントに分解し、各新規文書用に数字を加算する。より高級な機構では、ファイル名のコンポーネントである日付や時刻等および他のパターンを識別したり、既存のファイル名を解析し、その結果を用いてスキャン入力された文書から情報を選択してファイル名を生成することが含まれる。

　多目的プレースホルダーの例として、図１９の特定のスキャン・プレースホルダー・オブジェクト１５４、１５６、１５８、および１６０を（図１９に破線で示す）多目的プレースホルダー・オブジェクト１７０で代替することができる。使用時に、プレースホルダー１７０を複数回充当することにより各文書がスキャン入力された際に、各文書にはシステム内へスキャン入力された順序に対応する一連のファイル名が与えられる。

　多目的プレースホルダー１７０は永久に残される（すなわち、手操作または別のアプリケーション・プログラムにより削除されるまで）。あるいは、多目的プレースホルダー１７０は、（紙文書の見込個数に対応して）所定回数充当された場合、または特定の最終版文書の受信が確認された場合に削除されるよう設定可能である。

Ｂ．代替的な動作環境
　上述の例は、ネットワークベースの文書処理システムを前提にしており、ファイリングシステム・オブジェクト（文書ファイル・オブジェクト２８およびプレースホルダー・オブジェクト３０、９０、および１７０）は遠隔ユーザーがネットワーク経由でアクセスするファイル管理システム１４により編成されている。

　図２０に、ローカルなコンピュータシステム２００の第二の実施の形態の機能コンポーネントを示す。本システムは独立したシステムであっても、または図１の第一の実施の形態に示す端末１８の一つであってもよい。

　図２０を参照するに、システム２００は一般に、コンピュータプロセッサ２０２、メモリ（例えばＲＡＭ）２０４、大容量記憶装置（例えば光または磁気ディスク等のディスク装置）２０６、文書画像処理（または入力）装置（デジタルカメラや光学式スキャナ等）２０８、ユーザーキーボード２１０、ユーザー・ポインティング・デバイス（マウス、ジョイスティック、またはトラックボール等）２１２、通信インタフェース２１４（例えばネットワークへの接続）、および画像表示装置（ＶＤＵ）２１６（ＬＣＤ画面、ＣＲＴまたは他の電界放射装置等）が含まれる。システム２００はまた、文書印刷用のプリンタ２１８を含んでいてよい。これらの要素はプロセッサ２０２に別々に接続されているように模式的に示しているが、（当分野で公知のように）要素群を１個以上の共有バスにより接続できることは当業者には理解されよう。

　図２１を参照するに、システム２００は一般に、ファイル管理システム２２２（以下同様にファイリングシステム２２２とも呼ぶ）、およびグラフィカル・ユーザー・インタフェース（ＧＵＩ）２２４を含むオペレーティング・システム２２０を含むか、または実行させる。そのような適当なオペレーティング・システムとして、例えばＭｉｃｒｏｓｏｆｔ（登録商標）社が開発したＷｉｎｄｏｗｓがある。アプリケーション・プログラム２２６はシステム２００でオペレーティング・システム２２０の下で実行される。このようなプログラムには例えば、１個以上のプレースホルダー要素２、文書画像を保存するための文書処理アプリケーション、文書画像処理装置２０８を用いて文書イメージを取得するスキャン・アプリケーション、文書画像を電子テキストに変換する光学式文字認識アプリケーション、および文書処理アプリケーションが含まれる。

　図２２を参照するに、本例でファイル管理システム２２２はファイルを階層構造内のオブジェクト２２８として編成する。オブジェクト２２８は、文書ファイル種別２３０を含む各種のファイル種別を含んでいてよい。Ｗｉｎｄｏｗｓオペレーティング・システムの下で、ファイル種別はファイル名の３文字の拡張子により識別される。本発明は階層的なファイル管理システムに限定されないが、先に述べたように、他のファイル管理システムが属性や識別子を利用してファイリングシステム・オブジェクトを編成することもできる。

　これまで述べてきたように、本システムの大部分は従来方式によるものであり、当業者には公知であろう。従って、従来の態様をこれ以上詳しく述べる必要はない。

　第一の実施の形態と同様に、本実施の形態はまたプレースホルダー・オブジェクト２３２を収容して、現時点では存在が認識されていないが将来明らかに見込まれファイルの明示的な表現を与える。プレースホルダー・オブジェクト２３２（実際にはファイル）は、将来明らかに見込まれるファイル、または状態の明示的な表現としてファイル管理システム２２２が認識するファイル拡張子により指定することができる。第一の実施の形態と同様に、本システムは異なるタイプのプレースホルダーを提供して、異なるタイプの見込ファイル（異なるタイプの文書ファイル等）、および／または異なる機能を備えたプレースホルダー・カテゴリーを表現することができる。

　特に、プレースホルダー・オブジェクト２３２は第一の実施の形態と全く同様に、ファイル・プレースホルダー・オブジェクト、スキャン・プレースホルダー・オブジェクト、および多目的プレースホルダー・オブジェクト（マルチスキャン・プレースホルダー・オブジェクト等）を含んでいてよい。

　第一の実施の形態の技術的利点に加え、第二の実施の形態はまた、ファイリングシステム・オブジェクト２２８を処理するためのＧＵＩの付加的な特徴を提供する。各オブジェクトはＧＵＩにおいてオブジェクト２２８に関する動作を起動するための“目印”を提供することができる。例えば、オブジェクトが文書ファイル２３０である場合、ユーザーはビジュアル・ディスプレイのオブジェクトに対しポインタやカーソルを単に“クリック”するだけでファイルを開くことができる。それに加え、あるいはその代わりに、ＧＵＩ２２４内のオブジェクト上でポインタやカーソルを“クリックする”ことにより表示可能な各オブジェクトに関連付けられたサブメニュー（またはコンテキスト・メニュー）を提供することは従来通りである。同じことがプレースホルダー・オブジェクト２３２にあてはまり、プレースホルダーに関係する動作用の目印を提供することができる。特に、プレースホルダー・オブジェクトを“クリック”することにより、デフォルト充当動作等の既定動作を起動することができる。例えば、プレースホルダー・オブジェクトがファイル・プレースホルダーである場合、プレースホルダーを“クリックする”ことによりプレースホルダーを充当するファイルをユーザーが選択するためのブラウザ・ウインドウを開くことができる。あるいは、プレースホルダー・オブジェクトがスキャン・プレースホルダーである場合、プレースホルダーを“クリックする”ことによりプレースホルダーを充当するためのスキャン動作を開始することができる。

　プレースホルダーにはサブメニューも提供され、その中のコマンドの少なくとも１個は見込ファイルを用いてプレースホルダーを充当するためのものであってよい。それに加え、またその代わりに、ＧＵＩ２２４の従来からの所謂“ドラッグ・アンド・ドロップ”機能を用いてファイルをプレースホルダー２３２へ“ドラッグ・アンド・ドロップする”ことにより、プレースホルダー・オブジェクト２３２を充当することができる。

　サブメニュー内の他のオプションとして、プレースホルダー・オブジェクトのメタデータから各種の情報、例えば文書到着が見込まれる日時、見込文書と他の文書との関係、またプレースホルダーがバージョン・プレースホルダーである場合には旧バージョンの詳細等を提供することができる。

　プレースホルダー・オブジェクトが表現および処理される仕方は、第一の実施の形態と同様である。従って、技術的説明を繰り返す必要はない。その代わり、以下の例ではＧＵＩ２２４を用いて各種の相違に焦点を当てる。

Ｂ．１　ドラッグ・アンド・ドロップの例
　図２３に、“ケースフォルダー”と呼ばれる階層フォルダーの典型的なＧＵＩディスプレイの例を示す。これは（図２と同様の方法で）“Ｊｏｎへのメール”と呼ばれる第一の文書ファイル・オブジェクト２４０、“Ｊｏｎからの返信”と呼ばれるプレースホルダー・オブジェクト２４２、および“Ｔｅｍｐ”と呼ばれる付加的文書ファイル・オブジェクト２４４を含んでいる。

　本例でファイル“Ｔｅｍｐ”は、Ｊｏｎからの返信を表わす、新たに到着した文書ファイルであると想定されている。プレースホルダー・オブジェクト２４２を文書ファイルで充当するには、単にＧＵＩで“ドラッグ・アンド・ドロップ”操作を行なう、すなわち文書オブジェクト“Ｔｅｍｐ”２４４をプレースホルダー・オブジェクト２４２上へドラッグするだけでよい。図２３に、“ドラッグ・アンド・ドロップ”操作を矢印２４６で模式的に示す。

Ｂ．２　メニューの例
　上述の例は、見込ファイルがプレースホルダーと同じＧＵＩウインドウにあるか、または同時表示可能なＧＵＩウインドウにあるために“ドラッグ・アンド・ドロップ”操作が実行可能であると想定している。

　上述のように、プレースホルダー・オブジェクトが見込文書の出所を示す場合、“ドラッグ・アンド・ドロップ”技術の代替手段として単にプレースホルダー・アイコンを“クリックする”ことによりデフォルト充当動作を開始させるもできる。

　図２４を参照するに、代替技術として、オブジェクト（以下でプレースホルダー“Ｊｏｎからの返信”と呼ぶオブジェクト２４２）に関連付けられたコンテキスト・メニュー２５０の表示がある。コンテキスト・メニュー２５０は、既存のファイルでプレースホルダー・オブジェクト２４２を充当する（先にセクションＡ１で述べたのと同様な仕方で）第一の充当コマンド２５２を含み、このコマンドはユーザーが利用可能なファイルのリストからファイルを選択するためのファイル・リスター／ブラウザを起動する。

　コンテキスト・メニューはまた、光学式画像処理装置２０８を用いて文書を直接スキャンすることによりプレースホルダー・オブジェクト２４２を充当させる第二の充当コマンド２５４を含む。プレースホルダー・オブジェクト２４２がスキャン・プレースホルダーである場合、充当コマンド２５４はコンテキスト・メニュー２５０の既定充当コマンドであり、プレースホルダー２４２はまた、光学式画像処理装置２０８用の必要なスキャン制御情報への参照を（上述のセクションＡ．３で述べたのと同様の方法で）提供する。

　コンテキスト・メニューはまた、プレースホルダーを（上述のセクションＡ．２で述べたものと同様な仕方で）見込文書ファイルのドラフト・バージョンで充当する第三の充当コマンド２５６をも含む。

　コンテキスト・メニューはプレースホルダー・オブジェクトの種類に合わせて調整可能であり、ユーザーには通常、すべてのオプションではなく、プレースホルダーの種類に関係するものだけが提示されることを理解されたい。プレースホルダーが見込文書の出所を示さない場合、ユーザーにコンテキスト・メニューの選択肢を提示することができる。

Ｃ．メッセージ交換およびワークフローシステムにおけるプレースホルダー
　上述の実施の形態および実施例は一般に文書リポジトリ・システム内、またはユーザー側コンピュータに保存された文書ファイルに関連している。しかし、プレースホルダー・オブジェクトの概念は、将来明らかに見込まれるファイルの明示的な表現を提供するのに役立つ任意のファイル管理システムにも拡張可能である。

　そのようなシステムの一つが電子メールその他のメッセージ交換システム、および／またはタスクまたはワークフロー管理システムである。このようなシステムを構築するための装置やアプリケーションソフトウェアは当業者に公知であるため、ここでは詳しく述べない。以下の説明はそのようなシステムにおけるプレースホルダーの利用に焦点を当てる。

　図２５、２６に、電子メールその他のメッセージ交換システム用の階層ファイリングシステムの例を示す。このようなシステムは、本発明の目的を実現するためのファイル管理システムの単なる例に過ぎないことを理解されたい。その構造はすべてのメッセージや業務タスクを収容するための階層メッセージフォルダー３００を含んでいる。フォルダー３００は、送信ボックスフォルダー３０２、送信済みフォルダー３０４、および受信ボックスフォルダー３０６を含む各種のサブフォルダーを収容する。通常は、送信用に準備されているメッセージは、送信と同時に送信済みフォルダー３０４へ移されるまで、送信ボックスフォルダー３０２に保存される。到着したメッセージは受信ボックスフォルダー３０６に保存される。

　図２７に、このようなシステムでプレースホルダー・オブジェクトを用いるための処理ステップの例を示す。ステップ３１０において、送信メッセージ３１２が準備され、送信ボックス・フォルダー３０２（図２５参照）に保存される。フラグその他のインジケータがメッセージに設定されていて、返信が見込まれるか否かを示す。メッセージの標準フィールドには返信期限日も示されている。

　メッセージ３１２は、ステップ３１４で送信されるまで送信ボックスフォルダー３０２に残っている。その時点で、メッセージ３１２は送信ボックスフォルダー３０２から送信済みフォルダー３０４（図２６）へ移される。

　ステップ３１６において、返信を見込んでいることをメッセージが示しているか否かをテストを実行して決定する。Ｙｅｓの場合、プロセスはステップ３１８へ進み、見込返信用のプレースホルダー・オブジェクトが作成されて任意の適当なフォルダー、例えば受信ボックス・フォルダー３０６（図２６）に保存される。プレースホルダー・オブジェクトは、返信が見込まれる期限日、送信メッセージの件名、（返信を送ってくる予定の）元の受信者の氏名、および／または自動的に返信を認識可能にするためのラベルとして機能する一意な識別子コード等のうち１個以上の情報を含む。

　本例で、受信ボックスフォルダー３０６にプレースホルダー・オブジェクト３２０を作成することにより、ユーザーには受信ボックスを見るたびに未受信の返信が見込まれることが明示的に示される。ある場合には、受信ボックスフォルダー３０６はユーザーが最も頻繁に表示するフォルダーであるかもしれず、ユーザーが定期的に見る唯一のフォルダーである可能性もある。従って、プレースホルダー・オブジェクト３２０の存在は、依然として返信が見込まれることをユーザーに常に想起させる。他の例において、プレースホルダー・オブジェクト３２０は例えば、プレースホルダー専用のフォルダー、あるいは仕事の種類、見込文書の種類、または名前（例えばクライアントや受信者名）に応じて編成されたフォルダー等の異なるフォルダーに置かれてもよい。

　ステップ３１６において、返信は来ないと判定された場合、プロセスは経路３２２に沿って分岐してプレースホルダー３２０の作成を一切回避する。

　図２８に、受信メッセージを返信と見なしてプレースホルダーを充当する必要があるか否かを調べるよう要求された処理ステップを示す。第一に、ステップ３３０において、受信メッセージ３３２は受信ボックスフォルダー３０６（図２９）に保存される。ステップ３３４において、第一のテストを実行して受信メッセージが返信形式であるか否かを判定する。その種の返信の件名は“Ｒｅ：．．．”という文字で始まっているか、または“返信”という単語を含んでいる場合が多い。さらに、返信メッセージはオリジナル・メッセージの本文全体を含んでいる場合が多い。

　ステップ３３４において、受信メッセージが返信形式であることが判定された場合、プロセスはステップ３３６へ進み、メッセージが既存の返信プレースホルダー３２０のいずれかと合致するか否かを判定する。例えば、送信メッセージの件名、（返信を送ってくると見込まれる）元の受信者の氏名、および／または元のメッセージおよび返信に含まれている一意な識別子コードのうち１個以上とマッチングすることにより、そのような合致を示すことができる。

　ステップ３３６においてプレースホルダー３２０（図２９）が識別された場合、プロセスはステップ３３８へ進み、プレースホルダー３２０は受信ボックスフォルダー３０６から削除される（３４０に×印で示す）。このように、プレースホルダー３２０は自動的に削除されて、ユーザーに対して依然として返信が見込まれるとの誤った通知を回避することができる。

　ステップ３３４において受信メッセージが返信ではないと判定されたか、あるいはステップ３３６において合致するプレースホルダー３２０を識別することができない場合、プロセスが経路３４２に沿って分岐してプレースホルダー削除ステップ３３８を回避する。

　無論、（オリジナルのメッセージのデータから作成した返信ではなく）新規メッセージの形式で返信を送ることも可能であり、その場合自動処理ステップ３３４、３３６、および３３８はそのような新規メッセージを認識しないかもしれない。その場合、ユーザーは手動削除操作３４４を用いて手操作でプレースホルダー・オブジェクト３２０を削除することが必要になる。そのような手動削除操作は、メッセージフォルダー３０２、３０４、または３０６から任意の選択されたファイルをユーサーが削除できるようにする電子メールシステムに普通に提供されている削除機能と同じである。

　図３１に、抵当アプリケーションシステム形式で、ワークフローシステム内のメッセージ交換とプレースホルダーを実装するためのユーザーインタフェースの例を示す。図３１ａ〜ｄに、ユーザー向けの一連の操作の各ステップを表わす。

　図３１ａにおいて、第一のステップでユーザーがペンディング中フォルダーのリスト３７２からクライアントフォルダー３７０を選択する。

　図３１ｂにおいて、ユーザーに対しフォルダー３７０内の情報に基づく表示ウインドウが提示される。表示ウインドウには“Ｓｍｉｔｈ　Ｇａｒｅｔｈ用文書”と題されたサブウインドウ３７４が含まれ、図中の各種文書が求められていることを示している。サブウインドウ３７４において、プレースホルダー・オブジェクト３７６は明らかに文書が見込まれるが、まだ到着していないことを示す。

　サブウインドウ３７４はまた、求められた文書に関してクライアントへ送信する電子メールメッセージを作成するための“クライアントへ電子メールを送信”とラベル付けられた“クリック可能な”ボタンアイコン３７８を含む。ボタン３７８をクリックすると、電子メールメッセージウインドウ３８０（図３１ｃ）が開く。クライアントから文書を求めるべく、受信者“宛先”フィールド３８２はワークフローシステムから自動的に記入され、“件名”フィールド３８４とテキスト“本文”フィールド３８６はユーザーにより記入される。

　“送信”ボタン３８８をクリックすると、電子メールメッセージはクライアントへ送信される。また重要なことに、新たに要求された文書用に新規プレースホルダー・オブジェクト３９０が作成される（図３１ｄ）。新規プレースホルダー・オブジェクト３９０の件名は電子メールメッセージの“件名”フィールド３８４に基づいており、プレースホルダー・オブジェクト３９０用のメタデータは送信済み電子メールメッセージへのリンクを含んでいて、要求された文書の履歴を提供する。プレースホルダー・オブジェクト３９０は上述のいずれの方法を用いても置換または充当可能である。

　上述の例はプレースホルダー・オブジェクトの利用および作成に焦点を当てるために単純化されている。プレースホルダー・オブジェクトに付加的な情報、例えば要求文書の到着が見込まれる期限日、および見込文書の到着をユーザーに通知する（または文書が期限日までに到着していないことをユーザーに通知する）ための通知詳細等も提供できることを理解されたい。

Ｄ．　その他
　上述のすべての実施形態および実施例において、文書ファイルおよびプレースホルダー・オブジェクトはファイル管理システムにより識別可能なオブジェクトとして記述されていて、それによりプレースホルダー・オブジェクトはオペレーティング・システムのＧＵＩを用いた他の任意のファイル・オブジェクトと同様に処理することができる。

　しかし、プレースホルダーがファイリングシステム・オブジェクトではない場合、プレースホルダーがオブジェクト指向グラフィカル・ディスプレイ内でグラフィカル・オブジェクトとして表示されることが望ましい。従って、他の実施の形態においてプレースホルダーが明確なファイリングシステム・オブジェクトではなく、特定のアプリケーション・プログラムで処理可能なデータのグラフィカル表現であって、見込ファイルのグラフィカル表現をユーザーに提示するものであってよいことは理解されよう。この代替方式にもかかわらず、プレースホルダーは見込ファイル（または見込まれる将来の状態）の明示的な表現を提供する。

　一例として、メッセージ交換システムはすべてのメッセージを１個の巨大なファイルに、インデックスおよびいつ返信が見込まれるかスケジューリングするためのスケジューリングデータと共に保持することができる。そのような場合、タスクおよびメッセージへの見込返信のスケジューリングデータに基づくプレースホルダー・オブジェクトのグラフィカル表現を、そのようなオブジェクトがファイル構造内の論理要素として存在していなくても、システムが作成することができる。従って、プレースホルダー・オブジェクトが実在のオブジェクトであるかのように、ユーザーに対してグラフィカル表現が提示される。このようなプレースホルダーを仮想プレースホルダー・オブジェクトと呼ぶ場合がある。

　また上述のとおり、ファイル管理システムは本質的に階層的である必要はない。ファイリングシステム・オブジェクトは代替的に、例えばオブジェクト属性またはオブジェクト編成に用いられた識別子等、任意の適当な技術により編成することができる。

　場所を選ばないファイリングシステムは代替的なファイリングシステムの一例である。場所を選ばないファイリングシステムについては以下の米国特許第５９３０８０１号、第６２６６６８２号、第６３０８１７９号、第６３２４５５１号、第６２６６６７０号、第６２４０４２９号、第６２６９３８０号、第６２５３２１７号、また欧州特許出願０９８６００９　Ａ２に記述されている。

電子ネットワークベースの文書処理システムの機能コンポーネントを示す模式図である。 図１のファイル管理システムの階層ファイリング構造を示す模式図である。 図１のシステムの端末におけるコンピュータディスプレイの模式表現である。 プレースホルダー・オブジェクトの自動作成を示す模式的なフロー図である。 プレースホルダー・オブジェクト処理の処理ステップを示す模式的なフロー図である。 図１のシステムの端末におけるプレースホルダー作成画面の模式表現である。 図１のシステムの端末における充当画面の模式的な表示である。 プレースホルダーの充当後の階層ファイリング構造を示す模式図である。 プレースホルダーに対してドラフトファイルの充当が求められる処理ステップを示す模式的なフロー図である。 ドラフトファイルを含む階層ファイリング構造を示す模式図である。 ドラフト・バージョンが充当された後でファイルが充当された後の階層ファイリング構造を示す模式図である。 スキャン・プレースホルダーの機能を示す模式図である。 スキャン・プレースホルダーに関連付けられたスキャン制御情報を示す模式図である。 スキャナ装置のタッチセンシティブ画面の模式的な表現である。 スキャナ装置のタッチセンシティブ画面の模式的な表現である。 スキャナ装置のタッチセンシティブ画面の模式的な表現である。 スキャン・カバーシートの第一の例の模式的な表現である。 スキャン・カバーシートの第二の例の模式的な表現である。 抵当申し込みを処理するための階層ファイリング構造の模式表現である。 コンピュータシステムの第二の実施の形態のコンポーネント間の機能関係の模式的なブロック図である。 コンピュータオペレーティング・システムとアプリケーション・プログラムの関係を示す模式図である。 第二の実施の形態の階層ファイリング構造を示す模式図である。 第一のＧＵＩ（グラフィカル・ユーザー・インタフェース）ディスプレイの模式的な表現である。 文脈的メニューを含む第二のＧＵＩディスプレイの模式的な表現である。 第三の実施の形態の階層ファイリング構造の模式的な表現である。 第三の実施の形態の階層ファイリング構造の模式的な表現である。 メッセージ送信の処理ステップを示す模式的なフロー図である。 メッセージ受信の処理ステップを示す模式的なフロー図である。 プレースホルダーが応答メッセージにより充当された後のファイリング構造の模式的な表現である。 特定のプレースホルダー・イベントが発生したか、または発生しなかった際に通知を受けるために案内申し込みの詳細を入力するための入力画面の模式表現である。 ワークフローまたはメッセージ交換システムにおけるプレースホルダーを示す模式図である。 ワークフローまたはメッセージ交換システムにおけるプレースホルダーを示す模式図である。 ワークフローまたはメッセージ交換システムにおけるプレースホルダーを示す模式図である。 ワークフローまたはメッセージ交換システムにおけるプレースホルダーを示す模式図である。

符号の説明

　２　プレースホルダー要素、４　プレースホルダー・コントローラ、６　オブジェクト・ジェネレータ、８　バージョンデータ・ジェネレータ、１０　文書リポジトリ・システム、１２　大容量記憶装置、１４　ファイル管理システム、１６　ネットワーク、１８　コンピュータ端末、２０　スキャナ装置、２２　多機能文書プロセッサ、２４　ファイリングシステム・オブジェクト、２６　ケースフォルダー、２８　文書ファイル・オブジェクト、３０　プレースホルダー・オブジェクト、４２　プルダウン・メニュー、４４　プルダウン・メニュー、４８　件名、５０　要約、５２　本文、５４　キーワード、５６　著作者セクション、５８　ＯＫボタン、６４　ボックス、６６　ブラウズボタン、７２　最終文書ファイル・オブジェクト、７３　入力ボタン、７４　ドラフト文書ファイル、７６　ドラフト文書ファイル、９０　スキャン・プレースホルダー・オブジェクト、９２　文書識別子、９４　スキャナ識別子、９６　スキャン特性、９８　スキャン後変換、１００　記憶装置／ファイル名、１０２　配信／通知、１０４　使用後削除フラグ、１１０　選択画面、１１２　表示タブ、１１４　ファイル・リスター、１１８　ボタン、１２０　ボタン、１２２　ボタン、１２４　可変凡例、１２６　情報表示域、１４０　カバーシート、１４２　機械可読域、１４４　ユーザー可読域、１５０　カバーシート、１５４　抵当申請用紙、１５６　財産調査、　１５８　雇用者照会、１６０　与信審査、１６２　ケースフォルダー、１７０　多目的プレースホルダー・オブジェクト、２００　コンピュータシステム、２０２　プロセッサ、２０４　メモリ、２０６　大容量記憶装置、２０８　文書画像処理装置、２１０　キーボード、２１２　ポインティング・デバイス、２１４　ネットワーク・インタフェース、２１６　ＶＤＵ、２２０　オペレーティング・システム、２２２　ファイル管理システム、２２４　グラフィカル・ユーザー・インタフェース、２２６　アプリケーション・プログラム、２２８　オブジェクト、２３０　文書ファイル・オブジェクト、２３２　プレースホルダー・オブジェクト、２４０　文書ファイル・オブジェクト、２４２　プレースホルダー・オブジェクト、２４４　文書ファイル・オブジェクト、２４６　矢印、２５０　コンテキスト・メニュー、２５２　充当コマンド、２５４　充当コマンド、２５６　充当コマンド、３００　階層メッセージフォルダー、３０２送信ボックス、３０４　送信済み、３０６　受信ボックス、３１２　送信メッセージ、３２０　プレースホルダー・オブジェクト、３３２　受信メッセージ、３４０　削除プレースホルダー、３５０　入力画面、３５２　サブメニュー、３５４　プレースホルダー・オブジェクト、３５６　入力セレクタ、３５８　入力セレクタ、３７０　クライアントフォルダー、３７２　ペンディング中フォルダーのリスト、３７４　サブウインドウ、３７６　プレースホルダー・オブジェクト、３７８　ボタンアイコン、３８０　電子メールメッセージウインドウ、３８２　宛先フィールド、３８４　件名フィールド、３８６　本文フィールド、３８８　送信ボタン、３９０　プレースホルダー・オブジェクト。

Claims (3)

1. 　電子的に記録された文書と、文書を処理するための電子ファイリングシステムと、プレースホルダー・オブジェクト・ジェネレータと、プレースホルダー・コントローラとを有する電子文書処理システムであって、
   　電子文書に関連付けられたファイリングシステム・オブジェクトを管理する電子ファイリングシステムと、
   　前記ファイリングシステム・オブジェクトの電子文書ファイルクラスとは別のファイリングシステム・オブジェクトのプレースホルダークラスを電子ファイリングシステム内で作成するプレースホルダー・オブジェクト・ジェネレータと、
   　前記プレースホルダー・オブジェクト・ジェネレータにより作成された各プレースホルダーは、ａ）電子ファイリングシステム内で作成されるべき見込文書ファイルを識別するメタデータと共に電子ファイリングシステムに保存され、（ｂ）現時点では電子ファイリングシステムに存在しているとは認識されていないが、電子ファイリングシステムへ保存されることが明らかに見込まれる見込文書ファイルを表わすプレースホルダーと、見込文書ファイルが提示された際にプレースホルダー・オブジェクトを充当する充当動作を行なうプレースホルダー・コントローラと、を備え、
   　前記プレースホルダー・コントローラが前記プレースホルダー・オブジェクトを充当した後で見込文書ファイルが電子ファイリングシステムに存在していると認識されることを特徴とするシステム。
2. 　請求項１に記載の電子文書処理システムにおいて、
   　前記プレースホルダー・オブジェクトに対し見込文書ファイルの複数のバージョンを関連付け可能にすべく、前記プレースホルダー・オブジェクトに関連付けられたバージョンデータを作成するバージョンデータ・ジェネレータと、
   　前記プレースホルダー・コントローラは、見込文書ファイルのバージョンが提示された際に前記プレースホルダー・オブジェクトを見込文書ファイルのバージョンで充当することを特徴とするシステム。
3. 　請求項１に記載の電子文書処理システムにおいて、
   　前記プレースホルダー・オブジェクト・ジェネレータおよび前記プレースホルダー・コントローラは、
   　電子メッセージを送信および受信するためのメッセージ交換システムの一部を構成し、前記ファイリングシステム・オブジェクトは前記メッセージ交換システムに保存された電子メッセージと、
   　前記プレースホルダー・オブジェクトは現時点では前記メッセージ交換システムに存在していることが認識されていないが、明らかに見込まれる電子メッセージと、を含み、
   　前記メッセージ交換システムはワークフローシステムにおいて電子メッセージの送信および受信を管理することを特徴とするシステム。

Images