特許第6585220号(P6585220)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社ぐるなびの特許一覧

特許6585220情報処理装置、その制御方法及びプログラム
<>
  • 特許6585220-情報処理装置、その制御方法及びプログラム 図000002
  • 特許6585220-情報処理装置、その制御方法及びプログラム 図000003
  • 特許6585220-情報処理装置、その制御方法及びプログラム 図000004
  • 特許6585220-情報処理装置、その制御方法及びプログラム 図000005
  • 特許6585220-情報処理装置、その制御方法及びプログラム 図000006
  • 特許6585220-情報処理装置、その制御方法及びプログラム 図000007
  • 特許6585220-情報処理装置、その制御方法及びプログラム 図000008
  • 特許6585220-情報処理装置、その制御方法及びプログラム 図000009
  • 特許6585220-情報処理装置、その制御方法及びプログラム 図000010
  • 特許6585220-情報処理装置、その制御方法及びプログラム 図000011
  • 特許6585220-情報処理装置、その制御方法及びプログラム 図000012
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6585220
(24)【登録日】2019年9月13日
(45)【発行日】2019年10月2日
(54)【発明の名称】情報処理装置、その制御方法及びプログラム
(51)【国際特許分類】
   G06Q 10/02 20120101AFI20190919BHJP
   G06Q 50/12 20120101ALI20190919BHJP
【FI】
   G06Q10/02
   G06Q50/12
