JPH11175379A - 構造化ワークフォルダ - Google Patents

Abstract

(57)【要約】 【課題】 １単位の仕事と関連する、全てのドキュメン
ト、サポーティングデータ、ヒストリがグループ化され
たデータ環境を提供する。 【解決手段】 電子ドキュメントを系統立てる構造化ワ
ークフォルダは、関連するドキュメントをグループ化す
るセクションと、ワークフォルダ内に配置される予定の
ドキュメントを指示するプレースホルダを、備える。ワ
ークフォルダは、分散データ環境ユーザに多重ユーザか
らの同時アクセス・更新が可能な単一データオブジェク
ト内でのドキュメントとサポーティングメタデータを収
集し系統立てることを許容する。ワークフォルダは、１
つのワークフォルダに関連する仕事の進捗の追跡に用い
られるタスク入力をも備えることができる。さらに、ワ
ークフォルダへの全変更の詳細なヒストリログに加え
て、タスク形式のサポーティングメタデータ、情報フィ
ールド、連続ディスカッションが、蓄えられ得る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は一般的には文書の
系統立てに関するものであり、特に電子ドキュメントの
系統立てのための構造化ワークフォルダに関する。

【０００２】

【発明の背景】多くのビジネス取引において、取引を行
うために複雑な一連のドキュメントを整理することがし
ばしば必要になる。フォルダはそのようなドキュメント
を系統立てる一般的な方法である。取引の最初から利用
され得るドキュメントもあれば、他方で取引が進むにつ
れ受け取られたり作られたりするものもある。さまざま
な取引関連の仕事上で、作業を始めるに先立って利用可
能でなくてはならないドキュメントもあり得る。加え
て、多くの人々がその取引に同時に取り組む必要がある
こともあり、その場合その全ての人たちが、その取引の
情報に同時にアクセスする必要がある。１つの取引に関
連するドキュメントの全てが探知されることが必要であ
り、取引の完成に必要なドキュメントは紛失しないこと
が必要である。

【０００３】従来の電子ファイルシステムを用いると、
ドキュメントは、他のフォルダまたはドキュメントが置
かれる名前のついたフォルダすなわちディレクトリの階
層式の配列を利用して系統立てられる。典型的には、デ
ィレクトリは、内容またはカスタマＩＤのような通常の
基準により、配列されドキュメントをグループ化する。
それからドキュメントは、ユーザにディレクトリツリー
を探索し所望のドキュメントを選択するプログラムであ
るファイルマネジャのような基本的ツールを使ってユー
ザが直接アクセスしうる。

【０００４】ドキュメントを系統立てる階層式ファイル
システムを利用することの重大な欠点は、トランザクシ
ョンフォルダは独立のエンティティではなく、電子記憶
装置の記憶階層に堅くリンクされていることである。こ
のことは、系統立ての外部に存在するユーザにフォルダ
を配給することを排除する。またそれは、分類処理環境
のような、すべてのユーザが同じ電子記憶装置にアクセ
スするとは限らない状況では、複数のユーザ間で取引ド
キュメントを共有する場合に問題がある。さらに欠点と
して、ファイルシステムフォルダは相対的に構造化され
てないことがあげられ、そのため、トランザクションか
らトランザクションへの処理の整合性を保証するのが困
難である。

【０００５】共同環境にて利用する共有構造化データオ
ブジェクトのため、いくつかのプログラムが供給されて
いる。たとえば、ロータス・ノーツは情報を“フォー
ム”として系統立てる。そこでは、それぞれのフォーム
は、テキスト、数字、タイム、そして豊富なテキストの
ような特別なデータタイプにより構成されるフィールド
で作られている。電子ドキュメントは埋め込みドキュメ
ントとしてまたは連結ドキュメントとして、ロータスフ
ォームにアタッチすることができる。しかしながら、ロ
ータスノーツは、特定のタイプのドキュメントが蓄えら
れる場所のみならず、とりわけ将来作成されると予想さ
れるドキュメントを識別することについても、前もって
条件を指定しておくことがユーザに許されるメカニズム
を与えていない。さらに、ロータスノーツは、トランザ
クション・ドキュメントの選択を最適に系統立てかつ管
理するほど十分にフレッキシブルな構造を提供するもの
ではない。

【０００６】

【発明の概要】１ユニットの仕事と関連付けられた、全
てのドキュメント、支持するデータ、そしてヒストリが
ひとつにグループ化されたデータ環境を提供することが
本発明の目的である。

【０００７】１ユニットの仕事と関連する全てのデータ
が多くの異なるユーザから容易にアクセスできるデータ
環境を提供することも本発明の目的である。プロセスマ
ネジメントやデータフローと関連するさまざまな制御段
階すなわちガイダンスを供給するデータ環境をもたらす
ことも、さらに本発明の目的である。

【０００８】関連ドキュメントをグループ化するセクシ
ョンと、内部に置かれると予想されるドキュメントを指
し示すプレイスホルダとを備えた、電子ドキュメントを
系統立てる構造化ワークフォルダをもたらすことで、上
記のさらに他の目的は達成し得るものである。ワークフ
ォルダにより、ユーザは、多くのユーザが同時にアクセ
スし更新し得るシングルデータオブジェクト中のサポー
ティングメタデータと、ドキュメントとのコレクション
を収集し系統立てることが可能になる。

【０００９】本発明によると、ワークフォルダのドキュ
メントは、イメージ、ワープロファイル、スプレッドシ
ート、電子フォーム、ボイス、ビデオまたは他のどんな
タイプのフォーマットであってもかまわない。ドキュメ
ントはワークフォルダにアタッチしてもよく、その内容
はワークフォルダに蓄えられる。あるいは、ワークフォ
ルダはファイルシステムレファランスを経由して“外
部”ドキュメントと関連付けられる。オープンドキュメ
ントマネジメントアプリケーションプログラムインター
フェイス（ＯＤＭＡ）はドキュメントマネジメントシス
テムと連結しており、ユニバーサルリソースロケイタは
ウエッブベースのリポジトリに向いている。外部データ
源とのリンクをサポートする他のどんなメカニズムによ
ってもよい。

【００１０】ワークフォルダは、ワークフォルダと関連
する仕事の進捗を探知するのに用いられる１つのもしく
はより多くのタスクエントリをも備える。さらに、ワー
クフォルダにもたらされたすべての変更の詳細なヒスト
リログに加えて、情報フィールドの形式のサポーティン
グメタデータ、連続した議論がワークフォルダに蓄えら
れる。割当と締切を含んだ、仕事の探知を維持すること
により、要求に応じてまたはさまざまなイベントに応答
してスクリプトマクロを実行することにより、そして１
人以上のユーザが同じワークフォルダを更新するときに
データ更新の対立の和解の備えをすることによって、ワ
ークフォルダは処理関連の機能性をもたらす。

【００１１】ワークフォルダは、自動化インタフェイス
の利用によるサードパーティのアプリケーションのみな
らず、プログラムユーザインタフェイスの援助を得たユ
ーザによって、系統立てられ、形成され、アクセスされ
る特殊なデータオブジェクトとして実行される。コンピ
ューティング環境は、コンピュータが間断無くあるいは
断続的に相互連結される、ローカルエリアネットワーク
（ＬＡＮ）、イントラネット、インタネットを含む１つ
のまたはそれ以上のネットワークによって接続された１
台の又は多数のコンピュータである。従来技術のグラフ
ィカルユーザインタフェイス（ＧＵＩ）要素に基づくユ
ーザインタフェイスを備え、オブジェクト連結埋込（Ｏ
ＬＥ）オートメーションまたはコモンオブジェクトモデ
ル（ＣＯＭ）のような従来技術標準に基づく自動化イン
ターフェイスを備えた、マイクロソフトウインドウズの
ような従来技術のオペレーティングシステムにて、ワー
クフォルダのプログラムが実行されるのが好ましい。ワ
ークフォルダデータオブジェクトは、ネットワークを通
じて蓄えられ、転送され、分配され、種々の異なるプラ
ットフォームで稼動するソフトウエアによってアクセス
され修正される、という方法で、持続して蓄えられる。
好ましい持続性の表現とは、広範に受け入れられている
メッセージング標準への１準拠である。

【００１２】

