JP6968332B1 - 注文管理装置、注文管理プログラム、及び注文管理方法 - Google Patents

Abstract

【課題】複数の異なるフードデリバリーサービスシステムまたはテイクアウトサービスシステムを介して受け付けた商品の注文を一元管理する技術を提供する。【解決手段】 注文管理装置は、ユーザ端末から通信ネットワークを介して、フードデリバリーサービスまたはテイクアウトサービスを提供するフードサービスメディアの情報処理システムであって複数の異なるフードサービスメディアの情報処理システムそれぞれから、特定の店舗の商品に対する第１注文情報であって各フードサービスメディアの情報処理システムのデータフォーマットに応じた第１注文情報を取得する取得部と、第１注文情報のデータフォーマットを第１共通フォーマットに変換する変換部と、第１共通フォーマットに変換された第１注文情報である第２注文情報を一元的に表示させる表示制御部と、を備えることにより、上記課題の解決を図る。【選択図】図１

Description

本発明は、注文管理装置、注文管理プログラム、及び注文管理方法に関する。

従来、店舗内での飲食がメインであったが、新型コロナウィルス感染症の拡大により、外食を控えて自宅等で食事をする機会が増加している。このような社会情勢の変化により、客がスマートフォンのアプリケーションソフトウェア（いわゆる「アプリ」）やインターネットから料理の注文及びその配達を依頼できるフードデリバリーサービスが注目を集めている。

フードデリバリーサービスについて説明する。飲食店はいずれかのフードデリバリーサービスに加入すると、その飲食店のメニューが、その加入したフードデリバリーサービスのアプリで検索可能になる。ユーザは、検索した飲食店のメニューを選択して決済を済ませると、その注文情報が店舗に伝えられる。店舗側では、その注文情報に基づいて商品（料理）を準備し、準備完了後、フードデリバリーサービスにより提供された配達員にその商品を受け渡す。その商品を受け取った配達員は、配送先にその商品を配達する。

上記フードデリバリーサービスと併せて、客が専用Ｗｅｂサイトやアプリ等のオンラインで料理を予約（注文）し、予約した料理を店舗で受け取って持ち帰る、いわゆるテイクアウト型のサービス（以下、「テイクアウトサービス」と称する。）も注目が集まっている。

さて、店舗において、業務負担を軽減する技術が開示されている。例えば、第１の技術として、店舗管理者の業務負担軽く、受注伝票に対応した注文情報を業務ノウハウが反映されるように更新することができる注文情報更新技術が開示されている（例えば、特許文献１）。第１の技術では、注文情報更新サーバは、店舗端末を管理する店舗管理者から店舗端末への入力情報に基づく条件・更新内容情報を取得して記憶部に記憶させる条件・更新内容記憶手段と、前記記憶されている条件・更新内容情報に基づいて、ショッピングモールサーバに記憶されている注文情報又は注文情報管理サーバに記憶されている注文情報を更新させる更新処理を実行する注文情報更新手段と、を備える。

第２の技術として、複数の異なる業者について一元管理して容易に受発注できる技術がある（例えば、特許文献２）。第２の技術では、受発注システムは、複数の業種の訪問型サービスの受発注システムであって、サービス業者がサービスする物品および／またはサービスならびに訪問可能地域および期間を登録する手段と、サービス業者のスケジュールを表示および管理する手段と、ユーザが希望する地域、サービス、業種、業者、および／または日時を検索し、またはカテゴリーか選択した業者に対して可能な日時を入力して発注する手段と、サービス業者が発注を確認して受注確認を送信する手段と、決済手段および／または課金手段と、を備える。

第３の技術として、配送する料理の品質の維持と効率的な配送との両立ができる情報処理技術がある（例えば、特許文献３）。第３の技術では、コンピュータは、第１会員が操作する端末から第１料理の注文を示す第１注文を受信し、第１料理の調理と並行して調理可能な第２料理を決定し、第２料理の注文を促すための情報を生成し、第１会員と対応付けられた位置を取得し、第１会員と対応付けられた位置から所定の範囲内の位置に対応付けられる第２会員を特定し、生成した情報を第２会員が操作する端末へ送信する。

特許第６６９５６０２号 特開２０１９−０６１６７５号公報 特開２０１９−１８５７２７号公報

フードデリバリーサービス分野やテイクアウトサービス分野には、多くの企業が参入を始め、複数のフードデリバリーサービス及びテイクアウトサービスが存在する。店舗は、より多くの顧客からの注文を受けることができるように、複数のフードデリバリーサービスやテイクアウトサービスに加入することができる。

しかしながら、店舗側において、フードデリバリーサービス及びテイクアウトサービスは各社ごとまたは各メディアごと個別に受注管理画面等の管理画面が異なり、それぞれの画面を開いて確認する必要があり、その管理が煩雑で一元管理することができなかった。

そこで、本発明は、複数の異なるフードデリバリーサービスシステムまたはテイクアウトサービスシステムを介して受け付けた商品の注文を一元管理する技術を提供する。

本発明の一実施形態における注文管理装置は、ユーザにより操作されるユーザ端末から通信ネットワークを介して、商品としての料理の注文及び配達を受け付けるフードデリバリーサービスまたはテイクアウトするための前記商品の注文を受け付けるテイクアウトサービスを提供するフードサービスメディアの情報処理システムであって複数の異なるフードサービスメディアの情報処理システムそれぞれから、特定の店舗の前記商品に対する第１注文情報であって各フードサービスメディアの情報処理システムのデータフォーマットに応じた前記第１注文情報を取得する取得部と、前記第１注文情報のデータフォーマットを第１共通フォーマットに変換する変換部と、前記第１共通フォーマットに変換された前記第１注文情報である第２注文情報を一元的に表示させる画面であって、前記第２注文情報それぞれに対して、当該第２注文情報が前記ユーザによって確認されたか否かの第１ボタンと、当該第２注文情報に対応する注文された商品の受け渡しが済んだか否かの第２ボタンを含む前記画面を、前記ユーザ端末の表示部に表示させる表示制御部と、前記第１ボタンの押下に応じて、第２注文情報が前記ユーザによって確認されたか否かのステータスを示す第１ステータス情報を更新し、前記第２ボタンの押下に応じて、当該第２注文情報に対応する注文された商品の受け渡しが済んだか否かのステータスを示す第２ステータス情報を更新するステータス管理部と、一定期間ごとにまたは所定のタイミングで、前記ユーザ端末の画面に表示された前記第２注文情報それぞれの前記第１ステータス情報と前記第２ステータス情報のステータスの判定を行う判定部と、を備え、前記表示制御部は、前記判定の結果に応じて、未確認または前記注文された商品の受け渡しが済んでいない注文がある旨のメッセージを表示させることを特徴とする。

前記ステータス管理部は、いずれかの前記第２注文情報の前記第１ボタンが押下された場合、当該いずれかの前記第２注文情報の第１ステータス情報を、当該第２注文情報が前記ユーザによって確認された旨のステータスに更新し、いずれかの前記第２注文情報の前記第２ボタンが押下された場合、当該いずれかの前記第２注文情報の第２ステータス情報を、当該第２注文情報に対応する注文された商品の受け渡しが済んだ旨のステータスに更新し、さらに、前記第２注文情報は、調理が完了したか否かのステータスを示す第３ステータス情報を含み、前記表示制御部は、さらに、前記第１ステータス情報が前記ユーザによって確認された旨のステータスに更新されてから所定時間経過した前記第２注文情報の前記第３ステータス情報が調理が完了していない旨を示す場合、前記調理が済んでいない注文がある旨のメッセージを表示させ、前記第３ステータス情報が前記調理が完了した旨のステータスに更新されてから所定時間経過した前記第２注文情報の前記第２ステータス情報が前記注文された商品の受け渡しが済んでいない旨を示す場合、調理済みの注文が受け渡されていない旨のメッセージを表示させることを特徴とする。

前記表示制御部は、さらに、一元的に表示させた前記第２注文情報を、前記フードサービスメディアの情報処理システム毎に、表示させることを特徴とする。

前記注文管理装置は、さらに、前記特定の店舗における端末装置から所定の要求を取得した場合、前記所定の要求に対応する指示を、前記複数の異なるフードサービスメディアの情報処理システムに送信する指示送信部を備えることを特徴とする。

前記取得部は、さらに、ユーザにより操作されるユーザ端末から通信ネットワークを介して、現実のまたは仮想的な店舗の席の予約を受け付ける予約サービスメディアの情報処理システムであって複数の異なる予約サービスメディアの情報処理システムそれぞれから、特定の店舗の席の予約に関する第１予約情報であって各予約サービスメディアの情報処理システムのデータフォーマットに応じた前記第１予約情報を取得し、前記変換部は、前記第１予約情報が取得された場合、前記第１予約情報のデータフォーマットを第２共通フォーマットに変換し、前記表示制御部は、前記第２共通フォーマットに変換された前記第１予約情報である第２予約情報を一元的に表示させることを特徴とする。

