JP2002230144A - 情報提供システム及び情報提供サービス方法 - Google Patents

Abstract

(57)【要約】 【課題】 オープンなネットワーク上で人脈情報の提供
サービスを行い、提供情報に応じた料金を決定する。 【解決手段】 ユーザはユーザ装置３０から他ユーザに
対して電子メールで通信する際、その写し（ｃｃ）を情
報収集システム１０４に送る。人脈情報サーバ１００は
こうして収集されるユーザ間の通信情報を分析し、各ユ
ーザ間の話題の繋がりを求める。ユーザがリクエスト処
理システム１０６に対してある話題に詳しい人材を照会
すると、人脈情報サーバ１００が、自分の持っているユ
ーザ間の関係の情報から、そのリクエスト元ユーザを起
点として通信のある２者関係をたどり、その話題に対し
て詳しいユーザを見つける。リクエスト処理システム１
０６は、リクエスト元からそのユーザに至る人脈の情報
を、リクエスト元ユーザに回答する。そして、その人脈
の長さなどに応じた料金を、この回答に対して課す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報提供システム
に関し、特にユーザ間の繋がりの情報を提供するシステ
ムに関する。

【０００２】

【従来の技術】インターネットにより、個人の情報への
アクセス能力は質・量共に飛躍的に増大したが、古くか
らの人との対話による情報収集も依然として重要な意義
を持っている。ところが、このような人との対話による
情報収集は、個人の交友範囲が狭ければ所望の情報を持
っている人材にたどり着くことが困難であるという問題
がある。

【０００３】このような問題に対する解決手段として、
本出願人による特開平１０−３０１９０５号公報のシス
テムが知られている。このシステムでは、「パイプ」な
るオブジェクトを用いて各人の間の関係を管理する。パ
イプは、２人の間の関係を示す情報であり、それら２人
の間の共通の話題の情報を含んでいる。パイプの生成や
更新は、電子メールシステムなどによる各人の間の情報
交換をモニタリングし、コミュニケーションを検出する
ことによって行う。また、このシステムでは、共通の人
を介したパイプを合成することにより直接の情報交換が
ない２人の間をつなげるパイプを生成するなどにより、
人と人の間の潜在的な繋がりを発見する機能を提供して
いる。この従来システムは、ユーザからキーワードなど
の入力を受け付け、そのユーザを起点としてそのキーワ
ードを話題とした情報交換を行っている人の繋がり（パ
イプ）をたどることにより、そのキーワードに関する情
報を持っている人を「知人のつて」をたどって多数ピッ
クアップし、そのような人材の情報をユーザに提供する
ことができる。

【０００４】

【発明が解決しようとする課題】しかしながら、上記従
来システムは、オープンなネットワーク環境でそのよう
な情報を提供するサービスを行う場合についての配慮が
あまりよくなされていなかった。例えば上記従来技術で
は、システムが取得した情報はすべて取り込んでパイプ
の生成や更新に用いており、情報の利用をユーザの希望
により柔軟に制限することは困難であった。また、上記
従来技術では、サービス提供に係る料金について配慮が
なされていなかった。また、各人には、ある人との関係
を特定の人には知られたくないなどの場合もあり得る
が、上記従来技術ではそのような観点に対する配慮が示
されていない。

【０００５】本発明はこのような問題を解決した情報提
供のためのシステム及び情報提供サービス方法を提供す
ることを目的とする。

【０００６】

【課題を解決するための手段】上記目的を達成するた
め、本発明に係る情報提供システムは、与えられる原情
報を解析して各ユーザ間の関係を示す関係情報を生成し
て管理するとともに、リクエストを受け付けた場合に、
それら関係情報に基づき、そのリクエストに合致するユ
ーザを合致ユーザとして求め、求めた合致ユーザに関す
る情報を回答する関係情報サーバと、各ユーザ間で通信
される通信情報を収集し、それら通信情報を前記原情報
として前記関係情報サーバに供給する情報収集システム
と、ユーザからリクエストを受け付けて前記関係情報サ
ーバに渡し、このリクエストに対して前記関係情報サー
バから得られた合致ユーザに関する情報を、そのユーザ
に提供するリクエスト処理システムと、前記リクエスト
処理システムにて受けたリクエストに対する前記ユーザ
への情報提供に関する料金を計算し、記録する料金処理
システムとを備える。

【０００７】好適な態様では、前記情報収集システム
は、収集した通信情報に付随する利用許可情報に基づ
き、その通信情報が前記関係情報サーバに供給可能か否
かを判定する判定手段を備え、その判定手段で供給可能
と判断された通信情報のみを前記関係情報サーバに供給
することを特徴とする。この態様によれば、各ユーザに
よる情報開示の制御が可能になる。

【０００８】また本発明に係る情報提供システムは、各
ユーザ間の関係を示す関係情報を管理するとともに、リ
クエストを受け付けた場合に、それら関係情報に基づ
き、そのリクエストに合致するユーザを合致ユーザとし
て求め、求めた合致ユーザに関する情報を回答する関係
情報サーバと、前記リクエストに対する前記ユーザへの
情報提供に関する料金を計算し、記録する料金処理シス
テムと、を備え、前記料金処理システムは、そのリクエ
スト発信元ユーザから前記合致ユーザまでの間に介在す
る直接通信関係を有する２ユーザ関係の数に基づき、前
記合致ユーザに関する情報提供の料金を計算する計算手
段、を備える。

【０００９】また、本発明に係るシステムは、各ユーザ
間の関係を示す関係情報を管理するとともに、リクエス
トを受け付けた場合に、それら関係情報に基づき、その
リクエストに合致するユーザを合致ユーザとして求め、
求めた合致ユーザに関する情報を回答する関係情報サー
バと、前記リクエストに対する前記ユーザへの情報提供
に関する料金を計算し、記録する料金処理システムとを
備え、前記料金処理システムは、そのリクエスト発信元
ユーザと前記合致ユーザとの間の話題の繋がりと、前記
リクエストと、の合致度に基づき、前記合致ユーザに関
する情報提供の料金を計算する計算手段、を備える。

