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

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】

【０００１】

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

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

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

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

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

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

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

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

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

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

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

【００１１】ハイパーテキスト／ハイパーメディア：最
も簡単な総称としては、ｔｏｕｃｈ　ａｎｄ　ｇｅｔを
意味する。エンドユーザが（ポインティング・デバイス
を使って）オブジェクト（語句、グラフィカル・オブジ
ェクト等）をタッチし、それによって関連する情報体（
ｉｎｆｏｒｍａｔｉｏｎｅｎｔｉｔｙ）が得られるよう
にすることをさす。 ハイパーテキスト・システムの調査資料としては“Ｈｙ
ｐｅｒｔｅｘｔ：　Ａｎ　Ｉｎｔｒｏｄｕｃｔｉｏｎ　
Ｓｕｒｖｅｙ”ｂｙ　Ｊｅｆｆ　Ｃｏｎｋｌｉｎ、ＩＥ
ＥＥＣｏｍｐｕｔｅｒ、Ｓｅｐｔｅｍｂｅｒ　１９８７
、ｐｐ．　１７−４１、及び“Ａｎ　Ｏｖｅｒｖｉｅｗ
　ｏｆ　Ｈｙｐｅｒｔｅｘｔ　ａｎｄＨｙｐｅｒｍｅｄ
ｉａ”、Ｃｏｎｃｅｐｔｓ　＆　Ｉｓｓｕｅｓ、ＭｃＧ
ｒａｗ−Ｈｉｌｌ、Ｎｏｖｅｍｂｅｒ　１９８９がある
。

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

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

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

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

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

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

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

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

【００２０】

【従来の技術】多くのハイパーテキスト／ハイパーメデ
ィア・システムがＳｍａｌｌｔａｌｋ、Ｃ＋＋等のオブ
ジェクト指向プログラミング言語でプログラムされてい
る。Ｓｍａｌｌｔａｌｋ　はゼロックスのパロアルト研
究所（ＰＡＲＣ）で開発されたものである。この言語の
参考書としては、Ａｄｅｌｅ　ＧｏｌｄｂｅｒｇとＤａ
ｖｉｄ　Ｒｏｂｓｏｎによる“Ｓｍａｌｌｔａｌｋ−８
０：　ＴｈｅＬａｎｇｕａｇｅ　ａｎｄ　Ｉｔｓ　Ｉｍ
ｐｌｅｍｅｎｔａｔｉｏｎ”、Ａｄｄｉｓｏｎ−Ｗｅｓ
ｌｅｙ、１９８３、があげられる。Ｃ＋＋は、ＡＴ＆Ｔ
ベル研究所のＢｊａｒｎｅ　Ｓｔｒｏｕｓｔｒｕｐ　に
よって開発されたものである。この言語の参考書として
は同氏による“Ｔｈｅ　Ｃ＋＋　Ｐｒｏｇｒａｍｍｉｎ
ｇ　Ｌａｎｇｕａｇｅ”、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅ
ｙ、１９８６、があげられる。 オブジェクト指向プログラミング・システム（ＯＯＰＳ
）のメリットは、モジュール構造と、アイコンを用いた
オブジェクト指向ユーザ・インタフェースに代表される
。オブジェクト指向プログラミングとハイパーシステム
の詳細については、“Ｄｅｓｉｇｎ　ａｎｄ　Ｕｓｅ　
ｏｆ　ＨｙｐｅｒｍｅｄｉａＳｙｓｔｅｍｓ”ｂｙ　Ｒ
ｏｂｅｒｔ　Ａｋｓｃｙｎ　ｏｆ　Ｋｎｏｗｌｅｄｇｅ
　Ｓｙｓｔｅｍｓ、Ｉｎｃ．、Ｃｏｎｆｅｒｅｎｃｅ　
ｏｎＨｕｍａｎ　Ｆａｃｔｏｒｓ　ｉｎ　Ｃｏｍｐｕｔ
ｉｎｇ　Ｓｙｓｔｅｍｓ、Ｍａｙ　１４、１９８８、及
び“Ｉｎｔｅｒｍｅｄｉａ：　ＴｈｅＡｒｃｈｉｔｅｃ
ｔｕｒｅ　ａｎｄ　Ｃｏｎｓｔｒｕｃｔｉｏｎ　ｏｆ　
Ａｎ　Ｏｂｊｅｃｔ　Ｏｒｉｅｎｔｅｄ　Ｈｙｐｅｒｍ
ｅｄｉａ　Ｓｙｓｔｅｍａｎｄ　Ａｐｐｌｉｃａｔｉｏ
ｎ　Ｆｒａｍｅｗｏｒｋ”ｂｙ　Ｎｏｒｍａｎ　Ｍｅｙ
ｒｏｗｉｔｚ、ＩＲＩＳ、Ｂｒｏｗｎ　Ｕｎｉｖｅｒｓ
ｉｔｙ、ＯＯＰＳＬＡ　Ｐｒｏｃｅｅｄｉｎｇｓ、Ｓｅ
ｐｔｅｍｂｅｒ　１９８６、を参照されたい。

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

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

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

