JP2011095942A - 共用設備利用予約システム - Google Patents

Abstract

【課題】
共用設備等の利用予約につき、予約のキャンセルによる設備の使用状況の低下を防止し、より多くの利用者に希望する設備を利用する機会を与えることで、共用設備等をより有効に活用することを可能とした共用設備利用予約システムを提供する。
【解決手段】利用者は、予め付与されたポイントを使用して予約端末より設備の予約を行う。予約管理サーバは、設備利用予約要求に応じて、獲得ポイントと必要ポイントとを比較することで設備の利用予約を確定し、また、獲得ポイントから必要ポイントを減算することで第１の獲得ポイントを算出する予約処理手段と、予約キャンセル要求に応じて、第１の必要ポイントを算出し、さらに、そこから第２の獲得ポイントを算出するキャンセル処理手段と、設備利用処理手段と、譲渡処理手段とを有する予約管理部と、事後キャンセル要求処理部とを備える。
【選択図】図１

Description

本発明は、共用設備等を利用する可能性がある利用者に、予め共用設備等を予約するために必要なポイントを付与し、利用者はこのポイントを使用することで予約端末より希望する設備の利用予約を行うことが可能であり、さらに、より多くの利用者に希望する設備を利用する機会を与えることが可能な共用設備利用予約システムに関するものである。

近年、都市部を中心に人口集中による土地の高騰や生活環境の利便性から比較的大規模なマンション等の集合住宅に居住する人が増加する傾向にある。このような集合住宅には居住者が共同で利用できる共用室や共用設備等が備えられていることが多く見受けられる。また、特に最近では、プールやスポーツ施設等といった共用設備を備えたものも見受けられる。

このような集合住宅に備えられた共用設備等のうち、居住者にあまり人気のない設備はほとんど利用されることがない。その一方で、人気のある設備については予約が集中してしまい、設備の利用を希望していてもなかなか利用することができないといったことがしばしば起こっている。そのため、このような人気のある設備の利用希望者は利用する日をおおよそで決定し、とりあえず予約をしておくといった「とりあえず予約」が多く行われてしまっていることから、さらに予約が集中してしまい、状況は悪化する傾向にあるといった問題がある。

このような問題を解決するために、一般のレストランや娯楽施設等の予約については、上記のような「とりあえず予約」を防止する技術として、施設の予約やキャンセルをインターネット等の通信ネットワークを介してＰＣ端末から予約管理サーバに接続することで手軽に素早く行うことを可能とし、さらに、クレジットカードを使用して料金を支払った場合等に付与される利用ポイント等として一般的に広く普及しているポイント制度を利用した予約システムが提案されている。

例えば特許文献１には、利用者に与えられたポイントを利用して予約を管理する方法として、予約したサービスに応じて保証ポイント数を利用者に設定し、さらに、この保証ポイント数を予約ごとに記憶した予約受付手段と、予約履行通知の受信時には、予約に対応する利用者の保証ポイント数を消去し、また、予約不履行通知の受信時には、予約に対応する利用者の保証ポイント数を消去すると共に、この保証ポイント数を蓄積しておき、利用者がポイントを利用する際にポイント残高から蓄積された保証ポイント数の累計を差し引いたポイント数を超えたポイントの利用を許可しないように管理するポイント利用手段とを備えるポイント利用予約管理方法が提案されている。

この提案によると、例えば、各施設等に所定のポイント数を付与しておき、クレジットカードに貯まった利用ポイント数の範囲内で各施設等の予約を可能にし、施設等の予約がキャンセルされた場合には、この利用ポイント数を減算するということが可能になる。従って、施設等の予約をキャンセルすると、獲得した利用ポイント数が減算されてしまうので、利用者は利用ポイント数不足のためクレジット会社からのサービスを受けることができなくなるといった不都合が発生するのである。そのため、各利用者に十分に検討したうえで予約するという行動を促すことになり、「とりあえず予約」を防止することが可能となるのである。

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

しかしながら、特許文献１の提案では、一般的なレストランや娯楽施設等を予約の対象として考慮しているので、対応できる予約施設の範囲が非常に狭く、マンション等の比較的大規模な集合住宅における共用設備等の予約に適用するには次のような問題がある。
（１）利用者は予約をいつキャンセルしても利用者に与えられたポイント数から減算されるポイント数は同じである。つまり、予約のキャンセルに対するペナルティはいつの時点においてキャンセルしようとも同じということになる。従って、予約をキャンセルする可能性が高くなった場合にも、急いで予約のキャンセルをしようとはせず、直前まで待ってから予約をキャンセルするという「とりあえず予約」を行う可能性があり、予約をしていても予約をキャンセルする可能性が比較的高い割合で存在する。
（２）また、利用者が設備等の予約をキャンセルせず、予約したとおりに設備等を利用した場合には、利用者に与えられたポイント数は増減しない。そのため、同じ人が何度でも設備等を予約することができるということから、特定の利用者が毎回設備等を繰り返し利用するといった可能性が非常に高い。

マンション等の比較的大規模な集合住宅の共用設備等の場合、予約した設備を利用しないのならできるだけ早めにその予約をキャンセルし、より多くの利用者に希望する設備を利用する機会が与えられることが好ましい。また、特定の利用者だけで設備の利用を占有するのではなく、できるだけ各利用者が平均的に利用できるようにすることが好ましい。

ここで、このような共用設備等に関する問題はただ単にマンション等の比較的大規模な集合住宅においてだけではなく、例えばテニスコートや野球場、コンサート会場等といった各自治体が所有し運営する地域住民のための施設等においても同じ問題が存在している。

よって、本発明の目的は、マンション等の比較的大規模な集合住宅の居住者が共同で利用する共用設備等や各自治体が所有し運営する地域住民のための施設等の予約につき、共用設備等を利用する可能性がある利用者に、予め共用設備等を予約するために必要なポイントを付与し、利用者がこのポイントを使用して予約端末より希望する設備の利用予約を行うことで、利用予約のキャンセルによる設備の使用状況の低下を防止と共に、より多くの利用者に希望する設備を利用する機会を与えることで共用設備等をより有効に活用することを可能とした共用設備利用予約システムを提供することにある。

上記目的を達成するため、本発明の共用設備利用予約システムは、以下の構成を有する。
予約管理サーバと予約端末とが通信ネットワークを介して接続された共用設備利用予約システムであって、前記予約管理サーバは、会員の情報を、会員を識別するための識別符号である会員ＩＤ とパスワードとに対応づけて予め会員テーブルに登録する手段と、予約対象となる設備の情報と設備ごとに異なる設備利用ポイントとの組み合わせを、設備ＩＤと対応づけて予め設備テーブルに登録する手段と、前記予約対象となる設備の予約情報を、予約ＩＤと対応づけて予約テーブルに登録するための手段とをポイントＤＢに格納する手段と、前記予約端末からの設備利用予約要求に応じて、該設備利用予約要求に含まれる設備ＩＤに基づいて前記予約テーブルを参照し、設備ＩＤと利用日時とステータスとを取得する処理手段と、前記設備利用要求に含まれる利用日時とステータスと前記取得された利用日時と前記取得されたステータスとにより予約可能か否かを判断する処理手段と、前記判断の結果、予約可能の場合、前記設備利用予約要求に含まれる会員ＩＤに基づいて前記会員テーブルを参照し、獲得ポイントを取得し、さらに、前記設備利用予約要求に含まれる設備ＩＤに基づいて前記設備テーブルを参照し、必要ポイントを取得する処理手段と、前記獲得ポイントと前記必要ポイントとを比較する処理手段と、前記比較の結果、前記獲得ポイントが前記必要ポイントと同一若しくは大きい場合には、前記設備利用予約要求に含まれる利用日時と会員ＩＤと設備ＩＤとを予約ＩＤと対応づけて前記予約テーブルに登録する処理手段と、前記獲得ポイントから前記必要ポイントを減算し、第１の獲得ポイントを算出する処理手段と、前記第１の獲得ポイントを前記会員ＩＤと対応づけて前記会員テーブルに更新登録する処理手段とを行う予約処理手段と、前記予約端末からの予約キャンセル要求に応じて、前記予約キャンセル要求に含まれる予約ＩＤに基づいて前記予約テーブルを参照し、会員ＩＤと設備ＩＤとを取得する処理手段と、前記取得された設備ＩＤに基づいて前記設備テーブルを参照し、必要ポイントを取得し、該必要ポイントを所定の関数で変換して第１の必要ポイントを算出し、さらに、前記会員ＩＤに基づいて前記会員テーブルを参照し、獲得ポイントを取得し、該獲得ポイントに前記第１の必要ポイントを加算して第２の獲得ポイントを算出する処理手段と、前記第２の獲得ポイントを前記会員ＩＤに対応づけて前記会員テーブルに更新登録する処理手段とを行うキャンセル処理手段と、前記予約端末からの設備利用要求に応じて、前記設備利用要求に含まれる情報に基づいて前記予約テーブルの情報を更新登録する設備利用処理手段と、前記予約端末からの譲渡処理要求に応じて、前記譲渡処理要求に含まれる譲渡情報に基づいて前記予約テーブルと前記会員テーブルの情報を更新登録する譲渡処理手段とを有する予約管理部と、事後キャンセル要求に応じて、前記事後キャンセル要求に応じた時点での日時と前記予約テーブルの利用日時とを比較し、前記予約テーブルの利用日時が前記事後キャンセル要求に応じた時点での日時を既に経過したものが存在するか否かを検索する処理手段と、前記検索の結果存在する場合、 前記事後キャンセル要求に含まれる情報に基づいて前記予約テーブルと前記会員テーブルの情報を更新登録する処理手段とを有する事後キャンセル処理部とを備えることを特徴とする。