【００１０】また、本発明に係るシステムは、各ユーザ
間の関係を示す関係情報を管理するとともに、リクエス
トを受け付けた場合に、それら関係情報に基づき、その
リクエストに合致するユーザを合致ユーザとして求め、
求めた合致ユーザに関する情報を回答する関係情報サー
バと、ユーザからリクエストを受け付けて前記関係情報
サーバに渡し、このリクエストに対して前記関係情報サ
ーバから得られた合致ユーザに関する情報を、そのユー
ザに提供するリクエスト処理システムとを備え、前記リ
クエスト処理システムは、リクエスト元のユーザから前
記合致ユーザに至る繋がりに介在する各２ユーザ間関係
についての開示可否を判定し、前記繋がりに介在するす
べての２ユーザ間関係について開示許可が得られた場合
に、その合致ユーザに関する情報をリクエスト元のユー
ザに提供することを特徴とする。

【００１１】

【発明の実施の形態】以下、本発明の実施の形態（以下
実施形態という）について、図面に基づいて説明する。

【００１２】図１は、本発明を具現化した人脈情報提供
システム１０の概略構成を示す図である。

【００１３】図１において、人脈情報提供サービスシス
テム１０は、インターネット等の通信ネットワーク２０
に接続されている。また、パーソナルコンピュータや電
話機、携帯電話機などのユーザ装置３０も通信ネットワ
ーク２０に接続されている。人脈情報提供サービスシス
テム１０は、通信ネットワーク２０を介したユーザ装置
３０間の情報のやりとりをモニタリングして各ユーザ間
の話題の繋がりを求めると共に、ユーザからのリクエス
トに応じ、通信ネットワーク２０を介してその繋がりに
関する情報の提供サービスを行う。

【００１４】人脈情報提供サービスシステム１０におい
て、ユーザ登録システム１０２は、このシステム１０の
提供するサービスへのユーザ登録処理を実行するシステ
ムである。ユーザデータベース１１０は、このユーザ登
録により登録されたユーザの基礎情報を登録するデータ
ベースである。このユーザデータベース１１０は、情報
収集システム１０４、リクエスト処理システム１０６、
料金処理システム１０８、人脈情報サーバ１００により
適宜参照される。

【００１５】情報収集システム１０４は、ユーザ同士の
間でやりとりされる通信情報を収集し、収集した情報を
人脈情報サーバ１００に供給するシステムである。人脈
情報サーバ１００は、それら収集された情報を分析し
て、各ユーザ間の話題の繋がり関係の情報（パイプ情報
と呼ぶ）の生成、更新等の管理を行うとともに、与えら
れたリクエストに応じた人脈の情報を提供する。この人
脈情報サーバ１００の行う処理は、本出願人による特開
平１０−３０１９０５号公報に示されたパイプ生成、更
新、合成、検索などの処理と同様でよい。リクエスト処
理システム１０６は、ユーザから情報取得リクエストを
受け付け、このリクエストを人脈情報サーバ１００に送
り、これに応じて人脈情報サーバ１００から返されてく
る回答をそのユーザに送信する。料金処理システム１０
８は、このリクエストに対する回答サービスに対する料
金を計算し、記録するシステムである。

【００１６】以下、この人脈情報提供サービスシステム
１０にて行われる各種処理を説明する。

【００１７】＜ユーザ登録＞ユーザ登録では、少なくと
もユーザの身元保証情報と通信アドレスを登録してもら
う。身元保証情報は、住所、氏名、生年月日などのよう
な基礎的な身元情報と、これに対する裏付けとなるクレ
ジットカード番号やデビットカード番号、運転免許証番
号などの組合せである。通信アドレスは、電子メール
（Ｅメール）アドレス、電話番号、ＦＡＸ番号など、そ
のユーザが通信に利用するアドレスである。本実施形態
では、通信アドレスとしてＥメールアドレスと電話番号
など、複数種類のアドレスを登録できる。なお、これら
基礎的な情報の他に、ユーザの自己紹介などの情報を登
録してももちろん良い。

【００１８】このユーザ登録は、例えばユーザが、ユー
ザ装置３０から通信ネットワーク２０を介してユーザ登
録システム１０２にアクセスし、登録システム１０２が
提供するフォームに対して必要事項（身元保証情報や通
信アドレスなど）を入力することにより行うことができ
る。必要事項が入力されると、登録システム１０２は、
入力された身元保証情報を調べて、その正当性を検査す
る。ここでは例えば、登録システム１０２からクレジッ
トカード会社の顧客管理サーバなどに対し、住所、氏名
などとクレジットカード番号の組合せを送り、そのよう
な組合せに該当する顧客が登録されているかどうかを照
会することにより行うことができる。このような正当性
検査により正当なユーザの登録申込みと判断されると、
このユーザは正規ユーザとして人脈情報提供サービスシ
ステム１０の各種サービスを享受可能となる。また、正
当なユーザ登録と判断された場合、登録システム１０２
は、そのユーザに対して認証情報を付与する。この認証
情報は、例えば、登録システム１０２が自動的に付与し
た一意なユーザＩＤと、ユーザが入力したパスワードな
どの組から構成される。もちろんパスワード以外にも指
紋など様々な個人認証方式を利用することができる。こ
の認証情報は、例えばリクエストの受付などの際にユー
ザ認証などに用いられる。

【００１９】このようにして登録されたユーザ情報は、
ユーザデータベース１１０に登録され、サービスシステ
ム１０内の各サブシステムからの利用に供される。図２
は、ユーザデータベース１１０に登録される情報の例で
ある。この図に示すように、データベース１１０には、
各ユーザごとに、ユーザＩＤとパスワード等からなる認
証情報が登録される。またこの例では、各ユーザの通信
アドレスとしては、電話番号、ＦＡＸ番号、Ｅメールア
ドレスの３種類が登録可能である。また、身元保証情報
としてはクレジットカード番号が登録されている。な
お、図２に示したデータ項目は一部に過ぎず、例えばこ
のほかに各ユーザの住所や氏名、自己紹介などの情報が
データベース１１０に登録されていてもよい。

【００２０】＜情報収集＞情報収集システム１０４によ
る情報収集処理について説明する。ここでは、電子メー
ル（Ｅメール）を用いたユーザ間の通信の情報を収集す
る場合を例にとって説明する。この場合、各登録ユーザ
は、他のユーザ宛に送信する電子メールのｃｃ（カーボ
ンコピー：写し）やｂｃｃ（ブラインドカーボンコピ
ー）の宛先に情報収集システム１０４のメールアドレス
を記入することにより、そのメールの写しを情報収集シ
ステム１０４に送信する。これを受け取った情報収集シ
ステム１０４は、その電子メールを人脈情報サーバ１０
０に提供する。

