JPH10247943A - リンク情報管理システム - Google Patents

Abstract

(57)【要約】 【課題】 意味のあるリンク情報の固まりをリンク情報
名毎に管理してユーザの負担をなくしたシステムを得
る。 【解決手段】 ネットワーク上のオブジェクトの所在を
管理し、リンク情報名をキーとしてリンク情報名に対応
する一連のオブジェクト間の繋がりをリンク元とリンク
先で一意に定めたリンク情報テーブルと、クライアント
からのリンク情報名対応の要求に基づいて、一連のオブ
ジェクト間の繋がり情報を検索、登録、削除管理するリ
ンク情報管理部を備えたリンク情報サーバと、ユーザか
らプログラムを指定されると、リンク情報テーブルから
プログラムに対応するリンク情報名のキー対応の一連の
繋がり情報を得て必要なオブジェクトをダウンロードす
るオブジェクト・ダウンロード部を備えたクライアント
とで構成される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明はネットワーク環境
において散在するデータの一部であるオブジェクトの管
理システムに関り、リンク情報を通じて、オブジェクト
間の参照経路の制御及び参照経路そのものの継承による
新たな参照経路の作成と管理を行うシステムに関するも
のである。

【０００２】

【従来の技術】従来の例として特許平０８−８７４６３
号公報に示されるものがある。図２１はこの従来の例を
示すシステムブロック図であり、分散リソースサーバ装
置（装置Ａ）、分散リソースクライアント装置（装置
Ｂ）、リソースサーバ関係情報サーバ装置（装置Ｃ）及
び、通信網から構成される。

【０００３】上記装置Ａはリソース（オブジェクト）の
編集を行うリソース編集部、リソースの蓄積／管理を行
うリソース蓄積部、装置Ｂと通信を行うプロトコル機能
を有するリソースサーバ部、通信網を利用して装置Ｂと
情報を授受するネットワーク・インタフェース部から構
成される。上記装置Ａはリソース（オブジェクト）の編
集を行うリソース編集部、リソースの蓄積／管理を行う
リソース蓄積部、装置Ｂと通信を行うプロトコル機能を
有するリソースサーバ部、通信網を利用して装置Ｂと情
報を授受するネットワーク・インタフェース部から構成
される。

【０００４】上記装置Ｂはキーボードやマウスからの入
力を制御する入力部、ディスプレイ等への出力を制御す
る出力部、装置Ａや装置Ｃと通信するプロトコル機能を
有するリソースクライアント部、リンク情報及びリソー
ス情報を一時記憶するリンク情報一時記憶部／リソース
情報一時記憶部から構成される一時記憶部、通信網を介
して装置Ａや装置Ｃと情報を授受するネットワーク・イ
ンタフェース部、および、これらを制御する制御部から
構成される。

【０００５】上記装置Ｃは分散リソースの一覧テーブル
であるリソーステーブルを蓄積するリソーステーブル蓄
積部（図２２）、リソース間のリンク関係の情報である
リンク関係テーブルを蓄積するリンク関係テーブル（図
２３）、上記２テーブルを編集する編集部、通信網を介
して装置Ｂと情報を授受するネットワーク・インタフェ
ース部、装置Ｂつ通信する機能を有するリソース関係情
報サーバ部、およびこれらを制御する制御部から構成さ
れる。

【０００６】なお、装置Ａ、装置Ｂ、装置Ｃはそれぞれ
を一意に識別するマシンアドレスを各ネットワーク・イ
ンタフェース部に有している。この装置によるシステム
において、ユーザがオブジェクトをたどって所望のデー
タ出力を得る動作を考えてみる。従来のリンク情報のテ
ーブル構造では図２２のリソーステーブル蓄積部、図２
３のリンク関係テーブルの構造により２つのオブジェク
ト間のリンク情報が保持できるだけであり、複数のオブ
ジェクトの連続したリンク情報を一意に管理することは
不可能であった。例を挙げて説明する。図２４にあるよ
うに、「横浜食べ歩き」「横浜観光案内」の２種類の観
光案内が存在したとする。各案内は複数のオブジェクト
が連続してリンクすることにより構成されている。「横
浜食べ歩き」を構成するオブジェクトは「食べ歩きオー
プニング画面」（ワープロ文書）→「横浜の地図」（静
止画ファイル）→「中華街店名リスト」（表計算ファイ
ル）とする。「横浜観光案内」を構成するオブジェクト
は「観光案内オープニング画面」（ワープロ文書）→
「横浜の地図」（静止画ファイル）→「横浜観光スポッ
トリスト」（表計算ファイル）とする。ここで「横浜の
地図」（静止画ファイル）は２つの観光案内で共通して
利用するものとする。

