JP2015197720A - Ｓｎｓによるイベント参加費支払システム及びその支払方法 - Google Patents

Abstract

【課題】ＳＮＳと金融機関のシステムを連携させ、参加者のイベント参加費の支払を金融機関からの通知で確認する。【解決手段】ＳＮＳシステムは、イベントマスタとなるユーザから、イベント登録を受付け、イベントの参加者を募集する通知を参加候補者に送信し、イベントの参加者を受付ける。参加者は、イベントの参加費の支払方法に、銀行振込又はクレジットカードを選択でき、ＳＮＳは、その選択に基づいて、当該参加者に振込依頼又はカード決済依頼の支払依頼を送信する。金融機関のシステムは、この支払依頼に基づくイベント参加費の支払をインターネットのサイトから受け付ける。そして、ユーザが参加費の支払を実行すると、その支払情報を金融機関の公式シンボルと共にＳＮＳに送信する。ＳＮＳは、金融機関から公式シンボルと参加者がＳＮＳからの支払依頼に基づいた支払情報を受信したときに、参加者の参加費の支払確認をイベントマスタに送信する。【選択図】図１

Description

本発明は、イベント参加費支払システム及びその支払方法に関する。特に、イベント参加費の支払を金融機関から確認するイベント参加費支払システム及びその支払方法に関する。

従来から、宴会や会合等のイベントにおける幹事の仕事（会場の予約、参加者への連絡、集金、清算、会計報告等）をサポートするためのシステムが多数開示されている。例えば、特許文献１には、飲食店の検索を行い、結果を幹事端末に送信する飲食店情報検索手段と、飲食店と日時の候補の情報を登録する宴会情報登録手段と、飲食店と日時の候補の電子メールを参加者に対して送信する参加者送信手段と、参加者が選択した宴会の日時の情報と、飲食店の候補に対する客観的な評価の情報とを受信して加算する集計手段と、回答の締め切り後、幹事が決定した飲食店に対して宴会の予約の電子メールを送信する第１の予約手段と、決定した日時と飲食店の情報とを参加者に対して送信する決定送信手段と、を有する宴会予約支援システムが記載されている。

また、特許文献２には、インターネットを利用した会合の幹事業務支援システムにおいて、幹事が会合の会場となるホテルやレストランを決定した段階で、本発明のシステムを使用して、会合の日時・場所・参加対象者・会費などを定形のフォーマットに入力して、ホテルやレストランの端末から、会合情報掲載サーバにデータを送信する。そして、データを受信したサーバは、自動的にその会合を案内するホームページを立上げ、即座にどこからでもホームページが見られるようになり、会合情報を入手することができる。さらに、このホームページが見て、会合に参加しようと思った人は、ここから参加の申込や、会費の払込がインターネット経由でできるようになっている。

特開２００６−３２３８０５号公報 特開２００２−０９２２７１号公報

特許文献１に記載の宴会予約支援システムは、幹事が他の参加者に店舗、日時などを相談しながら、宴会や会合の幹事が店舗や日時の予約をすることを支援するものであるが、幹事にとって大きな負担となる会費の集金、清算、会計報告をサポートするものではない。また、特許文献２に記載の幹事業務支援システムは、参加者が参加の申し込みや会費の支払をインターネットのホームページを用いて行えるようにしたものであり、金融機関の預金口座を利用して集金を効率的に行えることを目指したものである。しかし、会費の支払方法は、クレジットカードに限られ、また、クレジットカード会社に対する決済要求を、会合の会場となるホテルやレストランに代わって行う専用の会合決済情報サーバを新たに構築する必要があった。

昨今では、宴会や会合等のイベントの呼びかけは、従来からの電子メールよりも、Ｆａｃｅｂｏｏｋ（登録商標）等のＳＮＳ（Social Networking Service)を利用していることが多くなってきた。ＳＮＳには、友達や知人やメンバがその属性と共に登録していることが多く、また、メンバ間の様々なコミュニケーション手段が用意されているので、幹事となったユーザがイベントの開催通知、参加確認、キャンセル時の処理等、多数の人間に一度に連絡をとったり個別に連絡をとったりすることが一貫して行えるので便利なためである。そのため、特許文献１や２のような専用システムは必要性が薄れてきている。しかしながら、ＳＮＳを利用しても、現状ではイベントの会費等の集金や支払の確認をすることまではできなかった。ＳＮＳと金融機関のシステムを結びつける手段が存在しないためである。そのため、イベントの集金、支払確認作業等は、いまでも多くの場合、幹事が手作業で行っているのが現状である。

したがって、本発明では、上記のような課題に鑑み、ＳＮＳと金融機関のシステムを連携させ、イベントの会費の支払を確認できるイベント参加費支払システムを提供することを目的とする。

上記課題を解決するため、本発明のイベント参加費支払システム及びイベント参加費支払方法は、以下のような解決手段を提供する。

本発明の第一の態様では、ＳＮＳシステムと、銀行システムと、前記ＳＮＳシステムのユーザでありイベントの主催者又は幹事であるユーザのイベントマスタ端末と、前記イベントの参加者である参加者端末とがネットワークで接続され、前記イベントの参加費の支払及び確認を行うイベント参加費支払システムであって、前記ＳＮＳシステムは、前記イベントマスタ端末から前記イベントの情報を受付け、イベント情報記憶手段に登録するイベント登録部と、前記イベントが登録されたときに、前記イベントの参加者を募集する通知を前記参加者端末に送信する参加者募集送信部と、前記募集の通知を受けた前記参加者端末から、前記イベントの参加者を受付ける参加者受付部と、前記参加者が前記イベントの参加費の支払方法に銀行振込を選択している場合に、当該参加者端末に振込依頼を送信する参加費支払依頼部と、前記銀行システムから、前記参加者が前記振込依頼に基づいた振込を行ったことを示す支払通知を前記銀行の公式シンボルと共に受信し、前記支払通知を前記イベントマスタ端末に送信する支払情報確認部とを備え、前記銀行システムは、前記振込依頼に基づく振込を受付ける振込受付部と、前記振込を実行する振込処理部と、前記振込の実行後、前記銀行の公式シンボルと共に前記参加者の支払情報を前記支払情報確認部に送信する支払情報送信部と、を備えることを特徴とする。

