説明

セルフ注文管理システム

【課題】 ユーザがもつ携帯電話を用いたセルフ注文管理システムを提供する。
【解決手段】 予約受付サーバ1は、携帯電話2より予約を受け付け、予約IDとメニューとアプリケーションソフトウェアとを携帯電話2へ送信する。携帯電話2は、受信した予約IDとメニューとアプリケーションソフトウェアとを用いて注文を入力しFeliCa通信機能を用いて注文の送信を行う。非接触ICメディアリーダライタ3は各店舗に複数設置してあり携帯電話2からの注文内容を受信し注文管理サーバ4に送信する。注文管理サーバ4は各店舗に設置されているものであり携帯電話2からの注文を複数の非接触ICメディアリーダライタ3を通じて受信する。また、注文管理サーバ4は携帯電話2へ注文の確認や会計情報などをeメールを介して送信する。インターネット網または無線電話網などの通信網5は予約受付サーバ1、携帯電話2と注文管理サーバ4を互いに接続する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、レストラン、居酒屋などの飲食店で注文品の注文に用いる注文管理システム、なかでも特に、客が注文入力装置を操作して注文入力するセルフ注文管理システムに関する。
【背景技術】
【0002】
従来、レストランや居酒屋においては、店員がメニューを持って客席へ行き、顧客から注文を受けていた。この際、顧客はメニューを見ながら注文を行い、店員は所持している入力端末から料理の名称または料理のコードなどと、その数量などを入力していた。そして、この入力端末より厨房に指示が出され、厨房にて料理が調理され、調理された料理が店員により顧客に提供されていた。更に、追加の注文がある毎に、店員が顧客のもとに呼び出され、顧客の注文を店員が入力していた。
また、注文または追加の注文に関するレシートが印刷され、顧客に渡されていた。その後、食事が終わると、顧客は会計場所に行き、印刷され渡されていたレシートを持って行くことにより、会計が行われていた。
【0003】
このように従来の店員が入力端末を使用して入力する方式では、店員が顧客の注文が終わるまで顧客の客席近くに待機していなければならず、また、顧客も注文する時において、店員が近くにいなければ注文ができなかった。また、追加注文を行う場合には、再度、顧客は店員を呼び出す必要があり、店員も顧客の注文のために顧客の近くに待機していなくてはならなかった。そのため、入力端末を顧客が自分自身で操作する案が考えられてきた。
【0004】
例えば、ハンディターミナル型の注文入力端末を顧客に渡して注文を入力することは行われていた(例えば、特許文献1参照)。これは、レストラン等において、レストラン等の店舗が、顧客に入力端末であるハンディターミナルを貸し出し、顧客はこの端末より注文の追加や、決算を行うことができるものである。
【0005】
しかし、このような機器を貸し出した場合、店舗は複数のハンディターミナルを用意する必要あり、そのための設備投資が必要になる問題がある。また、顧客はその場で貸し出されたハンディターミナルを用いるため、その操作に不慣れであるため、入力できないことや入力を間違える問題などがある。
【0006】
また、特許文献1に示すハンディターミナル装置を用いた注文では、宴会コースの種類による誤操作や誤注文が発生するという問題があった。これは、ハンディターミナル装置に表示されるメニューが煩雑であり、顧客が容易に選択することが難しいことによる。
【0007】
また例えば、特許文献1に示すハンディターミナルのメニューの表示において、注文可能な商品は濃く表示され、注文不可能な商品は薄く表示されるものであるが、これは顧客毎のコースなどを反映したものではない。そのため、顧客はコースを選択したのに、コースに含まれている料理を注文してしまうことや、逆に、コースに含まれない料理を注文してしまうことなど、メニューによる注文を間違える問題もある。
【0008】
コースを反映したメニューにより顧客が自分で入力する注文入力装置については、例えば特許文献2がある。特許文献2によれば、注文入力装置には、顧客のコースなどに応じたメニューが反映される。しかしながら、特許文献2においても、専用の注文端末が必要であるため、店舗の設備投資の問題や、ユーザの端末操作の不慣れなどの問題がある。
【0009】
特許文献1や特許文献2などのいずれの入力端末を用いるにせよ、顧客は当日貸し出されたハンディターミナルを用いることにより、不慣れな操作のため誤操作や誤注文もなされる問題もあった。
また、店側がハンディターミナルを用意する必要があること。顧客に貸すハンディターミナルの盗難やメンテナンスなど管理上の問題もあった。
【特許文献1】特開平06−052193号公報
【特許文献2】特開2004−164210号公報
【発明の開示】
【発明が解決しようとする課題】
【0010】
本発明は、このような事情に鑑みてなされたもので、その目的は、ユーザがもつ携帯電話を用いたセルフ注文管理システムを提供することにある。
【課題を解決するための手段】
【0011】
この発明は上述した課題を解決するためになされたものであり、第1の発明は、携帯電話用の注文を行うためのIDとメニューとアプリケーションソフトウェアを携帯電話に送信する予約受付サーバと、前記予約受付サーバより注文を行うためのIDとメニューとアプリケーションソフトウェアを受信し自身の記憶手段内に格納し、前記格納されたメニューとアプリケーションソフトウェアを用いてユーザによって入力された注文内容と前記IDとを短距離無線通信により送信する、携帯電話と、前記短距離無線送信された注文内容とIDとを受信し、前記受信した注文内容とIDに基づいて調理の指示を厨房へ出力する、注文管理サーバと、を有することを特徴とするセルフ注文管理システムである(第1の構成)。
【0012】
第1の構成において、前記予約受付サーバは、更に、前記携帯電話より予約を受け付け、前記予約を識別するための前記IDを生成すると共に受信した予約の内容に応じて前記メニューを生成し、前記生成したIDとメニューと予め内部に保持しているアプリケーションソフトウェアを、携帯電話網を通じて、前記携帯電話へ送信する、ことを特徴とする(第2の構成)。
【0013】
第2の構成によれば、顧客の携帯電話には、顧客が予約を行った内容に応じたメニューのみが表示し入力されるので、複数のメニューが表示され注文したいメニューを選択することに戸惑うことや、間違った注文を行うことが解消される。
【0014】
第2の構成おいて、前記予約受付サーバは、更に、前記生成したIDとメニューと予め内部に保持していたアプリケーションソフトウェアを、通信網を介して前記注文管理サーバへ送信し、前記注文管理サーバは、更に、前記予約受付サーバより送信されてきたIDとメニューとアプリケーションソフトウェアを受信し、前記注文管理サーバ内の記憶手段内に保持し、前記携帯電話からの要求に応じて前記保持したIDとメニューとアプリケーションソフトウェアを前記携帯電話へ短距離無通信により送信する、ことを特徴とする(第3の構成)。
【0015】
第3の構成によれば、顧客の携帯電話には、顧客が予約を行った内容に応じたメニューのみが表示し入力されるので、複数のメニューが表示され注文したいメニューを選択することに戸惑うことや、間違った注文を行うことが解消される。
【0016】
第1から第3の構成おいて、前記注文管理サーバは、更に、前記受信した注文内容を確認し、前記確認に応じた応答を、電子メールとして前記携帯電話へ送信する、ことを特徴とする(第4の構成)。
【0017】
第4の構成によれば、顧客は携帯電話を行った注文が正しく注文されたことが確認でき、また、会計情報などを確認することが可能となる。
【0018】
第1から第4の構成において、 前記注文管理サーバは、更に、前記受信した注文内容を確認し、確認に応じた応答を、短距離無線送信により前記携帯電話へ送信し、前記携帯電話が更に、前記注文管理サーバから短距離無線通信により送信されてきた応答を受信し、前記受信した応答の内容を表示する、ことを特徴とする(第5の構成)。
【0019】
第5の構成によれば、顧客は携帯電話を行った注文が正しく注文されたことが確認でき、また、会計情報などを確認することが可能となる。
【0020】
第1から第5の構成において、前記予約受付サーバは、更に、前記受信した予約の内容に応じて、前記携帯電話とは異なる第二の携帯電話用の第二のメニューを生成し、前記生成したIDと第二のメニューと予め内部に保持しているアプリケーションソフトウェアを、前記第二の携帯電話へ、携帯電話網を介して送信し、前記第二の携帯電話が、前記予約受付サーバより送信された注文を行うためのIDと第二のメニューとアプリケーションソフトウェアを受信し自身の格納手段内に格納し、前記格納した第二のメニューとアプリケーションソフトウェアを用いてユーザにより入力された第二の注文内容と前記IDとを短距離無線通信により送信する、ことを特徴とする(第6の構成)。
【0021】
第6の構成によれば、予約を行った顧客だけでなく、顧客と同伴するメンバも自身の携帯電話により注文を行うことが可能となる。また、顧客とメンバは異なるメニューにすることも可能である。
【0022】
第1から第6の構成において、前記予約受付サーバは、更に、複数のアプリケーションソフトウェアを予め自身の記憶手段内に保持しており、前記携帯電話または前記第二の携帯電話の機種に応じて、前記複数のアプリケーションソフトウェアより前記送信するアプリケーションソフトウェアを選択する、ことを特徴とする(第7の構成)。
【0023】
第7の構成によれば、顧客の携帯電話の機種、または顧客と同伴するメンバの携帯電話の機種がいずれの機種であっても、機種に応じたアプリケーションソフトウェアが携帯電話に送信されるため、顧客の携帯電話に依存しないセルフ注文管理システムが提供される。
【0024】
携帯電話より予約を受け付ける受付手段と、前記予約を識別するための前記IDを生成すると共に受信した予約の内容に応じてメニューを生成する生成手段と、前記生成したIDとメニューと予め内部に保持しているアプリケーションソフトウェアを、携帯電話網を通じて、前記携帯電話へ送信する送信手段と、を有することを特徴とする。
【0025】
携帯電話より短距離無線送信により注文内容とIDとを受信する短距離無線受信手段と、前記受信した注文内容とIDに基づいて調理の指示を厨房へ出力する指示出力手段と、を有することを特徴とする。
【0026】
コンピュータに、携帯電話より予約を受け付ける手順と、前記予約を識別するための前記IDを生成すると共に受信した予約の内容に応じてメニューを生成する手順と、前記生成したIDとメニューと予め内部に保持しているアプリケーションソフトウェアを、携帯電話網を通じて、前記携帯電話へ送信する手順と、を実行させる。
【0027】
コンピュータに、前記予約受付サーバより前記IDとメニューとアプリケーションソフトウェアを受信し自身の記憶手段内に格納した携帯電話から、短距離無線送信により注文内容とIDとを受信する手順と、前記受信した注文内容とIDに基づいて調理の指示を厨房へ出力する手順と、を実行させる。
【発明の効果】
【0028】
この発明によれば、顧客は自身の携帯電話を用いて注文することが可能であり、店員が近くにいなくても、使い慣れた端末を用いて注文を行うことが可能となる。また、店舗は注文を入力するための端末を用意する必要がなく、セルフ注文管理システムを導入することが可能となる。
【発明を実施するための最良の形態】
【0029】
本発明の実施の形態の説明のために、一例として、宴会を取り仕切る幹事自らが、店舗の選択や料理などのコースの選択などを行い宴会の予約を完了し、宴会当日には更に追加注文などを行うことを例として説明を行う。
幹事は、まず、宴会の予約として、複数の店舗を有するチェーン店のPC(パーソナルコンピュータ)用や携帯電話用のホームページから店舗を選び出し、予約コースや人数などを選択し予約を行う。予約コースには複数の料理が登録されており、登録されている料理については、食べ放題であり、宴会当日、コースの中より自由に追加注文を行うことが可能である。以上のような宴会とコースを想定して、説明を行う。
【0030】
以下、図面を参照して、本発明の実施の形態について説明する。
図1は、この発明の一実施の形態によるセルフ注文システムの構成を示すブロック図である。1は、居酒屋などの複数の店舗を有するチェーン店において1つある予約受付サーバであり、顧客から全チェーン店に対する予約を受け付ける。また予約を行った顧客の携帯電話2にアプリケーションソフトウェアなどを送信する。ここで携帯電話とは無線通信を利用した、持ち歩ける電話機のことをいう。このアプリケーションソフトウェアは、宴会当日に携帯電話2を用いて注文ができるようにするためのものである。
【0031】
2は、予約を行う幹事の携帯電話である。幹事は宴会当日において携帯電話2を用いて店舗に注文を行う。携帯電話2は、予約受付サーバ1よりダウンロードしたアプリケーションソフトウェアなどを用いて、幹事からの注文の登録や注文内容の送信を行う。従って、携帯電話2は、アプリケーションソフトウェアを実行できる必要がある。
また、実施の形態において、後述の非接触ICメディアリーダライタ3を用いているため、携帯電話2は短距離無線通信が可能となるFeliCa機能を内蔵していることが必要である。
【0032】
3は非接触ICメディアリーダライタであり、FeliCaによる通信機能を内蔵する携帯電話などと非接触型の短距離無線による双方向通信を行う機能を有している。例えばFeliCa(登録商標)リーダライタ(R/W)などである。非接触ICメディアリーダライタ3は、店舗の出入り口で会計や受付を行う場所や各座席や各部屋などに設置されている。
また、非接触ICメディアリーダライタ3は、携帯電話2からの注文内容を受信し、店舗に設置してある注文管理サーバ4に送信する。また、注文管理サーバ4からの情報を携帯電話2に送信する。これにより、予約を行っている顧客であることの確認や識別、また、注文を受け付けることができる。
また、1つの店舗には複数の非接触ICメディアリーダライタ3があるため、各非接触ICメディアリーダライタ3には、注文管理サーバ4より各々の非接触ICメディアリーダライタ3が識別される識別コードが付与されていてもよい。このような識別コードがあることにより、後述の顧客の携帯電話2による予約IDだけでなく、非接触ICメディアリーダライタ3の識別コードにもより、どの顧客または座席から注文がなされたのかの識別や確認が可能となる。
【0033】
4は注文管理サーバであり、通常1つの店舗に1つ設置されているものであり、顧客からの携帯電話2を用いた注文を店舗内にある複数の非接触ICメディアリーダライタ3を通じて受信する。また、注文管理サーバ4は、携帯電話2へ、注文の確認や会計情報などをeメールまたは非接触ICメディアリーダライタ3を通じて送信する。また、注文された注文内容を、調理場などに調理指示として提示する。また、注文管理サーバ4は、予約受付サーバ1より、通信網5を通じて、顧客からの予約により発生した情報を受信する。
【0034】
5は、インターネット網または無線電話網などの通信網であり、携帯電話2と予約受付サーバ1と注文管理サーバ4とを有線または無線により互いに接続する。
【0035】
次に図2を用いて、図1に示した実施の形態における、予約において用いられる一例としての手順を示すシーケンスを説明する。
まず、幹事は宴会の予約を行うために、自身の携帯電話等2により、予約受付サーバ1にアクセスする(ステップS21)。
予約受付サーバ1は、アクセスしてきた顧客または顧客の予約を識別するための予約IDを作成する。この予約IDは予約受付サーバ1と幹事の携帯電話2で、また、後述する注文管理サーバ4とメンバの携帯電話においても共有されるものであり、注文などを行う幹事の携帯電話2またはメンバの携帯電話が、どの宴会の予約に関するものであるかを、予約受付サーバ1または注文管理サーバ4が識別するために用いられるものである。
予約受付サーバ1は、以降、この予約IDを用いて顧客である幹事の携帯電話2を識別する。次に、予約受付サーバ1は幹事の携帯電話2に、宴会内容の選択や、幹事が持つ携帯電話2に関わる情報、例えばeメールアドレスや電話番号などを入力するための案内を送る(ステップS22)。
【0036】
幹事は、送られてきた案内より、費用、コース、人数、店舗、飲み放題の有無、予約を要する特別な料理の注文などの宴会の予約内容を検討・決定し入力する。また幹事は、自身が持つ携帯電話のeメールアドレスや電話番号などを入力する。入力が完了すると、幹事は、自身の携帯電話等2により、入力した情報を予約受付サーバ1に送信する(ステップS23)。
【0037】
次に、予約受付サーバ1は、入力された予約内容に応じたメニューを選択する。また予約受付サーバ1は、幹事の携帯電話2に応じた携帯電話用のアプリケーションソフトウェアを選択する。このアプリケーションソフトウェアは、宴会当日に幹事の携帯電話2で実行され、予約に応じて選択されたメニューを表示し、幹事からの注文の入力を受け付け、入力された注文の送信を行うために用いられるものである。
例えば、顧客の携帯電話2が、iモードに対応するものであれば、iアプリによるアプリケーションソフトウェアを選択する。選択されたメニューとアプリケーションソフトウェアと幹事により入力された情報は、先に作成した予約IDまたは幹事が入力した情報などと関連づけて予約受付サーバ1に保存する。
次に予約受付サーバ1は、携帯電話2へ、先に保存した予約IDと選択されたメニューとアプリケーションソフトウェアとをダウンロードするための案内を送信する。また、同時に、クーポンや割引券などに関する情報も携帯電話へ送信する。(ステップS24)
【0038】
次に、幹事は自身の携帯電話2にて、送信されてきた案内より、予約IDやメニューとアプリケーションソフトウェアを携帯電話にダウンロードする。ダウンロードが完了すると、携帯電話2は、携帯電話2へのダウンロードが正常に行われたことを示す応答をサーバに返す(ステップS25)。
予約受付サーバ1は応答を受けることにより、予約受付を完了する。
【0039】
上記説明においては、予約受付サーバ1が、入力された予約内容に応じたメニューを選択するとしたが、これはコースなどによって予め決められたものを選択されたメニューでもよいし、顧客の予約内容に応じて細かく設定され、設定を反映したメニューでもよい。
【0040】
例えば、ユーザの予約内容に応じて異なるメニューとして、ユーザが設定した飲み放題の内容がビール、ウイスキー、ウーロン茶が飲み放題である場合には、注文の時に用いるアプリケーションソフトウェアではワインが表示されないようにすることも可能である。また例えば、特定の素材を設定することにより、文化の違いのため牛肉を食べることができない場合には、牛肉を用いた料理は表示されなくすることも可能である。また、コースである場合には、コースの順番を指定することや、提供するタイミングを指定することも可能である。
このような様々なユーザ毎に異なる注文や要求に応じて、ユーザに対するメニューの作成を行う。
【0041】
以下に、図3を用いて、予約内容を反映したメニューの作成方法の一例を示す。
店舗はチェーン店であり、X店舗、Y店舗とZ店舗の3店舗があり、それぞれの店舗にはコースA、コースBとコースCの料理のコースがあるとする。店舗毎に提供される料理やコースは異なるものとする。
例えば図3のメニューテーブルT1においては、料理1に対しては、店舗X、Y、Zの全店で提供可能であるが、料理3については店舗YとZでのみ提供可能であり、店舗Xでは提供されていない。またコースによっても、料理1はコースA、BとCいずれでも提供されるが、料理3についてはコースBとCでしか提供されず、コースAでは提供されない。
また、人数によっても制限があり、例えばコース5は4名以上の人数でないと注文できない。また、料理の素材に関する情報もあり、例えば牛肉の使用についての有無があるとする。
【0042】
以上のようなメニューテーブルT1がある場合に、幹事が予約内容として「店舗X、コースB、3名、牛肉可能」という予約の条件R1を行うとする。すると、先のメニューテーブルT1より、料理3は店舗Xで提供されていない。料理5は4名以上であるため、予約が3名であることより提供されない。料理6と7は、コースBには含まれない。ということより、この予約の条件R1にて予約を行った幹事に対して提供可能な料理は、料理1、料理2と料理4であることになる。従って、この予約を行った幹事に対する注文可能なメニューM1は「料理1、料理2と料理4」となる。
【0043】
顧客毎の注文可能なメニューM1としては、更に飲み物などにもついて同様にメニューを作成することも可能である。また、肉料理、魚料理、サラダなど、カテゴリ別に作成することも可能である。また、顧客である幹事毎のメニューは、メニューテーブルT1のような1つのテーブルから作成するだけではなく、リレーショナルデータベースを用いて作成することも可能である。
【0044】
以上に一例としての幹事からの予約内容を反映したメニューの作成方法を示したが、メニューの作成方法はこのようなメニューテーブルを用いる方法でもよいし、他の方法で作成するものであっても構わない。顧客とその予約内容に応じて、顧客毎のメニューが選択または作成されるという点が重要な点である。一例としてのコース毎のメニューの作成方法については、特開2004−164210号公報にも詳細に記載されている。
【0045】
以上の予約処理により、幹事の携帯電話2には、予約を識別する予約IDと、宴会の予約内容を反映したメニューと、そのメニューを表示し注文の入力を行う携帯電話2用のアプリケーションソフトウェアが組み込まれる。
ここで重要な点は、顧客毎に予約された予約内容に応じて顧客毎のメニューが顧客の携帯電話に組み込まれている、という点である。
【0046】
また予約により、予約受付サーバ1には、宴会の予約内容と予約IDが記録されている。また、顧客の電話番号やeメールアドレスなども記録される。
また、上記例においては、顧客は店舗Xに予約を行ったので、予約受付サーバ1は、店舗Xにおける注文管理サーバ4にも、顧客の予約により発生した情報を送る。
【0047】
次に、宴会当日、幹事は携帯電話2を用い、予約を確認し宴会が開始され、追加の注文などを行う。この時に用いられる、予約の確認や注文のシーケンスを、図4を用いて説明する。
まず、幹事の携帯電話2には予約の段階で、予約IDと予約内容を反映したメニューとアプリケーションソフトウェアが内蔵されている。そのような携帯電話2を、店舗の出入り口で会計や受付を行う場所にある非接触ICメディアリーダライタ3と非接触的に短距離無線通信することにより、予約IDを送信する(ステップS51)。
【0048】
注文管理サーバ4は、送信されてきた予約IDより、予約を確認し、予約がされている場合には携帯電話2に宴会開始の応答を返す(ステップS52)。また、予約がされていることを店員にも示し、宴会開始の指示を受けた店員は、幹事達を座席等に通す。
【0049】
その後、予約していたコースにより料理等が運ばれるが、幹事が追加注文を行う場合、幹事はメニューとアプリケーションソフトウェアが組み込まれた自身の携帯電話2を用いて注文を入力する。次に、幹事は携帯電話2を、自分たちの座席の近くにある非接触ICメディアリーダライタ3に近づけ、非接触ICメディアリーダライタ3と非接触的に短距離無線通信することにより、入力した注文内容と予約IDを注文管理サーバ4に送信する。以上のようにして、幹事からの追加の注文の度毎に、注文内容と予約IDが注文管理サーバ4に送信される(ステップS53、S54、S55)。
【0050】
注文管理サーバ4は、送信されてきた注文内容と予約IDより、コースの設定条件などと照合して問題なければ注文を受理し、店員に注文を受理したことの報告を行うことや、調理場の調理を行う人に調理指示を出す。また、注文の受理においては、非接触ICメディアリーダライタ3の識別コードを用いて識別や確認を行うことも可能である。
注文管理サーバ4は、注文を受理すると、注文受理と会計情報、またはこれから出される料理などの情報を幹事の携帯電話2へ、通信網5を介してeメールとして送信する(ステップS56)。幹事は送信されてきた情報により、注文が受理されたことの確認や、現在の会計情報、これから運ばれてくる料理の情報などを随時確認することができる。
【0051】
宴会終了時には、幹事は携帯電話2より宴会の終了を送信する(ステップS57)。その後、注文管理サーバ4により会計処理が行われる。
【0052】
以上のように、携帯電話2に予約IDと予約内容を反映したメニューとアプリケーションソフトウェアが内蔵されていることにより、幹事は自身が有する携帯電話2を用いて注文が可能となる。また、予約内容に応じた幹事のためのメニューにより、容易にメニューの選択が可能となる。
【0053】
なお、上記説明において、注文管理サーバ4は、携帯電話2より送信されてきた注文内容に応じて、通信網4を介してeメールとして携帯電話2へ応答の送信(ステップS56)を行ったが、応答の送信は通信網4を介したeメールに限られるものではなく、非接触ICメディアリーダライタ3を介して送信されるものでもよい。
また、注文に対する応答だけでなく、他にも、注文された料理の材料の在庫などにより、在庫切れで料理を提供不可能な場合には、注文された料理に対して、提供不可能なことを返信してもよい。また、宴会コースに時間制限がある場合などには、制限時間の1時間前、30分前、10分前などに、残りの時間を通知してもよい。
【0054】
なお、会計の計算などの処理は注文管理サーバ4または携帯電話2によってなされてもよく、支払いが携帯電話2より非接触ICメディアリーダライタ3を用いて行うことも可能である。
【0055】
上記実施の形態としては、予約時に、予約受付サーバ1より、通信網4を介して、予約IDやメニューやアプリケーションソフトウェアを携帯電話2へダウンロードし、携帯電話2に組み込んでいた。
この別の実施の形態として、予約時には予約IDと予約IDに応じたメニューとアプリケーションソフトウェアをダウンロードすることが可能なアプリケーションソフトウェアのみを携帯電話2にダウンロードし保存しておき、宴会当日、店舗の出入り口で会計や受付を行う場所にある非接触ICメディアリーダライタ3を通じて携帯電話2に保存していたダウンロード用のアプリケーションソフトウェアを用いて予約IDを注文管理サーバ4へ送信し、注文管理サーバ4にある予約メニューと注文のためのアプリケーションソフトウェアを非接触ICメディアリーダライタ3を通じて携帯電話2にダウンロードし保存することも可能である。
【0056】
この時、予約受付サーバ1で受け付けた情報は、宴会当日前までに注文管理サーバ4にも反映されており、注文管理サーバ4には、予約IDと関連付けてメニューやアプリケーションソフトウェアが保存されている。注文管理サーバ4は、宴会当日、携帯電話2からの予約IDを非接触ICメディアリーダライタ3より受信し確認し、その予約IDに対応するメニューやアプリケーションソフトウェアを非接触ICメディアリーダライタ3を通じて携帯電話2に送信する。
【0057】
または、注文管理サーバ4は、予約IDと関連付けてメニューやアプリケーションソフトウェアを、予め予約受付サーバ1より受信し保存しておくのではなく、携帯電話2より非接触ICメディアリーダライタ3を通じて予約IDを受信し、その予約IDに関連するメニューやアプリケーションソフトウェアのダウンロードを要求された時に、予約受付サーバ1より予約IDと関連付けられたメニューやアプリケーションソフトウェアをダウンロードし、携帯電話2へ非接触ICメディアリーダライタ3を通じて携帯電話2へ送信してもよい。
【0058】
または、予約時には、予約受付サーバ1または予約受付サーバ1は、幹事の携帯電話の電話番号と関連して、予約IDやメニューやアプリケーションソフトウェアを作成し保存しておき、携帯電話2には何も保存せず、宴会当日、幹事が店舗で受付を行うとき、幹事が口頭で電話番号を通知することにより店員が予約受付サーバ1を用いて予約確認を行い、電話番号により識別された予約IDやメニューやアプリケーションソフトウェアを、非接触ICメディアリーダライタ3を通じて携帯電話2にダウンロードし保存するようにしてもよい。
【0059】
また、幹事は自身の携帯電話2を用いて予約受付サーバ1に対して予約を行ったが、幹事が有するパーソナルコンピュータ(PC)や、他の携帯電話により予約を行ってもよい。
例えば、この場合、予約の入力の段階で宴会当日用いる注文に用いる携帯電話のeメールアドレスを入力し予約受付サーバ1へ送信する(図2のステップ23)。予約受付サーバ1は受信したeメールアドレスへ注文のために必要な「予約IDとメニューとアプリケーションソフトウェア」がダウンロードできる場所(アドレス)をeメールとして送信する(図2のステップ24に相当)。次に、注文に用いる携帯電話は、eメールとして受信したアドレスより「予約IDとメニューとアプリケーションソフトウェア」をダウンロードし、正常にダウンロードが完了すると応答を返す(図2のステップ25に相当)。予約受付サーバ1は、応答を受信したことにより、予約の受付を完了する。
以上のように、携帯電話2を用いず、PCを用いた予約も可能である。
【0060】
以上のように、幹事の携帯電話2に予約IDとメニューやアプリケーションソフトウェアが組み込まれるタイミングは、予約してから宴会が開始されるまでの、任意のタイミングでダウンロードされ保存されてもよく、その方法は上記のように様々な方法が可能である。
【0061】
これまでの説明においては、幹事のみが、幹事が有する携帯電話2を用いて注文を行うことが可能であったが、宴会に参加する幹事以外の他のメンバも、メンバが有するそれぞれの携帯電話を用いて注文をするようにすることも可能である。また、幹事とメンバでは、そのメニューの内容が異なるように構成することも可能である。
【0062】
幹事とメンバで異なるメニューの作成方法の一例を、図5を用いて説明する。図5のメニューテーブルT2においては、図3で用いたメニューテーブルT1に「注文可能者」という項目が追加されている。注文可能者項目には、幹事、メンバがあり、例えば「料理1」は「幹事とメンバ」の両者が注文することが可能であり、「料理4」は「幹事」のみしか注文することが出来ない、とする。
【0063】
このようなメニューテーブルT2に対して、幹事が予約内容として「店舗X、コースB、3名、牛肉可能」という予約の条件R1を設定する。すると、幹事が注文可能なメニューとしてメニューM1が作成され、メンバが注文可能なメニューとしてメニューM2が作成される。幹事のメニューM1には先と同様に「料理1、料理2、料理4」がある。しかし、料理4は、メニューテーブルT2の注文可能者項目より、幹事のみしか注文することができないために、メンバのメニューM2には「料理4」がなく、「料理1、料理2」のみしかない。
【0064】
以上のようにして幹事とメンバのそれぞれのメニューを作成し、幹事の携帯電話2には予約IDとメニューM1が送信されるようにし、メンバの携帯電話には予約IDとメニューM2が送信されるようにする。また、それぞれの携帯電話に応じたアプリケーションソフトウェアを送信する。
以上のようにすることにより、幹事とメンバにより、異なるメニューを作成することも可能である。また、幹事とメンバは同一のメニューを持たせることも可能である。
【0065】
幹事とメンバの携帯電話が、予約受付サーバ1または注文管理サーバ4からアプリケーションソフトウェアなどをダウンロードする方法は、先に説明したものと同様に、予約時にeメールよりダウンロード先のあて先を送信し、そのeメールに応じてダウンロードすることや、宴会当日、非接触ICメディアリーダライタ3を通じてダウンロードすることも可能である。
また、本発明のシステムは必ずしも宴会のみでなく、通常のレストランにおいて、複数人のグループで飲食を行う場合にも利用可能である。
【0066】
なお、予約受付サーバ1または注文管理サーバ4より携帯電話2へ、eメールにて送信を行うとしたが、各種携帯電話に応じたメールの送信方法を用いてメールを送信してもよい。
【0067】
また、携帯電話に組み込まれるアプリケーションソフトウェアとしては、JAVA(登録商標)を用いたiアプリや、BREWを用いたEZアプリなど、携帯電話用のアプリケーションソフトウェアのいずれでも利用可能である。
また、複数のアプリケーションソフトウェアの形式や携帯電話に対応するために、予約受付サーバ1または注文管理サーバ4は、携帯電話の種類や利用可能なアプリケーションソフトウェアの形式を識別し、識別した携帯電話に対応するアプリケーションソフトウェアを選択し、選択したアプリケーションソフトウェアを携帯電話に送信してもよい。
【0068】
また、携帯電話2からの注文管理サーバ4への注文の送信は、非接触ICメディアリーダライタ3を介して行ってきたが、非接触ICメディアリーダライタ3に限られるものではなく、Bluetooth(登録商標)などの任意の無線LANを用いることも可能である。Bluetoothを用いる場合には、非接触ICメディアリーダライタ3の代わりに、Bluetooth送受信機が店舗に設置され、携帯電話にはBluetoothの通信機能が搭載されていることが必要である。
また、携帯電話2からの注文管理サーバ4への注文の送信は、通信網4を介した携帯電話2からの注文管理サーバ4へのeメールにより送ることも可能である。
【0069】
また、予約受付サーバ1、それぞれ携帯電話に対応したアプリケーションソフトウェアがアプリケーションソフトウェアを識別するためのアプリケーションソフトウェア識別コードと関連して予め保存されており、幹事の予約時において携帯電話に応じてアプリケーションソフトウェア識別コードを選択し、予約IDと、予約に応じたメニューと、携帯電話に応じて選択されたアプリケーションソフトウェア識別コードを保存してもよい。
また予約完了後、予約受付サーバ1より注文管理サーバ4へ、予約IDと、予約に応じたメニューと、携帯電話に応じて選択されたアプリケーションソフトウェア識別コードが送信され、注文管理サーバ4で送信されてきた情報が保存されるようにしてもよい。
【0070】
また、店舗にあるメニューに各料理やドリンクに対応して携帯電話用の2次元バーコードが添付されており、携帯電話2が有するデジタルカメラにより2次元バーコードを撮影し、注文を入力するようにしてもよい。2次元バーコードにより入力された注文は、これまで説明を行ったものと同様に、注文管理サーバ4に送信される。
また、この場合撮影された2次元バーコードによるメニューが携帯電話2に登録されている予約内容に応じたメニューに該当するかどうかの判定が行われてもよい。
【0071】
なお、予約受付サーバ1より注文管理サーバ4は異なるものとして説明を行ってきたが、予約受付サーバ1と注文管理サーバ4は同一のものとして設計することも可能である。
【0072】
なお、予約受付サーバ1および注文管理サーバ4はコンピュータであってもよい。また、予約受付サーバ1および注文管理サーバ4はコンピュータであり、コンピュータの内部にプログラムを格納し、そのプログラムを実行するもの、または、そのプログラムにより制御されるものであってもよい。
【0073】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【産業上の利用可能性】
【0074】
本発明は、レストラン、居酒屋などの飲食店で注文品の注文に用いる注文管理システム、なかでも特に、客が注文入力装置を操作して注文入力するセルフ注文管理システムに用いて最適である。
【図面の簡単な説明】
【0075】
【図1】この発明の一実施形態によるセルフ注文管理システムの構成を示すブロック図である。
【図2】図1の予約に用いられる処理の流れを示す図である。
【図3】図1の予約において作成されるメニューの一例を示す図である。
【図4】図1の携帯電話2を用いて注文を行う時に用いられる処理の流れを示す図である。
【図5】図1の予約において作成されるメニューの別の一例を示す図である。
【符号の説明】
【0076】
1 予約受付予約受付サーバ
2 携帯電話
3 非接触ICメディアリーダライタ
4 注文管理サーバ
5 通信網

