JP2022056355A - 情報処理装置、情報処理方法及び情報処理プログラム - Google Patents

Abstract

【課題】ユーザの利便性を向上できる情報処理装置、情報処理方法及び情報処理プログラムを提供すること。【解決手段】本発明に係る情報処理装置は、ユーザが所持するユーザ端末へメニューを提示させるための情報処理装置であって、ユーザの嗜好性に基づいて、メニューを記憶した第１記憶部からメニューを抽出する抽出部と、抽出されたメニューをユーザ端末へ提示させるための提示情報を前記ユーザ端末へ送信する送信部と、を備える。【選択図】図１

Description

本発明は、情報処理装置、情報処理方法及び情報処理プログラムに関する。

コロナ禍等による影響により飲食店の経営が厳しいものとなっている。このような中で、飲食店はテイクアウトを強化するなど努力を継続しているが、テイクアウトは客単価が高くないという問題がある。また衛生管理等など店内飲食とテイクアウトではオペレーションが異なるため対応が難しい面がある。このように、飲食店は、厳しい状況が継続することを前提とした中で存続するために固定費を低減した経営方針に移行する必要が生じている。

上記のような状況の中、例えば、人件費を抑制するために、お客自身がメニューのオーダーや決済を行う所謂セルフオーダー、セルフ決済が注目されている。例えば、特許文献１には、飲食店における注文を管理するセルフオーダーシステムが開示されている。この発明では、各テーブルに設置され、当該テーブルにおける注文の入力を受け付けるオーダー端末と、受け付けた注文の情報をテーブル毎に管理するオーダー管理サーバと、注文内容に応じた自動精算を実行する精算機と、を備え、精算機は、テーブル識別情報の入力を受け付け、オーダー管理サーバから取得した、テーブル識別情報に対応するテーブルの注文情報に基づいて自動精算を実行し、オーダー管理サーバは、精算機から、精算処理の完了通知を受信したら、精算が終了した注文情報を厨房に設置された装置に通知する。

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

しかしながら、セルフオーダー、セルフ決済は、従来からも存在するが十分に浸透しているとは言い難い。これは、単にメニューを提示し、そこからユーザにメニューを選択・注文してもらうだけであり、何ら顧客体験を向上させる工夫がされていないことが一因であると考えられる。

本発明は、上記課題に鑑みてなされたものであり、ユーザの利便性を向上できる情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。

上記課題を解決するため、本発明の情報処理装置は、ユーザが所持するユーザ端末へメニューを提示させるための情報処理装置であって、ユーザの嗜好性に基づいて、メニューを記憶した第１記憶部からメニューを抽出する抽出部と、抽出されたメニューをユーザ端末へ提示させるための提示情報を前記ユーザ端末へ送信する送信部と、を備える。

本発明によれば、ユーザの利便性を向上できる情報処理装置、情報処理方法及び情報処理プログラムを提供することができる。

実施形態に係る情報処理システムの概略構成の一例を示す図である。 実施形態に係るサーバ（情報処理装置）の構成の一例を示す図である。 実施形態に係るサーバの記憶装置に記憶されているデータベースの一例を示す図である。 実施形態に係るデータベースに記憶されているデータの一例を示す図である。 実施形態に係るサーバの機能構成の一例を示す図である。 実施形態に係る第１ユーザ端末の構成の一例を示す図である。 実施形態に係る第２ユーザ端末の構成の一例を示す図である。 実施形態に係る情報処理システムで実行される処理の一例を示すフローチャートである。 実施形態に係る第１ユーザ端末の表示装置に表示される画面の一例を示す図である。 実施形態に係る情報処理システムで実行される処理の一例を示すフローチャートである。 実施形態に係る情報処理システムで実行される処理の一例を示すフローチャートである。 実施形態に係る情報処理システムで実行される処理の一例を示すフローチャートである。 実施形態に係る情報処理システムで実行される処理の一例を示すフローチャートである。 実施形態の変形例１に係る情報処理システムにおけるメニューのカスタマイズ画面の一例を示す図である。 実施形態の変形例１に係る情報処理システムにおけるメニューのカスタマイズ画面の一例を示す図である。 実施形態の変形例１に係る情報処理システムにおけるメニューのカスタマイズ画面の一例を示す図である。 実施形態の変形例１に係る情報処理システムで実行される処理の一例を示すフローチャートである。 実施形態の変形例２に係る情報処理システムで実行される処理の一例を示すフローチャートである。

以下、本発明の実施形態を図面に基づいて説明する。

[実施形態]
（情報処理システム１の構成）
図１に示すように、実施形態の情報処理システム１は、情報処理システム１は、サーバ２、第１ユーザ端末３及び第２ユーザ端末４が通信ネットワーク５を介して接続された構成を有する。なお、情報処理システム１が備えるサーバ２、第１ユーザ端末３及び第２ユーザ端末４の数は任意である。

（サーバ２）
図２に示すように、サーバ２は、通信ＩＦ２００Ａ、記憶装置２００Ｂ、ＣＰＵ２００Ｃなどを備える。

通信ＩＦ２００Ａは、外部端末（例えば、ユーザＵ１、Ｕ２が利用するＳＮＳサーバ、第１ユーザ端末３及び第２ユーザ端末４など）と通信するためのインターフェースである。

記憶装置２００Ｂは、例えば、ＨＤＤや半導体記憶装置である。記憶装置２００Ｂには、サーバ２で利用する情報処理プログラムや各種データベースが記憶されている。なお、本実施形態では、情報処理プログラムや各種データベースは、サーバ２の記憶装置２００Ｂに記憶されているが、ＵＳＢメモリなどの外部記憶装置や通信ネットワーク５を介して接続された外部サーバ（データサーバ）に記憶し、必要に応じて参照やダウンロード可能に構成されていてもよい。

図３は、記憶装置２００Ｂに記憶されているデータベースの一例である。図３に示すように、記憶装置２００Ｂには、ユーザデータベース１（以下、ユーザＤＢ１）、店舗データベース２（以下、店舗ＤＢ２）、空席情報データベース３（以下、空席情報ＤＢ３）、予約データベース（以下、予約ＤＢ４）が記憶されている。

また、図４は、各種データベースに記憶されている情報（データ）の一例を示す図である。なお、本実施形態では、複数のデータベースを備えているが一つのデータベースとして記憶装置２００Ｂに記憶してもよい。また、必ずしもデータベースとして記憶装置２００Ｂに記憶されていなくともよい。また、ユーザＤＢ１から予約ＤＢ４の情報をどのように関連付けて記憶装置２００Ｂに記憶するかは任意である。

（ユーザＤＢ１）
図４（ａ）に示すように、ユーザＤＢ１には、本情報処理システムの利用者であるユーザＵ１の情報、例えば、ユーザＩＤ（以下、ＵＩＤ）、ログイン用パスワード（以下、ＰＷ）、連絡先（例えば、携帯電話番号やメールアドレス、ＳＮＳアカウントなど）、氏名、性別、年齢、生年月日、住所、過去予約した飲食店などの情報がユーザＵ１ごとに記憶されている。住所は、ユーザＵ１の住所である。過去予約した飲食店は、ユーザＵ１が過去に予約した飲食店のＩＤである。また、ユーザＵ１が過去に予約した飲食店のＩＤごとに、訪問回数、キャンセル回数などの情報が関連付けられている。訪問回数は、ユーザＵ１が過去に予約した飲食店を訪問した回数である。

（店舗ＤＢ２）
図４（ｂ）に示すように、店舗ＤＢ２には、本情報処理システムに登録されている飲食店の情報、例えば、店舗ＩＤ（以下、ＲＩＤ）、ログイン用パスワード（以下、ＰＷ）、店舗名、ジャンル、住所、電話番号、営業時間、メニューなどの情報が店舗ごとに記憶されている。ジャンルは、フランス料理、和食、中華、カフェ、創作など、店舗の業態のジャンルの情報である。なお、ジャンルに高級、カジュアル、低価格など、店舗の価格帯の情報を含めてもよい。住所は、店舗の所在地である。電話番号は、各店舗の電話番号である。営業時間は、店舗の営業時間である。なお、この営業時間には、営業曜日及び時間帯の情報が含まれる。メニューは、料理名やドリンク名である。また、メニューごとに、種別、料金、使用している食材名（例えば、トマト、パスタ、豚肉など）、調理法（例えば、煮る、揚げる、焼く、蒸すなど）及び調味料（醤油、ナンプラー、コチュジャンなど）などの情報が関連付けられている。なお、食材名、調理法及び調味料の少なくとも１以上を食材名等ともいう。種別は、料理、ドリンクなどメニューの種別である。料金は、メニューの料金である。なお、各メニューに画像を関連付けて店舗ＤＢ２へ記憶してもよい。また、店舗がＳＮＳのアカウントを有している場合には、ＳＮＳのアカウントも店舗ＩＤに関連付けて店舗ＤＢ２に記憶される。

