JP2022126408A - 情報処理方法、情報処理装置、及び、プログラム - Google Patents

Abstract

【課題】イベントの企画に対する心理的ハードルを低下させる情報処理方法、情報処理装置及びプログラムを提供する。【解決手段】イベント企画システム１００における情報処理方法であって、センターサーバ１は、第１のユーザのユーザ端末２から、第１のユーザが主催する所定の活動の企画に関する情報の公開を要求する公開要求と、複数のユーザのうち、第１のユーザによって所定の活動の運営への参加の依頼先として指定される１又は複数の第２のユーザの識別情報とを受信し、所定の活動の企画に関する情報を第１のウェブサイトに公開し、１又は複数の第２のユーザのユーザ端末へ、所定の活動の運営への参加依頼を送信する。【選択図】図１

Description

本開示は、情報処理方法、情報処理装置、及び、プログラムに関する。

配信希望者の通信端末に、イベントの開催に関する告知情報を配信し、当該イベントへの参加を希望する参加希望者の通信端末から、当該イベントへの申込情報を取得したことに応じて、決済処理又は与信枠を確保する技術が開示されている（例えば、特許文献１）。

特開２０１８－２０６０４１号公報

イベントを企画する場合には、例えば、企画前に当該イベントを共に運営する仲間を集めたりしなければならず、イベントの企画のハードルが高いことがある。

本開示は、イベントの企画に対する心理的ハードルを低下させることができる情報処理方法、情報処理装置、及び、プログラムを提供することを課題とする。

本開示の態様の一つは、
第１のユーザのユーザ端末から、前記第１のユーザが主催する所定の活動の企画に関する情報の公開を要求する公開要求と、複数のユーザのうち、前記第１のユーザによって前記所定の活動の運営への参加の依頼先として指定される１又は複数の第２のユーザの識別情報と、を受信することと、
前記所定の活動の企画に関する情報を第１のウェブサイトに公開することと、
前記１又は複数の第２のユーザのユーザ端末へ、前記所定の活動の運営への参加依頼を送信することと、
を含む情報処理方法である。

本開示の他の態様の一つは、
第１のユーザのユーザ端末から、前記第１のユーザが主催する所定の活動の企画に関する情報の公開を要求する公開要求と、複数のユーザのうち、前記第１のユーザによって前記所定の活動の運営への参加の依頼先として指定される１又は複数の第２のユーザの識別情報と、を受信することと、
前記所定の活動の企画に関する情報を第１のウェブサイトに公開することと、
前記１又は複数の第２のユーザのユーザ端末へ、前記所定の活動の運営への参加依頼を送信することと、
を実行する制御部、
を備える情報処理装置である。

本開示の他の態様の一つは、
コンピュータに、
第１のユーザが主催する所定の活動の企画に関する情報の公開を要求する公開要求と、複数のユーザのうち、前記所定の活動の運営への参加の依頼先としての１又は複数の第２の
ユーザの指定と、の入力を受け付けることと、
所定のサーバへ、前記公開要求と、前記１又は複数の第２のユーザの識別情報とを送信することと、
を実行させるためのプログラムであって、
前記所定のサーバは、
前記所定の活動の企画に関する情報を第１のウェブサイトに公開することと、
前記１又は複数の第２のユーザのユーザ端末へ、前記所定の活動の運営への参加依頼を送信することと、
を実行する、
プログラムである。

本開示によれば、イベントの企画に対する心理的ハードルを低下させることができる。

図１は、第１実施形態に係るイベント企画システムのシステム構成の一例を示す図である。 図２は、センタサーバ及びユーザ端末のハードウェア構成の一例である。 図３は、センタサーバ及びユーザ端末の機能構成の一例を示す図である。 図４は、ユーザ情報データベースに保持される情報の一例を示す図である。 図５は、イベント情報データベースに保持される情報の一例である。 図６は、イベントの状態遷移の一例を示す図である。 図７は、ユーザ端末のユーザ登録画面の一例である。 図８は、ユーザ端末のプロフィール画面の一例である。 図９は、ユーザ端末のお気に入りリソース一覧表示画面の一例である。 図１０は、ユーザ端末のイベント登録画面の一例である。 図１１は、ユーザ端末のユーザ検索画面の一例である。 図１２は、ユーザ端末の運営オファー一覧画面の一例である。 図１３は、ユーザ端末のイベント一覧画面の一例である。 図１４は、ユーザ端末の処理のフローチャートの一例である。 図１５は、センタサーバの処理のフローチャートの一例である。 図１６は、センタサーバのイベント管理処理のフローチャートの一例である。 図１７は、イベント企画システムにおけるイベントが起案されてから開催が決定するまでの処理のシーケンス図の一例である。

本開示の態様の一つは、第１のユーザのユーザ端末から、第１のユーザが主催する所定の活動の企画に関する情報の公開を要求する公開要求と、複数のユーザのうち、第１のユーザによって所定の活動の運営への参加の依頼先として指定される１又は複数の第２のユーザの識別情報と、を受信することと、所定の活動の企画に関する情報を第１のウェブサイトに公開することと、１又は複数の第２のユーザのユーザ端末へ、所定の活動の運営への参加依頼を送信することと、を含む情報処理方法である。

当該情報処理方法は、情報処理装置によって実行される。情報処理装置は、例えば、サーバ等のコンピュータである。当該サーバは、例えば、ウェブサーバであってもよい。情報処理装置は、例えば、プロセッサ等の制御部を備えており、当該制御部が情報処理方法を実行する。第１のユーザが主催する所定の活動は、例えば、所定の場所に所定人数を集めて行われるイベント、ウェブで配信されるイベント、及び、クラウドファンディング等である。イベントには、例えば、食事会、体験会、相談会、講演会、教室、演奏会、及び
、ツアー等がある。

本開示の態様の一つによれば、第１のユーザは、所定の活動の企画をする際に、共に運営に参加してもらいたい第２のユーザを指定することによって、上述の情報処理装置によって当該第２のユーザへ参加依頼を送信することができる。第１のユーザは、直接第２のユーザへアクセスせずに、所定の活動への参加を依頼することができるため、所定の活動の企画に対する心理的ハードルを下げることができる。

本開示の態様の一つにおいて、１又は複数の第２のユーザの指定は、複数のユーザのいずれのユーザに対しても可能であるようにしてもよい。すなわち、第１のユーザと第２のユーザ間で、互いに認識がなくても、第１のユーザは第２のユーザに所定の活動への参加を依頼することができる。第１のユーザは事前に第２のユーザと関係を築いていなくても、第２のユーザを運営に参加してもらう候補として指定して所定の活動の企画をすることができ、所定の活動を気軽に企画することができる。また、面識のない人にも運営への参加を依頼することができ、人との出会いのきっかけの一つにもなる。

本開示の態様の一つの情報処理方法は、複数のユーザそれぞれについて、ユーザに関するユーザ情報の一つとして、リソース情報を記憶部に保持することと、複数のユーザそれぞれについて、リソース情報を第１のウェブサイトに公開することと、をさらに含んでもよい。この場合には、所定の活動の企画に関する情報は、第１のユーザに関連付くリソース情報のうちの少なくとも１つを含んでもよい。リソース情報は、ユーザの、興味関心、及び、提供可能なスキルに関連のある、場所、物、及び、事を含んでもよい。

本開示の態様の一つでは、所定の活動は、各ユーザの興味関心、及び、提供可能なスキルに関連のある、場所、物、及び、事に基づいて、企画、公開、及び開催される。これによって、所定の活動を通じて、当該所定の活動に関連するリソース情報に共感した人と当該所定の活動を運営及び実施することができる。また、所定の活動に参加する人は、当該所定の活動に関連するリソース情報に共感した人であるので、これまでにはつながりのなかった人と出会え、自身の世界を広げることができる。

また、本開示の態様の一つにおいて、第２のユーザは、第１のユーザによって指定されるリソース情報による検索結果から選択されたユーザであってもよい。これによって、所定の活動の運営をともに行う人を、所定の活動に関連するリソース情報に共感する人の中から選択することができる。

また、本開示の態様の一つの情報処理方法は、第３のユーザのユーザ端末から、他のユーザについて公開されている第１のリソース情報の記録を要求する記録要求と、第１のリソース情報とを受信することと、第３のユーザのユーザ情報と第１のリソース情報とを関連付けて、記憶部に記録することと、をさらに含んでもよい。これによって、第３のユーザが気になった他のユーザのリソース情報を集めて蓄積することができる。蓄積された他のユーザのリソース情報は、例えば、第３のユーザが所定の活動を企画する際に、運営に参加してもらいたい候補を指名する場合の参照に用いられてもよい。