【発明の実施の形態】図１は本発明にかかるワークフォ
ルダ内の種々のデータ要素の構造関係を示す図である。
好適な実施形態では、ワークフォルダは単一構造化デー
タオブジェクト５として形成されており、データ要素は
お互いに結びついていて秩序だったツリーを形作る。ツ
リーの根部分はワークフォルダノード１０である。ワー
クフォルダノード１０はコンテントノード１２への連結
路を含んでおり、コンテントノード１２がワークフォル
ダのデータと構造の主要部分に連結している。ワークフ
ォルダノード１０は、１つ又はそれ以上の、タスクデー
タ要素２０、ディスカッションデータ要素１６、ヒスト
リデータ要素１８、フィールドデータ要素２０そしてス
クリプトデータ要素２２をも、含んでいる。これらの要
素は、コンテントノード１２の下に蓄えられた第一次の
データに関連するメタデータを含む。これらノードの各
々は、以下にて議論される。ワークフォルダ１０は構造
データ要素として系統立てられるので、オブジェクトや
ノードは、連結リスト、ツリー、その他類似のものと関
連する従来技術のプログラミング技術を用いると、追加
したり移動させたりさらに削除したりすることができ
る。

【００１３】コンテントノード１２は、ワークフォルダ
１０の構造要素が連結するベースとして役目を果たす。
コンテントノード１２２連結する可能性のある３つの第
一次の要素がある。ドキュメント２８、プレースホルダ
２４そしてセクション２６である。これら要素を追加し
形成することにより、ユーザは、非常にさまざまな異な
るビジネス取引に関係するドキュメントを管理し蓄える
のに適切な構造を備えたワークフォルダデータオブジェ
クトをつくることができる。

【００１４】ドキュメント要素２８は、添付のドキュメ
ントかもしくはワークフォルダ１０の外部に存するドキ
ュメントへの経路である。作業は異なる場所の蓄えられ
たさまざまなドキュメントタイプを使用して為されるの
で、ワークフォルダプログラムは、ワークフォルダ内部
に含まれるドキュメントタイプ、ドキュメントタイプが
蓄えられる場所に、制限を加えることがない。換言すれ
ば、あらゆるドキュメントファイルは、ワークフォルダ
によって同様に扱われる。ドキュメント２８は、従っ
て、イメージ、ワープロファイル、スプレッドシート、
ボイス、ビデオ、あるいは他のあらゆるタイプのデータ
フォーマット、であってよい。

【００１５】ドキュメントがコンテントノード１２に添
付されると、埋め込みファイルデータとしてドキュメン
ト内容を含んだドキュメント要素２８が作成される。こ
のようにして、ドキュメントとその内容がワークフォル
ダ１０の一部となる。これに代えて、ドキュメント要素
２８を外部ドキュメントへの経路としてもよい。経路
は、計算機環境により認識されるファイルアドレスのい
かなるタイプのものであってもよい。典型的に支持され
るファイルアドレスは、ローカルファイルシステムやネ
ットワークファイルシステムに蓄えられるドキュメント
への参照、ドキュメント管理システム内部に蓄積される
項目のためのＯＤＭＡドキュメント・アイデンティファ
イヤ、またはＷＥＢベースのイントラネット若しくはイ
ンターネット・ドキュメント・リポジトリのためのＵＲ
Ｌアドレス、を含む。計算機プラットフォームやその構
成に依存するが、他のロケーションもサポートされてい
る。

【００１６】後でドキュメントがユーザによりアクセス
されると、ドキュメントデータがワークフォルダプログ
ラムによってドキュメント要素２８から抜き出される
か、もしくは、適切な記憶領域からファイルを検索する
オペレーティングシステムにまで、ドキュメントリンク
が通される。ドキュメントが抜き出され、または検索さ
れた後、ワークフォルダプログラムはドキュメントをオ
ペレーティングシステムに渡し、そしてオペレーティン
グシステムはドキュメントタイプを決定し、ドキュメン
トを処理する適切なアプリケーションを決定する。

【００１７】コンテントノード１２に添付される第２の
主要な要素であり、本発明の第一次的な形態は、プレー
スホルダ２４である。プレースホルダ２４は、まだ作成
も受信もされていない、１つの又はそれ以上の特定のド
キュメントのために予約されたスロットである。１つの
又はそれ以上のプレースホルダ２４がコンテントノード
１２と連結可能であり、プレースホルダ２４は命令リス
トに従ってコンテントノード１２に連結されるのが望ま
しい。ワークフォルダが与えられた作業項目のためにド
キュメントを系統立てる目的で用いられるとき、ワーク
フォルダ内部のプレースホルダ２４の存在は、ユーザに
対し、特定のドキュメントがその部分に形成されるかま
たは蓄えられると予想されるということを、示すもので
ある。

【００１８】プレースホルダデータ要素２４の構造の例
示が図２に示されている。おのおののプレースホルダ２
４は、プレースホルダ２４の中に置かれるはずのドキュ
メントのデータ内容を指す名前３０と、現実のファイル
が後に添付されるかまたは連結されるファイルオブジェ
クトフック３４を備える。複数のプレースホルダが命令
リストに従って実行されるとき、リスト中でプレースホ
ルダ２４がどこに位置するかを示すポジション３２もそ
の特定のプレースホルダ２４が有することもある。さら
に、プログラミング環境に依存するが、プレースホルダ
２４は唯一の内部符号３６を有することがある。

【００１９】本発明の好適な実施形態では、どんなタイ
プのドキュメントでも、ファイルオブジェクトフック３
４の条件を満たし得る。別の実施形態では、プレースホ
ルダ２４は、ユーザにより設計される特定のファイルネ
ームおよび／またはタイプに制限され得る。上記で論じ
たようにドキュメント要素２８を追加するのと同様の方
法で、ファイルオブジェクトフック３４に（埋め込んで
または連結して）ドキュメントを添付することによりプ
レースホルダ２４は“満たさ”れる。好適な実施形態で
は、プレースホルダ２４は１つだけのドキュメントに対
し予約される。しかしながら、プレースホルダ２４は、
添付されるドキュメントのコレクションが行えるように
実行し得る。すなわち、追加ファイルオブジェクトフッ
ク３４を加えることによってドキュメントは添付又は連
結される。

【００２０】さまざまな追加データ項目もプレースホル
ダ２４に連結され得る。好適な実施形態では、プレース
ホルダ２４はステータス要素３８を含み、ドキュメント
ファイリングプレースホルダ２４のステータスをユーザ
に示すために利用される。ステータス３８は“ｎｏｔ
ｓｔａｒｔｅｄ（開始せず）”、“ｉｎ ｐｒｏｇｒｅ
ｓｓ（進行中）”、“ｃｏｍｐｌｅｔｅ（完了）”のよ
うな意味が割り当てられた状況を含む。アサインメント
要素４０に（ｅメールアドレスのような）ユニークなユ
ーザＩＤを蓄えることにより、１つのプレースホルダが
特定ユーザに割り当てられることもある。好適な実施形
態では、１ユーザにプレースホルダを割り当てると、割
り当てられたユーザに割り当てについて知らせるために
ｅメールを生成し送信するプログラムイベントを作成す
る。より好適な実施形態では、通知メッセージは、問題
の特定のワークフォルダ１０への経路と割り当てられた
プレースホルダについての情報を含む。

【００２１】プレースホルダ２４は、そのプレースホル
ダに関する付加的なフリーフォームの情報を与えるため
に用いられるコメント要素４４をも含む。さらに、プレ
ースホルダ２４は、トリガ状況と、デッドラインがそれ
までに満たされねばならない期間とを示す、デッドライ
ン要素４２を含み得る。デッドラインについては、以下
にタスクと関連してより詳細に論じられる。

【００２２】コンテントノード１２に添付され得る第３
の主要要素はセクション要素２６である。セクション２
６は、追加のプレースホルダ２４とドキュメント２８と
に対するアンカポイントとして役目を果たし、さらに別
の実施形態では、サブセクションをもふくむこともあ
る。セクション要素２６は、ワークフォルダ１０のコン
テント１２が広範なカテゴリに従って系統立てられるの
を許容する構造要素として役目を果たす。おのおののセ
クション要素２６は指定された内容を表す名前を持つ。
好適な実施形態では、１つのセクション２６の内部に位
置するドキュメント２８とプレースホルダ２４は順序の
あるリスト要素として蓄えられる。

