JP7274176B2 - 店舗管理補助システムおよびサーバ - Google Patents

Description

本発明は、例えば飲食店などの店舗における店舗管理補助システムおよびサーバ等に関するものである。

飲食店などの店舗においては、入店予約、注文受付、調理管理等のような管理業務が発生する。これらの管理業務は情報処理システムによる補助が可能であり、店舗の省人化に寄与する。

一方で、近年、スマートフォンやタブレットなどの個人端末（ユーザ端末）が普及しており、ユーザ端末の処理能力も高い。したがって、ユーザ端末はネットワークを介して情報処理システムのインターフェイスとして機能する。これにより顧客利便性を確保できる。

例えば、特許文献１ではユーザ端末を用いてレストランの予約が可能である。また、特許文献２ではユーザ端末を用いて料理の注文が可能である。

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

上記のような従来システムを参考に、本願発明者は、各技術を相互に生かし合う様に組み合わせることにより、店舗管理者、ユーザ(店舗顧客)、厨房担当者、店舗従業員各々にとって利便性の高いシステムを簡易に構築することを検討した。

本発明は、上記課題を解決するものであり、入店予約、注文受付、調理管理等のような管理業務を補助する店舗管理補助システムを提供することを目的とする。

上記課題を解決する本発明の店舗管理補助システムは、店舗店頭に提示されている店舗コードと、前記店舗コードを読み取り可能なユーザ端末と、前記ユーザ端末とネットワークを介して接続されるサーバと、を備える。前記サーバは、前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する接続要求受付部と、前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する入店待ち状況管理部と、前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する予約部と、を有する。

顧客は、顧客所有のユーザ端末を操作して、予約を完結できる。さらに、入店待ち状況を顧客所有のユーザ端末にて把握できるため、店舗店頭から離れることができる。顧客は待ち時間を有効に使うことができる。

上記発明において、好ましくは、前記サーバは、前記予約完了情報を送信したユーザ端末に対し、メニュー情報を送信するメニュー提示部と、前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、を有する。

顧客は、待ち時間を利用して、入店前に注文できる。料理人は事前に注文予測ができるため、作業性が向上する。

上記発明において、好ましくは、上記記載の店舗管理補助システムは、ネットワークを介してサーバと接続される厨房端末を備える。前記サーバは、前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、前記厨房端末から、調理開始情報を受信する調理開始管理部と、を有する。

注文情報と入店確認情報の双方により調理許可となる。調理許可後、厨房側の判断で、調理を開始できる。

上記課題を解決する本発明の店舗管理補助システムは、ユーザ端末と、厨房端末と、前記ユーザ端末および厨房端末とネットワークを介して接続されるサーバと、を備える。前記サーバは、前記ユーザ端末に対し、メニュー情報を送信するメニュー提示部と、前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、前記厨房端末から、調理開始情報を受信する調理開始管理部と、を有する。

顧客は顧客所有のユーザ端末を操作して注文できる。注文情報と入店確認情報の双方により調理許可となる。調理許可後、厨房側の判断で、調理を開始できる。

上記発明において、好ましくは、前記サーバは、前記ユーザ端末に対し、キャンセル可能な状態で、調理待ち情報を提示する調理待ち情報管理部と、前記メニュー情報を送信したユーザ端末から、注文キャンセル情報を受信し、注文をキャンセルする注文キャンセル部と、前記調理開始情報に基づいて、前記ユーザ端末に対し、キャンセル不可な状態で、調理中情報を提示する調理中情報管理部と、を有する。

調理開始時に契約成立とみなす。すなわち、調理開始前であればキャンセル可能であるが、調理開始後はキャンセル不可となる。

上記発明において、好ましくは、前記サーバは、前記厨房端末から、調理完了情報を受信し、前記ユーザ端末に調理完了情報を送信する調理完了管理部と、を有する。

顧客は、顧客所有のユーザ端末により注文した料理が提供されることを確認できる。

上記課題を解決する本発明のサーバは、店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末とネットワークを介して接続される。前記サーバは、前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する接続要求受付部と、前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する入店待ち状況管理部と、前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する予約部と、を有する。

顧客は、顧客所有のユーザ端末を操作して、予約を完結できる。さらに、入店待ち状況を顧客所有のユーザ端末にて把握できるため、店舗店頭から離れることができる。顧客は待ち時間を有効に使うことができる。

上記課題を解決する本発明のサーバは、ユーザ端末と、厨房端末と、ネットワークを介して接続される。前記サーバは、前記ユーザ端末に対し、メニュー情報を送信するメニュー提示部と、前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、前記厨房端末から、調理開始情報を受信する調理開始管理部と、を有する。