また、本発明の第二の態様では、ＳＮＳシステムと、クレジットカード会社のシステムと、前記ＳＮＳシステムのユーザでありイベントの主催者又は幹事であるユーザのイベントマスタ端末と、前記イベントの参加者である参加者端末とがネットワークで接続され、前記イベントの参加費の支払及び確認を行うイベント参加費支払システムであって、前記ＳＮＳシステムは、前記イベントマスタ端末から前記イベントの情報を受付け、イベント情報記憶手段に登録するイベント登録部と、前記イベントが登録されたときに、前記イベントの参加者を募集する通知を前記参加者端末に送信する参加者募集送信部と、前記募集の通知を受けた前記参加者端末から、前記イベントの参加者を受付ける参加者受付部と、前記参加者が前記イベントの参加費の支払方法にクレジットカードを選択している場合に、当該参加者端末にカード決済依頼を送信する参加費支払依頼部と、前記クレジットカード会社のシステムから、前記参加者が前記カード決済依頼に基づいた決済を行ったことを示す支払通知を前記クレジットカード会社の公式シンボルと共に受信し、前記支払通知を前記イベントマスタ端末に送信する支払情報確認部とを備え、前記クレジットカード会社のシステムは、前記イベントの会場の事業者が前記クレジットカードの加盟店であることを確認する加盟店情報確認部と、前記加盟店情報確認部からの依頼を受け、前記クレジットカードの利用を承認するオーソリ処理部と、前記クレジットカードの利用の承認後、前記クレジットカード会社の公式シンボルと共に前記参加者の支払情報を前記支払情報確認部に送信する支払情報送信部と、を備えることを特徴とする。

上記のイベント参加費支払システムにおいて、前記参加費支払依頼部は、前記イベントのＩＤ，前記参加者の前記ＳＮＳシステムのユーザＩＤ、前記参加者が指定した金融機関のインターネットサイトへのリンク情報、を含む参加費支払依頼を前記参加者端末に送信するように構成してもよい。

上記のイベント参加費支払システムにおいて、前記ＳＮＳシステムは、前記イベントの終了後の会計報告のために、前記支払情報の集計を行う支払情報集計部を備えるように構成してもよい。

上記のイベント参加費支払システムにおいて、前記イベントには、宴会、会合、寄付の募集、お祝金の贈答、宝くじの共同購入、団体が主催するイベントの料金徴収を含んでもよい。

本発明の第三の態様では、ＳＮＳシステムと、金融機関のシステムと、前記ＳＮＳシステムのユーザでありイベントの主催者又は幹事であるユーザのイベントマスタ端末と、前記イベントの参加者である参加者端末とがネットワークで接続され、前記イベントの参加費の支払及び確認を行うイベント参加費支払方法であって、前記ＳＮＳシステムにおいて、前記イベントマスタ端末から前記イベントの情報を受付け、イベント情報記憶手段に登録するステップと、前記イベントの登録後、前記イベントの参加者を募集する通知を前記参加者端末に送信するステップと、前記募集の通知を受けた前記参加者端末から、前記イベントの参加者を受付けるステップと、前記参加者が前記イベントの参加費の支払方法を選択している場合、前記支払方法に応じた支払依頼を当該参加者端末に送信するステップと、前記金融機関のシステムから、前記金融機関の公式シンボルと共に前記参加者の支払情報の通知を受信するステップと、前記通知を前記イベントマスタ端末に送信するステップと、を含み、前記金融機関のシステムにおいて、前記支払依頼に基づく参加費の支払を受け付けるステップと、前記支払依頼を実行するステップと、前記支払の実行後、前記金融機関の公式シンボルと共に前記参加者の支払情報を前記ＳＮＳシステムに送信するステップと、を含むことを特徴とする。

本発明によれば、ＳＮＳと金融機関のシステムを連携させ、イベントの会費の支払を確認できるイベント参加費支払システムを提供することができる。

本発明の基本概念を示す図である。 本発明の第一の実施形態に係るイベント参加費支払システムの機能構成を示す図である。 本発明の第二の実施形態に係るイベント参加費支払システムの機能構成を示す図である。 本発明の実施形態に係るイベントマスタＤＢ１１のデータ構造を示す図である。 本発明の実施形態に係るイベント参加費支払システムにおける各端末と各システム間の処理シーケンスを示す図である。 イベント登録画面とイベント参加申込画面の具体例を示す図である。 参加費を銀行振込で支払う場合の振込依頼画面と銀行の振込画面の具体例を示す図である。 参加費をクレジットカードで支払う場合のカード決済依頼画面とカード会社のシステムでの決済情報入力画面の具体例を示す図である。 イベントマスタ端末におけるイベントマスタトップ画面とイベントマスタ集計画面の具体例を示す図である。 ユーザ基本情報画面のイベントに関連する情報の具体例を示す図である。 イベントの具体例として、寄付イベント登録画面及びその集計画面を示す図である。 イベントの具体例として、お祝金イベント登録画面及びその集計画面を示す図である。 イベントの具体例として、宝くじ共同購入イベント登録画面及びその集計画面を示す図である。 イベントの変形として、受験料徴収イベント登録画面及びその集計画面を示す図である。

以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。以降の図においては、実施形態の説明の全体を通して同じ要素には同じ番号または符号を付している。また、機能構成の図において、機能ブロック間の矢印は、データの流れ方向、又は処理の流れ方向を表す。また、処理フロー図（フローチャート）においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。

（基本概念）
図１は、本発明の基本概念を示す図である。宴会や会合などのイベントの幹事や主催者等（以下、イベントマスタと呼ぶ）は、まず、ＳＮＳ上のイベント登録画面１００からイベントの登録を行う。登録されたイベントの情報は、ＳＮＳ上のイベントマスタＤＢ１１に格納される（ステップ１）。このとき、イベント登録画面１００では、イベントの参加を呼び掛ける参加候補者のリストを含めることができる。参加候補者は必ずしもＳＮＳのユーザでなくともよい。イベントの登録が終わり、「参加候補者に送信」ボタンを押すと、参加候補者が同じＳＮＳのユーザである場合は、参加候補者のトップ画面にイベント参加者募集通知が掲載されると共に、イベント参加者募集のメールが参加候補者のメールアドレスに送信される（ステップ２）。なお、参加候補者がＳＮＳユーザでない場合は、メールのみが送信される。

参加候補者は、イベント参加者募集画面２００からイベントの内容を見て、参加するかどうかを決定する。参加候補者がこの画面から「参加する」ボタンを押すと、イベント情報記憶手段であるイベントマスタＤＢ１１に「参加者」として登録され（ステップ３）、イベントマスタのイベントトップ画面１１０にも、その参加候補者が参加表明したことが表示される（ステップ４）。図示は省略しているが、イベント参加者募集画面２００には、イベントの参加費や会費等の支払方法を参加者が選択できるようにする。支払方法は、銀行振込、クレジットカード、当日現金払が選択できるものとする。

イベントマスタは、参加者を確認し、参加者が銀行振込又はクレジットカードでの支払を選択している場合は、その参加者に対して、支払依頼画面１２０から支払依頼を送信する（ステップ５）。この支払依頼はイベントマスタＤＢ１１に登録され、ＳＮＳ側では、提携している金融機関に対して、参加者ごとに参加費の支払予定情報を送信する（ステップ６）。金融機関側では、イベントマスタＤＢ１１のサブセットとして、金融機関側で必要なデータのみを含んだイベント情報補助記憶手段であるイベントスレーブＤＢ２１を備えており、イベントスレーブＤＢ２１に、イベントごと、参加者ごとに支払予定情報を格納する。この時点で、参加者が支払いに利用する金融機関を指定していれば、当該金融機関のみにその支払予定情報が送信されるが、金融機関を指定していなければ、すべての提携金融機関に、その支払予定情報が送信される。なお、イベントマスタＤＢ１１とイベントスレーブＤＢ２１は、常に最新の情報を同期しているものとする。

