JPH04274536A - ハイパーメディア・システム及びハイパーメディア・システムで実施されるリンク・マーカ操作方法 - Google Patents

Abstract

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

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、一般に、「ハイパーテ
キスト／ハイパーメディア」サービスを新しいコンピュ
ータ・プログラム・アプリケーションだけでなく、既存
のコンピュータ・プログラム・アプリケーションにも、
比較的シームレスに統合できるようにするソフトウエア
機能に関するものであり、とりわけ「ハイパーテキスト
／ハイパーメディア」サービスの一部としてのアブスト
ラク（すなわち、要約とキー・ワードの両方または一方
）の作成及び探索に対する支援に関するものである。

【０００２】

【従来の技術】以下の用語については、この開示全般に
わたって用いられる。

【０００３】アブストラクト：　　テキスト・オブジェ
クトが関連づけられているリンク・マーカにおいて見出
される重要な情報を要約した、キー・ワード、句、及び
、ステートメントの全てまたはいずれかから成るテキス
ト・オブジェクト。

【０００４】アプリケーション：　　ワード・プロセッ
サ、スプレッドシート、データベース・マネージメント
、グラフィックス・デザイナといった、オペレーティン
グ・システム以外のコンピュータ・プログラム。本書で
用いられるように、アプリケーション・プログラムは、
プレゼンタとも呼ばれる。

【０００５】アプリケーション・プログラミング・イン
ターフェイス（ＡＰＩ）：　　プログラムがサービスの
呼出しに用いる手段。

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

【０００７】コンテキスト・メニュ：　　しばしば「ポ
ップ・アップ」メニュとも呼ばれる、コンテキスト・メ
ニュは、視覚的にも、機能的にもプル・ダウン・メニュ
に似ているが、アクションまたは指令バーとは関連して
いない。それらは、ウインドウ内の任意の位置に現れる
ことができる。さらに、プル・ダウン・メニュの内容は
、任意の時点におけるアプリケーションの状態に基づい
て変化しないのが普通であるが（使用可能、あるいは、
使用禁止／どちらともいえない状態が考えられるが）、
一方、コンテキスト・メニュの内容は、動的であり、ア
プリケーションの状態に基づいて変化する、すなわち、
コンテキストに感応する。例えば、コンテキスト・メニ
ュに「保管」という項目が含まれていたとしても、コン
テキスト・メニュが表示されて、データ修正がなかった
場合「保管」オプションは、メニュに現われない。コン
テキスト・メニュが表示されるのは、一般に、エンド・
ユーザがあるウインドウについてマウス・ボタンをクリ
ック音を立てて操作した場合である。コンテキスト・メ
ニュには、一般に、プル・ダウン・メニュに似た機能が
含まれているが、任意の時間にクリック音を立ててオン
にされたオブジェクトに関連する項目しか含まれていな
い。

【０００８】文書：　　通常は、エンド・ユーザが認識
できる、ただし、必ずしもそうでなくてはならないとい
うわけではない（プレゼンタによって処理される時）、
名前付きのデータ・セット（例えば、テキスト・ファイ
ル、イメージ・ファイル、ビデオ・パッセージ等）。従
って、「文書」という用語は、テキスト・ファイルに限
定されるものではなく、テキスト、ビット・マップ・グ
ラフィックス、スプレッドシートまたは他の何らかのデ
ータ表現であってもかまわない。場合によっては、他の
オブジェクトがＬＭＳによって「文書」とみなされるこ
ともある。これらのオブジェクトには、オーディオ・フ
ァイル、モーション・ビデオ・ファイル及びクリップ、
及び、一連のイメージ・ファイル（すなわち、スライド
で見せる）がある。

【０００９】エンド・ユーザ・インターフェイス（ＥＵ
Ｉ）：　　エンド・ユーザが、システム、システム・コ
ンポーネント、及び、システム・アプリケーションの全
て、または、いずれかと対話するのに用いる、装置を含
めた方法論。

【００１０】グラフィカル・ユーザ・インターフェイス
（ＧＵＩ）：　　グラフィカルであるＥＵＩ、例えば、
エンド・ユーザは、ウインドウ、アイコン、メニュ、指
示装置等によって対話する。

【００１１】ハイパーテキスト／ハイパーメディア：　
　一般的な、最も単純な意味において、これらの用語は
、触れて、得ることを表している。これらは、エンド・
ユーザが、オブジェクト（例えば、語、句、グラフィカ
ル・オブジェクト等）に触れることによって（例えば、
ある種の指示装置を用いて）、１つ以上の関連した情報
エンティティが得られるようにすることができるという
概念を具現化したものてある。ハイパーテキスト・シス
テムの概略については、１９８７年９月のＩＥＥＥ　Ｃ
ｏｍｐｕｔｅｒ　１７〜４１頁に掲載のＪｅｆｆ　Ｃｏ
ｎｋｌｉｎ　による“Ｈｙｐｅｒｔｅｘｔ：　Ａｎ　Ｉ
ｎｔｒｏｄｕｃｔｉｏｎ　Ｓｕｒｖｅｙ”及び１９８９
年１１月の　ＭｃＧｒａｗ−Ｈｉｌｌ　社刊　Ｃｏｎｃ
ｅｐｔ　＆　Ｉｓｓｕｅｓ　における“Ａｎ　Ｏｖｅｒ
ｖｉｅｗ　ｏｆ　Ｈｙｐｅｒｔｅｘｔ　ａｎｄ　Ｈｙｐ
ｅｒｍｅｄｉａ”に記載されている。

【００１２】リンク：　　１つの文書中のポイントとも
う１つの文書中のポイント（同じ文書中における異なる
ポイント）を関連づけるオブジェクト。リンクは、双方
向生にすることができ、従って、どちらの端からでもた
どることが可能である。

【００１３】リンク・マネージャ・サービス（ＬＭＳ）
：　　ハイパーテキスト／ハイパーメディア・サービス
の完全に統合されたセット。

【００１４】リンク・マーカ：　　このポイント（リン
ク・マーカの位置）に１つ以上のリンクが存在すること
を表す、文書中に含まれた、エンド・ユーザに対する（
一般に）視覚表示。リンク・マーカから生じるリンクが
存在し、リンク・マーカがトリガされると（例えば、エ
ンド・ユーザがマウスを用いて）、リンク・マーカのリ
ンクのナビゲーションが可能になる。ＬＭＳは、（１）
オプションでテキストを含むことが可能なプッシュ・ボ
タン、（２）エンド・ユーザがリンク・マーカのフレー
ム付き領域を介してクライアント・アプリケーションの
基本をなしている、与えられたデータを取り扱うことが
できるようにする黒フレーム、（３）黒フレームのよう
に、透明にすることができるが、確実に見えるフレーム
を備えたハイライト・フレーム（基本をなしているデー
タの中に、黒または極めて暗い色のものが含まれている
場合、黒フレームに比べて、とりわけ有効である）、（
４）基本となるデータのパターンを認識できるので、や
はり、透明であるが、基本となるデータの色が変わるハ
イライト領域（反転ビデオとして知られる場合もある、
例えば、基本をなす黒のデータが、全て、白に変わり、
白が、全て、黒に変わり、青が、全て、黄に変わり、等
々）、（５）基本となるデータの遮蔽に関して、真に見
えない不可視といった、多種多様な外観スタイルをとる
ことが可能なリンク・マーカを供給する。

【００１５】マウス：　　この文書で用いられる場合、
マウスという用語は、実際には、マウス、トラック・ボ
ール、ライトペン、タッチ・スクリーン等を含む、ただ
し、これらに限定されるわけではない、任意のタイプの
オペレーティング・システムを支援する指示装置を表し
ている。また、アプリケーションの利用時に、エンド・
ユーザが対話に用いるスクリーン、キー・ボード及びマ
ウス操作、メニュ等。

【００１６】ナビゲーション：　　リンクに対する追従
、すなわち、トラバース。

【００１７】開放形システム：　　アプリケーション・
プレゼンタがリンクに関与できるようにするハイパーメ
ディア・システム。こうしたアプリケーションは、リン
クのもう一方の端にある文書とプレゼンタの両方または
一方に気づく必要はなく、従って、互いに全く関係なく
生じるアプリケーションとアプリケーションで処理され
るデータのシームレスな統合を可能にする。

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

【００１９】プル・ダウン・メニュ：　　これらは、ウ
インドウ上部のアクション・バー（メニュ・バー）に関
連したメニュである。これらのメニュには、カスケード
・メニュとして知られるサブ・メニュを含めることもで
きる。

【００２０】ハイパーテキスト／ハイパーメディア・シ
ステムのいくつかは、スモールトーク及びＣ＋＋といっ
たオブジェクト志向プログラミング言語によってプログ
ラムされる。前者は、Ｘｅｎｏｘ　Ｐａｌｏ　Ａｌｔｏ
　Ｒｅｓｅａｃｈ　Ｃｅｎｔｅｒ　（ＰＡＲＣ）　で開
発されたものであり、該言語に関する行き届いた説明は
、１９８３年　Ａｄｄｉｓｉｏｎ−Ｗｅｓｌｅｙ社刊の
　Ａｄｅｌｅ　Ｇｏｌｄｂｅｒｇ　及び　Ｄａｖｉｄ　
Ｒｏｂｓｏｎ　による　Ｓｍａｌｌｔａｌｋ−８０：　
Ｔｈｅ　ｌａｎｇｕａｇｅ　ａｎｄ　ＩｔｓＩｍｐｌｅ
ｍｅｎｔａｔｉｏｎ　と題する、テキスト・ブックを参
照することによって得られる。Ｃ＋＋言語は、ＡＴ＆Ｔ
　Ｂｅｌｌ　Ｌａｂｏｒａｔｏｒｉｅｓ　の　Ｂｊａｒ
ｎｅ　Ｓｔｒｏｕｓｔｒｕｐ　によって開発されたもの
であり、例えば、１９８６年　Ａｄｄｉｓｏｎ−Ｗｅｓ
ｌｅｙ社刊の　Ｔｈｅ　Ｃ＋＋　　Ｐｒｏｇｒａｍｍｉ
ｎｇ　Ｌａｎｇｕａｇｅ　と題する彼の著書に記載され
ている。オブジェクト志向プログラミング・システム（
ＯＯＰＳ）の利点の中には、アイコンを用いたモジュー
ラ構造及びオブジェクト志向ユーザ・インターフェイス
がある。オブジェクト志向プログラミング及びハイパー
システムに関するそれ以上の情報に付いては、１９８８
年５月１４日の　Ｋｎｏｗｌｅｄｇｅ　Ｓｙｓｔｅｍｓ
，　Ｉｎｃ．　の　Ｒｏｂｅｒｔ　Ａｋｓｃｙｎ　によ
る、Ｃｏｎｆｅｒｅｎｃｅ　ｏｎ　Ｈｕｍａｎ　Ｆａｃ
ｔｏｒｓ　ｉｎ　Ｃｏｍｐｕｔｉｎｇ　Ｓｙｓｔｅｍｓ
　における“Ｄｅｓｉｇｎ　ａｎｄ　Ｕｓｅ　ｏｆＨｙ
ｐｅｒｍｅｄｉａ　Ｓｙｓｔｅｍ”から得ることができ
るし、また、１９８６年９月のＯＯＰＳＬＡ　　Ｐｒｏ
ｃｅｅｄｉｎｇｓ　におれけるＩＲＩＳ、Ｂｒｏｗｎ　
Ｕｎｉｖｅｒｓｉｔｙ　の　Ｎｏｒｍａｎ　Ｍｅｙｒｏ
ｗｉｔｚによる“Ｉｎｔｅｒｍｅｄｉａ：　Ｔｈｅ　Ａ
ｒｃｈｉｔｅｃｔｕｒｅ　ａｎｄ　Ｃｏｎｓｔｒｕｃｔ
ｉｏｎ　ｏｆ　Ａｎ　Ｏｂｊｅｃｔ　Ｏｒｉｅｎｔｅｄ
　Ｈｙｐｅｒｍｅｄｉａ　Ｓｙｓｔｅｍ　ａｎｄ　Ａｐ
ｐｌｉｃａｔｉｏｎ　Ｆｒａｍｅｗｏｒｋ”から得るこ
ともできる。

【００２１】発明者が気づいている限りでは、アプリケ
ーション（プレゼンタ）が、シームレスに、かつ、容易
にハイパーテキスト／ハイパーメディア能力を開放形シ
ステム・アーキテクチャに組こむことができるようにす
る、しかも、プレゼンタ自体によってではなく、ハイパ
ーメディア・サービスによって管理される整合のとれた
エンド・ユーザ・ハイパーメディア・インターフェイス
が自動的に得られるようにするハイパーテキスト／ハイ
パーメディア・システム、あるいは、システム・サービ
スは、存在しない。さらに、ある程度「開放された」シ
ステムであるハイパーメディア・システムでさえ、将来
の解放時に、ユーザ・インターフェイスを変更できるよ
うにするには、システム内の全てのハイパーメディア・
アプリケーションを修正し、再構築することが必要にな
る。

【００２２】以下に述べる先行技術は、ハイパーテキス
ト／ハイパーメディア能力を具現化した製品とサービス
の両方または一方を表わすものである。

【００２３】Ａｐｐｌｅ　Ｃｏｒｐ．　から発表された
ハイパーカードは、多くの人によって（その著者Ｂｉｌ
ｌ　Ａｔｋｉｎｓｏｎ　を含む）、ハイパーメディア製
品ではなく「アプリケーション・ビルダ」または「カー
ド・スタック」とみなされている。ハイパーメディア・
システムであるとみなすと（カードが互いに「連係」し
ているので）、それは、閉鎖形ハイパーメディア・シス
テムであり、例えば、その製品によって与えられる表現
機能しか利用してはならない。ハイパーカードは、他の
（非ハイパーカードで得られる）アプリケーション（プ
レゼンタ）を使用可能にする機能にハイパーメディア能
力を付与するものではない。

【００２４】Ｓｉｌｉｃｏｎ　Ｂｅａｃｈ　Ｓｏｆｔｗ
ａｒｅ　によるスーパカード・プログラムは、ハイパー
カードと「うり二つ」であるが、ハイパーカードに比べ
てより強力である。ハイパーカード・プログラムは、「
カード」スタックだけでなく、アプリケーションの生成
も可能にする。閉鎖形ハイパーメディア・システムの他
の例には、他の（非ガイドによって与えられる）アプリ
ケーション（プレゼンタ）を使用可能にする機能にハイ
パーメディア能力を付与するものではないＯＷＬ　Ｉｎ
ｔｅｒｎａｔｉｏｎａｌ，　Ｉｎｃ．によるガイド２．
０、やはり、他の（非インターメディアで与えられる）
アプリケーション（プレゼンタ）を使用可能にする機能
にハイパーメディア能力を付与するものではない、Ｂｒ
ｏｗｎ　Ｕｎｉｖｅｒｓｉｔｙ　の　Ｉｎｓｔｉｔｕｔ
ｅｆｏｒ　Ｒｅｓｅａｒｃｈ　ｉｎ　Ｉｎｆｏｒｍａｔ
ｉｏｎ　ａｎｄ　Ｓｃｈｏｌａｒｓｈｉｐ（ＩＲＩＳ）
によるＩＲＩＳインダーメディア、及び、他の（非リン
クウエイによって与えられる）アプリケーション（プレ
ゼンタ）を使用可能にする機能にハイパーメディア能力
を付与するものではない　ＩＢＭ　Ｅｄｕｃａｔｉｏｎ
ａｌ　Ｓｙｓｔｅｍ　によるリンクウエイ２．０がある
。

【００２５】Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓ　よる
サン・リンク・サービスは、本発明者が利用し得る製品
と認める唯一の他の開放形ハイパーメディア・システム
である。サン・リンク・サービスの機能は、他の（非サ
ン・リンク・サービスによって与えられる）アプリケー
ションを使用可能にすることができる１組のサービスに
ハイパーメディア能力を付与するものではないが、この
使用可能化は、シームレスでもなければ、容易でもない
。さらに、サン・リンク・サービスは、ハイパーメディ
ア能力に関するエンド・ユーザ・インターフェイスを取
り扱うものでなく、従って、各アプリケーションがそれ
に関してそれ自体の概念を具現化しなければならないと
いうことになる。この製品に関するこれ以上の情報につ
いては、Ｈｙｐｅｒｔｅｘｔ　’８９　Ｐｒｏｃｅｅｄ
ｉｎｇｓ　の１３７〜１４６頁に記載の　Ａｍｙ　Ｐｅ
ａｒｌ　による“Ｓｕｎ’ｓ　Ｌｉｎｋ　Ｓｅｒｖｉｃ
ｅ：　Ａ　Ｐｒｏｔｏｃｏｌ　ｆｏｒ　Ｏｐｅｎ　Ｌｉ
ｎｋｉｎｇ”と題する論文によって得ることができる。

【００２６】上記以外に、ハイパーテキスト／ハイパー
メディア能力を具現化した他のいくつかの製品について
は、１９９０年１０月に発行の　ＰＣ／Ｃｏｍｐｕｔｉ
ｎｇ　Ｍａｇａｚｉｎｅ　２０１〜２１０頁に論評があ
った。これらには、Ｆｏｌｉｏ　Ｃｏｒｐ．　によるフ
ォリオ・ビュー２．０、Ｃｏｇｎｅｔｉｃｓ　Ｃｏｒｐ
．　によるハイパータイ、　Ｎｔｅｒｇａｉｄによるハ
イパーライタ、　Ｓｐｉｎｎａｋｅｒ　Ｓｏｆｔｗａｒ
ｅ　Ｃｏｒｐ．　によるスピンネーカ・プラス２．０、
及び、　Ｍａｘ　Ｔｈｉｎｋ　によるトランステキスト
が含まれている。フォリオ・ビューは、「大テキスト・
ファイルをカスタム化「情報ベース」に圧縮させ、相互
参照リンクを生成させる情報管理システム」とみなされ
た。この製品について、これ以上知られていないが、こ
の論評の示唆するところによれば、これは、異なるプレ
ゼンタと異なるタイプのデータの両方または一方の間に
おけるリンクを可能にするものではない。また、この示
唆するところによれば、他の（非フォリオ・ビューで与
えられる）アプリケーション（プレゼンタ）を使用可能
にする方法で、ハイパーメディア能力が付与されるもの
はない。

【００２７】ハイパータイは、「既存のファイル、オン
・ライン情報、走査を受ける材料、及び、ビデオを含む
各種媒体からハイパーテキスト文書及びマニュアルを生
成させる対話システム」とみなされた。ハイパータイは
閉鎖形ハイパーメディア・システムである、例えば、該
製品が与える表現機能だけしか利用してはならない。こ
の製品についてこれ以上のことは分からないが、論評の
示すところによれば、他の（ハイパータイで与えられる
）アプリケーション（プレゼンタ）を使用可能にする方
法で、ハイパーメディア能力が付与されるものはない。

【００２８】ハイパーライタは、「オーディオ及びビデ
オ能力と、制限された書き言葉によるハイパーテキスト
著作ツール」とみなされた。

【００２９】スピンネーカ・プラス２．０は、「カスタ
ム情報管理アプリケーションを作成し、実行するための
ハイパーテキスト・プログラミング環境」とみなされた
。これ以上の情報は知らないが、論評から明らかなこと
は、スピンネーカ・プラス２．０は「真」のハイパーテ
キスト製品に比べてより優れたアプリケーション生成プ
ログラムということがある。

【００３０】トランステキストは、「他の多くの市販さ
れているアプリケーションに対するハイパーテキスト・
リンクを生成させるワード・プロセッサ」とみなされた
。この製品に関してこれ以上のことは分からないが、論
評によれば、該製品からの単一方向のリンクを確立する
ことができ、おそらく、それによって、単に、既存の市
販されているアプリケーションに着手し、単に、それら
にユーザ指定のパラメータを与えることになるだけであ
る。

【００３１】さらに、Ｋｎｏｗｌｅｄｇｅ　Ｇａｒｄｅ
ｎ　によるノレッジ・プロは、１９８９年１１月に発行
された上述の　Ｃｏｎｃｅｐｔｓ　＆　Ｉｓｓｕｅｓ　
において、「．．．プログラミング技術の中には、該製
品に習熟するのに有効なものもあるが、その開発者の主
張するところによれば、こうした技術は、このプログラ
ム　．．．　エキスパート・システム生成プログラムと
ハイパーテキストを組み合わせるプログラミング環境を
学習するのに前もって必要とされるわけではない　．．
．　それは、外部ファイルを読み取り、外部プログラム
を呼び出し、他の言葉で書かれたルーチンによって拡張
することができる。」と論評されている。さらに、また
、この論評の示唆するところによれば、プログラミング
環境／エキスパート・システム生成プログラムの組合せ
によって、ある程度の高度な探索能力を得ることが可能
になる。ただし、この製品に含まれた探索能力と開放の
程度のいずれについても、それ以上詳しいことは分から
ない。

【００３２】最も基本的には、いかなる種類のハイパー
メディア・システムも、情報の記憶及び検索システムで
あるが、それらは、全て、情報を連関させて、コンテキ
ストを確立し、後で、そのコンテキストに基づいて検索
を行えるようにするという特質を備えている。例えば、
エンド・ユーザが、栄養に関するハイパーメディア文書
を読み取っていて、ＬＭＳ用語でリンク・マーカと呼ば
れるものに出くわし、リンク・マーカをトリガすれば（
例えば、指示装置によって活動化する）、エンド・ユー
ザに栄養価の表が示される旨の指示がなされて、エンド
・ユーザがリンク・マーカを活動化すると、栄養価の表
がエンド・ユーザに提示される。エンド・ユーザが、ハ
ード・コピーの形の文書（例えば、本）を利用している
場合、エンド・ユーザは、その文書のインデックスまた
は他の相互参照セクションを用いて、栄養価の表を探索
し、おそらくは、その表を求めて多数の参照箇所を確か
めなければならないであろうが、実際の表に関するもの
はそのうちの１つだけである。汎用の情報記憶及び検索
システムは、こうした単にインデックス／相互参照によ
る探索のタスクには十分適合するが、コンテキストの場
合には、かならずしもそうはいかない。

【００３３】何故両立させることができないのか？　　
上述の１９８９年１１月に発行されたＣｏｎｃｅｐｔｓ
　＆　Ｉｓｓｕｅｓ　　に記載のハイパーテキスト及び
ハイパーメディアについて述べた論文においては、「　
．．．　マルチ・メディア能力を加えても、データ検索
のためにハイパーメディアを用いることに関連した全て
の問題が解決されるわけではない。例えば、エンド・ユ
ーザが、捜している情報をどこで求めるかについてあま
り確信のない場合、どうなるか？」（すななち、トリガ
すべきリンク・マーカを見つけることができない）とい
った所見が示されている。 エンド・ユーザが、ハイパーメディア情報を検分して、
現在示されているリンク・マーカにはガイドのなるもの
がないという結論に達したが、この結論に関連した情報
を追求したいという場合にはどうなるか？　　また、ハ
イパーメディア・システムが、ＬＭＳで指定のような開
放形システムであって、異なる種類のデータ毎に別個に
作成したハイパーメディア・アプリケーションを有する
場合にはどうなるか？　　アプリケーション及びデータ
に関係のない（開放形）ハイパーメディア環境の利点を
犠牲にしないで、情報に対する広範な非コンテキスト要
求を満たすため、どんな開放形システム探索メカニズム
を構築することができるか？

【００３４】

【発明が解決しようとする課題】従って、本発明の目的
は、新しいアプリケーションだけでなく、既存のアプリ
ケーションについても、開放形システム構造を利用し、
「ハイパーテキスト／ハイパーメディア」サービスの一
部としてアブストラクトの作成及び探索を可能にするこ
とにある。

【００３５】

【課題を解決するための手段】本発明によれば、アプリ
ケーション（プレゼンタ）が、開放形システム・アーキ
テクチャ（ＬＭＳによって定義される）に対してハイパ
ーテキスト／ハイパーメディア能力を整合性のある、こ
れらサービスを受けるオブジェクトに対する著述及び探
索機能をシームレスに、かつ、容易に組み込むことがで
きるようにし、さらに、エンド・ユーザに対して、プレ
ゼンタ自体によってではなく、基礎をなすサービスによ
って完全に管理される、整合性のあるハイパーメディア
・リンク・マーカのアブストラクト作成及び探索ＥＵＩ
を自動的に提供できるようにする１組のシステム・リン
ク・マーカ・アブストラクト・サービスが得られる。

【００３６】

【実施例】本発明は、いくつかの異なるオペレーティン
グ・システム（ＯＳ）において、さまざまなコンピュー
タで実行することができる。コンピュータは、例えば、
パーソナル・コンピュータ、ミニ・コンピュータ、また
は、メイン・フレーム・コンピュータとすることができ
る。コンピュータは、独立型システム、ローカル・エリ
ア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネ
ットワーク（ＷＡＮ）といったネットワークの一部、あ
るいは、さらに大規模なテレプロセシング・システムで
もかまわない。単に例示目的のため、コンピュータの特
定の選択を制限するのは、メモリ及びディスクの記憶要
件だけであるが、以下の説明おいては、本発明は、ＩＢ
ＭのＰＳ／２シリーズといったパーソナル・コンピュー
タで実施されるものとする。ＩＢＭのＰＳ／２シリーズ
のコンピュータに関するこれ以上の情報については、Ｉ
ＢＭ社、部品番号６８Ｘ２２２４、注文番号Ｓ６８Ｘ−
２２２４の　Ｔｅｃｈｎｉｃａｌ　Ｒｅｆｅｒｅｎｃｅ
　Ｍａｎｕａｌ　Ｐｅｒｓｏｎａｌ　Ｓｙｓｔｅｍ／２
　（Ｍｏｄｅｌ　５０．６０Ｓｙｓｔｅｍ）、及び、Ｉ
ＢＭ社、部品番号６８Ｘ２２５６、注文番号Ｓ６８Ｘ−
２２５６の　Ｔｅｃｈｎｉｃａｌ　Ｒｅｆｅｒｅｎｃｅ
　Ｍａｎｕａｌ，　Ｐｅｒｓｏｎａｌ　Ｓｙｓｔｅｍ／
２　（Ｍｏｄｅｌ　８０）　参照のこと。

【００３７】本発明の望ましい実施例が実施されたオペ
レーティング・システムは、プレゼンテーション・マネ
ージャ（ＰＭ）を備えたＩＢＭのＯＳ／２であるが、も
ちろん、本発明は、他のさまざまなオペレーティング・
システムで実施可能であり、さらに重要なことには、オ
ペレーティング・システムに統合する、従って、その一
部をなすようにすることが可能である。ＩＢＭのＯＳ／
２オペレーティング・システムに関するこれ以上の情報
については、ＩＢＭ社のＩＢＭ　Ｏｐｅｒａｔｉｎｇ　
Ｓｙｓｔｅｍ／２，　Ｖｅｒｓｉｏｎ　１．２，　Ｓｔ
ａｎｄａｒｄ　Ｅｄｉｔｉｏｎ　Ｔｅｃｈｎｉｃａｌ　
Ｒｅｆｅｒｅｎｃｅ　参照のこと。

【００３８】ここで図面を、とりわけ、図１を参照する
と、システム・ユニット１１、キー・ボード１２、マウ
ス１３、及び、グラフィックス・ディスプレイ装置また
はモニタ１４から成るパーソナル・コンピュータ１０が
示されている。キー・ボード１２及びマウス１３が、ユ
ーザの入力装置を構成し、ディスプレイ装置１４が、ユ
ーザの出力装置をなしている。マウス１３は、ディスプ
レイ装置１４のスクリーン１６上に表示されるカーソル
１５の制御に用いられる。このシステムによって支援さ
れるグラフィック・ユーザ・インターフェイス（ＧＵＩ
）は、ユーザが、カーソル１５をスクリーン１６上のア
イコンまたは特定の位置まで移動させ、次に、マウス・
ボタンの１つを押して、ユーザ指令または選択を実施す
ることにより「狙い撃ち」を行えるようにする。

【００３９】図２には、図１に示すパーソナル・コンピ
ュータのコンポーネントがブロック図の形で示されてい
る。システム・ユニット１１には、各種コンポーネント
が取りつけられていて、各種コンポーネント間における
通信に用いられるシステム・バス２１が含まれている。 マイクロプロセッサ２２は、システム・バス２１に接続
されており、やはり、システム・バス２１に接続された
読取り専用メモリ（ＲＯＭ）２３及びランダム・アクセ
ス・メモリ（ＲＡＭ）２４によって支援される。ＩＢＭ
　　ＰＳ／２シリーズのコンピュータにおけるマイクロ
プロセッサ２２は、８０２８６、８０３８６、または、
８０４８６マイクロプロセッサを含む　Ｉｎｔｅｌ社の
一群のマイクロプロセッサの１つであるが、６８０００
、６８０２０、または、６８０３０マイクロプロセッサ
といった　Ｍｏｔｒｏｌａ　社の一群のマイクロプロセ
ッサ、及び、ＩＢＭ、　Ｈｅｗｌｅｔｔ　Ｐａｃｋａｒ
ｄ，　Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍ，　Ｉｎｔｅｌ
，　Ｍｏｔｒｏｌａ，　及び、その他の会社で製造され
た各種ＲＩＳＣ（縮小命令セット・コンピュータ）マイ
クロプロセッサを含む、ただし、これらに制限されるわ
けではない他のマイクロプロセッサを特定のコンピュー
タに利用することが可能である。

【００４０】ＲＯＭ２３には、とりわけ、ディスク・ド
ライブとキー・ボードの対話といった基本ハードウェア
操作に制御を加える基本入力／出力システム（ＢＩＯＳ
）が含まれている。ＲＡＭ２４は、オペレーティング・
システム及びアプリケーション・プログラムがロードさ
れる主メモリである。メモリ管理チップ２５は、システ
ム・バス２１に接続されており、ＲＡＭ２４とハードデ
ィスク・ドライブ２６及びフロッピィディスク・ドライ
ブ２７の間におけるページング・データを含む直接メモ
リ・アクセス（ＤＭＡ）操作に制御を加える。

【００４１】システム・ユニット１１の完全な説明を行
うと、Ｉ／Ｏコントローラは３つ存在する。これらは、
キー・ボード・コントローラ２８、マウス・コントロー
ラ２９、及び、ビデオ・コントローラ３０であり、その
全てが、システム・バス２１に接続されている。その名
が示すように、キー・ボード・コントローラ２８は、キ
ー・ボード１２に関するハードウェア・インターフェイ
スを形成し、マウス・コントローラ２９は、マウス１３
に関するハードウェア・インターフェイスを形成し、ビ
デオ・コントローラ３０は、グラフィック・ディスプレ
イ装置１４に関するハードウェア・インターフェイスを
形成する。

【００４２】図１及び図２に示すハードウェアが一般的
であるが、特定のアプリケーションについては変更可能
である。すなわち、光学記憶媒体、音声Ｉ／Ｏ、プリン
タ等のような他の周辺装置とすることができる。本発明
は、特に、ハードウェアを制御または「操作」するオペ
レーティング・システムの強化を目ざしたものである。 既述のように、本発明は、既存のＯＳに加えることもで
きるし、あるいは、ＯＳに統合することもできるが、こ
の開示のため、ＯＳはＧＵＩを支援するものと仮定する
。こうしたオペレーティング・システムには、本発明が
実施されたプレゼンテーション・マネージャ（ＰＭ）を
備えたＩＢＭのＯＳ／２がある。

【００４３】本発明は、図３に全体が示されているさま
ざまな非関連アプリケーション・プログラムの整合する
環境を支援し、提供する開放形システムが得られるよう
にするものである。図３において、リンク・マネージャ
・システム（ＬＭＳ）３１は、例えば、スプレッドシー
ト・プログラム３２、ワード処理プログラム３３、モー
ション・ビデオ・プログラム３４、グラフィカル・イメ
ージ・プログラム３５、及び、音声プログラム３６を含
む５つのアプリケーション・プログラムを支援するもの
として示されている。さらに詳細に後述するように、Ｌ
ＭＳ３１は、例えば、ハードディスク・ドライブ２６（
図２）に記憶されたデータ・ベース３７を介して、いく
つかのアプリケーション・プログラムのそれぞれに対し
てユーザが指定したさまざまなリンクを維持する。

【００４４】データ・ベース３７は、ＬＭＳが維持する
連関の集合である。ＬＭＳに関与するものとするために
、クライアント・アプリケーションがデータを修正また
は改ざんする必要がないように、特に、意図的に、この
情報を別個に保つ設計が施された。この結果、ＬＭＳシ
ステムの開放度が増すことになった。

【００４５】基本的に、確立することができるリンクの
タイプは、２つある。図４に示す第１のタイプは、単方
向性リンクである。これは、マーカ・オブジェクト間リ
ンクである。図４において、４１及び４２は、各種アプ
リケーションが実行中のウインドウを表わしている。例
えば、ウインドウ４１には、ワード処理プログラムによ
って生成されるテキスト文書、グラフィックス・プログ
ラムによって生成されるイメージ、または、スプレッド
シートを表示することができる。マーカ４３を表示され
た文書、イメージ、または、スプレッドシートのあるポ
イントに位置決めして、このマーカ４３とウインドウ４
２内のオブジェクトを連係させることができる。連係し
たオブジェクトは、テキスト文書、イメージ、スプレッ
ドシート、オーディオ、ビデオ、スライドでの表示、ま
たは他の任意のアプリケーションに含まれている。マー
カ４３の選択によって、連係したオブジェクトは、ウイ
ンドウ４２に表示されるが、マーカ４３には戻らないの
で、このリンクは単方向性である。

【００４６】図５には、双方向性リンクが示されている
。これは、マーカ・オブジェクト間リンクではなく、マ
ーカ・マーカ間リンクである。従って、例えば、ウイン
ドウ４１内のマーカ４３とウインドウ４２内のマーカ４
４を連係させることができる。マーカ４３を選択するこ
とによって、ウインドウ４２におけるテキスト文書、イ
メージ、または、スプレッドシート内のマーカ４４が表
示される。マーカを同じアプリケーション内のマーカに
連係させることができる点に留意されたい。例えば、テ
キスト文書内のマーカ４５ともう１つのマーカ４６を連
係させることができる。図５に示すように、、マーカ４
６とマーカ４５を同時に見えるようにすることはできな
いが、マーカ４５を選択することによって、文書におけ
るマーカ４６の位置する部分が表示される。同様に、マ
ーカ４６を選択すると、文書におけるマーカ４５の位置
する部分が表示される。

【００４７】図６には、リンク・マネージャ・サービス
（ＬＭＳ）５１と各種クライアント・アプリケーション
５２の関係が、ブロック図の形で示されている。さらに
詳細に後述するように、ＬＭＳ５１によって、均いで、
整合性のあるエンド・ユーザ・インターフェイス（ＥＵ
Ｉ）が得られる。とりわけ、ＬＭＳ５１は、これまで個
々のクライアント・アプリケーションによって実施され
てきたいくつかの機能を実施する。これらには、ＥＵＩ
の一部を構成するメニュ及び対話ボックスが含まれてい
る。例えば、特定のクライアント・アプリケーションが
、ＬＭＳ５１に対する呼出しを行うと、ＬＭＳ５１は、
必要なメニュまたは対話ボックスを生成し、これによっ
て、クライアント・アプリケーション間における完全に
均いで、整合性のあるＥＵＩが確保される。さらに、Ｌ
ＭＳ５１は、さまざまなクライアント・アプリケーショ
ン５２に着手することが可能なＥＵＩを提供する。これ
については、各種図面の図に関連した以下の論述から明
らかになるが、もちろん、ＬＭＳ５１は、クライアント
・アプリケーションの１つが生成したデータにアクセス
するビークルであり、マーカに連係したデータにアクセ
スするため、必要な時に、自動的にクライアント・アプ
リケーションに着手する。

【００４８】図６には、新しい概念、すなわち、「ウェ
ブ」の概念が導入されている。「ウェブ」という用語は
、文書、リンク、及び、リンク・マーカの定義の集合を
表わすのに用いられる。ウェブは、ＬＭＳが定義された
連関のナビゲーションに必要とする全ての情報を表して
いる。ナビゲーションによって、エンド・ユーザは、１
つの文書におけるリンク・マーカから、もう１つのアプ
リケーション、異なるアプリケーションによって与えら
れる文書、欄外書込み（オーディオ、テキスト等）、ま
たは、同一文書内の別の位置への移行が可能になる。 目標アプリケーションは、ＬＭＳの利用に関与するもの
もあれば、あるいは、ＬＭＳについて承知していないも
のもあり得る。すなわち、ウェブを用いることによって
、ＬＭＳは、文書自体に修正を加えなくても、文書間の
連関に関した全ての必要なデータを維持することが可能
になる。

【００４９】あるアプリケーションにおいて、ウェブは
、便宜上、ワード・プロセッサ、スライドでの表示、オ
ーディオでの表示等のようないくつかのクライアント・
アプリケーションを利用して、エンド・ユーザに、特定
のトピックに関する情報にアクセスする複数の選択を提
示する表示システムと考えることができる。一般に、ト
ピックの表示は、例えば、指導者といったシステムの第
１のタイプのエンド・ユーザによって作成され、例えば
、学生といったシステムの第２のタイプのエンド・ユー
ザによって見られる。例えば、学生に対するトピックの
提示は、ディスプレイ装置１４（図１参照）のスクリー
ン１６に初期ウインドウを表示することによって開始す
ることができ、学生は、選択すべきリンク・マーカを１
つ以上有しているのが普通である。さらに、学生の特定
の選択に応じて、この提示は、任意の順序に従うことに
なる。

【００５０】上述の例を用いると、エンド・ユーザが、
栄養に関するハイパーメディア文書を読み取っていて、
リンク・マーカに出くわし、リンク・マーカをトリガす
れば（例えば、指示装置を介して活動化する）、栄養価
の表がエンド・ユーザに示されることが指示されて、エ
ンド・ユーザがリンク・マーカを活動化すると、エンド
・ユーザに栄養価の表が提示されることになる。エンド
・ユーザが、ハードコピーの形をとる文書（例えば、本
）を利用している場合、エンド・ユーザは、その文書の
インデックスまたは他の相互参照セクションを用いて、
栄養価の表を探索し、おそらくは、その表を求めて多数
の参照箇所を確かめなければならないであろうが、実際
の表に関するものはそのうちの１つだけである。

【００５１】このタイプの提示を支援するためＬＭＳ５
１は、マーカのユーザ選択、あるいは、キー・ワードの
入力に応答して、ウェブ・データ・ベース５３にアクセ
スし、プレゼンタ（すなわち、アプリケーション、プロ
グラム）に着手して（開始する）、必要となる情報を与
える。ウェブ・ビューア５４を用いて、ウェブ・データ
・ベース内における文書、リンク、及び、マーカの関係
がグラフィック表示される。ウェブ・ビューア５４は、
ＬＭＳによって与えられる２つのタイプの能力−　（ａ
）可変量のスコープによって（例えば、アプリケーショ
ンのウェブ全体、または、ほんのわずかな文書に対する
「ズーム・イン」）ＬＭＳに記録されている文書間にど
んな連関が存在するかを確めることができるツール、及
び（ｂ）ウェブ・データ・ベースの管理及び開発用ツー
ル　−を備えたクライアント・アプリケーションである
。データ・ベース５３は、一般に、ハード・ディスク・
ドライブ２６に記憶されており（図２）、ウェブ・ビュ
ーア５４は、ディスプレイ装置１４（図１）に対する出
力スクリーンを提供する。ただし、ウェブ・ビューアが
、基本をなすオペレーティング・システム、装置、また
は、ＬＭＳによって得られる一般的な提示スペース及び
装置の両方または一方でないことは明かである。さらに
、ＬＭＳを使用するためにそれを用いる必要はない。ウ
ェブ・ビューアは、開示される、請求の範囲に記載の発
明を実施し、あるいは、理解するのに必要のない一般的
ユーティリティ・アプリケーションであり、従って、こ
れ以上詳細な説明は行わない。

【００５２】本発明が実施される特定のＧＵＩ環境が、
ウインドウ環境である。基本メッセージのセット・アッ
プは、ＯＳ／２　ＰＭ、ＭｉｃｒｏｓｏｆｔＲ　ウイン
ドウ、及び、Ｘウインドウを含むほとんどのウインドウ
・システムに共通である。基本的には、該システムにお
ける全てのウインドウが、それに関連したウインドウ手
順と呼ばれるものを備えている。オペレーティング・シ
ステムが、ウインドウにメッセージを送る際、そのメッ
セージは、そのウインドウに関連したウインドウ手順に
対して経路指定される。ウインドウ手順は、そのウイン
ドウを所有しており、いくつかのタイプのメッセージを
扱う方法を知っているアプリケーションによって得られ
るコードの一部にすぎない。オペレーティング・システ
ムからウインドウに送られる通常のメッセージが、ユー
ザ入力メッセージである。メッセージには、ボタンを押
すとか、ウインドウの活動化とかいったことが含まれる
。ウインドウがメッセージを受信するウインドウ手順は
、メッセージに従うこともあれば、メッセージに従わな
いこともあり得る。ウインドウ手順がメッセージに従わ
ない場合、呼び出すことが可能な省略時手順がいくつか
ある。

【００５３】本発明の場合、ＬＭＳは、ウインドウ機能
も利用する。流れ図のある位置で、ユーザ・アクション
としてオペレーティング・システムから、通知としてＬ
ＭＳからウインドウ手順に入る両方の矢印が示されてい
る。それは、ＬＭＳが、アプリケーションのウインドウ
手順に通知メッセージも送るということになる。

【００５４】ここで、図面のうちの図７を参照すると、
本発明によれば、クライアント・アプリケーションのウ
インドウ手順の論理が示されている。これには、別様の
場合はクライアント・アプリケーションとして知られる
、一般的なＬＭＳで使用可能となるアプリケーションの
ウインドウ手順が示されている。ユーザは、操作ブロッ
ク６１において何らかの入力を行い（例えば、マウス・
ボタンを押し、メニュを選択し、キーまたはキーの組合
せを押し、等々）、オペレーティング・システムが、そ
のメッセージをクライアント・アプリケーションのウイ
ンドウ手順に送る。クライアント・アプリケーションの
ウインドウ手順が、そのメッセージを得ると、判定ブロ
ック６２においてメッセージのテストを行い、それが指
令メッセージ（例えば、メニュ指令メッセージ）である
か否かを確認する。指令メッセージであれば、アプリケ
ーションは、判定ブロック６３においてさらにテストを
行い、それが定義されているメニュ指令の１つであるか
否か、すなわち、それが、ＬＭＳと関係なく、該アプリ
ケーションに関連したメニュの１つであるか否かを確か
める。これらの指令には、新しいファイルを開く指令、
カット指令、ペースト指令、及び、アプリケーションに
固有のその他の指令が含まれている。それが、アプリケ
ーション自体が定義したメニュ・オプションの１つであ
る場合、アプリケーションは、ＬＭＳが存在しないかの
ように、先に進み、機能ブロック６４において指令の処
理を行うだけである。一方、指令が、アプリケーション
によって定義されたメニュ項目でなく、メニュ指令であ
る場合、アプリケーションは、機能ブロック６５におい
て省略時ＬＭＳ処理手順を呼び出す。このサービスは、
ＬＭＳ省略時処理手順である、単なる機能呼出しの１つ
でしかない。従って、アプリケーションがメニュ指令を
理解していなければ、アプリレーションは、ＬＭＳサー
ビスを呼び出すことになる。

【００５５】判定ブロック６２に戻って、指令がメニュ
指令なければ、判例ブロック６６及び６７でテストを行
い、それがアプリケーションに固有の他のタイプのメッ
セージであるか否かを確かめる。例えば、アプリケーシ
ョンの中には、マウス・メッセージが入力されたか否か
を知ることに関心のあるものもある。判定ブロック６６
の判定により、入力されている場合、アプリケーション
は、それがマウス・メッセージを処理するタイプのアプ
リケーションであれば、機能ブロック６８においてその
処理を行う。アプリケーションの中には、これらのメッ
セージの処理を行わなかったり、行う必要のないものも
あり、一般に、アプリケーションは、そのメッセージの
処理を行うか否かは別にして、機能ブロック６９におい
て省略時ＬＭＳ手順の呼出しを行うのが望ましく、ＬＭ
Ｓは、そのメッセージを調べて、それに応じて作用する
機械を得る。

【００５６】指令がマウス・メッセージでなければ、ア
プリケーションは、判定ブロック６７において、そのメ
ッセージが他のアプリケーションに固有のメッセージか
否かを判定し、そうであれば、アプリケーションは、そ
れが呼び出す機能が何であれ、呼出しを行って、機能ブ
ロック７１でそのメッセージの処理を行う。別様の場合
には、アプリケーションが処理方法を知らないメッセー
ジの場合のように、アプリケーションは、機能ブロック
７２においてＬＭＳ省略時処理手順の呼出しを行う。

【００５７】ユーザ入力によって生じるメッセージの加
えて、ＬＭＳは、機能ブロック７３の指示に従い、それ
自体、メッセージの受信を期待しているクライアント・
アプリケーションにそれ自体のメッセージを送る場合も
ある。例えば、１つのウインドウにおけるＬＭＳが、シ
ステム内の別のウインドウに、そのウインドウがＬＭＳ
を承知しているか否かを尋ねるメッセージを送るが、そ
の別のウインドウにおけるアプリケーションは、そのメ
ッセージを理解しない。このメッセージは、マウス・メ
ッセージ、メニュ指令メッセージ、または、アプリケー
ションに固有のメッセージのカテゴリには入らず、従っ
て、アプリケーションは、このメッセージの処理を行わ
ないで、ＬＭＳ処理手順を呼び出す。ＬＭＳ処理手順は
、そのメッセージを承知しており、先に進んで、真、す
なわち、「はい、私はＬＭＳを承知しているアプリケー
ションです」に戻る。

【００５８】基本的なハードウェア及びシステムについ
て説明してきたが、次に、ＬＭＳの働きについて例示す
ることにする。図７には、ビット・マップ表示グラムに
よって得られるコンピュータ表示スクリーンが示されて
いる。このプログラムは、ＧＬＯＢＥ．ＢＭＰ文書（ビ
ット・マップ・グラフィック）を提供するプレセンタ（
すなわち、アプリケーション）である。ＧＬＯＢＥ．Ｂ
ＭＰ文書には、関連情報の存在を示すリンク・マーカ（
そのテキストの表示は、“Ｍｏｒｅ　ｉｎｆｏ−＞”）
が含まれている。マウスでクリック音を出して操作され
ると、リンク・マーカに関連したリンクがナビゲーショ
ンを受け、ユーザには、ＷＯＲＬＤ．ＴＸＴ文書（図９
参照）を与える　Ｆｉｌｅ　Ｂｒｏｗｓｅｒ　プレゼン
タが提示される。ＷＯＲＬＤ．ＴＸＴ文書には、追従す
ると、ＧＬＯＢＥ．ＢＭＰ文書までトラバースすること
になるリンク・マーカ（そのテキストの表示は、“Ｓｅ
ｅ　ａ　ｐｉｃｔａｕｒｅ−＞”）も含まれている。

【００５９】前述のように、ＬＭＳは、メニュ生成の責
務を想定して、整合のとれたＥＵＩも提供する。２つの
タイプのメニュ、すなわち、コンテキスト・メニュ（ポ
ップ・アップ・メニュと呼ばれることもある）とプル・
ダウン・メニュがある。前者は、ディスプレイの映像面
内におけるコンテキストまたはカーソルの位置に従って
表示されるメニュである。図１０及び図１１には、２タ
イプのコンテキスト・メニュの例が示されている。図１
０の場合、ユーザが、アフリカ大陸の上部に近いクライ
アント・アプリケーションのクライアントまたは作業空
間領域の上において、マウス・ボタンをクリック音を立
てて操作したところである。このコンテキスト・メニュ
によって、ユーザに、その位置においてリンク・マーカ
を生成することを含むいくつかのオプションが与えられ
る。図１０の場合、ユーザがリンク・マーカの上でクリ
ック音を立てて操作したところである。表示されるコン
テキスト・メニュは同様であるが、異なるオプションを
提供し（異なるコンテキストのため）、とりわけ、ユー
ザが、リンク・マーカを移動または削除させることを可
能にする。

【００６０】クライアント・アプリケーションは、ＬＭ
Ｓに対して、コンテキスト・メニュを構築するように明
示的に命令する必要はなく、場合によっては（例えば、
マウスが図１１におけるようにリンク・マーカの上にあ
る場合）、ＬＭＳに対してメッセージを送る必要さえな
い。コンテキスト・メニュは、従って、ＬＭＳのほとん
ど“自由な”機能となり、プル・ダウン・メニュの同じ
機能性に接近する。

【００６１】クライアント・アプリケーションの初期設
定時には、クライアント・アプリケーションが、ＬＭＳ
を呼び出して、ハイパーメディア・プル・ダウン・メニ
ュの構築を要求する。次に、ＬＭＳは、動的にメニュを
構築するので、メニュは、クライアント・アプリケーシ
ョン・コードで定義するする必要はない。ＬＭＳが、ク
ライアント・アプリケーションが処理に関心のない操作
システムのメッセージを受信すると、メニュの後続する
全ての処理（例えば、メニュ項目に隣接してチェック・
マークを配置したり、メニュ項目を使用禁止にしたり、
メニュ項目を選択したりする処理等）は、ＬＭＳによっ
て取り扱われる。

【００６２】クライアント・アプリケーションによって
処理されない全ての操作システム・メッセージは、クラ
イアント・アプリケーションによってＬＭＳに送られ、
ＬＭＳによって供給されるサービスを利用することにな
る。これには、メニュ・メッセージが含まれている。Ｌ
ＭＳは、特定のメニュ・メッセージに基づいて、何をな
すべきかを判定し、それを実施する。例えば、メッセー
ジが、ハイパーメディア・メニュが示されようとしてい
るということであれば、必要な場合、ＬＭＳは、メニュ
の外観を示す前に、リンク及びリンク・マーカの現在の
状態に基づき、それに調整を加え（例えば、不適当なメ
ニュ・オプションを全て使用禁止にする）、また、メッ
セージが、“マーカを生成する”が選択されたというこ
とであれば、ＬＭＳは、クライアント・アプリケーショ
ンの一部に追加作業を施さずに、エンド・ユーザに対し
てリンク・マーカを生成する。ＬＭＳを用いる全てのア
プリケーションが同じハイパーメディア・メニュを有す
ることになり、該メニュは、同じような働きをするので
、整合のとれたＥＵＩが確保される。

【００６３】図１２〜図１６には、例が示されている。 詳述すると、図１２には、アクションまたは指令バーに
おいてＬＩＮＫ上でクリック音を立ててマウスを操作し
た場合の、プル・ダウン・メニュが示されている。

【００６４】プル・ダウン・メニュは、層をなすように
することができる。例えば、図１３には、図１２の第１
のプル・ダウン・メニュにおいてＭＡＮＡＧＥ　　ＭＡ
ＲＫＥＲＳ上でクリック音を立ててマウスを操作した場
合の、第２のプル・ダウン・メニュが示されており、図
１４には、図１３の第２のプル・ダウン・メニュにおい
てＣＲＥＡＴＥ　　ＭＡＲＫＥＲ上でクリック音を立て
てマウスを操作した場合の、第３のプル・ダウン・メニ
ュが示されている。図１５には、もう１つの例が示され
ているが、これは、図１２のプル・ダウン・ウインドウ
においてＭＡＮＡＧＥ　　ＬＩＮＫＳ上でクリック音を
立ててマウスを操作した場合の、第２のプル・ダウン・
ウインドウが示されており、図１６には、図１５の第２
のプル・ダウン・ウインドウにおいてＣＲＥＡＴＥ　　
ＬＩＮＫ上でクリック音を立ててマウスを操作した場合
の、第３のプル・ダウン・ウインドウが示されている。

【００６５】図１６は、プル・ダウン・メニュの処理に
関する論理を示す流れ図である。該メニュに含まれたさ
まざまなメニュ項目を全て得るには、ＬＭＳは、クライ
アント・アプリケーションに関するメニュを実際に構築
することになるが、これも、また、将来、ＬＭＳの追加
機能性の開放が加えられと、ＬＭＳがそのメニュを構築
するので、クライアント・アプリケーションは、追加の
ＬＭＳの機能を持ち越す新しいバージョンを開放する必
要がないということを表わしている。ＬＭＳがメニュを
構築する方法は、クライアント・アプリケーションが、
まず始動すると、ＬＭＳ　　ＡＰＩ機能呼出しによって
ＬＭＳの呼出しを行い、機能ブロック７５に示すように
、トップ・レベル・メニュ、通常は、アクション・バー
に対する操作をＬＭＳに移行する。ＬＭＳは、次に、機
能ブロック７６において、資源として保管されているプ
ル・ダウン・メニュの定義をその動的リンク・ライブラ
リの一部としてロードする。ＬＭＳが資源をロードする
場合、機能ブロック７７において、クライアント・ウイ
ンドウ・メニュのハンドルにそれを挿入し、あるいは、
付加する。その後は、エンド・ユーザによってそのメニ
ュ・オプションが選択されると、そのメニュ内における
全てのＬＭＳメニュ項目が見れることになる。この手順
は、初期設定時に行われる。

【００６６】図１７の流れ図の残りの部分には、実際の
プル・ダウン・メニュの処理方法が示されている。ＬＭ
Ｓに２タイプのメニュがある点に留意されたい。プル・
ダウン・メニュは、ユーザがアクション・バーからリン
クを選択すると表示されるメニュであり、一方、コンテ
キスト・メニュは、クライアント・ウインドウにおける
クリック音を発するマウス操作に応答して表示される。 コンテキスト・メニュは、同様のオプションを提供する
が、ユーザがクリック音を立てて操作したオブジェクト
に対してより限定されることになる。従って、これら２
タイプのメニュに関する処理で行われる内容は異なる。

