以下、図面を参照して、実施形態に係るサーバ装置、プログラム及び注文システムについて説明する。以下に説明する実施形態では、スーパーマーケット等の施設内に設けられたフードコートに適用した例に説明する。なお、以下に説明する実施形態に限定されるものではない。
図1は、本実施形態に係る注文システムの構成の一例を示す図である。図1に示すように、注文システム1は、ユーザ端末10と、店舗端末20と、サーバ装置30とを有する。ユーザ端末10、店舗端末20及びサーバ装置30は、有線LAN(Local Area Network)や無線LAN、公衆回線等のネットワークN1を介して通信可能に接続される。
ユーザ端末10は、フードコートを利用するユーザが操作する端末装置である。例えば、ユーザ端末10は、ユーザが所持するスマートフォン等の端末装置であってもよいし、フードコート内に設けられた共用席等に設置される専用の端末装置であってもよい。
ユーザ端末10は、フードコート内の店舗で販売される飲食物(以下、単に商品ともいう)の注文に係る操作を受け付け、注文対象の商品を指示する情報を含んだ注文情報をサーバ装置30に送信する。また、ユーザ端末10は、サーバ装置30から送信される各種の情報に応じて、画面表示等の処理を実行する。
図2は、ユーザ端末10のハードウェア構成の一例を示す図である。図2に示すように、ユーザ端末10は、CPU(Central Processing Unit)11、ROM(Read Only Memory)12、及びRAM(Random Access Memory)13等のコンピュータ構成を備える。
CPU11は、プロセッサの一例であり、ユーザ端末10の各部を統括的に制御する。ROM12は、各種プログラムを記憶する。RAM13は、プログラムや各種データを展開するワークスペースである。CPU11は、ROM12や後述する記憶部18に記憶されRAM13に展開されたプログラムに従って動作することによって、各種の処理を実行する。
また、ユーザ端末10は、表示部14、操作部15、音声出力部16、通信部17、及び記憶部18等を備える。
表示部14は、LCD等の表示デバイスであり、CPU11の制御に従って各種の情報や画面を表示する。操作部15は、各種の操作キーを有し、ユーザの操作に応じた操作内容をCPU11に出力する。なお、操作部15は、表示部14の表面に設けられたタッチパネルであってもよい。音声出力部16は、スピーカ等の音声出力デバイスであり、CPU11の制御に従ってブザー音等の音声を出力する。
通信部17は、ネットワークN1に接続可能な通信インタフェースである。通信部17は、ネットワークN1を介して店舗端末20やサーバ装置30等の外部装置と通信を行う。
記憶部18は、HDDやフラッシュメモリ等で構成されており、電源を遮断しても記憶内容を維持する。記憶部18は、CPU11が実行することが可能なプログラムや、端末ID等の各種の設定情報を記憶する。端末IDは、ユーザ端末10を識別することが可能な識別情報である。端末IDは、例えばIPアドレスや電話番号等のネットワークN1上の識別子を用いてもよい。
図1に戻り、店舗端末20は、フードコート内の各店舗に設けられる端末装置である。店舗端末20は、例えば、サーバ装置30を介して通知されたユーザからの注文内容を受信し、当該注文内容を表示したりすることで、注文された商品の内訳を店舗内の店員に報知する。また、店舗端末20は、店員からの操作に応じて、注文に対する処理状況を示したステータス情報をサーバ装置30に送信する。
図3は、店舗端末20のハードウェア構成の一例を示す図である。図3に示すように、店舗端末20は、CPU21、ROM22、及びRAM23等のコンピュータ構成を備える。
CPU21は、プロセッサの一例であり、店舗端末20の各部を統括的に制御する。ROM22は、各種プログラムを記憶する。RAM23は、プログラムや各種データを展開するワークスペースである。CPU21は、ROM22や後述する記憶部27に記憶されRAM23に展開されたプログラムに従って動作することによって、各種の処理を実行する。
また、店舗端末20は、表示部24、操作部25、通信部26、及び記憶部27等を備える。
表示部24は、LCD等の表示デバイスであり、CPU21の制御に従って各種の情報や画面を表示する。操作部25は、各種の操作キーを有し、ユーザの操作に応じた操作内容をCPU21に出力する。なお、操作部25は、表示部24の表面に設けられたタッチパネルであってもよい。
通信部26は、ネットワークN1に接続可能な通信インタフェースである。通信部26は、ネットワークN1を介してユーザ端末10やサーバ装置30等の外部装置と通信を行う。
記憶部27は、HDDやフラッシュメモリ等で構成されており、電源を遮断しても記憶内容を維持する。記憶部27は、CPU21が実行することが可能なプログラムや、店舗ID等の各種の設定情報を記憶する。店舗IDは、店舗端末20が設けられた店舗を識別することが可能な識別情報である。店舗IDは、例えば店舗端末20のIPアドレスや電話番号等のネットワークN1上の識別子を用いてもよい。また、記憶部27は、自己の店舗で販売する商品の各々について、後述する商品ID,メニュー名、価格等を関連付けた商品マスタを記憶してもよい。
図1に戻り、サーバ装置30は、サーバ装置の一例である。サーバ装置30は、ユーザ(ユーザ端末10)と、フードコート内の各店舗(店舗端末20)との間の商取引を仲介する各種の処理を実行する。
例えば、サーバ装置30は、ユーザ端末10に対し、フードコート内の各店舗で販売される商品のメニューを示したメニュー情報を提供する。また、サーバ装置30は、ユーザ端末10から注文情報を受信し、注文情報に含まれた決済処理に係る情報に基づいて、注文された商品の決済処理を実行する。また、サーバ装置30は、注文情報に含まれた注文内容を、注文先となる店舗の店舗端末20に送信する。また、サーバ装置30は、店舗端末20から通知されるステータス情報等に基づいて注文の処理状況を管理し、当該処理状況に応じてユーザ端末10に報知等を行う。
図4は、サーバ装置30のハードウェア構成の一例を示す図である。図4に示すように、サーバ装置30は、CPU31、ROM32、及びRAM33等のコンピュータ構成を備える。
CPU31は、プロセッサの一例であり、サーバ装置30の各部を統括的に制御する。ROM32は、各種プログラムを記憶する。RAM33は、プログラムや各種データを展開するワークスペースである。CPU31は、ROM32や後述する記憶部35に記憶されRAM33に展開されたプログラムに従って動作することによって、各種の処理を実行する。
また、サーバ装置30は、通信部34、及び記憶部35等を備える。通信部34は、ネットワークN1に接続可能な通信インタフェースである。通信部34は、ネットワークN1を介してユーザ端末10や店舗端末20等の外部装置と通信を行う。
記憶部35は、HDDやフラッシュメモリ等で構成されており、電源を遮断しても記憶内容を維持する。記憶部35は、CPU21が実行することが可能なプログラムや各種の設定情報を記憶する。
また、記憶部35は、店舗マスタ351、メニューマスタ352を記憶する。店舗マスタ351は、フードコート内で営業する各店舗の店舗IDと店舗名とを関連付けた情報である。店舗IDは、フードコートにおいて店舗を識別するための識別情報である。
メニューマスタ352は、フードコート内の各店舗が販売する商品の各々について、店舗ID、商品ID、メニュー名、価格等を関連付けた情報である。商品IDは、各店舗で販売される商品を識別するための識別情報である。なお、メニューマスタ352は、商品IDに関連付けて、商品を表す画像や説明文等を記憶してもよい。
また、記憶部35は、店舗端末20から送信された注文情報を管理するための注文管理テーブル353を記憶する。注文管理テーブル353は、記憶手段の一例である。注文管理テーブル353は、例えば、図5に示す決済用テーブル3531と、図6に示す店舗用テーブル3532とを有する。
図5は、決済用テーブル3531のデータ構成の一例を示す図である。決済用テーブル3531は、注文IDに、受付日時、端末ID、店舗ID、金額、ステータス等の情報を関連付けて記憶する。注文IDは、注文を識別可能にするものであって、ひとまとまりの注文毎に発行される。受付日時は、注文を受け付けた日時を示す数字列である。端末IDには、注文を行ったユーザ端末10の端末IDが格納される。店舗IDは、注文先の店舗の店舗IDが格納される。金額は、店舗別の注文の合計金額である。例えば、ひとまとまりの注文で複数の店舗の商品が注文された場合、同一の注文ID及び端末IDに関連付けて、複数の店舗IDが格納されることになる(注文ID「注文02」参照)。
また、ステータスは、注文された商品の処理状況を示す情報である。例えば、ステータスには、注文及び決済が完了したことを示す「注文完了」や、商品の調理が開始されたことを示す「調理中」、商品の調理が完了したことを示す「調理完了」、商品の受け取りが完了したことを示す「受取完了」等の情報が格納される。なお、端末ID、店舗ID、及び金額は、注文情報に含まれる情報である。
図6は、店舗用テーブル3532のデータ構成の一例を示す図である。店舗用テーブル3532は、注文IDに、受付日時、店舗ID、商品ID、単価、個数、小計、及びステータス等の情報を関連付けて記憶する。ここで、小計は、商品IDで特定される商品の単価に個数を乗算した金額である。なお、店舗ID、商品ID、単価、個数、及び小計は、注文情報に含まれる情報である。
また、記憶部35は、各種のコンテンツデータを管理するためのコンテンツ管理テーブル354を記憶する。
図7は、コンテンツ管理テーブル354のデータ構成の一例を示す図である。コンテンツ管理テーブル354は、上述したステータス毎にコンテンツデータを記憶する。具体的には、コンテンツ管理テーブル354は、上述した「注文完了」、「調理中」、「調理完了」及び「受取完了」の各ステータスに関連付けて、第1~第4のコンテンツデータを記憶する。以下では第1~第4のコンテンツデータを総称して、単にコンテンツデータともいう。
コンテンツデータは、例えば動画データや静止画データであり、コマーシャル(CM)等の各種の内容を表すものである。コンテンツデータは、フードコートが設けられた施設やフードコート以外の店舗に関するものであってもよい。また、コンテンツデータは、フードコートに設けられた各店舗に関するものや、当該店舗で販売される商品に関するものであってもよい。また、コンテンツデータのデータ形式は、動画、静止画以外にもURL等のアクセス先を指示するアクセス先情報であってもよい。この場合、指示されたアクセス先にアクセスすることで、ライブ動画等の実データをアクセス先から取得できるものとする。
図7において、第1コンテンツデータは、ステータスが「注文完了」の際に提供されるコンテンツデータである。また、第2コンテンツデータは、ステータスが「調理中」の際に提供されるコンテンツデータである。また、第3コンテンツデータは、ステータスが「調理完了」の際に提供されるコンテンツデータである。また、第4コンテンツデータは、ステータスが「受取完了」の際に提供されるコンテンツデータである。
各ステータスで提供するコンテンツデータの内容は同様としてもよいが、本実施形態では、後述するように、ステータス毎に提供するコンテンツデータの内容を、そのステータス時のユーザの状態等に応じて相違させている。ここで、相違とは、記憶されるコンテンツデータが完全に相違する概念の他、主となるコンテンツデータが相違することをも含む概念である。後者の場合、各ステータスで共通するコンテンツデータを含んでもよいが、主となるコンテンツデータ(第1~第4のコンテンツデータ)の割合や提供頻度が相違することを意味する。
なお、図7では全てのステータスにコンテンツデータを関連付けた例を示しているが、これに限らず、コンテンツデータを関連付けないステータス、つまりコンテンツデータを提供しないステータスを設けてもよい。また、各ステータスに関連付けられるコンテンツデータの個数は特に問わないものとする。例えば、同一のステータスに複数のコンテンツデータが関連付けられる場合、コンテンツ管理テーブル354は、コンテンツデータの提供順序を規定したスケジュール情報をあわせて記憶してもよい。
次に、注文システム1の機能構成について説明する。図8は、ユーザ端末10、店舗端末20及びサーバ装置30の機能構成の一例を示す図である。なお、図8では、装置間で関係する機能部同士を矢印で接続している。
図8に示すように、ユーザ端末10は、メニュー表示部111と、注文情報送信部112と、報知動作部113と、コンテンツ表示部114とを機能部として備える。ユーザ端末10が備える機能部の一部又は全ては、ユーザ端末10のプロセッサ(CPU11)とメモリ(ROM12、記憶部18等)に記憶された各種プログラムとの協働により実現されてもよいし、プロセッサ等が具備する専用回路等で実現されてもよい。
また、店舗端末20は、注文受付部211と、ステータス通知部212とを機能部として備える。店舗端末20が備える機能部の一部又は全ては、店舗端末20のプロセッサ(CPU21)とメモリ(ROM22、記憶部27等)に記憶された各種プログラムとの協働により実現されてもよいし、プロセッサ等が具備する専用回路等で実現されてもよい。
また、サーバ装置30は、メニュー提供部311と、注文情報受信部312と、決済処理部313と、注文処理部314と、ステータス管理部315と、報知処理部316と、コンテンツ提供部317とを機能部として備える。サーバ装置30が備える機能部の一部又は全ては、サーバ装置30のプロセッサ(CPU31)とメモリ(ROM32、記憶部35等)に記憶された各種プログラムとの協働により実現されてもよいし、プロセッサ等が具備する専用回路等で実現されてもよい。
ユーザ端末10のメニュー表示部111は、サーバ装置30にアクセスすることで、サーバ装置30から提供されるメニュー情報を取得する。メニュー表示部111は、取得したメニュー情報に基づいて、注文の対象となる商品を選択可能な画面(以下、メニュー画面ともいう)を表示部14に表示させる。ユーザ端末10のユーザは、メニュー画面に基づいて注文する商品を選択することができる。
サーバ装置30のメニュー提供部311は、メニュー提供手段の一例である。メニュー提供部311は、フードコート内の各店舗が販売する商品の各々を示したメニュー情報をユーザ端末10に提供する。
具体的には、メニュー提供部311は、ユーザ端末10(メニュー表示部111)からのアクセスに応じてメニュー情報を提供する。より詳細には、メニュー提供部311は、店舗マスタ351及びメニューマスタ352に記憶された情報に基づいて、フードコート内の各店舗で販売されている商品を示したメニュー情報を生成し、アクセス元のサーバ装置30に送信する。なお、メニュー提供部311は、メニュー情報としてメニュー画面をユーザ端末10に提供する形態としてもよい。
ユーザ端末10の注文情報送信部112は、メニュー画面に対する操作に基づき、注文の対象となった商品の商品IDや決済処理に係る情報等を含んだ注文情報をサーバ装置30に送信する。
具体的には、注文情報送信部112は、メニュー画面から注文対象となる商品の選択を受け付けると、当該商品に係る店舗ID、商品ID、単価、個数及び小計、店舗別の注文の合計金額等とともに、自己のユーザ端末10の端末IDを含んだ注文情報を生成する。また、注文情報送信部112は、合計金額の決済処理に係る情報を注文情報に含めて生成する。ここで、決済処理に係る情報は、例えば、電子マネーやクレジットカード情報等のキャッシュレス決済に係る情報であり、操作部15や図示しないリーダ装置等を介して入力される。そして、注文情報送信部112は、生成した注文情報をサーバ装置30に送信する。
サーバ装置30の注文情報受信部312は、受信手段及び管理手段の一例である。注文情報受信部312は、ユーザ端末10から商品の注文を受け付ける。
具体的には、注文情報受信部312は、ユーザ端末10の各々から送信される注文情報を受信する。また、注文情報受信部312は、注文情報を受信する毎に注文IDを発行し、受信した注文情報に含まれる各種情報を、決済用テーブル3531及び店舗用テーブル3532に登録する。
より詳細には、注文情報受信部312は、発行した注文IDと、注文情報を受け付けた受付日時とに関連付けて、注文情報に含まれた端末ID、店舗ID、金額(合計金額)等の情報を決済用テーブル3531に登録する。また、注文情報受信部312は、発行した注文IDと、注文情報を受け付けた受付日時とに関連付けて、注文情報に含まれた店舗ID、商品ID、単価、個数、及び小計等の情報を店舗用テーブル3532に登録する。
サーバ装置30の決済処理部313は、決済処理手段の一例である。決済処理部313は、ユーザ端末10から送信される決済処理に係る情報に基づいて注文された商品の決済処理を実行する。
具体的には、決済処理部313は、注文情報受信部312が注文情報を受信すると、その注文情報に含まれた決済処理に係る情報に基づいて決済処理を実行する。また、決済処理部313は、外部の決済用サーバ等にアクセスし、注文情報に含まれた決済処理に係る情報を用いて合計金額分の決済処理を実行する。
なお、決済処理部313は、報知処理部316と協働することで、注文情報を送信したユーザ端末10宛に、決済処理の処理結果(成功又は失敗)を報知するメッセージ等を通知してもよい。また、決済処理部313は、決済処理が失敗した場合、決済用テーブル3531及び店舗用テーブル3532に登録された注文を削除又は無効化することで、注文内容が店舗に通知されないよう制御する。
サーバ装置30の注文処理部314は、通知手段の一例である。注文処理部314は、注文情報受信部312が受け付けた注文の注文内容を、注文先の店舗の店舗端末20に通知する。
具体的には、注文処理部314は、注文情報受信部312が受信した注文情報に含まれる商品の注文内容を注文先の店舗(店舗端末20)に送信する。より詳細には、注文処理部314は、注文情報に含まれた店舗IDに対応する店舗端末20宛に、注文情報受信部312が発行した注文IDと、その店舗IDに関連付けられた商品ID、単価、個数及び小計等を含んだ注文内容を送信する。そして、注文処理部314は、注文内容の送信が正常に完了すると、決済用テーブル3531に記憶された、その注文内容に係る注文ID及び店舗IDの条件に該当するステータスを「注文完了」に設定する。なお、注文処理部314は、報知処理部316と協働することで、注文情報を送信したユーザ端末10宛に、注文が完了したことを報知するメッセージ等を通知してもよい。
店舗端末20の注文受付部211は、サーバ装置30から通知される自店舗宛の注文内容を受け付ける。具体的には、注文受付部211は、サーバ装置30から注文内容を受信すると、その注文内容に含まれる商品ID、個数等の情報を注文ID毎に表示部24に表示させる。つまり、注文受付部211は、注文された商品のリスト(以下、注文リストともいう)を注文ID単位で出力する。
これにより、店舗端末20が置かれた店舗では、表示部24に表示された注文リストを確認することで、全体の注文状況等を把握することができる。なお、注文受付部211は、商品IDをメニュー名に変換して出力してもよい。また、注文受付部211は、図示しない印刷装置を用いて、注文リストを注文ID単位で出力する構成としてもよい。
店舗端末20のステータス通知部212は、操作部25を介して入力される操作内容に基づいて、注文に対する処理状況を示すステータス情報をサーバ装置30に通知する。具体的には、ステータス通知部212は、注文リストに対して行われる操作内容に基づき、その操作内容に応じたステータス情報をサーバ装置30に通知する。
例えば、ステータス通知部212は、特定の注文リストに対し調理開始の操作を受け付けると、操作された注文リストに対応する注文IDと、店舗IDと、調理中を示す情報とを含んだステータス情報を生成し、サーバ装置30に送信する。また、例えば、ステータス通知部212は、特定の注文リストに対し調理完了の操作を受け付けると、操作された注文リストに対応する注文IDと、店舗IDと、調理完了を示す情報とを含んだステータス情報を生成し、サーバ装置30に送信する。また、例えば、ステータス通知部212は、特定の注文リストに対し受取完了(引渡完了)の操作を受け付けると、操作された注文リストに対応する注文IDと、店舗IDと、受取完了を示す情報とを含んだステータス情報を生成し、サーバ装置30に送信する。
なお、例えば、調理開始の操作の際に、調理完了までの予測時間が入力される構成の場合には、ステータス通知部212は、入力された予測時間をステータス情報に含めて送信してもよい。
サーバ装置30のステータス管理部315は、取得手段及び管理手段の一例である。ステータス管理部315は、注文情報受信部312が受け付けた注文を、当該注文に対する店舗の処理状況と関連付けて管理する。
具体的には、ステータス管理部315は、店舗端末20から通知されるステータス情報を取得し、当該ステータス情報に基づいて、決済用テーブル3531に記憶された該当する注文のステータスを更新する。より詳細には、ステータス管理部315は、店舗端末20からステータス情報を取得すると、そのステータス情報に含まれた注文ID及び店舗IDの条件に該当するエントリを決済用テーブル3531から検索する。そして、ステータス管理部315は、検索したエントリに含まれるステータスに、ステータス情報で指示された調理中や調理完了、受取完了等を示す情報を格納(上書き)する。
これにより、決済用テーブル3531のステータスには、注文された商品が店舗で引き渡されるまでに行われる一連の処理工程を示す情報、つまり「注文完了」→「調理中」→「調理完了」→「受取完了」が順次格納されることになる。
サーバ装置30の報知処理部316は、報知手段の一例である。報知処理部316は、ステータス管理部315が調理完了を示すステータス情報を取得した場合に、注文した商品の受け取りが可能となったことをユーザ端末10に報知する。
具体的には、報知処理部316は、決済用テーブル3531のステータスに応じて、ユーザ端末10に各種の報知を行う。より詳細には、報知処理部316は、ステータスが「調理完了」に変更されると、そのステータスが関連付けられた端末IDを特定する。そして、ステータス管理部315は、特定した端末IDのユーザ端末10宛に、「調理完了」のステータスとなった店舗ID(又は店舗名)や商品ID(又はメニュー名)、商品の受け取りを指示するメッセージ等を含んだ報知情報を送信する。報知情報の送信方法は特に問わず、例えばSMS(ショートメッセージサービス)等を用いて送信してもよい。
また、報知処理部316は、上述した「調理開始」以外でも、ユーザ端末10に報知を行ってもよい。例えば、報知処理部316は、ステータスが「調理中」に変更された場合に、調理中を示すメッセージ等を含んだ報知情報を送信してもよい。またこの場合、店舗端末20からのステータス情報に調理完了までの予測時間が含まれているのであれば、報知処理部316は、調理完了までの予測時間を報知情報に含めて送信してもよい。
ユーザ端末10の報知動作部113は、サーバ装置30から報知情報が送信されると、表示部14や音声出力部16を用いて報知を行う。具体的には、報知動作部113は、報知情報の内容を表示部14に表示することで、調理が完了した旨や、調理が開始された旨をユーザに報知する。また、報知動作部113は、音声出力部16からブザー音等の音声を出力させることで、報知情報を受信したことをユーザに報知する。これにより、ユーザ端末10を操作するユーザは、報知動作部113による報知により、通門した商品を店舗で受け取るタイミングや、商品の調理状況を把握することができる。
上述したように、注文システム1では、ユーザ端末10を介して商品の注文及び決済を行うことができる。したがって、ユーザは、商品の注文を簡便に行うことができる。
ところで、フードコートを利用するユーザは、ユーザ端末10を操作して商品を注文した後、調理完了の報知(連絡)があるまでの間、フードコート内に設けられた共用席等にて待機することになる。また、ユーザは、調理完了の連絡に応じて店舗に移動し、注文した商品を受け取った後、共用席に戻って飲食を行うことになる。このように、ユーザは、比較的長い時間の間、フードコート内に滞在することになる。
そのため、フードコート内に滞在する間、CM等のコンテンツデータをユーザに提供することで待ち時間の負担軽減や販促等を行うことが考えられるが、不用意にコンテンツデータを提供するだけでは、かえってユーザの負担になる可能性がある。
そこで、本実施形態の注文システム1では、各ユーザが注文した商品の処理状況に応じて、提供するコンテンツデータを切り替えることが可能な構成を有している。具体的には、サーバ装置30は、コンテンツデータの提供に係る機能部としてコンテンツ提供部317を備えている。
コンテンツ提供部317は、コンテンツ提供手段の一例である。コンテンツ提供部317は、決済用テーブル3531に記憶された各注文のステータスに基づき、当該ステータスに対応するコンテンツデータを注文元のユーザ端末10に提供する。
具体的には、コンテンツ提供部317は、決済用テーブル3531に記憶された注文ID毎に、その注文IDに関連付けられたステータスを特定する。次いで、コンテンツ提供部317は、特定したステータスに対応するコンテンツデータをコンテンツ管理テーブル354から読み出す。例えば、コンテンツ提供部317は、ステータスが「調理中」の場合、コンテンツ管理テーブル354から第2コンテンツデータを読み出す。
なお、例えば一度の注文で複数の店舗の商品が注文された場合で、且つ店舗毎に処理状況が異なる場合、同一の注文IDに関連付けて異なるステータスが保持されることになる(図5の注文ID「注文02」のステータス参照)。このような場合、コンテンツ提供部317は、ステータスの各々に対応するコンテンツデータを読み出してもよいし、何れか一つのステータスに対応するコンテンツデータを読み出してもよい。後者の場合、例えばコンテンツ提供部317は、上述した一連の処理工程のうち、時系列的に先又は後のステータスに対応するコンテンツデータを読み出すようにしてもよい。
続いて、コンテンツ提供部317は、注文IDに対応する端末IDを決済用テーブル3531から特定する。そして、コンテンツ提供部317は、特定した端末IDに対応するユーザ端末10宛に、コンテンツ管理テーブル354から読み出したコンテンツデータを提供する。
一方、ユーザ端末10のコンテンツ表示部114は、サーバ装置30から提供されたコンテンツデータを取得すると、当該コンテンツデータに基づく画面を表示部14に表示させる。例えば、コンテンツ表示部114は、動画や静止画のコンテンツデータを取得した場合、そのコンテンツデータが表す動画又は静止画を表示部14に表示させる。また、コンテンツ表示部114は、URL等のアクセス先を示すコンテンツデータを取得した場合、そのアクセス先にアクセスすることで、当該アクセス先から提供されるデータ(例えばライブ動画)等を表示部14に表示させる。
なお、コンテンツ表示部114は、コンテンツデータの表示を自動で行ってもよいし、ユーザから表示が指示された場合に表示を行う形態としてもよい。例えば、後者の場合、報知情報がプッシュ型で提供されるのに対し、コンテンツデータがプル型で提供される形態としてもよい。
図9は、コンテンツ提供部317が注文のステータスに応じて提供するコンテンツデータの一例を示す図である。なお、図9では、上述した4つのステータスを含む処理工程を時系列順に表しており、図中左方から右方にかけて処理が進行する。
まず、注文のステータスが「注文完了」の状態では、ユーザは商品の注文をし終えた直後の状態と考えられる。かかる状況下では、注文のし忘れや、注文後に合流したユーザの要望等により、商品の追加注文が行われる可能性がある。そこで、例えば、ステータス「注文完了」に関連付けて、フードコート内で販売される各種商品のCMを第1コンテンツデータとしてコンテンツ管理テーブル354に格納することで、追加注文の候補となる商品のCMをユーザ端末10に提供することができる。
具体的には、コンテンツ提供部317は、処理対象の注文IDのステータスが「注文完了」の場合、図9に示すように、このステータスに関連付けて記憶された第1コンテンツデータ(商品のCM等)をコンテンツ管理テーブル354から読み出し、ユーザ端末10に提供する。これにより、ユーザ端末10では、ステータスが「注文完了」の間、商品のCMが表示されるため、商品の販促を効率的に行うことができ、商品購入の機会の増加を図ることができる。
なお、第1コンテンツデータで宣伝する商品は特に問わず、例えば新商品等の予め定められた商品であってもよいし、注文された商品の内容等に基づいて自動で決定してもよい。後者の場合、例えばコンテンツ提供部317は、注文された商品の内容から追加注文の候補となる候補商品を決定し、第1コンテンツデータとして予め記憶された複数の商品のCMの中から、候補商品のCMを読み出す構成としてもよい。この場合、候補商品は、例えば注文された商品と一緒に購入される可能性(頻度)の高い商品等とすることができる。
また、ステータスが「調理中」の状態では、ユーザは上述した報知動作部113の報知により調理が開始されたことや、調理が完了するまでの予測時間等を把握することができる。しかしながら、どのような環境で調理されているのかは不明であるため、ユーザが不安を覚える可能性がある。
そこで、例えば、ステータス「調理開始」に関連付けて、各店舗の厨房等を撮影するライブ動画の配信先(URL等)を第2コンテンツデータとしてコンテンツ管理テーブル354に格納することで、調理環境を表すコンテンツデータをユーザ端末10に提供することができる。
具体的には、コンテンツ提供部317は、処理対象の注文IDのステータスが「調理中」の場合に、その注文IDに対応する店舗IDを決済用テーブル3531から特定する。そして、コンテンツ提供部317は、図9に示すように、特定した店舗ID用の第2コンテンツデータ(ライブ動画)をコンテンツ管理テーブル354から読み出し、ユーザ端末10に配信する。これにより、ユーザ端末10では、ステータスが「調理中」の間、ユーザが注文した商品の調理環境を表示することができるため、調理を待つ間のユーザの不安を軽減させることができる。
また、ステータスが「調理完了」の状態では、ユーザは上述した報知動作部113の報知により、注文した商品を受け取るため店舗に移動する必要があることを認識することができる。しかしながら、フードコート内には複数の店舗が存在しており、またユーザ端末10を介して注文を行っているため、ユーザは、商品の受け取り先となる店舗の場所が分からない可能性がある。
そこで、例えば、ステータス「調理完了」に関連付けて、フードコート内での各店舗の存在位置を案内する動作データやマップデータ等を第3コンテンツデータとしてコンテンツ管理テーブル354に格納することで、店舗までの道案内となるコンテンツデータをユーザ端末10に提供することができる。
具体的には、コンテンツ提供部317は、処理対象の注文IDのステータスが「調理完了」の場合に、その注文IDに対応する店舗IDを決済用テーブル3531から特定する。そして、コンテンツ提供部317は、図9に示すように、特定した店舗ID用の第3コンテンツデータ(マップデータ)をコンテンツ管理テーブル354から読み出し、ユーザ端末10に配信する。これにより、ユーザ端末10では、ステータスが「調理完了」の間、商品の受け取り先となる店舗の位置を案内するコンテンツデータを表示することができるため、利便性の向上を図ることができる。
なお、コンテンツ提供部317は、第3コンテンツデータとともに、調理を完了した商品を受け取る際に店員に提示するコード情報(一次元コード又は二次元コード)を提供してもよい。コード情報は、ステータス情報とともに店舗端末20から送信されてもよいし、コンテンツ提供部317等が生成したものであってもよい。例えば、コード情報は、顧客が注文した商品の注文ID又は調理が完了した商品IDをコード化したものであってもよい。
顧客は表示されたマップに従い店舗へ向かい、店員にコード情報を見せる。店員は店舗端末20に接続されたスキャナなどの装置でコード情報を読取り、顧客がどの商品を取りに来たかを把握する。なお、店舗端末20のステータス通知部212は、コード情報の読取りをトリガに、受取完了のステータス情報をサーバ装置30に送信する形態としてもよい。
なお、ユーザ端末10のコンテンツ表示部114は、ユーザ端末10が有するGPS機能等と連携することで、顧客が対象となる店舗に到達した際にコード情報を自動で表示してもよい。また、コンテンツ表示部114は、表示されているコンテンツ情報に関わらずユーザ端末のタッチパネルにボタンを表示して手動でコード情報を表示できるようにしてもよい。
また、上述したユーザ端末10に対するコード情報の提供は、サーバ装置30の報知処理部316が行う形態としてもよい。この場合、ユーザ端末10の報知動作部113は、報知情報として送信されたコード情報を表示部14に表示させるものとする。
また、ステータスが「受取完了」の状態では、ユーザは受け取った商品を共用席まで運び、飲食を開始することが予測される。この場合、例えば、ステータス「受取完了」に関連付けて、フードコート以外の他店舗のCMや施設で催されるイベントのCM等を第4コンテンツデータとしてコンテンツ管理テーブル354に格納しておくことで、飲食後の行動の動機づけとなるコンテンツデータをユーザ端末10に提供することができる。
具体的には、コンテンツ提供部317は、処理対象の注文IDのステータスが「受取完了」の場合、図9に示すように、このステータスに対応する第4コンテンツデータ(例えば、ショッピングセンター内の他店舗のCM、ショッピングセンター内に設けられた映画館の上映情報、イベントホールのイベント情報等)をコンテンツ管理テーブル354から読み出し、ユーザ端末10に提供する。これにより、ユーザ端末10では、ステータスが「受取完了」の間、フードコート以外の他店舗や施設に係るCMが表示されるため、飲食後の行動をユーザに提案できるとともに、フードコート以外の販促や宣伝を効率的に行うことができる。
また、ステータスが「受取完了」の場合、上述した「注文完了」と同様に、追加注文の候補となる候補商品のCMを第4コンテンツデータとして格納する形態としてもよい。例えば、コンテンツ提供部317は、注文された商品の内容から食事が行われたと判定した場合に、食事の後に食されることの多いデザート等の商品のCMを選定して読み出す形態としてもよい。これにより、ユーザ端末10では、ステータスが「受取完了」の間、食事の後に食されることの多い商品のCMが表示されるため、追加注文に係るユーザの利便性を向上させるとともに、商品の購入機会の増加を図ることができる。
なお、上記したステータスの各期間において、コンテンツ提供部317がコンテンツデータの提供を開始するタイミングは特に問わず、任意に設定することが可能である。例えば、コンテンツ提供部317は、ステータスが変化したタイミングでコンテンツデータの提供を開始してもよい。また、コンテンツ提供部317は、ステータスが変化してから所定時間が経過したタイミングでコンテンツデータの提供を開始してもよい。
以下、図10を参照して、上述した注文システム1の動作例について説明する。図10は、注文システム1の動作の一例を示すシーケンス図である。
まず、ユーザ端末10のメニュー表示部111は、サーバ装置30にアクセスしメニュー情報を要求する(ステップS11)。サーバ装置30のメニュー提供部311は、ユーザ端末10からのアクセスに応じて、当該ユーザ端末10にメニュー情報を提供する(ステップS12)。
ユーザ端末10のメニュー表示部111は、サーバ装置30から提供されたメニュー情報に基づき、注文対象の商品を選択可能なメニュー画面を表示部14に表示させる(ステップS13)。ここで、ユーザの操作により、注文対象の商品や決済処理に係る情報が入力されると、ユーザ端末10の注文情報送信部112は、注文対象の商品の商品IDや決済処理に係る情報等を含んだ注文情報を生成し、サーバ装置30に送信する(ステップS14)。
サーバ装置30の注文情報受信部312は、サーバ装置30から商品の注文(注文情報)を受け付けると、この注文情報に含まれた内容を注文IDと関連付けて、決済用テーブル3531及び店舗用テーブル3532に登録する。
続いて、サーバ装置30の決済処理部313は、注文情報に含まれた決済処理に係る情報に基づいて決済処理を実行する(ステップS15)。サーバ装置30の注文処理部314は、ステップS15の決済処理が正常に完了すると、注文情報に含まれた注文内容を注文先の店舗の店舗端末20に通知する(ステップS16)。そして、サーバ装置30の注文処理部314は、ステップS16で注文内容を通知した注文に係るステータスを「注文完了」に設定する(ステップS17)。なお、ステップS17の処理は、ステータス管理部315が行う形態としてもよい。
続いて、サーバ装置30のコンテンツ提供部317は、ステップS17で設定されたステータス(注文完了)に対応する第1コンテンツデータをコンテンツ管理テーブル354から読み出し、ユーザ端末10に提供する(ステップS18)。そして、ユーザ端末10のコンテンツ表示部114は、サーバ装置30から提供された第1コンテンツデータに基づく画面を表示部14に表示させる(ステップS19)。
一方、店舗端末20の注文受付部211は、サーバ装置30から注文内容の通知を受け付けると、その注文内容を表示部24に表示させ、注文を受け付けたことを店員に報知する(ステップS20)。そして、ステータス通知部212は、特定の注文(注文ID)に対する調理開始の操作を受け付けると(ステップS21)、当該注文の調理開始を指示したステータス情報をサーバ装置30に送信する(ステップS22)。
サーバ装置30のステータス管理部315は、店舗端末20から特定の注文について調理開始を指示したステータス情報を受信すると、該当する注文に係るステータスを「調理中」に変更する(ステップS23)。
これに伴い、サーバ装置30のコンテンツ提供部317は、ステップS23で設定されたステータス(調理中)に対応する第2コンテンツデータをコンテンツ管理テーブル354から読み出し、ユーザ端末10に提供する(ステップS24)。そして、ユーザ端末10のコンテンツ表示部114は、サーバ装置30から提供された第2コンテンツデータに基づく画面を表示部14に表示させる(ステップS25)。
また、店舗端末20のステータス通知部212は、調理開始に続く操作として、特定の注文(注文ID)に対する調理完了の操作を受け付けると(ステップS26)、当該注文の調理完了を指示したステータス情報をサーバ装置30に送信する(ステップS27)。
サーバ装置30のステータス管理部315は、店舗端末20から特定の注文について調理完了を指示したステータス情報を受信すると、該当する注文に係るステータスを「調理完了」に変更する(ステップS28)。
これに伴い、サーバ装置30の報知処理部316は、注文元のユーザ端末10に報知情報を送信する(ステップS29)。ユーザ端末10の報知動作部113は、サーバ装置30から送信された報知情報に基づき、表示部14や音声出力部16を用いて報知を行う(ステップS30)。
また、サーバ装置30のコンテンツ提供部317は、ステップS28で設定されたステータス(調理完了)に対応する第3コンテンツデータをコンテンツ管理テーブル354から読み出し、ユーザ端末10に提供する(ステップS31)。そして、ユーザ端末10のコンテンツ表示部114は、サーバ装置30から提供された第3コンテンツデータに基づく画面を表示部14に表示させる(ステップS32)。
ユーザ端末10を操作するユーザは、ステップS29及びステップS31の処理により、注文した商品が受け取り可能な状態になったことを認識する。そして、ユーザは、注文した商品を受け取るため店舗へと移動する。
そして、店舗端末20のステータス通知部212は、調理完了に続く操作として、特定の注文(注文ID)に対する受取完了の操作を受け付けると(ステップS33)、当該注文の受取完了を指示したステータス情報をサーバ装置30に送信する(ステップS34)。なお、ステップS33で、受取完了の操作の際に入力される注文IDは、上述したコード情報の読み取りによって入力される形態としてもよい。
サーバ装置30のステータス管理部315は、店舗端末20から特定の注文について受取完了を指示したステータス情報を取得すると、該当する注文に係るステータスを「受取完了」に変更する(ステップS35)。
これに伴い、サーバ装置30のコンテンツ提供部317は、ステップS35で設定されたステータス(調理中)に対応する第4コンテンツデータをコンテンツ管理テーブル354から読み出し、ユーザ端末10に提供する(ステップS36)。そして、ユーザ端末10のコンテンツ表示部114は、サーバ装置30から提供された第4コンテンツデータに基づく画面を表示部14に表示させる(ステップS37)。
以上のように、サーバ装置30は、ユーザ端末10から商品の注文を受け付けると、受け付けた注文の注文内容を、注文対象の商品を販売する店舗の店舗端末20に通知するとともに、受け付けた注文を当該注文に対する店舗の処理状況と関連付けて管理する。そして、サーバ装置30は、処理状況に対応するコンテンツデータを注文元のユーザ端末10に提供する。
これにより、サーバ装置30は、注文の処理状況に対応するコンテンツデータをユーザに提供することができるため、注文された商品の処理状況に応じて提供するコンテンツデータを変更することができる。また、これにより、サーバ装置30は、各処理状況下におけるユーザの状態に適したコンテンツデータを提供することができるため、商品の販促やユーザ支援等を適切なタイミングで行うことができる。
また、サーバ装置30は、注文に対する処理状況を店舗端末20から取得し、この取得結果が変化する毎に、決済用テーブル3531のステータスを更新する。これにより、サーバ装置30では、店舗で実施される注文に対する処理状況をリアルタイムで反映することができるため、実際の処理状況に即したコンテンツデータをユーザ端末10に提供することができる。
また、サーバ装置30は、店舗端末20から処理状況として、注文された商品の調理開始(又は製造開始)と調理完了(又は製造完了)とを示す処理状況を少なくとも取得し、調理開始と調理完了とで提供するコンテンツデータを相違させる。これにより、サーバ装置30は、調理開始と調理完了との処理状況下において、ユーザの状態に適したコンテンツデータを提供することができるため、商品の販促やユーザ支援等を適切なタイミングで行うことができる。
また、サーバ装置30は、調理完了を示す処理状況を取得した場合に、注文した商品が受け取り可能となったことをユーザ端末10に報知する。これにより、サーバ装置30は、注文した商品の受け取りをユーザに促すことができるため、ユーザの利便性を向上させるとともに、フードコートの利用に係る効率性を向上させることができる。
また、サーバ装置30は、複数段階に区分された処理状況の種別と、処理状況の種別毎に用意されたコンテンツデータとを関連付けて記憶するコンテンツ管理テーブル354から、注文の処理状況に対応するコンテンツデータを読み出し、注文元のユーザ端末10に提供する。これにより、サーバ装置30では、コンテンツ管理テーブル354に格納するコンテンツデータを変更することで、様々なコンテンツをユーザ端末10に提供することができる。したがって、サーバ装置30では、コンテンツデータの管理を容易に行うことができる。
また、サーバ装置30では、フードコート内の各店舗が販売する商品の各々を示したメニュー情報をユーザ端末10に提供し、当該メニュー情報に基づいて選択された商品の注文を受け付ける。これにより、サーバ装置30は、フードコート全体で販売される商品の注文を統括して受け付けることができるため、複数の店舗で販売される商品を一度の注文で受け付けることができる。したがって、サーバ装置30は、商品の注文に係るユーザの利便性を向上させることができるとともに、各店舗で販売される商品の購入機会の増加を図ることができる。
なお、上述した実施形態は、上述した各装置が有する構成又は機能の一部を変更することで、適宜に変形して実施することも可能である。そこで、以下では、上述した実施形態に係るいくつかの変形例を他の実施形態として説明する。なお、以下では、上述した実施形態と異なる点を主に説明することとし、既に説明した内容と共通する点については詳細な説明を省略する。また、以下で説明する変形例は、個別に実施されてもよいし、適宜組み合わせて実施されてもよい。
(変形例1)
上述の実施形態では、注文システム1(サーバ装置30)をフードコートに適用した場合の形態を説明したが、これに限らないものとする。例えば、インターネットを介して自宅から商品(飲食物)を注文し、調理が完了した商品を店舗にて受け取るような販売方式の注文システムに適用してもよい。
また、上述の実施形態では、注文の対象となる商品も飲食物としたが、これに限らず、店舗において製造や加工等の処理が発生するものであれば、その種別は特に問わないものとする。
(変形例2)
上述の実施形態では、商品の注文から受け取りに至るまでの一連する処理工程を、「注文完了」、「調理中」、「調理完了」及び「受取完了」の4つのステータスで表す例を説明した。しかしながら、処理工程の分割数や種別はこれに限らないものとする。なお、処理工程の分割数や種別は、注文の対象となる商品や、各ステータス下におかれるユーザの状態に応じて決定することが好ましい。
(変形例3)
上述の実施形態では、商品の受け取りを注文ID毎に管理する形態を説明したが、これに限らずに商品ID毎に管理する形態としてもよい。この場合、第3コンテンツデータとして提供するコード情報には、注文IDとともに商品IDを含めることが好ましい。
上述の実施形態の各装置で実行されるプログラムは、ROM等に予め組み込まれて提供される。上述の実施形態の各装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでCD-ROM、フレキシブルディスク(FD)、CD-R、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。
さらに、上述の実施形態の各装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上述の実施形態の各装置で実行されるプログラムをインターネット等のネットワーク経由で提供又は配布するように構成してもよい。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更、組み合わせを行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。