参加者は、イベントマスタからの支払依頼を受け取った後、自らが取引している金融機関のＷＥＢページにログインし、その金融機関のＷＥＢページからイベント参加費を支払うものとする（ステップ７）。図示する振込画面２１０は、参加者が銀行のインターネットバンキングにアクセスし、参加費の振込を行っている場面を示している。参加者が金融機関を事前に指定している場合は、支払依頼の通知からその金融機関のＷＥＢページに遷移できるようにしてもよい。またこのとき、振込先の口座番号や金額は金融機関のＷＥＢページに自動的に入力されるようにしてもよい。参加者は、振込画面２１０の内容を確認後、振込のための暗証番号又はパスワード等を入力し、「振込」ボタンを押すと、イベントの支払が完了する。支払方法がクレジットカードの場合は、基本的には同様であるが、後述する。

参加者が支払いを完了したことは金融機関に通知される（ステップ８）。そして金融機関では、ＳＮＳ側に対してこの支払確認を通知するために、イベントマスタのイベントトップ画面１１１に、金融機関が確かにその支払を確認したことを証明する金融機関の公式シンボル（以後、「ペイドマーク」と呼ぶことにする）と共に、支払確認通知を投稿する（ステップ９）。このペイドマークは、偽造不可能な特別の画像で作成され、ＳＮＳ側では、この支払確認通知が確かに金融機関から投稿されたものであるとの認証を行った後に、イベントマスタのイベントトップ画面１１１に表示する。このようにすることで、イベントマスタは、参加者の支払が確実に行われたことを金融機関のお墨付で知ることができる。したがって、振込先の口座をいちいち確認する必要がなくなる。このことは多人数が参加するイベントにおいては特に有用である。

（機能構成）
図２は、本発明の第一の実施形態に係るイベント参加費支払システム（以下、本システム）の機能構成を示す図である。第一の実施形態では金融機関が銀行である場合について説明する。ＳＮＳシステム１０は、インターネットを介して、ユーザであるイベントマスタのイベントマスタ端末３１と、同じくユーザである参加者の参加者端末３２とに接続され、及び、インターネット又は専用のネットワークにて、銀行システム２０と接続されている。イベントマスタ端末３１と参加者端末３２は、一般的なＰＣやスマートフォン等で構成され、ハードウェア上の区別はない。また、ＳＮＳのユーザであれば、誰もがイベントマスタにもイベントの参加者にもなることができる。ただし、イベントマスタは、イベントマスタ端末３１を介して、自分が登録したイベントの会場（ホテルや宴会場等）のイベント会場端末３３と別途連絡を取っているものとする。

ＳＮＳシステム１０は、既存のＳＮＳシステムに、銀行システムと連携させイベントサポート用の機能を追加したものである。ＳＮＳシステムの典型的な構成例としては、イベントマスタＤＢ１１、イベント情報同期部１２、イベント登録部１３、参加者募集送信部１４ａ、参加者受付部１４ｂ、参加費支払依頼部１５、支払情報確認部１６、支払情報集計部１７で構成される。

イベントマスタＤＢ１１は、イベントＩＤ、イベントマスタとなるユーザＩＤ、そのユーザ情報、イベント会場、イベント参加費の支払先、参加者の人数、参加者ごとのユーザＩＤ、参加Status、参加費の支払方法等の情報を含んでいる。イベントマスタＤＢ１１に格納されるデータの具体例は、図４で後述する。

イベント情報同期部１２は、ＳＮＳ側のイベントマスタＤＢ１１と銀行システム２０側のイベントスレーブＤＢ２１を常に同期させる役目を持っている。具体的には、両者のＤＢの更新情報（データの交信日時とそのデータ）が常に一致するように、更新情報のやりとりと、書き込み時の排他アクセス制御を行なう。データベースの同期方法自体は、公知の技術なので詳細は省略する。

イベント登録部１３は、イベントマスタ端末３１からのイベントの情報の入力を受付け、イベントマスタＤＢ１１に格納する。イベント情報の登録、変更は、銀行システム側のイベントスレーブＤＢ２１にも同期されるのは当然であるが、銀行側で使用しない情報までを同期する必要はない。

参加者募集送信部１４ａは、イベントの登録があったときに、参加候補者のリストにある参加者に対して参加者募集通知を送信する。参加者受付部１４ｂは、参加者募集通知を送信したイベントに対し、参加の申し込みがあった参加者の情報を受付け、イベントマスタＤＢ１１に格納する。参加者の情報には、参加者のユーザＩＤ、参加費の支払方法の他、イベントマスタに対するメッセージやイベント終了後の評価等を含んでもよい。

参加費支払依頼部１５は、参加者が選択した支払方法に応じた支払依頼を生成する。図の場合は、参加者が銀行振込を選択しているものとしているので、銀行振込の参加者のリストを生成し、イベントマスタに送信する。イベントマスタは、この参加者リストを確認し、過不足がなければ、銀行振込を希望する参加者全員に振込依頼を送信する。このときの参加費支払依頼には、イベントＩＤ、参加費の金額、及び振込先の口座番号が含まれる。また、参加者が振込を行う銀行を指定している場合は、支払依頼通知にその銀行のインターネットサイトのリンク情報（ＵＲＬ）、イベントＩＤ、及び参加者がＳＮＳのユーザである場合は、その参加者のＳＮＳ上でのユーザＩＤを含ませ、参加者がこの支払依頼通知から銀行のＷＥＢページに遷移し、銀行のサイトに直接ログインできるようにしてもよい。このときの銀行のサイトに、イベントＩＤ、ＳＮＳ上のユーザＩＤ、振込先口座等の情報が自動的に受け渡されるようにしてもよい。なお、振込先口座はイベントマスタ自身の銀行口座にしてもよい。この場合、費用を立て替えたイベントマスタからイベント会場等に後日の清算が必要となる。参加者の参加費の支払方法がクレジットカードである場合は、図３で後述する。

支払情報確認部１６は、銀行振込を選択した参加者が実際にその振込を行った際に銀行システム２０から支払通知を受信し、イベントマスタＤＢ１１にその情報を書き込むと同時に、イベントマスタに通知する。この通知は、具体的には、イベントマスタのイベントトップ画面に表示される。

