JP6862716B2 - サーバ、その制御方法及びその制御プログラム - Google Patents

Description

本発明は、サーバ、その制御方法及びその制御プログラムに関する。

従来、イベントを開催する幹事ユーザは、複数の候補日時をイベントに招集する複数の招集ユーザに個別に通知し、複数の候補日時のそれぞれに対する招集ユーザから個別に受けた出欠可否の回答に基づいて、イベントの開催日時を決定する。

例えば、特許文献１には、幹事ユーザは、その飲み会の招集ユーザをスケジュール調整システムに登録し、スケジュール調整システムは、招集ユーザ全員のスケジュールを確認して招集ユーザ全員の都合のよい日時を設定することが開示されている。

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

特許文献１に記載されたスケジュール調整システムにおいて、幹事ユーザは、都合のよい招集ユーザの人数分の席を確保するため、予め店舗の席を予約する。その後、招集ユーザの予定が変更になると、幹事ユーザは、予約した店舗の席をキャンセルしなければならない。このように、店舗の席を予め予約すると、幹事ユーザの作業が多くなる可能性がある。

本発明は、このような課題を解決すべくなされたものであり、幹事ユーザに負担をかけずに自動的に予約を確定できるサーバ、その制御方法及びその制御プログラムを提供することを目的とする。

本発明に係る制御方法は、記憶部を備えるサーバの制御方法であって、複数のユーザごとに、各ユーザの予定の日時及び場所を関連付けて記憶部に記憶し、複数の施設ごとに、各施設の場所を記憶部に記憶し、全ての複数のユーザの予定が入っていない時間帯を抽出し、抽出した時間帯の直前に入っている全ての複数のユーザのそれぞれの予定の日時及び場所に基づいて、抽出した時間帯に全ての複数のユーザが集合できる施設を決定し、決定した施設内の設備を仮予約し、仮予約した設備の利用可能人数を複数のユーザのそれぞれのユーザ端末に出力し、複数のユーザのそれぞれのユーザ端末から参加の意思表示を受付け、受付けた参加の意思表示の数をカウントし、カウントした参加の意思表示の数が所定の人数に達した場合、設備を本予約する、ステップを有する。

本発明に係るサーバは、複数のユーザごとに、各ユーザの予定の日時及び場所を関連付けて記憶し、複数の施設ごとに、各施設の場所を記憶する記憶部と、全ての複数のユーザの予定が入っていない時間帯を抽出する抽出部と、抽出した時間帯の直前に入っている全ての複数のユーザのそれぞれの予定の日時及び場所に基づいて、抽出した時間帯に全ての複数のユーザが集合できる施設を決定する決定部と、決定した施設内の設備を仮予約する仮予約部と、仮予約した設備の利用可能人数を複数のユーザのそれぞれのユーザ端末に出力する出力部と、複数のユーザのそれぞれのユーザ端末から参加の意思表示を受付ける受付部と、受付けた参加の意思表示の数をカウントし、カウントした参加の意思表示の数が所定の人数に達した場合、設備を本予約する予約部と、を備える。

本発明に係る端末の制御プログラムは、サーバに、複数のユーザごとに、各ユーザの予定の日時及び場所を関連付けて記憶部に記憶し、複数の施設ごとに、各施設の場所を記憶部に記憶し、全ての複数のユーザの予定が入っていない時間帯を抽出し、抽出した時間帯の直前に入っている全ての複数のユーザのそれぞれの予定の日時及び場所に基づいて、抽出した時間帯に全ての複数のユーザが集合できる施設を決定し、決定した施設内の設備を仮予約し、仮予約した設備の利用可能人数を複数のユーザのそれぞれのユーザ端末に出力し、複数のユーザのそれぞれのユーザ端末から参加の意思表示を受付け、受付けた参加の意思表示の数をカウントし、カウントした参加の意思表示の数が所定の人数に達した場合、設備を本予約する、ことを実行させる。

本発明に係るサーバ、その制御方法、及びその制御プログラムによれば、幹事ユーザに負担をかけずに自動的に予約を確定できる。

予約システム１の概略を説明するための模式図である。 予約システム１の概略構成の一例を示す図である。 （ａ）は、幹事端末２の概略構成の一例を示す図であり、（ｂ）は、ユーザ端末３の概略構成の一例を示す図である。 サーバ４の概略構成の一例を示す図である。 テーブルのデータ構造の一例を示す図である。 他のテーブルのデータ構造の一例を示す図である。 予約システム１による動作シーケンスの一例を示す図である。 （ａ），（ｂ）は、幹事端末２に表示される画面の一例を示す図であり、（ｃ）は、ユーザ端末３に表示されるメッセージの一例を示す図である。 ユーザ端末３に表示される画面の一例を示す図である。 （ａ）は、ユーザ端末３に表示される他の画面の一例を示す図であり、（ｂ）は、他のテーブルのデータ構造の一例である。 予約システム１の概略を説明するための模式図である。

以下、図面を参照しつつ、本発明の様々な実施形態について説明する。ただし、本発明の技術的な範囲はそれらの実施形態に限定されず、特許請求の範囲に記載された発明とその均等物に及ぶ点に留意されたい。

図１は、予約システム１の概略を説明するための模式図である。

予約システム１は、ユーザ端末３と、記憶部等を備えるサーバ４等とを有する。サーバ４は、各ユーザのスケジュール管理及び施設内の設備の予約管理を行っている。そのため、サーバ４は、複数のユーザごとに、各ユーザの予定の日時及び場所を関連付けて記憶部に記憶する。また、サーバ４は、複数の施設ごとの各施設の場所を記憶部に記憶する。

サーバ４は、全ての複数のユーザの予定が入っていない時間帯を記憶部から抽出する（１）。例えば、ユーザＡの一日の最後の予定が16:00〜18:30の打合せであり、ユーザＢの一日の最後の予定が16:00〜17:00の会議であり、ユーザＨの一日の最後の予定が16:00〜18:00であるとする。この場合、例えば、サーバ４は、19:00〜21:00を全ての複数のユーザの予定が入っていない時間帯１０として抽出する。抽出する処理の詳細については、後述する。全ての複数のユーザの予定が入っていない時間帯は、イベントの開始日時から終了日時となる。

サーバ４は、抽出した時間帯の直前に入っている全ての複数のユーザのそれぞれの予定の日時及び場所１１〜１３に基づいて、抽出した時間帯に全ての複数のユーザが集合できる施設を決定する（２）。例えば、ユーザＡが直前に入っている予定が終わってから、イベントの開始日時まで、３０分あるので、サーバ４は、ユーザＡが予定の場所から３０分で移動できる範囲１４を特定する。同様に、サーバ４は、ユーザＢ及びユーザＨが直前の予定の場所からイベントの開始日時まで移動できる範囲１５，１６を特定する。各ユーザの移動できる範囲１４，１５，１６が全て重なった範囲に位置する施設を、全ての複数のユーザが集合できる施設として決定する。施設を決定する処理の詳細については、後述する。

サーバ４は、決定した施設内の設備を仮予約する（３）。仮予約は、設備を確保しておくことを意味する。例えば、サーバ４は、決定したレストランＡ内の招集ユーザの全員が入ることができる８名用個室Ａを仮予約する。

サーバ４は、仮予約した設備の利用可能数を複数のユーザのそれぞれのユーザ端末３に出力する（４）。利用可能数は、施設内の設備に対して、参加の意思表示を受付けることができる数を示す。

ユーザの操作に従って、ユーザ端末３は、参加の意思表示をサーバ４に送信すると、サーバ４は、ユーザ端末３から参加の意思表示を受付ける（５）。

サーバ４は、受付けた参加の意思表示の数をカウントし、カウントした参加の意思表示の数が所定の人数に達した場合、設備を本予約する（６）。所定の人数は、例えば、幹事ユーザ又はサーバ４によって設定される最低開催人数である。本予約は、仮予約を確定することを意味する。

このように、サーバ４は、施設内の設備を仮予約し、受付けた参加の意思表示の数に応じて、設備を本予約する。したがって、サーバ４は、幹事ユーザに負担をかけずに自動的に予約を確定できる。

図２は、予約システム１の概略構成の一例を示す図である。

予約システム１は、幹事端末２と、ユーザ端末３と、サーバ４とを備える。幹事端末２とサーバ４とは、通信ネットワークを介して相互に接続され、例えば、インターネット５を介して相互に接続される。幹事端末２で実行されるプログラムと、サーバ４で実行されるプログラムとは、ハイパーテキスト転送プロトコル（HTTP: Hypertext Transfer Protocol）等の通信プロトコルを用いて通信を行う。ユーザ端末３とサーバ４は、通信ネットワークを介して相互に接続され、例えば、インターネット５を介して相互に接続される。ユーザ端末３で実行されるプログラムと、サーバ４で実行されるプログラムとは、ハイパーテキスト転送プロトコル等の通信プロトコルを用いて通信を行う。なお、予約システム１は、複数のユーザ端末３を備えていてもよい。

図３（ａ）は、幹事端末２の概略構成の一例を示す図である。