【００６７】機能ブロック７８で示すように、ユーザ・
アクションが始まると、機能ブロック７９で示すアプリ
ケーションのウインドウ手順に進む。その時点で、アプ
リケーション・ウインドウ手順は、これが知っている（
すなわち、アプリケーション・コードによって規定され
た）メニュ指令でないと判定することができ、そのメッ
セージをＬＭＳ処理手順に送る（図７参照）。判定ブロ
ック８１において、ＬＭＳは、メッセージがメニュの提
示を要求しているか否かを判定する。要求している場合
、機能ブロック８２において、ＬＭＳは、適用可能なメ
ニュ項目を使用可能にし、適用可能でないメニュ項目を
使用禁止にし、かつ、メニュ項目のチェックを行うか、
あるいは、このいずれかを行う。メニュの提示を要求し
ていない場合、判定ブロック８３において、そのメッセ
ージがメニュ指令メッセージか否かの判定を行う。 メニュ指令メッセージでなければ、機能ブロック８４に
おいて、“非メニュ指令メッセージ・プロセッサ”が呼
び出される。この手順については、図１９に関連してさ
らに詳しく後述する。メッセージが、メニュ指令の場合
、ＬＭＳは先へ進んで、適切なアクションを実施しよう
とする。例えば、ＬＭＳが処理する保管マーカ及びリン
ク、合言葉などのようないくつかのメッセージがある。 メッセージが、判定ブロック８５、８６、及び、８７で
の判定により、ＬＭＳが処理するものであれば、ＬＭＳ
は、機能ブロック８８においてクライアント・アプリケ
ーションに今度のアクションを知らせ、次に、クライア
ント・アプリケーションが、判定ブロック８９における
判定に従ってＬＭＳが指令を実施することに反対しなけ
れば、ＬＭＳが、機能ブロック９０において機能を実施
し、機能ブロック９１においてクライアント・アプリケ
ーションに通知し、機能ブロック９２において、“真”
のメッセージを戻す。従って、メッセージが、ＬＭＳが
処理する指令の１つであれば、ＬＭＳは、さらに詳しく
後述するように指令を実施する。次に、ＬＭＳは、指令
を実施した後、クライアント・アプリケーションに通知
するが、その時点で、操作を加えたばかりのオブジェク
トに対するハンドルもクライアント・アプリケーション
に与えるので、クライアント・アプリケーションは、後
処理を施すことが可能になる。

【００６８】メッセージが、判定ブロック９３において
判定されるリンク・マーカ操作である場合、判定ブロッ
ク９４において、さらにテストが実施され、リンク・マ
ーカが選択された状態にあるか否かを判定する。リンク
・マーカは、ユーザが指令プル・ダウン・メニュからそ
の修正を行えるようになる前に、選択された状態になっ
ていなければならない（これは、コンテキスト・メニュ
にはあてはまらないが）。一般に、選択された状態にな
いオブジェクトにしか作用しない項目は、グレイ・アウ
トされる。例えば、選択されたリンク・マーカがなけれ
ば、リンク・マーカの移動がグレイ・アウトされ、ユー
ザは、それを選択することができなくなる。選択された
リンク・マーカがなければ、リンク・マーカの修正が使
用禁止になり、ユーザは、その指令を選択できなくなる
。これは、コンテキスト・メニュの場合は、適用できな
い項目を削除するだけであるという点で、コンテキスト
・メニュとは異なっている。いずれにせよ、ＬＭＳは、
ダブル・チェックを行って、作業の実施が許可されるが
どうか確かめるためのコードを提供する。従って、メニ
ュ指令がリンク・マーカに対して作用するものであれば
、まず、選択された状態で選択されたマーカが、少なく
とも１つは存在するか否かを判定し、存在すれば、先へ
進み、適正なリンク・マーカ指令、すなわち、判定ブロ
ック９５、９６、９７、９８、９９、及び、１００にお
ける判定に従ったリンク・マーカの修正、リンクの生成
、リンクの完成、リンク・マーカの表示、リンク・マー
カの隠蔽等を実施する。リンクの生成及びリンクの完成
は、リンク・マーカから生じるリンクを生成し、あるい
は、リンク・マーカに対するリンクを完成するので、リ
ンク・マーカの操作とみなされる。指令が完了すると、
クライアント・アプリケーションには、ＬＭＳが指令を
実施したことが通知され、真が戻される。

【００６９】次に、図１８を参照すると、コンテキスト
・メニュ処理手順１０１の論理を表わした流れ図が示さ
れている。このプロセスは、まず、判定ブロック１０２
及び１０３において、ＬＭＳがどんなタイプのコンテキ
スト・メニュを表示することになっているかを判定する
ことで開始する。判定ブロック１０２のテストでは、文
書のコンテキスト・メニュを表示すべきか否かが判定さ
れ、判定ブロック１０３のテストでは、リンク・マーカ
のコンテキスト・メニュを表示すべきか否かが判定され
る。ＬＭＳが文書のコンテキスト・メニュを表示するこ
とになっている場合、機能ブロック１０４において、該
メニュの資源定義がロードされ、ＬＭＳが、リンク・マ
ーカのコンテキスト・メニュを表示することになってい
る場合、機能ブロック１０５において、リンク・マーカ
のメニュに関する資源がロードされる。文書のコンテキ
スト・メニュでも、リンク・マーカのコンテキスト・メ
ニュでもなければ、機能ブロック１０６において、エラ
ー・メッセージが戻される。

【００７０】ＬＭＳが、メニュをロードすると、機能ブ
ロック１０７において、隠れウインドウが生成され、実
際に、ロードされたばかりのメニュを所有することにな
る。次に、機能ブロック１０８において、ロードされた
メニュが新しいウインドウに加えられ、機能ブロック１
０９において、ウインドウは、メニュを表示するように
命じられる。もちろん、リンク・プル・ダウン・メニュ
からの項目が使用可能になったり、使用禁止になったり
する場合と同様、オブジェクトの状態に基づいて、メニ
ュ内の項目が除去されることになる。この時点で、ＬＭ
Ｓは、機能ブロック１１０におけるユーザ選択を待機す
る。判定ブロック１１１において、ユーザが、実際に、
メニュを取り消したか、あるいは、メニュから項目を選
択したかの判定を行う。メニュ項目が実際に選択された
場合、指令ＩＤが、機能ブロック１１２の指示に従って
戻される。取り消された場合には、機能ブロック１１３
において、偽が、戻される。

【００７１】メニュが選択されたために、ＬＭＳがユー
ザ指令を得るという場合について述べてきたが、他の非
メニュ指令の処理についてはどうか？　　ほとんどのウ
インドウ・システムについて一般に得られる機能は、メ
ッセージの機能である。メッセージは、あるアプリケー
ションに対してオペレーティング・システム、もう１つ
のアプリケーション、それ自体、または、該アプリケー
ションのために行われるサービスから送ることができる
。 これらのメッセージは、アプリケーションに対して、要
求、要求に対する応答、実施されるアクション等を通知
するものである。

【００７２】同様に、ＬＭＳは、このメカニズムを利用
し、クライアント・アプリケーションが、任意に、ＬＭ
Ｓがとろうとしているアクションに気づき、これを適格
とみなすか、制限するか、修正するか、あるいは、阻止
することができるようにする。さらに、ＬＭＳは、何ら
かのアクションがとられた後、メッセージによってクラ
イアント・アプリケーションに知らせる。メッセージは
、“後”だけでなく“前”にも、メッセージによって表
わされるアクションが、ＥＵＩを利用するエンド・ユー
ザによって開始されたか、もう１つのクライアント・ア
プリケーションによって開始されたか、あるいは、その
アプリケーション自体によって開始されたかには関係な
く、送られる。一般に、クライアント・アプリケーショ
ンは、これらのメッセージを自由に無視する（省略時処
理に委ねる）ことにより、それらに省略時（ＬＳＭ）処
理を施すことが可能である。ただし、別様に行う場合も
有り得る。

【００７３】例えば、ＬＭＳは、プル・ダウン・メニュ
またはコンテキスト・メニュを表示するように要求され
ると、メニュに関してアクションをとる前に、クライア
ント・アプリケーションに対しそのことを知らせるメッ
セージを送る。ＬＭＳメニュが実際に表示される前に、
クライアント・アプリケーションが、ＬＭＳメニュから
の項目の使用禁止／除去を望む場合がある。同様に、Ｌ
ＭＳメニュ項目が要求されると（例えば、リンク・マー
カを生成するように）、あるいは、エンド・ユーザが、
リンク・マーカ上で“クリック音を立てて操作”するこ
とにより、１つ以上のリンク・マーカの“もう一方の端
”の１つに対するＬＭＳのナビゲーション／追従を要求
すると、クライアント・アプリケーションに対してその
ことを通知するメッセージが送られる。

【００７４】ＬＭＳは、クライアント・アプリケーショ
ンが、ＬＭＳハイパーメディア・システムの挙動及びデ
ータに対して任意に制御を加えることができるようにす
る強力なＡＰＩを提供する。実際、ＬＭＳ　　ＡＰＩは
、機能性及び能力に関して、ＬＭＳ　　ＥＵＩの有効な
スーパーセットであり、クライアント・アプリケーショ
ンに強大な能力及び可能性を提供するものである。ただ
し、より一般的には、クライアント・アプリケーション
がハイパーメディアに関与するものとして重要な働きを
するためには、ＬＭＳ　　ＡＰＩの利用を最小限にとど
める必要がある。

【００７５】非メニュ指令のメッセージ処理手順に関す
る論理の流れ図である図１８を参照する。やはり、機能
ブロック１１５において、ユーザが入力を行い、オペレ
ーティング・システムが、機能ブロック１１６において
、クライアント・アプリケーションのウインドウ手順に
メッセージを与える。ウインドウ手順は、前述のように
、機能ブロック１１７においてＬＭＳにメッセージを送
る。

【００７６】この処理手順は、ＬＭＳが、メッセージが
メニュ指令であるか否かを確かめるテストを終えている
という仮定にたつものである。メニュ・メッセージ以外
の他のメッセージには、マウス・メッセージ、ＬＭＳ自
体からＬＭＳへ送られる他のウインドウからのメッセー
ジ（例えば、もう１つのアプリケーションに、ＬＭＳが
承知のアプリケーションか否かを尋ねるようなメッセー
ジ）等がある。非メッセージ指令のメッセージ・プロセ
ッサは、判定ブロック１１８において、まず、マウス・
ボタン３が押されたか否かを確かめる。押されている場
合、機能ブロック１１９において、コンテキスト・メニ
ュ処理に戻され、判定ブロック１２１において、テスト
が行われ、ユーザによって指令が入力されたか、あるい
は、ユーザによって取消しが選択されたかが確かめられ
る。指令が選択された場合、ＬＭＳは、機能ブロック１
２２に指示されているように、また、図１７及び図１８
に例示のように、基本的なプル・ダウン・メニュ処理を
行う。基本的には、ＬＭＳは、上述のように、クライア
ント・アプリケーションに通告して、指令を実行する。 流れ図の表記において、流れ図に、「メニュのプル・ダ
ウン処理を行う」が現われる毎に、プロセスは、メニュ
のプル・ダウン処理に関して図１７に示す流れ図の上部
へ移行せずに、図１７の機能ブロック８８に入るという
点を想起されたい。

【００７７】判定ブロック１１８に戻ると、マウス・ボ
タン３が押されていなければ、判定ブロック１２３にお
いてさらにテストが行われ、メッセージが、シフト・キ
ー・プラス・マウス・ボタン１であるか否かが判定され
る。これが、リンク及びリンク・マーカの生成方法であ
る。上述の通りであれば、ＬＭＳは、機能ブロック１２
４においてその処理を行う。そうでなければ、判定ブロ
ック１２５においてテストを行い、それが指令メッセー
ジであるか否かが判定される。指令メッセージであれば
、判定ブロック１２６において、その指令がどんな種類
の指令であるかに関する判定、すなわち、ＬＭＳが、指
令として定義したのが指令１であるか？の判定が行われ
る。指令１であれば、機能ブロック１２７において、メ
ッセージが、アプリケーションに送られる。アプリケー
ションは、その処理を望まないので、該メッセージは、
やはり、フィルタリングを施されて、ＬＭＳに戻され、
ＬＭＳが、そのＬＭＳ指令処理を行うことになる。 メッセージが指令メッセージでない場合、機能ブロック
１２８において、そのメッセージがＬＭＳの理解するも
のでなければ、ＬＭＳはそれを廃棄するだけである。

【００７８】判定ブロック１２５に戻ると、指令メッセ
ージでなければ、判定ブロック１２９においてテストが
行われ、そのメッセージがＬＭＳメッセージであるか否
かの判定、すなわち、これが、ＬＭＳがそれ自体との通
信に用いるＬＭＳに固有のメッセージであるか？の判定
が行われる。ＬＭＳを利用しているさまざまなプロセス
のために実行されるＬＭＳは、これらのメッセージを送
り返したり、送り出したりして、クライアント・アプリ
ケーションを必要とせずに、互いに通信することができ
る。ＬＭＳメッセージであれば、そのタイプのメッセー
ジの一例が、判定ブロック１３１に示すような、アプリ
ケーションがＬＭＳの承知しているものか否かに関する
照会である。ＬＭＳメッセージでなければ、他のウイン
ドウがこのメッセージを得た場合、呼び出すべき処理手
順がないことになる。従って、そのウインドウは、その
メッセージを理解できないことを表わした、儀を戻すだ
けである。一方、このメッセージが、ＬＭＳの承知して
いるアプリケーションに届くと、それは、機能ブロック
１３２に示すように、真を戻す。このメッセージは、前
述のように、フィルタリングを施されて、ＬＭＳ処理手
順に戻される。判定ブロック１２９において、メッセー
ジがＬＭＳメッセージでないということになれば、機能
ブロック１３３において、メッセージが廃棄される。

【００７９】エンド・ユーザは、マウスを利用して、ス
クリーン上でオブジェクトとの対話を行う。ＬＭＳ、マ
ウスによるＬＭＳオブジェクト（例えば、文書及びリン
ク・マーカ）との対話を管理する。ＬＭＳは、いくつか
のやり方でマウスのアクションを管理する。

【００８０】クライアント・アプリケーションは、一般
に、マウス・メッセージをＬＭＳに送る。ＬＭＳがこれ
らのマウス・メッセージを受け取ると、ハイパーメディ
アに固有のアクションをとる必要があるか否かを判定す
る。このメカニズムを利用することによって、ＬＭＳは
、クライアント・アプリケーションの「クライアント・
ウインドウ」（主アプリケーション作業空間）の監督に
当たる時、マウスを制御することが可能になる。クライ
アント・アプリケーションが、まず、文書を表示すると
、ＬＭＳにこれを通知し、ＬＭＳに対して文書名、及び
、文書の表示がなされるウインドウのハンドルが知らさ
れる。次に、ＬＭＳは、ＬＭＳデータ・ベースからその
文書に関連した全てのＬＭＳオブジェクトを入手する。 これで、ＬＭＳは、クライアント・アプリケーションの
クライアント領域に生じるマウス・メッセージの処理に
十分な情報を得たことになる。これによって、ＬＭＳは
、クライアント・アプリケーションのクライアント・ウ
インドウにコンテキスト・メニュを表示できるようにな
る（図１０参照）。マウス・メッセージがＬＭＳに送ら
れると、ＬＭＳは、文書内におけるハイパーメディア・
オブジェクト（リンク、リンク・マーカ等）の状態を判
定して、コンテキスト・メニュ内の項目をどんなタイプ
にすべきか決定することができる（例えば、「リンク・
マーカを保管する」、「リンク・マーカを隠す」等）。 この機能は、“迅速な”リンクを形成する操作にも利用
され、この結果、ユーザは、２つのポイント（同一文書
内、または、異なる文書及びプレゼンタ）のうえでクリ
ック音を発してマウスを操作するだけで、２つのリンク
・マーカ（各ポイント１つ）と、その間のリンクを自動
的に生成することが可能になる。これは、エンド・ユー
ザがここに２つのリンク・マーカを生成し、それからリ
ンクを生成することによって行われるのが普通である。 以上の機能性は、全て、クライアント・アプリケーショ
ンの助けを受けずに、または、クライアント・アプリケ
ーションに関する知識を持たずに実現され、ＬＭＳサー
ビスを利用する全てのクライアント・アプリケーション
について整合のとれるものである。

【００８１】ＬＭＳリンク・マーカは、オペレーティン
グ・システムから直接メッセージを受信し、また「リン
ク・マーカ」としてオペレーティング・システムに知ら
れているクラスのウインドウは、ＬＭＳが「所有」して
いるので（すなわち、このタイプのウインドウがメッセ
ージを得ると、オペレーティング・システムは、ＬＭＳ
コードを直接呼び出すことになる）、リンク・マーカ・
ウインドウにおけるマウス管理は、クライアント・アプ
リケーションがメッセージをＬＭＳに“送る”ことを必
要とせずに、実施される。

【００８２】リンク・マーカが、マウスがその上にある
旨のメッセージを受け取ると（オペレーティング・シス
テムから）、ＬＭＳは、マウス・ポインタの外観を変え
て、エンド・ユーザにリンク・マーカの存在を表示する
（リンク・マーカは「見えない」ので、すなわち、ユー
ザは、リンク・マーカと対話することができるが、見る
ことはできないので、これは特に有効である）。さらに
、これによって、ＬＭＳは、マウスでリンク・マーカを
「つかまえ」、リンク・マーカの位置変更とサイズ変更
の両方または一方を行い、リンク・マーカに関するコン
テキスト・メニュを表示し（図１０参照）、リンク・マ
ーカの関連したリンクを検分するといった、リンク・マ
ーカに対する他のさまざまなタイプのマウスのアクティ
ビティを取り扱うことが可能になる。

【００８３】また、ＬＭＳは、マウスが、ＬＭＳサービ
スを利用しないウインドウの上にある場合に、マウスを
管理することが可能である。これが生じる状況の１つと
して、エンド・ユーザがリンクを形成するための高速経
路方法である“迅速な”リンクを利用して、リンク・マ
ーカ及びリンクを生成する場合がある。この状況の場合
、マウスがクライアント・アプリケーションの文書の一
部の上にある間に、ユーザは、マウス・ボタン及びキー
ボードのキーをただ単に押し、引き続いて、マウスを別
のポイントまで「引きずり」（同じ文書内、または、別
の文書／プレゼンタ）、マウス・ボタンを開放する（こ
の操作中の任意の時点において、マウスが有効なリンク
終端ポイントではない領域の上にくると、マウス・ポイ
ンタの外観が変化し、このことをエンド・ユーザに表示
する）。この手順によって、２つのポイント間において
、リンク・マーカ及びリンクを全て１ステップで形成す
ることが可能になる。この処理中に唯一必要とされるク
ライアントの関与は、上述のように、ＬＭＳにメッセー
ジを送ることである。