【００２１】なお、人脈情報サーバ１００に提供された
メールの情報は、人脈の繋がりという形で他のユーザに
知られる可能性があるので、各ユーザは自分の通信情報
について人脈情報サーバ１００に提供するか否かを制御
できることが望ましい。もちろん電子メールのｃｃやｂ
ｃｃの宛先に情報収集システム１０４を指定するか否か
でこのような制御は可能であるが、本実施形態では更
に、当該メールを人脈情報サーバ１００に供給してよい
か否かの判断基準となる利用許可情報を、ユーザが電子
メール中に組み込み可能とすることで、多様な仕方でこ
の情報供給制御を可能にしている。

【００２２】この方式では、図３に説明するように、情
報収集システム１０４は、電子メール（写し）を受信す
ると（Ｓ１０）、その電子メールに含まれる利用許可情
報の内容を調べることにより（Ｓ１２）、その電子メー
ルが人脈情報サーバ１００による人脈形成処理に利用可
能か否かを判定する（Ｓ１４）。そして、利用可能と判
定されるとその電子メールを人脈情報サーバ１００に提
供し（Ｓ１６）、利用不可と判定されるとその電子メー
ルは破棄して処理を終了する。なお、利用不可と判定さ
れた電子メールを破棄せずにストックしておき、ストッ
クした電子メールについて、ユーザから人脈情報サーバ
１００への供給の指示を受け付けられるようにすること
も可能である。

【００２３】以下、この具体例を説明する。まず第１の
例は電子メールの重要度に応じて制御するという方式で
ある。この方式では、電子メールでよく用いられる「重
要度」の情報が利用許可情報となる。そして、例えば、
『重要度が「高」のメールは人脈情報サーバ１００に供
給せず、重要度が「通常」以下のメールのみ供給する』
などのルールを個々のユーザが定め、情報収集システム
１０４に登録しておく。情報収集システム１０４は、ユ
ーザから電子メールの写しを受け取ると、その利用許可
情報「重要度」の値を調べ、その値を当該ユーザのルー
ルに従って判別することで、そのメールを人脈情報サー
バ１００に供給するかどうかを判定する。例えば、電子
メールの重要度が「高」で、送信元ユーザが上述の例と
同じルールを採用していた場合、その電子メールは人脈
情報サーバ１００に提供不可と判定される。

【００２４】また、別の例として、電子メールの内容を
人脈情報サーバ１００に供給するか否かを、その電子メ
ールの宛先に応じて制御することも可能である。この例
では、宛先自体が利用許可情報となる。そして、各ユー
ザは、どの宛先のメールをサーバ１００に供給する（あ
るいは供給しない）かなどの判定ルールを情報収集シス
テム１０４に予め登録しておく。判定ルールは、例えば
『ユーザａ，ｂ，ｃ宛の電子メールはサーバ１００に供
給しない。それ以外を宛先とするメールはサーバ１００
に供給する』などである。情報収集システム１０４は、
ユーザから電子メールの写しを受け取ると、その利用許
可情報である「宛先」を調べ、その「宛先」を当該ユー
ザのルール従って判別することで、そのメールを人脈情
報サーバ１００に供給するかどうかを判定する。なお、
電子メールでは、宛先欄に同時に複数ユーザのアドレス
が指定されることがあるが、その場合には、例えば個々
の宛先ユーザ（一人）ごとに別々のメールと解釈し、宛
先一人一人ごとにこの判定を行えばよい。

【００２５】なお以上の例では、１つの電子メール全体
を単位として人脈情報サーバ１００に供給するか否かを
制御したが、１つの電子メール内に含まれる各部分ごと
に同様の制御をできるようにすることもできる。これに
は、例えば、人脈情報サーバ１００に供給しない範囲の
開始位置や終了位置を指示するための予約語（例えばＸ
ＭＬ等のタグとして規定すればよい）を予め定めておく
などすればよい。ユーザは、電子メールのうちで人脈情
報サーバ１００の分析に回されたくない部分があれば、
その開始位置と終了位置をそれぞれ対応する予約語で挟
み込むことにより、これを明示的に指定することができ
る。この方式では、情報収集システム１０４は、受信し
た電子メールの写しのうち、予約語で囲まれた部分を削
除した内容を人脈情報サーバ１００に提供する。

【００２６】以上説明した、重要度や宛先などに基づく
人材情報サーバ１００への電子メールの供給判断と、電
子メール中での供給範囲の個別指定の処理とは、相互に
組み合わせることもできる。組み合わせる場合は、メー
ル全体が重要度等によって供給可能と判断された場合
に、メール本文中の予約語等による範囲指定を調べ、供
給可能な部分のみをサーバ１００に供給する。この場
合、メール全体が供給不可と判断された場合は、メール
本文は調べなくてよい。なお、このような組合せの代わ
りに、範囲指定のタグのみに応じて、メール本文の各範
囲がサーバ１００に供給可能か否かを判断する方式もも
ちろん可能である。

【００２７】なお、以上の例では電子メールのｃｃ（写
し）を中央の情報収集システム１０４に送信してもらう
ことでユーザ間の通信情報の収集を行ったが、これ以外
の方式も可能である。代替方式には、例えば、各ユーザ
装置３０と通信ネットワーク２０との間にそれぞれ情報
収集システムを設け、各ユーザ装置３０と通信ネットワ
ーク２０との間で出入りする通信情報を収集し、それを
中央の人脈情報サーバ１００（このサーバ１００は分散
化されていてもよい）に送信して集約するという方式が
ある。この場合、情報収集システムは、ユーザ装置３０
にソフトウエア又はハードウエアとして組み込んでもよ
いし、通信ネットワーク２０の交換局に組み込んでもよ
い。この方式では、ユーザは電子メールのｃｃに情報収
集システムのアドレスを指定する等の操作を行わなくて
も、ただ通信を行うだけでその通信情報を人脈情報サー
バ１００に供給することができる。利用可能情報を用い
た人脈情報サーバ１００への通信情報供給制御は、この
方式にとって非常に有用である。

【００２８】また、このように各ユーザ装置３０と通信
ネットワーク２０との間に情報収集システムを配置する
構成の場合、ｃｃ機能をサポートしない通信媒体を用い
た通信でも情報収集が可能となる。例えば、電話や携帯
電話、ＦＡＸ、個人ホームページへのアクセス、チャッ
トによる会話、文書ファイルの交換などの通信からも情
報を収集できる。これらはいずれも送信者と受信者のア
ドレスが何らかの形で通信情報中に含まれているので、
ユーザ間の通信の話題の分析に利用できる。なお、電話
や携帯電話などの音声による通信では、その通信内容を
音声認識技術にて電子的なテキスト情報に変換するなど
してから、人脈情報サーバ１００に提供する。また、Ｆ
ＡＸを用いた通信の場合は、文字認識技術を利用してＦ
ＡＸシート内の各文字を読みとってテキスト化すればよ
い。

【００２９】以上のような電子メール、電話等の通信内
容を取得した情報収集の他に、電子掲示板システムを利
用した情報収集も可能である。すなわち、電子掲示板に
おいて、他ユーザの投稿に対するレスポンスの投稿や、
他の投稿を引用した投稿を調べることにより、ユーザ間
の話題の繋がりを求めるという方法である。これには、
例えば、情報収集システム１０４が、電子掲示板サーバ
に蓄積された各投稿のデータを調査し、レスポンス関係
や、引用元を明示した引用部位を見つけて分析すればよ
い。

【００３０】＜パイプ生成・更新＞情報収集システムか
ら通信情報を供給されたときの人脈情報サーバ１００の
処理を、図４を参照して簡単に説明する。なお、前述し
たように、人脈情報サーバ１００には、本出願人による
特開平１０−３０１９０５号公報に示されたパイプ生
成、更新、合成、検索などの処理をそのまま利用できる
ので、詳細について必要があれば該公報を参照された
い。

【００３１】まず、人脈情報サーバ１００は、情報収集
システム１０４から通信情報を取得すると、その通信情
報から発信元及び宛先のアドレスを抽出し（Ｓ２０）、
それら各アドレスに基づき、発信元及び宛先のユーザを
特定する（Ｓ２２）。このユーザ特定処理は、発信元ア
ドレス、宛先アドレスに対応するユーザＩＤをユーザデ
ータベース１１０で調べることにより行うことができ
る。本実施形態では、複数の通信媒体の通信アドレスを
ユーザデータベース１１０に登録しているので、同じユ
ーザが異なる通信媒体を用いて通信を行った場合でも、
それをそのユーザの通信として認識することができる。
なお、電子メールで宛先が複数記載されている場合は、
個々の宛先ごとにそれぞれ別々のメールとして取り扱
い、それぞれに対して以下の処理を行う。

【００３２】発信元及び宛先のユーザが特定できると、
次は通信内容の分析を行う（Ｓ２４）。この分析では、
通信情報に含まれるキーワードを抽出する。キーワード
抽出は、例えば通信内容のテキストデータ（電子メール
の場合は、見出し及び／又は本文。電話の場合は、その
音声通信情報をテキスト化したデータ）に対して周知の
形態素解析を施すことにより行うことができる。ここ
で、話題の傾向にかかわらず一般的に現れる単語（例え
ば「こんにちわ」など）をキーワードとして取り上げな
いようにすることにより、より話題に特徴的なキーワー
ドを抽出できる。この場合、分析結果としては、通信情
報中に現れた各キーワードとその出現回数の情報が得ら
れる。

【００３３】人脈情報サーバ１００は、この分析結果に
基づき、発信元ユーザと宛先ユーザとの間の話題の繋が
りを示すパイプ情報を生成又は更新する（Ｓ２６）。そ
れら２人のユーザの間にそれまでパイプ情報が生成され
ていなければ、Ｓ２６ではパイプ情報を生成する。一
方、それらユーザ間にパイプ情報が既に生成されていれ
ば、今回の分析結果をそのパイプ情報に反映させること
により、パイプ情報を更新する。

【００３４】図５にパイプ情報のデータ形式の一例を示
す。パイプ情報は、人的繋がり（パイプ）の両端に位置
するユーザを示す２つのノード（ユーザＩＤを値として
持つ）情報と、それら２人の間の通信にこれまで話題と
してのぼったキーワード群やその各々の出現頻度（重
み）の情報を含む。新たにパイプ情報を生成する場合
は、これら図５に例示した項目のデータ構造を当該２人
のユーザのペアについて生成する。また、パイプ情報を
更新する場合には、通信内容の分析結果のキーワードや
その出現頻度の情報を、該当するパイプの重み情報に加
算するなどの処理を行う。

【００３５】以上、収集した通信情報の分析結果に基づ
くパイプ情報の生成、更新処理について説明した。これ
は通信を行った２人のユーザの間のパイプに関する処理
であるが、本実施形態では更にこの２者間関係の生成、
更新の結果を他のユーザのパイプ情報に反映させて、新
たな人脈関係を生成することもできる。これは、人脈情
報サーバ１００のパイプ合成機能により実現できる。パ
イプの合成処理には、直列合成とたたみ込み合成とが含
まれる。

【００３６】直列合成は、図６に示すように、ユーザＡ
とＢの間、ユーザＢとＣの間にパイプが形成されている
が、ユーザＡとＣの間にはパイプが形成されていないと
いう状況において、ＡとＢのパイプ、ＢとＣのパイプか
ら、ＡとＣの間のパイプを合成する処理である。合成さ
れるＡＣ間のパイプは、ＡＢ間の通信の話題（キーワー
ド）とＢＣ間の通信の話題とのいわば最大共通部分を取
り出したものである。図６では、ａ，ｂ，ｃなどは個々
のキーワードを表し、それらキーワードとイコール
「＝」で結ばれた数値がその重みを示す。図６の例で
は、例えばキーワードａはＢＣ間のパイプには現れない
ので合成パイプには現れず、キーワードｂはＡＢ間，Ｂ
Ｃ間の両方に現れるので、その重みの小さい方の値がＡ
Ｃ間の合成パイプの重みとなる。

【００３７】たたみ込み合成は、あるパイプの繋がり
を、その両端のノード（ユーザ）から延びる他のパイプ
の情報によって強化するために行う。図７はこのたたみ
込み合成の一例を示したものであり、この例では、元々
存在したユーザＢとＣの間のパイプ（ｘ＝２）が、ＡＢ
間のパイプとＣＤ間のパイプの共通話題の最大部分を組
み込むことで、強化されている（ｘ＝２，ｂ＝１，ｃ＝
３）。