幹事端末２は、端末通信部２１、端末記憶部２２、操作部２３、表示部２４及び端末処理部２５等を備える。幹事ユーザとは、複数のユーザが参加予定のイベントを開催する責任者であるユーザを意味する。イベントとは、施設で開催する催し物又は行事をいう。イベントは、例えば、社員旅行、新年会、交流会、忘年会、バーベキュー、宴会、懇親会、同窓会、及びゴルフコンペ等である。幹事端末２として、多機能携帯電話（所謂「スマートフォン」）が想定されるが、これに限定されるものではない。幹事端末２は、本発明が適用可能であればよく、例えば、携帯電話（所謂「フィーチャーフォン」）、携帯情報端末（PDA: Personal Digital Assistant, PDA）、タブレットＰＣ、パーソナルコンピュータ等でもよい。

端末通信部２１は、所定の周波数帯を感受帯域とするアンテナを含む通信インターフェース回路を備え、幹事端末２をインターネット５に接続する。端末通信部２１は、端末処理部２５から供給されたデータをサーバ４等に送信する。また、端末通信部２１は、サーバ４等から受信したデータを端末処理部２５に供給する。

端末記憶部２２は、例えば、半導体メモリ、磁気ディスク装置、又は光ディスク装置のうちの少なくともいずれか一つを備える。端末記憶部２２は、端末処理部２５での処理に用いられるオペレーティングシステムプログラム、ドライバプログラム、アプリケーションプログラム、データ等を記憶する。例えば、端末記憶部２２は、ドライバプログラムとして、操作部２３を制御する入力デバイスドライバプログラム、表示部２４を制御する出力デバイスドライバプログラム等を記憶する。また、端末記憶部２２は、アプリケーションプログラムとして、メッセージの送受信を実行するプログラム等を記憶する。また、端末記憶部２２は、データとして、送受信されたメッセージとそれに付随するデータを記憶する。さらに、端末記憶部２２は、所定の処理に係る一時的なデータを一時的に記憶してもよい。

操作部２３は、幹事端末２の操作が可能であればどのようなデバイスでもよく、例えば、タッチパッド、キーボード等である。幹事ユーザは、操作部２３を用いて、文字、数字等を入力することができる。操作部２３は、幹事ユーザにより操作されると、その操作に対応する信号を発生する。発生した信号は、幹事ユーザの指示として、端末処理部２５に供給される。

表示部２４は、文字列、画像等の表示が可能であればどのようなデバイスでもよく、例えば、液晶ディスプレイ、有機ＥＬ（Electro-Luminescence）ディスプレイ等である。表示部２４は、端末処理部２５から供給された、送受信されたメッセージ等を表示する。

端末処理部２５は、アクセス部２５１、スケジュール管理部２５２及びメッセージ管理部２５３等を備える。端末処理部２５は、幹事端末２の全体的な動作を統括的に制御するものであり、一又は複数個のプロセッサ及びその周辺回路（例えば、ＣＰＵ（Central Processing Unit））から構成される。端末処理部２５は、端末記憶部２２に記憶されているプログラムが操作部２３の操作等に応じて適切な手順で実行されるように、端末通信部２１、及び表示部２４等の動作を制御する。端末処理部２５は、端末記憶部２２に記憶されているプログラム（オペレーティングシステムプログラム、ドライバプログラム、アプリケーションプログラム等）に基づいて処理を実行する。また、端末処理部２５は、複数のプログラム（アプリケーションプログラム等）を並列に実行することができる。

アクセス部２５１、スケジュール管理部２５２及びメッセージ管理部２５３は、端末処理部２５が備えるプロセッサで実行されるプログラムにより実現される機能モジュールである。あるいは、アクセス部２５１、スケジュール管理部２５２及びメッセージ管理部２５３は、ファームウェアとして幹事端末２に実装されてもよい。

アクセス部２５１は、Ｗｅｂ（World Wide Web）にアクセスし、表示データの取得及び表示を行う。即ち、アクセス部２５１は、幹事ユーザからの指示に応じて、イベントに関する入力又は選択等を端末通信部２１を介してサーバ４に送信する。また、アクセス部２５１は、イベントに関する入力又は選択等に対する処理結果に対応する表示データを、端末通信部２１を介してサーバ４から受信し、受信した表示データに基づいて画面を表示部２４に表示する。

スケジュール管理部２５２は、予めダウンロードしていた専用のスケジュール管理アプリケーションを用いてスケジュールを管理する。スケジュール管理部２５２は、カレンダーを表示部２４に表示するとともに、サーバ４から受信した画面情報に基づいて、登録された予定、イベントアイコンをカレンダー上に表示する。

メッセージ管理部２５３は、端末通信部２１を介してメッセージを送受信する。

図３（ｂ）は、ユーザ端末３の概略構成の一例を示す図である。

ユーザ端末３は、端末通信部３１、端末記憶部３２、操作部３３、表示部３４及び端末処理部３５等を備える。ユーザ端末３は、イベントに招集される複数の招集ユーザの端末である。ユーザ端末３として、多機能携帯電話が想定されるが、これに限定されるものではない。ユーザ端末３は、本発明が適用可能であればよく、例えば、携帯電話、携帯情報端末、タブレットＰＣ、パーソナルコンピュータ等でもよい。

ユーザ端末３が備える端末通信部３１、端末記憶部３２、操作部３３、表示部３４及び端末処理部３５は、幹事端末２が備える端末通信部２１、端末記憶部２２、操作部２３、表示部２４及び端末処理部２５と同様である。但し、端末処理部３５は、スケジュール管理部３５２及びメッセージ管理部３５３を有するが、端末処理部３５には、アクセス部２５１は、含まれない。

図４は、サーバ４の概略構成の一例を示す図である。

サーバ４は、サーバ通信部４１、サーバ記憶部４２、及びサーバ処理部４３を備える。サーバ４は、単独の装置で構成される。なお、サーバ４は、複数の装置で構成されてもよい。

サーバ通信部４１は、インターネット５を介してデータの送受信を行うための通信インターフェース回路を備え、ユーザ端末３と通信を行う。

サーバ記憶部４２は、例えば、磁気テープ装置、磁気ディスク装置、又は光ディスク装置のうちの少なくともいずれか一つを備え、サーバ処理部４３での処理に用いられるオペレーティングシステムプログラム、ドライバプログラム、アプリケーションプログラム、データ等を記憶する。また、サーバ記憶部４２は、データとして、ユーザ管理テーブル（図５（ａ））及び予定管理テーブル（図５（ｂ））を記憶する。また、サーバ記憶部４２は、データとして、施設管理テーブル（図６（ａ））、予約管理テーブル（図６（ｂ））及びイベント管理テーブル（図６（ｃ））を記憶する。また、サーバ記憶部４２は、所定の処理に係る一時的なデータを一時的に記憶するためのバッファを更に備える。

サーバ処理部４３は、抽出部４３１、決定部４３２、予約部４３３、出力部４３４、受付部４３５、管理部４３６及び通知部４３７等を備える。サーバ処理部４３は、サーバ４の全体的な動作を統括的に制御するものであり、一又は複数個のプロセッサ及びその周辺回路（例えば、ＣＰＵ）から構成される。また、サーバ処理部４３は、サーバ記憶部４２に記憶されているプログラム（オペレーティングシステムプログラム、ドライバプログラム、アプリケーションプログラム等）に基づき、適切な手順でサーバ通信部４１等の動作を制御する。さらに、サーバ処理部４３は、複数のプログラム（アプリケーションプログラム等）を並列に実行してもよい。

抽出部４３１、決定部４３２、予約部４３３、出力部４３４、受付部４３５、管理部４３６及び通知部４３７は、サーバ処理部４３が備えるプロセッサで実行されるプログラムにより実行される機能モジュールである。なお、抽出部４３１、決定部４３２、予約部４３３、出力部４３４、受付部４３５、管理部４３６及び通知部４３７は、ファームウェアとしてサーバ４に実装されてもよい。

抽出部４３１は、予定管理テーブルを参照し、全ての複数のユーザの予定が入っていない時間帯を抽出する。抽出部４３１の処理の詳細については後述する。

決定部４３２は、施設管理テーブル及び予約管理テーブルを参照し、抽出した時間帯に全ての複数のユーザが集合できる施設を決定する。決定部４３２の処理の詳細については後述する。

予約部４３３は、施設内の設備を仮予約し、仮予約した設備を予約管理テーブルに記憶する。また、予約部４３３は、参加の意思表示の数が設備の最低開催人数に達した場合、当該設備を本予約する。予約部４３３の処理の詳細については後述する。

出力部４３４は、サーバ通信部４１を介してユーザ端末３に画面情報を送信することにより、ユーザ端末３に画面情報を出力する。出力部４３４の処理の詳細については、後述する。

受付部４３５は、サーバ通信部４１を介してユーザ端末３から受信した設定を受付ける。受付部４３５の処理の詳細については後述する。

管理部４３６は、スケジュールの管理を行う。管理部４３６の処理の詳細については、後述する。

通知部４３７は、サーバ通信部４１を介してユーザ端末３に意思表示の依頼のメッセージを送信することにより、ユーザ端末３に意思表示の依頼のメッセージを通知する。通知部４３７の処理の詳細については、後述する。

図５（ａ）は、ユーザ管理テーブルのデータ構造の一例を示す図である。

図５（ａ）に示すデータ構造は、サーバ記憶部４２に記憶されているユーザIDに関連付けられた一連のデータを示している。ユーザIDは、招集ユーザを識別するための情報である。一連のデータは、例えば、ユーザ名、勤務先情報、許可情報及びＥメールアドレス等を含む。上記の一連のデータは一例であって、その他のユーザに関する情報を含んでもよい。ユーザ名は、招集ユーザの名前である。勤務先情報は、招集ユーザが勤務する勤務先を識別する情報、及び、招集ユーザが勤務する勤務先の名称を含む。許可情報は、ユーザの名前の出力を許可するか否かを示す情報である。許可情報は、例えば、許可又は不許可の何れかを示す。

図５（ｂ）は、予定管理テーブルのデータ構造の一例を示す図である。

予定管理テーブルは、ユーザごとに記憶される。図５（ｂ）に示すデータ構造は、サーバ記憶部４２に記憶されているユーザIDに関連付けられた一連のデータを示している。一連のデータは、例えば、予定ID、予定名、場所、開始日時及び終了日時等を含む。上記の一連のデータは一例であって、その他の予定に関する情報を含んでもよい。予定IDは、予定を識別するための情報である。予定は、招集ユーザの行事又は行動を予め定めたものであり、スケジュール管理アプリケーションによって管理されるデータである。予定名は、予定の名称である。場所は、予定が行われる地点を示す情報である。場所は、例えば、住所若しくは緯度及び経度である。予定の日時は、予定が行われる日程である。例えば、予定の日時として、予定の開始日時及び終了日時が指定される。また、予定の日時として、予定が行われる開始日時のみが指定されてもよい。また、予定の日時として、予定が行われる開始日時から所定時間が経過するための期間が指定されてもよい。また、場所が予定に設定されていない場合、勤務時間帯の予定の場所はユーザの勤務先の住所が記憶されていてもよく、勤務時間帯以外の予定の場所はユーザの自宅の住所が記憶されていてもよい。

図６（ａ）は、施設管理テーブルのデータ構造の一例を示す図である。

図６（ａ）に示すデータ構造は、サーバ記憶部４２に記憶されている施設IDに関連付けられた一連のデータを示している。一連のデータは、例えば、施設名、場所及び各設備等を含む。施設名は、施設の名称である。上記の一連のデータは一例であって、その他の施設に関する情報を含んでもよい。施設は、飲み会等のイベントが開催される飲食店又は会議室等の施設である。施設IDは、施設を識別する情報である。場所は、施設が配置された地点を示す情報である。場所は、例えば、住所若しくは緯度及び経度である。各設備は、施設内の各設備に関する情報である。設備は、施設において、招集ユーザを収容可能なものである。設備は、例えば、個室、テーブル等である。各設備は、施設内の施設のそれぞれについて、設備を識別する情報、設備の名称、及び設備の最大収容人数を含む。なお、施設管理テーブルのデータ構造は、テーブル形式に限らず、データをプールして蓄積するサーバ構造としてもよい。

図６（ｂ）は、予約管理テーブルのデータ構造の一例を示す図である。

予約管理テーブルは、施設内の設備ごとに記憶される。図６（ｂ）に示すデータ構造は、サーバ記憶部４２に記憶されている設備IDに関連付けられた一連のデータを示している。一連のデータは、例えば、予約ID、開始日時、終了日時、仮予約フラグ等を含む。上記の一連のデータは一例であって、その他の予約に関する情報を含んでもよい。設備IDは、設備を識別する情報である。予約IDは、予約を識別する情報である。予約の日時は、予約された日程である。例えば、予約の日時として、予約の開始日時及び終了日時が指定される。また、予約の日時として、予約の開始日時から所定時間が経過するまでの期間が指定されてもよい。仮予約フラグは、予約が仮予約である場合はtrue（真）を示し、予約が仮予約でなく、確定した予約である場合はfalse（偽）を示す情報である。なお、予約管理テーブルのデータ構造は、テーブル形式に限らず、データをプールして蓄積するサーバ構造としてもよい。

図６（ｃ）は、イベント管理テーブルのデータ構造の一例を示す図である。

図６（ｃ）に示すデータ構造は、サーバ記憶部４２に記憶されているイベントIDに関連付けられた一連のデータを示している。一連のデータは、例えば、イベント名、施設ID、予約ID、設備、利用可能数、招集ユーザID、出欠情報等を含む。上記の一連のデータは一例であって、その他のイベントに関する情報を含んでもよい。イベント名は、イベントの名前である。設備は、イベントが開催される設備について、設備を識別する情報、設備の名称、設備の最大収容人数及び最低開催人数を含む。利用可能数は、設備に対してこれから参加の意思表示をすることができるユーザ数である。すなわち、利用可能数は、設備に対して招集ユーザが利用できる空き情報を示す。招集ユーザIDは、イベントに招集されたユーザを識別する情報である。出欠情報は、招集ユーザのIDと、招集ユーザによって設定された参加可否情報とを含む。参加可否情報は、例えば参加及び不参加のうちの何れかを示す。なお、イベント管理テーブルのデータ構造は、テーブル形式に限らず、データをプールして蓄積するサーバ構造としてもよい。

上記施設管理テーブル、予約管理テーブル、およびイベント管理テーブルは、それぞれ個別のサーバから成ってもよく、いずれか２つ以上をまとめて１つまたは２つのサーバから成ってもよい。

図７は、予約システム１による動作シーケンスの一例を示す図である。

なお、以下に説明する動作シーケンスは、予め端末記憶部２２、端末記憶部３２及びサーバ記憶部４２に記憶されているプログラムに基づいて、主に端末処理部２５、端末処理部３５及びサーバ処理部４３により、幹事端末２、ユーザ端末３及びサーバ４の各要素と協働して実行される。

まず、幹事ユーザの操作に従って、幹事端末２のアクセス部２５１は、サーバ４にログインし、イベント設定画面情報取得要求をサーバ４に送信する（ステップＳ１００）。イベント設定画面情報取得要求は、イベント設定画面情報を取得するための要求である。イベント設定画面情報は、後述するイベント設定画面を表示するための情報である。

次に、サーバ４の出力部４３４は、幹事端末２からイベント設定画面情報取得要求を受信すると、出力部４３４は、イベント設定画面情報を幹事端末２に送信する（ステップＳ１０１）。出力部４３４は、ユーザ管理テーブルを参照し、イベント設定画面情報取得要求を送信した幹事ユーザのユーザID及びユーザ名を特定する。出力部４３４は、ユーザ管理テーブルを参照し、特定した幹事ユーザと同一のグループに所属する各招集ユーザのユーザID及びユーザ名を特定する。グループは、会社等の組織であってもよく、交流会等の任意のグループであってもよい。出力部４３４は、特定した幹事ユーザのユーザ名、同一のグループに所属する各招集ユーザのユーザID及びユーザ名を含むイベント設定画面情報を幹事端末２に送信する。

次に、幹事端末２のアクセス部２５１は、サーバ４からイベント設定画面情報を受信すると、受信したイベント設定画面情報に基づいてイベント設定画面を表示部２４に表示する（ステップＳ１０２）。

図８（ａ）は、幹事端末２に表示されるイベント設定画面の一例を示す図である。

イベント設定画面には、幹事ユーザ名８００、入力ボックス８０１、チェックボックス８０２、プルダウン８０３，８０４，８０５及び設定ボタン８０６が表示されている。

幹事ユーザ名８００は、幹事ユーザのユーザ名である。入力ボックス８０１はイベント名を入力するための入力領域である。チェックボックス８０２は、イベントに招集する複数の招集ユーザを選択するための選択領域である。チェックボックス８０２には、幹事ユーザと同一のグループに所属する各招集ユーザのユーザ名が選択可能に表示される。プルダウン８０３は、イベントの最低開催人数として、イベントが開催される、参加の意思表示したユーザの最低人数が指定可能に表示される。プルダウン８０４，８０５には、イベント時間帯として、イベントの開催日程、開始日時及び終了日時が指定可能に表示される。設定ボタン８０６は、幹事ユーザが招集ユーザ、イベントの最低開催人数及びイベント時間帯を設定するためのボタンである。

幹事ユーザが操作部２３を用いて設定ボタン８０６を押下すると、アクセス部２５１は、イベント設定画面で指定されたイベント名、各招集ユーザの招集ユーザID、最低開催人数及び各イベント時間帯をサーバ４に送信する（ステップＳ１０３）。サーバ４の受付部４３５は、幹事端末２から各情報を受信すると、受信した各情報をイベント管理テーブルに記憶する。

サーバ４の抽出部４３１は、全ての複数のユーザの予定が入っていない時間帯を予定管理テーブルから抽出する（ステップＳ１０４）。まず、抽出部４３１は、予定管理テーブルを参照し、ステップＳ１０３において受信した各イベント時間帯に、全ての招集ユーザの予定が入っていない時間帯を日時とともに抽出する。全ての複数のユーザの予定が入っていない時間帯は、イベントの開始日時から終了日時の候補となる。なお、予定として、勤務時間が設定されている場合は、予定が入っていない時間帯は、勤務時間が終了後（定時後）から予定が入っていない時間帯であってもよい。