また、実施形態では、サーバ２の記憶装置２００Ｂには、店舗のフロアマップが店舗ＩＤ（ＲＩＤ）に関連付けて記憶されている。また、フロアマップに表示される各座席には対応する座席ＩＤが関連付けられており、フロアマップに表示される各座席の状態が空席情報データベース３（以下、空席情報ＤＢ３）に記憶されている座席の状態（空席、予約、来店）と連動するように構成されている。なお、ＲＩＤに、テーブル（四角）、円卓など、座席の種類を関連付けるようにしてもよい。このような構成により、例えば、フロアマップに表示される座席が空席であれば予約可、空席でなければ予約不可とすることができる。なお、店舗のフロアマップの登録は情報処理システム１の利用に必須ではないため、必ずしも全てのＲＩＤに関連付けて店舗のフロアマップが記憶されているわけではなく、店舗のフロアマップが関連付けられていない店舗が存在してもよい。

（空席情報ＤＢ３）
図４（ｃ）に示すように、空席情報ＤＢ３には、本情報処理システムに登録されている飲食店の空席情報、例えば、座席ＩＤ、席数、状態、個室か否か、予約ＩＤ（ＹＩＤ）などの情報が店舗ごとに記憶されている。席数は、座席の席数（１人席、２人席、４人席など）である。状態は、座席の状態であり、本実施形態では、予約、来店、空席のいずれかとなる。個室か否かは、座席が個室であるか否かの情報（個室であればＹＥＳ、個室でない場合ＮＯ）である。なお、予約ＩＤについては予約ＤＢ４で説明する。

（予約ＤＢ４）
図４（ｄ）に示すように、予約ＤＢ４には、ユーザＵ１による店舗の予約の情報が記憶される。例えば、予約ＤＢ４には、予約ＩＤ（ＹＩＤ）に関連付けて、座席を予約したユーザＵ１のユーザＩＤ、利用人数、予約時間（何年何月何時何分～何年何月何時何分）などの情報が記憶される。利用人数は、来店予定の人数である。予約時間は、ユーザＵ１が店舗に滞在を予定する時間である。なお、店舗滞在時間が不明の場合、来店予定時間だけを記憶してもよい。また、予め設定した所定時間（例えば、２時間や３時間）が来店予定時間からの滞在時間として自動的に記憶されるようにしてもよい。また、ユーザＵ１が予めメニューを注文している場合、注文したメニュー及び注文数の情報が予約ＩＤに関連付けて記憶されるようにしてもよい。

ＣＰＵ２００Ｃは、サーバ２を制御し、図示しないＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）を備えている。

（サーバ２の機能構成）
図５に示すように、サーバ２は、受信部２０１（第１～第５受信部）、送信部２０２、記憶装置制御部２０３、抽出部２０４、取得部２０５（第１，第２取得部）、学習部２０６、空席管理部２０７、判定部２０８、集計部２０９、付与部２１０などの機能を有する。なお、図５に示す機能は、ＣＰＵ２００Ｃが記憶装置２００Ｂに記憶されている情報処理プログラムを実行することで実現される。

受信部２０１は、第１ユーザ端末３及び第２ユーザ端末４から送信される情報（データ）を受信する。例えば、受信部２０１は、第１ユーザ端末３から送信される店舗の予約を受信する。また、受信部２０１は、第１ユーザ端末３から送信されるユーザＵ１がメニューを検索する際に入力した食材名等を含む検索条件を受信する。また、受信部２０１は、ユーザＵ１が注文したメニューの料金を集計する第１ユーザ端末３の指定、負担割合、注文したメニューのうち１以上のメニューを指定する情報などを受信する。また、受信部２０１は、第１ユーザ端末３から送信される自己の保持するポイント（価値交換媒体）を付与するユーザの指定情報を受信する。また、受信部２０１は、第２ユーザ端末４から送信されるメニューと、メニューの最低提供数と、募集期間（何年何月何時まで）と、提供価格（提供価格（メニューの料金）については、必要に応じて入力される）を含む出品情報を受信する。なお上述した情報は、あくまで受信部２０１が受信する情報の一例である。

送信部２０２は、第１ユーザ端末３及び第２ユーザ端末４へ情報（データ）を送信する。例えば、送信部２０２は、抽出部２０４により抽出されたメニューを第１ユーザ端末３へ提示させるための提示情報を第１ユーザ端末３へ送信する。また、送信部２０２は、上記出品情報を第１ユーザ端末３へ送信する。また、送信部２０２は、判定部２０８での判定結果を、出品情報を登録した店舗の第２ユーザ端末４及び第１ユーザ端末３へ送信する。また、送信部２０２は、店舗の座席の配置情報が店舗ごとに関連付けて記憶された空席情報ＤＢ３（第２記憶部）を参照し、店舗に関連付けられた座席の配置情報を第１ユーザ端末３へ送信する。また、送信部２０２は、予約された座席の情報を第１ユーザ端末３へ送信する。なお上述した情報は、あくまで送信部２０２が送信する情報の一例である。

記憶装置制御部２０３は、記憶装置２００Ｂを制御する。例えば、記憶装置制御部２０３は、記憶装置２００Ｂへの情報の書き込みや読み出しを行う。

抽出部２０４は、学習部２０６により学習されたユーザＵ１の嗜好性に基づいて、メニューを記憶した店舗ＤＢ２（第１記憶部）からメニューを抽出する。この際、抽出部２０４は、取得部２０５により取得されたメニューを注文する店舗の情報に応じてメニューを抽出する。また、抽出部２０４は、受信部２０１が受信した検索条件に含まれる食材名等に基づいて、メニューを抽出する。

取得部２０５は、ユーザＵ１がメニューを注文する店舗の情報を店舗ＤＢ２から取得する。また、取得部２０５は、ＡＰＩ連携等されたユーザＵ１のＳＮＳ（Social Networking Service）アカウントの投稿内容、例えば、食事の好みに関する投稿、店舗やメニューなどの投稿写真、「いいね」等の好みを表す情報が付与された店舗やメニューなどの情報を取得する。

学習部２０６（第１学習部）は、ユーザＵ１のメニューの注文履歴（ユーザＵ１が過去に注文したメニュー）に基づいてユーザＵ１の嗜好性を学習する。また、学習部２０６（第２学習部）は、取得部２０５により取得されるユーザＵ１のＳＮＳ（Social Networking Service）アカウントの投稿内容、例えば、食事の好みに関する投稿、店舗やメニューなどの投稿写真、「いいね」等の好みを表す情報が付与された店舗やメニューなどの情報に基づいてユーザＵ１の嗜好性を学習する。嗜好性には、例えば、メニューそのものの他、料理のジャンル、店舗の雰囲気などが含まれる。なお、嗜好性の学習には、既知の学習アルゴリズムを用いてもよい。既知の学習アルゴリズムとしては、例えば、決定木、ランダムフォレスト、パーセプトロン、ロジスティック回帰、サポートベクターマシン（SVM）、クラスタリング、自己組織化マップ（SOM）、協調フィルタリング、アソシエーション分析などが存在する。

空席管理部２０７は、空席情報ＤＢ３に記憶されている店舗の空席情報に含まれる席の状態を管理する。例えば、空席管理部２０７は、予約を受け付けると、予約を受け付けた店舗の席の状態を利用人数の分だけ予約状態に変更し、予約状態に変更した座席の座席ＩＤに予約ＩＤを関連付けて空席情報ＤＢ３に記憶させる。

判定部２０８は、出品情報に対する注文（例えば、注文予約）の数が最低提供数以上であるか否かを判定する。

集計部２０９は、指定された第１ユーザ端末３で注文されたメニューの料金を集計する（特定の人が料金を支払う場合など）。また、集計部２０９は、指定された第１ユーザ端末３で注文されたメニューの料金を集計し、集計した金額を指定された第１ユーザ端末３で除算して指定された第１ユーザ端末３ごとの料金を算出する（グループで注文したメニューの料金を割り勘する場合など）。また、集計部２０９は、指定された第１ユーザ端末３で注文されたメニューの料金を集計し、指定された負担割合に応じて、指定された第１ユーザ端末３ごとの料金を算出する（上司や部下など、ユーザＵ１に応じて負担割合を変えて料金を支払う場合など）。また、集計部２０９は、指定された１以上のメニューの料金を指定された第１ユーザ端末３で除算して、指定された第１ユーザ端末３ごとの料金を算出する（注文した特定の料理を特定の人で割り勘する場合など）。

