JP6818475B2 - 飲料の提供制御システム及び方法、並びにプログラム - Google Patents

Description

本開示は、飲料の提供に用いられるシステム及び方法に関する。

従来、ユーザからの操作に応じて、飲料を吐出する飲料ディスペンサが知られている。具体的には、ジュースやソフトドリンクの他、ビール等のアルコール飲料を提供する飲料ディスペンサが知られている（特許文献１参照）。飲料の吐出制御を電気的に行う電動式の飲料ディスペンサもまた知られている。

特開２０１４−０６５５００号公報

しかしながら、従来の飲料ディスペンサは、顧客に対して飲み放題サービスを提供するために設置されることが多く、その用途は、限定的である。
本開示の一側面によれば、例えば飲料ディスペンサを用いた新規な飲料提供サービスに好適な、飲料の提供制御システム及び方法を提供できることが望ましい。

本開示の一側面に係る提供制御システムは、識別ユニットと、許可ユニットと、を備える。識別ユニットは、飲料を要求する顧客である要求顧客を識別するように構成される。許可ユニットは、識別ユニットにより識別された要求顧客に対する飲料の提供を許可するか否かを判定するように構成される。具体的に、許可ユニットは、記憶デバイスが記憶する要求顧客の管理データに基づき、要求顧客に対する飲料の提供を許可するか否かを判定するように構成される。記憶デバイスは、顧客毎の管理データとして、顧客に対する飲料の過去の提供に関するデータを記憶するように構成される。

このシステムを用いれば、顧客に対する飲料の過去の提供を考慮して、顧客に飲料を提供することが可能である。従って、新規な飲料提供サービスを実現可能である。
本開示の一側面によれば、顧客に対する飲料の過去の提供に関するデータの例には、過去の提供を直接及び／又は間接的に表すデータ、及び／又は、顧客に対する飲料の提供によって更新されるデータ、及び／又は、顧客に対する飲料の過去の提供を反映するデータ、が含まれ得る。

本開示の一側面によれば、許可ユニットは、要求顧客の管理データに基づき、飲料の提供量及び提供回数の少なくとも一方に関する予め定められた条件が満足される場合には、要求顧客に対する飲料の提供を許可し、予め定められた条件が満足されない場合には、要求顧客に対する飲料の提供を許可しないように構成されてもよい。この許可ユニットを備えるシステムによれば、予め定められた条件下で自由に飲料を飲むことができる新規な飲料提供サービスを実現可能である。

本開示の一側面によれば、許可ユニットは、要求顧客の管理データに基づき、要求顧客に対する飲料の過去の提供量及び提供回数の少なくとも一方が予め定められた条件下にある場合には、要求顧客に対する飲料の提供を許可し、予め定められた条件下にない場合には、要求顧客に対する飲料の提供を許可しないように構成されてもよい。

本開示の一側面によれば、許可ユニットは、要求顧客に対する過去所定期間内の飲料の総提供量が所定量以下である場合に、要求顧客に対する飲料の提供を許可し、総提供量が所定量より大きい場合には、要求顧客に対する飲料の提供を許可しないように構成されてもよい。

本開示の一側面によれば、許可ユニットは、要求顧客に対する過去所定期間内の飲料の提供回数が所定回数以下である場合に、要求顧客に対する飲料の提供を許可し、提供回数が所定回数より大きい場合には、要求顧客に対する飲料の提供を許可しないように構成されてもよい。

提供量又は提供回数に基づく飲料の提供制限は、例えば収益性及び健康管理の少なくとも一方の観点で行われ得る。顧客の健康管理に注目すれば、本開示のシステムは、飲料がアルコール類であるサービスに用いられると特に有意義である。

本開示の一側面に係る提供制御システムは、飲料の提供が許可されたことを条件に、飲料に関するチケットを発行する発行ユニットを備えてもよい。一例によれば、飲料の提供に関わる店舗の店員は、発行されたチケットに基づき、要求顧客に飲料を提供するための作業を行うことができる。

発行ユニットは、飲料を提供する飲料ディスペンサに設けられてもよい。一例によれば、発行ユニットは、飲料の提供が許可されたことを条件に、飲料に関するチケットとして、飲料ディスペンサから提供される飲料を収納するための容器を受け取る権利が化体されたチケットを出力するように構成されてもよい。一例によれば、店舗の店員は、顧客から提示されたチケットに基づいて、上記容器を顧客に提供することができる。顧客は、この容器を用いて飲料の提供を受けることができる。

本開示の一側面によれば、顧客の識別情報を入力する入力ユニットが、飲料ディスペンサに設けられてもよい。識別ユニットは、この飲料ディスペンサの入力ユニットから入力される識別情報に基づき、要求顧客を識別するように構成され得る。

本開示の一側面に係る提供制御システムは、発行ユニットにより発行されたチケットが保持する情報を読み取って、外部の情報管理システムに送信する情報提供ユニットを備えていてもよい。チケットは、チケット発行元の飲料ディスペンサを特定可能な情報、及び、提供対象の飲料の種類及び量の少なくとも一方を特定可能な情報、の少なくとも一方を保持することができる。情報提供ユニットは、例えば、販売時点情報管理（ＰＯＳ）機能を有する店舗端末に設けられ得る。

本開示の一側面によれば、識別ユニット及び許可ユニットは、飲料ディスペンサと通信可能なサーバ装置に設けられてもよい。サーバ装置は、一つ又は複数の飲料ディスペンサと通信可能な構成にされてもよい。本開示の一側面によれば、提供制御システムは、複数の飲料ディスペンサに共通するサーバ装置を備えるように構成されてもよい。

本開示の一側面によれば、顧客の識別情報を入力する入力ユニットは、販売時点情報管理（ＰＯＳ）機能を有する店舗端末に備えられてもよい。この場合、識別ユニットは、店舗端末の入力ユニットから入力される識別情報に基づき、要求顧客を識別するように構成され得る。提供制御システムは、飲料の提供が許可されたことを条件に、店舗端末に対して飲料の提供が許可されたことを示す情報を出力する出力ユニットを備えていてもよい。

上記識別ユニット、許可ユニット、及び出力ユニットは、店舗端末と通信可能なサーバ装置に設けられてもよい。店舗の店員は、出力ユニットからの出力情報に基づき、顧客に対して、飲料を提供するための作業を行うことができる。

本開示の一側面によれば、提供制御システムは、許可ユニットにより飲料の提供が許可されたことに応じて、飲料ディスペンサを制御する制御ユニットを備えた構成にされてもよい。この制御ユニットは、上記入力ユニットと共に飲料ディスペンサに備えられてもよい。

本開示の一側面によれば、飲料ディスペンサは、飲料を吐出する飲料吐出機構を備えることができる。制御ユニットは、飲料の提供が許可されたことを条件に、飲料吐出機構から飲料が吐出されるように、飲料吐出機構を制御する構成にされ得る。

本開示の一側面によれば、飲料の提供制御システムは、識別ユニット及び許可ユニットを、飲料ディスペンサと通信可能なサーバ装置に備え、入力ユニット及び制御ユニットを、飲料ディスペンサに備えていてもよい。

本開示の一側面によれば、飲料の提供が完了したことを通知する通信信号を出力する通知ユニットが飲料ディスペンサに設けられてもよい。飲料ディスペンサと通信可能なサーバ装置は、飲料ディスペンサから当該通信信号を受信したことを条件に、記憶デバイスが記憶する、飲料の提供が完了した顧客の管理データを更新する更新ユニットを備えてもよい。更新ユニットは、管理データの更新によって、管理データが表す顧客に対する飲料の過去の提供に関する情報を更新することができる。この例によれば、顧客に対する飲料の提供が完了したことを条件に、管理データが更新されるので、顧客から飲料の要求があった時点で管理データを更新する場合よりも、飲料提供の事実に対応して、適切に管理データを更新することができる。

本開示の一側面によれば、上述した識別ユニット、許可ユニット、及び出力ユニットの少なくとも一つとしての機能をコンピュータに実現させるためのプログラムが提供されてもよい。本開示の一側面によれば、制御ユニットとしての機能をコンピュータに実現させるためのプログラムが提供されてもよい。本開示の一側面によれば、発行ユニットとしての機能をコンピュータに実現させるためのプログラムが提供されてもよい。本開示の一側面によれば、プログラムを記憶するコンピュータ読取可能な非一時的記録媒体が提供されてもよい。

本開示の一側面によれば、飲料を要求する顧客である要求顧客を識別する手順と、識別された要求顧客に対する飲料の提供を許可する手順と、を含む飲料の提供制御方法が提供されてもよい。上記識別する手順及び上記許可する手順は、コンピュータにより実行されてもよい。

許可する手順は、顧客毎の管理データとして顧客に対する飲料の過去の提供に関するデータを記憶する記憶デバイスが記憶する要求顧客の管理データに基づき、要求顧客に対する飲料の提供を許可するか否かを判定する手順を含んでいてもよい。例えば、許可する手順は、要求顧客の管理データに基づき、飲料の提供量及び提供回数の少なくとも一方に関する予め定められた条件が満足される場合には、要求顧客に対する飲料の提供を許可し、予め定められた条件が満足されない場合には、要求顧客に対する飲料の提供を許可しないように、要求顧客に対する飲料の提供を許可するか否かを判定する手順を含み得る。許可する手順は、要求顧客の管理データに基づき、要求顧客に対する飲料の過去の提供量及び提供回数の少なくとも一方が予め定められた条件下にある場合には、要求顧客に対する飲料の提供を許可し、予め定められた条件下にない場合には、要求顧客に対する飲料の提供を許可しないように、要求顧客に対する飲料の提供を許可するか否かを判定する手順を含んでもよい。

上述したシステムの構成から、対応する方法、プログラム、及び記録媒体に係る技術的思想が理解される。

第一実施形態における飲料ディスペンサの外観を概略的に表す図である。 第一実施形態の飲料ディスペンサ及び管理サーバの構成を表すブロック図である。 発行されるチケットの一例を表す図である。 第一実施形態において顧客が飲料提供を受けるまでの流れを説明した図である。 第一実施形態の制御システムを構成する飲料ディスペンサ、管理サーバ、ＰＯＳ端末、及び、ＰＯＳサーバの配置及び関係を説明したブロック図である。 第一実施形態において飲料ディスペンサのコントローラが実行する発券制御処理を表すフローチャートである。 顧客管理データベースの構成を表す図である。 第一実施形態において管理サーバの演算部が実行する許可判定処理を表すフローチャートである。 第一実施形態においてＰＯＳ端末が実行するチケット関連処理を表すフローチャートである。 第一実施形態において飲料ディスペンサのコントローラが実行する吐出制御処理を表すフローチャートである。 第二実施形態の制御システムを構成する飲料ディスペンサ、管理サーバ、ＰＯＳ端末、及び、ＰＯＳサーバの配置及び関係を説明したブロック図である。 第二実施形態の飲料ディスペンサの構成を表すブロック図である。 第二実施形態のＰＯＳ端末の構成を表すブロック図である。 第二実施形態においてＰＯＳ端末のコントローラが実行する利用受付処理を表すフローチャートである。 第三実施形態の制御システムを構成する飲料ディスペンサ、管理サーバ、及び、ＰＯＳサーバの配置及び関係を説明したブロック図である。 第三実施形態の飲料ディスペンサの構成を表すブロック図である。 第三実施形態において飲料ディスペンサのコントローラが実行する飲料提供処理を表すフローチャート（その１）である。 第三実施形態において飲料ディスペンサのコントローラが実行する飲料提供処理を表すフローチャート（その２）である。 第三実施形態において管理サーバの演算部が実行する許可判定処理を表すフローチャートである。

本開示の例示的実施形態を、図面を参照しながら以下に説明する。
［第１実施形態］
本実施形態の制御システム１は、電動式の飲料ディスペンサ１０を通じた顧客に対する飲料の提供を制御するシステムである。飲料ディスペンサ１０を通じた飲料提供サービスは、予め会員として登録された顧客に対して、予め定められた条件の範囲内で飲料を提供するサービスである。このような飲料提供サービスの一例は、コンビニエンスストア等の複数の小売店舗に設置された飲料ディスペンサ１０を通じて、顧客が飲料の提供を受けることができるというものである。このサービスによれば、顧客は、場所的及び時間的な制約の少ない比較的自由な環境下で、複数店舗を通じて飲料の提供を受けることができる。

本実施形態の制御システム１が提供対象とする飲料は、アルコール飲料であり、特にビール、より具体的には生ビールである。但し、制御システム１は、アルコール飲料以外の飲料の提供に用いられてもよい。

飲料提供サービスは、限定されないが、例えば月額定額制のサービスとして提供することができる。但し、過度のアルコール摂取は、顧客の健康に対して好ましくない影響を与える可能性がある。このため、本実施形態では、顧客の健康を考慮して飲料の提供に関する上記条件が定められ、制御システム１は、この条件の範囲内で、顧客に対して飲料を提供するように動作する。例えば、１日に提供可能な量の上限及び１週間で提供可能な回数の上限が定められ、顧客に対しては、この上限を超えない範囲内で飲料が提供される。

本実施形態で使用される飲料ディスペンサ１０は、図１及び図２に示される。図１左は、ボトル１９がセットされていない状態での飲料ディスペンサ１０の外観を表し、図１右は、ボトル１９がセットされた状態での飲料ディスペンサ１０の外観を表す。図１及び図２に示すように、飲料ディスペンサ１０は、吐出機構１１、コントローラ２１、読取部２３、ユーザインタフェース２５、発券部２７、及び、通信部２９を備える。

吐出機構１１は、コントローラ２１により電気的に制御され、図示しない飲料タンクから飲料を吸引してノズル１３から吐出するように構成される。吐出機構１１は、ノズル１３下方に、ボトル載置用のテーブル１５を備え、テーブル１５は、手動によるテーブル１５の回転操作により、ボトル載置面の高さを変更可能に構成される。吐出機構１１は、更にセンサ１７（図２参照）を備えており、センサ１７は、ノズル１３に対してボトル１９がセットされたか否か、及び、セットされたボトル１９のサイズを検知可能に構成される。

コントローラ２１は、飲料ディスペンサ１０の全体を統括制御するように構成される。このコントローラ２１は、ＣＰＵ２１Ａと、ＲＯＭ２１Ｂと、ＲＡＭ２１Ｃと、を備える。ＣＰＵ２１Ａは、ＲＯＭ２１Ｂが記憶するプログラムに従う処理を実行する。ＲＡＭ２１Ｃは、ＣＰＵ２１Ａによる処理実行時に作業用メモリとして使用される。コントローラ２１が実行する処理は、基本的に、ＣＰＵ２１Ａが上記プログラムに従う処理を実行することにより実現される。ここでは、ＣＰＵ２１Ａが上記プログラムに従って実行する処理を、コントローラ２１が実行する処理として説明する。

読取部２３は、会員証３０が保持する顧客ＩＤを読取可能に構成される。顧客ＩＤは、飲料ディスペンサ１０を通じた飲料提供サービスを利用可能な顧客の識別コードである。サービスを利用可能な顧客の夫々には、個別に顧客ＩＤが割り当てられる。会員証３０は、例えばＩＣカード又は磁気カードの形態で顧客に提供される。この場合、読取部２３は、ＩＣカード又は磁気カードを読取可能なカードリーダとして構成される。会員証３０は、顧客ＩＤがバーコード又は二次元コードの形態で記録されたカードであってもよい。この場合、読取部２３は、バーコード又は二次元コードを光学的に読取可能なリーダとして構成される。

ユーザインタフェース２５は、ユーザからの入力操作を受付可能、及び、ユーザに対して情報表示可能な構成にされる。例えば、ユーザインタフェース２５は、液晶ディスプレイと、液晶ディスプレイ上のタッチパネルと、により構成される。ユーザインタフェース２５は、コントローラ２１により制御されて、各種情報をユーザに向けて表示し、更には、ユーザからの操作情報をコントローラ２１に伝達する。

発券部２７は、飲料ディスペンサ１０を操作するユーザが飲料を提供可能な顧客である場合に、コントローラ２１により制御されて、飲料を顧客に提供するためのチケット３５を発行するように構成される。発行されるチケット３５は、飲料ディスペンサ１０から提供される飲料を収納するためのボトル１９を受け取る権利が化体されたチケットである。チケット３５は、例えば紙媒体に対する印字により形成される。この場合、発券部２７は、小型のプリンタにより構成され得る。

図３に示される例示的なチケット３５は、顧客に対する飲料の提供履歴に関する記述、及び、チケット３５の使い方に関する記述と共に、バーコード３５Ａを備える。このバーコード３５Ａは、飲料ディスペンサ１０にて提供される飲料の商品ＩＤと、飲料ディスペンサ１０の識別コードであるディスペンサＩＤと、を表す。商品ＩＤは、飲料の種類及び量の組合せ毎に異なると理解されてよい。商品ＩＤの一部又は全部は、例えばＪＡＮコードにより構成され得る。

通信部２９は、管理サーバ４０とネットワークを通じて通信可能に構成される。通信部２９は、コントローラ２１により制御され、チケット３５の発行に先駆けて、管理サーバ４０と通信し、飲料ディスペンサ１０を操作するユーザが飲料を提供可能な顧客であるか否かを管理サーバ４０に問い合わせる。

ここで、チケット３５を通じた飲料の提供手順の概略を、図４を用いて説明する。飲料の提供を所望する顧客は、飲料ディスペンサ１０を操作して自己の会員証３０を飲料ディスペンサ１０に提示することができる（Ｓ１）。会員証３０の提示を受けて飲料ディスペンサ１０は、会員証３０が保持する顧客ＩＤを読み取り（Ｓ２）、読み取った顧客ＩＤに対応する顧客に飲料を提供可能であるか否かを問い合わせるために、管理サーバ４０と通信する（Ｓ３）。

具体的に、飲料ディスペンサ１０は、顧客ＩＤ、顧客が所望する飲料提供量、及びディスペンサＩＤの情報を含む問い合わせ信号を、通信ネットワークを通じて管理サーバ４０に送信することができる。管理サーバ４０は、飲料ディスペンサ１０から受信した問い合わせ信号が表す顧客ＩＤ及び顧客が所望する飲料提供量の情報と、顧客管理データベース４５（図２参照）が記憶する過去の提供履歴を表す情報とに基づき、顧客ＩＤに対応する顧客に対する飲料の提供を許可するか否かを判定し、その判定結果を表す応答信号を送信することができる。

飲料ディスペンサ１０は、この応答信号に基づき、飲料の提供が許可されている場合には、上記チケット３５を発行（出力）するように動作する（Ｓ４）。
飲料の提供が許可された顧客は、飲料ディスペンサ１０の発券部２７から出力されたチケット３５を受け取り（Ｓ５）、そのチケット３５を、飲料ディスペンサ１０が設置された店舗の店員に提出することができる（Ｓ６）。

店員は、顧客からチケット３５を受け取り（Ｓ７）、そのチケット３５内のバーコード３５Ａを、店舗内のＰＯＳ（Ｐｏｉｎｔ Ｏｆ Ｓａｌｅ）端末６０を通じて読み取ることができる（Ｓ８）。ＰＯＳ端末６０は、図５に示すようにバーコードリーダ６１及び表示部６５を備える。表示部６５は、例えば、液晶ディスプレイで構成される。

ＰＯＳ端末６０を通じて読み取られたバーコード３５Ａの情報、即ち、商品ＩＤ及びディスペンサＩＤの情報は、その読取時刻及び店舗の識別コードと共に、ＰＯＳデータとして、ＰＯＳサーバ８０に送信される（Ｓ８）。ここで用いられるＰＯＳ端末６０は、周知のＰＯＳ端末と同様に構成されていると理解されてよい。即ち、ＰＯＳ端末６０は、会計機能及び販売時点情報管理（ＰＯＳ）機能を有した構成にされる。ＰＯＳ端末６０は、「ＰＯＳレジ」とも称され、キャッシュレジスタとしての機能を有する他、ＰＯＳデータとして、販売商品のＩＤ及び販売時刻等をＰＯＳサーバに伝達する機能を有する。

例示的な飲料提供サービスによれば、飲料提供サービスの利用料金は、月額固定料金として、例えば顧客のクレジットカードや銀行口座からの引き落としを通じて顧客から支払われる。このため、Ｓ８におけるバーコード３５Ａ読取時に、顧客と店員との間で金銭の授受は行われない。但し、飲料提供サービスの利用料金が従量制である場合には、バーコード３５Ａが読み取られるときに、ＰＯＳ端末６０において会計処理が行われて、顧客と店員との間で金銭の授受が行われてもよい。

バーコード３５Ａの読取後、ＰＯＳ端末６０は、上記読み取ったバーコード３５Ａから特定される飲料の種類及び量を表示部６５に表示する。店員は、このようにして表示部６５に表示される顧客に提供すべき飲料の量に基づいて、この量に対応したサイズのボトル１９を、顧客に提供する（Ｓ９）。顧客に提供されるボトル１９は、チケット３５のバーコード３５Ａが表す量の飲料を収納可能であるが、それを超える飲料を基本的には収納できないサイズのボトルである。

顧客は、上述の手順に従って、飲料ディスペンサ１０のユーザインタフェース２５を通じて入力した所望する飲料提供量に対応するサイズのボトル１９を受け取り（Ｓ１０）、このボトル１９を飲料ディスペンサ１０にセットするように、飲料ディスペンサ１０を操作することができる。更に、顧客は、飲料ディスペンサ１０のユーザインタフェース２５を通じて、飲料の吐出開始を指示することができる（Ｓ１１）。

飲料ディスペンサ１０は、吐出開始指示が入力されると、セットされたボトル１９のサイズに対応した量の飲料を吐出する（Ｓ１２）。付言すると、本実施形態において、チケット３５のバーコード３５Ａには、飲料の種類の情報が保持されるが、１台の飲料ディスペンサ１０から吐出可能な飲料は、１種類のみである。但し、飲料ディスペンサ１０の夫々からは、異なる種類の飲料が提供されてもよい。異なる種類の飲料には、銘柄の異なるビールが含まれ得る。別の実施形態として、飲料ディスペンサ１０は、１台で複数種の飲料を提供可能に構成されてもよい。

顧客は、飲料ディスペンサ１０からの飲料の提供（吐出）が完了すると、当該飲料が収納されたボトル１９を飲料ディスペンサ１０から取り出し（Ｓ１３）、ボトル１９の開口端をキャップで閉めた後、当該飲料が収納されたボトル１９を店舗外に持ち出して楽しむことができる。

このように、本実施形態の制御システム１（図５参照）は、複数店舗の夫々に設置された飲料ディスペンサ１０及びＰＯＳ端末６０、複数店舗に共通して設けられた飲料提供サービス事業者の管理サーバ４０、並びに、店舗に対応する小売業者のＰＯＳサーバ８０との協働により、飲料の提供制御及び販売管理に係る処理を実現する。

ＰＯＳ端末６０からＰＯＳサーバ８０に提供された飲料の提供に関するＰＯＳデータは、例えば、飲料ディスペンサ１０の設置空間を提供した店舗に対応する小売業者が、飲料提供サービスを提供する事業者に対して、その飲料の提供量に応じた手数料を要求するのに用いられる。ＰＯＳデータは、飲料ディスペンサ１０に対する飲料補充を含む保守管理に用いられてもよい。

続いて、飲料提供に対して主要な役割を果たす飲料ディスペンサ１０及び管理サーバ４０の構成及び動作の詳細を説明する。飲料ディスペンサ１０のコントローラ２１は、ＲＯＭ２１Ｂが記憶するプログラムに従って、図６に示す発券制御処理を繰返し実行するように構成される。

図６に示す発券制御処理を開始すると、コントローラ２１は、ユーザインタフェース２５を通じてユーザから飲料の提供要求を受けるまで待機する（Ｓ１１０）。飲料の提供要求を受けると（Ｓ１１０でＹｅｓ）、コントローラ２１は、ユーザが所望する飲料提供量の情報を、ユーザインタフェース２５を通じて受け付けるための処理を実行する（Ｓ１２０）。コントローラ２１は、ユーザが所望する飲料提供量を選択可能な選択画面を表示させるように、ユーザインタフェース２５を制御することができる。例えば、選択画面は、ボトルサイズの選択画面であることができ、ユーザは、ボトルサイズの選択により、所望の飲料提供量を選択することができる。

飲料提供量を確定する操作がユーザインタフェース２５を通じてユーザからなされると（Ｓ１３０でＹｅｓ）、コントローラ２１は、ユーザが飲料提供サービスの利用登録を受けた正当な顧客であるか否かを確認するために、ユーザに対して会員証３０の提示を要求する（Ｓ１４０）。コントローラ２１は、例えば、会員証３０の提示を要求するメッセージを表示させるように、ユーザインタフェース２５を制御することができる。

その後、コントローラ２１は、読取部２３を制御し、ユーザから提示される会員証３０を読取部２３に読み取らせる（Ｓ１５０）。要求後、所定期間経過しても会員証３０を読み取ることができない場合、処理は、Ｓ１１０に戻されてもよい。

コントローラ２１は、Ｓ１５０において、読取部２３を通じた会員証３０の読取に成功すると、会員証３０から読み取った顧客ＩＤ、ユーザが所望する飲料提供量（ボトルサイズ）、及び、ディスペンサＩＤの情報を含む問い合わせ信号を、通信部２９から通信ネットワークを通じて管理サーバ４０に送信する（Ｓ１６０）。この問い合わせ信号は、飲料ディスペンサ１０を操作するユーザ（顧客）に、飲料を提供可能であるか否かを問い合わせる信号である。問い合わせ信号には、ユーザが要求する飲料の種類、換言すれば飲料ディスペンサ１０から提供される飲料の種類を表す情報が含まれていてもよい。

その後、コントローラ２１は、当該問い合わせ信号に対する応答信号を、管理サーバ４０から通信部２９を介して受信する（Ｓ１７０）。応答信号には、顧客に対する飲料の提供を許可するかしないかについての管理サーバ４０の判定結果が含まれる。応答信号には更に、チケット３５への印字に使用される顧客名及び顧客に対する飲料の提供履歴に関する情報が含まれてもよい。

コントローラ２１は、この応答信号に基づき、管理サーバ４０から飲料の提供が許可されている場合には（Ｓ１８０でＹｅｓ）、発券部２７を制御して、上述したバーコード３５Ａを含むチケット３５を、発券部２７に発行させる（Ｓ１９０）。その後、コントローラ２１は、発券制御処理を一旦終了した後、発券制御処理を再実行し、次の提供要求を受けるまで待機する（Ｓ１１０）。

コントローラ２１は、管理サーバ４０から飲料の提供が許可されていない場合には（Ｓ１８０でＮｏ）、飲料を提供できない旨をその理由と共に記したメッセージを、ユーザインタフェース２５に表示させるように、ユーザインタフェース２５を制御する（Ｓ１９５）。管理サーバ４０は、応答信号に、不許可の理由に対応したエラーコードを含ませることができる。その後、コントローラ２１は、発券制御処理を一旦終了した後、発券制御処理を再実行し、次の提供要求を受けるまで待機する（Ｓ１１０）。

上記発券制御処理によって送信される問い合わせ信号を受信する管理サーバ４０は、図２上段に示すように、演算部４１と、記憶部４３と、通信部４９と、を備える。通信部４９は、ネットワークを通じて複数の飲料ディスペンサ１０と通信可能に構成される。

演算部４１は、ＣＰＵ４１Ａと、ＲＡＭ４１Ｃと、備える。ＣＰＵ４１Ａは、記憶部４３が記憶するプログラムに従って、各種処理を実行する。各種処理には、飲料ディスペンサ１０からの問い合わせ信号に基づく処理も含まれる。ＲＡＭ４１Ｃは、ＣＰＵ４１Ａによる処理実行時に、作業用メモリとして使用される。ここでは、ＣＰＵ４１Ａが上記プログラムに従って実行する処理を、演算部４１が実行する処理として説明する。

記憶部４３は、上記プログラムと共に、顧客管理データベース４５を記憶する。顧客管理データベース４５は、図７に示すように、飲料提供サービスの利用登録を受けた顧客毎の管理データを有する。管理データは、顧客ＩＤと、顧客タイプを表す情報と、顧客に対する飲料提供毎の履歴データと、を備える。顧客タイプは、顧客が有効会員及び無効会員のいずれであるかを表す。有効会員は、飲料提供サービスを利用可能な顧客である。無効会員は、サービス利用料金の未受領等を原因として飲料提供サービスを利用不可能な顧客である。

履歴データは、演算部４１が顧客に対する飲料提供を許可する毎に、演算部４１により生成され、管理データに追加される。具体的には、演算部４１が通信部４９を通じて問い合わせ信号（Ｓ１６０）を受信して、顧客に対する飲料提供を許可する度に、生成される。この履歴データは、上記問い合わせ信号送信元のディスペンサＩＤの情報を含む。更に、この履歴データは、飲料の提供日時、具体的には、問い合わせ信号に応答して飲料の提供を許可した日時の情報を含む。更に、この履歴データは、顧客に対して提供を許可した飲料の種類及び提供量の情報を含む。

演算部４１は、このような構成の管理データを顧客毎に備える顧客管理データベース４５を参照して、問い合わせ信号に基づく許可判定処理（図８参照）を実行し、通信部４９を通じて、問い合わせ信号の送信元に、応答信号を送信する。

具体的に、演算部４１は、図８に示す許可判定処理を繰返し実行するように構成される。許可判定処理を開始すると、演算部４１は、通信部４９を通じて問い合わせ信号を受信するまで待機する（Ｓ２１０）。

問い合わせ信号を受信すると（Ｓ２１０でＹｅｓ）、演算部４１は、問い合わせ信号が表す顧客ＩＤの管理データを、顧客管理データベース４５内で特定し、当該管理データを参照する（Ｓ２２０）。問い合わせ信号が表す顧客ＩＤの管理データを、顧客管理データベース４５内で特定する動作は、飲料の提供を要求する顧客を識別する動作に対応する。演算部４１は、この管理データに基づき、顧客に対する飲料提供を許可するか否かを判定する（Ｓ２３０）。

Ｓ２３０において、演算部４１は、参照先の管理データが有する顧客タイプの情報に基づき、顧客が無効会員である場合には、飲料提供を許可しないと判定する。顧客が有効会員である場合、演算部４１は、参照先の管理データが有する履歴データの一群に基づき、飲料提供を許可するか否かを判定する。

演算部４１は、上記判定のために、参照先の管理データが有する履歴データの一群に基づき、顧客に対する過去所定期間内の提供量を算出することができる。また、演算部４１は、当該履歴データの一群に基づき、顧客に対する過去所定期間における飲料の提供回数を算出することができる。過去所定期間は、現在を基準とした過去の所定期間であり得る。

一例によれば、演算部４１は、過去所定期間内の提供量として、顧客に対する本日の飲料提供量を算出することができる。更に、演算部４１は、過去所定期間内の飲料提供回数として、直近１週間の飲料提供日数を算出することができる。直近１週間の飲料提供日数は、本日を含む過去１週間の飲料提供日数であり得る。

演算部４１は、このように算出した本日の飲料提供量と、直近１週間の飲料提供日数とに基づき、本日の飲料提供量が第一の閾値以下であり、且つ、直近１週間の飲料提供日数が第二の閾値以下である場合に、飲料の提供を許可し（Ｓ２３０でＹｅｓ）、それ以外の場合には、飲料提供を許可しないと判定する（Ｓ２３０でＮｏ）ことができる。

第一の閾値は、顧客の健康管理のために定められた１日当たりの提供量上限から、問い合わせ信号が表す顧客が所望する飲料提供量を減算した値であり得る。第二の閾値は、顧客の健康管理のために定められた１週間あたりのアルコール摂取日数の上限から、本日顧客に対する飲料提供を許可していない場合には値１を、本日顧客に対する飲料提供を既に許可している場合には値０を減算した日数であり得る。

別例として、演算部４１は、飲料提供回数（日数）に依らず、顧客が有効会員である場合であって、顧客に対する過去所定期間（例えば１日又は１週間）の飲料提供量が第三の閾値以下である場合に、飲料の提供を許可し（Ｓ２３０でＹｅｓ）、それ以外の場合には、飲料の提供を許可しないと判定する（Ｓ２３０でＮｏ）ように構成されてもよい。第三の閾値は、所定期間当たりの提供量上限、又は、所定期間当たりの提供量上限から、問い合わせ信号が表す顧客が所望する飲料提供量を減算した値であり得る。

更なる別例として、演算部４１は、飲料提供量に依らず、顧客が有効会員である場合であって、顧客に対する過去所定期間（例えば１日又は１週間）の飲料提供回数が、第四の閾値以下である場合に、飲料の提供を許可し（Ｓ２３０でＹｅｓ）、それ以外の場合には、飲料の提供を許可しないと判定する（Ｓ２３０でＮｏ）ように構成されてもよい。第四の閾値は、所定期間当たりの提供回数上限、又は、所定期間当たりの提供回数上限から１減算した回数であり得る。

演算部４１は、上記の方法に従って、飲料の提供を許可すると判定すると（Ｓ２３０でＹｅｓ）、顧客に対する飲料の提供を許可することを表す応答信号を、問い合わせ信号送信元に送信する（Ｓ２４０）。更に、演算部４１は、この応答信号によって許可した飲料提供が実行されると推定して、この飲料提供の実行に関する履歴データを、顧客の管理データに追加する（Ｓ２５０）。これにより、顧客の管理データを更新する。履歴データの構成は、上述した通りである。

一方、演算部４１は、飲料の提供を許可しないと判定すると（Ｓ２３０でＮｏ）、顧客に対する飲料の提供を許可しないことを表す応答信号を、問い合わせ信号送信元に送信する（Ｓ２６０）。演算部４１は、Ｓ２５０又はＳ２６０の処理を終了すると、当該許可判定処理を一旦終了する。演算部４１は、このような許可判定処理を繰返し実行する。

図９には、Ｓ８（図４参照）の処理過程で、ＰＯＳ端末６０が実行するチケット関連処理のフローチャートを示す。ＰＯＳ端末６０は、店員の指示に従ってチケット関連処理を開始すると、バーコードリーダ６１を用いてチケット３５のバーコード３５Ａを読み取り（Ｓ３１０）、そのバーコード３５Ａが表す商品ＩＤ及びディスペンサＩＤを含むＰＯＳデータを、ＰＯＳサーバ８０に送信する（Ｓ３２０）。その後、ＰＯＳ端末６０は、上記読み取ったバーコード３５Ａから特定される飲料の種類及び量の情報と共に、対応するサイズのボトルを提供するように指示するメッセージを、表示部６５に表示する（Ｓ３３０）。ＰＯＳ端末６０は、店員の指示に従って、上記チケット関連処理を繰返し実行するように構成される。

この他、飲料ディスペンサ１０のコントローラ２１は、発券制御処理とは別に、図１０に示す吐出制御処理を繰返し実行するように構成される。
図１０に示す吐出制御処理を開始すると、コントローラ２１は、ユーザインタフェース２５を通じてユーザ（顧客）から吐出開始指示が入力されるまで待機する（Ｓ４１０）。吐出開始指示が入力されると、コントローラ２１は、ノズル１３に対してボトル１９がセットされたか否かを、センサ１７の出力に基づき判断する（Ｓ４２０）。コントローラ２１は、ボトル１９がセットされていないと判断すると、ボトル１９をセットするように要求するメッセージを表示させるように、ユーザインタフェース２５を制御する（Ｓ４３０）。

このように、コントローラ２１は、ボトル１９がセットされるまで、上記メッセージの表示により、ユーザにボトル１９のセットを要求する。そして、ボトル１９がセットされていると判断すると（Ｓ４２０でＹｅｓ）、コントローラ２１は、セットされたボトル１９のサイズを、センサ１７の出力に基づき判別する（Ｓ４４０）。

その後、コントローラ２１は、吐出機構１１の駆動制御を開始し、吐出機構１１に、Ｓ４４０で判別したサイズのボトル１９の容積に対応する量の飲料をノズル１３から吐出させる（Ｓ４５０）。コントローラ２１は、このような吐出機構１１の制御を、ボトル１９の容積に対応する量の飲料をノズル１３から吐出させるまで実行する。ノズル１３からの上記対応する量の飲料吐出が完了すると（Ｓ４６０）、コントローラ２１は、飲料の吐出制御処理を終了する。コントローラ２１は、このような吐出制御処理を繰返し実行する。

以上に説明した本実施形態の制御システム１では、管理サーバ４０が、顧客毎の管理データに基づき、飲料を要求した顧客に対する飲料の提供を許可するか否かを判定する。飲料ディスペンサ１０は、この判定結果に従って、チケット３５の発行を制御する。顧客は、発行されたチケット３５に基づいて、飲料の提供を受けるために必要なボトル１９の提供を店員から受けることができ、飲料ディスペンサ１０に対するボトル１９のセットにより、飲料ディスペンサ１０を通じた飲料の提供を受けることができる。

本実施形態によれば、顧客毎の管理データには、顧客に対する過去の飲料の提供履歴を表す履歴データの一群が含まれる。管理サーバ４０は、この履歴データの一群に基づき飲料ディスペンサ１０からのチケット３５の発行を制御することによって、間接的には、顧客に対する飲料提供を、その飲料提供量及び飲料提供回数（日数）が、所定範囲を超えないように制御する。範囲は、顧客の健康が維持されるように定められる。

従って、本実施形態によれば、飲料ディスペンサ１０を用いてアルコール飲料（例えば生ビール）を提供する飲料提供サービスに好適な飲料の提供制御システムを構築することができる。換言すれば、本実施形態の制御システム１を用いることによっては、アルコール飲料の提供サービスを、顧客の健康維持を図りながら適切に運用することができる。

本実施形態によれば、チケット３５を通じてＰＯＳ端末６０からＰＯＳデータを送信するために、販売集計や飲料ディスペンサ１０の保守管理を容易に行うこともできる。従って、本実施形態の制御システム１は、複数店舗を通じた飲料提供サービスに対して大変有意義である。

上記実施形態では、管理サーバ４０が飲料の提供を許可した時点で、管理データに履歴データが追加されるが、制御システム１は、この履歴データを、例えば、ＰＯＳ端末６０からの取消し要求に従って削除可能に構成されてもよい。取消し要求は、例えば、店舗におけるボトル１９の在庫切れを原因として顧客に飲料を提供できない場合に役立つ。また、会員証３０は、ギフトカードの形態で、サービス利用料金の支払い者とは別の顧客に提供されてもよい。

［第二実施形態］
続いて、第二実施形態の制御システム２を、図１１〜図１４を用いて説明する。第二実施形態の制御システム２の構成の内、以下において説明されない構成は、第一実施形態の制御システム１と同様であると理解されてもよい。

図１１に示す本実施形態の制御システム２は、第一実施形態と同様、複数店舗に設置された飲料ディスペンサ１１０及びＰＯＳ端末１６０と、複数店舗に共通して設けられた管理サーバ１４０と、ＰＯＳサーバ１８０とを備える。第一実施形態との相違点として、本実施形態の制御システム２は、会員証３０の読取からボトル１９の提供までの一連の手続きに必要な店舗内の処理を、ＰＯＳ端末１６０が実行するように構成にされる。

本実施形態において、店舗に設置される飲料ディスペンサ１１０は、図１２に示すように、吐出機構１１１、コントローラ１２１、及びユーザインタフェース１２５を備える。吐出機構１１１、コントローラ１２１、及びユーザインタフェース１２５は、夫々、第一実施形態の吐出機構１１、コントローラ２１、及びユーザインタフェース２５と同一のハードウェア構成を有する。

コントローラ１２１は、ＣＰＵ１２１Ａと、ＲＯＭ１２１Ｂと、ＲＡＭ１２１Ｃと、を備える。ＣＰＵ１２１Ａは、ＲＯＭ１２１Ｂが記憶するプログラムに従う処理を実行する。ＲＡＭ１２１Ｃは、ＣＰＵ１２１Ａによる処理実行時に作業用メモリとして使用される。コントローラ１２１が実行する処理は、基本的に、ＣＰＵ１２１Ａが上記プログラムに従う処理を実行することにより実現される。ここでは、ＣＰＵ１２１Ａが上記プログラムに従って実行する処理を、コントローラ１２１が実行する処理として説明する。

図１２から理解できるように、本実施形態の飲料ディスペンサ１１０は、第一実施形態の飲料ディスペンサ１０が備える読取部２３、発券部２７及び通信部２９を備えない。更に、飲料ディスペンサ１１０のコントローラ１２１は、図１０に示す吐出制御処理を実行するが、図６に示す発券制御処理を実行しないように構成される。上記の点を除いて、飲料ディスペンサ１１０は、基本的に、第一実施形態の飲料ディスペンサ１０と同一構成にされる。

一方、第一実施形態のＰＯＳ端末６０に対応する本実施形態のＰＯＳ端末１６０は、図１３に示すように構成される。即ち、ＰＯＳ端末１６０は、バーコードリーダ１６１と、コントローラ１６３と、表示部１６５と、操作部１６６と、カードリーダ１６７と、通信部１６９と、を備える。バーコードリーダ１６１は、バーコードを読取可能に構成される。

コントローラ１６３は、ＰＯＳ端末１６０の全体を統括制御するように構成される。具体的に、コントローラ１６３は、ＣＰＵ１６３Ａと、ＲＯＭ１６３Ｂと、ＲＡＭ１６３Ｃと、を備える。ＣＰＵ１６３Ａは、ＲＯＭ１６３Ｂが記憶するプログラムに従う処理を実行する。ＲＡＭ１６３Ｃは、ＣＰＵ１６３Ａによる処理実行時に作業用メモリとして使用される。コントローラ１６３が実行する処理は、基本的に、ＣＰＵ１６３Ａが上記プログラムに従う処理を実行することにより実現される。ここでは、ＣＰＵ１６３Ａが上記プログラムに従って実行する処理を、コントローラ１６３が実行する処理として説明する。

表示部１６５は、コントローラ１６３に制御され、ＰＯＳ端末１６０の操作者に向けて各種情報を表示するように構成される。表示部１６５は、例えば、液晶ディスプレイで構成される。操作部１６６は、ＰＯＳ端末１６０の操作者（例えば店員）からの入力操作を受付可能な構成にされる。入力操作情報は、操作部１６６からコントローラ１６３に伝達される。

カードリーダ１６７は、会員証３０を読取可能に構成される。この他、通信部１６９は、管理サーバ１４０及びＰＯＳサーバ１８０とネットワークを通じて通信可能に構成される。通信部１６９は、コントローラ１６３に制御されて、第一実施形態において飲料ディスペンサ１０が送信する問い合わせ信号と同様の信号を、管理サーバ１４０に送信し、その応答信号を管理サーバ１４０から受信する。また、通信部１６９は、コントローラ１６３に制御されて、第一実施形態においてＰＯＳ端末６０が送信するＰＯＳデータと同様のＰＯＳデータを、ＰＯＳサーバ１８０に送信する。

このＰＯＳ端末１６０のコントローラ１６３は、操作部１６６を通じて飲料提供サービスに関する処理の実行指示が入力されると、図１４に示す利用受付処理を実行するように構成される。飲料ディスペンサ１１０が設置された店舗の店員は、例えば口頭で、顧客から飲料の提供要求があると、ＰＯＳ端末１６０を操作して、上記実行指示を入力することができる。第一実施形態では、飲料ディスペンサ１０に対して顧客から飲料の提供要求が入力されたが、本実施形態では、このように顧客から店員に口頭で飲料の提供要求が伝えられる。

ＰＯＳ端末１６０のコントローラ１６３は、利用受付処理を開始すると、顧客から提示された会員証３０を、カードリーダ１６７を通じて読み取る処理を実行する（Ｓ５１０）。その後、コントローラ１６３は、顧客が所望する飲料提供量（例えばボトルサイズ）の情報を受け付けるための処理を実行する（Ｓ５２０）。

Ｓ５２０において、コントローラ１６３は、所望する飲料提供量（例えばボトルサイズ）の情報を入力することを要求するメッセージを、表示部１６５に表示させ、操作部１６６からの飲料提供量の入力を受け付けることができる。入力は、店員の操作、及び、顧客の操作のいずれによって実現されてもよい。ＰＯＳ端末１６０は、表示部１６５及び操作部１６６として、店員側の表示部及び操作部と、顧客側の表示部及び操作部を備えた構成にされ得る。

コントローラ１６３は、上記飲料提供量の入力操作が完了すると（Ｓ５３０でＹｅｓ）、顧客に飲料を提供可能であるか否かを問い合わせる問い合わせ信号を、管理サーバ１４０に通信部１６９を介して送信する（Ｓ５４０）。

問い合わせ信号は、第一実施形態と同様、会員証３０から読み取った顧客ＩＤ、顧客が所望する飲料提供量（ボトルサイズ）、及び、ディスペンサＩＤの情報を含むことができる。ディスペンサＩＤは、ＰＯＳ端末１６０と関連付けられた同一店舗内の飲料ディスペンサ１１０の識別コードである。このディスペンサＩＤに加えて又は代えて、問い合わせ信号には、店舗の識別コードである店舗ＩＤが含まれていてもよい。

この問い合わせ信号を受信する管理サーバ１４０は、第一実施形態の管理サーバ４０と同様の構成にされ、問い合わせ信号に基づく図８に示す許可判定処理を実行し、対応する応答信号を、問い合わせ信号送信元のＰＯＳ端末１６０に送信する。応答信号には、顧客に対する飲料の提供を許可するかしないかについての管理サーバ１４０の判定結果が含まれる。

問い合わせ信号送信後、コントローラ１６３は、問い合わせ信号に対する応答信号を、管理サーバ１４０から通信部１６９を介して受信する（Ｓ５５０）。コントローラ１６３は、受信した応答信号に基づき、管理サーバ１４０から飲料の提供が許可されている場合には（Ｓ５６０でＹｅｓ）、当該飲料に関するＰＯＳデータを、通信部１６９を介してＰＯＳサーバ１８０に送信する（Ｓ５７０）。ＰＯＳデータは、提供される飲料の種類及び量、ディスペンサＩＤ、及び、店舗ＩＤの情報を含むことができる。

更に、ＰＯＳ端末１６０は、提供が許可された飲料の当該提供量に対応するサイズのボトル１９を提供するように指示するメッセージを、表示部１６５に表示させることにより、店員から顧客にボトル１９が提供されるように促す（Ｓ５８０）。その後、当該利用受付処理を終了する。

管理サーバ１４０から飲料の提供が許可されていない場合（Ｓ５６０でＮｏ）、コントローラ１６３は、飲料を提供できない旨をその理由と共に記したメッセージを、表示部１６５に表示させるように、表示部１６５を制御する（Ｓ５９０）。その後、コントローラ１６３は、当該利用受付処理を終了する。

このような処理を経て、店員からボトル１９を受け取った顧客は、第一実施形態と同様に、ボトル１９を飲料ディスペンサ１１０にセットして、吐出開始指示を、ユーザインタフェース１２５を通じて入力することができる。この吐出開始指示を受けて、飲料ディスペンサ１１０のコントローラ１２１は、図１０に示すＳ４２０以降の処理を実行し、顧客に飲料を提供することができる。

以上に説明した本実施形態の制御システム２によれば、第一実施形態と比較して、チケット３５に関連する顧客及び店員の操作を省略することができる。従って、本実施形態によれば、顧客にとって利便性の飲料提供サービスを実現することができる。

［第三実施形態］
続いて、第三実施形態の制御システム３を、図１５〜図１９を用いて説明する。本実施形態の制御システム３は、第二実施形態の制御システム２において、飲料提供サービスのためにＰＯＳ端末１６０が実行する処理を、およそ飲料ディスペンサ２１０が実行するように構成されたものである。従って、本実施形態の制御システム３は、図１５に示すように、ＰＯＳ端末１６０なしで、飲料提供サービスを顧客に提供可能な構成にされる。

図１５に示すように、本実施形態の制御システム３は、複数店舗に設置された飲料ディスペンサ２１０と、複数店舗に共通して設けられる管理サーバ２４０と、ＰＯＳサーバ２８０とを備える。

飲料ディスペンサ２１０は、図１６に示すように、吐出機構２１１、コントローラ２２１、読取部２２３、ユーザインタフェース２２５、及び、通信部２２９を備える。吐出機構２１１、コントローラ２２１、読取部２２３、ユーザインタフェース２２５、及び、通信部２２９は、夫々、第一実施形態の吐出機構１１、コントローラ２１、読取部２３、ユーザインタフェース２５、及び、通信部２９と同一のハードウェア構成を有する。

コントローラ２２１は、ＣＰＵ２２１Ａと、ＲＯＭ２２１Ｂと、ＲＡＭ２２１Ｃと、を備える。ＣＰＵ２２１Ａは、ＲＯＭ２２１Ｂが記憶するプログラムに従う処理を実行する。ＲＡＭ２２１Ｃは、ＣＰＵ２２１Ａによる処理実行時に作業用メモリとして使用される。コントローラ２２１が実行する処理は、基本的に、ＣＰＵ２２１Ａが上記プログラムに従う処理を実行することにより実現される。ここでは、ＣＰＵ２２１Ａが上記プログラムに従って実行する処理を、コントローラ２２１が実行する処理として説明する。

図１６から理解できるように、本実施形態の飲料ディスペンサ２１０は、第一実施形態の飲料ディスペンサ１０が備える発券部２７を備えない。更に、飲料ディスペンサ２１０のコントローラ２２１は、図６及び図１０に示す処理に代えて、図１７及び図１８に示す飲料提供処理を繰返し実行するように構成される。上記の点を除いて、飲料ディスペンサ２１０は、基本的に、第一実施形態の飲料ディスペンサ１０と同一構成である。

管理サーバ２４０は、図２に示される第一実施形態の管理サーバ４０と同一のハードウェア構成にされる。従って、以下では、図２で示される符号を用いて、管理サーバ２４０の動作を説明する。管理サーバ２４０の演算部４１は、図８に示す許可判定処理に代えて、図１９に示す許可判定処理を繰返し実行するように構成される。この許可判定処理は、記憶部４３が記憶するプログラムに従う処理をＣＰＵ４１Ａが実行することにより実現される。本実施形態の管理サーバ２４０も、記憶部４３に、顧客管理データベース４５を備える。

飲料ディスペンサ２１０のコントローラ２２１は、図１７及び図１８に示す飲料提供処理をＲＯＭ２２１Ｂが記憶するプログラムに従って開始すると、ユーザインタフェース２２５を通じてユーザから飲料の提供要求を受けるまで待機する（Ｓ６１０）。飲料の提供要求を受けると（Ｓ６１０でＹｅｓ）、コントローラ２２１は、ユーザが所望する飲料提供量を、ユーザインタフェース２２５を通じて、ユーザから受け付けるための処理を実行する（Ｓ６２０）。Ｓ６２０の処理は、第一実施形態におけるＳ１２０（図６）の処理と同様であると理解されてよい。

飲料提供量を確定する操作がユーザインタフェース２２５を通じてユーザからなされると（Ｓ６３０でＹｅｓ）、コントローラ２２１は、Ｓ１４０の処理と同様、ユーザに対して会員証３０の提示を要求する（Ｓ６４０）。その後、コントローラ２２１は、読取部２２３を制御し、ユーザから提示される会員証３０を読取部２２３に読み取らせる（Ｓ６５０）。

コントローラ２２１は、Ｓ６５０において、読取部２２３を通じた会員証３０の読取に成功すると、Ｓ１６０の処理と同様、会員証３０から読み取った顧客ＩＤ、ユーザが所望する飲料提供量（ボトルサイズ）、及び、ディスペンサＩＤの情報を含む問い合わせ信号を、通信部２２９から通信ネットワークを通じて管理サーバ２４０に送信する（Ｓ６６０）。更に、コントローラ２２１は、問い合わせ信号に対する応答信号を、管理サーバ２４０から通信部２２９を介して受信する（Ｓ６７０）。

コントローラ２２１は、この管理サーバ２４０からの応答信号に基づき、管理サーバ２４０から飲料の提供が許可されている場合には（Ｓ６８０でＹｅｓ）、Ｓ７００以降の処理（図１８参照）を実行する。管理サーバ２４０から飲料の提供が許可されていない場合（Ｓ６８０でＮｏ）、コントローラ２２１は、Ｓ１９５の処理と同様、飲料を提供できない旨をその理由と共に記したメッセージを、ユーザインタフェース２２５に表示させるように、ユーザインタフェース２２５を制御する（Ｓ６９０）。その後、当該飲料提供処理を一旦終了する。

コントローラ２２１は、飲料の提供が許可されていることで、処理をＳ７００に移行すると、ユーザインタフェース２２５を通じてユーザから取消操作がなされたか否かを判断する。そして、取消操作がなされたと判断すると（Ｓ７００でＹｅｓ）、取消通知信号を、通信部２２９を通じて管理サーバ２４０に送信した後（Ｓ７０５）、当該飲料提供処理を終了する。

コントローラ２２１は、取消操作がなされていないと判断すると（Ｓ７００でＮｏ）、ノズル１３に対してボトル１９がセットされたか否かを、センサ１７の出力に基づき判断する。吐出機構２１１は、第一実施形態と吐出機構１１と同様に構成され、ノズル１３及びセンサ１７を備える。

コントローラ２２１は、ボトル１９がセットされていないと判断すると（Ｓ７１０でＮｏ）、ボトル１９をセットするように要求するメッセージを表示させるように、ユーザインタフェース２２５を制御する（Ｓ７２０）。その後、処理をＳ７００に戻す。

コントローラ２２１は、ボトル１９がセットされていると判断すると（Ｓ７１０でＹｅｓ）、セットされたボトル１９のサイズを、センサ１７の出力に基づき判別する（Ｓ７３０）。その後、コントローラ２２１は、セットされたボトル１９が、適切なサイズであるか否かを判断する（Ｓ７４０）。ここで言う適切なボトルサイズは、Ｓ６２０で受け付けた提供量の飲料を収納可能であるが、それを超える飲料を基本的には収納できないボトルサイズである。

コントローラ２２１は、セットされたボトル１９が適切なサイズでないと判断すると（Ｓ７４０でＮｏ）、適切なサイズのボトル１９をセットするように要求するメッセージを表示させるように、ユーザインタフェース２２５を制御する（Ｓ７５０）。その後、処理をＳ７００に戻す。

適切なサイズのボトル１９がユーザによりセットされると（Ｓ７４０でＹｅｓ）、コントローラ２２１は、Ｓ７４０において肯定判断して、処理をＳ７６０に移行する。
Ｓ７６０において、コントローラ２２１は、吐出機構２１１の駆動制御を開始し、吐出機構２１１に、Ｓ７３０で判別したサイズのボトル１９の容積に対応する量の飲料をノズル１３から吐出させる（Ｓ７６０）。コントローラ２２１は、このような吐出機構２１１の制御を、ボトル１９の容積に対応する量の飲料をノズル１３から吐出させるまで実行する。

ノズル１３からの上記対応する量の飲料吐出が完了すると（Ｓ７７０でＹｅｓ）、コントローラ２２１は、今回の飲料の提供に関するＰＯＳデータを、通信部２２９を通じてＰＯＳサーバ２８０に送信すると共に（Ｓ７８０）、飲料の提供完了を知らせる完了通知信号を管理サーバ２４０に送信する（Ｓ７９０）。その後、当該飲料提供処理を一旦終了する。

この飲料ディスペンサ２１０が送信する問い合わせ信号、完了通知信号、及び取消通知信号を受ける管理サーバ２４０の演算部４１は、図１９に示す許可判定処理を繰返し実行する。

許可判定処理を開始すると、演算部４１は、飲料ディスペンサ１０から通信部４９を通じて問い合わせ信号を受信するまで待機し（Ｓ９１０）、問い合わせ信号を受信すると（Ｓ９１０でＹｅｓ）、問い合わせ信号が表す顧客ＩＤの管理データを、顧客管理データベース４５内で特定し、当該管理データを参照する（Ｓ９２０）。演算部４１は、この参照先の管理データに基づき、顧客に対する飲料提供を許可するか否かを判定する（Ｓ９３０）。Ｓ９３０では、第一実施形態におけるＳ２３０（図８）での処理と同様の手法で、顧客に対する飲料提供を許可するか否かを判定することができる。

演算部４１は、上記管理データに基づき、飲料の提供を許可しないと判定すると（Ｓ９３０でＮｏ）、顧客に対する飲料の提供を許可しないことを表す応答信号を、問い合わせ信号送信元に送信する（Ｓ９８０）。その後、許可判定処理を一旦終了する。

一方、演算部４１は、飲料の提供を許可すると判定すると（Ｓ９３０でＹｅｓ）、顧客に対する飲料の提供を許可することを表す応答信号を、問い合わせ信号送信元に送信する（Ｓ９４０）。

その後、演算部４１は、問い合わせ信号送信元の飲料ディスペンサ２１０から上記取消通知信号及び完了通知信号のいずれかを通信部４９を通じて受信するまで待機する（Ｓ９５０，Ｓ９６０）。演算部４１は、取消通知信号を受信すると（Ｓ９５０でＹｅｓ）、参照先の管理データを更新せずに、当該許可判定処理を終了する。一方、演算部４１は、完了通知信号を受信すると（Ｓ９６０でＹｅｓ）、飲料ディスペンサ２１０を通じた顧客への飲料提供が完了したとみなして、参照先の管理データを更新する（Ｓ９７０）。Ｓ９７０の処理は、Ｓ２５０と同様である。即ち、演算部４１は、Ｓ９４０での応答信号の送信によって許可した飲料ディスペンサ２１０による飲料提供に関する履歴データを、顧客の管理データに追加する。これにより、顧客の管理データを更新する。追加される履歴データは、ディスペンサＩＤと、飲料の提供日時の情報と、顧客に提供された飲料の種類及び提供量の情報とを含む。演算部４１は、このように管理データを更新すると、当該許可判定処理を一旦終了する。

以上に説明した本実施形態の制御システム３によれば、飲料提供サービスの運用に伴って、店舗内のＰＯＳ端末を改造する必要がない。また、本実施形態によれば、飲料提供が完了したことに基づいて、管理サーバ２４０が、管理データを更新するので、管理データには、提供の事実に基づくより適切な履歴データを格納することができる。

本実施形態によれば、飲料ディスペンサ２１０の前に位置する顧客から届く位置に、顧客が持ち出し可能なボトル１９を配置することで、顧客は、飲料ディスペンサ２１０の前から移動することなく、飲料の提供要求から、飲料の受け取りまでの作業を終えることができる。従って、本実施形態の制御システム３に基づいて飲料提供サービスを提供すれば、顧客には大変便利である。

［その他の実施形態］
以上に、本開示の例示的実施形態として、制御システム１，２，３を説明したが、本開示は、上記実施形態に限定されるものではなく、種々の態様を採ることができる。

例えば、Ｓ２３０（図８），Ｓ９３０（図１９）の処理において、演算部４１は、管理データが備える履歴データの一群から、顧客に対して提供可能な飲料の残り量及び／又は残り回数（日数）を特定して、残り量及び／又は残り回数（日数）に基づき、顧客に対して飲料の提供を許可するか否かを判定してもよい。この判定のために、予め設定された残り提供可能量／回数が、提供の度に減算／デクリメントされてもよい。判定は、その残り提供可能量／回数を参照して行われもよい。この判定のために、管理データは、履歴データに代えて又は加えて、残り提供可能量／回数の情報を有し得る。管理データの更新動作は、残り提供可能量／回数の更新動作を含むことができる。別例として、管理データは、履歴データに代えて又は加えて、基準時点から現在までの顧客に対する飲料提供量／提供回数の情報を有していてもよい。即ち、顧客に対して飲料の提供を許可するか否かの判定は、飲料提供量／提供回数の上限値と、現在までの顧客に対する飲料提供量／提供回数との対比により行われてもよい。

この他、顧客に飲料提供を許可するか否かの判定主体は、管理サーバ４０，１４０，２４０ではなく、飲料ディスペンサ１０，２１０、又は、ＰＯＳ端末１６０であってもよい。飲料ディスペンサ１０，２１０、又は、ＰＯＳ端末１６０は、管理サーバ４０，１４０，２４０から上記応答信号を受信する代わりに、顧客ＩＤに対応する管理データを受信して、受信した管理データに基づき、顧客に対する飲料提供を許可するか否かを判定することができる。

この他、管理サーバ４０，１４０，２４０は、管理データに基づいて、顧客に対する過去の提供量及び／若しくは提供回数（日数）、又は、顧客に対する飲料の残り提供量及び／若しくは残り提供回数（日数）を算出し、その算出値を、上記応答信号に代えて、飲料ディスペンサ１０，２１０、又は、ＰＯＳ端末１６０に送信する構成にされてもよい。これに対応して、飲料ディスペンサ１０，２１０、又は、ＰＯＳ端末１６０は、管理サーバ４０，１４０，２４０から受信した算出値と閾値との比較により、顧客に対する飲料提供を許可するか否かを判定するように構成されてもよい。

上記実施形態における１つの構成要素が有する機能は、複数の構成要素に分散して設けられてもよい。複数の構成要素が有する機能は、１つの構成要素に統合されてもよい。上記実施形態の構成の一部は、省略されてもよい。上記実施形態の構成の少なくとも一部は、他の上記実施形態の構成に対して付加又は置換されてもよい。特許請求の範囲に記載の文言から特定される技術思想に含まれるあらゆる態様が本開示の実施形態である。

［用語間の対応関係］
用語間の対応関係は、次の通りである。管理サーバ４０，１４０，２４０の演算部４１が実行するＳ２２０，Ｓ９２０の処理は、識別ユニットにより実現される処理の一例に対応し、管理サーバ４０，１４０，２４０が実行するＳ２３０，Ｓ９３０の処理は、許可ユニットにより実現される処理の一例に対応する。飲料ディスペンサ１０のコントローラ２１が実行する発券制御処理は、発行ユニットにより実現される処理の一例に対応する。飲料ディスペンサ１０，２１０が備える読取部２３，２２３及びＰＯＳ端末１６０が備えるカードリーダ１６７は、入力ユニットの一例に対応する。ＰＯＳ端末６０が実行するチケット関連処理は、情報提供ユニットにより実現される処理の一例に対応する。管理サーバ１４０が実行するＳ２４０の処理は、出力ユニットにより実現される処理の一例に対応する。飲料ディスペンサ２１０のコントローラ２２１が実行するＳ７６０の処理は、制御ユニットにより実現される処理の一例に対応する。コントローラ２２１が実行するＳ７９０の処理は、通知ユニットにより実現される処理に一例に対応し、管理サーバ２４０の演算部４１が実行するＳ９７０の処理は、更新ユニットの一例に対応する。

１…制御システム、２…制御システム、３…制御システム、１０…飲料ディスペンサ、１１…吐出機構、１３…ノズル、１７…センサ、１９…ボトル、２１…コントローラ、２１Ａ…ＣＰＵ、２１Ｂ…ＲＯＭ、２３…読取部、２５…ユーザインタフェース、２７…発券部、２９…通信部、３０…会員証、３５…チケット、３５Ａ…バーコード、４０…管理サーバ、４１…演算部、４１Ａ…ＣＰＵ、４３…記憶部、４５…顧客管理データベース、４９…通信部、６０…ＰＯＳ端末、６１…バーコードリーダ、６５…表示部、８０…ＰＯＳサーバ、１１０…飲料ディスペンサ、１１１…吐出機構、１２１…コントローラ、１２１Ａ…ＣＰＵ、１２１Ｂ…ＲＯＭ、１２５…ユーザインタフェース、１２９…通信部、１４０…管理サーバ、１６０…ＰＯＳ端末、１６３…コントローラ、１６３Ａ…ＣＰＵ、１６３Ｂ…ＲＯＭ、１６５…表示部、１６６…操作部、１６７…カードリーダ、１６９…通信部、１８０…ＰＯＳサーバ、２１０…飲料ディスペンサ、２１１…吐出機構、２２１…コントローラ、２２１Ａ…ＣＰＵ、２２１Ｂ…ＲＯＭ、２２３…読取部、２２５…ユーザインタフェース、２２９…通信部、２４０…管理サーバ、２８０…ＰＯＳサーバ。

Claims (24)

1. 飲料を要求する顧客である要求顧客を識別するように構成される識別ユニットと、
   前記識別ユニットにより識別された前記要求顧客に対する前記飲料の提供を許可するように構成される許可ユニットと、
   を備え、前記許可ユニットは、顧客毎の管理データとして顧客に対する飲料の過去の提供に関するデータを記憶する記憶デバイスが記憶する前記要求顧客の前記管理データに基づき、前記要求顧客に対する第一の期間における前記飲料の提供量及び提供回数の少なくとも一方が第一の条件を満足し、且つ、前記第一の期間より長い第二の期間における前記飲料の提供量及び提供回数の少なくとも一方が前記第一の条件とは別の第二の条件を満足することを条件に、前記飲料の提供を許可する飲料の提供制御システム。
2. 前記許可ユニットは、仮に前記飲料の提供を許可したときに前記要求顧客に提供される前記飲料を含む前記第一の期間における前記飲料の提供量及び提供回数の少なくとも一方が、前記第一の条件としての第一の上限以下であり、且つ、仮に前記飲料の提供を許可したときに前記要求顧客に提供される前記飲料を含む前記第二の期間における前記飲料の提供量及び提供回数の少なくとも一方が、前記第二の条件としての第二の上限以下であることを条件に、前記飲料の提供を許可する請求項１記載の飲料の提供制御システム。
3. 前記飲料の容器への注入量を予め指定する指定情報を取得するように構成される取得ユニット
   を備え、前記許可ユニットは、前記指定情報に基づく予め指定された前記注入量の前記飲料の提供を許可するように構成される請求項１又は請求項２記載の飲料の提供制御システム。
4. 飲料を要求する顧客である要求顧客を識別するように構成される識別ユニットと、
   前記飲料の容器への注入量を予め指定する指定情報を取得するように構成される取得ユニットと、
   前記識別ユニットにより識別された前記要求顧客に対する、前記指定情報に基づく予め指定された前記注入量の前記飲料の提供を許可するように構成される許可ユニットと、
   を備え、
   前記注入量は、前記指定によって変化する量であり、
   前記許可ユニットは、顧客毎の管理データとして顧客に対する飲料の過去の提供に関するデータを記憶する記憶デバイスが記憶する前記要求顧客の前記管理データから特定される前記要求顧客に対する過去の前記飲料の提供量と、仮に前記飲料の提供を許可した場合に前記要求顧客に対して提供される飲料の提供量である前記注入量と、に基づき、前記要求顧客に対する前記飲料の提供を許可するか否かを判定する飲料の提供制御システム。
5. 前記許可ユニットは、仮に前記飲料の提供を許可したときに前記要求顧客に提供される前記注入量の前記飲料を含む前記要求顧客に対する過去所定期間内の前記飲料の総提供量が所定量以下である場合には、前記要求顧客に対する前記飲料の提供を許可し、前記総提供量が前記所定量より大きい場合には、前記要求顧客に対する前記飲料の提供を許可しないように構成される請求項４記載の提供制御システム。
6. 飲料を要求する顧客である要求顧客を識別するように構成される識別ユニットと、
   前記識別ユニットにより識別された前記要求顧客に対する前記飲料の提供を許可するように構成される許可ユニットと、
   前記飲料を提供する飲料ディスペンサに設けられ、前記飲料の提供が許可されたことを条件に、前記飲料に関するチケットを発行する発行ユニットと、
   を備え、
   前記許可ユニットは、顧客毎の管理データとして顧客に対する飲料の過去の提供に関するデータを記憶する記憶デバイスが記憶する前記要求顧客の前記管理データに基づき、前記要求顧客に対する前記飲料の提供を許可するか否かを判定し、
   前記発行ユニットは、前記飲料の提供が許可されたことを条件に、前記飲料に関するチケットとして、前記飲料ディスペンサから提供される前記飲料を収納するための容器を受け取る権利が化体されたチケットを出力するように構成される飲料の提供制御システム。
7. 顧客の識別情報を入力する入力ユニットを前記飲料ディスペンサに備え、
   前記識別ユニットは、前記入力ユニットから入力される前記識別情報に基づき、前記要求顧客を識別する請求項６記載の提供制御システム。
8. 前記チケットは、チケット発行元の前記飲料ディスペンサを特定可能な情報、及び、提供対象の前記飲料の種類及び量の少なくとも一方を特定可能な情報、の少なくとも一方を保持し、
   前記提供制御システムは、前記チケットが保持する情報を読み取って、外部の情報管理システムに送信する情報提供ユニットを、販売時点情報管理機能を有する店舗端末に備える請求項６又は請求項７記載の提供制御システム。
9. 前記識別ユニット及び前記許可ユニットを、前記飲料ディスペンサと通信可能なサーバ装置に備える請求項６〜請求項８のいずれか一項記載の提供制御システム。
10. 販売時点情報管理機能を有する店舗端末に設けられた入力ユニットから入力される、顧客の識別情報に基づき、飲料を要求する顧客である要求顧客を識別するように構成される識別ユニットと、
    前記識別ユニットにより識別された前記要求顧客に対する前記飲料の提供を許可するように構成される許可ユニットと、
    を備え、前記許可ユニットは、顧客毎の管理データとして顧客に対する飲料の過去の提供に関するデータを記憶する記憶デバイスが記憶する前記要求顧客の前記管理データに基づき、前記要求顧客に対する前記飲料の提供を許可するか否かを判定する飲料の提供制御システム。
11. 前記飲料の提供が許可されたことを条件に、前記店舗端末に対して前記飲料の提供が許可されたことを示す情報を出力する出力ユニットを更に備える請求項１０記載の提供制御システム。
12. 前記識別ユニット、前記許可ユニット、及び前記出力ユニットを、前記店舗端末と通信可能なサーバ装置に備える請求項１１記載の提供制御システム。
13. 顧客の識別情報を入力する入力ユニットを、前記飲料を提供する飲料ディスペンサに備え、
    前記識別ユニットは、前記入力ユニットから入力される前記識別情報に基づき、前記要求顧客を識別する請求項１〜請求項５のいずれか一項記載の提供制御システム。
14. 前記許可ユニットにより前記飲料の提供が許可されたことに応じて、前記飲料ディスペンサを制御する制御ユニットを備える請求項６〜請求項９及び請求項１３のいずれか一項記載の提供制御システム。
15. 前記飲料ディスペンサは、前記飲料を吐出する飲料吐出機構を備え、
    前記制御ユニットは、前記飲料の提供が許可されたことを条件に、前記飲料吐出機構から前記飲料が吐出されるように、前記飲料吐出機構を制御する請求項１４記載の提供制御システム。
16. 飲料を提供する飲料ディスペンサに設けられ、顧客の識別情報を入力する入力ユニットと、
    前記飲料ディスペンサと通信可能なサーバ装置に設けられ、前記入力ユニットから入力される前記識別情報に基づき、前記飲料を要求する顧客である要求顧客を識別するように構成される識別ユニットと、
    前記サーバ装置に設けられ、前記識別ユニットにより識別された前記要求顧客に対する前記飲料の提供を許可するように構成される許可ユニットと、
    前記飲料ディスペンサに設けられ、前記許可ユニットにより前記飲料の提供が許可されたことに応じて、前記飲料ディスペンサによる前記飲料の吐出を制御する制御ユニットと、
    を備え、前記許可ユニットは、顧客毎の管理データとして顧客に対する飲料の過去の提供に関するデータを記憶する記憶デバイスが記憶する前記要求顧客の前記管理データに基づき、前記要求顧客に対する前記飲料の提供を許可するか否かを判定する飲料の提供制御システム。
17. 前記飲料ディスペンサに設けられ、前記飲料の提供が完了したことを通知する通信信号を出力する通知ユニットと、
    前記サーバ装置に設けられ、前記飲料ディスペンサから前記通信信号を受信したことを条件に、前記記憶デバイスが記憶する、前記飲料の提供が完了した前記要求顧客の前記管理データを更新することによって、前記管理データが表す前記要求顧客に対する前記飲料の過去の提供に関する情報を更新する更新ユニットと、
    を備える請求項１６記載の提供制御システム。
18. 前記飲料は、アルコール類である請求項１〜請求項１７のいずれか一項記載の提供制御システム。
19. コンピュータにより実行される方法であって、
    飲料を要求する顧客である要求顧客を識別する手順と、
    前記識別された前記要求顧客に対する前記飲料の提供を許可する手順と、
    を含み、前記許可する手順は、顧客毎の管理データとして顧客に対する飲料の過去の提供に関するデータを記憶する記憶デバイスが記憶する前記要求顧客の前記管理データに基づき、前記要求顧客に対する第一の期間における前記飲料の提供量及び提供回数の少なくとも一方が第一の条件を満足し、且つ、前記第一の期間より長い第二の期間における前記飲料の提供量及び提供回数の少なくとも一方が前記第一の条件とは別の第二の条件を満足することを条件に、前記飲料の提供を許可する手順を含む飲料の提供制御方法。
20. コンピュータにより実行される方法であって、
    飲料を要求する顧客である要求顧客を識別する手順と、
    前記飲料の容器への注入量を予め指定する指定情報を取得する手順と、
    前記識別する手順により識別された前記要求顧客に対する、前記指定情報に基づく予め指定された前記注入量の前記飲料の提供を許可する手順と、
    を含み、
    前記注入量は、前記指定によって変化する量であり、
    前記許可する手順は、顧客毎の管理データとして顧客に対する飲料の過去の提供に関するデータを記憶する記憶デバイスが記憶する前記要求顧客の前記管理データから特定される前記要求顧客に対する過去の前記飲料の提供量と、仮に前記飲料の提供を許可した場合に前記要求顧客に対して提供される飲料の提供量である前記注入量と、に基づき、前記要求顧客に対する前記飲料の提供を許可するか否かを判定する手順を含む飲料の提供制御方法。
21. コンピュータにより実行される方法であって、
    飲料を要求する顧客である要求顧客を識別する手順と、
    前記識別する手順により識別された前記要求顧客に対する前記飲料の提供を許可する手順と、
    前記飲料の提供が許可されたことを条件に、前記飲料を提供する飲料ディスペンサに設けられたチケット発行デバイスに、前記飲料に関するチケットを発行させる手順と、
    を含み、
    前記許可する手順は、顧客毎の管理データとして顧客に対する飲料の過去の提供に関するデータを記憶する記憶デバイスが記憶する前記要求顧客の前記管理データに基づき、前記要求顧客に対する前記飲料の提供を許可するか否かを判定する手順を含み、
    前記発行させる手順は、前記飲料に関するチケットとして、前記飲料ディスペンサから提供される前記飲料を収納するための容器を受け取る権利が化体されたチケットを前記チケット発行デバイスに発行させる手順を含む飲料の提供制御方法。
22. コンピュータにより実行される方法であって、
    販売時点情報管理機能を有する店舗端末に設けられた入力ユニットから入力される、顧客の識別情報に基づき、飲料を要求する顧客である要求顧客を識別する手順と、
    前記識別する手順により識別された前記要求顧客に対する前記飲料の提供を許可する手順と、
    を含み、前記許可する手順は、顧客毎の管理データとして顧客に対する飲料の過去の提供に関するデータを記憶する記憶デバイスが記憶する前記要求顧客の前記管理データに基づき、前記要求顧客に対する前記飲料の提供を許可するか否かを判定する手順を含む飲料の提供制御方法。
23. 飲料を提供する飲料ディスペンサと通信可能なサーバ装置のコンピュータにより実行される方法であって、
    前記飲料ディスペンサに設けられた入力ユニットから入力される顧客の識別情報に基づき、前記飲料を要求する顧客である要求顧客を識別する手順と、
    前記識別する手順により識別された前記要求顧客に対する前記飲料の提供を許可する手順と、
    を含み、前記許可する手順は、顧客毎の管理データとして顧客に対する飲料の過去の提供に関するデータを記憶する記憶デバイスが記憶する前記要求顧客の前記管理データに基づき、前記要求顧客に対する前記飲料の提供を許可するか否かを判定し、許可すると判定したことを条件に、前記飲料ディスペンサに対し、前記飲料の提供を許可する許可信号を送信する手順を含む飲料の提供制御方法。
24. 請求項１９〜請求項２３のいずれか一項記載の飲料の提供制御方法を、コンピュータに実行させるためのプログラム。

Images