【００８４】ＬＭＳは、オペレーティング・システムの
サービスを利用して、マウスの排他的利用を可能にする
ことによってこの機能性を実現する（すなわち、マウス
がどのウインドウの上にあるかに関係なく、全てのマウ
ス・メッセージを受信する）。マウス・ボタンを開放す
る（操作を完了する）と、ＬＭＳは、もしあれば、マウ
スがどのウインドウの上にあるかを確かめるように、シ
ステムに照会する。次に、そのウインドウに対して、Ｌ
ＭＳサービスを利用するアプリケーションであるか否か
を判定するように、メッセージが送られる。メッセージ
を受けるウインドウがＬＭＳを利用するものであれば、
このメッセージを処理する必要がなく（処理することに
ならず）、このアプリケーションがＬＭＳサービスを利
用すると答えるＬＭＳに該メッセージを送ることになる
。このプロセスの目標ウインドウがＬＭＳサービスを利
用するアプリケーションであれば、リンク・マーカが、
そのアプリケーションのために、マウス・ポインタに位
置へ自動的に生成され、操作の始点に関して、リンクが
形成される。メッセージに対する応答が、このアプリケ
ーションはＬＭＳサービスを利用しないということであ
れば、そのアプリケーションに対してリンクが形成され
るが、それに対してリンク・マーカが設けられることに
はならない（ＬＭＳは、こうしたタイプのアプリケーシ
ョンを「不承知の」アプリケーションと呼ぶ）。

【００８５】エンド・ユーザは、クライアント・アプリ
ケーション・ウインドウ内にリンク・マーカを生成し、
削除し、そのサイズを決め、そのテキストを変更し、そ
の外観スタイルを変更することができる。マーカの生成
及び削除を除くと（上述のように、メッセージを送るこ
とが必要になる）、これは、全て、クライアント・アプ
リケーションを関与させずに実施することができる。Ｌ
ＭＳは、リンク・マーカを「所有」しているので（上述
のように、また、図２１に関連してさらに詳細に後述の
ように）、ＬＭＳは、リンク・マーカ・ウインドウのペ
インティング及び位置決めを制御する。リンク・マーカ
は、その下にあるクライアント・アプリケーション・デ
ータを反転させて、ユーザに対してハイライトがかかっ
たように見せることができるが、反転領域を得るのに、
クライアント・アプリケーションによる処理が要求され
ることはない。

【００８６】次に図２０を参照すると、ＬＭＳのマーカ
生成手順の論理に関する流れ図が示されている。このプ
ロセスは、機能ブロック１３５において生成指令で開始
する。これは、ユーザが、アプリケーションのクライア
ント・ウインドウ内におけるクライアント作業空間上で
、ただし、マーカ上ではないが、クリック音を立てて操
作を行うと表示される、リンク・プル・ダウン・メニュ
からか、あるいは、コンテキスト・メニュからかはとも
かく、いずれにせよ、クーカ生成指令を受信したことを
表わしている。クライアント作業空間でクリック操作す
る場合、そのアクションは、文書に対してクリック操作
するものとみなすことができ、従って、コンテキスト・
メニュは、文書コンテキスト・メニュ、または、その省
略形で呼ばれる。いずれにせよ、図２０の流れ図の場合
、生成指令は、該ソースの１つから入力されたものと仮
定される。

【００８７】最初に行われることは、機能ブロック１３
６におけるＬＭＳによるマウスの捕捉である。それは、
マウス・ポインタの制御が可能になることを表わしたウ
インドウ処理用語である。機能ブロック１３７において
、マウス・ポインタを異なるポイント形状に変化させ、
ＬＭＳがマーカ生成のプロセスを行っていることが示さ
れる。この形状は、ユーザがスクリーン上で移動させ、
どこにマーカを配置させたいのかを示すトラッキング矩
形である。

【００８８】次に、プロセスは、機能ブロック１３８に
おいて、オペレーティング・システムのメッセージを待
つ。これは、新たらしいメッセージ処理ループを挿入し
て、アプリケーションが実行を継続できるようにするこ
とによって行われるが、ＬＭＳは、アプリケーションに
送る前に、全てのメッセージにフィルタリングを施す。 従って、機能ブロック１３８は、メッセージを捜し続け
るメッセージ獲得ループと呼ばれる小ループである。通
常、それを行うのはアプリケーション自体であるが、Ｌ
ＭＳは、この場合、極めて厳重な制御を行う。メッセー
ジが入力される毎に、ＬＭＳは、メッセージを調べ、判
定ブロック１３９において、これが、マウスのこの捕捉
を終了させるメッセージであるか否かを判定する。上記
メッセージでなければ、機能ブロック１４１においてク
ライアント・アプリケーションにメッセージが送られ、
上記メッセージであれば、機能ブロック１４２において
、マウス捕捉が終了する。次に、判定ブロック１４３に
おいてテストを行い、ユーザがマーカ生成プロセスを取
り消したか、あるいは、本当に、その継続を望んだかの
判定が行われる。ユーザが取り消した場合、プロセスは
、機能ブロック１４４において取り消され、一方、ユー
ザが継続を望んだ場合には、機能ブロック１４５におい
て新しい「マーカ」が生成される。（マーカは、コンテ
キスト内のオブジェクトであり、その用語は、オブジェ
クト志向プログラミング言語において用いられる。）次
に、実際のマーカ・オブジェクトが、機能ブロック１４
６においてデータ・ベースから新しい識別文字（ＩＤ）
を取り出し、機能ブロック１４７において、マーカ・ウ
インドウが生成される。このマーカ・ウインドウは、マ
ーカの見える表現であり、ウインドウ・システムにおい
てウインドウが生成される毎に、上述のように、そのウ
インドウと連係するようにウインドウ手順の割当が行わ
れる。マーカ・ウインドウ機能に関するウインドウ手順
は、ＬＭＳ動的リンク・ライブラリに常駐している。こ
うして、クリック音を立ててマーカに操作が加えられる
か、あるいは、入力がマーカに達する毎に、リンク・マ
ネージャ・コードが実行され、従って、クライアント・
アプリケーションの対話が有効に排除される。マーカ・
ウインドウが生成されると、機能ブロック１４８におい
て表示されることになる。

【００８９】次に図２１を参照すると、マーカ・ウイン
ドウの論理が示される。本発明に関連し、リンク・マー
カは、便宜上、アプリケーション・ウインドウ内におけ
るウインドウとみなすことができ、実際に、それはその
通りである。マーカ・ウインドウ手順は、クライアント
・アプリケーションのウインドウ手順または任意のウイ
ンドウ手順と似ており、マーカ・ウインドウ手順のコー
ドは、ＬＭＳに常駐している。機能ブロック１５１にお
いて、ユーザがメッセージを入力し、機能ブロック１５
２においてオペレーティング・システムに通され、機能
ブロック１５３においてマーカ・ウインドウ手順に届く
ことになる。マーカ・ウインドウがメッセージを得ると
、マーカ・ウインドウ手順は、ユーザの指示による実施
しなければならないことをチェックする。例えば、判定
ブロック１５４において、テストを行い、ボタン３を押
すか否かの判定が行われる。マウス・ボタン３を押すと
、機能ブロック１５５においてマーカ・コンテキスト・
メニュが表示されるが、なぜなら、ＬＭＳの望ましい実
施例の場合、それが、ウインドウに関してボタンを押す
ことによって、ユーザがコンテキスト・メニュを提示す
る方法であるからである。コンテキスト・メニュ・プロ
セッサは、判定ブロック１５６に示すように、指令が実
際にコンテキスト・メニュから選択されたものか否かと
いう質問が返される。指令がコンテキスト・メニュ処理
から選択されたものであれば、ＬＭＳは、基本的に、一
般に機能ブロック１５７に示すように、機能ブロック８
８で始まる図１７に示すように、また、図１８に示すよ
うにプル・ダウン・メニュ処理に入る。すなわち、クラ
イアント・アプリケーションが、ＬＭＳによる指令の実
行を阻止することを望んでいるといけないので、ＬＭＳ
は、実際に指令を実行する前に、クライアント・アプリ
ケーションに対して通知メッセージを送ることになる。 ＬＭＳは、また、指令の実行後にも、クライアント・ア
プリケーションにメッセージを送る。ＬＭＳは、内部的
に指令を実行しようとする場合にはいつでも、必ず、最
初にクライアント・アプリケーションに対して特殊なＬ
ＭＳメッセージによる通知を行う。ＬＭＳは、指令を実
行した後はいつでも、必ず、ＬＭＳが指令を実施した旨
のメッセージをクライアント・アプリケーションに通知
する。

【００９０】ユーザ入力が、判定ブロック１５８におけ
る判定で、通常のマウスによるクリック操作にすぎない
場合にはどうなるか？上述の場合には、判定ブロック１
５９においてさらにテストを行い、そのメッセージが、
マウス・ボタン１をクリック音を立てて２度操作するこ
とか否かが判定される。その通りであれば、機能ブロッ
ク１６１において、リンク追従操作が行われる。Ｃ＋＋
「マーカ・オブジェクト」は、それに関連した全てのリ
ンク及びリンクの端に関する全ての情報を承知しており
、この情報は、全て、データ・ベースに納められていて
、ＬＭＳがリンク追従を行えるようになっている。一方
、メッセージが、判定ブロック１６２における判定によ
り、マウス・ボタン２をクリック音を立てて２度操作す
ることであれば、ＬＭＳは、機能ブロック１６３におい
て対話ボックスを表示し、マーカから生じる全てのリン
クをユーザに示す。

【００９１】マウスのクリック操作が、マウスのクリッ
ク操作に関するメッセージのいずれでもない場合、ＬＭ
Ｓは、チェックを行って、判定ブロック１６４及び１６
５に示すように、マウス・ボタンが押し下げられるのと
同時に、制御キーが押されたが否かを確認する。同時に
押されている場合、ＬＭＳは、直接操作作業を行う。直
接操作は、ユーザが制御キーを押し、マウスを用いて、
機能ブロック１６６でマーカを移動させるか、あるいは
、機能ブロック１６７でマーカのサイズを決めることを
表わしている。

【００９２】判定ブロック１５８に戻り、メッセージが
マウスによるクリック操作でなければ、判定ブロック１
６８でテストを行い、それがペインティング・メッセー
ジか否かを確かめる。ペインティング・メッセージであ
れば、マーカは、そのウインドウを閉じ、機能ブロック
１６９で再ペインティングが行われる。

【００９３】次に図２２を参照すると、流れ図でウイン
ドウ・ペインティング処理の論理が示されている。オペ
レーティング・システムは、既述の他のプロセスのよう
に、機能ブロック１７１においてＬＳＭにメッセージを
送る。今度は、マーカがメッセージを得るのに、最初に
クライアント・アプリケーションを経る必要がないので
、メッセージは、直接、マーカ・ウインドウ手順１７２
に入る。判定ブロック１７３において、マーカ・ウイン
ドウは、メッセージがペインティング・メッセージか否
かの判定を行う。ペインティング・メッセージであれば
、すなわち、オペレーティング・システムの命令が、ウ
インドウを描き直す必要があるということであれば、マ
ーカは、判定ブロック１７４において、データ・ベース
を調べることによって、どんなマーカ・スタイルである
か判定する。透明でない（すなわち、見通すことができ
ない）２つのスタイル、すなわち、１つは、ブラック・
アンド・ホワイトと呼ばれる、２次元のスタイル、及び
、もう１つは、プッシュ・ボタンと呼ばれ、押すと、沈
下する動きを示す、３次元の外観を有するスタイルがあ
る。他のスタイルは、いずれも透明であり、例えば、図
２３に示すように、ビデオ反転またはハイライト・フレ
ームとして、スクリーン・プリントで表示される。

【００９４】見通せるタイプのマーカ（すなわち、プッ
シュ・ボタンまたはブラック・アンド・ホワイト）でな
ければ、機能ブロック１７５において、マーカのペイン
ティングが行われる。透明なマーカ・スタイルであれば
、機能ブロック１７６において、マーカが隠される、す
なわち、マーカ・ウインドウ全体が、スクリーンから除
去される。マーカ・ウインドウがスクリーンから除去さ
れると、その下の親ウインドウが、機能ブロック１７７
においてそれ自体の再ペインティングを行うように命じ
られる。この結果、親ウインドウ内における何もかも、
全てのデータが現在のものであり、最新のものであるこ
とが保証される。再ペインティングがすむと、即座に、
機能ブロック１７８において、マーカが再び示されるが
、境界のペインティングまたは反転の実施が所望されな
い限り、親ウインドウの再ペインティングは行われない
。

【００９５】Ｍｉｃｒｏｓｏｆｔ（マイクロソフト社の
商標）ウインドウ及びＯＳ／２　ＰＭの場合、パレット
には、透明性に備えたビットが予約されていないのでユ
ーザが見通すことの可能な、また、いつでも正確に、か
つ、適正に更新されるウインドウを生成することができ
ない。このウインドウ及びＯＳ／２提示マネージャ・ウ
インドウは、不透明である。一般に、アプリケーション
によってウインドウが生成されると、そのウインドウが
スクリーン上に現れる、すなわち、オペレーティング・
システムが、ウインドウにそれ自体のペインティングを
命じ、ウインドウが、それ自体のペインティングを行う
。もちろん、例えば、１つのウインドウをつかまえて、
もう１つのウインドウに重ねることによって、ウインド
ウの上にペインティングを行う場合、どうなるかという
と、オペレーティングは、実際には、ウインドウを引き
込まないで、ウインドウに白の背景、テキスト、その他
何でも充填する。これについては、例えば、多種多様な
ウインドウ、スクロール・バー、アイコン、プッシュ・
ボタン等を示した図２４に例示されている。オペレーテ
ィング・システムは、スクリーン領域を予約することに
よって、ウインドウを生成し、そこで、クリック音を発
してマウス操作が行われると、そのウインドウ手順メッ
セージを送るが、ユーザは、やはり、ウインドウを通し
て、その下のウインドウを見ることができる。従って、
透明なウインドウの実現により表面上における外観は、
実際、それ自体のペインティングを行わないウインドウ
と同じほど単純になる。

【００９６】あいにく、実際には、全くそれほど容易と
いうわけにはいかない。オペレーティング・システムが
、生成されたこの新しいウインドウに、それ自体のペイ
ンティングを行うように命じる毎に、ウインドウが、透
明であろうとしてそれ自体のペインティングを行わない
という可能性がある。ただし、ウインドウは、実際には
透明ではない。スクリーンのその領域におけるビットに
ペインティングが施されないといったことになるだけで
ある。従って、「透明な」ウインドウの上に、別のウイ
ンドウを重ねておいて、それから移動させると、ウイン
ドウは、決して他のウインドウの上にペインティングを
施さないので、「透明な」ウインドウが重ねられたウイ
ンドウは、「透明な」ウインドウが位置する領域を除い
て、それ自体の再ペインティングを行うことになる。 「透明な」ウインドウは、それ自体にペインティングを
しようとはしない。スクリーン上にあるビットは、「透
明な」ウインドウ及びそれが上に重ねられたウインドウ
の、両方の上に重ねられた第３のウインドウからのビッ
トであり、従って、スクリーンに間違って提示されるこ
とになる。

【００９７】図２２に示すウインドウ・ペインティング
手順には、この問題に対する解決法が含まれている。す
なわち、透明なウインドウの上にもう１つの第３のウイ
ンドウを重ねて、それから移動させると、オペレーティ
ング・システムは、透明なウインドウにペインティング
・メッセージを送る。全く完全にペインティングを行わ
ないというより、ウインドウが行うのは、スクリーンの
この部分におけるビットが第３のウインドウからのもの
であることを認識することであり、その第３のウインド
ウは、移動ずみであるので（ペインティング・メッセー
ジの受信によって示されるように）、透明なウインドウ
は、その下にあるものを見せなければならない。これは
、図２２の機能ブロック１７６において、透明なウイン
ドウがそれ自体を隠すことによって行われる。オペレー
ティング・システムには、それを行う機能がある。次に
、親ウインドウは、透明なウインドウが親ウインドウに
すぐにそれに従って行動するように命じる、オペレーテ
ィング・システムからのペインティング・メッセージを
得る。この時点で、親ウインドウは、機能ブロック１７
７においてそれ自体のペインティングを行うことになる
。ウインドウは、別の見えるウインドウの上にペインテ
ィングを施すことはないが、他のスクリーン領域におい
てウインドウが見えなければ（すなわち、隠されていれ
ば）、そのスクリーン領域においてペインティングを行
う。従って、手順は、ウインドウを隠して、透明なウイ
ンドウがあったこの特定の領域にそれ自体のペインティ
ングを行うように、親ウインドウに命じることになる。 こうして、スクリーンは、完全に再生され、最新の、現
行のものとなる。

【００９８】次に、もう１度透明な窓を示さなければな
らない。透明なウインドウが再び表示されると、オペレ
ーティング・システムは、これを認識し、ウインドウに
それ自体のペインティングを行うように命じられるが、
透明なウインドウは、それ自体のペインティングを行わ
ないので、エンド・ユーザは、透明なウインドウを通し
て、その下のデータを見ることができる。これは、全て
、瞬時に行われ、ＯＳ／２のＰＭに透明なウインドウを
有効に生じることになる。透明なウインドウは、やはり
、所望の場合、透明なウインドウによって占められたス
クリーンの矩形領域にあるビットを反転し、図２３に示
すように、反転ビデオによるハイライトを生じさせたり
、あるいは、ウインドウの境界にワイヤ・フレームを描
くといった何らかのペインティングを施すことができる
。スクリーン１４（図１）における反転ビデオによるハ
イライトを施したテキストを示すスクリーン・プリント
である図２３の場合、それは、実際にはハイライトを施
したテキストではなく、実際は、そこに透明なウインド
ウがある。

【００９９】メニュ以外に、エンド・ユーザとアプリケ
ーションとの間における対話のもう１つの方法は、対話
ボックスの利用である。対話ボックスは、エンド・ユー
ザから特定のタスクに必要な情報を収集する。ＬＭＳは
、クライアント・アプリケーションが完全なハイパーメ
ディア支援を行うのに必要な全ての対話ボックスを生成
し、管理する。図２４、２５、及び２６は、ＬＭＳによ
って得られる対話ボックスのいくつかに関する例を示し
ている。すなわち、図２４には、エンド・ユーザに対し
、リンク・マーカのスタイルを指定するように指示メッ
セージを与えるのに用いられる対話ボックスの例が示さ
れている。図２５には、エンド・ユーザに対し、管理の
ため、すなわち、リンク・マーカのアブストラクトを表
示するため、リンクを選択するとか、リンクに従うとか
いった指示メッセージを与えるために用いられる対話ボ
ックスの例が示されている。図２６には、エンド・ユー
ザに対して、ハイパーメディア・データ・ベースの探索
のためキーワードを入力するように指示メッセージを与
える対話ボックスの例が示されている。

