JP2020106912A - 予約手続支援システム、プログラム - Google Patents

Abstract

【課題】キャンセルされてもサービスの提供者の損害発生を抑止でき、キャンセル料徴収時の負担過大化を抑止できる予約手続支援システムを提供する。【解決手段】予約手続支援システム１は、サービスの利用者からサービスの提供者に対して送られる、サービスを予約するための予約申請情報を取得する予約申請取得部１１と、予約申請情報を送った利用者から、サービスを予約するための予約金の支払が行われたか否かを確認する支払確認部１２と、所定期間内に予約金の支払が行われたことが確認された場合に利用者のサービスの予約を確定させる予約確定部１３とを備える。【選択図】図１

Description

本発明は、各種の対価と引き換えに提供される、サービス等の予約の手続を支援する技術に関する。

従来、特定の施設における飲食物の提供、特定敷地で開催されるパーティや宴会等の各種イベント、飲食物や役務のデリバリー等、多様なサービスが提供されている。そして、サービスの提供を求める利用者（以下単に「利用者」と称する。）と、サービスの提供者（以下単に「提供者」と称する。）との間で、提供するサービスの予約を行うための各種システムが提供されている。

具体的には、たとえば、飲食店において飲食や宴会を行いたい利用者と店舗とがネットワークコンピュータシステムを使って予約手続を行う発明が知られている（例えば、特許文献１参照）。

一方、利用者は、サービスの予約を行った後のさまざまな事情の変化でサービスを受けられなくなる得ない事態が生ずることがある。その場合、利用者は予約をキャンセルすることになるが、提供者が提供する施設の設営や提供する物（たとえば料理）の材料の購入や下準備などを始めている場合、提供者は設営費や材料費を回収できずに損害を被ることになる。このような損害の発生を抑止するため、予約しておきながら来店しなかった利用者の情報を決済代行サーバに送信し、決済代行サーバによって各種の処理（たとえば登録されたクレジットカードからの引き落とし）を行う発明が知られている（たとえば、特許文献２参照）。

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

しかし、サービスの提供を予約する利用者や、予約をキャンセルする利用者の事情は多種多様である。そして、特許文献１に記載の発明においては、予約のキャンセルが発生した場合にキャンセル処理を行うための構成が設けられていないので、キャンセルが発生した時に提供者が提供する施設の設営や提供する物（たとえば料理）の材料の購入や下準備などを始めている場合、提供者は設営費や材料費を回収できずに損害を被ることになる。また、キャンセル料の徴収を行う際の提供者側の負担が過大になるという問題がある。

また、サービスの提供を予約する利用者や、予約をキャンセルする利用者が、必ずクレジットカード等を所有しているとは限らない。特に、予約する利用者が複数いる場合、複数の利用者の全員が、提供者の指定するクレジットカードを所持している（つまり、当該クレジットカードによって決済を行う信販会社等と契約済みである。）とは限らない。そのため、予約特許文献２に記載の発明においては、キャンセルが発生した場合に、常に利用者から（特に複数の利用者がいる場合の全ての利用者から）クレジットカードからの料金引き落とし等によって全てのキャンセル料を徴収できるとは限らないという問題がある。そして、特許文献２に記載の発明において、複数の利用者の中の特定の利用者（たとえば宴会の幹事）のみにキャンセル料の徴収を行う場合、その特定の利用者が全ての利用者分のキャンセル料を支払うこととなってその特定の利用者の金銭的な負担が過大となったり、その特定の利用者が個々の利用者からキャンセル料の徴収を別途行う必要が生じ、その特定の利用者の労力が過大になったりするという問題がある。

本発明は上記の問題に鑑みてなされたものであり、予約されたサービスがキャンセルされた場合であっても、サービスの提供者に損害が発生することを抑止でき、発生したキャンセル料の徴収に際してサービスの提供者や利用者の負担が過大になる事態を抑止できる予約手続支援システムを提供することを課題としている。

かかる課題を達成するために、請求項１に記載の発明は、報酬と引き換えに提供されるサービスを予約して利用する利用者と、該利用者が予約した前記サービスを前記報酬と引き換えに提供する提供者との間で、前記サービスの提供の予約に関する手続を行う予約手続支援システムであって、前記利用者から前記提供者に対して送られる、前記サービスを予約するための予約申請情報を取得する予約申請取得手段と、前記予約申請情報を送った前記利用者から、前記サービスを予約するための予約金の支払が行われたか否かを確認する支払確認手段と、所定期間内に前記予約金の支払が行われたことが確認された場合に前記利用者の前記サービスの予約を確定させる予約確定手段とを備えたことを特徴とする。

請求項２に記載の発明は、請求項１に記載の構成に加え、前記予約が確定した後に前記予約のキャンセルが申請された場合、前記予約のキャンセル処理、及び／又は、徴収済の前記予約金から取得したキャンセル料を前記提供者に支払うキャンセル料支払処理を行うキャンセル処理手段を備えたことを特徴とする。

請求項３に記載の発明は、請求項１又は２に記載の構成に加え、前記支払確認手段は、前記予約金が支払われたか否かを、複数の前記利用者の中の代表者、及び／又は、複数の前記利用者のそれぞれ、について確認し、前記予約確定手段は、前記予約金の支払いが確認できた前記利用者だけについて前記サービスの予約を確定させることを特徴とする。

請求項４に記載の発明は、請求項１乃至３の何れか一つに記載の構成に加え、一又は複数の前記利用者からの預かり金としてのデポジットを管理するデポジット管理手段を備え、前記支払確認手段は、前記デポジット管理手段の管理する前記預かり金から金銭を徴収して、徴収した金銭を前記利用者から取得された前記予約金として扱うことを特徴とする。

請求項５に記載の発明は、請求項１乃至４の何れか一つに記載の構成に加え、前記利用者に対する前記サービスの提供によって発生した、追加徴収分の費用を徴収する追加徴収手段を備え、該追加徴収手段は、前記サービスの提供によって発生した請求額から前記予約金の金額を引いた金額を前記追加徴収分の費用として前記利用者に請求する処理を行うことを特徴とする。

請求項６に記載の発明は、請求項５に記載の構成に加え、一又は複数の前記利用者からの預かり金としてのデポジットを管理するデポジット管理手段を備え、前記追加徴収手段は、前記デポジット管理手段が管理する前記デポジットから前記追加徴収分の費用を徴収することを特徴とする。

請求項７に記載の発明は、請求項１乃至６の何れか一つに記載の構成に加え、前記利用者がクレジットカードでの支払を含む後払いで前記サービスの提供を受ける場合の、前記後払いの限度額を取得する処理としてのオーソリを行うオーソリ取得手段と、それぞれの前記利用者の前記オーソリと前記利用者に提供された前記サービスの対価としての請求額とを対比し前記利用者の支払の必要性を判定する判定手段とを備え、該判定手段は、前記利用者に対する前記請求額が前記オーソリの範囲内の場合は、前記サービスの対価についての前記後払いを許諾する処理を行うことを特徴とする。

請求項８に記載の発明は、プログラムであって、コンピュータを請求項１乃至７の何れか一つに記載の予約手続支援システムとして機能させることを特徴とする。

請求項１に記載の発明によれば、利用者から提供者に対して送られる、サービスを予約するための予約申請情報を取得し、予約申請情報を送った利用者から、サービスを予約するための予約金の支払が行われたか否かを確認し、所定期間内に予約金の支払が行われたことが確認された場合に利用者のサービスの予約を確定させることにより、
予約申請情報を送った利用者が、所定期間内に予約金の支払を行った場合のみをサービスの享受の予約があったものとして処理することができる。そのため、利用者が提供者に対し、少なくとも一部のサービスの対価を予約金として前払いで支払った場合のみを予約があったものとし、仮に事後的に予約のキャンセルがあった場合には支払済の予約金からキャンセル料を徴収することを確実に行えるので、予約のキャンセルの発生による提供者の損害の発生を抑止することができる。また、予約申請情報の取得、予約金の支払いの確認、予約の確定をシステムによって行うことにより、予約金の徴収を含む、サービスの予約に必要な手続きをシステム処理によって一律に行うことができて、提供者側も利用者側も、簡易な手続で確実に予約を確定させるまでの一連の作業を行うことができる。これにより、予約されたサービスがキャンセルされた場合であっても、サービスの提供者に損害が発生することを抑止でき、発生したキャンセル料の徴収に際してサービスの提供者や利用者の負担が過大になる事態を抑止できる。

請求項２に記載の発明によれば、予約が確定した後に予約のキャンセルが申請された場合、予約のキャンセル処理、及び／又は、徴収済の予約金から取得したキャンセル料を前記提供者に支払うキャンセル料支払処理を行うことにより、予約確定後に予約がキャンセルされた場合であっても、提供者に確実にキャンセル料の支払を行って、キャンセルの発生によって提供者に損害が生ずる事態をより確実に抑止できる。

請求項３に記載の発明によれば、予約金が支払われたか否かを、複数の利用者の中の代表者、及び／又は、複数の利用者のそれぞれ、について確認することにより、利用者が複数いる場合に、予約金の支払いが行われたか否かを、代表者のみに確認することで手続の簡素化を図ること、及び／又は、それぞれの利用者に確認することで個々の予約金の支払状況を正確に確認すること、が可能となり、手続の簡素化、及び／又は、正確な確認、を実現できる。また、予約金の支払いが確認できた利用者だけについてサービスの予約を確定させることにより、利用者が複数いる場合においても、予約確定後に、その利用者のうちの少なくとも一部にキャンセルが発生した場合、サービスの提供者に損害が発生することをより確実に抑止できる。

請求項４に記載の発明によれば、一又は利用者からの預かり金としてのデポジットを管理し、管理された預かり金から金銭を徴収して、徴収した金銭を前記利用者から取得された予約金として扱うことにより、利用者が予約申請のたびに予約金を支払う手続きを省略し、提供者は既存の預かり金から予約金を徴収することが可能になって、利用者と提供者との双方の予約金の徴収に関する手続の簡素化を図ることが可能となる。

請求項５に記載の発明によれば、利用者に対するサービスの提供によって発生した、追加徴収分の費用について、請求額から予約金の金額を引いた金額を追加徴収分の費用として利用者に請求することにより、サービスの提供によって発生した費用が予約金の金額を上回った場合であっても、予約金を含めて適正な請求額として請求することができて、支払の簡素化を図ると共に適正な金額での請求を実現できる。

請求項６に記載の発明によれば、一又は利用者からの預かり金としてのデポジットを管理し、デポジットから追加徴収分の費用を徴収することにより、サービスの提供によって発生した費用が予約金の金額を上回った場合の請求を、デポジットから引き落とすことが可能となり、支払の簡素化を図ると共に適正な金額での請求を実現できる。

請求項７に記載の発明によれば、利用者に対する請求額が前記オーソリの範囲内の場合は、サービスの対価についての後払いを許諾する処理を行うことにより、支払の信頼性が認められる範囲で、支払態様の多様性を認め、利用者の予約の利便性を向上させることが可能となる。

請求項８に記載の発明によれば、本発明の予約手続支援システムをプログラム化し、多様なコンピュータハードウェア上で実現させることができる。

この発明の実施の形態の予約システムおよび予約手続支援システムにおけるシステム構成図及び機能ブロック図である。 同上予約手続支援システムの処理手順を示すフローチャートである。 同上予約システムを構成する利用者端末の表示部に表示される予約ページを模式的に示した図である。 同上予約システムを構成する利用者端末の表示部に表示される予約承認メールを模式的に示した図である。 同上予約システムを構成する利用者端末の表示部に表示される予約ページを模式的に示した図である。 同上予約システムを構成する利用者端末の表示部に表示される予約承認メールを模式的に示した図である。

［システム構成］
図１乃至図６に、この発明の実施の形態を示す。

図１は、この実施の形態の予約システムのシステム構成図及び機能ブロック図である。同図に示すとおり、予約システム１Ａは、予約手続支援システム１と、Ｎ個（Ｎ≧１）の利用者端末２_１〜２_ｎと、Ｍ個（Ｍ≧１）の店舗端末３_１〜３_ｍとを備えており、予約手続支援システム１と利用者端末２_１〜２_ｎと店舗端末３_１〜３_ｍとは、ＷＡＮ（Wide Area Network）としてのインターネット４を介して相互に交信可能である。

この実施の形態の予約システム１Ａは、報酬と引き換えに提供されるサービス（後述）を予約して利用する利用者（以下単に「利用者」と称する。）と、利用者が予約したサービスを報酬と引き換えに提供する提供者（以下単に「提供者」と称する。）との間での、サービスの提供の予約に関する手続を、インターネット４を介したデータ等の通信によって行うためのシステムである。

予約手続支援システム１は、金融商品の取扱業者が管理し運用するサーバコンピュータであり、Ｗｅｂサーバ機能、データベース機能を備えている。

利用者端末２_１，２_２，・・・，２_ｎは、サービスの提供を受ける個人又は法人が所持し使用する、データ通信機能を有する通信端末であって、スマートフォンやタブレット（符号２_１参照）、携帯電話端末（符号２_２参照）、パーソナルコンピュータ（符号２_ｎ参照）等がこれに該当する。スマートフォンやタブレット、携帯電話からなる利用者端末（符号２_１，２_２参照）はネットワークに無線接続し、パーソナルコンピュータからなる利用者端末（符号２_ｎ参照）はネットワークに無線接続する。利用者端末２_１，２_２，・・・，２_ｎは、マウスやキーボード等各種指示を入力するために用いられる操作部２１_１，２２_２，・・・，２１_ｎ、ＬＣＤ（Liquid Crystal Display）等からなり操作部２１_１，２２_２，・・・，２１_ｎから入力された各種指示等や各種画像を表示する表示部２２_１，２２_２，・・・，２２_ｎを有している。

利用者端末２_１，２_２，・・・，２_ｎの操作部２１_１，２２_２，・・・，２１_ｎと表示部２２_１，２２_２，・・・，２２_ｎは、指やタッチペン等のポインティングデバイスの接触位置の座標情報等に基づいて各種入力を行う、タッチパネル式のディスプレイとして構成されていてもよい。なお、利用者端末２_１，２_２，・・・，２_ｎ、操作部２１_１，２２_２，・・・，２１_ｎ、表示部２２_１，２２_２，・・・，２２_ｎは同じ構成を持つので、以下、区別する必要がある場合を除き、利用者端末２、操作部２１、表示部２２とする。

店舗端末３_１，３_２，・・・，３_ｍは、サービスの提供を受ける個人又は法人が所持し使用する、データ通信機能を有する通信端末であって、スマートフォンやタブレット（符号３_１参照）、携帯電話端末（符号３_２参照）、パーソナルコンピュータ（符号３_ｍ参照）等がこれに該当する。スマートフォンやタブレット、携帯電話からなる店舗端末（符号３_１，３_２参照）はネットワークに無線接続し、パーソナルコンピュータからなる店舗端末（符号３_ｍ参照）はネットワークに無線接続する。店舗端末３_１，３_２，・・・，３_ｍは、マウスやキーボード等各種指示を入力するために用いられる操作部３１_１，３１_２，・・・，３１_ｍ、ＬＣＤ（Liquid Crystal Display）等からなり操作部３１_１，３１_２，・・・，３１_ｍから入力された各種指示等や各種画像を表示する表示部３２_１，３２_２，・・・，３２_ｍを有している。また、店舗端末３_１，３_２，・・・，３_ｍは、ＱＲコード（登録商標）情報確認部３３_１，３３_２，・・・，３３_ｍ、顔認証部３４_１，３４_２，・・・，３４_ｍを備えている。

店舗端末３_１，３_２，・・・，３_ｍの操作部３１_１，３１_２・・・，３１_ｍと表示部３２_１，３２_２，・・・，３２_ｍは、指やタッチペン等のポインティングデバイスの接触位置の座標情報等に基づいて各種入力を行う、タッチパネル式のディスプレイとして構成されていてもよい。

店舗端末３_１，３_２，・・・，３_ｍのＱＲコード（登録商標）情報確認部３３_１，３３_２，・・・，３３_ｍは、ＱＲコード（登録商標）を読み取って取得した、それぞれの利用者の情報や、それぞれの利用者の予約情報が、予約手続支援システム１のデータベース２０（後述）に記録された予約情報と一致するか否かを確認する。店舗端末３_１，３_２，・・・，３_ｍの顔認証部３４_１，３４_２，・・・，３４_ｍは、利用者の顔画像を取得し、取得した顔画像の人物が予約申請を行った利用者の顔であるか否かを確認し判定する。

なお、店舗端末３_１，３_２・・・，３_ｍ、操作部３１_１，３１_２，・・・，３１_ｍ、表示部３２_１，３２_２，・・・，３２_ｍ、ＱＲコード（登録商標）情報確認部３３_１，３３_２，・・・，３３_ｍ、顔認証部３４_１，３４_２，・・・，３４_ｍは同じ構成を持つので、以下、区別する必要がある場合を除き、店舗端末３、操作部３１、表示部３２、ＱＲコード（登録商標）情報確認部３３、顔認証部３４とする。

図示しないが、予約手続支援システム１は少なくとも１のＣＰＵ（Central Processing Unit、中央処理装置）、及び、ＣＰＵの作業領域として機能するＲＡＭ（Random Access Memory）、起動用ブートプログラム等が記録されたＲＯＭ（Read Only Memory）、各種プログラムやデータ等が記録されるハードディスク等の補助記憶装置、データの送受信に用いる通信インターフェース、マウス、キーボード等、オペレータが予約手続支援システムの操作を行うための操作部、ＬＣＤ等からなり文字や画像を表示する表示部等が設けられている。補助記憶装置には、ＯＳ（Operating System）用プログラム、各種アプリケーションプログラム、データベースに記録されたデータ等が記録されており、これらのプログラムやデータはＣＰＵの演算処理により、ハードウェア資源と協働して各種機能を実現する。なお、利用者端末２、店舗端末３も、予約手続支援システム１同様のＣＰＵ、ＲＡＭ、ＲＯＭ、補助記憶装置、通信インターフェース等を有する。

図１に示す通り、予約手続支援システム１は、上述した各種プログラムとハードウェア資源とに基づいて実現される機能手段として、「予約申請取得手段」としての予約申請取得部１１、「支払確認手段」としての支払確認部１２、「予約確定手段」としての予約確定部１３、「キャンセル処理手段」としてのキャンセル処理部１４、「追加徴収手段」としての追加徴収部１５、「デポジット管理手段」としてのデポジット管理部１６、「オーソリ取得手段」としてのオーソリ取得部１７、「判定手段」としての判定部１８、予約者評価部１９、及びデータベース２０を備えている。

予約申請取得部１１は、利用者から提供者に対して送られる、サービスを予約するための予約申請情報を取得する処理を行う。具体的には、利用者によって利用者端末２から入力された、各種の予約申請情報を取得する処理を行う。

支払確認部１２は、予約申請情報を送った利用者から、サービスを予約するための予約金の支払が行われたか否かを確認するための処理を行う。具体的には、利用者端末２から予約申請情報を送った利用者による、利用者端末２から予約金の支払手続きが行われたか否かを確認する処理を行う。

なお、支払確認部１２において確認される利用者の支払いは、信販会社や決済代行会社のシステム（図示せず）に利用者が予約金の決済手続きを行ったことが、信販会社や決済代行会社のシステムから予約手続支援システム１に送信されることで行われてもよいし、利用者が予約手続支援システム１の決済処理部（図示せず）に対して直接入金処理を行う（たとえば銀行口座や予納口座等から決済処理部（図示せず）に対する入金処理を行う）ことで行われてもよいし、その他、支払いを実行するためのどのような態様でおこなわれてもよい。

また、支払確認部１２は、一の予約を行った利用者が複数存在する場合（たとえば、特定の宴会を予約した、宴会参加者としての利用者が複数名いる場合）、予約金が支払われたか否かを、複数の利用者の中の代表者、及び／又は、複数の利用者のそれぞれ、について確認を行う。即ち、支払確認部１２は、予約金が支払われたか否かを、複数の利用者（たとえば個々の宴会参加者）に対してそれぞれ確認することもできるし、代表者（たとえば宴会の幹事）に対してのみ行うこともできる。

予約確定部１３は、所定期間内に予約金の支払が行われたことが確認された場合に利用者のサービスの予約を確定させるための処理を行う。具体的には、利用者端末２から予約申請情報を送った利用者が、利用者端末２から予約金の支払の手続きを行い、この手続きが完了したことを確認した場合に、その利用者のサービスの予約を確定させる処理を行う。

