JPH0736147B2

JPH0736147B2 - ハイパー・メディア・システムおよびそのグラフィカル・ユーザ・インタフェース方法

Info

Publication number: JPH0736147B2
Application number: JP3270552A
Authority: JP
Inventors: キース・バーンスタイン; ジョン・アンソニー・スティーブンス
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1990-10-31
Filing date: 1991-09-24
Publication date: 1995-04-19
Anticipated expiration: 2010-04-19
Also published as: EP0483576B1; CA2051180A1; BR9104712A; EP0483576A2; EP0483576A3; JPH04287116A; US5204947A; DE69128605D1; CA2051180C

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、一般的には“ハイパ
ーテキスト／ハイパーメディア”サービスを既存の（及
び新しい）コンピュータ・プログラム・アプリケーショ
ンに比較的シームレス（継ぎ目なく）に統合するソフト
ウェア・ファシリティに関し、特に、オープン・システ
ム・アーキテクチャを用いた、エンドユーザ・インタフ
ェース、リンクとリンク・マーカのオーサリング、リン
ク・ナビゲーション、及びリンク・マーカ・アブストラ
クトのサポートに関する。これにはエンドユーザ・イン
タフェース及びデータベース内のストレージのサポート
も含まれる。

【０００２】この発明の主題は、1988年11月18日付米国
特許出願第２７３５２７号明細書に関連する。

【用語の説明】この発明では次の用語を用いる。

【０００３】アブストラクト：キーワード、句、文など
から成るテキスト・オブジェクトで、テキスト・オブジ
ェクトに関連するリンク・マーカに見られる重要な情報
を要約したもの。

【０００４】アプリケーション：ワープロ、スプレッド
シート、データベース管理、グラフィクス・デザイナ
等、オペレーティング・システム以外のコンピュータ・
プログラム。この説明でも用いているように、アプリケ
ーション・プログラムはプレゼンタとも呼ばれる。

【０００５】アプリケーション・プログラミング・イン
タフェース（ＡＰＩ）：プログラムがサービスを呼び出
すための手段。

【０００６】クライアント・アプリケーション：ＬＭＳ
サービス（後述）を使用するアプリケーション（プレゼ
ンタ／プログラム）。

【０００７】コンテクスト・メニュー：“ポップアッ
プ”メニューともいう。視覚的、機能的にはプルダウン
・メニューに似ているが、アクションまたはコマンド・
バーには結びついていない。ウィンドウ内の任意の位置
に表示させることができる。プルダウン・メニューの内
容は通常、その時点のアプリケーションの状態によって
変化することはないが（使用可能にしたり使用不可にし
たりはできる）、コンテクスト・メニューの内容は動的
で、アプリケーションの状態によって変化する。コンテ
クスト対応型といえる。例えばコンテクスト・メニュー
に“セーブ”という項目がある場合は、コンテクスト・
メニューが表示され、データが変更されていないとき
は、“セーブ”オプションはメニュー内に現われない。
代表的なコンテクスト・メニューは、エンドユーザがウ
ィンドウでマウス・ボタンをクリックしたときに表示さ
れる。コンテクスト・メニューは通常、プルダウン・メ
ニューと似た機能を持つが、ある時点ではクリックされ
たオブジェクトに関連した項目しか持たない。

【０００８】ドキュメント：データ（テキスト・ファイ
ル、イメージ・ファイル、ビデオ等）の集合に名前をつ
けたもので、（いつもではないが）通常は（プレゼンタ
によって表示されたときに）エンドユーザが認識でき
る。“ドキュメント”という言葉は、テキスト・ファイ
ルに限定されることはなく、テキスト、ビットマップ・
グラフィクス、スプレッドシート、その他のデータも意
味する。他のオブジェクトもＬＭＳから見れば“ドキュ
メント”になるケースがある。このようなオブジェクト
には、オーディオ・ファイル、動画ファイル、動画クリ
ップ、連続したイメージ・ファイル（スライド）等があ
る。

【０００９】エンドユーザ・インタフェース（ＥＵ
Ｉ）：エンドユーザがシステム、システム・コンポーネ
ント、システム・アプリケーション等を扱う（インタラ
クション）方法（デバイスを含む）。

【００１０】グラフィカル・ユーザ・インタフェース
（ＧＵＩ）：グラフィカルなＥＵＩ。例えばエンドユー
ザは、ウィンドウ、アイコン、メニュー、ポインティン
グデバイス等を通してシステムを扱う。

【００１１】ハイパーテキスト／ハイパーメディア：最
も簡単な総称としては、ｔｏｕｃｈａｎｄｇｅｔを意
味する。エンドユーザが（ポインティング・デバイスを
使って）オブジェクト（語句、グラフィカル・オブジェ
クト等）をタッチし、それによって関連する情報体（in
formationentity）が得られるようにすることをさす。
ハイパーテキスト・システムの調査資料としては“Hype
rtext: An Introduction Survey”by Jeff Conklin、IE
EEComputer、September 1987、pp. 17-41、及び“An Ov
erview of Hypertext andHypermedia”、Concepts & Is
sues、McGraw-Hill、November 1989がある。

【００１２】リンク:あるドキュメント内のある点を別
のドキュメント内のある点（または同じドキュメント内
の別の点）に関連づけるオブジェクト。リンクは両方向
も考えられ、いずれの側からもたどれるものがある。

【００１３】リンク・マネジャ・サービス（ＬＭＳ）：
ハイパーテキスト／ハイパーメディア・サービスをすべ
て統合したもの。

【００１４】リンク・マーカ：代表的なものは、ドキュ
メント内に含まれドキュメント内のこの点（リンク・マ
ーカの位置）にリンクが存在することを示す、エンドユ
ーザに対するビジュアル表示。リンク・マーカから始ま
るリンクがあり、リンク・マーカが（エンドユーザがマ
ウスを使うことによって）トリガされた場合、リンク・
マーカのリンクをナビゲートすることができる。ＬＭＳ
が提供するリンク・マーカの外観には様々なスタイルが
ある。例えば（１）任意にテキストを加えることのでき
るプッシュ・ボタン、（２）エンドユーザがリンク・マ
ーカのフレームつきエリアを通して、クライアント・ア
プリケーションの下位の表現されたデータを見ることの
できるブラック・フレーム、（３）ブラック・フレーム
と同じようにトランスペアレンシを考慮しているが、見
えることが保証されたフレームを持つハイライト・フレ
ーム（ブラック・フレームと比べると特に下位のデータ
が黒かまたは非常に暗いときに便利）、（４）これも、
下位のデータのパターンが認識できるという意味でトラ
ンスペアレントであるが、下位のデータの色が変化する
（反転表示ともいう） − 例えば背景がすべて黒から白
へ、すべて白から黒へ、すべて青から黄色へ、というよ
うに変化するハイライト・エリア、（５）背景のデータ
が隠れている場合に全く見えない状態、等がある。

【００１５】マウス：マウスという言葉は、本願で用い
る場合は、マウス、トラック・ボール、ライトペン、タ
ッチ・スクリーン等、オペレーティング・システムによ
ってサポートされるポインティング・デバイスをいう。
またスクリーン、キーボードやマウスの操作、メニュー
等、エンドユーザがアプリケーションを使っているとき
に操作の対象とするものも指す。

【００１６】ナビゲーション：リンクをたどること。

【００１７】オープン・システム：アプリケーション
（プレゼンタ）がリンクの形成に参加できるハイパーメ
ディア・システム。このようなアプリケーションは、リ
ンクのもう一端のドキュメントやプレゼンタを意識する
必要がないので、全く別個に開発されたアプリケーショ
ン及びアプリケーションによって表現されたデータをシ
ームレス（継ぎ目なく）に統合することができる。

【００１８】プレゼンタ：エンドユーザのためにデータ
（テキスト・ファイル、イメージ・ファイル、オーディ
オ等）を表現するアプリケーション。

【００１９】プルダウン・メニュー：ウィンドウ最上部
のアクション・バー（メニュー・バー）に結びつけられ
たメニューをいう。このようなメニューには、サブメニ
ュー（カスケード・メニューと呼ばれる）を置くことも
できる。

【００２０】

【従来の技術】多くのハイパーテキスト／ハイパーメデ
ィア・システムがSmalltalk、C++等のオブジェクト指向
プログラミング言語でプログラムされている。Smalltal
k はゼロックスのパロアルト研究所（ＰＡＲＣ）で開発
されたものである。この言語の参考書としては、Adele
GoldbergとDavid Robsonによる“Smalltalk-80: TheLan
guage and Its Implementation”、Addison-Wesley、19
83、があげられる。Ｃ＋＋は、ＡＴ＆Ｔベル研究所のBj
arne Stroustrup によって開発されたものである。この
言語の参考書としては同氏による“The C++ Programmin
g Language”、Addison-Wesley、1986、があげられる。
オブジェクト指向プログラミング・システム（ＯＯＰ
Ｓ）のメリットは、モジュール構造と、アイコンを用い
たオブジェクト指向ユーザ・インタフェースに代表され
る。オブジェクト指向プログラミングとハイパーシステ
ムの詳細については、“Design and Use of Hypermedia
Systems”by Robert Akscyn of Knowledge Systems、In
c.、Conference onHuman Factors in Computing System
s、May 14、1988、及び“Intermedia: TheArchitecture
and Construction of An Object Oriented Hypermedia
Systemand Application Framework”by Norman Meyrow
itz、IRIS、Brown University、OOPSLA Proceedings、S
eptember 1986、を参照されたい。

【００２１】発明者の知るかぎり、アプリケーション
（プレゼンタ）がハイパーテキスト／ハイパーメディア
機能をオープン・システム・アーキテクチャに簡単にシ
ームレス（継ぎ目なし）に組み込み、プレゼンタ自体に
よってではなくハイパーメディア・サービスによって管
理されるエンドユーザのための一貫したハイパーメディ
ア・インタフェースを自動的に提供するハイパーテキス
ト／ハイパーメディア・システムは現在存在しない。ま
た、多少とも“オープン”なシステムであるこのような
ハイパーメディア・システムでも、システム内のすべて
のハイパーメディア・アプリケーションに手を加えて最
構成するのでなければ、次期バージョンのユーザインタ
フェースを変更することはできない。

【００２２】以下に述べる従来技術は、ハイパーテキス
ト／ハイパーメディア機能を実現した製品やサービスを
代表する技術である。

【００２３】Apple Corp. から出ている「ハイパーカー
ド」はハイパーメディア製品ではなく、“アプリケーシ
ョン・ビルダ”または“カードのスタック”であるとい
うのが（その作者Bill Atkinson を含めた）大方の見方
である。ハイパーメディア・システムとして見ると（カ
ードが“リンクされる”という意味で）、ハイパーカー
ドは閉じたハイパーメディア・システムである。例え
ば、この製品で提供されるプレゼンテーション・ファシ
リティしか使えない。ハイパーカードは、ハイパーメデ
ィア機能で他の（ハイパーカードに提供されていない）
アプリケーション（プレゼンタ）を使えるようにするフ
ァシリティを提供していない。