顧客は顧客所有のユーザ端末を操作して注文できる。注文情報と入店確認情報の双方により調理許可となる。調理許可後、厨房側の判断で、調理を開始できる。

上記課題を解決する本発明の予約管理方法では、サーバを用いる。サーバは店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末とネットワークを介して接続される。サーバは、前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信し、前記接続要求のあったユーザ端末に対し、入店待ち情報を送信し、前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する。

顧客は、顧客所有のユーザ端末を操作して、予約を完結できる。さらに、入店待ち状況を顧客所有のユーザ端末にて把握できるため、店舗店頭から離れることができる。顧客は待ち時間を有効に使うことができる。

上記課題を解決する本発明の注文管理方法では、サーバを用いる。サーバはユーザ端末と、厨房端末と、ネットワークを介して接続される。サーバは、前記ユーザ端末に対し、メニュー情報を送信し、前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信し、前記ユーザ端末の所有者が入店したか否かを確認する入店確認情報を受信し、前記厨房端末に対し、前記入店確認情報と前記注文情報とを含む調理許可情報を送信し、前記厨房端末から、調理開始情報を受信する。

顧客は顧客所有のユーザ端末を操作して注文できる。注文情報と入店確認情報の双方により調理許可となる。調理許可後、厨房側の判断で、調理を開始できる。

上記課題を解決する本発明のプログラムは、サーバに、前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する処理と、前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する処理と、前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する処理と、を実行させる。サーバは、店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末とネットワークを介して接続される。

顧客は、顧客所有のユーザ端末を操作して、予約を完結できる。さらに、入店待ち状況を顧客所有のユーザ端末にて把握できるため、店舗店頭から離れることができる。顧客は待ち時間を有効に使うことができる。

上記課題を解決する本発明のプログラムは、サーバに、前記ユーザ端末に対し、メニュー情報を送信する処理と、前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する処理と、前記ユーザ端末の所有者が入店したか否かを確認する入店確認情報を受信する処理と、前記厨房端末に対し、前記入店確認情報と前記注文情報とを含む調理許可情報を送信する処理と、前記厨房端末から、調理開始情報を受信する処理と、を実行させる。サーバは、ユーザ端末と、厨房端末と、ネットワークを介して接続される。

本発明のシステムは、飲食店などの店舗における入店予約、注文受付、調理管理等のような管理業務を補助し、店舗管理者、ユーザ(店舗顧客)、厨房料理人、店舗店員各々にとっての利便性を向上することができる。

本願システムの概略図 サーバの物理構成図 サーバの機能ブロック図 サーバの演算処理フロー図（動作１） システムのシーケンス図（動作１） サーバの演算処理フロー図（動作２） システムのシーケンス図（動作２） ユーザ端末画面（動作１） ユーザ端末画面（動作１） ユーザ端末画面（動作１） ユーザ端末画面（動作１） ユーザ端末画面（動作１） ユーザ端末画面（動作１） ユーザ端末画面（動作２） ユーザ端末画面（動作２） ユーザ端末画面（動作２） 厨房端末画面（動作２） 厨房端末画面（動作２） 厨房端末画面（動作２） 厨房端末画面（動作２） 店員端末画面（動作１） 店員端末画面（動作２）

～システム概略～
図１は本願システムの概略図である。本願システムは、飲食店などの店舗において、入店予約、注文受付、調理管理等のような管理業務を補助する。

本願システムはサーバ１０を主構成とする。サーバ１０はインターネット等の通信網を介してユーザ端末１、厨房端末２、店舗端末３と通信可能に接続している。通信は無線を原則とするが、例えば、サーバ－厨房端末間の通信は有線でも良い場合もある。

サーバ１０は、店舗に設置していてもよいし、店舗外において管理されていてもよい。サーバ１０は、単数又は複数のサーバ装置や記憶装置等を含んで構成されたサーバシステムである。

ユーザ端末１は、店舗を利用する顧客が所有するスマートフォンやタブレットなどの個人端末である。顧客は複数であり、各顧客はそれぞれユーザ端末１Ａ，１Ｂを有している。

厨房端末２は、厨房に設置されたタブレットまたは料理人が所有するスマートフォンである。別途、大型モニターを設置して、情報を表示してもよい。

店員端末３は、店舗で働く店員が携帯する端末である。市販のスマートフォンを利用してもよいし、店舗独自の携帯端末でもよい。

本願システムは、入店予約→注文受付の一連の流れ（動作１）と、注文受付→調理管理の一連の流れ（動作２）を補助する。

店舗店頭には店舗コード（例えば２次元バーコード）６が提示されている。

～サーバ構成～
図２はサーバ１０の物理構成図である。サーバ１０の各構成は、本願システムを制御する。サーバ１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、大容量記憶部１４、通信部１５、表示部１６、操作部１７などを備える演算処理装置である。物理構成１１～１７はバスを介して各々接続されている。

ＲＯＭ１２または大容量記憶部１４には、所定の動作プログラムが予め格納されている。動作プログラムはＣＰＵ１１にて実行され、所定の演算処理が実現される。

通信部１５はユーザ端末１、厨房端末２、店員端末３と通信する。

本願発明ではサーバ１０を操作することを前提としていないが、表示部１６、操作部１７を備えていてもよい。サーバ１０の動作状況を確認することができる。

図３はサーバ１０の機能ブロック図である。

機能構成２１～２６は、主に、入店予約→注文受付の一連の流れ（動作１）を実現する構成である。機能構成３１～３６は、主に、注文受付→調理管理の一連の流れ（動作２）を実現する構成である。ただし、機能構成２５，２６，３３等は両動作に共通する構成である。

まず、機能構成２１～２６について説明する。

接続要求受付部２１は、店舗コード６を読み取ったユーザ端末１から、接続要求情報を受信する。

入店待ち状況管理部２２は、接続要求のあったユーザ端末１に対し、入店待ち情報を送信する。たとえば、ユーザ端末１に入店待ち状況を示すユーザ端末画面１１１を表示する。

予約部２３は、接続要求のあったユーザ端末１に対し、ユーザ情報要求情報を送信し、ユーザ端末１から、ユーザ情報を受信し、ユーザ端末１に対し、予約完了情報を送信する。

ユーザ情報は、例えば、ユーザ固有のメールアドレスや携帯電話番号などである。たとえば、ユーザ端末１にユーザ情報入力を促すユーザ端末画面１１２を表示する。さらに、予約完了を通知するユーザ端末画面１１３を表示する。さらに、ユーザ端末画面１１３からユーザ端末画面１１５に遷移できる。

メニュー提示部２４は、予約完了情報を送信したユーザ端末１に対し、メニュー情報を送信する。たとえば、ユーザ端末１に料理メニューを選択可能に提示するユーザ端末画面１１４を表示する。

注文受付部２５は、メニュー情報を送信したユーザ端末１から、メニューから選択された注文情報を受信する。さらに、注文情報を調理待ち情報管理部３３に送信する。

入店確認部２６は、ユーザ端末１の所有者が入店したか否かを確認する。入店確認部２６の動作詳細については、別途詳述する。

次に、機能構成３１～３６について説明する。

調理許可部３１は、厨房端末２に対し、入店確認部２６による入店確認情報と注文受付部２５による注文情報とを含む調理許可情報を送信する。たとえば、厨房端末２の表示を厨房端末画面１２１→１２２のように変更する。

調理開始管理部３２は、厨房端末２から、調理開始情報を受信する。

調理待ち情報管理部３３は、ユーザ端末２に対し、キャンセル可能な状態で、調理待ち情報を提示する。たとえば、ユーザ端末１に調理待ち状況を示すユーザ端末画面１１７を表示する。また、厨房端末２に調理待ち状況を示す厨房端末画面１２１を表示する。

注文キャンセル部３４は、メニュー情報を送信したユーザ端末１から、注文キャンセル情報を受信し、注文をキャンセルする。

調理中情報管理部３５は、厨房端末画面１２３を介して厨房端末２から調理開始情報に基づいて、ユーザ端末１に対し、キャンセル不可な状態で、調理中情報を提示する。たとえば、ユーザ端末１の表示をユーザ端末画面１１７→１１８のように変更する。

調理完了管理部３６は、厨房端末画面１２４を介して厨房端末２から、調理完了情報を受信し、ユーザ端末１および店員端末３に調理完了情報を送信する。たとえば、ユーザ端末１に調理完了を通知するユーザ端末画面１１９を表示し、さらに、店員端末３に調理完了を通知する店員端末画面１３２を表示する。

各機能構成間の相互関係は、動作詳細として説明する。

～動作１～
図４は、入店予約→注文受付の一連の動作（動作１）に対応するサーバ１０における演算処理のフロー図である。図５は、動作１に対応するシステムのシーケンス図である。入店予約→注文受付について、システムの動作および、顧客、厨房の料理人、店舗の店員の動作について説明する。

飲食は嗜好性が高く、その時の気分（今日は和食を食べたい気分）に影響され、事前予約なしで来店することも多い。人気のある飲食店では、顧客が事前予約なしで来店しても待たされることも多い。

従来例では、店舗店頭に待ち行列をする、店舗店頭にある入店待ちリストに記名し、名前を呼ばれるのを待つ、店舗店頭にある発券機から順番券を発券するなどの対応をしている。しかしながら、いずれも待ち時間が発生する。本願システムは上記課題を以下のようにして解決できる。

本願システムでは、店舗店頭にインターネット接続先を意味する店舗コード６が提示されている。ユーザ端末１はカメラを有し、店舗コード６を読み取り可能である。

ユーザ端末１は店舗コード読み取り情報２０１を読み取り、サーバ１０に接続要求２０２を発信する。サーバ１０が接続要求２０２を受信すると、サーバ１０とユーザ端末１とは接続する（ステップ２１）。

サーバ１０は、複数のユーザ端末１Ａ，１Ｂから入店予約を受けており、入店順番を判断し、おおよその入店待ち時間を推測し、入店待ち情報２０３とする（ステップ２２）。

サーバ１０はユーザ端末１に入店待ち情報２０３を送信する。たとえば、ユーザ端末１に入店待ち状況を示すユーザ端末画面１１１を表示する（ステップ２３）。なお、併せて、入店待ち情報２０３を店頭モニターに表示してもよい。

顧客は、入店待ち情報を見て、ある程度の時間待ってでも入店するか、諦めて他の店を探すか考える。

サーバ１０はユーザ端末１にユーザ情報要求情報２０４を送信する。たとえば、ユーザ端末１にユーザ情報入力を促すユーザ端末画面１１２を表示する（ステップ２４）。

顧客は、ユーザ端末画面１１２を介して、ユーザを特定できる情報を入力する。例えば、ユーザ端末１に名前や電話番号（またはメールアドレス）を入力する。さらに、顧客を含む人数（大人・小人別）や喫煙の有無や席等の希望の有無を入力してもよい。

サーバ１０はユーザ端末１から、ユーザ情報２０５を受信する（ステップ２５）。

なお、ステップ２２→２３（入店待ち状況把握）の処理と、ステップ２４→２５（予約）の処理の順番を入れ替えてもよい。

サーバ１０はユーザ端末１に予約完了情報２０６を送信する。たとえば、ユーザ端末１に予約完了を通知するユーザ端末画面１１３を表示する（ステップ２６）。

顧客は、ユーザ端末１のユーザ端末画面１１３を見て、予約が完了したことを確認する。ユーザ端末画面１１３には、当該顧客の入店待ち情報が表示されている。

さらに、本願システムでは以下のように顧客は入店待ちの間に注文することができる。

サーバ１０はユーザ端末１にメニュー情報２０７を送信する。たとえば、ユーザ端末１に料理メニューを選択可能に提示するユーザ端末画面１１４を表示する（ステップ２７）。ユーザ端末画面１１３からユーザ端末画面１１４に遷移するようにしてもよい。

顧客は、ユーザ端末１のユーザ端末画面１１４を見ながら、所望の料理を注文する。例えば、当該選択項目を反転表示させ確定する。

サーバ１０はユーザ端末１からメニューから選択された注文情報２０８を受信する。さらに、注文情報２０８を厨房端末２に送信する（ステップ２８）。

サーバ１０はユーザ端末１に調理待ち情報３０１を送信する。たとえば、ユーザ端末１に調理待ち状況を示すユーザ端末画面１１７を表示する（動作２にて後述）。

顧客は、ユーザ端末１のユーザ端末画面１１７を見て、注文内容を確認する（動作２にて後述）。

なお、ステップ２６（予約完了確認）の処理は、ステップ２４→２５（予約）→ステップ２７→２８（注文）の処理の後におこなってもよい。この場合、予約完了確認には注文情報２０８が含まれる。

店舗コード６読み取り以降の顧客の動作は、店舗店頭から離れた場所からでもできる。例えば、店舗がデパートやショッピングモール内にある場合、予約から注文までの動作をデパートやショッピングモール内を散策しながら行なうことができる。顧客は時間を有効に使うことができる。すなわち、顧客利便性が高い。一方で、店員や料理人は特に対応することはなく、負担が少ない。料理人は事前に注文予測ができるため、作業性が向上する。入店前に注文が完了しているため顧客回転が速い。店舗管理者利便性が高い。

サーバ１０は複数の顧客の入店待ち状況を管理し、ユーザ端末１に入店待ち情報２０３を随時更新している（ステップ２３）。サーバ１０はユーザ端末１にリマインダ通知を送信してもよい。

顧客は、ユーザ端末画面１１３の入店待ち情報を見ながら、入店順番が近づいたと判断すると、店舗に再来店する。顧客は、予約済情報２０９に相当するユーザ端末画面１１５を店員に提示する。ユーザ端末画面１１５にはたとえば、２次元バーコードが含まれている。

店員は、店舗入口にて顧客対応し、カメラ付き店員端末３を介して、予約済情報２０９（例えば２次元バーコード）を読み取る。

