JP2022129096A - サーバ装置およびプログラム - Google Patents

Abstract

【課題】複数の場所から参加するコミュニケーション形態の提供と、飲食物の取り寄せと、を両立可能なサーバ装置およびプログラムを提供する。【解決手段】サーバ装置は、複数の端末からアクセスを受け付け、アクセス元の端末と当該端末を操作するユーザとユーザの参加場所と終了時刻とを関連付けて管理する管理手段と、同一グループに属するユーザの前記端末同士を通信可能に接続する通信制御手段と、前記参加場所に配達可能な商品の情報を含むメニュー情報を、前記通信制御手段で通信可能に接続された前記端末同士で閲覧可能に提供する提供手段と、前記メニュー情報が提供された前記端末の何れかから商品の注文を受け付け、注文された商品に関する情報を、当該商品を取り扱う店舗に通知する注文受付手段と、を備える。【選択図】図１６

Description

本発明の実施形態は、サーバ装置およびプログラムに関する。

テレワークやリモートワーク等の普及に伴い、ネットワークを介して会議を行うＷｅｂ会議システムが広く利用されるようになってきている。また、ビジネス以外の用途でＷｅｂ会議システムを用いることも行われている。例えば、Ｗｅｂ会議システムを用いて飲み会やパーティ等を行う所謂リモート飲み会等が行われている。また、例えば、ユーザが互いに異なる店舗に来店し、店舗に置かれた端末を用いてＷｅｂ会議を行うことで、店舗が提供する飲食物（商品）を飲食しながら、他の店舗にいるユーザとコミュニケーションを行うことができる。

一方、従来では、実店舗におけるオーダシステムに関し、顧客グループを構成する人数に基づき、一人当たりの支払金額を算出する技術が提案されている（例えば特許文献１）。この従来技術では、一人当たりの支払金額を飲食の実態に応じて算出するために、グループの注文履歴を把握し、注文履歴に含まれる商品を分類するカテゴリに分類し、各カテゴリの商品を飲食したとする顧客の人数を把握する。

しかしながら、従来の技術では、ユーザが集まって飲食する店舗内でオーダや注文が行われることが前提となっているため、上述したように店舗や自宅など複数の参加場所に亘ってリモート飲み会を行う形態や、リモート飲み会を継続しつつ店舗外或いは自宅外から飲食物を取り寄せる形態については何ら想定されていない。そのため、利便性の向上に関して改善の余地がある。

本発明が解決しようとする課題は、複数の場所から参加するコミュニケーション形態の提供と、飲食物の取り寄せと、を両立可能なサーバ装置およびプログラムを提供することである。

実施形態のサーバ装置は、複数の端末からアクセスを受け付け、アクセス元の端末と当該端末を操作するユーザとユーザの参加場所と終了時刻とを関連付けて管理する管理手段と、同一グループに属するユーザの前記端末同士を通信可能に接続する通信制御手段と、前記参加場所に配達可能な商品の情報を含むメニュー情報を、前記通信制御手段で通信可能に接続された前記端末同士で閲覧可能に提供する提供手段と、前記メニュー情報が提供された前記端末の何れかから商品の注文を受け付け、注文された商品に関する情報を、当該商品を取り扱う店舗に通知する注文受付手段と、を備える。

図１は、実施形態にかかるリモート飲食提供システムの構成例を示す図である。 図２は、実施形態に係る席端末のハードウェア構成の一例を示す図である。 図３は、実施形態に係る受注端末のハードウェア構成の一例を示す図である。 図４は、実施形態に係るサーバ装置のハードウェア構成の一例を示す図である。 図５は、実施形態に係るリモートレストラン管理テーブルのデータ構成の一例を示す図である。 図６は、実施形態に係るデリバリー店舗管理テーブルのデータ構成の一例を示す図である。 図７は、実施形態に係るメニュー管理テーブルのデータ構成の一例を示す図である。 図８は、実施形態に係るユーザ管理テーブルのデータ構成の一例を示す図である。 図９は、実施形態に係る予約管理テーブルのデータ構成の一例を示す図である。 図１０は、実施形態に係るオーダ管理テーブルのデータ構成の一例を示す図である。 図１１は、実施形態に係る配達状況管理テーブルのデータ構成の一例を示す図である。 図１２は、実施形態に係るサーバ装置、席端末またはユーザ端末、および受注端末の機能構成の一例を示す図である。 図１３は、実施形態に係る各装置間のデータ送受信の一例を示す図である。 図１４は、実施形態の席端末またはユーザ端末に表示される画面の一例を示す図である。 図１５は、実施形態の席端末またはユーザ端末に表示される画面の他の例を示す図である。 図１６は、実施形態の席端末またはユーザ端末に表示される画面の他の例を示す図である。 図１７は、実施形態の席端末またはユーザ端末に表示される画面の他の例を示す図である。 図１８は、実施形態の席端末またはユーザ端末に表示される画面の一部分の例を拡大して示す図である。 図１９は、実施形態における注文可能／不可能の判断を説明する図である。 図２０は、実施形態の席端末またはユーザ端末に表示される画面の他の例を示す図である。 図２１は、実施形態の席端末またはユーザ端末に表示される画面の他の例を示す図である。 図２２は、実施形態の席端末またはユーザ端末に表示される画面の他の例を示す図である。 図２３は、実施形態の席端末またはユーザ端末に表示される画面の他の例を示す図である。 図２４は、実施形態のサーバ装置が実行するログイン処理の一例を示すフローチャートである。 図２５は、実施形態のサーバ装置が実行するメニュー提供処理の一例を示すフローチャートである。 図２６は、実施形態のサーバ装置が実行するオーダ処理の一例を示すフローチャートである。 図２７は、実施形態のサーバ装置が実行する会計処理の一例を示すフローチャートである。

以下、図面を参照して、実施形態について詳細に説明する。なお、以下に説明する実施形態によりこの発明が限定されるものではない。

図１は、実施形態にかかるリモート飲食提供システム１の構成例を示す図である。リモート飲食提供システム１は、席端末１０やユーザ端末２０、サーバ装置３０、受注端末４０、外部サービスサーバ５０、ドライバー端末６０、キッチン端末７０等を含む。サーバ装置３０は、他の各端末（席端末１０やユーザ端末２０、受注端末４０、外部サービスサーバ５０、ドライバー端末６０、キッチン端末７０等）と、インターネットや携帯電話回線網等のネットワークＮを介して通信可能に接続される。また、外部サービスサーバ５０は、受注端末４０やドライバー端末６０、サーバ装置３０と、ネットワークＮを介して通信可能に接続される。

席端末１０は、リモートレストラン９１の各々に設けられる端末装置である。リモートレストラン９１は、外部で調理され配達された飲食物を飲食する場を提供する店舗である。リモートレストラン９１は、その性質上、調理場を持たなくともよい。本実施形態のリモートレストラン９１は、ドリンクメニューについては店舗内で提供可能であるとする。なお、リモートレストラン９１の各々は、チェーン店等の系列店であってもよいし、各々が独立した店舗であってもよい。

席端末１０は、例えば、リモートレストラン９１内の各席に設けられるセルフオーダ用のオーダ端末であり、タブレット端末等により実現される。なお、リモートレストラン９１に設けられる席端末１０の台数は特に問わず、複数台であってもよい。

また、リモートレストラン９１の各々は、サーバ装置３０から通知されるオーダ情報を表示するためのキッチン端末７０を備える。また、リモートレストラン９１の各々は、席端末１０やキッチン端末７０を管理する店舗サーバ（図示せず）を備える。

ユーザ端末２０は、リモート飲食提供システム１を利用するユーザが使用する端末装置である。ユーザ端末２０は、例えばスマートフォンやタブレット端末等の携帯型の端末装置で実現することができる。なお、本実施形態では、説明の便宜上、ユーザ端末２０はユーザ自宅９２からリモート飲食提供システム１に接続している例について説明するが、実施にあたってはこれに限らない。例えば、ユーザ端末２０を使用するユーザが、ユーザ自宅９２以外の場所でリモート飲食提供システム１を利用しても構わない。

サーバ装置３０は、本実施形態のサーバ装置の一例である。サーバ装置３０は、例えばワークステーション等の情報処理装置によって実現される。なお、本実施形態では、サーバ装置３０を単体の装置として説明するが、これに限らないものとする。例えば、サーバ装置３０は、複数のサーバ装置で分散して機能を動作させる構成としてもよい。

サーバ装置３０は、リモート飲食提供システム１が含む他の各端末と協働することで、席端末１０およびユーザ端末２０を使用するユーザに対し、リモート飲食提供サービスを提供する。より具体的には、サーバ装置３０は、複数のリモートレストラン９１の各々に設けられた席端末１０およびユーザ端末２０間の通信を制御することで、居場所が異なるユーザ同士の会話の仲介や画面共有、を行うサービス（リモート飲食提供サービス）を提供する。以下では、席端末１０を用いたリモート飲食提供サービス、または席端末１０を用いてリモート飲食提供サービスを行う（享受する）ことを、「リモート飲み会」ともいう。

また、サーバ装置３０は、席端末１０およびユーザ端末２０から、デリバリー商品の注文を受け付け、配達完了までを管理する。

受注端末４０は、デリバリー店舗９３の各々が備える端末装置である。受注端末４０は、例えば、タブレット端末等により実現される。デリバリー店舗９３は、調理スタッフが調理を行うキッチンおよび顧客が飲食するホールの両方を備える店舗であってもよいし、キッチンのみを備えホールがないテイクアウト販売あるいは受注販売の店舗であってもよい。受注端末４０は、キッチンの調理スタッフに対して、商品の受注にかかる情報を報知する。

外部サービスサーバ５０は、例えば既存のデリバリーサービスを実施する事業者が備えるサーバ装置であって、サーバ装置３０に、各デリバリー店舗９３が提供する商品の情報（メニュー）や、各ドライバー９４の稼働状況を提供する。

ドライバー端末６０は、各ドライバー９４が所持する端末装置である。ドライバー端末６０は、例えばスマートフォンやタブレット端末等の携帯型の端末装置で実現することができる。

キッチン端末７０は、各リモートレストラン９１のバックヤードに設けられる端末装置である。キッチン端末７０は、例えば、タブレット端末等により実現される。キッチン端末７０は、配膳スタッフに対して、リモートレストラン９１内のユーザが注文した商品にかかる情報を報知する。報知内容は、例えば、デリバリーされてくる予定の時刻や、商品の画像、適する食器の形状や大きさ、注文者の席を識別するための情報などである。

次に、リモート飲食提供システム１が有する主要な装置の構成について説明する。

図２は、実施形態に係る席端末１０のハードウェア構成の一例を示す図である。席端末１０は、ＣＰＵ（Central Processing Circuit）１１、ＲＯＭ（Read Only Memory）１２、及びＲＡＭ（Random Access Memory）１３等のコンピュータ構成を備える。

ＣＰＵ１１は、プロセッサの一例であり、席端末１０の各部を統括的に制御する。ＲＯＭ１２は、各種プログラムを記憶する。ＲＡＭ１３は、プログラムや各種データを展開するワークスペースである。

また、席端末１０は、通信部１４と、記憶部１５と、表示部１６と、操作部１７と、撮像部１８と、音声入出力部１９とを備える。

通信部１４は、ネットワークＮに接続可能な通信インタフェースである。通信部１４は、ネットワークＮを介してサーバ装置３０等の外部装置と通信を行う。また、通信部１４は、自店舗内の店舗サーバや他の席端末１０と通信を行う。