【００２４】Silicon Beach Softwareの「スーパカー
ド」プログラムは、ハイパーカード“風”だがハイパー
カードよりも強力である。“カード”のスタックを提供
するほかにアプリケーションを生成する。この他の閉じ
たハイパーメディア・システムとしては、OWL Internat
ional、Inc. の「ガイド２．０」 − ハイパーメディア
機能で他の（ガイドに提供されていない）アプリケーシ
ョン（プレゼンタ）を使えるようにするファシリティは
提供されていない − Brown UniversityのIRIS (Instit
ute for Research in Information and Scholarship）
のIRIS Intermedia−これもハイパーメディア機能で他
の（Intermediaに提供されていない）アプリケーション
（プレゼンタ）を使えるようにするファシリティを提供
していない− IBM Educational Systems のLinkWay 2.0
− これもまたハイパーメディア機能で他の（LinkWay
に提供されていない）アプリケーション（プレゼンタ）
を使えるようにするファシリティを提供していない −
等がある。

【００２５】Sun MicrosystemsのSun Link Serviceは、
発明者の知るかぎり、他のオープンなハイパーメディア
・システムのなかで唯一使える製品である。Sun のファ
シリティは、ハイパーメディア機能で他の（Sun に提供
されていない）アプリケーションを使えるようにするサ
ービスを提供している。ただしシームレス（継ぎ目な
し）かつ容易に使えるようにはならない。またSun Link
Serviceは、ハイパーメディア機能のエンドユーザ・イ
ンタフェースを管理しない。つまり、この点について各
アプリケーションはそれ自体のアイデアを実現しなけれ
ばならない。この製品の詳細についてはHypertext '89
Proceedings に掲載されたAmy Pearl による記事“Sun'
s Link Service: A Protocol for Open Linking”(pp.
137-146)を参照されたい。

【００２６】上記の他、PC/Computing Magazine 誌はハ
イパーテキスト／ハイパーメディア機能を実現した数種
の製品の評文を載せている。製品はFolio Corp.のFolio
Views 2.0、Cognetics Corp.のHyperties、NtergaidのH
yperWriter、SpinnakerSoftware Corp.のSpinnaker Plu
s 2.0、MaxThinkのTranstext等である。FolioViews は
「大きいテキスト・ファイルを扱いやすい“インフォベ
ース”に圧縮してクロスレファレンス・リンクを作る情
報管理システム」という。この製品についてこれ以上の
ことはわかっていないが、製品評は、これが異なるプレ
ゼンタ相互間やタイプの異なるデータ相互間のリンクを
形成できないとしている。またハイパーメディア機能で
他の（Folio Views に提供されていない）アプリケーシ
ョン（プレゼンタ）を使えるようにする方法が与えられ
ないともいう。

【００２７】Hyperties は「既存のファイル、オンライ
ン情報、走査した書類、ビデオ等、各種のメディアから
ハイパーテキストのドキュメントやマニュアルを作るイ
ンタラクティブ・システム」と評されている。Hypertie
s は閉じたハイパーメディア・システムである。例えば
製品に提供されるプレゼンテーション・ファシリティし
か使えない。Hypertiesについてこれ以上のことはわか
っていないが、製品評は、ハイパーメディア機能で他の
（Hyperties に提供されていない）アプリケーション
（プレゼンタ）を使えるようにする方法が与えられてい
ないという。

【００２８】HyperWriter は「オーディオ、ビデオの処
理機能があり、制限はあるがスクリプト言語も備えるハ
イパーテキスト・オーサリング・ツール」という。

【００２９】Spinnaker Plus 2.0は「カスタム情報管理
アプリケーションを開発、実行するためのハイパーテキ
スト・プログラミング環境」と評されている。これ以上
のことはわかっていないが、製品評から判断すると、Sp
innaker は“真”のハイパーテキスト製品に止どまらな
いアプリケーション生成プログラムのようである。

【００３０】Transtext は「市販の他の多くのアプリケ
ーションとの間でハイパーテキスト・リンクを形成でき
るワードプロセサ」と評されている。製品についてこれ
以上のことはわかっていないが、製品評は、この製品か
ら１方向のリンクを形成できることを示しているようで
ある。リンクが形成されると、おそらく、市販のアプリ
ケーションが投入され、それにユーザが指定したパラメ
ータが引き渡されるだけであろう。

【００３１】またKnowledge Garden、Inc.のKnowledgeP
ro について先に引いたConcepts &Issues誌は「．．．
この製品に慣れるにはある程度プログラミングの経験が
あった方がいいが、開発者によると、そうした経験はこ
のプログラムを習得する必要条件ではない．．．エキス
パート・システム・ジェネレータとハイパーテキストを
組み合わせたプログラミング環境．．．外部ファイルを
読み出し、外部プログラムを呼び出して、他の言語で書
かれたルーチンによって拡張できる」と評している（19
89年11月号）。製品評はさらに、プログラミング環境と
エキスパート・システム・ジェネレータの組み合わせに
よって高度なサーチ機能が得られるという。但しこの製
品のサーチ機能についても製品がどの程度オープンであ
るかについてもこれ以上のことはわからない。

【００３２】

【発明が解決しようとする課題】この発明の目的は、オ
ープン・システム・アーキテクチャにおいてアプリケー
ション（プレゼンタ）がハイパーテキスト／ハイパーメ
ディア機能を容易にシームレス（継ぎ目なし）に組み込
めるようにし、プレゼンタ自体ではなく下位のリンク形
成サービスによって完全に管理される一貫したハイパー
メディア・インタフェースがエンドユーザに自動的に提
供されるシステム・リンク・サービスを提供することに
ある。

【００３３】この発明の目的には、アプリケーションか
ら独立したハイパーメディア・システムによって作成さ
れるクライアント・アプリケーションのための一貫した
メニューとダイアログ・ボックスを提供することも含ま
れる。

【００３４】この発明の目的には、ドキュメント内のあ
る点のリンクの位置を識別するリンク・マーカ・ファシ
リティをエンドユーザに提供することも含まれる。

【００３５】この発明の目的には、見えないウィンドウ
またはトランスペアレントなウィンドウを扱う汎用ユー
ティリティのプロシジャを提供することも含まれる。

【００３６】

【課題を解決するための手段】この発明によれば、エン
ドユーザ・インタフェース管理により、ハイパーメディ
ア・メニュー、ダイアログ・ボックス、マウス処理、及
びリンク・マーカ管理について、すべてのクライアント
・アプリケーションに共通のエンドユーザ・インタフェ
ースが与えられる。このようなファシリティでは、これ
らのもの（Notion）の外観がサポートされるほか、結果
的にはエンドユーザの要求をセマンティックに満足する
コード実行される。エンドユーザとプログラムの（ＧＵ
Ｉ環境における）インタラクションを実現する方法の基
本は、メニューの使用である。したがってメニューは、
エンドユーザがプログラムの機能にアクセスするための
第１の手段になる。メニュー管理は、ほとんどのアプリ
ケーションでかなり厄介なタスクであり、アプリケーシ
ョンのＥＵＩに一貫性がなくなるケースが多い。ＬＭＳ
によるメニュー・サポートは、この問題を解決するため
に、メニューの作成と維持を管理する。ＬＭＳはまた、
クライアント・アプリケーションの手を借りることなく
メニュー内のすべての機能を実行する。

【００３７】

【実施例】この発明は、異なるオペレーティング・シス
テム（ＯＳ）を用い、各種のコンピュータ上で実行する
ことができる。コンピュータは、パーソナル・コンピュ
ータ、ミニコンピュータ、メインフレーム・コンピュー
タ等であり、ローカル・エリア・ネットワーク（ＬＡ
Ｎ）やワイド・エリア・ネットワーク（ＷＡＮ）等のネ
ットワークの１部であるスタンドアロン・システムや大
型の遠隔データ処理システムが使用できる。便宜上、こ
の発明はＩＢＭのＰＳ／２シリーズ等のパーソナル・コ
ンピュータに実現されるものとして説明する。もちろ
ん、コンピュータの選択の幅を制限するのは、必要なメ
モリやディスク・ストレージの条件だけである。ＩＢＭ
ＰＳ／２シリーズの詳細については、Technical Refe
renceManual Personal System/2 (Model 50、60 System
s) (Part No.68X2224、OrderNo. S68X-2224）及びTechn
ical Reference Manual、Personal System/2(Model 80)
（Part No. 68X2256、Order No. S68X-2256）を参照さ
れたい。

【００３８】この発明の実施例を示すためのオペレーテ
ィング・システムとして、プレゼンテーション・マネジ
ャ（ＰＭ）を備えたＩＢＭのＰＳ／２を使用したが、こ
の発明は他の異なるオペレーティング・システムでも実
現できること、そしてそれより重要なことであるが、オ
ペレーティング・システムに組み込めることは理解され
よう。IBM OS/2オペレーティング・システムの詳細につ
いては、IBMOperating System/2、Version 1.2、Standa
rd Edition TechnicalReference を参照されたい。

【００３９】以下各図により説明する。図１は、システ
ム・ユニット１１、キーボード１２、マウス１３、及び
グラフィクス・ディスプレイ・デバイスまたはモニタ１
４から成るパーソナル・コンピュータ１０である。キー
ボード１２とマウス１３は、ユーザ入力デバイスであ
り、ディスプレイ・デバイスはユーザ出力デバイスであ
る。マウス１３は、ディスプレイ・デバイス１４の画面
１６に表示されるカーソル１５を制御するために用いら
れる。このシステムによってサポートされるグラフィク
ス・ユーザ・インタフェース（ＧＵＩ）では、ユーザ
が、カーソル１５をアイコンのところまたは画面１６上
の点に移動させ、マウスボタンの１つを押してユーザ・
コマンドを実行するかまたは選択を行うことによって
“ｐｏｉｎｔ−ａｎｄ−ｓｈｏｏｔ”ができる。

【００４０】図２は、図１に示したパーソナル・コンピ
ュータのコンポーネントのブロック図である。システム
・ユニット１１は、各コンポーネントが接続され、各コ
ンポーネント間の通信が行われるシステム・バス２１を
含む。マイクロプロセサ２２はシステム・バス２１に接
続され、同じくシステム・バス２１に接続される読み出
し専用メモリ（ＲＯＭ）２３とランダム・アクセス・メ
モリ（ＲＡＭ）２４によってサポートされる。ＩＢＭ
ＰＳ／２シリーズ・コンピュータのマイクロプロセサ２
２は、Intel のマイクロプロセサ・ファミリ８０２８
６、８０３８６、８０４８６のいずれかであるが、特定
のコンピュータに、６８０００、６８０２０、６８０３
０等、Motorolaのマイクロプロセサ・ファミリや、IB
M、HewlettPackard、Sun Microsystems、Intel、Motoro
la、その他のメーカが生産している各種のＲＩＳＣ（縮
小命令セット・コンピュータ）マイクロプロセサ等も使
用できる。

【００４１】ＲＯＭ２３は、特にディスク・ドライブや
キーボードのインタラクション等、ハードウェアの基本
動作を制御する基本入出力システム（ＢＩＯＳ）を格納
する。ＲＡＭ２４は、オペレーティング・システムとア
プリケーション・プログラムがロードされるメイン・メ
モリである。メモリ管理チップ２５は、システム・バス
２１に接続され、ＲＡＭ２４、ハードディスク・ドライ
ブ２６、及びフロッピーディスク・ドライブ２７の間の
データのページングを含めた直接メモリ・アクセス（Ｄ
ＭＡ）動作を制御する。

【００４２】システム・ユニット１１には上記のほか３
つのＩ／Ｏコントローラ（キーボード・コントローラ２
８、マウス・コントローラ２９、ビデオ・コントローラ
３１）があり、すべてシステム・バス２１に接続され
る。キーボード・コントローラ２８は、名前からわかる
とおり、キーボード１２に、マウス・コントローラ２９
はマウス１３に、ビデオ・コントローラ３０はグラフィ
クス・ディスプレイ・デバイスに各々ハードウェア・イ
ンタフェースを提供する。

【００４３】図１、図２に示したハードウェアは代表的
なものであるが、アプリケーションによって異なる。例
えば光学式記憶装置、オーディオＩ／Ｏ、プリンタ等、
他の周辺装置を追加することができる。この発明は特
に、ハードウェアを制御または“稼働”させるオペレー
ティング・システム（ＯＳ）のエンハンスを対象として
いる。上述のように、この発明は既存ＯＳに追加したり
組み込んだりできるが、ここでは便宜上、ＯＳがＧＵＩ
をサポートするものとする。このようなオペレーティン
グ・システムがプレゼンテーション・マネジャ（ＰＭ）
を備えるＩＢＭＯＳ／２で、本発明はこのＯＳ上で展開
した。

【００４４】この発明は、図３に示すように、関連のな
い各種アプリケーション・プログラムのための一貫した
環境をサポートし提供するオープン・システムを提供す
る。図３のリンク・マネジャ・システム（ＬＭＳ）３１
は、スプレッドシート・プログラム３２、ワープロ・プ
ログラム３３、動画プログラム３４、グラフィカル・イ
メージ・プログラム３５、及びオーディオ・プログラム
３６の５つのアプリケーション・プログラムをサポート
するものとして示した。後で詳述するが、ＬＭＳ３１
は、数種類のアプリケーション・プログラムの各々につ
いてユーザが指定した各種のリンクをデータベース３７
（図２のハードディスク・ドライブ２６等に格納され
る）を通して維持する。

【００４５】データベース３７は、ＬＭＳが維持するア
ソシエーションの集合である。ＬＭＳは、この情報を個
別に維持することを目的として設計されたものである。
これによりクライアント・アプリケーションは、ＬＭＳ
に参加するときにそのデータを変更したり破壊したりす
る必要がなくなる。そしてＬＭＳシステムのオープン性
が高まる。

【００４６】リンクは基本的には２種類形成することが
できる。第１に１方向リンクである（図４Ａ）。これは
マーカからオブジェクトへのリンクである。図４Ａの４
１、４２は、各種のアプリケーションを実行することの
できるウィンドウを表わす。例えばウィンドウ４１で
は、ワープロ・プログラムによって作成されたテキスト
・ドキュメントや、グラフィクス・プログラムまたはス
プレッドシートによって作成されたイメージを表示する
ことができる。マーカ４３は表示されたドキュメント、
イメージ、またはスプレッドシート内に置くことがで
き、そのマーカ４３をウィンドウ４２内のオブジェクト
にリンクすることができる。リンクされたオブジェクト
は、テキスト・ドキュメント、イメージ、スプレッドシ
ート、オーディオ、ビデオ、スライド、その他のアプリ
ケーション内に置ける。このリンクは１方向である。つ
まりマーカ４３を選択すると、リンクされたオブジェク
トがウィンドウ４２に表示されるが、マーカ４３へのリ
ターンはない。

【００４７】図４Ｂは両方向リンクを示す。これはマー
カからオブジェクトへのリンクではなくマーカからマー
カへのリンクである。例えばウィンドウ４１内のマーカ
４３はウィンドウ４２内のマーカ４４にリンクすること
ができる。マーカ４３を選択すると、ウィンドウ４２内
のテキスト・ドキュメント、イメージ、スプレッドシー
ト等が表示される。マーカを同じアプリケーション内の
マーカにリンクできることに注意されたい。例えばテキ
スト・ドキュメント内のマーカ４５はもう１つのマーカ
４６にリンクすることができる。図４Ｂに示したよう
に、マーカ４６はマーカ４５と同時には見えない場合も
あるが、マーカ４５を選択することによって、ドキュメ
ント内のマーカ４６が位置する部分が表示される。同様
にマーカ４６が選択されると、ドキュメント内のマーカ
４５が位置する部分が表示される。

【００４８】図５は、リンク・マネジャ・サービス（Ｌ
ＭＳ）５１と各クライアント・アプリケーション５２の
関係を示すブロック図である。後述するように、ＬＭＳ
５１は同一形式の一貫したエンドユーザ・インタフェー
ス（ＥＵＩ）を与える。ＬＭＳ５１は特に、これまでは
独立したクライアント・アプリケーションによって実行
された機能を実行する。これらの機能にはＥＩＵの１部
を成すメニューやダイアログ・ボックスの生成が含まれ
る。ある特定のクライアント・アプリケーションがＬＭ
Ｓ５１にコールをかけ、ＬＭＳ５１が、要求されたメニ
ューまたはダイアログ・ボックスを生成することによっ
て、クライアント・アプリケーションが変わっても一貫
したＥＩＵが保証される。ＬＭＳ５１はまた、クライア
ント・アプリケーション５２を投入するためのＥＵＩを
提供する。この点については各図による以下の説明から
明らかになるが、ここではＬＭＳ５１が、どのクライア
ント・アプリケーションによっても生成され得るデータ
をアクセスするための手段であって、マーカにリンクさ
れたデータをアクセスするために、必要に応じてクライ
アント・アプリケーションを投入するということを理解
されたい。

【００４９】図５は“ウェブ”という新しい考え方を示
している。“ウェブ”という言葉は、ドキュメント、リ
ンク、及びリンク・マーカの定義の集合をいうのに用い
られる。ウェブは、定義されたアソシエーションをＬＭ
Ｓがナビゲートするのに必要なすべての情報を表わす。
ナビゲーションでは、エンドユーザがあるドキュメント
内のリンク・マーカから別のアプリケーションへ、異な
るアプリケーションによって表現されたドキュメント
へ、マージン・ノート（オーディオ、テキスト等）へ、
或いは同じドキュメント内の別の場所へ行くことができ
る。ターゲット・アプリケーションは、ＬＭＳを使うこ
とにしているアプリケーションか、またはＬＭＳを意識
することもないアプリケーションである。言い替える
と、ウェブを用いることによって、ＬＭＳは、ドキュメ
ント自体を変更することなく、ドキュメント間のアソシ
エーションについて必要なデータをすべて維持すること
ができる。

【００５０】ウェブは、あるアプリケーションでは、あ
るトピックに関する情報にアクセスするときに複数の選
択肢をエンドユーザに与えるために、ワープロ、スライ
ド、オーディオ等、クライアント・アプリケーションを
いくつか利用するプレゼンテーション・システムと考え
ればわかりやすいかもしれない。通常、トピックのプレ
ゼンテーションは、システムの第１エンドユーザ（例え
ばインストラクタ）によって著され、システムの第２エ
ンドユーザ（例えば学習者）が見る。その場合、学習者
に対するトピックのプレゼンテーションは、ディスプレ
イ・デバイス１４の画面１６（図１参照）にウィンドウ
を表示することによって開始することができる。学習者
は通常、リンク・マーカを選択する。そこでプレゼンテ
ーションは学習者が選択したものに応じた順序で進行す
る。

【００５１】上記の例でいえば、エンドユーザが、栄養
に関するハイパーメディア・ドキュメントを読んでい
て、リンク・マーカをトリガすると（ポインティング・
デバイスで起動する等）カロリー表が読者に表示される
ことを示すリンク・マーカがそこにあった場合、読者が
リンク・マーカを起動するとカロリー表が表示される。
読者がドキュメントをハードコピーの形で（書籍等）使
う場合には、読者はドキュメントの索引等を使ってカロ
リー表を探すことになる。その場合はおそらく、カロリ
ー表を引く項目がいくつかあって、カロリー表自体に対
応したものはそのうちの１つだけであろう。

【００５２】この種のプレゼンテーションをサポートす
るために、ユーザがマーカを選択するか、キーワードを
入力したときに、それに応じてＬＭＳ５１によってウェ
ブ・データベース５３がアクセスされ、プレゼンタ（ア
プリケーション・プログラム）がＬＭＳ５１によって投
入（起動）されて、要求された情報が表現される。ウェ
ブ・ビューワ５４は、ウェブ・データベース内のドキュ
メント、リンク、及びマーカの関係をグラフィカルに表
示するのに用いられる。ウェブ・ビューワ５４はＬＭＳ
が提供するクライアント・アプリケーションであり、２
つの機能を持つ。（１）ＬＭＳで登録されたドキュメン
ト間のアソシエーションをスコープを変えて（アプリケ
ーションのウェブ全体、数個のドキュメントへの“ズー
ムイン”等）見えるようにするツールと、（２）ウェブ
・データベースを管理、開発するためのツールである。
データベース５３は通常、ハードディスク・ドライブ２
６（図２）に格納され、ウェブ・ビューワ５４は、ディ
スプレイ・デバイス１４（図１）に出力画面を作る。但
し、ウェブ・ビューワは、下位のオペレーティング・シ
ステム、デバイス、またはＬＭＳによって提供される一
般的なプレゼンテーション空間（或いはデバイス）では
ないことに注意されたい。また、ＬＭＳを使用するため
にウェブ・ビューワを使用する必要はない。ウェブ・ビ
ューワは汎用ユーティリティ・アプリケーションであっ
て、本発明の適用あるいは理解に必要なものではないの
で、ここでは詳述しない。

【００５３】この発明が適用されるＧＵＩ環境はウィン
ドウイング環境である。基本メッセージのセットアップ
は、OS/2 PM、MicrosoftWindows、X-Windows 等、ほと
んどのウィンドウ・システムに共通である。基本的に
は、システム内のどのウィンドウにもウィンドウ・プロ
シジャと呼ばれるものが関連づけられる。オペレーティ
ング・システムがメッセージをウィンドウに送ると、そ
のメッセージは、そのウィンドウに関連づけられたウィ
ンドウ・プロシジャに向けられる。ウィンドウ・プロシ
ジャは、そのウィンドウを保有し、あるタイプのメッセ
ージの処理方法を知っているアプリケーションによって
提供されるコードにすぎない。オペレーティング・シス
テムからウィンドウに送られる普通のメッセージはユー
ザ入力メッセージである。メッセージは、ボタンの押
下、ウィンドウの起動等である。メッセージを受け取る
ウィンドウのウィンドウ・プロシジャはメッセージに従
う場合と従わない場合とがある。ウィンドウ・プロシジ
ャがメッセージに従わない場合、デフォルト・プロシジ
ャが呼び出されることがある。

【００５４】この発明では、ＬＭＳはウィンドウ・ファ
シリティも利用する。流れ図のなかで、矢印がオペレー
ティング・システム（ユーザ・アクション）とＬＭＳ
（通知）の両方からウィンドウ・プロシジャへ行くとこ
ろがある。つまりＬＭＳも通知メッセージをアプリケー
ションのウィンドウ・プロシジャに送信する。

【００５５】図６は、この発明に従ったクライアント・
アプリケーションのウィンドウ・プロシジャのロジック
を示す。これはＬＭＳによって活動化される代表的なア
プリケーション（他の場合はクライアント・アプリケー
ションという）のウィンドウ・プロシジャである。ユー
ザは、操作ブロック６１で何らかの入力（マウス・ボタ
ンを押す、メニューを選択する、キーを押す等）を行
い、オペレーティング・システムはそのメッセージをク
ライアント・アプリケーションのウィンドウ・プロシジ
ャに送る。クライアント・アプリケーションのウィンド
ウ・プロシジャは、メッセージを受け取ると、判断ブロ
ック６２でメッセージを調べ、メッセージがコマンド・
メッセージ（メニュー・コマンド・メッセージ等）かど
うかを判断する。その通りなら、アプリケーションはさ
らに判断ブロック６３で、そのメッセージが自ら定義し
たメニュー・コマンドの１つかどうかを調べる。すなわ
ちＬＭＳとは無関係にそのアプリケーションに関連する
メニュー・コマンドかどうかである。これらのコマンド
には、新しいファイルのオープン、カット、ペースト、
その他、アプリケーション特有のコマンドが含まれる。
そのアプリケーション自体が定義したメニュー・オプシ
ョンの１つである場合、アプリケーションは先へ進み、
判断ブロック６４で、あたかもＬＭＳが存在しなかった
かのようにコマンドを処理する。一方、コマンドがアプ
リケーションによって定義されたメニュー項目ではな
く、メニュー・コマンドである場合は、アプリケーショ
ンは機能ブロック６５でデフォルトのＬＭＳ処理プロシ
ジャを呼び出す。このサービスは１回のファンクション
・コールに過ぎず、ＬＭＳのデフォルト処理プロシジャ
である。アプリケーションがメニュー・コマンドを認識
しない場合、そのアプリケーションはＬＭＳサービスを
呼び出す。

【００５６】判断ブロック６２に戻るが、コマンドがメ
ニュー・コマンドでなければ、判断ブロック６６、６７
で、アプリケーション特有の他のタイプのメッセージ
かどうかが調べられる。例えばマウス・メッセージが入
ってきたかどうかを知ろうとするアプリケーションがあ
る。そして判断ブロック６６で判定されるように、マウ
ス・メッセージであれば、アプリケーションは、それが
マウス・メッセージを処理するタイプのアプリケーショ
ンなら機能ブロック６８でそれを処理する。このような
メッセージを処理するアプリケーションがあり、その必
要のないアプリケーションもある。そして通常はアプリ
ケーションがメッセージを処理するかどうかにかかわら
ず、そのアプリケーションは、ＬＭＳがメッセージを調
べて対応できるように、機能ブロック６９でデフォルト
ＬＭＳプロシジャを呼び出す必要がある。例えばＬＭＳ
はコンテクスト・メニューをもってくるかもしれない。

【００５７】コマンドがマウス・メッセージでない場
合、アプリケーションは、判断ブロック６７で、メッセ
ージが他のアプリケーション特有のメッセージがどうか
を判定し、その通りなら、機能ブロック７１でそのメッ
セージを処理するための機能を呼び出す。他の場合、ア
プリケーションが処理方法を知らないメッセージの場合
と同じように、アプリケーションは機能ブロック７２で
ＬＭＳのデフォルト処理プロシジャを呼び出す。

【００５８】ＬＭＳは、ユーザ入力によって生成される
メッセージのほか、機能ブロック７３に示すように、メ
ッセージ自体を受理することを想定してＬＭＳ自体のメ
ッセージをクライアント・アプリケーションに送ること
がある。あるウィンドウ内のＬＭＳは、システム内の別
のウィンドウにメッセージを送って、そのウィンドウに
ＬＭＳを認識するかどうかをたずねるが、後者のウィン
ドウ内のアプリケーションはそのメッセージを認識しな
い場合がある。そのメッセージは、マウス・メッセー
ジ、メニュー・コマンド・メッセージ、或いはアプリケ
ーション特有のメッセージというカテゴリに入らず、し
たがってアプリケーションはそのメッセージを処理せ
ず、ＬＭＳの処理プロシジャを呼び出す。ＬＭＳ処理プ
ロシジャはそのメッセージを認識していて先へ進み、Ｔ
ＲＵＥ（「私はＬＭＳを認識するアプリケーション」）
を返す。

【００５９】基本ハードウェアとシステム構成について
述べたが、ここでＬＭＳの動作例について説明する。図
７は、「ビットマップ・ディスプレイア」プログラムに
よって作成されたコンピュータのディスプレラ譁ハを示
す。このプログラムはプレゼンタ（アプリケーション）
であり、ＧＬＯＢＥ．ＢＭＰドキュメント（ビットマッ
プ・グラフィクス）を表現する。ＧＬＯＢＥ．ＢＭＰド
キュメントは、関連した情報の存在を示すリンク・マー
カ（テキストは“More info→”）を含む。マウスでク
リックすると、リンク・マーカに関連づけられたリンク
がナビゲートされ、ＷＯＲＬＤ．ＴＸＴドキュメントを
表現するプレゼンタ「ファイル・ブラウザ」がユーザに
表示される（図８参照）。ＷＯＲＬＤ．ＴＸＴドキュメ
ントにもリンク・マーカ（テキストは“See apicture
→”）が含まれる。このリンク・マーカをたどると、
ＧＬＯＢＥ．ＢＭＰドキュメントに行きつく。

【００６０】先にも触れたが、ＬＭＳは、メニューの作
成を担当することによって一貫したＥＵＩを提供する役
割も担う。メニューはコンテクスト・メニュー（ポップ
アップ・メニューともいう）とプルダウン・メニューの
２種類ある。前者は、コンテクストまたはディスプレイ
のフィールド内のカーソル位置に応じて表示されるメニ
ューである。図９、図１０は２種類のコンテクスト・メ
ニューの例を示す。図９でユーザは、マウス・ボタンで
アフリカ大陸の最北端付近にあるクライアント・アプリ
ケーションのクライアントまたはワークスペース・エリ
アをクリックしている。ユーザはこのコンテクスト・メ
ニューから、その位置でマーカを作成する等、オプショ
ンをいくつか選択することができる。図１０では、ユー
ザはリンク・マーカをクリックしている。表示されたコ
ンテクスト・メニューは上記と似ているが、オプション
が異なる（コンテクストが異なるため）。ユーザはここ
で例えばマーカの移動や削除が行える。

【００６１】クライアント・アプリケーションは、コン
テクスト・メニューの作成をＬＭＳに対して明示的に指
示する必要はなく、場合によっては（マウスが図１０の
ようにリンク・マーカの上にあるとき等）、メッセージ
もＬＭＳに送る必要がない。そこでコンテクスト・メニ
ューはほとんどＬＭＳの“自由な”フィーチャになり、
プルダウン・メニューと同一の機能へのアクセスを提供
する。

【００６２】クライアント・アプリケーションの初期化
時、クライアント・アプリケーションはＬＭＳを呼び出
して、ハイパーメディアのプルダウン・メニューの作成
を要求する。ＬＭＳはそこで、メニューを、クライアン
ト・アプリケーションのコードで定義しなくてよいよう
に、動的に作成する。この後のメニューの処理（チェッ
クの印をメニュー項目の横につける、メニュー項目を使
用禁止にする、メニュー項目を選択する等）はすべて、
クライアント・アプリケーションは関係しないオペレー
ティング・システム・メッセージをＬＭＳが受け取った
ときにＬＭＳによって行われる。

【００６３】クライアント・アプリケーションによって
処理されないオペレーティング・システム・メッセージ
はすべて、クライアント・アプリケーションによって、
ＬＭＳが提供するサービスを使ってＬＭＳに向けられ
る。これにはメニュー・メッセージが含まれる。ＬＭＳ
は、メニュー・メッセージを基に必要な処置を決定し実
行する。例えばハイパーメディア・メニューが表示され
ようとする、というメッセージであれば、ＬＭＳは、リ
ンクとリンク・マーカの現在状態を基に、必要に応じて
メニューの外観を調整（不適当なメニューオプションを
すべて使用禁止にする等）してからそれを表示する。或
いはメッセージが、“マーカ作成”が選択されたという
ものなら、クライアント・アプリケーション側では何の
作業も行われず、ＬＭＳがエンドユーザのためにリンク
・マーカを作成する。ＬＭＳを使用するアプリケーショ
ンはすべて、同じハイパーメディア・メニューを持ち、
これらのメニューは同じように動く。これによって一貫
したＥＵＩが保証される。

【００６４】例を図１１ないし図１５に示した。図１１
は、マウスでアクションバーまたはコマンド・バーのＬ
ＩＮＫがクリックされたときのプルダウン・メニューを
示す。

【００６５】プルダウン・メニューは階層に分けること
ができる。例えば図１２は、マウスで図１１の第１プル
ダウン・メニューのＭＡＮＡＧＥＭＡＲＫＥＲＳがク
リックされたときの第２プルダウン・メニューを示す。
図１３は、マウスが図１２の第２プルダウン・メニュー
のＣＲＥＡＴＥＭＡＲＫＥＲでクリックされたときの
第３プルダウン・メニューを示す。さらに図１４は、マ
ウスで図１１のプルダウン・ウィンドウのＭＡＮＡＧＥ
ＬＩＮＫＳでクリックされたときの第２プルダウン・
ウィンドウを示す。そして図１５は、マウスで図１４の
第２プルダウン・ウィンドウのＣＲＥＡＴＥＬＩＮＫ
がクリックされたときの第３プルダウン・ウィンドウを
示す。

【００６６】図１６は、プルダウン・メニュー処理のロ
ジックを示す流れ図である。ＬＭＳは、このメニュー内
の異なるメニュー項目をすべて取得するために、クライ
アント・アプリケーションのために実際にそのメニュー
を作成する。これはまた、将来リリースされるＬＭＳに
機能が追加される場合は、ＬＭＳがそのメニューを作る
ので、クライアント・アプリケーションは、追加された
ＬＭＳ機能を継承するために新しいバージョンをリリー
スする必要はないということでもある。ＬＭＳがメニュ
ーを作成する方法は次のようになる。アプリケーション
は、初めて起動されたとき、ＬＭＳＡＰＩのファンク
ション・コールを通してＬＭＳを呼び出し、ＬＭＳにそ
の最上位レベルのメニュー（普通はアクション・バー）
へのハンドルを引き渡す（機能ブロック７５）。ＬＭＳ
はそこで、その動的リンク・ライブラリの１部としての
リソースとしてセーブされていたそのプルダウン・メニ
ュー定義をロードする（機能ブロック７６）。ＬＭＳ
は、リソースをロードすると、それをクライアントのウ
ィンドウのメニュー・ハンドルに挿入または接続する
（機能ブロック７７）。ここから、エンドユーザは、そ
のメニュー・オプションを選択したときに、そのメニュ
ー内のＬＭＳのメニュー項目をすべて見ることになる。
このプロシジャは初期化時に実行される。

【００６７】図１６の流れ図の他の部分は、プルダウン
・メニューが実際にどう処理されるかを示す。ＬＭＳで
は２種類のメニューがあることに注意されたい。プルダ
ウン・メニューは、ユーザがアクション・バーからリン
クを選択したときに表示されるメニューで、コンテクス
ト・メニューは、マウスでクライアント・ウィンドウが
クリックされたことに応答して表示される。コンテクス
ト・メニューにも同じようなオプションが付加される
が、ユーザがクリックしたオブジェクトとの結びつきが
強い。そのため、これら２種類のメニューの処理で起こ
ることは異なっている。

【００６８】ユーザ・アクションが入ると（機能ブロッ
ク７８）、これはアプリケーションのウィンドウ・プロ
シジャ（機能ブロック７９で表わされる）へ行く。この
ときアプリケーションのウィンドウ・プロシジャは、こ
のアクションは自分が知っている（アプリケーション・
コードで定義されている）メニュー・コマンドではない
と判定することができるので、メッセージをＬＭＳの処
理プロシジャに引き渡す（図６参照）。ＬＭＳは判断ブ
ロック８１で、そのメッセージに対してメニューを表示
する必要があるかどうかを判定する。必要があれば、Ｌ
ＭＳは、適用できるメニュー項目を使えるようにした
り、適用できないものを使えないようにしたり、或いは
項目にチェックを入れたりすることができる（機能ブロ
ック８２）。他の場合、判断ブロック８３で、メッセー
ジがメニュー項目のメッセージかどうかが判定される。
そうでない場合、機能ブロック８４で“非メニュー項目
メッセージ・プロセサ”が呼び出される。このプロシジ
ャについては図１８により後述する。メッセージがメニ
ュー項目であれば、ＬＭＳは先へ進み適切なアクション
を実行しようとする。例えばマーカとリンクのセーブ、
パスワード等、ＬＭＳが処理するメッセージがある。判
断ブロック８５、８６、８７で判定されるように、メッ
セージがＬＭＳによって処理されるものである場合、Ｌ
ＭＳは、次に行われるアクションをクライアント・アプ
リケーションに通知し（機能ブロック８８）、アプリケ
ーションがＬＭＳのコマンド処理に反対しないなら（判
断ブロック８９）、ＬＭＳはその機能を実行し（機能ブ
ロック９０）、アプリケーションに通知し（機能ブロッ
ク９１）、“ＴＲＵＥ”メッセージを返す（機能ブロッ
ク９２）。このように、メッセージがＬＭＳによって処
理されるコマンドの１つであれば、ＬＭＳがそのコマン
ドを実行する（詳細は後述）。そしてＬＭＳは、コマン
ドを実行した後にアプリケーションに通知を出し、通常
は、アプリケーションが何らかの後処理ができるよう
に、このとき対応したばかりのオブジェクトへのハンド
ルもアプリケーションに与える。

【００６９】メッセージが、判断ブロック９３で判定さ
れるように、マーカ操作であれば、マーカが選択された
状態かどうかが判定される（判断ブロック９４）。マー
カが選択された状態になければ、ユーザがそのコマンド
のプルダウン・メニューでそれを変更することはできな
い（コンテクスト・メニューには当てはまらない）。通
常、選択された状態にないオブジェクトにしか作用しな
い項目はグレーにされる。例えば、選択されたマーカが
ない場合、「マーカ移動」はグレーになり、ユーザはこ
れを選択することができない。選択されたマーカがない
場合、「マーカ変更」は行えず、ユーザはそのコマンド
を選択できない。これはコンテクスト・メニューでは異
なる。コンテクスト・メニューでは、適用されない項目
は省略される。いずれの場合でもＬＭＳは、何らかの作
業を行えるかどうかを２重にチェックするためにコード
を提供する。したがって、メニュー項目がマーカに作用
する場合、最初、少なくともマーカが１つ選択されてい
て選択された状態かどうかが判定され、そのとおりなら
先へ進み、適切なマーカ・コマンドすなわち「マーカ変
更」、「リンク作成」、「リンク確立」、「マーカ表
示」、「マーカ消去」等、判断ブロック９５、９６、９
７、９８、９９、及び１００で判定された処理が行われ
る。「リンク作成」と「リンク確立」がマーカ操作とみ
なされるのは、それらがマーカを起点とするリンクを作
成し、マーカまでのリンクを確立するからである。これ
らのコマンドが終了すると、ＬＭＳがコマンドを実行し
たことがアプリケーションに通知され、ＴＲＵＥが返
る。

【００７０】次に、図１７は、コンテクスト・メニュー
処理プロシジャ１０１のロジックを示す流れ図である。
初めに判断ブロック１０２、１０３で、ＬＭＳが表示す
ることになっているコンテクスト・メニューはどのタイ
プかが判定される。判断ブロック１０２では、ドキュメ
ントのコンテクスト・メニューを表示するかどうかが、
判断ブロック１０３では、マーカのコンテクスト・メニ
ューを表示するかどうかが判定される。ＬＭＳがドキュ
メントのコンテクスト・メニューを表示することになっ
ている場合、そのメニューのリソース定義が機能ブロッ
ク１０４にロードされる。ＬＭＳがマーカのコンテクス
ト・メニューを表示することになっている場合は、マウ
ス・メッセージのリソースが機能ブロック１０５にロー
ドされる。ドキュメント・コンテクスト・メニューでも
マーカ・コンテクスト・メニューでもない場合、エラー
・メッセージが返される（機能ブロック１０６）。

【００７１】ＬＭＳがメニューをロードすると隠しウィ
ンドウが作成される（機能ブロック１０７）。これは実
際にはロードされたばかりのメニューを保有するもので
ある。次に、ロードされたメニューが新しいウィンドウ
に追加され（機能ブロック１０８）、そのウィンドウが
メニューを表示するように指示される（機能ブロック１
０９）。メニュー内の項目は、オブジェクトの状態に応
じて除外されることに注意されたい。これは、プルダウ
ン・メニューで項目が使えるようになったり使えないよ
うになったりするのと同様である。このときＬＭＳはユ
ーザの選択を待つ（機能ブロック１１０）。判断ブロッ
ク１１１では、ユーザが実際にメニューをキャンセルし
たか、またはメニューから項目を選択したかどうかが判
定される。メニュー項目が実際に選択されるとコマンド
ＩＤが返される（機能ブロック１１２）。他の場合はＦ
ＡＬＳＥが返される（機能ブロック１１３）。

【００７２】ここまで、メニューが選択されているため
にＬＭＳがユーザ・コマンドを受け取るケースについて
説明した。他の非メニュー・コマンド処理はどのように
なるだろうか。一般にほとんどのウィンドウ・システム
で利用できるフィーチャはメッセージのそれである。メ
ッセージは、オペレーティング・システムから、別のア
プリケーションから、アプリケーション自体から、或い
はアプリケーションを代表するサービスからアプリケー
ションへ送ることができる。このようなメッセージは、
要求、要求に対する応答、実行されたアクション等の、
アプリケーションへの通知である。

【００７３】同様に、ＬＭＳはこのメカニズムを利用し
て、ＬＭＳが実行しようとするアクションをクライアン
ト・アプリケーションが任意に認識、修飾、制限、変
更、或いは防止することを許す。またＬＭＳは、何らか
のアクションが行われた後にメッセージを通してクライ
アント・アプリケーションへの通知を行う。“事前”メ
ッセージも“事後”メッセージも、メッセージによって
表わされるアクションをエンドユーザがＥＩＵを使って
開始したか、または別のクライアント・アプリケーショ
ンが開始したか、或いはクライアント・アプリケーショ
ン自体が開始したかどうかとは無関係に送られる。一般
に、クライアント・アプリケーションはこれらのメッセ
ージを任意に無視し（デフォルト処理に任せる）、それ
らのデフォルト（ＬＭＳ）処理を得る。ただし他のこと
を実行する機会も得られる。

【００７４】例えばＬＭＳが、プルダウン・メニューま
たはコンテクスト・メニューの表示を求められた場合、
ＬＭＳは、メニューに関してアクションが取られる前
に、クライアント・アプリケーションにメッセージを送
ってそれと同じことを通知する。クライアント・アプリ
ケーションは、メニューが実際に表示される前に、ＬＭ
Ｓメニューから何かの項目を使えないようにする、或い
は削除することもできる。同様に、ＬＭＳメニュー項目
が要求された場合（リンク・マーカを作成するため
等）、またはエンドユーザがリンク・マーカを“クリッ
ク”することによってリンク・マーカの“もう一端”の
いずれかにまでナビゲートすることをＬＭＳに要求した
場合、それと同じことを知らせたクライアント・アプリ
ケーションにメッセージが送られる。

【００７５】ＬＭＳは、クライアント・アプリケーショ
ンが任意にＬＳＭハイパーメディア・システムの挙動と
データを制御するための充実したＡＰＩを提供する。実
際、機能の点では、ＬＭＳＡＰＩはＬＭＳＥＵＩの
優れたスーパセットであり、クライアント・アプリケー
ションに強力な機能を提供する。ただし通常は、クライ
アント・アプリケーションがハイパーメディアの参加者
として重要な役割を担うには、ＬＭＳＡＰＩを最小限
利用するだけでよい。

【００７６】図１８は、非メニュー項目メッセージ処理
プロシジャのロジックを示す流れ図である。ここでもユ
ーザが何らかの入力を行い（機能ブロック１１５）、オ
ペレーティング・システムがクライアント・アプリケー
ションのウィンドウ・プロシジャにメッセージを与える
（機能ブロック１１６）。ウィンドウ・プロシジャは、
上述のように、そのメッセージをＬＭＳに渡す（機能ブ
ロック１１７）。

【００７７】この処理プロシジャでは、メッセージがメ
ニュー項目であるかどうかの判定をＬＭＳが省略してい
るとみなされる。メニュー・メッセージ以外のメッセー
ジには、マウス・メッセージ、ＬＭＳ自体からＬＭＳへ
送られた他のウィンドウからのメッセージ（別のアプリ
ケーションに、それがＬＭＳを認識するアプリケーショ
ンかどうかをたずねるメッセージを含む）等がある。非
メニュー項目メッセージ・プロセサは最初、マウス・ボ
タン３が押されたかどうかを判定する（判断ブロック１
１８）。その通りならコンテクスト・メニュー処理が戻
り（機能ブロック１１９）、ユーザがコマンドを入力し
たか、または「取消」を選択したかどうかが判定される
（判断ブロック１２１）。コマンドが選択されていれ
ば、ＬＭＳが基本プルダウン・メニュー処理を行う（機
能ブロック１２２、図１６、図１７）。ＬＭＳは、基本
的には、上述のようにコマンドを実行してクライアント
・アプリケーションに通知を出す。流れ図の記法では、
プロセスは、“プルダウン・メニュー処理実行”が現わ
れるたびに、プルダウン・メニュー処理について図１６
に示した流れ図の先頭には行かず、図１６の機能ブロッ
ク８８に入る。

【００７８】判断ブロック１１８に戻るが、マウス・ボ
タン３が押されなかった場合は、メッセージがＳＨＩＦ
Ｔキーとマウス・ボタン１かどうかが判定される（判断
ブロック１２３）。これはリンクとマーカを作成する操
作である。そのとおりであればＬＭＳがその処理を実行
する（機能ブロック１２４）。その操作でなければコン
テクスト・メニューかどうかが判定される（判断ブロッ
ク１２５）。コンテクスト・メニューなら、どのような
コマンドかが判定される（判断ブロック１２６）。つま
りＬＭＳがコマンドとして定義したコマンドかどうかで
ある。そのとおりならアプリケーションにメッセージが
渡される（機能ブロック１２７）。このメッセージは、
アプリケーションが処理しようとしないので、またＬＭ
Ｓに戻される。そこでＬＭＳは自身のＬＭＳコマンド処
理を行う。メッセージがコンテクスト・メニューでない
場合、ＬＭＳは、そのメッセージを理解できななければ
棄却する。

【００７９】判断ブロック１２５に戻るが、コンテクス
ト・メニューでない場合は、メッセージがＬＭＳメッセ
ージかどうか、すなわちＬＭＳが自身と通信するのに使
うＬＭＳ特有のメッセージかどうかが判定される（判断
ブロック１２９）。ＬＭＳを使用する異なるプロセスを
代表して動くＬＭＳは、これらのメッセージを、クライ
アント・アプリケーションの介入なしに行き来させて通
信し合うこともできる。ＬＭＳメッセージであれば、こ
のタイプのメッセージの一例として考えられるのは、ア
プリケーションがＬＭＳを認識するかどうかについての
問い合わせである（判断ブロック１３１）。でなけれ
ば、そのもう１つのウィンドウは、メッセージを受けた
ときに、呼び出すべきＬＭＳ処理プロシジャを持たな
い。したがって、そのウィンドウはただＦＡＬＳＥを返
し、メッセージを理解できないことを示す。このメッセ
ージが、ＬＭＳを認識するアプリケーションへ届いた場
合、そのアプリケーションはＴＲＵＥを返す（機能ブロ
ック１３２）。メッセージは上述のようにＬＭＳ処理プ
ロシジャに返される。もし判断ブロック１２９で、メッ
セージがＬＭＳメッセージでなかった場合は、そのメッ
セージは破棄される（機能ブロック１３３）。

【００８０】エンドユーザはマウスを使って画面上のオ
ブジェクトを操作する。ＬＭＳは、マウスとＬＭＳオブ
ジェクト（ドキュメント、リンク・マーカ等）のインタ
ラクションを管理する。ＬＭＳがマウス・アクションを
管理する方法はいくつかある。

【００８１】クライアント・アプリケーションは通常マ
ウス・メッセージをＬＭＳに渡す。ＬＭＳは、マウス・
メッセージを受け取ると、ハイパーメディア特有のアク
ションが必要かどうかを判定する。ＬＭＳは、このメカ
ニズムにより、クライアント・アプリケーションの“ク
ライアント・ウィンドウ”（アプリケーションの基本ワ
ークスペース）の上にあるときにマウスを制御すること
ができる。クライアント・アプリケーションは、最初に
ドキュメントを表示したとき、それをＬＭＳに通知し、
ドキュメント名と、ドキュメントが表示されているウィ
ンドウのハンドルを知らせる。ＬＭＳはそこで、ＬＭＳ
データベースから、ドキュメントに関連するすべてのＬ
ＭＳオブジェクトを得る。これでＬＭＳは、クライアン
ト・アプリケーションのクライアント・エリアで発生す
るマウス・メッセージを処理するのに充分な情報を得た
ことになる。これによりＬＭＳは、クライアント・アプ
リケーションのクライアント・ウィンドウ上にコンテク
スト・メニューを表示することができる。（図９参
照）。マウス・メッセージがＬＭＳに渡されたとき、Ｌ
ＭＳは、ドキュメント内のハイパーメディア・オブジェ
クト（リンク、リンク・マーカ等）の状態を判定し、そ
こでコンテクスト・メニューにどのタイプの項目を入れ
るかを決定することができる（“マーカ・セーブ”、
“マーカ消去”等）。このファシリティはまた“高速”
リンクの作成操作にも用いられる。高速リンクでは、ユ
ーザは、マウスを使って２箇所（同じドキュメント内ま
たは別々のドキュメントやプレゼンタ内）をクリックす
るだけで、２つのリンク・マーカ（１箇所に１個）及び
その間のリンクを自動的に作成することができる。普通
これは、エンドユーザが２つのリンク・マーカを個別に
作成して、それからリンクを形成することによって行わ
れる。上記の機能はすべて、クライアント・アプリケー
ションの援助あるいは知識を利用せずに行われ、ＬＭＳ
サービスを利用するすべてのクライアント・アプリケー
ションに共通である。

【００８２】ＬＭＳリンク・マーカは、メッセージをオ
ペレーティング・システムから直接受け取り、オペレー
ティング・システムが“ＬｉｎｋＭａｒｋｅｒ”として
認識するウィンドウのクラスはＬＭＳによって“保有”
される（このタイプのウィンドウがメッセージを受け取
ったときにオペレーティング・システムがＬＭＳコード
を直接起動する）ので、リンク・マーカ・ウィンドウ上
のマウス管理を行うのに、クライアント・アプリケーシ
ョンがメッセージをＬＭＳに“渡す”必要はない。

【００８３】リンク・マーカが、マウスがその上にある
とのメッセージを（オペレーティング・システムから）
受け取ると、ＬＭＳはマウス・ポインタの外観を変え、
リンク・マーカの存在をエンドユーザに知らせる（これ
は特にマーカが“見えない”場合つまりユーザがそれを
操作できるけれども見えない場合に便利である）。また
これによってＬＭＳは、マウスでマーカを“つかみ”、
リンク・マーカの位置やサイズを変えたりすること、リ
ンク・マーカのコンテクスト・メニューを表示すること
（図９参照）、リンク・マーカ関連のリンクを表示する
こと等、リンク・マーカ上の他の多くのマウス・アクテ
ィビティを処理することができる。

【００８４】ＬＭＳはこのほか、ＬＭＳサービスを利用
しないウィンドウ上にマウスがあるときにマウスを管理
することもできる。これは例えば、エンドユーザが、リ
ンクを確立するための高速パス法である“高速”リンク
を使ってリンク・マーカとリンクを作成するときに生じ
る。その場合ユーザは、クライアント・アプリケーショ
ンのドキュメントのある部分にマウス・ポインタがある
ときにマウス・ボタンとキーボードのキーを押し、マウ
スを別のところ（同じドキュメント内または別のドキュ
メント／プレゼンタ内）へ“ドラッグ”し、マウス・ボ
タンを離す（この操作の間、マウスが、リンク終了点と
して有効でないエリアにある場合、マウス・ポインタの
外観が変わることによってそのことがエンドユーザに知
らされる）。このプロシジャでは、２点間にリンク・マ
ーカとリンクを１回のステップで形成することができ
る。この処理の間クライアント・アプリケーションに必
要なのは、上述のようにメッセージをＬＭＳに渡すこと
だけである。

【００８５】ＬＭＳはこの機能を、マウスを排他的に使
用する（マウスがどのウィンドウの上にあるかにかかわ
らずマウス・メッセージをすべて受け取る）ためにオペ
レーティング・システムのサービスを利用することによ
って実現する。マウス・ボタンが離される（操作を終了
するため）とき、ＬＭＳは、マウスがどのウィンドウ
（存在する場合）の上にあるかを判定するためにシステ
ムに問い合わせをする。次に、それがＬＭＳサービスを
利用するアプリケーションかどうかを判定するために、
ウィンドウにメッセージが送られる。メッセージを受け
取るウィンドウがＬＭＳサービスを利用する場合、その
ウィンドウがメッセージを処理する必要はない（また処
理しない）が、このアプリケーションがＬＭＳサービス
を利用すると応答するＬＭＳにそのメッセージを引き渡
す。このプロセスのターゲット・ウィンドウが、ＬＭＳ
サービスを利用するアプリケーションであれば、そのア
プリケーションのマウス・ポインタの位置にリンク・マ
ーカが自動的に作成され、操作の起点とのリンクが形成
される。メッセージへの応答が、このアプリケーション
がＬＭＳサービスを利用しないというものであれば、そ
のアプリケーションへのリンクは確立されるが、マーカ
は置かれない（ＬＭＳはこのようなアプリケーションを
“ｕｎａｗａｒｅ”と呼ぶ）。

【００８６】エンドユーザは、クライアント・アプリケ
ーションのウィンドウ内にリンク・マーカを作成し、削
除、サイズ変更、テキスト変更、及び表示スタイルの変
更が行える。マーカの作成と削除を除き（これには上述
のようにメッセージの引き渡しが必要）、これらの操作
はすべてクライアント・アプリケーションの手を借りず
に行える。ＬＭＳはリンク・マーカを“保有する”ので
（先にも触れたが後で図２０により詳述する）、リンク
・マーカ・ウィンドウの描画と位置づけを制御する。リ
ンク・マーカは、その下のクライアント・アプリケーシ
ョンのデータを反転するように作成することもできる。
データは強調して表示される。クライアント・アプリケ
ーションが、反転したエリアを得るために処理を行う必
要はない。

【００８７】図１９は、ＬＭＳのマーカ作成プロシジャ
のロジックを示す流れ図である。プロセスは機能ブロッ
ク１３５のコマンドの作成からスタートする。つまり、
ユーザが、マーカではなくアプリケーションのクライア
ント・ウィンドウ内のクライアントのワークスペースを
クリックしたときに表示されたリンクのプルダウン・メ
ニューまたはコンテクスト・メニューから、マーカ作成
コマンドが何らかの方法で受け取られているということ
である。クライアントのワークスペースがクリックされ
た場合、そのアクションは、ドキュメントのクリックと
みなされることがあるので、コンテクスト・メニューは
ドキュメント・コンテクスト・メニューと呼ばれる。い
ずれにしろ図１９の流れ図では、作成コマンドがこれら
のソースの１つから来ているとみなされる。

【００８８】最初の操作としてＬＭＳがマウスをとらえ
る（機能ブロック１３６）。これはウィンドウ用語で、
マウス・ポインタの制御が得られたことを意味する。マ
ウス・ポインタの形が変えられ（機能ブロック１３
７）、ＬＭＳがマーカ作成プロセスにかかっていること
が示される。形状は三角形で、ユーザは画面上でこれを
動かして、マーカをセットするところを指示する。

【００８９】次にプロセスはオペレーティング・システ
ムのメッセージを待つ（機能ブロック１３８）。これ
は、アプリケーションが動作を続けられるように新しい
メッセージ処理ループを挿入することによって行われる
が、ＬＭＳはアプリケーションに引き渡す前に全メッセ
ージをフィルタする。機能ブロック１３８は、メッセー
ジ取得ループと呼ばれる小さいループで、メッセージを
探し続ける。通常これを行うのはアプリケーション自体
であるが、ＬＭＳはここでかなり厳密な制御を行う。メ
ッセージが入るたびに、ＬＭＳはそれを調べ、マウスの
捕捉を中止させるメッセージかどうかを判定する（判断
ブロック１３９）。そうでなければメッセージはクライ
アント・アプリケーションに送られる（機能ブロック１
４１）。他の場合マウスの捕捉が終了する（機能ブロッ
ク１４２）。次に判断ブロック１４３で、ユーザがマー
カ作成プロセスをキャンセルしてしまったか、それとも
操作を続けたいのかが判定される。ユーザがキャンセル
していたら、プロセスはキャンセルされる（機能ブロッ
ク１４４）。ユーザが操作を続けたいなら、新しい“マ
ーカ”が作成される（機能ブロック１４５）。（このマ
ーカは、オブジェクト指向プログラミング言語で用いら
れる意味では「オブジェクト」である。）次に実際のマ
ーカ・オブジェクトが、データベースから新しいＩＤを
得（機能ブロック１４６）、マーカ・ウィンドウが作成
される（機能ブロック１４７）。このマーカ・ウィンド
ウはマーカを見える形にしたもので、ウィンドウ・シス
テムでウィンドウが作成されるたびに、上述のようにウ
ィンドウ・プロシジャが割り当てられてそのウィンドウ
に関連づけられる。マーカ・ウィンドウ機能のウィンド
ウ・プロシジャはＬＭＳの動的リンク・ライブラリに存
在する。そのため、マーカがクリックされるか、または
マーカに対して入力があると、リンク・マネジャ・コー
ドが実行されるので、クライアント・アプリケーション
の手を借りる必要がなくなる。マーカ・ウィンドウは、
作成された後、機能ブロック１４８で表示される。

【００９０】図２０はマーカ・ウィンドウ・プロシジャ
のロジックを示す。この発明では、リンク・マーカは、
アプリケーション・ウィンドウ内のウィンドウと考えれ
ばわかりやすく、実際にその通りである。マーカ・ウィ
ンドウ・プロシジャは、クライアント・アプリケーショ
ンのウィンドウ・プロシジャその他のウィンドウ・プロ
シジャに似ており、マーカ・ウィンドウ・プロシジャの
コードはＬＭＳに存在する。メッセージは、機能ブロッ
ク１５１でユーザによって入力され、機能ブロック１５
２のオペレーティング・システムを通り、１５３のマー
カ・ウィンドウ・プロシジャに入る。マーカ・ウィンド
ウがメッセージを受け取ると、マーカ・ウィンドウ・プ
ロシジャは、その実行がユーザによって指示されている
かどうかをチェックする。例えば、判断ブロック１５４
で、ボタン３が押されている状態かどうかが判定され
る。マウス・ボタン３が押されていれば、マーカがマー
カ・コンテクスト・メニューを表示する（機能ブロック
１５５）。これが、ＬＭＳの実施例ではユーザがウィン
ドウ上でボタンを押すことによってコンテクスト・メニ
ューを引き出す方法だからである。コンテクスト・メニ
ューからコマンドが実際に選択されたかどうかはコンテ
クスト・メニュー・プロセサが応答する（判断ブロック
１５６）。コマンドが選択されていれば、ＬＭＳが基本
的にはプルダウン・メニュー処理に入る − 機能ブロッ
ク１５７、図１６（起点は機能ブロック８８）、図１
７。つまりＬＭＳは、ＬＭＳがコマンドを実行するのを
クライアント・アプリケーションが妨げようとする場合
を考慮して、実際にコマンドを実行する前に通知メッセ
ージをクライアント・アプリケーションに与える。ＬＭ
Ｓはまた、コマンドを実行した後にもメッセージをクラ
イアント・アプリケーションに送る。ＬＭＳが内部でコ
マンドを実行しようとするときは、ＬＭＳは常に最初は
特別なＬＭＳメッセージでクライアント・アプリケーシ
ョンに通知を出す。ＬＭＳがコマンドを実行した後は、
ＬＭＳは必ず、ＬＭＳがコマンドを実行したというメッ
セージをクライアント・アプリケーションに知らせる。

【００９１】ユーザ入力がごく普通のマウス・クリック
だったらどうだろうか？（判断ブロック１５８）その場
合、メッセージがマウス・ボタン１のダブル・クリック
かどうかが判定される（判断ブロック１５９）。その通
りであればリンクがたどられる（機能ブロック１６
１）。Ｃ＋＋の“マーカ・オブジェクト”は、それに関
連づけられたリンク及びリンクの終わりについての情報
をすべて把握しており、この情報はすべてデータベース
に格納されるので、ＬＭＳはリンクをたどることができ
る。一方メッセージがマウス・ボタン２のダブル・クリ
ックであれば（判断ブロック１６２）、ＬＭＳはダイア
ログ・ボックスを表示し（機能ブロック１６３）、マー
カから派生するすべてのリンクをユーザに示す。

【００９２】マウス・クリックがこうしたマウス・クリ
ック・メッセージのいずれでもなければ、ＬＭＳは、マ
ウス・ボタンと同時にコントロール・キーが押されたか
どうかをチェックする（判断ブロック１６４、１６
５）。その場合ＬＭＳは何らかの直接操作を行う。直接
操作とは、ユーザがコントロール・キーを押し、マウス
を使ってマーカを移動させるか（機能ブロック１６６）
またはマーカのサイズを変更する（機能ブロック１６
７）ことである。

【００９３】判断ブロック１５８に戻るが、メッセージ
がマウス・クリックでなければ、描画メッセージかどう
かが判定される（判断ブロック１６８）。それならば再
描画するためにマーカがそのウィンドウを閉じる（機能
ブロック１６９）。

【００９４】図２１は、ウィンドウ描画処理のロジック
を示す流れ図である。オペレーティング・システムは、
先に説明した他の処理の場合と同じようにＬＭＳにメッ
セージを送る（機能ブロック１７１）。このときのメッ
セージは直接マーカ・ウィンドウ・プロシジャ（１７
２）に入る。マーカが、最初にクライアント・アプリケ
ーションを通過する必要なくメッセージを受け取るから
である。マーカ・ウィンドウは、メッセージが描画メッ
セージかどうかを判定する（判断ブロック１７３）。描
画メッセージなら、つまりウィンドウを再描画する必要
があるとオペレーティング・システムが言っているな
ら、マーカは、データベースを調べることによって、マ
ーカ・スタイルがどのようなものかを判定する（判断ブ
ロック１７４）。トランスペアレントでない（それを通
して見ることができない）スタイルは２つある。１つは
モノクロかつ２次元で、もう１つはプッシュ・ボタンと
いい、３次元表示であり、押されたときにその状態が見
える。他のスタイルはどれもトランスペアレントで、図
２２に示すように、反転または強調されたビデオ・フレ
ームの形で表わされる。

【００９５】透視できるタイプのマーカでなければ（す
なわちプッシュ・ボタンかモノクロ）、マーカが描かれ
る（機能ブロック１７５）。トランスペアレントなスタ
イルのマーカであれば、マーカは隠される（機能ブロッ
ク１７６）。言い替えるとマーカ・ウィンドウ全体が画
面から消去される。マーカ・ウィンドウが画面から消去
されると、下の親ウィンドウにそれ自体の再描画が指示
される（機能ブロック１７７）。これによりすべてが、
つまり親ウィンドウの全データが最新のカレントにな
る。この後すぐマーカが表示される（機能ブロック１７
８）が、親ウィンドウは、境界の描画または反転表示が
求められるまでは再描画されない。

【００９６】Microsoft WindowsとOS/2 PMでは、トラン
スペアレンシのためにパレット上に予約されるビットは
ないので、ウィンドウは、ユーザが透視でき、いつでも
正しく更新されるようにはならない。WindowsとOS/2 の
プレゼンテーション・マネジャのウィンドウは半透明で
ある。通常、アプリケーションによってウィンドウが作
成されたときは、ウィンドウは画面の上にくる。すなわ
ちオペレーティング・システムが、それ自体を描画する
ように指示し、そのとおり実行される。もちろん、ウィ
ンドウの上で描画するときに何が起こるかといえば、あ
るウィンドウをとらえて、別のウィンドウの最上部に置
いたときのように、オペレーティング・システムが実際
にウィンドウを描くのではなく、白い背景、テキスト等
でウィンドウを埋めるだけである。これは例えば図２３
からわかる。図２３は色々なタイプのウィンドウ、スク
ロール・バー、アイコン、プッシュ・ボタン等を示す。
オペレーティング・システムは、画面のあるエリアを予
約することによってウィンドウを作り、マウス・クリッ
クが行われたとき、そのウィンドウ・プロシジャ・メッ
セージを送るが、ユーザはまだそのウィンドウを通して
下のウィンドウを見ることはできない。したがって、ト
ランスペアレント・ウィンドウを実現した場合に表面が
どのように見えるかは、実際には自分を描いていないウ
ィンドウのようなものにすぎない。

【００９７】しかし残念ながら現実はそれほど簡単では
ない。オペレーティング・システムが、作成された新し
いウィンドウに自分を描くことを指示するときは、可能
性としてはまず、そのウィンドウが、トランスペアレン
トになるために自分を描くことはないと考えられる。但
しそのウィンドウは本当にトランスペアレントになるわ
けではない。画面のそのエリア上のビットが描かれない
だけである。そのため、別のウィンドウが“トランスペ
アレント”ウィンドウの上に置かれ、それから消去され
ると、“トランスペアレント”ウィンドウがその上にあ
ったウィンドウは、“トランスペアレント”ウィンドウ
が存在するエリアを除いて自分を再描画する。ウィンド
ウが他のウィンドウの上に描画されることはないからで
ある。また“トランスペアレント”ウィンドウは自分を
描こうとはしない。画面上にあったビットは、“トラン
スペアレント”ウィンドウとその上のウィンドウの上に
あった第３のウィンドウからのビットである。そのため
画面は正しく表示されない。

【００９８】この問題を解決する方法は、図２１に示し
たウィンドウ描画処理プロシジャにある。具体的には、
第３のウィンドウがトランスペアレント・ウィンドウの
上に置かれ、消去された場合、オペレーティング・シス
テムは、トランスペアレント・ウィンドウに描画メッセ
ージを送る。ウィンドウが実行するのは、全く描画しな
いことではなく、画面のこの部分のビットが第３のウィ
ンドウのものであることを認識することである。第３の
ウィンドウは消去されている（描画メッセージの受理に
よって示される）ので、トランスペアレント・ウィンド
ウはその下のものが見えるようにしなければならない。
これを行うために、トランスペアレント・ウィンドウは
自分を隠す（図２１の機能ブロック１７６）。オペレー
ティング・システムにはこれを行う機能がある。親ウィ
ンドウは次に、描画メッセージをオペレーティング・シ
ステムから取得する。このメッセージでトランスペアレ
ント・ウィンドウが親ウィンドウに直ちに動作するよう
に指示する。このとき親ウィンドウは自分を描く（機能
ブロック１７７）。ウィンドウは、見える別のウィンド
ウの上に描画されることはないが、ウィンドウが他の画
面エリアで見えない（つまり隠れている）場合はそこで
描画される。したがってこのプロシジャは、ウィンドウ
を隠し、親ウィンドウにトランスペアレント・ウィンド
ウがあったエリアで自分を描くことを指示することであ
る。こうして画面はすべてリフレッシュされ、最新のカ
レント状態になる。

【００９９】ここでトランスペアレント・ウィンドウを
もう１度表示させなければならない。トランスペアレン
ト・ウィンドウが再表示されると、オペレーティング・
システムはこれを認識し、ウィンドウに自分を描くこと
を指示するが、トランスペアレント・ウィンドウは、エ
ンドユーザがこれを通して下のデータを見ることができ
るように自分を描こうとはしない！これはＯＳ／２の
ＰＭでは即座に行われ、トランスペアレント・ウィンド
ウが効果的に作成される。ここでもトランスペアレント
・ウィンドウは、必要なら何らかの描画を行える。例え
ば図２２に示すように、トランスペアレント・ウィンド
ウが占める画面の四角形のエリアにあるビットを反転さ
せて反転表示にするか、ウィンドウの境界にワイア・フ
レームを描く等である。図２２の場合、画面１４（図
１）上に反転表示で強調されたテキストを示す画面表示
であるが、これは実際には強調されたテキストではな
く、トランスペアレント・ウィンドウである。

【０１００】エンドユーザとアプリケーションのインタ
ラクションにはメニューのほかにダイアログ・ボックス
の使用がある。ダイアログ・ボックスはタスクに必要な
情報をエンドユーザから集める。ＬＭＳは、クライアン
ト・アプリケーションがハイパーメディアをフルにサポ
ートするのに必要なダイアログ・ボックスをすべて提供
し管理する。図２４、図２５、図２６は、ＬＭＳによっ
て提供されるダイアログ・ボックスの例を示す。図２４
はリンク・マーカのスタイルの指定をエンドユーザに求
めるダイアログ・ボックスの例である。図２５は管理の
ために（リンク・マーカのアブストラクトを表示する、
リンクをたどる等）リンクの選択をエンドユーザに求め
るダイアログ・ボックスの例である。図２６は、ハイパ
ーメディア・データベースをサーチするためにキーワー
ドの入力をユーザに求めるダイアログ・ボックスの例で
ある。

【０１０１】クライアント・アプリケーションは、ダイ
アログ・ボックスを表示または管理するためにＬＭＳサ
ービスを呼び出す必要はない。このサポートはＬＭＳが
自動的に提供する。これによりＬＭＳサービスを利用す
るアプリケーションはすべて、クライアント・アプリケ
ーションが変わっても一貫したハイパーメディア・ダイ
アログ・ボックスを提供することができる。

【０１０２】ＬＭＳは全ダイアログ・ボックスの定義
（外観／動作）を格納する。エンドユーザがハイパーメ
ディア・サービス（通常はメニューの使用）を要求した
とき、ＬＭＳは要求の実行を開始する。その間、ダイア
ログ・ボックスの表示が必要（他の情報が必要等）と判
断された場合は、ＬＭＳがそれらを表示する。ハイパー
メディア・ダイアログ・ボックスはいずれもＬＭＳオブ
ジェクト（リンク、リンク・マーカ等）に関連している
ので、ＬＭＳは、クライアント・アプリケーションの協
力がなくてもエンドユーザの要求をオブジェクトに適用
することができる。

【０１０３】図２７は、ダイアログ・ボックス管理のロ
ジックの流れ図である。ＬＭＳコマンド・プロセサ１８
１が実行する各コマンド（マーカ作成、リンク形成、事
項変更等）について、ダイアログ・ボックスが必要かど
うかが判定される（判断ブロック１８２）、答えが肯定
ならＬＭＳはダイアログ・ボックスを表示する（機能ブ
ロック１８３）。このようなダイアログ・ボックスはメ
ニューと同じようにＬＭＳリソースとともに格納され
る。クライアント・アプリケーションと一緒に格納され
ることはない。ユーザ・インタフェースはそっくりＬＭ
Ｓとともに格納される。つまりモジュール形式であり、
ＬＭＳの新バージョンが導入された場合は、新しいユー
ザ・インタフェースが、クライアント・アプリケーショ
ンの１部としてエンドユーザに提示される。クライアン
ト・アプリケーション・コードを書き換える必要がな
い。

【０１０４】いずれにしてもダイアログ・ボックスは、
ＬＭＳがどのオブジェクトを操作の対象にしているか
（マーカかドキュメントかリンクか等）に応じて表示さ
れる。ダイアログ・ボックスが、それとユーザとのイン
タラクションに基づいてオブジェクトを変更する（判断
ブロック１８４）。そしてＬＭＳが何らかの変更を加え
ようとしていることをアプリケーションに伝えるメッセ
ージがアプリケーションに送られ（機能ブロック１８
５）、ここでアプリケーションは継続できるかどうかを
応答する（メッセージ・ブロック１８６）。アプリケー
ションが継続できると応答すれば、ＬＭＳはコマンドを
処理し（機能ブロック１８７）、上述のようにアプリケ
ーションに通知を出す（機能ブロック１８８）。

【０１０５】判断ブロック１８４に戻るが、ダイアログ
・ボックスがオブジェクトを変更するのでなければ、Ｌ
ＭＳは、アプリケーションが変更を加えるべきかどうか
をアプリケーションに聞くことはしない。その代わりＬ
ＭＳはコマンドを処理する（機能ブロック１８９）。

【０１０６】最後に、ダイアログ・ボックスが判断ブロ
ック１８２で判定されたように用いられない場合、さら
に判断ブロック１９１で直接操作が必要かどうかが判定
される。直接操作はここでも、メニュー項目を選択する
ことではなくマウスでマーカをつかむことである。つま
りメニューが関係することはなく、キーボードとマウス
を使って、ものを選択し、それに対してことを行い、リ
ンクを作る等である。直接操作が必要な場合、ＬＭＳは
メッセージをアプリケーションに送る（機能ブロック１
９２）。例えば直接操作がマーカを移動させることであ
れば（ところでマーカとは、ユーザがプルダウン・メニ
ューから選択できる項目である）、ＬＭＳは、あたかも
ユーザがその機能をプルダウン・メニューから選択した
かのように、マーカを移動させようとするというメッセ
ージをアプリケーションに送る。これによりクライアン
ト・アプリケーションは、ユーザがこのようなアクティ
ビティを実行するために使う方法を意識する必要がな
い。前述のとおり、ＬＭＳは、アプリケーションが先に
進むかどうかの応答を待つ。アプリケーションが先に進
めると応答すれば、他の場合と同様、コマンドを処理し
てからアプリケーションに通知を出す（機能ブロック１
８８）。

【０１０７】ＬＭＳが提供するＥＵＩの他のエリアの場
合と同じく、クライアント・アプリケーションがハイパ
ーメディアをサポートする必要がなくても、クライアン
ト・アプリケーションは、ＬＭＳが提供したダイアログ
・ボックスの変更、エンハンス、表示の防止等を行え
る。またクライアント・アプリケーションが、ＬＭＳの
ダイアログ・ボックスを、ＬＭＳがそれを必要とみなし
たときだけではなくその選択時にも表示するためのサー
ビスが提供される。

【０１０８】ドキュメント間リンクのサポートに必要な
情報はすべて、ウェブという別のデータベース（図５参
照）内にＬＭＳによって維持される。クライアント・ア
プリケーションのデータを入れるファイルは、そのアプ
リケーションがＬＭＳサービスを利用するために変更す
る必要はない。その代わり、すべてのハイパーメディア
・オブジェクトの、理論上はパラレルな“ビュー”また
は“オーバレイ”がウェブ・データベースに格納され
る。クライアント・アプリケーションは、このデータベ
ースのフォーマットも、データベースへのアクセスも考
慮する必要がない。これらはすべてＬＭＳによって処理
される。このデータベースは、シングルユーザのワーク
ステーション環境、或いはマルチ・ワークステーション
／ユーザ／プロセス（ネットワーク等）環境でも使え、
更新を含めてデータベース・アクセスを共有することが
できる。ＬＭＳのハイパーメディア・オブジェクトはし
たがって、クライアント・アプリケーションが終了した
後でも（データベース内に）存続し、クライアント・ア
プリケーションがそのドキュメントを表現するのに再び
用いられるときにも使えるようになる。以下、クライア
ント・アプリケーションの負担を大幅に軽減するこの設
計について述べる。

【０１０９】ハイパーメディア・オブジェクトはドキュ
メント、プレゼンタ、リンク・マーカ、及びリンクであ
る。ＬＭＳは新しいハイパーメディア・オブジェクト及
び変更されたハイパーメディア・オブジェクトをすべて
データベースにセーブし、削除が要求されたハイパーメ
ディア・オブジェクトをすべてデータベースから除外す
る。これはそれを要求されたとき（エンドユーザまたは
クライアント・アプリケーションによって）、また、ク
ライアント・アプリケーションが終了したとき（エンド
ユーザまたはクライアント・アプリケーションによって
終了しないように要求されていない場合）に行われる。

【０１１０】ハイパーメディア・オブジェクトがすでに
データベースにあった場合クライアント・アプリケーシ
ョンが自分とそのドキュメントをＬＭＳに示すと、ＬＭ
Ｓは関連するハイパーメディア・オブジェクト・データ
をデータベースから自動的にロードし、その時点でクラ
イアント・アプリケーションによって表示されているド
キュメントの部分に適したリンク・マーカを表示する。

【０１１１】ハイパーメディア・オブジェクトがデータ
ベースにない場合クライアント・アプリケーションが最
初にＬＭＳに認識されたとき（クライアント・アプリケ
ーションがＬＭＳＡＰＩを介してＬＭＳに“チェック
イン”したとき）、クライアント・アプリケーションに
ついてのＬＭＳデータ（その名前等）を持つプレゼンタ
・オブジェクトがＬＭＳによって自動的に作成される。
これはドキュメント・オブジェクトでも同じである。Ｌ
ＭＳは、エンドユーザによって（ＬＭＳＥＵＩを使
用）またはクライアント・アプリケーションによって
（ＬＭＳＡＰＩを使用）要求されたときはリンク・マー
カとリンク・オブジェクトを作成する。後者（ＬＭＳ
ＡＰＩ）の例として、ヒューリスティックなクライアン
ト・アプリケーション或いは他のＡＩ（人工知能）クラ
イアント・アプリケーション、或いは、既に存在する
（おそらくは大量の）機械可読情報に関してドキュメン
ト、リンク・マーカ、及びリンク・オブジェクトを動的
に（エンドユーザの手を借りずに）作成するように書か
れたプログラム等があげられる。機械可読情報のフォー
マット、内容、及びセマンティック・アソシエーション
は、利用度の高い（おそらくは非線形の）ハイパーメデ
ィア・アソシエーションのウェブ・データベース（機器
の保守情報、百科事典、医療情報、人材情報、系統的学
習やアリストテレス的な発見を可能にする教育コース、
販売／カタログ情報、辞書等）が得られるようにプログ
ラムによって認識または発見される。

【０１１２】図２８、図２９は、ＬＭＳデータベースの
保守に関する流れ図である。図２９に示したプロシジャ
は図２８のプロシジャから呼び出される。データベース
保守プロシジャは、ハイパーメディア・システムのユー
ザがドキュメント、リンク・マーカ、リンク等を作成、
変更、或いは削除したときに起動される。図２８、図２
９で、データベース・オブジェクトとの関係からロック
とアンロックに言及するのは、それらを他に利用できる
範囲を説明するためである。ロックは、排他的使用権を
得ることを、アンロックは排他的使用権を解除して他が
使用できるようにすることをいう。したがって、あるプ
ロセスがＬＭＳのドキュメント・データベース・オブジ
ェクトをロックした場合、他のプロセスは、オブジェク
トがアンロックされるまでは、データベース内のそのオ
ブジェクトへアクセスすることができない。プロセスが
ＬＭＳデータベース（全体）をロックした場合、他のプ
ロセスは、データベースがアンロックされるまではデー
タベース内のどのオブジェクトもアクセスすることがで
きない。

【０１１３】まず図２８について述べる。ＬＭＳデータ
ベース更新プロシジャでは最初、判断ブロック２０１
で、更新対象のドキュメントがデータベースに存在する
かどうかが判定される。存在する場合、ドキュメントは
データベース内でロックされる（機能ブロック２０
２）。他の場合ドキュメントは機能ブロック２０３でロ
ックされるが、いずれの場合でも、さらに、ドキュメン
トが削除されるかどうかが判定される（判断ブロック２
０４）。削除される場合、プロセスは最初のループに入
り、ドキュメントに属するリンク・マーカが識別されて
削除される。このループの先頭は判断ブロック２０５
で、ここで、これがこのドキュメントに属する最初のリ
ンク・マーカかどうか、または別のリンク・マーカがあ
るかどうかが判定される。肯定なら、リンク・マーカに
削除のためのフラグが立てられ（機能ブロック２０
６）、プロシジャ２０７においてリンク・マーカとその
リンクがデータベースから除外される。これはリンク・
マーカとリンクのデータベースの更新プロシジャ（ＬＭ
ＬＤＢＵ）を呼び出すことによって行われる（図２９に
より後述）。このプロシジャからのリターン後、プロセ
スは判断ブロック２０５にループバックする。

【０１１４】判断ブロック２０５での判定が、リンク・
マーカがないか、または全リンク・マーカにフラグが立
てられていることを示す場合、ドキュメントはデータベ
ースから削除される（機能ブロック２０８）。次に判断
ブロック２０９で、ドキュメントがデータベースに存在
していたかどうかが判定される。そうならプロシジャが
終了する前にドキュメントのロックがデータベース内で
破壊され（機能ブロック２１０）、他の場合はプロシジ
ャが終了する前に最初にデータベースがアンロックされ
る（機能ブロック２１１）。

【０１１５】判断ブロック２０４に戻るが、ドキュメン
トが削除されないとすると、第２のループが取られ、ド
キュメントに属するリンク・マーカが識別され、更新が
行われる。このループの先頭は判断ブロック２１２で、
ここで、これがこのドキュメントに属する最初のリンク
・マーカか、または他にリンク・マーカがあるかどうか
が判定される。肯定ならさらに、判断ブロック２１３に
おいてリンク・マーカが新しいものか、変更されている
か、或いは削除されているかが判定される。肯定であれ
ば、プロシジャ２１４が呼び出され、リンク・マーカと
そのリンクがデータベース内で更新される。プロシジャ
２１４はプロシジャ２０７と同じであり、これも図２９
により後述する。プロシジャ２１４から戻った後、また
はリンク・マーカが新しくないか、変更されているか、
または削除されている（判断ブロック２１３）場合、プ
ロセスは判断ブロック２１２にループバックする。

【０１１６】すべてのリンク・マーカが識別、更新され
ると、ループが終了して判断ブロック２１５が取られ、
ここでドキュメントが新規かまたは変更されているかど
うかが判定される。肯定なら、ドキュメント・オブジェ
クト・データがデータベースに書き込まれる（機能ブロ
ック２１６）。いずれにしてもドキュメントがデータベ
ースに存在していたかどうかが判定される（判断ブロッ
ク２１７）。存在していた場合、プロシジャが終了する
前にドキュメントがデータベース内でアンロックされる
（機能ブロック２１８）。他の場合プロシジャが終了す
る前にデータベースがアンロックされる（機能ブロック
２１１）。

【０１１７】次に図２９について述べる。リンク・マー
カとリンクのデータベースの更新プロシジャが図２８の
プロシジャ２０７または２１４で呼び出されたとき、最
初に判断ブロック２２１で、リンク・マーカがデータベ
ースに存在するかどうかが判定される。そうならリンク
・マーカがデータベースでロックされる（機能ブロック
２２２）。他の場合データベースがロックされる（機能
ブロック２２３）。いずれの場合でもリンク・マーカが
削除されるかどうかが判定される（判断ブロック２２
４）。削除される場合はプロシジャは最初のループに入
り、リンク・マーカにつながるリンクが識別され、これ
らのリンクが削除される。このループの先頭は判断ブロ
ック２２５で、ここで、これがリンク・マーカにつなが
る最初のリンクかまたは別にリンクがあるかどうかが判
定される。肯定なら、リンクのもう一端のリンク・マー
カがデータベースでロックされる（機能ブロック２２
６）、次にもう一端のリンク・マーカがデータベースか
ら読み出され、リンクがデータベースから切断され、も
う一端のリンク・マーカが再びデータベースに書き込ま
れる（機能ブロック２２７）。リンクのもう一端のリン
ク・マーカがデータベース内でアンロックされ（機能ブ
ロック２２８）、そこでプロセスが判断ブロック２２５
にループバックする前にリンクがデータベースから削除
される（機能ブロック２２９）。

【０１１８】全リンクが識別されると、ループが終了し
て機能ブロック２３０が取られ、ここでリンク・マーカ
がデータベースから削除される。次に、リンク・マーカ
が前にデータベースに存在していたかどうかが判定され
る（判断ブロック２３１）。その通りならプロセス終了
前にリンク・マーカのロックが破壊され（機能ブロック
２３２）、他の場合にはプロセス終了前に最初にデータ
ベースがアンロックされる（機能ブロック２３３）。

【０１１９】判断ブロック２２４に戻るが、リンク・マ
ーカが削除されない場合は、プロセスは第２のループに
入り、リンク・マーカにつながるリンクが識別され、更
新が行われる。このループの先頭は判断ブロック２３４
である。ここで、これがリンク・マーカにつながる最初
のリンクかまたは他にリンクがあるかどうかが判定され
る。肯定ならリンクが新しいか、変更されているか、ま
たは削除されているかが判定される（判断ブロック２３
５）。肯定ならリンクが削除されるかどうかが判定され
る（判断ブロック２３６）。削除される場合はリンクの
もう一端のリンク・マーカがデータベース内でロックさ
れる（機能ブロック２３７）。次にもう一端のリンク・
マーカがデータベースから読み出され、リンクがデータ
ベースから切断され、もう一端のリンク・マーカが再び
データベースに書き込まれる（機能ブロック２３８）。
リンクのもう一端のリンク・マーカがデータベース内で
アンロックされ（機能ブロック２３９）、プロシジャが
判断ブロック２３４にループバックする前にリンクがデ
ータベースから削除される（機能ブロック２４０）。リ
ンクが削除されず、新規かまたは変更されている場合
は、プロシジャが判断ブロック２３４にループバックす
る前にリンク・オブジェクト・データがデータベースに
書き込まれる（機能ブロック２４１）。

【０１２０】全リンクが識別、更新されると、ループは
終了し、判断ブロック２４２でリンク・マーカが新規か
または変更されているかどうかが判定される。肯定なら
リンク・マーカのオブジェクト・データがデータベース
に書き込まれる（機能ブロック２４３）。いずれの場合
でもさらに、リンク・マーカがデータベースに存在して
いたかどうかが判定される（判断ブロック２４４）。そ
の通りならリンク・マーカがデータベース内でアンロッ
クされる（機能ブロック２４５）。他の場合プロシジャ
が終了する前にデータベースがアンロックされる（機能
ブロック２３３）。

【０１２１】ＬＭＳは、クライアント・アプリケーショ
ンの負担を軽減するメカニズムを提供するが、クライア
ント・アプリケーションを制約するのは望ましくない。
負担が軽減されるときはしばしば、アプリケーションが
実際にその機能に制約を受けることがある。ＬＭＳがコ
マンドを処理する前に必ず通知メッセージを送る理由は
そこにある。

【０１２２】クライアント・アプリケーションには、あ
る特定のＬＭＳオブジェクト（特にマーカやリンク等）
とのそれ自身のリンクについての情報を格納する方法が
与えられる。例えばテキスト・エディタ・アプリケーシ
ョンがリンク・マーカ・サービスで自分を使えるように
して、そのファイル内のどの行番号にマーカが関連づけ
られているかを知りたい場合、ＬＭＳはクライアント・
アプリケーションのデータを知らず、したがってＬＭＳ
は行が何かを認識しない。この問題を解決するために、
ユーザ・データと呼ばれるＬＭＳオブジェクト（マーカ
とリンク）の各々にエリアが設けられ、このエリアのデ
ータにアクセスするためのＡＰＩが提供される。基本的
にはこれはＬＭＳがそこに格納されているデータを認識
しないエリアである。これはアプリケーションがデータ
を格納できるエリアである。ＬＭＳは、そのデータが全
くのバイナリ・データなので調べず、アプリケーション
は何でもそこに格納することができる。例えばマーカが
５行目に属することを知っている場合、アプリケーショ
ンは何らかの構造体をユーザ・データにセットするか、
または任意に整数１個をセットし、このマーカが５行目
に当たることを伝えることができる。そこでＬＭＳはと
もかくデータを、マーカ・オブジェクトとともにウェブ
・データベースに格納する。エディタが次にドキュメン
トを表示し、マーカとリンクをすべてロードすることを
ＬＭＳに指示すると、ＬＭＳが各マーカをたどり、ＬＭ
Ｓによって提供された機能を使ってマーカを列挙する。
そのとき各マーカについて、マーカに関連するユーザ・
データを識別する。この例の場合、ユーザ・データはア
プリケーションが格納したものと同じである。ＬＭＳが
ともかくアプリケーションが格納したデータを提供す
る。ＬＭＳはそのデータにどんな意味があるかを知らな
いが、アプリケーションは、そのマーカが５行目に当た
ることを意味するものと認識する。この時点でアプリケ
ーションは、ＡＰＩを通してマーカを再配置する等、ア
プリケーションが望む操作を行える。

【０１２３】これはリンクについても同じである。リン
クのユーザ・データは、マーカのユーザ・データと全く
同じように動く。リンク・ユーザ・データの使用例とし
ては、リンクが確立されるたびに、アプリケーション
が、リンクの作成時にその状態がどうだったかについて
の情報を維持しようとする場合（アプリケーションがタ
イトル・バーを持つことができるかどうか等）があげら
れる。アプリケーションが実行したいことは、そのリン
ク・ユーザ・データ（すなわちリンクが完成したときに
タイトル・バーを持たないということ）を格納すること
かもしれない。別の場合、もしタイトル・バーを持って
いるとしたら、アプリケーションがそのリンクを格納す
ることになる。そのリンクがたどられ、アプリケーショ
ンが起動されてそのドキュメントがロードされるとき、
アプリケーションは、このリンク内のユーザ・データを
チェックする。ユーザ・データは、このリンクが作成さ
れたときにアプリケーションはタイトル・バーを持って
いなかったことをアプリケーションに教える。それでア
プリケーションはそのタイトル・バーを隠すが、他のリ
ンクが検出されると、アプリケーションには、それがタ
イトル・バーを持っていたことがユーザ・データによっ
て教えられるので、タイトル・バーが表示される。

【０１２４】ＬＭＳはユーザ・データを理解しない。こ
れは、アプリケーションが各リンク、各マーカとともに
維持しておける小さいノートのようなものである。また
ＬＭＳは、リンクとマーカの両方を伴うユーザ・キーと
いうものを持つ。これはアプリケーションにとっては、
マーカまたはリンクを素早くソートしてファイルにしま
うための手段である。これはキーであるから、アプリケ
ーションがいつでも特定のマーカ項目を１つアクセスし
たいが、多くのマーカ（たとえば数千）がドキュメント
に関連する場合、アプリケーションは、特別に長い値を
マーカに割り当てることができる。ほとんどのＬＭＳ機
能が、ユーザ・キーをパラメータとするので、ユーザが
最初のマーカを検索したい場合は、ＬＭＳは単に、マー
カ全部から見つけられる最初のマーカを返す。しかしユ
ーザが、ユーザ・キーが１０である最初のマーカの検索
を求める場合、ＬＭＳがすべてのマーカをサーチし、ど
のマーカにユーザ・キー１０があるかを判定する。

【０１２５】ＬＭＳは、エンドユーザによる（ＬＭＳ
ＥＵＩを使用）ハイパーメディア・オブジェクトの削除
及びクライアント・アプリケーションによる（ＬＭＳ
ＡＰＩを使用）その削除を可能にする。リンクがリンク
・マーカから削除されると、ＬＭＳはそのもう一端を、
それが結びつけられたリンク・マーカから自動的に削除
する。リンク・マーカがドキュメントから削除される
と、ＬＭＳはドキュメントに結びつけられたすべてのリ
ンクを自動的に削除する。ドキュメントが削除される
と、ＬＭＳはドキュメントのすべてのリンク・マーカを
削除する。

【０１２６】ドキュメント、リンク・マーカ、及びリン
クの属性は、エンドユーザが（ＬＭＳＥＵＩを使っ
て）、或いはクライアント・アプリケーションが（ＬＭ
ＳＡＰＩを使って）変更することができる。例えばリ
ンク・マーカのスタイル、サイズ、位置等をこれらのフ
ァシリティを使って変更することができる。

【０１２７】リンク・マーカ、リンク、ドキュメント、
及びプレゼンタについての情報はすべて、ＬＭＳによっ
て管理されるデータベースに維持されるので、ＬＭＳ
は、エンドユーザがリンクをたどろうとしたとき、どの
プレゼンタでどのドキュメントをもってくるかを判定す
ることができる。リンク・マーカは、クライアント・ア
プリケーションの介入なく自身のメッセージを取得して
処理するので（上記の「マウス処理」参照）、ＬＭＳは
リンクがどこへ行くか（プレゼンタＰがドキュメントＤ
を必要ならリンク・マーカＭに対して位置づける等）を
データベースに問い合わせることによって判定できる。
ＬＭＳはアプリケーションを投入（起動）できるので、
エンドユーザはＬＭＳによってリンクをたどることがで
き、クライアント・アプリケーションの手を借りる必要
がない。

【０１２８】ＬＭＳは、ハイパーメディアをサポートす
る（よってクライアント・アプリケーションのコード化
作業と開発時間を少なくする）のに必要な作業のほとん
どを引き受けるために何でもこなすとしても、クライア
ント・アプリケーションが、ハイパーメディア・システ
ムの挙動やデータの変更に関して制御を行えないように
するのは望ましくない。ＬＭＳはこの制御機能を、メッ
セージとアプリケーション・プログラミング・インタフ
ェース（ＡＰＩ）を通して提供する。

【０１２９】上述のように、リンク・マーカのＬＭＳ的
なプッシュ・ボタンは２つのスタイルに分けられる。１
つは外観は“３次元”で、“押された”ときにその動き
が表示され、もう１つは“モノクロ”と呼ばれ、外観は
２次元である。いずれについても任意に、リンク・マー
カのリンクがナビゲートされる場合に取得される情報を
簡単に記したテキストを入れることができる。したがっ
てリンク・マーカのテキストは、リンク・マーカのリン
クのもう一端にある情報を短くまとめたものと考えるこ
とができる。

【０１３０】リンク・マーカに入ったテキストのほか
に、ＬＭＳは、リンク・マーカによって保有されるリン
ク・マーカ・アブストラクト・オブジェクトを実現す
る。これはリンク・アブストラクト・データで、保有す
るリンク・マーカの位置で検出できる情報についてのア
ブストラクト・テキスト情報と定義される。ＬＭＳが、
対象となるリンク・マーカ候補のリストをユーザに提示
するとき（リンクが２つ以上伸びているリンク・マーカ
をユーザが“クリック”した結果、またはリンク・マー
カ・アブストラクトをサーチした結果）、対象となるリ
ンク・マーカ候補の各々が、（１）対象のアブストラク
ト・テキスト − 存在しない場合は、（２）対象の親
ドキュメント名 − 存在しない場合は、（３）対象の
プレゼンタ名、によってリストアップされる。したがっ
て、少なくともリンク・マーカについて短くまとめられ
たデータがあれば、ナビゲーションの対象となる候補を
表示するときに目安となるものをエンドユーザに提供す
ることができ、これはサーチにも役立つ。リンク・マー
カのアブストラクト・オブジェクトは、存在する場合
は、ショートとロングの２つまでのアブストラクト・テ
キストから成り、両方でもいずれか一方でも置ける。

【０１３１】リンク・マーカ・アブストラクトのショー
ト・テキスト・データは、１行に表示するのに適した簡
単な説明文とするものである。リンク・マーカ・アブス
トラクトのロング・テキスト・データは、それを保有す
るリンク・マーカの位置で検出できる情報について多く
の情報を提供することが求められる場合に使用するもの
である。このテキストはキャラクタ数で数万個にもな
り、ある言語のキャラクタ・セットではもっと多くな
る。ロング・アブストラクト・テキストは、エンドユー
ザが要求したときにのみ表示されるが、アブストラクト
・サーチのときには必ず調べられる。サーチを想定し
て、他ではなくテキストにキーワードを指定するのが望
ましい場合は、おそらくは最初に説明文を読もうとする
ようなエンドユーザの便宜を考えて、ロング・アブスト
ラクトの終わりにキーワードを置くのがよいだろう。

【０１３２】ＬＭＳは、ハイパーメディア・メニュー、
ダイアログ・ボックス、マウス処理、及びリンク・マー
カ表示管理について、すべてのクライアント・アプリケ
ーションで一貫したエンドユーザ・インタフェースを提
供する。これらのファシリティは、このようなものの外
観を与えるためのものであると同時に、これらのファシ
リティにより、エンドユーザの要求をセマンティックに
満たすコードが実行される。ＬＭＳ、アプリケーショ
ン、及びＥＵＩの機能的な関係を要約すると図３０のよ
うになる。ユーザは、ブロック２８４に示すように、コ
マンド（つまりメッセージ）をいろいろな方法で入力す
ることができる。マウス、キーボード、ＬＭＳメニュー
等がそれである。メッセージは最初にアプリケーション
・ウィンドウ２８５を通してアプリケーション・プログ
ラムに入力することができる。メッセージはアプリケー
ション２８６のメッセージ処理コードに引き渡され、ア
プリケーションがメッセージを処理しないことを決めれ
ば、メッセージはＬＭＳ２８７のメッセージ処理コード
に送られる。一例としてメニュー（プルダウン・メニュ
ーとコンテクスト・メニュー）の作成がある。一方メッ
セージがＬＭＳメッセージの場合は、ＬＭＳ２８７に直
接渡される。この例としてはリンク・マーカが選択され
た場合があげられる。

【図面の簡単な説明】

【図１】パーソナル・コンピュータの図である。

【図２】図１のパーソナル・コンピュータの機能ブロッ
ク図である。

【図３】図１、図２に示したパーソナル・コンピュータ
に実現されたリンク・マネジャ・サービスの機能ブロッ
ク図である。

【図４Ａ】マーカからオブジェクトへの（１方向）リン
クを示すブロック図である。

【図４Ｂ】マーカからマーカへの（両方向）リンクを示
すブロック図である。

【図５】オープン・システムにおけるリンク・マネジャ
・サービス相互の機能的関係を示すブロック図である。

【図６】クライアント・アプリケーションのウィンドウ
・プロシジャのロジックを示す流れ図である。

【図７】ナビゲーションの前のドキュメントとマーカを
示す画面である。

【図８】ナビゲーションの後の新しいドキュメントとマ
ーカを示す画面である。

【図９】ドキュメント上でマウスがクリックされたとき
のコンテクスト・メニューを示す画面である。

【図１０】リンク・マーカ上でマウスがクリックされた
ときのコンテクスト・メニューを示す画面である。

【図１１】マウスでコマンド・バーのＬＩＮＫがクリッ
クされたときのプルダウン・メニューを示す画面であ
る。

【図１２】マウスで図１１の第１プルダウン・メニュー
のＭＡＮＡＧＥＭＡＲＫＥＲＳがクリックされたとき
の第１プルダウン・メニューを示す画面である。

【図１３】マウスで図１２の第２プルダウン・メニュー
のＣＲＥＡＴＥＭＡＲＫＥＲがクリックされたときの
第３プルダウン・メニューを示す画面である。

【図１４】マウスで図１１のプルダウン・メニューのＭ
ＡＮＡＧＥＬＩＮＫＳがクリックされたときの第２プ
ルダウン・メニューを示す画面である。

【図１５】マウスで図１４の第２プルダウン・メニュー
のＣＲＥＡＴＥＬＩＮＫがクリックされたときの第３
プルダウン・メニューを示す画面である。

【図１６】ＬＭＳによって実行されるプルダウン・メニ
ュー処理のロジックを示す流れ図である。

【図１７】ＬＭＳによって実行されるコンテクスト・メ
ニュー処理のロジックを示す流れ図である。

【図１８】ＬＭＳによって実行される非メニュー・コマ
ンド・メッセージ処理のロジックを示す流れ図である。

【図１９】ＬＭＳによって実行されるマーカ作成プロシ
ジャのロジックを示す流れ図である。

【図２０】ＬＭＳによって実行されるマーカ・ウィンド
ウ・プロシジャのロジックを示す流れ図である。

【図２１】トランスペアレントなウィンドウまたは見え
ないウィンドウをサポートするウィンドウ描画プロシジ
ャのロジックを示す流れ図である。

【図２２】見えないマーカ（ウィンドウ）の位置を反転
表示によって示す画面表示である。

【図２３】通常はウィンドウが画面に描かれるときに取
られるプロシジャを説明する重なり合った複数のウィン
ドウの画面である。

【図２４】リンク・マーカのスタイルを選択するＬＭＳ
ダイアログ・ボックスの一例を示す画面である。

【図２５】リンクを管理するＬＭＳダイアログ・ボック
スの一例を示す画面である。

【図２６】ＬＭＳハイパーメディア・データベースのサ
ーチを開始するＬＭＳダイアログ・ボックスの一例を示
す画面である。

【図２７】ＬＭＳによって実行されるダイアログ・ボッ
クス管理プロシジャのロジックを示す流れ図である。

【図２８】ＬＭＳデータベース更新プロシジャのロジッ
クを示す流れ図である。

【図２９Ａ】図２８に示したプロシジャによって呼び出
されるリンク・マーカとリンク・データベースの更新プ
ロシジャのロジックを示す流れ図である。

【図２９Ｂ】図２８に示したプロシジャによって呼び出
されるリンク・マーカとリンク・データベースの更新プ
ロシジャのロジックを示す流れ図である。

【図３０】ＬＭＳ、アプリケーション、及びＥＵＩの機
能的関係を示すブロック図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者ジョン・アンソニー・スティーブンスアメリカ合衆国メリーランド州、ボイド、トップリッジ・ドライブ 20501番地 (56)参考文献特開昭62−156721（ＪＰ，Ａ) 特開平２−263227（ＪＰ，Ａ) 特開平２−4027（ＪＰ，Ａ) 特開昭64−14678（ＪＰ，Ａ) 国際公開90−10913（ＷＯ，Ａ)