サーバ１０は店員端末３から予約済情報２０９を受信する（ステップ２９）。

店舗の店員は顧客を座席まで誘導する。座席は座席識別情報２１０を有する。店員は顧客と座席を関連づける。例えば、店員が座席に付した２次元バーコードを読み取ってもよい。サーバ１０が座席使用状況を判断し、案内する座席を提示し、店員が案内完了を店員端末３の店員端末画面１３１を介して報告してもよい。動作１における店員動作は極めて少ない。店舗の省人化に寄与する。

更なる省人化として、店舗の店員に代えて、入店確認用の２次元バーコード読取装置を店舗入口に設置してもよい。

サーバ１０は店員端末３から座席識別情報２１０を受信する。さらに、座席識別情報２１０を厨房端末２に送信する（ステップ３０）。

座席識別情報２１０をユーザ端末１に送信してもよい。顧客はユーザ端末１のユーザ端末画面１１６に誘導され、当該座席に着席する。

サーバ１０は、予約済情報２０９を受信（ステップ２９）した時点で入店確認としてもよいし、座席識別情報２１０を受信（ステップ３０）した時点で入店確認としてもよい。すなわち、予約済情報２０９または座席識別情報２１０のいずれかを入店確認情報とみなす。

～動作２～
図６は、注文受付→調理管理の一連の動作（動作２）に対応するサーバ１０における演算処理のフロー図である。図７は、動作２に対応するシステムのシーケンス図である。注文受付→調理管理について、システムの動作および、顧客、厨房、店員の動作について説明する。

従来例では一般に、店員が店員端末を介して顧客の注文を受け付けることが行われている。店員が店員端末を操作するためトラブルは発生しにくい。

これに対し、本願ステムでは、顧客の所有するユーザ端末１を介して、顧客自身が注文に係る操作を行なう（ステップ２８）。したがって、一般的な従来例では想定し得ないような不具合が発生するおそれがある。例えば、一度、注文を入力してしまうと、注文が確定されてしまい、キャンセルすることが難しくなる。一方、顧客が自由にキャンセルできるような注文システムとすると、調理開始後にキャンセルされる可能性もあり、厨房の料理人が調理開始するか否かについて判断に迷う。

ところで、民法では、相対立する二つ以上の意思表示の合致したときに契約が成立するとされている。企業間の取引等では契約書として明文化する。しかしながら、飲食店などでは契約書などを作成することなく、店員と顧客との間における口頭に基づいておこなわれる。本願システムでは、省人の観点より、顧客と店員の意思疎通の機会をなるべく減らすように企図されているため、契約成立時点を確定することが難しい。本願システムは上記課題を以下のようにして解決できる。

動作１で説明したように、サーバ１０はユーザ端末１からメニューから選択された注文情報２０８を受信する。さらに、注文情報２０８を厨房端末２に送信する（ステップ２８）。

ただし、この時点では、厨房の料理人は特別動作をする事ことはない。当該料理が注文されてことを認識するだけでよい。

サーバ１０はユーザ端末１にキャンセル可能な状態で、調理待ち情報３０１を提示する。たとえば、ユーザ端末１に調理待ち状況を示すユーザ端末画面１１７を表示する（ステップ３１）。

ユーザ端末画面１１７には注文情報２０８に相当する情報とキャンセルアイコンが表示されている。顧客は、ユーザ端末画面１１７を見て、自分が何を注文したのかを確認できる。

サーバ１０は、ユーザ端末１からキャンセル情報３０２を受信し、さらに、キャンセル情報３０２を厨房端末２に送信する。連動して、ユーザ端末画面１１７の表示も変更する。

ユーザ端末画面１１７が表示されている限り、顧客はユーザ端末画面１１７を介して、いつでもキャンセル可能である。この点でも顧客利便性が高い。厨房の料理人も注文がキャンセルされてことを認識するだけで特別動作をすることはない。

動作１で説明したように、サーバ１０は店員端末３から予約済情報２０９を受信する（ステップ２９）とともに、店員端末３から座席識別情報２１０を受信する。予約済情報２０９受信または座席識別情報２１０受信を入店確認情報と解釈し、入店確認情報２０９（または２１０）と注文情報２０８とを含む調理許可情報３０３を送信する。たとえば、厨房端末２の表示を厨房端末画面１２１→１２２のように変更する（ステップ３２）。

なお、調理許可後であっても、ユーザ端末画面１１７が表示されている限り、顧客はユーザ端末画面１１７を介して、いつでもキャンセル可能である。

サーバ１０は、ユーザ端末１からキャンセル情報３０２を受信しているか否か、随時確認している（ステップ３３）。図示では、調理許可（ステップ３２）の後にキャンセル有無を確認するようにしているが、これに限定されない。