また、本開示の態様の一つの情報処理方法は、第２のユーザのユーザ端末すべてから、所定の活動の運営への参加依頼に対して、参加の承諾の応答を受けた場合に、所定の活動の企画の成立を判定して公開し、第２のユーザのユーザ端末のうちの少なくとも１つから、参加の拒否の応答を受けた場合に、所定の活動の企画の不成立を判定して公開することをさらに含んでもよい。本開示の態様の一つでは、第２のユーザの少なくともいずれかが運営への参加を拒否した場合には、所定の活動の企画が成立しない。そのため、本開示の態様の一つでは、例えば、企画が成立してから運営への参加を依頼された場合よりも、第
２のユーザが運営への参加を断りやすく、第２のユーザにとっても、所定の活動の企画に対する心理的ハードルを下げることができる。

本開示の態様の一つの情報処理方法は、所定の活動の企画が成立した後に、第１のユーザのユーザ端末と１又は複数の第２のユーザのユーザ端末間でメッセージ交換を許可することをさらに含んでもよい。これによって、企画成立前の、所定の活動を主催する第１のユーザと運営への参加を依頼される第２のユーザ間の交流を抑制することができ、例えば、第２のユーザが運営への参加の依頼を断りやすくすることができる。これによって、所定の活動の企画に対する心理的ハードルを下げることができる。

本開示の態様の一つの情報処理方法は、公開された所定の活動の企画に対して、第４のユーザのユーザ端末から、第４のユーザがスタッフとして参加を所望していることを示す参加要求を受信することと、第４のユーザの数が所定数に達した場合に、所定の活動の開催決定を判定して公開し、第４のユーザの数が所定数に達しない場合には、所定の活動の開催のキャンセルを判定して公開することと、をさらに含んでもよい。本開示の態様の一つでは、所定の活動の企画の開催決定は、開催場所や予算等を確保しているか否かに関わらず、第４のユーザが所定数に達しているか否かに応じて判定される。これによって、第１のユーザは、所定の活動の開催決定のために、開催場所や予算等を確保するために行動しなくてよく、例えば、所定の活動の開催が決定してから、すなわち、参加者が十分に集まってから、場所や予算等の確保にうつることができる。これによって、イベントの企画等に対する心理的ハードルを下げることができる。

本開示は、他の態様の一つとして、ユーザ端末に搭載されるアプリケーションプログラムとして特定することができる。当該プログラムは、コンピュータに、第１のユーザが主催する所定の活動の企画に関する情報の公開を要求する公開要求と、複数のユーザのうち、所定の活動の運営への参加の依頼先としての１又は複数の第２のユーザの指定と、の入力を受け付けることと、所定のサーバへ、公開要求と、１又は複数の第２のユーザの識別情報とを送信することと、を実行させる。当該所定のサーバは、上述の情報処理方法を実行する。当該プログラムを実行するコンピュータは、例えば、スマートフォン、ＰＣ（Personal Computer）、タブレット端末等のユーザ端末である。

以下、図面に基づいて、本開示の実施の形態を説明する。以下の実施形態の構成は例示であり、本開示は実施形態の構成に限定されない。

＜第１実施形態＞
図１は、第１実施形態に係るイベント企画システム１００のシステム構成の一例を示す図である。イベント企画システム１００は、イベントの、企画、スタッフ募集、及び、参加募集を行うＳＮＳ（ソーシャルネットワークサービス）を提供するシステムである。第１実施形態では、イベントは、所定の場所に所定人数を集めて行われる活動である。具体的には、イベントは、食事会、体験会、相談会、講演会、教室、演奏会、及び、ツアー等がある。また、イベントは、ウェブ上で行われるものであってもよい。

イベント企画システム１００は、各ユーザの、興味関心のある又は提供可能な場所、事、及び、物を公開し、それらに共感するユーザ同士でイベントを開催することをサポートするシステムである。各ユーザの、興味関心のある又は提供可能な場所、事、及び、物を、以降、リソース、と称する。事は、無形であり、例えば、事象、及び、経験等である。物は、有形であり、例えば、人物も含まれる。イベント企画システム１００では、ユーザ及びイベントについて、関連するリソースが公開され、公開されたリソースを手掛かりに、ユーザ及びイベントの検索が行われる。すなわち、イベント企画システム１００は、リソースによってユーザ同士をつなげることを目的とするシステムである。

イベント企画システム１００は、センタサーバ１とユーザ端末２とを含む。ただし、図１ではユーザ端末２は１台のみ示されているが、イベント企画システム１００には、複数のユーザ端末が含まれる。

センタサーバ１及びユーザ端末２は、それぞれ、ネットワークＮ１に接続しており、ネットワークＮ１を通じて通信可能である。ネットワークＮ１は、例えば、インターネットである。

ユーザ端末２には、イベント企画システム１００のクライアントアプリケーションプログラムがインストールされている。ユーザ端末２のユーザがイベントを主催する場合には、ユーザ端末２に、例えば、イベントに関する情報が入力される。イベントに関する情報には、例えば、イベントの名称、開催希望地域、イベントの概要の説明文、及び、イベントに関連するリソースの情報等が含まれる。以降、イベントに関する情報を、イベント情報と称する。

また、第１実施形態では、ユーザは、イベント情報を入力する際に、イベントの運営に参加してもらいたい他のユーザを指定することができる。イベントの起案者を、以降、起案ユーザと称する。イベントの運営に参加してもらいたい他のユーザを、以降、運営候補ユーザと称する。運営候補ユーザの指定には制限がなく、イベント企画システム１００に登録しているいずれのユーザも指定可能である。起案ユーザは、「第１のユーザ」の一例である。運営候補ユーザは、「第２のユーザ」の一例である。

ユーザ端末２は、センタサーバ１へ、イベントの公開要求を送信する。センタサーバ１は、ユーザ端末２からイベントの公開要求を受信すると、当該イベントのイベント情報をイベント企画システム１００のウェブサイト上に公開する。イベント情報が公開されると、当該イベントを運営する運営ユーザ、当該イベントの手伝いを行うサポータの募集が開始される。運営ユーザは、イベントの開催時期、開催場所、及び、内容の決定、及び進行等の企画に関わるユーザである。サポータは、企画には関わらないものの、スタッフとして、イベント当日の受付、及び、案内等の手伝いを行うユーザである。サポータは、「第４のユーザ」の一例である。イベント企画システム１００のウェブサイトは、「第１のウェブサイト」の一例である。

センタサーバ１は、イベント情報を公開するとともに、指定された運営候補ユーザのユーザ端末２へ、当該イベントの運営への参加依頼である運営オファーを送信する。運営候補ユーザは、イベントの情報を見て、運営に参加するか否かを判断する。第１実施形態では、すべての運営候補ユーザのユーザ端末２から、運営オファーに対して承諾の応答が受信された場合には、当該イベントの企画は成立し、次のフレーズへと移行する。少なくともいずれかの運営候補ユーザのユーザ端末２から、運営オファーに対して拒否の応答が受信された場合には、当該イベントの企画は不成立となり、当該イベントの企画は終了する。運営オファーに承諾した運営候補ユーザは、運営に加わるので、以降、運営ユーザと称ｄされるようになる。

また、第１実施形態では、イベントの企画が成立した後、センタサーバ１は、起案ユーザと運営ユーザ間で交流できるように、例えば、メッセージ交換を許可する。以降、起案ユーザと運営ユーザ間で打ち合わせが行われ、イベントの詳細が決定される。

センタサーバ１は、イベントのサポータが所定数集まった場合に、当該イベントの開催決定を判定する。一方、例えば、イベントの成立から所定期間経過しても、サポータが所定数に達しない場合には、センタサーバ１は、当該イベントの開催キャンセルを判定する
。

第１実施形態では、ユーザはイベントを企画する場合に、他のユーザを運営候補ユーザとして指定することで、センタサーバ１が運営候補ユーザに運営オファーを送信するので、自身が事前に仲間を集めなくてもよい。これによって、共に運営する仲間がいない状態でもイベントを企画することができ、イベントの企画に対する心理的ハードルを下げることができる。

図２は、センタサーバ１及びユーザ端末２のハードウェア構成の一例である。センタサーバ１は、ハードウェア構成として、ＣＰＵ １０１、メモリ１０２、外部記憶装置１０３、及び、通信部１０４を備える。メモリ１０２および外部記憶装置１０３は、コンピュータで読み取り可能な記録媒体である。センタサーバ１は、「情報処理装置」の一例である。

外部記憶装置１０３は、様々なプログラムや、各プログラムの実行に際してＣＰＵ １０１が使用するデータを格納する。外部記憶装置１０３は、例えば、ＥＰＲＯＭ（Erasable Programmable ROM）やハードディスクドライブ（Hard Disk Drive）である。外部記憶装置１０３に保持されるプログラムには、例えば、オペレーティングシステム（ＯＳ）、イベント企画システム１００の制御プログラム、及び、その他様々なアプリケーションプログラムを保持する。

メモリ１０２は、ＣＰＵ １０１に、外部記憶装置１０３に格納されているプログラムをロードする記憶領域および作業領域を提供したり、バッファとして用いられたりする記憶装置である。メモリ１０２は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random
Access Memory）のような半導体メモリを含む。

