WO2017221467A1

WO2017221467A1 - サービスシステム、アプリケーションプログラム及び決済方法

Info

Publication number: WO2017221467A1
Application number: PCT/JP2017/007886
Authority: WO
Inventors: 仁博平嶋
Original assignee: 仁博平嶋
Priority date: 2016-06-20
Filing date: 2017-02-28
Publication date: 2017-12-28
Also published as: JP2017227945A; JP6120237B1

Abstract

店舗運営者が提供する商品又はサービスに関する情報が入力される店舗情報入力部Ｓ１１１と、顧客が要望する商品又はサービスに関する条件が入力される顧客条件入力部Ｓ１２１０，Ｓ４９１と、店舗情報入力部に入力された情報が、顧客条件入力部に入力された条件と合致する場合に、店舗情報入力部に入力された情報を顧客端末４０に送信する店舗情報送信部Ｓ１３２と、情報送信後の顧客端末４０における予約操作を受けて仮決済を実行する仮決済部Ｓ１４３と、仮決済を実行後の顧客端末４０における支払操作を受けて決済情報を算出しその決済情報を顧客端末４０に送信する決済情報送信部Ｓ１６１と、決済情報を送信後の顧客端末４０における店舗運営者による承認操作を受けて本決済を実行する本決済部Ｓ１６３とを有する。

Description

サービスシステム、アプリケーションプログラム及び決済方法

　この発明は、サービスシステム、アプリケーションプログラム及び決済方法に関する。

　ＪＰ２０１５－１５３４０３Ａは、予約支援システム、特に当日予約を支援するシステムについて開示する。このＪＰ２０１５－１５３４０３Ａによれば、このシステムは、電話番号を用いたユーザー認証を行うことで、いたずらでの予約を防止できるとしている。

　複数の店舗で予約し、その後キャンセルするモラルが低い顧客も少なからず存在する。このキャンセルが、予約時刻の直前である場合は、限られた商品又はサービスを顧客に提供したい店舗の提供機会を奪うこととなり、店舗側に損害が生じる。また顧客は、店舗の評価を気にすることも多いが、前述した従来のシステムでは、その点は何ら考慮されていない。

　本発明は、このような従来の問題点に着目したサービスシステム、アプリケーションプログラム及び決済方法を提供することである。

　本発明は以下のような解決手段によって前記課題を解決する。なお、理解を容易にするために明細書中に使用した符号を付するが、これに限定されるものではない。また符号を付して説明した構成は適宜代替しても改良してもよい。

　本発明のある態様のサービスシステムは、店舗運営者が提供する商品又はサービスに関する情報が入力される店舗情報入力部と、顧客が要望する商品又はサービスに関する条件が入力される顧客条件入力部と、前記店舗情報入力部に入力された情報が、前記顧客条件入力部に入力された条件と合致する場合に、前記店舗情報入力部に入力された情報を顧客端末に送信する店舗情報送信部と、前記情報送信後の前記顧客端末における予約操作を受けて仮決済を実行する仮決済部と、前記仮決済を実行後の前記顧客端末における支払操作を受けて決済情報を算出しその決済情報を前記顧客端末に送信する決済情報送信部と、前記決済情報を送信後の前記顧客端末における店舗運営者による承認操作を受けて本決済を実行する本決済部とを有する。

図１は、本発明に係るサービスシステムの概要機能について説明する図である。図２は、店舗情報入力処理を示すフローチャートである。図３は、初期登録処理を示すフローチャートである。図４は、配信条件設定処理を示すフローチャートである。図５は、情報配信処理を示すフローチャートである。図６は、予約可能な場合の予約処理を示すフローチャートである。図７は、予約不可な場合の予約処理を示すフローチャートである。図８は、クーポン発行処理を示すフローチャートである。図９は、支払処理を示すフローチャートである。図１０は、評価処理を示すフローチャートである。図１１は、キャンセルチャージ処理を示すフローチャートである。図１２は、評価表示処理を示すフローチャートである。図１３は、店舗を検索した場合の情報配信処理を示すフローチャートである。

　以下、添付図面を参照しながら本発明の実施形態について説明する。

　図１は、本発明に係るサービスシステムの概要機能について説明する図である。

　はじめに、図１を参照してサービスシステムの概要機能について説明する。