予約確定部１３は、一の予約を行った利用者が複数存在する場合（たとえば、特定の宴会を予約した、宴会参加者としての利用者が複数名いる場合）、予約金の支払いが確認できた利用者だけについてサービスの予約を確定させることができる。また、予約確定部１３は、一の予約を行った利用者が複数存在する場合、それぞれの利用者のサービスの予約の確定状況を代表者（たとえば、予約申請情報に記録されている代表者（たとえば宴会の幹事））に提供する機能（たとえば、予約を行った利用者の氏名などを報告するためのメールを代表者に送信する機能など）を備えている。このような機能を備えたことにより、利用者の代表者は、予約した者の氏名や予約人数を提供者に報告する必要がなくなり、利用者の代表者の予約にあたっての労力が過大になることを抑止できる。

キャンセル処理部１４は、予約が確定した後に予約のキャンセルが申請された場合、予約のキャンセル処理、及び／又は、徴収済の予約金から取得したキャンセル料を提供者に支払うキャンセル料支払処理を行うための処理を行う。具体的には、利用者端末２から予約申請情報を送り、サービスの予約を確定させた利用者が、サービスの確定後に利用者端末２等から予約をキャンセルする処理を行い、予約をキャンセルする旨の情報を取得した場合に、支払確認部１２において確認済みである、予約にあたって利用者から支払処理が行われた予約金の中から、キャンセル料に相当する額をキャンセル料に充当させる処理を行う。

また、キャンセル処理部１４は、一の予約を行った利用者が複数存在し、かつ、サービスの予約の登録が確定した利用者も複数存在するときに、利用者から予約のキャンセルが申請されて予約をキャンセルする処理を行った場合、それぞれの利用者のサービスの予約の確定状況を代表者（たとえば、予約申請情報に記録されている代表者（たとえば宴会の幹事））に対し、キャンセルを行った利用者の氏名やキャンセルを行った日時などを提供する機能（たとえばキャンセルした利用者の氏名やキャンセルの日時を報告するメールを代表者に送信する機能など）を備えている。このような機能を備えたことにより、利用者の代表者は、キャンセルした者の氏名や人数を提供者に報告する必要がなくなり、利用者の代表者の予約にあたっての労力が過大になることを抑止できる。

キャンセル処理部１４は、一の予約を行った利用者が複数存在し、かつ、サービスの予約の登録が確定した利用者も複数存在するときに、予約をキャンセルする利用者が出現した場合、原則として、キャンセル料の支払手続きを、キャンセルする利用者に行わせる。これにより、複数の利用者の中の代表者（たとえば宴会の幹事）が、他の利用者のキャンセル料を立て替え払いして代表者の手続的・金銭的負担が過大になることを抑止できる。ただし、キャンセル料の支払手続きを、複数の利用者の中の代表者に対して行わせるようにすることもできる。

追加徴収部１５は、予約申請取得部１１が取得した情報に基づいて予約されたサービスが利用者に提供されたことで発生した、追加徴収分の費用を徴収する。具体的には、追加徴収部１５は、利用者に対して提供されたサービスの提供によって発生した費用の情報と、利用者から支払処理が行われた予約金の額を照合し、費用の総額から予約金の額を引いた額を算出し、この算出された額を追加徴収分として利用者に請求する。この請求は、利用者端末に対して送信されるメール等によって行われてもよいし、利用者の銀行口座からの自動引き落とし、利用者のクレジットカード等に係る信販会社や決済代行会社に対する請求として行われてもよい。

追加徴収部１５は、一の予約を行った利用者が複数存在し、かつ、サービスの予約の登録が確定した利用者も複数存在する場合、原則として、個々の利用者に追加徴収分の費用を請求する。これにより、複数の利用者の中の代表者（たとえば宴会の幹事）が他の利用者の追加徴収分の費用を立て替え払いして代表者の手続的・金銭的負担が過大になることを抑止できる。ただし、追加徴収分の費用の支払手続きを、複数の利用者の中の代表者に対して行わせるようにすることもできる。

デポジット管理部１６は、一又は複数の利用者からの預かり金としてのデポジット（以下単に「デポジット」と称する。）を管理する。なお、この場合、デポジット管理部１６は、利用者が予約手続支援システム１に対して直接行ったデポジットの入金情報を管理していてもよいし、利用者の手続きにより、信販会社や決済代行会社からデポジットとして設定された金額の入金情報や、利用者の銀行口座からデポジットとして入金された金額の入金情報等を管理してもよい。

デポジット管理部１６は、前述の追加徴収部１５が追加徴収分の費用を算出した場合において、利用者のデポジットが存在する場合、利用者からの利用者端末２を用いた申請や、提供者からの店舗端末３を用いた申請や、予め設定されたプログラム処理に基づく自動処理等により、利用者に発生した追加徴収分の費用を、その利用者のデポジットから徴収することができる。

オーソリ取得部１７は、利用者が、クレジットカードでの支払を含む後払いでサービスの提供を受ける場合の、前記後払いの限度額を取得する処理としてのオーソリ（以下単に「オーソリ」と称する。）を行う。

判定部１８は、それぞれの利用者のオーソリと利用者に提供されたサービスの対価としての請求額とを対比し利用者の支払の必要性を判定する。判定部１８は、この判定の結果、利用者に対する請求額がオーソリの範囲内であることを確認した場合には、その、オーソリの範囲であることが確認された利用者に対する、サービスの対価についての後払いを許諾する処理を行う。

つまり、判定部１８は、請求額がオーソリの範囲内であることを確認した利用者に対しては、ただちに請求額の請求を行わず、所定の猶予期間（たとえば支払が発生した日の属する月の翌月の所定の支払日まで）を猶予したのちに、その利用者に対して請求額にあたる金額の支払いを請求したり（たとえば支払いを要求するメールを送信する、など。）、または、支払を行わせる処理を行う（たとえばその利用者の銀行口座から請求額に対応する額の金額を引き落とす処理を行う、など。）。

予約者評価部１９は、予約手続支援システム１を用いてサービスの提供の予約を行った利用者それぞれの評価を行い、店舗端末３を利用する提供者の要求があった場合や、利用者端末２を利用する利用者からサービスの予約があった場合などの所定の場合に、サービスを提供する提供者の店舗端末３に、利用者ごとの評価情報を表示させる。

