JP2004348760A - 呼関係管理装置 - Google Patents

Abstract

【課題】本発明は、リアルタイムで変化するネットワーク資源を利用者の便宜に応じて切換できるコミュニケーション・ナビゲーション・システムを提供する。
【解決手段】端末局2は、センター局1にオブジェクトの属性を登録する登録部21と、センター局に呼関係候補オブジェクトを要求する呼関係候補要求部22と、センター局から通知される呼関係候補オブジェクトのエントリを格納する呼関係候補格納部23と、呼関係候補格納部の呼関係候補との呼関係を締結或いは解消する呼関係制御部24とを備え、センター局1は、端末局によって登録されるオブジェクトの属性とオブジェクトのエントリとを保持する保持部11と、オブジェクトに関する呼関係候補オブジェクトをオブジェクトのエントリ又はオブジェクトの属性により決定する呼関係候補決定部12と、オブジェクトからの要求に応じて、呼関係候補オブジェクトのエントリをオブジェクトに通知する呼関係候補通知部13と含む。
【選択図】 図１

Description

本発明は、ネットワークに接続されている複数の計算機上のオブジェクト間の呼関係を管理する呼関係管理装置に関する。

ネットワーク・コミュニケーションの為のユーティリティとして良く知られているものとして、「Ｈａｂｉｔａｔ」が挙げられる。「Ｈａｂｉｔａｔ」は、ユーザに２次元の共有空間（マップ）を提供するシステムであり、利用者端末局（ＰＣ）上のグラフィックス表示装置と、センター局でＬＡＮ接続されたホスト群から構成される。ホストにログオンした利用者はホスト内のタスクとして管理され、マップ上の領域を共有する利用者相互の通信は、センター局のホスト内或いはホスト間の通信によって実現され、通信内容が利用者端末局に転送される。

「Ｍｏｓａｉｃ」も又ネットワーク・ナビゲーションの機能を持つネットワーク・ユーティリティとして、良く知られている。「Ｍｏｓａｉｃ」は、ネットワーク上に置かれた（基本的に）静的なデータをハイパー・テキストとして提示するシステムである。このシステムはデータ・サーバ・マシン上のｈｔｔｐｄと呼ばれるサーバと、Ｍｏｓａｉｃ、或いはｃｈｉｍｅｒａ等のクライアントから構成される。クライアントはｈｔｍｌ仕様で記述されたテキストを解釈し、必要なデータを得るためにサーバにアクセスする。サーバは、クライアントから要求されたデータを転送するが、その際必要であれば、データに対するアクセス権のチェックを行う。クライアントは、サーバ（群）から転送されて来たデータを、その属性に従って利用者に提示する。更にクライアントは利用者の指示（ハイパー・テキストのクリック）に従い、サーバにデータ・アクセスを行う。

「Ｈａｂｉｔａｔ」システムにおけるネットワーク資源提示の切り口は、二次元のマップに限定されており、様々な視点からネットワーク資源を提示する能力に欠ける。例えば、マップ上で利用者端末の所在地域が近い利用者のみを提示する事、或いは二次元マップから利用者の所属組織別の表示に切り換える事等、利用者の要求に即応する機動的な運用が困難である。更に、「Ｈａｂｉｔａｔ」はセンターに於ける集中制御である為、共有データの整合性維持が容易である反面、センターの処理能力が利用者の規模を規定してしまう。従って、極めて大規模なシステムを構築するには多大なコストが必要となる。「Ｍｏｓａｉｃ」システムの場合も、ネットワーク資源提示の形式は、ハイパー・テキストに限定されている。このシステムでは、サーバ設置のコストは極めて低い。しかし、ハイパー・テキストのナビゲーション機能は静的である。即ち、リアル・タイムで内容や所在が変化するデータに対するナビゲーションには不向きである。

本発明は、リアルタイムで変化するネットワーク資源を、センターに過大な負荷を懸けること無く、様々な視点で提示し、しかも、その視点を各利用者の便宜に応じて任意に切り替える事を可能とするコミュニケーション・ナビゲーション・システムを提供することを目的とする。

本発明は、センター局とターミナル局とを用いてオブジェクト間にコミュニケーションの機会を提供するコミュニケーション・ナビゲーション・システムにおいて、各オブジェクトに属する前記ターミナル局が、センター局にオブジェクトの属性を登録する登録手段と、センター局に呼関係候補オブジェクトを要求する呼関係候補要求手段と、センター局から通知される呼関係候補オブジェクトのエントリを格納する呼関係候補格納手段と、呼関係候補格納手段に格納されている呼関係候補との呼関係を締結或いは解消する呼関係制御手段とを備え、センター局が、ターミナル局の前記登録手段によって登録されるオブジェクトの属性と当該オブジェクトのエントリとを保持する保持手段と、各オブジェクトに関する呼関係候補オブジェクトをオブジェクトのエントリ又はオブジェクトの属性に基づいて決定する呼関係候補決定手段と、オブジェクトからの要求に応じて、当該オブジェクトに関する呼関係候補オブジェクトのエントリを当該オブジェクトに対して通知する呼関係候補通知手段とを含む事を特徴とする、コミュニケーション・ナビゲーション・システムを提供する。

オブジェクトがキー情報登録手段を有し、センター局にオブジェクトの属性を通知する。各オブジェクトの属性は、センター局のキー情報保持手段に格納される。これにより、オブジェクトは、リアルタイムで変化する属性をセンター局に登録する事が可能になる。オブジェクトの呼関係候補要求手段は、必要に応じて、センター局に呼関係候補オブジェクトを要求する。この際、呼関係候補の幾つかの属性を指定する事も可能である。センター局の呼関係候補決定手段がこの要求を受取り、当該オブジェクトに関する呼関係候補を決定し、それを呼関係候補通知手段に引き渡す。呼関係候補通知手段は呼関係候補のエントリをオブジェクトに通知する。この際、キー情報保持手段に登録されている、呼関係候補オブジェクトの属性を通知する様にしても良い。センター局から通知される呼関係候補オブジェクトのエントリは、オブジェクトの呼関係候補格納手段に格納される。呼関係候補通知手段から呼関係候補オブジェクトの属性が通知される場合には、それも又ここに格納される。オブジェクトの呼関係制御手段が、呼関係候補格納手段に格納されている呼関係候補とそのエントリを参照して、呼関係候補との呼関係を制御する。呼関係制御手段は、呼関係を締結（解消）する前に、利用者の指示に基づいて、当該候補と呼関係を締結（解消）するか否かを選択する様にしても良い。呼関係候補の属性が呼関係候補格納手段に格納されている場合には、その属性もこの選択の判断材料となり得る。

この発明によれば、ネットワークに接続されているオブジェクトがリアルタイムで変化するネットワーク内の呼関係を必要に応じて取得し、例えば他のオブジェクト間の呼関係をアクセスする等、呼関係情報を積極的に利用することができる。