また、上記システムにおいて、前記予約管理サーバは、所定の日時に基づいて前記予約テーブルの利用日時を参照し、ステータスを取得する処理手段と、前記ステータスより設備利用予約者が未決定か否かを判断する処理手段と、前記判断の結果、設備利用予約者が未決定の場合、前記予約テーブルより予約情報を抽出し、設備利用予約者未確定情報を生成する処理手段と、前記生成された設備利用予約者未確定情報に含まれる設備ＩＤと利用日時とに基づいて同一情報が存在するか否かを検索する処理手段と、前記検索の結果、同一情報が存在する場合、前記設備利用予約者未確定情報に含まれる会員ＩＤに基づいて前記会員テーブルを参照し、獲得ポイントを取得する処理手段と、前記取得された獲得ポイントにより設備利用予約者を決定する処理手段とを有する利用者決定部を備えることが好適である。

さらに、上記システムにおいて、前記予約管理サーバは、予約対象となる設備の内既に予約済みとなった設備の予約譲渡情報を、予約ＩＤと対応づけて譲渡テーブルに登録する手段を格納した前記ポイントDBと、前記予約端末から第１の譲渡申出要求を受信すると、前記第１の譲渡申出要求に含まれる会員ＩＤに基づいて前記予約テーブルを参照し、ステータスと利用有無とを取得する処理手段と、前記ステータスと前記利用有無とにより譲渡可能か否かを判断する処理手段と、前記判断の結果譲渡可能の場合、前記第１の譲渡申出要求に応じて、前記会員ＩＤに基づいて前記予約テーブルから予約情報を抽出し、該予約情報から譲渡可能予約情報を生成する処理手段と、前記生成された譲渡可能予約情報を前記予約端末へ送信する処理手段と、前記予約端末からの第２の譲渡申出要求に応じて、前記第２の譲渡申出要求に含まれる情報を予約ＩＤと対応づけて前記譲渡テーブルに登録する処理手段とを有する譲渡申出処理手段と、前記予約端末からの第１の譲渡受入要求を受信すると、前記第１の譲渡受入要求に含まれる設備ＩＤに基づいて前記譲渡テーブルを参照し、譲渡先会員ＩＤを取得する処理手段と、前記譲渡先会員ＩＤより譲渡受入が可能か否かを判断する処理手段と、前記判断の結果譲渡受入が可能の場合、前記第１の譲渡申出要求に応じて、前記設備ＩＤに基づいて前記譲渡テーブルから譲渡情報を抽出し、該譲渡情報から譲渡受入可能予約情報を生成する処理手段と、前記生成された譲渡受入可能予約情報を前記予約端末へ送信する処理手段と、前記予約端末からの第２の譲渡受入要求に応じて、前記第２の譲渡受入要求に含まれる情報を予約ＩＤと対応づけて前記譲渡テーブルに更新登録する処理手段と、前記第２の譲渡受入要求に含まれる設備ＩＤに基づいて前記設備テーブルを参照して必要ポイントを取得し、前記第２の譲渡受入要求に含まれる謝礼ポイントに前記必要ポイントを加算して第２の必要ポイントを算出する処理手段と、前記第２の譲渡受入要求に含まれる会員ＩＤに基づいて前記会員テーブルを参照して獲得ポイントを取得し、該獲得ポイントから前記第２の必要ポイントを減算して第３の獲得ポイントを算出する処理手段と、前記第３の獲得ポイントを前記会員ＩＤに対応づけて前記会員テーブルに更新登録する処理手段と、前記第２の譲渡受入要求に含まれる譲渡元会員ＩＤに基づいて前記会員テーブルの会員ＩＤを参照して会員ＩＤと獲得ポイントとを取得し、該獲得ポイントに前記第２の必要ポイントを加算して第４の獲得ポイントを算出する処理手段と、前記第４の獲得ポイントを前記会員ＩＤに対応づけて前記会員テーブルに更新登録する処理手段とを行う譲渡受入処理手段とを有する前記予約管理部とを備えることが、好適である。

本発明によれば、マンション等の比較的大規模な集合住宅の居住者が共同で利用する共用設備等や各自治体が所有し運営する地域住民のための施設等の予約につき、利用者による利用予約やキャンセルを手軽に素早く行うことを可能とし、利用予約のキャンセルが原因となる共用設備等の使用状況の低下を防止と共に、より多くの利用者に希望する設備を利用する機会を与えることで共用設備等をより有効に活用することを可能とする。

本発明の一実施例を示すシステム構成図である。 ポイントデータベースに格納されている会員テーブルのデータの構成図である。 ポイントデータベースに格納されている設備テーブルのデータの構成図である。 ポイントデータベースに格納されている予約テーブルのデータの構成図である。 予約管理部の処理の流れを説明するフローチャートである。 予約管理部の予約処理を説明するフローチャートである。 予約管理部のキャンセル処理を説明するフローチャートである。 予約管理部の設備利用処理を説明するフローチャートである。 事後キャンセル部を説明するフローチャートである。 予約管理部の譲渡処理を説明するフローチャートである。 ログイン画面の一例を示す図である。 メニュー画面の一例を示す図である。 予約画面の一例を示す図である。 キャンセル画面の一例を示す図である。 設備利用画面の一例を示す図である。 譲渡画面の一例を示す図である。 利用者決定部を説明するフローチャートである。 ポイントデータベースに格納されている譲渡テーブルのデータの構成図である。 予約管理部の譲渡申出処理を説明するフローチャートである。 予約管理部の譲渡受入処理を説明するフローチャートである。

以下、本発明を適用した共用設備利用予約システムの一実施の形態について説明する。なお、同一の構成要素については、同一の参照番号を付し、説明を省略する。
図１は、本発明の一実施例を示すシステム構成図である。利用者が共用設備等の予約を行うための予約端末２０と予約管理サーバ１０とがＬＡＮ（Local Area Network）等の通信ネットワーク３０を介して接続されている。

予約端末２０と予約管理サーバ１０は、それぞれ適宜のコンピュータを用いて実施され、本システムの処理機能を実施可能とするプログラムをハードディスク等の適宜の記憶媒体に格納している。また、プログラムは当該コンピュータのＣＰＵ（Central Processing Unit）により実行される。

ここで、予約端末２０は、１台分しか図示していないが、実際にはマンション等の集合住宅の各居住区域や共用スペース等に設置すればよく、２台以上存在する。予約管理サーバ１０についても１台分しか図示していないが、負荷分散を計る等の目的で２台以上設置してもよい。また、通信ネットワーク３０はＬＡＮに限定されるものではなく、例えばＷＡＮ（Wide Area Network）とすることもできるし、これらの組み合わせとすることもできる。このような構成を有することにより、後に詳述するように、予約管理サーバ１０は予約端末２０からの要求を受信して、予約、キャンセル等の処理を実行することができる。

予約管理サーバ１０は、入力装置１３、表示装置１４及び記憶装置１５を備えており、これらは予約管理サーバ１０と有線又は無線により通信可能に接続されている。入力装置１３は、キーボードやマウス、タッチパネル等の入力手段として機能する入力補助装置であり、表示装置１４は、ディスプレイやプリンタ等の画面表示手段および出力手段として機能する装置である。記憶装置１５は、磁気ディスク等の記憶装置であり、予約管理サーバ１０に内蔵又は外部接続されている。ここで、この記憶装置１５について、１台の記憶装置１５が予約管理サーバ１０に接続されているように図示しているが、２台以上の記憶装置１５が予約管理サーバ１０に接続されていてもよい。

記憶装置１５には、本システムに必要な各種情報を登録するためのポイントＤＢ（DataBase）１６が格納されている。なお、以降においては、ポイントＤＢ１６がＲＤＢ（Relational DataBase）であるという前提で説明をするが、必ずしもＲＤＢである必要はなく、通常のファイルにする等構築されるシステムの規模等に合せて選択すればよい。

予約管理サーバ１０は、さらに、予約端末２０からの共用設備等の設備利用予約要求や予約キャンセル要求、設備利用要求、譲渡要求等の各要求に応じて処理を行い、それらの処理の結果を予約端末２０に送信したり、予約端末２０に画面表示等させるための予約管理部１１と、事後キャンセル要求に応じて予約されたものの実際には利用されなかった設備予約のキャンセル処理を行う事後キャンセル部１２を備えている。

予約端末２０は、前述の予約管理サーバ１０と同様に入力装置２２及び表示装置２３を備えており、これらは予約端末２０と有線又は無線により通信可能に接続されている。入力装置２２は、キーボードやマウス、タッチパネル等の入力手段として機能する入力補助装置であり、表示装置２３は、ディスプレイやプリンタ等の画面表示手段および出力手段として機能する装置である。また、図示していないが、予約端末２０は記憶手段として機能する磁気ディスク等の記憶装置を備えており、予約端末２０に記憶内臓又は外部接続している。

また、予約端末２０は、予約管理サーバ１０から受信した情報を表示装置２３に画面表示するための、画面表示部２１を備えている。画面表示部２１は、本実施形態に係わる独自のプログラムであってもよいし、ＷＥＢブラウザ等であってもよい。例えば、ＷＥＢブラウザを画面表示部２１として使用する場合、予約管理サーバ１０の予約管理部１１は、ＷＥＢアプリケーションとすればよい。

図２は、ポイントＤＢ１６に格納されている会員テーブル２０１のデータの構成図である。会員テーブル２０１は、例えば、マンション等の集合住宅の居住者等で共用設備等を利用予約する可能性がある者（以下「会員」という。）の情報を登録したテーブルであり、会員ＩＤ２０２、パスワード２０３、会員名２０４、会員種別２０５及び獲得ポイント２０６の各データ項目から構成されている。これらの情報は、会員情報として本システムの管理者等により予め登録される。当然ながら予約管理サーバ１０には、会員テーブル２０１を登録、変更、削除等するためのプログラムが存在する。

会員ＩＤ２０２には、会員毎に設定され一意に識別可能な識別符号が登録されている。ここで登録に用いられる識別符号とは、例えば「Ｋ１２３」、「１２３４５６７８９」、「Ｋ−１２３−Ａ００１」のように数字又はアルファベット又は記号等で構成された符号であり、重複しないように設定する必要がある。これを用いることで、各会員を容易に識別することが可能となる。

