JPH09500744A

JPH09500744A - プレース・オブジェクト・システム

Info

Publication number: JPH09500744A
Application number: JP7501720A
Authority: JP
Inventors: ディキンソン，ロバート，デイヴィッド
Original assignee: タリジェントインコーポレイテッド
Priority date: 1993-06-03
Filing date: 1994-01-10
Publication date: 1997-01-21
Also published as: DE69406280D1; AU6812294A; US5634057A; EP0693194B1; EP0693194A1; CN1113395A; CA2141930A1; WO1994029791A1

Abstract

(57)【要約】プレース・オブジェクト・ディスプレイ・システムに関するもので、情報をプレース・オブジェクト内に編成し、そのプレース・オブジェクトをユーザに表示する方法と装置が開示されている。作成されたプレース・オブジェクトは、そのあとで多数のユーザがアクセスすることができる。従って、本発明によれば、あるプレース・オブジェクトをアクセスしたユーザは、情報をディスプレイ・システム内で編成し、他のユーザと通信することができる。

Description

【発明の詳細な説明】プレース・オブジェクト・ディスプレイ・システム関連特許出願の相互参照本出願は、1992年12月23日出願の特許出願(発明の名称「オブジェクト指向フレームワーク・システム」(Object Oriented Framework System)、発明者Debra L.Orton、David B.Goldsmith，Christopher P. Moeller、およびAndrew G.Henin ger、承継人Taligent Inc.)の関連出願であり、その開示内容は引用により本明細書の一部を構成するものである。また、本出願は特許出願(発明の名称「コンカレント・フレームワーク・システム」(Concurrent Framework System)、発明者Jack Palevich他、承継人Taligent Inc.)の関連出願でもあり、その開示内容は引用により本明細書の一部を構成するものである。発明の分野本発明は、一般的には、オブジェクト指向オペレーティング・システムにおいて種々の情報を編成し、アクセスする方法およびシステムに関し、より具体的には、異種コンテナ・オブジェクト(distinct container objects)内でユーザがやりとり(interaction) することに関する。発明の背景インタフェースにコミュニティ・センス(sense of community)をもたせるという設計思想を中心に構築されるユーザ・インタフェースを提供することがますます重要になっている。このコミュニティ・センスは、人やプレース（場所）、その他にツール、器具、文房具、ドキュメントといった項目を図形表現することに由来している。エルゴノミック・インタフェース(ergonomic interface−人間工学的インタフエース) を提供する初期の試みでは、Xerox Starコンピュータ・システムとそれに追随するシステムに見られるような、さらには、米国特許第5,10 7,443 号、第5,072,412 号、第5,159,669 号、第4,974,173 号および第5,121,47 8 号に特許されているようなデスクトツプ・メタフオア(desktop metaphor)が使用されていた。発明の概要コンピュータ・システムのユーザ、特に未経験のユーザは、実世界の特性を備えた環境を作り出すアプリケーションの恩益を受けている。特に、アプリケーションに未経験のユーザは使い慣れた参照フレーム(frame of reference)を利用すると、アプリケーションの概念を容易に把握できるであろう。好適実施例では、他のオブジェクトをそこに収めておくことができるプレース・オブジェクト(pla ce 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を装備している。ワークステーションには、アップル社Sy stem/7 （登録商標）オペレーティング・システムなどのオペレーティング・システムが置かれている。ドキュメント・フレームワーク・アーキテクチャ(document fram ework architecture)はRAM14 に置かれており、CPU10 の制御の下で、本発明の好適実施例を実現することを受け持っている。好適実施例では、本発明は、オブジェクト指向プログラミング技法を使用して C++ プログラミング言語で書かれている。この分野に精通しているものならば容易に理解されるように、オブジェクト指向プログラミング(Object-Oriented Pro gramming - OOP)のオブジェクトは、データ構造とデータに対するオペレーション（操作、演算など）からなるソフトウェア・エンティティ(software entity) である。これらのエレメントが協力し合うことにより、オブジェクトは、そのデータ・エレメントで表されたその特性、およびそのデータ操作関数(data manupu lation functions)で表されたその作用(behavior)からとらえて、ほとんどどのような実世界のエンティティでもモデル化することができる。この方法によると、オブジェクトは、人やコンピュータなどの具体物をモデル化することができ、また、数や幾何学的概念などの抽象概念をモデル化することができる。オブジェクト・テクノロジの利点は次の３つの基本的原理から得られるものである。それは、カプセル化(encapsulation)、多態 (polymorphism)および継承(inheritance)である。オブジェクトは、そのデータの内部構造とその関数が実行されるときのアルゴリズムを隠蔽する。つまりカプセル化する。これらのインプリメンテーション細部を見せる代わりに、オブジェクトは、外部情報(extraneous information)のないクリーンな形でその抽象化(abstractions)を表しているインタフェースを提示する。多態はカプセル化をさらに一歩進めたものである。この考え方は、多数の形体をもつ、１つのインタフェースである。あるソフトウェア・コンポーネントは、別のコンポーネントがなんであるかを正確に知らなくても、その別のコンポーネントを要求することができる。要求を受け取ったコンポーネントはその要求を解釈し、その要求をどのように実行すべきかを、その変数とデータに従って判断する。三番目の原理である継承によれば、開発者は既存の設計やコードを再利用することができる。この機能を利用すると、開発者はソフトウェアを初めから作ることが回避される。むしろ、継承を通して、開発者は作用を継承するサブクラスを派生し、その作用を開発者独自の要求に合ったものにカストマイズすることができる。従来のアプローチでは、オブジェクトとクラス・ライブラリを手続き的環境で階層化する方法がとられていた。市販されている多くのアプリケーション・フレームワークはこの設計手法を採用している。この設計では、モノリシック・オペレーティング・システム(monolithic operating sy stem)の上に１つまたは２つ以上のオブジェクト層が置かれている。このアプローチでは、カプセル化、多態および継承のすべての原理がオブジェクト層に採用され、手続き的プログラミング技法を大幅に改善しているが、このアプローチにはいくつかの制約がある。これらの問題は、開発者が自身のオブジェクトを再利用することは容易であるが、他のシステムからのオブジェクトを使用することが困難であるため、手続き的オペレーティング・システム(OS)のコールを使用して、下位の非オブジェクト層まで到達する必要があることに起因している。オブジェクト指向プログラミングがもつもう１つの側面は、アプリケーションを開発するのにフレームワーク・アプローチを採用していることである。フレームワークの最も合理的な定義の１つとして、イリノイ大学のRalph E.Johnson と PurdueのVincentF.Russo によるものがある。両氏の1991年の論文「オブジェクト指向設計の再利用」(Reusing Object-Oriented Designs)、イリノイ大学技術報告書UIUCDCS91-1696の中で、次のような定義を提案している。「抽象クラスとは、一組の責任分担を協力し合って実行するオブジェクトの集合を設計したものである。従って、フレームワークとは、組で定義された演算責任分担を協力し合って実行するオブジェクト・クラスが集まったものである。」プログラミング側から見たときは、フレームワークとは、基本的には、実働アプリケーション(working application)の事前に作られた構造を提供する、相互に接続されたオブジェクト・クラスの集まりである。例えば、ユーザ・インタフェース・フレームワークは、描画ウィンドウ(drawi ng window)、スクロールバー、メニューなどをサポートし、これらの「デフォルト（省略時）」の作用を提供することができる。フレームワークはオブジェクト・テクノロジを基礎にいているので、この作用を継承してオーバライド(overrid e)することにより、開発者はフレームワークを拡張し、カストマイズした解決手法を特定の専門分野で作ることができる。これが従来のプログラミングに比べて大きな利点であるのは、プログラマはオリジナル・コードを変更することなく、むしろソフトウェアを拡張できるからである。さらに、フレームワークは、アーキテクチャに関するガイダンスとモデリングを提供すると同時に、問題領域に特有の個々のアクションを指定することから開発者を解放するので、開発者はいくつかのコード層を通って盲目的に作業する必要がない。ビジネス側から見たときは、フレームワークは、特定の知識分野において専門知識をカプセル化または具現化する方法と見ることができる。企業の開発集団、独立ソフトウェア・ベンダ(Independent Software Vendors - ISV)およびシステム統合者(systems integrators)は、前述した例のように、製造、会計、通貨取引きといった特定分野における専門知識をもっている。この専門知識はコードで具現化されている。フレームワークを使用すると、企業は、その専門知識を企業のコードで具現化することにより、専門知識の共通特性を取り込んで、パッケージ化することができる。まず、そのようにすると、開発者は専門知識を利用するアプリケーションを作成または拡張できるので、問題がいったん解決されれば、ビジネス・ルールや設計は統一的に実施され、使用されることになる。また、フレームワークと、フレームワークの背景にある具現化された専門知識は、製造、会計、バイオテクノロジといった垂直的マーケットにおいて専門知識を得た企業にとっては、戦略的資産をもつことを意味し、企業の専門知識をパッケージ化し、再販し、流布し、テクノロジの進歩と普及化を促進するための分配メカニズムをもつことになる。歴史的には、フレームワークがパーソナル・コンピューティング・プラットフォーム上の主流概念として出現したのは、つい最近のことである。この移行を助長したのが、C++ といったオブジェクト指向言語の出現である。従来までは、C+ + は大部分がUNIXシステムと研究者のワークステーション上に搭載され、コマーシャル・ベースのパーソナル・コンピュータには搭載されていなかった。いくつかの大学や研究所のプロジェクトが今日の商用フレームワークおよびクラス・ライブラリの先駆けとなり得たのは、C++ などの言語やSmalltalk などの他のオブジェクト指向言語のお陰である。その例のいくつかを挙げると、スタンフォード大学のInterViews、カーネギ・メロン大学のAndr ewツールキット、チューリッヒ大学のET++フレームワークがある。フレームワークは、どのレベルのシステムに関心があり、どのような問題を解決しようとしているかに応じて、多種類のものがある。フレームワークの種類はユーザ・インタフェースの開発を支援するアプリケーション・フレームワークから、通信、印刷、ファイル・システム・サポート、グラフィックスなどの基本的システム・ソフトウェア・サービスを提供する低レベルのフレームワークまでにわたっている。商用化されているアプリケーション・フレームワークの例をいくつか挙げると、MacApp(Apple)、Bedrock(Symantec)、OWL(Borland)、NeXtStep A pp 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 collabora tion style)をもっており、これらはそのプレース・オブジェクトの目的を補足するものである。従って、協同構成(collaboration arrangement)には、ブロードキャスト・スクリーン共有、対話式スクリーン共有、電話通信(telephony)、共有ホワイトボード(shared white board)、プロジェクトまたはドキュメント、注釈が付けられる掲示板スレッド(bulletin board thread)、ビデオ会議、あるいはこれらの組合せを含めることができる。スクリーン共有協同モデルは、ホスト・ワークステーション上に置かれている、プレースの中のすべてのオブジェクトを他のワークステーションにいる複数のユーザに表示する。しかし、ホスト・ワークステーション以外のワークステーションに置かれているオブジェクトはいずれも、ホスト・ワークステーションに移されるまでは表示されない。スクリーン共有モデルでは、すべてのユーザはあるプレース・オブジェクトを同じ表示を共有する必要がある。スクリーン共有によると、異なるプレース・オブジェクトの中で異なる種類のやりとり(interaction -対話)を行うことができる。例えば、複数の設計者の小グループ会議では、各設計者が異なるロケーションにいても図面はリアルタイムで分析され、修正される。この場合、各設計者は、図面を修正する能力をもつことになる。別の例として、プレース・オブジェクトを学校の講義室とすることができ、プレゼンテーションをあるユーザから他のユーザ・グループにブロードキャスト（同報通信）する。このプレゼンテーションを行っているユーザは、マルチメディア・トーク(multimedia talk)を作成し、クラスの他の人達にそれを伝えることができる。プレゼンテーションが行われている間、クラスのメンバは、講師のプレゼンテーションを変更するために、どのようなことを行うことも許されない。しかし、他のユーザはメモをとったり、ユーザ間の議論に参加することは許される。ドキュメントのように、注釈を付けたり、マージングしたりできるオブジェクトは、表示目的のためにすべてのユーザによって操作される。しかし、ドキュメントに対する各ユーザの表示は、異なるものである。従って、複数のユーザが同時にあるドキュメントに注釈を付けたり、マージングしたりすることが可能である。これが可能であるのは、どのユーザも、他のユーザと共通の表示を共有していないからである。注釈マージングやオブジェクト・マージング協同作業に関与する各ユーザが、あるドキュメントの異なる部分で作業することができるのはそのためである。オブジェクト・マージングと注釈マージングの協同モデルは、ドキュメントのように、プレース・オブジェクト内のオブジェクトを、複数のユーザに同時にオープンするので、各ユーザはオブジェクトの異なる部分を見ることができる。例えば、あるユーザがドキュメントの序文を書いている間に、別のユーザが結論を書くことができる。この例では、オープン・ドキュメントは協同作業に参加する各ユーザに自動的に表示されることはない。むしろ、各ユーザはそのドキュメントのコピーをオープンして編集することになるが、そのコピーはあとでメイン・ドキュメントと一致させる。以上のように、プレース・オブジェクト内のオブジェクトは、そのオブジェクトをサポートしている協同モデルをベースにしてサポートされる。スクリーン共有の協同モデルは、協同作業内のすべてのユーザに対してオブジェクトをオープンする。スクリーン協同作業内の各ユーザは、データの１つの表示に束縛されているので、ファイル・ドキュメントの一部分だけが一度に一回の割合で処理される。例えば、すべてのユーザがグラフィック・ドキュメントに変更を加えることができるのは、大部分のグラフィック・プログラムが、グラフィック・ドキュメント内のデータをすべて収めている全画面表示(full screen view)をサポートしているからである。しかし、ワード・プロセッシング・ドキュメントは、複数ページ・ドキュメントであるので事情が異なる。そのために、協同作業内のすべてのユーザは、一度に１ページずつだけをディスプレイ上に表示して、作業を行うことができる。従って、ホスト側のワークステーションに置かれているすべてのオープン・ワード・プロセッシング・ドキュメントはすべてのユーザに表示される。コンテナの固有特性コンテナは次のような固有特性をもっている。・コンテナは、オブジェクトを収容することができる。ワークスペース・コンテナ（例えば、フォルダとプレース）は、ワークスペース・オブジェクト（例えば、ドキュメント、フォルダ）だけを収容するのに対して、他の特殊目的コンテナは他のタイプのオブジェクトを収容することができる。例えば、データベース・コンテナはデータベース照会(database query)の結果を収容することができる。あるオブジェクトをコンテナから削除すると、そのオブジェクトのモデル（メモリ内の構造）とモデル・ストア（ディスク上の構造）がシステムから除去される。・コンテナはオブジェクトとの参照リンク (reference link)を収容できるので、参照されたオブジェクトがあるコンテナから別のコンテナヘコピーされるときこれらのリンクを修正(fixing-up)するときのスコープ（有効範囲）となる。ある参照をコンテナから削除すると、その参照だけが除去され、参照されたオブジェクトのモデルとモデル・ストアは影響されない。非コンテナ(non-container)もオブジェクトへの参照を収容できるが、これは、コンテナと参照が密に結合されていないためである。・コンテナはファイル・システム階層から独立した包含階層(containment h ierarchy)を構築することができる。言い換えれば、ユーザは、情報がファイル・システムのどこに、あるいはどのようにストアされているかに関係なく、情報を自由に編成してワークスペースに置いておくことができる。コンテナは複数のボリュームにまたがることができる。すべてのボリュームが利用できないと、利用できないオブジェクトは表示されないか、あるいはぼかされて(gray out)表示される。コンテナ自体、つまり、包含階層のルート(root)はその格納プレース(e nclosing place)に残されており、そのプレースと同じ記憶ドメイン(storage do main)(network:machine:volume)に属している。ディスプレイ・インタフェース内のプレース・オブジェクトプレース・オブジェクトは階層構造になっており、ユーザ・インタフェースでの最高レベル・オブジェクトになっている。従って、すべてのやりとりと通信はある種のプレース・オブジェクトのコンテキスト内で行われる。各ユーザは独自のホームプレース・オブジェクト(home place object)をもっている。ホームプレース・オブジェクトは基本的トップ・レベル・オブジェクトで、セッションを開始するとユーザに表示される。プレース間のナビゲーションは、ユーザが別のプレース・オブジェクトをホームプレースに追加するか、あるいはプレースへの遠隔アクセスを必要とするとき可能である。ユーザは、サブプレース(sub-place )と呼ばれるものをホームプレース内に作ることができる。プレース・オブジェクトはタスク、プロジェクト、協同モデルといった、特性別にセグメント化することができる。あるプレースが大きなサイズまでになったとき、ユーザはそのプレースを、いくつかの小さなプレースに再分割することができる。しかし、デスクトップ・ディスプレイ全体を包括するプレース・オブジェクトはウィンドウに表示することもできる。アプリケーションではないプレース・オブジェクトは情報を編成し、構造化するときに使用される。あるプレース・オブジェクトでの作業の個別的要求に応じて、ユーザはそのプレース内にオブジェクトを挿入すると、その作業が容易になる。そのようなオブジェクトには、ファイル・ドキュメント、ツール、およびコンテナがある。プレース・オブジェクトに入れられたオブジェクトは、望み通りに編成し、保守することができる。例えば、家計管理 (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 をデスクトップ・ディスプレイのサイズまで拡大すると、ワークスペース210 内に全部が表示されることになる。好適実施例では、単一のワークステーションを共有する複数のユーザをサポートしており、各ユーザは個人的情報データが置かれているホームプレース・オブジェクトをもつことができる。各ユーザはサブプレース・オブジェクトをホームプレース・オブジェクト内に作っておくと、個人的情報を分割(partition)することができる。第４図に示すように、ワークステーション内のユーザプレース・オブジェクトの代表的階層が示されている。ワークステーション400 は、Ann、John およびTe rry という名前の３人のユーザが共有している。共有ユーザの各々は、それぞれ 402,404,406 に示すホームプレース・オブジェクトを所有している。さらに、ホームプレース・オブジェクト404(Johnのホームプレース・オブジェクト)はサブプレース・オブジェクト408(Johnのワークプレース・オブジェクト)と410(John のアートプレース(Art P1ace)オブジェクト)に再分割されている。ワークステーションには、特定のユーザと関連づけられていない他のプレース・オブジェクトを置いておくことも可能である。そのようなプレース・オブジェクトとしては、好ましくは、ゲスト・プレース・オブジェクト(guest place obj ect)、ログイン・プレース・オブジェクト(log-in place object)、システム保守プレース・オブジェクト(system maintenance place object)、転送プレース・オブジェクト(transfer place object)などがある。ゲストまたは公開(public )プレース・オブジェクトは、ワークステーションに知らされていないユーザによるアクセスを可能にする。ログイン・プレース・オブジェクトは、オブジェクトとユーザ・セッションの開始に関する情報とを収めている。システム保守プレース・オブジェクトはユーザが保守タスクを実行することを可能にし、マシン・ルームを収めている。マシン・ルームはワークステーションに関する持続的構成情報を収めており、特定のユーザと関連づけられていない場合がある。転送プレース・オブジェクトは、情報をストアし、ワークステーションのユーザ間で情報を転送することを可能にする。プレース・オブジェクトのアクセスプレース・オブジェクトをアクセスし、その間でナビゲートするには、いくつかの方法がある。例えば、(i)資源ブック(resource book)による方法、(ii)マップ表現の内部での方法、(iii)ポストカードなどのプレースへの参照の使用による方法、(iv)インビテーション（invitation：招待状）による方法がある。資源ブックにより、ブックのコンテキスト内で情報をユーザに提示して、プレース・オブジェクトへアクセスすることができる。通信ブック（communication book）に収められている情報は、名前サービス・ディレクトリ(name service di rectory)内に存在する、資源と呼ばれるオブジェクトに関するものである。従って、資源ブックを通してアクセスできる資源には、人やプレースなどのオブジェクトが含まれる。このため、資源ブックは、プレース・オブジェクトを探し出してアクセスするときの手段となる。資源ブック内には、資源ブック内のプレース・オブジェクトに関する１つまたは２つ以上のタブがあり、そこにはプレース・オブジェクトを記述した情報が入っている。そのような情報には、プレース・オブジェクト内に置かれたオブジェクト、およびプレース・オブジェクトをアクセスするときのコストを含めることができる。資源ブックによると、プレース・オブジェクトが見つけやすくなり、そのあとで、ユーザはそのプレース・オブジェクトを持続的参照 (persistent reference)としてローカル・ワークステーションに持ち込むことができる。従って、下述するポストカードのような資源ブック内に表されている選択されたプレース・オブジェクトは、そのプレース・オブジェクトを将来アクセスすることに備えて、資源ブックからドラグしてワークステーションのデスクトップ・ディスプレイ上に置いておくことができる。マップは、プレース・オブジェクトを空間的に表現したものである。マップには、なんらかの方法で結合されたプレース・オブジェクト群が含まれている。従って、ユーザはマップ上をたどっていって、あるエリアに置かれていることが分かっているプレース・オブジェクトを探し出すことができる。マップでは、アニメーションとサウンドが使用されるので、ユーザはあるプレース・オブジェクトから別のプレース・オブジェクトヘ移動するとき、コンテキストと移動感(sense of transition)を得ることができる。マップは空間的表示(spatial view)を使用して、ユーザが指定した種々のプレース・オブジェクトへのアクセスを可能にする。ユーザはマップを使用して、新しいプレース・オブジェクトを作成し、既存のプレース・オブジェクトを操作することができる。マップは対話式(interactive)である。従って、ユーザはマップを使用すると、(i)その参照をマップ上でダブルクリックしてプレース・オブジェクトをオープンすること、(ii)ポストカードのような参照をマップから使用可能なコンテナヘドラグすること、(iii)ファイルを現在のプレース・オブジェクトからマップ上の別のプレース・オブジェクトを指す参照へドラグしてフィアルを移動すること、(iv)１つまたは２つ以上のプレース・オブジェクトを選択し、プロパティ・シート(property sheet)をオープンし、選択したプレース・オブジェクトの新しいプロパティを指定して１つまたは２つ以上のプレース・オブジェクトのプロパティを変更すること、などが行える。マップは、ユーザがあるプレース・オブジェクトから別のプレース・オブジェクトヘ移動するとき、コンテキストと移動感を与えることができる。例えば、ユーザが第１プレース・オブジェクトから出て第２プレース・オブジェクトへ移るとき、マップは、アニメーション、例えば、２オブジェクト間のラインをイラストで示してプレース間の移動を表示する。このようなアニメーション・シーケンスには、２つのプレース・オブジェクトのロケーション・コンテキストが示される。第１に、シーケンスは移動感に関係するものである。第２に、シーケンスは、あるプレース・オブジェクトから別のプレース・オブジェクトヘ移るときにいつでもマップが使用できることをユーザに知らせるものである。ポストカードは、プレース・オブジェクトを指す参照である。ポストカードは、そこへ戻ることが望ましいプレース・オブジェクトをアクセスしたときに、ユーザにより作られる。アクセスしたプレース・オブジェクトのポストカードを作成しておくと、そのプレース・オブジェクトへの将来のアクセスが容易になる。この種のポストカードを他のユーザへ転送すると、プレース・オブジェクトが存在することをユーザに警告したり、アクセス情報を得たりすることもできる。インビテーション（招待状）もプレース・オブジェクトを指す参照であるが、これによると、特定のユーザが特定の時刻にプレース・オブジェクトをアクセスすることができる。このアクションにより、プレース・オブジェクトの作成者は選択したユーザを指名して、一定の期間に限って、また特定の制約条件の下でプレース・オブジェクトをアクセスさせることができる。ある種のプレース・オブジェクトはアクセス料金を請求する場合があるので、インビテーションを使用すると、ユーザはプレース・オブジェクトへのトライアル・アクセスを受けることができる場合がある。また、インビテーションは、ユーザが特定の日付と時刻にプレース・オブジェクトをアクセスできることを指定できるので、単純なアクセス制御メカニズムとして働くことになる。さらに、インビテーションは、他のユーザに協同作業に参加することを勧誘するためにも使用できる。事前に予告しないである人を協同作業に組み入れることは適切でないので、インビテーションを転送すれば、協同作業に参加するかどうかの機会をユーザに与えることができる。第５図に示すように、インビテーションが示されている。タイトルバー502 が示すように”invitation from Rob Dickinson”（Rob Dickinsonからの招待状）と名付けたインビテーション500は、見出し504 に示すように”CPSR Annual MEE TING”に関する情報を収めている。このインビテーションを転送する人、ミーティングの時刻、ミーティングの場所、および指名したゲストに関する情報も、それぞれ参照符号506,508,510,512 で示すように、このインビテーションに示されている。必要とするプレース・オブジェクトが見つかったとき、ユーザはサブプレースであるプレース・オブジェクト間をナビゲートしなければならない。プレース・オブジェクトの設計者が選択するナビゲーション方法は、プレース・オブジェクトの重要な特性である。プレース・オブジェクトは階層になっているので、ユーザは、プレース・オブジェクトが深いネスト構造(deep nested structure)にあるのか、浅い構造(shallowstructure)にあるのかを知っている必要がある。深いネストは、ユーザが連続するサブプレース・オブジェクトをオープンしていくか、あるいは参照を使用して深いネストのプレース・オブジェクトまで到達しなければならないことを意味する場合がある。これに対して、多数のエレメントからなる浅い構造は空間的により多くのスペースを占めるので、潜在的には、ユーザにより多くの選択項目をよりハイレベルで与えることができる。従って、作成者が選択するナビゲーション方法は、到達しようとするプレース・オブジェクトの構造によって決まる。好ましくは、スケーリング方法(scaling method)とパンニング方法(panning m ethod)を併用すると、デスクトップ・ディスプレイ内でナビゲートすることができる。あるプレース・オブジェクトを均一にスケーリングするには、アスペクト比（aspect ratio：横縦比）を一定に保ちながら、プレース・オブジェクトの寸法を拡大または縮小する。スケーリングは、ズームしてドキュメントやプレース・オブジェクト・ビューに入ったり、そこから出たりするユーザにとっても重要である。プレース・オブジェクトが正しくスケーリングされたあと、パンニングを使用すると、プレース・オブジェクト内をナビゲートすることができる。パンニングを行うときは、プレース・オブジェクトの特定部分を表示するように、グラフィック・カーソル(graphic cursor)を動かしながら手操作でデスクトップに指示する。パンニング・グラフィックをドラグすることにより、ユーザはデスクトップの他の領域をビューに移動する。別の方法として、好適実施例では、スクローリングや自動パンニング(auto-pa nning)またはディストーティング(distorting)方法を使用して、プレース・オブジェクト内をナビゲートしている。自動パンニングはホットゾーン(hot-zone)（通常は、デスクトップのエッジを取り巻くエリアであるが）に入り込むカーソルの動きを検出して、ディスプレイを動きの方向にパンする。システムには、照会 (query)により、あるプレース・オブジェクトを見つけたり、プレース・オブジェクトのある内容を見つけるためのメカニズムも、ユーザのために用意されている。アクセス制限プレース・オブジェクト内のセキュリティとアクセス制御を実現するには、いくつかの方法がある。第一は、一組のアクセス権をプレース・オブジェクトと関連づける方法である。この方法によると、その組のアクセス権の範囲にあるユーザは、だれもプレース・オブジェクトをアクセスすることが許される。第二は、あるプレース・オブジェクトへの最低限のアクセス権を指定した人に与える方法である。しかし、増加したアクセス権がプレース・オブジェクト内に包含されたオブジェクトと関連づけられることになる。第三は、プレース・オブジェクトを必要とする個人とグループを指定して、アクセス権を割り当てる方法であるが、これらの権利はプレース・オブジェクトとそこに包含されるオブジェクト全体に適用されることになる。これらのルールによると、個別のファイル管理を必要としないで、プレース・オブジェクト内に異なる共有レベルをもたせることができる。アクセスを制限する別の方法として、プレース・オブジェクトをアクセスするユーザに費用を負担させることが可能である。従って、プレース・オブジェクトはサービスを提供する手段として利用することができる。そのようなサービスには、ダウジョーンズ(Dow Jonesのような情報サービス、ウォールストリート・ジャーナル(Wall Street Journal)のようなニュース・サービス、購買サービスおよびAmerica On-Lineのような収集プレース・オブジェクトを含めることが可能である。プレース・オブジェクトは、サービスを提供し、サービスへのアクセスを制限するように構築することができる。ユーザがあるプレース・オブジェクトに入ったときの費用を計算するモデルがいくつか用意されている。具体的には、費用は、 (i) プレース・オブジェクトへのアクセス (ii)プレース・オブジェクトのアクセス時間 (iii) あるプレース・オブジェクト内でアクセスされたオブジェクトの数 (iv)一定額の費用または申込み金 (v) あらかじめ決めた使用制限 (vi)これらの任意の組合せの任意の１つまたは組合せに基づいて計算することができる。好ましくは、発生した費用と潜在的費用の通知は、あるプレース・オブジェクトにアクセスするとユーザに表示される。さらに、オペレーションが高価になるおそれがあることは、ユーザに事前に警告される。さらに、ユーザは、あるプレース・オブジェクトの最大費用を指定することができる。最大費用に達すると、ユーザに通知されるので、ユーザはそのプレース・オブジェクトから出るか、それとも将来発生する追加費用を負担するかを選択することができる。プレース・オブジェクトのビジュアル表現プレース・オブジェクトのビジュアル表現は、ロケーション感(sense of loca tion)を作る上で重要である。従って、プレース・オブジェクトは、背景イメージ、レイアウト、スケール、デザイン・スタイル、空間ボリューム(spatial vol ume)、照明効果および文字体裁(typography)といった、いくつかのエレメントに関して設計することができる。好適実施例では、これらのエレメントを組み合わせて、識別性(distinctive)があり、ナビゲーションを容易にする環境を作成している。プレース・オブジェクトに適用される背景イメージは、リードオンリ・モデル (read-only model)を通して作成することができる。これには、移動するイメージや、現在時刻を基準にしてそのプレゼンテーションを変更する夜間／昼間プレース・オブジェクトのように、データ駆動(data-driven)のイメージが含まれる。さらに、プレース・オブジェクトの背景イメージをぼかすと、背景イメージと、ディスプレイの最前部のウィンドウやオブジェクト・アイコンなどのアイテム（項目）との間の奥行き(depth stratification)を追加することができる。また、彩度(saturation)を利用すると、前景アイテムと背景イメージの間に独特のスタイルを作ることもできる。プレース・オブジェクトの密度とレイアウトは、プレース・オブジェクトが満足のいくように反映されるように適応される。プレース・オブジェクトがリードオンリ・アクセスだけを許しているのでなければ、ユーザがプレース・オブジェクトに加えたレイアウト変更はセーブ（格納）され、リターン時にリストア（復元）される。背景イメージと、プレース・オブジェクトの寸法スケールおよび寸法比との関係により、ユーザのスコープ感(sense of scope)が設定される。従って、小さい、遠のいて行くプレース・オブジェクトは距離を示し、大きいプレース・オブジェクトはプレース・オブジェクトの広がりを表している。プレース・オブジェクトの空間ボリュームは、プレース・オブジェクトの表現に不可欠である。プレース・オブジェクト内のオブジェクトの選択、配置およびレンダリング(rendering)はユーザが使用できるオプションの範囲を示している。プレース・オブジェクトには、ユーザに理解しやすいものと、オープンと読取りによって詳細分析を必要とするものがある。それにもかかわらず、プレース・オブジェクトは、プレース・オブジェクトに収められたエレメントを調べると、容易に区別することができる。さらに、空間の奥行きと対話によるナビゲーション方法はプレース・オブジェクトの特性になっている。空間仮想現実(spatial v irtual realities)を実現すると、三次元入力デバイスの使用とナビゲーションが可能になる。照明と文字体裁のエレメントは、各プレース・オブジェクトに独特の特性をもたせる上で役に立つ。プレース・オブジェクトは、プレース・オブジェクトの特定の側面に焦点を当てて設計することができる。大きなサイズで使用される表示タイプフェースのような、文字体裁を利用すると、プレース・オブジェクトに独特の特徴をもたせることが可能である。プレース・オブジェクト以外のオブジェクトプレース・オブジェクトとワークスペースに置かれる他のタイプのオブジェクトの中では、プレース・オブジェクトが最高レベル・オブジェクトである。従って、フォルダのようなコンテナ・オブジェクトを含んでいる典型的なオブジェクトが現れるのは、プレース・オブジェクトのコンテキスト内である。さらに、フォルダのようなコンテナ・オブジェクトはプレース・オブジェクトを収容することができない。コンテナ・オブジェクトは、ポストカードのようなプレース・オブジェクトを指す参照だけを収容することができる。プレース・オブジェクトは他のオブジェクトを多数収容することができる。そのようなオブジェクトとしては、ドキュメント、コンテナ、器具、ツール、文房具、および人を指す参照などがある。プレース・オブジェクトは、サブプレース・オブジェクトと呼ばれる他のオブジェクトを収容することも可能である。プレース・オブジェクトは他のプレース・オブジェクトを指す参照を収容することもできる。従って、プレース・オブジェクトの階層は、関連のオブジェクトをさらに再分割できるように維持することができる。好適実施例では、共有プレース・オブジェクトのワークスペース内に挿入できるオブジェクトの作成が可能である。例えば、掲示板(bulletin board)をプレース・オブジェクト内に挿入しておくと、プレース・オブジェクトをアクセスした人は、お互いに情報をやりとりすることができる。さらに、ビジネス・カード(b usiness card：名刺)をプレース・オブジェクト内に挿入しておくと、ある人はビジネス・カードで表された人と連絡することができる。好適実施例では、ユーザは２つの方法で、プレース・オブジェクトをナビゲートしている間に、選択したオブジェクトをアクセスできる。２つの方法とは、ポータブル・コンテナ(portable container)とワークスペース・シェルフ(workspa ce 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)、(ii)コピー、(ii i)参照の移動、(iv)コピー送付、(v)移動である。好ましくは、プレース・オブジェクトと人では、「参照の移動」がドラグされたオブジェクトのデフォルト条件になっている。好ましくは、プレース・オブジェクト内に置かれているオブジェクトの配置は、ワークスペースに関連する各ユーザ別に管理される。従って、あるプレース・オブジェクトの各ユーザには、ユーザによって最後に再配置されたときのプレース・オブジェクトを示すステート(state−状態)がプレース・オブジェクトと関連づけられている。ユーザのステートは、ユーザのローカル・ワークステーション上にセーブされる。別の方法として、あるプレース・オブジェクトを１つだけのステート内に維持しておけば、そのプレース・オブジェクトをアクセスするすべてのユーザには、そのプレース・オブジェクトが同じように表示されることになる。オブジェクトは、アイコンをトラッシュ(trash：ごみ箱)アイコンに移してから、トラッシュを空にするコマンドを選択することで、プレース・オブジェクトのワークスペースから削除することができる。好ましくは、すべてのワークスペース・オブジェクトは、１つのトラッシュ・オブジェクトだけを通して削除することができる。さらに、このようなトラッシュ・オブジェクトは、削除しようとするオブジェクトがトラッシュ・アイコン上にドラッグされると、ターゲット受付け(target acceptance)を表示し、そのあと、ドラグされたオブジェクトがそこに収容されると、ビジュアル・フィードバック(visual feedback)を表示する。さらに、トラッシュ・オブジェクトをオープンすると、そこに入っているエレメントを見ることができる。プレース・オブジェクト内に表される人人オブジェクト(person object)が使用されるのは、あるプレース・オブジェクトからの人が存在するか存在しないかを示すときだけである。例えば、あるユーザがプレース・オブジェクトを作成したとき、そのユーザの人オブジェクトが作成されたプレース・オブジェクト内に作られることが好ましい。このようにすると、そのプレース・オブジェクトをアクセスする他のユーザは、作られた人オブジェクトの存在を通してユーザが存在することを知ることができる。人オブジェクトとは異なり、人を指す参照は、プレース・オブジェクト内に人が存在するか、存在しないかを示さない。むしろ、人を指す参照からは、人に関する情報とその人との通信方法を知ることができる。例えば、プレース・オブジェクトに置かれているビジネス・カードからは、ユーザは、ビジネス・カードの中で参照された人との連絡方法を知ることができる。人を人オブジェクトとして表すほかに、他の側面から見た存在を表すことも可能である。そのような見方として、(i)あるプレース・オブジェクトがユーザのアクティブ・プレース・オブジェクトであるか、主要プレース・オブジェクトであるか、(ii)人の関心レベル、つまり、人の注目がいくつかの他のプレース・オブジェクトに分割されているかどうか、(iii)プレース・オブジェクト内の人の活動レベル(activity level)、および(iv)その人と連絡できるかどうか、といったことがある。好適実施例では、あるプレース・オブジェクトが人のアクティブ・プレース・オブジェクトであるかどうかを関係づけることができる。つまり、あるプレース・オブジェクト内に表された人がそのプレース・オブジェクト内に現在存在するかどうか、である。この判断が必要になるのは、ある人がウィンドウ・プレース・オブジェクトの使用を介して２つ以上のプレース・オブジェクトに同時にいるときだけである。さらに、包含ドキュメントのように、あるプレース・オブジェクト内にあるオブジェクトも、特定の人に表示されるものとして描画することが可能である。ある人の関心レベル、つまり、注目レベルは、ユーザが現在関係づけられているプレース・オブジェクトの数と関係がある。従って、３つのプレース・オブジェクト内に存在するユーザは、いずれか１つに対する注目度が、１つのプレース・オブジェクト内に単独で存在するユーザよりも低くなるはずである。さらに、アクティブ・プレース・オブジェクトの側面から見た場合と同様に、プレース・オブジェクトにいることと包含ドキュメントに関心をもっていることとの関係も関心レベルをレンダリングするときに考慮される。ユーザの活動レベルは、ユーザがプレース・オブジェクト内のいずれかの活動を現在行っているか、活動を最近行ったばかりであるかを示している。従って、非活動度(inactivity)が高いときは、その人がオフィスにいないか、あるいは自分の席にいないかのどちらかである。このような情報は、非活動度の高い人に連絡しようとするときに役に立つ。好適実施例によれば、ある人が手があいているかどうか(availability)の側面も関係づけることが可能である。つまり、情報をやりとりするためにその人と連絡をとることができるかどうかである。好適実施例では、種々形態のグループ通信ができるようになっているが、個人が作業の邪魔をされないようにすることもできる。従って、ユーザは手があいていないステート(state of unavailability )を示しておけば、他のユーザからの連絡を拒否することができる。従って、連絡不能ステートは、プレース・オブジェクト内の人を、邪魔されたくないとの表示を使用して表現することにより関係づけられる。プレース・オブジェクト内に表現された人に関する他のタイプの個別情報はユーザと関係づけられる。そのような情報としては、その人の名前、その人の物理的ロケーション、その人がオンラインであるかどうか、その人が共有している各ドキュメントの特権レベル(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 に移り、そこでユーザは名前リストから名前を選択する。そのあと、機能ブロック 820 で、ユーザ・オブジェクトをインスタンス生成(instantiate)することによりユーザ・セッションが作成される。次に、機能ブロック830 はユーザ・オブジェクトに関連する登録アイテム(registered items)を開始し、機能ブロック840 はプレースButlerと名付けた登録アイテムをインスタンス生成し、機能ブロック 850 はプレースButlerに関連するユーザ・トラベル・バッグをオープンし、機能ブロック860 はユーザ・プレースButlerの開始プレースを判断し、機能ブロック 870 はプレースをオープンし、端子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)である。ラベル1 200は協同作業 (collaboration)の例を示している。ラベル1210はオブジェクトの作成例を示している。ラベル1220は間接的協同作業(indirect collaboration)の例を示している。最後に、ラベル1230は包含(containment)の例を示している。第13図は好適実施例によるBoochダイアグラムである。論理的には、プレースは、アトミック(atomic)に操作できる自己完結環境(sel f-contained environment)である。残念ながら、プレースで実行される内容は論理的に関連づけられているが、下位レベルのサービス別にグループ化されていない。別の言い方をすれば、プレースは、別々のアドレス空間(address space)で実行され、層サーバ(layer server)、ビュー・システム(view system)またはドキュメント・アーキテクチャなどのオペレーティング・システム・フレームワークによって個別的に扱われるアイテムを、論理的にグループ化したものである。論理ユニット(logical unit)として機能するためには、最高レベルのプレース・サービスは、第14図に示すように、別々の環境の概念モデルをユーザに提示するようにプレースのアイテムを管理しなければならない。各ユーザは、その所有者となっているプレースのセットをマシン上にもっている。また、各ユーザは他のプレースに入れるようにするためのアクセス権をもっている場合もある。プレースの所有権階層あるマシン上の各ユーザは、第15図に示すようにドキュメントとワークスペース・アイテムをストアしておくことができる、１つの「ホーム」プレースをもつことになる。個々のマシンの共有が許されるので、システム上に多数のホームプレースが存在することになる。そのため、システムに知らされていない他の人が使用できるゲストまたは公開(public)プレースをもつようにシステムを構成する単純な方法が用意されている。単純なプレース階層が第４図に示されている。第４図は、共有マシンのユーザ間の論理的プレース階層を示したものである。各人は独自の「ホーム」プレースをもち、ユーザ独自の情報を収容し、用途別にいくつかのサブプレースに再分割されている。ユーザは常にプレースにいるユーザは常にプレースに存在する。ユーザがボイド(void −空白)であることはあり得ないので、ユーザがログインするときは、該当するプレースに置かれていなければならない。そのようなプレースとなり得るのは、ホームプレースまたはデフォルト・プレース、ログオフする前に最後にいたプレース、またはユーザが選んだプレースである。第16図はいくつかのダイアログ例を示したもので、そこには、これらの選択項目だけが示されている。ユーザは、ログインしたあとどのプレースへ行くかを指定することができる。ユーザは次の中から１つを選択する。1)絶対：HomeまたはMailプレースなどの特定のプレースへ行く、または2)最近のプレース（つまり、ユーザがログアウトする直前にいた場所）。最近のプレースがリモート・プレースであれば、システムは、ユーザがいまそこへ行きたいのかを尋ねてくる。ユーザには、第16図に示すダイアログ・ボックスと同じようなダイアログ・ボックスが表示される。各ユーザはデフォフト・プレースと呼ばれるプレースをもっている。デフォルト・プレースはプレースを指す参照だけであり、ユーザがログインしたときその参照を使用して操作が開始されるものである。デフォルト・プレースは、ユーザが必要時に戻ることができるプレースでもある。これは、コマンド・キーなどのショートカット(shortcut)によるか、シェルフを通してアクセスすると、もっと簡単に得ることができる。プレースはユーザ固有の情報を保持するプレースは多くの側面からとらえて設計されているので、ユーザによるカストマイズと活動記録(history)を可能にしている。例えば、各ユーザはプレースについて独自の表示をもつことができ、ドキュメントの独自のセーブされたプレゼンテーション(saved presentation)をもつことができる。この情報はどこかにストアしておく必要があるが、これはユーザ固有の情報であるので、peopleサブシステムに用意されているユーザ域にストアされる。ユーザ・セッション・サブシステムはプレース・エレメント(place elements) を始動する。プレースの設計では、ユーザ・セッションの開始時にある種のインタフェース・エレメントをオープンする必要がある。そのようなオブジェクトの例として、シェルフ(shelf)またはトラベル・バッグがある。プレースのフレームワークでは、活動記録(history)サービスといった、ある種のプロセスが稼働状態にあることが必要である。これらのサービスは、ユーザ・セッションが生成されると始動する。プレースはどういう人がそこにいるかを表示できる第17図は、プレースにいる人を表示している人ストリップ(peaple strip)を示している。プレースにいる人のアイコンから、その人のビジネス・カードを自動的にドラグすることができる。TPlaceモデル・クラスは現在そのプレースに接続されているTPerson オブジェクト群を維持している。人がそのプレースに入ると、その人のために人オブジェクトがインスタンス化され、プレース・モデルに追加される。プレースから出ると、プレースは人を指す参照を除去する。以下に示したのは人存在管理(person presence management)に関係するTPlace モデルのメソッドである。これらのやりとりは第18図に示されている。プレースおよびユーザの選好人オブジェクトをプレース・モデルに追加するときのプロセスを示したのが第 19図であり、以下、このプロセスについて説明する。このロジックの極端なケースでは、プレースはバーチャル・マシン(virtual machine)としての意味をもち、そのことは、各プレースには独自の選好(preference)がセットとして関連づけられ、ユーザの選好もすべてがプレースに特有のものであることを意味することになる。このようにすると、ほとんど完全に異なるユーザ環境が得られるという点で（環境が選好を用いてカストマイズできる限りにおいて）、ユーザは高度の柔軟性が得られるが、そうすると、単純性が犠牲になり、選好の上に置くべきインタフェースがさらに複雑化することになる。プレース固有の選好を許すことは、ユーザが選好を指定するとき、ユーザがもつかもしれない意図がいくつかあるために複雑になる。・この選好を、このプレースにいるときだけ使用する。・このタイプの固有の選好をもたない、すべてのプレースについてはこれをデフォルトの選好にする。・これを常に、このタイプの現在の選好にする。この選好はオーバライド値である。デフォルトの選好とプレース固有の選好が指定できる唯一のパラメータであれば、ユーザは混乱し、正しくないデフォルトを指定し、それがどこでも適用されると期待するおそれがある。そのタイプのプレース固有の選好がなくても、プレースに入ることができることになってしまう。プレースとワークスペースとの関係は第20図と第21図に示されている。プレースはワークスペースの最高レベル・エンティティであり、ワークスペースの他のエレメントを使用するときのコンテキストとなるものである。プレースは他のプレースを収容することができ、フォルダやドキュメントなどの、他のワークスペース・エレメントを収容することができる。基本的には、ユーザ情報スペースは、プロジェクト別、タスク別、企業組織別といったように、より意味のある論理的グループに分割されている。プレース内には、以下に説明するように、フォルダとドキュメントの包含階層(containment hierarcy)が存在する。持続的ドキュメント・ステートの維持プレース・プレゼンテーションがサポートしなければならない機能の１つは、ユーザが最後にプレースにいたときに存在していた状態にステートを復元できることである。プレースとプレース上のプレゼンテーションのどちらも、そこで論理的にオープンになっているドキュメントを参照する。・プレース内でオープンしているドキュメント群の記録をとっておく。・ユーザがプレースに入ったときこれらのドキュメントをオープンする。・ユーザがプレースから出たときこれらのドキュメントをクローズする。・上記のいずれの場合も、プレース・プレゼンテーションはプレースでオープンしていた特定のプレゼンテーションをセーブしておき、環境を現実のステートで提示できるようになっていなければならない。例えば、カレンダ・ドキュメントが複数のプレゼンテーションをサポートしていれば、毎月のビューはあるプレースに置かれ、毎日のビューは別のプレースに置かれるはずである。リスト・ビュー(list view) 内のコンテナはあるプレースで専用され、空間ビュー(spati alview) 内のコンテナは別のプレースで専用される。プレースとプレース・プレゼンテーションのどちらも、どのドキュメントがそのプレースでオープンしているかの情報を維持していなければならない。ユーザと一緒にストアされるユーザ固有のプレゼンテーション第22図は、ドキュメント・プレゼンテーション・ステートを維持するためにユーザ情報と一緒にストアされているオブジェクトを示している。大きなモデル・ストアは、プレース上のセーブされたプレゼンテーションとユーザ・ドキュメント上のプレゼンテーションが共にそこに存在することを示している。カタログはドキュメントと、プレースの特定プレゼンテーションとの対応関係（マッピング）を示している。これらが使用されるのは、ユーザがドキュメントをオープンするときであり、これにより、正しいプレゼンテーションが使用されるようになる。ユーザのスペース内では、選好情報と最近の活動記録(history) 情報のための記憶域は、人(people)サブシステムが提供する。プレゼンテーション自体は、それを参照するカタログと一緒にここにストアされる。カタログは、ユーザ選好MP referenceCollection オブジェクトが提供するディクショリナリ・セマンティック(dictionary semantics)を使用する。・各人はプレース上に１つのプレゼンテーションをもち、そこには、最後に表示されたときの、そのプレースをユーザに提示するのに必要な一切の情報が収められている。この情報は、プレース内のオープン・ドキュメントのリストを含んでいる（プレゼンテーション代用物として表現され、可能ならば、データ・モデルIDが一緒に付いて表現されている）。・各人は、複数のプレゼンテーションを１つのドキュメント上にセーブしておくことができる。各人は、それが表示される各プレースごとに異なるプレゼンテーションをもつことができる。ドキュメント・プレゼンテーション情報のカタログはドキュメントを、それらが表示されたプレース用に存在する既存のセーブされたプレゼンテーションと対応づける。このカタログに入っている情報は、キー、プレースID、およびプレゼンテーションのプレゼンテーション代用物として、モデルID(グローバルID)だけを必要とするドキュメントである。プレース・プレゼンテーションには、ドキュメントがいつ初めてオープンされたか、といったドキュメントに関する情報が、次回にプレースに入ったときステートを正しく復元するために必要である。そのためには、ウィンドウ・プレゼンテーションがプレースでいつオープンされたかの通知を受け取る必要がある。これは、次のようなプロジージャを通して行われる。・オープン／クローズ／フォロー・コマンドはすべて、ドキュメントをオープンし、クローズする作業を包含ポリシ・オブジェクト(contained policy object)に委任する形体のモデル・コマンドを使用する。第23図は、好適実施例に従ってプレース・ドキュメント・ポリシを採用するコマンド・サブクラスを示すBooch ダイアグラムである。ラベル2310は好適実施例に従ってドキュメントをオープンするモデル・コマンドを示している。ラベル2320は2310に示したコマンドであって、プレース・ドキュメント・ポリシ・オブジェクトに委任するモデル・コマンドのサブクラスを示している。ラベル2330は、2320で使用されたドキュメント・ポリシをメモリにストアするmixin クラスである。すべてのプレース固有モデル・コマンドはラベル2330のオブジェクトからのサブクラスである。ラベル2340は、その前に置かれたオブジェクトに示されているオペレーションを実行するポリシ・オブジェクトである。・ポリシ・オブジェクトは、このプレースに対して行おうとしているタイプの作用(behavior)を包括している。この作用は協同プレースでは異なり、異なるヒューマン・インタフェースが必要な場合も異なる。・各コンテナまたはドキュメント・プレゼンテーションがその“オープン” コマンドをメニューに登録するときは、これらのオープン委任コマンド(delegat ing open command)を使用し、このコマンドには、ドキュメント登録のためのプレースとの連絡方法に関する情報が入っている。これらのプレゼンテーションは、そのオープン時にポリシ・オブジェクトを自身で受け取っている。これについては、あとで説明する。・オープン・コマンドが実行されると、オープンすべきドキュメントを始動する（これはコマンド自体が実行すべきドキュメントに渡されたとき行われる）。・オープン・コマンドはオープンを、そこに入っているポリシ・オブジェクトに委任する。・ポリシ・オブジェクトは、そのユーザのためにセーブされたプレゼンテーションのカタログを調べて、どのプレゼンテーションを使用すべきかを判断する。・次に、ポリシ・オブジェクトはそのプレゼンテーションをオープンし、そのプレゼンテーションのポリシ・オブジェクトを自身と同じになるようにセットする。このようにして、ポリシ・オブジェクトは、プレース内でオープンされたすべてのプレゼンテーションにプロパゲート(propagate)していく。この方法は、ウィンドウ・プレースがあるときも、複数のプレースが同時にオープンしているときでも有効である。・次に、ポリシ・オブジェクトは、ドキュメントがオープンしたことを、プレース・プレゼンテーションと一緒に登録する。・プレース・プレゼンテーションは、新しいアイテムを追加するようにそのオープン・ドキュメント・リストを更新する。・プレース内のドキュメント上のセーブされたプレゼンテーションをオープンするときのステップは第24図に示されており、プレース内のドキュメント上のプレゼンテーションをクローズするときのステップは第25図に示されている。コンテナ・モデル・アーキテクチャオブジェクトＡがオブジェクトＢを埋め込むとき、ＢのモデルはＡのモデル・ストアにコピーされる。Ｂは埋め込まれたモデル(embedded model)と呼ばれる。ＢはＡと共に埋込み階層(embedment hierarchy)を形成する。Ｂのプレゼンテーションは、Ａのプレゼンテーションの内側にフレーム／サムネイル(frame/thumb nail)として現れる。Ｂのサムネイルは、同じウィンドウとチーム内では同じ場所(in-place)でオープンすることができ、別のウィンドウであるが、同じチーム内では場所の外で(out-of-place)オープンすることができる。オブジェクトＡがオブジェクトＢを収めているときは、ＢのモデルはＡのモデル・ストアにコピーされることはない。Ｂはコンテナブル (containable)と呼ばれる。ＢはＡと共に包含階層(containment hierarchy) を形成する。Ｂは常に、場所の外で（別のウィンドウとチーム内で）オープンされる。第26図は、埋込みと包含の違いを要約して説明したものである。このメッセージでは、比色(color matching)問題に関する要求が行われている。イメージはドキュメントに埋め込まれ、イメージを越えてスクロールしなくてもメッセージ全体を包含するように縮小されている。これは、“HEY I'M A FRAME”境界で区別されている。イメージはデフォルトにより、その場所でオープンされる。フォルダはJim に調べさせるJeffのコードを収めている。これはメッセージに包含されているので、常に場所の外でオープンされる。コンテナの固有特性コンテナは次のような固有特性をもっている。・コンテナはオブジェクトを収容できる。ワークスペース・コンテナ（例：フォルダとプレース）はワークスペース・オブジェクト（例：ドキュメント、フォルダ）だけを収容するのに対し、他の特殊目的コンテナは他のタイプのオブジェクトを収容できる。例えば、データベース・コンテナはデータベース照会の結果を収容することができる。あるオブジェクトをコンテナから削除すると、そのオブジェクトのモデル（メモリ内の構造）とモデル・ストア（ディスク上の構造）がシステムから除去される。・コンテナはオブジェクトとの参照リンクを収容できるので、参照されたオブジェクトがあるコンテナから別のコンテナへコピーされるとき、これらのリンクを修正するときのスコープ（有効範囲）を提供する。ある参照をコンテナから削除すると、その参照だけが除去され、参照されたオブジェクトのモデルとモデル・ストアには影響しない。非コンテナ(non-container)もオブジェクトへの参照を収容できる。つまり、コンテナと参照は密に結合されていない。・コンテナは、ファイル・システム階層から独立した包含階層を作ることができる。言い換えれば、ユーザは、情報がファイル・システムのどこに、どのようにストアされているかに関係なく、コンテナを使用すると、情報を自由にユーザのワークスペースに編成することができる。コンテナは複数のボリュームにまたがることができる。すべてのボリュームが使用可能になっていないと、使用できないオブジェクトは表示されないか、あるいはぼかされて表示される。コンテナ自体、つまり、包含階層のルート(root)はその格納プレース(enclosing place )に残っており、そのプレースと同じ記憶ドメイン（network:machine:volume）に属している。・スマート・コンテナ(smart container)はロケータ(locator)を使用して、その内容をフィルタにかけることができる。コンテナの継承特性には、次のものがある。・コンテナに対するユーザのオペレーション（カット／コピー／ペースト、ドラグ／ドロップ、選択、移動など）は、一定の回数に限り取り消し(undo)、やり直す(redo)ことができる。・コンテナはウィンド／フレーム／サムネイル／アイコン・プレゼンテーションをもつことができる。同じコンテナのプレゼンテーションは複数にすることが可能であり、各プレゼンテーションは他と異なる外観と、場合によっては、感触をもっている(例：フォルダとrolodex)。使い方のシナリオ以下に示したシナリオでは、フォルダとドキュメントを使用して、ユーザとコンテナおよびコンテナブル(containable)とのやりとりを説明している。他のタイプのコンテナとコンテナブルの働き方も、同じである。フォルダを作成する：フォルダ文房具でダブルクリックすると、新しいフォルダがシェルフに作成される。他のタイプのコンテナを作成するための他のタイプの文房具もある。フォルダ作成ロジックを示すVDL ダイアグラムは第27図に示されている。フォルダをあるフォルダから別のフォルダへコピーする：オプション・ドラグ (option-drag)でオプション・キーを押えたまま、フォルダＡをフォルダＸからドラグし、それをドロップしてフォルダＹに入れる。フォルダA′はすべてのオリジナル・ドキュメントのコピーを収容する。これらのオリジナルがリンクされていると、コピーは相互にリンクされるが、オリジナルにはリンクされない。フォルダ・コピー・ロジックを示す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,10 7,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月）と題された論文である。この参考資料のなかで、ディスプレイ上でオープン・ウインドウで表現されている“ルーム”には、人物のリストがあり、ディスプレイ上でアイコンとして描かれている。その他のアイコンは、複写機、ファックス、ごみ箱、およびブリーフ・ケースを表すのに利用されている。アイコンは、オブジェクト、たとえば文書、をアイコン上に置くことで、対話的に働かせることができる。たとえば、ある文書は、ごみ箱アイコンのうえに重ねることで、その廃棄が完了する。しかしながら、個々のルームは、単なるグラフィックな表現にすぎず、ディスプレイ上の単一のウインドウに制限されている。インテリジェントなスタートアップ・コントロールの他の例として、IBM テクニカル・ディスクロージャ・ブレティン 35巻、No.4B，160-161頁の”インテリジェント・スタートアップ・コントロール”（1992年９月発行）がある。そこでは、最初にシステムを立ち上げたとき、どのアプリケーションをスタートさせるか、又これらのアプリケーションをスタートさせる順序を、ユーザが指定することができるグラフィックで直接的な操作についての技術を議論している。この種のシステムでは、すべてのシステムがスタートアップ時のデフォルトを持って出荷されている。このデフォルトは、“スタートアップ”アイコンとして提供され、ユーザは各自のニーズに最もよく適合するようにアプリケーション・スタートアップ・デフォルトを修正するために開く。スタートアップ・ウインドウは、スタートしつつあるアプリケーションとスタートの順序をグラフィック表示で見せる。ユーザは、“スタートアップ”ウインドウの中の別の場所にアイコンをドラッグすることで、アプリケーションのスタート順序を変更できる。スタートアップ・ウインドウにおいて行われた順序の変更により、co nfig.sysおよびスタートアップ・コマンド・ファイルは自動的に更新される。発明の概要コンピュータ・システムのユーザ、特に未経験のユーザは、実世界の特性を備えた環境を作り出すアプリケーションの恩益を受けている。特に、アプリケーションに未経験のユーザは使い慣れた参照フレーム(frame of reference)を利用すると、アプリケーションの概念を容易に把握できるであろう。好適実施例では、他のオブジェクトをそこに収めておくことができるプレース・オブジェクト(pla ce object)のセットをユーザが作成できるようにすることによって、このような環境を提供している。請求の範囲１．メモリ（14,16）、メモリに結合された処理手段(10)、処理手段に結合された入力手段(24,26,32)、および処理手段に結合されたディスプレイ・デバイス(3 8)を有するコンピュータ・システムにおける方法において、 (a)コンピュータ・システムの各ユーザのために人クラスを含むプロフィール情報をメモリにストアするステップ(第18図、506)と、 (b)複数のユーザの選択可能なプレース・クラスをメモリにストアするステップであって、複数のプレース・クラスのそれぞれは、別個の予め定められた物理的位置、ワークスペース・グラッフィク・データ、およびユーザ・プロフィール情報をストアするデータ構造を表す表示を生成するビユー・データを有し(402,4 04,406，408,410 )、 (c)処理手段により生成され、ディスプレイ・デバイス上に表示されたユーザ・ログイン・リクエスト・グラッフィクに応答して、入力手段からユーザに関連したユーザ・アイデンティファイア(user identifier)を受け取るステップ(710 〜715)と、 (d)ユーザ・アイデンティファイアを有するユーザのために人クラスから人オブジェクトをインスタンス形成するステップ(820〜850)と、 (e)人オブジェクトのユーザ・プロフィール情報に基づいて複数の予め定義されたプレース・クラスの１つを選択し、かつ、選択されたプレース・クラスからプレース・オブジェクトをインスタンス形成するステップ(860〜870)と、 (f)インスタンス形成されたプレース・オブジェクトのデータ構造中にユーザに特有のプロフィール情報をストアするステップ(1020)と、 (g)予め定められた物理的位置のビユーを生成するプレース・オブジェクト・ビユー・データをディスプレイ・デバイスに表示するステップ(38,402〜410)と、 (h)ディスプレイ・デバイス上の予め定められた物理的位置に関連したワークスペース・グラッフィクを表示するステップ(402〜410)と、 (i)人オブジェクトにより識別された第１のワークスペース・オブジェクトを表すグラッフィクをワークスペースに表示するステップ(500)とを備えることを特徴とする方法。２．請求の範囲第１項に記載の方法において、第１のワークスペース・オブジェクトを表示するステップが、ドキュメント、ツールおよびコンテナのうち少なくとも１つのビジュアル表示をディスプレイ・デバイス上に表示するステップ（第６図）を備えることを特徴とする方法。３．請求の範囲第２項に記載の方法において、サブプレース・オブジェクトにより供給さられるサブプレース・ビユー(408，410)をディスプレイ・デバイス上に表示するステップを含み、サブプレース・ビユーは、プレース・オブジェクト(4 04)によって生成される物理的位置のビユー内にディスプレイ・デバイス上に表示されることを特徴とする方法。４．請求の範囲第３項に記載の方法において、ユーザ・プロフィール情報がユーザの選好を備え、(i)ステップは、ユーザ選好をワークスペース・オブジェクトに適用するステップ(510,512)を備えることを特徴とする方法。５．請求の範囲第１項に記載の方法において、 (a)プレース・オブジェクトにより生成される物理的位置のビユーに表示されるインビテーションの表示をディスプレイ・デバイス上に表示するステップ(500 )と、 (b)複数のインビテーション・レスポンスをディスプレイ・デバイス上に表示するステップ(508,510,512)と、 (c)第２のユーザに、複数のインビテーション・レスポンスの１つを選択するようプロンプトするステップ(508,510,512)と、 (d)第２のユーザが複数のインビテーション・レスポンスの１つを選択したことに応答して、インスタンス形成されたプレース・オブジェクトのデータ構造中に第２のユーザのためにユーザ・プロフィール情報をストアするステップ(1020) とを含むことを特徴とする方法。６．請求の範囲第１項に記載の方法において、 (a)ポストカードをディスプレイ・デバイス上に表示するステップ(500)と、 (b)複数のポストカード・レスポンスをディスプレイ・デバイス上に表示するステップ(508,510,512)と、 (c)第２のユーザに、複数のポストカード・レスポンスの１つを選択するようにプロンプトするステップ(508,510,512)と、 (d)第２のユーザが複数のポストカード・レスポンスの１つを選択したことに応答して、インスタンス形成されたプレース・オブジェクトのデータ構造中に第２のユーザのためにユーザ・プロフィール情報をストアするステップ(1020)とを含むことを特徴とする方法。７．請求の範囲第１項に記載の方法において、ステップ(a)は、ビユー・データを保持するデータ構造を定義する情報を人オブジェクトの各々にストアするステップを含み、さらに前記方法は、人オブジェクトにストアされたビユー・データをディスプレイ・デバイスに表示するステップを含み、ビユー・データは、プレース・オブジェクトにユーザが存在することを示すために、人オブジェクトにより表されているユーザの表示をディスプレイ・デバイス上に提供する（第５図）ことを特徴とする方法。８．メモリ(14,16)、メモリに結合された処理手段(10)、処理手段に結合された入力手段(24,26,32)、および処理手段に結合されたディスプレイ・デバイス(38) を有する情報を編成するシステムにおいて、 (a)コンピュータ・システムの各ユーザのために人クラスを含むプロフィール情報をメモリにストアする手段(第18図、506)と、 (b)複数のユーザの選択可能なプレース・クラスをメモリにストアする手段であって、複数のプレース・クラスは、別個の予め定められた物理的位置、ワークスペース・グラッフィク・データ、およびユーザ・プロフィール情報をストアするデータ構造を表す表示を生成するビユー・データを有し(402,404,406,408,410 )、 (c)処理手段により生成され、ディスプレイ・デバイス上に表示されるユーザ・ログイン・リクエスト・グラッフィクに応答して、入力手段からユーザに関連したューザ・アイデンティフアイア(user identifier)[ユーザを識別するログイン・コマンド]を受け取る手段(710〜715)と、 (d)ユーザ・アイデンティファイアに応答して、ユーザのために人クラスから人オブジェクトをインスタンス形成する手段(820〜850)と、 (e)人オブジェクト中のユーザ・プロフィール情報に応答して、複数のプレース・クラスの１つを選択し、選択したプレース・クラスからプレース・オブジェクトをインスタンス形成する手段(860〜870)と、 (f)プレース・オブジェクトのインスタンス形成に応答して、インスタンス形成されたプレース・オブジェクトのデータ構造中にユーザに特有のプロフィール情報をストアする手段(1020)と、 (g)プレース・オブジェクトのインスタンス形成に応答して、予め定められた物理的位置のビユーを生成するプレース・オブジェクトのビユー・データをディスプレイ・デバイスに表示するために手段(38,402〜410)と、 (h)プレース・オブジェクトのインスタンス形成に応答して、ディスプレイ・デバイス上の予め定められた物理的位置に関連したワークスペース・グラッフィクを表示する手段(402〜41 0)と、 (i)人オブジェクト中の情報に応答して、人オブジェクトにより識別された第１のワークスペース・オブジェクトを表すグラッフィクをワークスペースに表示する手段(500)とを備えることを特徴とするシステム。９．請求の範囲第８項に記載のシステムにおいて、第１のワークスペース・オブジェクトを表示する手段が、ドキュメント、ツール、コンテナのうち少なくとも１つのビジュアル表示をディスプレイ・デバイス上に表示する手段（第６図）を備えることを特徴とするシステム。 10．請求の範囲第８項に記載のシステムにおいて、サブプレース・オブジェクトにより供給されるサブプレース・ビユー(408，410)をディスプレイ・デバイス上に表示する手段を含み、サブプレース・オブジェクトは、プレース・オブジェクト(404)により生成される物理的位置のビユー内にディスプレイ・デバイス上に表示されることを特徴とするシステム。 11．請求の範囲第８項に記載のシステムにおいて、ユーザ・プロフィール情報がユーザ選好を備え、ワークスペース・オブジェクト表示手段はユーザ選択をワークスペース・オブジェクトに適用するステップ(510,512)を備えることを特徴とするシステム。 12．請求の範囲第８項に記載のシステムにおいて、 (a)インビテーションと複数のインビテーション・レスポンスを表示する手段( 500)と、 (b)ユーザに複数のインビテーション・レスポンスから１つを選択するようにプロンプトする手段(508,510,512)と、 (c)複数のインビテーション・レスポンスの１つを選択する第２のユーザに応答して、インスタンス形成されたプレース・オブジェクトのデータ構造中に第２のユーザのためにユーザ・プロフィール情報をストアする手段(1020)とを含むことを特徴とするシステム。 13．請求の範囲第８項に記載のシステムにおいて、 (a)ポストカードと複数のポストカード・レスポンスを表示する手段(500)と、 (b)複数のポストカード・レスポンスから１つのポストカード・レスポンスをユーザに選択するようにプロンプトする手段(508,510,512)と、 (c)複数のポストカード・レスポンスを選択する第２のユーザに応答して、インスタンス形成されたプレース・オブジェクトのデータ構造中に第２のユーザのためにユーザ・プロフィール情報をストアする手段(1020)と、を含むことを特徴とするシステム。 14．請求の範囲第８項に記載のシステムにおいて、各ユーザ・クラスがビユー・データを保持するためのデータ構造を含み、さらに前記システムは、人オブジェクトにストアされたビユー・データをディスプレイ・デバイス上に表示する手段を含み、人オブジェクトは、プレース・オブジェクトにユーザが存在することを示すために、ビユー・データが人オブジェクトにより表されているユーザの表示をディスプレイ・デバイス上に提供する（第５図）ことを特徴とするシステム。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ

Claims

【特許請求の範囲】１．メモリ、メモリに接続された処理手段、処理手段に接続された入力手段、および処理手段に接続されたディスプレイ・デバイスを備えたコンピュータ・システムにおいて、ユーザとやりとり（対話または相互に作用し合うこと）する方法であって、 (a)ユーザを指定したログイン・コマンドを入力手段から受け取るステップと、 (b)ログイン・コマンドに応答して、デフォルト・プレース・オブジェクトをディスプレイ・デバイスから表示するステップであって、該デフォルト・プレース・オブジェクトは、メモリにストアされ、ユーザと関連づけられたプロフィール情報に基づいており、さらに該デフォルト・プレース情報はディスプレイ・デバイス上にワークスペースを定義しているものと、 (c)デフォルト・プレース・オブジェクトによって定義されたワークスペースに、少なくとも１つのワークスペース・オブジェクトを表示するステップとを含んでいることを特徴とする方法。２．請求の範囲第１項に記載の方法において、少なくとも１つのワークスペース・オブジェクトを表示するステップは、ドキュメント、ツールおよびコンテナのうち少なくとも１つを表示するステップからなることを特徴とする方法。３．請求の範囲第１項に記載の方法において、少なくとも１つのワークスペース・オブジェクトを表示するステップは、デフォルト・プレース・オブジェクト内にサブプレース・オブジェクトを表示するステップからなることを特徴とする方法。４．請求の範囲第１項に記載の方法において、デフォルト・プレース・オブジェクトはユーザと関連づけられたホームプレース・オブジェクトであることを特徴とする方法。５．請求の範囲第１項に記載の方法において、 (a)ワークスペース・オブジェクトを一時的にストアしておくワークスペース・シェルフをワークスペース内に表示するステップと、 (b)入力デバイスからの信号に応答して、シェルフ上にストアされたオブジェクトを表示するためにシェルフをオープンするステップとを含むことを特徴とする方法。６．請求の範囲第１項に記載の方法において、 (a)インビテーションを表示するステップと、 (b)インビテーションへの応答を選択するようにユーザにプロンプトするステップと、 (c)応答をインビテーションへの返答にフォーマッティングするステップとを含むことを特徴とする方法。７．請求の範囲第１項に記載の方法において、 (a)ポストカードを表示するステップと、 (b)ポストカードへの応答を選択するようにユーザにプロンプトするステップと、 (c)応答をポストカードへの返答にフォーマッティングするステップとを含むことを特徴とする方法。８．請求の範囲第１項に記載の方法において、ユーザを表すために人オブジェクトをワークスペース内に表示するステップを含むことを特徴とする方法。９．メモリ、メモリに接続された処理手段、処理手段に接続された入力手段、および処理手段に接続されたディスプレイ・デバイスを備えたコンピュータにおいて、ユーザに関する情報を編成するシステムであって、 (a)ユーザを指定したログイン・コマンドを入力手段から受け取る手段と、 (b)ログイン・コマンドに応答して、デフォルト・プレース・オブジェクトをディスプレイ・デバイスから表示する手段であって、該デフォルト・プレース・オブジェクトは、メモリにストアされ、ユーザと関連づけられたプロフィール情報に基づいており、さらに該デフォルト・プレース情報はディスプレイ・デバイス上にワークスペースを定義しているものと、 (c)デフォルト・プレース・オブジェクトによって定義されたワークスペースに、少なくとも１つのワークスペース・オブジェクトを表示する手段とを含んでいることを特徴とするシステム。 10．請求の範囲第９項に記載のシステムにおいて、少なくとも１つのワークスペース・オブジェクトを表示する手段は、ドキュメント、ツールおよびコンテナのうち少なくとも１つを表示する手段からなることを特徴とするシステム。 11．請求の範囲第９項に記載のシステムにおいて、デフォルト・プレース・オブジェクト内にサブプレース・オブジェクトを表示する手段を含むことを特徴とするシステム。 12．請求の範囲第９項に記載のシステムにおいて、デフォルト・プレース・オブジェクトはユーザと関連づけられたホームプレース・オブジェクトであることを特徴とするシステム。 13．請求の範囲第９項に記載のシステムにおいて、 (a)ワークスペース・オブジェクトを一時的にストアしておくワークスペース・シェルフをワークスペース内に表示する手段と、 (b)入力デバイスからの信号に応答して、シェルフ上にストアされたオブジェクトを表示するためにシェルフをオープンする手段とを含むことを特徴とするシステム。 14．請求の範囲第９項に記載のシステムにおいて、 (a)インビテーションを表示する手段と、 (b)インビテーションへの応答を選択するようにユーザにプロンプトする手段と、 (c)応答をインビテーションへの返答にフォーマッティング（形式化）する手段とを含むことを特徴とするシステム。 15．請求の範囲第９項に記載のシステムにおいて、 (a)ポストカードを表示する手段と、 (b)ポストカードへの応答を選択するようにユーザにプロンプトする手段と、 (c)応答をポストカードへの返答にフォーマッティングする手段とを含むことを特徴とするシステム。 16．請求の範囲第９項に記載のシステムにおいて、ユーザを表すために人オブジェクトをワークスペース内に表示する手段を含むことを特徴とするシステム。