【００２３】本発明の別の実施形態として、ワークフォ
ルダ１０は、１単位の作業を完成するのに要求される一
連のステップを定義するタスクを含み、各々がユーザに
割り当てられデッドラインを持つ、タスクデータ要素１
４を有する。タスクデータ要素１４の内部に蓄えられる
各々のタスクは名前を持ち、為されるべき作業とステー
タスを示す。ステータスは、“ｎｏｔ ｓｔａｒｔｅｄ
（開始せず）”、“ｉｎ ｐｒｏｇｒｅｓｓ（進行
中）”、“ｃｏｍｐｌｅｔｅ（完了）”を意味するよう
定義された状況を含むグループから選択されるのが望ま
しい。

【００２４】さらに、タスクデータ要素１４の内部のお
のおのの作業は、作業請負者、コメントフィールド、デ
ッドラインを含む属性を備えるのが望ましい。上述し
た、プレースホルダ２４に対するデッドラインと同様
に、タスクに対するデッドラインは絶対的な満了日でも
よいしトリガイベントに関する期間でもよい。関連する
日付を条件として指定することは、デッドラインの時計
がトリガ状況に合致するまでスタートしないことを示
す。デッドラインの満了は、当業者には公知の従来技術
であるイベントハンドラルーチンを利用して処理される
満了イベントをいわば発火することになる。より好適な
実施形態では、トリガ状況は、タスクまたはプレースホ
ルダの終結はもちろん、プレースホルダの条件満足、タ
スクの完了、タスクまたはプレースホルダの割当を含
む、ワークフォルダデータの追加、削除、修正のなんで
もかまわない。イベントのセッティングとハンドリング
は以下図３と図４を参照しつつ論じられる。

【００２５】第一次のコンテントノード１２とタスクデ
ータ要素１４に加えて、ワークフォルダはいくつかの付
加的なメタデータ要素をも含むことがある。本発明の１
つの実施形態によると、ヒストリデータ要素１６がワー
クフォルダ１０の内部に位置する。ヒストリデータ要素
１６は、ワークフォルダ１０の内部の他のあらゆるデー
タ要素に対する付加、修正、削除のログを含む。変更が
ユーザインタフェイスを通したものであっても自動化イ
ンタフェイスを通したものであっても、ヒストリはワー
クフォルダプログラムによって自動的に生成される。お
のおののヒストリ入力は、変更前と変更後のデータ要素
の値に加えて、変更がいつ為されたか、誰によるのか、
どんなタイプの変更が為されたのかというような情報を
含むことが望ましい。周期的に、ワークフォルダは、統
合リポートのための一点集中リポジトリへの最新ヒスト
リ入力のコピーを送信する。好適な実施形態では、ワー
クフォルダがセーブされるときはいつでも、ヒストリを
ｅメール経由で知られた場所へ送信することにより、こ
のことはなされる。ワークフォルダ１０自体は、ワーク
フォルダ１０に蓄えられまたはワークフォルダ１０によ
って連結されるドキュメントを作成し修正するのに用い
るソフトウエアからは独立したものであるから、ドキュ
メント変更のヒストリは一般にはドキュメント変更の実
体部についての詳細を含まない、ということを銘記すべ
きである。

【００２６】ヒストリデータは、作業項目の進展を追跡
し、作業プロセスについての重大情報を引き出すのに利
用され得る。パフォーマンスを計測しモニタし、ボトル
ネックを識別し訂正し、全体構成が絶えず自らの全体の
ビジネスプロセスを改良する助けをする、源としても利
用され得る。ヒストリログの各々の入力は、プレースホ
ルダ２４、セクション２８またはドキュメント２８のよ
うな特定のノードまたはデータ要素と調和し、入力は単
一の繋がれたリストとして蓄えられる、のが好ましい。
従って、ヒストリログはワークフォルダ１０全体のため
に眺めても良い。その一方で、プレースホルダ２４のよ
うな、ワークフォルダ１０の内部の単一のオブジェクト
のヒストリを眺めても良い。この情況では、ワークフォ
ルダプログラムは、所望のオブジェクトに関する情報の
みを含むヒストリログのサブセットを提供する。

【００２７】好適な実施形態では、ワークフォルダ１０
は、１つ又はそれ以上のワークフォルダの特性に関する
ユーザが定義可能なメタデータを収容するフィールドデ
ータ要素２０をも含む。好適な実施形態では、フィール
ド要素２０は、データ要素を形成するためにユーザに装
入させ、消去させ、再命令を出させ、さまざまな特性を
割り当てさせるユーザインタフェイスと共に定義される
従来技術のフォーム処理データ要素を含む。それぞれの
データ要素は名前、（日付、通貨、またはテキストスト
リングのような）データタイプを持ち、さらに適当なデ
ータ値を持つことがある。フィールド２０は、ワークフ
ォルダ１０レベルで定義されるのが望ましい。しかしな
がら、フィールド２０は、より低いレベル、すなわちそ
れぞれのセクション２６、プレースホルダ２４、または
ドキュメント２８の内部にても、定義されることもあ
る。フィールドが追加され、編集され、そして／または
削除されると、ヒストリデータ要素１８にて維持されて
いるヒストリログは、それに従って更新される。

【００２８】本発明の１つの実施形態によると、フィー
ルドデータ要素２０のデータ内容のいくぶんかまたは全
ては、オペレーティングシステムにさらされそしてオペ
レーティングシステムを通じ、標準的メカニズムを経由
して他のアプリケーションプログラムにさらされる。好
適な実施形態では、このことは、公開データフィールド
をＭＡＰＩ（“ｍｅｓｓａｇｉｎｇ ａｐｐｌｉｃａｔ
ｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃ
ｅ”）と名の付く特性により説明を加えることで、なさ
れる。利用される特定メカニズムはオペレーティング環
境に依存するものである。このように、フィールドデー
タ要素２０の内部に蓄えられたデータは、サードパーテ
ィサーチエンジンにより検索可能であり、ワークフォル
ダプログラムの外部から拾い読み可能である。本発明の
別の実施形態によると、ディスカッションデータ項目１
６がワークフォルダ１０の内部に蓄えられる。ディスカ
ッションデータ項目１６は進行中の作業に関係する幾数
個ものトピックに関する進行中のコミュニケーションの
ための場所を提供する。好適な実施形態では、コメント
は、誰がコメントをいつ書いたかを識別するデータに加
えてコメントの主題を記述する主題識別子を含む。簡易
利用のため、コメントは従来技術の連続ディスカッショ
ンツリーの中に分類され、インターネットＵＳＥＮＥＴ
告示板システムにより維持されるディスカッションと同
様の方法で処理される。

【００２９】ワークフォルダ１０と連結するのが望まし
い、追加のデータ要素はスクリプトデータ要素２２であ
る。本発明の１つの形態によると、ワークフォルダプロ
グラムは、ユーザにワークフォルダの機能を拡張させ
る、手書きのインターフェースを含む。スクリプトデー
タ要素２２はワークフォルダ１０の内部で１人またはそ
れ以上のユーザのスクリプトが埋め込まれる位置を提供
する。それぞれのスクリプトは要求により実行し得る
し、アクセス可能なスクリプトエンジンによりサポート
されるならばどんなスクリプト言語で書かれていてもよ
い。典型的に支持されるスクリプト言語は、ＶＢＳｃｒ
ｉｐｔとＪａｖａＳｃｒｉｐｔを含む。本発明の１つの
形態では、スクリプトはワークフォルダそれ自身の内容
と構造を修正し、ＯＬＥ自動インターフェースを通して
他のアプリケーションソフトウエアとも通信しうる。ス
クリプトデータ要素２２はイベントハンドラと共に用い
るのが望ましい。好適な実施形態では、スクリプトデー
タ要素２２は、何のイベントがイベントハンドラにより
モニタされるべきか、どのスクリプトを種々のトリガイ
ベントに応答して実行すべきか、を決するマスタイベン
トスクリプトを含む。マスタイベントスクリプトは追加
のスクリプトコードを含むことができ、すなわち最も単
純な形式では、それはスクリプトディスパッチャに過ぎ
ない。