次に、決定部４３２は、抽出した時間帯の直前に入っている全ての複数のユーザのそれぞれの予定の日時及び場所に基づいて、全ての複数のユーザが抽出した時間帯に集合できる施設を選択する（ステップＳ１０５）。まず、決定部４３２は、予定管理テーブルを参照し、抽出した時間帯の直前に入っている全ての招集ユーザのそれぞれの予定の日時及び場所を特定する。次に、決定部４３２は、施設管理テーブルを参照し、特定した予定の日時及び場所に基づいて、イベントの開始日時まで各招集ユーザが移動できる範囲を特定する。決定部４３２は、各招集ユーザの移動できる範囲が全て重なった範囲内の駅を特定する。決定部４３２は、決定した駅から所定距離（例えば、５００ｍ）以内のおすすめ度が最大の施設を選択する。施設のおすすめ度は、サーバ４が施設に対する評価データベース（不図示）から取得したものである。次に、決定部４３２は、予約管理テーブルを参照し、選択した施設内の設備のうち、抽出した時間帯に予約が入っておらず、招集ユーザが全員で利用できる設備があるか否かを判定する。抽出した時間帯に予約が入っておらず、招集ユーザが全員で利用できる設備があると判定した場合、決定部４３２は、選択した施設及び設備を、全ての招集ユーザが抽出した時間帯に集合できる施設として選択する。一方、抽出した時間帯に予約が入っておらず、招集ユーザが全員で利用できる設備がないと判定した場合、決定部４３２は、おすすめ度が次の順の施設の選択を行い、一連の処理を繰り返す。

なお、決定部４３２は、駅を特定する際に、特定した各招集ユーザの予定の場所の重心から一番近い駅を特定してもよい。また、決定部４３２は、駅を特定する際に、特定した各招集ユーザの予定の場所の最寄り駅のうち、一番多い最寄り駅を特定してもよい。

また、決定部４３２は、各招集ユーザが移動できる範囲を特定する範囲を特定する際に、直前の予定の終了日時からイベントの開始日時までの乗車時間で各招集ユーザが直前の予定の場所から電車移動できる駅を各招集ユーザが移動できる範囲としてもよい。

出力部４３４は、施設決定画面情報を幹事端末２に送信する（ステップＳ１０６）。施設決定画面情報は、後述する施設決定画面を表示するための情報である。出力部４３４は、ステップＳ１０４において抽出した予定が入っていない時間（イベントの開始日時から終了日時の候補）と、ステップＳ１０５において選択した施設及び設備を含む施設決定画面情報を幹事端末２に送信する。

次に、幹事端末２のアクセス部２５１は、サーバ４から施設決定画面情報を受信すると、受信した施設決定画面情報に基づいて施設決定画面を表示部２４に表示する（ステップＳ１０７）。

図８（ｂ）は、幹事端末２に表示される施設決定画面の一例を示す図である。

施設決定画面には、イベント開始日時及び終了日時並びに施設名及び設備名８１０，８１１、ラジオボタン８１２及び決定ボタン８１３が表示されている。

イベント開始日時及び終了日時並びに施設名及び設備名８１０，８１１は、イベントが開催される候補の情報である。ラジオボタン８１２は、イベント開始日時及び終了日時並びに施設を決定するための選択領域である。決定ボタン８１３は、幹事ユーザがイベント開始日時及び終了日時並びに施設を決定するためのボタンである。

幹事ユーザが操作部２３を用いて決定ボタン８１３を押下すると、アクセス部２５１は、施設決定画面で指定されたイベント開始日時及び終了日時並びに施設名の施設ID及び設備名の設備IDをサーバ４に送信する（ステップＳ１０８）。

次に、決定部４３２は、幹事端末２からイベント開始日時及び終了日時並びに施設名の施設ID及び設備名の設備IDを受信すると、全ての複数のユーザが集合できる施設を決定する（ステップＳ１０９）。決定部４３２は、受信した施設IDの施設を、全ての複数のユーザが集合できる施設に決定する。

次に、予約部４３３は、決定した施設内の設備を仮予約する（ステップＳ１１０）。予約部４３３は、ステップＳ１０８において受信した設備に新たな予約IDを割り当て、受信した設備の設備ID、受信したイベント開始日時及び終了日時を関連付けて予約管理テーブルに記憶する。予約部４３３は、ユーザ管理テーブルを参照し、ステップＳ１０３において受信した招集ユーザの招集ユーザIDを特定する。予約部４３３は、割り当てた予約IDに新たなイベントIDを割り当て、ステップＳ１０３において受信したイベント名、受信した施設ID、受信した設備に関する情報、特定した招集ユーザIDを関連付けてイベント管理テーブルに記憶する。さらに、予約部４３３は、受信した設備の最大収容人数を利用可能人数としてイベント管理テーブルに記憶する。

次に、通知部４３７は、意思表示の依頼のメッセージを各招集ユーザのユーザ端末３に通知する（ステップＳ１１１）。ユーザ端末３のメッセージ管理部３５３は、サーバ４からメッセージを受信すると、受信したメッセージを表示部３４に表示する。

図８（ｃ）は、ユーザ端末３に表示されるメッセージの一例を示す図である。

メッセージには、差出人８２０、宛先８２１、イベント名８２２、イベントに関する情報８２３及び依頼テキスト８２４が含まれる。差出人８２０として、幹事ユーザのユーザ名が表示される。宛先８２１として、各招集ユーザの招集ユーザ名が表示される。イベント名８２２として、図８（ａ）の入力ボックス８０１において入力されたイベント名が表示される。イベントに関する情報８２３として、図８（ｂ）のラジオボタン８１２において選択された施設のイベントに関する情報が表示される。

スケジュール管理部３５２は、招集ユーザの操作に従って、スケジュール管理アプリケーションを起動する（ステップＳ１１２）。

次に、スケジュール管理部３５２は、カレンダー表示情報取得要求及びイベント画面情報取得要求をサーバ４に送信する（ステップＳ１１３）。カレンダー表示情報取得要求は、カレンダー表示情報を取得するための要求である。イベント画面情報取得要求は、イベント画面情報を取得するための要求である。

また、管理部４３６は、ユーザ端末３からカレンダー表示情報取得要求及びイベント画面情報取得要求を受信すると、カレンダー表示情報及びイベント画面情報を作成する。カレンダー表示情報は、予定をカレンダー形式に表示するための表示データである。イベント画面情報は、参加の意思表示を受付けるための画面を表示するための表示データである。

管理部４３６は、イベント管理テーブルを参照し、イベント画面情報取得要求を送信したユーザ端末３の招集ユーザが招集されているイベント名を特定する。管理部４３６は、イベント管理テーブル及び施設管理テーブルを参照し、招集されたイベントの施設名及び設備名を特定する。管理部４３６は、イベント管理テーブル及び予約管理テーブルを参照し、イベントの開始日時及び終了日時を特定する。管理部４３６は、イベント管理テーブルを参照し、設備の利用可能数を特定する。

管理部４３６は、イベント管理テーブル及びユーザ管理テーブルを参照し、参加の意思表示した招集ユーザの許可情報が許可を示す場合は、招集ユーザの名前及び招集ユーザの勤務先名を特定する。したがって、管理部４３６は、参加の意思表示した招集ユーザごとに、各招集ユーザの許可情報が各招集ユーザの名前の出力を許可することを示す場合は各招集ユーザの名前を出力するように制御する。

一方、管理部４３６は、イベント管理テーブル及びユーザ管理テーブルを参照し、参加の意思表示した招集ユーザの許可情報が不許可を示す場合は、各招集ユーザの名前を特定せずに、参加の意思表示した招集ユーザのうち、許可情報が不許可である招集ユーザの数をカウントする。管理部４３６は、カウントした数を特定する。したがって、管理部４３６は、各招集ユーザの許可情報が各招集ユーザの名前の出力を許可しないことを示す場合は各招集ユーザの名前を出力しないように制御する。

管理部４３６は、特定した各情報を含むイベント画面情報を作成する。なお、特定した利用可能数がゼロになると、管理部４３６は、イベント画面情報を作成しない。そのため、イベントに参加する参加ユーザ以外のカレンダーにイベントアイコン９０１が表示されなくなる。これにより、管理部４３６は、設備の利用可能人数がゼロになると、参加の意思表示していない招集ユーザのユーザ端末に利用可能人数を出力しないように制御することができる。

次に、管理部４３６は、予定管理テーブルを参照し、カレンダー表示情報取得要求及びイベント画面情報取得要求を送信した招集ユーザの予定を特定する。管理部４３６は、特定した招集ユーザの予定を含むカレンダー表示情報を作成する。カレンダー表示情報は、予定をカレンダー形式に表示するための表示データである。

出力部４３４は、作成したカレンダー表示情報及びイベント画面情報をユーザ端末３に送信する（ステップＳ１１４）。

