JP2017045263A - 注文管理サーバ、注文システム、及びプログラム - Google Patents

Abstract

【課題】座席を離れることなく商品を注文・受け取ることができ、かつ、商品の受け取りまでの目安待ち時間を利用者に把握させることが可能な注文管理技術を提供する。
【解決手段】管理サーバ３００は、携帯端末１００から注文情報を受信すると、オーダー管理テーブルＴＡ２に登録されている他の注文情報のステータス等を参照し、当該注文情報に対応する商品の受け渡しが完了するまでの目安待ち時間を算出し、携帯端末１００に通知する。さらに、管理サーバ３００は、店舗Ａの注文受付端末２００に注文情報を送信する。店舗Ａの注文受付端末２００は、管理サーバ３００から送信される注文情報について、プリンタ２５０を利用して注文レシート（２枚）を出力する。
【選択図】図１

Description

本発明は、イベント会場等において商品の注文を管理する技術に関する。

スポーツイベントなど、多くの利用者が集まる大規模なイベントは、利用者が座って観戦できるように、予約時に割り当てられる識別可能な座席（例えば、Ａ−４席）を有する施設（スタジアムなど）で開催される。

このようなイベントにおいて食べ物及び飲み物を欲する場合、利用者は、施設内を往来して食べ物及び飲み物を売り歩く売り子を見つけて注文するか、施設内の売店（店舗）まで出向いて注文するのが一般的である（例えば、特許文献１参照）。

特開２００２−２０３０１７号公報

しかしながら、売り子は通常１種類の食べ物又は飲み物しか持ち合わせておらず、利用者が欲している商品（例えばビールと弁当など）を持っているとは限らない。よって、多くの場合はそのような売り子が現れるまで待たなければならないが、売り子がいつ来るかは全く予想できず、非効率的であるという問題がある。

一方、売店に出向く場合には、試合の途中、あるいはハーフタイムまで待って売店に行き、商品を購入することになるが、多くの場合、売店の前には長蛇の列ができており、実際に商品を購入するまでに時間がかかるうえ、どれくらい待てば所望の商品を購入できるのかわからないために、待っている間に試合の重要な局面を見逃してしまう、という問題もある。

本発明は、以上説明した事情を鑑みてなされたものであり、座席を離れることなく商品を注文・受け取ることができ、かつ、商品の受け取りまでの目安待ち時間を利用者に把握させることが可能な注文管理技術を提供することを目的の一つとする。

本発明の一実施形態に係る注文管理サーバは、携帯端末から送信される商品の注文を受け付ける受付部と、注文された商品の種類、数、受付時刻を少なくとも含む注文情報を生成する生成部と、生成された注文情報を登録する記憶部と、記憶部に新たな注文情報が登録された場合には、既に記憶部に登録されている注文情報、および新たに登録された注文情報に基づいて、新たに登録された注文情報に係る商品の受け渡しに要する目安待ち時間を算出する算出部と、算出した目安待ち時間を携帯端末に通知する通知部とを備えることを特徴とする。

ここで、上記構成にあっては、算出部は、新たに登録された注文情報に係る商品が複数ある場合には、商品の各々について、個別の目安待ち時間を算出する態様が好ましい。

さらに、上記構成にあっては、通知部は、携帯端末から目安待ち時間の問い合わせを受けた場合に、算出した目安待ち時間を通知する態様も好ましい。

本発明によれば、利用者は座席を離れることなく商品を注文・受け取ることができ、かつ、商品の受け取りまでの目安待ち時間を把握することが可能となる。

本実施形態に係る注文システム１０００の概略構成を示す図である。 注文画面を例示した図である。 注文受付端末２００の主要構成を示すブロック図である。 注文管理画面を例示した図である。 注文システム１０００における業務フローを示すフローチャートである。 注文時における携帯端末１００、管理サーバ３００、注文受付端末２００間での処理フローをあらわすシーケンス図である。 注文情報のステータス更新時における管理サーバ３００、注文受付端末２００間での処理フローをあらわすシーケンス図である。 ３台の注文受付端末２００Ａ〜２００Ｃを利用して順番管理を行う場合のシーケンス図である。 目安待ち時間の表示例を示す図である。 目安待ち時間の表示例を示す図である。 注文時における携帯端末１００、管理サーバ３００、注文受付端末２００間での処理フローをあらわすシーケンス図である。