ＣＰＵ １０１は、外部記憶装置１０３に保持されたＯＳや様々なアプリケーションプログラムをメモリ１０２にロードして実行することによって、様々な処理を実行する。ＣＰＵ １０１は、１つに限られず、複数備えられてもよい。ＣＰＵ １０１は、「制御部」の一例である。

通信部１０４は、例えば、ＬＡＮ（Local Area Network）や専用線等の有線のネットワークカードであり、当該ＬＡＮ等のアクセスネットワークを通じてネットワークＮ１に接続する。センタサーバ１のハードウェア構成は、図２に示されるものに限定されない。

ユーザ端末２は、ハードウェア構成として、例えば、ＣＰＵ ２０１、メモリ２０２、外部記憶装置２０３、無線通信部２０４、及び、タッチパネルディスプレイ２０５を備える。ただし、図２では、イベント企画システム１００に関係するハードウェアが抽出して表示されており、ユーザ端末２のハードウェア構成は図２に示されるものに限定されない。

ＣＰＵ ２０１、メモリ２０２、及び、外部記憶装置２０３は、それぞれ、ＣＰＵ １０１、メモリ１０２、及び、外部記憶装置１０３と同様であるため、説明を省略する。外部記憶装置２０３には、イベント企画システム１００のクライアントアプリケーションプログラムが格納されている。

無線通信部２０４は、例えば、５Ｇ（5th Generation）、ＬＴＥ（Long Term Evolution）、ＬＴＥ－Ａｄｖａｎｃｅｄ、及び、３Ｇ等の移動体通信方式、又は、ＷｉＦｉ等の
無線通信方式に対応する無線通信回路である。無線通信部２０４は、無線通信によってアクセスネットワークに接続し、当該アクセスネットワークを通じてネットワークＮ１に接
続する。

タッチパネルディスプレイ２０５は、入力装置及び出力装置の一例である。例えば、タッチパネルディスプレイ２０５には、ユーザ操作が入力され、当該ユーザ操作の内容は ＣＰＵ ２０１へ出力される。また、タッチパネルディスプレイ２０５は、ＣＰＵ ２０１からの指示によって、画像データを表示する。

図３は、センタサーバ１及びユーザ端末２の機能構成の一例を示す図である。ユーザ端末２は、機能構成として、制御部２１、及び、画面データ格納部２２を備える。これらの機能構成要素は、例えば、ユーザ端末２のＣＰＵ ２０１がイベント企画システム１００のクライアントアプリケーションプログラムを実行することによって達成される。

制御部２１は、タッチパネルディスプレイ２０５を通じて、例えば、ユーザ情報の登録要求、お気に入りリソースの記録要求、イベントの公開要求、運営オファーに対する応答、及び、イベントへの参加要求等の送信のユーザ操作の入力を受ける。制御部２１は、無線通信部２０４を通じて、センタサーバ１へ、例えば、ユーザ情報の登録要求、お気に入りリソースの記録要求、イベントの公開要求、運営オファーに対する応答、及び、イベントへの参加要求等を送信する。また、制御部２１は、ユーザ操作及びセンタサーバ１から受信したデータ等に応じた画面を画面データ格納部２２から読み出し、タッチパネルディスプレイ２０５に出力させる。

画面データ格納部２２は、外部記憶装置２０３の記憶領域に作成される。画面データ格納部２２は、イベント企画システム１００のクライアントアプリケーションプログラムにおける画面データを保持する。制御部２１の処理の詳細、及び、画面データ格納部２２に保持される画面データの詳細については、後述される。

次に、センタサーバ１は、機能構成として、制御部１１、ユーザ情報ＤＢ １２、及び、イベント情報ＤＢ １３を備える。これらの機能構成は、例えば、センタサーバ１のＣＰＵ １０１が外部記憶装置１０３に記憶されているイベント企画システム１００の制御プログラムを実行することによって達成される。

制御部１１は、ユーザ情報及びイベント情報の管理を行う。制御部１１は、通信部１０４を通じて、ユーザ端末２から、ユーザ情報の登録要求、及び、お気に入りリソースの記録要求等を受信する。制御部１１は、ユーザ端末２からのユーザ情報の登録要求、及び、お気に入りリソースの記録要求等の受信に応じて、後述のユーザ情報ＤＢ １２内の該当のユーザ情報を更新する。

また、制御部１１は、通信部１０４を通じて、ユーザ端末２から、例えば、イベントの公開要求及びイベントへの参加要求等を受信する。イベントの公開要求及びイベントへの参加要求とともに、送信元のユーザ端末２のユーザのユーザ識別情報も受信される。イベントの公開要求とともに、イベントの情報及び運営候補ユーザのユーザ識別情報も受信される。

イベントの公開要求を受信した場合には、制御部１１は、イベント企画システム１００のウェブサイトに当該イベントを公開する。制御部１１は、イベントを公開することによって、当該イベントの運営ユーザ及びサポータの募集を開始し、イベントの運営ユーザ又はサポータとしての参加要求の受付を開始する。

イベントの公開とともに、制御部１１は、起案ユーザによって指定された運営候補ユーザのユーザ端末２へ、当該イベントの運営オファーを送信する。起案ユーザによって指定
された運営候補ユーザ全てから運営オファーに対する承諾の応答が受信された場合に、制御部１１は、当該イベントの成立を判定する。起案ユーザによって指定された運営候補ユーザのいずれかから運営オファーに対する拒否の応答が受信された場合には、制御部１１は、当該イベントの不成立を判定する。不成立となったイベントは、企画そのものが終了する。

イベントへの参加要求を受信した場合には、制御部１１は、後述のイベント情報ＤＢ １３内の当該イベント情報に参加要求の送信元のユーザの情報を、運営ユーザ又はサポータとして、追加する。例えば、制御部１１は、イベントの成立から所定期間経過した時点で、当該イベントのサポータが所定数に達している場合には、当該イベントの開催決定を判定する。イベントの成立から所定期間経過した時点で、当該イベントのサポータが所定数に達していない場合には、制御部１１は、当該イベントの開催キャンセルを判定する。なお、制御部１１の処理の詳細は、後述される。

ユーザ情報ＤＢ １２及びイベント情報ＤＢ １３は、外部記憶装置１０３の記憶領域に作成される。ユーザ情報ＤＢ １２は、ユーザに関するユーザ情報を保持する。イベント情報ＤＢ １３は、イベントに関するイベント情報を保持する。ユーザ情報ＤＢ １２及びイベント情報ＤＢ １３に保持される情報の詳細については、後述される。センタサーバ１及びユーザ端末２の機能構成は、図３に示される例に限定されない。

図４は、ユーザ情報ＤＢ １２に保持される情報の一例を示す図である。ユーザ情報ＤＢ １２には、ユーザに関するユーザ情報が保持されている。ユーザ情報ＤＢ １２の１レコードが一人のユーザのユーザ情報に相当する。ユーザ情報ＤＢ １２の１レコードには、例えば、ユーザＩＤ、アカウント名、活動地域、リソース＃１、．．．リソース＃Ｍ、お気に入りリソース＃１、．．．、及び、お気に入りリソース＃Ｎのフィールドを含む。Ｍ及びＮは、いずれも正の整数である。

ユーザＩＤのフィールドには、ユーザ識別情報が格納されている。ユーザ識別情報は、例えば、ユーザ登録時に、制御部１１によって、イベント企画システム１００内でユニークに付与される。アカウント名のフィールドには、ユーザのアカウント名が格納される。活動地域のフィールドには、ユーザの活動地域を示す情報が格納されている。ユーザの活動地域を示す情報は、例えば、コードであってもよい。リソース＃１、．．．、及び、リソース＃Ｍのフィールドには、ユーザのリソース情報が格納されている。

お気に入りリソース＃１、．．．、及び、お気に入りリソース＃Ｎのフィールドには、ユーザがメモした、他のユーザのリソース情報が格納されている。より具体的には、お気に入りリソース＃１、．．．、及び、お気に入りリソース＃Ｎのフィールドには、他のユーザのユーザ識別情報と当該他のユーザのリソース情報の一つとの組み合わせが格納されている。

アカウント名、活動地域、リソース＃１、．．．、リソース＃Ｍ、お気に入りリソース＃１、．．．、及び、お気に入りリソース＃Ｎのフィールドの値は、ユーザによって指定される。なお、図４に示されるユーザ情報ＤＢ １２に保持される情報は一例であって、ユーザ情報ＤＢ １２に保持される情報は図４に示される例に限定されない。

図５は、イベント情報ＤＢ １３に保持される情報の一例である。イベント情報ＤＢ １３には、イベントに関するイベント情報が格納されている。イベント情報ＤＢ １３の１レコードが１つのイベントのイベント情報に相当する。イベント情報ＤＢ １３の１レコードには、例えば、イベントＩＤ、起案ユーザＩＤ、イベント名、開催地域、運営候補ユーザＩＤ、運営ユーザＩＤ、サポータ下限値、サポータＩＤ、及び、状態のフィールド
が含まれている。

