(57)【特許請求の範囲】
【請求項１】
商品及び／又はサービスの提供を受けるための予約をするユーザと、前記ユーザに前記商品及び／又は前記サービスを提供する提供者との間で前記予約を実行する場合にデポジットを設定し、前記予約がキャンセルされた場合に前記デポジットの少なくとも一部を前記提供者に提供可能な予約システムであって、
予約人数及び予約日時を含む予約情報を受け付ける予約情報受付部と、
前記予約情報に、設定された前記デポジットを含む予約設定情報を付加する予約設定情報付加部と、
前記予約がキャンセルされた場合に前記デポジットから徴収する額の割合である徴収割合を定めたポリシーであって、前記予約人数に応じて決定される１以上の人数カテゴリーごとに異なる内容が設定されている前記ポリシーを、前記予約情報の前記予約人数に基づいて前記予約に対して設定するポリシー設定部と、
前記予約がキャンセルされた場合、前記ポリシー設定部が設定した前記ポリシーに基づいてキャンセル処理を実行するキャンセル処理実行部と、
前記予約人数の変更指示を受け付ける変更受付部と
を備え、
前記ポリシーが、前記人数カテゴリーごとに、予約日以前に設定される１以上の期日それぞれに対応付けられる前記徴収割合を含み、
前記変更受付部が、前記変更指示を受け付けた時が、前記期日のうち最先の期日であって、前記ポリシーが実行可能な最先日であるポリシー実行最先日より所定期間以上前か否かを判断し、所定期間未満の場合は前記変更指示を受け付けず、所定期間以上前の場合は前記変更指示を受け付ける予約システム。
【請求項２】
前記ポリシー設定部が、前記変更指示による変更後の前記予約人数に応じた前記ポリシーを前記予約に対して再設定する請求項１に記載の予約システム。
【請求項３】
前記ポリシー実行最先日より所定期間だけ遡った日の到来時、前記デポジットのオーソリゼーションを実行するオーソリ実行部と、
前記オーソリゼーションの実行に応じ、予約内容を確定し、前記予約内容を前記ユーザのユーザ端末に通知する予約通知部と
を更に備える請求項１に記載の予約システム。
【請求項４】
商品及び／又はサービスの提供を受けるための予約をするユーザと、前記ユーザに前記商品及び／又は前記サービスを提供する提供者との間で前記予約を実行する場合にデポジットを設定し、前記予約がキャンセルされた場合に前記デポジットの少なくとも一部を前記提供者に提供可能な予約システムの予約サーバであって、
予約人数及び予約日時を含む予約情報を受け付ける予約情報受付部と、
前記予約情報に、設定された前記デポジットを含む予約設定情報を付加する予約設定情報付加部と、
前記予約がキャンセルされた場合に前記デポジットから徴収する額の割合である徴収割合を定めたポリシーであって、前記予約人数に応じて決定される１以上の人数カテゴリーごとに異なる内容が設定されている前記ポリシーを、前記予約情報の前記予約人数に基づいて前記予約に対して設定するポリシー設定部と、
前記予約がキャンセルされた場合、前記ポリシー設定部が設定した前記ポリシーに基づいてキャンセル処理を実行するキャンセル処理実行部と、
前記予約人数の変更指示を受け付ける変更受付部と
を備え、
前記ポリシーが、前記人数カテゴリーごとに、予約日以前に設定される１以上の期日それぞれに対応付けられる前記徴収割合を含み、
前記変更受付部が、前記変更指示を受け付けた時が、前記期日のうち最先の期日であって、前記ポリシーが実行可能な最先日であるポリシー実行最先日より所定期間以上前か否かを判断し、所定期間未満の場合は前記変更指示を受け付けず、所定期間以上前の場合は前記変更指示を受け付ける予約サーバ。
【請求項５】
商品及び／又はサービスの提供を受けるための予約をするユーザと、前記ユーザに前記商品及び／又は前記サービスを提供する提供者との間で前記予約を実行する場合にデポジットを設定し、前記予約がキャンセルされた場合に前記デポジットの少なくとも一部を前記提供者に提供可能な予約システムが実行する予約方法であって、
前記予約システムが有する予約情報受付部が、予約人数及び予約日時を含む予約情報を受け付ける予約情報受付工程と、
前記予約システムが有する予約設定情報付加部が、前記予約情報に、設定された前記デポジットを含む予約設定情報を付加する予約設定情報付加工程と、
前記予約システムが有するポリシー設定部が、前記予約がキャンセルされた場合に前記デポジットから徴収する額の割合である徴収割合を定めたポリシーであって、前記予約人数に応じて決定される１以上の人数カテゴリーごとに異なる内容が設定されている前記ポリシーを、前記予約情報の前記予約人数に基づいて前記予約に対して設定するポリシー設定工程と、
前記予約システムが有するキャンセル処理実行部が、前記予約がキャンセルされた場合、前記ポリシー設定工程において設定された前記ポリシーに基づいてキャンセル処理を実行するキャンセル処理実行工程と、
前記予約システムが有する変更受付部が、前記予約人数の変更指示を受け付ける変更受付工程と
を備え、
前記ポリシーが、前記人数カテゴリーごとに、予約日以前に設定される１以上の期日それぞれに対応付けられる前記徴収割合を含み、
前記変更受付部が、前記変更受付工程において、前記変更指示を受け付けた時が、前記期日のうち最先の期日であって、前記ポリシーが実行可能な最先日であるポリシー実行最先日より所定期間以上前か否かを判断し、所定期間未満の場合は前記変更指示を受け付けず、所定期間以上前の場合は前記変更指示を受け付ける予約方法。
【請求項６】
商品及び／又はサービスの提供を受けるための予約をするユーザと、前記ユーザに前記商品及び／又は前記サービスを提供する提供者との間で前記予約を実行する場合にデポジットを設定し、前記予約がキャンセルされた場合に前記デポジットの少なくとも一部を前記提供者に提供可能な予約システム用の予約プログラムであって、
コンピュータに、
予約人数及び予約日時を含む予約情報を受け付ける予約情報受付機能と、
前記予約情報に、設定された前記デポジットを含む予約設定情報を付加する予約設定情報付加機能と、
前記予約がキャンセルされた場合に前記デポジットから徴収する額の割合である徴収割合を定めたポリシーであって、前記予約人数に応じて決定される１以上の人数カテゴリーごとに異なる内容が設定されている前記ポリシーを、前記予約情報の前記予約人数に基づいて前記予約に対して設定するポリシー設定機能と、
前記予約がキャンセルされた場合、前記ポリシー設定機能が設定した前記ポリシーに基づいてキャンセル処理を実行するキャンセル処理実行機能と、
前記予約人数の変更指示を受け付ける変更受付機能と
を実現させ、
前記ポリシーが、前記人数カテゴリーごとに、予約日以前に設定される１以上の期日それぞれに対応付けられる前記徴収割合を含み、
前記変更受付機能が、前記変更指示を受け付けた時が、前記期日のうち最先の期日であって、前記ポリシーが実行可能な最先日であるポリシー実行最先日より所定期間以上前か否かを判断し、所定期間未満の場合は前記変更指示を受け付けず、所定期間以上前の場合は前記変更指示を受け付ける予約プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、予約システム、予約サーバ、予約方法、及び予約プログラムに関する。特に、本発明は、予約の際に予約に関するポリシーを自動的に設定可能な予約システム、予約サーバ、予約方法、及び予約プログラムに関する。
【背景技術】
【０００２】
従来、店舗が受け付けた顧客の予約情報を店舗から受信して予約を管理する予約管理サーバであって、情報の送信、受信を行う通信部と、顧客を特定する情報、顧客の連絡先の情報及び予約日の情報を少なくとも含む予約情報が格納される登録予約情報データベースと、予約管理サーバの動作を制御する制御部とを備え、制御部は、予約情報に含まれる顧客の連絡先に、クレジットカードによる事前決済手続を案内するＷｅｂページのＵＲＬ情報を送信する事前決済案内処理部と、Ｗｅｂページから顧客により入力されたクレジットカード番号に対して決済代行サーバがトークン処理を施したトークン情報を決済代行サーバから取得し、登録予約情報データベースに格納するトークン情報処理部と、店舗から、予約を特定する情報と共に、予約日に来店した顧客に提供したサービスの代金の情報、又は、予約日に来店しなかった顧客に請求するキャンセル料の情報を受信した時、代金の情報、又は、キャンセル料の情報と予約に対応するトークン情報とを決済代行サーバに送り、決済を申請する決済申請処理部とを備える予約管理サーバが知られている（例えば、特許文献１参照。）。特許文献１に記載の予約管理サーバによれば、ノーショーやドタキャンによる損害を抑えることができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１９−２０４２６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載の予約管理サーバは、例えば、予約人数の多寡にかかわらず一定のキャンセル料金が発生するので、利用者に不公平感が募る場合がある。また、この場合、店舗側としては予約人数の多寡により商品及び／又はサービスの提供準備に要する労力も変動するところ、予約人数によらず一定のキャンセル料金が発生するだけでは店舗側に損失が発生する可能性もある。更に、特許文献１に記載の予約管理サーバを含む従来の予約システムにおいては、予約人数の変更による予約内容の変更に柔軟に対応することが困難であると共に、予約日直前に大幅な予約人数の変更を依頼された場合の対処が困難である。
【０００５】
したがって、本発明の目的は、利用者による予約内容の変更に比較的柔軟に対応でき、ノーショー等による店の損失の抑制もできる予約システム、予約サーバ、予約方法、及び予約プログラムを提供することにある。
【課題を解決するための手段】
【０００６】
本発明は、上記目的を達成するため、商品及び／又はサービスの提供を受けるための予約をするユーザと、ユーザに商品及び／又はサービスを提供する提供者との間で予約を実行する場合にデポジットを設定し、予約がキャンセルされた場合にデポジットの少なくとも一部を提供者に提供可能な予約システムであって、予約人数及び予約日時を含む予約情報を受け付ける予約情報受付部と、予約情報に、デポジットを含む予約設定情報を付加する予約設定情報付加部と、予約がキャンセルされた場合にデポジットから徴収する額の割合である徴収割合を定めたポリシーであって、予約人数に応じて決定される１以上の人数カテゴリーごとに異なる内容が設定されているポリシーを、予約情報の予約人数に基づいて予約に対して設定するポリシー設定部と、予約がキャンセルされた場合、ポリシー設定部が設定したポリシーに基づいてキャンセル処理を実行するキャンセル処理実行部とを備える予約システムが提供される。
【０００７】
また、本発明は、上記目的を達成するため、商品及び／又はサービスの提供を受けるための予約をするユーザと、ユーザに商品及び／又はサービスを提供する提供者との間で予約を実行する場合にデポジットを設定し、予約がキャンセルされた場合にデポジットの少なくとも一部を提供者に提供可能な予約システムの予約サーバであって、予約人数及び予約日時を含む予約情報を受け付ける予約情報受付部と、予約情報に、デポジットを含む予約設定情報を付加する予約設定情報付加部と、予約がキャンセルされた場合にデポジットから徴収する額の割合である徴収割合を定めたポリシーであって、予約人数に応じて決定される１以上の人数カテゴリーごとに異なる内容が設定されているポリシーを、予約情報の予約人数に基づいて予約に対して設定するポリシー設定部と、予約がキャンセルされた場合、ポリシー設定部が設定したポリシーに基づいてキャンセル処理を実行するキャンセル処理実行部とを備える予約サーバが提供される。
【０００８】
また、本発明は、上記目的を達成するため、商品及び／又はサービスの提供を受けるための予約をするユーザと、ユーザに商品及び／又はサービスを提供する提供者との間で予約を実行する場合にデポジットを設定し、予約がキャンセルされた場合にデポジットの少なくとも一部を提供者に提供可能な予約方法であって、予約人数及び予約日時を含む予約情報を受け付ける予約情報受付工程と、予約情報に、デポジットを含む予約設定情報を付加する予約設定情報付加工程と、予約がキャンセルされた場合にデポジットから徴収する額の割合である徴収割合を定めたポリシーであって、予約人数に応じて決定される１以上の人数カテゴリーごとに異なる内容が設定されているポリシーを、予約情報の予約人数に基づいて予約に対して設定するポリシー設定工程と、予約がキャンセルされた場合、ポリシー設定工程において設定されたポリシーに基づいてキャンセル処理を実行するキャンセル処理実行工程とを備える予約方法が提供される。
【０００９】
また、本発明は、上記目的を達成するため、商品及び／又はサービスの提供を受けるための予約をするユーザと、ユーザに商品及び／又はサービスを提供する提供者との間で予約を実行する場合にデポジットを設定し、予約がキャンセルされた場合にデポジットの少なくとも一部を提供者に提供可能な予約システム用の予約プログラムであって、コンピュータに、予約人数及び予約日時を含む予約情報を受け付ける予約情報受付機能と、予約情報に、デポジットを含む予約設定情報を付加する予約設定情報付加機能と、予約がキャンセルされた場合にデポジットから徴収する額の割合である徴収割合を定めたポリシーであって、予約人数に応じて決定される１以上の人数カテゴリーごとに異なる内容が設定されているポリシーを、予約情報の予約人数に基づいて予約に対して設定するポリシー設定機能と、予約がキャンセルされた場合、ポリシー設定機能が設定したポリシーに基づいてキャンセル処理を実行するキャンセル処理実行機能とを実現させる予約プログラムが提供される。
【発明の効果】
【００１０】
本発明に係る予約システム、予約サーバ、予約方法、及び予約プログラムによれば、利用者による予約内容の変更に比較的柔軟に対応でき、ノーショー等による店の損失の抑制もできる予約システム、予約サーバ、予約方法、及び予約プログラムを提供できる。
【図面の簡単な説明】
【００１１】
【図１】本実施の形態に係る予約システムの概要図である。
【図２】本実施の形態に係る予約サーバの機能構成ブロック図である。
【図３】本実施の形態に係るユーザ端末、店端末、及び決済代行サーバそれぞれの機能構成ブロック図である。
【図４】本実施の形態に係る店情報格納部、及びポリシー格納部のデータ構成を示す図である。
【図５】本実施の形態に係る予約システムの処理のフロー図である。
【図６】本実施の形態に係る予約システムの処理のフロー図である。
【図７】本実施の形態に係る予約システムの処理のフロー図である。
【図８】本実施の形態に係る予約システムの処理のフロー図である。
【図９】本実施の形態に係る予約システムの処理のフロー図である。
【図１０】本実施の形態に係る予約設定情報付加部が予約設定情報を取得する画面を示す図である。
【発明を実施するための形態】
【００１２】
［実施の形態］
図１は、本発明の実施の形態に係る予約システムの概要を示す。
【００１３】
［予約システム１０の概要］
本実施形態に係る予約システム１０は、所定の商品及び／又はサービスの提供を受けるための予約をユーザがした場合にデポジットを設定すると共に、予約がキャンセルされた場合にデポジットから徴収する額の割合（以下、「徴収割合」という）を定めたポリシーを自動的に設定する。この場合において予約システム１０は、予約人数に応じて異なるポリシーを自動的に設定する。そして、予約システム１０は、ユーザが予約をキャンセルした場合に、設定したポリシーに基づいてデポジットから所定の額を徴収することを可能にする。すなわち、予約システム１０は、所定のサービスの利用を受けるための予約がなされた場合に、予約人数に応じたポリシーを自動的に設定し、予約がキャンセルされた場合には当該ポリシーで定められた徴収割合をデポジットに乗じて算出される額をユーザから徴収して提供者に提供するシステムである。
【００１４】
また、予約システム１０は、ユーザが予約した後、予約人数の変更依頼を予約日前の所定期間内に受け付けた場合、変更後の予約人数に応じたポリシーを自動的に再設定することができる。更に、予約システム１０は、ポリシーの設定及び／又は再設定と併せ、ユーザが予約をキャンセルせずに所定のサービスの利用を受けた場合にユーザに提供するボーナス（以下、「チェックインボーナス」という場合がある）を設定することもできる。例えば、予約システム１０は、デポジットの所定割合の額をボーナスの額として設定してよい。
【００１５】
これにより、本実施形態に係る予約システム１０によれば、ユーザが予約をキャンセルした場合、予約人数に応じて変わるポリシーに基づいて予約時に設定されたデポジットから所定割合の徴収額を提供者に提供できるので、ノーショー等による提供者の損失を低減できる。また、予約システム１０は、予約人数に応じて変わるポリシーを自動的に予約に設定するので、予約人数が変更された場合には、変更後の予約人数に応じたポリシーを自動的に設定する。これにより、予約システム１０によれば、予約のキャンセル時にデポジットから徴収される額を予約人数の変動に応じて柔軟に変動させることができ、ユーザ及び提供者の双方の納得感を得ることができる。更に、予約システム１０は、デポジットの所定割合の額をチェックインボーナスの額として設定することもできるので、ユーザの予約の実行のインセンティブを高めることもできる。
【００１６】
（予約システム１０の構成及び処理の流れの概要）
例えば、図１に示すように予約システム１０は、商品及び／又はサービスの提供に関する予約の各種処理を実行する予約サーバ１と、当該予約をするユーザのユーザ端末２と、商品及び／又はサービスを提供する提供者の店端末３と、クレジットカード会社等の決済手段を提供する金融機関と予約サーバ１及び／又は店端末３とを仲介して決済処理を提供する決済代行サーバ４とを備える。予約サーバ１、ユーザ端末２、店端末３、及び／又は決済代行サーバ４は通信網５を介して双方向通信可能に接続される。
【００１７】
一例として、ユーザが飲食店に食事の予約をする場合を挙げて説明する。まずユーザは、ユーザ端末２を用いてウェブ上を検索する。そして、様々な飲食店が紹介されている情報サイトや当該飲食店のホームページ等の所定のフォームに、ユーザの氏名、電話番号、予約日時、及び予約人数等の予約情報を入力して食事の予約をする。飲食店の店端末３は、通信網５を介して予約情報を受け付ける。そして、店端末３は、デポジットやチェックインボーナスの有無、及び飲食店の担当者名等の情報（以下、「予約設定情報」という）を予約情報に付加する。次に、予約システム１０の予約サーバ１は、店端末３を介し、予約設定情報が予約情報に付加された情報を受け取る。予約サーバ１は、店端末３から受け取った情報に含まれる予約人数に基づいてポリシーを設定する。なお、ユーザは、店に電話等で直接予約してもよい。その場合、店端末３は、ユーザからの予約情報と、店員等が設定する予約設定付加情報とを受け付け、受け付けた予約情報及び予約設定情報を予約サーバ１に供給する。
【００１８】
ここで、本実施形態に係るポリシーには、予約人数に応じて決定される人数カテゴリーごとに異なる内容のポリシーが設定される。また、各ポリシーは、予約日（図１のポリシー１３５において「当日」と表現されている日）を基点に所定日数、遡るごとに異なる徴収割合を設定した複数のポリシーを含んで構成される。一例として、図１に示すようにポリシー１３５は、予約人数が１〜４名の場合を「少人数」カテゴリーとし、予約人数が５〜８名の場合を「中人数」カテゴリーとするように、予約人数ごとに複数の人数カテゴリーを設ける。更に、ポリシー１３５は、人数カテゴリーごとに、予約日（当日）、及び予約日から所定日数遡った日（図１における「期日」）のそれぞれに徴収割合を設定する。例えば、図１の例では、人数カテゴリーが「少人数」の場合、予約日（当日）にキャンセルした場合はデポジットの１００％を徴収し、予約日の２日前にキャンセルした場合はデポジットの５０％を徴収し、予約日の３日前にキャンセルした場合はデポジットの３０％を徴収するポリシーが定められている。なお、予約日の４日前以前についてはデポジットから徴収しないため、ポリシーは規定されていない。
【００１９】
ここで、人数カテゴリーが異なる場合、人数の多少による公平感を担保する観点から、「期日」は人数カテゴリーごとに異なっていることが好ましく、「期日」の数が異なっていることも好ましい。例えば、所定の予約人数の人数カテゴリー（第１の人数カテゴリー）より予約人数が多い人数カテゴリー（第２の人数カテゴリー）が設定されている場合、第２の人数カテゴリーがより多くの「期日」を含むことや、より長い日数遡った日まで期日として定めることが好ましい。そして、各人数カテゴリーの期日の中で予約日からの期間が最も長い期日（つまり、最先の期日）が、ポリシーが実行可能となる最先日（以下、「ポリシー実行最先日」という）となる。例えば、図１のポリシー１３５の例では、人数カテゴリーが「少人数」の場合、予約日の３日前がポリシー実行最先日となる。
【００２０】
予約サーバ１は予約情報に含まれる予約人数に応じてポリシーを設定すると共に、ユーザ端末２に予約をしてよいか否かを問い合わせる。予約サーバ１は、ユーザ端末２から予約をしてよい旨の情報を受け付けた場合、予約を設定する。
【００２１】
そして、予約サーバ１は、ポリシー実行最先日に基づいて設定される所定期間内にユーザ端末２若しくは店端末３から予約人数の変更を受け付けた場合、予約人数の変更を実行し、変更後の予約人数に対応するポリシーを再設定する。続いて、予約サーバ１は、ポリシー実行最先日から所定日数前の日になった場合、オーソリゼーションを実行する。すなわち、予約サーバ１は、決済代行サーバ４に対し、デポジット分のオーソリゼーションの実行を依頼する。例えば、図１の例において人数カテゴリーが「少人数」の場合である場合、ポリシーが実行される最先日は予約日から３日前である。ここで、予約サーバ１は、ポリシー実行最先日から更に所定日数遡った日が到来した場合、オーソリゼーションを実行する。例えば、図１の「少人数」の人数カテゴリーにおいて、所定日数が２日間に設定してある場合、ポリシー実行最先日である３日前から更に２日遡った日（つまり、予約日から５日前の日）が到来した場合、予約サーバ１はオーソリゼーションを実行する。これにより、後述する予約人数の変更において、予約日直前の大幅な予約人数変更を抑制しやすくできる。
【００２２】
続いて、決済代行サーバ４においてオーソリゼーションが正常に認められた場合、予約サーバ１は、ユーザ端末２に対し、予約が確定したことを示す情報を供給する。この場合において予約サーバ１は、予約に関する情報を含む識別コード（１次元コード若しくは２次元コード等）を生成する。予約サーバ１は、当該識別コードについて、ユーザ端末２から任意に閲覧可能に設定する。
【００２３】
そして、予約サーバ１は、予約内容（例えば、予約人数）の変更依頼をユーザ端末２若しくは店端末３から受け取った場合、変更依頼を受け取った日がポリシー実行最先日から数えて所定日数より前である場合は人数変更を受け付け、所定日数より前でない場合は人数変更を受け付けない。これにより、予約日に近い日における大幅な予約人数の変更を抑制できる。例えば、予約サーバ１は、人数カテゴリーが「少人数」のポリシーが設定されている場合において当該所定日数を２日に設定してある場合、予約人数の変更依頼をポリシー実行最先日（３日前）から数えて２日より前（つまり、予約日から数えて５日より前）に取得した場合は人数変更を受け付け、予約日から数えて５日以内に取得した場合は人数変更を受け付けない。予約サーバ１は、人数変更を受け付けた場合、予約人数を変更した旨をユーザ端末２及び店端末３に通知する。更に、予約サーバ１は、ポリシー実行最先日から所定日数前の日が到来した場合、上記と同様にオーソリゼーションを実行する。
【００２４】
ここで、予約サーバ１は、ポリシー実行最先日より前の日に予約のキャンセルを受け付けた場合、デポジットからの徴収を発生させずにキャンセル処理を実行する（以下、「正常キャンセル処理」という場合がある）。一方、予約サーバ１は、ポリシー実行最先日以降に予約のキャンセルを受け付けた場合、ポリシーに則った内容のキャンセル処理を実行する。すなわち、予約サーバ１は、キャンセルを受け付けた日とポリシーで規定される期日とを比較し、一致する期日に対応付けられている徴収割合を用い、デポジットから徴収する額を決定する。そして、予約サーバ１は、決定した額について決済処理を決済代行サーバ４に依頼する。これにより、当該額が提供者に提供されることになるので、予約がキャンセルされた場合における提供者の損失を抑制できる。
【００２５】
他方、予約サーバ１は、ユーザが予約日に予定通り提供者の店に来た場合、ユーザ端末２が表示する予約に関する情報を含む識別コードを読み取って、デポジット全額分の決済処理を決済代行サーバ４に依頼して実行する。そして店端末３は、ユーザが提供者の店で消費等した商品及び／又はサービスの費用からデポジット及びチェックインボーナスを差し引いた額をユーザに請求する。
【００２６】
これにより、予約システム１０によれば、商品及び／又はサービスの提供の予約がキャンセルされても提供者に所定額の収入を保証できると共に、ユーザによるノーショーやドタキャン等を抑制できる。また、予約システム１０によれば、ユーザによる予約内容の変更に柔軟に対応できると共に予約日直前の予約人数の大幅な変更を抑制できる。更に、予約システム１０によれば、予約時にユーザにチェックインボーナスを設定し、ユーザが商品及び／又はサービスの提供を実際に受けた場合に、チェックインボーナスをユーザに付与できるので、顧客満足度を向上させることもできる。
【００２７】
なお、提供者は飲食店に限らず、商品及び／又はサービスの提供に予約を要する業態であれば特に限定はない。例えば、飲食店、ヘアサロンやネイルサロン等の美容サロン、理容室、整体院、病院や歯科医院等の医療施設、ホテル等の宿泊施設、スポーツ観戦の予約、遊園地等のアミューズメント施設での遊興の予約、映画館や美術館等の予約、商品の引渡しの予約等、様々な商品及び／又はサービスの提供の予約に活用できる。
【００２８】
また、ユーザ端末２及び店端末３は、携帯通信端末やスマートフォン、デスクトップパソコン、ノートパソコン、及び／又はタブレット型ＰＣ等であってよい。ただし、ユーザ端末２は携帯可能な端末であることが好ましい。更に、通信網５は、携帯電話網、及び／又はインターネット等の通信網である。通信網５は、有線ＬＡＮ及び無線ＬＡＮ等の通信ネットワークを含むこともできる。そして、以下において本実施形態に係る予約システム１０の詳細を説明するが、上記説明及び下記説明における名称や数値、数量等はあくまで例示であり、これらの名称や数値、数量等に限定されることはないことを付言する。
【００２９】
［予約システム１０の構成の詳細］
図２及び図３は、本発明の実施形態に係る予約システムの機能構成の一例を示す。具体的に、図２は、本実施形態に係る予約サーバの機能構成の一例を示し、図３は、本実施形態に係るユーザ端末、店端末、及び決済代行サーバそれぞれの機能構成の一例を示す。また、図４は、本実施形態に係る店情報格納部、及びポリシー格納部のデータ構成の一例を示す。
【００３０】
＜予約システム１０の構成の概要＞
予約システム１０は、商品及び／又はサービスの提供を受けるための予約をするユーザと、ユーザに商品及び／又はサービスを提供する提供者との間で予約を実行する場合にデポジットを設定し、予約がキャンセルされた場合にデポジットの少なくとも一部を提供者に提供可能なシステムである。予約システム１０は、予約サーバ１、ユーザ端末２、及び店端末３を備える。予約システム１０は、決済については決済代行サーバ４に依頼して実行する。
【００３１】
そして、予約サーバ１は、商品及び／又はサービスを提供する店等の店情報を取得する店情報取得部１００と、店情報を格納する店情報格納部１０２と、ポリシーを設定するポリシー設定部１０４と、予約システム１０の利用登録の有無を確認する利用登録確認部１０６と、予約システム１０の利用登録を実行する利用登録部１０８と、利用登録の結果を通知する利用登録通知部１１０と、ユーザの予約の指示を受け付ける予約指示受付部１１２と、予約を確認する予約確認部１１４と、予約の指示を受け付けた旨を通知する予約設定通知部１１６と、予約の変更を受け付ける変更受付部１１８と、オーソリゼーションを実行するオーソリ実行部１２０と、予約が確定したことを通知する予約通知部１２２と、キャンセル指示を受け付けるキャンセル指示受付部１２４と、キャンセル処理を実行するキャンセル処理実行部１２６と、決済を依頼する決済依頼部１２８と、決済結果を通知する決済結果通知部１３０と、外部の各種構成要素に所定の情報を送信する予約サーバ送信部１３２と、ポリシーを格納するポリシー格納部１３４とを有する。
【００３２】
また、ユーザ端末２は、各種の情報の入力を受け付けるユーザ端末入力部２００と、各種の情報を出力するユーザ端末出力部２０２とを少なくとも有する。ユーザ端末入力部２００は、例えば、タッチパネル等であり、ユーザ端末出力部２０２は、例えば、表示部や音声出力部等である。そして、店端末３は、予約情報を受け付ける予約情報受付部３００と、予約設定情報を付加する予約設定情報付加部３０２と、外部の各種構成要素に所定の情報を送信する店端末送信部３０４と、識別情報を取得する識別情報取得部３０６とを少なくとも有する。識別情報取得部３０６は、例えば、識別情報である識別コードの読み取り装置（バーコードリーダー等）である。また、決済代行サーバ４は、アカウントを発行するアカウント発行部４００と、アカウントを通知するアカウント通知部４０２と、決済処理を実行する決済部４０４とを少なくとも有する。
【００３３】
なお、予約システム１０は、上記複数の構成要素を物理的に同一の場所に有するだけでなく、上記複数の構成要素の一部を物理的に離れた位置に設置してもよい。例えば、予約システム１０は、予約サーバ１と、予約サーバ１の機能の少なくとも一部を有する店端末３とで構成してもよい。また、予約システム１０は、予約サーバ１の機能の一部をユーザ端末２及び／又は店端末３に担わせてもよい。更に予約システム１０においては、店端末３の機能の一部を予約サーバ１が担っていてもよい（例えば、予約設定情報付加部３０２を予約サーバ１が有していてもよい。）。なお、予約サーバ１は、複数のサーバの集合体であってもよく、この場合、各サーバが予約サーバ１の各構成要素の一部若しくはすべてを担う。例えば、予約システム１０の複数の処理の一部を予約サーバ１において実行し、その他の処理を他の１以上のサーバにおいて実行してもよい。
【００３４】
＜予約システム１０の構成の詳細＞
（店情報取得部１００、店情報格納部１０２）
店情報取得部１００は、商品及び／又はサービスを提供する店であって予約システム１０の利用を希望する店に関する情報である店情報を取得する。店情報は、例えば、店の運営者に関する情報（法人番号、会社名、代表者名、連絡先等）、店の所在地、連絡先（電話番号、ＦＡＸ番号、電子メールアドレス等）等に関する情報である。店情報格納部１０２は、店を識別する識別子（店ＩＤ）に対応付けて店情報取得部１００が取得した店情報を格納する（例えば、図４参照）。これにより、予約サーバ１に店情報が登録される。そして、店情報取得部１００は、取得した店情報を決済代行サーバ４のアカウント発行部４００に供給する。
【００３５】
（予約情報受付部３００）
予約情報受付部３００は、ユーザ端末２から商品及び／又はサービスの提供を提供者から受けるための予約に関する予約情報を受け付ける。予約情報受付部３００は、様々な店舗情報を掲載するサイトであって、当該サイトから各店舗に商品及び／又はサービスの提供の予約ができる情報サイト６を介し、ユーザ端末２から予約情報を受け付けることもできる。すなわち、予約情報受付部３００は、ユーザ端末２が情報サイトに入力した予約情報を情報サイトから取得し、受け付けることもできる。ここで、予約情報とは、少なくとも予約人数及び予約日時を含む情報である。例えば、予約情報は、予約人数、予約者名（つまり、ユーザ名）、予約者の電話番号（予約者を識別する情報であれば、メールアドレス等の情報でもよい）、予約日時、商品及び／又はサービスの用途等の情報を含む。予約情報受付部３００は、受け付けた予約情報を予約設定情報付加部３０２に供給する。
【００３６】
（予約設定情報付加部３０２）
予約設定情報付加部３０２は、受け取った予約情報に、予約の設定に用いる予約設定情報を付加する。予約設定情報とは、例えば、デポジット、担当スタッフ、チェックインボーナスの有無、予約人数の変更可否等に関する情報である。なお、チェックインボーナスとは、ユーザが予約をキャンセルせずに店に来た場合にユーザに付与される金銭的価値のあるボーナスであって、例えば、デポジットに応じて決定される額の金銭であり、当該予約により提供される商品及び／又はサービスの対価の一部として利用可能なボーナスである。チェックインボーナスの額は、デポジットに応じて自動的に設定してよい。例えば、予約設定情報付加部３０２は、一人当たりのデポジット（単位デポジット）を設定することができる。そして、予約設定情報付加部３０２は、単位デポジットに予約人数を乗じて得られるデポジット（総計デポジット）の所定割合（一例として、１０％）をチェックインボーナスの額として設定してよい。一例として、予約人数が４名、単位デポジットが２，０００円の場合、所定割合を１０％に設定すれば、８００円がチェックインボーナスの額となる。予約設定情報付加部３０２は、予約設定情報が付加された予約情報をポリシー設定部１０４に供給する。
【００３７】
（ポリシー設定部１０４、ポリシー格納部１３４）
ポリシー設定部１０４は、予約設定情報付加部３０２から供給される予約情報に対応する予約に対して所定のポリシーを設定する。具体的に、ポリシー設定部１０４は、予約がキャンセルされた場合にデポジットから徴収する額の割合である徴収割合を定めたポリシーを予約に対して設定する。当該ポリシーは、予約人数に応じて決定される１以上の人数カテゴリーごとに異なる内容が設定されている。そして、ポリシー設定部１０４は、予約情報の予約人数に基づいて予約に対して自動的にポリシーを設定する。
【００３８】
ここで、ポリシー格納部１３４は、ポリシーを一意に識別するポリシーＩＤに対応付けて、人数カテゴリー、期日、及び徴収割合を格納する。人数カテゴリーとは、予約人数に応じて設定される分類である。一例として、予約人数が１〜４名の場合を「少人数」カテゴリー、予約人数が５〜８名の場合を「中人数」カテゴリー、予約人数が９名〜２０名の場合を「大人数」カテゴリー、予約人数が２１名以上の場合を「団体」カテゴリーと分類する。また、期日は、予約日以前に設定される１以上の日であり、各期日に徴収割合が対応付けられている。すなわち、期日は、予約日を起点として遡った日であって、当該期日が到来した日に予約がキャンセルされた場合に当該期日に対応する徴収割合に応じたデポジットから差し引かれる額が決定される日である。一例として、期日が「ｘ日前」の場合は予約日のｘ日前の日に予約がキャンセルされた場合に、当該期日に対応付けられている徴収割合をデポジットに乗じた額がデポジットから徴収される（なお、ｘは１以上の整数である。）。期日が「当日」の場合は予約日に予約がキャンセルされた場合を規定する。すなわち、予約人数及び期日に応じ、徴収割合が異なる。なお、期日が設けられていない日であって、予約日より前の日に予約がキャンセルされた場合には、デポジットに乗じる徴収割合は「０％」と予め設定しておくことが好ましい。
【００３９】
ポリシー設定部１０４は、予約設定情報付加部３０２から受け取った、予約設定情報が付加された予約情報に含まれる予約人数を取得する。そして、ポリシー設定部１０４は、ポリシー格納部１３４を参照し、取得した予約人数に対応する人数カテゴリーのポリシーを設定する。この場合において、ポリシー設定部１０４は、予約のキャンセルがなされていない状態であるので期日の特定は実行しない。そして、ポリシー設定部１０４は、ポリシーを設定した時にポリシーを実行可能に設定し、期日の内の最先の期日であって、ポリシーが実行可能な最先日をポリシー実行最先日として設定する。
【００４０】
一例として、図１の例を挙げて説明する。ユーザから予約人数が１〜４名の範囲で予約を受けた場合、ポリシー設定部１０４は、予約人数が１〜４名に対応する「少人数」カテゴリーのポリシーを当該予約に対して設定する。図１の例では「少人数」カテゴリーには３種類の期日が設定されており、期日の内、最先の期日は「３日前」である。ポリシー設定部１０４は、この「３日前」の期日をポリシー実行最先日として設定する。そして、ポリシー設定部１０４は、ポリシーを設定したタイミングで、ポリシーに含まれる複数の期日のいずれかの期日に予約がキャンセルされた場合、当該期日に対応付けられているポリシーを実行可能な状態にする（係る状態を、以下、「ポリシーを有効にする」という。）。
【００４１】
ポリシー設定部１０４は、ポリシーを設定した後、ユーザ端末２に対し、予約を実行するか否かを確認する予約確認情報を予約サーバ送信部１３２に送信させる。例えば、ポリシー設定部１０４は、ショートメッセージサービス（ＳＭＳ）を用い、予約確認情報をユーザ端末２に送信する。この予約確認情報は、ユーザに予約を確定する意思があるか否かを確認する情報と共に、ユーザが予約システム１０の利用登録をしているか否かを確認する情報、及び／又はユーザの予約を確定する処理を実行するための予約サーバ１に設けられているサイトのＵＲＬ等を含んでよい。
【００４２】
（利用登録確認部１０６）
利用登録確認部１０６は、ユーザ端末２を用いるユーザが予約システム１０の利用登録を既にしているか否かを確認する。利用登録確認部１０６は、ユーザ端末２がポリシー設定部１０４から受け取った利用登録をしているか否かを確認する情報を受け取った後、ユーザ端末２から利用登録をしていない旨の情報を受け取った場合、利用登録部１０８に利用登録を実行させる。この場合、利用登録確認部１０６は、ユーザ端末２を介し、ユーザ固有の情報（例えば、氏名、年齢、住所、連絡先、クレジットカード情報等）を取得する。利用登録確認部１０６は、ユーザ端末２から受け取ったユーザ固有の情報を利用登録部１０８に供給する。
【００４３】
（利用登録部１０８、利用登録通知部１１０）
利用登録部１０８は、ユーザが予約システム１０の利用登録をしていない場合、ユーザ固有の情報をユーザ端末２から取得し、少なくともクレジットカード情報を決済代行サーバ４に登録する。これにより、利用登録部１０８は、ユーザによる予約システム１０の利用を可能にする。そして、利用登録通知部１１０は、利用登録部１０８がユーザによる予約システム１０の利用を可能にした旨をユーザ端末２に通知する。
【００４４】
（予約指示受付部１１２、予約確認部１１４、予約設定通知部１１６）
予約指示受付部１１２は、予約確認情報を参照したユーザによる予約の指示をユーザ端末２から受け付ける。予約指示受付部１１２は、予約の指示を示す情報を予約設定通知部１１６に供給する。予約設定通知部１１６は、予約の指示を受け付けた旨をユーザ端末２及び店端末３に通知する。一方、予約確認部１１４は、予約指示受付部１１２から予め定められた期間内にユーザによる予約の指示を受け付けない場合、ユーザ端末２に予約の指示を促す予約確認情報を送信する。予約確認部１１４は、予約の指示を促す予約確認情報の送信後、予め定められた予約指示の受付期限までに予約の指示を受け付けない場合、予約を取り消すことができる。
【００４５】
（変更受付部１１８）
変更受付部１１８は、ユーザ端末２及び／又は店端末３から予約情報の内容の変更指示を受け付ける。変更受付部１１８は、例えば、予約情報に含まれる予約人数の変更指示を受け付ける。変更受付部１１８は、変更指示を受け付けた日が、ポリシー設定部１０４が設定したポリシーに含まれる１以上の期日のうち最先の期日であって、ポリシーが実行可能な最先日であるポリシー実行最先日より所定期間以上前か否かを判断し（つまり、ポリシー実行最先日から所定日数以上、遡った日であるか否かを判断し）、所定期間未満の場合（つまり、所定日数以上、遡った日ではない場合）は変更指示を受け付けず、所定期間以上前の場合（つまり、所定日数以上、遡った日である場合）は変更指示を受け付ける。例えば、ポリシー実行最先日が予約日の３日前であり、所定期間が２日間である場合、変更受付部１１８は、予約日の５日前より前の日（つまり、予約日より６日以上前の日）は変更指示を受け付ける。一方、この場合、変更受付部１１８は、予約日の５日前以降の日（つまり、予約日より５日前から予約日当日までの日）においては、変更指示を受け付けない。変更受付部１１８は、予約人数の変更を受け付けた場合、予約情報の予約人数を変更し、変更後の予約人数に関する情報をポリシー設定部１０４に供給する。ポリシー設定部１０４は、変更指示による変更後の予約人数に応じたポリシーを上記のポリシー設定部１０４における説明と同様に、変更後の予約に対して再設定する。
【００４６】
なお、変更受付部１１８が受付可能な予約人数の変更数に上限及び下限を設けてもよい。一例として、当初に予約した予約人数の±２名までというような人数変更に制限を設けてもよい。これにより、例えば、一の人数カテゴリーに隣接する他の人数カテゴリーまでの人数変更を認める一方、隣接する人数カテゴリーを超えた人数カテゴリーへの人数変更を禁止することができ、予約人数の大幅な変更を防止することで店の損失の抑制を図ることができる。なお、変更受付部１１８は、大幅な人数変更を抑制する観点から、所定の人数カテゴリー（例えば、「団体」カテゴリー）に対する人数変更の受け付けを禁止することもできる。
【００４７】
（オーソリ実行部１２０）
オーソリ実行部１２０は、ポリシー実行最先日より所定期間だけ遡った日の到来時、予約設定情報付加部３０２が付加したデポジットについてオーソリゼーションを実行する。すなわち、オーソリ実行部１２０は、デポジット分についてのオーソリゼーションの実行を決済代行サーバ４に依頼する。例えば、オーソリ実行部１２０は、ポリシー実行最先日が予約日より３日前であり、所定期間が２日間である場合、予約日の５日前が到来した時にオーソリゼーションを実行する。また、オーソリ実行部１２０は、決済代行サーバ４によるオーソリゼーションの実行後、オーソリゼーションの実行結果を示す情報を決済代行サーバ４から取得する。オーソリ実行部１２０は、決済代行サーバ４から取得した情報を予約通知部１２２に供給する。これにより、ポリシーが有効になる直前の人数変更を抑制でき、人数変更が禁止された後からポリシー実行最先日までの間は正常キャンセルが可能になると共に、ポリシー実行最先日以降のキャンセルについてはデポジットからポリシーに応じた額の徴収を確実に実行できる。
【００４８】
（予約通知部１２２）
予約通知部１２２は、オーソリゼーションの実行に応じ、予約内容を確定し、確定した予約内容をユーザ端末２に通知する。具体的に、予約通知部１２２は、オーソリ実行部１２０から受け取った情報がオーソリゼーションに問題がなかったことを示す情報を含む場合、ユーザの予約内容を確定し、予約内容に基づいて所定の識別情報を生成すると共に、ユーザ端末２に予約がなされたことを示す情報を通知する。ここで、この識別情報は、予約内容に関する情報を含む情報であって、１次元識別コード若しくは２次元識別コード等の識別コードであってよい。また、予約通知部１２２は、ユーザ端末２からの問い合わせに応じ、ユーザ端末２に識別情報を表示させることもできる。なお、予約通知部１２２は、オーソリゼーションに問題があったことを示す情報をオーソリ実行部１２０から受け取った場合、予約できない旨をユーザ端末２に通知してもよい。
【００４９】
（キャンセル指示受付部１２４）
キャンセル指示受付部１２４は、ユーザ端末２から予約のキャンセル指示を受け付ける。キャンセル指示受付部１２４は、キャンセル指示がされた日時に対応付けてキャンセル指示を受け付ける。キャンセル指示受付部１２４は、受け付けたキャンセル指示をキャンセル処理実行部１２６に供給する。
【００５０】
（キャンセル処理実行部１２６）
キャンセル処理実行部１２６は、キャンセル指示を受け付けた場合、ポリシー設定部１０４が設定したポリシーに基づいて所定のキャンセル処理を実行する。なお、キャンセル処理実行部１２６は、ポリシー実行最先日より前にキャンセル指示を受け付けた場合、正常キャンセル処理を実行する。キャンセル処理実行部１２６は、ポリシーに応じた決済処理の実行命令を決済依頼部１２８に供給する。すなわち、キャンセル処理実行部１２６は、キャンセル指示を受け付けた日がポリシーに設定されている期日のいずれの期日に該当するかを判断し、該当する期日に対応付けられている徴収割合をデポジットに乗じた額の決済処理の実行命令を決済依頼部１２８に供給する。
【００５１】
（決済依頼部１２８、決済結果通知部１３０）
決済依頼部１２８は、所定の決済処理の依頼を決済代行サーバ４に供給する。決済代行サーバ４は、当該依頼に基づいて所定の決済処理を実行する。そして、決済結果通知部１３０は、決済代行サーバ４による決済結果をユーザ端末２及び店端末３に通知する。
【００５２】
（アカウント発行部４００、アカウント通知部４０２）
アカウント発行部４００は、商品及び／又はサービスを提供する店が決済代行サーバ４の利用を可能にするためのアカウントを発行する。アカウント発行部４００は、店情報取得部１００が取得した店情報に基づいてアカウントを発行する。アカウント通知部４０２は、アカウント発行部４００が発行したアカウントを予約サーバ１及び／又は当該店の店端末３に通知する。アカウント通知部４０２が予約サーバ１に通知した当該通知を、予約サーバ送信部１３２が店端末３に通知してもよい。
【００５３】
（決済部４０４）
決済部４０４は、決済依頼部１２８から受け取った所定の決済処理の依頼に基づいて決済処理を実行する。例えば、決済部４０４は、所定期間内に識別情報取得部３０６において識別情報が取得されたことを示す情報を取得した場合、決済処理を実行する。また、決済部４０４は、予約がキャンセルされた場合、当該予約に設定されているポリシーに応じた決済処理を実行する。
【００５４】
［予約システム１０の処理の流れ］
図５〜図９は本実施形態に係る予約システムの処理の流れの概要を示す。また、図１０は、本実施形態に係る予約設定情報付加部が予約設定情報を取得する画面の一例の概要である。
【００５５】
＜利用登録処理＞
まず、商品及び／又はサービスを提供する店が予約システム１０の利用登録をしていない場合から説明する。この場合、図５に示すように店情報取得部１００は、当該店の店情報を取得する（ステップ１０。以下、ステップを「Ｓ」と表す。）。店情報は、店から依頼を受けた予約サーバ１の管理者等が予約サーバ１に入力し、当該店情報を店情報取得部１００が取得してもよい。店情報取得部１００は取得した店情報をアカウント発行部４００に供給する（Ｓ１２）。アカウント発行部４００は受け取った店情報に基づいて、店情報を提供した店のアカウントを発行する（Ｓ１４）。アカウント通知部４０２は、アカウント発行部４００が発行したアカウントに関する情報を予約サーバ１に供給する（Ｓ１６）。予約サーバ１は、アカウント通知部４０２から受け取ったアカウントに関する情報を店端末３に供給する（Ｓ１８）。これにより、店端末３による予約システム１０の利用登録が完了する。
【００５６】
＜ユーザによる予約処理＞
次に、ユーザによる予約の流れを説明する。まず、図５に示すようにユーザはユーザ端末２を用い、様々な店の情報が掲載されている情報サイト６であって、当該情報サイト６から所望の店に予約ができる情報サイト６等を用いて予約を欲する店を検索する。そして、ユーザは、情報サイト６に予約を欲する店、及び予約人数や予約日時等の予約情報を入力し、予約を申し込む（Ｓ２０）。情報サイト６はユーザ端末２を介して受け取った予約情報を店端末３に供給する（Ｓ２２）。予約情報受付部３００は、この予約情報を受け付ける（Ｓ２４）。なお、ユーザは、店に電話等で直接、予約を申し込んでもよい。この場合、予約情報受付部３００は、ユーザから予約情報を受け付ける（例えば、ユーザから予約情報を受け付けた店員を介し、予約情報を受け付ける。）。そして、予約設定情報付加部３０２は、この予約情報に予約設定情報を付加する。
【００５７】
例えば、図１０に示すように予約設定情報付加部３０２は、店端末３の表示部等の画面６００に予約設定情報の入力及び／又は選択を受け付けるフォームを表示させる。フォームには、予約人数の選択を受け付ける人数選択欄６０２、デポジットの金額の入力を受け付けるデポジット入力欄６０４、人数選択欄６０２において選択された予約人数に応じて自動的に設定される予約ポリシーの内容を確認可能な予約ポリシー確認欄６０６が表示される。また、フォームは、ユーザの電話番号を入力する電話番号入力欄６０８、予約日を選択する予約日選択欄６１０、予約時刻を選択する予約時刻選択欄６１２、ユーザの氏名等を入力する名称入力欄６１４、商品及び／又はサービスの用途を入力する用途入力欄６１６、店の担当スタッフを選択するスタッフ選択欄６１８、チェックインボーナスを設定するか否かを選択するチェックインボーナス指定欄６２０、予約人数の変更を受け付けるか否かを設定可能な人数変更指定欄６２２、及び設定したデポジットの額、及びデポジットの額に応じて自動的に算出されるチェックインボーナスの額を表示する表示領域６２４を含んでもよい。予約設定情報付加部３０２は、例えば、ユーザが店に電話等で直接予約を申し出た場合、上記フォームに表示される各種欄への所定の情報の入力を受け付けて、予約設定情報を含む予約情報を生成してもよい。
【００５８】
予約設定情報付加部３０２は、少なくともデポジットの設定入力を受け付け、予約情報に予約設定情報を付加する。なお、予約設定情報付加部３０２は、予約情報に含まれている各種情報については、例えば、図１０に示すフォームの所定の領域に自動的に表示させてもよい。予約設定情報付加部３０２は、予約設定情報が付加された予約情報をポリシー設定部１０４に供給する（Ｓ２６）。
【００５９】
ポリシー設定部１０４は、予約処理を実行する（Ｓ２８）。すなわち、ポリシー設定部１０４は、予約情報に含まれる予約人数に応じたポリシーを、当該予約情報に対応する予約に設定する。具体的に、ポリシー設定部１０４は、予約設定情報が付加された予約情報に含まれる予約人数を取得し、ポリシー格納部１３４を参照して取得した予約人数に対応する人数カテゴリーのポリシーを予約に設定する。また、ポリシー設定部１０４は、ポリシーの設定時にポリシーを有効にする。ポリシー設定部１０４は、ポリシー設定後、ユーザ端末２に予約確認情報を送信する（Ｓ３０）。
【００６０】
ユーザ端末２は予約サーバ１から予約確認情報を取得し、予約確認情報をユーザ端末出力部２０２に出力させる（Ｓ３２）。ここで、利用登録確認部１０６は、ユーザによる予約システム１０の利用登録がなされているか否かを判断する（Ｓ３４）。ユーザによる予約システム１０の利用登録がされている場合（Ｓ３４のＹｅｓ）、予約指示受付部１１２はユーザによる予約の指示の有無を確認する（Ｓ４２）。例えば、ユーザ端末２は、予約確認情報に基づいて、ユーザ端末出力部２０２（例えば、表示部であるタッチパネル）に予約の指示を受け付ける「予約オーダー」のアイコンを表示する。ユーザ端末入力部２００がユーザによる当該アイコンのタップ入力を受け付けた場合、予約指示受付部１１２は、予約の指示があったものとして受け付け、予約情報を格納する格納部等に格納する。すなわち、ユーザによる予約指示がある場合（Ｓ４２のＹｅｓ）、予約指示受付部１１２は、ユーザ端末２から予約指示を受け付ける（Ｓ４４）。ここで予約指示受付部１１２は、予約の指示を受け付けた場合、ユーザによるオーソリゼーション実行に対する許可が得られたと判断してよい。これにより、オーソリ実行部１２０は、予約人数に応じて自動的に定められるポリシー実行最先日に基づいたタイミングで、オーソリゼーションを実行可能となる。そして、予約指示受付部１１２は、予約指示を示す情報を予約設定通知部１１６に供給する（Ｓ４６）。予約設定通知部１１６は、予約指示を受け付けた旨を店端末３に通知すると共に（Ｓ４８）、ユーザ端末２に通知する（Ｓ５０）。
【００６１】
一方、ユーザによる予約システム１０の利用登録がされていない場合（Ｓ３４のＮｏ）、利用登録部１０８は、ユーザ端末２を介してユーザの情報（少なくともクレジットカード情報）を取得し（Ｓ３６）、決済代行サーバ４にクレジットカード情報を登録する（Ｓ３８）。決済代行サーバ４は、登録したことを示す情報を予約サーバ１に供給し、予約サーバ１は当該情報を格納する（Ｓ３９）。クレジットカード情報を登録後、利用登録通知部１１０は、ユーザ端末２に予約システム１０の利用が可能であることを示す情報を通知する（Ｓ４０）。
【００６２】
また、ユーザによる予約指示が予め定められた期間内にない場合（Ｓ４２のＮｏ）、予約確認部１１４は、ユーザ端末２に予約の指示を促す予約確認情報を送信する。そして、予約確認部１１４は、予約確認情報の送信後、予め定められた予約指示の受付期限までに予約の指示を受け付けない場合、予約を取消す（Ｓ５２）。具体的に、予約確認部１１４は、予約情報に含まれる予約日までの期間に基づいて、予約指示を受け付ける期限を設定する。例えば、予約情報受付部３００が予約情報を受け付けた日が予約日から２週間以内の場合であって、受け付けた日から２４時間以内に予約指示受付部１１２が予約指示を受け付けない場合、予約を取り消す。また、予約情報受付部３００が予約情報を受け付けた日が予約日から２週間を超える場合であって、受け付けた日から４８時間以内に予約指示受付部１１２が予約指示を受け付けない場合、予約を取り消す。更に、予約情報受付部３００が予約情報を受け付けた日が予約日当日である場合は、予約時刻の３時間前までに予約指示を受け付けない場合には予約を取り消し、予約時刻の３時間以内の場合には予約自体を受け付けないようにすることもできる。なお、これらの期限等の数値は店の事情に合わせ、適宜変更してよい。
【００６３】
＜予約人数変更処理、オーソリゼーション処理＞
次に、予約人数の変更処理の流れを説明する。まず、図６に示すようにユーザ端末入力部２００が予約人数の変更を受け付けた場合（Ｓ６０のＹｅｓ）、変更受付部１１８はユーザ端末２から予約人数の変更指示を受け付ける（Ｓ６２）。また、店端末３が予約人数の変更を受け付けた場合は、変更受付部１１８は店端末３から予約人数の変更指示を受け付ける（Ｓ６４）。なお、ユーザ端末入力部２００が予約人数の変更を受け付けない場合（Ｓ６０のＮｏ）、特に処理は実行しなくてよい。
【００６４】
変更受付部１１８は、変更指示を受け付けた日（以下、「変更指示受付日」という）がポリシー実行最先日から所定日数以上、遡った日であるか否かを判断する（Ｓ６６）。変更受付部１１８は、変更指示受付日がポリシー実行最先日から所定日数以上、遡った日ではないと判断した場合（つまり、変更指示受付日が、ポリシー実行最先日から所定期間未満の場合；Ｓ６６のＮｏ）、変更指示を受け付けず、変更指示を受け付けない旨を店端末３に通知すると共に（Ｓ６８）、ユーザ端末２にも同様の内容を通知する（Ｓ７０）。一方、変更受付部１１８は、変更指示受付日がポリシー実行最先日から所定日数以上、遡った日であると判断した場合（Ｓ６６のＹｅｓ）、予約情報の予約人数を変更する（Ｓ７２）。そして、ポリシー設定部１０４は、変更受付部１１８が変更した予約人数に応じ、予約に設定されていたポリシーを変更後の予約人数に応じたポリシーに再設定する。変更受付部１１８は、予約人数を変更した旨を店端末３に通知すると共に（Ｓ７４）、ユーザ端末２に通知する（Ｓ７６）。
【００６５】
続いて、ポリシー実行最先日から所定日数、遡った日が到来した場合（Ｓ７８のＹｅｓ）、オーソリ実行部１２０は、予約設定情報に含まれるデポジットについてのオーソリゼーションを実行する（Ｓ８０）。決済代行サーバ４は当該オーソリゼーションを実行し、オーソリゼーションの結果をオーソリ実行部１２０に通知する（Ｓ８２）。オーソリ実行部１２０は、ポリシー実行最先日から所定日数、遡った日が到来するまでは（Ｓ７８のＮｏ）、処理を待機する。予約通知部１２２は、オーソリ実行部１２０からオーソリゼーションの結果を受け取り、オーソリゼーションの結果に問題がない場合、ユーザの予約内容を確定する（Ｓ９０）。そして、予約通知部１２２は、予約内容に基づいて所定の識別コードを生成し、ユーザ端末２に予約がなされたことを示す情報を通知する（Ｓ９２）。予約通知部１２２は、オーソリ実行部１２０からオーソリゼーションの結果に問題がある旨を受け取った場合、予約できない旨をユーザ端末２に通知してもよい。
【００６６】
＜キャンセル処理＞
次に、キャンセル処理の流れを説明する。まず、図７に示すように、キャンセル指示受付部１２４はユーザ端末２から予約のキャンセル指示を受け付ける（Ｓ１００）。キャンセル処理実行部１２６は、キャンセル指示を受け付けた日がポリシー実行最先日より前であるか否かを判断する（Ｓ１０２）。キャンセル指示を受け付けた日がポリシー実行最先日より前である場合（Ｓ１０２のＹｅｓ）、キャンセル処理実行部１２６は、正常キャンセル処理を実行する（Ｓ１０４）。すなわち、キャンセル処理実行部１２６は、デポジットから金額を徴収せずに予約をキャンセルする。なお、例えば、Ｓ４２のステップにおいて、予約指示受付部１１２が予約指示を受け付けず、キャンセル指示受付部１２４がキャンセル指示を受け付けてもよい。この場合、キャンセル指示受付部１２４は、当該指示を受け付けた後、ポリシーを実行させずに予約をキャンセルしてもよい。
【００６７】
一方、キャンセル処理実行部１２６は、キャンセル指示を受け付けた日がポリシー実行最先日より前ではない場合（つまり、ポリシー実行最先日から予約日までの間の日である場合；Ｓ１０２のＮｏ）、予約に設定されているポリシーに応じ、キャンセル指示を受け付けた日に該当する期日に紐づけられた徴収割合を用いた決済処理の実行命令を決済依頼部１２８に供給する。決済依頼部１２８は、キャンセル処理実行部１２６から受け取った命令に基づいて、決済代行サーバ４に決済処理を依頼する（Ｓ１０６）。決済代行サーバ４は、ポリシーに応じた決済処理を実行し、実行結果を決済依頼部１２８に通知する（Ｓ１０８）。決済依頼部１２８は、正常キャンセルした場合は正常キャンセルした旨、ポリシーに応じた決済処理を実行した場合はその旨を店端末３に通知すると共に（Ｓ１１０）、ユーザ端末２に通知する（Ｓ１１２）。
【００６８】
＜当日キャンセル時の処理＞
続いて、ユーザが当日キャンセルした場合や事前連絡なしに来店しない場合の処理の流れを説明する。まず、図８に示すように、キャンセル指示受付部１２４は、予約情報に含まれる予約日時を参照し、予約日時の到来まで待機する（Ｓ１２０のＮｏ）。キャンセル指示受付部１２４は、予約日時までにキャンセル指示を受け付けた場合は図７で説明した処理を実行する。そして、キャンセル指示受付部１２４は、予約日時が到来し（Ｓ１２０のＹｅｓ）、予約時刻から所定時間が経過するまでは処理を待機する（Ｓ１２２のＮｏ）。なお、予約時刻から所定時間が経過するまでにキャンセル指示を受け付けた場合は図７で説明した処理を実行する。また、この所定時間は適宜設定することができ、例えば、１時間に設定することができる。
【００６９】
そして、キャンセル指示受付部１２４は、予約時刻から所定時間が経過した場合（Ｓ１２２のＹｅｓ）、ユーザが来店していない旨を示す情報を店端末３に供給する（Ｓ１２４）。また、キャンセル指示受付部１２４は、ユーザ端末２に対し、来店していない旨を示すリマインド情報を通知する（Ｓ１２６）。
【００７０】
その後、店端末３の識別情報取得部３０６が、識別情報（つまり、識別コード）を読み込んだ場合であって（Ｓ１２８のＹｅｓ）、識別情報を読み込んだ時刻が予約時刻から所定時間内である場合（例えば、予約内容において滞在時間が定められている場合、予約時刻に滞在時間を加えて算出される時刻までの間）（Ｓ１３２のＹｅｓ）、後述するＳ１５４を実行する。
【００７１】
一方、店端末３の識別情報取得部３０６が、識別情報を読み込んでいない場合であって（Ｓ１２８のＮｏ）、予約時刻から所定時間が経過した場合（Ｓ１３０のＹｅｓ）、及び店端末３の識別情報取得部３０６が、識別情報を読み込んだ場合であって（Ｓ１２８のＹｅｓ）、識別情報を読み込んだ時刻が予約時刻から所定時間内でない場合（Ｓ１３２のＮｏ）、キャンセル指示受付部１２４は、予約に設定されているデポジット全額の決済処理の実行命令を決済依頼部１２８に供給する。決済依頼部１２８は、キャンセル処理実行部１２６から受け取った命令に基づいて、決済代行サーバ４に決済処理を依頼する（Ｓ１３４）。決済代行サーバ４は、デポジット全額分の決済処理を実行し、実行結果を決済依頼部１２８に通知する（Ｓ１３８）。決済依頼部１２８は、デポジット全額分の決済を実行した旨を店端末３に通知すると共に（Ｓ１３８）、ユーザ端末２に通知する（Ｓ１４０）。なお、店端末３の識別情報取得部３０６が、識別情報を読み込んでいない場合であって（Ｓ１２８のＮｏ）、予約時刻から所定時間が経過していない場合（Ｓ１３０のＮｏ）、予約時刻から所定時間が経過するまでキャンセル指示受付部１２４は処理を待機する。なお、天変地異や急病、事故等のやむを得ない事情によりユーザが来店できない事情がある場合、当該事情に関する情報をキャンセル指示受付部１２４が受け付けてよい。そして、キャンセル処理実行部１２６は、当該事情に関する情報に基づいて、特別キャンセル処理を実行してもよい。特別キャンセル処理とは、予約に設定されているポリシーに関わらず、正常キャンセル処理を実行する処理である。
【００７２】
＜来店処理＞
続いて、ユーザが来店した場合の処理の流れを説明する。まず、図９に示すように、ユーザ端末２に表示される識別情報、若しくはユーザ端末２等に表示される識別情報をプリントアウトした識別情報の提示を店が受け付ける（Ｓ１５０）。識別情報取得部３０６は、提示された識別情報を読み取る（Ｓ１５２）。識別情報取得部３０６は、読み取った識別情報に基づいて、当該識別情報で識別される予約に設定されているデポジット分の決済処理の依頼を決済依頼部１２８に通知する（Ｓ１５４）。決済依頼部１２８は、デポジット分の決済処理の依頼（つまり、キャプチャ処理）を決済代行サーバ４に供給する（Ｓ１５６）。決済代行サーバ４は、当該依頼に基づいてデポジット分の決済処理を実行し、実行結果を決済結果通知部１３０に供給する（Ｓ１５８）。決済結果通知部１３０は、決済代行サーバ４による決済結果を店端末３に通知すると共に（Ｓ１６０）、ユーザ端末２に通知する（Ｓ１６２）。そして、店端末３は、ユーザが店において消費等した商品及び／又はサービスの費用からデポジット及びチェックインボーナスを差し引いた額をユーザに請求する（Ｓ１７０）。
【００７３】
なお、Ｓ１５２において識別情報取得部３０６は、識別情報を読み取る代わりに、店端末３の表示部等に予約日の当日にかぎりユーザを特定する所定の情報の手動入力を促すボタンやアイコン等を表示させてもよい。識別情報取得部３０６は、当該ボタンやアイコン等に対する入力を受け付けた場合、ユーザを特定する所定の情報（例えば、ユーザの氏名やユーザ端末２の電話番号等のユーザ個人を特定する情報）の入力により得られる情報を、識別情報を読み取って取得する情報の代わりにすることができる。これにより、ユーザがユーザ端末２を店に持参しなかった場合やプリントアウトした識別情報を持参しなかった場合等であっても、予約システム１０による予約処理を実行できる。
【００７４】
［予約プログラム］
図１〜図１０に示した本実施形態に係る予約システム１０が備える各構成要素は、中央演算処理装置（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ：ＣＰＵ）等の演算処理装置にプログラム（すなわち、予約プログラム）を実行させること、つまり、ソフトウェアによる処理により実現できる。また、集積回路（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ：ＩＣ）等の電子部品としてのハードウェアにプログラムを予め書き込むことで実現することもできる。なお、ソフトウェアとハードウェアとを併用することもできる。
【００７５】
本実施形態に係る予約プログラムは、例えば、ＩＣやＲＯＭ等に予め組み込むことができる。また、予約プログラムは、インストール可能な形式、又は実行可能な形式のファイルで、磁気記録媒体、光学記録媒体、半導体記録媒体等のコンピュータで読み取り可能な記録媒体に記録し、コンピュータプログラムとして提供することもできる。プログラムを格納している記録媒体は、ＣＤ−ＲＯＭやＤＶＤ等の非一過性の記録媒体であってよい。更に、予約プログラムを、インターネット等の通信ネットワークに接続されたコンピュータに予め格納させ、通信ネットワークを介してダウンロードによる提供ができるようにすることもできる。
【００７６】
本実施形態に係る予約プログラムは、ＣＰＵ等に働きかけて、予約プログラムを、図１〜図１０にかけて説明した店情報取得部１００、店情報格納部１０２、ポリシー設定部１０４、利用登録確認部１０６、利用登録部１０８、利用登録通知部１１０、予約指示受付部１１２、予約確認部１１４、予約設定通知部１１６、変更受付部１１８、オーソリ実行部１２０、予約通知部１２２、キャンセル指示受付部１２４、キャンセル処理実行部１２６、決済依頼部１２８、決済結果通知部１３０、予約サーバ送信部１３２、ポリシー格納部１３４、ユーザ端末入力部２００、ユーザ端末出力部２０２、予約情報受付部３００、予約設定情報付加部３０２、店端末送信部３０４、識別情報取得部３０６、アカウント発行部４００、アカウント通知部４０２、及び決済部４０４として機能させる。
【００７７】
（実施の形態の効果）
本実施形態に係る予約システム１０は、ユーザが商品及び／又はサービスの提供者に対して商品及び／又はサービスの提供の予約をする場合にデポジットを設定し、予約人数に応じたポリシー（キャンセル時にデポジットから差し引かれる額の割合を設定したポリシー）を自動的に設定できる。これにより、予約システム１０によれば、ノーショー等による提供者の損失を低減できるだけでなく、予約人数に応じた適切な徴収割合を設定できるので、ユーザにとっての使い勝手の向上を図ることができる。
【００７８】
また、本実施形態に係る予約システム１０によれば、予約人数の変更に応じて予約に設定するポリシーを自動的に再設定できることから徴収割合を予約人数に応じた適切な割合に変更できることになり、ユーザの不公平感を低減できる。更に、予約システム１０によれば、ユーザが予約をキャンセルせずに来店した場合、所定のチェックインボーナスをユーザに提供できるので、ユーザの満足度の向上を図ることもできる。
【００７９】
以上、本発明の実施の形態を説明したが、上記に記載した実施の形態は特許請求の範囲に係る発明を限定するものではない。また、実施の形態の中で説明した特徴の組合せのすべてが発明の課題を解決するための手段に必須であるとは限らない点に留意すべきである。更に、上記した実施形態の技術的要素は、単独で適用されてもよく、プログラム部品とハードウェア部品とのような複数の部分に分割されて適用されるようにすることもできる。
【符号の説明】
【００８０】
１  予約サーバ
２  ユーザ端末
３  店端末
４  決済代行サーバ
５  通信網
６  情報サイト
１０  予約システム
１００  店情報取得部
１０２  店情報格納部
１０４  ポリシー設定部
１０６  利用登録確認部
１０８  利用登録部
１１０  利用登録通知部
１１２  予約指示受付部
１１４  予約確認部
１１６  予約設定通知部
１１８  変更受付部
１２０  オーソリ実行部
１２２  予約通知部
１２４  キャンセル指示受付部
１２６  キャンセル処理実行部
１２８  決済依頼部
１３０  決済結果通知部
１３２  予約サーバ送信部
１３４  ポリシー格納部
１３５  ポリシー
２００  ユーザ端末入力部
２０２  ユーザ端末出力部
３００  予約情報受付部
３０２  予約設定情報付加部
３０４  店端末送信部
３０６  識別情報取得部
４００  アカウント発行部
４０２  アカウント通知部
４０４  決済部
６００  画面
６０２  人数選択欄
６０４  デポジット入力欄
６０６  予約ポリシー確認欄
６０８  電話番号入力欄
６１０  予約日選択欄
６１２  予約時刻選択欄
６１４  名称入力欄
６１６  用途入力欄
６１８  スタッフ選択欄
６２０  チェックインボーナス指定欄
６２２  人数変更指定欄
６２４  表示領域
【要約】      （修正有）【課題】利用者による予約内容の変更に比較的柔軟に対応できると共に予約日直前の予約人数の大幅な変更を抑制でき、ノーショー等による店の損失の抑制もできる予約システム、予約サーバ、予約方法及び予約プログラムを提供する。【解決手段】予約システム１０において、予約人数及び予約日時を含む予約情報を受け付け、予約情報に、デポジットを含む予約設定情報を付加する店端末３と、予約がキャンセルされた場合にデポジットから徴収する額の割合である徴収割合を定めたポリシーであって、予約人数に応じて決定される１以上の人数カテゴリーごとに異なる内容が設定されているポリシーを、予約情報の予約人数に基づいて予約に対して設定し、予約がキャンセルされた場合、設定したポリシーに基づいてキャンセル処理を実行する予約サーバ１と、を備える。【選択図】図１【図１】
0006934651.tif 000002
【図２】
0006934651.tif 000003
【図３】
0006934651.tif 000004
【図４】
0006934651.tif 000005
【図５】
0006934651.tif 000006
【図６】
0006934651.tif 000007
【図７】
0006934651.tif 000008
【図８】
0006934651.tif 000009
【図９】
0006934651.tif 000010
【図１０】
0006934651.tif 000011