本発明の他の実施形態における注文管理プログラムは、コンピュータに、ユーザにより操作されるユーザ端末から通信ネットワークを介して、商品としての料理の注文及び配達を受け付けるフードデリバリーサービスまたはテイクアウトするための前記商品の注文を受け付けるテイクアウトサービスを提供するフードサービスメディアの情報処理システムであって複数の異なるフードサービスメディアの情報処理システムそれぞれから、特定の店舗の前記商品に対する第１注文情報であって各フードサービスメディアの情報処理システムのデータフォーマットに応じた前記第１注文情報を取得する取得処理と、前記第１注文情報のデータフォーマットを第１共通フォーマットに変換する変換処理と、前記第１共通フォーマットに変換された前記第１注文情報である第２注文情報を一元的に表示させる画面であって、前記第２注文情報それぞれに対して、当該第２注文情報が前記ユーザによって確認されたか否かの第１ボタンと、当該第２注文情報に対応する注文された商品の受け渡しが済んだか否かの第２ボタンを含む前記画面を、前記ユーザ端末の表示部に表示させる表示制御処理と、前記第１ボタンの押下に応じて、第２注文情報が前記ユーザによって確認されたか否かのステータスを示す第１ステータス情報を更新し、前記第２ボタンの押下に応じて、当該第２注文情報に対応する注文された商品の受け渡しが済んだか否かのステータスを示す第２ステータス情報を更新するステータス管理処理と、一定期間ごとにまたは所定のタイミングで、前記ユーザ端末の画面に表示された前記第２注文情報それぞれの前記第１ステータス情報と前記第２ステータス情報のステータスの判定を行う判定処理と、
を実行させ、前記表示制御処理は、前記判定の結果に応じて、未確認または前記注文された商品の受け渡しが済んでいない注文がある旨のメッセージを表示させることを特徴とする。

本発明の他の実施形態における注文管理方法において、コンピュータがユーザにより操作されるユーザ端末から通信ネットワークを介して、商品としての料理の注文及び配達を受け付けるフードデリバリーサービスまたはテイクアウトするための前記商品の注文を受け付けるテイクアウトサービスを提供するフードサービスメディアの情報処理システムであって複数の異なるフードサービスメディアの情報処理システムそれぞれから、特定の店舗の前記商品に対する第１注文情報であって各フードサービスメディアの情報処理システムのデータフォーマットに応じた前記第１注文情報を取得し、前記第１注文情報のデータフォーマットを第１共通フォーマットに変換し、前記第１共通フォーマットに変換された前記第１注文情報である第２注文情報を一元的に表示させる画面であって、前記第２注文情報それぞれに対して、当該第２注文情報が前記ユーザによって確認されたか否かの第１ボタンと、当該第２注文情報に対応する注文された商品の受け渡しが済んだか否かの第２ボタンを含む前記画面を、前記ユーザ端末の表示部に表示させ、前記第１ボタンの押下に応じて、第２注文情報が前記ユーザによって確認されたか否かのステータスを示す第１ステータス情報を更新し、前記第２ボタンの押下に応じて、当該第２注文情報に対応する注文された商品の受け渡しが済んだか否かのステータスを示す第２ステータス情報を更新し、一定期間ごとにまたは所定のタイミングで、前記ユーザ端末の画面に表示された前記第２注文情報それぞれの前記第１ステータス情報と前記第２ステータス情報のステータスの判定を行い、前記判定の結果に応じて、未確認または前記注文された商品の受け渡しが済んでいない注文がある旨のメッセージを表示させることを特徴とする。

本発明によれば、複数の異なるフードデリバリーサービスシステムまたはテイクアウトサービスシステムを介して受け付けた商品の注文を一元管理することができる。

本発明の実施形態における注文管理装置の概要を説明する図である。 本実施形態における注文管理システムの全体構成の一例を示す図である。 本実施形態における注文管理システムの機能ブロック図である。 本実施形態における注文管理サーバ１２により管理されているデータベースのデータ構造の一例を示す図である。 本実施形態における店舗端末に表示されるテイクアウト・デリバリー注文管理画面（簡易表示）の表示例を示す図である。 本実施形態における店舗端末に表示されるテイクアウト・デリバリー注文管理画面（詳細表示）の表示例を示す図である。 本実施形態におけるメッセージ画面の表示例を示す図である。 本実施形態におけるメニュー情報登録時のシーケンス図である。 本実施形態におけるデリバリー／テイクアウト一時停止処理のシーケンス図である。 本実施形態におけるデリバリーまたはテイクアウトする飲食物の注文時のシーケンス図である。 本実施形態におけるデリバリー／テイクアウト一元管理処理の詳細を示すフローチャートである。 本実施形態におけるステータスチェック処理の詳細なフローチャートを示す図である。 本実施形態の他の実施例における注文管理システムの全体構成の一例を示す図である。 本実施形態の他の実施例における複数のブランドの店舗の予約を管理する予約一元管理画面の一例を示す図である。 本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。

図１は、本発明の実施形態における注文管理装置の概要を説明する図である。注文管理装置１の一例として、後述する注文管理サーバ１２が挙げられる。注文管理装置１は、取得部２、変換部３、表示制御部４を含む。

取得部２は、複数の異なるフードサービスメディアの情報処理システムそれぞれから、特定の店舗の商品に対する第１注文情報であって各フードサービスメディアの情報処理システムのデータフォーマットに応じた第１注文情報を取得する。ここで、フードサービスメディアの情報処理システムは、ユーザにより操作されるユーザ端末から通信ネットワークを介して、商品としての料理の注文及び配達を受け付けるフードデリバリーサービスまたはテイクアウトするための前記商品の注文を受け付けるテイクアウトサービスを提供する情報処理システムである。第１注文情報は、例えば、各フードサービスメディアの情報処理システムから取得されるオリジナルの注文情報である。取得部２の一例として、後述する取得部２２が挙げられる。フードサービスメディアの情報処理システムの一例として、後述するＦＤＳサーバ１３が挙げられる。

変換部３は、第１注文情報のデータフォーマットを第１共通フォーマットに変換する。第１共通フォーマットの一例として、例えば、注文管理データベース（ＤＢ）のデータ項目が挙げられる。変換部３の一例として、後述する注文管理部２３が挙げられる。

表示制御部４は、第１共通フォーマットに変換された第１注文情報である第２注文情報を一元的に表示させる。表示制御部４の一例として、後述する表示制御部２４が挙げられる。

このように構成することにより、複数の異なるフードデリバリーサービスシステムまたはテイクアウトサービスシステムを介して受け付けた商品の注文を一元管理することができる。

また、第２注文情報は、特定の店舗において第２注文情報が確認されたか否か及び第２注文情報に対応する注文された商品の受け渡しが済んだか否かのステータス情報を含んでもよい。この場合、注文管理装置１は、さらに、判定部５を含む。判定部５は、一定期間ごとにまたは所定のタイミングで、一元的に表示させた第２注文情報のステータス情報を判定する。判定部５の一例として、後述する注文管理部２３が挙げられる。表示制御部は、ステータス情報の判定結果に応じて、所定のメッセージを表示させる。例えば、ステータス情報が第２注文情報がまだ確認されていない旨を示す場合、所定のメッセージとして、未確認の第２注文情報を確認するように促すようなメッセージであってもよい。また、例えば、ステータス情報が、第２注文情報に対応する注文された商品の受け渡しが済んでいない旨を示す場合、所定のメッセージとして、第２注文情報に対応する注文された商品の受け渡しが済んでいない旨を通知するようなメッセージであってもよい。

このように構成することにより、店舗担当者に、注文の確認忘れや、商品の受け渡し忘れがないように注意を促すことができると共に、迅速な注文の処理及び配達の手配を行うことができ、より早く注文主へ商品を届けることができる。

表示制御部４は、さらに、一元的に表示させた前記第２注文情報を、フードサービスメディアの情報処理システム毎に、表示させるようにしてもよい。

このように構成することにより、フードデリバリーサービスシステム毎の注文情報を管理しやすくすることができる。

注文管理装置１は、さらに、指示送信部６を含む。指示送信部６は、特定の店舗における端末装置から所定の要求を取得した場合、所定の要求に対応する指示を、複数の異なるフードサービスメディアの情報処理システムに送信してもよい。指示送信部６の一例として、後述する注文管理部２３や登録処理部２５、予約管理部１０２が挙げられる。所定の要求とは、例えば、デリバリーやテイクアウトの注文を一時的に停止する要求やメニューの更新要求、席の予約を一時的に停止する要求が挙げられる。

このように構成することにより、店舗担当者は、一括して、加入している全てのフードデリバリーサービスシステムに対して、デリバリーやテイクアウトの注文を一時的に停止させたり、メニューの一斉更新をしたり、席の予約を一時的に停止することができる。

