JP3798015B2 - プレース・オブジェクト・システム - Google Patents
プレース・オブジェクト・システム Download PDFInfo
- Publication number
- JP3798015B2 JP3798015B2 JP50171995A JP50171995A JP3798015B2 JP 3798015 B2 JP3798015 B2 JP 3798015B2 JP 50171995 A JP50171995 A JP 50171995A JP 50171995 A JP50171995 A JP 50171995A JP 3798015 B2 JP3798015 B2 JP 3798015B2
- Authority
- JP
- Japan
- Prior art keywords
- place
- document
- user
- person
- presentation information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Operations Research (AREA)
- Economics (AREA)
- Marketing (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- User Interface Of Digital Computer (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
著作権表記
本出願は、一部に著作権保護の対象となる内容を含んでいる。著作権者は、何人が情報を得る目的で特許出願の一部として複製しても、それを妨げるものではないが、他のすべての権利、特に本内容の商業的利用に関する権利を留保する。
発明の分野
本発明は、一般的には、オブジェクト指向オペレーティング・システムにおいて種々の情報を編成し、アクセスする方法およびシステムに関し、より具体的には、異種コンテナ・オブジェクト(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)が使用されていた。
コンピュータ・システムのユーザにエルゴノミック・インターフェイスを提供する初期の試みのもうひとつの例は、“Form and Room:Metaphors for Groupware”（「フォームとルーム，グループ・ウエアのためのメタフォア」CONFERENCE ON ORGANIZATIONAL COMPUTING SYSTEMS(組織的なコンピュータ・システムに関する会議)vol.12、no.2,3,5、94-105頁、ジョージア州アトランタ、1991年11月）と題された論文である。この参考資料のなかで、ディスプレイ上でオープン・ウインドウで表現されている“ルーム”には、人物のリストがあり、ディスプレイ上でアイコンとして描かれている。その他のアイコンは、複写機、ファックス、ごみ箱、およびブリーフ・ケースを表すのに利用されている。アイコンは、オブジェクト、たとえば文書、をアイコン上に置くことで、対話的に働かせることができる。たとえば、ある文書は、ごみ箱アイコンのうえに重ねることで、その削除が完了する。しかしながら、個々のルームは、単なるグラフィックな表現にすぎず、ディスプレイ上の単一のウインドウに制限されている。
発明の概要
コンピュータ・システムのユーザ、特に未経験のユーザは、実世界の特性を備えた環境を作り出すアプリケーションの恩益を受けている。特に、アプリケーションに未経験のユーザは使い慣れた参照フレーム(frame of reference)を利用すると、アプリケーションの概念を容易に把握できるであろう。好適実施例では、他のオブジェクトをそこに収めておくことができるプレース・オブジェクト(place object)のセットをユーザが作成できるようにすることによって、このような環境を提供している。
好適実施例によれば、コンピュータ・システムにおける情報は、コンピュータのメモリ内の複数のプレース・オブジェクト内に編成される。プレース・オブジェクトへのアクセスは、マウスやその他のカーソル位置付けデバイスによって、カーソル文字をそのプレース・オブジェクトの上に置くことにより行われる。そのあとで、そのプレース・オブジェクトが選択されると、プレース・オブジェクトに関連するメソッドが関連のユーザ・インタフェースをユーザに提示して、プレース・オブジェクトの使用を容易にする。
【図面の簡単な説明】
本発明の上記および他の目的、側面および利点を理解しやすくするために、添付図面を参照して本発明の好適実施例について、以下で詳しく説明する。添付図面において、
第１図は、本発明の好適実施例によるコンピュータ・システムを示すブロック図である。
第２図は、本発明の好適実施例によるウィンドウ内のプレース・オブジェクトとデスクトップのプレース・オブジェクトを示す図である。
第３図は、本発明の好適実施例によるウィンドウ内のプレース・オブジェクトの拡大を示す図である。
第４図は、本発明の好適実施例によるワークステーション内のユーザプレース・オブジェクトの典型的な階層を示す図である。
第５図は、本発明の好適実施例によるインビテーション（招待状）を示す図である。
第６図は、本発明の好適実施例によるトラベル・バッグを示す図である。
第７図は、本発明の好適実施例によるハイレベルの制御の流れを示すフローチャートである。
第８図は、本発明の好適実施例による詳細ロジックを示すフローチャートである。
第９図は、本発明の好適実施例による詳細ロジックを示すフローチャートである。
第10図は、本発明の好適実施例による詳細ロジックを示すフローチャートである。
第11図は、本発明の好適実施例による詳細ロジックを示すフローチャートである。
第12図は、本発明の好適実施例による他のVDL図例の中で用いられている用語を説明するビジュアル設計言語(Visual Design Language-VDL)のキーを示す図である。
第13図は、本発明の好適実施例によるBoochダイアグラムを示す図である。
第14図は、本発明の好適実施例による別々の環境のプレゼンテーションを示す図である。
第15図は、ドキュメントおよびワークスペース・アイテムを、ユーザがそこにストアしておくことができる単一の「ホーム」プレースをもつ、本発明の好適実施例によるあるマシンを示す図である。
第16図は、ホームまたはデフォルトのプレース、ログオフする前にユーザがそこに置かれていた最後のプレース、ユーザが選択できるプレースの選択項目を表示する、本発明の好適実施例によるいくつかのダイアログ例を示す図である。
第17図は、あるプレースにいる人々を表示している、本発明の好適実施例による人物ストリップを示す図である。
第18図は、本発明の好適実施例による、人物存在管理に関係するモデルのメソッドを示す図である。
第19図は、人物オブジェクトがプレース・モデルに追加されるときの、本発明の好適実施例によるプロセスを示す図である。
第20図および第21図は本発明の好適実施例によるプレースとワークプレースとの関係を示す図である。
第22図は、本発明の好適実施例に従ってドキュメント・プレゼンテーション・ステートを維持するためにユーザ情報と一緒にストアされるオブジェクトを示す図である。
第23図は、本発明の好適実施例に従ってプレース・ドキュメント・ポリシ・オブジェクトを採用するコマンド・サブクラスを示しているBoochダイアグラムである。
第24図は、本発明の好適実施例に従ってあるプレース内のドキュメント上のセーブされたプレゼンテーションをオープンするときに実行されるステップを示す図である。
第25図は、本発明の好適実施例に従ってあるプレース内のドキュメント上のプレゼンテーションをクローズするときに実行されるステップを示す図である。
第26図は本発明の好適実施例による埋込み(embedment)と包含(containment)の違いを示す図である。
第27図は、本発明の好適実施例に従ってフォルダを作成する様子を示すVDLダイアグラムである。
第28図は、本発明の好適実施例に従ってフォルダ・ロジックをコピーする様子を示すVDLダイアグラムである。
第29図は、本発明の好適実施例に従ってフォルダ・ロジックを移動する様子を示すVDLダイアグラムである。
第30図は、本発明の好適実施例に従ってフォルダ・ロジックを移動する様子を示すVDLダイアグラムである。
第31図は、本発明の好適実施例に従ってフォルダ・ロジックを移動する様子を示すVDLダイアグラムである。
本発明の好適実施例の詳細な説明
ユーザはプレース(place-場所)を、人、プレースおよび物が存在するエリアとして概念化する。プレース・オブジェクト(place object)は、実際のロケーションの形式的および機能的特性を取り込むために作成される。プレース・オブジェクトは、情報を親しみやすく、意味のあるコンテキストに編成し、セグメント化することにより、実世界の知識を基礎にして構築される。さらに、本発明の好適実施例では、ユーザとコンピュータ・システムとの間で意味のあるやりとり(interaction−対話)を行うためのコンテキストが用意されている。
好適実施例では、情報は「プレース(place)−場所」と呼ばれる、持続性のある構造内に編成される。人やドキュメントなどの他のオブジェクトの形体をもつ情報は、プレース・オブジェクト間で適当にセグメント化される。一例として、ポストオフィス・プレース(post office place)は、通信資源に関係するオブジェクトの集まりを収容するように作られる。プレース・オブジェクトは、あるプレースに係わりをもつ人に関するオブジェクトを収容するように作ることもできる。別の例として、ライブラリ（図書館）プレースは大量の図書とライブラリアン（司書）を表すオブジェクトが置かれるプレースとして作られる。この場合、利用者はライブラリ・プレースをアクセスし、大量の図書の中から必要とする図書を探し出すために分類を行ってから、その図書を検索することが可能になる。他の方法として、利用者は、ライブラリアンを表すオブジェクト内に収められている情報によってライブラリアンに連絡し、ライブラリアンに文献検索を行わせることも可能である。
コンピュータ・システム
好適実施例は、好ましくは、IBM（登録商標）社PS/2（登録商標）またはアップル（登録商標）社マッキントッシュ（登録商標）コンピュータなどのパーソナル・コンピュータ上に置かれているオペレーティング・システムの環境（コンテキスト）で実施される。代表的なハードウェア環境は第１図に示されているが、同図は、従来のマイクロプロセッサのような中央演算処理ユニット10、およびシステム・バス12を介して相互に接続された複数の他のユニットを装備した、本発明の好適実施例によるワークステーションの代表的ハードウェア構成を示している。第１図に示すワークステーションは、ランダム・アクセス・メモリ(RAM)14、リードオンリ・メモリ(ROM)16、ディスク・ユニット20などの周辺デバイスをバスに接続するための入出力アダプタ18、キーボード24、マウス26、スピーカ28、マイクロホン32、および／またはタッチ・スクリーン・デバイス（図示せず）などのユーザ・インタフェース・デバイスをバスに接続するためのユーザ・インタフェース・アダプタ22、ワークステーションをデータ処理ネットワークに接続するための通信アダプタ34、およびバスをディスプレイ・デバイス38に接続するための表示アダプタ36を装備している。ワークステーションには、アップル社System/7（登録商標）オペレーティング・システムなどのオペレーティング・システムが置かれている。ドキュメント・フレームワーク・アーキテクチャ(document framework architecture)はRAM14に置かれており、CPU10の制御の下で、本発明の好適実施例を実現することを受け持っている。
好適実施例では、本発明は、オブジェクト指向プログラミング技法を使用してC++プログラミング言語で書かれている。この分野に精通しているものならば容易に理解されるように、オブジェクト指向プログラミング(Object-Oriented Programming-OOP)のオブジェクトは、データ構造とデータに対するオペレーション（操作、演算など）からなるソフトウェア・エンティティ(software entity)である。これらのエレメントが協力し合うことにより、オブジェクトは、そのデータ・エレメントで表されたその特性、およびそのデータ操作関数(data manupulation functions)で表されたその作用(behavior)からとらえて、ほとんどどのような実世界のエンティティでもモデル化することができる。この方法によると、オブジェクトは、人やコンピュータなどの具体物をモデル化することができ、また、数や幾何学的概念などの抽象概念をモデル化することができる。オブジェクト・テクノロジの利点は次の３つの基本的原理から得られるものである。それは、カプセル化(encapsulation)、多態(polymorphism)および継承(inheritance)である。
オブジェクトは、そのデータの内部構造とその関数が実行されるときのアルゴリズムを隠蔽する。つまりカプセル化する。これらのインプリメンテーション細部を見せる代わりに、オブジェクトは、外部情報(extraneous information)のないクリーンな形でその抽象化(abstractions)を表しているインタフェースを提示する。多態はカプセル化をさらに一歩進めたものである。この考え方は、多数の形体をもつ、１つのインタフェースである。あるソフトウェア・コンポーネントは、別のコンポーネントがなんであるかを正確に知らなくても、その別のコンポーネントを要求することができる。要求を受け取ったコンポーネントはその要求を解釈し、その要求をどのように実行すべきかを、その変数とデータに従って判断する。三番目の原理である継承によれば、開発者は既存の設計やコードを再利用することができる。この機能を利用すると、開発者はソフトウェアを初めから作ることが回避される。むしろ、継承を通して、開発者は作用を継承するサブクラスを派生し、その作用を開発者独自の要求に合ったものにカストマイズすることができる。
従来のアプローチでは、オブジェクトとクラス・ライブラリを手続き的環境で階層化する方法がとられていた。市販されている多くのアプリケーション・フレームワークはこの設計手法を採用している。この設計では、モノリシック・オペレーティング・システム(monolithic operating system)の上に１つまたは２つ以上のオブジェクト層が置かれている。このアプローチでは、カプセル化、多態および継承のすべての原理がオブジェクト層に採用され、手続き的プログラミング技法を大幅に改善しているが、このアプローチにはいくつかの制約がある。これらの問題は、開発者が自身のオブジェクトを再利用することは容易であるが、他のシステムからのオブジェクトを使用することが困難であるため、手続き的オペレーティング・システム(OS)のコールを使用して、下位の非オブジェクト層まで到達する必要があることに起因している。
オブジェクト指向プログラミングがもつもう１つの側面は、アプリケーションを開発するのにフレームワーク・アプローチを採用していることである。フレームワークの最も合理的な定義の１つとして、イリノイ大学のRalph E.JohnsonとPurdueのVincent F.Russoによるものがある。両氏の1991年の論文「オブジェクト指向設計の再利用」(Reusing Object-Oriented Designs)、イリノイ大学技術報告書UIUCDCS91-1696の中で、次のような定義を提案している。「抽象クラスとは、一組の責任分担を協力し合って実行するオブジェクトの集合を設計したものである。従って、フレームワークとは、組で定義された演算責任分担を協力し合って実行するオブジェクト・クラスが集まったものである。」プログラミング側から見たときは、フレームワークとは、基本的には、実働アプリケーション(working application)の事前に作られた構造を提供する、相互に接続されたオブジェクト・クラスの集まりである。例えば、ユーザ・インタフェース・フレームワークは、描画ウィンドウ(drawing window)、スクロールバー、メニューなどをサポートし、これらの「デフォルト（省略時）」の作用を提供することができる。フレームワークはオブジェクト・テクノロジを基礎にいているので、この作用を継承してオーバライド(override)することにより、開発者はフレームワークを拡張し、カストマイズした解決手法を特定の専門分野で作ることができる。これが従来のプログラミングに比べて大きな利点であるのは、プログラマはオリジナル・コードを変更することなく、むしろソフトウェアを拡張できるからである。さらに、フレームワークは、アーキテクチャに関するガイダンスとモデリングを提供すると同時に、問題領域に特有の個々のアクションを指定することから開発者を解放するので、開発者はいくつかのコード層を通って盲目的に作業する必要がない。
ビジネス側から見たときは、フレームワークは、特定の知識分野において専門知識をカプセル化または具現化する方法と見ることができる。企業の開発集団、独立ソフトウェア・ベンダ(Independent Software Vendors-ISV)およびシステム統合者(systems integrators)は、前述した例のように、製造、会計、通貨取引きといった特定分野における専門知識をもっている。この専門知識はコードで具現化されている。フレームワークを使用すると、企業は、その専門知識を企業のコードで具現化することにより、専門知識の共通特性を取り込んで、パッケージ化することができる。まず、そのようにすると、開発者は専門知識を利用するアプリケーションを作成または拡張できるので、問題がいったん解決されれば、ビジネス・ルールや設計は統一的に実施され、使用されることになる。また、フレームワークと、フレームワークの背景にある具現化された専門知識は、製造、会計、バイオテクノロジといった垂直的マーケットにおいて専門知識を得た企業にとっては、戦略的資産をもつことを意味し、企業の専門知識をパッケージ化し、再販し、流布し、テクノロジの進歩と普及化を促進するための分配メカニズムをもつことになる。
歴史的には、フレームワークがパーソナル・コンピューティング・プラットフォーム上の主流概念として出現したのは、つい最近のことである。この移行を助長したのが、C++といったオブジェクト指向言語の出現である。従来までは、C++は大部分がUNIXシステムと研究者のワークステーション上に搭載され、コマーシャル・ベースのパーソナル・コンピュータには搭載されていなかった。いくつかの大学や研究所のプロジェクトが今日の商用フレームワークおよびクラス・ライブラリの先駆けとなり得たのは、C++などの言語やSmalltalkなどの他のオブジェクト指向言語のお陰である。その例のいくつかを挙げると、スタンフォード大学のInterViews、カーネギ・メロン大学のAndrewツールキット、チューリッヒ大学のET++フレームワークがある。
フレームワークは、どのレベルのシステムに関心があり、どのような問題を解決しようとしているかに応じて、多種類のものがある。フレームワークの種類はユーザ・インタフェースの開発を支援するアプリケーション・フレームワークから、通信、印刷、ファイル・システム・サポート、グラフィックスなどの基本的システム・ソフトウェア・サービスを提供する低レベルのフレームワークまでにわたっている。商用化されているアプリケーション・フレームワークの例をいくつか挙げると、MacApp(Apple)、Bedrock(Symantec)、OWL(Borland)、NeXtStep App Kit(NeXT)、Smalltak-80 MVC(ParcPlace)がある。
フレームワークでプログラミングを行うには、他の種類のシステムに慣れている開発者は考え方を変える必要がある。確かに、このプログラミングは、従来考えられていたプログラミングとはまったく異なっている。DOSやUNIXなどの旧スタイルのオペレーティング・システムでは、開発者自身のプログラムが構造全体になっている。オペレーティング・システムはシステム・コール(system call)を通してサービスを提供している。つまり、開発者のプログラムはサービスの必要時にコールを行い、サービスが提供されたとき制御が返却される。プログラム構造は制御の流れに基礎を置き、これは開発者が書いたコードに具現化されている。
フレームワークが使用されるときは、これとは反対である。開発者は制御の流れに責任をもつ必要がなくなる。開発者は、プログラミング・タスクを実行の流れから把握して理解しようとする癖を止めなければならない。むしろ、オブジェクトの責任分担からとらえて思考する必要があるので、タスクをいつ実行させるかを判断するには、フレームワークに頼らざるを得なくなる。開発者が書いたルーチンは、開発者が書かなかった、従って開発者には見えないコードによってアクチベート(activate−活性化)される。この制御の流れのフリップフロップは、手続き的プログラミングだけに経験のある開発者にとっては、大きな心理的障壁となっている。しかし、このことをいったん理解してしまえば、フレームワーク・プログラミングによると、他のタイプのプログラミングによる場合よりも作業量が大幅に減少することになる。
アプリケーション・フレームワークが開発者にプレハブの機能を提供するのと同じように、本発明の好適実施例に含まれているようなシステム・フレームワークはシステム・レベルのサービスを提供することによって同じ考え方をてこにしている。つまり、システム・プログラマといった開発者は、システム・レベルのサービスをサブクラス化またはオーバライドして、カストマイズした解決手法を作成することができる。例えば、オーディオ、ビデオ、MIDI、アニメーションなどの新規なデバイスや異種デバイスをサポートする基礎を提供できるマルチメディア・フレームワークについて考えてみることにする。新しい種類のデバイスをサポートする必要がある場合、開発者はデバイス・ドライバを書くことが必要になる。フレームワークでこれを行う場合は、開発者に要求されることは、その新デバイスに特有の特性と作用を指定するだけである。
この場合の開発者は、マルチメディア・フレームワークから呼び出されるある種のメンバ関数(member functions)のインプリメンテーションを用意することになる。開発者にとってすぐに利点となることは、デバイスのカテゴリ別に必要になる汎用コード(generic code)がマルチメディア・フレームワークにすでに用意されていることである。このことは、デバイス・ドライバ開発者が書き、テストし、デバッグするコードが少なくなることを意味する。システム・フレームワークを使用するもう１つの例は、SCSIデバイス、NuBusカード、およびグラフィックス・デバイス別のI/Oフレームワークを持つ場合である。機能は継承されるので、各フレームワークには、そのデバイス・カテゴリに見られる共通機能に対するサポートが用意されている。この場合、他の開発者は、これらの統一インタフェース(consistent interfaces)を通して、あらゆる種類のデバイスにアクセスすることが可能になる。
協同モデル
固有の協同モデル(inherent collaboration model)は特定のプレース・オブジェクトの関数と通信スタイルをサポートしている。特に、好適実施例によれば、次の協同モデルをサポートすることが可能である。すなわち、(i)スクリーン共有(screen sharing)、(ii)注釈マージング(annotation merging)、(iii)ドキュメント・マージング(document merging)である。従って、ユーザは、作成されるプレース・オブジェクトに合った協同モデルを選択することができる。
これらの３つの協同モデルを使用すると、ユーザは異なった方法でオブジェクトにアクセスすることができる。ユーザは、スクリーン共有協同モデルを使用すると、オブジェクトをリアルタイム（実時間）で見ることができる。これとは対照的に、注釈マージングとドキュメント・マージング協同モデルを使用すると、あるオブジェクトの異なる部分を同時にアクセスすることができる。
ある種のプレース・オブジェクトは固有の協同スタイル(intrinsic collaboration 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 hierarchy)を構築することができる。言い換えれば、ユーザは、情報がファイル・システムのどこに、あるいはどのようにストアされているかに関係なく、情報を自由に編成してワークスペースに置いておくことができる。コンテナは複数のボリュームにまたがることができる。すべてのボリュームが利用できないと、利用できないオブジェクトは表示されないか、あるいはぼかされて(gray out)表示される。コンテナ自体、つまり、包含階層のルート(root)はその格納プレース(enclosing place)に残されており、そのプレースと同じ記憶ドメイン(storage domain)(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およびTerryという名前の３人のユーザが共有している。共有ユーザの各々は、それぞれ402,404,406に示すホームプレース・オブジェクトを所有している。さらに、ホームプレース・オブジェクト404(Johnのホームプレース・オブジェクト)はサブプレース・オブジェクト408(Johnのワークプレース・オブジェクト)と410(Johnのアートプレース(Art Place)オブジェクト)に再分割されている。
ワークステーションには、特定のユーザと関連づけられていない他のプレース・オブジェクトを置いておくことも可能である。そのようなプレース・オブジェクトとしては、好ましくは、ゲスト・プレース・オブジェクト(guest place object)、ログイン・プレース・オブジェクト(log-in place object)、システム保守プレース・オブジェクト(system maintenance place object)、転送プレース・オブジェクト(transfer place object)などがある。ゲストまたは公開(public)プレース・オブジェクトは、ワークステーションに知らされていないユーザによるアクセスを可能にする。ログイン・プレース・オブジェクトは、オブジェクトとユーザ・セッションの開始に関する情報とを収めている。システム保守プレース・オブジェクトはユーザが保守タスクを実行することを可能にし、マシン・ルームを収めている。マシン・ルームはワークステーションに関する持続的構成情報を収めており、特定のユーザと関連づけられていない場合がある。転送プレース・オブジェクトは、情報をストアし・ワークステーションのユーザ間で情報を転送することを可能にする。
プレース・オブジェクトのアクセス
プレース・オブジェクトをアクセスし、その間でナビゲートするには、いくつかの方法がある。例えば、(i)資源ブック(resource book)による方法、(ii)マップ表現の内部での方法、(iii)ポストカードなどのプレースへの参照の使用による方法、(iv)インビテーション（invitation：招待状）による方法がある。
資源ブックにより、ブックのコンテキスト内で情報をユーザに提示して、プレース・オブジェクトへアクセスすることができる。通信ブック(communication book)に収められている情報は、名前サービス・ディレクトリ(name service directory)内に存在する、資源と呼ばれるオブジェクトに関するものである。従って、資源ブックを通してアクセスできる資源には、人やプレースなどのオブジェクトが含まれる。このため、資源ブックは、プレース・オブジェクトを探し出してアクセスするときの手段となる。
資源ブック内には、資源ブック内のプレース・オブジェクトに関する１つまたは２つ以上のタブがあり、そこにはプレース・オブジェクトを記述した情報が入っている。そのような情報には、プレース・オブジェクト内に置かれたオブジェクト、およびプレース・オブジェクトをアクセスするときのコストを含めることができる。資源ブックによると、プレース・オブジェクトが見つけやすくなり、そのあとで、ユーザはそのプレース・オブジェクトを持続的参照(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 MEETING”に関する情報を収めている。このインビテーションを転送する人、ミーティングの時刻、ミーティングの場所、および指名したゲストに関する情報も、それぞれ参照符号506,508,510,512で示すように、このインビテーションに示されている。
必要とするプレース・オブジェクトが見つかったとき、ユーザはサブプレースであるプレース・オブジェクト間をナビゲートしなければならない。プレース・オブジェクトの設計者が選択するナビゲーション方法は、プレース・オブジェクトの重要な特性である。プレース・オブジェクトは階層になっているので、ユーザは、プレース・オブジェクトが深いネスト構造(deep nested structure)にあるのか、浅い構造(shallowstructure)にあるのかを知っている必要がある。深いネストは、ユーザが連続するサブプレース・オブジェクトをオープンしていくか、あるいは参照を使用して深いネストのプレース・オブジェクトまで到達しなければならないことを意味する場合がある。これに対して、多数のエレメントからなる浅い構造は空間的により多くのスペースを占めるので、潜在的には、ユーザにより多くの選択項目をよりハイレベルで与えることができる。従って、作成者が選択するナビゲーション方法は、到達しようとするプレース・オブジェクトの構造によって決まる。
好ましくは、スケーリング方法(scaling method)とパンニング方法(panning method)を併用すると、デスクトップ・ディスプレイ内でナビゲートすることができる。あるプレース・オブジェクトを均一にスケーリングするには、アスペクト比（aspect ratio：横縦比）を一定に保ちながら、プレース・オブジェクトの寸法を拡大または縮小する。スケーリングは、ズームしてドキュメントやプレース・オブジェクト・ビューに入ったり、そこから出たりするユーザにとっても重要である。プレース・オブジェクトが正しくスケーリングされたあと、パンニングを使用すると、プレース・オブジェクト内をナビゲートすることができる。パンニングを行うときは、プレース・オブジェクトの特定部分を表示するように、グラフィック・カーソル(graphic cursor)を動かしながら手操作でデスクトップに指示する。パンニング・グラフィックをドラグすることにより、ユーザはデスクトップの他の領域をビューに移動する。
別の方法として、好適実施例では、スクローリングや自動パンニング(auto-panning)またはディストーティング(distorting)方法を使用して、プレース・オブジェクト内をナビゲートしている。自動パンニングはホットゾーン(hot-zone)（通常は、デスクトップのエッジを取り巻くエリアであるが）に入り込むカーソルの動きを検出して、ディスプレイを動きの方向にパンする。システムには、照会(query)により、あるプレース・オブジェクトを見つけたり、プレース・オブジェクトのある内容を見つけるためのメカニズムも、ユーザのために用意されている。
アクセス制限
プレース・オブジェクト内のセキュリティとアクセス制御を実現するには、いくつかの方法がある。第一は、一組のアクセス権をプレース・オブジェクトと関連づける方法である。この方法によると、その組のアクセス権の範囲にあるユーザは、だれもプレース・オブジェクトをアクセスすることが許される。第二は、あるプレース・オブジェクトへの最低限のアクセス権を指定した人に与える方法である。しかし、増加したアクセス権がプレース・オブジェクト内に包含されたオブジェクトと関連づけられることになる。第三は、プレース・オブジェクトを必要とする個人とグループを指定して、アクセス権を割り当てる方法であるが、これらの権利はプレース・オブジェクトとそこに包含されるオブジェクト全体に適用されることになる。これらのルールによると、個別のファイル管理を必要としないで、プレース・オブジェクト内に異なる共有レベルをもたせることができる。
アクセスを制限する別の方法として、プレース・オブジェクトをアクセスするユーザに費用を負担させることが可能である。従って、プレース・オブジェクトはサービスを提供する手段として利用することができる。そのようなサービスには、ダウジョーンズ(Dow Jonesのような情報サービス、ウォールストリート・ジャーナル(Wall Street Journal)のようなニュース・サービス、購買サービスおよびAmerica On-Lineのような収集プレース・オブジェクトを含めることが可能である。プレース・オブジェクトは、サービスを提供し、サービスへのアクセスを制限するように構築することができる。
ユーザがあるプレース・オブジェクトに入ったときの費用を計算するモデルがいくつか用意されている。具体的には、費用は、
(i)プレース・オブジェクトへのアクセス
(ii)プレース・オブジェクトのアクセス時間
(iii)あるプレース・オブジェクト内でアクセスされたオブジェクトの数
(iv)一定額の費用または申込み金
(v)あらかじめ決めた使用制限
(vi)これらの任意の組合せ
の任意の１つまたは組合せに基づいて計算することができる。
好ましくは、発生した費用と潜在的費用の通知は、あるプレース・オブジェクトにアクセスするとユーザに表示される。さらに、オペレーションが高価になるおそれがあることは、ユーザに事前に警告される。さらに、ユーザは、あるプレース・オブジェクトの最大費用を指定することができる。最大費用に達すると、ユーザに通知されるので、ユーザはそのプレース・オブジェクトから出るか、それとも将来発生する追加費用を負担するかを選択することができる。
プレース・オブジェクトのビジュアル表現
プレース・オブジェクトのビジュアル表現は、ロケーション感(sense of location)を作る上で重要である。従って、プレース・オブジェクトは、背景イメージ、レイアウト、スケール、デザイン・スタイル、空間ボリューム(spatial volume)、照明効果および文字体裁(typography)といった、いくつかのエレメントに関して設計することができる。好適実施例では、これらのエレメントを組み合わせて、識別性(distinctive)があり、ナビゲーションを容易にする環境を作成している。
プレース・オブジェクトに適用される背景イメージは、リードオンリ・モデル(read-only model)を通して作成することができる。これには、移動するイメージや、現在時刻を基準にしてそのプレゼンテーションを変更する夜間／昼間プレース・オブジェクトのように、データ駆動(data-driven)のイメージが含まれる。さらに、プレース・オブジェクトの背景イメージをぼかすと、背景イメージと、ディスプレイの最前部のウィンドウやオブジェクト・アイコンなどのアイテム（項目）との間の奥行き(depth stratification)を追加することができる。また、彩度(saturation)を利用すると、前景アイテムと背景イメージの間に独特のスタイルを作ることもできる。
プレース・オブジェクトの密度とレイアウトは、プレース・オブジェクトが満足のいくように反映されるように適応される。プレース・オブジェクトがリードオンリ・アクセスだけを許しているのでなければ、ユーザがプレース・オブジェクトに加えたレイアウト変更はセーブ（格納）され、リターン時にリストア（復元）される。背景イメージと、プレース・オブジェクトの寸法スケールおよび寸法比との関係により、ユーザのスコープ感(sense of scope)が設定される。従って、小さい、遠のいて行くプレース・オブジェクトは距離を示し、大きいプレース・オブジェクトはプレース・オブジェクトの広がりを表している。
プレース・オブジェクトの空間ボリュームは、プレース・オブジェクトの表現に不可欠である。プレース・オブジェクト内のオブジェクトの選択、配置およびレンダリング(rendering)はユーザが使用できるオプションの範囲を示している。プレース・オブジェクトには、ユーザに理解しやすいものと、オープンと読取りによって詳細分析を必要とするものがある。それにもかかわらず、プレース・オブジェクトは、プレース・オブジェクトに収められたエレメントを調べると、容易に区別することができる。さらに、空間の奥行きと対話によるナビゲーション方法はプレース・オブジェクトの特性になっている。空間仮想現実(spatial virtual realities)を実現すると、三次元入力デバイスの使用とナビゲーションが可能になる。
照明と文字体裁のエレメントは、各プレース・オブジェクトに独特の特性をもたせる上で役に立つ。プレース・オブジェクトは、プレース・オブジェクトの特定の側面に焦点を当てて設計することができる。大きなサイズで使用される表示タイプフェースのような、文字体裁を利用すると、プレース・オブジェクトに独特の特徴をもたせることが可能である。
プレース・オブジェクト以外のオブジェクト
プレース・オブジェクトとワークスペースに置かれる他のタイプのオブジェクトの中では、プレース・オブジェクトが最高レベル・オブジェクトである。従って、フォルダのようなコンテナ・オブジェクトを含んでいる典型的なオブジェクトが現れるのは、プレース・オブジェクトのコンテキスト内である。さらに、フォルダのようなコンテナ・オブジェクトはプレース・オブジェクトを収容することができない。コンテナ・オブジェクトは、ポストカードのようなプレース・オブジェクトを指す参照だけを収容することができる。
プレース・オブジェクトは他のオブジェクトを多数収容することができる。そのようなオブジェクトとしては、ドキュメント、コンテナ、器具、ツール、文房具、および人を指す参照などがある。プレース・オブジェクトは、サブプレース・オブジェクトと呼ばれる他のオブジェクトを収容することも可能である。プレース・オブジェクトは他のプレース・オブジェクトを指す参照を収容することもできる。従って、プレース・オブジェクトの階層は、関連のオブジェクトをさらに再分割できるように維持することができる。
好適実施例では、共有プレース・オブジェクトのワークスペース内に挿入できるオブジェクトの作成が可能である。例えば、掲示板(bulletin board)をプレース・オブジェクト内に挿入しておくと、プレース・オブジェクトをアクセスした人は、お互いに情報をやりとりすることができる。さらに、ビジネス・カード(business card：名刺)をプレース・オブジェクト内に挿入しておくと、ある人はビジネス・カードで表された人と連絡することができる。
好適実施例では、ユーザは２つの方法で、プレース・オブジェクトをナビゲートしている間に、選択したオブジェクトをアクセスできる。２つの方法とは、ポータブル・コンテナ(portable container)とワークスペース・シェルフ(workspace 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)コピー、(iii)参照の移動、(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)である。ラベル1200は協同作業(collaboration)の例を示している。ラベル1210はオブジェクトの作成例を示している。ラベル1220は間接的協同作業(indirect collaboration)の例を示している。最後に、ラベル1230は包含(containment)の例を示している。第13図は好適実施例によるBoochダイアグラムである。
論理的には、プレースは、アトミック(atomic)に操作できる自己完結環境(self-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)内のコンテナはあるプレースで専用され、空間ビュー(spatialview)内のコンテナは別のプレースで専用される。プレースとプレース・プレゼンテーションのどちらも、どのドキュメントがそのプレースでオープンしているかの情報を維持していなければならない。
ユーザと一緒にストアされるユーザ固有のプレゼンテーション
第22図は、ドキュメント・プレゼンテーション・ステートを維持するためにユーザ情報と一緒にストアされているオブジェクトを示している。大きなモデル・ストアは、プレース上のセーブされたプレゼンテーションとユーザ・ドキュメント上のプレゼンテーションが共にそこに存在することを示している。カタログはドキュメントと、プレースの特定プレゼンテーションとの対応関係（マッピング）を示している。これらが使用されるのは、ユーザがドキュメントをオープンするときであり、これにより、正しいプレゼンテーションが使用されるようになる。ユーザのスペース内では、選好情報と最近の活動記録(history)情報のための記憶域は、人(people)サブシステムが提供する。プレゼンテーション自体は、それを参照するカタログと一緒にここにストアされる。カタログは、ユーザ選好MPreferenceCollectionオブジェクトが提供するディクショリナリ・セマンティック(dictionary semantics)を使用する。
・ 各人はプレース上に１つのプレゼンテーションをもち、そこには、最後に表示されたときの、そのプレースをユーザに提示するのに必要な一切の情報が収められている。この情報は、プレース内のオープン・ドキュメントのリストを含んでいる（プレゼンテーション代用物として表現され、可能ならば、データ・モデルIDが一緒に付いて表現されている）。
・ 各人は、複数のプレゼンテーションを１つのドキュメント上にセーブしておくことができる。各人は、それが表示される各プレースごとに異なるプレゼンテーションをもつことができる。
ドキュメント・プレゼンテーション情報のカタログはドキュメントを、それらが表示されたプレース用に存在する既存のセーブされたプレゼンテーションと対応づける。このカタログに入っている情報は、キー、プレースID、およびプレゼンテーションのプレゼンテーション代用物として、モデルID（グローバルID）だけを必要とするドキュメントである。
プレース・プレゼンテーションには、ドキュメントがいつ初めてオープンされたか、といったドキュメントに関する情報が、次回にプレースに入ったときステートを正しく復元するために必要である。そのためには、ウィンドウ・プレゼンテーションがプレースでいつオープンされたかの通知を受け取る必要がある。これは、次のようなプロジージャを通して行われる。
・ オープン／クローズ／フォロー・コマンドはすべて、ドキュメントをオープンし、クローズする作業を包含ポリシ・オブジェクト(contained policy object)に委任する形体のモデル・コマンドを使用する。第23図は、好適実施例に従ってプレース・ドキュメント・ポリシを採用するコマンド・サブクラスを示すBoochダイアグラムである。ラベル2310は好適実施例に従ってドキュメントをオープンするモデル・コマンドを示している。ラベル2320は2310に示したコマンドであって、プレース・ドキュメント・ポリシ・オブジェクトに委任するモデル・コマンドのサブクラスを示している。ラベル2330は、2320で使用されたドキュメント・ポリシをメモリにストアするmixinクラスである。すべてのプレース固有モデル・コマンドはラベル2330のオブジェクトからのサブクラスである。ラベル2340は、その前に置かれたオブジェクトに示されているオペレーションを実行するポリシ・オブジェクトである。
・ ポリシ・オブジェクトは、このプレースに対して行おうとしているタイプの作用(behavior)を包括している。この作用は協同プレースでは異なり、異なるヒューマン・インタフェースが必要な場合も異なる。
・ 各コンテナまたはドキュメント・プレゼンテーションがその“オープン”コマンドをメニューに登録するときは、これらのオープン委任コマンド(delegating 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 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,107,443号、第5,072,412号、第5,159,669号、第4,974,173号および第5,121,478号に特許されているようなデスクトップ・メタフォア(desktop metaphor)が使用されていた。
コンピュータ・システムのユーザにエルゴノミック・インターフェイスを提供する初期の試みのもうひとつの例は、“Form and Room:Metaphors for Groupware”（「フォームとルーム，グループ・ウエアのためのメタフォア」CONFERENCE ON ORGANIZATIONAL COMPUTING SYSTEMS(組織的なコンピュータ・システムに関する会議)vol.12、no.2,3,5、94-105頁、ジョージア州アトランタ、1991年11月）と題された論文である。この参考資料のなかで、ディスプレイ上でオープン・ウインドウで表現されている“ルーム”には、人物のリストがあり、ディスプレイ上でアイコンとして描かれている。その他のアイコンは、複写機、ファックス、ごみ箱、およびブリーフ・ケースを表すのに利用されている。アイコンは、オブジェクト、たとえば文書、をアイコン上に置くことで、対話的に働かせることができる。たとえば、ある文書は、ごみ箱アイコンのうえに重ねることで、その削除が完了する。しかしながら、個々のルームは、単なるグラフィックな表現にすぎず、ディスプレイ上の単一のウインドウに制限されている。
発明の概要
コンピュータ・システムのユーザ、特に未経験のユーザは、実世界の特性を備えた環境を作り出すアプリケーションの恩益を受けている。特に、アプリケーションに未経験のユーザは使い慣れた参照フレーム(frame of reference)を利用すると、アプリケーションの概念を容易に把握できるであろう。好適実施例では、他のオブジェクトをそこに収めておくことができるプレース・オブジェクト(place object)のセットをユーザが作成できるようにすることによって、このような環境を提供している。
好適実施例によれば、コンピュータ・システムにおける情報は、コンピュータのメモリ内の複数のプレース・オブジェクト内に編成される。プレース・オブジェクトへのアクセスは、マウスやその他のカーソル位置付けデバイスによって、カーソル文字をそのプレース・オブジェクトの上に置くことにより行われる。そのあとで、そのプレース・オブジェクトが選択されると、プレース・オブジェクトに関連するメソッドが関連のユーザ・インタフェースをユーザに提示して、プレース・オブジェクトの使用を容易にする。
【図面の簡単な説明】
本発明の上記および他の目的、側面および利点を理解しやすくするために、添付図面を参照して本発明の好適実施例について、以下で詳しく説明する。添付図面において、
第１図は、本発明の好適実施例によるコンピュータ・システムを示すブロック図である。
第２図は、本発明の好適実施例によるウィンドウ内のプレース・オブジェクトとデスクトップのプレース・オブジェクトを示す図である。
第３図は、本発明の好適実施例によるウィンドウ内のプレース・オブジェクトの拡大を示す図である。
第４図は、本発明の好適実施例によるワークステーション内のユーザプレース・オブジェクトの典型的な階層を示す図である。
第５図は、本発明の好適実施例によるインビテーション（招待状）を示す図である。
第６図は、本発明の好適実施例によるトラベル・バッグを示す図である。
第７図は、本発明の好適実施例によるハイレベルの制御の流れを示すフローチャートである。
第８図は、本発明の好適実施例による詳細ロジックを示すフローチャートである。
第９図は、本発明の好適実施例による詳細ロジックを示すフローチャートである。
第10図は、本発明の好適実施例による詳細ロジックを示すフローチャートである。
第11図は、本発明の好適実施例による詳細ロジックを示すフローチャートである。
第12図は、本発明の好適実施例による他のVDL図例の中で用いられている用語を説明するビジュアル設計言語(Visual Design Language-VDL)のキーを示す図である。
第13図は、本発明の好適実施例によるBoochダイアグラムを示す図である。
第14図は、本発明の好適実施例による別々の環境のプレゼンテーションを示す図である。
第15図は、ドキュメントおよびワークスペース・アイテムを、ユーザがそこにストアしておくことができる単一の「ホーム」プレースをもつ、本発明の好適実施例によるあるマシンを示す図である。
第16図は、ホームまたはデフォルトのプレース、ログオフする前にユーザがそこに置かれていた最後のプレース、ユーザが選択できるプレースの選択項目を表示する、本発明の好適実施例によるいくつかのダイアログ例を示す図である。
第17図は、あるプレースにいる人々を表示している、本発明の好適実施例による人物ストリップを示す図である。
第18図は、本発明の好適実施例による、人物存在管理に関係するモデルのメソッドを示す図である。
第19図は、人物オブジェクトがプレース・モデルに追加されるときの、本発明の好適実施例によるプロセスを示す図である。
第20図および第21図は本発明の好適実施例によるプレースとワークプレースとの関係を示す図である。
第22図は、本発明の好適実施例に従ってドキュメント・プレゼンテーション・ステートを維持するためにユーザ情報と一緒にストアされるオブジェクトを示す図である。
第23図は、本発明の好適実施例に従ってプレース・ドキュメント・ポリシ・オブジェクトを採用するコマンド・サブクラスを示しているBoochダイアグラムである。
第24図は、本発明の好適実施例に従ってあるプレース内のドキュメント上のセーブされたプレゼンテーションをオープンするときに実行されるステップを示す図である。
第25図は、本発明の好適実施例に従ってあるプレース内のドキュメント上のプレゼンテーションをクローズするときに実行されるステップを示す図である。
第26図は本発明の好適実施例による埋込み(embedment)と包含(containment)の違いを示す図である。
第27図は、本発明の好適実施例に従ってフォルダを作成する様子を示すVDLダイアグラムである。
第28図は、本発明の好適実施例に従ってフォルダ・ロジックをコピーする様子を示すVDLダイアグラムである。
第29図は、本発明の好適実施例に従ってフォルダ・ロジックを移動する様子を示すVDLダイアグラムである。
第30図は、本発明の好適実施例に従ってフォルダ・ロジックを移動する様子を示すVDLダイアグラムである。
第31図は、本発明の好適実施例に従ってフォルダ・ロジックを移動する様子を示すVDLダイアグラムである。
本発明の好適実施例の詳細な説明
ユーザはプレース(place-場所)を、人、プレースおよび物が存在するエリアとして概念化する。プレース・オブジェクト(place object)は、実際のロケーションの形式的および機能的特性を取り込むために作成される。プレース・オブジェクトは、情報を親しみやすく、意味のあるコンテキストに編成し、セグメント化することにより、実世界の知識を基礎にして構築される。さらに、本発明の好適実施例では、ユーザとコンピュータ・システムとの間で意味のあるやりとり(interaction−対話)を行うためのコンテキストが用意されている。
好適実施例では、情報は「プレース(place)−場所」と呼ばれる、持続性のある構造内に編成される。人やドキュメントなどの他のオブジェクトの形体をもつ情報は、プレース・オブジェクト間で適当にセグメント化される。一例として、ポストオフィス・プレース(post office place)は、通信資源に関係するオブジェクトの集まりを収容するように作られる。プレース・オブジェクトは、あるプレースに係わりをもつ人に関するオブジェクトを収容するように作ることもできる。別の例として、ライブラリ（図書館）プレースは大量の図書とライブラリアン（司書）を表すオブジェクトが置かれるプレースとして作られる。この場合、利用者はライブラリ・プレースをアクセスし、大量の図書の中から必要とする図書を探し出すために分類を行ってから、その図書を検索することが可能になる。他の方法として、利用者は、ライブラリアンを表すオブジェクト内に収められている情報によってライブラリアンに連絡し、ライブラリアンに文献検索を行わせることも可能である。
コンピュータ・システム
好適実施例は、好ましくは、IBM（登録商標）社PS/2（登録商標）またはアップル（登録商標）社マッキントッシュ（登録商標）コンピュータなどのパーソナル・コンピュータ上に置かれているオペレーティング・システムの環境（コンテキスト）で実施される。代表的なハードウェア環境は第１図に示されているが、同図は、従来のマイクロプロセッサのような中央演算処理ユニット10、およびシステム・バス12を介して相互に接続された複数の他のユニットを装備した、本発明の好適実施例によるワークステーションの代表的ハードウェア構成を示している。第１図に示すワークステーションは、ランダム・アクセス・メモリ(RAM)14、リードオンリ・メモリ(ROM)16、ディスク・ユニット20などの周辺デバイスをバスに接続するための入出力アダプタ18、キーボード24、マウス26、スピーカ28、マイクロホン32、および／またはタッチ・スクリーン・デバイス（図示せず）などのユーザ・インタフェース・デバイスをバスに接続するためのユーザ・インタフェース・アダプタ22、ワークステーションをデータ処理ネットワークに接続するための通信アダプタ34、およびバスをディスプレイ・デバイス38に接続するための表示アダプタ36を装備している。ワークステーションには、アップル社System/7（登録商標）オペレーティング・システムなどのオペレーティング・システムが置かれている。ドキュメント・フレームワーク・アーキテクチャ(document framework architecture)はRAM14に置かれており、CPU10の制御の下で、本発明の好適実施例を実現することを受け持っている。
好適実施例では、本発明は、オブジェクト指向プログラミング技法を使用してC++プログラミング言語で書かれている。この分野に精通しているものならば容易に理解されるように、オブジェクト指向プログラミング(Object-Oriented Programming-OOP)のオブジェクトは、データ構造とデータに対するオペレーション（操作、演算など）からなるソフトウェア・エンティティ(software entity)である。これらのエレメントが協力し合うことにより、オブジェクトは、そのデータ・エレメントで表されたその特性、およびそのデータ操作関数(data manupulation functions)で表されたその作用(behavior)からとらえて、ほとんどどのような実世界のエンティティでもモデル化することができる。この方法によると、オブジェクトは、人やコンピュータなどの具体物をモデル化することができ、また、数や幾何学的概念などの抽象概念をモデル化することができる。オブジェクト・テクノロジの利点は次の３つの基本的原理から得られるものである。それは、カプセル化(encapsulation)、多態(polymorphism)および継承(inheritance)である。
オブジェクトは、そのデータの内部構造とその関数が実行されるときのアルゴリズムを隠蔽する。つまりカプセル化する。これらのインプリメンテーション細部を見せる代わりに、オブジェクトは、外部情報(extraneous information)のないクリーンな形でその抽象化(abstractions)を表しているインタフェースを提示する。多態はカプセル化をさらに一歩進めたものである。この考え方は、多数の形体をもつ、１つのインタフェースである。あるソフトウェア・コンポーネントは、別のコンポーネントがなんであるかを正確に知らなくても、その別のコンポーネントを要求することができる。要求を受け取ったコンポーネントはその要求を解釈し、その要求をどのように実行すべきかを、その変数とデータに従って判断する。三番目の原理である継承によれば、開発者は既存の設計やコードを再利用することができる。この機能を利用すると、開発者はソフトウェアを初めから作ることが回避される。むしろ、継承を通して、開発者は作用を継承するサブクラスを派生し、その作用を開発者独自の要求に合ったものにカストマイズすることができる。
従来のアプローチでは、オブジェクトとクラス・ライブラリを手続き的環境で階層化する方法がとられていた。市販されている多くのアプリケーション・フレームワークはこの設計手法を採用している。この設計では、モノリシック・オペレーティング・システム(monolithic operating system)の上に１つまたは２つ以上のオブジェクト層が置かれている。このアプローチでは、カプセル化、多態および継承のすべての原理がオブジェクト層に採用され、手続き的プログラミング技法を大幅に改善しているが、このアプローチにはいくつかの制約がある。これらの問題は、開発者が自身のオブジェクトを再利用することは容易であるが、他のシステムからのオブジェクトを使用することが困難であるため、手続き的オペレーティング・システム(OS)のコールを使用して、下位の非オブジェクト層まで到達する必要があることに起因している。
オブジェクト指向プログラミングがもつもう１つの側面は、アプリケーションを開発するのにフレームワーク・アプローチを採用していることである。フレームワークの最も合理的な定義の１つとして、イリノイ大学のRalph E.JohnsonとPurdueのVincent F.Russoによるものがある。両氏の1991年の論文「オブジェクト指向設計の再利用」(Reusing Object-Oriented Designs)、イリノイ大学技術報告書UIUCDCS91-1696の中で、次のような定義を提案している。「抽象クラスとは、一組の責任分担を協力し合って実行するオブジェクトの集合を設計したものである。従って、フレームワークとは、組で定義された演算責任分担を協力し合って実行するオブジェクト・クラスが集まったものである。」プログラミング側から見たときは、フレームワークとは、基本的には、実働アプリケーション(working application)の事前に作られた構造を提供する、相互に接続されたオブジェクト・クラスの集まりである。例えば、ユーザ・インタフェース・フレームワークは、描画ウィンドウ(drawing window)、スクロールバー、メニューなどをサポートし、これらの「デフォルト（省略時）」の作用を提供することができる。フレームワークはオブジェクト・テクノロジを基礎にいているので、この作用を継承してオーバライド(override)することにより、開発者はフレームワークを拡張し、カストマイズした解決手法を特定の専門分野で作ることができる。これが従来のプログラミングに比べて大きな利点であるのは、プログラマはオリジナル・コードを変更することなく、むしろソフトウェアを拡張できるからである。さらに、フレームワークは、アーキテクチャに関するガイダンスとモデリングを提供すると同時に、問題領域に特有の個々のアクションを指定することから開発者を解放するので、開発者はいくつかのコード層を通って盲目的に作業する必要がない。
ビジネス側から見たときは、フレームワークは、特定の知識分野において専門知識をカプセル化または具現化する方法と見ることができる。企業の開発集団、独立ソフトウェア・ベンダ(Independent Software Vendors-ISV)およびシステム統合者(systems integrators)は、前述した例のように、製造、会計、通貨取引きといった特定分野における専門知識をもっている。この専門知識はコードで具現化されている。フレームワークを使用すると、企業は、その専門知識を企業のコードで具現化することにより、専門知識の共通特性を取り込んで、パッケージ化することができる。まず、そのようにすると、開発者は専門知識を利用するアプリケーションを作成または拡張できるので、問題がいったん解決されれば、ビジネス・ルールや設計は統一的に実施され、使用されることになる。また、フレームワークと、フレームワークの背景にある具現化された専門知識は、製造、会計、バイオテクノロジといった垂直的マーケットにおいて専門知識を得た企業にとっては、戦略的資産をもつことを意味し、企業の専門知識をパッケージ化し、再販し、流布し、テクノロジの進歩と普及化を促進するための分配メカニズムをもつことになる。
歴史的には、フレームワークがパーソナル・コンピューティング・プラットフォーム上の主流概念として出現したのは、つい最近のことである。この移行を助長したのが、C++といったオブジェクト指向言語の出現である。従来までは、C++は大部分がUNIXシステムと研究者のワークステーション上に搭載され、コマーシャル・ベースのパーソナル・コンピュータには搭載されていなかった。いくつかの大学や研究所のプロジェクトが今日の商用フレームワークおよびクラス・ライブラリの先駆けとなり得たのは、C++などの言語やSmalltalkなどの他のオブジェクト指向言語のお陰である。その例のいくつかを挙げると、スタンフォード大学のInterViews、カーネギ・メロン大学のAndrewツールキット、チューリッヒ大学のET++フレームワークがある。
フレームワークは、どのレベルのシステムに関心があり、どのような問題を解決しようとしているかに応じて、多種類のものがある。フレームワークの種類はユーザ・インタフェースの開発を支援するアプリケーション・フレームワークから、通信、印刷、ファイル・システム・サポート、グラフィックスなどの基本的システム・ソフトウェア・サービスを提供する低レベルのフレームワークまでにわたっている。商用化されているアプリケーション・フレームワークの例をいくつか挙げると、MacApp(Apple)、Bedrock(Symantec)、OWL(Borland)、NeXtStep App Kit(NeXT)、Smalltak-80 MVC(ParcPlace)がある。
フレームワークでプログラミングを行うには、他の種類のシステムに慣れている開発者は考え方を変える必要がある。確かに、このプログラミングは、従来考えられていたプログラミングとはまったく異なっている。DOSやUNIXなどの旧スタイルのオペレーティング・システムでは、開発者自身のプログラムが構造全体になっている。オペレーティング・システムはシステム・コール(system call)を通してサービスを提供している。つまり、開発者のプログラムはサービスの必要時にコールを行い、サービスが提供されたとき制御が返却される。プログラム構造は制御の流れに基礎を置き、これは開発者が書いたコードに具現化されている。
フレームワークが使用されるときは、これとは反対である。開発者は制御の流れに責任をもつ必要がなくなる。開発者は、プログラミング・タスクを実行の流れから把握して理解しようとする癖を止めなければならない。むしろ、オブジェクトの責任分担からとらえて思考する必要があるので、タスクをいつ実行させるかを判断するには、フレームワークに頼らざるを得なくなる。開発者が書いたルーチンは、開発者が書かなかった、従って開発者には見えないコードによってアクチベート(activate−活性化)される。この制御の流れのフリップフロップは、手続き的プログラミングだけに経験のある開発者にとっては、大きな心理的障壁となっている。しかし、このことをいったん理解してしまえば、フレームワーク・プログラミングによると、他のタイプのプログラミングによる場合よりも作業量が大幅に減少することになる。
アプリケーション・フレームワークが開発者にプレハブの機能を提供するのと同じように、本発明の好適実施例に含まれているようなシステム・フレームワークはシステム・レベルのサービスを提供することによって同じ考え方をてこにしている。つまり、システム・プログラマといった開発者は、システム・レベルのサービスをサブクラス化またはオーバライドして、カストマイズした解決手法を作成することができる。例えば、オーディオ、ビデオ、MIDI、アニメーションなどの新規なデバイスや異種デバイスをサポートする基礎を提供できるマルチメディア・フレームワークについて考えてみることにする。新しい種類のデバイスをサポートする必要がある場合、開発者はデバイス・ドライバを書くことが必要になる。フレームワークでこれを行う場合は、開発者に要求されることは、その新デバイスに特有の特性と作用を指定するだけである。
この場合の開発者は、マルチメディア・フレームワークから呼び出されるある種のメンバ関数(member functions)のインプリメンテーションを用意することになる。開発者にとってすぐに利点となることは、デバイスのカテゴリ別に必要になる汎用コード(generic code)がマルチメディア・フレームワークにすでに用意されていることである。このことは、デバイス・ドライバ開発者が書き、テストし、デバッグするコードが少なくなることを意味する。システム・フレームワークを使用するもう１つの例は、SCSIデバイス、NuBusカード、およびグラフィックス・デバイス別のI/Oフレームワークを持つ場合である。機能は継承されるので、各フレームワークには、そのデバイス・カテゴリに見られる共通機能に対するサポートが用意されている。この場合、他の開発者は、これらの統一インタフェース(consistent interfaces)を通して、あらゆる種類のデバイスにアクセスすることが可能になる。
協同モデル
固有の協同モデル(inherent collaboration model)は特定のプレース・オブジェクトの関数と通信スタイルをサポートしている。特に、好適実施例によれば、次の協同モデルをサポートすることが可能である。すなわち、(i)スクリーン共有(screen sharing)、(ii)注釈マージング(annotation merging)、(iii)ドキュメント・マージング(document merging)である。従って、ユーザは、作成されるプレース・オブジェクトに合った協同モデルを選択することができる。
これらの３つの協同モデルを使用すると、ユーザは異なった方法でオブジェクトにアクセスすることができる。ユーザは、スクリーン共有協同モデルを使用すると、オブジェクトをリアルタイム（実時間）で見ることができる。これとは対照的に、注釈マージングとドキュメント・マージング協同モデルを使用すると、あるオブジェクトの異なる部分を同時にアクセスすることができる。
ある種のプレース・オブジェクトは固有の協同スタイル(intrinsic collaboration 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 hierarchy)を構築することができる。言い換えれば、ユーザは、情報がファイル・システムのどこに、あるいはどのようにストアされているかに関係なく、情報を自由に編成してワークスペースに置いておくことができる。コンテナは複数のボリュームにまたがることができる。すべてのボリュームが利用できないと、利用できないオブジェクトは表示されないか、あるいはぼかされて(gray out)表示される。コンテナ自体、つまり、包含階層のルート(root)はその格納プレース(enclosing place)に残されており、そのプレースと同じ記憶ドメイン(storage domain)(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およびTerryという名前の３人のユーザが共有している。共有ユーザの各々は、それぞれ402,404,406に示すホームプレース・オブジェクトを所有している。さらに、ホームプレース・オブジェクト404(Johnのホームプレース・オブジェクト)はサブプレース・オブジェクト408(Johnのワークプレース・オブジェクト)と410(Johnのアートプレース(Art Place)オブジェクト)に再分割されている。
ワークステーションには、特定のユーザと関連づけられていない他のプレース・オブジェクトを置いておくことも可能である。そのようなプレース・オブジェクトとしては、好ましくは、ゲスト・プレース・オブジェクト(guest place object)、ログイン・プレース・オブジェクト(log-in place object)、システム保守プレース・オブジェクト(system maintenance place object)、転送プレース・オブジェクト(transfer place object)などがある。ゲストまたは公開(public)プレース・オブジェクトは、ワークステーションに知らされていないユーザによるアクセスを可能にする。ログイン・プレース・オブジェクトは、オブジェクトとユーザ・セッションの開始に関する情報とを収めている。システム保守プレース・オブジェクトはユーザが保守タスクを実行することを可能にし、マシン・ルームを収めている。マシン・ルームはワークステーションに関する持続的構成情報を収めており、特定のユーザと関連づけられていない場合がある。転送プレース・オブジェクトは、情報をストアし・ワークステーションのユーザ間で情報を転送することを可能にする。
プレース・オブジェクトのアクセス
プレース・オブジェクトをアクセスし、その間でナビゲートするには、いくつかの方法がある。例えば、(i)資源ブック(resource book)による方法、(ii)マップ表現の内部での方法、(iii)ポストカードなどのプレースへの参照の使用による方法、(iv)インビテーション（invitation：招待状）による方法がある。
資源ブックにより、ブックのコンテキスト内で情報をユーザに提示して、プレース・オブジェクトへアクセスすることができる。通信ブック(communication book)に収められている情報は、名前サービス・ディレクトリ(name service directory)内に存在する、資源と呼ばれるオブジェクトに関するものである。従って、資源ブックを通してアクセスできる資源には、人やプレースなどのオブジェクトが含まれる。このため、資源ブックは、プレース・オブジェクトを探し出してアクセスするときの手段となる。
資源ブック内には、資源ブック内のプレース・オブジェクトに関する１つまたは２つ以上のタブがあり、そこにはプレース・オブジェクトを記述した情報が入っている。そのような情報には、プレース・オブジェクト内に置かれたオブジェクト、およびプレース・オブジェクトをアクセスするときのコストを含めることができる。資源ブックによると、プレース・オブジェクトが見つけやすくなり、そのあとで、ユーザはそのプレース・オブジェクトを持続的参照(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 MEETING”に関する情報を収めている。このインビテーションを転送する人、ミーティングの時刻、ミーティングの場所、および指名したゲストに関する情報も、それぞれ参照符号506,508,510,512で示すように、このインビテーションに示されている。
必要とするプレース・オブジェクトが見つかったとき、ユーザはサブプレースであるプレース・オブジェクト間をナビゲートしなければならない。プレース・オブジェクトの設計者が選択するナビゲーション方法は、プレース・オブジェクトの重要な特性である。プレース・オブジェクトは階層になっているので、ユーザは、プレース・オブジェクトが深いネスト構造(deep nested structure)にあるのか、浅い構造(shallowstructure)にあるのかを知っている必要がある。深いネストは、ユーザが連続するサブプレース・オブジェクトをオープンしていくか、あるいは参照を使用して深いネストのプレース・オブジェクトまで到達しなければならないことを意味する場合がある。これに対して、多数のエレメントからなる浅い構造は空間的により多くのスペースを占めるので、潜在的には、ユーザにより多くの選択項目をよりハイレベルで与えることができる。従って、作成者が選択するナビゲーション方法は、到達しようとするプレース・オブジェクトの構造によって決まる。
好ましくは、スケーリング方法(scaling method)とパンニング方法(panning method)を併用すると、デスクトップ・ディスプレイ内でナビゲートすることができる。あるプレース・オブジェクトを均一にスケーリングするには、アスペクト比（aspect ratio：横縦比）を一定に保ちながら、プレース・オブジェクトの寸法を拡大または縮小する。スケーリングは、ズームしてドキュメントやプレース・オブジェクト・ビューに入ったり、そこから出たりするユーザにとっても重要である。プレース・オブジェクトが正しくスケーリングされたあと、パンニングを使用すると、プレース・オブジェクト内をナビゲートすることができる。パンニングを行うときは、プレース・オブジェクトの特定部分を表示するように、グラフィック・カーソル(graphic cursor)を動かしながら手操作でデスクトップに指示する。パンニング・グラフィックをドラグすることにより、ユーザはデスクトップの他の領域をビューに移動する。
別の方法として、好適実施例では、スクローリングや自動パンニング(auto-panning)またはディストーティング(distorting)方法を使用して、プレース・オブジェクト内をナビゲートしている。自動パンニングはホットゾーン(hot-zone)（通常は、デスクトップのエッジを取り巻くエリアであるが）に入り込むカーソルの動きを検出して、ディスプレイを動きの方向にパンする。システムには、照会(query)により、あるプレース・オブジェクトを見つけたり、プレース・オブジェクトのある内容を見つけるためのメカニズムも、ユーザのために用意されている。
アクセス制限
プレース・オブジェクト内のセキュリティとアクセス制御を実現するには、いくつかの方法がある。第一は、一組のアクセス権をプレース・オブジェクトと関連づける方法である。この方法によると、その組のアクセス権の範囲にあるユーザは、だれもプレース・オブジェクトをアクセスすることが許される。第二は、あるプレース・オブジェクトへの最低限のアクセス権を指定した人に与える方法である。しかし、増加したアクセス権がプレース・オブジェクト内に包含されたオブジェクトと関連づけられることになる。第三は、プレース・オブジェクトを必要とする個人とグループを指定して、アクセス権を割り当てる方法であるが、これらの権利はプレース・オブジェクトとそこに包含されるオブジェクト全体に適用されることになる。これらのルールによると、個別のファイル管理を必要としないで、プレース・オブジェクト内に異なる共有レベルをもたせることができる。
アクセスを制限する別の方法として、プレース・オブジェクトをアクセスするユーザに費用を負担させることが可能である。従って、プレース・オブジェクトはサービスを提供する手段として利用することができる。そのようなサービスには、ダウジョーンズ(Dow Jonesのような情報サービス、ウォールストリート・ジャーナル(Wall Street Journal)のようなニュース・サービス、購買サービスおよびAmerica On-Lineのような収集プレース・オブジェクトを含めることが可能である。プレース・オブジェクトは、サービスを提供し、サービスへのアクセスを制限するように構築することができる。
ユーザがあるプレース・オブジェクトに入ったときの費用を計算するモデルがいくつか用意されている。具体的には、費用は、
(i)プレース・オブジェクトへのアクセス
(ii)プレース・オブジェクトのアクセス時間
(iii)あるプレース・オブジェクト内でアクセスされたオブジェクトの数
(iv)一定額の費用または申込み金
(v)あらかじめ決めた使用制限
(vi)これらの任意の組合せ
の任意の１つまたは組合せに基づいて計算することができる。
好ましくは、発生した費用と潜在的費用の通知は、あるプレース・オブジェクトにアクセスするとユーザに表示される。さらに、オペレーションが高価になるおそれがあることは、ユーザに事前に警告される。さらに、ユーザは、あるプレース・オブジェクトの最大費用を指定することができる。最大費用に達すると、ユーザに通知されるので、ユーザはそのプレース・オブジェクトから出るか、それとも将来発生する追加費用を負担するかを選択することができる。
プレース・オブジェクトのビジュアル表現
プレース・オブジェクトのビジュアル表現は、ロケーション感(sense of location)を作る上で重要である。従って、プレース・オブジェクトは、背景イメージ、レイアウト、スケール、デザイン・スタイル、空間ボリューム(spatial volume)、照明効果および文字体裁(typography)といった、いくつかのエレメントに関して設計することができる。好適実施例では、これらのエレメントを組み合わせて、識別性(distinctive)があり、ナビゲーションを容易にする環境を作成している。
プレース・オブジェクトに適用される背景イメージは、リードオンリ・モデル(read-only model)を通して作成することができる。これには、移動するイメージや、現在時刻を基準にしてそのプレゼンテーションを変更する夜間／昼間プレース・オブジェクトのように、データ駆動(data-driven)のイメージが含まれる。さらに、プレース・オブジェクトの背景イメージをぼかすと、背景イメージと、ディスプレイの最前部のウィンドウやオブジェクト・アイコンなどのアイテム（項目）との間の奥行き(depth stratification)を追加することができる。また、彩度(saturation)を利用すると、前景アイテムと背景イメージの間に独特のスタイルを作ることもできる。
プレース・オブジェクトの密度とレイアウトは、プレース・オブジェクトが満足のいくように反映されるように適応される。プレース・オブジェクトがリードオンリ・アクセスだけを許しているのでなければ、ユーザがプレース・オブジェクトに加えたレイアウト変更はセーブ（格納）され、リターン時にリストア（復元）される。背景イメージと、プレース・オブジェクトの寸法スケールおよび寸法比との関係により、ユーザのスコープ感(sense of scope)が設定される。従って、小さい、遠のいて行くプレース・オブジェクトは距離を示し、大きいプレース・オブジェクトはプレース・オブジェクトの広がりを表している。
プレース・オブジェクトの空間ボリュームは、プレース・オブジェクトの表現に不可欠である。プレース・オブジェクト内のオブジェクトの選択、配置およびレンダリング(rendering)はユーザが使用できるオプションの範囲を示している。プレース・オブジェクトには、ユーザに理解しやすいものと、オープンと読取りによって詳細分析を必要とするものがある。それにもかかわらず、プレース・オブジェクトは、プレース・オブジェクトに収められたエレメントを調べると、容易に区別することができる。さらに、空間の奥行きと対話によるナビゲーション方法はプレース・オブジェクトの特性になっている。空間仮想現実(spatial virtual realities)を実現すると、三次元入力デバイスの使用とナビゲーションが可能になる。
照明と文字体裁のエレメントは、各プレース・オブジェクトに独特の特性をもたせる上で役に立つ。プレース・オブジェクトは、プレース・オブジェクトの特定の側面に焦点を当てて設計することができる。大きなサイズで使用される表示タイプフェースのような、文字体裁を利用すると、プレース・オブジェクトに独特の特徴をもたせることが可能である。
プレース・オブジェクト以外のオブジェクト
プレース・オブジェクトとワークスペースに置かれる他のタイプのオブジェクトの中では、プレース・オブジェクトが最高レベル・オブジェクトである。従って、フォルダのようなコンテナ・オブジェクトを含んでいる典型的なオブジェクトが現れるのは、プレース・オブジェクトのコンテキスト内である。さらに、フォルダのようなコンテナ・オブジェクトはプレース・オブジェクトを収容することができない。コンテナ・オブジェクトは、ポストカードのようなプレース・オブジェクトを指す参照だけを収容することができる。
プレース・オブジェクトは他のオブジェクトを多数収容することができる。そのようなオブジェクトとしては、ドキュメント、コンテナ、器具、ツール、文房具、および人を指す参照などがある。プレース・オブジェクトは、サブプレース・オブジェクトと呼ばれる他のオブジェクトを収容することも可能である。プレース・オブジェクトは他のプレース・オブジェクトを指す参照を収容することもできる。従って、プレース・オブジェクトの階層は、関連のオブジェクトをさらに再分割できるように維持することができる。
好適実施例では、共有プレース・オブジェクトのワークスペース内に挿入できるオブジェクトの作成が可能である。例えば、掲示板(bulletin board)をプレース・オブジェクト内に挿入しておくと、プレース・オブジェクトをアクセスした人は、お互いに情報をやりとりすることができる。さらに、ビジネス・カード(business card：名刺)をプレース・オブジェクト内に挿入しておくと、ある人はビジネス・カードで表された人と連絡することができる。
好適実施例では、ユーザは２つの方法で、プレース・オブジェクトをナビゲートしている間に、選択したオブジェクトをアクセスできる。２つの方法とは、ポータブル・コンテナ(portable container)とワークスペース・シェルフ(workspace 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)コピー、(iii)参照の移動、(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)である。ラベル1200は協同作業(collaboration)の例を示している。ラベル1210はオブジェクトの作成例を示している。ラベル1220は間接的協同作業(indirect collaboration)の例を示している。最後に、ラベル1230は包含(containment)の例を示している。第13図は好適実施例によるBoochダイアグラムである。
論理的には、プレースは、アトミック(atomic)に操作できる自己完結環境(self-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)内のコンテナはあるプレースで専用され、空間ビュー(spatialview)内のコンテナは別のプレースで専用される。プレースとプレース・プレゼンテーションのどちらも、どのドキュメントがそのプレースでオープンしているかの情報を維持していなければならない。
ユーザと一緒にストアされるユーザ固有のプレゼンテーション
第22図は、ドキュメント・プレゼンテーション・ステートを維持するためにユーザ情報と一緒にストアされているオブジェクトを示している。大きなモデル・ストアは、プレース上のセーブされたプレゼンテーションとユーザ・ドキュメント上のプレゼンテーションが共にそこに存在することを示している。カタログはドキュメントと、プレースの特定プレゼンテーションとの対応関係（マッピング）を示している。これらが使用されるのは、ユーザがドキュメントをオープンするときであり、これにより、正しいプレゼンテーションが使用されるようになる。ユーザのスペース内では、選好情報と最近の活動記録(history)情報のための記憶域は、人(people)サブシステムが提供する。プレゼンテーション自体は、それを参照するカタログと一緒にここにストアされる。カタログは、ユーザ選好MPreferenceCollectionオブジェクトが提供するディクショリナリ・セマンティック(dictionary semantics)を使用する。
・ 各人はプレース上に１つのプレゼンテーションをもち、そこには、最後に表示されたときの、そのプレースをユーザに提示するのに必要な一切の情報が収められている。この情報は、プレース内のオープン・ドキュメントのリストを含んでいる（プレゼンテーション代用物として表現され、可能ならば、データ・モデルIDが一緒に付いて表現されている）。
・ 各人は、複数のプレゼンテーションを１つのドキュメント上にセーブしておくことができる。各人は、それが表示される各プレースごとに異なるプレゼンテーションをもつことができる。
ドキュメント・プレゼンテーション情報のカタログはドキュメントを、それらが表示されたプレース用に存在する既存のセーブされたプレゼンテーションと対応づける。このカタログに入っている情報は、キー、プレースID、およびプレゼンテーションのプレゼンテーション代用物として、モデルID（グローバルID）だけを必要とするドキュメントである。
プレース・プレゼンテーションには、ドキュメントがいつ初めてオープンされたか、といったドキュメントに関する情報が、次回にプレースに入ったときステートを正しく復元するために必要である。そのためには、ウィンドウ・プレゼンテーションがプレースでいつオープンされたかの通知を受け取る必要がある。これは、次のようなプロジージャを通して行われる。
・ オープン／クローズ／フォロー・コマンドはすべて、ドキュメントをオープンし、クローズする作業を包含ポリシ・オブジェクト(contained policy object)に委任する形体のモデル・コマンドを使用する。第23図は、好適実施例に従ってプレース・ドキュメント・ポリシを採用するコマンド・サブクラスを示すBoochダイアグラムである。ラベル2310は好適実施例に従ってドキュメントをオープンするモデル・コマンドを示している。ラベル2320は2310に示したコマンドであって、プレース・ドキュメント・ポリシ・オブジェクトに委任するモデル・コマンドのサブクラスを示している。ラベル2330は、2320で使用されたドキュメント・ポリシをメモリにストアするmixinクラスである。すべてのプレース固有モデル・コマンドはラベル2330のオブジェクトからのサブクラスである。ラベル2340は、その前に置かれたオブジェクトに示されているオペレーションを実行するポリシ・オブジェクトである。
・ ポリシ・オブジェクトは、このプレースに対して行おうとしているタイプの作用(behavior)を包括している。この作用は協同プレースでは異なり、異なるヒューマン・インタフェースが必要な場合も異なる。
・ 各コンテナまたはドキュメント・プレゼンテーションがその“オープン”コマンドをメニューに登録するときは、これらのオープン委任コマンド(delegating 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 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図に示されている。
Claims (18)
- プロセッサ、メモリおよびディスプレイ装置を有するコンピュータ・システムを使用して、プレース、人およびそのプレースに存在する情報の視覚的表現を提供する方法において、
(a)前記プロセッサを制御して、前記メモリに人オブジェクトを生成し、各々の人を表すステップであって、前記人オブジェクトは、人がオープンした各ドキュメントについて有するカタログを含み、プレースＩＤは、オープンされた前記ドキュメントがどこのプレースにあるかを示し、ユーザ固有のプレゼンテーション情報は、前記ドキュメントについてドキュメントの内容の情報を、どのように前記ディスプレイ装置に視覚的に表示すべきかを示すステップと、
(b)前記プロセッサを制御して、前記メモリにプレース・オブジェクトを生成し、前記プレースを表すステップであって、前記プレース・オブジェクトは、ドキュメントおよび人オブジェクトに対するコンテナとして動作し、視覚的表示を特定するプレース・プレゼンテーション情報を含み、前記ディスプレイ装置に前記プレースを表すステップと、
(c)プレース・オブジェクトの生成に応答して、プレースを表すプレース・オブジェクトにおける前記プレース・プレゼンテーション情報で前記表示を制御し、前記プレースの表現を視覚的に表示するステップと、
(d)前記プレース・プレゼンテーション情報を使用して、前記プロセッサを制御して、前記プレースでオープンされた全てのドキュメントをオープンするステップと、
(e)前記人に関連付けられた人オブジェクトに含まれるカタログを使用して、各々のオープンされたドキュメントに対するユーザ固有のプレゼンテーション情報で前記表示を制御し、前記プレースに特有の方法により前記ドキュメントを表示するステップと
を備えたことを特徴とする方法。 - 請求項１に記載の方法において、(b)ステップにおいて、前記プレース・オブジェクトは、他のプレース・オブジェクトを含むことを特徴とする方法。
- 請求項１に記載の方法において、(b)ステップにおいて、前記プレース・オブジェクトは、前記プレースに対する作用を特定するポリシ・オブジェクトを含み、前記特定された作用に関連付けられたドキュメントをオープンし、クローズするドキュメントオープンコマンドおよびドキュメントクローズコマンドを含むことを特徴とする方法。
- 請求項３に記載の方法において、(d)ステップは、前記プレース・プレゼンテーション情報を使用して、ユーザが前記プレース・オブジェクトにより表されたプレースに入る場合に、各々のドキュメントにオープンコマンドを発行するステップを備えたことを特徴とする方法。
- 請求項４に記載の方法において、(d)ステップにおいて、ドキュメントに対する各オープンコマンドは、前記ポリシ・オブジェクトにおける前記オープンコマンドを使用して、前記特定された作用に関連付けられたドキュメントをオープンすることを特徴とする方法。
- 請求項５に記載の方法において、(e)ステップは、前記ポリシ・オブジェクトにおける前記オープンコマンドを使用して、前記カタログにおける前記ユーザ固有のプレゼンテーション情報を使用して前記表示を制御し、前記特定された作用に関連付けられた各々のオープンされたドキュメントについてドキュメントの内容の情報を表示するステップを備えたことを特徴とする方法。
- 請求項６に記載の方法において、前記ユーザ固有のプレゼンテーション情報は、前記表示されたドキュメントの内容の情報の作用を特定するポリシ・オブジェクトを含み、(e)ステップは、前記プレース・オブジェクトの前記ポリシ・オブジェクトを使用して、前記ユーザ固有のプレゼンテーション情報における前記ポリシ・オブジェクトを設定し、前記プレース・オブジェクトにおける前記ポリシ・オブジェクトと同じにすることを特徴とする方法。
- 請求項３に記載の方法において、(d)ステップは、前記ポリシ・オブジェクトを使用して、前記プレース・プレゼンテーション情報でドキュメントのオープンを登録するステップを備えたことを特徴とする方法。
- 請求項８に記載の方法において、前記プレース・プレゼンテーション情報は、オープンするドキュメントのリストを含み、(d)ステップにおいて、前記ドキュメントのオープンの登録は、前記オープンするドキュメントのリストを更新することを特徴とする方法。
- プロセッサ、メモリおよびディスプレイ装置を有するコンピュータ・システムを使用して、プレース、人およびそのプレースに存在する情報の視覚的表現を提供する装置において、
前記プロセッサを制御して、前記メモリに人オブジェクトを生成し、各々の人を表す手段であって、前記人オブジェクトは、人がオープンした各ドキュメントについて有するカタログを含み、プレースＩＤは、オープンされた前記ドキュメントがどこのプレースにあるかを示し、ユーザ固有のプレゼンテーション情報は、前記ドキュメントについてドキュメントの内容の情報を、どのように前記ディスプレイ装置に視覚的に表示すべきかを示す手段と、
前記プロセッサを制御して、前記メモリにプレース・オブジェクトを生成し、前記プレースを表す手段であって、前記プレース・オブジェクトは、ドキュメントおよび人オブジェクトに対するコンテナとして動作し、視覚的表示を特定するプレース・プレゼンテーション情報を含み、前記ディスプレイ装置に前記プレースを表す手段と、
プレース・オブジェクトの生成に応答して、プレースを表すプレース・オブジェクトにおける前記プレース・プレゼンテーション情報で前記表示を制御し、前記プレースの表現を視覚的に表示する手段と、
前記プレース・プレゼンテーション情報を使用して、前記プロセッサを制御して、前記プレースでオープンされた全てのドキュメントをオープンする手段と、
前記人に関連付けられた人オブジェクトに含まれるカタログを使用して、各々のオープンされたドキュメントに対するユーザ固有のプレゼンテーション情報で前記表示を制御し、前記プレースに特有の方法により前記ドキュメントを表示する手段と
を備えたことを特徴とする装置。 - 請求項１０に記載の装置において、前記プレース・オブジェクトは、他のプレース・オブジェクトを含むことを特徴とする装置。
- 請求項１０に記載の装置において、前記プレース・オブジェクトは、前記プレースに対する作用を特定するポリシ・オブジェクトを含み、前記特定された作用に関連付けられたドキュメントをオープンし、クローズするドキュメントオープンコマンドおよびドキュメントクローズコマンドを含むことを特徴とする装置。
- 請求項１２に記載の装置において、前記プレース・プレゼンテーション情報を使用して、ドキュメントをオープンする手段は、前記プレース・プレゼンテーション情報を使用して、ユーザが前記プレース・オブジェクトにより表されたプレースに入る場合に、各々のドキュメントにオープンコマンドを発行する手段を備えたことを特徴とする装置。
- 請求項１３に記載の装置において、ドキュメントに対する各オープンコマンドは、前記ポリシ・オブジェクトにおける前記オープンコマンドを使用して、前記特定された作用に関連付けられたドキュメントをオープンすることを特徴とする装置。
- 請求項１４に記載の装置において、カタログを使用して前記表示を制御する手段は、前記ポリシ・オブジェクトにおける前記オープンコマンドを使用して、前記カタログにおける前記ユーザ固有のプレゼンテーション情報を使用して前記表示を制御し、前記特定された作用に関連付けられた各々のオープンされたドキュメントについてドキュメントの内容の情報を表示する手段を備えたことを特徴とする装置。
- 請求項１５に記載の装置において、前記ユーザ固有のプレゼンテーション情報は、前記表示されたドキュメントの内容の情報の作用を特定するポリシ・オブジェクトを含み、カタログを使用して前記表示を制御する手段は、前記プレース・オブジェクトの前記ポリシ・オブジェクトを使用して、前記ユーザ固有のプレゼンテーション情報における前記ポリシ・オブジェクトを設定し、前記プレース・オブジェクトにおける前記ポリシ・オブジェクトと同じにすることを特徴とする装置。
- 請求項１２に記載の装置において、前記プレース・プレゼンテーション情報を使用する手段は、前記ポリシ・オブジェクトを使用して、前記プレース・プレゼンテーション情報でドキュメントのオープンを登録する手段を備えたことを特徴とする装置。
- 請求項１７に記載の装置において、前記プレース・プレゼンテーション情報は、オープンするドキュメントのリストを含み、前記ドキュメントのオープンを登録する手段は、前記オープンするドキュメントのリストを更新することを特徴とする装置。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US7183593A | 1993-06-03 | 1993-06-03 | |
| US08/071,835 | 1993-06-03 | ||
| PCT/US1994/000196 WO1994029803A1 (en) | 1993-06-03 | 1994-01-06 | Place object system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH08511117A JPH08511117A (ja) | 1996-11-19 |
| JP3798015B2 true JP3798015B2 (ja) | 2006-07-19 |
Family
ID=22103900
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP50171995A Expired - Lifetime JP3798015B2 (ja) | 1993-06-03 | 1994-01-06 | プレース・オブジェクト・システム |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US5634129A (ja) |
| EP (1) | EP0689698B1 (ja) |
| JP (1) | JP3798015B2 (ja) |
| CN (1) | CN1110066A (ja) |
| AU (1) | AU6022094A (ja) |
| CA (1) | CA2141931A1 (ja) |
| DE (1) | DE69406277D1 (ja) |
| WO (1) | WO1994029803A1 (ja) |
Families Citing this family (78)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5838906A (en) | 1994-10-17 | 1998-11-17 | The Regents Of The University Of California | Distributed hypermedia method for automatically invoking external application providing interaction and display of embedded objects within a hypermedia document |
| US6212575B1 (en) * | 1995-05-05 | 2001-04-03 | Apple Computer, Inc. | Extensible, replaceable network component system |
| US7047241B1 (en) * | 1995-10-13 | 2006-05-16 | Digimarc Corporation | System and methods for managing digital creative works |
| US6807534B1 (en) * | 1995-10-13 | 2004-10-19 | Trustees Of Dartmouth College | System and method for managing copyrighted electronic media |
| US5923846A (en) * | 1995-11-06 | 1999-07-13 | Microsoft Corporation | Method of uploading a message containing a file reference to a server and downloading a file from the server using the file reference |
| US5960173A (en) * | 1995-12-22 | 1999-09-28 | Sun Microsystems, Inc. | System and method enabling awareness of others working on similar tasks in a computer work environment |
| JPH09212497A (ja) * | 1996-02-05 | 1997-08-15 | Ricoh Co Ltd | データ処理装置 |
| US5818442A (en) * | 1996-04-30 | 1998-10-06 | Intel Corporation | Method and apparatus for modeling business card exchanges in an international electronic conference |
| GB2315343A (en) * | 1996-06-25 | 1998-01-28 | Texas Instruments Inc | Non-model-based application transitioning |
| JPH1021261A (ja) * | 1996-07-05 | 1998-01-23 | Hitachi Ltd | マルチメディアデータベース検索方法及びシステム |
| US5897670A (en) * | 1996-07-12 | 1999-04-27 | Sun Microsystems, Inc. | Method and system for efficient organization of selectable elements on a graphical user interface |
| US6041312A (en) * | 1997-03-28 | 2000-03-21 | International Business Machines Corporation | Object oriented technology framework for accounts receivable and accounts payable |
| US6708222B1 (en) * | 1997-05-01 | 2004-03-16 | Microsoft Corporation | Method and system for locating enclosing owners of embedded objects |
| US6275225B1 (en) | 1997-10-24 | 2001-08-14 | Sun Microsystems, Inc. | Method, apparatus, system and computer program product for a user-configurable graphical user interface |
| US6219669B1 (en) * | 1997-11-13 | 2001-04-17 | Hyperspace Communications, Inc. | File transfer system using dynamically assigned ports |
| US6208659B1 (en) * | 1997-12-22 | 2001-03-27 | Nortel Networks Limited | Data processing system and method for providing personal information in a communication network |
| US6058395A (en) * | 1998-01-29 | 2000-05-02 | Buzaglo; Jacques | Computerized communication system for managing multi-disciplinary engineering virtual community |
| US6058416A (en) * | 1998-05-22 | 2000-05-02 | International Business Machines Corportion | Flexible state sharing and consistency mechanism for interactive applications |
| US6195685B1 (en) | 1998-05-22 | 2001-02-27 | International Business Machines Corporation | Flexible event sharing, batching, and state consistency mechanisms for interactive applications |
| US6611954B1 (en) * | 1998-06-03 | 2003-08-26 | Intel Corporation | Binary compatible software objects |
| US6157392A (en) * | 1998-07-20 | 2000-12-05 | Micron Technology, Inc. | Animation packager for an on-line book |
| US6510452B1 (en) * | 1998-08-21 | 2003-01-21 | Nortel Networks Limited | System and method for communications management with a network presence icon |
| US6618852B1 (en) | 1998-09-14 | 2003-09-09 | Intellichem, Inc. | Object-oriented framework for chemical-process-development decision-support applications |
| US6845370B2 (en) | 1998-11-12 | 2005-01-18 | Accenture Llp | Advanced information gathering for targeted activities |
| US7043529B1 (en) * | 1999-04-23 | 2006-05-09 | The United States Of America As Represented By The Secretary Of The Navy | Collaborative development network for widely dispersed users and methods therefor |
| US6532488B1 (en) * | 1999-01-25 | 2003-03-11 | John J. Ciarlante | Method and system for hosting applications |
| GB2368665A (en) * | 2000-03-02 | 2002-05-08 | Outersonic Ltd | On-line multimedia product catalogue |
| US7624172B1 (en) | 2000-03-17 | 2009-11-24 | Aol Llc | State change alerts mechanism |
| WO2001072002A2 (en) * | 2000-03-17 | 2001-09-27 | America Online, Inc. | Shared groups rostering system |
| US9246975B2 (en) | 2000-03-17 | 2016-01-26 | Facebook, Inc. | State change alerts mechanism |
| US7085773B2 (en) * | 2001-01-05 | 2006-08-01 | Symyx Technologies, Inc. | Laboratory database system and methods for combinatorial materials research |
| US7366990B2 (en) | 2001-01-19 | 2008-04-29 | C-Sam, Inc. | Method and system for managing user activities and information using a customized computer interface |
| US7024662B2 (en) | 2001-03-14 | 2006-04-04 | Microsoft Corporation | Executing dynamically assigned functions while providing services |
| US20020133535A1 (en) * | 2001-03-14 | 2002-09-19 | Microsoft Corporation | Identity-centric data access |
| US6985958B2 (en) * | 2001-03-14 | 2006-01-10 | Microsoft Corporation | Messaging infrastructure for identity-centric data access |
| US7284271B2 (en) | 2001-03-14 | 2007-10-16 | Microsoft Corporation | Authorizing a requesting entity to operate upon data structures |
| US7302634B2 (en) | 2001-03-14 | 2007-11-27 | Microsoft Corporation | Schema-based services for identity-based data access |
| US7539747B2 (en) * | 2001-03-14 | 2009-05-26 | Microsoft Corporation | Schema-based context service |
| US6968538B2 (en) * | 2001-06-01 | 2005-11-22 | Symyx Technologies, Inc. | System and methods for integration of custom classes into pre-existing objects models |
| US7062533B2 (en) * | 2001-09-20 | 2006-06-13 | International Business Machines Corporation | Specifying monitored user participation in messaging sessions |
| US7013466B2 (en) * | 2002-03-07 | 2006-03-14 | International Business Machines Corporation | Method and system for supporting object oriented programming class replacement |
| US7711847B2 (en) | 2002-04-26 | 2010-05-04 | Sony Computer Entertainment America Inc. | Managing users in a multi-user network game environment |
| US6645547B1 (en) * | 2002-05-02 | 2003-11-11 | Labcoat Ltd. | Stent coating device |
| US7709048B2 (en) * | 2002-05-02 | 2010-05-04 | Labcoat, Ltd. | Method and apparatus for coating a medical device |
| US7048962B2 (en) * | 2002-05-02 | 2006-05-23 | Labcoat, Ltd. | Stent coating device |
| US20030217135A1 (en) | 2002-05-17 | 2003-11-20 | Masayuki Chatani | Dynamic player management |
| US9886309B2 (en) | 2002-06-28 | 2018-02-06 | Microsoft Technology Licensing, Llc | Identity-based distributed computing for device resources |
| US20040010512A1 (en) * | 2002-07-12 | 2004-01-15 | Incursion Technologies, Inc. | Interactive system and method for the dissemination of information on an event |
| US8560707B2 (en) | 2007-10-05 | 2013-10-15 | Sony Computer Entertainment America Llc | Seamless host migration based on NAT type |
| US8131802B2 (en) | 2007-10-05 | 2012-03-06 | Sony Computer Entertainment America Llc | Systems and methods for seamless host migration |
| US8122137B2 (en) | 2002-11-18 | 2012-02-21 | Aol Inc. | Dynamic location of a subordinate user |
| US8965964B1 (en) | 2002-11-18 | 2015-02-24 | Facebook, Inc. | Managing forwarded electronic messages |
| US7590696B1 (en) | 2002-11-18 | 2009-09-15 | Aol Llc | Enhanced buddy list using mobile device identifiers |
| US8005919B2 (en) | 2002-11-18 | 2011-08-23 | Aol Inc. | Host-based intelligent results related to a character stream |
| US8701014B1 (en) | 2002-11-18 | 2014-04-15 | Facebook, Inc. | Account linking |
| US7899862B2 (en) | 2002-11-18 | 2011-03-01 | Aol Inc. | Dynamic identification of other users to an online user |
| US7640306B2 (en) | 2002-11-18 | 2009-12-29 | Aol Llc | Reconfiguring an electronic message to effect an enhanced notification |
| WO2004046867A2 (en) | 2002-11-18 | 2004-06-03 | America Online, Inc. | People lists |
| US7428580B2 (en) | 2003-11-26 | 2008-09-23 | Aol Llc | Electronic message forwarding |
| JP2004258802A (ja) * | 2003-02-24 | 2004-09-16 | Fuji Xerox Co Ltd | 作業空間管理装置 |
| US8117265B2 (en) | 2003-03-26 | 2012-02-14 | Aol Inc. | Identifying and using identities deemed to be known to a user |
| US7653693B2 (en) | 2003-09-05 | 2010-01-26 | Aol Llc | Method and system for capturing instant messages |
| US8825906B2 (en) * | 2003-12-12 | 2014-09-02 | International Business Machines Corporation | Method and system for named collaborative spaces in a collaborative computing environment |
| US8156445B2 (en) * | 2008-06-20 | 2012-04-10 | Microsoft Corporation | Controlled interaction with heterogeneous data |
| US9128479B2 (en) * | 2011-11-11 | 2015-09-08 | Rockwell Automation Technologies, Inc. | Automation control and monitoring system and method |
| US9218685B2 (en) | 2012-06-05 | 2015-12-22 | Apple Inc. | System and method for highlighting a feature in a 3D map while preserving depth |
| US9959327B2 (en) * | 2015-03-23 | 2018-05-01 | Dropbox, Inc. | Creating conversations in shared folder backed integrated workspaces |
| US10471348B2 (en) | 2015-07-24 | 2019-11-12 | Activision Publishing, Inc. | System and method for creating and sharing customized video game weapon configurations in multiplayer video games via one or more social networks |
| US11185784B2 (en) | 2015-10-08 | 2021-11-30 | Activision Publishing, Inc. | System and method for generating personalized messaging campaigns for video game players |
| US10099140B2 (en) | 2015-10-08 | 2018-10-16 | Activision Publishing, Inc. | System and method for generating personalized messaging campaigns for video game players |
| US10108688B2 (en) | 2015-12-22 | 2018-10-23 | Dropbox, Inc. | Managing content across discrete systems |
| US10719807B2 (en) | 2016-12-29 | 2020-07-21 | Dropbox, Inc. | Managing projects using references |
| US10970656B2 (en) | 2016-12-29 | 2021-04-06 | Dropbox, Inc. | Automatically suggesting project affiliations |
| US10402786B2 (en) | 2016-12-30 | 2019-09-03 | Dropbox, Inc. | Managing projects in a content management system |
| US11226939B2 (en) | 2017-12-29 | 2022-01-18 | Dropbox, Inc. | Synchronizing changes within a collaborative content management system |
| US10765952B2 (en) | 2018-09-21 | 2020-09-08 | Sony Interactive Entertainment LLC | System-level multiplayer matchmaking |
| US10695671B2 (en) | 2018-09-28 | 2020-06-30 | Sony Interactive Entertainment LLC | Establishing and managing multiplayer sessions |
| US10657228B1 (en) | 2018-11-06 | 2020-05-19 | Dropbox, Inc. | Technologies for integrating cloud content items across platforms |
Family Cites Families (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA1184305A (en) * | 1980-12-08 | 1985-03-19 | Russell J. Campbell | Error correcting code decoder |
| US4821220A (en) * | 1986-07-25 | 1989-04-11 | Tektronix, Inc. | System for animating program operation and displaying time-based relationships |
| US4885717A (en) * | 1986-09-25 | 1989-12-05 | Tektronix, Inc. | System for graphically representing operation of object-oriented programs |
| US5072412A (en) * | 1987-03-25 | 1991-12-10 | Xerox Corporation | User interface with multiple workspaces for sharing display system objects |
| US4974173A (en) * | 1987-12-02 | 1990-11-27 | Xerox Corporation | Small-scale workspace representations indicating activities by other users |
| US5008853A (en) * | 1987-12-02 | 1991-04-16 | Xerox Corporation | Representation of collaborative multi-user activities relative to shared structured data objects in a networked workstation environment |
| US5038318A (en) * | 1987-12-17 | 1991-08-06 | Square D Company | Device for communicating real time data between a programmable logic controller and a program operating in a central controller |
| US4891630A (en) * | 1988-04-22 | 1990-01-02 | Friedman Mark B | Computer vision system with improved object orientation technique |
| EP0347162A3 (en) * | 1988-06-14 | 1990-09-12 | Tektronix, Inc. | Apparatus and methods for controlling data flow processes by generated instruction sequences |
| US5107443A (en) * | 1988-09-07 | 1992-04-21 | Xerox Corporation | Private regions within a shared workspace |
| US5121478A (en) * | 1988-09-08 | 1992-06-09 | Xerox Corporation | Window system with independently replaceable window functionality |
| US5041992A (en) * | 1988-10-24 | 1991-08-20 | University Of Pittsburgh | Interactive method of developing software interfaces |
| US5159669A (en) * | 1988-12-15 | 1992-10-27 | Xerox Corporation | Automatically creating a second workspace operation record including history data and a unit ID based on a first workspace operation |
| US5133075A (en) * | 1988-12-19 | 1992-07-21 | Hewlett-Packard Company | Method of monitoring changes in attribute values of object in an object-oriented database |
| US5050090A (en) * | 1989-03-30 | 1991-09-17 | R. J. Reynolds Tobacco Company | Object placement method and apparatus |
| US5060276A (en) * | 1989-05-31 | 1991-10-22 | At&T Bell Laboratories | Technique for object orientation detection using a feed-forward neural network |
| US5125091A (en) * | 1989-06-08 | 1992-06-23 | Hazox Corporation | Object oriented control of real-time processing |
| US5181162A (en) * | 1989-12-06 | 1993-01-19 | Eastman Kodak Company | Document management and production system |
| US5093914A (en) * | 1989-12-15 | 1992-03-03 | At&T Bell Laboratories | Method of controlling the execution of object-oriented programs |
| US5075848A (en) * | 1989-12-22 | 1991-12-24 | Intel Corporation | Object lifetime control in an object-oriented memory protection mechanism |
| US5305435A (en) * | 1990-07-17 | 1994-04-19 | Hewlett-Packard Company | Computer windows management system and method for simulating off-screen document storage and retrieval |
| JP2865827B2 (ja) * | 1990-08-13 | 1999-03-08 | 株式会社日立製作所 | 会議システムにおけるデータ蓄積方法 |
| US5261044A (en) * | 1990-09-17 | 1993-11-09 | Cabletron Systems, Inc. | Network management system using multifunction icons for information display |
| US5295244A (en) * | 1990-09-17 | 1994-03-15 | Cabletron Systems, Inc. | Network management system using interconnected hierarchies to represent different network dimensions in multiple display views |
| US5151987A (en) * | 1990-10-23 | 1992-09-29 | International Business Machines Corporation | Recovery objects in an object oriented computing environment |
| US5119475A (en) * | 1991-03-13 | 1992-06-02 | Schlumberger Technology Corporation | Object-oriented framework for menu definition |
| US5315703A (en) * | 1992-12-23 | 1994-05-24 | Taligent, Inc. | Object-oriented notification framework system |
| US5434965A (en) * | 1992-12-23 | 1995-07-18 | Taligent, Inc. | Balloon help system |
| US5446842A (en) * | 1993-02-26 | 1995-08-29 | Taligent, Inc. | Object-oriented collaboration system |
| US5379431A (en) * | 1993-12-21 | 1995-01-03 | Taligent, Inc. | Boot framework architecture for dynamic staged initial program load |
-
1994
- 1994-01-06 CA CA002141931A patent/CA2141931A1/en not_active Abandoned
- 1994-01-06 DE DE69406277T patent/DE69406277D1/de not_active Expired - Lifetime
- 1994-01-06 CN CN94190304.4A patent/CN1110066A/zh active Pending
- 1994-01-06 EP EP94906536A patent/EP0689698B1/en not_active Expired - Lifetime
- 1994-01-06 AU AU60220/94A patent/AU6022094A/en not_active Abandoned
- 1994-01-06 JP JP50171995A patent/JP3798015B2/ja not_active Expired - Lifetime
- 1994-01-06 WO PCT/US1994/000196 patent/WO1994029803A1/en active IP Right Grant
-
1995
- 1995-12-20 US US08/575,241 patent/US5634129A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| DE69406277D1 (de) | 1997-11-20 |
| WO1994029803A1 (en) | 1994-12-22 |
| JPH08511117A (ja) | 1996-11-19 |
| CN1110066A (zh) | 1995-10-11 |
| AU6022094A (en) | 1995-01-03 |
| EP0689698A1 (en) | 1996-01-03 |
| US5634129A (en) | 1997-05-27 |
| CA2141931A1 (en) | 1994-12-22 |
| EP0689698B1 (en) | 1997-10-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3798015B2 (ja) | プレース・オブジェクト・システム | |
| US5544302A (en) | Object-oriented framework for creating and using container objects with built-in properties | |
| US5396626A (en) | Object-oriented locator system | |
| US20200334019A1 (en) | Application authoring using web-of-sheets data model | |
| Meyrowitz | Intermedia: The architecture and construction of an object-oriented hypemedia system and applications framework | |
| EP0664028B1 (en) | Object-oriented system locator system | |
| US5912666A (en) | Object-oriented global cursor tool | |
| JP4425348B2 (ja) | 複合ドキュメント・フレームワーク | |
| US6990480B1 (en) | Information manager method and system | |
| US6275227B1 (en) | Computer system and method for controlling the same utilizing a user interface control integrated with multiple sets of instructional material therefor | |
| US5634057A (en) | Place object display system having place objects selected in response to a user identifier | |
| US5787448A (en) | Dynamic linking system | |
| US5479589A (en) | Object-oriented system for selecting a graphic image on a display | |
| US5848429A (en) | Object-oriented global cursor tool which operates in an incompatible document by embedding a compatible frame in the document | |
| Pawson et al. | Naked objects: a technique for designing more expressive systems | |
| JPH09251416A (ja) | ハイパーメディア型文書管理装置 | |
| Decouchant et al. | Griffon: A cooperative, structured, distributed document editor | |
| Cousins | Reification and affordances in a user interface for interacting with heterogeneous distributed applications | |
| CA2154451C (en) | Object-oriented cursor tool | |
| Merna | OOD editor: A tool for creating object-oriented designs | |
| Araujo | A Design Process based on patterns and non-functional requirements |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040831 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20041130 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20050117 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050228 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050705 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051005 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060411 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060419 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100428 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110428 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110428 Year of fee payment: 5 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110428 Year of fee payment: 5 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120428 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120428 Year of fee payment: 6 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D02 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D04 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120428 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130428 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130428 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140428 Year of fee payment: 8 |
|
| EXPY | Cancellation because of completion of term |