JP2023092648A - 店舗予約システム - Google Patents

Abstract

【課題】大人数での予約を行う際であってもユーザの店舗の選択肢を狭くすることなく、店舗側も利益を得る機会を失うこととのない店舗予約システムを提供する。【解決手段】ユーザが店舗の利用の予約を行う場合において、予約対象となる利用人数を取得し、予約の候補となる候補店舗の混雑状況を取得し、利用人数と候補店舗の混雑状況とを考慮して複数の候補店舗を対象として利用人数を振り分けるとともに振り分けた結果で予約を行うことをユーザに提案するように構成する。【選択図】図１３

Description

本発明は、店舗の利用の予約を行う店舗予約システムに関する。

従来より、例えば飲食店、カラオケ、スポーツジム、美容院等の店舗をユーザが訪れて利用する場合において、事前に電話やインターネットを用いて店舗の利用の予約をすることが行われている。また、特に飲食店やカラオケ店などの一部のジャンルの店舗については、大人数での利用を行う場合があるが、そのような場合において大人数の利用客を受け入れ可能な店舗は一部の大型の店舗に限られるため、ユーザが店舗の予約を行う場合に店舗の選択肢が狭くなる問題がある。また、店舗側としても大人数の利用客の受け入れができないことによって利益を得る機会を失うこととなる。

そこで例えば特開２０２０－６４３４５号公報には、一つのテーブルで大人数の利用客の受け入れが難しい小型の店舗において、利用客を連席となる複数のテーブルに振り分けて予約を受け付けることによって大人数での予約に対応することを可能にした技術について開示されている。

特開２０２０－６４３４５号公報（段落００２３－００３５）

しかしながら、上記特許文献１の技術は基本的に同じ店舗内での利用客の振り分けに限られていた。従って、利用客の人数に対してそもそも座席数が不足する店舗については利用客を受け入れることができなかった。

ところで近年ではスマートフォンやタブレット端末が普及するとともにそれらの通信端末を使ってオンラインで映像や音声を共有し、コミュニケーションをとる為のアプリケーションも普及している。そのようなアプリケーションを使用すれば仮に場所が離れていたとしても同じ空気間を共有できる。従って、大人数の利用客が複数の店舗へと分かれて利用することに対する弊害は少ないと予想される。

本発明は前記従来における問題点を解消するためになされたものであり、異なる複数の店舗間で利用客を振り分けて予約を行うことを提案することによって、大人数での予約を行う際であってもユーザの店舗の選択肢を狭くすることなく、店舗側も利益を得る機会を失うこととのない店舗予約システムを提供することを目的とする。

前記目的を達成するため本発明に係る店舗予約システムは、ユーザが店舗の利用の予約を行う場合において、予約対象となる利用人数を取得する人数取得手段と、予約の候補となる店舗を検索する店舗検索手段と、前記店舗検索手段により検索された店舗である候補店舗の混雑状況を取得する混雑状況取得手段と、前記利用人数と前記候補店舗の混雑状況とを考慮して複数の候補店舗を対象として利用人数を振り分けるとともに振り分けた結果で予約を行うことをユーザに提案する予約提案手段と、を有する。

前記構成を有する本発明に係る店舗予約システムによれば、利用人数と予約の候補となる候補店舗の混雑状況とを考慮して複数の候補店舗を対象として利用人数を振り分けるとともに振り分けた結果で予約を行うことをユーザに提案するので、異なる複数の店舗間で利用客を振り分けて予約を受け付けることが可能となる。それによって、大人数での予約を行う際であってもユーザの店舗の選択肢を狭くすることなく、店舗側も利益を得る機会を失うことがない。

本実施形態に係る店舗予約システムを示した概略構成図である。 本実施形態に係る店舗予約システムの構成を示したブロック図である。 予約ＤＢに記憶される予約情報の一例を示した図である。 店舗管理ＤＢに記憶される店舗管理情報の一例を示した図である。 本実施形態に係る通信端末の制御系を模式的に示すブロック図である。 本実施形態に係る予約管理処理プログラムのフローチャートである。 通信端末のディスプレイに対して表示される希望条件入力画面を示した図である。 通信端末のディスプレイに対して表示される店舗案内画面を示した図である。 通信端末のディスプレイに対して表示される振り分け店舗案内画面を示した図である。 通信端末のディスプレイに対して表示される予約画面を示した図である。 通信端末のディスプレイに対して表示される予約画面を示した図である。 店舗の混雑状況を予測する方法について説明した図である。 利用客の振り分け方法について説明した図である。

以下、本発明に係る店舗予約システムについて具体化した一実施形態に基づき図面を参照しつつ詳細に説明する。先ず、本実施形態に係る店舗予約システム１の概略構成について図１を用いて説明する。図１は本実施形態に係る店舗予約システム１を示した概略構成図である。

図１に示すように、本実施形態に係る店舗予約システム１は、利用の予約を行うことが可能な複数の店舗２が有する予約管理サーバ（予約管理装置）３と、ユーザ４が所持する通信端末５と、を基本的に有する。また、予約管理サーバ３と通信端末５は通信ネットワーク網６を介して互いに電子データを送受信可能に構成されている。尚、通信端末５としては例えば携帯電話機、スマートフォン、タブレット型端末、パーソナルコンピュータ、車載器であるナビゲーション装置等がある。また、以下の説明ではユーザ４が店舗２へ移動する場合には車両で移動することを前提とするが、車両以外の移動手段で移動しても良いし、徒歩で移動しても良い。

ここで、予約管理サーバ３は、店舗予約システム１における情報の管理や提供を行うサーバ装置である。予約管理サーバ３は、ユーザ４が利用の予約を行うことが可能な複数の店舗２に対して設置される。この複数の店舗２は後述のようにユーザから複数人で利用する予約があった場合に利用客を互いに振り分ける提携関係にある。例えば同じ親会社によって経営される店舗であっても良いし、同じ商店街に属する店舗であっても良い。尚、予約管理サーバ３は複数の店舗２のそれぞれに設置されていても良いし、代表の店舗２のみに設置されても良いし、店舗２と異なる第三者が管理する外部のサーバとして存在しても良い。その場合には予約管理サーバ３は通信ネットワーク網６を介して各店舗２から必要な情報を適宜取得したり配信する。

