JP2008003809A - 情報共有制御システム - Google Patents
情報共有制御システム Download PDFInfo
- Publication number
- JP2008003809A JP2008003809A JP2006171838A JP2006171838A JP2008003809A JP 2008003809 A JP2008003809 A JP 2008003809A JP 2006171838 A JP2006171838 A JP 2006171838A JP 2006171838 A JP2006171838 A JP 2006171838A JP 2008003809 A JP2008003809 A JP 2008003809A
- Authority
- JP
- Japan
- Prior art keywords
- information
- terminal
- user
- mediation
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Operations Research (AREA)
- General Business, Economics & Management (AREA)
- Marketing (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- Economics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Information Transfer Between Computers (AREA)
- Storage Device Security (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】Ｋｎｏｗ−Ｗｈｏシステムでのユーザ間のプライベートな関係情報及び人物間仲介の情報流出を防止する。
【解決手段】端末は、電子メール又は公開されていない媒体に基づき作成される、他の端末の識別情報を含むプライベートな関係情報４、５、６を保持する。第１のサーバは、アプリケーション又はグループへの参加要求（例えば、電子会議室への入室要求）を端末から受信し、該端末の識別情報と該アプリケーション又はグループの識別情報とが対応付けられた属性情報を記憶する。例えば、関係情報・共有可否情報管理サーバ１６は、該属性情報を参照し、同じアプリケーション又はグループに属することを含む共有条件にマッチングしている端末について、端末のプライベートな関係情報を一時的に共有可能とさせる。
【選択図】図１
【解決手段】端末は、電子メール又は公開されていない媒体に基づき作成される、他の端末の識別情報を含むプライベートな関係情報４、５、６を保持する。第１のサーバは、アプリケーション又はグループへの参加要求（例えば、電子会議室への入室要求）を端末から受信し、該端末の識別情報と該アプリケーション又はグループの識別情報とが対応付けられた属性情報を記憶する。例えば、関係情報・共有可否情報管理サーバ１６は、該属性情報を参照し、同じアプリケーション又はグループに属することを含む共有条件にマッチングしている端末について、端末のプライベートな関係情報を一時的に共有可能とさせる。
【選択図】図１
Description
本発明は、情報共有制御システムに係り、特に、情報公開の設定方式についての情報共有制御システムに関する。
自分が知りたい情報を「誰が」知っているかを検索するＫｎｏｗ−Ｗｈｏシステムと呼ばれる仕組みがある。このシステムの動作を以下簡単に説明する。まずシステムでは各ユーザ間の関係を論文の共著関係や電子メールの送受信情報から取得、サーバ側で把握する。また、一方で同じく論文や電子メールの内容をテキストマイニングする等して、各ユーザが持っているナレッジ情報をサーバ側で把握しておく。これら２つの情報を基に、あるユーザが知りたい情報について、そのユーザと関係が深い人物の中でだれがその情報について詳しいかを検索する。例えば、友達Ａの友達Ｂがその情報について詳しいことが検索されれば、友達Ａに仲介してもらい、友達の友達Ｂから情報を教えてもらうようなことが可能となる。
また、コンサルタント等の為に各企業の組織編成や人物間の交流状態を可視化するツールも存在する。このツールも上記Ｋｎｏｗ−Ｗｈｏシステムと同様、電子メールの送受信状態や内容をサーバ側で把握し、そこから社員間の関係を把握し、現在の組織編成の改良をアドバイスするためのヒントとして活用される。
また、コンサルタント等の為に各企業の組織編成や人物間の交流状態を可視化するツールも存在する。このツールも上記Ｋｎｏｗ−Ｗｈｏシステムと同様、電子メールの送受信状態や内容をサーバ側で把握し、そこから社員間の関係を把握し、現在の組織編成の改良をアドバイスするためのヒントとして活用される。
現在のＫｎｏｗ−Ｗｈｏシステムでは様々な情報をサーバが取得し、人物間のつながりを把握する仕組みをとっているが、本システムではプライバシが大きな課題となる。論文や報告書の様なパブリックな文書から人物間のつながりを取得する場合はまだ良い。しかし、例えば電子メールはプライバシに関わる情報を含む可能性もある。例えば、サーバ側で取得して解析する場合、利用ユーザに心理的な抵抗が発生する可能性があり、また、信頼する友人以外には知られたくない情報等が意図する人以外に知られてしまう場合がある。
本発明は、以上の点に鑑み、Ｋｎｏｗ−Ｗｈｏシステムでのユーザ間の関係情報、及び人物間仲介からの個人情報流出を防止することを目的とする。本発明は、各ユーザが信頼できるユーザとテンポラリにプライベートな人物間の接続情報を共有することで情報（例えば、ユーザ間の関係）が開示する可能性を低くすることを目的とする。また、ユーザの心理的抵抗を下げることを目的とする。また、本発明は、人物（端末）間の仲介を行う場合、仲介の依頼者（情報を受ける者）に目的人物（情報提供者）のＩＤやアドレスなどの情報を公開せずに、既に目的人物のＩＤやアドレスを知っている仲介人物と目的人物との間で交渉を行うことを目的とする。さらに、本発明は、もし交渉後、目的人物が目的に合致しなかった場合や交渉に合意しなかった場合でも、目的人物のＩＤやアドレスが依頼者に流出することを防止することを目的とする。
本発明は、サーバが、人物間の関係情報を、電子メール等のプライバシを含む可能性のある情報源から取得せずに、Ｋｎｏｗ−Ｗｈｏシステムを構築することを目的のひとつとする。
本発明は、以上の点に鑑み、Ｋｎｏｗ−Ｗｈｏシステムでのユーザ間の関係情報、及び人物間仲介からの個人情報流出を防止することを目的とする。本発明は、各ユーザが信頼できるユーザとテンポラリにプライベートな人物間の接続情報を共有することで情報（例えば、ユーザ間の関係）が開示する可能性を低くすることを目的とする。また、ユーザの心理的抵抗を下げることを目的とする。また、本発明は、人物（端末）間の仲介を行う場合、仲介の依頼者（情報を受ける者）に目的人物（情報提供者）のＩＤやアドレスなどの情報を公開せずに、既に目的人物のＩＤやアドレスを知っている仲介人物と目的人物との間で交渉を行うことを目的とする。さらに、本発明は、もし交渉後、目的人物が目的に合致しなかった場合や交渉に合意しなかった場合でも、目的人物のＩＤやアドレスが依頼者に流出することを防止することを目的とする。
本発明は、サーバが、人物間の関係情報を、電子メール等のプライバシを含む可能性のある情報源から取得せずに、Ｋｎｏｗ−Ｗｈｏシステムを構築することを目的のひとつとする。
各ユーザの電子会議室への入退室情報、プレゼンス情報等を確認して、ユーザ間で信頼関係を持っていると判断できる条件に合致した場合に、各メンバが持つプライベートな人物間の接続情報をテンポラリに（一時的に）共有する仕組みを提供する。プライベートな人物間の接続情報とは、例えば、自分の電子メールの送受信頻度や内容を自端末で解析して得られた自分と他人との接続情報や、パブリックに公開していない自分のプロファイル（入社年度、所属部活、趣味等）の情報から得られた他人との接続情報である。
また、テンポラリに共有した人物間の接続情報を利用してユーザ間の仲介を行う時、仲介希望者が目的人物の名前の公の情報を指定して仲介人物に仲介依頼し、仲介人物が目的人物のＩＤ（識別情報）を指定して目的に対する交渉を行うシステムを提供する。ここで、ＩＤとは、例えば、目的人物が利用する端末のＩＰアドレス、プライベートで利用している電子メールアドレス、チャットのＩＤ等を用いることができる。
図１、図２に動作概要図を示す。図１は、プライベートな関係情報を共有するときのイメージ図である。図２は、プライベートな関係情報を用いて仲介パスを検出した後の仲介動作イメージ図である。
また、テンポラリに共有した人物間の接続情報を利用してユーザ間の仲介を行う時、仲介希望者が目的人物の名前の公の情報を指定して仲介人物に仲介依頼し、仲介人物が目的人物のＩＤ（識別情報）を指定して目的に対する交渉を行うシステムを提供する。ここで、ＩＤとは、例えば、目的人物が利用する端末のＩＰアドレス、プライベートで利用している電子メールアドレス、チャットのＩＤ等を用いることができる。
図１、図２に動作概要図を示す。図１は、プライベートな関係情報を共有するときのイメージ図である。図２は、プライベートな関係情報を用いて仲介パスを検出した後の仲介動作イメージ図である。
図１では１に示すＵｓｅｒＡ、２に示すＵｓｅｒＢ、３に示すＵｓｅｒＣがそれぞれ４、５、６の様に自分と他人とがどのように接続されているかを示す関係情報を保持している。その時７の様にお互いの共有条件がマッチした場合、８の様にお互いの関係情報４、５、６を共有する。その後、この共有した他人との関係情報８と、関係情報・共有可否情報管理サーバ１６が保有しているパブリックな関係情報９とを組み合わせて、目的人物への仲介ルートを検索する。また、仲介ルート検索後は、図２のステップ１２の様に仲介依頼を出し、ステップ１４、ステップ１５の様に取り次ぎ、最終的にはステップ１５の様に情報提供を行うが、その際、情報提供に対して目的人物１１や仲介人物１８のＩＤやアドレス等のプライバシ情報を出来る限り開示させずに仲介を行う。
本システムは、例えば、各ユーザの種々の属性情報（オブジェクト情報）の値を比較し、条件にマッチングしている場合に各ユーザが保持する自分と他人との接続情報を共有することを特徴のひとつとする。
本システムは、例えば、各ユーザの種々の属性情報（オブジェクト情報）の値を比較し、条件にマッチングしている場合に各ユーザが保持する自分と他人との接続情報を共有することを特徴のひとつとする。
本システムのサーバは、例えば、目的人物への仲介ルートを経由するとき、仲介者、及び目的人物が保持する個人を特定する情報を仲介希望者へ提示せずに共通記号を仲介希望者、目的人物、仲介人物に配布し、共通記号から各ルートで公開可能となる情報のみを返信し、各人物への情報公開制御する事を特徴のひとつとする。上述の公開可能な情報とは、例えば、各人物が公的に公開している名前等の情報である。
上述のシステムにおいて、種々の属性情報（オブジェクト情報）とは電子会議室への入退室情報である事を特徴のひとつとする。また、種々の属性情報（オブジェクト情報）とは各ユーザの位置情報、現在状態等の動的に変化する情報である事を特徴のひとつとする。上述のシステムにおいて、種々の属性情報（オブジェクト情報）とは各ユーザが保持する所属部署、年齢、性別等各個人の特徴を現す静的情報である事を特徴のひとつとする。
上述のシステムの情報端末において、自分と他人との接続情報を各々の情報端末で保持し、共有条件に合致した時、お互いに通信を行う事により目的人物への仲介ルートを検索する事ができる。また、自分と他人との接続情報を一旦サーバに登録し、サーバが共有条件に従いアクセス制御を行う事もできる。
上述のシステムにおいて、種々の属性情報（オブジェクト情報）とは電子会議室への入退室情報である事を特徴のひとつとする。また、種々の属性情報（オブジェクト情報）とは各ユーザの位置情報、現在状態等の動的に変化する情報である事を特徴のひとつとする。上述のシステムにおいて、種々の属性情報（オブジェクト情報）とは各ユーザが保持する所属部署、年齢、性別等各個人の特徴を現す静的情報である事を特徴のひとつとする。
上述のシステムの情報端末において、自分と他人との接続情報を各々の情報端末で保持し、共有条件に合致した時、お互いに通信を行う事により目的人物への仲介ルートを検索する事ができる。また、自分と他人との接続情報を一旦サーバに登録し、サーバが共有条件に従いアクセス制御を行う事もできる。
上述のシステムにおいて、接続情報の共有可否を情報端末側で判断する事ができる。また、各ユーザの属性情報をサーバで保持しておき、サーバで各ユーザの条件マッチングを行い、共有条件の合致を判断する事もできる。
上述のシステムにおいて、共有の可否を段階的に定義し、レベルに応じて、公開する自分と他人との接続情報を制御する事を特徴のひとつとする。
仲介ルート検索の結果を一旦各ユーザの情報端末に返信し、そこから各ユーザが仲介ルートを選択できる。また、サーバが仲介ルート検索の結果から仲介ルートを自動的に選択し、仲介手続きを行う事もできる。さらに、サーバが仲介ルート検索の結果、仲介手続きを電話や文字通信、電子会議を制御するサーバに送信し、目的人物と仲介人物、または仲介依頼人物との通信を制御する事ができる。
上述のシステムにおいて、共有の可否を段階的に定義し、レベルに応じて、公開する自分と他人との接続情報を制御する事を特徴のひとつとする。
仲介ルート検索の結果を一旦各ユーザの情報端末に返信し、そこから各ユーザが仲介ルートを選択できる。また、サーバが仲介ルート検索の結果から仲介ルートを自動的に選択し、仲介手続きを行う事もできる。さらに、サーバが仲介ルート検索の結果、仲介手続きを電話や文字通信、電子会議を制御するサーバに送信し、目的人物と仲介人物、または仲介依頼人物との通信を制御する事ができる。
本発明の第１の解決手段によると、
送受信される電子メール又は公開されていない情報若しくは媒体に基づき作成される、他の端末又はユーザの識別情報を含むプライベートな関係情報をそれぞれ保持する複数の端末と、
アプリケーション又はグループへの参加要求を前記端末から受信し、該端末の識別情報と該アプリケーション又はグループの識別情報とを対応付けた属性情報を記憶する第１のサーバと、
を備え、
該属性情報に基づき、同じアプリケーション又はグループに属する各端末が、それぞれの前記プライベートな関係情報を一時的に共有する情報共有制御システムが提供される。
送受信される電子メール又は公開されていない情報若しくは媒体に基づき作成される、他の端末又はユーザの識別情報を含むプライベートな関係情報をそれぞれ保持する複数の端末と、
アプリケーション又はグループへの参加要求を前記端末から受信し、該端末の識別情報と該アプリケーション又はグループの識別情報とを対応付けた属性情報を記憶する第１のサーバと、
を備え、
該属性情報に基づき、同じアプリケーション又はグループに属する各端末が、それぞれの前記プライベートな関係情報を一時的に共有する情報共有制御システムが提供される。
本発明の第２の解決手段によると、
送受信される電子メール又は公開されていない情報若しくは媒体に基づき作成される、他の端末又はユーザの識別情報を含むプライベートな関係情報をそれぞれ保持する複数の端末と、
アプリケーション又はグループへの参加要求を前記端末から受信し、該端末の識別情報と該アプリケーション又はグループの識別情報とを対応付けた属性情報を記憶する第１のサーバと、
ユーザの識別情報と、該ユーザが知っている情報とが対応して記憶されたデータベースを有し、前記複数の端末のうちの第１の端末から情報検索要求を受信し、要求された情報を知る情報提供ユーザの識別情報を、前記データベースを参照して取得し、該情報提供ユーザの識別情報と第１の端末の識別情報とを送信する第２のサーバと、
公開された又は公開予定の情報若しくは媒体に基づき作成される、互いに関係のある端末又はユーザの識別情報が対応付けられたパブリックな関係情報を保持する第３のサーバと
を備え、
前記第３のサーバは、
前記第２のサーバから情報提供ユーザの識別情報と第１の端末の識別情報を受信し、
受信された第１の端末の識別情報に対応するアプリケーション又はグループに属する各端末の識別情報を求め、
該端末のプライベートな関係情報に基づき、受信された情報提供ユーザの識別情報、又は、パブリックな関係情報に基づき求められた該情報提供ユーザの識別情報に対応する第１の仲介端末の識別情報に対応する第２の仲介端末の識別情報を求め、
求められた第２の仲介端末の識別情報に従い、第２の端末に仲介依頼を送信し、
前記第２の仲介端末は、直接又は前記第１の仲介端末を介して、情報提供ユーザの端末に第１の端末の識別情報を含む情報提供依頼を送信し、
前記情報提供ユーザの端末は、第１の端末の識別情報を表示部に表示し、
表示された第１の端末の識別情報に従い、情報提供ユーザが要求された情報を第１の端末のユーザに提供することにより、第１の端末に仲介端末及び情報提供ユーザの識別情報を開示せずに、要求された情報を提供する情報共有制御システムが提供される。
送受信される電子メール又は公開されていない情報若しくは媒体に基づき作成される、他の端末又はユーザの識別情報を含むプライベートな関係情報をそれぞれ保持する複数の端末と、
アプリケーション又はグループへの参加要求を前記端末から受信し、該端末の識別情報と該アプリケーション又はグループの識別情報とを対応付けた属性情報を記憶する第１のサーバと、
ユーザの識別情報と、該ユーザが知っている情報とが対応して記憶されたデータベースを有し、前記複数の端末のうちの第１の端末から情報検索要求を受信し、要求された情報を知る情報提供ユーザの識別情報を、前記データベースを参照して取得し、該情報提供ユーザの識別情報と第１の端末の識別情報とを送信する第２のサーバと、
公開された又は公開予定の情報若しくは媒体に基づき作成される、互いに関係のある端末又はユーザの識別情報が対応付けられたパブリックな関係情報を保持する第３のサーバと
を備え、
前記第３のサーバは、
前記第２のサーバから情報提供ユーザの識別情報と第１の端末の識別情報を受信し、
受信された第１の端末の識別情報に対応するアプリケーション又はグループに属する各端末の識別情報を求め、
該端末のプライベートな関係情報に基づき、受信された情報提供ユーザの識別情報、又は、パブリックな関係情報に基づき求められた該情報提供ユーザの識別情報に対応する第１の仲介端末の識別情報に対応する第２の仲介端末の識別情報を求め、
求められた第２の仲介端末の識別情報に従い、第２の端末に仲介依頼を送信し、
前記第２の仲介端末は、直接又は前記第１の仲介端末を介して、情報提供ユーザの端末に第１の端末の識別情報を含む情報提供依頼を送信し、
前記情報提供ユーザの端末は、第１の端末の識別情報を表示部に表示し、
表示された第１の端末の識別情報に従い、情報提供ユーザが要求された情報を第１の端末のユーザに提供することにより、第１の端末に仲介端末及び情報提供ユーザの識別情報を開示せずに、要求された情報を提供する情報共有制御システムが提供される。
本発明の第３の解決手段によると、
各ユーザの位置情報及び／又は現在状態を含む、動的に変化する属性情報を、ユーザの識別情報毎に記憶する第４のサーバと、
各ユーザの属性情報を、前記第４のサーバへ登録するための登録部と、
送受信される電子メール又は公開されていない情報若しくは媒体に基づき作成される、他のユーザの識別情報を含むプライベートな関係情報をそれぞれ保持する各ユーザの端末、又は、第３のサーバと
を備え、
属性情報に基づき、同じ位置情報を有する又は予め定められたプレゼンス情報を有するユーザについて、前記ユーザの端末又は前記第３のサーバは、それぞれのユーザのプライベートな関係情報を一時的に共有する情報共有制御システムが提供される。
各ユーザの位置情報及び／又は現在状態を含む、動的に変化する属性情報を、ユーザの識別情報毎に記憶する第４のサーバと、
各ユーザの属性情報を、前記第４のサーバへ登録するための登録部と、
送受信される電子メール又は公開されていない情報若しくは媒体に基づき作成される、他のユーザの識別情報を含むプライベートな関係情報をそれぞれ保持する各ユーザの端末、又は、第３のサーバと
を備え、
属性情報に基づき、同じ位置情報を有する又は予め定められたプレゼンス情報を有するユーザについて、前記ユーザの端末又は前記第３のサーバは、それぞれのユーザのプライベートな関係情報を一時的に共有する情報共有制御システムが提供される。
本発明によると、Ｋｎｏｗ−Ｗｈｏシステムでのユーザ間の関係情報、及び人物間仲介からの個人情報流出を防止することができる。本発明によると、各ユーザが信頼できるユーザとテンポラリにプライベートな人物間の接続情報を共有することで情報（例えば、ユーザ間の関係）が開示する可能性を低くすることができる。また、本発明によると、ユーザの心理的抵抗を下げることができる。また、本発明によると、人物（端末）間の仲介を行う場合、仲介の依頼者（情報を受ける者）に目的人物（情報提供者）のＩＤやアドレスなどの情報を公開せずに、既に目的人物のＩＤやアドレスを知っている仲介人物と目的人物との間で交渉を行うことができる。さらに、本発明によると、もし交渉後、目的人物が目的に合致しなかった場合や交渉に合意しなかった場合でも、目的人物のＩＤやアドレスが依頼者に流出することを防止することができる。
本発明によると、サーバが、人物間の関係情報を、電子メール等のプライバシを含む可能性のある情報源から取得せずに、Ｋｎｏｗ−Ｗｈｏシステムを構築することができる。
本発明によると、サーバが、人物間の関係情報を、電子メール等のプライバシを含む可能性のある情報源から取得せずに、Ｋｎｏｗ−Ｗｈｏシステムを構築することができる。
１．第１の実施の形態
本実施の形態では、まず、第１の例を用いて、各ユーザが保持するプライベートな他人との接続情報の共有シーケンスを説明する。本例の説明では本実施の形態のサーバと端末の論理的構造、物理的構造、及びこれらを接続するネットワーク概要についても説明する。また、本実施の形態における端末とサーバが保持、共有するデータテーブルの例を説明する。その後、本実施の形態での複数動作シーケンスパターンを本例から派生させた形で説明する。
本実施の形態では、まず、第１の例を用いて、各ユーザが保持するプライベートな他人との接続情報の共有シーケンスを説明する。本例の説明では本実施の形態のサーバと端末の論理的構造、物理的構造、及びこれらを接続するネットワーク概要についても説明する。また、本実施の形態における端末とサーバが保持、共有するデータテーブルの例を説明する。その後、本実施の形態での複数動作シーケンスパターンを本例から派生させた形で説明する。
（システム構成）
図３には、本実施の形態の第１の例の動作概念図を示す。
本通信システムは、関係情報・共有可否情報管理サーバ１６と、多人数会議制御サーバ２１と、Ｋｎｏｗ−Ｗｈｏ検索サーバ２２と、複数のユーザ（例えば、Ｕｓｅｒ Ａ、Ｂ、Ｃ等）に対応する複数の端末を備える。なお、以下の説明において、単にＵｓｅｒ、人物と記すことがあるが、それらの者に対応する端末を指す。
この図では、１に示すＵｓｅｒＡ、２に示すＵｓｅｒＢ、３に示すＵｓｅｒＣが、多人数会議制御サーバ２１が管理する電子会議室Ａ２５に入室し、２９に示す様に文字、音声、映像のいずれかを用いて議論している。ただし、本例では、議論は例えば文字ベースのチャットで行われているものとする。例えば会議の中で、明日の展示会についての議論が発生した時、会議に参加中のユーザが誰も展示会についての詳細情報を知らなかったとする。そのとき、例えばＵｓｅｒＡはＫｎｏｗ−Ｗｈｏ検索サーバ２２に対して明日の展示会について詳細を知っているユーザの検索要求を行う。Ｋｎｏｗ−Ｗｈｏ検索サーバ２２は、自身が保持するＫｎｏｗ−Ｗｈｏデータベース２４を検索し、情報を持っていそうな目的人物を提示する。その後、関係情報・共有可否情報管理サーバ１６が持つパブリックなユーザ間関係情報２３と、信頼関係情報３２の内容に基づき、３０の様に共有された、各ユーザの保持するプライベートな関係情報４、５、６を２８の様に連携させることで目的人物への仲介パスを提示する。その後、ＵｓｅｒＡ１は２６の様に仲介依頼を、例えばＵｓｅｒＢ２に出し、ＵｓｅｒＢがさらに３３の様にＵｓｅｒＤ１８に仲介依頼をする。ＵｓｅｒＤ１８がＵｓｅｒＥ１１に対して２７の様に情報提供依頼を出し、ＵｓｅｒＥ１１が例えば３３に示す様に、電子会議室Ａに参加する。ＵｓｅｒＥ１１が電子会議室Ａで発言することでＵｓｅｒＥ１１またはＵｓｅｒＡ１等へ情報提供を行う。
図３には、本実施の形態の第１の例の動作概念図を示す。
本通信システムは、関係情報・共有可否情報管理サーバ１６と、多人数会議制御サーバ２１と、Ｋｎｏｗ−Ｗｈｏ検索サーバ２２と、複数のユーザ（例えば、Ｕｓｅｒ Ａ、Ｂ、Ｃ等）に対応する複数の端末を備える。なお、以下の説明において、単にＵｓｅｒ、人物と記すことがあるが、それらの者に対応する端末を指す。
この図では、１に示すＵｓｅｒＡ、２に示すＵｓｅｒＢ、３に示すＵｓｅｒＣが、多人数会議制御サーバ２１が管理する電子会議室Ａ２５に入室し、２９に示す様に文字、音声、映像のいずれかを用いて議論している。ただし、本例では、議論は例えば文字ベースのチャットで行われているものとする。例えば会議の中で、明日の展示会についての議論が発生した時、会議に参加中のユーザが誰も展示会についての詳細情報を知らなかったとする。そのとき、例えばＵｓｅｒＡはＫｎｏｗ−Ｗｈｏ検索サーバ２２に対して明日の展示会について詳細を知っているユーザの検索要求を行う。Ｋｎｏｗ−Ｗｈｏ検索サーバ２２は、自身が保持するＫｎｏｗ−Ｗｈｏデータベース２４を検索し、情報を持っていそうな目的人物を提示する。その後、関係情報・共有可否情報管理サーバ１６が持つパブリックなユーザ間関係情報２３と、信頼関係情報３２の内容に基づき、３０の様に共有された、各ユーザの保持するプライベートな関係情報４、５、６を２８の様に連携させることで目的人物への仲介パスを提示する。その後、ＵｓｅｒＡ１は２６の様に仲介依頼を、例えばＵｓｅｒＢ２に出し、ＵｓｅｒＢがさらに３３の様にＵｓｅｒＤ１８に仲介依頼をする。ＵｓｅｒＤ１８がＵｓｅｒＥ１１に対して２７の様に情報提供依頼を出し、ＵｓｅｒＥ１１が例えば３３に示す様に、電子会議室Ａに参加する。ＵｓｅｒＥ１１が電子会議室Ａで発言することでＵｓｅｒＥ１１またはＵｓｅｒＡ１等へ情報提供を行う。
情報端末４１〜４３は、例えば、電子メール又は公開されていない媒体に基づき作成される、他の端末の識別情報を含むプライベートな関係情報を保持する。
多人数会議制御サーバ（第１のサーバ）２１は、電子会議室Ａ２５への入室要求を端末４１〜４３から受信し、端末の識別情報と会議室の識別情報とが対応付けられた属性情報を記憶する。なお、会議室以外にも、適宜のアプリケーション又はグループであってもよい。例えば、関係情報・共有可否情報管理サーバ１６は、属性情報を参照し、同じアプリケーション又はグループに属することを含む共有条件にマッチングしている端末について、プライベートな関係情報を一時的に共有可能とさせる。
Ｋｎｏｗ−Ｗｈｏ検索サーバ（第２のサーバ）２２は、ユーザの識別情報と、ユーザが知っている情報とが対応して記憶されたデータベースを有する。また、複数の端末のうちの第１の端末から情報検索要求を受信し、要求された情報を知るユーザの識別情報を、データベースを参照して取得し、送信する。
関係情報・共有可否情報管理サーバ（第３のサーバ）１６は、公開された又は公開予定の媒体に基づき作成される、関係のある端末の識別情報が対応付けられたパブリックな関係情報を保持する。また、Ｋｎｏｗ−Ｗｈｏ検索サーバ２２から目的人物の識別情報を受信し、目的人物の識別情報に基づき、共有可能なプライベートな関係情報、及び／又は、パブリックな関係情報を参照して、目的人物へ仲介するひとつ又は複数の仲介端末の識別情報を求める。
多人数会議制御サーバ（第１のサーバ）２１は、電子会議室Ａ２５への入室要求を端末４１〜４３から受信し、端末の識別情報と会議室の識別情報とが対応付けられた属性情報を記憶する。なお、会議室以外にも、適宜のアプリケーション又はグループであってもよい。例えば、関係情報・共有可否情報管理サーバ１６は、属性情報を参照し、同じアプリケーション又はグループに属することを含む共有条件にマッチングしている端末について、プライベートな関係情報を一時的に共有可能とさせる。
Ｋｎｏｗ−Ｗｈｏ検索サーバ（第２のサーバ）２２は、ユーザの識別情報と、ユーザが知っている情報とが対応して記憶されたデータベースを有する。また、複数の端末のうちの第１の端末から情報検索要求を受信し、要求された情報を知るユーザの識別情報を、データベースを参照して取得し、送信する。
関係情報・共有可否情報管理サーバ（第３のサーバ）１６は、公開された又は公開予定の媒体に基づき作成される、関係のある端末の識別情報が対応付けられたパブリックな関係情報を保持する。また、Ｋｎｏｗ−Ｗｈｏ検索サーバ２２から目的人物の識別情報を受信し、目的人物の識別情報に基づき、共有可能なプライベートな関係情報、及び／又は、パブリックな関係情報を参照して、目的人物へ仲介するひとつ又は複数の仲介端末の識別情報を求める。
図４は、図３の例の物理的な接続構成図である。電子会議を行っている１に示すＵｓｅｒＡ、２に示すＵｓｅｒＢ、３に示すＵｓｅｒＣは実際には情報端末４１、４２、４３をそれぞれが所有、使用し、ＩＰネットワーク４６を経由して多人数会議制御サーバ２１に接続している。また、会議中の文字情報、音声情報、映像情報の送受信は本例ではＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバ４７が制御している。ＳＩＰは文字、音声、映像等のあらゆるユーザ間コミュニケーションについて、相手ユーザの呼び出しから相手ユーザとのコミュニケーション終了までの状態を制御するプロトコルであり、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で標準化されたプロトコルである。但し、本例では制御をＳＩＰで行っているが、制御プロトコルはＳＩＰ以外でも特に構わない。また、関係情報・共有可否情報管理サーバ１６、Ｋｎｏｗ−Ｗｈｏ検索サーバ２２、仲介人物であるＵｓｅｒＤ１８が所有する情報端末４８、目的人物であるＵｓｅｒＥ１１が所有する情報端末４４もＩＰネットワーク４６を経由して他のサーバ、端末と接続されている。
図５、図６、図２３、図２４はそれぞれ、情報端末４１〜４３、関係情報・共有可否情報管理サーバ１６、多人数会議制御サーバ２１、Ｋｎｏｗ−Ｗｈｏ検索サーバ２２の機能ブロック図である。図５、図６、図２３、図２４の機能ブロック図は、ソフトウェア上実現される論理的な機能構成を示した図であるが、各機能ブロックをハードウェアで構成しても構わない。各ブロックの機能について以下に説明する。
図５は、情報端末５１の機能ブロック図である。情報端末５１は例えば、図４の端末４１〜４３等である。端末４４、４８も同様の構成としてもよい。
情報端末５１は、例えば、コミュニケーション制御部５２と、情報送受信制御部５３と、Ｋｎｏｗ−Ｗｈｏ検索部５４と、人間関係管理部５５とを有する。
本ブロック図の中でコミュニケーション制御部５２の会議室入退室管理・制御部５６は自端末の電子会議室入退室状態を管理し、ユーザから入力される入室、退室要求を受け、外部要求のトリガリングを行い、また外部からの会議室情報を受け取り、状態を把握する。文字・音声映像情報入出力部５７はコミュニケーションで利用される文字・音声・映像情報を外部へ送信するためのフォーマットに変換する、もしくは受信した情報を端末へ表示するためのフォーマットに変換する作業を行う。
図５は、情報端末５１の機能ブロック図である。情報端末５１は例えば、図４の端末４１〜４３等である。端末４４、４８も同様の構成としてもよい。
情報端末５１は、例えば、コミュニケーション制御部５２と、情報送受信制御部５３と、Ｋｎｏｗ−Ｗｈｏ検索部５４と、人間関係管理部５５とを有する。
本ブロック図の中でコミュニケーション制御部５２の会議室入退室管理・制御部５６は自端末の電子会議室入退室状態を管理し、ユーザから入力される入室、退室要求を受け、外部要求のトリガリングを行い、また外部からの会議室情報を受け取り、状態を把握する。文字・音声映像情報入出力部５７はコミュニケーションで利用される文字・音声・映像情報を外部へ送信するためのフォーマットに変換する、もしくは受信した情報を端末へ表示するためのフォーマットに変換する作業を行う。
Ｋｎｏｗ−Ｗｈｏ検索部５４のＫｎｏｗ−Ｗｈｏ検索制御部６４はユーザからの要求によりＫｎｏｗ−Ｗｈｏ検索を行うための外部要求のトリガリングを行う。また、検索結果メッセージを受信し、その結果をユーザに通知する。人間関係管理部５５の人間関係情報管理部６５は、自分の端末の適宜の記憶部に保存された電子メール等の情報から取得した自分と他人との関係情報（図１の４、５、６）を管理する部分であり、人間関係情報入出力制御部６６がこれら情報の出力可否を判断し、入力された情報を人間関係情報管理部６５に蓄積する作業を行う。
情報送受信制御部５３は、主に外部との通信を行う為のプロトコルインターフェースを担当するブロックである。多人数コミュニケーション制御情報分析・構築部５８は、電子会議室への入退室情報の通信プロトコルに合ったメッセージフォーマット変換作業を行う。コミュニケーション情報構築・分析部５９は、コミュニケーションに利用する文字、音声、映像等の情報を外部送信する為に、通信プロトコルに合ったメッセージヘッダの付与、適切なメッセージ長への変換等を行う。これらメッセージは、多人数コミュニケーション情報送受信部６２により実際に送受信される。また、Ｋｎｏｗ−Ｗｈｏ検索情報構築・分析部６０は、Ｋｎｏｗ−Ｗｈｏ検索についての情報の通信プロトコルに合ったメッセージフォーマット変換作業を行う。このメッセージは、Ｋｎｏｗ−Ｗｈｏ検索関連情報送受信部６３により実際に送受信される。人間関係情報構築、分析部６１は、人間関係情報の通信プロトコルに合ったメッセージフォーマット変換作業を行う。このメッセージは、人間関係情報送受信部６７により実際に送受信される。
情報送受信制御部５３は、主に外部との通信を行う為のプロトコルインターフェースを担当するブロックである。多人数コミュニケーション制御情報分析・構築部５８は、電子会議室への入退室情報の通信プロトコルに合ったメッセージフォーマット変換作業を行う。コミュニケーション情報構築・分析部５９は、コミュニケーションに利用する文字、音声、映像等の情報を外部送信する為に、通信プロトコルに合ったメッセージヘッダの付与、適切なメッセージ長への変換等を行う。これらメッセージは、多人数コミュニケーション情報送受信部６２により実際に送受信される。また、Ｋｎｏｗ−Ｗｈｏ検索情報構築・分析部６０は、Ｋｎｏｗ−Ｗｈｏ検索についての情報の通信プロトコルに合ったメッセージフォーマット変換作業を行う。このメッセージは、Ｋｎｏｗ−Ｗｈｏ検索関連情報送受信部６３により実際に送受信される。人間関係情報構築、分析部６１は、人間関係情報の通信プロトコルに合ったメッセージフォーマット変換作業を行う。このメッセージは、人間関係情報送受信部６７により実際に送受信される。
図６は、関係情報・共有可否情報管理サーバ１６の機能ブロック図である。
関係情報・共有可否情報管理サーバ１６は、例えば、仲介者情報制御・算出部７２と、情報送受信機能７３と、共有判断部７４とを有する。
本ブロック図の中で仲介者情報制御・算出部７２の関係情報管理部８４は、パブリックに管理されたユーザ間の関係情報の管理、及びプライベートなユーザ間の関係情報の管理を行う。例えば、パブリックなユーザ間関係情報を保持するためのテーブル１６１、１６７を有する。仲介パス算出部８５は、関係情報管理部８４に蓄積された情報を利用して、ユーザとユーザを仲介する第３者のユーザを算出する。関係情報問い合わせ制御部８６は、仲介者の算出要求等を受信して、各ブロックの動作のトリガリングを行う。また、要求の受信と計算結果の返信を管理、制御する。
共有判断部７４の共有判断情報管理部８７は、各ユーザが関係情報管理部８４で保持する人間関係情報をアクセス制御に関する情報を管理する。また、共有判定部８８は、上記アクセス制御情報を用いて共有可否の判断を行う。
関係情報・共有可否情報管理サーバ１６は、例えば、仲介者情報制御・算出部７２と、情報送受信機能７３と、共有判断部７４とを有する。
本ブロック図の中で仲介者情報制御・算出部７２の関係情報管理部８４は、パブリックに管理されたユーザ間の関係情報の管理、及びプライベートなユーザ間の関係情報の管理を行う。例えば、パブリックなユーザ間関係情報を保持するためのテーブル１６１、１６７を有する。仲介パス算出部８５は、関係情報管理部８４に蓄積された情報を利用して、ユーザとユーザを仲介する第３者のユーザを算出する。関係情報問い合わせ制御部８６は、仲介者の算出要求等を受信して、各ブロックの動作のトリガリングを行う。また、要求の受信と計算結果の返信を管理、制御する。
共有判断部７４の共有判断情報管理部８７は、各ユーザが関係情報管理部８４で保持する人間関係情報をアクセス制御に関する情報を管理する。また、共有判定部８８は、上記アクセス制御情報を用いて共有可否の判断を行う。
情報送受信機能７３は、主に外部との通信を行う為のプロトコルインターフェースを担当するブロックである。Ｋｎｏｗ−Ｗｈｏ検索情報構築・分析部７８は、Ｋｎｏｗ−Ｗｈｏ検索についての情報の通信プロトコルに合ったメッセージフォーマット変換作業を行う。このメッセージは、Ｋｎｏｗ−Ｗｈｏ検索情報送受信部８１により実際に送受信される。関係情報問合せ情報構築・分析部７９は、各端末に対して、共有判定部８８の判断に則った関係情報の問合せに関する情報の通信プロトコルに合ったメッセージフォーマット変換作業を行う。このメッセージは、関係情報問合せ送受信部８２により実際に送受信される。共有判断情報分析部８０は、他サーバで管理するプレゼンス情報や会議室への入退室情報等の情報が記述されたメッセージを受信し、分析する。このメッセージは、共有判断情報受信部８３により実際に受信される。
図２３は、多人数会議サーバ２１の機能ブロック図である。
多人数会議サーバ２１は、例えば、会議室管理部２９１と、情報送受信制御部２９２とを有する。
本ブロック図の中で会議室管理部２９１の会議室情報・入室ユーザ情報管理部２９３は、本サーバ２１が開設している電子会議室の管理、及び各会議室へのユーザ入室情報の管理を行う。会議室入退室制御部２９４は、各ユーザの電子会議室への入退室要求を受け取り、入退室の可否、入室、退室のトリガリングを行う。
情報送受信制御部２９２は、これら情報について、主に外部との通信を行う為のプロトコルインターフェースを担当するブロックである。会議室入退室情報分析・構築部２９５は、会議室の入退室についての情報の通信プロトコルに合ったメッセージフォーマット変換作業を行う。このメッセージは、会議室入退室情報送受信部２９６により実際に送受信される。
多人数会議サーバ２１は、例えば、会議室管理部２９１と、情報送受信制御部２９２とを有する。
本ブロック図の中で会議室管理部２９１の会議室情報・入室ユーザ情報管理部２９３は、本サーバ２１が開設している電子会議室の管理、及び各会議室へのユーザ入室情報の管理を行う。会議室入退室制御部２９４は、各ユーザの電子会議室への入退室要求を受け取り、入退室の可否、入室、退室のトリガリングを行う。
情報送受信制御部２９２は、これら情報について、主に外部との通信を行う為のプロトコルインターフェースを担当するブロックである。会議室入退室情報分析・構築部２９５は、会議室の入退室についての情報の通信プロトコルに合ったメッセージフォーマット変換作業を行う。このメッセージは、会議室入退室情報送受信部２９６により実際に送受信される。
図２４は、Ｋｎｏｗ−Ｗｈｏ検索サーバ２２の機能ブロック図である。
Ｋｎｏｗ−Ｗｈｏ検索サーバ２２は、例えば、Ｋｎｏｗ−Ｗｈｏ検索制御部３０２と、情報送受信制御部３０１とを有する。
本ブロックの中でＫｎｏｗ−Ｗｈｏ検索制御部３０２は、実際に関係する動作を行う。例えば、Ｋｎｏｗ−Ｗｈｏ検索制御部３０２は、Ｋｎｏｗ−Ｗｈｏデータベース２４を参照し、入力されるキーワードに対して、関連する情報を知っているユーザの識別情報を取得する。例えば、Ｋｎｏｗ−Ｗｈｏデータベース２４は、情報のキーワードに対応して、その情報を知っているユーザの識別情報がされる。なお、これらの情報は、例えば、論文などの公開された情報から得られたものをＫｎｏｗ−Ｗｈｏデータベース２４に記憶しておくことができる。また、関係する情報についての通信プロトコルに合ったメッセージ変換作業をＫｎｏｗ−Ｗｈｏ検索関連情報分析・構築部３０３が行う。実際のメッセージ送受信をＫｎｏｗ−Ｗｈｏ検索関連情報送受信部３０４が行う。
Ｋｎｏｗ−Ｗｈｏ検索サーバ２２は、例えば、Ｋｎｏｗ−Ｗｈｏ検索制御部３０２と、情報送受信制御部３０１とを有する。
本ブロックの中でＫｎｏｗ−Ｗｈｏ検索制御部３０２は、実際に関係する動作を行う。例えば、Ｋｎｏｗ−Ｗｈｏ検索制御部３０２は、Ｋｎｏｗ−Ｗｈｏデータベース２４を参照し、入力されるキーワードに対して、関連する情報を知っているユーザの識別情報を取得する。例えば、Ｋｎｏｗ−Ｗｈｏデータベース２４は、情報のキーワードに対応して、その情報を知っているユーザの識別情報がされる。なお、これらの情報は、例えば、論文などの公開された情報から得られたものをＫｎｏｗ−Ｗｈｏデータベース２４に記憶しておくことができる。また、関係する情報についての通信プロトコルに合ったメッセージ変換作業をＫｎｏｗ−Ｗｈｏ検索関連情報分析・構築部３０３が行う。実際のメッセージ送受信をＫｎｏｗ−Ｗｈｏ検索関連情報送受信部３０４が行う。
図７には、図５、図６、図２３、図２４で示した各機能ブロックが、ハードウェア上、どのように実現されているかを示す。各装置は、例えば、ＣＰＵ（処理部）９３と、メモリ９２と、ディスクストレージと、各インタフェース９７、９８、９９とを有する。また、各装置は、入力部、出力部、表示部等を有してもよい。
図５、図６、図２３、図２４に示した種々の機能ブロックの動作は、図７に示すメモリ９２の処理モジュール群９５に収納されており、動作時にはＣＰＵ９３がその動作手順を読み出して実行する。個々の処理モジュールが動作する際に必要な情報は、ハードディスク等のディスクストレージ上に保存された恒久的な情報管理テーブル１０３、及びメモリ９２上の一時的な情報管理テーブル９４に格納されており必要に応じて読み出し、書き込みが行われる。また、４１〜４４に示す情報端末が実際に文字通信を行う際には１０１に示すキーボード・マウス等の入力部をマウス・キーボード入力インターフェース９８に接続して利用する。また、音声、映像通信を行う際には１０２に示すスピーカ、マイク、ＰＣカメラなどのデバイスを音声・映像入出力インターフェース９９に接続して利用する。実際のデータはデータバス９６を経由してＣＰＵ９３に転送され処理が行われる。また、ＩＰネットワーク４６にはネットワークインターフェース９７を経由して接続する。
図５、図６、図２３、図２４に示した種々の機能ブロックの動作は、図７に示すメモリ９２の処理モジュール群９５に収納されており、動作時にはＣＰＵ９３がその動作手順を読み出して実行する。個々の処理モジュールが動作する際に必要な情報は、ハードディスク等のディスクストレージ上に保存された恒久的な情報管理テーブル１０３、及びメモリ９２上の一時的な情報管理テーブル９４に格納されており必要に応じて読み出し、書き込みが行われる。また、４１〜４４に示す情報端末が実際に文字通信を行う際には１０１に示すキーボード・マウス等の入力部をマウス・キーボード入力インターフェース９８に接続して利用する。また、音声、映像通信を行う際には１０２に示すスピーカ、マイク、ＰＣカメラなどのデバイスを音声・映像入出力インターフェース９９に接続して利用する。実際のデータはデータバス９６を経由してＣＰＵ９３に転送され処理が行われる。また、ＩＰネットワーク４６にはネットワークインターフェース９７を経由して接続する。
図８は、図３に示した動作実施の形態の動作シーケンス図である。図８のシーケンスにより図３の動作内容の詳細を説明する。
まず始めに、各ユーザがシーケンスの動作に入る前に事前に保持しているプライベートな関係情報、及び関係情報・共有可否情報管理サーバが保持しているパブリックな関係情報について説明する。
図９は、入退室管理テーブル１４１の構成例である。入退室管理テーブル１４１は、電子会議室の会議室ＩＤと参加ユーザであるＵｓｅｒのＩＤを対応して記憶する。
まず始めに、各ユーザがシーケンスの動作に入る前に事前に保持しているプライベートな関係情報、及び関係情報・共有可否情報管理サーバが保持しているパブリックな関係情報について説明する。
図９は、入退室管理テーブル１４１の構成例である。入退室管理テーブル１４１は、電子会議室の会議室ＩＤと参加ユーザであるＵｓｅｒのＩＤを対応して記憶する。
図１０は、各ユーザが保持するプライベートな関係情報の例を示すテーブル１５１の構成例である。
本テーブル１５１は、関係情報の所有者とフィールド１５２に示すユーザＩＤを持つユーザとの関係を記述している。フィールド１５２には相手のユーザＩＤを示す。フィールド１５３には対象ユーザＩＤの外部公開している名称（例えば、姓、氏名）を示すが、本フィールドについては後述詳細を説明する。フィールド１５５には各関係情報の公開レベルを示す。公開レベルについてはフィールド１５３同様、後述詳細を説明する。尚、テーブル１５１に記載する情報は例えば、各ユーザの情報端末にインストールされて電子メールソフトに保存された電子メールの送受信情報を各ユーザが各自、自分が所有する情報端末上で分析して生成させることもできる。例えば、取得源をフィールド１５４に記憶してもよい。なお、本実施の形態では、テーブル１５１に記載された情報の生成方法については特に制限せず、どのような方法で取得しても構わない。また、テーブル１５１の構成についてもシステムによっては仲介パス検索をより高度に行うために、例えばお互いの信頼度や親密度の様な人間関係を示すための様々な情報が付加される可能性が考えられるが、基本的に１５２のようなフィールドを持ち、関係を持つ相手が分かれば、テーブルスキーマはどのような構成でも構わない。
本テーブル１５１は、関係情報の所有者とフィールド１５２に示すユーザＩＤを持つユーザとの関係を記述している。フィールド１５２には相手のユーザＩＤを示す。フィールド１５３には対象ユーザＩＤの外部公開している名称（例えば、姓、氏名）を示すが、本フィールドについては後述詳細を説明する。フィールド１５５には各関係情報の公開レベルを示す。公開レベルについてはフィールド１５３同様、後述詳細を説明する。尚、テーブル１５１に記載する情報は例えば、各ユーザの情報端末にインストールされて電子メールソフトに保存された電子メールの送受信情報を各ユーザが各自、自分が所有する情報端末上で分析して生成させることもできる。例えば、取得源をフィールド１５４に記憶してもよい。なお、本実施の形態では、テーブル１５１に記載された情報の生成方法については特に制限せず、どのような方法で取得しても構わない。また、テーブル１５１の構成についてもシステムによっては仲介パス検索をより高度に行うために、例えばお互いの信頼度や親密度の様な人間関係を示すための様々な情報が付加される可能性が考えられるが、基本的に１５２のようなフィールドを持ち、関係を持つ相手が分かれば、テーブルスキーマはどのような構成でも構わない。
図１１は、関係情報・共有可否情報管理サーバ２１が保持するパブリックな関係情報の例を示すテーブル１６１、１６７の構成例である。
テーブル１６１では、同一レコード上のフィールド１６２で示すユーザＩＤとフィールド１６３で示すユーザＩＤに関係があることを示す。また、テーブル１６７は、フィールド１６８に記述されたユーザＩＤがどのような名称で公開されているかをフィールド１６９に示したテーブルであるが、本テーブルについては後に詳細を説明する。尚、テーブル１６１に記載する情報は例えば、学会論文や特許文献等公開された情報の共著関係や参照関係を自動的に分析して関係情報を生成する又は手動で入力する方法等をとることができる。例えば、論文や特許文献、研究報告から著者名を抽出し、テーブル１６７を参照してユーザＩＤに変換し、テーブル１６１に登録してもよい。なお、本実施の形態では、テーブル１６１に記載された情報の生成方法については特に制限せず、どのような方法で生成しても構わない。なお、すでに公開された情報以外にも、公開予定の情報、公開されることが想定される情報等をさらに用いてもよい。また、テーブル１６１の構成についてもテーブル１５１と同様、システムにより人間関係を示すための様々な情報が付加される可能性が考えられるが、基本的にテーブル１６２、１６３のようなフィールドにより、関係を持つ２ユーザを示す情報が存在すれば、テーブルスキーマはどのような構成でも構わない。
テーブル１６１では、同一レコード上のフィールド１６２で示すユーザＩＤとフィールド１６３で示すユーザＩＤに関係があることを示す。また、テーブル１６７は、フィールド１６８に記述されたユーザＩＤがどのような名称で公開されているかをフィールド１６９に示したテーブルであるが、本テーブルについては後に詳細を説明する。尚、テーブル１６１に記載する情報は例えば、学会論文や特許文献等公開された情報の共著関係や参照関係を自動的に分析して関係情報を生成する又は手動で入力する方法等をとることができる。例えば、論文や特許文献、研究報告から著者名を抽出し、テーブル１６７を参照してユーザＩＤに変換し、テーブル１６１に登録してもよい。なお、本実施の形態では、テーブル１６１に記載された情報の生成方法については特に制限せず、どのような方法で生成しても構わない。なお、すでに公開された情報以外にも、公開予定の情報、公開されることが想定される情報等をさらに用いてもよい。また、テーブル１６１の構成についてもテーブル１５１と同様、システムにより人間関係を示すための様々な情報が付加される可能性が考えられるが、基本的にテーブル１６２、１６３のようなフィールドにより、関係を持つ２ユーザを示す情報が存在すれば、テーブルスキーマはどのような構成でも構わない。
１−１．第１の動作パターン
次に、シーケンス図の各ステップについての具体的な動作内容を説明する。
まず、情報端末４１は、多人数会議制御サーバ２１に会議室入室要求を送信する（ステップ１１１）。会議室入室要求は例えば、入室する会議室Ａの会議室ＩＤ（例えば、ｃｏｎｆＡ）と、ユーザＩＤとを含む、より具体的には、ＵｓｅｒＡの所有する情報端末４１の図５に示すコミュニケーション制御部５２の会議室入退室制御部５６が、図３の２５に示す電子会議室Ａに入室する為に、会議室への入室要望の作成を情報送受信制御部５３の多人数コミュニケーション制御情報分析・構築部５８に指示する。情報端末４１は、多人数コミュニケーション情報送受信部６２経由でステップ１１１において多人数会議制御サーバ２１に対して入室要求を送信して、電子会議室Ａに入室する。
次に、シーケンス図の各ステップについての具体的な動作内容を説明する。
まず、情報端末４１は、多人数会議制御サーバ２１に会議室入室要求を送信する（ステップ１１１）。会議室入室要求は例えば、入室する会議室Ａの会議室ＩＤ（例えば、ｃｏｎｆＡ）と、ユーザＩＤとを含む、より具体的には、ＵｓｅｒＡの所有する情報端末４１の図５に示すコミュニケーション制御部５２の会議室入退室制御部５６が、図３の２５に示す電子会議室Ａに入室する為に、会議室への入室要望の作成を情報送受信制御部５３の多人数コミュニケーション制御情報分析・構築部５８に指示する。情報端末４１は、多人数コミュニケーション情報送受信部６２経由でステップ１１１において多人数会議制御サーバ２１に対して入室要求を送信して、電子会議室Ａに入室する。
多人数会議制御サーバ２１は、会議室入室要求を受信し、受信された会議室入室要求内の会議室ＩＤと、ユーザＩＤとを入退室管理テーブル１４１に記憶する。より具体的には、多人数会議制御サーバ２１は、図２３の会議室入退室情報送受信部２９６でステップ１１１の要求を受信すると、その内容を会議室入退室情報分析・構築部２９５で分析し、会議室管理部２９１の会議室入退室管理部２９４に通知する。会議室入退室管理部２９４は、この要求を受け付けると会議室情報・入室ユーザ情報管理部２９３で管理する図９に示す様な会議室の入退室管理テーブル１４１に、図３の２５に示す電子会議室Ａの会議室ＩＤと参加ユーザであるＵｓｅｒＡのＩＤをそれぞれフィールド１４２、１４３にペアで記憶し、ＵｓｅｒＡが会議室へ入室したことを記録する。
また、会議室入退室管理部２９４はＵｓｅｒＡが電子会議室Ａに入室したことを示す会議室情報を、会議室入退室情報分析・構築部２９５で情報を構築して、会議室入退室情報送受信部２９６から関係情報・共有可否情報管理サーバ１６に送信する（ステップ１１２）。例えば、会議室情報は、会議室ＩＤとユーザＩＤを含む。関係情報・共有可否情報管理サーバ１６は、会議室情報を受信し、テーブル１４４に登録する。より具体的には、関係情報・共有可否情報管理サーバ１６はステップ１１２で送信された情報を図６の情報送受信機能７３内の共有判断情報送受信部８３で受信し、共有判断情報分析部８０で分析し、その内容を共有判断部７４の共有判断情報管理部８７に通知する。共有判断情報管理部８７は受信した情報を内部に保持する。結果、共有判断情報管理部８７は多人数会議制御サーバ２１が持つ図９に示した会議室の入退室管理テーブル１４１と同じテーブル１４４を内部に保持する。なお、本実施の形態では本ステップで動作した共有判断情報送受信部８３、共有判断情報分析部８０、共有判断情報管理部８７は、一例として、多人数会議制御サーバ２１が保持する電子会議室への入退室情報をそれぞれ受信、分析、保存しているが、取り扱う情報は本実施の形態での情報には限定しない。他のシステムでは共有判断情報が電子会議室への入退室情報で無い場合もあり、その場合、各機能ブロックは各システムでの共有判断情報を受信、分析、保存する。
ステップ１１３、１１４、及び１１５、１１６は、ＵｓｅｒＢの情報端末４２、ＵｓｅｒＣの情報端末４３がステップ１１１と同様、多人数会議制御サーバ２１に対して、図３の２５に示す電子会議室Ａへの入室要求を送信し、その情報を関係情報・共有可否情報管理サーバ１６に送信しているが、これらステップでの情報端末と各サーバの動作についてはステップ１１１、１１２と同様である。
ステップ１１１から１１６の結果、多人数会議制御サーバ２１の会議室情報・入室ユーザ情報管理部２９３、及び関係情報・共有可否情報管理サーバ１６の共有判断情報管理部８７では図９のテーブル１４１、１４４の様にＵｓｅｒＡ、ＵｓｅｒＢ、ＵｓｅｒＣが同じ会議室に入室している情報を保持する。本例では図３の２５に示す電子会議室Ａの会議室ＩＤを”ＣｏｎｆＡ”、ＵｓｅｒＡ、ＵｓｅｒＢ、ＵｓｅｒＣのユーザＩＤをそれぞれ”ｓｉｐ：ＵｓｅｒＡ＠ａｂｃ．ｃｏｍ”、”ｓｉｐ：ＵｓｅｒＢ＠ａｂｃ．ｃｏｍ”、”ｓｉｐ：ＵｓｅｒＣ＠ａｂｃ．ｃｏｍ”としている。本実施の形態では、関係情報・共有可否情報管理サーバ１６は、テーブル１４４の様にＵｓｅｒＡ、ＵｓｅｒＢ、ＵｓｅｒＣが同一会議室に入室していることを確認することで、３ユーザが現在信頼関係を持っており、各ユーザのプライベートな関係情報が共有可能であると判断できる。
ステップ１１１から１１６の結果、多人数会議制御サーバ２１の会議室情報・入室ユーザ情報管理部２９３、及び関係情報・共有可否情報管理サーバ１６の共有判断情報管理部８７では図９のテーブル１４１、１４４の様にＵｓｅｒＡ、ＵｓｅｒＢ、ＵｓｅｒＣが同じ会議室に入室している情報を保持する。本例では図３の２５に示す電子会議室Ａの会議室ＩＤを”ＣｏｎｆＡ”、ＵｓｅｒＡ、ＵｓｅｒＢ、ＵｓｅｒＣのユーザＩＤをそれぞれ”ｓｉｐ：ＵｓｅｒＡ＠ａｂｃ．ｃｏｍ”、”ｓｉｐ：ＵｓｅｒＢ＠ａｂｃ．ｃｏｍ”、”ｓｉｐ：ＵｓｅｒＣ＠ａｂｃ．ｃｏｍ”としている。本実施の形態では、関係情報・共有可否情報管理サーバ１６は、テーブル１４４の様にＵｓｅｒＡ、ＵｓｅｒＢ、ＵｓｅｒＣが同一会議室に入室していることを確認することで、３ユーザが現在信頼関係を持っており、各ユーザのプライベートな関係情報が共有可能であると判断できる。
その後、電子会議室Ａに入室した各ユーザは、例えば、電子会議室Ａ内で文字チャットを行う（ステップ１１７〜１２２）。例えば、ＵｓｅｒＡが発言を行う時は、ＵｓｅｒＡが所有する情報端末４１のキーボード１０１で入力された文字が、図５のコミュニケーション制御部５２の文字・音声・映像情報入出力部５７へ伝達される。また、情報送受信制御部５３のコミュニケーション情報構築・分析部５９で文字チャット用のプロトコルに合った情報形式を構築し、多人数コミュニケーション情報送受信部６２から送信される。このようにして送信された情報は、図８のステップ１１７のように多人数会議制御サーバ２１に送信される。多人数会議制御サーバ２１は、ステップ１１７で受信した文字情報を図９のテーブル１４１に登録された情報を確認し、ＵｓｅｒＡと同じ会議室Ａに入室しているＵｓｅｒＢ、及びＵｓｅｒＣに対してステップ１１８で転送する。他のユーザのメッセージについても同様であり、ＵｓｅｒＢの発言についてはステップ１１９、１２０で、ＵｓｅｒＣの発言についてはステップ１２１、１２２で同じ電子会議室に入室している他ユーザに対して転送される。
ステップ１２４では、この様な文字チャットで、例えばＵｓｅｒＡが発言の中で出た来週に開催される”○×展示会”の詳細が気になり、キーワードとして選択したとする。例えば、キーワードが直接入力されてもよいし、チャット中の文字、単語を選択候補としてもよく、そのひとつが選択されるようにしてもよい。
情報端末４１は選択されたキーワードと、自らのユーザＩＤとを含むＫｎｏｗ−Ｗｈｏ検索要求を送信する（ステップ１２５）。例えば、ＵｓｅｒＡが所有する情報端末４１は、図５のＫｎｏｗ−Ｗｈｏ検索部５４のＫｎｏｗ−Ｗｈｏ検索制御部６４で、気になった”○×展示会”をキーワードとしたＫｎｏｗ−Ｗｈｏ検索要求を情報送受信制御部５３のＫｎｏｗ−Ｗｈｏ検索情報構築・分析部６０で構築し、それをＫｎｏｗ−Ｗｈｏ検索関連情報送受信部６３経由でステップ１２５においてＫｎｏｗ−Ｗｈｏ検索サーバ２２に送信する。
情報端末４１は選択されたキーワードと、自らのユーザＩＤとを含むＫｎｏｗ−Ｗｈｏ検索要求を送信する（ステップ１２５）。例えば、ＵｓｅｒＡが所有する情報端末４１は、図５のＫｎｏｗ−Ｗｈｏ検索部５４のＫｎｏｗ−Ｗｈｏ検索制御部６４で、気になった”○×展示会”をキーワードとしたＫｎｏｗ−Ｗｈｏ検索要求を情報送受信制御部５３のＫｎｏｗ−Ｗｈｏ検索情報構築・分析部６０で構築し、それをＫｎｏｗ−Ｗｈｏ検索関連情報送受信部６３経由でステップ１２５においてＫｎｏｗ−Ｗｈｏ検索サーバ２２に送信する。
その後、Ｋｎｏｗ−Ｗｈｏ検索サーバ２２は、ステップ１２５で送信された情報を図２４の情報送受信制御部３０１のＫｎｏｗ−Ｗｈｏ検索関連情報送受信部３０４で受信する。次に、その要求の内容をＫｎｏｗ−Ｗｈｏ検索関連情報分析・構築部３０３で解析し、Ｋｎｏｗ−Ｗｈｏ検索制御部３０２に通知する。Ｋｎｏｗ−Ｗｈｏ検索制御部３０２は通知を受けるとステップ１２６でＫｎｏｗ−Ｗｈｏ検索を開始する。例えば、受信されたＫｎｏｗ−Ｗｈｏ検索要求に含まれるキーワードに対応するユーザ（目的人物）を取得する。なお、Ｋｎｏｗ−Ｗｈｏ検索の方式については本実施の形態では限定せず、どのような方式でも構わない。本例ではＫｎｏｗ−Ｗｈｏ検索の結果、図３の１１に示すＵｓｅｒＥが目的人物であったとする。本例ではＵｓｅｒＥ一人が目的人物であった場合を示すが、もし複数人物が目的人物の候補として挙がった場合、全ての候補を通知してもよい。
次に、Ｋｎｏｗ−Ｗｈｏ検索サーバ２２は、Ｋｎｏｗ−Ｗｈｏ検索結果を関係情報共有可否情報管理サーバ１６に送信する（ステップ１２７）。この情報には目的人物（この例ではユーザＥ）と、仲介を希望する人物（この例ではユーザＡ）のユーザＩＤが記載されている。さらにキーワードを含んでもよい。Ｋｎｏｗ−Ｗｈｏ検索サーバ２２は検索結果を図２４に示す情報送受信制御部３０１のＫｎｏｗ−Ｗｈｏ検索関連情報分析・構築部３０３で送信情報を構築した後、Ｋｎｏｗ−Ｗｈｏ検索関連情報送受信部３０４からステップ１２７で関係情報・共有可否情報管理サーバ１６に送信する。
送信された情報は図６の情報送受信機能７３内のＫｎｏｗ−Ｗｈｏ検索送受信部８１で受信し、その後、Ｋｎｏｗ−Ｗｈｏ検索情報構築・分析部７８で内容を解析して仲介人物情報制御・算出部７２の仲介パス算出部８５に通知される。
送信された情報は図６の情報送受信機能７３内のＫｎｏｗ−Ｗｈｏ検索送受信部８１で受信し、その後、Ｋｎｏｗ−Ｗｈｏ検索情報構築・分析部７８で内容を解析して仲介人物情報制御・算出部７２の仲介パス算出部８５に通知される。
仲介パス算出部８５はまず、関係情報管理部８４に保存されたパブリックな関係情報１６１を検索する。パブリックな関係情報を図１１のテーブル１６１に示す。仲介パス算出部８５はこのテーブルから目的人物であるＵｓｅｒＥに対応する仲介人物候補を検索する。本例ではテーブル１６１のフィールド１６２、１６３を確認した結果、レコード１７０でＵｓｅｒＥと関係する人物にｓｉｐ：ＵｓｅｒＤ＠ａｂｃ．ｃｏｍで示されるＵｓｅｒＤと、ｓｉｐ：ＵｓｅｒＨ＠ａｂｃ．ｃｏｍで示されるＵｓｅｒＨとが存在する事が分かる。よって、本例ではパブリックな関係情報から仲介候補者をＵｓｅｒＤ、ＵｓｅｒＨと判断する。
次に、仲介パス算出部８５は、プライベートな関係情報からさらに詳細な仲介人物を検索するために、仲介希望人物を確認して、図６に示す共有判断部７４の共有判定部８８に問合せを行う。本実施の形態では１に示すＵｓｅｒＡが仲介希望人物である。共有判定部８８は問合せを受けると、共有判断情報管理部８７に蓄積された共有判断情報１４４を確認し、ＵｓｅｒＡがどのユーザと関係情報を共有できるかを確認し、仲介パス算出部８５に共有可能なユーザＩＤを通知する。本実施の形態では前述で、共有判断情報１４４は図９のテーブル１４１と同様の情報を有しており、同一電子会議室に入室しているユーザ同士が関係情報を共有できると判断すると説明した。よって本実施の形態ではテーブル１４４の記述通り、ＵｓｅｒＡは同一電子会議室に入室しているＵｓｅｒＢ（ｓｉｐ：ＵｓｅｒＢ＠ａｂｃ．ｃｏｍ）、ＵｓｅｒＣ（ｓｉｐ：ＵｓｅｒＣ＠ａｂｃ．ｃｏｍ）と関係情報を共有できると判断される。なお、関係情報共有可否情報蓄積サーバ１６はテーブル１４４を有さず、多人数会議制御サーバ２１に問い合わせてもよい。また、パブリックな関係情報で求められたユーザのひとりと、電子会議室Ａに入室しているユーザのひとりが同じ場合には、以下のステップ１２８、１２９を省略してステップ１３０へ移ることができる。
本実施の形態ではさらに、関係情報の共有について、単純な可否だけでなく、共有レベルを設定して、段階的に共有範囲を変化させることも可能である。共有レベルを設定する場合、共有判断情報管理部８７は、図９のテーブル１４１の他に、図１２に示すテーブル１７１のような共有レベルを判断するためのテンプレートテーブルを保持する。本テーブル１７１は、フィールド１７２に会議室ＩＤ、フィールド１７３に共有レベルが対応して記述されている。このテーブル１７１を利用して、各電子会議室において各ユーザが同一会議室に入室していた場合の共有レベルを判断する。本実施の形態では、図３の電子会議室Ａは前述の通り、会議室ＩＤが”ＣｏｎｆＡ”であるので、テーブル１７１より共有レベルは３であると判断できる。
また、図１０のテーブル１５１に示す各ユーザが持つ他人との関係情報の公開レベルフィールド１５５には、ユーザが自分と他人との各関係情報の公開可能レベルが記述されている。例えば、レコード１５６に示す関係情報については公開レベルフィールド１５５の値が３であるので、３以上の共有レベルで関係情報を共有中の他ユーザにしか公開されない。本例では共有レベルの値を数字で表しているが、表現方法は制限しない。しかし、どのような表現方法を取ったとしても、各ユーザは他ユーザの関係情報について、公開レベルが設定された共有レベル以下の者のみ参照可能となる。このように共有レベルを設定すると、各ユーザが他人との関係情報に重要度を付けることが可能となり、公開レベルを関係単位で詳細設定可能となる。この公開レベルは例えば、電子メールの内容をテキスト解析し、送受信されている電子メール情報の内容がどの程度フォーマルな内容であるかを確認し、フォーマル度に合わせて、フォーマルな関係なら公開範囲を広げ（公開レベルを小さく設定し）、逆にインフォーマルな関係なら公開範囲を狭める（公開レベルを大きく設定する）ポリシで設定する方法が考えられる。公開レベルの付与方式については本実施の形態では特に制限せず、どのような手段を用いても構わない。
関係情報・共有可否情報管理サーバ１６は、共有可能と判断されたＵｓｅｒＢ、ＵｓｅｒＣに対して、仲介経路の有無を問い合わせる（ステップ１２８）。この問い合わせのためのメッセージには目的人物がＵｓｅｒＥ、仲介候補者がＵｓｅｒＤ、ＵｓｅｒＨである事が記述されている。
関係情報・共有可否情報管理サーバ１６の仲介パス算出部８５は、関係情報問い合わせ制御部８６に対して問合せ指示を出す。関係情報問い合わせ制御部８６は、共有関係が確認できたＵｓｅｒＢ、ＵｓｅｒＣに対して、目的人物間の仲介が可能であるかどうかの問合せを行うために、関係情報問い合わせ情報構築・分析部７９を経由して関係情報問合せ送受信部８２からステップ１２８でＵｓｅｒＢ、ＵｓｅｒＣに目的人物との関係を持っているかどうかの確認メッセージを送信する。メッセージには目的人物がＵｓｅｒＥ、仲介候補者がＵｓｅｒＤ、ＵｓｅｒＨである事が記述されている。また、このメッセージには、目的人物、仲介候補者の他、仲介希望者のユーザＩＤと現在共有中である条件も記述されている。送信先のユーザ端末が本当に共有状態である事を確認する為である。本例では図１２のテーブル１７１の形で共有レベルの設定がされている場合で手順を説明する。共有レベルの設定がある場合は、共有レベルもステップ１２８で同時に通知し、問い合わせ先ユーザがどの共有レベルまでを考慮すべきかについて伝達する。
関係情報・共有可否情報管理サーバ１６の仲介パス算出部８５は、関係情報問い合わせ制御部８６に対して問合せ指示を出す。関係情報問い合わせ制御部８６は、共有関係が確認できたＵｓｅｒＢ、ＵｓｅｒＣに対して、目的人物間の仲介が可能であるかどうかの問合せを行うために、関係情報問い合わせ情報構築・分析部７９を経由して関係情報問合せ送受信部８２からステップ１２８でＵｓｅｒＢ、ＵｓｅｒＣに目的人物との関係を持っているかどうかの確認メッセージを送信する。メッセージには目的人物がＵｓｅｒＥ、仲介候補者がＵｓｅｒＤ、ＵｓｅｒＨである事が記述されている。また、このメッセージには、目的人物、仲介候補者の他、仲介希望者のユーザＩＤと現在共有中である条件も記述されている。送信先のユーザ端末が本当に共有状態である事を確認する為である。本例では図１２のテーブル１７１の形で共有レベルの設定がされている場合で手順を説明する。共有レベルの設定がある場合は、共有レベルもステップ１２８で同時に通知し、問い合わせ先ユーザがどの共有レベルまでを考慮すべきかについて伝達する。
ステップ１２８で送信したメッセージは、ＵｓｅｒＢ、ＵｓｅｒＣそれぞれが所有する情報端末４２、４３（内部構造を図５の５１に示した）のＫｎｏｗ−Ｗｈｏ検索関係情報送受信部６３で受信され、人間関係情報構築・分析部６１を経由して人間関係管理部５５の人間関係情報入出力制御部６６に通知される。人間関係情報入出力制御部６６はまず、仲介希望者と関係共有の条件を確認する。共有の確認は端末が自動的に行っても良いし、ユーザに確認を求め、手動で確認しても良い。共有している事を確認すると、次に人間関係情報管理部６５に保存された、自分と他人の関係情報１５１を検索して目的人物又はパブリックな関係情報から取得された仲介候補者に対して、仲介可能かどうかを判断する。人間関係情報管理部６５ではテーブル１５１に示す様な各ユーザのプライベートな関係情報を保持している。図１０に示すテーブル１５１はＵｓｅｒＣが保持するテーブルの例であり、本例ではこのテーブルを利用して動作例を示す。テーブル１５１には本例で仲介候補者となっているＵｓｅｒＤがレコード１５７に存在していることが確認できる。また、レコード１５７の公開レベルフィールド１５５の値は２であり、本例の共有レベル３以下である。従って、問合せに対して公開できることが確認できる。ＵｓｅｒＣが所有する情報端末４３の人間関係情報入出力制御部６６はテーブル１５１を確認した結果、パブリック情報から得られた仲介候補者ＵｓｅｒＤに仲介可能と判断する。同様にして、ＵｓｅｒＨに仲介可能と判断する。
情報端末４３は、その結果を人間関係情報構築・分析部６１を経由してＫｎｏｗ−Ｗｈｏ検索関係情報送受信部６３からステップ１２９で関係情報・共有可否情報管理サーバ１６に通知する。ＵｓｅｒＢが所有する情報端末４２についても上記と同様の処理を行い、同じくステップ１２９で関係情報・共有可否情報蓄積サーバ１６に結果を通知する。例えば、情報端末４２は、仲介不可能であることを関係情報・共有可否情報蓄積サーバ１６に通知してもよい。
関係情報・共有可否情報管理サーバ１６は、問合せに対する結果を各ユーザの端末４２、４３から受信し、仲介依頼先、仲介人物を決定して、仲介依頼を送信する（ステップ１３０）。仲介依頼先としてＵｓｅｒＣ、仲介人物をＵｓｅｒＤ（又はＵｓｅｒＨ）として決定する。仲介依頼は、例えば、目的人物のＩＤと仲介人物とのＩＤとを含む。さらに、キーワード、依頼者（この例ではＵｓｅｒＡ）のＩＤを含んでも良い。なお、本例では、パブリックな関係情報とプライベートな関係情報の双方を参照しているが、仲介経路が定まれば、いずれか一方のみでもよい。
関係情報・共有可否情報管理サーバ１６は、問合せに対する結果を各ユーザの端末４２、４３から受信し、仲介依頼先、仲介人物を決定して、仲介依頼を送信する（ステップ１３０）。仲介依頼先としてＵｓｅｒＣ、仲介人物をＵｓｅｒＤ（又はＵｓｅｒＨ）として決定する。仲介依頼は、例えば、目的人物のＩＤと仲介人物とのＩＤとを含む。さらに、キーワード、依頼者（この例ではＵｓｅｒＡ）のＩＤを含んでも良い。なお、本例では、パブリックな関係情報とプライベートな関係情報の双方を参照しているが、仲介経路が定まれば、いずれか一方のみでもよい。
より具体的には、関係情報・共有可否情報蓄積サーバ１６はステップ１２９のメッセージを関係情報問い合わせ送受信部８２で受信し、関係情報問合せ情報構築・分析部７９経由で関係情報問合せ制御部８６に通知し、さらに関係情報問合せ制御部８６はその内容を仲介パス算出部８５に通知する。仲介パス算出部８５は、その結果を基に仲介依頼先を選定し、関係情報問合せ情報構築・分析部７９経由で関係情報問合せ送受信部８２から仲介依頼を送信する。本例では、ステップ１３０で仲介依頼をＵｓｅｒＣに送信している。また、これら処理で、もし複数ユーザから仲介可能である通知を受信した場合、サーバは実際に仲介依頼を送信するユーザを選択するが、本実施の形態ではその選択方式の詳細は、どのような構成でも構わない。この様に、関係情報・共有可否情報管理サーバ１６は、テーブル１６１に示す様なパブリックな関係情報と、仲介希望者との共有条件を満たす他ユーザが持つテーブル１５１に示す様なプライベートな関係情報とを組み合わせて最終的な仲介人物を選択し、仲介依頼を送信する。
ＵｓｅｒＣの情報端末４３は、仲介依頼を受信し、受信された仲介依頼に従い、仲介人物ＵｓｅｒＤに仲介を依頼し（ステップ１３１）、ＵｓｅｒＤは目的人物ＵｓｅｒＥに情報提供を依頼する（ステップ１３２）。
例えば、情報端末４３は、受信された仲介依頼に従い、ＵｓｅｒＤの情報端末４８に、例えば目的人物ＵｓｅｒＥのＩＤ、依頼者ＵｓｅｒＡのＩＤ、キーワード等を含む仲介依頼を送信する。情報端末４８は、情報端末４３からの仲介依頼に従い、ＵｓｅｒＥの情報端末４４に、例えば、依頼者ＵｓｅｒＡのＩＤ、キーワード等を含む情報提供依頼を送信する。情報端末４４は、情報提供依頼を受信すると、キーワードと依頼者等を表示部に表示する。ＵｓｅｒＥは、表示された情報から依頼があることを知り、ＵｓｅｒＡに情報提供する。
例えば、情報端末４３は、受信された仲介依頼に従い、ＵｓｅｒＤの情報端末４８に、例えば目的人物ＵｓｅｒＥのＩＤ、依頼者ＵｓｅｒＡのＩＤ、キーワード等を含む仲介依頼を送信する。情報端末４８は、情報端末４３からの仲介依頼に従い、ＵｓｅｒＥの情報端末４４に、例えば、依頼者ＵｓｅｒＡのＩＤ、キーワード等を含む情報提供依頼を送信する。情報端末４４は、情報提供依頼を受信すると、キーワードと依頼者等を表示部に表示する。ＵｓｅｒＥは、表示された情報から依頼があることを知り、ＵｓｅｒＡに情報提供する。
なお、ステップ１３１、１３２は、上述のように端末が自動的に依頼を送信する以外にも、例えば、情報端末４３がステップ１３０で受信した仲介依頼を表示部に表示し、表示をみたユーザＣが、ユーザＤに依頼するなどしてもよい。
より具体的には、ＵｓｅｒＣが所有する情報端末４３は、ステップ１３０のメッセージを人間関係情報送受信部６７で受信し、それを人間関係情報構築、分析部６１経由で人間関係情報入出力制御部６６に通知する。人間関係情報入出力制御部６６は、その情報を端末の画面に表示し、ＵｓｅｒＣに仲介依頼を受信した事を通知する。ＵｓｅｒＣは、その情報を基にステップ１３１で１８に示すＵｓｅｒＤに対して仲介依頼を行う。さらにＵｓｅｒＤは、１１に示すＵｓｅｒＥに情報提供依頼を行う。なお、ステップ１３１、１３２での具体的な依頼方法は、例えば、チャットで依頼を行う、電話で依頼を行う、直接会って依頼を行う等様々な方法をとることもできるが、本実施の形態ではその具体的な方法についてはいずれの方法でも構わない。
より具体的には、ＵｓｅｒＣが所有する情報端末４３は、ステップ１３０のメッセージを人間関係情報送受信部６７で受信し、それを人間関係情報構築、分析部６１経由で人間関係情報入出力制御部６６に通知する。人間関係情報入出力制御部６６は、その情報を端末の画面に表示し、ＵｓｅｒＣに仲介依頼を受信した事を通知する。ＵｓｅｒＣは、その情報を基にステップ１３１で１８に示すＵｓｅｒＤに対して仲介依頼を行う。さらにＵｓｅｒＤは、１１に示すＵｓｅｒＥに情報提供依頼を行う。なお、ステップ１３１、１３２での具体的な依頼方法は、例えば、チャットで依頼を行う、電話で依頼を行う、直接会って依頼を行う等様々な方法をとることもできるが、本実施の形態ではその具体的な方法についてはいずれの方法でも構わない。
また、最終的にステップ１３３の様に１１に示すＵｓｅｒＥは、何らかの形で情報を１に示すＵｓｅｒＡに提供する。具体的には、例えばＵｓｅｒＥが、電子会議室Ａに参加してＵｓｅｒＡの情報端末４１に対して直接情報を提供する、ＵｓｅｒＡに電話して情報提供する、ＵｓｅｒＡと直接会うアポイントを取って情報を提供する等、様々な方法が考えられるが、本実施の形態ではその具体的な方法はどれをとっても構わない。
また、もしステップ１３６の様に、例えばＵｓｅｒＡの情報端末４１が多人数会議制御サーバ２１に対して電子会議室Ａからの退室要求メッセージを送信し、それにより、１に示すＵｓｅｒＡが電子会議室Ａから退出すると、ステップ１３７の様に、その情報が多人数会議制御サーバ２１から関係情報・共有可否情報管理サーバ１６に送信される。その結果、関係情報・共有可否情報管理サーバ１６が管理する図９のテーブル１４４からＵｓｅｒＡが電子会議室Ａに入室しているレコードが削除され、関係情報の共有が解除される。端末４２、４３が退室要求を送信した場合も同様である。
また、もしステップ１３６の様に、例えばＵｓｅｒＡの情報端末４１が多人数会議制御サーバ２１に対して電子会議室Ａからの退室要求メッセージを送信し、それにより、１に示すＵｓｅｒＡが電子会議室Ａから退出すると、ステップ１３７の様に、その情報が多人数会議制御サーバ２１から関係情報・共有可否情報管理サーバ１６に送信される。その結果、関係情報・共有可否情報管理サーバ１６が管理する図９のテーブル１４４からＵｓｅｒＡが電子会議室Ａに入室しているレコードが削除され、関係情報の共有が解除される。端末４２、４３が退室要求を送信した場合も同様である。
本例ではＵｓｅｒＡはステップ１２５でＫｎｏｗ−Ｗｈｏ検索要求を送信した後、全てのシーケンスが終了するまで、サーバ、及び他ユーザからメッセージを受信しない。よって、ＵｓｅｒＡには目的人物、及び仲介人物の情報は一切通知されない。このように、依頼者ＵｓｅｒＡに対して目的人物、仲介人物を通知しない事で、仲介が成立しなかった場合でもＵｓｅｒＡには仲介人物、目的人物の情報がＵｓｅｒＡに流出する事を防止する事が可能となる。
（第１の動作パターンの変形例）
図１６は、第１の実施の形態のプライベートの関係情報の共有イメージ図である。
上述の例では、図１６の２１７、２１８、２１９の様に各ユーザがプライベートな関係情報を保持する。関係情報・共有可否情報管理サーバ１６は、２１１の様に保存されたテーブル１４４、１４１の情報から共有可能な他ユーザを判断し、プライベートな情報から仲介人物検索を行うためにＵｓｅｒＢ、ＵｓｅｒＣに対して、図８のステップ１２８で問合せメッセージを送信している。本実施の形態では別の方法として、事前にＵｓｅｒＡ、ＵｓｅｒＢ、ＵｓｅｒＣが２１２、２１３、２１４の様に各ユーザのプライベートな関係情報を関係情報・共有可否情報管理サーバ１６の内部に通知しておき、関係情報・共有可否情報管理サーバ１６は内部に保存された情報を検索するパターンも考えられる。
図１６は、第１の実施の形態のプライベートの関係情報の共有イメージ図である。
上述の例では、図１６の２１７、２１８、２１９の様に各ユーザがプライベートな関係情報を保持する。関係情報・共有可否情報管理サーバ１６は、２１１の様に保存されたテーブル１４４、１４１の情報から共有可能な他ユーザを判断し、プライベートな情報から仲介人物検索を行うためにＵｓｅｒＢ、ＵｓｅｒＣに対して、図８のステップ１２８で問合せメッセージを送信している。本実施の形態では別の方法として、事前にＵｓｅｒＡ、ＵｓｅｒＢ、ＵｓｅｒＣが２１２、２１３、２１４の様に各ユーザのプライベートな関係情報を関係情報・共有可否情報管理サーバ１６の内部に通知しておき、関係情報・共有可否情報管理サーバ１６は内部に保存された情報を検索するパターンも考えられる。
２１７、２１８、２１９の様に各ユーザが自分でプライベートな関係情報を保持する場合、プライベートな関係情報を各ユーザの所有する情報端末内部で管理するので、物理的にセキュリティを確保できる。一方、２１２、２１３、２１４の様にサーバ１６でプライベートな関係情報を保存する場合、物理的なセキュリティは確保できないが、共有可否情報２１１（共有判断情報テーブル１４４）によりアクセス制御を行う事で論理的なセキュリティを確保する事が可能である。また、サーバ１６側で保存した場合、図８のステップ１２８、１２９に示すシーケンスを省略する事ができ、通信コストを削減する事が可能となる。サーバ１６でプライベートな関係情報を保持する場合、各端末４１〜４３は、自身が持つ関係情報をサーバ１６に登録する必要がある。本実施の形態ではそのタイミングについては特には問わないが、例えば、各端末４１〜４３が関係情報を算出する度にサーバ１６に対して新たに算出した内容を登録する方法が考えられる。
１−２．第２の動作パターン
図１３は、図８に示すシーケンス図の１３４で囲んだ部分についての２つ目の動作パターンのシーケンス図である。このシーケンスは図８の例と比較してステップ１２５〜１２９の動作は同様である。上述の例では、図８のステップ１３０で関係情報・共有可否情報管理サーバ１６がＵｓｅｒＣに対して仲介要求メッセージを送信していたが、本例では、まず一旦ステップ１８２で関係情報・共有可否情報管理サーバ１６がＵｓｅｒＡに対して検索の結果得られた仲介人物を通知する。その後、ステップ１８３でＵｓｅｒＡが直接ＵｓｅｒＣに対して仲介要求を送信する。図８のパターンでは仲介要求時、ＵｓｅｒＡに対して仲介人物であるＵｓｅｒＣ、ＵｓｅｒＤのＩＤ、及び目的人物であるＵｓｅｒＥのＩＤをＵｓｅｒＡに送信する必要が無かったため、ＩＤを隠したままでのシーケンス実行が可能であった。しかし、本シーケンスパターンでは、ＵｓｅｒＡがＵｓｅｒＣにステップ１８２で直接仲介依頼するので、ＵｓｅｒＡは少なくとも第１仲介人物であるＵｓｅｒＣのＩＤは知っている必要がある。関係情報・共有可否情報管理サーバ１６は、ステップ１８２において、ＵｓｅｒＣのＩＤをＵｓｅｒＡに通知してもよい。一方、第２仲介人物であるＵｓｅｒＤ、及び目的人物であるＵｓｅｒＥのＩＤは、図２５に示す方法を用いる事で通知しないでシーケンスを実行する事が可能となる。以下、図２５の動作について順を追って説明する。
図１３は、図８に示すシーケンス図の１３４で囲んだ部分についての２つ目の動作パターンのシーケンス図である。このシーケンスは図８の例と比較してステップ１２５〜１２９の動作は同様である。上述の例では、図８のステップ１３０で関係情報・共有可否情報管理サーバ１６がＵｓｅｒＣに対して仲介要求メッセージを送信していたが、本例では、まず一旦ステップ１８２で関係情報・共有可否情報管理サーバ１６がＵｓｅｒＡに対して検索の結果得られた仲介人物を通知する。その後、ステップ１８３でＵｓｅｒＡが直接ＵｓｅｒＣに対して仲介要求を送信する。図８のパターンでは仲介要求時、ＵｓｅｒＡに対して仲介人物であるＵｓｅｒＣ、ＵｓｅｒＤのＩＤ、及び目的人物であるＵｓｅｒＥのＩＤをＵｓｅｒＡに送信する必要が無かったため、ＩＤを隠したままでのシーケンス実行が可能であった。しかし、本シーケンスパターンでは、ＵｓｅｒＡがＵｓｅｒＣにステップ１８２で直接仲介依頼するので、ＵｓｅｒＡは少なくとも第１仲介人物であるＵｓｅｒＣのＩＤは知っている必要がある。関係情報・共有可否情報管理サーバ１６は、ステップ１８２において、ＵｓｅｒＣのＩＤをＵｓｅｒＡに通知してもよい。一方、第２仲介人物であるＵｓｅｒＤ、及び目的人物であるＵｓｅｒＥのＩＤは、図２５に示す方法を用いる事で通知しないでシーケンスを実行する事が可能となる。以下、図２５の動作について順を追って説明する。
図２５は、本動作パターンの仲介形式の説明図である。図２６は、仲介ＩＤテーブルの構成例である。
図２５では、まず、関係情報・共有可否情報管理サーバ１６が仲介人物の候補を算出すると、図１３のステップ１８１でこれら仲介経路に対してサーバ内部で一意の仲介ＩＤを割り振り、図２６の３３１に示すテーブルの内部でレコード３３６のような形式でその情報を保持する。図２６の３３２が一意の仲介ＩＤであり、３３３、３３４、３３５は仲介経路である。３３３〜３３５については仲介経路上の人物の人数に応じてフィールドの数が変化する。例えば仲介者が３人いる場合、本例では省略しているが３３５の右隣りには”第３仲介者”を記述するためのフィールドが用意されており、そのフィールドに第３仲介者のＩＤを記入する。レコード３３６の例では、仲介元としてＵｓｅｒＡのＩＤが記憶され、仲介者としてＵｓｅｒＣ、ＵｓｅｒＤのＩＤが記憶され、また、目的人物としてＵｓｅｒＥのＩＤが記憶される。なお、これらの各情報は、ステップ１２７で受信される情報や、パブリックな関係情報、ＵｓｅｒＢ、Ｃからの問い合わせに対する返信の情報を用いることができる。
図２５では、まず、関係情報・共有可否情報管理サーバ１６が仲介人物の候補を算出すると、図１３のステップ１８１でこれら仲介経路に対してサーバ内部で一意の仲介ＩＤを割り振り、図２６の３３１に示すテーブルの内部でレコード３３６のような形式でその情報を保持する。図２６の３３２が一意の仲介ＩＤであり、３３３、３３４、３３５は仲介経路である。３３３〜３３５については仲介経路上の人物の人数に応じてフィールドの数が変化する。例えば仲介者が３人いる場合、本例では省略しているが３３５の右隣りには”第３仲介者”を記述するためのフィールドが用意されており、そのフィールドに第３仲介者のＩＤを記入する。レコード３３６の例では、仲介元としてＵｓｅｒＡのＩＤが記憶され、仲介者としてＵｓｅｒＣ、ＵｓｅｒＤのＩＤが記憶され、また、目的人物としてＵｓｅｒＥのＩＤが記憶される。なお、これらの各情報は、ステップ１２７で受信される情報や、パブリックな関係情報、ＵｓｅｒＢ、Ｃからの問い合わせに対する返信の情報を用いることができる。
次に、関係情報・共有可否情報管理サーバ１６は、１１に示すＵｓｅｒＡに対してステップ３１１で仲介人物の候補（ここでは、例えばＵｓｅｒＣ）、目的人物を通知する。本動作は図１３のシーケンス図のステップ１８２に相当する。図２５の３１９はこのステップで送信される情報である。この情報には仲介者の候補であるＵｓｅｒＣ、ＵｓｅｒＨのＩＤ、及び各仲介人物を仲介する場合の仲介ＩＤが記述されている。ＵｓｅｒＡはこれら候補の内、誰に依頼を出すかを選択して仲介依頼を送信する。この様に図１３のシーケンスパターンでは、複数の仲介人物候補が見つかった場合、ＵｓｅｒＡが実際に誰に対して仲介を依頼するかを自分で選択できるメリットがある。本例ではＵｓｅｒＡはＵｓｅｒＣを選択した事とする。
そこでＵｓｅｒＡはステップ３１２でＵｓｅｒＣに対して仲介依頼を送信する。本ステップは図１３のシーケンス図のステップ１８２に相当する。図２５の３２０はこのステップで送信される情報である。この情報には３１９に示した情報の中の仲介ＩＤ情報が付与されている。ステップ３１２で仲介依頼を受信した３に示すＵｓｅｒＢはステップ３１３で受信した仲介ＩＤ情報から仲介経路を特定するために、関係情報・共有可否情報管理サーバ１６に対して仲介ＩＤを送信する。本ステップは図１３のステップ１８４の動作に相当する。
そこでＵｓｅｒＡはステップ３１２でＵｓｅｒＣに対して仲介依頼を送信する。本ステップは図１３のシーケンス図のステップ１８２に相当する。図２５の３２０はこのステップで送信される情報である。この情報には３１９に示した情報の中の仲介ＩＤ情報が付与されている。ステップ３１２で仲介依頼を受信した３に示すＵｓｅｒＢはステップ３１３で受信した仲介ＩＤ情報から仲介経路を特定するために、関係情報・共有可否情報管理サーバ１６に対して仲介ＩＤを送信する。本ステップは図１３のステップ１８４の動作に相当する。
関係情報・共有可否情報管理サーバ１６は、図２６の３３１に示すテーブルを検索し、受信した仲介ＩＤから仲介経路を確認する。本例ではレコード３３６の仲介ＩＤフィールド３３２の値が受信した仲介ＩＤと一致することが確認できる。関係情報・共有可否情報管理サーバ１６は、仲介依頼の送信元がＵｓｅｒＡ、仲介経路を要求するユーザがＵｓｅｒＣである事を確認し、レコード３３６からＵｓｅｒＣが次に取り次ぐユーザ名とＩＤをステップ３１４でＵｓｅｒＣに返信する。本動作は図１３のステップ１８５に相当する。本例ではＵｓｅｒＣが取り次ぐ仲介人物はフィールド３３５に記述されたｓｉｐ：ＵｓｅｒＤ＠ａｂｃ．ｃｏｍのＩＤを持つＵｓｅｒＤであるので、その事を３２１の様に記述してＵｓｅｒＣに返信する。
その後、ＵｓｅｒＣは、ステップ３１５（図１３のステップ１３１）の様に次の仲介人物ＵｓｅｒＤに仲介依頼を送信する。ＵｓｅｒＤは、上述のＵｓｅｒＣの場合と同様に、関係情報・共有可否情報管理サーバ１６にステップ３１６（図１３のステップ１８６）で仲介経路を問合せ、ステップ３１７（図１３のステップ１８７）で３２２に示す様な情報を受信する。ＵｓｅｒＤは、最終的にステップ３１８（図８のステップ１３２）でＵｓｅｒＥに対して情報提供依頼を行う。ステップ３１５〜３１７についてはステップ３１２、３１３、３１４と同様である。ただし、３２２にはＵｓｅｒＤが次に取り次ぐユーザは仲介人物ではなく、目的人物であるので、その事が記述されており、ＵｓｅｒＤはその情報を確認して次の取り次ぎ先には仲介依頼ではなく、情報提供依頼を行う。
その後、ＵｓｅｒＣは、ステップ３１５（図１３のステップ１３１）の様に次の仲介人物ＵｓｅｒＤに仲介依頼を送信する。ＵｓｅｒＤは、上述のＵｓｅｒＣの場合と同様に、関係情報・共有可否情報管理サーバ１６にステップ３１６（図１３のステップ１８６）で仲介経路を問合せ、ステップ３１７（図１３のステップ１８７）で３２２に示す様な情報を受信する。ＵｓｅｒＤは、最終的にステップ３１８（図８のステップ１３２）でＵｓｅｒＥに対して情報提供依頼を行う。ステップ３１５〜３１７についてはステップ３１２、３１３、３１４と同様である。ただし、３２２にはＵｓｅｒＤが次に取り次ぐユーザは仲介人物ではなく、目的人物であるので、その事が記述されており、ＵｓｅｒＤはその情報を確認して次の取り次ぎ先には仲介依頼ではなく、情報提供依頼を行う。
尚、上記の例では仲介ＩＤを利用して仲介作業を実現したが、仲介ＩＤを利用しなかった場合、図１３のステップ１８１、１８４、１８５、１８６、１８７、及び図２５の３１３、３１４、３１６、３１７のシーケンスは発生しない。
この様な仲介希望者が直接仲介依頼を出すシーケンスパターンでは、上記の仲介人物を選択できるメリットに加えて、仲介依頼時に目的の詳細を直接仲介人物に伝える事ができるメリットもある。
また、本例では、仲介希望者Ａに対して直接依頼する人物Ｃ以外の仲介人物Ｄと目的人物ＥのＩＤを通知しない方法について説明したが、セキュリティレベルを考え、公開しても問題ない場合、例えば図２５の３１９や３２０に仲介人物のＩＤ、目的人物のＩＤを付与して送信しても構わない。ＩＤを付与した場合、図２５のステップ３１３、３１４、３１６、３１７の様に関係情報・共有可否情報管理サーバ１６に対して仲介経路を問い合わせる必要は無くなる。
この様な仲介希望者が直接仲介依頼を出すシーケンスパターンでは、上記の仲介人物を選択できるメリットに加えて、仲介依頼時に目的の詳細を直接仲介人物に伝える事ができるメリットもある。
また、本例では、仲介希望者Ａに対して直接依頼する人物Ｃ以外の仲介人物Ｄと目的人物ＥのＩＤを通知しない方法について説明したが、セキュリティレベルを考え、公開しても問題ない場合、例えば図２５の３１９や３２０に仲介人物のＩＤ、目的人物のＩＤを付与して送信しても構わない。ＩＤを付与した場合、図２５のステップ３１３、３１４、３１６、３１７の様に関係情報・共有可否情報管理サーバ１６に対して仲介経路を問い合わせる必要は無くなる。
さらに、上記の様に目的人物ＥのＩＤまでを仲介希望者Ａに公開すべきでない場合も存在する。例えば、仲介人物Ｃ、Ｄが目的人物への仲介を行う際、目的人物がプライベートで所有する携帯電話に電話をするような場合は仲介希望者に対して目的人物のＩＤである携帯電話の電話番号までを公開すべきではない。この様な場合、仲介希望者に対して、目的人物のＩＤを公開するのではなく、目的人物の氏名など、秘匿性の低い情報のみを公開することも可能である。関係情報・共有可否情報管理サーバ１６がパブリックな関係情報に加えて、図１１のテーブル１６７の様に、ユーザＩＤフィールド１６８とユーザの氏名のような公開名を記述するフィールド１６９の組み合わせを保持し、目的人物と判断されたユーザのＩＤからフィールド１６９の情報を検索し、その情報だけを仲介希望者に通知する。テーブル１６７の情報は、一例として、会社が保持する社員情報データベースから取得し、事前にテーブル作成しておく事で構築する方法が考えられる。この様な動作を行う事で、仲介希望者には目的人物の名前だけを通知し、実際のＩＤは通知せずに済む。仲介希望者は目的人物の名前からどのような人物かを判別できる場合もあり、関係情報・共有可否情報管理サーバ１６から複数の目的人物が提示された場合、誰に対して情報提供を依頼するかを判断する材料にする事が可能となる。
１−３．第３の動作パターン
図１４は、図８に示すシーケンス図の１３４で囲んだ部分についての３つ目の動作パターンのシーケンス図である。このシーケンスは図８の例と比較してステップ１２５〜１２７の動作は同様である。ステップ１９３でパブリックな関係情報から仲介経路候補を検索した後、ステップ１９４でその結果をＵｓｅｒＡに返信している。図８のステップ１２８、１２９で行っているプライベートな関係情報からの仲介人物絞込みはＵｓｅｒＡがステップ１９５、１９７で行う。その後のステップ１８３の仲介要求送信は図１３と同じであり、ステップ１３１の仲介依頼は図８と同じ動きとなる。
図１４は、図８に示すシーケンス図の１３４で囲んだ部分についての３つ目の動作パターンのシーケンス図である。このシーケンスは図８の例と比較してステップ１２５〜１２７の動作は同様である。ステップ１９３でパブリックな関係情報から仲介経路候補を検索した後、ステップ１９４でその結果をＵｓｅｒＡに返信している。図８のステップ１２８、１２９で行っているプライベートな関係情報からの仲介人物絞込みはＵｓｅｒＡがステップ１９５、１９７で行う。その後のステップ１８３の仲介要求送信は図１３と同じであり、ステップ１３１の仲介依頼は図８と同じ動きとなる。
図１４の様に、ＵｓｅｒＡが直接他ユーザに対してプライベートな関係情報の問合せを行う場合、共有可否の判断は図９のテーブル１４１に示す様な関係情報・共有可否情報管理サーバ１６上のデータベースで判断するのではなく、ＵｓｅｒＡは自分自身で現在誰と関係情報を共有しているかを判断できる。これはＵｓｅｒＡに対して仲介ユーザや目的ユーザのＩＤは公開されるが、ＵｓｅｒＡが自分の判断で関係情報の問い合わせ先を選択する、目的人物を選択することが可能となり、ＵｓｅｒＡにとってのユーザビリティは向上する。また、本例でも関係情報の問合せ先ユーザ（本例ではＵｓｅｒＢ、ＵｓｅｒＣ）はＵｓｅｒＡに対して自分と他人との関係情報を公開するかを判断できるので、ＵｓｅｒＢ、ＵｓｅｒＣが持つ関係情報はアクセスコントロール可能である。
本例ではＵｓｅｒＡは自分が、現在どの電子会議室に入室しているかを管理しており、さらに現在入室中の電子会議室の他メンバも把握している。ＵｓｅｒＡは自分自身が保持するこれら情報から共有相手を判断して、その結果、ステップ１９５でＵｓｅｒＢ、ＵｓｅｒＣに対して問合せを行っている。また、ＵｓｅｒＢ、ＵｓｅｒＣも同様、ＵｓｅｒＡが同一会議室に参加している事を自分で把握している。ＵｓｅｒＢ、ＵｓｅｒＣはＵｓｅｒＡからの問合せに対してステップ１９６で共有可否を判断し、共有可能な場合、ステップ１９７で返信している。本シーケンスパターンでは、ＵｓｅｒＡは自分でプライベートな関係情報の問合せ先を選択する事が可能である。例えば、各ユーザが自分の頭の中で持っている友人、飲み友達の情報等、各ユーザの電子会議室への入退室情報の様な関係情報・共有可否情報管理サーバ１６のデータベース上で管理できない情報や実際に仲介してくれるかどうか、仲介能力があるかどうか等、データベース上では表せない様々な情報を基にプライベートな関係情報問合せ先を選択できる。
１−４．第４の動作パターン
図１５は、図８に示すシーケンス図の１３４で囲んだ部分についての４つ目の動作パターンのシーケンス図である。このシーケンスは図８の例と比較してステップ１２５〜１２９の動作は同様である。図８のシーケンスでは、仲介依頼をＵｓｅｒＣに対して送信するのに対し、ステップ２０１では、多人数会議制御サーバ２１に対して送信する。多人数会議制御サーバ２１は、ステップ２０２で１１に示すＵｓｅｒＥに会議室への参加要望を送信している。本パターンにより仲介者であるＵｓｅｒＣが実際に仲介する負担を減らすことが可能となる。また、仲介依頼作業、仲介作業はサーバ１６が代行して行うので、問い合わせユーザや仲介者に他ユーザのＩＤを通知せずに仲介作業を行うことが可能である。なお、図８のステップ１３２は省略できる。本シーケンスと他のシーケンスとの違いを図１７を用いて説明する。
図１５は、図８に示すシーケンス図の１３４で囲んだ部分についての４つ目の動作パターンのシーケンス図である。このシーケンスは図８の例と比較してステップ１２５〜１２９の動作は同様である。図８のシーケンスでは、仲介依頼をＵｓｅｒＣに対して送信するのに対し、ステップ２０１では、多人数会議制御サーバ２１に対して送信する。多人数会議制御サーバ２１は、ステップ２０２で１１に示すＵｓｅｒＥに会議室への参加要望を送信している。本パターンにより仲介者であるＵｓｅｒＣが実際に仲介する負担を減らすことが可能となる。また、仲介依頼作業、仲介作業はサーバ１６が代行して行うので、問い合わせユーザや仲介者に他ユーザのＩＤを通知せずに仲介作業を行うことが可能である。なお、図８のステップ１３２は省略できる。本シーケンスと他のシーケンスとの違いを図１７を用いて説明する。
図１７は、本動作パターンの仲介イメージ図である。
図１７のステップ２２１、２２２、２２７に示す動作の流れが図１５以外のシーケンスでの仲介実現方法である。ステップ２２１では１に示すＵｓｅｒＡ、もしくは関係情報・共有可否情報管理サーバ１６が、３に示すＵｓｅｒＣに仲介依頼を送信する。この動作は図８のステップ１３０、図１３のステップ１８３に相当する。ＵｓｅｒＣはそれを基に、ステップ２２２で１８に示すＵｓｅｒＤに仲介依頼を送信し、ＵｓｅｒＤはステップ２２７でＵｓｅｒＥに対して情報提供依頼を送信する。これら動作は図８のステップ１３１、１３２に相当する。
図１７のステップ２２１、２２２、２２７に示す動作の流れが図１５以外のシーケンスでの仲介実現方法である。ステップ２２１では１に示すＵｓｅｒＡ、もしくは関係情報・共有可否情報管理サーバ１６が、３に示すＵｓｅｒＣに仲介依頼を送信する。この動作は図８のステップ１３０、図１３のステップ１８３に相当する。ＵｓｅｒＣはそれを基に、ステップ２２２で１８に示すＵｓｅｒＤに仲介依頼を送信し、ＵｓｅｒＤはステップ２２７でＵｓｅｒＥに対して情報提供依頼を送信する。これら動作は図８のステップ１３１、１３２に相当する。
図１５に示すシーケンスでは、関係情報・共有可否情報管理サーバ１６はＵｓｅｒＣではなく、電子会議室へのユーザ入退室を管理する多人数会議制御サーバ１６、もしくは通信セッションを管理するＳＩＰサーバ４７に、ステップ２２３で自動での仲介依頼を送信する（図１５のステップ２０１）。これらサーバは、その情報を受信するとステップ２２４の様にＵｓｅｒＥに対して情報提供の依頼と電子会議室への参加要請を送信する（図１５のステップ２０２）。２２５は、その内容の一例である。２２５では情報提供を希望するユーザはＵｓｅｒＡ、仲介人物はＵｓｅｒＣ、ＵｓｅｒＤである事と、必要とする情報と、情報提供を行うために電子会議室Ａに参加して欲しい事が記述されている。１１に示すＵｓｅｒＥはこのメッセージを受信し、自分が所有する情報端末４４を利用してステップ２２６の様に会議室に参加して情報を提供する。この時、多人数会議制御サーバ１６やＳＩＰサーバ４７はＳＩＰの制御メッセージを用いて通信セッションを制御して、ＵｓｅｒＥが情報提供を許可した場合、自動的に電子会議室Ａに参加できるように通信を制御する。
２．第２の実施の形態
図１８は、図３の例における図８に示すシーケンス図の１３５で囲んだ部分について、異なる手段で共有可否情報を収集した場合の概念図である。
本システムは、関係情報・共有可否情報管理サーバ１６と、Ｋｎｏｗ−Ｗｈｏ検索サーバ２２と、受信機２３１と、プレゼンスサーバ２３２と、各ユーザが所持するＲＦＩＤ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）タグ２４２〜２４４とを備える。
図３の例では、関係情報・共有可否情報管理サーバ１６は、電子会議室への入退室情報を基に、各ユーザ間のプライベートな関係情報の共有可否を判断していた。本実施の形態（図１８の例）では、各ユーザは電子的な会議室でチャットを用いて議論するのではなく、本当の会議室（例えば第２会議室２３３）に集合して直接面と向かって議論を行っている。また、会議室にはその会議室に現在どのユーザが入室しているかを把握するために例えば、ＲＦＩＤの様な無線信号を感知する受信機２３１が設置されている。この受信機２３１で受信した情報はプレゼンスサーバ２３２へ送信され、各ユーザのプレゼンス情報として取り扱われる。本例では入退室を把握するための方法としてＲＦＩＤによる各ユーザの現在位置把握を例として挙げているが、本実施の形態ではその方法については他のものでも構わない。例えば、各ユーザが位置情報を端末等から入力して、プレゼンスサーバ２３２がこれを管理してもよい。
図１８は、図３の例における図８に示すシーケンス図の１３５で囲んだ部分について、異なる手段で共有可否情報を収集した場合の概念図である。
本システムは、関係情報・共有可否情報管理サーバ１６と、Ｋｎｏｗ−Ｗｈｏ検索サーバ２２と、受信機２３１と、プレゼンスサーバ２３２と、各ユーザが所持するＲＦＩＤ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）タグ２４２〜２４４とを備える。
図３の例では、関係情報・共有可否情報管理サーバ１６は、電子会議室への入退室情報を基に、各ユーザ間のプライベートな関係情報の共有可否を判断していた。本実施の形態（図１８の例）では、各ユーザは電子的な会議室でチャットを用いて議論するのではなく、本当の会議室（例えば第２会議室２３３）に集合して直接面と向かって議論を行っている。また、会議室にはその会議室に現在どのユーザが入室しているかを把握するために例えば、ＲＦＩＤの様な無線信号を感知する受信機２３１が設置されている。この受信機２３１で受信した情報はプレゼンスサーバ２３２へ送信され、各ユーザのプレゼンス情報として取り扱われる。本例では入退室を把握するための方法としてＲＦＩＤによる各ユーザの現在位置把握を例として挙げているが、本実施の形態ではその方法については他のものでも構わない。例えば、各ユーザが位置情報を端末等から入力して、プレゼンスサーバ２３２がこれを管理してもよい。
また、”プレゼンス情報”とはその名の如く、各ユーザの”存在”を他ユーザに通知するための情報であり、具体的には各ユーザの現在位置や現在状態、その他様々な自分の存在を示す情報である。この”プレゼンス”を他のユーザに対してリアルタイムに通知することでお互いの現在状態を把握することが可能となる。これらプレゼンスの概念と通信技術はＩＭ（Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ）技術から発展した。ＩＭ、及びプレゼンスの概念についてはＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のｉｍｐｐ（Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ）ワーキンググループを中心に標準化が行われている。ｉｍｐｐワーキンググループで標準化された内容は、例えばＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ）２７７８、２７７９に記述されている。また、具体的なプレゼンス通信技術についてはｉｍｐｐで規定された概念を基に、様々なＩＥＴＦのワーキンググループで議論、標準化が行われている。本例ではＲＦＩＤで取得した情報をプレゼンス情報として取り扱い、プレゼンスサーバ２３２に保存する。関係情報・共有可否情報管理サーバ１６はこのプレゼンス情報を基にして各ユーザのプライベートな関係情報の共有可否を判断する。なお、ＲＦＩＤによる電波送受信以外の手段で各ユーザのプレゼンス情報を取得して、それを利用する事も可能である。また、現在の忙しさの状態や気分等、位置情報以外のプレゼンス情報を共有可否情報として利用する事も可能である。
図１９は、本システムのネットワーク構成図である。第２会議室２３３に設置されたＲＦＩＤの受信機２３１、プレゼンスサーバ２３２、関係情報・共有可否情報管理サーバ１６、Ｋｎｏｗ−Ｗｈｏ検索サーバ２２、ＵｓｅｒＡ、ＵｓｅｒＤ、ＵｓｅｒＥがそれぞれ所有する情報端末２４１、２４５、２４６はＩＰネットワーク２４７に接続されている。但し、ＵｓｅｒＤ、ＵｓｅｒＥは必ず情報端末を所有している必要があるわけではなく所有している場合、それをＩＰネットワーク２４７に接続している。また、端末２４１は、ＵｓｅｒＡが所有する以外にも、ＵｓｅｒＢ、Ｃ所有のものであってもよいし、会議室に備えられた端末を用いてもよい。関係情報・共有可否情報管理サーバ１６は、上述の第１の実施の形態と同様、例えば図１０に示すようなパブリックな関係情報テーブル１６１、１６７を有している。また、各ユーザは、プライベートな関係情報を有しており、例えば、各ユーザの端末に記憶されていてもよいし、関係情報・共有可否情報管理サーバ１６に予め記憶されも良い。
図２０は、図８の１３５、１３６で囲んだ部分のシーケンス図である。このシーケンスは、例えば、図１８の例に合わせたものである。この部分以降のシーケンスについては、例えば、図１３のステップ１８３以降、又は、図１４のステップ１９５以降と同様とすることができる。
図２０では、ＵｓｅｒＡが所有するＲＦＩＤタグＡ２４２は、受信器２３１が発信する電波をユーザの第２会議室２３３への入室時に受信し、そのレスポンスをステップ２５１で受信機２３１に送信する。レスポンスは、例えば、ＲＦＩＤタグのＩＤを含む。受信機２３１は、レスポンスを受信し、ＲＦＩＤタグのＩＤと、自らの識別情報をステップ２５２でプレゼンスサーバ２３２に送信する。
図２０では、ＵｓｅｒＡが所有するＲＦＩＤタグＡ２４２は、受信器２３１が発信する電波をユーザの第２会議室２３３への入室時に受信し、そのレスポンスをステップ２５１で受信機２３１に送信する。レスポンスは、例えば、ＲＦＩＤタグのＩＤを含む。受信機２３１は、レスポンスを受信し、ＲＦＩＤタグのＩＤと、自らの識別情報をステップ２５２でプレゼンスサーバ２３２に送信する。
プレゼンスサーバ２３２では、図２１の２７１に示す様なテーブルでユーザのプレゼンス情報を管理している。テーブル２７１は、例えば、ユーザのＩＤと、ユーザが所持するＲＦＩＤタグのＩＤとが対応して予め記憶されている。本例では、受信機２３１から送信された情報の識別子はＲＦＩＤタグＡが持つＩＤの０００１である。よって、テーブル２７１のフィールド２７３のＲＦＩＤのＩＤ“０００１”に対応する第１番目のレコードの現在位置フィールド２７３の記述が受信機２３２の設置位置に更新される。結果としてユーザＩＤが”ｓｉｐ：ＵｓｅｒＡ＠ａｂｃ．ｃｏｍ”のレコードが更新され、ＵｓｅｒＡのプレゼンス情報が更新される。本例ではこの様にプレゼンスサーバ２３２が各ＲＦＩＤのＩＤとユーザＩＤの対応をテーブルで管理しており、ステップ２５３でＲＦＩＤの信号受信機が受信した情報をユーザＩＤと対応付けてユーザのプレゼンスを更新する。但し、この機能については必ずプレゼンスサーバ２３２が持っている必要は無く、物理的に異なるサーバ、もしくは物理的には同一サーバ内であるが、別なソフトウェアが本機能を実現しても構わない。プレゼンスサーバ２３２はこれらプレゼンス情報をさらにステップ２５４で関係情報・共有可否情報管理サーバ１６に送信する。結果、関係情報・共有可否情報管理サーバ１６はテーブル２７１と同じ情報をサーバ内部に保存する。なお、ＵｓｅｒＡが第２会議室２３３から退席すると、例えば他の場所の受信機が上述と同様の動作をすることによりプレゼンス情報が更新される。ＵｓｅｒＢ、ＵｓｅｒＣについての処理２５５〜２６２についても、上述のステップ２５１〜２５４と同様である。
また、関係情報・共有可否情報管理サーバ１６は、図２２のテーブル２８１の様な情報を、共有レベルを管理するテンプレートとして保持する。このテーブル２８１は、図３の例での図１２のテーブル１７１と同様の役割を持つ。テーブル２８１の見方を説明する。例えばレコード２８７の様にプレゼンス項目１フィールド２８３に「現在位置」、プレゼンス値１フィールド２８４に「第２会議室」が予め記述されている。また、プレゼンス項目２フィールド２８５には「所属」、プレゼンス値２フィールド２８６には「○○事業部」が予め記述されている。さらに共有レベルフィールド２８２には「３」が記述されている。これは、図２１のテーブル２７１の現在位置フィールド２７４の内容が「第２会議室」で、さらに所属フィールド２７６が「○○事業部」でマッチングしているユーザ間の共有レベルが３であることを示している。
本例ではｓｉｐ：ＵｓｅｒＡ＠ａｂｃ．ｃｏｍのＩＤで示されるＵｓｅｒＡとｓｉｐ：ＵｓｅｒＣ＠ａｂｃ．ｃｏｍで示されるＵｓｅｒＣが本条件にマッチしており、共有レベルが３である。またテーブル２８１のレコード２８８を同様に見ると、「現在位置」が「第２会議室」でマッチングしているユーザ同士は共有レベルが２である事が分かる。本例ではＵｓｅｒＡとｓｉｐ：ＵｓｅｒＢ＠ａｂｃ．ｃｏｍのＩＤで示されるＵｓｅｒＢ、ＵｓｅｒＢとＵｓｅｒＣの間の共有レベルが２である。共有レベルとプライベートな関係情報の公開範囲との関係ついては第１の実施の形態と同様である。例えば、本例では、ＵｓｅｒＡからの目的人物Ｅへの仲介経路を算出するために、ＵｓｅｒＢについては公開レベルが２以下のプライベートな関係情報と、ＵｓｅｒＣについては公開レベルが３以下のプライベートな関係情報とを用いる。
この様にプレゼンス情報のマッチングを条件に共有レベルを判断することで、複数あるプレゼンス項目から様々なマッチングパターンを生成して、共有レベルを細かく制御させる事が可能となる。テーブル２８１でのマッチング処理による共有レベル判定動作は、本例ではステップ２６７で行われる。この動作は図８で示した例でのステップ１２８の前に行っている、図６の共有判断部７４の共有判定部８８による共有可否判断作業に相当する。
この様にプレゼンス情報のマッチングを条件に共有レベルを判断することで、複数あるプレゼンス項目から様々なマッチングパターンを生成して、共有レベルを細かく制御させる事が可能となる。テーブル２８１でのマッチング処理による共有レベル判定動作は、本例ではステップ２６７で行われる。この動作は図８で示した例でのステップ１２８の前に行っている、図６の共有判断部７４の共有判定部８８による共有可否判断作業に相当する。
また、ステップ２６３から２６９までのシーケンスで示すＫｎｏｗ−Ｗｈｏ検索から仲介までの動作は、例えば、図８の様に関係情報・共有可否情報管理サーバ１６が仲介者経路の有無を各ユーザに直接問い合わせて、仲介経路を算出した後、仲介依頼も含めて代理で行うパターン、図１３の様に仲介経路の有無を各ユーザに問い合わせて仲介経路の算出までサーバが行い、その結果を問い合わせユーザに返信し、仲介依頼作業は各ユーザが行うパターン、図１４の様にサーバは目的人物の候補とサーバ内部で保持する関係情報からの仲介経路候補までのみを算出し、その結果を問い合わせユーザに返信、問い合わせユーザが仲介経路の有無を他ユーザに対して問い合わせて仲介作業まで行うパターン、図１５の様に仲介の作業を各ユーザに依頼せずに自動的に仲介を行うパターン等多数のパターンのいずれかを取ることができる。
しかし、図１８の例の場合、図８等で示したようなＵｓｅｒＣに対して関係情報・共有可否情報管理サーバ１６が仲介依頼を送信するシーケンスパターンを利用する事は出来ない場合もある。なぜなら第２会議室２３３での会議中、ＵｓｅｒＣが自らの端末を手元に所有していない可能性があるからである。その場合は、図１３のパターンでのステップ１８３の様にＵｓｅｒＡが直接ＵｓｅｒＣに対して仲介依頼を行う。この場合は、電子的なメッセージの送受信で仲介依頼を出すのではなく、口頭で直接仲介依頼を出す形になる。また、プライベートな関係情報は、図１６のように予めサーバに記憶しておく。さらに、この様に口頭で仲介依頼を出す場合、図２５の様に仲介ＩＤを用いて目的人物をＵｓｅｒＡに公開しないで仲介を行う事は出来ない。理由は先ほどと同様で、ＵｓｅｒＣが手元に情報端末を所有していないと、仲介ＩＤを伝えてもＩＰネットワーク経由で関係情報・共有可否情報管理サーバ１６に次に取り次ぐユーザを問い合わせる事が出来ないからである。
また、図１６の２１７、２１８、２１９の様に各ユーザがプライベートな関係情報を自分の端末で保持して、ＵｓｅｒＡが図１４のステップ１９５の様に各ユーザに直接プライベートな関係情報の問合せを行うことが出来ない場合がある。この理由も上記と同様で、ＵｓｅｒＢ、ＵｓｅｒＣが情報端末を所有していない可能性、所有していてもＩＰネットワーク２４６に接続していない可能性、電源を入れていない可能性が考えられるからである。この様な場合、プライベートな関係情報は図１６の２１２、２１３、２１４の様にサーバ側で管理し、アクセスコントロールする形でプライベートな関係情報の問合せを実現させる。
また、図１５のように、自動的に仲介を行うパターンでは、例えば関係情報・共有可否情報管理サーバ１６がＵｓｅｒＥに仲介依頼を送信することができる。
上述の第１及び第２の実施の形態において、仲介依頼、情報提供依頼は、端末間で通信する以外にも、ユーザ間で直接行うこともできる。この場合、端末は、例えば検索され、受信された仲介経路に関する情報を表示部に表示し、ユーザが表示部の表示に従い仲介することも可能である。また、第１の実施の形態において、各動作パターンを適宜組み合わせてもよい。
また、図１５のように、自動的に仲介を行うパターンでは、例えば関係情報・共有可否情報管理サーバ１６がＵｓｅｒＥに仲介依頼を送信することができる。
上述の第１及び第２の実施の形態において、仲介依頼、情報提供依頼は、端末間で通信する以外にも、ユーザ間で直接行うこともできる。この場合、端末は、例えば検索され、受信された仲介経路に関する情報を表示部に表示し、ユーザが表示部の表示に従い仲介することも可能である。また、第１の実施の形態において、各動作パターンを適宜組み合わせてもよい。
本発明は、例えば、Ｋｎｏｗ−Ｗｈｏシステムに利用可能である。また、情報の開示を制御するシステムに利用可能である。
１ ＵｓｅｒＡ
２ ＵｓｅｒＢ
３ ＵｓｅｒＣ
１１ ＵｓｅｒＥ
１６ 関係情報・共有可否情報管理サーバ
１８ ＵｓｅｒＤ
２１ 多人数会議制御サーバ
２２ Ｋｎｏｗ−Ｗｈｏ検索サーバ
４１、４２、４３、４４、４８、５１ 情報端末
４６ ＩＰネットワーク
４７ ＳＩＰサーバ
５２ コミュニケーション制御部
５３ 情報送受信制御部
５４ Ｋｎｏｗ−Ｗｈｏ検索部
５５ 人間関係管理部
７２ 仲介者情報制御・算出部
７３ 情報送受信機能
７４ 共有判断部
１４１ 入退室管理テーブル
１４４ 共有判断情報テーブル
１５１ プライベートな関係情報テーブル
１６１、１６７ パブリックな関係情報テーブル
１７１ 共有レベルテーブル
２３１ 受信機
２３２ プレゼンスサーバ
２４１、２４５、２４６ 情報端末
２４２、２４３、２４４ ＲＦＩＤタグ
２４７ ＩＰネットワーク
２７１ プレゼンス情報テーブル
２８１ 共有レベルテーブル
２９１ 会議室管理部
２９２ 情報送受信制御部
３０１ 情報送受信制御部
３０２ Ｋｎｏｗ−Ｗｈｏ検索制御部
３３１ 仲介ＩＤテーブル
２ ＵｓｅｒＢ
３ ＵｓｅｒＣ
１１ ＵｓｅｒＥ
１６ 関係情報・共有可否情報管理サーバ
１８ ＵｓｅｒＤ
２１ 多人数会議制御サーバ
２２ Ｋｎｏｗ−Ｗｈｏ検索サーバ
４１、４２、４３、４４、４８、５１ 情報端末
４６ ＩＰネットワーク
４７ ＳＩＰサーバ
５２ コミュニケーション制御部
５３ 情報送受信制御部
５４ Ｋｎｏｗ−Ｗｈｏ検索部
５５ 人間関係管理部
７２ 仲介者情報制御・算出部
７３ 情報送受信機能
７４ 共有判断部
１４１ 入退室管理テーブル
１４４ 共有判断情報テーブル
１５１ プライベートな関係情報テーブル
１６１、１６７ パブリックな関係情報テーブル
１７１ 共有レベルテーブル
２３１ 受信機
２３２ プレゼンスサーバ
２４１、２４５、２４６ 情報端末
２４２、２４３、２４４ ＲＦＩＤタグ
２４７ ＩＰネットワーク
２７１ プレゼンス情報テーブル
２８１ 共有レベルテーブル
２９１ 会議室管理部
２９２ 情報送受信制御部
３０１ 情報送受信制御部
３０２ Ｋｎｏｗ−Ｗｈｏ検索制御部
３３１ 仲介ＩＤテーブル
Claims (21)
- 送受信される電子メール又は公開されていない情報若しくは媒体に基づき作成される、他の端末又はユーザの識別情報を含むプライベートな関係情報をそれぞれ保持する複数の端末と、
アプリケーション又はグループへの参加要求を前記端末から受信し、該端末の識別情報と該アプリケーション又はグループの識別情報とを対応付けた属性情報を記憶する第１のサーバと、
を備え、
該属性情報に基づき、同じアプリケーション又はグループに属する各端末が、それぞれの前記プライベートな関係情報を一時的に共有する情報共有制御システム。 - 請求項１に記載の情報共有制御システムにおいて、
ユーザの識別情報と、該ユーザが知っている情報とが対応して記憶されたデータベースを有し、前記複数の端末のうちの第１の端末から情報検索要求を受信し、要求された情報を知る情報提供ユーザの識別情報を、前記データベースを参照して取得し、該情報提供ユーザの識別情報と第１の端末の識別情報とを送信する第２のサーバと、
公開された又は公開予定の情報若しくは媒体に基づき作成される、互いに関係のある端末又はユーザの識別情報が対応付けられたパブリックな関係情報を保持し、及び、前記第２のサーバから情報提供ユーザの識別情報と第１の端末の識別情報を受信し、第１の端末が属するアプリケーション又はグループの各端末が共有する前記プライベートな関係情報と、前記パブリックな関係情報と、第１の端末が属するアプリケーション又はグループの各端末の識別情報とのいずれか又は複数を参照して、第１の端末から情報提供ユーザへ仲介するひとつ又は複数の仲介端末又はユーザの識別情報を求める第３のサーバと
をさらに備えた情報共有制御システム。 - 請求項２に記載の情報共有制御システムにおいて、
前記第３のサーバは、求められた仲介端末の識別情報に従い、該仲介端末のひとつに仲介依頼を送信し、
前記仲介端末は、受信された仲介依頼に従い、他の仲介端末に仲介依頼を送信する、又は、第１の端末から情報提供の依頼があることを示す情報提供依頼を情報提供ユーザの端末に送信する、又は、情報提供ユーザへの仲介依頼があることを自端末の表示部に表示する情報共有制御システム。 - 請求項２に記載の情報共有制御システムにおいて、
前記第３のサーバは、仲介識別子を設定し、第１の端末の識別情報と、求められた仲介端末の識別情報と、情報提供ユーザの識別情報とに対応して、設定された仲介識別子を記憶し、
該仲介識別子と前記仲介端末の識別情報とを含む仲介候補情報を前記第１の端末に送信し、
前記第１の端末は、仲介候補情報に従い、仲介識別子を含む仲介依頼を前記仲介端末に送信し、
前記仲介端末は、受信された仲介依頼に含まれる仲介識別子を前記第３のサーバへ送信することで仲介先を問い合わせ、
前記第２のサーバは、該問い合わせに従い、仲介識別子に対応する情報提供ユーザの識別情報又はさらに仲介するための他の仲介端末の識別情報を読み出し、前記仲介端末へ送信し、
前記仲介端末は、受信された情報提供ユーザの識別情報に基づき、該ユーザの端末に前記情報提供依頼を送信する、又は、受信された他の仲介端末の識別情報に基づき仲介依頼を送信する情報共有制御システム。 - 請求項１に記載の情報共有制御システムにおいて、
前記第１のサーバは、電子会議室の入退室を管理するサーバであり、
属性情報は、電子会議室への入退室情報である事を特徴とする情報共有制御システム。 - 請求項１に記載の情報共有制御システムにおいて、
前記プライベートな関係情報を各々の前記端末で保持し、該端末と前記第３のサーバが通信する事により、又は、該端末が互いに通信する事により、情報提供ユーザへの仲介端末を検索する事を特徴とする情報共有制御システム。 - 請求項１に記載の情報共有制御システムにおいて、
各端末は、前記プライベートな関係情報を前記第２のサーバに登録し、
前記第３のサーバが、属性情報に基づき、登録されたプライベートな関係情報へのアクセス制御を行う情報共有制御システム。 - 請求項１に記載の情報共有制御システムにおいて、
前記端末が、前記第１のサーバに記憶された属性情報を参照し、又は、前記第１のサーバから予め受信し記憶された属性情報を参照し、同じアプリケーション又はグループに属する端末を判断することを特徴とする情報共有制御システム。 - 請求項１に記載の情報共有制御システムにおいて、
前記第３のサーバが、前記第１のサーバに記憶された属性情報を参照し、又は、前記第１のサーバから予め受信し記憶された属性情報を参照し、同じアプリケーション又はグループに属する端末を判断することを特徴とする情報共有制御システム。 - 請求項１に記載の情報共有制御システムにおいて、
アプリケーション又はグループ毎に共有レベルが定義され、
前記プライベートな関係情報について、他の端末又はユーザの識別情報毎に公開レベルが定義され、
共有レベル及び公開レベルに応じて、前記プライベートな関係情報の共有範囲を制限する情報共有制御システム。 - 請求項１に記載の情報共有制御システムにおいて、
前記第３のサーバは、
仲介端末及び情報提供ユーザを含む仲介ルートに対応して共通記号を設定し、該共通記号を第１の端末、情報提供ユーザの端末及び／又は仲介端末に配布し、該共通記号を含む問合せに対して、共通記号に対応する各ルートで公開可能な情報を返信し、各端末の情報公開を制御する事を特徴とする情報共有制御システム。 - 請求項１１に記載の情報共有制御システムにおいて、
公開可能な情報とは、各ユーザの名前又は公開しているユーザの識別情報であることを特徴とする情報共有制御システム。 - 請求項２に記載の情報共有制御システムにおいて、
前記第３のサーバは、求められた複数の仲介端末の識別情報を前記第１の端末に送信し、
前記第１の端末は、複数の仲介端末の識別情報のひとつを選択して、該仲介端末に仲介依頼を送信する情報共有制御システム。 - 請求項２に記載の情報共有制御システムにおいて、
前記第３のサーバは、求められた複数の仲介端末の識別情報のひとつを自動的に選択し、該仲介端末に仲介依頼を送信する情報共有制御システム。 - 請求項２に記載の情報共有制御システムにおいて、
前記第３のサーバは、仲介依頼を前記第１のサーバに送信し、
前記第１のサーバは、仲介端末の識別情報と、第１の端末の識別情報とを含む情報提供依頼、又は、第１の端末が属するアプリケーション若しくはグループへの参加依頼を、情報提供ユーザの端末に送信する情報共有制御システム。 - 送受信される電子メール又は公開されていない情報若しくは媒体に基づき作成される、他の端末又はユーザの識別情報を含むプライベートな関係情報をそれぞれ保持する複数の端末と、
アプリケーション又はグループへの参加要求を前記端末から受信し、該端末の識別情報と該アプリケーション又はグループの識別情報とを対応付けた属性情報を記憶する第１のサーバと、
ユーザの識別情報と、該ユーザが知っている情報とが対応して記憶されたデータベースを有し、前記複数の端末のうちの第１の端末から情報検索要求を受信し、要求された情報を知る情報提供ユーザの識別情報を、前記データベースを参照して取得し、該情報提供ユーザの識別情報と第１の端末の識別情報とを送信する第２のサーバと、
公開された又は公開予定の情報若しくは媒体に基づき作成される、互いに関係のある端末又はユーザの識別情報が対応付けられたパブリックな関係情報を保持する第３のサーバと
を備え、
前記第３のサーバは、
前記第２のサーバから情報提供ユーザの識別情報と第１の端末の識別情報を受信し、
受信された第１の端末の識別情報に対応するアプリケーション又はグループに属する各端末の識別情報を求め、
該端末のプライベートな関係情報に基づき、受信された情報提供ユーザの識別情報、又は、パブリックな関係情報に基づき求められた該情報提供ユーザの識別情報に対応する第１の仲介端末の識別情報に対応する第２の仲介端末の識別情報を求め、
求められた第２の仲介端末の識別情報に従い、第２の端末に仲介依頼を送信し、
前記第２の仲介端末は、直接又は前記第１の仲介端末を介して、情報提供ユーザの端末に第１の端末の識別情報を含む情報提供依頼を送信し、
前記情報提供ユーザの端末は、第１の端末の識別情報を表示部に表示し、
表示された第１の端末の識別情報に従い、情報提供ユーザが要求された情報を第１の端末のユーザに提供することにより、第１の端末に仲介端末及び情報提供ユーザの識別情報を開示せずに、要求された情報を提供する情報共有制御システム。 - 各ユーザの位置情報及び／又は現在状態を含む、動的に変化する属性情報を、ユーザの識別情報毎に記憶する第４のサーバと、
各ユーザの属性情報を、前記第４のサーバへ登録するための登録部と、
送受信される電子メール又は公開されていない情報若しくは媒体に基づき作成される、他のユーザの識別情報を含むプライベートな関係情報をそれぞれ保持する各ユーザの端末、又は、第３のサーバと
を備え、
属性情報に基づき、同じ位置情報を有する又は予め定められたプレゼンス情報を有するユーザについて、前記ユーザの端末又は前記第３のサーバは、それぞれのユーザのプライベートな関係情報を一時的に共有する情報共有制御システム。 - 請求項１７に記載の情報共有制御システムにおいて、
前記登録部は、
複数の無線タグと、
前記無線タグを有するユーザが近づくことにより、前記無線タグから該無線タグの識別情報を受信し、自識別情報と受信された無線タグの識別情報とを前記第４のサーバに送信する受信機と
を有し、
前記第４のサーバは、
前記受信機から受信された該受信機の識別情報から、該受信機が設置された位置情報を特定し、及び、無線タグの識別情報からユーザの識別情報を特定し、ユーザの識別情報と位置情報とを対応して記憶する情報共有制御システム。 - 請求項１７に記載の情報共有制御システムにおいて、
請求項１に記載の情報共有制御システムにおいて、
ユーザの識別情報と、該ユーザが知っている情報とが対応して記憶されたデータベースを有し、第１の端末から情報検索要求を受信し、要求された情報を知る情報提供ユーザの識別情報を、前記データベースを参照して取得し、該情報提供ユーザの識別情報と第１の端末の識別情報とを送信する第２のサーバ
をさらに備え、
前記第３のサーバは、
公開された又は公開予定の情報若しくは媒体に基づき作成される、互いに関係のある端末又はユーザの識別情報が対応付けられたパブリックな関係情報を保持し、及び、前記第２のサーバから情報提供ユーザの識別情報と第１の端末の識別情報を受信し、第１の端末と同じ位置情報を有する又はプレゼンス情報を有する各ユーザが共有する前記プライベートな関係情報と、前記パブリックな関係情報と、第１の端末と同じ位置情報を有する又はプレゼンス情報を有する各ユーザの識別情報とのいずれか又は複数を参照して、第１の端末から情報提供ユーザへ仲介するひとつ又は複数の仲介端末又はユーザの識別情報を求める情報共有制御システム。 - 請求項１７に記載の情報共有制御システムにおいて、
属性情報に含まれる各情報の組み合わせに対応して共有レベルが定義され、
ユーザ間のプライベートな関係情報について、該ユーザの識別情報毎に公開レベルが定義され、
属性情報に基づき共有レベルを求め、該共有レベル及び公開レベルに応じて、前記プライベートな関係情報の共有範囲を制限する情報共有制御システム。 - 請求項１７に記載の情報共有制御システムにおいて、
属性情報は、各ユーザの所属部署、年齢、性別のいずれか又は複数を含む各ユーザの特徴を現す静的情報をさらに含む事を特徴とする情報共有制御システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006171838A JP4869804B2 (ja) | 2006-06-21 | 2006-06-21 | 情報共有制御システム |
| US11/812,022 US20070299852A1 (en) | 2006-06-21 | 2007-06-14 | Information sharing control system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006171838A JP4869804B2 (ja) | 2006-06-21 | 2006-06-21 | 情報共有制御システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2008003809A true JP2008003809A (ja) | 2008-01-10 |
| JP4869804B2 JP4869804B2 (ja) | 2012-02-08 |
Family
ID=38874663
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006171838A Expired - Fee Related JP4869804B2 (ja) | 2006-06-21 | 2006-06-21 | 情報共有制御システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20070299852A1 (ja) |
| JP (1) | JP4869804B2 (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010211733A (ja) * | 2009-03-12 | 2010-09-24 | Nec Corp | 検索装置および検索方法 |
| JP2014078894A (ja) * | 2012-10-11 | 2014-05-01 | Fujitsu Ltd | 通信システム、管理装置、基地局、通信機器、及び通信路制御方法 |
| JP2014143536A (ja) * | 2013-01-23 | 2014-08-07 | Ricoh Co Ltd | 伝送管理装置、伝送管理方法及びプログラム |
| JPWO2015063873A1 (ja) * | 2013-10-30 | 2017-03-09 | 株式会社日立製作所 | 情報検索システムおよび情報検索方法 |
| JP2017084285A (ja) * | 2015-10-30 | 2017-05-18 | キヤノンマーケティングジャパン株式会社 | ウェブ会議システムおよびその制御方法、プログラム |
| WO2021080110A1 (ko) * | 2019-10-22 | 2021-04-29 | 주식회사 트러스랩 | 클라우드 환경에서 단말의 소속 식별 및 관리를 위한 시스템과 방법 |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8879404B2 (en) * | 2008-01-09 | 2014-11-04 | At&T Intellectual Property I, Lp | Apparatus for managing communication device identifiers |
| FR2927452B1 (fr) * | 2008-02-12 | 2013-07-05 | Ingenico Sa | Procede de controle d'acces, dispositif et produit programme d'ordinateur correspondants. |
| US20100287251A1 (en) * | 2009-05-06 | 2010-11-11 | Futurewei Technologies, Inc. | System and Method for IMS Based Collaborative Services Enabling Multimedia Application Sharing |
| US9053329B2 (en) * | 2012-05-24 | 2015-06-09 | Lockbox Llc | Systems and methods for validated secure data access |
| WO2017004593A1 (en) * | 2015-07-02 | 2017-01-05 | Dots Communication, Inc. | Information sharing control |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09214618A (ja) * | 1996-02-02 | 1997-08-15 | Canon Inc | 通信装置及び通信システム |
| JP2002268986A (ja) * | 2001-03-12 | 2002-09-20 | Fujitsu Ltd | 情報配信装置および情報配信方法 |
| JP2003141381A (ja) * | 2001-11-02 | 2003-05-16 | Tryark Kk | 人脈情報検索システム及び人脈経路探索システム |
| JP2004021995A (ja) * | 2002-06-18 | 2004-01-22 | Microsoft Corp | グループコネクティビティのためのビジュアルグループインタフェース |
| WO2004042612A1 (ja) * | 2002-11-08 | 2004-05-21 | Sumitomo Heavy Industries, Ltd. | 情報管理装置、情報管理システム、情報管理プログラム及び記録媒体 |
| JP2004348179A (ja) * | 2003-05-19 | 2004-12-09 | National Institute Of Advanced Industrial & Technology | 人間関係データの作成方法、人間関係データの作成プログラム及び人間関係データの作成プログラムを記録したコンピュータ読取可能な記録媒体 |
| JP2005038393A (ja) * | 2003-06-23 | 2005-02-10 | Hitachi Ltd | 情報公開設定制御方法、情報管理装置および該情報管理装置を用いたサービス |
| JP2005182211A (ja) * | 2003-12-16 | 2005-07-07 | Fuji Xerox Co Ltd | 情報共有化支援装置および方法 |
| JP2005203928A (ja) * | 2004-01-14 | 2005-07-28 | Nec Corp | 情報伝達システム及び方法 |
| JP2005318503A (ja) * | 2004-03-29 | 2005-11-10 | Hitachi Ltd | プレゼンスサーバ、セッション制御サーバ、パケット中継システム、サーバ、及びシステム |
| JP2005346494A (ja) * | 2004-06-03 | 2005-12-15 | Sony Corp | コンテンツ共有システム及びコンテンツ重要度判定方法 |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1246084A3 (en) * | 1995-03-15 | 2004-05-26 | Kabushiki Kaisha Toshiba | A communication method and the system thereof applied for the network having plural client systems and server systems |
| DE69735486T2 (de) * | 1996-07-22 | 2006-12-14 | Cyva Research Corp., San Diego | Werkzeug zur sicherheit und zum austauch von persönlichen daten |
| US5884035A (en) * | 1997-03-24 | 1999-03-16 | Pfn, Inc. | Dynamic distributed group registry apparatus and method for collaboration and selective sharing of information |
| JPH1196099A (ja) * | 1997-09-19 | 1999-04-09 | Hitachi Ltd | サービス提供システム |
| US6269369B1 (en) * | 1997-11-02 | 2001-07-31 | Amazon.Com Holdings, Inc. | Networked personal contact manager |
| US6820204B1 (en) * | 1999-03-31 | 2004-11-16 | Nimesh Desai | System and method for selective information exchange |
| US7006999B1 (en) * | 1999-05-13 | 2006-02-28 | Xerox Corporation | Method for enabling privacy and trust in electronic communities |
| US7437550B2 (en) * | 1999-12-02 | 2008-10-14 | Ponoi Corp. | System for providing session-based network privacy, private, persistent storage, and discretionary access control for sharing private data |
| US7437408B2 (en) * | 2000-02-14 | 2008-10-14 | Lockheed Martin Corporation | Information aggregation, processing and distribution system |
| US7085834B2 (en) * | 2000-12-22 | 2006-08-01 | Oracle International Corporation | Determining a user's groups |
| WO2002057917A2 (en) * | 2001-01-22 | 2002-07-25 | Sun Microsystems, Inc. | Peer-to-peer network computing platform |
| US7162451B2 (en) * | 2001-11-30 | 2007-01-09 | International Business Machines Corporation | Information content distribution based on privacy and/or personal information |
| JP4292835B2 (ja) * | 2003-03-13 | 2009-07-08 | 沖電気工業株式会社 | 秘密再構成方法、分散秘密再構成装置、及び秘密再構成システム |
| CN1316325C (zh) * | 2003-06-23 | 2007-05-16 | 株式会社日立制作所 | 服务器 |
-
2006
- 2006-06-21 JP JP2006171838A patent/JP4869804B2/ja not_active Expired - Fee Related
-
2007
- 2007-06-14 US US11/812,022 patent/US20070299852A1/en not_active Abandoned
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09214618A (ja) * | 1996-02-02 | 1997-08-15 | Canon Inc | 通信装置及び通信システム |
| JP2002268986A (ja) * | 2001-03-12 | 2002-09-20 | Fujitsu Ltd | 情報配信装置および情報配信方法 |
| JP2003141381A (ja) * | 2001-11-02 | 2003-05-16 | Tryark Kk | 人脈情報検索システム及び人脈経路探索システム |
| JP2004021995A (ja) * | 2002-06-18 | 2004-01-22 | Microsoft Corp | グループコネクティビティのためのビジュアルグループインタフェース |
| WO2004042612A1 (ja) * | 2002-11-08 | 2004-05-21 | Sumitomo Heavy Industries, Ltd. | 情報管理装置、情報管理システム、情報管理プログラム及び記録媒体 |
| JP2004348179A (ja) * | 2003-05-19 | 2004-12-09 | National Institute Of Advanced Industrial & Technology | 人間関係データの作成方法、人間関係データの作成プログラム及び人間関係データの作成プログラムを記録したコンピュータ読取可能な記録媒体 |
| JP2005038393A (ja) * | 2003-06-23 | 2005-02-10 | Hitachi Ltd | 情報公開設定制御方法、情報管理装置および該情報管理装置を用いたサービス |
| JP2005182211A (ja) * | 2003-12-16 | 2005-07-07 | Fuji Xerox Co Ltd | 情報共有化支援装置および方法 |
| JP2005203928A (ja) * | 2004-01-14 | 2005-07-28 | Nec Corp | 情報伝達システム及び方法 |
| JP2005318503A (ja) * | 2004-03-29 | 2005-11-10 | Hitachi Ltd | プレゼンスサーバ、セッション制御サーバ、パケット中継システム、サーバ、及びシステム |
| JP2005346494A (ja) * | 2004-06-03 | 2005-12-15 | Sony Corp | コンテンツ共有システム及びコンテンツ重要度判定方法 |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010211733A (ja) * | 2009-03-12 | 2010-09-24 | Nec Corp | 検索装置および検索方法 |
| JP2014078894A (ja) * | 2012-10-11 | 2014-05-01 | Fujitsu Ltd | 通信システム、管理装置、基地局、通信機器、及び通信路制御方法 |
| JP2014143536A (ja) * | 2013-01-23 | 2014-08-07 | Ricoh Co Ltd | 伝送管理装置、伝送管理方法及びプログラム |
| JPWO2015063873A1 (ja) * | 2013-10-30 | 2017-03-09 | 株式会社日立製作所 | 情報検索システムおよび情報検索方法 |
| JP2017084285A (ja) * | 2015-10-30 | 2017-05-18 | キヤノンマーケティングジャパン株式会社 | ウェブ会議システムおよびその制御方法、プログラム |
| WO2021080110A1 (ko) * | 2019-10-22 | 2021-04-29 | 주식회사 트러스랩 | 클라우드 환경에서 단말의 소속 식별 및 관리를 위한 시스템과 방법 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20070299852A1 (en) | 2007-12-27 |
| JP4869804B2 (ja) | 2012-02-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4869804B2 (ja) | 情報共有制御システム | |
| US8849907B1 (en) | System and method for notifying participants of topics in an ongoing meeting or conference | |
| US6785681B2 (en) | Generating a list of people relevant to a task | |
| US7447996B1 (en) | System for using gender analysis of names to assign avatars in instant messaging applications | |
| US20070005698A1 (en) | Method and apparatuses for locating an expert during a collaboration session | |
| US20080019353A1 (en) | System and method for peer-to-peer Internet communication | |
| US20060029106A1 (en) | System and method for providing content-based instant messaging | |
| US20060173936A1 (en) | Establishment and maintenance of collaborative communication associations based on multiple contextual criteria | |
| JP2012048708A (ja) | コミュニケーション支援装置およびプログラム | |
| US20160247123A1 (en) | Converting Scheduling Information into Different Conferencing Domains | |
| US11159584B2 (en) | Methods, apparatus and/or system for using email to schedule and/or launch group communications sessions | |
| US7822739B2 (en) | Method for exploitation of social networks to derive a location of employees | |
| US20080281914A1 (en) | Computer system | |
| JP2006285708A (ja) | 状態情報管理システム、状態情報管理サーバ、状態情報管理プログラム、及び状態情報管理方法 | |
| JP2005149010A (ja) | イベント開催システムおよびイベント開催方法 | |
| JP6792224B1 (ja) | 情報処理システム、情報処理装置、サーバ装置、プログラム、又は方法 | |
| EP2469449A1 (en) | Information management device, information management method, and information management program | |
| KR101243854B1 (ko) | 인맥 관계를 이용한 미팅 서비스 시스템 및 방법 | |
| JP2020071644A (ja) | チャットシステム。 | |
| JP2015097009A (ja) | ソーシャルネットワーキングサービス提供システムおよびサーバ | |
| JP3890582B2 (ja) | 情報流通システム及び情報流通方法 | |
| JP5323803B2 (ja) | コミュニティ管理サーバおよびコミュニティ生成方法 | |
| JP5169384B2 (ja) | 会議システム、端末装置、会議支援装置及びプログラム | |
| JP4736945B2 (ja) | 状態情報管理システム及び状態情報管理サーバ | |
| WO2022185556A1 (ja) | 交流管理装置、交流管理方法、および記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20081031 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110328 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110412 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110609 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20111115 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20111116 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20141125 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |