JPH08511117A - プレース・オブジェクト・システム - Google Patents

Abstract

(57)【要約】 情報をプレース・オブジェクト内に編成し、そのプレース・オブジェクトをユーザに表示する方法と装置が開示されている。プレース・オブジェクトは、人、物およびその他のプレースを参照する他のプレースを収容するために作成される。作成されたプレース・オブジェクトは、そのあとで多数のユーザがアクセスすることができる。従って、本発明によれば、あるプレース・オブジェクトをアクセスしたユーザは、協同に作業を行って、相互に情報をやりとりすることができる。

Description

【発明の詳細な説明】 プレース・オブジェクト・システム 関連特許出願の相互参照 本出願は、1992年12月23日出願の特許出願（発明の名称「オブジェクト指向フ レームワーク・システム」（Object Oriented Framework System）、発明者Debr a L.Orton、David B.Goldsmith、Christopher P．Moeller、およびAndrew G.Hen inger、承継人Taligent Inc.）の関連出願であり、その開示内容は引用により本 明細書の一部を構成するものである。また、本出願は特許出願（発明の名称「コ ンカレント・フレームワーク・システム」（Concurrent Framework System）、 発明者Jack Palevich他、承継人Taligent Inc.）の関連出願でもあり、その開示 内容は引用により本明細書の一部を構成するものである。 発明の分野 本発明は、一般的には、オブジェクト指向オペレーティング・システムにおい て種々の情報を編成し、アクセスする方法およびシステムに関し、より具 体的には、異種コンテナ・オブジェクト（distinct container objects）内でユ ーザがやりとり（interaction）することに関する。 発明の背景 インタフェースにコミュニティ・センス（sense of community）をもたせると いう設計思想を中心に構築されるユーザ・インタフェースを提供することがます ます重要になっている。このコミュニティ・センスは、人やプレース（場所）、 その他にツール、器具、文房具、ドキュメントといった項目を図形表現すること に由来している。エルゴノミック・インタフェース（ergonomic interface−人 間工学的インタフェース）を提供する初期の試みでは、Xerox Starコンピュータ ・システムとそれに追随するシステムに見られるような、さらには、米国特許第 5,107,443号、第5,072,412号、第5,159,669号、第4,974,173号および第5,121,47 8号に特許されているようなデスクトップ・メタフォア（desktop metaphor）が 使用されていた。 発明の概要 コンピュータ・システムのユーザ、特に未経験の ユーザは、実世界の特性を備えた環境を作り出すアプリケーションの恩益を受け ている。特に、アプリケーションに未経験のユーザは使い慣れた参照フレーム（ frame of reference）を利用すると、アプリケーションの概念を容易に把握でき るであろう。好適実施例では、他のオブジェクトをそこに収めておくことができ るプレース・オブジェクト（place object）のセットをユーザが作成できるよう にすることによって、このような環境を提供している。 好適実施例によれば、コンピュータ・システムにおける情報は、コンピュータ のメモリ内の複数のプレース・オブジェクト内に編成される。プレース・オブジ ェクトへのアクセスは、マウスやその他のカーソル位置付けデバイスによって、 カーソル文字をそのプレース・オブジェクトの上に置くことにより行われる。そ のあとで、そのプレース・オブジェクトが選択されると、プレース・オブジェク トに関連するメソッドが関連のユーザ・インタフェースをユーザに提示して、プ レース・オブジェクトの使用を容易にする。 図面の簡単な説明 本発明の上記および他の目的、側面および利点を理解しやすくするために、添 付図面を参照して本発明の好適実施例について、以下で詳しく説明する。添付図 面において、 第１図は、本発明の好適実施例によるコンピュータ・システムを示すブロック 図である。 第２図は、本発明の好適実施例によるウィンドウ内のプレース・オブジェクト とデスクトップのプレース・オブジェクトを示す図である。 第３図は、本発明の好適実施例によるウィンドウ内のプレース・オブジェクト の拡大を示す図である。 第４図は、本発明の好適実施例によるワークステーション内のユーザプレース ・オブジェクトの典型的な階層を示す図である。 第５図は、本発明の好適実施例によるインビテーション（招待状）を示す図で ある。 第６図は、本発明の好適実施例によるトラベル・バッグを示す図である。 第７図は、本発明の好適実施例によるハイレベルの制御の流れを示すフローチ ャートである。 第８図は、本発明の好適実施例による詳細ロジックを示すフローチャートであ る。 第９図は、本発明の好適実施例による詳細ロジックを示すフローチャートであ る。 第10図は、本発明の好適実施例による詳細ロジックを示すフローチャートであ る。 第11図は、本発明の好適実施例による詳細ロジックを示すフローチャートであ る。 第12図は、本発明の好適実施例による他のVDL図例の中で用いられている用語 を説明するビジュアル設計言語（Visual Design Language - VDL）のキーを示す 図である。 第13図は、本発明の好適実施例によるBoochダイアグラムを示す図である。 第14図は、本発明の好適実施例による別々の環境のプレゼンテーションを示す 図である。 第15図は、ドキュメントおよびワークスペース・アイテムを、ユーザがそこに ストアしておくことができる単一の「ホーム」プレースをもつ、本発明の好適実 施例によるあるマシンを示す図である。 第16図は、ホームまたはデフォルトのプレース、ログオフする前にユーザがそ こに置かれていた最後のプレース、ユーザが選択できるプレースの選択項目を表 示する、本発明の好適実施例によるいくつかのダイアログ例を示す図である。 第17図は、あるプレースにいる人々を表示している、本発明の好適実施例によ る人物ストリップを示す図である。 第18図は、本発明の好適実施例による、人物存在管理に関係するモデルのメソ ッドを示す図である。 第19図は、人物オブジェクトがプレース・モデルに追加されるときの、本発明 の好適実施例によるプロセスを示す図である。 第20図および第21図は本発明の好適実施例によるプレースとワークプレースと の関係を示す図である。 第22図は、本発明の好適実施例に従ってドキュメント・プレゼンテーション・ ステートを維持するためにユーザ情報と一緒にストアされるオブジェクトを示す 図である。 第23図は、本発明の好適実施例に従ってプレース・ドキュメント・ポリシ・オ ブジェクトを採用するコマンド・サブクラスを示しているBoochダイアグラムで ある。 第24図は、本発明の好適実施例に従ってあるプレース内のドキュメント上のセ ーブされたプレゼンテーションをオープンするときに実行されるステップを示す 図である。 第25図は、本発明の好適実施例に従ってあるプレース内のドキュメント上のプ レゼンテーションをクローズするときに実行されるステップを示す図である。 第26図は本発明の好適実施例による埋込み（embedment）と包含（containment ）の違いを示す図である。 第27図は、本発明の好適実施例に従ってフォルダを作成する様子を示すVDLダ イアグラムである。 第28図は、本発明の好適実施例に従ってフォルダ・ロジックをコピーする様子 を示すVDLダイアグラムである。 第29図は、本発明の好適実施例に従ってフォルダ・ロジックを移動する様子を 示すVDLダイアグラムである。 第30図は、本発明の好適実施例に従ってフォルダ・ロジックを移動する様子を 示すVDLダイアグラムである。 第31図は、本発明の好適実施例に従ってフォルダ・ロジックを移動する様子を 示すVDLダイアグラムである。 本発明の好適実施例の詳細な説明 ユーザはプレース（place-場所）を、人、プレースおよび物が存在するエリア として概念化する。プレース・オブジェクト（place object）は、実際のロケー ションの形式的および機能的特性を取り込むために作成される。プレース・オブ ジェクトは、情報を親しみやすく、意味のあるコンテキストに編成し、セグメン ト化することにより、実世界の知識を基礎にして構築される。さらに、本発明の 好適実施例では、ユーザとコンピュータ・システムとの間で意味のあるやりとり （interaction−対話）を行うためのコンテキストが用意されている。 好適実施例では、情報は「プレース（place）−場所」と呼ばれる、持続性の ある構造内に編成される。 人やドキュメントなどの他のオブジェクトの形体をもつ情報は、プレース・オブ ジェクト間で適当にセグメント化される。一例として、ポストオフィス・プレー ス（post office place）は、通信資源に関係するオブジェクトの集まりを収容 するように作られる。プレース・オブジェクトは、あるプレースに係わりをもつ 人に関するオブジェクトを収容するように作ることもできる。別の例として、ラ イブラリ（図書館）プレースは大量の図書とライブラリアン（司書）を表すオブ ジェクトが置かれるプレースとして作られる。この場合、利用者はライブラリ・ プレースをアクセスし、大量の図書の中から必要とする図書を探し出すために分 類を行ってから、その図書を検索することが可能になる。他の方法として、利用 者は、ライブラリアンを表すオブジェクト内に収められている情報によってライ ブラリアンに連絡し、ライブラリアンに文献検索を行わせることも可能である。 コンピュータ・システム 好適実施例は、好ましくは、IBM（登録商標）社PS/2（登録商標）またはアッ プル（登録商標）社マッキントッシュ（登録商標）コンピュータなどのパーソナ ル・コンピュータ上に置かれているオペレーティング・システムの環境（コンテ キスト）で実施される。 代表的なハードウェア環境は第１図に示されているが、同図は、従来のマイクロ プロセッサのような中央演算処理ユニット10、およびシステム・バス12を介して 相互に接続された複数の他のユニットを装備した、本発明の好適実施例によるワ ークステーションの代表的ハードウェア構成を示している。第１図に示すワーク ステーションは、ランダム・アクセス・メモリ（RAM）14、リードオンリ・メモ リ（ROM）16、ディスク・ユニット20などの周辺デバイスをバスに接続するため の入出力アダプタ18、キーボード24、マウス26、スピーカ28、マイクロホン32、 および／またはタッチ・スクリーン・デバイス（図示せず）などのユーザ・イン タフェース・デバイスをバスに接続するためのユーザ・インタフェース・アダプ タ22、ワークステーションをデータ処理ネットワークに接続するための通信アダ プタ34、およびバスをディスプレイ・デバイス38に接続するための表示アダプタ 36を装備している。ワークステーションには、アップル社System/7（登録商標） オペレーティング・システムなどのオペレーティング・システムが置かれている 。ドキュメント・フレームワーク・アーキテクチャ（document framework archi tecture）はRAM14に置かれており、CPU10の制御の下で、本発明の好適実施例を 実現することを受け持っている。 好適実施例では、本発明は、オブジェクト指向プロ グラミング技法を使用してC++プログラミング言語で書かれている。この分野に 精通しているものならば容易に理解されるように、オブジェクト指向プログラミ ング（Object-Oriented Programming-OOP）のオブジェクトは、データ構造とデ ータに対するオペレーション（操作、演算など）からなるソフトウェア・エンテ ィティ（software entity）である。これらのエレメントが協力し合うことによ り、オブジェクトは、そのデータ・エレメントで表されたその特性、およびその データ操作関数（data manupulation functions）で表されたその作用（behavio r）からとらえて、ほとんどどのような実世界のエンティティでもモデル化する ことができる。この方法によると、オブジェクトは、人やコンピュータなどの具 体物をモデル化することができ、また、数や幾何学的概念などの抽象概念をモデ ル化することができる。オブジェクト・テクノロジの利点は次の３つの基本的原 理から得られるものである。それは、カプセル化（encapsulation）、多態（pol ymorphism）および継承（inheritance）である。 オブジェクトは、そのデータの内部構造とその関数が実行されるときのアルゴ リズムを隠蔽する。つまりカプセル化する。これらのインプリメンテーション細 部を見せる代わりに、オブジェクトは、外部情報（extraneous information）の ないクリーンな形でその抽象化（abstractions）を表しているインタフェースを 提示する。多態はカプセル化をさらに一歩進めたものである。この考え方は、多 数の形体をもつ、１つのインタフェースである。あるソフトウェア・コンポーネ ントは、別のコンポーネントがなんであるかを正確に知らなくても、その別のコ ンポーネントを要求することができる。要求を受け取ったコンポーネントはその 要求を解釈し、その要求をどのように実行すべきかを、その変数とデータに従っ て判断する。三番目の原理である継承によれば、開発者は既存の設計やコードを 再利用することができる。この機能を利用すると、開発者はソフトウェアを初め から作ることが回避される。むしろ、継承を通して、開発者は作用を継承するサ ブクラスを派生し、その作用を開発者独自の要求に合ったものにカストマイズす ることができる。 従来のアプローチでは、オブジェクトとクラス・ライブラリを手続き的環境で 階層化する方法がとられていた。市販されている多くのアプリケーション・フレ ームワークはこの設計手法を採用している。この設計では、モノリシック・オペ レーティング・システム（monolithic operating system）の上に１つまたは２ つ以上のオブジェクト層が置かれている。このアプローチでは、カプセル化、多 態および継承のすべての原理がオブジェクト層に採用され、手続き的プログラミ ング技法を大幅に改善しているが、このアプローチにはいくつかの制約がある。 これらの問題は、開発者 が自身のオブジェクトを再利用することは容易であるが、他のシステムからのオ ブジェクトを使用することが困難であるため、手続き的オペレーティング・シス テム（OS）のコールを使用して、下位の非オブジェクト層まで到達する必要があ ることに起因している。 オブジェクト指向プログラミングがもつもう１つの側面は、アプリケーション を開発するのにフレームワーク・アプローチを採用していることである。フレー ムワークの最も合理的な定義の１つとして、イリノイ大学のRalph E.JohnsonとP urdueのVincent F.Russoによるものがある。両氏の1991年の論文「オブジェクト 指向設計の再利用」（Reusing Object-Oriented Designs）、イリノイ大学技術 報告書UIUCDCS91-1696の中で、次のような定義を提案している。「抽象クラスと は、一組の責任分担を協力し合って実行するオブジェクトの集合を設計したもの である。従って、フレームワークとは、組で定義された演算責任分担を協力し合 って実行するオブジェクト・クラスが集まったものである。」プログラミング側 から見たときは、フレームワークとは、基本的には、実働アプリケーション（wo rking application）の事前に作られた構造を提供する、相互に接続されたオブ ジェクト・クラスの集まりである。例えば、ユーザ・インタフェース・フレーム ワークは、描画ウィンドウ（drawing window）、スクロールバー、メニューなど を サポートし、これらの「デフォルト（省略時）」の作用を提供することができる 。フレームワークはオブジェクト・テクノロジを基礎にいているので、この作用 を継承してオーバライド（override）することにより、開発者はフレームワーク を拡張し、カストマイズした解決手法を特定の専門分野で作ることができる。こ れが従来のプログラミングに比べて大きな利点であるのは、プログラマはオリジ ナル・コードを変更することなく、むしろソフトウェアを拡張できるからである 。さらに、フレームワークは、アーキテクチャに関するガイダンスとモデリング を提供すると同時に、問題領域に特有の個々のアクションを指定することから開 発者を解放するので、開発者はいくつかのコード層を通って盲目的に作業する必 要がない。 ビジネス側から見たときは、フレームワークは、特定の知識分野において専門 知識をカプセル化または具現化する方法と見ることができる。企業の開発集団、 独立ソフトウェア・ベンダ（Independent Software Vendors - ISV）およびシス テム統合者（systems integrators）は、前述した例のように、製造、会計、通 貨取引きといった特定分野における専門知識をもっている。この専門知識はコー ドで具現化されている。フレームワークを使用すると、企業は、その専門知識を 企業のコードで具現化することにより、専門知識の共通特性を取り込んで、パッ ケージ化することができ る。まず、そのようにすると、開発者は専門知識を利用するアプリケーションを 作成または拡張できるので、問題がいったん解決されれば、ビジネス・ルールや 設計は統一的に実施され、使用されることになる。また、フレームワークと、フ レームワークの背景にある具現化された専門知識は、製造、会計、バイオテクノ ロジといった垂直的マーケットにおいて専門知識を得た企業にとっては、戦略的 資産をもつことを意味し、企業の専門知識をパッケージ化し、再販し、流布し、 テクノロジの進歩と普及化を促進するための分配メカニズムをもつことになる。 歴史的には、フレームワークがパーソナル・コンピューティング・プラットフ ォーム上の主流概念として出現したのは、つい最近のことである。この移行を助 長したのが、C++といったオブジェクト指向言語の出現である。従来までは、C++ は大部分がUNIXシステムと研究者のワークステーション上に搭載され、コマーシ ャル・ベースのパーソナル・コンピュータには搭載されていなかった。いくつか の大学や研究所のプロジェクトが今日の商用フレームワークおよびクラス・ライ ブラリの先駆けとなり得たのは、C++などの言語やSmalltalkなどの他のオブジェ クト指向言語のお陰である。その例のいくつかを挙げると、スタンフォード大学 のInterViews、カーネギ・メロン大学のAndrewツールキット、チューリッヒ大学 のET++フレー ムワークがある。 フレームワークは、どのレベルのシステムに関心があり、どのような問題を解 決しようとしているかに応じて、多種類のものがある。フレームワークの種類は ユーザ・インタフェースの開発を支援するアプリケーション・フレームワークか ら、通信、印刷、ファイル・システム・サポート、グラフィックスなどの基本的 システム・ソフトウェア・サービスを提供する低レベルのフレームワークまでに わたっている。商用化されているアプリケーション・フレームワークの例をいく つか挙げると、MacApp（Apple）、Bedrock（Symantec）、0WL（Borland）、NeXt Step App Kit（NeXT）、Smalltak-80 MVC（ParcPlace）がある。 フレームワークでプログラミングを行うには、他の種類のシステムに慣れてい る開発者は考え方を変える必要がある。確かに、このプログラミングは、従来考 えられていたプログラミングとはまったく異なっている。DOSやUNIXなどの旧ス タイルのオペレーティング・システムでは、開発者自身のプログラムが構造全体 になっている。オペレーティング・システムはシステム・コール（system call ）を通してサービスを提供している。つまり、開発者のプログラムはサービスの 必要時にコールを行い、サービスが提供されたとき制御が返却される。プログラ ム構造は制御の流れに基礎を置き、これは開発者が書いたコードに具現化されて いる。 フレームワークが使用されるときは、これとは反対である。開発者は制御の流 れに貴任をもつ必要がなくなる。開発者は、プログラミング・タスクを実行の流 れから把握して理解しようとする癖を止めなければならない。むしろ、オブジェ クトの責任分担からとらえて思考する必要があるので、タスクをいつ実行させる かを判断するには、フレームワークに頼らざるを得なくなる。開発者が書いたル ーチンは、開発者が書かなかった、従って開発者には見えないコードによってア クチベート（activate−活性化）される。この制御の流れのフリップフロップは 、手続き的プログラミングだけに経験のある開発者にとっては、大きな心理的障 壁となっている。しかし、このことをいったん理解してしまえば、フレームワー ク・プログラミングによると、他のタイプのプログラミングによる場合よりも作 業量が大幅に減少することになる。 アプリケーション・フレームワークが開発者にプレハブの機能を提供するのと 同じように、本発明の好適実施例に含まれているようなシステム・フレームワー クはシステム・レベルのサービスを提供することによって同じ考え方をてこにし ている。つまり、システム・プログラマといった開発者は、システム・レベルの サービスをサブクラス化またはオーバライドして、カストマイズした解決手法を 作成することができる。 例えば、オーディオ、ビデオ、MIDI、アニメーションなどの新規なデバイスや異 種デバイスをサポートする基礎を提供できるマルチメディア・フレームワークに ついて考えてみることにする。新しい種類のデバイスをサポートする必要がある 場合、開発者はデバイス・ドライバを書くことが必要になる。フレームワークで これを行う場合は、開発者に要求されることは、その新デバイスに特有の特性と 作用を指定するだけである。 この場合の開発者は、マルチメディア・フレームワークから呼び出されるある 種のメンバ関数（member functions）のインプリメンテーションを用意すること になる。開発者にとってすぐに利点となることは、デバイスのカテゴリ別に必要 になる汎用コード（generic code）がマルチメディア・フレームワークにすでに 用意されていることである。このことは、デバイス・ドライバ開発者が書き、テ ストし、デバッグするコードが少なくなることを意味する。システム・フレーム ワークを使用するもう１つの例は、SCSIデバイス、NuBusカード、およびグラフ ィックス・デバイス別のI/Oフレームワークを持つ場合である。機能は継承され るので、各フレームワークには、そのデバイス・カテゴリに見られる共通機能に 対するサポートが用意されている。この場合、他の開発者は、これらの統一イン タフェース（consistent interfaces）を通し て、あらゆる種類のデバイスにアクセスすることが可能になる。 協同モデル 固有の協同モデル（inherent collaboration model）は特定のプレース・オブ ジェクトの関数と通信スタイルをサポートしている。特に、好適実施例によれば 、次の協同モデルをサポートすることが可能である。すなわち、（i）スクリー ン共有（screen sharing）、（ii）注釈マージング（annotation merging）、（ iii）ドキュメント・マージング（document merging）である。従って、ユーザ は、作成されるプレース・オブジェクトに合った協同モデルを選択することがで きる。 これらの３つの協同モデルを使用すると、ユーザは異なった方法でオブジェク トにアクセスすることができる。ユーザは、スクリーン共有協同モデルを使用す ると、オブジェクトをリアルタイム（実時間）で見ることができる。これとは対 照的に、注釈マージングとドキュメント・マージング協同モデルを使用すると、 あるオブジェクトの異なる部分を同時にアクセスすることができる。 ある種のプレース・オブジェクトは固有の協同スタイル（intrinsic collabor ation style）をもっており、これらはそのプレース・オブジェクトの目的 を補足するものである。従って、協同構成（collaboration arrangement）には 、ブロードキャスト・スクリーン共有、対話式スクリーン共有、電話通信（tele phony）、共有ホワイトボード（shared white board）、プロジェクトまたはド キュメント、注釈が付けられる掲示板スレッド（bulletin board thread）、ビ デオ会議、あるいはこれらの組合せを含めることができる。 スクリーン共有協同モデルは、ホスト・ワークステーション上に置かれている 、プレースの中のすべてのオブジェクトを他のワークステーションにいる複数の ユーザに表示する。しかし、ホスト・ワークステーション以外のワークステーシ ョンに置かれているオブジェクトはいずれも、ホスト・ワークステーションに移 されるまでは表示されない。スクリーン共有モデルでは、すべてのユーザはある プレース・オブジェクトを同じ表示を共有する必要がある。 スクリーン共有によると、異なるプレース・オブジェクトの中で異なる種類の やりとり（interaction -対話）を行うことができる。例えば、複数の設計者の 小グループ会議では、各設計者が異なるロケーションにいても図面はリアルタイ ムで分析され、修正される。この場合、各設計者は、図面を修正する能力をもつ ことになる。別の例として、プレース・オブジェクトを学校の講義室とすること ができ、プレゼンテー ションをあるユーザから他のユーザ・グループにブロードキャスト（同報通信） する。このプレゼンテーションを行っているユーザは、マルチメディア・トーク （multimedia talk）を作成し、クラスの他の人達にそれを伝えることができる 。プレゼンテーションが行われている間、クラスのメンバは、講師のプレゼンテ ーションを変更するために、どのようなことを行うことも許されない。しかし、 他のユーザはメモをとったり、ユーザ間の議論に参加することは許される。 ドキュメントのように、注釈を付けたり、マージングしたりできるオブジェク トは、表示目的のためにすべてのユーザによって操作される。しかし、ドキュメ ントに対する各ユーザの表示は、異なるものである。従って、複数のユーザが同 時にあるドキュメントに注釈を付けたり、マージングしたりすることが可能であ る。これが可能であるのは、どのユーザも、他のユーザと共通の表示を共有して いないからである。注釈マージングやオブジェクト・マージング協同作業に関与 する各ユーザが、あるドキュメントの異なる部分で作業することができるのはそ のためである。 オブジェクト・マージングと注釈マージングの協同モデルは、ドキュメントの ように、プレース・オブジェクト内のオブジェクトを、複数のユーザに同時にオ ープンするので、各ユーザはオブジェクトの異なる部分を見ることができる。例 えば、あるユーザがド キュメントの序文を書いている間に、別のユーザが結論を書くことができる。こ の例では、オープン・ドキュメントは協同作業に参加する各ユーザに自動的に表 示されることはない。むしろ、各ユーザはそのドキュメントのコピーをオープン して編集することになるが、そのコピーはあとでメイン・ドキュメントと一致さ せる。 以上のように、プレース・オブジェクト内のオブジェクトは、そのオブジェク トをサポートしている協同モデルをベースにしてサポートされる。スクリーン共 有の協同モデルは、協同作業内のすべてのユーザに対してオブジェクトをオープ ンする。スクリーン協同作業内の各ユーザは、データの１つの表示に束縛されて いるので、ファイル・ドキュメントの一部分だけが一度に一回の割合で処理され る。例えば、すべてのユーザがグラフィック・ドキュメントに変更を加えること ができるのは、大部分のグラフィック・プログラムが、グラフィック・ドキュメ ント内のデータをすべて収めている全画面表示（full screen view）をサポート しているからである。しかし、ワード・プロセッシング・ドキュメントは、複数 ページ・ドキュメントであるので事情が異なる。そのために、協同作業内のすべ てのユーザは、一度に１ページずつだけをディスプレイ上に表示して、作業を行 うことができる。従って、ホスト側のワークステーションに置かれているす べてのオープン・ワード・プロセッシング・ドキュメントはすべてのユーザに表 示される。 コンテナの固有特性 コンテナは次のような固有特性をもっている。 ・ コンテナは、オブジェクトを収容することができる。ワークスペース・コ ンテナ（例えば、フォルダとプレース）は、ワークスペース・オブジェクト（例 えば、ドキュメント、フォルダ）だけを収容するのに対して、他の特殊目的コン テナは他のタイプのオブジェクトを収容することができる。例えば、データベー ス・コンテナはデータベース照会（database query）の結果を収容することがで きる。あるオブジェクトをコンテナから削除すると、そのオブジェクトのモデル （メモリ内の構造）とモデル・ストア（ディスク上の構造）がシステムから除去 される。 ・ コンテナはオブジェクトとの参照リンク（reference link）を収容できる ので、参照されたオブジェクトがあるコンテナから別のコンテナへコピーされる ときこれらのリンクを修正（fixing-up）するときのスコープ（有効範囲）とな る。ある参照をコンテナから削除すると、その参照だけが除去され、参照された オブジェクトのモデルとモデル・ストアは影響されない。非コンテナ（non-cont ainer）もオブジェクトへ の参照を収容できるが、これは、コンテナと参照が密に結合されていないためで ある。 ・ コンテナはファイル・システム階層から独立した包含階層（containment hierarchy）を構築することができる。言い換えれば、ユーザは、情報がファイ ル・システムのどこに、あるいはどのようにストアされているかに関係なく、情 報を自由に編成してワークスペースに置いておくことができる。コンテナは複数 のボリュームにまたがることができる。すべてのボリュームが利用できないと、 利用できないオブジェクトは表示されないか、あるいはぼかされて（gray out） 表示される。コンテナ自体、つまり、包含階層のルート（root）はその格納プレ ース（enclosing place）に残されており、そのプレースと同じ記憶ドメイン（s torage domain）（network:machine:volume）に属している。 ディスプレイ・インタフェース内のプレース・オブジェクト プレース・オブジェクトは階層構造になっており、ユーザ・インタフェースで の最高レベル・オブジェクトになっている。従って、すべてのやりとりと通信は ある種のプレース・オブジェクトのコンテキスト内で行われる。各ユーザは独自 のホームプレース・オブジェクト（home place object）をもっている。ホーム プレース・オブジェクトは基本的トップ・レベル・オブジェクトで、セッション を開始するとユーザに表示される。プレース間のナビゲーションは、ユーザが別 のプレース・オブジェクトをホームプレースに追加するか、あるいはプレースへ の遠隔アクセスを必要とするとき可能である。ユーザは、サブプレース（sub-pl ace）と呼ばれるものをホームプレース内に作ることができる。 プレース・オブジェクトはタスク、プロジェクト、協同モデルといった、特性 別にセグメント化することができる。あるプレースが大きなサイズまでになった とき、ユーザはそのプレースを、いくつかの小さなプレースに再分割することが できる。しかし、デスクトップ・ディスプレイ全体を包括するプレース・オブジ ェクトはウィンドウに表示することもできる。 アプリケーションではないプレース・オブジェクト は情報を編成し、構造化するときに使用される。あるプレース・オブジェクトで の作業の個別的要求に応じて、ユーザはそのプレース内にオブジェクトを挿入す ると、その作業が容易になる。そのようなオブジェクトには、ファイル・ドキュ メント、ツール、およびコンテナがある。プレース・オブジェクトに入れられた オブジェクトは、望み通りに編成し、保守することができる。例えば、家計管理 （home financing）が行われるプレース・オブジェクトのワークスペースには、 ユーザは元帳、小切手帳、取引銀行とのオンライン接続といったオブジェクトを 挿入することが可能である。プレース・オブジェクトがクローズされ、再オープ ンされるとき、そのプレース・オブジェクトのワークスペース内のオブジェクト は、そこから出たときと同じように表示される。 ユーザは、１つまたは２つ以上のプレースをオープンして、デスクトップ・プ レース・プレゼンテーションのほかにウィンドウ・ベースのプレース・プレゼン テーションにも入れておくと、複数のプレース・オブジェクトを同時にアクセス して、表示することができる。ウィンドウ内のプレース・オブジェクトは、デス クトップ・プレース・オブジェクトに関連する属性をすべて具備している。この 機能により、ユーザはプレース・オブジェクト・ウィンドウのサイズを縮小して 複数のプレース・オブジェクト・ウィンドウを表示 することができる。ユーザは、ウィンドウ内のプレース・オブジェクトをセット でオープンすることができる。その結果、ユーザは、オブジェクトを複数のプレ ース・オブジェクト・ウィンドウ間で即座に移動し、コピーすることができる。 さらに、ユーザは複数のプレース・オブジェクト間を手際よくナビゲートするこ ともできる。 第２図に示すように、デスクトップ・プレース内のウィンドウ・プレースが示 されている。プレース・オブジェクト200は、タイトルバー202が示すように「ホ ームプレース」と名付けられている。プレース・オブジェクト200のワークスペ ース204はデスクトップ・ディスプレイ全体を包括している。また、第２図には プレース・オブジェクト206も示されている。プレース・オブジェクト206はタイ トルバー208が示すように「マシン・ルーム」と名付けられ、ウィンドウ内に収 められ、ワークスペース210を所有している。全体が表示されるオブジェクト214 と216、および一部が表示されるオブジェクト218はプレース・オブジェクト206 のワークスペース210内に置かれている。オブジェクト206はコントロール212も 所有しているので、プレース・オブジェクト206を拡大することが可能になって いる。 第３図に示すように、第２図のプレース・オブジェクト206が拡大されて示さ れている。プレース・オブ ジェクト206のコントロール212を第２図に示すようにドラグすると、プレース・ オブジェクト206は、デスクトップ・ディスプレイ全体のサイズであるフルサイ ズまで拡大される。その結果、オブジェクト218と300は、プレース・オブジェク ト206をデスクトップ・ディスプレイのサイズまで拡大すると、ワークスペース2 10内に全部が表示されることになる。 好適実施例では、単一のワークステーションを共有する複数のユーザをサポー トしており、各ユーザは個人的情報データが置かれているホームプレース・オブ ジェクトをもつことができる。各ユーザはサブプレース・オブジェクトをホーム プレース・オブジェクト内に作っておくと、個人的情報を分割（partition）す ることができる。 第４図に示すように、ワークステーション内のユーザプレース・オブジェクト の代表的階層が示されている。ワークステーション400は、Ann、JohnおよびTerr yという名前の３人のユーザが共有している。共有ユーザの各々は、それぞれ402 ,404,406に示すホームプレース・オブジェクトを所有している。さらに、ホーム プレース・オブジェクト404（Johnのホームプレース・オブジェクト）はサブプ レース・オブジェクト408（Johnのワークプレース・オブジェクト）と410（John のアートプレース（Art Place）オブジェクト）に再分割されている。 ワークステーションには、特定のユーザと関連づけられていない他のプレース ・オブジェクトを置いておくことも可能である。そのようなプレース・オブジェ クトとしては、好ましくは、ゲスト・プレース・オブジエクト（guest place ob ject）、ログイン・プレース・オブジェクト（log-in place object）、システ ム保守プレース・オブジェクト（system maintenance place object）、転送プ レース・オブジェクト（transfer place object）などがある。ゲストまたは公 開（public）プレース・オブジェクトは、ワークステーションに知らされていな いユーザによるアクセスを可能にする。ログイン・プレース・オブジェクトは、 オブジェクトとユーザ・セッションの開始に関する情報とを収めている。システ ム保守プレース・オブジェクトはユーザが保守タスクを実行することを可能にし 、マシン・ルームを収めている。マシン・ルームはワークステーションに関する 持続的構成情報を収めており、特定のユーザと関連づけられていない場合がある 。転送プレース・オブジェクトは、情報をストアし、ワークステーションのユー ザ間で情報を転送することを可能にする。 プレース・オブジェクトのアクセス プレース・オブジェクトをアクセスし、その間で ナビゲートするには、いくつかの方法がある。例えば、（i）資源ブック（resou rce book）による方法、（ii）マップ表現の内部での方法、（iii）ポストカー ドなどのプレースへの参照の使用による方法、（iv）インビテーション（invita tion：招待状）による方法がある。 資源ブックにより、ブックのコンテキスト内で情報をユーザに提示して、プレ ース・オブジェクトへアクセスすることができる。通信ブック（communication book）に収められている情報は、名前サービス・ディレクトリ（name service d irectory）内に存在する、資源と呼ばれるオブジェクトに関するものである。従 って、資源ブックを通してアクセスできる資源には、人やプレースなどのオブジ ェクトが含まれる。このため、資源ブックは、プレース・オブジェクトを探し出 してアクセスするときの手段となる。 資源ブック内には、資源ブック内のプレース・オブジェクトに関する１つまた は２つ以上のタブがあり、そこにはプレース・オブジェクトを記述した情報が入 っている。そのような情報には、プレース・オブジェクト内に置かれたオブジェ クト、およびプレース・オブジェクトをアクセスするときのコストを含めること ができる。資源ブックによると、プレース・オブジェクトが見つけやすくなり、 そのあとで、ユーザはそのプレース・オブジェクトを持続的参照 （persistent reference）としてローカル・ワークステーションに持ち込むこと ができる。従って、下述するポストカードのような資源ブック内に表されている 選択されたプレース・オブジェクトは、そのプレース・オブジェクトを将来アク セスすることに備えて、資源ブックからドラグしてワークステーションのデスク トップ・ディスプレイ上に置いておくことができる。 マップは、プレース・オブジェクトを空間的に表現したものである。マップに は、なんらかの方法で結合されたプレース・オブジェクト群が含まれている。従 って、ユーザはマップ上をたどっていって、あるエリアに置かれていることが分 かっているプレース・オブジェクトを探し出すことができる。マップでは、アニ メーションとサウンドが使用されるので、ユーザはあるプレース・オブジェクト から別のプレース・オブジェクトへ移動するとき、コンテキストと移動感（sens e of transition）を得ることができる。 マップは空間的表示（spatial view）を使用して、ユーザが指定した種々のプ レース・オブジェクトへのアクセスを可能にする。ユーザはマップを使用して、 新しいプレース・オブジェクトを作成し、既存のプレース・オブジェクトを操作 することができる。マップは対話式（interactive）である。従って、ユーザは マップを使用すると、（i）その参照をマップ上でダブ ルクリックしてプレース・オブジェクトをオープンすること、（ii）ポストカー ドのような参照をマップから使用可能なコンテナへドラグすること、（iii）フ ァイルを現在のプレース・オブジェクトからマップ上の別のプレース・オブジェ クトを指す参照へドラグしてフィアルを移動すること、（iv）１つまたは２つ以 上のプレース・オブジェクトを選択し、プロパティ・シート（property sheet） をオープンし、選択したプレース・オブジェクトの新しいプロパティを指定して １つまたは２つ以上のプレース・オブジェクトのプロパティを変更すること、な どが行える。 マップは、ユーザがあるプレース・オブジェクトから別のプレース・オブジェ クトへ移動するとき、コンテキストと移動感を与えることができる。例えば、ユ ーザが第１プレース・オブジェクトから出て第２プレース・オブジェクトへ移る とき、マップは、アニメーション、例えば、２オブジェクト間のラインをイラス トで示してプレース間の移動を表示する。このようなアニメーション・シーケン スには、２つのプレース・オブジェクトのロケーション・コンテキストが示され る。第１に、シーケンスは移動感に関係するものである。第２に、シーケンスは 、あるプレース・オブジェクトから別のプレース・オブジェクトへ移るときにい つでもマップが使用できることをユーザに知らせるものである。 ポストカードは、プレース・オブジェクトを指す参照である。ポストカードは 、そこへ戻ることが望ましいプレース・オブジェクトをアクセスしたときに、ユ ーザにより作られる。アクセスしたプレース・オブジェクトのポストカードを作 成しておくと、そのプレース・オブジェクトへの将来のアクセスが容易になる。 この種のポストカードを他のユーザへ転送すると、プレース・オブジェクトが存 在することをユーザに警告したり、アクセス情報を得たりすることもできる。 インビテーション（招待状）もプレース・オブジェクトを指す参照であるが、 これによると、特定のユーザが特定の時刻にプレース・オブジェクトをアクセス することができる。このアクションにより、プレース・オブジェクトの作成者は 選択したユーザを指名して、一定の期間に限って、また特定の制約条件の下でプ レース・オブジェクトをアクセスさせることができる。ある種のプレース・オブ ジェクトはアクセス料金を請求する場合があるので、インビテーションを使用す ると、ユーザはプレース・オブジェクトへのトライアル・アクセスを受けること ができる場合がある。また、インビテーションは、ユーザが特定の日付と時刻に プレース・オブジェクトをアクセスできることを指定できるので、単純なアクセ ス制御メカニズムとして働くことになる。さらに、インビテーションは、他の ユーザに協同作業に参加することを勧誘するためにも使用できる。事前に予告し ないである人を協同作業に組み入れることは適切でないので、インビテーション を転送すれば、協同作業に参加するかどうかの機会をユーザに与えることができ る。 第５図に示すように、インビテーションが示されている。タイトルバー502が 示すように“invitation from Rob Dickinson”（Rob Dickinsonからの招待状） と名付けたインビテーション500は、見出し504に示すように“CPSR Annual MEET ING”に関する情報を収めている。このインビテーションを転送する人、ミーテ ィングの時刻、ミーティングの場所、および指名したゲストに関する情報も、そ れぞれ参照符号506,508,510,512で示すように、このインビテーションに示され ている。 必要とするプレース・オブジェクトが見つかったとき、ユーザはサブプレース であるプレース・オブジェクト間をナビゲートしなければならない。プレース・ オブジェクトの設計者が選択するナビゲーション方法は、プレース・オブジェク トの重要な特性である。プレース・オブジェクトは階層になっているので、ユー ザは、プレース・オブジェクトが深いネスト構造（deep nested structure）に あるのか、浅い構造（shallowstructure）にあるのかを知っている必要がある。 深いネストは、ユーザが連続するサブプレース・ オブジェクトをオープンしていくか、あるいは参照を使用して深いネストのプレ ース・オブジェクトまで到達しなければならないことを意味する場合がある。こ れに対して、多数のエレメントからなる浅い構造は空間的により多くのスペース を占めるので、潜在的には、ユーザにより多くの選択項目をよりハイレベルで与 えることができる。従って、作成者が選択するナビゲーション方法は、到達しよ うとするプレース・オブジェクトの構造によって決まる。 好ましくは、スケーリング方法（scaling method）とパンニング方法（pannin g method）を併用すると、デスクトップ・ディスプレイ内でナビゲートすること ができる。あるプレース・オブジェクトを均一にスケーリングするには、アスペ クト比（aspect ratio：横縦比）を一定に保ちながら、プレース・オブジェクト の寸法を拡大または縮小する。スケーリングは、ズームしてドキュメントやプレ ース・オブジェクト・ビューに入ったり、そこから出たりするユーザにとっても 重要である。プレース・オブジェクトが正しくスケーリングされたあと、パンニ ングを使用すると、プレース・オブジェクト内をナビゲートすることができる。 パンニングを行うときは、プレース・オブジェクトの特定部分を表示するように 、グラフィック・カーソル（graphic cursor）を動かしながら手操作でデスクト ップに指示する。パンニング・グラフィックをドラグす ることにより、ユーザはデスクトップの他の領域をビューに移動する。 別の方法として、好適実施例では、スクローリングや自動パンニング（auto-p anning）またはディストーティング（distorting）方法を使用して、プレース・ オブジェクト内をナビゲートしている。自動パンニングはホットゾーン（hot-zo ne）（通常は、デスクトップのエッジを取り巻くエリアであるが）に入り込むカ ーソルの動きを検出して、ディスプレイを動きの方向にパンする。システムには 、照会（query）により、あるプレース・オブジェクトを見つけたり、プレース ・オブジェクトのある内容を見つけるためのメカニズムも、ユーザのために用意 されている。 アクセス制限 プレース・オブジェクト内のセキュリティとアクセス制御を実現するには、い くつかの方法がある。第一は、一組のアクセス権をプレース・オブジェクトと関 連づける方法である。この方法によると、その組のアクセス権の範囲にあるユー ザは、だれもプレース・オブジェクトをアクセスすることが許される。第二は、 あるプレース・オブジェクトへの最低限のアクセス権を指定した人に与える方法 である。しかし、増加したアクセス権がプレース・オブジェクト内に包含された オブジェクトと関連づけられることになる。第三は、プレース・オブジェクトを 必要とする個人とグループを指定して、アクセス権を割り当てる方法であるが、 これらの権利はプレース・オブジェクトとそこに包含されるオブジェクト全体に 適用されることになる。これらのルールによると、個別のファイル管理を必要と しないで、プレース・オブジェクト内に異なる共有レベルをもたせることができ る。 アクセスを制限する別の方法として、プレース・オブジェクトをアクセスする ユーザに費用を負担させることが可能である。従って、プレース・オブジェクト はサービスを提供する手段として利用することができる。そのようなサービスに は、ダウジョーンズ（Dow Jonesのような情報サービス、ウォールストリート・ ジャーナル（Wall Street Journal）のようなニュース・サービス、購買サービ スおよびAmerica On-Lineのような収集プレース・オブジェクトを含めることが 可能である。プレース・オブジェクトは、サービスを提供し、サービスへのアク セスを制限するように構築することができる。 ユーザがあるプレース・オブジェクトに入ったときの費用を計算するモデルが いくつか用意されている。具体的には、費用は、 （i）プレース・オブジェクトへのアクセス （ii）プレース・オブジェクトのアクセス時間 （iii）あるプレース・オブジェクト内でアクセスされたオブジェクトの数 （iv）一定額の費用または申込み金 （v）あらかじめ決めた使用制限 （vi）これらの任意の組合せ の任意の１つまたは組合せに基づいて計算することができる。 好ましくは、発生した費用と潜在的費用の通知は、あるプレース・オブジェク トにアクセスするとユーザに表示される。さらに、オペレーションが高価になる おそれがあることは、ユーザに事前に警告される。さらに、ユーザは、あるプレ ース・オブジェクトの最大費用を指定することができる。最大費用に達すると、 ユーザに通知されるので、ユーザはそのプレース・オブジェクトから出るか、そ れとも将来発生する追加費用を負担するかを選択することができる。 プレース・オブジェクトのビジュアル表現 プレース・オブジェクトのビジュアル表現は、ロケーション感（sense of loc ation）を作る上で重要である。従って、プレース・オブジェクトは、背景イメ ージ、レイアウト、スケール、デザイン・スタイル、空間ボリューム（spatial volume）、照明効果および文字体裁（typography）といった、いくつかのエレメ ントに関して設計することができる。好適実施例では、これらのエレメントを組 み合わせて、識別性（distinctive）があり、ナビゲーションを容易にする環境 を作成している。 プレース・オブジェクトに適用される背景イメージは、リードオンリ・モデル （read-only model）を通して作成することができる。これには、移動するイメ ージや、現在時刻を基準にしてそのプレゼンテーションを変更する夜間／昼間プ レース・オブジェクトのように、データ駆動（data-driven）のイメージが含ま れる。さらに、プレース・オブジェクトの背景イメージをぼかすと、背景イメー ジと、ディスプレイの最前部のウィンドウやオブジェクト・アイコンなどのアイ テム（項目）との間の奥行き（depth stratification）を追加することができる 。また、彩度（saturation）を利用すると、前景アイテムと背景イメージの間に 独特のスタイルを作ることもできる。 プレース・オブジェクトの密度とレイアウトは、プレース・オブジェクトが満 足のいくように反映されるように適応される。プレース・オブジェクトがリード オンリ・アクセスだけを許しているのでなければ、ユーザがプレース・オブジェ クトに加えたレイアウト変更はセーブ（格納）され、リターン時にリストア（復 元）される。背景イメージと、プレース・オブジェクトの寸法スケールおよび寸 法比との関係によ り、ユーザのスコープ感（sense of scope）が設定される。従って、小さい、遠 のいて行くプレース・オブジェクトは距離を示し、大きいプレース・オブジェク トはプレース・オブジェクトの広がりを表している。 プレース・オブジェクトの空間ボリュームは、プレース・オブジェクトの表現 に不可欠である。プレース・オブジェクト内のオブジェクトの選択、配置および レンダリング（rendering）はユーザが使用できるオプションの範囲を示してい る。プレース・オブジェクトには、ユーザに理解しやすいものと、オープンと読 取りによって詳細分析を必要とするものがある。それにもかかわらず、プレース ・オブジェクトは、プレース・オブジェクトに収められたエレメントを調べると 、容易に区別することができる。さらに、空間の奥行きと対話によるナビゲーシ ョン方法はプレース・オブジェクトの特性になっている。空間仮想現実（spatia l virtual realities）を実現すると、三次元入力デバイスの使用とナビゲーシ ョンが可能になる。 照明と文字体裁のエレメントは、各プレース・オブジェクトに独特の特性をも たせる上で役に立つ。プレース・オブジェクトは、プレース・オブジェクトの特 定の側面に焦点を当てて設計することができる。大きなサイズで使用される表示 タイプフェースのよう な、文字体裁を利用すると、プレース・オブジェクトに独特の特徴をもたせるこ とが可能である。 プレース・オブジェクト以外のオブジェクト プレース・オブジェクトとワークスペースに置かれる他のタイプのオブジェク トの中では、プレース・オブジェクトが最高レベル・オブジェクトである。従っ て、フォルダのようなコンテナ・オブジェクトを含んでいる典型的なオブジェク トが現れるのは、プレース・オブジェクトのコンテキスト内である。さらに、フ ォルダのようなコンテナ・オブジェクトはプレース・オブジェクトを収容するこ とができない。コンテナ・オブジェクトは、ポストカードのようなプレース・オ ブジェクトを指す参照だけを収容することができる。 プレース・オブジェクトは他のオブジェクトを多数収容することができる。そ のようなオブジェクトとしては、ドキュメント、コンテナ、器具、ツール、文房 具、および人を指す参照などがある。プレース・オブジェクトは、サブプレース ・オブジェクトと呼ばれる他のオブジェクトを収容することも可能である。プレ ース・オブジェクトは他のプレース・オブジェクトを指す参照を収容することも できる。従って、プレース・オブジェクトの階層は、関連のオブジェクトをさ らに再分割できるように維持することができる。 好適実施例では、共有プレース・オブジェクトのワークスペース内に挿入でき るオブジェクトの作成が可能である。例えば、掲示板（bulletin board）をプレ ース・オブジェクト内に挿入しておくと、プレース・オブジェクトをアクセスし た人は、お互いに情報をやりとりすることができる。さらに、ビジネス・カード （business card：名刺）をプレース・オブジェクト内に挿入しておくと、ある 人はビジネス・カードで表された人と連絡することができる。 好適実施例では、ユーザは２つの方法で、プレース・オブジェクトをナビゲー トしている間に、選択したオブジェクトをアクセスできる。２つの方法とは、ポ ータブル・コンテナ（portable container）とワークスペース・シェルフ（work space shelf）である。ポータブル・コンテナはバックパック（backpack）また はブリーフケース（briefcase）に図形表現されたもので、ドキュメント、コン テナ、ツール・パレットなどのオブジェクトを指す参照を収容するために使用さ れる。この種のオブジェクトは、共有プレース・オブジェクトを含めて、アクセ スした各プレース・オブジェクト内に置かれている。しかし、運ばれるオブジェ クトを共有したり、協同プレース・オブジェクトにコピーしたりする場合は、そ のオブジェクトはコンテナからドラグされて共有スペースに入れられる。 ワークスペース・シェルフは、ユーザがある場所から別の場所へ移動しようと するデータの一時的レポジトリ（temporary repository）である。ワークスペー ス・シェルフは、常時ディスプレイ上に表示されているので、シェルフから直接 にアクセスできるワークスペース・オブジェクトを提示することにより、ユーザ の操作を容易にする。 第６図に示すように、ワークスペース・シェルフが示されている。デスクトッ プ600は、オープンしているシェルフ604およびクローズしているシェルフ606と 一緒にメニュー602を含んでいる。シェルフ604とシェルフ606は、それぞれコー ド（cord）608とコード610をもっている。シェルフ604がオープンしているのは 、コード608がマウス・ポインタでドラグされていたためである。これに対して 、コード610はドラグされていないので、シェルフ606はクローズしたままになっ ている。シェルフ604をオープンすると、それぞれがアイコン612と614で表され た２つのワークスペース・オブジェクトが得られる。ワークスペース・オブジェ クト・アイコン上でマウス・ポインタをダブルクリックすると、そのワークスペ ース・オブジェクトはアクセスまたはオープンされる。 ワークスペース・シェルフまたはポータブル・コンテナを使用する代わりに、 ユーザは直接操作によってあるオブジェクトを別のオブジェクトへ移動すること を選択することも可能である。直接操作は、選択しようとするオブジェクトを要 求するだけであり、ターゲット・オブジェクトでドロップされるまでドラグされ る。ドラグされたオブジェクトは、タイプ、内容、および「リード（read）とラ イト（write）」または「リードオンリ」属性などのオリジン（origin）情報を 収めている。ターゲット・オブジェクトはこの情報を使用して、ドラグされたオ ブジェクトとターゲット・オブジェクトとの間でどのようなやりとりを行うべき かを判断する。つまり、デフォルト条件 （default conditions）に従って、ど のようなやりとりを行うかを判断する。具体的には、好適実施例では、次の５つ のタイプのやりとりが可能になっている。すなわち、（i）拒否（reject）、（i i）コピー、（iii）参照の移動、（iv）コピー送付、（v）移動である。好まし くは、プレース・オブジェクトと人では、「参照の移動」がドラグされたオブジ ェクトのデフォルト条件になっている。 好ましくは、プレース・オブジェクト内に置かれているオブジェクトの配置は 、ワークスペースに関連する各ユーザ別に管理される。従って、あるプレース・ オブジェクトの各ユーザには、ユーザによって最後に再配置されたときのプレー ス・オブジェクトを示すステート（state−状態）がプレース・オブジェクトと 関連づけられている。ユーザのステートは、ユーザの ローカル・ワークステーション上にセーブされる。別の方法として、あるプレー ス・オブジェクトを１つだけのステート内に維持しておけば、そのプレース・オ ブジェクトをアクセスするすべてのユーザには、そのプレース・オブジェクトが 同じように表示されることになる。 オブジェクトは、アイコンをトラッシュ（trash：ごみ箱）アイコンに移して から、トラッシュを空にするコマンドを選択することで、プレース・オブジェク トのワークスペースから削除することができる。好ましくは、すべてのワークス ペース・オブジェクトは、１つのトラッシュ・オブジェクトだけを通して削除す ることができる。さらに、このようなトラッシュ・オブジェクトは、削除しよう とするオブジェクトがトラッシュ・アイコン上にドラッグされると、ターゲット 受付け（target acceptance）を表示し、そのあと、ドラグされたオブジェクト がそこに収容されると、ビジュアル・フィードバック（visual feedback）を表 示する。さらに、トラッシュ・オブジェクトをオープンすると、そこに入ってい るエレメントを見ることができる。 プレース・オブジェクト内に表される人 人オブジェクト（person object）が使用されるの は、あるプレース・オブジェクトからの人が存在するか存在しないかを示すとき だけである。例えば、あるユーザがプレース・オブジェクトを作成したとき、そ のユーザの人オブジェクトが作成されたプレース・オブジェクト内に作られるこ とが好ましい。このようにすると、そのプレース・オブジェクトをアクセスする 他のユーザは、作られた人オブジェクトの存在を通してユーザが存在することを 知ることができる。人オブジェクトとは異なり、人を指す参照は、プレース・オ ブジェクト内に人が存在するか、存在しないかを示さない。むしろ、人を指す参 照からは、人に関する情報とその人との通信方法を知ることができる。例えば、 プレース・オブジェクトに置かれているビジネス・カードからは、ユーザは、ビ ジネス・カードの中で参照された人との連絡方法を知ることができる。 人を人オブジェクトとして表すほかに、他の側面から見た存在を表すことも可 能である。そのような見方として、（i）あるプレース・オブジェクトがユーザ のアクティブ・プレース・オブジェクトであるか、主要プレース・オブジェクト であるか、（ii）人の関心レベル、つまり、人の注目がいくつかの他のプレース ・オブジェクトに分割されているかどうか、（iii）プレース・オブジェクト内 の人の活動レベル（activity level）、および（iv）その人と連絡できるかどう か、といったことがある。 好適実施例では、あるプレース・オブジェクトが人のアクティブ・プレース・ オブジェクトであるかどうかを関係づけることができる。つまり、あるプレース ・オブジェクト内に表された人がそのプレース・オブジェクト内に現在存在する かどうか、である。この判断が必要になるのは、ある人がウィンドウ・プレース ・オブジェクトの使用を介して２つ以上のプレース・オブジェクトに同時にいる ときだけである。さらに、包含ドキュメントのように、あるプレース・オブジェ クト内にあるオブジェクトも、特定の人に表示されるものとして描画することが 可能である。 ある人の関心レベル、つまり、注目レベルは、ユーザが現在関係づけられてい るプレース・オブジェクトの数と関係がある。従って、３つのプレース・オブジ ェクト内に存在するユーザは、いずれか１つに対する注目度が、１つのプレース ・オブジェクト内に単独で存在するユーザよりも低くなるはずである。さらに、 アクティブ・プレース・オブジェクトの側面から見た場合と同様に、プレース・ オブジェクトにいることと包含ドキュメントに関心をもっていることとの関係も 関心レベルをレンダリングするときに考慮される。 ユーザの活動レベルは、ユーザがプレース・オブジェクト内のいずれかの活動 を現在行っているか、活動を最近行ったばかりであるかを示している。従っ て、非活動度（inactivity）が高いときは、その人がオフィスにいないか、ある いは自分の席にいないかのどちらかである。このような情報は、非活動度の高い 人に連絡しようとするときに役に立つ。 好適実施例によれば、ある人が手があいているかどうか（availability）の側 面も関係づけることが可能である。つまり、情報をやりとりするためにその人と 連絡をとることができるかどうかである。好適実施例では、種々形態のグループ 通信ができるようになっているが、個人が作業の邪魔をされないようにすること もできる。従って、ユーザは手があいていないステート（state of unavailabil ity）を示しておけば、他のユーザからの連絡を拒否することができる。従って 、連絡不能ステートは、プレース・オブジェクト内の人を、邪魔されたくないと の表示を使用して表現することにより関係づけられる。 プレース・オブジェクト内に表現された人に関する他のタイプの個別情報はユ ーザと関係づけられる。そのような情報としては、その人の名前、その人の物理 的ロケーション、その人がオンラインであるかどうか、その人が共有している各 ドキュメントの特権レベル（level of privilege）、共有されている各ドキュメ ントのタイトル、ドキュメントのどの部分でその人が作業しているか、などがあ る。この個別情報は、人を指定して“GetInfo”コマンドを出すことにより検索 す ることができる。 好適実施例によれば、人を異なるアイデンティティ（identity）の使用を通し て表現することが可能である。具体的には、プレース・オブジェクト内に表現し ようとする人は、写真イメージによっても、個人色の薄い別の表現によっても表 現することができる。さらに、人は、人を真実のアイデンティティで表す代わり に、そのアイデンティティを匿名のままにしておくことも、偽名を使用すること もできる。さらに、あるプレース・オブジェクト内であるアクションを実行する 人のアイデンティティを隠すことも可能である。 プレース・オブジェクトは、ユーザによるアクセスの前に一定レベルのIDを要 求する場合がある。例えば、プレース・オブジェクトは、プレース・オブジェク トをアクセスするすべてのユーザが真実のアイデンティティで表現されているこ とを要求する場合がある。収集プレース・オブジェクトのような、他のプレース ・オブジェクトでは、ユーザは真実のアイデンティティの代わりに偽名を使用す ることが可能である。さらに、機密性が重要とされるような他のプレース・オブ ジェクトでは、オブジェクトをアクセスし、そのオブエクトに参加するユーザの すべてのアイデンティティを隠すことができる。 ユーザの選好（preference）をプレース・オブジェクトの必要とするアイデン ティティ・レベルと対応づけ るために、交渉メカニズム（negotiation mechanism）が採用されている。この 交渉メカニズムによると、ユーザはプレース・オブジェクトの必要とするアイデ ンティティ・レベルを基準にして正しいアイデンティティを選択することができ る。例えば、ユーザは偽名をデフォルトにしたい場合がある。あるユーザが、各 ユーザの真実のアイデンティティを必要とするプレース・オブジェクトにアクセ スしようとすると、そのプレース・オブジェクトでは偽名の入力が許されないと のメッセージがそのユーザに出されることになる。そのあと、そのユーザは再入 力するように指示される。従って、ユーザには、好みのアイデンティティが不十 分であるとき、好みのアイデンティティを既存の事情に基づいて適応させる機会 が与えられる。 好ましくは、人は、プレース・オブジェクトの他の包含オブジェクトと一緒に 、プレース・オブジェクトのワークスペース内に表現される。別の方法として、 物理的にプレース・オブジェクトのワークスペース内にない、別の媒体内に表現 することも可能である。そのような媒体としては、（i）別のウィンドウ、（ii ）オープン時に人を表示する引出し（slide-out drawer）、（iii）接続された 人のパレットを表示するメニューなどがある。 人を物理的にプレース・オブジェクトのワークスペース内にいるように表現す るか、プレース・オブジェクトの外にいるように表現するかの選択は、プレース ・オブジェクトに対する人の役割によって決まる。従って、プレース・オブジェ クト内でサービスを提供するユーザは、人をプレース・オブジェクト内に表現す ることにより正確に描画される。例えば、ライブラリアンは、ライブラリにおい て公衆のために種々サービスを提供するものと考えられているのが普通である。 従って、ライブラリアンは、ライブラリ内に描画することができる。これに対し て、ライブラリの利用者は別のウィンドウ内に描画することができる。 あるプレース・オブジェクト内には非常に多数の人が存在することがあるので 、好適実施例では、これらの人をスケーリングして、プレース・オブジェクト内 にグループで表現している。プレース・オブジェクトに非常に多数の人がいると きは、個人の通信が行われる可能性は少なくなる。従って、プレース・オブジェ クト内のすべての人を納めて（collapse）、１つのグループで表現することがで きる。従って、グループに属するすべての人にメッセージを送ることによって同 時に連絡することができる。グループのすべての人と連絡する能力はアクセス制 御の対象である。 すべての人を納めてグループにする必要がない場合は、多数の人を分割するこ とができる。つまり、全員 の一部分だけを表現して、即時にアクセス可能にすることができる。分割は、任 意的に判断することができる。例えば、あるユーザに最も近くに置かれている人 達を別々にグループ化することができる。 多数の人を納めてグループにすることによって多数の人が表現されているか、 グループの一部のメンバを分割することによって表現されているかに関係なく、 好適実施例には、種々の探索ツールが用意されているので、ユーザは多数の人を 探索して、特定の人を識別することができる。 詳細ロジック 以下では、本発明による好適実施例の詳細ロジックについて説明する。第７図 は、好適実施例によるハイレベルの制御の流れを示すフローチャートである。処 理は端子200から開始され、即時に機能ブロック710に移り、そこでユーザはログ オンする。機能ブロック712に示すように、関連のトラベル・バッグは、プレー ス・オブジェクトにストアされているプロフィール情報に基づいてアクチベート されるが、機能ブロック715では、初期プレース・オブジェクトはユーザ・プロ フィール情報に基づいてアクチベートされる。そのあと、判定ブロック720でテ ストが行われ、ユーザが別のプレース（場所）へナビゲートすることを望ん でいるかどうかが判断される。そうであれば、制御がラベル730から第９図のラ ベル900に渡されて、新しいプレースへのナビゲーションが処理される。そのあ と、制御が戻されると、処理は判定ブロック720から再開される。ユーザが望ん でいなければ、機能ブロック740で、現在のプレース環境内のタスクが処理され 、制御が機能ブロック710へ戻されて、別のユーザがログオンするのを待つこと になる。 第８図は、好適実施例によるユーザ・セッション処理の詳細ロジックを示すフ ローチャートである。処理は端子800から開始され、即時に機能ブロック810に移 り、そこでユーザは名前リストから名前を選択する。そのあと、機能ブロック82 0で、ユーザ・オブジェクトをインスタンス生成（instantiate）することにより ユーザ・セッションが作成される。次に、機能ブロック830はユーザ・オブジェ クトに関連する登録アイテム（registered items）を開始し、機能ブロック840 はプレースButlerと名付けた登録アイテムをインスタンス生成し、機能ブロック 850はプレースButlerに関連するユーザ・トラベル・バッグをオープンし、機能 ブロック860はユーザ・プレースButlerの開始プレースを判断し、機能ブロック8 70はプレースをオープンし、端子880から制御が呼出し側プログラムに戻る。 第９図は、好適実施例に従って旧プレースをクロー ズし、新プレースをオープンするときの詳細ロジックを示すフローチャートであ る。処理は端子900から開始され、即時に機能ブロック910に移って他方のプレー スを探し出し、機能ブロック920に示すように現在のプレースから出て、判定ブ ロック930でテストを行って旧プレースから正しく出たかどうかを判断する。旧 プレースから正しく出ていれば、ターゲット・プレースが機能ブロック940でオ ープンされ、機能ブロック950でターゲット・プレースに入るようにユーザに指 示し、旧プレースは機能ブロック960でクローズされ、制御が端子970で呼出し側 アプリケーションに戻る。旧プレースから正しく出ていないと判定ブロック930 で判断されていると、制御が端子970から呼出し側アプリケーションに戻る。 第10図は、好適実施例に従ってプレースをクローズするときの詳細ロジックを 示すフローチャートである。処理は端子1000から開始され、即時に機能ブロック 1010に移って、旧プレースに関連するプレゼンテーション・ドキュメントをクロ ーズし、次に、現プレース・ステータス（状態）情報のプロフィールが機能ブロ ック1020でストアされ、テストが判定ブロック1030で行われて、追加のプレゼン テーション・ドキュメントがあるかどうかが判断される。もしあれば、制御が機 能ブロック1010に移り、追加のドキュメントを処理する。もしなければ、制御は 端子1040から呼出し側 ルーチンに返えされる。 第11図は、好適実施例に従って新プレースをオープンするときの詳細ロジック を示すフローチャートである。処理は端子1100から開始され、即時に機能ブロッ ク1110に移って、プレースに関連する背景が描画される。そのあと、機能ブロッ ク1120で、プレースに関連するドキュメントがオープンされ、そのドキュメント に関連するプレゼンテーションが機能ブロック1130で開始される。次に、テスト が判定ブロック1140で行われ、処理すべきドキュメントがまだ残っているかどう かが判断される。残っていれば、制御が機能ブロック1120に戻されて、残ってい るドキュメントが処理される。残っていなければ、処理は端子1150で終了する。 アーキテクチャ 以下、詳細ロジックを記述するアーキテクチャについて説明する。ロジックは 、システム内のやりとり（interactions）を示すために、クラスおよびオブジェ クト・ダイアグラムなどのツールを用いて記述されている。第12図は、本発明の 好適実施例に従って他のVDLダイアグラムの中で用いられている用語を説明する ビジュアル設計言語（Visual Design Language - VDL）のキー（key）である。 ラベル1200は協同作業 （collaboration）の例を示している。ラベル1210はオブジェクトの作成例を示 している。ラベル1220は間接的協同作業（indirect collaboration）の例を示し ている。最後に、ラベル1230は包含（containment）の例を示している。第13図 は好適実施例によるBoochダイアグラムである。 論理的には、プレースは、アトミック（atomic）に操作できる自己完結環境（ self-contained environment）である。残念ながら、プレースで実行される内容 は論理的に関連づけられているが、下位レベルのサービス別にグループ化されて いない。別の言い方をすれば、プレースは、別々のアドレス空間（address spac e）で実行され、層サーバ（layer server）、ビュー・システム（view system） またはドキュメント・アーキテクチャなどのオペレーティング・システム・フレ ームワークによって個別的に扱われるアイテムを、論理的にグループ化したもの である。論理ユニット（logical unit）として機能するためには、最高レベルの プレース・サービスは、第14図に示すように、別々の環境の概念モデルをユーザ に提示するようにプレースのアイテムを管理しなければならない。各ユーザは、 その所有者となっているプレースのセットをマシン上にもっている。また、各ユ ーザは他のプレースに入れるようにするためのアクセス権をもっている場合もあ る。 プレースの所有権階層 あるマシン上の各ユーザは、第15図に示すようにドキュメントとワークスペー ス・アイテムをストアしておくことができる、１つの「ホーム」プレースをもつ ことになる。個々のマシンの共有が許されるので、システム上に多数のホームプ レースが存在することになる。そのため、システムに知らされていない他の人が 使用できるゲストまたは公開（public）プレースをもつようにシステムを構成す る単純な方法が用意されている。単純なプレース階層が第４図に示されている。 第４図は、共有マシンのユーザ間の論理的プレース階層を示したものである。各 人は独自の「ホーム」プレースをもち、ユーザ独自の情報を収容し、用途別にい くつかのサブプレースに再分割されている。 ユーザは常にプレースにいる ユーザは常にプレースに存在する。ユーザがボイド（void−空白）であること はあり得ないので、ユーザがログインするときは、該当するプレースに置かれて いなければならない。そのようなプレースとなり得るのは、ホームプレースまた はデフォルト・プレース、ログオフする前に最後にいたプレース、またはユーザ が選んだプレースである。第16図はいくつかのダイア ログ例を示したもので、そこには、これらの選択項目だけが示されている。 ユーザは、ログインしたあとどのプレースへ行くかを指定することができる。 ユーザは次の中から１つを選択する。1）絶対：HomeまたはMailプレースなどの 特定のプレースへ行く、または2）最近のプレース（つまり、ユーザがログアウ トする直前にいた場所）。最近のプレースがリモート・プレースであれば、シス テムは、ユーザがいまそこへ行きたいのかを尋ねてくる。ユーザには、第16図に 示すダイアログ・ボックスと同じようなダイアログ・ボックスが表示される。 各ユーザはデフォフト・プレースと呼ばれるプレースをもっている。デフォル ト・プレースはプレースを指す参照だけであり、ユーザがログインしたときその 参照を使用して操作が開始されるものである。デフォルト・プレースは、ユーザ が必要時に戻ることができるプレースでもある。これは、コマンド・キーなどの ショートカット（shortcut）によるか、シェルフを通してアクセスすると、もっ と簡単に得ることができる。 プレースはユーザ固有の情報を保持する プレースは多くの側面からとらえて設計されて いるので、ユーザによるカストマイズと活動記録（history）を可能にしている 。例えば、各ユーザはプレースについて独自の表示をもつことができ、ドキュメ ントの独自のセーブされたプレゼンテーション（saved presentation）をもつこ とができる。この情報はどこかにストアしておく必要があるが、これはユーザ固 有の情報であるので、peopleサブシステムに用意されているユーザ域にストアさ れる。ユーザ・セッション・サブシステムはプレース・エレメント（place elem ents）を始動する。プレースの設計では、ユーザ・セッションの開始時にある種 のインタフェース・エレメントをオープンする必要がある。そのようなオブジェ クトの例として、シェルフ（shelf）またはトラベル・バッグがある。プレース のフレームワークでは、活動記録（history）サービスといった、ある種のプロ セスが稼働状態にあることが必要である。これらのサービスは、ユーザ・セッシ ョンが生成されると始動する。 プレースはどういう人がそこにいるかを表示できる 第17図は、プレースにいる人を表示している人ストリップ（peaple strip）を 示している。プレースにいる人のアイコンから、その人のビジネス・カードを自 動 的にドラグすることができる。TPlaceモデル・クラスは現在そのプレースに接続 されているTPersonオブジェクト群を維持している。人がそのプレースに入ると 、その人のために人オブジェクトがインスタンス化され、プレース・モデルに追 加される。プレースから出ると、プレースは人を指す参照を除去する。 以下に示したのは人存在管理（person presence management）に関係するTPla ceモデルのメソッドである。これらのやりとりは第18図に示されている。 プレースおよびユーザの選好 人オブジェクトをプレース・モデルに追加するときのプロセスを示したのが第 19図であり、以下、このプロセスについて説明する。このロジックの極端なケー スでは、プレースはバーチャル・マシン（virtual machine）としての意味をも ち、そのことは、各プレースには独自の選好（preference）がセットとして関連 づけられ、ユーザの選好もすべてがプレースに特有のものであることを意味する ことになる。このようにすると、ほとんど完全に異なるユーザ環境が得られると いう点で（環境が選好を用いてカストマイズできる限りにおいて）、ユーザは高 度の柔軟性が得られるが、そうすると、単純性が犠牲になり、選好の上に置くべ きインタフェースがさらに複雑化することになる。 プレース固有の選好を許すことは、ユーザが選好を指定するとき、ユーザがも つかもしれない意図がいくつかあるために複雑になる。 ・ この選好を、このプレースにいるときだけ使用する。 ・ このタイプの固有の選好をもたない、すべてのプレースについてはこれを デフォルトの選好にする。 ・ これを常に、このタイプの現在の選好にする。この選好はオーバライド値 である。デフォルトの選好 とプレース固有の選好が指定できる唯一のパラメータであれば、ユーザは混乱し 、正しくないデフォルトを指定し、それがどこでも適用されると期待するおそれ がある。そのタイプのプレース固有の選好がなくても、プレースに入ることがで きることになってしまう。 プレースとワークスペースとの関係は第20図と第21図に示されている。プレー スはワークスペースの最高レベル・エンティティであり、ワークスペースの他の エレメントを使用するときのコンテキストとなるものである。プレースは他のプ レースを収容することができ、フォルダやドキュメントなどの、他のワークスペ ース・エレメントを収容することができる。基本的には、ユーザ情報スペースは 、プロジェクト別、タスク別、企業組織別といったように、より意味のある論理 的グループに分割されている。プレース内には、以下に説明するように、フォル ダとドキュメントの包含階層（containment hierarcy）が存在する。 持続的ドキュメント・ステートの維持 プレース・プレゼンテーションがサポートしなければならない機能の１つは、 ユーザが最後にプレースにいたときに存在していた状態にステートを復元できる ことである。プレースとプレース上のプレゼンテー ションのどちらも、そこで論理的にオープンになっているドキュメントを参照す る。 ・ プレース内でオープンしているドキュメント群の記録をとっておく。 ・ ユーザがプレースに入ったときこれらのドキュメントをオープンする。 ・ ユーザがプレースから出たときこれらのドキュメントをクローズする。 ・ 上記のいずれの場合も、プレース・プレゼンテーションはプレースでオー プンしていた特定のプレゼンテーションをセーブしておき、環境を現実のステー トで提示できるようになっていなければならない。例えば、カレンダ・ドキュメ ントが複数のプレゼンテーションをサポートしていれば、毎月のビューはあるプ レースに置かれ、毎日のビューは別のプレースに置かれるはずである。リスト・ ビュー（list view）内のコンテナはあるプレースで専用され、空間ビュー（spa tialview）内のコンテナは別のプレースで専用される。プレースとプレース・プ レゼンテーションのどちらも、どのドキュメントがそのプレースでオープンして いるかの情報を維持していなければならない。 ユーザと一緒にストアされるユーザ固有のプレゼンテーション 第22図は、ドキュメント・プレゼンテーション・ステートを維持するためにユ ーザ情報と一緒にストアされているオブジェクトを示している。大きなモデル・ ストアは、プレース上のセーブされたプレゼンテーションとユーザ・ドキュメン ト上のプレゼンテーションが共にそこに存在することを示している。カタログは ドキュメントと、プレースの特定プレゼンテーションとの対応関係（マッピング ）を示している。これらが使用されるのは、ユーザがドキュメントをオープンす るときであり、これにより、正しいプレゼンテーションが使用されるようになる 。ユーザのスペース内では、選好情報と最近の活動記録（history）情報のため の記憶域は、人（people）サブシステムが提供する。プレゼンテーション自体は 、それを参照するカタログと一緒にここにストアされる。カタログは、ユーザ選 好MPreferenceCollectionオブジェクトが提供するディクショリナリ・セマンテ ィック（dictionary semantics）を使用する。 ・ 各人はプレース上に１つのプレゼンテーションをもち、そこには、最後に 表示されたときの、そのプレースをユーザに提示するのに必要な一切の情報が収 められている。この情報は、プレース内のオープン・ ドキュメントのリストを含んでいる（プレゼンテーション代用物として表現され 、可能ならば、データ・モデルIDが一緒に付いて表現されている）。 ・ 各人は、複数のプレゼンテーションを１つのドキュメント上にセーブして おくことができる。各人は、それが表示される各プレースごとに異なるプレゼン テーションをもつことができる。 ドキュメント・プレゼンテーション情報のカタログはドキュメントを、それら が表示されたプレース用に存在する既存のセーブされたプレゼンテーションと対 応づける。このカタログに入っている情報は、キー、プレースID、およびプレゼ ンテーションのプレゼンテーション代用物として、モデルID（グローバルID）だ けを必要とするドキュメントである。 プレース・プレゼンテーションには、ドキュメントがいつ初めてオープンされ たか、といったドキュメントに関する情報が、次回にプレースに入ったときステ ートを正しく復元するために必要である。そのためには、ウィンドウ・プレゼン テーションがプレースでいつオープンされたかの通知を受け取る必要がある。こ れは、次のようなプロジージャを通して行われる。 ・ オープン／クローズ／フォロー・コマンドはすべて、ドキュメントをオー プンし、クローズする作業を包含ポリシ・オブジェクト（contained policy object）に委任する形体のモデル・コマンドを使用する。第23図は、好適実施例 に従ってプレース・ドキュメント・ポリシを採用するコマンド・サブクラスを示 すBoochダイアグラムである。ラベル2310は好適実施例に従ってドキュメントを オープンするモデル・コマンドを示している。ラベル2320は2310に示したコマン ドであって、プレース・ドキュメント・ポリシ・オブジェクトに委任するモデル ・コマンドのサブクラスを示している。ラベル2330は、2320で使用されたドキュ メント・ポリシをメモリにストアするmixinクラスである。すべてのプレース固 有モデル・コマンドはラベル2330のオブジェクトからのサブクラスである。ラベ ル2340は、その前に置かれたオブジェクトに示されているオペレーションを実行 するポリシ・オブジェクトである。 ・ ポリシ・オブジェクトは、このプレースに対して行おうとしているタイプ の作用（behavior）を包括している。この作用は協同プレースでは異なり、異な るヒューマン・インタフェースが必要な場合も異なる。 ・ 各コンテナまたはドキュメント・プレゼンテーションがその“オープン” コマンドをメニューに登録するときは、これらのオープン委任コマンド（delega ting open command）を使用し、このコマンドには、ドキュメント登録のための プレースとの連絡方 法に関する情報が入っている。これらのプレゼンテーションは、そのオープン時 にポリシ・オブジェクトを自身で受け取っている。これについては、あとで説明 する。 ・ オープン・コマンドが実行されると、オープンすべきドキュメントを始動 する（これはコマンド自体が実行すべきドキュメントに渡されたとき行われる） 。 ・ オープン・コマンドはオープンを、そこに入っているポリシ・オブジェク トに委任する。 ・ ポリシ・オブジェクトは、そのユーザのためにセーブされたプレゼンテー ションのカタログを調べて、どのプレゼンテーションを使用すべきかを判断する 。 ・ 次に、ポリシ・オブジェクトはそのプレゼンテーションをオープンし、そ のプレゼンテーションのポリシ・オブジェクトを自身と同じになるようにセット する。このようにして、ポリシ・オブジェクトは、プレース内でオープンされた すべてのプレゼンテーションにプロパゲート（propagate）していく。この方法 は、ウィンドウ・プレースがあるときも、複数のプレースが同時にオープンして いるときでも有効である。 ・ 次に、ポリシ・オブジェクトは、ドキュメントがオープンしたことを、プ レース・プレゼンテーショ ンと一緒に登録する。 ・ プレース・プレゼンテーションは、新しいアイテムを追加するようにその オープン・ドキュメント・リストを更新する。 ・ プレース内のドキュメント上のセーブされたプレゼンテーションをオープ ンするときのステップは第24図に示されており、プレース内のドキュメント上の プレゼンテーションをクローズするときのステップは第25図に示されている。 コンテナ・モデル・アーキテクチャ オブジェクトＡがオブジェクトＢを埋め込むとき、ＢのモデルはＡのモデル・ ストアにコピーされる。Ｂは埋め込まれたモデル（embedded model）と呼ばれる 。ＢはＡと共に埋込み階層（embedment hierarchy）を形成する。Ｂのプレゼン テーションは、Ａのプレゼンテーションの内側にフレーム／サムネイル（frame/ thumbnail）として現れる。Ｂのサムネイルは、同じウィンドウとチーム内では 同じ場所（in-place）でオープンすることができ、別のウィンドウであるが、同 じチーム内では場所の外で（out-of-place）オープンすることができる。オブジ ェクトＡがオブジェクトＢを収めているときは、ＢのモデルはＡのモデル・スト アにコピーされることはない。Ｂはコンテナブル （containable）と呼ばれる。ＢはＡと共に包含階層（containment hierarchy） を形成する。Ｂは常に、場所の外で（別のウィンドウとチーム内で）オープンさ れる。 第26図は、埋込みと包含の違いを要約して説明したものである。このメッセー ジでは、比色（color matching）問題に関する要求が行われている。イメージは ドキュメントに埋め込まれ、イメージを越えてスクロールしなくてもメッセージ 全体を包含するように縮小されている。これは、“HEY I'M A FRAME”境界で区 別されている。イメージはデフォルトにより、その場所でオープンされる。フォ ルダはJimに調べさせるJeffのコードを収めている。これはメッセージに包含さ れているので、常に場所の外でオープンされる。 コンテナの固有特性 コンテナは次のような固有特性をもっている。 ・ コンテナはオブジェクトを収容できる。ワークスペース・コンテナ（例： フォルダとプレース）はワークスペース・オブジェクト（例：ドキュメント、フ ォルダ）だけを収容するのに対し、他の特殊目的コンテナは他のタイプのオブジ ェクトを収容できる。例えば、データベース・コンテナはデータベース照会の結 果を収容することができる。あるオブジェクトをコ ンテナから削除すると、そのオブジェクトのモデル（メモリ内の構造）とモデル ・ストア（ディスク上の構造）がシステムから除去される。 ・ コンテナはオブジェクトとの参照リンクを収容できるので、参照されたオ ブジェクトがあるコンテナから別のコンテナへコピーされるとき、これらのリン クを修正するときのスコープ（有効範囲）を提供する。ある参照をコンテナから 削除すると、その参照だけが除去され、参照されたオブジェクトのモデルとモデ ル・ストアには影響しない。非コンテナ（non-container）もオブジェクトへの 参照を収容できる。つまり、コンテナと参照は密に結合されていない。 ・ コンテナは、ファイル・システム階層から独立した包含階層を作ることが できる。言い換えれば、ユーザは、情報がファイル・システムのどこに、どのよ うにストアされているかに関係なく、コンテナを使用すると、情報を自由にユー ザのワークスペースに編成することができる。コンテナは複数のボリュームにま たがることができる。すべてのボリュームが使用可能になっていないと、使用で きないオブジェクトは表示されないか、あるいはぼかされて表示される。コンテ ナ自体、つまり、包含階層のルート（root）はその格納プレース（enclosing pl ace）に残っており、そのプレースと同じ記憶ドメイン（network:machine:volum e）に属している。 ・ スマート・コンテナ（smart container）はロケータ（locator）を使用し て、その内容をフィルタにかけることができる。コンテナの継承特性には、次の ものがある。 ・ コンテナに対するユーザのオペレーション（カット／コピー／ペースト、 ドラグ／ドロップ、選択、移動など）は、一定の回数に限り取り消し（undo）、 やり直す（redo）ことができる。 ・ コンテナはウィンド／フレーム／サムネイル／アイコン・プレゼンテーシ ョンをもつことができる。同じコンテナのプレゼンテーションは複数にすること が可能であり、各プレゼンテーションは他と異なる外観と、場合によっては、感 触をもっている（例：フォルダとrolodex）。 使い方のシナリオ 以下に示したシナリオでは、フォルダとドキュメントを使用して、ユーザとコ ンテナおよびコンテナブル（containable）とのやりとりを説明している。他の タイプのコンテナとコンテナブルの働き方も、同じである。 フォルダを作成する：フォルダ文房具でダブルクリックすると、新しいフォル ダがシェルフに作成される。他のタイプのコンテナを作成するための他のタイ プの文房具もある。フォルダ作成ロジックを示すVDLダイアグラムは第27図に示 されている。 フォルダをあるフォルダから別のフォルダへコピーする：オプション・ドラグ （option-drag）でオプション・キーを押えたまま、フォルダＡをフォルダＸか らドラグし、それをドロップしてフォルダＹに入れる。フォルダＡ′はすべての オリジナル・ドキュメントのコピーを収容する。これらのオリジナルがリンクさ れていると、コピーは相互にリンクされるが、オリジナルにはリンクされない。 フォルダ・コピー・ロジックを示すVDLダイアグラムは第28図に示されている。 フォルダをあるフォルダから別のフォルダへ移動する：フォルダＡをフォルダ Ｘからドラグし、それをドロップしてフォルダＺに入れる。フォルダ移動ロジッ クを示すVDLダイアグラムは第29図に示されている。 フォルダを削除する：フォルダＡをフォルダＺからドラグし、それをドロップ してごみ箱（Waste Basket）（トラッシュ・カンを指す参照）に入れるか、トラ ッシュ・カンに入れる。フォルダ移動ロジックを示すVDLダイアグラムは第30図 に示されている。 コンテナブルをあるフォルダから別のフォルダへコピー（移動）する：ドキュ メントFooをフォルダＸからオプション・ドラグし、それをドロップしてフォル ダＹに入れる。コピーされたドキュメントがリンクを もっていれば、そのリンクは正しく修正される。移動されたドキュメントは、ソ ース・フォルダから除去される。 コンテナブルをフォルダからドキュメントへコピー（移動）する：ドキュメン トFooをフォルダＹからドキュメントBarへオプション・ドラグする。ドキュメン トはコンテナブルも収容できるので、ドキュメントFooはドキュメントBarにアイ コンとして現れる。（移動されたコンテナブルはフォルダから除去される。）フ ォルダ移動ロジックを示すVDLダイアグラムは第31図に示されている。