イベントＩＤのフィールドには、イベント識別情報が格納されている。イベント識別情報は、例えば、制御部１１によってイベント企画システム１００においてユニークに付与される。起案ユーザのＩＤのフィールドには、起案ユーザのユーザ識別情報が格納されている。イベント名のフィールドには、イベント名が格納されている。開催地域のフィールドには、当該イベントの開催予定地域を示す情報が格納されている。運営候補ユーザＩＤのフィールドには、運営候補ユーザのユーザ識別情報が格納されている。運営ユーザＩＤのフィールドには、運営ユーザの識別情報が格納されている。サポータ下限値のフィールドには、サポータの最低必要数が格納されている。サポータＩＤのフィールドには、サポータのユーザ識別情報が格納されている。

状態のフィールドには、当該イベントの状態を示す情報が格納されている。イベントの状態を示す情報は、例えば、フラグ、又は、コードである。イベントの状態の詳細については、後述される。図５に示されるイベント情報ＤＢ １３に保持される情報は一例であって、イベント情報ＤＢ １３に保持される情報は図５に示される例に限定されない。

図６は、イベントの状態遷移の一例を示す図である。イベントの状態には、例えば、公開、成立、不成立、開催決定、開催キャンセル、及び、開催済みがある。初期状態は、「公開」である。運営候補ユーザ全てから運営オファーに対する承諾の応答が得られた場合には、イベントの状態は「公開」から「成立」に移行する。イベントの状態が「成立」になると、制御部１１は、起案ユーザと運営ユーザとの交流を許可する。例えば、起案ユーザと運営ユーザとがメッセージ交換可能なウェブページを作成し、起案ユーザと運営ユーザとが当該ウェブページへアクセス可能にすることで、制御部１１は、起案ユーザと運営ユーザとの交流を許可する。

運営候補ユーザの少なくとも一人から運営オファーに対する拒否の応答が得られた場合には、イベントの状態は「公開」から「不成立」に移行する。「不成立」の状態となったイベントは、所定期間経過後、公開が取り下げられる。

サポータが最低必要数に達した場合には、イベントの状態は「成立」から「開催決定」へと移行する。所定期間経過してもサポータが最低必要数に達しない場合には、イベントの状態は「成立」から「開催キャンセル」へと移行する。「開催キャンセル」の状態となったイベントは、所定時間経過後、公開が取り下げられる。また、「開催キャンセル」の状態となったイベントは、制御部１１は、起案ユーザと運営ユーザとの交流を停止させる。例えば、上述の起案ユーザと運営ユーザとがメッセージ交換可能なウェブページにおいて、制御部１１は、メッセージの新規作成を禁止することで、起案ユーザと運営ユーザとの交流を停止させる。

サポータの最低必要数は、例えば、起案ユーザによって指定される。イベントの開催キャンセルの判定時期は、例えば、一律に予め設定されていてもよいし、起案ユーザによって指定されてもよい。

イベントの開催日が経過すると、イベントの状態は「開催決定」から「開催済み」へと移行する。「開催キャンセル」の状態となったイベントは、所定期間経過後、公開が取り下げられる。また、「開催キャンセル」の状態となったイベントは、制御部１１は、起案ユーザと運営ユーザとの交流を停止させる。

制御部１１は、イベントの状態の遷移を判定し、イベントの状態が遷移すると、イベント情報ＤＢ １３の該当レコードの状態のフィールドを更新する。なお、イベントの状態
は、図６に示されるものに限定されず、実施の形態に応じて適宜変更可能である。

図７から図１３は、ユーザ端末２の画面例である。図７は、ユーザ端末２のユーザ登録画面の一例である。ユーザ登録画面は、イベント企画システム１００へユーザ登録する際の情報を登録する画面である。ユーザ登録画面には、例えば、アカウント名、ユーザの画像、活動地域、自己紹介メッセージ、及び、リソース情報を入力する欄が設けられている。アカウント名、メッセージ、及び、リソース情報の入力欄は、それぞれ、自由にテキストを入力可能である。活動地域の入力は、例えば、ドロップメニューリストから選択するようになっている。

画面下部の「登録」ボタンが選択されると、ユーザ端末２にユーザ情報の登録要求のユーザ操作が入力される。ユーザ情報の登録要求のユーザ操作が入力されると、制御部２１は、ユーザ登録画面に入力されたユーザ情報と、ユーザ情報の登録要求とをセンタサーバ１へ送信する。センタサーバ１の制御部１１は、ユーザ端末２からユーザ情報の登録要求を受信すると、当該ユーザにユーザ識別情報を付与し、ユーザ情報ＤＢ １２に新たにユーザ情報を登録する（図４参照）。なお、図７に示されるユーザ登録画面は一例であって、ユーザ登録画面の構成は図７に示される例に限定されない。

図８は、ユーザ端末２のプロフィール画面の一例である。プロフィール画面は、ユーザ情報が表示される画面である。プロフィール画面には、ユーザ情報である、アカウント名、活動地域、自己紹介メッセージ、及び、リソース情報等が表示される。

リソース情報の表示欄には、それぞれ、お気に入り追加ボタンＢ１が設けられている。お気に入り追加ボタンを選択すると、プロフィール画面に表示中のユーザの該当のリソース情報を、プロフィール画面を表示中のユーザのお気に入りフォルダに登録することができる。お気に入り追加ボタンが選択されると、ユーザ端末２にリソース情報の記録要求のユーザ操作が入力される。リソース情報の記録要求が入力されると、ユーザ端末２の制御部２１は、リソース情報の記録要求と、ユーザ識別情報と、対象のユーザの識別情報及びリソース情報とをセンタサーバ１へ送信する。

センタサーバ１の制御部１１は、ユーザ端末２からリソース情報の記録要求を受信すると、送信元のユーザ端末２のユーザに該当するユーザ情報ＤＢ １２にお気に入りリソースのフィールドを追加して、記録要求とともに受信されたユーザの識別情報及びリソース情報を登録する（図４参照）。なお、図８に示されるプロフィール画面は一例であって、プロフィール画面の構成は図８に示される例に限定されない。

図９は、ユーザ端末２のお気に入りリソース一覧表示画面の一例である。お気に入りリソース一覧表示画面は、お気に入りに登録した他のユーザのリソース情報を一覧表示する画面である。お気に入りリソース一覧画面は、例えば、メニュー操作によって表示される。

お気に入りリソース画面では、例えば、お気に入りに登録されたリソース情報それぞれについて、ユーザのプロフィール画像、アカウント名、活動地域、及び、自己紹介メッセージと、リソース情報とが表示される。

お気に入りリソース一覧表示画面は、例えば、お気に入りリソース一覧表示画面の表示を指示するユーザ操作がユーザ端末２に入力されると、ユーザ端末２の制御部２１がお気に入りリソースの取得要求をセンタサーバ１へ送信する。センタサーバ１の制御部１１は、ユーザ端末２からお気に入りリソースの取得要求を受信すると、ユーザ情報ＤＢ １２の該当ユーザのレコードからお気に入りリソースのフィールドのユーザ識別情報とリソー
ス情報との組み合わせを取得して、ユーザ端末２へ送信する（図４参照）。このとき、各ユーザのユーザ情報として、ユーザのプロフィール画像、アカウント名、活動地域、及び、自己紹介メッセージもユーザ端末２へ送信される。なお、図９に示されるお気に入りリソース一覧表示画面は一例であって、お気に入りリソース一覧表示画面の構成は図９に示される例に限定されない。

図１０は、ユーザ端末２のイベント登録画面の一例である。イベント登録画面は、イベントを起案する際に情報を入力する画面である。イベント登録画面は、例えば、メニュー操作によって表示される。

イベント登録画面には、例えば、イベント名、開催地域、開催時期、イベントの概要メッセージ、イベントに関連するリソース情報、及び、運営候補ユーザの指定の入力欄が設けられている。イベント名、イベントの概要メッセージ、及び、イベントに関連するリソース情報の入力欄は、自由にテキストを入力可能である。開催地域及び開催時期は、例えば、プルダウンメニューから選択して入力される。なお、開催場所及び開催時期は入力がなくてもよい。

運営候補ユーザの指定の入力欄には、指定の有無を選択するラジオボタンが備えられている。例えば、「指定有り」のラジオボタンを選択すると、運営候補ユーザの選択方法を選択するチェックボックスが表示される。運営候補ユーザの選択方法には、例えば、お気に入りリソースから選択する方法と、リソース情報による検索結果から選択する方法とがある。「お気に入りから選択」のチェックボックスは、お気に入りリソースから運営候補ユーザを選択する方法を選択するためのチェックボックスである。「検索結果から選択」のチェックボックスは、リソース情報による検索結果から運営候補ユーザを選択する方法を選択するためのチェックボックスである。

例えば、「お気に入りから選択」のチェックボックスにチェックを入れると、お気に入りリソース一覧表示画面（図９）に遷移し、お気に入りリソースに登録した他のユーザのリソース情報から、運営候補ユーザを指定可能になる。