【００２４】Ｓｉｌｉｃｏｎ　Ｂｅａｃｈ　Ｓｏｆｔｗ
ａｒｅの「スーパカード」プログラムは、ハイパーカー
ド“風”だがハイパーカードよりも強力である。“カー
ド”のスタックを提供するほかにアプリケーションを生
成する。この他の閉じたハイパーメディア・システムと
しては、ＯＷＬ　Ｉｎｔｅｒｎａｔｉｏｎａｌ、Ｉｎｃ
．　の「ガイド２．０」　−　ハイパーメディア機能で
他の（ガイドに提供されていない）アプリケーション（
プレゼンタ）を使えるようにするファシリティは提供さ
れていない　−　Ｂｒｏｗｎ　Ｕｎｉｖｅｒｓｉｔｙの
ＩＲＩＳ　（Ｉｎｓｔｉｔｕｔｅ　ｆｏｒ　Ｒｅｓｅａ
ｒｃｈ　ｉｎ　Ｉｎｆｏｒｍａｔｉｏｎ　ａｎｄ　Ｓｃ
ｈｏｌａｒｓｈｉｐ）のＩＲＩＳ　Ｉｎｔｅｒｍｅｄｉ
ａ−これもハイパーメディア機能で他の（Ｉｎｔｅｒｍ
ｅｄｉａに提供されていない）アプリケーション（プレ
ゼンタ）を使えるようにするファシリティを提供してい
ない−　ＩＢＭ　Ｅｄｕｃａｔｉｏｎａｌ　Ｓｙｓｔｅ
ｍｓ　のＬｉｎｋＷａｙ　２．０　−　これもまたハイ
パーメディア機能で他の（ＬｉｎｋＷａｙ　に提供され
ていない）アプリケーション（プレゼンタ）を使えるよ
うにするファシリティを提供していない　−　等がある
。

【００２５】Ｓｕｎ　ＭｉｃｒｏｓｙｓｔｅｍｓのＳｕ
ｎ　Ｌｉｎｋ　Ｓｅｒｖｉｃｅは、発明者の知るかぎり
、他のオープンなハイパーメディア・システムのなかで
唯一使える製品である。Ｓｕｎ　のファシリティは、ハ
イパーメディア機能で他の（Ｓｕｎ　に提供されていな
い）アプリケーションを使えるようにするサービスを提
供している。ただしシームレス（継ぎ目なし）かつ容易
に使えるようにはならない。またＳｕｎ　Ｌｉｎｋ　Ｓ
ｅｒｖｉｃｅは、ハイパーメディア機能のエンドユーザ
・インタフェースを管理しない。つまり、この点につい
て各アプリケーションはそれ自体のアイデアを実現しな
ければならない。この製品の詳細についてはＨｙｐｅｒ
ｔｅｘｔ　’８９　Ｐｒｏｃｅｅｄｉｎｇｓ　に掲載さ
れたＡｍｙ　Ｐｅａｒｌ　による記事“Ｓｕｎ’ｓ　Ｌ
ｉｎｋ　Ｓｅｒｖｉｃｅ：　Ａ　Ｐｒｏｔｏｃｏｌ　ｆ
ｏｒ　Ｏｐｅｎ　Ｌｉｎｋｉｎｇ”（ｐｐ．　１３７−
１４６）を参照されたい。

【００２６】上記の他、ＰＣ／Ｃｏｍｐｕｔｉｎｇ　Ｍ
ａｇａｚｉｎｅ　誌はハイパーテキスト／ハイパーメデ
ィア機能を実現した数種の製品の評文を載せている。製
品はＦｏｌｉｏ　Ｃｏｒｐ．のＦｏｌｉｏＶｉｅｗｓ　
２．０、Ｃｏｇｎｅｔｉｃｓ　Ｃｏｒｐ．のＨｙｐｅｒ
ｔｉｅｓ、ＮｔｅｒｇａｉｄのＨｙｐｅｒＷｒｉｔｅｒ
、ＳｐｉｎｎａｋｅｒＳｏｆｔｗａｒｅ　Ｃｏｒｐ．の
Ｓｐｉｎｎａｋｅｒ　Ｐｌｕｓ　２．０、ＭａｘＴｈｉ
ｎｋのＴｒａｎｓｔｅｘｔ等である。ＦｏｌｉｏＶｉｅ
ｗｓ　は「大きいテキスト・ファイルを扱いやすい“イ
ンフォベース”に圧縮してクロスレファレンス・リンク
を作る情報管理システム」という。この製品についてこ
れ以上のことはわかっていないが、製品評は、これが異
なるプレゼンタ相互間やタイプの異なるデータ相互間の
リンクを形成できないとしている。またハイパーメディ
ア機能で他の（Ｆｏｌｉｏ　Ｖｉｅｗｓ　に提供されて
いない）アプリケーション（プレゼンタ）を使えるよう
にする方法が与えられないともいう。

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

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

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

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