以下、本発明の実施形態について図面を参照しつつ詳細に説明する。なお、同一の要素には同一の符号を付し、重複する説明を省略する。

Ａ．本実施形態
図１は、本実施形態に係る注文システム１０００の概略構成を示す図である。
同図に示すように、注文システム１０００は、スポーツ観戦に訪れた各利用者が所持する携帯端末１００と、携帯端末１００から送信される商品（様々な役務も含む）の注文情報の受け付けを行う注文受付端末２００と、注文受付端末２００を管理する管理サーバ３００とを備えて構成される。

本実施形態では、スポーツイベントが開催されるイベント会場（例えば、アリーナや競技場）に適用した場合を例に説明を行うが、これに限る趣旨ではなく、あらゆる施設（屋内外を問わず）に適用可能である。また、図１では、店舗（店舗Ａ）に注文受付端末２００が設置されているが、１つのイベント会場に複数の店舗（店舗Ａ、店舗Ｂ・・・）が入っている場合には、店舗ごとに注文受付端末２００を設けても良い。さらに、本実施形態では注文情報として飲食に関わる商品（ビールやおつまみなど）を例示するが、いかなる商品またはサービスに適用するかはシステム運用等に応じて適宜変更可能である。

携帯端末１００は、例えばスマートフォンによって構成され、各利用者による操作に応じて店舗Ａで販売されている商品の注文情報を生成し、送信する。携帯端末１００から送信される注文情報は、通信ネットワークＮを経由して注文受付端末２００及び管理サーバ３００に受信される。携帯端末１００は、パーソナルコンピュータ（ＰＣ）、ノートＰＣ、携帯電話機、携帯情報端末（ＰＤＡ）など、インターネットにアクセス可能なあらゆる端末装置を利用することができる。

注文受付端末２００は、例えばタブレット端末などによって構成され、各携帯端末１００から送信される様々な注文情報を受信する。注文受付端末２００は、例えば店舗Ａの所定箇所（例えば、キッチンなど）に設置され、店舗Ａの各担当者が閲覧等することが可能となっている。注文受付端末２００は、タブレット端末に限る趣旨ではなく、パーソナルコンピュータ（ＰＣ）、ノートＰＣ、スマートフォン、携帯電話機、携帯情報端末（ＰＤＡ）など、通信ネットワークＮを介して管理サーバ３００とデータの授受が可能なあらゆる端末装置を利用することができる。

プリンタ２５０は、有線ケーブルまたは無線によって注文受付端末２００と接続され、注文情報ごとに、注文情報が印字されたレシート（以下、「注文レシート」という）を発券する。本実施形態では、注文レシートを２枚ずつ発券するが、その理由は後に詳述する。

管理サーバ３００は、例えば、演算処理能力の高いコンピュータによって構成され、そのコンピュータにおいて所定のサーバ用プログラムが動作することにより、サーバ機能を実現するものである。ここで、管理サーバ３００を構成するコンピュータは、必ずしも１台である必要はなく、通信ネットワークＮ上に分散する複数のコンピュータから構成されてもよい。管理サーバ３００は、施設ごとに注文受付端末２００を管理するためのデータベース３１０と、プロセッサ３２０と、を備えている。データベース３１０は、クライアント管理テーブルＴＡ１、オーダー管理テーブルＴＡ２、Ｗｅｂ管理テーブルＴＡ３を備えている。

クライアント管理テーブルＴＡ１には、施設ごとに固有のＩＤとパスコード（アカウント）が対応づけて登録されている。ここでは、「店舗Ａ」で利用される注文受付端末２００に対してユニークな識別情報（例えば、「ＩＤ：Ａ１・・・」）などが設定されている。識別情報は、例えばシステム導入の際に店舗Ａの管理者等が設定すればよい。なお、同一施設内で複数の注文受付端末２００を利用する場合には、全ての注文受付端末２００に同一の識別情報を設定しても良いが、注文管理端末２００ごとに異なる識別情報を設定しても良い。