【００３８】このように生成された合成パイプの両端の
ユーザ同士の間では、そのパイプに含まれるすべての話
題（キーワード）を「直接には」通信していないかもし
れない。しかし、他のユーザとの通信内容からみて、そ
れら２人のユーザは「直接には」通信していない話題に
ついても知識を持っていると推定され、合成パイプに示
されるキーワードを潜在的な共通話題として持っている
と考えることができる。このようなパイプの合成によ
り、ユーザ間の潜在的な話題の繋がりを発見することが
できる。

【００３９】パイプの合成は、収集した通信情報を分析
するごとに、その通信情報がやりとりされたユーザ間の
パイプを起点に実行すればよい。またパイプ合成処理を
１時間ごとなど定期的に実行するようにしてもよい。そ
して、合成により得られたパイプの情報には、これがど
のノード間のパイプを合成した結果得られたかを示す情
報を関連付けて記憶しておく。

【００４０】このようにして生成、更新又は合成された
パイプ情報群により、各ユーザ間の話題の繋がりのネッ
トワークが表現されることになる。人脈情報サーバ１０
０は、これらパイプ情報群を保持しており、リクエスト
に応じてその情報を提供することができる。

【００４１】＜リクエスト処理＞次に、ユーザから人脈
情報サーバ１００へのリクエストに関する処理を説明す
る。本実施形態では、ある話題に詳しい人又はある話題
に関心のある人の照会や、ある話題に関して関心を持つ
人の集団の形成などを人脈情報サーバ１００へリクエス
トすることができる。

【００４２】ユーザは、ユーザ装置３０からリクエスト
処理システム１０６にアクセスして情報取得のリクエス
トを入力する。これには、例えばリクエスト処理システ
ム１０６側でリクエスト入力用のウェブページを提供す
ればよい。このウェブページは、ｉモード（登録商標）
など携帯電話ベースのウェブサービスのページであって
もよい。また、電子メールや電話などでリクエストを処
理システム１０６に入力することも可能である。

【００４３】以下、図８を参照してリクエスト処理シス
テム１０６の処理を説明する。まず、リクエスト処理部
１０６は、ユーザからリクエストの申込みを受けると
（Ｓ３０）、ユーザ認証を行う（Ｓ３２）。例えば、ウ
ェブページを用いてリクエストを受ける場合、ユーザＩ
Ｄとパスワード等の認証情報を入力するページを提供
し、そのページに正しい認証情報が入力された場合、正
当なユーザからのリクエストと判定する。電子メールを
用いて送られてきたリクエストの場合、送信元の電子メ
ールアドレスを調べ、それが登録ユーザのアドレスに合
致する場合は、正当なユーザからのリクエスト申込みと
判定する。ＦＡＸや電話を用いたリクエストの場合も同
様でよい。なお、出先の電話機などからリクエストした
場合に対応するため、発信元アドレスに該当するものが
データベース１１０に登録されていない場合には、音声
ガイダンス等に従ってユーザにユーザＩＤとパスワード
を入力してもらうようにしてもよい。

【００４４】認証が失敗した場合（Ｓ３４の結果がＮ）
は、そのリクエストの受付を拒否し、ユーザ認証に失敗
した旨のメッセージをユーザに返すなどの所定のエラー
処理を実行して、処理を終了する。

【００４５】一方認証が成功してリクエスト発信元ユー
ザが正当なユーザと判定された場合（Ｓ３４の結果が
Ｙ）、リクエスト処理システム１０６は、そのとき受け
付けたリクエストの内容を人脈情報サーバ１００に転送
し、処理を依頼する（Ｓ３６）。

【００４６】ウェブページでリクエストを受け付ける場
合は、ユーザ認証成功後に、リクエスト内容を指定する
ページをユーザに提供し、そのページに入力された事項
を人脈情報サーバ１００に転送することになる。

【００４７】ここで、リクエストは、例えばリクエスト
の種類（人材照会か、コミュニティ形成か）と、人脈を
絞り込む話題を特定するためのキーワードなどの情報を
指定することにより行う。ウェブページを用いる場合
は、話題やキーワードを入力する入力欄をページに設け
ればよい。電話の場合、音声ガイダンスによりユーザに
キーワードの発声を求め、これに応じて発声されたキー
ワードを音声認識で判別するなどの処理を行えばよい。
電子メールを用いたリクエストでは、例えばサブジェク
ト（件名）にリクエストの種類、本文に話題（キーワー
ド）を書き込むなどすればよい。このようなリクエスト
内容は、当該リクエストの発信元のユーザＩＤと関連付
けて、人脈情報サーバ１００に転送される。

【００４８】人脈情報サーバ１００にリクエストを転送
すると、リクエスト処理システム１０６はそのリクエス
トに対する回答がサーバ１００から返ってくるのを待つ
（Ｓ３８）。

【００４９】人脈情報サーバ１００は、転送されてきた
リクエストを処理し、それに対する回答を生成する。こ
の処理は、前掲の本出願人による特開平１０−３０１９
０５号公報に開示された処理と同様でよい。

【００５０】簡単に説明すると、人材照会のリクエスト
の場合、リクエスト発信元のユーザから延びる各パイプ
について、そのパイプとリクエスト内容との合致度を求
める。

【００５１】合致度は、合成されたパイプについても計
算する。合致度は、例えば、そのパイプに含まれる各キ
ーワードの重みをそれぞれ要素とするｎ次元の特徴ベク
トル（ｎはそのパイプの全キーワード数）を考え、リク
エスト内容も同様にｎ次元の特徴ベクトルと考え、それ
らの内積を計算することにより求めることができる。リ
クエストに含まれるキーワードの種類は、一般にパイプ
のキーワード種類数（次元数）よりも少ないと考えられ
るが、その場合リクエストに含まれていないキーワード
の重みは０とすればよい。リクエスト発信元ユーザから
延びるパイプのうち、このように求めた合致度がもっと
も高いパイプの相手方ノード（もう一方のノードはリク
エスト発信元自身である）のユーザをリクエスト内容に
合致するユーザ（合致ユーザ）として抽出する。

