JP6744650B1

JP6744650B1 - イベント管理システム

Info

Publication number: JP6744650B1
Application number: JP2020061564A
Authority: JP
Inventors: 康太前田
Original assignee: 株式会社プラグ
Priority date: 2020-03-30
Filing date: 2020-03-30
Publication date: 2020-08-19
Anticipated expiration: 2040-03-30
Also published as: JP2021162944A

Abstract

【課題】イベントのマッチング（調整）をより高度に実現する。【解決手段】本発明の一態様における、ネットワークで接続される、所定のイベントを提案する提案者に関連する提案者側端末と、参加候補者に関連する候補者端末と、を仲介するサーバ端末により提供されるイベント管理システムであって、サーバ端末は、前記イベントの開催条件を含む案内情報を、前記提案者が予め指定した参加候補者に関連する候補者端末に送信する送信部と、前記案内情報を受信した候補者端末から、前記イベントへの参加条件を含む応答情報を受信する受信部と、前記開催条件と前記参加条件とを照合してイベント開催の成否を判定する判定部と、を備える。【選択図】図８

Description

本発明は、所定のイベントに関する調整などの情報処理を行うイベント管理システムに関する。

例えば、企業が一般利用者などの参加者に対するイベントを提案する場合、地域拠点となる店舗などは、イベントの開催場所の提供が可能である。また、スポンサーとなる企業等は、当該イベントに商品・サービス・人などの提供が可能である。また、地域拠点となる店舗によるイベントの企画・開催なども同様に可能である。

上記開催される各種のイベントに関して、開催場所、日時、人、物など、各種の要素を調整する作業などが必要である。上記イベントの調整に関する従来技術としては、例えばイベント提案者（企業など）と、イベント開催場所の提供者（店舗など）との二者間の調整を行う情報処理システム等がある（特許文献１参照）。

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

しかしながら、特許文献１は、イベントの提案者とイベント開催のための場所（施設）の提供者との二者間での調整を可能とするものの、各者の希望・要求の条件をマッチングするような高度な調整の実現のためには好ましいものとは言えなかった。

そこで、本発明の目的は、イベントのマッチング（調整）をより高度に実現できるマッチングシステムを提供することである。

本発明の一態様における、ネットワークで接続される、所定のイベントを提案する提案者に関連する提案者側端末と、参加候補者に関連する候補者端末と、を仲介するサーバ端末により提供されるイベント管理システムであって、サーバ端末は、前記イベントの開催条件を含む案内情報を、前記提案者が予め指定した参加候補者に関連する候補者端末に送信する送信部と、前記案内情報を受信した候補者端末から、前記イベントへの参加条件を含む応答情報を受信する受信部と、前記開催条件と前記参加条件とを照合してイベント開催の成否を判定する判定部と、を備える。

本発明によれば、イベントのマッチング（調整）がより高度に実現され得る。

本発明の一実施形態に係るイベント管理システムを示すブロック構成図である。図１のサーバ端末１００の機能ブロック構成図である。図１の提案者端末２００を示す機能ブロック構成図である。サーバ端末１００に格納される開催条件情報１０００の一例を示す図である。サーバ端末１００に格納されるスケジュール情報２０００の一例を示す図である。サーバ端末１００に格納される予約情報３０００の一例を示す図である。サーバ端末１００に格納される会員情報４０００の一例を示す図である。本発明の一実施形態に係る、イベント管理処理に係るフローチャートの一例である。東京都渋谷区の栄湯で開催される「銭湯でもくもく会」というイベントの参加候補者である会員各々の候補者端末３００に表示される画面の一例である。候補者端末３００に表示される参加確認ページ５０００の一例である。イベント管理システム１が実行するイベント管理処理の具体的な流れを示す図解図である。本発明の一実施形態に係る、イベント管理処理に係るフローチャートの一例である。開催条件が設定されていてイベントが成立するタイミングの一例を示した表である。条件付き参加と回答した人が、参加成立するタイミング又は参加が確定するタイミングの一例を示した表である。用語の整理（言葉の意味）を示した表である。参加候補者であるＣとＦが同時に参加成立となるが、Ｃの方が回答が早いためＣが参加確定となるパターンを示した表である（ケース１）。参加候補者であるＣとＤが同じタイミングで参加成立となるが、Ｃの方が回答が早いためＣが参加確定となる。またFは定員オーバーで回答ができないパターンを示した表である（ケース２）。参加候補者であるＦが参加と回答するまで、誰も参加確定しない、またＥは定員オーバーになるため回答ができないパターンを示した表である（ケース３）。参加候補者であるＣは募集締め切りまで参加確定にならないパターンを示した表である（ケース４）。参加候補者であるＥが不参加になることでイベントの非開催が決定し、またＥが参加確定するまで、他のゲストは参加確定しないパターンを示した表である（ケース５）。参加候補者であるＦが参加確定するまで、他のゲストは参加確定しないパターンを示した表である（ケース６）。特定の人が参加なら参加と回答したが、すでに不参加と回答されている、また回答後に不参加と回答され、また募集期限になり最低参加人数で条件を満たさないことが確定し、不参加確定するパターンを示した表である（ケース７）。参加候補者であるＣはＥとＦが不参加でも募集期限までに友達が招待される可能性があるので、募集期限での不参加の確定になるパターンを示した表である（ケース８）。ＮＧリスト設定者が参加し、募集締め切りまで待たずに不参加確定するパターンを示した表である（ケース９）。参加候補者であるＦの参加を条件にするが、Ｆが回答できないためＢとＣがＦの回答を待たずに不参加確定となるパターンを示した表である（ケース１０）。参加候補者であるＤとＥはＦが参加となっても、定員オーバーで参加できないし、Ｆが不参加でもＢが参加しないから参加できないことになるので、回答した瞬間に不参加確定になるパターンを示した表である（ケース１１）。参加候補者であるＦが参加になることで、Ｂが参加になり、それによりＣが参加となり、Ｆが参加になることで、Ｄが参加となるパターンを示した表である（ケース１２）。