以下、図面を参照しながら実施例を説明する。
図１には、本発明の一実施例に係るコミュニケーション・ナビゲーション・システムが示されている。同図によると、センター局１には、キー情報保持部１１、呼関係候補決定部１２および呼関係通知部１３からなり、キー情報保持部１１には、例えばオブジェクトの属性の一つとして、仮想３次元空間に於けるオブジェクトの位置と大きさが保持されている。ネットワーク資源は利用者オブジェクト２、静的資源オブジェクト３および動的資源オブジェクト３の３つの種類に分類される。

利用者オブジェクト２は、例えばユーザのプロセスなどであり、システム利用者にシステムの状況を表示し、利用者からオブジェクトに対する指示を受取る為に、マルチメディア情報制御部２５を有する。又、他のオブジェクトと呼関係を結ぶ前に参照すべき情報を格納する呼関係制御部２４を有する。

この利用者オブジェクト２の各部の動作においては、システム利用者が、マルチメディア情報制御部２５を操作してシステムにログインする様に指示する。マルチメディア情報制御部２５は、キー情報登録部２１に対して、オブジェクトのネットワーク・エントリとオブジェクトの属性とを、センター局１に登録する様に指示する。ここでは、オブジェクトの属性として、オブジェクトの３次元空間内の位置と大きさ、利用者端末２の所在地域が含まれているものとする。

静的資源オブジェクト３は、言わば「待ちオブジェクト」であり、例えば劇場などの動かないオブジェクトであり、データベース的なものである。静的資源オブジェクトのキー情報登録部３１は、静的資源オブジェクトをセンター局１に登録する際にのみ用いられ、後は他のオブジェクトから通信の要求が来るのを待っている。

動的資源オブジェクト４は、「自走オブジェクト」であり、例えば、自動車等のような移動オブジェクトであり、エージェントやデーモンのようなプロセスである。動的資源オブジェクト４はキー情報登録部４１を有しており、例えば３次元空間での位置を一定時間ごとに更新することができる。

実際のネットワークには、図２に示すようにこれらのオブジェクトの組合せで種々の形態を取ることができる。

それぞれのオブジェクト２、３および４はそれぞれのキー情報登録部２１、３１および４１が登録を終えると、例えば利用者端末２に属するマルチメディア情報制御部２５は呼関係候補要求部２２に３次元空間内の位置に基づく呼関係を要求する様指示を出す。呼関係候補要求部２２はセンター局１に３次元空間内の位置に基づく呼関係候補を通知するよう要求を出す。センター局１から通知される呼関係候補のネットワーク・エントリとその属性は、呼関係候補格納部２３に格納される。呼関係候補格納部２３は、呼関係候補の更新を、呼関係制御部２４に通知する。呼関係格納部２３は現在締結中の呼関係を格納している。ログイン時には、当然、呼関係格納部２３には呼関係が格納されていない。呼関係制御部２４は、呼関係格納部２３に格納されている呼関係を検索し、特定の呼関係が結ばれているか否かを調べる事ができる。呼関係制御部２４は、現在呼関係締結を禁止されているオブジェクトを格納している。それは、オブジェクトのネットワーク・エントリで指定されている場合もあり、オブジェクトの属性で指定されている場合もある。オブジェクトの属性で指定されていると言うことは、即ち「或る属性を有する（有しない）オブジェクトとは呼関係を結ばない」と言う事である。

呼関係制御部２４に格納される呼関係制御情報は、利用者が設定したものである。呼関係制御部２４は、呼関係制御部２４に格納されている呼関係制御情報を検索し、特定の呼関係の締結が許可されているか否かを調べる事ができる。利用者が呼関係制御情報を適切に設定することにより、呼関係制御部２４の呼関係制御情報設定手段を次の様に活用することができる。

ｉ）仕事でシステムにアクセスする際に、私的な交遊関係の知人・友人とは呼関係を結ばない様にする。

ｉｉ）以前に出会った好ましくない人物とは一定期間呼関係を結ばない様にする。

図３、図４、図５および図６は、呼関係制御部２４、３２および４４の動作を示している。

図３において、まず、呼関係候補更新通知、オブジェクトＸからの接続要求、オブジェクトＸからの接続受理およびオブジェクトＸからの切断通告を受け取ると、それぞれに対応する処理が実行される。

即ち、呼関係候補更新通知を受けると、呼関係オブジェクトのリストＬおよび呼関係オブジェクトのリストＬ’が読み出され、これらリストに基づいてオブジェクトＭ；について、呼関係候補の更新が実行される。なお、この図３において、ＣＯＳは図１８に示されるように呼関係格納部を示し、ＩＷおよびＳＷは画像情報格納部および音響情報格納部を示している。

図３において、接続要求を受け取った場合には、図４のフローに従って接続処理を実行する。また、接続受理を受け取った場合には、図５のフローに従って接続受理の処理を実行する。同様に、切断通告を受け取った場合には、図６のふろーに従って切断通告の処理を実行する。なお、図６において、ＩＲおよびＳＲは図１８に示すように画像情報読み取り部および音響情報読み取り部を示している。

マルチメディア情報制御部２５は、オブジェクトに関係するマルチメディアデータを格納し、ネットワークを通じたアクセスに応じて、格納しているデータを送信する。マルチメディア情報制御部２５は、呼関係制御部２４から与えられるネットワーク・エントリから、データを読み出す。呼関係制御部２４がマルチメディア情報制御部２５に対してデータ読取り中止を指示したとき、マルチメディア情報制御部２５は、読取り中であれば読取りを中止し、マルチメディア情報制御部２５との接続を切断する。読取り中でなければ何も行わない。マルチメディア情報制御部２５は読み取ったデータ表示する。

動（静）的資源オブジェクト４（３）の各部の動作は、利用者オブジェクト２の各部の動作と同様である。ただし、動的資源オブジェクト４は、一定時間毎に３次元空間上のオブジェクトの位置を更新でき、オブジェクトの属性を変更し、新たな属性をセンター局１に登録するよう、キー情報登録部４１に指示を与える。次いで、呼関係候補要求部４２に対して、新たな呼関係候補を要求するように指示を与える。位置の変化によって、呼関係を結ぶべきオブジェクトは変わっている筈だからである。

利用者オブジェクト２において、利用者がマルチメディア情報制御部２５を通して位置を変更した場合も、同様に呼関係を更新しなければならない。この手続きは、動的資源オブジェクト４とまったく同様に、キー情報登録部２１に次いで呼関係候補要求部２２に対する指示で実現される。

次に、センター局１の各部の動作を説明する。

キー情報保持部１１は、例えばオブジェクト２のキー情報登録部２１から送られるネットワーク・エントリと属性とを図７の様なリストで保持する。検索と登録の便を計るため、幾つかの一般的な属性に関しては、ハッシュ・テーブルを作成する。呼関係候補決定部１２は、オブジェクト２の呼関係候補要求部２２からの要求に応じて、キー情報保持部１１のリストを検索し、当該オブジェクト２に関する呼関係候補を決定し、それを呼関係候補通知部１３に送る。呼関係候補要求部２２からの要求は、例えば、次の様な形で与えられる。

