(57)【要約】【課題】電子会議室やメーリングリスト等のコミュニティサービス上における売り手によるセールス活動を可能にする。【解決手段】少なくとも一名の利用者が所属するグループに通信ネットワーク上のコミュニティサービスを提供するコミュニティサーバにおいて、売り手端末から、グループに対するセールス活動を希望する通知を受け取ると、売り手端末からそのコミュニティサービスへのアクセス権限を生成し、これを記憶し、グループに所属する利用者の使用する利用者端末から、売り手に対して商品などの提案依頼を希望する通知を受け取ると、売り手の使用する売り手端末からグループに提供されているコミュニティサービスへのアクセス権限を生成してこれを記憶し、売り手端末から、登録グループに提供されているコミュニティサービスへの参加要求があった場合には、アクセス権限に基づいて参加の可否を判定する。【選択図】    図６
2007157099.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも一名の利用者が所属するグループに通信ネットワーク上のコミュニティサービスを提供するコミュニティシステムにおいて、
グループにコミュニティサービスを提供するコミュニティサーバと、
利用者が使用する端末であって、前記コミュニティサーバに通信ネットワークを介して接続可能な利用者端末と、
売り手が使用する端末であって、前記コミュニティサーバに通信ネットワークを介して接続可能な売り手端末と、
を備え、
前記コミュニティサーバは：
利用者が使用する利用者端末から、前記利用者に関する情報である利用者情報と、前記利用者の所属するグループを特定する所属情報を含む、前記グループに関するグループ情報と、を受け取り、これを記憶し、
前記利用者情報及び前記グループ情報の少なくとも一方の情報に基づいて、前記グループ情報の登録を済ませたグループである登録グループに所属する、前記利用者情報の登録を済ませた利用者である登録利用者の使用する利用者端末による、前記登録グループに提供されているコミュニティサービスへのアクセスを許可し、
売り手が使用する売り手端末から、前記売り手に関する情報である売り手情報を受け取り、これを記憶し、
前記売り手情報の登録を済ませた売り手である登録売り手が使用する売り手端末から、前記登録グループに対するセールス活動を行うことを希望する通知を受け取ると、前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成し、これを売り手のアクセス権限であることを識別できる状態で記憶し、
あるいは、
前記登録グループに所属する前記登録利用者が使用する利用者端末から、前記登録売り手に商品またはサービスの提案依頼を希望する通知を受け取ると、前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成し、これを売り手のアクセス権限であることを識別できる状態で記憶し、
前記売り手端末から、前記登録グループに提供されている前記コミュニティサービスへの参加要求を受け取った場合には、前記アクセス権限に基づいて参加の可否を判定し、
前記コミュニティサービス上において、前記売り手に商品またはサービスの提案と交渉を行わせ、前記提案または前記交渉の結果、取引が成立し、前記登録利用者が使用する利用者端末から、前記登録売り手に対する注文情報を受け取り、これを記憶する際に、どの登録グループに提供されているコミュニティサービスを使用して取引が成立したのか、という情報である取引グループ情報を含む注文情報を記憶する
ことを特徴とするコミュニティシステム。
【請求項２】
少なくとも一名の利用者が所属するグループに通信ネットワーク上のコミュニティサービスを提供するコミュニティサーバにおいて、
利用者が使用する利用者端末から、前記利用者に関する情報である利用者情報と、前記利用者の所属するグループを特定する所属情報を含む、前記グループに関するグループ情報と、を受け取り、これを記憶し、
前記利用者情報及び前記グループ情報の少なくとも一方の情報に基づいて、前記グループ情報の登録を済ませたグループである登録グループに所属する、前記利用者情報の登録を済ませた利用者である登録利用者の使用する利用者端末による、前記登録グループに提供されているコミュニティサービスへのアクセスを許可し、
売り手が使用する売り手端末から、前記売り手に関する情報である売り手情報を受け取り、これを記憶し、
前記売り手情報の登録を済ませた売り手である登録売り手が使用する売り手端末から、前記登録グループに対するセールス活動を行うことを希望する通知を受け取ると、前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成し、これを売り手のアクセス権限であることを識別できる状態で記憶し、
前記売り手端末から、前記登録グループに提供されている前記コミュニティサービスへの参加要求を受け取った場合には、前記アクセス権限に基づいて参加の可否を判定する
ことを特徴とするコミュニティサーバ。
【請求項３】
前記利用者端末から、前記利用者及び前記グループの少なくとも一方に関するマーケティング情報を受け取り、これを記憶し、
前記売り手端末から、前記マーケティング情報の閲覧要求を受け取った場合に、要求に合致する前記マーケティング情報を前記売り手端末に返信し、
前記売り手端末から、返信した前記マーケティング情報に基づいて決定されたグループの選定情報を受け取る
ことを特徴とする請求項２に記載のコミュニティサーバ。
【請求項４】
前記登録売り手の使用する売り手端末による、前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成する際に、前記登録売り手に対して、交渉権料を課金する
ことを特徴とする請求項２、または請求項３に記載のコミュニティサーバ。
【請求項５】
少なくとも一名の利用者が所属するグループに通信ネットワーク上のコミュニティサービスを提供するコミュニティサーバにおいて、
利用者が使用する利用者端末から、前記利用者に関する情報である利用者情報と、前記利用者の所属するグループを特定する所属情報を含む、前記グループに関するグループ情報と、を受け取り、これを記憶し、
前記利用者情報及び前記グループ情報の少なくとも一方の情報に基づいて、前記グループ情報の登録を済ませたグループである登録グループに所属する、前記利用者情報の登録を済ませた利用者である登録利用者の使用する利用者端末による、前記登録グループに提供されているコミュニティサービスへのアクセスを許可し、
売り手が使用する売り手端末から、前記売り手に関する情報である売り手情報を受け取り、これを記憶し、
前記登録グループに所属する前記登録利用者が使用する利用者端末から、前記登録売り手に商品またはサービスの提案依頼を希望する通知を受け取ると、前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成し、これを売り手のアクセス権限であることを識別できる状態で記憶し、
前記売り手端末から、前記登録グループに提供されている前記コミュニティサービスへの参加要求を受け取った場合には、前記アクセス権限に基づいて参加の可否を判定する
ことを特徴とするコミュニティサーバ。
【請求項６】
前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成する際に、これを、有効期限情報と伴に、売り手のアクセス権限であることを識別できる状態で記憶し、
前記売り手端末から、前記登録グループに提供されている前記コミュニティサービスへの参加要求を受け取った場合には、前記アクセス権限を所持し、かつ、有効期限内である場合にのみ参加を許可する
ことを特徴とする請求項２から５のいずれかに記載のコミュニティサーバ。
【請求項７】
前記売り手端末から、セールス活動の対象とする前記登録グループに所属する前記登録利用者宛てに、広告を配信する要求を受け取った場合に、
前記アクセス権限に基づいて配信の可否を判定し、
前記登録グループに所属する前記登録利用者の内、少なくとも一人宛てに広告を送信する
ことを特徴とする請求項２から６のいずれかに記載のコミュニティサーバ。
【請求項８】
前記登録利用者が使用する利用者端末から、前記登録売り手に対する注文を受け取り、これを記憶する際に、
どの登録グループに提供されているコミュニティサービスを使用して取引が成立したのか、という情報である取引グループ情報を含む注文情報を記憶する
ことを特徴とする請求項２から７のいずれかに記載のコミュニティサーバ。
【請求項９】
前記注文情報毎に、取引額に応じて、ポイントを計算し、
前記注文情報に含まれる前記取引グループ情報を基に、前記グループ毎に、一定期間分の前記ポイントを集計し、これを割引率計算対象グループポイントとし、
同一の前記登録グループに所属する前記登録利用者同士の通話または通信の料金を計算する際に、前記割引率計算対象グループポイントを基に割引率を算出する
ことを特徴とする請求項８に記載のコミュニティサーバ。
【請求項１０】
前記登録売り手が、前記商品を前記登録利用者に受け渡す際に、前記売り手端末から商品受渡日を受け取り、これを記憶し、
前記利用者端末からユーザ登録情報を受け取り、これを記憶し、
ユーザ管理者が前記商品を購入したユーザを管理するために予め登録した前記登録グループに、前記登録利用者を構成員として登録し、これを記憶する
ことを特徴とする請求項２から９のいずれかに記載のコミュニティサーバ。
【請求項１１】
前記利用者情報と前記グループ情報を基に、前記登録利用者が所属しているグループに所属している利用者の連絡先情報リストを作成し、
前記利用者端末に送信する
ことを特徴とする請求項２から９のいずれかに記載のコミュニティサーバ。
【請求項１２】
前記登録売り手及び前記登録利用者の少なくとも一方から受け取る収益を一定期間毎に集計し、
集計結果を基に、コミュニティサービスの運営に再投資する金額を算出する
ことを特徴とする請求項２から９のいずれかに記載のコミュニティサーバ。
【請求項１３】
少なくとも一名の利用者が所属するグループに通信ネットワーク上のコミュニティサービスを提供する方法であるコミュニティサービス提供方法において、
利用者が使用する利用者端末から、前記利用者に関する情報である利用者情報と、前記利用者の所属するグループを特定する所属情報を含む、前記グループに関するグループ情報と、を受け取り、これを記憶し、
前記利用者情報及び前記グループ情報の少なくとも一方の情報に基づいて、前記グループ情報の登録を済ませたグループである登録グループに所属する、前記利用者情報の登録を済ませた利用者である登録利用者の使用する利用者端末による、前記登録グループに提供されているコミュニティサービスへのアクセスを許可し、
売り手が使用する売り手端末から、前記売り手に関する情報である売り手情報を受け取り、これを記憶し、
前記売り手情報の登録を済ませた売り手である登録売り手が使用する売り手端末から、前記登録グループに対するセールス活動を行うことを希望する通知を受け取ると、前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成し、これを売り手のアクセス権限であることを識別できる状態で記憶し、
前記売り手端末から、前記登録グループに提供されている前記コミュニティサービスへの参加要求を受け取った場合には、前記アクセス権限に基づいて参加の可否を判定する
ことを特徴とするコミュニティサービス提供方法。
【請求項１４】
前記利用者端末から、前記利用者及び前記グループの少なくとも一方に関するマーケティング情報を受け取り、これを記憶し、
前記売り手端末から、前記マーケティング情報の閲覧要求を受け取った場合に、要求に合致する前記マーケティング情報を前記売り手端末に返信し、
前記売り手端末から、返信した前記マーケティング情報に基づいて決定されたグループの選定情報を受け取る
ことを特徴とする請求項１３に記載のコミュニティサービス提供方法。
【請求項１５】
前記登録売り手の使用する売り手端末による、前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成する際に、前記登録売り手に対して、交渉権料を課金する
ことを特徴とする請求項１３、または請求項１４に記載のコミュニティサービス提供方法。
【請求項１６】
少なくとも一名の利用者が所属するグループに通信ネットワーク上のコミュニティサービスを提供する方法であるコミュニティサービス提供方法において、
利用者が使用する利用者端末から、前記利用者に関する情報である利用者情報と、前記利用者の所属するグループを特定する所属情報を含む、前記グループに関するグループ情報と、を受け取り、これを記憶し、
前記利用者情報及び前記グループ情報の少なくとも一方の情報に基づいて、前記グループ情報の登録を済ませたグループである登録グループに所属する、前記利用者情報の登録を済ませた利用者である登録利用者の使用する利用者端末による、前記登録グループに提供されているコミュニティサービスへのアクセスを許可し、
売り手が使用する売り手端末から、前記売り手に関する情報である売り手情報を受け取り、これを記憶し、
前記登録グループに所属する前記登録利用者が使用する利用者端末から、前記登録売り手に商品またはサービスの提案依頼を希望する通知を受け取ると、前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成し、これを売り手のアクセス権限であることを識別できる状態で記憶し、
前記売り手端末から、前記登録グループに提供されている前記コミュニティサービスへの参加要求を受け取った場合には、前記アクセス権限に基づいて参加の可否を判定する
ことを特徴とするコミュニティサービス提供方法。
【請求項１７】
前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成する際に、これを、有効期限情報と伴に、売り手のアクセス権限であることを識別できる状態で記憶し、
前記売り手端末から、前記登録グループに提供されている前記コミュニティサービスへの参加要求を受け取った場合には、前記アクセス権限を所持し、かつ、有効期限内である場合にのみ参加を許可する
ことを特徴とする請求項１３から１６のいずれかに記載のコミュニティサービス提供方法。
【請求項１８】
前記売り手端末から、セールス活動の対象とする前記登録グループに所属する前記登録利用者宛てに、広告を配信する要求を受け取った場合に、
前記アクセス権限に基づいて配信の可否を判定し、
前記登録グループに所属する前記登録利用者の内、少なくとも一人宛てに広告を送信する
ことを特徴とする請求項１３から１７のいずれかに記載のコミュニティサービス提供方法。
【請求項１９】
前記登録利用者が使用する利用者端末から、前記登録売り手に対する注文を受け取り、これを記憶する際に、
どの登録グループに提供されているコミュニティサービスを使用して取引が成立したのか、という情報である取引グループ情報を含む注文情報を記憶する
ことを特徴とする請求項１３から１８のいずれかに記載のコミュニティサービス提供方法。
【請求項２０】
前記注文情報毎に、取引額に応じて、ポイントを計算し、
前記注文情報に含まれる前記取引グループ情報を基に、前記グループ毎に、一定期間分の前記ポイントを集計し、これを割引率計算対象グループポイントとし、
同一の前記登録グループに所属する前記登録利用者同士の通話または通信の料金を計算する際に、前記割引率計算対象グループポイントを基に割引率を算出する
ことを特徴とする請求項１９に記載のコミュニティサービス提供方法。
【請求項２１】
前記登録売り手が、前記商品を前記登録利用者に受け渡す際に、前記売り手端末から商品受渡日を受け取り、これを記憶し、
前記利用者端末からユーザ登録情報を受け取り、これを記憶し、
ユーザ管理者が前記商品を購入したユーザを管理するために予め登録した前記登録グループに、前記登録利用者を構成員として登録し、これを記憶する
ことを特徴とする請求項１３から２０のいずれかに記載のコミュニティサービス提供方法。
【請求項２２】
前記利用者情報と前記グループ情報を基に、前記登録利用者が所属しているグループに所属している利用者の連絡先情報リストを作成し、
前記利用者端末に送信する
ことを特徴とする請求項１３から２０のいずれかに記載のコミュニティサービス提供方法。
【請求項２３】
前記登録売り手及び前記登録利用者の少なくとも一方から受け取る収益を一定期間毎に集計し、
集計結果を基に、コミュニティサービスの運営に再投資する金額を算出する
ことを特徴とする請求項１３から２０のいずれかに記載のコミュニティサービス提供方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コミュニティシステム、コミュニティサーバ、並びにコミュニティサービス提供方法に関し、より詳細には、インターネット等の通信ネットワーク上において、潜在的買い手である利用者に対してコミュニティサービスを提供し、売り手に対して、該コミュニティサービス上でのセールス活動を可能にするサービスを提供する、セールス活動を支援する機能を有するコミュニティシステム、コミュニティサーバ、並びにコミュニティサービス提供方法に関する。
【背景技術】
【０００２】
近年、インターネット上で、電子会議室（電子掲示板）サービス、チャットサービス、メーリングリストサービス等による通信ネットワーク上のコミュニティサービスが多数提供されている。そして、これらのサービスを利用して、特定の仲間内のみに参加者を限定しているコミュニティ（グループ）や、共通の趣味や関心事や嗜好を有する不特定多数の参加者を対象としているコミュニティ（グループ）が通信ネットワーク上に多数構築されている。
【０００３】
特定の仲間内のみに参加者を限定しているコミュニティ（グループ）では、売り手による自由な宣伝行為（セールス活動）は、現時点では不可能であるが、このような場でのセールス活動の効率の良さは以前より認識されている。
【０００４】
なぜなら、該特定の仲間内のみに参加者を限定しているコミュニティ（グループ）とは、たとえば大学のサークル、学校の仲間、同窓会といったグループに相当し、サークルの飲み会、同窓会の行事、学校の仲間達で行く旅行といったグループの消費活動をセールス活動の対象とすることができることや、コミュニティの参加者同士が互いに誘い合うことで、より多くの買い手が購入に至ること等が想定され、取引額が大きくなることが期待できるからである。
【０００５】
また、不特定多数の参加者を対象としているコミュニティ（グループ）では、一参加者として参加した売り手により、そのテーマにあった商品やサービスの宣伝行為（セールス活動）等が行われることがあるが、コミュニケーションが妨げられる等の理由で、参加者が不快な思いをすることがあり、ルールを定めることにより、該行為を禁止しているような場合もある。
【０００６】
しかしながら、該不特定多数の参加者を対象としているコミュニティ（グループ）についても、前記特定の仲間内のみに参加者を限定しているコミュニティ（グループ）と同様に、セールス活動の効率の良さは以前より認識されている。なぜなら、共通の趣味や関心事や嗜好を有する参加者が集まっているからである。
【０００７】
以上のように、特定の仲間内のみに参加者を限定しているコミュニティ（グループ）ならびに不特定多数の参加者を対象としているコミュニティ（グループ）におけるセールス活動は効率が良く、売り手からのニーズが高いが、現時点では、セールス活動における利用は不可能、もしくは、肩身の狭い思いで行うことしかできなかった。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
通信ネットワーク上に構築されたコミュニティ（グループ）におけるセールス活動は、コミュニティ内で行われるコミュニケーションを妨げる等の理由で、参加者が不快な思いをすることがあるため、不可能もしくは困難であった。しかしながら、そのニーズは高く、実現が望まれている。
【０００９】
本発明は、このような課題に鑑みてなされたものであり、電子会議室（電子掲示板）やメーリングリスト等のコミュニティサービスを利用する通信ネットワーク上のコミュニティ（グループ）に対する売り手によるセールス活動を可能にすることを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するための手段として、本発明は以下の特徴を有する。  
本発明の第１の態様は、少なくとも一名の利用者（潜在的買い手）が所属するグループに通信ネットワーク上のコミュニティサービスを提供するコミュニティシステムとして提案される。
【００１１】
このシステムは、グループにコミュニティサービスを提供するコミュニティサーバと、利用者が使用する端末であって、前記コミュニティサーバに通信ネットワークを介して接続可能な利用者端末と、売り手が使用する端末であって、前記コミュニティサーバに通信ネットワークを介して接続可能な売り手端末と、を備えている。
【００１２】
このシステムにおいて、前記コミュニティサーバは、利用者が使用する利用者端末から、前記利用者に関する情報である利用者情報と、前記利用者の所属するグループを特定する所属情報を含む、前記グループに関するグループ情報と、を受け取り、これを記憶し、前記利用者情報及び前記グループ情報の少なくとも一方の情報に基づいて、前記グループ情報の登録を済ませたグループである登録グループに所属する、前記利用者情報の登録を済ませた利用者である登録利用者の使用する利用者端末による、前記登録グループに提供されているコミュニティサービスへのアクセスを許可し、売り手が使用する売り手端末から、前記売り手に関する情報である売り手情報を受け取り、これを記憶し、前記売り手情報の登録を済ませた売り手である登録売り手が使用する売り手端末から、前記登録グループに対するセールス活動を行うことを希望する通知を受け取ると、前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成し、これを売り手のアクセス権限であることを識別できる状態で記憶し、あるいは、前記登録グループに所属する前記登録利用者が使用する利用者端末から、前記登録売り手に商品またはサービスの提案依頼を希望する通知を受け取ると、前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成し、これを売り手のアクセス権限であることを識別できる状態で記憶し、前記売り手端末から、前記登録グループに提供されている前記コミュニティサービスへの参加要求を受け取った場合には、前記アクセス権限に基づいて参加の可否を判定し、前記コミュニティサービス上において、前記売り手に商品またはサービスの提案と交渉を行わせ、前記提案または前記交渉の結果、取引が成立し、前記登録利用者が使用する利用者端末から、前記登録売り手に対する注文情報を受け取り、これを記憶する際に、どの登録グループに提供されているコミュニティサービスを使用して取引が成立したのか、という情報である取引グループ情報を含む注文情報を記憶することを特徴としている。
【００１３】
本発明に係るコミュニティシステムによれば、電子会議室（電子掲示板）やメーリングリスト等のコミュニティサービスを利用して構築された通信ネットワーク上のコミュニティ（グループ）に対する売り手によるセールス活動を可能にする。
【００１４】
ここで、「コミュニティサービス」とは、コミュニティ（グループ）に所属する利用者同士のコミュニケーションを支援するツールを使用したサービスであり、該ツールとは、コンピュータ上で使用可能なすべてのプログラム又はソフトウエアであって、具体的には、電子会議室、電子掲示板、チャットルーム、メーリングリストなどを指している。
また、以下に説明する実施の形態では、「コミュニティサービス」に加えて、各種登録サービスや割引サービス等も含む、グループと該グループに所属する利用者たちに提供されるサービス全般を総称して、「グループサービス」としている。
また、「利用者」とは、コミュニティサービスの利用者であり、潜在的な買い手である。請求の範囲では、利用者は、登録を済ませると登録利用者となり、コミュニティサーバが提供するコミュニティサービスを利用できるようになる。一方、実施の形態においては、利用者は、登録後に初めて正式な「利用者（買い手）１２」になるとしている。  
また、「売り手」とは、コミュニティサービスを利用しているグループに対してセールス活動を行う者である。請求の範囲では、売り手は、登録を済ませると登録売り手となる。一方、実施の形態においては、売り手は、登録後に初めて正式な「会員（売り手）１３」になるとしている。  
また、「利用者情報」とは、利用者に関する基本的な情報を指しており、実施の形態においては、利用者情報ＴＢＬ４１１に相当する。  
また、「前記利用者の前記グループへの所属情報」とは、どの利用者がどのグループに所属しているのかという情報である。実施の形態においては、メンバ情報ＴＢＬ４１３に相当する。  
また、「グループ情報」とは、グループに関する基本的な情報を指しており、実施の形態においては、グループ基本情報ＴＢＬ４１２１の内、マーケティング情報に相当する「興味のある分野に関する情報」等を除いた情報に加えて、「前記利用者の前記グループへの所属情報」に相当するメンバ情報ＴＢＬ４１３を含んでいる。  
また、「売り手のアクセス権限であることが識別できる状態で記憶」させるのは、売り手に対して付与されるアクセス権限が、利用者の持つアクセス権限と比較して、参加できるコミュニティサービスの範囲や有効期限等の点で異なっているために、売り手のアクセス権限であることを識別できるようにしておく必要があるためである。  
なお、以上は、本発明の他の態様においても同様である。
【００１５】
本発明の第２の態様は、少なくとも一名の利用者（潜在的買い手）が所属するグループに通信ネットワーク上のコミュニティサービスを提供するコミュニティサーバとして提案される。
【００１６】
このコミュニティサーバは、利用者が使用する利用者端末から、前記利用者に関する情報である利用者情報と、前記利用者の所属するグループを特定する所属情報を含む、前記グループに関するグループ情報と、を受け取り、これを記憶し、前記利用者情報及び前記グループ情報の少なくとも一方の情報に基づいて、前記グループ情報の登録を済ませたグループである登録グループに所属する、前記利用者情報の登録を済ませた利用者である登録利用者の使用する利用者端末による、前記登録グループに提供されているコミュニティサービスへのアクセスを許可し、売り手が使用する売り手端末から、前記売り手に関する情報である売り手情報を受け取り、これを記憶し、前記売り手情報の登録を済ませた売り手である登録売り手が使用する売り手端末から、前記登録グループに対するセールス活動を行うことを希望する通知を受け取ると、前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成し、これを売り手のアクセス権限であることを識別できる状態で記憶し、前記売り手端末から、前記登録グループに提供されている前記コミュニティサービスへの参加要求を受け取った場合には、前記アクセス権限に基づいて参加の可否を判定することを特徴としている。
【００１７】
上記コミュニティサーバによれば、売り手から利用者にアプローチする方法によるセールス活動（いわゆるアウトバウンド型営業）について、電子会議室（電子掲示板）やメーリングリスト等のコミュニティサービスを利用する通信ネットワーク上のコミュニティ（グループ）に対する売り手によるセールス活動を可能にする。
【００１８】
また、上記コミュニティサーバは、前記登録売り手がセールス活動の対象とする前記登録グループを選定する方法として、前記利用者端末から、前記利用者及び前記グループの少なくとも一方に関するマーケティング情報を受け取り、これを記憶し、前記売り手端末から、前記マーケティング情報の閲覧要求を受け取った場合に、要求に合致する前記マーケティング情報を前記売り手端末に返信し、前記売り手端末から、返信した前記マーケティング情報に基づいて決定されたグループの選定情報を受け取ることを特徴として有していても良い。
【００１９】
上記コミュニティサーバによれば、売り手から利用者にアプローチする方法によるセールス活動（いわゆるアウトバウンド型営業）を行う際に、セールス活動の対象となるグループの情報を取得して、選定することを容易にする。
【００２０】
ここで、「マーケティング情報」とは、グループに所属する利用者たちの共通の興味や関心事に関する情報である。実施の形態では、グループ基本情報ＴＢＬ４１２１の内、マーケティング情報に相当する「興味のある分野に関する情報」等と、記念日情報ＴＢＬ４１２２と、提案依頼ＴＢＬ４１２３に相当する。
【００２１】
また、上記コミュニティサーバは、前記登録売り手の使用する売り手端末による、前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成する際に、前記登録売り手に対して、交渉権料を課金することを特徴として有していても良い。
【００２２】
上記コミュニティサーバによれば、グループに提供されているコミュニティサービスへのアクセス権限を、売り手に販売することが可能となる。
【００２３】
本発明の第３の態様は、第２の態様と同様に、少なくとも一名の利用者（潜在的買い手）が所属するグループに通信ネットワーク上のコミュニティサービスを提供するコミュニティサーバとして提案される。
【００２４】
このコミュニティサーバは、利用者が使用する利用者端末から、前記利用者に関する情報である利用者情報と、前記利用者の所属するグループを特定する所属情報を含む、前記グループに関するグループ情報と、を受け取り、これを記憶し、前記利用者情報及び前記グループ情報の少なくとも一方の情報に基づいて、前記グループ情報の登録を済ませたグループである登録グループに所属する、前記利用者情報の登録を済ませた利用者である登録利用者の使用する利用者端末による、前記登録グループに提供されているコミュニティサービスへのアクセスを許可し、売り手が使用する売り手端末から、前記売り手に関する情報である売り手情報を受け取り、これを記憶し、前記登録グループに所属する前記登録利用者が使用する利用者端末から、前記登録売り手に商品またはサービスの提案依頼を希望する通知を受け取ると、前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成し、これを売り手のアクセス権限であることを識別できる状態で記憶し、前記売り手端末から、前記登録グループに提供されている前記コミュニティサービスへの参加要求を受け取った場合には、前記アクセス権限に基づいて参加の可否を判定することを特徴としている。
【００２５】
上記コミュニティサーバによれば、利用者から売り手にアプローチする方法によるセールス活動（いわゆるインバウンド型営業）について、電子会議室（電子掲示板）やメーリングリスト等のコミュニティサービスを利用する通信ネットワーク上のコミュニティ（グループ）に対する売り手によるセールス活動を可能にする。
【００２６】
また、上記コミュニティサーバは、  前記登録売り手の使用する売り手端末による前記登録グループに提供されている前記コミュニティサービスへのアクセス権限を生成する際に、これを、有効期限情報と伴に、売り手のアクセス権限であることを識別できる状態で記憶し、前記売り手端末から、前記登録グループに提供されている前記コミュニティサービスへの参加要求を受け取った場合には、前記アクセス権限を所持し、かつ、有効期限内である場合にのみ参加を許可することを特徴として有していても良い。
【００２７】
上記コミュニティサーバによれば、売り手に付与されるアクセス権限が、利用者のアクセス権限とは異なり、有効期限の制約があるアクセス権限とすることができる。
【００２８】
また、上記コミュニティサーバは、前記登録売り手が、前記登録グループに対して、商品またはサービスの提案を行う方法として、前記売り手端末から、セールス活動の対象とする前記登録グループに所属する前記登録利用者宛てに、広告を配信する要求を受け取った場合に、前記アクセス権限に基づいて配信の可否を判定し、前記登録グループに所属する前記登録利用者の内、少なくとも一人宛てに広告を送信することを特徴として有していても良い。
【００２９】
上記コミュニティサーバによれば、売り手は、セールス活動としての交渉をグループに所属する利用者たちに対して行う前に、「挨拶」的な位置付けとしての広告による情報提供を行うことが可能となるため、交渉へのスムーズな移行を可能にする。
【００３０】
また、上記コミュニティサーバは、前記登録利用者が使用する利用者端末から、前記登録売り手に対する注文を受け取り、これを記憶する際に、どの登録グループに提供されているコミュニティサービスを使用して取引が成立したのか、という情報である取引グループ情報を含む注文情報を記憶することを特徴として有していても良い。
【００３１】
上記コミュニティサーバによれば、注文情報に「どのグループのコミュニティサービスを使用して取引が成立したのかという情報」を持つことによって、取引額や取引件数等をグループ毎に集計することが可能となる。
【００３２】
また、上記コミュニティサーバは、同一の前記登録グループに所属する前記登録利用者同士の通話または通信において、通話料金または通信料金を割引く方法として、前記注文情報毎に、取引額に応じて、ポイントを計算し、前記注文情報に含まれる前記取引グループ情報を基に、前記グループ毎に、一定期間分の前記ポイントを集計し、これを割引率計算対象グループポイントとし、同一の前記登録グループに所属する前記登録利用者同士の通話または通信の料金を計算する際に、前記割引率計算対象グループポイントを基に割引率を算出することを特徴として有していても良い。
【００３３】
上記コミュニティサーバによれば、利用者は、ポイントを取得できる活動（購買活動等）を活発に行えば行うほど、同一グループに所属する利用者同士の通話・通信費用を低減させることができるため、購買活動等のポイント取得活動に対するインセンティブを得ることができる。
【００３４】
また、上記コミュニティサーバは、商品を購入した前記登録利用者が該商品のユーザ管理者にユーザ登録する方法として、前記登録売り手が、前記商品を前記登録利用者に受け渡す際に、前記売り手端末から商品受渡日を受け取り、これを記憶し、前記利用者端末からユーザ登録情報を受け取り、これを記憶し、ユーザ管理者が前記商品を購入したユーザを管理するために予め登録した前記登録グループに、前記登録利用者を構成員として登録し、これを記憶することを特徴として有していても良い。
【００３５】
上記コミュニティサーバによれば、商品受渡日を基準に商品修理保証期限を算出することが可能となり、利用者が商品やサービスのアフターサービスを確実に受けることを可能にする。また、ユーザ管理者によるユーザ管理の省力化を可能にする。
【００３６】
また、上記コミュニティサーバは、前記登録利用者が、交友関係のある利用者の連絡先情報を取得する方法として、前記利用者情報と前記グループ情報を基に、前記登録利用者が所属しているグループに所属している利用者の連絡先情報リストを作成し、前記利用者端末に送信することを特徴として有していても良い。
【００３７】
上記コミュニティサーバによれば、利用者は、交友関係のある利用者たちの連絡先（住所、電話番号）を常にアップデートされた状態で取得することが可能となり、交友関係のある利用者たち同士の連絡をより確実なものにすることが可能となる。ここで、交友関係のある利用者とは、同一のグループに所属している利用者たちのことを意味している。
【００３８】
また、上記コミュニティサーバは、前記登録売り手及び前記登録利用者の少なくとも一方から受け取る収益を一定期間毎に集計し、集計結果を基に、コミュニティサービスの運営に再投資する金額を算出することを特徴として有していても良い。
【００３９】
上記コミュニティサーバによれば、売り手や利用者から受け取る収益の一部を、利用者に提供するサービスの拡充に使用することが可能となる。
【発明の効果】
【００４０】
本発明によれば、電子会議室（電子掲示板）やメーリングリスト等のコミュニティサービスを利用する通信ネットワーク上のコミュニティ（グループ）に対する売り手によるセールス活動を可能にする。
【００４１】
また、本発明によれば、買い手としてのコミュニティ（グループ）の構成員である利用者にとっても、集団で交渉することで有利な条件を引き出すことができる等のメリットがある。更に、本発明にかかるシステムの主催者、コミュニティサーバの所有者、運用者、管理者、並びにコミュニティサービス提供方法の実行者などにとっては、交渉権料やマーケティング情報利用料や取引仲介手数料等の収益を得ることができるメリットがある。収益の一部をコミュニティサービス等の拡充に使用すれば、コミュニティ（グループ）の構成員である利用者にとってのメリットが更に増す。
【発明を実施するための最良の形態】
【００４２】
以下、図面を参照しながら、本発明の実施形態について詳細に説明する。
【００４３】
［１．本実施の形態により実現されるビジネスモデル］
まず、本実施の形態にかかるコミュニティシステムにより実現されるビジネスモデルについて説明する。図１は、本発明に係るコミュニティシステム（以下「本発明システム」とする）を利用することで実現されるビジネスモデルの概要を示す図で、各主体間でやり取りされる情報とサービスと商品と金銭等の流れを表している。
【００４４】
［１．１．主体について］
該ビジネスモデルに登場する主体（自然人、法人、団体等のいずれであってもよい）は、主催者１１、利用者（買い手）１２、会員（売り手）１３の三者である。
【００４５】
主催者１１は、該ビジネスモデルもしくは本発明システムを運営管理する主催者である。
【００４６】
利用者（買い手）１２（以下「利用者１２」とする）は、主催者１１が提供する通信ネットワーク上のコミュニティサービスの利用者であり、該ビジネスモデルに買い手として参加する主体である。利用者１２は、グループ１Ａに所属することで、該ビジネスモデルに参加（すなわち、本発明システムを利用）することが可能となる。ここで、グループ１Ａとは、少なくとも１人以上の利用者１２で構成される集団であり、前記「コミュニティ（グループ）」は、該ビジネスモデル上では、グループ１Ａとして管理される。また、利用者１２は複数のグループ１Ａに参加することが可能であり、グループ１Ａに参加した場合、利用者１２はグループ１Ａの「メンバ」となる。
【００４７】
会員（売り手）１３（以下「会員１３」とする）は、該ビジネスモデルに商品やサービスの売り手として参加する主体であり、具体的には、商品やサービスの販売会社などに相当する。ただし、本コミュニティシステム、コミュニティサービス提供方法において必ずしも会員制を採用しなければならないわけではない。
【００４８】
［１．２．主体間の取引について］
［１．２．１．主催者１１＜＝＞利用者１２（グループ１Ａ）］
［１．２．１．１．グループ情報１４ａ（利用者１２（グループ１Ａ）＝＞主催者１１）］
利用者１２は、自身に関する情報と、自らが所属するグループ１Ａに関する情報（以下「グループ情報」とする）を主催者１１に提供する（１４ａ）。ここで、該グループ情報とは、グループ名称や所属メンバ情報（どの利用者１２が所属しているのかという所属情報）の他に、グループ１Ａのメンバが共通して持つ趣味や関心事や嗜好、サービスや商品のニーズ、結成日、活動内容といったマーケティング情報を含む。このマーケティング情報は、後述するように、主催者１１を介して、会員１３に提供されるようになる（１６ａ）。ここで、マーケティング情報の収集は必須ではないが、収集しておくことが望ましい。
【００４９】
［１．２．１．２．交渉権１４ｂ（利用者１２（グループ１Ａ）＝＞主催者１１）］  
また、利用者１２は、会員１３と会員１３の提供する商品等について交渉したいと考えた場合、交渉希望の意思を主催者に伝えることができる（１４ｂ）。これは、後述するように、主催者１１を介して、交渉権として、会員１３に付与される（１６ｂ）。
【００５０】
［１．２．１．３．グループサービス１５ａ（主催者１１＝＞利用者１２（グループ１Ａ））］
逆に、主催者１１は、利用者１２に対して、グループ活動を支援するサービス（以下「グループサービス」とする）等を提供する。ここで、グループサービスとは、具体的には、電子会議室（電子掲示板）サービス、チャットサービス、メーリングリストサービス、バーチャルコミュニティサービス、グループスケジュール管理表サービス、同一グループに所属する利用者同士で行うオンラインゲーム等のコミュニティサービスや、会員１３の所有する会員ホームページ閲覧サービス、各種登録関係サービス、グループサービスを利用して行われる通話・通信などの様々なサービスが考えられる。ここで、グループサービスを利用して行われる通話・通信とは、同一グループに所属する利用者同士の通話・通信を意味しており、通常の通話・通信とは別の料金体系（料金を割引く、定額にする、免除する等）を設定することで提供される。また、グループサービス以外にも、利用者１２個人に対して様々な情報サービス等を提供することもできる。
【００５１】
説明を補足すると、「コミュニティサービス」とは、コミュニティ（グループ）に所属する利用者同士のコミュニケーションを支援するツールを使用したサービスであり、該ツールとは、コンピュータ上で使用可能なすべてのプログラム又はソフトウエアであって、具体的には、電子会議室、電子掲示板、チャットルーム、メーリングリストなどを指している。
また、本実施の形態では、「コミュニティサービス」に加えて、各種登録サービスや割引サービス等も含む、グループと該グループに所属する利用者たちに提供されるサービス全般を総称して、「グループサービス」としている。
【００５２】
［１．２．２．主催者１１＜＝＞会員１３］
［１．２．２．１．マーケティング情報１６ａ（主催者１１＝＞会員１２）］
主催者１１は、会員１３に対して、マーケティング情報を提供する（１６ａ）。該マーケティング情報の１つは、前記グループ情報に含まれる情報である。
【００５３】
その他のマーケティング情報としては、利用者１２と会員１３の間で取引が成立した場合（１９）の取引実績情報を、具体的な取引がわからないように処理したデータが考えられる。該データは、グループ１Ａの活動状態を計る一つの目安としての利用価値が期待できる。処理方法としては、例えば、過去1年間の取引累計額から、月あたりの取引平均額を算出し、額の大きい順にランクＡ〜Ｅとする等の様々な方法が考えられる。  
また、グループサービスの利用頻度を通信データ量や通話時間などを基に算出し、同様にランク付けする等してマーケティング情報として提供することも同様の利用価値が期待できる。  
更にグループ１Ａに対してホームページ（以下「ＨＰ」とする）やブログのレンタルサーバサービスを提供（無料も可）し、ＨＰやブログを作成してもらい、グループ１Ａが許可する場合のみ、その情報を公開することもマーケティング情報として有益と考えられる。
【００５４】
また、主催者１１は、マーケティング情報の提供する見返りとして、会員１３からマーケティング情報の利用料を徴収することができる（１７ａ）。
【００５５】
マーケティング情報の提供方法は、通信ネットワークを介して行われても良いし、或いは印刷物の郵送など通信ネットワークを介さない方法でも良い。通信ネットワークを介して行われる方法としては、例えば、会員１３の所有する端末から検索条件を入力し、コミュニティサーバ（もしくは、データベースサーバ）で検索条件に合致するマーケティング情報を抽出し、抽出したマーケティング情報を会員１３の所有する端末に返信するといったマーケティングデータベース検索サービスのような方法が考えられる。また、これ以外にも、予め条件を登録しておき、利用者１２により、グループ情報が登録／更新される都度、条件に合致する情報を会員１３に配信する方法や、グループ１ＡのＨＰやブログを公開する方法等も考えられる。
【００５６】
［１．２．２．２．交渉権１６ｂ（主催者１１＝＞会員１３）］
会員１３は、次の２つの方法で、主催者１１から利用者１２（グループ１Ａ）と交渉する権利（以下「交渉権」とする）を取得することができる（１６ｂ）。
【００５７】
１つ目の方法は会員１３が、主催者１１から提供されたマーケティング情報や利用者１２のＨＰやブログ等を基に、セールス活動を行いたいグループ１Ａを選定し、交渉権を購入する方法である。このとき、主催者１１は、会員１３から交渉権料を徴収することができる（１７ａ）。
２つ目の方法は、利用者１２が、会員１３のＨＰやカタログやテレビＣＭ等を閲覧する等して、交渉をしたいと考えた場合に、利用者１２が主催者１１を介して会員１３に交渉権を付与する方法である（１４ｂ＝＞１６ｂ）。
【００５８】
［１．２．２．３．各種利用料１７ａ（会員１３＝＞主催者１１）］
逆に、主催者１１は、会員１３から次のような各種料金を徴収することができる。
１）会員登録料
２）マーケティング情報の利用料
３）会員１３に交渉権を販売した場合の交渉権料
４）利用者１２と会員１３の間で取引が成立した場合（１９ａ）の取引仲介手数料
ここで、会員登録料は、利用者１２の使用する端末の通信料が従量課金制の場合（例えば携帯電話等）、利用者１２が会員１３のホームページを閲覧する場合に限り、その料金を割引く、または免除（無料）するといった料金体系と組み合わせることで、会員１３が会員登録料を支払うメリットをより明確にすることができる。
【００５９】
［１．２．３．利用者１２（グループ１Ａ）＜＝＞会員１３］
会員１３は、交渉権を取得することで、グループ１Ａに所属する利用者１２に対して電子会議室（電子掲示板）やメーリングリスト等のコミュニティサービスを通してセールス活動を行うことができるようになる（１８ａ）。
【００６０】
さらに該セールス活動１８ａの結果、取引が成立すれば、会員１３から利用者１２に対して商品が受け渡され、逆に利用者１２から会員１３に対して対価（金銭等）が支払われる（１９ａ）。このときに、主催者１１が利用者１２やグループ１Ａに対して、取引額に応じてポイント等を付与しておくと利用者１２に対するグループサービスや利用料の水準（割引率など）を決定する際の算出基準に活用することができる。
【００６１】
また、主催者１１は、取引成立時に、会員１３もしくは利用者１２から取引仲介手数料を徴収することができる（１７ａ）。
【００６２】
［１．３．ビジネスの循環］
次に、前記ビジネスモデルがどのように循環し発展していくのかについて説明する。図２は、前記ビジネスモデルの各サービスが循環してビジネスが発展していくことを示す図である。
【００６３】
まず、会員１３から徴収される各種料金の一部をグループサービス等の原資とすることにより、利用者１２（グループ１Ａ）に対するサービスの水準を向上させることができる（２１）。
さらに、利用者１２（グループ１Ａ）に対するサービスの水準が向上することで、利用者１２とグループ１Ａの増加（２２）が期待され、グループ情報（マーケティング情報等）の充実度を高める（２３）ことができる。
【００６４】
さらに、グループ情報（マーケティング情報等）が充実（２３）することで、マーケティング情報データベースの利用者である会員１３の増加（２４）が期待され、会員１３から徴収される会員登録料・マーケティング情報利用料（ＤＢ利用料）・交渉権料等が増加する（２５）。  
利用者１２／グループ１Ａの増加（２２）と会員１３の増加（２４）は、取引の増加（２６）につながり、取引仲介手数料の増加（２７）が期待できる。  
これらの収益の一部を、さらに利用者１２／グループ１Ａに対するサービス向上（２１）の原資とすることで、ビジネスが発展する好循環を生み出すことができる。
【００６５】
上記に加えて、利用者１２／グループ１Ａに対するサービス向上（２１）の一環として、サービスの提供方法の工夫が考えられる。具体例としては、取引額に応じてポイントを付与する方法を用いて、蓄積されたポイントに応じてグループサービスや利用料割引サービスに差を付けるなどして、利用者１２（グループ１Ａ）に対して購買に対するインセンティブを提供する方法が考えられる。これにより、取引を増加させる効果が期待できる。
【００６６】
［２．本発明システムの範囲］  
さて、本発明システムは、前記ビジネスモデルを実現するために、以下の仕組みを有する。
【００６７】
（１）  会員１３から利用者１２にアプローチする方法によるセールス活動（以下「アウトバウンド型営業」とする）を支援する仕組み（以下「仕組みＡ」とする）
（２）  利用者１２から会員１３にアプローチする方法によるセールス活動（以下「インバウンド型営業」とする）を支援する仕組み（以下「仕組みＢ」とする）
【００６８】
また、本発明システムは、前記２つの仕組みに加えて、サービス内容を拡充するために、以下の仕組みを実現するようにしても良い。  
（３）  グループサービスを利用して行われる通話・通信（同一グループに所属する利用者同士の通話・通信）において、割引率計算対象ポイントに応じて、料金を割り引く仕組み（以下「仕組みＣ」とする）
（４）  商品のユーザ管理者や会員１３等がユーザ（顧客）管理（ユーザサポート）を行う仕組み（以下「仕組みＤ」とする）  
（５）  同一グループに所属する利用者同士の交友関係の維持が容易となるように、交友関係のある利用者１２の連絡先情報リスト（住所録）を作成する仕組み（以下「仕組みＥ」とする）  
（６）  本発明システムによって実現されるビジネスモデルを好循環させるために、会員１３または利用者１２から受け取る収益の一部を、コミュニティサービスの運営に再投資するための再投資額を算出する仕組み（以下「仕組みＦ」とする）  
【００６９】
［３．仕組みＡおよび仕組みＢを実現する本発明システムの実施の形態］
前記仕組みＡおよび仕組みＢについて、図３Ａ／図３Ｂを参照しながら説明する。図３Ａ／図３Ｂは、それぞれ、前記アウトバウンド型営業を支援する仕組みである仕組みＡと前記インバウンド型営業を支援する仕組みである仕組みＢについて、利用者１２と会員１３がシステムに参加してから取引成立に至るまでの過程（状態遷移）を表している。なお、図３Ａ／図３Ｂはどちらも、大きく分けて、左側が利用者１２が本発明システムに参加してから取引成立に至るまでの流れを、右側が会員１３が本発明システムに参加してから取引成立に至るまでの流れを表している。
【００７０】
［３．１．仕組みＡおよび仕組みＢの概要］
［３．１．１．仕組みＡについて］
先に、仕組みＡについて図３Ａを参照しながら説明する。  
利用者１２は、まず、本発明システムに利用者登録を行う（ステップ（以下「Ｓ」と略す）Ｓ３１ａ）。  
次に、同様に利用者登録を済ませた利用者１２の中から仲間を募り（正確には、仲間を募るのは、グループ１Ａを登録した後でも良い）、グループ１Ａを結成し、本発明システムにグループ１Ａの登録と、グループ１Ａに所属するメンバ（利用者１２）の登録とを行う（Ｓ３１ａ）。
【００７１】
このとき、必須ではないが、グループ名称や所属メンバの情報の他に、グループのメンバが共通して持つ趣味や関心事や嗜好、商品やサービスのニーズ、結成日、活動内容といったマーケティング情報を登録しておくことが望ましい。また、これらの情報の内容は後から変更や追加や削除が可能である。
【００７２】
なお、必須処理ではないが、利用者登録の際に、該利用者１名のみが所属する、他の利用者が所属できないグループ１Ａを自動登録（同時にメンバ登録）するようにすることで、どのグループ１Ａにも属さない利用者を無くすことができ、また、利用者個人をセールス対象とすることができる。
【００７３】
登録を終えると、利用者１２はグループサービスＳ３２ａを利用することができるようになる。
【００７４】
これと同時並行的に、会員１３は、会員登録を行う（Ｓ３３ａ）。会員１３は会員登録を済ませると、グループ情報を取得するためのサービスＳ３４ａを利用できるようになる。仕組みＡ（図３Ａ）では、ＤＢ検索（マーケティングデータベース検索サービス）としているが、このサービスＳ３４ａの目的は、会員１３が欲するグループ情報を会員１３に取得させることにあるため、方法はこれに限定されない。例えば、予め条件を登録しておき、グループ情報が登録または変更される都度、条件に合致する情報を会員１３に配信する方法や、グループ１ＡのＨＰやブログを閲覧してグループ情報を取得し、セールス活動を行いたいと考えたときに交渉権を購入する方法、等でも良い。なお、主催者１１がマーケティングデータベース検索サービスを提供する場合は、Ｓ３１ａにおいて、利用者１２により、グループのメンバが共通して持つ趣味や関心事や嗜好、商品やサービスのニーズ、結成日、活動内容といったマーケティング情報を登録しておく必要がある。
【００７５】
次に、会員１３は、Ｓ３４ａにおいて取得したグループ情報を基に、セールス活動を行いたいグループ１Ａを選定し交渉権を購入する（Ｓ３５ａ）。このとき、利用者１２（グループ１Ａ）は、会員１３からセールスのアプローチがあることをメールや参照画面等により知る（Ｓ３６ａ）。
【００７６】
次に、Ｓ３５ａにおいて交渉権を購入した会員１３は、グループ１Ａに所属する利用者１２に対して、電子会議室等のグループサービスを使用して交渉（セールス活動）を行う（Ｓ３７ａ）。また、会員１３からのセールスのアプローチがあることを知った利用者１２（グループ１Ａ）は、電子会議室等のコミュニティサービスを使用して会員１３と交渉を行う（Ｓ３７ａ）。
【００７７】
交渉が成立すると、会員１３は、利用者１２から商品を受注し、取引が成立する（Ｓ３８ａ）。
【００７８】
［３．１．２．仕組みＢについて］
次に、仕組みＢについて図３Ｂを参照しながら説明する。  
利用者１２は、まず、本発明システムに利用者登録を行う（Ｓ３１ｂ）。  
次に仕組みＡ（図３Ａ）と同様に、利用者登録を済ませた利用者の中から仲間を募り（正確には、仲間を募るのは、グループ１Ａを登録した後でも良い）、グループ１Ａを結成し、本発明システムにグループ１Ａの登録とグループ１Ａに所属するメンバ（利用者１２）の登録を行う（Ｓ３１ｂ）。
【００７９】
このとき、仕組みＡ（図３Ａ）の場合とは異なり、グループのメンバが共通して持つ趣味や関心事や嗜好、サービスや商品のニーズ、結成日、活動内容といったマーケティング情報を登録する必要は必ずしもない。
【００８０】
また、仕組みＡ（図３Ａ）と同様、必須処理ではないが、利用者登録の際に、該利用者１名のみが所属する、他の利用者が所属できないグループ１Ａを自動登録（同時にメンバ登録）するようにすることで、どのグループ１Ａにも属さない利用者を無くすことができ、また、利用者個人をセールス対象とすることができる。
【００８１】
登録を終えると、利用者１２はグループサービスＳ３２ｂを利用することができるようになる。
【００８２】
これと同時並行的に、会員１３は、会員登録を行う（Ｓ３３ｂ）。  
会員１３は会員登録を済ませると、ＨＰ（ホームページ）等を通して商品情報が利用者１２に公開されるようになる（Ｓ３４ｂ）。仕組みＢ（図３Ｂ）では、商品情報を公開する方法として、ＨＰを採用しているが、方法はこれに限定されない。例えば、商品カタログや雑誌やテレビＣＭ等でも良い。ただし、利用者１２が、商品情報に加えて、会員ＩＤや会員ＨＰのＵＲＬ等、会員を特定できる情報を取得できなくてはならない。例えば、商品カタログや雑誌の場合には、ＱＲコードなどが利用可能である。
【００８３】
一方、利用者１２は、何らかの商品やサービスを得ようと考えたとき、情報収集を開始する。そして、公開されている会員１３のＨＰ等を閲覧し、目的の（興味のある）商品を探す（Ｓ３５ｂ）。
【００８４】
次に、目的の商品を見つけたら、利用者１２は、会員１３に対して提案を依頼するために交渉権を付与する（Ｓ３６ｂ）。このとき、同時に、会員１３は、利用者１２が提案を依頼して交渉権を付与してきたことをメールや参照画面等により知る（Ｓ３７ｂ）。
【００８５】
ここで、利用者１２は必ずしも会員１３に対して交渉権を付与して交渉する必要はなく、目的の商品を見つけたら、そのまま注文する場合もある。
【００８６】
次に、利用者１２（グループ１Ａ）からの提案依頼があったことを知った会員１３は、提案を依頼してきた利用者１２（グループ１Ａ）に対して、電子会議室等のコミュニティサービスを使用して交渉（セールス活動）を行う（Ｓ３８ｂ）。また、Ｓ３６ｂにおいて交渉権を付与した利用者１２（グループ１Ａ）は、同様に、電子会議室等のグループサービスを使用して会員１３と交渉を行う（Ｓ３８ｂ）。
【００８７】
交渉が成立すると、会員１３は利用者１２から受注し、取引が成立する（Ｓ３９ｂ）。
【００８８】
［３．２．本発明システムのハードウェア構成例］
次に、仕組みＡおよび仕組みＢについて、本実施の形態に係る本発明システムのハードウェア構成について説明する。ただし、ここでの説明は、仕組みＣおよび仕組みＤおよび仕組みＥおよび仕組みＦにも対応している。図４は、本実施の形態に係る本発明システムの概略構成を示すブロック図である。
【００８９】
同図に示すように、本発明システムは、コミュニティサービスを提供するためのさまざまなデータならびに処理プログラムに加えて、セールス活動を支援するためのさまざまなデータならびに処理プログラムが格納されているコミュニティサーバ４０と、利用者１２が使用する利用者端末５０と、会員１３が使用する会員端末６０と、を備えている。また、必要に応じて、会員（売り手）ＨＰサーバ８０や、ユーザ管理サーバ９０、を備えても良い。コミュニティサーバ４０と利用者端末５０と会員端末６０、および、会員（売り手）ＨＰサーバ８０とユーザ管理サーバ９０は、インターネット等に代表される通信ネットワーク７０を介して接続されており、それぞれの通信インタフェースを介して、互いにデータの送受信が可能である。
【００９０】
［３．２．１．コミュニティサーバ４０，会員（売り手）ＨＰサーバ８０，ユーザ管理サーバ９０］
コミュニティサーバ４０は、本発明システムの主催者が設置するサーバもしくは情報処理装置であり、各種演算を行う演算装置と、処理プログラム等を格納するデータ記憶部と、種々のデータを格納するデータベース（以下「ＤＢ」とする）と、を有している。筐体は必ずしも１つである必要はなく、複数のコンピュータを組み合わせ、処理を分散させたコミュニティサーバ群として実現しても良い。また、データベースならびに処理（動作）の詳細については後述する。
【００９１】
また、Ｗｅｂアプリケーションを動作させるために、Ｗｅｂアプリケーションサーバをインストールしても良い。Ｗｅｂアプリケーションサーバには、商用プロダクツ、オープンソースプロダクツ等があるが、例えば、オープンソースプロダクツであるＪａｋａｒｔａ  Ｐｒｏｊｅｃｔ（http://jakarta.apache.org）のＴｏｍｃａｔを使用することができる。該Ｗｅｂアプリケーションサーバには、Ｊａｖａ（登録商標）サーブレットやＪＳＰを実行するための環境が含まれており、開発言語にＪａｖａ言語を採用する場合に使用することができる。
【００９２】
また、必要に応じて設置される、会員（売り手）ＨＰサーバ８０とユーザ管理サーバ９０についても、コミュニティサーバ４０と同様の仕様とすることができる。
【００９３】
［３．２．２．利用者端末５０，会員端末６０］
利用者端末５０及び会員端末６０は、それぞれ、利用者１２毎、会員１３毎に端末が用意されており、図４に示すように、利用者端末５０−１、利用者端末５０−２、・・・と、会員端末６０−１、会員端末６０−２、・・・から構成される。もちろん、複数の利用者１２もしくは複数の会員１３で同一の端末を用いても良い。また、該利用者端末５０と該会員端末６０は、入力手段としてのキーボードやマウス、表示手段としてのディスプレイ等、そして編集機能と演算機能と通信機能を備えた情報処理装置であればどのようなものでも良い。具体的には、パソコンや携帯電話やＰＤＡ（Personal Digital Assistant）等が利用可能である。該利用者端末５０と該会員端末６０は通信ネットワーク７０を介してコミュニティサーバ４０にアクセスし、サーバ内のデータを受信することで、ディスプレイ上に必要な情報が表示される。
また、開発言語にＪａｖａ言語を採用する場合は、Ｊａｖａ仮想マシン（ＪａｖａＶＭ）をインストールしておく必要がある。
【００９４】
［３．２．３．通信ネットワーク７０］
通信ネットワーク７０は、有線／無線を問わず、接続されている装置が目的とする装置に対してデータの送受信を可能とするように作用する。具体的には、インターネット等であるが、ゲートウェイを介して複数の通信網が組み合わされて実現されていても良い。
【００９５】
［３．３．本発明システムのデータベース構成例］
次に、仕組みＡおよび仕組みＢについて、本実施の形態に係る本発明システムのデータベースの構成について説明する。ただし、ここでの説明は、仕組みＣおよび仕組みＤおよび仕組みＥおよび仕組みＦにも対応している。また、データベースは必ずしもコミュニティサーバ４０に格納される必要はなく、データベースサーバ等を別途設置して格納しても良い。
【００９６】
［３．３．１．本発明システムのデータベース構成の概要］
図５は、本実施の形態に係る本発明システムのデータベースの構成を概略的に示すブロック図である。同図に示すように、大きく５つのデータベース（以下「ＤＢ」とする）から構成されており、各ＤＢには次のようなテーブルが格納される。
【００９７】
利用者関係データベースＤＢ４１は、利用者１２に関する情報、および、利用者１２が所属するグループ１Ａに関する情報が格納される。具体的には、利用者情報テーブル（以下「ＴＢＬ」とする）４１１、グループ情報ＴＢＬ４１２、メンバ情報ＴＢＬ４１３、スレッド管理（利用者用）ＴＢＬ４１４、グループＨＰコンテンツＴＢＬ４１５が設置される。ここで、グループ情報ＴＢＬ４１２は、グループ１Ａに関する情報ＴＢＬ全般を指しており、実施の形態では、グループ１Ａの基本的な情報（グループ名、結成日、管理者、等）を管理するグループ基本情報ＴＢＬ４１２１と、マーケティング関連の情報である記念日情報ＴＢＬ４１２２および提案依頼情報ＴＢＬ４１２３と、を含んでいる。もちろん、マーケティング情報を充実させるために、マーケティング関連のＴＢＬが追加されても良い。また、説明の便宜上、利用者１２に関連するＴＢＬである利用者情報ＴＢＬ４１１とグループ情報ＴＢＬ４１２（ＴＢＬ４１２１、ＴＢＬ４１２２、ＴＢＬ４１２３）とメンバ情報ＴＢＬ４１３と、をまとめて利用者・グループ・メンバ情報ＴＢＬ４１０としている。
【００９８】
会員関係データベースＤＢ４２は、会員１３に関する情報が格納される。具体的には、会員情報ＴＢＬ４２１、会員アクセス権限管理ＴＢＬ４２２、スレッド管理（会員用）ＴＢＬ４２３、会員ＨＰコンテンツＴＢＬ４２４が設置される。
【００９９】
電子会議室関係データベースＤＢ４３は、電子会議室に関する情報が格納される。具体的には、スレッド管理ＴＢＬ４３１、電子会議室ＴＢＬ４３２が設置される。
【０１００】
取引関係データベースＤＢ４４は、取引に関係する情報が格納される。具体的には、注文ＴＢＬ４４１、取引実績ＴＢＬ４４２、商品ＴＢＬ４４３が設置される。
【０１０１】
その他データベースＤＢ４５は、上記４つのＤＢに分類されない情報が格納される。具体的には、通話／通信料金計算結果ＴＢＬ４５１、商品受渡日管理ＴＢＬ４５２、ユーザ登録画面ＴＢＬ４５３、収益ＴＢＬ４５４、再投資額ＴＢＬ４５５が設置される。
【０１０２】
次に、各ＴＢＬに格納される属性について説明する。
【０１０３】
［３．３．２．利用者関係データベースＤＢ４１］
［３．３．２．１．利用者情報ＴＢＬ４１１］
利用者情報ＴＢＬ４１１には、利用者１２に関する属性が格納される。
具体的には、「利用者ＩＤ」、認証用の「パスワード」、「氏名」、「郵便番号」、「住所」、「電話番号」、「メールアドレス」、「生年月日」、「利用者ポイント残高」、「割引率計算用利用者ポイント」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納される。
【０１０４】
ここで、「利用者ポイント残高」とは、利用者１２が購買時に金銭のように使用することができるポイントのことで、例えば、取引時に取引額に応じて付与されたり、広告メールを会員１３から受け取った場合などに付与されたりする。  
また、「割引率計算用利用者ポイント」は、各種サービスの割引率を決定するとき等に使用されるポイントのことで、例えば、前月分の取引額の合計等から算出される。  
また、電話番号や住所等は複数登録できるようにしても良い。  
これ以外にも、商品代金等の引き落とし先としての「銀行口座番号」を格納しても良いし、クレジットカード決済を行う場合は、「クレジットカード番号」を格納しても良い。
【０１０５】
［３．３．２．２．グループ基本情報ＴＢＬ４１２１］
グループ基本情報ＴＢＬ４１２１には、利用者１２がメンバとして所属するグループ１Ａに関する基本的な属性が格納される。
具体的には、「グループＩＤ」、「グループ名称」、「グループ種類（仲間内のグループ,不特定多数のグループ,利用者個人）」、「結成日」、「活動内容」、「管理者の利用者ＩＤ」、「ＨＰアドレス」、「人数」、「グループポイント残高」、「割引率計算用グループポイント」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納される。さらにマーケティング情報としての、「興味のある分野に関する情報」、「通信量（メールや電子会議室の利用量を算出してランクＡ〜Ｅのように具体的な通信量がわからないように処理して記録しておく）」、「通話量（通信量と同様の処理をして記録する。）」、「取引量（取引金額を基に、通信料と同様の処理をして記録する。）」等の属性も格納される。
【０１０６】
ここで、人数は、後述するメンバ情報ＴＢＬ４１３から導出することができる。  
また、「グループポイント残高」は、グループ１Ａでの購買時にみんなで相談して、金銭のように使用することができるポイントのことで、例えば、取引時に取引額に応じて付与されたり、広告メールを会員１３から受け取った場合などに付与されたりする。
また、「割引率計算用グループポイント」は、同一グループ１Ａに所属する利用者１２同士の通話・通信等の使用料の割引率を決定するとき等に使用されるポイントで、例えば、前月分の取引額等から算出される。
また、グループ種類とは、グループ１Ａの種類を管理する属性で、括弧「（）」内に記載されている、「仲間内のグループ」、「不特定多数のグループ」、「利用者個人」等の種類を管理できる。
【０１０７】
［３．３．２．３．記念日情報ＴＢＬ４１２２］
記念日情報ＴＢＬ４１２２は、「グループＩＤ」、「記念日Ｎｏ」、「記念日」、「件名」、「内容」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納される。
【０１０８】
［３．３．２．４．提案依頼情報ＴＢＬ４１２３］
提案依頼情報ＴＢＬ４１２３は、「グループＩＤ」、「提案依頼Ｎｏ」、「分野」、「件名」、「内容」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納される。
【０１０９】
これらのマーケティング情報は、主催者が様々な属性を自由に設定して、マーケティング情報の価値を高めることが重要である。
【０１１０】
［３．３．２．５．メンバ情報ＴＢＬ４１３］
メンバ情報ＴＢＬ４１３は、「利用者ＩＤ」、「グループＩＤ」、「ステータス（未承認,承認済）」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納され、利用者情報ＴＢＬ４１１とグループ基本情報ＴＢＬ４１２１を関連付ける。言い換えると、どの利用者１２がどのグループ１Ａに所属して（メンバとなって）いるのかという情報を持つ。
【０１１１】
ここで、ステータスとは、グループ１Ａの管理者（利用者１２）によってメンバ登録が承認されたかどうかを管理するための属性で、括弧「（）」内に記載されている、「未承認」、「承認済」等の状態を管理できる（後述の「メンバ登録（新規・削除）Ｓ４１６」を参照）。
【０１１２】
［３．３．２．６．スレッド管理（利用者用）ＴＢＬ４１４］
スレッド管理（利用者用）ＴＢＬ４１４は、利用者１２が参加可能な電子会議室のスレッドについて、利用者１２の参照状況を管理するＴＢＬで、「利用者ＩＤ」、「グループＩＤ」、「スレッドＩＤ」、「参照済意見Ｎｏ」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納される。
【０１１３】
［３．３．２．７．グループＨＰコンテンツＴＢＬ４１５］
グループＨＰコンテンツＴＢＬ４１５には、利用者ＨＰやブログのコンテンツが格納されるＴＢＬで、「グループＩＤ」、「ＨＰ（ブログ）コンテンツ」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納される。
【０１１４】
［３．３．３．会員関係データベースＤＢ４２］
［３．３．３．１．会員情報ＴＢＬ４２１］
会員情報ＴＢＬ４２１には、会員１３に関する属性が格納される。
具体的には、「会員ＩＤ」、認証用の「パスワード」、「名称」、「郵便番号」、「住所」、「電話番号」、「メールアドレス」、「ＨＰアドレス」、「受注画面アドレス」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納される。これ以外にも、会員登録料やデータベース利用料や交渉権料や仲介手数料の引き落とし元、もしくは、決済代行サービスを行う場合に利用者１２から受け取る商品代金の振込先としての「銀行口座番号」を格納しても良いし、クレジットカード決済を行う場合は、「クレジットカード番号」を格納しても良い。
【０１１５】
［３．３．３．２．会員アクセス権限管理ＴＢＬ４２２］
会員アクセス権限管理ＴＢＬ４２２は、会員１３がグループサービスに参加する際の権限チェックに使用されるＴＢＬで、「会員ＩＤ」と「グループＩＤ」を持ち、会員１３とグループ１Ａ（正確にはグループサービス）を関連付けるためのものである。これ以外にも、参加可能なグループサービスの種類を管理するための「広告配信権フラグ」や「交渉権フラグ」、参加が可能となる電子会議室の「スレッドＩＤ」、「広告配信権を取得した日時」、「広告配信権の有効期限」、「交渉権を取得した日時」、「交渉権の有効期限」、「生成方法（会員１３による購入，利用者１２による付与）」、広告配信権の購入者の「会員ＩＤ」、広告配信権の付与者の「利用者ＩＤ」、利用者１２による付与の場合に使用される「お問い合わせ内容」、広告メールの「配信状況（未配信，配信済）」、「登録日」、「更新日」、「削除フラグ」、「削除日」といった属性を格納することで、交渉権の権利範囲を限定することができる。
【０１１６】
ここで、生成方法とは、会員１３が交渉権を取得した際の方法を管理するための属性で、括弧「（）」内に記載されている、「会員１３による購入」、「利用者１２による付与」等の方法を管理できる。
また、配信状況とは、会員１３が広告メールを送信したかどうかを管理するための属性で、括弧「（）」内に記載されている、「未配信」、「配信済」等の状態を管理できる。
【０１１７】
［３．３．３．３．スレッド管理（会員用）ＴＢＬ４２３］
スレッド管理（会員用）ＴＢＬ４２３は、会員１３が参加可能な電子会議室のスレッドについて、会員１３の参照状況を管理するＴＢＬで、「会員ＩＤ」、「グループＩＤ」、「スレッドＩＤ」、「参照済意見Ｎｏ」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納される。
【０１１８】
［３．３．３．４．会員ＨＰコンテンツＴＢＬ４２４］
会員ＨＰコンテンツＴＢＬ４２４は、会員ＨＰのコンテンツが格納されるＴＢＬで、「会員ＩＤ」、「ＨＰコンテンツ」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納される。
【０１１９】
［３．３．４．電子会議室関係データベースＤＢ４３］
［３．３．４．１．スレッド管理ＴＢＬ４３１］
スレッド管理ＴＢＬ４３１は、電子会議室のスレッドについて、書き込み状況等の状態を管理するＴＢＬで、「グループＩＤ」、「スレッドＩＤ」、「スレッド種類（会議室，（連絡専用）掲示板）」、「テーマ」、「ステータス（交渉中、通常）」、「最新意見Ｎｏ」、「登録日」、「更新日」、「削除フラグ」、「削除日」の属性が格納される。
【０１２０】
ここで、スレッド種類とは、電子会議室のスレッドの種類を管理する属性で、括弧「（）」内に記載されている、「会議室」、「（連絡専用）掲示板」等の種類を管理できる。
また、ステータスとは、利用者１２の電子会議室のスレッドに対する状態を管理する属性で、括弧「（）」内に記載されている、「交渉中」、「通常」等の状態を管理できる。交渉中となっているときは、利用者１２に交渉の意思があると判断され、有効期限後もスレッドの利用可能な状態を継続する。
【０１２１】
［３．３．４．２．電子会議室ＴＢＬ４３２］
電子会議室ＴＢＬ４３２は、電子会議室の意見データを格納するＴＢＬで、「グループＩＤ」、「スレッドＩＤ」、「意見Ｎｏ」、「書き込み者の利用者ＩＤもしくは書き込み者の会員ＩＤ」、「書き込み人名」、「日付」、「時刻」、「本文」、「削除フラグ」、「削除日」の属性が格納される。
【０１２２】
［３．３．５．取引関係データベースＤＢ４４］
［３．３．５．１．注文ＴＢＬ４４１］
注文ＴＢＬ４４１は、利用者１２と会員１３の間で取引が成立した場合に、利用者１２の注文を管理するための情報が格納される。  
具体的には、「注文Ｎｏ」、「注文明細Ｎｏ」、商品代金請求先（購入者、商品代金を支払う利用者１２）の「利用者ＩＤ」と「氏名」、商品の送付先となる利用者１２の「利用者ＩＤ」と「氏名」、「送付先郵便番号」、「送付先住所」、「送付先電話番号」、交渉に使用したコミュニティサービス（電子会議室等）をコミュニティサーバ４０により提供されている「グループＩＤ」と「グループ名称」（請求の範囲における「取引グループ情報」に相当する）、「受注日時」、「商品コード」、「商品名」、「単価」、「数量」、「値引き額」、「金額」、「商品受渡し状況（受渡済、未受渡）」、「決済状況（未決済，決済完了）」、取引する商品の売り手となる会員１３の「会員ＩＤ」、発注者（注文画面から注文内容を入力する利用者１２）の「利用者ＩＤ」、「注文取消フラグ」「注文取消日」等の属性が格納される。
【０１２３】
ここで、商品受渡し状況とは、会員１３が利用者１２に商品の受渡しを行ったかどうかを管理するための属性で、括弧「（）」内に記載されている、「受渡済」、「未受渡」等の状態を管理できる。
また、決済状況とは、会員１３が利用者１２に商品の受渡しを行った後に金銭の受渡しが行われたかどうかを管理するための属性で、括弧「（）」内に記載されている、「未決済」、「決済完了」等の状態を管理できる。
【０１２４】
［３．３．５．２．取引実績ＴＢＬ４４２］
取引実績ＴＢＬ４４２は、決済を管理するための情報が格納される。
具体的には、「決済Ｎｏ」、「注文Ｎｏ」、「注文明細Ｎｏ」、商品代金請求先（購入者、商品代金を支払う利用者１２）の「利用者ＩＤ」と「氏名」、交渉に使用したコミュニティサービス（電子会議室等）をコミュニティサーバ４０により提供されている「グループＩＤ」と「グループ名称」（請求の範囲における「取引グループ情報」に相当する）、「受注日時」、「商品コード」、「単価」、「数量」、「値引き額」、「金額」、取引する商品の売り手となる会員１３の「会員ＩＤ」、購入者の所属グループ１Ａの「グループＩＤ」、発注者（注文画面から注文内容を入力する利用者１２）の「利用者ＩＤ」、「仲介手数料」、「利用者ポイント」、「グループポイント」等の属性が格納される。
【０１２５】
［３．３．５．３．商品ＴＢＬ４４３］
商品ＴＢＬ４４３は、商品を管理するための情報が格納される。
具体的には、「商品ＩＤ」、「商品名」、「定価」、「値引き額」、「単価」、「在庫数」、「商品情報（製造元ＩＤ，ユーザグループのグループＩＤ，ユーザ管理サーバ９０のＵＲＬ等も含む）」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納される。
【０１２６】
［３．３．６．その他データベースＤＢ４５］
［３．３．６．１．通話／通信料金計算結果ＴＢＬ４５１］
通話／通信料金計算結果ＴＢＬ４５１は、通話／通信料金の計算結果を管理するための情報が格納される。
具体的には、「通話／通信Ｎｏ」、「利用者ＩＤ」、「通話／通信料金」、「割引率」、「割引額」、「割引適用後通話／通信料金」、「日時」等の属性が格納される。
【０１２７】
［３．３．６．２．商品受渡日管理ＴＢＬ４５２］
商品受渡日管理ＴＢＬ４５２は、商品を受渡した日付を管理するための情報が格納される。
具体的には、「受取人（所有者）の利用者ＩＤ」、「商品ＩＤ」、「商品名」、「商品受渡日」、「製造元名」、「製造元のユーザ管理サーバのＵＲＬ」「登録者の会員ＩＤ」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納される。
【０１２８】
［３．３．６．３．ユーザ登録画面ＴＢＬ４５３］
ユーザ登録画面ＴＢＬ４５３は、ユーザ登録画面のデータが格納される。
具体的には、「商品ＩＤ」、「ユーザ登録画面イメージデータ」、「登録日」、「更新日」、「削除フラグ」、「削除日」等の属性が格納される。
【０１２９】
［３．３．６．４．収益ＴＢＬ４５４］
収益ＴＢＬ４５４は、会員１３もしくは利用者１２から徴収した利用料等の収益に関する情報が格納される。  
具体的には、「収益Ｎｏ」、「収益発生元の会員ＩＤもしくは利用者ＩＤ」、「収益種類（会員登録料，マーケティング情報の利用料，交渉権料，取引仲介手数料）」、「金額」、「日時」等の属性が格納される。
【０１３０】
ここで、収益種類とは、収益の種類を管理するための属性で、括弧「（）」内に記載されている、「会員登録料」，「マーケティング情報の利用料」，「交渉権料」，「取引仲介手数料」等の状態を管理できる。
【０１３１】
［３．３．６．５．再投資額ＴＢＬ４５５］
再投資額ＴＢＬ４５５は、再投資額の計算結果が格納される。  
具体的には、「再投資額計算Ｎｏ」、「計算期間（年月日から年月日）」、「再投資額」「計算日」等の属性が格納される。
【０１３２】
［３．４．本発明システムの動作例］
次に、仕組みＡおよび仕組みＢについて、本実施の形態に係る本発明システムの動作について説明する。図６は本発明システムの一実施形態のデータフロー図（以下「ＤＦＤ」とする）で、仕組みＡおよび仕組みＢに関する動作の全体像を表している。本発明システムは、主なプロセスとして、利用者関係各種登録Ｓ４１、会員関係各種登録Ｓ４２、会員アクセス権限生成Ｓ４３、広告配信Ｓ４４、交渉Ｓ４５、注文Ｓ４６、受渡決済Ｓ４７のプロセスを有している。ここで、広告配信Ｓ４４は必須プロセスではないし、前記図３Ａ／図３Ｂの説明でも特には登場していない。
最初に、仕組みＡおよび仕組みＢに関する動作の全体像について、図６を参照しながら説明する。
【０１３３】
まず、利用者関係各種登録Ｓ４１において、利用者１２は、利用者端末５０を用いて利用者登録を行い、次に、同様に利用者登録を済ませた他の利用者たちを募り（正確には、仲間を募るのは、グループ１Ａを登録した後でも良い）、グループを結成し、グループ登録とグループ１Ａに所属する利用者１２であるメンバの登録を行い、利用者・グループ・メンバ情報ＴＢＬ４１０（ＴＢＬ４１１，ＴＢＬ４１２，ＴＢＬ４１３）に記録する。このとき、利用者１２の基本情報に加えて、グループ１Ａに関するマーケティング情報等も登録しておくこともできる。
【０１３４】
この時点で、グループ１Ａに所属する利用者１２は、グループ１Ａに提供されているグループサービス（コミュニティサービスを含む）を利用できるようになる。
【０１３５】
同時並行的に、会員関係各種登録Ｓ４２において、会員１３は、会員端末６０を用いて会員登録を行い、会員情報ＴＢＬ４２１に記録する。
【０１３６】
次に、会員アクセス権限生成Ｓ４３において、会員１３が広告配信権を購入する、もしくは、利用者１２が広告配信権を付与するなどして、会員１３がグループ１Ａに対してセールス活動を行う権限を生成し、会員アクセス権限管理ＴＢＬ４２２に記録する。実施の形態では、会員アクセス権限管理ＴＢＬ４２２という会員１３専用の権限管理ＴＢＬを設けることで、会員１３の権限であることが識別できる状態で記録することが可能となっている。
【０１３７】
次に、広告配信Ｓ４４において、会員１３は、会員端末６０を用いて広告を編集し、グループ１Ａのメンバである利用者１２たちに対して広告を送信する。このとき、会員アクセス権限管理ＴＢＬ４２２を参照して、広告配信権がある場合にのみ、送信することが可能となる。また、広告が送信された後に、会員アクセス権限管理ＴＢＬ４２２に広告配信したことを記録すると同時に、新たに交渉権を記録する。また、このとき、同時に電子会議室のスレッドを設置したりしても良い。
【０１３８】
また、広告配信Ｓ４４において、利用者１２は、会員１３から受け取った広告を見て、会員１３の提供する商品やサービスの購入を決定した場合、直接、注文Ｓ４６に遷移しても良い。
ここで、この広告配信Ｓ４４は必須処理ではない。広告配信Ｓ４４を省く場合、会員アクセス権限生成Ｓ４３において、広告配信権を生成せずに、交渉権を生成すれば良い。
【０１３９】
次に、交渉Ｓ４５において、利用者１２と会員１３は、それぞれ利用者端末５０と会員端末６０を用いて相互に交渉を行う。具体的には、電子会議室（電子掲示板）やメーリングリストなどのコミュニティサービスを利用する。このとき、利用者１２は、利用者・グループ・メンバ情報ＴＢＬ４１０（ＴＢＬ４１１，ＴＢＬ４１２，ＴＢＬ４１３）を基に、コミュニティサービスへのアクセスを許可する。また、会員１３は、会員アクセス権限管理ＴＢＬ４２２を基に、コミュニティサービスへのアクセスを許可する。
【０１４０】
次に、交渉の結果、利用者１２が会員１３の提供する商品やサービスの購入を決定した場合、注文Ｓ４６に遷移する。
【０１４１】
次に、注文Ｓ４６において、利用者１２は、利用者端末５０を用いて注文入力を行い、注文ＴＢＬ４４１に記録する。
【０１４２】
最後に受渡決済Ｓ４７において、注文ＴＢＬ４４１を基に、受渡決済処理を行い、取引実績ＴＢＬ４４２に記録する。
【０１４３】
ここで、図６においては、あくまで動作の全体像を表すことを目的としているため、すべてのＴＢＬが記載されているわけではなく、ポイントになるＴＢＬのみを記載していることを断っておく。
以下、前記利用者関係各種登録Ｓ４１から前記受渡決済Ｓ４７までの７つのプロセスについて順に説明していく。
【０１４４】
［３．４．１．利用者関係各種登録Ｓ４１］
利用者関係各種登録Ｓ４１は、利用者関係の各種登録を行うことを目的とするプロセスである。図７は図６の利用者関係各種登録Ｓ４１を展開した図で、本実施形態においては、利用者関係各種登録Ｓ４１は、利用者登録（新規）Ｓ４１１、利用者登録（変更・削除）Ｓ４１２、グループ登録（新規・変更・削除）Ｓ４１３、マーケティング情報登録（記念日）Ｓ４１４、マーケティング情報登録（提案依頼）Ｓ４１５、メンバ登録（新規・削除）Ｓ４１６、スレッド登録（新規・変更・削除）Ｓ４１７の７つのプロセスから構成されることを示している。なお図７では、利用者関係各種登録Ｓ４１は７つのプロセスで構成されているが、マーケティング情報をより充実させるためのプロセス等が利用者関係各種登録Ｓ４１に追加されても良い。以下、該７つのプロセスについて順に説明する。
【０１４５】
［３．４．１．１．利用者登録（新規）Ｓ４１１］
利用者登録（新規）Ｓ４１１は、利用者１２が自身に関する情報を入力し、本ビジネスモデルに利用者として登録することを目的とするプロセスである。
【０１４６】
システム的には、利用者１２（正確には、この時点ではまだ利用者ではない。）により編集・入力された利用者１２自身に関する情報を、利用者情報ＴＢＬ４１１に新規に記録する処理を行う。より詳細には、利用者登録（新規）Ｓ４１１は、図８のＤＦＤに示すような処理フローで実現することができる。以下、図８を参照しながら利用者登録（新規）Ｓ４１１の一例を説明する。
【０１４７】
利用者登録（新規）Ｓ４１１が開始されると、まず、Ｓ４１１１において、コミュニティサーバ４０は、利用者端末５０に利用者登録画面を表示させる（＜１＞）。なお、図中で使用している「丸数字（数字を丸で囲んだ記号）」は明細書中では数字を「＜＞」で囲んで表示するものとする。図９に、利用者端末５０に表示される利用者登録画面の一例を示す。
【０１４８】
利用者１２は、利用者端末５０に表示される該画面（図９）を通して、自身に関する情報を編集・入力し、[登録]ボタンを押下する（＜２＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４１１２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０１４９】
次に、Ｓ４１１２において、コミュニティサーバ４０は、利用者情報ＴＢＬ４１１を参照して利用者ＩＤの空き番号を自動で取得し、これを利用者ＩＤとすると同時に、更にパスワードの自動生成を行った後、受信した情報と一緒に利用者情報ＴＢＬ４１１に記録する。また、パスワードは、この段階では自動生成でも良いが、その場合は、利用者１２は初回ログイン時にパスワードを変更することが望ましい。
【０１５０】
なお、Ｓ４１１２の必須処理ではないが、実施の形態ではこれに加えて、利用者登録の際に該利用者１名のみが所属する、かつ、他の利用者が所属できないグループ１Ａを自動登録（同時にメンバ登録）する仕様にしている。これは前述した通り、利用者が、どのグループ１Ａにも属さない状態になることがあることを防ぎ、また、利用者個人もセールス対象に加えることを目的とした処理である。
【０１５１】
該仕様を実現するために、Ｓ４１１２において、利用者情報ＴＢＬ４１１への記録に加えて、グループ基本情報ＴＢＬ４１２１に新しいグループ１Ａの記録を行う。ここで、グループＩＤは、利用者ＩＤ同様に、グループ基本情報ＴＢＬ４１２１を参照して、空き番号を自動取得すれば良いが、利用者ＩＤから連想される番号をグループＩＤとしても良い（例えば、利用者ＩＤが「Ｒ００００１」であれば、グループＩＤは「Ｇ００００１」といった具合。）。グループ名は、利用者氏名をそのまま使うこともできる。グループ種類は、「利用者個人」をセットする。その他の属性は、入力情報から取得する、もしくは、いったんＮＵＬＬ値としておき、別途、グループ情報関連の登録画面から入力するようにしても良い。メンバ情報ＴＢＬ４１３には、自動取得した利用者ＩＤとグループＩＤを記録する（「ステータス」の属性には「承認済」をセットする）。
【０１５２】
最後に、Ｓ４１１２において、コミュニティサーバ４０は登録完了メッセージを利用者端末５０に送信し、画面に表示させる（＜３＞）。図１０は、登録完了メッセージ画面の一例である。自動取得した利用者ＩＤとグループＩＤとパスワードが表示されている。ここで[ＯＫ]ボタンをクリックすると、すぐにログインする仕様にしても良い。
【０１５３】
利用者１２は、利用者登録（新規）Ｓ４１１を済ませると、好きなときに本発明システムにログインできるようになる。図１１は、利用者登録（新規）Ｓ４１１を済ませることによって使用できるようになるログイン処理（利用者ログインＳ４８）の一例を示すＤＦＤである。以下、図１１を参照しながら利用者ログインＳ４８の一例を説明する。
【０１５４】
利用者ログインＳ４８が開始されると、まず、Ｓ４８１において、コミュニティサーバ４０は利用者端末５０にログイン画面を表示させる（＜１＞）。図１２は、利用者端末５０に表示されるログイン画面の一例である。利用者１２は、利用者端末５０に表示される該画面（図１２）を通して、ログイン情報（利用者ＩＤ，パスワード）を入力し、[ログイン]ボタンを押下する（＜２＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した利用者ＩＤを用いて、利用者情報ＴＢＬ４１１に記録されているパスワードを参照し、受信したパスワードと照合する。一致する場合は、ログイン認証が成功したことになり、コミュニティサーバ４０は、端末を特定できるように処理する。具体的には、例えば、端末にＷＥＢブラウザを用いる場合は、コミュニティサーバ４０は、セッションＩＤ（端末を特定するための情報）を発行し、利用者端末５０に送信する。利用者端末５０では、クッキーという仕組みを使い、該セッションＩＤを記憶する。同時に、コミュニティサーバ４０は、セッションＩＤと関連付けてセッションスコープ（各端末に割り当てられる記憶領域）を確保し、利用者ＩＤや利用者氏名等の基本情報を記憶する。次に、コミュニティサーバ４０は、実行プロセスをＳ４８２に遷移する。
【０１５５】
Ｓ４８２において、コミュニティサーバ４０は、利用者端末５０にメニュー画面を表示させる（＜３＞）。図１３はメニュー画面の一例である。
【０１５６】
利用者１２は、利用者ログインＳ４８を終えると、利用者ログイン認証が必要となる利用者向けサービス（例えば、「電子会議室」、「ショッピングモール」などのグループサービス）を利用できる状態になる。
【０１５７】
付け加えておくと、利用者ログイン認証Ｓ４８１は、上述したようなパスワード認証方式に限定されない。バイオメトリクス（生体）認証方式等を利用することも可能である。
【０１５８】
［３．４．１．２．利用者登録（変更・削除）Ｓ４１２］
利用者登録（変更・削除）Ｓ４１２は、利用者１２が、自身の利用者情報を変更する、もしくは、本ビジネスモデルを脱退する場合に自身の利用者情報を削除することを目的とするプロセスである。
【０１５９】
システム的には、利用者１２が、利用者端末５０を通して、現在の利用者登録情報を取得し、これを修正し、利用者情報ＴＢＬ４１１等の該当レコードを更新もしくは削除する処理を行う。より詳細には、図１４のＤＦＤに示すような処理フローで実現することができる。以下、図１４を参照しながら利用者登録（変更・削除）Ｓ４１２の一例を説明する。
【０１６０】
Ｓ４８において、利用者１２は本発明システムにログイン（＜１＞）し、利用者メニュー画面（図１３）において、[利用者登録（変更・削除）]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４１２１に遷移する。次に、Ｓ４１２１において、コミュニティサーバ４０は、利用者情報ＴＢＬ４１１から現在の登録情報を取得し、編集画面を利用者端末５０に表示させる（＜３＞）。図１５は、編集画面（利用者登録（変更・削除）画面）の一例である。
【０１６１】
変更する場合は、Ｓ４１２１において、利用者１２は、利用者端末５０に表示される該画面（図１５）を通して、自身（利用者１２）に関する情報を修正編集し、[登録]ボタンを押下する（＜４＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４１２２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０１６２】
次に、Ｓ４１２２において、コミュニティサーバ４０は、受信した情報を基に利用者情報ＴＢＬ４１１を更新する。  
同時に、グループ種類＝「利用者個人」の場合等で、グループ基本情報ＴＢＬ４１２１に影響する変更がある場合は、これも更新する（実施の形態では、利用者登録の際に、同時に利用者個人のグループ１Ａを登録しており、このときに、利用者情報を利用してグループ情報をセットしている場合がある。例えばグループ名称に利用者氏名を使用するなど。）。
【０１６３】
最後に、コミュニティサーバ４０は登録完了メッセージを利用者端末５０に送信し、利用者端末５０の画面に登録完了メッセージを表示させる（＜５＞）。本明細書では、該登録完了メッセージの画面例を割愛しているが、図１０に示す画面例を参考にすることができる。
【０１６４】
削除する場合は、Ｓ４１２１において、利用者１２は、編集画面（図１５）上の[削除]チェックボックスをチェックして、[登録]ボタンを押下する（＜４＞）。削除情報を受信したコミュニティサーバ４０は、注文ＴＢＬ４４１を参照して、決済の終わっていない注文が存在しないことと、グループ基本情報ＴＢＬ４１２１を参照して、削除対象の利用者１２が管理者となっているグループ１Ａが存在しないこと等を確認し、問題がない場合は実行プロセスをＳ４１２２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０１６５】
次に、Ｓ４１２２において、コミュニティサーバ４０は、利用者登録が削除されることによって影響を受けるすべてのＴＢＬ上のレコードについて、削除フラグをＯＮに更新し、削除日を記録する。具体的には、利用者情報ＴＢＬ４１１と、グループ情報ＴＢＬ４１２（ＴＢＬ４１２１，ＴＢＬ４１２２，ＴＢＬ４１２３）と、メンバ情報ＴＢＬ４１３と、スレッド管理（利用者用）ＴＢＬ４１４と、グループＨＰコンテンツＴＢＬ４１５と、会員アクセス権限管理ＴＢＬ４２２と、スレッド管理（会員用）ＴＢＬ４２３と、スレッド管理ＴＢＬ４３１と、電子会議室ＴＢＬ４３２等である。さらに、削除日からの経過日数を基準に、バッチ処理で物理的にレコードを削除すれば良い。
【０１６６】
最後に、登録完了メッセージ（正確には削除完了メッセージ）を利用者端末５０の画面に表示させる（＜５＞）。
【０１６７】
また、図１５では、[パスワード変更]ボタンを用意しているが、これを押下した場合は、利用者端末５０に、図１６のパスワード変更（利用者用）画面が表示され、これを用いてパスワードを変更することができる。
【０１６８】
この利用者登録（変更・削除）Ｓ４１２の機能の内、特に削除機能は、利用者１２本人のみが行えるように権限管理するのが望ましい。
【０１６９】
［３．４．１．３．グループ登録（新規・変更・削除）Ｓ４１３］
グループ登録（新規・変更・削除）Ｓ４１３は、利用者１２が、利用者登録（新規）Ｓ４１１を済ませた利用者１２を募って、グループ１Ａを結成するとき、これを本発明システムに登録することを目的とするプロセスである。また、登録されたグループ情報の変更、および、グループ１Ａを解散した際の該グループ情報の削除にも使用される。
【０１７０】
システム的には、利用者１２が利用者端末５０を通して、結成するグループ１Ａに関するグループ情報をコミュニティサーバ４０に入力・送信し、グループ基本情報ＴＢＬ４１２１に新規に記録する、もしくは、更新する、もしくは、削除する処理を行う。より詳細には、図１７のＤＦＤに示すような処理フローで実現することができる。以下、図１７を参照しながらグループ登録（新規・変更・削除）Ｓ４１３の一例を説明する。
【０１７１】
Ｓ４８において、利用者１２は本発明システムにログイン（＜１＞）し、利用者メニュー画面（図１３）において、[グループ登録（新規・変更・削除）]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４１３１に遷移し、編集画面を利用者端末５０に表示させる（＜３＞）。図１８は、編集画面（グループ登録（新規・変更・削除）画面）の一例である。
【０１７２】
図１８に示す画面例において、[グループＩＤ]リストボックスは、「新規」と登録者自身が所属するグループ１Ａを選択することができる。すなわち、表示する際に、グループ基本情報ＴＢＬ４１２１とメンバ情報ＴＢＬ４１３より、登録者が所属するグループ１Ａのリスト（グループＩＤ，グループ名称）を導出し、これを[グループＩＤ]リストボックスにロードする。
【０１７３】
同様に図１８に示す画面例において、[グループ種類]リストボックスは、「仲間内のグループ,不特定多数のグループ」の２種類から選択することが可能である。ここで、[グループＩＤ]リストボックスにおいて、利用者個人のグループ１Ａを選択した場合は、グループ種類＝「利用者個人」が表示されるが、他のグループ種類に変更することはできない。ちなみに、本実施の形態においては、このグループ種類＝「利用者個人」という登録は、利用者登録時にのみ、自動で登録されるものであり、この画面で登録することはできないし、変更することもできない仕様にしている。
【０１７４】
同様に図１８に示す画面例において、[管理者]リストボックスは、該グループ１Ａに所属するメンバを選択することができる。すなわち、
[グループＩＤ]リストボックスを選択し、[登録情報取得]ボタンを押下すると、利用者情報ＴＢＬ４１１とメンバ情報ＴＢＬ４１３より、グループ１Ａに所属するメンバのリスト（利用者ＩＤ，利用者氏名）を導出し、これを[管理者]リストボックスにロードする。
【０１７５】
新規に登録する場合は、Ｓ４１３１において、利用者１２は、編集画面（図１８）上の[グループＩＤ]リストボックスで「新規」を選択し、続いて他の項目を入力していく。
[管理者]リストボックスは、この時点では、登録者本人しかメンバが確定していないため、登録者自身しか選択できない。編集・入力を終えたら、編集画面（図１８）上の[登録]ボタンを押下する（＜４＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４１３２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０１７６】
次に、Ｓ４１３２において、コミュニティサーバ４０はグループ基本情報ＴＢＬ４１２１を参照して、グループＩＤの空き番号を取得し、受信した情報と一緒にグループ基本情報ＴＢＬ４１２１に記録する。同時に、メンバ情報ＴＢＬ４１３に登録者自身を該グループ１Ａのメンバとして記録する。
【０１７７】
最後に、コミュニティサーバ４０は登録完了メッセージを利用者端末５０に送信し、画面に表示する（＜５＞）。図１９は、新規にグループ登録した場合の登録完了メッセージ画面の一例である。自動取得したグループＩＤが表示されている。
【０１７８】
変更する場合は、Ｓ４１３１において、利用者１２は、編集画面（図１８）上の[グループＩＤ]リストボックスで、登録情報を変更したいグループ１Ａを選択し、[登録情報取得]ボタンを押下する。すると、コミュニティサーバ４０は該グループ１Ａのグループ情報をグループ基本情報ＴＢＬ４１２１から取得し、画面の各項目に表示する。続いて利用者１２はこれらの項目を修正入力していく。
【０１７９】
編集を終えたら、利用者１２は編集画面（図１８）上の[登録]ボタンを押下する（＜４＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４１３２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０１８０】
次に、Ｓ４１３２において、コミュニティサーバ４０は、受信した情報を基にグループ基本情報ＴＢＬ４１２１を更新する。
【０１８１】
最後に、コミュニティサーバ４０は登録完了メッセージを利用者端末５０に送信し、画面に表示する（＜５＞）。本明細書では、変更時の登録完了メッセージの画面例を割愛しているが、図１９を参考にすることができる。
【０１８２】
削除する場合は、Ｓ４１３１において、利用者１２は編集画面（図１８）上の「削除」チェックボックスをチェックして、[登録]ボタンを押下する（＜４＞）。Ｓ４１３２において、削除情報を受け取ったコミュニティサーバ４０は、グループ１Ａが削除されることにより影響を受けるすべてのＴＢＬ上のレコードについて、削除フラグをＯＮに更新し、削除日を記録する。具体的には、グループ情報ＴＢＬ４１２（ＴＢＬ４１２１，ＴＢＬ４１２２，ＴＢＬ４１２３）と、メンバ情報ＴＢＬ４１３と、スレッド管理（利用者用）ＴＢＬ４１４と、グループＨＰコンテンツＴＢＬ４１５と、会員アクセス権限管理ＴＢＬ４２２と、スレッド管理（会員用）ＴＢＬ４２３と、スレッド管理ＴＢＬ４３１と、電子会議室ＴＢＬ４３２等である。さらに、削除日からの経過日数を基準に、バッチ処理で物理的にレコードを削除すれば良い。
【０１８３】
最後に、登録完了メッセージを利用者端末５０の画面に表示させる（＜５＞）。
【０１８４】
このグループ登録処理（新規・変更・削除）Ｓ４１３の機能の内、特に削除機能は、グループ１Ａの管理者のみが行えるように権限管理するのが望ましい。
【０１８５】
［３．４．１．４．マーケティング情報登録（記念日）Ｓ４１４］
マーケティング情報登録（記念日）Ｓ４１４は、利用者１２が、グループ１Ａのマーケティング情報としての記念日情報を本発明システムに登録することを目的とするプロセスである。また、登録された記念日情報を変更する場合や削除する場合にも使用される。
【０１８６】
システム的には、利用者１２が、利用者端末５０を通してグループ１Ａの記念日情報を入力し、記念日情報ＴＢＬ４１２２に新規に記録、もしくは更新、もしくは削除する処理を行う。より詳細には、図２０のＤＦＤに示すような処理フローで実現することができる。以下、図２０を参照しながらマーケティング情報登録（記念日）Ｓ４１４の一例を説明する。
【０１８７】
Ｓ４８において、利用者１２は本発明システムにログイン（＜１＞）し、利用者メニュー画面（図１３）において、[マーケティング情報登録（記念日）]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４１４１に遷移する。次に、Ｓ４１４１において、コミュニティサーバ４０は、記念日情報ＴＢＬ４１２２から現在の登録情報を取得し、編集画面を利用者端末５０に表示させる（＜３＞）。図２１は、編集画面（マーケティング情報登録（記念日）画面）の一例である。
【０１８８】
図２１に示す画面例において、[グループＩＤ]リストボックスでは、登録者自身が所属するグループ１Ａを選択することが可能である。すなわち、表示する際に、グループ基本情報ＴＢＬ４１２１とメンバ情報ＴＢＬ４１３より、登録者が所属するグループ１Ａのリスト（グループＩＤ，グループ名称）を導出し、これを[グループＩＤ]リストボックスにロードする。
【０１８９】
同様に図２１に示す画面例において、[記念日Ｎｏ]リストボックスでは、「新規」と、[グループＩＤ]リストボックスで選択されたグループ１Ａの既に登録された記念日情報の番号（記念日Ｎｏ）を選択することができる。すなわち、[グループＩＤ]リストボックスで対象グループ１Ａを選択して、[登録情報取得]ボタンを押下すると、記念日情報ＴＢＬ４１２２から、選択されたグループ１Ａの登録済み記念日情報のリスト（記念日Ｎｏ，件名）を取得し、[記念日Ｎｏ]リストボックスにロードする。
【０１９０】
記念日情報を新規に登録する場合は、Ｓ４１４１において、利用者１２は編集画面（図２１）上で、[グループＩＤ]リストボックスで対象グループ１Ａを選択した後、[記念日Ｎｏ]リストボックスで「新規」を選択し、[登録情報取得]ボタンを押下して、表示内容をリセットし、続いて他の項目を入力していく。
【０１９１】
編集を終えたら、利用者１２は編集画面（図２１）上の[登録]ボタンを押下する（＜４＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４１４２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０１９２】
次に、Ｓ４１４２において、コミュニティサーバ４０は、記念日情報ＴＢＬ４１２２を参照して、記念日Ｎｏの空き番号を取得し、受信した情報と一緒に記念日情報ＴＢＬ４１２２に記録する。
【０１９３】
最後に、コミュニティサーバ４０は登録完了メッセージを利用者端末５０に送信し、画面に表示させる（＜５＞）。
【０１９４】
記念日情報を変更する場合は、Ｓ４１４１において、利用者１２は編集画面（図２１）上で、 [グループＩＤ]リストボックスで対象グループ１Ａを選択した後、[登録情報取得]ボタンを押下して、表示内容（[記念日Ｎｏ]リストボックス）を更新する。[記念日Ｎｏ]リストボックスで、変更しようとする記念日Ｎｏを選択し、再度、[登録情報取得]ボタンを押下して、表示内容を更新する。このとき、記念日情報は記念日情報ＴＢＬ４１２２から取得して表示内容を更新する。続いて他の項目を修正入力していく。
【０１９５】
編集を終えたら、利用者１２は編集画面上の[登録]ボタンを押下する（＜４＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４１４２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０１９６】
次に、Ｓ４１４２において、コミュニティサーバ４０は、受信した情報を基に記念日情報ＴＢＬ４１２２を更新する。
【０１９７】
最後に、コミュニティサーバ４０は登録完了メッセージを利用者端末５０に送信し、画面に表示させる（＜５＞）。
【０１９８】
記念日情報を削除する場合は、Ｓ４１４１において、利用者１２は編集画面（図２１）上の「グループＩＤ」リストボックスと[記念日Ｎｏ]リストボックスで、削除対象となる記念日情報を選択し、「削除」チェックボックスをチェックして、 [登録]ボタンを押下する（＜４＞）。Ｓ４１４２において、削除情報を受け取ったコミュニティサーバ４０は、記念日情報ＴＢＬ４１２２上の関連するレコードの削除フラグをＯＮに更新し、削除日を記録する。さらに、削除日からの経過日数を基準に、バッチ処理で物理的にレコードを削除すれば良い。
【０１９９】
最後に、登録完了メッセージを利用者端末５０の画面に表示させる（＜５＞）。
【０２００】
［３．４．１．５．マーケティング情報登録（提案依頼）Ｓ４１５］
マーケティング情報登録（提案依頼）Ｓ４１５は、利用者１２が、グループ１Ａのマーケティング情報としての提案依頼情報を本発明システムに登録することを目的とするプロセスである。また、登録された提案依頼情報を変更する場合や削除する場合にも使用される。
【０２０１】
システム的には、利用者１２が、利用者端末５０を通してグループ１Ａの提案依頼情報を入力し、提案依頼情報ＴＢＬ４１２３に新規に記録、もしくは更新、もしくは削除する処理を行う。より詳細には、図２２のＤＦＤに示すような処理フローで実現することができる。以下、図２２を参照しながらマーケティング情報登録（提案依頼）Ｓ４１５の一例を説明する。
【０２０２】
Ｓ４８において、利用者１２は本発明システムにログイン（＜１＞）し、利用者メニュー画面（図１３）において、[マーケティング情報登録（提案依頼）]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４１５１に遷移する。次に、Ｓ４１５１において、コミュニティサーバ４０は、提案依頼情報ＴＢＬ４１２３から現在の登録情報を取得し、編集画面を利用者端末５０に表示させる（＜３＞）。図２３は、編集画面（マーケティング情報登録（提案依頼）画面）の一例である。
【０２０３】
図２３に示す画面例において、[グループＩＤ]リストボックスでは、登録者自身が所属するグループ１Ａを選択することが可能である。すなわち、表示する際に、グループ基本情報ＴＢＬ４１２１とメンバ情報ＴＢＬ４１３より、登録者が所属するグループ１Ａのリスト（グループＩＤ，グループ名称）を導出し、これを[グループＩＤ]リストボックスにロードする。
【０２０４】
同様に図２３に示す画面例において、[提案依頼Ｎｏ]リストボックスでは、「新規」と、[グループＩＤ]リストボックスで選択されたグループ１Ａの既に登録された提案依頼情報の番号（提案依頼Ｎｏ）を選択することができる。すなわち、[グループＩＤ]リストボックスを選択して、[登録情報取得]ボタンを押下すると、提案依頼情報ＴＢＬ４１２３から、選択されたグループ１Ａの登録済み提案依頼情報のリスト（提案依頼Ｎｏ，件名）を取得し、[提案依頼Ｎｏ]リストボックスにロードする。
【０２０５】
提案依頼情報を新規に登録する場合は、Ｓ４１５１において、利用者１２は編集画面（図２３）上で、[グループＩＤ]リストボックスで対象グループ１Ａを選択した後、[提案依頼Ｎｏ]リストボックスで「新規」を選択し、[登録情報取得]ボタンを押下して、表示内容をリセットし、続いて他の項目を入力していく。
【０２０６】
編集・入力を終えたら、利用者１２は、編集画面（図２３）上の[登録]ボタンを押下する（＜４＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４１５２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０２０７】
次に、Ｓ４１５２において、コミュニティサーバ４０は、提案依頼情報ＴＢＬ４１２３を参照して、提案依頼Ｎｏの空き番号を取得し、受信した情報と一緒に提案依頼情報ＴＢＬ４１２３に記録する。
【０２０８】
最後に、コミュニティサーバ４０は登録完了メッセージを利用者端末５０に送信し、画面に表示させる（＜５＞）。
【０２０９】
提案依頼情報を変更する場合は、Ｓ４１５１において、利用者１２は編集画面（図２３）上で、[グループＩＤ]リストボックスで対象グループ１Ａを選択した後、[登録情報取得]ボタンを押下して、表示内容（[提案依頼Ｎｏ]リストボックス）を更新する。[提案依頼Ｎｏ]リストボックスで、変更しようとする提案依頼Ｎｏを選択し、[登録情報取得]ボタンを押下して、表示内容を更新する。このとき、提案依頼情報は提案依頼情報ＴＢＬ４１２３から取得して表示内容を更新する。続いて他の項目を修正入力していく。
【０２１０】
編集を終えたら、編集画面（図２３）上の[登録]ボタンを押下する（＜４＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４１５２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。  
次に、Ｓ４１５２において、コミュニティサーバ４０は、受信した情報を基に提案依頼情報ＴＢＬ４１２３を更新する。
【０２１１】
最後に、コミュニティサーバ４０は登録完了メッセージを利用者端末５０に送信し、画面に表示する（＜５＞）。
【０２１２】
提案依頼情報を削除する場合は、Ｓ４１５１において、利用者１２は編集画面（図２３）上の「グループＩＤ」リストボックスと[提案依頼Ｎｏ]リストボックスで、削除対象となる提案依頼情報を選択し、「削除」チェックボックスをチェックして、[登録]ボタンを押下する（＜４＞）。Ｓ４１５２において、削除情報を受け取ったコミュニティサーバ４０は、提案依頼情報ＴＢＬ４１２３上の関連するレコードの削除フラグをＯＮに更新し、削除日を記録する。さらに、削除日からの経過日数を基準に、バッチ処理で物理的にレコードを削除すれば良い。
【０２１３】
最後に、登録完了メッセージを利用者端末５０の画面に表示させる（＜５＞）。
【０２１４】
［３．４．１．６．メンバ登録（新規・削除）Ｓ４１６］
メンバ登録（新規・削除）Ｓ４１６は、利用者１２をグループ１Ａに所属させるために、メンバとして登録することを目的とするプロセスである。また、登録を削除する場合にも使用される。
グループ１Ａに利用者１２をメンバ登録する方法には２つある。１つは、グループ１Ａに参加しようとする利用者１２がグループ１Ａの管理者（利用者´（買い手）１２）に対して参加希望の意思を伝え、管理者がこれを承認する方法である。もう１つは、管理者（利用者´（買い手）１２）が利用者１２に対して、グループ１Ａへの参加勧誘を行い、利用者１２がこれに応じる方法である。どちらからアプローチするかの違いはあるにせよ、いずれの方法も利用者１２と管理者の双方の同意が必要となる。実施の形態では、前者の方法を採用している。
【０２１５】
図２４は、メンバ登録（新規・削除）Ｓ４１６の具体例を示すＤＦＤであり、この例では、メンバ登録（新規・削除）Ｓ４１６がメンバ登録申請Ｓ４１６１のプロセスと、メンバ承認Ｓ４１６２のプロセスから構成されることを示している。
【０２１６】
システム的には次のような処理になる。Ｓ４１６１において、グループ１Ａにメンバとして参加を希望する利用者１２は、利用者端末５０−１を通して、メンバ登録申請を行うと、コミュニティサーバ４０は、これをメンバ情報ＴＢＬ４１３に未承認の状態で記録する。Ｓ４１６２において、前記グループ１Ａの管理者としての利用者´（買い手）１２は、利用者´端末５０−２を通して、自身が管理者を務めるグループ１Ａに対するメンバ登録申請の情報を取得し、これらを承認すると、コミュニティサーバ４０は、メンバ情報ＴＢＬ４１３上の該当する情報を承認済に更新する。より詳細には、図２５および図２７のＤＦＤに示すような処理フローで実現することができる。
【０２１７】
以下、メンバ登録申請Ｓ４１６１のプロセスと、メンバ承認Ｓ４１６２のプロセスの一例について、図２５および図２７を参照しながら説明する。
【０２１８】
［３．４．１．６．１．メンバ登録申請Ｓ４１６１］
まず、メンバ登録申請Ｓ４１６１について図２５を参照しながら説明する。図２５は、メンバ登録申請Ｓ４１６１の一例を示すデータフロー図である。
【０２１９】
Ｓ４８において、利用者１２は本発明システムにログイン（＜１＞）し、利用者メニュー画面（図１３）において、[メンバ登録申請（新規・削除）]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４１６１１に遷移し、編集画面を利用者端末５０−１に表示させる（＜３＞）。図２６は、編集画面（メンバ登録申請（新規・削除）画面）の一例である。  
【０２２０】
図２６に示す画面例において、[グループＩＤ]リストボックスは、「新規」もしくは、登録者が所属しているグループ１Ａを選択することができる。すなわち、画面表示の際に、グループ基本情報ＴＢＬ４１２１とメンバ情報ＴＢＬ４１３から、自身が所属するグループ１Ａのリスト（グループＩＤ，グループ名）を導出し、これを[グループＩＤ]リストボックスにロードする。
【０２２１】
メンバ登録を新規に行う場合は、[グループＩＤ]リストボックスで「新規」を選択し、続いて参加を希望するグループ１ＡのグループＩＤを入力する。編集・入力を終えたら、利用者１２は編集画面（図２６）上の[登録]ボタンを押下する（＜４＞）。すると、入力情報が、利用者端末５０−１からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行い、参加を希望するグループＩＤがグループ基本情報ＴＢＬ４１２１上に存在していることを確認し、さらに、メンバ情報ＴＢＬ４１３上に既に同じ登録がないことを確認した後に、問題がなければ、実行プロセスをＳ４１６１２に遷移する。問題のある場合には、利用者端末５０−１にエラーメッセージを返信し、正しい入力を促す。
【０２２２】
次に、Ｓ４１６１２において、コミュニティサーバ４０は、受信した情報をメンバ情報ＴＢＬ４１２に記録する。このとき、「ステータス」の属性は「未承認」としておく。
【０２２３】
最後に、コミュニティサーバ４０は登録完了メッセージを利用者端末５０−１に送信し、画面に表示する（＜５＞）。
【０２２４】
メンバ登録を削除する場合は、Ｓ４１６１１において利用者１２は[グループＩＤ]リストボックスで、脱退したい（すなわち、メンバ登録を削除したい）グループ１Ａを選択し、「削除」チェックボックスをチェックして、編集画面（図２６）上の[登録]ボタンを押下する（＜４＞）。Ｓ４１６１２において、削除情報を受け取ったコミュニティサーバ４０は、メンバ登録が削除されることにより影響を受けるすべてのＴＢＬ上のレコードについて、削除フラグをＯＮに更新し、削除日を記録する。具体的には、メンバ情報ＴＢＬ４１３とスレッド管理（利用者用）ＴＢＬ４１４等である。さらに、削除日からの経過日数を基準に、バッチ処理で物理的にレコードを削除すれば良い。
【０２２５】
最後に、登録完了メッセージを利用者端末５０−１の画面に表示する（＜５＞）。
【０２２６】
［３．４．１．６．２．メンバ承認Ｓ４１６２］
次に、メンバ承認Ｓ４１６２について図２７を参照しながら説明する。図２７は、メンバ承認Ｓ４１６２の一例を示すデータフロー図である。
【０２２７】
Ｓ４８において、グループ１Ａの管理者としての利用者´１２は本発明システムにログイン（＜１＞）し、利用者メニュー画面（図１３）において、[メンバ承認]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４１６２１に遷移し、編集画面を利用者´端末５０−２に表示させる（＜３＞）。図２８は、編集画面（メンバ承認画面）の一例である。  
【０２２８】
承認する場合は、利用者´１２は、Ｓ４１６２１において、編集画面（図２８）上の[未承認リスト]ボタンを押下すると、コミュニティサーバ４０は、利用者情報ＴＢＬ４１１とグループ基本情報ＴＢＬ４１２１とメンバ情報ＴＢＬ４１３から利用者´１２が管理者となっているグループ１Ａに対する未承認状態のメンバ登録申請者のリストを抽出し、そのリストを利用者´端末５０−２に表示させる。次に、利用者´１２は承認しようとするメンバ登録申請者のチェックボックスにチェック入力し、編集画面（図２８）上の[承認]ボタンを押下する（＜４＞）。すると、入力情報が、利用者´端末５０−２からコミュニティサーバ４０に送信される。入力情報を受信したコミュニティサーバ４０は、実行プロセスをＳ４１６２２に遷移する。
【０２２９】
次に、Ｓ４１６２２において、コミュニティサーバ４０は、メンバ情報ＴＢＬ４１３上の該当するレコードの「ステータス」属性を、「未承認」から「承認済」に更新する。同時に、コミュニティサーバ４０は、スレッド管理（利用者用）ＴＢＬ４１４に、承認されることによって、利用者１２が新しく参加可能となったグループ１Ａの電子会議室のスレッドを登録する。このとき、「参照済意見Ｎｏ」属性は、「０（未読）」である。
【０２３０】
最後に、コミュニティサーバ４０は承認完了メッセージを利用者´端末５０−２に送信し、画面に表示する（＜５＞）。
【０２３１】
承認ミス等で、未承認状態に戻す場合は、図２８に示す編集画面において、利用者´１２は[承認済リスト]ボタンを押下すると、コミュニティサーバ４０は、利用者情報ＴＢＬ４１１とグループ基本情報ＴＢＬ４１２１とメンバ情報ＴＢＬ４１３から利用者´１２が管理者となっているグループ１Ａの承認済メンバのリストを抽出し、利用者´端末５０−２に表示させる。次に、承認を解除しようとするメンバのチェックボックスにチェック入力し、編集画面（図２８）上の[承認解除]ボタンを押下する（＜４＞）。すると、入力情報が、利用者´端末５０−２からコミュニティサーバ４０に送信される。入力情報を受信したコミュニティサーバ４０は、実行プロセスをＳ４１６２２に遷移する。
【０２３２】
次に、Ｓ４１６２２において、コミュニティサーバ４０は、メンバ情報ＴＢＬ４１３上の該当するレコードの「ステータス」属性を、「承認済」から「未承認」に更新する。同時に、コミュニティサーバ４０は、スレッド管理（利用者用）ＴＢＬ４１４上の、承認解除されたグループ１Ａのスレッドの削除フラグをＯＮに更新し、削除日を記録する。さらに、削除日からの経過日数を基準に、バッチ処理で物理的にレコードを削除すれば良い。
【０２３３】
最後に、コミュニティサーバ４０は承認完了メッセージを利用者´端末５０−２に送信し、画面に表示させる（＜５＞）。
【０２３４】
最後に付け加えておくと、管理人としての利用者´１２自身を未承認状態にすることはできないような仕様にしておくと良い。
【０２３５】
また、本実施の形態では、不特定多数の利用者１２によるグループ参加を防ぐ目的で、グループ管理者が承認する仕様としているが、不特定多数の参加を認める場合は、該プロセスＳ４１６２を無くしても良いし、登録申請があった際に自動的に承認するようにしても良い。
【０２３６】
［３．４．１．７．スレッド登録（新規・変更・削除）Ｓ４１７］
スレッド登録（新規・変更・削除）Ｓ４１７は、利用者１２が、グループ１Ａの電子会議室のスレッド（テーマ、議題）を登録することを目的とするプロセスである。また、登録されたスレッドの登録情報を変更する場合や削除する場合にも使用される。
【０２３７】
システム的には、利用者１２が、利用者端末５０を通して、新しく設置する電子会議室のスレッドの情報を入力し、スレッド管理ＴＢＬ４３１と電子会議室ＴＢＬ４３２とスレッド管理（利用者用）ＴＢＬ４１４に記録する処理を行う。より詳細には、スレッド登録（新規・変更・削除）Ｓ４１７は、図２９のＤＦＤに示すような処理フローで実現することができる。以下、図２９を参照しながらスレッド登録（新規・変更・削除）Ｓ４１７の一例を説明する。
【０２３８】
Ｓ４８において、利用者１２は本発明システムにログイン（＜１＞）し、利用者メニュー画面（図１３）において、[スレッド登録（新規・変更・削除）]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４１７１に遷移し、編集画面を利用者端末５０に表示させる（＜３＞）。図３０は、編集画面（スレッド登録（新規・変更・削除）画面）の一例である。
【０２３９】
図３０に示す画面例において、[グループＩＤ]リストボックスでは、登録者自身が所属するグループ１Ａを選択することが可能である。すなわち、表示する際に、グループ基本情報ＴＢＬ４１２１とメンバ情報ＴＢＬ４１３より、登録者が所属するグループ１Ａのリスト（グループＩＤ，グループ名称）を導出し、これを[グループＩＤ]リストボックスにロードする。
【０２４０】
同様に図３０に示す画面例において、[スレッドＩＤ]リストボックスでは、「新規」と、[グループＩＤ]リストボックスで選択されたグループ１Ａの既に登録されたスレッドＩＤを選択することができる。すなわち、[グループＩＤ]リストボックスを選択して、[登録情報取得]ボタンを押下すると、スレッド管理（利用者用）ＴＢＬ４１４（もしくはスレッド管理ＴＢＬ４３１でも可）から、選択されたグループ１Ａの登録済みスレッドのリスト（スレッドＩＤ，テーマ）を取得し、[スレッドＩＤ]リストボックスにロードする。
【０２４１】
同様に図３０に示す画面例において、スレッド種類には、「会議室，（連絡専用）掲示板」などを選択できるようにすることができる。例えば「（連絡専用）掲示板」を選択した場合には、連絡をする利用者１２（例えば、スレッドの管理者）のみが書き込めるように、書き込み制限をする。
【０２４２】
スレッドを新規に登録する場合は、利用者１２は、編集画面（図３０）中の[グループＩＤ]リストボックスで対象グループ１Ａを選択した後、[スレッドＩＤ]リストボックスで「新規」を選択し、[登録情報取得]ボタンを押下して、表示内容をリセットし、続いて他の項目を入力していく。
【０２４３】
編集を終えたら、利用者１２は編集画面（図３０）上の[登録]ボタンを押下する（＜４＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４１７２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０２４４】
次に、Ｓ４１７２において、コミュニティサーバ４０は、スレッド管理ＴＢＬ４３１を参照して、スレッドＩＤの空き番号を取得し、受信した情報と一緒にスレッド管理ＴＢＬ４３１と電子会議室ＴＢＬ４３２とスレッド管理（利用者用）ＴＢＬ４１４に記録する。ここで、スレッド管理（利用者用）ＴＢＬ４１４には、選択したグループ１Ａに所属するメンバ全員分について記録が必要である。
【０２４５】
最後に、コミュニティサーバ４０は登録完了メッセージを利用者端末５０に送信し、利用者端末５０の画面に登録完了メッセージを表示させる（＜５＞）。
【０２４６】
スレッドの情報を変更する場合は、変更を希望する利用者１２は編集画面（図３０）上の[グループＩＤ]リストボックスで対象グループ１Ａを選択した後、[登録情報取得]ボタンを押下して、表示内容（[スレッドＩＤ]リストボックス）を更新する。[スレッドＩＤ]リストボックスで、変更しようとするスレッドＩＤを選択し、[登録情報取得]ボタンを押下して、表示内容を更新する。このとき、コミュニティサーバ４０は、スレッド管理ＴＢＬ４３１からスレッド情報を取得し、利用者端末５０の表示内容を更新させる。続いて他の項目を修正入力していく。
【０２４７】
編集を終えたら、利用者１２は編集画面中の[登録]ボタンを押下する（＜４＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４１７２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０２４８】
次に、Ｓ４１７２において、コミュニティサーバ４０は、受信した情報を基にスレッド管理ＴＢＬ４３１を更新する。
【０２４９】
最後に、コミュニティサーバ４０は登録完了メッセージを利用者端末５０に送信し、画面に表示させる（＜５＞）。
【０２５０】
スレッドを削除する場合は、Ｓ４１７１において、利用者１２は編集画面（図３０）上の「グループＩＤ」リストボックスと[スレッドＩＤ]リストボックスで、削除対象となるスレッドＩＤを選択し、「削除」チェックボックスをチェックして、[登録]ボタンを押下する（＜４＞）。Ｓ４１７２において、削除情報を受け取ったコミュニティサーバ４０は、スレッドが削除されることによって影響を受けるすべてのＴＢＬ上のレコードについて、削除フラグをＯＮに更新し、削除日を記録する。具体的には、スレッド管理ＴＢＬ４３１と電子会議室ＴＢＬ４３２とスレッド管理（利用者用）ＴＢＬ４１４等である。さらに、削除日からの経過日数を基準に、バッチ処理で物理的にレコードを削除すれば良い。
【０２５１】
最後に、登録完了メッセージを利用者端末５０の画面に表示させる（＜５＞）。
【０２５２】
以上で、利用者関係各種登録Ｓ４１の一例の説明を終了する。
【０２５３】
［３．４．２．会員関係各種登録Ｓ４２］
次に、図６に戻り、本発明システムの主な動作の一つである、会員関係各種登録Ｓ４２について説明する。  
会員関係各種登録Ｓ４２は、会員関係の各種登録を行うことを目的とするプロセスである。図３１は図６の会員関係各種登録Ｓ４２を展開した図で、会員登録（新規）Ｓ４２１と会員登録（変更・削除）Ｓ４２２の２つのプロセスから構成されることを示している。以下、該２つのプロセスについて順に説明する。
【０２５４】
［３．４．２．１．会員登録（新規）Ｓ４２１］
会員登録（新規）Ｓ４２１は、会員１３が自身に関する情報を入力し、本ビジネスモデルに会員として登録することを目的とするプロセスである。
【０２５５】
システム的には、会員１３（正確には、この時点ではまだ会員ではない。）が、会員端末６０を通して、自身に関する情報を編集・入力し、会員情報ＴＢＬ４２１に新規に記録する処理を行う。より詳細には、図３２のＤＦＤに示すような処理フローで実現することができる。以下、図３２を参照しながら会員登録（新規）Ｓ４２１の一例を説明する。
【０２５６】
会員登録（新規）Ｓ４２１が開始されると、まず、Ｓ４２１１において、コミュニティサーバ４０は、会員端末６０に会員登録画面を表示させる（＜１＞）。図３３に、会員端末６０に表示される会員登録画面の一例を示す。
【０２５７】
会員１３は、会員端末６０に表示される該画面（図３３）を通して、自身に関する情報を編集・入力し、[登録]ボタンを押下する（＜２＞）。すると、入力情報が、会員端末６０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４２１２に遷移する。問題のある場合には、会員端末６０にエラーメッセージを返信し、正しい入力を促す。
【０２５８】
次に、Ｓ４２１２において、コミュニティサーバ４０は、会員情報ＴＢＬ４２１を参照して会員ＩＤの空き番号を取得し、これを会員ＩＤとすると同時に、更にパスワードの自動生成を行った後、受信した情報と一緒に会員情報ＴＢＬ４２１に記録する。また、パスワードは、この段階では自動生成でも良いが、その場合は、会員１３は初回ログイン時にパスワードを変更することが望ましい。
【０２５９】
最後に、Ｓ４２１２において、コミュニティサーバ４０は登録完了メッセージを会員端末６０に送信し、画面に表示させる（＜３＞）。図３４は、登録完了メッセージ画面の一例である。自動取得した会員ＩＤとパスワードが表示されている。ここで[ＯＫ]ボタンをクリックすると、すぐにログインする仕様にしても良い。
【０２６０】
なお、マーケティング情報利用料等の徴収や、決済代行した際の商品代金の振込先に使用される銀行口座番号については、図３３の画面からは入力しないほうが良い。別途、紙の申込書（要登録印等）を郵送で受け取り、主催者側で登録することが好ましい。
【０２６１】
会員１３は、会員登録（新規）Ｓ４２１を済ませると、好きなときに本発明システムにログインできるようになる。図３５は、会員登録（新規）Ｓ４２１を済ませることによって使用できるようになるログイン処理（会員ログインＳ４９）の一例を示すＤＦＤである。以下、図３５を参照しながら会員ログインＳ４９の具体例を説明する。
【０２６２】
会員ログインＳ４９が開始されると、まず、Ｓ４９１において、コミュニティサーバ４０は会員端末６０にログイン画面を表示させる（＜１＞）。ログイン画面の例は割愛するが、図１２に示す画面とほぼ同様の画面とすることができる。会員１３は、会員端末６０に表示されるログイン画面を通して、ログイン情報（会員ＩＤ、パスワード）を入力し、[ログイン]ボタンを押下する（＜２＞）。すると、入力情報が、会員端末６０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した会員ＩＤを用いて、会員情報ＴＢＬ４２１に記録されているパスワードを参照し、受信したパスワードと照合する。一致する場合は、ログイン認証が成功したことになり、コミュニティサーバ４０は、端末を特定できるように処理する。具体的には、例えば、端末にＷＥＢブラウザを用いる場合は、コミュニティサーバ４０は、セッションＩＤ（端末を特定するための情報）を発行し、会員端末６０に送信する。会員端末６０では、クッキーという仕組みを使い、該セッションＩＤを記憶する。同時に、コミュニティサーバ４０は、セッションＩＤと関連付けてセッションスコープ（各端末に割り当てられる記憶領域）を確保し、会員ＩＤと会員名称等の基本情報を記憶する。次に、コミュニティサーバ４０は、実行プロセスをＳ４９２に遷移する。
【０２６３】
Ｓ４９２において、コミュニティサーバ４０は、会員端末６０にメニュー画面を表示させる（＜３＞）。図３６はメニュー画面の一例である。
【０２６４】
会員１３は、会員ログインＳ４９を終えると、会員ログイン認証が必要となる会員向けサービス（例えば、「マーケティング情報検索」、「広告配信」など）を利用できる状態になる。
【０２６５】
付け加えておくと、会員ログイン認証プロセスＳ４９１は、上述したようなパスワード認証方式に限定されない。バイオメトリクス（生体）認証方式等を利用することも可能である。
【０２６６】
［３．４．２．２．会員登録（変更・削除）Ｓ４２２］
会員登録（変更・削除）Ｓ４２２は、会員１３が、自身の会員情報を変更する、もしくは、本ビジネスモデルを脱退する場合に自身の利用者情報を削除することを目的とするプロセスである。
【０２６７】
システム的には、会員１３が、会員端末６０を通して、現在の会員登録情報を取得し、これを修正し、会員情報ＴＢＬ４２１等の該当レコードを更新もしくは削除する処理を行う。より詳細には、図３７のＤＦＤに示すような処理フローで実現することができる。以下、図３７を参照しながら会員登録（変更・削除）Ｓ４２２の一例について説明する。
【０２６８】
Ｓ４９において、会員１３は本発明システムにログイン（＜１＞）し、会員メニュー画面（図３６）において、[会員登録（変更・削除）]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４２２１に遷移する。次に、Ｓ４２２１において、コミュニティサーバ４０は、会員情報ＴＢＬ４２１から現在の登録情報を取得し、編集画面を会員端末６０に表示させる（＜３＞）。図３８は、編集画面（会員登録（変更・削除）画面）の一例である。
【０２６９】
会員の登録情報を変更する場合は、Ｓ４２２１において、会員１３は、会員端末６０に表示される該画面（図３８）を通して、自身（会員１３）に関する情報を修正編集・入力し、[登録]ボタンを押下する（＜４＞）。すると、入力情報が、会員端末６０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４２２２に遷移する。問題のある場合には、会員端末６０にエラーメッセージを返信し、正しい入力を促す。
【０２７０】
次に、Ｓ４２２２において、コミュニティサーバ４０は、受信した情報を基に会員情報ＴＢＬ４２１を更新する。
【０２７１】
最後に、コミュニティサーバ４０は登録完了メッセージを会員端末６０に送信し、会員端末６０の画面に表示させる（＜５＞）。本明細書では、該登録完了メッセージの画面例を割愛しているが、図３４に示す画面例を参考にすることができる。
【０２７２】
会員の登録情報を削除する場合は、Ｓ４２２１において、会員登録（変更・削除）画面（図３８）上の[削除]チェックボックスをチェックして、[登録]ボタンを押下する（＜４＞）。Ｓ４２２２において、削除情報を受け取ったコミュニティサーバ４０は、会員情報ＴＢＬ４２１とスレッド管理（会員用）ＴＢＬ４２３と会員ＨＰコンテンツＴＢＬ４２４の関連するレコードの削除フラグをＯＮに更新し、削除日を記録する。さらに、削除日からの経過日数を基準に、バッチ処理で物理的にレコードを削除すれば良い。
【０２７３】
会員アクセス権限管理ＴＢＬ４２２の関連するレコードも、このときに削除フラグをＯＮにしても良いが、有効期限で自動的に削除される仕様となっている場合は、特に削除する必要はない。
【０２７４】
最後に、登録完了メッセージを会員端末６０に送信し、会員端末６０の画面に表示させる（＜５＞）。
【０２７５】
また、図３８に示す画面例では、[パスワード変更]ボタンを用意しているが、これを押下した場合は、会員端末６０にパスワード変更（会員用）画面が表示され、これを用いてパスワードを変更することができる。パスワード変更（会員用）画面は、図１６を参考にすることができる。
【０２７６】
最後に、会員１３に会員登録料を請求する場合は、コミュニティサーバ４０は、会員情報ＴＢＬ４２１に基づいて月次処理で料金計算することができる。さらに計算結果を、収益ＴＢＬ４５４に記録しておく。
【０２７７】
以上で、会員関係各種登録Ｓ４２の一例の説明を終了する。
【０２７８】
［３．４．３．会員アクセス権限生成Ｓ４３］
次に、図６に戻り、本発明システムの主要な動作の一つである、会員アクセス権限生成Ｓ４３について説明する。  
会員アクセス権限生成Ｓ４３は、会員１３がグループ１Ａに対して提供されるコミュニティサービス（電子会議室やチャット等）に参加するために必要なアクセス権限を生成することを目的とするプロセスである。本実施の形態においては、広告の配信権を生成する使用としているが、交渉の前に広告を配信しない仕様とする場合は、交渉権を生成する仕様としても良い。
【０２７９】
図３９は、図６の会員アクセス権限生成Ｓ４３を展開した図である。本実施の形態において、会員アクセス権限生成Ｓ４３は、会員１３が利用するプロセスである広告配信権購入Ｓ４３１と、利用者１２が利用するプロセスである広告配信権付与Ｓ４３２の２つのプロセスにより構成される。広告配信権購入Ｓ４３１は、前記仕組みＡ（アウトバウンド型営業を支援する仕組み）で使用されるアクセス権限生成手段であり、広告配信権付与Ｓ４３２は、前記仕組みＢ（インバウンド型営業を支援する仕組み）で使用されるアクセス権限生成手段である。これらのプロセスは、互いに補完する関係にはなく、独立して存在できるため、どちらか一方のプロセスだけでもビジネスモデルは成立する。  
以下、該２つのプロセスについて順に説明する。
【０２８０】
［３．４．３．１．広告配信権購入Ｓ４３１］
まず、広告配信権購入Ｓ４３１について説明する。このプロセスは、会員１３がグループ１Ａに対する広告の配信権を購入するときに使用されるプロセスである。ここで、広告配信権とは、会員１３がグループ１Ａ（正確には、グループ１Ａに所属する利用者１２）に対して、広告を送付することができる権利である。本実施の形態では、会員１３が広告配信権を購入したいと思うグループ１Ａを探し出す方法として、マーケティング情報検索システムを使用する構成としているが、方法はこれに限定されない。予め条件を登録しておき、利用者１２がマーケティング情報を更新する都度、登録条件と照合し、合致する場合には、そのグループ情報を各会員１３に配信するような方法でも良いし、グループ１Ａが公開しているＨＰやブログを閲覧して探す方法でも良い。
【０２８１】
システム的には、会員１３が、グループ１Ａに対する広告配信権の購入を決めたとき、会員１３は、会員端末６０を通して、広告配信権を購入したいグループ１Ａを選択し、会員アクセス権限管理ＴＢＬ４２２に広告配信権のレコードを記録する処理を行う。より詳細には、図４０のＤＦＤに示すような処理フローで広告配信権購入Ｓ４３１を実現することができる。以下、図４０を参照しながら、広告配信権購入Ｓ４３１の一例について説明する。
【０２８２】
Ｓ４９において、会員１３は本発明システムにログイン（＜１＞）し、会員メニュー画面（図３６）において、[マーケティング情報検索]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４３１１に遷移する。次に、Ｓ４３１１において、コミュニティサーバ４０は、マーケティング情報検索画面を会員端末６０に表示させる（＜３＞）。図４１は、マーケティング情報検索画面の一例である。
【０２８３】
図４１に示す画面例において、上段部は検索条件入力部の一例である。ここで、[分野]リストボックスでは、グループ登録（新規・変更・削除画面（図１８））で入力する興味のある分野を選択することができるようにしても良い。また、検索条件の入力項目等の画面設計は、マーケティング情報の内容や使い勝手等を考慮して、自由に設計することができる。
【０２８４】
次に、Ｓ４３１１において、会員１３は、会員端末６０に表示されるマーケティング情報検索画面（図４１）を通して、グループ１Ａのマーケティング情報を検索するために、検索条件を入力し、[検索]ボタンを押下する（＜４＞）。すると、入力情報が、会員端末６０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、グループ情報ＴＢＬ４１２（４１２１，４１２２，４１２３）から検索条件に合致するグループ１Ａのリストを抽出し、検索結果として抽出したグループ１Ａのリストを会員端末６０に返信する（＜５＞）。問題のある場合には、会員端末６０にエラーメッセージを返信し、正しい入力を促す。
【０２８５】
図４１に示す画面例において、下段部は検索結果表示部の一例である。ここで、[詳細]ボタンを押下すると、図４２に示すような詳細情報表示画面が会員端末６０に表示され、会員１３はマーケティング情報に関する詳細情報を得ることができる。図４１において、提案依頼情報についてキーワード＝「セブ島」で検索しているため、図４２には、図２３で入力された内容等が表示されている。
【０２８６】
次に、Ｓ４３１１において、検索結果を受け取った会員１３は、会員端末６０に表示されているマーケティング情報検索画面（図４１）の下段部（検索結果表示部）において、広告配信権を購入しようとするグループ１Ａのチェックボックスをチェック入力し、[広告配信権購入]ボタンを押下する（＜６＞）。すると、入力情報が、会員端末６０からコミュニティサーバ４０に送信される。続いて、入力情報を受信したコミュニティサーバ４０は、実行プロセスをＳ４３１２に遷移する。Ｓ４３１２において、コミュニティサーバ４０は、受信したチェック入力情報を基に広告配信権のレコードを会員アクセス権限管理ＴＢＬ４２２に記録する。
【０２８７】
最後に、コミュニティサーバ４０は購入完了メッセージを会員端末６０に送信し、画面に表示させる（＜７＞）。
【０２８８】
なお、本発明システムにおいて、会員１３にマーケティング情報利用料を請求する場合は、会員情報ＴＢＬ４２１を基に、毎月、定額を徴収することもできるし、グループ１Ａの詳細情報を閲覧する毎に料金を徴収する場合は、図４１に示す画面例において、詳細ボタンを押下する都度、課金しても良い。
【０２８９】
また、会員１３に広告配信権の購入代金を請求する場合は、会員アクセス権限管理ＴＢＬ４２２に基づいて月次処理で料金計算することができる。例えば、広告配信権１件あたりの単価に購入件数を乗算する方法がある。
【０２９０】
課金額・購入代金額については、コミュニティサーバ４０が、随時、収益ＴＢＬ４５４に記録しておき、別途請求書を出力する、或いは図示していない決済システム（銀行決済システム、クレジットカード決済システム等）に請求情報を送信することにより、課金情報に応じた請求を会員１３に行うことができるようにしても良い。
【０２９１】
［３．４．３．２．広告配信権付与Ｓ４３２］
次に、広告配信権付与Ｓ４３２について説明する。広告配信権付与Ｓ４３２は、利用者１２が興味のある商品をＨＰ等で見つけて、該ＨＰの所有者（会員１３）との交渉を希望する時、該ＨＰの所有者である会員１３に広告配信権を付与することを目的とするプロセスである。
【０２９２】
システム的には、利用者１２が興味のある商品をＨＰ等で見つけて、該ＨＰの所有者（会員１３）と交渉したいと考えたとき、利用者１２により、利用者端末５０を通して入力された広告配信権を付与したい会員１３の会員ＩＤと（自身が所属する）グループ１ＡのグループＩＤを基に、会員アクセス権限管理ＴＢＬ４２２に広告配信権のレコードを記録する処理を行う。より詳細には、図４３のＤＦＤに示すような処理フローで実現することができる。以下、図４３を参照しながら、広告配信権付与Ｓ４３２の一例を説明する。
【０２９３】
Ｓ４８において、利用者１２は本発明システムにログイン（＜１＞）し、利用者メニュー画面（図１３）において、[ショッピングモール]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４３２１に遷移し、ショッピングモール画面を利用者端末５０に表示させる（＜３＞）。図４４は、ＨＰ閲覧Ｓ４３２１において利用者端末５０に表示されるショッピングモール画面の一例である。
【０２９４】
利用者１２は、利用者端末５０に表示されるショッピングモール画面を通して、商品を探索する（＜４＞）。その結果、目的の商品が掲載されているＨＰを探し当てる（＜５＞）。図４５は、目的の商品が掲載されているＨＰの一例である。
【０２９５】
次に、Ｓ４３２１において、利用者１２は、興味のある商品を見つけて、会員１３と交渉したいと考えたとき、図４５に示す画面において、[交渉希望]ボタンを押下する（＜６＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、実行プロセスをＳ４３２２に遷移し、広告配信権付与画面を利用者端末５０に表示する（＜７＞）。図４６は、広告配信権付与画面の一例である。
【０２９６】
図４６に示す画面おいて、[交渉希望グループ]リストボックスでは、広告配信権の付与者である利用者１２の所属するグループ１Ａを選択することができる。すなわち、画面表示の際に、グループ基本情報ＴＢＬ４１２１とメンバ情報ＴＢＬ４１３から、広告配信権の付与者である利用者１２が所属するグループ１Ａのリスト（グループＩＤ，グループ名）を導出し、これを[交渉希望グループ]リストボックスにロードする。ここで、広告配信権の付与者とは、該画面（図４６）を使用して広告配信権を会員１３に付与する登録を行う利用者１２である。
【０２９７】
続いて、Ｓ４３２２において、利用者１２は広告配信権付与画面（図４６）上のその他の入力項目を入力し、[広告配信権付与]ボタンを押下する（＜８＞）と、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４３２３に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０２９８】
Ｓ４３２３において、コミュニティサーバ４０は、受信した入力情報を基に広告配信権を会員アクセス権限管理ＴＢＬ４２２に記録する。
【０２９９】
最後に、コミュニティサーバ４０は広告配信権付与完了メッセージを利用者端末５０に送信し、画面に表示させる（＜９＞）。図４７は、広告配信権付与完了画面の一例である。
【０３００】
本実施の形態では、利用者１２が興味のある商品を見つける方法として、ＨＰ閲覧を行う構成としているが、広告配信権付与Ｓ４３２を実現する方法はこれに限定されない。例えば、商品カタログや雑誌等でも良い。ただし、この場合は、売り手である会員１３が会員登録を済ませている必要があり、また、利用者１２は、売り手である会員１３の会員ＩＤを取得できなければならない。
【０３０１】
以上が、会員アクセス権限生成Ｓ４３を構成する２つのプロセスに関する説明である。これらに加えて、次に説明するような変形例が考えられる。
【０３０２】
［３．４．３．３．広告配信権付与Ｓ４３２の変形例１］
図４８は、広告配信権付与Ｓ４３２の変形例１のＤＦＤである。この変形例は、利用者１２が、本発明システムにログインする前にＨＰを閲覧し、興味のある商品を探し出し、ＨＰの所有者である会員１３との交渉を希望し、該会員１３に交渉権を付与する場合の処理である。
【０３０３】
利用者１２は、Ｓ４３２１において、興味のある商品を探し出し、図４５に示す様な会員１３の所有するＨＰ画面において[交渉希望]ボタンを押下する（＜１＞＜２＞＜３＞＜４＞）。すると、コミュニティサーバ４０は、該情報を受信し、まず、該利用者１２がログインしていないことを確認する。次に、実行プロセスを利用者ログイン認証Ｓ４８１に遷移し、利用者端末５０にログイン画面（図１２）を表示する（＜５＞）。利用者１２は、該画面にログイン情報を入力し、ログインする（＜６＞）。コミュニティサーバ４０は、利用者ログイン認証Ｓ４８１処理を終えると、利用者端末５０に利用者メニュー画面（図１３）を表示させることなく、実行プロセスを編集Ｓ４３２２に遷移し、利用者端末５０に広告配信権付与画面（図４６）を表示させる（＜７＞）。
【０３０４】
利用者１２は、利用者端末５０に表示される広告配信権付与画面（図４６）を通して、必要事項を編集・入力し、[広告配信権付与]ボタンを押下する（＜８＞）と、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４３２３に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０３０５】
続いてＳ４３２３において、コミュニティサーバ４０は、受信した入力情報を基に広告配信権を会員アクセス権限管理ＴＢＬ４２２に記録する。
【０３０６】
最後に、コミュニティサーバ４０は広告配信権付与完了メッセージを利用者端末５０に送信し、画面に表示させる（＜９＞）。
【０３０７】
［３．４．３．４．広告配信権付与Ｓ４３２の変形例２］
図４９は、広告配信権付与Ｓ４３２の変形例２のＤＦＤである。この例は、会員ＨＰコンテンツがコミュニティサーバ４０と異なるサーバ（会員ＨＰサーバ８０）に格納されている場合のプロセスである。この場合、会員ＨＰサーバ８０は、例えば、会員１３自身が所有するサーバでも良いし、レンタルサーバでも良い。また、会員ＨＰサーバ８０は、通信ネットワーク７０を介してコミュニティサーバ４０と利用者端末５０と会員端末６０と接続されており、通信インタフェースを介して互いにデータの送受信が可能な状態にある。
【０３０８】
利用者１２は、会員ＨＰサーバ８０からＨＰコンテンツを受信し、目的の商品を探す（＜１＞＜２＞）。このとき、利用者端末５０に表示される画面は、図４４や図４５と同様である。
【０３０９】
次に、[交渉希望]ボタンを押下する（＜３＞）。すると、会員ＨＰサーバ８０は、該情報を受信し、利用者端末５０に対して、コミュニティサーバ４０に格納されている広告配信権付与ＩＩ画面へのリダイレクト指示を与える。このとき、ＵＲＬ情報に付加するなどして、会員ＩＤを一緒に送信する（＜４＞）。
【０３１０】
次に、利用者端末５０は、該情報を受信し、コミュニティサーバ４０の広告配信権付与ＩＩ画面にリダイレクトする（＜５＞）。すると、コミュニティサーバ４０は、受信した会員ＩＤが会員情報ＴＢＬ４２１に存在することを確認し、利用者端末５０にログイン機能のある広告配信権付与ＩＩ画面（図５０）を表示させる（＜６＞）。  
図５０は、利用者端末５０に表示されるログイン機能のある広告配信権付与ＩＩ画面の一例を示す図である。該画面は、図４６にログイン機能を付加した画面である。
【０３１１】
図５０に示す画面例において、［交渉希望グループＩＤ］欄には、会員１３との交渉を希望するグループ１ＡのグループＩＤを入力する。  
また、［付与者の利用者ＩＤ］欄には、該画面（図５０）を使用して、会員１３に広告配信権を付与しようとする利用者１２の利用者ＩＤを入力する。  
また、［付与者のパスワード］欄には、該画面（図５０）を使用して、会員１３に広告配信権を付与しようとする利用者１２のログインパスワードを入力する。
【０３１２】
次に、Ｓ４３２２において、利用者１２は、利用者端末５０に表示される該画面（図５０）を通して、ログイン情報を含む各入力項目を入力し、[広告配信権付与]ボタンを押下する（＜７＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック、付与先としての会員ＩＤが会員情報ＴＢＬ４２１に存在していることを確認すると同時に、［交渉希望グループ］欄に入力されたグループＩＤがグループ基本情報ＴＢＬ４１２１に存在していることを確認し、さらに、付与者の利用者ＩＤが交渉希望グループ１Ａのメンバとして登録されていることをメンバ情報ＴＢＬ４１３により確認し、問題がなければ、実行プロセスをＳ４８１に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０３１３】
続いて、Ｓ４８１において、コミュニティサーバ４０は、受信した入力情報の内、ログイン情報（付与者の利用者ＩＤ，付与者のパスワード）を基にログイン認証を行う。ログイン認証に成功すると、コミュニティサーバ４０は、実行プロセスをＳ４３２３に遷移する。Ｓ４３２３において、コミュニティサーバ４０は、広告配信権を会員アクセス権限管理ＴＢＬ４２２に記録する。
【０３１４】
最後に、コミュニティサーバ４０は広告配信権付与完了メッセージを利用者端末５０に送信し、画面に表示させる（＜８＞）。
【０３１５】
［３．４．３．５．広告配信権付与Ｓ４３２の変形例３］
広告配信権付与Ｓ４３２の変形例３は、カタログや雑誌等で目的の商品を見つけた場合に使用する広告配信権付与方法である。図５１は、広告配信権付与Ｓ４３２の変形例３で使用される広告配信権付与ＩＩＩ画面の一例を示す図である。利用者１２は、目的の商品を見つけた場合に、付与先の会員ＩＤをカタログ等の紙面から取得し、該画面（図５１）に入力することで、会員に広告配信権を付与することができる。処理の詳細は説明しないが、利用者メニュー画面（図１３）上にリンクボタンを設置し、図４３のＳ４３２の処理を参考にして、実現することができる。
【０３１６】
［３．４．３．６．広告配信権購入Ｓ４３１の変形例］
また、広告配信権付与Ｓ４３２を応用して、広告配信権購入Ｓ４３１の変形例を実現することができる。このパターンは、図４５において、[交渉希望]ボタンを設置するのと同様に、グループ１Ａの所有するＨＰやブログに、[交渉権購入]ボタンを設置する方法である。会員１３が、グループ１ＡのＨＰやブログを参照して、セールス活動を行いたいと考えたとき、会員１３が該ボタンを押下すると、広告配信権を取得することができる。これについても、処理の詳細は説明しないが、他の広告配信権生成手段を参考にして、実現することができる。
【０３１７】
［３．４．４．広告配信Ｓ４４］
次に、図６に戻り、本発明システムの主な動作の一つである、広告配信Ｓ４４について説明する。
広告配信Ｓ４４は、会員１３がグループ１Ａに所属する利用者１２に対して広告を目的としたメール等を送付することを目的とするプロセスである。もちろん、該メールを送信するためには、前記会員アクセス権限生成Ｓ４３により広告配信権を取得していることが条件となる。
【０３１８】
システム的には、会員１３は、会員端末６０を通して、コミュニティサーバ４０に広告メールを送信し、コミュニティサーバ４０は、広告配信権があることをチェックし、利用者情報ＴＢＬ４１１とメンバ情報ＴＢＬ４１３から、広告配信対象となるグループ１Ａに所属する利用者１２のメールアドレスのリストを作成し、それらのメールアドレスに向けて広告メールを送信する処理である。利用者１２は、利用者端末５０のメールソフト（メーラー）等を通して、これらの広告メールを受信し、閲覧することができる。より詳細には、図５２のＤＦＤに示すような処理フローで実現することができる。以下、図５２を参照しながら広告配信Ｓ４４の一例を説明する。
【０３１９】
Ｓ４９において、会員１３は本発明システムにログイン（＜１＞）し、会員メニュー画面（図３６）において、[広告配信]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４４１に遷移する。次に、Ｓ４４１において、コミュニティサーバ４０は、会員アクセス権限管理ＴＢＬ４２２とグループ基本情報ＴＢＬ４１２１から広告配信可能なグループ１Ａのリストを抽出し、広告配信権一覧画面を会員端末６０に表示させる（＜３＞）。図５３は、広告配信権一覧画面の一例である。
【０３２０】
次に、会員１３は、会員端末６０に表示される広告配信権一覧画面（図５３）において、広告メールを送付しようとするグループ１Ａの[広告メール編集]ボタンを押下する（＜４＞）と、ボタン押下の情報が、会員端末６０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、未配信であることを確認して、実行プロセスをＳ４４２に遷移する。配信済の場合は、配信できない旨のメッセージを会員端末６０に返信する。
【０３２１】
Ｓ４４２において、コミュニティサーバ４０は、会員端末６０に、広告メール編集画面を表示させる（＜５＞）。図５４は、会員端末６０に表示される広告メール編集画面の一例である。ちなみに該画面例で採用したメールの内容は、アウトバウンド型営業で使用される広告メールの一例である。
【０３２２】
広告メール編集画面が表示されると、会員１３は、会員端末６０を通して、該画面を編集・入力し、[広告メール配信]ボタンを押下する（＜６＞）。すると、入力情報が、会員端末６０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェックおよびデータ量の適切性のチェック等を行った後、問題がなければ、実行プロセスをＳ４４３に遷移する。問題のある場合には、コミュニティサーバ４０は、会員端末６０にエラーメッセージを返信し、正しい入力を促す。
【０３２３】
Ｓ４４３において、コミュニティサーバ４０は、会員アクセス権限管理ＴＢＬ４２２を参照して、広告配信権があることと、未配信であることと、広告メールのデータ量が適切であることと、を再度確認した後に、実行プロセスをＳ４４４に遷移する。
【０３２４】
Ｓ４４４において、コミュニティサーバ４０は、利用者情報ＴＢＬ４１１とメンバ情報ＴＢＬ４１３から、広告配信対象となるグループ１Ａに所属する利用者のメールアドレスのリストを作成し、それらのメールアドレスに向けて広告メールを送信する（＜７＞）。図５５は、利用者１２が、利用者端末５０を通して受け取る受信メールの一例である。通常のメールソフトを使用して閲覧することができる。
【０３２５】
また、本実施の形態では、交渉を行うためのコミュニティサービスに電子会議室を採用しているため、コミュニティサーバ４０は、広告メールを送信するのと同時に、交渉を行うための電子会議室のスレッドを新しく設置する処理として、スレッド管理ＴＢＬ４３１と電子会議室ＴＢＬ４３２とスレッド管理（利用者用）ＴＢＬ４１４とスレッド管理（会員用）ＴＢＬ４２３に、新しく設置したスレッドの情報を記録する。また、交渉権を会員アクセス権限管理ＴＢＬ４２２に記録する。
【０３２６】
最後に、コミュニティサーバ４０は広告配信完了メッセージを会員端末６０に送信し、画面に表示する（＜８＞）。
【０３２７】
また、参考として、図５６に、インバウンド型営業で使用される広告メールの一例を掲載した。
【０３２８】
本実施の形態では、グループ１Ａに所属する利用者１２全員に対して広告メールを送信する仕様としているが、広告メールの送信先は少なくとも1人以上であれば良い。
【０３２９】
また、Ｓ４４３で、利用者１２が利用者端末５０を通して広告メールを受信し、会員１３の提供する商品の購入を交渉なしに直ちに決めた場合には、メールに設置される受注画面へのリンクボタン（例：図５５中の「（注文画面）」の部分）により注文Ｓ４６に直ちに遷移することができる。
【０３３０】
また、本実施の形態においては、広告メールを送信する仕様としているが、方法はこれに限定されない。例えば、紙媒体による広告チラシを送付することも可能である。
【０３３１】
なお、該プロセス（広告配信Ｓ４４）は、本発明システムにおいて必須のプロセスではない。広告配信Ｓ４４を省略した場合は、会員アクセス権限生成Ｓ４３において、広告配信権ではなく、交渉権を直接生成し、会員アクセス権限管理ＴＢＬ４２２に記録し、同時に交渉を行うための電子会議室のスレッドを新しく設置する処理を行えば良い。
【０３３２】
また、本実施の形態においては、広告を配信すると同時に、電子会議室のスレッドを新しく設置し、交渉権を会員アクセス権限管理ＴＢＬ４２２に記録する処理を行っているが、変形例として、配信した広告中に［スレッド設置］ボタンを付けておき、閲覧した利用者１２が、広告の内容を検討して、売り手１３のセールス活動に興味を持ち、［スレッド設置］ボタンを押下した場合に、電子会議室のスレッドを新しく設置し、交渉権を会員アクセス権限管理ＴＢＬ４２２に記録する仕様とすることもできる。
【０３３３】
また、本実施の形態においては、電子会議室のスレッドを新しく設置する仕様としているが、必ずしも新しく設置する必要はなく、予め設置されているスレッドを使用してセールス活動を行う仕様としても良い。
【０３３４】
［３．４．５．交渉Ｓ４５］
次に、図６に戻り、本発明システムの主な動作の一つである、交渉Ｓ４５について説明する。
交渉Ｓ４５は、利用者１２と会員１３が、商品等について交渉を行うことを目的とするプロセスである。本実施の形態では、交渉のためのコミュニティサービス（コミュニケーションツール）として電子会議室を採用しているが、通信ネットワーク７０を介して利用者１２と会員１３が意思疎通可能なコミュニティサービス（コミュニケーションツール）であれば良く、例えばチャット、メーリングリスト、バーチャルコミュニティサービス等も利用可能である。
【０３３５】
本実施の形態においては、交渉Ｓ４５は、図５７に示す様に、利用者アクセスチェックＳ４５１、会員アクセスチェックＳ４５２，及び電子会議室Ｓ４５３、の３つのプロセスで構成される。
【０３３６】
利用者アクセスチェックＳ４５１は、利用者１２が、利用者端末５０を通して電子会議室に参加しようとするとき、参加可能であるかをチェックすることを目的とするプロセスである。
【０３３７】
会員アクセスチェックＳ４５２は、会員１３が、会員端末６０を通して電子会議室に参加しようとするとき、参加可能であるかをチェックすることを目的とするプロセスである。
【０３３８】
電子会議室Ｓ４５３は、Ｓ４５１とＳ４５２のプロセスで参加可能と判定された利用者１２と会員１３が電子会議室のスレッド上で交渉を行い、その結果、利用者１２が、商品の購入を決定し、注文Ｓ４６に遷移する機能を提供することを目的とするプロセスである。
【０３３９】
システム的には、利用者アクセスチェックＳ４５１において、利用者１２が、利用者端末５０を通して電子会議室のスレッドに参加しようとするとき、利用者１２自身が所属するグループ１Ａの電子会議室のスレッドであり、参加可であるかどうかをコミュニティサーバ４０がチェックし、参加可と判定された場合にのみ電子会議室Ｓ４５３に遷移し、該電子会議室のスレッドに対する参照と書き込みを許可する処理を行う。
【０３４０】
同時並行的に、会員アクセスチェックＳ４５２において、会員１３が、会員端末６０を通して交渉の場となる電子会議室のスレッドに参加しようとするとき、会員アクセス権限管理ＴＢＬ４２２を参照して、該電子会議室のスレッド（もしくは、該電子会議室のスレッドを所有するグループ１Ａ）に対して交渉権を持っているかどうかをコミュニティサーバ４０がチェックし、参加可と判定された場合にのみ電子会議室Ｓ４５３に遷移し、該電子会議室のスレッドに対する参照と書き込みを許可する処理を行う。
【０３４１】
最後に、電子会議室Ｓ４５３において、コミュニティサーバ４０は、利用者１２と会員１３に、それぞれの端末を通して電子会議室サービス（すなわち、前記電子会議室のスレッドに対する参照と書き込み）を提供する処理を行うとともに、利用者１２が商品の購入を決定した場合に、注文Ｓ４６に遷移する処理を行う。
より詳細には、それぞれ図５８、図６０、図６２に示すような処理フローで実現される。以下、該３つのプロセスについて順に説明する。
【０３４２】
［３．４．５．１．利用者アクセスチェックＳ４５１］
最初に図５８を参照しながら利用者アクセスチェックＳ４５１について説明する。図５８は、利用者アクセスチェックＳ４５１の一例を示すＤＦＤである。
【０３４３】
Ｓ４８において、利用者１２は本発明システムにログイン（＜１＞）し、利用者メニュー画面（図１３）において、[電子会議室]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４５１１に遷移する。次に、Ｓ４５１１において、コミュニティサーバ４０は、スレッド管理ＴＢＬ４３１とスレッド管理（利用者用）ＴＢＬ４１４とグループ基本情報ＴＢＬ４１２１から、当該利用者１２が参加可能な電子会議室のスレッドのリストを導出し、利用者端末５０の画面に、電子会議室スレッド一覧（利用者用）画面を表示させる（＜３＞）。図５９は電子会議室スレッド一覧（利用者用）画面の一例である。
【０３４４】
図５９に示す画面おいて、[交渉]ボタンは、利用者１２が交渉状態にあると認識している場合に使用されるボタンである。
[交渉]ボタンを押下すると、コミュニティサーバ４０によりスレッド管理ＴＢＬ４３１のステータスの属性が、通常状態から交渉状態に更新される。通常状態では、有効期限が来ると自動的に削除されるが、交渉状態になっていると、有効期限後も削除されない。逆に、[解除]ボタンを押下すると、交渉状態が解除され通常状態となる。
【０３４５】
また、同様に図５９に示す画面おいて、新着メッセージ（Ｍｓｇ）の有／無の判定は、スレッド管理ＴＢＬ４３１の最新意見Ｎｏと、スレッド管理（利用者用）ＴＢＬ４１４の参照済意見Ｎｏと、を比較して判定することができる。
【０３４６】
Ｓ４５１１において、利用者１２は、利用者端末５０に表示された電子会議室スレッド一覧（利用者用）画面（図５９）を通して、[スレッドＩＤ]ボタンを押下する（＜４＞）と、押下されたという情報が、利用者端末５０からコミュニティサーバ４０に送信される。次に、コミュニティサーバ４０は、実行プロセスをＳ４５１２に遷移する。
【０３４７】
次に、Ｓ４５１２において、コミュニティサーバ４０は、スレッド管理（利用者用）ＴＢＬ４１４を参照し、利用者１２自身が所属するグループ１Ａの電子会議室のスレッドであるかどうか等をチェックし、参加可と判定された場合にのみ、後述する電子会議室Ｓ４５３に遷移する。
【０３４８】
［３．４．５．２．会員アクセスチェックＳ４５２］
次に、図６０を参照しながら会員アクセスチェックＳ４５２について説明する。図６０は、会員アクセスチェックＳ４５２の一例を示すＤＦＤである。
【０３４９】
Ｓ４９において、会員１３は本発明システムにログイン（＜１＞）し、会員メニュー画面（図３６）において、[交渉]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４５２１に遷移する。次に、Ｓ４５２１において、コミュニティサーバ４０は、スレッド管理ＴＢＬ４３１とスレッド管理（会員用）ＴＢＬ４２３とグループ基本情報ＴＢＬ４１２１から、参加可能な電子会議室のスレッドのリストを導出し、会員端末６０の画面に、電子会議室スレッド一覧（会員用）画面を表示させる（＜３＞）。図６１は、電子会議室スレッド一覧（会員用）画面の一例である。
【０３５０】
次に、Ｓ４５２１において、会員１３は、会員端末６０に表示されている電子会議室スレッド一覧（会員用）画面（図６１）上の [スレッドＩＤ]ボタンを押下する（＜４＞）と、押下されたという情報が、会員端末６０からコミュニティサーバ４０に送信される。次に、コミュニティサーバ４０は、実行プロセスをＳ４５２２に遷移する。
【０３５１】
次に、Ｓ４５２２において、コミュニティサーバ４０は、会員アクセス権限管理ＴＢＬ４２２を参照し、前記会員１３が交渉権を持っている電子会議室のスレッドであるかどうかをチェックし、また、交渉権の有効期限内であるかをチェックし、参加可と判定された場合にのみ、電子会議室Ｓ４５３に遷移する。ここで、有効期限内ではない場合でも、スレッド管理ＴＢＬ４３１の「ステータス」属性が、交渉状態となっている場合は、参加可と判定される。
【０３５２】
［３．４．５．３．電子会議室Ｓ４５３］
最後に図６２を参照しながら電子会議室Ｓ４５３について説明する。図６２は電子会議室Ｓ４５３の一例を示すＤＦＤである。電子会議室Ｓ４５３において、コミュニティサーバ４０は、利用者端末５０に電子会議室画面（表示内容は、アクセスした電子会議室のスレッドの内容）を表示させる（５０＜１＞）。図６３は、電子会議室画面の一例である。
【０３５３】
利用者１２は、利用者端末５０に表示される電子会議室画面（図６３）を通して、アクセスした電子会議室のスレッドに対して参照と書き込みを繰り返す（５０＜２＞）。ここで、利用者端末５０より書き込みが行われたときには、コミュニティサーバ４０は、電子会議室ＴＢＬ４３２に記録すると同時に、スレッド管理ＴＢＬ４３１の「最新意見Ｎｏ」を更新する。また、利用者１２が[戻る]ボタンを押下する等して、電子会議室から退室する場合は、コミュニティサーバ４０は、スレッド管理（利用者用）ＴＢＬ４１４の「参照済意見Ｎｏ」をスレッド管理ＴＢＬ４３１の「最新意見Ｎｏ」の値に更新する。
【０３５４】
一方、これとは別に、電子会議室Ｓ４５３において、コミュニティサーバ４０は、会員端末６０に図６３に示す様な電子会議室画面（表示内容は、アクセスした電子会議室のスレッドの内容）を表示させる（６０＜１＞）。会員１３は、会員端末６０に表示される電子会議室画面（図６３）を通して、アクセスした電子会議室のスレッドに対して参照と書き込みを繰り返す（６０＜２＞）。ここで、書き込みが行われたときには、コミュニティサーバ４０は、電子会議室ＴＢＬ４３２に記録すると同時に、スレッド管理ＴＢＬ４３１の「最新意見Ｎｏ」を更新する。また、会員１３が[戻る]ボタンを押下する等して、電子会議室から退室する場合は、スレッド管理（会員用）ＴＢＬ４２３の「参照済意見Ｎｏ」をスレッド管理ＴＢＬ４３１の「最新意見Ｎｏ」の値に更新する。
【０３５５】
上記のように、利用者１２と会員１３の双方が、参照と書き込みを繰り返すことで、交渉を行う。その結果、利用者１２（グループ１Ａ）が、会員１３の提供する商品の購入を決定した場合（交渉成立）、利用者１２（グループ１Ａ）の代表もしくは各人が[注文画面]ボタンを押下する（５０＜３＞）。すると、コミュニティサーバ４０は、実行プロセスを注文Ｓ４６に遷移する（図６参照）。
【０３５６】
以上で、交渉Ｓ４５の一例の説明を終了する。
【０３５７】
［３．４．６．注文Ｓ４６］
次に、図６に戻り、本発明システムの主な動作の一つである、注文Ｓ４６について説明する。
注文Ｓ４６は、本発明システムを利用して、交渉成立に至った利用者１２と会員１３が、注文の内容を確定することを目的とするプロセスである。
【０３５８】
図６４は、注文Ｓ４６の一例を示すＤＦＤで、本実施の形態においては、注文Ｓ４６は、注文入力Ｓ４６１と値引き額入力Ｓ４６２の２つのプロセスから構成されることを示している。以下、該２つのプロセスについて順に説明する。
【０３５９】
［３．４．６．１．注文入力Ｓ４６１］
注文入力Ｓ４６１は、購入を決めた利用者１２が注文入力を行うことを目的とするプロセスである。システム的には、利用者１２は、利用者端末５０を通して、注文情報を入力し、注文ＴＢＬ４４１に注文内容を記録する処理である。より詳細には、図６５のＤＦＤに示すような処理フローで実現することができる。以下、図６５を参照しながら、注文入力Ｓ４６１の一例を説明する。
【０３６０】
購入を決めた利用者１２は、電子会議室画面（図６３）において[注文画面]ボタンを押下する。すると、コミュニティサーバ４０は、実行プロセスをＳ４６１１に遷移する。Ｓ４６１１において、コミュニティサーバ４０は、利用者端末５０に注文編集画面を表示させる（＜１＞）。このとき、注文編集画面のアドレスは、会員情報ＴＢＬ４２１上の「受注画面アドレス」属性から取得することも可能である。図６６および図６７は注文編集画面の一例である。
【０３６１】
図６７に示す注文編集画面２において、[ご請求先]リストボックスと[ご送付先]リストボックスでは、購入を決めた利用者１２が所属するグループ１Ａのメンバ（利用者１２）を選択することが可能である。すなわち、表示する際に、利用者情報ＴＢＬ４１１とメンバ情報ＴＢＬ４１３より、購入を決めた利用者１２が所属するグループ１Ａに所属するメンバのリスト（利用者ＩＤ、利用者氏名）を導出し、これを[ご請求先]リストボックスと[ご送付先]リストボックスにロードする。
【０３６２】
次に、Ｓ４６１１において、利用者１２は、図６６に示す注文編集画面１において、注文する商品と数量に関する情報を編集する。このとき、商品情報を受信したコミュニティサーバ４０は、商品ＴＢＬ４４３を基に、商品の在庫があることを確認する。注文編集画面１（図６６）の編集を終えたら、次に、[代金請求先指定]ボタンを押下する。すると、入力情報を受信したコミュニティサーバ４０は、利用者端末５０に注文編集画面２（図６７）を表示させる。次に、注文編集画面２（図６７）において、利用者１２は、代金の請求先と請求金額と商品の送付先と数量に関する情報を編集する。
【０３６３】
注文編集画面２（図６７）の編集を終えたら、該画面（図６７）上の[注文確認]ボタンを押下する（＜２＞）と、押下されたという情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０では、受信した注文情報について、フォーマットや値の有効性チェック等を行い、商品ＴＢＬ４４３を基に、再度、商品の在庫があることを確認し、請求先毎の金額の合計と全体の請求金額が一致すること等を確認した後に、問題がなければ、実行プロセスをＳ４６１２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０３６４】
Ｓ４６１２において、コミュニティサーバ４０は、注文確認画面を利用者端末５０に表示させる（＜３＞）。図６８は、注文確認画面の一例である。利用者１２は、注文確認画面（図６８）の[注文]ボタンを押下する（＜４＞）と、押下されたという情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、実行プロセスをＳ４６１３に遷移する。
【０３６５】
次に、Ｓ４６１３において、コミュニティサーバ４０は、商品ＴＢＬ４４３を基に、再度、商品の在庫があることを確認し、在庫がある場合は、受注内容を注文ＴＢＬ４４１に記録する。同時に、在庫数を減少させる。最後に、コミュニティサーバ４０は、利用者端末５０に受注完了メッセージを表示させる（＜５＞）。
【０３６６】
ここで、注文画面は、図６９に示すような注文見積書画面でも良い。ただし、この場合、会員１３は、電子会議室での交渉の中で、利用者１２の購入する商品と購入数量と請求先と送付先を聞き出し、注文見積書を作成しなければならない。注文見積書を作成する場合の処理については、図６５等を、画面については、図６６、図６７、図６８、等を参考にすることができる。
【０３６７】
また、購入を決めた利用者１２が、電子会議室画面（図６３）だけではなく、受信した広告メールに設置された注文画面へのリンクボタンを押下することによっても、該プロセス（注文入力Ｓ４６１）に遷移することができるようにしても良い。
【０３６８】
［３．４．６．２．値引き額入力Ｓ４６２］
注文Ｓ４６を構成するもう一つのプロセスである値引き額入力Ｓ４６２は、会員１３が利用者１２の入力した注文に対して、値引き額を入力することを目的とするプロセスである。システム的には、会員１３は、会員端末６０を通して、値引き情報を入力し、注文ＴＢＬ４４１上の注文レコードに値引き額を記録する処理である。より詳細には、図７０のＤＦＤに示すような処理フローで実現することができる。以下、図７０を参照しながら交渉値引き額入力Ｓ４６２の一例を説明する。
【０３６９】
Ｓ４９において、会員１３は本発明システムにログイン（＜１＞）し、会員メニュー画面（図３６）において、[受注一覧]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４６２１に遷移する。次に、Ｓ４６２１において、コミュニティサーバ４０は、受注一覧画面を会員端末６０に表示させる（＜３＞）。図７１は、受注一覧（会員用）画面の一例である。
【０３７０】
Ｓ４６２１において、会員１３は会員端末６０を通して、受注一覧（会員用）画面（図７１）上の値引きしようとする注文レコードの[値引き]ボタンを押下する（＜４＞）と、押下されたという情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、実行プロセスを、Ｓ４６２２に遷移し、会員端末６０に、値引き額入力画面を表示させる（＜５＞）。図７２は、値引き額入力画面の一例である。
【０３７１】
会員１３は、会員端末６０を通して、該値引き額入力画面（図７２）で値引き額を入力し、[登録]ボタンを押下する（＜６＞）と、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。ここで、商品受渡し状況が受渡済（決済済）となっている注文については、[値引き]ボタンを使用することはできない。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４６２３に遷移する。問題のある場合には、コミュニティサーバ４０は、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０３７２】
次に、Ｓ４６２３において、コミュニティサーバ４０は、受信した値引き額情報を注文ＴＢＬ４４１上の該当する注文レコードの「値引き額」属性に記録する。
【０３７３】
最後に、コミュニティサーバ４０は会員端末６０に更新後の受注一覧画面を送信し、画面に表示させる（＜７＞）。
【０３７４】
以上で、注文Ｓ４６の一例の説明を終了する。
【０３７５】
［３．４．７．受渡決済Ｓ４７］
次に、図６に戻り、本発明システムの主な動作の一つである、受渡決済Ｓ４７について説明する。
受渡決済Ｓ４７は、注文に対する会員１３の商品受渡し行為を管理することと、商品受渡しが完了した取引について、仲介手数料と利用者ポイントとグループポイントを計算し、取引実績を記録することを目的とするプロセスである。
【０３７６】
図７３は、図６の受渡決済Ｓ４７を展開した図で、本実施の形態において、受渡決済Ｓ４７は商品受渡管理Ｓ４７１と取引実績記録Ｓ４７２の２つのプロセスから構成されることを示している。以下、該２つのプロセスについて順に説明する。
【０３７７】
［３．４．７．１．商品受渡管理Ｓ４７１］
商品受渡管理Ｓ４７１は、注文に対する会員１３の商品受渡し行為を管理することを目的とするプロセスで、システム的には、会員１３は、金銭を銀行振込等で受け取り、続いて、商品の受渡しを完了したら、会員端末６０を通して、商品受渡し完了の入力を行い、コミュニティサーバ４０に、注文ＴＢＬ４４１の「商品受渡し状況」属性を「受渡済」に更新させる処理である。より詳細には、図７４のＤＦＤに示すような処理フローで実現することができる。以下、図７４を参照しながら商品受渡管理Ｓ４７１の一例を説明する。
【０３７８】
Ｓ４９において、会員１３は本発明システムにログイン（＜１＞）し、会員メニュー画面（図３６）において、[受注一覧]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４７１１に遷移する。次に、Ｓ４７１１において、コミュニティサーバ４０は、注文ＴＢＬ４４１から受注リストを抽出し、会員端末６０の画面に、抽出した受注リストに基づいて、図７１に示す受注一覧（会員用）画面を表示させる（＜３＞）。
【０３７９】
次に、Ｓ４７１１において、会員１３は、会員端末６０の受注一覧（会員用）画面（図７１）を通して、商品の受渡しの完了した注文について、チェックボックスにチェックを入力し、[商品受渡し完了]ボタンを押下する（＜４＞）。すると、入力情報が、会員端末６０からコミュニティサーバ４０に送信される。次に、入力情報を受信したコミュニティサーバ４０は、実行プロセスをＳ４７１２に遷移する。
【０３８０】
次に、Ｓ４７１２において、コミュニティサーバ４０は、注文ＴＢＬ４１１の「商品受渡し状況」属性を「受渡済」に更新する。
【０３８１】
最後に、コミュニティサーバ４０は、会員端末６０に、更新後の受注一覧（会員用）画面を表示させる（＜５＞）。該画面では、商品受渡状況の欄に「受渡済」と表示される。
【０３８２】
［３．４．７．２．取引実績記録Ｓ４７２］
取引実績記録Ｓ４７２は、商品の受渡しが完了した取引について、仲介手数料と利用者ポイントとグループポイントを計算し、取引実績を記録することを目的とするプロセスで、図７３のＤＦＤに示すような処理フローで実現することができる。
【０３８３】
取引実績記録Ｓ４７２において、コミュニティサーバ４０は、注文ＴＢＬ４４１から商品受渡しが完了している取引（「商品受渡し状況」属性が「受渡済」となっている注文）で、かつ、「決済状況」属性が「未決済」となっている注文レコードを抽出し、各レコード毎に、会員１３へ請求する仲介手数料と、購入者（利用者１２）へ付与するポイント（利用者ポイント）と、グループ１Ａへ付与するポイント（グループポイント）を計算する。計算方法は、取引額に一定の利率を乗算する方法等が考えられる。
【０３８４】
続いて、計算結果を含めて、取引実績ＴＢＬ４４２に取引実績を記録する。また、この時同時に、注文ＴＢＬ４４１の「決済状況」属性を「決済完了」に更新する。
また、このとき、同時に、仲介手数料を収益ＴＢＬ４５４に記録しておいても良い。
【０３８５】
また、主催者１１は注文ＴＢＬ４４１、もしくは、取引実績ＴＢＬ４４２を基に、決済代行業務を行うこともできる。具体的には、銀行口座からの引き落としにより、利用者１２から商品代金を回収し、商品代金から仲介手数料を差し引いた金額を、会員１３の銀行口座に振り込むこともできる。
【０３８６】
以上で、受渡決済Ｓ４７の一例の説明を終了する。
【０３８７】
［４．仕組みＣを実現する本発明システムの実施の形態］
次に、本発明システムで実現される仕組みの内、仕組みＣについて説明する。該仕組みＣは、前記仕組みＡおよび仕組みＢを実現するための本実施に係る本発明システムに追加される仕組みであり、前記した仕組みＡおよび仕組みＢを実現するための本実施に係る本発明システムを前提として記載される。
【０３８８】
［４．１．通話／通信料金割引処理Ｓ４Ａ］
仕組みＣは、グループサービスを利用して行われる通話・通信（同一グループに所属する利用者同士の通話・通信）において、蓄積されたポイントに応じてその料金を割引く仕組みであり、本実施の形態においては、「通話／通信料金割引処理Ｓ４Ａ」としている。
【０３８９】
通話／通信料金割引処理Ｓ４Ａを導入することで、利用者１２は、ポイントを取得できる活動（購買活動等）を活発に行えば行うほど、同一グループに所属する利用者同士の通話・通信費用を低減させることができるため、購買活動等のポイント取得活動に対するインセンティブを得ることができる。
【０３９０】
システム的には、取引実績ＴＢＬ４４２を基に割引率計算用グループポイントを算出し、その結果をグループ基本情報ＴＢＬ４１２１の「割引率計算用グループポイント」属性に記録する処理と、グループ基本情報ＴＢＬ４１２１に記録された割引率計算用グループポイントを基に通話・通信料を計算し、通話／通信料金計算結果ＴＢＬ４５１に記録する処理を行う。より詳細には、図７５のＤＦＤに示すような処理フローで実現することができる。以下、図７５を参照しながら通話／通信料金割引処理Ｓ４Ａの一例を説明する。
【０３９１】
まず、Ｓ４Ａ１において、コミュニティサーバ４０は、取引実績ＴＢＬ４４２を基に、バッチ処理で当月分のグループポイントをグループ毎に集計し、グループ基本情報ＴＢＬ４１２１の「割引率計算用グループポイント」に記録する。ここで、該割引率は、翌月もしくは当月の割引率計算に利用される。
【０３９２】
次に、通話・通信料金を計算する際に、Ｓ４Ａ２において、コミュニティサーバ４０は、メンバ情報ＴＢＬ４１３を基に、通話・通信を行う２人の利用者が所属しているグループ１Ａのリストを抽出する。次に、グループ基本情報ＴＢＬ４１２１から、先に抽出された１つ以上のグループ１Ａの「割引率計算用グループポイント」を集計する。さらに、集計ポイントに応じて、例えば図７６の表に従って、割引率を決定し、割引前の通話／通信料に該割引率を乗算して割引額を計算し、割引前の通話／通信料などとともに、通話／通信料金計算結果ＴＢＬ４５１に記録する。
【０３９３】
上記のようにポイントを集計してから割引率表を参照して計算する方法のほかに、割引率表を基に、先に各グループ１Ａの割引率を決定してから、それらを集計して最終的な割引率を決定する方法もある。
【０３９４】
最後に付け加えておくと、該処理（Ｓ４Ａ）を行うコンピュータハードウェアはコミュニティサーバ４０である必要は必ずしもなく、別途コンピュータハードウェアを用意しても良い。
【０３９５】
［５．仕組みＤを実現する本発明システムの実施の形態］
次に、本発明システムで実現される仕組みの内、仕組みＤについて説明する。該仕組みＤは、前記仕組みＣと同様、前記仕組みＡおよび仕組みＢを実現するための本実施に係る本発明システムに追加される仕組みであり、前記した仕組みＡおよび仕組みＢを実現するための本実施の形態に係る本発明システムを前提として記載される。
【０３９６】
［５．１．ユーザ管理Ｓ４Ｂ］
仕組みＤは、利用者１２が商品を購入した場合に、商品の製造元や会員１３等（以下「ユーザ管理者」とする）によるユーザ（顧客）の管理方法に関する仕組みであり、本実施の形態においては、「ユーザ管理Ｓ４Ｂ」としている。
【０３９７】
ユーザ登録を行う場合、現在は、郵送による登録もしくはインターネット上で登録することができる。しかし、登録後のサポートは、ホームページ（ＨＰ）や電子メールやダイレクトメール（ＤＭ）等により行われており、例えば、製造元のＨＰ上で、ユーザが所有する製品の情報を探すには若干の手間がかかるし、電子メールやＤＭによる案内については整理に手間がかかる。仕組みＤ（ユーザ管理Ｓ４Ｂ）は、上記の問題点を鑑みて考え出された仕組みであり、本発明システムのグループサービスを利用したユーザ登録およびユーザ管理（もしくは契約管理）の方法を提案するものである。
【０３９８】
図７７は、ユーザ管理Ｓ４Ｂを展開した図で、本実施の形態において、ユーザ管理Ｓ４Ｂは商品受渡日登録Ｓ４Ｂ１とユーザ登録Ｓ４Ｂ２の２つのプロセスから構成されることを示している。以下、該２つのプロセスについて順に説明する。
【０３９９】
［５．１．１．商品受渡日登録Ｓ４Ｂ１］
商品受渡日登録Ｓ４Ｂ１は、会員１３が、利用者１２に商品を受渡したときに、受渡日を登録することを目的とするプロセスである。この受渡日は、商品の製品修理保証期限を算出する際の基準日として利用される。
【０４００】
システム的には、会員１３は、商品の受渡しを完了したら、会員端末６０から商品受渡日の入力を行い、商品受渡日管理ＴＢＬ４５２に記録する処理を行う。より詳細には、図７８のＤＦＤに示すような処理フローで実現することができる。以下、図７８を参照しながら商品受渡日登録Ｓ４Ｂ１の一例を説明する。
【０４０１】
Ｓ４９において、会員１３は本発明システムにログイン（＜１＞）し、会員メニュー画面（図３６）において、[商品受渡日登録]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４Ｂ１１に遷移する。次に、Ｓ４Ｂ１１において、会員端末６０の画面に、編集画面（商品受渡日登録画面）を表示させる（＜３＞）。図７９は、商品受渡日登録画面の一例である。
【０４０２】
図７９に示す画面例において、商品受渡日（登録日）は、会員１３が該画面を使用して商品受渡日を登録する日付を自動取得すれば良い。
【０４０３】
次に、Ｓ４Ｂ１１において、会員１３は、会員端末６０の商品受渡日登録画面（図７９）を通して、商品ＩＤと受取人の利用者ＩＤを入力し、[登録]ボタンを押下する（＜４＞）。すると、入力情報が、会員端末６０からコミュニティサーバ４０に送信される。次に、入力情報を受信したコミュニティサーバ４０は、商品ＴＢＬ４４３を参照して、受信した商品ＩＤが存在していることを確認し、また、利用者情報ＴＢＬ４１１を参照して、受信した受取人の利用者ＩＤが存在していることを確認し、問題がなければ、実行プロセスをＳ４Ｂ１２に遷移する。問題のある場合には、会員端末６０にエラーメッセージを返信し、正しい入力を促す。
【０４０４】
次に、Ｓ４Ｂ１２において、コミュニティサーバ４０は、商品ＴＢＬ４４３を参照して、登録対象商品に関する情報を取得し、受信した情報と一緒に商品受渡日管理ＴＢＬ４５２に記録する。
【０４０５】
最後に、コミュニティサーバ４０は登録完了メッセージを会員端末６０に送信し、会員端末６０の画面に表示させる（＜５＞）。
【０４０６】
なお、付け加えておくと、商品受渡日登録Ｓ４Ｂ１を、商品受渡管理Ｓ４７１で一緒に処理しても良い。
【０４０７】
［５．１．２．ユーザ登録Ｓ４Ｂ２］
ユーザ登録Ｓ４Ｂ２は、利用者１２が、購入した商品のユーザ管理者（製造元等）からユーザサポートを受けるために、ユーザ登録を行うことを目的とするプロセスである。ただし、該プロセス（ユーザ登録Ｓ４Ｂ２）を実行するには、ユーザ管理者は、利用者１２として、予め以下の下準備をしておく必要がある。
グループ登録（新規・変更・削除）Ｓ４１３を利用して製品に関するグループ１Ａを設置する。
スレッド登録（新規・変更・削除）Ｓ４１７を利用して電子会議室のスレッドを設置しておく。
このとき、継続的な製品情報の提供を行うスレッド（スレッド種類：（連絡専用）掲示板）や、製品に関する議論をおこなうためのスレッド（スレッド種類：会議室）等、目的に合わせて、複数のスレッドを設置しておいても良い。
【０４０８】
図７７に戻って、ユーザ登録Ｓ４Ｂ２は、システム的には、利用者１２は、利用者端末５０からユーザ登録情報を入力し、ユーザ管理者が設置したグループ１Ａにメンバ登録すると同時に、ユーザ管理サーバ９０にユーザ登録情報を送信する処理を行う。より詳細には、図８０のＤＦＤに示すような処理フローで実現することができる。以下、図８０を参照しながらユーザ登録Ｓ４Ｂ２の一例を説明する。
【０４０９】
Ｓ４８において、利用者１２は本発明システムにログイン（＜１＞）し、利用者メニュー画面（図１３）において、[ユーザ登録]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４Ｂ２１に遷移する。次に、Ｓ４Ｂ２１において、コミュニティサーバ４０は、、前記利用者１２の利用者ＩＤを基に、商品受渡日管理ＴＢＬ４５２から、商品ＩＤと商品名と製造元名と商品受渡日と製造元のユーザ管理サーバ９０のＵＲＬ等を取得し、また、ユーザ登録画面ＴＢＬ４５３から商品ＩＤに対応する編集画面のイメージを取得し、さらに、グループ基本情報ＴＢＬ４１２１からグループ名等と利用者情報ＴＢＬから利用者名や住所等を取得し、編集画面を利用者端末５０に表示させる（＜３＞）。図８１は、編集画面（ユーザ登録画面）の一例である。
【０４１０】
図８１に示す画面例において、[情報取得]ボタンを押下すると、商品受渡日管理ＴＢＬ４５２に記録されている情報の内、該利用者１２に関連する情報が順番に取得され、表示される。
【０４１１】
次に、Ｓ４Ｂ２１において、利用者１２は、ユーザ登録画面（図８１）上で、必要な入力項目を入力した後、[登録]ボタンを押下する（＜４＞）。すると、入力情報が、利用者端末５０からコミュニティサーバ４０に送信される。コミュニティサーバ４０は、受信した入力情報について、フォーマットや値の有効性チェック等を行った後、問題がなければ、実行プロセスをＳ４Ｂ２２に遷移する。問題のある場合には、利用者端末５０にエラーメッセージを返信し、正しい入力を促す。
【０４１２】
次に、Ｓ４Ｂ２２において、コミュニティサーバ４０は、ユーザ管理サーバ９０にユーザ登録情報を送信する。
【０４１３】
ユーザ管理サーバ９０は、利用者１２がユーザ登録画面（図８１）上で入力したシリアルＮｏとパスワードによりユーザ認証を行う。すなわちユーザ管理サーバ９０はシリアルＮｏとパスワードを関連付けて管理していなくてはならない。ユーザ認証に成功した場合は、ユーザ管理サーバ９０は、データベースに受信したユーザ登録情報を記録し、ユーザ登録に成功した旨をコミュニティサーバ４０に返信する。
【０４１４】
次に、Ｓ４Ｂ２２において、コミュニティサーバ４０では、ユーザ管理者が設置したグループ１Ａにメンバ登録する（すなわち、メンバ情報ＴＢＬ４１３とスレッド管理（利用者用）ＴＢＬ４１４に必要な情報を記録する）。
【０４１５】
最後に、コミュニティサーバ４０は登録完了メッセージを利用者端末５０に送信し、画面に表示させる（＜５＞）。
【０４１６】
［６．仕組みＥを実現する本発明システムの実施の形態］
続いて、本発明システムで実現される仕組みの内、仕組みＥについて説明する。該仕組みＥは、前記仕組みＣおよび仕組みＤと同様、前記仕組みＡおよび仕組みＢを実現するための本実施に係る本発明システムに追加される仕組みであり、前記した仕組みＡおよび仕組みＢを実現するための本実施に係る本発明システムを前提として記載される。
【０４１７】
［６．１．交友関係のある利用者一覧作成Ｓ４Ｃ］
仕組みＥは、同一グループに所属するメンバ同士の交友関係の維持が容易となるように、交友関係のある利用者１２の連絡先情報リスト（住所録）を作成する仕組みであり、本実施の形態においては、「交友関係のある利用者一覧作成Ｓ４Ｃ」としている。
【０４１８】
より詳細には、図８２に示すＤＦＤのような処理フローで実現することができる。以下、図８２を参照しながら、交友関係のある利用者一覧作成Ｓ４Ｃの一例を説明する。
【０４１９】
Ｓ４８において、利用者１２は本発明システムにログイン（＜１＞）し、利用者メニュー画面（図１３）において、[交友関係のある利用者一覧]ボタンを押下する（＜２＞）と、コミュニティサーバ４０は、実行プロセスをＳ４Ｃ１に遷移し、交友関係のある利用者一覧画面を利用者端末５０に表示させる（＜３＞）。図８３は、交友関係のある利用者一覧画面の一例である。
【０４２０】
ここで、交友関係のある利用者一覧を抽出する処理は、例えば以下のようになる。
メンバ情報ＴＢＬ４１３から、自分が所属しているグループ１Ａのリスト（グループＩＤ）（以下「リストＡ」とする）を導出する。
リストＡとメンバ情報ＴＢＬ４１３から、導出されたリストＡのグループ１Ａに所属するメンバのリスト（利用者ＩＤ，グループＩＤ）（以下「リストＢ」とする）を作成する。
リストＢと利用者情報ＴＢＬ４１１とグループ基本情報ＴＢＬ４１２１から、コミュニティサーバ４０は利用者一覧リストを生成する。
【０４２１】
この仕組みＥを用いることで、利用者１２は、住所変更時や電話番号変更時に、友人全員に連絡する必要がなくなるメリットがある。また、ダウンロード機能を使用することで、携帯電話等の電話帳を更新することができるメリットがある。
【０４２２】
また、さらに応用例として、携帯電話に電話帳データを持たせることをせずに、サーバ上で管理することで、他人の携帯電話等を使用してログインし、電話帳を閲覧して、電話をかける、もしくは、メールをすることができる。このとき、通話・通信料金の請求は、ログイン者に対して行うような仕様にすることができる。
【０４２３】
また、通話・通信先を該リスト（交友関係のある利用者一覧）上のメンバ（すなわち、同一グループ１Ａに所属する利用者１２）に限定する機能を設置することで、利用者ＩＤとパスワードを盗まれても、悪用される危険性が減るメリットがある。また、ログインとは別の認証パスワードを用意して、グループ登録またはメンバ登録をしていない店や人物に対して通話することができるようにもできる。
【０４２４】
［７．仕組みＦを実現する本発明システムの実施の形態］
続いて、本発明システムで実現される仕組みの内、仕組みＦについて説明する。該仕組みＦは、前記仕組みＣおよび仕組みＤおよび仕組みＥと同様、前記仕組みＡおよび仕組みＢを実現するための本実施に係る本発明システムに追加される仕組みであり、前記した仕組みＡおよび仕組みＢを実現するための本実施に係る本発明システムを前提として記載される。
【０４２５】
［７．１．再投資額算出処理Ｓ４Ｄ］
仕組みＦは、本発明システムによって実現されるビジネスモデルを好循環させるために、会員１３または利用者１２から受け取る収益の一部を、コミュニティサービスの運営に再投資するための再投資額を算出する仕組みであり、本実施の形態においては、「再投資額算出処理Ｓ４Ｄ」としている。
【０４２６】
より詳細には、図８４に示すＤＦＤのような処理フローで実現することができる。以下、図８４を参照しながら、再投資額算出処理Ｓ４Ｄの一例を説明する。
【０４２７】
再投資額算出処理Ｓ４Ｄにおいて、収益ＴＢＬ４５４から一定期間（例えば１ヶ月）の収益を集計し、該集計値に対して、決められた利率を乗算し、算出された値を再投資額として、再投資額ＴＢＬ４５５に記録する。
【０４２８】
この仕組みＦを用いることで、収益の内、コミュニティサービスの拡充を含む運営に再投資する金額を算出し、主催者１１は、この金額の範囲内で、利用者１２に対するサービスを向上させ、図２に示したようなビジネスの好循環を実現することができる。
【図面の簡単な説明】
【０４２９】
【図１】本発明システムを利用することで実現されるビジネスモデルの概要を示す図
【図２】本発明により実現されるビジネスモデルの各サービスが循環してビジネスが発展していくことを示す図
【図３Ａ】本ビジネスモデルにおけるアウトバウンド型営業を支援する仕組みを説明する図、
【図３Ｂ】本ビジネスモデルにおけるインバウンド型営業を支援する仕組みを説明する図
【図４】本発明システムの概略構成を示すブロック図
【図５】コミュニティサーバのデータベース構成を概略的に示すブロック図
【図６】本発明システムの一実施形態のデータフロー図
【図７】利用者関係各種登録を展開したデータフロー図
【図８】利用者登録（新規）の一例を示す、データフロー図
【図９】利用者端末に表示される利用者登録画面の一例を示す図
【図１０】利用者端末に表示される登録完了メッセージ画面の一例を示す図
【図１１】ログイン処理の例を示すデータフロー図
【図１２】利用者端末に表示されるログイン画面の一例を示す図
【図１３】利用者端末に表示されるメニュー画面の一例を示す図
【図１４】利用者登録（変更・削除）の一例を示すデータフロー図
【図１５】利用者端末に表示される編集画面（利用者登録（変更・削除）画面）の一例を示す図
【図１６】利用者端末に表示されるパスワード変更（利用者用）画面の一例を示す図
【図１７】グループ登録（新規・変更・削除）の一例を示すデータフロー図
【図１８】利用者端末に表示される編集画面の一例を示す図
【図１９】利用者端末に表示される新規にグループ登録した場合の登録完了メッセージ画面の一例を示す図
【図２０】マーケティング情報登録（記念日）の一例を示すデータフロー図
【図２１】利用者端末に表示される編集画面（マーケティング情報登録（記念日）画面）の一例を示す図
【図２２】マーケティング情報登録（提案依頼）の具体例を示すデータフロー図
【図２３】利用者端末に表示される編集画面（マーケティング情報登録（提案依頼）画面）の一例を示す図
【図２４】メンバ登録の具体例を示すデータフロー図
【図２５】メンバ登録申請の一例を示すデータフロー図
【図２６】利用者端末に表示される編集画面（メンバ登録申請（新規・削除）画面）の一例を示す図
【図２７】メンバ承認の一例を示すデータフロー図
【図２８】利用者端末に表示される編集画面（メンバ承認画面）の一例を示す図
【図２９】スレッド登録（新規・変更・削除）の一例を示すデータフロー図
【図３０】利用者端末に表示される編集画面（スレッド登録（新規・変更・削除）画面）の一例を示す図
【図３１】会員関係各種登録を展開したデータフロー図
【図３２】会員登録（新規）の一例を示すデータフロー図
【図３３】会員端末に表示される会員登録画面の一例を示す図
【図３４】登録完了メッセージ画面の一例を示す図
【図３５】会員ログインの一例を示すデータフロー図
【図３６】会員端末に表示されるメニュー画面の例を示す図
【図３７】会員登録（変更・削除）の一例を示すデータフロー図
【図３８】会員端末に表示される編集画面（会員登録（変更・削除）画面）の一例を示す図
【図３９】会員アクセス権限生成の一例を示すデータフロー図
【図４０】広告配信権購入の一例を示すデータフロー図
【図４１】会員端末に表示される編集画面（マーケティング情報検索画面）の一例を示す図
【図４２】会員端末に表示される詳細情報表示画面の例を示す図
【図４３】広告配信権付与の一例を示すデータフロー図
【図４４】利用者端末に表示されるショッピングモール画面の一例を示す図
【図４５】利用者端末に表示される目的の商品が掲載されているＨＰ表示画面の例を示す図
【図４６】利用者端末に表示される広告配信権付与画面の一例を示す図
【図４７】利用者端末に表示される広告配信権付与完了画面の一例を示す図
【図４８】広告配信権付与の変形例１を示すデータフロー図
【図４９】広告配信権付与の変形例２を示すデータフロー図
【図５０】利用者端末に表示される広告配信権付与画面の一例を示す図
【図５１】利用者端末に表示される広告配信権付与の変形例３で使用される画面の例を示す図
【図５２】広告配信の一例を示すデータフロー図
【図５３】会員端末に表示される広告配信権一覧画面の一例を示す図
【図５４】会員端末に表示される広告メール編集画面の一例を示す図
【図５５】利用者端末を通して受け取る広告配信としての受信メールの一例を示す図
【図５６】インバウンド型営業で使用される広告メールの一例を示す図
【図５７】交渉の一例を示すデータフロー図
【図５８】利用者アクセスチェックの一例を示すデータフロー図
【図５９】利用者端末に表示される電子会議室スレッド一覧（利用者用）画面の一例を示す図
【図６０】会員アクセスチェックの一例を示すデータフロー図
【図６１】会員端末に表示される電子会議室スレッド一覧（会員用）画面の一例を示す図
【図６２】電子会議室の一例を示すデータフロー図
【図６３】利用者端末及び会員端末に表示される電子会議室画面の一例を示す図
【図６４】注文の一例を示すデータフロー図
【図６５】注文入力の一例を示すデータフロー図
【図６６】利用者端末に表示される注文編集画面の一例を示す図
【図６７】利用者端末に表示される注文編集画面の一例を示す図
【図６８】利用者端末に表示される注文確認画面の一例を示す図
【図６９】利用者端末及び会員端末に表示される注文見積書画面の一例を示す図
【図７０】交渉値引き額入力の一例を示すデータフロー図
【図７１】会員端末に表示される受注一覧（会員用）画面の一例を示す図
【図７２】会員端末に表示される値引き額入力画面の一例を示す図
【図７３】受渡決済の一例を示すデータフロー図
【図７４】商品受渡管理の一例を示すデータフロー図
【図７５】通話／通信料金割引処理の一例を示すデータフロー図
【図７６】集計ポイントと割引率の対応を示す表の一例を示す図
【図７７】ユーザ管理の一例を示すデータフロー図
【図７８】商品引渡日入力の一例を示すデータフロー図
【図７９】商品受渡日登録画面の一例を示す図
【図８０】ユーザ登録処理の一例を示すデータフロー図
【図８１】ユーザ登録画面の一例を示す図
【図８２】交友関係のある利用者一覧作成処理の一例を示すデータフロー図
【図８３】交友関係のある利用者一覧画面の一例を示す図
【図８４】再投資額算出処理の一例を示すデータフロー図
【符号の説明】
【０４３０】
４０      …  コミュニティサーバ
５０      …  利用者（買い手）端末
６０      …  会員（売り手）端末
７０      …  通信ネットワーク
８０      …  会員（売り手）ＨＰサーバ
９０      …  ユーザ管理サーバ
【図１】
2007157099.tif 000003
【図２】
2007157099.tif 000004
【図３Ａ】
2007157099.tif 000005
【図３Ｂ】
2007157099.tif 000006
【図４】
2007157099.tif 000007
【図５】
2007157099.tif 000008
【図６】
2007157099.tif 000009
【図７】
2007157099.tif 000010
【図８】
2007157099.tif 000011
【図９】
2007157099.tif 000012
【図１０】
2007157099.tif 000013
【図１１】
2007157099.tif 000014
【図１２】
2007157099.tif 000015
【図１３】
2007157099.tif 000016
【図１４】
2007157099.tif 000017
【図１５】
2007157099.tif 000018
【図１６】
2007157099.tif 000019
【図１７】
2007157099.tif 000020
【図１８】
2007157099.tif 000021
【図１９】
2007157099.tif 000022
【図２０】
2007157099.tif 000023
【図２１】
2007157099.tif 000024
【図２２】
2007157099.tif 000025
【図２３】
2007157099.tif 000026
【図２４】
2007157099.tif 000027
【図２５】
2007157099.tif 000028
【図２６】
2007157099.tif 000029
【図２７】
2007157099.tif 000030
【図２８】
2007157099.tif 000031
【図２９】
2007157099.tif 000032
【図３０】
2007157099.tif 000033
【図３１】
2007157099.tif 000034
【図３２】
2007157099.tif 000035
【図３３】
2007157099.tif 000036
【図３４】
2007157099.tif 000037
【図３５】
2007157099.tif 000038
【図３６】
2007157099.tif 000039
【図３７】
2007157099.tif 000040
【図３８】
2007157099.tif 000041
【図３９】
2007157099.tif 000042
【図４０】
2007157099.tif 000043
【図４１】
2007157099.tif 000044
【図４２】
2007157099.tif 000045
【図４３】
2007157099.tif 000046
【図４４】
2007157099.tif 000047
【図４５】
2007157099.tif 000048
【図４６】
2007157099.tif 000049
【図４７】
2007157099.tif 000050
【図４８】
2007157099.tif 000051
【図４９】
2007157099.tif 000052
【図５０】
2007157099.tif 000053
【図５１】
2007157099.tif 000054
【図５２】
2007157099.tif 000055
【図５３】
2007157099.tif 000056
【図５４】
2007157099.tif 000057
【図５５】
2007157099.tif 000058
【図５６】
2007157099.tif 000059
【図５７】
2007157099.tif 000060
【図５８】
2007157099.tif 000061
【図５９】
2007157099.tif 000062
【図６０】
2007157099.tif 000063
【図６１】
2007157099.tif 000064
【図６２】
2007157099.tif 000065
【図６３】
2007157099.tif 000066
【図６４】
2007157099.tif 000067
【図６５】
2007157099.tif 000068
【図６６】
2007157099.tif 000069
【図６７】
2007157099.tif 000070
【図６８】
2007157099.tif 000071
【図６９】
2007157099.tif 000072
【図７０】
2007157099.tif 000073
【図７１】
2007157099.tif 000074
【図７２】
2007157099.tif 000075
【図７３】
2007157099.tif 000076
【図７４】
2007157099.tif 000077
【図７５】
2007157099.tif 000078
【図７６】
2007157099.tif 000079
【図７７】
2007157099.tif 000080
【図７８】
2007157099.tif 000081
【図７９】
2007157099.tif 000082
【図８０】
2007157099.tif 000083
【図８１】
2007157099.tif 000084
【図８２】
2007157099.tif 000085
【図８３】
2007157099.tif 000086
【図８４】
2007157099.tif 000087