以下、本発明の一実施形態について図面を参照して説明する。なお、以下に説明する実施形態は、特許請求の範囲に記載された本開示の内容を不当に限定するものではない。また、実施形態に示される構成要素のすべてが、本開示の必須の構成要素であるとは限らない。

＜構成＞
図１は、本発明の一実施形態に係るイベント管理システムを示すブロック構成図である。イベント管理システム１は、所定のイベントを提案する提案者に関連する提案者端末２００と、所定のイベントの参加候補者に関連する候補者端末３００と、を仲介するサーバ端末１００と、により構成される。参加候補者は、サーバ端末１００により提供されるサービスに予め会員登録をしたユーザである。また、会員には提案者を含んでも良い。提案者もイベントの参加候補者となり得るし、イベントへの参加候補者も提案者になり得るからである。所定のイベントには、所定の地域又はこの所定の地域の近隣で開催される、各種のイベントであり、具体的には、祭り、花火大会、朝市、所定の店舗におけるバーゲン、花見等へ会員の外出を促すこと、会員を集めることが可能な各種のイベントが含まれる。

サーバ端末１００と、提案者端末２００及び候補者端末３００とは、ネットワークＮＷを介して接続される。ネットワークＮＷは、インターネット、イントラネット、無線ＬＡＮ（Local Area Network）又はＷＡＮ（Wide Area Network）等により構成される。

サーバ端末１００は、提案者から、提案者端末２００を通じて所定のイベントに関連する情報を受け付け、参加候補者から、候補者端末３００を通じて受け付けられる、所定のイベントに関連する情報に基づいて、イベントのマッチング（調整）を行う装置であり、例えば、ワークステーション又はパーソナルコンピュータのような汎用コンピュータとしてもよいし、或いはクラウド・コンピューティングによって論理的に実現されてもよい。本実施形態においては、説明の便宜上サーバ端末として１台を例示しているが、これに限定されず、複数台であってもよい。

提案者端末２００は、イベントの開催者又は関係者など、サーバ端末１００により提供されるサービスを利用する会員が所有する、例えば、パーソナルコンピュータ、タブレット端末等の情報処理装置であるが、スマートフォン、携帯電話、ＰＤＡ等により構成しても良い。

候補者端末３００は、上述の通り、祭り及び花火大会など各種イベントへの参加候補者であって、サーバ端末１００により提供されるサービスを利用する会員が所有する、例えば、パーソナルコンピュータ、タブレット端末等の情報処理装置であるが、スマートフォン、携帯電話、ＰＤＡ等により構成しても良い。

本実施形態では、イベント管理システム１は、サーバ端末１００と、提案者端末２００及び候補者端末３００とを備え、提案者または参加候補者が各々、提案者端末２００、候補者端末３００を利用して、サーバ端末１００に対する操作を行う構成として説明するが、サーバ端末１００がスタンドアローンで構成され、サーバ端末自身に、提案者または参加候補者が操作を行う機能を備えても良い。