【００３０】図３と図４とは、本発明の１つの実施形態
にかかる、イベントの生成と処理を示すフローチャート
である。図３は、本発明の１つの実施形態にかかる、ワ
ークフォルダイベントのセッティングを示すフローチャ
ートである。１つのワークフォルダへの更新を基にした
ワークフォルダイベントはワークフォルダがセーブされ
るときにのみ始められるのが望ましい。ワークフォルダ
がセーブされるとき（ブロック２５０）、ワークフォル
ダプログラムは何らかの変更が為されたか確定するため
にワークフォルダを調査する。（ブロック２５２）。こ
の調査は、セーブされるワークフォルダと上書きされる
ワークフォルダとの間の、１要素ずつの比較であること
が望ましい。ワークフォルダが変更されていたら、変更
部のリストが生成され（ブロック２５４）各々の変更は
モニタすべきイベントと対応するのかどうか確定するた
めに調査される（ブロック２５６）。ワークフォルダの
どんな変更もモニタすべきイベントとして対応させるこ
とができる。典型的な例としては、タスクの割当やプレ
ースホルダを満たすことが含まれる。１つの変更がモニ
タすべきイベントであるとすると、適切なプログラムイ
ベントインジケータがセットされイベントハンドラにど
のイベントが発生したかを通知する。（ブロック２５
８）。調査は、ワークフォルダへの全ての変更が調査さ
れ全て適切なイベントがセットされるまで続く。（ブロ
ック２６０）。デッドラインの終結のような、他のワー
クフォルダイベントは、当業者に公知の、従来技術のス
ケジューラルーチンを利用してセットされる。

【００３１】図４は、本発明の１つの実施形態にかかる
ワークフォルダイベントのモニタリングを示すフローチ
ャートである。典型的には、ワークフォルダイベント
は、イベントがセットされたかどうかを常にチェックす
るイベントハンドラルーチンによりモニターされる。
（ブロック２６２）。イベントがセットされれば、その
イベントに割り当てられた、予め定義されたワークフォ
ルダアクションが存在するか否かを確定するために、イ
ベントデータが調査される。（ブロック２６４）。予め
定義されたアクションが割り当てられていれば、そのア
クションが実行される。（ブロック２６６）。典型的な
予め定義されたアクションは、タスクアサインイベント
に応答して、情報を与えるｅ―メイルを生成し送信す
る。ユーザ定義スクリプトと異なり予め定義されたアク
ションは特にワークフォルダ内部に含ませておく必要が
ないことが認められる。予め定義されたアクションがイ
ベントに割り当てられないならば、イベントハンドラチ
ェックはユーザ定義スクリプトがそのイベントに割り当
てられたかをチェックする。（ブロック２６８）。そう
であれは、ユーザ定義スクリプトがワークフォルダから
引き出され、適切なスクリプティングエンジンを用いて
実行される。

【００３２】本発明のさらなる形態によると、プレース
ホルダ２４、セクション２６、ドキュメント２８の要素
の適切な構造と配置を、ワークフォルダ１０中にユーザ
がいったん定義すると、ワークフォルダ１０はワークフ
ォルダテンプレートとして公開されることができる。テ
ンプレートは、埋め込みタスク１４、フィールド２０、
スクリプト２２に加えて、コンテントノード１２中のプ
レースホルダ２４とセクション２６の、名前と順序を含
めて、ワークフォルダ１０の構造を保存する。ワークフ
ォルダがテンプレートとして公開されたときは、埋め込
みのまたは連結のファイルやフィールド値のような、特
定データを求めに応じて残したり削除したりする選択権
がユーザにあるのが望ましい。ディスカッション１６と
ヒストリ１８データは特定のワークフォルダオブジェク
ト１０に属するのであり、新しく作られるテンプレート
に属するものではないから、落とされる。（そのテンプ
レート自身に関連するヒストリログは、ユーザがさらに
進んで以下のようにテンプレートを編集すれば作成され
る。）いったん１つのテンプレートが作成されると、そ
のテンプレートと同じ構造を持つが特定の作業項目を指
し示す、多重ワークフォルダオブジェクトインスタンス
を作成するのに用いられる。

【００３３】ワークフォルダプログラム初期化データの
一部として、コンテントノード１２と、望ましくはタス
ク１４、ディスカッション１６、ヒストリ１８、フィー
ルド２０、スクリプト２２データ要素とを、含む基本的
なワークフォルダテンプレートが供給される。基本的な
テンプレートのコンテントノード１２は、予め定義され
たプレースホルダ２４、セクション２６、ドキュメント
２８を備えないし、データ要素１４−２２は空である。
このワークフォルダテンプレートは、上述のように、さ
まざまなタスク１４、スクリプト２２、フィールド２０
だけでなく、プレースホルダ２４、セクション２６、ド
キュメント２８を加えることにより、ユーザがカスタマ
イズ化されたワークフォルダを作成するスタートポイン
トとして、役目を果たす。

【００３４】このように、本発明によると、ワークフォ
ルダ１０は、単一データファイルとして蓄えられ処理さ
れる（外部連結ドキュメント以外の）特定作業項目に関
連するあらゆるデータについての、自らをも包含するデ
ータリポジトリである。ワークフォルダ１０の構造は、
特別に順序付けられたプレースホルダ要素２４、セクシ
ョン要素２６、そしてドキュメント２８により定義付け
られ、それらは全てコンテントノード１２の下に蓄えら
れる。好適な実施形態では、ワークフォルダ全体は、オ
ペレーティング環境の内部で他のプログラムにアクセス
可能である。ワークフォルダは、後述のようにワークフ
ォルダユーザインタフェイスを通じて、または自動イン
タフェイスを経た他のプログラムによって、操作するこ
とができる。

【００３５】構造化ワークフォルダ環境はスタンドアロ
ーンコンピュータ環境上で構築可能であるが、構造化ワ
ークフォルダとワークフォルダプログラムはネットワー
クシステム上で実行されるのが望ましい。図５は、本発
明にかかる共有化ワークフォルダを利用したネットワー
クコンピュータ環境の基本図である。ワークフォルダと
ワークフォルダテンプレートは、ネットワーク５２に、
従って多数のユーザ５４−５９に繋がれた電子記憶装置
５０上で維持される。ユーザ端末は、スタンドアローン
コンピュータ（ユーザ５６）や、ローカルプロセッサ６
０に繋がれた端末（ユーザ５４）や、リモートプロセッ
サ６２に繋がれたダム端末（ユーザ５８）や、インター
ネットサーバ６１に繋がれた“Ｗｅｂブラウザ”（ユー
ザ５９）であってよい。ネットワーク５２は１つの又は
それ以上の“外部”ドキュメントリポジトリ６４へのア
クセスをも与える。図５に示される要素間のデータ接続
は、物質的な接続と、遠隔データ連結たとえばセルラモ
デムのようなワイヤレス技術によるものとの両方を、含
むことを認識させられる。

【００３６】ワークフォルダ記憶装置５０は独立の共有
ハードウエア要素として示されているが、当業者なら
ば、この記憶装置要素が物理的に独立した実在物か、ネ
ットワークに接続されたローカルプロセッサまたはリモ
ートプロセッサの内部に含まれるか、分散記憶システム
かは、大した問題ではない。要求されるのは、記憶領域
５０がユーザ各々からアクセス可能であることのみであ
る。ネットワーク５２はどんな構成でもよく、特に、従
来技術のＬＡＮでも、イントラネットでも、インターネ
ットでも、異なるネットワーク構成のいかなる組み合わ
せでもよい、ということも認識される。電子ドキュメン
トリポジトリ６４は、１つまたはそれ以上の、ローカル
ドキュメントマネジメントシステムでも、ＣＤ−ＲＯＭ
ジュークボックスのようなデータアーカイブでも、その
ＵＲＬアドレスによりアクセス可能なインターネットサ
ーバのような他のどんなアクセス可能なデータサーバで
あっても、かまわない。

【００３７】本発明のさらなる形態によると、ワークフ
ォルダ環境は移動データ環境に設定可能である。したが
って、１人のまたはそれ以上のユーザが、ワークフォル
ダを後でネットワークから切り離せるリモートコンピュ
ータまたは移動コンピュータにダウンロードでき、ワー
クフォルダ内部のデータだけではなく遠隔連結ファイル
の内容にもアクセスできることが、必要である。本発明
によると、ワークフォルダは、中央記憶領域から遠隔記
憶領域まで従来技術のネットワークファイル転送プロト
コルを用いて最初に転送される。リモートユニットは、
ワークフォルダが転送されていると検出されるとワーク
フォルダを開始するよう形成されている。そしてリモー
トユニットで稼動するワークフォルダプログラムは、外
部ドキュメントを指し示すワークフォルダ内の全ての連
結を引き出す。それからワークフォルダは、連結された
ドキュメントの一部または全てのネットワークからの取
り出しを開始する。取り出されたドキュメントはリモー
トシステム上の指定領域に蓄えられる。ワークフォルダ
のリモートコピー中のドキュメントリンクは変更され、
それらリンクはリモートシステム上の取り出されたファ
イルを指し示しネットワーク上のファイルを指し示さな
い。リモートユーザがワークフォルダをメインシステム
に転送し返したら、処理は逆に為される。競合チェック
もまた求めに応じて為され得る。