ＧＥＴＮＢ オブジェクト名，（３ｄ，ｄ）
ＧＥＴＮＢ オブジェクト名，（３ｄ，ｄ），（ｌｏｃ，Ｔ市）
ｄは実数である。初めの要求は、仮想３次元空間において、当該オブジェクト２の中心から距離ｄ内にある呼関係候補を与える様要求している。後の例では、それに加えて、端末所在地域がＴ市である様な呼関係候補オブジェクトを要求している。呼関係候補通知部１３は呼関係候補決定部１２から送られた呼関係候補のリストを、属性付きで当該オブジェクトの呼関係候補格納部２３に転送する。

次に、第２の実施例を説明する。この実施例は、上記第１の実施例のシステムによって、仮想的な市場（バーチャル・マーケット）を実現したときの実施例をである。

図７は、このバーチャルマーケットの構成を示している。バーチャルマーケットマップ管理装置５では、仮想的な空間座標とその空間に存在するオブジェクトのデータを管理しており、必要に応じて各オブジェクトにネットワークを介してデータを提供したり、受けとったりする。ネットワークには、買物客が使う買物客用端末６、店員が使う店員用端末８、自動販売機のような挙動をする動的資源オブジェクトである店エージェントをもつサーバ７などが存在する。

図８はバーチャルマーケットマップ管理装置５が有しているデータの一例であり、呼関係候補リストとして各端末や各サーバに通知される。なお、このデータはユーザのマーケットへのログイン、ログアウトなどによって動的に変化する。

ところで、実際にバーチャルマーケットを運用する場合、コミュニケーションの形態は、次のように仮定できる。

１）お店の数に対して、買物客が大多数である。

２）対話の大部分は「お客ー店員」である。

３）「お客ーお客」、「店員ー店員」の対話は相対的に非常に少ない。

そこで、これらの形態に会わせた呼関係制御部が考えられる。
図９は買物客用に特化したユーザオブジェクトにおける呼関係制御部の一例を示す。これによると、ユーザは買物の形態として、次の３つのモードを選択できる。

“決め買いモード”は、買うもの（または買う店）がはっきり決まっていて、他の客オブジェクトと通信することを全く必要としないときに使用し、店員や店舗とのみ通信を確立することで、人混みにわずらさされることがなく、通信量も大幅に縮小できる。

“活気実感モード”は、買うもの（または買う店）が漠然としていて、周囲の状況（お店の人気や活気）を知りたいが、他の客オブジェクトと通信は必要ないときに使用し、店員や店舗とのみ通信を確立すると同時に、他のお客の流れを示した“人混み”オブジェクトを生成する。これによってどの店に人が集まっているかを視覚化でき、買物の判断に利用することができ、同時に、通信量も縮小できる。

“通常通信モード”は、マーケットを無目的でぶらつきたいような時に使用し、通常の呼関係制御によって選択されたオブジェクト全てと通信を確立する。これにより、「お客ーお客」、「店員ー店員」の対話を実現する。

図１０は上記の３つのモードによって、買物客用の端末でどのように表示が行なわれるかを示している。図１０（ａ）は“決め買いモード”での表示であり、他のお客は全く見ずに済む。図１０（ｂ）は“活気実感モード”での表示であり、他の１つの人混みオブジェクトとして見え、お店の人気具合を感じることができる。図１０（ｃ）は“通常通信モード”であり、店に集まっているお客全てと対話が可能になっており、個人個人を識別できる。

図１１は“活気実感モード”での”人混みオブジェクトの生成処理のフローチャートである。初めに店舗オブジェクトを呼関係候補リストから選び（S81）、店舗の座標をもとに、例えば“半径ｒ以内”のような範囲基準で、お客オブジェクトの数を数える（S82)。つぎに、その数に応じた“人混み図形”を選択し（S83）、端末に表示する。この人混みオブジェクトはローカルなものなので、バーチャルマーケットマップ管理装置には通知は行なわない(S84)。

この３つのモードは動的に変更もしくは混在可能で、例えば、“決め買い”が終ったので町をブラついたり、人混みオブジェクトの中の特定のオブジェクトを分離して通信路確立したりすることも可能である。図１２は人数に応じた人混み図形の例を示し、人数を直観的に感じることができる。

次に、お店の方の立場からの対話を考え、お店や商品の宣伝をお客の合わせて効率的に行なう手段について説明する。

図１３は店員と店舗オブジェクトの一実現形態であり、店員用端末の利用者オブジェクト１１０と店舗オブジェクト１１１から構成される。店員用の利用者オブジェクト１１０では、呼関係候補リストと店舗オブジェクトが持つ顧客データ１１３から客層分離部１１６で客層を分類し、その分類の従って、宣伝広告の内容を制御し、広告通知部１１７を介して呼関係を結んだ各買物客オブジェクトに自動的に発送する。

図１６に広告データ１１２の一例を示す。ここでは、例えば、特売品、取扱商品一覧、お店の紹介などその性質でいくつかに分類された形になっている。また、通常の商談は通信を介して直接、買物客と店員の間で行なわれる。

店舗オブジェクト１１１は顧客データ１１３、商品データ１１４、店舗データ１１５などで構成される。商品データ１１４は品物在庫などが管理され、店舗データ１１５はグラフィック表示用のデータが格納されている。