支払情報集計部１７は、イベントマスタからの要求に応じて、イベントマスタＤＢ１１を読出し、そのイベントの支払情報を集計する。支払情報集計部１７は、例えば、ペイドマークを抽出してソートすることや、参加者が支払を行った金融期間ごとに集計を行うこと等ができる。また、参加者が現金で支払った場合も、そのデータをイベントマスタに手入力してもらうことで集計に加えることもできる。集計結果は、主にイベントマスタに送信されるが、一部の情報は参加者にも送信されるようにしてもよい。この機能は、イベント終了後に、イベントマスタが会計報告をする際に有用である。

次に銀行システム２０側の機能構成について説明する。銀行システム２０は、銀行が備えるインターネットバンキングのシステム［ＥＢ（Electronic Banking）システムとも呼ぶ］に、ＳＮＳと連携させ、イベントサポート用の機能を追加したものである。銀行システムの典型的な構成としては、イベントスレーブＤＢ２１、イベント情報同期部２２、振込受付部２３、振込処理部２４、支払情報送信部２５で構成される。

イベントスレーブＤＢ２１は、前述のイベントマスタＤＢ１１から、銀行側で使用する情報を受信し格納する。イベント情報同期部２２は、このデータベース間の同期をＳＮＳ側のイベント情報同期部１２と協業して制御する。

振込受付部２３は、銀行システム２０のインターネットバンキングにおける振込処理と同様であるが、この振込画面には、イベントのＩＤとＳＮＳ上のユーザＩＤを参加者に入力させる。ここで、イベントＩＤは、両システムで共通のものを使用するが、ユーザＩＤは、ＳＮＳと銀行システムで当然異なるものだからである。振込受付部２３は、このイベントＩＤとＳＮＳ上のユーザＩＤに基づいてイベントスレーブＤＢ２１を検索し、参加費の金額や振込先口座を自動入力することができる。もちろん、参加者が受け取る振込依頼には金額や振込先口座が記載されているので、参加者が振込の際にそれらを手入力してもよい。また、参加者が予め振込を行う銀行を指定している場合は、参加者が受け取った振込依頼通知に銀行のイベント振込専用のＵＲＬが記載されており、そのＵＲＬをクリックして参加者が銀行システム２０にログインすると、振込に必要な情報が自動的に入力された画面を表示するようにしてもよい。

振込処理部２４は、銀行の一般的な勘定系システムであり、振込受付部２３が受け付けた振込（口座間の資金移動）を実行する。そして振込処理が正常に行われた場合は、イベントスレーブＤＢ２１にその結果を書き込む。振込結果を振込受付部２３に返信し、振込受付部２３がイベントスレーブＤＢ２１に振込結果を書き込むようにしてもよい。

支払情報送信部２５は、イベント参加費に関する振込が正常に行われた場合、その情報をＳＮＳ側の支払情報確認部１６に送信する。具体的には、銀行側の支払情報送信部２５は、当該イベントＩＤと参加者のＳＮＳ上のユーザＩＤを、自社の公式ペイドマークと共に、ＳＮＳ側の支払情報確認部１６に送信する。そして、ＳＮＳ側の支払情報確認部１６は、イベントマスタのトップ画面に、このペイドマークを参加者のＩＤ、支払金額と共に表示する。

図３は、本発明の第二の実施形態に係るイベント参加費支払システムの機能構成を示す図である。第二の実施形態では、金融機関がクレジットカード会社である場合を説明する。ＳＮＳシステム１０は、イベントマスタ端末３１と、参加者端末３２とインターネットで接続されるのは同様であるが、インターネット又は専用ネットワークにて、クレジットカード会社システム２０Ａと接続される。以下では、第一の実施形態と異なる部分のみを説明する。なお、第一の実施形態と第二の実施形態は選択的に利用するものでなく、本システムでは両者を共に備えることができる。

ＳＮＳシステム１０においては、参加費支払依頼部１５が、カード決済のために依頼を行う機能が追加される。参加費支払依頼部１５は、参加者がクレジットカードでの参加費の支払を選択している場合に、参加者端末３２にクレジットカードによる決済依頼を送信する。このときの、決済依頼の情報には当該イベントＩＤと参加者のＳＮＳ上でのユーザＩＤ、参加費用の金額を含んでいる。決済依頼を受け取った参加者は、自身が契約しているクレジットカード会社のシステムのＷＥＢページにログインし、この支払の決済を行うことになる。支払情報確認部１６は、カード決済が完了したことの支払通知を受信する。

クレジットカードのＷＥＢシステムは、通常は、カードの利用状況の確認、請求書の確認、支払方法の変更（あとリボ払いやあと分割払いへの変更）等に利用されるが、本システムにおいては、イベントサポート機能が追加されているのでイベント参加費のカード決済が可能である。すなわち、クレジットカード会社のシステムは、通常は、加盟店端末からのカードの決済要求を受け、その決済が問題ないかを判断するオーソリ（そのカードが使用可能かどうかの承認を取ること）を行うことが主であるが、本システムでは、参加者と加盟店（この場合は、イベント会場となるホテルや店舗等）との決済を代行する役目を果たす。

そのため、図示するように、クレジットカード会社システム２０Ａは、加盟店情報確認部２６とオーソリ処理部２７とを備えている。加盟店情報確認部２６は、参加者端末３２から、ＳＮＳを介して、決済のためのログインがあった際に、イベントスレーブＤＢ２１を読出し、イベントＩＤと、ＳＮＳ上のユーザＩＤが登録されているかを確認する。

ここで、イベントＩＤは、両システムで共通であるが、ユーザＩＤは、両システムで当然異なる。本システムにおいては、参加者は、クレジットカード会社システム２０Ａにおいて、イベントＩＤ、ＳＮＳ上のユーザＩＤ、クレジットカード番号、決済用の暗証番号又はパスワードを入力することで、イベント参加費を決済することができる。このため、カードシステム側の加盟店情報確認部２６は、イベントスレーブＤＢ２１から入力されたイベントＩＤとＳＮＳ上のユーザＩＤとに基づいて、当該イベントの情報を読出し、その中に含まれるイベント会場となる施設（ホテルや店舗等）のＩＤ、名称、住所等を読み出す。そしてその施設のＩＤ、名称、住所等が当該クレジットカードの加盟店として登録されていれば、その施設が備える加盟店システム４０にこれらの情報を照会し確認する。そして、この照会の結果、当該施設が自社の加盟店である場合は、あたかも参加者が加盟店システム４０のＷＥＢページからカード決済を行ったものとみなし、オーソリ処理部２７に当該カードの承認を依頼する。