取得部２は、さらに、複数の異なる予約サービスメディアの情報処理システムそれぞれから、特定の店舗の席の予約に関する第１予約情報であって各予約サービスメディアの情報処理システムのデータフォーマットに応じた第１予約情報を取得してもよい。予約サービスメディアの情報処理システムとは、ユーザにより操作されるユーザ端末から通信ネットワークを介して、現実のまたは仮想的な店舗の席の予約を受け付ける予約サービスメディアの情報処理システムである。予約サービスメディアの情報処理システムの一例として、後述する予約Ｗｅｂサイトが設置された予約Ｗｅｂサイトサーバまたは予約アプリに対応するサーバが挙げられる。

変換部３は、第１予約情報が取得された場合、第１予約情報のデータフォーマットを第２共通フォーマットに変換する。表示制御部４は、第２共通フォーマットに変換された前記第１予約情報である第２予約情報を一元的に表示させる。

このように構成することにより、１つの店舗で複数のブランドの飲食店を運営するバーチャルレストランや複数の実店舗の予約を一元的に管理することができる。

以下、図面を参照して、本発明の実施形態について説明する。

図２は、本実施形態における注文管理システムの全体構成の一例を示す図である。注文管理システム１１は、注文管理サーバ装置（以下、「注文管理サーバ」と称する。）１２、フードデリバリーサービス（ＦＤＳ）サーバ装置（以下、「ＦＤＳサーバ」と称する。）１３、店舗端末１４、ユーザ端末１５、及び通信ネットワーク１６を含む。注文管理サーバ１２、ＦＤＳサーバ１３、店舗端末１４、及びユーザ端末１５は、通信可能なように通信ネットワーク１６で接続されている。

ＦＤＳサーバ１３は、例えば、飲食店等の店舗の商品の注文の仲介と電子決済、及び注文主の指定する場所への注文商品の配達の指示・管理を行う。また、ＦＤＳサーバ１３は、テイクアウトサービスにも対応しており、飲食店等の店舗に対して、顧客からテイクアウトのための商品の予約（注文）を受け付けて、電子決済し、それを店舗側に伝える。ＦＤＳサーバ１３は、ＦＤＳ事業者毎に存在する。ＦＤＳサーバ１３の一例として、図２では、ＦＤＳサーバ１３ａ，１３ｂが示されている。ＦＤＳサーバ１３ａには、例えば、Ａ社によって提供されるＦＤＳのサーバシステムが設置されている。ＦＤＳサーバ１３ｂには、例えば、Ｂ社によって提供されるＦＤＳのサーバシステムが設置されている。ＦＤＳサーバ１３は、物理サーバであってもよいし、仮想サーバであってもよい。ＦＤＳサーバ１３は、例えば、ユーザ端末１５にインストールされた専用のアプリを介してユーザ端末１５と通信を行う。

注文管理サーバ１２は、複数のＦＤＳサーバ１３のそれぞれを介して行われる、例えば飲食店等の店舗が取り扱う商品の配達を実現するために用いられる情報処理装置である。注文管理サーバ１２は、インターネットのような通信ネットワーク１６を介して複数のＦＤＳサーバ１３と通信可能に接続される。図２においては複数のＦＤＳサーバ１３として便宜的に複数のＦＤＳサーバ１３ａ，１３ｂが示されているが、注文管理サーバ１２は、３以上のＦＤＳサーバ１３と通信可能に接続されても構わない。

店舗端末１４は、店舗で使用される情報処理端末装置であり、例えば、パーソナルコンピュータ、タブレットコンピュータ、スマートフォン等であってもよい。店舗端末１４は、例えば、店舗の店員が、その店舗が加入しているＦＤＳのＦＤＳサーバ１３にアクセスしてメニューを更新及び管理を行ったり、注文管理サーバ１２にアクセスして注文対象となるメニューの登録や注文状況を確認したり等することに用いられる。本実施形態では、一例として、店舗端末１４は、ある店舗が導入している店舗端末であるとする。

なお、図２においては便宜的に１つの店舗端末１４のみが示されているが、１店舗内に複数の店舗端末１４があってもよく、また、複数の店舗にそれぞれ１以上の店舗端末１４があってもよい。

ユーザ端末１５は、例えば、ユーザが所有または占有等する通信機能を有する情報通信端末であり、例えばパーソナルコンピュータ（ＰＣ）、スマートフォン及びタブレットコンピュータ等を含む。本実施形態では、ユーザ端末１５の一例として、スマートフォンを用いることとする。

図３は、本実施形態における注文管理システムの機能ブロック図である。本実施形態では一例として、ユーザ端末１５として、ユーザ端末１５ａとユーザ端末１５ｂを用いることとする。ユーザ端末１５ａには、Ａ社が提供するＦＤＳのアプリがインストールされており、ユーザは、ユーザ端末１５ａのアプリを介してＦＤＳサーバ１３ａにアクセスして、Ａ社のフードデリバリーサービスやテイクアウトサービスを受けることができるものとする。ユーザ端末１５ｂには、Ｂ社が提供するＦＤＳのアプリがインストールされており、ユーザは、ユーザ端末１５ｂのアプリを介してＦＤＳサーバ１３ｂにアクセスして、Ｂ社のフードデリバリーサービスやテイクアウトサービスを受けることができるものとする。

また、以下では、ＦＤＳサーバ１３ａの構成、機能、及びＦＤＳサーバ１３ａにアクセスするユーザ端末については符号に添え字「ａ」を付与し、ＦＤＳサーバ１３ｂの構成、機能、及びＦＤＳサーバ１３ｂにアクセスするユーザ端末については符号に添え字「ｂ」を付与するものとする。

ＦＤＳサーバ１３（１３ａ，１３ｂ）は、制御部４１（４１ａ，４１ｂ）、記憶部４２（４２ａ，４２ｂ）を含む。記憶部４２（４２ａ，４２ｂ）には、ＦＤＳに加入する店舗が提供する商品に関するメニュー情報４３（４３ａ，４３ｂ）やその店舗の営業時間等に関する情報が格納されている。

制御部４１（４１ａ，４１ｂ）は、ユーザ端末１５（１５ａ，１５ｂ）からのアクセスに応じて、記憶部４２（４２ａ，４２ｂ）からメニュー情報４３を読み出し、ユーザ端末１５（１５ａ，１５ｂ）の画面にユーザにより選択された店舗のメニュー情報（４３ａ，４３ｂ）を表示させる。

注文管理サーバ１２は、制御部２１、記憶部３１を含む。記憶部３１は、メニュー管理データベース（以下、データベースを「ＤＢ」と称する。）３２、注文管理ＤＢ３３等を格納する。

メニュー管理ＤＢ３２は、店舗別に、デリバリー及び／またはテイクアウト対象の飲食物のメニューを格納するデータベースである。注文管理ＤＢ３３は、店舗別に、受け付けた注文を管理するデータベースである。記憶部３１には、他にも、店舗別にデリバリーやテイクアウト可能な時間帯や受渡できる時間等のデリバリーやテイクアウトに関する店舗側の条件等の設定情報を格納するデータベースや、店舗別に注文に対する決済を管理するデータベース等が格納されている。また、記憶部３１には、注文管理サーバ１２が各ＦＤＳサーバ１３にログインできるように、各ＦＤＳサーバ１３のログインＩＤとパスワードが格納されている。

制御部２１は、本実施形態におけるプログラムを、記憶部３１より読み出して実行することにより、取得部２２、注文管理部２３、表示制御部２４、及び登録処理部２５として機能する。

登録処理部２５は、取得部２２により取得された、店舗端末１４より入力されたその店舗におけるデリバリーやテイクアウト対象となる飲食物のメニュー情報を、メニュー管理ＤＢ３２に登録する。また、登録処理部２５は、店舗端末１４からの操作に応じて、メニュー管理ＤＢ３２に登録されたメニュー情報を更新または削除することもできる。さらに、登録処理部２５は、メニュー管理ＤＢ３２に登録・更新されたメニュー情報の登録・更新を各ＦＤＳサーバ１３に指示したり、メニュー管理ＤＢ３２から削除されたメニュー情報の登録・更新を各ＦＤＳサーバ１３に指示することができる。

また、登録処理部２５は、取得部２２により取得された、店舗端末１４より入力されたその店舗における注文受付に関する受付条件情報を記憶部３１内の所定のデータベースに登録する。また、登録処理部２５は、店舗端末１４からの操作に応じて、そのデータベースに登録された受付条件情報を更新または削除することもできる。さらに、登録処理部２５は、所定のデータベースに登録・更新された受付条件情報の登録・更新を各ＦＤＳサーバ１３に指示したり、所定のデータベースから削除された受付条件情報の登録・更新を各ＦＤＳサーバ１３に指示することができる。

取得部２２は、外部からの要求を取得する。例えば、取得部２２は、ＦＤＳサーバ１３から送信された要求を取得したり、店舗端末１４からの操作に対する要求またはデータを取得したりする。