図２は、図１のサーバ端末１００の機能ブロック構成図である。サーバ端末１００は、通信部１１０（送信部及び受信部）と、記憶部１２０と、制御部１３０とを備える。

通信部１１０は、ネットワークＮＷを介して提案者端末２００及び候補者端末３００と通信を行うための通信インターフェースであり、例えばＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）等の通信規約により通信が行われる。

記憶部１２０は、各種制御処理又は制御部１３０内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等から構成される。また、記憶部１２０は、提案者に関連する各種データを格納する、提案者データ格納部１２１、参加候補者に関連する各種データを格納する、参加候補者データ格納部１２２等を有する。さらに、記憶部１２０は、提案者端末２００、候補者端末３００と通信を行ったデータを一時的に記憶することもできる。なお、各種データを格納したデータベース（図示せず）が記憶部１２０またはサーバ端末１００外に構築されていてもよい。

制御部１３０は、記憶部１２０に記憶されているプログラムを実行することにより、サーバ端末１００の全体の動作を制御するものであり、ＣＰＵ（Central Processing Unit）又はＧＰＵ（Graphics Processing Unit）等から構成される。制御部１３０の機能としては、提案者端末２００又は候補者端末３００からの指示を受け付ける指示受付部１３１と、提案者に関連する各種データを参照し、処理する、提案者データ管理部１３２と、参加候補者に関連する各種データを参照し、処理する、参加候補者データ管理部１３３と、イベント開催の成否を判定する、マッチング処理部１３４（判定部）等を有する。この指示受付部１３１、提案者データ管理部１３２、参加候補者データ管理部１３３、マッチング処理部１３４は、記憶部１２０に記憶されているプログラムにより起動されてコンピュータ（電子計算機）であるサーバ端末１００により実行される。

指示受付部１３１は、サーバ端末１００が提供し、提案者端末２００又は候補者端末３００において、ウェブブラウザまたはアプリケーションを介して表示される画面等のユーザインターフェースを介して、提案者または参加候補者であるユーザが、（キーワードを入力したり、アイコンを押下する等したりして）所定の要求を行ったとき、提案者端末２００又は候補者端末３００から通信部１１０を介して指示を受付ける。

提案者データ管理部１３２は、提案者に関連する各種データ（例えば、会員ＩＤ、氏名、住所、Ｅメールアドレス等の連絡先、その他ＳＮＳアカウント情報等）を管理し、処理を行う。

参加候補者データ管理部１３３は、参加候補者に関連する各種データ（例えば、ユーザの氏名、住所、Ｅメールアドレス等の連絡先、その他ＳＮＳアカウント情報等）を管理し、処理を行う。

マッチング処理部１３４は、提案者の求めに応じてイベント開催の成否を判定する処理を行う。

図３は、図１の提案者端末２００を示す機能ブロック構成図である。提案者端末２００は、通信部２１０と、表示操作部２２０と、記憶部２３０と、制御部２４０とを備える。

通信部２１０は、ネットワークＮＷを介してサーバ端末１００と通信を行うための通信インターフェースであり、例えばＴＣＰ／ＩＰ等の通信規約により通信が行われる。

表示操作部２２０は、提案者が指示を入力し、制御部２４０からの入力データに応じてテキスト、画像等を表示するために用いられるユーザインターフェースである。提案者端末２００がパーソナルコンピュータで構成されている場合はディスプレイとキーボード及びマウスにより構成される。提案者端末２００がスマートフォンまたはタブレット端末で構成されている場合はタッチパネル等から構成される。この表示操作部２２０は、記憶部２３０に記憶されている制御プログラムにより起動されてコンピュータ（電子計算機）である提案者端末２００により実行される。

記憶部２３０は、各種制御処理又は制御部２４０内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、ＲＡＭ又はＲＯＭ等から構成される。また、記憶部２３０は、サーバ端末１００との通信内容を一時的に記憶している。

制御部２４０は、記憶部２３０に記憶されているプログラムを実行することにより、提案者端末２００の全体の動作を制御するものであり、ＣＰＵ又はＧＰＵ等から構成される。

なお、サーバ端末１００が表示操作部の機能を備える構成としても良く、この場合、提案者端末２００を備えない構成としても良い。

なお、候補者端末３００の機能構成についても、提案者端末２００と実質同一であるので、説明を省略する。

図４は、サーバ端末１００に格納される開催条件情報の一例を示す図である。