なお、負担割合は％で指定してもよいし、金額で指定してもよい。例えば、上司であるユーザＵ１の第１ユーザ端末３では負担率８０％とし、部下であるユーザＵ１の第１ユーザ端末３では負担率２０％と指定すると、集計部２０９は、集計した金額の８０％を上司であるユーザＵ１の第１ユーザ端末３の数で除算し、集計した金額の２０％を部下であるユーザＵ１の第１ユーザ端末３の数で除算して、指定された第１ユーザ端末３ごとの料金を算出する。
また、金額を指定する場合、上司の負担額（例えば、上司１万円）を入力すると、集計部２０９は、上司であるユーザＵ１の第１ユーザ端末３の数に負担額を乗算した額を、集計した料金から減算し、減算した額を部下であるユーザＵ１の第１ユーザ端末３の数で除算して、指定された第１ユーザ端末３ごとの料金を算出する。なお、部下の負担額（例えば、部下２千円）を入力すると、集計部２０９は、部下であるユーザＵ１の第１ユーザ端末３の数に負担額を乗算した額を、集計した料金から減算し、減算した額を上司であるユーザＵ１の第１ユーザ端末３の数で除算して、指定された第１ユーザ端末３ごとの料金を算出する。

付与部２１０は、受信部２０１が、ユーザＵ１が保持するポイント（価値交換媒体）を付与するユーザの指定情報を受信すると、ユーザＵ１が保持するポイントを指定されたユーザのアカウントへ付与する。

なお、サーバ２に入力装置（例えば、キーボード、タッチパネルなど）及び表示装置（例えば、液晶モニタや有機ＥＬモニタなど）を備えるようにしてもよい。

（第１ユーザ端末３）
第１ユーザ端末３は、ＰＣ（Personal Computer）や携帯端末（例えば、タブレット端末）などである。図６（ａ）に示すように、第１ユーザ端末３は、通信ＩＦ３００Ａ、記憶装置３００Ｂ、入力装置３００Ｃ、表示装置３００Ｄ、ＣＰＵ３００Ｅなどを備える。

通信ＩＦ３００Ａは、他の装置（例えば、サーバ２）と通信するためのインターフェースである。

記憶装置３００Ｂは、例えば、ＨＤＤ（Hard Disk Drive）や半導体記憶装置（ＳＳＤ(Solid State Drive)）である。記憶装置３００Ｂには、第１ユーザ端末３の識別子（ＩＤ）及び情報処理プログラムなどが記憶されている。なお、識別子は、サーバ２が第１ユーザ端末３に対して新たに付与してもよいし、ＩＰ（Internet Protocol）アドレス、ＭＡＣ（Media Access Control）アドレスなどを利用してもよい。

入力装置３００Ｃは、例えば、キーボード、タッチパネルなどであり、ユーザＵ１は、入力装置３００Ｃを操作して、情報処理システム１の利用に必要な情報を入力することができる。

表示装置３００Ｄは、例えば、液晶モニタや有機ＥＬモニタなどである。表示装置３００Ｄは、情報処理システム１の利用に必要な画面を表示する。

ＣＰＵ３００Ｅは、第１ユーザ端末３を制御し、図示しないＲＯＭ及びＲＡＭを備えている。

図６（ｂ）に示すように、第１ユーザ端末３は、受信部３０１、送信部３０２、記憶装置制御部３０３、操作受付部３０４、表示装置制御部３０５などの機能を有する。なお、図６（ｂ）に示す機能は、ＣＰＵ３００Ｅが、記憶装置３００Ｂに記憶されている情報処理プログラムを実行することで実現される。

受信部３０１は、サーバ２から送信される情報を受信する。

送信部３０２は、入力装置３００Ｃを利用して入力された情報に識別子を付与してサーバ２へ送信する。第１ユーザ端末３から送信される情報に識別子を付与することでサーバ２は、受信した情報がどの第１ユーザ端末３から送信されたものであるかを認識できる。

記憶装置制御部３０３は、記憶装置３００Ｂを制御する。具体的には、記憶装置制御部３０３は、記憶装置３００Ｂを制御して情報の書き込みや読み出しを行う。

操作受付部３０４は、入力装置３００Ｃでの入力操作を受け付ける。

表示装置制御部３０５は、表示装置３００Ｄを制御する。具体的には、表示装置制御部３０５は、表示装置３００Ｄを制御して実施形態に係る情報処理システム１の利用に必要な画面を表示させる。

なお、第１ユーザ端末３は、例えば、ＷＥＢブラウザを用いて、サーバ２から送信される情報を表示するようにしてもよいし、第１ユーザ端末３にアプリケーションソフトウェアがインストールされており、このアプリケーション上でサーバ２から送信される情報を表示してもよい。

（第２ユーザ端末４）
第２ユーザ端末４は、ＰＣ（Personal Computer）や携帯端末（例えば、タブレット端末）などであり、飲食店の店員などであるユーザＵ２により操作される。なお、第２ユーザ端末４は、専用端末であってもよい。図７（ａ）に示すように、第２ユーザ端末４は、通信ＩＦ４００Ａ、記憶装置４００Ｂ、入力装置４００Ｃ、表示装置４００Ｄ、ＣＰＵ４００Ｅなどを備える。

通信ＩＦ４００Ａは、他の装置（例えば、サーバ２）と通信するためのインターフェースである。

記憶装置４００Ｂは、例えば、ＨＤＤ（Hard Disk Drive）や半導体記憶装置（ＳＳＤ(Solid State Drive)）である。記憶装置４００Ｂには、第２ユーザ端末４の識別子及び情報処理プログラムなどが記憶されている。なお、識別子は、サーバ２が第２ユーザ端末４に対して新たに付与してもよいし、ＩＰ（Internet Protocol）アドレス、ＭＡＣ（Media Access Control）アドレスなどを利用してもよい。

入力装置４００Ｃは、例えば、キーボード、タッチパネルなどであり、ユーザＵ２は、入力装置４００Ｃを操作して、情報処理システム１の利用に必要な情報を入力することができる。

表示装置４００Ｄは、例えば、液晶モニタや有機ＥＬモニタなどである。表示装置４００Ｄは、実施形態に係る情報処理システム１の利用に必要な画面を表示する。

ＣＰＵ４００Ｅは、実施形態に係る第２ユーザ端末４を制御し、図示しないＲＯＭ及びＲＡＭを備えている。

図７（ｂ）に示すように、第２ユーザ端末４は、受信部４０１、送信部４０２、記憶装置制御部４０３、操作受付部４０４、表示装置制御部４０５などの機能を有する。なお、図７（ｂ）に示す機能は、ＣＰＵ４００Ｅが、記憶装置４００Ｂに記憶されている情報処理プログラムを実行することで実現される。

受信部４０１は、サーバ２から送信される情報を受信する。

送信部４０２は、入力装置４００Ｃを利用して入力された情報に識別子を付与してサーバ２へ送信する。

記憶装置制御部４０３は、記憶装置４００Ｂを制御する。具体的には、記憶装置制御部４０３は、記憶装置４００Ｂを制御して情報の書き込みや読み出しを行う。

操作受付部４０４は、入力装置４００Ｃでの入力操作を受け付ける。

表示装置制御部４０５は、表示装置４００Ｄを制御する。具体的には、表示装置制御部４０５は、表示装置４００Ｄを制御して実施形態に係る情報処理システム１の利用に必要な画面を表示させる。

（情報処理システム１で実行される処理）
図８～図１３は、情報処理システム１で実行される処理の一例を示すフローチャート及び第１ユーザ端末３の表示装置３００Ｄに表示される画面を示す図である。以下、図８～図１３を参照して、情報処理システム１で実行される処理について説明するが、図１～図７を参照して説明した構成と同一の構成には同一の符号を付して重複する説明を省略する。

（予約受付処理）
図８は、情報処理システム１で実行される予約受付処理の一例を示すフローチャートである。図９は予約受付処理において、第１ユーザ端末３の表示装置３００Ｄに表示される画面の一例である。以下、図８及び図９を参照して、サーバ２で実行される予約受付処理について説明する。

（ステップＳ１０１）
ユーザＵ１は、第１ユーザ端末３の入力装置３００Ｃを操作して、第１ユーザ端末３の表示装置３００Ｄに表示された図９（ａ）に示す画面で、店舗情報１０４０を左右にスライドさせて予約したい店舗及び時刻（１０４３ａ～１０４３ｃのいずれか）を選択する。ユーザＵ１が店舗を選択すると、該選択が操作受付部３０４で受け付けられる。受け付けられた選択操作の情報は、送信部３０２から通信ネットワーク５を介してサーバ２へ送信される。送信された選択操作の情報は、サーバ２の受信部２０１で受信される。

（ステップＳ１０２）
サーバ２は、受信部２０１で受信した選択操作の情報が、席指定「有」の操作であるか、席指定「無」の操作であるかを判定する。席指定「有」の操作である場合、サーバ２はステップＳ１０３の処理を実行する。席指定「無」の操作である場合、サーバ２はステップＳ１０５の処理を実行する。