パスワード２０３には、会員が本人であると予約管理サーバ１０が認証するための識別符号が登録される。これは、会員本人しか知り得ない文字及び数字の羅列等から作成及び登録されたものである。このように、会員ＩＤ２０２とパスワード２０３とを組み合わせ、各情報に対応させることで、より強固に会員に対するセキュリティーを確保することが可能となる。

会員名２０４には、会員の氏名等が登録され、会員種別２０５には、本システムに対する会員が有する権限を示すコード等が登録される。また、獲得ポイント２０６には、会員が既に獲得しているポイントの数が登録される。

図３は、ポイントＤＢ１６に格納されている設備テーブル３０１のデータの構成図である。設備テーブル３０１は、予約対象となる設備の情報を登録するテーブルであり、設備ＩＤ３０２、設備名３０３、必要ポイント３０４及び収容人数３０５の各データ項目から構成される。これらの情報は、予約対象設備情報として本システムの管理者等により予め登録される。当然ながら予約管理サーバ１０には、設備テーブル３０１を登録、変更、削除等するプログラムが存在する。

設備ＩＤ３０２には、設備毎に設定され一意に識別可能な識別符号が登録される。ここで登録に用いられる識別符号とは、上述の会員ＩＤ２０２で設定されたものと同様に構成され、登録されるものである。また、設備名３０３には、例えば「集会室」のような設備の名称が登録され、必要ポイント３０４には、当該設備に割り当てられ、会員が設備を利用予約する際に必要となるポイント数が登録される。収容人数３０５には、当該設備の収容人数が登録される。

図４は、ポイントＤＢ１６に格納されている予約テーブル４０１のデータの構成図である。予約テーブル４０１は、予約ＩＤ４０２、利用日時４０３、会員ＩＤ４０４、設備ＩＤ４０５、ステータス４０６及び利用有無４０７の各データ項目から構成され、会員によって予約対象とる設備の予約が行われる毎に新しいレコードが作成されて予約情報が登録更新される。

予約ＩＤ４０２には、予約情報毎に設定され一意に識別可能な識別符号が登録される。ここで登録に用いられる識別符号とは、上述の会員ＩＤ２０２で設定されたものと同様に構成され、登録されるものである。利用日時４０３には、利用予約設備の希望利用日時が、例えば“2009年8月26日14時〜16時”というように登録される。会員ＩＤ４０４には、利用予約を行った会員の会員ＩＤ２０２が登録され、設備ＩＤ４０５には、利用予約の対象設備の設備ＩＤ３０２が登録される。ステータス４０６には、利用予約が未確定であることを示すコードや利用予約が確定したことを示すコード、利用予約がキャンセルされたことを示すコード等が、例えば“予約未確定”“予約確定”“キャンセル”というように登録される。利用有無４０７には、予約を行った会員が未だ設備を利用していないことを示すコードや実際に設備を利用したことを示すコード等が、例えば、“利用なし” “利用済み”というように登録される。

次に、本発明の共用設備利用予約システムの処理の流れについて図を参照し、説明する。
図５は、予約管理部１１の処理の流れを説明するフローチャートである。共用設備等の利用予約を希望する会員が、予約端末２０の入力装置２２を操作して画面表示部２１を起動すると、画面表示部２１は予約端末２０より予約管理サーバ１０の予約管理部１１にログイン画面送信要求を送信する。予約管理部１１は予約端末２０よりログイン画面送信要求を受信すると、この要求に応じて、
予約端末２０へログイン画面を送信する。予約端末２０で受信したログイン画面は画面表示部２１によって表示装置２３に画面表示される（Ｓ５０１）。

表示されたログイン画面の指示に基づいて会員は入力装置２２を操作し、会員ＩＤ及びパスワードを入力する。そして、会員が「実行」ボタン又は「中止」ボタンのクリック操作を行うと、画面表示部２１は予約端末２０より画面入力された情報を予約管理サーバ１０の予約管理部１１に送信する。予約管理部１１は、受信した情報より判断及び検索を行う。前記情報に「中止」ボタンをクリック操作した情報が含まれる場合には、処理終了であると判断し、予約管理部１１は予約管理サーバ１０より予約端末２０へ処理終了要求を送信し、処理を終了する。予約端末２０は処理終了要求を受信すると、画面表示部２１の処理を終了する。

一方、前記情報に「実行」ボタンをクリック操作した情報が含まれる場合には、予約管理部１１は、受信した情報に含まれる会員ＩＤとパスワードとに基づいてポイントＤＢ１６の会員テーブル２０１を参照し、前記会員ＩＤと前記パスワードとが登録されているか否かを検索する。

検索の結果、登録されていない場合には、予約管理部１１は予約管理サーバ１０より予約端末２０へ処理終了要求を送信し、処理を終了する。予約端末２０は処理終了要求を受信すると、画面表示部２１の処理を終了する。
また、検索の結果、登録されている場合には、予約管理部１１は予約管理サーバ１０よりメニュー画面を予約端末２０へ送信する（Ｓ５０２）。予約端末２０で受信したメニュー画面は、画面表示部２１によって表示装置２３に画面表示される（Ｓ５０３）。

ここで、Ｓ５０２でメニュー画面を送信する際、会員ＩＤ２０２に基づいたレコードの会員種別２０５を参照し、この会員種別２０５の設定値に応じたメニュー画面を送信するというステップを入れることにより、予約端末２０で画面表示されるメニュー画面を会員種別２０５毎に変更することが可能となる。

会員は、予約端末２０の表示装置２３に画面表示されたメニュー画面の指示に基づいて、入力装置２２を用いてクリック操作等することで、次の要求を予約端末２０より予約管理サーバ１０の予約管理部１１へ送信する。予約管理部１１は、受信した要求より判断を行う。
受信した要求が「中止」である場合には、処理終了であると判断し、予約管理部１１は予約管理サーバ１０より予約端末２０へ処理終了要求を送信し、処理を終了する。予約端末２０は処理終了要求を受信すると、画面表示部２１の処理を終了する（Ｓ５０４）。また、予約管理部１１は、受信した要求が「中止」以外である場合には、要求に応じた処理を実行し、Ｓ５０３へ遷移して処理を繰り返す（Ｓ５０５）。

次に、図６に予約管理部１１の予約処理を説明するフローチャートを示す。予約管理部１１は、Ｓ５０５で予約端末２０より予約処理要求を受信すると、この要求に応じて、予約端末２０へ予約画面を送信する。予約端末２０で受信した予約画面は、画面表示部２１によって表示装置２３に表示される（Ｓ６０１）。

表示された予約画面の指示に基づいて会員は入力装置２２を操作し、利用予約希望の設備ＩＤ及び利用日を入力する。そして、会員が「実行」ボタン又は「中止」ボタンのクリック操作を行い、画面表示部２１は予約端末２０より画面入力された情報を設備利用要求として予約管理サーバ１０の予約管理部１１に送信する。予約管理部１１は、受信した情報より判断及び検索を行う。前記要求に「中止」ボタンをクリック操作した情報が含まれる場合には、処理終了であると判断し、Ｓ５０３へ遷移する。
一方、前記要求に「実行」ボタンをクリック操作した情報が含まれる場合には、前記要求に応じて、予約管理部１１は予約処理を開始する（Ｓ６０２）。

まず、予約管理部１１は、受信した前記要求に含まれる設備ＩＤに基づいてポイントＤＢ１６の予約テーブル４０１を参照し、前記設備ＩＤ４０５と利用日４０３とステータス４０６とを取得する。そして、前記要求に含まれる利用日時とステータスと前記取得された利用日時４０３とステータス４０６とにより予約可能か否かを判断する。

具体的には、予約テーブル４０１のうち、設備ＩＤ４０５に前記要求に含まれる設備ＩＤが設定されているレコードを参照し、利用日時４０３の全て又は一部が前記要求に含まれる利用日時と重複しているおり、かつステータス４０６に「予約確定」を示すコードが登録されているレコードが存在する場合には、予約不可能と判断し、予約管理部１１は予約管理サーバ１０より予約端末２０にエラーメッセージを送信する。ここで、利用日時が重複しているとは、次のようなことを示している。例えば、利用日時４０３に“２００９年８月２６日１４時〜１６時”が登録されており、前記要求に含まれる利用日時が“２００９年８月２６日１５時〜１７時”であれば、利用日時が１時間だけ重複しているということになる。

また、予約管理部１１は予約可能であると判断した場合には、設備利用要求に含まれる会員ＩＤに基づいてポイントＤＢ１６の会員テーブル２０１を参照し、獲得ポイント２０６を取得し、さらに、前記要求に含まれる設備ＩＤに基づいてポイントＤＢ１６の設備テーブル３０１を参照し、必要ポイント３０４を取得する。そして、取得された獲得ポイント２０６と必要ポイント３０４とを比較する。

前記比較の結果、獲得ポイント２０６が必要ポイント３０４よりも小さい場合には、予約管理部１１は予約端末２０へエラーメッセージを送信する。逆に、比較の結果、獲得ポイント２０６が必要ポイント３０４と同一若しくは大きい場合には、設備利用予約要求に含まれる利用日時と会員ＩＤと設備ＩＤとを予約ＩＤと対応づけて予約テーブル４０１に新たなレコードとして、例えば、予約ＩＤ４０２に当該予約レコードを一意に識別可能な識別符号（例えば１から始まる通番等）を、利用日時４０３に予約画面から入力された利用日時を、会員ＩＤ４０４にログイン画面で入力された会員ＩＤ（すなわち予約端末２０の操作を行っている会員の会員ＩＤ）を、設備ＩＤ４０５に予約画面から入力された設備ＩＤを、ステータス４０６に“予約確定”を示すコードを、利用有無４０７に初期値である“利用なし”を示すコードを登録する。

その後、予約管理部１１は、獲得ポイント２０６から必要ポイント３０４を減算し、第１の獲得ポイントを算出し、この第１の獲得ポイントを設備利用要求に含まれる会員ＩＤと対応づけてポイントＤＢ１６の会員テーブル２０１に新たな獲得ポイントとして更新登録する（Ｓ６０３）。
そして、予約管理部１１は以上の処理を行った後、予約処理を終了し、Ｓ５０３へ遷移する。