【００５２】このようにして求められた合致ユーザの情
報が、回答としてリクエスト処理システム１０６に返さ
れる。ここで、回答の情報には、合致ユーザの名前や通
信アドレスなどを含めることで、リクエスト発信者から
合致ユーザに連絡が取れるようにする。また、単に合致
ユーザだけでなく、その合致ユーザに至る人脈（「つ
て」）の情報も回答に加えることで、リクエスト者が合
致ユーザに連絡を取る際に、その「つて」を説明するこ
とで合致ユーザの信用を得やすくすることができる。こ
こで、「つて」の情報は、合致度に基づき選び出したパ
イプが合成パイプであった場合に求められる。合成パイ
プについては、その合成の元となったパイプを記憶して
いるので、この記憶情報に応じて合成パイプを展開する
ことで、リクエスト元から合致ユーザに至るまでに経由
するユーザを特定することができる。

【００５３】なお、以上の例では最高の合致度を持つパ
イプの相手方ノードのユーザの情報のみをリクエスト元
に回答したが、この代わりに、合致度の高い順に所定数
の合致ユーザについての情報を回答するようにすること
も可能である。また、閾値を定め、その閾値を超える合
致度を持つパイプの相手方ノードのユーザをすべて回答
するようにしてもよい。

【００５４】コミュニティ形成のリクエストの場合は、
人脈情報サーバ１００は、上記人材照会の場合と同様に
して、リクエスト発信元のユーザから延びる各パイプ
の、リクエストに対する合致度を求める。そして、それ
らパイプのうち、合致度が予め定めた閾値以上となるパ
イプのみを選び出す。このようにして選び出した各パイ
プの相手方ノードのユーザの集合を、リクエストに指定
された話題に合致するコミュニティとして回答する。も
ちろん、この際、その集合の各ユーザに（リクエスト元
から）至る人脈の情報を付加してもよい。

【００５５】人脈情報サーバ１００からこのようなリク
エストに対する回答を受け取ると、リクエスト処理シス
テム１０６は、その回答をリクエスト発信者に対して送
信し（Ｓ４０）、料金処理システム１０８に対してその
回答についての料金の課金処理を指示する（Ｓ４２）。

【００５６】なお、リクエスト処理システム１０６は、
ユーザから、リクエストに対する回答の回答形式（どの
通信媒体を用いるかなど）の指定を受け付けることがで
きる。例えば、ユーザは、リクエスト処理システム１０
６にリクエスト内容を入力する際、回答を電子メールで
受け取りたい、携帯電話に音声で知らせて欲しい、ＦＡ
Ｘで送って欲しいなどと、その回答形式を指定できる。
もちろんこの際ユーザは、明示的にせよデフォルト指定
にせよ、何らかの形で回答返信先の通信アドレスを指定
する必要がある。リクエスト処理システム１０６は、こ
のような回答形式の指定のあったリクエストについて
は、その指定された回答形式に従って回答をユーザ宛に
送信する。

【００５７】また、以上の例では、コミュニティ形成
は、リクエスト発信元のユーザを起点とするコミュニテ
ィの場合であったが、リクエスト発信元に起点を限定せ
ず、人脈情報サーバ１００の内包する人脈ネットワーク
情報のなかで広くそのリクエストに合致するユーザのコ
ミュニティネットワークを生成するようにすることも可
能である。この場合、例えば、まずコミュニティ形成リ
クエストの内容に最も合致するパイプを見つけだし、こ
のパイプを起点にして上記と同様のコミュニティ形成処
理を行うなどの処理が考えられる。また、コミュニティ
形成の起点をリクエスト発信元ユーザが指定できるよう
にすることも考えられる。

【００５８】＜料金処理＞料金処理システム１０８は、
リクエスト処理システム１０６からの料金処理指示に従
って、リクエスト元のユーザに対して、リクエスト回答
サービスに対する料金の課金処理を行う。本実施形態で
は、人脈情報提供ならではの課金処理を実行している。

【００５９】本実施形態の料金計算では、回答に含まれ
る合致ユーザのリクエスト発信元からの人脈的な距離
と、合致ユーザとリクエスト発信元を結ぶパイプの合致
度と、をパラメータとして用いている。

【００６０】人脈的な距離は、リクエスト発信元から合
致ユーザに達するまでに経由する直接の知人関係（すな
わち直接の通信のある関係）の数であり、この数が大き
いほど、リクエスト元からみて、より知り合いになりに
くかったであろうという意味で、貴重な情報源であると
言える。したがって、一つの考え方として、リクエスト
元から回答する合致ユーザまでの人脈的距離が大きいほ
ど、料金を高くするという考え方がありえる。特に、リ
クエスト元ユーザにとって直接の通信関係のないユーザ
を回答として紹介してもらえるのは、非常に有益であ
る。また、別の観点からすれば、回答された合致ユーザ
がリクエスト元から見てあまりに人脈的距離が大きい
と、あまりに関係が薄く、リクエスト元が合致ユーザに
コンタクトをとる際に「知人のつて」を説明しづらくな
ることも考えられる。したがって、人脈的距離が遠すぎ
ると、料金を低くするのが妥当と考えられる。このよう
なことを考慮すると、人脈的距離と料金の関係は、例え
ばある人脈的距離（例えば知人を４人介する程度）まで
は料金が上昇し、以降は料金が下降するような関数とし
て規定するなどが考えられる。

【００６１】また、合致ユーザとリクエスト発信元とを
結ぶパイプの、リクエストに対する合致度が高いほど、
その合致ユーザは、そのリクエストに指定された話題に
関してたくさん通信を行っているということなので、そ
の話題に関する知識も多いと想定できる。したがって、
合致度の高い合致ユーザほど、リクエスト元から見て価
値ある人材と考えられる。したがって、このようなこと
から、合致度が高いほど料金を高くするような関数を用
いて料金を決定することが妥当であると考えられる。

【００６２】料金処理システム１０８は、このような考
え方に基づき、人脈的距離と合致度の２つのパラメータ
を含んだ料金決定関数に基づき料金の値を決定する。そ
して料金処理システム１０８は、決定した料金をリクエ
スト元のユーザに対応づけて記録する。本実施形態で
は、各ユーザごとに身元保証情報を保持しているので、
この身元保証情報を用いて請求書の発行やクレジットカ
ード決済などを行うことができる。なお、支払いには、
地域限定マネーや商品券、航空会社のマイレージポイン
トなど、金銭に換算可能な各種形態の価値を利用可能と
することで、ユーザの利便性を向上させることができ
る。

