(57)【特許請求の範囲】
【請求項１】
コミュニティ利用者に電話番号を公開することなく前記コミュニティ利用者間の通話を実現するコミュニティ管理装置であって、
前記コミュニティ利用者のメンバ情報を保持するメンバ情報管理部と、
前記メンバ情報管理部から所定の利用者のメンバ情報を検索するメンバ検索部と、
第１利用者から第２利用者への発呼を代理する仮名電話部と、を備え、
前記仮名電話部は、
前記第１利用者から前記第２利用者への代理発呼要求があった場合、前記メンバ検索部を通じて前記メンバ情報管理部から前記第１利用者のコミュニティにおける過去の情報発信履歴を含むメンバ情報を取得し、取得した前記第１利用者のメンバ情報を前記第２利用者に送信し、前記第２利用者から発呼許可を示す応答があった場合に、前記第１利用者を発信者として前記第２利用者に発呼を行う、コミュニティ管理装置。
【請求項２】
前記仮名電話部は、前記第２利用者が複数人であって、前記第１利用者と、前記第２利用者のいずれかの利用者との間で通話が行われた場合に、前記第２利用者のうち、前記第１利用者と通話を行わなかった利用者に対して、応答不要を示すメッセージを送信する、請求項１に記載のコミュニティ管理装置。
【請求項３】
前記メンバ検索部は、前記第１利用者からの検索条件に応じて、前記メンバ情報管理部から前記第２利用者を選択する、請求項１又は２に記載のコミュニティ管理装置。
【請求項４】
前記仮名電話部は、前記第２利用者から着呼拒否を示す応答があった場合に、一定時間前記第１利用者への呼出音の提供を継続する、請求項１乃至３のいずれか一項に記載のコミュニティ管理装置。
【請求項５】
前記メンバ検索部は、前記第１利用者からの検索条件に応じて、前記メンバ情報管理部から前記第２利用者を選択する場合、選択した前記第２利用者のメンバ情報が、前記第２利用者に通話意思のないことを示す場合、前記第２利用者を選択結果から除外する、請求項３又は４に記載のコミュニティ管理装置。
【請求項６】
コミュニティ利用者に電話番号を公開することなく前記コミュニティ利用者間の通話を実現するコミュニティ管理装置による通話方法であって、
前記コミュニティ管理装置の処理手順は、
前記第１利用者から前記第２利用者への代理発呼要求があった場合、前記第１利用者のコミュニティにおける過去の情報発信履歴を含むメンバ情報を取得するステップと、
取得した前記第１利用者のメンバ情報を前記第２利用者に送信するステップと、
前記第２利用者から発呼許可を示す応答があった場合に、前記第１利用者を発信者として前記第２利用者に発呼を行うステップと、を含む通話方法。
【請求項７】
前記第２利用者が複数人であって、前記第１利用者と、前記第２利用者のいずれかの利用者との間で通話が行われた場合に、前記第２利用者のうち、前記第１利用者と通話を行わなかった利用者に対して、応答不要を示すメッセージを送信するステップを含む、請求項６に記載の通話方法。
【請求項８】
前記第１利用者からの検索条件に応じて、前記第２利用者を選択するステップを含む、請求項６又は７に記載の通話方法。
【請求項９】
前記第２利用者から発呼拒否を示す応答があった場合に、一定時間前記第１利用者への呼出音の提供を継続するステップを含む、請求項６乃至８のいずれか一項に記載の通話方法。
【請求項１０】
前記第１利用者からの検索条件に応じて、前記メンバ情報管理部から前記第２利用者を選択する場合、選択した前記第２利用者のメンバ情報が、前記第２利用者に通話意思のないことを示す場合、前記第２利用者を選択結果から除外するステップを含む、請求項８又は９に記載の通話方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、コミュニティ管理装置及び通話方法に関し、特に、コミュニティ利用者に電話番号を公開することなくコミュニティ利用者間の通話を可能にするコミュニティ管理装置及び通話方法に関する。
【背景技術】
【０００２】
ＳＮＳ（Social Networking Service）等のコミュニティにおけるコミュニケーション手段は、E-Mailをはじめとしたメッセージを用いることが多い。しかし、緊急の用件や込み入った用件を解決するためのコミュニケーション手段としては、メッセージよりも電話のようなリアルタイムコミュニケーションの方が適している。近年Group Me（非特許文献１）、Fast Society（非特許文献２）、モバツイWho’s Who（非特許文献３）のように、コミュニティに登録する情報として電話番号を用いるサービスが出現している。このようなサービスでは、コミュニティのコミュニケーション手段として電話を用いることができ、コミュニティ内でのリアルタイムコミュニケーションが可能となる。しかし既存のサービスでは、コミュニティ内で電話をコミュニケーション手段として用いることに対する問題に対して十分な配慮がなされていない。例えば、通常の連絡先を相手に知らせることなくメッセージを交換する方法としては、privango（非特許文献４）が知られている。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】"Group me"、［online］、［平成23年1月10日検索］、インターネット〈http://groupme.com/〉
【非特許文献２】"Fast Society"、［online］、［平成23年1月10日検索］、インターネット〈http://m.fastsociety.com/〉
【非特許文献３】Who's Who、 "マインドスコープ、ツイッターと連動したWebサービス「モバツイ Who's Who!?」の提供を開始"、［online］、［平成23年1月10日検索］、インターネット〈http://www.mindscope.co.jp/news-2010122001.html〉
【非特許文献４】高橋克己、外２名、「条件付きＩＤ技術privangoを用いた迷惑メール対策」、ＮＴＴ技術ジャーナル、２００５年１月、ｐｐ．３６−３９
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、非特許文献４の技術は、有効期限などの利用条件を設定したメールアドレスによって通常の連絡先を相手に知らせることなくメッセージを交換することができるが、電話のようなリアルタイムコミュニケーションに関する検討は行われていない。
【０００５】
したがって、かかる点に鑑みてなされた本発明の目的は、コミュニティ利用者に電話番号を公開することなく、即ち、誰でもいつでもリアルタイムコミュニケーションが可能となる連絡先を公開することなく、コミュニティ利用者間の属性（互いにコミュニティに属しているか等）および状態（互いにリアルタイムコミュニケーションが開始できるか等）の一致に基づいた通話を可能にするコミュニティ管理装置及び通話方法を提供することにある。
【課題を解決するための手段】
【０００６】
本発明に係るコミュニティ管理装置は、コミュニティ利用者に電話番号を公開することなく前記コミュニティ利用者間の通話を実現するコミュニティ管理装置であって、前記コミュニティ利用者のメンバ情報を保持するメンバ情報管理部と、前記メンバ情報管理部から所定の利用者のメンバ情報を検索するメンバ検索部と、第１利用者から第２利用者への発呼を代理する仮名電話部と、を備え、前記仮名電話部は、前記第１利用者から前記第２利用者への代理発呼要求があった場合、前記メンバ検索部を通じて前記メンバ情報管理部から前記第１利用者のコミュニティにおける過去の情報発信履歴を含むメンバ情報を取得し、取得した前記第１利用者のメンバ情報を前記第２利用者に送信し、前記第２利用者から発呼許可を示す応答があった場合に、前記第１利用者を発信者として前記第２利用者に発呼を行うものである。
【０００７】
また、本発明に係る通話方法は、コミュニティ利用者に電話番号を公開することなく前記コミュニティ利用者間の通話を実現するコミュニティ管理装置による通話方法であって、前記コミュニティ管理装置の処理手順は、前記第１利用者から前記第２利用者への代理発呼要求があった場合、前記第１利用者のコミュニティにおける過去の情報発信履歴を含むメンバ情報を取得するステップと、取得した前記第１利用者のメンバ情報を前記第２利用者に送信するステップと、前記第２利用者から発呼許可を示す応答があった場合に、前記第１利用者を発信者として前記第２利用者に発呼を行うステップと、を含むものである。
【発明の効果】
【０００８】
本発明に係るコミュニティ管理装置及び通話方法によれば、コミュニティ利用者に電話番号を公開することなくコミュニティ利用者間の通話を可能にすることができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、本発明の一実施形態に係るコミュニティ管理装置を含むシステムの概要を示す図である。
【図２】図２は、本発明の一実施形態に係るコミュニティ管理装置の機能ブロックを示す図である。
【図３】図３は、本発明の一実施形態に係るコミュニティ管理装置の動作シーケンスを示す図である。
【図４】図４は、本発明の一実施形態に係るコミュニティ管理装置の動作シーケンスを示す図である。
【図５】図５は、本発明の一実施形態に係るコミュニティ管理装置の動作シーケンスを示す図である。
【図６】図６は、本発明の一実施形態に係るコミュニティ管理装置の動作シーケンスを示す図である。
【図７】図７は、本発明の一実施形態に係るコミュニティ管理装置の動作シーケンスを示す図である。
【図８】図８は、本発明の一実施形態に係るコミュニティ管理装置の動作シーケンスを示す図である。
【図９】図９は、本発明の一実施形態に係るコミュニティ管理装置の動作シーケンスを示す図である。
【図１０】図１０は、本発明の一実施形態に係るコミュニティ管理装置の動作シーケンスを示す図である。
【図１１】図１１は、本発明の一実施形態に係るコミュニティ管理装置の動作シーケンスを示す図である。
【発明を実施するための形態】
【００１０】
まず、本発明に係るコミュニティ管理装置１で実現すべき要件を以下に述べる。
【００１１】
例えば、既存のサービスでは、コミュニティ内の不特定多数に自分の電話番号を公開する必要がある。そのため悪意のあるユーザによる電話番号の流出、イタズラ電話等の問題が起こることが懸念される。そこで、コミュニティ管理装置１は、お互いの電話番号を秘匿したまま電話をすることを実現することが必要となる。
【００１２】
また、既存のサービスでは、電話を着信した(以下電話の着信を着呼と呼ぶ)際、要件と発呼側の素性がわからないので着呼を拒否する場合があり、電話を用いたリアルタイムコミュニケーションが円滑に行われないことが懸念される。このため、コミュニティ管理装置１は、電話の用件と通話相手の素性について、着呼者が通話前に把握することができるようにすることが好ましい。
【００１３】
また、既存のサービスでは、無駄な折り返しが発生する場合がある。例えば、ある問題を解決する際にコミュニティ内のあるメンバへ発呼したが応答しなかったために別のメンバと電話をし、問題が解決する場合がある。この場合、はじめに発呼を試み呼び出したが着呼に応答できなかったメンバは問題が解決したことを知らないため、無駄な折り返し電話を試みてしまう。このため、コミュニティ管理装置１は、用件終了時に、発呼を行い呼び出したが着呼に応答できなかったメンバに対して用件終了の旨を知らせることが望ましい。
【００１４】
また、既存のサービスでは、コミュニティ内から、自分が電話をする目的を達成するのに適している相手を探す事が難しい。例えば、電話を発信する人や利用シーンによって誰に電話をかける(以下発呼と呼ぶ)べきか判断に困る場合がある。このため、コミュニティ管理装置１は、発信者自身が通話相手を特定することなく、適した相手に発呼することができるようにすることが好ましい。
【００１５】
また、既存のサービスでは、着呼を拒否したことが発呼側に伝わってしまうという問題がある。例えば、友達や近所の人の様な親密なコミュニティにおいては、着呼を拒否したことが発呼側に伝わることでメンバ間の友好関係・信頼関係を損ねてしまうことが懸念される。或いは、関係を損ねないよう着呼に応答する必要が生じてしまう。このため、コミュニティ管理装置１は、着呼を拒否したことを発呼側に気づかせないことが望ましい。
【００１６】
また、既存のサービスでは、着呼側が着呼に応答する意志がない時でも無関係に着呼してしまう。このため、コミュニティ管理装置１は、着呼側のコンテキスト情報を基に発呼・着呼を制御することができることが望ましい。
【００１７】
以降、諸図面を参照しながら、本発明の実施態様を詳細に説明する。
【００１８】
図１は、本発明の一実施形態に係るコミュニティ管理装置を含むシステムの概要を示す図である。メンバＡとメンバＢはそれぞれコミュニティ管理装置１の管理するコミュニティに登録している。メンバＡとメンバＢはお互いに面識はなく、お互いの電話番号も把握していない。本実施形態では、メンバＡが、コミュニティ管理装置１を介して、電話番号を知らないメンバＢに対して通話を試みるものとする。
【００１９】
図２は、本発明の一実施形態に係るコミュニティ管理装置の機能ブロックを示す図である。コミュニティ管理装置１は、メンバ登録部１１と、発信受信部１２と、メンバ情報管理部１３と、メンバ検索部１４と、仮名電話部１５と、レーティング部１６とを備えている。なお、以下の説明では、電話の発信を「発呼」、電話の着信を「着呼」、相手と会話可能な状態のことを「通話」と呼び、発呼・着呼・通話の一連の動作を「電話を行う」と称する。
【００２０】
メンバ登録部１１は、利用者からの入力を受け、コミュニティ利用者のメンバ情報をメンバ情報管理部１３に登録する。登録に用いる情報は仮名、プロフィール、コンテキスト情報、電話番号である。登録方法としては、Ｗｅｂインターフェースを用いて利用者が登録する方法、位置情報を利用し自動的に登録する方法、ＮＦＣ(Near Field Communication)を用いて登録する方法等が考えられる。
【００２１】
発信受信部１２は、メンバがコミュニティへ情報を発信したり、コミュニティから情報受信したりすることを可能とする。メンバが発信した情報は、発信受信部１２によってメンバ情報管理部１３に送信され、メンバ情報管理部１３により保存される。
【００２２】
メンバ情報管理部１３は、コミュニティを構成する利用者のメンバ情報を管理する。メンバ情報管理部１３は、メンバ登録部１１、発信受信部１２より渡されたメンバ情報を保存し、必要に応じて他の機能ブロックへ提供する。メンバ情報として登録される情報は、仮名、メンバのプロフィール、過去の情報発信履歴、電話番号、コンテキスト情報、コミュニティにおけるメンバの評価などである。ここで仮名とは、メンバがコミュニティ内で用いるニックネームであり、登録時にメンバが指定する場合と、メンバ登録部１１が自動的に付与する場合が考えられる。プロフィールとは、コミュニティにおけるメンバの属性情報である。この情報はコミュニティ内で共有され、検索時や着呼時に参照される。例えば、年齢・性別・職業・居住地・出身地・血液型・趣味等が考えられる。過去の情報発信履歴とは、メンバがコミュニティ内で発信した情報の履歴である。この情報はコミュニティ内で共有され、検索時や着呼時に参照される。例えば、過去に発信したメッセージの履歴や過去に参照したＷｅｂページの履歴等が考えられる。電話番号とは、メンバとの通話が可能となる端末の電話番号である。この情報はメンバ検索部１４や仮名電話部１５が参照することができるが、コミュニティのメンバは参照することが出来ない。コンテキスト情報とは、メンバの現在の状況を示す情報である。例えば、現在コミュニティにチェックインしているか否か、またはチェックイン中の状態(Online、Offline、busy、away等)、通話できるかといったプレゼンス情報、GPS等を用いて取得することのできるメンバの位置情報等が考えられる。この情報はメンバ検索部１４や仮名電話部１５が参照することができるが、コミュニティのメンバは参照することが出来ない。メンバの評価とはコミュニティにおけるメンバがどのような貢献をしてきたかを表す指標である。評価は各メンバに１つだけ設定する場合と、発呼側・着呼側等、役割毎に設定する場合が考えられる。また、コミュニティにおける絶対評価と、メンバによって異なる相対評価が考えられる。この情報はコミュニティ内で共有され、検索時や着呼時に参照される。
【００２３】
メンバ検索部１４は、コミュニティから条件に一致する他の利用者を検索することが出来る機能である。これは、メンバ検索部１４は、メンバ情報管理部１３に保存されているメンバ情報を検索することで実現する。この際に、利用者は検索条件に重みをつけることができ、メンバ検索部１４は、検索条件と重みとにより検索を行うことができる。また、メンバ検索部１４は、検索結果に含まれるメンバに対して、代理発呼するように仮名電話部１５に依頼することもできる。なお、代理発呼とは、発呼者（例えばメンバＡ）の代わりに、仮名電話部１５が、着呼先（例えばメンバＢ）に発呼を行うことである。
【００２４】
仮名電話部１５は、コミュニティの利用者またはメンバ検索部１４により代理発呼依頼を受けメンバに発呼することで、メンバ間での通話を実現する機能である。まず、仮名電話部１５は、コミュニティの利用者がお互いに電話番号を知らせずに電話を行うことが出来る機能を備える。これによりコミュニティにおける、相手に面識がなく、信頼関係が構築されていないメンバと電話をする際の抵抗感を低減することができる。また、仮名電話部１５は、発呼側が着呼側にメッセージを送る機能を備える。これにより発呼側が電話の用件等を発呼とともに送ることができ、着呼側はどのような意図の電話であるかを確認することができる。この機能はSMS（Short Message Service）やSIP Message Methodを用いて実現することができる。また、仮名電話部１５は、着呼時に着呼側が発呼側の情報を参照することができる機能を備える。参照できる情報はメンバのプロフィール、過去の情報発信履歴、コミュニティにおけるメンバの評価である。これにより着呼側が着呼を受けるかどうかを判断することができる。
【００２５】
さらに、仮名電話部１５は、着呼側が着呼を拒否した場合でも発呼側に拒否されたことを気づかせない機能を有する。例えば、仮名電話部１５は、着呼側が着呼を拒否した場合でも、発呼側の呼び出しを継続し、発呼側に拒否されたのか、不在で出ることができないのか判別できない状態とすることができる。これにより発呼側、着呼側共に気兼ねなく発呼と着呼拒否をすることができ、コミュニティにおいて活発なコミュニケーションが期待できる。
【００２６】
レーティング部１６は、通話終了後、発呼・着呼側双方がお互いの評価を行う機能である。これによりコミュニティにおけるメンバの評価を設定することができ、別の機会における着呼を受け入れるかを決定する際等に参照することができる。
【００２７】
これ以降、図３〜図１１を用いて、コミュニティ管理装置１の動作シーケンスを説明する。なお、以下の例においては、図３〜図９においては、メンバＡ及びメンバＢの二者間の動作シーケンスを説明し、図１０及び図１１においては、メンバＡ、メンバＢ及びメンバＣの三者間の動作シーケンスを説明する。
【００２８】
図３は、メンバ登録処理のシーケンス図である。メンバＡがメンバ登録操作を行うと（ステップＳ１０１）、メンバ登録部１１は、登録情報をメンバ情報管理部１３に通知する（ステップＳ１０２）。メンバ情報管理部１３は、登録情報通知を受けると、メンバＡの情報を登録する（ステップＳ１０３）。ここで、登録する情報は、コミュニティ内での仮名とプロフィール、電話番号、コンテキスト情報である。この際、自分をメンバとして登録する方法として、Ｗｅｂインターフェースを用いてメンバが情報を自ら登録する方法や、ＧＰＳ等の位置測定機能があり、予め登録情報を持った携帯端末を用いて、ある場所に行くと自動的に登録するといった位置情報を利用する方法や、予め登録情報を持ったＮＦＣ(Near Field Communication)機能を持ったカードや携帯端末を用いて登録する方法等が考えられる。なお、コミュニティに登録する情報におけるコンテキスト情報は逐次更新することができる。その方法としてはメンバが自らコンテキスト情報を登録する場合、携帯端末等を用いて位置が変化したら位置情報を自動的に登録する場合、コンテキスト推定技術を用いて自動的に登録する場合等が考えられる。
【００２９】
例えば、メンバＡと同様にメンバＢがメンバ情報の登録を行うと、メンバ情報管理部１３は、表１に示すメンバ情報を持つことになる。以下の表１に登録する情報の項目では該当する情報がない場合を空欄で表現している。なお実装上ではnull値等が登録される。
【００３０】
【表１】
0005693993.tif 000002
【００３１】
図４は、発信受信処理のシーケンス図である。上記の通り、メンバＡ及びメンバＢは、発信受信部１２を用いて、コミュニティにて共有する情報の発信を行うことができる。メンバＡが情報を発信すると（ステップＳ２０１）、発信情報部１２はメンバ情報管理部１３に発信情報を通知する（ステップＳ２０２）。メンバ情報管理部１３は、発信情報通知を受けると、メンバＡの発信履歴を更新する（ステップＳ２０３）。また、メンバＢが情報を発信すると（ステップＳ２０４）、発信情報部１２はメンバ情報管理部１３に発信情報を通知する（ステップＳ２０５）。メンバ情報管理部１３は、発信情報通知を受けると、メンバＢの発信履歴を更新する（ステップＳ２０６）。このとき、メンバ情報管理部１３は、発信受信部１２を通じて、メンバＢの発信情報を予めコミュニティに登録しているメンバＡに転送することができる（ステップＳ２０７、２０８）。
【００３２】
例えば、メンバＡがステップＳ２０１において「このURLが有用です。http://www.ntt.co.jp」という情報を発信し、メンバＢがステップＳ２０４において「このコミュニティに関係ある研究をしています」という情報を発信した場合には、メンバ情報管理部１３は、表２のように、メンバ情報の発信履歴を更新する。
【００３３】
【表２】
0005693993.tif 000003
【００３４】
図５は、メンバ検索処理のシーケンス図である。なお、メンバＡがメンバＢの発信情報を受信し、自らメンバＢを見つける場合には、メンバ検索処理は必要ではない。メンバＡは、メンバ検索部１４を用いることにより、条件を指定してコミュニティ内から一致するメンバを検索することができる。まず、メンバＡは、メンバ検索部１４を用いて、複数の検索条件の組み合わせと各検索条件の重みを指定し、コミュニティからメンバ検索を試みる（ステップＳ３０１）。メンバ検索部１４は、検索条件をメンバ情報管理部１３に通知する（ステップＳ３０２）。メンバ情報管理部１３は、検索条件に沿ってメンバ検索を行い、検索結果をメンバ検索部１４に通知する（ステップＳ３０３）。この際に、メンバ検索部１４は、検索したメンバのコンテキスト情報に、コミュニティにチェクインしていない、通話を拒否している等の情報があり、明らかに通話する事ができない（通話意思のない）ことが判明している場合は、当該メンバを検索結果から除外する。その後、メンバ検索部１４は、検索結果をメンバＡに通知する（ステップＳ３０４）。なお、メンバ検索部１４がメンバＡに通知する検索結果は、通常の公開情報であって、電話番号といった秘密情報は含まれない。例えば、メンバ検索部１４は、通話できることが明らかなメンバ（例えばメンバＢ）についても、電話番号を検索結果に含めない。メンバＡが設定する検索条件としては、親密度、コミュニティでの評価、プレゼンス情報、位置情報、プロフィール、コミュニティでの役割等が考えられる。ここで親密度は、メンバ間の通信頻度や同じコミュニティに参加している数、いつも一緒に行動しているため位置情報の履歴が似ている等により決定することができる。また、検索の条件や重みを決定する際に、メンバが手動で設定する場合や、利用シーンごとに標準の設定を提示したり、コミュニティにてよく使われる設定を提示したりする等の方法により、入力の省力化を図ることも考えられる。
【００３５】
例えば、メンバＡがステップＳ３０１において検索条件として「３０代、研究員」という条件を設定し、メンバ検索部１４を通じて検索を行うと、メンバ検情報管理部１３は、表２のメンバ情報を基にメンバＢを検索し、メンバＡには、メンバＢの公開情報（例えば、仮名、プロフィール、下記の発信履歴、コミュニティにおける評価）が通知される。検索の結果複数のメンバの情報が通知された場合には、メンバＡは複数のメンバの過去の情報発信履歴やコミュニティにおける評価等を参照し、メンバＢを指定することができる。
【００３６】
図６は、仮名電話部１５による代理発呼処理のシーケンス図である。メンバＡは、仮名電話部１５を用いてメンバＢにメッセージを送信することができる。まずメンバＡはメンバＢに電話の用件をメッセージで送信するように仮名電話部１５に依頼する（ステップＳ４０１）。依頼を受けた仮名電話部１５は、メンバＢの電話番号を、メンバ検索部１４を用いてメンバ情報管理部１３に問い合わせる（ステップＳ４０２、Ｓ４０３）。メンバ情報管理部１３は、メンバ検索部１４を介してメンバＢの電話番号を仮名電話部１５に伝える（ステップＳ４０４、Ｓ４０５）。その後、仮名電話部１５は、メッセージの送信者をメンバＡとしてメンバＢにメッセージを送信する（ステップＳ４０６）。メッセージ送信後、メンバＡは、メンバＢを指定して仮名電話部１５に代理発呼を依頼する（ステップＳ４０７）。
【００３７】
例えば、メンバＡは、ステップＳ４０１において、メンバＢに対して「研究について教えてください」というメッセージを送信することができる。また、メンバＢは、ステップＳ４０６において送信者をメンバＡとしてメッセージを受け取るが、メンバＡの電話番号を取得することはない。これにより、メンバＡは、電話の用件のメッセージをお互いの電話番号を知らせることなくメンバＢに送信することが可能となり、メンバＢは、メッセージを受けて通話を開始するか否かを決定する指針とすることができる。なお、メッセージを送信する手段としてSMS、E-Mail、SIP Message methodを用いることが考えられる。
【００３８】
図７は、図６から続く仮名電話部１５による代理発呼処理のシーケンス図である。仮名電話部１５は、メンバＡから代理発呼の要求があると、メンバＡの情報要求を行う（ステップＳ５０１）。仮名電話部１５は、メンバ検索部１４を用いてメンバ情報管理部１３にメンバＡの情報を問い合わせる（ステップＳ５０２）。メンバ情報管理部１３は、メンバ検索部１４を介してメンバＡの情報を仮名電話部１５に通知する（ステップＳ５０３、Ｓ５０４）。なお、ここで通知されるメンバＡの情報には、メンバＡの電話番号は含まれない。仮名電話部１５は取得したメンバＡの情報をメンバＢに通知し、メンバＢはコミュニティにおけるメンバＡの情報を参照し、着呼を受け入れるか否かを決めるための指針とすることができる（ステップＳ５０５）。メンバＢは、着呼に応じる場合、仮名電話部１５に発呼許可を示す応答メッセージを送信する（ステップＳ５０６）。仮名電話部１５は、メンバＢから発呼許可を示す応答メッセージを受けると、メンバＢに対して、発信者をメンバＡとして発呼を行う（ステップＳ５０７）。その後、仮名電話部１５はメンバＡ及びメンバＢ間の通話を確立し（ステップＳ５０８）、メンバＡ及びメンバＢは互いに通話することができる（ステップＳ５０９）。
【００３９】
図８は、メンバＢが着呼を拒否した場合のシーケンス図である。ステップＳ５１１からステップＳ５１５までは、図８のステップＳ５０１からステップＳ５０５と同様の処理が行われる。メンバＢは、ステップＳ５１５において送信されたコミュニティにおけるメンバＡの情報を参照し、着呼を拒否することができる（ステップＳ５１６）。メンバＢが着呼を拒否した場合、仮名電話部１５はメンバＡからの呼び出しをすぐには切断せず、一定時間メンバＡへの呼び出し音を継続する（ステップＳ５１７）。そして、仮名電話部１５は、一定時間経過後に通話を確立出来なかった旨をメンバＡに通知する（ステップＳ５１８）。これにより、メンバＡは、メンバＢが明示的に着呼を拒否したのか、不在等の理由で出ることができなかったのかを判断することができないので、着呼を拒否したことをメンバＡに気づかせないことができる。
【００４０】
図９は、メンバのレーティング処理のシーケンス図である。通話終了後、メンバＡは、レーティング部１６を用いてメンバＢの評価を行う（ステップＳ６０１）。レーティング部１６は、評価情報をメンバ情報管理部１３に通知し（ステップＳ６０２）、メンバ情報管理部１３は、メンバＢの評価情報を更新する（ステップＳ６０３）。同様に、メンバＢは、レーティング部１６を用いてメンバＡの評価を行う（ステップＳ６０４）。レーティング部１６は、評価情報をメンバ情報管理部１３に通知し（ステップＳ６０５）、メンバ情報管理部１３は、メンバＡの評価情報を更新する（ステップＳ６０６）。これによりコミュニティにおけるメンバの評価を設定することができる。なお、コミュニティにおける評価は各メンバに１つだけ設定する場合と、発呼側・着呼側等、役割毎に設定する場合が考えられる。
【００４１】
例えば、メンバＡは、ステップＳ６０１においてメンバＢを５と評価し、メンバＢは、ステップＳ６０４において、メンバＡを３と評価するとする。この場合、メンバ情報管理部１３のメンバ情報のうち、コミュニティにおける評価の列は、表３の通り更新される。
【００４２】
【表３】
0005693993.tif 000004
【００４３】
図３〜９の動作シーケンスでは、メンバＡ及びメンバＢの二者間の処理であったが、例えば、利用者Ａの検索条件に応じてメンバ検索部１４が複数のメンバを抽出した場合など、利用者Ａからの発呼が複数のメンバに対して行われる場合も考えられる。複数人に対して発呼をする場合、以下の２つの方法が考えられる。
【００４４】
１番目の方法は、まず、メンバＡは、図５のシーケンスの通り、メンバ検索部１４を用いて電話を行うメンバ候補を複数人見つける。次に、メンバＡは、見つけた複数の候補の中から、発呼を行うメンバの優先順序を決定する。そして図６のシーケンスにより、優先順序の高いメンバから順次発呼を行う。この際発呼を行う優先順序はメンバ自らが手動で決定する場合や、検索条件によりソートすることで自動的に決定する場合が考えられる。
【００４５】
２番目の方法は、メンバＡが検索条件にマッチする複数のメンバの中から特定のメンバを指定するのでもなく、複数のメンバの優先順序を手動で決定するのでもなく、検索条件にマッチした複数のメンバの中のいずれかに発呼する場合である。図１０は、当該処理のシーケンスを示す図である。
【００４６】
まず、メンバＡは、メンバ検索部１４を用いて、複数の検索条件の組み合わせと各検索条件の重みを指定し、コミュニティからメンバ検索を試みる（ステップＳ７０１）。メンバ検索部１４は、検索条件をメンバ情報管理部１３に通知する（ステップＳ７０２）。メンバ情報管理部１３は、検索条件に沿ってメンバ検索を行い、検索結果をメンバ検索部１４に通知する（ステップＳ７０３）。なお、メンバ情報管理部１３は、コンテキスト情報により通話することが判明しているメンバは候補から外す。
【００４７】
メンバＡは、メンバ検索部１４にメンバ検索を依頼するだけではなく、検索条件に合うメンバのいずれかに発呼するようメンバ検索部１４に依頼する（ステップＳ７０４）。この場合、検索結果にはメンバＢ及びメンバＣが含まれており、メンバ検索部１４は、仮名電話部１５にメンバＢ及びメンバＣへの発呼を依頼する。なお、発呼をする順序はメンバＡが指定した条件に、より合致する順序とすることができる。まず仮名電話部１５は、メンバＢに発呼を行い（ステップＳ７０６）、メンバＢが発呼に応答しないまたは着呼を拒否した場合、仮名電話部１５はすぐにメンバＣに発呼を行う（ステップＳ７０７）。メンバＣが着呼に応答した場合、仮名電話部１５は、メンバＡとメンバＣとの通話を確立し（ステップＳ７０９）、メンバＡ及びメンバＣ間の通話が可能となる（ステップＳ７１０）。
【００４８】
以上により、三者間においても、メンバＡは匿名性を確保しつつ、電話を行う目的の合う、現在通話可能なメンバと電話を行うことができる。また自ら発呼を続ける必要がないので通話相手をより早く見つけることができる。
【００４９】
図１１は、レーティング処理のシーケンス図である。図１０に示す通話終了後、メンバＡは、レーティング部１６を用いてメンバＣの評価を行う（ステップＳ８０１）。レーティング部１６は、評価情報をメンバ情報管理部１３に通知し（ステップＳ８０２）、メンバ情報管理部１３は、メンバＣの評価情報を更新する（ステップＳ８０３）。同様に、メンバＣは、レーティング部１６を用いてメンバＡの評価を行う（ステップＳ８０４）。レーティング部１６は、評価情報をメンバ情報管理部１３に通知し（ステップＳ８０５）、メンバ情報管理部１３は、メンバＡの評価情報を更新する（ステップＳ８０６）。これによりコミュニティにおけるメンバの評価を設定することができる。
【００５０】
通話終了後、メンバＡは、仮名電話部１５を用いて、代理発呼に応答しなかったメンバＢへ電話の用件は解決したという旨の応答不要を示すメッセージを送信する（ステップＳ８０７、Ｓ８０８）。これによりメンバＢからの無駄な折り返し等を防ぐことができる。
【００５１】
本実施形態によれば、仮名電話部１５は、メンバＡ（第１利用者）からメンバＢ（第２利用者）への代理発呼要求があった場合、メンバ検索部１４を通じてメンバ情報管理部１３からメンバＡのメンバ情報を取得し、取得したメンバＡのメンバ情報をメンバＢに送信し、メンバＢから発呼許可を示す応答があった場合に、メンバＡを発信者としてメンバＢに発呼を行う。これにより、コミュニティ利用者に電話番号を公開することなくコミュニティ利用者間の通話を可能にすることができる。また、電話の用件と通話相手の素性について、着呼者は通話前に把握することが可能になる。
【００５２】
また、仮名電話部１５は、第２利用者が複数人（メンバＢ、メンバＣ）であって、メンバＡと、メンバＢ及びメンバＣのいずれかの利用者（メンバＣ）との間で通話が行われた場合に、第２利用者（メンバＢ、メンバＣ）のうち、メンバＡと通話を行わなかったメンバＢに対して、応答不要を示すメッセージを送信する。これにより、用件終了時に、発呼を行い呼び出したが着呼に応答できなかったメンバに対して用件終了の旨を知らせることができる。用件終了時に過去に発呼を行ったが応答しなかったメンバに対してメッセージを送信することで、用件を完了した旨を通知し余計な折り返し電話を防ぐことができる。
【００５３】
また、メンバ検索部１４は、メンバＡ（第１利用者）からの検索条件に応じて、メンバ情報管理部１３からメンバＢ（第２利用者）を選択する。これにより、発信者自身が通話相手を特定することなし、適した相手に発呼することができる。メンバ検索部１４を用いて、用件(電話の目的)によってコミュニティのメンバを検索することにより、該当するメンバを複数指定し、優先順序の高い順から順次発呼することが可能になる。
【００５４】
また、仮名電話部１５は、メンバＢ（第２利用者）から着呼拒否を示す応答があった場合に、一定時間メンバＡ（第１利用者）への呼出音の提供を継続する。これにより、これにより発呼側は着呼側が明示的に着呼を拒否したのか、不在等の理由で出ることができなかったのかを判断することができず、着呼を拒否したことが発呼者に気づかれない。または、発呼側が自ら発呼を行うのではなく、発呼側が指定する条件に合致する着呼側に対してシステムが自動的に発呼を行ない、通話が可能な着呼側のみをメンバに通知することができる。これにより発呼側は誰が着呼を拒否したのかがわからない。
【００５５】
また、メンバ検索部１４は、メンバＡ（第１利用者）からの検索条件に応じて、メンバ情報管理部１３から第２利用者を選択する場合、選択した第２利用者のメンバ情報が、第２利用者に通話意思のないことを示す場合、第２利用者を選択結果から除外する。これにより、着呼側のコンテキスト情報を基に発呼・着呼を制御することができる。つまり、メンバ検索部１４がコンテキスト情報(プレゼンス情報・位置情報等)を参照し、通話しない意志を表明している場合は検索結果に候補を表示しないことで、発呼・着呼が起こらないようにすることができる。
【００５６】
本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各部材、各手段、各ステップなどに含まれる部などは論理的に矛盾しないように再配置可能であり、複数の手段やステップなどを１つに組み合わせたり、或いは分割したりすることが可能である。
【符号の説明】
【００５７】
１  コミュニティ管理装置
１１  メンバ登録部
１２  発信受信部
１３  メンバ情報管理部
１４  メンバ検索部
１５  仮名電話部
１６  レーティング部
【図１】
0005693993.tif 000005
【図２】
0005693993.tif 000006
【図３】
0005693993.tif 000007
【図４】
0005693993.tif 000008
【図５】
0005693993.tif 000009
【図６】
0005693993.tif 000010
【図７】
0005693993.tif 000011
【図８】
0005693993.tif 000012
【図９】
0005693993.tif 000013
【図１０】
0005693993.tif 000014
【図１１】
0005693993.tif 000015