この、予約者評価部１９における評価情報とは、利用者ごとの、たとえば下記（情報１）〜（情報６）のような情報として取得されてデータベース２０に記録される。
（情報１）利用者が過去に予約を行った件数
（情報２）利用者が過去の予約において予約金を支払った件数
（情報３）利用者が過去の予約において予約金を支払わなかった件数
（情報４）利用者がキャンセル手続きを行った、キャンセル料が発生する前のキャンセルの数
（情報５）利用者がキャンセル手続きを行った、キャンセル料が発生した後のキャンセルの数
（情報６）利用者がキャンセル手続きを行い、キャンセル料が発生したケースの数
（情報７）利用者がキャンセル手続きを行わず、キャンセル料が発生したケース
（情報８）利用者がキャンセル手続きを行わなかったが、キャンセル料が発生しなかったケース
（情報９）上記（情報１）〜（情報８）を含む情報を元に算出された、利用者それぞれのキャンセルリスク（その利用者が確定した予約をキャンセルするリスクの指数や、その利用者によって生じたキャンセルの発生によって提供者が損害を被るリスクの指数など）
予約者評価部１９は、（情報１）〜（情報９）の情報を、利用者を特定するための情報、たとえば、利用者の氏名、電話番号、メールアドレス等と関連付けた状態でデータベース２０に記録する。そして、予約者評価部１９は、たとえば、店舗端末３から特定の利用者の氏名や電話番号やメールアドレスをもとに予約者の評価に関する情報の取得を要求された場合、この、利用者の氏名や電話番号やメールアドレスに基づいて対応する利用者の（情報１）〜（情報９）のうちの一部又は全部の情報を取得して、店舗端末３の表示部３２に取得した情報を表示させる。これにより、提供者に、それぞれの利用者のキャンセルリスクを把握させ、提供者がその予約者の予約申請を承認してよいか否かの判断を行うための材料を提供とすることができる。

データベース２０には、上述の、予約者評価部１９によって取得され作成された利用者ごとの評価情報をはじめとする、予約手続支援システム１において予約手続等を行う上で必要な各種の情報が記録されている。

［この実施の形態の「サービス」について］
この実施の形態における「サービス」とは、利用者が払う報酬と引き換えに提供者が利用者に提供する各種の役務であって、提供の日時や場所についての予約が可能なものをいう。

具体的には、たとえば下記の（例１）〜（例３）に示すものがあげられる。なお、（例１）〜（例３）はあくまでも一例であって、この実施の形態の「サービス」が（例１）〜（例３）のみに限定することを示すものではない。
（例１）特定の敷地内（たとえば店舗の建物内や、店舗の所有又は占有する土地など）において行われる、飲食物や施設の提供。たとえば、レストランや居酒屋等の飲食店における宴席や飲み物や食べ物の提供が該当する。またたとえば、ホテルや旅館における宿泊の提供が該当する。またたとえば、コンサートホールでの音楽鑑賞の機会提供や劇場での観劇の機会提供やスポーツ競技場におけるスポーツ観戦の機会提供などが該当する。またたとえば、鉄道やバスや旅客機や旅客船など、各種公共交通機関の乗車券の確保による乗車機会、搭乗機会、乗船機会の提供などが該当する。
（例２）利用者の自宅や所在地への物品の配送や役務の提供が該当する。たとえば、飲食物の出前による宅配や、家政婦やホームヘルパーの派遣などが該当する。
（例３）利用者の所持品や譲渡品等の移送が該当する。たとえば、利用者の依頼による物品の宅配や、引越サービスの提供などが該当する。

なお、以下、この実施の形態の説明においては、上述のような「サービス」の一例として、店舗内での飲食物の提供、特に、複数の利用者によるレストランでの会食の提供や、複数の利用者による居酒屋での宴席の提供などに基づいて説明する。

［処理手順］
以下、この実施の形態における処理手順について説明する。

［利用者と提供者の利用登録］
利用者と提供者は、それぞれ、予約システム１Ａの利用登録を行う。

利用者は、利用者端末２の操作部２１を用いて、自らの氏名、電話番号、メールアドレス（これらが、個々の利用者を特定するための情報となる）や、ログインＩＤやログインパスワード等の情報を入力し、予約手続支援システム１に記録する。

また、利用者が、予約にあたって、デポジットを行うことや、金銭の支払いにあたって銀行口座からの引き落としや信販会社や決済代行会社からの支払を行うことを希望する場合には、利用者は、利用者端末２の操作部２１から自らの銀行口座情報やクレジットカードの情報等を入力し、それらの情報を予約手続支援システム１に記録する。

なお、利用者が信販会社や決済代行会社からの支払を希望する場合、予約手続支援システム１のオーソリ取得部１７は、利用者が契約する信販会社や決済代行会社のシステムに問合せを行って、オーソリの情報を取得する。

一方、提供者も、店舗端末３の操作部３１を用いて、自らの会社名、代表者名、メールアドレス、電話番号等の情報や、ログインＩＤやログインパスワード等の情報を入力し、予約手続支援システム１に記録する。

なお、利用者が複数いる場合には、個々の利用者が上記の情報を予約手続支援システム１に記録することが望ましいが、一部の利用者が予約手続支援システム１に上記の情報を記録していなくても、予約手続支援システム１によって予約手続を行うことができるように設定することもできる。

［利用登録完了後の手続］
図２は、利用登録完了後の手続を示すフローチャートであり、図３乃至図６は、利用者端末２の表示部２２や店舗端末３の表示部３２に表示される画面の模式図である。以下、これらのフローチャートや模式図を参照しつつ、処理手順を説明する。なお、図３ないし図６においては、利用者端末２や店舗端末３はスマートフォンであり、表示部２２や表示部３２はスマートフォンのタッチパネルとして説明するが、利用者端末２や店舗端末３の態様や、表示部２２や表示部３２の態様はどのようなものでもよい。

［（１）予約者が１名の場合の予約申請手続］
利用者がサービスの提供の予約を行う場合、利用者端末２の表示部２２にログイン画面（図示せず）を表示させ、ログインＩＤとログインパスワードを入力する。これにより、利用者の利用者端末２は予約手続支援システム１にログインし、利用者端末２の表示部２２には、図３に概念図を示す、予約ページ４１ａが表示される（ステップＳ１）。

図３に示す、予約ページ４１ａには、サービスの提供を受けたい提供者（たとえば提供者の店舗名や支店名など）の提供者情報入力欄４２、予約情報入力欄４３が表示される。

予約情報入力欄４３は、たとえば図２に示すように、予約日時入力欄４３１、予約者氏名入力欄４３２、予約するサービス名を入力する予約品名入力欄４３３、予約金額を入力する予約金額入力欄４３４、予約人数入力欄４３５、電話番号、及び／又はメールアドレスを入力する連絡先入力欄４３６が表示される。なお、予約ページ４１ａが１名のみの予約専用のページである場合、予約人数入力欄４３５は存在しなくてもよい。また、予約金額入力欄４３４が存在せず、予約品名入力欄４３３にサービス名を入力すると、予約金額が自動的に設定される構成となっていてもよい。この場合、予約手続支援システム１のデータベース２０に記録された情報中に、予約品名入力欄４３３に入力された商品名やサービス名に基づいて予約金額を特定するための情報が記録されていることが望ましい。

特定の利用者がそれぞれの入力欄４２，４３１，４３２，４３３，４３４，４３５，４３６、に必要な情報を入力して実行ボタン４４をクリックすると、入力した情報が予約手続支援システム１のデータベース２０に記録される。

それぞれの入力欄４２，４３１，４３２，４３３，４３４，４３５，４３６、に必要な情報が入力された状態で実行ボタン４４がクリックされると、予約申請がされた提供者の店舗端末３の表示部３２に、予約の申請があった旨の表示がされる（ステップＳ２）。

ここで、提供者が、店舗端末３から、その予約申請のあった利用者に関する評価情報の提供を求める入力を行うと、予約手続支援システム１の予約者評価部１９は、店舗端末３の表示部３２に評価情報表示画面（図示せず）を表示させる。この評価情報表示画面（図示せず）には、上記（情報１）〜（情報６）に示すような、予約申請のあった利用者に関する評価情報が表示されている。

評価情報表示画面（図示せず）の評価情報を確認した提供者が予約申請を承認する場合（ステップＳ３の“Ｙｅｓ”）、予約手続支援システム１の支払確認部１２は利用者の利用者端末２に、予約金の支払方法を選択させるための選択画面（図示せず）を表示させる。

選択画面（図示せず）には、利用者が、予約金の支払にあたり、現金支払、銀行振込、クレジットカード等の決済方法を選択する選択ボタン（図示せず）が、チェックボックス形式やラジオボタン形式で表示されている。利用者が利用者端末２において、選択ボタン（図示せず）をチェック又はクリックして特定の支払方法を選択すると（ステップＳ４）、予約手続支援システム１の支払確認部１２は、選択された支払方法での支払が可能かどうかを確認する。

選択された支払方法が可能な場合（ステップＳ５の“Ｙｅｓ”）、予約手続支援システム１から利用者の利用者端末２に対し、予約承認メール５１（図４参照）が送付されて予約が承認される（ステップＳ６）。この予約承認メール５１（図４参照）は、連絡先入力欄４３６に入力されたメールアドレス宛てに送信される。また、連絡先入力欄４３６に携帯電話番号が入力された場合、その携帯電話番号宛てのショートメールによって予約承認メール５１が送信されてもよいし、その他いかなる方法で取得されたメールアドレス宛てに予約承認メール５１（図４参照）が送信されてもよい。

なお、ステップＳ３で提供者が予約申請を承認しない場合（ステップＳ３の“Ｎｏ”）、および、ステップＳ５で、利用者が選択した支払方法での予約金の支払いができない場合（ステップＳ５の“Ｎｏ”）予約手続支援システム１から利用者の利用者端末２に対しては、予約が承認されない旨の情報が送信され、利用者端末２の表示部２２にはその旨の表示がされる（ステップＳ７）。

図４は、利用者端末２の表示部２２に表示された予約承認メールを模式的に示すものである。同図に示すとおり、予約承認メール５１には、予約内容を利用者端末２の表示部２２や店舗端末３の表示部３２に表示させるためのＱＲコード（登録商標）５２が表示されている。

なお、予約承認メール５１の送信とともに、利用者端末２に、利用者端末２に装備されたカメラによって利用者の顔画像を撮影し、撮影した顔画像を予約手続支援システム１のデータベース２０に記録させる構成を備えていてもよい。この顔画像は、たとえば、後述する顔認証による予約情報の確認等に用いられる。

予約承認メール５１を取得した利用者は、予約した日時に予約した提供者の店舗に行き、店舗において、予約内容の確認手続きを行う。具体的には、たとえば、下記第一の方法、及び、第二の方法が考えられる。

第一の方法を説明する。第一の方法では、予約承認メール５１のＱＲコード（登録商標）５２を店舗端末３のＱＲコード（登録商標）情報確認部３３に読み取らせると、店舗端末３から予約手続支援システム１に読み取り情報が送信され、予約手続支援システム１においては、読み取った予約情報が、データベース２０に記録された予約情報と一致するかを確認する。

双方が一致した場合には（ステップＳ８の“Ｙｅｓ”）、予約手続支援システム１から店舗端末３に対し、ＱＲコード（登録商標）の予約情報が正しい旨の情報が送信され、店舗端末３の表示部３２にその旨の表示がされる（ステップＳ９）。ＱＲコード（登録商標）の読み取り情報がデータベース２０に記録された予約情報と一致しない場合（ステップＳ８の“Ｎｏ”）、ＱＲコード（登録商標）の予約情報が正しくない旨の情報が送信され、店舗端末３の表示部３２にその旨の表示がされる（ステップＳ１０）。

第二の方法を説明する。第二の方法として、利用者の顔画像の情報が、予約情報に関連付けられて予約手続支援システム１のデータベース２０に記録されている場合は、利用者は、店舗端末３の顔認証部３４において顔画像を撮影する。顔認証部３４は、予約手続支援システム１のデータベース２０に記録された顔画像、および顔画像に関連付けられて記録された予約情報との照合を行い、顔画像および予約情報が双方とも一致した場合には（ステップＳ８の“Ｙｅｓ”）ステップＳ９の処理が行われ、一致しない場合には（ステップＳ８の“Ｎｏ”）ステップＳ１０の処理が行われる。

第一の方法、第二の方法において、ステップＳ８の“Ｙｅｓ”として、予約情報が正しい旨の表示が表示部３２に表示されると、利用者は店舗でサービスの提供を享受することができる（ステップＳ９）。

サービスの享受が終了し、利用者の支払金額が確定すると、店舗端末３から予約手続支援システム１に支払金額の情報が送信される。予約手続支援システム１は、支払金額と予約金の金額を比較し、支払金額が予約金の金額以下であれば（ステップＳ１１の“Ｙｅｓ”）、予約手続支援システム１は、予約金から支払金額を徴収する旨の処理を行う（ステップＳ１２）。

予約手続支援システム１の比較の結果、支払金額が予約金の金額を超えている場合（ステップＳ１１の“Ｎｏ”）、予約手続支援システム１において追加徴収の手続を行う（ステップＳ１３）。具体的には、追加徴収部１５が、追加徴収分の費用が発生した個々の利用者に対して、追加徴収分の費用を徴収する手続きを行う。また、利用者がデポジットを有している場合には、デポジット管理部１６は、デポジットから追加徴収分の費用を徴収する。さらに、利用者がクレジットカードでの決済を希望している場合であり、判定部１８が追加徴収分の金額がオーソリの範囲であると判定した場合、追加徴収の実行を遅延させることもできる。

ステップＳ１２やステップＳ１３の後、店舗端末３から予約手続支援システム１に対しては、決済金額の内容の情報が送信され、予約手続支援システム１のデータベース２０に決済金額の内容の情報が記録される。予約手続支援システム１から利用者端末２に対しては、会計内容を通知するメールが送信される（ステップＳ１４）。なお、ステップＳ１３において、利用者が予約手続支援システムのサイトに利用者端末２からログインすると、会計情報が表示部２２に表示されるように構成してもよい。そして、ステップＳ１３の後、提供者の店舗端末３や予約手続支援システム１から利用者の利用者端末２に対して領収書がメール添付ファイル等によって送信されたり、利用者端末２から予約手続支援システム１にアクセスすると、ＵＲＬ先に示されたサイトに領収書が閲覧可能に表示されたりするように構成してもよい。