調理許可後、いつ調理開始するかの判断は、厨房の料理人に委ねられる。厨房側では、複数の調理管理が平行しておこなわれている。厨房側の判断で、調理を開始する。すなわち、料理人利便性が高い。調理開始の際には、厨房の料理人は、厨房端末２を操作し、厨房端末画面１２３を介して調理開始の旨を報告する。厨房端末２の表示を厨房端末画面１２２→１２３のように変更する。

サーバ１０は、厨房端末２から、調理開始情報３０４を受信する（ステップ３４）。

本願システムにおいて、入店確認情報２０９（または２１０）と注文情報２０８に基づいて調理許可（ステップ３２）する点、注文時や調理許可時でなく、調理開始時（ステップ３４）に契約成立とみなす点が特徴的である。これにより、無用のトラブルを回避でき、店舗管理者利便性が高い。

サーバ１０は、調理開始情報に基づいて、ユーザ端末１に対し、キャンセル不可な状態で、調理中情報３０５を提示する。たとえば、ユーザ端末１の表示をユーザ端末画面１１７→１１８のように変更する（ステップ３５）。

ユーザ端末画面１１８には、キャンセルアイコンが非表示状態で注文情報２０８に相当する情報が表示されている。さらに、注文確定の旨を記載してもよい。または、調理開始したためキャンセル不可の旨を記載してもよい。顧客は、ユーザ端末画面１１８を見て、調理が開始したことおよびキャンセルが不可能であることを確認できる。調理状況を把握できるため、注文した料理が来ない苛立が緩和される。ユーザ端末画面１１７に予想待ち時間を適宜掲示してもよい。すなわち顧客利便性が高い。

とくに、複数人により注文した場合、各人の料理提供に時間差があると苛立が増す。本願システムでは、注文料理ごとに状況を把握でき、無用のトラブルを防止できる。

調理完了後には、厨房の料理人は、厨房端末２を操作し、厨房端末画面１２４を介して調理完了の旨を報告する。厨房端末２の表示を厨房端末画面１２３→１２４のように変更する。

サーバ１０は、厨房端末２から、調理完了情報３０６を受信し、ユーザ端末１および店員端末３に調理完了情報３０６を送信する（ステップ３６）。たとえば、ユーザ端末１に調理完了を通知するユーザ端末画面１１９を表示し、店員端末３に調理完了を通知する店員端末画面１３２を表示する。

店舗の店員は店員端末画面１３２を見て、該当する座席に調理完了した料理を提供する。さらに、店員が料理提供完了を店員端末３を介して報告してもよい。動作２における店員動作は極めて少ない。店舗の省人化に寄与する。

顧客は、ユーザ端末画面１１９を見て、提供された料理と未提供の料理（調理前や調理中）について確認する。注文した料理が全て提供されると、ユーザ端末画面１１９はその旨を表示する。

～動作（その他）～
本願システムの代表的な動作を動作１（入店予約→注文受付）および動作２（注文受付→調理管理）として説明したが、これに限定されない。

全ての顧客がユーザ端末を有する前提としているが、ユーザ端末を持たない顧客の為、従来システムと併存させてもよい。

特徴的動作として入店前注文（ステップ２８）について説明したが、入店後においても注文可能である。

説明の便宜のため、注文はユーザ端末１を介しておこなわれるが、並行して、店員端末３を介して注文がおこなわれていてもよい。

サーバ１０とユーザ端末１とは接続が継続されている前提としているが、接続が切れてしまった場合でも、一般的な方法で当該インターネット接続先を指定したり、店舗コード６を再読み取りすることで、再接続可能である。

～各端末画面～
図８～図１６にユーザ端末画面の遷移を示す。

図８は、入店待ち状況を示すユーザ端末画面１１１の例である。上記動作例では接続直後に表示される（ステップ２３）。顧客は、来店時に、ユーザ端末画面１１１を見て、ある程度の時間待ってでも入店するか、諦めて他の店を探すか判断する。

図９は、ユーザ情報入力を促すユーザ端末画面１１２の例である。上記動作例ではユーザ端末画面１１１の予約アイコンを操作すると表示される（ステップ２４）。顧客は、ユーザ端末画面１１２を介して、電話番号やメールアドレス等のユーザ情報を入力する。

図１０は、予約完了を通知するユーザ端末画面１１３の例である。上記動作例ではユーザ端末画面１１２の登録アイコンを操作すると表示される（ステップ２６）。ユーザ端末画面１１３には、当該顧客の入店待ち情報が表示されている。顧客は、ユーザ端末画面１１３を見て、待ち時間を有効に使うことができる。例えば、待ち時間に注文をしてもよい。ユーザ端末画面１１３を見て、入店順番が近づいたと判断すると、店舗に再来店する。

