JPH09282276A

JPH09282276A - 情報管理システム

Info

Publication number: JPH09282276A
Application number: JP9721796A
Authority: JP
Inventors: Yuji Wada; 裕二和田; Akira Kawamura; 旭川村; Matsukeebu Furanshisu; マッケーブフランシス; Masatoshi Shiouchi; 正利塩内; Yoshiaki Teramoto; 良明寺本; Hiroshi Takada; 裕志高田
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1996-04-19
Filing date: 1996-04-19
Publication date: 1997-10-31

Abstract

(57)【要約】【課題】本発明は、ネットワークを利用して利用者情
報を管理する情報管理システムに関し、ネットワークを
利用した利用者の個人情報およびグループ情報を効率的
に管理し得るシステムを構築することを目的とする。【解決手段】利用者に対応づけて設け当該利用者の個
人情報および他の利用者との間のグループ情報を管理す
る分身と、この分身に対応づけてネットワーク上に設け
当該分身から通知された個人情報を一貫性を持って管理
すると共に、当該分身から通知されたグループ情報につ
いてネットワーク上の該当する他の本体と通信して当該
グループ情報を一貫性を持って管理する本体とを備える
ように構成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークを利
用して利用者情報を管理する情報管理システムに関する
ものである。

【０００２】

【従来の技術】計算機技術の発展に伴い、ネットワーク
で繋がった複数の計算機上で動作するシステムが開発さ
れるようになってきている。例えばネットワーク上でス
ケジュールを管理するシステムなどがこれに当たる。こ
のようなシステムを構築する場合、従来は、図１０に示
すように、全利用者のスケジュールを管理するためにサ
ーバを用意し、各利用者はサーバに対してクライアント
としてアクセスし、各スケッジュールなどを登録、更新
などすることが行われる。

【０００３】

【発明が解決しようとする課題】上述した図１０の従来
のサーバに全利用者がクライアントとしてアクセスし、
スケジュールを登録、更新などすると、以下のような問
題が発生する。

【０００４】（１）サーバに負荷が集中してしまう。
例えばスケジュール管理システムの場合、システム利用
者の全ての情報をサーバで集中管理し、各利用者の個人
のスケジュールや、更にミーティングなどの複数の利用
者で共有するスケジュールも管理することが可能となる
が、各利用者の個人スケージュルや共有するグループス
ケジュールのいずれも常にサーバにアクセスする必要が
生じてしまう。このため、多数の利用者でこのようなス
ケジュール管理システムを使用すると、個々の利用者の
サーバに対する負荷が小さくても、大規模なシステムの
場合にはサーバに負荷が集中して非常に重くなってしま
い、応答が遅くなってしまうという問題がある。

【０００５】（２）ネットワークの速度が遅い場合、
システムの動作速度が遅くなる。例えばスケジュール管
理システムの場合に、利用者が個人のスケジュールの登
録、更新などの場合でも、常にサーバにアクセスが必要
となり、通信容量が小さい通信路を用いてサーバと接続
していた場合や、ネットワークの負荷が非常に高い場合
には、システム自身の動作速度が遅くなってしまい、ネ
ットワークの速度に依存して遅くなってしまうという問
題がある。

【０００６】（３）サーバにアクセスできない環境で
は利用できない。例えば利用者の端末がサーバに接続で
きない情況（携帯端末がサーバと接続できない情況）の
場合には、スケジュールの登録、更新などができなくな
ってしまい、サービスを受けられなくなってしまう問題
がある。

【０００７】本発明は、これらの問題を解決するため、
利用者の分身に対応づけてネットワーク上に本体を設け
て当該利用者の個人情報を管理および他の利用者の本体
と通信してグループ情報を管理すると共に、分身が本体
と通信できないときは当該分身内で情報を保留し通信可
能となったときに本体に送信して管理し、ネットワーク
を利用した利用者の個人情報およびグループ情報を効率
的に管理し得るシステムを構築することを目的としてい
る。

【０００８】