【請求項の数】10
【全頁数】21
(21)【出願番号】特願2018-76249(P2018-76249)
(22)【出願日】2018年4月11日
(62)【分割の表示】特願2018-507032(P2018-507032)の分割
【原出願日】2017年11月24日
(65)【公開番号】特開2018-110042(P2018-110042A)
(43)【公開日】2018年7月12日
【審査請求日】2019年6月18日
(31)【優先権主張番号】特願2016-229126(P2016-229126)
(32)【優先日】2016年11月25日
(33)【優先権主張国】JP
【早期審査対象出願】
(73)【特許権者】
【識別番号】500175565
【氏名又は名称】株式会社ぐるなび
(74)【代理人】
【識別番号】100104215
【弁理士】
【氏名又は名称】大森 純一
(74)【代理人】
【識別番号】100196575
【弁理士】
【氏名又は名称】高橋 満
(74)【代理人】
【識別番号】100168181
【弁理士】
【氏名又は名称】中村 哲平
(74)【代理人】
【識別番号】100117330
【弁理士】
【氏名又は名称】折居 章
(74)【代理人】
【識別番号】100160989
【弁理士】
【氏名又は名称】関根 正好
(74)【代理人】
【識別番号】100168745
【弁理士】
【氏名又は名称】金子 彩子
(74)【代理人】
【識別番号】100176131
【弁理士】
【氏名又は名称】金山 慎太郎
(74)【代理人】
【識別番号】100197398
【弁理士】
【氏名又は名称】千葉 絢子
(74)【代理人】
【識別番号】100197619
【弁理士】
【氏名又は名称】白鹿 智久
(72)【発明者】
【氏名】古木 信司
【審査官】 牧 裕子
(56)【参考文献】
【文献】 特開2004−178001(JP,A)
【文献】 特開2009−163406(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 − 99/00
(57)【特許請求の範囲】
【請求項1】
1人以上の人がテーブルで提供を受けるサービスの予約を受け付ける情報処理装置であって、
1人以上の人を含むグループが前記サービスの提供を受けることを予約する予約情報を受信する受信部と、
前記サービスの提供に利用される、順序付けられた第1のテーブル群と、前記第1のテーブル群に空きがある非混雑時には使用されず予備として扱われ前記第1のテーブル群に空きがない混雑時に使用される第2のテーブル群の情報を記憶する記憶部と、
前記受信部が前記予約情報を受信すると、受信した前記予約情報に基づいて、受信した前記予約情報を前記第1のテーブル群の各順位のテーブルに関連付け
前記予約情報を関連付けられるテーブルが前記第1のテーブル群の中にない場合に、既存の複数の前記予約情報の関連付けを解除し、
前記予約情報を予約した前記グループに前記サービスを提供する優先度を、前記予約情報に基づいて、受信した複数の前記予約情報それぞれについて算出し、
前記第2のテーブル群から少なくとも1つのテーブルを前記第1のテーブル群に含ませた上で、算出した前記優先度に基づいて、前記予約情報を前記第1のテーブル群の高順位のテーブルから順に一対一対応で関連付ける
制御部と、
前記予約情報に関連付けられたテーブルの情報を前記予約情報と併せて出力する出力部
を具備する
情報処理装置。
【請求項2】
請求項1に記載の情報処理装置であって、
前記制御部は、前記予約情報から取得する人数、客単価、予約時間、滞在時間、過去のサービス利用態様の中から選ばれる少なくとも1以上に基づいて、当該予約情報に含まれる前記優先度を算出する
情報処理装置。
【請求項3】
請求項1又は2に記載の情報処理装置であって、
前記制御部は、前記第1のテーブル群と前記第2のテーブル群を合わせたテーブル数と同数のグループの前記予約情報を前記受信部が受信した場合に、満席と判断する
情報処理装置。
【請求項4】
請求項1から3のいずれか1項に記載の情報処理装置であって、
前記記憶部は、利用可能な人数の最大数が異なる前記第1のテーブル群及び前記第2のテーブル群の情報を複数記憶し、
前記受信部は、前記グループの人数を含む前記予約情報を受信し、
前記制御部は、前記受信部が受信した前記予約情報に含まれる人数に応じて、複数の前記第1のテーブル群及び前記第2のテーブルの情報のうち、いずれかを選択し、選択した前記第1のテーブル群及び前記第2のテーブルの情報に含まれる前記第1のテーブル群のいずれかのテーブルに、受信した前記予約情報を関連付ける
情報処理装置。
【請求項5】
請求項1から4のいずれか1項に記載の情報処理装置であって、
前記受信部は、前記第1のテーブル群及び前記第2のテーブル群に含まれる1のテーブルを指定して分割する分割コマンドを受信し、
前記制御部は、前記分割コマンドにより指定された前記1のテーブルを2つのテーブルに分割し、分割後の2つのテーブルを含むように前記第1のテーブル群及び前記第2のテーブルの情報を更新し、前記記憶部に記憶させる
情報処理装置。
【請求項6】
1人以上の人がテーブルで提供を受けるサービスの予約を受け付ける情報処理装置であって、
1人以上の人を含むグループが前記サービスの提供を受けることを予約する予約情報を受信する受信部と、
前記サービスの提供に利用される、順序付けられた第1のテーブル群と、前記第1のテーブル群に空きがない場合に前記サービスの提供に利用され、前記第1のテーブル群に属するテーブルよりも順位が上のテーブルからなる第2のテーブル群の情報を記憶する記憶部と、
前記受信部が前記予約情報を受信すると、受信した前記予約情報に基づいて、受信した前記予約情報を前記第1のテーブル群の各順位のテーブルに関連付け
前記予約情報を関連付けられるテーブルが前記第1のテーブル群の中にない場合に、既存の複数の前記予約情報の関連付けを解除し、
前記予約情報を予約した前記グループに前記サービスを提供する優先度を、前記予約情報に基づいて、受信した複数の前記予約情報それぞれについて算出し、
前記第2のテーブル群から少なくとも1つのテーブルを前記第1のテーブル群に含ませた上で、算出した前記優先度に基づいて、前記予約情報を前記第1のテーブル群の高順位のテーブルから順に一対一対応で関連付ける
制御部と、
前記予約情報に関連付けられたテーブルの情報を前記予約情報と併せて出力する出力部
を具備する
情報処理装置。
【請求項7】
1人以上の人がテーブルで提供を受けるサービスの提供に利用される、順序付けられた第1のテーブル群と、前記第1のテーブル群に空きがある非混雑時には使用されず予備として扱われ前記第1のテーブル群に空きがない混雑時に使用される第2のテーブル群の情報を記憶する記憶部を具備する情報処理装置が実行する制御方法であって、
1人以上の人を含むグループが前記サービスの提供を受けることを予約する予約情報を受信するステップと、
前記受信するステップにて前記予約情報が受信されると、受信した前記予約情報に基づいて、受信した前記予約情報を前記第1のテーブル群の各順位のテーブルに関連付けるステップと、
前記予約情報を関連付けられるテーブルが前記第1のテーブル群の中にない場合に、既存の複数の前記予約情報の関連付けを解除するステップと、
前記予約情報を予約した前記グループに前記サービスを提供する優先度を、前記予約情報に基づいて、受信した複数の前記予約情報それぞれについて算出するステップと、
前記第2のテーブル群から1つのテーブルを前記第1のテーブル群に含ませた上で、算出した前記優先度に基づいて、前記予約情報を前記第1のテーブル群の高順位のテーブルから順に一対一対応で関連付けるステップと、
前記予約情報に関連付けられたテーブルの情報を前記予約情報と併せて出力するステップ
を含む
情報処理装置の制御方法。
【請求項8】
1人以上の人がテーブルで提供を受けるサービスの提供に利用される、順序付けられた第1のテーブル群と、前記第1のテーブル群に空きがない場合に前記サービスの提供に利用され、前記第1のテーブル群に属するテーブルよりも順位が上のテーブルからなる第2のテーブル群の情報を記憶する記憶部を具備する情報処理装置が実行する制御方法であって、
1人以上の人を含むグループが前記サービスの提供を受けることを予約する予約情報を受信するステップと、
前記受信するステップにて前記予約情報を受信されると、受信した前記予約情報に基づいて、受信した前記予約情報を前記第1のテーブル群の各順位のテーブルに関連付けるステップと、
前記予約情報を関連付けられるテーブルが前記第1のテーブル群の中にない場合に、既存の複数の前記予約情報の関連付けを解除するステップと、
前記予約情報を予約した前記グループに前記サービスを提供する優先度を、前記予約情報に基づいて、受信した複数の前記予約情報それぞれについて算出するステップと、
前記第2のテーブル群から少なくとも1つのテーブルを前記第1のテーブル群に含ませた上で、算出した前記優先度に基づいて、前記予約情報を前記第1のテーブル群の高順位のテーブルから順に一対一対応で関連付けるステップと、
前記予約情報に関連付けられたテーブルの情報を前記予約情報と併せて出力するステップ
を含む
情報処理装置の制御方法。
【請求項9】
1人以上の人が卓で提供を受けるサービスの提供に利用される、順序付けられた第1のテーブル群と、前記第1のテーブル群に空きがある非混雑時には使用されず予備として扱われ前記第1のテーブル群に空きがない混雑時に使用される第2のテーブル群の情報を記憶する記憶部を具備する情報処理装置に、
1人以上の人を含むグループが前記サービスの提供を受ける優先度を含む、前記グループの前記サービスの提供を受けることを予約する予約情報を受信するステップと、
前記受信するステップにて前記予約情報が受信されると、受信した前記予約情報に基づいて、受信した前記予約情報を前記第1のテーブル群の各順位のテーブルに関連付けるステップと、
前記予約情報を関連付けられるテーブルが前記第1のテーブル群の中にない場合に、既存の複数の前記予約情報の関連付けを解除するステップと、
前記予約情報を予約した前記グループに前記サービスを提供する優先度を、前記予約情報に基づいて、受信した複数の前記予約情報それぞれについて算出するステップと、
前記第2のテーブル群から1つのテーブルを前記第1のテーブル群に含ませた上で、算出した前記優先度に基づいて、前記予約情報を前記第1のテーブル群の高順位のテーブルから順に一対一対応で関連付けるステップと、
前記予約情報に関連付けられたテーブルの情報を前記予約情報と併せて出力するステップ
を実行させる
情報処理装置の制御プログラム。
【請求項10】
1人以上の人がテーブルで提供を受けるサービスの提供に利用される、順序付けられた第1のテーブル群と、前記第1のテーブル群に空きがない場合に前記サービスの提供に利用され、前記第1のテーブル群に属するテーブルよりも順位が上のテーブルからなる第2のテーブル群の情報を記憶する記憶部を具備する情報処理装置に、
1人以上の人を含むグループが前記サービスの提供を受けることを予約する予約情報を受信するステップと、
前記受信するステップにて前記予約情報を受信されると、受信した前記予約情報に基づいて、受信した前記予約情報を前記第1のテーブル群の各順位のテーブルに関連付けるステップと、
前記予約情報を関連付けられるテーブルが前記第1のテーブル群の中にない場合に、既存の複数の前記予約情報の関連付けを解除するステップと、
前記予約情報を予約した前記グループに前記サービスを提供する優先度を、前記予約情報に基づいて、受信した複数の前記予約情報それぞれについて算出するステップと、
前記第2のテーブル群から少なくとも1つのテーブルを前記第1のテーブル群に含ませた上で、算出した前記優先度に基づいて、前記予約情報を前記第1のテーブル群の高順位のテーブルから順に一対一対応で関連付けるステップと、
前記予約情報に関連付けられたテーブルの情報を前記予約情報と併せて出力するステップ
を実行させる
情報処理装置の制御プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本技術は、情報処理装置、その制御方法及びプログラムに関する。
【背景技術】
【0002】
飲食店などが提供する飲食物提供サービスを受けることを予約する情報システムの先行例としては、例えば特許文献1に記載の技術などがある。特許文献1には、可搬型通信端末からユーザ識別情報と共に人数や来店時間などの情報を含んだ施設利用予約を受信して、空席を確認し、予約を入れる技術が開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2015−153403号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1に記載の技術によれば、単にユーザが空席のある店舗に予約を入れることは可能になるものの、店舗側でユーザを適切なテーブル(卓)に案内することまでは可能にならない。
【0005】
ユーザを適切なテーブルに案内することは、元来、熟練とノウハウが必要である。飲食店の店舗に来るユーザは、可能であれば広めのテーブル、出入り口や厨房への通路などから遠くて落ち着くテーブルを好む。ユーザの希望に応えることはカスタマー・サティスファクションに通じるが、来店客数が増えてくると条件の劣るテーブルに案内する必要も出てくる。店舗の案内係は、店の混み具合に応じて、ユーザをゆとりのある席から順に案内する「条件の良い席に先着順」の配席方法から、可能な限り多くのユーザにサービスを提供することを目的にした「配席効率優先」の配席方法に切り替えていく必要がある。
【0006】
サーバコンピュータとクライアント端末などを組み合わせた飲食店の予約システムにおいて配席を可能にすることを考慮した場合、上述のような、店舗の混み具合に応じて「条件の良い席に先着順」から「配席効率優先」への切り替えの問題を技術的に解決する必要がある。
【0007】
店舗では来店客のグループ規模に応じて案内するテーブルを分けていることがある。例えば、4人から6人までのグループ向けのテーブル群と、2人から4人までのグループ向けのテーブル群とを用意し、グループの規模に応じ案内するテーブルを振り分けている。しかしながら、この運用を上述のような予約システムにおける配席アルゴリズムで実行しようとすると、後から来たグループが先に到着していたグループよりも良い席に案内されて不公平感が生まれる可能性がある。
【0008】
具体的には例えば、2人グループが「条件の良い席に先着順」に案内された結果、2人から4人までのグループ向けのテーブル群のストックが枯渇してしまい、その次に来た2人グループが、2人から4人までのグループ向けのテーブル群よりもキャパシティが大きい(すなわち、条件のより良い)4人から6人までのグループ向けのテーブル群に属するテーブルに案内されてしまう、ないし、案内せざるを得ない状況が生まれる。この観点からも、店舗の混み具合に応じて「条件の良い席に先着順」から「配席効率優先」への切り替えが要請される。
【0009】
以上のような事情に鑑み、本技術の目的は、予約受付を行う情報処理装置において、予約受付状況に応じて適切な配席を行うことにある。
【課題を解決するための手段】
【0010】
上記目的を達成する本発明の一側面としての情報処理装置は、1人以上の人がテーブルで提供を受けるサービスの予約を受け付ける情報処理装置であって、受信部と、記憶部と、制御部と、出力部を具備する。
上記受信部は、1人以上の人を含むグループが上記サービスの提供を受けることを予約する予約情報を受信する。
上記記憶部は、上記サービスの提供に利用される、順序付けられた第1のテーブル群と、上記第1のテーブル群に空きがない場合に上記サービスの提供に利用され、上記第1のテーブル群に属するテーブルよりも順位が上のテーブルからなる第2のテーブル群の情報を記憶する。
上記制御部は、上記受信部により上記予約情報が受信されると、上記第1のテーブル群に属するテーブルへ一対一対応の関連付けが可能である限り、上記予約情報を上記第1のテーブル群の高順位のテーブルから順に関連付ける。
また、上記制御部は、上記予約情報を関連付けられるテーブルが上記第1のテーブル群の中にない場合に、既存の複数の上記予約情報の関連付けを解除する。
また、上記制御部は、上記予約情報を予約した上記グループに上記サービスを提供する優先度を、上記予約情報に基づいて、受信した複数の上記予約情報それぞれについて算出する。
また、上記制御部は、上記第2のテーブル群から少なくとも1つのテーブルを上記第1のテーブル群に含ませた上で、算出した上記優先度に基づいて、上記予約情報を上記第1のテーブル群の高順位のテーブルから順に一対一対応で関連付ける。
上記出力部は、上記予約情報に関連付けられたテーブルの情報を上記予約情報と併せて出力する。
【0011】
上記情報処理装置によれば、客グループを第1のテーブル群に属するテーブルに関連付けられる間(=店が比較的空いている間)は予約順に関連付けられるので、先着順に広くよい席に案内することができる一方で、第1のテーブル群に属するテーブルに関連付けられなくなったとき(=予約が多いとき)は予備のテーブル(本来もっと人数の多い客向けにキープしておきたい席など)を第1のテーブル群に含ませた上で、客グループの優先度に基づいて関連付けるので、席効率優先で配席することができる。
また、人数の多い客にも対応できるような広い席が、あとから予約を入れたグループに対して配席されることをなくすことができる。これにより不公平感を客に抱かせる可能性を低減できる。
また、上記制御部を有する情報処理装置が、従来、複数の店舗において別々に処理される配席処理を一括して行うことができるので、複数の店舗それぞれに高性能な計算機を備える必要がなくなり、計算機資源の節約になるという効果もある。
【0012】
上記制御部は、上記予約情報から取得する人数、客単価、予約時間、滞在時間、過去のサービス利用態様の中から選ばれる少なくとも1以上に基づいて、当該予約情報に含まれる上記優先度を算出してもよい。
【0013】
上記制御部がこのように優先度を算出することで、過去に店舗に売り上げをもたらしたユーザの履歴が考慮され、店舗とユーザ双方の満足度を高めることができる。
【0014】
上記制御部は、上記第1のテーブル群と上記第2のテーブル群を合わせたテーブル数と同数のグループの上記予約情報を上記受信部が受信した場合に、満席と判断してもよい。
【0015】
上記制御部がこのように満席の判断を行うことで、予約の受付に上限を設けることができ、店舗とユーザ双方の満足度を高めることができる。
【0016】
上記記憶部は、利用可能な人数の最大数が異なる上記第1のテーブル群及び上記第2のテーブル群の情報を複数記憶し、上記受信部は、上記グループの人数を含む上記予約情報を受信してもよい。
この場合、上記制御部は、上記受信部が受信した上記予約情報に含まれる人数に応じて、複数の上記第1のテーブル群及び上記第2のテーブルの情報のうち、いずれかを選択し、選択した上記第1のテーブル群及び上記第2のテーブルの情報に含まれる上記第1のテーブル群のいずれかのテーブルに、受信した上記予約情報を関連付けてもよい。
【0017】
上記制御部がこのように予約情報に含まれる人数に応じて、上記第1のテーブル群及び上記第2のテーブル群の情報を切り替えることで、適切な配席が行われるようになる。
【0018】
上記受信部は、上記第1のテーブル群及び上記第2のテーブル群に含まれる1のテーブルを指定して分割する分割コマンドを受信してもよい。
この場合、上記制御部は、上記分割コマンドにより指定された上記1のテーブルを2つのテーブルに分割し、分割後の2つのテーブルを含むように上記第1のテーブル群及び上記第2のテーブルの情報を更新し、上記記憶部に記憶させてもよい。
【0019】
上記制御部がこのように上記第1のテーブル群及び上記第2のテーブルの情報を更新することで、テーブルの分割を行うことが可能になり、店舗はより多くのユーザにサービスを提供することができるようになる。
【0020】
上記目的を達成する本発明の別の一側面は、受信部と、記憶部と、制御部と、出力部を具備する情報処理装置である。
上記情報処理装置は、1人以上の人がテーブルで提供を受けるサービスの予約を受け付ける。
上記受信部は、1人以上の人を含むグループが上記サービスの提供を受けることを予約する予約情報を受信する。
上記記憶部は、上記サービスの提供に利用される、順序付けられた第1のテーブル群と、上記第1のテーブル群に空きがない場合に上記サービスの提供に利用され、上記第1のテーブル群に属するテーブルよりも順位が上のテーブルからなる第2のテーブル群の情報を記憶する。
上記制御部は、上記受信部が上記予約情報を受信すると、上記予約情報に基づいて、受信した上記予約情報を上記第1のテーブル群の高順位のテーブルから順に関連付ける。
また、上記制御部は、上記予約情報を関連付けられるテーブルが上記第1のテーブル群の中にない場合に、既存の複数の上記予約情報の関連付けを解除する。
また、上記制御部は、上記予約情報を予約した上記グループに上記サービスを提供する優先度を、上記予約情報に基づいて、受信した複数の上記予約情報それぞれについて算出する。
また、上記制御部は、上記第2のテーブル群から少なくとも1つのテーブルを上記第1のテーブル群に含ませた上で、算出した上記優先度に基づいて、上記予約情報を上記第1のテーブル群の高順位のテーブルから順に一対一対応で関連付ける。
上記出力部は、上記予約情報に関連付けられたテーブルの情報を上記予約情報と併せて出力する。
【0021】
上記目的を達成する本発明の別の一側面は、1人以上の人がテーブルで提供を受けるサービスの提供に利用される、順序付けられた第1のテーブル群と、上記第1のテーブル群に空きがない場合に上記サービスの提供に利用され、上記第1のテーブル群に属するテーブルよりも順位が上のテーブルからなる第2のテーブル群の情報を記憶する記憶部を具備する情報処理装置が実行する制御方法である。
上記情報処理装置の制御方法は、以下の各ステップを含む。
・1人以上の人を含むグループが上記サービスの提供を受けることを予約する予約情報を受信するステップ。
・上記受信するステップにて上記予約情報が受信されると、上記第1のテーブル群に属するテーブルへ一対一対応の関連付けが可能である限り、上記予約情報を上記第1のテーブル群の高順位のテーブルから順に関連付けるステップ。
・上記予約情報を関連付けられるテーブルが上記第1のテーブル群の中にない場合に、既存の複数の上記予約情報の関連付けを解除するステップ。
・上記予約情報を予約した上記グループに上記サービスを提供する優先度を、上記予約情報に基づいて、受信した複数の上記予約情報それぞれについて算出するステップ。
・上記第2のテーブル群から1つのテーブルを上記第1のテーブル群に含ませた上で、算出した上記優先度に基づいて、上記予約情報を上記第1のテーブル群の高順位のテーブルから順に一対一対応で関連付けるステップ。
・上記予約情報に関連付けられたテーブルの情報を上記予約情報と併せて出力するステップ。
【0022】
上記目的を達成する本発明の別の一側面は、1人以上の人が卓で提供を受けるサービスの提供に利用される、順序付けられた第1のテーブル群と、上記第1のテーブル群に空きがない場合に上記サービスの提供に利用され、上記第1のテーブル群に属するテーブルよりも順位が上のテーブルからなる第2のテーブル群の情報を記憶する記憶部を具備する情報処理装置に、以下のステップを実行させるプログラムである。
・1人以上の人を含むグループが上記サービスの提供を受ける優先度を含む、上記グループの上記サービスの提供を受けることを予約する予約情報を受信するステップ。
・上記受信するステップにて上記予約情報が受信されると、上記第1のテーブル群に属するテーブルへ一対一対応の関連付けが可能である限り、上記予約情報を上記第1のテーブル群の高順位のテーブルから順に関連付けるステップ。
・上記予約情報を関連付けられるテーブルが上記第1のテーブル群の中にない場合に、既存の複数の上記予約情報の関連付けを解除するステップ。
・上記予約情報を予約した上記グループに上記サービスを提供する優先度を、上記予約情報に基づいて、受信した複数の上記予約情報それぞれについて算出するステップ。
・上記第2のテーブル群から1つのテーブルを上記第1のテーブル群に含ませた上で、算出した上記優先度に基づいて、上記予約情報を上記第1のテーブル群の高順位のテーブルから順に一対一対応で関連付けるステップ。
・上記予約情報に関連付けられたテーブルの情報を上記予約情報と併せて出力するステップ。
【発明の効果】
【0023】
以上のように、本技術によれば、予約受付を行う情報処理装置において、予約受付状況に応じて適切な配席を行うことができる。
【図面の簡単な説明】
【0024】
図1】本技術の実施形態に係る予約受付システム構成例を示す図である。
図2】上記実施形態における記憶部に記憶されている情報を示す図である。
図3】上記実施形態におけるユーザ情報の構成を説明するための図である。
図4】上記実施形態における店舗情報の構成を説明するための図である。
図5】上記実施形態におけるテーブル情報の構成を説明するための図である。
図6】上記テーブル情報に含まれる卓シンボルの分類を説明するための図である。
図7】上記実施形態における予約情報の構成を説明するための図である。
図8】上記実施形態における配席処理の流れを示すフローチャートである。
図9】上記実施形態における店舗端末への表示出力態様の一例を示す図である。
図10】上記実施形態における満席時の処理の流れを示すフローチャートである。
図11】上記テーブル情報に含まれる卓シンボルの分類を説明するための図である。
【発明を実施するための形態】
【0025】
以下、本技術に係る実施形態を、図面を参照しながら説明する。なお、説明は以下の順番で行うものとする。
1.予約受付システムの構成
2.予約受付システムの概略動作
3.ユーザ情報の構成
4.店舗情報の構成
5.予約情報の構成及び生成
6.配席処理
7.出力処理
8.満席時の処理
9.複数のテーブル情報
【0026】
<予約受付システムの構成>
図1を参照すると、本実施形態に係る予約受付システム1の構成例が示されている。図示のように、本実施形態に係る予約受付システム1は、配席サーバ100、ユーザ端末200、店舗端末300がネットワーク400を介して相互に通信可能に接続した情報通信システムである。
【0027】
配席サーバ100は、店舗端末300に対応する各店舗において、例えば飲食サービスのように、テーブルで客にサービスが提供される際の客の配席処理を制御するサーバコンピュータであり、制御部101、記憶部102、通信部103、出力部104を備える。制御部101は例えば中央演算装置(Central Processing Unit)などで構成することができ、配席サーバ100の演算及び制御を行う物理デバイスとして構成することができる。記憶部102は例えば物理的にはハードディスクドライブなど不揮発性の記憶デバイスで構成することができる。通信部103は例えばローカルエリアネットワークへのインタフェイスデバイスなどで構成することができる。
【0028】
上記配席サーバ100は、例えば、飲食店に関する情報を掲載したポータルサイトを運営する飲食店情報提供サーバであってもよい。この場合、配席サーバ100は、上記ポータルサイトにおいて、ユーザ端末200のユーザ向けに飲食店情報の検索システムを提供するとともに、飲食店の予約受付システムを提供する。具体的には、配席サーバ100は、ユーザ端末200からの検索要求に基づいて検索条件に合致する飲食店情報を検索し、検索結果を掲載したWebページを生成してユーザ端末200へ送信し、ユーザの予約要求に基づいて、いずれかの飲食店情報に対応する飲食店に対する利用予約を受け付ける。
【0029】
出力部104は制御部101の情報処理結果を出力する機能を備える論理的な機能ブロックである。具体的な一例として、出力部104はディスプレイデバイスなど表示出力可能なデバイスで構成されてもよい。あるいは、出力部104が店舗端末300やユーザ端末200に対して、上記通信部103によりネットワーク400を介して情報処理結果を出力するウェブサーバで構成されてもよい。
【0030】
ユーザ端末200は、通信部203、表示部204、入力部205を備える。ユーザ端末200は可搬性のある情報通信端末(スマートフォンなど)として構成されてもよい。通信部203は例えばモバイルデータ通信可能な通信デバイスなどで構成することができる。表示部204はユーザ端末200の情報処理結果や配席サーバ100の出力部104などから出力された情報などをユーザに対して表示する機能を備える。表示部204は液晶タッチパネルなどで構成されてもよい。入力部205はユーザ端末200のユーザの操作入力をユーザ端末200に入力する機能を備える。入力部205は例えば液晶タッチパネルなどで構成されてもよい。
【0031】
店舗端末300は、例えば飲食店等、テーブルでサービスを提供する店舗が有する端末であり、記憶部302、通信部303、表示部304、入力部305を備える。店舗端末300は可搬性のある情報通信端末(スマートフォンなど)あるいは据え置き型のパーソナルコンピュータとして構成されてもよい。記憶部302は例えば物理的にはハードディスクドライブや半導体メモリなど不揮発性の記憶デバイスで構成することができる。通信部303は例えばローカルエリアネットワークへのインタフェイスデバイスなどで構成することができる。表示部304は店舗端末300の情報処理結果や配席サーバ100の出力部104などから出力された情報などをユーザに対して表示する機能を備える。表示部304は液晶タッチパネルなどで構成されてもよい。入力部305は店舗端末300のユーザの操作入力を店舗端末300に入力する機能を備える。入力部305は例えば液晶タッチパネルなどで構成されてもよい。
【0032】
ネットワーク400は、配席サーバ100、ユーザ端末200、店舗端末300を相互に通信可能にする通信ネットワークである。ネットワーク400は、例えば、インターネットやモバイルデータ通信ネットワークなどが複合的に組み合わさって構成されてもよい。
【0033】
本実施形態に係る予約受付システム1には、1以上複数のユーザ端末200が含まれてもよく、1以上複数の店舗端末300が含まれてもよい。
【0034】
<予約受付システムのデータベースの概略>
予約受付システム1は、ユーザ端末200からサービスの提供を受けることの予約を受け付けて、予約された店舗における配席を行い、配席結果を店舗端末300に送出する情報処理を行う。ここで言う「サービス」とは1以上の座席が設定されたテーブルで提供を受けるサービスを指し、例えば、飲食店における飲食サービスがその典型として挙げられるが、飲食サービスに限定する必要はない。
【0035】
予約受付システム1には、上記情報処理を行うために、店舗情報があらかじめ記憶されている必要がある。また、予約受付システム1にはユーザ端末200や店舗端末300から予約情報が入力される必要がある。その他に、必須ではないが、予約受付システム1にユーザ情報があらかじめ記憶されていてもよい。
【0036】
図2を参照すると本実施形態における記憶部102及び/又は記憶部302にあらかじめ記憶されている情報が示されている。図示のように、カスタマーデータベース510と店舗データベース520が記憶されている。これらの記憶先は配席サーバ100と店舗端末300のどちらでもよい。カスタマーデータベース510は1以上のユーザ情報を記憶する。店舗データベース520は1以上の店舗情報を記憶する。
【0037】
ユーザ情報は予約受付システム1の1人のユーザに関する情報であって、ユーザ端末200を使用するユーザに関する情報である。店舗情報は店舗端末300が設置されている店舗に関する情報である。以下、ユーザ情報、店舗情報、予約情報のそれぞれについてこの順番に説明する。
【0038】
<ユーザ情報の構成>
カスタマーデータベース510は例えばリレーショナルデータベースとして構成することができ、図3に示すようなユーザ情報をユーザごとに記憶している。図3を参照すると本実施形態におけるユーザ情報を説明するための概念図が示されている。図3(a)にはユーザ情報における「顧客の基本情報」が、図3(b)にはユーザ情報における「来店履歴」が示されている。
【0039】
予約受付システム1のユーザの基本情報は、図3(a)に示すように、顧客識別情報、来店人数の中央値、客単価の中央値などを「ユーザ」ごとに有する情報としてカスタマーデータベース510に格納される。来店人数の中央値、客単価の中央値は来店履歴から算出してもよい。
【0040】
予約受付システム1のユーザの来店履歴は、図3(b)に示すように、来店日時、滞在時間、グループでの来店人数、支払いした総額などを「店舗(又は店舗ID)」ごとに有する情報としてカスタマーデータベース510に格納される。来店履歴に係る情報テーブルには店舗識別情報が含まれている。店舗は当該店舗識別情報から特定可能である。
【0041】
<店舗情報の構成>
店舗データベース520も例えばリレーショナルデータベースとして構成することができ、図4に示すような店舗情報を店舗ごとに記憶している。図4を参照すると本実施形態における店舗情報を説明するための概念図が示されている。図4(a)には店舗情報における「店舗の基本情報」が、図4(b)には店舗情報における「テーブル基本情報」が、図4(c)には店舗情報における「テーブル情報」が示されている。
【0042】
店舗の基本情報は、図4(a)に示すように、店舗識別情報、その店舗のサービスの種類(ジャンル)、営業時間などを「店舗」ごとに有する情報として店舗データベース520に格納される。店舗の基本情報としてはこのほかに店舗の所在する位置情報や住所などを含んでも良い。サービスの種類(ジャンル)としては、「フレンチレストラン」、「和食レストラン」など提供する料理による分類のほか、「居酒屋」など業態による分類でもよい。
【0043】
店舗のテーブル基本情報は、図4(b)に示すように、店舗が備えるテーブル(卓)の卓ID、席数、連結可能な卓、卓ポイントなどを「テーブル」ごとに有する情報として店舗データベース520に格納される。ここで、卓IDはテーブルを識別するための情報、席数はそのテーブルに着座可能な最大人数(定員、キャパシティ)である。連結可能な卓は自己を含まない他のテーブルの卓IDが指定される情報である。隣にあるテーブルの卓IDなどが指定される。卓ポイントはそのテーブルの快適さの度合いを示す指標である。
【0044】
卓ポイントはそのテーブルがユーザ(来店客)にとって快適なテーブルであれば高いポイントが、混雑時以外は避けたいテーブルであれば低いポイントが付与される。例えば、店舗内の奥まった場所にあるような上席には高いポイントが付与される。出入り口に近い場所などにあるテーブルは低いポイントが付与される。卓ポイントの付与は店舗のオーナーや従業員が行う。卓ポイントを自動的に付与しても良い。
【0045】
テーブル基本情報において、卓IDが付与されるテーブルは、これ以上のテーブルの分割が不可能な(又は好ましくない)最小単位とする。卓IDが付与されるテーブルは、物理的に1個のテーブルとしてもよい。
【0046】
店舗のテーブル情報は、図4(c)に示すように、卓シンボルID、席数、構成する卓ID、卓ポイントなどを「卓シンボル」ごとに有する情報として店舗データベース520に格納される。テーブル情報は、テーブル基本情報に基づいて生成される。「卓シンボル」は1以上の「卓IDが付与されたテーブル」により構成された論理的なテーブルである。予約受付システム1は、「卓シンボル」を、来店した1グループに対して1つ割り当てる(配席する)。
【0047】
図4(c)に示されている「卓シンボル」は、図4(b)に列挙した卓を用いて生成された「卓シンボル」の一例にすぎない。卓の組み合わせによっては図4(c)に示された例とは異なる卓シンボルが生成されうる。また、図4(b)に示したようなテーブル基本情報から、複数のテーブル情報が生成されてもよい。
【0048】
図5を参照すると店舗レイアウトの一例が示されている。図中、矩形はテーブルを示し、円形は座席を示す。矩形のテーブルは卓IDが付与されるテーブルであって、図4のテーブル基本情報における1エントリに相当する。図中破線で囲まれた1つ又は複数のテーブルは、各々、「卓シンボル」を表し、図4のテーブル情報における1エントリに相当する。図5中に示した卓IDや卓シンボルIDは図4の卓IDや卓シンボルIDに合わせている。
【0049】
店舗のテーブル情報における、ある卓シンボルの席数は、図4(c)と図5に示すように、その卓シンボルを構成する卓の席数を単純加算したデータとすることができる。
【0050】
店舗のテーブル情報における、ある卓シンボルを構成する卓の卓IDは、図4(c)と図5に示すように、テーブル基本情報に含まれる卓IDを1つ以上複数含むデータとすることができる。このデータは例えば、図5に示すように隣り合うテーブルなどの卓IDを含むデータとなる。
【0051】
店舗のテーブル情報における、ある卓シンボルの卓ポイントは、その卓シンボルの快適さの度合いを示す指標である。卓シンボルの卓ポイントの設定方法に限定はなく、例えば、その卓シンボルを構成する卓の卓ポイントを加算して算出される値としてもよい。あるいは、その卓シンボルを構成する卓の卓ポイントの算術平均としてもよい。
【0052】
図6を参照すると、図4(c)に示したテーブル情報が複数、各テーブル情報に含まれる卓シンボルの分類と共に示されている。店舗データベース520は、各店舗ごとに、1以上複数のテーブル情報を格納する。図6には、対象人数の異なるテーブル情報が3つ示されている。
【0053】
なお、対象人数は、テーブル情報が含む卓シンボルの中で、最も席数(図4(c)に示す「席数」)が少ない卓シンボルの席数にあわせる。例えば、図4(c)のテーブル情報の例では、卓シンボルIDがbbabの卓シンボルの席数が最小の2であるから、当該テーブル情報は、図6中の「テーブル情報1」のように2人以下向けとする。テーブル情報1の中には、4人まで着座可能な卓シンボルが含まれるが、それらも含めてすべて、2人以下向けの卓シンボルとなる。
【0054】
各テーブル情報は、テーブル情報に含まれる卓シンボルを少なくとも2種に分類する情報も含む。1種目の卓シンボル群を第1のテーブル群、2種目の卓シンボル群を第2のテーブル群と呼ぶ。なお、卓シンボルは第3のテーブル群、第4の・・・とさらに分類されてもよいが、本実施形態において2種を超える分類については扱わない。
【0055】
第1のテーブル群は、店舗が比較的混雑していない状態のときに、来店客に案内されるテーブル(卓シンボルとしてまとめられている1以上複数の卓IDが付与されたテーブルのまとまりを指す)の集合である。第2のテーブル群は、店舗が比較的混雑していない状態のときに、予備のテーブルとしてストックされているが、店舗が混雑している状態では使用され得るテーブルの集合である。
【0056】
以上に説明したような店舗情報が、店舗ごとに店舗データベース520に格納されている。なお、店舗のテーブル情報は、動的に生成される情報であってもよい。
【0057】
<予約情報の構成及び生成>
図7(a)を参照すると、予約情報の構成の一例が示されている。図示のように、予約情報は少なくとも、顧客識別情報、予約人数、予約日時、店舗識別情報を含む情報である。図7(b)を参照するとユーザ端末200の表示部204に表示されるユーザインタフェイス画面の一例が示されている。
【0058】
ユーザ端末200は、図7(b)に示すような画面を用いてユーザ端末200のユーザに予約人数、予約日時の入力を促し、顧客識別情報と店舗識別情報と共に、配席サーバ100に送信する。当該画面は、配席サーバ100が生成したWebページとしてユーザ端末200のブラウザ上で実行されてもよいし、ユーザ端末200にインストールされた店舗検索・予約用のアプリケーション上で実行されてもよい。なお、図7(b)のようなダイアログに顧客識別情報と店舗識別情報を埋め込むことや、このようなダイアログから入力された情報に基づいて、図7(a)に示すような予約情報を生成することについては、当業者に良く知られているWebアプリケーション技術を利用することができる。
【0059】
<配席処理>
配席サーバ100が、ユーザ端末200から送出された予約情報を受信すると、配席サーバ100の制御部101により予約処理と配席処理が実行される。予約情報に含まれる店舗識別情報により特定される店舗に、予約情報に含まれる顧客識別情報により特定されるユーザの予約を入れる予約処理については、当業者に良く知られている技術を利用することができる。
【0060】
以下、その予約処理に続いて(あるいは予約処理中に)配席サーバ100により実行される配席処理について述べる。配席処理の具体的な流れについては種々の方法があり、以下ではその一例について述べる。
【0061】
本実施形態の配席処理においては、まず、受信部103が予約情報を受信した際に、制御部101は予約情報に含まれる人数をチェックする。次に、制御部101は、予約情報の人数に応じて、複数のテーブル情報のうち、いずれかを選択する。例えば、4人の予約であれば、「テーブル情報2」が選択される。図6を参照しながら述べたように、店舗データベース520は、対象人数が異なるテーブル情報を複数記憶している。
【0062】
上記制御部がこのように予約情報に含まれる人数に応じて、テーブル情報を切り替えることで、適切な配席が行われるようになる。以下では、1つのテーブル情報に含まれる卓シンボルに対して予約情報の配席を行う配席処理について、図8を参照しながら説明するが、他のテーブル情報に対しても同様の配席処理が行われる。
【0063】
図8を参照すると、配席処理の流れの一例がフローチャートで示されている。図示のように、配席サーバ100の通信部103が予約情報を受信したと制御部101により判断されると(S101,Yes)、制御部101は、受信した予約情報と、第1のテーブル群に属する卓シンボルの1つとを相互に関連付ける(S102)。
【0064】
このS102において、制御部101は、第1のテーブル群に属する卓シンボルのうちいずれの予約情報とも関連付けられていないものの中で、最も卓ポイントの高いものを、受信した予約情報と関連付ける。関連付けられた卓シンボルは、「予約が埋まった」テーブルとみなせる。
【0065】
次に、制御部101は、第1のテーブル群に予約を入れることのできる、関連付けられていない卓シンボルがあるか否かを判定する(S103)。S101からS103までの繰り返し処理は、第1のテーブル群に関連付けがなされていない卓シンボルが一つもなくなるまで、続けられる。すなわち、第1のテーブル群に予約を入れる空きがなくなると(S103,No)、S101からS103までの繰り返し処理を抜ける。
【0066】
S104以後は、第1のテーブル群に属するすべての卓シンボルに予約情報が関連付けられている。S101と同様に、配席サーバ100の通信部103が予約情報を受信したと制御部101により判断されると(S104,Yes)、制御部101は、既存の予約情報と卓シンボルとの関連付けをいったん解除する(S105)。
【0067】
次に、制御部101は、予約情報の優先度を算出する(S106)。ここでいう「予約情報の優先度」は、当該予約の人数、予測される客単価、予約時間、予測される滞在時間、過去のサービス利用態様の中から選ばれる少なくとも1以上に基づいて算出される。予約の人数、予測される客単価、予約時間、予測される滞在時間、過去のサービス利用態様は、予約情報そのものか、あるいは予約情報に含まれる顧客識別情報と店舗識別情報に基づいて、制御部101が決定ないし算出する。
【0068】
制御部101が実行する客単価などの予想は、過去のユーザの利用履歴やユーザを含む利用者全体の利用履歴を用いて、教師あり機械学習を行う方法など、種々の方法で実行することが可能である。
【0069】
過去のサービス利用態様の具体例としては、例えば、「得意客である/ない」のような客の属性も含まれる。そのほかには例えば、一月あたりの利用頻度といった情報も含まれる。例外的な客の属性、利用頻度などの過去のサービス利用態様に係る情報は、図3(a)に示された「顧客の基本情報」に含まれるようにして、カスタマーデータベース510に格納されていてもよい。
【0070】
S106における優先度の算出の対象となる予約情報は、まだ算出していない予約情報だけを対象に行ってもよい。
【0071】
次に、制御部101は、第2のテーブル群に属する卓シンボルのうち1つを第1のテーブル群に属するよう、分類を変更する(S107)。このとき制御部101は、第2のテーブル群に属する卓シンボルのうち、卓ポイントが最も低い卓シンボルを選択して、第1のテーブル群に属するように分類を変更してもよい。
【0072】
次に、制御部101は、S105で関連付けの外れた予約情報と、S107で数の増えた第1のテーブル群に属する卓シンボルとを関連付けする(S108)。このとき、制御部101は、S106で算出した予約情報の優先度が高いものから順に、卓ポイントの高い卓シンボルに関連付けていく。
【0073】
制御部101は、予約キャンセルや、予約時間が到来してサービスの提供が終わった場合に、予約情報と卓シンボルとの関連付けを解消する。図8中には示されていないが、S104からS108のループ中のどの時点であっても、このような場合が発生すると、制御部101は、予約情報と卓シンボルとの解消処理を実行する。
【0074】
<出力処理>
出力部104は、卓シンボルと予約情報との関連付けを随時、出力する。したがって、出力部104は、予約キャンセルが発生して、卓シンボルと予約情報との関連付けが解消された場合や、図8のS105からS108までの処理が行われて卓シンボルと予約情報との関連付けが変更になった場合でも、変更後の関連付けを随時出力する。出力先は、店舗端末300の表示部304が好ましい。図9に出力部104による表示部304への表示出力態様の一例を示す。
【0075】
<満席時の処理>
制御部101は、図8のS104で、受信部103が新たな予約情報を受信したとき、そのことによって受信した予約情報の総数が、第1のテーブル群に属する卓シンボルの個数と第2のテーブル群に属する卓シンボルの個数を合わせた個数と同じになれば、満席と判断する。例えば、図6のように、第1のテーブル群に属する卓シンボルの個数と第2のテーブル群に属する卓シンボルの個数を合わせた個数が4個であれば、制御部101はS104で合計4つの予約情報が受信された場合に、満席と判断する。
【0076】
図10を参照すると、満席時の処理手順がフローチャートにより示されている。図10に示された手順は、図8のS104とS105の間に挿入される。図示のように、制御部101は、まず、テーブル情報を参照して関連付けされていない卓シンボルがあるか、判断する(S201)。ある場合は(S201,Yes)、本処理を終了してS105に移る。
【0077】
関連付けされていない卓シンボルがないと判断される場合(S201,No)、制御部101は、卓シンボルの分割をするか否かを判断する(S202)。図4(c)に示したように、卓シンボルは、複数の物理的テーブル(卓IDが付与されるテーブル)から構成されるものがある。図4(c)中の例で言えば、例えば、図中bbaaやbbacの卓シンボルIDを持つ卓シンボルがそれに該当する。制御部101は、このような卓シンボルの分割をするかないかを、S202において判断する。この判断は、制御部101が、テーブル情報中に分割可能のフラグが付与されている卓シンボルがあるか否かを判断するなどして、行う。フラグの付与は、事前に店舗端末300により行われる。
【0078】
卓シンボルの分割をしないと判断される場合(S202,No)、制御部101は、満席と判断する(S203)。他方、卓シンボルの分割をすると判断される場合(S202,Yes)、制御部101は、卓シンボルの分割処理を実行した上で(S204)、S105に遷移する。
【0079】
卓シンボルの分割処理は、制御部101が分割対象の卓シンボルを、2つの卓シンボルに、分割後のそれぞれの卓シンボルが少なくとも一つの卓IDを有するように分割し、分割後の卓シンボルにそれぞれ卓シンボルIDを付与することで行われる。分割対象の卓シンボルは、テーブル情報に分割可能のフラグが付与されているものから1つが選ばれる。
【0080】
分割対象の卓シンボルが店舗端末300から指定されるよう構成してもよい。この場合、受信部103は、テーブル情報中の1の卓シンボルを指定して分割する分割コマンドを受信する。受信部103が分割コマンドを受信すると、制御部101は、その分割コマンドにより指定された1の卓シンボルを2つの卓シンボルに分割し、分割後の2つの卓シンボルを含むようにテーブル情報を更新する。更新後のテーブル情報は、店舗データベース520に格納する。
【0081】
<変形例>
本発明は上述の実施形態にのみ限定されるものではなく、本開示の要旨を逸脱しない範囲内において種々変更され得る。
【0082】
上述の実施形態においては、図6のようにテーブル情報が1つの場合の例を説明したが、本発明はそれに限定されず、他の実施形態においては図11に示すように複数のテーブル情報を有するように構成されてもよい。この場合、図11のように各卓シンボルが、来店グループの規模に対応した異なるテーブル情報に分類されるように構成されてもよい。すなわち、記憶部102は、複数のテーブル情報(第1のテーブル群及び第2のテーブル群の情報)を記憶する。複数のテーブル情報は、利用可能な人数の最大数が異なる。
【0083】
このような予約受付システム1において、通信部103が予約情報を受信すると、制御部101は予約情報に含まれるグループの人数の情報に応じて、図11に示したような複数のテーブル情報のうち、いずれかのテーブル情報を選択する。次に、選択したテーブル情報を用いて、図8を参照しながら説明したような処理を行う。このように構成すれば、来店人数の点で多様なグループに対して効率よく配席の予約をすることが可能になる。換言すれば、適切な配席をすることが可能になる。
【0084】
また、上述の実施形態においては、予約受付システム1が配席サーバ100を有し、配席サーバの制御部101が上述の配席処理、出力処理、満席時の処理といった各処理を実行する構成が開示された。しかしながら、上記実施形態において制御部101が担った役割を店舗端末300の制御部が担うこととしてもよい。この場合、上述の実施形態における配席サーバ100を省略することができ、各店舗端末300がそれぞれ配席処理を行う構成とすることができる。各店舗端末300の独立性が高まるという効果がある。なお、この場合、各店舗端末300がそれぞれカスタマーデータベース510を有する構成としてもよい。
【0085】
<変形例2>
上述の実施形態においては、配席処理の一例として、第1のテーブル群に予約を入れることのできる限り、制御部101が予約情報を、先着順に、卓ポイントの高い卓シンボルに関連付けていく実施例が開示された(図8、S101〜S103)。しかしながら、この実施例を変形して、制御部101が、第1のテーブル群に予約を入れることのできるときに、予約情報を、単に先着順に、卓ポイントの高い卓シンボルに関連付けるのではなく、予約情報の優先度に基づいて、卓ポイントの高い卓シンボルに関連付けてもよい。
【0086】
この場合、予約情報の優先度は、図8のS106についての処理の説明にて述べたように、例えば、当該予約情報に係る人数、予想客単価、予約時間、予想滞在時間、過去のサービス利用態様から選ばれる少なくとも1以上に基づいて算出される優先度が一例として挙げられる。ここで言う過去のサービス利用態様もS106についての処理の説明にて述べたように、「得意客や常連客である/ない」などの情報や、サービスの利用頻度が一例として挙げられる。つまり、予約情報の優先度は、予約情報に基づいて制御部101により算出される。
【0087】
したがって、この場合、制御部101は、第1のテーブル群に予約の入れることのできる限り、予約情報に基づいて(より詳細には予約情報に基づいて算出される優先度に基づいて)、暫定的に、受信した予約情報を卓ポイントの高い卓シンボルに関連付ける。
【0088】
言うまでもなく、この変形実施例は、以上に述べた構成を除く部分の構成については、上述の実施形態において開示した構成のすべてを取り込む。この変形実施例は、第1のテーブル群に予約を入れることのできる限り、すなわち、残席数に余裕がある場合においても、予約情報に基づいて、CS(Customer Satisfaction)を提供すべき相手に対して条件の良い席に案内することによって、CSを向上させることができる。
【0089】
<変形例3>
予約情報について補足する。
上述の実施形態においては、予約情報の一例として、図7を例示し、予約情報は少なくとも、顧客識別情報、予約人数、予約日時、店舗識別情報を含む情報であるとした。また、その生成の一例として、ユーザ端末200上で実行されるブラウザやアプリケーションを介して生成される例を説明した。しかしながら、予約情報の生成は、上述の実施形態で述べた例に限られない。店舗端末300が予約情報を生成してもよい。
【0090】
例えば、ウォークイン客が自分で操作する店舗端末300を店舗の入口に設置し、ウォークイン客自身に人数と顧客識別情報を入力させてもよい。この場合、店舗端末300は、予約日時に現在時間を、店舗識別情報に自店舗の識別情報を自動的に補完し、配席サーバ100に予約情報を送信する。なお、この場合、店舗端末300は例えばタブレット端末を採用してもよい。また、ウォークイン客による顧客識別情報の店舗端末300への入力は、顔認証による顧客識別や、顧客識別情報を特定可能な情報を含む非接触型ICカードの読み取りなど、当業者にとってよく知られた種々の技術を利用してもよい。
【0091】
その他に、例えば、従業員が店舗端末300に手入力で、ウォークイン客の人数など、いくつかの情報を入力することによって、店舗端末300が予約情報の生成に必要な情報が補完されてもよい。
なお、このように、予約情報がウォークイン客の来店と同時に生成される場合は、予約日時がすぐに到来するので、図8の配席処理は速やかに実行されることが好ましい。
【0092】
この変形実施例においては、上述の実施形態においてユーザ端末200で予約情報が生成される場合に代えて、店舗端末300で予約情報が生成される場合を開示した。このように、「予約情報」には、ウォークイン客が利用する席を速やかに決めるためのテーブル使用要求の概念も含まれる。換言すると、「予約情報」には、ウォークイン客のケースのように、ほとんど間を空けずにサービスの提供を受けることを予約する情報も含まれる。
【0093】
<変形例4>
上述の実施形態や変形例においては、予約受付状況が切り替わる前の状況で予約客のために用意しておくテーブルの個数が2以上であるものとしている。これらの記載はテーブルの個数が1である場合を除外する意図はなく、テーブルの個数が1である場合でも上述の実施形態や変形例に開示した作用効果が得られる。なお、予約受付状況が切り替わった後の状況で予約客のために用意しておくテーブルの個数が1である場合も同様である。
【符号の説明】
【0094】
1…予約受付システム
100…配席サーバ
101…制御部
102…記憶部
103…通信部
104…出力部
200…ユーザ端末
203…通信部
204…表示部
205…入力部
300…店舗端末
302…記憶部
303…通信部
304…表示部
305…入力部
510…カスタマーデータベース
520…店舗データベース
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11