【０１００】クライアント・アプリケーションは、対話
ボックスを表示または管理するためにＬＭＳサービスを
呼び出す必要はなく、ＬＭＳが、自動的にこの支援を提
供する。この結果、ＬＭＳサービスを用いる全てのアプ
リケーションが、クライアント・アプリケーション間に
おいて整合のとれた１組のハイパーメディア対話ボック
スを確実に生成できるようになっている。

【０１０１】ＬＭＳには、全ての対話ボックスの定義が
含まれている（すなわち、外観／挙動）。エンド・ユー
ザがハイパーメディア・サービスを要求すると（一般に
、メニュを用いて）、ＬＭＳは、要求の実行を開始する
。この実行中、対話ボックスの表示が必要であると判定
されると（例えば、より多くの情報が必要になる）、Ｌ
ＭＳがその表示を行う。ハイパーメディア対話ボックス
の全てが、ＬＭＳオブジェクト（例えば、リンク、リン
ク・マーカ等）に関連している場合、ＬＭＳは、クライ
アント・アプリケーションと協働せずに、エンド・ユー
ザの要求をオブジェクトに加えることができる。

【０１０２】図２８は、対話ボックスの管理の論理に関
する流れ図である。マーカの生成、リンクの生成、事項
の修正といった、ＬＭＳ指令プロセッサ１８１が実行す
る各指令毎に、判定ブロック１８２においてテストを行
い、対話ボックスが必要か否かが判定される。答が、は
いであれば、ＬＭＳは、機能ブロック１８３において対
話ボックスを表示する。これらの対話ボックスには、メ
ニュとちょうど同じようなＬＭＳ資源が納められるが、
クライアント・アプリケーションは納められない。ユー
ザ・インターフェイス全体には、ＬＭＳが納められるが
、これは、それがモジューラであり、従って、ＬＭＳの
新しいバージョンが導入した場合、新しいユーザ・イン
ターフェイスは、エンド・ユーザにとって、クライアン
ト・アプリケーション・コードに書き直しのない、クラ
イアント・アプリケーションの一部のように思える。

【０１０３】いずれにせよ、対話ボックスは、ＬＭＳが
どんなオブジェクトに対して作業をしているか、すなわ
ち、マーカか、文書か、あるいは、リンク等であるかに
従って表示される。判定ブロック１８４における判定に
より、対話ボックスは、ユーザとそれとの対話に基づい
てオブジェクトに修正を加える場合、アプリケーション
に対してＬＭＳが何かを変更しようとしていることを伝
えるメッセージが、機能ブロック１８５においてアプリ
ケーションに送られ、その時点で、メッセージ・ブロッ
ク１８６において、アプリケーションは、続行してもい
いか否かの返答をする。アプリケーションが続行しても
いいと言えば、ＬＭＳは、機能ブロック１８７で指令を
処理し、前述のように、機能ブロック１８８においてア
プリケーションに通知する。

【０１０４】判定ブロック１８４に戻り、対話ボックス
が、オブジェクトに修正を加えようとしていなければ、
ＬＭＳは、わざわざアプリケーションにこれを行うべき
か否かを尋ねなくてもすむ。代わりに、ＬＭＳは、機能
ブロック１８９において指令の処理を行う。

【０１０５】最後に、対話ボックスが判定ブロック１８
２におけるテストに基づく判定により用いられなければ
、判定ブロック１９１においてさらにテストを行い、直
接操作が必要か否かが判定される。直接操作では、やは
り、マウスでマーカをつかまえるが、メニュ項目の選択
は行わない、すなわち、ただキーボード及びマウスを利
用して、事項の選択を行い、それらをつかまえて、かな
りの操作を加え、リンクの生成等を行うだけであって、
メニュは含まれない。ある種の直接操作が必要になる場
合、機能ブロック１９２において、ＬＭＳがアプリケー
ションにメッセージを送る。例えば、直接操作が、マー
カを、ちなみに、これは、ユーザがプル・ダウン・メニ
ュから選択できる項目であるが、移動させることであれ
ば、ＬＭＳは、ユーザがプル・ダウン・メニュからその
機能を選択した場合とちょうど同じように、マーカを移
動させようとしている旨のメッセージをアプリケーショ
ンに送り、クライアント・アプリケーションが、ユーザ
がこれらのアクティビティを実施するために利用してい
る方法に感応する必要がないようにする。前述のように
、ＬＭＳは、アプリケーションが、続行すべきか否かの
返答をするのを待つ。アプリケーションが、続行しても
いいという返答をする場合、ＬＭＳは、機能ブロック１
８７において指令の処理を行い、次に、いつものように
、その処理をすましたのち、機能ブロック１８８におい
てアプリケーションに通知する。

【０１０６】ＬＭＳによって供給されるＥＵＩの他の領
域にはあてはまるように、クライアント・アプリケーシ
ョンは、ハイパーメディアの支援を要求されることはな
いが、ＬＭＳによって与えられる対話ボックスの表示を
修正し、強化し、あるいは、阻止することができる。さ
らに、クライアント・アプリケーションが、ＬＭＳが必
要と認めた場合だけでなく、選択時に、ＬＭＳ対話ボッ
クスを表示することができるサービスが得られる。

【０１０７】文書間のリンクの支援に必要な全ての情報
が、ＬＭＳによって、ウェブとして知られる独立したデ
ータ・ベースに維持される（図６参照）。クライアント
・アプリケーションがＬＭＳサービスを利用するために
、該アプリケーションのデータを含むファイルに修正を
加える必要はなく、むしろ、全てのハイパーメディア・
オブジェクトに関する概念的に並列な「ビュー」または
「オーバレイ」が、ウェブ・データ・ベースに記憶され
ている。クライアント・アプリケーションは、このデー
タ・ベースのフォーマットにも、あるいは、データ・ベ
ースに対するアクセスにも関与する必要はなく、これら
の問題は、ＬＭＳによって完全に取り扱われる。このデ
ータ・ベースは、更新を含む共用データ・ベースのアク
セスを可能にする、単一ユーザのワークステーション環
境または複数ワークステーション／ユーザ／プロセス（
例えば、ネットワーク）環境に利用することができる。 クライアント・アプリケーションの終了後も、ＬＭＳハ
イパーメディア・オブジェクトは、いぜんとして持続し
（データ・ベース内に）、クライアント・アプリケーシ
ョンをもう１度利用して、文書を表現する際、再利用す
ることが可能になる。クライアント・アプリケーション
からかなりの作業をオフ・ロードするこの設計について
は、後述する。

【０１０８】ハイパー・メディア・オブジェクトは、文
書、プレゼンタ、リンク・マーカ、及び、リンクである
。ＬＭＳは、全ての新しい修正されたハイパーメディア
・オブジェクトをデータ・ベースに保管し、そうするよ
うに要求された場合（エンド・ユーザまたはクライアン
ト・アプリケーションによって）だけでなく、クライア
ント・アプリケーションが閉じる場合にも（エンド・ユ
ーザまたはクライアント・アプリケーションいよって、
そうしないように要求されない限り）、データ・ベース
から削除を要求された全てのハイパーメディア・オブジ
ェクトを除去する。

【０１０９】クライアント・アプリケーションがそのデ
ータを表現している時、オブジェクトの生成は、次の２
つの方法のいずれかまたは両方によって明示することが
できる。

【０１１０】データ・ベースに既存のハイパーメディア
・オブジェクト：　　クライアント・アプリケーション
がそれ自体及びその文書をＬＭＳにたいして識別すると
、ＬＭＳは、データ・ベースからの関連するハイパーメ
ディア・オブジェクト・データを自動的にロードし、ク
ライアント・アプリケーションによって現在表示中の文
書の一部に適してリンク・マーカを表示する。

【０１１１】ハイパーメディア・オブジェクトがデータ
・ベースに存在しない：クライアント・アプリケーショ
ンが初めてＬＭＳに認知される毎に（すなわち、クライ
アント・アプリケーションが、ＬＭＳ　　ＡＰＩを介し
て、ＬＭＳに“チェック・イン”すると）、クライアン
ト・アプリケーションに関するＬＭＳデータ（例えば、
その名前）を含むプレゼンタ・オブジェクトが、ＬＭＳ
によって自動的に生成される。文書オブジェクトについ
ても、同じことがいえる。エンド・ユーザ（ＬＭＳ　　
ＥＵＩを利用）とクライアント・アプリケーション（Ｌ
ＭＳ　　ＡＰＩを利用）の両方またはいずれかによって
そうするように要求される毎に、ＬＭＳは、リンク・マ
ーカ及びリンク・オブジェクトを生成する。後者（ＬＭ
Ｓ　　ＡＰＩ）の場合の例として、発見的またはその他
の人工知能クライアント・アプリケーション、あるいは
、ユーティリティ・プログラムにとって既知の、または
、ユーティリティ・プログラムが発見することの可能な
、機械が読み取れる情報、フォーマット、内容、及び、
意味論的連関の既存の（おそらく、大規模な）集大成に
関して、文書、リンク・マーカ、及び、リンク・オブジ
ェクトを動的に（すなわち、エンド・ユーザと対話せず
に）生成し、ハイパーメディア連関の極めて有効で、お
そらく正統的でない、ウェブ・データ・ベースが得られ
るようにする（例えば、機械保守情報、エンサイクロペ
ディア、医療情報、職員の技能情報、構造化学習及びほ
ぼ　ｐｅｒｉｐａｔｅｔｉｃ　発見の両方または一方を
可能にする教育課程、販売／カタログ情報、辞書等）た
めに書かれたユーティリティ・プログラムが考えられる
。

【０１１２】図２９及び図３０は、ＬＭＳデータ・ベー
スの維持に関する流れ図である。図３０に示す手順は、
図２９の手順から呼び出される。データ・ベースの維持
手順は、ハイパーメディア・システムのユーザが、文書
、リンク・マーカ、または、リンクの生成、変更、また
は、削除を行う毎に呼び出される。図２９及び図３０に
おいて、データ・ベース・オブジェクトに関して用いら
れる場合のロック及びアンロックに言及するのは、それ
以外に対する可用性の範囲を説明するためである。ロッ
クは、排他的利用が行えるようにすることであり、アン
ロックは、排他的利用の解除を意味しており、従って、
それ以外のものにも利用可能になる。従って、あるプロ
セスがＬＭＳ文書データ・ベースのオブジェクトの１つ
をロックすると、そのオブジェクトがアンロックされる
まで、その他のプロセスは、データ・ベースのそのオブ
ジェクトにアクセスすることができない。プロセスがＬ
ＭＳデータ・ベース（全体）をロックすると、データ・
ベースがアンロックされるまで、他のプロセスが、引き
続き、データ・ベースのオブジェクトにアクセスするこ
とはできない。

【０１１３】まず図２９を参照すると、ＬＭＳデータ・
ベース更新手順は、判定ブロック２０１においてテスト
を行い、更新の対象となる文書がデータ・ベース内に存
在するか否かを判定することによって開始する。存在す
る場合には、機能ブロック２０２において、文書がデー
タ・ベースでロックされることになり、存在しなければ
、データ・ベースは機能ブロック２０３においてロック
されるが、いずれにせよ、判定ブロック２０４において
、さらにテストを行い、文書を削除すべきか否かが判定
される。削除すべきであれば、プロセスは、第１のルー
プに入り、その文書に属するリンク・マーカを識別して
、取り除く。判定ブロック２０５でループが開始し、テ
ストを行って、これが、この文書に属する第１のリンク
・マーカであるか、あるいは、別のリンク・マーカであ
るかが判定される。第１のリンク・マーカであれば、リ
ンク・マーカに、機能ブロック２０６で削除するように
フラグが立てられ、手順２０７で、リンク・マーカ及び
そのリンクがデータ・ベースから除去される。これは、
図３０に関連してさらに詳細に後述するリンク・マーカ
及びリンク・データ・ベース更新手順を呼び出すことに
よって行われる。この手順から戻ると、プロセスは、ル
ープをたどって判定ブロック２０５に戻る。

【０１１４】判定ブロック２０５のテストで、リンク・
マーカが存在しない、あるいは、全てのリンク・マーカ
にフラグが立てられているということになると、機能ブ
ロック２０８において、データ・ベースから文書が削除
される。次に、判定ブロック２０９においてテストを行
い、データ・ベースに既存の文書があるか否かが判定さ
れる。存在すれば、手順が終了する前に、機能ブロック
２１０で、データ・ベースにおける文書のロックが破壊
され、存在しなければ、手順が終了する前に、機能ブロ
ック２１１において、データ・ベースがまずアンロック
される。

【０１１５】判定ブロック２０４に戻り、文書を削除す
べきでないと仮定すると、第２のループに入って、文書
に属するリンク・マーカを識別し、さらに、必要な更新
を実施する。このループは、判定ブロック２１２で開始
され、テストを行って、これが第１のリンク・マーカか
、あるいは、この文書に属する別のリンク・マーカかが
判定される。第１のリンク・マーカであれば、判定ブロ
ック２１３において、さらにテストを行い、そのリンク
・マーカが、新しい、変更された、あるいは、削除され
たものか否かが判定される。そうであれば、手順２１４
を呼び出して、データ・ベース内におけるリンク・マー
カ及びリンクの更新が行われる。手順２１４は、手順２
０７と同じであり、図３０、３１に関連して、さらに詳
細に後述する。手順２１４から戻ると、あるいは、リン
ク・マーカが、判定ブロック２１３において、新しい、
変更された、あるいは、削除されたものでなければ、プ
ロセスは、ループを判定ブロック２１２まで戻る。

【０１１６】全てのリンク・マーカが識別され、更新さ
れている場合、ループは判定ブロック２１５まで続き、
テストを行って、文書が新しいか、または、変更された
ものであるか否かが判定される。そうであれば、機能ブ
ロック２１６において、文書オブジェクト・データがデ
ータ・ベースに書き込まれる。いずれにせよ、次に、判
定ブロック２１７においてテストが行われ、その文書が
データ・ベースにおいて既存のものか否かが判定される
。既存のものであれば、手順が終了する前に、機能ブロ
ック２１８において、文書がデータ・ベースでアンロッ
クされ、既存のものでなければ、手順が終了する前に、
機能ブロック２１１において、データ・ベースがアンロ
ックされる。

【０１１７】次に、図３０及び図３１を参照するが、図
２９の手順２０７または２１４において、リンク・マー
カ及びリンク・データ・ベース更新手順が呼び出される
と、まず判定ブロック２２１においてテストを行い、リ
ンク・マーカがデータ・ベース内にあるか否かの判定か
行われる。存在すれば、機能ブロック２２２において、
リンク・マーカがデータ・ベースでロックされ、存在し
なければ、機能ブロック２２３においてデータ・ベース
がロックされる。いずれにせよ、次に、判定ブロック２
２４において、テストが行われ、リンク・マーカを削除
すべきか否かが判定される。削除すべきであれば、手順
は第１のループに入り、リンク・マーカに付加されたリ
ンクを識別して、リンクを削除する。ループは、判定ブ
ロック２２５で開始し、テストを行って、これが第１の
リンクか、あるいは、リンク・マーカに付加された別の
リンクが存在するかが判定される。その通りであれば、
機能ブロック２２６において、リンクのもう一方の端に
リンク・マーカが、データ・ベースでロックされる。次
に、もう一方の端のリンク・マーカが、機能ブロック２
２７において、データ・ベースから読み取られ、リンク
がそれから分離され、もう一方の端のリンク・マーカが
、機能ブロック２２７においてデータ・ベースに書き直
される。リンクのもう一方の端のリンク・マーカが、機
能ブロック２２８において、データ・ベースでアンロッ
クされ、次に、プロセスがループを判定ブロック２２５
に戻る前に、機能ブロック２２９において、リンクがデ
ータ・ベースから削除される。

【０１１８】全てのリンクが識別されると、ループは機
能ブロック２３０に出て、リンク・マーカがデータ・ベ
ースから削除される。次に、判定ブロック２３１におい
て、テストを行い、データ・ベースに既存のリンク・マ
ーカがあるか否かが判定される。存在すれば、プロセス
の終了前に、機能ブロック２３２において、リンク・マ
ーカが破壊され、存在しなければ、プロセスの終了前に
、まず、機能ブロック２３３において、データ・ベース
がアンロックされる。

【０１１９】判定ブロック２２４に戻り、リンク・マー
カを削除すべきでなければ、プロセスは、第２のループ
に入り、リンク・マーカに付加されたリンクを識別して
、必要な更新を実施する。このループは、判定ブロック
２３４で開始し、テストを行って、これが第１のリンク
であるか、あるいは、リンク・マーカに付加されたもう
１つのリンクが存在するかが判定される。その通りであ
れば、判定ブロック２３５において、さらにテストを行
い、リンクが、新しい、変更された、あるいは、削除さ
れたものかどうかが判定される。そうであれば、判定ブ
ロック２３６において、テストを行い、リンクを削除す
べきか否かが判定される。削除すべきであれば、機能ブ
ロック２３７において、リンクのもう一方の端のリンク
・マーカが、データ・ベースでロックされる。次に、機
能ブロック２３８において、もう一方の端のリンク・マ
ーカがデータ・ベースから読み取られ、リンクがそれか
ら分離され、もう一方の端のリンク・マーカが、データ
・ベースで書き直される。機能ブロック２３９において
、リンクのもう一方の端のリンク・マーカがデータ・ベ
ースでアンロックされ、手順がループを判定ブロック２
４０に戻る前に、機能ブロック２４０において、リンク
がデータ・ベースから削除される。リンクを削除すべき
でなく、そのリンクが新しいか、変更されたものであれ
ば、プロセスがループを判定ブロック２３４に戻る前に
、機能ブロック２４１において、リンク・オブジェクト
・データがデータ・ベースに書き込まれる。

【０１２０】全てのリンクが識別され、更新されると、
ループは、判定ブロック２４２まで続けられ、テストを
行って、リンク・マーカが新しいもの、または、変更さ
れたものであるか否かが判定される。その通りであれば
、リンク・マーカ・オブジェクト・データは、機能ブロ
ック２４３においてデータ・ベースに書き込まれる。 いずれにせよ、判定ブロック２４４において、さらにテ
ストを行い、データ・ベースに既存のリンク・マーカが
あるか否かが判定される。存在する場合、手順の処理前
に、機能ブロック２４５において、リンク・マーカがデ
ータ・ベースでアンロックされ、存在しなければ、手順
の処理前に、機能ブロック２３３において、データ・ベ
ースがアンロックされる。