オーソリ処理部２７は、通常の加盟店端末（ＰＯＳ端末等）からのカードの承認依頼と同様に、カード番号、暗証番号、名義人、有効期限、利用限度額等を確認し、カードが利用可能であれば、その決済を承認する。さらに加盟店情報確認部２６からの承認依頼の場合は、承認に問題がなければ、イベントスレーブＤＢ２１にその承認結果を書き込む。カードシステム側のイベント情報同期部２２は、この承認結果（ＤＢの更新情報）をＳＮＳ側のイベント情報同期部１２に送信し、イベントスレーブＤＢ２１とイベントマスタＤＢ１１を常に同期させるようにするのは図２の場合と同様である。そして、カードシステム側の支払情報送信部２５は、オーソリ処理部２７によって、カードの利用が承認されれば（イベントスレーブＤＢ２１の当該イベントＩＤの当該ユーザＩＤのカード決済の承認が記載されていれば）、そのイベントＩＤと参加者のＳＮＳ上のユーザＩＤを、自社の公式ペイドマークと共に、ＳＮＳ側の支払情報確認部１６に送信する。ＳＮＳ側では、イベントマスタのトップ画面に、このペイドマークを参加者のＩＤ、支払金額と共に表示する。なお、上記の説明では、参加者が直接、加盟店にクレジットカードで支払うことになるが、クレジットマスタ自身が個人事業主として加盟店となることも可能なので、その場合は、参加者はイベントマスタに対して、クレジットカードで支払うことになる。つまり、イベントマスタ自身が加盟店としてクレジットカード会社に対して請求データを発生させ、クレジットカード会社は、その請求データについて、参加者のクレジットカードの支払口座から引き落とすという処理になる。

図４は、上記で説明した本発明の実施形態に係るイベントマスタＤＢ１１のデータ構造を示す図である。図示するようにイベントマスタＤＢ１１は、イベントに固有なイベントＩＤの他、イベントの内容であるイベント情報１１ａと参加者情報１１ｂとに分けられる。イベント情報１１ａは、通常イベント登録時に入力されるが、その後更新することも可能である。参加者情報１１ｂは、参加者の申し込みを受け、時々刻々と変化するものである。

イベント情報１１ａには、イベントマスタとなったユーザのイベントマスタ情報１１ａ１（ユーザＩＤ，メールアドレス、電話番号等）が含まれる。イベントマスタが参加費用を立て替える場合は、イベントマスタ自身の銀行口座を暗号化して含んでもよい。また、イベント情報１１ａには、イベント会場情報１１ａ２が含まれ、イベント会場情報１１ａ２には、イベントの開催日時、開催場所、参加費、参加費の支払を受け付ける方法（銀行振込、クレジットカード、現金等）、銀行振込を受け付ける場合はその振込先の口座番号、及びイベントの参加募集期間が格納される。

参加者情報１１ｂは、現時点での参加表明した参加者の人数と、その参加者ごとのユーザＩＤ、参加意志の有無を示す参加Status、参加費の支払方法、及びその支払状況を示す支払Statusが格納される。支払方法には、振込元となる銀行名や、クレジットカードの名称を含んでもよい。支払Statusには、銀行振込の場合は、「振込依頼準備中」、「振込依頼中」、「振込済」のうちどれかが格納される。クレジットカード支払の場合は、「決済依頼準備中」、「決済依頼中」、「決済済」の他、決済後に参加のキャンセルを受け付けることができる場合には、「要返金」、「返金済」等の状態が格納される。

以上説明した本システムの機能構成は、あくまで一例であり、一つの機能ブロック（データベース及び機能処理部）を分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能処理部は、装置に内蔵されたＣＰＵ（Central Processing Unit）が、ＲＯＭ（Read Only Memory）、フラッシュメモリ、ＳＳＤ(Solid State Drive)、ハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。

図５は、本発明の実施形態に係るイベント参加費支払システムにおける各端末と各システム間の処理シーケンスを示す図である。この図では、金融機関が銀行である場合の第一の実施形態について説明するが、第二の実施形態においても基本的には同様で、第二の実施形態で異なる部分については、その部分のみを最後に説明する。この図の説明では、イベントマスタ端末３１をマスタ端末、ＳＮＳシステム１０をＳＮＳ、銀行システム２０を銀行システム、参加者端末３２を参加者端末と単に呼ぶことにする。また、以下ではイベントマスタのイベントの登録から参加者の参加申込までのプロセスは既に完了しているものとする。

最初に、マスタ端末は、ステップＳ１０において、イベント参加者の中から銀行振込希望者を選択し、振込依頼をＳＮＳに送信する。このとき、銀行振込を希望する参加者のリストは、参加者の参加申込時の情報に基づいて、ＳＮＳにより自動生成されるが、イベントマスタは、銀行振込希望の参加者のリストをいつでも変更することができる。参加者の中には、支払方法の変更やイベントの参加自体をキャンセルする際に、ＳＮＳで連絡する前にイベントマスタに別の方法（電話等）で連絡をとったりする場合があるからである。

ＳＮＳでは、この振込依頼をマスタ端末から受信すると、ステップＳ２０において、イベントマスタＤＢ１１の支払Statusを「振込依頼中」に更新し、銀行システムに送信する。銀行システムでは、ステップＳ３０において、イベントスレーブＤＢ２１を最新状態に更新し、データベースを同期させる。さらにＳＮＳでは、ステップＳ２１において、イベントマスタＤＢ１１から銀行振込希望の参加者のメールアドレスを取得し、振込依頼メールを参加者端末に送信する。このとき、各参加者のイベントトップ画面にも、この依頼通知が記載されるのは言うまでもない。

参加者端末では、ステップＳ４０において、振込依頼を受信すると、参加者が契約しているネットバンキングにログインし、ログイン後に表示される「イベント振込」を選択する（ステップＳ４１）ことを求められる。イベント振込とは、ＳＮＳと連携したイベントの参加料を支払うために用意された専用の振込画面のことである。イベント振込画面には通常の振込画面にイベントＩＤとＳＮＳ上のユーザＩＤの入力が求められるが、ＳＮＳ上の振込依頼画面からリンクされたＵＲＬから銀行システムにログインすると、イベントＩＤ、ＳＮＳ上のユーザＩＤが自動的に入力される。

銀行システムでは、銀行のインターネットバンキングにログインした参加者がイベント振込を選択したことを検知すると、入力されたイベントＩＤとＳＮＳ上のユーザＩＤに基づいて、イベントスレーブＤＢ２１からイベント参加費の振込金額、振込先口座を取得し、振込画面を生成する（ステップＳ３１）。参加者は、この振込画面の内容を確認後、ＯＫであれば、振込用の暗証番号又はパスワードを入力して、振込実行依頼を銀行に送信する（ステップＳ４２）。

振込実行依頼を受けた銀行システム（勘定系システム）は、ステップＳ３２において、その振込を実行する。そして、イベントスレーブＤＢ２１の当該参加者の支払Statusを更新し、同時にＳＮＳにも公式ペイドマークをＳＮＳに送信する（ステップＳ３３）。

ＳＮＳでは、ステップＳ２２において、このペイドマークを受信すると、イベントマスタＤＢ１１を更新し、ステップＳ２３において、イベントマスタＤＢ１１の更新された情報、すなわち、参加者が振込を完了し、銀行システムが確認したことを、ペイドマークと共にマスタ端末に送信する。マスタ端末では最後に、イベントトップ画面に表示されたイベント情報に銀行からの公式ペイドマークを確認し、参加者が確かに参加費の支払を完了したことを知ることができる（ステップＳ１１）。このようにして、イベントマスタからの振込依頼に対して、参加者の振込完了までのプロセスが完了する。