【０００７】この２つの観光案内のリンク情報を従来の
リンク関係テーブルであらわすと図２５の様になる。こ
の場合、「横浜の地図」（静止画ファイル）のリンク先
となるオブジェクトは「中華街店名リスト」（表計算フ
ァイル）と「横浜観光スポットリスト」（表計算ファイ
ル）の２つとなる。つまり、ユーザがどちらの観光案内
を利用しても「横浜の地図」（静止画ファイル）の先に
進もうとすると「中華街店名リスト」（表計算ファイ
ル）と「横浜観光スポットリスト」（表計算ファイル）
のどちらかを選ばなければならない。ユーザがリンク先
を選択する場合、「観光案内オープニング画面」（ワー
プロ文書）→「横浜の地図」（静止画ファイル）とリン
クを辿ってきたとしても、次に辿るべきオブジェクトが
「中華街店名リスト」（表計算ファイル）となる可能性
があり、ユーザにはどれが正しいリンクなのか判らない
場合がある。このように、従来のリンク関係テーブルの
構造であると意味の有る一つながりのオブジェクトの固
まりを情報として保持できないため、一つのオブジェク
トから複数のオブジェクトがリンクされていた場合、ど
ちらのオブジェクトを選択するかはユーザが判断する必
要がある。

【０００８】

【発明が解決しようとする課題】従来の分散リソースリ
ンク・システムは上述のように構成されており、リンク
関係テーブルでは２つのオブジェクト間は別として３つ
以上または分岐のある複数のオブジェクトの連続したリ
ンク情報を一意に管理することができないという課題が
あった。また、従来の分離リソースリンク・システムで
はリソース関係情報サーバがネットワーク上で複数台連
携して動く機構が無く、データ量が増えた場合のレスポ
ンス、メンテナンス、等でリソース関係情報サーバにボ
トルネックが発生する可能性があるという課題もあっ
た。また、オブジェクトはサーバ上で必ず一元的に管理
されなければならず、サーバ上ににあるオブジェクト
（パブリックなオブジェクト）にクライアント側からロ
ーカルなオブジェクト（他の人は参照不可なオブジェク
ト）をリンクすることなど、ユーザ毎のフレキシブルな
リンク情報の付加が困難であるという課題もあった。

【０００９】この発明は上記の課題を解決するためにな
されたもので、意味の有るリンク情報の固まりを管理し
てユーザのオブジェクト選択の負担をなくすること、ま
たパブリックなリンク情報に対してユーザ独自のリンク
情報の付加を可能にしたリンク情報管理システムを得る
ことを目的としている。

【００１０】

【課題を解決するための手段】この発明に係るリンク情
報管理システムは、ネットワーク上に分散して在るオブ
ジェクトを相互利用するために、これらオブジェクト間
のリンク情報を共通ファイルとして管理するシステムに
おいて、ネットワーク上のオブジェクトの所在を管理
し、リンク情報名をキーとしてリンク情報名に対応する
一連のオブジェクト間の繋がりをリンク元とリンク先で
一意に定めたリンク情報テーブルと、クライアントから
のリンク情報名対応の要求に基づいて、一連のオブジェ
クト間の繋がり情報を検索、登録、削除管理するリンク
情報管理部を備えたリンク情報サーバと、ユーザからプ
ログラムを指定されると、リンク情報テーブルからプロ
グラムに対応するリンク情報名のキー対応の一連の繋が
り情報を得て必要なオブジェクトをダウンロードするオ
ブジェクト・ダウンロード部を備え、ユーザの要求を解
析して上記リンク情報名の特定リンク元を定めて対応す
るリンク先を出力するようにしたクライアントとで構成
される。

【００１１】また更に、リンク情報サーバは、リンク情
報名とリンク情報サーバとを対応させたリンク情報名対
リンク情報サーバ名対応テーブルを持ち、クライアント
からのプログラム対応のリンク情報名のキー対応の一連
の繋がり情報のダウンロード要求があった場合に自リン
ク情報サーバにこの情報がないと、リンク情報名対リン
ク情報サーバ名対応テーブルにある他リンク情報サーバ
に要求を転送するようにした。

【００１２】また更に、クライアントは、そのクライア
ントに固有のリンク元とリンク先の繋がり情報を記憶す
るローカルリンク情報テーブルを持ち、ユーザの要求を
解析してリンク情報サーバか自身のローカルリンク情報
テーブルにリンク情報名対応の特定リンク元を得る簡易
リンクマネージャを付加した。

【００１３】また更に、クライアントは、リンク情報テ
ーブルとリンク情報名対リンク情報サーバ名対応テーブ
ルの、必要部分をダウンロードして記憶するリンク情報
テーブル一時記憶部を付加した。

【００１４】

【発明の実施の形態】

実施の形態１．リンク情報名をキーにして一連のオブジ
ェクト間の繋がりを集中管理して有効利用を図り、また
メンテナンスを容易にしたシステムを説明する。図１は
本実施の形態におけるリンク情報管理システムの構成ブ
ロック図であり、例として一つのリンク情報サーバと二
つのクライアントが通信網を介して接続された場合を示
している。図において、１は通信網、１１はリンク情報
サーバ、１２はリンク情報テーブル、１３はこのリンク
情報テーブル１２を管理するリンク情報管理部、１４は
クライアントからの要求でリンク情報テーブルを検索す
るリンク情報検索部、１５は他のリンク情報サーバやク
ライアントと通信網１と通信を行うネットワーク・イン
タフェース部である。２１、３１はユーザが画面等で情
報を得て次を検索するクライアントで、内部に２２のア
プリケーション、２３のアプリケーション・インタフェ
ース部からの要求を解析して必要情報を得たり他に要求
するアプリケーション・メッセージ受信部、２４の他の
クライアントやリンク情報サーバと通信を行うネットワ
ーク・インタフェース部、２５の他のクライアント等か
らのオブジェクトやリンク情報サーバ１１からのリンク
情報を受けるオブジェクト・ダウンロード部、２６のオ
ブジェクトファイル、２７のアプリケーション・インタ
フェース部がある。