記憶部１５は、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ等の記憶媒体で構成されており、電源を遮断しても記憶内容を維持する。記憶部１５は、ＣＰＵ１１が実行することが可能なプログラムや各種の設定情報を記憶する。例えば、記憶部１５は、リモート飲み会用に用意されたプログラム（クライアントプログラム）やＧＵＩ（Graphical User Interface）の表示に係るコンテンツ等を記憶する。ＣＰＵ１１は、ＲＯＭ１２や記憶部１５に記憶されＲＡＭ１３に展開されたプログラムに従って動作することによって、各種の処理を実行する。

表示部１６は、ＬＣＤ（Liquid Crystal Display）等の表示デバイスであり、ＣＰＵ１１の制御に従って各種の情報や画面を表示する。操作部１７は、各種の操作キーを有し、ユーザの操作に応じた操作内容をＣＰＵ１１に出力する。なお、操作部１７は、表示部１６の表面に設けられたタッチパネルであってもよい。

撮像部１８は、ＣＣＤ（Charge Coupled Device）等の撮像素子を具備する撮像装置である。撮像部１８は、例えば、席端末１０を操作するユーザを撮像することで、ユーザの画像データ（静止画、動画）を取得し、取得した画像データをＣＰＵ１１に出力する。

音声入出力部１９は、マイク等の音声入力装置と、スピーカ等の音声出力装置とを具備する。音声入出力部１９は、ユーザの音声データを取得し、取得した音声データをＣＰＵ１１に出力する。また、音声入出力部１９は、ＣＰＵ１１から入力される音声データを音声として出力する。

なお、席端末１０のハードウェア構成は、図２の構成に限らないものとする。また、ユーザ端末２０は、席端末１０と同様のハードウェア構成を備えるものとして説明を進める。

図３は、実施形態に係る受注端末４０のハードウェア構成の一例を示す図である。受注端末４０は、ＣＰＵ４１、ＲＯＭ４２、及びＲＡＭ４３等のコンピュータ構成を備える。

ＣＰＵ４１は、プロセッサの一例であり、受注端末４０の各部を統括的に制御する。ＲＯＭ４２は、各種プログラムを記憶する。ＲＡＭ４３は、プログラムや各種データを展開するワークスペースである。

また、受注端末４０は、通信部４４と、記憶部４５と、表示部４６と、操作部４７と、を備える。

通信部４４は、ネットワークＮに接続可能な通信インタフェースである。通信部４４は、ネットワークＮを介してサーバ装置３０や外部サービスサーバ５０等の外部装置と通信を行う。

記憶部４５は、ＨＤＤやフラッシュメモリ等の記憶媒体で構成されており、電源を遮断しても記憶内容を維持する。記憶部４５は、ＣＰＵ４１が実行することが可能なプログラムや各種の設定情報を記憶する。例えば、記憶部４５は、ＧＵＩの表示に係るコンテンツ等を記憶する。ＣＰＵ４１は、ＲＯＭ４２や記憶部４５に記憶されＲＡＭ４３に展開されたプログラムに従って動作することによって、各種の処理を実行する。

表示部４６は、ＬＣＤ等の表示デバイスであり、ＣＰＵ４１の制御に従って各種の情報や画面を表示する。操作部４７は、各種の操作キーを有し、ユーザの操作に応じた操作内容をＣＰＵ４１に出力する。なお、操作部４７は、表示部４６の表面に設けられたタッチパネルであってもよい。

なお、受注端末４０のハードウェア構成は、図３の構成に限らないものとする。また、ドライバー端末６０およびキッチン端末７０は、受注端末４０と同様のハードウェア構成を備えるものとして説明を進める。

図４は、実施形態に係るサーバ装置３０のハードウェア構成の一例を示す図である。図４に示すように、サーバ装置３０は、ＣＰＵ３１、ＲＯＭ３２、及びＲＡＭ３３等のコンピュータ構成を備える。

ＣＰＵ３１は、プロセッサの一例であり、サーバ装置３０の各部を統括的に制御する。ＲＯＭ３２は、各種プログラムを記憶する。ＲＡＭ３３は、プログラムや各種データを展開するワークスペースである。

また、サーバ装置３０は、通信部３４と、記憶部３５とを備える。通信部３４は、ネットワークＮに接続可能な通信インタフェースである。通信部３４は、ネットワークＮを介して席端末１０やユーザ端末２０等の外部装置と通信を行う。

記憶部３５は、ＨＤＤやフラッシュメモリ等の記憶媒体で構成されており、電源を遮断しても記憶内容を維持する。記憶部３５は、ＣＰＵ３１が実行することが可能なプログラムや各種の設定情報を記憶する。例えば、記憶部３５は、リモート飲み会用に用意されたプログラム（サーバプログラム）やＧＵＩの表示に係るコンテンツ等を記憶する。ＣＰＵ３１は、ＲＯＭ３２や記憶部３５に記憶されＲＡＭ３３に展開されたプログラムに従って動作することによって、各種の処理を実行する。

なお、サーバ装置３０のハードウェア構成は、図４の構成に限らないものとする。また、外部サービスサーバ５０は、サーバ装置３０と同様のハードウェア構成を備えるものとして説明を進める。

また、サーバ装置３０の記憶部３５は、リモートレストラン管理テーブル３５１と、デリバリー店舗管理テーブル３５２と、デリバリーメニュー管理テーブル３５３と、ユーザ管理テーブル３５４と、予約管理テーブル３５５と、オーダ管理テーブル３５６と、配達状況管理テーブル３５７と、を記憶する。

図５は、実施形態に係るリモートレストラン管理テーブル３５１のデータ構成の一例を示す図である。リモートレストラン管理テーブル３５１は、各リモートレストラン９１のＩＤ（リモートレストランＩＤ）に関連付けて、当該リモートレストランＩＤに対応するリモートレストラン９１に関する情報（リモートレストラン情報）を記憶する。

リモートレストランＩＤは、リモートレストラン９１の各々を識別するための識別情報である。リモートレストラン情報は、リモートレストラン９１の名称（リモートレストラン名）、住所、連絡先、及び画像（リモートレストラン画像）等の項目を含む。リモートレストラン名は、リモートレストラン９１の屋号や支店名等である。住所は、リモートレストラン９１の所在地を示す住所を意味する。連絡先は、例えばリモートレストラン９１の住所や、ＩＰアドレス等のアドレス情報を意味する。リモートレストラン画像は、リモートレストランＩＤに対応するリモートレストラン９１を表したアイコンやロゴマーク等の画像情報である。なお、リモートレストラン管理テーブル３５１のデータ構成は、図５の例に限らないものとする。

図６は、実施形態に係るデリバリー店舗管理テーブル３５２のデータ構成の一例を示す図である。デリバリー店舗管理テーブル３５２は、各デリバリー店舗９３のＩＤ（デリバリー店舗ＩＤ）に関連付けて、当該デリバリー店舗ＩＤに対応するデリバリー店舗９３に関する情報（デリバリー店舗情報）を記憶する。

デリバリー店舗ＩＤは、デリバリー店舗９３の各々を識別するための識別情報である。デリバリー店舗情報は、デリバリー店舗９３の名称（デリバリー店舗名）、住所、連絡先、及び画像（デリバリー店舗画像）等の項目を含む。デリバリー店舗名は、デリバリー店舗９３の屋号や支店名等である。住所は、デリバリー店舗９３の所在地を示す住所を意味する。連絡先は、例えばデリバリー店舗９３の住所や、ＩＰアドレス等のアドレス情報を意味する。デリバリー店舗画像は、デリバリー店舗ＩＤに対応するデリバリー店舗９３を表したアイコンやロゴマーク等の画像情報である。なお、デリバリー店舗管理テーブル３５２のデータ構成は、図６の例に限らないものとする。

図７は、実施形態に係るデリバリーメニュー管理テーブル３５３のデータ構成の一例を示す図である。デリバリーメニュー管理テーブル３５３は、各デリバリー店舗９３のデリバリー店舗ＩＤに関連付けて、当該デリバリー店舗ＩＤに対応するデリバリー店舗９３が提供（調理）可能な各商品（メニュー）に関するメニュー情報を記憶する。サーバ装置３０は、例えば、外部サービスサーバ５０を介して取得した各デリバリー店舗９３のメニュー情報を、デリバリーメニュー管理テーブル３５３に記憶する。

メニュー情報は、例えば、商品（メニュー）の商品ＩＤ、商品名、一般名、価格、商品画像、説明、調理時間、および配膳時間等を含む。

商品ＩＤは、各デリバリー店舗９３で販売される商品を識別するための識別情報である。商品名は、商品ＩＤに対応する商品の商品名（品目、正式名称等）を示す情報である。一般名は、商品名の一般名や略称、呼称を示す情報である。例えば、デリバリー店舗９３の一つであるデリバリー店舗Ａで販売される「ビール」が「Ａビール大」及び「Ａビール中」、デリバリー店舗９３の他の一つであるデリバリー店舗Ｂで販売される「ビール」の名称が「Ｂビール」である場合を想定する。この場合、デリバリー店舗Ａのデリバリー店舗ＩＤに関連付けて、「Ａビール大」及び「Ａビール中」を示す商品ＩＤ及び商品名がそれぞれ登録されるとともに、これら商品ＩＤの各々に関連付けて一般名「ビール」が登録される。また、デリバリー店舗Ｂのデリバリー店舗ＩＤに関連付けて、「Ｂビール」を示す商品ＩＤ及び商品名が登録されるとともに、この商品ＩＤに関連付けて一般名「ビール」が登録される。

価格は、商品ＩＤに対応する商品の単価を示す情報である。商品画像は、商品ＩＤに対応する商品を表す写真やイラスト等の画像データ（商品画像）である。説明は、商品ＩＤに対応する商品の説明文や、調理に要する目安の時間、デリバリー店舗ＩＤに対応する店舗での人気度等を示す情報である。

調理時間は、デリバリー店舗９３での調理に要する目安の時間である。配膳時間は、リモートレストラン９１での配膳に要する目安の時間である。

なお、デリバリーメニュー管理テーブル３５３のデータ構成は、図７の例に限らないものとする。また、サーバ装置３０は、デリバリーメニュー管理テーブル３５３のメニュー情報を、外部サービスサーバ５０から定期的または随時取得することで、所定のタイミングでメニュー情報を更新する形態としてもよい。

図８は、実施形態に係るユーザ管理テーブル３５４のデータ構成の一例を示す図である。ユーザ管理テーブル３５４は、各ユーザのユーザＩＤに関連付けて、当該ユーザＩＤに対応するユーザに関するユーザ情報を記憶する。ここで、ユーザＩＤは、各ユーザを識別するための識別情報である。

ユーザ情報は、例えば、ユーザ名、住所、連絡先、及び決済用情報等を含む。ユーザ名は、ユーザＩＤに対応するユーザの名前を示す情報である。住所は、ユーザＩＤに対応するユーザの住所や居所を示す情報である。連絡先は、ユーザＩＤに対応するユーザの連絡先を示す情報である。連絡先には、ユーザが所持するユーザ端末２０の電話番号や端末ＩＤ等の識別情報が登録される。決済用情報は、クレジットカード決済や電子マネー決済等の電子決済に係る情報である。決済用情報は、例えばクレジットカード番号等の情報を一または複数保持し、商品の代金を電子決済で支払う際に使用される。

なお、ユーザ管理テーブル３５４のデータ構成は、図６の例に限らないものとする。例えば、ユーザ管理テーブル３５４は、各ユーザのユーザＩＤに関連付けて、そのユーザＩＤに対応するユーザの性別や年齢、嗜好等の情報を記憶してもよい。

ここで、サーバ装置３０は、ユーザ管理テーブル３５４で管理するユーザのユーザＩＤに対応付けて、ユーザのアイコン画像を記憶していてもよい。当該アイコン画像は、リモート飲み会の開催中に各端末に表示させる画面において、各種情報に添えて表示されることで、当該情報を修飾する（つまり当該情報にアイコン画像のユーザが関係していることを示す）。なお、アイコン画像は、例えばユーザ管理テーブル３５４が記憶する。以下、本実施形態では、ユーザ管理テーブル３５４がアイコン画像を記憶しているとする。

図９は、実施形態に係る予約管理テーブル３５５のデータ構成の一例を示す図である。予約管理テーブル３５５は、予約ＩＤに関連付けて、当該予約ＩＤに関する予約情報を記憶する。

ここで、予約ＩＤは、リモート飲み会の利用予約を識別するための識別情報である。サーバ装置３０は、ユーザからユーザ端末２０等を介してリモート飲み会の利用予約を受け付ける毎に、ユニークな予約ＩＤ（例えば、昇順の番号）を発行する。

予約情報は、例えば、予約日時、ユーザＩＤ、参加場所（リモートレストランＩＤまたは自宅）、端末ＩＤ、及びログイン日時等の情報を含む。

予約日時は、リモート飲み会を行う予定の日時を示す情報である。予約日時は、例えば、開始日時と終了日時との期間によって表される。

ユーザＩＤには、リモート飲み会に参加するユーザのユーザＩＤが登録される。予約ＩＤの各々には、１または複数のユーザＩＤを関連付けることが可能となっており、同一の予約ＩＤに関連付けられたユーザＩＤは、同一のリモート飲み会に参加するグループとして管理される。換言すると、予約ＩＤは、各グループを識別するための識別子としても機能する。以下、同一の予約ＩＤに関連付けられたユーザＩＤまたは当該ユーザＩＤに対応するユーザを、同一グループの属するユーザ等とも表記する。

端末ＩＤには、リモート飲み会にリモートレストラン９１から参加する場合には、当該リモートレストラン９１で使用される席端末１０の識別情報が登録される。またこの場合、ログイン日時には、端末ＩＤに対応する席端末１０の使用を開始した日時が登録される。一方、リモート飲み会に自宅から参加した場合、端末ＩＤには、ユーザ端末２０の識別情報が登録される。またこの場合、ログイン日時には、ユーザ端末２０でリモート飲食提供システム１にログインした日時が登録される。

本実施形態では、予約情報に含まれる情報のうち、予約日時、ユーザＩＤ及び参加場所は、リモート飲み会の開催前に登録されることを想定している。また、予約情報に含まれる情報のうち、端末ＩＤ及びログイン日時は、リモート飲み会の開催日当日、つまりユーザＩＤに対応するユーザが参加場所からリモート飲食提供システム１にログインした際に登録されることを想定している。

参加場所は、自宅でない場合には、リモート飲み会の開催日当日、ユーザがリモートレストラン９１に来店した際に、そのリモートレストラン９１のリモートレストランＩＤが登録される形態としてもよい。あるいは、ユーザとユーザが来店するリモートレストラン９１を関連付けて登録してもよい。例えば、予約ＩＤの予約情報に登録されるユーザＩＤと関連付けて、リモートレストラン９１を事前に登録してもよい。参加場所が自宅の場合には、自宅であることを示す情報が登録される。自宅であることを示す情報は、例えば、リモートレストランＩＤと同じコード体系のもので、全リモートレストランＩＤと重複しない値である。

なお、予約管理テーブル３５５のデータ構成は、図９の例に限らないものとする。例えば、予約管理テーブル３５５は、予約ＩＤに関連付けて、そのリモート飲み会の名称や説目を示す情報を記憶してもよい。また、予約管理テーブル３５５は、ユーザＩＤに関連付けて、そのリモート飲み会の主催者や幹事を示す情報を記憶してもよい。以下、本実施形態では、予約管理テーブル３５５は、主催者を示す情報をユーザＩＤに関連付けて記憶しているとする。

図１０は、実施形態に係るオーダ管理テーブル３５６のデータ構成の一例を示す図である。オーダ管理テーブル３５６は、予約ＩＤに関連付けて、その予約ＩＤに対応するリモート飲み会でオーダ（注文）された商品に関するオーダ履歴情報を記憶する。

オーダ履歴情報は、例えば、オーダＩＤ、オーダ元ユーザＩＤ、オーダ先ユーザＩＤ、参加場所（リモートレストランＩＤまたは自宅）、商品ＩＤ、数量、支払済フラグ等の情報を含む。

ここで、オーダＩＤは、各オーダを識別するための識別情報である。サーバ装置３０は、ユーザ（席端末１０またはユーザ端末２０）から商品のオーダを受け付ける毎に、ユニークなオーダＩＤ（例えば、昇順の番号）を発行する。

オーダ元ユーザＩＤには、商品のオーダを行ったユーザのユーザＩＤが登録される。オーダ先ユーザＩＤには、オーダされた商品の提供先となるユーザのユーザＩＤが登録される。例えば、ユーザ自身が自分で飲食する商品をオーダした場合、オーダ元ユーザＩＤと、オーダ先ユーザＩＤとには同一のユーザＩＤが登録される。また、例えば、或るユーザが他のユーザが飲食する商品をオーダした場合、オーダ元ユーザＩＤと、オーダ先ユーザＩＤとには異なるユーザＩＤが登録される。

参加場所には、オーダ先のリモートレストランＩＤまたは自宅であることを示す情報（上述）が登録される。つまり、オーダ先ユーザＩＤのユーザが、リモートレストラン９１に存在するのであれば、参加場所には、オーダ先ユーザＩＤのユーザが存在するリモートレストラン９１のリモートレストランＩＤが登録される。また、オーダ先ユーザＩＤのユーザが、自宅に存在するのであれば、参加場所には、自宅であることを示す情報が登録される。

商品ＩＤには、オーダの対象となった商品の商品ＩＤが登録される。数量には、オーダの対象となった商品の数量が登録される。

また、支払済フラグには、オーダの対象となった商品の支払いが支払済か否かを示すフラグ情報が登録される。本実施形態では、後述するように、或るユーザが他のユーザに商品をプレゼントするような場合に（以下、このオーダ方法を「おごリオーダ」等ともいう）、その商品の支払いを先に行うように構成されている。つまり、支払済フラグには、オーダ元ユーザＩＤとオーダ先ユーザＩＤとが異なり、且つオーダ元ユーザＩＤに対応するユーザが商品の代金を支払う場合に、支払済を示すフラグが登録される。換言すると、支払済フラグは、おごりオーダが行われたか否かを示す指標ともなる。図１０では、未支払をフラグ“０”、支払済をフラグ“１”とした場合を示している。

なお、オーダ管理テーブル３５６のデータ構成は、図１０の例に限らないものとする。例えば、オーダ管理テーブル３５６は、オーダされた日時を示す情報を記憶してもよい。

図１１は、実施形態に係る配達状況管理テーブル３５７のデータ構成の一例を示す図である。配達状況管理テーブル３５７は、デリバリー注文ＩＤに関連付けて、そのデリバリー注文ＩＤに対応するリモート飲み会でオーダ（注文）された商品に関する配達状況情報を記憶する。

ここで、デリバリー注文ＩＤは、各デリバリー注文を識別するための識別情報である。サーバ装置３０は、ユーザ（席端末１０またはユーザ端末２０）から受け付けたオーダのオーダＩＤが発行される毎に、ユニークなデリバリー注文ＩＤ（例えば、昇順の番号）を発行する。

配達状況情報は、例えば、オーダＩＤ、オーダ元ユーザＩＤ、オーダ先ユーザＩＤ、参加場所（リモートレストランＩＤまたは自宅）、商品ＩＤ、数量、配達状況フラグ、ドライバー連絡先等の情報を含む。オーダＩＤ、オーダ元ユーザＩＤ、オーダ先ユーザＩＤ、参加場所、商品ＩＤおよび数量は、オーダ管理テーブル３５６と同じ値が転記される。

また、配達状況フラグには、オーダの対象となった商品の配達状況が配達済か否かを示すフラグ情報が登録される。図１１では、未配達をフラグ“０”、配達済をフラグ“１”とした場合を示している。

ドライバー連絡先は、ドライバー端末６０と通信するための情報であって、例えば、ドライバー専用のアプリケーションを提供するシステムにおけるＩＤ情報、或いはメールアドレスや電話番号などである。サーバ装置３０は、オーダ毎に、外部サービスサーバ５０にドライバー９４の割り当てを依頼し、割り当てられたドライバー９４の連絡先の提供を外部サービスサーバ５０から受け、提供された連絡先を配達状況管理テーブル３５７に記憶させる。また、サーバ装置３０は、ドライバー連絡先を用いて、ドライバー端末６０と通信することにより、配達状況を把握するための情報を取得する。

なお、配達状況管理テーブル３５７のデータ構成は、図１１の例に限らないものとする。例えば、配達状況管理テーブル３５７は、オーダされた日時を示す情報を記憶してもよい。

次に、図１２を参照して、サーバ装置３０、席端末１０またはユーザ端末２０、および受注端末４０の機能構成について説明する。図１２は、実施形態に係るサーバ装置３０、席端末１０またはユーザ端末２０、および受注端末４０の機能構成の一例を示す図である。

まず、席端末１０（ユーザ端末２０）は、通信制御部２１と、出力制御部２２と、操作受付部２３とを機能部として備える。

席端末１０が備える機能部の一部又は全ては、席端末１０のプロセッサ（例えばＣＰＵ１１）とメモリ（例えばＲＯＭ１２、記憶部１５）に記憶されたプログラムとの協働により実現されるソフトウェア構成であってもよい。また、席端末１０が備える機能部の一部又は全ては、席端末１０に搭載された専用回路等で実現されるハードウェア構成であってもよい。

席端末１０の通信制御部２１は、通信部１４を制御することで、サーバ装置３０や店舗サーバとの間で各種情報（データ）の授受を行う。例えば、通信制御部２１は、撮像部１８及び音声入出力部１９で取得された画像データ及び音声データをサーバ装置３０に送信する。また、例えば、通信制御部２１は、他の席端末１０やユーザ端末２０から送信される画像データ及び音声データを、サーバ装置３０を介して受信する。

出力制御部２２は、表示部１６及び音声入出力部１９を制御することで、各種情報（データ）の出力を行う。例えば、出力制御部２２は、撮像部１８で取得された画像データや、他の席端末１０或いはユーザ端末２０から送信された画像データを表示部１６に表示させる。また、出力制御部２２は、サーバ装置３０と協働することで、各種のＧＵＩを表示部１６に表示させる。また、出力制御部２２は、音声入出力部１９で取得された音声データや、他の席端末１０或いはユーザ端末２０から送信された音声データを音声入出力部１９に出力させる。

操作受付部２３は、操作部１７を介して入力されたユーザの操作内容を受け付ける。例えば、操作受付部２３は、表示部１６に表示されたＧＵＩに対する操作を受け付ける。なお、席端末１０やユーザ端末２０は、本実施形態において、サーバ装置３０の入出力インタフェースとして機能する。

次に、受注端末４０は、通信制御部４１１と、出力制御部４１２と、操作受付部４１３とを、機能部として備える。

受注端末４０が備える機能部の一部又は全ては、受注端末４０のプロセッサ（例えばＣＰＵ４１）とメモリ（例えばＲＯＭ４２、記憶部４５）に記憶されたプログラムとの協働により実現されるソフトウェア構成であってもよい。また、受注端末４０が備える機能部の一部又は全ては、受注端末４０に搭載された専用回路等で実現されるハードウェア構成であってもよい。

