(57)【要約】【課題】仮想コミュニティにおいて所定の関係を構築するための申請をした申請者の情報を、その申請を承認しようとする被申請者に提供すること。【解決手段】複数のユーザ間で情報共有するための仮想コミュニティ内で、第１ユーザの要求と第２ユーザの該要求に対する承認とにより、該第１ユーザと該第２ユーザとの間に所定の関係を生成するコミュニティ管理システム１は、ユーザＡとユーザＣとの間の１ホップの関係の生成を要求するための要求情報をユーザＡの携帯電話機Ｍ１から受信する受信部と、要求情報が受信された場合に、１ホップの関係の生成を承認するための承認情報をユーザＣの携帯電話機Ｍ２から受信する前に、その携帯電話機Ｍ２の、ユーザＡのユーザ情報へのアクセス権を拡張する第１変更部と、を備えることを特徴とする。【選択図】図１
2009175966.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザ間で情報共有するための仮想コミュニティ内で、第１ユーザ情報で示される第１ユーザの要求と第２ユーザ情報で示される第２ユーザの該要求に対する承認とにより、該第１ユーザと該第２ユーザとの間に所定の関係を生成するコミュニティ管理システムであって、
前記第１ユーザと前記第２ユーザとの間の所定の関係の生成を要求するための要求情報を該第１ユーザの第１通信端末から受信する要求受信手段と、
前記要求受信手段により前記要求情報が受信された場合に、前記所定の関係の生成を承認するための承認情報を前記第２ユーザの第２通信端末から受信する前に、該第２通信端末の前記第１ユーザ情報へのアクセス権を拡張する承認前拡張手段と、
を備えることを特徴とするコミュニティ管理システム。
【請求項２】
前記承認前拡張手段により前記第１ユーザ情報へのアクセス権が拡張された前記第２通信端末から前記承認情報を受信する承認受信手段と、
前記承認受信手段により前記承認情報が受信された場合に、前記要求情報により要求された前記所定の関係を生成し、前記第１通信端末の前記第２ユーザ情報へのアクセス権を拡張する承認後拡張手段と、
を更に備えることを特徴とする請求項１に記載のコミュニティ管理システム。
【請求項３】
前記要求受信手段が、他のユーザを介して間接的に前記第２ユーザと関連付けられている前記第１ユーザの要求情報を受信し、
前記所定の関係が、前記第１ユーザと前記第２ユーザとを直接関連付ける関係である、
ことを特徴とする請求項１又は２に記載のコミュニティ管理システム。
【請求項４】
複数のユーザ間で情報共有するための仮想コミュニティ内で、第１ユーザ情報で示される第１ユーザの要求と第２ユーザ情報で示される第２ユーザの該要求に対する承認とにより、該第１ユーザと該第２ユーザとの間に所定の関係を生成するコミュニティ管理システム、におけるコミュニティ管理方法であって、
前記コミュニティ管理システムが、前記第１ユーザと前記第２ユーザとの間の所定の関係の生成を要求するための要求情報を該第１ユーザの第１通信端末から受信する要求受信ステップと、
前記コミュニティ管理システムが、前記要求受信ステップにおいて前記要求情報が受信された場合に、前記所定の関係の生成を承認するための承認情報を前記第２ユーザの第２通信端末から受信する前に、該第２通信端末の前記第１ユーザ情報へのアクセス権を拡張する承認前拡張ステップと、
を含むことを特徴とするコミュニティ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想コミュニティを管理するコミュニティ管理システム及びコミュニティ管理方法に関するものである。
【背景技術】
【０００２】
従来から、コンピュータシステム上に構築された仮想コミュニティ（以下では単に「コミュニティ」という）が知られている。このようなコミュニティは、例えば、下記特許文献１に示す手法により生成される。すなわち、下記特許文献１には、一のユーザからのコミュニティ生成要求に基づいてメーリングリストのメンバにコミュニティへの招待通知を送信し、参加要求を送信してきたメンバのみをコミュニティに参加させるコミュニティ生成システムが開示されている。このようにして生成されるコミュニティ上では、複数のユーザが各種情報を共有あるいは交換することが可能である。
【０００３】
このようなコミュニティでは、友人などの一部のユーザに限って自己の情報を公開できるようにアクセス制限が設定される場合がある。このアクセス制限は、ユーザ同士の関係の変化に伴って変わり得る。例えば、一のユーザがコミュニティ上において別のユーザと友人になることを希望して該別のユーザに友人申請をし、別のユーザがその申請を承認することで初めて、一のユーザ（申請者）と別のユーザ（被申請者）とが互いに相手の個人情報（ユーザ情報）を閲覧できるような制御が行われる。
【特許文献１】特開２００１−１６８９０１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記のようなコミュニティでは、ユーザ情報に対するアクセス制限により、友人申請を承認しようとする被申請者が申請者のユーザ情報を十分に閲覧できず、その結果、その申請を承認すべきか否かを判断できないことがある。そのため、被申請者が希望しない相手からの友人申請を承認してしまう場合もある。
【０００５】
本発明は、上記課題を解決するためになされたものであり、仮想コミュニティにおいて所定の関係を構築するための申請をした申請者の情報を、その申請を承認しようとする被申請者に提供することが可能なコミュニティ管理システム及びコミュニティ管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明のコミュニティ管理システムは、複数のユーザ間で情報共有するための仮想コミュニティ内で、第１ユーザ情報で示される第１ユーザの要求と第２ユーザ情報で示される第２ユーザの該要求に対する承認とにより、該第１ユーザと該第２ユーザとの間に所定の関係を生成するコミュニティ管理システムであって、第１ユーザと第２ユーザとの間の所定の関係の生成を要求するための要求情報を該第１ユーザの第１通信端末から受信する要求受信手段と、要求受信手段により要求情報が受信された場合に、所定の関係の生成を承認するための承認情報を第２ユーザの第２通信端末から受信する前に、該第２通信端末の第１ユーザ情報へのアクセス権を拡張する承認前拡張手段と、を備えることを特徴とする。
【０００７】
また、本発明のコミュニティ管理方法は、複数のユーザ間で情報共有するための仮想コミュニティ内で、第１ユーザ情報で示される第１ユーザの要求と第２ユーザ情報で示される第２ユーザの該要求に対する承認とにより、該第１ユーザと該第２ユーザとの間に所定の関係を生成するコミュニティ管理システム、におけるコミュニティ管理方法であって、コミュニティ管理システムが、第１ユーザと第２ユーザとの間の所定の関係の生成を要求するための要求情報を該第１ユーザの第１通信端末から受信する要求受信ステップと、コミュニティ管理システムが、要求受信ステップにおいて要求情報が受信された場合に、所定の関係の生成を承認するための承認情報を第２ユーザの第２通信端末から受信する前に、該第２通信端末の第１ユーザ情報へのアクセス権を拡張する承認前拡張ステップと、を含むことを特徴とする。
【０００８】
このようなコミュニティ管理システム及びコミュニティ管理方法によれば、第２ユーザと所定の関係を構築しようとする第１ユーザ（申請者）の第１通信端末から要求情報が受信されると、第２通信端末の第１ユーザ情報へのアクセス権が拡張される。これにより、第２ユーザ（被申請者）は第１ユーザ情報をより広い範囲で参照できるので、仮想コミュニティにおいて所定の関係を構築するための申請をした申請者の情報を、その申請を承認しようとする被申請者に提供できる。
【０００９】
本発明のコミュニティ管理システムでは、承認前拡張手段により第１ユーザ情報へのアクセス権が拡張された第２通信端末から承認情報を受信する承認受信手段と、承認受信手段により承認情報が受信された場合に、要求情報により要求された所定の関係を生成し、第１通信端末の第２ユーザ情報へのアクセス権を拡張する承認後拡張手段と、を更に備えることが好ましい。
【００１０】
この場合、第２通信端末からの承認情報が受信されると、第１ユーザが要求した所定の関係が生成され、第１通信端末の第２ユーザ情報へのアクセス権が拡張される。これにより、申請者である第１ユーザはコミュニティ上で第２ユーザと所定の関係を構築でき、第２ユーザ情報をより広い範囲で参照できる。
【００１１】
本発明のコミュニティ管理システムでは、要求受信手段が、他のユーザを介して間接的に第２ユーザと関連付けられている第１ユーザの要求情報を受信し、所定の関係が、第１ユーザと第２ユーザとを直接関連付ける関係であることが好ましい。
【００１２】
この場合、要求情報は、第２ユーザと間接的に関連付けられている第１ユーザを第２ユーザと直接関連付けるための情報となる。したがって、第２ユーザ（被申請者）は自己と直接関連付けられることを望んでいる第１ユーザ（申請者）の第１ユーザ情報を承認前に参照することができる。また、第１のユーザと第２ユーザとが直接関連付けられて初めて、第１ユーザ及び第２ユーザは互いに相手のユーザ情報を参照できる。したがって、自己のユーザ情報を公開する範囲をより限定して個人情報をより確実に保護することが可能になる。
【発明の効果】
【００１３】
このようなコミュニティ管理システム及びコミュニティ管理方法によれば、申請者である第１ユーザの第１通信端末からの要求情報が受信されると、被申請者である第２ユーザが所有する第２通信端末の第１ユーザ情報へのアクセス権が拡張されるので、仮想コミュニティにおいて所定の関係を構築するための申請をした申請者の情報を、その申請を承認しようとする被申請者に提供できる。
【発明を実施するための最良の形態】
【００１４】
以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。なお、図面の説明において同一又は同等の要素には同一の符号を付し、重複する説明を省略する。
【００１５】
まず、図１〜６を用いて、実施形態に係るコミュニティ管理システム１の構成を説明する。図１はコミュニティ管理システム１の全体構成を示す図である。図２はコミュニティにおけるユーザ間の関係の例を示す図である。図３は図２に対応する関係情報を示す図である。図４は、図１に示す第１変更部１３による関係情報の更新の例を示す図である。図５は、図１に示す第２変更部１５による関係情報の更新の例を示す図である。図６は更新されたユーザ間の関係を示す図である。
【００１６】
コミュニティ管理システム１は、複数のユーザが互いに情報を共有・交換するために構築された仮想コミュニティ（以下では単に「コミュニティ」という）を管理するコンピュータシステムである。コミュニティ管理システム１は、ユーザＡ（第１ユーザ）の携帯電話機Ｍ１（第１通信端末）と、ユーザＣ（第２ユーザ）の携帯電話機Ｍ２（第２通信端末）と、管理サーバ１０とを備えている。携帯電話機Ｍ１、携帯電話機Ｍ２及び管理サーバ１０は、図示しないネットワークを介して互いに通信可能である。なお、図１では、説明の簡単のために携帯電話機を二つのみ示しているが、コミュニティ管理システム１に含まれる携帯電話機の台数は任意である。
【００１７】
携帯電話機Ｍ１，Ｍ２は、ウェブ閲覧機能及びメール送受信機能を有する移動通信端末である。携帯電話機Ｍ１の所持者であるユーザＡ及び携帯電話機Ｍ２の所持者である第２ユーザは共にコミュニティのメンバであり、自己が所有する携帯電話機を用いてそのコミュニティに接続し、コミュニティ内の各種情報にアクセスすることが可能である。
【００１８】
管理サーバ１０は、コミュニティを構成する各種情報を制御するコンピュータシステムであり、機能的構成要素として記憶部１１、受信部（要求受信手段、承認受信手段）１２、第１変更部（承認前拡張手段）１３、通知部１４及び第２変更部（承認後拡張手段）１５を備えている。この管理サーバ１０は、ウェブ（Ｗｅｂ）サーバ、メールサーバ及びデータベースサーバという複数のコンピュータにより構成されてもよいし、ウェブ画面提供機能、メール送受信機能及びデータベース機能を備える一台のコンピュータにより構成されてもよい。
【００１９】
記憶部１１は、コミュニティに所属するユーザのユーザ情報を記憶する手段である。ユーザ情報は、例えば、ユーザを識別する識別情報やユーザの属性を示す属性情報などで構成されるプロフィール、ユーザが作成した日記（ブログ）、ユーザのスケジュール、及びユーザがアップロードした画像ファイル（写真）をデータ化したものである。ユーザ情報は、コミュニティ内においてユーザ毎に用意されたポータル画面（ユーザポータル）上に表示される。これにより、各ユーザは、他人のポータル画面にアクセスして他人の個人情報や日記、写真などを参照したり、メッセージを残したりすることが可能になる。なお、ユーザ情報の構成はこれに限定されず、プロフィールと日記のみでユーザ情報を構成したり、ポータル画面へのアクセス履歴（足あと）をユーザ情報に含ませたりしてもよい。
【００２０】
記憶部１１は、ユーザ情報に加えて、他のユーザとの関係と、他のユーザのポータル画面（ユーザ情報）に対する閲覧権限とを規定した関係情報を記憶している。この関係情報は、ユーザ情報と同様に、コミュニティのユーザ毎に記憶される。
【００２１】
図２及び３を用いて、関係情報の具体例を説明する。図２において、両方向矢印はユーザ間の関係を示している。このうち、実線矢印は、間に他のユーザが介在することなく二人のユーザが直接関連付けられていることを示している。以下では、このような関係を「１ホップ（友人）の関係」という。例えば、ユーザＡとユーザＢとは１ホップの関係Ｒ１ａにあり、ユーザＣとユーザｃ３とは１ホップの関係Ｒ１ｂにある。これに対し、破線矢印は、一人のユーザを介して、言い換えれば二つの「１ホップの関係」を介して、二人のユーザが間接的に関連付けられていることを示している。以下では、このような関係を「２ホップ（友人の友人）の関係」という。例えば、ユーザＡとユーザＣとは２ホップの関係Ｒ２ａの関係にある。
【００２２】
図３には、具体例としてユーザＡ及びユーザＣの関係情報が示されている。関係情報は、１ホップの関係にあるユーザの集合（１ホップリスト）と、２ホップの関係にあるユーザの集合（２ホップリスト）と、ポータル画面の閲覧が可能なユーザの集合（閲覧可能リスト）とにより構成されている。したがって、関係情報はポータル画面へのアクセス権を規定するアクセス権情報であるともいえる。図３に示す例では、１ホップの関係にあるユーザに対してのみ自己のポータル画面を公開するように閲覧権限が設定されているので、１ホップリストと閲覧可能リストとは等しい。もっとも、閲覧権限をどのように設定するかは限定されず、２ホップの関係にあるユーザに対して一部のユーザ情報への閲覧権限を与えてもよい。
【００２３】
なお、記憶部１１は、ユーザ情報と関係情報とを分けて記憶してもよいし、これら二つの情報を一つの情報としてまとめて記憶してもよい。
【００２４】
受信部１２は、携帯電話機Ｍ１，Ｍ２からの各種情報を受信する手段である。具体的には、受信部１２は、ユーザ間の所定の関係の生成を要求するための要求情報を受信するとともに、その要求を承認するための承認情報を受信する手段である。なお、ユーザ間の所定の関係とは情報交換に関する関係のことであり、より具体的には、互いが相手のユーザ情報の全部又は一部にアクセスし得る関係をいう。以下では、ユーザＡとユーザＣとが図２及び３で示されるように既に２ホップの関係にあることを前提として、ユーザＡがユーザＣに対して１ホップの関係（友人関係）を結ぼうとする（友人申請をする）場面を例に説明する。
【００２５】
ユーザＡは、携帯電話機Ｍ１に表示された友人申請用のウェブ画面を介して、ユーザＣと１ホップの関係になるための入力操作を行う。例えば、ユーザＡがユーザＣのポータル画面にアクセス可能であれば、ユーザＡはそのポータル画面上で所定の操作を行うことで友人申請を行うことが可能である。また、ユーザＡは所定のウェブ画面上でユーザＣのメールアドレスを指定することで友人申請を行うことも可能である。携帯電話機Ｍ１はこの操作により入力されたデータに基づいて要求情報を生成し管理サーバ１０に送信する。この要求情報は少なくとも、ユーザＡを識別する情報とユーザＣを識別する情報とを含み（例えばユーザＩＤや端末ＩＤなど）、場合によっては更にユーザＣのメールアドレスも含む。受信部１２は携帯電話機Ｍ１からの要求情報を受信して第１変更部１３に出力する。
【００２６】
ユーザＣがその友人申請を承認する場合、ユーザＣは携帯電話機Ｍ２に表示された承認用の画面を介してユーザＡを承認するための入力操作を行う。携帯電話機Ｍ２は、この操作により入力されたデータに基づいて承認情報を生成し管理サーバ１０に送信する。この承認情報は少なくとも、ユーザＡを識別する情報とユーザＣを識別する情報とを含む（例えばユーザＩＤや端末ＩＤなど）を含む。受信部１２は、その承認情報を受信して第２変更部１５に出力する。
【００２７】
第１変更部１３は、受信部１２により要求情報が受信された場合に、携帯電話機Ｍ２（第２通信端末）の、ユーザＡのユーザ情報（第１ユーザ情報）へのアクセス権を拡張する手段である。
【００２８】
具体的には、第１変更部１３は入力された要求情報からユーザＡ及びユーザＣを識別する情報を抽出し、抽出した情報に基づいてユーザＡの関係情報とユーザＣの関係情報とを記憶部１１から読み出す。以下では、第１変更部１３が図３（ａ）及び（ｂ）で示される関係情報を読み出したものとする。続いて、第１変更部１３はユーザＡからユーザＣへの友人申請が可能か否かを判定する。例えば、第１変更部１３はユーザＡの関係情報内にある２ホップリストにユーザＣが含まれているか否かを検査し、その中にユーザＣが含まれていれば友人申請が可能であると判定する。また第１変更部１３は、入力された要求情報にユーザＣのメールアドレスが含まれている場合に、ユーザＣのユーザ情報を用いてそのメールアドレスが有効であるか否かを検査し、メールアドレスが有効であれば友人申請が可能であると判定する。
【００２９】
友人申請が有効である場合、第１変更部１３はユーザＡがユーザＣに対して友人申請を行ったことを示す申請通知を生成して通知部１４に出力する。続いて、第１変更部１３は、被申請者であるユーザＣが申請者であるユーザＡのポータル画面を閲覧できるように、ユーザＡの１ホップリストにユーザＣを追加する（図４（ａ）参照）。この更新により、ユーザＡの関係情報を構成する１ホップリスト及び２ホップリストの双方にユーザＣが含まれることになるが、この場合はユーザＣが１ホップリストであることが優先される。したがって、閲覧可能リストにもユーザＣが追加され（図４（ａ）参照）、携帯電話機Ｍ２にユーザＡのユーザ情報へのアクセス権が付与される。これに対し、ユーザＣの関係情報は更新されないので（図３（ｂ）及び図４（ｂ）参照）、ユーザＡ（申請者）がユーザＣ（被申請者）のポータル画面を閲覧できないことは変わらない。
【００３０】
通知部１４は、第１変更部１３から入力された申請通知を携帯電話機Ｍ２（第２通信端末）に送信する手段である。これにより、被申請者であるユーザＣはユーザＡから友人申請が届いたことを知りうる。この時点で第１変更部１３によりユーザＡの関係情報が更新されているので、ユーザＣはユーザＡのポータル画面にアクセスしてユーザＡのユーザ情報を参照できる。そして、ユーザＣがユーザＡからの友人申請を承認する場合には、ユーザＣは携帯電話機Ｍ２に表示された承認用画面を介して承認のための操作を行う。これにより承認情報が管理サーバ１０に送信される。
【００３１】
第２変更部１５は、受信部１２により承認情報が受信された場合に、ユーザＡとユーザＣとの間に所定の関係を生成し、携帯電話機Ｍ１（第１通信端末）の、ユーザＣのユーザ情報（第２ユーザ情報）へのアクセス権を拡張する手段である。
【００３２】
具体的には、第２変更部１５は入力された承認情報からユーザＡ及びユーザＣを識別する情報を抽出し、抽出された情報に基づいてユーザＣの関係情報を記憶部１１から読み出す。以下では、第２変更部１５が図４（ｂ）で示される関係情報を読み出したものとする。続いて第２変更部１５は、申請者であるユーザＡが被申請者であるユーザＣのポータル画面を閲覧できるように、ユーザＣの１ホップリスト及び閲覧可能リストにユーザＡを追加する（図５（ｂ）参照）。これにより、ユーザＡとユーザＣとの間に１ホップの関係が生成され、携帯電話機Ｍ１にユーザＣのユーザ情報（第２ユーザ情報）へのアクセス権が付与される。なお、ユーザＡの関係情報は更新されない。
【００３３】
これにより、図２に示されるユーザ間の関係は図６で示されるようなものに変更される。すなわち、ユーザＡとユーザＣとが２ホップの関係から１ホップの関係Ｒ１ｃになり、互いに相手のポータル画面（ユーザ情報）を参照できる。また、例えばユーザＡとユーザｃ１とが２ホップの関係Ｒ２ｂになり、相手に対して友人申請を行うことが可能になる。
【００３４】
次に、図７を用いて、図１に示すコミュニティ管理システム１の処理を説明するとともに本実施形態に係るコミュニティ管理方法について説明する。図７はコミュニティ管理システム１の処理を示すシーケンス図である。ここでも、ユーザ間の関係が図２で示されるものでありユーザＡがユーザＣに友人申請する場合を例に説明する。
【００３５】
まず、携帯電話機Ｍ１がユーザＡの友人申請が受け付けて（ステップＳ１１）、申請の内容を要求情報として管理サーバ１０に送信する（ステップＳ１２）。
【００３６】
その後、管理サーバ１０において受信部１２が要求情報を受信する（要求受信ステップ）。続いて、第１変更部１３がその要求情報に基づいてユーザＡ及びＣの関係情報を読み出し（ユーザ情報を読み出す場合もある）、ユーザＡによる友人申請が可能か否かを判定する（ステップＳ１３）。ここで友人申請が可能であれば（ステップＳ１３；ＹＥＳ）第１変更部１３は申請通知を生成し（ステップＳ１４）、友人申請が不可能であれば（ステップＳ１３；ＮＯ）処理を終了する。申請通知が生成された場合は、通知部１４がその申請通知を携帯電話機Ｍ２に送信する（ステップＳ１５）。
【００３７】
第１変更部１３は申請通知を生成すると共にユーザＡの関係情報を変更する。具体的には、第１変更部１３はユーザＡの１ホップリスト及び閲覧可能リストにユーザＣを追加することで、携帯電話機Ｍ２（ユーザＣ）にユーザＡのユーザ情報へのアクセス権を付与する（携帯電話機Ｍ２の、ユーザＡのユーザ情報へのアクセス権を拡張する）（ステップＳ１６、承認前拡張ステップ）。なお、第１変更部１３は通知部１４により申請通知が送信される前にユーザＡの関係情報を変更してもよい。
【００３８】
その後、携帯電話機Ｍ２が申請通知を受信する。これによりユーザＣはユーザＡからの友人申請があったことを知ることができる。その後、ユーザＣは必要であればユーザＡのポータル画面を閲覧し（ステップＳ１７）、友人申請を承認する場合にはそのための操作を行う。携帯電話機Ｍ２はその承認を受け付け（ステップＳ１８）、承認情報として管理サーバ１０に送信する（ステップＳ１９）。
【００３９】
その後、管理サーバ１０において受信部１２が承認情報を受信する。続いて、第２変更部１５がその承認情報に基づいてユーザＣの関係情報を変更する。具体的には、第２変更部１５はユーザＣの１ホップリスト及び閲覧可能リストにユーザＡを追加することで、携帯電話機Ｍ１（ユーザＡ）にユーザＣのユーザ情報へのアクセス権を付与する（携帯電話機Ｍ１の、ユーザＣのユーザ情報へのアクセス権を拡張する）（ステップＳ２０）。これにより、ユーザＡとユーザＣとが１ホップの関係で結ばれ、互いに相手のポータル画面を閲覧できる。
【００４０】
以上説明したように、本実施形態によれば、携帯電話機Ｍ１からの要求情報が受信されると、携帯電話機Ｍ２の、ユーザＡのユーザ情報へのアクセス権が拡張ので、被申請者であるユーザＣはユーザＡのユーザ情報を閲覧できる。これにより、１ホップの関係を構築するための申請をしたユーザＡの情報を、その申請を承認しようとするユーザＣに提供できる。更に、その後携帯電話機Ｍ２からの承認情報が受信されると、ユーザＡとユーザＣとの間に１ホップの関係が生成され、携帯電話機Ｍ１の、ユーザＣのユーザ情報へのアクセス権が拡張される。これにより、ユーザＡはユーザＣのユーザ情報を閲覧できる。
【００４１】
また本実施形態によれば、要求情報は、２ホップの関係により他のユーザ（例えばユーザＣ）と間接的に関連付けられているユーザ（例えばユーザＡ）を１ホップの関係により該他のユーザと直接関連付けるための情報となる。したがって、例えばユーザＣは自己と直接関連付けられることを望んでいるユーザＡのユーザ情報を承認前に参照できる。また、ユーザ同士が１ホップの関係で直接関連付けられて初めて、各ユーザは互いに相手のユーザ情報を参照できる。したがって、自己のユーザ情報を公開する範囲をより限定して個人情報をより確実に保護することが可能になる。
【００４２】
以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で以下のような様々な変形が可能である。
【００４３】
上記実施形態では、２ホップの関係にある二人のユーザの一方が他方のユーザと１ホップの関係になる場合を説明したが、所定の関係を要求（申請）するユーザの条件やその所定の関係の内容は限定されない。例えば、コミュニティにおいて申請者が何らつながりのないユーザに対して１ホップの関係の構築を要求する場面で、本発明を適用してもよい。
【００４４】
上記実施形態では被申請者はコミュニティ内のユーザであったが、コミュニティ内のユーザがコミュニティサービスに未加入のユーザに対して友人申請をしてもよい。この場合、要求情報には未加入のユーザのメールアドレスが含まれる。管理サーバ１０は、そのメールアドレス宛にコミュニティサービスのＵＲＬ（Uniform Resource Locator）を含む通知メールを送信する。未加入のユーザは自身の通信端末が受信した通知メールに含まれるＵＲＬにアクセスすることでコミュニティサービスに加入する。これにより、加入したユーザと友人申請を行ったユーザとの間に所定の関係（例えば１ホップの関係）が構築される。
【００４５】
上記実施形態では関係情報はユーザ間の関係を定義するものであったが、関係情報は、ユーザ間の関係に加えて、ユーザと一以上のユーザで構成されるグループ（サークル）との関係を定義するものであってもよい。
【００４６】
上記実施形態では、ユーザが使用する通信端末が携帯電話機であったが、ユーザは他の種類の移動通信端末やパーソナルコンピュータなどの固定端末を用いてもよい。
【図面の簡単な説明】
【００４７】
【図１】実施形態に係るコミュニティ管理システムの全体構成を示す図である。
【図２】コミュニティにおけるユーザ間の関係の例を示す図である。
【図３】図２に対応する関係情報を示す図である。
【図４】図１に示す第１変更部による関係情報の更新の例を示す図である。
【図５】図１に示す第２変更部による関係情報の更新の例を示す図である。
【図６】更新されたユーザ間の関係を示す図である。
【図７】図１に示すコミュニティ管理システムの処理を示すシーケンス図である。
【符号の説明】
【００４８】
１…コミュニティ管理システム、１０…管理サーバ、１１…記憶部、１２…受信部（要求受信手段、承認受信手段）、１３…第１変更部（承認前拡張手段）、１４…通知部、１５…第２変更部（承認後拡張手段）、Ｍ１…携帯電話機（第１通信端末）、Ｍ２…携帯電話機（第２通信端末）
【図１】
2009175966.tif 000003
【図２】
2009175966.tif 000004
【図３】
2009175966.tif 000005
【図４】
2009175966.tif 000006
【図５】
2009175966.tif 000007
【図６】
2009175966.tif 000008
【図７】
2009175966.tif 000009