ユーザ端末３のスケジュール管理部３５２は、サーバ４からカレンダー表示情報及びイベント画面情報を受信すると、受信したカレンダー表示情報及びイベント画面情報に基づいてイベント画面を表示部３４に表示する（ステップＳ１１５）。まず、スケジュール管理部３５２は、受信したカレンダー表示情報に従って、招集ユーザの予定９００をカレンダー上に表示する。さらに、スケジュール管理部３５２は、受信したイベント画面情報に含まれるイベントの開始日時及び終了日時に従って、イベントアイコン９０１を、イベントの開始日時及び終了日時のカレンダー上に表示する。

図９（ａ）は、ユーザ端末３に表示されるイベント画面の一例を示す図である。

イベント画面には、招集ユーザの予定９００及びイベントアイコン９０１が表示されている。

招集ユーザの予定９００は、カレンダー表示情報に従って表示される。イベントアイコン９０１は、イベント画面情報に含まれるイベントの開始日時及び終了日時に従って表示される。

次に、スケジュール管理部３５２は、参加の意思表示の入力を受付ける（ステップＳ１１６）。スケジュール管理部３５２は、招集ユーザによってイベントアイコン９０１が指定された場合、対応するイベントに係る参加可否設定ウィンドウを表示する。

図９（ｂ）は、ユーザ端末３に表示される参加可否設定ウィンドウ９１０の一例を示す図である。

参加可否設定ウィンドウ９１０には、参加ボタン９１１、不参加ボタン９１２、イベントに関する情報９１３、施設名９１４、設備名９１５、利用可能数９１６及び参加ユーザに関する情報９１７が表示される。

参加ユーザに関する情報９１７には、名前の出力が許可されていない参加ユーザの数と、名前の出力が許可される参加ユーザの名前及び勤務先名が表示される。参加ユーザは、招集ユーザのうち参加の意思表示をしたユーザである。これにより、参加ユーザのプライバシーを守りつつ、招集ユーザは、他の参加ユーザの名前及び勤務先名を閲覧し、イベントに参加するか否かを判断することができる。

次に、招集ユーザの操作に従って、参加ボタン９１１が押下されると、スケジュール管理部３５２は、参加の意思表示をサーバ４に送信する（ステップＳ１１７）。招集ユーザの操作に従って、参加ボタン９１１及び不参加ボタン９１２のうちの何れかのボタンが押下されると、スケジュール管理部２５２は、押下されたボタンに対応する参加可否情報をサーバ４に送信する。ここで、参加可否情報が参加を示す場合、スケジュール管理部３５２は、参加の意思表示をサーバ４に送信することになる。

サーバ４の受付部４３５は、ユーザ端末３から参加の意思表示を受信すると、参加の意思表示を受付ける（ステップＳ１１８）。受付部４３５は、ユーザ端末３から受信した参加可否情報を特定する。受付部４３５は、ユーザ管理テーブルを参照し、参加可否情報を送信した招集ユーザのユーザIDを特定する。受付部４３５は、意思表示したイベントに関連づけて、特定したユーザID及び受信した参加可否情報をイベント管理テーブルに記憶する。受付部４３５は、イベント管理テーブルを参照し、設備の利用可能人数をデクリメントする。デクリメントは、１を引くことを意味する。

参加可否情報が参加を示す場合、受付部４３５は、イベント管理テーブルを参照し、意思表示したイベントのイベント名を特定する。受付部４３５は、イベント管理テーブル及び施設管理テーブルを参照し、イベントの施設の場所を特定する。受付部４３５は、イベント管理テーブル及び予約管理テーブルを参照し、イベントの開始日時及び終了日時を特定する。受付部４３５は、特定した各種情報を参加の意思表示した招集ユーザの予定として、参加の意思表示した招集ユーザのユーザIDと関連付けて予約管理テーブルに登録する。これにより、招集ユーザは、イベントの予定を登録しなくても、参加ボタンを押下することにより、予定を登録することができる。

次に、予約部４３３は、施設内の設備を本予約する（ステップＳ１１９）。予約部４３３は、イベント管理テーブルを参照し、参加を示す参加可否情報の数をカウントすることにより、受付けた参加の意思表示の数をカウントする。予約部４３３は、イベント管理テーブルを参照し、イベントの開始日時の所定期間（例えば、二日）前までにカウントした参加の意思表示の数が設備の最低開催人数に達した場合、設備を本予約する。すなわち、予約部４３３は、予約管理テーブルを参照し、予約を確定した設備の仮予約フラグを”true”から”false”に変更する。

一方、イベントの開始日時の所定期間前までにカウントした参加の意思表示の数が設備の最低開催人数に達しない場合、予約部４３３は、最低開催人数に達しない設備の仮予約をキャンセルする。すなわち、予約部４３３は、最低開催人数に達しない設備の予約を予約管理テーブルから削除する。その場合、予約部４３３は、イベント管理テーブルを参照し、既に参加の意思表示した招集ユーザがいるか否かを判定する。既に参加の意思表示した招集ユーザがいる場合、予約部４３３は、参加の意思表示した招集ユーザのイベントの予定をキャンセルする。すなわち、予約部４３３は、参加の意思表示した招集ユーザのイベントの予定を予定管理テーブルから削除する。これにより、招集ユーザは、イベントの予定の削除を自身で行わなくても、予約部４３３は、イベントがキャンセルになった場合に、イベントの予定も連動して削除する。

以上で、予約システム１による動作シーケンスは終了する。なお、予約システム１は、ステップＳ１１１〜１１７の処理を幹事端末２に対して実行してもよい。

このように、サーバ４は、施設内の設備を仮予約し、受付けた参加の意思表示の数に応じて、設備を本予約する。したがって、サーバ４は、幹事ユーザに負担をかけずに自動的に予約を確定できる。

なお、本発明は、図１〜９に示した実施形態に限定されるものではない。例えば、以下に示すように、変更及び修正することができる。

（１）スケジュール管理部３５２は、スケジュール管理アプリケーションを用いてスケジュールを管理するのではなく、Ｗｅｂサーバにアクセスすることによりスケジュールを管理してもよい。この場合、図７のステップＳ１１２において、アクセス部２５１は、スケジュール管理アプリケーションを起動する代わりに、Ｗｅｂサーバとして動作するサーバ４にアクセスすることにより、カレンダー表示情報及びイベント画面情報取得要求をサーバ４に送信する。これにより、招集ユーザは専用のスケジュール管理アプリケーションを予めダウンロードしなくてよい。

（２）図７のステップＳ１０２，１０３のイベントを設定する処理、ステップＳ１０７，１０８の施設を決定する処理を幹事端末２ではなく、サーバ４が実行してもよい。この場合、図７のステップＳ１０２，１０３，１０７，１０８の処理がサーバ４のサーバ記憶部４２に記憶された所定のプログラムにより自動的に実行される。

（３）図８（ａ）に示すイベントに招集する複数の招集ユーザは、社内の社員のユーザ又は社外の社員のユーザであってもよい。これにより、参加ユーザは、社内の社員のユーザ又は社外の社員のユーザと交流を深めることができる。

（４）端末処理部２５、端末処理部３５及びサーバ処理部４３が備える各機能をコンピュータに実現させるためのコンピュータプログラムは、磁気記録媒体、光記録媒体等のコンピュータにより読み取り可能な記録媒体に記憶された形で提供されてもよい。

（５）サーバ４の管理部４３６は、他のスケジュール管理を行うサーバから予定管理テーブルに記憶されたデータのうちの必要なデータを取得してもよい。この場合、管理部４３６は、予定管理テーブルに対して行った変更を他のスケジュール管理を行うサーバに通知し、予定管理テーブルに記憶されたデータを同期する。これにより、サーバ４は、サーバ記憶部４２の記憶容量の削減をすることができる。

（６）サーバ４の予約部４３３は、他の施設の設備の予約を行うサーバから予約管理テーブルに記憶されたデータのうちの必要なデータを取得してもよい。この場合、予約部４３３は、予約管理テーブルに対して行った変更を他の施設の設備を行うサーバに通知し、予約管理テーブルに記憶されたデータを同期する。これにより、サーバ４は、サーバ記憶部４２の記憶容量の削減をすることができる。

（７）予約部４３３は、図７のステップＳ１１０の処理において、施設内の設備を仮予約することに代えて、施設内の設備を予約することにより、施設内の設備を確保してもよい。また、予約部４３３は、図７のステップＳ１１９の処理において、施設内の設備を本予約することに代えて、施設内の設備の予約を維持することにより、予約を確定させてもよい。

（８）図９（ｂ）に示す参加の意思表示は、二名以上の参加の意思表示であってもよい。

図１０（ａ）は、二名以上の参加の意思表示できる参加可否設定ウィンドウ１０００の一例を示す図である。

参加可否設定ウィンドウ１０００には、参加ボタン１００１、一名追加参加ボタン１００２、二名追加参加ボタン１００３、及び不参加ボタン１００４が表示される。

次に、招集ユーザの操作に従って、一名追加参加ボタン１００２が押下されると、スケジュール管理部３５２は、二名の参加の意思表示をサーバ４に送信する。招集ユーザの操作に従って、二名追加参加ボタン１００３が押下されると、スケジュール管理部３５２は、三名の参加の意思表示をサーバ４に送信する。これにより、招集ユーザは、自身の友達とともにイベントに参加することができる。追加参加ボタン１００２，１００３は、三名以上の追加参加ボタンであってもよい。