図４に示す開催条件情報１０００には、所定のイベント（例えば、毎年１回、毎月１回、毎週１回などのように、定期的に開催されるイベント）の開催条件が登録されている。図４に示されるように、開催条件情報１０００には、イベントごとに、対応する「イベント名」、「開催日時条件」、「施設条件」などの情報が含まれる。「イベント名」は、イベントの名前である。「開催日時条件」は、イベントを開催すべき日時に関する条件である。例えば、「月例飲み会」のイベントは、毎月２５日〜３１日の平日の午後６時に開催される。また例えば、「新年会」のイベントは、毎年１月の６日〜１５日の平日の午後６時に開催される。「施設条件」は、イベントで利用すべき施設（飲食店）に関する条件である。例えば、「月例飲み会」のイベントには店舗Ａが利用される。また、「新年会」のイベントは、ホテルのレストランが利用される。なお、「施設条件」には、施設に関する一又は複数の属性情報（例えば、名前、場所、業態、予算など）に関する条件が含まれていてもよい。開催条件情報１０００は、例えば、提案者端末２００における提案者の操作に応じて、サーバ端末１００の制御部１３０によって随時更新される。

図５は、サーバ端末１００に格納されるスケジュール情報の一例を示す図である。

図５に示すスケジュール情報２０００には、イベントの参加候補者である複数のユーザの各々の予定（例えば、イベント）が登録されている。図５に示されるように、スケジュール情報２０００には、予定ごとに、対応する「会員名」、「タイトル」、「日付」、「時間帯」などの情報が含まれる。「会員名」は、その予定に対応する会員の名前である。なお、「会員名」の代わりに、会員を識別可能なＩＤが使用されてもよい。「タイトル」は、その予定の内容を示すタイトルである。「日付」は、その予定が入っている日時である。「時間帯」は、その予定が入っている時間帯である。例えば、会員Ｂは、２０２０年３月２４日から翌々日の２６日まで「出張」の予定が入っている。スケジュール情報２０００は、例えば、候補者端末３００における参加候補者の操作に応じて、サーバ端末１００の制御部１３０によって随時更新される。

図６は、サーバ端末１００に格納される予約情報の一例を示す図である。

予約情報３０００には、施設ごとの予約状況が登録されている。予約情報３０００は、例えば、施設ごとに生成される。図６は、店舗Ａの予約情報３０００を示している。図６に示されるように、予約情報３０００には、受け付けられた予約ごとに、対応する「予約者名」、「来店日時」、「人数」、「テーブル」などの情報が含まれる。「予約者名」は、例えば、イベントを提案した提案者（来店するグループの代表者）の名前である。「来店日時」は、そのグループが来店する日時である。「人数」は、そのグループの人数である。「テーブル」は、そのグループに割り当てられるテーブルである。予約情報３０００は、例えば、各施設において新規の予約が受け付けられるごとに、提案者端末２００における提案者の操作に応じて、サーバ端末１００の制御部１３０によって随時更新される。

図７は、サーバ端末１００に格納される会員情報の一例を示す図である。

図７に示す会員情報４０００には、イベントの提案者又は参加候補者である複数の会員の各々に関する情報が登録されている。図７に示されるように、会員情報４０００には、会員ごとに、対応する「会員名」、「連絡先」などの情報が含まれる。「会員名」は、そのユーザの名前である。なお、「会員名」の代わりに、会員を識別可能なＩＤが使用されてもよい。「連絡先」は、その会員が使用しているＥメールアドレス等の連絡先である。「会員名」及び「連絡先」は、提案者端末２００又は候補者端末３００における特定の会員の操作に応じて、サーバ端末１００の制御部１３０によって登録される。

なお、開催条件情報１０００、スケジュール情報２０００、会員情報４０００の一部又は全部が、サーバ端末１００、提案者端末２００、候補者端末３００からネットワークＮＷを介してアクセス可能な他のサーバに記憶されていることも考えられる。この場合、サーバ端末１００の制御部１３０は、提案者端末２００、候補者端末３００又は前記他のサーバから前記情報を適宜に取得して、後述のイベント管理処理を実行してもよい。

＜処理の流れ＞
図８を参照しながら、本実施形態のイベント管理システム１が実行するイベント管理処理の流れについて説明する。図８は、本発明の一実施形態に係る、イベント管理処理に係るフローチャートの一例である。