図１１は、料理メニューを選択可能に提示するユーザ端末画面１１４の例である。ユーザ端末画面１１３の注文アイコンを操作すると表示される（ステップ２７）。顧客は、ユーザ端末１のユーザ端末画面１１４を見ながら、所望の料理を注文する。上記動作例では入店待ち時間を利用して注文する動作について説明したが、入店後もユーザ端末画面１１７を介して注文可能である。

図１２は、入店確認時に用いるユーザ端末画面１１５の例である。ユーザ端末画面１１３の予約番号アイコンを操作すると表示される（ステップ２９）。ユーザ端末画面１１５にはたとえば、２次元バーコードが含まれている。顧客は、ユーザ端末画面１１５を店員に提示する。店員は、カメラ付き店員端末３を介して、２次元バーコードを読み取る。

図１３は、座席情報に係るユーザ端末画面１１６の例である。店員が顧客と座席を関連づけると（ステップ３０）、ユーザ端末画面１１６が表示される。店員が顧客を案内してもよいし、顧客がユーザ端末画面１１６を見て当該座席に着席してもよい。

ついで、注文管理について説明する。注文に係るユーザ端末画面はユーザ端末画面１１７→１１８→１１９のように変化する。

図１４はユーザ端末画面１１７の例である。注文された料理リストが表示される（ステップ２８）（ステップ３１）。顧客は、ユーザ端末画面１１７を見て、自分が何を注文したのかを確認できる。注文リストと一緒に各注文に対応してキャンセルアイコンが表示されている。キャンセルされると注文リストから当該注文の表示が消去される。

ユーザ端末画面１１７には注文リストに加えて注文アイコンが表示されている。注文アイコンを押すと、料理メニューを選択可能に提示するユーザ端末画面１１４が表示される。これにより追加注文もできる。また、ユーザ端末画面１１７には精算アイコンが表示されている。精算アイコンを押すと、キャンセル不可となる。

図１５はユーザ端末画面１１８の例である。本願システムにおいて、調理開始時（ステップ３４）に契約成立とみなす点が特徴的である。調理開始後の注文に対応するキャンセルアイコンは調理中表示アイコンに変更される。なお、調理開始前の注文に対応するキャンセルアイコンはそのまま表示される。

図１６はユーザ端末画面１１９の例である。調理完了の注文に対応する調理中表示は調理完了表示に変更される。

ユーザ端末画面１１９にも注文リストアイコンがそのまま表示され、すべての注文に対する料理の調理完了後も追加注文もできる。

図１７~２０に厨房端末画面の遷移を示す。厨房端末画面は厨房端末画面１２１→１２２→１２３→１２４のように変化する。

図１７は、調理待ちを示す厨房端末画面１２１の例である。注文された料理リストが表示される（ステップ２８）（ステップ３１）。調理待ちアイコンが表示されている。顧客は、厨房端末画面１２１を見て、顧客が何を注文したのかを確認できる。なお、この時点ではキャンセル可能である。厨房の料理人も特別動作をすることはない。

図１８は、調理許可を示す厨房端末画面１２２の例である。上記動作例では調理許可後（ステップ３２）、厨房端末画面１２１の対応する調理待ちアイコンが調理許可アイコンに変更される。なお、調理許可後、いつ調理開始するかの判断は、厨房の料理人に委ねられる。

図１９は、調理中を示す厨房端末画面１２３の例である。上記動作例では厨房側の判断で、調理を開始する（ステップ３４）。厨房端末画面１２２の対応する調理許可アイコンを押すと、調理中アイコンが表示される。

図２０は、調理完了を示す厨房端末画面１２４の例である。上記動作例では調理完了後、調理完了報告する（ステップ３６）。厨房端末画面１２３の対応する調理中アイコンを押すと、調理完了アイコンが表示される。注文した料理が全て調理完了すると、全て調理完了アイコンが表示される。

図２１~２２に店員端末画面例を示す。

図２１は、店員端末画面１３１の例である。カメラ付き店員端末３を介して、ユーザ端末画面１１５の２次元バーコードを読み取り（ステップ２９）、顧客の予約済情報が表示される。さらに、座席情報が表示されている。店員端末画面１３１において顧客と座席を関連づけることができる。

図２２は、店員端末画面１３２の例である。調理完了を示す厨房端末画面１２４（ステップ３６）と同様な情報が表示される。店員は店員端末画面１３２を見て、該当する座席に調理完了した料理を提供する。顧客に注文した料理が全て提供されているかを確認する店員確認アイコンが表示されている。