受注端末４０の通信制御部４１１は、通信部４４を制御することで、サーバ装置３０や外部サービスサーバ５０との間で、各種情報（データ）の授受を行う。例えば、通信制御部４１１は、席端末１０やユーザ端末２０送信されるオーダ情報を、サーバ装置３０を介して受信する。

出力制御部４１２は、表示部４６を制御することで、各種情報（データ）の出力を行う。例えば、出力制御部２２は、サーバ装置３０から受信したオーダ情報を、表示部４６に表示させる。また、出力制御部４１２は、サーバ装置３０と協働することで、各種のＧＵＩを表示部４６に表示させる。

操作受付部４１３は、操作部４７を介して入力された調理スタッフの操作内容を受け付ける。例えば、操作受付部４１３は、表示部４６に表示されたＧＵＩに対する操作を受け付ける。

そして、サーバ装置３０は、予約受付部３１１と、端末間通信部３１２と、ＧＵＩ提供部３１３と、オーダ受付部３１４と、会計処理部３１５とを、機能部として備える。

サーバ装置３０が備える機能部の一部又は全ては、サーバ装置３０のプロセッサ（例えばＣＰＵ３１）とメモリ（例えばＲＯＭ３２、記憶部３５）に記憶されたプログラムとの協働により実現されるソフトウェア構成であってもよい。また、サーバ装置３０が備える機能部の一部又は全ては、サーバ装置３０に搭載された専用回路等で実現されるハードウェア構成であってもよい。

予約受付部３１１は、リモート飲み会の利用予約を受け付け、受け付けた予約の内容を予約管理テーブル３５５に登録する。予約の受け付け方法は特に問わず、種々の方法を採用することが可能である。

例えば、リモート飲み会の開催日時や利用店舗を指定することが可能なＷｅｂサイトをネットワークＮ上に公開し、そのＷｅｂサイトを介して予約を受け付ける形態としてもよい。この場合、主催者又は幹事となるユーザ（以下、幹事ともいう）はユーザ端末２０を用いてＷｅｂサイトにアクセスし、リモート飲み会の開催日時や、自己のユーザＩＤ、自己が利用するリモートレストラン９１のＩＤ（リモートレストランＩＤ）等を入力することで、リモート飲み会の予約（新規予約）を行う。予約受付部３１１は、新規予約を受け付けると、予約ＩＤを発行し、入力された事項とともに予約管理テーブル３５５に登録する。また、予約受付部３１１は、発行した予約ＩＤをユーザのユーザ端末２０に通知する。そして、幹事は、リモート飲み会の参加メンバーとなる他のユーザにユーザＩＤを通知する。なお、新規予約の際に、幹事以外の他のユーザのユーザＩＤが入力されてもよい。

一方、予約ＩＤの通知を受けた他のユーザは、自己が所持するユーザ端末２０を用いて、上記のＷｅｂサイトに予約ＩＤを指定したアクセスを行う。予約受付部３１１では、予約ＩＤを指定したアクセスと受け付けると、その予約ＩＤに対応する予約情報（開催日時等）を予約管理テーブル３５５から読み出し、アクセス元のユーザ端末２０に視認可能に提供する。そして、他のユーザは、自己のユーザＩＤや自己が利用するリモートレストラン９１のＩＤ（リモートレストランＩＤ）を入力することで、リモート飲み会の予約（追加予約）を行う。予約受付部３１１は、追加予約を受け付けると、先に入力された予約ＩＤの予約情報に、追加予約された事項を追加登録する。

なお、予約受付部３１１は、ユーザ情報に記憶された住所と、各リモートレストラン９１のリモートレストラン情報に記憶された住所とを比較し、ユーザの住所から所定範囲内（例えば３Ｋｍ以内等）に存在するリモートレストラン９１を、利用候補としてユーザに提示する形態としてもよい。

予約受付部３１１は、上記の処理（予約処理）を行うことで、同一のリモート飲み会に参加する各ユーザの、ユーザＩＤと当該ユーザが利用するリモートレストランＩＤとの組を、共通する予約ＩＤに関連付けて予約管理テーブル３５５に記憶する。なお、上記の説明では、予約ＩＤの通知を受けた他のユーザが個人で、予約ＩＤの予約情報に自身のユーザＩＤ等を登録し、追加登録するとしたが、これに限定されなくてもよい。例えば、代表者が、事前に参加者のユーザＩＤを取得している場合には、代表者がまとめて参加者のユーザＩＤを登録してもよい。また、予約処理完了後、ユーザＩＤの登録が完了したユーザに対しては、予約ＩＤと、ユーザＩＤとが関連付けられた二次元コード情報あるいは当該二次元コード情報を表示するためのリンク情報をユーザ端末２０が取得してもよい。例えば、ユーザ端末２０が予約当日に、二次元コード情報を表示し、表示された二次元コード情報を席端末１０が読み込むことでログイン処理が実行されるとしてもよい。

端末間通信部３１２は、予約受付部３１１とともに管理手段の一例として機能する。端末間通信部３１２は、リモートレストラン９１の席端末１０からアクセスを受け付け、アクセス元のリモートレストラン９１（リモートレストランＩＤ）及び席端末１０（端末ＩＤ）と、当該席端末１０を操作するユーザ（ユーザＩＤ）とを関連付けて管理する。また、端末間通信部３１２は、ユーザ端末２０からアクセスを受け付け、アクセス元のユーザ端末２０の連絡先（電話番号や端末ＩＤ等の識別情報）と、当該ユーザ端末２０を操作するユーザ（ユーザＩＤ）とを関連付けて管理する。

また、端末間通信部３１２は、通信制御手段の一例である。端末間通信部３１２は、同一の予約ＩＤに関連付けられたユーザ、つまり同一グループに属するユーザの席端末１０およびユーザ端末２０同士を、通信可能に接続する。

具体的には、端末間通信部３１２は、席端末１０から予約ＩＤ及びユーザＩＤ等の参加情報を指定したアクセスを受け付けると、指定された予約ＩＤに対応する予約情報を予約管理テーブル３５５から特定する。端末間通信部３１２は、特定した予約情報に指定されたユーザＩＤが含まれるか否かを判定するログイン処理を実行する。端末間通信部３１２は、指定されたユーザＩＤが予約情報に含まれた場合、そのユーザＩＤに関連付けて、アクセス元の席端末１０の端末ＩＤと、現在の日時（ログイン日時）とを予約情報に追加登録する。

ユーザがユーザ端末２０によって参加した場合も同様に、端末間通信部３１２は、ユーザ端末２０から予約ＩＤ及びユーザＩＤ等の参加情報を指定したアクセスを受け付けると、指定された予約ＩＤに対応する予約情報を予約管理テーブル３５５から特定する。端末間通信部３１２は、特定した予約情報に指定されたユーザＩＤが含まれるか否かを判定するログイン処理を実行する。端末間通信部３１２は、指定されたユーザＩＤが予約情報に含まれた場合、そのユーザＩＤに関連付けて、アクセス元のユーザ端末２０の連絡先（電話番号や端末ＩＤ等の識別情報）と、現在の日時（ログイン日時）とを予約情報に追加登録する。

そして、端末間通信部３１２は、予約情報に端末ＩＤ及びログイン日時を登録すると、その予約情報に登録された端末ＩＤ（または連絡先）の席端末１０（またはユーザ端末２０）同士を通信可能に接続するための制御を行う。これにより、同一の予約ＩＤに関連付けられた席端末１０およびユーザ端末２０同士でデータ共有を行うことができるため、同一グループに属するユーザは、席端末１０の各々で撮像された画像（顔画像）を見ながら、他のユーザと会話することができる。

なお、端末間通信部３１２は、席端末１０からのアクセス時に、席端末１０の端末ＩＤと当該席端末１０が属するリモートレストラン９１のリモートレストランＩＤとを予約情報に登録する形態としてもよい。

同様に、端末間通信部３１２は、ユーザ端末２０からのアクセス時に、ユーザ端末２０の連絡先（電話番号や端末ＩＤ等の識別情報）と、当該ユーザ端末２０を所持するユーザの参加場所（例えば自宅であることを示す情報）とを、予約情報に登録する形態としてもよい。

また、端末間通信部３１２は、席端末１０（またはユーザ端末２０）から受け付けたユーザＩＤが、該当する予約ＩＤの予約情報に含まれない場合、アクセスを拒否する形態としてもよいし、予約情報に追加登録する形態としてもよい。

ＧＵＩ提供部３１３は、提供手段の一例である。ＧＵＩ提供部３１３は、席端末１０およびユーザ端末２０に対し各種のＧＵＩを提供する。具体的には、ＧＵＩ提供部３１３は、各端末（席端末１０およびユーザ端末２０）の参加場所（リモートレストラン９１またはユーザ自宅９２）にデリバリー可能な商品を示すメニュー情報を含む画面を、提供する。また、このメニュー情報の画面において、ＧＵＩ提供部３１３は、端末間通信部３１２で通信可能に接続された同一グループの端末同士で各メンバーのメニュー情報を、相互に閲覧可能に提供する。

また、ＧＵＩ提供部３１３は、席端末１０およびユーザ端末２０の各々に対し、商品のオーダを行うための画面や会計を行うための画面等を提供する。ＧＵＩ提供部３１３が提供する各種操作画面については後述する。

オーダ受付部３１４は、注文受付手段の一例である。オーダ受付部３１４は、メニュー情報が提供された席端末１０およびユーザ端末２０の何れかから商品のオーダを受け付け、オーダされた商品に関する情報（オーダ情報）を、当該商品を提供するデリバリー店舗９３の受注端末４０に通知する。

また、オーダ受付部３１４は、商品のオーダを受け付ける毎に、注文を行った席端末１０またはユーザ端末２０のユーザのユーザＩＤ（オーダ元ユーザＩＤ）と、注文された商品を提供する先のユーザのユーザＩＤ（オーダ先ユーザＩＤ）とを特定する。そして、オーダ受付部３１４は、特定したユーザＩＤに対応する予約ＩＤの下、新たに発行したオーダＩＤに関連付けて、特定したユーザＩＤ、注文先の店舗ＩＤ、商品ＩＤ等の情報をオーダ履歴情報としてオーダ管理テーブル３５６に登録する。

会計処理部３１５は、会計手段の一例である。会計処理部３１５は、オーダ受付部３１４が受け付けた商品の代金を、当該商品を提供するデリバリー店舗９３に支払う会計処理を実行する。具体的には、会計処理部３１５は、ユーザ管理テーブル３５４に記憶された決済用情報を用いて、オーダされた商品の代金を支払う会計処理を実行する。

なお、商品代金の支払いは、決済用情報を用いた方法に限らないものとする。例えば、二次元コード情報等を用いたコード決済や現金決済等の他の支払い方法であってもよい。この場合、会計処理部３１５は、ユーザ端末２０や店舗サーバ等の装置から、ユーザＩＤとともに、商品代金の支払いが完了したことを示す情報を受信したことを条件に、そのユーザの支払が完了したと判断する。

以上のような構成のリモート飲食提供システム１において、システムが含む各装置（席端末１０、ユーザ端末２０、サーバ装置３０、受注端末４０、外部サービスサーバ５０、ドライバー端末６０、キッチン端末７０）は、図１３に示すようにデータの送受信を行う。これにより、リモート飲食提供システム１が機能する。図１３は、実施形態に係る各装置間のデータ送受信の一例を示す図である。この図１３で示す一例は、本システムの概要の理解のために単純化したものである。なお、リモート飲み会の予約は事前に行われているものとする。