【００１５】図２は、具体的なリンク情報名対応の一連
のオブジェクトの繋がりを表すリンク情報の例を示す図
であり、リンク情報テーブル１２に収容されている。図
において、１２１はリンク情報名、１２２はリンク元フ
ァイルロケーション、１２３はリンク元アンカー・オブ
ジェクト名、１２４はリンク先ファイルロケーション、
１２５はリンク先アンカー・オブジェクト名であり、そ
れぞれの欄に具体的な名称が登録される。１２６はリン
ク情報名１２１の例として登録された「横浜食べ歩
き」、１２７は同じく「横浜観光案内」で、それぞれフ
ァイル「横浜食べ歩き」、「横浜観光案内」でもあると
する。またリンク先アンカー・オブジェクト名が＊の場
合はリンク先オブジェクトはリンク先ファイルそのもの
を表し、１２９のように１２３、１２４、１２５の３つ
のフィールド（欄）が全て＊の場合はそのリンク情報の
終端を表すものとする。なお、リンク情報テーブル１２
にこれ以外の他の付加情報を持つようにしてもよい。図
３は図２のリンク情報名「横浜食べ歩き」１２６と同じ
く「横浜観光案内」１２７に関わるオブジェクトの一部
を示す図で、１３１、１３３、１３５、１３６、１３８
は図３で示されるファイルの一部としての例えば「横浜
の地図」オブジェクト（この場合は画像データ）であ
る。１３２、１３４、１３７は図３で示されるオブジェ
クトのある領域を示すオブジェクト（アンカー・オブジ
ェクト）である。図４はユーザがクライアント２１で行
う入力に基づいての情報の流れを説明する図で、図５は
アプリケーション・メッセージ受信部２３の動作を説明
する動作説明図で、図６はリンク情報サーバ１１の検索
動作を説明する動作説明図である。

【００１６】上述の構成によるシステムの動作を説明す
る。最初にあるユーザが図３に示すアプリケーションの
ファイル「横浜食べ歩き」１２６を作成して、かつリン
ク情報サーバ１１のリンク情報テーブル１２に図２に示
すリンク情報「横浜食べ歩き」１２６を登録していると
する。また別に、図３に示すアプリケーションのファイ
ル「横浜観光案内」１２７をファイル「横浜食べ歩き」
の一部を利用して作成し、リンク情報テーブル１２に登
録しているとする。図２のリンク情報テーブル１２では
関係が判りにくいが、このリンク情報が図３の白い矢印
と黒い矢印の関係を示し、同じファイルの一部である
「横浜の地図」１３３がファイルによって一意に異なる
次のオブジェクトに繋がることが判る。ユーザがクライ
アント２１の図示しないキーボード、マウス等の入力装
置からアプリケーションの「横浜観光案内」を開いて見
ようとする。このファイルのオープンによってファイル
「横浜観光案内」はそのオブジェクトが収容されている
クライアントまたはサーバ等から検索の都度クライアン
ト２１にダウンロードされる場合を説明するが、一括し
てクライアント２１のオブジェクト２６にダウンロード
してもよい。そして最初の画面として図３の「観光案内
オープニング画面」１３６が出る。ユーザが特定の領域
「次へ」１３７を選択（マウスによるクリックなど）す
ると、この入力は登録や削除の要求ではないので、図４
のアプリケーション・インタフェース部２７はリンク元
ファイルロケーションとリンク元アンカー・オブジェク
ト名と共に要求を検索として要求の種類２１１をまとめ
て、アプリケーション・メッセージ受信部２３に送信す
る。