また、店舗２はユーザ４により利用の予約を行うことが可能な店舗とするが、“ユーザによる利用”とは、店舗で商品を売買すること、店舗で提供された商品を店舗内で消費（例えば飲食）すること、店舗でサービス（例えば散髪、マッサージ）の提供を受けること、店舗が備える設備を利用すること等が該当する。従って、“ユーザ４が利用の予約を行うことが可能な店舗２”としては、それらの利用を事前に予約して行うことが可能な店舗であり、例えばレストランなどの飲食店、スポーツジム、映画館、カラオケ店、マッサージ店等が該当する。但し、本実施形態では特に複数人での利用が行われる店舗とし、飲食店、カラオケ店などが該当する。

また、本実施形態ではユーザ４による店舗２の利用の予約は通信端末５を用いてオンラインで行うこととする。但し、店舗２は予約による利用のみが可能な店舗に限定されるものではなく、予約による利用に加えて予約を行わない利用が可能な店舗についても含む。

そして、予約管理サーバ３は、ユーザ４が店舗２の利用の予約を希望する場合において、ユーザの希望する条件に合った予約内容を提案する。特にユーザ４が利用人数を複数人とした場合であって、一の店舗２で予約が実行できない場合については、複数の店舗２に対して利用人数を振り分けて予約を行うことを提案する。更に予約内容の提案を受けたユーザ４が通信端末５を介して上記店舗２に対する利用の予約を行った場合には、行われた予約の内容をＤＢで管理するとともに、ユーザから予約があったこと並びに予約の内容を店舗２の従業員に提供する。詳細については後述する。

一方、通信端末５は、ユーザ４が所持し、ウェブサーバに接続する機能やナビ機能等を備えた情報端末が用いられ、例えば携帯電話機、スマートフォン、タブレット型端末、パーソナルコンピュータ、ナビゲーション装置等が該当する。特に通信端末５がスマートフォン等のアプリケーションを実行可能な端末である場合には、アプリケーションの一つとして利用の予約が可能な店舗２に対してオンラインで予約を行うことが可能となるアプリケーションプログラムがインストールされている。尚、これらの店舗２に対してオンラインで予約を行う機能は、目的地までの移動案内を行うナビ機能の一部としても良いし、ナビ機能とは異なるアプリケーションプログラムにより実行されても良い。

また、通信ネットワーク網６は全国各地に配置された多数の基地局と、各基地局を管理及び制御する通信会社とを含み、基地局及び通信会社を有線（光ファイバー、ＩＳＤＮ等）又は無線で互いに接続することにより構成されている。ここで、基地局は通信端末５との通信をするトランシーバー（送受信機）とアンテナを有する。そして、基地局は通信会社の間で無線通信を行う一方、通信ネットワーク網６の末端となり、基地局の電波が届く範囲（セル）にある通信端末５の通信を予約管理サーバ３との間で中継する役割を持つ。

続いて、店舗予約システム１における予約管理サーバ３の構成について図２を用いてより詳細に説明する。尚、以下の実施例では特に予約管理サーバ３の設置された店舗２は、店舗Ａ～店舗Ｃの３店舗であって、いずれも食事の提供を行う飲食店であって、ユーザによる食事の予約が可能な店舗である場合を例に挙げて説明する。

予約管理サーバ３は、図２に示すようにサーバ制御部１１と、サーバ制御部１１に接続された情報記録手段としての予約ＤＢ１２と、店舗管理ＤＢ１３と、地図情報ＤＢ１４と、商品管理ＤＢ１５と、サーバ側通信装置１７とを備える。

サーバ制御部１１は、予約管理サーバ３の全体の制御を行う制御ユニット（ＭＣＵ、ＭＰＵ等）であり、演算装置及び制御装置としてのＣＰＵ２１、並びにＣＰＵ２１が各種の演算処理を行うにあたってワーキングメモリとして使用されるＲＡＭ２２、制御用のプログラムのほか、後述の予約管理処理プログラム（図６）等が記録されたＲＯＭ２３、ＲＯＭ２３から読み出したプログラムを記憶するフラッシュメモリ２４等の内部記憶装置を備えている。尚、サーバ制御部１１は、後述の通信端末５の制御部とともに処理アルゴリズムとしての各種手段を有する。例えば、人数取得手段は、ユーザが店舗の利用の予約を行う場合において、予約対象となる利用人数を取得する。店舗検索手段は、予約の候補となる店舗を検索する。混雑状況取得手段は、店舗検索手段により検索された店舗である候補店舗の混雑状況を取得する。予約提案手段は、利用人数と候補店舗の混雑状況とを考慮して複数の候補店舗を対象として利用人数を振り分けるとともに振り分けた結果で予約を行うことをユーザに提案する。

また、予約ＤＢ１２は、本予約管理サーバ３の設置された各店舗２（店舗Ａ～Ｃ）に対してユーザ４から利用の予約があった場合に、予約の内容を記録する記憶手段である。具体的には、予約者の情報（氏名、ＩＤ、電話番号など）、予約の日時（来店予定日時）、予約の人数等が記憶される。尚、予約の内容（予約メニュー）等についても記憶するようにしても良い。尚、本実施形態ではユーザ４が通信端末５を用いて注文を行うことを前提としており、ユーザ４が通信端末５においてオンライン予約を行う為の所定のアプリケーションプログラムを起動し、予約操作を行うことによって、ユーザによって入力された各情報が予約管理サーバ３へと送信され、現在の時刻（予約受付時刻）とともに予約ＤＢ１２に格納される。また、予約ＤＢ１２に格納された各情報は予約された店舗２内に設けられたディスプレイ等を介して店舗２の従業員に対して提供される。例えば図３は予約ＤＢ１２に記憶される予約情報の一例を示した図である。

図３に示す例では店舗Ａには『ＩＤ：１０００２』のユーザ４によって２０２１年の１２月２１日の１８時に４人の利用で予約があり、『ＩＤ：２０００１』のユーザ４によって２０２１年の１２月２１日の１８時半に６人の利用で予約があり、『ＩＤ：２０２２１』のユーザ４によって２０２１年の１２月２１日の１８時半に３人の利用で予約があることを示している。同様に他の店舗Ｂ、Ｃの予約情報についても記憶されている。