（ステップＳ１０３）
サーバ２の送信部２０２は、選択された店舗の店舗ＩＤに関連付けられたフロアマップの情報を送信する。フロアマップの情報は、第１ユーザ端末３の受信部３０１で受信され、表示装置制御部３０５により図９（ｂ）に示すフロアマップ表示画面が表示装置３００Ｄに表示される。なお上述したように、フロアマップに表示される各座席には対応する座席ＩＤが関連付けられており、フロアマップに表示される各座席の状態が空席情報データベース３（以下、空席情報ＤＢ３）に記憶されている座席の状態（空席、予約、来店）と連動するように構成されている。このため、図９（ｂ）に示すように利用人数分（例では４名）が予約可の席１０５４ｂと予約不可の席１０５４ａ（予約済、来店中、利用人数分（例では４名）の席が無いなど）とが判別できる態様で表示される。

（ステップＳ１０４）
ユーザＵ１は、フロアマップ１０５２を拡大表示させるなどして図９（ｃ）に示す座席指定画面において、第１ユーザ端末３の入力装置３００Ｃを操作して、予約を希望する座席を選択操作等により指定する。ユーザＵ１が予約を希望する座席を選択すると、該選択操作が操作受付部３０４で受け付けられ、指定された座席の表示態様が変化する。次いで、ユーザＵ１が第１ユーザ端末３の入力装置３００Ｃを操作して、ボタン１０６４を選択操作すると、該選択操作が操作受付部３０４で受け付けられ、送信部３０２からサーバ２へ送信され、サーバ２の受信部２０１で受信される。なお、表示装置３００Ｄの表示画面が図９（ｄ）の予約確定画面へと遷移する。

（ステップＳ１０５）
ユーザＵ１は、図９（ｄ）に示す予約確定画面において、第１ユーザ端末３の入力装置３００Ｃを操作して、ボタン１０７３を選択操作する。ユーザＵ１がボタン１０７３を選択操作すると、該選択操作が操作受付部３０４で受け付けられ、該選択操作が送信部３０２からサーバ２へ送信され、サーバ２の受信部２０１で受信される。

（ステップＳ１０６）
空席管理部２０７は、受信部２０１が第１ユーザ端末３から送信される選択操作を受信すると、席の状態を予約状態に変更し、予約状態に変更した座席の座席ＩＤに予約ＩＤを関連付けて空席情報ＤＢ３に記憶させる。より具体的には、ステップＳ１０４で座席が指定されている場合（Ｓ１０２のＹＥＳ）には、空席管理部２０７は、指定された座席の状態を予約状態に変更し、予約状態に変更した座席の座席ＩＤに予約ＩＤを関連付けて空席情報ＤＢ３に記憶させる。また、座席が指定されていない場合（Ｓ１０２のＮＯ）には、空席管理部２０７は、利用人数分の空席が存在する座席の状態を予約状態に変更し、予約状態に変更した座席の座席ＩＤに予約ＩＤを関連付けて空席情報ＤＢ３に記憶させる。また、記憶装置制御部２０３は、予約ＩＤに関連付けて、座席を予約したユーザＵ１のユーザＩＤ、利用人数、予約時間（何年何月何時何分～何年何月何時何分）などの情報を予約ＤＢ４に記憶する。

（ステップＳ１０７）
空席管理部２０７により座席の状態が予約状態に変更されると、送信部２０２は、予約ＩＤ及び予約の情報（予約情報の氏名、予約時間、予約人数などの情報）を予約確定情報として第１ユーザ端末３及び第２ユーザ端末４へ送信する。送信部２０２から送信された予約ＩＤ及び予約の情報は、第１ユーザ端末３の受信部３０１及び第２ユーザ端末４の受信部４０１で受信される。第１ユーザ端末３の受信部３０１が予約ＩＤ及び予約の情報を受信すると、表示装置制御部３０５により予約席の位置を示すフロアマップ（予約席が他の席と異なる態様で表示される（例えば、異なる色彩や「予約席はこちら」などが表示される））の画面が表示装置３００Ｄに表示される。このようにユーザＵ１は、店舗に来店した際にどの席に行けばよいかがわかるため、ユーザＵ１への席案内が不要となる（店員との接触も減らすことができる）。なお、店舗の座席に、テーブル番号や座席番号を貼付し、フロアマップに座席に貼付した番号を表示させるようにしてもよい。この場合、ユーザＵ１には、予約したテーブル番号や座席番号が提示される。また、第２ユーザ端末４の受信部４０１が予約ＩＤ及び予約の情報を受信すると、予約が入った旨が表示装置４００Ｄに表示されるなどしてユーザＵ２に報知される。これより、ユーザＵ２は、ユーザＵ１から予約が入ったことを確認することができる。

（メニュー提示処理）
図１０は、情報処理システム１で実行されるメニュー提示処理の一例を示すフローチャートである。以下、図１０を参照して、情報処理システム１で実行されるメニュー提示処理について説明する。

（ステップＳ２０１）
サーバ２の取得部２０５は、ユーザＵ１がメニューを注文する店舗の情報を店舗ＤＢ２から取得する。例えば、店舗の机等に貼付された店舗のＷＥＢサイトへアクセスするためのリンクであるＵＲＬがコード化されたＱＲコード（登録商標）などを読み取ることで、取得部２０５は、ユーザＵ１がメニューを注文する店舗を認識して、該店舗の情報を店舗ＤＢ２から取得してもよい。また、第１ユーザ端末３にＧＰＳセンサを備え、取得部２０５は、該ＧＰＳセンサで検出される位置からユーザＵ１が来店した店舗を認識して、該店舗の情報を店舗ＤＢ２から取得してもよい。さらに、ユーザＵ１が店舗を予約している場合には、取得部２０５は、ユーザＵ１が予約した店舗の情報を店舗ＤＢ２から取得してもよい。

（ステップＳ２０２）
抽出部２０４は、受信部２０１で検索条件（例えば、食材名等）が受信されたか否かを判定する。検索条件（例えば、食材名等）が受信された場合（ＹＥＳ）、抽出部２０４は、ステップＳ２０３の処理を実行する。検索条件（例えば、食材名等）が受信されていない場合（ＮＯ）、抽出部２０４は、ステップＳ２０４の処理を実行する。

（ステップＳ２０３）
抽出部２０４は、受信部２０１が受信した検索条件に含まれる食材名等に基づいて、メニューを抽出する。具体的には、取得部２０５は、店舗ＤＢ２（第１記憶部）を参照し、ステップＳ２０１で取得した店舗に関連付けられたメニューから、検索条件に含まれる食材名等が関連付けられたメニューを抽出する。

（ステップＳ２０４）
抽出部２０４は、店舗ＤＢ２（第１記憶部）を参照し、ステップＳ２０１で取得した店舗に関連付けられたメニューから、学習部２０６により学習されたユーザＵ１の嗜好性に基づいてメニューを抽出する。この際、抽出部２０４は、取得部２０５により取得された店舗の情報に応じてメニューを抽出する。また、抽出部２０４は、受信部２０１が受信した検索条件に含まれる食材名等に基づいて、メニューを抽出する。

（ステップＳ２０５）
送信部２０２は、抽出部２０４により抽出されたメニューを第１ユーザ端末３へ提示させるための提示情報を第１ユーザ端末３へ送信する。具体的には、送信部２０２は、抽出部２０４により抽出されたメニューを店舗のメニュー提示画面において提示される情報として第１ユーザ端末３へ送信する。これにより、ユーザＵ１ごとに嗜好性や検索条件に応じたメニュー表が第１ユーザ端末３へ表示される。このように店舗のメニュー表がユーザＵ１に応じてカスタマイズされた状態でユーザＵ１に提示される。

なお、ステップＳ２０３において、抽出部２０４は、学習部２０６により学習されたユーザＵ１の嗜好性に基づいてメニューを抽出した後、受信部２０１が受信した検索条件に含まれる食材名等に基づいてメニューを抽出するようにしてもよい。また、ステップＳ２０３において、抽出部２０４は、受信部２０１が受信した検索条件に含まれる食材名等に基づいてメニューを抽出した後、学習部２０６により学習されたユーザＵ１の嗜好性に基づいてメニューを抽出するようにしてもよい。

（出品処理）
図１１は、情報処理システム１で実行される出品処理の一例を示すフローチャートである。以下、図１１を参照して、情報処理システム１で実行される出品処理について説明する。

（ステップＳ３０１）
ユーザＵ２は、第２ユーザ端末４の入力装置４００Ｃを操作して、メニューと、メニューの最低提供数と、募集期間（何年何月何時まで）と、提供価格（提供価格（メニューの料金）については、必要に応じて入力される）を含む出品情報（例えば、「明日の１３時までに１０名上のご注文（予約注文）で和牛Ａ５ランクのステーキ２００ｇを２５００円で提供」など）を入力する。ユーザＵ２の入力操作は、操作受付部４０４で受け付けられる。第２ユーザ端末４の送信部４０２は、該操作に対応する情報をサーバ２へ送信し、サーバ２の受信部２０１で受信される。