【手続補正書】特許法第１８４条の８ 【提出日】１９９５年６月１日 【補正内容】 （原文明細書第１頁〜第２頁） 明細書 プレース・オブジェクト・システム 著作権表記 本出願は、一部に著作権保護の対象となる内容を含んでいる。著作権者は、何 人が情報を得る目的で特許出願の一部として複製しても、それを妨げるものでは ないが、他のすべての権利、特に本内容の商業的利用に関する権利を留保する。 発明の分野 本発明は、一般的には、オブジェクト指向オペレーティング・システムにおい て種々の情報を編成し、アクセスする方法およびシステムに関し、より具体的に は、異種コンテナ・オブジェクト（distinct container objects）内でユーザが やりとり（interaction）することに関する。 発明の背景 インタフェースにコミュニティ・センス（sense of community）をもたせると いう設計思想を中心に構築されるユーザ・インタフェースを提供することがます ます重要になっている。このコミュニティ・センスは、人やプレース（場所）、 その他にツール、器具、文房具、ドキュメントといった項目を図形表現すること に由来している。エルゴノミック・インタフェース（ergonomic interface−人 間工学的インタフェース）を提供する初期の試みでは、Xerox Starコンピュータ ・システムとそれに追随するシステムに見られるような、さらには、米国特許第 5,107,443号、第5,072,412号、第5,159,669号、第4,974,173号および第5,121,47 8号に特許されているようなデスクトップ・メタフォア（desktop metaphor）が 使用されていた。 コンピュータ・システムのユーザにエルゴノミック・インターフェイスを提供 する初期の試みのもうひとつの例は、“Form and Room：Metaphors for Groupwa re”（「フォームとルーム，グループ・ウエアのためのメタフォア」CONFERENCE ON ORGANIZATIONAL COMPUTING SYSTEMS（組織的なコンピュータ・システムに関 する会議）vol.12、no.2,3,5、94-105頁、ジョージア州アトランタ、1991 年11月）と題された論文である。この参考資料のなかで、ディスプレイ上でオー プン・ウインドウで表現されている“ルーム”には、人物のリストがあり、ディ スプレイ上でアイコンとして描かれている。その他のアイコンは、複写機、ファ ックス、ごみ箱、およびブリーフ・ケースを表すのに利用されている。アイコン は、オブジェクト、たとえば文書、をアイコン上に置くことで、対話的に働かせ ることができる。たとえば、ある文書は、ごみ箱アイコンのうえに重ねることで 、その削除が完了する。しかしながら、個々のルームは、単なるグラフィックな 表現にすぎず、ディスプレイ上の単一のウインドウに制限されている。 発明の概要 コンピュータ・システムのユーザ、特に未経験のユーザは、実世界の特性を備 えた環境を作り出すアプリケーションの恩益を受けている。特に、アプリケーシ ョンに未経験のユーザは使い慣れた参照フレーム（frame of reference）を利用 すると、アプリケーションの概念を容易に把握できるであろう。好適実施例では 、他のオブジェクトをそこに収めておくことができるプレース・オブジェクト（ place object）のセットをユーザが作成できるようにすることによって、このよ うな環境を提供している。 好適実施例によれば、コンピュータ・システムにおける情報は、コンピュータ のメモリ内の複数のプレース・オブジェクト内に編成される。プレース・オブジ ェクトへのアクセスは、マウスやその他のカーソル位置付けデバイスによって、 カーソル文字をそのプレース・オブジェクトの上に置くことにより行われる。そ のあとで、そのプレース・オブジェクトが選択されると、プレース・オブジェク トに関連するメソッドが関連のユーザ・インタフェースをユーザに提示して、プ レース・オブジェクトの使用を容易にする。 図面の簡単な説明 本発明の上記および他の目的、側面および利点を理解しやすくするために、添 付図面を参照して本発明の好適実施例について、以下で詳しく説明する。 請求の範囲 １．ディスプレイ装置を有するコンピュータ・システムのメモリに、物理的位置 に関連する情報をストアする方法において、、 （a）複数のプレース・クラスを定義する情報をメモリにストアするステップ であって、各前記複数のプレース・クラスは、物理的位置を表すディスプレイ表 示を生成するデータ、情報を保持するためのデータ構造、各プレース・クラスか らプレース・オブジェクトを構築するためのメンバー関数、オブジェクトに関す る情報を前記データ構造に挿入する複数のメンバー関数、および第１のプレース ・オブジェクトから第２のプレース・オブジェクトへオブジェクトを識別する情 報を伝達するための複数のメンバー関数を含み、 （b）複数のユーザの一人のために、第１のプレース・オブジェクトをメモリ にインスタンス生成するための構築を行うメンバー関数を実行するステップであ って、第１のプレース・オブジェクトは、第１の物理的位置を表すディスプレイ 表示を有しており、 （c）第１のインスタンス生成されたプレース・オブジェクトのデータ構造に 、一人のユーザのためのユーザ選好情報を挿入する複数の挿入メンバー関数のう ちの第１の関数を実行するステップと、 （d）複数の挿入メンバー関数のうちの第２の関数を 実行して、第１のインスタンス生成されたプレース・オブジェクトのデータ構造 中の物理的位置で特徴付けられる関数を行うアプリケーション・プログラムを挿 入し、選好情報がアプリケーション・プログラムに適用されるようにするステッ プと を備えることを特徴とする方法。 ２．請求の範囲第１項に記載の方法において、 （e）一人のユーザのために、メモリに第２のプレース・オブジェクトをイン スタンス生成する、構築を行うメンバー関数を実行ステップであって、第２のプ レース・オブジェクトは、第２物理的位置を表すディスプレイ表示を有しており 、 （f）複数の伝達メンバー関数の１つを実行して、第１にインスタンス生成さ れたプレース・オブジェクトのデータ構造から第２にインスタンス生成されたプ レース・オブジェクトのデータ構造へユーザ選好情報を伝達し、ユーザが第１物 理的位置から第２物理的位置へ移動するように見えるステップと をさらに備えることを特徴とする方法。 ３．請求の範囲第２項に記載の方法において、 （g）複数のユーザのうちの他の一人の選好情報を、第１のインスタンス生成 されたプレース・オブジェクトのデータ構造中に挿入するための複数の挿入メン バー関数のうちの第２の関数を実行するステップ をさらに備えることを特徴とする方法。 ４．請求の範囲第３項に記載の方法において、複数のプレース・クラスの各々は 、複数のユーザのうちの二人が対話できる複数の協同作業メンバー関数を有して おり、 （h）一人のユーザから他のユーザに情報を伝達する複数の協同作業メンバー 関数の１つを実行するステップ をさらに備えることを特徴とする方法。 ５．請求の範囲第１項に記載の方法において、 （i）複数の挿入メンバー関数のうちの選択されたそれぞれの関数を実行し、 複数のアプリケーション・プログラムを第１のインスタンス生成されたプレース ・オブジェクトのデータ構造に挿入するステップをさらに備え、前記複数のアプ リケーション・プログラムの各々は、第１のインスタンス生成されたプレース・ オブジェクトで表される物理的位置に存在する物理的オブジェクトを表すオブジ ェクトをインスタンス生成する ことを特徴とする方法。 ６．請求の範囲第１項に記載の方法において、 （j）複数の挿入メンバー関数の１つを実行し、人を表す複数の人オブジェク トの情報を第１のインスタンス生成されたプレース・オブジェクトのデータ構造 に挿入するステップをさらに備え、前記複数の人オブジェクトは、第１のインス タンス生成されたプレース・オブジェクトで表される物理的位置に存在する人物 を表す ことを特徴とする方法。 ７．複数のユーザの間で対話するコンピュータ・システムにおいて、 （a）メモリと、 （b）前記メモリにストアされており、異なる物理的位置を表す属性を各々に 有している複数のプレース・クラスと、 （c）前記メモリにストアされており、複数のプレース・クラスの１つからイ ンスタンス生成され、対応する１つのプレース・クラスの物理的位置を表してい るプレース・オブジェクトと、 （d）前記プレース・オブジェクトに参照された少なくとも１つのワークスペ ース・エレメントと、 （e）前記プレース・オブジェクトにストアされたユーザ情報プロフィールと 、 （f）前記プレース・オブジェクトをアクチベートする手段と、 （g）前記プレース・オブジェクトがアクチベートされたとき、前記ワークス ペース・エレメントに前記ユーザ情報プロフィールを適用するための手段と を備えることを特徴とするコンピュータ・システム。 ８．請求の範囲第７項に記載のコンピュータ・システムにおいて、プレース・オ ブジェクトにストアされたサブプレース・オブジェクトをさらに備えることを特 徴とするコンピュータ・システム。 ９．請求の範囲第７項に記載のコンピュータ・システムにおいて、プレース・オ ブジェクトがアクチベートされたときに存在するコンピュータ・システム・パラ メータを表す情報を含むユーザ情報プロフィールに従ってコンピュータ・システ ムを構成する手段を備えることを特徴とするコンピュータ・システム。 ９．請求の範囲第７項に記載のコンピュータ・システムにおいて、プレース・オ ブジェクトがアクチベートされたとき、物理的位置に関連する予め定められたド キュメントをオープンする手段を含むことを特徴とするコンピュータ・システム 。 10．請求の範囲第９項に記載のコンピュータ・システ ムにおいて、 プレゼンテーション・デバイスと、 プレース・オブジェクトがアクチベートされたとき、プレース・オブジェクト にストアされているユーザ情報プロフィールに従ってプレゼンテーション・デバ イスにドキュメントを提示する手段と を含むことを特徴とするコンピュータ・システム。 11．請求の範囲第10項に記載のコンピュータ・システムにおいて、プレース・オ ブジェクトにストアされたユーザ情報プロフィールに従ってコンピュータ・シス テムを構成する手段を含むことを特徴とするコンピュータ・システム。 12．請求の範囲第11項に記載のコンピュータ・システムにおいて、コンピュータ ・システムの特定のユーザに関連したユーザ情報プロフィールに従ってドキュメ ントを提示する手段を含むことを特徴とするコンピュータ・システム。 13．請求の範囲第10項に記載のコンピュータ・システムにおいて、 メモリにインスタンス生成されたトラベルバッグ・オブジェクトと、 それぞれが前記トラベルバッグ・オブジェクトに含 まれており、特定のユーザにより使用に供される複数のオブジェクトを前記トラ ベルバッグ・オブジェクトにストアする手段と を含むことを特徴とするコンピュータ・システム。 14．請求の範囲第７項に記載のコンピュータ・システムにおいて、特定のユーザ に関連した情報をストアするための人オブジェクトを、人クラスからインスタン ス生成するための手段を含むことを特徴とするコンピュータ・システム。 15．請求の範囲第７項に記載のコンピュータ・システムにおいて、プレース・オ ブジェクトがアクチベートされたとき、プレース・オブジェクトにストアされた ユーザ情報プロフィールに従って、２人のユーザ間に協同作業をインスタンス生 成するための手段を含むことを特徴とするコンピュータ・システム。 16．請求の範囲第７項に記載のコンピュータ・システムにおいて、プレース・オ ブジェクトのドキュメントがアクチベートされたとき、プレース・オブジェクト にストアされたユーザ情報プロフィールに従って、２人のユーザ間に協同作業を インスタンス生成するための手段を含むことを特徴とするコンピュータ・システ ム。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 9288−5Ｌ Ｇ０６Ｆ 15/20 ５９６Ｚ 9288−5Ｌ ５７０Ｄ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，Ｇ Ｂ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ， ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ

Claims (1)

1. 【特許請求の範囲】 １．情報をコンピュータ・システムのメモリ内に編成する方法であって、 （a）プレース・オブジェクトをデフォルト・プレース・オブジェクトに基づ いてメモリ内にインスタンス生成するステップと、 （b）プレース・オブジェクト内の少なくとも１つのワークスペース・エレメ ントを参照するステップと、 （c）プロフィール情報をプレース・オブジェクトにストアするステップと を含むことを特徴とする方法。 ２．請求の範囲第１項に記載の方法において、子（child）プレースを示す情報 をプレース・オブジェクトにストアするステップを含むことを特徴とする方法。 ３．請求の範囲第１項に記載の方法において、プレース・オブジェクトがアクチ ベートされたとき、コンピュータ・システム・パラメータを示すプロフィール情 報に従ってコンピュータ・システムをリストア（復元）するステップを含むこと を特徴とする方法。 ４．請求の範囲第１項に記載の方法において、プレース・オブジェクトがアクチ ベートされたとき特定のドキュメントをオープンするステップを含むことを特徴 とする方法。 ５．請求の範囲第４項に記載の方法において、プレースがアクチベートされたと きプロフィール情報に従ってドキュメントを提示するステップを含むことを特徴 とする方法。 ６．請求の範囲第１項に記載の方法において、コンピュータ・システムの特定ユ ーザに関連するプロフィール情報に従ってコンピュータ・システムをリストアす るステップを含むことを特徴とする方法。 ７．請求の範囲第６項に記載の方法において、コンピュータ・システムの特定ユ ーザに関連するプロフィール情報に従ってドキュメントを提示するステップを含 むことを特徴とする方法。 ８．請求の範囲第１項に記載の方法において、特定のユーザによる使用のために 、一時的オブジェクトをトラベル・バッグにストアしておくステップを含むこと を特徴とする方法。 ９．請求の範囲第１項に記載の方法において、特定のユーザに関連する情報をス トアするための人オブジェクトを作成するステップを含むことを特徴とする方法 。 10．複数のユーザ間でやりとりするためのコンピュータ・システムであって、 （a）メモリ内にあって、デフォルト・プレース・オブジェクトからインスタ ンス生成されたプレース・オブジェクトと、 （b）プレース・オブジェクト内で参照された少なくとも１つのワークスペー ス・エレメントと、 （c）プレース・オブジェクトにストアされたプロフィール情報と を含むことを特徴とするコンピュータ・システム。 11．請求の範囲第10項に記載のシステムにおいて、コンピュータ・システムのメ モリ内のプレース・オブジェクトにストアされた、子（child）プレースを示す 情報を含むことを特徴とするシステム。 12．請求の範囲第10項に記載のシステムにおいて、プレース・オブジェクトがア クチベートされたときコンピュータ・システム・パラメータを示すプロフィール 情報に従って、コンピュータ・システムをリストアす る手段を含むことを特徴とするシステム。 13．請求の範囲第10項に記載のシステムにおいて、プレース・オブジェクトがア クチベートされたとき特定のドキュメントをオープンする手段を含むことを特徴 とするシステム。 14．請求の範囲第13項に記載のシステムにおいて、プレースがアクチベートされ たときコンピュータ・システムのメモリにストアされたプロフィール情報に従っ てドキュメントを提示する手段を含むことを特徴とするシステム。 15．請求の範囲第14項に記載のシステムにおいて、コンピュータ・システムの特 定ユーザに関連するプロフィール情報に従ってコンピュータ・システムをリスト アする手段を含むことを特徴とするシステム。 16．請求の範囲第14項に記載のシステムにおいて、コンピュータ・システムの特 定ユーザに関連するプロフィール情報に従ってドキュメントを提示する手段を含 むことを特徴とするシステム。 17．請求の範囲第10項に記載のシステムにおいて、特定のユーザによる使用のた めに、一時的オブジェクト をトラベル・バッグにストアしておく手段を含むことを特徴とするシステム。 18．請求の範囲第10項に記載のシステムにおいて、特定のユーザに関連する情報 をストアするための人オブジェクトを作成する手段を含むことを特徴とするシス テム。 19．請求の範囲第10項に記載のシステムにおいて、プレースがアクチベートされ たとき、コンピュータ・システムのメモリにストアされたプロフィール情報に従 って協同作業を開始する手段を含むことを特徴とするシステム。 20．請求の範囲第10項に記載のシステムにおいて、ドキュメントがアクチベート されたとき、コンピュータ・システムのメモリにストアされたプロフィール情報 に従って協同作業を開始する手段を含むことを特徴とするシステム。