一方、店舗管理ＤＢ１３は、現時点における本予約管理サーバ３の設置された各店舗２（店舗Ａ～Ｃ）の混雑状況を管理するＤＢである。具体的には、現時点における各店舗２内の空き座席の数を夫々記憶する。尚、空き座席についてはテーブル単位で管理するのが望ましい。また、座席やテーブルの配置を特定する情報についても記憶するのが望ましい。例えば図４は店舗管理ＤＢ１３に記憶される店舗管理情報の一例を示した図である。

図４に示す例では例えば店舗Ａには現時点（２０２１年の１２月２１日の１７時時点）において、４名用のテーブル席が５つと、６名用のテーブル席が３つと、８名用のテーブル席が２つ空き状態にあることを示している。同様に他の店舗Ｂ、Ｃの店舗管理情報についても記憶されている。尚、店舗の混雑状況については、具体的な空き座席の数以外に座席の利用率で特定しても良い。例えば座席の利用率５０％未満を『空き』、５０％以上８０％未満を『やや混』、８０％以上を『混雑』として特定しても良い。また、現時点の混雑状況だけではなく将来的な店舗の混雑状況が予測できるのであれば、将来的な混雑状況も店舗管理ＤＢ１３で管理するようにしても良い。

そして、上述の予約ＤＢ１２に記憶された予約情報や店舗管理ＤＢ１３に記憶された店舗管理情報は、後述のように予約を行おうとするユーザ４がある場合に、ユーザ４の指定した利用人数の受け入れができるか否かの判断、及びユーザ４の指定した利用人数の受け入れができない場合については利用人数の振り分けの提案を行う為に用いられる。

また、地図情報ＤＢ１４は、地図情報が記憶される記憶手段である。地図情報は、道路網を始めとして経路探索、経路案内及び地図表示に必要な各種情報から構成されている。例えば、道路（リンク）に関するリンクデータ、ノード点に関するノードデータ、各交差点に関する交差点データ、施設等の地点に関する地点データ、地図を表示するための地図表示データ、経路を探索するための探索データ、地点を検索するための検索データ等からなる。

尚、地図情報ＤＢ１４に記憶された地図情報は、後述のように店舗２側がこれから予約を行おうとするユーザ４の店舗２への到着時刻を予測する為に用いられる。

一方、商品管理ＤＢ１５は、本予約管理サーバ３が設置された各店舗２（店舗Ａ～Ｃ）毎に、提供可能な商品（メニュー）の一覧について格納された記憶手段である。また、各メニューの価格や調理時間の目安についても格納しても良い。

そして、サーバ制御部１１は、後述のように商品管理ＤＢ１５に記憶された商品の一覧を考慮することにより、店舗２の利用の予約を希望するユーザ４に対して、ユーザの希望条件に合った店舗２の予約の提案を行うことが可能となる。

一方、サーバ側通信装置１７は情報の送受信対象となる通信端末５と通信ネットワーク網６を介して通信を行う為の通信装置である。また、通信端末５以外にインターネット網等に対する通信も可能である。

次に、ユーザ４が所有する通信端末５の概略構成について図５を用いて説明する。図５は本実施形態に係る通信端末５の制御系を模式的に示すブロック図である。尚、以下では特に通信端末５がスマートフォンである場合を例に挙げて説明する。

図５に示すように通信端末５はデータバスＢＵＳに、ＣＰＵ３１と、通信端末５を所持するユーザ４に関するユーザ情報（ユーザＩＤ等）やウェブの閲覧履歴やユーザの移動履歴等が記憶されたメモリ３２と、通信ネットワーク網６の基地局との間で信号の送受信を行う送受信回路部（ＲＦ）３３と、送受信回路部３３において受信したＲＦ（Radio Frequency）信号をベースバンド信号に変換するとともにベースバンド信号をＲＦ信号に変換するベースバンド処理部３４と、マイクロホン３５及びスピーカ３６等とのインターフェイスである入出力部３７と、液晶表示パネル等で構成されたディスプレイ３８と、タッチパネルやハードボタン等から構成される入力操作部３９と、ＧＰＳ４０と、カメラ４１とが接続されることにより構成されている。

ここで、通信端末５に内蔵されるＣＰＵ３１は、メモリ３２に格納されている動作プログラムに従って種々の動作を実行する通信端末５の制御手段であり、メモリ３２とともに通信端末制御部４２を構成する。また、通信端末制御部４２の各種処理内容は必要に応じてディスプレイ３８に表示される。

また、メモリ３２は通信端末５を所持するユーザ４に関するユーザ情報（ユーザＩＤ等）、ユーザによるウェブの閲覧履歴、ＧＰＳ４０やその他のセンサに基づいて検出された位置情報の履歴であるユーザの移動履歴、スケジュール情報等が記憶された記憶媒体である。また、後述の予約管理処理プログラム（図６）を含む各種アプリケーションプログラムについても記憶される。また、メモリ３２は、ハードディスク、メモリーカード等により構成しても良い。

また、スピーカ３６は、通話の音声出力以外に、ナビ機能の実行時においては通信端末制御部４２からの指示に基づいて案内経路（ユーザの移動予定経路）に沿った走行を案内する音声ガイダンスを出力する。

また、ディスプレイ３８は、筐体の一面に配設されており、液晶ディスプレイや有機ＥＬディスプレイ等が用いられる。そして、通信端末５にインストールされている各種アプリケーションを実行する為のトップ画面や、実行されたアプリケーションに係る画面（インターネット画面、メール画面、ナビ画面等）や、画像、動画等の各種情報が表示される。特に本実施形態では店舗２の利用の予約をオンラインで行う為の予約画面についても表示される。

また、入力操作部３９は、ディスプレイ３８の前面に設けられたタッチパネルや筐体に配置されたハードボタン等によって構成されている。そして、通信端末制御部４２は、タッチパネルやハードボタンの押下等により出力される電気信号に基づき、対応する各種の動作を実行すべく制御を行う。また、本実施形態では、オンラインでの店舗２の利用の予約を行う際にも操作される。尚、入力操作部３９は、番号／文字入力キー、表示された内容を選択するためのカーソルを動かすカーソルキー、選択を確定する決定キー等の各種キー等により構成することもできる。

また、ＧＰＳ４０は、人工衛星によって発生させられた電波を受信することにより、通信端末５（即ちユーザ４）の現在位置及び現在日時を検出可能とする。また、ＧＰＳ４０以外にも通信端末５の現在位置や方位を検出する為の他の装置（例えばジャイロセンサ等）を備える構成としても良い。

また、カメラ４１は、例えばＣＣＤ等の固体撮像素子を用いたカメラにより構成される小型の撮像装置であり、通信端末５の背面側に内蔵される。そして、専用のアプリケーションプログラムが起動された状態で、ユーザが入力操作部３９を操作することによって周辺を撮像することが可能となる。尚、カメラ４１で撮像された撮像画像は、メモリ３２に格納される。

続いて、前記構成を有する店舗予約システム１において、予約管理サーバ３及び通信端末５が実行する予約管理処理プログラムについて図６に基づき説明する。図６は本実施形態に係る予約管理処理プログラムのフローチャートである。ここで、予約管理処理プログラムは、通信端末５において店舗２の利用の予約を行う為の所定のアプリケーションプログラムが起動された後に実行され、店舗２の利用の予約を希望するユーザ４に対して、ユーザの希望条件に合った予約内容について提案するプログラムである。尚、以下の図６にフローチャートで示されるプログラムは、予約管理サーバ３や通信端末５が備えているＲＡＭやＲＯＭに記憶されており、ＣＰＵ２１或いはＣＰＵ３１により実行される。

先ず、図６に基づいて通信端末５のＣＰＵ３１が実行する予約管理処理プログラムについて説明する。ステップ（以下、Ｓと略記する）１においてＣＰＵ３１は、店舗２の利用の予約をオンラインで行う為の所定のアプリケーションプログラム（以下、予約アプリという）を起動する。尚、予約アプリの起動についてはユーザ４が通信端末５で所定の操作を行う以外に、例えば店舗のホームページに記載されているリンクを選択したり、店舗の広告に記載されている二次元コードを通信端末５で読み取ること等によっても起動することが可能である。また、予約アプリを起動するタイミングはユーザが店舗への移動を開始する前でも可能であるし、店舗への移動を開始した後でも可能である。予約アプリは予めウェブサーバ等からダウンロードされて通信端末５にインストールされていることを前提とする。

ここで、通信端末５において予約アプリが起動されると、先ずディスプレイ３８には図７に示す希望条件入力画面５１を出力する。図７に示すように希望条件入力画面５１には、店舗の予約を行うにあたって予約を行う主体であるユーザの希望内容を入力する為の入力画面が表示される。具体的には、利用人数を入力する欄と、利用する地域を入力する欄と、希望する店舗のジャンルを入力する欄と、希望する料金の価格帯を入力する欄とが表示される。尚、希望条件である地域、ジャンル、料金については必ずしもその全てを条件に含める必要はなく、また地域、ジャンル、料金以外の条件（例えば駐車場の有無、営業時間等）を追加することも可能である。また、ユーザが店舗を利用する際の希望の時刻（予約時刻）が決まっている場合において、予約時刻を入力する為の欄についても表示される。予約時刻の入力は必須ではない。但し、予約時刻を入力しない場合についてはユーザが予約完了後に遅滞なく店舗に向かって移動を開始すると仮定して以降の処理を実行することとなる。

また、ユーザが選択可能な店舗のジャンルとしては、例えば『和食』、『寿司』、『フレンチ』、『イタリアン』、『居酒屋』などがある。尚、本実施形態では特に予約管理サーバ３が設置された各店舗２が、食事の提供を行う飲食店である場合を例に挙げて説明しているが、予約管理サーバ３が設置された各店舗２は飲食店以外であっても良く、その場合には例えば店舗のジャンルとして『カラオケ店』、『スポーツジム』、『映画館』、『マッサージ店』等をユーザに指定させるようにする。また、『映画館』のような予め利用可能な時間帯（例えば上映スケジュール）が決まっている店舗を予約対象とする場合については、ユーザが店舗を利用する際の希望の時刻（予約時刻）を入力することを必須としても良い。

次に、Ｓ２においてＣＰＵ３１は、予約アプリの起動された通信端末５において上述のようにディスプレイ３８に表示された希望条件入力画面５１（図７）で受け付けたユーザの操作に基づいて希望条件の入力を行う。前記Ｓ２で入力された希望条件はメモリ３２に一旦格納される。

その後、Ｓ３においてＣＰＵ３１は、前記Ｓ２で希望条件の入力が完了する、具体的には希望条件入力画面５１に表示された入力完了ボタン５２が押下されると、ＧＰＳ４０を用いて通信端末５（即ち通信端末５を所持するユーザ）の現在位置を検出する。また、ＧＰＳ４０以外にジャイロセンサ等のセンサを用いることによってユーザの現在位置をより詳細に検出することが望ましい。

次に、Ｓ４においてＣＰＵ３１は、予約を希望するユーザの予約希望情報として、前記Ｓ２で入力された希望条件と、前記Ｓ３で検出された現在位置情報と、を送信元となる通信端末５を特定する端末ＩＤに紐づけて、予約管理サーバ３に対して送信する。

その後、予約希望情報を受信した予約管理サーバ３では、後述の様に予約管理サーバ３の設置された複数の店舗２の内、ユーザの希望する条件に合った店舗２を検索し、検索された店舗２で予約を行う予約内容を提案する。特にユーザ４が利用人数を複数人とした場合であって、一の店舗２のみでは予約が実行できない場合については、複数の店舗２に対して利用人数を振り分けて予約を行うことを提案する（Ｓ１１～Ｓ１７）。詳細については後述する。