図１４には広告通知処理のフローチャートを示す。初めに広告データを読み込み(step111)、呼関係候補リストの中から、新たに来店したお客オブジェクトを抽出する(step112 〜step113）。抽出した各オブジェクトと顧客データとを比較しお客の常連の度合を求める。図１７に顧客データの一例を示す。ここでは、利用回数や利用金額などのデータから顧客の重要度をある評価関数を用いて計算し、常連の度合としている。

度合がある閾値を越え、“常連”と判断されると、その買物客には、例えば特売品のデータのみを発送するので、お客が既知であると判断できるような無駄なデータを送らずに済む。また、”来店経験が有る”程度と判断されると、特売品と一般商品の広告を発送する。全く新規のお客にはより多くの広告を出して、顧客を広げることを支援する。

さらに、より詳細に顧客データを分析して、お客の傾向に合わせて、広告を制御することも可能である。

また、本実施では、常連の度合に応じて制御を行なったが、例えば、呼関係候補リストが持つ属性として、性別、年齢、家族構成なども持てば、これらの情報を用いて制御を行なう事ももちろん可能である。そして、これらの広告は、買物客の方で広告の受理・拒否を制御する事ができ、興味のない広告を受け取らずに済むこともできる。

図１５は、買物客が店に近付いた時に受けとる広告の様子を示している。図１５（ａ）は”常連”客の表示、（ｂ）は来店経験が有る客の表示、（ｃ）は新規のお客に対する表示であり、それぞれ広告の内容が異なる。

上記第２の実施例の発明によれば、第１の実施例で実現できる動的なコミュニケーション部をつかって仮想的な市場を実現でき、その市場の性質に適合した呼関係制御部を用いることで、仮想市場における効率的なコミュニケーションや広告の部を提供できる。
図１８を参照して第３の実施例を説明する。この実施例によると、センター局のキー情報持部には、オブジェクトの属性の一つとして、仮想３次元空間に於けるオブジェクトの位置と大きさが保持されているものとする。

オブジェクトＡは、システム利用者にシステムの状況を表示し、利用者からオブジェクトに対する指示を受取る為のＧＵＩを有する。又、他のオブジェクトと呼関係を結ぶ前に参照すべき情報を格納する呼関係制御情報格納部を有する。

オブジェクトＢは、言わば「待ちオブジェクト」である。オブジェクトＢのキー情報登録部は、オブジェクトＢをセンター局に登録する際にのみ用いられ、後は他のオブジェクトから通信の要求が来るのを待っている。

オブジェクトＣは、「自走オブジェクト」であり、３次元空間でのオブジェクトＣの位置を一定時間ごとに更新する位置更新部ＰＵを有している。

オブジェクトＢとオブジェクトＣとは、同一の利用者端末Ｔ´上にある。

次に、オブジェクトＡの各部の動作を説明する。

システム利用者が、ＧＵＩを操作してシステムにログインする様に指示する。ＧＵＩは、キー情報登録部ＫＲに対して、オブジェクトのネットワーク・エントリとオブジェクトの属性とを、センター局に登録する様に指示する。ここでは、オブジェクトの属性として、オブジェクトの３次元空間内の位置と大きさ、利用者端末の所在地域が含まれているものとする。

キー情報登録部ＫＲが登録を終えると、ＧＵＩは呼関係候補要求部ＣＲに３次元空間内の位置に基づく呼関係を要求する様に指示を出す。呼関係候補要求部ＣＲはセンター局に３次元空間内の位置に基づく呼関係候補を通知するよう要求を出す。

センター局から通知される呼関係候補のネットワーク・エントリとその属性は、呼関係候補格納部ＣＳに格納される。呼関係候補格納部ＣＳは、呼関係候補の更新を、呼関係制御部ＣＣに通知する。呼関係格納部ＣＯＳは現在締結中の呼関係を格納しているが、ログイン時には、当然、呼関係格納部ＣＯＳには呼関係が格納されていない。呼関係制御部ＣＣは、呼関係格納部ＣＯＳに格納されている呼関係を検索し、特定の呼関係が結ばれているか否かを調べる事ができる。

呼関係制御情報格納部ＣＩは、現在呼関係締結が禁止されているオブジェクトを格納している。それは、オブジェクトのネットワーク・エントリで指定されている場合もあり、オブジェクトの属性で指定されている場合もある。オブジェクトの属性で指定されているとは、即ち「或る属性を有する（有しない）オブジェクトとは呼関係を結ばない」と言う事である。呼関係制御情報格納部ＣＩに格納される呼関係制御情報は、利用者が設定したものである。呼関係制御部ＣＣは、呼関係制御情報格納部ＣＩに格納されている呼関係制御情報を検索し、特定の呼関係の締結が許可されているか否かを調べる事ができる。利用者が呼関係制御情報を適切に設定することで、呼関係制御情報設定部を次の様に活用することができる：ｉ）仕事でシステムにアクセスする際に、私的な交遊関係の知人・友人とは呼関係を結ばない様にする，ｉｉ）以前に出会った好ましくない人物とは一定期間呼関係を結ばない様にするなどがある。

呼関係制御部ＣＣの動作は図３ないし図６に示すフローチャートと同様である。即ち、画像（音響）情報格納部ＩＷ（ＳＷ）は、オブジェクトに関係する画像データ（音響データ）を格納し、ネットワークを通じたアクセスに応じて、格納しているデータを送信する。

画像（音響）情報読取り部ＩＲ（ＳＲ）は、呼関係制御部ＣＣから与えられる画像（音響）情報格納部ＩＷ（ＳＷ）のネットワーク・エントリから、画像（音響）データを読み出す。呼関係制御部ＣＣが画像（音響）情報読取り部ＩＲ（ＳＲ）に対してデータ読取り中止を指示したとき、画像（音響）情報読取り部ＩＲ（ＳＲ）は、読取り中であれば読取りを中止し、画像（音響）情報格納部ＩＷ（ＳＷ）との接続を切断する。読取り中でなければ何も行わない。画像情報読取り部ＩＲは読み取った画像データをＧＵＩに送り、ＧＵＩがそれを表示する。音響情報読取り部ＳＲが読み取った音響データは、利用者端末の音響データ再生装置に送られ、そこで再生される。

オブジェクトＢおよびＣの各部の動作は、オブジェクトＡの各部の動作と同様である。ただし、オブジェクトＣは、一定時間ごとに３次元空間上のオブジェクトの位置を更新する位置更新部ＵＰを有している。位置更新部ＵＰは３次元空間の位置というオブジェクトの属性を変更し、新たな属性をセンター局に登録するよう、キー情報登録部に指示を与える。次いで、呼関係候補要求部ＣＲに対して、新たな呼関係候補を要求するように指示を与える。位置の変化によって、呼関係を結ぶべきオブジェクトは変わっている筈だからである。

オブジェクトＡにおいて、利用者がＧＵＩを通して位置を変更した場合も、同様に呼関係を更新しなければならない。この手続きは、オブジェクトＣとまったく同様に、キー情報登録部ＫＲに次いで呼関係候補要求部ＣＲに対する指示で実現される。

センター局の各部の動作を説明する。

キー情報保持部は、オブジェクトのキー情報登録部から送られるネットワーク・エントリと属性とを図１９の様なリストで保持する。検索と登録の便を計るため、幾つかの一般的な属性に関しては、ハッシュ・テーブルを作成する。呼関係候補決定部は、オブジェクトの呼関係候補要求部ＣＲからの要求に応じて、キー情報保持部のリストを検索し、当該オブジェクトに関する呼関係候補を決定し、それを呼関係候補通知部に送る。呼関係候補要求部ＣＲからの要求は、例えば、次の様な形で与えられる。

ＧＥＴＮＢ オブジェクト名，（３ｄ，ｄ）
ＧＥＴＮＢ オブジェクト名，（３ｄ，ｄ），（ｌｏｃ，Ｔ市）
ｄは実数である。初めの要求は、仮想３次元空間において、当該オブジェクトの中心から距離ｄ内にある呼関係候補を与える様要求している。後の例では、それに加えて、端末所在地域がＴ市である様な呼関係候補オブジェクトを要求している。

呼関係候補通知部は、呼関係候補決定部から送られた呼関係候補のリストを、属性付きで当該オブジェクトの呼関係候補格納部ＣＳに転送する。

以上に述べた実施例のシステムによって、オブジェクトのＧＵＩは、例えば図２０の様な形でネットワーク資源を提示する事ができる。オブジェクトＣは、二階建ての家の様な施設であり、オブジェクトＢはどうやら亀らしきものであると言うことが分かる。さらに、利用者端末Ｔのスピーカーから、家の中から聞こえてくるピアノの音と、何やらぶつぶつと言う亀の呟きが再生される。

端末Ｔのシステム利用者が、端末所在地がＴ市であるオブジェクトのみを表示したいと考えた場合、ＧＵＩを通じて、呼関係候補要求部ＣＲに対して、上記二番目のＧＥＴＮＢコマンドを発行する様に指示すれば良い。或いは次の様な方法を用いる事も可能である。即ち、呼関係制御情報格納部ＣＩにＴ市にあるオブジェクトのみ表示する様に呼関係制御情報を設定する。次に、呼関係制御部ＣＣに対して、呼関係格納部ＣＯＳに格納されている呼関係をスキャンして呼関係制御情報が満たされているか否かのチェックを行い、制御情報を満足しない呼関係を切断する様に指示する。この方法によれば、センター部にアクセスする事なく、所望の表示が容易に得られる。

次に、第４の実施例を説明するが、この実施例によると、ネットワーク利用者やネットワークに接続されているオブジェクトは, 各々他のネットワーク利用者やオブジェクトからネットワーク・コミュニケーションを通じて何らかの情報を得たいと考えている. 或は, 何らかの知識或は与えたい情報を有しており, ネットワーク・コミュニケーションを通して, それを他のネットワーク利用者やオブジェクトに与えたいと考えている. オブジェクトＡのキー情報登録部がセンター局に登録する属性の一例を次に挙げる。

(KNOW (数学 (幾何学 (位相多様体 (ホモロジー論, ホモトピー論)))))、
(KNOW (数学 (計算機数学 計算量の理論)))、
(ASK (計算機 (数値解析 (構造解析, 多変量解析))))、
(INTEREST (音楽 (クラシック音楽 (モーツァルト(ロマン派 ブラームス)))))
即ち, このオブジェクトは, 数学の中で幾何学と計算機数学の知識を有し, それを公開する用意がある. 数学については, 幾何学特に位相多様体のホモロジー論とホモトピー論に関する知識がある。 又計算機数学に関しては, 計算量の理論に関する知識を有している。更に、このオブジェクトは計算機に関する知識を求めている。必要としているのは、数値解析の中で構造解析と多変量解析に関する知識である。又、このオブジェクトは (即ち, このオブジェクトを通じてネットワークにアクセスしている利用者は)クラシック音楽に興味を持っており、モーツァルトとロマン派、就中ブラームスを好む.
他のオブジェクトＡ’の呼関係候補要求部から鍵管理装置に対して次の様なGETNB コマンドが発行されたとする。

GETNB オブジェクト名、(ASK (絵画 印象派))、 (INTERST モーツァルト)(INTEREST モーツァルト) によって、オブジェクト Ａ’がモーツァルトに興味を有している事が分かるからセンター局の呼関係候補決定部はオブジェクトＡを含む呼関係候補を求め、呼関係候補通知部が、それをオブジェクトＡ’に通知する。従って、第３の実施例に記述した仕組みにより、オブジェクトＡ’とＡとの間に呼関係が成立する。呼関係通知部は、オブジェクトＡの登録属性も送るので、オブジェクトＡ’の呼関係候補格納部には、上記のオブジェクトＡの属性が格納されている。オブジェクトＡ’の利用者は、適宜それを参照し、例えば、オブジェクトＡが構造解析に関する知識を求めている事を知る事ができる。オブジェクトＡ’の利用者は、構造解析の専門家を知っているので、その人物へのアクセスの方法をオブジェクトＡに知らせる事ができる。

上記第３及び第４の実施例によるコミュニケーション・ナビゲーション・システムによれば, リアルタイムで変化するネットワーク資源を, センターに過大な負荷を懸けることなく,様々な視点で提示する事ができる. しかも、その視点は、各利用者の便宜に応じて任意にかつ容易に切替える事が可能である.
図２１を参照して第５の実施例を説明する。この実施例によると、オフィスサーバ２０１とユーザ作業環境２１１に大きく分かれており、この２つの間はコンピュータネットワークで交信を行なう。オフィスサーバ２０１はモデルサーバ２０４と位置サーバ２０８で構成される。モデルサーバ２０４はレイアウト送信部２０５と出退勤管理部２０６からなり、この２つは仮想オフィスモデル２０２と勤務データ部２０３とで情報をやりとりする。また、位置サーバ２０８はユーザ情報制御部２０９と近接ユーザ送信部２１０からなり、位置データベース２０７とのやりとりを行なう。

オフィスデータ管理部２１２はネットワークを介してレイアウト送信部２０５からオフィスのデータを受けとり、ユーザインターフェース２１７で利用者にグラフィカルに表示を行なう。ユーザデータ管理部２１３は、利用者の操作を管理し、ネットワークを介して出退勤管理部２０６へログインしたり、社員に関するデータをレイアウト送信部から受け取ったり、また仮想オフィス内の移動情報をユーザ情報制御部２０９に送り、更新された近接データをユーザ送信部２１０から受けとる。さらに、他の勤務者との通信の管理も行ない、これらの情報と人物イメージデータ２１４を基に、ユーザインターフェース２１７で利用者にグラフィカルに人物の表示を行なう。またユーザデータ管理部２１３は視点による見え方の変化が生じた場合はオフィスデータ管理部２１２へ視点に関すデータを送り、オフィスデータ管理部はその変化を画面に反映させる。

ユーザ作業ファイル２１５および２１６は利用者の本来の業務に必要な作業用のファイルであるユーザ作業環境２１１でローカルに持っていたり、ネットワークを介して持っていたりできる。

以下、図２１の各部分について説明を行なう。

図２２は、図２１における仮想オフィスモデル２０２の例である。仮想オフィスモデルは３次元のグラフィカルなデータが階層的に表現されているレイアウトデータ２２１とオフィスでの勤務のルールを記述した勤務ルール２２２と社員の仮想オフィスでの座席に関する社員データ２２３で構成されている。これらのデータはモデルサーバ２０４で使用される。

図２３は、図２１における勤務データ２０３の例を示しており、仮想オフィスに対する遠隔勤務に関する情報が記述されている。このデータは出退勤管理部２０６で管理される。

図２４は、図２１における出勤管理部２０６の処理フローチャートであり、利用者がネットワークを通じてオフィスサーバ２０４へログインしてくると(S401)、社員データ２２３と照合を行なう(S402)。社員であれば(S403)、レイアウト送信部２０５へ「出社」を通知し(S404)、勤務データ２０３にログインの時刻を記録する(S405)。その後、利用者がログアウトすると、その時刻を勤務データ２０３に記録する(S407)。

図２５は、図２１におけるレイアウト送信部２０５の処理フローチャートであり、出退勤管理部２０６から「出社」のメッセージを受けると(S501)、仮想オフィスモデル２０２からレイアウトデータ２２１を取りだし、利用者の環境が持つオフィスデータ管理部２１２へ送信する(S503)。同時に社員データ２２３をユーザデータ管理部２１３へ送信する(S504)。

図２６は、図２１におけるユーザ情報制御部２０９の処理フローチャートである。ユーザ情報制御部２０９はユーザデータ管理部２１３から利用者の仮想オフィス上での位置データまたはログアウト情報を受けとる(S601)。利用者が「出社」した場合は、以前の位置データがあるかがチェックされ（S602)、初期値として位置データを生成し(S603)、近接ユーザデータも生成する(S604)。利用者が仮想オフィス上で位置を変更したかがチェックされ(S605)、変更した場合は、位置データを更新し(S606)、近接ユーザデータも更新する(S607)。利用者がログアウトしたかがチェックされ(S608)、変更した場合は、位置データと近接ユーザデータを消去する(S609-S612)。これらのデータの変化を位置データベース２０７に反映させる。

