(57)【要約】【課題】メーリングリストなどのコミュニティの管理では、メーリングリストの管理者にメンバ追加や削除などの作業の負荷が集中する課題があり、その対策として自動的にメンバを追加、削除を行うとコミュニティのメンバとして適していないユーザまで参加できるという課題がある。【解決手段】メーリングリスト管理情報８０にメンバ加入時、脱退時の承認者決定情報を付加するとともに、メーリングリストへ誰が誰を招待したかという招待関係情報９０を保持する。メーリングリスト管理手段４０は、メンバ追加要求があった際に、上記承認者決定情報に基づき、招待関係情報から承認権限を有するメンバをその都度決定し、承認依頼を行い、承認されたユーザのみをメーリングリストに追加する。【選択図】図１
2007228243.tif 000002
【特許請求の範囲】
【請求項１】
メンバリストに登録されたメンバで構成されるコミュニティを管理するコミュニティ管理システムであって、
前記メンバリストについてメンバの登録申込が行われる度に、該登録申込に対する承認権限を有するメンバをその都度決定するための承認者決定情報を含むメンバリスト管理情報を保持するとともに、
前記メンバリストに対する登録申込に対し、前記承認者決定情報により決定されたメンバから承認を得られているか否かを確認した後、該メンバリストへの登録処理を行うメンバリスト管理手段を備えたこと、
を特徴とするコミュニティ管理システム。
【請求項２】
メンバリストに登録されたメンバで構成されるコミュニティを管理するコミュニティ管理システムであって、
前記メンバリストについてメンバの削除申込が行われる度に、該削除申込に対する承認権限を有するメンバをその都度決定するための承認者決定情報を含むメンバリスト管理情報を保持するとともに、
前記メンバリストからの削除申込に対し、前記承認者決定情報により決定されたメンバから承認を得られているか否かを確認した後、該メンバリストからの削除処理を行うメンバリスト管理手段を備えたこと、
を特徴とするコミュニティ管理システム。
【請求項３】
前記メンバリスト管理手段は、前記承認者決定情報にて決定される複数メンバのうち、所定の人数以上のメンバから承認が得られたことを条件に、前記メンバリストへの登録処理又は前記メンバリストからの削除処理を実行すること、
を特徴とする請求項１又は２に記載のコミュニティ管理システム。
【請求項４】
前記メンバリスト管理手段は、コミュニティのメンバからの招待又は参加受諾を受けていることを条件に、該メンバリストへの登録申込を受け付け、
更に、前記メンバリストへの登録時に、該メンバと招待者又は参加受諾者との親子関係を示すメンバ関係情報を保持するとともに、
任意のメンバリストに対する登録申込又は削除申込に対し承認権限が与えられるメンバが、前記承認者決定情報に定められた数だけ前記メンバ関係情報を親側に辿ることにより決定されること、
を特徴とする請求項１乃至３いずれか一に記載のコミュニティ管理システム。
【請求項５】
前記承認権限の行使用サイトを構成するＷｅｂサーバを含み、
前記承認権限の行使用サイトへのアドレスを含んだ承認依頼メールを用いて、前記メンバへ承認依頼が行われ、
前記メンバリスト管理手段は、前記Ｗｅｂサーバ経由で入力された承認結果に基づいて、該メンバリストへの登録処理又は前記メンバリストからの削除処理を実行すること、
を特徴とする請求項１乃至４いずれか一に記載のコミュニティ管理システム。
【請求項６】
任意のコミュニティへの参加意思を確認するための参加意思確認用サイトを構成するＷｅｂサーバを含み、
前記参加意思確認用サイトへのアドレスを含んだ招待メールを用いて、未参加メンバへの招待が行われ、
前記メンバリスト管理手段は、前記Ｗｅｂサーバ経由で入力された参加意思確認結果に基づいて、メンバリストへの登録申込を受け付けること、
を特徴とする請求項１乃至５いずれか一に記載のコミュニティ管理システム。
【請求項７】
前記メンバリスト管理手段からの課金情報により課金処理を行う課金サーバを備えること、
を特徴とする請求項１乃至６いずれか一に記載のコミュニティ管理システム。
【請求項８】
前記課金情報による課金額が、前記承認者決定情報を用いたメンバリストへの登録処理の回数に応じて増大していくこと、
を特徴とする請求項７に記載のコミュニティ管理システム。
【請求項９】
前記メンバリスト管理手段が、新規のコミュニティの開設時に、前記課金サーバに対して課金情報を発行すること、
を特徴とする請求項７又は８に記載のコミュニティ管理システム。
【請求項１０】
前記メンバリストがメーリングリストであること、
を特徴とする請求項１乃至９いずれか一に記載のコミュニティ管理システム。
【請求項１１】
メンバリストに登録されたメンバで構成されるコミュニティを管理するコミュニティ管理システムにおけるコミュニティの新規メンバの登録方法であって、
前記コミュニティ管理システムが、任意のメンバリストについてメンバの登録申込が行われる度に該登録申込に対する承認権限を有するメンバをその都度決定するための承認者決定情報の設定を受け付けるステップと、
前記メンバリストに対する登録申込に対し、前記コミュニティ管理システムが、前記承認者決定情報により決定されたメンバから承認を得られているか否かを確認した後、該メンバリストへの登録処理を行うステップと、を含むこと、
を特徴とするコミュニティの新規メンバの登録方法。
【請求項１２】
メンバリストに登録されたメンバで構成されるコミュニティを管理するコミュニティ管理システムにおけるコミュニティからの既存メンバの削除方法であって、
前記コミュニティ管理システムが、任意のメンバリストについてメンバの削除申込が行われる度に該削除申込に対する承認権限を有するメンバをその都度決定するための承認者決定情報の設定を受け付けるステップと、
前記メンバリストからの削除申込に対し、前記コミュニティ管理システムが、前記承認者決定情報により決定されたメンバから承認を得られているか否かを確認した後、該メンバリストからの削除処理を行うステップと、を含むこと、
を特徴とするコミュニティからの既存メンバの削除方法。
【請求項１３】
メンバリストに登録されたメンバで構成されるコミュニティを管理するコミュニティ管理システムを構成するコンピュータに実行させるメンバリスト管理プログラムであって、
任意のメンバリストについてメンバの登録申込が行われる度に該登録申込に対する承認権限を有するメンバをその都度決定するための承認者決定情報の設定を受け付ける処理と、
前記メンバリストに対する登録申込に対して、前記承認者決定情報により決定されたメンバから承認を得られているか否かを確認する処理と、
前記確認の結果、前記承認権限を有するメンバからの承認を得られている場合に、前記メンバリストに前記登録申込者を登録する処理と、を前記コンピュータに実行させるプログラム。
【請求項１４】
メンバリストに登録されたメンバで構成されるコミュニティを管理するコミュニティ管理システムを構成するコンピュータに実行させるメンバリスト管理プログラムであって、
任意のメンバリストについてメンバの削除申込が行われる度に該削除申込に対する承認権限を有するメンバをその都度決定するための承認者決定情報の設定を受け付ける処理と、
前記メンバリストに対する削除申込に対して、前記承認者決定情報により決定されたメンバから承認を得られているか否かを確認する処理と、
前記確認の結果、前記承認権限を有するメンバからの承認を得られている場合に、前記メンバリストから前記削除申込者を削除する処理と、を前記コンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コミュニティ管理システム、そのメンバ管理方法及び該方法を実施するためのプログラムに関し、特に、メンバを列記したメンバリストを用いて管理されるコミュニティの管理システム、そのメンバリストの管理方法及び該方法を実施するためのプログラムに関する。
【背景技術】
【０００２】
メンバを列記したリストを用いて管理されるコミュニティ（特定の目的を持った集団）として、インターネットサービスプロバイダや企業内におけるメーリングリストが挙げられる。また、ピアツーピア型やサーバ型のファイル共有システムにおいても、メンバ管理が行われており、これらもメンバを列記したリストを用いて管理されるコミュニティということができる。
【０００３】
前者のメーリングリストにおいては、「ｍａｊｏｒｄｏｍｏ」や「ｆｍｌ」といったソフトウェアやその他有償のソフトウェアが多数提供されており、これらを用いたメンバ管理が広く行われている。
【０００４】
図２６に、上記メーリングリストの管理・運営用のソフトウェアが導入されたコニュミティ管理システムの基本的な構成を示す。この従来のコミュニティ管理システムは、メールサーバと、メンバのハンドル名やメールアドレス等を保持するメーリングリスト管理情報を管理するメーリングリスト管理手段と、メンバから発信されたメールを他のメンバに転送するメーリングリスト処理手段と、ユーザが利用するクライアント端末とメールサーバとから構成されている。
【０００５】
このような構成を有する従来のコミュニティ管理システムは、概略次のように動作する。まず、メーリングリスト管理情報は、メーリングリスト管理者、あるいは、サーバの管理者によって管理される。これら管理者は、メーリングリストの開設を希望するユーザやメンバ追加を希望するユーザからの要望に応じて、クライアント端末を介して、メーリングリスト管理情報に対して、新たなメーリングリスト名や既存メーリングリストへのメンバの登録を行う。
【０００６】
当該コミュニティ管理システムにメーリングリストへの自動登録機能がある場合は、メーリングリストへの加入を希望するユーザは、クライアント端末からメーリングリスト加入専用メールアドレスに対して、自己のメールアドレス等を含んだ加入依頼メールを送付する。加入依頼メールを受け取ったメールサーバは、メーリングリスト管理手段に対し当該ユーザの登録依頼メールを送付する。メーリングリスト管理手段は、登録依頼メールの内容に従って、当該ユーザのメールアドレスをメーリングリスト管理情報へ追加する。メーリングリストからの脱退も同様に自動処理することが可能である。
【０００７】
一方、メンバよりメーリングリスト宛に送信されたメールは、メールサーバからメーリングリスト処理手段へ送られる。メーリングリスト処理手段は、メーリングリスト管理情報に基づいて、メーリングリスト名をメーリングリストのメンバのメールアドレスに変換し、メーリングリストのメンバに対し、メールサーバ経由で当該メールを送信する。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上記のとおり、従来のコミュニティ管理システム、特にメーリングリストにおいては、メンバ登録（追加）・削除といったメンバ管理の負荷が管理者に掛かり過ぎるとともに、当該管理者が不在の時には、メンバの登録・削除ができないという問題点がある。
【０００９】
また、上記自動登録機能を用いた場合、上記管理者の負荷が解消され、また、メンバの即時登録・脱退が可能となるが、参加意思の希薄な不特定多数のユーザが登録可能となってしまうという問題点がある。また、自動退会機能を付加すると、コミュニティの中心的なメンバの退会に制限が効かなくなり、コミュニティ自体が変容を来たしてしまうことも指摘されている。
【００１０】
上記の点は、ファイル共有システムも同様であり、不特定多数のユーザが何ら監視機能が働くことなく利用可能となっているため、その本来の目的を逸脱したファイル交換が行われてしまう背景ともなっている。
【００１１】
本発明は、上記した各事情に鑑みてなされたものであって、その目的とするところは、メンバリストに登録されたメンバで構成されるコミュニティにおける上記メンバリストの管理負荷が管理者に集中しないよう構成するとともに、コミュニティの変容に一定の歯止めが掛けられるコミュニティ管理システムを提供することにある。
【課題を解決するための手段】
【００１２】
本発明の第１の視点によれば、メンバリストに登録されたメンバで構成されるコミュニティを管理するコミュニティ管理システムであって、前記メンバリストについてメンバの登録申込が行われる度に、該登録申込に対する承認権限を有するメンバをその都度決定するための承認者決定情報を含むメンバリスト管理情報を保持するとともに、前記メンバリストに対する登録申込に対し、前記承認者決定情報により決定されたメンバから承認を得られているか否かを確認した後、該メンバリストへの登録処理を行うメンバリスト管理手段を備えたこと、を特徴とするコミュニティ管理システム、その新規メンバ登録方法及び該方法を実施するためのプログラムが提供される。
【００１３】
また、本発明の第２の視点によれば、メンバリストに登録されたメンバで構成されるコミュニティを管理するコミュニティ管理システムであって、前記メンバリストについてメンバの削除申込が行われる度に、該削除申込に対する承認権限を有するメンバをその都度決定するための承認者決定情報を含むメンバリスト管理情報を保持するとともに、前記メンバリストからの削除申込に対し、前記承認者決定情報により決定されたメンバから承認を得られているか否かを確認した後、該メンバリストからの削除処理を行うメンバリスト管理手段を備えたこと、を特徴とするコミュニティ管理システム、その既存メンバ削除方法及び該方法を実施するためのプログラムが提供される。
【発明の効果】
【００１４】
本発明によれば、コミュニティ構成員を管理するメンバリストの管理に関する負荷を、他のメンバに適宜移転可能とするとともに、野放図なメンバ登録によるコミュニティの変容を抑止することが可能となる。その理由は、メンバリスト毎に設定可能な承認者決定情報により任意のメンバを指定し、メンバ入退会の承認権限を付与可能としたことにある。
【発明を実施するための最良の形態】
【００１５】
［第１の実施形態］
続いて、本発明を実施するための最良の形態について図面を参照して詳細に説明する。図１は、本発明をメーリングリストに適用した本発明の第１の実施形態に係るコミュニティ管理システムの構成を表したブロック図である。
【００１６】
図１を参照すると、複数のクライアント端末１０ａ〜１０ｃと、複数のメールサーバ２０ａ〜２０ｄと、Ｗｅｂサーバ３０と、メーリングリストへのメンバ登録、メンバ削除、承認処理を行うメーリングリスト管理手段４０と、メーリングリストに送られてきたメールをメーリングリストのメンバへ分配配信するメーリングリスト処理手段５０と、メーリングリストの利用に対する課金を行う課金サーバ６０と、メーリングリストに属するメンバ情報を管理するメーリングリスト管理情報８０と、メーリングリストへ誰が誰を招待したかというメンバ間の招待／被招待関係を保持する招待関係情報９０（メンバ関係情報）とが示されている。
【００１７】
クライアント端末１０ａ〜１０ｃは、Ｗｅｂサーバ３０を介して、メーリングリスト関連処理（メーリングリスト作成、メーリングリストメンバ追加申請（申込）、メーリングリストメンバ追加承認、メーリングリストメンバ離脱申請（申込）、メーリングリストメンバ離脱承認）を行うパーソナルコンピュータ、携帯端末等の情報処理装置である。また、クライアント端末１０ａ〜１０ｃは、それぞれ自己のアカウントを有するメールサーバ２０ａ〜２０ｃを介してメーリングリスト処理手段５０から発信された電子メールを受信する端末ともなる。
【００１８】
なお、図１では、クライアント端末１０ａ〜１０ｃ、メールサーバ２０ａか〜２０ｃとそれぞれ３台記載しているが、説明上３台としているだけであり、実際は、それぞれｎ台、ｍ台の構成となる。
【００１９】
メールサーバ２０ａ〜２０ｃは、メールサーバ２０ｄからのメールの配送を受けて、クライアント端末１０ａ〜１０ｃからのメール受信指示が来るまで配送されたメールを保持する。クライアント端末１０ａ〜１０ｃからメール受信指示があると、保持していたメールをクライアントへ送信する。通常、メールサーバは複数のユーザ宛のメールを保持できるが、ここでは説明を簡略化するため、クライアント端末１０ａを利用するユーザ宛のメールはメールサーバ２０ａで保持し、クライアント端末１０ｂを利用するユーザ宛のメールはメールサーバ２０ｂで保持し、クライアント端末１０ｃを利用するユーザ宛のメールはメールサーバ２０ｃで保持するものとする。
【００２０】
メールサーバ２０ｄは、メーリングリスト宛のメールを他のメールサーバから受信すると、そのメールをメーリングリスト処理手段５０へ渡す。またメーリングリスト処理手段５０及びメーリングリスト管理手段４０からメール送信指示を受け取り、該当するメールサーバへメールを配信する。
【００２１】
Ｗｅｂサーバ３０は、メーリングリストの開設や設定変更、各種申請の承認、新規参加者の紹介、メールの閲覧等のメニューを提供するポータルサイトを構成するサーバであり、クライアント端末１０ａ〜１０ｃからの要求に応じて、上記各処理を行うための入力画面等を送信し、メーリングリスト管理手段とのユーザインターフェースを提供する。
【００２２】
なお、ここまでに述べたクライアント、メールサーバ、Ｗｅｂサーバは、市販されているハードウェア及びソフトウェアを用いて実現可能である。
【００２３】
メーリングリスト管理手段４０は、メーリングリストの開設や設定変更、各種申請の承認、新規参加者の紹介、メールの閲覧等の処理（以下、メーリングリスト関連処理ともいう）を行うためのＷｅｂページを生成し、該Ｗｅｂページに入力された情報を受け取り、メーリングリスト関連処理を行う。
【００２４】
また、メーリングリスト管理手段４０は、メーリングリスト関連処理において、メンバによる承認が必要な場合に、該当するメンバへ承認を依頼するためのメールを生成し、生成したメールをメールサーバ２０ｄへ送信する。さらに、メーリングリスト管理手段４０は、メーリングリストが新規に開設された場合とメーリングリストからメンバが削除された場合にはメーリングリスト管理情報８０を更新し、メーリングリストにメンバが追加された場合はメーリングリスト管理情報８０と招待関連情報９０を更新する。
【００２５】
また、メーリングリスト管理手段４０は、メーリングリスト毎に課金フラグを保持しており、課金フラグがＯＮである場合には、メンバの追加／削除時にその都度課金を行うべく課金サーバ６０に送信する課金額をカウントアップし、課金フラグがＯＦＦである場合には、メンバの追加／削除については課金を行わないといった細かい課金処理を実行可能となっている。
【００２６】
メーリングリスト処理手段５０は、メーリングリスト宛のメールを受け取ったときにメールサーバ２０ｄからメーリングリスト宛のメールを受け取り、メーリングリスト管理情報８０を利用してメーリングリストのメールアドレスを、メーリングリストの各メンバのメールアドレスに変換し、メールサーバ２０ｄへ返却する処理を行って、任意のメンバの発言を他のメンバに伝達する。
【００２７】
課金サーバ６０は、メーリングリスト管理手段４０より適宜送信される課金情報を受け取り、メーリングリストの利用に対する課金を行う。
【００２８】
メーリングリスト管理情報８０は、メーリングリストのメールアドレス（メールリスト名）と、メーリングリストに属するメンバのメールアドレス（管理者及びメンバ）と、メーリングリストのメンバ追加／削除申請に対する承認者を決定する承認者決定情報として確認範囲情報と、を保持する。
【００２９】
図２は、メーリングリスト管理情報８０の内容の一例を表した図である。図２の例では、メーリングリストのメールアドレス（メーリングリスト名）と、メーリングリストを作成した管理者のメールアドレス（管理者アドレス）と、メーリングリストのメンバのメールアドレス（メンバアドレス）と、承認者を決定するための数値で設定される確認範囲と、から構成されている。
【００３０】
この確認範囲とは、例えば、メンバＡ（親）がメンバＢ（子）を招待（追加）し、メンバＢ（子）がメンバＣ（孫）を招待（追加）しており、（Ａ→Ｂ→Ｃ）という親子関係が成立する場合に、メンバＣ（孫）がメンバＤ（曾孫）を招待する際に、メンバＤ（曾孫）の参加申請について、承認を得べきメンバを決定するため上記親子関係（招待／被招待関係）を辿る段階数を表している。例えば、確認範囲が「２」であれば、追加されるメンバＤから２段階辿ったメンバＢの承認が必要なことを意味する。同様に、確認範囲が２、１であれば、メンバＢ承認後、メンバＣの承認が必要なことを示している。
【００３１】
例えば、図２の「ａａａ＠ｘｘｘ．ｊｐ」とのメールアドレスで特定されるメーリングリストには、「ａ１＠ｘｘｘ．ｊｐ」とのメールアドレスを有する管理者（親）と、「ａ２＠ｓｓｓ．ｊｐ」、「ａ３＠ｔｔｔ．ｊｐ」とのメールアドレスを有する２人のメンバ（子、孫）が所属しており、その確認範囲としては、「２」が設定されている。例えば、「ａ３＠ｔｔｔ．ｊｐ」とのメールアドレスを有するメンバから紹介を受けた者の参加申込に対しては、招待／被招待関係を２段階辿ったユーザ（管理者）が承認権限を有することとなる。また、確認範囲情報としては、「２、３」、「１−３」という具合に、所定のデリミタやハイフンを用いて複数の確認範囲を設定することも可能である。
【００３２】
招待関係情報９０は、メーリングリストへ誰が誰を招待し、誰が承認したかというメンバ間の関係情報を保持する。
【００３３】
図３は、招待関係情報９０の内容の一例を表した図である。図３の例では、招待関係情報９０は、メーリングリストアドレスであるメーリングリスト名と、ユーザを招待した招待者アドレスと、招待された被招待者アドレスと、メーリングリストに追加するときに承認したユーザのアドレスである承認者アドレスと、から構成されている。
【００３４】
例えば、図３の第１行目３０１には、メーリングリスト「ａａａ＠ｘｘｘ．ｊｐ」に、「ａ１＠ｘｘｘ．ｊｐ」が「ａ２＠ｓｓｓ．ｊｐ」を招待し、「ａ１＠ｘｘｘ．ｊｐ」が承認を行ったことを読み取ることができる。図３の第２行目３０２には、メーリングリスト「ａａａ＠ｘｘｘ．ｊｐ」に、「ａ２＠ｓｓｓ．ｊｐ」が「ａ３＠ｔｔｔ．ｊｐ」を招待し、「ａ１＠ｘｘｘ．ｊｐ」が承認を行ったことを読み取ることができる。
【００３５】
続いて、本実施形態の動作について、フローチャート及び入力画面のイメージ図等を用いて詳細に説明する。
【００３６】
［メーリングリスト開設］
図４は、メーリングリストが開設されるまでの流れを表したフローチャートである。図４を参照すると、メーリングリストの開設を望むユーザが、クライアント端末を用いて、予め入手しておいたＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）にてＷｅｂサーバ３０にアクセスし、メーリングリスト開設（作成）を要求する（ステップＳ４０１）。なお、以下詳しい説明は省略するが、Ｗｅｂサーバ３０へアクセスする際には、適宜、メールアドレス又はＩＤと、パスワードの組み合わせ等の公知の方法により、ユーザ認証が行われているものとする。
【００３７】
図５は、Ｗｅｂサーバ３０より要求されるメーリングリスト開設（作成）時の入力項目を説明するための画面イメージ図である。図５の例では、メーリングリスト作成画面は、メーリングリストを作成するユーザのメールアドレス（管理者アドレス）、メーリングリスト名、メンバの追加時の承認要否、確認範囲の各入力欄と、作成ボタンを含んで構成されている。
【００３８】
ユーザが、図５のメーリングリスト作成画面の必要項目に入力し（ステップＳ４０２）、作成ボタンを押下すると（ステップＳ４０３）、Ｗｅｂサーバ３０は、メーリングリスト作成画面に入力された内容をメーリングリスト管理手段４０へ渡す（ステップＳ４０４）。
【００３９】
メーリングリスト管理手段４０は、メーリングリストの作成について課金するため、課金サーバ６０に対して課金に必要となる情報を送信する（ステップＳ４０５）。例えば、課金するユーザを識別するためのＩＤ、課金額、決済サービス名等が、課金サーバ６０に対して送信される。
【００４０】
続いて、メーリングリスト管理手段４０は、Ｗｅｂサーバ３０から受け取ったメーリングリスト名や管理者アドレス、確認範囲等をメーリングリスト管理情報８０に追加更新する（ステップＳ４０６）。
【００４１】
図６は、図２の状態から図５の各入力内容にて「ｄｄｄ＠ｘｘｘ．ｊｐ」なるメーリングリストが開設された後のメーリングリスト管理情報の状態を表した図である。
【００４２】
［メンバ追加］
図７は、メーリングリストにメンバが追加される過程を表したフローチャートである。図７を参照すると、まず、任意のユーザにメーリングリストへの参加を望むメンバ（招待メンバ）が、Ｗｅｂサーバ３０にアクセスし、メーリングリスト名、自分のメールアドレス、当該招待対象のユーザ（被招待者）のメールアドレス等を入力・送信する（ステップＳ７０１）。以下、招待メンバは、クライアント端末１０ａを利用、被招待者はクライアント端末１０ｂを利用、参加を承認するメンバはクライアント端末１０ｃを利用しているものとし、クライアント端末１０ａはメールサーバ２０ａから、クライアント端末１０ｂはメールサーバ２０ｂから、クライアント端末１０ｃはメールサーバ２０ｃからそれぞれメールを受信するものとして説明する。
【００４３】
図８は、メーリングリストに招待する際に、Ｗｅｂサーバ３０より要求される入力項目を説明するための画面イメージ図である。図８の例では、メーリングリストメンバ招待画面は、メーリングリスト名、招待するユーザのメールアドレス（あなたのメールアドレス）、当該メーリングリストへ新たに招待されるユーザのメールアドレス（クライアント端末１０ｂのユーザ）、招待されるユーザに対するメッセージの各入力欄と、招待依頼ボタンを含んで構成されている。
【００４４】
図８に示したように各項目を入力した上で招待依頼ボタンを押下すると、入力した内容がＷｅｂサーバ３０からメーリングリスト管理手段４０へ伝えられる。
【００４５】
続いて、メーリングリスト管理手段４０は、Ｗｅｂサーバ３０から受け取ったメーリングリストや招待するユーザに関する情報に基づいてメーリングリスト招待確認画面を作成しＷｅｂサーバ３０へ渡す（ステップＳ７０２）。このとき、メーリングリスト管理手段４０は、メーリングリスト招待確認画面へアクセスするためのＵＲＬも取得しておく。
【００４６】
続いて、メーリングリスト管理手段４０は、ステップＳ７０１にて入力された招待するユーザ（被招待者）に対する招待メールを作成し、メールサーバ２０ｄへ送信する（ステップＳ７０３）。招待メールは、メールサーバ２０ｄ、メールサーバ２０ｂを介して、クライアント端末１０ｂに送信される。
【００４７】
図９は、招待メールの一例を表した図である。招待メールは、ヘッダと本文から構成され、本文にはメーリングリストメンバ招待画面で入力したメッセージ、メーリングリスト招待確認画面のＵＲＬが必ず含まれているものとする。これ以外の本文の内容については、あらかじめテンプレートとして準備しておけば良い。また、このときのメールの発信者は招待をしたユーザのメールアドレスを用いるものとしてもよいが、招待メール発信用アドレスを用いることとしてもよい。
【００４８】
図１０は、図９の招待メールに含まれるＵＲＬにてＷｅｂサーバ３０にアクセスした際に表示されるメーリングリスト招待確認画面の例である。図１０を参照すると、メーリングリスト招待確認画面は、メーリングリスト名とメーリングリストに新たに招待されるユーザのメールアドレスの各入力欄と、参加／不参加の意思決定を行うボタンと、を含んで構成されている。また、提示されたメールアドレスと別のメールアドレスに変更することも可能であり、当該メーリングリストに当該別のメールアドレスで参加することが可能となっている。
【００４９】
ステップＳ７０４でユーザがメーリングリスト参加確認画面の「参加」又は「不参加」ボタンを押下すると、Ｗｅｂサーバ３０は、メーリングリスト管理手段４０に対して参加情報を送信し、ユーザが招待を受けたか否かを送信する。参加情報は、メーリングリスト名、招待するユーザのメールアドレス、招待を受けるユーザのメールアドレス及びメーリングリストへの参加フラグ等から構成される。この参加フラグは、参加ボタンを押下した場合はＯＮに、不参加ボタンを押下した場合はＯＦＦになるものとする。
【００５０】
メーリングリスト管理手段４０は、Ｗｅｂサーバ３０から受け取った参加情報の参加フラグがＯＮである場合は（ステップＳ７０５のＹ）、後述する方法により当該参加に対する承認メンバを決定する（ステップＳ７０６）。
【００５１】
ステップＳ７０６にて承認メンバが決定できた場合（承認メンバが存在）は（ステップＳ７０６のＹ）、メーリングリスト管理手段４０は、内部的な処理フラグである課金フラグをＯＮにする（ステップＳ７０７）。更に、メーリングリスト管理手段４０は、ステップＳ７０６で決定した承認メンバに対して、承認依頼メールを作成してメールサーバ２０ｄに送信する。メールサーバ２０ｄは、承認メンバ（クライアント端末１０ｃ）のメールサーバ２０ｃに対して受け取った承認依頼メールを送信する（ステップＳ７０８）。
【００５２】
図１１は、承認依頼メールの一例を表した図である。承認依頼メールの本文には紹介者と被紹介者に関する情報と、後記するメーリングリスト参加承認画面のＵＲＬが必ず含まれているものとする。
【００５３】
承認メンバは、クライアント端末１０ｃを操作して、メールサーバ２０ｃより受信した承認依頼メールを参照し、該メールに記載されているメーリングリスト参加承認画面のＵＲＬへアクセスし、承認可否を入力する（ステップＳ７０９）。
【００５４】
図１２は、図１１の承認依頼メールに含まれるＵＲＬにてＷｅｂサーバ３０にアクセスした際に表示されるメーリングリスト参加承認画面の例である。図１２を参照すると、メーリングリスト参加承認画面は、メーリングリスト名とメーリングリストに新たに招待されるユーザのメールアドレスと、承認メンバのメールアドレスの入力欄と、承認／拒否ボタンを含んで構成されている。
【００５５】
ステップＳ７０９にて、承認メンバがメーリングリスト参加承認画面の承認／拒否ボタンを押下すると、Ｗｅｂサーバ３０は、メーリングリスト参加承認画面にて入力されたメーリングリスト名、被招待ユーザメールアドレス、承認ユーザメールアドレス及びメーリングリストへの承認フラグといった各情報をメーリングリスト管理手段４０に送信する。ここで、承認ボタンが押下された場合は、承認フラグはＯＮに、拒否ボタンが押下された場合は、承認フラグはＯＦＦになるものとする。
【００５６】
ここで、承認フラグがＯＮであるが（ステップＳ７１０のＹ）、他に承認メンバが存在する場合は（ステップＳ７１１のＹ）、メーリングリスト管理手段４０は、ステップＳ７０８からの処理を繰り返す。一方、他に承認メンバが存在しない場合は（ステップＳ７１１のＮ）、メーリングリスト管理手段４０は、保持している課金フラグを参照し、課金フラグがＯＮの場合は（ステップＳ７１２のＹ）、課金サーバ６０へ課金情報を送信し、承認サービスに対する課金処理を依頼する（ステップＳ７１３）。
【００５７】
ステップＳ７１３の課金処理の依頼後、又は、すべての承認メンバから承認を得、かつ、課金フラグがＯＦＦである場合（ステップＳ７１２のＮ）、メーリングリスト管理手段４０は、メーリングリスト管理情報８０の該当するメーリングリストのメンバアドレスに被招待ユーザのメールアドレスを追記する（ステップＳ７１４）。更に、メーリングリスト管理手段４０は、招待関連情報９０に、メーリングリスト名、メーリングリストへの招待アドレス、被招待者アドレス、承認メンバアドレスを追記する（ステップＳ７１５）。
【００５８】
図１３、図１４は、図２、図３の状態から、図８、図９、図１２の各入力内容にて「ａ４＠ｕｕｕ．ｊｐ」とのメールアドレスを持つユーザ（被招待者）が、メーリングリスト「ａａａ＠ｘｘｘ．ｊｐ」のメンバとして登録された状態のメーリングリスト管理情報８０、招待関連情報９０を表した図である。
【００５９】
最後に、メーリングリスト管理手段４０は、招待メンバ及び招待を受けたユーザ（被招待者）に対して、参加が承認されたことを通知する参加承認メールを作成し、メールサーバ２０ｄへ送信する（ステップＳ７１６）。参加承認メールは、メールサーバ２０ｄ、メールサーバ２０ａ、２０ｂを介して、クライアント端末１０ａ、１０ｂに送信される。図１５は、招待を受けたユーザ（被招待者）に宛てられた参加承認メールの一例を表した図である。
【００６０】
一方、ステップＳ７０５にて、招待を受けたユーザ（被招待者）が招待確認画面（図１０参照）の「不参加」ボタンを押下すると、Ｗｅｂサーバ３０は、当該ユーザがメーリングリストへ参加しないことをメーリングリスト管理手段４０へ伝える（ステップＳ７０５のＮ）。この場合、メーリングリスト管理手段４０は、招待メンバに対して、被招待ユーザに参加の意思がなかったことを伝える不参加通知メールを作成し、送信する（ステップＳ７１８）。
【００６１】
また、ステップＳ７１０にて、承認フラグがＯＦＦ、即ち、承認メンバが参加承認依頼に対して拒否を行った場合は（ステップＳ７１０のＮ）、メーリングリスト管理手段４０は、招待メンバ、被招待ユーザに対して承認拒否通知メールを作成し、送信する。図１６は、招待メンバに宛てられた承認拒否通知メールの一例を表した図である（ステップＳ７１７）。
【００６２】
［承認メンバの決定］
ここで、上記メンバ追加フローのステップＳ７０６、Ｓ７１１における承認メンバの決定方法について、図１７のフローチャートを参照して詳細に説明する。以下、図１０の「参加」ボタンが押下され、Ｗｅｂサーバ３０を介して、図８の各入力項目に相当する参加情報がメーリングリスト管理手段４０に送信されたものとして説明する。
【００６３】
はじめに、メーリングリスト管理手段４０は、メーリングリスト管理情報８０（図２参照）から、参加情報のメーリングリスト名（図８参照）に合致する行を抽出する（ステップＳ１７０１）。
【００６４】
ここで、ステップＳ１７０１にて抽出した行の確認範囲情報が０の場合は（ステップＳ１７０２のＹ；図２のメーリングリスト「ｃｃｃ＠ｘｘｘ．ｊｐ」参照）、メーリングリスト管理手段４０は、承認メンバの承認が不要と設定されたメーリングリストであり、承認メンバなしと判定する（ステップＳ１７１３）。
【００６５】
一方、ステップＳ１７０１にて抽出した行の確認範囲情報が１の場合は（ステップＳ１７０３のＹ；図２のメーリングリスト「ｂｂｂ＠ｘｘｘ．ｊｐ」参照）、メーリングリスト管理手段４０は、承認メンバ＝招待ユーザと判定する（ステップＳ１７１４）。
【００６６】
更に、ステップＳ１７０１にて抽出した行の確認範囲情報が２以上の場合は（ステップＳ１７０３のＮ；図２のメーリングリスト「ａａａ＠ｘｘｘ．ｊｐ」参照）、メーリングリスト管理手段４０は、招待関係情報９０（図３参照）から参加情報のメーリングリスト名に合致する行を抽出し、抽出結果をαとする（ステップＳ１７０４）。例えば、図３の招待関係情報９０に対し、メーリングリスト名「ａａａ＠ｘｘｘ．ｊｐ」を検索した場合、抽出結果αは行３０１、３０２となる。
【００６７】
ステップＳ１７０４にて、合致する行が存在せず抽出行が０である場合は（ステップＳ１７０５のＹ）、メーリングリスト管理手段４０は、承認メンバ＝メーリングリスト管理者と判定する（ステップＳ１７１５）。例えば、確認範囲情報が２であるがメンバが存在しない、図６のメールリングリスト「ｄｄｄ＠ｘｘｘ．ｊｐ」に対し参加情報が送られた場合がこのケースに該当する。
【００６８】
一方、ステップＳ１７０４にて抽出結果αを抽出できた場合は（ステップＳ１７０５のＮ）、メーリングリスト管理手段４０は、参加情報の招待メンバ名（図８のあなたのメールアドレス）が被招待者アドレスに合致する行を抽出結果αから抽出し、抽出結果βを得る（ステップＳ１７０６）。
【００６９】
ここで、抽出結果βを抽出できなかった場合は（ステップＳ１７０７のＹ）、メーリングリスト管理手段４０は、承認メンバ＝メーリングリスト管理者と判定する（ステップＳ１７１５）。
【００７０】
一方、ステップＳ１７０６にて、抽出結果βを抽出できた場合（ステップＳ１７０７のＮ）、メーリングリスト管理手段４０は、内部変数ｉに２を代入する（ステップＳ１７０８）。例えば、図３の招待関係情報９０に対し、メーリングリスト名「ａａａ＠ｘｘｘ．ｊｐ」、かつ、被招待者アドレスが「ａ３＠ｔｔｔ．ｊｐ」である行を検索した場合、抽出結果βとして行３０２が得られ、このケースに該当する。
【００７１】
続いて、メーリングリスト管理手段４０は、内部変数ｉが確認範囲情報と等しいか否かを判定し、内部変数ｉ＝確認範囲情報である場合は（ステップＳ１７０９のＹ）、承認メンバ＝抽出結果βの招待者アドレスと判定する（ステップＳ１７１６）。例えば、抽出結果βとして行３０２が得られている場合、承認メンバは、招待メンバ「ａ３＠ｔｔｔ．ｊｐ」の本メーリングリスト参加時の招待者である「ａ２＠ｓｓｓ．ｊｐ」となる。
【００７２】
一方、内部変数ｉが確認範囲情報と等しくない場合は（ステップＳ１７０９のＮ）、メーリングリスト管理手段４０は、抽出結果αから、抽出結果βの招待者アドレスが被招待者アドレスとして含まれる行を検索し、その抽出結果γを得る（ステップＳ１７１０）。
【００７３】
ここで、抽出結果γを抽出できなかった場合は（ステップＳ１７１１のＹ）、メーリングリスト管理手段４０は、承認メンバ＝メーリングリスト管理者と判定する（ステップＳ１７１５）。
【００７４】
一方、抽出結果γを抽出できた場合は、内部変数ｉを１増加するとともに、抽出結果βの内容を抽出結果γに置き換え（ステップＳ１７１２）、ステップＳ１７０９移行の処理を実行する。これにより、招待関係情報９０の招待／被招待の親子関係を、確認範囲情報で制定された段階分辿っていき、承認メンバを決定することが可能となる。
【００７５】
なお、ここでは、メーリングリスト管理情報８０に記載される確認範囲情報が１つのみ存在する場合を述べているが、２以上の確認範囲情報が設定する場合は他に承認メンバが存在すると判定され（図７のステップＳ７１１のＹのケース）、本処理が繰り返し行われることとなる。例えば、確認範囲情報に、「２、３」と記載されていた場合は、最初の承認メンバ決定（図７のステップＳ７０６に相当）にて確認範囲情報「２」による承認メンバの決定が行われ、次の承認メンバ決定（図７のステップＳ７１１に相当）にて、確認範囲情報「３」による承認メンバの決定が行われることとなる。
【００７６】
［メンバ削除］
図１８は、メーリングリストからメンバが削除される過程を表したフローチャートである。図１８を参照すると、まず、任意のメンバをメーリングリストから離脱（退会）させることを望むメンバ（以下、離脱要求メンバ）が、Ｗｅｂサーバ３０にアクセスし、メーリングリスト名、自分のメールアドレス、離脱させたいメンバ（離脱メンバ）のメールアドレス等を入力・送信する（ステップＳ１８０１）。
【００７７】
図１９は、メーリングリストからの離脱要求を行う際に、Ｗｅｂサーバ３０より要求される入力項目を説明するための画面イメージ図である。図１９の例では、メーリングリストメンバ離脱依頼画面は、メーリングリスト名、あなたのメールアドレス（離脱要求メンバメールアドレス）、当該メーリングリストから新たに脱退させるユーザのメールアドレス（離脱メンバメールアドレス）、該ユーザに対するメッセージの各入力欄と、離脱確認付きで依頼ボタン、即時離脱依頼ボタン、を含んで構成されている。
【００７８】
図１９に示したように各項目を入力した上で、後述する離脱確認が必要であるか否かに応じて、離脱要求メンバが、離脱確認付きで依頼ボタン又は即時離脱依頼ボタンを押下すると、入力した内容が離脱情報として、Ｗｅｂサーバ３０からメーリングリスト管理手段４０へ伝えられる。このとき送信される離脱情報は、メーリングリスト離脱依頼画面に入力された各項目内容及び離脱確認フラグから構成され、具体的には、メーリングリスト名、離脱要求メンバメールアドレス、離脱メンバメールアドレス、離脱メンバに対するメッセージ、及び離脱確認フラグから構成される。この離脱確認フラグは、離脱確認付きで依頼ボタンを押下した場合はＯＮに、即時離脱依頼ボタンを押下した場合はＯＦＦになるものとする。
【００７９】
メーリングリスト管理手段４０は、Ｗｅｂサーバ３０から離脱情報を受け取ると、離脱確認フラグを確認し、離脱フラグがＯＮであれば（ステップＳ１８０２のＹ）、承認メンバを決定する（ステップＳ１８０３）。承認メンバは、招待関連情報９０から、離脱情報のメーリングリスト名が合致し、かつ、離脱情報の離脱メンバメールアドレスが招待関係情報９０の被招待者アドレスに一致する行の承認者アドレスで特定されるメンバ、即ち、当該メンバを承認した者に決定される。
【００８０】
メーリングリスト管理手段４０は、ステップＳ１８０３で決定した承認メンバに対して、メーリングリスト離脱承認依頼メールを作成・送信する（ステップＳ１８０４）。
【００８１】
図２０は、離脱承認依頼メールの一例を表した図である。離脱承認依頼メールの本文には離脱要求メンバと離脱メンバに関する情報と、後記するメーリングリスト離脱承認画面のＵＲＬが必ず含まれているものとする。
【００８２】
承認メンバは、クライアント端末を操作して、メールサーバより受信した離脱承認依頼メールを参照し、該メールに記載されているメーリングリスト離脱承認画面のＵＲＬへアクセスし、承認可否を入力する（ステップＳ１８０５）。
【００８３】
図２１は、図２０の離脱承認依頼メールに含まれるＵＲＬにてＷｅｂサーバ３０にアクセスした際に表示されるメーリングリスト離脱承認画面の例である。図２０を参照すると、メーリングリスト離脱承認画面は、メーリングリスト名とメーリングリストから離脱させるメンバのメールアドレスと、承認メンバのメールアドレスの入力欄と、承認／拒否ボタンを含んで構成されている。
【００８４】
ステップＳ１８０５にて、承認メンバがメーリングリスト離脱承認画面の承認／拒否ボタンを押下すると、Ｗｅｂサーバ３０は、メーリングリスト離脱承認画面にて入力されたメーリングリスト名、離脱要求メンバメールアドレス、離脱メンバメールアドレス、承認メンバのメールアドレス及びメーリングリストへの承認フラグから構成される離脱承認情報をメーリングリスト管理手段４０に送信する。ここで、承認ボタンが押下された場合は、承認フラグはＯＮに、拒否ボタンが押下された場合は、承認フラグはＯＦＦになるものとする。
【００８５】
Ｗｅｂサーバ３０から受け取った離脱承認情報の承認フラグがＯＮである場合（ステップＳ１８０６のＹ）、メーリングリスト管理手段４０は、他に承認メンバが存在するか否を確認し、他に承認メンバが存在する場合は（ステップＳ１８０７のＹ）、ステップＳ１８０４に戻り、当該他の承認メンバに対する承認依頼メールを生成、送信する。
【００８６】
一方、他に承認メンバが存在しない場合は（ステップＳ１８０７のＮ）、又は、ステップＳ１８０２にて離脱情報の離脱確認フラグがＯＦＦとされている場合は、メーリングリスト管理手段４０は、メーリングリスト管理情報８０の該当するメーリングリストのメンバアドレスから離脱メンバのメールアドレスを削除する（ステップＳ１８０８）。
【００８７】
図２２は、図１３の状態から、図１９の入力内容にて「ａ３＠ｔｔｔ．ｊｐ」とのメールアドレスを持つメンバが、メーリングリスト「ａａａ＠ｘｘｘ．ｊｐ」から削除された状態のメーリングリスト管理情報８０を表した図である。
【００８８】
最後に、メーリングリスト管理手段４０は、離脱要求メンバ及び離脱メンバに対して、参加が承認されたことを通知する離脱承認メールを作成し、メールサーバ２０ｄへ送信する（ステップＳ１８０９）。図２３は、上記離脱承認メールの一例を表した図である。
【００８９】
一方、ステップＳ１８０６にて、承認フラグがＯＦＦ、即ち、承認メンバが離脱承認依頼に対して拒否を行った場合は（ステップＳ１８０６のＮ）、メーリングリスト管理手段４０は、離脱要求メンバ、離脱メンバに対して離脱承認拒否通知メールを作成し、送信する（ステップＳ１８１０）。図２４は、離脱要求メンバに宛てられた離脱承認拒否通知メールの一例を表した図である。
【００９０】
以上のとおり、本実施の形態では、確認範囲情報という招待者を基準とする相対的な招待被招待関係を辿ってメーリングリストへのメンバ追加に対する承認権限を有する者を決定可能としたため、メンバ追加の際の管理者の負担が低減される。
【００９１】
また、本実施の形態では、上記確認範囲情報にて指定する数値を増減させ、あるいは、複数設定する等して、メーリングリストの性質に応じたメンバ追加基準を柔軟に設定することが可能となる。
【００９２】
また、本実施の形態では、メンバ追加時の審査処理機能の利用に対して課金できるように構成されているため、メンバ追加時に厳密な審査が必要なメーリングリストは有料、審査が必要でないあるいは審査が少ないメーリングリストは無料とする、といった管理負担の低減量に応じた対価を徴収することが可能となる。
【００９３】
なお、上記した実施形態では、メンバ追加時のみに、確認範囲情報を用いるものとして説明したが、メーリングリストの性質に応じて、メンバ削除時にも、確認範囲情報を用いた承認メンバの決定を行うものとしてもよい。例えば、あるメンバの離脱の際に、参加時に承認を行ったメンバが離脱している場合などは、より上位（親側）のメンバの承認を必要とするといった厳格なメンバ管理が可能となる。
【００９４】
［第２実施形態］
続いて、上記第１の実施形態と同様の構成にて実現可能な本発明の第２の最良の形態について図面を参照して説明する。上記第１の実施形態では、メーリングリストのメンバが任意のユーザを招待することにより参加が可能となっているが、本実施形態では、メーリングリストに参加していないユーザ側からメーリングリストのメンバに対して参加を申請する形態としたものである。
【００９５】
図２５は、第１の実施形態と動作上相違する部分を表したフローチャートであり、図７のステップＳ７０１〜Ｓ７０４に置き換えることが可能である。図２５を参照すると、まず、メーリングリストに参加を希望するユーザは、Ｗｅｂサーバ３０にアクセスし、そのメーリングリスト参加申請画面にて、メーリングリスト名、自分のメールアドレス、参加申請先となるメンバ（任意）、該メンバに宛てたメッセージ等を入力・送信する（ステップＳ２５０１）。
【００９６】
Ｗｅｂサーバ３０が、入力された内容をメーリングリスト管理手段４０へ伝達すると、メーリングリスト管理手段４０は、Ｗｅｂサーバ３０から受け取った情報に基づいてメーリングリスト参加申請画面を作成しＷｅｂサーバ３０へ渡す（ステップＳ２５０２）。このとき、メーリングリスト管理手段４０は、メーリングリスト参加申請画面へアクセスするためのＵＲＬも取得しておく。
【００９７】
続いて、メーリングリスト管理手段４０は、ステップＳ２５０１にて入力されたメーリングリストより適宜選択したメンバ、あるいは、ステップＳ２５０１にてユーザより指定されたメンバに対し、前記メーリングリスト参加申請画面へのＵＲＬを含んだ参加申請メールを作成し、メールサーバ２０ｄへ送信する（ステップＳ２５０３）。
【００９８】
前記参加申請メールを受け取ったメンバが、参加申請メールに記載されたＵＲＬにてＷｅｂサーバ３０にアクセスし、メーリングリスト参加申請画面より、参加申請の受諾可否を入力する（ステップＳ２５０４）。
【００９９】
以降は、図７における招待メンバ、被招待メンバを、それぞれ参加申請先メンバ、参加申請ユーザに読み替え、第１の実施形態と同様の手順で進めることが可能である。
【０１００】
本実施の形態では、メーリングリストへの招待という形態ではなく参加申請という形態でメンバを追加できるため、メーリングリストのメンバによる、メンバの勧誘等が不要となる。
【０１０１】
以上、本発明をメーリングリストに適用した第１、第２の実施形態を説明したが、本発明の技術的範囲は、上述した各実施形態に限定されるものではなく、メンバの加除に際して、承認者決定情報によりその都度決定されるメンバに承認権限を与えるという本発明の要旨を逸脱しない範囲で、各種の変形・置換をなしうることが可能であることはいうまでもない。本発明は、インターネットサービスプロバイダや企業内におけるメーリングリスト運営システムに適用できるほか、ピアツーピア型やサーバ型のファイル共有システムにおけるメンバ管理といった用途にも適用可能である。
【０１０２】
また、上記した実施形態では、招待メンバ又は参加申請先メンバを基準に招待関係情報を辿って承認権限を有するメンバを決定するものとして説明したが、最新の登録メンバ等を基準に承認権限を有するメンバを決定することとしてもよい。例えば、確認範囲情報（承認者決定情報）として「３」が設定されている場合、最新の登録メンバから辿って、３番目に新しく登録されたメンバ、３番目の招待／被招待関係にあるメンバに、承認権限を与えるといった変形実施も可能である。
【０１０３】
また、上記した実施形態では省略したが、更にユーザの便宜のため、コミュニティの検索機能や、各コミュニティの概要や外部から参加申請を受け付けるか否かといったコミュニティの属性情報を一覧表示する機能を備えることも可能である。
【図面の簡単な説明】
【０１０４】
【図１】本発明の第１の実施形態に係るコミュニティ管理システムの構成を表したブロック図である。
【図２】本発明の第１の実施形態に係るコミュニティ管理システムで保持されるメーリングリスト管理情報を説明するための図である。
【図３】本発明の第１の実施形態に係るコミュニティ管理システムで保持される招待関係情報を説明するための図である。
【図４】本発明の第１の実施形態に係るコミュニティ管理システムにおいてメーリングリストが開設されるまでの流れを表したフローチャートである。
【図５】本発明の第１の実施形態に係るコミュニティ管理システムにおけるメーリングリスト開設時の入力項目を説明するための画面イメージ図である。
【図６】図２の状態から新たにメーリングリストが開設され更新された状態のメーリングリスト管理情報を説明するための図である。
【図７】本発明の第１の実施形態に係るコミュニティ管理システムにおいてメーリングリストにメンバが追加される過程を表したフローチャートである。
【図８】本発明の第１の実施形態に係るコミュニティ管理システムにおけるメーリングリスト紹介時の入力項目を説明するための画面イメージ図である。
【図９】本発明の第１の実施形態に係るコミュニティ管理システムにおいて生成される招待メールの一例を表した図である。
【図１０】図９の招待メールに含まれるＵＲＬにてクライアント端末に表示されるメーリングリスト招待確認画面のイメージ図である。
【図１１】本発明の第１の実施形態に係るコミュニティ管理システムにおいて生成される承認依頼メールの一例を表した図である。
【図１２】図１１の承認依頼メールに含まれるＵＲＬにてクライアント端末に表示されるメーリングリスト参加承認画面のイメージ図である。
【図１３】図２の状態から、図８、図９、図１２の各入力内容にて更新されたメーリングリスト管理情報を表した図である。
【図１４】図３の状態から、図８、図９、図１２の各入力内容にて更新された招待関係情報を表した図である。
【図１５】本発明の第１の実施形態に係るコミュニティ管理システムにおいて招待を受けたユーザ（被招待者）に送信される参加承認メールの一例を表した図である。
【図１６】本発明の第１の実施形態に係るコミュニティ管理システムにおいて招待メンバに宛てられた承認拒否通知メールの一例を表した図である。
【図１７】本発明の第１の実施形態に係るコミュニティ管理システムにおいて承認メンバが決定される過程を表したフローチャートである。
【図１８】本発明の第１の実施形態に係るコミュニティ管理システムにおいてメーリングリストからメンバが削除される過程を表したフローチャートである。
【図１９】本発明の第１の実施形態に係るコミュニティ管理システムにおけるメーリングリスト離脱要求時の入力項目を説明するための画面イメージ図である。
【図２０】本発明の第１の実施形態に係るコミュニティ管理システムにおいて生成される離脱承認依頼メールの一例を表した図である。
【図２１】図２０の離脱承認依頼メールに含まれるＵＲＬにてクライアント端末に表示されるメーリングリスト離脱承認画面のイメージ図である。
【図２２】図１３の状態から、図１９の入力内容にて更新されたメーリングリスト管理情報を表した図である。
【図２３】本発明の第１の実施形態に係るコミュニティ管理システムにおいて生成される参加承認メールの一例を表した図である。
【図２４】本発明の第１の実施形態に係るコミュニティ管理システムにおいて生成される離脱承認拒否通知メールの一例を表した図である。
【図２５】本発明の第２の実施形態に係るコミュニティ管理システムにおける、第１の実施形態との相違部分を表したフローチャートである。
【図２６】従来のメーリングリスト管理システムの構成を示すブロック図である。
【符号の説明】
【０１０５】
１０ａ、１０ｂ、１０ｃ  クライアント端末
２０ａ、２０ｂ、２０ｃ、２０ｄ  メールサーバ
３０  Ｗｅｂサーバ
４０  メーリングリスト管理手段
５０  メーリングリスト処理手段
６０  課金サーバ
８０  メーリングリスト管理情報
９０  招待関連情報
【図１】
2007228243.tif 000003
【図２】
2007228243.tif 000004
【図３】
2007228243.tif 000005
【図４】
2007228243.tif 000006
【図５】
2007228243.tif 000007
【図６】
2007228243.tif 000008
【図７】
2007228243.tif 000009
【図８】
2007228243.tif 000010
【図９】
2007228243.tif 000011
【図１０】
2007228243.tif 000012
【図１１】
2007228243.tif 000013
【図１２】
2007228243.tif 000014
【図１３】
2007228243.tif 000015
【図１４】
2007228243.tif 000016
【図１５】
2007228243.tif 000017
【図１６】
2007228243.tif 000018
【図１７】
2007228243.tif 000019
【図１８】
2007228243.tif 000020
【図１９】
2007228243.tif 000021
【図２０】
2007228243.tif 000022
【図２１】
2007228243.tif 000023
【図２２】
2007228243.tif 000024
【図２３】
2007228243.tif 000025
【図２４】
2007228243.tif 000026
【図２５】
2007228243.tif 000027
【図２６】
2007228243.tif 000028