(57)【要約】      （修正有）【課題】予約受付を行う情報処理装置において、予約受付状況に応じて適切な配席を行う情報処理装置を提供する。【解決手段】店舗において、ユーザーを適切なテーブルに案内するための予約受付システム１であって、配席サーバ１００の記憶部１０２は、順序付けられた第１のテーブル群と、これに空きがない場合に利用される第２のテーブル群の情報を記憶する。制御部１０１は、予約情報を受信すると予約情報に基づいて、受信した予約情報を第１のテーブル群の高順位のテーブルから順に関連付ける。予約情報を関連付けられるテーブルが第１のテーブル群の中にない場合に、既存の複数の予約情報の関連付けを解除し、予約情報に基づいて優先度を算出する。また、第２のテーブル群から少なくとも１つのテーブルを第１のテーブル群に含ませた上で、算出した優先度に基づいて予約情報と第１のテーブル群とを関連付ける。【選択図】図１
2020013596.tif 000002
【特許請求の範囲】
【請求項１】
１人以上の人がテーブルで提供を受けるサービスの予約を受け付ける情報処理装置であって、
１人以上の人を含むグループが前記サービスの提供を受けることを予約する予約情報を受信する受信部と、
前記サービスの提供に利用される、順序付けられた第１のテーブル群と、前記第１のテーブル群に空きがある非混雑時には使用されず予備として扱われ前記第１のテーブル群に空きがない混雑時に使用される第２のテーブル群の情報を記憶する記憶部と、
前記受信部が前記予約情報を受信すると、受信した前記予約情報に基づいて、受信した前記予約情報を前記第１のテーブル群の各順位のテーブルに関連付け、
前記予約情報を関連付けられるテーブルが前記第１のテーブル群の中にない場合に、既存の複数の前記予約情報の関連付けを解除し、
前記予約情報を予約した前記グループに前記サービスを提供する優先度を、前記予約情報に基づいて、受信した複数の前記予約情報それぞれについて算出し、
前記第２のテーブル群から少なくとも１つのテーブルを前記第１のテーブル群に含ませた上で、算出した前記優先度に基づいて、前記予約情報を前記第１のテーブル群の高順位のテーブルから順に一対一対応で関連付ける
制御部と、
前記予約情報に関連付けられたテーブルの情報を前記予約情報と併せて出力する出力部
を具備する
情報処理装置。
【請求項２】
請求項１に記載の情報処理装置であって、
前記制御部は、前記予約情報から取得する人数、客単価、予約時間、滞在時間、過去のサービス利用態様の中から選ばれる少なくとも１以上に基づいて、当該予約情報に含まれる前記優先度を算出する
情報処理装置。
【請求項３】
請求項１又は２に記載の情報処理装置であって、
前記制御部は、前記第１のテーブル群と前記第２のテーブル群を合わせたテーブル数と同数のグループの前記予約情報を前記受信部が受信した場合に、満席と判断する
情報処理装置。
【請求項４】
請求項１から３のいずれか１項に記載の情報処理装置であって、
前記記憶部は、利用可能な人数の最大数が異なる前記第１のテーブル群及び前記第２のテーブル群の情報を複数記憶し、
前記受信部は、前記グループの人数を含む前記予約情報を受信し、
前記制御部は、前記受信部が受信した前記予約情報に含まれる人数に応じて、複数の前記第１のテーブル群及び前記第２のテーブルの情報のうち、いずれかを選択し、選択した前記第１のテーブル群及び前記第２のテーブルの情報に含まれる前記第１のテーブル群のいずれかのテーブルに、受信した前記予約情報を関連付ける
情報処理装置。
【請求項５】
請求項１から４のいずれか１項に記載の情報処理装置であって、
前記受信部は、前記第１のテーブル群及び前記第２のテーブル群に含まれる１のテーブルを指定して分割する分割コマンドを受信し、
前記制御部は、前記分割コマンドにより指定された前記１のテーブルを２つのテーブルに分割し、分割後の２つのテーブルを含むように前記第１のテーブル群及び前記第２のテーブルの情報を更新し、前記記憶部に記憶させる
情報処理装置。
【請求項６】
１人以上の人がテーブルで提供を受けるサービスの予約を受け付ける情報処理装置であって、
１人以上の人を含むグループが前記サービスの提供を受けることを予約する予約情報を受信する受信部と、
前記サービスの提供に利用される、順序付けられた第１のテーブル群と、前記第１のテーブル群に空きがない場合に前記サービスの提供に利用され、前記第１のテーブル群に属するテーブルよりも順位が上のテーブルからなる第２のテーブル群の情報を記憶する記憶部と、
前記受信部が前記予約情報を受信すると、受信した前記予約情報に基づいて、受信した前記予約情報を前記第１のテーブル群の各順位のテーブルに関連付け、
前記予約情報を関連付けられるテーブルが前記第１のテーブル群の中にない場合に、既存の複数の前記予約情報の関連付けを解除し、
前記予約情報を予約した前記グループに前記サービスを提供する優先度を、前記予約情報に基づいて、受信した複数の前記予約情報それぞれについて算出し、
前記第２のテーブル群から少なくとも１つのテーブルを前記第１のテーブル群に含ませた上で、算出した前記優先度に基づいて、前記予約情報を前記第１のテーブル群の高順位のテーブルから順に一対一対応で関連付ける
制御部と、
前記予約情報に関連付けられたテーブルの情報を前記予約情報と併せて出力する出力部
を具備する
情報処理装置。
【請求項７】
１人以上の人がテーブルで提供を受けるサービスの提供に利用される、順序付けられた第１のテーブル群と、前記第１のテーブル群に空きがある非混雑時には使用されず予備として扱われ前記第１のテーブル群に空きがない混雑時に使用される第２のテーブル群の情報を記憶する記憶部を具備する情報処理装置が実行する制御方法であって、
１人以上の人を含むグループが前記サービスの提供を受けることを予約する予約情報を受信するステップと、
前記受信するステップにて前記予約情報が受信されると、受信した前記予約情報に基づいて、受信した前記予約情報を前記第１のテーブル群の各順位のテーブルに関連付けるステップと、
前記予約情報を関連付けられるテーブルが前記第１のテーブル群の中にない場合に、既存の複数の前記予約情報の関連付けを解除するステップと、
前記予約情報を予約した前記グループに前記サービスを提供する優先度を、前記予約情報に基づいて、受信した複数の前記予約情報それぞれについて算出するステップと、
前記第２のテーブル群から１つのテーブルを前記第１のテーブル群に含ませた上で、算出した前記優先度に基づいて、前記予約情報を前記第１のテーブル群の高順位のテーブルから順に一対一対応で関連付けるステップと、
前記予約情報に関連付けられたテーブルの情報を前記予約情報と併せて出力するステップ
を含む
情報処理装置の制御方法。
【請求項８】
１人以上の人がテーブルで提供を受けるサービスの提供に利用される、順序付けられた第１のテーブル群と、前記第１のテーブル群に空きがない場合に前記サービスの提供に利用され、前記第１のテーブル群に属するテーブルよりも順位が上のテーブルからなる第２のテーブル群の情報を記憶する記憶部を具備する情報処理装置が実行する制御方法であって、
１人以上の人を含むグループが前記サービスの提供を受けることを予約する予約情報を受信するステップと、
前記受信するステップにて前記予約情報を受信されると、受信した前記予約情報に基づいて、受信した前記予約情報を前記第１のテーブル群の各順位のテーブルに関連付けるステップと、
前記予約情報を関連付けられるテーブルが前記第１のテーブル群の中にない場合に、既存の複数の前記予約情報の関連付けを解除するステップと、
前記予約情報を予約した前記グループに前記サービスを提供する優先度を、前記予約情報に基づいて、受信した複数の前記予約情報それぞれについて算出するステップと、
前記第２のテーブル群から少なくとも１つのテーブルを前記第１のテーブル群に含ませた上で、算出した前記優先度に基づいて、前記予約情報を前記第１のテーブル群の高順位のテーブルから順に一対一対応で関連付けるステップと、
前記予約情報に関連付けられたテーブルの情報を前記予約情報と併せて出力するステップ
を含む
情報処理装置の制御方法。
【請求項９】
１人以上の人が卓で提供を受けるサービスの提供に利用される、順序付けられた第１のテーブル群と、前記第１のテーブル群に空きがある非混雑時には使用されず予備として扱われ前記第１のテーブル群に空きがない混雑時に使用される第２のテーブル群の情報を記憶する記憶部を具備する情報処理装置に、
１人以上の人を含むグループが前記サービスの提供を受ける優先度を含む、前記グループの前記サービスの提供を受けることを予約する予約情報を受信するステップと、
前記受信するステップにて前記予約情報が受信されると、受信した前記予約情報に基づいて、受信した前記予約情報を前記第１のテーブル群の各順位のテーブルに関連付けるステップと、
前記予約情報を関連付けられるテーブルが前記第１のテーブル群の中にない場合に、既存の複数の前記予約情報の関連付けを解除するステップと、
前記予約情報を予約した前記グループに前記サービスを提供する優先度を、前記予約情報に基づいて、受信した複数の前記予約情報それぞれについて算出するステップと、
前記第２のテーブル群から１つのテーブルを前記第１のテーブル群に含ませた上で、算出した前記優先度に基づいて、前記予約情報を前記第１のテーブル群の高順位のテーブルから順に一対一対応で関連付けるステップと、
前記予約情報に関連付けられたテーブルの情報を前記予約情報と併せて出力するステップ
を実行させる
情報処理装置の制御プログラム。
【請求項１０】
１人以上の人がテーブルで提供を受けるサービスの提供に利用される、順序付けられた第１のテーブル群と、前記第１のテーブル群に空きがない場合に前記サービスの提供に利用され、前記第１のテーブル群に属するテーブルよりも順位が上のテーブルからなる第２のテーブル群の情報を記憶する記憶部を具備する情報処理装置に、
１人以上の人を含むグループが前記サービスの提供を受けることを予約する予約情報を受信するステップと、
前記受信するステップにて前記予約情報を受信されると、受信した前記予約情報に基づいて、受信した前記予約情報を前記第１のテーブル群の各順位のテーブルに関連付けるステップと、
前記予約情報を関連付けられるテーブルが前記第１のテーブル群の中にない場合に、既存の複数の前記予約情報の関連付けを解除するステップと、
前記予約情報を予約した前記グループに前記サービスを提供する優先度を、前記予約情報に基づいて、受信した複数の前記予約情報それぞれについて算出するステップと、
前記第２のテーブル群から少なくとも１つのテーブルを前記第１のテーブル群に含ませた上で、算出した前記優先度に基づいて、前記予約情報を前記第１のテーブル群の高順位のテーブルから順に一対一対応で関連付けるステップと、
前記予約情報に関連付けられたテーブルの情報を前記予約情報と併せて出力するステップ
を実行させる
情報処理装置の制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、情報処理装置、その制御方法及びプログラムに関する。
【背景技術】
【０００２】
飲食店などが提供する飲食物提供サービスを受けることを予約する情報システムの先行例としては、例えば特許文献１に記載の技術などがある。特許文献１には、可搬型通信端末からユーザ識別情報と共に人数や来店時間などの情報を含んだ施設利用予約を受信して、空席を確認し、予約を入れる技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−１５３４０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に記載の技術によれば、単にユーザが空席のある店舗に予約を入れることは可能になるものの、店舗側でユーザを適切なテーブル（卓）に案内することまでは可能にならない。
【０００５】
ユーザを適切なテーブルに案内することは、元来、熟練とノウハウが必要である。飲食店の店舗に来るユーザは、可能であれば広めのテーブル、出入り口や厨房への通路などから遠くて落ち着くテーブルを好む。ユーザの希望に応えることはカスタマー・サティスファクションに通じるが、来店客数が増えてくると条件の劣るテーブルに案内する必要も出てくる。店舗の案内係は、店の混み具合に応じて、ユーザをゆとりのある席から順に案内する「条件の良い席に先着順」の配席方法から、可能な限り多くのユーザにサービスを提供することを目的にした「配席効率優先」の配席方法に切り替えていく必要がある。
【０００６】
サーバコンピュータとクライアント端末などを組み合わせた飲食店の予約システムにおいて配席を可能にすることを考慮した場合、上述のような、店舗の混み具合に応じて「条件の良い席に先着順」から「配席効率優先」への切り替えの問題を技術的に解決する必要がある。
【０００７】
店舗では来店客のグループ規模に応じて案内するテーブルを分けていることがある。例えば、４人から６人までのグループ向けのテーブル群と、２人から４人までのグループ向けのテーブル群とを用意し、グループの規模に応じ案内するテーブルを振り分けている。しかしながら、この運用を上述のような予約システムにおける配席アルゴリズムで実行しようとすると、後から来たグループが先に到着していたグループよりも良い席に案内されて不公平感が生まれる可能性がある。
【０００８】
具体的には例えば、２人グループが「条件の良い席に先着順」に案内された結果、２人から４人までのグループ向けのテーブル群のストックが枯渇してしまい、その次に来た２人グループが、２人から４人までのグループ向けのテーブル群よりもキャパシティが大きい（すなわち、条件のより良い）４人から６人までのグループ向けのテーブル群に属するテーブルに案内されてしまう、ないし、案内せざるを得ない状況が生まれる。この観点からも、店舗の混み具合に応じて「条件の良い席に先着順」から「配席効率優先」への切り替えが要請される。
【０００９】
以上のような事情に鑑み、本技術の目的は、予約受付を行う情報処理装置において、予約受付状況に応じて適切な配席を行うことにある。
【課題を解決するための手段】
【００１０】
上記目的を達成する本発明の一側面としての情報処理装置は、１人以上の人がテーブルで提供を受けるサービスの予約を受け付ける情報処理装置であって、受信部と、記憶部と、制御部と、出力部を具備する。
上記受信部は、１人以上の人を含むグループが上記サービスの提供を受けることを予約する予約情報を受信する。
上記記憶部は、上記サービスの提供に利用される、順序付けられた第１のテーブル群と、上記第１のテーブル群に空きがない場合に上記サービスの提供に利用され、上記第１のテーブル群に属するテーブルよりも順位が上のテーブルからなる第２のテーブル群の情報を記憶する。
上記制御部は、上記受信部により上記予約情報が受信されると、上記第１のテーブル群に属するテーブルへ一対一対応の関連付けが可能である限り、上記予約情報を上記第１のテーブル群の高順位のテーブルから順に関連付ける。
また、上記制御部は、上記予約情報を関連付けられるテーブルが上記第１のテーブル群の中にない場合に、既存の複数の上記予約情報の関連付けを解除する。
また、上記制御部は、上記予約情報を予約した上記グループに上記サービスを提供する優先度を、上記予約情報に基づいて、受信した複数の上記予約情報それぞれについて算出する。
また、上記制御部は、上記第２のテーブル群から少なくとも１つのテーブルを上記第１のテーブル群に含ませた上で、算出した上記優先度に基づいて、上記予約情報を上記第１のテーブル群の高順位のテーブルから順に一対一対応で関連付ける。
上記出力部は、上記予約情報に関連付けられたテーブルの情報を上記予約情報と併せて出力する。
【００１１】
上記情報処理装置によれば、客グループを第１のテーブル群に属するテーブルに関連付けられる間（＝店が比較的空いている間）は予約順に関連付けられるので、先着順に広くよい席に案内することができる一方で、第１のテーブル群に属するテーブルに関連付けられなくなったとき（＝予約が多いとき）は予備のテーブル（本来もっと人数の多い客向けにキープしておきたい席など）を第１のテーブル群に含ませた上で、客グループの優先度に基づいて関連付けるので、席効率優先で配席することができる。
また、人数の多い客にも対応できるような広い席が、あとから予約を入れたグループに対して配席されることをなくすことができる。これにより不公平感を客に抱かせる可能性を低減できる。
また、上記制御部を有する情報処理装置が、従来、複数の店舗において別々に処理される配席処理を一括して行うことができるので、複数の店舗それぞれに高性能な計算機を備える必要がなくなり、計算機資源の節約になるという効果もある。
【００１２】
上記制御部は、上記予約情報から取得する人数、客単価、予約時間、滞在時間、過去のサービス利用態様の中から選ばれる少なくとも１以上に基づいて、当該予約情報に含まれる上記優先度を算出してもよい。
【００１３】
上記制御部がこのように優先度を算出することで、過去に店舗に売り上げをもたらしたユーザの履歴が考慮され、店舗とユーザ双方の満足度を高めることができる。
【００１４】
上記制御部は、上記第１のテーブル群と上記第２のテーブル群を合わせたテーブル数と同数のグループの上記予約情報を上記受信部が受信した場合に、満席と判断してもよい。
【００１５】
上記制御部がこのように満席の判断を行うことで、予約の受付に上限を設けることができ、店舗とユーザ双方の満足度を高めることができる。
【００１６】
上記記憶部は、利用可能な人数の最大数が異なる上記第１のテーブル群及び上記第２のテーブル群の情報を複数記憶し、上記受信部は、上記グループの人数を含む上記予約情報を受信してもよい。
この場合、上記制御部は、上記受信部が受信した上記予約情報に含まれる人数に応じて、複数の上記第１のテーブル群及び上記第２のテーブルの情報のうち、いずれかを選択し、選択した上記第１のテーブル群及び上記第２のテーブルの情報に含まれる上記第１のテーブル群のいずれかのテーブルに、受信した上記予約情報を関連付けてもよい。
【００１７】
上記制御部がこのように予約情報に含まれる人数に応じて、上記第１のテーブル群及び上記第２のテーブル群の情報を切り替えることで、適切な配席が行われるようになる。
【００１８】
上記受信部は、上記第１のテーブル群及び上記第２のテーブル群に含まれる１のテーブルを指定して分割する分割コマンドを受信してもよい。
この場合、上記制御部は、上記分割コマンドにより指定された上記１のテーブルを２つのテーブルに分割し、分割後の２つのテーブルを含むように上記第１のテーブル群及び上記第２のテーブルの情報を更新し、上記記憶部に記憶させてもよい。
【００１９】
上記制御部がこのように上記第１のテーブル群及び上記第２のテーブルの情報を更新することで、テーブルの分割を行うことが可能になり、店舗はより多くのユーザにサービスを提供することができるようになる。
【００２０】
上記目的を達成する本発明の別の一側面は、受信部と、記憶部と、制御部と、出力部を具備する情報処理装置である。
上記情報処理装置は、１人以上の人がテーブルで提供を受けるサービスの予約を受け付ける。
上記受信部は、１人以上の人を含むグループが上記サービスの提供を受けることを予約する予約情報を受信する。
上記記憶部は、上記サービスの提供に利用される、順序付けられた第１のテーブル群と、上記第１のテーブル群に空きがない場合に上記サービスの提供に利用され、上記第１のテーブル群に属するテーブルよりも順位が上のテーブルからなる第２のテーブル群の情報を記憶する。
上記制御部は、上記受信部が上記予約情報を受信すると、上記予約情報に基づいて、受信した上記予約情報を上記第１のテーブル群の高順位のテーブルから順に関連付ける。
また、上記制御部は、上記予約情報を関連付けられるテーブルが上記第１のテーブル群の中にない場合に、既存の複数の上記予約情報の関連付けを解除する。
また、上記制御部は、上記予約情報を予約した上記グループに上記サービスを提供する優先度を、上記予約情報に基づいて、受信した複数の上記予約情報それぞれについて算出する。
また、上記制御部は、上記第２のテーブル群から少なくとも１つのテーブルを上記第１のテーブル群に含ませた上で、算出した上記優先度に基づいて、上記予約情報を上記第１のテーブル群の高順位のテーブルから順に一対一対応で関連付ける。
上記出力部は、上記予約情報に関連付けられたテーブルの情報を上記予約情報と併せて出力する。
【００２１】
上記目的を達成する本発明の別の一側面は、１人以上の人がテーブルで提供を受けるサービスの提供に利用される、順序付けられた第１のテーブル群と、上記第１のテーブル群に空きがない場合に上記サービスの提供に利用され、上記第１のテーブル群に属するテーブルよりも順位が上のテーブルからなる第２のテーブル群の情報を記憶する記憶部を具備する情報処理装置が実行する制御方法である。
上記情報処理装置の制御方法は、以下の各ステップを含む。
・１人以上の人を含むグループが上記サービスの提供を受けることを予約する予約情報を受信するステップ。
・上記受信するステップにて上記予約情報が受信されると、上記第１のテーブル群に属するテーブルへ一対一対応の関連付けが可能である限り、上記予約情報を上記第１のテーブル群の高順位のテーブルから順に関連付けるステップ。
・上記予約情報を関連付けられるテーブルが上記第１のテーブル群の中にない場合に、既存の複数の上記予約情報の関連付けを解除するステップ。
・上記予約情報を予約した上記グループに上記サービスを提供する優先度を、上記予約情報に基づいて、受信した複数の上記予約情報それぞれについて算出するステップ。
・上記第２のテーブル群から１つのテーブルを上記第１のテーブル群に含ませた上で、算出した上記優先度に基づいて、上記予約情報を上記第１のテーブル群の高順位のテーブルから順に一対一対応で関連付けるステップ。
・上記予約情報に関連付けられたテーブルの情報を上記予約情報と併せて出力するステップ。
【００２２】
上記目的を達成する本発明の別の一側面は、１人以上の人が卓で提供を受けるサービスの提供に利用される、順序付けられた第１のテーブル群と、上記第１のテーブル群に空きがない場合に上記サービスの提供に利用され、上記第１のテーブル群に属するテーブルよりも順位が上のテーブルからなる第２のテーブル群の情報を記憶する記憶部を具備する情報処理装置に、以下のステップを実行させるプログラムである。
・１人以上の人を含むグループが上記サービスの提供を受ける優先度を含む、上記グループの上記サービスの提供を受けることを予約する予約情報を受信するステップ。
・上記受信するステップにて上記予約情報が受信されると、上記第１のテーブル群に属するテーブルへ一対一対応の関連付けが可能である限り、上記予約情報を上記第１のテーブル群の高順位のテーブルから順に関連付けるステップ。
・上記予約情報を関連付けられるテーブルが上記第１のテーブル群の中にない場合に、既存の複数の上記予約情報の関連付けを解除するステップ。
・上記予約情報を予約した上記グループに上記サービスを提供する優先度を、上記予約情報に基づいて、受信した複数の上記予約情報それぞれについて算出するステップ。
・上記第２のテーブル群から１つのテーブルを上記第１のテーブル群に含ませた上で、算出した上記優先度に基づいて、上記予約情報を上記第１のテーブル群の高順位のテーブルから順に一対一対応で関連付けるステップ。
・上記予約情報に関連付けられたテーブルの情報を上記予約情報と併せて出力するステップ。
【発明の効果】
【００２３】
以上のように、本技術によれば、予約受付を行う情報処理装置において、予約受付状況に応じて適切な配席を行うことができる。
【図面の簡単な説明】
【００２４】
【図１】本技術の実施形態に係る予約受付システム構成例を示す図である。
【図２】上記実施形態における記憶部に記憶されている情報を示す図である。
【図３】上記実施形態におけるユーザ情報の構成を説明するための図である。
【図４】上記実施形態における店舗情報の構成を説明するための図である。
【図５】上記実施形態におけるテーブル情報の構成を説明するための図である。
【図６】上記テーブル情報に含まれる卓シンボルの分類を説明するための図である。
【図７】上記実施形態における予約情報の構成を説明するための図である。
【図８】上記実施形態における配席処理の流れを示すフローチャートである。
【図９】上記実施形態における店舗端末への表示出力態様の一例を示す図である。
【図１０】上記実施形態における満席時の処理の流れを示すフローチャートである。
【図１１】上記テーブル情報に含まれる卓シンボルの分類を説明するための図である。
【発明を実施するための形態】
【００２５】
以下、本技術に係る実施形態を、図面を参照しながら説明する。なお、説明は以下の順番で行うものとする。
１．予約受付システムの構成
２．予約受付システムの概略動作
３．ユーザ情報の構成
４．店舗情報の構成
５．予約情報の構成及び生成
６．配席処理
７．出力処理
８．満席時の処理
９．複数のテーブル情報
【００２６】
＜予約受付システムの構成＞
図１を参照すると、本実施形態に係る予約受付システム１の構成例が示されている。図示のように、本実施形態に係る予約受付システム１は、配席サーバ１００、ユーザ端末２００、店舗端末３００がネットワーク４００を介して相互に通信可能に接続した情報通信システムである。
【００２７】
配席サーバ１００は、店舗端末３００に対応する各店舗において、例えば飲食サービスのように、テーブルで客にサービスが提供される際の客の配席処理を制御するサーバコンピュータであり、制御部１０１、記憶部１０２、通信部１０３、出力部１０４を備える。制御部１０１は例えば中央演算装置（Central Processing Unit）などで構成することができ、配席サーバ１００の演算及び制御を行う物理デバイスとして構成することができる。記憶部１０２は例えば物理的にはハードディスクドライブなど不揮発性の記憶デバイスで構成することができる。通信部１０３は例えばローカルエリアネットワークへのインタフェイスデバイスなどで構成することができる。
【００２８】
上記配席サーバ１００は、例えば、飲食店に関する情報を掲載したポータルサイトを運営する飲食店情報提供サーバであってもよい。この場合、配席サーバ１００は、上記ポータルサイトにおいて、ユーザ端末２００のユーザ向けに飲食店情報の検索システムを提供するとともに、飲食店の予約受付システムを提供する。具体的には、配席サーバ１００は、ユーザ端末２００からの検索要求に基づいて検索条件に合致する飲食店情報を検索し、検索結果を掲載したＷｅｂページを生成してユーザ端末２００へ送信し、ユーザの予約要求に基づいて、いずれかの飲食店情報に対応する飲食店に対する利用予約を受け付ける。
【００２９】
出力部１０４は制御部１０１の情報処理結果を出力する機能を備える論理的な機能ブロックである。具体的な一例として、出力部１０４はディスプレイデバイスなど表示出力可能なデバイスで構成されてもよい。あるいは、出力部１０４が店舗端末３００やユーザ端末２００に対して、上記通信部１０３によりネットワーク４００を介して情報処理結果を出力するウェブサーバで構成されてもよい。
【００３０】
ユーザ端末２００は、通信部２０３、表示部２０４、入力部２０５を備える。ユーザ端末２００は可搬性のある情報通信端末（スマートフォンなど）として構成されてもよい。通信部２０３は例えばモバイルデータ通信可能な通信デバイスなどで構成することができる。表示部２０４はユーザ端末２００の情報処理結果や配席サーバ１００の出力部１０４などから出力された情報などをユーザに対して表示する機能を備える。表示部２０４は液晶タッチパネルなどで構成されてもよい。入力部２０５はユーザ端末２００のユーザの操作入力をユーザ端末２００に入力する機能を備える。入力部２０５は例えば液晶タッチパネルなどで構成されてもよい。
【００３１】
店舗端末３００は、例えば飲食店等、テーブルでサービスを提供する店舗が有する端末であり、記憶部３０２、通信部３０３、表示部３０４、入力部３０５を備える。店舗端末３００は可搬性のある情報通信端末（スマートフォンなど）あるいは据え置き型のパーソナルコンピュータとして構成されてもよい。記憶部３０２は例えば物理的にはハードディスクドライブや半導体メモリなど不揮発性の記憶デバイスで構成することができる。通信部３０３は例えばローカルエリアネットワークへのインタフェイスデバイスなどで構成することができる。表示部３０４は店舗端末３００の情報処理結果や配席サーバ１００の出力部１０４などから出力された情報などをユーザに対して表示する機能を備える。表示部３０４は液晶タッチパネルなどで構成されてもよい。入力部３０５は店舗端末３００のユーザの操作入力を店舗端末３００に入力する機能を備える。入力部３０５は例えば液晶タッチパネルなどで構成されてもよい。
【００３２】
ネットワーク４００は、配席サーバ１００、ユーザ端末２００、店舗端末３００を相互に通信可能にする通信ネットワークである。ネットワーク４００は、例えば、インターネットやモバイルデータ通信ネットワークなどが複合的に組み合わさって構成されてもよい。
【００３３】
本実施形態に係る予約受付システム１には、１以上複数のユーザ端末２００が含まれてもよく、１以上複数の店舗端末３００が含まれてもよい。
【００３４】
＜予約受付システムのデータベースの概略＞
予約受付システム１は、ユーザ端末２００からサービスの提供を受けることの予約を受け付けて、予約された店舗における配席を行い、配席結果を店舗端末３００に送出する情報処理を行う。ここで言う「サービス」とは１以上の座席が設定されたテーブルで提供を受けるサービスを指し、例えば、飲食店における飲食サービスがその典型として挙げられるが、飲食サービスに限定する必要はない。
【００３５】
予約受付システム１には、上記情報処理を行うために、店舗情報があらかじめ記憶されている必要がある。また、予約受付システム１にはユーザ端末２００や店舗端末３００から予約情報が入力される必要がある。その他に、必須ではないが、予約受付システム１にユーザ情報があらかじめ記憶されていてもよい。
【００３６】
図２を参照すると本実施形態における記憶部１０２及び／又は記憶部３０２にあらかじめ記憶されている情報が示されている。図示のように、カスタマーデータベース５１０と店舗データベース５２０が記憶されている。これらの記憶先は配席サーバ１００と店舗端末３００のどちらでもよい。カスタマーデータベース５１０は１以上のユーザ情報を記憶する。店舗データベース５２０は１以上の店舗情報を記憶する。
【００３７】
ユーザ情報は予約受付システム１の１人のユーザに関する情報であって、ユーザ端末２００を使用するユーザに関する情報である。店舗情報は店舗端末３００が設置されている店舗に関する情報である。以下、ユーザ情報、店舗情報、予約情報のそれぞれについてこの順番に説明する。
【００３８】
＜ユーザ情報の構成＞
カスタマーデータベース５１０は例えばリレーショナルデータベースとして構成することができ、図３に示すようなユーザ情報をユーザごとに記憶している。図３を参照すると本実施形態におけるユーザ情報を説明するための概念図が示されている。図３（ａ）にはユーザ情報における「顧客の基本情報」が、図３（ｂ）にはユーザ情報における「来店履歴」が示されている。
【００３９】
予約受付システム１のユーザの基本情報は、図３（ａ）に示すように、顧客識別情報、来店人数の中央値、客単価の中央値などを「ユーザ」ごとに有する情報としてカスタマーデータベース５１０に格納される。来店人数の中央値、客単価の中央値は来店履歴から算出してもよい。
【００４０】
予約受付システム１のユーザの来店履歴は、図３（ｂ）に示すように、来店日時、滞在時間、グループでの来店人数、支払いした総額などを「店舗（又は店舗ＩＤ）」ごとに有する情報としてカスタマーデータベース５１０に格納される。来店履歴に係る情報テーブルには店舗識別情報が含まれている。店舗は当該店舗識別情報から特定可能である。
【００４１】
＜店舗情報の構成＞
店舗データベース５２０も例えばリレーショナルデータベースとして構成することができ、図４に示すような店舗情報を店舗ごとに記憶している。図４を参照すると本実施形態における店舗情報を説明するための概念図が示されている。図４（ａ）には店舗情報における「店舗の基本情報」が、図４（ｂ）には店舗情報における「テーブル基本情報」が、図４（ｃ）には店舗情報における「テーブル情報」が示されている。
【００４２】
店舗の基本情報は、図４（ａ）に示すように、店舗識別情報、その店舗のサービスの種類（ジャンル）、営業時間などを「店舗」ごとに有する情報として店舗データベース５２０に格納される。店舗の基本情報としてはこのほかに店舗の所在する位置情報や住所などを含んでも良い。サービスの種類（ジャンル）としては、「フレンチレストラン」、「和食レストラン」など提供する料理による分類のほか、「居酒屋」など業態による分類でもよい。
【００４３】
店舗のテーブル基本情報は、図４（ｂ）に示すように、店舗が備えるテーブル（卓）の卓ＩＤ、席数、連結可能な卓、卓ポイントなどを「テーブル」ごとに有する情報として店舗データベース５２０に格納される。ここで、卓ＩＤはテーブルを識別するための情報、席数はそのテーブルに着座可能な最大人数（定員、キャパシティ）である。連結可能な卓は自己を含まない他のテーブルの卓ＩＤが指定される情報である。隣にあるテーブルの卓ＩＤなどが指定される。卓ポイントはそのテーブルの快適さの度合いを示す指標である。
【００４４】
卓ポイントはそのテーブルがユーザ（来店客）にとって快適なテーブルであれば高いポイントが、混雑時以外は避けたいテーブルであれば低いポイントが付与される。例えば、店舗内の奥まった場所にあるような上席には高いポイントが付与される。出入り口に近い場所などにあるテーブルは低いポイントが付与される。卓ポイントの付与は店舗のオーナーや従業員が行う。卓ポイントを自動的に付与しても良い。
【００４５】
テーブル基本情報において、卓ＩＤが付与されるテーブルは、これ以上のテーブルの分割が不可能な（又は好ましくない）最小単位とする。卓ＩＤが付与されるテーブルは、物理的に１個のテーブルとしてもよい。
【００４６】
店舗のテーブル情報は、図４（ｃ）に示すように、卓シンボルＩＤ、席数、構成する卓ＩＤ、卓ポイントなどを「卓シンボル」ごとに有する情報として店舗データベース５２０に格納される。テーブル情報は、テーブル基本情報に基づいて生成される。「卓シンボル」は１以上の「卓ＩＤが付与されたテーブル」により構成された論理的なテーブルである。予約受付システム１は、「卓シンボル」を、来店した１グループに対して１つ割り当てる（配席する）。
【００４７】
図４（ｃ）に示されている「卓シンボル」は、図４（ｂ）に列挙した卓を用いて生成された「卓シンボル」の一例にすぎない。卓の組み合わせによっては図４（ｃ）に示された例とは異なる卓シンボルが生成されうる。また、図４（ｂ）に示したようなテーブル基本情報から、複数のテーブル情報が生成されてもよい。
【００４８】
図５を参照すると店舗レイアウトの一例が示されている。図中、矩形はテーブルを示し、円形は座席を示す。矩形のテーブルは卓ＩＤが付与されるテーブルであって、図４のテーブル基本情報における１エントリに相当する。図中破線で囲まれた１つ又は複数のテーブルは、各々、「卓シンボル」を表し、図４のテーブル情報における１エントリに相当する。図５中に示した卓ＩＤや卓シンボルＩＤは図４の卓ＩＤや卓シンボルＩＤに合わせている。
【００４９】
店舗のテーブル情報における、ある卓シンボルの席数は、図４（ｃ）と図５に示すように、その卓シンボルを構成する卓の席数を単純加算したデータとすることができる。
【００５０】
店舗のテーブル情報における、ある卓シンボルを構成する卓の卓ＩＤは、図４（ｃ）と図５に示すように、テーブル基本情報に含まれる卓ＩＤを１つ以上複数含むデータとすることができる。このデータは例えば、図５に示すように隣り合うテーブルなどの卓ＩＤを含むデータとなる。
【００５１】
店舗のテーブル情報における、ある卓シンボルの卓ポイントは、その卓シンボルの快適さの度合いを示す指標である。卓シンボルの卓ポイントの設定方法に限定はなく、例えば、その卓シンボルを構成する卓の卓ポイントを加算して算出される値としてもよい。あるいは、その卓シンボルを構成する卓の卓ポイントの算術平均としてもよい。
【００５２】
図６を参照すると、図４（ｃ）に示したテーブル情報が複数、各テーブル情報に含まれる卓シンボルの分類と共に示されている。店舗データベース５２０は、各店舗ごとに、１以上複数のテーブル情報を格納する。図６には、対象人数の異なるテーブル情報が３つ示されている。
【００５３】
なお、対象人数は、テーブル情報が含む卓シンボルの中で、最も席数（図４（ｃ）に示す「席数」）が少ない卓シンボルの席数にあわせる。例えば、図４（ｃ）のテーブル情報の例では、卓シンボルＩＤがｂｂａｂの卓シンボルの席数が最小の２であるから、当該テーブル情報は、図６中の「テーブル情報１」のように２人以下向けとする。テーブル情報１の中には、４人まで着座可能な卓シンボルが含まれるが、それらも含めてすべて、２人以下向けの卓シンボルとなる。
【００５４】
各テーブル情報は、テーブル情報に含まれる卓シンボルを少なくとも２種に分類する情報も含む。１種目の卓シンボル群を第１のテーブル群、２種目の卓シンボル群を第２のテーブル群と呼ぶ。なお、卓シンボルは第３のテーブル群、第４の・・・とさらに分類されてもよいが、本実施形態において２種を超える分類については扱わない。
【００５５】
第１のテーブル群は、店舗が比較的混雑していない状態のときに、来店客に案内されるテーブル（卓シンボルとしてまとめられている１以上複数の卓ＩＤが付与されたテーブルのまとまりを指す）の集合である。第２のテーブル群は、店舗が比較的混雑していない状態のときに、予備のテーブルとしてストックされているが、店舗が混雑している状態では使用され得るテーブルの集合である。
【００５６】
以上に説明したような店舗情報が、店舗ごとに店舗データベース５２０に格納されている。なお、店舗のテーブル情報は、動的に生成される情報であってもよい。
【００５７】
＜予約情報の構成及び生成＞
図７（ａ）を参照すると、予約情報の構成の一例が示されている。図示のように、予約情報は少なくとも、顧客識別情報、予約人数、予約日時、店舗識別情報を含む情報である。図７（ｂ）を参照するとユーザ端末２００の表示部２０４に表示されるユーザインタフェイス画面の一例が示されている。
【００５８】
ユーザ端末２００は、図７（ｂ）に示すような画面を用いてユーザ端末２００のユーザに予約人数、予約日時の入力を促し、顧客識別情報と店舗識別情報と共に、配席サーバ１００に送信する。当該画面は、配席サーバ１００が生成したＷｅｂページとしてユーザ端末２００のブラウザ上で実行されてもよいし、ユーザ端末２００にインストールされた店舗検索・予約用のアプリケーション上で実行されてもよい。なお、図７（ｂ）のようなダイアログに顧客識別情報と店舗識別情報を埋め込むことや、このようなダイアログから入力された情報に基づいて、図７（ａ）に示すような予約情報を生成することについては、当業者に良く知られているＷｅｂアプリケーション技術を利用することができる。
【００５９】
＜配席処理＞
配席サーバ１００が、ユーザ端末２００から送出された予約情報を受信すると、配席サーバ１００の制御部１０１により予約処理と配席処理が実行される。予約情報に含まれる店舗識別情報により特定される店舗に、予約情報に含まれる顧客識別情報により特定されるユーザの予約を入れる予約処理については、当業者に良く知られている技術を利用することができる。
【００６０】
以下、その予約処理に続いて（あるいは予約処理中に）配席サーバ１００により実行される配席処理について述べる。配席処理の具体的な流れについては種々の方法があり、以下ではその一例について述べる。
【００６１】
本実施形態の配席処理においては、まず、受信部１０３が予約情報を受信した際に、制御部１０１は予約情報に含まれる人数をチェックする。次に、制御部１０１は、予約情報の人数に応じて、複数のテーブル情報のうち、いずれかを選択する。例えば、４人の予約であれば、「テーブル情報２」が選択される。図６を参照しながら述べたように、店舗データベース５２０は、対象人数が異なるテーブル情報を複数記憶している。
【００６２】
上記制御部がこのように予約情報に含まれる人数に応じて、テーブル情報を切り替えることで、適切な配席が行われるようになる。以下では、１つのテーブル情報に含まれる卓シンボルに対して予約情報の配席を行う配席処理について、図８を参照しながら説明するが、他のテーブル情報に対しても同様の配席処理が行われる。
【００６３】
図８を参照すると、配席処理の流れの一例がフローチャートで示されている。図示のように、配席サーバ１００の通信部１０３が予約情報を受信したと制御部１０１により判断されると（Ｓ１０１，Ｙｅｓ）、制御部１０１は、受信した予約情報と、第１のテーブル群に属する卓シンボルの１つとを相互に関連付ける（Ｓ１０２）。
【００６４】
このＳ１０２において、制御部１０１は、第１のテーブル群に属する卓シンボルのうちいずれの予約情報とも関連付けられていないものの中で、最も卓ポイントの高いものを、受信した予約情報と関連付ける。関連付けられた卓シンボルは、「予約が埋まった」テーブルとみなせる。
【００６５】
次に、制御部１０１は、第１のテーブル群に予約を入れることのできる、関連付けられていない卓シンボルがあるか否かを判定する（Ｓ１０３）。Ｓ１０１からＳ１０３までの繰り返し処理は、第１のテーブル群に関連付けがなされていない卓シンボルが一つもなくなるまで、続けられる。すなわち、第１のテーブル群に予約を入れる空きがなくなると（Ｓ１０３，Ｎｏ）、Ｓ１０１からＳ１０３までの繰り返し処理を抜ける。
【００６６】
Ｓ１０４以後は、第１のテーブル群に属するすべての卓シンボルに予約情報が関連付けられている。Ｓ１０１と同様に、配席サーバ１００の通信部１０３が予約情報を受信したと制御部１０１により判断されると（Ｓ１０４，Ｙｅｓ）、制御部１０１は、既存の予約情報と卓シンボルとの関連付けをいったん解除する（Ｓ１０５）。
【００６７】
次に、制御部１０１は、予約情報の優先度を算出する（Ｓ１０６）。ここでいう「予約情報の優先度」は、当該予約の人数、予測される客単価、予約時間、予測される滞在時間、過去のサービス利用態様の中から選ばれる少なくとも１以上に基づいて算出される。予約の人数、予測される客単価、予約時間、予測される滞在時間、過去のサービス利用態様は、予約情報そのものか、あるいは予約情報に含まれる顧客識別情報と店舗識別情報に基づいて、制御部１０１が決定ないし算出する。
【００６８】
制御部１０１が実行する客単価などの予想は、過去のユーザの利用履歴やユーザを含む利用者全体の利用履歴を用いて、教師あり機械学習を行う方法など、種々の方法で実行することが可能である。
【００６９】
過去のサービス利用態様の具体例としては、例えば、「得意客である／ない」のような客の属性も含まれる。そのほかには例えば、一月あたりの利用頻度といった情報も含まれる。例外的な客の属性、利用頻度などの過去のサービス利用態様に係る情報は、図３（ａ）に示された「顧客の基本情報」に含まれるようにして、カスタマーデータベース５１０に格納されていてもよい。
【００７０】
Ｓ１０６における優先度の算出の対象となる予約情報は、まだ算出していない予約情報だけを対象に行ってもよい。
【００７１】
次に、制御部１０１は、第２のテーブル群に属する卓シンボルのうち１つを第１のテーブル群に属するよう、分類を変更する（Ｓ１０７）。このとき制御部１０１は、第２のテーブル群に属する卓シンボルのうち、卓ポイントが最も低い卓シンボルを選択して、第１のテーブル群に属するように分類を変更してもよい。
【００７２】
次に、制御部１０１は、Ｓ１０５で関連付けの外れた予約情報と、Ｓ１０７で数の増えた第１のテーブル群に属する卓シンボルとを関連付けする（Ｓ１０８）。このとき、制御部１０１は、Ｓ１０６で算出した予約情報の優先度が高いものから順に、卓ポイントの高い卓シンボルに関連付けていく。
【００７３】
制御部１０１は、予約キャンセルや、予約時間が到来してサービスの提供が終わった場合に、予約情報と卓シンボルとの関連付けを解消する。図８中には示されていないが、Ｓ１０４からＳ１０８のループ中のどの時点であっても、このような場合が発生すると、制御部１０１は、予約情報と卓シンボルとの解消処理を実行する。
【００７４】
＜出力処理＞
出力部１０４は、卓シンボルと予約情報との関連付けを随時、出力する。したがって、出力部１０４は、予約キャンセルが発生して、卓シンボルと予約情報との関連付けが解消された場合や、図８のＳ１０５からＳ１０８までの処理が行われて卓シンボルと予約情報との関連付けが変更になった場合でも、変更後の関連付けを随時出力する。出力先は、店舗端末３００の表示部３０４が好ましい。図９に出力部１０４による表示部３０４への表示出力態様の一例を示す。
【００７５】
＜満席時の処理＞
制御部１０１は、図８のＳ１０４で、受信部１０３が新たな予約情報を受信したとき、そのことによって受信した予約情報の総数が、第１のテーブル群に属する卓シンボルの個数と第２のテーブル群に属する卓シンボルの個数を合わせた個数と同じになれば、満席と判断する。例えば、図６のように、第１のテーブル群に属する卓シンボルの個数と第２のテーブル群に属する卓シンボルの個数を合わせた個数が４個であれば、制御部１０１はＳ１０４で合計４つの予約情報が受信された場合に、満席と判断する。
【００７６】
図１０を参照すると、満席時の処理手順がフローチャートにより示されている。図１０に示された手順は、図８のＳ１０４とＳ１０５の間に挿入される。図示のように、制御部１０１は、まず、テーブル情報を参照して関連付けされていない卓シンボルがあるか、判断する（Ｓ２０１）。ある場合は（Ｓ２０１，Ｙｅｓ）、本処理を終了してＳ１０５に移る。
【００７７】
関連付けされていない卓シンボルがないと判断される場合（Ｓ２０１，Ｎｏ）、制御部１０１は、卓シンボルの分割をするか否かを判断する（Ｓ２０２）。図４（ｃ）に示したように、卓シンボルは、複数の物理的テーブル（卓ＩＤが付与されるテーブル）から構成されるものがある。図４（ｃ）中の例で言えば、例えば、図中ｂｂａａやｂｂａｃの卓シンボルＩＤを持つ卓シンボルがそれに該当する。制御部１０１は、このような卓シンボルの分割をするかないかを、Ｓ２０２において判断する。この判断は、制御部１０１が、テーブル情報中に分割可能のフラグが付与されている卓シンボルがあるか否かを判断するなどして、行う。フラグの付与は、事前に店舗端末３００により行われる。
【００７８】
卓シンボルの分割をしないと判断される場合（Ｓ２０２，Ｎｏ）、制御部１０１は、満席と判断する（Ｓ２０３）。他方、卓シンボルの分割をすると判断される場合（Ｓ２０２，Ｙｅｓ）、制御部１０１は、卓シンボルの分割処理を実行した上で（Ｓ２０４）、Ｓ１０５に遷移する。
【００７９】
卓シンボルの分割処理は、制御部１０１が分割対象の卓シンボルを、２つの卓シンボルに、分割後のそれぞれの卓シンボルが少なくとも一つの卓ＩＤを有するように分割し、分割後の卓シンボルにそれぞれ卓シンボルＩＤを付与することで行われる。分割対象の卓シンボルは、テーブル情報に分割可能のフラグが付与されているものから１つが選ばれる。
【００８０】
分割対象の卓シンボルが店舗端末３００から指定されるよう構成してもよい。この場合、受信部１０３は、テーブル情報中の１の卓シンボルを指定して分割する分割コマンドを受信する。受信部１０３が分割コマンドを受信すると、制御部１０１は、その分割コマンドにより指定された１の卓シンボルを２つの卓シンボルに分割し、分割後の２つの卓シンボルを含むようにテーブル情報を更新する。更新後のテーブル情報は、店舗データベース５２０に格納する。
【００８１】
＜変形例＞
本発明は上述の実施形態にのみ限定されるものではなく、本開示の要旨を逸脱しない範囲内において種々変更され得る。
【００８２】
上述の実施形態においては、図６のようにテーブル情報が１つの場合の例を説明したが、本発明はそれに限定されず、他の実施形態においては図１１に示すように複数のテーブル情報を有するように構成されてもよい。この場合、図１１のように各卓シンボルが、来店グループの規模に対応した異なるテーブル情報に分類されるように構成されてもよい。すなわち、記憶部１０２は、複数のテーブル情報（第１のテーブル群及び第２のテーブル群の情報）を記憶する。複数のテーブル情報は、利用可能な人数の最大数が異なる。
【００８３】
このような予約受付システム１において、通信部１０３が予約情報を受信すると、制御部１０１は予約情報に含まれるグループの人数の情報に応じて、図１１に示したような複数のテーブル情報のうち、いずれかのテーブル情報を選択する。次に、選択したテーブル情報を用いて、図８を参照しながら説明したような処理を行う。このように構成すれば、来店人数の点で多様なグループに対して効率よく配席の予約をすることが可能になる。換言すれば、適切な配席をすることが可能になる。
【００８４】
また、上述の実施形態においては、予約受付システム１が配席サーバ１００を有し、配席サーバの制御部１０１が上述の配席処理、出力処理、満席時の処理といった各処理を実行する構成が開示された。しかしながら、上記実施形態において制御部１０１が担った役割を店舗端末３００の制御部が担うこととしてもよい。この場合、上述の実施形態における配席サーバ１００を省略することができ、各店舗端末３００がそれぞれ配席処理を行う構成とすることができる。各店舗端末３００の独立性が高まるという効果がある。なお、この場合、各店舗端末３００がそれぞれカスタマーデータベース５１０を有する構成としてもよい。
【００８５】
＜変形例２＞
上述の実施形態においては、配席処理の一例として、第１のテーブル群に予約を入れることのできる限り、制御部１０１が予約情報を、先着順に、卓ポイントの高い卓シンボルに関連付けていく実施例が開示された（図８、Ｓ１０１〜Ｓ１０３）。しかしながら、この実施例を変形して、制御部１０１が、第１のテーブル群に予約を入れることのできるときに、予約情報を、単に先着順に、卓ポイントの高い卓シンボルに関連付けるのではなく、予約情報の優先度に基づいて、卓ポイントの高い卓シンボルに関連付けてもよい。
【００８６】
この場合、予約情報の優先度は、図８のＳ１０６についての処理の説明にて述べたように、例えば、当該予約情報に係る人数、予想客単価、予約時間、予想滞在時間、過去のサービス利用態様から選ばれる少なくとも１以上に基づいて算出される優先度が一例として挙げられる。ここで言う過去のサービス利用態様もＳ１０６についての処理の説明にて述べたように、「得意客や常連客である／ない」などの情報や、サービスの利用頻度が一例として挙げられる。つまり、予約情報の優先度は、予約情報に基づいて制御部１０１により算出される。
【００８７】
したがって、この場合、制御部１０１は、第１のテーブル群に予約の入れることのできる限り、予約情報に基づいて（より詳細には予約情報に基づいて算出される優先度に基づいて）、暫定的に、受信した予約情報を卓ポイントの高い卓シンボルに関連付ける。
【００８８】
言うまでもなく、この変形実施例は、以上に述べた構成を除く部分の構成については、上述の実施形態において開示した構成のすべてを取り込む。この変形実施例は、第１のテーブル群に予約を入れることのできる限り、すなわち、残席数に余裕がある場合においても、予約情報に基づいて、ＣＳ（Customer Satisfaction）を提供すべき相手に対して条件の良い席に案内することによって、ＣＳを向上させることができる。
【００８９】
＜変形例３＞
予約情報について補足する。
上述の実施形態においては、予約情報の一例として、図７を例示し、予約情報は少なくとも、顧客識別情報、予約人数、予約日時、店舗識別情報を含む情報であるとした。また、その生成の一例として、ユーザ端末２００上で実行されるブラウザやアプリケーションを介して生成される例を説明した。しかしながら、予約情報の生成は、上述の実施形態で述べた例に限られない。店舗端末３００が予約情報を生成してもよい。
【００９０】
例えば、ウォークイン客が自分で操作する店舗端末３００を店舗の入口に設置し、ウォークイン客自身に人数と顧客識別情報を入力させてもよい。この場合、店舗端末３００は、予約日時に現在時間を、店舗識別情報に自店舗の識別情報を自動的に補完し、配席サーバ１００に予約情報を送信する。なお、この場合、店舗端末３００は例えばタブレット端末を採用してもよい。また、ウォークイン客による顧客識別情報の店舗端末３００への入力は、顔認証による顧客識別や、顧客識別情報を特定可能な情報を含む非接触型ＩＣカードの読み取りなど、当業者にとってよく知られた種々の技術を利用してもよい。
【００９１】
その他に、例えば、従業員が店舗端末３００に手入力で、ウォークイン客の人数など、いくつかの情報を入力することによって、店舗端末３００が予約情報の生成に必要な情報が補完されてもよい。
なお、このように、予約情報がウォークイン客の来店と同時に生成される場合は、予約日時がすぐに到来するので、図８の配席処理は速やかに実行されることが好ましい。
【００９２】
この変形実施例においては、上述の実施形態においてユーザ端末２００で予約情報が生成される場合に代えて、店舗端末３００で予約情報が生成される場合を開示した。このように、「予約情報」には、ウォークイン客が利用する席を速やかに決めるためのテーブル使用要求の概念も含まれる。換言すると、「予約情報」には、ウォークイン客のケースのように、ほとんど間を空けずにサービスの提供を受けることを予約する情報も含まれる。
【００９３】
＜変形例４＞
上述の実施形態や変形例においては、予約受付状況が切り替わる前の状況で予約客のために用意しておくテーブルの個数が２以上であるものとしている。これらの記載はテーブルの個数が１である場合を除外する意図はなく、テーブルの個数が１である場合でも上述の実施形態や変形例に開示した作用効果が得られる。なお、予約受付状況が切り替わった後の状況で予約客のために用意しておくテーブルの個数が１である場合も同様である。
【符号の説明】
【００９４】
１…予約受付システム
１００…配席サーバ
１０１…制御部
１０２…記憶部
１０３…通信部
１０４…出力部
２００…ユーザ端末
２０３…通信部
２０４…表示部
２０５…入力部
３００…店舗端末
３０２…記憶部
３０３…通信部
３０４…表示部
３０５…入力部
５１０…カスタマーデータベース
５２０…店舗データベース
【図１】
2020013596.tif 000003
【図２】
2020013596.tif 000004
【図３】
2020013596.tif 000005
【図４】
2020013596.tif 000006
【図５】
2020013596.tif 000007
【図６】
2020013596.tif 000008
【図７】
2020013596.tif 000009
【図８】
2020013596.tif 000010
【図９】
2020013596.tif 000011
【図１０】
2020013596.tif 000012
【図１１】
2020013596.tif 000013