受付部４３５は、ユーザ端末３から二名又は三名の参加の意思表示を受信すると、二名又は三名の参加の意思表示を受付ける。受付部４３５は、図７のステップＳ１１８と同様に、特定したイベントIDに関連づけて、特定したユーザID及び受信した参加可否情報をイベント管理テーブルに記憶する。さらに、受付部４３５は、参加の意思表示した人数を参加人数としてイベント管理テーブルに記憶する。但し、イベント管理テーブルは、図６（ｃ）に示したイベント管理テーブルに代えて、図１０（ｂ）に示したイベント管理テーブルである。イベント管理テーブルの出欠情報は、招集ユーザIDと、招集ユーザによって設定された参加可否情報と、参加人数とを含む。

（９）また、予約システム１は、幹事端末２を所有する幹事ユーザによって設定されたイベントの予約を管理するだけでなく、施設を所有及び／又は運営する施設管理者によって設定されたイベントの予約を管理してもよい。以下、図１１を参照して、本変形例について説明する。

予約システム１は、ユーザ端末３、サーバ４及び施設端末６を有する。施設端末６は、施設関係者が所有するコンピュータ等であって、例えば、施設が飲食店である場合、施設端末６は、飲食店関係者が経営する飲食店の店舗等に設置される。

まず、施設端末６において、施設関係者によって施設利用可能時間が入力される（図１１の（１））。施設利用可能時間は、イベントの開始日時及び終了日時等であり、図１１の（１）に示される例では、イベントの開始日時として８月２４日の１９時００分が入力され、且つ、イベントの終了日時として８月２４日の２１時００分が入力される。例えば、施設端末６は、図８（ａ）のイベント設定画面の例で示されるプルダウン８０４及び８０５と同様の入力フォームを表示し、施設関係者は、表示された入力フォームを操作することによって、施設利用可能時間を入力する。

また、入力される施設利用可能時間に係るイベントの参加人数に上限がある場合、施設関係者によってイベントの利用可能人数（最大収容人数）が入力される。図１１の（１）に示される例では、イベントの利用可能人数として１６人が入力される。例えば、施設端末６は、図８（ａ）のイベント設定画面の例で示されるプルダウン８０３と同様の入力フォームを表示し、施設関係者は、表示された入力フォームを操作することによって、利用可能人数を入力する。なお、利用可能人数は、空席情報の一例である。

ここでは、施設端末６から施設利用可能時間を送信する構成としたが、サーバ４が施設の予約情報を管理している場合は、予約の存在しない時間帯を施設利用可能時間と認識して以降の処理に進んでもよい。

次に、施設端末６は、入力された施設利用可能時間をサーバ４に送信する。サーバ４の受付部４３５は、施設端末６から送信された施設利用可能時間を、サーバ通信部４１を介して受信し、受信した施設利用可能時間を予約管理テーブルに記憶（登録）する（図１１の（２））。なお、施設端末６において、施設利用可能時間に係るイベントの利用可能人数が入力された場合、施設利用可能時間とともに利用可能人数がサーバ４に送信され、サーバ４は、施設利用可能時間と利用可能人数とを関連付けて予約管理テーブルに記憶する。

次に、サーバ４の通知部４３７は、送信先及び送信タイミングを参照して、登録された施設利用可能時間を含む意思表示の依頼のメッセージを、サーバ通信部４１を介してユーザ端末３に通知する（図１１の（３））。

送信先は、登録された施設利用可能時間の送信先となるグループに所属するユーザ等である。サーバ記憶部４２は、送信先として設定されたグループに所属するユーザを、各施設利用可能時間に関連付けて記憶する。例えば、まず、サーバ４の受付部４３５は、施設利用可能時間が登録されると、予定管理テーブルを参照して、登録された施設利用可能時間の開始時間の直前に設定された各ユーザの予定に関連付けられた場所を抽出する。次に、受付部４３５は、施設管理テーブルを参照して、施設利用可能時間に係る施設の場所を抽出する。次に、受付部４３５は、施設の場所から所定の範囲内の場所に関連付けられた予定のユーザを特定する。そして、受付部４３５は、特定したユーザの数が所定の下限数を超えるグループを、送信先のグループとして設定し、設定された送信先のグループを、登録された施設利用可能時間に関連付けてサーバ記憶部４２に記憶する。なお、下限数は、後述する第１所定数以上である。なお、送信先のグループは、所定のグループの一例である。

なお、場所は、エリア情報の一例であり、予定は、スケジュールの一例であり、施設が存在するエリア情報から所定の範囲内に位置するエリア情報は、施設が存在するエリア情報と特定の関係であるエリア情報の一例である。また、登録された施設利用可能時間の開始時間の直前に設定された各ユーザの予定に関連付けられた場所は、ユーザに関連するエリア情報の一例である。

また、例えば、施設端末６は、施設利用可能時間とともに、送信先のグループを入力してもよく、この場合、受付部４３５は、施設利用可能時間とともに受信した送信先のグループを、登録された施設利用可能時間に関連付けてサーバ記憶部４２に記憶する。

送信タイミングは、登録された施設利用可能時間を送信する日時である。サーバ記憶部４２は、送信タイミングとして設定された日時を、各施設利用可能時間に関連付けて記憶する。例えば、サーバ４の受付部４３５は、施設利用可能時間が登録されると、登録された施設利用可能時間の開始時間から所定時間前（例えば、６時間前）の日時を、送信タイミングとして設定し、設定された送信タイミングを、登録された施設利用可能時間に関連付けてサーバ記憶部４２に記憶する。また、例えば、施設端末６は、施設利用可能時間とともに、日時を入力して、サーバ４に送信してもよく、この場合、受付部４３５は、施設利用可能時間とともに受信した日時を、送信タイミングとして設定し、設定された送信タイミングを、登録された施設利用可能時間に関連付けてサーバ記憶部４２に記憶する。

次に、ユーザ端末３のメッセージ管理部３５３は、サーバ４から送信されたメッセージを、端末通信部３１を介して受信した場合、受信したメッセージを表示部３４に表示する。なお、表示部３４に表示されるメッセージは、図８（ｃ）に示される例と同様のメッセージであるが、差出人８２０として、メッセージに含まれる施設利用可能時間に係る施設の名称が表示される。また、宛先８２１として、送信先となるグループに所属するユーザのユーザ名が表示される。

次に、メッセージ管理部３５３は、ユーザの操作に従って、スケジュール管理アプリケーションを起動し、カレンダー表示情報取得要求を、端末通信部３１を介してサーバ４に送信する。次に、サーバ４の管理部４３６は、サーバ通信部４１を介してカレンダー表示情報取得要求を受信すると、予定管理テーブルを参照して、カレンダー表示情報取得要求を送信したユーザの予定を特定し、特定した予定を含むカレンダー表示情報を作成する。サーバ４の出力部４３４は、作成したカレンダー表示情報を、カレンダー表示情報取得要求を送信したユーザのユーザ端末３に、サーバ通信部４１を介して送信する。

次に、ユーザ端末３のスケジュール管理部３５２は、端末通信部３１を介してサーバ４からのカレンダー表示情報を受信した場合、受信したカレンダー表示情報、メッセージに含まれる施設利用可能時間及び施設の名称等に基づいてイベント画面を表示部３４に表示する。なお、表示部３４に表示されるイベント画面は、図９（ａ）に示される例と同様のイベント画面であるが、イベント画面には、施設利用可能時間に対応するイベントアイコン９０１が表示され、イベントアイコン９０１内に、施設利用可能時間に係る施設の名称が表示される。また、イベント画面は、スケジュール管理画面の一例である。

なお、スケジュール管理部３５２は、イベント画面のイベントアイコン９０１の表示領域に、ユーザ端末３を所有するユーザの予定が登録されていない場合に限り、イベントアイコン９０１を表示してもよい。すなわち、イベントアイコン９０１に対応する施設利用可能時間の少なくとも一部が、ユーザ端末３を所有するユーザの予定に含まれる場合、イベントアイコン９０１は表示されない。

次に、スケジュール管理部３５２は、参加の意思表示の入力を受付ける。すなわち、スケジュール管理部３５２は、ユーザによって、イベントアイコン９０１又はイベントアイコン９０１内に表示された施設の名称が指定された場合、対応するイベントに係る参加可否設定ウィンドウを表示部３４に表示する。なお、表示部３４に表示される参加可否設定ウィンドウは、図９（ｂ）に示される例と同様の参加可否設定ウィンドウである。ここで、参加可否設定ウィンドウに表示される参加ユーザは、ユーザと同一のグループに所属し且つ参加の意思表示をしたユーザである。

次に、招集ユーザの操作に従って、参加可否設定ウィンドウに表示される参加ボタン９１１及び不参加ボタン９１２のうちの何れかのボタンが押下されると、スケジュール管理部２５２は、押下されたボタンに対応する参加可否情報をサーバ４に送信する。ここで、参加可否情報が参加を示す場合、スケジュール管理部３５２は、参加の意思表示をサーバ４に送信することになる。なお、図１０（ａ）に示されるように、複数人数分の参加を示す参加可否情報が、入力されて、サーバ４に送信されてもよい。