【課題を解決するための手段】図１を参照して課題を解
決するための手段を説明する。図１において、分身１
は、利用者に対応づけて設け当該利用者の個人情報およ
び他の利用者との間のグループ情報を管理する端末であ
る。

【０００９】本体２は、分身１に対応づけてネットワー
ク３上に設け分身１から通知された個人情報を一貫性を
持って管理したり、分身１から通知されたグループ情報
についてネットワーク３上の該当する他の本体２と通信
して当該グループ情報を一貫性を持って管理したりなど
するものである。

【００１０】ネットワーク２は、本体２などが相互に情
報の授受を行うネットワークである。次に、動作を説明
する。

【００１１】利用者の個人情報および他の利用者との間
のグループ情報を管理する分身１を設け、この分身１に
対応づけてネットワーク３上に本体２を設け、当該本体
２に分身１から通知された個人情報を一貫性を持って管
理する手段および分身１から通知されたグループ情報に
ついてネットワーク３上の該当する他の本体２と通信し
て当該グループ情報を一貫性を持って管理する手段を持
たせるようにしている。

【００１２】この際、ネットワーク３上に設けた本体２
が対応する分身１に個人情報およびグループ情報を通知
して一貫性を保持させるようにしている。また、ネット
ワーク３上の本体２が該当する他の本体２にグループ情
報を通知して全ての本体２からグループ情報の更新のＯ
Ｋの旨の通知に対応してその旨を全ての本体２に通知し
て一貫性を持ってグループ情報を更新するようにしてい
る。

【００１３】また、分身１が対応する本体２と通信不可
のときに当該分身１内の個人情報あるいはグループ情報
を更新し、通信可となったときに変更分を本体２に通知
して当該本体２が一貫性を持って個人情報およびグルー
プ情報を管理しその一貫性を持たせた個人情報およびグ
ループ情報を分身２に通知して当該分身２内の個人情報
およびグループ情報の一貫性を保持させるようにしてい
る。

【００１４】従って、利用者の分身１に対応づけてネッ
トワーク３上に本体２を設けて当該利用者の個人情報を
管理および他の利用者の本体２と通信してグループ情報
を管理すると共に、分身１が本体２と通信できないとき
は当該分身１内で情報を保留して通信可能となったとき
に本体２に送信して管理することにより、ネットワーク
３を利用した利用者の個人情報およびグループ情報を効
率的に管理し得るシステムを構築することが可能とな
る。

【００１５】

【発明の実施の形態】次に、図２から図９を用いて本発
明の実施の形態および動作を順次詳細に説明する。

【００１６】図２は、本発明の分身の構成図を示す。こ
れは、図１の分身１の構成例である。図２において、通
信部１１は、ネットワーク３との間でデータの授受を行
うものであって、例えば後述する図８に示す通信パケッ
トを送受信するものである。

【００１７】制御部１２は、各種制御を行うものであっ
て、全体を統括制御するものである。入出力部１３は、
入出力装置１４との間でデータの入出力を行うと共に、
入出力するデータを制御部１２との間で受渡しするもの
である。

【００１８】入出力装置１４は、データを表示して利用
者に知らせたり、利用者がキーあるいは画面から入力し
たデータを取り込んだりなどするものである。記録部１
５は、入力されたデータやネットワーク３から受信した
データなどをファイルに記録データ１６として記録させ
たり、ファイルから記録データ１６を読みだしたりなど
するものである。

【００１９】記録データ１６は、各種データを記憶した
ものであって、ここでは、例えば利用者の個人情報ある
いはグループ情報などについて登録、変更などしたとき
の元の情報との変更分を記録するものである。

【００２０】ファイル１７は、通信時に必要な各種デー
タを保存するものであって、ここでは通信用テーブル
（分身）１７−１を保存するものである。通信用テーブ
ル（分身）１７−１は、例えば後述する図７の（ｃ）に
示すように、分身１と、対応する本体２のアドレスとを
対応づけて保存するものである。