　図１に示すように、サービスシステム１は、サーバー１０と、店舗端末３０と、顧客端末４０とを含む。店舗端末３０及び顧客端末４０は、ネットワーク２０によってサーバー１０に接続され、通信プロトコル（たとえば、ＴＣＰ／ＩＰ）を介してデータを送受信可能になっている。なお、ネットワーク２０は、たとえば、インターネット、専用通信回線（たとえばＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、ゲートウェイ等によって構築されている。

　店舗端末３０は、店舗運営者が操作する機器である。店舗端末３０としては、たとえばパーソナルコンピューターやタブレット端末・スマートフォンなどを含む携帯通信端末，ＰＯＳ(Point Of Sales)システムなどを例示することができる。店舗運営者は、店舗端末３０を操作して、店舗運営者が提供する商品又はサービスに関する情報を入力する。この情報は、たとえば店舗が飲食店であれば、料理名・価格などであり、これに加えて写真があってもよい。また「今が旬！」といったコメントなどが加わってもよい。店舗がマッサージ店であれば、施術メニュー・価格・特別価格の場合の時間帯などであり、これに加えて店舗や施術者などの写真があってもよい。また店舗のコメントなどが加わってもよい。店舗が宿泊施設であれば、部屋タイプ・価格・特別価格の場合の宿泊日などであり、これに加えて部屋などの写真があってもよい。また店舗のコメントなどが加わってもよい。

　顧客端末４０は、顧客が操作する機器である。顧客端末４０としては、たとえば、スマートフォン・タブレット端末を含む携帯通信端末などを例示することができるが、パーソナルコンピューターであってもよい。顧客は、顧客端末４０を操作して、顧客が要望する商品又はサービスに関する条件を入力する。この条件は、たとえば店舗が飲食店であれば、東京駅周辺・虎ノ門といった料理の提供エリア／現在地から店舗までの距離又は所要時間／予算／和食洋食などのジャンル／情報配信希望時刻などである。店舗がマッサージ店であれば、エリア／現在地から店舗までの距離又は所要時間／提供価格／情報配信希望日などである。店舗が宿泊施設であれば、エリア／部屋タイプ／価格／情報配信希望日などである。

　続いて、サービスシステム１の具体的なロジックについて、フローチャートを参照して説明する。なおここでは発明の理解を容易にするために、店舗が飲食店である場合を挙げて説明する。

　図２は、店舗情報入力処理を示すフローチャートである。

　ステップＳ３１１において、店舗端末３０のＣＰＵ（以下適宜「店舗端末ＣＰＵ」と称す）は、店舗端末３０の画面にデフォルト店舗情報を表示する。デフォルト店舗情報とは、たとえば、通常変更しない定番メニューや予約をキャンセルした場合に課金される料金などである。キャンセル料金は、予約金額の全額や２０％などであり、店舗運営者が自由に設定可能である。また詳細は省略するが、必要であれば店舗運営者がデフォルト店舗情報を変更することも可能である。店舗運営者がデフォルト店舗情報を変更した場合、店舗端末ＣＰＵは、その情報をサーバー１０に送信する。

　ステップＳ３１２において、店舗端末ＣＰＵは、追加店舗情報が有るか否かを判定し、判定結果が肯であればステップＳ３１３に処理を移行し、否であればステップＳ３１３をスキップする。

　ステップＳ３１３において、店舗端末ＣＰＵは、追加情報入力画面を表示する。追加店舗情報について一例を挙げれば、時間帯（ランチ）／料理名（鰹のたたき丼）／価格（８００円税込）／提供数（１０食）／コメント（今が旬！市場で安く仕入れたので今日だけ特別価格でご提供！）／写真などである。店舗端末ＣＰＵは、店舗運営者が入力した店舗情報をサーバー１０に送信する。

　サーバー１０のＣＰＵ（以下適宜「サーバーＣＰＵ」と称す）は、ステップＳ１１１において、店舗端末３０から受信した情報を店舗情報ＤＢに格納・更新する。

　図３は、初期登録処理を示すフローチャートである。

　ステップＳ４１１において、顧客端末４０のＣＰＵ（以下適宜「顧客端末ＣＰＵ」と称す）は、顧客端末４０の画面に会員登録画面を表示する。顧客が、氏名等の会員情報やクレジットカード情報などを入力して登録したら、顧客端末ＣＰＵは、顧客の登録情報をサーバー１０に送信する。

　サーバーＣＰＵは、ステップＳ１２１において、顧客端末４０から受信した情報を会員情報ＤＢに格納・更新する。