［（２）予約者が複数名の場合の予約申請手続］
予約者が複数名の場合、ステップＳ１において、利用者端末２の表示部２２には、図５に概念図を示す、予約手続支援システム１の予約ページ４１ｂが表示される。

図５に示す予約ページ４１ｂには、予約情報入力欄４３は、たとえば図３に示す予約ページ４１ａの予約者氏名入力欄４３２に替えて、Ｋ名（Ｋ≧１）の利用者それぞれの予約者氏名入力欄４３２_１，４３２_２，・・・４３２_ｋ、連絡先入力欄４３６に替えて、Ｋ名（Ｋ≧１）の利用者それぞれの電話番号、及び／又はメールアドレスを入力する連絡先入力欄４３６_１，４３２_２，・・・４３６_ｋ、が表示され、また、代表者（たとえば宴会の幹事）をチェックボックスで選択して指定するＫ個（Ｋ≧１）の代表者選択欄４３７_１，４３７_１，・・・４３７_ｋ、が表示される（なお、代表者選択欄４３７_１，４３７_１，・・・４３７_ｋへのチェックで代表者として指定された利用者の利用者端末２に対しては、予約手続支援システム１から、予約した利用者の氏名や予約人数を報告するメールや、確定した予約をキャンセルした利用者の情報を報告するメール等が送信されるように構成される。）。

なお、図３に示す予約ページ４１ａを１名のみの予約専用ページ、図５に示す予約ページ４１ｂを複数名での予約専用ページとする場合、予約人数入力欄４３５は存在しなくてもよい。また、表示部２２に図３に示す予約ページ４１ａが表示された状態で、予約人数入力欄４３５に複数名の人数が入力されて実行ボタン４４がクリックされた場合に、表示部２２に、図５に示す予約ページ４１ｂが表示されるように構成してもよい。

特定の利用者（たとえば宴会の幹事）がそれぞれの入力欄４２，４３１，４３２_１，・・・４３２_ｋ，４３３，４３４，４３５，４３６_１，４３６_２・・・４３６_ｋ，４３７_１，４３７_２・・・４３７_ｋ、に必要な情報を入力して実行ボタン４４をクリックすると、入力した情報が予約手続支援システム１のデータベース２０に記録される。すると、個々の利用者の利用者端末２（つまり、連絡先入力欄４３６_１，４３６_２・・・４３６_ｋに入力されたメールアドレスや携帯電話の電話番号）に、予約承認メール５１（携帯電話番号に対して送信されるショートメールを含む。）が送信される。ここの利用者は、店舗において、それぞれ、予約承認メール５１に基づく予約確認手続きを行う。それ以外の処理は、上記と同じである。

［キャンセル手続］
上記（１）（２）の予約申請手続により予約が確定した後、利用者がキャンセル手続を行う場合、利用者は、利用者端末２に予約キャンセル画面を表示させて、この予約キャンセル画面上でキャンセル手続を行う。

具体的には、たとえば、確定した予約をキャンセルしたい利用者は、利用者端末２の表示部に、図４に示す予約承認メール５１を表示させる。利用者が、操作部２１の操作により、予約承認メール５１のキャンセル用ＵＲＬ５３をクリックすると、キャンセル用ＵＲＬ５３に付加されたハイパーリンクによって、利用者端末２の表示部２２には、予約手続支援システム１の予約キャンセル画面が表示される。なお、利用者端末２の表示部２２に予約キャンセル画面を表示させる方法は、予約承認メール５１のキャンセル用ＵＲＬ５３以外のどのようなものであってもよい。たとえば、利用者が利用者端末２で予約手続支援システム１にアクセスして表示部２２に予約キャンセル画面を表示させるような態様でもよい。

図６は、利用者端末２の表示部２２に表示された予約キャンセル画面を模式的に示したものである。この予約キャンセル画面６１には、キャンセルする予約情報が表示されている。予約キャンセル画面６１には、予約金表示欄６２に、利用者が支払い済みの予約金の金額が表示され、キャンセル料表示欄６３に発生したキャンセル料の金額が表示される。また、キャンセル画面には、キャンセルを実行する際にクリックする実行ボタン６４と、キャンセルを取り止める際にクリックする取り消しボタン６５が表示されている。

図６に示した状態で、利用者が実行ボタン６４をクリックすると、利用者端末２から予約手続支援システム１に、利用者からのキャンセル要求を示す情報が送信される。この情報を予約手続支援システムが受領すると、予約手続支援システム１は確定した予約をキャンセルする手続を行う。

具体的には、ステップＳ２２において、予約手続支援システム１のキャンセル処理部１４は、予約手続において発生するキャンセル料を算出し、既に利用者から取得している予約金とキャンセル料とを比較し、キャンセル料の金額が予約金の金額以下の場合は予約金からキャンセル料を徴収する。

一方、キャンセル料の金額が予約金の金額よりも大きい場合、キャンセル料の追加徴収を行う。たとえば、予約手続支援システム１から利用者の利用者端末２に対し、キャンセル料から予約金を引いた差額分の追加徴収を連絡するメールを送信する。

また、デポジット管理部１６がその利用者のデポジットを管理している場合、キャンセル処理部１４はそのデポジットから、キャンセル料から予約金を引いた差額分の追加徴収を行う。さらに、その利用者がクレジットカードでの決済を希望している場合であって、判定部１８は、その差額分の追加徴収の実行期限を猶予する処理を行うこともできる。

上述したとおり、キャンセル処理部１４は、一の予約を行った利用者が複数存在し、かつ、サービスの予約の登録が確定した利用者も複数存在するときに、予約をキャンセルする利用者が出現した場合、キャンセル料の支払手続きを、キャンセルする利用者に行わせる。

また、上述したとおり、キャンセル処理部１４は、一の予約を行った利用者が複数存在し、かつ、サービスの予約の登録が確定した利用者も複数存在するときに、利用者から予約のキャンセルが申請されて予約をキャンセルする処理を行った場合、それぞれの利用者のサービスの予約の確定状況を代表者（たとえば、予約申請情報に記録されている代表者（たとえば宴会の幹事））に対し、キャンセルを行った利用者の氏名やキャンセルを行った日時などをメール送信などによって提供する。

［効果］
以上示したとおり、この実施の形態においては、利用者から提供者に対して送られる、サービスを予約するための予約申請情報を取得し、予約申請情報を送った利用者から、サービスを予約するための予約金の支払が行われたか否かを確認し、所定期間内に予約金の支払が行われたことが確認された場合に利用者のサービスの予約を確定させることにより、予約申請情報を送った利用者が、所定期間内に予約金の支払を行った場合のみをサービスの享受の予約があったものとして処理することができる。そのため、利用者が提供者に対し、少なくとも一部のサービスの対価を予約金として前払いで支払った場合のみを予約があったものとし、仮に事後的に予約のキャンセルがあった場合には支払済の予約金からキャンセル料を徴収することを確実に行えるので、予約のキャンセルの発生による提供者の損害の発生を抑止することができる。また、予約申請情報の取得、予約金の支払いの確認、予約の確定をシステムによって行うことにより、予約金の徴収を含む、サービスの予約に必要な手続きをシステム処理によって一律に行うことができて、提供者側も利用者側も、簡易な手続で確実に予約を確定させるまでの一連の作業を行うことができる。これにより、予約されたサービスがキャンセルされた場合であっても、サービスの提供者に損害が発生することを抑止でき、発生したキャンセル料の徴収に際してサービスの提供者や利用者の負担が過大になる事態を抑止できる。