図２７は、図２１における近接ユーザ送信部２１０の処理フローチャートである。近接ユーザ送信部２１０は位置データベース２０７が更新されたどうかを監視しており(S701)、更新があった場合、位置データを更新したユーザに新たな近傍データをネットワークを介して送信し(S702)、他の勤務者の中で近傍データの更新を受けたユーザ全てに新たな近傍データを送信する(S703)。位置データベースが更新されない場合には、サーバ停止命令の有無がチェックされ(S704)、命令があれば、処理が終了し、なければ、ステップＳ７０１に戻る。

図２８は、図２１における位置データベース２０７のデータ例である。位置データベース２０７は位置データ２８０と近傍データ２８１で構成されている。位置データ８２０は勤務者のネットワーク上のアドレス、仮想オフィス上の座標データ、勤務者の近傍データ名が記述されており、近傍データ２８１は勤務者の近傍に存在する全ての勤務者の仮想オフィス上の座標とネットワーク上でのアドレスが記述されている。このデータは位置の更新や「出社」、「退社」などのイベントがあるたびに、ユーザ情報制御部２０９によって更新される。

図２９は、図２１におけるオフィスデータ管理部２１２の処理フローチャートである。オフィスデータ管理部２１２はレイアウト送信部２０５からレイアウトデータを受けとると(S901)、利用者に指定された表示方法にデータを変換して表示する(S902-S906)。その後、ユーザデータ管理部２１３からの視点の変化に関するメッセージに即して仮想オフィスの表示を変更する(S907-S910)。

図３０は、図２１におけるユーザデータ管理部２１３の処理フローチャートである。ユーザデータ管理部２１３はユーザがいろいろなイベント毎にそれぞれの処理を行なう。即ち、入力イベントの有無が確認され(S1001)、これがＹＥＳであると、ステップＳ１００２、Ｓ１００４，Ｓ１００６，Ｓ１００８，Ｓ１０１０，Ｓ１０１２およびＳ１０１４の確認処理が順次行われ、これら処理に対応する処理Ｓ１００３，Ｓ１００５，Ｓ１００７，Ｓ１００９，Ｓ１０１１、Ｓ１０１３およびＳ１０１５が実行される。イベントがない場合には、近傍データの更新の有無が確認され（S1016)、ＹＥＳで更新の表示が行われる(S1017)。

図３１は、図３０におけるログイン処理S1003の処理フローチャートである。ログインイベントを受けとると、人物イメージデータ２１４から人物イメージを取り出し、社員データ２２３を基にして仮想オフィス内に表示する(S1101)。ユーザステータスの値を他の勤務者と交信可能な「Normal」にセットし(S1102)、位置データをユーザ情報制御部２０９に送信する(S1103)。新たに生成された近傍データを近接ユーザ送信部より受け取り(S1104)、仮想オフィスに近傍ユーザを表示する(S1105)。

図３２は、図３０における位置変更処理S1005の処理フローチャートである。位置変更イベントを受け取ると、位置データをオフィスデータ管理部２１２に視点の変更として送り(S1201)、同時に位置データをユーザ情報制御部２０９に送信し、更新された近傍データを近傍データ送信部２１０より受け取り画面に反映する(S1202-S1204)。

図３３は、図３０におけるユーザステータス処理S1007の処理フローチャートであり、指定されたユーザステータスに再設定すると(S1301)、例えばユーザステータスの値を「対話不可」に設定すると、他の人との対話を拒絶でき、逆に「Nor-mal」にしておくと、現在対話可能であることを他の人に宣言できる。また、対話中は自動的に「対話中」となる。また、対話中は第３者の参加を認める「（参加可）」と参加を認めない「（参加不可）」の属性を与えることができる。

図３４は、図３０における視点変更処理S1009の処理フローチャートであり、これによると、ステップＳ１４０１では、仮想オフィスへの位置の移動を伴わない視点の変更をオフィスデータ管理部２１２に送信する。

図３５は、図３０における近接ユーザ状態一覧処理S1011の処理フローチャートである。このイベントにより、現在の近傍ユーザのユーザステータスの値をネットワークを通じて各ユーザ作業環境に問い合わせを発し(S1501)、その値を画面に表示する(S1502)。

図３６は、図３０における近接ユーザとのアクセス処理S1013の処理フローチャートである。この処理において、ステータスの値の要求の有無が確認され(S1601)、要求があれば、その値を送る(S1602-S1604)。要求がなければ、外部からの対話要求が来ているかが確認され(S1605)、これがＹＥＳであれば、ステータスが「対話不可」または「対話中（参加不可）」が順次確認され(S1606, S1607)、これらステップＳ１６０６およびＳ１６０７がＹＥＳであれば、要求の有無のみを通知し(S1608)、そうでなければ、対話が開始される(S1613-S1618)。逆に、自分から他のユーザへのアクセスをした場合(S1609)、同様に、相手のステータスが「対話不可」または「対話中（参加不可）」が確認され(S1610, S1611, S1612)、これがＹＥＳであれば、要求の有無のみを通知し(S1613)、そうでなければ、同様に対話が開始される。なお、対話中に第三者の参加の合否を決めることができ(S1615-S1614)、対話を制御できる。

図３７は、図３０におけるログアウト処理S1015の処理フローチャートであり、これによると、ステップＳ１７０１，Ｓ１７０２およびＳ１７０３においてログアウトのメッセージを出退勤管理部２０６、オフィスデータ管理部２１２およびユーザ情報制御部２０９に送信する。

図３８は、本発明によって実現される仮想オフィスの表示例を示しており、この例では、現在４名が勤務中であり、ユーザであるＦと同僚のＣとが対話中であることを示している。

図３９は、本発明によって実現される遠隔勤務の様子を示す図であり、仮想的なオフィスの中で勤務している同僚の様子が分かり、遠隔でも同僚が勤務している事が実感でき、公私の切り替えをつけるために心理的な効果が得られる。また、Ｂ主任のように自分の現在ステータスをセットすることで会話を制御し、重要度や緊急度の低いものを排除できる。

次に、図４０を参照して第６の実施例を説明する。図４０は、図２１における近接ユーザ送信部２１０の処理および近傍データ２１８をユーザ作業環境２１１に持たせた実施例を示しており、図４１はユーザ情報制御部２０９で実行される処理のアルゴリズムを示し、図４２は近接ユーザ送信部２１０で実行される処理のアルゴリズムを示している。

第５の実施例では、個人端末の処理能力が低く、オフィスサーバが高性能を持った計算機である場合に適した構成であり、位置データベース２０７が一元的にデータを管理し、データの更新は全てサーバを介して各ユーザに反映する集中型の構成である。それに対し、この第６の実施例では、個人端末の処理能力が高く、オフィスサーバが極端に高性能ではない計算機である場合に適した構成であり、位置データのみを一元的に管理し、近接ユーザデータの更新は各ユーザ間での通信によって反映する分散型の構成である。