【００６３】なお、人材照会リクエストでは、回答に合
致ユーザが複数含まれる場合があり、コミュニティ形成
リクエストでは回答に複数の合致ユーザが含まれること
が一般的である。このような場合は、各合致ユーザにつ
いての料金の合算額をリクエストに関する総料金として
もよいし、あるいは所定のルールに基づいた割引（２人
目の合致ユーザの料金は１人目より低くするなど）を行
ってもよい。

【００６４】以上説明したように、本実施形態のシステ
ムによれば、オープンなネットワーク環境で人脈に関す
る情報を提供するサービスが実現できる。また、人脈の
情報を形成する元となる情報を各ユーザから集める際、
各ユーザごとの情報の開示制限に応じて情報収集が行え
る。また、このサービスに関する料金を、提供する人脈
の情報に応じた妥当な形で決定することができる。

【００６５】以上の例では、リクエスト処理システム１
０６は、人脈情報サーバ１００で求められた合致ユーザ
をすべてリクエスト発信元に回答していた。

【００６６】しかしながら、ユーザよっては、ある人と
の関係を特定の人には知られたくなかったり、あるいは
ある人との関係を開示する範囲を制限したいなどの要望
があるケースがある。そのリクエスト元から合致ユーザ
までに至る人脈のうちのいずれかの２者関係がこのよう
なケースに該当する場合、その合致ユーザをリクエスト
元に知らせるのは、その２者のいずれか少なくとも一方
にとって迷惑となる。そこで、このような問題に対する
対策として、リクエスト処理システム１０６に、次のよ
うな処理機能を組み込むことが好適である。

【００６７】すなわち、この処理では、図９に示すよう
に、人脈情報サーバ１００から合致ユーザの情報を受け
取ったときに（Ｓ３８）、リクエスト処理システム１０
６が、リクエスト元からその合致ユーザまでに至る人脈
に存在する各２者関係（この２者間は直接通信がある）
ごとに、その関係がそのリクエスト元に対して開示可能
かどうかを判定し（Ｓ４４）、すべての関係が開示可能
と判定された場合にのみ（Ｓ４６の結果がＹ）、その合
致ユーザをリクエスト発信元に回答する（Ｓ４０）。い
ずれかの２者関係が開示不可と判定された場合は、リク
エスト発信元にその合致ユーザを回答することは取りや
め、従ってその合致ユーザに関する課金も行わない。人
材情報サーバ１００から受け取った合致ユーザが複数あ
る場合は、個々の合致ユーザごとに上述の判定（Ｓ４
４，Ｓ４６）を行えばよい。

【００６８】なお、各２者関係が開示可能か否かの判定
のためには、各ユーザごとに、そのユーザが持つ直接的
な２者間通信関係の各々について、それを開示したくな
い相手やそれを開示してよい範囲を示す条件などの登録
を受け付けておき、この登録情報を参照して判定するな
どの処理が可能である。また、これとは別に、リクエス
ト元から合致ユーザまでに至る人脈上の各ユーザに対
し、その人脈上での該ユーザに関する２者関係をリクエ
スト元ユーザに開示してよいかどうかをリクエスト処理
システム１０６から電子メール等で問い合わせ、これに
対してすべてのユーザから開示してよいとの回答が得ら
れた場合にのみ、その合致ユーザを回答する等の処理も
好適である。

【図面の簡単な説明】

【図１】 本発明に係るシステムの概要を示す図であ
る。

【図２】 ユーザデータベースの登録内容の一例を示す
図である。

【図３】 情報収集システムの処理手順を示す図であ
る。

【図４】 人脈情報サーバが、収集された通信情報に基
づき人脈情報を形成する手順を示す図である。

【図５】 パイプ情報のデータ構造の例を示す図であ
る。

【図６】 パイプの直列合成を説明する図である。

【図７】 パイプのたたみ込み合成を説明する図であ
る。

【図８】 リクエスト処理システムの処理手順を示す図
である。

【図９】 リクエスト処理システムの処理手順の変形例
を示す図である。

【符号の説明】

１０ 人脈情報提供サービスシステム、２０ 通信ネッ
トワーク、３０ ユーザ装置、１００ 人脈情報サー
バ、１０２ ユーザ登録システム、１０４ 情報収集シ
ステム、１０６ リクエスト処理システム、１０８ 料
金処理システム、１１０ ユーザデータベース。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 岸野 政利 東京都港区赤坂二丁目17番22号 富士ゼロ ックス株式会社内 Ｆターム(参考） 5B075 ND20 NK32

Claims (11)

【特許請求の範囲】
1. 【請求項１】 与えられる原情報を解析して各ユーザ間
   の関係を示す関係情報を生成して管理するとともに、リ
   クエストを受け付けた場合に、それら関係情報に基づ
   き、そのリクエストに合致するユーザを合致ユーザとし
   て求め、求めた合致ユーザに関する情報を回答する関係
   情報サーバと、 各ユーザ間で通信される通信情報を収集し、それら通信
   情報を前記原情報として前記関係情報サーバに供給する
   情報収集システムと、 ユーザからリクエストを受け付けて前記関係情報サーバ
   に渡し、このリクエストに対して前記関係情報サーバか
   ら得られた合致ユーザに関する情報を、そのユーザに提
   供するリクエスト処理システムと、 前記リクエスト処理システムにて受けたリクエストに対
   する前記ユーザへの情報提供に関する料金を計算し、記
   録する料金処理システムと、 を備える情報提供システム。
2. 【請求項２】 前記情報収集システムは、収集した通信
   情報に付随する利用許可情報に基づき、その通信情報が
   前記関係情報サーバに供給可能か否かを判定する判定手
   段を備え、その判定手段で供給可能と判断された通信情
   報のみを前記関係情報サーバに供給することを特徴とす
   る請求項１記載の情報提供システム。
3. 【請求項３】 各ユーザ間の関係を示す関係情報を管理
   するとともに、リクエストを受け付けた場合に、それら
   関係情報に基づき、そのリクエストに合致するユーザを
   合致ユーザとして求め、求めた合致ユーザに関する情報
   を回答する関係情報サーバと、 前記リクエストに対する前記ユーザへの情報提供に関す
   る料金を計算し、記録する料金処理システムと、 を備え、 前記料金処理システムは、そのリクエスト発信元ユーザ
   から前記合致ユーザまでの間に介在する直接通信関係を
   有する２ユーザ関係の数に基づき、前記合致ユーザに関
   する情報提供の料金を計算する計算手段、を備えること
   を特徴とする情報提供システム。
4. 【請求項４】 各ユーザ間の関係を示す関係情報を管理
   するとともに、リクエストを受け付けた場合に、それら
   関係情報に基づき、そのリクエストに合致するユーザを
   合致ユーザとして求め、求めた合致ユーザに関する情報
   を回答する関係情報サーバと、 前記リクエストに対する前記ユーザへの情報提供に関す
   る料金を計算し、記録する料金処理システムと、 を備え、 前記料金処理システムは、そのリクエスト発信元ユーザ
   と前記合致ユーザとの間の話題の繋がりと、前記リクエ
   ストと、の合致度に基づき、前記合致ユーザに関する情
   報提供の料金を計算する計算手段、を備えることを特徴
   とする情報提供システム。
5. 【請求項５】 各ユーザ間の関係を示す関係情報を管理
   するとともに、リクエストを受け付けた場合に、それら
   関係情報に基づき、そのリクエストに合致するユーザを
   合致ユーザとして求め、求めた合致ユーザに関する情報
   を回答する関係情報サーバと、 ユーザからリクエストを受け付けて前記関係情報サーバ
   に渡し、このリクエストに対して前記関係情報サーバか
   ら得られた合致ユーザに関する情報を、そのユーザに提
   供するリクエスト処理システムと、 を備え、前記リクエスト処理システムは、リクエスト元
   のユーザから前記合致ユーザに至る繋がりに介在する各
   ２ユーザ間関係についての開示可否を判定し、前記繋が
   りに介在するすべての２ユーザ間関係について開示許可
   が得られた場合に、その合致ユーザに関する情報をリク
   エスト元のユーザに提供することを特徴とする情報提供
   システム。
6. 【請求項６】 ユーザの身元保証情報と通信アドレスの
   情報の登録を受け付け、それら情報を該ユーザに対して
   付与した認証情報と関連付けてユーザデータベースに登
   録し、 通信ネットワークを介してユーザ間で通信される通信情
   報を収集し、 収集された通信情報の発信元及び宛先の通信アドレスが
   どのユーザのものかを前記ユーザデータベースを参照し
   て調べるとともに、その通信情報の話題内容を分析する
   ことにより、各ユーザ間の話題の繋がりを示す関係情報
   を生成又は更新し、 ユーザから通信ネットワークを介して情報取得リクエス
   トを受けた場合に、そのリクエストが前記ユーザデータ
   ベースに登録された正当なユーザからのものであるか否
   かを、そのリクエストの発信元の通信アドレス、又はそ
   のリクエストに伴って受け取った認証情報に基づいて判
   定し、 正当なユーザからの情報取得リクエストと判断した場合
   に、そのリクエストの内容と各関係情報の話題特性との
   合致度に応じて、そのリクエストに合致する合致ユーザ
   を求め、その合致ユーザに関する情報をリクエスト発信
   元のユーザに回答し、 情報取得リクエストに関する料金を、そのリクエストの
   発信元のユーザの身元保証情報と関連づけ可能なように
   記録する、 情報提供サービス方法。
7. 【請求項７】 収集した前記通信情報が前記関係情報の
   生成又は更新に利用できるか否かを、その通信情報に付
   随する利用許可情報に応じて判定し、利用できると判定
   された通信情報のみを利用して前記関係情報を生成又は
   更新することを特徴とする請求項６記載の情報提供サー
   ビス方法。
8. 【請求項８】 通信ネットワークを介してユーザ間で通
   信される通信情報を収集し、 収集された通信情報を分析して各ユーザ間の話題の繋が
   りを示す関係情報を生成又は更新し、 ユーザから情報取得リクエストを取得した場合に、その
   リクエストの内容と各関係情報の話題特性との合致度に
   応じて、そのリクエスト発信元のユーザに対してそのリ
   クエスト内容が示す話題に関して繋がりを有する合致ユ
   ーザを求め、その合致ユーザに関する情報をリクエスト
   発信元のユーザに回答し、 このリクエストの回答に対する料金を、その回答に含ま
   れる合致ユーザとリクエスト発信元のユーザとの間に介
   在する２ユーザ間関係の数に基づいて計算し、そのリク
   エスト発信元ユーザに課金する、 情報提供サービス方法。
9. 【請求項９】 通信ネットワークを介してユーザ間で通
   信される通信情報を収集し、 収集された通信情報を分析して各ユーザ間の話題の繋が
   りを示す関係情報を生成又は更新し、 ユーザから情報取得リクエストを取得した場合に、その
   リクエストの内容と各関係情報の話題特性との合致度に
   応じて、そのリクエスト発信元のユーザに対してそのリ
   クエスト内容が示す話題に関して繋がりを有する合致ユ
   ーザを求め、その合致ユーザに関する情報をリクエスト
   発信元のユーザに回答し、 このリクエスト回答に対する料金を、その回答に含まれ
   る合致ユーザとリクエスト発信元のユーザとの話題の繋
   がりと、そのリクエストと、の合致度に基づいて計算
   し、そのリクエスト発信元ユーザに課金する、 情報提供サービス方法。
10. 【請求項１０】 通信ネットワークを介してユーザ間で
    通信される通信情報を収集し、 収集された通信情報を分析して各ユーザ間の話題の繋が
    りを示す関係情報を生成又は更新し、 ユーザから情報取得リクエストを取得した場合に、その
    リクエストの内容と各関係情報の話題特性との合致度に
    応じて、そのリクエスト発信元のユーザに対してそのリ
    クエスト内容が示す話題に関して繋がりを有する合致ユ
    ーザを求め、 リクエスト発信元ユーザからその合致ユーザに至る繋が
    りに介在する各２ユーザ間関係についての開示可否を判
    定し、 それらすべての関係について開示可能と判定された場合
    に前記合致ユーザに関する情報を回答する、 情報提供サービス方法。
11. 【請求項１１】 各２ユーザ間関係についての開示可否
    の判定は、その関係を構成するユーザに対する開示可否
    の問い合わせの結果に基づき行うことを特徴とする請求
    項１０記載の情報提供サービス方法。