このように、会員が設備の利用予約を行うと、予め会員毎に付与されたポイントである獲得ポイントから予約した設備に応じたポイントである必要ポイントが減算される。また、獲得ポイントが予約したい設備の必要ポイントより小さい場合には、残念ながら設備を予約することはできない。

例えば、ある会員の獲得ポイントが１００で、集会室の必要ポイントが３０、テニスコートの必要ポイントが８０である場合、当該会員が集会室を利用予約すると、当該会員の獲得ポイントより集会室の必要ポイントが減算されて獲得ポイントは残り７０となる。次にテニスコートを予約しようとしても、テニスコートの必要ポイントは８０であるため、獲得ポイント不足により予約することはできない。

これにより、同じ会員が多数の共用設備等を利用予約することを抑制することが可能となり、「とりあえず予約」等を最小限に抑えることが可能となる。また、さらに、予約が殺到するような人気のある設備には高いポイント数を、あまり利用されない人気のない設備には低いポイント数を、各々設備の必要ポイントに設定することで、会員により共用設備等ができるだけ平均的に利用されるようにすることが可能となる。

図７は、予約管理部１１のキャンセル処理を説明するフローチャートである。予約管理部１１は、Ｓ５０５で予約端末２０よりキャンセル処理要求を受信すると、この要求に応じて、前記要求に含まれる会員ＩＤに基づいて予約テーブル４０１を参照し、予約ＩＤ４０２と利用日時４０３と設備ＩＤ４０５とステータス４０６と利用有無４０７を取得する。そして、この取得された情報のうち、ステータス４０６と利用有無４０７とによりキャンセル可能か否かを判断する。具体的には、ステータス４０６に“キャンセル”を示すコードが登録されておらず、かつ利用有無４０７に利用前である“利用なし” を示すコードが登録されているレコード（以下「キャンセル対象レコード」という。）である場合にはキャンセル可能と判断し、予約キャンセル情報を生成する。また、前記条件に一致せずキャンセル不可能であると判断された場合には、予約キャンセル情報は生成されない。

次に予約管理部１１は、前記生成された予約キャンセル情報を含んだキャンセル画面を予約端末２０へ送信する。予約端末２０で受信したキャンセル画面は、画面表示部２１によって、表示装置２３に表示される（Ｓ７０１）。

表示されたキャンセル画面の指示に基づいて会員は入力装置２２を操作し、キャンセル希望の設備及び利用日を選択し入力する。そして、会員が「実行」ボタン又は「中止」ボタンのクリック操作を行い、画面表示部２１は予約端末２０より画面入力された情報を予約キャンセル要求として予約管理サーバ１０の予約管理部１１に送信する。予約管理部１１は、受信した情報より判断及び検索を行う。予約キャンセル要求に「中止」ボタンをクリック操作した情報が含まれる場合には、処理終了であると判断し、Ｓ５０３へ遷移する。
一方、キャンセル処理要求に「実行」ボタンをクリック操作した情報が含まれる場合には、前記要求に応じて、予約管理部１１はキャンセル処理を開始する（Ｓ７０２）。

まず、予約管理部１１は、受信した予約キャンセル要求に応じて、前記要求に含まれる予約ＩＤに基づいてポイントＤＢ１６の予約テーブル４０１を参照し、ステータス４０６を取得して“キャンセル”を示すコードを登録する。またこの時、予約管理部１１は同様にして予約テーブル４０１を参照し、会員ＩＤ４０４と設備ＩＤ４０５とを取得する。前記取得された設備ＩＤに基づいてポイントＤＢ１６の設備テーブル３０１を参照し、必要ポイント３０４を取得し、該必要ポイントを所定の関数で変換して第１の必要ポイントを算出する。さらに、会員ＩＤ４０４に基づいてポイントＤＢ１６の会員テーブル２０１を参照し、獲得ポイント２０６を取得し、該獲得ポイント２０６に第１の必要ポイントを加算して第２の獲得ポイントを算出する。そして、第２の獲得ポイントを会員ＩＤ４０４に対応づけてポイントＤＢ１６の会員テーブル２０１に新たな獲得ポイントとして更新登録する。（Ｓ７０３）
予約管理部１１は、以上の処理を行った後、処理を終了し、Ｓ５０３へ遷移する。

このように、キャンセル処理は、会員が設備の利用予約をキャンセルすると、予め会員に付与したポイントである獲得ポイントに、予約した設備に応じたポイントである必要ポイントを所定の関数で変換し算出したポイントが加算される。そこで、この所定の関数は、当該予約レコードの利用日時４０３に近づくほど減少する、いわゆる広義単調減少関数とすればよい。こうすることで、早めに設備の利用予約をキャンセルすれば予約時に減算された必要ポイントとあまり違わないポイントが会員の獲得ポイントに加算される。従って、予約した設備を利用できなくなった場合には早めにキャンセルするという行動を会員に促すことが可能となり、これにより、他の会員が共有設備等を有効に活用できる機会が増加する。

ところで、上述の予約処理とキャンセル処理だけを備えた共用設備利用予約システムでも、本発明の目的を達成することは可能である。その場合、利用予約がキャンセルされないまま利用日時が経過してしまったものについては、利用予約した会員により設備が利用されたものとみなすことになる。従って、より共用設備等を有効に利用するためには、利用予約をしたにも関わらず実際には利用せず、またキャンセルもしなかった会員については、さらにペナルティを与えた方が好ましいと考えられる。そうすることで、会員は利用予約した設備を利用する必要がなくなった場合、さらなるペナルティを避けるために、できるだけ早め、少なくとも利用日時が経過する前までに利用予約をキャンセルするという行動を促されることになる。

そこで、利用予約がキャンセルされず、かつ実際に利用もされなかったかどうかを管理するためには、利用予約された設備が実際に利用された際、その旨の情報を予約テーブル４０１に登録する必要がある。具体的には、予約テーブル４０１の利用有無４０７に“利用済み”を登録する必要がある。
以下に、この処理を行うための設備利用処理について説明する。

図８は、予約管理部１１の設備利用処理を説明するフローチャートである。予約管理サーバ１０の予約管理部１１は、Ｓ５０５で予約端末２０より設備利用要求を受信すると、この要求に応じて、ポイントＤＢ１６に格納されている予約テーブル４０１のステータス４０６と利用有無４０７とを参照し、ステータス４０６に“キャンセル”を示すコードが登録されておらず、かつ利用有無４０７に利用前である“利用なし”のコード が登録されている予約レコード（以下「設備利用対象レコード」という。）をすべて抽出し、設備利用情報を生成する。そして、予約管理部１１は、前記生成された設備利用情報を含んだ設備利用画面を予約端末２０へ送信し、予約端末２０で受信した設備利用画面は、画面表示部２１によって、表示装置２３に表示される（Ｓ８０１）

ここで、上述の条件に加えて、利用日時４０３が予約管理部１１で設備利用要求を予約端末２０より受信した時点での日時であるレコードを設備利用対象レコードとしてもよい。これにより、予約端末２０の表示装置２３に設備利用画面が画面表示される際、表示される情報量を削減し、会員は設備利用処理の対象となる予約レコードを探しやすくなる。

次に、表示された設備利用画面の指示に基づいて会員は入力装置２２を操作し、設備利用処理希望の情報を選択し入力する。そして、会員が「実行」ボタン又は「中止」ボタンのクリック操作を行い、画面表示部２１は予約端末２０より画面入力された情報を設備利用処理要求として予約管理サーバ１０の予約管理部１１に送信する。予約管理部１１は、受信した情報より判断及び検索を行う。設備利用処理要求に「中止」ボタンをクリック操作した情報が含まれる場合には、処理終了であると判断し、Ｓ５０３へ遷移する。
一方、設備利用処理要求に「実行」ボタンをクリック操作した情報が含まれる場合には、前記要求に応じて、予約管理部１１は設備利用処理を開始する（Ｓ８０２）。

予約管理部１１は、受信した設備利用処理要求に応じて、前記要求に含まれる予約ＩＤに基づいてポイントＤＢ１６の予約テーブル４０１を参照して利用有無４０７を取得し、“利用済み”であることを示すコードを更新登録する（Ｓ８０３）。

なお、設備利用処理を行うことができるのは、予約管理権限を有している会員のみに限定することが望ましい。従って、運用上は、設備を利用する会員が、利用開始時等に部屋の鍵や設備利用のために必要な備品を、予約管理権限を有している会員から借りる等とし、その際、予約管理権限を有している会員が設備利用処理を行うようにすればよい。あるいは、予約管理権限を有している会員が、利用日時に実際に利用されているかを確認して設備利用処理を行ってもよいし、設備利用終了後、部屋の鍵等が返却された時点で設備利用処理を行ってもよい。

このような設備利用処理を備えることで、予約された設備が実際に利用されたときに、その旨の情報を予約テーブル４０１に更新登録することができる。逆に、予約テーブル４０１に登録されている利用予約の中で、利用日時４０７を経過した後、実際に利用されなかった設備利用予約について特定することが可能となり、当該予約を行った会員にペナルティを与えることが可能になる。
以下に、この会員にペナルティを与える処理である事後キャンセル処理について説明する。

図９は、事後キャンセル処理部１２の事後キャンセル処理を説明するフローチャートである。予約管理サーバ１０の操作者が、予約管理サーバ１０の表示装置１４に表示された画面の指示に基づいて入力装置１３を操作し、事後キャンセル処理を事後キャンセル部１２へ要求する。この場合の操作者とは、予約管理権限を有している会員であることが好ましい。

事後キャンセル部１２は要求に応じて、ポイントＤＢ１６の予約テーブル４０１を参照し、前記事後キャンセル要求に応じた時点での日時と予約テーブル４０１の利用日時４０３とを比較し、予約テーブル４０１の利用日時４０３が前記事後キャンセル要求に応じた時点での日時を既に経過したものが存在するか否かを検索する（Ｓ９０１）。例えば、要求に応じた日時、つまり、会員が事後キャンセル処理を行った日時が“2009年8月26日16時1分”の場合、予約テーブル４０１の利用日時４０３に“2009年8月26日14時〜16時”が登録されているレコードは、前記日時を既に経過したものが存在するとして検索される。

