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

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

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

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

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

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

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

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

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

【００１１】ハイパーテキスト／ハイパーメディア：
一般的な、最も単純な意味において、これらの用語は、
触れて、得ることを表している。これらは、エンド・ユ
ーザが、オブジェクト（例えば、語、句、グラフィカル
・オブジェクト等）に触れることによって（例えば、あ
る種の指示装置を用いて）、１つ以上の関連した情報エ
ンティティが得られるようにすることができるという概
念を具現化したものてある。ハイパーテキスト・システ
ムの概略については、１９８７年９月のIEEE Computer
１７〜４１頁に掲載のJeff Conklin による“Hypertex
t: An Introduction Survey”及び１９８９年１１月の
McGraw-Hill 社刊 Concept & Issues における“An Ove
rview of Hypertext and Hypermedia”に記載されてい
る。

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

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

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

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

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

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

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

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

【００２０】ハイパーテキスト／ハイパーメディア・シ
ステムのいくつかは、スモールトーク及びＣ⁺⁺といった
オブジェクト志向プログラミング言語によってプログラ
ムされる。前者は、Xerox Palo Alto Reseach Center
(PARC) で開発されたものであり、該言語に関する行き
届いた説明は、１９８３年 Addision-Wesley社刊の Ade
le Goldberg 及び David Robson による Smalltalk-80:
The language and ItsImplementation と題する、テキ
スト・ブックを参照することによって得られる。Ｃ⁺⁺言
語は、AT&T Bell Laboratories の Bjarne Stroustrup
によって開発されたものであり、例えば、１９８６年 A
ddison-Wesley社刊の The Ｃ⁺⁺ Programming Language
と題する彼の著書に記載されている。オブジェクト志
向プログラミング・システム（ＯＯＰＳ）の利点の中に
は、アイコンを用いたモジューラ構造及びオブジェクト
志向ユーザ・インターフェイスがある。オブジェクト志
向プログラミング及びハイパーシステムに関するそれ以
上の情報に付いては、１９８８年５月１４日の Knowled
ge Systems, Inc. の Robert Akscyn による、Conferen
ce on Human Factors in Computing Systems における
“Design and Use ofHypermedia System”から得ること
ができるし、また、１９８６年９月のＯＯＰＳＬＡ Pr
oceedings におれけるＩＲＩＳ、Brown University の
Norman Meyrowitzによる“Intermedia: The Architectu
re and Construction of An Object Oriented Hypermed
ia System and Application Framework”から得ること
もできる。

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

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

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

【００２４】Silicon Beach Software によるスーパカ
ード・プログラムは、ハイパーカードと「うり二つ」で
あるが、ハイパーカードに比べてより強力である。ハイ
パーカード・プログラムは、「カード」スタックだけで
なく、アプリケーションの生成も可能にする。閉鎖形ハ
イパーメディア・システムの他の例には、他の（非ガイ
ドによって与えられる）アプリケーション（プレゼン
タ）を使用可能にする機能にハイパーメディア能力を付
与するものではないＯＷＬ International, Inc.による
ガイド２.０、やはり、他の（非インターメディアで与
えられる）アプリケーション（プレゼンタ）を使用可能
にする機能にハイパーメディア能力を付与するものでは
ない、Brown University の Institute for Research i
n Information and Scholarship（ＩＲＩＳ）によるＩ
ＲＩＳインダーメディア、及び、他の（非リンクウエイ
によって与えられる）アプリケーション（プレゼンタ）
を使用可能にする機能にハイパーメディア能力を付与す
るものではない ＩＢＭ Educational System によるリ
ンクウエイ２.０がある。

【００２５】Sun Microsystems よるサン・リンク・サ
ービスは、本発明者が利用し得る製品と認める唯一の他
の開放形ハイパーメディア・システムである。サン・リ
ンク・サービスの機能は、他の（非サン・リンク・サー
ビスによって与えられる）アプリケーションを使用可能
にすることができる１組のサービスにハイパーメディア
能力を付与するものではないが、この使用可能化は、シ
ームレスでもなければ、容易でもない。さらに、サン・
リンク・サービスは、ハイパーメディア能力に関するエ
ンド・ユーザ・インターフェイスを取り扱うものでな
く、従って、各アプリケーションがそれに関してそれ自
体の概念を具現化しなければならないということにな
る。この製品に関するこれ以上の情報については、Hype
rtext '89 Proceedings の１３７〜１４６頁に記載の A
my Pearl による“Sun's Link Service: A Protocol fo
r Open Linking”と題する論文によって得ることができ
る。