　図４は、配信条件設定処理を示すフローチャートである。

　ステップＳ４２１において、顧客端末ＣＰＵは、顧客端末４０の画面に、設定画面を表示する。この画面に従って、顧客が、提供エリア（東京駅）あるいは現在地から店舗までの距離（５００ｍ）又は所要時間（１０分）／ジャンル（和食ランチ）／予算・価格帯（８００～１０００円）／情報配信条件（時刻１１：４５に配信又は店舗から所定の距離のエリアに入ったら配信）等を入力したら、顧客端末ＣＰＵは、顧客が設定した配信条件の情報をサーバー１０に送信する。

　サーバーＣＰＵは、ステップＳ１２１０において、顧客端末４０から受信した情報を会員情報ＤＢに格納・更新する。

　図５は、情報配信処理を示すフローチャートである。

　ステップＳ１３１において、サーバーＣＰＵは、顧客の配信条件に合致する店舗情報が有るか否かを判定し、判定結果が肯であればステップＳ１３２に処理を移行し、否であればステップＳ１３２をスキップする。

　ステップＳ１３２において、サーバーＣＰＵは、顧客が設定した配信条件で店舗情報を配信する。配信される情報について一例を挙げれば、店舗名（○×食堂）／料理名（鰹のたたき丼）／写真があれば写真／価格（８００円税込）／提供可能数（あと８食）／その他店のコメント（今が旬！市場で安く仕入れたので今日だけ特別価格でご提供！）などである。

　この配信情報を受けて、ステップＳ４３１において、顧客端末ＣＰＵは、顧客端末４０の画面に、この情報を表示する。なおこの表示は、アプリのポップアップ表示やプッシュ通知であってもよいし、電子メールであってもよい。顧客はこれらの情報を確認して予約を希望すれば予約ボタンを押す。すると予約処理が開始される。

　図６は、予約可能な場合の予約処理を示すフローチャートである。

　ステップＳ４４１において、顧客端末ＣＰＵは、顧客端末４０の画面に、予約希望時間帯及び予約人数のプルダウンメニューを表示する。顧客が顧客端末４０を操作して予約希望時間帯（１２：００～１２：３０）／人数（４人）を選択したら、顧客端末ＣＰＵは、この情報をサーバー１０に送信する。

　この条件で予約可能な場合は（ステップＳ１４１）、ステップＳ１４２において、サーバーＣＰＵは、予約情報を送信する。

　この情報を受けて、ステップＳ４４２において、顧客端末ＣＰＵは、顧客端末４０の画面に、予約確認情報（４名（離れた２人席を２つ）／鰹のたたき丼４食／金額３，２００円）を表示する。なおこの予約確認情報とともにキャンセルした場合に課金される金額などの注意書きも明示される。顧客が、これらの情報を確認して予約確定ボタンを押したら、顧客端末ＣＰＵは、その情報をサーバー１０に送信する。

　この情報を受けて、サーバーＣＰＵは、ステップＳ１４３において、登録してあるクレジットカードの仮決済を実行するとともに、ステップＳ１４４において、料理の残り数を更新する。

　図７は、予約不可な場合の予約処理を示すフローチャートである。

　この条件で予約不可な場合は（ステップＳ１４１１）、ステップＳ１４１２において、サーバーＣＰＵは、代替条件が有るか否かを判定し、判定結果が肯であればステップＳ１４１３に処理を移行し、否であればそれ以降のステップをスキップする。

　ステップＳ１４１３において、サーバーＣＰＵは、代替条件を送信する。

　この情報を受けて、ステップＳ４４１１において、顧客端末ＣＰＵは、顧客端末４０の画面に、メッセージ（たとえば「２人席を２つならご用意できます」）を表示する。

　ステップＳ４４１２において、顧客端末ＣＰＵは、顧客が予約するか（予約ボタンを押すか）否かを判定し、判定結果が肯であればステップＳ４４２に処理を移行し、否であればステップＳ４４２をスキップする。

　ステップＳ４４２において、顧客端末ＣＰＵは、顧客端末４０の画面に、予約確認情報（４名（離れた２人席を２つ）／鰹のたたき丼４食／金額３，２００円）を表示する。なおこの予約確認情報とともにキャンセルした場合に課金される金額などの注意書きも明示される。顧客が、これらの情報を確認して予約確定ボタンを押したら、顧客端末ＣＰＵは、その情報をサーバー１０に送信する。