検索の結果、前記日時を既に経過したもの（以下「事後キャンセル対象レコード」という。）が存在する場合、事後キャンセル部１２は、事後キャンセル対象レコードについて、事後キャンセル処理を実行し、予約テーブル４０１のステータス４０６に“キャンセル”を示すコードを更新登録する。

またこのとき、事後キャンセル部１２は、事後キャンセル対象レコードの会員ＩＤ４０４と設備ＩＤ４０５を取得し、取得された情報に基づいて前述のキャンセル処理と同様な算出方法により第２の獲得ポイントの算出を行う。つまり、前記取得された設備ＩＤ４０５に基づいてポイントＤＢ１６の設備テーブル３０１を参照し、必要ポイント３０４を取得し、該必要ポイントを所定の関数で変換して第１の必要ポイントを算出する。さらに、会員ＩＤ４０４に基づいてポイントＤＢ１６の会員テーブル２０１を参照し、獲得ポイント２０６を取得し、該獲得ポイント２０６に第１の必要ポイントを加算して第２の獲得ポイントを算出する。そして、第２の獲得ポイントを会員ＩＤ４０４に対応づけてポイントＤＢ１６の会員テーブル２０１に新たな獲得ポイントとして更新登録する（Ｓ９０３）。その後、Ｓ９０１へ遷移し、処理を繰り返す。
検索の結果、事後キャンセル対象レコードが存在しない場合には処理を終了する（Ｓ９０２）。

このように、事後キャンセル処理では、会員が利用予約をキャンセルせず実際には予約した設備を利用しなかった場合、会員の獲得ポイントには、予約した設備の必要ポイントを所定の関数で変換して算出したポイントが加算されるが、この場合には、前述したキャンセル処理において算出されるポイントよりも低い値になるようにするとよい。そうすることで、結果的に会員にはポイントが殆ど戻らなくなり、会員自身の獲得ポイントが減少してしまって別の利用予約が行えないということになる。従って、利用予約した設備を利用できなくなった場合には、そのまま利用予約を放置せず、会員自らキャンセルするという行動を促すことが可能になる。なお、事後キャンセル処理が行われた場合には、会員へはポイントを戻さない、あるいは、さらに獲得ポイント２０６を減算することで、ペナルティ効果を上げることも可能である。

ここで、会員が利用予約した設備を利用できなくなった場合に、それをキャンセルするのではなく、別の設備利用希望者である会員を積極的に見つける行動を促すことで、キャンセルに基づいたペナルティによる効果に加え、さらに、より多くの会員に共有設備等を活用できる機会を与えることが可能となる。
以下に、そのための処理機能としての譲渡処理について説明する。

図１０は、予約管理部１１の譲渡処理を説明するフローチャートである。予約管理サーバ１０の予約管理部１１は、Ｓ５０５で予約端末２０より譲渡処理要求を受信すると、この要求に応じて、譲渡処理要求に含まれる会員ＩＤに基づいてポイントＤＢ１６に格納されている予約テーブル４０１のステータス４０６と利用有無４０７とを参照し、ステータス４０６に“キャンセル”を示すコードが登録されておらず、かつ利用有無４０７に利用前である“利用なし”のコード が登録されている予約レコード（以下「譲渡対象レコード」という。）をすべて抽出し、譲渡可能情報を生成する。そして、予約管理部１１は、前記生成された譲渡可能情報を含んだ譲渡画面を予約端末２０へ送信し、予約端末２０で受信した譲渡画面は、画面表示部２１によって、表示装置２３に表示される（Ｓ１００１）。

表示された譲渡画面の指示に基づいて会員は入力装置２２を操作し、譲渡を希望する設備及び利用日を選択し入力する。そして、会員が「実行」ボタン又は「中止」ボタンのクリック操作を行い、画面表示部２１は予約端末２０より画面入力された情報を譲渡要求として予約管理サーバ１０の予約管理部１１に送信する。予約管理部１１は、受信した情報より判断及び検索を行う。譲渡要求に「中止」ボタンをクリック操作した情報が含まれる場合には、処理終了であると判断し、Ｓ５０３へ遷移する。
一方、譲渡要求に「実行」ボタンをクリック操作した情報が含まれる場合には、前記要求に応じて、予約管理部１１は譲渡処理を開始する（Ｓ１００２）。

まず、予約管理部１１は、受信した譲渡要求に応じて、前記要求に含まれる譲渡先を新たな会員ＩＤとして、前記要求に含まれる予約ＩＤに対応づけてポイントＤＢ１６の予約テーブル４０１に更新登録する。

またこの時、設備の利用予約を譲渡した会員に対する獲得ポイントの処理を行う。予約管理部１１は同様に前記要求に含まれる予約ＩＤに基づいてポイントＤＢ１６の予約テーブル４０１を参照して設備ＩＤ４０５を取得し、前記取得された設備ＩＤ４０５に基づいてポイントＤＢ１６の設備テーブル３０１を参照して必要ポイント３０４を取得する。また、前記要求に含まれる会員ＩＤに基づいてポイントＤＢ１６の会員テーブル２０１を参照して獲得ポイント２０６を取得する。前記獲得ポイント２０６に前記必要ポイント３０４を加算して新たな獲得ポイントとし、前記会員ＩＤに対応づけてポイントＤＢ１６の会員テーブル２０１に更新登録する。

さらに、設備の利用予約を前記会員より譲渡された譲渡元である会員に対する獲得ポイントの処理を行う。前記要求に含まれる譲渡元に基づいてポイントＤＢ１６の会員テーブル２０１の会員ＩＤ２０２を参照して獲得ポイント２０６を取得する。前記獲得ポイント２０６から前記必要ポイント３０４を減算して新たな獲得ポイントとし、前記会員ＩＤに２０２に対応づけてポイントＤＢ１６の会員テーブル２０１に更新登録する（Ｓ１００３）。
予約管理部１１は、以上の処理を行った後、処理を終了し、Ｓ５０３へ遷移する。

続いて、上述の各処理を行う際、予約端末２０の画面表示部２１によって表示装置２３に表示される各処理画面について図を用いて説明する。
図１１は、ログイン画面の一例を示す図である。ログイン画面１１０１は、会員ＩＤ入力欄とパスワード入力欄と「実行」ボタンと「中止」ボタンとから構成される。予約端末２０の操作者である会員は、会員ＩＤとこれに対応するパスワードとを入力装置２２をそれぞれの入力欄に使用して入力する。ここで入力された情報である会員ＩＤとパスワードは、会員が入力装置２２によって「実行」ボタン又は「中止」ボタンのクリック操作を行うことで、画面表示部２１は予約端末２０より予約管理サーバ１０の予約管理部１１に送信する。

図１２は、メニュー画面１２０１の一例を示す図である。メニュー画面１２０１は、「予約」「キャンセル」「譲渡」「設備利用」の４つの各処理メニューボタンと、「中止」ボタンとから構成されている。予約端末２０の操作者である会員は、入力装置２２を使用して各処理ボタンのクリック操作を行うことで、画面表示部２１は予約端末２０より各処理要求を予約管理サーバ１０の予約管理部１１に送信する。

ここで、各処理のうち、例えば「予約」「キャンセル」「譲渡」は一般の会員が行う処理であり、「設備利用」は予約管理権限を有している会員が行う処理である。そこで、一般の会員が操作を誤って「設備利用」ボタンをクリック操作しないようにするため、会員種別によりメニュー画面に表示される内容を変更するとよい。

具体的には、図５のＳ５０２で、予約管理部１１が予約端末２０より受信した情報に基づいてポイントＤＢ１６の会員テーブル２０１を参照し、会員ＩＤとパスワードとが登録されているか否かの検索後、登録されている場合には、前記会員ＩＤに基づいて会員テーブル２０１の会員種別２０５を取得するというステップを追加する。そして、会員種別２０５に予約管理権限を有していることを示すコードが登録されている場合には、図１２のメニュー画面を予約端末２０へ送信する。また、会員種別２０５に予約管理権限を有していることを示すコードが登録されていない場合には、「予約」「キャンセル」「譲渡」の３つの各処理メニューボタンと、「中止」ボタンとから構成されるメニュー画面を予約端末２０へ送信すればよい。

図１３は、予約画面の一例を示す図である。予約画面１３０１は、設備ＩＤ入力欄と利用日時入力欄と「実行」ボタンと「中止」ボタンとから構成される。予約端末２０の操作者である会員は、利用予約を希望している設備に対応する設備ＩＤと、それを利用する利用日時とをそれぞれの入力欄に入力装置２２を使用して入力する。ここで入力された情報である設備ＩＤと利用日時とは、会員が入力装置２２によって「実行」ボタン又は「中止」ボタンのクリック操作を行うことで、画面表示部２１は予約端末２０より予約処理要求として予約管理サーバ１０の予約管理部１１に送信する。

なお、図に示した予約画面１３０１では、会員が入力装置２２を使用して設備ＩＤ及び利用日時を入力するが、そのためには、利用予約を希望する設備に対応する設備ＩＤを既に知っている必要がある。また、予約処理を実行するまで、利用予約を希望する設備で希望する利用日時に予約が可能か否かを知ることができないことから、やや利便性に欠ける。

そこで、予約画面１３０１で、例えば、予約可能設備及び利用日時の情報を一覧で表示し、表示された情報の中から利用予約を希望する設備、利用日時を選択できるようにしてもよい。また、さらに、一覧として表示された情報を、設備名等で並び替えたり、絞込んだりして表示できるようにしてもよい。