【００３８】特別に好適な実施形態では、ＷＦＸと名づ
けられたワークフォルダ環境は、１つまたはそれ以上の
ワークフォルダを含んでサポートし、マイクロソフト・
エクスチェンジ・メッセージング（Ｍｉｃｒｏｓｏｆｔ
Ｅｘｃｈａｎｇｅ Ｍｅｓｓａｇｉｎｇ）インフラス
トラクチャと連結された、マイクロソフト・ウインドウ
ズ９５（Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ９５）ま
たはウインドウズＮＴ４．０（Ｗｉｎｄｏｗｓ ＮＴ
４．０）環境にて、稼動する。エクスチェンジ・メッセ
ージング（Ｅｘｃｈａｎｇｅ Ｍｅｓｓａｇｉｎｇ）イ
ンフラストラクチャは、パブリックフォルダとして知ら
れる共有メッセージリポジトリ、グローバルにアクセス
可能なアドレスブック、グローバルアドレスブックのど
のユーザにもどんなメッセージをも送信できる能力、と
いうような機能を含んだサポートを、多重ユーザ環境に
対し即座に供給する。マイクロソフト・エクスチェンジ
・メッセージング（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎ
ｇｅ Ｍｅｓｓａｇｉｎｇ） インフラストラクチャ
は、マイクロソフト・バックオフィス・ソフトウエア・
ディベロップメント・キット（Ｍｉｃｒｏｓｏｆｔ Ｂ
ａｃｋＯｆｆｉｃｅＳｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐ
ｍｅｎｔ Ｋｉｔ）（ＳＤＫ）にて、特にマイクロソフ
ト・エクスチェンジ・ソフトウエア・ディベロップメン
ト・キット（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ
Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）
とＭＡＰＩソフトウエア・ディベロップメント・キット
｛ＭＡＰＩ（工業標準Ｍｅｓｓａｇｉｎｇ ＡＰＩ）Ｓ
ｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ｝に
て、定義される。マイクロソフト・エクスチェンジ・ソ
フトウエア・ディベロップメント・キット（Ｍｉｃｒｏ
ｓｏｆｔ Ｅｘｃｈａｎｇｅ Ｓｏｆｔｗａｒｅ Ｄｅ
ｖｅｌｏｐｍｅｎｔ Ｋｉｔ）とＭＡＰＩソフトウエア
・ディベロップメント・キット（ＭＡＰＩ Ｓｏｆｔｗ
ａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）の両方は米
国ワシントン・レッドモンドのマイクロソフトコーポレ
ーションから利用できる。重要なサポーティングドキュ
メンテーションがマイクロソフト・ディベロッパーズ・
ネットワーク・ライブラリ（Ｍｉｃｒｏｓｏｆｔ Ｄｅ
ｖｅｌｏｐｅｒｓ’ Ｎｅｔｗｏｒｋ ｌｉｂｒａｒ
ｙ）の技術記事に見出せる。しかしながら、これらの機
能はすべて、要求すれば、ＷＦＸプログラムに直接に組
みこむこともできる。

【００３９】ハードウエア環境は、マイクロソフト・エ
クスチェンジ・サーバ５．０（Ｍｉｃｒｏｓｏｆｔ Ｅ
ｘｃｈａｎｇｅ Ｓｅｒｖｅｒ ５．０）（またはそれ
以上のバージョン）が稼動するハイエンドネットワーク
サーバと、マイクロソフト・ウインドウズ９５（Ｍｉｃ
ｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ９５）またはマイクロソ
フト・ウインドウズＮＴ４．０（Ｍｉｃｒｏｓｏｆｔ
Ｗｉｎｄｏｗｓ ＮＴ４．０）（またはそれ以上のバー
ジョン）およびマイクロソフト・エクスチェンジ（Ｍｉ
ｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ）またはマイクロソ
フト・アウトルック（Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏ
ｏｋ）クライアントが稼動する１台またはそれ以上のク
ライアントワークステーションとを備えるのが、望まし
い。ＷＦＸワークフォルダプログラムはＣ＋＋プログラ
ミング言語で書かれている。もっとも他のプログラミン
グ言語で書かれていてもよいことは認識される。

【００４０】特に望ましい実施形態では、ＷＦＸプログ
ラムはＭＡＰＩ（工業標準Ｍｅｓｓａｇｉｎｇ ＡＰ
Ｉ）フォームハンドラであり、それは一連のＭＡＰＩメ
ッセージクラスのためのビューアプリケーションとして
エクスチェンジ環境に登録される。この登録されたプロ
セスは、ＷＦＸが引き出すメッセージクラスのあるセッ
トの中のメッセージを、ユーザがビューしようとすると
き、エクスチェンジを指図しそのポイントから前方へい
つもＷＦＸプログラムを引き出す、従来技術のＭＡＰＩ
ファンクションコールを生成するＷＦＸプログラムから
構成される。いったん引き出されると、ＷＦＸプログラ
ムは実際のワークフォルダデータをロードするため追加
のＭＡＰＩファンクションコールを作成する。該ファン
クションコールはマイクロソフト・エクスチェンジ（Ｍ
ｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ）サーバ上のＭＡ
ＰＩメッセージ内に蓄えられる。ユーザがワークフォル
ダの種々のデータ要素を変更しまたは追加し、ワークフ
ォルダをセーブする要求をした後で、ＷＦＸプログラム
は、マイクロソフト・エクスチェンジ（Ｍｉｃｒｏｓｏ
ｆｔ Ｅｘｃｈａｎｇｅ）サーバに対しＭＡＰＩメッセ
ージとしてワークフォルダを書き戻すＭＡＰＩファンク
ションコールを生成する。

【００４１】ユーザがワークフォルダメッセージと取り
組む際に、ＷＦＸプログラムがエクスチェンジとやりと
りをする場所である、追加のインスタンスがある。これ
らは、アサインメントフィーチャ、デッドラインフィー
チャ、ヒストリエクスポートフィーチャ、センドアンド
ムーブトゥフォルダフィーチャ、レコンサイリエイショ
ンフィーチャを含み、それら全てはＷＦＸプログラムに
含まれるのが望ましく、また以下にて論じられる。上記
にてさらに下記にて述べられた全てのケースにおいて、
ＷＦＸプログラムは、従来技術を備えたプログラマには
公知の、従来からあるＭＡＰＩファンクションコール、
そして／または、マイクロソフト・エクスチェンジ・ソ
フトウエア・ディベロップメント・キット（Ｍｉｃｒｏ
ｓｏｆｔＥｘｃｈａｎｇｅ Ｓｏｆｔｗａｒｅ Ｄｅｖ
ｅｌｏｐｍｅｎｔ Ｋｉｔ）ファンクションコールを、
利用する。

【００４２】本発明のこの特定の実施形態では、ＷＦＸ
は、ワークフォルダの機能性を増加させる幾つかのビル
トイン（すなわち予め定義された）イベントスクリプト
を備える。アサインメントフィーチャは、プレースホル
ダやタスクがユーザに割り当てられたとき検出するよう
に、与えられる。このイベントに応答して、ｅ−メイル
メッセージが生成され割り当てられた者に対し割当を知
らせる。デッドラインフィーチャは、ワークフォルダデ
ッドラインが計算されたり変更されたとき検出するよ
う、与えられる。これに応答して、ｅ−メイルメッセー
ジが生成され（マイクロソフト・エクスチェンジ・メイ
ルボックスのような）予め定義されたｅ−メイルアドレ
スに送られる。同様に、デッドラインの終了が検出され
たとき、ｅ−メイルメッセージがＷＦＸプログラムによ
って生成され１人またはそれ以上の予め定義されたユー
ザ（すなわち終結を迎えたタスクまたはプレースホルダ
を割り当てられた者）に送られ、終了を知らせる。

【００４３】ヒストリエクスポートフィーチャは、ワー
クフォルダヒストリを蓄積し、エクスポートするため
に、望ましくは予め定義されたユーザアドレスに送るｅ
−メイルメッセージとして、ワークフォルダヒストリを
フォーマットするために、与えられる。メッセージは、
蓄積されたヒストリが、一点に収集してのレポーティン
グや統計収集のためにデータベースの中にインポートさ
れ得るように、フォーマットされるのが望ましい。