【０１２１】ＬＭＳは、クライアント・アプリケーショ
ンから作業をオフ・ロードするためのメカニズムを提供
するが、クライアント・アプリケーションを制限するの
は望ましくない。作業をオフ・ロードすると、場合によ
っては、クライアント・アプリケーションの機能性が実
際に制限されることもあり得る。そのため、ＬＭＳは、
指令に操作を加える前に、必ず、通知メッセージを送る
ことになる。

【０１２２】クライアント・アプリケーションには、と
りわけ、マーカやリンクといったいくつかのＬＭＳオブ
ジェクトに関して、それ自体が望む情報を記憶する方法
が与えられる。例えば、テキスト・エディタ・アプリケ
ーションが、リンク・マネージャによってそれ自体使用
可能となり、マーカがそのファイル中のどの行番号に連
関しているかを知りたいという場合、ＬＭＳは、クライ
アント・アプリケーションのデータを理解していないの
で、従って、どの行かが分からない。この問題を解決す
るため、各ＬＭＳオブジェクト、とりわけ、マーカ及び
リンクには、ユーザ・データと呼ばれる領域が設けられ
、このデータ領域へのアクセスのため、ＡＰＩが設けら
れる。基本的には、これは、ＬＭＳがそこに収容されて
いるデータについて理解していない領域である。それは
、アプリケーションがデータを記憶することができる領
域である。ＬＭＳは、生２進データであるため、そのデ
ータを調べないが、アプリケーションは、その領域に望
みのものを何でも記憶することができる。例えば、アプ
リケーションが、あるマーカが行５に位置していること
を知っている場合、アプリケーションは、ユーザ・デー
タに、このマーカが行５に位置していることを表わす何
らかの構造、所望であれば、単なる１つの整数をセット
することができる。従って、ＬＭＳは、その特定のマー
カ・オブジェクトに関するデータをウェブ・データ・ベ
ース内に離して記憶するだけである。これにより、次に
、エディタが、文書を示し、ＬＭＳに、全てのマーカ及
びリンクをロード・アップするように命じる時には、Ｌ
ＭＳは、ＬＭＳによって得られる機能を利用してマーカ
を列挙しながら、各マーカに操作を施すことになるが、
その列挙の際、ＬＭＳは、各マーカ毎に、このマーカに
関連したユーザ・データの識別を行う。とりあげた例の
場合、それは、アプリケーションが記憶したのと同じユ
ーザ・データであり、ＬＳＭは、アプリケーションが記
憶していたデータを提供するだけである。ＬＭＳは、そ
のデータの内容を知らないが、アプリケーションは、こ
のマーカが行５に位置することを表わしたものであると
認識する。その時点で、アプリケーションは、ＡＰＩを
介して、マーカの位置変更を行うこともできるし、ある
いは、アプリケーションがそれに関して所望するいかな
ることでも行えるようになる。

【０１２３】同じことが、リンクにもあてはまる。リン
クは、マーカ・ユーザ・データとちょうど同じ働きをす
るユーザ・データである。リンク・データ・ユーザの使
用例として、リンクが形成される毎に、アプリケーショ
ンが、リンク生成時に、どんな状態であったか、例えば
、アプリケーションは、タイトル・バーを備えることが
できたか否かといった、固有の情報を記録しておきたい
という場合がある。アプリケーションがしようとするこ
とは、リンク・ユーザ・データの記憶である（すなわち
、リンクの完成時、タイトル・バーがなかったという事
実）。タイトル・バーがあれば、アプリケーションが、
そのリンクを記憶する場合もある。そのリンクに追従し
て、アプリケーションが、結果として、その文書をロー
ドするということになれば、アプリケーションは、この
リンクでユーザ・データのチェックを行う。ユーザ・デ
ータが、アプリケーションに対し、このリンクの生成時
に、アプリケーションにはタイトル・バーがなかったこ
とを知らせると、アプリケーションは、そのタイトル・
バーを隠すが、別のリンクが見つかったとき、アプリケ
ーションが、ここでのユーザ・データからアプリケーシ
ョンにタイトル・バーがあったということを知ると、タ
イトル・バーを表示する。

【０１２４】ＬＭＳは、ユーザ・データを理解せず、ア
プリケーションが各リンク及び各マーカ毎に記録するこ
とができる、小形のノート・パッドのようなものである
。さらに、ＬＭＳは、アプリケーションが、特定マーカ
または特定のリンクを迅速に分類し、ファイルするため
の手段である、リンクとマーカの両方を備えた、ユーザ
・キーと呼ばれるものである。それは、キーであり、従
って、アプリケーションが常に特定のマーカ項目の１つ
にアクセスすることを望んでいるが、多くのマーカ、お
そらく数千のマーカが、１つの文書に連関している場合
、アプリケーションは、マーカに対して、長い特定な値
である特定のユーザ・キーを割り当てる。ほとんどのＬ
ＭＳ機能は、ユーザ・キーをパラメータとしてとらえて
おり、従って、ユーザが、第１のマーカを検索したいと
いう場合、ＬＭＳは、マーカ・セット全体の中から見つ
け出される第１のマーカに戻ることになるだけである。 しかし、ユーザが、ユーザ・キー１０で第１のマーカを
検索したいという場合、ＬＭＳは、全てのマーカを探索
して、どのマーカがユーザ・キー１０を有しているか確
かめることになる。

【０１２５】ＬＭＳは、エンド・ユーザ（ＬＭＳ　　Ｅ
ＵＩを利用）だけでなく、クライアント・アプリケーシ
ョン（ＬＭＳ　　ＡＰＩを利用）によるハイパーメディ
ア・オブジェクトの削除も可能にする。リンク・マーカ
からリンクが削除されると、ＬＭＳは、もう一方の端が
付加されたリンク・マーカから、自動的にそのもう一方
の端を除去する。リンク・マーカが文書から削除される
と、ＬＭＳは、それに付加された全てのリンクを自動的
に削除する。文書が削除されると、ＬＭＳは、自動的に
その文書に関する全てのリンク・マーカを削除する。

【０１２６】文書、リンク・マーカ、及び、リンクの属
性は、エンド・ユーザ（ＬＭＳ　　ＥＵＩを利用）とク
ライアント・アプリケーション（ＬＭＳ　　ＡＰＩを利
用）の両方または一方によって修正することができる。 例えば、リンク。マーカのスタイル、サイズ、位置は、
これらの機能を用いて、変更することができる。

【０１２７】リンク・マーカ、リンク、文書、及び、プ
レゼンタに関する全ての情報が、ＬＭＳの管理するデー
タ・ベースに記録されているので、エンド・ユーザがリ
ンクに追従しようとすると、ＬＭＳは、どのプレゼンタ
がどの文書に着手すべきかを判定することができる。リ
ンク・マーカは、クライアント・アプリケーションとの
対話を行わずに、それ自体のメッセージを得て、処理を
行うので（上述の「マウス処理」参照）、ＬＭＳは、デ
ータ・ベースに照会して、リンクがどこに位置するかを
確かめることができ（例えば、プレゼンタＰは、必要が
あれば、文書Ｄをリンク・マーカＭに対して位置決めす
ることになる）、ＬＭＳは、アプリケーションに着手す
る（アプリケーションを開始する）能力があるので、Ｌ
ＭＳによって、エンド・ユーザは、いずれにせよ、クラ
イアント・アプリケーションの関与を必要とせずに、リ
ンクに追従することが可能になる。

【０１２８】ＬＭＳは、ハイパーメディアの支援を行う
のに必要なほぼ全ての作業をオフ・ロードするために、
どんなことでもする（従って、クライアント・アプリケ
ーションのコード化の努力及び開始時間を減少させる）
としても、クライアント・アプリケーションが、ハイパ
ーメディア・システムの挙動及びデータ修正に対して制
御を加えることができないようにするのは望ましくない
。ＬＭＳは、メッセージ及びアプリケーション・プログ
ラミング・インターフェイス（ＡＰＩ）を介してこの制
御能力が得られるようにする。

【０１２９】前述のように、リンク・マーカのＬＭＳプ
ッシュ・ボタン・スタイルには、２つのサブ・スタイル
が備わっている。１つは、外観が「３次元」であって「
押す」と、視覚的に沈下し、もう１つは、「ブラック・
アンド・ホワイト」として知られ、外観が２次元である
。これらは、両方とも、オプションで、１つ以上のリン
ク・マーカのリンクについてナビゲーション（トラバー
ス）を行う場合に得られる情報を簡単に説明したテキス
トを含めることも可能である。従って、リンク・マーカ
のテキストは、存在する場合、リンク・マーカのリンク
のもう一方の端に位置する情報のミニ・アブストラクト
とみなすことが可能であり、後述のように、探索論理と
して前述のように扱われることになる。

【０１３０】リンク・マーカに含まれるテキストに加え
、ＬＭＳは、リンク・マーカが所有するリンク・マーカ
のアブストラクト・オブジェクトを実現する。リンク・
アブストラクト・データは、所有するリンク・マーカの
位置に見出すことのできる情報に関した要約テキスト情
報と定義することができる。従って、ＬＭＳが目標リン
ク・マーカ候補をユーザに提示すると、（ユーザがリン
ク・マーカに対して「クリック操作」して、２つ以上の
リンクが生じる結果、または、リンク・マーカのアブス
トラクトを探索する結果として）各目標リンク・マーカ
候補は、（１）目標の短いアブストラクト・テキストの
形で、ただし存在しなければ、（２）目標の親文書名の
形で、ただし存在しなければ、（３）目標のプレゼンタ
名の形で、リスト内に提示されることになる。従って、
リンク・マーカについて少なくとも短いアブストラクト
・データを有していることは、ナビゲーション目標候補
のリストを表示する場合に、エンド・ユーザに有意味の
弁別を行うのにも、また、探索に用いるにも有効である
。存在するとして、リンク・マーカのアブストラクト・
オブジェクトは、２つまでのテキスト部分、その一方ま
たは両方が存在し得る短いアブストラクト・テキスト及
び長いアブストラクト・テキストから構成される。

【０１３１】リンク・マーカのアブストラクトの短いテ
キスト・データは、１行に表示するのに適した短い記述
テキストにすることを意図したものである。リンク・マ
ーカのアブストラクトの長いテキスト・データは、所有
するリンク・マーカ位置に見出すことが可能な情報に関
するより多量の情報を提供することが望ましい場合に、
用いることを意図したものである。このテキストは、文
字の数万倍のすることができ、ある種の国語の文字セッ
トに対しては、それ以上とすることもできる。長いアブ
ストラクト・テキストは、要求に応じてエンド・ユーザ
に提示されるだけであるが、アブストラクト探索時に必
ず調べられる。探索を見越して、別様であればテキスト
内にはないキー・ワードを指定することが望ましい場合
、ガイド・ラインは、おそらく、まず記述テキストの読
み取りに関心のあるエンド・ユーザに対する優遇措置と
して、長いアブストラクトの終わりにそれらを配置する
ことである。

【０１３２】探索は、ＬＭＳ　　ＥＵＩまたはＬＭＳ　
　ＡＰＩによって開始させることができる。ＬＭＳ　　
ＥＵＩによって開始する場合、結果（目標リンク・マー
カ候補を表わすリスト）が、表示されるので、エンド・
ユーザはその検査を行うことが可能であり、そうするこ
とが所望の場合には、リストに形で表した情報を表示す
るように、選択的に要求することができる。ＬＭＳ　　
ＡＰＩによって開始する場合、目標リンク・マーカ候補
のリストは、呼び出し手に利用可能になる。いずれにせ
よ、探索制限パラメータ及び探索論理は、同じである（
ＬＭＳ　　ＥＵＩは、内部的にＬＭＳ　　ＡＰＩを利用
する）。ハイパーメディアＬＭＳデータ・ベース内のデ
ータだけが、探索される。エンドユーザまたはクライア
ント・アプリケーションが、追加／修正／削除されたリ
ンク・マーカ・テキストまたはリンク・マーカ・アブス
トラクトを有しているが、そうした変化が、データ・ベ
ースにおいて（まだ）反映されていない場合、探索結果
においてその変化が反映されることはない。

【０１３３】次の４つの判定基準の組合わせを指定する
ことによって、探索を制限／認定することができる。

【０１３４】（１）テキスト・ストリング探索パラメー
タは、探索機能が、データ・ベースで見つけようとする
データである。

【０１３５】（２）大文字／小文字不感度探索パラメー
タは、唯一の相違が大文字／小文字の一方である場合、
探索機能が比較されるストリングを整合のとれるものと
みなすか否かを示す。例えば、“ｃａｒｅ　ｆｏｒ　ｔ
ｈｅ　ｙｏｕｎｇ”が　“Ｃａｒｅ　Ｆｏｒ　Ｔｈｅ　
Ｙｏｕｎｇ”と整合するとみなすか否かは、このパラメ
ータによって決まる。

【０１３６】（３）ワード・アライメント探索パラメー
タは、データ・ベースのデータが、それぞれ、テキスト
・ワードの始めまたは終わり以外で開始または終了する
場合、探索機能が、別様に一致するストリングを整合す
るとみなすか否かを示す。例えば、“ａｒｅ　ｆｏｒ　
ｙｏｕ”の探索パラメータが、“ｐｒｅｐａｒｅ　ｆｏ
ｒ　ｙｏｕｔｈｆｕｌｌ”の一致するデータ・ベースの
データとみなすことになるか否かは、このパラメータに
よって決まる。

【０１３７】（４）文書識別子探索パラメータは、探索
機能が、データ・ベースの広範な探索に対して、特定の
文書の探索に限定するか否かを示す。

【０１３８】図３２には、ＬＭＳが作成する対話ボック
スが示されている。これは、リンク・マーカに関するア
ブストラクトを構成する要約テキスト・データをＬＭＳ
ハイパーメディア・データ・ベースに入力するためのユ
ーザ・インターフェイスである。図２６には、ＬＭＳハ
イパーメディア・ベース・ベースの探索に関する探索判
定規準を入力するように、ユーザに指示メッセージを与
えるのに用いられるＬＭＳアブストラクト探索要求対話
ボックスの例が示されている。探索テキストの入力以外
に、ユーザに対し、探索パラメータの任意選択を促す指
示メッセージも与えられる。図３３には、ＬＭＳアブス
トラクト探索結果対話ボックスの例が示されている。こ
の対話ボックスは、探索判定基準の見つかったＬＭＳハ
イパーメディア・データ・ベースからの一致のリストを
ユーザに提供する。ユーザは、この対話ボックスにおい
て、任意に対話ボックスに表示された項目の１つを選択
し、とりわけ、その項目に関するリンク・マーカ・アブ
ストラクトを表示し、そのリンクに追従し、指示に従っ
てその他諸々を行う。

【０１３９】ハイパーメディアＬＭＳデータ・ベースを
探索する方法に関する論理が、図３４及び図３５に示さ
れており、次に、この図を参照する。プロセスは、判定
ブロック２５１で開始され、テストを行って、文書識別
子探索パラメータが空白か否かが判定される。空白であ
れば、ＬＭＳを呼び出して、機能ブロック２５２で、デ
ータ・ベースがロックされ、機能ブロック２５３におい
て、ＬＭＳは、探索リストに用いられる全ての文書識別
文字のリストをデータ・ベースに構築する。一方、探索
パラメータが空白でなければ、前述のように、機能ブロ
ック２５４において、文書がデータ・ベースでロックさ
れるが、機能ブロック２５５において、ＬＭＳは、文書
識別子だけから成る探索リストを構築する。

【０１４０】機能ブロック２５３または機能ブロック２
５５において、ＬＭＳによって探索リストが構築される
と、プロセスは、機能ブロック２５６に移行し、候補リ
ストを空にセットすることによって、探索の初期設定が
行われる。次に、判定ブロック２５７においてテストを
行い、これが、リスト内における第１の文書か、あるい
は、後続のパスにおいて、リスト内に別の文書が存在す
るかの判定が行われる。とりあえず、これが第１の文書
であるか、または、リスト内に他の文書があるものと仮
定すると、機能ブロック２５８において、ＬＭＳが呼び
出され、現在の文書識別に関する全てのリンク・マーカ
識別文字のリストを構築する。次に、判定ブロック２５
９において、テストを行い、これが第１のリンク・マー
カ識別文字が、あるいは、リスト内に別のリンク・マー
カ識別文字が存在するかが判定される。上記の通りでな
ければ、プロセスは、ループを判定ブロック２５７まで
戻り、リスト内における次の文書に関するリンク・マー
カ識別文字のリストを構築することになるが、上記の通
りであれば、機能ブロック２６０において、ＬＭＳを呼
び出し、データ・ベースからリンク・マーカのデータを
入手する。判定ブロック２６１において、さらにテスト
を行い、現在のリンク・マーカが１つ以上のリンクを有
しているか否かが判定される。有していなければ、プロ
セスは、ループを判定ブロック２５９まで戻り、データ
・ベースから次のリンク・マーカのデータが検索される
ことになるが、有している場合には、判定ブロック２６
２において、さらにテストを行い、リンク・マーカのテ
キストが探索パラメータと一致するか否かが判定される
。一致すれば、判定ブロック２６３においてテストを行
い、これが最初のリンクか、あるいは、リンク・マーカ
に関する別のリンクが存在するかが判定される。上記の
通りであれば、判定ブロック２６４においてテストを行
い、リンクのもう一方の端のリンク・マーカ識別文字が
候補リストに含まれているか否かが判定される。含まれ
ていれば、プロセスは、ループを判定ブロック２６３ま
で戻り、含まれていなければ、プロセスがループを判定
ブロック２６３まで戻る前に、判定ブロック２６５にお
いて、リンクのもう一方の端のリンク・マーカ識別文字
が、候補リストに追加される。

【０１４１】判定ブロック２６３のテストで、これが第
１のリンクか、あるいは、リンク・マーカに関する別の
リンクが存在するかの判定が行われない場合、プロセス
は、判定ブロック２６６に進み、テストを行って、リン
ク・マーカがアブストラクトを有しているか否かを判定
し、有していれば、アブストラクト内に、探索パラメー
タが見出されるか否かを判定する。エンド・ユーザが、
リンク・マーカの生成時に、任意にアブストラクトの入
力を行うことを想起されたい。リンク・マーカに関する
アブストラクトに探索パラメータが見つかると、判定ブ
ロック２６７において、さらにテストを行い、リンク・
マーカの識別文字が候補リストに含まれているか否かが
判定される。含まれていなければ、プロセスは、ループ
を判定ブロック２５９まで戻り、含まれていなければ、
プロセスがループを判定ブロック２５９まで戻る前に、
リンク・マーカの識別文字が、機能ブロック２６８にお
いて候補リストに追加される。もちろん、リンク・マー
カがアブストラクトを備えていなければ、プロセスは、
ループを直接判定ブロック２６６から判定ブロック２５
９に戻る。