上記第５及び第６の実施例によると、仮想的なオフィスのイメージを勤務者の視点に合わせて表示し、その中に自分の近傍で勤務している同僚の様子を表示することによって、遠隔でも同僚が勤務している事が実感でき、公私の切り替えをつけるために心理的な効果をユーザに与える事ができ、自分の現在状態をセットし、その情報を用いて同僚との会話を制御することで重要度や緊急度の低いものを排除することができ、効率的な勤務を行う環境を提供できる。

図４３及び図４４を参照して第７の実施例を説明する。この実施例においては、図４３に矢線で示すように、オブジェクト間で呼関係が成立する。即ち、オブジェクトから呼関係管理装置に向かう矢線は呼関係の登録を示し、呼関係管理装置からオブジェクトに向かう矢線は呼関係の通知を示している。図４４には、オブジェクトと呼関係管理装置の構成が示されている。これによると、オブジェクトが他のオブジェクトと呼関係を確立すると、呼関係登録部が呼関係管理装置の呼関係取得部に対して呼関係を登録する。この実施例では、通信を求めたオブジェクトが呼関係を登録するものとする。無論、通信要求を受理したオブジェクトが呼関係を登録しても良い。

呼関係の登録には、例えば、次のような文字列を呼関係取得部に送信する。即ち、register（Ａ，Ｘ，０）。Ａは通信を求めたオブジェクトのオブジェクトＩＤであり、Ｘは通信関係の確率を受理したオブジェクトのＩＤである。最後の０はセキュリティレベルが０であることを表している。呼関係管理装置の呼関係取得部は新規に取得した呼関係を呼関係格納部に格納する。

オブジェクトＡがオブジェクトＸとの呼関係を解消したときの動作は、次のようになる。即ち，Ａの呼関係登録部がＸとの呼関係の解消を呼関係管理装置に通知する。具体的には、文字列delete（Ａ，Ｘ）を呼関係取得部に送信する。呼関係取得部は呼関係格納部に格納されているＡとＸとの間の呼関係情報を消去する。

本発明では、呼関係の解消を呼関係装置に通知するのは、呼関係を解消したオブジェクトの側としているが、呼関係を解消された側で通知を行っても良い。

次に、オブジェクトのコミュニケーション・モニタが呼関係を表示する際の動作を説明する。

まず、呼関係要求部が呼関係管理装置に対して呼関係を要求する。具体的には、文字列reg（Ａ、＜＝、１）を呼関係要求受理部に対して送信する。ここに、Ａは要求を出すオブジェクトのＩＤであり、残りの引数によって、セキュリティレベルが１以下の呼関係を通知するように要求している。オブジェクトからの要求は呼関係受理部から呼関係検索部に送られる。呼関係検索部は呼関係格納部の中から要求に応じた呼関係（群）を見出し、それを呼関係通知部に転送する。呼関係通知部は要求を出したオブジェクトの呼関係入力部に呼関係のリストを送信する。それは、例えば次のような文字列として表現されている。

（Ａ，Ｂ，０）；（Ａ，Ｃ，０）；（Ａ，Ｄ，０）；（Ｃ，Ｄ，０）
（Ｘ，Ｙ，０）；（Ｘ，Ｚ，０）；（Ｙ，Ｚ，０）；（Ｙ，Ｗ，０）
オブジェクト内のコミュニケーションモニタの呼関係表示部が呼関係入力部が受け取った呼関係リストを表示する。

呼関係表示部の表示例が図４５に示されている。これは、上記呼関係リストの表示を示している。即ち、Ａ，Ｃ，Ｄ間の会話は三者間で呼関係が全結合であるため、お互いの話を聞くことができるが、Ｃ，Ｄの話を聞くことができない。このことに注意を喚起するために、Ｂ，Ｃ間及びＢ，Ｄ間は点線によって結ばれている。また、Ｙ，Ｗ間の通信はセキュリティレベルが１であり、セキュリティレベルが０である他の通信と区別される。このことは、図４５では、Ｙ，Ｗ間の二重線で示されている。

上記の実施例によると、ネットワークに接続されているオブジェクトがリアルタイムで変化するネットワーク内の呼関係を必要に応じて取得し、例えば他のオブジェクト間の呼関係をアクセスする等、呼関係情報を積極的に利用することができる。

次に、図４６を参照して第８の実施例を説明する。

この実施例によると、センター局３０１には予め複数の利用者端末３０４、３０５、３０６、３０７からキー情報３０２が入力され、キー情報３０２はメモリ３０３に保持されている。ここで、キー情報３０２とは、例えば図４７に示すように、利用者のある２次元仮想空間Ａでの位置、別の１次元仮想空間Ｂでの位置、スポーツへの興味の度合い、音楽への興味の度合い、その他の趣味、職業などである。そしてそれらの鍵は利用者毎に番号が割り振られ、その利用者が用いる端末のアドレスとともに保持されている。

図４６に戻り、利用者は他の端末のいずれかと接続したい場合には、端末３０４を操作して、まず呼関係候補要求部３０９から同要求信号３０８をセンター局３０１に送信する。センター局３０１の中にある呼関係候補決定部３１０は、要求信号３０８に含まれている端末３０４のアドレスから、メモリ３０３を参照することにより、端末３０４の登録番号を検知する。次に、所定のキー情報において、端末３０４と近い値を持つ他の端末をメモリ３０３の中から見つけ、それらのアドレス３１１が呼関係候補通知部３１２を介して端末３０４に知らせる。

端末３０４と近いものを見つけるアルゴリズムが図４８に示されており、これによると、まず初めに、ステップＳ３１３において、メモリ３０３を参照することにより、端末３０４のアドレスから要求者の登録番号を検知し、その番号をここではｎｒとする。次に、番号に関する変数ｎをゼロにセットし、続いてｎに１を加える。ｎがｎｒと異なる場合にステップＳ３１４において、所定のキー情報αiのｎの値αi（ｎ）とαi（ｎｒ）距離ｈを求める。この距離ｈは例えばαiが空間の位置ならば通常のユークリッド距離を用いればよいし、スポーツへの興味の度合いといったものなら、その値の差でよい。また、趣味や職業といった数値で与えられていないものの場合は予め決めておく遠近の決まりに基づき距離を決定する。そして、その距離ｈがしきい値Ｔよりも小さい場合はｎのアドレス３１１を出力し、これは上述した様に端末３０４に送られる。この手順をｎが登録件数Ｎに達するまで行うことにより、キー情報αiにおいて端末３０４と近い端末のアドレス３１１を全て見つけることができる。

図４７において、仮に端末３０４が番号１、空間Ｂでの呼関係の要求、Ｔ＝５００の場合は番号２と３のアドレス「００１０」と「０１０１」が端末３０４に通知される。Ｔよりも近くにいる人が多すぎる場合には、距離の小さなものを優先したり、ランダムにまびいた残りを端末３０４に通知すればよい。