まず、外部サービスサーバ５０は、各デリバリー店舗９３の受注端末４０から、当該店舗の提供する商品の情報（メニュー情報）を取得し、記憶する（ステップＳ５０１）。また、外部サービスサーバ５０は、各ドライバー９４のドライバー端末６０にアクセスして各ドライバー９４の稼働状況の情報（稼働情報）を取得し、記憶する（ステップＳ５０２）。これらの工程（ステップＳ５０１，Ｓ５０２）は、随時行われる。

サーバ装置３０は、外部サービスサーバ５０にアクセスしてメニュー情報を取得し、記憶部３５のデリバリーメニュー管理テーブル３５３に記憶させる（ステップＳ３０１）。この工程は、随時行われる。

席端末１０およびユーザ端末２０は、リモート飲食提供サービスの利用開始（つまりリモート飲み会の開始）にあたり、サーバ装置３０に対し、ログイン操作を行う（ステップＳ１０１）。これを受けたサーバ装置３０は、ログインに伴い、リモート飲み会開始に際しての所定の処理（後述）を行う（ステップＳ３０２）。

席端末１０およびユーザ端末２０は、表示されたメニューから選択する操作を行うことで、商品の注文を行う（ステップＳ１０２）。サーバ装置３０は、注文を受け付けると、まず、受注端末４０に、当該注文の情報を送信する（ステップＳ３０３）。注文の情報を受信した受注端末４０は、デリバリー店舗９３の調理担当者が見るための画面に、注文にかかる情報を表示する（ステップＳ４０１）。調理担当者は、受注端末４０に注文を受け付けた旨の操作を行い、注文にかかる商品の調理を行う。

次に、サーバ装置３０は、外部サービスサーバ５０に対し、ドライバー９４の割り当てを依頼する（ステップＳ３０４）。外部サービスサーバ５０は、割り当て依頼を受信すると、注文の内容に適するドライバー９４を選択し（ステップＳ５０３）、当該ドライバー９４の連絡先をサーバ装置３０に送信する（ステップＳ５０４）。

サーバ装置３０は、外部サービスサーバ５０からドライバー９４の連絡先を受信すると、当該ドライバー９４の連絡先に連絡して、注文された商品の配送（デリバリー）を依頼する（ステップＳ３０５）。ドライバー９４が所持するドライバー端末６０は、サーバ装置３０からの依頼を受信すると（ステップＳ６０１）、依頼を受託した旨の返信をする（ステップＳ６０２）。

受注端末４０は、商品が準備できた旨の操作を受けると、サーバ装置３０に所定の信号を送信する（ステップＳ４０２）。これを受信したサーバ装置３０は、オーダ元の端末（席端末１０またはユーザ端末２０）に、調理完了を報告する（ステップＳ３０６）。

また、オーダ先ユーザの参加場所がリモートレストラン９１である場合、サーバ装置３０は、参加場所のリモートレストラン９１のキッチン端末７０に、配膳のための情報を報知する（ステップＳ３０７）。報知内容は、例えば、デリバリーされてくる予定の時刻や、商品の画像、適する食器の形状や大きさ、注文者の席を識別するための情報などである。キッチン端末７０は、サーバ装置３０から配膳のための情報を受信すると、当該受信した情報を配膳スタッフに向けた情報として画面表示や音声などにより報知する（ステップＳ７０１）。

なお、図１３に示していないが、ドライバー端末６０は、サーバ装置３０に、配達状況を随時報告する。ドライバー端末６０から報告を受けたサーバ装置３０は、オーダ元の端末（席端末１０またはユーザ端末２０）に、配達状況を随時報告する。

さて、サーバ装置３０は、ＧＵＩ提供部３１３が席端末１０やユーザ端末２０に提供する画面に対応した操作に従って、各種処理を実行する。そのため、以下では、席端末１０やユーザ端末２０の表示部１６に表示される画面（図１４～図２２、図２３）を参照して、サーバ装置３０の動作を説明する。なお、リモート飲み会の予約は事前に行われているものとする。

まず、リモート飲み会開始に際しての所定の処理（上述のステップＳ３０２）について説明する。端末間通信部３１２では、席端末１０またはユーザ端末２０から予約ＩＤとユーザＩＤとを指定したアクセスを受け付けると、上述したログイン処理を実行することで予約情報を特定する。なお、参加場所がリモートレストラン９１の場合、ログイン処理は、ユーザ端末２０で表示された二次元コード情報を、席端末１０のコードリーダ(不図示)が読み込むことで、二次元コード情報に関連付けられた予約ＩＤとユーザＩＤとを取得し、予約情報を特定するとしてもよい。また、端末間通信部３１２は、特定した予約情報に、アクセス元の席端末１０の端末ＩＤとログイン日時とを登録する。

次いで、端末間通信部３１２は、予約情報に含まれる予約日時と現在日時とを比較し、リモート飲み会の開始日時に達した否かを判定する。

ここで、開始日時に達していないと判定した場合、端末間通信部３１２は、ＧＵＩ提供部３１３と協働することで、席端末１０（参加場所がユーザ自宅９２のユーザの場合にはユーザ端末２０）の表示部１６に、開始日時に達していないことを通知する待機画面（図示せず）を表示させる。かかる待機画面では、例えば、開始日時までのカウントダウンが表示されてもよい。

また、開始日時に達した又は達していると判定した場合、端末間通信部３１２は、ＧＵＩ提供部３１３と協働することで、席端末１０（参加場所がユーザ自宅９２のユーザの場合にはユーザ端末２０）の表示部１６に、リモート飲み会の開始を指示することが可能な開始画面（図１４参照）を表示させる。

図１４は、実施形態の席端末１０またはユーザ端末２０に表示される画面の一例を示す図である。図１４は、開始画面１００の表示例を示している。図１４に示すように、開始画面１００は、リモート飲み会の開始を指示するための操作子であるスタートボタン１０１を有する。

端末間通信部３１２は、席端末１０またはユーザ端末２０からスタートボタン１０１の操作を受け付けると、予約情報に登録された端末ＩＤの席端末１０およびユーザ端末２０間の通信を確立し、同一グループの席端末１０およびユーザ端末２０間でデータ共有が可能な状態を実現する。

また、ＧＵＩ提供部３１３は、席端末１０またはユーザ端末２０からスタートボタン１０１の操作を受け付けると、席端末１０およびユーザ端末２０間で共有されるデータ（画像データ）を表示するためのメイン画面１１０（図１５参照）を、席端末１０およびユーザ端末２０の表示部１６に表示させる。

図１５は、実施形態の席端末１０またはユーザ端末２０に表示される画面の他の例を示す図である。図１５では、メイン画面１１０の表示例を示している。ここで、メイン画面１１０は、主たる表示画面の一例である。

図１５に示すように、メイン画面１１０は、タイトル表示欄１１１や、リモート飲み会の参加人数に応じて分割された複数のサブ画面を有する。図１５では、ユーザＡ～ユーザＣの３人のユーザに応じて、メイン画面１１０を３つのサブ画面１１２，１１３，１１４に分割した例を示している。

サブ画面１１２，１１３，１１４の各々には、各ユーザが操作する端末（席端末１０またはユーザ端末２０）の端末ＩＤや、当該端末を操作するユーザのユーザＩＤ、席端末１０が所属するリモートレストラン９１のリモートレストランＩＤ等が対応付けられる。また、サブ画面１１２，１１３，１１４の各々には、対応する端末ＩＤの端末（席端末１０またはユーザ端末２０）で取得（撮像）された画像データが表示される。また、サーバ装置３０から席端末１０およびユーザ端末２０の各々には、席端末１０およびユーザ端末２０で取得された音声データが提供され、出力制御部２２によって音声入出力部１９から出力される。

これにより、席端末１０またはユーザ端末２０のユーザは、メイン画面１１０を視聴することで、リモート飲み会の参加者それぞれと、互いの顔を見ながら会話することができる。

また、サブ画面１１２，１１３，１１４の各々には、当該サブ画面１１２，１１３，１１４に対応付けられたユーザＩＤのユーザの参加場所１１５や、アイコン画像１１７が表示される。具体的には、ＧＵＩ提供部３１３は、ユーザＩＤに対応するアイコン画像を、ユーザ管理テーブル３５４から読み出す。また、ＧＵＩ提供部３１３は、各ユーザの参加場所を、予約管理テーブル３５５から読み出す。そして、ＧＵＩ提供部３１３は、読み出したアイコン画像及び参加場所を、アイコン画像１１７及び参加場所１１５として、サブ画面１１２，１１３，１１４に重ねて表示させる。

また、サブ画面１１２，１１３，１１４のいずれかに重ねて、主催者ラベル１１６が表示される。具体的には、ＧＵＩ提供部３１３は、主催者を示す情報が関連付けられているユーザＩＤを、予約管理テーブル３５５から読み出す。そして、ＧＵＩ提供部３１３は、読み出したユーザＩＤのユーザが表示されるサブ画面１１２に重ねて、主催者ラベル１１６を表示させる。

図１５では、左のサブ画面１１２にユーザ名に基づいた「Ａさん」と、ユーザＡの参加場所１１５として、ユーザＡが利用するリモートレストランＡのリモートレストラン名とを表示した例を示している。また、中央のサブ画面にユーザ名に基づいた「Ｂさん」と、ユーザＢの参加場所１１５として、ユーザＢが利用するリモートレストランＢのリモートレストラン名とを表示した例を示している。また、右のサブ画面にユーザ名に基づいた「Ｃさん」と、ユーザＣの参加場所１１５である「自宅」を表示した例を示している。

これにより、席端末１０およびユーザ端末２０のユーザは、メイン画面１１０を見ることで、リモート飲み会に参加した各ユーザのアイコン画像１１７や、各ユーザの参加場所１１５を、容易に確認することができる。また、各参加者は、主催者ラベル１１６により主催者を認識することができる。

なお、メイン画面１１０は、席端末１０またはユーザ端末２０を操作するユーザ本人以外の画像を表示する設定としてもよい。

メイン画面１１０には、各参加場所１１５にデリバリー可能な商品を示すメニュー情報の表示を指示するための注文ボタン１２１が設けられる。ＧＵＩ提供部３１３は、席端末１０またはユーザ端末２０から注文ボタン１２１の操作を受け付けると、デリバリー可能なメニュー情報を、デリバリーメニュー管理テーブル３５３から読み出す。ここで、上述の「デリバリー可能なメニュー情報」の初期状態は、操作者すなわちオーダ元ユーザの参加場所にデリバリー可能な商品を示すものである。そして、ＧＵＩ提供部３１３は、読み出したメニュー情報に基づくメニュー画面１３０（後述、図１６）を、操作元の端末（席端末１０またはユーザ端末２０）の表示部１６に表示させる。

注文ボタン１２１の操作後、サブ画面１１２，１１３，１１４のいずれかの表示領域に触れる等サブ画面を選択する操作が行われた場合には、ＧＵＩ提供部３１３は、選択されたサブ画面に表示されたユーザが、商品のデリバリー先として指定されたと認識する。例えば、ユーザＡが使用中の席端末１０において、注文ボタン１２１が操作された後に、ユーザＣを表示するサブ画面１１４が選択された場合には、ＧＵＩ提供部３１３は、ユーザＡが、ユーザＣにプレゼントする商品をこれから注文する、と認識する。つまりこの場合、ＧＵＩ提供部３１３は、この後の操作において、オーダ元がユーザＡでオーダ先がユーザＣの注文が行われる、と認識する。

そして、ＧＵＩ提供部３１３は、上述のように認識したオーダ先に即したメニュー画面１３０（後述、図１６）を、操作元の端末（席端末１０またはユーザ端末２０）の表示部１６に表示させる。つまり、上記例で言えば、ユーザＡの席端末１０に、ユーザＣの自宅にデリバリー可能なメニュー情報を、表示する。もちろん、注文ボタン１２１の操作後にサブ画面１１２，１１３，１１４のいずれかの選択操作がない状態では、ＧＵＩ提供部３１３は、オーダ元およびオーダ先がともに操作元と同一であると認識し、オーダ元ユーザの参加場所にデリバリー可能な商品を示すメニュー情報を表示させている。

ＧＵＩ提供部３１３が行う「デリバリー可能とするメニュー情報」の抽出処理の流れの一例は、以下の通りである。ＧＵＩ提供部３１３は、まず、操作を受け付けると、オーダ先となるユーザのユーザＩＤに関連付けられた参加場所を、予約管理テーブル３５５で確認し、これを配達場所としてＲＡＭ３３に一時的に記憶させる。

次にＧＵＩ提供部３１３は、デリバリー店舗管理テーブル３５２が記憶する各デリバリー店舗９３の住所と、上記配達場所とから、各デリバリー店舗９３から配達場所までの移動に要する時間（移動時間）を算出し、これらをＲＡＭ３３に一時的に記憶させる。次にＧＵＩ提供部３１３は、デリバリーメニュー管理テーブル３５３が記憶する各商品の調理時間および配膳時間を取得し、これらをＲＡＭ３３に一時的に記憶させる。次にＧＵＩ提供部３１３は、移動時間と調理時間と配膳時間との合計時間を算出する。そして、ＧＵＩ提供部３１３は、現在時刻から上記合計時間だけ経過した時刻が、リモート飲み会の終了時刻より所定時間前の時刻（以降、提供完了時刻とする）以前となる商品を、「デリバリー可能な商品を示すメニュー情報」に含める。また、ＧＵＩ提供部３１３は、上記提供完了時刻から上記合計時間だけさかのぼった時刻を、受付終了時刻として認識する。受付終了時刻は、いわゆるラストオーダの時刻である。受付終了時刻を超過した商品は、現在時刻から上記合計時間だけ経過後の時刻が提供完了時刻を超過するので、メニューに表示されない。

上述の「所定時間」は、例えばその商品の飲食に最低限要すると考えられる時間であって例えば２０分などであるが、リモートレストラン９１の裁量で決定されてよく、例えば５分でもよいし、０分としても構わない。以下、本実施形態では、所定時間を２０分とする。つまり、リモート飲み会の終了時刻が図１５に示す通り２２時であれば、ＧＵＩ提供部３１３は、２１時４０分までにオーダ先に提供完了可能な商品を、メニュー情報に含める。

以上により、「デリバリー可能とするメニュー情報」の抽出が行われる。なお、上述の手順は理解しやすさを優先した一例であって、より効率的な抽出手法によってメニュー情報を抽出して構わない。

例えば、上記例では、デリバリー店舗９３から配達場所までの移動時間を、デリバリー可能なメニュー情報の抽出に用いたが、実施にあたっては、移動時間に代えて、例えば、デリバリー店舗９３と配達場所との間の距離を、メニュー情報の抽出に用いてもよい。この場合、例えば、第１段階として、配達場所からの距離が第１の閾値以下のデリバリー店舗９３を抽出する。次に、第２段階として、第１段階で抽出されたデリバリー店舗９３が取り扱う商品のうち、調理時間と配膳時間と上記「所定時間」との合計時間が、第２の閾値以下となる商品を抽出し、メニュー情報に含める。この場合の第２の閾値は、例えば、現在時刻からリモート飲み会の終了時刻までの時間から、第１の閾値の距離の移動に要する時間を減算した値である。

図１６は、実施形態の席端末１０またはユーザ端末２０に表示される画面の他の例を示す図である。図１６では、メニュー画面１３０の表示例を示している。メニュー画面１３０は、メニュー情報を表示するメニュー表示領域１３１を、主たる表示画面であるメイン画面１１０の一部を覆うように重ねて、構成される。

図１６に示すように、ＧＵＩ提供部３１３は、メニュー画面１３０において、サブ画面１１２，１１３，１１４に重ねて、メニュー表示領域１３１を表示する。メニュー表示領域１３１は、オーダ先にデリバリー可能な商品を示すメニュー情報を、表示する。

メニュー表示領域１３１は、１つの商品の情報を表示する矩形の表示欄１３２を、１つ以上含む。図示例のメニュー表示領域１３１では、ＧＵＩ提供部３１３は、複数の表示欄１３２を、サブ画面１１２，１１３，１１４の並び方向に合わせて横一列に並べている。また、ＧＵＩ提供部３１３は、図示例のメニュー表示領域１３１において、表示欄１３２の並び方向に合わせて指を滑らせるような操作を検知した場合、表示欄１３２をスクロールする。なお、ＧＵＩ提供部３１３は、メニュー表示領域１３１の左右両端に設けたボタン１３８が操作を受けた場合にも、表示欄１３２をスクロールする。

ＧＵＩ提供部３１３は、表示欄１３２に、商品名欄１３３、価格欄１３４、店舗画像欄１３５、商品画像欄１３６、提供時間欄１３７等を含める。ＧＵＩ提供部３１３は、商品名欄１３３、価格欄１３４、商品画像欄１３６のそれぞれに、デリバリーメニュー管理テーブル３５３から取得した商品名、価格、商品画像を表示する。また、ＧＵＩ提供部３１３は、店舗画像欄１３５に、デリバリー店舗管理テーブル３５２から取得したデリバリー店舗画像を表示する。また、提供時間欄１３７は、提供までの所要時間を示す欄であって、ＧＵＩ提供部３１３は、この欄に、デリバリーメニュー管理テーブル３５３から取得した調理時間と配膳時間と、上述の移動時間との合計時間を表示させる。

図示例のようなメニュー表示領域１３１を有するメニュー画面１３０によれば、ユーザがメニュー画面１３０を閲覧、操作している間も、他のユーザと会話を継続することができる。

図１７は、実施形態の席端末１０またはユーザ端末２０に表示される画面の他の例を示す図である。図１７では、メニュー画面１３０において、１以上の商品が選択され、且つ、注文を送信する前の表示例を示している。図１７に示すように、ＧＵＩ提供部３１３は、メニュー画面１３０で１以上の商品の選択があった場合、サブ画面１１２，１１３，１１４に重ねて、未確定注文表示領域１４１を表示する。未確定注文表示領域１４１は、商品表示欄１４２と、注文確定ボタン１４４とを含む。

なお、商品表示欄１４２は、メニュー表示領域１３１で選択操作を受けた商品の商品画像を表示する商品画像欄１４３と、商品画像欄１４３に表示された商品を提供するデリバリー店舗９３の店舗画像を表示する店舗画像欄１３５とを有している。

商品表示欄１４２は、メニュー表示領域１３１で商品の選択操作がある都度、増える。図１７に示す例においては、商品表示欄１４２は、メニュー表示領域１３１とともに、メニュー表示領域１３１の下側に、メニュー画面１３０に表示される。これにより、ユーザは、参加者との会話を継続しながら、メニュー情報を閲覧するとともに、商品の選択状況を確認することが、容易に可能となる。

また、図１７に示す例はユーザＡの席端末１０における表示例であるが、商品表示欄１４２に、ＧＵＩ提供部３１３は、オーダ先のユーザのアイコン画像１１７を表示する。これにより、ユーザＡは、自身の飲食用に選んだ商品と、ユーザＣにプレゼントする商品とを、容易に区別することができる。

注文確定ボタン１４４は、未確定注文表示領域１４１に含まれる商品表示欄１４２に表示された商品の注文を確定する操作を受け付ける（上記ステップＳ１０２）。ＧＵＩ提供部３１３は、注文確定ボタン１４４が操作を受けたことを検知すると、未確定注文表示領域１４１に含まれる商品表示欄１４２に表示された商品を、各デリバリー店舗９３の受注端末４０に送信する（上記ステップＳ３０３）。

なお、注文確定ボタン１４４が操作を受けると、ＧＵＩ提供部３１３は、未確定注文表示領域１４１およびメニュー表示領域１３１を消去するとともに注文を受け付けた旨を伝える簡単なダイアログを所定時間表示した後、表示をメイン画面１１０（図１５参照）に戻す。

図１８は、実施形態の席端末１０またはユーザ端末２０の表示部１６に表示される画面の一部分の例を拡大して示す図である。図１８は、上述の表示欄１３２の表示状態の一例を示している。ＧＵＩ提供部３１３は、下記の所定の条件が満たされるとき、表示欄１３２に、受付終了予告１３９を含める。上記の所定の条件は、例えば、「注文の受付終了時刻までの時間が１０分以下」である。つまりこの場合には、注文の受付終了時刻までの時間が１０分以下になると、ＧＵＩ提供部３１３は、表示欄１３２に受付終了予告１３９を含め、ユーザに対して、注文の受付終了までの残り時間（すなわち商品を注文可能な残り時間）を認識可能な情報を、報知する。

図１９は、実施形態における注文可能／不可能の判断を説明する図である。ＧＵＩ提供部３１３は、リモート飲み会の終了時刻が、例えば２２時の場合、所定時間２０分を差し引き、提供完了時刻を、２１時４０分と認識する。また、メニューＥの商品は、調理時間８分、移動時間５分、配膳時間２分の合計が１５分で、つまり、注文確定から提供までの所要時間が１５分の商品である。

この場合、２１時１５分の時点でメニュー表示領域１３１を表示させるにあたり、ＧＵＩ提供部３１３は、提供完了時刻までの残り時間が２５分あるので、メニューＥの表示欄１３２をメニュー表示領域１３１に含める。また、この時点で、注文確定から提供までの所要時間が１５分の商品に対し、提供完了時刻までの残り時間が２５分であって、両者の差は１０分である。つまり、注文の受付終了時刻まであと１０分であるので、その旨を示す受付終了予告１３９を、表示欄１３２に含める。この時点での受付終了予告１３９には、例えば「受付終了まであと１０分」などと表示される。なお、図１８が示すのは、現在時刻がさらに５分進んだ２１時２０分時点の表示欄１３２の例である。

なお、受付終了予告１３９に示す残り時間は、例えば１分ごとのカウントダウン表示でもよいし、より細かい時間間隔でのカウントダウン表示であってもよい。また、受付終了予告１３９は、周囲よりも目を引く色合いや形状、動きで表示されてもよい。

さらに、受付終了予告１３９は、商品を注文可能な残り時間を認識可能な情報として、注文の受付終了時刻までの残り時間でなく、例えば、受付終了時刻を表示してもよい。

このように、受付終了予告１３９が表示されると、ユーザが、その商品が間もなくメニューに表示されなくなることを前もって知ることができるので、利便性が高く好適である。

図２０は、実施形態の席端末１０またはユーザ端末２０に表示される画面の他の例を示す図である。図２０では、ＧＵＩ提供部３１３がユーザＡの席端末１０の表示部１６でメニュー画面１３０に重ねて表示させる確認画面１６１の一例を示している。図２０に示すように、確認画面１６１には、オーダ先ユーザのユーザ名（ユーザＣ）や、当該ユーザに商品をプレゼントすることをオーダ元ユーザ（ユーザＡ）に確認するためのメッセージ１４５が表示される。また、確認画面１６１は、オーダ元ユーザ（ユーザＡ）が操作するボタン１４６，１４７を含む。「はい」のボタン１４６はオーダを行うことを指示する操作を受け付ける。「いいえ」のボタン１４７は、オーダをキャンセルすることを指示する操作を受け付ける。

オーダ元のユーザ（ユーザＡ）は、メッセージ１４５を確認し、問題ないと判断した場合には、「はい」のボタン１４６を操作する。また、オーダ元のユーザ（ユーザＡ）は、メッセージ１４５を確認し、このオーダを行わないと判断した場合には、「いいえ」のボタン１４７を操作する。「はい」のボタン１４６が操作された場合、サーバ装置３０は、ユーザＣが使用するユーザ端末２０に、次に説明する通知画面１６２（図２１参照）を表示させる。

図２１は、実施形態の席端末１０またはユーザ端末２０に表示される画面の他の例を示す図である。図２１では、ＧＵＩ提供部３１３がユーザＣのユーザ端末２０の表示部１６でメニュー画面１３０に重ねて表示させる通知画面１６２の一例を示している。図２１に示すように、通知画面１６２には、オーダ元ユーザ（ユーザＡ）から商品がプレゼントされることについてオーダ先ユーザのユーザ名（ユーザＣ）に確認するためのメッセージ１４８が表示される。また、通知画面１６２は、オーダ先ユーザ（ユーザＣ）が操作するボタン１４６，１４７を含む。「はい」のボタン１４６はオーダを行うことを指示する操作を受け付ける。「いいえ」のボタン１４７は、オーダをキャンセルすることを指示する操作を受け付ける。

オーダ先のユーザ（ユーザＣ）は、メッセージ１４８を確認し、問題ないと判断した場合には、「はい」のボタン１４６を操作する。また、オーダ先のユーザ（ユーザＣ）は、メッセージ１４８を確認し、問題があると判断した場合には、「いいえ」のボタン１４７を操作する。「はい」のボタン１４６が操作された場合、サーバ装置３０は、ユーザＡが使用する席端末１０と決済に関するデータの送受信を行う。

図２２は、実施形態の席端末１０またはユーザ端末２０に表示される画面の他の例を示図である。図２２は、ユーザＡの席端末１０における表示例である。この図に示すように、例えば、メイン画面１１０は、当該メイン画面１１０を表示している端末（席端末１０またはユーザ端末２０）のユーザ（ここではユーザＡ）が注文した商品のうち、提供完了前のものの情報および状況を示すオーダ履歴アイコン１５１を、各商品のオーダ先ユーザのサブ画面１１２，１１４に、表示する。オーダ履歴アイコン１５１は、商品の情報を示す商品画像欄１４３および店舗画像欄１３５を有する。また、オーダ履歴アイコン１５１は、商品の状況を示す状況アイコン１５２，１５３を有する。状況アイコン１５２，１５３は、例えば「配達中」や「調理中」などの文字でもよいし、同様の意味を伝えるイラストでもよい。これにより、各ユーザは、自身が注文した商品の状況を容易に知ることができる。

ここで、図１５～図１７が示すように、メイン画面１１０およびメニュー画面１３０は、注文状況ボタン１２２を備える。ＧＵＩ提供部３１３は、注文状況ボタン１２２が操作を受けると、操作を受けた端末（席端末１０またはユーザ端末２０）の表示部１６に、オーダした商品の状況を示す注文状況画面（図２３参照）を表示させる。

図２３は、実施形態の席端末１０またはユーザ端末２０に表示される画面の他の例を示す図である。注文状況画面は、メイン画面１１０に重ねて表示されるものであっても、単独画面として表示されるものであってもよい。図示例では、全注文者の注文の各々にかかる商品名、注文者、配達先、状況、提供目安時刻が、一覧表示されている。状況は、例えば、「調理」欄、「デリバリー」欄、「盛付」欄のそれぞれについて、「未」、「中」、「済」等を表示する。この例では、「調理」欄が「済」であれば「調理済」を意味し、「デリバリー」欄が「中」であれば「デリバリー中」を意味し、「盛付」欄が「未」であれば「未盛付」を意味する。提供目安時刻は、幅を持たせて表示してよい。なお、図示例では全て文字によってオーダした商品の状況を示しているが、それぞれがアイコンなどの画像で示されていてもよい。

以下、図２４～図２７のフローチャートを参照して、上述したサーバ装置３０の動作例について説明する。

図２４は、実施形態のサーバ装置３０が実行するログイン処理の一例を示すフローチャートである。なお、本処理の前提として、リモート飲み会の予約は行われているものとする。

まず、端末間通信部３１２は、リモートレストラン９１の席端末１０または参加場所がユーザ自宅９２のユーザ端末２０から、当該端末を操作するユーザのユーザＩＤ、リモート飲み会の予約ＩＤ等を含んだ参加情報が送信されると、当該参加情報を受信する（ステップＳ１１）。次いで、端末間通信部３１２は、予約管理テーブル３５５を参照し、参加情報の条件に該当する予約情報を特定する（ステップＳ１２）。

続いて、端末間通信部３１２は、予約情報に含まれる予約日時（開始日時）と、現在日時とを比較し、予約日時に到達したか否かを判定する（ステップＳ１３）、ここで、予約日時に到達していない場合には（ステップＳ１３；Ｎｏ）、端末間通信部３１２は、ＧＵＩ提供部３１３と協働することで、席端末１０またはユーザ端末２０に待機画面を提供し（ステップＳ１４）、ステップＳ１３に処理を戻す。

また、予約日時に到達した場合には（ステップＳ１３；Ｙｅｓ）、端末間通信部３１２は、ＧＵＩ提供部３１３と協働することで、リモート飲み会の開始画面１００を席端末１０またはユーザ端末２０に提供する（ステップＳ１５）。

続いて、端末間通信部３１２は、席端末１０またはユーザ端末２０から開始指示を受け付けるまで待機する（ステップＳ１６；Ｎｏ）。端末間通信部３１２は、席端末１０またはユーザ端末２０から開始指示を受け付けると（ステップＳ１６；Ｙｅｓ）、参加情報を送信した席端末１０またはユーザ端末２０と、予約情報に登録された他のユーザの席端末１０またはユーザ端末２０との間の通信を確立し（ステップＳ１７）、端末間でのデータ共有を開始する（ステップＳ１８）。

そして、ＧＵＩ提供部３１３は、参加情報を送信した席端末１０またはユーザ端末２０にメイン画面１１０を提供し（ステップＳ１９）、本処理を終了する。

サーバ装置３０は、上記の処理を行うことで、リモート飲み会を行うことが可能な環境を、参加場所がユーザ自宅９２のユーザ端末２０に、実現することができる。

図２５は、実施形態のサーバ装置３０が実行するメニュー提供処理の一例を示すフローチャートである。本処理において、ＧＵＩ提供部３１３は、注文ボタン１２１が操作を受けると（ステップＳ２１）、オーダ先のユーザの参加場所を特定し（ステップＳ２２）する。続いてＧＵＩ提供部３１３は、ステップＳ２２で特定した場所に提供可能なメニューを、オーダ元のユーザの端末（席端末１０またはユーザ端末２０）に表示させる（ステップＳ２３）。ここで、上記提供可能なメニュー（商品）は、図１６に示すメニュー画面１３０のメニュー表示領域１３１の表示欄１３２に、商品毎に表示される。

ＧＵＩ提供部３１３は、注文確定ボタン１４４への操作を検知すると注文を受け付けたとし（ステップＳ２４のＹｅｓ）、注文処理を行う（ステップＳ２５）。このステップＳ２５は、図１３におけるステップＳ３０３～Ｓ３０５に相当する。

また、ＧＵＩ提供部３１３は、注文確定ボタン１４４への操作がないとき（ステップＳ２４のＮｏ）、配送先の指定の有無を判断する（ステップＳ２６）。つまり、ＧＵＩ提供部３１３は、サブ画面１１２，１１３，１１４のいずれかの表示領域に触れる等サブ画面を選択する操作が行われた場合には、選択されたサブ画面に表示されたユーザが、商品の配送先として指定されたと判断する。
ステップＳ２６において配送先の指定が行われていなかった場合には（ステップＳ２６のＮｏ）、ＧＵＩ提供部３１３は処理をステップＳ２４に戻す。また、ステップＳ２６において配送先の指定が行われていた場合には（ステップＳ２６のＹｅｓ）、ＧＵＩ提供部３１３は、指定の配送先に提供可能なメニューを表示し（ステップＳ２７）、処理をステップＳ２４に戻す。

図２６は、実施形態のサーバ装置３０が実行するオーダ処理の一例を示すフローチャートである。なお、図２６では、メニュー画面１３０に基づくオーダ操作を、席端末１０から受け付けた場合の処理の一例を示している。

まず、オーダ受付部３１４は、席端末１０から商品のオーダ操作を受け付ける（ステップＳ３１）。次いで。オーダ受付部３１４は、オーダ元のユーザＩＤと、オーダ先のユーザＩＤとが一致するか否かを判定する（ステップＳ３２）。両ユーザＩＤが一致する場合、オーダ受付部３１４は、ユーザ自身が自分で飲食する商品をオーダしたと判断するこの場合、オーダ受付部３１４は、オーダ先のデリバリー店舗９３の受注端末４０にオーダ内容（商品ＩＤ、オーダ元のユーザＩＤ等）を通知する（ステップＳ３３）。また、オーダ受付部３１４は、受け付けたオーダ内容を含むオーダ履歴情報を、オーダ管理テーブル３５６の該当する予約ＩＤに関連付けて登録する（ステップＳ３４）。また、ＧＵＩ提供部３１３は、オーダ先のサブ画面１１２，１１３，１１４に、オーダ履歴アイコン１５１を表示させ（ステップＳ３５）、本処理を終了する。

また、ステップＳ３２で両ユーザＩＤが相違すると判定した場合（ステップＳ３２；Ｎｏ）、オーダ受付部３１４は、商品の代金をオーダ元のユーザが支払う方式（おごり）が指示されているか否かを判定する（ステップＳ３６）。

ここで、オーダ先のユーザが支払う方式が指示されていた場合（ステップＳ３６；Ｎｏ）、オーダ受付部３１４は、オーダ先のユーザが操作する端末（席端末１０またはユーザ端末２０）にオーダ内容を確認するための確認画面を表示させる（ステップＳ３７）。次いで、オーダ受付部３１４は、オーダ先のユーザから回答を受け付けるまで待機する。

ここで、オーダ内容を拒否する回答を受け付けた場合（ステップＳ３８；Ｎｏ）、オーダ受付部３１４は、商品のオーダを行わず本処理を終了する。なお、この場合、オーダ受付部３１４は、その旨を示す結果情報を、オーダ元のユーザが操作する席端末１０に提供してもよい。

また、ステップＳ３８で、オーダ内容を受け付ける同意の回答が得られた場合（ステップＳ３８；Ｙｅｓ）、オーダ受付部３１４は、オーダ先のデリバリー店舗９３の受注端末４０にオーダ内容（商品ＩＤ、オーダ先のユーザＩＤ等）を通知する（ステップＳ３９）。また、オーダ受付部３１４は、受け付けたオーダ内容を含むオーダ履歴情報を、オーダ管理テーブル３５６の該当する予約ＩＤに関連付けて登録する（ステップＳ４０）。また、ＧＵＩ提供部３１３は、オーダ先のサブ画面１１２，１１３，１１４に、オーダ履歴アイコン１５１を表示させ（ステップＳ３５）、本処理を終了する。

一方、ステップＳ３６において、オーダ元のユーザが支払う方式が指示されていた場合（ステップＳ３６；Ｙｅｓ）、オーダ受付部３１４は、オーダ元のユーザが操作する端末（席端末１０またはユーザ端末２０）に、オーダ内容を確認するための確認画面１６１を表示させる（ステップＳ４０）。また、オーダ受付部３１４は、オーダ先のユーザが操作する端末（席端末１０またはユーザ端末２０）に、オーダ内容を確認するための通知画面１６２を表示させる（ステップＳ４１）。そして、オーダ受付部３１４は、各ユーザから回答を受け付けるまで待機する。

ここで、オーダ元及びオーダ先のユーザの何れか一方又は両方から、オーダ内容を拒否する回答を受け付けた場合（ステップＳ４２；Ｎｏ）、オーダ受付部３１４は、商品のオーダを行わず本処理を終了する。なお、オーダ先のユーザがオーダ内容を拒否した場合、オーダ受付部３１４は、その旨を示す結果情報を、オーダ元のユーザが操作する席端末１０に提供してもよい。

また、オーダ元及びオーダ先のユーザの両方で、オーダ内容を受け付ける同意の回答が得られた場合（ステップＳ４２；Ｙｅｓ）、オーダ受付部３１４は、オーダ先のデリバリー店舗９３の受注端末４０にオーダ内容（商品ＩＤ、オーダ先のユーザＩＤ等）を通知する（ステップＳ４４）。また、オーダ受付部３１４は、受け付けたオーダ内容を含むオーダ履歴情報を、オーダ管理テーブル３５６の該当する予約ＩＤに関連付けて登録する（ステップＳ４５）。また、ＧＵＩ提供部３１３は、オーダ先のサブ画面１１２，１１３，１１４に、オーダ履歴アイコン１５１を表示させ（ステップＳ３５）、本処理を終了する。

なお、オーダ元及びオーダ先のユーザの両方で、オーダ内容を受け付ける同意の回答が得られた場合（ステップＳ４２；Ｙｅｓ）、会計処理部３１５は、オーダ元のユーザの決済用情報等に基づいて、オーダされた商品の会計処理（支払い）を実行する。また、会計処理部３１５は、ステップＳ４５で登録したオーダ履歴情報の支払い済フラグを支払い済み“１”に設定する。

図２７は、実施形態のサーバ装置３０が実行する会計処理の一例を示すフローチャートである。なお、図２７では、席端末１０またはユーザ端末２０から受け付けたオーダに係るオーダ履歴情報が、オーダ管理テーブル３５６に登録済みであるとする。

まず、予約受付部３１１は、予約管理テーブル３５５に登録された予約情報に基づき、終了日時に到達した予約ＩＤ（リモート飲み会）が存在するか否かを判定する（ステップＳ５１）。ここで、終了日時に到達した予約ＩＤが存在する場合（ステップＳ５１；Ｙｅｓ）、予約受付部３１１は、その予約ＩＤに関連付けられた端末ＩＤの各々に終了報知画面を提供し（ステップＳ５２）、ステップＳ５３に移行する。また、終了日時に到達した予約ＩＤが存在しないと判定した場合も（ステップＳ５１；Ｎｏ）、ステップＳ５３に移行する。

ステップＳ５３では、会計処理部３１５が、メイン画面１１０やメニュー画面１３０に設けられた会計ボタン１２３（図１５～図１７参照）を介して、リモート飲み会の会計が指示されたか否かを判定する（ステップＳ５３）。ここで、会計指示を受け付けない場合には（ステップＳ５３；Ｎｏ）、会計処理部３１５は、ステップＳ５１に処理を戻す。

また、ステップＳ５３で、会計指示を受け付けた場合（ステップＳ５３；Ｙｅｓ）、会計処理部３１５は、会計対象の予約ＩＤに係るオーダ履歴情報のうち、支払い済フラグが“１”のオーダ履歴情報を除いた、残りのオーダ履歴情報に基づいて支払総額を算出する（ステップＳ５４）。次いで、会計処理部３１５は、ステップＳ５４の算出結果等に基づき、会計対象の予約ＩＤに係る端末（席端末１０またはユーザ端末２０）の各々に会計画面を提供する（ステップＳ５５）。

続いて、会計処理部３１５は、会計画面を提供した席端末１０またはユーザ端末２０の何れかから支払方法を指定する操作を受け付けると（ステップＳ５６）、指定された支払い方法が「個別支払い」及び「割り勘支払い」の何れであるかを判定する（ステップＳ５７）。

ここで、指定された支払い方法が個別支払いの場合（ステップＳ５７；Ｙｅｓ）、会計処理部３１５は、指定された金額を、その支払操作を行ったユーザの支払金額に設定し（ステップＳ５８）、ステップＳ６０に移行する。

一方、指定された支払い方法が割り勘支払いの場合（ステップＳ５７；Ｎｏ）、会計処理部３１５は、支払総額、又は支払総額から支払金額を減算した残額を、未支払いのユーザの人数で除算した割り勘金額を、当該ユーザの支払金額に設定し（ステップＳ５９）、ステップＳ６０に移行する。

ステップＳ６０では、会計処理部３１５が、支払総額から支払金額を減算した残額がゼロか否かを判定する（ステップＳ６０）。ここで、残額がゼロでない場合には（ステップＳ６０；Ｎｏ）、ステップＳ５５に処理を戻すことで、残金等を更新した会計画面を席端末１０またはユーザ端末２０に提供する。

また、ステップＳ６０で、残額がゼロと判定した場合（ステップＳ６０；Ｙｅｓ）、会計処理部３１５は、各ユーザの決済用情報を用いて、当該ユーザに設定した支払金額を取得する会計処理を実行し（ステップＳ６１）、本処理を終了する。

以上のように、本実施形態のサーバ装置３０およびサーバ装置３０が備えるコンピュータが実行するプログラムによれば、複数の場所から参加するコミュニケーション形態の提供と、飲食物の取り寄せと、を両立することができる。つまり、リモート飲み会において参加メンバーとのコミュニケーションを中断することなしに、使用中端末（席端末１０またはユーザ端末２０）の表示部１６にオーダ先へデリバリー可能な商品の情報を表示させて、商品を注文することができる。

なお、上述した実施形態は、上述した各装置が有する構成又は機能の一部を変更することで、適宜に変形して実施することも可能である。そこで、以下では、上述した実施形態に係るいくつかの変形例を他の実施形態として説明する。なお、以下では、上述した実施形態と異なる点を主に説明することとし、既に説明した内容と共通する点については詳細な説明を省略する。また、以下で説明する変形例は、個別に実施されてもよいし、適宜組み合わせて実施されてもよい。

また、上述の実施形態の各装置で実行されるプログラムは、ＲＯＭや記憶部等に予め組み込まれた状態で提供される。上述の実施形態の各装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ－ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ－Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。

さらに、上述の実施形態の各装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上述の実施形態の各装置で実行されるプログラムをインターネット等のネットワーク経由で提供又は配布するように構成してもよい。

以上、本発明の実施形態を説明したが、この実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これらの新規な実施形態やその変形例は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これらの実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１ …リモート飲食提供システム、
１０ …席端末、
１１ …ＣＰＵ、１２…ＲＯＭ、１３…ＲＡＭ、１４…通信部、１５…記憶部、
１６ …表示部、１７…操作部、１８…撮像部、１９…音声入出力部、
２０ …ユーザ端末、
２１ …通信制御部、２２…出力制御部、２３…操作受付部、
３０ …サーバ装置、
３１ …ＣＰＵ、３２…ＲＯＭ、３３…ＲＡＭ、３４…通信部、３５…記憶部、
３１１…予約受付部（管理手段の一例を構成）、
３１２…端末間通信部（管理手段の一例を構成、通信制御手段の一例）、
３１３…ＧＵＩ提供部（提供手段の一例）、
３１４…オーダ受付部（注文受付手段の一例）、
３１５…会計処理部、
３５１…リモートレストラン管理テーブル、
３５２…デリバリー店舗管理テーブル、
３５３…デリバリーメニュー管理テーブル、
３５４…ユーザ管理テーブル、
３５５…予約管理テーブル、
３５６…オーダ管理テーブル、
３５７…配達状況管理テーブル、
４０ …受注端末、
４１ …ＣＰＵ、４２…ＲＯＭ、４３…ＲＡＭ、
４４ …通信部、４５…記憶部、４６…表示部、４７…操作部、
４１１…通信制御部、４１２…出力制御部、４１３…操作受付部、
５０ …外部サービスサーバ、
６０ …ドライバー端末、
７０ …キッチン端末、
９１ …リモートレストラン、９２…ユーザ自宅、
９３ …デリバリー店舗、９４…ドライバー、
１００…開始画面、１０１…スタートボタン、
１１０…メイン画面（主たる表示画面）、１１１…タイトル表示欄、
１１２，１１３，１１４…サブ画面、１１５…参加場所、
１１６…主催者ラベル、１１７…アイコン画像、
１２１…注文ボタン、１２２…注文状況ボタン、１２３…会計ボタン、
１３０…メニュー画面、
１３１…メニュー表示領域、１３２…表示欄、
１３３…商品名欄、１３４…価格欄、１３５…店舗画像欄、
１３６…商品画像欄、１３７…提供時間欄、１３８…ボタン、
１３９…受付終了予告、
１４１…未確定注文表示領域、１４２…商品表示欄、１４３…商品画像欄、
１４４…注文確定ボタン、
１５１…オーダ履歴アイコン、１５２…状況アイコン、
１６１…確認画面、１４５…メッセージ、１４６，１４７…ボタン、
１６２…通知画面、１４８…メッセージ。

特開２０１５－１７６３３５号公報

Claims (6)

1. 複数の端末からアクセスを受け付け、アクセス元の端末と、当該端末を操作するユーザと、ユーザの参加場所と、終了時刻と、を関連付けて管理する管理手段と、
   同一グループに属するユーザの前記端末同士を通信可能に接続する通信制御手段と、
   前記参加場所に配達可能な商品の情報を含むメニュー情報を、前記通信制御手段で通信可能に接続された前記端末同士で閲覧可能に提供する提供手段と、
   前記メニュー情報が提供された前記端末の何れかから商品の注文を受け付け、注文された商品に関する情報を、当該商品を取り扱う店舗に通知する注文受付手段と、
   を備えるサーバ装置。
2. 前記提供手段は、前記終了時刻までに前記参加場所に配達可能な商品の情報を、前記メニュー情報として提供する
   請求項１に記載のサーバ装置。
3. 前記提供手段は、オーダ先として前記参加場所のいずれかを指定する操作を受け付け、指定されたオーダ先に配達可能な商品の情報を、前記メニュー情報として提供する
   請求項１または２に記載のサーバ装置。
4. 前記提供手段は、前記メニュー情報を、主たる表示画面の一部を覆うように重ねて、表示デバイスに表示させる
   請求項１～３のいずれか１つに記載のサーバ装置。
5. 前記提供手段は、前記メニュー情報に、商品を注文可能な残り時間を認識可能な情報を含める
   請求項１～４のいずれか１つに記載のサーバ装置。
6. サーバ装置のコンピュータを、
   複数の端末からアクセスを受け付け、アクセス元の端末と、当該端末を操作するユーザと、ユーザの参加場所と、終了時刻と、を関連付けて管理する管理手段と、
   同一グループに属するユーザの前記端末同士を通信可能に接続する通信制御手段と、
   前記参加場所に配達可能な商品の情報を含むメニュー情報を、前記通信制御手段で通信可能に接続された前記端末同士で閲覧可能に提供する提供手段と、
   前記メニュー情報が提供された前記端末の何れかから商品の注文を受け付け、注文された商品に関する情報を、当該商品を取り扱う店舗に通知する注文受付手段と、
   として機能させるためのプログラム。

Images