続いて、Ｓ５においてＣＰＵ３１は、予約管理サーバ３から送信された“提案された予約内容”を受信する。尚、受信する“提案された予約内容”については、利用人数を振り分けなくとも希望条件に該当する一の店舗２でユーザの希望する利用人数の予約が実行できる場合については、予約可能な店舗２の一覧に関する情報である。一方、一の店舗２で予約が実行できない場合については、複数の店舗２に対して利用人数を振り分けた振り分け結果と、振り分けた各店舗２に関する情報である。

その後、Ｓ６においてＣＰＵ３１は、前記Ｓ５で予約管理サーバ３から受信した“提案された予約内容”をディスプレイ３８に対して表示する。例えば図８は希望条件に該当する一の店舗２でユーザの希望する利用人数の予約が実行できる場合の表示例であり、予約可能な店舗２の一覧を示した店舗案内画面５５を表示する。尚、予約可能な店舗は、前記Ｓ２で入力した希望条件（地域、ジャンル、料金）に該当するとともに、ユーザが到着する到着時刻においてユーザの指定した利用人数を収容することが可能な店舗である。尚、ユーザが予め予約を行う店舗を個別に指定している場合には、ユーザにより指定された一の店舗（但しその店舗が到着時刻においてユーザの指定した利用人数を収容することが可能であることが条件）のみを表示するようにしても良い。

図８に示すように予約可能な店舗の一覧を表示した店舗案内画面５５には、店舗を示す画像（店舗の外観画像であっても商品の画像であっても店舗の看板の画像などでも良い）とともに店舗名、ジャンル、店舗までの所要時間が表示される。尚、所在地、営業時間、定休日などの情報についても表示するようにしても良い。また、表示対象となる店舗が複数ある場合には、例えばユーザの嗜好に適合する順や所要時間が短い順に表示する。また、店舗案内画面５５には店舗毎に予約ボタン５６についても表示され、ユーザがいずれかの予約ボタン５６を押下するとユーザが予約管理サーバ３によって提案された予約内容を受け入れたと判定し（Ｓ７：ＹＥＳ）、後述の予約画面（図１０）へと表示が切り替わる。一方、ユーザがいずれの予約ボタン５６も押下しなかった場合には、ユーザが予約管理サーバ３によって提案された予約内容を受け入れなかったと判定し（Ｓ７：ＮＯ）、店舗２に対する予約を行うことなく処理を終了する。

一方で例えば図９は希望条件に該当する一の店舗２でユーザの希望する利用人数の予約が実行できない場合における“提案された予約内容”の表示例であり、複数の店舗２に対して利用人数を振り分けた振り分け結果と、振り分けた各店舗２を示した振り分け店舗案内画面５８を表示する。尚、振り分けられる店舗は、前記Ｓ２で入力した希望条件（地域、ジャンル、料金）に該当する店舗である。また、図９に示す例では２つの店舗に利用人数を振り分けているが、３つ以上の店舗に振り分けても良い。また、利用客の氏名が分かる場合には人数だけではなく、利用客の氏名を使って振り分け結果を表示しても良い。

図９に示すように複数の店舗２に対して利用人数を振り分けた振り分け結果と、振り分けた各店舗２を示した振り分け店舗案内画面５８には、振り分ける人数とともに振り分けられる店舗を示す画像（店舗の外観画像であっても商品の画像であっても店舗の看板の画像などでも良い）、店舗名、ジャンル、店舗までの所要時間が表示される。尚、所在地、営業時間、定休日などの情報についても表示するようにしても良い。また、振り分け店舗案内画面５８には予約ボタン５９と予約中止ボタン６０についても表示され、ユーザが予約ボタン５９を押下するとユーザが予約管理サーバ３によって提案された予約内容を受け入れたと判定し（Ｓ７：ＹＥＳ）、後述の予約画面（図１０）へと表示が切り替わる。一方、ユーザが予約中止ボタン６０を押下するとユーザが予約管理サーバ３によって提案された予約内容を受け入れなかったと判定し（Ｓ７：ＮＯ）、店舗２に対する予約を行うことなく処理を終了する。

そして、ユーザが予約ボタン５６又は予約ボタン５９を押下すると、ＣＰＵ３１は提案された店舗をユーザが予約対象に決定したと判定し、予約アプリの起動された通信端末５において新たに図１０に示す予約画面６１をディスプレイ３８に表示する。

そして、Ｓ８においてＣＰＵ３１は、ディスプレイ３８に表示される予約画面６１で受け付けたユーザの操作に基づいて予約情報の入力を行う。例えばユーザは予約画面６１において予約者（代表者）の氏名、予約の日時（来店予定日時）、予約の人数、予約の内容（予約メニュー）について入力する。そして、予約情報の入力が完了した後にユーザは予約完了ボタン６２を押下する。

予約完了ボタン６２が押下されると、Ｓ９においてＣＰＵ３１は入力された予約情報を予約対象店舗が備える予約管理サーバ３へと送信する。ここで、予約情報には、入力された予約情報に加えて予約対象となる店舗を特定する情報と予約情報の送信元の通信端末５を特定する端末ＩＤとが含まれている。上記予約情報を受信した予約管理サーバ３は、後述のように予約ＤＢ１２（図３）に対して予約情報を格納する。

尚、複数の店舗２に対して利用人数を振り分けた予約を行う場合については、図１１に示すように店舗毎に予約情報の入力を行う。例えばユーザは最初に表示された１件目の店舗の予約画面６１において予約者（代表者）の氏名、予約の日時（来店予定日時）、予約の人数、予約の内容（予約メニュー）について入力する。尚、予約の人数については提案された振り分け結果に従って予め入力されていることが望ましい。そして、１件目の店舗２の予約情報の入力が完了した後にユーザは予約進行ボタン６３を押下すると、続いて2件目の店舗の予約画面６１が表示される。２件目の店舗の予約画面６１においてもユーザは同様に予約者（代表者）の氏名、予約の日時（来店予定日時）、予約の人数、予約の内容（予約メニュー）について入力する。そして、予約情報の入力が完了した後にユーザは予約完了ボタン６２を押下する。

また、ユーザが予約画面６１において予約情報の入力が完了した後には、予約対象店舗をナビ機能における目的地或いは経由地に設定するようにしても良い。その結果、該当する店舗を目的地或いは経由地に設定した新たな推奨経路が探索され、通信端末５ではナビ機能を実行して周辺の地図や交差点拡大図等の移動案内画面を表示し、推奨経路に沿った移動案内が行われる。その結果、オンラインで予約を行った店舗までのユーザの移動を支援することが可能となる。尚、推奨経路の探索については通信端末５が自身で行っても良いし、地図情報を有する外部のサーバに探索を要求し、探索された推奨経路を受信するようにしても良い。

また、予約が完了した後に予約した店舗の情報（特に複数の店舗２に対して利用人数を振り分けた予約を行った場合については複数の店舗の情報）について、予約を実行するユーザのみではなく利用客全員の端末に対して送信するのが望ましい。

次に、予約管理サーバ３のＣＰＵ２１が実行する予約管理処理プログラムについて説明する。尚、以下のＳ１１～Ｓ１９の各処理は、通信端末５からの対応する情報を受信したタイミングで開始される。従って、各ステップの実施順序は必ずしもステップ番号の小さい順に実施されるとは限らない。

先ず、Ｓ１１においてＣＰＵ２１は、通信端末５から送信される予約希望情報を受信する。尚、予約希望情報には、予約を希望するユーザの希望条件と予約を希望するユーザの現在位置を特定する情報とが含まれる。更に、ユーザの希望条件には、利用人数と、利用する地域と、希望する店舗のジャンルと、希望する料金の価格帯と、ユーザが店舗を利用する際の希望の時刻（予約時刻）が決まっている場合には予約時刻とを含む。

次に、Ｓ１２においてＣＰＵ２１は、本予約管理サーバ３の設置された各店舗２の内、前記Ｓ１１で取得した希望条件にあう店舗を予約の候補となる店舗（以下、候補店舗という）として抽出する。但し、Ｓ１２の段階では利用人数の条件については無視する。また、ユーザの希望する地域に該当する店舗があるか否かについては店舗の住所や地図情報ＤＢ１４に記憶された地図情報を参照することによって判定する。同じくユーザの希望するジャンルと料金の価格帯に該当する店舗があるか否かについては商品管理ＤＢ１５を参照することによって判定する。尚、希望条件に完全に一致する店舗が存在しない場合には、希望条件に合う店舗がないことを通信端末５に回答しても良いし、希望条件に近い店舗を候補店舗として抽出するようにしても良い。

その後、Ｓ１３においてＣＰＵ２１は、前記Ｓ１１の予約希望情報の送信元となるユーザ（以下、送信元ユーザという）の候補店舗への到着時刻を予測する。候補店舗が複数ある場合には候補店舗毎に予測する。尚、到着時刻の予測は、地図情報ＤＢ１４に記憶された地図情報を用いて送信元ユーザの現在位置から候補店舗までの推奨経路を探索し、更にユーザの移動手段や交通状況を考慮して推奨経路を移動するのに必要な時間を算出することにより行う。尚、ユーザの移動手段については例えば候補店舗から送信元ユーザの現在位置までの距離が近い場合については徒歩で移動すると推定し、店舗から送信元ユーザの現在位置までの距離が遠い場合については車両を用いて候補店舗まで移動すると推定して到着時刻を予測する。尚、推奨経路の探索については例えば公知のダイクストラ法を用いて行われるが、予約管理サーバ３が行っても良いし、地図情報を有する外部のサーバに探索を要求し、探索された推奨経路を受信するようにしても良い。

尚、前記Ｓ１１で受信した予約希望情報には、送信元ユーザが店舗を利用する際の希望の時刻（予約時刻）が既に決まっている場合には、ユーザにより指定された予約時刻が含まれている。従って、予約時刻が含まれている場合については予約時刻にユーザが候補店舗に到着すると予想されるので、予約時刻を到着時刻とするのが望ましい。

次に、Ｓ１４においてＣＰＵ２１は、前記Ｓ１２で予測された到着時刻における候補店舗の混雑状況を予測する。具体的には、到着時刻における候補店舗内の空き座席をテーブル単位で予測する。尚、候補店舗の混雑状況については現時点の候補店舗の混雑状況と予約ＤＢ１２（図３）に記憶された予約情報から推定する。現時点の候補店舗の混雑状況については店舗管理ＤＢ１３に格納されている。

例えば、図１２に示すように候補店舗の現時点（２０２１年の１２月２１日の１８時時点）の混雑状況が４名用のテーブル席が５つと、６名用のテーブル席が３つと、８名用のテーブル席が２つ空き状態にある場合であって、到着時刻が２０２１年の１２月２１日の１９時と予想され、更に現在時刻である１８時から到着時刻の１９時までの間に利用人数が夫々4名、５名、７名、８名の計４組の予約が入っている場合を例に挙げて説明する。図１２に示す例では送信元ユーザの到着時刻までに４名用のテーブル席が１つ、６名用のテーブル席が１つ、８名用のテーブル席が２つ新たに使用されると予想されるので、到着時刻における候補店舗内の混雑状況は４名用のテーブル席が４つ、６名用のテーブル席が２つ空き状態であり、８名用のテーブル席が空きなしの状態になると予想される。

続いて、Ｓ１５においてＣＰＵ２１は、前記Ｓ１４で予測された到着時刻における候補店舗の混雑状況に基づいて、前記Ｓ１２で抽出された候補店舗の内、送信元ユーザの指定した利用人数を受け入れることができる店舗があるか否かを判定する。具体的には到着時刻において利用人数以上の席を備えたテーブルに空きがある場合に、利用人数を受け入れることができると判定する。但し、必ずしも一つのテーブルで受け入れる必要はなく、例えば隣接する複数のテーブルで受け入れることができるのであれば、利用人数を受け入れることができると判定しても良い。

そして、前記Ｓ１２で抽出された候補店舗の内、送信元ユーザの指定した利用人数を受け入れることができる店舗が少なくとも一以上あると判定された場合（Ｓ１５：ＹＥＳ）には、Ｓ１６へと移行する。それに対して、前記Ｓ１２で抽出された候補店舗の内、送信元ユーザの指定した利用人数を受け入れることができる店舗がないと判定された場合（Ｓ１５：ＮＯ）には、Ｓ１７へと移行する。

