IP Force 特許公報掲載プロジェクト 2022.1.31 β版

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

▶ 象印マホービン株式会社の特許一覧

特開2023-114937食品容器管理システム、食品容器管理方法、飲料容器
<>
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図1
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図2
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図3
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図4
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図5
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図6
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図7
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図8
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図9
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図10
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図11
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図12
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図13
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図14
  • 特開-食品容器管理システム、食品容器管理方法、飲料容器 図15
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023114937
(43)【公開日】2023-08-18
(54)【発明の名称】食品容器管理システム、食品容器管理方法、飲料容器
(51)【国際特許分類】
   G06Q 30/06 20230101AFI20230810BHJP
【FI】
G06Q30/06
【審査請求】未請求
【請求項の数】10
【出願形態】OL
(21)【出願番号】P 2022017549
(22)【出願日】2022-02-07
(71)【出願人】
【識別番号】000002473
【氏名又は名称】象印マホービン株式会社
(74)【代理人】
【識別番号】110000338
【氏名又は名称】弁理士法人 HARAKENZO WORLD PATENT & TRADEMARK
(72)【発明者】
【氏名】槇村 仁志
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049BB21
(57)【要約】
【課題】店舗で食品をユーザ専用の食品容器に入れて提供することができる食品容器管理システム等を実現する。
【解決手段】注文を受け付けた飲料を入れるボトルを管理するボトル管理システム(50)は、表示部(25)、撮影部(26)、および制御部(21)を備える。制御部(21)は、注文に対応付いたユーザ識別子に紐付けられているボトル識別子を表示部(25)に表示させる表示制御部(211)と、撮影部(26)にボトルからボトル識別子を読み取らせる読取制御部(212)と、読み取らせたボトル識別子と注文に対応付いたユーザ識別子とが対応しているかを判定する判定部(213)と、を備える。
【選択図】図3
【特許請求の範囲】
【請求項1】
注文を受け付けた食品を入れる食品容器を管理する食品容器管理システムであって、
表示装置と、取得装置と、情報処理装置とを備え、
前記情報処理装置は、
注文に対応付いたユーザ識別子に紐付けられている容器識別子を前記表示装置に表示させる表示制御部と、
前記取得装置に食品容器の容器識別子を取得させる取得制御部と、
前記取得装置に取得させた容器識別子と前記注文に対応付いたユーザ識別子とが対応しているか否かを判定する判定部と、を備える食品容器管理システム。
【請求項2】
前記取得制御部は、前記取得装置に前記食品容器から前記容器識別子を読み取らせる請求項1に記載の食品容器管理システム。
【請求項3】
前記食品容器は、飲料を入れる飲料容器である請求項1または2に記載の食品容器管理システム。
【請求項4】
前記食品容器は、飲料以外の食品を入れる容器である請求項1または2に記載の食品容器管理システム。
【請求項5】
前記食品容器は、それぞれ分離不可能な複数の部分からなり、
前記複数の部分のそれぞれに前記取得装置で読み取り可能な前記容器識別子が設けられ、
前記判定部は、前記複数の部分のそれぞれの前記容器識別子が、前記注文に対応付いたユーザ識別子と対応しているか否かを判定する請求項2に記載の食品容器管理システム。
【請求項6】
前記複数の部分は、前記食品容器の本体部と、前記本体部を塞ぐと共に前記本体部に対して着脱可能な蓋部と、を含む請求項5に記載の食品容器管理システム。
【請求項7】
注文を受け付けた食品を入れる食品容器を管理する食品容器管理方法であって、
注文に対応付いたユーザ識別子に紐付けられている容器識別子を表示する表示ステップと、
食品容器の容器識別子を取得する取得ステップと、
取得した容器識別子と前記注文に対応付いたユーザ識別子とが対応しているか否かを判定する判定ステップと、を含む食品容器管理方法。
【請求項8】
前記判定ステップの判定結果が、取得した容器識別子と前記注文に対応付いたユーザ識別子とが対応していることを示す場合、作業者が、注文を受け付けた前記食品を前記食品容器に入れるステップを含む、請求項7に記載の食品容器管理方法。
【請求項9】
飲料を入れる本体部と、
前記本体部を塞ぐと共に前記本体部に対して着脱可能な蓋部と、を備え、
前記本体部の底面および前記蓋部の天面のそれぞれに対応する容器識別子が読み取り可能に設けられている飲料容器。
【請求項10】
円筒形である請求項9に記載の飲料容器。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、食品容器を管理するシステム等に関する。
【背景技術】
【0002】
従来から環境問題に対応して、店舗で食品を提供する際に食品を入れる食品容器を繰り返し使用することが行われている。例えば、下記の特許文献1には、リユース容器を利用して飲料の販売を行うに際して、容器を回収・洗浄・再使用する際の環境負荷をできる限り少なくするリユースボトル管理システムが開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2021-72038号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、上述のような従来技術は、リユース容器を用いるシステムであり、ユーザ専用の容器ではない。そのため、他のユーザが使用した容器を使用することに抵抗があるユーザも存在した。このようなユーザは、自前の容器(所謂マイボトル)を店舗に持参して食品の提供を受けることとなるが、自前容器は常に携帯し、自分で容器を洗浄しなくてはならないという面倒な点がある。
【0005】
本発明の一態様は、ユーザ専用の食品容器を店舗で保管しつつ、注文を受け付けた場合に、間違えることなく注文したユーザのユーザ専用の食品容器に食品を入れて提供することができる食品容器管理システム等の実現を目的とする。
【課題を解決するための手段】
【0006】
上記の課題を解決するために、本発明の一態様に係る食品容器管理システムは、注文を受け付けた食品を入れる食品容器を管理する食品容器管理システムであって、表示装置と、読取装置と、情報処理装置とを備え、前記情報処理装置は、注文に対応付いたユーザ識別子に紐付けられている容器識別子を前記表示装置に表示させる表示制御部と、前記読取装置に食品容器から容器識別子を読み取らせる取得制御部と、前記読取装置に読み取らせた容器識別子と前記注文に対応付いたユーザ識別子とが対応しているか否かを判定する判定部と、を備える。
【0007】
上記の課題を解決するために、本発明の一態様に係る食品容器管理方法は、注文を受け付けた食品を入れる食品容器を管理する食品容器管理方法であって、注文に対応付いたユーザ識別子に紐付けられている容器識別子を表示する表示ステップと、食品容器から容器識別子を読み取る読取ステップと、読み取った容器識別子と前記注文に対応付いたユーザ識別子とが対応しているか否かを判定する判定ステップと、を含む。
【0008】
上記の課題を解決するために、本発明の一態様に係る飲料容器は、飲料を入れる本体部と、前記本体部を塞ぐと共に前記本体部に対して着脱可能な蓋部と、を備え、前記本体部の底面および前記蓋部の天面のそれぞれに対応する容器識別子が読み取り可能に設けられている。
【発明の効果】
【0009】
本発明の一態様によれば、ユーザ専用の食品容器を店舗で保管しつつ、注文を受け付けた場合に、間違えることなく注文したユーザのユーザ専用の食品容器に食品を入れて提供することができる。
【図面の簡単な説明】
【0010】
図1】本発明の実施形態1に係るボトル管理システムおよび注文管理システムが含まれる飲料注文システムの概要を示す図である。
図2】上記ボトル管理システムで管理されるボトルの構成を示す図である。
図3】店舗端末の構成例を示すブロック図である。
図4】記憶部に記憶される注文管理テーブルの例を示す図である。
図5】記憶部に記憶されるボトル管理テーブルの例を示す図である。
図6】記憶部に記憶される注文可否テーブルの例を示す図である。
図7】上記ボトル管理システムにおいて表示部に表示される表示例を示す図である。
図8】上記ボトル管理システムにおいて表示部に表示される別の表示例を示す図である。
図9】上記ボトル管理システムにおけるボトルを管理する処理の一例を示すフローチャートである。
図10】上記注文管理システムにおける注文を管理する処理の一例を示すフローチャートである。
図11】本発明の実施形態2に係るボトル管理システムおよび注文管理システムが含まれる飲料注文システムの概要を示す図である。
図12】上記ボトル管理システムに備えられる、ロッカー装置の電気的な構成を示すブロック図である。
図13】記憶部に記憶される注文管理テーブルの例を示す図である。
図14】記憶部に記憶されるボトル管理テーブルの例を示す図である。
図15】上記ボトル管理システムにおいて表示部に表示される別の表示例を示す図である。
【発明を実施するための形態】
【0011】
〔実施形態1〕
以下、本発明の一実施形態について、詳細に説明する。なお、本実施形態では、食品容器は、飲料を入れる飲料容器(以下、ボトルと称する)である構成を例示するが、食品容器は、飲料以外の食品を入れる容器であってもよい。
【0012】
(1.飲料注文システムおよびボトル管理システムの概要)
図1は、本発明の一実施形態に係るボトル管理システム50および注文管理システム60が含まれる飲料注文システム100の概要を示す図である。飲料注文システム100は、飲料を注文した注文者にユーザ専用のボトルに飲料を入れて提供するシステムであり、ボトル管理システム(食品容器管理システム)50および注文管理システム60を含むシステムである。なお、以下では、飲料注文システム100を利用して飲料を注文する注文者をユーザと呼ぶ。
【0013】
図1に示すように、飲料注文システム100には、ユーザの端末装置1、店舗に設置された店舗端末2、およびボトル(食品容器)3が含まれる。店舗は、ユーザに飲料をユーザ専用のボトル3に入れて提供(販売)する。店舗は、ユーザより使用済みのユーザ専用のボトル3を回収し、洗浄して保管し、当該ユーザの次回の注文時に、保管しているユーザ専用のボトル3に飲料を入れて提供する。
【0014】
端末装置1は、ユーザである注文者が飲料注文システム100を利用するために用いる装置である。端末装置1は、例えばスマートフォンやタブレットPC(Personal Computer)であってもよい。端末装置1は、携帯型の装置であることが好ましい。
【0015】
飲料注文システム100を利用するための端末装置1の各機能は、汎用のコンピュータにプログラムをインストールすることにより実現することもできる。上記プログラムは、アプリケーションソフトウェア(以下、飲料注文ユーザ用アプリと称する)と呼ぶこともできる。以下では、端末装置1が、飲料注文ユーザ用アプリをインストールしたスマートフォンである例を説明する。
【0016】
店舗端末2は、店舗が飲料注文システム100を利用して飲料を提供(販売)するために用いられる装置である。店舗端末2は、画像の表示、画像の読み取り、通信機能等を備えたものであればよく、設置型の装置であっても、タブレットPC等であってもよい。
【0017】
飲料注文システム100を利用するための店舗端末2の各機能は、汎用のコンピュータにプログラムをインストールすることにより実現することもできる。上記プログラムは、アプリケーションソフトウェア(以下、飲料注文店舗用アプリと称する)と呼ぶこともできる。以下では、店舗端末2が、飲料注文店舗用アプリをインストールしたタブレットPCである例を説明する。
【0018】
ボトル3は、注文を受け付けた飲料を入れるための容器である。ボトル3は、注文者である各ユーザに紐付けられたユーザ専用のボトルである。ボトル3は、ボトルを一意に識別するためのボトル識別子(容器識別子)が付けられている。ボトル識別子は、ボトル3を一意に識別できるものであればよく、例えば、ボトル3毎に付される製造番号(シリアル番号)等を用いることができる。
【0019】
なお、ボトル3は、ユーザが飲料注文システム100を初めて利用する際に購入し、自前の容器としてもよい。また、ボトル3は、ユーザが飲料注文システム100を初めて利用する際に保証金を預け、ユーザ専用のボトルとして借り受けてもよい。あるいは、ユーザがすでに保有するボトルを持参し、店舗でボトル識別子を発行するようにしてもよい。
【0020】
店舗は、このようにユーザに紐付けられたボトル3を管理するために、ボトル管理システム(食品容器管理システム)50を導入している。ボトル管理システム50は、注文を受け付けた飲料(食品)を入れるボトルを管理するシステムである。本実施形態では、ボトル管理システム50は、第1および第2の2つの機能を有している。
【0021】
第1機能は、後述のように、ユーザに対応付けてユーザ専用のボトル3のステータスを管理する機能である。第1機能を有することで、ボトル管理システム50は、ユーザ専用のボトル3を店舗で保管し、注文を受けた飲料をユーザ専用のボトル3に入れて提供する仕組みを実現する。本実施形態での説明において、図1に示す、「預かり中」、「注文準備中」、「店頭準備完了」、「洗浄段階」は、ボトルが店舗側に有る状態を示し(図1中では、「---(破線)店舗側ステータス」にて示す)、「使用中」は、ボトルがユーザ側に有る状態を示している(図1中では、「―――(実線)ユーザ側ステータス」にて示す)。
【0022】
第2機能は、後述のように、ボトル3から読み取らせたボトル識別子とユーザ識別子とが対応しているか否かを判定する機能である。第2機能を有することで、ボトル管理システム50は、ユーザ専用のボトル3を店舗で保管しつつ、ユーザより注文を受けた場合に、間違えることなく注文を行ったユーザの専用のボトル3に飲料を入れて提供する仕組みを実現する。
【0023】
ボトル管理システム50は、店舗端末2に備えられている。ボトル管理システム50を利用するための店舗端末2の各機能は、汎用のコンピュータにプログラムをインストールすることにより実現することもできる。上記プログラムは、アプリケーションソフトウェア(以下、ボトル管理アプリと称する)と呼ぶこともできる。ボトル管理アプリは、飲料注文店舗用アプリに含めることができる。その場合、飲料注文店舗用アプリをインストールした店舗端末2がボトル管理システム50としての機能を備える。
【0024】
店舗は、このように「ユーザに紐付けられたボトル3に飲料を入れて提供するサービス」の注文を受け付けて管理するために、注文管理システム60を導入している。注文管理システム60は、飲料をボトル3に入れて提供する注文を受け付けて管理するシステムである。
【0025】
注文管理システム60は、店舗端末2に備えられている。注文管理システム60を利用するための店舗端末2の各機能は、汎用のコンピュータにプログラムをインストールすることにより実現することもできる。上記プログラムは、アプリケーションソフトウェア(以下、注文管理アプリと称する)と呼ぶこともできる。注文管理アプリは、飲料注文店舗用アプリに含めることができる。その場合、飲料注文店舗用アプリをインストールした店舗端末2が注文管理システム60としての機能を備える。
【0026】
(2.ボトル)
図2は、上記ボトル管理システム50で管理されるボトル3の構成を示す図である。図2に示すように、ボトル3は、飲料を入れる本体部3aと、本体部3aを塞ぐと共に本体部3aに対して着脱可能な蓋部3bと、を備える。本体部3aの底面3a1および蓋部3bの天面3b1のそれぞれに対応するボトル識別子が読み取り可能に設けられる。
【0027】
ボトル識別子は、店舗の作業者やユーザ等の人が視認できる文字表記と、後述する撮影部26(図3参照)の読み取りに適した光学読み取りマークであるコード情報(一次元コードや二次元コード等)Qとで設けられる。図2の例では、ボトル識別子である「12345」との文字表記と、「12345」を示す二次元コードのコード情報Qとが設けられている。
【0028】
このように、ボトル3が本体部3aと蓋部3bの複数の部分からなる場合、それぞれの部分にボトル識別子を設けることで、ボトル3を構成する各部分をユーザに紐付けて管理することができる。
【0029】
なお、ここでは、本体部3aと蓋部3bの2つの部分からなるボトル3を例示したが、ボトル等の食品容器が、それぞれ分離不可能な複数の部分からなる場合、複数の部分それぞれにボトル識別子が設けられる。
【0030】
また、本体部3aの底面3a1および蓋部3bの天面3b1にコード情報Qを設けているので、撮影部26(図3参照)に向けるボトル3の軸方向の向きを変えるだけで簡単にコード情報Qを読み取らせることができる。これに対し、本体部3aおよび蓋部3bの各側面(周面)にコード情報Qが設けられていた場合は、ボトル3を回転させてコード情報Qが設けられている位置を確認してから読み取らせる必要が有り、作業性に劣る。また、撮影部26にコード情報Qを読み取らせる作業だけでなく、作業者が保管されている複数のボトル3の中から、必要なボトル3を探し出す際の作業も容易に行える。
【0031】
図2では、円筒形のボトル3を例示したが、ボトル3の形状は特に限定されるものではない。しかしながら、円筒形のボトルの場合、本体部3aおよび蓋部3bの各側面は曲面となる。そのため、側面にコード情報Qを設けた場合に、側面が平面である場合よりも読み取りエラーの発生頻度が高くなる恐れがある。したがって、円筒形のボトル3の場合、図2に示す例のように、ボトル識別子のコード情報Qを、本体部3aの底面3a1および蓋部3bの天面3b1に設けることが好ましい。
【0032】
(3.店舗端末の構成例)
図3は、店舗端末2の構成例を示すブロック図である。図3に示すように、店舗端末2は、店舗端末2の各部を統括して制御する制御部21と、店舗端末2が使用する各種データを記憶する記憶部22を備えている。また、店舗端末2は、店舗端末2に対する入力操作を受け付ける入力部(取得装置)23、店舗端末2が他の装置と通信するための通信部24、画像を表示する表示装置である表示部25、および画像を撮影する撮影装置(読取装置、取得装置)である撮影部26を備えている。入力部23はタッチパネルであってもよく、この場合、表示部25の表示面が入力部23の入力面を兼ねることになる。撮影部26は、少なくともボトル3に設けられているボトル識別子を読み取る機能を有していればよい。
【0033】
制御部21には、注文管理部214、ボトル管理部(食品容器管理部)215、表示制御部211、読取制御部(取得制御部)212、および判定部213が含まれている。制御部21は、本実施形態におけるボトル管理システム50の情報処理装置である。また、制御部21は、本実施形態における注文管理システム60の情報処理装置である。記憶部22には、それぞれ後述する、注文管理テーブル221(図4参照)、ボトル管理テーブル222(図5参照)および注文可否テーブル223(図6参照)が記憶されている。
【0034】
上述のように、店舗端末2の注文管理システム60の各機能、すなわち注文管理部214および注文管理テーブル221の各機能は、注文管理アプリにより実現することもできる。同様に、店舗端末2のボトル管理システム50の各機能、すなわち表示制御部211、読取制御部212、判定部213、ボトル管理部215、およびボトル管理テーブル222の各部の機能は、ボトル管理アプリにより実現することもできる。
【0035】
注文管理部214は、通信部24、又は入力部23にて受け付けた注文を注文管理テーブル221(図4参照)に登録する処理を行う。注文管理部214は、通信部24、又は入力部23より、飲料注文システム100において商品を提供するために必要な情報の入力を受け付ける。具体的には、注文管理部214は、注文したユーザ識別子、注文する商品の情報、商品を受け取る受取予定日時の情報等の入力を受け付ける。ユーザ識別子は、ユーザを一意に識別できるものであればよく、例えばユーザ名やユーザ識別子等であってもよい。必要な情報には、登録されている受け付け済の注文のキャンセルする情報等も含まれる。
【0036】
本実施形態では、注文管理部214は、ボトル管理部215にて管理されているユーザに紐付けられている食品容器のステータスを参照し、ステータスに基づいて、ユーザからの注文を受け付け可能か否かを判定する。
【0037】
注文管理部214は、注文の受け付けが可能であると判定した場合に、受け付けた注文を注文管理テーブル221に登録する。ボトル3のステータスは、ボトル管理テーブル222(図5参照)に記憶されている。ステータスと注文の受け付け可否の関係は、注文可否テーブル223(図6参照)に記憶されている。
【0038】
また、注文管理部214は、通信部24、又は入力部23より、注文管理テーブル221に登録している注文のキャンセルを受け付ける。注文管理部214は、キャンセルを受け付けると、注文管理テーブル221に登録されている注文(キャンセルを受け付けた注文)にキャンセルのフラグを立てるなどして、注文をキャンセルする。
【0039】
本実施形態では、注文管理部214は、ボトル3のステータスを参照し、受付済の注文においてユーザに飲料を提供する予定時刻の所定時間(以下、第2所定時間と称する)前の時点でボトル3が店舗側に無い場合、当該注文をキャンセルする。後述する「使用中」が、ボトル3が店舗側に無い状態を示すステータスである。
【0040】
注文管理部214は、注文を受け付けた場合、注文を受け付けたことを通信部24を介してユーザの端末装置1に通知する。同様に、注文管理部214は、注文のキャンセルを受け付けた場合、および注文管理部214側からキャンセルした場合、注文をキャンセルしたことを、通信部24を介してユーザの端末装置1に通知する。
【0041】
ボトル管理部215は、通信部24、又は入力部23にて受け付けたユーザ識別子とボトル3のボトル識別子をボトル管理テーブル222に登録する処理を行う。飲料注文システム100を利用して最初に飲料を提供する際に、受け付けた注文のユーザ識別子と、該ユーザに対応付けるボトル3のボトル識別子を登録する。ボトル3のボトル識別子は、読取制御部212がボトル3に設けられているコード情報Qから読み取る。
【0042】
また、ボトル管理部215は、注文を行うユーザに対応付けて、当該ユーザに紐付けられているボトル3のステータスを管理する。ボトル管理部215は、例えば、ボトル3のステータスとして、少なくとも、ボトル3が、店舗側に有るか無いかを管理する。また、ボトル管理部215は、ボトル3が店舗側に有る場合、ボトル3は洗浄済みであるか、飲料を入れる注入準備の段階にあるか、飲料が入れられて提供可能な状態にあるか、などを管理してもよい。
【0043】
本実施形態では、ボトル管理部215は、ボトル3のステータスとして、「預かり中」、「使用中」、「注文準備中」、「店頭準備完了」、および「洗浄段階」の項目にて管理する。なお、ここで例示した項目は、あくまで一例であり、これらの各項目を、どのように称呼するか、どのように管理するための項目とするか等は、本飲料注文システム100の利用側(実施形態では店舗側)が任意に設定できる。また各項目をさらに細かく細分化することも任意で設定可能である。
【0044】
ボトル管理部215は、入力部23からの入力、あるいは入力部23からの入力と撮影部26による容器識別子の読み取り等に基づいて、ボトル3のステータスの管理に必要な情報の入力を受け付ける。
【0045】
表示制御部211は、表示部25を制御する。ボトル管理システム50が第1機能を有している場合、表示制御部211は、ボトル管理テーブル222を参照して、ボトル3のステータスを表示部に表示させる。ボトル管理システム50が第2機能を有している場合、表示制御部211は、注文に対応付いたユーザ識別子に紐付けられているボトル識別子を表示部25に表示させる。表示制御部211は、ボトル管理テーブル222を参照して、注文に対応付いたユーザ識別子に紐付けられているボトル識別子の情報を取得する。
【0046】
読取制御部212は、撮影部26を制御する。読取制御部212は、撮影部26にボトル3からボトル識別子を読み取らせる。これにより、読取制御部212は、ボトル識別子を取得する。なお、本実施形態における読取制御部212は、入力部23(取得装置)に店舗作業者によるボトル識別子の入力を受け付けさせることで、ボトル識別子を取得する。あるいは、ユーザによるボトル識別子の入力を受け付けさせることで、ボトル識別子を取得してもよい。
【0047】
判定部213は、撮影部26に読み取らせたボトル識別子と注文に対応付いたユーザ識別子とが対応しているかを判定する。判定部213は、ボトル3が分離不可能な複数の部分からなる場合、各部分にそれぞれ設けられているボトル識別子が、注文に対応付いたユーザ識別子と対応しているかを判定する。つまり、本体部3aと蓋部3bの両方に対して、それぞれに設けられているボトル識別子がユーザ識別子に対応しているかを判定する。本実施形態では、判定部213は判定結果を表示制御部211に送信し、表示制御部211が表示部25に判定結果を表示させる。
【0048】
(4.記憶部に記憶されるデータの例)
図4は、記憶部22に記憶される注文管理テーブル221の例を示す図である。図4に示す注文管理テーブル221では、注文番号、注文日時、商品、受取予定日時、注文したユーザのユーザ識別子、およびキャンセルフラグが対応付けられている。
【0049】
注文番号は、注文を受け付けた順に付され、受け付けた注文の識別に用いられる情報である。注文日時は、注文を受け付けた日時の情報である。商品は、注文を受け付けた商品の情報である。受取予定日時は、注文を受け付けた商品をユーザが受け取る予定の日時の情報である。ユーザ識別子は、受け付けた注文を行ったユーザのユーザ識別子である。
【0050】
図4に示す注文管理テーブル221では、注文番号「000001」の注文は、ユーザ識別子「0001」のユーザより、2021年11月1日の15時10分に、2021年11月3日の8時45分の受け取り予定で、ブレンドコーヒの注文を受けたことを示す。注文番号「000004」の注文は、キャンセルフラグが「1」となっており、ユーザ識別子「0117」のユーザよりなされた注文がキャンセルされたことを示している。これらの情報は、飲料注文システム100を利用したユーザからの注文を、店舗端末2が通信部24又は入力部23で受け付けた時に入力される。
【0051】
図5は、記憶部22に記憶されるボトル管理テーブル222の例を示す図である。図5に示すボトル管理テーブル222では、ユーザ識別子とボトル識別子とボトル3のステータスとが対応付けられている。ユーザが複数のボトル3を購入あるいは借り受けて使用している場合、ユーザ識別子に対して複数のボトル識別子が対応付けられる。図5に示すボトル管理テーブル222では、ユーザ識別子「0003」のユーザに、「27531」および「32541」の2つのボトル識別子が対応付けられる。
【0052】
ボトル管理部215は、ボトル3のステータスとして、上述したように、「預かり中」、「使用中」、「注文準備中」、「店頭準備完了」、および「洗浄段階」の項目にて管理する。
【0053】
「預かり中」は、ボトル3が店舗側に有り、洗浄済みで、飲料を入れる準備が整っていることを示すステータスである。「使用中」は、ボトル3がユーザ側に有る、つまり、店舗側に無いことを示すステータスである。「注文準備中」は、ボトル3が店舗側に有り、かつ、飲料を入れる注入準備の段階にあることを示すステータスである。ボトル管理部215は、現時刻がユーザに飲料提供する受取予定日時の第1所定時間(所定時間)前を過ぎたかを管理している。受取予定日時の第1所定時間(例えば20分)前になると、ステータス「注文準備中」となる。「店頭準備完了」は、ボトル3が店舗側に有り、かつ、飲料が入れられてユーザに受け渡し可能であることを示すステータスである。「洗浄段階」は、ボトル3が店舗側に有り、かつ、洗浄完了前の(洗浄中を含み、まだ飲料をボトルに入れられない)段階にあることを示すステータスである。
【0054】
図5に示すボトル管理テーブル222では、例えば、ユーザ識別子「0001」のユーザに紐付けられているボトル3(識別子「12345」)は、「預かり中」であることを示す。また、ユーザ識別子「0002」のユーザに紐付けられている識別子「56914」のボトル3は「注文準備中」であることを示す。ユーザ識別子「0003」のユーザに紐付けられている識別子「32541」のボトル3は「使用中」であることを示す。
【0055】
図6は、記憶部22に記憶される注文可否テーブル223の例を示す図である。図6に示す注文可否テーブル223では、ステータスと注文の受け付け可否の関係が設定されている。注文管理部214は、注文可否テーブル223の設定に基づいて、注文を受け付け可能か否かを判定する。
【0056】
図6に示す注文可否テーブル223では、「注文準備中」および「店頭準備完了」に受付不可が設定されている。注文管理部214は、ボトル3のステータスが、「注文準備中」および「店頭準備完了」の場合、受け付け不可と判定する。「注文準備中」および「店頭準備完了」は、ユーザに紐付けられているボトル3に飲料が注入される段階、あるいは既に注入されている状態である。そのため、ユーザからの飲料の種類や量の変更、受取予定日時の変更、注文キャンセル等、全て不可としてもよい。
【0057】
一方、「預かり中」、「使用中」および「洗浄段階」には受付可が設定されている。注文管理部214は、ボトル3のステータスが、「預かり中」、「使用中」および「洗浄段階」である場合、受け付け可と判定する。飲料の種類や量の変更、受取予定日時の変更、注文キャンセル等、全て可となる。
【0058】
(5.ボトルのステータスの管理)
ここで、ボトル管理システム50によるボトル3のステータスの管理の一例を、図1を用いて説明する(第1機能)。図1に示すように、ボトル3が店舗側に有り、ボトル3の洗浄が完了している状態では、ボトル管理部215は、ステータスを「預かり中」とする。ボトル3が購入あるいは借り受けられ、ボトル管理テーブル222に新たに登録された場合も、ボトル管理部215は、ステータスを「預かり中」とする。
【0059】
ボトル3が店舗側に有り、かつ、現時刻が受け付けた注文の受取予定日時の第1所定時間前(例えば20分前)になる(内部タイマーによるトリガー入力)と、ボトル管理部215は、ステータスを「預かり中」から「注文準備中」に切り換え、表示制御部は表示装置に準備開始指示を表示することによって店舗作業者に飲料準備開始を促す。作業者が、ボトル3に飲料を入れ、作業者がユーザに受け渡し可能となったことを入力(トリガー入力)すると、ボトル管理部215は、ステータスを「注文準備中」から「店頭準備完了」に切り換える。注文管理部214は、ステータスが「注文準備中」から「店頭準備完了」に切り換えられると、飲料の準備が完了したことを示す「商品のお渡し準備ができました!」等のメッセージを当該注文のユーザの端末装置1に通知する。
【0060】
ユーザがボトル3を受け取り、作業者が、ユーザがボトル3を受け取ったことを入力(トリガー入力)すると、ボトル管理部215は、ステータスを「店頭準備完了」から「使用中」に切り換える。その後、ユーザが、ボトル3を店舗に返却し、作業者が、ボトル3の返却がなされたことを入力(トリガー入力)すると、ボトル管理部215は、ステータスを「使用中」から「洗浄段階」に切り換える。ボトル3の洗浄が完了し、作業者が、洗浄が完了したことを入力(トリガー入力)すると、ボトル管理部215は、ステータスを「洗浄段階」から「預かり中」に切り換える。
【0061】
作業者は、ステータスを切り換えるための入力(トリガーとなる入力)を行う際、入力部23を用いた入力に加えて、撮影部26を用いてボトル識別子を読み取らせてもよい。ボトル識別子を読み取らせることで、ステータスを切り替えるべきボトル3の情報を、店舗端末2に容易に入力することができる。また、「預かり中」から「注文準備中」へのステータスの切り換えのために、現時刻が受取予定日時の第1所定時間前になった時点で、注文管理部214からボトル管理部215へ信号を送信するようにしてもよい。ボトル管理部215は、該信号の入力をトリガーとして、ステータスを「預かり中」から「注文準備中」へ切り換える。
【0062】
(6.表示部に表示される表示の例)
図7は、ボトル管理システム50において表示部25に表示される表示例を示す図である(第2機能)。図7の画面701は、図4に示す注文管理テーブル221における、注文番号「000001」の注文の飲料提供時に、表示制御部211が表示部25に表示させる、飲料の提供準備を作業者に指示する画面である。また、この画面には、「受け渡し時刻」または、受け渡し時刻までの残り時間を示す「あと〇〇分(例えば10分)」等の、作業者に時間的な告知を行うメッセージを表示してもよい。
【0063】
表示制御部211は、例えば、受取予定日時の第1所定時間、例えば20分前になると、注文管理テーブル221およびボトル管理テーブル222を参照して、画面701を表示する。画面701には、注文番号「000001」、商品名「ブレンドコーヒ」、注文したユーザのユーザ識別子「0001」、および当該ユーザ識別子に紐付けられているボトル識別子「12345」が表示される。
【0064】
作業者は、画面701を見て、保管している複数のボトル3の中から、表示されている「12345」のボトル識別子のボトル3を選び出す。次に作業者は、「ボトル確認(本体部)」の第1欄30の横の第1カメラアイコン31をタップして撮影部26を起動させ、ボトル3の本体部3aに設けられているコード情報Qを読み取らせる(図2参照)。
【0065】
画面702,703に示すように、本体部3aより読み取ったコード情報Qで示されるボトル識別子(以下、読み取ったボトル識別子と呼ぶ)は、第1欄30に表示される。画面502に示すように、注文番号「000001」のユーザ識別子に対応するボトル識別子と読み取ったボトル識別子とが同じである場合、第1欄30の下に「確認できました。」と表示される。これにより、作業者は、本体部3aが正しいことを確認する。
【0066】
一方、画面703に示すように、注文番号「000001」のユーザ識別子に対応するボトル識別子と読み取ったボトル識別子とが異なる場合、第1欄30の下に「ボトルが間違っています。」と表示される。これにより、作業者は、選び出したボトル3が間違っていたことを認識する。この場合は、作業者は、保管している複数のボトル3の中からボトル3を選び直す。そして、第1カメラアイコン31を再びタップするなどして画面501に戻し、選び直したボトル3の本体部3aに設けられているコード情報Qを読み取らせる。
【0067】
本体部3aの確認を終えると、作業者は、続けて「ボトル確認(蓋部)」の第2欄32の横の第2カメラアイコン33をタップして撮影部26を起動させ、ボトル3の蓋部3bに設けられているコード情報Qを読み取らせる(図2参照)。
【0068】
画面704,705に示すように、蓋部3bより読み取ったボトル識別子は、第2欄32に表示される。画面704に示すように、注文番号「000001」のユーザ識別子に対応するボトル識別子と読み取ったボトル識別子とが同じである場合、第2欄32の下に「確認できました。」と表示される。これにより、作業者は、蓋部3bが正しいことを確認する。
【0069】
一方、画面705に示すように、注文番号「000001」のユーザ識別子に対応するボトル識別子と読み取ったボトル識別子とが異なる場合、第2欄32の下に「ボトルが間違っています。」と表示される。これにより、作業者は、本体部3aと蓋部3bとの組み合せが間違っていたことを認識する。この場合、作業者は、表示されている蓋部3bを読み取ったボトル識別子を手掛かりに正しい蓋部3bを探し出し、本体部3aと蓋部3bの組み合わせを正す。その後、第2カメラアイコン33を再びタップするなどして画面502に戻し、選び直した蓋部3bに設けられているコード情報Qを読み取らせる。
【0070】
図8は、ボトル管理システム50において表示部25に表示される別の表示例を示す図である(第1機能)。図8の画面801は、作業者が、注文番号「000009」の注文を行ったユーザのボトル3のステータスの確認操作を行った場合に、表示制御部211が表示部25に表示させる、ステータス確認画面である。
【0071】
表示制御部211は、例えば、作業者が、注文一覧画面(図示せず)等から、注文番号「000009」の注文に対して、ステータス確認ボタン等をタップすると、注文管理テーブル221およびボトル管理テーブル222を参照して、画面801を表示する。画面801には、注文番号、注文日時、受取予定日時と共に、ステータスが表示される。画面801では、飲料提供からボトル回収までの手順に沿って、「注文準備中」→「店頭準備完了」→「使用中」→「洗浄段階」→「預かり中」の順で項目が並べられ、現在のステータスである「使用中」が色を変えて表示される。
【0072】
(7.ボトルを管理する処理の流れ)
図9は、ボトル管理システム50におけるボトルを管理する処理(食品容器管理方法)の一例を示すフローチャートである(第2機能)。図9の処理は、店舗端末2においてボトル管理アプリを含む飲料注文店舗用アプリが起動されたときに行われる。なお、以下の各処理の実行主体は、ボトル管理アプリ、あるいはボトル管理アプリを含む飲料注文店舗用アプリと読み替えることもできる。
【0073】
制御部21は、表示部25に基準画面を表示している(S1)。制御部21は、注文管理テーブル221で管理している何れかの注文の受取予定日時の第1所定時間前になったかを常(あるいは定期的)に判定している(S2)。制御部21(表示制御部211)は、第1所定時間前になったと判定すると(S2でYES)、飲料の提供準備を作業者に指示する画面(図7の画面701参照)を表示する(S3:表示ステップ)。画面701が表示されると、ボトル3のステータスは「預かり中」から「注文準備中」に切り換わる。
【0074】
制御部21は、飲料の提供準備を作業者に指示する画面において、第1カメラアイコン31のタップがなされたかを判定する(S4)。制御部21(読取制御部212)は、タップがなされたと判定すると(S4でYES)、撮影部26を起動させ、ボトル3の本体部3aのコード情報Qの読み取りを行う(S5:読取ステップ)。
【0075】
制御部21(判定部213)は、S5で読み取ったコード情報Qにて示されるボトル識別子(読み取ったボトル識別子)と、当該注文のユーザ識別子とが対応するかを判定する(判定ステップ)。ここでは、制御部21(判定部213)は、読み取ったボトル識別子と、当該注文のユーザ識別子に紐付けられているボトル識別子(注文に紐付いているボトル識別子)とが一致するかを判定する(S6)。
【0076】
制御部21(表示制御部211)は、読み取ったボトル識別子と注文に紐付いているボトル識別子とが一致すると判定すると(S6でYES)、第1欄30の下に「正しいボトルです。」(図7の画面702参照)を表示する(S7)。この場合、S9の処理に進む。
【0077】
一方、読み取ったボトル識別子と注文に紐付いているボトル識別子とが一致しないと判定すると(S6でNO)、制御部21(表示制御部211)は、第1欄30の下に「ボトルが間違っています。」(図7の画面703参照)を表示する(S8)。この場合、S4の処理に戻る。
【0078】
制御部21は、飲料の提供準備を作業者に指示する画面において、第2カメラアイコン33のタップがなされたかを判定する(S9)。制御部21(読取制御部212)は、タップがなされたと判定すると(S9でYES)、撮影部26を起動させ、ボトル3の蓋部3bのコード情報Qの読み取りを行う(S10:読取ステップ)。なお、読取制御部212は、入力部23(取得装置)に作業者によるボトル識別子の入力を受け付けさせることで、ボトル識別子を取得してもよい。
【0079】
制御部21(判定部213)は、S10で読み取ったボトル識別子と、当該注文のユーザ識別子とが対応するかを判定する(判定ステップ)。ここでは、制御部21(判定部213)は、読み取ったボトル識別子と、当該注文に紐付いているボトル識別子とが一致するかを判定する(S11)。
【0080】
制御部21(表示制御部211)は、読み取ったボトル識別子と注文に紐付いているボトル識別子とが一致すると判定すると(S11でYES)、第2欄32の下に「正しいボトルです。」(図7の画面704参照)を表示する(S12)。この場合、S14の処理に進む。
【0081】
一方、読み取ったボトル識別子と注文に紐付いているボトル識別子とが一致しないと判定すると(S11でNO)、制御部21(表示制御部211)は、第2欄32の下に「ボトルが間違っています。」(図7の画面705参照)を表示する(S13)。この場合、S9の処理に戻る。
【0082】
制御部21は、飲料の提供準備を作業者に指示する画面に設けられているクリアボタン(図示せず)のタップがなされたかを判定する(S14)。制御部21(読取制御部212)は、タップがなされたと判定すると(S14でYES)、S1の処理に戻る。なお、S1の処理に戻るためのクリアボタンは、図7の画面701~705の各画面に設けられている。便宜上、図9のフローチャートでは、図7の画面701~703,705の画面でクリアボタンがタップされた場合の処理の記載を省略している。作業者は、判定結果がユーザ識別子とボトル識別子とが対応していることを示す場合、注文を受け付けた飲料(この場合はブレンドコーヒ)をボトル3に入れるステップに進む。
【0083】
(8.注文を受け付けて管理する処理の流れ)
図10は、注文管理システム60における注文を管理する処理(注文管理方法)の一例を示すフローチャートである。図10の処理は、店舗端末2において注文管理アプリを含む飲料注文店舗用アプリが起動されたときに行われる。なお、以下の各処理の実行主体は、注文管理アプリ、あるいは注文管理アプリを含む飲料注文店舗用アプリと読み替えることもできる。
【0084】
注文管理部214は、注文の依頼を受け付けたかを常(あるいは定期的)に判定している(S21)。注文管理部214は、注文の依頼を受け付けていないと判定すると(S21でNO)、S31の処理に進む。S31では、注文管理部214は、注文管理テーブル221で管理している何れかの注文において、受取予定日時の第2所定時間(例えば20分)前の時点でボトル3のステータスが「使用中」の注文があるかを判定する(S31)。注文管理部214は、ステータスが「使用中」の注文があると判定すると(S31でYES)、当該注文をキャンセルし(S32)、注文をキャンセルしたことを示すメッセージを当該注文のユーザの端末装置1に通知し(S33)する。その後、S21の処理に戻る。
【0085】
一方、注文管理部214は、注文の依頼を受け付けたと判定すると(S21でYES)、注文データを受信する(S22)。注文データを受信すると、注文管理部214は、現時刻は、S22で注文データを受信した注文における、受取予定日時の第1所定時間前を過ぎているかを判定する(S23)。注文管理部214は、現時刻が受取予定日時の第1所定時間前を過ぎていると判定すると(S23でYES)、当該注文を受け付けず、注文不可であることを示すメッセージを当該注文のユーザの端末装置1に通知する(S28)。その後、S21の処理に戻る。
【0086】
一方、注文管理部214は、現時刻が受取予定日時の第1所定時間前を過ぎていないと判定すると(S23でNO)、ボトル管理テーブル222に管理されている、当該注文を行ったユーザに紐付いているボトル3のステータスを参照する(S24)。そして、注文管理部214は、当該ユーザのボトル3のステータスに応じて、注文を受け付け可能かを判定する(S25)。ここで注文管理部214は、ステータスが、「注文準備中」の場合、および「店頭準備完了」の場合、受け付け不可と判定し、「預かり中」の場合、「使用中」の場合、および「洗浄段階」の場合、受け付け可と判定する。
【0087】
注文管理部214は、注文を受け付け不可と判定すると(S25でNO)、S28の処理に進み、当該注文を受け付けず、注文不可であることを当該注文のユーザの端末装置1に通知する。一方、注文管理部214は、注文を受け付け可と判定すると(S25でYES)、S22で受信した注文データを注文管理テーブル221に登録し(S26)、注文を受け付けたことを示すメッセージを当該注文のユーザの端末装置1に通知する(S27)。その後、S21の処理に戻る。
【0088】
なお、より簡単な管理方法としては単にボトルのステータスが「使用中」(ユーザ側にある)であれば、注文管理システムは新たな注文を受け付けないという運用も可能である。
【0089】
(9.効果)
以上のように、上記構成によれば、ボトル管理システム50が、ユーザに対応付けてユーザ専用のボトル3のステータスを管理する第1機能を有しているので、ユーザ専用のボトル3のステータスを店舗側で把握することができる。
【0090】
ユーザ専用のボトル3のステータスを把握することで、ユーザ専用のボトル3での飲料の提供ができない場合には、注文を受け付けないようにしたり、注文をキャンセルしたりすることができる。これにより、注文した飲料を店舗に受け取りに来たユーザに、店舗側にユーザ専用のボトル3が無く、ユーザ専用のボトル3に入れて提供できないなどの、飲料注文システム100を利用するユーザに不信感を抱かせる事態の招来を未然に防ぐことができる。
【0091】
このように、上記構成によれば、ユーザ専用のボトル3を店舗で保管し、注文を受けた飲料をユーザ専用のボトル3に入れて提供することが可能となり、かつ、該仕組みを円滑に進めることができる。
【0092】
また、上記構成によれば、ボトル管理システム50が、ボトル3から読み取らせたボトル識別子とユーザ識別子とが対応しているか否かを判定する第2機能を有している。
【0093】
これによれば、ユーザより注文が有った場合に、作業者は、店舗で保管している複数のボトル3の中から選び出したボトル3が、注文を行ったユーザ専用の正しいボトル3であるかを容易に確認することができる。ボトル3が本体部3aと蓋部3bからなる場合も、本体部3aおよび蓋部3bの両方が注文を行ったユーザ専用の正しい組み合わせであるかを容易に確認することができる。
【0094】
これにより、他のユーザのボトル3にて飲料を提供するといった、飲料注文システム100を利用するユーザに不信感を抱かせるボトル間違いを未然に防ぐことができる。その結果、ユーザ専用の食品容器を店舗で保管しつつ、注文を受け付けた場合に間違えることなくユーザ専用の食品容器に食品を入れて提供することができる。
【0095】
また、ユーザ専用のボトル3となることで取扱いが丁寧になり、リユースである場合よりもボトル3の寿命が延びることも期待できる。
【0096】
このような構成によれば、プラスチックごみの発生量を低減できる。これにより、持続可能な開発目標(SDGs)の達成に貢献できる。
【0097】
なお、本実施形態では、ボトル管理システム50が、第1機能および第2機能の両方を有している場合を記載した。しかしながら、ボトル管理システム50が、第1機能および第2機能の両方を有している必要はなく、第1機能又は第2機能を単独で有していてもよい。第1機能を単独で有している場合は、上述した第1機能による作用効果を奏する。同様に、第2機能を単独で有している場合は、上述した第2機能による作用効果を奏する。
【0098】
〔実施形態2〕
本発明の他の実施形態について、以下に説明する。なお、説明の便宜上、上記実施形態にて説明した部材と同じ機能を有する部材については、同じ符号を付記し、その説明を繰り返さない。
【0099】
前述の実施形態1における飲料注文システム100では、飲料の受け渡しを店頭で行う、これに対し、本実施形態における飲料注文システム100Aは、飲料の受け渡しを専用のロッカーを用いて行う。以下では、飲料注文システム100と異なる点のみを記載する。
【0100】
(1.飲料注文システムおよびボトル管理システムの概要)
図11は、本発明の一実施形態に係るボトル管理システム50Aおよび注文管理システム60Aが含まれる飲料注文システム100Aの概要を示す図である。飲料注文システム100Aは、ボトル管理システム(食品容器管理システム)50A、注文管理システム60Aを含む。ボトル管理システム50Aは、店舗端末2Aとロッカー装置40とを備える。
【0101】
店舗端末2Aは、図3を参照して説明すると、制御部21が、注文管理部214に代えて注文管理部214Aを備え、ボトル管理部215に代えてボトル管理部215Aを備える。また、店舗端末2Aは、記憶部22が、注文管理テーブル221に代えて注文管理テーブル221Aを備え、ボトル管理テーブル222に代えてボトル管理テーブル222A(図14参照)を備える。さらに、記憶部22は、注文可否テーブル223に代えて注文可否テーブル223Aを備える。
【0102】
ボトル管理部215は、ボトル3のステータスを示す項目に、ロッカー装置40に収納されている状態、ロッカー装置40に返却されている状態等の、ロッカー装置40に対するボトル3の状態を示す項目を含む。
【0103】
注文管理部214Aは、ボトル管理部215Aにて登録されるボトル管理テーブル222Aのステータスを参照し、注文の可否を判定し、あるいは、注文のキャンセルを行う。注文管理部214は、ステータスが「預かり中」から「注文準備中」に切り換えられると、ロッカー装置40に対し、注文コードを通知してもよい。
【0104】
(2.ロッカー装置の構成例)
図11に示すように、ボトル3が収納されるロッカーボックス41を有すると共に店舗端末(情報処理装置)2と通信可能なロッカー装置40を備える。本実施形態では、ロッカー装置40は、ボトル3を収納する複数のロッカーボックス41を備える。ロッカーボックス41は、開閉可能な扉を備える。ロッカーボックス41は、扉をロックするロック部48(図12参照)を備え、ロックが解除されると自動で開くように構成されている。また、ロッカーボックス41は、扉の開閉を検知する扉開閉検知部47(図12参照)を備える。各ロッカーボックス41には、一意に識別できるようにロッカー番号等が付されている。
【0105】
図12は、ロッカー装置40の電気的な構成を示すブロック図である。図12に示すように、ロッカー装置40は、ロッカー装置40の各部を統括して制御する制御部43を備えている。制御部43は、前述した各ロッカーボックス41のロック部48および扉開閉検知部47と接続されている。これにより、制御部43は、各ロッカーボックス41の扉の施錠および解錠を制御し、かつ、各ロッカーボックス41の扉の開閉を検知できる。
【0106】
さらに、ロッカー装置40は、ロッカー装置40に対する入力操作を受け付けると共に表示を行う操作表示部46、ロッカー装置40が他の装置と通信するための通信部45、および読取部44を備える。読取部44は、読み取りに適した光学読み取りマークであるコード情報(一次元コードや二次元コード等)等の読み取りを行う。
【0107】
制御部43は、読取制御部432、ロッカー管理部431、照合部433、および扉制御部434を含む。読取制御部432は、読取部44を制御してコード情報を読み取らせる。照合部433は、読取部44で読み取ったコード情報、操作表示部46より入力された情報の照合を行う。扉制御部434は、ロック部48を制御して扉のロックおよびロック解除を行う。
【0108】
ロッカー管理部431は、複数のロッカーボックス41の空き状態を管理すると共に、ボトル3を収納している場合は、収納しているボトル3を、注文に一意に対応付けられている注文コード情報と紐付けて管理する。
【0109】
(3.ロッカー装置におけるボトルの管理)
ここで、ボトル管理システム50Aによるロッカー装置40を組み入れたボトル3のステータスを管理の一例を、図11および図12を用いて説明する(第1機能)。
【0110】
店舗側の作業者(図示せず)は、飲料の提供準備が完了すると、ボトル3をロッカーボックス41に収納する。このとき、注文管理システム60とロッカー装置40とのやりとりにて、ロッカー装置40は既に注文コードを受信している。そして、ロッカー管理部431は、当該注文コードのボトル3を収納するロッカーボックス41を決定している。
【0111】
ボトル3を収納するにあたり、作業者は、操作表示部46より所定の作業者コード番号および/又はボトル3の収納が可能であることを示す情報を入力する。照合部433は、入力された情報と予め記憶している情報と照合する。照合部433が適正と判定すると、ロッカー管理部431は、決定しているロッカーボックス41のロッカー番号を扉制御部434に通知する。これにより、注文と紐付けられているロッカーボックス41のロックが解除され、ロッカーボックス41の扉が自動に開く。ロッカー管理部431は、決定しているロッカーボックス41のロック解除と同時に、注文管理システム60にロッカー番号情報を受信した注文コードの注文に対応付けて通知する。
【0112】
ロッカー管理部431は、作業者がボトル3を収納して扉を閉じると、ロック部48が扉を再び施錠する。ロッカー管理部431は、扉開閉検知部47が検知すると、店舗端末2に対し、受信した注文コードに対応付けてボトル3のロッカー投入が完了したことを通知する(ロッカー投入のトリガー)。
【0113】
ボトル管理システム50Aは、ロッカー装置40より、通知した注文コードのボトル3のロッカー投入が完了したことが通知されると(ロッカー投入のトリガー入力)、ボトル管理部215Aは、該当するボトル3のステータスを「注文準備中」から「ロッカー準備完了」に切り換える。つまり、ボトル管理部215Aは、飲料が入れられたボトル3がロッカーボックス41に収納されると、ステータスをボトル3がユーザに提供可能であることを示すステータスに切り換える。注文管理部214は、ステータスが「注文準備中」から「ロッカー準備完了」に切り換えられると、飲料の準備が完了したことを示す「商品のお渡し準備ができました!」等のメッセージを当該注文のユーザの端末装置1に通知する。
【0114】
ユーザは、ボトル3をロッカーボックス41から取り出すにあたり、飲料注文システム100より注文時に受け取った注文コード情報をユーザの端末装置1に表示し、読取部44に読み取らせる。照合部433は、読取部44が読み取った注文コード情報を、ロッカー管理部431にて管理している注文に対応付けられた注文コード情報と照合する。照合部433は、注文コード情報が一致すると、一致した注文コード情報のボトル3を収納しているロッカーボックス41を特定し、扉制御部434に通知する。
【0115】
扉制御部434は、照合部433より通知されたロッカーボックス41の扉のロックを解除する。これにより、ロックが解除されたロッカーボックス41の扉が自動に開き、ユーザは扉が開いたロッカーボックス41より注文した商品の入ったボトル3を受け取る。ユーザが扉を閉じると、ロック部48が扉を再び施錠する。ロッカー管理部431は、ロッカーボックス41が閉じられたことを扉開閉検知部47が検知すると、店舗端末2に対し、受信した注文コードの注文に対応付けてボトル3がロッカーから取り出されたことを通知する(ロッカー取り出しのトリガー)。また、ロッカー管理部431は、受信した注文コードの注文とロッカーボックス41のロッカー番号との紐付けを解消する。
【0116】
ボトル管理システム50Aは、ロッカー装置40より通知した注文コードのボトル3の取り出しがなされたことが通知されると(ロッカー取り出しのトリガー入力)、ボトル管理部215Aは、該当するボトル3のステータスを「ロッカー準備完了」から「使用中」に切り換える。つまり、ボトル管理部215Aは、ボトル3がロッカーボックス41から取り出されると、ステータスをボトル3がユーザ側に有ることを示すステータスに切り換える。
【0117】
ユーザは、ボトル3をロッカーボックス41に返却するにあたり、ユーザの端末装置1に表示させた、飲料注文システム100より注文時に受け取った注文コード情報、あるいはボトル3に付されたボトル識別子(二次元コードのコード情報Q)を、読取部44に読み取らせる。照合部433は、読取部44が読み取った注文コード情報を、ロッカー管理部431にて管理している注文に対応付けられた注文コード情報と照合する。照合部433は、注文コード情報が一致すると、空いているロッカーボックス41の1つのロックを解除する。これにより、ロックが解除されたロッカーボックス41の扉が自動に開き、ユーザは、扉が開いたロッカーボックス41にボトル3を返却し、扉を閉じる。
【0118】
ロッカー管理部431は、ロッカーボックス41が閉じられたことを扉開閉検知部47が検知すると、店舗端末2に対し、注文コード情報のボトル3がロッカーに返却されたことを通知する(ボトル返却のトリガー)。また、ロッカー管理部431は、ボトル3が返却されたロッカーボックス41のロッカー番号を、返却されたボトル3を収納しているロッカーボックス41として管理する。
【0119】
ボトル管理システム50Aは、ロッカー装置40よりボトル3がロッカーに返却されたことが通知されると(ロッカー返却のトリガー入力)、ボトル管理部215Aは、該当するボトルのステータスを「使用中」から「ロッカー返却済」に切り換える。
【0120】
作業者は、ボトル3をロッカーボックス41から回収するにあたり、作業者は、操作表示部46より所定の作業者コード番号およびボトル3の回収であることを示す情報を入力する。照合部433は、作業者コード番号を予め記憶している情報と照合する。照合部433が適正と判定すると、ロッカー管理部431は、扉制御部434に通知し、返却されたボトル3を収納している全てのロッカーボックス41のロックを解除させる。
【0121】
これにより、返却されたボトル3が収納されているロッカーボックス41の扉が自動に開き、作業者がボトル3を回収し、扉を閉める。ロッカー管理部431は、ロッカーボックス41が閉じられたことを扉開閉検知部47が検知すると、店舗端末2に対し、回収されたボトル3それぞれについて、注文コード情報のボトル3がロッカーより回収されたことを通知する(ロッカーより回収のトリガー入力)。
【0122】
ボトル管理システム50Aは、ロッカー装置40よりボトル3がロッカーより回収されたことが通知されると(ロッカーより回収のトリガー入力)、ボトル管理部215Aは、該当するそれぞれのボトル3のステータスを「ロッカー返却済」から「洗浄段階」に切り換える。「洗浄段階」はボトル3が店舗側にあることを示すステータスでもある。つまり、ボトル管理部215Aは、ボトル3がロッカーボックス41から回収されると、ステータスをボトル3が店舗側に有ることを示すステータスに切り換える。
【0123】
なお、ここでは、ボトル管理部215Aは、ボトル3がロッカーボックス41から回収されると、ボトル3が店舗側に有ることを示すステータスに切り換えるようにしている。しかしながら、ボトル管理部215Aは、ボトル3がロッカーボックス41に返却されたことを示すトリガーの入力で、ボトル3が店舗側に有ることを示すステータスに切り換えてもよい。
【0124】
(4.記憶部に記憶されるデータの例)
図13は、記憶部22Aに記憶される注文管理テーブル221Aの例を示す図である。図13に示す注文管理テーブル221Aでは、注文管理テーブル221で管理していた項目に加えて、注文コード情報が対応付けられている。
【0125】
図14は、記憶部22Aに記憶されるボトル管理テーブル222Aの例を示す図である。図14Aに示すボトル管理テーブル222Aでは、「店舗準備完了」に代えて、ボトル3がロッカーボックス41に収納されたこと示す「ロッカー準備完了」が管理される。「使用中」と「洗浄段階」との間のステータスとして、「ロッカー返却済み」が新たに管理される。
【0126】
図示しないが、注文可否テーブル223Aでは、「店頭準備完了」と同様に「ロッカー準備完了」には、受付不可が設定される。「ロッカー返却済み」には受付可が設定される。
【0127】
(5.表示部に表示される表示の例)
図15は、ボトル管理システム50Aにおいて表示部25に表示される表示例を示す図である(第1機能)。図15の画面1501は、作業者が、注文番号「111111」の注文を行ったユーザのボトル3のステータスの確認操作を行った場合に、表示制御部211が表示部25に表示させる、ステータス確認画面である。
【0128】
表示制御部211は、例えば、作業者が、注文一覧画面(図示せず)等から、注文番号「111111」の注文に対して、ステータス確認ボタン等をタップすると、注文管理テーブル221Aおよびボトル管理テーブル222Aを参照して、画面1501を表示する。画面1501には、注文番号、注文日時、受取予定日時、注文コード情報と共に、ステータスが表示される。画面1501では、ロッカー装置40を用いた飲料提供からボトル回収までの手順に沿って、「注文準備中」→「ロッカー準備完了」→「使用中」→「ロッカー返却済」→「洗浄段階」→「預かり中」の順で項目が並べられ、現在のステータスである「使用中」が色を変えて表示される。
【0129】
〔変形例〕
以上、本発明の実施の形態を詳細に説明してきたが、前述の説明はあらゆる点において本発明の例示に過ぎない。本発明の範囲を逸脱することなく種々の改良や変形を行うことができることは言うまでもない。例えば、以下のような変更が可能である。なお、以下では、説明の便宜上、上記実施形態にて説明した部材と同じ機能を有する部材については、同じ符号を付記し、その説明を繰り返さない。
【0130】
上記実施形態では、ボトル管理システム50における第2機能において、ボトル識別子とユーザ識別子とを分けて説明したが、ボトル識別子とユーザ識別子とは同じであってもよい。つまり、ボトル識別子を用いてユーザを一意に対応付けてもよいし、ボトル3にユーザ識別子を読み取り可能に設けて、ユーザ識別子にてボトル3を一意に対応付けてもよい。
【0131】
また、上記実施形態では、ボトル管理テーブル222と注文管理テーブル221とを分けて説明した。しかしながら、ボトル管理システム50における第2機能を単独で備える構成においては、端末装置1および入力部23から注文する際の注文のデータの中に、ボトル識別子の情報が含まれているようにしてもよい。その場合、注文管理テーブルにボトル識別子の情報が含まれる。
【0132】
上記実施形態では、ボトル管理システム50における第2機能において、判定部213の判定結果は、表示制御部211に送信され、表示制御部211が表示部25に表示させる。しかしながら、店舗端末2が、音出力装置である音出力部を備えている場合は、判定結果を音や音声で伝えるようにしてもよい。あるいは、表示部25による表示と音出力部による音との両方で判定結果を伝えるようにしてもよい。
【0133】
上記実施形態では、食品容器として飲料を入れるボトル3を例示したが、上述したように、食品容器は、飲料以外の食品を入れる容器、例えば、弁当箱や、惣菜等を入れる本体と蓋体とからなる容器であってもよい。弁当箱であって、内部を仕切る仕切り部材等が含まれている場合は、仕切り部材にも容器識別子を設けてユーザ識別子に対応付ければよい。
【0134】
上記実施形態では、ボトル管理システム50における第2機能において、ボトル3にボトル識別子を示すコード情報Qを設ける構成を例示したが、コード情報Qに代えてボトル識別子を示すRFIDタグを設けてもよい。その場合、店舗端末2は、撮影装置である撮影部26に代えてRFIDタグの読取装置を備えることとなる。
【0135】
上記実施形態では、ボトル管理システム50における第1機能において、ボトル3のステータスに応じて、注文の受け付けの可否を判定する、あるいは注文をキャンセルする例示した。しかしながら、これに限定されるものではなく、例えば、受取予定日時の所定時間前(例えば30分前)の時点で、ボトル3が店舗側に返却されていない場合には、返却を促すメッセージを当該注文のユーザの端末装置1に通知するといったことも可能になる。また、第1機能の場合、ボトル3にボトル識別子が設けられていることは必須の構成要素ではない。
【0136】
また、ボトル3のステータスとして管理する項目も、破損や、入荷待ち、解約等の項目を加えてもよい。ユーザ専用のボトル3のステータスを管理することで、ユーザに対して、専用ボトル3に関連する様々なサービスを提供することもできる。
【0137】
〔ソフトウェアによる実現例〕
店舗端末2(以下、「装置」と呼ぶ)の機能は、当該装置としてコンピュータを機能させるためのプログラムであって、当該装置の各制御ブロック(特に制御部21に含まれる各部)としてコンピュータを機能させるためのプログラムにより実現することができる。
【0138】
また、店舗端末2を当該装置としてコンピュータを機能させる場合について説明したが、店舗端末2とは異なる他のサーバ装置に機能させるようにしても良い。
【0139】
この場合、上記装置は、上記プログラムを実行するためのハードウェアとして、少なくとも1つの制御装置(例えばプロセッサ)と少なくとも1つの記憶装置(例えばメモリ)を有するコンピュータを備えている。この制御装置と記憶装置により上記プログラムを実行することにより、上記各実施形態で説明した各機能が実現される。
【0140】
上記プログラムは、一時的ではなく、コンピュータ読み取り可能な、1または複数の記録媒体に記録されていてもよい。この記録媒体は、上記装置が備えていてもよいし、備えていなくてもよい。後者の場合、上記プログラムは、有線または無線の任意の伝送媒体を介して上記装置に供給されてもよい。
【0141】
また、上記各制御ブロックの機能の一部または全部は、論理回路により実現することも可能である。例えば、上記各制御ブロックとして機能する論理回路が形成された集積回路も本発明の範疇に含まれる。この他にも、例えば量子コンピュータにより上記各制御ブロックの機能を実現することも可能である。
【0142】
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
【符号の説明】
【0143】
1 端末装置
2 店舗端末
3 ボトル(食品容器、飲料容器)
3a 本体部
3b 蓋部
21 制御部(情報処理装置)
22 記憶部
23 入力部(取得装置)
25 表示部(表示装置)
24 通信部
26 撮影部(取得装置)
50 ボトル管理システム(食品容器管理システム)
100 飲料注文システム
211 表示制御部
212 読取制御部(取得制御部)
213 判定部

図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15