この実施の形態においては、予約が確定した後に予約のキャンセルが申請された場合、予約のキャンセル処理、及び／又は、徴収済の予約金から取得したキャンセル料を前記提供者に支払うキャンセル料支払処理を行うことにより、予約確定後に予約がキャンセルされた場合であっても、提供者に確実にキャンセル料の支払を行って、キャンセルの発生によって提供者に損害が生ずる事態をより確実に抑止できる。

この実施の形態においては、予約金が支払われたか否かを、複数の利用者の中の代表者、及び／又は、複数の利用者のそれぞれ、について確認することにより、利用者が複数いる場合に、予約金の支払いが行われたか否かを、代表者のみに確認することで手続の簡素化を図ること、及び／又は、それぞれの利用者に確認することで個々の予約金の支払状況を正確に確認すること、が可能となり、手続の簡素化、及び／又は、正確な確認、を実現できる。また、予約金の支払いが確認できた利用者だけについてサービスの予約を確定させることにより、利用者が複数いる場合においても、予約確定後に、その利用者のうちの少なくとも一部にキャンセルが発生した場合、サービスの提供者に損害が発生することをより確実に抑止できる。

この実施の形態においては、一又は利用者からの預かり金としてのデポジットを管理し、管理された預かり金から金銭を徴収して、徴収した金銭を前記利用者から取得された予約金として扱うことにより、利用者が予約申請のたびに予約金を支払う手続きを省略し、提供者は既存の預かり金から予約金を徴収することが可能になって、利用者と提供者との双方の予約金の徴収に関する手続の簡素化を図ることが可能となる。

この実施の形態においては、利用者に対するサービスの提供によって発生した、追加徴収分の費用について、請求額から予約金の金額を引いた金額を追加徴収分の費用として利用者に請求することにより、サービスの提供によって発生した費用が予約金の金額を上回った場合であっても、予約金を含めて適正な請求額として請求することができて、支払の簡素化を図ると共に適正な金額での請求を実現できる。

この実施の形態においては、一又は利用者からの預かり金としてのデポジットを管理し、デポジットから追加徴収分の費用を徴収することにより、サービスの提供によって発生した費用が予約金の金額を上回った場合の請求を、デポジットから引き落とすことが可能となり、支払の簡素化を図ると共に適正な金額での請求を実現できる。

この実施の形態においては、利用者に対する請求額が前記オーソリの範囲内の場合は、サービスの対価についての後払いを許諾する処理を行うことにより、支払の信頼性が認められる範囲で、支払態様の多様性を認め、利用者の予約の利便性を向上させることが可能となる。

上記実施の形態は本発明の例示であり、本発明が上記実施の形態のみに限定されることを意味するものではないことは、いうまでもない。

１・・・予約手続支援システム
１１・・・予約申請取得部（予約申請取得手段）
１２・・・支払確認部（支払確認手段）
１３・・・予約確定部（予約確定手段）
１４・・・キャンセル処理部（キャンセル処理手段）
１５・・・追加徴収部（追加徴収手段）
１６・・・デポジット管理部（デポジット管理手段）
１７・・・オーソリ取得部（オーソリ取得手段）
１８・・・判定部（判定手段）

Claims (8)

1. 報酬と引き換えに提供されるサービスを予約して利用する利用者と、該利用者が予約した前記サービスを前記報酬と引き換えに提供する提供者との間で、前記サービスの提供の予約に関する手続を行う予約手続支援システムであって、
   前記利用者から前記提供者に対して送られる、前記サービスを予約するための予約申請情報を取得する予約申請取得手段と、
   前記予約申請情報を送った前記利用者から、前記サービスを予約するための予約金の支払が行われたか否かを確認する支払確認手段と、
   所定期間内に前記予約金の支払が行われたことが確認された場合に前記利用者の前記サービスの予約を確定させる予約確定手段とを備えたことを特徴とする予約手続支援システム。
2. 前記予約が確定した後に前記予約のキャンセルが申請された場合、前記予約のキャンセル処理、及び／又は、徴収済の前記予約金から取得したキャンセル料を前記提供者に支払うキャンセル料支払処理を行うキャンセル処理手段を備えたことを特徴とする請求項１に記載の予約手続支援システム。
3. 前記支払確認手段は、前記予約金が支払われたか否かを、複数の前記利用者の中の代表者、及び／又は、複数の前記利用者のそれぞれ、について確認し、
   前記予約確定手段は、前記予約金の支払いが確認できた前記利用者だけについて前記サービスの予約を確定させることを特徴とする請求項１又は２に記載の予約手続支援システム。
4. 一又は複数の前記利用者からの預かり金としてのデポジットを管理するデポジット管理手段を備え、
   前記支払確認手段は、前記デポジット管理手段の管理する前記預かり金から金銭を徴収して、徴収した金銭を前記利用者から取得された前記予約金として扱うことを特徴とする請求項１乃至３の何れか一つに記載の予約手続支援システム。
5. 前記利用者に対する前記サービスの提供によって発生した、追加徴収分の費用を徴収する追加徴収手段を備え、
   該追加徴収手段は、前記サービスの提供によって発生した請求額から前記予約金の金額を引いた金額を前記追加徴収分の費用として前記利用者に請求する処理を行うことを特徴とする請求項１乃至４の何れか一つに記載の予約手続支援システム。
6. 一又は複数の前記利用者からの預かり金としてのデポジットを管理するデポジット管理手段を備え、
   前記追加徴収手段は、前記デポジット管理手段が管理する前記デポジットから前記追加徴収分の費用を徴収することを特徴とする請求項５に記載の予約手続支援システム。
7. 前記利用者がクレジットカードでの支払を含む後払いで前記サービスの提供を受ける場合の、前記後払いの限度額を取得する処理としてのオーソリを行うオーソリ取得手段と、
   それぞれの前記利用者の前記オーソリと前記利用者に提供された前記サービスの対価としての請求額とを対比し前記利用者の支払の必要性を判定する判定手段とを備え、
   該判定手段は、前記利用者に対する前記請求額が前記オーソリの範囲内の場合は、前記サービスの対価についての前記後払いを許諾する処理を行うことを特徴とする請求項１乃至６の何れか一つに記載の予約手続支援システム。
8. コンピュータを請求項１乃至７の何れか一つに記載の予約手続支援システムとして機能させることを特徴とするプログラム。

Images