説明

コミュニティ管理システム及びコミュニティ管理方法

【課題】仮想コミュニティにおいて所定の関係を構築するための申請をした申請者の情報を、その申請を承認しようとする被申請者に提供すること。
【解決手段】複数のユーザ間で情報共有するための仮想コミュニティ内で、第1ユーザの要求と第2ユーザの該要求に対する承認とにより、該第1ユーザと該第2ユーザとの間に所定の関係を生成するコミュニティ管理システム1は、ユーザAとユーザCとの間の1ホップの関係の生成を要求するための要求情報をユーザAの携帯電話機M1から受信する受信部と、要求情報が受信された場合に、1ホップの関係の生成を承認するための承認情報をユーザCの携帯電話機M2から受信する前に、その携帯電話機M2の、ユーザAのユーザ情報へのアクセス権を拡張する第1変更部と、を備えることを特徴とする。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、仮想コミュニティを管理するコミュニティ管理システム及びコミュニティ管理方法に関するものである。
【背景技術】
【0002】
従来から、コンピュータシステム上に構築された仮想コミュニティ(以下では単に「コミュニティ」という)が知られている。このようなコミュニティは、例えば、下記特許文献1に示す手法により生成される。すなわち、下記特許文献1には、一のユーザからのコミュニティ生成要求に基づいてメーリングリストのメンバにコミュニティへの招待通知を送信し、参加要求を送信してきたメンバのみをコミュニティに参加させるコミュニティ生成システムが開示されている。このようにして生成されるコミュニティ上では、複数のユーザが各種情報を共有あるいは交換することが可能である。
【0003】
このようなコミュニティでは、友人などの一部のユーザに限って自己の情報を公開できるようにアクセス制限が設定される場合がある。このアクセス制限は、ユーザ同士の関係の変化に伴って変わり得る。例えば、一のユーザがコミュニティ上において別のユーザと友人になることを希望して該別のユーザに友人申請をし、別のユーザがその申請を承認することで初めて、一のユーザ(申請者)と別のユーザ(被申請者)とが互いに相手の個人情報(ユーザ情報)を閲覧できるような制御が行われる。
【特許文献1】特開2001−168901号公報
【発明の開示】
【発明が解決しようとする課題】
【0004】
しかしながら、上記のようなコミュニティでは、ユーザ情報に対するアクセス制限により、友人申請を承認しようとする被申請者が申請者のユーザ情報を十分に閲覧できず、その結果、その申請を承認すべきか否かを判断できないことがある。そのため、被申請者が希望しない相手からの友人申請を承認してしまう場合もある。
【0005】
本発明は、上記課題を解決するためになされたものであり、仮想コミュニティにおいて所定の関係を構築するための申請をした申請者の情報を、その申請を承認しようとする被申請者に提供することが可能なコミュニティ管理システム及びコミュニティ管理方法を提供することを目的とする。
【課題を解決するための手段】
【0006】
本発明のコミュニティ管理システムは、複数のユーザ間で情報共有するための仮想コミュニティ内で、第1ユーザ情報で示される第1ユーザの要求と第2ユーザ情報で示される第2ユーザの該要求に対する承認とにより、該第1ユーザと該第2ユーザとの間に所定の関係を生成するコミュニティ管理システムであって、第1ユーザと第2ユーザとの間の所定の関係の生成を要求するための要求情報を該第1ユーザの第1通信端末から受信する要求受信手段と、要求受信手段により要求情報が受信された場合に、所定の関係の生成を承認するための承認情報を第2ユーザの第2通信端末から受信する前に、該第2通信端末の第1ユーザ情報へのアクセス権を拡張する承認前拡張手段と、を備えることを特徴とする。
【0007】
また、本発明のコミュニティ管理方法は、複数のユーザ間で情報共有するための仮想コミュニティ内で、第1ユーザ情報で示される第1ユーザの要求と第2ユーザ情報で示される第2ユーザの該要求に対する承認とにより、該第1ユーザと該第2ユーザとの間に所定の関係を生成するコミュニティ管理システム、におけるコミュニティ管理方法であって、コミュニティ管理システムが、第1ユーザと第2ユーザとの間の所定の関係の生成を要求するための要求情報を該第1ユーザの第1通信端末から受信する要求受信ステップと、コミュニティ管理システムが、要求受信ステップにおいて要求情報が受信された場合に、所定の関係の生成を承認するための承認情報を第2ユーザの第2通信端末から受信する前に、該第2通信端末の第1ユーザ情報へのアクセス権を拡張する承認前拡張ステップと、を含むことを特徴とする。
【0008】
このようなコミュニティ管理システム及びコミュニティ管理方法によれば、第2ユーザと所定の関係を構築しようとする第1ユーザ(申請者)の第1通信端末から要求情報が受信されると、第2通信端末の第1ユーザ情報へのアクセス権が拡張される。これにより、第2ユーザ(被申請者)は第1ユーザ情報をより広い範囲で参照できるので、仮想コミュニティにおいて所定の関係を構築するための申請をした申請者の情報を、その申請を承認しようとする被申請者に提供できる。
【0009】
本発明のコミュニティ管理システムでは、承認前拡張手段により第1ユーザ情報へのアクセス権が拡張された第2通信端末から承認情報を受信する承認受信手段と、承認受信手段により承認情報が受信された場合に、要求情報により要求された所定の関係を生成し、第1通信端末の第2ユーザ情報へのアクセス権を拡張する承認後拡張手段と、を更に備えることが好ましい。
【0010】
この場合、第2通信端末からの承認情報が受信されると、第1ユーザが要求した所定の関係が生成され、第1通信端末の第2ユーザ情報へのアクセス権が拡張される。これにより、申請者である第1ユーザはコミュニティ上で第2ユーザと所定の関係を構築でき、第2ユーザ情報をより広い範囲で参照できる。
【0011】
本発明のコミュニティ管理システムでは、要求受信手段が、他のユーザを介して間接的に第2ユーザと関連付けられている第1ユーザの要求情報を受信し、所定の関係が、第1ユーザと第2ユーザとを直接関連付ける関係であることが好ましい。
【0012】
この場合、要求情報は、第2ユーザと間接的に関連付けられている第1ユーザを第2ユーザと直接関連付けるための情報となる。したがって、第2ユーザ(被申請者)は自己と直接関連付けられることを望んでいる第1ユーザ(申請者)の第1ユーザ情報を承認前に参照することができる。また、第1のユーザと第2ユーザとが直接関連付けられて初めて、第1ユーザ及び第2ユーザは互いに相手のユーザ情報を参照できる。したがって、自己のユーザ情報を公開する範囲をより限定して個人情報をより確実に保護することが可能になる。
【発明の効果】
【0013】
このようなコミュニティ管理システム及びコミュニティ管理方法によれば、申請者である第1ユーザの第1通信端末からの要求情報が受信されると、被申請者である第2ユーザが所有する第2通信端末の第1ユーザ情報へのアクセス権が拡張されるので、仮想コミュニティにおいて所定の関係を構築するための申請をした申請者の情報を、その申請を承認しようとする被申請者に提供できる。
【発明を実施するための最良の形態】
【0014】
以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。なお、図面の説明において同一又は同等の要素には同一の符号を付し、重複する説明を省略する。
【0015】
まず、図1〜6を用いて、実施形態に係るコミュニティ管理システム1の構成を説明する。図1はコミュニティ管理システム1の全体構成を示す図である。図2はコミュニティにおけるユーザ間の関係の例を示す図である。図3は図2に対応する関係情報を示す図である。図4は、図1に示す第1変更部13による関係情報の更新の例を示す図である。図5は、図1に示す第2変更部15による関係情報の更新の例を示す図である。図6は更新されたユーザ間の関係を示す図である。
【0016】
コミュニティ管理システム1は、複数のユーザが互いに情報を共有・交換するために構築された仮想コミュニティ(以下では単に「コミュニティ」という)を管理するコンピュータシステムである。コミュニティ管理システム1は、ユーザA(第1ユーザ)の携帯電話機M1(第1通信端末)と、ユーザC(第2ユーザ)の携帯電話機M2(第2通信端末)と、管理サーバ10とを備えている。携帯電話機M1、携帯電話機M2及び管理サーバ10は、図示しないネットワークを介して互いに通信可能である。なお、図1では、説明の簡単のために携帯電話機を二つのみ示しているが、コミュニティ管理システム1に含まれる携帯電話機の台数は任意である。
【0017】
携帯電話機M1,M2は、ウェブ閲覧機能及びメール送受信機能を有する移動通信端末である。携帯電話機M1の所持者であるユーザA及び携帯電話機M2の所持者である第2ユーザは共にコミュニティのメンバであり、自己が所有する携帯電話機を用いてそのコミュニティに接続し、コミュニティ内の各種情報にアクセスすることが可能である。
【0018】
管理サーバ10は、コミュニティを構成する各種情報を制御するコンピュータシステムであり、機能的構成要素として記憶部11、受信部(要求受信手段、承認受信手段)12、第1変更部(承認前拡張手段)13、通知部14及び第2変更部(承認後拡張手段)15を備えている。この管理サーバ10は、ウェブ(Web)サーバ、メールサーバ及びデータベースサーバという複数のコンピュータにより構成されてもよいし、ウェブ画面提供機能、メール送受信機能及びデータベース機能を備える一台のコンピュータにより構成されてもよい。
【0019】
記憶部11は、コミュニティに所属するユーザのユーザ情報を記憶する手段である。ユーザ情報は、例えば、ユーザを識別する識別情報やユーザの属性を示す属性情報などで構成されるプロフィール、ユーザが作成した日記(ブログ)、ユーザのスケジュール、及びユーザがアップロードした画像ファイル(写真)をデータ化したものである。ユーザ情報は、コミュニティ内においてユーザ毎に用意されたポータル画面(ユーザポータル)上に表示される。これにより、各ユーザは、他人のポータル画面にアクセスして他人の個人情報や日記、写真などを参照したり、メッセージを残したりすることが可能になる。なお、ユーザ情報の構成はこれに限定されず、プロフィールと日記のみでユーザ情報を構成したり、ポータル画面へのアクセス履歴(足あと)をユーザ情報に含ませたりしてもよい。
【0020】
記憶部11は、ユーザ情報に加えて、他のユーザとの関係と、他のユーザのポータル画面(ユーザ情報)に対する閲覧権限とを規定した関係情報を記憶している。この関係情報は、ユーザ情報と同様に、コミュニティのユーザ毎に記憶される。
【0021】
図2及び3を用いて、関係情報の具体例を説明する。図2において、両方向矢印はユーザ間の関係を示している。このうち、実線矢印は、間に他のユーザが介在することなく二人のユーザが直接関連付けられていることを示している。以下では、このような関係を「1ホップ(友人)の関係」という。例えば、ユーザAとユーザBとは1ホップの関係R1にあり、ユーザCとユーザc3とは1ホップの関係R1にある。これに対し、破線矢印は、一人のユーザを介して、言い換えれば二つの「1ホップの関係」を介して、二人のユーザが間接的に関連付けられていることを示している。以下では、このような関係を「2ホップ(友人の友人)の関係」という。例えば、ユーザAとユーザCとは2ホップの関係R2の関係にある。
【0022】
図3には、具体例としてユーザA及びユーザCの関係情報が示されている。関係情報は、1ホップの関係にあるユーザの集合(1ホップリスト)と、2ホップの関係にあるユーザの集合(2ホップリスト)と、ポータル画面の閲覧が可能なユーザの集合(閲覧可能リスト)とにより構成されている。したがって、関係情報はポータル画面へのアクセス権を規定するアクセス権情報であるともいえる。図3に示す例では、1ホップの関係にあるユーザに対してのみ自己のポータル画面を公開するように閲覧権限が設定されているので、1ホップリストと閲覧可能リストとは等しい。もっとも、閲覧権限をどのように設定するかは限定されず、2ホップの関係にあるユーザに対して一部のユーザ情報への閲覧権限を与えてもよい。
【0023】
なお、記憶部11は、ユーザ情報と関係情報とを分けて記憶してもよいし、これら二つの情報を一つの情報としてまとめて記憶してもよい。
【0024】
受信部12は、携帯電話機M1,M2からの各種情報を受信する手段である。具体的には、受信部12は、ユーザ間の所定の関係の生成を要求するための要求情報を受信するとともに、その要求を承認するための承認情報を受信する手段である。なお、ユーザ間の所定の関係とは情報交換に関する関係のことであり、より具体的には、互いが相手のユーザ情報の全部又は一部にアクセスし得る関係をいう。以下では、ユーザAとユーザCとが図2及び3で示されるように既に2ホップの関係にあることを前提として、ユーザAがユーザCに対して1ホップの関係(友人関係)を結ぼうとする(友人申請をする)場面を例に説明する。
【0025】
ユーザAは、携帯電話機M1に表示された友人申請用のウェブ画面を介して、ユーザCと1ホップの関係になるための入力操作を行う。例えば、ユーザAがユーザCのポータル画面にアクセス可能であれば、ユーザAはそのポータル画面上で所定の操作を行うことで友人申請を行うことが可能である。また、ユーザAは所定のウェブ画面上でユーザCのメールアドレスを指定することで友人申請を行うことも可能である。携帯電話機M1はこの操作により入力されたデータに基づいて要求情報を生成し管理サーバ10に送信する。この要求情報は少なくとも、ユーザAを識別する情報とユーザCを識別する情報とを含み(例えばユーザIDや端末IDなど)、場合によっては更にユーザCのメールアドレスも含む。受信部12は携帯電話機M1からの要求情報を受信して第1変更部13に出力する。
【0026】
ユーザCがその友人申請を承認する場合、ユーザCは携帯電話機M2に表示された承認用の画面を介してユーザAを承認するための入力操作を行う。携帯電話機M2は、この操作により入力されたデータに基づいて承認情報を生成し管理サーバ10に送信する。この承認情報は少なくとも、ユーザAを識別する情報とユーザCを識別する情報とを含む(例えばユーザIDや端末IDなど)を含む。受信部12は、その承認情報を受信して第2変更部15に出力する。
【0027】
第1変更部13は、受信部12により要求情報が受信された場合に、携帯電話機M2(第2通信端末)の、ユーザAのユーザ情報(第1ユーザ情報)へのアクセス権を拡張する手段である。
【0028】
具体的には、第1変更部13は入力された要求情報からユーザA及びユーザCを識別する情報を抽出し、抽出した情報に基づいてユーザAの関係情報とユーザCの関係情報とを記憶部11から読み出す。以下では、第1変更部13が図3(a)及び(b)で示される関係情報を読み出したものとする。続いて、第1変更部13はユーザAからユーザCへの友人申請が可能か否かを判定する。例えば、第1変更部13はユーザAの関係情報内にある2ホップリストにユーザCが含まれているか否かを検査し、その中にユーザCが含まれていれば友人申請が可能であると判定する。また第1変更部13は、入力された要求情報にユーザCのメールアドレスが含まれている場合に、ユーザCのユーザ情報を用いてそのメールアドレスが有効であるか否かを検査し、メールアドレスが有効であれば友人申請が可能であると判定する。
【0029】
友人申請が有効である場合、第1変更部13はユーザAがユーザCに対して友人申請を行ったことを示す申請通知を生成して通知部14に出力する。続いて、第1変更部13は、被申請者であるユーザCが申請者であるユーザAのポータル画面を閲覧できるように、ユーザAの1ホップリストにユーザCを追加する(図4(a)参照)。この更新により、ユーザAの関係情報を構成する1ホップリスト及び2ホップリストの双方にユーザCが含まれることになるが、この場合はユーザCが1ホップリストであることが優先される。したがって、閲覧可能リストにもユーザCが追加され(図4(a)参照)、携帯電話機M2にユーザAのユーザ情報へのアクセス権が付与される。これに対し、ユーザCの関係情報は更新されないので(図3(b)及び図4(b)参照)、ユーザA(申請者)がユーザC(被申請者)のポータル画面を閲覧できないことは変わらない。
【0030】
通知部14は、第1変更部13から入力された申請通知を携帯電話機M2(第2通信端末)に送信する手段である。これにより、被申請者であるユーザCはユーザAから友人申請が届いたことを知りうる。この時点で第1変更部13によりユーザAの関係情報が更新されているので、ユーザCはユーザAのポータル画面にアクセスしてユーザAのユーザ情報を参照できる。そして、ユーザCがユーザAからの友人申請を承認する場合には、ユーザCは携帯電話機M2に表示された承認用画面を介して承認のための操作を行う。これにより承認情報が管理サーバ10に送信される。
【0031】
第2変更部15は、受信部12により承認情報が受信された場合に、ユーザAとユーザCとの間に所定の関係を生成し、携帯電話機M1(第1通信端末)の、ユーザCのユーザ情報(第2ユーザ情報)へのアクセス権を拡張する手段である。
【0032】
具体的には、第2変更部15は入力された承認情報からユーザA及びユーザCを識別する情報を抽出し、抽出された情報に基づいてユーザCの関係情報を記憶部11から読み出す。以下では、第2変更部15が図4(b)で示される関係情報を読み出したものとする。続いて第2変更部15は、申請者であるユーザAが被申請者であるユーザCのポータル画面を閲覧できるように、ユーザCの1ホップリスト及び閲覧可能リストにユーザAを追加する(図5(b)参照)。これにより、ユーザAとユーザCとの間に1ホップの関係が生成され、携帯電話機M1にユーザCのユーザ情報(第2ユーザ情報)へのアクセス権が付与される。なお、ユーザAの関係情報は更新されない。
【0033】
これにより、図2に示されるユーザ間の関係は図6で示されるようなものに変更される。すなわち、ユーザAとユーザCとが2ホップの関係から1ホップの関係R1cになり、互いに相手のポータル画面(ユーザ情報)を参照できる。また、例えばユーザAとユーザc1とが2ホップの関係R2になり、相手に対して友人申請を行うことが可能になる。
【0034】
次に、図7を用いて、図1に示すコミュニティ管理システム1の処理を説明するとともに本実施形態に係るコミュニティ管理方法について説明する。図7はコミュニティ管理システム1の処理を示すシーケンス図である。ここでも、ユーザ間の関係が図2で示されるものでありユーザAがユーザCに友人申請する場合を例に説明する。
【0035】
まず、携帯電話機M1がユーザAの友人申請が受け付けて(ステップS11)、申請の内容を要求情報として管理サーバ10に送信する(ステップS12)。
【0036】
その後、管理サーバ10において受信部12が要求情報を受信する(要求受信ステップ)。続いて、第1変更部13がその要求情報に基づいてユーザA及びCの関係情報を読み出し(ユーザ情報を読み出す場合もある)、ユーザAによる友人申請が可能か否かを判定する(ステップS13)。ここで友人申請が可能であれば(ステップS13;YES)第1変更部13は申請通知を生成し(ステップS14)、友人申請が不可能であれば(ステップS13;NO)処理を終了する。申請通知が生成された場合は、通知部14がその申請通知を携帯電話機M2に送信する(ステップS15)。
【0037】
第1変更部13は申請通知を生成すると共にユーザAの関係情報を変更する。具体的には、第1変更部13はユーザAの1ホップリスト及び閲覧可能リストにユーザCを追加することで、携帯電話機M2(ユーザC)にユーザAのユーザ情報へのアクセス権を付与する(携帯電話機M2の、ユーザAのユーザ情報へのアクセス権を拡張する)(ステップS16、承認前拡張ステップ)。なお、第1変更部13は通知部14により申請通知が送信される前にユーザAの関係情報を変更してもよい。
【0038】
その後、携帯電話機M2が申請通知を受信する。これによりユーザCはユーザAからの友人申請があったことを知ることができる。その後、ユーザCは必要であればユーザAのポータル画面を閲覧し(ステップS17)、友人申請を承認する場合にはそのための操作を行う。携帯電話機M2はその承認を受け付け(ステップS18)、承認情報として管理サーバ10に送信する(ステップS19)。
【0039】
その後、管理サーバ10において受信部12が承認情報を受信する。続いて、第2変更部15がその承認情報に基づいてユーザCの関係情報を変更する。具体的には、第2変更部15はユーザCの1ホップリスト及び閲覧可能リストにユーザAを追加することで、携帯電話機M1(ユーザA)にユーザCのユーザ情報へのアクセス権を付与する(携帯電話機M1の、ユーザCのユーザ情報へのアクセス権を拡張する)(ステップS20)。これにより、ユーザAとユーザCとが1ホップの関係で結ばれ、互いに相手のポータル画面を閲覧できる。
【0040】
以上説明したように、本実施形態によれば、携帯電話機M1からの要求情報が受信されると、携帯電話機M2の、ユーザAのユーザ情報へのアクセス権が拡張ので、被申請者であるユーザCはユーザAのユーザ情報を閲覧できる。これにより、1ホップの関係を構築するための申請をしたユーザAの情報を、その申請を承認しようとするユーザCに提供できる。更に、その後携帯電話機M2からの承認情報が受信されると、ユーザAとユーザCとの間に1ホップの関係が生成され、携帯電話機M1の、ユーザCのユーザ情報へのアクセス権が拡張される。これにより、ユーザAはユーザCのユーザ情報を閲覧できる。
【0041】
また本実施形態によれば、要求情報は、2ホップの関係により他のユーザ(例えばユーザC)と間接的に関連付けられているユーザ(例えばユーザA)を1ホップの関係により該他のユーザと直接関連付けるための情報となる。したがって、例えばユーザCは自己と直接関連付けられることを望んでいるユーザAのユーザ情報を承認前に参照できる。また、ユーザ同士が1ホップの関係で直接関連付けられて初めて、各ユーザは互いに相手のユーザ情報を参照できる。したがって、自己のユーザ情報を公開する範囲をより限定して個人情報をより確実に保護することが可能になる。
【0042】
以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で以下のような様々な変形が可能である。
【0043】
上記実施形態では、2ホップの関係にある二人のユーザの一方が他方のユーザと1ホップの関係になる場合を説明したが、所定の関係を要求(申請)するユーザの条件やその所定の関係の内容は限定されない。例えば、コミュニティにおいて申請者が何らつながりのないユーザに対して1ホップの関係の構築を要求する場面で、本発明を適用してもよい。
【0044】
上記実施形態では被申請者はコミュニティ内のユーザであったが、コミュニティ内のユーザがコミュニティサービスに未加入のユーザに対して友人申請をしてもよい。この場合、要求情報には未加入のユーザのメールアドレスが含まれる。管理サーバ10は、そのメールアドレス宛にコミュニティサービスのURL(Uniform Resource Locator)を含む通知メールを送信する。未加入のユーザは自身の通信端末が受信した通知メールに含まれるURLにアクセスすることでコミュニティサービスに加入する。これにより、加入したユーザと友人申請を行ったユーザとの間に所定の関係(例えば1ホップの関係)が構築される。
【0045】
上記実施形態では関係情報はユーザ間の関係を定義するものであったが、関係情報は、ユーザ間の関係に加えて、ユーザと一以上のユーザで構成されるグループ(サークル)との関係を定義するものであってもよい。
【0046】
上記実施形態では、ユーザが使用する通信端末が携帯電話機であったが、ユーザは他の種類の移動通信端末やパーソナルコンピュータなどの固定端末を用いてもよい。
【図面の簡単な説明】
【0047】
【図1】実施形態に係るコミュニティ管理システムの全体構成を示す図である。
【図2】コミュニティにおけるユーザ間の関係の例を示す図である。
【図3】図2に対応する関係情報を示す図である。
【図4】図1に示す第1変更部による関係情報の更新の例を示す図である。
【図5】図1に示す第2変更部による関係情報の更新の例を示す図である。
【図6】更新されたユーザ間の関係を示す図である。
【図7】図1に示すコミュニティ管理システムの処理を示すシーケンス図である。
【符号の説明】
【0048】
1…コミュニティ管理システム、10…管理サーバ、11…記憶部、12…受信部(要求受信手段、承認受信手段)、13…第1変更部(承認前拡張手段)、14…通知部、15…第2変更部(承認後拡張手段)、M1…携帯電話機(第1通信端末)、M2…携帯電話機(第2通信端末)