注文管理部２３は、各ＦＤＳサーバ１３から取得した、各ＦＤＳサーバ１３毎のデータフォーマットの注文情報のデータフォーマットを、共通データフォーマットに変換する。ここでは、各ＦＤＳサーバ１３から取得される注文情報は、ＦＤＳ（ＦＤＳサーバ１３）毎に異なるので、一元管理しやすいように、注文管理部２３は、各注文情報のデータフォーマットを共通データフォーマットに変更する。共通データフォーマットは、例えば、注文管理ＤＢ３３のデータ項目に対応するフォーマットである。これにより、注文管理部２３は、ＦＤＳ毎にデータフォーマットの異なる注文情報を注文管理ＤＢ３３に格納して管理することができる。

より具体的には、注文管理部２３は、ユーザ端末１５からの操作に応じて各ＦＤＳの専用アプリより受け付けたデリバリーやテイクアウトの注文情報を共通フォーマット化して注文管理ＤＢ３３に登録することができる。また、注文管理部２３は、店舗端末１４からの入力に応じて注文管理ＤＢ３３に格納されている注文情報を更新したり、削除したりすることもできる。

さらに、注文管理部２３は、店舗端末１４から所定の要求を取得した場合、所定の要求に対応する指示を、各ＦＤＳサーバ１３に送信する。所定の要求とは、例えば、デリバリーやテイクアウトの注文を一時的に停止する要求であってもよい。その指示を受け付けた各ＦＤＳサーバ１３は、その指示に応じた処理を行う。

また、注文管理部２３は、注文管理ＤＢ３３に格納されている注文情報に含まれるステータス情報を管理、チェックしている。

表示制御部２４は、店舗端末１４の画面に出力する画面画像を生成し、店舗端末１４の画面に出力する。本実施形態では、表示制御部２４は、例えば、ＦＤＳサーバ１３を介して注文された注文情報を管理する画面の表示を制御する。

図４は、本実施形態における注文管理サーバ１２により管理されているデータベースのデータ構造の一例を示す図である。図４（Ａ）はメニュー管理ＤＢ３２のデータ構造を示し、図４（Ｂ）は注文管理ＤＢ３３のデータ構造を示す。

メニュー管理ＤＢ３２は、「店舗ＩＤ」、「商品ＩＤ」、「カテゴリー」、「商品名」、「金額」、「イメージデータ」等のデータ項目を含む。項目「店舗ＩＤ」には、店舗を識別する識別情報（店舗ＩＤ）が格納される。項目「商品ＩＤ」には、デリバリーまたはテイクアウト対象となる商品（飲食物等）を識別する識別情報が格納される。項目「カテゴリー」には、その商品のカテゴリーが格納される。項目「商品名」には、その商品の名称が格納される。項目「金額」には、商品の単価が格納される。項目「イメージデータ」には、その商品の写真データまたは写真データの所在情報が格納される。

注文管理ＤＢ３３は、「店舗ＩＤ」、「ＦＤＳ名」、「ＦＤＳ注文ＩＤ」、「整理番号」、「注文日時」、「受渡予定日時」、「注文種別」、「注文内容」、「金額」、「確認未／済」、「キャンセル」、「受渡未／済」、「注文主名」、「お届け先」、「決済方法」、「受渡完了日時」、「備考」等のデータ項目を含む。項目「店舗ＩＤ」には、店舗を識別する識別情報（店舗ＩＤ）が格納される。項目「ＦＤＳ名」には、ＦＤＳを識別する名称が格納される。項目「ＦＤＳ注文ＩＤ」には、そのＦＤＳにおいて注文情報を識別する識別情報（注文ＩＤ）が格納される。項目「整理番号」には、当該店舗において注文情報を識別する識別情報が格納される。項目「注文日時」には、注文が確定したときの日時（注文日時）が格納される。項目「受渡予定日時」には、注文日時に対して、予め設定した調理時間に注文件数を乗じて得られた時間を加算した時刻が格納される。項目「注文種別」には、注文した商品の提供方法が持ち帰り（テイクアウト）か配達（デリバリー）かが格納される。項目「注文内容」には、注文した商品の商品ＩＤが格納される。項目「金額」には、「注文内容」に対応する金額が格納される。項目「確認未／済」には、注文情報を店舗側で確認したか否かのステータス情報（フラグ情報（０：未確認（デフォルト）、１：確認済））が格納される。項目「キャンセル」には、注文情報のキャンセルがあったか否かのステータス情報（フラグ情報（０：キャンセルなし（デフォルト）、１：キャンセルあり））が格納される。項目「受渡未／済」には、注文情報に対応する商品が配達員または顧客に受け渡されたか否かのステータス情報（フラグ情報）が格納され、例えば、顧客または配達員への注文品の受渡が未完了の場合には“０”が格納され、受渡が完了した場合には“１”が格納される。項目「注文主名」には、顧客（注文主）の名前が格納される。項目「お届け先」には、注文種別がデリバリーの場合にその配達先の住所が格納される。項目「決済方法」には、事前決済か代金引換か等の決済の方法が格納される。項目「受渡完了日時」には、顧客または配達員への注文品の受け渡しが完了した日時が格納される。項目「備考」には、例えば、ＦＤＳから提供されるその他のデータが格納される。

以下では、メニュー管理ＤＢ３２に登録する情報をメニュー情報といい、注文管理ＤＢ３３に登録する情報を注文情報という。

図５は、本実施形態における店舗端末に表示されるテイクアウト・デリバリー注文管理画面（簡易表示）の表示例を示す図である。図５は、店舗担当者が、店舗端末１４を用いて注文管理サーバ１２へアクセスした場合に表示される画面例である。

テイクアウト・デリバリー注文管理画面５０は、ヘッダ表示欄５１と、注文一覧表示欄７０を含む。ヘッダ表示欄５１は、表示対象日付表示欄５２、日時検索ボタン５３、テイクアウト一時受付停止ボタン５４、デリバリー一時停止ボタン５５、注文総件数表示欄５６、未確認注文件数表示欄５７、確認済み注文件数表示欄５８、受渡済み注文件数標示欄５９、キャンセル注文件数表示欄６０、「ＡＬＬ」表示ボタン６１、「Ｙｂｅｒ Ｅａｔｓ」表示ボタン６２、「出前屋」表示ボタン６３、「配達」表示ボタン６４、「持ち帰り」表示ボタン６５、「受渡・配達時間順」ソートボタン６６、「受付時間順」ソートボタン６７、「簡易表示」ボタン６８、「詳細表示」ボタン６９を含む。

表示対象日付表示欄５２において日付を選択すると、注文一覧表示欄７０にその選択された日付に対応する注文情報または注文情報の履歴を表示させることができる。日時検索ボタン５３を押下すると、日時を入力して、その入力した日時に対応する注文情報または注文情報の履歴を表示させることができる。

テイクアウト一時受付停止ボタン５４を押下すると、各ＦＤＳサーバ１３または全ＦＤＳサーバ１３に対して、テイクアウトの注文の受け付けを一時的に停止する指示を出すことができる。デリバリー一時停止ボタン５５を押下すると、各ＦＤＳサーバ１３または全ＦＤＳサーバ１３に対して、デリバリーの注文の受け付けを一時的に停止する指示を出すことができる。

注文総件数表示欄５６には、注文一覧表示欄７０における注文情報の総件数が表示される。未確認注文件数表示欄５７には、注文一覧表示欄７０において、未確認の注文情報の件数が表示される。確認済み注文件数表示欄５８には、注文一覧表示欄７０において、確認済みの注文情報の件数が表示される。受渡済み注文件数標示欄５９には、注文一覧表示欄７０において、受渡済みの注文情報の件数が表示される。キャンセル注文件数表示欄６０には、注文一覧表示欄７０において、キャンセルされた注文情報の件数が表示される。
なお、注文総件数表示欄５６、未確認注文件数表示欄５７、確認済み注文件数表示欄５８、受渡済み注文件数標示欄５９、キャンセル注文件数表示欄６０をまとめてステータス表示領域と称する。

「ＡＬＬ」表示ボタン６１を押下すると、表示対象日付表示欄５２に表示された日時における注文情報が全て注文一覧表示欄７０に表示される。「Ｙｂｅｒ Ｅａｔｓ」表示ボタン６２を押下すると、表示対象日付表示欄５２に表示された日時において、ＦＤＳ「Ｙｂｅｒ Ｅａｔｓ」を介して受け付けた注文情報のみが注文一覧表示欄７０に表示される。「出前屋」表示ボタン６３を押下すると、表示対象日付表示欄５２に表示された日時において、ＦＤＳ「出前屋」を介して受け付けた注文情報のみが注文一覧表示欄７０に表示される。「配達」表示ボタン６４を押下すると、表示対象日付表示欄５２に表示された日時において、各ＦＤＳを介して受け付けたデリバリー（配達）の注文情報のみが注文一覧表示欄７０に表示される。「持ち帰り」表示ボタン６５を押下すると、表示対象日付表示欄５２に表示された日時において、各ＦＤＳを介して受け付けたテイクアウト（持ち帰り）の注文情報のみが注文一覧表示欄７０に表示される。

「受渡・配達時間順」ソートボタン６６を押下すると、注文一覧表示欄７０に表示された注文情報を、受渡・配達時間順に並び替えることができる。「受付時間順」ソートボタン６７を押下すると、注文一覧表示欄７０に表示された注文情報を、受付時間順に並び替えることができる。「簡易表示」ボタン６８を押下すると、注文一覧表示欄７０に表示された各注文情報を簡易表示させることができる。「詳細表示」ボタン６９を押下すると、注文一覧表示欄７０に表示された各注文情報を詳細表示させることができる。

注文一覧表示欄７０には、表示対象日付表示欄５２において選択された日付における注文情報７１または注文情報７１の履歴情報が表示される。

注文情報７１は、ＦＤＳ名表示欄７２、決済方法表示欄７３、確認未／済表示欄７４、ＦＤＳ注文ＩＤ表示欄７５、整理番号表示欄７６、注文主名表示欄７７、お届け先表示欄７８、キャンセルボタン７９、ステータス遷移確認ボタン（「確認済」確認ボタン８０、「受渡済み」確認ボタン８１）、詳細ボタン８２を含む。

ＦＤＳ名表示欄７２には、ＦＤＳを識別する名称またはマーク等が表示される。決済方法表示欄７３には、その注文の決済方法が表示される。確認未／済表示欄７４には、その注文情報が未確認か確認済みかを判別する表示がなされる。ＦＤＳ注文ＩＤ表示欄７５には、そのＦＤＳにおいて管理されている注文ＩＤが表示される。整理番号表示欄７６には、当該店舗において注文情報を管理する整理番号が表示される。注文主名表示欄７７には、注文主の名前が表示される。お届け先表示欄７８には、お届け先の住所が表示される。キャンセルボタン７９を押下すると、その注文情報が生成されたＦＤＳサーバ１３にその注文情報のキャンセル処理を要求すると共に、注文一覧表示欄７０内の注文情報のステータスをキャンセルにして、その注文情報をキャンセルすることができる。

ステータス遷移確認ボタンには、例えば、「確認済」確認ボタン８０、「受渡済み」確認ボタン８１がある。「確認済」確認ボタン８０を押下すると、未確認の注文情報のステータスを「確認済み」にすることができる。「確認済」確認ボタン８０を押下すると、未確認の注文情報のステータスを「未確認」から「確認済み」にすることができる。「受渡済み」確認ボタン８１を押下すると、未確認の注文情報の受け渡しステータスを「未受渡」から「受渡済み」にすることができる。詳細ボタン８２を押下すると、その注文情報の詳細情報を表示させることができる。

図６は、本実施形態における店舗端末に表示されるテイクアウト・デリバリー注文管理画面（詳細表示）の表示例を示す図である。図６のテイクアウト・デリバリー注文管理画面５０は、図５において「詳細表示」ボタン６９を押下した場合に表示される。

図５において「詳細表示」ボタン６９を押下した場合、注文一覧表示欄７０の各注文情報７１に詳細情報９０が付与されている。詳細情報９０は、メニュー一覧表示欄９１、金額表示欄９２、備考表示欄９３を含む。

メニュー一覧表示欄９１は、注文された商品の内容の一覧が表示される。金額表示欄９２には、メニュー一覧表示欄９１に表示された商品数量の合計、その金額の小計、消費税、及び合計額が表示される。備考表示欄９３には、例えば、ＦＤＳサーバ１３から送信されたオリジナルデータが表示されてもよい。

図７は、本実施形態におけるメッセージ画面の表示例を示す図である。本実施形態では、注文一覧表示欄７０が確認済みか否か、商品が受渡済みか否か等、各注文情報７１のステータス状態が定期的にチェックされており、チェックの結果、例えば、注文一覧表示欄７０に未確認の注文情報７１または商品が未受渡しの注文情報７１がある場合、「未読・受け渡しができていない注文がございます。」旨のメッセージ画面１００がポップアップで表示される。

図８は、本実施形態におけるメニュー情報登録時のシーケンス図である。店舗担当者は、店舗端末１４を用いて、通信ネットワーク１６を介して、注文管理サーバ１２にアクセスし、店舗ＩＤ及びパスワードを用いて、注文管理サーバ１２にログインする（Ｓ１）。ログインが成功すると、注文管理サーバ１２は、所定のメニュー登録画面を表示させる（Ｓ２）。

店舗担当者は、店舗端末１４を用いて、メニュー情報を、そのメニュー登録画面に入力し、登録を確定させる（Ｓ３）。すると、注文管理サーバ１２は、メニュー情報をメニュー管理ＤＢ３２に登録する。登録処理が完了したら、注文管理サーバ１２は、登録完了を店舗端末１４に通知する（Ｓ４）。

さらに、店舗担当者は、登録したメニュー情報を各ＦＤＳサーバ１３に反映させるために、メニュー登録画面にある所定のボタンを押下する（Ｓ５）。すると、注文管理サーバ１２は、各ＦＤＳサーバ１３にログインして（Ｓ６，Ｓ７）、Ｓ３で登録したメニュー情報をＦＤＳサーバ１３に登録する（Ｓ８，Ｓ９，Ｓ１０）。

図９は、本実施形態におけるデリバリー／テイクアウト一時停止処理のシーケンス図である。店舗担当者は、店舗端末１４を用いて、通信ネットワーク１６を介して、注文管理サーバ１２にアクセスし、店舗ＩＤ及びパスワードを用いて、注文管理サーバ１２にログインする（Ｓ１１）。ログインが成功すると、注文管理サーバ１２は、所定の画面を表示させる（Ｓ１２）。

店舗担当者は、店舗端末１４を用いて、テイクアウト・デリバリー注文管理画面５０を表示させる要求を行う（Ｓ１３）。すると、注文管理サーバ１２は、その要求に応じて、テイクアウト・デリバリー注文管理画面５０を店舗端末１４に表示させる（Ｓ１４）。

店舗担当者は、店舗端末１４を用いて、テイクアウト一時受付停止ボタン５４またはデリバリー一時停止ボタン５５を押下すると、店舗端末１４は注文管理サーバ１２に対して、テイクアウト一時受付停止要求またはデリバリー一時停止要求を送信する（Ｓ１５）。

注文管理サーバ１２は、店舗端末１４からテイクアウト一時受付停止要求またはデリバリー一時停止要求を取得すると、各ＦＤＳサーバ１３に対して、テイクアウト一時受付停止要求またはデリバリー一時停止要求を送信する（Ｓ１６）。

各ＦＤＳサーバ１３は、注文管理サーバ１２からテイクアウト一時受付停止要求またはデリバリー一時停止要求を取得すると、ユーザ端末１５から当該店舗への商品の注文を停止する。

各ＦＤＳサーバ１３は、停止処理が完了した旨を注文管理サーバ１２に通知する（Ｓ１７）。注文管理サーバ１２は、各ＦＤＳサーバ１３から停止処理が完了した旨を取得した場合、店舗端末１４に全ＦＤＳサーバ１３においてテイクアウトまたはデリバリーの注文の受け付けを停止した旨を通知する（Ｓ１８）。

これにより、ユーザは、ユーザ端末１５のアプリ上で、当該店舗の商品のテイクアウトまたはデリバリーの注文ができなくなる。

図１０は、本実施形態におけるデリバリーまたはテイクアウトする飲食物の注文時のシーケンス図である。ユーザは、ユーザ端末１５にインストールされた専用アプリを用いて、通信ネットワーク１６を介して、その専用アプリに対応するＦＤＳサーバ１３にアクセスする（Ｓ２１）。

すると、ＦＤＳサーバ１３は、注文画面をユーザ端末１５の画面に表示させる（Ｓ２２）。ユーザは、注文画面から注文したい店舗の料理（商品）を選択し、注文を確定する（Ｓ２３）。すると、ＦＤＳサーバ１３は、その商品について注文確定処理を行い、注文管理サーバ１２に注文情報を、例えば電子メールで送信する（Ｓ２４）。電子メールに記載されている注文情報の項目や内容等のフォーマットは、ＦＤＳサーバ１３毎に異なる。

注文管理サーバ１２は、ＦＤＳサーバ１３から送信された電子メールに記載された注文情報を取得し、注文情報受領報告をＦＤＳサーバ１３に送信する（Ｓ２５）。ＦＤＳサーバ１３は、その注文情報受領報告を取得すると、ユーザ端末１５に注文完了を通知する（Ｓ２６）。

図１１は、本実施形態におけるデリバリー／テイクアウト一元管理処理の詳細を示すフローチャートである。注文管理サーバ１２（取得部２２）は、各ＦＤＳサーバ１３から送信された、ＦＤＳサーバ１３毎のフォーマットで構成された注文情報を電子メールで取得する（Ｓ３１）。

注文管理サーバ１２（注文管理部２３）は、取得した電子メールに記載された注文情報から、その注文情報がどのＦＤＳの注文情報であるかを判別する（Ｓ３２）。ＦＤＳの判別方法としては、注文管理サーバ１２（注文管理部２３）は、例えば、電子メールの件名や本文にＦＤＳ名が記載されている場合には、そのＦＤＳ名を検出して判別してもよい。