ここで、イベント管理システム１を利用するために、提案者及び／または参加候補者は、提案者端末２００、候補者端末３００各々のウェブブラウザまたはアプリケーション等を利用してサーバ端末１００にアクセスする。一方、初めてサービスを利用する場合は、提案者及び／または参加候補者は、前述の提案者基本情報等、参加候補者基本情報等を各々入力する。一方、既に提案者、参加候補者のアカウントが取得済みの場合は、例えばＩＤとパスワードを入力する等の所定の認証を受けてログインすることで、サービスが利用可能となる。この認証後、ウェブサイト、アプリケーション等を介して所定のユーザインターフェースが提供され、図８に示すステップＳ１０１へ進む。

まず、ステップＳ１０１の処理として、提案者端末２００の制御部２４０は、イベントの開催条件を示す開催条件情報１０００（図４）、イベントの参加候補者である会員各々の予定を示すスケジュール情報２０００（図５）、及びイベントで利用される施設の空き状況を示す予約情報３０００（図６）の少なくともいずれか１つに基づいて、イベントの開催候補日時を自動的に設定する。例えば、制御部２４０は、開催条件情報１０００に登録されているイベントごとに、開催条件情報１０００の「開催日時条件」に示されている一又は複数の日のうちの最先の日から予め定められた日数だけ遡った時点で、そのイベントの開催候補日時を設定する。

図９は、東京都渋谷区の栄湯で開催される「銭湯でもくもく会」というイベントの参加候補者である会員各々の候補者端末３００に表示される画面の一例である。図９に示すように、このイベントの提案者であるＡ（ハンドルネームでにしみやと名乗る会員）に関する提案者端末２００は、２０１９年１１月２３日（土）から３４日だけ遡った日時（すなわち、２０１９年１０月２０日（日））になった時点で、「銭湯でもくもく会」のイベントの開催候補日時を自動的に２０１９年１１月２３日（土）に設定する。

開催候補日時の設定方法としては、種々の方法が考えられる。例えば、制御部２４０は、スケジュール情報２０００に基づいて、開催条件情報１０００の「開催日時条件」を満たす日時のうち、一定数以上又は一定割合以上の会員の予定が空いている日時を開催候補日時として設定してもよい。また例えば、制御部２４０は、開催条件情報１０００の「施設条件」において特定の施設が指定されている場合に、その施設の予約情報３０００に基づいて、開催条件情報１０００の「開催日時条件」を満たす日時のうち、その施設を利用可能な日時を開催候補日時として設定してもよい。

制御部２４０は、イベントを提案する提案者の操作に基づいて、そのイベントへの参加候補者を指定する。例えば、「銭湯でもくもく会」のイベントの場合、提案者であるＡに関する提案者端末２００は、Ｂ〜Ｆの５人を参加候補者として指定する。また、「銭湯でもくもく会」の開催条件には、例えば、イベントの参加人数が所定人数以上であること、イベントに特定の参加候補者が参加すること等が含まれる。具体的に、「銭湯でもくもく会」のイベントは、３人以上の会員が参加する場合であって、かつ、特定の参加候補者であるＢが参加する場合に開催される。

次に、ステップＳ１０２の処理として、サーバ端末１００は、通信部１１０を介して、所定のイベントの開催条件情報を含む案内情報を、提案者が予め指定した参加候補者を示す情報とともに提案者端末２００から受信する。例えば、「銭湯でもくもく会」のイベントの場合、イベントの開催に必要な人数を示す最低必要人数情報として「３」が、イベントの開催に必須の必須参加候補者情報として「Ｂ」が開催条件情報として受信される。このとき受信した開催条件情報は記憶部１２０に格納される。

次に、ステップＳ１０３の処理として、サーバ端末１００は、通信部１１０を介して、イベントの開催条件を含む案内情報を、提案者が予め指定した参加候補者に関連する候補者端末３００に送信する。例えば、サーバ端末１００の制御部１３０は、会員情報４０００（図７）に登録されている「連絡先」に基づいて、図１０に示されるような参加確認ページ５０００にアクセスするためのアクセス情報（例えば、ＵＲＬなど）を、Ｅメールにより各会員に通知する。そのＥメールを受信した会員は、前記アクセス情報に基づいて、自身の候補者端末３００から参加確認ページ５０００にアクセスすることができる。