【特許請求の範囲】
【請求項1】
複数のユーザ間で情報共有するための仮想コミュニティ内で、第1ユーザ情報で示される第1ユーザの要求と第2ユーザ情報で示される第2ユーザの該要求に対する承認とにより、該第1ユーザと該第2ユーザとの間に所定の関係を生成するコミュニティ管理システムであって、
前記第1ユーザと前記第2ユーザとの間の所定の関係の生成を要求するための要求情報を該第1ユーザの第1通信端末から受信する要求受信手段と、
前記要求受信手段により前記要求情報が受信された場合に、前記所定の関係の生成を承認するための承認情報を前記第2ユーザの第2通信端末から受信する前に、該第2通信端末の前記第1ユーザ情報へのアクセス権を拡張する承認前拡張手段と、
を備えることを特徴とするコミュニティ管理システム。
【請求項2】
前記承認前拡張手段により前記第1ユーザ情報へのアクセス権が拡張された前記第2通信端末から前記承認情報を受信する承認受信手段と、
前記承認受信手段により前記承認情報が受信された場合に、前記要求情報により要求された前記所定の関係を生成し、前記第1通信端末の前記第2ユーザ情報へのアクセス権を拡張する承認後拡張手段と、
を更に備えることを特徴とする請求項1に記載のコミュニティ管理システム。
【請求項3】
前記要求受信手段が、他のユーザを介して間接的に前記第2ユーザと関連付けられている前記第1ユーザの要求情報を受信し、
前記所定の関係が、前記第1ユーザと前記第2ユーザとを直接関連付ける関係である、
ことを特徴とする請求項1又は2に記載のコミュニティ管理システム。
【請求項4】
複数のユーザ間で情報共有するための仮想コミュニティ内で、第1ユーザ情報で示される第1ユーザの要求と第2ユーザ情報で示される第2ユーザの該要求に対する承認とにより、該第1ユーザと該第2ユーザとの間に所定の関係を生成するコミュニティ管理システム、におけるコミュニティ管理方法であって、
前記コミュニティ管理システムが、前記第1ユーザと前記第2ユーザとの間の所定の関係の生成を要求するための要求情報を該第1ユーザの第1通信端末から受信する要求受信ステップと、
前記コミュニティ管理システムが、前記要求受信ステップにおいて前記要求情報が受信された場合に、前記所定の関係の生成を承認するための承認情報を前記第2ユーザの第2通信端末から受信する前に、該第2通信端末の前記第1ユーザ情報へのアクセス権を拡張する承認前拡張ステップと、
を含むことを特徴とするコミュニティ管理方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate


【公開番号】特開2009−175966(P2009−175966A)
【公開日】平成21年8月6日(2009.8.6)
【国際特許分類】
【出願番号】特願2008−12862(P2008−12862)
【出願日】平成20年1月23日(2008.1.23)
【出願人】(392026693)株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Fターム(参考)】