【００２１】スケジュールデータ操作部１８は、スケジ
ュールデータ１９を操作（登録、更新、変更、削除な
ど）を行うものである。スケジュールデータ１９は、利
用者に関するスケジュールデータであって、利用者の個
人情報に対応する個人用のスケジュールデータ１９−
１、およびグループ情報に対応するグループ用のスケジ
ュールデータ１９−２を保存したものである。

【００２２】以上のように、分身１が通信用テーブル
（分身）を持ち、当該分身１に対応する本体２にアドレ
スを用いて通信することが可能となると共に、スケジュ
ールデータ（個人用）１９−１およびスケジュールデー
タ（グループ用）１９−２を個別に持ち、利用者の個人
情報および複数の利用者に関係するグループ情報をそれ
ぞれ管理することが可能となる。

【００２３】図３は、本発明の本体の構成図を示す。こ
れは、図１の本体２の構成例である。図３において、通
信部２１は、ネットワーク３との間でデータの授受を行
うと共に対応する分身１との間でデータの授受を行うも
のであって、例えば後述する図８に示す通信パケットを
送受信するものである。

【００２４】制御部２２は、各種制御を行うものであっ
て、全体を統括制御するものである。入出力部２３は、
入出力装置２４との間でデータの入出力を行うと共に、
入出力するデータを制御部２２との間で受渡しするもの
である。

【００２５】入出力装置２４は、データを表示したり、
キーあるいは画面から入力したデータを取り込んだりな
どするものである。ファイル２７は、通信時に必要な各
種データを保存するものであって、ここでは通信用テー
ブル２７−１および通信用テーブル（本体）２７−２を
保存するものである。通信用テーブル２７−１は、後述
する図７の（ａ）に示すように、利用者名に対応づけて
そのアドレスを登録したものである。通信用テーブル
（本体）２７−２は、後述する図７の（ｂ）に示すよう
に、本体２に対応する分身１のアドレスを登録したもの
である。

【００２６】スケジュールデータ操作部２８は、スケジ
ュールデータ２９を操作（登録、更新、変更、削除な
ど）を行うものである。スケジュールデータ２９は、利
用者に関するスケジュールデータであって、利用者の個
人情報に対応する個人用のスケジュールデータ２９−
１、およびグループ情報に対応するグループ用のスケジ
ュールデータ２９−２を保存したものである。ここで、
本体２の個人用のスケジュールデータ２９−１、および
グループ情報に対応するグループ用のスケジュールデー
タ２９−２について、一貫性を常に保持するようにして
おり、一貫性を保持させた後に対応する分身１に通知し
て既述した図２の個人用のスケジュールデータ１９−
１、およびグループ情報に対応するグループ用のスケジ
ュールデータ１９−２を更新し、一貫性を保持するよう
にしている。

【００２７】以上のように、本体２が通信用テーブル２
７−１および通信テーブル（本体）２７−２を持ち、他
の利用者の本体２に通信したり、当該本体２に対応する
分身１にアドレスを用いて通信したりすることが可能と
なると共に、スケジュールデータ（個人用）２９−１お
よびスケジュールデータ（グループ用）２９−２を個別
に持ち、一貫性を保持させたこれらを対応する分身１に
通知して当該分身１のスケジュールデータ（個人用）１
９−１およびスケジュールデータ（グループ用）１９−
２を更新して一貫性を保持させることが可能となる。

【００２８】次に、図４のフローチャートに示す順序に
従い、図１ないし図３の構成のもとで、分身１と本体２
２との情報交換について詳細に説明する。図４は、本発
明の分身と本体との情報交換フローチャートを示す。

【００２９】図４において、Ｓ１は、本体のアドレスを
通信用テーブルに登録する。これは、後述する図７の
（ａ）の本体２が持つ通信用テーブル２７−１に本体の
アドレスを登録する。例えば利用者Ａに対応する本体１
“＃１１”に対応づけてそのアドレス“＃０１”を図示
のように登録する。これにより、利用者Ａの本体２が
“＃１”であって、そのアドレスが“＃０１”である旨
が登録され、当該通信用テーブル２７−１は、全ての本
体２に通知されて保持され、本体２は任意の利用者の本
体２との間で通信することが可能となる。