オーダー管理テーブルＴＡ２には、注文情報の詳細（注文番号、注文された商品の種類や数、注文時刻、座席位置、言付けなど）、注文情報のステータス（「未対応」、「調理完了」、「受渡完了」など）が施設ごとに登録されている。一例を挙げて説明すると、店舗Ａにおいて、注文番号が「００１８」、受付時刻は「１４：１１」、注文された商品の種類や数は「えだまめ／１個、ビール／３本」、ステータスは「未対応」、席は「Ｗ２１０−０１３−Ｔ１０」、言付けは「なし」等である。オーダー管理テーブルＴＡ２の登録内容は、各携帯端末１００を用いた注文情報の新規登録操作や、各注文受付端末２００を用いた注文情報のステータスの更新操作に基づいて変更される。

Ｗｅｂ管理テーブルＴＡ３には、商品に関わる注文画面が施設ごとに登録されている。図２は、注文画面を例示した図である。各利用者には、予め注文画面のＵＲＬ等が通知されている、あるいは、各利用者がＱＲＬコードを読み取るなどして携帯端末１００から注文画面にアクセス可能となっている。注文画面にアクセスすると、利用者は、携帯端末１００を適宜操作して商品の注文を行う。商品注文に応じた注文情報などは、上述したようにオーダー管理テーブルＴＡ２に登録される。

プロセッサ３２０は、算術演算、論理演算、ビット演算等を処理する算術論理演算ユニット（ＣＰＵなど）および各種レジスタから構成され、ＲＯＭ等の記憶手段に格納されている各種プログラムを実行することで管理サーバ３００の各部を中枢的に制御する。また、プロセッサ３２０は、注文受付端末２００と連携して注文を管理するためのコンピュータプログラム（注文管理アプリケーション）も実行する。

通信ネットワークＮは、管理サーバ３００と注文受付端末２００との間で相互に情報を送受信可能な通信網を含む。通信ネットワークＮは、例えばインターネット、ＬＡＮ、専用線、電話回線、企業内ネットワーク、移動体通信網、ブルートゥース、ＷｉＦｉ（Wireless Fidelity）、その他の通信回線、それらの組み合わせ等のいずれであっても良く、無線であるかを問わない。

通信ネットワークＮは、管理サーバ３００と注文受付端末２００との間で相互に情報を送受信可能な通信網を含む。通信ネットワークＮは、例えば、インターネット、ＬＡＮ、専用線、電話回線、企業内ネットワーク、移動体通信網、ブルートゥース、ＷｉＦｉ（Wireless Fidelity）、その他の通信回線、それらの組み合わせ等のいずれであってもよく、有線であるか無線であるかを問わない。

図３は、注文受付端末２００の主要構成を示すブロック図である。注文受付端末２００は、プロセッサ２１０と、入力装置２１５と、表示装置２１６と、通信インタフェース２２０と、記憶資源２３０とを備える。注文受付端末２００は、店舗Ａの担当者が入力装置２１５を操作することで、ステータスが更新された注文情報の登録等を受け付ける。

プロセッサ２１０は、算術演算、論理演算、ビット演算等を処理する算術論理演算ユニット（ＣＰＵなど）および各種レジスタから構成され、記憶資源２３０に格納されている各種プログラムを実行することで注文受付端末２００の各部を中枢的に制御する。各種レジスタは、例えば、プログラムカウンタ、データレジスタ、命令レジスタ、汎用レジスタ等である。

入力装置２１５は、担当者による注文情報の新規登録操作やステータスの更新操作等を受け付けるための各種操作ボタンやタッチパネル２１５ａを備えている。

表示装置２１６は、図４に示すような受け付けが行われた注文管理画面を表示するための装置であり、例えば液晶ディスプレイにより構成される。

通信インタフェース２２０は、通信ネットワークＮに接続し、通信ネットワークＮ上の他の端末と通信をするためのハードウェアモジュールである。通信インタフェース２２０は、例えば、ＩＳＤＮモデム、ＡＤＳＬモデム、ケーブルモデム、光モデム、ソフトモデム等の変調復調装置である。

記憶資源２３０は、例えば、物理デバイスの記憶領域が提供する論理デバイスである。物理デバイスは、例えば、ディスクドライブまたは半導体メモリ（ＲＯＭ、ＲＡＭなど）等のコンピュータ読み取り可能な記録媒体である。記憶資源２３０は、複数の物理デバイスを１つの論理デバイスにマッピングして構築してもよいし、１つの物理デバイスを複数の論理デバイスにマッピングして構築してもよい。

記憶資源２３０には、オペレーティングシステムプログラム、ドライバプログラム、各種データ等が格納される。ドライバプログラムとしては、例えば、通信インタフェース２２０を制御するための通信インタフェースドライバプログラム等がある。また、記憶資源２３０には、これら各種プログラムや各種データのほか、プロセッサ２１０が実行することにより、管理サーバ３００と連携して注文情報を管理するためのプログラム（注文管理アプリケーション）ＡＰ１が記憶されている。次に、本実施形態における注文システム１０００の動作について説明する。

（注文〜受け渡しまでの業務フロー）
図５は、商品の注文が行われてから受け渡しが完了するまでの業務フローを模式的に示した図である。

まず、利用者は、携帯端末１００を利用して注文Ｗｅｂページにアクセスし、店舗Ａに対する商品の注文を行う（Ｃ１）。管理サーバ３００は、利用者からの注文に応じて注文情報を作成し、店舗Ａに送信する。店舗Ａの注文受付端末２００は、注文情報を受信すると、受信した注文情報を、２枚のレシート（以下、注文レシート）に印字してプリンタ２５０から出力する（Ｃ２）。店舗Ａにおいて商品を管理する担当者は、注文レシートに印字された注文情報に基づき、利用者に提供する商品を用意した後（Ｃ３）、商品とともに注文レシート（２枚）を売り子に渡す（Ｃ４）。売り子は、注文レシートに記載されている座席位置（例えば、「Ｗ２１０−０１３−Ｔ１０」）を参照しながら、注文した利用者に商品を配送する（Ｃ５）。売り子は、利用者に商品を渡すとともに、お客様控えとして注文レシート（１枚）を渡す（Ｃ６）。利用者は、商品を受け取ると、現金またはキャッシュカード等を利用して精算を行う。もっとも、携帯端末１００が何らかの電子課金システムを利用できる状態にある場合には、電子課金システムを利用してカードレス決済を行っても良い。

このように商品の配送が完了すると、売り子は、残り１枚の注文レシートを持って店舗Ａに戻り（Ｃ７）、自身の名前をサインして担当者に渡す（Ｃ８）。担当者は、注文受付端末２００に注文管理画面を表示させた後、スワイプ操作等して受け渡しが完了した旨の入力を行う（Ｃ９）。前掲図４に示すように、注文管理画面には、注文番号、受付時刻、メニュー、個数、価格とともに、注文処理のステータスが表示される。担当者は、注文レシートを参照して対応が完了した注文を特定すると、この注文に対応するステータス部分をスワイプ操作し、「受渡完了」のコマンドを選択操作することで、注文した商品の受け渡しが正常に完了したことを注文受付端末２００に入力する。担当者は、かかる入力を終えると、残り１枚のレシートをフォルダ等にファイリングして処理を終了する。

（注文処理フロー）
図６は、注文時における携帯端末１００、管理サーバ３００、注文受付端末２００間での処理フローをあらわすシーケンス図である。
携帯端末１００は、利用者による注文ＷｅｂページのＵＲＬ等の入力操作に応じて、管理サーバ３００に注文画面の表示リクエストを送信する（ステップＳ１）。管理サーバ３００は、携帯端末１００からの表示リクエストを受信すると、この表示リクエストを検索キーとしてＷｅｂ管理テーブルＴＡ３を検索することにより、対応する店舗（ここでは、店舗Ａ）の注文画面を読み出し、携帯端末１００に送信する（ステップＳ２）。携帯端末１００は、管理サーバ３００から受信した注文画面（図２参照）を表示し（ステップＳ３）、利用者による注文操作の入力を待つ（ステップＳ４）。