　図８は、クーポン発行処理を示すフローチャートである。

　ステップＳ４５１において、顧客端末ＣＰＵは、顧客端末４０の画面に、メッセージ（お料理写真の投稿でクーポンゲット！）をポップアップ表示する。これは、たとえば予約してある時刻になったタイミングで表示すればよい。

　ステップＳ４５２において、顧客端末ＣＰＵは、写真が投稿されたか否かを判定し、判定結果が肯であればステップＳ４５３に処理を移行し、否であればそれ以降のステップをスキップする。

　ステップＳ４５３において、顧客端末ＣＰＵは、投稿された写真の情報をサーバー１０に送信する。

　この情報を受けて、サーバーＣＰＵは、ステップＳ１５１において、受信した写真の情報を店舗情報に追加するとともに、ステップＳ１５２において、投稿時刻に応じたクーポンを発行する。たとえば投稿時刻が早いほど、その投稿写真を見る人が多く有用であると考えられる。そこで、サーバーＣＰＵは値引き金額の高いクーポンを発行する。投稿時刻が遅ければ、その投稿写真を見る人が少ないと考えられる。そこで、サーバーＣＰＵは値引き金額の低いクーポンを発行する。

　この情報を受けて、ステップＳ４５４において、顧客端末ＣＰＵは、顧客端末４０の画面に、発行されたクーポンの情報を表示する。

　図９は、支払処理を示すフローチャートである。

　顧客が顧客端末４０を操作すると、ステップＳ４６１において、顧客端末ＣＰＵは、顧客端末４０に支払情報の入力画面を表示する。顧客が、クレジットカード払いする料理及び人数を入力すると、顧客端末ＣＰＵは、この情報をサーバー１０に送信する。

　この情報を受けて、ステップＳ１６１において、サーバーＣＰＵは、金額を算出する。クーポンが発行されていれば、クーポンの値引きを反映させて金額を算出する。サーバーＣＰＵは、この情報を顧客端末４０に送信する。

　この情報を受けて、ステップＳ４６２において、顧客端末ＣＰＵは、金額を表示する。

　顧客が金額を確認して支払いボタンを押したら、ステップＳ４６３において、顧客端末ＣＰＵは、顧客端末４０に、承認パスワードの入力画面を表示する。この承認パスワードは、店舗運営者が顧客の支払金額を承認して入力するものである。店舗運営者が承認パスワードを入力してスワイプしたら、その情報がサーバー１０に送信される。

　この情報を受けて、ステップＳ１６２において、サーバーＣＰＵは、登録してあるクレジットカードの本決済を実行する。

　なお、ここで決済されなかった代金は、従来通り、各人が店舗運営者に現金や電子マネーなどで支払う。またステップＳ４６１において、顧客が、クレジットカード払いする人数をゼロと入力した場合は、店舗運営者が承認した後、その顧客が現金や電子マネーなどで支払うことが可能である。

　図１０は、評価処理を示すフローチャートである。

　登録してあるクレジットカードの本決済が完了すると、評価処理が実行される。

　ステップＳ４７１において、顧客端末ＣＰＵは、顧客端末４０に評価画面を表示する。顧客が、評価を入力したら、顧客端末ＣＰＵは、この情報をサーバー１０に送信する。なお顧客が評価を行うことなく、アプリを終了したり、画面を切り替えた場合には、それ以降のステップをスキップする。

　顧客の評価情報を受けて、サーバーＣＰＵは、ステップＳ１７１において評価情報を蓄積するとともに、ステップＳ１７２においておすすめ情報を送信する。このおすすめ情報は、顧客が設定した配信条件に基づくものであってもよいし、顧客が食事をした店舗の運営者が店舗情報の一環として入力したものであってもよい。

　この情報を受けて、ステップＳ４７２において、顧客端末ＣＰＵは、顧客端末４０におすすめ情報を表示する。

　ステップＳ４７３において、顧客端末ＣＰＵは、顧客がこのおすすめ情報をお気に入りリストに入れる操作をしたか否かを判定し、判定結果が肯であればステップＳ４７４に処理を移行し、否であればステップＳ４７４をスキップする。

　ステップＳ４７４において、顧客端末ＣＰＵは、顧客端末４０のお気に入りリストを更新する。

　図１１は、キャンセルチャージ処理を示すフローチャートである。