【００２６】上記以外に、ハイパーテキスト／ハイパー
メディア能力を具現化した他のいくつかの製品について
は、１９９０年１０月に発行の PC/Computing Magazine
２０１〜２１０頁に論評があった。これらには、Folio
Corp. によるフォリオ・ビュー２.０、Cognetics Cor
p. によるハイパータイ、 Ntergaid によるハイパーラ
イタ、 Spinnaker Software Corp. によるスピンネーカ
・プラス２.０、及び、 Max Think によるトランステキ
ストが含まれている。フォリオ・ビューは、「大テキス
ト・ファイルをカスタム化「情報ベース」に圧縮させ、
相互参照リンクを生成させる情報管理システム」とみな
された。この製品について、これ以上知られていない
が、この論評の示唆するところによれば、これは、異な
るプレゼンタと異なるタイプのデータの両方または一方
の間におけるリンクを可能にするものではない。また、
この示唆するところによれば、他の（非フォリオ・ビュ
ーで与えられる）アプリケーション（プレゼンタ）を使
用可能にする方法で、ハイパーメディア能力が付与され
るものはない。

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

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

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

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

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

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

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

【００３４】

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

【００３５】

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

【００３６】

【実施例】本発明は、いくつかの異なるオペレーティン
グ・システム（ＯＳ）において、さまざまなコンピュー
タで実行することができる。コンピュータは、例えば、
パーソナル・コンピュータ、ミニ・コンピュータ、また
は、メイン・フレーム・コンピュータとすることができ
る。コンピュータは、独立型システム、ローカル・エリ
ア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネ
ットワーク（ＷＡＮ）といったネットワークの一部、あ
るいは、さらに大規模なテレプロセシング・システムで
もかまわない。単に例示目的のため、コンピュータの特
定の選択を制限するのは、メモリ及びディスクの記憶要
件だけであるが、以下の説明おいては、本発明は、ＩＢ
ＭのＰＳ／２シリーズといったパーソナル・コンピュー
タで実施されるものとする。ＩＢＭのＰＳ／２シリーズ
のコンピュータに関するこれ以上の情報については、Ｉ
ＢＭ社、部品番号68X2224、注文番号S68X-2224の Techn
ical Reference Manual Personal System/2 (Model 50.
60 System)、及び、ＩＢＭ社、部品番号68X2256、注文
番号S68X-2256の Technical Reference Manual, Person
al System/2 (Model 80) 参照のこと。

【００３７】本発明の望ましい実施例が実施されたオペ
レーティング・システムは、プレゼンテーション・マネ
ージャ（ＰＭ）を備えたＩＢＭのＯＳ／２であるが、も
ちろん、本発明は、他のさまざまなオペレーティング・
システムで実施可能であり、さらに重要なことには、オ
ペレーティング・システムに統合する、従って、その一
部をなすようにすることが可能である。ＩＢＭのＯＳ／
２オペレーティング・システムに関するこれ以上の情報
については、ＩＢＭ社のＩＢＭ Operating System/2, V
ersion 1.2, Standard Edition Technical Reference
参照のこと。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００５８】基本的なハードウェア及びシステムについ
て説明してきたが、次に、ＬＭＳの働きについて例示す
ることにする。図８には、ビット・マップ表示グラムに
よって得られるコンピュータ表示スクリーンが示されて
いる。このプログラムは、ＧＬＯＢＥ．ＢＭＰ文書（ビ
ット・マップ・グラフィック）を提供するプレセンタ
（すなわち、アプリケーション）である。ＧＬＯＢＥ．
ＢＭＰ文書には、関連情報の存在を示すリンク・マーカ
（そのテキストの表示は、“More info->")が含まれて
いる。マウスでクリックされると、リンク・マ-カに関連したリンクがナヒ゛ケ゛-シ
ョンを受け、ユ-サ゛には、WORLD.TXT文書(図9参照)を与える Fi
le Browser プレゼンタが提示される。ＷＯＲＬＤ．Ｔ
ＸＴ文書には、追従すると、ＧＬＯＢＥ．ＢＭＰ文書ま
でトラバースすることになるリンク・マーカ（そのテキ
ストの表示は、“See a picture->")も含まれている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１３５】（２）大文字／小文字不感度探索パラメー
タは、唯一の相違が大文字／小文字の一方である場合、
探索機能が比較されるストリングを整合のとれるものと
みなすか否かを示す。例えば、“care for the young”
が “Care For The Young”と整合するとみなすか否か
は、このパラメータによって決まる。

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

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

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

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

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

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

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

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

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

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

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

【０１４７】

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

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【符号の説明】

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジヨン・アンソニー・ステフアンズ アメリカ合衆国メリーランド州ボイズ、ト ツプリツジ・ドライブ20501番地 (56)参考文献 特表 平３−504546（ＪＰ，Ａ) ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＯＦ ＴＨＥ ＡＣＭ，ＶＯＬ．31，ＮＯ．７ （1988−７）Ｐ．836−852

Claims (12)

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