(57)【特許請求の範囲】
【請求項１】
携帯電話用の注文を行うためのＩＤとメニューと店舗において注文入力を実行するためのアプリケーションソフトウェアとを携帯電話へ送信する予約受付サーバと、
前記予約受付サーバより、前記ＩＤと前記メニューと前記アプリケーションソフトウェアとを受信して自身の記憶手段内に格納し、店舗において前記アプリケーションソフトウェアを用いてユーザによって入力された注文内容と前記ＩＤとを、短距離無線通信により送信する携帯電話と、
前記短距離無線通信により送信された前記注文内容と前記ＩＤとを取得し、取得した前記注文内容と前記ＩＤとに基づいて調理の指示を厨房へ出力する注文管理サーバとを含むセルフ注文管理システムであって、
前記予約受付サーバが、
前記携帯電話より、ユーザに関する情報と前記ユーザが飲食したいメニューに関する情報とを含む予約を受け付け、
前記予約を受け付けた場合、注文を行うための前記ＩＤを生成すると共に、受信した前記予約に含まれる情報に応じて、前記ユーザが注文可能な料理のみに関するメニューを生成し、
生成した前記ＩＤと生成した前記メニューと予め内部に保持している前記アプリケーションソフトウェアとを、携帯電話網を通じて前記携帯電話へ送信する
ことを特徴とするセルフ注文管理システム。
【請求項２】
前記予約受付サーバが更に、
生成した前記ＩＤと生成した前記メニューと予め内部に保持している前記アプリケーションソフトウェアとを、通信網を通じて前記注文管理サーバへ送信し、
前記注文管理サーバが更に、
前記予約受付サーバより、前記ＩＤと前記メニューと前記アプリケーションソフトウェアとを受信して、前記注文管理サーバ内の記憶手段内に保持し、
前記携帯電話からの要求に応じて、前記記憶手段内に保持した前記ＩＤと前記メニューと前記アプリケーションソフトウェアとを送信し、前記携帯電話に短距離無線通信により取得させる
ことを特徴とする請求項１に記載のセルフ注文管理システム。
【請求項３】
前記携帯電話が更に、
前記注文管理サーバから、前記携帯電話が送信した前記注文内容を受信し確認したことを示す応答を受信して、前記応答の内容を表示する
ことを特徴とする請求項１また請求項２に記載のセルフ注文管理システム。
【請求項４】
前記予約受付サーバが更に、
受信した前記予約の内容に応じて、前記携帯電話とは異なる第二の携帯電話用の第二のメニューを生成し、
生成した前記ＩＤと前記第二のメニューと予め内部に保持している前記アプリケーションソフトウェアとを、携帯電話網を通じて前記第二の携帯電話へ送信し、
前記第二の携帯電話が、
前記ＩＤと前記第二のメニューと前記アプリケーションソフトウェアとを受信して自身の記憶手段内に格納し、店舗において前記第二のメニューとアプリケーションソフトウェアとを用いてユーザにより入力された第二の注文内容と前記ＩＤとを、短距離無線通信により送信する
ことを特徴とする請求項１から請求項３のいずれかに記載のセルフ注文管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、レストラン、居酒屋などの飲食店で注文品の注文に用いる注文管理システム、なかでも特に、客が注文入力装置を操作して注文入力するセルフ注文管理システムに関する。
【背景技術】
【０００２】
従来、レストランや居酒屋においては、店員がメニューを持って客席へ行き、顧客から注文を受けていた。この際、顧客はメニューを見ながら注文を行い、店員は所持している入力端末から料理の名称または料理のコードなどと、その数量などを入力していた。そして、この入力端末より厨房に指示が出され、厨房にて料理が調理され、調理された料理が店員により顧客に提供されていた。更に、追加の注文がある毎に、店員が顧客のもとに呼び出され、顧客の注文を店員が入力していた。
また、注文または追加の注文に関するレシートが印刷され、顧客に渡されていた。その後、食事が終わると、顧客は会計場所に行き、印刷され渡されていたレシートを持って行くことにより、会計が行われていた。
【０００３】
このように従来の店員が入力端末を使用して入力する方式では、店員が顧客の注文が終わるまで顧客の客席近くに待機していなければならず、また、顧客も注文する時において、店員が近くにいなければ注文ができなかった。また、追加注文を行う場合には、再度、顧客は店員を呼び出す必要があり、店員も顧客の注文のために顧客の近くに待機していなくてはならなかった。そのため、入力端末を顧客が自分自身で操作する案が考えられてきた。
【０００４】
例えば、ハンディターミナル型の注文入力端末を顧客に渡して注文を入力することは行われていた（例えば、特許文献１参照）。これは、レストラン等において、レストラン等の店舗が、顧客に入力端末であるハンディターミナルを貸し出し、顧客はこの端末より注文の追加や、決算を行うことができるものである。
【０００５】
しかし、このような機器を貸し出した場合、店舗は複数のハンディターミナルを用意する必要あり、そのための設備投資が必要になる問題がある。また、顧客はその場で貸し出されたハンディターミナルを用いるため、その操作に不慣れであるため、入力できないことや入力を間違える問題などがある。
【０００６】
また、特許文献１に示すハンディターミナル装置を用いた注文では、宴会コースの種類による誤操作や誤注文が発生するという問題があった。これは、ハンディターミナル装置に表示されるメニューが煩雑であり、顧客が容易に選択することが難しいことによる。
【０００７】
また例えば、特許文献１に示すハンディターミナルのメニューの表示において、注文可能な商品は濃く表示され、注文不可能な商品は薄く表示されるものであるが、これは顧客毎のコースなどを反映したものではない。そのため、顧客はコースを選択したのに、コースに含まれている料理を注文してしまうことや、逆に、コースに含まれない料理を注文してしまうことなど、メニューによる注文を間違える問題もある。
【０００８】
コースを反映したメニューにより顧客が自分で入力する注文入力装置については、例えば特許文献２がある。特許文献２によれば、注文入力装置には、顧客のコースなどに応じたメニューが反映される。しかしながら、特許文献２においても、専用の注文端末が必要であるため、店舗の設備投資の問題や、ユーザの端末操作の不慣れなどの問題がある。
【０００９】
特許文献１や特許文献２などのいずれの入力端末を用いるにせよ、顧客は当日貸し出されたハンディターミナルを用いることにより、不慣れな操作のため誤操作や誤注文もなされる問題もあった。
また、店側がハンディターミナルを用意する必要があること。顧客に貸すハンディターミナルの盗難やメンテナンスなど管理上の問題もあった。
【特許文献１】特開平０６−０５２１９３号公報
【特許文献２】特開２００４−１６４２１０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明は、このような事情に鑑みてなされたもので、その目的は、ユーザがもつ携帯電話を用いたセルフ注文管理システムを提供することにある。
【課題を解決するための手段】
【００１１】
この発明は上述した課題を解決するためになされたものであり、第１の発明は、携帯電話用の注文を行うためのＩＤとメニューとアプリケーションソフトウェアを携帯電話に送信する予約受付サーバと、前記予約受付サーバより注文を行うためのＩＤとメニューとアプリケーションソフトウェアを受信し自身の記憶手段内に格納し、前記格納されたメニューとアプリケーションソフトウェアを用いてユーザによって入力された注文内容と前記ＩＤとを短距離無線通信により送信する、携帯電話と、前記短距離無線送信された注文内容とＩＤとを受信し、前記受信した注文内容とＩＤに基づいて調理の指示を厨房へ出力する、注文管理サーバと、を有することを特徴とするセルフ注文管理システムである（第１の構成）。
【００１２】
第１の構成において、前記予約受付サーバは、更に、前記携帯電話より予約を受け付け、前記予約を識別するための前記ＩＤを生成すると共に受信した予約の内容に応じて前記メニューを生成し、前記生成したＩＤとメニューと予め内部に保持しているアプリケーションソフトウェアを、携帯電話網を通じて、前記携帯電話へ送信する、ことを特徴とする（第２の構成）。
【００１３】
第２の構成によれば、顧客の携帯電話には、顧客が予約を行った内容に応じたメニューのみが表示し入力されるので、複数のメニューが表示され注文したいメニューを選択することに戸惑うことや、間違った注文を行うことが解消される。
【００１４】
第２の構成おいて、前記予約受付サーバは、更に、前記生成したＩＤとメニューと予め内部に保持していたアプリケーションソフトウェアを、通信網を介して前記注文管理サーバへ送信し、前記注文管理サーバは、更に、前記予約受付サーバより送信されてきたＩＤとメニューとアプリケーションソフトウェアを受信し、前記注文管理サーバ内の記憶手段内に保持し、前記携帯電話からの要求に応じて前記保持したＩＤとメニューとアプリケーションソフトウェアを前記携帯電話へ短距離無通信により送信する、ことを特徴とする（第３の構成）。
【００１５】
第３の構成によれば、顧客の携帯電話には、顧客が予約を行った内容に応じたメニューのみが表示し入力されるので、複数のメニューが表示され注文したいメニューを選択することに戸惑うことや、間違った注文を行うことが解消される。
【００１６】
第１から第３の構成おいて、前記注文管理サーバは、更に、前記受信した注文内容を確認し、前記確認に応じた応答を、電子メールとして前記携帯電話へ送信する、ことを特徴とする（第４の構成）。
【００１７】
第４の構成によれば、顧客は携帯電話を行った注文が正しく注文されたことが確認でき、また、会計情報などを確認することが可能となる。
【００１８】
第１から第４の構成において、  前記注文管理サーバは、更に、前記受信した注文内容を確認し、確認に応じた応答を、短距離無線送信により前記携帯電話へ送信し、前記携帯電話が更に、前記注文管理サーバから短距離無線通信により送信されてきた応答を受信し、前記受信した応答の内容を表示する、ことを特徴とする（第５の構成）。
【００１９】
第５の構成によれば、顧客は携帯電話を行った注文が正しく注文されたことが確認でき、また、会計情報などを確認することが可能となる。
【００２０】
第１から第５の構成において、前記予約受付サーバは、更に、前記受信した予約の内容に応じて、前記携帯電話とは異なる第二の携帯電話用の第二のメニューを生成し、前記生成したＩＤと第二のメニューと予め内部に保持しているアプリケーションソフトウェアを、前記第二の携帯電話へ、携帯電話網を介して送信し、前記第二の携帯電話が、前記予約受付サーバより送信された注文を行うためのＩＤと第二のメニューとアプリケーションソフトウェアを受信し自身の格納手段内に格納し、前記格納した第二のメニューとアプリケーションソフトウェアを用いてユーザにより入力された第二の注文内容と前記ＩＤとを短距離無線通信により送信する、ことを特徴とする（第６の構成）。
【００２１】
第６の構成によれば、予約を行った顧客だけでなく、顧客と同伴するメンバも自身の携帯電話により注文を行うことが可能となる。また、顧客とメンバは異なるメニューにすることも可能である。
【００２２】
第１から第６の構成において、前記予約受付サーバは、更に、複数のアプリケーションソフトウェアを予め自身の記憶手段内に保持しており、前記携帯電話または前記第二の携帯電話の機種に応じて、前記複数のアプリケーションソフトウェアより前記送信するアプリケーションソフトウェアを選択する、ことを特徴とする（第７の構成）。
【００２３】
第７の構成によれば、顧客の携帯電話の機種、または顧客と同伴するメンバの携帯電話の機種がいずれの機種であっても、機種に応じたアプリケーションソフトウェアが携帯電話に送信されるため、顧客の携帯電話に依存しないセルフ注文管理システムが提供される。
【００２４】
携帯電話より予約を受け付ける受付手段と、前記予約を識別するための前記ＩＤを生成すると共に受信した予約の内容に応じてメニューを生成する生成手段と、前記生成したＩＤとメニューと予め内部に保持しているアプリケーションソフトウェアを、携帯電話網を通じて、前記携帯電話へ送信する送信手段と、を有することを特徴とする。
【００２５】
携帯電話より短距離無線送信により注文内容とＩＤとを受信する短距離無線受信手段と、前記受信した注文内容とＩＤに基づいて調理の指示を厨房へ出力する指示出力手段と、を有することを特徴とする。
【００２６】
コンピュータに、携帯電話より予約を受け付ける手順と、前記予約を識別するための前記ＩＤを生成すると共に受信した予約の内容に応じてメニューを生成する手順と、前記生成したＩＤとメニューと予め内部に保持しているアプリケーションソフトウェアを、携帯電話網を通じて、前記携帯電話へ送信する手順と、を実行させる。
【００２７】
コンピュータに、前記予約受付サーバより前記ＩＤとメニューとアプリケーションソフトウェアを受信し自身の記憶手段内に格納した携帯電話から、短距離無線送信により注文内容とＩＤとを受信する手順と、前記受信した注文内容とＩＤに基づいて調理の指示を厨房へ出力する手順と、を実行させる。
【発明の効果】
【００２８】
この発明によれば、顧客は自身の携帯電話を用いて注文することが可能であり、店員が近くにいなくても、使い慣れた端末を用いて注文を行うことが可能となる。また、店舗は注文を入力するための端末を用意する必要がなく、セルフ注文管理システムを導入することが可能となる。
【発明を実施するための最良の形態】
【００２９】
本発明の実施の形態の説明のために、一例として、宴会を取り仕切る幹事自らが、店舗の選択や料理などのコースの選択などを行い宴会の予約を完了し、宴会当日には更に追加注文などを行うことを例として説明を行う。
幹事は、まず、宴会の予約として、複数の店舗を有するチェーン店のＰＣ（パーソナルコンピュータ）用や携帯電話用のホームページから店舗を選び出し、予約コースや人数などを選択し予約を行う。予約コースには複数の料理が登録されており、登録されている料理については、食べ放題であり、宴会当日、コースの中より自由に追加注文を行うことが可能である。以上のような宴会とコースを想定して、説明を行う。
【００３０】
以下、図面を参照して、本発明の実施の形態について説明する。
図１は、この発明の一実施の形態によるセルフ注文システムの構成を示すブロック図である。１は、居酒屋などの複数の店舗を有するチェーン店において１つある予約受付サーバであり、顧客から全チェーン店に対する予約を受け付ける。また予約を行った顧客の携帯電話２にアプリケーションソフトウェアなどを送信する。ここで携帯電話とは無線通信を利用した、持ち歩ける電話機のことをいう。このアプリケーションソフトウェアは、宴会当日に携帯電話２を用いて注文ができるようにするためのものである。
【００３１】
２は、予約を行う幹事の携帯電話である。幹事は宴会当日において携帯電話２を用いて店舗に注文を行う。携帯電話２は、予約受付サーバ１よりダウンロードしたアプリケーションソフトウェアなどを用いて、幹事からの注文の登録や注文内容の送信を行う。従って、携帯電話２は、アプリケーションソフトウェアを実行できる必要がある。
また、実施の形態において、後述の非接触ＩＣメディアリーダライタ３を用いているため、携帯電話２は短距離無線通信が可能となるＦｅｌｉＣａ機能を内蔵していることが必要である。
【００３２】
３は非接触ＩＣメディアリーダライタであり、ＦｅｌｉＣａによる通信機能を内蔵する携帯電話などと非接触型の短距離無線による双方向通信を行う機能を有している。例えばＦｅｌｉＣａ（登録商標）リーダライタ（Ｒ／Ｗ）などである。非接触ＩＣメディアリーダライタ３は、店舗の出入り口で会計や受付を行う場所や各座席や各部屋などに設置されている。
また、非接触ＩＣメディアリーダライタ３は、携帯電話２からの注文内容を受信し、店舗に設置してある注文管理サーバ４に送信する。また、注文管理サーバ４からの情報を携帯電話２に送信する。これにより、予約を行っている顧客であることの確認や識別、また、注文を受け付けることができる。
また、１つの店舗には複数の非接触ＩＣメディアリーダライタ３があるため、各非接触ＩＣメディアリーダライタ３には、注文管理サーバ４より各々の非接触ＩＣメディアリーダライタ３が識別される識別コードが付与されていてもよい。このような識別コードがあることにより、後述の顧客の携帯電話２による予約ＩＤだけでなく、非接触ＩＣメディアリーダライタ３の識別コードにもより、どの顧客または座席から注文がなされたのかの識別や確認が可能となる。
【００３３】
４は注文管理サーバであり、通常１つの店舗に１つ設置されているものであり、顧客からの携帯電話２を用いた注文を店舗内にある複数の非接触ＩＣメディアリーダライタ３を通じて受信する。また、注文管理サーバ４は、携帯電話２へ、注文の確認や会計情報などをｅメールまたは非接触ＩＣメディアリーダライタ３を通じて送信する。また、注文された注文内容を、調理場などに調理指示として提示する。また、注文管理サーバ４は、予約受付サーバ１より、通信網５を通じて、顧客からの予約により発生した情報を受信する。
【００３４】
５は、インターネット網または無線電話網などの通信網であり、携帯電話２と予約受付サーバ１と注文管理サーバ４とを有線または無線により互いに接続する。
【００３５】
次に図２を用いて、図１に示した実施の形態における、予約において用いられる一例としての手順を示すシーケンスを説明する。
まず、幹事は宴会の予約を行うために、自身の携帯電話等２により、予約受付サーバ１にアクセスする（ステップＳ２１）。
予約受付サーバ１は、アクセスしてきた顧客または顧客の予約を識別するための予約ＩＤを作成する。この予約ＩＤは予約受付サーバ１と幹事の携帯電話２で、また、後述する注文管理サーバ４とメンバの携帯電話においても共有されるものであり、注文などを行う幹事の携帯電話２またはメンバの携帯電話が、どの宴会の予約に関するものであるかを、予約受付サーバ１または注文管理サーバ４が識別するために用いられるものである。
予約受付サーバ１は、以降、この予約ＩＤを用いて顧客である幹事の携帯電話２を識別する。次に、予約受付サーバ１は幹事の携帯電話２に、宴会内容の選択や、幹事が持つ携帯電話２に関わる情報、例えばｅメールアドレスや電話番号などを入力するための案内を送る（ステップＳ２２）。
【００３６】
幹事は、送られてきた案内より、費用、コース、人数、店舗、飲み放題の有無、予約を要する特別な料理の注文などの宴会の予約内容を検討・決定し入力する。また幹事は、自身が持つ携帯電話のｅメールアドレスや電話番号などを入力する。入力が完了すると、幹事は、自身の携帯電話等２により、入力した情報を予約受付サーバ１に送信する（ステップＳ２３）。
【００３７】
次に、予約受付サーバ１は、入力された予約内容に応じたメニューを選択する。また予約受付サーバ１は、幹事の携帯電話２に応じた携帯電話用のアプリケーションソフトウェアを選択する。このアプリケーションソフトウェアは、宴会当日に幹事の携帯電話２で実行され、予約に応じて選択されたメニューを表示し、幹事からの注文の入力を受け付け、入力された注文の送信を行うために用いられるものである。
例えば、顧客の携帯電話２が、ｉモードに対応するものであれば、ｉアプリによるアプリケーションソフトウェアを選択する。選択されたメニューとアプリケーションソフトウェアと幹事により入力された情報は、先に作成した予約ＩＤまたは幹事が入力した情報などと関連づけて予約受付サーバ１に保存する。
次に予約受付サーバ１は、携帯電話２へ、先に保存した予約ＩＤと選択されたメニューとアプリケーションソフトウェアとをダウンロードするための案内を送信する。また、同時に、クーポンや割引券などに関する情報も携帯電話へ送信する。（ステップＳ２４）
【００３８】
次に、幹事は自身の携帯電話２にて、送信されてきた案内より、予約ＩＤやメニューとアプリケーションソフトウェアを携帯電話にダウンロードする。ダウンロードが完了すると、携帯電話２は、携帯電話２へのダウンロードが正常に行われたことを示す応答をサーバに返す（ステップＳ２５）。
予約受付サーバ１は応答を受けることにより、予約受付を完了する。
【００３９】
上記説明においては、予約受付サーバ１が、入力された予約内容に応じたメニューを選択するとしたが、これはコースなどによって予め決められたものを選択されたメニューでもよいし、顧客の予約内容に応じて細かく設定され、設定を反映したメニューでもよい。
【００４０】
例えば、ユーザの予約内容に応じて異なるメニューとして、ユーザが設定した飲み放題の内容がビール、ウイスキー、ウーロン茶が飲み放題である場合には、注文の時に用いるアプリケーションソフトウェアではワインが表示されないようにすることも可能である。また例えば、特定の素材を設定することにより、文化の違いのため牛肉を食べることができない場合には、牛肉を用いた料理は表示されなくすることも可能である。また、コースである場合には、コースの順番を指定することや、提供するタイミングを指定することも可能である。
このような様々なユーザ毎に異なる注文や要求に応じて、ユーザに対するメニューの作成を行う。
【００４１】
以下に、図３を用いて、予約内容を反映したメニューの作成方法の一例を示す。
店舗はチェーン店であり、Ｘ店舗、Ｙ店舗とＺ店舗の３店舗があり、それぞれの店舗にはコースＡ、コースＢとコースＣの料理のコースがあるとする。店舗毎に提供される料理やコースは異なるものとする。
例えば図３のメニューテーブルＴ１においては、料理１に対しては、店舗Ｘ、Ｙ、Ｚの全店で提供可能であるが、料理３については店舗ＹとＺでのみ提供可能であり、店舗Ｘでは提供されていない。またコースによっても、料理１はコースＡ、ＢとＣいずれでも提供されるが、料理３についてはコースＢとＣでしか提供されず、コースＡでは提供されない。
また、人数によっても制限があり、例えばコース５は４名以上の人数でないと注文できない。また、料理の素材に関する情報もあり、例えば牛肉の使用についての有無があるとする。
【００４２】
以上のようなメニューテーブルＴ１がある場合に、幹事が予約内容として「店舗Ｘ、コースＢ、３名、牛肉可能」という予約の条件Ｒ１を行うとする。すると、先のメニューテーブルＴ１より、料理３は店舗Ｘで提供されていない。料理５は４名以上であるため、予約が３名であることより提供されない。料理６と７は、コースＢには含まれない。ということより、この予約の条件Ｒ１にて予約を行った幹事に対して提供可能な料理は、料理１、料理２と料理４であることになる。従って、この予約を行った幹事に対する注文可能なメニューＭ１は「料理１、料理２と料理４」となる。
【００４３】
顧客毎の注文可能なメニューＭ１としては、更に飲み物などにもついて同様にメニューを作成することも可能である。また、肉料理、魚料理、サラダなど、カテゴリ別に作成することも可能である。また、顧客である幹事毎のメニューは、メニューテーブルＴ１のような１つのテーブルから作成するだけではなく、リレーショナルデータベースを用いて作成することも可能である。
【００４４】
以上に一例としての幹事からの予約内容を反映したメニューの作成方法を示したが、メニューの作成方法はこのようなメニューテーブルを用いる方法でもよいし、他の方法で作成するものであっても構わない。顧客とその予約内容に応じて、顧客毎のメニューが選択または作成されるという点が重要な点である。一例としてのコース毎のメニューの作成方法については、特開２００４−１６４２１０号公報にも詳細に記載されている。
【００４５】
以上の予約処理により、幹事の携帯電話２には、予約を識別する予約ＩＤと、宴会の予約内容を反映したメニューと、そのメニューを表示し注文の入力を行う携帯電話２用のアプリケーションソフトウェアが組み込まれる。
ここで重要な点は、顧客毎に予約された予約内容に応じて顧客毎のメニューが顧客の携帯電話に組み込まれている、という点である。
【００４６】
また予約により、予約受付サーバ１には、宴会の予約内容と予約ＩＤが記録されている。また、顧客の電話番号やｅメールアドレスなども記録される。
また、上記例においては、顧客は店舗Ｘに予約を行ったので、予約受付サーバ１は、店舗Ｘにおける注文管理サーバ４にも、顧客の予約により発生した情報を送る。
【００４７】
次に、宴会当日、幹事は携帯電話２を用い、予約を確認し宴会が開始され、追加の注文などを行う。この時に用いられる、予約の確認や注文のシーケンスを、図４を用いて説明する。
まず、幹事の携帯電話２には予約の段階で、予約ＩＤと予約内容を反映したメニューとアプリケーションソフトウェアが内蔵されている。そのような携帯電話２を、店舗の出入り口で会計や受付を行う場所にある非接触ＩＣメディアリーダライタ３と非接触的に短距離無線通信することにより、予約ＩＤを送信する（ステップＳ５１）。
【００４８】
注文管理サーバ４は、送信されてきた予約ＩＤより、予約を確認し、予約がされている場合には携帯電話２に宴会開始の応答を返す（ステップＳ５２）。また、予約がされていることを店員にも示し、宴会開始の指示を受けた店員は、幹事達を座席等に通す。
【００４９】
その後、予約していたコースにより料理等が運ばれるが、幹事が追加注文を行う場合、幹事はメニューとアプリケーションソフトウェアが組み込まれた自身の携帯電話２を用いて注文を入力する。次に、幹事は携帯電話２を、自分たちの座席の近くにある非接触ＩＣメディアリーダライタ３に近づけ、非接触ＩＣメディアリーダライタ３と非接触的に短距離無線通信することにより、入力した注文内容と予約ＩＤを注文管理サーバ４に送信する。以上のようにして、幹事からの追加の注文の度毎に、注文内容と予約ＩＤが注文管理サーバ４に送信される（ステップＳ５３、Ｓ５４、Ｓ５５）。
【００５０】
注文管理サーバ４は、送信されてきた注文内容と予約ＩＤより、コースの設定条件などと照合して問題なければ注文を受理し、店員に注文を受理したことの報告を行うことや、調理場の調理を行う人に調理指示を出す。また、注文の受理においては、非接触ＩＣメディアリーダライタ３の識別コードを用いて識別や確認を行うことも可能である。
注文管理サーバ４は、注文を受理すると、注文受理と会計情報、またはこれから出される料理などの情報を幹事の携帯電話２へ、通信網５を介してｅメールとして送信する（ステップＳ５６）。幹事は送信されてきた情報により、注文が受理されたことの確認や、現在の会計情報、これから運ばれてくる料理の情報などを随時確認することができる。
【００５１】
宴会終了時には、幹事は携帯電話２より宴会の終了を送信する（ステップＳ５７）。その後、注文管理サーバ４により会計処理が行われる。
【００５２】
以上のように、携帯電話２に予約ＩＤと予約内容を反映したメニューとアプリケーションソフトウェアが内蔵されていることにより、幹事は自身が有する携帯電話２を用いて注文が可能となる。また、予約内容に応じた幹事のためのメニューにより、容易にメニューの選択が可能となる。
【００５３】
なお、上記説明において、注文管理サーバ４は、携帯電話２より送信されてきた注文内容に応じて、通信網４を介してｅメールとして携帯電話２へ応答の送信（ステップＳ５６）を行ったが、応答の送信は通信網４を介したｅメールに限られるものではなく、非接触ＩＣメディアリーダライタ３を介して送信されるものでもよい。
また、注文に対する応答だけでなく、他にも、注文された料理の材料の在庫などにより、在庫切れで料理を提供不可能な場合には、注文された料理に対して、提供不可能なことを返信してもよい。また、宴会コースに時間制限がある場合などには、制限時間の１時間前、３０分前、１０分前などに、残りの時間を通知してもよい。
【００５４】
なお、会計の計算などの処理は注文管理サーバ４または携帯電話２によってなされてもよく、支払いが携帯電話２より非接触ＩＣメディアリーダライタ３を用いて行うことも可能である。
【００５５】
上記実施の形態としては、予約時に、予約受付サーバ１より、通信網４を介して、予約ＩＤやメニューやアプリケーションソフトウェアを携帯電話２へダウンロードし、携帯電話２に組み込んでいた。
この別の実施の形態として、予約時には予約ＩＤと予約ＩＤに応じたメニューとアプリケーションソフトウェアをダウンロードすることが可能なアプリケーションソフトウェアのみを携帯電話２にダウンロードし保存しておき、宴会当日、店舗の出入り口で会計や受付を行う場所にある非接触ＩＣメディアリーダライタ３を通じて携帯電話２に保存していたダウンロード用のアプリケーションソフトウェアを用いて予約ＩＤを注文管理サーバ４へ送信し、注文管理サーバ４にある予約メニューと注文のためのアプリケーションソフトウェアを非接触ＩＣメディアリーダライタ３を通じて携帯電話２にダウンロードし保存することも可能である。
【００５６】
この時、予約受付サーバ１で受け付けた情報は、宴会当日前までに注文管理サーバ４にも反映されており、注文管理サーバ４には、予約ＩＤと関連付けてメニューやアプリケーションソフトウェアが保存されている。注文管理サーバ４は、宴会当日、携帯電話２からの予約ＩＤを非接触ＩＣメディアリーダライタ３より受信し確認し、その予約ＩＤに対応するメニューやアプリケーションソフトウェアを非接触ＩＣメディアリーダライタ３を通じて携帯電話２に送信する。
【００５７】
または、注文管理サーバ４は、予約ＩＤと関連付けてメニューやアプリケーションソフトウェアを、予め予約受付サーバ１より受信し保存しておくのではなく、携帯電話２より非接触ＩＣメディアリーダライタ３を通じて予約ＩＤを受信し、その予約ＩＤに関連するメニューやアプリケーションソフトウェアのダウンロードを要求された時に、予約受付サーバ１より予約ＩＤと関連付けられたメニューやアプリケーションソフトウェアをダウンロードし、携帯電話２へ非接触ＩＣメディアリーダライタ３を通じて携帯電話２へ送信してもよい。
【００５８】
または、予約時には、予約受付サーバ１または予約受付サーバ１は、幹事の携帯電話の電話番号と関連して、予約ＩＤやメニューやアプリケーションソフトウェアを作成し保存しておき、携帯電話２には何も保存せず、宴会当日、幹事が店舗で受付を行うとき、幹事が口頭で電話番号を通知することにより店員が予約受付サーバ１を用いて予約確認を行い、電話番号により識別された予約ＩＤやメニューやアプリケーションソフトウェアを、非接触ＩＣメディアリーダライタ３を通じて携帯電話２にダウンロードし保存するようにしてもよい。
【００５９】
また、幹事は自身の携帯電話２を用いて予約受付サーバ１に対して予約を行ったが、幹事が有するパーソナルコンピュータ（ＰＣ）や、他の携帯電話により予約を行ってもよい。
例えば、この場合、予約の入力の段階で宴会当日用いる注文に用いる携帯電話のｅメールアドレスを入力し予約受付サーバ１へ送信する（図２のステップ２３）。予約受付サーバ１は受信したｅメールアドレスへ注文のために必要な「予約ＩＤとメニューとアプリケーションソフトウェア」がダウンロードできる場所（アドレス）をｅメールとして送信する（図２のステップ２４に相当）。次に、注文に用いる携帯電話は、ｅメールとして受信したアドレスより「予約ＩＤとメニューとアプリケーションソフトウェア」をダウンロードし、正常にダウンロードが完了すると応答を返す（図２のステップ２５に相当）。予約受付サーバ１は、応答を受信したことにより、予約の受付を完了する。
以上のように、携帯電話２を用いず、ＰＣを用いた予約も可能である。
【００６０】
以上のように、幹事の携帯電話２に予約ＩＤとメニューやアプリケーションソフトウェアが組み込まれるタイミングは、予約してから宴会が開始されるまでの、任意のタイミングでダウンロードされ保存されてもよく、その方法は上記のように様々な方法が可能である。
【００６１】
これまでの説明においては、幹事のみが、幹事が有する携帯電話２を用いて注文を行うことが可能であったが、宴会に参加する幹事以外の他のメンバも、メンバが有するそれぞれの携帯電話を用いて注文をするようにすることも可能である。また、幹事とメンバでは、そのメニューの内容が異なるように構成することも可能である。
【００６２】
幹事とメンバで異なるメニューの作成方法の一例を、図５を用いて説明する。図５のメニューテーブルＴ２においては、図３で用いたメニューテーブルＴ１に「注文可能者」という項目が追加されている。注文可能者項目には、幹事、メンバがあり、例えば「料理１」は「幹事とメンバ」の両者が注文することが可能であり、「料理４」は「幹事」のみしか注文することが出来ない、とする。
【００６３】
このようなメニューテーブルＴ２に対して、幹事が予約内容として「店舗Ｘ、コースＢ、３名、牛肉可能」という予約の条件Ｒ１を設定する。すると、幹事が注文可能なメニューとしてメニューＭ１が作成され、メンバが注文可能なメニューとしてメニューＭ２が作成される。幹事のメニューＭ１には先と同様に「料理１、料理２、料理４」がある。しかし、料理４は、メニューテーブルＴ２の注文可能者項目より、幹事のみしか注文することができないために、メンバのメニューＭ２には「料理４」がなく、「料理１、料理２」のみしかない。
【００６４】
以上のようにして幹事とメンバのそれぞれのメニューを作成し、幹事の携帯電話２には予約ＩＤとメニューＭ１が送信されるようにし、メンバの携帯電話には予約ＩＤとメニューＭ２が送信されるようにする。また、それぞれの携帯電話に応じたアプリケーションソフトウェアを送信する。
以上のようにすることにより、幹事とメンバにより、異なるメニューを作成することも可能である。また、幹事とメンバは同一のメニューを持たせることも可能である。
【００６５】
幹事とメンバの携帯電話が、予約受付サーバ１または注文管理サーバ４からアプリケーションソフトウェアなどをダウンロードする方法は、先に説明したものと同様に、予約時にｅメールよりダウンロード先のあて先を送信し、そのｅメールに応じてダウンロードすることや、宴会当日、非接触ＩＣメディアリーダライタ３を通じてダウンロードすることも可能である。
また、本発明のシステムは必ずしも宴会のみでなく、通常のレストランにおいて、複数人のグループで飲食を行う場合にも利用可能である。
【００６６】
なお、予約受付サーバ１または注文管理サーバ４より携帯電話２へ、ｅメールにて送信を行うとしたが、各種携帯電話に応じたメールの送信方法を用いてメールを送信してもよい。
【００６７】
また、携帯電話に組み込まれるアプリケーションソフトウェアとしては、ＪＡＶＡ（登録商標）を用いたｉアプリや、ＢＲＥＷを用いたＥＺアプリなど、携帯電話用のアプリケーションソフトウェアのいずれでも利用可能である。
また、複数のアプリケーションソフトウェアの形式や携帯電話に対応するために、予約受付サーバ１または注文管理サーバ４は、携帯電話の種類や利用可能なアプリケーションソフトウェアの形式を識別し、識別した携帯電話に対応するアプリケーションソフトウェアを選択し、選択したアプリケーションソフトウェアを携帯電話に送信してもよい。
【００６８】
また、携帯電話２からの注文管理サーバ４への注文の送信は、非接触ＩＣメディアリーダライタ３を介して行ってきたが、非接触ＩＣメディアリーダライタ３に限られるものではなく、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの任意の無線ＬＡＮを用いることも可能である。Ｂｌｕｅｔｏｏｔｈを用いる場合には、非接触ＩＣメディアリーダライタ３の代わりに、Ｂｌｕｅｔｏｏｔｈ送受信機が店舗に設置され、携帯電話にはＢｌｕｅｔｏｏｔｈの通信機能が搭載されていることが必要である。
また、携帯電話２からの注文管理サーバ４への注文の送信は、通信網４を介した携帯電話２からの注文管理サーバ４へのｅメールにより送ることも可能である。
【００６９】
また、予約受付サーバ１、それぞれ携帯電話に対応したアプリケーションソフトウェアがアプリケーションソフトウェアを識別するためのアプリケーションソフトウェア識別コードと関連して予め保存されており、幹事の予約時において携帯電話に応じてアプリケーションソフトウェア識別コードを選択し、予約ＩＤと、予約に応じたメニューと、携帯電話に応じて選択されたアプリケーションソフトウェア識別コードを保存してもよい。
また予約完了後、予約受付サーバ１より注文管理サーバ４へ、予約ＩＤと、予約に応じたメニューと、携帯電話に応じて選択されたアプリケーションソフトウェア識別コードが送信され、注文管理サーバ４で送信されてきた情報が保存されるようにしてもよい。
【００７０】
また、店舗にあるメニューに各料理やドリンクに対応して携帯電話用の２次元バーコードが添付されており、携帯電話２が有するデジタルカメラにより２次元バーコードを撮影し、注文を入力するようにしてもよい。２次元バーコードにより入力された注文は、これまで説明を行ったものと同様に、注文管理サーバ４に送信される。
また、この場合撮影された２次元バーコードによるメニューが携帯電話２に登録されている予約内容に応じたメニューに該当するかどうかの判定が行われてもよい。
【００７１】
なお、予約受付サーバ１より注文管理サーバ４は異なるものとして説明を行ってきたが、予約受付サーバ１と注文管理サーバ４は同一のものとして設計することも可能である。
【００７２】
なお、予約受付サーバ１および注文管理サーバ４はコンピュータであってもよい。また、予約受付サーバ１および注文管理サーバ４はコンピュータであり、コンピュータの内部にプログラムを格納し、そのプログラムを実行するもの、または、そのプログラムにより制御されるものであってもよい。
【００７３】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【産業上の利用可能性】
【００７４】
本発明は、レストラン、居酒屋などの飲食店で注文品の注文に用いる注文管理システム、なかでも特に、客が注文入力装置を操作して注文入力するセルフ注文管理システムに用いて最適である。
【図面の簡単な説明】
【００７５】
【図１】この発明の一実施形態によるセルフ注文管理システムの構成を示すブロック図である。
【図２】図１の予約に用いられる処理の流れを示す図である。
【図３】図１の予約において作成されるメニューの一例を示す図である。
【図４】図１の携帯電話２を用いて注文を行う時に用いられる処理の流れを示す図である。
【図５】図１の予約において作成されるメニューの別の一例を示す図である。
【符号の説明】
【００７６】
１  予約受付予約受付サーバ
２  携帯電話
３  非接触ＩＣメディアリーダライタ
４  注文管理サーバ
５  通信網
【図１】
0004732912.tif 000002
【図２】
0004732912.tif 000003
【図３】
0004732912.tif 000004
【図４】
0004732912.tif 000005
【図５】
0004732912.tif 000006