【００３０】Ｓ２は、本体と分身の通信用テーブルを作
成する。これは、後述する図７の（ｂ）の通信用テーブ
ル（本体）２７−２および図７の（ｃ）の通信用テーブ
ル（分身）２７−１をそれぞれ作成し、本体２と分身１
に保持させる。ここで、通信用テーブル（本体）２７−
２は、本体２が持ち、本体２“＃１”に対応づけて分身
１のアドレス“＃００１”が登録され、本体２が対応す
る分身１に通信することが可能となる。同様に、通信用
テーブル（分身）１７−１は、分身１が持ち、分身１
“＃１１”に対応づけて本体２のアドレス“＃０１”が
登録され、分身１が対応する本体２に通信することが可
能となる。

【００３１】Ｓ３は、分身が本体と通信して情報を交換
する。これは、分身１がＳ２で作成した通信テーブル
（分身）１７−１を参照して対応する本体２のアドレス
に後述する図８の通信パケットを送信すると共に、本体
２がＳ２で作成した通信テーブル（本体）１７−２を参
照して対応する分身１のアドレスに後述する図８の通信
パケットを送信し、情報を交換する。

【００３２】以上の通信テーブル２７−１、通信テーブ
ル（本体）２７−２、および通信テーブル（分身）１７
−１を作成することにより、分身１と本体２、更に本体
２の対応する利用者の本体２との間で相互に情報を交換
することが可能となる。

【００３３】図５は、本発明のグループスケジュール処
理フローチャートを示す。図５において、Ｓ１１は、利
用者からグループスケジュールの依頼を受ける。これ
は、利用者が分身１を操作してグループスケジュールの
依頼を対応する本体２に、後述する図８の通信パケット
を送信する。

【００３４】Ｓ１２は、参加者を調べる。これは、Ｓ１
１で依頼を受けた本体２が通信パケットを参照、例えば
後述する図８の通信パケットのデータ中の参加者のフィ
ールドを参照して当該グループスケジュールへの参加者
がここでは、“Ａ、Ｂ、Ｃ”である旨を調べる。

【００３５】Ｓ１３は、参加者の本体のアドレスを探
す。これは、Ｓ１２で調べた参加者（例えばＡ、Ｂ、
Ｃ）について、図７の（ａ）の通信テーブル２７−１を
参照してその参加者の本体２のアドレス（ここでは、＃
０１、＃０２、＃０３）を探す。

【００３６】Ｓ１４は、参加者の本体にグループスケジ
ュールを依頼する。これは、Ｓ１３で探した全ての参加
者のアドレスに、グループスケジュールを送信してその
本体２に依頼する。

【００３７】Ｓ１５は、全ての本体が依頼を受理したか
判別する。ＹＥＳの場合には、Ｓ１４で参加者の本体２
にグループスケジュールの依頼を行い、当該本体２でス
ケジュールが取れたのでそのＯＫという受理した旨を全
ての本体２から返信を受けたと判明したので、Ｓ１６で
グループスケジュールの成功した旨を全ての参加者に通
知し、全ての参加者の本体２が対応するグループ用のス
ケジュールデータを一貫性を持って更新する（図６を用
いて詳述する）。一方、Ｓ１５のＮＯの場合には、グル
ープスケジュールについていずれかの本体２で失敗した
と判明したので、Ｓ１７でグループスケジュールの失敗
した旨を全ての参加者に通知し、グループスケジュール
の依頼を破棄する。そして、グループスケジュールに失
敗した旨を依頼元の分身１に通知し、その利用者に知ら
せる。