（ステップＳ３０２）
サーバ２の送信部２０２は、受信部２０１で受信された上記出品情報を第１ユーザ端末３へ送信する。送信部２０２は、例えば、ユーザＤＢ１に記憶されているユーザＵ１の連絡先（例えば、メールアドレスなど）に送信する。なお、サーバ２は、店舗のＳＮＳのアカウントとＡＰＩ連携し、上記出品情報を店舗のＳＮＳのアカウントへ投稿するようにしてもよい。なお、上記出品情報を送信する第１ユーザ端末３をユーザＵ２が指定できるように構成してもよい。例えば、店舗のファンクラブのメンバーであるユーザＵ１を店舗ＩＤに関連付けてユーザＤＢ１又は店舗ＤＢ２に記憶しておき、ユーザＵ２が店舗のファンクラブのメンバーに送信することを指定すると、送信部２０２は、ファンクラブのメンバーに送信するようにしてもよい。

（ステップＳ３０３）
サーバ２の判定部２０８は、メニューと、メニューの最低提供数とを含む出品情報に対する注文の数が最低提供数以上であるか否かを判定する。具体的には、判定部２０８は、出品情報に含まれる募集期間（何年何月何時まで）内にメニューの最低提供数以上の注文があったか否かを判定する。

（ステップＳ３０４）
サーバ２の送信部２０２は、判定部２０８での判定結果を、出品情報を登録した店舗の第２ユーザ端末４及び第１ユーザ端末３へ送信する。

なお、図１１の例では、ユーザＵ２は、注文が最低数に達しない場合、出品したメニューが提供されない形式で出品情報を提示している。しかしながら、どのような形式で出品するかは、ユーザＵ２が適宜選択することができる。例えば、ユーザＵ２は、all-in型、all-or-nothing型、寄付型、株式型などを選択して出品することができる。

（集計処理）
図１２は、情報処理システム１で実行される集計処理の一例を示すフローチャートである。以下、図１２を参照して、情報処理システム１で実行される集計処理について説明する。

（ステップＳ４０１）
サーバ２の受信部２０１は、ユーザＵ１が注文したメニューの料金を集計する第１ユーザ端末３の指定を受信する。

（ステップＳ４０２）
サーバ２の受信部２０１は、注文したメニューのうち１以上のメニューを指定する情報を受信する。

（ステップＳ４０３）
サーバ２の受信部２０１は、各ユーザＵ１の負担割合（０～１００％）を受信する。

（ステップＳ４０４）
集計部２０９は、第１ユーザ端末３で注文されたメニューの料金を集計する（特定の人が料金を支払う場合など）。また、例えば、注文したメニューのうち１以上のメニューの指定及び各ユーザＵ１の負担割合の情報を受信していない場合、集計部２０９は、指定された第１ユーザ端末３で注文されたメニューの料金を集計し、集計した金額を指定された第１ユーザ端末３数で除算して指定された第１ユーザ端末３ごとの料金を算出する（割り勘にする場合など）。また、例えば、各ユーザＵ１の負担割合の情報が受信されている場合、集計部２０９は、指定された第１ユーザ端末３で注文されたメニューの料金を集計し、指定された負担割合に応じて、指定された第１ユーザ端末３ごとの料金を算出する（上司や部下など、ユーザＵ１に応じて負担割合を変えて料金を支払う場合など）。また、例えば、注文したメニューのうち１以上のメニューの指定及び各ユーザＵ１の負担割合の情報を受信している場合、集計部２０９は、指定された１以上のメニューの料金を集計し、指定された負担割合に応じて、指定された第１ユーザ端末３ごとの料金を算出する（注文した特定の料理を特定の人で割り勘する場合など）。

（ステップＳ４０５）
送信部２０２は、集計部２０９での集計結果を第１ユーザ端末３へ送信する。

（ポイント付与処理）
図１３は、サーバ２で実行されるポイント付与処理の一例を示すフローチャートである。以下、図１３を参照して、情報処理システム１で実行されるポイント付与処理について説明する。

（ステップＳ５０１）
サーバ２の受信部２０１は、ポイント（価値交換媒体）を付与する対象者（本実施形態では、スタッフや調理師（シェフ）などの店舗の店員である）のアカウントの情報（口座番号やユーザＩＤ）を受信する。ここで、ポイントを付与する対象者アカウントの情報を指定する方法としては、対象者のアカウント（口座）の情報をＱＲコード（登録商標）で読み取ったり、ＮＦＣタグを利用して取得してもよいし、サーバ２にポイントを付与する対象者のアカウントの情報を店舗ＩＤに関連付けて記憶しておき、第１ユーザ端末３を利用してサーバ２へアクセスし、ポイントを付与する対象者を選択操作することでポイントを付与する対象者アカウントの情報を指定できるようにしてもよい。また、店舗の予約時に予約をしたユーザＵ１の担当者（店員）を決めておき、該担当者を、ポイントを付与する対象者アカウントの情報を指定するようにしてもよい。

（ステップＳ５０２）
ユーザＵ１は、第１ユーザ端末３の入力装置３００Ｃを操作して、対象者へ付与するポイント数を入力すると、該入力操作が操作受付部３０４で受け付けられる。受け付けられた入力操作の情報は送信部３０２からサーバ２へ送信され、サーバ２の受信部２０１で受信される。

（ステップＳ５０３）
サーバ２の付与部２１０は、受信部２０１が、ユーザＵ１が保持するポイントを付与するユーザの指定情報（ステップＳ５０１）及び付与するポイント数（ステップＳ５０２）を受信すると、ユーザＵ１が保持するポイントを指定されたユーザ（店員）へ付与する。

なお、上記説明では、ユーザＵ１がポイント数を指定しているが、ポイント付与の対象者を指定すると予め決まった所定のポイント数が対象者へ付与される構成としてもよい。なお、本情報処理システム１において独自に流通しているポイントを付与できるようにしてもよいし、ＡＰＩ連携等により他のサービスで流通しているポイント（例えば、ＬＩＮＥポイント（登録商標）、ｄポイント（登録商標）、楽天ポイント（登録商標）など）を付与できるようにしてもよい。なお、決済のための価値交換媒体が対象者に付与できればよく、ポイント以外にも、例えば、ビットコインなどの仮想通貨であってもよい。

以上のように、本実施形態のサーバ２は、ユーザＵ１が所持する第１ユーザ端末３へメニューを提示させるための情報処理装置である。サーバ２は、ユーザＵ１の嗜好性に基づいて、メニューを記憶した店舗ＤＢ２（第１記憶部）からメニューを抽出する抽出部２０４と、抽出されたメニューを第１ユーザ端末３へ提示させるための提示情報を第１ユーザ端末３へ送信する送信部２０２と、を備える。このため、ユーザＵ１に応じて異なるメニューを提示することができユーザＵ１の満足度や顧客体験の向上が期待できる。

また、サーバ２は、ユーザＵ１がメニューを注文する店舗の情報を取得する取得部２０５を備え、店舗ＤＢ２（第１記憶部）には、店舗と、店舗のメニューとが関連付けて記憶されている。サーバ２の抽出部２０４は、取得された店舗の情報に応じて、メニューを抽出する。このため来店した店舗に応じてメニューが抽出される。

また、本実施形態では、提示情報は、記店舗のメニュー提示画面において提示される情報として第１ユーザ端末３へ送信される。このため、店舗のメニュー表がユーザＵ１に応じてカスタマイズされた状態でユーザＵ１に提示され、ユーザＵ１の満足度や顧客体験の向上が期待できる。

また、本実施形態では、ユーザＵ１のメニューの注文履歴に基づいてユーザＵ１の嗜好性を学習する学習部２０６（第１学習部）を備える。このように、注文履歴に基づいてユーザＵ１の嗜好性を学習するのでメニューを抽出する精度の向上が期待できる。

また、本実施形態では、ＡＰＩ連携等されたユーザＵ１のＳＮＳ（Social Networking Service）アカウントの投稿内容、例えば、食事の好みに関する投稿、店舗やメニューなどの投稿写真、「いいね」等の好みを表す情報が付与された店舗やメニューなどの情報を取得する取得部２０５と、取得部２０５で取得された情報に基づいてユーザＵ１の嗜好性を学習する学習部２０６（第２学習部）を備える。このように、注文履歴以外の情報に基づいて、ユーザＵ１の嗜好性を学習するので、メニューを抽出する精度の向上が期待できる。

