JPH08511118A - コンテナ・オブジェクト・システム - Google Patents

Abstract

(57)【要約】 コンテナ内に情報を編成する方法と装置が開示されている。オブジェクトは、フォルダ、プレース、マップ、人、引出し、シェルフ、およびトラッシュを参照する他のオブジェクトを収容するために作成される。作成されたコンテナは、あとで複数のユーザがアクセスすることができる。コンテナは、カット、コピー、ペースト、ドラグ、ドロップ、選択、移動、およびすでに実行されたオペレーションをバックアウトする能力を含む、デフォルトのユーザ・オペレーションを用意している。コンテナは、ウィンドウ、フレーム、サムネイルまたはアイコン・プレゼンテーションをディスプレイ上にもつこともできる。また、コンテナは同じコンテナの複数のプレゼンテーションをサポートする。例えば、同じコンテナ・オブジェクトについてフォルダとrolodexを表示することができる。

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）のセットをユーザが作成できるよう にすることによって、このような環境を提供している。ここで言う他のオブジェ クトとしては、人、物やアイテム（項目）、および他のプレースを機能別に表現 したものがある。 好適実施例では、コンピュータ・システムにおける情報を、コンピュータのメ モリに置かれた複数のコンテナ（container）内に編成している。この編成は、 メモリ内のコンテナをインスタント生成（instantiate）し、そのコンテナをフ ォルダ、バスケット（basket）やプレースなどのオブジェクトのクラスに合わせ て作り替えることから開始される。コンテナは、カット、コピー、ペースト、ド ラグ、ドロップ、選択、移動、およびすでに実行済みのオペレーション（操作） から戻る能力を含む、デフォルト・ユーザ・オペレーションを継承している。ま た、コンテナは、ウィンドウ、フレーム、サムネイル（thumbnail）またはアイ コン表現をディスプレイ上に表示し、同じコンテナの複数表現をサポートするこ とも可能である。例え ば、同じコンテナ・オブジェクトについて、フォルダとロロデックス（rolodex ）を表示することが可能である。 図面の簡単な説明 本発明の上記および他の目的、側面および利点を理解しやすくするために、添 付図面を参照して本発明の好適実施例について、以下で詳しく説明する。添付図 面において、 第１図は、本発明の好適実施例によるコンピュータ・システムを示すブロック 図である。 第２図は、本発明の好適実施例によるウィンドウ内のプレース・オブジェクト とデスクトップのプレース・オブジェクトを示す図である。 第３図は、本発明の好適実施例によるウィンドウ内のプレース・オブジェクト の拡大を示す図である。 第４図は、本発明の好適実施例によるワークステーション内のユーザプレース ・オブジェクトの典型的な階層を示す図である。 第５図は、本発明の好適実施例によるインビテーション（招待状）を示す図で ある。 第６図は、本発明の好適実施例によるトラベル・バッグを示す図である。 第７図は、本発明の好適実施例によるハイレベルの 制御の流れを示すフローチャートである。 第８図は、本発明の好適実施例による詳細ロジックを示すフローチャートであ る。 第９図は、本発明の好適実施例による詳細ロジックを示すフローチャートであ る。 第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 of fice place）は、通信資源に関係するオ ブジェクトの集まりを収容するように作られる。プレース・オブジェクトは、あ るプレースに係わりをもつ人に関するオブジェクトを収容するように作ることも できる。別の例として、ライブラリ（図書館）プレースは大量の図書とライブラ リアン（司書）を表すオブジェクトが置かれるプレースとして作られる。この場 合、利用者はライブラリ・プレースをアクセスし、大量の図書の中から必要とす る図書を探し出すために分類を行ってから、その図書を検索することが可能にな る。他の方法として、利用者は、ライブラリアンを表すオブジェクト内に収めら れている情報によってライブラリアンに連絡し、ライブラリアンに文献検索を行 わせることも可能である。 コンピュータ・システム 好適実施例は、好ましくは、IBM（登録商標）社PS/2（登録商標）またはアッ プル（登録商標）社マッキントッシュ（登録商標）コンピュータなどのパーソナ ル・コンピュータ上に置かれているオペレーティング・システムの環境（コンテ キスト）で実施される。代表的なハードウェア環境は第１図に示されているが、 同図は、従来のマイクロプロセッサのような中央演算処理ユニット10、およびシ ステム・バス12を介して相互に接続された複数の他のユニットを装備した、本発 明の好適実施例によるワークステーションの代表的ハードウェア構成を示してい る。第１図に示すワークステーションは、ランダム・アクセス・メモリ（RAM）1 4、リードオンリ・メモリ（ROM）16、ディスク・ユニット20などの周辺デバイス をバスに接続するための入出力アダプタ18、キーボード24、マウス26、スピーカ 28、マイクロホン32、および／またはタッチ・スクリーン・デバイス（図示せず ）などのユーザ・インタフェース・デバイスをバスに接続するためのユーザ・イ ンタフェース・アダプタ22、ワークステーションをデータ処理ネットワークに接 続するための通信アダプタ34、およびバスをディスプレイ・デバ イス38に接続するための表示アダプタ36を装備している。ワークステーションに は、アップル社System/7（登録商標）オペレーティング・システムなどのオペレ ーティング・システムが置かれている。ドキュメント・フレームワーク・アーキ テクチャ（document framework architecture）はRAM14に置かれており、CPU10 の制御の下で、本発明の好適実施例を実現することを受け持っている。 好適実施例では、本発明は、オブジェクト指向プログラミング技法を使用して C++プログラミング言語で書かれている。この分野に精通しているものならば容 易に理解されるように、オブジェクト指向プログラミング（0bject-Oriented Pr ogramming - OOP）のオブジェクトは、データ構造とデータに対するオペレーシ ョン（操作、演算など）からなるソフトウェア・エンティティ（software entit y）である。これらのエレメントが協力し合うことにより、オブジェクトは、そ のデータ・エレメントで表されたその特性、およびそのデータ操作関数（data m anupulation functions）で表されたその作用（behavior）からとらえて、ほと んどどのような実世界のエンティティでもモデル化することができる。この方法 によると、オブジェクトは、人やコンピュータなどの具体物をモデル化すること ができ、また、数や幾何学的概念などの抽象概念をモデル化することができる。 オブジェクト・テクノロジ の利点は次の３つの基本的原理から得られるものである。それは、カプセル化（ encapsulation）、多態（polymorphism）および継承（inheritance）である。 オブジェクトは、そのデータの内部構造とその関数が実行されるときのアルゴ リズムを隠蔽する。つまりカプセル化する。これらのインプリメンテーション細 部を見せる代わりに、オブジェクトは、外部情報（extraneous information）の ないクリーンな形でその抽象化（abstractions）を表しているインタフェースを 提示する。多態はカプセル化をさらに一歩進めたものである。この考え方は、多 数の形体をもつ、１つのインタフェースである。あるソフトウェア・コンポーネ ントは、別のコンポーネントがなんであるかを正確に知らなくても、その別のコ ンポーネントを要求することができる。要求を受け取ったコンポーネントはその 要求を解釈し、その要求をどのように実行すべきかを、その変数とデータに従っ て判断する。三番目の原理である継承によれば、開発者は既存の設計やコードを 再利用することができる。この機能を利用すると、開発者はソフトウェアを初め から作ることが回避される。むしろ、継承を通して、開発者は作用を継承するサ ブクラスを派生し、その作用を開発者独自の要求に合ったものにカストマイズす ることができる。 従来のアプローチでは、オブジェクトとクラス・ライブラリを手続き的環境で 階層化する方法がとられて いた。市販されている多くのアプリケーション・フレームワークはこの設計手法 を採用している。この設計では、モノリシック・オペレーティング・システム（ monolithic operating system）の上に１つまたは２つ以上のオブジェクト層が 置かれている。このアプローチでは、カプセル化、多態および継承のすべての原 理がオブジェクト層に採用され、手続き的プログラミング技法を大幅に改善して いるが、このアプローチにはいくつかの制約がある。これらの問題は、開発者が 自身のオブジェクトを再利用することは容易であるが、他のシステムからのオブ ジェクトを使用することが困難であるため、手続き的オペレーティング・システ ム（OS）のコールを使用して、下位の非オブジェクト層まで到達する必要がある ことに起因している。 オブジェクト指向プログラミングがもつもう１つの側面は、アプリケーション を開発するのにフレームワーク・アプローチを採用していることである。フレー ムワークの最も合理的な定義の１つとして、イリノイ大学のRalph E.JohnsonとP urdueのVincent F.Russoによるものがある。両氏の1991年の論文「オブジェクト 指向設計の再利用」（Reusing Object-Oriented Designs）、イリノイ大学技術 報告書UIUCDCS91-1696の中で、次のような定義を提案している。「抽象クラスと は、一組の責任分担を協力し合って実行するオブジェクトの集合を設計したもの であ る。従って、フレームワークとは、組で定義された演算責任分担を協力し合って 実行するオブジェクト・クラスが集まったものである。」プログラミング側から 見たときは、フレームワークとは、基本的には、実働アプリケーション（workin g application）の事前に作られた構造を提供する、相互に接続されたオブジェ クト・クラスの集まりである。例えば、ユーザ・インタフェース・フレームワー クは、描画ウィンドウ（drawing window）、スクロールバー、メニューなどをサ ポートし、これらの「デフォルト（省略時）」の作用を提供することができる。 フレームワークはオブジェクト・テクノロジを基礎にいているので、この作用を 継承してオーバライド（override）することにより、開発者はフレームワークを 拡張し、カストマイズした解決手法を特定の専門分野で作ることができる。これ が従来のプログラミングに比べて大きな利点であるのは、プログラマはオリジナ ル・コードを変更することなく、むしろソフトウェアを拡張できるからである。 さらに、フレームワークは、アーキテクチャに関するガイダンスとモデリングを 提供すると同時に、問題領域に特有の個々のアクションを指定することから開発 者を解放するので、開発者はいくつかのコード層を通って盲目的に作業する必要 がない。 ビジネス側から見たときは、フレームワークは、特定の知識分野において専門 知識をカプセル化または具 現化する方法と見ることができる。企業の開発集団、独立ソフトウェア・ベンダ （Independent Software Vendors - ISV）およびシステム統合者（systems inte grators）は、前述した例のように、製造、会計、通貨取引きといった特定分野 における専門知識をもっている。この専門知識はコードで具現化されている。フ レームワークを使用すると、企業は、その専門知識を企業のコードで具現化する ことにより、専門知識の共通特性を取り込んで、パッケージ化することができる 。まず、そのようにすると、開発者は専門知識を利用するアプリケーションを作 成または拡張できるので、問題がいったん解決されれば、ビジネス・ルールや設 計は統一的に実施され、使用されることになる。また、フレームワークと、フレ ームワークの背景にある具現化された専門知識は、製造、会計、バイオテクノロ ジといった垂直的マーケットにおいて専門知識を得た企業にとっては、戦略的資 産をもつことを意味し、企業の専門知識をパッケージ化し、再販し、流布し、テ クノロジの進歩と普及化を促進するための分配メカニズムをもつことになる。 歴史的には、フレームワークがパーソナル・コンピューティング・プラットフ ォーム上の主流概念として出現したのは、つい最近のことである。この移行を助 長したのが、C++といったオブジェクト指向言語の出現である。従来までは、C++ は大部分がUNIXシステ ムと研究者のワークステーション上に搭載され、コマーシャル・ベースのパーソ ナル・コンピュータには搭載されていなかった。いくつかの大学や研究所のプロ ジェクトが今日の商用フレームワークおよびクラス・ライブラリの先駆けとなり 得たのは、C++などの言語やSmalltalkなどの他のオブジェクト指向言語のお陰で ある。その例のいくつかを挙げると、スタンフォード大学のInterViews、カーネ ギ・メロン大学のAndrewツールキット、チューリッヒ大学のET++フレームワーク がある。 フレームワークは、どのレベルのシステムに関心があり、どのような問題を解 決しようとしているかに応じて、多種類のものがある。フレームワークの種類は ユーザ・インタフェースの開発を支援するアプリケーション・フレームワークか ら、通信、印刷、ファイル・システム・サポート、グラフィックスなどの基本的 システム・ソフトウェア・サービスを提供する低レベルのフレームワークまでに わたっている。商用化されているアプリケーション・フレームワークの例をいく つか挙げると、MacApp（Apple）、Bedrock（Symantec）、OWL（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）は特定のプレース・オブ ジェクトの関数と通信スタイルをサポートしている。特に、好適実施例によれば 、次の協同モデルをサポートすることが可能である。すなわち、（ｉ）スクリー ン共有（screen sharing）、（ii）注釈マージング（annotation merging）、（ iii）ドキュメント・マージング（document merging）である。従って、ユーザ は、作成されるプレース・オブジェクトに合った協同モデルを選択することがで きる。 これらの３つの協同モデルを使用すると、ユーザは異なった方法でオブジェク トにアクセスすることがで きる。ユーザは、スクリーン共有協同モデルを使用すると、オブジェクトをリア ルタイム（実時間）で見ることができる。これとは対照的に、注釈マージングと ドキュメント・マージング協同モデルを使用すると、あるオブジェクトの異なる 部分を同時にアクセスすることができる。 ある種のプレース・オブジェクトは固有の協同スタイル（intrinsic collabor ation style）をもっており、これらはそのプレース・オブジェクトの目的を補 足するものである。従って、協同構成（collaboration arrangement）には、ブ ロードキャスト・スクリーン共有、対話式スクリーン共有、電話通信（telephon y）、共有ホワイトボード（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）プレース・オブジェクトは、ワークステーションに知らされていな いユーザによるアクセスを可能にする。ログイン・プレース・オブジェクトは、 オブジェクトとユーザ・セッションの開始に関する情報とを収めている。システ ム保守プレース・オブジェクトはユーザが保守タスクを実行することを可能にし 、マシン・ルームを収めている。マシン・ルームはワークステーションに関する 持続的構成情報を収めており、特定のユーザと関連づけられていない場合がある 。転送プレース・オブジェクトは、情報をストアし、ワークステーションのユー ザ間で情報を転送することを可能にする。 プレース・オブジェクトのアクセス プレース・オブジェクトをアクセスし、その間で ナビゲートするには、いくつかの方法がある。例えば、（ｉ）資源ブック（reso urce book）による方法、（ii）マップ表現の内部での方法、（iii）ポストカー ドなどのプレースへの参照の使用による方法、（iv）インビテーション（invita tion：招待状）による方法がある。 資源ブックにより、ブックのコンテキスト内で情報をユーザに提示して、プレ ース・オブジェクトへアクセスすることができる。通信ブック（communication book）に収められている情報は、名前サービス・ディレクトリ（name service d irectory）内に存在する、資源と呼ばれるオブジェクトに関するものである。従 って、資源ブックを通してアクセスできる資源には、人やプレースなどのオブジ ェクトが含まれる。このため、資源ブックは、プレース・オブジェクトを探し出 してアクセスするときの手段となる。 資源ブック内には、資源ブック内のプレース・オブジェクトに関する１つまた は２つ以上のタブがあり、そこにはプレース・オブジェクトを記述した情報が入 っている。そのような情報には、プレース・オブジェクト内に置かれたオブジェ クト、およびプレース・オブジェクトをアクセスするときのコストを含めること ができる。資源ブックによると、プレース・オブジェクトが見つけやすくなり、 そのあとで、ユーザはそのプレース・オブジェクトを持続的参照 （persistent reference）としてローカル・ワークステーションに持ち込むこと ができる。従って、下述するポストカードのような資源ブック内に表されている 選択されたプレース・オブジェクトは、そのプレース・オブジェクトを将来アク セスすることに備えて、資源ブックからドラグしてワークステーションのデスク トップ・ディスプレイ上に置いておくことができる。 マップは、プレース・オブジェクトを空間的に表現したものである。マップに は、なんらかの方法で結合されたプレース・オブジェクト群が含まれている。従 って、ユーザはマップ上をたどっていって、あるエリアに置かれていることが分 かっているプレース・オブジェクトを探し出すことができる。マップでは、アニ メーションとサウンドが使用されるので、ユーザはあるプレース・オブジェクト から別のプレース・オブジェクトへ移動するとき、コンテキストと移動感（sens e of transition）を得ることができる。 マップは空間的表示（spatial view）を使用して、ユーザが指定した種々のプ レース・オブジェクトへのアクセスを可能にする。ユーザはマップを使用して、 新しいプレース・オブジェクトを作成し、既存のプレース・オブジェクトを操作 することができる。マップは対話式（interactive）である。従って、ユーザは マップを使用すると、（ｉ）その参照をマップ上でダブ ルクリックしてプレース・オブジェクトをオープンすること、（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のような収集プレース・オブジェクトを含めることが 可能である。プレース・オブジェクトは、サービスを提供し、サービスへのアク セスを制限するように構築することができる。 ユーザがあるプレース・オブジェクトに入ったときの費用を計算するモデルが いくつか用意されている。具体的には、費用は、 （ｉ）プレース・オブジェクトへのアクセス （ii）プレース・オブジェクトのアクセス時間 （iii）あるプレース・オブジェクト内でアクセスされたオブジェクトの数 （iv）一定額の費用または申込み金 （ｖ）あらかじめ決めた使用制限 （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に移り 、そこでユーザは名前リストから名前を選択する。そのあと、機能ブロック820 で、ユーザ・オブジェクトをインスタンス生成（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図はいくつかのダイア ログ例を示したもので、そこには、これらの選択項目だけが示されている。 ユーザは、ログインしたあとどのプレースへ行くかを指定することができる。 ユーザは次の中から１つを選択する。１)絶対：HomeまたはMailプレースなどの 特定のプレースヘ行く、または２)最近のプレース（つまり、ユーザがログアウ トする直前にいた場所）。最近のプレースがリモート・プレースであれば、シス テムは、ユーザがいまそこへ行きたいのかを尋ねてくる。ユーザには、第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）サブシステムが提供する。プレゼンテーション自体は 、それを参照するカタログと一緒にここにストアされる。カタログは、ユーザ選 好MPreferenceCo11ectionオブジェクトが提供するデイクシヨリナリ・セマンテ イツク（dictionary semantics）を使用する。 ・ 各人はプレース上に１つのプレゼンテーションをもち、そこには、最後に 表示されたときの、そのプレースをユーザに提示するのに必要な一切の情報が収 められている。この情報は、プレース内のオープン・ ドキュメントのリストを含んでいる（プレゼンテーション代用物として表現され 、可能ならば、データ・モデル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）でオプション・キーを押えたまま、フォルダＡをフォルダＸか らドラグし、それをドロップしてフォルダＹに入れる。フォルダ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, 107,443号、第5,072,412号、第5,159,669号、第4,974,173号および第5,121,478 号に特許されているようなデスクトップ・メタフォア（desktop metaphor）が使 用されていた。 コンピュータ・システムのユーザにエルゴノミック・インターフェースを提供 する初期の試みの別の例として、IBM出願の特許明細書EP-0-520-942-A2がある。 これには、テキストとアイコンの組み合わせによって、通常オブジェクトのリス トを表示するコンテナについて記述されている。コンテナ・オブジェクト用のア イコンは、バスケット（in-basket）（文書が入っている）またはフォルダまた はファイル・キャビネッ ト（引き出しのついている）で表されることがある。オフイスビジョン／２コン テナ・オブジェクトは、特定の特徴を有しており、ある種のアクション、例えば コピー、削除、移動、オープン、印刷、送信、リネームおよびビユーのみを実行 することができる。オブジェクト指向の環境のもとでは、コンテナ・オブジェク トは、引き出しやファイル等のコンテナを作るためメソッドを含むクラスである 。 発明の概要 コンピュータ・システムのユーザ、特に未経験のユーザは、実世界の特性を備 えた環境を作り出すアプリケーションの恩益を受けている。特に、アプリケーシ ョンに未経験のユーザは使い慣れた参照フレーム（frame of reference）を利用 すると、アプリケーシヨンの概念を容易に把握できるであろう。好適実施例では 、他のオブジェクトをそこに収めておくことができるプレース・オブジェクト（ place object）のセットをユーザが作成できるようにすることによって、このよ うな環境を提供している。ここで言う他のオブジェクトとしては、人、物やアイ テム（項目）、および他のプレースを機能別に表現したものがある。 請求の範囲 １．オブジェクト指向のシステムを含むメモリを有するコンピュータにコンテ ナ・オブジェクトを形成する方法において、 （ａ）情報を保持するデータ構造、コンテナ・クラスからコンテナ・オブジェ クトを構築するメンバー関数、収容可能なオブジェクトを識別する情報をデータ 構造に挿人するための第１メンバー関数、編集操作を行う複数のメンバー関数、 および編集操作を識別する情報をデータ構造に挿入する第２メンバー関数を含む コンテナ・クラスを定義する情報をメモリのシステム・アドレス空間にストアす るステップ（第１図、24）と、 （ｂ）メモリのアプリケーション・プログラム・アドレス空間にコンテナ・オ ブジェクトをインスタンス形成するためのコンストラクティング・メンバー関数 を実行するステップ（第27図）と、 （ｃ）インスタンス形成されたコンテナ・オブジェクトのデータ構造に、収容 可能なオブジェクトを識別する情報を挿入するために、インスタンス形成された コンテナ・オブジェクトの第１挿入メンバー関数を実行するステップ（第18図） と、 （ｄ）インスタンス形成されたコンテナ・オブジェクトのデータ構造中の情報 によって識別される収容可能 なオブジェクトに対して編集操作を行うために、インスタンス形成されたコンテ ナ・オブジェクトの編集メンバー関数の１つを実行するステップ（第28図）と、 （ｅ）編集操作を取り消したり、やり直したりできるように、ステップ（ｄ） において実施された編集操作を識別する情報をインスタンス形成されたコンテナ ・オブジェクトのデータ構造に挿入するための第２挿入メンバー関数を実行する ステップ（第29図）と で特徴付けられる方法。 ２．請求の範囲第１項に記載の方法において、ステップ（ｃ）は、 （c1）他のコンテナ・オブジェクトを識別する情報をインスタンス形成された コンテナ・オブジェクトのデータ構造に挿入するための挿入メンバー関数を実行 するステップ（第18図） を備えることを特徴とする方法。 ３．請求の範囲第１項に記載の方法において、ステップ（ｃ）は、 （c2）物理位置を表す情報を含んでいるプレース・オブジェクトを識別する情 報を挿入するための挿入メンバー関数を実行するステップ（715、第４図） を備えることを特徴とする方法。 ４．請求の範囲第１項に記載の方法において、ステップ（ｃ）は、 （C3）メッセージを受信するメンバー関数を含むインボックス・オブジェクト を識別する情報を挿入するための挿入メンバー関数を実行するステップ（第17図 ） を備えることを特徴とする方法。 ５．請求の範囲第１項に記載の方法において、ステップ（ｃ）は、 （c4）メッセージを送信するメンバー関数を含むアウトボックス・オブジェク トを識別する情報を挿入するための挿入メンバー関数を実行するステップ（第17 図） を備えることを特徴とする方法。 ６．請求の範囲第１項に記載の方法において、ステップ（ｃ）は、 （c5）コンピュータ・システムをブートするメンバー関数を含むブートセット ・オブジェクトを識別する情報を挿入するための挿人メンバー関数を実行するス テップ（第７図） を備えることを特徴とする方法。 ７．請求の範囲第１項に記載の方法において、ステッ プ（ｃ）は、 （c6）データベース照会によって生成された情報を含むデータベース照会オブ ジェクトを識別する情報を挿入するための挿入メンバー関数を実行するステップ （第22図） を備えることを特徴とする方法。 ８．請求の範囲第１項に記載の方法において、ステップ（ｃ）は、 （c7）内容ベースのデータベース照会によって生成された情報を含む内容ベー スの検索オブジェクトを識別する情報を挿入するための挿入メンバー関数を実行 するステップ（第22図） を備えることを特徴とする方法。 ９．請求の範囲第１項に記載の方法において、ステップ（ｄ）は、 （d1）編集操作を選択するために、ユーザから入力を得るステップと、 （d2）インスタンス形成されたコンテナ・オブジェクトのデータ構造中の情報 によって識別された収容可能なオブジェクトに対して編集操作を行うために、イ ンスタンス形成されたコンテナ・オブジェクト中の編集メンバー関数の１つ実行 するステップと（第27図、第28図、第29図、第30図および第31図） を備えることを特徴とする方法。 １０．請求の範囲第９項に記載の方法において、ステップ（d1）は、 （d1a）コピー、削除、カット、ペースト、選択、ドラッグ、ドロップ、およ び移動からなる１組の編集操作から１つの編集操作を選択するためにユーザの入 力を得るステップ（第27図、第28図、第29図、第30図および第31図） を備えることを特徴とする方法。 １１．請求の範囲第１項に記載の方法において、コンテナ・クラスは、コンテナ ・オブジェクトを表すプレゼンテーションを作成するメンバー関数をさらに備え 、 （ｆ）インスタンス形成されたコンテナ・オブジェクトをウィンドウ・プレゼ ンテーション、フレーム・プレゼンテーション、およびアイコン・プレゼンテー シヨンとして生成するためのプレゼンテーション作成メソッドを実行するステッ プ（第５図、第17図、第26図） をさらに備えることを特徴とする方法。 １２．オブジェクト指向のシステムを含むメモリを有するコンピュータにコンテ ナ・オブジェクトを形成する システムにおいて、 （ａ）情報を保持するデータ構造、コンテナ・クラスからコンテナ・オブジェ クトを構築するメンバー関数、収容可能なオブジェクトを識別する情報をデータ 構造に挿入するための第１メンバー関数、編集操作を行う複数のメンバー関数、 および編集操作を識別する情報をデータ構造に挿入する第２メンバー関数を含む コンテナ・クラスを定義する情報をメモリのオペレーティング・システム・アド レス空間にストアする手段（第１図、24）と、 （ｂ）メモリのアプリケーション・プログラム・アドレス空間にコンテナ・オ ブジェクトをインスタンス形成するために、アプリケーション・プログラムによ り制御されてコンストラクティング・メンバー関数を実行する手段（第27図）と 、 （ｃ）インスタンス形成されたコンテナ・オブジェクトのデータ構造に、収容 可能なオブジェクトを識別する情報を挿入するために、アプリケーション・プロ グラムにより制御されてインスタンス形成されたコンテナ・オブジェクトの第１ 挿入メンバー関数を実行する手段（第18図）と、 （ｄ）インスタンス形成されたコンテナ・オブジェクトのデータ構造中の情報 によって識別される収容可能なオブジェクトに対して編集操作を行うために、ア プリケーション・プログラムにより制御されてインスタ ンス形成されたコンテナ・オブジェクトの編集メンバー関数の１つを実行する手 段（第28図）と、 （ｅ）特定の編集操作に応答して、編集操作を取り消したり、やり直したりで きるように、特定の編集操作を識別する情報をインスタンス形成されたコンテナ ・オブジェクトのデータ構造に挿入するための第２挿入メンバー関数を実行する 手段（第29図）と で特徴付けられるシステム。 １３．請求の範囲第12項に記載のシステムにおいて、第１挿入メンバー関数を実 行する手段［オブジェクトのクラスはフォルダである］は、アプリケーション・ プログラムにより制御され、他のコンテナ・オブジェクトを識別する情報をイン スタンス形成されたコンテナ・オブジェクトのデータ構造に挿入する（第18図） ことを特徴とするシステム。 １４．請求の範囲第12項に記載のシステムにおいて、挿入メンバー関数を実行す る手段は、アプリケーション・プログラムにより制御され、物理位置を表す情報 を含んでいるプレース・オブジェクトを識別する情報を挿入する（715、第４図 ）ことを特徴とするシステム。 １５．請求の範囲第12項に記載のシステムにおいて、挿 入メンバー関数を実行する手段は、アプリケーション・プログラムにより制御さ れ、メッセージを受信するメンバー関数を含むインボックス・オブジェクトを識 別する情報を挿入する（第17図）ことを特徴とするシステム。 １６．請求の範囲第12項に記載のシステムにおいて、挿入メンバー関数を実行す る手段は、アプリケーション・プログラムにより制御され、メッセージを送信す るメンバー関数を含むアウトボックス・オブジェクトを識別する情報を挿入する （第17図）ことを特徴とするシステム。 １７．請求の範囲第12項に記載のシステムにおいて、挿入メンバー関数を実行す る手段は、アプリケーション・プログラムにより制御され、コンピュータ・シス テムをブートするメンバー関数を含むブートセット・オブジェクトを識別する情 報を挿入する（第７図）ことを特徴とするシステム。 １８．請求の範囲第12項に記載のシステムにおいて、挿入メンバー関数を実行す る手段は、アプリケーション・プログラムにより制御され、データベース照会に よって生成された情報を含むデータベース照会オブジェクトを識別する情報を挿 入する（第22図）ことを 特徴とするシステム。 １９．請求の範囲第12項に記載のシステムにおいて、挿入メンバー関数を実行す る手段［オブジェクトのクラスであり］は、アプリケーション・プログラムによ り制御され、内容ベースのデータベース照会によって生成された情報を含む内容 ベースの検索オブジェクトを識別する情報を挿入する（第22図）ことを特徴とす るシステム。 ２０．請求の範囲第12項に記載のシステムにおいて、編集操作を選択するために 、ユーザから入力を得る手段と、編集操作の選択に応答して、インスタンス形成 されたコンテナ・オブジェクトのデータ構造中の情報によって識別された収容可 能なオブジェクトに対して編集操作を行うために、インスタンス形成されたコン テナ・オブジェクト中の編集メンバー関数の１つ実行する手段と（第27図、第28 図、第29図、第30図および第31図）を含むことを特徴とするシステム。 ２１．請求の範囲第20項に記載のシステムにおいて、コピー、削除、カット、ペ ースト、選択、ドラッグ、ドロップ、および移動からなる１組の編集操作から１ つの編集操作を選択するためにユーザの入力を得る手段（第27図、第28図、第29 図、第30図および第31図）を 含むことを特徴とするシステム。 ２２．請求の範囲第21項に記載のシステムにおいて、コンテナ・クラスは、コン テナ・オブジェクトを表すプレゼンテーションを作成するメンバー関数をさらに 備え、インスタンス形成されたコンテナ・オブジェクトをウィンドウ・プレゼン テーション、フレーム・プレゼンテーション、およびアイコン・プレゼンテーシ ョンとして生成するためのプレゼンテーション作成メソッドを実行する手段（第 ５図、第17図、第26図）をさらに備えることを特徴とするシステム。

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