【００３８】以上によって、利用者が分身１を操作して
グループスケジュールを依頼すると、当該分身１が対応
する本体２に依頼し、当該本体２がグループスケジュー
ル中から参加者を見つけてその参加者の全ての本体２に
グループスケジュールの依頼を行い、全ての本体２から
ＯＫの旨を受け取ったときに成功を全ての本体２に通知
して本体２が持つグループスケジュールを更新する。こ
れにより、ある利用者が分身１を介して本体２に参加者
を指定してグループスケジュールを送信して依頼するの
みで、自動的に参加者の本体２に取い合わせてグループ
スケジュールすることが可能となる。

【００３９】図６は、本発明の本体のグループスケジュ
ール処理フローチャート（その２）を示す。これは、既
述した図５のＳ１４で他の本体からグループスケジュー
ルの依頼を受けたときの処理である。

【００４０】図６において、Ｓ２１は、他の本体からグ
ループスケジュールの依頼を受ける。これは、例えば既
述した図５のＳ１４で、本体（Ａ）２から参加者である
Ｂ、Ｃの本体２がグループスケジュールの依頼を受け
る。

【００４１】Ｓ２２は、スケジュールを調べる。これ
は、Ｓ２１でスケジュールの依頼を受けた本体２が、ス
ケジュールデータを調べる。Ｓ２３は、Ｓ２２で調べた
結果、スケジュールに空きがあるか判別する。ＹＥＳの
場合には、Ｓ２４でスケジュールの依頼を受理し、Ｓ２
５で受理を通知（依頼元の本体２に受理した旨を通知）
する。そして、他の全ての本体２から受理した旨の通知
を依頼元の本体２が受けたときに、スケジュール成功の
旨が通知されるので、このときにグループスケジュール
を更新して一貫性を保持すると共に依頼元の分身１にグ
ルークスケジュールに成功した旨を知らせる。一方、Ｓ
２３のＮＯの場合には、Ｓ２６で依頼を拒否し、Ｓ２７
で拒否を通知（依頼元の本体２に拒否する旨を通知）す
る。そして、依頼元の本体２は拒否の旨を参加者の本体
２に通知してグループスケジュールの更新を中止すると
共に依頼元の分身１にグループスケジュールが失敗した
旨を知らせる。

【００４２】図７は、本発明のテーブル例を示す。図７
の（ａ）は、通信用テーブルを示す。これは、ネットワ
ーク３に接続された全ての本体２が共通に保持するもの
であって、利用者名に対応づけてその本体２のアドレス
を登録したものである。これにより、例えば既述したグ
ループスケジュールの依頼を受けたある本体２が当該グ
ループスケジュール中の参加者に対応する本体２のアド
レスを、この通信用テーブル２７−１から見つけて通信
パケットを送信することが可能となる。

【００４３】図７の（ｂ）は、通信用テーブル（本体）
を示す。これは、本体２が持つものであって、本体２が
対応する分身１に通信するときのアドレスを登録したも
のである。

【００４４】図７の（ｃ）は、通信用テーブル（分身）
を示す。これは、分身１が持つものであって、分身１が
対応する本体２に通信するときのアドレスを登録したも
のである。

【００４５】図８は、本発明の通信パケット例を示す。
この通信パケットは、分身１と本体２、本体２と他の本
体２との間で情報を交換するときの例である。ここで
は、図示のように下記の項目を設定する。

【００４６】・送信元アドレス：・送信先アドレス：・操作属性・ローカル：分身と本体との間の情報の交換を表す・リモート：分子と本体と他の本体との間の情報の交換を表す。

【００４７】・データ・スケジュールデータ：・操作：挿入、削除、変更など・日付：・イベント：・参加者：例えばＡ、Ｂ、Ｃ・その他図９は、本発明の分身の処理フローチャートを示す。

【００４８】図９において、Ｓ３１は、分身内でスケジ
ュールデータの更新（個人用とグループ用を分けて）す
る。Ｓ３２は、データの変更分を保存（個人用とグルー
プ用を分けて）する。これらＳ３１、Ｓ３２は、利用者
が分身１を操作してスケジュールデータの更新を行った
場合、当該分身１が持つ個人用のスケジュールデータ
と、グループ用のスケジュールデータとを分けてそれぞ
れ更新し、この更新したときの変更分のみを別途保存す
る。

【００４９】Ｓ３３は、分身が本体と通信可能か判別す
る。ＹＥＳの場合には、Ｓ３４に進む。ＮＯの場合に
は、分身１が本体２と通信不可と判明したので、分身１
内でのみＳ３１の更新と、Ｓ３２の変更分の保存との個
人用とグループ用に分けて行う。これにより、分身１が
本体２と通信不可のときであっても、分身１が保持する
個人用およびグループ用のスケジュールデータを参照し
て更新することが可能となる。

【００５０】Ｓ３４は、Ｓ３３のＹＥＳで分身１が本体
２と通信可能と判明したので、変更分（個人用）のみを
本体に送信する。Ｓ３５は、本体で変更分（個人用）の
スケジュールデータの更新する。

【００５１】Ｓ３６は、本体が分身に変更（個人用）処
理終了を通知する。以上のＳ３３のＹＥＳからＳ３６に
よって、分身１と本体２とが通信可能となったときに、
分身１から変更分（個人用）を本体２に送信して本体２
の個人用のスケジュールデータを更新し、更新が終了し
たときに分身１にその旨を通知し、本体２と分身１との
個人用のスケジュールデータの一貫性が確保されたこと
となる。

【００５２】Ｓ３７は、変更分（グループ用）のスケジ
ュールデータを本体に送信する。Ｓ３８は、本体で変更
分（グループ用）のスケジュールデータの更新する。Ｓ
３９は、既述した図５のＳ１１〜Ｓ１７の処理を行う。
これにより、本体２がグループ用のスケジュールデータ
中の参加者の全ての本体２にグループスケジュール依頼
を行い、その応答（成功、失敗）を受け取る。

【００５３】Ｓ４０は、全部成功か判別する。これは、
Ｓ３９でグループスケジュールの受け取った結果が全部
成功か判別する。ＹＥＳの場合には、Ｓ４１で成功を全
本体と分身に通知する。これにより、グループスケジュ
ールの参加者の本体２でグループスケジュールが更新さ
れることとなる。一方、ＮＯの場合には、Ｓ４２で失敗
を全本体と分身に通知する。これにより、グループスケ
ジュールの参加者の本体２が失敗を知り、グループスケ
ジュールを更新を中止し、グループスケジュールを依頼
した依頼元の分身１はその依頼が失敗した旨を利用者に
表示して知らせる。

【００５４】Ｓ４１は、本体のスケジュールデータを分
身に送信する。これは、本体２で一貫性の保持したグル
ープ用のスケジュールデータおよび個人用のスケジュー
ルデータについて、対応する分身１に送信する。

【００５５】Ｓ４２は、分身がスケジュールデータを更
新する。これは、Ｓ４１で受信した一貫性の保持された
グループ用のスケジュールデータおよび個人用のスケジ
ュールデータで、当該分身１が保持するそれぞれのデー
タを更新し、本体１との一貫性を保持させる。

【００５６】以上によって、分身１内で個人用とグルー
プ用に分けてスケジュールデータを更新および変更分を
保存し、分身１が本体２と通信可能のとき、あるいは通
信可能となったときに本体２に送信して当該本体２の個
人用のスケジュールデータを更新して一貫性を保持、お
よび当該本体２のグループ用のスケジュールデータにつ
いては他の参加者に依頼して成功したときに更新して一
貫性を保持させた後、対応する分身１に個人用およびグ
ループ用のスケジュールデータを送信して分身１のスケ
ジュールデータの一貫性を保持させることが可能とな
る。

【００５７】