図１４は、キャンセル画面の一例を示す図である。キャンセル画面１４０１は、「キャンセル」指示用のチェックボックスと設備名と利用日時と「実行」ボタンと「中止」ボタンとから構成され、予約管理サーバ１０の予約管理部１１より受信した予約キャンセル情報は、一覧として予約端末２０の表示装置２３に画面表示される。予約端末２０の操作者である会員は、入力装置２２を使用し、キャンセルを希望する利用予約に対応している「キャンセル」指示用のチェックボックスにチェックを入力する。その後、会員が入力装置２２によって「実行」ボタン又は「中止」ボタンのクリック操作を行うことで、画面表示部２１は予約端末２０よりキャンセル処理要求として予約管理サーバ１０の予約管理部１１に送信する。

なお、表示画面には表示されていないが、予約キャンセル情報には設備名と利用日時とに対応した利用予約に係る予約ＩＤ４０２の情報も含まれている。従って、画面表示部２１は会員によって「キャンセル」指示用のチェックボックスがチェックされた場合、当該チェックボックスに対応する設備名と利用日時とに加え、当該利用予約に係る予約ＩＤも特定することが可能である。

このように、予約端末２０の操作者である会員は、予約キャンセル情報として設備名と利用日時とを対応させた一覧表を参照することで、会員自身が利用予約した内容を確認することが可能となる。また、利用予約のキャンセルを希望する際、容易にその作業を行うことが可能となる。

図１５は、設備利用画面１５０１の一例を示す図である。設備利用画面１５０１は、「利用済み」指示用のチェックボックスと設備名と会員名と利用日時と「実行」ボタンと「中止」ボタンとから構成され、予約管理サーバ１０の予約管理部１１より受信した設備利用情報は、一覧として予約端末２０の表示装置２３に画面表示される。予約端末２０の操作者である会員は、入力装置２２を使用し、設備利用処理を希望する利用予約に対応している「利用済み」指示用のチェックボックスにチェックを入力する。その後、会員が入力装置２２によって「実行」ボタン又は「中止」ボタンのクリック操作を行うことで、画面表示部２１は予約端末２０より設備利用処理要求として予約管理サーバ１０の予約管理部１１に送信する。

なお、表示画面には表示されていないが、設備利用情報として設備名と会員名と利用日時とに対応した利用予約に係る予約ＩＤ４０２の情報も含まれている。従って、画面表示部２１は会員によって「利用済み」指示用のチェックボックスがチェックされた場合、当該チェックボックスに対応する設備名と会員名と利用日時とに加え、当該利用予約に係る予約ＩＤも特定することが可能である。

このように、予約端末２０の操作者である会員は、設備利用情報として設備名と会員名と利用日時を対応させた一覧表を参照することで、設備利用処理の対象とすべき利用予約、すなわち、実際に利用されようとしている利用予約又は実際に利用された利用予約を容易に特定することが可能となる。また、利用予約の設備利用処理を希望する際、容易にその作業を行うことが可能となる。

図１６は、譲渡画面１６０１の一例を示す図である。譲渡画面１６０１は、設備名と利用日時と譲渡先入力欄と「実行」ボタンと「中止」ボタンとから構成され、予約管理サーバ１０の予約管理部１１より受信した譲渡情報は、一覧として予約端末２０の表示装置２３に画面表示される。予約端末２０の操作者である会員は、入力装置２２を使用し、譲渡処理を希望する利用予約に対応している譲渡先入力欄に利用予約の譲渡先である会員に対応する会員ＩＤを入力する。その後、会員が入力装置２２によって「実行」ボタン又は「中止」ボタンのクリック操作を行うことで、画面表示部２１は予約端末２０より譲渡処理要求として予約管理サーバ１０の予約管理部１１に送信する。

なお、表示画面には表示されていないが、譲渡情報として設備名と利用日時とに対応した利用予約に係る予約ＩＤ４０２の情報も含まれている。従って、画面表示部２１は会員によって譲渡先入力欄に譲渡先が入力された場合、当該入力に対応する設備名と利用日時とに加え、当該利用予約に係る予約ＩＤも特定することが可能である。

さて、上述の本システムでは、設備の利用予約を希望する会員が予約端末２０で予約操作を行うと、その段階で設備予約が確定するということになり、早い者から順に利用予約することが可能である。会員の中には頻繁に設備の利用予約をする者が存在する一方で、たまにしか予約しない者も存在する。そのような中で、マンション等の大規模な集合住宅の共用設備等や公共施設等は、特定の利用者だけで利用するのではなく、できるだけ多くの利用者に利用してもらうことが好ましい。

そこで、早い者から順に利用予約するのではなく、予約の段階では予約を確定せずに利用時間が重複する利用予約も許可しておき、所定の日時、例えば、利用日時の１週間前等に、改めて設備利用予約者を確定する処理を追加することで、頻繁に設備を利用しない利用者にも利用予約の機会を与え、できるだけ多くの利用者に共有設備等を利用してもらうことが可能となる。

以下に図を参照し、頻繁に設備を利用予約しない会員を優先して利用予約させるための追加機能である予約管理サーバ１０の利用者決定部について説明する。
図１７は、利用者決定部を説明するフローチャートである。利用者決定部は、例えば、毎日深夜等、所定の日時で起動され、所定の日時に基づいてポイントＤＢ１６の予約テーブル４０１の利用日時４０３を参照し、ステータス４０６を取得する。そして、ステータス４０６より設備利用予約者が未決定か否かを判断する。前記判断の結果、設備利用予約者が未決定の場合、つまり、ステータス４０６に“予約未確定”を示すコードが登録されている場合には、予約テーブル４０１より予約情報を抽出し、設備利用予約者未確定情報を生成する（Ｓ１７０１）。

前記生成された設備利用予約者未確定情報に含まれる設備ＩＤ４０５と利用日時４０３とに基づいて順に参照し、同一情報、つまり、設備ＩＤ４０５に同一の値が登録されており、利用日時４０３の全部又は一部が重複する情報が存在するか否かを検索する（Ｓ１７０２）。

前記検索の結果、同一情報が存在しない場合には、前記設備利用予約者未確定情報に含まれる予約ＩＤに基づいてポイントＤＢ１６の予約テーブル４０１を参照し、ステータス４０６を取得する。前記取得されたステータス４０６に“予約確定”を示すコードを更新登録する（Ｓ１７０５）。以上の処理を行った後、処理を終了し、Ｓ１７０２へ遷移する。

一方、前記検索の結果、同一情報が存在する場合には、前記設備利用予約者未確定情報に含まれる会員ＩＤに基づいてポイントＤＢ１６の会員テーブル２０１を参照し、獲得ポイント２０６を取得する（Ｓ１７０３）。そして、取得された獲得ポイント２０６のポイント数を比較し、ポイント数が最大である会員が行った利用予約を確定させる。つまり、獲得ポイント２０６のポイント数が最大である会員ＩＤに基づいて前記設備利用予約者未確定情報を参照し、予約ＩＤを取得する。前記予約ＩＤに基づいてポイントＤＢ１６の予約テーブル４０１を参照し、ステータス４０６を取得し、“予約確定”を示すコードを更新登録する。また、同一情報を有する他の会員ＩＤに基づいて前記設備利用予約者未確定情報を参照して予約ＩＤを取得し、前記予約ＩＤに基づいてポイントＤＢ１６の予約テーブル４０１を参照し、ステータス４０６を取得し、“キャンセル”を示すコードを更新登録する。

例えば、ある設備について、ポイントＤＢ１６の予約テーブル４０１の利用日時４０３に 第１のレコードとして“2009年8月26日14時〜16時”、第２のレコードとして“2009年8月26日15時〜17時”、第３のレコードとして“2009年8月26日16時〜18時”が登録されている３つの予約レコードが存在していたとする。第２のレコードに係る会員の獲得ポイント２０６が最大である場合、第２のレコードのステータス４０６に“予約確定”を示すコードが登録され、他の第１のレコード及び第３のレコードのステータス４０６には“キャンセル”を示すコードが登録される。

またこのとき、予約が確定した会員ＩＤに対しては、前記設備利用予約者未確定情報に含まれる設備ＩＤ４０５に基づいてポイントＤＢ１６の設備テーブル３０１を参照し、必要ポイント３０４を取得する。その後、利用者決定部は、前記取得された獲得ポイント２０６から必要ポイント３０４を減算し、第１の獲得ポイントを算出し、この第１の獲得ポイントを前記会員ＩＤと対応づけてポイントＤＢ１６の会員テーブル２０１に新たな獲得ポイントとして更新登録する（Ｓ１７０４）。

さらに、利用者決定部は、図示していないが、利用予約が確定した会員対して予約確定通知メールを、利用予約がキャンセルされた会員に対してキャンセル通知メールを送信する等の処理を行った後、処理を終了し、Ｓ１７０２へ遷移し、処理を繰り返す。

予約管理サーバ１０がこのような利用者決定部を備えることで、獲得ポイント２０６が最大の会員、つまり、設備を頻繁に利用しない会員の利用予約が優先して予約確定されることになる。これにより、特定の会員だけでなく、より多くの会員に共有設備等を利用できる機会を提供することが可能となる。また、さらに、予約管理部１１によるキャンセル処理で、予約テーブル４０１のステータス４０６が“予約未確定”であり、同じ設備について利用日時が重複する予約が存在する場合には、キャンセルによるペナルティを課さないようにすることで、重複予約されているほど人気のある設備のキャンセルを容易にし、より多くの会員が共有設備等を有効に活用できる機会を提供することが可能となる。

続いて、図１０で説明した譲渡処理において、予約端末２０より譲渡処理を行う際、利用予約の譲渡を希望している会員が譲渡先である会員の会員ＩＤを入力するので、譲渡を希望していない利用予約を、利用予約の譲渡を希望している会員から勝手に譲渡される可能性が存在する。ただし、マンション等の大規模な集合住宅の共有設備等の利用予約では、そのようなことを行うと集団生活に支障をきたすため、会員による身勝手な利用予約の譲渡は抑制される。しかしながら、例えば、利用予約の対象を公共施設等とし、地域住民全員が公共施設等の利用者である会員となるような、会員の幅が広い場合には、上述のような抑制は効きにくくなる。