次に、サーバ４の受付部４３５は、ユーザ端末３から送信された参加の意思表示を、サーバ通信部４１を介して受信した場合、受信した参加の意思表示を受付ける。受付部４３５は、ユーザ端末３から受信した参加可否情報を特定し、ユーザ管理テーブルを参照して、参加可否情報を送信したユーザのユーザＩＤを特定する。受付部４３５は、意思表示したイベントに関連づけて、特定したユーザＩＤ及び受信した参加可否情報をサーバ記憶部４２に記憶するとともに、グループごとに参加を示す参加可否情報を送信したユーザの数を集計する。なお、参加を示す参加可否情報は、参加登録の一例である。以降、参加可否情報を送信したユーザの数を参加登録者数と称する。

次に、予約部４３３は、最初に参加登録者数が第１所定数を超えたグループを利用グループとして特定し、特定された利用グループをサーバ記憶部４２に記憶する。図１１の（４）に示される例では、第１所定数は１２人である。なお、第１所定数は、利用可能人数未満に設定される。なお、受付部４３５は、利用グループとして特定されたグループに含まれ且つ参加を示す参加可否情報を送信したユーザ端末３を所有するユーザの数が、利用可能人数に到達した場合、当該利用グループに所属する他のユーザのユーザ端末３から送信された、参加を示す参加可否情報を、以降、受け付けない。なお、送信先のグループが１つしか存在しない場合や、送信先のグループを１つと限定する場合は、単に予約部４３３は、最初に参加登録者数が第１所定数を超えた場合に、送信先のグループをサーバ記憶部４２に記憶すればよい。

そして、サーバ４の予約部４３３は、特定された利用グループに含まれるユーザが所有し且つ参加を示す参加可否情報を送信したユーザ端末３に、参加案内情報を、サーバ通信部４１を介して送信する（図１１の（５））。参加案内情報は、施設利用可能時間に係るイベント、利用グループによって行われることを示すメッセージである。なお、参加案内情報に参加の可否を再確認する入力フォームに係る情報が含まれてもよい。

以上により、予約システム１による、施設管理者によって設定されたイベントの予約の管理が終了する。

従来、飲食店の店舗等の施設を利用者が予約する場合、利用者は、電話等を用いて施設を所有及び／又は運営する施設管理者に連絡して、予約の申し入れを行っていた。近年では、利用者は、インターネットを介して施設のウェブサイトの予約ページを用いて、当該施設の予約を行うことが可能となっていた。しかしながら、利用者が予約ページを用いて施設を予約する予約システムでは、施設管理者は、店舗等の施設の利用者がいない時間帯に対する集客を行うことができなかった。図１１によって示された、施設を所有及び／又は運営する施設管理者によって設定されたイベントの予約を管理する予約システム１は、このような課題を解決すべくなされたものであり、店舗等の施設の利用者がいない時間帯に対する集客を可能とする制御方法、制御プログラム、及びサーバを提供することを目的とするものである。そして、図１１によって示された、施設を所有及び／又は運営する施設管理者によって設定されたイベントの予約を管理する予約システム１によって、施設管理者は、店舗等の施設の利用者がいない時間帯に対する集客を実施することが可能になる。

なお、図１１の（３）で示される、登録された施設利用可能時間を含む意思表示の依頼のメッセージの送信において、送信先のグループに含まれる複数のユーザのうち、施設利用可能時間にスケジュールが登録されていないユーザの数が、所定の下限数を超える場合、送信先のグループに含まれ且つ施設利用可能時間に予定が登録されていない各ユーザのユーザ端末３に、登録された施設利用可能時間を含む意思表示の依頼のメッセージを送信してもよい。なお、所定の下限数は、第１所定数以上であり、第２所定数の一例である。これにより、施設利用可能なユーザが少ないグループに対して施設利用可能時間を送信することを防止することが可能となり、

また、図１１の（３）で示される、登録された施設利用可能時間を含む意思表示の依頼のメッセージの送信において、送信先のグループに含まれる複数のユーザのうち、施設利用可能時間より前に予定が登録されているユーザの数が、所定の下限数を超える場合、送信先のグループに含まれ且つ施設利用可能時間に予定が登録されておらず且つ施設利用可能時間より前に予定が登録されている各ユーザのユーザ端末３に、登録された施設利用可能時間を含む意思表示の依頼のメッセージを送信してもよい。

また、図１１の（３）で示される、登録された施設利用可能時間を含む意思表示の依頼のメッセージの送信において、送信先のグループの設定処理に、所定の条件を適用してもよい。例えば、図１１の（５）で示される参加案内情報の送信において、サーバ４の予約部４３３は、参加案内情報を送信したユーザ端末３を所有するユーザの履歴を、利用グループに関連付けてサーバ記憶部４２に記憶する。サーバ４の通知部４３７は、図１１の（３）で示される、登録された施設利用可能時間を含む意思表示の依頼のメッセージの送信において、サーバ記憶部４２に記憶されたユーザの履歴数が多いグループほど、優先的にメッセージを送信する。なお、優先的にメッセージを送信することとは、例えば、送信先のグループとして設定された他のグループよりも速い送信タイミングでメッセージを送信すること、メッセージに特定のクーポン情報を付加すること等である。

また、図１１の（３）で示される、登録された施設利用可能時間を含む意思表示の依頼のメッセージの送信に、所定の制限を設定してもよい。例えば、サーバ４の通知部４３７は、登録された施設利用可能時間を含む意思表示の依頼のメッセージを、送信先のグループに所属する各ユーザのユーザ端末３に送信する前に、当該メッセージに含まれる施設利用可能時間の日付と同日の施設利用可能時間を含む他のメッセージの当該ユーザ端末３に対する送信数が、所定の送信上限数を超えているか否か判定する。そして、通知部４３７は、過去に当該所定の送信上限数を超えるメッセージを送信していると判定したユーザ端末３には、メッセージを送信しないようにしてもよい。なお、送信上限数は、第３所定数の一例である。また、例えば、各ユーザ端末３を所有するユーザの予定のうちの施設利用可能時間の日付と同日の最後の予定の終了時刻が施設利用可能時間よりも前に登録されている場合、通知部４３７は、施設利用可能時間及び施設が存在する場所と最後の予定の終了時刻及び当該終了時刻においてユーザが存在する場所（最後の予定の場所）とに基づいて、各ユーザ端末３を所有するユーザが、施設利用可能時間までに施設が存在する場所に到着可能であるか否かを判別する。そして、通知部４３７は、施設利用可能時間までに施設が存在する場所に到着可能であると判別されたユーザが所有するユーザ端末３に限り、登録された施設利用可能時間を含む意思表示の依頼のメッセージを送信するようにしてもよい。

また、ユーザ端末３のスケジュール管理部３５２による参加の意思表示の送信に、所定の制限を設定してもよい。例えば、サーバ４の予約部４３３は、ユーザ端末３への参加案内情報の送信後に、サーバ記憶部４２に記憶された、参加案内情報に対応するユーザ端末３の参加登録を削除する。予約部４３３は、ユーザ端末３ごとに、記憶された参加登録の参加登録数を計数し、所定のタイミングで、各ユーザ端末３に参加登録数を、サーバ通信部４１を介して送信する。次に、ユーザ端末３は、サーバ４から送信された参加登録数を端末記憶部２２に記憶する。そして、ユーザ端末３のスケジュール管理部３５２は、参加の意思表示の送信の前に、参加登録数が登録上限数を超えるか否かを判定し、参加登録数が登録上限数を超える場合、参加登録を送信しないようにしてもよい。なお、登録上限数は、第４所定数の一例である。

また、施設端末６は、インターネット５（図２）を介してサーバ４に接続し、サーバ４と通信を行う。施設端末６として、パーソナルコンピュータ（Personal Computer, PC）を想定するが、本発明はこれに限定されない。施設端末６は、本発明が適用可能であればよく、例えば、多機能携帯電話（所謂「スマートフォン」）、携帯電話（所謂「フィーチャーフォン」）、ＰＤＡ、携帯ゲーム機、携帯音楽プレーヤ、タブレット端末、タブレットＰＣ、ノートＰＣ等の情報処理装置でもよい。また、施設端末６は、飲食店に設置され且つ飲食店の関係者等が扱うメニュー端末等であってもよい。

当業者は、本発明の精神及び範囲から外れることなく、様々な変更、置換及び修正をこれに加えることが可能であることを理解されたい。

１ 予約システム
２ 幹事端末
３ ユーザ端末
４ サーバ
４３１ 抽出部
４３２ 決定部
４３３ 予約部
４３４ 出力部
４３５ 受付部
４３６ 管理部
４３７ 通知部
５ インターネット
６ 施設端末

Claims (18)