【００４４】センドフィーチャも、１ユーザが別のユー
ザにワークフォルダをｅ−メイルメッセージとして配送
することを許容するために、与えられる。ワークフォル
ダの内容はｅ−メイルメッセージに埋め込まれてもよい
し、メッセージが、より簡単に引き出されるようにワー
クフォルダとのリンクを含んでいてもよい。

【００４５】これらのフィーチャは、異なる内容のｅ−
メイルメッセージをマイクロソフト・エクスチェンジ
（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ）グローバル
アドレスブックのメイルアドレスに送信するマイクロソ
フト・エクスチェンジ（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈ
ａｎｇｅ）ｅ−メイルサブシステムを利用して、実行さ
れる。全てのケースで、従来技術のＭＡＰＩファンクシ
ョンコールはこれらフィーチャを成し遂げるために利用
される。

【００４６】センドトゥフォルダフィーチャは、ユーザ
にワークフォルダをマイクロソフト・エクスチェンジ
（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ）メッセージ
記憶領域内部の別の位置に移動させる。このことは、マ
イクロソフト・エクスチェンジ・ソフトウエア・ディベ
ロップメント・キット（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈ
ａｎｇｅ Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ
Ｋｉｔ）に詳述されている従来技術のファンクション
コールを通じて、なされる。

【００４７】特に好適な実施形態では、ワークフォルダ
テンプレートは、あらゆるフォルダフォームライブラリ
に加えてオーガニゼーションアンドパーソナルフォーム
ライブラリを含んだマイクロソフト・エクスチェンジ
（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ）フォームサ
ブシステムのどこでも、蓄積可能なマイクロソフト・エ
クスチェンジ（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇ
ｅ）フォームとして実行される。どんなワークフォルダ
メッセージも、ＷＦＸプログラムに与えられたメカニズ
ムを利用して、ワークフォルダメッセージをユーザ仕様
のフォームライブラリ中のマイクロソフト・エクスチェ
ンジ（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ）フォー
ムとして公開することにより、ワークフォルダテンプレ
ートに成り得る。これらのメカニズムは、ワークフォル
ダメッセージ中に目下存在するワークフォルダデータを
取りだし、さらにユーザが新しいワークフォルダメッセ
ージのテンプレートとして利用できる新しいマイクロソ
フト・エクスチェンジ（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈ
ａｎｇｅ）フォームを作成するために、ディベロップメ
ント・キット（Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）に記
述されているような、マイクロソフト・エクスチェンジ
・ソフトウエア（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇ
ｅ Ｓｏｆｔｗａｒｅ）に対するファンクションコール
を生成する。

【００４８】フォームはマイクロソフト・エクスチェン
ジ（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ）に対し公
開されるので、ユーザが“ｐｕｂｌｉｃ（公開）”とし
て印を付けたワークフォルダフィールドは、マイクロソ
フト・エクスチェンジ（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈ
ａｎｇｅ）環境においては、ネームドプロパティにな
る。フォームを公開しそれらが公開されるべきことを指
示する経過の間に、これらのフィールド名やデータタイ
プをマイクロソフト・エクスチェンジ（Ｍｉｃｒｏｓｏ
ｆｔ Ｅｘｃｈａｎｇｅ）に供給することにより、この
ことは為される。いったんフォームが公開されフィール
ドがネームドプロパティになると、フィールドはそれか
らサードパーティのアプリケーションによって検索可能
となり、さらに表示可能になりユーザのマイクロソフト
・エクスチェンジ（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎ
ｇｅ）クライアント中のワークフォルダメッセージをグ
ループ化しフィルタをかけ分類するのに用いられる。

【００４９】ＷＦＸワークフォルダプログラムは、ワー
クフォルダメッセージがなくとも、ワークフォルダをベ
ースとしたマイクロソフト・エクスチェンジ（Ｍｉｃｒ
ｏｓｏｆｔ Ｅｘｃｈａｎｇｅ）フォームをビューし編
集するのにも用いることができる。これはテンプレート
エディティングモードと呼ばれる。上述のメカニズムを
通してワークフォルダをロードするよりも、ＷＦＸワー
クフォルダプログラムは、ユーザ仕様のワークフォルダ
ベースのフォームを編集のため直接ロードするマイクロ
ソフト・エクスチェンジ・ソフトウエア（Ｍｉｃｒｏｓ
ｏｆｔ Ｅｘｃｈａｎｇｅ Ｓｏｆｔｗａｒｅ）ファン
クションコールを生成する。いったんロードされると、
ＷＦＸプログラム内で利用可能なセーブと公開の機能
は、再びマイクロソフト・エクスチェンジ・ソフトウエ
ア（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ Ｓｏｆｔ
ｗａｒｅ）ファンクションコールの利用を通じて、マイ
クロソフト・エクスチェンジ（Ｍｉｃｒｏｓｏｆｔ Ｅ
ｘｃｈａｎｇｅ）フォームサブシステムの同じ位置かま
たは異なる位置にフォームを再び発行（公開）する。

【００５０】この特定の実施形態では、ＷＦＸプログラ
ムは、各々のワークフォルダをエクスチェンジメッセー
ジとしてフォーマットする。したがって、多重ユーザが
同時に同じワークフォルダにアクセスし作業できるよう
に、ワークフォルダはエクスチェンジパブリックフォル
ダに置くことができる。ＷＦＸはエクスチェンジメイル
インフラストラクチャを作業の分配と処理のために利用
する。このように、ワークフォルダは、１ユーザから他
のユーザに直接転送することもできる。フィールドデー
タ要素は、エクスチェンジネームドプロパティとして定
義することにより、サードパーティアプリケーションに
も利用可能になる。ワークフォルダテンプレートはエク
スチェンジフォームサブシステムの内部に蓄積される。
各々のワークフォルダテンプレートは、ユーザがワーク
フォルダテンプレートを用いてドキュメントを作成する
ときエクスチェンジにＷＦＸプログラムをコールさせる
アプリケーションデータによってタグ付けされている。

【００５１】本発明の好ましい実施形態では、上記レコ
ンサイリエイションフィーチャには、サーバサイドの実
行と、クライアントサイドの実行とがある。両構成と
も、マイクロソフト・エクスチェンジ・ソフトウエア
（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ Ｓｏｆｔｗ
ａｒｅ）ファンクションコールとＭＡＰＩファンクショ
ンコールとの組み合わせを利用する。それは以下の目的
のためである。（１）ワークフォルダメッセージがエク
スチェンジ競合メッセージを生成したことを検出するた
め。（２）競合情報を抽出しユーザに差し出すため。そ
して（３）競合を解決するため。ワークフォルダが競合
を調停するのが好ましいのであるから、標準的なマイク
ロソフト・エクスチェンジ（Ｍｉｃｒｏｓｏｆｔ Ｅｘ
ｃｈａｎｇｅ）競合ハンドリングメカニズムを放棄する
ことが必要である。当業者には明らかな、マイクロソフ
ト・エクスチェンジ（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａ
ｎｇｅ）とＭＡＰＩソフトウエア・ディベロップメント
・キット（ＭＡＰＩ Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏ
ｐｍｅｎｔ Ｋｉｔｓ）との標準的主要点を利用するこ
とにより、このことは容易に達成し得る。

【００５２】特定の好ましい実施形態が、ＷＦＸプログ
ラムにより生成される種々のコンピュータスクリーン表
示を示す図６−図１５を参照しつつ、論じられる。一般
に、ＷＦＸプログラムは、ワークフォルダ情報をユーザ
に、プルダウンメニューとツールバーを備えた従来技術
のマイクロソフト・ウインドウズ（Ｍｉｃｒｏｓｏｆｔ
Ｗｉｎｄｏｗｓ）ＧＵＩプロトコルを通じて提供す
る。ワークフォルダは、挿入、削除、複写、切取、貼付
のような標準的コマンドを用いて、作成し編集すること
ができる。

【００５３】望ましい実施形態は、ユーザにワークフォ
ルダへの間違った変更を訂正させる訂正オペレーション
を、サポートする。訂正オペレーションは、公知技術で
ある。しかしながら、ワークフォルダの修正が訂正され
たとき、そのワークフォルダ内部のヒストリログもま
た、訂正された修正部への言及部分が除去されるよう更
新されなければならない。１レベルだけの訂正機能がサ
ポートされているのが望ましい。しかし、１レベル以上
が、複雑に増大したプログラムコードにより、サポート
可能である。

