コミュニティ利用者に電話番号を公開することなく前記コミュニティ利用者間の通話を実現するコミュニティ管理装置であって、前記コミュニティ利用者のメンバ情報を保持するメンバ情報管理部と、前記メンバ情報管理部から所定の利用者のメンバ情報を検索するメンバ検索部と、第1利用者から第2利用者への発呼を代理する仮名電話部と、を備え、前記仮名電話部は、前記第1利用者から前記第2利用者への代理発呼要求があった場合、前記メンバ検索部を通じて前記メンバ情報管理部から前記第1利用者のメンバ情報を取得し、取得した前記第1利用者のメンバ情報を前記第2利用者に送信し、前記第2利用者から発呼許可を示す応答があった場合に、前記第1利用者を発信者として前記第2利用者に発呼を行う、コミュニティ管理装置。前記仮名電話部は、前記第2利用者が複数人であって、前記第1利用者と、前記第2利用者のいずれかの利用者との間で通話が行われた場合に、前記第2利用者のうち、前記第1利用者と通話を行わなかった利用者に対して、応答不要を示すメッセージを送信する、請求項1に記載のコミュニティ管理装置。前記メンバ検索部は、前記第1利用者からの検索条件に応じて、前記メンバ情報管理部から前記第2利用者を選択する、請求項1又は2に記載のコミュニティ管理装置。前記仮名電話部は、前記第2利用者から着呼拒否を示す応答があった場合に、一定時間前記第1利用者への呼出音の提供を継続する、請求項1乃至3のいずれか一項に記載のコミュニティ管理装置。前記メンバ検索部は、前記第1利用者からの検索条件に応じて、前記メンバ情報管理部から前記第2利用者を選択する場合、選択した前記第2利用者のメンバ情報が、前記第2利用者に通話意思のないことを示す場合、前記第2利用者を選択結果から除外する、請求項3又は4に記載のコミュニティ管理装置。コミュニティ利用者に電話番号を公開することなく前記コミュニティ利用者間の通話を実現するコミュニティ管理装置による通話方法であって、前記コミュニティ管理装置の処理手順は、前記第1利用者から前記第2利用者への代理発呼要求があった場合、前記第1利用者のメンバ情報を取得するステップと、取得した前記第1利用者のメンバ情報を前記第2利用者に送信するステップと、前記第2利用者から発呼許可を示す応答があった場合に、前記第1利用者を発信者として前記第2利用者に発呼を行うステップと、を含む通話方法。前記第2利用者が複数人であって、前記第1利用者と、前記第2利用者のいずれかの利用者との間で通話が行われた場合に、前記第2利用者のうち、前記第1利用者と通話を行わなかった利用者に対して、応答不要を示すメッセージを送信するステップを含む、請求項6に記載の通話方法。前記第1利用者からの検索条件に応じて、前記第2利用者を選択するステップを含む、請求項6又は7に記載の通話方法。前記第2利用者から発呼拒否を示す応答があった場合に、一定時間前記第1利用者への呼出音の提供を継続するステップを含む、請求項6乃至8のいずれか一項に記載の通話方法。前記第1利用者からの検索条件に応じて、前記メンバ情報管理部から前記第2利用者を選択する場合、選択した前記第2利用者のメンバ情報が、前記第2利用者に通話意思のないことを示す場合、前記第2利用者を選択結果から除外するステップを含む、請求項8又は9に記載の通話方法。しかし、非特許文献4の技術は、有効期限などの利用条件を設定したメールアドレスによって通常の連絡先を相手に知らせることなくメッセージを交換することができるが、電話のようなリアルタイムコミュニケーションに関する検討は行われていない。したがって、かかる点に鑑みてなされた本発明の目的は、コミュニティ利用者に電話番号を公開することなく、即ち、誰でもいつでもリアルタイムコミュニケーションが可能となる連絡先を公開することなく、コミュニティ利用者間の属性互いにコミュニティに属しているか等および状態互いにリアルタイムコミュニケーションが開始できるか等の一致に基づいた通話を可能にするコミュニティ管理装置及び通話方法を提供することにある。本発明に係るコミュニティ管理装置は、コミュニティ利用者に電話番号を公開することなく前記コミュニティ利用者間の通話を実現するコミュニティ管理装置であって、前記コミュニティ利用者のメンバ情報を保持するメンバ情報管理部と、前記メンバ情報管理部から所定の利用者のメンバ情報を検索するメンバ検索部と、第1利用者から第2利用者への発呼を代理する仮名電話部と、を備え、前記仮名電話部は、前記第1利用者から前記第2利用者への代理発呼要求があった場合、前記メンバ検索部を通じて前記メンバ情報管理部から前記第1利用者のメンバ情報を取得し、取得した前記第1利用者のメンバ情報を前記第2利用者に送信し、前記第2利用者から発呼許可を示す応答があった場合に、前記第1利用者を発信者として前記第2利用者に発呼を行うものである。また、本発明に係る通話方法は、コミュニティ利用者に電話番号を公開することなく前記コミュニティ利用者間の通話を実現するコミュニティ管理装置による通話方法であって、前記コミュニティ管理装置の処理手順は、前記第1利用者から前記第2利用者への代理発呼要求があった場合、前記第1利用者のメンバ情報を取得するステップと、取得した前記第1利用者のメンバ情報を前記第2利用者に送信するステップと、前記第2利用者から発呼許可を示す応答があった場合に、前記第1利用者を発信者として前記第2利用者に発呼を行うステップと、を含むものである。本発明に係るコミュニティ管理装置及び通話方法によれば、コミュニティ利用者に電話番号を公開することなくコミュニティ利用者間の通話を可能にすることができる。まず、本発明に係るコミュニティ管理装置1で実現すべき要件を以下に述べる。例えば、既存のサービスでは、コミュニティ内の不特定多数に自分の電話番号を公開する必要がある。そのため悪意のあるユーザによる電話番号の流出、イタズラ電話等の問題が起こることが懸念される。そこで、コミュニティ管理装置1は、お互いの電話番号を秘匿したまま電話をすることを実現することが必要となる。また、既存のサービスでは、電話を着信した際、要件と発呼側の素性がわからないので着呼を拒否する場合があり、電話を用いたリアルタイムコミュニケーションが円滑に行われないことが懸念される。このため、コミュニティ管理装置1は、電話の用件と通話相手の素性について、着呼者が通話前に把握することができるようにすることが好ましい。また、既存のサービスでは、無駄な折り返しが発生する場合がある。例えば、ある問題を解決する際にコミュニティ内のあるメンバへ発呼したが応答しなかったために別のメンバと電話をし、問題が解決する場合がある。この場合、はじめに発呼を試み呼び出したが着呼に応答できなかったメンバは問題が解決したことを知らないため、無駄な折り返し電話を試みてしまう。このため、コミュニティ管理装置1は、用件終了時に、発呼を行い呼び出したが着呼に応答できなかったメンバに対して用件終了の旨を知らせることが望ましい。また、既存のサービスでは、コミュニティ内から、自分が電話をする目的を達成するのに適している相手を探す事が難しい。例えば、電話を発信する人や利用シーンによって誰に電話をかけるべきか判断に困る場合がある。このため、コミュニティ管理装置1は、発信者自身が通話相手を特定することなく、適した相手に発呼することができるようにすることが好ましい。また、既存のサービスでは、着呼を拒否したことが発呼側に伝わってしまうという問題がある。例えば、友達や近所の人の様な親密なコミュニティにおいては、着呼を拒否したことが発呼側に伝わることでメンバ間の友好関係信頼関係を損ねてしまうことが懸念される。或いは、関係を損ねないよう着呼に応答する必要が生じてしまう。このため、コミュニティ管理装置1は、着呼を拒否したことを発呼側に気づかせないことが望ましい。また、既存のサービスでは、着呼側が着呼に応答する意志がない時でも無関係に着呼してしまう。このため、コミュニティ管理装置1は、着呼側のコンテキスト情報を基に発呼着呼を制御することができることが望ましい。以降、諸図面を参照しながら、本発明の実施態様を詳細に説明する。図1は、本発明の一実施形態に係るコミュニティ管理装置を含むシステムの概要を示す図である。メンバAとメンバBはそれぞれコミュニティ管理装置1の管理するコミュニティに登録している。メンバAとメンバBはお互いに面識はなく、お互いの電話番号も把握していない。本実施形態では、メンバAが、コミュニティ管理装置1を介して、電話番号を知らないメンバBに対して通話を試みるものとする。図2は、本発明の一実施形態に係るコミュニティ管理装置の機能ブロックを示す図である。コミュニティ管理装置1は、メンバ登録部11と、発信受信部12と、メンバ情報管理部13と、メンバ検索部14と、仮名電話部15と、レーティング部16とを備えている。なお、以下の説明では、電話の発信を発呼、電話の着信を着呼、相手と会話可能な状態のことを通話と呼び、発呼着呼通話の一連の動作を電話を行うと称する。メンバ登録部11は、利用者からの入力を受け、コミュニティ利用者のメンバ情報をメンバ情報管理部13に登録する。登録に用いる情報は仮名、プロフィール、コンテキスト情報、電話番号である。登録方法としては、Webインターフェースを用いて利用者が登録する方法、位置情報を利用し自動的に登録する方法、NFCを用いて登録する方法等が考えられる。発信受信部12は、メンバがコミュニティへ情報を発信したり、コミュニティから情報受信したりすることを可能とする。メンバが発信した情報は、発信受信部12によってメンバ情報管理部13に送信され、メンバ情報管理部13により保存される。メンバ情報管理部13は、コミュニティを構成する利用者のメンバ情報を管理する。メンバ情報管理部13は、メンバ登録部11、発信受信部12より渡されたメンバ情報を保存し、必要に応じて他の機能ブロックへ提供する。メンバ情報として登録される情報は、仮名、メンバのプロフィール、過去の情報発信履歴、電話番号、コンテキスト情報、コミュニティにおけるメンバの評価などである。ここで仮名とは、メンバがコミュニティ内で用いるニックネームであり、登録時にメンバが指定する場合と、メンバ登録部11が自動的に付与する場合が考えられる。プロフィールとは、コミュニティにおけるメンバの属性情報である。この情報はコミュニティ内で共有され、検索時や着呼時に参照される。例えば、年齢性別職業居住地出身地血液型趣味等が考えられる。過去の情報発信履歴とは、メンバがコミュニティ内で発信した情報の履歴である。この情報はコミュニティ内で共有され、検索時や着呼時に参照される。例えば、過去に発信したメッセージの履歴や過去に参照したWebページの履歴等が考えられる。電話番号とは、メンバとの通話が可能となる端末の電話番号である。この情報はメンバ検索部14や仮名電話部15が参照することができるが、コミュニティのメンバは参照することが出来ない。コンテキスト情報とは、メンバの現在の状況を示す情報である。例えば、現在コミュニティにチェックインしているか否か、またはチェックイン中の状態、通話できるかといったプレゼンス情報、GPS等を用いて取得することのできるメンバの位置情報等が考えられる。この情報はメンバ検索部14や仮名電話部15が参照することができるが、コミュニティのメンバは参照することが出来ない。メンバの評価とはコミュニティにおけるメンバがどのような貢献をしてきたかを表す指標である。評価は各メンバに1つだけ設定する場合と、発呼側着呼側等、役割毎に設定する場合が考えられる。また、コミュニティにおける絶対評価と、メンバによって異なる相対評価が考えられる。この情報はコミュニティ内で共有され、検索時や着呼時に参照される。メンバ検索部14は、コミュニティから条件に一致する他の利用者を検索することが出来る機能である。これは、メンバ検索部14は、メンバ情報管理部13に保存されているメンバ情報を検索することで実現する。この際に、利用者は検索条件に重みをつけることができ、メンバ検索部14は、検索条件と重みとにより検索を行うことができる。また、メンバ検索部14は、検索結果に含まれるメンバに対して、代理発呼するように仮名電話部15に依頼することもできる。なお、代理発呼とは、発呼者例えばメンバAの代わりに、仮名電話部15が、着呼先例えばメンバBに発呼を行うことである。仮名電話部15は、コミュニティの利用者またはメンバ検索部14により代理発呼依頼を受けメンバに発呼することで、メンバ間での通話を実現する機能である。まず、仮名電話部15は、コミュニティの利用者がお互いに電話番号を知らせずに電話を行うことが出来る機能を備える。これによりコミュニティにおける、相手に面識がなく、信頼関係が構築されていないメンバと電話をする際の抵抗感を低減することができる。また、仮名電話部15は、発呼側が着呼側にメッセージを送る機能を備える。これにより発呼側が電話の用件等を発呼とともに送ることができ、着呼側はどのような意図の電話であるかを確認することができる。この機能はSMSShortMessageServiceやSIPMessageMethodを用いて実現することができる。また、仮名電話部15は、着呼時に着呼側が発呼側の情報を参照することができる機能を備える。参照できる情報はメンバのプロフィール、過去の情報発信履歴、コミュニティにおけるメンバの評価である。これにより着呼側が着呼を受けるかどうかを判断することができる。さらに、仮名電話部15は、着呼側が着呼を拒否した場合でも発呼側に拒否されたことを気づかせない機能を有する。例えば、仮名電話部15は、着呼側が着呼を拒否した場合でも、発呼側の呼び出しを継続し、発呼側に拒否されたのか、不在で出ることができないのか判別できない状態とすることができる。これにより発呼側、着呼側共に気兼ねなく発呼と着呼拒否をすることができ、コミュニティにおいて活発なコミュニケーションが期待できる。レーティング部16は、通話終了後、発呼着呼側双方がお互いの評価を行う機能である。これによりコミュニティにおけるメンバの評価を設定することができ、別の機会における着呼を受け入れるかを決定する際等に参照することができる。これ以降、図3~図11を用いて、コミュニティ管理装置1の動作シーケンスを説明する。なお、以下の例においては、図3~図9においては、メンバA及びメンバBの二者間の動作シーケンスを説明し、図10及び図11においては、メンバA、メンバB及びメンバCの三者間の動作シーケンスを説明する。図3は、メンバ登録処理のシーケンス図である。メンバAがメンバ登録操作を行うとステップS101、メンバ登録部11は、登録情報をメンバ情報管理部13に通知するステップS102。メンバ情報管理部13は、登録情報通知を受けると、メンバAの情報を登録するステップS103。ここで、登録する情報は、コミュニティ内での仮名とプロフィール、電話番号、コンテキスト情報である。この際、自分をメンバとして登録する方法として、Webインターフェースを用いてメンバが情報を自ら登録する方法や、GPS等の位置測定機能があり、予め登録情報を持った携帯端末を用いて、ある場所に行くと自動的に登録するといった位置情報を利用する方法や、予め登録情報を持ったNFC機能を持ったカードや携帯端末を用いて登録する方法等が考えられる。なお、コミュニティに登録する情報におけるコンテキスト情報は逐次更新することができる。その方法としてはメンバが自らコンテキスト情報を登録する場合、携帯端末等を用いて位置が変化したら位置情報を自動的に登録する場合、コンテキスト推定技術を用いて自動的に登録する場合等が考えられる。例えば、メンバAと同様にメンバBがメンバ情報の登録を行うと、メンバ情報管理部13は、表1に示すメンバ情報を持つことになる。以下の表1に登録する情報の項目では該当する情報がない場合を空欄で表現している。なお実装上ではnull値等が登録される。図4は、発信受信処理のシーケンス図である。上記の通り、メンバA及びメンバBは、発信受信部12を用いて、コミュニティにて共有する情報の発信を行うことができる。メンバAが情報を発信するとステップS201、発信情報部12はメンバ情報管理部13に発信情報を通知するステップS202。メンバ情報管理部13は、発信情報通知を受けると、メンバAの発信履歴を更新するステップS203。また、メンバBが情報を発信するとステップS204、発信情報部12はメンバ情報管理部13に発信情報を通知するステップS205。メンバ情報管理部13は、発信情報通知を受けると、メンバBの発信履歴を更新するステップS206。このとき、メンバ情報管理部13は、発信受信部12を通じて、メンバBの発信情報を予めコミュニティに登録しているメンバAに転送することができるステップS207、208。例えば、メンバAがステップS201においてこのURLが有用です。httpwwwnttcojpという情報を発信し、メンバBがステップS204においてこのコミュニティに関係ある研究をしていますという情報を発信した場合には、メンバ情報管理部13は、表2のように、メンバ情報の発信履歴を更新する。図5は、メンバ検索処理のシーケンス図である。なお、メンバAがメンバBの発信情報を受信し、自らメンバBを見つける場合には、メンバ検索処理は必要ではない。メンバAは、メンバ検索部14を用いることにより、条件を指定してコミュニティ内から一致するメンバを検索することができる。まず、メンバAは、メンバ検索部14を用いて、複数の検索条件の組み合わせと各検索条件の重みを指定し、コミュニティからメンバ検索を試みるステップS301。メンバ検索部14は、検索条件をメンバ情報管理部13に通知するステップS302。メンバ情報管理部13は、検索条件に沿ってメンバ検索を行い、検索結果をメンバ検索部14に通知するステップS303。この際に、メンバ検索部14は、検索したメンバのコンテキスト情報に、コミュニティにチェクインしていない、通話を拒否している等の情報があり、明らかに通話する事ができない通話意思のないことが判明している場合は、当該メンバを検索結果から除外する。その後、メンバ検索部14は、検索結果をメンバAに通知するステップS304。なお、メンバ検索部14がメンバAに通知する検索結果は、通常の公開情報であって、電話番号といった秘密情報は含まれない。例えば、メンバ検索部14は、通話できることが明らかなメンバ例えばメンバBについても、電話番号を検索結果に含めない。メンバAが設定する検索条件としては、親密度、コミュニティでの評価、プレゼンス情報、位置情報、プロフィール、コミュニティでの役割等が考えられる。ここで親密度は、メンバ間の通信頻度や同じコミュニティに参加している数、いつも一緒に行動しているため位置情報の履歴が似ている等により決定することができる。また、検索の条件や重みを決定する際に、メンバが手動で設定する場合や、利用シーンごとに標準の設定を提示したり、コミュニティにてよく使われる設定を提示したりする等の方法により、入力の省力化を図ることも考えられる。例えば、メンバAがステップS301において検索条件として30代、研究員という条件を設定し、メンバ検索部14を通じて検索を行うと、メンバ検情報管理部13は、表2のメンバ情報を基にメンバBを検索し、メンバAには、メンバBの公開情報例えば、仮名、プロフィール、下記の発信履歴、コミュニティにおける評価が通知される。検索の結果複数のメンバの情報が通知された場合には、メンバAは複数のメンバの過去の情報発信履歴やコミュニティにおける評価等を参照し、メンバBを指定することができる。図6は、仮名電話部15による代理発呼処理のシーケンス図である。メンバAは、仮名電話部15を用いてメンバBにメッセージを送信することができる。まずメンバAはメンバBに電話の用件をメッセージで送信するように仮名電話部15に依頼するステップS401。依頼を受けた仮名電話部15は、メンバBの電話番号を、メンバ検索部14を用いてメンバ情報管理部13に問い合わせるステップS402、S403。メンバ情報管理部13は、メンバ検索部14を介してメンバBの電話番号を仮名電話部15に伝えるステップS404、S405。その後、仮名電話部15は、メッセージの送信者をメンバAとしてメンバBにメッセージを送信するステップS406。メッセージ送信後、メンバAは、メンバBを指定して仮名電話部15に代理発呼を依頼するステップS407。例えば、メンバAは、ステップS401において、メンバBに対して研究について教えてくださいというメッセージを送信することができる。また、メンバBは、ステップS406において送信者をメンバAとしてメッセージを受け取るが、メンバAの電話番号を取得することはない。これにより、メンバAは、電話の用件のメッセージをお互いの電話番号を知らせることなくメンバBに送信することが可能となり、メンバBは、メッセージを受けて通話を開始するか否かを決定する指針とすることができる。なお、メッセージを送信する手段としてSMS、EMail、SIPMessagemethodを用いることが考えられる。図7は、図6から続く仮名電話部15による代理発呼処理のシーケンス図である。仮名電話部15は、メンバAから代理発呼の要求があると、メンバAの情報要求を行うステップS501。仮名電話部15は、メンバ検索部14を用いてメンバ情報管理部13にメンバAの情報を問い合わせるステップS502。メンバ情報管理部13は、メンバ検索部14を介してメンバAの情報を仮名電話部15に通知するステップS503、S504。なお、ここで通知されるメンバAの情報には、メンバAの電話番号は含まれない。仮名電話部15は取得したメンバAの情報をメンバBに通知し、メンバBはコミュニティにおけるメンバAの情報を参照し、着呼を受け入れるか否かを決めるための指針とすることができるステップS505。メンバBは、着呼に応じる場合、仮名電話部15に発呼許可を示す応答メッセージを送信するステップS506。仮名電話部15は、メンバBから発呼許可を示す応答メッセージを受けると、メンバBに対して、発信者をメンバAとして発呼を行うステップS507。その後、仮名電話部15はメンバA及びメンバB間の通話を確立しステップS508、メンバA及びメンバBは互いに通話することができるステップS509。図8は、メンバBが着呼を拒否した場合のシーケンス図である。ステップS511からステップS515までは、図8のステップS501からステップS505と同様の処理が行われる。メンバBは、ステップS515において送信されたコミュニティにおけるメンバAの情報を参照し、着呼を拒否することができるステップS516。メンバBが着呼を拒否した場合、仮名電話部15はメンバAからの呼び出しをすぐには切断せず、一定時間メンバAへの呼び出し音を継続するステップS517。そして、仮名電話部15は、一定時間経過後に通話を確立出来なかった旨をメンバAに通知するステップS518。これにより、メンバAは、メンバBが明示的に着呼を拒否したのか、不在等の理由で出ることができなかったのかを判断することができないので、着呼を拒否したことをメンバAに気づかせないことができる。図9は、メンバのレーティング処理のシーケンス図である。通話終了後、メンバAは、レーティング部16を用いてメンバBの評価を行うステップS601。レーティング部16は、評価情報をメンバ情報管理部13に通知しステップS602、メンバ情報管理部13は、メンバBの評価情報を更新するステップS603。同様に、メンバBは、レーティング部16を用いてメンバAの評価を行うステップS604。レーティング部16は、評価情報をメンバ情報管理部13に通知しステップS605、メンバ情報管理部13は、メンバAの評価情報を更新するステップS606。これによりコミュニティにおけるメンバの評価を設定することができる。なお、コミュニティにおける評価は各メンバに1つだけ設定する場合と、発呼側着呼側等、役割毎に設定する場合が考えられる。例えば、メンバAは、ステップS601においてメンバBを5と評価し、メンバBは、ステップS604において、メンバAを3と評価するとする。この場合、メンバ情報管理部13のメンバ情報のうち、コミュニティにおける評価の列は、表3の通り更新される。図3~9の動作シーケンスでは、メンバA及びメンバBの二者間の処理であったが、例えば、利用者Aの検索条件に応じてメンバ検索部14が複数のメンバを抽出した場合など、利用者Aからの発呼が複数のメンバに対して行われる場合も考えられる。複数人に対して発呼をする場合、以下の2つの方法が考えられる。1番目の方法は、まず、メンバAは、図5のシーケンスの通り、メンバ検索部14を用いて電話を行うメンバ候補を複数人見つける。次に、メンバAは、見つけた複数の候補の中から、発呼を行うメンバの優先順序を決定する。そして図6のシーケンスにより、優先順序の高いメンバから順次発呼を行う。この際発呼を行う優先順序はメンバ自らが手動で決定する場合や、検索条件によりソートすることで自動的に決定する場合が考えられる。2番目の方法は、メンバAが検索条件にマッチする複数のメンバの中から特定のメンバを指定するのでもなく、複数のメンバの優先順序を手動で決定するのでもなく、検索条件にマッチした複数のメンバの中のいずれかに発呼する場合である。図10は、当該処理のシーケンスを示す図である。まず、メンバAは、メンバ検索部14を用いて、複数の検索条件の組み合わせと各検索条件の重みを指定し、コミュニティからメンバ検索を試みるステップS701。メンバ検索部14は、検索条件をメンバ情報管理部13に通知するステップS702。メンバ情報管理部13は、検索条件に沿ってメンバ検索を行い、検索結果をメンバ検索部14に通知するステップS703。なお、メンバ情報管理部13は、コンテキスト情報により通話することが判明しているメンバは候補から外す。メンバAは、メンバ検索部14にメンバ検索を依頼するだけではなく、検索条件に合うメンバのいずれかに発呼するようメンバ検索部14に依頼するステップS704。この場合、検索結果にはメンバB及びメンバCが含まれており、メンバ検索部14は、仮名電話部15にメンバB及びメンバCへの発呼を依頼する。なお、発呼をする順序はメンバAが指定した条件に、より合致する順序とすることができる。まず仮名電話部15は、メンバBに発呼を行いステップS706、メンバBが発呼に応答しないまたは着呼を拒否した場合、仮名電話部15はすぐにメンバCに発呼を行うステップS707。メンバCが着呼に応答した場合、仮名電話部15は、メンバAとメンバCとの通話を確立しステップS709、メンバA及びメンバC間の通話が可能となるステップS710。以上により、三者間においても、メンバAは匿名性を確保しつつ、電話を行う目的の合う、現在通話可能なメンバと電話を行うことができる。また自ら発呼を続ける必要がないので通話相手をより早く見つけることができる。図11は、レーティング処理のシーケンス図である。図10に示す通話終了後、メンバAは、レーティング部16を用いてメンバCの評価を行うステップS801。レーティング部16は、評価情報をメンバ情報管理部13に通知しステップS802、メンバ情報管理部13は、メンバCの評価情報を更新するステップS803。同様に、メンバCは、レーティング部16を用いてメンバAの評価を行うステップS804。レーティング部16は、評価情報をメンバ情報管理部13に通知しステップS805、メンバ情報管理部13は、メンバAの評価情報を更新するステップS806。これによりコミュニティにおけるメンバの評価を設定することができる。通話終了後、メンバAは、仮名電話部15を用いて、代理発呼に応答しなかったメンバBへ電話の用件は解決したという旨の応答不要を示すメッセージを送信するステップS807、S808。これによりメンバBからの無駄な折り返し等を防ぐことができる。本実施形態によれば、仮名電話部15は、メンバA第1利用者からメンバB第2利用者への代理発呼要求があった場合、メンバ検索部14を通じてメンバ情報管理部13からメンバAのメンバ情報を取得し、取得したメンバAのメンバ情報をメンバBに送信し、メンバBから発呼許可を示す応答があった場合に、メンバAを発信者としてメンバBに発呼を行う。これにより、コミュニティ利用者に電話番号を公開することなくコミュニティ利用者間の通話を可能にすることができる。また、電話の用件と通話相手の素性について、着呼者は通話前に把握することが可能になる。また、仮名電話部15は、第2利用者が複数人メンバB、メンバCであって、メンバAと、メンバB及びメンバCのいずれかの利用者メンバCとの間で通話が行われた場合に、第2利用者メンバB、メンバCのうち、メンバAと通話を行わなかったメンバBに対して、応答不要を示すメッセージを送信する。これにより、用件終了時に、発呼を行い呼び出したが着呼に応答できなかったメンバに対して用件終了の旨を知らせることができる。用件終了時に過去に発呼を行ったが応答しなかったメンバに対してメッセージを送信することで、用件を完了した旨を通知し余計な折り返し電話を防ぐことができる。また、メンバ検索部14は、メンバA第1利用者からの検索条件に応じて、メンバ情報管理部13からメンバB第2利用者を選択する。これにより、発信者自身が通話相手を特定することなし、適した相手に発呼することができる。メンバ検索部14を用いて、用件によってコミュニティのメンバを検索することにより、該当するメンバを複数指定し、優先順序の高い順から順次発呼することが可能になる。また、仮名電話部15は、メンバB第2利用者から着呼拒否を示す応答があった場合に、一定時間メンバA第1利用者への呼出音の提供を継続する。これにより、これにより発呼側は着呼側が明示的に着呼を拒否したのか、不在等の理由で出ることができなかったのかを判断することができず、着呼を拒否したことが発呼者に気づかれない。または、発呼側が自ら発呼を行うのではなく、発呼側が指定する条件に合致する着呼側に対してシステムが自動的に発呼を行ない、通話が可能な着呼側のみをメンバに通知することができる。これにより発呼側は誰が着呼を拒否したのかがわからない。また、メンバ検索部14は、メンバA第1利用者からの検索条件に応じて、メンバ情報管理部13から第2利用者を選択する場合、選択した第2利用者のメンバ情報が、第2利用者に通話意思のないことを示す場合、第2利用者を選択結果から除外する。これにより、着呼側のコンテキスト情報を基に発呼着呼を制御することができる。つまり、メンバ検索部14がコンテキスト情報を参照し、通話しない意志を表明している場合は検索結果に候補を表示しないことで、発呼着呼が起こらないようにすることができる。本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各部材、各手段、各ステップなどに含まれる部などは論理的に矛盾しないように再配置可能であり、複数の手段やステップなどを1つに組み合わせたり、或いは分割したりすることが可能である。