Ｓ１６においてＣＰＵ２１は、利用人数を振り分けなくとも希望条件に該当する一の候補店舗でユーザの希望する利用人数の予約が実行できると判定し、予約可能な候補店舗で予約を行う予約内容を提案し、“提案された予約内容”を送信元ユーザの通信端末５へと送信する。尚、具体的に“提案された予約内容”として送信元ユーザの通信端末５へと送信されるのは、ユーザの希望する利用人数の予約が実行できる候補店舗、即ち送信元ユーザの到着時刻において利用人数以上の席を備えたテーブルに空きがある候補店舗を特定する情報（店舗ＩＤ、店舗名、所在地等）である。その結果、送信元ユーザの通信端末５では、前述したように“提案された予約内容”として予約可能な候補店舗の一覧がユーザに案内される（図８）。

一方、Ｓ１７においてＣＰＵ２１は、利用人数を振り分けなければ希望条件に該当する候補店舗でユーザの希望する利用人数の予約が実行できないと判定し、複数の候補店舗で利用人数を振り分けて予約を行う予約内容を提案し、“提案された予約内容”を送信元ユーザの通信端末５へと送信する。尚、具体的に“提案された予約内容”として送信元ユーザの通信端末５へと送信されるのは、複数の候補店舗に対して利用人数を振り分けた振り分け結果（例えば店舗Ａに対して４人、店舗Ｂに対して４人等）と、振り分けた候補店舗を特定する情報（店舗ＩＤ、店舗名、所在地等）である。その結果、送信元ユーザの通信端末５では、前述したように“提案された予約内容”として複数の候補店舗に対して利用人数を振り分けた振り分け結果と、振り分けた各候補店舗がユーザに案内される（図９）。

尚、前記Ｓ１７において利用人数の振り分けを行う場合には、振り分ける店舗の数ができる限り少なく、且つ振り分ける人数はできる限り均等に近くなるようにするのが望ましい。例えば図１３に示すように予約を希望する送信元ユーザの利用人数が８人である一方で、候補店舗として店舗Ａ～Ｃがあって、送信元ユーザの到着時刻における空き座席が、店舗Ａは６名テーブルのみ、店舗Ｂは２名テーブルのみ、店舗Ｃは４名テーブルのみの場合について説明する。上記の場合では、送信元ユーザの指定した利用人数を一の候補店舗のみで受け入れることはできないので利用人数の振り分けを行う。振り分け方法としては、例えば店舗Ａ～Ｃに２名ずつ振り分けを行うことも可能であるし、店舗Ａに６名、店舗Ｂ又は店舗Ｃに２名で振り分けを行うことも可能である。しかしながら、振り分ける店舗の数ができる限り少なく、且つ振り分ける人数はできる限り均等に近くなるようにするという条件に従って、店舗Ａに４名、店舗Ｃに４名で振り分けを行うのが望ましい。

また、振り分ける候補となる候補店舗が多数ある場合には、振り分ける店舗間の距離ができる限り近くなるように店舗を選択するのが望ましい。また、振り分ける候補となる店舗をユーザに選択させるようにしても良い。

続いて、Ｓ１８においてＣＰＵ２１は、通信端末５から送信される予約情報を受信する。尚、予約情報には、予約情報の送信元の通信端末５を特定する端末ＩＤと、予約対象となる店舗、予約者（代表者）の氏名、予約の日時（来店予定日時）、予約の人数、予約の内容（予約メニュー）等が含まれている。

次に、Ｓ１９においてＣＰＵ３１は、前記Ｓ１８で受信した予約情報を現在の時刻とともに予約ＤＢ１２に格納する。一方、予約ＤＢ１２に格納された各情報は店舗２内に設けられたディスプレイに表示したり、予約情報を印刷した紙を出力すること等によって店舗２の従業員に対して提供される。

尚、上記実施例では利用人数の振り分けが行われた場合に同じグループの利用客が別々の店舗を利用することとなる問題がある。但し、近年ではスマートフォンやタブレット端末が普及するとともにそれらの通信端末を使ってオンラインで映像や音声を共有し、コミュニケーションをとる為のアプリケーションも普及している。そのようなアプリケーションを使用すれば仮に場所が離れていたとしても同じ空気間を共有できる。従って、大人数の利用客が複数の店舗へと分かれて利用することに対する弊害は少ない。尚、上記のコミュニケーションツールを店舗側で予め備えることとしても良い。それによってユーザの利便性をより向上させる。

尚、上記実施例は予約管理サーバ３が設置された店舗２が、食事の提供を行う飲食店である場合を例に挙げて説明している。しかしながら、予約管理サーバ３が設置された店舗２は飲食店以外であっても良い。但し、美容院やマッサージ店などの基本的に一人で利用する店舗については、本願発明が適用される機会は少なく、居酒屋やカラオケ店などの大人数で利用する店舗が主な対象になる。