携帯端末１００は、注文操作がない場合には（ステップＳ４：ＮＯ）、ステップＳ３の処理を繰り返し実行する一方、注文操作を検知すると（ステップＳ４：ＹＥＳ）、注文操作に応じた注文情報を作成する（ステップＳ５）。注文情報には、利用者が選択した商品の種類と数（例えば、「えだまめ／１個、ビール／３本」）とともに、利用者の座席（例えば、「Ｗ２１０−０１３−Ｔ１０」）や言付け（例えば、「なし」）などが含まれる。なお、座席の特定方法としては、各利用者に座席番号等を直接入力させる方法を採用しても良いが、座席番号に対応するＱＲコード（登録商標）を携帯端末１００に読み込ませる方法等を採用しても良い。

携帯端末１００は、注文情報を作成すると、注文が完了したか否かを判断する（ステップＳ６）。携帯端末１００は、注文完了ボタンがタッチ操作等されることなく、追加注文・変更等の操作がなされた場合には（ステップＳ６：ＮＯ）、ステップＳ４に戻り、上述した一連の処理を繰り返し実行する。一方、携帯端末１００は、注文画面に表示される注文完了ボタンがタッチ操作等され、注文が完了したと判断すると（ステップＳ６：ＹＥＳ）、作成した注文情報を管理サーバ３００に送信する（ステップＳ７）。

管理サーバ（受付部）３００は、携帯端末１００から注文情報を受信すると、クライアント管理テーブルＴＡ１等を参照し、店舗Ａの注文受付端末２００宛てに注文情報を送信（転送）する（ステップＳ８）。管理サーバ（生成部）３００は、携帯端末１００からの注文情報をもとに、注文情報の詳細（注文番号、注文された商品の種類や数、注文時間、座席位置、言付けなど）、注文情報のステータス（新規登録であれば「未対応」）を含む注文情報を生成（加工）し、店舗Ａの注文受付端末２００宛てに送信する。

店舗Ａの注文受付端末（受信部）２００は、管理サーバ３００から注文情報を受信すると、プリンタ２５０を利用して注文情報が印字された注文レシート（２枚）を出力する（ステップＳ９）。なお、注文受付端末２００が、新たに注文情報を受信したとしても、担当者が気づかない可能性がある。よって、新たに注文情報を受信した場合には、これを担当者に確実に伝えるべく、注文受付端末（報知部）２００から効果音や表示メッセージなどを出力しても良い。

一方、管理サーバ（記憶部）３００は、上述した注文情報をオーダー管理テーブルＴＡ２に新たに登録する（ステップＳ１０）。さらに、管理サーバ（算出部、通知部）３００は、オーダー管理テーブルＴＡ２に登録されている他の注文情報のステータス等を参照し、当該注文情報に対応する商品の受け渡しが完了するまでの予測時間（以下、目安待ち時間）を算出し、携帯端末１００に通知する（ステップＳ１１）。管理サーバ３００のメモリ（図示略）には、目安待ち時間を算出するための参照テーブルやアルゴリズムなどが格納されている。参照テーブルには、商品と商品の提供に要する目安待ち時間とが対応づけて登録されている。例えば、商品「えだまめ」については、目安待ち時間「５分」であり、商品「玉子焼」については、目安待ち時間「１５分」・・・等である。簡単な例として、「未対応」の他の注文情報として「えだまめ」が「６つ」あり、今回の注文情報として「玉子焼」が「２つ」ある場合、目安待ち時間は「６０分」（＝５分×６＋１５分×２）となる。もっとも、目安待ち時間は、未対応の他の注文情報のみならず、店の混雑状況（例えば、対応可能な担当者の数や）などによって変わり得ることから、これらの事情を考慮して目安待ち時間を算出しても良い。

携帯端末１００は、管理サーバ３００から通知された目安待ち時間（例えば「目安待ち時間：４０分程度」など）を、表示画面に表示した後（ステップＳ１２）、処理を終了する。利用者は、表示画面上の目安待ち時間を把握することで、商品を注文したものの、いつ届くかわからないために席を立てない、あるいは本当に商品が届くか不安になる、という心配を払拭することができる。

（ステータスの更新処理フロー）
図７は、注文情報のステータス更新時における管理サーバ３００、注文受付端末２００間での処理フローをあらわすシーケンス図である。以下、ステータスが更新される一例として注文の受け渡しが完了した場合を想定する。