このような場合の対策としては、譲渡申出処理と譲渡受入処理とを譲渡処理の追加機能とすることが好ましい。そこで、以下に、譲渡申出処理と譲渡受入処理とを図に示し、説明する。なお、譲渡申出処理と譲渡受入処理に係る会員からの指示は、図１２で示したメニュー画面に各指示ボタンを追加することで行うとよい。

図１８は、ポイントＤＢ１６に格納されている譲渡テーブル１８０１のデータの構成図である。譲渡テーブル１８０１は、予約対象となる設備の内既に予約済みとなった設備の利用予約の譲渡に係る予約譲渡情報が登録されるテーブルであり、予約ＩＤ１８０２、設備ＩＤ１８０３、譲渡元会員ＩＤ１８０４、譲渡先ＩＤ１８０５及び謝礼ポイント１８０６の各データ項目から構成され、自身の利用予約の譲渡を希望する会員より譲渡申出が行われる毎に新しいレコードが作成されて予約譲渡情報が登録更新される。

予約ＩＤ１８０２には、譲渡の対象となる利用予約の予約ＩＤ４０２が登録され、設備ＩＤ１８０３には、譲渡の対象となる利用予約の設備ＩＤ３０２が登録される。また、譲渡元会員ＩＤ１８０４には、自身の利用予約の譲渡を希望する会員の会員ＩＤ２０２が登録され、譲渡先会員ＩＤ１８０４には、利用予約の譲渡を受け入れた会員の会員ＩＤ２０２が登録される。ここで登録されるＩＤは、それぞれ予約テーブル４０１で登録された予約ＩＤ４０２と、設備テーブル３０１で登録された設備ＩＤ３０２と、会員テーブル２０１で登録された会員ＩＤ２０２とに対応している。一方、謝礼ポイント１８０６には、利用予約の譲渡を希望する会員である譲渡元会員から、利用予約の譲渡を受け入れた会員である譲渡先会員への見返りとして支払われる謝礼ポイント数が登録される。

図１９は、予約管理部１１の譲渡申出処理を説明するフローチャートである。予約管理サーバ１０の予約管理部１１は、Ｓ５０５で予約端末２０より第１の譲渡申出要求を受信すると、この第１の譲渡申出要求に含まれる会員ＩＤに基づいてポイントＤＢ１６に格納されている予約テーブル４０１を参照し、ステータス４０６と利用有無４０７とを取得する。取得されたステータス４０６と利用有無４０７とにより利用予約の譲渡が可能か否かを判断する。具体的には、ステータス４０６に“予約確定”を示すコードが登録されており、かつ利用有無４０７に利用前である“利用なし”のコード が登録されている場合には、譲渡可能であると判断し、第１の譲渡申出要求に応じて、対応する予約情報を抽出し、譲渡可能予約情報を生成する。そして、予約管理部１１は、前記生成された譲渡可能予約情報を含んだ譲渡申出画面を予約端末２０へ送信し、予約端末２０で受信した譲渡申出画面は、画面表示部２１によって、表示装置２３に表示される（Ｓ１９０１）。

表示された譲渡申出画面の指示に基づいて会員は入力装置２２を操作し、譲渡可能予約情報の内譲渡を希望する情報を選択して謝礼ポイントを入力する。そして、会員が「実行」ボタン又は「中止」ボタンのクリック操作を行い、画面表示部２１は予約端末２０より画面入力された情報を第２の譲渡申出要求として予約管理サーバ１０の予約管理部１１に送信する。予約管理部１１は、受信した情報より処理を行う。譲渡要求に「中止」ボタンをクリック操作した情報が含まれる場合には、処理終了であると判断し、Ｓ５０３へ遷移する（Ｓ１９０２）。

一方、第２の譲渡申出要求に「実行」ボタンをクリック操作した情報が含まれる場合には、前記要求に応じて、予約管理部１１は第２の譲渡申出要求に含まれる情報を予約ＩＤ４０２と対応づけてポイントＤＢ１６の譲渡テーブル１８０１に更新登録する（Ｓ１９０３）。
予約管理部１１は、以上の処理を行った後、処理を終了し、Ｓ５０３へ遷移する。

図２０は、予約管理部１１の譲渡受入処理を説明するフローチャートである。予約管理サーバ１０の予約管理部１１は、Ｓ５０５で予約端末２０より譲渡申出検索要求を受信すると、前記要求に応じて、譲渡検索画面を予約端末２０へ送信し、予約端末２０で受信した譲渡検索画面は、画面表示部によって、表示装置２３に表示される。表示された譲渡検索画面の指示に基づいて会員は入力装置２２を操作し、譲渡検索を希望する設備ＩＤを入力する。そして、会員が「実行」ボタン又は「中止」ボタンのクリック操作を行い、画面表示部２１は予約端末２０より画面入力された情報を第１の譲渡受入要求として予約管理サーバ１０の予約管理部１１に送信する。予約管理部１１は、受信した情報より処理を行う。第１の譲渡受入要求に「中止」ボタンをクリック操作した情報が含まれる場合には、処理終了であると判断し、Ｓ５０３へ遷移する。
一方、第１の譲渡受入要求に「実行」ボタンをクリック操作した情報が含まれる場合には、前記要求に応じて、予約管理部１１は譲渡受入処理を開始する。

予約管理部１１は、第１の譲渡受入要求に応じて、この第１の譲渡受入要求に含まれる設備ＩＤに基づいてポイントＤＢ１６に格納されている譲渡テーブル１８０１を参照し、譲渡先会員ＩＤ１８０５を取得する。取得された譲渡先ＩＤ１８０５により利用予約の譲渡受入が可能か否かを判断する。具体的には、譲渡先ＩＤ１８０５に初期値が登録されている場合、つまり利用予約の譲渡が申出されているが譲渡の受入がなされていない場合には、譲渡受入可能であると判断し、第１の譲渡受入要求に応じて、対応する譲渡情報を抽出し、譲渡受入可能予約情報を生成する。そして、予約管理部１１は、前記生成された譲渡受入可能予約情報を含んだ譲渡受入画面を予約端末２０へ送信し、予約端末２０で受信した譲渡受入画面は、画面表示部２１によって、表示装置２３に表示される（Ｓ２００１）。

表示された譲渡受入画面の指示に基づいて会員は入力装置２２を操作し、譲渡受入可能予約情報の内譲渡受入を希望する情報を選択し入力する。そして、会員が「実行」ボタン又は「中止」ボタンのクリック操作を行い、画面表示部２１は予約端末２０より画面入力された情報を第２の譲渡受入要求として予約管理サーバ１０の予約管理部１１に送信する。予約管理部１１は、受信した情報より譲渡処理を行う。第２の譲渡受入要求に「中止」ボタンをクリック操作した情報が含まれる場合には、処理終了であると判断し、Ｓ５０３へ遷移する。
一方、第２の譲渡受入要求に「実行」ボタンをクリック操作した情報が含まれる場合には、前記要求に応じて、予約管理部１１は譲渡処理を開始する（Ｓ２００２）。

予約管理部１１は第２の譲渡受入要求に含まれる会員ＩＤ２０２を予約ＩＤ４０２と対応づけてポイントＤＢ１６の譲渡テーブル１８０１の譲渡先会員ＩＤ１８０５に更新登録する。さらに、第２の譲渡申出要求に含まれる会員ＩＤ２０２を予約ＩＤ４０２に対応づけてポイントＤＢ１６の予約テーブル４０１の会員ＩＤ４０４に更新登録する。

またこの時、第２の譲渡受入要求をした会員に対する獲得ポイントの処理を行う。予約管理部１１は第２の譲渡受入要求に含まれる設備ＩＤに基づいてポイントＤＢ１６の設備テーブル３０１を参照して必要ポイント３０４を取得し、第２の譲渡受入要求に含まれる謝礼ポイントに必要ポイント３０４を加算して第２の必要ポイントを算出する。次に、第２の譲渡受入要求に含まれる会員ＩＤ２０２に基づいて会員テーブル２０１を参照して獲得ポイント２０６を取得し、該獲得ポイント２０６から第２の必要ポイントを減算して第３の獲得ポイントを算出する。そして、第３の獲得ポイントを会員ＩＤ２０２に対応づけてポイントＤＢ１６の会員テーブル２０１の獲得ポイント２０６に新たな獲得ポイントとして更新登録する。

さらに、第２の譲渡受入要求に係る譲渡元の会員に対する獲得ポイントの処理を行う。第２の譲渡受入要求に含まれる譲渡元会員ＩＤ１８０４に基づいてポイントＤＢ１６の会員テーブル２０６の会員ＩＤ２０２を参照して獲得ポイント２０６を取得し、該獲得ポイント２０６に第２の必要ポイントを加算して第４の獲得ポイントを算出する。そして、第４の獲得ポイントを会員ＩＤ２０２に対応づけてポイントＤＢ１６の会員テーブル２０１の獲得ポイント２０６に新たな獲得ポイントとして更新登録する（Ｓ２００３）。
予約管理部１１は、以上の処理を行った後、処理を終了し、Ｓ５０３へ遷移する。

ここで、上述の譲渡申出処理と譲渡受入処理とに係る譲渡申出画面と譲渡受入画面とについて説明する。なお、それぞれの画面について図示はしていない。
譲渡申出画面は、図１６の譲渡画面の表示と類似し、設備名と利用日時と謝礼ポイント入力欄と「実行」ボタンと「中止」ボタンとから構成され、予約管理サーバ１０の予約管理部１１より受信した譲渡可能予約情報は、一覧として予約端末２０の表示装置２３に画面表示されるとよい。予約端末２０の操作者であり利用予約の譲渡を希望している会員は、入力装置２２を使用し、譲渡を希望する利用予約に対応している謝礼ポイント入力欄に利用予約の譲渡先の会員に見返りとして与えられるポイント数を入力する。その後、会員が入力装置２２によって「実行」ボタン又は「中止」ボタンのクリック操作を行うことで、画面表示部２１は予約端末２０より第２の譲渡申出要求として予約管理サーバ１０の予約管理部１１に送信される。

また、譲渡受入画面は、図１５の設備利用画面の表示と類似し、「譲渡受入」指示用のチェックボックスと設備名と会員名と利用日時と「実行」ボタンと「中止」ボタンとから構成され、予約管理サーバ１０の予約管理部１１より受信した譲渡受入可能予約情報は、一覧として予約端末２０の表示装置２３に画面表示されるとよい。予約端末２０の操作者であり利用予約の譲渡受入を希望している会員は、入力装置２２を使用し、希望する利用予約に対応している「譲渡受入」指示用のチェックボックスにチェックを入力する。その後、会員が入力装置２２によって「実行」ボタン又は「中止」ボタンのクリック操作を行うことで、画面表示部２１は予約端末２０より第２の譲渡受入要求として予約管理サーバ１０の予約管理部１１に送信される。

このように、利用予約について譲渡の申出及び譲渡の受入という２段階の手続きを踏むことにより、譲渡を申し出た会員と、譲渡を受け入れる会員とが納得した上で利用予約を譲渡することが可能になる。また、譲渡を受け入れると謝礼ポイントを受けることができるため、会員が設備を利用したい日時を、譲渡が申出されている利用予約の日時に合せて変更する等の行動を行うことも期待できる。従って、共用設備等がより平均的に利用されることになる。

なお、ここでは、譲渡申出→譲渡受入の順で行う譲渡処理を説明したが、まず譲渡受入を登録し（希望する利用日時、設備ＩＤ及び譲渡してくれた場合の謝礼ポイント等を設定した譲渡レコードを作成し）、利用予約をキャンセルしたい会員が、譲渡情報を参照して予約を譲渡してもよい。

１０…予約管理サーバ、１１…予約管理部、１２…事後キャンセル部、１３…入力装置、１４…表示装置、１５…記憶装置、１６…ポイントＤＢ、２０…予約端末、２１…画面表示部、２２…入力装置、２３…表示装置、３０…通信ネットワーク、２０１…会員テーブル、３０１…設備テーブル、４０１…予約テーブル、１１０１…ログイン画面、１２０２…メニュー画面、１３０１…予約画面、１４０１…キャンセル画面、１５０１…設備利用画面、１６０１…譲渡画面、１８０１…譲渡テーブル

Claims (3)

1. 予約管理サーバと予約端末とが通信ネットワークを介して接続された共用設備利用予約システムであって、
   前記予約管理サーバは、
   会員の情報を、会員を識別するための識別符号である会員ＩＤ とパスワードとに対応づけて予め会員テーブルに登録する手段と、
   予約対象となる設備の情報と設備ごとに異なる設備利用ポイントとの組み合わせを、設備ＩＤと対応づけて予め設備テーブルに登録する手段と、
   前記予約対象となる設備の予約情報を、予約ＩＤと対応づけて予約テーブルに登録するための手段とをポイントＤＢに格納する手段と、
   前記予約端末からの設備利用予約要求に応じて、該設備利用予約要求に含まれる設備ＩＤに基づいて前記予約テーブルを参照し、設備ＩＤと利用日時とステータスとを取得する処理手段と、
   前記設備利用要求に含まれる利用日時とステータスと前記取得された利用日時と前記取得されたステータスとにより予約可能か否かを判断する処理手段と、
   前記判断の結果、予約可能の場合、
   前記設備利用予約要求に含まれる会員ＩＤに基づいて前記会員テーブルを参照し、獲得ポイントを取得し、さらに、前記設備利用予約要求に含まれる設備ＩＤに基づいて前記設備テーブルを参照し、必要ポイントを取得する処理手段と、
   前記獲得ポイントと前記必要ポイントとを比較する処理手段と、
   前記比較の結果、前記獲得ポイントが前記必要ポイントと同一若しくは大きい場合には、
   前記設備利用予約要求に含まれる利用日時と会員ＩＤと設備ＩＤとを予約ＩＤと対応づけて前記予約テーブルに登録する処理手段と、
   前記獲得ポイントから前記必要ポイントを減算し、第１の獲得ポイントを算出する処理手段と、
   前記第１の獲得ポイントを前記会員ＩＤと対応づけて前記会員テーブルに更新登録する処理手段とを行う予約処理手段と、
   前記予約端末からの予約キャンセル要求に応じて、
   前記予約キャンセル要求に含まれる予約ＩＤに基づいて前記予約テーブルを参照し、会員ＩＤと設備ＩＤとを取得する処理手段と、
   前記取得された設備ＩＤに基づいて前記設備テーブルを参照し、必要ポイントを取得し、該必要ポイントを所定の関数で変換して第１の必要ポイントを算出し、さらに、前記会員ＩＤに基づいて前記会員テーブルを参照し、獲得ポイントを取得し、該獲得ポイントに前記第１の必要ポイントを加算して第２の獲得ポイントを算出する処理手段と、
   前記第２の獲得ポイントを前記会員ＩＤに対応づけて前記会員テーブルに更新登録する処理手段とを行うキャンセル処理手段と、
   前記予約端末からの設備利用要求に応じて、
   前記設備利用要求に含まれる情報に基づいて前記予約テーブルの情報を更新登録する設備利用処理手段と、
   前記予約端末からの譲渡処理要求に応じて、
   前記譲渡処理要求に含まれる譲渡情報に基づいて前記予約テーブルと前記会員テーブルの情報を更新登録する譲渡処理手段とを有する予約管理部と、
   事後キャンセル要求に応じて、前記事後キャンセル要求に応じた時点での日時と前記予約テーブルの利用日時とを比較し、前記予約テーブルの利用日時が前記事後キャンセル要求に応じた時点での日時を既に経過したものが存在するか否かを検索する処理手段と、
   前記検索の結果存在する場合、
   前記事後キャンセル要求に含まれる情報に基づいて前記予約テーブルと前記会員テーブルの情報を更新登録する処理手段とを有する事後キャンセル処理部とを備えることを特徴とする共用設備利用予約システム。
2. 前記予約管理サーバは、さらに、
   所定の日時に基づいて前記予約テーブルの利用日時を参照し、ステータスを取得する処理手段と、
   前記ステータスより設備利用予約者が未決定か否かを判断する処理手段と、
   前記判断の結果、設備利用予約者が未決定の場合、
   前記予約テーブルより予約情報を抽出し、設備利用予約者未確定情報を生成する処理手段と、
   前記生成された設備利用予約者未確定情報に含まれる設備ＩＤと利用日時とに基づいて同一情報が存在するか否かを検索する処理手段と、
   前記検索の結果、同一情報が存在する場合、
   前記設備利用予約者未確定情報に含まれる会員ＩＤに基づいて前記会員テーブルを参照し、獲得ポイントを取得する処理手段と、
   前記取得された獲得ポイントにより設備利用予約者を決定する処理手段とを有する利用者決定部を備えることを特徴とする請求項１に記載の共用設備利用予約システム。
3. 前記予約管理サーバは、さらに、
   予約対象となる設備の内既に予約済みとなった設備の予約譲渡情報を、予約ＩＤと対応づけて譲渡テーブルに登録する手段を格納した前記ポイントDBと、
   前記予約端末から第１の譲渡申出要求を受信すると、
   前記第１の譲渡申出要求に含まれる会員ＩＤに基づいて前記予約テーブルを参照し、ステータスと利用有無とを取得する処理手段と、
   前記ステータスと前記利用有無とにより譲渡可能か否かを判断する処理手段と、
   前記判断の結果譲渡可能の場合、前記第１の譲渡申出要求に応じて、
   前記会員ＩＤに基づいて前記予約テーブルから予約情報を抽出し、該予約情報から譲渡可能予約情報を生成する処理手段と、
   前記生成された譲渡可能予約情報を前記予約端末へ送信する処理手段と、
   前記予約端末からの第２の譲渡申出要求に応じて、
   前記第２の譲渡申出要求に含まれる情報を予約ＩＤと対応づけて前記譲渡テーブルに登録する処理手段とを有する譲渡申出処理手段と、
   前記予約端末からの第１の譲渡受入要求を受信すると、
   前記第１の譲渡受入要求に含まれる設備ＩＤに基づいて前記譲渡テーブルを参照し、譲渡先会員ＩＤを取得する処理手段と、
   前記譲渡先会員ＩＤより譲渡受入が可能か否かを判断する処理手段と、
   前記判断の結果譲渡受入が可能の場合、前記第１の譲渡申出要求に応じて、
   前記設備ＩＤに基づいて前記譲渡テーブルから譲渡情報を抽出し、該譲渡情報から譲渡受入可能予約情報を生成する処理手段と、
   前記生成された譲渡受入可能予約情報を前記予約端末へ送信する処理手段と、前記予約端末からの第２の譲渡受入要求に応じて、
   前記第２の譲渡受入要求に含まれる情報を予約ＩＤと対応づけて前記譲渡テーブルに更新登録する処理手段と、
   前記第２の譲渡受入要求に含まれる設備ＩＤに基づいて前記設備テーブルを参照して必要ポイントを取得し、前記第２の譲渡受入要求に含まれる謝礼ポイントに前記必要ポイントを加算して第２の必要ポイントを算出する処理手段と、
   前記第２の譲渡受入要求に含まれる会員ＩＤに基づいて前記会員テーブルを参照して獲得ポイントを取得し、該獲得ポイントから前記第２の必要ポイントを減算して第３の獲得ポイントを算出する処理手段と、
   前記第３の獲得ポイントを前記会員ＩＤに対応づけて前記会員テーブルに更新登録する処理手段と、
   前記第２の譲渡受入要求に含まれる譲渡元会員ＩＤに基づいて前記会員テーブルの会員ＩＤを参照して会員ＩＤと獲得ポイントとを取得し、該獲得ポイントに前記第２の必要ポイントを加算して第４の獲得ポイントを算出する処理手段と、
   前記第４の獲得ポイントを前記会員ＩＤに対応づけて前記会員テーブルに更新登録する処理手段とを行う譲渡受入処理手段とを有する前記予約管理部とを備えることを特徴とする請求項１又は２に記載の共用設備利用予約システム。

Images