【特許請求の範囲】
【請求項1】
携帯電話用の注文を行うためのIDとメニューとアプリケーションソフトウェアを携帯電話に送信する予約受付サーバと、
前記予約受付サーバより注文を行うためのIDとメニューとアプリケーションソフトウェアを受信し自身の記憶手段内に格納し、
前記格納されたメニューとアプリケーションソフトウェアを用いてユーザによって入力された注文内容と前記IDとを短距離無線通信により送信する、
携帯電話と、
前記短距離無線送信された注文内容とIDとを受信し、
前記受信した注文内容とIDに基づいて調理の指示を厨房へ出力する、
注文管理サーバと、
を有することを特徴とするセルフ注文管理システム。
【請求項2】
前記予約受付サーバは、更に、
前記携帯電話より予約を受け付け、
前記予約を識別するための前記IDを生成すると共に受信した予約の内容に応じて前記メニューを生成し、
前記生成したIDとメニューと予め内部に保持しているアプリケーションソフトウェアを、携帯電話網を通じて、前記携帯電話へ送信する、
ことを特徴とする請求項1に記載のセルフ注文管理システム。
【請求項3】
前記予約受付サーバは、更に、
前記生成したIDとメニューと予め内部に保持していたアプリケーションソフトウェアを、通信網を介して前記注文管理サーバへ送信し、
前記注文管理サーバは、更に、
前記予約受付サーバより送信されてきたIDとメニューとアプリケーションソフトウェアを受信し、前記注文管理サーバ内の記憶手段内に保持し、
前記携帯電話からの要求に応じて前記保持したIDとメニューとアプリケーションソフトウェアを前記携帯電話へ短距離無通信により送信する、
ことを特徴とする請求項2に記載のセルフ注文管理システム。
【請求項4】
前記注文管理サーバは、更に、
前記受信した注文内容を確認し、
前記確認に応じた応答を、電子メールとして前記携帯電話へ送信する、
ことを特徴とする請求項1から請求項3に記載のセルフ注文管理システム。
【請求項5】
前記注文管理サーバは、更に、
前記受信した注文内容を確認し、確認に応じた応答を、短距離無線送信により前記携帯電話へ送信し、
前記携帯電話が更に、
前記注文管理サーバから短距離無線通信により送信されてきた応答を受信し、
前記受信した応答の内容を表示する、
ことを特徴とする請求項1から請求項4に記載のセルフ注文管理システム。
【請求項6】
前記予約受付サーバは、更に、
前記受信した予約の内容に応じて、前記携帯電話とは異なる第二の携帯電話用の第二のメニューを生成し、
前記生成したIDと第二のメニューと予め内部に保持しているアプリケーションソフトウェアを、前記第二の携帯電話へ、携帯電話網を介して送信し、
前記第二の携帯電話が、
前記予約受付サーバより送信された注文を行うためのIDと第二のメニューとアプリケーションソフトウェアを受信し自身の格納手段内に格納し、
前記格納した第二のメニューとアプリケーションソフトウェアを用いてユーザにより入力された第二の注文内容と前記IDとを短距離無線通信により送信する、
ことを特徴とする請求項1から請求項5に記載のセルフ注文管理システム。
【請求項7】
前記予約受付サーバは、更に、
複数のアプリケーションソフトウェアを予め自身の記憶手段内に保持しており、
前記携帯電話または前記第二の携帯電話の機種に応じて、前記複数のアプリケーションソフトウェアより前記送信するアプリケーションソフトウェアを選択する、
ことを特徴とする請求項1から請求項6に記載のセルフ注文管理システム。
【請求項8】
携帯電話より予約を受け付ける受付手段と、
前記予約を識別するための前記IDを生成すると共に受信した予約の内容に応じてメニューを生成する生成手段と、
前記生成したIDとメニューと予め内部に保持しているアプリケーションソフトウェアを、携帯電話網を通じて、前記携帯電話へ送信する送信手段と、
を有することを特徴とする予約受付サーバ。
【請求項9】
携帯電話より短距離無線送信により注文内容とIDとを受信する短距離無線受信手段と、
前記受信した注文内容とIDに基づいて調理の指示を厨房へ出力する指示出力手段と、
を有することを特徴とする注文管理サーバ。
【請求項10】
コンピュータに、
携帯電話より予約を受け付ける手順と、
前記予約を識別するための前記IDを生成すると共に受信した予約の内容に応じてメニューを生成する手順と、
前記生成したIDとメニューと予め内部に保持しているアプリケーションソフトウェアを、携帯電話網を通じて、前記携帯電話へ送信する手順と、
を実行させるためのプログラム。
【請求項11】
コンピュータに、
前記予約受付サーバより前記IDとメニューとアプリケーションソフトウェアを受信し自身の記憶手段内に格納した携帯電話から、短距離無線送信により注文内容とIDとを受信する手順と、
前記受信した注文内容とIDに基づいて調理の指示を厨房へ出力する手順と、
を実行させるためのプログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate