(57)【特許請求の範囲】
【請求項１】
氏名または団体名、住所、電話番号等の個人・団体のメンバー情報を格納するメンバー管理テーブルと、
そのメンバー管理テーブルに登録されたあるメンバーとそのメンバーに関係する他のメンバーの二者の関係を親子関係で規定された関係レコードを記録するとともにその関係の種類および関係の優先順位を表す区分コードを記録する関係管理テーブルとからなるデータベースを備えた関係付け情報管理システムにおいて、  参照対象としてメンバーが指定されたときに、そのメンバーと親子関係があるメンバーを抽出して、参照対象とともに親メンバー、子メンバー、孫メンバーをリストとして表示する、次のステップを実行する手段を有する関係付け情報管理システム。
（１）特定の条件を指定して抽出されたメンバーリストで選択されているメンバーのコードを参照対象コード（以下本人ＣＩＦ）とする。
（２）本人ＣＩＦを元に参照対象の情報をメンバー管理テーブルより取得し、参照対象表示域に格納する。
（３）本人ＣＩＦを元に関係管理テーブルより参照対象者の親関係にあたる全てのメンバーのコード（以下親ＣＩＦ）と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから親メンバーリスト表示領域に格納する。
（４）本人ＣＩＦを元に関係管理テーブルより参照対象者の子関係にあたる全てのメンバーのコード（以下子ＣＩＦ）と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから子メンバーリスト表示領域に格納する。
（５）子メンバーリスト表示領域の最上にある子ＣＩＦを元に関係管理テーブルより子メンバーリスト表示領域の最上にある子メンバーの子関係にあたる全てのメンバーのコード（以下孫ＣＩＦ）と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから孫メンバーリスト表示領域に格納する。
（６）表示領域を表示する。
（７）子メンバーリスト表示領域の中で最上以外のメンバーをユーザが選択したかどうかを判断する。選択したらステップ（８）に進む。選択しなければステップ（９）に進む。
（８）選択された子ＣＩＦを元に関係管理テーブルより子メンバーリスト表示領域の選択された子メンバーの子関係にあたる全てのメンバーのコードと区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから孫メンバーリスト表示領域に格納し、再度表示する。
（９）参照対象変更ボタンを押下したかどうかを判断する。押下したらステップ（１０）に進む。押下しなければ次の指示を待つ。
（１０）親メンバーリスト表示領域と子メンバーリスト表示領域と孫メンバーリスト表示領域の中でユーザが選択したメンバーのコードを本人ＣＩＦとする。ステップ（２）に戻る。
【請求項２】
氏名または団体名、住所、電話番号等の個人・団体のメンバー情報を格納するメンバー管理テーブルと、
そのメンバー管理テーブルに登録されたあるメンバーとそのメンバーに関係する他のメンバーの二者の関係を親子関係で規定された関係レコードを記録するとともにその関係の種類および関係の優先順位を表す区分コードを記録する関係管理テーブルとからなるデータベースを備えた関係付け情報管理システムにおいて、  参照対象に設定されたメンバーコードにより、親子関係があるメンバーを抽出して、親等の近い順に複数親等をツリービューに表示する、次のステップを実行する手段を有する関係付け情報管理システム。
（１）参照対象ＣＩＦをもとにメンバー管理テーブルの参照対象メンバーの情報を取得し、ツリービュー領域に表示する。
（２）１親等洗い出し
（２−１）参照対象ＣＩＦをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域２列目に１メンバー１段で参照対象の下に追加表示する。
（２−２）参照対象ＣＩＦをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域２列目に１メンバー１段で親メンバーの下に追加表示する。
ただし、ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に省略記号を付加する。
（３）２親等洗い出し
（３−１）２列目に表示されている１親等のメンバーについて上から順にそれぞれ次の処理を行う。
（３−２）１親等者ＣＩＦをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域３列目に１メンバー１段で該当の１親等のメンバーと次の１親等のメンバーの間に挿入表示する。
ただし、直系の２親等前（参照対象）が同じメンバーなら「２親等洗い出し」はしない。
（３−３）元にする１親等の該当段目のメンバーに省略記号がついていれば「２親等洗い出し」はしない。
（３−４）ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に省略記号を付加する。
（３−５）１親等者ＣＩＦをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域３列目に１メンバー１段で該当の１親等のメンバーと次の１親等のメンバーの間に挿入表示する。
ただし、直系の２親等前（参照対象）が同じメンバーなら「２親等洗い出し」はしない。
（３−６）元にする１親等の該当段目のメンバーに省略記号がついていれば「２親等洗い出し」はしない。
（３−７）ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に省略記号を付加する。
（４）ｎ親等洗い出し。（ｎ＝３）とする
（４−１）ｎ列目に表示されているｎ−１親等のメンバーについて上から順にそれぞれ次の処理を行う。
（４−２）ｎ−１親等者ＣＩＦをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域ｎ＋１列目に１メンバー１段で該当のｎ−１親等のメンバーと次のｎ−１親等のメンバーの間に挿入表示する。
ただし、直系の２親等前（ｎ−２親等者）が同じメンバーなら「ｎ親等洗い出し」はしない。
（４−３）元にするｎ−１親等の該当段目のメンバーに省略記号がついていれば「ｎ親等洗い出し」はしない。
（４−４）ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に省略記号を付加する。
（４−５）ｎ−１親等者ＣＩＦをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域ｎ＋１列目に１メンバー１段で該当のｎ−１親等のメンバーと次のｎ−１親等のメンバーの間に挿入表示する。
ただし、直系の２親等前（ｎ−２親等者）が同じメンバーなら「ｎ親等洗い出し」はしない。
（４−６）元にするｎ−１親等の該当段目のメンバーに省略記号がついていれば「ｎ親等洗い出し」はしない。
（４−７）ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に省略記号を付加する。
（５）以降、ステップ（４）のｎを１累進させて、ｎが所定の数に達するまで（４）のステップを繰り返し、ｎが所定の数に達すれば処理終了する。
【請求項３】
氏名または団体名、住所、電話番号等の個人・団体のメンバー情報を格納するメンバー管理テーブルと、
そのメンバー管理テーブルに登録されたあるメンバーとそのメンバーに関係する他のメンバーの二者の関係を親子関係で規定された関係レコードを記録するとともにその関係の種類および関係の優先順位を表す区分コードを記録する関係管理テーブルとからなるデータベースを備えた関係付け情報管理システムにおいて、  参照対象に設定された二人のメンバーコードにより、その二人に関係ルートが出来上がっているかどうかを、任意の親等まで抽出して表示する、次のステップを実行する手段を有する関係付け情報管理システム。
（１）関係の追跡をする二人のメンバーのうち、一方を正、他方を副とし、正メンバーに副メンバーが繋がっているかを追跡するため、設定条件を保存し、検索結果を一時保存するメモリ内の配列エリアを初期化する。
（２）処理を行う際に、ユーザが指定した、最大何親等まで探すか、最短ルートか全てのルートかの設定条件を保存する。
（３）正メンバーの親子の関係である１親等目を抽出する。
（３−１）抽出された１親等目のｎａのレコード数のうち、ｉａ番目（ｉ＝１〜ｎ）は副メンバーかを判断する。
（３−１−１）副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の１親等目のレコードに対し、（３−１）のステップの処理を実行する。
（４）副メンバーでなければ、１親等目のｉａ番目のメンバーの親子の関係である２親等目を抽出する。
（４−１）抽出された２親等目のｎｂのレコード数のうち、ｉｂ番目（ｉ＝１〜ｎ）は副メンバーかを判断する。
（４−１−１）副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の２親等目のレコードに対し、（４−１）のステップの処理を実行する。
（４−２）副メンバーでなければ、２親等目のｉｂ番目と同じメンバーがルート中の上位に存在しないかどうか判断する。
（４−２−１）存在していれば、その処理を中断し次の２親等目のレコードに対し、（４−１）のステップの処理を実行する。
（５）存在していなければ、２親等目のｉｂ番目のメンバーの親子の関係である３親等目を抽出する。
（５−１）抽出された３親等目のｎｃのレコード数のうち、ｉｃ番目（ｉ＝１〜ｎ）は副メンバーかを判断する。
（５−１−１）副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の３親等目のレコードに対し、（５−１）のステップの処理を実行する。
（５−２）副メンバーでなければ、３親等目のｉｃ番目と同じメンバーがルート中の上位に存在しないかどうか判断する。
（５−２−１）存在していれば、その処理を中断し次の３親等目のレコードに対し、（５−１）のステップの処理を実行する。
（６）存在していなければ、３親等目のｉｃ番目のメンバーの親子の関係である４親等目を抽出する。
（７）これをあらかじめ設定された数の親等まで数値を累進しながら繰り返し、最終親等で、次の処理を行う。
（７−１）抽出された最終親等目のｎｘのレコード数のうち、ｉｘ番目（ｉ＝１〜ｎ）は副メンバーかを判断する。
（７−１−１）副メンバーであれば、正メンバーからのルートを前記メモリ内の配列エリアに保存し、最終親等の次のレコードに進む。
（７−２）副メンバーでなければ、最終親等の次のレコードに進む。最終親等のレコードがｎ迄終われば、それより１つ前の親等のレコード数を１つ累進させて処理を行う。
（７−３）１つ前の親等のレコード数がｎ迄終われば、さらに１つ前の親等のレコード数を１つ累進させて処理を行う。
（８）これを全ての親等のレコード数が終了するまで行う。
（９）前記メモリ内の配列エリアに保存されている検索結果をルートの親等数の少ないものから並べ直す。
（１０）検索結果の１番目をツリービューに表示する。
（１１）ユーザが検索結果表示の変更をプルダウンリストボックスで指示したときは、検索結果の中のユーザの選択したルートをツリービューに表示する。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、各種情報を関係付けて管理する関係付け情報管理システム、関係付け情報管理用プログラム、及び記録媒体に関し、また、個人・団体の情報のデータと相互の関係を系統を持たせて記録する系図型人脈管理システムに関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
情報化時代、ＩＴ革命などを経てパソコン、携帯情報端末（ＰＤＡ）その他各種情報端末機器が様々な分野で飛躍的に普及している。それに伴い情報端末で処理し管理する情報は、人に関する情報、組織に関する情報、営業・顧客その他事業に関する情報、文書・文献に関する情報、各種管理に関する情報など非常に多岐に拡がっている。このように情報の種類が多くなるだけでなく、情報の量も多くなると、当然それら情報の間にもいろいろな関連がでてくる。それらの情報の関係を有効に活用するためには、情報を整理し情報の関係を管理することが必要不可欠となる。
【０００３】
一般に情報の関係付けとしては、例えばあるジャンルやカテゴリーで、一定の規則にしたがって上位から下位へツリー構造に関係付けを行うことでなされている。また、家族の系図のようなものは、親から子供、さらにその子供、そして、それぞれの姻戚へと繋がっていくが、上位から下位への関係付けが基本であり、複雑に関係が錯綜することはない。
【０００４】
しかし、情報の種類と量が多くなると、扱う情報によって、情報全体を整理するために、さらに、ジャンル、カテゴリーの異なる情報も含めた関係付けも管理の対象として必要となる。図４４は関係図の例を示す図、図４５は関係付けされた各種情報の例を示す図である。
【０００５】
例えば図４４に示すようにＡ〜Ｊの情報が矢印に示すように関係付けされるとすると、一般に関係付けは、情報の全てが実線のようなツリー構造にはならず、ＡとＦとの関係は、ＡとＢＣＤを介しても点線で示す関係があるというように、別の関係付けが存在する例はよくあることで、多数ある情報間ではそれらの関係が錯綜してくる。また、図４５に示すように文献や、○○大学、○○建設、作成者、図面、○○文書、管理部署などがそれぞれ情報の単位とした場合、例えば○○文書に着目すると、これに対し、作成者、文献、図面、応用文書、保管場所、担当部署が関係付けられている。
【０００６】
上記のようにジャンル、カテゴリーの異なる様々な情報の関係付けだけでなく、人に関する情報として、人脈を系統化しようとすると、一人の人に繋がっている人の数は数人から数百人になり、さらに、友達の友達が別の友達のまた友達というように、同じ人脈の系図に同一人物が重複して関係付けされ、非常に煩雑になる。
【０００７】
このような関係付けを有する情報を一般の関係図として表すと非常に入り組んで複雑、煩雑になり、それを記録することや、まして全ての関係を記録することは非常に困難なことである。そこで、それぞれの目的に応じ限定して管理するようにしたり、例えば人脈では、重要なところだけが、人の記憶に頼って管理されている。これが現状である。
【０００８】
一般の家系図では直系家族を表すことはできるが、婚姻によって結ばれた外戚を一緒に表記することは困難である。長男の外戚のみならば、図４６に示すように何とかできるが、兄弟全員の外戚を表記し、その配偶者の兄弟それぞれが婚姻した外戚や、そのそれぞれの親や親の兄弟、親の実家の外戚などをすべて表記するとなると、３次元で立体的に表すほかない。しかも家族であるから、系図の中にあらわれる個人は必ず１箇所にしか名前は出てこない。兄弟も多くて１０数人である。
【０００９】
しかし、人脈を系統化しようとすると、図４７に示すように一人の人に繋がっている人の数は数人から数百人はいるし、友達の友達が、別の友達のまた友達という風に、同じ系図に同一人物が幾度となく出てくる。こうなると、一般の関係図を記録するのは非常に困難であるし、すべての関係を記録することはできない。そこで、人脈は重要なところだけを、人の記憶に頼って管理されているのが現状である。
【００１０】
従来においては、人脈情報を電子メールに含まれる発信者氏名、宛先人氏名、およびそれらの電子メールアドレスから抽出して管理するシステム（特開２０００−６６９７０号公報）や、名刺情報をコンピュータで読み取り、その名刺を誰が誰からもらったかをという情報を併せて登録することにより人脈情報を得る装置（特開平１１−６６０８２号公報）が提案されている。
【００１１】
しかしながら、これらの従来技術においては、人脈の二次元的なつながりを規定するのみであり、親子関係（上下関係）などの三次元的な広がりやつながりの深さをもつ人脈についての情報は規定も検索もすることができなかった。
【００１２】
【課題を解決するための手段】
本発明は、上記課題を解決するものであって、簡単な構成により様々な情報の関係付けの登録、管理を可能にし、位置時系列を含む関係の検索、抽出を簡便に行えるようにするものである。
【００１６】
そのために本発明は、氏名または団体名、住所、電話番号等の個人・団体のメンバー情報を格納するメンバー管理テーブルと、
そのメンバー管理テーブルに登録されたあるメンバーとそのメンバーに関係する他のメンバーの二者の関係を親子関係で規定された関係レコードを記録するとともにその関係の種類および関係の優先順位を表す区分コードを記録する関係管理テーブルとからなるデータベースを備えた関係付け情報管理システムにおいて、  参照対象としてメンバーが指定されたときに、そのメンバーと親子関係があるメンバーを抽出して、参照対象とともに親メンバー、子メンバー、孫メンバーをリストとして表示する、次のステップを実行する手段を有する関係付け情報管理システム。
（１）特定の条件を指定して抽出されたメンバーリストで選択されているメンバーのコードを参照対象コード（以下本人ＣＩＦ）とする。
（２）本人ＣＩＦを元に参照対象の情報をメンバー管理テーブルより取得し、参照対象表示域に格納する。
（３）本人ＣＩＦを元に関係管理テーブルより参照対象者の親関係にあたる全てのメンバーのコード（以下親ＣＩＦ）と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから親メンバーリスト表示領域に格納する。
（４）本人ＣＩＦを元に関係管理テーブルより参照対象者の子関係にあたる全てのメンバーのコード（以下子ＣＩＦ）と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから子メンバーリスト表示領域に格納する。
（５）子メンバーリスト表示領域の最上にある子ＣＩＦを元に関係管理テーブルより子メンバーリスト表示領域の最上にある子メンバーの子関係にあたる全てのメンバーのコード（以下孫ＣＩＦ）と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから孫メンバーリスト表示領域に格納する。
（６）表示領域を表示する。
（７）子メンバーリスト表示領域の中で最上以外のメンバーをユーザが選択したかどうかを判断する。選択したらステップ（８）に進む。選択しなければステップ（９）に進む。
（８）選択された子ＣＩＦを元に関係管理テーブルより子メンバーリスト表示領域の選択された子メンバーの子関係にあたる全てのメンバーのコードと区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから孫メンバーリスト表示領域に格納し、再度表示する。
（９）参照対象変更ボタンを押下したかどうかを判断する。押下したらステップ（１０）に進む。押下しなければ次の指示を待つ。
（１０）親メンバーリスト表示領域と子メンバーリスト表示領域と孫メンバーリスト表示領域の中でユーザが選択したメンバーのコードを本人ＣＩＦとする。ステップ（２）に戻る。
【００１７】
さらに、本発明は、前記システムにおいて、参照対象に設定されたメンバーコードにより、親子関係があるメンバーを抽出して、親等の近い順に複数親等をツリービューに表示する、次のステップを実行する手段を有する。
（１）参照対象ＣＩＦをもとにメンバー管理テーブルの参照対象メンバーの情報を取得し、ツリービュー領域に表示する。
（２）１親等洗い出し
（２−１）参照対象ＣＩＦをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域２列目に１メンバー１段で参照対象の下に追加表示する。
（２−２）参照対象ＣＩＦをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域２列目に１メンバー１段で親メンバーの下に追加表示する。
【００１８】
ただし、ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に省略記号を付加する。
（３）２親等洗い出し
（３−１）２列目に表示されている１親等のメンバーについて上から順にそれぞれ次の処理を行う。
（３−２）１親等者ＣＩＦをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域３列目に１メンバー１段で該当の１親等のメンバーと次の１親等のメンバーの間に挿入表示する。
【００１９】
ただし、直系の２親等前（参照対象）が同じメンバーなら「２親等洗い出し」はしない。
（３−３）元にする１親等の該当段目のメンバーに省略記号がついていれば「２親等洗い出し」はしない。
（３−４）ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に省略記号を付加する。
（３−５）１親等者ＣＩＦをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域３列目に１メンバー１段で該当の１親等のメンバーと次の１親等のメンバーの間に挿入表示する。
【００２０】
ただし、直系の２親等前（参照対象）が同じメンバーなら「２親等洗い出し」はしない。
（３−６）元にする１親等の該当段目のメンバーに省略記号がついていれば「２親等洗い出し」はしない。
（３−７）ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に省略記号を付加する。
（４）ｎ親等洗い出し。（ｎ＝３）とする。
（４−１）ｎ列目に表示されているｎ−１親等のメンバーについて上から順にそれぞれ次の処理を行う。
（４−２）ｎ−１親等者ＣＩＦをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域ｎ＋１列目に１メンバー１段で該当のｎ−１親等のメンバーと次のｎ−１親等のメンバーの間に挿入表示する。
【００２１】
ただし、直系の２親等前（ｎ−２親等者）が同じメンバーなら「ｎ親等洗い出し」はしない。
（４−３）元にするｎ−１親等の該当段目のメンバーに省略記号がついていれば「ｎ親等洗い出し」はしない。
（４−４）ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に省略記号を付加する。
（４−５）ｎ−１親等者ＣＩＦをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域ｎ＋１列目に１メンバー１段で該当のｎ−１親等のメンバーと次のｎ−１親等のメンバーの間に挿入表示する。
【００２２】
ただし、直系の２親等前（ｎ−２親等者）が同じメンバーなら「ｎ親等洗い出し」はしない。
（４−６）元にするｎ−１親等の該当段目のメンバーに省略記号がついていれば「ｎ親等洗い出し」はしない。
（４−７）ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に省略記号を付加する。
（５）以降、ステップ（４）のｎを１累進させて、ｎが所定の数に達するまで（４）のステップを繰り返し、ｎが所定の数に達すれば処理終了する。
【００２３】
さらに本発明は、前記システムにおいて、
参照対象に設定された二人のメンバーコードにより、その二人に関係ルートが出来上がっているかどうかを、任意の親等まで抽出して表示する、次のステップを実行する手段を有する。
（１）関係の追跡をする二人のメンバーのうち、一方を正、他方を副とし、正メンバーに副メンバーが繋がっているかを追跡するため、設定条件を保存し、検索結果を一時保存するメモリ内の配列エリアを初期化する。
（２）処理を行う際に、ユーザが指定した、最大何親等まで探すか、最短ルートか全てのルートかの設定条件を保存する。
（３）正メンバーの親子の関係である１親等目を抽出する。
（３−１）抽出された１親等目のｎａのレコード数のうち、ｉａ番目（ｉ＝１〜ｎ）は副メンバーかを判断する。
（３−１−１）副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の１親等目のレコードに対し、（３−１）のステップの処理を実行する。
（４）副メンバーでなければ、１親等目のｉａ番目のメンバーの親子の関係である２親等目を抽出する。
（４−１）抽出された２親等目のｎｂのレコード数のうち、ｉｂ番目（ｉ＝１〜ｎ）は副メンバーかを判断する。
（４−１−１）副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の２親等目のレコードに対し、（４−１）のステップの処理を実行する。
（４−２）副メンバーでなければ、２親等目のｉｂ番目と同じメンバーがルート中の上位に存在しないかどうか判断する。
（４−２−１）存在していれば、その処理を中断し次の２親等目のレコードに対し、（４−１）のステップの処理を実行する。
（５）存在していなければ、２親等目のｉｂ番目のメンバーの親子の関係である３親等目を抽出する。
（５−１）抽出された３親等目のｎｃのレコード数のうち、ｉｃ番目（ｉ＝１〜ｎ）は副メンバーかを判断する。
（５−１−１）副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の３親等目のレコードに対し、（５−１）のステップの処理を実行する。
（５−２）副メンバーでなければ、３親等目のｉｃ番目と同じメンバーがルート中の上位に存在しないかどうか判断する。
（５−２−１）存在していれば、その処理を中断し次の３親等目のレコードに対し、（５−１）のステップの処理を実行する。
（６）存在していなければ、３親等目のｉｃ番目のメンバーの親子の関係である４親等目を抽出する。
（７）これをあらかじめ設定された数の親等まで数値を累進しながら繰り返し、最終親等で、次の処理を行う。
（７−１）抽出された最終親等目のｎｘのレコード数のうち、ｉｘ番目（ｉ＝１〜ｎ）は副メンバーかを判断する。
（７−１−１）副メンバーであれば、正メンバーからのルートを前記メモリ内の配列エリアに保存し、最終親等の次のレコードに進む。
（７−２）副メンバーでなければ、最終親等の次のレコードに進む。最終親等のレコードがｎ迄終われば、それより１つ前の親等のレコード数を１つ累進させて処理を行う。
（７−３）１つ前の親等のレコード数がｎ迄終われば、さらに１つ前の親等のレコード数を１つ累進させて処理を行う。
（８）これを全ての親等のレコード数が終了するまで行う。
（９）前記メモリ内の配列エリアに保存されている検索結果をルートの親等数の少ないものから並べ直す。
（１０）検索結果の１番目をツリービューに表示する。
（１１）ユーザが検索結果表示の変更をプルダウンリストボックスで指示したときは、検索結果の中のユーザの選択したルートをツリービューに表示する。
【００３０】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照しつつ説明する。図１は本発明に係る関係付け情報管理システムの実施の形態を示す図、図２はメンバー管理テーブルの構成例を示す図、図３は関係管理テーブルの構成例を示す図、図４はマスタテーブルの構成例を示す図である。図中、１は入力処理部、２は出力処理部、３はデータ登録・更新処理部、４は検索処理部、５は編集処理部、６は関係管理テーブル、７はメンバー管理テーブル、８はマスタテーブルを示す。
【００３１】
図１において、入力処理部１は、関係管理テーブル６、メンバー管理テーブル７、マスタテーブル８などの各データに対する設定、登録、更新、削除などを行う各種データの入力や、検索、編集、出力などの各種指示の入力処理を行うものである。出力処理部２は、各データに対する設定、登録、更新、削除などを行う各種データや、検索、編集、出力などの各種指示の入力画面、各種指示の入力に基づく処理結果に関する画面、情報の表示出力、印刷出力、ネットワークや通信回線を通して他の機器へのデータ転送、送出処理を行うものである。
【００３２】
データ管理を行うデータ登録・更新処理部３は、入力処理部１からの入力に基づき各データに対する設定、登録、更新、削除などの各種処理を行うものであり、例えばメンバー詳細情報登録／更新、履歴情報登録／更新、関係入力などを行う。検索処理部４は、入力処理部１からの指示入力に基づき設定された検索条件に従って各データにアクセスしてメンバー情報の検索処理を行うものであり、例えばメンバー該当検索、メンバー履歴検索、メンバー関係検索などを行う。編集処理部５は、入力処理部１からの指示入力に基づき設定された出力条件に従って検索結果を出力するための編集処理を行うものであり、例えばメンバー紹介系図、前後ｎ親等表示、繋がり検索表示などを行う。
【００３３】
メンバー詳細情報登録／更新では、メンバーの情報を登録すると共に、更にイメージ画像表示機能により、それぞれメンバーに関係する画像を表示する。また、郵便番号入力後、郵便番号検索ボタンを押すことで、郵便番号から住所を引き当てる。履歴情報登録／更新では、対応履歴、売上履歴のような細かな情報を登録メンバー毎に登録し、更に、入力された内容は、メンバー履歴検索機能を使用することで履歴内容からメンバーを引き当てる。関係入力では、どちらからどちらへ繋がっているか、そしてそれらがどういう関係なのかを登録する。関係区分では、親から見て、子のメンバーとどういう関係かを予め設定した内容から選択し、メンバー関係検索機能を使用して選択した関係区分から登録メンバーを検索する。関係詳細登録では、入力時にその繋がりに対する詳細情報を入力することでメンバー関係検索機能を使用して登録時に入力した詳細情報を利用して検索する。
【００３４】
メンバー該当検索では、条件を与えて得られた結果を何度も条件を重ね合わせて目的のメンバー群に絞り込み、かつ（ＡＮＤ）検索では、前回の結果に今回の条件を与えてさらにデータを絞り込み、または（ＯＲ）検索では、前回の結果と今回の条件の結果のどちらか一方でも満たせば一致となる。検索により、通常は該当するメンバーをリストボックスに表示し、該当しないメンバーを選択（クリック）すると、条件で選ばれたメンバー以外のメンバーをリストボックスに表示する。メンバー履歴検索では、メンバー毎に入力された履歴を基にメンバーを検索する。例えば履歴を売買情報として使用する場合、先週１週間の内の○○を販売した人といった検索ができる。メンバー関係検索では、メンバー同士の関係を基に検索する。例えば営業マンの顧客開拓用に関係を使用した場合には、顧客毎の見込み率を登録することで、エリア別に営業戦略を立てることができる。
【００３５】
メンバー紹介系図では、参照対象者を基に親方向へ２親等、子親等へ２親等表示をし、また、参照対象者を変更することで、全ての関係者を参照することができる。前後ｎ親等表示では、参照対象者を基に、例えば親方向へ５親等と子方向へ５親等、合わせて１０親等までの関係者を色分け表示し、画面の片側に親メンバー、子メンバーのリストを表示する。繋がり検索では、任意の２人を指定しそのメンバー間で繋がりがあるかを検索する。
【００３６】
関係管理テーブル６は、識別情報により個別の各種情報について１対１で関係付けを行うテーブルである。本発明において、識別情報は、識別子、識別番号、識別コード、ＩＤ、ＩＤ番号、ＣＩＦのほか、ＯＳが管理するファイルアロケーションテーブル（以下、ＦＡＴという）情報、固体識別可能な属性情報などを含むものである。また、その関係付けに関しては、相互の関係する方向、例えば図３に示すように親→子、主→従、上→下或いはその逆の方向の対応で、さらに必要に応じてその関係度合いが分かる関係区分などの情報を付加したものである。関係区分としては、例えば人に関する場合、一般的には上司、部下、友人、紹介、反目、学校名簿との関係には出身（ＯＢ）、人でないものとの関係には所有、会社関係には下請け、提携、取引先、人事評定に使う関係には直属、同僚、所属、金融機関が保証の連鎖関係を管理する際に使う関係には保証人、連帯保証人、所属建物、所属土地、文書・文献・図面との関係には作成者、著作者、紹介者、推薦者など、それぞれの関係に応じて設定される。このような関係管理テーブルは、その使用目的など必要に応じて複数使用される。
【００３７】
メンバー管理テーブル７は、各識別情報に対応して各メンバーの情報そのもの、あるいはその情報を取得できる関係情報、例えばＦＡＴ情報、ＦＡＴ内記録アドレス、ファイル種別、位置情報、オブジェクト、属性、属性情報などを含む情報を格納したものである。メンバーは、例えば人、文書・文献・図面、企業・本支店・支社・出張所・部署、場所・施設・機関、商品・機械・設備などのような人や物、施設、機関、組織、データ、ファイルを含む有形、無形の各種管理単位であってあらゆるジャンル、カテゴリーを含む。管理するメンバーデータは、メンバー固有の識別情報と、メンバーに応じて各種別のメンバーの区分け情報やフォルダなどの位置情報や、物理アドレス番号で表される関係情報、メンバー固有の詳細情報などを登録し、メンバー情報で直接、またはメンバー情報を取得するための情報で間接に管理する。例えば図２に示すように各メンバー毎の区分けする区分け情報は、それぞれのメンバー種別、ランク、分類、業種などの情報であり、メンバー固有の詳細情報は、摘要、履歴などの情報である。日付は、登録・更新の日付である。
【００３８】
区分け情報のメンバー種別、ランク、分類、業種などは、検索を行うため、編集出力するための条件であり、その指定の有無によって検索、編集出力の対象に含めるか除外するかなどを判断する。摘要の情報は、例えば人であれば氏名をメンバー名として、性別、生年月日、住所、電話、ファックス、メールアドレス勤務先・所属・役職・入社年月日、所属グループ、趣味、経歴・略歴、写真など、また、文書・文献・図面であればその名称をメンバー名として、文献分類、作成日・発行日、作成者・発行者・著者、内容の要約、推薦文・紹介文などを含む任意の情報である。履歴の情報は、メンバーの略歴や更新履歴などを含む情報である。
【００３９】
マスタテーブル８は、例えばメンバー管理テーブル７にそれぞれのメンバー情報に応じて最低限必要な情報の登録がなされるようにするために登録区分を設定したり、検索や編集出力の条件として指定する際に必要な各種情報の定義テーブルなどを有するものである。例えば図４に示すような種別テーブルやランクテーブル、分類テーブル、業種テーブル、関係区分テーブルなどがそれらである。
【００４０】
種別テーブルは、例えば図４（Ａ）に示すようにどのようなメンバーかを識別する種別の情報、人、会社、文書、……などを定義するものである。ランクテーブルは、例えば図４（Ｂ）に示すようなランクと優先順位を定義するものであり、一般的なランクとしては最重要、重要、顧客Ａランク、顧客Ｂランク、顧客Ｃランクなどのランクに高、中、低などの優先順位を定義し、特殊なランクとしては交渉中、再度交渉可、面識なしなど、メンバー種別が人でないものでは動産・不動産など、名寄せを処理したメンバーに使う目的のものとしては本人、名寄せ済みなどのランクに高、中、低などの優先順位を定義する。
【００４１】
分類テーブルは、例えば図４（Ｃ）に示すように地域、人事評定や社内評定に使う部課、商品、グループなどを大分類、中分類、小分類に属する項目として定義する。業種テーブルは、例えば図４（Ｄ）に示すように製造業、情報サービス業、自治体、建築・建設業、保険・金融業、農林漁業、自営業など各業種を定義するものである。
【００４２】
関係区分テーブルは、例えば図４（Ｅ）に示す関係区分とそれぞれの優先順位を定義するものであり、種別が人の一般的な区分としては上司、部下、友人、紹介、反目など、親を学校名等にする場合の区分としては出身（ＯＢ）、子を人でないものを対象とする場合の区分としては所有、会社と会社の間の関係を結ぶ場合の区分としては下請け、提携、取引先など、人事評定に使う場合の区分としては直属、同僚、所属などがある。
【００４３】
関係区分は、登録されたメンバー同士をつなぐ「手」の役目を果たし、２つのデータ（メンバー）の係わりを表すコードで定義される。人と人、人と物、物と物とを関係付ける際に、どういう関係で結ばれているのかを指定するためのものであり、関係にも深い繋がりからちょっとした繋がり、例えば人と人の場合には顔見知り程度まで、関係の度合いに差がある。関係区分は、このことを考慮して優先順位をつけているのであり、より重要でより密接な関係を上位に表示させるなどのことができるようにしている。
【００４４】
次に、本発明に係る関係付け情報管理システムの関係付け検索処理について説明する。図５は本発明に係る関係付け情報管理システムの関係付け検索処理の流れの例を説明するための図、図６は検索条件及び出力条件の例を説明するための図である。
【００４５】
本発明に係る関係付け情報管理システムの関係付け検索処理は、例えば図５に示すように検索条件の設定（ステップＳ１１）、出力条件の設定（ステップＳ１２）を行う。ここでは、検索条件として、検索を開始するメンバーに対して、例えば図６（Ａ）に示すようにどのようなメンバー種別を対象にするか、どのような分類、ランク、業種を対象にするか、さらには検索範囲、例えば何段まで、何親等までかを対象にするかを設定する。また、出力条件として、編集出力する範囲や条件を、例えば図６（Ｂ）に示すように親、子をどこまで出力するか、その際の出力色をどの色にするか、関係も併せて出力するか、親・子の方向を矢印で出力するか、親・子を左右方向に分けて出力するか、親・子を表形式で出力するか、ツリー構造で出力するか、など出力するモードやパターンをどのようなものにするかを設定する。
【００４６】
次に、検索条件に従い親から子の検索を行って（ステップＳ１３）、検索された子及びその関係をメモリに保持する（ステップＳ１４）。同様に子から親の検索を行って（ステップＳ１５）、検索された親及びその関係をメモリに保持する（ステップＳ１６）。さらに出力条件を基に次段の検索も対象になるか否かを判定し（ステップＳ１７）、次段の検索が必要な場合には、ステップＳ１３〜Ｓ１６で検索、保持された最終段のメンバーを検索キーとした後（ステップＳ１８）、それら検索、保持されているメンバーと重複する場合には検索キーを削除して（ステップＳ１９）、ステップＳ１３に戻り同様の処理を繰り返し実行する。
【００４７】
ステップＳ１７で、検索が終了したと判断された場合には、設定された出力条件に従って検索結果の編集を行い（ステップＳ２０）、その編集した検索結果を出力する（ステップＳ２１）。
【００４８】
次に、メンバーデータに登録される詳細情報について具体的に例示し説明する。摘要の情報は、項目名を限定せず、用途に応じて変更可能なものであり、例えば一般的な摘要項目においては、記録台帳番号、初回取引日、事業内容、取引内容覚書など、保険の外交営業に使用する場合においては、証券番号、入保月日、家族構成，病歴など、人事評定に使用する場合においては、社員番号、入社年月日、家族構成、特筆事項、総合評価など、金融機関が保証の繋がりを管理する場合においては、口座種別・番号、契約日、家族構成、保証債務の有無、資産など、営業に使用する場合においては、会員番号、初回訪問日、特徴、趣味・嗜好などの情報が登録される。
【００４９】
履歴の情報は、時系列の対応記録を入力できるようにするものであり、例えば一般的な項目においては、日付、打ち合わせ内容、数値目標、達成度、次期繰延べなど、営業に使用する場合においては、購入日、購入品名、数量、購入金額、ポイント数など、保険に使用する場合においては、保険額変更月日、保険名称・内容、入金回数、基本金額、合計金額など、人事に使用する場合においては、年月日、業務名、金額、自己評価、内部評価など、金融機関が使用する場合には、貸付日、担保、貸付金額、毎月返済予定額、残高などの情報が登録される。
【００５０】
関係入力の画面で繋がれるメンバー相互の関係を付加情報として関係摘要項目を入力する場合には、項目を用途に応じて設定する。例えば一般的に使用する場合には、出来事、親の注意点、子の注意点、紹介日、共通の記念日、備考日付、親→子信頼度、子→親信頼度、親密度、評価（親→子）、評価（親←子）など、取引関係に使用する場合には、受注、発注、下請、紹介日、取引日（初回）、取引日（最終）、持株、発注ウエイト、受注ウエイト、関係の変遷、取引内容など、保険に使用する場合には、共通の趣味、特技、健康状態、最新遭遇月日、初見月日、結婚記念日、親密度、知合年数、敵意、備考など、人事に使用する場合には、年度、配属部署、配属年月日、評価年月日、移動年月日、能力、協調性、頑張り、評価（親→子）、評価（親←子）など、金融機関で使用する場合には、保証内容、抵当権順位（物）、メモ、保証更新日、初回支払日、最終支払日、保証金額、保証限度額、路線価（物）、詳しい関係などが登録される。
【００５１】
本発明に係る関係付け情報管理システムの拡張した実施の形態についてさらに説明する。図７はシンクロ方式を利用する場合について説明するための図、図８は親選択集団と子選択集団を使った並列の関係付けの例を説明するための図、図９はカテゴリーの一致による並列の関係付けの例を説明するための図、図１０はＬＬ方式のデータベース間インポートの例を説明するための図である。
【００５２】
既に構築、運営されている他のデータベースに本発明の関係付け情報管理機能を持たせるシンクロ方式について説明する。既存のデータベースに関係管理機能を付加するには、それを運営するソフトウエアそのものをはじめから作りなおす方法とデータ受渡しインターフェースを持つ関係管理ソフトウエアを連結させる方法とがある。シンクロ方式は、その後者を指す。このシンクロ方式では、既存のデータベース構造の、ソフトウエアを全く改造することなく、図７に示すようにそのデータベースが持つデータ固有のＩＤ番号を関係管理テーブルに記録する。つまり、１つのデータベースに異なったソフトウエアが複数付いていることになる。しかし、データベース自体は既存ソフト用に設計されている場合が多いので、既存ソフトからの情報を受け取るインターフェース部分を関係管理ソフト側で持つ。それにより、関係管理ソフト側では、基本的なデータ表示部分を開発することなく、既存ソフトのデータ参照部分を利用できる。関係管理ソフト側では、既に登録されているデータ同士の関係付けをし、系図表示などの関係管理機能部分を受け持つ。関係管理ソフト内に既存ソフトの機能を全て取り込み（外部ソフト実行機能による）、外見的には既存システムに関係管理部分が追加されたようにすることも可能である。
【００５３】
シンクロ方式を利用するためには、既存ソフトでの追加・修正・削除によるＩＤの変更を関係管理ソフト側で監視する必要があり、既存ソフトがＩＤの変更を許容している場合には、そのＩＤ番号振りなおしに関係管理ソフト側が対応するか、既存データに不変的なＩＤを付加する必要がある。シンクロ方式を応用することにより、稼働中のデータベースシステムにとって変わる新しいシステムを導入することなく、省コストで関係管理機能を持ったシステムへと移行させることができる。
【００５４】
次に、自動関係付けについて説明する。与えられた条件に一致するもの、カテゴリー、選択したものなど、メンバー管理テーブルに登録された任意の１または複数のデータと、異なる１または複数のデータの関係付けの処理を行うようにしてもよい。この場合、直列の関係付けとして、任意の指定により選択された複数のデータを順に直列につなぐ関係付けが、ユーザ指定により予め並び替えされた順に、あるいは１つずつ順に行われる。
【００５５】
また、並列関係付けとして、親選択集団と子選択集団に、それぞれ全てのデータの中から条件指定によって抽出されたデータ、データが個別に持つカテゴリーで抽出されたデータ、任意に選択されたデータ、または全てのデータが表示され、親子の指定により関係付けを行い関係管理テーブルを作成する。
【００５６】
この場合、例えば図８（Ａ）に示すように親選択集団と子選択集団に１つずつメンバーがあったとき、それぞれを直接親と子として１対１の関係付けを行う。また、親選択集団に１つと子選択集団に複数があったとき、１つの親をそれぞれの子と１対１の繰り返しで子の件数分、１対多の関係付けを行い、親選択集団に複数と子選択集団に１つがあったとき、１つの子をそれぞれの親と１対１の繰り返しで親の件数分、多対１の関係付けを行う。
【００５７】
また、親選択集団と子選択集団にそれぞれ複数あったとき、１対多の関係付けを親の件数分、あるいは多対１の関係付けを子の件数分行ったり、図８（Ｂ）に示すように親と子の間に新規または既存のデータαを指定し、全ての親指定データはαの親、全ての子指定データはαの子として関係テーブルに保存する多対多の関係付けを行う。それぞれ関係付けは、関係付けボタンなどの一括処理起動や、ドラックアンドドロップなどで行う。
【００５８】
また、カテゴリーの一致による並列の関係付けとして、図９に示すようにメンバー管理テーブルのデータ１件１件にカテゴリー登録枠を複数個設け、馬、木、りんご、花、山などそこに登録されたカテゴリーに一致するデータを選びだして新規または既存のデータに関係付けする。例えば同じグループなど同じ属性、同じ言葉を含むデータについて同様に適用できる。
【００５９】
データベース間でのインポートについて説明する。本発明の関係付け情報管理システムを、例えばプロフェッショナル版、スタンダード版、パーソナル版のように複数のグレードに分けると、これらを利用して、例えば図１０に示すように管理者と１人または複数の部員とでＬＬ方式のような疑似ネットワークを組むことができる。ここで、プロフェッショナル版は、データ登録制限なし、履歴情報入力・検索可、関係詳細情報入力・検索可、複数データベース可、スタンダード版は、データ登録制限なし、履歴情報入力・検索可、パーソナル版は、数百件までの登録制限とし、共通のデータベースを利用するものとする。そして、プロフェッショナル版は、データベースを複数保有し、切り換えながら利用することができる。データベースは、同一フォルダ内でなければ、ＬＡＮ上の他のパソコンのどこにあっても操作対象とすることができる。
【００６０】
管理者は、プロフェッショナル版を利用することにより、自分のデータベースのほか、部員のデータベースを参照・更新可能になり、部員は、スタンダード版を利用することにより、自分のデータベースしか操作できなくなる。万が一、他の人のデータを無断コピーしてもデータベース毎に４ランクのＩＤとパスワードを設けることにより、内部に入ることをできなくする。プロフェッショナル版は、スタンダード版では見ることのできない関係詳細情報の部分の参照・更新ができるので、部員のデータベースに本人の管理外での書き込みが可能となる。
【００６１】
また、任意に指定されたデータからｎ親等までの範囲で関係付けされたデータをインポートの対象とし、取り込み側のデータ識別コードと重複しないコードを振り直してインポートする。インポートの際、取り込み側と、移植側に同一データが存在した場合には、更に「本人」（同一データであるという関係区分）で関係付けを行う。同一かどうかの判定が曖昧な場合にはユーザにメッセージするか別データと判断するかを選択させる。
【００６２】
次に、ファイル管理ソフトでの運用について説明する。図１１は関係を繋ぐ媒体について説明するための図、図１２はエクスプローラ等のファイル管理ソフトにおける関係付けについて説明するための図、図１３は多種類データのファイル内の部分的な関係付けについて説明するための図、図１４はその他のファイル等の関係付けについて説明するための図、図１５は複数の管理テーブルを設けて関係付けする場合について説明するための図である。
【００６３】
ファイル管理ソフト（エクスプローラ等）の現状を見ると、ファイル管理ソフトは、全体を１つの大きな収納庫と考え、フォルダという分類可能なコンテナボックスにファイルを分けていれるだけでファイル関係を探すことはできない。しかし、ファイルを管理している上で、ファイル同士の繋がりが分かった方が整理しやすいというのは万人の望むところである。
【００６４】
例えばワードで作成された文書Ａがあり、それを修正した文書Ａ′があった場合、２つの文書に関係があるというのはファイル名か、同一フォルダに保存されているか、プロパティに関係があることを記録する他はない。もし、プロパティで識別するならば、Ａ''、Ａ''' 、Ａ''''などが作成された場合、後から作成された文書が前に作成された文書と関わりがあることを、それまで作成された全ての文書のプロパティに記入していかなければならない。
【００６５】
Ａ''''を作成した時、Ａ''' のプロパティしか変更しなければ、ひとつずつ遡ってプロパティをみていかなければ、ＡとＡ''''に関係があることが分からない。同様に、異なるファイル形式（文書、表計算、画像、ＣＡＤ等）に関係があることは、カテゴリーで分けると作成者でまとめられない。ファイル種別でわけると、業務での統一ができないなどの不便が生じる。
【００６６】
そこで、ファイル管理ソフトに本発明の関係付け情報管理機能が加われば、格納してある場所はカテゴリー別や作成者別など分かりやすいフォルダに整理しておき、それに関する各種ファイルの関係図を表示することによって、変更の履歴や、業務プロジェクトでの括りができるようになる。
【００６７】
ファイル管理ソフト内に、自動関係付け機能、親子孫のような系図表示、前後５親等のようなツリー系図表示、繋がり検索のような一定の親等間のルート探索機能、関係入力画面などの機能を備える。関係付けは、関係入力画面等を利用しても、ドラッグアンドドロップでもできる。エクスプローラ上で関係付けされたファイルがコピーされた場合、関係付け全てをコピーするわけではなく、元ファイルと複製という関係付けでつなぎを作る。ファイルが隠しファイルであった場合には、隠しファイルを見せない設定の時には関係付けもされないような表示にする。関係付けは、ファイル名ではなく、ファイルを識別情報とし、フォルダなどの位置情報や物理アドレス番号などを利用することもできる。
【００６８】
関係をつなぐ媒体について説明する。関係をつなぐという本発明の関係付け情報管理機能の思考に媒体も含めると、音声情報、時間情報、位置情報などを含め、その一部を取り出しても独立したオブジェクトとして特定できる属性または属性を持つ情報を対象とし、データベース等の配列に入れる。例えば図１１に示すように表計算ソフト（Ａ）の任意のシートや選択されたセル、ファイル管理ソフト（Ｂ）のファイル全体、ＣＡＤ図面（Ｃ）の図面内の任意のオブジェクト、画像（Ｄ）の画像全体または任意の選択された部分に関して、配列の背番号もしくはアドレスなど、それぞれを特定できるキーを識別子として用い、メンバー管理テーブル（Ｆ）に関係情報を格納し、関係管理テーブル（Ｅ）で関係付けを行うことにより、エクスプローラに限らず新規または既存のアプリケーション内で利用可能とする。
【００６９】
エクスプローラ等のファイル管理ソフトにおける関係付けについて説明する。エクスプローラ等において、表示されるフォルダとファイル名は、ＯＳが管理するファイルアロケーションテーブル（以下、ＦＡＴという）などのディレクトリパスに記憶している。このようなエクスプローラ等に本発明の関係付け情報管理機能を持たせるためには、メンバー管理テーブルをＦＡＴ以外に持つ方法▲１▼、ＦＡＴ自体をメンバー管理テーブルとして利用する方法▲２▼、関係管理テーブルがＩＤを管理する考え方ではなくＦＡＴ情報そのものを持って関係管理をする方法▲３▼を利用することができる。
【００７０】
メンバー管理テーブルをＦＡＴ以外に持つ▲１▼の方法では、図１２（Ａ）に示すようにメンバー管理テーブルでＩＤと、ＦＡＴに記録されているファイル情報をそのままコピーして利用するか、ＦＡＴ内の物理的な記録位置アドレスなどの情報を利用する。また、▲２▼の方法には、図１２（Ｂ）に示すようにＯＳ設計の段階でＦＡＴそのものの形状を変更してＩＤを持つようにする場合と、ＦＡＴ内の物理的な記録位置アドレスなどの情報を関係管理テーブルに直接入れて関係付けをするか、ＦＡＴ情報そのものを関係管理テーブルに格納して関係付けする場合などがある。そして、▲３▼の方法では、ＦＡＴ情報それ自体が１件１件を識別できる内容になっているので、図１２（Ｃ）に示すように特別にＩＤをつけなくてもそのまま関係管理テーブルに記録することによって関係管理ができる。この方法では、関係管理テーブルにＦＡＴ情報またはＦＡＴ内の物理的な記録位置アドレスを格納するので、ファイルやフォルダの変更時に関係管理テーブルの同時変更が必要になる。
【００７１】
関係をつなぐ対象は、ファイルやフォルダを問わず、ネットワーク上であってもファイル管理ソフト上で処理可能なものであれば実施が可能である。エクスプローラと同様の機能を持つ個別アプリケーションに付属しているエクスプローラライクのものは、ＦＡＴの代わりに独自のエリアにファイル情報を持っているが、機能としては同じである。
【００７２】
具体的な実行例を説明すると次のようになる。まず、画面のどこかに関係付け対象とすべきファイル等を指定するエリアを設け、入力またはドラッグアンドドロップ等で関係付けをする対象を入れる。各指定領域にはリストボックスのように、１つまたは複数の指定ができ、先に図８で説明したように１対１、１対多、多対１、多対多の関係付けができる。そこで、任意のファイル等を選択し、例えば系図表示ボタンまたは右クリックからのメニューに系図表示を選択して関係を表示させる画面へ移行させる。さらに、２つ以上のファイル等の関係を追跡する繋がり検索画面や前後ｎ浸透全ての関係表示のできる画面を持ち、任意の画面から進むことができる。関係付けされているファイルやフォルダ等がコピーされた時は、関係もコピー元と同様に継承されるか、コピー元とコピー先のみの関係付けかを選択することができる。
【００７３】
多種類データのファイル内の部分的な関係付けについて説明する。多種類データの部分的な関係付けは、ファイル名やフォルダ名の関係付けのみだったファイル管理ソフトの場合と違い、関係するアプリケーションとそれにより作成されるデータファイルに関係情報や関係情報処理機能を持たせなければならない。これは、関係の管理をエクスプローラのようなＯＳ側の管理ソフトに任せる場合やそれぞれのアプリケーションの内部だけでデータの関係付けをする場合においても同様である。
【００７４】
例えば画像処理ソフトとそれにより作成された画像ファイルを例に説明する。一般にアプリケーションで作成されたファイルの持つ情報は、画像情報のほかに、形状・オブジェクト、カラー・彩度・明度・アルファチャネル・レイヤ情報・変更履歴のような属性情報を持つファイル形式（フォトショップのＰＳＤ等）から、画像情報のみを持つ形式（ＢＭＰ等）といったように、利用環境によって様々である。そのファイル形式と、使用するアプリケーションによって、ファイル内に保有できる属性は、情報量が違っている。画像内で範囲切り出しされたものを、クリップボードを経由してコピー・ペーストするという場合には、コピーされた瞬間のデータのみを対象とすればよいので、その際の属性は引き継いでも、ファイル情報などは継承しなくてもよい。しかし、関係を結び、継続的な関係を維持していくには、内容の変更や関係範囲の変更・移動に対応しなければならない。従って、ファイル自体に、関係付けされた部分がどの範囲のどういう属性情報だったかを記憶しておく必要があり、画像処理ソフトでは、ファイルに保存された関係情報を表示し、変更を監視する機能が必要になる。ここでメンバー管理テーブルを用いることにより、基本的なデータを保存するのではなく、関係付けをすべき選択範囲が存在する場所やデータの特性などが記録され、データの本体はオリジナルファイルの中に存在する。勿論、データ自体をオリジナルファイルからコピーしてメンバー管理テーブルに記録することも可能である。
【００７５】
即ち、図１３に示すようにファイルに関係指定範囲情報を持ち、メンバー管理テーブルと関係管理テーブルを使うほか、メンバー管理テーブルは使わず、関係管理テーブルのみで関係管理をする場合、ファイルには持たず、メンバー管理テーブルまたは関係管理テーブルで情報管理をする場合などそれぞれの組み合わせに応じた利用環境がある。
【００７６】
次に、関係レイヤを設けた場合の例を説明する。画像データに重ねて透明の関係指定範囲を表示する関係レイヤを設ける。画像処理ソフト内で関係付けする範囲を指定し、その範囲を関係レイヤに表示する。指定された範囲の持つ属性には、選択された形状・オブジェクトのほか、カラー・彩度・明度・アルファチャネル・レイヤ情報・変更履歴などアプリケーションによって保有できる情報量が違うので、ここでは選択範囲とその他の属性として説明する。画像処理ソフトに関係情報設定ボタン等を設け、それがオンの状態で範囲を選択すると、メンバー管理テーブルにＩＤ、ファイル種別、ディレクトリパス、ファイル名、選択範囲、その他の属性などを書き込む。同時に、選択範囲をメンバー管理テーブル書き込みのときに取得したＩＤを指定範囲の識別名として画像ファイル内に選択範囲情報と共に記録する。メンバー管理テーブルに書き込まれた個別情報は、関係入力ボタンまたは右クリックのメニューなどによってＯＳのファイル管理ソフトの関係入力の画面で、その他の情報と関係付けをし、その関係を関係管理テーブルに書き込み。画像データの関係指定範囲に含まれる部分に修正が加えられた場合には、画像処理ソフトの監視機能によって関係指定範囲の変更をするかどうかを訪ねてくることにより、変更があれば、その情報を記録している画像ファイルやメンバー管理テーブルの変更も行われる。
【００７７】
メンバー管理テーブルを用いない場合には、直接、関係管理テーブルにファイル種別、ディレクトリパス、ファイル名、選択範囲、その他の属性などを書き込んで関係付けをしてもよい。しかし、同じファイルを同じ指定範囲、同じ続低で違う関係付けをするための独自のメンバーを考えるならば、ＩＤを含め、メンバー固有の識別可能な形式にして保存しなければならない。
【００７８】
画像ファイルに関係情報を記録しない場合には、それらの全ての情報をメンバー管理テーブルまたは関係管理テーブルに記録し、画像処理ソフトは、関係レイヤなどに表示するための情報を画像ファイルからではなく、それらの外部テーブルから受け取る。ＯＳや統一管理ソフトで管理せず、アプリケーションで単独に管理せず、画像アプリケーション内で単独管理する場合には、アプリケーション独自の関係管理テーブルとメンバー管理テーブルを持ち、関係入力や系図表示等の機能は画像処理ソフト内に装備することになる。
【００７９】
以上は画像についてであるが、ワープロソフトと文書ファイル、表計算ソフトとブックファイル、ＣＡＤソフトと図面データ、音源ソフトと音源データなど、同様の組み合わせで記録と監視機能が必要になる。図１４に示すようにメンバー管理テーブルを利用する場合には、ＩＤ、ファイル種別、ディレクトリパス、ファイル名、選択範囲、その他の属性、例えば表計算であれば、シート、セル、書式情報など、ＣＡＤであればレイヤ、線種、色、形状など、文書であれば、ページ、書式情報など、音源であれば、時間、波長、音域情報などを記録する。メンバー管理テーブルを迂回せず直接関係管理テーブルに書き込む場合には、関係管理テーブルに、ファイル種別、ディレクトリパス、ファイル名、選択範囲、その他の属性などを記録する。それらは、データ同士が識別可能な形であればよいので、パソコン内部の絶対アドレスなどといった、関係をつなぐためのビット単位のメンバー同士の関係まで表すことのできる表現を用いても応用できる。それぞれの入力、表示手段は、画面、印刷媒体のほかに、Ｗｅｂ、ＡＳＰ、ＰＤＡなどの外部通信手段を利用したものでもよい。基本的には、関係管理テーブルで親子関係を繋いだデータ同士を系図型に表示し、いもづる式に辿っていくことができる機能は、各ソフトウエアのデータ側でもコンピュータのＯＳ側でも持つことができる。その他、任意のデータ間の関係を追跡し表示する繋がり検索機能を持つこともできる。
【００８０】
複数の管理テーブルを設けて関係付けする場合について説明する。関係付けの対象は、登録されたメンバー同士であるが、履歴情報同士の関係を持ちたいときや、履歴と関係情報や、画像と他メンバーの摘要項目などを関係付けたい場合など、１つのメンバー管理テーブルや関係管理テーブルでは表すことができない。これに対応するため、図１５に示すようにメンバー管理テーブルや関係管理テーブルは、１つのシステム内に１つではなく、複数存在することもできる。Ｎ番目のメンバー管理テーブルは基本となるメンバー管理テーブルのどの識別情報（ＣＩＦ）のどの情報のどの部分に関するものかという属性まで含んだ形で記録され、Ｎ番目の関係管理テーブルには、部分関係入力用の画面によって関係付けられた親子関係が記録され、部分関係表示用の系図に表示される。こうすることにより、頭だけの関係しか見ることのできなかった関係系図のほかに、それぞれの部位の繋がりまで見ることができるようになる。
【００８１】
次に、本発明を系図型人脈管理システムとして適用した場合の実施の形態を説明する。本実施形態においては、３次元でしか表せなかった関係図をコンピュータの中で管理し、その一部を取り出して表すことにより、２次元の紙の上で表現することができるようにした。以下に、その考え方を記述する。
【００８２】
本実施形態のシステムは、データ入力の際、条件検索やフリガナ検索などの検索機能を充実させ、重複データの登録を極力させないようにする。そのため、関係付けをしようとするデータが一点集中型で管理され、無駄な繋がりが作成されにくくなっている。また、重複データがあった場合にも、それらを「同じ人のデータ」という関係でつなぐことにより、系図を作成したときには必ず近所に表示されていることになる。
【００８３】
一般の顧客管理の考え方からいえば、図１６に示すように、データはカード形式に保存されているので、個別データの一部に次に繋がるデータの顧客番号等を記憶しておくという手法をとる。本実施形態のシステムでは個別データと関係データを完全に分離した形で管理している。関係のデータも１：１で保存する。関係を表す基本のファイル（データベースのテーブル）は親の顧客番号と子の顧客番号と関係コードを持っている。
【００８４】
図１７は、そのテーブルの一例を示すものである。それを、親順に並べると、一人の人に複数の子がいることがわかる。図１７の例でいえば、図１８に示すようにＡさんには、ＢさんとＤさんという子関係の人がいる。Ｃさんには、Ａさんという子がいて、Ｄさんには、ＢさんとＥさんという子がいる。さらに、このファイルを子順に並び替えると、図１９に示すように、Ａさんには、Ｃさんという親がいる。ＢさんにはＡさんとＤさん、ＤさんにはＡさん、ＥさんにはＤさんという親がいることになる。
【００８５】
これをＡさんを中心に親子関係を見ると、図２０のようになる。本実施形態のシステムはこの連鎖を繰り返しながら、系図を作成する。ただし、系図の中に同じ人が現れた場合には、系図の中心人物により近い場所に出現したほうを正規のルートとして、それ以降のつながり表示は正規ルートと重なるので、「…」で省略している。これにより、同じ人が系図の中に何度現れても（循環しても）、確実に関係ルートを探し出せる。
【００８６】
さらに、本実施形態のシステムには、繋がりをただ繋がっているというだけではなく、どっちからどっちへ繋がっているという方向性を持たせている。それは、系図をツリー構造で表すときに、非常に大切な意味を持つ。前述のように、親を元に並び替えをし、子を元に並び替えをすることにより、繋がりの方向性がはっきりし、中心になる人を決めることで、それに繋がる人を引き当てることが可能になるからである。
【００８７】
一般の系図のような、「親→祖父→曽祖父」といった直系重視から、「親→子→子→親→親」といった単発的な組み合わせでの連鎖のほうが、より遠くまで関係をつないで見ることができる。また、親子の方向性を持たせたことで、対等な関係でしか表現できなかったつながり部分を、部下・上司・恩師・教え子のように、明確な関係を表現できるようになった。そして、それぞれの関係区分に優先順位をもたせたことにより、繋がりの強さを判断することができる。
【００８８】
図２１に示すように、本実施形態のシステムの利用者がＸさんに繋がりを持ちたいと思ったとき、そのどちらのルートのコネを利用すればより効果的かがわかる。このように、繋がりを親子で表すことにより、その関係を区別でき、さらに繋がりの深さを区別できることになる。また、系図を世代で表すと「親→祖父→曽祖父」という直系での見方になるので、上は上、下は下という完全な流れができてしまう。しかし、親等で表すと、「親」と「子」しかないので親が上から下、子が下から上という概念を捨ててしまえば、図２２に示すように、関係を蛇腹折のように折りたたむことができるようになる。
【００８９】
これを利用して、本実施形態のシステムでは系図を作成するとき、図２３に示すように、最も左に系図の中心になる人を置き、その人から、１親等目を親子を問わず、右に１段ずれて表示する。２親等目も親子を問わず、右にもう１段ずれて表示する。これを繰り返すことによって、系図はツリー構造に展開し、平面状に書き表すことができるようになる。このようにして、系図を世代ではなく、親等で表すことにより、親方向と子方向への繋がり方向を固定化せず、自由に追跡し、ツリー表示することができる。
【００９０】
さらに、本実施形態では、関係のみを表すファイルに親子のつながりだけを入れてあるので、「親→子→親→子」と機械的に見ていくだけで、関係の連鎖は続く。ただ、画面表示や印刷表示の制限から、一度に見られる範囲を区切っているだけであるので、区切られた所から先に関係があれば、そこから同様に「親→子→親→子」と機械的に追跡を繰り返し、系図に作り上げていくことは可能である。それを、実際に表しているのが、「メンバー紹介系図（親・子・孫）」である。直系のみの表示であるが、関係が続く限り、どこまでも表示することができる。
【００９１】
さらに、関係検索という機能では、図２４に示すように、任意の二人を指定して、その二人に関係ルートができ上がっているかどうかを追跡することができる。最短の関係のほかに、指定した親等内ですべてのルートを探し出し、そのルートを系図表示する。ここでは参照対象メンバーから親方向へ５親等と子方向へ５親等、あわせて１０親等のつながりを持つすべてのメンバーを表示している。図２５に示すように、５親等とは関わりが５人目の人を指す。参照対象者から見たとき、Ａさんは６親等目になるので系図の範囲外になるが、Ｂさんを参照対象者にすれば５親等目になるので系図に表れてくる。端同士のＣさんから見て、Ｄさんは１０親等目、１１人のつながりが発見できる。このように、系図の表示範囲外になったメンバーも、参照対象をずらして系図を作成することにより表示が可能となる。
【００９２】
以下、実施例について説明する。図２６は本実施形態の系図型人脈管理システムのソフトウエア構成を示すシステムブロック図である。データベースとしては、氏名または団体名、住所、電話番号等の個人・団体のメンバー情報を格納するメンバー管理テーブルと、そのメンバー管理テーブルに登録されたあるメンバーとそのメンバーに関係する他のメンバーの二者の関係を親子関係で規定するとともにその関係の種類および関係の優先順位を表す区分コードを記入する関係管理テーブルとを有し、マスタテーブルには、区分コードがどのような関係を表すかおよびどのような優先順位を表すかを規定する区分テーブル等の参照テーブルを有している。
【００９３】
以下に、本実施形態の実施例のシステムにおける基本的な操作手順とデータ処理について説明する。図２７は本システムのメインメニュー画面を示すものである。
１．メンバー管理
・メンバー追加
・メンバー修正
・メンバー削除
上記の３つは個人や団体の情報の入力・更新・削除を行う。
・関係入力
・系図表示
上記の２つはメンバー同士の繋がりや系図を登録・表示する。
２．データ資料
条件を指定して、登録されているメンバーの内該当するメンバー群を抽出し、帳票やテキストファイルに出力する。
３．基本設定
システムの基本となるコード設定などを登録・管理する。
４．システム管理
データベースの保守管理をする。
【００９４】
図２８は図２７のメインメニュー画面の「メンバー追加」ボタンを押したときに現れる入力画面を示す。この画面から、個人登録か団体登録かを選択し、個人登録の場合は氏名、フリガナ、生年月日、男女の別、住所、電話番号、ファックス番号を入力する。また、このメンバーのデータを他の閲覧者に公開するか非公開にするかを選択する。この入力画面における特殊な入力項目について説明する。
【００９５】
１．ＢＯＸ
ＢＯＸとはランクコードのことである。入力しようとしているメンバーが、ユーザにとってどういう相手なのかを表す。図２９、図３０にその例を示す。メンバーのデータカードをランクの箱に仕分けして保存するという意味で、ＢＯＸと呼ぶ。ＢＯＸは優先順位をつけることが可能である。
【００９６】
本実施形態のシステムは、顧客のみを管理する顧客管理ソフトとは異なり、面識はなくとも将来つながりを持ちたいと思っている人や、その人の関係者を入力しておくことが重要になる。ＢＯＸに「面識なし」という意味のランクを設けておけば、現在の顧客との区別をつけることができる。登録データを増やし、関係をつないでいくことにより、つながりを希望していた人への人脈ルートが出来上がる可能性が広がる。その場合は「関係検索」機能によって、人脈ルートがつながったかどうかを検索することができる。
【００９７】
２．分類コード
分類コードは登録メンバーの統計資料作成や所属分類に振り分けるために設けている。入力しようとするメンバーが、大分類・中分類・小分類で区分される事項のいずれに属するかを指定し、件数や比率をグラフ等で表示する。この分類コードの例を図３１に示す。分類項目には「都道府県・市町村・町名」などの住所によるもののほか、所属部署や管轄地区など集計目的に合わせて三段階に分類する。
【００９８】
本実施形態のシステムを人脈ではなく、物品管理などに利用する場合には、地区ではなく、管理分類として応用することも出来る。
例としては、在庫管理：倉庫、棚、箱
カー用品：メーカー、パーツ、部品
動植物  ：目、科、属
等である。
【００９９】
３．関係区分
関係区分は、図２７の「基本設定」ボタンを押下したときに表れるメニューの一つである。この関係区分は、登録されたメンバー同士をつなぐ「手」の役目をする。人と人を関係付ける際に、どういう関係で結ばれているのかを指定するために設けている。関係にも、深いつながりから、ちょっとした顔見知り程度まで、関係の度合いによって優先順位をつけることが可能である。その例を図３２、図３３に示す。
【０１００】
２つのデータのかかわりを表すコードであるので、別々のデータを同じものとするという指定も可能になる。たとえば、結婚による姓の変更、企業やグループの名称変更など、日常的によく見られる出来事である。この場合のように、旧名のときの内容と新名での内容をそれぞれ残す方がメンバーの状況を把握しやすいことが多々ある。
【０１０１】
本実施形態システムは、関係区分に既定初期コードとして「本人」という関係を用意している。一般の顧客管理ソフトであれば１つのデータにまとめて登録しなければならないが、本実施形態のシステムはデータ同士を「本人」として関係付けてしまえば、データを一本化する必要はない。不確かなデータや間違って重複して登録されたデータもデータ同士をすべて「本人」として関係付けてしまえば、見落とすことはない。
【０１０２】
「本人」としてつなぐメンバー同士のデータは、どれかを主データに、その他を従データとして１親等でつなぐ。どのデータが主データかが判別しにくい場合には、ＢＯＸに「重複データ」を意味するコードを設け、従データのＢＯＸ欄に指定すると見分けやすくなる。また、統計資料のデータ件数に重複を避けたい場合にも、分類コードに「重複データ」という意味の分類を設けて、従データの地区に指定すると、不要のカウントはそちらに集計される。
【０１０３】
人脈であるから、仲が良いという情報だけではなく、犬猿の仲という関係が登録されていてもかまわない。同じ集まりに出席を呼びかけてはいけない場合や、その人の前では話題にしてはいけない人など、要注意の関係も入れておくと非常に役立つ。また、メンバーが転勤や退職などで関係が途切れたとしても、その関係者と新たな関係ができることがあるので、関係の削除はせず、残したままとすることが好ましい。
【０１０４】
次に、関係入力について説明する。図２８の下に表れる「関係入力」ボタンを押下すると、図３４に示す関係入力画面が表れる。ここでは、メンバーとメンバーのつながり及びその内容を設定する。ただ、ＡさんとＢさんがつながっているというだけではなく、どちらから、どちらへつながっているか、どういう関係なのかを指定する。どちらからどちらへは、主となるメンバーを親、従となるメンバーを子として関係を考える。親から見て、子のメンバーとどういう関係なのかをあらかじめ考えられるパターンを前述の関係区分に登録しておく。
【０１０５】
図３４の画面上部には、この画面の前処理であるメンバー特定検索で選ばれて来たメンバー（基準メンバー）が表示されている。画面下半分には、対象メンバーに関係づける人の候補を一覧する。その間に上と下の関係を示す「親子切替」ボタンとリストボックスがある。「親子切替」ボタンには上下のどちらを親（主）にするかを設定し、リストボックスには関係区分が表示されるので、親からの関係を選ぶ。
【０１０６】
ｉ）．「関」ボタン
対象メンバーの１親等に関係づけされているメンバーを表示する。
現在の関係づけの参照／変更／削除の際に使用する。
リストの中から関係の変更又は削除する人を選ぶ。
【０１０７】
ｉｉ）．関係更新／削除ボタン
変更の場合は、関係内容を変更して「関係更新」ボタンをクリックする。
関係を削除する場合は、「削除」ボタンをクリックする。
関係の削除は、データそのものを削除するわけではなく、つながりをなくしてしまうだけのことで、関係を削除してもデータは残る。しかし関係を削除された者どうしは別ルートでのつながりがない限り、同じ系図に現れることはない。関係は、前述の「関係区分」でも述べたが、犬猿の仲や縁切れという関係も人脈の一種ととらえて極力、削除しないようにする。
【０１０８】
次に、本実施形態の特徴である系図表示について説明する。本実施形態のシステムには、２種類の系図表示方式がある。１つは、図３５に示す「メンバー紹介系図（親・子・孫）」である。参照対象者を中心に親と子と孫を表示する。この系図表示は「参照対象変更」ボタンをクリックして参照対象を表示されている親・子・孫にずらして行くことで、系図の中心の人を変えながら、そのメンバーにつながるすべての関係者をいもづる式に表示していく。
【０１０９】
登録されているメンバーすべてが、切れ目なしに関係付けされていれば、途切れることなく表示されるが、関係付けのグループが異なれば、参照対象を移動しても系図はつながることはない。この場合は別グループのメンバーを選択して系図表示に入れば、同様に関係者をいもづる式に表示していく。データベースの中では、小さな集団がいくつも形成されて少しづつ大きく成長していく。
【０１１０】
また、この系図の表示方式では、図３６に示すように、限られたメンバーしか表示されてはいない。表示されているのは直系の親・子・孫のみである。親から別につながっているＡ、子から別につながっているＢとその直系は、参照対象を変更することにより表示されるようになる。
【０１１１】
この「メンバー紹介系図（親・子・孫）」を検索処理するための手順の概要は、次の通りである。
（１）特定の条件を指定して抽出されたメンバーリストで選択されているメンバーのコードを参照対象コード（以下本人ＣＩＦ）とする。
（２）本人ＣＩＦを元に参照対象の情報をメンバー管理テーブルより取得し、参照対象表示域に格納する。
（３）本人ＣＩＦを元に関係管理テーブルより参照対象者の親関係にあたる全てのメンバーのコード（以下親ＣＩＦ）と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから親メンバーリスト表示領域に格納する。
（４）本人ＣＩＦを元に関係管理テーブルより参照対象者の子関係にあたる全てのメンバーのコード（以下子ＣＩＦ）と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから子メンバーリスト表示領域に格納する。
（５）子メンバーリスト表示領域の最上にある子ＣＩＦを元に関係管理テーブルより子メンバーリスト表示領域の最上にある子メンバーの子関係にあたる全てのメンバーのコード（以下孫ＣＩＦ）と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから孫メンバーリスト表示領域に格納する。
（６）表示領域を表示する。
（７）子メンバーリスト表示領域の中で最上以外のメンバーをユーザが選択したかどうかを判断する。選択したらステップ（８）に進む。選択しなければステップ（９）に進む。
（８）選択された子ＣＩＦを元に関係管理テーブルより子メンバーリスト表示領域の選択された子メンバーの子関係にあたる全てのメンバーのコード（以下孫ＣＩＦ）と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから孫メンバーリスト表示領域に格納し、再度表示する。
（９）参照対象変更ボタンを押下したかどうかを判断する。押下したらステップ（１０）に進む。押下しなければ処理を終了する。
（１０）親メンバーリスト表示領域と子メンバーリスト表示領域と孫メンバーリスト表示領域の中でユーザが選択したメンバーのコードを本人ＣＩＦとする。ステップ（２）に戻る。
【０１１２】
この親子孫表示画面では、直系の上に１世代、下に２世代しか表示されない。この表示されない部分を補っているのが、もう１つの系図、「メンバー紹介系図（前後５親等）」である。その例を図２３に示す。この「メンバー紹介系図（前後５親等）」は、図３５の「メンバー紹介系図（親・子・孫）」で決定した参照対象を中心に前後５親等の範囲で、すべての関係者を系図化する。
【０１１３】
本実施形態のシステムのような人脈を表現する系図は、家系図のように親が上で子が下といった、一方向の流れで表すことは不可能である。それに代わるものとして、本実施形態のシステムでは、図３７に示すように、系図の中心とする人を一番上の左端に表示する。１親等目を左に１段下げた位置に表示している。同様に５親等目までを１段ずつ左へ下げながら表示している。横向きの矢印は親から子への関係を表しており、「…」は他に最短ルートがある事を示している。
【０１１４】
例えば、（い）の「坂本竜馬」には「…」がついている。（い）の「坂本竜馬」は「勝海舟」から見て２親等目にあたるが、他のルートを見てみると、１親等目の（ろ）にも「坂本竜馬」が表示されている。（い）より（ろ）の方が参照対象の「勝海舟」により近いので、「…」のついている箇所は参考ということになる。＋印はこの下にも人脈が続いていることを意味している。隠したい人脈や複雑な人脈の場合、この＋機能を使って系図を自由に再構成することができる。
【０１１５】
このメンバー紹介系図を生成するための手順の概要は、次の通りである。
（１）参照対象ＣＩＦをもとにメンバー管理テーブルの参照対象メンバーの情報を取得し、ツリービュー領域に表示する。
（２）１親等洗い出し
（２−１）参照対象のコード（ＣＩＦ）をもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域２列目に１メンバー１段で参照対象の下に追加表示する。
（２−２）参照対象ＣＩＦをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域２列目に１メンバー１段で親メンバーの下に追加表示する。
【０１１６】
ただし、ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に「…」を付加する。
（３）２親等洗い出し
（３−１）２列目に表示されている１親等のメンバーについて上から順にそれぞれ次の処理を行う。
（３−２）１親等者ＣＩＦをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域３列目に１メンバー１段で該当の１親等のメンバーと次の１親等のメンバーの間に挿入表示する。
【０１１７】
ただし、直系の２親等前（参照対象）が同じメンバーなら「２親等洗い出し」はしない。
（３−３）元にする１親等の該当段目のメンバーに「…」がついていれば「２親等洗い出し」はしない。
（３−４）ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に「…」を付加する。
（３−５）１親等者ＣＩＦをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域３列目に１メンバー１段で該当の１親等のメンバーと次の１親等のメンバーの間に挿入表示する。
【０１１８】
ただし、直系の２親等前（参照対象）が同じメンバーなら「２親等洗い出し」はしない。
（３−６）元にする１親等の該当段目のメンバーに「…」がついていれば「２親等洗い出し」はしない。
（３−７）ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に「…」を付加する。
（４）ｎ親等洗い出し。（ｎ＝３）とする
（４−１）３列目に表示されている２親等のメンバーについて上から順にそれぞれ次の処理を行う。
（４−２）２親等者ＣＩＦをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域４列目に１メンバー１段で該当の２親等のメンバーと次の２親等のメンバーの間に挿入表示する。
【０１１９】
ただし、直系の２親等前（１親等者）が同じメンバーなら「３親等洗い出し」はしない。
（４−３）元にする２親等の該当段目のメンバーに「…」がついていれば「３親等洗い出し」はしない。
（４−４）ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に「…」を付加する。
（４−５）２親等者ＣＩＦをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域４列目に１メンバー１段で該当の２親等のメンバーと次の２親等のメンバーの間に挿入表示する。
【０１２０】
ただし、直系の２親等前（１親等者）が同じメンバーなら「３親等洗い出し」はしない。
（４−６）元にする２親等の該当段目のメンバーに「…」がついていれば「３親等洗い出し」はしない。
（４−７）ツリービュー内にすでに同じＣＩＦのメンバーが表示されていれば名前の後に「…」を付加する。
（５）以降、ステップ（４）の数を累進させて、４親等、５親等も同様の処理をする。
【０１２１】
次に、本実施形態のもう一つの特徴である関係検索機能について説明する。「関係検索」ボタンをクリックすると図２４に示すメンバー関係検索の画面が表示される。ここでは２人（個人・団体とも可）を指定してメンバー間につながりがあるかを探す。上段には参照対象メンバーが入っているが「条件検索」ボタンで検索画面へ移動するので、上段・下段ともにメンバーを任意に変更することができる。１親等から１０親等までの範囲で関係を追跡するが、最短ルートを見つけるのか、全てのルートを見つけるのかをラジオボタンで指定する。「全ての関係を表示する」にチェックして実行ボタンをクリックすると、図２４の系図の左上にあるリストボックス内に親等数と、同親等内での連番が表示される。図３８はその説明図であり、左右両側の２人のメンバー間の系図の例を示している。
【０１２２】
リストボックス内の参照したいルートを選択すると、そのルートの系図が表示される。「詳細」ボタンは他の画面と同様に、クリックをすると系図内で選択された人の登録内容が表示される。「印刷」ボタンは、表示されている追跡結果をプレビューし、プリンタで印刷可能な状態にする。
【０１２３】
この関係検索機能の処理手順は次の通りである。
（１）関係の追跡をする二人のメンバーのうち、一方を正、他方を副とし、正メンバーに副メンバーが繋がっているかを追跡するため、設定条件を保存し、検索結果を一時保存するメモリ内の配列エリアを初期化する。なお、ユーザによってキャンセルボタンが押されたときは処理を中止し、メモリ内に格納されている途中までの結果を破棄する。
（２）処理を行う際に、ユーザが指定した、最大何親等まで探すか、最短ルートか全てのルートかの設定条件を保存する。ここでは、４親等までの全てであるとして説明する。
（３）正メンバーの親子の関係である１親等目を抽出する。
（３−１）抽出された１親等目のｎａのレコード数のうち、ｉａ番目（ｉ＝１〜ｎ）は副メンバーかを判断する。
（３−１−１）副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の１親等目のレコードに対し、（３−１）のステップの処理を実行する。
（４）副メンバーでなければ、１親等目のｉａ番目のメンバーの親子の関係である２親等目を抽出する。
（４−１）抽出された２親等目のｎｂのレコード数のうち、ｉｂ番目（ｉ＝１〜ｎ）は副メンバーかを判断する。
（４−１−１）副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の２親等目のレコードに対し、（４−１）のステップの処理を実行する。
（４−２）副メンバーでなければ、２親等目のｉｂ番目と同じメンバーがルート中の上位に存在しないかどうか判断する。
（４−２−１）存在していれば、その処理を中断し次の２親等目のレコードに対し、（４−１）のステップの処理を実行する。
（５）存在していなければ、２親等目のｉｂ番目のメンバーの親子の関係である３親等目を抽出する。
（５−１）抽出された３親等目のｎｃのレコード数のうち、ｉｃ番目（ｉ＝１〜ｎ）は副メンバーかを判断する。
（５−１−１）副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の３親等目のレコードに対し、（５−１）のステップの処理を実行する。
（５−２）副メンバーでなければ、３親等目のｉｃ番目と同じメンバーがルート中の上位に存在しないかどうか判断する。
（５−２−１）存在していれば、その処理を中断し次の３親等目のレコードに対し、（５−１）のステップの処理を実行する。
（６）存在していなければ、３親等目のｉｃ番目のメンバーの親子の関係である４親等目を抽出する。
（７）抽出された４親等目のｎｄのレコード数のうち、ｉｄ番目（ｉ＝１〜ｎ）は副メンバーかを判断する。
（７−１−１）副メンバーであれば、正メンバーからのルートを前記メモリ内の配列エリアに保存し、４親等の次のレコードに進む。
（７−２）副メンバーでなければ、４親等の次のレコードに進む。４親等のレコードがｎ迄終われば、３親等のレコード数を１つ累進させて処理を行う。
（７−３）３親等のレコード数がｎ迄終われば、２親等のレコード数を１つ累進させて処理を行う。
（７−４）２親等のレコード数がｎ迄終われば、１親等のレコード数を１つ累進させて処理を行う。
（８）前記メモリ内の配列エリアに保存されている検索結果をルートの親等数の少ないものから並べ直す。
（９）検索結果の１番目をツリービューに表示する。
（１０）ユーザが検索結果表示の変更をプルダウンリストボックスで指示したときは、検索結果の中のユーザの選択したルートをツリービューに表示する。
【０１２４】
以上の実施形態では、複雑に絡み合った関係情報に対し、部分的にスポットを当てながらそれをずらして見ていくという構成で関係系図をシンプルに表示できるように工夫されている。この構成によれば、中心データとそれから離れていくデータの繋がりを見ることは可能になる。しかし、この構成では、時間的な流れをおって結合や分離の変遷を追跡し、関係の変化を見ることはできない。関係管理テーブルでは、親子の関係付けはするが、この親子関係が必ずしも発生の順に親と子として設定されているとは限らない。親と子は、利用者の都合で設定するものとなっている。したがって、一度親と子の関係付けをすると、その逆方向の関係や複数の関係を同時に設定することはできない。それは、関係付けを辿るために２者の関係を一方向にしておかなければ、関係検索・追跡時に永久に循環する関係ができてしまうからである。
【０１２５】
次に、上記実施形態に対し、さらに関係ベクトルテーブルを付加して関係管理テーブルと併用して、「溯り（さかのぼり）ルート」により位置的、時間的な流れを追った関係検索・追跡を可能にした実施形態について説明する。これは、例えば次のような場合に必要になる。
【０１２６】
上記実施形態では、関係する人脈を入力する場合において、名前が変化すると、本人という関係で繋いでも、発生の順番を持っていないので、ルーツを溯ることはできない。それぞれのデータ内に発生順を持つことは可能であるが、系図にその順番通りの表示を反映させるのは困難である。そのためには、発生の時間と親子関係の方向ではない、場合に応じた方向が関係情報の中に必要になる。
【０１２７】
また、宇宙の発生を例にとると、ビッグバンである物質Ａがある時間、ある位置で分離し、さらにある時間、位置で物質ＢとＣとに分離し、物質Ａは物質Ａ′に変化する、というような現象を繰り返す。このような結合と分離を繰り返し、元の物質とは異なる物質として固有なものになる場合や、元の属性を残したまま変化する場合など、科学的な分野で関係情報を操作する場合には、関係ができた時間及び位置情報を持たなければ、同じ現象で分離・結合したものは同じものとみなしてしまう危険性がある。人脈など、任意の２人がどこで知り合ったかが重要視されない単なる関係に限ればこのままでもよい。しかし、物質の変化や微生物の分裂情報などは、時間と位置は欠かせない情報であり、このような関係情報を時間の流れや位置で溯ることにより、データの変遷を追跡することが可能になる。
【０１２８】
さらに、噂が広まった情報源を辿るため、情報伝達に関わった人たちに関する情報を記録する場合、噂は、Ａ→Ｂ→Ｃ→……→Ａ→Ｂ→Ｇ→……→Ｂ→Ａ→…のように何度か同じ人に戻ったりすることがある。その場合、最初に聞いた内容と２度目に聞いた内容は違っている場合が多い。繋がりのみを見た場合には、最初のＡとＢの関係と２度目のＡとＢの関係は全く同じであり、３度目のＢとＡの関係は情報伝達方向が逆転しているだけである。しかし、情報が伝達された時間が異なっており、伝達位置によっても、それらが情報の変化に影響している可能性もある。これらの時間や位置も、それぞれ個人の情報に含まれるべきものではなく、関係情報に含まれて処理されるべきものである。
【０１２９】
上記のように、関係情報を操作する上で、「溯りルート」を特定することによるメリットは非常に大きい。そこで、この「溯りルート」を操作するため、データテーブルとして図３９に示すように関係管理テーブルＫＫＴに加えて関係ベクトルテーブルＫＶＴを持つ。
【０１３０】
図３９において、関係管理テーブルＫＫＴは、これまでと同様であるが、関係区分などはこの中に持たず、関係ベクトルテーブルＫＶＴに持たせてもよい。各データの詳細部分は図示しないメンバー管理テーブルに保存してあってもよい。既に説明したように関係管理テーブルＫＫＴは、親子関係を持たせることで２者間の関係追跡の流れる方向を決定するもので、実際には処理上の検索・追跡などに永久循環を防ぐための方向付け手段としての役割がある。そのため、２者間の親子関係はダブって登録されることなく、固有の関係であり、親子が逆転して登録されることもない。
【０１３１】
関係ベクトルテーブルＫＶＴは、関係管理テーブルＫＫＴの親子とは別に２者の関係を、その方向と位置時系列、接続位置、接続順などとともに複数登録するものであり、関係ベクトルテーブルＫＶＴに書き込むことを前提とした処理内で関係付けされた全ての関係に１レコードずつ記録され、関係の向きを親と子ではなく元と先で表す。この元と先は親子の設定には関係なく指定することができる。関係ベクトルテーブルＫＶＴの各レコードは、個別に順指定された集合体が１つのグループとして登録されているという内容や、連結の順位付けがされているという内容の付加情報を持たせて、ユニークなレコードとして認識させる。関係ベクトルテーブルＫＶＴは、明らかに複数の関係が発生する場合や関係に順位が生ずる場合には必要となる。しかし、関係さえ判ればよいという場合には、記憶領域を圧迫するため、利用者の必要に応じて、関係ベクトルテーブルＫＶＴに情報を書き込むかどうかを選ぶことができるようにしておくのが望ましい。
【０１３２】
関係ベクトルテーブルＫＶＴでは、関係を、１：１、１：多、多：１、多：多で接続する際、図４０に示すように任意の付加情報を持たせ、ここで「同じ」、「置換」、「変体」、「連続」、「結合」、「分離」などのような分別区分を持って利用者が自由に接続位置と接続順を設定できるようにする。「同じ」は、２つのデータを同じものとみなすが、一体化はせずグループの形状を残したまま接続する、つまり関係区分「本人」と同じ考え方である。「置換」は、２つのデータを同じものとみなし、どちらかを優先的なデータとして表示し、非優先データは隠しデータ、又は名寄せデータとして１つに統合する。「変体」は、元データから先データへと変化したものとして新旧の区別を明確にして接続する。「連続」は、元データから先データへと連続したものとして新旧の区別を明確にして接続する。「結合」は、多：１の接続をし、「分離」は、１：多の接続をする。また、利用者の意思ではっきりとした時系列の関係付けが必要な場合には、図４１に示すように既にグループ化された関係同士をどのグループのどのメンバーで連結させるかを指定する。
【０１３３】
この関係ベクトルテーブルＫＶＴを用いることにより、参照対象中心表示（以下、関係系図ともいう）と位置時系列表示（以下、関係地図または関係年表ともいう）を併用することができる。例えば図４０に示すように１：１で繋いでいくうちに利用者も気がつかない関係網で出来上がっている参照対象中心表示とは別に、位置時系列表示は、図４１に示すように利用者の意思に沿った関係付けがそのまま表示される。これらを併用することで、データの関係地図や関係年表を作ることができ、その中で指定した任意のデータの参照対象中心表示を用いることができる。
【０１３４】
関係管理テーブルＫＫＴでは、上記で述べた並列や直列、グループとしての関係も、全て１：１の固有の繋がりとして分解して登録され、同じ関係や逆転関係は記録されない。すなわち、関係管理テーブルＫＫＴのみで関係を表す場合には、関係表現と関係追跡の流れを表示する親子関係を共用していたので、２者の関係パターンが複数あった場合や、Ａ→Ｂであり、Ｂ→Ａでもあるような関係が存在する場合には、そのひとつのみを登録するしかなかった。
【０１３５】
例えばＡはＢの上司、ＡとＢは同じサークルに属している。また、ＢはＡの先輩であり、師匠であるとする。この場合、もし、最初の関係がＢ→Ａ（先輩）であり、その後Ａ＝Ｂ（サークル仲間）となり、しばらくしてＡ→Ｂ（上司）という関係が出来、最後にＢ→Ａ（師匠）という関係が出来上がったとすると、関係管理テーブルＫＫＴの親子関係のみでは表現できない。したがって、それぞれの関係とその方向と時系列情報などを関係ベクトルテーブルＫＶＴに記録するのである。この場合の関係ベクトルテーブルＫＶＴの概念は、この中に登録された関係情報が固有であり、任意の２者間には、まったく同じ属性の関係は存在しないという前提で作成される。ゆえに、利用者が関係の順番を意図的に指定したい場合や、同じ関係内に複数の関係の意味を持たせたい場合、逆転の関係を残したい場合には、関係ベクトルテーブルＫＶＴに時間情報や位置情報などそれぞれのレコードが別の関係であると識別できる情報を持たせる。
【０１３６】
これにより、繋がりを連鎖で表したとき、同じ関係が複数の時点で表れても別物として「溯りルート」を表示することができる。しかし、この表示では、参照対象の表示位置が固有ではないため一度に全ての関係者を見ることはできない。例えば図４２は図４３の関係地図を関係系図に置き換えたものであり、分解し突き詰めれば同じ関係の図である。図４２はそれぞれの個体から見た関係が一目でわかるし、図４３は関係の変遷が理解しやすい表示になっている。しかし、図４３の下方のＧを参照中には、Ｅとの繋がりは分からないことになる。
【０１３７】
そこで、Ｇを参照中にＧを参照対象にした関係系図が表示でき、ここで繋がりがあると表示された別メンバーが関係地図上のどこに表示されているかを参照することができ、さらにその位置に移動して他の繋がりまで見ることができれば、時間や位置の違いまでも同時に把握することができようになる。
【０１３８】
例えば関係地図（関係年表）上の複数の場所に対象とするデータが分散して、移動先が複数あったときは、リストボックスなどでそれらの位置や属性を示し、利用者に表示対象を選択させ、関係地図上の該当データ部分を高輝度表示するなどで位置を把握しやすいようにしてもよい。また、選択された位置に移動する時には、ジャンプボタンなどで関係地図上の指定位置に自動的にスクロール表示されるようにしておくのが望ましい。このように、関係地図上の任意の場所で関係系図を適宜参照し、移動することが出来れば、極めて関係の把握がしやすいシステムを構築することが可能である。
【０１３９】
任意の付加情報において、例えば時間は、年月日時分秒に限らず、情報の変化の過程などを表す属性でも構わない。位置と時間という表現を用いることにより、位置が３次元空間で、時間はその変化の過程などを表す４次元としての働きを持たせることができる。時間が同じであっても、ＡとＢの関係は、Ｃから見れば普通の関係であるが、Ｄから見れば仲が悪いととられ、Ｅから見ればおしどり夫婦に見られている、という場合に登録者の主観が関係付けに大きく影響する。このように１つのシステムに不特定多数の利用者がいる場合、別の入力者であるという情報も１つの位置情報と見ることもできる。
【０１４０】
この他にも、速度、力など、同じ２者間に存在する複数の関係をそれぞれ固有であると認識するための付加情報は、その任意の付加情報をもつエリアを関係ベクトルテーブルＫＶＴ内に持っていさえすれば、システムの開発者と利用者に関わらず設定することができる。
【０１４１】
また、「集合体：単体」、「単体：集合体」、「集合体：集合体」などのように、作成された集合体をグループメンバーとして名前を付けて登録し、関係地図を作成することにより、集合体ごとの繋がりとそれを構成する単体メンバーとの繋がりを同時に知ることができる。さらに、特定の連鎖関係を含んだ集合体を検索することが可能になる。例えば学術的分野では、任意の分子構造を持つ多分子結合体などの研究分野、言語などのような発生と遷移を追跡すべき研究分野、天体の星座・星雲と恒星・惑星などの研究分野に広く応用することができる。
【０１４２】
なお、本発明は、上記実施の形態に限定されるものではなく、種々の変形が可能である。例えば上記実施の形態では、メンバーデータの詳細情報として、摘要の情報と履歴の情報を説明したが、その他、写真や添付ファイルなど様々な情報を付加してもよいし、同じメンバーに関して、識別コードで区分け情報と固有の詳細情報で登録してもよい。
【０１４３】
【発明の効果】
以上述べたように、本発明によれば下記の効果を奏する。
１．人脈の系図を２次元の紙に書き表すことができる
２．同じ人が系図の中に何度現れても（循環しても）、確実に関係ルートを探し出せる。
３．繋がりを親子で表し、その関係を区別でき、さらに繋がりの深さを区別できる。
４．系図を世代ではなく、親等で表すことにより、親方向と子方向への繋がり方向を固定化せず、自由に追跡し、ツリー表示することができる。
５．関係が続く限り、系図を連続で作成することができる。
６．任意の二人の繋がりを、あらゆるルートで追跡することができる。
【０１４４】
また、本発明によれば、各種情報を関係付けて管理する関係付け情報管理システムであって、少なくとも各種情報間の関係、該関係の方向及び位置時系列情報を格納する関係ベクトルテーブルと、関係ベクトルテーブルに格納された関係、該関係の方向及び位置時系列情報を基に関係付けの検索処理を行い関係図の出力処理を行う検索処理手段とを備え、さらに各種情報間で親と子の関係付けを格納する関係管理テーブルを備え、検索処理手段は、関係図として、各種情報間の位置時系列に沿った関係の変遷を表示する関係地図と各種情報間の繋がりを連鎖で表示する関係系図の出力処理を行うように構成することにより、関係地図と関係系図の表示を併用することができ、データの関係地図や関係年表を作ることができ、その中で指定した任意のデータの参照対象中心表示を用いることができる。したがって、「溯り（さかのぼり）ルート」により位置的、時間的な流れを追った関係検索・追跡を可能になる。
【０１４５】
さらに、各種情報を関係付けて管理する関係付け情報管理システムであって、少なくとも各種情報の識別情報で親と子の関係付けを格納する関係管理テーブルと、指定された情報と範囲で関係管理テーブルの関係付けにより親から子、子から親へ各種情報の検索処理を行う検索処理手段とを備えるので、データ間の関係を親（主、上）と子（従、下）で表し、世代ではなく、親等で管理することにより関係の追跡と表示を簡易にすることができる。しかも、登録されたデータ同士を関係付けすることにより、関係が続く限り引き当てることができ、２者の関係ルートを追跡したり、それらの関係を系図に表現することができる。重複データも名寄せ処理することなく、同一データという関係で結べば双方参照でき、旧姓、新姓データも関係付けにより両立させることができる。
【０１４６】
また、人と人だけでなく、人と物、物と物との関係付けを行い、物品のデータと人のデータを混在させて管理できるようにすることにより、例えば官庁等と取引のある会社で、また後に流用する可能性のある重要な書類を作成した場合、その文書を作成した人間や、その文書管轄の課等に関係付けを行っておくことができ、次に使用する際に記憶を辿らずに済む。
【０１４７】
文書を作成する際に参考にした本や地図資料等がどこの課のどの支所のものだったかなども、その課や支所などに関係付けをしておくことにより、その「課」、「本」、「資料」、「文書」のどれか１つだけでも手掛かりがあれば、詳しく覚えていない場合でも、関係をいもづる式に辿って必要な情報に辿りつくことができる。勿論、文書だけでなく、顧客と買い上げた車などの商品と結び付けておくこともでき、土地をデータとして入力しておき、所有者の変遷を辿ることもできる。曖昧なデータや不確実なデータも、ニュースソースに関係付けしておくことで行方不明データにはならない。
【図面の簡単な説明】
【図１】  本発明に係る関係付け情報管理システムの実施の形態を示す図である。
【図２】  メンバー管理テーブルの構成例を示す図である。
【図３】  関係管理テーブルの構成例を示す図である。
【図４】  マスタテーブルの構成例を示す図である。
【図５】  本発明に係る関係付け情報管理システムの関係付け検索処理の流れの例を説明するための図である。
【図６】  検索条件及び出力条件の例を説明するための図である。
【図７】  シンクロ方式を利用する場合について説明するための図である。
【図８】  親選択集団と子選択集団を使った並列の関係付けの例を説明するための図である。
【図９】  カテゴリーの一致による並列の関係付けの例を説明するための図である。
【図１０】  ＬＬ方式のデータベース間インポートの例を説明するための図である。
【図１１】  関係を繋ぐ媒体について説明するための図である。
【図１２】  エクスプローラ等のファイル管理ソフトにおける関係付けについて説明するための図である。
【図１３】  多種類データのファイル内の部分的な関係付けについて説明するための図である。
【図１４】  その他のファイル等の関係付けについて説明するための図である。
【図１５】  複数の管理テーブルを設けて関係付けする場合について説明するための図である。
【図１６】  一般のカード形式の顧客管理の方法を示す説明図である。
【図１７】  本発明における関係管理テーブルの例を示す説明図である。
【図１８】  子関係の説明図である。
【図１９】  親関係の説明図である。
【図２０】  親子関係の説明図である。
【図２１】  利用者と関係を探りたい人物とのルートの説明図である。
【図２２】  本発明における親子関係によるつながりの説明図である。
【図２３】  本発明のメンバー紹介系図の画面の例を示す図である。
【図２４】  本発明のメンバー関係検索の画面の例を示す図である。
【図２５】  本発明による系図の探り方を説明する図である。
【図２６】  本発明のシステムのソフトウエア構成を示すブロック図である。
【図２７】  本発明の実施システムのメインメニュー画面の図である。
【図２８】  本発明実施例のメンバー情報入力画面の図である。
【図２９】  本発明実施例のＢＯＸ項目入力画面の図である。
【図３０】  本発明実施例のＢＯＸ項目入力画面の図である。
【図３１】  本発明実施例の分類コード入力画面の図である。
【図３２】  本発明実施例の関係区分登録画面の図である。
【図３３】  本発明実施例の関係区分登録画面の図である。
【図３４】  本発明実施例の関係入力画面の図である。
【図３５】  本発明実施例のメンバー紹介系図（親、子、孫）の画面の図である。
【図３６】  本発明実施例において表示されている系図の範囲の説明図である。
【図３７】  図２３の表示画面の詳細図である。
【図３８】  関係検索において探索されるルートの説明図である。
【図３９】  関係管理テーブルと関係ベクトルテーブルの併用例を示す図である。
【図４０】  関係を繋ぐ方法の例を説明するための図である。
【図４１】  グループ化された関係同士の連結例を示す図である。
【図４２】  参照対象中心表示で作成した関係系図の例を示す図である。
【図４３】  位置時系列表示で作成した関係地図の例を示す図である。
【図４４】  関係図の例を示す図である。
【図４５】  関係付けされた各種情報の例を示す図である。
【図４６】  一般の家系図の表示例を示す説明図である。
【図４７】  人脈のつながりの例を示す説明図である。
１…入力処理部、２…出力処理部、３…データ登録・更新処理部、４…検索処理部、５…編集処理部、６…関係管理テーブル、７…メンバー管理テーブル、８…マスタテーブル
【図１】
0003730174.tif 000002
【図２】
0003730174.tif 000003
【図３】
0003730174.tif 000004
【図４】
0003730174.tif 000005
【図５】
0003730174.tif 000006
【図６】
0003730174.tif 000007
【図７】
0003730174.tif 000008
【図８】
0003730174.tif 000009
【図９】
0003730174.tif 000010
【図１０】
0003730174.tif 000011
【図１１】
0003730174.tif 000012
【図１２】
0003730174.tif 000013
【図１３】
0003730174.tif 000014
【図１４】
0003730174.tif 000015
【図１５】
0003730174.tif 000016
【図１６】
0003730174.tif 000017
【図１７】
0003730174.tif 000018
【図１８】
0003730174.tif 000019
【図１９】
0003730174.tif 000020
【図２０】
0003730174.tif 000021
【図２１】
0003730174.tif 000022
【図２２】
0003730174.tif 000023
【図２３】
0003730174.tif 000024
【図２４】
0003730174.tif 000025
【図２５】
0003730174.tif 000026
【図２６】
0003730174.tif 000027
【図２７】
0003730174.tif 000028
【図２８】
0003730174.tif 000029
【図２９】
0003730174.tif 000030
【図３０】
0003730174.tif 000031
【図３１】
0003730174.tif 000032
【図３２】
0003730174.tif 000033
【図３３】
0003730174.tif 000034
【図３４】
0003730174.tif 000035
【図３５】
0003730174.tif 000036
【図３６】
0003730174.tif 000037
【図３７】
0003730174.tif 000038
【図３８】
0003730174.tif 000039
【図３９】
0003730174.tif 000040
【図４０】
0003730174.tif 000041
【図４１】
0003730174.tif 000042
【図４２】
0003730174.tif 000043
【図４３】
0003730174.tif 000044
【図４４】
0003730174.tif 000045
【図４５】
0003730174.tif 000046
【図４６】
0003730174.tif 000047
【図４７】
0003730174.tif 000048