【００５４】図６は基本的なＷＦＸワークフォルダ処理
スクリーン１００の図である。スクリーンは上部内容区
画１０２と下部タブ区画１０４とから構成される。内容
区画１０２は、特定のワークフォルダオブジェクト１０
のコンテントノード１２の下に蓄えられる構造とデータ
を系統立て表示するために利用される。図６では、定義
されたワークフォルダはなく、よって内容区画１０２は
空である。

【００５５】タブ区画１０４は、ワークフォルダ１０に
蓄えられているフィールド２０、タスク１４、ディスカ
ッション１６、ヒストリ１８データオブジェクトに蓄え
られる情報を表示する。それぞれのデータオブジェクト
１４−２０の内容は、適切なフィールド、タスク、ディ
スカッション、またはヒストリのタブを選択することに
よりアクセス可能である。さらに、基本的なワークフォ
ルダスクリーン１００は、従来技術のプルダウンメニュ
項目１１６とアイコンドリブンのツールバーを備える。
ドキュメント２８、セクション２６、そしてプレースホ
ルダのようなデータオブジェクトは、メニュシステムか
ら選んだ適切な“挿入”や“新しいオブジェクト”など
のコマンドを通してまたは一連のマウスクリックを経
て、ユーザにより追加される。

【００５６】図７は、特許出願作業項目を系統立てるた
めに形成されたワークフォルダ１０の図である。内容区
画１０２が全スクリーンを埋めるまで広げられているこ
とを銘記すべきである。該ワークフォルダ１０は幾つか
のセクション２６を備えるように構成されている。それ
ぞれのセクションウインドウ名１２０はセクション２６
の名前に対応する。この例では、ワークフォルダは、ク
ライアント対応、パテントオフィス対応、図面、そして
外国出願の、セクションに分けられている。

【００５７】各々のセクション１２０内部には、たくさ
んのプレースホルダ２４がある。空のプレースホルダ
は、プレースホルダ名１２４のとなりの空のトレイ１２
２として表されている。満たされたプレースホルダ２４
は、プレースホルダ２４に蓄えられた、またはプレース
ホルダが指し示すドキュメントタイプを表すアイコン１
２６をのせたトレイとして表現されている。ユーザは、
適切なプレースホルダを選び加えるべき適切なドキュメ
ントを指し示すことで、たとえばドキュメントのアドレ
スをタイプしたり、ファイルマネジャアプリケーション
からドキュメントを選んだり、カットアンドペースト経
由したりすることで、プレースホルダを満たすことがで
きる。プレースホルダが満たされると、適切なアイコン
イメージが従来技術の手段を通ってオペレーティングシ
ステムにより引き出される。さらに、ドキュメント位置
とドキュメントタイプの情報が、プレースホルダ名に続
いて、ステータスラインすなわち１３０、１３２に、与
えられている。

【００５８】この例では、プレースホルダ１２６は外部
インターネットドキュメントへのＵＲＬリンクを含んで
おり、プレースホルダ１３４はユーザの“Ｃ”ドライブ
上に位置するマイクロソフト・ワード（Ｍｉｃｒｏｓｏ
ｆｔ ｗｏｒｄ）ドキュメントへのポインタを含む。満
たされていないプレースホルダ１２８の番号がワークフ
ォルダウインドウ１００の底部のステータスライン１２
９に示される。

【００５９】このように、本発明の１つの形態による
と、ＷＦＸプログラムは、満たされないプレースホル
ダ、満たされたプレースホルダ、そしてプレースホルダ
内にないドキュメントとの間には目に見える形の区別が
与えられている。ここで、プレースホルダ内にないドキ
ュメントは、プレースホルダ“ｂａｓｋｅｔ（バスケッ
ト）”（示されず。）と切り離されたアイコンとして表
示されている。テンプレートから持ちこまれたワークフ
ォルダ要素と“カスタマイズされた”要素との間にも、
これら項目を異なる色で表示することによって、目に見
える区別が与えられている。

【００６０】図８は、フィールド・タブ１０６を選択し
た、タブ区画１０４を示す。上述で論じたように、フィ
ールド要素２０は、従来技術のフォームプロセッサを経
て定義される従来技術のフォーム処理データ要素を含
む。フィールドは、挿入し、削除し、記録し、種々の特
性を割り付けることができる。この例では、フィールド
は、クライアントと特許提出と発行日付とシリアル番号
とに関する情報を定義するのに用いられている。

【００６１】さらに、図８は、プレースホルダ１３７が
ステータスライン１３８に示されるように添付されたビ
ットマップイメージで満たされたことを示す。“出願時
図面（Ｄｒａｆｔ Ａｐｐｌｉｃａｔｉｏｎ）”プレー
スホルダ１３９のステータスラインは、プレースホルダ
ステータス１４０｛ここでは“ｃｏｍｐｌｅｔｅｄ（完
了）”｝と、プレースホルダがユーザ１４２に割り当て
られたことと、プレースホルダを満たすデッドライン１
４４とを、示す。

【００６２】図９は、タスク・タブ１０８を選択した、
タブ区画１０４を示す。図９では、２つのタスク１４
８、１５０が定義されている。タスクは、ポップアップ
ダイアログボックスのような従来技術のインプットメカ
ニズムを利用することにより定義可能で更新可能であ
る。この例では、両タスクは“ｎｏｔ ｓｔａｒｔｅｄ
（開始せず）”のステータスである。タスク１４８
（“出願の準備”）は絶対的デッドラインを有する。対
照的に、タスク１５０（“出願の提出”）は出願の準備
タスク１４８の完了日に左右される相対的デッドライン
を有する。タスクは独特のタスクアイコン１５２により
視覚的に表される。

【００６３】図１０は、ディスカッション・タブ１１０
を選択した、タブ区画１０４を示す。各々のコメント１
５６、１５８は適切な名前のトピックフォルダ１５４の
下に蓄えられている。コメントは、コメント１５８に対
する返事が元々のコメント１５６と繋がるように、連続
したディスカッションとして表される。コメントタイト
ル１６０が選択されると、コメントのテキスト１６２が
コメントウインドウに表示される。

【００６４】図１１は、ヒストリ・タブ１１２を選択し
た、タブ区画１０４を示す。上述で論じたように、ワー
クフォルダ１０の構造に対する変更の各々は、ヒストリ
データ要素１８に記録される。ヒストリタブ１１２が選
択されると、ヒストリログ１６４が表示される。ログ１
６４における各々の要素のヒストリデータは、カラムヘ
ッダバー１６６に対応してカラム上に表示される。古い
値と新しい値のみならず、誰が修正をしたか、いつした
か、何を変えたか、を含む、修正作業の全属性は、表示
可能である。全ヒストリログを表示するのに加えて、ユ
ーザは、項目を選びヒストリファンクションを利用する
ことで、セクションやプレースホルダのような、特定の
プレースホルダ要素に関連するヒストリを、引き出すこ
とができる。

【００６５】図１２は、イベントスクリプトエディタ１
６８を示す。イベントスクリプトは、従来技術のテキス
トエディタを利用して編集することができる。一方で、
ビジュアルベーシックスクリプトやジャバスクリプトの
ようなスクリプト言語にて、スクリプトを記述するため
の特別のアプリケーションも利用できる。この単純な例
であるスクリプトは、ビジュアルベーシックにて記述さ
れており、フィールドのデータを変更することにより引
き動かされるワークフォルダイベントに対応してメッセ
ージを送るものである。スクリプトがスクリプトデータ
要素２２に蓄えられると、ワークフォルダ・スクリプト
・プロセッサが、イベントデータハンドラと連動して、
選択されたイベントをモニタする。イベントが発生する
と、スクリプトは上述にて論じられたように自動的に実
行される。図１３は図１２のスクリプトの実行結果を示
す。