図５においては、金融機関が銀行である場合の第一の実施形態を説明したが、金融機関がクレジットカード会社の場合の第二の実施形態では、銀行システム２０をクレジットカード会社システム２０Ａに、振込依頼を決済依頼に、振込画面を決済画面に、振込実行依頼をカードの承認依頼に置き換えれば、基本的に同様である。ただし、上記のステップＳ３１において、決済画面を生成する前に、前述の加盟店システム４０に対し、イベント情報に記載されたイベント会場を運営する事業者が当該クレジットカードの加盟店かどうかを確認するステップが加わることになる（図３の加盟店情報確認部２６の説明を参照）。

図６は、イベント登録画面とイベント参加申込画面の具体例を示す図である。
図示するイベント登録画面１００は、イベントマスタがイベントを登録する際に使用する画面である。この画面はＳＮＳ内のメニューから選択することができる。イベントの登録情報としては、イベント名、開催日時、開催場所、参加費用、参加者を募集する期間、受付可能な参加費の支払方法を選択する。そして、参加を呼び掛けるユーザを、ＳＮＳの友達リストや別途インポートしたリストから参加者募集リストを作成する。イベントの登録が完了するとＳＮＳからイベントＩＤが割り当てられ、「このイベントの参加者を募る」ボタンを押すと、参加募集リストの参加者に通知される。

参加候補者の元にはイベント参加者募集画面２００が送信され、参加者候補者は、イベントの内容を確認後、参加する場合は、参加費用支払方法を選択して、「このイベントに参加する」ボタンを押すと、イベントマスタＤＢ１１に参加者として登録され、同時にイベントマスタにそのことが通知される。

図７は、参加費を銀行振込で支払う場合の振込依頼画面と銀行の振込画面の具体例を示す図である。イベントマスタは、支払依頼画面１２０（振込依頼画面）から振込先の銀行口座番号、名義人、振込金額を入力後、振込依頼を送信する参加者を確認後、「振込依頼」を送信する。振込先の銀行口座番号、名義人は、イベントマスタのユーザ基本情報からデフォルトとして入力されていてもよい。振込依頼を送信する参加者のリストは、ＳＮＳの友達や知人リストから、又は別途用意された参加候補ファイルをインポートして生成されるが、過不足があればイベントマスタがそのリストを変更することができる。

振込依頼を受け取った参加者は、自身が契約する銀行のインターネットバンキングにログインし、図示するようなイベント参加費の振込画面２１０から、イベントＩＤとＳＮＳ上の自身のユーザＩＤを入力する。イベントＩＤとユーザＩＤは手入力してもよいが、振込依頼に記載されたＵＲＬから銀行のインターネットバンキングにログインすると、イベントＩＤとユーザＩＤが自動的に入力されるようにしてもよい。参加者は、表示されている引落口座及び振込先口座と振込金額を確認し、振込を行う。

図８は、参加費をクレジットカードで支払う場合のカード決済依頼画面とカード会社のシステムでの決済情報入力画面の具体例を示す図である。イベントマスタは、カード決済を選択した参加者に対して、図示するようなカード決済依頼画面１２１（支払依頼画面）から、参加費の支払を依頼する。

カード決済依頼を受け取った参加者は、図示するようなイベント参加費カード決済画面２１１から、カード情報を入力し（イベントＩＤ，ＳＮＳユーザは自動入力されているものとする）、支払先を確認後、支払回数と決済用の暗証番号又はパスワードを入力し、決済を行う。

図９は、イベントマスタ端末におけるイベントトップ画面とイベントマスタ集計画面の具体例を示す図である。イベントトップ画面は、イベントマスタのＳＮＳでのトップ画面であり、自分が主催者であるイベントに関するすべての情報が時系列で表示される。図示するイベントトップ画面１１２には、イベント参加者の参加表明、不参加表明、キャンセルの申し出の他、金融機関からの参加費の支払確認が各金融機関の公式ペイドマークと共に表示される。この画面上で、ペイドマークだけをソートしたり、参加者ごとにソートしたりできる機能をもたせてもよい。

イベントマスタ集計画面１４０は、イベントの各種情報を集計して表示する機能を持った画面である。具体的には図示するように、参加候補者（参加を呼び掛けた人）の人数、実際の参加者の人数、欠席者、未回答者の人数と、各人数の内訳が表示される。また、金融機関ごとの支払確認件数とその内訳、カード決済後のキャンセル者の人数とその内訳（返金対象者）、及び支払依頼をしたにも関わらず未支払の人数とその内訳が表示される。未支払者には督促を送信するが、それでも支払が行われない場合は、不参加として扱ってもよい。また、イベントの終了後に、画面下の「会計報告を作成」ボタンを押すと、参加者に対する会計報告が支払情報集計部１７によって、自動的に作成される。

図１０は、ユーザ基本情報画面のイベントに関連する情報の具体例を示す図である。ＳＮＳには、ネットワーク作りの基本として、ユーザのプロフィールを登録するのが一般的であるが、本システムでは、出身や年齢といったユーザの個人情報に加え、イベントマスタを務めた回数、イベントマスタとして受けた評価やコメント、参加者としてイベントに参加した件数とその内訳、参加したイベントで支払が完了しているものと支払が完了していないものの件数と内訳等、イベントに関するあらゆる情報が基本情報に追加され、図示するようにユーザ基本情報画面１３０に表示可能である。これらの情報を公開するか否かはユーザの設定によるが、他のユーザに公開することで、どのようなイベントに多く参加しているか、どのようなイベントに興味を持っているか、イベントマスタとして活躍しているか等、そのユーザの人望を知る機会がより多く与えられる。

（イベントの他の具体例）
本システムによれば、宴会や会合等のイベント参加費の支払及び確認をスムーズに行うことができるが、本システムが扱うイベントは宴会や会合に限らず、支払いを伴う様々なイベントに適用することができる。以下ではそのようなイベントの具体例について説明する。

図１１は、イベントの具体例として、寄付イベント登録画面及びその集計画面を示す図である。寄付には、宴会や会合と違って、イベント会場の予約、カード決済、参加者との連絡、参加のキャンセル、会計報告といった要素は一般的にはないが、本システムの仕組みがそのまま適用できる。すなわち、本システムのユーザであれば誰でも、様々な規模の私的・公的の寄付を呼びかけることができる。寄付の発起人は本システムでイベントマスタとなり、図示するようなイベント登録画面１０１から寄付のイベントを登録する。登録するイベント情報は、基本的には宴会や会合の場合と同様であるが、イベント詳細情報には、寄付金総額のみが参加者に開示されることを明記する。また参加者の募集対象を友人や知人だけでなくＳＮＳの全ユーザを対象にすることもできる。