Claims

【特許請求の範囲】

【請求項１】個々のアプリケーションのデータをディス
プレイ・デバイスの画面で、各アプリケーションに対応
する別々のアプリケーション・ウィンドウに表示するこ
とができ、各アプリケーション・ウィンドウが、該デー
タが表示されるアプリケーションの基本ワークスペース
を含む、オープン・ハイパーメディア・システムにおい
て、該ハイパーメディア・システムによって実行される
グラフィカル・ユーザ・インターフェース方法であっ
て、アプリケーションの初期化時に上記ハイパーメディ
ア・システムとアプリケーションが相互に認識できるよ
うにするステップと、上記ディスプレイ・デバイス上で
ユーザ制御ポインタの現在位置をモニタするステップ
と、ユーザの最初の入力と上記ポインタの上記現在位置
に応答して、アプリケーション・ウィンドウ内の上記ユ
ーザ制御ポインタの現在位置に適した選択可能なサービ
スのメニューを表示するステップとを含むことにより、
該ハイパーメディア・システムから得られるハイパーメ
ディア・サービスを利用するアプリケーションに、同一
形式の一貫したグラフィカル・ユーザ・インタフェース
を提供し、かつ選択可能なハイパーメディア・サービス
のメニューを上記アプリケーションから独立してユーザ
に提示するグラフィカル・ユーザ・インタフェース方
法。
【請求項２】選択された上記サービスの実行要求を受理
したことを示すメッセージを上記アプリケーションに送
るステップを含む、請求項１のグラフィカル・ユーザ・
インタフェース方法。
【請求項３】上記アプリケーションが上記選択されたサ
ービスの処理を上記ハイパーメディア・システムに要求
した場合に該アプリケーションからメッセージを受け取
るステップを含む、請求項２のグラフィカル・ユーザ・
インタフェース方法。
【請求項４】上記ユーザ制御ポインタが、上記ディスプ
レイ・デバイスの画面上のカーソルであって、上記ウィ
ンドウがアクション・バーを含み、上記メニュー表示ス
テップが、上記ユーザ入力の時点で該ポインタが該アク
ション・バー内のコマンド上に位置するときに該コマン
ドに対応する選択可能なサービスを提供するポップダウ
ン・メニューを表示するステップより成る、請求項１の
グラフィカル・ユーザ・インタフェース方法。
【請求項５】上記ユーザ制御ポインタが、上記ディスプ
レイ・デバイスの画面上のカーソルであって、上記メニ
ュー表示ステップが、上記ユーザ入力の時点で上記アプ
リケーションの基本ワークスペース内の該カーソルの位
置に従って選択可能なサービスを提供するコンテクスト
・メニューを表示するステップより成る、請求項１の方
法。
【請求項６】上記ユーザ制御ポインタが、上記ディスプ
レイ・デバイスの画面上のカーソルであって、上記ウィ
ンドウがアクション・バーを含み、上記メニュー表示ス
テップが、上記ユーザ入力の時点で上記カーソルが上記
アクション・バー内のコマンド上に位置するときに該コ
マンドに対応する選択可能なサービスを提供するポップ
ダウン・メニューを表示するステップと、上記ユーザ入
力の時点で上記アプリケーションの基本ワークスペース
内の上記カーソルの位置に従って選択可能なサービスを
提供するコンテクスト・メニューを表示するステップと
より成り、上記ポップダウン・メニューと上記コンテク
スト・メニューが、上記アプリケーションから独立した
同一形式の一貫したフォーマットを備える、請求項１の
グラフィカル・ユーザ・インタフェース方法。
【請求項７】選択されたサービスを処理するために別の
情報が必要なときに、サービスのユーザによってメニュ
ーから選択されたものに応答してユーザ入力を受け取る
ために上記画面にダイアログ・ボックスを表示するステ
ップを含む、請求項１のグラフィカル・ユーザ・インタ
フェース方法。
【請求項８】上記ダイアログ・ボックスが、上記画面に
表示されたオブジェクトを変更するオプションをユーザ
に与え、オブジェクトを変更するためのユーザ入力を受
け取るステップと、上記ハイパーメディア・システム
が、上記オブジェクトを変更するための上記ユーザ入力
を処理するというメッセージをアプリケーションに引き
渡すステップと、上記アプリケーションが上記メッセー
ジを受け取った場合に上記ユーザ入力を処理するステッ
プとを含む、請求項７のグラフィカル・ユーザ・インタ
フェース方法。
【請求項９】上記ユーザ入力が処理されたときに上記ア
プリケーションに通知を出すステップを含む、請求項８
のグラフィカル・ユーザ・インタフェース方法。
【請求項１０】個々のアプリケーションのデータをディ
スプレイ・デバイスの画面で、別々のアプリケーション
・ウィンドウに表示することができ、該ウィンドウの各
々が、上記データが表示されるアプリケーションの基本
ワークスペースを含み、オープン・ハイパーメディア・
システムから得られるハイパーメディア・サービスを利
用するアプリケーションに、同一形式の一貫したグラフ
ィカル・ユーザ・インタフェースを提供するハイパーメ
ディア・システムにおいて、該ハイパーメディア・シス
テムによって実行される方法であって、上記画面上のア
プリケーション・ウィンドウ内に、他のリンク・マーカ
やオブジェクトにリンクされた第１リンク・マーカを表
示するステップと、上記リンク・マーカのデータベース
を維持するステップと、上記第１リンク・マーカのユー
ザによる起動に応答して、上記データベースをサーチ
し、該第１リンク・マーカにリンクされたリンク・マー
カまたはオブジェクトを上記画面に表示するステップと
を含む、ハイパーメディア・システム実行方法。
【請求項１１】上記第１リンク・マーカが、複数のリン
ク・マーカまたはオブジェクトにリンクされ、該リンク
の表現を上記画面に表示して、ナビゲート対象のリンク
を選択することを上記ユーザに促すステップを含む、請
求項１０のハイパーメディア・システム実行方法。
【請求項１２】上記第１リンク・マーカにリンクされた
リンク・マーカまたはオブジェクトを上記画面に表示す
るために、ユーザが選択したリンクをナビゲートするス
テップを含む、請求項１１のハイパーメディア・システ
ム実行方法。
【請求項１３】上記第１リンク・マーカにリンクされた
第２リンク・マーカまたはオブジェクトが、第２アプリ
ケーションのデータ内にあり、該第２アプリケーション
のアプリケーション・ウィンドウ内の、該第２リンク・
マーカまたは該オブジェクトを含む上記データを上記画
面に表示するステップを含む、請求項１０のハイパーメ
ディア・システム実行方法。
【請求項１４】上記第２アプリケーションが実行されて
いない場合に、上記第２アプリケーションを投入するス
テップと、上記第２アプリケーションのために上記画面
にアプリケーション・ウィンドウを開くステップとを含
む、請求項１３のハイパーメディア・システム実行方
法。
【請求項１５】上記リンク・マーカが、上記ハイパーメ
ディア・システムのアプリケーションのデータを含むウ
ィンドウである、請求項１０のハイパーメディア・シス
テム実行方法。
【請求項１６】上記リンク・マーカを半透明または透明
にすることのできる、請求項１５のハイパーメディア・
システム実行方法。
【請求項１７】デフォルト形状を持つユーザ制御ポイン
タが上記ディスプレイ・デバイスの画面に表示され、上
記ディスプレイ・デバイス上の上記カーソルの現在位置
をモニタするステップと、上記ディスプレイ・デバイス
上のリンク・マーカの上で上記カーソルが移動されたと
きに該カーソルの上記デフォルト形状を第２形状に変更
するステップとを含む、請求項１５のハイパーメディア
・システム実行方法。
【請求項１８】リンク・マーカが透明属性を持つことが
でき、上記カーソルのデフォルト形状の上記第２形状へ
の変更が、該カーソルの位置にリンク・マーカが存在す
ることを示す、請求項１７のハイパーメディア・システ
ム実行方法。
【請求項１９】リンク・マーカを作成、編集、または削
除するオプションがユーザに与えられる、請求項１０の
ハイパーメディア・システム実行方法。
【請求項２０】リンク・マーカとリンク・マーカのリン
クが両方向であり、リンク・マーカとオブジェクトのリ
ンクが１方向であって、リンク・マーカが作成されたと
きにリンク・マーカからリンク・マーカまたはオブジェ
クトへのリンクを確立するステップと、リンク・マーカ
が編集されたときにリンクを含むリンク・マーカの属性
を変更するステップと、リンク・マーカが削除されたと
きにリンク・マーカへのリンクをすべて削除するステッ
プとを含む、請求項１９のハイパーメディア・システム
実行方法。
【請求項２１】アプリケーションからのデータを別々の
ウィンドウに表示することができ、ウィンドウが重なり
合い、通常は下のウィンドウの各部を覆い隠すように該
ウィンドウを画面上で個別に移動させることのできるウ
ィンドウイング・コンピュータ・ディスプレイにおい
て、ウェブのためのエリアを上記画面上に割り当てるス
テップと、上記ウィンドウの透明属性をチェックするス
テップと、上記透明属性が検出されない場合には上記画
面上に上記ウィンドウを描くステップと、上記透明属性
が検出された場合には上記ウィンドウを隠し、該ウィン
ドウが第２ウィンドウの上にくる場合には該第２ウィン
ドウを再描画するステップとを含む、上記画面上の透明
なウィンドウをサポートするウィンドウ管理方法。
【請求項２２】上記透明なウィンドウの境界を、該透明
なウィンドウの下のウィンドウ内のデータを隠すことな
く、強調によって表示するステップを含む、請求項２１
のウィンドウ管理方法。
【請求項２３】上記画面上でユーザの制御によってカー
ソルを移動させることができ、上記透明なウィンドウの
位置を示すために、該透明ウィンドウの上記エリア内の
該カーソルの形状を変更するステップを含む、請求項２
１のウィンドウ管理方法。
【請求項２４】上記透明ウィンドウが上記第２ウィンド
ウに重なり、透明でない第３ウィンドウが該透明ウィン
ドウに少なくとも部分的に重なり、上記第３ウィンドウ
を、上記透明ウィンドウに重ならないように移動させる
ステップと、上記第３ウィンドウが上記第２ウィンドウ
に重なっていた、上記透明ウィンドウのエリアを含むエ
リア内で上記第２ウィンドウを再描画するステップとを
含む、請求項２１のウィンドウ管理方法。
【請求項２５】個々のアプリケーションのデータをディ
スプレイ・デバイスの画面で、各アプリケーションのた
めの別々のアプリケーション・ウィンドウに表示するこ
とができ、該アプリケーション・ウィンドウが各々、該
データが表示されるアプリケーションの基本ワークスペ
ースを含むハイパーメディア・システムであって、アプ
リケーション初期化時に上記ハイパーメディア・システ
ムとアプリケーションが相互に認識できるようにする手
段と、上記ディスプレイ・デバイス上でユーザ制御ポイ
ンタの現在位置をモニタする手段と、アプリケーション
・ウィンドウ内の上記ユーザ制御ポインタの現在位置に
適した選択可能なサービスのメニューを表示するため
に、ユーザの第１入力及び上記ポインタの上記現在位置
に応答する手段とを含むことにより、オープン・ハイパ
ーメディア・システムから得られるハイパーメディア・
サービスを利用するアプリケーションに同一形式の一貫
したグラフィカル・ユーザ・インタフェースを提供し、
かつ選択可能なハイパーメディア・サービスのメニュー
を、該アプリケーションから独立してユーザに提示する
ハイパーメディア・システム。
【請求項２６】上記選択されたサービスの実行要求が受
理されたことを示すメッセージを上記アプリケーション
に送る手段を含む、請求項２５のハイパーメディア・シ
ステム。
【請求項２７】上記選択されたサービスの処理を上記ア
プリケーションが上記ハイパーメディア・システムに要
求した場合に該アプリケーションからメッセージを受け
取る手段を含む、請求項２６のハイパーメディア・シス
テム。
【請求項２８】上記ユーザ制御ポインタが上記ディスプ
レイ・デバイスの画面上のカーソルであって、上記ウィ
ンドウがアクション・バーを含み、上記メニュー表示手
段が、上記ユーザ入力の時点で該カーソルが該アクショ
ン・バー内のコマンド上に位置するときに該コマンドに
対応する選択可能なサービスを提供するポップダウン・
メニューを表示する手段を含む、請求項２５のハイパー
メディア・システム。
【請求項２９】上記ユーザ制御ポインタが上記ディスプ
レイ・デバイス上のカーソルであって、上記メニュー表
示手段が、上記ユーザ入力の時点の上記アプリケーショ
ンの基本ワークスペース内の上記カーソルの位置に従っ
て選択可能なサービスを提供するコンテクスト・メニュ
ーを表示する手段を含み、該ポップダウン・メニューと
該コンテクスト・メニューが、上記アプリケーションか
ら独立して同一形式の一貫したフォーマットを備える、
請求項２５のハイパーメディア・システム。
【請求項３０】上記ユーザ制御ポインタが上記ディスプ
レイ・デバイス上のカーソルであって、上記ウィンドウ
がアクション・バーを含み、上記メニュー表示手段が、
上記ユーザ入力の時点で上記ポインタが上記アクション
・バー内のコマンド上に位置するときに、該コマンドに
対応する選択可能なサービスを提供するポップダウン・
メニューを表示する手段と、上記ユーザ入力時点の上記
アプリケーションの基本ワークスペース内の上記カーソ
ルの位置に従って選択可能なサービスを提供するコンテ
クスト・メニューを表示する手段とを含む、請求項２５
のハイパーメディア・システム。
【請求項３１】選択されたサービスを処理するのに別の
情報が必要なときにユーザがメニューからサービスを選
択したことに応答してユーザ入力を受け取るために上記
画面にダイアログ・ボックスを表示する手段を含む、請
求項２５のハイパーメディア・システム。
【請求項３２】上記ダイアログ・ボックスが、上記画面
に表示されたオブジェクトを変更するオプションをユー
ザに与え、オブジェクトを変更するためのユーザ入力を
受け取る手段と、上記ハイパーメディア・システムが上
記オブジェクトを変更するためのユーザ入力を処理する
とのメッセージを上記アプリケーションに引き渡す手段
と、上記アプリケーションが上記メッセージを受け取っ
た場合に上記ユーザ入力を処理する手段とを含む、請求
項３１のハイパーメディア・システム。
【請求項３３】上記ユーザ入力が処理されたときに上記
アプリケーションに通知を出す手段を含む、請求項３２
のハイパーメディア・システム。
【請求項３４】個々のアプリケーションのデータをディ
スプレイ・デバイスの画面上で、別々のアプリケーショ
ン・ウィンドウに表示することができ、該ウィンドウが
各々、上記データが表示されるアプリケーションの基本
ワークスペースを含み、オープン・ハイパーメディア・
システムから得られるハイパーメディア・サービスを利
用するアプリケーションに同一形式の一貫したグラフィ
カル・ユーザ・インタフェースを提供し、リンク・マー
カまたはオブジェクトにリンクされたアプリケーション
・ウィンドウ内の第１リンク・マーカを上記画面に表示
する手段と、上記リンク・マーカのデータベースを維持
する手段と、上記データベースをサーチするユーザによ
る上記第１リンク・マーカの起動に応答し、該第１リン
ク・マーカにリンクされたリンク・マーカまたはオブジ
ェクトを上記画面に表示する手段とを含む、ハイパーメ
ディア・システム。
【請求項３５】上記第１リンク・マーカが複数のリンク
・マーカまたはオブジェクトにリンクされ、上記リンク
の表現を上記画面に表示し、ナビゲート対象のリンクの
選択をユーザに促す手段を含む、請求項３４のハイパー
メディア・システム。
【請求項３６】上記第１リンク・マーカにリンクされた
リンク・マーカまたはオブジェクトを上記画面に表示す
るために、ユーザが選択したリンクをナビゲートする手
段を含む、請求項３５のハイパーメディア・システム。
【請求項３７】上記第１リンク・マーカにリンクされた
第２リンク・マーカまたはオブジェクトが第２アプリケ
ーションのデータ内にあり、該第２アプリケーションの
アプリケーション・ウィンドウ内の該第２リンク・マー
カまたは該オブジェクトを含む該データを上記画面に表
示する手段を含む、請求項３４のハイパーメディア・シ
ステム。
【請求項３８】上記第２アプリケーションが実行されて
いない場合に、上記第２アプリケーションを投入する手
段と、上記第２アプリケーションのアプリケーション・
ウィンドウを上記画面に開く手段とを含む、請求項３７
のハイパーメディア・システム。
【請求項３９】上記リンク・マーカが、上記ハイパーメ
ディア・システムのアプリケーションのデータを含むウ
ィンドウである、請求項３４のハイパーメディア・シス
テム。
【請求項４０】上記リンク・マーカを半透明または透明
にすることのできる、請求項３９のハイパーメディア・
システム。
【請求項４１】デフォルト形状を持つユーザ制御カーソ
ルが上記ディスプレイ・デバイスの画面に表示され、上
記ディスプレイ・デバイス上の上記カーソルの現在位置
をモニタする手段と、上記ディスプレイ・デバイス上の
リンク・マーカの上で上記カーソルが移動されたとき
に、該カーソルの上記デフォルト形状を、リンク・マー
カを示す第２形状に変更する手段を含む、請求項４０の
ハイパーメディア・システム。
【請求項４２】リンク・マーカが透明属性を持つことが
でき、上記カーソルのデフォルト形状の上記第２形状へ
の変更が、該カーソルの位置にリンク・マーカがあるこ
とを示す、請求項４１のハイパーメディア・システム。
【請求項４３】リンク・マーカを作成、編集、または削
除するオプションを上記ハイパーメディア・システムが
ユーザに提供する、請求項３４のハイパーメディア・シ
ステム。
【請求項４４】リンク・マーカとリンク・マーカのリン
クが両方向で、リンク・マーカとオブジェクトのリンク
が１方向であって、リンク・マーカが作成されたときに
リンク・マーカからリンク・マーカまたはオブジェクト
へのリンクを確立する手段と、リンク・マーカが編集さ
れたときにリンクを含むリンク・マーカの属性を変更す
る手段と、リンク・マーカが削除されたときにリンク・
マーカへのリンクをすべて削除する手段とを含む、請求
項４３のハイパーメディア・システム。
【請求項４５】アプリケーションからのデータを別々の
ウィンドウに表示することができ、ウィンドウが重なり
合い、通常は下のウィンドウの各部を覆い隠すように、
該ウィンドウをコンピュータ・ディスプレイ・システム
の画面上で個別に移動させることができ、該画面上の透
明なウィンドウをサポートし、ウィンドウ・データベー
スのためのエリアを上記画面上に割り当てる手段と、上
記ウィンドウの透明属性をチェックする手段と、上記透
明属性が検出されなかった場合には上記画面上の上記ウ
ィンドウを描画する手段とを含み、上記透明属性が検出
された場合には上記チェック手段が上記ウィンドウを隠
し、該ウィンドウが第２ウィンドウに重なる場合には、
上記描画手段が該第２ウィンドウを再描画する、ウィン
ドウイング・コンピュータ・ディスプレイ・システム。
【請求項４６】上記透明ウィンドウの下のウィンドウ内
のデータを隠すことなく、該透明ウィンドウの境界を強
調によって表示する手段を含む、請求項４５のウィンド
ウイング・コンピュータ・ディスプレイ・システム。
【請求項４７】カーソルをユーザの制御によって上記画
面上で移動させることができ、上記透明ウィンドウの位
置を示すために、該透明ウィンドウの上記エリア内の該
カーソルの形状を変更する手段を含む、請求項４５のウ
ィンドウイング・コンピュータ・ディスプレイ・システ
ム。
【請求項４８】上記透明ウィンドウが上記第２ウィンド
ウに重なり、透明でない第３ウィンドウが該透明ウィン
ドウに少なくとも部分的に重なり、該透明ウィンドウに
重ならないように該第３ウィンドウを移動させる手段を
含み、上記描画手段が後に、該透明ウィンドウのエリア
を含む該第２ウィンドウに該第３ウィンドウが重なって
いたエリア内の該第２ウィンドウを再描画する、請求項
４５のウィンドーイング・コンピュータ・ディスプレイ
・システム。