注文した商品の受け渡しが完了すると、担当者は、注文受付端末２００上の注文管理画面に表示される複数の注文情報の中から、受け渡しが完了した注文情報を特定する。そして、この注文情報に対応するステータス部分をスワイプ操作し、「受渡完了」のコマンドを選択する。注文受付端末２００は、「受渡完了」のコマンドが選択されたことから、注文情報のステータスが更新されたと判断すると（ステップＳａ１：ＹＥＳ）、注文番号や店舗Ａの識別情報を含めて、注文情報のステータスの更新内容を管理サーバ３００宛てに送信する（ステップＳａ２）。なお、注文情報のステータスが更新されない場合には（ステップＳａ１：ＮＯ）、ステップＳａ１の処理を繰り返し実行する。管理サーバ３００は、注文情報のステータスの更新内容を受信すると、注文番号や店舗Ａの識別情報をもとに、オーダー管理テーブルＴＡ２を参照し、対応する注文情報のステータスを更新（ここでは、「未対応」→「受渡完了」）し（ステップＳａ３）、処理を終了する。なお、ステータスが「受渡完了」に切り換わると、この注文情報は注文管理画面から消去される（いわゆる消し込み）。

ここで、注文情報のステータスの更新は、「受渡完了」以外に、注文の取り消しを意味する「取消」、注文した商品の調理の完了を意味する「調理完了」などがある。もちろん、ステータスの種類や数は、これらに限定する趣旨ではなく、業務形態などに応じて適宜設定・変更可能である。

（商品の在庫がなくなった場合等の対応）
多数の人が集まるイベント会場では、早々に商品の在庫がきれてしまうことも懸念される。商品の在庫が無くなった場合（あるいは商品の在庫が無くなりかけた場合）には、速やかに注文の受付を止める必要があるため、本実施形態では、注文受付端末２００を用いて商品の注文受付のコントロール（受付停止、受付再開など）を行う。一例を挙げて説明すると、担当者は、注文受付端末２００を操作することで管理設定画面を表示し、注文受付を停止する商品（以下では、商品Ａとする）を選択する。注文受付の停止操作がなされると、注文受付端末２００から管理サーバ３００に対して、店舗Ａにおいて商品Ａの注文受付を停止すべき旨の通知が行われる。管理サーバ３００は、かかる通知に基づき、Ｗｅｂ管理テーブルＴＡ３を参照し、店舗Ａにおいて商品Ａの注文の受付けを停止する処理（商品Ａの選択を無効とするなど）を行う。

このように、本実施形態によれば、注文受付端末２００の簡単な操作で、直ちに所定商品の注文受付を停止することができるというメリットを享受できる。なお、上記では、商品の在庫が無くなった場合を例に説明したが、在庫が無くなった場合のみならず、店舗Ａの営業を停止する場合も同様に説明することができる。この場合は、携帯端末１００の管理設定画面を表示し、店舗Ａでの注文受付を全て停止する。注文受付の停止操作がなされると、注文受付端末２００から管理サーバ３００に対して、店舗Ａにおける注文受付を全て停止する旨の通知が行われる。管理サーバ３００は、かかる通知に基づき、Ｗｅｂ管理テーブルＴＡ３を参照し、店舗Ａにおける注文の受付けを全て停止する処理（店舗Ａの選択そのものを無効とするなど）を行う。このような処理を実行してもよい。

以上説明したように、本実施形態によれば、管理サーバ３００は、携帯端末１００から注文情報を受信すると、オーダー管理テーブルＴＡ２に登録されている他の注文情報のステータス等を参照し、当該注文情報に対応する商品の受け渡しが完了するまでの目安待ち時間を算出し、携帯端末１００に通知する。これにより、利用者は、携帯端末１００の表示画面上の目安待ち時間を把握することで、商品を注文したものの、いつ届くかわからないために席を立てない、あるいは本当に商品が届くか不安になる、という心配を払拭することが可能となる。

Ｂ．その他
なお、本発明は、上述した実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。このため、上記実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述した各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更し、または並列に実行することができる。