　ステップＳ１８１において、サーバーＣＰＵは、予約してある時刻から所定時間が経過しても登録してあるクレジットカードの本決済が完了していないか否かを判定し、判定結果が肯であればステップＳ１８２に処理を移行し、否であればステップＳ１８２をスキップする。

　ステップＳ１８２において、サーバーＣＰＵは、仮決済された金額のうちキャンセルチャージ分の本決済を実行する。

　図１２は、評価表示処理を示すフローチャートである。

　ステップＳ４８１において、顧客端末ＣＰＵは、顧客が顧客端末４０を操作して評価を表示させる場合は、ステップＳ４８２に処理を移行し、ステップＳ４８２において、この情報をサーバー１０に送信する。

　この情報を受けて、ステップＳ１９１において、サーバーＣＰＵは、評価情報を顧客端末４０に送信する。

　この情報を受けて、ステップＳ４８３において、顧客端末ＣＰＵは、評価情報を表示する。評価情報は、所定期間毎（たとえば１月毎）の推移（変化）が分かるようにグラフ表示される。顧客は、これを見ることで、ここ最近評価がどのように変化したのかを容易に把握することができる。たとえば飲食店であれば、シェフが変わることで味付けが大幅に変わることがある。また給仕人が変わることで、サービスが大幅に変わることもある。グラフ表示にすることで、そのような最近の変化を容易に把握できるようになり、顧客の店舗選択の指針とすることができる。

　図１３は、店舗を検索した場合の情報配信処理を示すフローチャートである。

　上記説明においては、図５に示されているように、店舗情報が、予め設定されている顧客の配信条件に合致する場合に、店舗情報を配信し、この配信情報を受けて、顧客端末４０の画面に、この情報を表示するようにしている。しかしながら、顧客が配信情報設定していない場合もある。また配信情報から外れた地域に出張して店舗を探したい場合もある。このような場合は、以下のように処理される。

　ステップＳ４９１において、顧客端末ＣＰＵは、顧客端末４０が顧客によって操作されて検索条件が入力されたら、その情報をサーバー１０に送信する。

　ステップＳ１３１において、サーバーＣＰＵは、顧客の検索条件に合致する店舗情報が有るか否かを判定し、判定結果が肯であればステップＳ１３２に処理を移行し、否であればステップＳ１３２をスキップする。

　ステップＳ１３２において、サーバーＣＰＵは、顧客端末４０に店舗情報を送信する。送信される情報について一例を挙げれば、店舗名（○×食堂）／料理名（鰹のたたき丼）／写真があれば写真／価格（８００円税込）／提供可能数（あと８食）／その他店のコメント（今が旬！市場で安く仕入れたので今日だけ特別価格でご提供！）などである。

　この送信情報を受けて、ステップＳ４９２において、顧客端末ＣＰＵは、顧客端末４０の画面に、この情報を表示する。顧客はこの情報を確認して予約を希望すれば予約ボタンを押す。すると予約処理が開始される。

　以上説明した本実施形態によれば、顧客端末４０における予約操作を受けて仮決済を実行し、仮決済の実行後、顧客端末４０における支払操作を受けて決済情報を算出し、顧客端末４０に表示された決済情報を確認した店舗運営者が、顧客端末４０を操作して承認することで、本決済を実行するようにした。このようにしたので、予約時点で仮決済を実行するので、低モラルな顧客を排除することができる。また店舗運営者が顧客端末４０の情報読取装置などを用意する必要がなく、全体としてコストが安価なシステムを提供することができる。

　店舗運営者の承認操作は、たとえば、顧客端末４０における支払操作を受けて生成されて店舗端末３０に表示されたワンタイムパスワードを入力することである。このようにするので、セキュアなシステムを低コストで提供することができる。

　顧客が予約した時点で、登録してあるクレジットカードの仮決済を実行し、予約してある時刻から所定時間が経過しても本決済が実行されない場合には、キャンセルチャージ分の本決済を実行するようにした。このようにしたので、いたずらでの予約を防止できるとともに、予約が成立したにもかかわらずキャンセルされた場合の店舗側の損害を低く抑えることができる。

　顧客端末４０から写真が投稿された場合に、クーポンを発行するので、顧客の写真投稿が活発化する。そして投稿された写真を店舗運営者が提供する商品又はサービスに関する情報に追加して店舗情報として活用できる。そのため他の顧客の興味を刺激することができる。