【００１７】アプリケーション・メッセージ受信部２３
では、これを受けて図５の動作をする。即ち、ステップ
２２１で要求の種類が登録ではないので、先ほどの要求
の種類２１１を要求の種類（検索）２２２としてネット
ワーク・インタフェース部２４からリンク情報サーバ１
１にリンク情報を問い合わせる。リンク情報サーバ１１
では、ネットワーク・インタフェース部１５経由で受け
た要求の種類（検索）２２２をみて、リンク情報検索部
１４がリンク情報テーブル１２を参照し、検索結果２３
３として図２のリンク先ファイルロケーション１２４(
及びリンク先アンカー・オブジェクト名だが、この場合
はリンク先ファイルそのものなのでない）の「横浜の地
図」のファイルの位置を得る。そしてネットワーク・イ
ンタフェース部１５からクライアント２１に送信する。

【００１８】クライアント２１では、リンク情報サーバ
１１からのネットワーク・インタフェース部２４で受け
た「横浜の地図」のファイルの位置の情報に基づき、図４
でオブジェクト・ダウンロード部２５がリンク先ファイ
ルをダウンロードし、ファイルに対応するアプリケーシ
ョンを立ち上げて、更にアンカー・オブジェクトのアク
ティブ化２１３により、リンク先ファイル（この場合は
「 横浜の地図」 ）を表示する。以降、ユーザが表示画面
の特定領域であるボタン「次へ」１３５を選択すると、上
述の各部動作と同様の動作が続く。なお、アプリケーシ
ョン・インタフェース部２７は、それぞれのアプリケー
ションが持つマクロ等で記述された固まりである。

【００１９】なお、上述の動作はユーザがファイルを開
いて、アンカー・オブジェクトをたどる動作、つまり検
索動作を説明した。この他に例えば最初にファイルを作
成したユーザがメンテナンスのため途中のファイルの一
部を変更したり、バージョンの変更のためリンク情報テ
ーブル１２の対応するリンク情報を一時削除したり、再
びまたは新規登録する際の動作を説明する。クライアン
ト２１のアプリケーション・インタフェース部２２から
別に設定されたフォーマットで「リンク情報」を指定し
て「削除」の要求をすると、アプリケーション・メッセ
ージ受信部２３が要求の種類２１１の内容が「削除」で
あるので、そのむねネットワーク・インタフェース部２
４からリンク情報サーバ１１に要求の種類（削除）を送
信する。これを受けたリンク情報サーバ１１は、その要
求内容からリンク情報管理部１３が対応する「リンク情
報」をリンク情報テーブル１２から削除する。もちろん
削除はリンク情報であり、オブジェクトそのものは削除
はしない。再登録または新規登録の動作も上述の削除動
作と同様である。

【００２０】実施の形態２．リンク情報サーバは主とし
てそのネットワークに接続されるクライアントがよく利
用するファイルを管理している。しかし、あるクライア
ントからのファイルの問い合わせが管理範囲を越えてい
てもそのリンク情報サーバが対処できるシステムを説明
する。こうすることで管理の効率化と要求の多様性を両
立させることができる。図７は本実施の形態におけるリ
ンク情報管理システムの構成図である。図において、４
１は横浜市のリンク情報サーバ、４２はリンク情報テー
ブル、４３はリンク情報管理部、４４はリンク情報検索
部、４５はネットワーク・インタフェース部である。実
施の形態１と異なる新規な要素として４６はリンク情報
名対サーバ名対応比較部、４７はリンク情報名対サーバ
名対応テーブル、１２７は「横浜観光案内」ファイルで
ある。また５１は鎌倉市のリンク情報サーバ、５２は神
奈川県のリンク情報サーバ、５３は「鎌倉観光案内」フ
ァイル、５４は「神奈川観光案内」ファイルである。な
おクライアントは実施の形態１と同様である。図８はリ
ンク情報名対サーバ名対応テーブルの例を示す図であ
り、４７１はリンク情報名の欄、４７５はそのファイル
を持っているサーバの名称を示す欄である。図９はリン
ク情報名対サーバ名対応比較部４６の動作を説明する図
である。

【００２１】上述構成のシステムのリンク情報検索時の
動作概要は以下の様になる。横浜市サーバ４１につなが
っているクライアント２１からリンク情報名「鎌倉観光
案内」４７４に対する検索要求が横浜市サーバ４１に対
して送られてくると、横浜市サーバ４１はサーバ内にあ
る「リンク情報名−サーバ名対応テーブル」４７よりリ
ンク情報名「鎌倉観光案内」４７４が管理されているリ
ンク情報サーバが「鎌倉市サーバ」４７８であることが
分かる。横浜市サーバ４１はクライアント２１から送ら
れてきた検索要求を鎌倉市サーバ５１に転送し、鎌倉市
サーバ５１から検索結果（リンク先のオブジェクトのロ
ケーション）を受け取り、それを要求もとのクライアン
ト２１に送信する。

【００２２】リンク情報サーバ（横浜市）４１の転送動
作を図９に基づき詳細に説明する。「リンク情報名−サ
ーバ名対応比較部」４６は、ネットワーク・インタフェ
ース部４５を介してクライアント２１から送られてくる
検索要求（４４１）を受信する。次に送られてきた検索
要求４４１の中のリンク情報名「鎌倉観光案内」をキー
にしてリンク情報名−サーバ名対応テーブル４７からそ
のリンク情報を格納しているリンク情報サーバ名を検索
する（ステップ４６１）。得られたリンク情報サーバ５
１に対し、クライアントからのメッセージを転送する
（ステップ４６２）。転送先のサーバ上のリンク情報検
索部５５は実施の形態１と同様に検索を行い、結果を送
信元サーバであるリンク情報サーバ（横浜市）４１のリ
ンク情報名−サーバ名対応比較部４６に返す。リンク情
報名−サーバ名対応比較部４６は帰ってきた検索結果を
ネットワーク・インタフェース部４５を介してクライア
ント２１に転送する。クライアントのその後の動作は実
施の形態１と同様である。

【００２３】なお、リンク情報テーブルを上述のように
リンク情報名をキーとして一意に定めて管理しておけ
ば、これらのリンク情報名を組み合わせて新しい情報名
で一連のオブジェクト間の繋がりを登録できる。以下に
その組合せ利用の場合を説明する。図１０はリンク情報
の結合を説明するための図で、図１１はファイル「神奈
川観光案内」５４の結合部分であるファイルの一部５４
１の説明図である。図１０（ａ）に示すように、もとは
ファイル「神奈川観光案内」５４、「横浜観光案内」１
２７と「鎌倉観光案内」５３はそれぞれ別のファイルで
あった。これをファイルの一部５４１のアンカー・オブ
ジェクトを加工して、リンク情報テーブルに新しいリン
ク情報名として「神奈川観光案内」５４０を図１１
（ｂ）に示すような一連情報として登録すれば、図１０
（ｂ）のように結合できる。

【００２４】実施の形態３．多数の人が利用できるパブ
リックな情報ではなくて個人医療情報のような担当の医
者以外は秘密にしておきたい情報があり、その場合でも
パブリックな情報と結合して効果を発揮できるシステム
がある。本実施の形態のシステムはクライアントに特徴
がある。図１２は本実施の形態におけるリンク情報管理
システムの構成図である。図において、６０は医療リン
ク情報サーバ、６１は医師クライアント、６２はアプリ
ケーション、６３はアプリケーション・メッセージ受信
部、６４はネットワーク・インタフェース部、６５はオ
ブジェクト・ダウンロード部、６６はオブジェクトで、
他の実施の形態の同名の要素と同じある。実施の形態１
と異なる新規な要素として６７は簡易リンクマネージャ
部、６８はローカルリンク情報テーブルである。図１３
は医療リンク情報サーバ６０の医療リンク情報ファイル
６０１のファイルの一部である＊＊＊ファイル６０２、
同じく盲腸の症例ファイル６０３、同盲腸の対処法ファ
イル６０４、＊＊＊＊ファイル６０５の関係と、医師ク
ライアントからこのパブリックな医療リンク情報ファイ
ル６０１の一部のファイルを利用する場合の説明図であ
る。図において、６９は患者のカルテファイルである。
図１４はリンク情報テーブル６０１の医療リンク情報６
１０のリンク元ファイルとリンク先ファイルを結んだ一
連のオブジェクト間の繋がりを示す図であり、図１５は
医師クライアント６１のローカルリンク情報６８の例を
示す図である。また図１６は同じく医師クライアント６
１内の簡易リンクマネージャ部６７の動作を説明するた
めの図である。

【００２５】まず、各医師が持つクライアント６１上に
は診療した患者のカルテ６９がオブジェクトとして存在
する。医師が医療リンク情報サーバ６０のパブリックな
医療リンク情報６１０を検索し、自分が診察している盲
腸患者のカルテに参考となるオブジェクト「盲腸の症例
ファイル」６０３を見つけた場合、盲腸患者のカルテ６
９（オブジェクト）を検索したオブジェクト「盲腸の症
例ファイル」６０３とリンクしておく。図１５はこのリ
ンクを自分のローカルリンク情報テーブル６８に登録し
た後の状態を示している。この登録で図１３の太線表示
のように盲腸患者のカルテファイル６９から盲腸の症例
ファイル６０３に接続される。このことはローカル医療
リンク情報６８１で登録、管理される。この様に医療リ
ンク情報サーバ６０で管理されるパブリックな情報にカ
ルテファイルの様なローカルなオブジェクト６９をリン
クすることが可能になる。また、リンクしたローカルな
オブジェクト６９は他のクライアントからは辿ることが
できないため、個人の秘密を保護するというセキュリテ
ィの面でも有効である。

【００２６】盲腸患者のカルテ６９から盲腸の症例ファ
イル６０３及びその先の盲腸の対処法ファイル６０４を
辿る場合の動作概要は以下の様になる。盲腸患者のカル
テ６９からリンクされているオブジェクトを検索する場
合、まず、ローカル医療リンク情報６８１を検索し、リ
ンク先オブジェクト（盲腸症例）６０３のロケーション
を得る。その後盲腸症例ファイル６０３の先のリンク情
報を検索する場合は、まず、ローカルリンク情報を検索
し（当然存在しない）、次に医療リンク情報サーバ６０
に検索要求を行って盲腸症例ファイル６０３のリンク先
オブジェクト「盲腸の対処法ファイル」のロケーション
６０４を得ることが出来る。

【００２７】クライアント６１の中にある簡易リンクマ
ネージャ部６７の動作を説明する。ユーザの動作に対し
て、つまりアプリケーション・インタフェース部からの
ローカルリンク情報に対しての登録／削除／検索の要求
には、図１６の動作を行う。図４の動作と同様、アプリ
ケーション・インタフェース部からアプリケーション・
メッセージ受信部６３に送られた処理要求は、この場
合、簡易リンクマネージャ部６７に渡される。ステップ
６７１で処理要求が検索以外（登録／削除）の場合、ス
テップ６７２でローカルリンク情報テーブル６８に対し
て登録／削除が行われる。処理要求が検索の場合、ま
ず、ステップ６７３でローカルリンク情報テーブル６８
を検索し、該当するリンク情報が存在すれば、ステップ
６７５でオブジェクト・ダウンロード部６５に「リンク
情報名」「リンク先ファイルロケーション」「リンク先
アンカー・オブジェクト名」を渡す。またローカルリン
ク情報の検索で該当するリンク情報が存在しない場合、
ステップ６７４で処理要求（検索）はネットワーク・イ
ンタフェース部６４を介して医療リンク情報サーバ６０
に渡される。それ以降のオブジェクト・ダウンロード部
６５等の動作は、実施の形態１で述べたと同様になる。

【００２８】実施の形態４．上述の各実施の形態ではク
ライアントからリンク情報のリンク元を指定してその都
度リンク先を主としてリンク情報サーバから得る場合を
説明したが、ネットワーク上の通信量を減らしてかつリ
ンク情報サーバの負荷を減らすシステムを説明する。本
実施の形態のシステムもクライアントに特徴がある。図
１７は本実施の形態におけるリンク情報管理システムの
構成図である。図において、８０はリンク情報サーバ、
７１はクライアント、７２はアプリケーション、７３は
アプリケーション・メッセージ受信部、７４はネットワ
ーク・インタフェース部、７５はオブジェクト・ダウン
ロード部、７６はオブジェクトで、他の実施の形態の同
名の要素と同じある。実施の形態１と異なる新規な要素
として８２はリンク情報一時保持部、８３はリンク情報
名対サーバ名対応テーブル一時保持部、８４は簡易リン
ク検索部、８５はリンク情報一括ダウンロード部であ
る。図１８は本実施の形態におけるリンク情報と端末へ
のダウンロードの例を示す図であり、図１９はクライア
ントの中のリンク情報一括ダウンロード部８５の動作を
説明するための図である。また図２０は本実施の形態で
用いる車のセールスに関するリンク情報テーブルの例を
示す図である。

【００２９】クライアント７１はリンク情報サーバ８０
に対して利用するリンク情報名を指定し、そのリンク情
報群及び、「リンク情報名−サーバ名対応テーブル」の
中で必要となる部分をリンク情報サーバ８０から受け取
る。受け取った後はリンク情報の検索はクライアント７
１側のみで行えるため、検索においてサーバとの通信は
必要ない。クライアント７１内でリンク情報を検索すれ
ば、必要なオブジェクトを管理するクライアントが判
る。オブジェクトのダウンロードはこの判明した管理し
ているクライアントにオブジェクトのダウンロードの要
求を行って実行される。

【００３０】具体的な例を以下に示す。車の営業を例に
する。セールスマンは自分のノートパソコンの端末１
７１に顧客情報として個別の「顧客１」９１１、「顧客
２」９１２の情報ファイル及び、「車種Ａの写真」９１
３、「車種Ｂの写真」（画像ファイル）９１４を持って
おり、これらのオブジェクトのリンク情報は営業所のリ
ンク情報サーバ８０によって管理されているとする。ま
た、「車種Ａの写真」「車種Ｂの写真」はそれぞれその
車の詳細なスペックを記述した複数の「カタログ」（車
種Ａカタログ１９０１→車種Ａカタログ２、車種Ｂカタ
ログ１→車種Ｂカタログ２）がリンク先として連なって
いるとする。この「カタログ」オブジェクト自身は営業
所のカタログ情報サーバ９０にあるものとする。図１８
に示すようにリンク情報テーブルは「顧客１」から連な
るリンク情報名を「顧客１リンク」８８、「顧客２」か
ら連なるリンク情報名を「顧客２リンク」８９として持
っている。普段営業所内で高速の通信網を利用する場
合、実施の形態１で示した様なリンクの検索を行う。し
かしながら客先への営業のために端末１ ７１を持って
行く場合、営業所のサーバ８０との通信は低速な公衆回
線を利用するため、通常の経路でいちいちリンク情報の
検索、ダウンロードを行っていたのでは、リンク先のオ
ブジェクトが表示されるまで時間がかかってしまう。

【００３１】そこで、顧客１の自宅を訪問して営業活動
を行う場合、端末１ ７１にある情報以外のリンク先オ
ブジェクト（「カタログ」）が必要になったら、まず、
リンク情報サーバ８０からリンク情報名顧客１リンク８
８のリンク情報と、必要なら「リンク情報名−サーバ名
対応テーブル」を一括して端末１ ７１にダウンロード
を行い（上述の場合はリンク情報は分散されていないた
め、「リンク情報名−サーバ名対応テーブル」のダウン
ロードは必要なないが）端末１ ７１の中に保持する。
その後リンク情報の検索は「顧客１」に関する限り端末
１ ７１内で全て行えるため、低速な公衆回線を利用し
てリンク情報サーバと情報のやり取りをする必要が無く
なる。実際のリンク先のオブジェクトのダウンロードは
端末１ ７１の中で行った検索の結果得たクライアント
またはサーバから直接ダウンロードを行う。

【００３２】クライアント７１としての端末１における
他の実施の形態にはない部分の動作を説明する。図１９
において、リンク情報一括ダウンロード部８５はユーザ
からステップ８５１でリンク情報名の入力を受け、リン
ク情報サーバ８０に処理要求（リンク情報一括ダウンロ
ード要求）とリンク情報名をステップ８５２で送信す
る。リンク情報サーバ８０はリンク情報名に関連するリ
ンク情報（この場合は顧客１リンク８８）と関連するリ
ンク情報名―サーバ名対応テーブルを要求元のクライア
ント７１のリンク情報一括ダウンロード部８５に送信す
る。サーバ８０から情報を受け取ったリンク情報一括ダ
ウンロード部８５は、その情報を「リンク情報一時保持
部」８２とリンク情報名−サーバ名対応テーブル一時保
持部８３に保持する。それ以降は、アプリケーション・
インタフェース部からのユーザの問い合わせに対し、原
則として簡易リンク検索部８４はリンク情報一時保持部
８２、リンク情報名−サーバ名対応テーブル一時保持部
８３に対しての検索を行う。即ち、図４にあらわされる
様なアプリケーション・インタフェース部からアプリケ
ーション・メッセージ受信部に送られた検索要求は、こ
の実施の形態では簡易リンク検索部８４に渡される。検
索要求を受信した簡易リンク検索部８４は、リンク情報
一時保持部８２、リンク情報名−サーバ名対応テーブル
一時保持部８３を検索し、オブジェクト・ダウンロード
部７５に「リンク情報名」「リンク先ファイルロケーシ
ョン」「リンク先アンカー・オブジェクト名」を渡す。
これは先の実施の形態の簡易リンクマネージャ部と全く
同じ動作であり、これ以外の動作は先の実施の形態にお
ける同名の要素と全く同じ動作をする。ただし、簡易リ
ンク検索部は簡易リンクマネージャ部の持つリンク情報
の登録／削除機能は持たない。なお、この実施の形態に
よれば、リンク情報をモーバイル端末などの非同期処理
が必要な環境でも利用可能である。

【００３３】

【発明の効果】以上のようにこの発明によれば、リンク
情報名をキーとした一意に定まるリンク情報テーブルを
設けたので、ユーザに専門知識を要求せず、選択の負担
を軽くし、サーバ側の動作の負担を軽くする効果があ
る。

【００３４】また更に、管理するリンク情報サーバ対応
のリンク情報を記憶するリンク情報名対リンク情報サー
バ名テーブルを備えたので、リンク情報サーバの規模を
抑えて利用規模を広げられ、かつメンテナンスが容易に
なる効果がある。

【００３５】また更に、クライアントに他のクライアン
トからは覗けないローカルリンク情報テーブルを設けた
ので、ローカルなオブジェクトからなるファイルに対し
ては秘密が保てる効果がある。またフレキシブルなファ
イルの構成ができる効果もある。

【００３６】また更に、クライアントにリンク情報一時
記憶部を設けたので、通信量と通信時間を減らす効果が
ある。また非同期処理が必要なクライアントでも使用で
きる効果がある。

【図面の簡単な説明】

【図１】 本発明の実施の形態１におけるリンク情報管
理システムの構成ブロック図である。

【図２】 実施の形態１におけるリンク情報テーブルの
データ例を示す図である。

【図３】 実施の形態１におけるリンク情報名対応のオ
ブジェクトの例を示す図である。

【図４】 実施の形態１におけるユーザの入力操作に対
応する情報の流れを示す図である。

【図５】 実施の形態１におけるアプリケーション・メ
ッセージ受信部の動作を説明するための図である。

【図６】 実施の形態１におけるリンク検索部の動作を
説明するための図である。

【図７】 本発明の実施の形態２におけるリンク情報管
理システムの構成ブロック図である。

【図８】 実施の形態２におけるリンク情報名対サーバ
名対応テーブルのデータ例を示す図である。

【図９】 実施の形態２におけるリンク情報名対サーバ
名対応比較部の動作を説明するための図である。

【図１０】 実施の形態２におけるリンク情報の結合利
用を説明するための図である。

【図１１】 実施の形態２におけるリンク情報の結合利
用を説明するための図である。

【図１２】 本発明の実施の形態３におけるリンク情報
管理システムの構成ブロック図である。

【図１３】 実施の形態３におけるパブリックなファイ
ルの一部利用を説明するための図である。

【図１４】 実施の形態３におけるリンク情報テーブル
のデータ例を示す図である。

【図１５】 実施の形態３におけるローカルリンク情報
テーブルを示す図である。

【図１６】 実施の形態３における簡易リンクマネージ
ャ部の動作を説明するための図である。

【図１７】 本発明の実施の形態４におけるリンク情報
管理システムの構成ブロック図である。

【図１８】 実施の形態４におけるリンク情報の例と端
末へのダウンロードの例を示す図である。

【図１９】 実施の形態４におけるリンク情報一括ダウ
ンロード部の動作を説明する図である。

【図２０】 実施の形態４におけるリンク情報テーブル
のデータ例を示す図である。

【図２１】 従来の分散リソースリンク管理システムの
図である。

【図２２】 従来の分散リソースリンク管理システムの
リソース蓄積部の構成図である。

【図２３】 従来の分散リソースリンク管理システムの
リンク関係テーブルの図である。

【図２４】 従来の分散リソースリンク管理システムを
説明するためのオブジェクト・リンク説明図である。

【図２５】 従来の分散リソースリンク管理システムの
リンク関係テーブルの図である。

【符号の説明】

１ 通信網、１１ リンク情報サーバ、１２ リンク情
報テーブル、１３ リンク情報管理部、１４ リンク情
報検索部、１５ ネットワーク・インタフェース部、２
１ クライアント、２２ アプリケーション、２３ ア
プリケーション・メッセージ受信部、２４ ネットワー
ク・インタフェース部、２５ オブジェクト・ダウンロ
ード部、２６ オブジェクトファイル、２７ アプリケ
ーション・インタフェース部、３１，３２ クライアン
ト、４１ リンク情報サーバ、４２ リンク情報テーブ
ル、４３ リンク情報管理部、４４ リンク情報検索
部、４５ ネットワーク・インタフェース部、４６ リ
ンク情報名対サーバ名対応比較部、４７ リンク情報名
対サーバ名対応テーブル、５１ リンク情報サーバ、５
２ リンク情報サーバ、５３ 鎌倉観光案内ファイル、
５４ 神奈川観光案内ファイル、６０ リンク情報サー
バ、６１ 医師クライアント、６２ アプリケーショ
ン、６３ アプリケーション・メッセージ受信部、６４
ネットワーク・インタフェース部、６５ オブジェク
ト・ダウンロード部、６６ オブジェクトファイル、６
７ 簡易リンクマネージャ部、６８ ローカルリンク情
報テーブル、６９ カルテファイル、６０１ 医療リン
ク情報ファイル、７１ クライアント（端末１）、７２
アプリケーション、７３ アプリケーション、７４
ネットワーク・インタフェース部、７５ オブジェクト
・ダウンロード部、７６ オブジェクトファイル、８０
リンク情報サーバ、８２ リンク情報一時保持部、８
３ リンク情報名対サーバ名対応テーブル一時保持部、
８４ 簡易リンク検索（マネージャ）部、８５ リンク
情報一括ダウンロード部、９０ カタログ情報サーバ。

Claims (4)

【特許請求の範囲】
1. 【請求項１】 ネットワーク上に分散して在るオブジェ
   クトを相互利用するために、上記オブジェクト間のリン
   ク情報を共通ファイルとして管理するシステムにおい
   て、 上記ネットワーク上のオブジェクトの所在を管理し、リ
   ンク情報名をキーとして該リンク情報名に対応する一連
   のオブジェクト間の繋がりをリンク元とリンク先で一意
   に定めたリンク情報テーブルと、クライアントからの上
   記リンク情報名対応の要求に基づき上記一連のオブジェ
   クト間の繋がり情報を検索、登録、削除管理するリンク
   情報管理部を備えたリンク情報サーバと、 ユーザからプログラムを指定されると、上記リンク情報
   テーブルから該プログラムに対応する上記リンク情報名
   のキー対応の一連の繋がり情報を得て必要なオブジェク
   トをダウンロードするオブジェクト・ダウンロード部を
   備え、ユーザの要求を解析して上記リンク情報名の特定
   リンク元を定めて対応するリンク先を出力するようにし
   たクライアントからなるリンク情報管理システム。
2. 【請求項２】 リンク情報サーバは、リンク情報名とリ
   ンク情報サーバとを対応させたリンク情報名対リンク情
   報サーバ名対応テーブルを持ち、クライアントからのプ
   ログラム対応のリンク情報名のキー対応の一連の繋がり
   情報のダウンロード要求があった場合に自リンク情報サ
   ーバに該情報がないと、上記リンク情報名対リンク情報
   サーバ名対応テーブルにある他リンク情報サーバに要求
   を転送するようにしたことを特徴とする請求項１記載の
   リンク情報管理システム。
3. 【請求項３】 クライアントは、該クライアントに固有
   のリンク元とリンク先の繋がり情報を記憶するローカル
   リンク情報テーブルを持ち、ユーザの要求を解析してリ
   ンク情報サーバか上記ローカルリンク情報テーブルにリ
   ンク情報名対応の特定リンク元を得る簡易リンクマネー
   ジャを付加したことを特徴とする請求項１記載のリンク
   情報管理システム。
4. 【請求項４】 クライアントは、リンク情報テーブル
   と、リンク情報名対リンク情報サーバ名対応テーブルの
   必要部分をダウンロードして記憶するリンク情報テーブ
   ル一時記憶部を付加したことを特徴とする請求項１記載
   のリンク情報管理システム。