【００６６】図１４は、競合調停手続きの間にユーザに
与えられる競合調停対話ボックス１７０を示す。本発明
のさらなる形態によると、ワークフォルダプログラム
は、２人またはそれ以上のユーザが１つのワークフォル
ダの内容を更新するときデータの競合を防ぐためのロッ
キングメカニズムを必要としないのが望ましい。本発明
のこの形態によると、２人のユーザが１つのワークフォ
ルダに同時変更をかけその後セーブするとき、それら変
更は直接的に競合しているのか、それとも変更はマージ
しうるものなのか、を確定するためにそれら変更が分析
される。たとえば、ユーザ１がドキュメントをプレース
ホルダに加え、ユーザ２が無関係のアドレスフィールド
にデータを入力するのならば、変更は競合しておらずよ
ってマージすることができる。ワークフォルダがセーブ
され別のユーザの変更との競合が検出されると、すなわ
ちユーザ１とユーザ２が同じプレースホルダに異なるド
キュメントを加えたのならば、自らの変更が競合を生じ
たユーザ（典型的には更新されたワークフォルダをセー
ブする第２のユーザ）には、競合が解決し得るような競
合解決データが与えられる。この例では、ユーザの変更
は２つの競合を生じさせた。示されているように、競合
対話ボックス１７０は、変更されたデータ要素１７２、
ユーザによりなされた変更１７４、先のユーザにより入
力された競合する変更１７６、そしてユーザ達のＩＤを
示す。この情報を与えられて、ユーザは、２つの値のど
ちらを保存すべきかを選択することにより競合を解決す
ることができる。該選択は個別に行うことができるし、
またはユーザは、ＩＤを与え、そのＩＤによる変更を全
て、たとえば適切なファンクション・ボタン１８０を押
すことにより、保存せよというような指示を出すことも
できる。

【００６７】その一方で、競合の調停は引き伸ばすこと
ができる。この引き伸ばされた競合の調停は、ネットワ
ーク環境内の、鏡像を作成するさまざまのサイトにわた
って、ワークフォルダが自動複写されるときに、実行さ
れるのが望ましい。この環境では、競合は複写の最中に
検出され得、この最中には影響を受けるユーザは直接の
競合調停対話に参加しようとしても利用不可能である。
この情況では、競合項目は、代替用のサブ項目としてセ
ーブされ競合状態の識別が付けられる。該ワークフォル
ダがアクセスされると、競合状態の項目は、ユーザがど
の変更を保存すべきか選択し得るように識別されてい
る。

【００６８】図１５は、調停が必要な競合が発生したが
調停が行われないときに（すなわち人手によらない調停
中に）生成される、競合中のサブ項目を示すスクリーン
ディスプレイである。競合要素を備えたワークフォルダ
がビューされると、競合要素の両方の版が、競合ヘディ
ング１８２の下にサブ要素１８４、１８６として与えら
れる。この例では、あるユーザが発明開示プレースホル
ダのステータスを「開始された」と定義したところ、別
のユーザが該ステータスを「開始せず」と定義したため
に、競合が発生した。適正な権限を備えた１人のユーザ
が、２つのサブ項目１８４、１８６のいずれを保存すべ
きか選択すれば、競合は解決する。

【００６９】本発明は、それについてのある好適な実施
形態を特に参照しながら詳細に述べられた。しかし本発
明の精神と範囲の中で変更修正が可能であることは理解
される。

【図面の簡単な説明】

【図１】 本発明にかかる、ワークフォルダ中の種々の
データ要素の構造化された関係を示す図。

【図２】 図１のプレイスホルダデータ項目の構造上
の、かつデータの内容を示す図。

【図３】 本発明の１つの実施形態にかかる、イベント
の生成と処理を示すフローチャート（１）。

【図４】 本発明の１つの実施形態にかかる、イベント
の生成と処理を示すフローチャート（２）。

【図５】 本発明にかかる、共有化されたワークフォル
ダを利用したネットワークコンピュータ環境のシステム
図。

【図６】 本発明の好適な実施形態にかかる、基本的な
ワークフォルダプログラム処理スクリーンの例示図。

【図７】 特許出願作業項目を系統立てるために形成さ
れたワークフォルダを用いた、本発明の好適な実施形態
にかかる、プログラムスクリーン。

【図８】 フィールドタブを備え選択されたタブ区画を
示す、本発明の好適な実施形態にかかるプログラムスク
リーン。

【図９】 タスクタブを備え選択されたタブ区画を示
す、本発明の好適な実施形態にかかるプログラムスクリ
ーン。

【図１０】 ディスカッションタブを備え選択されたタ
ブ区画を示す、本発明の好適な実施形態にかかるプログ
ラムスクリーン。

【図１１】 ヒストリタブを備え選択されたタブ区画を
示す、本発明の好適な実施形態にかかるプログラムスク
リーン。

【図１２】 イベントスクリプトエディタを示す、本発
明の好適な実施形態にかかるプログラムスクリーン。

【図１３】 図１２に示されたスクリプトを実行した結
果を示すプログラムスクリーン。

【図１４】 本発明の好適な実施形態にかかる競合調停
対話ボックス。

【図１５】 調停を要求する競合が生じたが調停が為さ
れないときに生成される競合サブ項目を示す、本発明の
好適な実施形態にかかるプログラムスクリーン。

【符号の説明】

１０・・・ワークフォルダ、１２・・・コンテント、１
４・・・タスク、１６・・・ディスカッション、１８・
・・ヒストリ、２０・・・フィールド、２２・・・スク
リプト、２４・・・プレースホルダ、２６・・・セクシ
ョン、２８・・・、ドキュメント、５０・・・共有ワー
クフォルダとテンプレート、５２・・・ネットワーク、
６４・・・電子ドキュメントリポジトリ、１００・・・
ＷＦＸワークフォルダ処理スクリーン、１０２・・・上
部内容区画、１０４・・・下部タブ区画、１７０・・・
競合調停対話ボックス

───────────────────────────────────────────────────── フロントページの続き (71)出願人 597097009 Ｐ．Ｏ．Ｂｏｘ 66，Ｓｔａｔｉｏｎ Ｒ ｏａｄ，Ｈｅｍｅｌ Ｈｅｍｐｓｔｅａ ｄ，Ｈｅｒｔｆｏｒｄｓｈｉｒｅ ＨＰ11 ＪＵ，Ｕｎｉｔｅｄ Ｋｉｎｇｄｏｍ (72)発明者 ダニエル・バーグ アメリカ合衆国06897コネチカット州ウィ ルトン、アームガード・レイン20番 (72)発明者 ランド・スカラード アメリカ合衆国10024ニューヨーク州ニュ ーヨーク、ウエスト・エイティシックス ス・ストリート340番、アパートメント９ ディ (72)発明者 プラディープ・アール・シーマ アメリカ合衆国11780ニューヨーク州セン ト・ジェイムズ、ジェファーソン・アベニ ュー198ビー番、アパートメント２シー (72)発明者 マーク・エイ・ソロモン アメリカ合衆国11758ニューヨーク州ノー ス・マサペカ、ノース・シラクース・アベ ニュー280番

Claims (3)

【特許請求の範囲】
1. 【請求項１】 内部にレコードを蓄えるための数多くの
   記憶位置を備えた計算機読み取り可能記憶部において、 電子ドキュメントを蓄積し系統立てるための、少なくと
   も１つの構造化ワークフォルダを備え、 上記ワークフォルダは基本データを蓄積するコンテント
   要素を備え、 上記コンテント要素は１つまたはそれ以上のプレースホ
   ルダを備え、 上記プレースホルダはそれを経由して上記ワークフォル
   ダに付加される予定であるドキュメントを指示するため
   のものである、計算機読み取り可能記憶部。
2. 【請求項２】 内部にレコードを蓄えるための数多くの
   記憶位置を備えた計算機読み取り可能記憶部において、 電子ドキュメントを蓄積し系統立てるための１つの構造
   化ワークフォルダの１つまたはそれ以上の特定の実例を
   作成するために用いられるテンプレートを備え、 上記テンプレートはコンテント要素を備え、 上記コンテント要素はプレースホルダを備え、 上記プレースホルダは上記ワークフォルダ実例に連結さ
   れる予定であるドキュメントを指示するためのものであ
   り、 上記ドキュメントは上記ワークフォルダ実例中の上記プ
   レースホルダの特定の実例を経由して上記ワークフォル
   ダ実例と連結可能である、計算機読み取り可能記憶部。
3. 【請求項３】 計算機読み取り可能記憶部内に、電子ド
   キュメントを系統立てるための構造化ワークフォルダを
   作成する方法において、 基本データを蓄積するためのコンテント要素を内部に含
   む、構造化ワークフォルダ・ルート・ノードを作成する
   工程と、 上記ワークフォルダと連結される予定であるドキュメン
   トを指示し、該連結は自らを経由して為される、少なく
   とも１つのプレースホルダを作成する工程と、を備える
   ことを特徴とする、構造化ワークフォルダ作成方法。