図１０は、候補者端末３００に表示される参加確認ページ５０００の一例である。参加確認ページ５０００には、対象イベントのイベント名（ここでは、「銭湯でもくもく会」）が表示される。また、参加確認ページ５０００には、対象イベント「銭湯でもくもく会」に対し、候補者端末３００における候補者の操作に応じて参加条件情報を入力可能な確認欄Ｆ１０が設けられている。本実施形態において、参加条件情報は、イベントの提案者には非公開な情報である。この確認欄Ｆ１０には、対象イベントごとに、出席（参加）に対応する選択領域Ｒ１０と、欠席（不参加）に対応する選択領域Ｒ２０とが表示される。会員は、対象イベントごとに、選択領域Ｒ１０又は選択領域Ｒ２０を操作（例えば、クリック、タッチなど）することによって、いずれか一方を択一的に選択することができる。

上述した参加条件には、例えば、イベントへの参加を表明した参加候補者の中に特定の参加候補者が含まれること、イベントへの参加が確定した参加候補者の人数が所定人数以上であること等が含まれる。

図１１は、イベント管理システム１が実行するイベント管理処理の具体的な流れを示す図解図である。図１１に示すように、参加候補者Ｃの参加条件には、「銭湯でもくもく会」への参加を表明した参加候補者の中に参加候補者Ｄが含まれることが入っている。参加候補者Ｅの参加条件には、「銭湯でもくもく会」への参加を表明した参加候補者の中に参加候補者Ｂが含まれることが入っている。参加候補者Ｄの参加条件には、「銭湯でもくもく会」への参加が確定した参加候補者の人数が５名以上であることが含まれている。

次に、ステップＳ１０４の処理として、候補者端末３００における候補者の操作に応じて確認欄Ｆ１０に参加条件が入力されると、その参加条件情報を含む応答情報が、候補者端末３００から通信部１１０を介してサーバ端末１００に送信される。

次に、ステップＳ１０５の処理として、サーバ端末１００のマッチング処理部１３４は、記憶部１２０に記憶されている開催条件情報と、応答情報に含まれる参加条件情報とを照合してイベント開催の成否を判定する。具体的には、マッチング処理部１３４は、参加条件情報を受け取ると、記憶部１２０から最低必要人数情報「３」と、必須参加候補者情報「Ｂ」とを読み出し、当該読み出した情報と、参加条件情報とを照合しつつイベント開催の成否を判定する。

ここで、マッチング処理部１３４によるイベント開催の成否判定処理については、いくつかの方法が考えられるが、以下ではその一例を用いて詳述する。図１２は、本発明の一実施形態に係る、イベント管理処理に係るフローチャートの一例である。

まず、ステップＳ２０１の処理として、サーバ端末１００において、通信部１１０は、候補者端末３００から応答情報を受信すると（ステップＳ２０１におけるＹＥＳ）、当該受信した応答情報内に参加条件情報が含まれていた場合には（ステップＳ２０２におけるＹＥＳ）、その参加条件情報を読み出す（ステップＳ２０３）。ここで、サーバ端末１００において、応答情報を通信部１１０から受け取ったマッチング処理部１３４は、応答情報の受信回数としての変数「Ｋ（初期値「０」）」を１だけインクリメントする（ステップＳ２０４）。

そして、マッチング処理部１３４は、記憶部１２０から読み出した必須参加候補者の会員名「Ｂ」と、応答情報に紐付けられた参加候補者の会員名「Ｂ」とが一致し、かつ、会員名「Ｂ」の来否情報が「欠席（不参加）」であった場合には（ステップＳ２０５におけるＹＥＳ）、通信部１１０に開催中止情報の送信要求を出力する（ステップＳ２０６）。そして、サーバ端末１００において、通信部１１０は、「銭湯でもくもく会」の提案者であるＡに関する提案者端末２００と、その参加候補者であるＢ〜Ｆ全員の候補者端末３００に開催中止情報を、ネットワークＮＷを介して送信する（ステップＳ２０７）。

一方、マッチング処理部１３４は、記憶部１２０から読み出した必須参加候補者の会員名「Ｂ」と、応答情報に紐付けられた参加候補者の会員名「Ｂ」とが一致し、かつ、来否情報が「出席（参加）」であった場合には（ステップＳ２０５におけるＮＯに続いてステップＳ２０８におけるＹＥＳ）、必須参加候補者「Ｂ」の現参加者数としての変数「Ｌ（初期値「０」）」を１だけインクリメントする（ステップＳ２０９）。

また、一方で、マッチング処理部１３４は、記憶部１２０から読み出した必須参加候補者の会員名「Ｂ」と、応答情報に紐付けられた参加候補者の会員名「Ｂ」とが一致せず（ステップＳ２０５におけるＮＯに続いてステップＳ２０８におけるＮＯ）、来否情報が「出席（参加）」であった場合には（ステップＳ２１０におけるＹＥＳ）、必須参加候補者以外の参加候補者「Ｃ」〜「Ｆ」の現参加者数としての変数「Ｍ（初期値「０」）」を１だけインクリメントする（ステップＳ２１１）。