以上詳細に説明した通り、本実施形態に係る店舗予約システム１、予約管理サーバ３及び予約管理サーバ３で実行されるコンピュータプログラムでは、ユーザが店舗の利用の予約を行う場合において、予約対象となる利用人数を取得し（Ｓ１１）、予約の候補となる候補店舗の混雑状況を取得し（Ｓ１３）、利用人数と候補店舗の混雑状況とを考慮して複数の候補店舗を対象として利用人数を振り分けるとともに振り分けた結果で予約を行うことをユーザに提案する（Ｓ１７、Ｓ６）ので、異なる複数の店舗間で利用客を振り分けて予約を受け付けることが可能となる。それによって、大人数での予約を行う際であってもユーザの店舗の選択肢を狭くすることなく、店舗側も利益を得る機会を失うことがない。
また、利用人数と候補店舗の混雑状況とに基づいて、一の候補店舗に対して予約を実行できるか否かを判定し（Ｓ１５）、一の候補店舗に対して予約を実行できると判定された場合には、当該一の候補店舗で予約を行うことをユーザに提案し（Ｓ１６）、一の候補店舗に対して予約を実行できないと判定された場合に、複数の候補店舗を対象として利用人数を振り分けるとともに振り分けた結果で予約を行うことをユーザに提案する（Ｓ１７）ので、利用客を振り分けることなく一の店舗での利用が可能である場合にはその予約を優先して提案する一方で、利用客を振り分ける必要な場合については異なる複数の店舗間で利用客を振り分けて予約を受け付けることが可能となる。
また、ユーザが店舗の利用を開始する予定の時刻である予約時刻を取得した場合には、予約時刻における候補店舗の混雑状況を予測して取得し、予約時刻を取得できない場合には、ユーザの現在位置と候補店舗の位置に基づいてユーザが候補店舗に到着する到着時刻を推定し、到着時刻における候補店舗の混雑状況を予測して取得する（Ｓ１３、Ｓ１４）ので、ユーザが店舗を利用するタイミングでの店舗の混雑状況を正確に取得することが可能となる。
また、提案された予約の内容に対してユーザが同意したか否かを取得し（Ｓ７）、提案された予約の内容に対してユーザが同意した場合に、提案された予約の内容で予約を実行する（Ｓ８、Ｓ１８）ので、利用客を振り分けて予約を受け付けることをユーザが同意した場合にのみにおいて異なる複数の店舗間で利用客を振り分けて予約を受け付けることが可能となる。それによって、ユーザの意思を尊重しつつ大人数での予約を行う際であってもユーザの店舗の選択肢を狭くすることなく、店舗側も利益を得る機会を失うことがない。
また、ユーザにより指定された地域、ジャンル、料金の少なくとも一の条件に該当する店舗を候補店舗として検索する（Ｓ１２）ので、ユーザが予約を希望する条件に該当する店舗を対象として予約を受け付けることが可能となる。

尚、本発明は前記実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の改良、変形が可能であることは勿論である。
例えば本実施形態では、予約管理サーバ３はユーザが利用の予約を行う対象となる店舗２が備えることとしているが、予約管理サーバ３は店舗２から情報の提供を受ける第３者が備えるサーバであっても良い。

また、本実施形態では、一の候補店舗に対して予約を実行できないと判定された場合のみに、複数の候補店舗に利用人数を振り分けて予約を行うことをユーザに提案している（Ｓ１７）が、一の候補店舗に対して予約を実行できる場合であっても、複数の候補店舗に利用人数を振り分けて予約を行うことをユーザに提案しても良い。また、一の候補店舗に対して予約を行う内容と複数の候補店舗に利用人数を振り分けて予約を行う内容を比較してユーザに提案しても良い。

また、本実施形態では予約情報の管理を行うサーバと、店舗の混雑状況を推測して予約の提案を行うサーバは同一のサーバとしているが、異なるサーバであっても良い。

また、本実施形態の店舗予約システム１は、一のアプリケーションによりユーザに対して予約内容の提案を行うとともに、ユーザからの店舗の利用の予約も受け付けているが、ユーザに対して予約内容の提案を行うのみとし、店舗の利用予約については他のアプリケーションや電話による予約で行うようにしても良い。

また、本実施形態では、通信端末５をスマートフォンに適用した例について説明したが、予約管理サーバ３と通信可能であってオンライン予約を行う機能を有していれば他の種類の通信端末に対して適用することも可能である。例えば携帯電話機、タブレット型端末、パーソナルコンピュータ、ナビゲーション装置等に適用することが可能である。また、ナビゲーション装置以外に適用する場合には、ユーザが車で移動する以外の状況、例えば徒歩で移動する状況においても実施可能である。

また、本実施形態では、Ｓ１２～Ｓ１７の店舗の空き状況を予測する処理や予約内容を提案する処理を予約管理サーバ３が行う構成としているが、通信端末５が行っても良い。

１…店舗予約システム、２…店舗、３…予約管理サーバ、４…ユーザ、５…通信端末、１１…サーバ制御部、１２…予約ＤＢ、１３…店舗管理ＤＢ、１４…地図情報ＤＢ、１５…商品管理ＤＢ、２１…ＣＰＵ、２２…ＲＡＭ、２３…ＲＯＭ

Claims (5)

1. ユーザが店舗の利用の予約を行う場合において、予約対象となる利用人数を取得する人数取得手段と、
   予約の候補となる店舗を検索する店舗検索手段と、
   前記店舗検索手段により検索された店舗である候補店舗の混雑状況を取得する混雑状況取得手段と、
   前記利用人数と前記候補店舗の混雑状況とを考慮して複数の候補店舗を対象として利用人数を振り分けるとともに振り分けた結果で予約を行うことをユーザに提案する予約提案手段と、を有する店舗予約システム。
2. 前記利用人数と前記候補店舗の混雑状況とに基づいて、一の候補店舗に対して予約を実行できるか否かを判定する予約実行判定手段を有し、
   前記予約提案手段は、
   一の候補店舗に対して予約を実行できると判定された場合には、当該一の候補店舗で予約を行うことをユーザに提案し、
   一の候補店舗に対して予約を実行できないと判定された場合に、複数の候補店舗を対象として利用人数を振り分けるとともに振り分けた結果で予約を行うことをユーザに提案する請求項１に記載の店舗予約システム。
3. 前記混雑状況取得手段は、
   ユーザが店舗の利用を開始する予定の時刻である予約時刻を取得した場合には、前記予約時刻における前記候補店舗の混雑状況を予測して取得し、
   前記予約時刻を取得できない場合には、ユーザの現在位置と前記候補店舗の位置に基づいてユーザが前記候補店舗に到着する到着時刻を推定し、前記到着時刻における前記候補店舗の混雑状況を予測して取得する請求項１又は請求項２に記載の店舗予約システム。
4. 前記予約提案手段により提案された予約の内容に対してユーザが同意したか否かを取得する同意取得手段と、
   前記予約提案手段により提案された予約の内容に対してユーザが同意した場合に、前記予約提案手段により提案された予約の内容で予約を実行する予約手段と、を有する請求項１乃至請求項３のいずれかに記載の店舗予約システム。
5. 前記店舗検索手段は、ユーザにより指定された地域、ジャンル、料金の少なくとも一の条件に該当する店舗を前記候補店舗として検索する請求項１乃至請求項４のいずれかに記載の店舗予約システム。

Images