また、本実施形態では、サーバ２は、食材名等を含む検索条件を受信する受信部２０１（第１受信部）を備える。そして、店舗ＤＢ２（第１記憶部）には、メニューと、メニューの材料である食材名等とが関連付けて記憶されており、抽出部２０４は、受信した検索条件に含まれる食材名等に基づいてメニューを抽出する。このように、メニュー名だけでなく食材名等に基づいてもメニューを抽出できるので利便性が向上する。

また、本実施形態では、サーバ２の送信部２０２は、メニューと、メニューの最低提供数とを含む出品情報を第１ユーザ端末３へ送信し、受信部２０１は、第１ユーザ端末３から出品情報に含まれるメニューの注文を受信する。そして、サーバ２は、注文の数が最低提供数以上であるか否かを判定する判定部２０８を備え、送信部２０２は、判定部２０８での判定結果を、出品情報を登録した店舗の第２ユーザ端末４及び第１ユーザ端末３へ送信する。

また、本実施形態では、店舗ＤＢ２（第１記憶部）には、メニューと、メニューの料金とが関連付けて記憶され、第１ユーザ端末３で注文されたメニューの料金を集計する集計部２０９を備える。このため、注文したメニューの会計を素早く行うことができる。

また、本実施形態では、注文したメニューの料金を集計する第１ユーザ端末３の指定情報を受信する受信部２０１（第３受信部）を備え、集計部２０９は、指定された第１ユーザ端末３で注文されたメニューの料金を集計し、集計した金額を指定された第１ユーザ端末３数で除算してユーザＵ１ごとの料金を算出する。このため、決められたユーザＵ１間で注文したメニューの料金を割り勘で支払うといった使い方ができ利便性が向上する。

また、本実施形態では、サーバ２の受信部２０１（第３受信部）は、注文したメニューの料金に関する負担割合（０～１００％まで）の情報を受信し、集計部２０９は、指定された第１ユーザ端末３で注文されたメニューの料金を集計し、負担割合に応じて、ユーザＵ１ごとの料金を算出する。このため、男性と女性、新入社員と役職付社員、じゃんけんでの勝敗、など種々の状況に応じてユーザＵ１の会計の負担割合を決めて各ユーザＵ１の会計費用を算出することができ利便性が向上する。

また、本実施形態では、サーバ２の受信部２０１（第３受信部）は、注文したメニューのうち１以上のメニューを指定する情報と、指定した１以上のメニューの料金を支払う第１ユーザ端末３を指定する情報とを受信し、集計部２０９は、指定された１以上のメニューの料金を集計し、指定された第１ユーザ端末３数で除算して、ユーザごとの料金を算出する。このため、例えば５名のお客さん（お酒飲めない人が２人、飲める人３人）で、飲めない２人は、それぞれソフトドリンクを注文し、飲める３人はボトルワインを入れて、ボトルワインの会計は、この３人で負担する、などといった使いかたをすることができ利便性が向上する。

また、本実施形態では、サーバ２は、自己の保持する価値交換媒体を付与するユーザの指定情報を受信する受信部２０１（第４受信部）と、ポイント（価値交換媒体）を指定されたユーザ（例えば、店員など）へ付与する付与部２１０を備える。日本ではチップを支払う文化がほとんど見られないが、ポイントであれば金銭とは異なり心理的負担が低いため、チップを支払いやすい環境を整えることができる。また、ポイントであってももらう側（店員）にとってはモチベーションのアップにつながる。

また、本実施形態では、サーバ２は、第１ユーザ端末３から送信される店舗の予約を受信する受信部２０１（第５受信）を備え、送信部２０２は、店舗の座席の配置情報が店舗ごとに関連付けて記憶された空席情報ＤＢ３（第２記憶部）を参照し、店舗に関連付けられた座席の配置情報を第１ユーザ端末３へ送信する。このように座席の配置情報を第１ユーザ端末３へ送信するので、ユーザＵ１は店舗の間取りを事前（来店前）に確認することができ利便性が向上する。

また、本実施形態では、サーバ２の送信部２０２は、予約された座席の情報を第１ユーザ端末３へ送信する。このため、ユーザＵ１は、店舗に来店した際にどの席に行けばよいかがわかるため、ユーザＵ１への席案内が不要となる（店員との接触も減らすことができる）。

[実施形態の変形例１]
上記実施形態において、第１ユーザ端末３へメニューを提示させる際に、該メニューで使用する食材、味付け、調理法、トッピング、調味料、個数の少なくとも１以上をカスタマイズ可能に提示させるように構成してもよい。

実施形態の変形例１に係る情報処理システム１では、サーバ２の記憶装置２００Ｂに記憶された店舗ＤＢ２のメニューには、メニューで選択可能な食材（食材には部位も含まれる）、味付け（味付けには、味の濃さや濃度が含まれる）、調理法、トッピング、調味料（ドレッシング、たれを含む）、個数の少なくとも１以上が選択可能な範囲で記憶されている。なお、これら選択可能な食材（食材の部位を含む）、味付け（味の濃さや濃度を含まれる）、調理法、トッピング、調味料（ドレッシング、たれを含む）、個数は、メニューにより異なる。

以下、選択可能な食材、味付け、調理法、トッピング、調味料、個数の選択の一例を示す。
食材の選択としては、例えば、「もも」、「むね」、「砂肝」などである。
味付けの選択としては、例えば、「塩」、「たれ」、「薄め」、「ふつう」、「濃いめ」などである。
調理法の選択としては、例えば、「炒める」、「蒸す」、「煮る」、「揚げる」などである。
トッピングの選択としては、例えば、「トマト」、「ミックスビーンズ」、「ブロッコリー」、「半熟煮卵」、「スムースチキン」、「アボカド」、「小エビ」、「生ハム」、「ペコリーノチーズ」などである。
調味料の選択としては、例えば、「一味」、「からし」、「和風（ドレッシング）」、「ごま（たれ）」などである。
個数の選択としては、例えば、「１本」、「２本」などである。

実施形態の変形例１に係る情報処理システム１のサーバ２の送信部２０２は、メニューと、メニューで選択可能な食材、味付け、調理法、トッピング、調味料、個数の少なくとも１以上とが記憶された店舗ＤＢを参照し、メニューと、メニューで選択可能な食材、味付け、調理法、トッピング、調味料、個数の少なくとも１以上とを第１ユーザ端末３へ送信する。
また、サーバ２の受信部２０１（第６受信部）は、第１ユーザ端末３から送信される食材、味付け、調理法、トッピング、調味料、個数の１以上の選択をユーザＵ１のカスタマイズとして受信する。

図１４～図１６は、第１ユーザ端末３の表示装置３００Ｄに表示されるメニューのカスタマイズ画面の一例を示す図である。
図１４は、焼き鳥のカスタマイズ画面の一例を示す図である。
図１４に示すように、焼き鳥のカスタマイズ画面では、ユーザＵ１は、食材として「もも」、「砂肝」、「ねぎま」のいずれかを選択することができる。また、ユーザＵ１は、味付けとして「塩」「たれ」のいずれかを選択することができる。なお、図１４に示す焼き鳥のカスタマイズ画面は、あくまで一例であり、他の選択肢が提示されていてもよい。

図１５は、サラダのカスタマイズ画面の一例を示す図である。
図１５に示すように、サラダのカスタマイズ画面では、ユーザＵ１は、トッピングとして「トマト」、「ミックスビーンズ」、「ブロッコリー」を選択（複数可）することができる。また、ユーザＵ１は、追加トッピングとして「半熟煮卵」、「スムースチキン」、「アボカド」、「小エビ」、「生ハム」、「ペコリーノチーズ」などを選択（複数可）することができる。
また、ユーザＵ１は、調味料（ドレッシング）として「ごま」、「和風」、「イタリアン」のいずれかを選択することができる。
なお、図１５に示すサラダのカスタマイズ画面は、あくまで一例であり、他の選択肢が提示されていてもよい。

図１６は、お酒（レモンサワー）のカスタマイズ画面の一例を示す図である。
図１６に示すように、お酒のカスタマイズ画面では、ユーザＵ１は、味付けとして「薄め」、「ふつう」、「濃いめ」のいずれかを選択することができる。また、ユーザＵ１は、トッピングとして「はちみつ」、「ジンジャー」、「ソルト（塩）」のいずれかを選択することができる。また、ユーザＵ１は、調理法として、レモンを「フローズンカット」、「フレッシュスライス」、「塩漬け込み」のいずれかから選択することができる。
なお、図１６に示すお酒のカスタマイズ画面は、あくまで一例であり、他の選択肢が提示されていてもよい。

（メニュー提示処理）
図１７は、実施形態の変形例１に係る情報処理システム１で実行されるメニュー提示処理の一例を示すフローチャートである。以下、図１７を参照して、実施形態の変形例１に係る情報処理システム１で実行されるメニュー提示処理について説明する。