注文管理サーバ１２（注文管理部２３）は、判別したＦＤＳに応じて、注文情報のフォーマットを共通フォーマットに変換する（Ｓ３３）。共通フォーマットは、例えば、注文管理ＤＢ３３のデータ項目からなるデータフォーマットである。注文管理サーバ１２の記憶部３１には、例えば、各ＦＤＳから送信される注文情報の各項目と、注文管理ＤＢ３３のデータ項目とを対応付けた対応テーブルが格納されているとする。注文管理サーバ１２（注文管理部２３）は、その対応テーブルを用いて、ＦＤＳ毎のデータフォーマットからなる注文情報を、共通フォーマットに変換する。また、注文管理サーバ１２は、共通フォーマット化した注文情報に整理番号を付与する。

注文管理サーバ１２（注文管理部２３）は、共通フォーマットに変換した注文情報を注文管理ＤＢ３３に登録する（Ｓ３４）。なお、注文管理ＤＢ３３のデータ項目「備考」には、データフォーマット変換前のオリジナルデータを格納してもよいし、共通フォーマットに変換されなかったデータ（差分データ）を格納してもよい。

注文管理サーバ１２（表示制御部２４）は、店舗端末１４からの表示要求に基づいて、店舗端末１４の画面に表示されたテイクアウト・デリバリー注文管理画面５０の注文一覧表示欄７０に、Ｓ３４で登録した注文情報７１を表示させる（Ｓ３５）。

図１２は、本実施形態におけるステータスチェック処理の詳細なフローチャートを示す図である。注文管理サーバ１２は、テイクアウト・デリバリー注文管理画面が表示されている場合、一定期間毎または所定のタイミングで、図１２のフローを実行する。

注文管理サーバ１２（注文管理部２３）は、未確認・未受渡フラグを０で初期化する（Ｓ４１）。注文管理サーバ１２（注文管理部２３）は、注文管理ＤＢ３３から、テイクアウト・デリバリー注文管理画面５０の表示対象日付表示欄５２または日時検索ボタン５３にて指定された日付の注文情報を抽出する（Ｓ４２）。

注文管理サーバ１２（注文管理部２３）は、抽出した注文情報のうち、データ項目「確認未／済」＝０（未確認）の注文情報があるかをチェックする（Ｓ４３）。データ項目「確認未／済」＝０（未確認）の注文情報があると判定された場合（Ｓ４４でＹＥＳ）、注文管理サーバ１２（注文管理部２３）は、未確認・未受渡フラグに１をセットする（Ｓ４５）。

Ｓ４４の処理後またはデータ項目「確認未／済」＝０（確認）の注文情報がないと判定された場合（Ｓ４４でＮＯ）、注文管理サーバ１２（注文管理部２３）は、抽出した注文情報のうち、データ項目「受渡未／済」＝０（未受渡）の注文情報があるかをチェックする（Ｓ４６）。データ項目「受渡未／済」＝０（未受渡）の注文情報があると判定された場合（Ｓ４７でＹＥＳ）、注文管理サーバ１２（注文管理部２３）は、未確認・未受渡フラグに１をセットする（Ｓ４８）。

Ｓ４８の処理後またはデータ項目「受渡未／済」＝０（未受渡）の注文情報がないと判定された場合（Ｓ４７でＮＯ）、注文管理サーバ１２（注文管理部２３）は、未確認・未受渡フラグが「１」か否かを判定する（Ｓ４９）。未確認・未受渡フラグ＝１と判定された場合（Ｓ４９でＹＥＳ）、注文管理サーバ１２（表示制御部２４）は、テイクアウト・デリバリー注文管理画面５０に、「未読・受け渡しができていない注文がございます。」旨のメッセージ画面１００をポップアップで表示させる（Ｓ５０）。

Ｓ５０の処理後または未確認・未受渡フラグ＝０と判定された場合（Ｓ４９でＮＯ）、注文管理サーバ１２（注文管理部２３）は、一定期間毎または所定のタイミングで、Ｓ４１の処理に戻り、処理を繰り返す。

本実施形態は、いわゆるバーチャルレストランにおいて適用してもよい。バーチャルレストランとは、例えば、実際に店舗を持たず、シェアキッチンなどを間借りして調理を行い、デリバリーサービスを行うサイトやアプリを介して注文を受け、配達するシステムを採用した飲食店のことである。また、バーチャルレストランの他の形態としては、例えば、１つのキッチンや店舗で、複数のバーチャルレストラン、すなわち複数のブランドの飲食店を経営してもよい。このような複数のブランドの飲食店への予約について、図１３、図１４を用いて説明する。

図１３は、本実施形態の他の実施例における注文管理システムの全体構成の一例を示す図である。注文管理システム１１’は、注文管理サーバ１２、複数の予約サービスメディアサーバ１１１（１１１−１，１１１−２，・・・）、店舗端末１４、ユーザ端末１５を含む。

複数の予約サービスメディアサーバ１１１は、予約Ｗｅｂサイトサーバ１１１−１、予約アプリ用サーバ１１１−２を含む。予約Ｗｅｂサイトサーバは、飲食店の席の予約を受け付けるＷｅｂサイトが設置されたサーバであり、飲食店の席の予約を受け付ける各業者によって運営されている。予約アプリ用サーバ１１１−２は、ユーザ端末にインストールされたアプリと通信して、飲食店の席の予約を受け付けるサーバであり、飲食店の席の予約を受け付ける各業者によって運営されている。

複数の予約サービスメディアサーバ１１１はそれぞれ、ユーザ端末１５から任意の店舗の席の予約を受け付けると、注文管理サーバ１２にその予約情報を、例えば電子メールで送信する。電子メールに記載されている予約情報の項目や内容等のフォーマットは、予約サービスメディアサーバ１１１毎に異なる。

注文管理サーバ１２は、上記したデリバリーサービスやテイクアウトサービスによる注文の一元管理だけでなく、店舗の席の予約の一元管理も行うことができる。注文管理サーバ１２は、制御部２１、記憶部３１を含む。記憶部３１は、予約管理ＤＢ１０４を含む。予約管理ＤＢ１０４は、店舗の席の予約を管理するＤＢである。

制御部２１は、本実施形態におけるプログラムを、記憶部３１より読み出して実行することにより、取得部１０１、予約管理部１０２、及び表示制御部１０３として機能する。

取得部２２は、通信ネットワーク１６を介して、予約Ｗｅｂサイトサーバ１１１−１または予約アプリ用サーバ１１１−２から、例えば、電子メール等により、サーバ毎のデータフォーマットで構成された予約情報を取得する。

予約管理部１０２は、取得した電子メールに記載された予約情報から、その予約情報がどの媒体（予約サービスメディアサーバ１１１）から予約情報であるかを判別する。媒体の判別方法としては、予約管理部１０２は、例えば、電子メールの件名や本文に媒体名が記載されている場合には、その媒体名を検出して判別してもよい。

予約管理部１０２は、判別した媒体に応じて、予約情報のフォーマットを共通フォーマットに変換する。すなわち、予約管理部１０２は、判別した媒体に応じて、予約Ｗｅｂサイトサーバ１１１−１または予約アプリ用サーバ１１１−２から取得した、予約Ｗｅｂサイトサーバ１１１−１または予約アプリ用サーバ１１１−２のデータフォーマットの予約情報のデータフォーマットを、共通データフォーマットに変換する。共通データフォーマットは、例えば、予約管理ＤＢ１０４のデータ項目に対応するフォーマットである。予約管理ＤＢ１０４は、例えば、「店舗運営者ＩＤ」、「店舗ＩＤ」、「予約日時」、「予約者名」、「人数」、「コースの種類」、「媒体名」のデータ項目を含む。

項目「店舗運営者ＩＤ」には、店舗を運営している人を特定する識別情報が格納される。項目「店舗ＩＤ」には、その店舗を特定する識別情報が格納される。項目「予約日時」には、予約する日時が格納される。項目「予約者名」には、予約者の名前が格納される。項目「人数」には、予約する人数が格納される。項目「コースの種類」は、予約したコースの種類が格納される（席のみの予約の場合には、「席のみ」が格納される。）。項目「媒体名」には、予約元のＷｅｂサイトまたはアプリを特定する情報が格納される。

注文管理サーバ１２の記憶部３１には、例えば、予約Ｗｅｂサイトサーバ１１１−１または予約アプリ用サーバ１１１−２から送信される予約情報の各項目と、予約管理ＤＢのデータ項目とを対応付けた対応テーブルが格納されているとする。予約管理部１０２は、その対応テーブルを用いて、予約元のＷｅｂサイトまたはアプリに対応するサーバ毎のデータフォーマットからなる予約情報を、共通フォーマットに変換する。予約管理部１０２は、共通フォーマットに変換した予約情報を予約管理ＤＢ１０４に登録する。

表示制御部２４は、店舗端末１４からの表示要求に基づいて、店舗端末１４の画面に、その店舗に関する予約情報であって予約管理ＤＢ１０４に登録した予約情報を一元的に表示させる。

図１４は、本実施形態の他の実施例における複数のブランドの店舗の予約を管理する予約一元管理画面の一例を示す図である。予約一元管理画面１２１は、表示対象日付表示欄１２２、本日予約テーブル表示ボタン１２３、ネット予約停止ボタン１２４、予約タイムテーブル表示欄１２５を含む。

表示対象日付表示欄１２２において日付を選択すると、予約タイムテーブル表示欄１２５にその選択された日付に対応する注文情報または注文情報の履歴を表示させることができる。本日予約テーブル表示ボタン１２３を押下すると、予約タイムテーブル表示欄１２５に本日の予約テーブルを表示させることができる。

ネット予約停止ボタン１２４を押下すると、予約管理部１０２は、各予約サービスメディアサーバ１１１または全予約サービスメディアサーバ１１１に対して、通信ネットワーク経由の予約の受け付けを一時的に停止する指示を出すことができる。

予約タイムテーブル表示欄１２５は、縦軸に店舗の各テーブルを特定するテーブル名、横軸に時間からなるタイムテーブルを表示する。予約タイムテーブル表示欄１２５には、通信ネットワークを介して受け付けた予約が予約枠１２６として表示される。

予約枠１２６は、「飲食店名」、「予約時間帯」、「予約者名及び予約人数」、「コースの種類」、「媒体名」のデータ項目を含む。項目「飲食店名」には、予約の対象となる飲食店の名称が表示される。項目「予約時間」には、予約の時間帯が表示される。項目「予約者名及び予約人数」には、予約者の名前及び予約する人数が表示される。項目「コースの種類」には、予約したコースの種類が表示される（席のみの予約の場合には、「席のみ」が表示される。）。項目「媒体名」には、予約元のＷｅｂサイトまたはアプリを特定する情報が表示される。

ここで、予約タイムテーブル表示欄１２５には、通信ネットワーク１６介して、複数の異なる予約Ｗｅｂサイトそれぞれまたはアプリから予約された予約情報が予約枠１２６として表示される。そのため、予約枠１２６の項目「媒体名」には、その予約元となった予約Ｗｅｂサイトまたはアプリを特定する情報（例えば、予約Ｗｅｂサイト名またはアプリ名等）が表示される。

また、図１４の例は、１つの店舗で複数のバーチャルレストランを運営している例であり、複数の店舗名（ブランド名）に対する予約がされているため、予約タイムテーブル表示欄１２５の各予約枠１２６の「飲食店名」には、異なる飲食店名が表示されている。

表示制御部２４は、店舗端末１４からの表示要求に基づいて、店舗端末１４の画面に予約一元管理画面１２１に、予約管理ＤＢに登録した予約情報を予約タイムテーブル表示欄１２５上に予約枠１２６として表示させる。

なお、本実施形態の他の実施例は、バーチャルレストランに限定されず、複数の実店舗を、予約一元管理画面１２１で一元管理してもよい。この場合、予約タイムテーブル表示欄１２５の縦軸は各実店舗の席またはテーブル名が表示されることになる。

また、図１４で予約枠１２６に表示される内容は一例であって、これに限定されず、例えば、子供が同伴である旨や、車椅子での来店、アレルギー等に関する注意情報等を含めてもよい。

なお、予約情報に所定のステータス情報（例えば、事前決済済みか、店舗での支払い方法において現時点で未払い）を付与し、一定期間ごとにまたは所定のタイミングで、予約管理部１０２に一元的に予約タイムテーブル表示欄１２５に表示させた予約情報のステータスをチェックさせてもよい。この場合、表示制御部１０３にステータス情報の判定結果に応じて、所定のメッセージ（例えば、「清算前の予約情報があります。」等）を表示させてもよい。

図１５は、本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。コンピュータ１３１は、注文管理サーバ１２であってもよいし、ＦＤＳサーバ１３、予約Ｗｅｂサイトサーバ１１１−１または予約アプリ用サーバ１１１−２であってもよいし、店舗端末１４であってもよいし、ユーザ端末１５であってもよい。コンピュータ１３１は、ＣＰＵ１３２、ＲＯＭ１３３、ＲＡＭ１３４、記憶装置１３５、入力Ｉ／Ｆ１３６、出力Ｉ／Ｆ１３７、通信Ｉ／Ｆ１３８、読取装置１３９、バス１４０によって構成されている。

ここで、ＣＰＵは、中央演算装置を示す。ＲＯＭは、リードオンリメモリを示す。ＲＡＭは、ランダムアクセスメモリを示す。Ｉ／Ｆは、インターフェースを示す。バス１４０には、ＣＰＵ１３２、ＲＯＭ１３３、ＲＡＭ１３４、記憶装置１３５、入力Ｉ／Ｆ１３６、出力Ｉ／Ｆ１３７、通信Ｉ／Ｆ１３８、及び必要に応じて読取装置１３９が接続されていてもよい。

ＣＰＵ１３２は、記憶装置１３５から本実施形態に係るプログラムを読み出し、例えば注文管理サーバ１２として機能する場合には、取得部２２、注文管理部２３、表示制御部２４、登録処理部２５、取得部１０１、予約管理部１０２、表示制御部１０３として当該プログラムを実行する。ＲＯＭ１３３は、読み出し専用のメモリを示す。ＲＡＭ１３４は、一時的に記憶するメモリである。

記憶装置１３５は、大容量の情報を記憶する装置である。記憶装置１３５としては、ハードディスク、ソリッドステートドライブ（ＳＳＤ）、フラッシュメモリカードなど様々な形式の記憶装置を使用することができる。記憶装置１３５には、本発明の実施形態に係るプログラムや、記憶部３１に格納されている各種データが記憶されている。

入力Ｉ／Ｆ１３６は、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサ、タブレット、タッチパネル、情報読取装置等の入力装置と接続することが可能である。また、出力Ｉ／Ｆ１３７は、ディスプレイ、タッチパネル、プロジェクタ、プリンタ、スピーカ等の出力装置と接続することが可能である。

通信Ｉ／Ｆ１３８は、通信ネットワークと接続して他の装置と通信するためのポート等のインターフェースである。通信ネットワークは、インターネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、専用線、有線、無線等の通信網であってよい。読取装置１３９は、可搬型記録媒体を読み出す装置である。

上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワークおよび通信Ｉ／Ｆ１３８を介して、例えば記憶装置１３５に格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読取装置１３９にセットされて、ＣＰＵ１３２によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＩＣカード、ＵＳＢメモリ装置、半導体メモリカードなど様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読取装置１３９によって読み取られる。

また、当該プログラムは、スタンドアローン型のコンピュータにインストールされてもよいし、クラウドコンピュータによりインストールされて機能のみをユーザに提供してもよい。

本実施形態によれば、複数の異なるフードデリバリーサービスシステムを介して受け付けた商品の注文を一元管理することができる。すなわち、ＦＤＳ毎またはテイクアウトサービス毎に異なるデータフォーマットを有する注文情報を共通フォーマット化して、同一の画面で一元的に管理することができる。

また、本実施形態では、注文情報のステータス情報として、データ項目「確認未／済」及びデータ項目「受渡未／済」のフラグ情報を用いたが、これに限定されず、例えば、調理が完了したか否かを判定する「調理未／済」等のステータス情報を用いてもよい。

また、注文管理部２３は、テイクアウト・デリバリー注文管理画面５０において、ステータス情報に応じて注文情報のステータスのチェックを行ってもよい。この場合、表示制御部２４は、そのチェック結果に応じて、所定のメッセージを示すメッセージ画面を表示させてもよい。例えば、確認済みになってから所定時間経過した注文情報であって「調理未／済」＝「０」の注文情報が存在している場合、表示制御部２４は、「調理が済んでいない注文があります。」旨のメッセージ画面を表示させてもよい。また、例えば、調理済みになってから所定時間経過した注文情報であって「受渡未／済」＝「０」の注文情報が存在している場合、表示制御部２４は、「調理済の注文が受け渡されていません。」旨のメッセージ画面を表示させてもよい。

また、本実施形態の他の実施例によれば、１つの店舗で複数のブランドの飲食店を運営するバーチャルレストランや複数の実店舗の予約を一元的に管理することができる。すなわち、複数の異なる予約Ｗｅｂサイトサーバ毎または予約アプリに対応するサーバ毎に異なるデータフォーマットを有する予約情報を共通フォーマット化して、同一の画面で一元的に管理することができる。

なお、本実施形態では、商品として飲食物を取り扱ったが、これに限定されず、例えば、家電、ゲーム機、玩具、被服、靴等であってもよい。また、本実施形態で示したフローチャートは実施形態の一例として示したものであり、発明の範囲を逸脱しない範囲で、その内容に限定されない。

以上、実施形態、変形例に基づき本態様について説明してきたが、上記した態様の実施の形態は、本態様の理解を容易にするためのものであり、本態様を限定するものではない。本態様は、その趣旨並びに特許請求の範囲を逸脱することなく、変更、改良され得ると共に、本態様にはその等価物が含まれる。また、その技術的特徴が本明細書中に必須なものとして説明されていなければ、適宜、削除することができる。

１ 注文管理装置
２ 取得部
３ 変換部
４ 表示制御部
５ 判定部
６ 指示送信部
１１ 注文管理システム
１２ 注文管理装置
１３（１３ａ，１３ｂ） ＦＤＳサーバ
１４ 店舗端末
１５（１５ａ，１５ｂ） ユーザ端末
１６ 通信ネットワーク
２１ 制御部
２２ 取得部
２３ 注文管理部
２４ 表示制御部
２５ 登録処理部
３１ 記憶部
３２ メニュー管理ＤＢ
３３ 注文管理ＤＢ
３５ 顧客管理ＤＢ
４１（４１ａ，４１ｂ） 制御部
４２（４２ａ，４２ｂ） 記憶部
４３（４３ａ，４３ｂ） メニュー情報
１１’ 注文管理システム
１０１ 取得部
１０２ 予約管理部
１０３ 表示制御部
１０４ 予約管理ＤＢ
１１１ 予約サービスメディアサーバ
１１１−１ 予約Ｗｅｂサイトサーバ
１１１−２ 予約アプリ用サーバ

Claims (7)

1. ユーザにより操作されるユーザ端末から通信ネットワークを介して、商品としての料理の注文及び配達を受け付けるフードデリバリーサービスまたはテイクアウトするための前記商品の注文を受け付けるテイクアウトサービスを提供するフードサービスメディアの情報処理システムであって複数の異なるフードサービスメディアの情報処理システムそれぞれから、特定の店舗の前記商品に対する第１注文情報であって各フードサービスメディアの情報処理システムのデータフォーマットに応じた前記第１注文情報を取得する取得部と、
   前記第１注文情報のデータフォーマットを第１共通フォーマットに変換する変換部と、
   前記第１共通フォーマットに変換された前記第１注文情報である第２注文情報を一元的に表示させる画面であって、前記第２注文情報それぞれに対して、当該第２注文情報が前記ユーザによって確認されたか否かの第１ボタンと、当該第２注文情報に対応する注文された商品の受け渡しが済んだか否かの第２ボタンを含む前記画面を、前記ユーザ端末の表示部に表示させる表示制御部と、
   前記第１ボタンの押下に応じて、第２注文情報が前記ユーザによって確認されたか否かのステータスを示す第１ステータス情報を更新し、前記第２ボタンの押下に応じて、当該第２注文情報に対応する注文された商品の受け渡しが済んだか否かのステータスを示す第２ステータス情報を更新するステータス管理部と、
   一定期間ごとにまたは所定のタイミングで、前記ユーザ端末の画面に表示された前記第２注文情報それぞれの前記第１ステータス情報と前記第２ステータス情報のステータスの判定を行う判定部と、
   を備え、
   前記表示制御部は、前記判定の結果に応じて、未確認または前記注文された商品の受け渡しが済んでいない注文がある旨のメッセージを表示させる
   ことを特徴とする注文管理装置。
2. 前記ステータス管理部は、いずれかの前記第２注文情報の前記第１ボタンが押下された場合、当該いずれかの前記第２注文情報の第１ステータス情報を、当該第２注文情報が前記ユーザによって確認された旨のステータスに更新し、いずれかの前記第２注文情報の前記第２ボタンが押下された場合、当該いずれかの前記第２注文情報の第２ステータス情報を、当該第２注文情報に対応する注文された商品の受け渡しが済んだ旨のステータスに更新し、
   さらに、前記第２注文情報は、調理が完了したか否かのステータスを示す第３ステータス情報を含み、
   前記表示制御部は、さらに、前記第１ステータス情報が前記ユーザによって確認された旨のステータスに更新されてから所定時間経過した前記第２注文情報の前記第３ステータス情報が調理が完了していない旨を示す場合、前記調理が済んでいない注文がある旨のメッセージを表示させ、前記第３ステータス情報が前記調理が完了した旨のステータスに更新されてから所定時間経過した前記第２注文情報の前記第２ステータス情報が前記注文された商品の受け渡しが済んでいない旨を示す場合、調理済みの注文が受け渡されていない旨のメッセージを表示させる
   ことを特徴とする請求項１に記載の注文管理装置。
3. 前記表示制御部は、さらに、一元的に表示させた前記第２注文情報を、前記フードサービスメディアの情報処理システム毎に、表示させる
   ことを特徴とする請求項１または２に記載の注文管理装置。
4. 前記注文管理装置は、さらに、
   前記特定の店舗における端末装置から所定の要求を取得した場合、前記所定の要求に対応する指示を、前記複数の異なるフードサービスメディアの情報処理システムに送信する指示送信部
   を備えることを特徴とする請求項1〜３のうちいずれか１項に記載の注文管理装置。
5. 前記取得部は、さらに、ユーザにより操作されるユーザ端末から通信ネットワークを介して、現実のまたは仮想的な店舗の席の予約を受け付ける予約サービスメディアの情報処理システムであって複数の異なる予約サービスメディアの情報処理システムそれぞれから、特定の店舗の席の予約に関する第１予約情報であって各予約サービスメディアの情報処理システムのデータフォーマットに応じた前記第１予約情報を取得し、
   前記変換部は、前記第１予約情報が取得された場合、前記第１予約情報のデータフォーマットを第２共通フォーマットに変換し、
   前記表示制御部は、前記第２共通フォーマットに変換された前記第１予約情報である第２予約情報を一元的に表示させる
   ことを特徴とする請求項１〜４のうちいずれか１項に記載の注文管理装置。
6. コンピュータに、
   ユーザにより操作されるユーザ端末から通信ネットワークを介して、商品としての料理の注文及び配達を受け付けるフードデリバリーサービスまたはテイクアウトするための前記商品の注文を受け付けるテイクアウトサービスを提供するフードサービスメディアの情報処理システムであって複数の異なるフードサービスメディアの情報処理システムそれぞれから、特定の店舗の前記商品に対する第１注文情報であって各フードサービスメディアの情報処理システムのデータフォーマットに応じた前記第１注文情報を取得する取得処理と、
   前記第１注文情報のデータフォーマットを第１共通フォーマットに変換する変換処理と、
   前記第１共通フォーマットに変換された前記第１注文情報である第２注文情報を一元的に表示させる画面であって、前記第２注文情報それぞれに対して、当該第２注文情報が前記ユーザによって確認されたか否かの第１ボタンと、当該第２注文情報に対応する注文された商品の受け渡しが済んだか否かの第２ボタンを含む前記画面を、前記ユーザ端末の表示部に表示させる表示制御処理と、
   前記第１ボタンの押下に応じて、第２注文情報が前記ユーザによって確認されたか否かのステータスを示す第１ステータス情報を更新し、前記第２ボタンの押下に応じて、当該第２注文情報に対応する注文された商品の受け渡しが済んだか否かのステータスを示す第２ステータス情報を更新するステータス管理処理と、
   一定期間ごとにまたは所定のタイミングで、前記ユーザ端末の画面に表示された前記第２注文情報それぞれの前記第１ステータス情報と前記第２ステータス情報のステータスの判定を行う判定処理と、
   を実行させ、
   前記表示制御処理は、前記判定の結果に応じて、未確認または前記注文された商品の受け渡しが済んでいない注文がある旨のメッセージを表示させる
   ことを特徴とする注文管理プログラム。
7. コンピュータが
   ユーザにより操作されるユーザ端末から通信ネットワークを介して、商品としての料理の注文及び配達を受け付けるフードデリバリーサービスまたはテイクアウトするための前記商品の注文を受け付けるテイクアウトサービスを提供するフードサービスメディアの情報処理システムであって複数の異なるフードサービスメディアの情報処理システムそれぞれから、特定の店舗の前記商品に対する第１注文情報であって各フードサービスメディアの情報処理システムのデータフォーマットに応じた前記第１注文情報を取得し、
   前記第１注文情報のデータフォーマットを第１共通フォーマットに変換し、
   前記第１共通フォーマットに変換された前記第１注文情報である第２注文情報を一元的に表示させる画面であって、前記第２注文情報それぞれに対して、当該第２注文情報が前記ユーザによって確認されたか否かの第１ボタンと、当該第２注文情報に対応する注文された商品の受け渡しが済んだか否かの第２ボタンを含む前記画面を、前記ユーザ端末の表示部に表示させ、
   前記第１ボタンの押下に応じて、第２注文情報が前記ユーザによって確認されたか否かのステータスを示す第１ステータス情報を更新し、前記第２ボタンの押下に応じて、当該第２注文情報に対応する注文された商品の受け渡しが済んだか否かのステータスを示す第２ステータス情報を更新し、
   一定期間ごとにまたは所定のタイミングで、前記ユーザ端末の画面に表示された前記第２注文情報それぞれの
   前記第１ステータス情報と前記第２ステータス情報のステータスの判定を行い、
   前記判定の結果に応じて、未確認または前記注文された商品の受け渡しが済んでいない注文がある旨のメッセージを表示させる
   ことを特徴とする注文管理方法。
   

Images