例えば、「検索結果から選択」のチェックボックスにチェックを入れると、後述のユーザ検索画面に遷移し、リソース情報によってユーザを検索し、その検索結果のユーザの中から、運営候補ユーザを指定可能になる。

図１０に示されるイベント登録画面では、運営候補ユーザの選択方法を選択するチェックボックスの下方に、ユーザが選択した運営候補ユーザの情報が表示されている。

また、図１０に示されるイベント登録画面では、画面の下方に公開ボタンが設けられている。公開ボタンが選択されると、イベントの公開要求のユーザ操作がユーザ端末２へ入力され、ユーザ端末２の制御部２１は、センタサーバ１へ、公開要求、ユーザ識別情報、及び、イベント情報を送信する。このときにセンタサーバ１へ送信されるイベント情報には、例えば、イベント名、開催地域、開催時期、概要メッセージ、イベントに関連するリソース情報及び、運営候補ユーザのユーザ識別情報が含まれる。ただし、開催地域、開催時期、及び、運営候補ユーザのユーザ識別情報は、入力がある場合に送信される。

センタサーバ１の制御部１１は、ユーザ端末２からイベントの公開要求を受信すると、当該イベントにイベント識別情報を付与し、イベント情報をイベント情報ＤＢ １３へ登録し（図５参照）、当該イベント情報を公開し、運営候補ユーザへ運営オファーを送信する。なお、図１０に示されるイベント登録画面は、一例であって、イベント登録画面の構成は、実施の形態に応じて適宜変更可能である。

図１１は、ユーザ端末２のユーザ検索画面の一例である。ユーザ検索画面は、リソース情報からユーザを検索する画面である。ユーザ検索画面は、例えば、メニュー操作によって表示されたり、イベント登録画面（図１０）において運営候補ユーザの選択方法としてリソース情報による検索結果から選択する方法が選択された場合に表示されたりする。

ユーザ検索画面には、例えば、検索条件として、活動地域、及び、リソース情報の入力欄が設けられている。活動地域は、例えば、プルダウンメニューから選択して入力される。なお、活動地域は入力がなくてもよい。リソース情報の入力欄は、自由にテキストを入力可能である。

ユーザ検索画面には、検索開始ボタンが設けられており、検索開始ボタンが選択されると、ユーザの検索要求のユーザ操作がユーザ端末２へ入力される。ユーザ端末２の制御部２１は、ユーザの検索要求のユーザ操作が入力されると、センタサーバ１へ、ユーザの検索要求と、入力された検索条件とを送信する。センタサーバ１の制御部１１は、ユーザ端末２から、ユーザの検索要求を受信すると、受信された検索条件でユーザ情報ＤＢ １２からユーザ情報を検索し、検索結果をユーザ端末２へ送信する。検索結果には、ユーザの識別情報、アカウント名、プロフィール画像、自己紹介メッセージ、及び、リソース情報等が含まれる。ユーザ端末２の制御部２１は、センタサーバ１から検索結果を受信すると、ユーザ検索画面に検索結果を表示する。

図１１に示されるユーザ検索画面の下方には、ユーザの検索結果が表示されている。各ユーザの表示には、チェックボックスが付帯しており、当該チェックボックスにチェックを入れ、「チェックしたユーザを選択する」ボタンを選択すると、チェックしたユーザを選択することができる。なお、図１１に示されるユーザ検索画面は一例であって、ユーザ検索画面の構成は、実施の形態に応じて適宜変更可能である。

図１２は、ユーザ端末２の運営オファー一覧画面の一例である。運営オファー一覧画面は、運営候補ユーザとして指定されたイベントの一覧を表示する画面である。運営オファー一覧画面は、例えば、メニュー操作によって表示される。

運営オファー一覧画面には、運営オファーを受けた各イベントの情報の表示欄が含まれている。運営オファー一覧画面に表示されるイベントの情報の表示欄には、運営オファーを受信した日時、イベント名、起案ユーザのアカウント名、及び、イベントの概要説明メッセージが含まれている。また、図１２に示される各イベントの情報の表示欄には、承諾ボタンとみおくるボタンとが含まれている。

承認ボタンが選択されると、ユーザ端末２へ、該当のイベントの運営オファーに対する承諾の応答のユーザ操作が入力される。みおくるボタンが選択されると、ユーザ端末２へ、該当のイベントの運営オファーに対する拒否の応答のユーザ操作が入力される。

ユーザ端末２の制御部２１は、運営オファーに対する承諾の応答のユーザ操作が入力されると、センタサーバ１へ、該当の運営オファーに対する承諾の応答を送信する。ユーザ端末２の制御部２１は、運営オファーに対する拒否の応答のユーザ操作が入力されると、センタサーバ１へ、該当の運営オファーに対する拒否の応答を送信する。承諾の応答及び拒否の応答のいずれについても、ユーザ識別情報及び該当のイベントのイベント識別情報がともに送信される。

センタサーバ１の制御部１１は、ユーザ端末２から、運営オファーに対する承諾の応答を受信すると、イベント情報ＤＢ １３の該当のイベントのレコードを更新する（図５）
。具体的には、制御部１１は、該当のユーザ識別情報を、イベント情報ＤＢ １３の該当のイベントのレコードの運営候補ユーザＩＤのフィールドから削除し、運営ユーザＩＤのフィールドに追加する。運営オファーに対する拒否の応答を受信した場合には、例えば、制御部１１は、イベント情報ＤＢ １３を更新しない。

所定期間が経過してから、イベント情報ＤＢ １３の該当のイベントのレコードの運営候補ユーザＩＤのフィールドが空の場合には、運営候補ユーザ全てが運営オファーに対して承諾の応答をしていることが示される。この場合には、センタサーバ１の制御部１１は、該当イベントの成立を判定し、イベント情報ＤＢ １３の該当のイベントのレコードの状態のフィールドを「公開」から「成立」に更新する。

一方、所定期間が経過してからも、イベント情報ＤＢ １３の該当のイベントのレコードの運営候補ユーザＩＤのフィールドにいずれかのユーザ識別情報が格納されている場合、又は、いずれかの運営候補ユーザから運営オファーに対して拒否の応答を受信した場合には、センタサーバ１の制御部１１は、該当イベントの不成立を判定する。制御部１１は、イベント情報ＤＢ １３の該当のイベントのレコードの状態のフィールドを「公開」から「不成立」に更新する。なお、図１２に示される運営オファー一覧画面は一例であって、運営オファー一覧画面の構成は実施の形態に応じて適宜変更可能である。

図１３は、ユーザ端末２のイベント一覧画面の一例である。イベント一覧画面は、起案されているイベントの一覧を表示する画面である。イベント一覧画面は、例えば、メニュー操作によって表示される。イベント一覧画面に表示されるイベントは、状態が、「公開」、「成立」、及び「開催決定」のいずれかであるイベントである。状態が「不成立」及び「開催キャンセル」であるイベントは、当該状態になってから所定期間はイベント一覧画面に表示されるが、当該所定期間が経過するとイベント一覧画面の表示対象から除外される。また、イベントが公開されるとは、例えば、イベント一覧画面に表示されることを示す。

イベント一覧画面には、各イベントについての表示欄が含まれる。各イベントについての表示欄には、例えば、イベントの状態、イベント名、起案ユーザのアカウント名、開催地域、概要説明メッセージ、及び、イベントに関連するリソース情報が含まれている。また、各イベントについての表示欄には、運営参加希望ボタンとサポート希望ボタンとが含まれている。

運営参加希望ボタンが選択された場合には、ユーザ端末２へ、該当のイベントについて運営ユーザとしての参加要求のユーザ操作が入力される。サポート希望ボタンが選択された場合には、ユーザ端末２へ、該当のイベントについてサポータとしての参加要求のユーザ操作が入力される。ユーザ端末２の制御部２１は、運営ユーザとしての参加要求又はサポータとしての参加要求のユーザ操作が入力された場合には、イベントへの参加要求をセンタサーバ１へ送信する。イベントのへの参加要求とともに、例えば、ユーザ識別情報、該当のイベント識別情報、及び、運営ユーザ又はサポータのいずれを参加希望しているかを示す情報も送信される。運営ユーザ又はサポータのいずれを参加希望しているかを示す情報は、例えば、フラグ、又は、コードであってもよい。

センタサーバ１の制御部１１は、ユーザ端末２からイベントへの参加要求を受信すると、イベント情報ＤＢ １３の該当のイベントのレコードを更新する（図５）。例えば、イベントの参加要求が運営ユーザとして参加希望を示す場合には、制御部１１は、イベント情報ＤＢ １３の該当のイベントのレコードの運営ユーザＩＤに参加要求とともに受信されたユーザ識別情報を追加する。例えば、イベントの参加要求がサポータとして参加希望を示す場合には、制御部１１は、イベント情報ＤＢ １３の該当のイベントのレコードの
サポータＩＤに参加要求とともに受信されたユーザ識別情報を追加する。なお、運営ユーザ及びサポータとしての参加希望のいずれの場合でも、制御部１１は、起案ユーザに参加希望についての可否を確認してから、イベント情報ＤＢ １３を更新するようにしてもよい。

＜処理の流れ＞
図１４は、ユーザ端末２の処理のフローチャートの一例である。図１４に示される処理は、例えば、ユーザ端末２において、イベント企画システム１００のクライアントアプリケーションプログラムの実行中、繰り返し実行される。なお、図１４に示される処理の実行主体は、ユーザ端末２のＣＰＵ ２０１であるが、便宜上、機能構成要素を主体として説明する。

ＯＰ１０１では、制御部２１は、ユーザ操作の入力の有無を判定する。第１実施形態において、ユーザ端末２へ入力されるユーザ操作には、例えば、ユーザ情報の登録要求、リソース情報の記録要求、ユーザの検索要求、お気に入りリソースの取得要求、イベントの公開要求、イベントへの参加要求、及び、運営オファーに対する応答がある。

ユーザ操作が入力された場合には（ＯＰ１０１：ＹＥＳ）、処理がＯＰ１０２へ進む。ユーザ操作が入力されていない場合には（ＯＰ１０１：ＮＯ）、図１４に示される処理が終了する。

ＯＰ１０２では、制御部２１は、ＯＰ１０１で入力されたユーザ操作に応じた情報をセンタサーバ１へ送信する。例えば、ユーザ情報の登録要求のユーザ操作が入力された場合には、制御部２１は、ユーザ情報の登録要求及びユーザ情報をセンタサーバ１へ送信する。

例えば、リソース情報の記録要求のユーザ操作が入力された場合には、制御部２１は、リソース情報の記録要求、ユーザ識別情報、及び、記録対象のユーザ識別情報とリソース情報との組み合わせをセンタサーバ１へ送信する。例えば、ユーザの検索要求のユーザ操作が入力された場合には、制御部２１は、ユーザの検索要求及び検索条件をセンタサーバ１へ送信する。例えば、お気に入りリソースの取得要求のユーザ操作が入力された場合には、制御部２１は、お気に入りリソースの取得要求及びユーザ識別情報をセンタサーバ１へ送信する。

例えば、イベントの公開要求のユーザ操作が入力された場合には、制御部２１は、イベントの公開要求、ユーザ識別情報、及び、イベント情報をセンタサーバ１へ送信する。例えば、イベントへの参加要求のユーザ操作が入力された場合には、制御部２１は、イベントへの参加要求、ユーザ識別情報、対象のイベントのイベント識別情報、及び、運営ユーザ又はサポータのいずれでの参加希望かを示す情報をセンタサーバ１へ送信する。例えば、運営オファーに対する承諾又は拒否の応答のユーザ操作が入力された場合には、制御部２１は、運営オファーに対する承諾又は拒否応答、対象のイベントのイベント識別情報、及び、ユーザ識別情報をセンタサーバ１へ送信する。その後、図１４に示される処理が終了する。なお、ユーザ端末２の処理は、図１４に示される処理に限定されず、実施の形態に応じて適宜変更可能である。

図１５は、センタサーバ１の処理のフローチャートの一例である。図１５に示される処理は、所定の周期で繰り返し実行される。図１５に示される処理の実行主体は、センタサーバ１のイベント企画システム１００であるが、便宜上、機能構成要素を主体として説明する。以降のフローチャートについても同様である。

ＯＰ２０１では、制御部１１は、ユーザ端末２からユーザ情報の登録要求又はリソース情報の記録要求が受信されたか否かを判定する。ユーザ端末２からユーザ情報の登録要求又はリソース情報の記録要求が受信された場合には（ＯＰ２０１：ＹＥＳ）、処理がＯＰ２０２へ進む。ユーザ端末２からユーザ情報の登録要求又はリソース情報の記録要求のいずれも受信されていない場合には（ＯＰ２０１：ＮＯ）、処理がＯＰ２０３へ進む。

ＯＰ２０２では、制御部１１は、ユーザ端末２から受信されたユーザ情報の登録要求又はリソース情報の記録要求に応じて、ユーザ情報ＤＢ １２を更新する。例えば、ユーザ端末２からユーザ情報の登録要求を受信した場合には、制御部１１は、受信したユーザ情報のレコードをイベント情報ＤＢ １３に新たに追加する（図４）。例えば、ユーザ端末２からリソース情報の記録要求を受信した場合には、制御部１１は、イベント情報ＤＢ １３内の該当のレコードのお気に入りリソースのフィールドに受信したユーザ識別情報とリソース情報との組み合わせを格納する。その後、図１５に示される処理が終了する。

ＯＰ２０３では、制御部１１は、ユーザ端末２からユーザの検索要求又はお気に入りリソースの取得要求が受信されたか否かを判定する。ユーザ端末２からユーザの検索要求又はお気に入りリソースの取得要求が受信された場合には（ＯＰ２０３：ＹＥＳ）、処理がＯＰ２０４へ進む。ユーザ端末２からユーザの検索要求又はお気に入りリソースの取得要求のいずれも受信されていない場合には（ＯＰ２０３：ＮＯ）、処理がＯＰ２０６へ進む。

ＯＰ２０４では、制御部１１は、検索要求又は取得要求に応じた検索条件でユーザ情報ＤＢ １２を検索する。ＯＰ２０５では、制御部１１は、ＯＰ２０４の検索結果をユーザ端末２へ送信する。その後、図１５に示される処理が終了する。

例えば、ユーザの検索要求が受信された場合には、制御部１１は、検索要求とともに受信された検索条件でユーザ情報ＤＢ １２を検索し、合致したユーザ情報を検索結果としてユーザ端末２へ送信する。この場合の検索条件は、例えば、リソース情報である。例えば、お気に入りリソースの取得要求が受信された場合には、制御部１１は、取得要求とともに受信されたユーザ識別情報に該当するイベント情報ＤＢ １３のレコードのお気に入りフィールドに格納されているユーザ識別情報とリソース情報の組み合わせを検索結果としてユーザ端末２へ送信する。また、ユーザ端末２は、検索結果として検出した各ユーザ識別情報に該当するユーザ情報をユーザ端末２へ送信する。

ＯＰ２０６では、制御部１１は、ユーザ端末２からイベントの公開要求が受信されたか否かを判定する。ユーザ端末２からイベントの公開要求が受信された場合には（ＯＰ２０６：ＹＥＳ）、処理がＯＰ２０７へ進む。ユーザ端末２からイベントの公開要求が受信されていない場合には（ＯＰ２０６：ＮＯ）、処理がＯＰ２０８へ進む。

ＯＰ２０７では、制御部１１は、イベント管理処理を実行する。イベント管理処理は、イベントの状態を管理する処理である。イベント管理処理の詳細は後述される。その後、図１５に示される処理が終了する。

ＯＰ２０８では、制御部１１は、ユーザ端末２からイベントの運営オファーに対する応答又はイベントへの参加要求が受信されたか否かを判定する。イベントの運営オファーに対する応答又はイベントへの参加要求が受信された場合には（ＯＰ２０８：ＹＥＳ）、処理がＯＰ２０９へ進む。ユーザ端末２からイベントの運営オファーに対する応答又はイベントへの参加要求のいずれも受信されていない場合には（ＯＰ２０８：ＮＯ）、図１５に示される処理が終了する。

ＯＰ２０９では、制御部１１は、ユーザ端末２から受信されたイベントの運営オファーに対する応答又はイベントへの参加要求に応じて、イベント情報ＤＢ １３を更新する。例えば、ユーザ端末２からイベントの運営オファーに対する承諾の応答が受信された場合には、制御部１１は、参加要求とともに受信したユーザ識別情報を、イベント情報ＤＢ １３内の参加要求とともに受信したイベント識別情報に該当するレコードの運営候補ユーザのフィールドから削除し、運営ユーザのフィールドに追加する（図５）。例えば、ユーザ端末２からイベントへの参加要求を受信した場合には、制御部１１は、参加要求とともに受信したユーザ識別情報を、イベント情報ＤＢ １３内の参加要求とともに受信したイベント識別情報に該当するレコードの運営ユーザ又はサポータのフィールドに追加する（図５）。その後、図１５に示される処理が終了する。

図１６は、センタサーバ１のイベント管理処理のフローチャートの一例である。図１６に示される処理は、図１５のＯＰ２０７の処理に相当する。すなわち、図１６に示される処理は、ユーザ端末２からイベントの公開要求が受信されると開始される。

ＯＰ３０１では、制御部１１は、イベントの公開要求とともに受信されたイベント情報をイベント情報ＤＢ １３に登録し、公開する。ＯＰ３０２では、制御部１１は、運営候補ユーザの指定があるか否かを判定する。運営候補ユーザの指定がある場合には、ユーザ端末２から、イベントの公開要求とともに、運営候補ユーザのユーザ識別情報が受信される。運営候補ユーザの指定がない場合には（ＯＰ３０２：ＮＯ）、処理がＯＰ３０６へ進む。