一般的に、個人や知らない団体が主催する寄付に募金することには多少の不安感があるが、主催者の前述したユーザ基本情報を見て、イベントマスタとしての実績が豊富なユーザが主催している寄付であると分かれば、他のユーザは安心して募金することができる。寄付イベントを主催するユーザには、ユーザ基本情報のイベントに関する部分の公開を義務付けてもよい。また、本システムを利用すれば、支払確認が金融機関からの公式ペイドマークで確認できるので、募金者には、より安心感を得られる。図示するように、募金終了時又は所定の期間ごとに、募金者数と寄付金総額がイベントマスタ集計画面１４１に表示され、イベントマスタに通知される。そして、イベントマスタが、募金活動終了後、画面下の「募金者に送付」ボタンを押すと、募金者のユーザ全員に、この募金者数と寄付金総額が募金活動の報告として送信される。

図１２は、イベントの具体例として、お祝金イベント登録画面及びその集計画面を示す図である。この画面は、入学、卒業、入社、結婚、出産等のお祝金の募集を本システムのイベントとして登録した例である。お祝金のイベント登録画面１０２から登録するイベント情報には、図示するような情報を入力するが、イベント詳細情報には、お祝金の送り先（贈答先）のユーザＩＤを記載すれば、参加者が本システムを通じて、お祝いメッセージ等を送ることができる。また、お祝金に対して贈答先から半返し等を行う場合もあるので、お祝金の内訳は贈答先に開示されることを明記する。

お祝金イベントのイベントマスタ集計画面１４２には、お祝金の参加者の人数とその内訳ボタンが表示されるが、内訳ボタンを押しても、誰がいくら支払ったかの詳細まではイベントマスタには開示されないようにしてもよい。もちろん、イベントマスタが「贈答先に送付」ボタンを押すと、その内訳のすべてが贈答先に開示される。

図１３は、イベントの具体例として、宝くじ共同購入のイベント登録画面及びその集計画面を示す図である。図示する宝くじ共同購入のイベント登録画面１０３は、宝くじの共同購入を本システムのイベントとして登録した例である。この画面では、図示するようなイベント情報を入力するが、イベント詳細情報には、出資金の詳細を出資者全員に公開されることを選択している。出資金の総額のみを出資者に公開するようにも選択できる。

宝くじ共同購入イベントにおけるイベントマスタ集計画面１４３には、参加者（出資者）の人数とその内訳ボタンが表示されるが、内訳ボタンは、上記のイベント詳細情報が、出資金の総額のみ出資者に開示となっている場合は、イベントマスタ（又は宝くじを実際にまとめて購入したユーザ）にのみ表示することが可能である。これは出資者のプライバシーに配慮したものであるが、システム上は、各出資者の出資金の内訳が金融機関の支払確認通知によって記録されているので、当選金の分配に不正があった場合等には容易に発見が可能である。なお、購入した宝くじ券の番号を、バーコードリーダなどですべて読み取り、このイベントマスタ集計画面１４３から添付ファイルとして参加者に送付するようにしてもよい。なお、宝くじに当選したときの配当金の分配を本システムを利用して行えるようにしてもよい。例えば、イベントマスタ集計画面１４３にイベントマスタから出資者に対する通知手段を設け、このときの通知内容には、出資者の出資金額に応じた割合の分配金が自動計算されて含まれる。イベントマスタは、以後、この通知内容に示された金額と出資者を確認しながら、個々の出資者と当選金の分配方法等をやりとりすることができる。

図１４は、イベントの変形として、受験料徴収のイベント登録画面及びその集計画面を示す図である。図１１〜図１３では、個人のユーザがイベントマスタとなり、イベントを登録する例を示したが、ＳＮＳにおいては、企業や大学等の団体もユーザとして登録できるので、団体が主催するイベントを登録することも可能である。そのイベントが団体の本来の業務であっても構わない。例えば、図示するイベント登録画面１０４は、大学の入学試験の受験料の徴収を本システムのイベントとして登録した例である。

この画面では、図示するようなイベント情報を入力するが、イベント詳細情報には、ここでは本システムを利用して受験料を支払うと特典があることが明記されている。イベントの主催者（大学）にとっては、本システムを利用することで、受験料の徴収や支払の確認業務が軽減されるというメリットがある。さらに、ＳＮＳを利用することで、大学の国内外での知名度アップにも貢献できるというメリットもある。また、受験生やその親にとっては、大学のホームページ等から支払を行うより、普段利用しているＳＮＳで支払ができれば親近感がもて、同じ大学を受験するＳＮＳ上の友人等とのコミュニケーションを深めることもできる。さらに、いくつかの大学を掛け持ち受験する受験生にとっては、大学ごとのバラバラな支払方法でなく、ＳＮＳ上の統一した支払方法を利用できるというメリットもある。しかも支払確認を金融機関が行ってくれるので安心である。銀行振込だけでなく、クレジットカードでも受験料を手軽に支払えるのも魅力である。

受験料徴収イベントのイベントマスタ集計画面１４４は、本システムを利用した受験料払込者の総数及び金融機関ごとの支払確認実績の一覧が表示されるようにしてもよい。この画面でイベントマスタが「集計表を作成」ボタンを押すと、例えば、金融機関ごとの集計や、受験生のプロフィール毎の集計等を行うこともできる。このように、団体が主催者となり本来の業務に関するようなイベントに対しては、ＳＮＳ側、金融機関側からその団体に対して一定の利用手数料を課すようにしてもよい。

（実施形態の効果）
本システムよれば、ＳＮＳと金融機関のシステムを連携させ、ユーザが普段利用しているＳＮＳからイベントの主催や幹事の業務を行うことができ、特にイベントの参加費の集金、支払確認、清算等の業務を効率化することができる。特に、金融機関（銀行、クレジットカード会社）の支払確認である公式シンボル（ペイドマーク）がイベントマスタのイベントトップ画面に表示されるので、参加者が確かに参加費等を支払ってくれたことが金融機関のお墨付きでＳＮＳ上でも確認できる。また、イベントＩＤ、支払金額、支払先、ＳＮＳ上のユーザＩＤ等が参加者が受信した支払依頼通知から金融機関のインターネットサイトに自動的に受け渡されるので、振込やカード決済の際の入力作業が容易になる。また、本システムを利用すれば、支払情報の集計を行ってくれるので、幹事等の会計報告も容易になる。また、本システムが扱うイベントは、宴会や会合だけでなく、寄付の募集、お祝金の贈答、宝くじの共同購入、企業や大学などの団体が主催する各種イベントの料金徴収を含むことができるので利用範囲が広い。

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。なお、上記の実施形態では、本発明を物の発明としてイベント参加費支払システムを説明したが、本発明は、方法の発明（イベント参加費支払方法）としても捉えることもできる。