そして、マッチング処理部１３４は、各変数いずれかをインクリメントした後（ステップＳ２０９またはステップＳ２１１）、もしくは、記憶部１２０から読み出した必須参加候補者の会員名「Ｂ」と、応答情報に紐付けられた参加候補者の会員名「Ｂ」とが一致せず、来否情報が「欠席（不参加）」である場合に（ステップＳ２１０におけるＮＯ）、現参加者の人数「Ｌ＋Ｍ」と、最低必要人数「３」との大小を比較する（ステップＳ２１２）。ここで、マッチング処理部１３４は、「Ｌ＋Ｍ」が「３」と等しい、あるいは、「３」よりも大きい場合に（ステップＳ２１２におけるＹＥＳ）、通信部１１０に開催決定情報の送信要求を出力する（ステップＳ２１３）。そして、サーバ端末１００において、通信部１１０は、「銭湯でもくもく会」の提案者であるＡに関する提案者端末２００と、その参加候補者であるＢ〜Ｆ全員の候補者端末３００に開催決定情報を、ネットワークＮＷを介して送信する（ステップＳ２１４）。

ここで、参加候補者Ｃの参加条件には、「銭湯でもくもく会」への参加を表明した参加候補者の中に参加候補者Ｄが含まれることが入っている。したがって、参加候補者Ｄの来否情報が「出席（参加）」であった場合には（ステップＳ２１０におけるＹＥＳ）、サーバ端末１００において、通信部１１０は、「銭湯でもくもく会」の参加候補者Ｃに関する候補者端末３００に開催決定情報を示す参加フラグを、ネットワークＮＷを介して送信する（ステップＳ２１４）。

同様に、参加候補者Ｅの参加条件には、「銭湯でもくもく会」への参加を表明した参加候補者の中に参加候補者Ｂが含まれることが入っている。したがって、参加候補者Ｂの来否情報が「出席（参加）」であった場合には（ステップＳ２０５におけるＮＯに続いてステップＳ２０８におけるＹＥＳ）、サーバ端末１００において、通信部１１０は、「銭湯でもくもく会」の参加候補者Ｅに関する候補者端末３００に開催決定情報を示す参加フラグを、ネットワークＮＷを介して送信する（ステップＳ２１４）。

また、参加候補者Ｄの参加条件には、「銭湯でもくもく会」への参加が確定した参加候補者の人数が５名以上であることが含まれている。したがって、現参加者の人数「Ｌ（参加確定ユーザの人数）＋Ｍ（条件付き参加見込ユーザの人数）」が５以上の場合に（ステップＳ２１２におけるＹＥＳ）、サーバ端末１００において、通信部１１０は、「銭湯でもくもく会」の参加候補者Ｄに関する候補者端末３００に開催決定情報を示す参加フラグを、ネットワークＮＷを介して送信する（ステップＳ２１４）。

ステップＳ２１２に戻って、マッチング処理部１３４は、「Ｌ＋Ｍ」が「３」より小さい場合（ステップＳ２１２におけるＮＯ）、現参加者の人数「Ｌ＋Ｍ」と、参加候補者Ｂ〜Ｆ全員の人数「５」より「Ｋ」を差し引くことで未回答数を表した数「５−Ｋ」との和「（Ｌ＋Ｍ）＋（５−Ｋ）」と、最低必要人数「３」との大小を比較する（ステップＳ２１５）。ここで、マッチング処理部１３４は、「（Ｌ＋Ｍ）＋（５−Ｋ）」が「３」より小さい場合には（ステップＳ２１５におけるＹＥＳ）、未回答の参加候補者が全て参加を表明しても最低必要人数「３」を超さない結果、これ以上の応答を待つ必要がないので、通信部１１０に開催中止情報の送信要求を出力する（ステップＳ２１６）。

そして、サーバ端末１００において、通信部１１０は、参加候補者であるＢ〜Ｆ全員に関する候補者端末３００に開催中止情報を、ネットワークＮＷを介して送信する（ステップＳ２１７）。なお、「（Ｌ＋Ｍ）＋（５−Ｋ）」が「３」より大きい場合には（ステップＳ２１５におけるＮＯ）、未回答の参加候補者による参加表明によっては最低必要人数「３」を超す結果、引き続き応答を待つ必要があるので、応答情報の受信を待機する（ステップＳ２０１）。