　クーポンは、写真が投稿されたタイミングに応じたものである。たとえば、飲食店の場合は、朝の市場での仕入れ状況によって、その日の特別ランチを提供することがある。このような場合に、ランチのピークタイムの開始時刻（たとえば１２：００）よりも前に投稿された特別ランチの情報は、ランチの店舗を探している顧客が多いので非常に有用であり、価値が高い。一方、ランチのピークタイムが過ぎてから投稿された特別ランチの情報は、ランチの店舗を探している顧客が少ないので、価値が低い。このように情報には、いわば賞味期限があると言える。そこで写真が投稿されたタイミングによってクーポンを変更することで、早いタイミングでの価値の高い投稿を促すインセンティブとなる。また店舗側としても、価値が低い情報に無用なクーポンを発行してしまうことを回避でき、ひいては利益率の向上につながる。

　本決済実行後に顧客端末における評価操作を受けつけるようにした。本決済がクレジットカード決済であれば、クレジットカードによって個人が特定されているので、無責任な評価を防止でき、いわゆる評価あらしを排除することができる。

　評価結果は、所定期間毎（たとえば１月毎）の推移（変化）が分かるようにグラフ表示される。顧客は、これを見ることで、ここ最近評価がどのように変化したのかを容易に把握することができる。たとえば飲食店であれば、シェフが変わることで味付けが大幅に変わることがある。また給仕人が変わることで、サービスが大幅に変わることもある。グラフ表示にすることで、そのような最近の変化を容易に把握できるようになり、顧客の店舗選択の指針とすることができる。

　以上、本発明の実施形態について説明したが、上記実施形態は本発明の適用例の一部を示したに過ぎず、本発明の技術的範囲を上記実施形態の具体的構成に限定する趣旨ではない。

　上記説明においては、店舗として特に飲食店を挙げて説明したが、これには限られない。本発明によるサービスシステムはさまざまな業態に使用することができる。たとえばマッサージ店やホテルである。マッサージ店であればこのシステムを使用して顧客が少ない場合に特別タイム（サービス提供時間）の情報を配信することで、集客につなげることができる。またホテルであればこのシステムを使用して当日キャンセルが出た場合に今現在の特別料金情報を配信することで、集客につなげることができる。

　なお上記実施形態は、適宜組み合わせ可能である。また一部を抜き出して実行してもよい。

　本願は、２０１６年６月２０日に日本国特許庁に出願された特願２０１６－１２１３６５に基づく優先権を主張し、この出願の全ての内容は参照によって本明細書に組み込まれる。

Claims