ＯＰ３０３では、制御部１１は、運営候補ユーザのユーザ端末２へ、運営オファーを送信する。運営オファーとともに、イベント識別情報も送信される。

ＯＰ３０４では、制御部１１は、起案ユーザによって指定された全ての運営候補ユーザから承諾の応答が受信されたか否かを判定する。起案ユーザによって指定された全ての運営候補ユーザから承諾の応答が受信された場合には（ＯＰ３０４：ＹＥＳ）、処理がＯＰ３０６へ進む。起案ユーザによって指定されたいずれかの運営候補ユーザから拒否の応答が受信された場合、又は、所定期間経過してもすべての運営候補ユーザから承諾の応答が得られなかった場合には（ＯＰ３０４：ＮＯ）、処理がＯＰ３０５へ進む。

ＯＰ３０５では、制御部１１は、イベントの状態が「公開」から「不成立」へ遷移したことを判定し、イベント情報ＤＢ １３の該当レコードの状態のフィールドを更新する。その後、図１６に示される処理が終了する。

ＯＰ３０６では、制御部１１は、イベントの状態が「公開」から「成立」へ遷移したことを判定し、イベント情報ＤＢ １３の該当レコードの状態のフィールドを更新する。ＯＰ３０７では、制御部１１は、起案ユーザと運営ユーザ間のメッセージ交換を許可する。

ＯＰ３０８では、制御部１１は、イベントのサポータの数が所定数に達したか否かを判定する。イベントのサポータの数が所定数に達した場合には（ＯＰ３０８：ＹＥＳ）、処理がＯＰ３０９へ進む。所定期間経過しても、イベントのサポータの数が所定数に達しない場合には（ＯＰ３０８：ＮＯ）、処理がＯＰ３１０へ進む。なお、ＯＰ３０２において、運営候補ユーザの指定がなかった場合には、ＯＰ３０８において、制御部１１は、運営ユーザが所定数に達したか否かをさらに判定してもよい。運営ユーザとサポータとがともに所定数に達した場合に、ＯＰ３０８において肯定判定としてもよい。運営ユーザとサポータのいずれかが所定数に達しない場合に、制御部１１は、ＯＰ３０８において否定判定としてもよい。

ＯＰ３０９では、制御部１１は、イベントの状態が「成立」から「開催決定」へ遷移したことを判定し、イベント情報ＤＢ １３の該当レコードの状態のフィールドを更新する。ＯＰ３１０では、制御部１１は、イベントの状態が「成立」から「開催キャンセル」へ遷移したことを判定し、イベント情報ＤＢ １３の該当レコードの状態のフィールドを更新する。その後、図１６に示される処理が終了する。

ＯＰ３１１では、制御部１１は、イベントの開催日が経過したか否かを判定する。イベントの開催日が経過した場合には（ＯＰ３１１：ＹＥＳ）、処理がＯＰ３１２へ進む。イベントの開催日が経過していない場合には（ＯＰ３１１：ＮＯ）、ＯＰ３１１の処理が繰り返される。

ＯＰ３１２では、制御部１１は、イベントの状態が「開催決定」から「開催済み」へ遷移したことを判定し、イベント情報ＤＢ １３の該当レコードの状態のフィールドを更新する。その後、図１６に示される処理が終了する。

図１７は、イベント企画システム１００におけるイベントが起案されてから開催が決定するまでの処理のシーケンス図の一例である。図１７では、起案ユーザのユーザ端末をユーザ端末２Ａ、運営候補ユーザのユーザ端末をユーザ端末２Ｂとする。

Ｓ１１では、起案ユーザがユーザ端末２Ａのイベント登録画面（図１０）にイベント情報を入力する。起案ユーザは、ユーザ端末２Ｂのユーザを運営候補ユーザとして指定する。Ｓ１２では、ユーザ端末２Ａは、起案ユーザによるイベントの公開要求のユーザ操作の入力を受けて、イベントの公開要求をセンタサーバ１へ送信する。

Ｓ１３では、センタサーバ１は、ユーザ端末２Ａからイベントの公開要求を受信すると（図１５、ＯＰ２０６）、当該イベント情報をイベント企画システム１００のウェブサイト上で公開する（図１６、ＯＰ３０１）。

Ｓ２１では、センタサーバ１は、運営候補ユーザのユーザ端末２Ｂへ当該イベントの運営オファーを送信する（図１６、ＯＰ３０３）。Ｓ２２では、ユーザ端末２Ｂは、運営候補ユーザからの運営オファーに対する承諾の応答のユーザ操作の入力を受けて、センタサーバ１へ、承諾の応答を送信する。センタサーバ１は、ユーザ端末２Ｂからの承諾の応答を受信する（図１６、ＯＰ３０４）。

図１７に示される例では、ユーザ端末２Ｂのユーザ以外に運営候補ユーザが指定されていないこととする。Ｓ２３では、センタサーバ１は、全ての運営候補ユーザから承諾の応答を受信したので（図１６、ＯＰ３０４）、イベントの状態が「公開」から「成立」に遷移したことを判定する（図１６、ＯＰ３０６）。Ｓ２４では、センタサーバ１は、ユーザ端末２Ａとユーザ端末２Ｂ間のメッセージ交換を許可する（図１６、ＯＰ３０７）。これ以降、起案ユーザと運営ユーザ間で当該イベントに関して、イベント企画システム１００上でメッセージ交換によって交流することが可能になる。

Ｓ３１では、センタサーバ１は、イベントへの運営ユーザ又はサポータとして参加を希望するユーザのユーザ端末２から、参加要求を受信する。Ｓ３２では、イベントの公開から所定期間経過後、又は、サポータが所定数に達した場合に、センタサーバ１は、当該イベントの状態が「成立」から「開催決定」に遷移したことを判定する。以降、イベントが開催されると、当該イベントの状態が「開催決定」から「開催済み」に遷移し、イベントの公開が終了する。

なお、イベントの状態が「開催決定」になった段階で、当該イベントの開催場所や開催
日時等が未定であってもよい。

＜第１実施形態の作用効果＞
第１実施形態では、イベントを起案する場合に、運営候補ユーザを指定することで、センタサーバ１によって、運営候補ユーザへ運営オファーが送信される。起案ユーザは、実際に面識がない、又は、イベント企画システム１００上又はその他ＳＮＳ上でつながりがないユーザの中から、運営候補ユーザを指定することができる。これによって、起案ユーザは、運営候補ユーザを事前に集めることをせずに、イベントを企画することができ、イベントの企画に対するハードルを下げることができる。

また、第１実施形態では、各ユーザは、リソース情報を公開しており、起案ユーザはリソース情報で検索したユーザの中から運営候補ユーザを指定する。また、イベント情報には、イベントに関するリソース情報が含まれており、イベントの公開では当該リソース情報も公開される。したがって、第１実施形態に係るイベント企画システム１００は、リソース情報によってユーザ同士をつなげることができる。リソース情報は、ユーザによって自由に指定されるものであって、ユーザ又はイベントの世界観が表現されるツールとして作用する。これによって、イベントの世界観に共感したユーザが集うことになるので、これまでにない新たな出会いを生み出すことができる。

また、第１実施形態では、イベントが「成立」状態になって初めて、起案ユーザと運営候補ユーザとが交流できるようになる。また、イベントは、参加者が所定数に達してから「開催決定」の状態となる。第１実施形態では、「開催決定」の状態でイベントの開催場所及び開催日時等の詳細が未定であってもよい。通常、イベントを企画する場合には、開催場所や予算を確保してから企画するが、第１実施形態によれば、通常のイベントの企画のように、イベントを企画する前に開催場所や予算を確保しなくともよく、例えば、イベントの開催が決定してから予算等を確保する行動をとることができ、気軽にイベントを企画することができる。また、イベントが成立しない場合や開催がキャンセルされた場合でも、開催場所や予算等を確保していない場合には、開催場所や予算等の確保にかかる金銭、労力、及び、時間等の無駄の発生を抑制することができる。

また、第１実施形態では、例えば、運営候補ユーザから運営オファーに対して拒否の応答が受信され、イベントが「不成立」になった場合には、起案ユーザは、別のユーザを運営候補ユーザに指定して、再度同じイベントを企画すればよい。これによって、例えば、イベントが成立しなかった場合でも、同じイベントを再度企画しやすく、気軽にイベントを企画することができる。

また、運営オファーを受けた運営候補ユーザも、ユーザ端末２からボタンを選択して応答するだけなので、運営オファーを受けやすかったり断りやすかったりして、イベントに対するハードルを下げることができる。

＜その他の実施形態＞
上記の実施形態はあくまでも一例であって、本開示はその要旨を逸脱しない範囲内で適宜変更して実施しうる。

第１実施形態に係るイベント企画システム１００は、実際に複数人が集まって開催されるイベントの企画を対象とするが、第１実施形態で説明された技術は、イベントの企画の他に、クラウドファンディング等の、運営ユーザを複数人集めて行われる活動にも適用することができる。

本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に
組み合わせて実施することができる。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本開示は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク、ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１・・センタサーバ
２・・ユーザ端末
１１・・制御部
１２・・ユーザ情報データベース
１３・・イベント情報データベース
２１・・制御部
２２・・画面データ格納部
１００・・イベント企画システム
１０１、２０１・・ＣＰＵ
１０２、２０２・・メモリ
１０３、２０３・・外部記憶装置
１０４・・通信部
２０４・・無線通信部
２０５・・タッチパネルディスプレイ

Claims (20)

1. 第１のユーザのユーザ端末から、前記第１のユーザが主催する所定の活動の企画に関する情報の公開を要求する公開要求と、複数のユーザのうち、前記第１のユーザによって前記所定の活動の運営への参加の依頼先として指定される１又は複数の第２のユーザの識別情報と、を受信することと、
   前記所定の活動の企画に関する情報を第１のウェブサイトに公開することと、
   前記１又は複数の第２のユーザのユーザ端末へ、前記所定の活動の運営への参加依頼を送信することと、
   を含む情報処理方法。
2. 前記１又は複数の第２のユーザの指定は、前記複数のユーザのいずれのユーザに対しても可能である、
   請求項１に記載の情報処理方法。
3. 前記複数のユーザそれぞれについて、ユーザに関するユーザ情報の一つとして、興味関心、及び、提供可能なスキルに関連のある、場所、物、及び、事を含むリソース情報を記憶部に保持することと、
   前記複数のユーザそれぞれについて、前記リソース情報を前記第１のウェブサイトに公開することと、
   をさらに含み、
   前記所定の活動の企画に関する情報は、前記第１のユーザに関連付くリソース情報のうちの少なくとも１つを含む、
   請求項１に記載の情報処理方法。
4. 前記１又は複数の第２のユーザは、前記第１のユーザによって指定されるリソース情報による検索結果から選択されたユーザである、
   請求項３に記載の情報処理方法。
5. 前記複数のユーザのうちの第３のユーザのユーザ端末から、他のユーザについて公開されている第１のリソース情報の記録を要求する記録要求と、前記第１のリソース情報とを受信することと、
   前記第３のユーザのユーザ情報と前記第１のリソース情報とを関連付けて、前記記憶部に記録することと、
   をさらに含む、
   請求項３又は４に記載の情報処理方法。
6. 前記１又は複数の第２のユーザのユーザ端末すべてから、前記所定の活動の運営への参加依頼に対して、前記所定の活動の運営への参加の承諾の応答を受けた場合に、前記所定の活動の企画の成立を判定して公開し、
   前記１又は複数の第２のユーザのユーザ端末のうちの少なくとも１つから、前記所定の活動の運営への参加依頼に対して、前記所定の活動の運営への参加の拒否の応答を受けた場合に、前記所定の活動の企画の不成立を判定して公開する、
   ことをさらに含む請求項１から５のいずれか一項に記載の情報処理方法。
7. 前記所定の活動の企画が成立した後に、前記第１のユーザのユーザ端末と前記１又は複数の第２のユーザのユーザ端末間でメッセージ交換を許可することをさらに含む、
   請求項６に記載の情報処理方法。
8. 公開された前記所定の活動の企画に対して、第４のユーザのユーザ端末から、前記第４
   のユーザがスタッフとして参加を所望していることを示す参加要求を受信することと、
   公開された前記所定の活動の企画に対して、前記第４のユーザの数が所定数に達した場合に、前記所定の活動の開催決定を判定して公開し、前記第４のユーザの数が所定数に達しない場合には、前記所定の活動の開催のキャンセルを判定して公開することと、
   をさらに含む、
   請求項１から７のいずれか一項に記載の情報処理方法。
9. 第１のユーザのユーザ端末から、前記第１のユーザが主催する所定の活動の企画に関する情報の公開を要求する公開要求と、複数のユーザのうち、前記第１のユーザによって前記所定の活動の運営への参加の依頼先として指定される１又は複数の第２のユーザの識別情報と、を受信することと、
   前記所定の活動の企画に関する情報を第１のウェブサイトに公開することと、
   前記１又は複数の第２のユーザのユーザ端末へ、前記所定の活動の運営への参加依頼を送信することと、
   を実行する制御部、
   を備える情報処理装置。
10. 前記１又は複数の第２のユーザの指定は、前記複数のユーザのいずれのユーザに対しても可能である、
    請求項９に記載の情報処理装置。
11. 前記複数のユーザそれぞれについて、ユーザに関するユーザ情報の一つとして、興味関心、及び、提供可能なスキルに関連のある、場所、物、及び、事を含むリソース情報を保持する記憶部をさらに備え、
    前記制御部は、
    前記複数のユーザそれぞれについて、前記リソース情報を前記第１のウェブサイトに公開することをさらに実行し、
    前記所定の活動の企画に関する情報は、前記第１のユーザに関連付くリソース情報のうちの少なくとも１つを含む、
    請求項９に記載の情報処理装置。
12. 前記１又は複数の第２のユーザは、前記第１のユーザによって指定されるリソース情報による検索結果から選択されたユーザである、
    請求項１１に記載の情報処理装置。
13. 前記制御部は、
    前記複数のユーザのうちの第３のユーザのユーザ端末から、他のユーザについて公開されている第１のリソース情報の記録を要求する記録要求と、前記第１のリソース情報とを受信することと、
    前記第３のユーザのユーザ情報と前記第１のリソース情報とを関連付けて、前記記憶部に記録することと、
    をさらに実行する、
    請求項１１又は１２に記載の情報処理装置。
14. 前記制御部は、
    前記１又は複数の第２のユーザのユーザ端末すべてから、前記所定の活動の運営への参加依頼に対して、前記所定の活動の運営への参加の承諾の応答を受けた場合に、前記所定の活動の企画の成立を判定して公開し、
    前記１又は複数の第２のユーザのユーザ端末のうちの少なくとも１つから、前記所定の活動の運営への参加依頼に対して、前記所定の活動の運営への参加の拒否の応答を受けた
    場合に、前記所定の活動の企画の不成立を判定して公開する、
    ことをさらに実行する請求項９から１３のいずれか一項に記載の情報処理装置。
15. 前記制御部は、
    前記所定の活動の企画が成立した後に、前記第１のユーザのユーザ端末と前記１又は複数の第２のユーザのユーザ端末間でメッセージ交換を許可することをさらに実行する、
    請求項１４に記載の情報処理装置。
16. 前記制御部は、
    公開された前記所定の活動の企画に対して、第４のユーザのユーザ端末から、前記第４のユーザがスタッフとして参加を所望していることを示す参加要求を受信することと、
    公開された前記所定の活動の企画に対して、前記第４のユーザの数が所定数に達した場合に、前記所定の活動の開催決定を判定して公開し、前記第４のユーザの数が所定数に達しない場合には、前記所定の活動の開催のキャンセルを判定して公開することと、
    をさらに実行する、
    請求項９から１５のいずれか一項に記載の情報処理装置。
17. コンピュータに、
    第１のユーザが主催する所定の活動の企画に関する情報の公開を要求する公開要求と、複数のユーザのうち、前記所定の活動の運営への参加の依頼先としての１又は複数の第２のユーザの指定と、の入力を受け付けることと、
    所定のサーバへ、前記公開要求と、前記１又は複数の第２のユーザの識別情報とを送信することと、
    を実行させるためのプログラムであって、
    前記所定のサーバは、
    前記所定の活動の企画に関する情報を第１のウェブサイトに公開することと、
    前記１又は複数の第２のユーザのユーザ端末へ、前記所定の活動の運営への参加依頼を送信することと、
    を実行する、
    プログラム。
18. 前記１又は複数の第２のユーザの指定は、前記複数のユーザのいずれのユーザに対しても可能である、
    請求項１７に記載のプログラム。
19. 前記コンピュータに、
    前記第１のユーザの、興味関心、及び、提供可能なスキルに関連のある、場所、物、及び、事を含むリソース情報と、前記リソース情報の登録を要求する登録要求との入力を受け付けることと、
    前記所定のサーバへ、前記登録要求と、前記リソース情報と、を送信することと、
    をさらに実行させ、
    前記所定のサーバは、
    前記第１のユーザのユーザ情報の一つとして前記リソース情報を記憶部に保持することと、
    前記リソース情報を前記第１のウェブサイトに公開することと、
    をさらに実行し、
    前記所定の活動の企画に関する情報は、前記第１のユーザに関連付くリソース情報のうちの少なくとも１つを含む、
    請求項１７に記載のプログラム。
20. 前記コンピュータに、
    他のユーザについて公開されている第１のリソース情報の指定と、指定された前記第１のリソース情報の記録を要求する記録要求と、の入力を受け付けることと、
    前記所定のサーバへ、前記記録要求と、前記第１のリソース情報とを送信することと、をさらに実行させ、
    前記所定のサーバは、
    前記第１のユーザのユーザ情報と前記第１のリソース情報とを関連付けて、前記記憶部に記録することと、
    をさらに実行する、
    請求項１９に記載のプログラム。

Images