【０１４２】判定ブロック２５９において、リスト内に
、他にリンク・マーカ識別文字が存在しないと判定され
ると、プロセスは、ループを判定ブロック２５７まで戻
り、これで探索リスト内における全ての文書及びリンク
・マーカの検査がすんだと仮定すると、判定ブロック２
６９においてさらにテストを行い、探索パラメータが空
白か否かが判定され、空白であれば、機能ブロック２７
０において、データ・ベースがアンロックされ、機能ブ
ロック２７１において、候補リストが戻される。探索パ
ラメータが空白でなければ、機能ブロック２７２におい
て、文書がデータ・ベースでアンロックされ、機能ブロ
ック２７１において、候補リストが戻される。

【０１４３】図３４及び図３５の流れ図に示す探索論理
は、下記擬似コードによって実現し、前記擬似コードか
ら、適合する任意のコンピュータ言語で原始コードを書
くことができる。コンピュータ言語は、オブジェクト志
向言語であることが望ましく、本発明の実施例の１つで
は、Ｃ＋＋コンピュータ言語が用いられた。擬似コード
において、論理記述に用語比較が用いられる場合、アラ
イメント及び文字に対する不感度に関する上述のパラメ
ータ規則の認識を含めて考えなければならない。

【０１４４】探索論理 −Ｉｆ文書が別子探索パラメータが空白である−ｔｈｅ
ｎＬＭＳサービスを呼び出して、データ・ベースをロッ
クする（他のプロセスによるデータ・ベースの修正を阻
止する）、 −ｅｌｓｅＬＭＳサービスを呼び出して、データ・ベー
スにおいて、文書識別子探索パラメータが指定する文書
をロックする（他のプロセスによるデータ・ベース内の
文書に対する修正を阻止する）。 ・ＥＮＤＩＦ −探索すべき文書に関する文書識別子のリストを構築す
る．．． −Ｉｆ文書識別子探索パラメータが空白である−ｔｈｅ
ｎＬＭＳサービスを呼び出して、データ・ベースにおけ
る全ての文書識別子のリストを構築する、−ｅｌｓｅ探
索すべき文書のリストに文書識別子探索パラメータだけ
を納める。 ＥＮＤＩＦ −目標リンク・マーカ識別子候補のリストを構築する．
．． −候補リストを空になるようにセットする−リスト内の
各文書識別子毎に．．． −ＬＭＳサービスを呼び出して、現在の文書識別子に関
する全てのリンク・マーカ識別子のリストを構築する。 −リスト内における各リンク・マーカ識別子毎に．．．
−ＬＭＳサービスを呼び出して、データ・ベースからリ
ンク・マーカ・データを検索する。 −Ｉｆリンク・マーカは、それから生じる１つ以上のリ
ンクを備えているｔｈｅｎ．．． −Ｉｆリンク・マーカは、テキストを含んでおり、テキ
ストが探索パラメータ・テキストに等しいとみなされる
ｔｈｅｎ．．． −現在のリンク・マーカから生じる各リンク毎に．．．
−Ｉｆリンクのもう一方の端にリンク・マーカ識別子が
候補リストに含まれていないｔｈｅｎ −もう１つの端のリンク・マーカ識別子を候補リストに
追加する。 ＥＮＤＩＦ ＥＮＤＦＯＲＬＯＯＰ ＥＮＤＩＦ −Ｉｆリンク・マーカにアブストラクトが含まれており
、探索パラメータ・テキストが短いまたは長いアブスト
ラクト・テキストに等しいものとみなされ、　　　　リ
ンク・マーカ識別子が、候補リストに含まれていない、
ｔｈｅｎ −リンク・マーカ識別子を候補リストを追加するＥＮＤ
ＩＦ ＥＮＤＩＦ ＥＮＤＦＯＲＬＯＯＰ ＥＮＤＦＯＲＬＯＯＰ ＥＮＤＢＵＩＬＤ（次に、リンク・マーカ識別子候補の
認定リストが構築される。） −Ｉｆ文書識別子探索パラメータが空白である−ｔｈｅ
ｎＬＭＳサービスを呼び出して、データ・ベースをアン
ロックする（他のプロセスによるデータ・ベースの修正
を可能にする）、 −ｅｌｓｅＬＭＳサービスを呼び出し、データ・ベース
において文書識別子探索パラメータによって指定された
文書をアンロックする（他のプロセスによるデータ・ベ
ースの文書に対する修正を可能にする）。 ＥＮＤＦＩＦ ＥＮＤ　ａｗ　ＳＥＡＲＣＨ　　ＬＯＧＩＣ

【０１４５
】エラー等についてチェックするといったことに関する
取るに足りない、明白な論理は、明らかなだけでなく、
読者に対して探索論理の本質を不必要に分かりにくくす
ることにもなるので、故意に省かれている。

【０１４６】ＬＭＳは、全てのクライアント・アプリケ
ーション間に、ハイパーメディア・メニュ、対話ボック
ス、マウス処理、及び、リンク・マーカ表示管理に関す
る整合のとれたエンド・ユーザ・インターフェイスを提
供する。これらの機能は、これらの概念を明らかにする
だけでなく、コードを実行して、エンド・ユーザの要求
を意味論的に満たすことにもなる。ＬＭＳ、アプリケー
ション、及び、ＥＵＩの機能的関係については、図３６
に概念が示されている。ユーザは、ブロック２８４に示
すように、さまざまな方法で指令、すなわち、メッセー
ジを入力することができる。これらには、マウス、キー
ボード、または、ＬＭＳメニュが含まれている。まず第
１に、アプリケーション・ウインドウ２８５を介して、
アプリケーション・プログラムにメッセージが入力され
る。これらのメッセージは、アプリケーション２８６の
メッセージ処理コードに送られ、アプリケーションがそ
のメッセージに処理を加えないという選択を行うと、さ
らに、ＬＭＳ２８７のメッセージ処理コードに送られる
。一例として、プル・ダウンとコンテキストの両方のメ
ニュの生成がある。一方、メッセージが、ＬＭＳメッセ
ージであれば、メッセージは、直接ＬＭＳ２８７に送ら
れる。一例として、リンク・マーカの選択された場合が
ある。

【０１４７】リンク・マーカのアブストラクトは、それ
ぞれのリンク・マーカを所有している。リンク・マーカ
のアブストラクトの生成または修正は、完全にＬＭＳに
よって管理される。生成及び修正は、ＬＭＳ　　ＥＵＩ
とＬＭＳ　　ＡＰＩの両方または一方によって行うこと
ができる。リンク・マーカのアブストラクトのリンク・
マーカが納められている。文書に関するデータの残りの
部分が保管されている。リンク・マーカのアブストラク
トは、それを所有しているリンク・マーカがデータ・ベ
ースから削除される毎に、ＬＭＳハイパーメディア・デ
ータ・ベースから自動的に削除される。

【０１４８】

【発明の効果】本発明によれば、アプリケーション（プ
レゼンタ）が、開放形システム・アーキテクチャ（ＬＭ
Ｓによって定義される）に対してハイパーテキスト／ハ
イパーメディア能力と整合のとれる、サービスを受ける
オブジェクトに関する作成及び探索機能をシームレスに
、かつ、容易に組み込むことができ、同時に、プレゼン
タ自体ではなく、基本的サービスによって完全に管理さ
れる、整合性のあるハイパーメディア・リンク・マーカ
のアブストラクト作成及び探索ＥＵＩを自動的にユーザ
に与える、１組のシステム・リンク・マーカのアブスト
ラクト・サービスが得られる。

【図面の簡単な説明】

【図１】パーソナル・コンピュータの絵画的表現による
図である。

【図２】図１に示すパーソナル・コンピュータのシステ
ム・ブロック図である。

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

【図４】オブジェクト（単方向生）・リンクに対するマ
ーカを示すブロック図である。

【図５】マーカ（両方構成）・リンクに対するマーカを
示すブロック図である。

【図６】開放形システムにおけるリンク・マネージャ・
サービスの機能関係を示すブロック図である。

【図７】クライアント・アプリケーション・ウインドウ
手順の論理を示す流れ図である。

【図８】ナビゲーション以前の文書及びマーカを示すス
クリーンの図である。

【図９】ナビゲーション後の新しい文書及びマーカを示
すスクリーンの図である。

【図１０】文書上においてマウスをクリック操作した場
合のコンテキスト・メニュを示すスクリーンの図である
。

【図１１】リンク・マーカ上においてマウスをクリック
操作した場合のコンテキスト・メニュを示すスクリーン
の図である。

【図１２】指令バーにおけるＬＩＮＫ上でマウスをクリ
ック操作した場合のプル・ダウン・メニュを示すスクリ
ーンの図である。

【図１３】図１２の第１のプル・ダウン・メニュにおけ
るＭＡＮＡＧＥ　　ＭＡＲＫＥＲＳ上でマウスをクリッ
ク操作した場合の第２のプル・ダウン・メニュを示すス
クリーンの図である。

【図１４】図１３の第２のプル・ダウン・メニュにおけ
るＣＲＥＡＴＥ　　ＭＡＲＫＥＲ上でマウスをクリック
操作した場合の第３のプル・ダウン・メニュを示すスク
リーンの図である。

【図１５】図１２のプル・ダウン・ウインドウにおける
ＭＡＮＡＧＥ　　ＬＩＮＫＳ上でマウスをクリック操作
した場合の第２のプル・ダウン・ウインドウを示すスク
リーンの図である。

【図１６】図１５の第２のプル・ダウン・ウインドウに
おけるＣＲＥＡＴＥ　　ＬＩＮＫ上でマウスをクリック
操作した場合の第３のプル・ダウン・ウインドウを示す
スクリーンの図である。

【図１７】ＬＭＳによって実施されるプル・ダウン・メ
ニュ処理の論理を示す流れ図である。

【図１８】ＬＭＳによって実施されるコンテキスト・メ
ニュ処理の論理を示す流れ図である。

【図１９】ＬＭＳによって実施される非メニュ指令メッ
セージの論理を示す流れ図である。

【図２０】ＬＭＳによって実施されるマーカ生成手順の
論理を示す流れ図である。

【図２１】ＬＭＳによって実施されるマーカ・ウインド
ウ手順の論理を示す流れ図である。

【図２２】透明または見えないウインドウを支援するウ
インドウ・ペインティング手順の論理を示すウインドウ
の論理を示す流れ図である。

【図２３】反転ビデオによるハイライト処理で、見えな
いマーカ（すなわち、ウインドウ）の位置を示すスクリ
ーン・プリントの図である。

【図２４】スクリーン上にウインドウのペインティング
が施されると、通常従うことになる手順を表わした複数
の重なったウインドウを示すスクリーンの図である。

【図２５】リンク・マーカ・スタイルを選択するＬＭＳ
対話ボックスの例を示すスクリーンの図である。

【図２６】リンクを管理するＬＭＳ対話ボックスのもう
１つの例を示すスクリーンの図である。

【図２７】ＬＭＳハイパーメディア・データ・ベースの
探索を開始させるＬＭＳ対話ボックスの第３の例を示す
スクリーンの図である。

【図２８】ＬＭＳによって実施される対話ボックス管理
手順の論理を示す流れ図である。

【図２９】ＬＭＳデータ・ベース更新手順の論理を示す
流れ図である。

【図３０】図２９に示す手順から呼び出されたリンク・
マーカ及びリンク・データ・ベース更新手順の論理を示
す流れ図である。

【図３１】図２９に示す手順から呼び出されたリンク・
マーカ及びリンク・データ・ベース更新手順の論理を示
す流れ図である。

【図３２】ＬＭＳアブストラクト作成対話ボックスの例
を示す図である。

【図３３】ＬＭＳアブストラクト探索結果の対話ボック
スの例を示す図である。

【図３４】本発明による探索論理を示す流れ図である。

【図３５】本発明による探索論理を示す流れ図である。

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

【符号の説明】

１０．　　パーソナル・コンピュータ １１．　　システム・ユニット １２．　　キー・ボード １３．　　マウス １４．　　ディスプレイ装置 １５．　　カーソル １６．　　スクリーン ２１．　　システム・バス ２２．　　マイクロプロセッサ ２３．　　ＲＯＭ ２４．　　ＲＡＭ ２５．　　メモリ管理チップ

Claims (14)

【特許請求の範囲】
1. 【請求項１】個々のアプリケーションに関するデータを
   ディスプレイ装置のスクリーン上におけるアプリケーシ
   ョン・ウインドウに表示することが可能になっており、
   前記ウインドウのそれぞれには、前記データが表示され
   る主アプリケーション作業空間が設けられていて、開放
   形ハイパーメディア・システムによって得られるハイパ
   ーメディア・サービスを活用するアプリケーションに対
   して、均一で、整合性のあるグラフィカル・ユーザ・イ
   ンターフェイスを供給する開放形ハイパーメディア・シ
   ステムにおいて、アプリケーション・ウインドウ内に、
   １つ以上のリンク・マーカとオブジェクトの両方または
   一方に連係した第１のリンク・マーカを生成するため、
   ユーザに情報を入力するように指示メッセージを与える
   ステップと、リンク・マーカの位置で見出すことが可能
   な情報に関して、ユーザに要約テキストの形をとるリン
   ク・マーカのアブストラクトを入力するオプションを与
   えるステップと、前記リンク・マーカ及びリンク・マー
   カのアブストラクトに関するデータ・ベースを維持する
   ステップから構成される、前記ハイパーメディア・シス
   テムで実施される方法。
2. 【請求項２】前記リンク・マーカには、リンク・マーカ
   のリンクのもう一方の端に位置するテキストの表示情報
   が含まれることを特徴とする、請求項１に記載のハイパ
   ーメディア・システムで実施される方法。
3. 【請求項３】前記ディスプレイ装置に対話ボックスを表
   示し、探索すべきデータを入力できるようにするステッ
   プと、ユーザによるデータ入力に応答し、前記データ・
   ベースのリンク・マーカ及びアブストラクトを探索する
   ステップと、前記入力データに一致するデータの前記デ
   ータ・ベース内におけるリンク・マーカを表わしたリス
   トを表示するステップが、さらに含まれることを特徴と
   する、請求項２に記載のハイパーメディア・システムで
   実施される方法。
4. 【請求項４】前記データが、キー・ワード、句、または
   、文といったテキストであることを特徴とする、請求項
   ３に記載のハイパーメディア・システムで実施される方
   法。
5. 【請求項５】前記リスト内のある位置を選択するユーザ
   入力を受け入れるステップと、前記データへのナビゲー
   ションを行うステップが、さらに含まれることを特徴と
   する、請求項３に記載のハイパーメディア・システムで
   実施される方法。
6. 【請求項６】前記データが第２のアプリケーションのデ
   ータである場合、前記第２のアプリケーションのアプリ
   ケーション・ウインドウ内に前記データを表示するステ
   ップが、さらに含まれることを特徴とする、請求項５に
   記載のハイパーメディア・システムで実施される方法。
7. 【請求項７】前記第２のアプリケーションが、現在実行
   されていない場合、さらに、前記第２のアプリケーショ
   ンに着手するステップと、前記スクリーン上において前
   記第２のアプリケーションに関するアプリケーション・
   ウインドウを開くステップが、含まれることを特徴とす
   る、請求項６に記載のハイパーメディア・システムで実
   施される方法。
8. 【請求項８】個々のアプリケーションに関するデータを
   ディスプレイ装置のスクリーン上におけるアプリケーシ
   ョン・ウインドウに表示することが可能になっており、
   前記ウインドウのそれぞれには、前記データが表示され
   る主アプリケーション作業空間が設けられていて、開放
   形ハイパーメディア・システムによって得られるハイパ
   ーメディア・サービスを活用するアプリケーションに対
   して均いで、整合生のあるグラフィカル・ユーザ・イン
   ターフェイスを供給する開放形ハイパーメディア・シス
   テムにおいて、アプリケーション・ウインドウ内に、１
   つ以上のリンク・マーカとオブジェクトの両方または一
   方に連係した第１のリンク・マーカを生成するため、ユ
   ーザに情報を入力するように指示メッセージを与える手
   段と、リンク・マーカの位置で見出すことが可能な情報
   に関して、ユーザに要約テキストの形をとるリンク・マ
   ーカのアブストラクトを入力するオプションを与える手
   段と、前記リンク・マーカ及びリンク・マーカのアブス
   トラクトに関するデータ・ベースを維持する手段から構
   成される、ハイパーメディア・システム。
9. 【請求項９】前記リンク・マーカに、リンク・マーカの
   リンクの端に位置するテキストの表示情報が含まれるこ
   とを特徴とする、請求項８に記載のハイパーメディア・
   システム。
10. 【請求項１０】さらに、前記ディスプレイ装置に対話ボ
    ックスを表示し、探索すべきデータをユーザが入力でき
    るようにする手段と、ユーザによるデータ入力に応答し
    、前記データ・ベースのリンク・マーカ及びアブストラ
    クトを探索する手段と、前記入力データに一致するデー
    タの前記データ・ベース内におけるリンク・マーカを表
    わしたリストを前記スクリーンに表示する手段が、含ま
    れることを特徴とする、請求項９に記載のハイパーメデ
    ィア・システム。
11. 【請求項１１】前記データが、キー・ワード、句、また
    は文といったテキストであることを特徴とする、請求項
    １０に記載のハイパーメディア・システム。
12. 【請求項１２】前記リスト内のある位置を選択するユー
    ザ入力を受け入れる手段と、前記データへのナビゲーシ
    ョンを行う手段が、さらに含まれることを特徴とする、
    請求項１０に記載のハイパーメディア・システム。
13. 【請求項１３】前記データが第２のアプリケーションの
    データである場合、前記第２のアプリケーションのアプ
    リケーション・ウインドウ内に前記データを表示する手
    段が、さらに含まれることを特徴とする、請求項１２に
    記載のハイパーメディア・システム。
14. 【請求項１４】前記第２のアプリケーションが、現在実
    行されていない場合、前記第２のアプリケーションに着
    手する手段と、前記スクリーン上において前記第２のア
    プリケーションに関するアプリケーション・ウインドウ
    を開く手段が、さらに含まれていることを特徴とする、
    請求項１３に記載のハイパーメディア・システム。