（ステップＳ６０１）
サーバ２の取得部２０５は、ユーザＵ１がメニューを注文する店舗の情報を店舗ＤＢ２から取得する。例えば、店舗の机等に貼付された店舗のＷＥＢサイトへアクセスするためのリンクであるＵＲＬがコード化されたＱＲコード（登録商標）などを読み取ることで、取得部２０５は、ユーザＵ１がメニューを注文する店舗を認識して、該店舗の情報を店舗ＤＢ２から取得してもよい。また、第１ユーザ端末３にＧＰＳセンサを備え、取得部２０５は、該ＧＰＳセンサで検出される位置からユーザＵ１が来店した店舗を認識して、該店舗の情報を店舗ＤＢ２から取得してもよい。さらに、ユーザＵ１が店舗を予約している場合には、取得部２０５は、ユーザＵ１が予約した店舗の情報を店舗ＤＢ２から取得してもよい。

（ステップＳ６０２）
サーバ２の送信部２０２は、店舗ＤＢ２を参照し、メニューを注文する店舗のメニューと、該メニューで選択可能な食材、味付け、調理法、トッピング、調味料、個数の少なくとも１以上を第１ユーザ端末３へ送信する。

（ステップＳ６０３）
サーバ２の受信部２０１は、第１ユーザ端末３から送信される食材、味付け、調理法、トッピング、調味料、個数の１以上の選択をユーザＵ１のカスタマイズとして受信する。

（ステップＳ６０４）
サーバ２の送信部２０２は、第１ユーザ端末３から送信される食材、味付け、調理法、トッピング、調味料、個数の１以上の選択をユーザＵ１のカスタマイズとして、ユーザＵ１が予約した店舗の第２ユーザ端末４へ送信する。これにより、ユーザＵ１のカスタマイズされたメニューが店舗に注文される。

なお、ステップＳ６０２において、抽出部２０４が学習部２０６により学習されたユーザＵ１の嗜好性に基づいてメニューを抽出した後、送信部２０２は、抽出部２０４が抽出したメニューと、該メニューで選択可能な食材、味付け、調理法、トッピング、調味料、個数の少なくとも１以上を第１ユーザ端末３へ送信するようにしてもよい。

以上のように、実施形態の変形例１に係る情報処理システム１は、サーバ２の送信部２０２が、店舗ＤＢ２を参照し、メニューと、該メニューで選択可能な食材、味付け、調理法、トッピング、調味料、個数の少なくとも１以上と第１ユーザ端末３へ送信する。
そして、サーバ２の受信部（第６受信部）は、第１ユーザ端末３から送信される食材、味付け、調理法、トッピング、調味料、個数の１以上の選択をユーザＵ１のカスタマイズとして第１ユーザ端末３から受信する。
このように、メニューをカスタマイズすることができるので、グループで入店しても個々人がそれぞれのニーズにあったメニューを注文することができる。また、近年、増えているおひとり様のユーザＵ１にも対応することができる。また、一人一人のユーザＵ１に対するあつらえ感が出るためチェーン店やフランチャイズ店などであっても家庭的な雰囲気を感じてもらうことができる。

[実施形態の変形例２]
また、上記実施形態において、店舗ＤＢ２に記憶されているメニューの料金を更新する料金更新部をサーバ２に備え、店舗の混雑度、食材の在庫量、食材の過去の値段の推移などに応じて更新する構成としてもよい。
実施形態の変形例２に係る情報処理システム１のサーバ２の記憶装置２００Ｂには、在庫ＤＢ５及び過去推移ＤＢ６が記憶される。以下、在庫ＤＢ５及び過去推移ＤＢ６について説明する。

（在庫ＤＢ５）
在庫ＤＢ５には、食材の在庫量が店舗ごとに記憶されている。具体的には、最低在庫量、単位、発注量、消費期限及び日々の在庫量が食材ごとに記憶されている。在庫ＤＢ５に記憶されている食材の在庫量は、サーバ２の料金更新部がメニューの料金を変更する際に利用される。

（過去推移ＤＢ６）
過去推移ＤＢ６は、食材の過去の値段の推移、具体低には、食材の日々の値段が食材ごとに記憶されている。過去推移ＤＢ６に記憶されている食材の過去の値段の推移は、サーバ２の料金更新部がメニューの料金を変更する際に利用される。

次に、料金更新部について説明する。
料金更新部は、受信部２０１が受信した第１ユーザ端末３から送信される店舗の予約の来店日時に応じて、メニューの料金を変化させる。例えば、店舗の空席率又は混雑率（１００－空席率）に応じてメニューの料金を変化させる（空席率が高ければメニューの料金を安く、空席率が低ければメニューの料金を高くする。また、混雑率が高ければメニューの料金を高く、混雑率が低ければメニューの料金を安くする。）。
また、料金更新部は、受信部２０１が受け付けたメニューの注文数に応じて、メニューの料金を変化させてもよい。この場合、同じメニューの注文数が多いほどメニューの料金を安くし、同じメニューの注文数が少ないほどメニューの料金を高くしてもよい。この際、同じユーザが注文する注文数を利用してもよいし、同日に注文される注文数を利用してもよい。
また、料金更新部は、食材の在庫量や消費期限に応じて、メニューの料金を変化させてもよい。例えば、料金更新部は、在庫量が多い（所定の在庫量を超える）食材を使用するメニューの料金を安くしてもよいし、食材の消費期限が近い（所定の日数以下の）食材を使用するメニューの料金を安くしてもよい。
また、料金更新部は、後述の推測部が推測した食材の値段に応じて、メニューの料金を変化させてもよい。例えば、料金更新部は、推測部が推測した食材の値段が高ければ、それに応じて該食材を使用するメニューの料金を高くしてもよい。

推測部は、記憶装置２００Ｂに記憶された過去推移ＤＢ６を参照し、食材の過去の値段に応じて、予約日の食材の値段を推測する。例えば、推測部は、予約日の前年同日の食材の値段を予約日の食材の値段と推測してもよいし、予約日の前年同月の食材の値段の平均値を予約日の食材の値段と推測してもよい。

（料金変更処理）
図１８は、情報処理システム１で実行される料金変更処理の一例を示すフローチャートである。以下、図１８を参照して、情報処理システム１で実行される料金変更処理について説明する。

（ステップＳ７０１）
サーバ２の料金更新部は、在庫ＤＢ５を参照し、食材の在庫量に応じて、メニューの料金を変更する。なお、既に述べたように、料金更新部は、食材の消費期限に応じてメニューの料金を変更してもよい。

（ステップＳ７０２）
サーバ２の料金更新部は、ユーザの予約の来店日時に応じて、メニューの料金を変化させる。また、既に述べたように、料金更新部は、メニューの注文数に応じてメニューの料金を変更してもよい。

（ステップＳ７０３）
サーバ２の料金更新部は、推測部が推測した食材の値段に応じて、メニューの料金を変化させる。

なお、サーバ２の料金更新部は、必ずしも上記ステップＳ７０１～Ｓ７０３の全てのステップを処理する必要は無く、いずれか１以上のステップを処理するようにしてもよい。

以上のように、本実施形態の変形例では、サーバ２は、受信部２０１（受付部）が受信した（受け付けた）ユーザの来店日時に応じて、メニューの料金を変化させる料金更新部を備える。
このため、店舗の混雑状況や早割等をメニューの料金に反映することができ、利便性が向上する。

本実施形態のサーバ２の料金更新部は、受信部２０１（受付部）が受信した（受け付けた）メニューの注文数に応じて、メニューの料金を変化させる。
このように、注文数をメニューの料金に反映することができ、利便性が向上する。

本実施形態のサーバ２の料金更新部は、食材の在庫量に応じて、メニューの料金を変化させる。
このように、食材の在庫量をメニューの料金に反映することができ、利便性が向上する。

本実施形態のサーバ２は、食材の過去の値段に応じて、所定日時の食材の値段を推測する推測部を備える。そして、料金更新部は、推測部が推測した食材の値段に応じて、メニューの料金を変化させる。
このため、季節によって値段が大きく異なる食材の調達費用をメニューの料金に反映することができ、利便性が向上する（例えば、時価などと表示する必要性を低減できる）。またユーザＵ１も事前に料金を知ることができ、安心して注文することができる。

[実施形態の変形例３]
また、上記実施形態において、空席管理部２０７が管理する店舗の空席状況に応じて、受信部２０１（第７受信部）が受信したユーザによる店舗の予約の日時における店舗の混雑度（例えば、予約数、空席率、混雑率（１００－空席率）などの情報）を第１ユーザ端末３へ送信する構成としてもよい。
このように、店舗の混雑度を送信するので、店舗の混雑度に応じて予約をしたり、しなかったり、といった選択肢をユーザに提示することができ、ユーザの利便性が向上する。

その他、上記実施形態及び変形例１～３は、何れも本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその要旨、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。例えば、実施形態の各構成を各々組み合わせて実施してもよい。