上述の実施形態では、注文受付端末２００と管理サーバ３００とが連携して注文情報を管理するシステムについて説明したが、システムの構成はこれに限られず、種々の構成を採用可能である。例えば、管理サーバ３００が有する機能を注文受付端末２００側で備えることにより、注文受付端末２００単体で注文システム１０００と同等の機能を備える装置を構成することができる。

また、本実施形態では、１施設（実施形態では店舗Ａ）で１台の注文受付端末２００を利用する場合を例示したが、１施設で複数台の注文受付端末２００を利用することも可能である。１施設で複数台の注文受付端末２００を利用する場合には、各注文受付端末２００の間でデータが共有される。

図８は、３台の注文受付端末２００Ａ〜２００Ｃを利用して順番管理を行う場合のシーケンス図である。たとえば、店舗Ａにおいて特定の注文受付端末２００（図８に示す注文受付端末２００Ａ）が操作されると（Ｃ１１）、その操作内容（注文情報の新規登録など）は管理サーバ３００にアップロードされる（Ｃ１２）。管理サーバ３００は、受信した新たな注文情報に基づき、オーダー管理テーブルＴＡ２に登録されている店舗Ａの注文情報を更新する（Ｃ１３）。そして、管理サーバ３００は、クライアント管理テーブルＴＡ１を参照し、今回、注文を受付けた注文受付端末２００Ａを特定する（Ｃ１４）。ここでは、店舗Ａに対して３台の注文受付端末２００Ａ〜２００Ｃがクライアント管理テーブルＴＡ１に登録されていることから、管理サーバ３００は、注文受付端末２００Ａ以外の端末、すなわち注文受付端末２００Ｂ及び２００Ｃに対してアップデートされた最新の注文情報を送信し（Ｃ１５）、処理を終了する。

この結果、最新の情報が、常に同期した状態で各注文受付端末２００に反映され、これにより、１施設で複数台の注文受付端末２００を利用する場合であっても、注文情報の更新が一部の注文受付端末２００において反映されない等の不具合を生ずることなく、最適な注文情報の管理を行うことが可能となる。

また、本実施形態では、管理サーバ（算出部）３００は、注文した商品が複数ある場合、全ての商品の受け渡しが完了するまでのトータルの目安待ち時間を通知する構成としたが（図９参照）、これに代えて（または加えて）、注文した商品の各々について個別の目安待ち時間を通知しても良い（図１０参照）。

さらにまた、商品が選択される都度、目安待ち時間を通知する構成としても良い。
図１１は、変形例に係る注文時における携帯端末１００、管理サーバ３００、注文受付端末２００間での処理フローをあらわすシーケンス図である。なお、図１１において図６に対応するステップには同一符号を付し、詳細な説明は割愛する。

携帯端末１００は、注文操作を検知すると（ステップＳ４：ＹＥＳ）、注文操作に応じた注文情報を作成する（ステップＳ５）。注文情報には、利用者が選択した商品の種類と数（例えば、「えだまめ／１個、ビール／３本」）とともに、利用者の座席（例えば、「Ｗ２１０−０１３−Ｔ１０」）や言付け（例えば、「なし」）などが含まれる。そして、個別の注文情報のそれぞれについて目安待ち時間（以下、「個別目安待ち時間」）の問い合わせを行う（ステップＳ１３）。管理サーバ（通知部）３００は、個別目安待ち時間の問い合わせを受けると、オーダー管理テーブルＴＡ２に登録されている他の注文情報のステータス等を参照し、個別目安待ち時間を算出し、携帯端末１００に通知する（ステップＳ１４）。

携帯端末１００は、管理サーバ３００から通知された個別目安待ち時間（図１０参照）を、表示画面に表示する（ステップＳ１５）。その後、携帯端末１００は、利用者によって注文完了ボタンがタッチ操作等されたか否かを判断する（ステップＳ６）。例えば、ある特定の商品の個別目安待ち時間が極端に長いため（例えば、「４５分」）、注文を変更するような場合には、注文完了ボタンがタッチ操作等されることなく、追加注文・変更等の操作がなされる（ステップＳ６：ＮＯ）。この場合は、ステップＳ４に戻り、上述した一連の処理が繰り返し実行される。一方、携帯端末１００は、注文画面に表示される注文完了ボタンがタッチ操作等され、注文が完了したと判断すると（ステップＳ６：ＹＥＳ）、作成した注文情報を管理サーバ３００に送信する（ステップＳ７）。なお、この後の動作は、上記本実施形態と同様に説明することができるため、これ以上の説明は割愛する。このように、商品が選択される都度（すなわち、注文が完了する前に）、商品の受け渡しまでの目安待ち時間がわかることで、より効率の良い商品注文が可能となる。