1. 記憶部を備えるサーバの制御方法であって、
   複数のグループのそれぞれに含まれる複数のユーザを前記記憶部に記憶し、
   施設端末から送信された施設利用可能時間を前記記憶部に記憶し、
   前記複数のユーザのそれぞれに関連するエリア情報及び前記施設端末に係る施設が存在するエリア情報を前記記憶部に記憶し、
   前記複数のグループのうちの所定のグループに含まれる複数のユーザのそれぞれに関連する前記エリア情報と前記施設が存在するエリア情報とが特定の関係であるか否かを判定し、
   前記施設が存在するエリア情報と特定の関係であると判定された前記エリア情報に関連するユーザが所有する各ユーザ端末に、前記施設の施設端末から送信された前記施設利用可能時間を送信し、
   前記施設利用可能時間を受信したユーザ端末から送信された、前記施設利用可能時間において当該施設におけるイベントに参加する意思表示を受け付け、当該参加の意思表示を前記記憶部に記憶し、
   前記記憶した参加の意思表示の数が、第１所定数を超えた場合に、前記所定のグループを利用グループとして前記記憶部に記憶する、
   ことを含むことを特徴とする制御方法。
2. 前記利用グループの記憶において、
   前記施設利用可能時間が複数の所定のグループに含まれる複数のユーザのそれぞれが所有する各ユーザ端末に送信される場合に、前記記憶された参加の意思表示の数を、グループごとに計数し、
   前記計数した参加の意思表示の数が、最初に前記第１所定数を超えたグループを前記利用グループとして特定する、請求項１に記載の制御方法。
3. 前記ユーザ端末を所有するユーザのスケジュールを管理するためのスケジュール管理画面を表示するための表示データを、前記ユーザ端末に送信し、
   前記スケジュール管理画面の前記施設利用可能時間に対応する表示領域に、前記施設利用可能時間に係る施設の名称を表示するための表示データを、前記ユーザ端末に送信する、請求項１に記載の制御方法。
4. 前記スケジュール管理画面を表示するための表示データは、前記施設利用可能時間に対応する表示領域に、当該ユーザ端末を所有するユーザのスケジュールが登録されていない場合に限り、前記施設利用可能時間に係る施設の名称を表示するための表示データである、請求項３に記載の制御方法。
5. 前記複数のユーザのそれぞれが所有する各ユーザ端末によって登録された、各ユーザ端末を所有するユーザのスケジュールを、当該スケジュールの開始日時及び終了日時とともに前記記憶部に記憶し、
   前記施設利用可能時間の送信において、前記所定のグループに含まれる複数のユーザのうち、前記施設利用可能時間にスケジュールが登録されていないユーザの数が、第２所定数を超える場合、前記所定のグループに含まれ且つ前記施設利用可能時間にスケジュールが登録されていない各ユーザのユーザ端末に、前記施設利用可能時間を送信する、請求項３または４に記載の制御方法。
6. 前記施設利用可能時間の送信において、前記所定のグループに含まれる複数のユーザのうち、前記施設利用可能時間より前にスケジュールが登録されているユーザの数が、前記第２所定数を超える場合、前記所定のグループに含まれ且つ前記施設利用可能時間にスケジュールが登録されておらず且つ前記施設利用可能時間より前にスケジュールが登録されている各ユーザのユーザ端末に、前記施設利用可能時間を送信する、請求項５に記載の制御方法。
7. 前記施設の名称を表示するための表示データは、前記ユーザ端末で表示されているときに前記施設の名称がユーザによって選択されたことに従って、前記施設利用可能時間において当該施設における前記イベントへの参加の意思表示を送信した他のユーザの名称を表示するための表示データである、請求項３〜６のいずれか１項に記載の制御方法。
8. 前記ユーザに関連するエリア情報は、前記スケジュール管理画面に表示された前記施設利用可能時間の直前のスケジュールに関するエリア情報である、請求項３〜７のいずれか１項に記載の制御方法。
9. 前記利用グループに含まれるユーザが所有し且つ前記参加の意思表示を送信したユーザ端末に、参加案内情報を送信し、且つ、前記参加案内情報を送信したユーザ端末を所有するユーザを前記利用グループに関連付けて前記記憶部に記憶し、
   前記施設利用可能時間の送信において、前記所定のグループが過去に記憶された利用グループである場合、当該所定のグループを優先して各ユーザ端末に前記施設利用可能時間を送信する、請求項１〜８のいずれか１項に記載の制御方法。
10. 前記施設利用可能時間の送信において、前記施設利用可能時間の日付と同日の第３所定数を超える数の他の施設利用可能時間を過去に送信している場合、前記施設利用可能時間を送信しない、請求項１〜９のいずれか１項に記載の制御方法。
11. 前記施設利用可能時間の送信において、前記施設利用可能時間よりも所定時間前に前記施設利用可能時間を送信する、請求項１〜１０のいずれか１項に記載の制御方法。
12. 前記施設利用可能時間の開始時刻の所定期間前までに前記記憶部に記憶された参加の意思表示の数が最低開催人数に達しない場合、前記記憶部に記憶された前記施設利用可能時間を削除する、請求項１〜１１のいずれか一項に記載の制御方法。
13. 前記利用グループに含まれるユーザが所有し且つ前記参加の意思表示を送信したユーザ端末に、参加案内情報を送信し、且つ、前記記憶部に記憶された、前記参加案内情報に対応する参加の意思表示を削除し、前記記憶部に記憶された参加の意思表示の数が第４所定数を超える場合、前記サーバは、前記参加の意思表示の送信を禁止する参加禁止信号を前記ユーザ端末に送信する、または、前記ユーザ端末からの前記参加の意思表示を受け付けない、請求項１〜１２のいずれか１項に記載の制御方法。
14. 前記施設利用可能時間の記憶において、前記施設利用可能時間とともに前記施設端末から送信された、前記施設利用可能時間におけるイベントに参加できる人数を示す空席情報を前記記憶部に記憶し、
    前記第１所定数は、前記空席情報で示される数未満に設定され、
    前記利用グループに含まれ且つ前記参加の意思表示を送信したユーザ端末を所有するユーザの数が、前記空席情報で示される数に到達した場合、以降の参加の意思表示を受け付けない、請求項１〜１３のいずれか１項に記載の制御方法。
15. 前記ユーザ端末は、複数人数分の前記参加の意思表示を送信することが可能である、請求項１４に記載の制御方法。
16. 前記施設利用可能時間の送信において、
    各ユーザ端末を所有するユーザのスケジュールのうちの前記施設利用可能時間の日付と同日の最後のスケジュールの終了時刻が前記施設利用可能時間よりも前に登録されている場合、前記施設利用可能時間及び前記施設が存在するエリア情報と前記最後のスケジュールの終了時刻及び当該終了時刻においてユーザが存在するエリア情報とに基づいて、各ユーザ端末を所有するユーザが、前記施設利用可能時間までに前記施設が存在するエリア情報に到着可能であるか否かを判別し、
    前記施設利用可能時間までに前記施設が存在するエリア情報に到着可能であると判別されたユーザが所有するユーザ端末に、前記施設の施設端末から送信された施設利用可能時間を送信する、請求項３〜１５のいずれか１項に記載の制御方法。
17. 記憶部を備えるサーバの制御プログラムであって、前記サーバに、
    複数のグループのそれぞれに含まれる複数のユーザを前記記憶部に記憶し、
    施設端末から送信された施設利用可能時間を前記記憶部に記憶し、
    前記複数のユーザのそれぞれに関連するエリア情報及び前記施設端末に係る施設が存在するエリア情報を前記記憶部に記憶し、
    前記複数のグループのうちの所定のグループに含まれる複数のユーザのそれぞれに関連する前記エリア情報と前記施設が存在するエリア情報とが特定の関係であるか否かを判定し、
    前記施設が存在するエリア情報と特定の関係であると判定された前記エリア情報に関連するユーザが所有する各ユーザ端末に、前記施設の施設端末から送信された前記施設利用可能時間を送信し、
    前記施設利用可能時間を受信したユーザ端末から送信された、前記施設利用可能時間において当該施設におけるイベントに参加する意思表示を受け付け、当該参加の意思表示を前記記憶部に記憶し、
    前記記憶した参加の意思表示の数が、第１所定数を超えた場合に、前記所定のグループを利用グループとして前記記憶部に記憶する、
    ことを実行させる制御プログラム。
18. 複数のグループのそれぞれに含まれる複数のユーザを記憶し、施設端末から送信された施設利用可能時間を記憶し、さらに、前記複数のユーザのそれぞれに関連するエリア情報及び前記施設端末に係る施設が存在するエリア情報を記憶する記憶部と、
    前記複数のグループのうちの所定のグループに含まれる複数のユーザのそれぞれに関連する前記エリア情報と前記施設が存在するエリア情報とが特定の関係であると判定された前記エリア情報に関連するユーザが所有する各ユーザ端末に、前記施設の施設端末から送信された前記施設利用可能時間を送信する通知部と、
    前記施設利用可能時間を受信したユーザ端末から送信された、前記施設利用可能時間において当該施設におけるイベントに参加する意思表示を受け付け、当該参加の意思表示を前記記憶部に記憶し、前記記憶した参加の意思表示の数が、第１所定数を超えた場合に、前記所定のグループを利用グループとして前記記憶部に記憶する予約部と、
    を備えることを特徴とするサーバ。

Images