図４６に戻り、端末３０４はアドレス３１１を一時的にメモリ３１５に格納する。呼関係制御部３１６を介してアドレス３１１を発し、これにより端末３０４と他の端末の通信が開始する。ここで通信を行いたくない他の端末がある場合は、予め制御部３１６に登録しておけば、たとえアドレス３１１にその端末が含まれていたとしても、それを除くことができる。

距離の決定に用いるキー情報αiはセンター局３０１が適当に決めてもよいし、端末３０４が要求信号３０８に含めて指定してもよい。また、利用者が、ある特定の端末及びその周辺の端末と通信したい場合には、その通信したい端末のアドレスを要求信号３０８に含めてセンター局３０１に通知する。決定部３１０ではｎｒの他に、端末３０４から通信を希望されているアドレスからその番号ｎｐを求める。

次に、図４９に示すようにキー情報の種類を意味する変数ｉをゼロにセットし、これを１ずつ加算しながら、αi（ｎｐ）とαi（ｎｒ）の距離を求める。その距離がしきい値Ｔよりも小さくなった時点でαiを決定し、あとは図４８に示したアルゴリズムと同じようにして、アドレス３１１を決定する。全てのｉにおいて、距離がＴよりも小さくならなかった場合は、アドレス３１１の代わりにその旨を端末３０４に伝える。

利用者はキー情報を指定することにより、例えば仮想空間で近くにいる人達、あるいは、自分と趣味が近い人達などと通信をすることができる。また、特定の相手のアドレスを指定することにより、その人が必ず含まるように何人かの人達と通信できる。あるいは、端末側からは何も指定をしない場合は、センター局３０１が適当にキー情報を決めることにより偶然の出会いが可能となる。この場合も利用者とは何らかのキー情報で近くにいる人達と通信ができる点はキー情報を利用者が指定する場合と同じであり、全く何の関連もない人と通信してしまうことはない。

本発明一実施例に係るシステムの全体構成を示す図。 図１のオブジェクトの組合せによるシステムの構成を示す図。 呼関係制御のアルゴリズムを示す図。 呼関係制御のアルゴリズムを示す図。 呼関係制御のアルゴリズムを示す図。 呼関係制御のアルゴリズムを示す図。 バーチャルマーケットにおけるオブジェクト構成を示す図。 オブジェクトのデータベース例を示す図。 買物客ようのオブジェクトの構成を示す図。 モードによる表示の違いを示す図 人混みオブジェクトの生成アルゴリズムを示す図。 人数別の人混みオブジェクトの表示例を示す図。 店員オブジェクトおよび店舗オブジェクトの構成を示す図。 広告通知処理のアルゴリズムを示す図。 常連の度合別による表示の違いを示す図 広告データの例を示す図。 顧客データの例を示す図。 この発明の他の実施例に従ったコミュニケーション・ナビゲーション・システムのブロック図。 ネットワーク・エントリと属性との関係を示すリストを示す図。 ネットワーク資源を示す図。 システムの全体構成を示す図。 図２１における仮想オフィスモデル２０２の例を示す図。 図２１における勤務データ２０３を示す図。 図２１における出勤管理部２０６の処理フローチャート図。 図２１におけるレイアウト送信部２０５の処理フローチャート図。 図２１におけるユーザ情報制御部２０９の処理フローチャート図。 図２１における近接ユーザ送信部２１０の処理フローチャート図。 図２１における位置データベース２０７のデータ例を示す図。 図２１におけるオフィスデータ管理部２１２の処理フローチャート図。 図２１におけるユーザデータ管理部２１３の処理フローチャート図。 図３０におけるログイン処理Ｓ１００３の処理フローチャート図。 図３０における位置変更処理Ｓ１００５の処理フローチャート図。 図３０におけるユーザステータス処理Ｓ１００７の処理フローチャート図。 図３０における視点変更処理Ｓ１００９の処理フローチャート図。 図３０における近接ユーザ状態一覧処理Ｓ１０１１の処理フローチャート図。 図３０における近接ユーザとのアクセス処理Ｓ１０１３の処理フローチャート図。 図３０におけるログアウト処理Ｓ１０１５の処理フローチャート図。 仮想オフィスの表示例を示す図。 遠隔勤務の様子を示す図。 図２１における近接ユーザ送信部の処理と近傍データをユーザ作業環境に持たせたコミュニケーション・ナビゲーション・システムを示す図。 ユーザ情報制御部で実行される処理のアルゴリズムを示す図。 近接ユーザ送信部で実行される処理のアルゴリズムを示す図。 オブジェクト間の呼関係を示す図。 オブジェクトと呼関係管理装置の構成を示す図。 呼関係表示部の表示例を示す図。 他の実施例に従ったコミュニュケーション・ナビゲイション・システムのブロック図。 キー情報を示す図。 端末３０４と近い端末を見つけるアルゴリズムを示す図。 端末３０４と近い端末を見つけるアルゴリズムを示す図。

符号の説明

１…センター局、２…利用者端末局、３…静的資源オブジェクト、４…動的資源オブジェクト、１１…キー情報保持部、１２…呼関係候補決定部、１３…呼関係候補通知部、２１…キー情報登録部、２２…呼関係候補要求部、２３…呼関係候補格納部、２４…呼関係制御部、２５…マルチメディア情報制御部。

Claims (6)

1. ネットワークに接続されている複数の計算機上のオブジェクト間の呼関係を管理する呼関係管理装置であって、
   前記オブジェクト間の呼関係を取得する呼関係取得手段と、
   各オブジェクトを頂点とし、オブジェクトの呼関係を辺とするグラフを格納する呼関係格納手段と、
   各オブジェクトからの要求に応じて前記呼関係格納手段に格納されているグラフの全体又は一部を当該オブジェクトに対して転送する呼関係通知手段と、
   を備えたことを特徴とする呼関係管理装置。
2. 前記呼関係取得手段が通信周波数帯域やセキュリティレベルなどの呼関係属性を取得し、前記呼関係格納手段が呼関係属性を併せて格納し、前記呼関係通知手段が呼関係系属性をも併せて通知することを特徴とする請求項１の呼関係管理装置。
3. ネットワークに接続されているオブジェクトが他のオブジェクトとの呼関係の成立又は解消に関する情報をオブジェクトの計算機から受信する手段を有することを特徴とする請求項１の呼関係管理装置。
4. ネットワークに接続されているオブジェクトが、他のオブジェクトとの呼関係の成立又は解消に関する情報と共に呼関係の属性に関する情報をオブジェクトの計算機から受信する手段を有することを特徴とする請求項１の呼関係管理装置。
5. オブジェクトの計算機から呼関係を取得する呼関係入力手段と、ネットワークに接続されている全ての或いは一部のオブジェクト群を表示すると共にオブジェクト群内の呼関係を表示する呼関係表示手段とを有することを特徴とする請求項１または３の呼関係管理装置。
6. オブジェクトの計算機から呼関係及び呼関係属性を取得する呼関係入力手段と、ネットワークに接続されている全ての或いは一部のオブジェクト群を表示すると共にオブジェクト群内の呼関係並びに呼関係属性を表示する呼関係表示手段を有することを特徴とする請求項２または４の呼関係管理装置。

Images