また、本実施形態では、注文してから商品の受け渡しが行われるまで、特に呼出を行う点について言及しなかったが、電話呼出を行うようにしても良い。商品注文の際、電話での呼出設定を希望するか、利用者に確認するメッセージを携帯端末１００に表示する（「電話でのお呼出を設定できます。ご希望の方は、下記ボタンを押した後、電話番号を入力してください。」など）。利用者は、電話での呼出設定を希望する場合には、このメッセージに従って電話番号を入力する。この結果、商品の受け渡しを行う際に、例えば利用者が座席を離れていて見つからない場合でも、売り子等による呼出が行われ、商品の受け渡しを確実に行うことが可能となる。また、電話呼出に代えて（あるいは加えて）、テキストメッセージによる呼出を行うようにしても良い。具体的には、商品の注文の際、テキストメッセージによる呼出設定を希望するか、利用者に確認するメッセージを携帯端末１００に表示する（「通知を受け取るメールアドレスを下記に入力してください。」など）。利用者は、このメッセージに従ってメールアドレスを入力することで、テキストメッセージによる呼出を受けることが可能となる。

１０００…注文システム
１００、１００Ａ、１００Ｂ、１００Ｃ…携帯端末
２００…注文受付端末
２５０…プリンタ
３００…管理サーバ
３２０…プロセッサ
ＴＡ１…クライアント管理テーブル
ＴＡ２…オーダー管理テーブル
ＴＡ３…Ｗｅｂ管理テーブル
Ｎ…通信ネットワーク
２１０…プロセッサ
２１５…入力装置
２１５ａ…タッチパネル
２１６…表示装置
２２０…通信インタフェース
２３０…記憶資源
ＡＰ１…注文管理アプリケーション

Claims (5)

1. 携帯端末から送信される商品の注文を受け付ける受付部と、
   注文された前記商品の種類、数、受付時刻を少なくとも含む注文情報を生成する生成部と、
   生成された前記注文情報を登録する記憶部と、
   前記記憶部に新たな注文情報が登録された場合には、既に前記記憶部に登録されている前記注文情報、および新たに登録された前記注文情報に基づいて、新たに登録された前記注文情報に係る商品の受け渡しに要する目安待ち時間を算出する算出部と、
   算出した目安待ち時間を前記携帯端末に通知する通知部と
   を備えた注文管理サーバ。
2. 前記算出部は、新たに登録された前記注文情報に係る商品が複数ある場合には、前記商品の各々について、個別の目安待ち時間を算出する、請求項１に記載の注文管理サーバ。
3. 前記通知部は、前記携帯端末から前記目安待ち時間の問い合わせを受けた場合に、算出した前記目安待ち時間を通知する、請求項１に記載の注文管理サーバ。
4. 商品を管理する注文受付端末と、請求項１〜３のいずれか１の請求項に記載の注文管理サーバを備えた注文システムであって、
   前記注文受付端末は、
   前記注文管理サーバから前記注文情報を受信する受信部と、
   前記注文情報を受信した場合に、当該注文情報を受信したことを報知する報知部を備える、注文システム。
5. 記憶部を備えたコンピュータに、
   携帯端末から送信される商品の注文を受け付ける受付機能と、
   注文された前記商品の種類、数、受付時刻を少なくとも含む注文情報を生成する生成機能と、
   生成された前記注文情報を前記記憶部に登録する記憶機能と、
   前記記憶部に新たな注文情報が登録された場合には、既に前記記憶部に登録されている前記注文情報、および新たに登録された前記注文情報に基づいて、新たに登録された前記注文情報に係る商品の受け渡しに要する目安待ち時間を算出する算出機能と、
   算出した目安待ち時間を前記携帯端末に通知する通知機能とを実現させるためのプログラム。

Images