(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022043574
(43)【公開日】2022-03-16
(54)【発明の名称】店舗管理補助システムおよびサーバ
(51)【国際特許分類】
G06Q 50/12 20120101AFI20220309BHJP
【FI】
G06Q50/12
【審査請求】有
【請求項の数】6
【出願形態】OL
(21)【出願番号】P 2020148909
(22)【出願日】2020-09-04
(71)【出願人】
【識別番号】520341957
【氏名又は名称】ジャストウェア株式会社
(74)【代理人】
【識別番号】100154405
【弁理士】
【氏名又は名称】前島 大吾
(74)【代理人】
【識別番号】100079005
【弁理士】
【氏名又は名称】宇高 克己
(74)【代理人】
【識別番号】100201341
【弁理士】
【氏名又は名称】畠山 順一
(72)【発明者】
【氏名】呉 俊
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049CC24
(57)【要約】
【課題】入店予約、注文受付、調理管理等のような管理業務を補助する店舗管理補助システムを提供する。
【解決手段】店舗管理補助システムは、店舗店頭に提示されている店舗コード6と、店舗コード6を読み取り可能なユーザ端末1と、ユーザ端末1とネットワークを介して接続されるサーバ10と、を備える。サーバ10は、店舗コード6を読み取ったユーザ端末1から、接続要求情報を受信する接続要求受付部21と、前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する入店待ち状況管理部22と、前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する予約部23と、を有する。
【選択図】
図1
【特許請求の範囲】
【請求項1】
店舗店頭に提示されている店舗コードと、
前記店舗コードを読み取り可能なユーザ端末と、
前記ユーザ端末とネットワークを介して接続されるサーバと、
を備え、
前記サーバは、
前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する接続要求受付部と、
前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する入店待ち状況管理部と、
前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する予約部と、
を有する
ことを特徴とする店舗管理補助システム。
【請求項2】
前記サーバは、
前記予約完了情報を送信したユーザ端末に対し、メニュー情報を送信するメニュー提示部と、
前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、
を有する
ことを特徴とする請求項1記載の店舗管理補助システム。
【請求項3】
請求項2記載の店舗管理補助システムは、ネットワークを介してサーバと接続される厨房端末を備え、
前記サーバは、
前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、
前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、
前記厨房端末から、調理開始情報を受信する調理開始管理部と、
を有する
ことを特徴とする店舗管理補助システム。
【請求項4】
ユーザ端末と、厨房端末と、前記ユーザ端末および厨房端末とネットワークを介して接続されるサーバと、
を備え、
前記サーバは、
前記ユーザ端末に対し、メニュー情報を送信するメニュー提示部と、
前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、
前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、
前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、
前記厨房端末から、調理開始情報を受信する調理開始管理部と、
を有する
ことを特徴とする店舗管理補助システム。
【請求項5】
前記サーバは、
前記ユーザ端末に対し、キャンセル可能な状態で、調理待ち情報を提示する調理待ち情報管理部と、
前記メニュー情報を送信したユーザ端末から、注文キャンセル情報を受信し、注文をキャンセルする注文キャンセル部と、
前記調理開始情報に基づいて、前記ユーザ端末に対し、キャンセル不可な状態で、調理中情報を提示する調理中情報管理部と、
を有する
ことを特徴とする請求項3または4記載の店舗管理補助システム。
【請求項6】
前記サーバは、
前記厨房端末から、調理完了情報を受信し、前記ユーザ端末に調理完了情報を送信する調理完了管理部と、
を有する
ことを特徴とする請求項3または4記載の店舗管理補助システム。
【請求項7】
店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末とネットワークを介して接続されるサーバであって、
前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する接続要求受付部と、
前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する入店待ち状況管理部と、
前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する予約部と、
を有する
ことを特徴とするサーバ。
【請求項8】
ユーザ端末と、厨房端末と、ネットワークを介して接続されるサーバであって、
前記ユーザ端末に対し、メニュー情報を送信するメニュー提示部と、
前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、
前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、
前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、
前記厨房端末から、調理開始情報を受信する調理開始管理部と、
を有する
ことを特徴とするサーバ。
【請求項9】
店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末とネットワークを介して接続されるサーバが、
前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信し、
前記接続要求のあったユーザ端末に対し、入店待ち情報を送信し、
前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する
ことを特徴とする予約管理方法。
【請求項10】
ユーザ端末と、厨房端末と、ネットワークを介して接続されるサーバが、
前記ユーザ端末に対し、メニュー情報を送信し、
前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信し、
前記ユーザ端末の所有者が入店したか否かを確認する入店確認情報を受信し、
前記厨房端末に対し、前記入店確認情報と前記注文情報とを含む調理許可情報を送信し、
前記厨房端末から、調理開始情報を受信する
ことを特徴とする注文管理方法。
【請求項11】
店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末とネットワークを介して接続されるサーバに、
前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する処理と、
前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する処理と、
前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する処理と、
を実行させることを特徴とするプログラム。
【請求項12】
ユーザ端末と、厨房端末と、ネットワークを介して接続されるサーバに、
前記ユーザ端末に対し、メニュー情報を送信する処理と、
前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する処理と、
前記ユーザ端末の所有者が入店したか否かを確認する入店確認情報を受信する処理と、
前記厨房端末に対し、前記入店確認情報と前記注文情報とを含む調理許可情報を送信する処理と、
前記厨房端末から、調理開始情報を受信する処理と、
を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、例えば飲食店などの店舗における店舗管理補助システムおよびサーバ等に関するものである。
【背景技術】
【0002】
飲食店などの店舗においては、入店予約、注文受付、調理管理等のような管理業務が発生する。これらの管理業務は情報処理システムによる補助が可能であり、店舗の省人化に寄与する。
【0003】
一方で、近年、スマートフォンやタブレットなどの個人端末(ユーザ端末)が普及しており、ユーザ端末の処理能力も高い。したがって、ユーザ端末はネットワークを介して情報処理システムのインターフェイスとして機能する。これにより顧客利便性を確保できる。
【0004】
例えば、特許文献1ではユーザ端末を用いてレストランの予約が可能である。また、特許文献2ではユーザ端末を用いて料理の注文が可能である。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2006-268720号公報
【特許文献2】特開2019-175193号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
上記のような従来システムを参考に、本願発明者は、各技術を相互に生かし合う様に組み合わせることにより、店舗管理者、ユーザ(店舗顧客)、厨房担当者、店舗従業員各々にとって利便性の高いシステムを簡易に構築することを検討した。
【0007】
本発明は、上記課題を解決するものであり、入店予約、注文受付、調理管理等のような管理業務を補助する店舗管理補助システムを提供することを目的とする。
【課題を解決するための手段】
【0008】
上記課題を解決する本発明の店舗管理補助システムは、店舗店頭に提示されている店舗コードと、前記店舗コードを読み取り可能なユーザ端末と、前記ユーザ端末とネットワークを介して接続されるサーバと、を備える。前記サーバは、前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する接続要求受付部と、前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する入店待ち状況管理部と、前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する予約部と、を有する。
【0009】
顧客は、顧客所有のユーザ端末を操作して、予約を完結できる。さらに、入店待ち状況を顧客所有のユーザ端末にて把握できるため、店舗店頭から離れることができる。顧客は待ち時間を有効に使うことができる。
【0010】
上記発明において、好ましくは、前記サーバは、前記予約完了情報を送信したユーザ端末に対し、メニュー情報を送信するメニュー提示部と、前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、を有する。
【0011】
顧客は、待ち時間を利用して、入店前に注文できる。料理人は事前に注文予測ができるため、作業性が向上する。
【0012】
上記発明において、好ましくは、上記記載の店舗管理補助システムは、ネットワークを介してサーバと接続される厨房端末を備える。前記サーバは、前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、前記厨房端末から、調理開始情報を受信する調理開始管理部と、を有する。
【0013】
注文情報と入店確認情報の双方により調理許可となる。調理許可後、厨房側の判断で、調理を開始できる。
【0014】
上記課題を解決する本発明の店舗管理補助システムは、ユーザ端末と、厨房端末と、前記ユーザ端末および厨房端末とネットワークを介して接続されるサーバと、を備える。前記サーバは、前記ユーザ端末に対し、メニュー情報を送信するメニュー提示部と、前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、前記厨房端末から、調理開始情報を受信する調理開始管理部と、を有する。
【0015】
顧客は顧客所有のユーザ端末を操作して注文できる。注文情報と入店確認情報の双方により調理許可となる。調理許可後、厨房側の判断で、調理を開始できる。
【0016】
上記発明において、好ましくは、前記サーバは、前記ユーザ端末に対し、キャンセル可能な状態で、調理待ち情報を提示する調理待ち情報管理部と、前記メニュー情報を送信したユーザ端末から、注文キャンセル情報を受信し、注文をキャンセルする注文キャンセル部と、前記調理開始情報に基づいて、前記ユーザ端末に対し、キャンセル不可な状態で、調理中情報を提示する調理中情報管理部と、を有する。
【0017】
調理開始時に契約成立とみなす。すなわち、調理開始前であればキャンセル可能であるが、調理開始後はキャンセル不可となる。
【0018】
上記発明において、好ましくは、前記サーバは、前記厨房端末から、調理完了情報を受信し、前記ユーザ端末に調理完了情報を送信する調理完了管理部と、を有する。
【0019】
顧客は、顧客所有のユーザ端末により注文した料理が提供されることを確認できる。
【0020】
上記課題を解決する本発明のサーバは、店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末とネットワークを介して接続される。前記サーバは、前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する接続要求受付部と、前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する入店待ち状況管理部と、前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する予約部と、を有する。
【0021】
顧客は、顧客所有のユーザ端末を操作して、予約を完結できる。さらに、入店待ち状況を顧客所有のユーザ端末にて把握できるため、店舗店頭から離れることができる。顧客は待ち時間を有効に使うことができる。
【0022】
上記課題を解決する本発明のサーバは、ユーザ端末と、厨房端末と、ネットワークを介して接続される。前記サーバは、前記ユーザ端末に対し、メニュー情報を送信するメニュー提示部と、前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、前記厨房端末から、調理開始情報を受信する調理開始管理部と、を有する。
【0023】
顧客は顧客所有のユーザ端末を操作して注文できる。注文情報と入店確認情報の双方により調理許可となる。調理許可後、厨房側の判断で、調理を開始できる。
【0024】
上記課題を解決する本発明の予約管理方法では、サーバを用いる。サーバは店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末とネットワークを介して接続される。サーバは、前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信し、前記接続要求のあったユーザ端末に対し、入店待ち情報を送信し、前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する。
【0025】
顧客は、顧客所有のユーザ端末を操作して、予約を完結できる。さらに、入店待ち状況を顧客所有のユーザ端末にて把握できるため、店舗店頭から離れることができる。顧客は待ち時間を有効に使うことができる。
【0026】
上記課題を解決する本発明の注文管理方法では、サーバを用いる。サーバはユーザ端末と、厨房端末と、ネットワークを介して接続される。サーバは、前記ユーザ端末に対し、メニュー情報を送信し、前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信し、前記ユーザ端末の所有者が入店したか否かを確認する入店確認情報を受信し、前記厨房端末に対し、前記入店確認情報と前記注文情報とを含む調理許可情報を送信し、前記厨房端末から、調理開始情報を受信する。
【0027】
顧客は顧客所有のユーザ端末を操作して注文できる。注文情報と入店確認情報の双方により調理許可となる。調理許可後、厨房側の判断で、調理を開始できる。
【0028】
上記課題を解決する本発明のプログラムは、サーバに、前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する処理と、前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する処理と、前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する処理と、を実行させる。サーバは、店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末とネットワークを介して接続される。
【0029】
顧客は、顧客所有のユーザ端末を操作して、予約を完結できる。さらに、入店待ち状況を顧客所有のユーザ端末にて把握できるため、店舗店頭から離れることができる。顧客は待ち時間を有効に使うことができる。
【0030】
上記課題を解決する本発明のプログラムは、サーバに、前記ユーザ端末に対し、メニュー情報を送信する処理と、前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する処理と、前記ユーザ端末の所有者が入店したか否かを確認する入店確認情報を受信する処理と、前記厨房端末に対し、前記入店確認情報と前記注文情報とを含む調理許可情報を送信する処理と、前記厨房端末から、調理開始情報を受信する処理と、を実行させる。サーバは、ユーザ端末と、厨房端末と、ネットワークを介して接続される。
【発明の効果】
【0031】
本発明のシステムは、飲食店などの店舗における入店予約、注文受付、調理管理等のような管理業務を補助し、店舗管理者、ユーザ(店舗顧客)、厨房料理人、店舗店員各々にとっての利便性を向上することができる。
【図面の簡単な説明】
【0032】
【発明を実施するための形態】
【0033】
~システム概略~
図1は本願システムの概略図である。本願システムは、飲食店などの店舗において、入店予約、注文受付、調理管理等のような管理業務を補助する。
【0034】
本願システムはサーバ10を主構成とする。サーバ10はインターネット等の通信網を介してユーザ端末1、厨房端末2、店舗端末3と通信可能に接続している。通信は無線を原則とするが、例えば、サーバ-厨房端末間の通信は有線でも良い場合もある。
【0035】
サーバ10は、店舗に設置していてもよいし、店舗外において管理されていてもよい。サーバ10は、単数又は複数のサーバ装置や記憶装置等を含んで構成されたサーバシステムである。
【0036】
ユーザ端末1は、店舗を利用する顧客が所有するスマートフォンやタブレットなどの個人端末である。顧客は複数であり、各顧客はそれぞれユーザ端末1A,1Bを有している。
【0037】
厨房端末2は、厨房に設置されたタブレットまたは料理人が所有するスマートフォンである。別途、大型モニターを設置して、情報を表示してもよい。
【0038】
店員端末3は、店舗で働く店員が携帯する端末である。市販のスマートフォンを利用してもよいし、店舗独自の携帯端末でもよい。
【0039】
本願システムは、入店予約→注文受付の一連の流れ(動作1)と、注文受付→調理管理の一連の流れ(動作2)を補助する。
【0040】
店舗店頭には店舗コード(例えば2次元バーコード)6が提示されている。
【0041】
~サーバ構成~
図2はサーバ10の物理構成図である。サーバ10の各構成は、本願システムを制御する。サーバ10は、CPU11、ROM12、RAM13、大容量記憶部14、通信部15、表示部16、操作部17などを備える演算処理装置である。物理構成11~17はバスを介して各々接続されている。
【0042】
ROM12または大容量記憶部14には、所定の動作プログラムが予め格納されている。動作プログラムはCPU11にて実行され、所定の演算処理が実現される。
【0043】
通信部15はユーザ端末1、厨房端末2、店員端末3と通信する。
【0044】
本願発明ではサーバ10を操作することを前提としていないが、表示部16、操作部17を備えていてもよい。サーバ10の動作状況を確認することができる。
【0045】
【0046】
機能構成21~26は、主に、入店予約→注文受付の一連の流れ(動作1)を実現する構成である。機能構成31~36は、主に、注文受付→調理管理の一連の流れ(動作2)を実現する構成である。ただし、機能構成25,26,33等は両動作に共通する構成である。
【0047】
まず、機能構成21~26について説明する。
【0048】
接続要求受付部21は、店舗コード6を読み取ったユーザ端末1から、接続要求情報を受信する。
【0049】
入店待ち状況管理部22は、接続要求のあったユーザ端末1に対し、入店待ち情報を送信する。たとえば、ユーザ端末1に入店待ち状況を示すユーザ端末画面111を表示する。
【0050】
予約部23は、接続要求のあったユーザ端末1に対し、ユーザ情報要求情報を送信し、ユーザ端末1から、ユーザ情報を受信し、ユーザ端末1に対し、予約完了情報を送信する。
【0051】
ユーザ情報は、例えば、ユーザ固有のメールアドレスや携帯電話番号などである。たとえば、ユーザ端末1にユーザ情報入力を促すユーザ端末画面112を表示する。さらに、予約完了を通知するユーザ端末画面113を表示する。さらに、ユーザ端末画面113からユーザ端末画面115に遷移できる。
【0052】
メニュー提示部24は、予約完了情報を送信したユーザ端末1に対し、メニュー情報を送信する。たとえば、ユーザ端末1に料理メニューを選択可能に提示するユーザ端末画面114を表示する。
【0053】
注文受付部25は、メニュー情報を送信したユーザ端末1から、メニューから選択された注文情報を受信する。さらに、注文情報を調理待ち情報管理部33に送信する。
【0054】
入店確認部26は、ユーザ端末1の所有者が入店したか否かを確認する。入店確認部26の動作詳細については、別途詳述する。
【0055】
次に、機能構成31~36について説明する。
【0056】
調理許可部31は、厨房端末2に対し、入店確認部26による入店確認情報と注文受付部25による注文情報とを含む調理許可情報を送信する。たとえば、厨房端末2の表示を厨房端末画面121→122のように変更する。
【0057】
調理開始管理部32は、厨房端末2から、調理開始情報を受信する。
【0058】
調理待ち情報管理部33は、ユーザ端末2に対し、キャンセル可能な状態で、調理待ち情報を提示する。たとえば、ユーザ端末1に調理待ち状況を示すユーザ端末画面117を表示する。また、厨房端末2に調理待ち状況を示す厨房端末画面121を表示する。
【0059】
注文キャンセル部34は、メニュー情報を送信したユーザ端末1から、注文キャンセル情報を受信し、注文をキャンセルする。
【0060】
調理中情報管理部35は、厨房端末画面123を介して厨房端末2から調理開始情報に基づいて、ユーザ端末1に対し、キャンセル不可な状態で、調理中情報を提示する。たとえば、ユーザ端末1の表示をユーザ端末画面117→118のように変更する。
【0061】
調理完了管理部36は、厨房端末画面124を介して厨房端末2から、調理完了情報を受信し、ユーザ端末1および店員端末3に調理完了情報を送信する。たとえば、ユーザ端末1に調理完了を通知するユーザ端末画面119を表示し、さらに、店員端末3に調理完了を通知する店員端末画面132を表示する。
【0062】
各機能構成間の相互関係は、動作詳細として説明する。
【0063】
~動作1~
図4は、入店予約→注文受付の一連の動作(動作1)に対応するサーバ10における演算処理のフロー図である。
図5は、動作1に対応するシステムのシーケンス図である。入店予約→注文受付について、システムの動作および、顧客、厨房の料理人、店舗の店員の動作について説明する。
【0064】
飲食は嗜好性が高く、その時の気分(今日は和食を食べたい気分)に影響され、事前予約なしで来店することも多い。人気のある飲食店では、顧客が事前予約なしで来店しても待たされることも多い。
【0065】
従来例では、店舗店頭に待ち行列をする、店舗店頭にある入店待ちリストに記名し、名前を呼ばれるのを待つ、店舗店頭にある発券機から順番券を発券するなどの対応をしている。しかしながら、いずれも待ち時間が発生する。本願システムは上記課題を以下のようにして解決できる。
【0066】
本願システムでは、店舗店頭にインターネット接続先を意味する店舗コード6が提示されている。ユーザ端末1はカメラを有し、店舗コード6を読み取り可能である。
【0067】
ユーザ端末1は店舗コード読み取り情報201を読み取り、サーバ10に接続要求202を発信する。サーバ10が接続要求202を受信すると、サーバ10とユーザ端末1とは接続する(ステップ21)。
【0068】
サーバ10は、複数のユーザ端末1A,1Bから入店予約を受けており、入店順番を判断し、おおよその入店待ち時間を推測し、入店待ち情報203とする(ステップ22)。
【0069】
サーバ10はユーザ端末1に入店待ち情報203を送信する。たとえば、ユーザ端末1に入店待ち状況を示すユーザ端末画面111を表示する(ステップ23)。なお、併せて、入店待ち情報203を店頭モニターに表示してもよい。
【0070】
顧客は、入店待ち情報を見て、ある程度の時間待ってでも入店するか、諦めて他の店を探すか考える。
【0071】
サーバ10はユーザ端末1にユーザ情報要求情報204を送信する。たとえば、ユーザ端末1にユーザ情報入力を促すユーザ端末画面112を表示する(ステップ24)。
【0072】
顧客は、ユーザ端末画面112を介して、ユーザを特定できる情報を入力する。例えば、ユーザ端末1に名前や電話番号(またはメールアドレス)を入力する。さらに、顧客を含む人数(大人・小人別)や喫煙の有無や席等の希望の有無を入力してもよい。
【0073】
サーバ10はユーザ端末1から、ユーザ情報205を受信する(ステップ25)。
【0074】
なお、ステップ22→23(入店待ち状況把握)の処理と、ステップ24→25(予約)の処理の順番を入れ替えてもよい。
【0075】
サーバ10はユーザ端末1に予約完了情報206を送信する。たとえば、ユーザ端末1に予約完了を通知するユーザ端末画面113を表示する(ステップ26)。
【0076】
顧客は、ユーザ端末1のユーザ端末画面113を見て、予約が完了したことを確認する。ユーザ端末画面113には、当該顧客の入店待ち情報が表示されている。
【0077】
さらに、本願システムでは以下のように顧客は入店待ちの間に注文することができる。
【0078】
サーバ10はユーザ端末1にメニュー情報207を送信する。たとえば、ユーザ端末1に料理メニューを選択可能に提示するユーザ端末画面114を表示する(ステップ27)。ユーザ端末画面113からユーザ端末画面114に遷移するようにしてもよい。
【0079】
顧客は、ユーザ端末1のユーザ端末画面114を見ながら、所望の料理を注文する。例えば、当該選択項目を反転表示させ確定する。
【0080】
サーバ10はユーザ端末1からメニューから選択された注文情報208を受信する。さらに、注文情報208を厨房端末2に送信する(ステップ28)。
【0081】
サーバ10はユーザ端末1に調理待ち情報301を送信する。たとえば、ユーザ端末1に調理待ち状況を示すユーザ端末画面117を表示する(動作2にて後述)。
【0082】
顧客は、ユーザ端末1のユーザ端末画面117を見て、注文内容を確認する(動作2にて後述)。
【0083】
なお、ステップ26(予約完了確認)の処理は、ステップ24→25(予約)→ステップ27→28(注文)の処理の後におこなってもよい。この場合、予約完了確認には注文情報208が含まれる。
【0084】
店舗コード6読み取り以降の顧客の動作は、店舗店頭から離れた場所からでもできる。例えば、店舗がデパートやショッピングモール内にある場合、予約から注文までの動作をデパートやショッピングモール内を散策しながら行なうことができる。顧客は時間を有効に使うことができる。すなわち、顧客利便性が高い。一方で、店員や料理人は特に対応することはなく、負担が少ない。料理人は事前に注文予測ができるため、作業性が向上する。入店前に注文が完了しているため顧客回転が速い。店舗管理者利便性が高い。
【0085】
サーバ10は複数の顧客の入店待ち状況を管理し、ユーザ端末1に入店待ち情報203を随時更新している(ステップ23)。サーバ10はユーザ端末1にリマインダ通知を送信してもよい。
【0086】
顧客は、ユーザ端末画面113の入店待ち情報を見ながら、入店順番が近づいたと判断すると、店舗に再来店する。顧客は、予約済情報209に相当するユーザ端末画面115を店員に提示する。ユーザ端末画面115にはたとえば、2次元バーコードが含まれている。
【0087】
店員は、店舗入口にて顧客対応し、カメラ付き店員端末3を介して、予約済情報209(例えば2次元バーコード)を読み取る。
【0088】
サーバ10は店員端末3から予約済情報209を受信する(ステップ29)。
【0089】
店舗の店員は顧客を座席まで誘導する。座席は座席識別情報210を有する。店員は顧客と座席を関連づける。例えば、店員が座席に付した2次元バーコードを読み取ってもよい。サーバ10が座席使用状況を判断し、案内する座席を提示し、店員が案内完了を店員端末3の店員端末画面131を介して報告してもよい。動作1における店員動作は極めて少ない。店舗の省人化に寄与する。
【0090】
更なる省人化として、店舗の店員に代えて、入店確認用の2次元バーコード読取装置を店舗入口に設置してもよい。
【0091】
サーバ10は店員端末3から座席識別情報210を受信する。さらに、座席識別情報210を厨房端末2に送信する(ステップ30)。
【0092】
座席識別情報210をユーザ端末1に送信してもよい。顧客はユーザ端末1のユーザ端末画面116に誘導され、当該座席に着席する。
【0093】
サーバ10は、予約済情報209を受信(ステップ29)した時点で入店確認としてもよいし、座席識別情報210を受信(ステップ30)した時点で入店確認としてもよい。すなわち、予約済情報209または座席識別情報210のいずれかを入店確認情報とみなす。
【0094】
~動作2~
図6は、注文受付→調理管理の一連の動作(動作2)に対応するサーバ10における演算処理のフロー図である。
図7は、動作2に対応するシステムのシーケンス図である。注文受付→調理管理について、システムの動作および、顧客、厨房、店員の動作について説明する。
【0095】
従来例では一般に、店員が店員端末を介して顧客の注文を受け付けることが行われている。店員が店員端末を操作するためトラブルは発生しにくい。
【0096】
これに対し、本願ステムでは、顧客の所有するユーザ端末1を介して、顧客自身が注文に係る操作を行なう(ステップ28)。したがって、一般的な従来例では想定し得ないような不具合が発生するおそれがある。例えば、一度、注文を入力してしまうと、注文が確定されてしまい、キャンセルすることが難しくなる。一方、顧客が自由にキャンセルできるような注文システムとすると、調理開始後にキャンセルされる可能性もあり、厨房の料理人が調理開始するか否かについて判断に迷う。
【0097】
ところで、民法では、相対立する二つ以上の意思表示の合致したときに契約が成立するとされている。企業間の取引等では契約書として明文化する。しかしながら、飲食店などでは契約書などを作成することなく、店員と顧客との間における口頭に基づいておこなわれる。本願システムでは、省人の観点より、顧客と店員の意思疎通の機会をなるべく減らすように企図されているため、契約成立時点を確定することが難しい。本願システムは上記課題を以下のようにして解決できる。
【0098】
動作1で説明したように、サーバ10はユーザ端末1からメニューから選択された注文情報208を受信する。さらに、注文情報208を厨房端末2に送信する(ステップ28)。
【0099】
ただし、この時点では、厨房の料理人は特別動作をする事ことはない。当該料理が注文されてことを認識するだけでよい。
【0100】
サーバ10はユーザ端末1にキャンセル可能な状態で、調理待ち情報301を提示する。たとえば、ユーザ端末1に調理待ち状況を示すユーザ端末画面117を表示する(ステップ31)。
【0101】
ユーザ端末画面117には注文情報208に相当する情報とキャンセルアイコンが表示されている。顧客は、ユーザ端末画面117を見て、自分が何を注文したのかを確認できる。
【0102】
サーバ10は、ユーザ端末1からキャンセル情報302を受信し、さらに、キャンセル情報302を厨房端末2に送信する。連動して、ユーザ端末画面117の表示も変更する。
【0103】
ユーザ端末画面117が表示されている限り、顧客はユーザ端末画面117を介して、いつでもキャンセル可能である。この点でも顧客利便性が高い。厨房の料理人も注文がキャンセルされてことを認識するだけで特別動作をすることはない。
【0104】
動作1で説明したように、サーバ10は店員端末3から予約済情報209を受信する(ステップ29)とともに、店員端末3から座席識別情報210を受信する。予約済情報209受信または座席識別情報210受信を入店確認情報と解釈し、入店確認情報209(または210)と注文情報208とを含む調理許可情報303を送信する。たとえば、厨房端末2の表示を厨房端末画面121→122のように変更する(ステップ32)。
【0105】
なお、調理許可後であっても、ユーザ端末画面117が表示されている限り、顧客はユーザ端末画面117を介して、いつでもキャンセル可能である。
【0106】
サーバ10は、ユーザ端末1からキャンセル情報302を受信しているか否か、随時確認している(ステップ33)。図示では、調理許可(ステップ32)の後にキャンセル有無を確認するようにしているが、これに限定されない。
【0107】
調理許可後、いつ調理開始するかの判断は、厨房の料理人に委ねられる。厨房側では、複数の調理管理が平行しておこなわれている。厨房側の判断で、調理を開始する。すなわち、料理人利便性が高い。調理開始の際には、厨房の料理人は、厨房端末2を操作し、厨房端末画面123を介して調理開始の旨を報告する。厨房端末2の表示を厨房端末画面122→123のように変更する。
【0108】
サーバ10は、厨房端末2から、調理開始情報304を受信する(ステップ34)。
【0109】
本願システムにおいて、入店確認情報209(または210)と注文情報208に基づいて調理許可(ステップ32)する点、注文時や調理許可時でなく、調理開始時(ステップ34)に契約成立とみなす点が特徴的である。これにより、無用のトラブルを回避でき、店舗管理者利便性が高い。
【0110】
サーバ10は、調理開始情報に基づいて、ユーザ端末1に対し、キャンセル不可な状態で、調理中情報305を提示する。たとえば、ユーザ端末1の表示をユーザ端末画面117→118のように変更する(ステップ35)。
【0111】
ユーザ端末画面118には、キャンセルアイコンが非表示状態で注文情報208に相当する情報が表示されている。さらに、注文確定の旨を記載してもよい。または、調理開始したためキャンセル不可の旨を記載してもよい。顧客は、ユーザ端末画面118を見て、調理が開始したことおよびキャンセルが不可能であることを確認できる。調理状況を把握できるため、注文した料理が来ない苛立が緩和される。ユーザ端末画面117に予想待ち時間を適宜掲示してもよい。すなわち顧客利便性が高い。
【0112】
とくに、複数人により注文した場合、各人の料理提供に時間差があると苛立が増す。本願システムでは、注文料理ごとに状況を把握でき、無用のトラブルを防止できる。
【0113】
調理完了後には、厨房の料理人は、厨房端末2を操作し、厨房端末画面124を介して調理完了の旨を報告する。厨房端末2の表示を厨房端末画面123→124のように変更する。
【0114】
サーバ10は、厨房端末2から、調理完了情報306を受信し、ユーザ端末1および店員端末3に調理完了情報306を送信する(ステップ36)。たとえば、ユーザ端末1に調理完了を通知するユーザ端末画面119を表示し、店員端末3に調理完了を通知する店員端末画面132を表示する。
【0115】
店舗の店員は店員端末画面132を見て、該当する座席に調理完了した料理を提供する。さらに、店員が料理提供完了を店員端末3を介して報告してもよい。動作2における店員動作は極めて少ない。店舗の省人化に寄与する。
【0116】
顧客は、ユーザ端末画面119を見て、提供された料理と未提供の料理(調理前や調理中)について確認する。注文した料理が全て提供されると、ユーザ端末画面119はその旨を表示する。
【0117】
~動作(その他)~
本願システムの代表的な動作を動作1(入店予約→注文受付)および動作2(注文受付→調理管理)として説明したが、これに限定されない。
【0118】
全ての顧客がユーザ端末を有する前提としているが、ユーザ端末を持たない顧客の為、従来システムと併存させてもよい。
【0119】
特徴的動作として入店前注文(ステップ28)について説明したが、入店後においても注文可能である。
【0120】
説明の便宜のため、注文はユーザ端末1を介しておこなわれるが、並行して、店員端末3を介して注文がおこなわれていてもよい。
【0121】
サーバ10とユーザ端末1とは接続が継続されている前提としているが、接続が切れてしまった場合でも、一般的な方法で当該インターネット接続先を指定したり、店舗コード6を再読み取りすることで、再接続可能である。
【0122】
~各端末画面~
図8~
図16にユーザ端末画面の遷移を示す。
【0123】
図8は、入店待ち状況を示すユーザ端末画面111の例である。上記動作例では接続直後に表示される(ステップ23)。顧客は、来店時に、ユーザ端末画面111を見て、ある程度の時間待ってでも入店するか、諦めて他の店を探すか判断する。
【0124】
図9は、ユーザ情報入力を促すユーザ端末画面112の例である。上記動作例ではユーザ端末画面111の予約アイコンを操作すると表示される(ステップ24)。顧客は、ユーザ端末画面112を介して、電話番号やメールアドレス等のユーザ情報を入力する。
【0125】
図10は、予約完了を通知するユーザ端末画面113の例である。上記動作例ではユーザ端末画面112の登録アイコンを操作すると表示される(ステップ26)。ユーザ端末画面113には、当該顧客の入店待ち情報が表示されている。顧客は、ユーザ端末画面113を見て、待ち時間を有効に使うことができる。例えば、待ち時間に注文をしてもよい。ユーザ端末画面113を見て、入店順番が近づいたと判断すると、店舗に再来店する。
【0126】
図11は、料理メニューを選択可能に提示するユーザ端末画面114の例である。ユーザ端末画面113の注文アイコンを操作すると表示される(ステップ27)。顧客は、ユーザ端末1のユーザ端末画面114を見ながら、所望の料理を注文する。上記動作例では入店待ち時間を利用して注文する動作について説明したが、入店後もユーザ端末画面117を介して注文可能である。
【0127】
図12は、入店確認時に用いるユーザ端末画面115の例である。ユーザ端末画面113の予約番号アイコンを操作すると表示される(ステップ29)。ユーザ端末画面115にはたとえば、2次元バーコードが含まれている。顧客は、ユーザ端末画面115を店員に提示する。店員は、カメラ付き店員端末3を介して、2次元バーコードを読み取る。
【0128】
図13は、座席情報に係るユーザ端末画面116の例である。店員が顧客と座席を関連づけると(ステップ30)、ユーザ端末画面116が表示される。店員が顧客を案内してもよいし、顧客がユーザ端末画面116を見て当該座席に着席してもよい。
【0129】
ついで、注文管理について説明する。注文に係るユーザ端末画面はユーザ端末画面117→118→119のように変化する。
【0130】
図14はユーザ端末画面117の例である。注文された料理リストが表示される(ステップ28)(ステップ31)。顧客は、ユーザ端末画面117を見て、自分が何を注文したのかを確認できる。注文リストと一緒に各注文に対応してキャンセルアイコンが表示されている。キャンセルされると注文リストから当該注文の表示が消去される。
【0131】
ユーザ端末画面117には注文リストに加えて注文アイコンが表示されている。注文アイコンを押すと、料理メニューを選択可能に提示するユーザ端末画面114が表示される。これにより追加注文もできる。また、ユーザ端末画面117には精算アイコンが表示されている。精算アイコンを押すと、キャンセル不可となる。
【0132】
図15はユーザ端末画面118の例である。本願システムにおいて、調理開始時(ステップ34)に契約成立とみなす点が特徴的である。調理開始後の注文に対応するキャンセルアイコンは調理中表示アイコンに変更される。なお、調理開始前の注文に対応するキャンセルアイコンはそのまま表示される。
【0133】
図16はユーザ端末画面119の例である。調理完了の注文に対応する調理中表示は調理完了表示に変更される。
【0134】
ユーザ端末画面119にも注文リストアイコンがそのまま表示され、すべての注文に対する料理の調理完了後も追加注文もできる。
【0135】
図17~20に厨房端末画面の遷移を示す。厨房端末画面は厨房端末画面121→122→123→124のように変化する。
【0136】
図17は、調理待ちを示す厨房端末画面121の例である。注文された料理リストが表示される(ステップ28)(ステップ31)。調理待ちアイコンが表示されている。顧客は、厨房端末画面121を見て、顧客が何を注文したのかを確認できる。なお、この時点ではキャンセル可能である。厨房の料理人も特別動作をすることはない。
【0137】
図18は、調理許可を示す厨房端末画面122の例である。上記動作例では調理許可後(ステップ32)、厨房端末画面121の対応する調理待ちアイコンが調理許可アイコンに変更される。なお、調理許可後、いつ調理開始するかの判断は、厨房の料理人に委ねられる。
【0138】
図19は、調理中を示す厨房端末画面123の例である。上記動作例では厨房側の判断で、調理を開始する(ステップ34)。厨房端末画面122の対応する調理許可アイコンを押すと、調理中アイコンが表示される。
【0139】
図20は、調理完了を示す厨房端末画面124の例である。上記動作例では調理完了後、調理完了報告する(ステップ36)。厨房端末画面123の対応する調理中アイコンを押すと、調理完了アイコンが表示される。注文した料理が全て調理完了すると、全て調理完了アイコンが表示される。
【0140】
【0141】
図21は、店員端末画面131の例である。カメラ付き店員端末3を介して、ユーザ端末画面115の2次元バーコードを読み取り(ステップ29)、顧客の予約済情報が表示される。さらに、座席情報が表示されている。店員端末画面131において顧客と座席を関連づけることができる。
【0142】
図22は、店員端末画面132の例である。調理完了を示す厨房端末画面124(ステップ36)と同様な情報が表示される。店員は店員端末画面132を見て、該当する座席に調理完了した料理を提供する。顧客に注文した料理が全て提供されているかを確認する店員確認アイコンが表示されている。
【0143】
~効果まとめ~
顧客は、顧客が所有するユーザ端末を操作することにより、店舗管理状況を把握でき、顧客利便性が高い。
【0144】
情報処理の殆どはサーバにより処理される。したがってユーザ端末に専用アプリをダウンロードやインストールする必要がない。この点でも、顧客利便性が高い。
【0145】
厨房の料理人は、厨房側の判断を優先することができ、調理に集中できる。
【0146】
店舗店員の動作は極めて少なく、店舗の省人化に寄与する。
【0147】
想定されるトラブルが回避されており、店舗管理人の負担が軽減される。
【符号の説明】
【0148】
1 顧客端末(ユーザ端末)
2 厨房端末
3 店員端末
6 店舗コード
10 サーバ
21 接続要求受付部
22 入店待ち状況管理部
23 予約部
24 メニュー提示部
25 注文受付部
26 入店確認部
31 調理許可部
32 調理開始管理部
33 調理待ち情報管理部
34 注文キャンセル部
35 調理中情報管理部
36 調理完了管理部
【手続補正書】
【提出日】2021-12-28
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
一度来店したものの入店できなかった顧客の便宜を図るシステムであって、
店舗店頭に提示されている店舗コードと、
前記店舗コードを読み取り可能なユーザ端末と、
前記ユーザ端末とネットワークを介して接続されるサーバと、
ネットワークを介してサーバと接続される厨房端末と
を備え、
前記サーバは、
前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する接続要求受付部と、
前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する入店待ち状況管理部と、
前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する予約部と、
前記予約完了情報を送信したユーザ端末に対し、メニュー情報を送信するメニュー提示部と、
前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、
前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、
前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、
前記厨房端末から、調理開始情報を受信する調理開始管理部と、
を有する
ことを特徴とする店舗管理補助システム。
【請求項2】
前記サーバは、
前記ユーザ端末に対し、キャンセル可能な状態で、調理待ち情報を提示する調理待ち情報管理部と、
前記メニュー情報を送信したユーザ端末から、注文キャンセル情報を受信し、注文をキャンセルする注文キャンセル部と、
前記調理開始情報に基づいて、前記ユーザ端末に対し、キャンセル不可な状態で、調理中情報を提示する調理中情報管理部と、
を有する
ことを特徴とする請求項1記載の店舗管理補助システム。
【請求項3】
前記サーバは、
前記厨房端末から、調理完了情報を受信し、前記ユーザ端末に調理完了情報を送信する調理完了管理部と、
を有する
ことを特徴とする請求項2記載の店舗管理補助システム。
【請求項4】
一度来店したものの入店できなかった顧客の便宜を図るシステムの一構成であるサーバであって、
店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末および厨房端末と、ネットワークを介して接続されるサーバであって、
前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する接続要求受付部と、
前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する入店待ち状況管理部と、
前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する予約部と、
前記ユーザ端末に対し、メニュー情報を送信するメニュー提示部と、
前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する注文受付部と、
前記ユーザ端末の所有者が入店したか否かを確認する入店確認部と、
前記厨房端末に対し、前記入店確認部による入店確認情報と前記注文受付部による注文情報とを含む調理許可情報を送信する調理許可部と、
前記厨房端末から、調理開始情報を受信する調理開始管理部と、
を有する
ことを特徴とするサーバ。
【請求項5】
一度来店したものの入店できなかった顧客の便宜を図るシステムの一構成であるサーバを用いた店舗管理補助方法であって、
店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末および厨房端末と、ネットワークを介して接続されるサーバが、
前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信し、
前記接続要求のあったユーザ端末に対し、入店待ち情報を送信し、
前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信し、
前記ユーザ端末に対し、メニュー情報を送信し、
前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信し、
前記ユーザ端末の所有者が入店したか否かを確認する入店確認情報を受信し、
前記厨房端末に対し、前記入店確認情報と前記注文情報とを含む調理許可情報を送信し、
前記厨房端末から、調理開始情報を受信する
ことを特徴とする店舗管理補助方法。
【請求項6】
一度来店したものの入店できなかった顧客の便宜を図るシステムの一構成であるサーバに実行させるプログラムであって、
店舗店頭に提示されている店舗コードを読み取り可能なユーザ端末および厨房端末と、ネットワークを介して接続されるサーバに、
前記店舗コードを読み取ったユーザ端末から、接続要求情報を受信する処理と、
前記接続要求のあったユーザ端末に対し、入店待ち情報を送信する処理と、
前記接続要求のあったユーザ端末に対し、ユーザ情報要求情報を送信し、前記ユーザ端末から、ユーザ情報を受信し、前記ユーザ端末に対し、予約完了情報を送信する処理と、
前記ユーザ端末に対し、メニュー情報を送信する処理と、
前記メニュー情報を送信したユーザ端末から、メニューから選択された注文情報を受信する処理と、
前記ユーザ端末の所有者が入店したか否かを確認する入店確認情報を受信する処理と、
前記厨房端末に対し、前記入店確認情報と前記注文情報とを含む調理許可情報を送信する処理と、
前記厨房端末から、調理開始情報を受信する処理と、
を実行させることを特徴とするプログラム。