１ 情報処理システム
２ サーバ
２００Ａ 通信ＩＦ
２００Ｂ 記憶装置
２００Ｃ ＣＰＵ
２０１ 受信部（第１～第７受信部）
２０２ 送信部
２０３ 記憶装置制御部
２０４ 抽出部
２０５ 取得部（第１，第２取得部）
２０６ 学習部
２０７ 空席管理部
２０８ 判定部
２０９ 集計部
２１０ 付与部
３，４ 第１，第２ユーザ端末
３００Ａ，４００Ａ 通信ＩＦ
３００Ｂ，４００Ｂ 記憶装置
３００Ｃ，４００Ｃ 入力装置
３００Ｄ，４００Ｄ 表示装置
３００Ｅ，４００Ｅ ＣＰＵ
３０１，４０１ 受信部
３０２，４０２ 送信部
３０３，４０３ 記憶装置制御部
３０４，４０４ 操作受付部
３０５，４０５ 表示装置制御部
５ 通信ネットワーク
ＤＢ１ ユーザデータベース
ＤＢ２ 店舗データベース
ＤＢ３ 空席情報データベース
ＤＢ４ 予約データベース
Ｕ１，Ｕ２ ユーザ

Claims (23)

1. ユーザが所持するユーザ端末へメニューを提示させるための情報処理装置であって、
   前記ユーザの嗜好性に基づいて、前記メニューを記憶した第１記憶部からメニューを抽出する抽出部と、
   抽出された前記メニューを前記ユーザ端末へ提示させるための提示情報を前記ユーザ端末へ送信する送信部と、
   を備えることを特徴とする情報処理装置。
2. 前記ユーザがメニューを注文する店舗の情報を取得する第１取得部を備え、
   前記第１記憶部には、
   前記店舗と、前記店舗のメニューとが関連付けて記憶され、
   前記抽出部は、
   取得された店舗の情報に応じて、前記メニューを抽出する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記提示情報は、
   前記店舗のメニュー提示画面において提示される情報として前記ユーザ端末へ送信されることを特徴とする請求項２に記載の情報処理装置。
4. 前記ユーザのメニューの注文履歴に基づいて前記ユーザの嗜好性を学習する第１学習部を備えることを特徴とする請求項１乃至請求項３のいずれかに記載の情報処理装置。
5. 前記ユーザの投稿内容を取得する第２取得部と、
   前記ユーザの投稿内容に基づいて前記ユーザの嗜好性を学習する第２学習部と、
   を備えることを特徴とする請求項１乃至請求項４のいずれかに記載の情報処理装置。
6. 食材名、調理法及び調味料の少なくとも１以上を含む検索条件を受信する第１受信部を備え、
   前記第１記憶部には、
   前記メニューと、前記メニューに使用される食材名、調理法及び調味料の少なくとも１以上とが関連付けて記憶され、
   前記抽出部は、
   受信した前記検索条件に含まれる食材名、調理法及び調味料の少なくとも１以上に基づいて、前記メニューを抽出する
   ことを特徴とする請求項１乃至請求項５のいずれかに記載の情報処理装置。
7. 前記送信部は、
   メニューと、前記メニューの最低提供数とを含む出品情報を前記ユーザ端末へ送信し、
   前記情報処理装置は、
   前記ユーザ端末から前記出品情報に含まれるメニューの注文を受信する第２受信部と、
   前記注文の数が前記最低提供数以上であるか否かを判定する判定部と、を備え、
   前記送信部は、
   前記判定結果を、前記出品情報を登録した店舗へ送信する、
   ことを特徴とする請求項１乃至請求項６のいずれかに記載の情報処理装置。
8. 前記第１記憶部には、
   前記メニューと、前記メニューの料金とが関連付けて記憶され、
   前記ユーザ端末で注文された前記メニューの料金を集計する集計部を備えることを特徴とする請求項１乃至請求項７のいずれかに記載の情報処理装置。
9. 注文したメニューの料金を集計するユーザ端末の指定情報を受信する第３受信部を備え、
   前記集計部は、
   指定された前記ユーザ端末で注文された前記メニューの料金を集計し、集計した金額を前記指定されたユーザ端末で除算して、前記ユーザ端末ごとの料金を算出することを特徴とする請求項８に記載の情報処理装置。
10. 前記第３受信部は、
    前記注文したメニューの料金に関する負担割合の情報を受信し、
    前記集計部は、
    前記負担割合に応じて、前記ユーザ端末ごとの料金を算出することを特徴とする請求項９に記載の情報処理装置。
11. 前記第３受信部は、
    前記注文したメニューのうち１以上のメニューを指定する情報と、前記指定した１以上のメニューの料金を支払うユーザ端末を指定する情報とを受信し、
    前記集計部は、
    指定された１以上のメニューの料金を集計し、前記指定されたユーザ端末ごとの料金を算出することを特徴とする請求項９又は請求項１０に記載の情報処理装置。
12. 自己の保持する価値交換媒体を付与するユーザの指定情報を受信する第４受信部と、
    前記価値交換媒体を指定されたユーザへ付与する付与部と、
    を備えることを特徴とする請求項１乃至請求項１１のいずれかに記載の情報処理装置。
13. 前記ユーザ端末から送信される前記店舗の予約を受信する第５受信部を備え、
    前記送信部は、
    店舗の座席の配置情報が前記店舗ごとに関連付けて記憶された第２記憶部を参照し、前記店舗に関連付けられた座席の配置情報を前記ユーザ端末へ送信することを特徴とする請求項１乃至請求項１２のいずれかに記載の情報処理装置。
14. 前記送信部は、
    前記予約された座席の情報を前記ユーザ端末へ送信することを特徴とする請求項１３に記載の情報処理装置。
15. ユーザ端末へメニューを提示させるための情報処理装置であって、
    前記ユーザ端末から前記メニューのカスタマイズを受信する第６受信部、を備える、
    ことを特徴とする情報処理装置。
16. 前記メニューと、前記メニューで選択可能な食材、味付け、調理法、トッピング、調味料、個数の少なくとも１以上とが記憶された第２記憶部を参照し、前記メニューと、前記メニューで選択可能な食材、味付け、調理法、トッピング、調味料、個数の少なくとも１以上とを前記ユーザ端末へ送信する送信部、を備え、
    前記第６受信部は、
    前記食材、前記味付け、前記調理法、前記トッピング、前記調味料、前記個数の１以上の選択を前記カスタマイズとして前記ユーザ端末から受信する、
    ことを特徴とする請求項１５に記載の情報処理装置。
17. 前記ユーザ端末から来店日時を含む予約を受信する第７受信部と、
    前記第７受信部が受信した前記来店日時に応じて、前記メニューの料金を変化させる料金更新部と、を備える、
    ことを特徴とする請求項１乃至請求項１６のいずれかに記載の情報処理装置。
18. 前記第７受信部は、
    ユーザ端末から前記メニューの注文を受信し、
    前記料金更新部は、
    前記第７受信部が受信した前記メニューの注文数に応じて、前記メニューの料金を変化させる、
    ことを特徴とする請求項１７に記載の情報処理装置。
19. 前記料金更新部は、
    食材の在庫量に応じて、前記メニューの料金を変化させる、
    ことを特徴とする請求項１７又は請求項１８に記載の情報処理装置。
20. 食材の過去の値段に応じて、所定日時の前記食材の値段を推測する推測部、を備え、
    前記料金更新部は、
    前記推測部が推測した前記食材の値段に応じて、前記メニューの料金を変化させる、
    ことを特徴とする請求項１７乃至請求項１９のいずれかに記載の情報処理装置。
21. 前記第７受信部が受信した前記予約に応じて、前記店舗の空席を管理する空席管理部を備え、
    前記送信部は、
    前記空席管理部が管理する前記店舗の空席状況に応じて、前記第７受信部が受信した前記ユーザによる店舗の予約の日時における前記店舗の混雑度を前記ユーザ端末へ送信する、
    ことを特徴とする請求項１７乃至請求項２０のいずれかに記載の情報処理装置。
22. ユーザが所持するユーザ端末へメニューを提示させるための情報処理方法であって、
    抽出部が、前記ユーザの嗜好性に基づいて、前記メニューを記憶した記憶部からメニューを抽出する工程と、
    送信部が、抽出された前記メニューを前記ユーザ端末へ提示させるための提示情報を前記ユーザ端末へ送信する工程と、
    を有することを特徴とする情報処理方法。
23. ユーザが所持するユーザ端末へメニューを提示させるための情報処理プログラムであって、
    コンピュータを、
    前記ユーザの嗜好性に基づいて、前記メニューを記憶した記憶部からメニューを抽出する抽出部、
    抽出された前記メニューを前記ユーザ端末へ提示させるための提示情報を前記ユーザ端末へ送信する送信部、
    として機能させることを特徴とする情報処理プログラム。
    
    

Images