Claims (1)

1. 【特許請求の範囲】 １．情報をコンピュータ・システムのメモリに編成する方法であって、 （ａ）コンテナをメモリにインスタンス生成し、 （ｂ）コンテナをオブジェクトのクラスに合わせて作り替え、 （ｃ）コンテナをメモリにストアするステップを含むことを特徴とする方法。 ２．オブジェクトのクラスはフォルダであることを特徴とする請求の範囲第１ 項に記載の方法。 ３．オブジェクトのクラスはプレース（place）であることを特徴とする請求 の範囲第１項に記載の方法。 ４．オブジェクトのクラスはインボックス（inbox）であることを特徴とする 請求の範囲第１項に記載の方法。 ５．オブジェクトのクラスはアウトボックス（outbox）であることを特徴とす る請求の範囲第１項に記載の方法。 ６．オブジェクトのクラスはブート・セット（boot set）であることを特徴とする請求の範囲第１項に記載の方法。 ７．オブジェクトのクラスはデータベース照会（database query）であること を特徴とする請求の範囲第１項に記載の方法。 ８．オブジェクトのクラスは内容ベース検索（content-based retrieval）で あることを特徴とする請求の範囲第１項に記載の方法。 ９．コンテナについてユーザがオペレーションを行うステップを含むことを特 徴とする請求の範囲第１項に記載の方法。 １０．オペレーションはコピー、削除、カット、ペースト、選択、ドラグ、ドロ ップ、選択、移動、やり直しおよび取消しを含むことを特徴とする請求の範囲第 ９項に記載の方法。 １１．コンテナをウィンドウ、フレーム、サムネイルおよびアイコンとして表示 するステップを含むことを特徴とする請求の範囲第１項に記載の方法。 １２．情報をコンピュータ・システムのメモリに編成す るシステムであって、 （ａ）コンテナをメモリにインスタンス生成する手段と、 （ｂ）コンテナをオブジェクトのクラスに合わせて作り替える手段と、 （ｃ）コンテナをメモリにストアする手段とを含むことを特徴とするシステム 。 １３．オブジェクトのクラスはフォルダであることを特徴とする請求の範囲第12 項に記載のシステム。 １４．オブジェクトのクラスはプレース（place）であることを特徴とする請求 の範囲第12項に記載のシステム。 １５．オブジェクトのクラスはインボックス（inbox）であることを特徴とする 請求の範囲第12項に記載のシステム。 １６．オブジェクトのクラスはアウトボックス（outbox）であることを特徴とす る請求の範囲第12項に記載のシステム。 １７．オブジェクトのクラスはブート・セット（boot set）であることを特徴と する請求の範囲第12項に記載 のシステム。 １８．オブジェクトのクラスはデータベース照会（database query）であること を特徴とする請求の範囲第12項に記載のシステム。 １９．オブジェクトのクラスは内容ベース検索（content-based retrieval）で あることを特徴とする請求の範囲第12項に記載のシステム。 ２０．コンテナについてユーザがオペレーションを行う手段を含むことを特徴と する請求の範囲第12項に記載のシステム。 ２１．オペレーションはコピー、削除、カット、ペースト、選択、ドラグ、ドロ ップ、選択、移動、やり直しおよび取消しを含むことを特徴とする請求の範囲第 20項に記載のシステム。 ２２．コンテナをウィンドウ、フレーム、サムネイルおよびアイコンとして表示 する手段を含むことを特徴とする請求の範囲第21項に記載のシステム。