【発明の効果】以上説明したように、本発明によれば、
利用者の分身１に対応づけてネットワーク３上に本体２
を設けて当該利用者の個人情報を管理および他の利用者
の本体２と通信してグループ情報を管理すると共に、分
身１が本体２と通信できないときは当該分身１内で情報
を保留して通信可能となったときに本体２に送信して管
理する構成を採用しているため、ネットワーク３を利用
した利用者の個人情報およびグループ情報を効率的に管
理し得るシステムを構築することができた。これによ
り、（１）従来のシステム時のサーバに負荷を集中する事
態を無くし、高速処理を実現できた。

【００５８】（２）ネットワークの速度の遅い環境で
あっても、分身１内の情報を参照でき、動作速度が遅く
なる事態を無くすことができた。（３）従来のサーバにアクセスできない環境であって
も、分身１内の情報を参照してスケジュールなどを行う
ことができ、しかも通信可能となったときに自動的にス
ケジュールなどの一貫性を保持させることが可能となっ
た。

【図面の簡単な説明】

【図１】本発明のシステム構成図である。

【図２】本発明の分身の構成図である。

【図３】本発明の本体の構成図である。

【図４】本発明の分身と本体との情報交換フローチャー
トである。

【図５】本発明の本体のグループスケジュール処理フロ
ーチャートである。

【図６】本発明の本体のグループスケジュール処理フロ
ーチャート（その２）である。

【図７】本発明のテーブル例である。

【図８】本発明の通信パケット例である。

【図９】本発明の分身の処理フローチャートである。

【図１０】従来技術の説明図である。

【符号の説明】

１：分身１１、２１：通信部１２、２２：制御部１３、２３：入出力部１４、２４：入出力装置１５：記録部１６：記録データ１７、２７：ファイル１７−１：通信用テーブル（分身）１８、２８：スケジュールデータ操作部１９、２９：スケジュールデータ１９−１、２９−１：個人用のスケジュールデータ１９−２、２９−２：グループ用のスケジュールデータ２：本体２７−１：通信用テーブル２７−２：通信用テーブル（本体）３：ネットワーク

───────────────────────────────────────────────────── フロントページの続き (72)発明者フランシスマッケーブ神奈川県川崎市中原区上小田中４丁目１番１号富士通株式会社内 (72)発明者塩内正利神奈川県川崎市中原区上小田中４丁目１番１号富士通株式会社内 (72)発明者寺本良明神奈川県川崎市中原区上小田中４丁目１番１号富士通株式会社内 (72)発明者高田裕志神奈川県川崎市中原区上小田中４丁目１番１号富士通株式会社内

Claims

【特許請求の範囲】

【請求項１】ネットワークを利用して利用者情報を管理
する情報管理システムにおいて、利用者に対応づけて設け当該利用者の個人情報および他
の利用者との間のグループ情報を管理する分身と、この分身に対応づけてネットワーク上に設け当該分身か
ら通知された個人情報を一貫性を持って管理すると共
に、当該分身から通知されたグループ情報についてネッ
トワーク上の該当する他の本体と通信して当該グループ
情報を一貫性を持って管理する本体とを備えたことを特
徴とする情報管理システム。
【請求項２】上記ネットワーク上に設けた本体が対応す
る分身に上記個人情報およびグループ情報を通知して一
貫性を保持させることを特徴とする請求項１記載の情報
管理システム。
【請求項３】上記ネットワーク上の本体が該当する他の
本体にグループ情報を通知して全ての本体からグループ
情報の更新のＯＫの旨の通知に対応してその旨を全ての
本体に通知して一貫性を持ってグループ情報を更新する
ことを特徴とする請求項１あるいは請求項２記載のいず
れかの情報管理システム。
【請求項４】上記分身が対応する本体と通信不可のとき
に当該分身内の個人情報あるいはグループ情報を更新お
よび変更分を保存し、通信可となったときに変更分を本
体に通知して当該本体が一貫性を持って個人情報および
グループ情報を管理しその一貫性を持たせた個人情報お
よびグループ情報を分身に通知して当該分身内の個人情
報およびグループ情報の一貫性を保持させることを特徴
とする請求項１ないし請求項３記載のいずれかの情報管
理システム。