～効果まとめ～
顧客は、顧客が所有するユーザ端末を操作することにより、店舗管理状況を把握でき、顧客利便性が高い。

情報処理の殆どはサーバにより処理される。したがってユーザ端末に専用アプリをダウンロードやインストールする必要がない。この点でも、顧客利便性が高い。

厨房の料理人は、厨房側の判断を優先することができ、調理に集中できる。

店舗店員の動作は極めて少なく、店舗の省人化に寄与する。

想定されるトラブルが回避されており、店舗管理人の負担が軽減される。

１ 顧客端末(ユーザ端末)
２ 厨房端末
３ 店員端末
６ 店舗コード
１０ サーバ
２１ 接続要求受付部
２２ 入店待ち状況管理部
２３ 予約部
２４ メニュー提示部
２５ 注文受付部
２６ 入店確認部
３１ 調理許可部
３２ 調理開始管理部
３３ 調理待ち情報管理部
３４ 注文キャンセル部
３５ 調理中情報管理部
３６ 調理完了管理部

Claims (6)

1. 一度来店したものの入店できなかった顧客の便宜を図るシステムであって、
   店舗店頭に提示されている店舗コードと、
   前記店舗コードを読み取り可能なユーザ端末と、
   前記ユーザ端末とネットワークを介して接続されるサーバと、
   ネットワークを介してサーバと接続される厨房端末と
   を備え、
   前記サーバは、
   前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する接続要求受付部と、
   前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する入店待ち状況管理部と、
   前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する予約部と、
   前記予約完了情報を送信したユーザ端末に対し、メニュー情報を送信するメニュー提示部と、
   前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、
   前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、
   前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、
   前記厨房端末から、調理開始情報を受信する調理開始管理部と、
   を有し、
   前記店舗店頭は待ち行列可能な範囲である
   ことを特徴とする店舗管理補助システム。
2. 前記サーバは、
   前記ユーザ端末に対し、キャンセル可能な状態で、調理待ち情報を提示する調理待ち情報管理部と、
   前記メニュー情報を送信したユーザ端末から、注文キャンセル情報を受信し、注文をキャンセルする注文キャンセル部と、
   前記調理開始情報に基づいて、前記ユーザ端末に対し、キャンセル不可な状態で、調理中情報を提示する調理中情報管理部と、
   を有する
   ことを特徴とする請求項１記載の店舗管理補助システム。
3. 前記サーバは、
   前記厨房端末から、調理完了情報を受信し、前記ユーザ端末に調理完了情報を送信する調理完了管理部と、
   を有する
   ことを特徴とする請求項２記載の店舗管理補助システム。
4. 一度来店したものの入店できなかった顧客の便宜を図るシステムの一構成であるサーバであって、
   店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末および厨房端末と、ネットワークを介して接続されるサーバであって、
   前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する接続要求受付部と、
   前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する入店待ち状況管理部と、
   前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する予約部と、
   前記ユーザ端末に対し、メニュー情報を送信するメニュー提示部と、
   前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、
   前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、
   前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、
   前記厨房端末から、調理開始情報を受信する調理開始管理部と、
   を有し、
   前記店舗店頭は待ち行列可能な範囲である
   ことを特徴とするサーバ。
5. 一度来店したものの入店できなかった顧客の便宜を図るシステムの一構成であるサーバを用いた店舗管理補助方法であって、
   店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末および厨房端末と、ネットワークを介して接続されるサーバが、
   前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信し、
   前記接続要求のあったユーザ端末に対し、入店待ち情報を送信し、
   前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信し、
   前記ユーザ端末に対し、メニュー情報を送信し、
   前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信し、
   前記ユーザ端末の所有者が入店したか否かを確認する入店確認情報を受信し、
   前記厨房端末に対し、前記入店確認情報と前記注文情報とを含む調理許可情報を送信し、
   前記厨房端末から、調理開始情報を受信し、
   前記店舗店頭は待ち行列可能な範囲である
   ことを特徴とする店舗管理補助方法。
6. 一度来店したものの入店できなかった顧客の便宜を図るシステムの一構成であるサーバに実行させるプログラムであって、
   店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末および厨房端末と、ネットワークを介して接続されるサーバに、
   前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する処理と、
   前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する処理と、
   前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する処理と、
   前記ユーザ端末に対し、メニュー情報を送信する処理と、
   前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する処理と、
   前記ユーザ端末の所有者が入店したか否かを確認する入店確認情報を受信する処理と、
   前記厨房端末に対し、前記入店確認情報と前記注文情報とを含む調理許可情報を送信する処理と、
   前記厨房端末から、調理開始情報を受信する処理と、
   を実行させ、
   前記店舗店頭は待ち行列可能な範囲である
   ことを特徴とするプログラム。

Images