　店舗運営者が提供する商品又はサービスに関する情報が入力される店舗情報入力部と、
　顧客が要望する商品又はサービスに関する条件が入力される顧客条件入力部と、
　前記店舗情報入力部に入力された情報が、前記顧客条件入力部に入力された条件と合致する場合に、前記店舗情報入力部に入力された情報を顧客端末に送信する店舗情報送信部と、
　前記情報送信後の前記顧客端末における予約操作を受けて仮決済を実行する仮決済部と、
　前記仮決済を実行後の前記顧客端末における支払操作を受けて決済情報を算出しその決済情報を前記顧客端末に送信する決済情報送信部と、
　前記決済情報を送信後の前記顧客端末における店舗運営者による承認操作を受けて本決済を実行する本決済部と、
を有するサービスシステム。
　請求項１に記載のサービスシステムにおいて、
　前記仮決済を実行後の前記顧客端末における支払操作を受けてワンタイムパスワードを生成し、そのワンタイムパスワードを店舗端末に送信するパスワード送信部を有し、
　前記本決済部は、前記決済情報を送信後の前記顧客端末への前記ワンタイムパスワード入力操作を受けて本決済を実行する、
を有するサービスシステム。
　請求項１又は請求項２に記載のサービスシステムにおいて、
　前記仮決済を実行後に予約してある時刻から所定の時間が経過しても本決済が実行されない場合に、キャンセルチャージ分の本決済を実行するキャンセルチャージ実行部を有する、
サービスシステム。
　請求項１から請求項３までのいずれか１項に記載のサービスシステムにおいて、
　前記顧客端末から写真情報を受信した場合に、クーポンを発行するクーポン発行部を有する、
サービスシステム。
　請求項４に記載のサービスシステムにおいて、
　前記クーポン発行部は、写真情報を受信したタイミングに応じたクーポンを発行する、
サービスシステム。
　請求項４又は請求項５に記載のサービスシステムにおいて、
　前記顧客端末から写真情報を受信した場合に、その写真情報を前記店舗運営者が提供する商品又はサービスに関する情報に追加する情報追加部を有する、
サービスシステム。
　請求項１から請求項６までのいずれか１項に記載のサービスシステムにおいて、
　前記本決済実行後の前記顧客端末における評価操作を受けて、その評価情報を蓄積する評価蓄積部と、
　前記蓄積された評価情報を前記顧客端末に送信して、所定期間毎の変化が分かるように、前記顧客端末の画面にグラフ表示させる評価送信部と、
を有するサービスシステム。
　請求項１から請求項７までのいずれか１項に記載のサービスシステムにおいて、
　前記店舗運営者が提供する商品又はサービスに関する情報は、料理に関する情報を含み、
　前記顧客が要望する商品又はサービスに関する条件は、少なくとも料理の提供エリア又は提供価格に関する条件を含む、
サービスシステム。
　請求項１から請求項７までのいずれか１項に記載のサービスシステムにおいて、
　前記店舗運営者が提供する商品又はサービスに関する情報は、マッサージに関する情報を含み、
　前記顧客が要望する商品又はサービスに関する条件は、少なくともマッサージの提供エリア又は提供時間に関する条件を含む、
サービスシステム。
　請求項１から請求項７までのいずれか１項に記載のサービスシステムにおいて、
　前記店舗運営者が提供する商品又はサービスに関する情報は、宿泊施設に関する情報を含み、
　前記顧客が要望する商品又はサービスに関する条件は、少なくとも宿泊施設の提供エリア又は提供日時に関する条件を含む、
サービスシステム。
　請求項１から請求項７までのいずれか１項に記載のサービスシステムにおいて、
　前記情報送信後の前記顧客端末における予約希望条件の入力操作を受けて、その予約希望条件が成立しない場合に、代替条件を顧客端末に送信する代替条件送信部を有する、
サービスシステム。
　請求項１１に記載のサービスシステムにおいて、
　前記店舗運営者が提供する商品又はサービスに関する情報は、料理に関する情報を含み、
　前記顧客が要望する商品又はサービスに関する条件は、少なくとも料理の提供エリア又は提供価格に関する条件を含み、
　前記予約希望条件は、料理の提供時間及び席数に関する条件を含み、
　前記代替条件は、座席に関する条件又は料理の提供時間に関する条件を含む、
サービスシステム。
　請求項１から請求項１２までのいずれか１項に記載のサービスシステムと情報を授受する顧客端末に組み込まれるアプリケーションプログラムにおいて、
　前記店舗情報送信部から送信された情報を受信して前記顧客端末に表示するステップと、
　前記顧客端末に前記情報を表示した後、その顧客端末に入力された予約情報を送信するステップと、
　前記仮決済部における仮決算の実行後に、前記顧客端末に入力された支払情報を送信するステップと、
　前記決済情報送信部から送信された決済情報を受信して前記顧客端末に表示するステップと、
　前記顧客端末に前記決済情報を表示した後、その顧客端末に入力された承認パスワード情報を送信するステップと、
を有するアプリケーションプログラム。
　請求項１から請求項１２までのいずれか１項に記載のサービスシステムと情報を授受する店舗端末に組み込まれるアプリケーションプログラムにおいて、
　前記仮決済を実行後の前記顧客端末における支払操作を受けてワンタイムパスワードを生成し、そのワンタイムパスワードを店舗端末に送信するパスワード送信部から送信されたワンタイムパスワードを受信して前記店舗端末に表示するステップを有する、
アプリケーションプログラム。
　店舗運営者が提供する商品又はサービスに関する情報が入力される店舗情報入力工程と、
　顧客が要望する商品又はサービスに関する条件が入力される顧客条件入力工程と、
　前記店舗情報入力工程で入力された情報が、前記顧客条件入力工程で入力された条件と合致する場合に、前記店舗情報入力工程で入力された情報を顧客端末に送信する情報送信工程と、
　前記情報送信後の前記顧客端末における予約操作を受けて仮決済を実行する仮決済工程と、
　前記仮決済を実行後の前記顧客端末における支払操作を受けて決済情報を算出しその決済情報を前記顧客端末に送信する送信工程と、
　前記決済情報を送信後の前記顧客端末における店舗運営者による承認操作を受けて本決済を実行する本決済工程と、
を有する決済方法。