【００３１】またＫｎｏｗｌｅｄｇｅ　Ｇａｒｄｅｎ、
Ｉｎｃ．のＫｎｏｗｌｅｄｇｅＰｒｏ　について先に引
いたＣｏｎｃｅｐｔｓ　＆Ｉｓｓｕｅｓ誌は「．．．こ
の製品に慣れるにはある程度プログラミングの経験があ
った方がいいが、開発者によると、そうした経験はこの
プログラムを習得する必要条件ではない．．．エキスパ
ート・システム・ジェネレータとハイパーテキストを組
み合わせたプログラミング環境．．．外部ファイルを読
み出し、外部プログラムを呼び出して、他の言語で書か
れたルーチンによって拡張できる」と評している（１９
８９年１１月号）。製品評はさらに、プログラミング環
境とエキスパート・システム・ジェネレータの組み合わ
せによって高度なサーチ機能が得られるという。但しこ
の製品のサーチ機能についても製品がどの程度オープン
であるかについてもこれ以上のことはわからない。

【００３２】

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

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

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

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

【００３６】

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

【００３７】

【実施例】この発明は、異なるオペレーティング・シス
テム（ＯＳ）を用い、各種のコンピュータ上で実行する
ことができる。コンピュータは、パーソナル・コンピュ
ータ、ミニコンピュータ、メインフレーム・コンピュー
タ等であり、ローカル・エリア・ネットワーク（ＬＡＮ
）やワイド・エリア・ネットワーク（ＷＡＮ）等のネッ
トワークの１部であるスタンドアロン・システムや大型
の遠隔データ処理システムが使用できる。便宜上、この
発明はＩＢＭのＰＳ／２シリーズ等のパーソナル・コン
ピュータに実現されるものとして説明する。もちろん、
コンピュータの選択の幅を制限するのは、必要なメモリ
やディスク・ストレージの条件だけである。ＩＢＭ　　
ＰＳ／２シリーズの詳細については、Ｔｅｃｈｎｉｃａ
ｌ　ＲｅｆｅｒｅｎｃｅＭａｎｕａｌ　Ｐｅｒｓｏｎａ
ｌ　Ｓｙｓｔｅｍ／２　（Ｍｏｄｅｌ　５０、６０　Ｓ
ｙｓｔｅｍｓ）　（Ｐａｒｔ　Ｎｏ．６８Ｘ２２２４、
ＯｒｄｅｒＮｏ．　Ｓ６８Ｘ−２２２４）及びＴｅｃｈ
ｎｉｃａｌ　Ｒｅｆｅｒｅｎｃｅ　Ｍａｎｕａｌ、Ｐｅ
ｒｓｏｎａｌ　Ｓｙｓｔｅｍ／２（Ｍｏｄｅｌ　８０）
（Ｐａｒｔ　Ｎｏ．　６８Ｘ２２５６、Ｏｒｄｅｒ　Ｎ
ｏ．　Ｓ６８Ｘ−２２５６）を参照されたい。

【００３８】この発明の実施例を示すためのオペレーテ
ィング・システムとして、プレゼンテーション・マネジ
ャ（ＰＭ）を備えたＩＢＭのＰＳ／２を使用したが、こ
の発明は他の異なるオペレーティング・システムでも実
現できること、そしてそれより重要なことであるが、オ
ペレーティング・システムに組み込めることは理解され
よう。ＩＢＭ　ＯＳ／２オペレーティング・システムの
詳細については、ＩＢＭＯｐｅｒａｔｉｎｇ　Ｓｙｓｔ
ｅｍ／２、Ｖｅｒｓｉｏｎ　１．２、Ｓｔａｎｄａｒｄ
　Ｅｄｉｔｉｏｎ　ＴｅｃｈｎｉｃａｌＲｅｆｅｒｅｎ
ｃｅ　を参照されたい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (48)

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