１、１Ａ イベント参加費支払システム
１０ ＳＮＳシステム
１１ イベントマスタＤＢ
１１ａ イベント情報
１１ａ１ イベントマスタ情報
１１ａ２ イベント会場情報
１２ イベント情報同期部（ＳＮＳ側）
１３ イベント登録部
１４ａ 参加者募集送信部
１４ｂ 参加者受付部
１５ 参加費支払依頼部
１６ 支払情報確認部
１７ 支払情報集計部
２０ 銀行システム
２０Ａ クレジットカード会社システム
２１ イベントスレーブＤＢ
２２ イベント情報同期部（金融機関側）
２３ 振込受付部
２４ 振込処理部
２５ 支払情報送信部
２６ 加盟店情報確認部
２７ オーソリ処理部
３１ イベントマスタ端末
３２ 参加者端末
３３ イベント会場端末
４０ 加盟店システム
１００ イベント登録画面
１０１ イベント登録画面（寄付）
１０２ イベント登録画面（お祝金）
１０３ イベント登録画面（宝くじ共同購入）
１０４ イベント登録画面（受験料徴収）
１１０、１１１、１１２ イベントトップ画面
１２０ 振込依頼画面（支払依頼画面）
１２１ カード決済依頼画面（支払依頼画面）
１３０ ユーザ基本情報画面
１４０，１４１，１４２，１４３，１４４，１４５ イベントマスタ集計画面
２００ イベント参加者募集画面
２１０ イベント参加費の振込画面
２１１ イベント参加費のカード決済画面

Claims (6)

1. ＳＮＳシステムと、銀行システムと、前記ＳＮＳシステムのユーザでありイベントの主催者又は幹事であるユーザのイベントマスタ端末と、前記イベントの参加者である参加者端末とがネットワークで接続され、前記イベントの参加費の支払及び確認を行うイベント参加費支払システムであって、
   前記ＳＮＳシステムは、
   前記イベントマスタ端末から前記イベントの情報を受付け、イベント情報記憶手段に登録するイベント登録部と、
   前記イベントが登録されたときに、前記イベントの参加者を募集する通知を前記参加者端末に送信する参加者募集送信部と、
   前記募集の通知を受けた前記参加者端末から、前記イベントの参加者を受付ける参加者受付部と、
   前記参加者が前記イベントの参加費の支払方法に銀行振込を選択している場合に、当該参加者端末に振込依頼を送信する参加費支払依頼部と、
   前記銀行システムから、前記参加者が前記振込依頼に基づいた振込を行ったことを示す支払通知を前記銀行の公式シンボルと共に受信し、前記支払通知を前記イベントマスタ端末に送信する支払情報確認部とを備え、
   前記銀行システムは、
   前記振込依頼に基づく振込を受付ける振込受付部と、
   前記振込を実行する振込処理部と、
   前記振込の実行後、前記銀行の公式シンボルと共に前記参加者の支払情報を前記支払情報確認部に送信する支払情報送信部と、
   を備えることを特徴とするイベント参加費支払システム。
2. ＳＮＳシステムと、クレジットカード会社のシステムと、前記ＳＮＳシステムのユーザでありイベントの主催者又は幹事であるユーザのイベントマスタ端末と、前記イベントの参加者である参加者端末とがネットワークで接続され、前記イベントの参加費の支払及び確認を行うイベント参加費支払システムであって、
   前記ＳＮＳシステムは、
   前記イベントマスタ端末から前記イベントの情報を受付け、イベント情報記憶手段に登録するイベント登録部と、
   前記イベントが登録されたときに、前記イベントの参加者を募集する通知を前記参加者端末に送信する参加者募集送信部と、
   前記募集の通知を受けた前記参加者端末から、前記イベントの参加者を受付ける参加者受付部と、
   前記参加者が前記イベントの参加費の支払方法にクレジットカードを選択している場合に、当該参加者端末にカード決済依頼を送信する参加費支払依頼部と、
   前記クレジットカード会社のシステムから、前記参加者が前記カード決済依頼に基づいた決済を行ったことを示す支払通知を前記クレジットカード会社の公式シンボルと共に受信し、前記支払通知を前記イベントマスタ端末に送信する支払情報確認部とを備え、
   前記クレジットカード会社のシステムは、
   前記イベントの会場の事業者が前記クレジットカードの加盟店であることを確認する加盟店情報確認部と、
   前記加盟店情報確認部からの依頼を受け、前記クレジットカードの利用を承認するオーソリ処理部と、
   前記クレジットカードの利用の承認後、前記クレジットカード会社の公式シンボルと共に前記参加者の支払情報を前記支払情報確認部に送信する支払情報送信部と、
   を備えることを特徴とするイベント参加費支払システム。
3. 前記参加費支払依頼部は、前記イベントのＩＤ，前記参加者の前記ＳＮＳシステムのユーザＩＤ、前記参加者が指定した金融機関のインターネットサイトへのリンク情報、を含む参加費支払依頼を前記参加者端末に送信することを特徴とする請求項１又は２に記載のイベント参加費支払システム。
4. 前記ＳＮＳシステムは、前記イベントの終了後の会計報告のために、前記支払情報の集計を行う支払情報集計部を備えることを特徴とする請求項１乃至３のいずれか一項に記載のイベント参加費支払システム。
5. 前記イベントには、宴会、会合、寄付の募集、お祝金の贈答、宝くじの共同購入、団体が主催するイベントの料金徴収を含むことを特徴とする請求項１乃至４のいずれか一項に記載のイベント参加費支払システム。
6. ＳＮＳシステムと、金融機関のシステムと、前記ＳＮＳシステムのユーザでありイベントの主催者又は幹事であるユーザのイベントマスタ端末と、前記イベントの参加者である参加者端末とがネットワークで接続され、前記イベントの参加費の支払及び確認を行うイベント参加費支払方法であって、
   前記ＳＮＳシステムにおいて、
   前記イベントマスタ端末から前記イベントの情報を受付け、イベント情報記憶手段に登録するステップと、
   前記イベントの登録後、前記イベントの参加者を募集する通知を前記参加者端末に送信するステップと、
   前記募集の通知を受けた前記参加者端末から、前記イベントの参加者を受付けるステップと、
   前記参加者が前記イベントの参加費の支払方法を選択している場合、前記支払方法に応じた支払依頼を当該参加者端末に送信するステップと、
   前記金融機関のシステムから、前記金融機関の公式シンボルと共に前記参加者の支払情報の通知を受信するステップと、
   前記通知を前記イベントマスタ端末に送信するステップと、を含み、
   前記金融機関のシステムにおいて、
   前記支払依頼に基づく参加費の支払を受け付けるステップと、
   前記支払依頼を実行するステップと、
   前記支払の実行後、前記金融機関の公式シンボルと共に前記参加者の支払情報を前記ＳＮＳシステムに送信するステップと、
   を含むことを特徴とするイベント参加費支払方法。

Images