このように、本実施形態によれば、イベントのマッチング（調整）がより高度に実現され得る。特に、イベントの提案者及び参加候補者がイベントの希望・要求の条件を指定できるので、当該条件下での高度なマッチングを実現できる。これにより、イベント開催のリスクを効果的に低減することができる。

また、イベントの提案者が参加候補者をイベントに勧誘すること、又は、イベントへの勧誘に対する回答をメッセージレス、かつ条件付きで行うことができるので、本音を言えず返事を躊躇すること、又は、勧誘したとしても断られるという不安を払拭することができる。

また、イベントへの条件付き参加見込ユーザの間でメッセージ等を交換したりすることができるので、イベント開催のために必要なコミュニケーションを円滑にすることができる。

以上、開示に係る実施形態について説明したが、これらはその他の様々な形態で実施することが可能であり、種々の省略、置換および変更を行なって実施することが出来る。これらの実施形態および変形例ならびに省略、置換および変更を行なったものは、特許請求の範囲の技術的範囲とその均等の範囲に含まれる。

なお、サーバ端末１００は、所定のイベントを提案する及び当該提案者が高頻度で当該イベントに招待している参加候補者を一又は二以上のグループに分けたグループ単位で情報交換可能に設定する設定部を備えるものであってもよい。グループとは、例えば、「大学サークルグループ、大学ゼミグループ、会社同僚グループ、高校同級生グループ等であり、これらのグループ単位で情報交換可能に設定してある。したがって、グループ内でＳＮＳなどによるチャットを行ったり、メッセージ又は写真等を交換したりする等、情報交換をスムーズに進めることができる。

図１６〜図２７は、参加候補者の参加条件のバリエーションを示した説明図である。ここで、オーナー側の人数のカウント、すなわち、ゲストの数のみの人数であって、定員が３名のイベントの参加者は４名になるようにカウントするものとし、ゲスト側の人数のカウント、すなわち、オーナーとゲストの足した人数、最低３名以上なら参加と回答する場合、そのイベントは３名以上になるようにカウントすることを前提条件とする。

１イベント管理システム、１００サーバ端末、１１０通信部（送信部及び受信部）、１２０記憶部、１３０制御部、１３４マッチング処理部（判定部）、２００提案者端末、３００候補者端末、ＮＷネットワーク

Claims

ネットワークで接続される、所定のイベントを提案する提案者に関連する少なくとも１つの提案者側端末と、参加候補者に関連する複数の候補者端末と、前記提案者側端末と前記複数の候補者端末とをマッチングするサーバ端末と、を備えたイベント管理システムであって、
前記サーバ端末により提供されるサービスに予め登録した会員は、前記提案者にも前記参加候補者にもなり得るものであって、
サーバ端末は、
前記イベントの開催条件を含むとともに、飲食場所又は遊興場所を含む案内情報を、前記提案者が予め指定した参加候補者に関連する前記複数の候補者端末に送信する送信部と、
前記案内情報を受信した前記複数の候補者端末のそれぞれから、他の参加候補者による前記イベントへの参加表明の有無を含む参加条件を含む応答情報を受信する受信部と、
前記開催条件と前記参加条件とを照合してイベント開催の成否を判定する判定部と、を備え、
前記送信部は、前記判定部が判定したイベント開催の成否を前記複数の候補者端末と前記提案者側端末とに送信する、
イベント管理システム。
前記開催条件には、前記イベントの参加人数が所定人数以上であることが含まれる、請求項１に記載のイベント管理システム。
前記開催条件には、前記イベントに特定の必須参加候補者が参加することが含まれる、請求項１に記載のイベント管理システム。
前記判定部は、前記受信部が受信した複数の応答情報に基づいて、前記参加条件を満たすと判断し、且つイベント開催を決定したとき、前記参加条件を含む応答情報を送信した候補者端末に開催決定を送信させる、請求項１に記載のイベント管理システム。
前記参加条件は、前記イベントへの参加を表明した参加候補者の中に特定の参加候補者が含まれるか否かに関するものある、請求項１に記載のイベント管理システム。
前記参加条件には、前記イベントへの参加を表明した参加候補者の人数が所定人数以上か否かに関するものである、請求項１に記載のイベント管理システム。
さらに、前記サーバ端末は、前記提案者及び当該提案者が高頻度で前記イベントに招待している参加候補者を一又は二以上のグループに分けたグループ単位で情報交換可能に設定する設定部を備える、請求項１に記載のイベント管理システム。