JP7445137B2 - 情報処理システム、情報処理方法、及び情報処理プログラム - Google Patents

Description

本発明は、施設の情報を提供可能な情報処理システム、情報処理方法、及び情報処理プログラムに関する。

飲食店などの施設では、売上を拡大させるために、施設を予約する利用者の数を増加させる様々な施策が実施される。従来、利用者数を増加させることが可能なシステムが提案されている。例えば、複数の飲食店の情報と各飲食店のメニューの概要の情報とを利用者端末に表示させ、利用者が特定の飲食店を指定すると、利用者の現在位置に応じて当該飲食店までの交通情報、当該飲食店の宣伝情報及び割引情報などの詳細情報を利用者端末に提供するシステムが提案されている（例えば特許文献１参照）。

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

しかし、従来の技術は、利用者数を増加させて売上を拡大することを目的としたものであり、施設の利益については考慮されていない。このため、例えば、利用者数が増加しても施設のスタッフの人数が多い場合には、人件費が高くなり施設の利益が増加しない又は低下する可能性がある。このように、従来の技術では、施設の利用者数を増加させつつ利益を拡大させることは困難である。

本発明の目的は、施設の利用者数を増加させつつ利益を拡大させることが可能な情報処理システム、情報処理方法、及び情報処理プログラムを提供することにある。

本発明に係る情報処理システムは、施設の利用対象日又は利用対象時間帯の利用者数を取得する第１取得処理部と、前記利用対象日又は前記利用対象時間帯の前記施設のスタッフ数を取得する第２取得処理部と、前記第２取得処理部により取得される前記スタッフ数に基づいて、前記利用対象日又は前記利用対象時間帯に前記施設が受け入れ可能な利用者の受入可能人数を算出する算出処理部と、前記第１取得処理部により取得される前記利用者数と、前記算出処理部により算出される前記受入可能人数とに基づいて、前記利用対象日又は前記利用対象時間帯の前記施設の利用に関する特典情報を出力する出力処理部と、を備える。

本発明に係る情報処理方法は、施設の利用対象日又は利用対象時間帯の利用者数を取得する第１取得ステップと、前記利用対象日又は前記利用対象時間帯の前記施設のスタッフ数を取得する第２取得ステップと、記第２取得ステップにより取得される前記スタッフ数に基づいて、前記利用対象日又は前記利用対象時間帯に前記施設が受け入れ可能な利用者の受入可能人数を算出する算出ステップと、前記第１取得ステップにより取得される前記利用者数と、前記算出ステップにより算出される前記受入可能人数とに基づいて、前記利用対象日又は前記利用対象時間帯の予約に関する特典情報を出力する出力ステップと、を一又は複数のプロセッサーにより実行する方法である。

本発明に係る情報処理プログラムは、施設の利用対象日又は利用対象時間帯の利用者数を取得する第１取得ステップと、前記利用対象日又は前記利用対象時間帯の前記施設のスタッフ数を取得する第２取得ステップと、記第２取得ステップにより取得される前記スタッフ数に基づいて、前記利用対象日又は前記利用対象時間帯に前記施設が受け入れ可能な利用者の受入可能人数を算出する算出ステップと、前記第１取得ステップにより取得される前記利用者数と、前記算出ステップにより算出される前記受入可能人数とに基づいて、前記利用対象日又は前記利用対象時間帯の予約に関する特典情報を出力する出力ステップと、を一又は複数のプロセッサーに実行させるためのプログラムである。

本発明によれば、施設の利用者数を増加させつつ利益を拡大させることが可能な情報処理システム、情報処理方法、及び情報処理プログラムが提供される。

図１は、本発明の実施形態に係る情報処理システムの構成を示すブロック図である。 図２は、本発明の実施形態に係る情報処理システムで使用される施設情報の一例を示す図である。 図３は、本発明の実施形態に係る情報処理システムで使用される予約情報の一例を示す図である。 図４は、本発明の実施形態に係る情報処理システムで使用される勤務情報の一例を示す図である。 図５は、本発明の実施形態に係る利用者端末に表示される検索条件設定ページの一例を示す図である。 図６は、本発明の実施形態に係る利用者端末に表示される検索結果ページの一例を示す図である。 図７は、本発明の実施形態に係る利用者端末に表示される検索結果ページの一例を示す図である。 図８は、本発明の実施形態に係る情報処理システムで実行される情報処理の手順の一例を示すフローチャートである。 図９は、本発明の他の実施形態に係る情報処理システムで使用される予約情報の一例を示す図である。 図１０は、本発明の他の実施形態に係る情報処理システムで使用される予約人数情報の一例を示す図である。 図１１は、本発明の実施形態に係る情報処理システムで使用される勤務情報の他の例を示す図である。 図１２は、本発明の実施形態に係る情報処理システムで使用される勤務情報の他の例を示す図である。 図１３は、本発明の実施形態に係る情報処理システムで使用される勤務情報の他の例を示す図である。 図１４は、本発明の実施形態に係る情報処理システムで使用される勤務情報の他の例を示す図である。

以下添付図面を参照しながら、本発明の実施形態について説明し、本発明の理解に供する。なお、以下の実施形態は、本発明を具体化した一例であって、本発明の技術的範囲を限定するものではない。

［情報処理システム１］
図１に示すように、本発明の実施形態に係る情報処理システム１は、情報処理装置２と利用者端末３と施設端末４とを含む。情報処理装置２、利用者端末３、及び施設端末４は、インターネット、ＬＡＮ、ＷＡＮ、又は公衆電話回線などの通信網Ｎ１を介して通信可能である。

情報処理装置２は、施設を検索するための検索条件を利用者端末３から受付可能であり、検索条件に基づく検索処理を実行して検索結果を利用者端末３に提示する。また、情報処理装置２は、検索結果に含まれる施設のうち利用者に選択された施設の予約処理を実行する。以下、本実施形態では、情報処理システム１において、検索対象の施設が、飲食物を提供する飲食店である場合を例に挙げて説明する。なお、前記施設は、例えば宿泊施設、カラオケ店、ボーリング場、卓球場、ゴルフ場、温泉施設、サービス提供施設などの各種の施設であってもよい。

利用者端末３は、施設の検索及び予約を要求する利用者によって操作される情報処理装置である。施設端末４は、施設に配置され、施設の予約を管理する情報処理装置である。情報処理システム１には、１又は複数の利用者端末３と、施設ごとに配置される複数の施設端末４とが含まれる。

本実施形態では、情報処理装置２単体が本発明に係る情報処理システムに相当するが、本発明に係る情報処理システムは、情報処理装置２、利用者端末３、及び施設端末４のうち一又は複数の構成要素を含むものであってもよい。例えば、情報処理装置２、利用者端末３、及び施設端末４の構成要素が協働して後述する情報処理（図８参照）を分担して実行する場合には、その処理を実行する複数の構成要素を含むシステムを本発明に係る情報処理システムとして捉えることが可能である。例えば、情報処理装置２及び施設端末４が本発明に係る情報処理システムを構成してもよい。

［情報処理装置２］
図１に示されるように、情報処理装置２は、制御部２１、記憶部２２、操作表示部２３、及び通信Ｉ／Ｆ２４などを備えるサーバーである。なお、情報処理装置２は、１台のコンピュータに限らず、複数台のコンピュータが協働して動作するコンピュータシステムであってもよい。また、情報処理装置２で実行される各種の処理は、一又は複数のプロセッサーによって分散して実行されてもよい。

通信Ｉ／Ｆ２４は、情報処理装置２を有線又は無線で通信網Ｎ１に接続し、通信網Ｎ１を介して利用者端末３、施設端末４などの外部機器との間で所定の通信プロトコルに従ったデータ通信を実行するための通信インターフェースである。

操作表示部２３は、各種の情報を表示する液晶ディスプレイ又は有機ＥＬディスプレイのような表示部と、操作を受け付けるマウス、キーボード、又はタッチパネルのような操作部とを備えるユーザーインターフェースである。

記憶部２２は、各種の情報を記憶するＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）又はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などの不揮発性の記憶部である。具体的に、記憶部２２には、施設情報Ｄ１、予約情報Ｄ２、勤務情報Ｄ３などのデータが記憶される。施設情報Ｄ１には、検索対象及び予約対象の飲食店に関する情報が含まれる。予約情報Ｄ２には、飲食店の予約情報が含まれる。勤務情報Ｄ３には、飲食店のスタッフの勤務スケジュールに関する情報（シフト情報）が含まれる。図２は施設情報Ｄ１の一例を示す図であり、図３は予約情報Ｄ２の一例を示す図であり、図４は勤務情報Ｄ３の一例を示す図である。また、記憶部２２には、飲食店の店内、外観などを示す画像データ、飲食店の場所を示す地図データなども記憶されている。

図２に示されるように、施設情報Ｄ１には、飲食店ごとに、対応する「施設ＩＤ」、「施設名」、「エリア」、「ジャンル」、「住所」、「ＵＲＬ」などの情報が含まれる。前記施設ＩＤは、飲食店の識別情報であり、前記施設名は、飲食店の名称である。前記エリアは、飲食店の所在地の地域名称などである。前記ジャンルは、飲食店で提供される商品（飲食物）の内容を識別可能な情報であって、例えば料理ジャンルを示す。前記住所は、飲食店の詳細な住所であり、当該飲食店の位置を示す情報として用いられる。前記ＵＲＬは、飲食店のホームページ、予約ページなどのウェブページにアクセスするためのアクセス情報である。また、施設情報Ｄ１には、飲食店の利用について必要な平均的な金額として予め設定された金額（予算）の情報、飲食店の画像の識別情報などが含まれてもよい。

予約情報Ｄ２は、施設情報Ｄ１に登録されている飲食店ごとに対応付けて記憶部２２に記憶される。図３には、飲食店Ｓ１の予約情報Ｄ２を示している。図３に示されるように、予約情報Ｄ２には、「来店日」、「予約者名」、「予約人数」、「テーブル」、「利用者数」などの情報が含まれる。前記来店日は、利用者が来店する予定日（利用日）である。前記予約者名は、予約を行った利用者の氏名である。前記予約人数は、来店する予定の利用者の人数である。前記テーブルは、利用者が利用するテーブル、部屋などの利用対象物を識別する情報である。前記テーブルは、利用者が予約要求の際に選択してもよいし、飲食店が割り当ててもよい。前記利用者数は、前記来店日の利用者（予約した利用者）の合計人数を示す情報である。例えば、情報処理装置２の制御部２１は、前記来店日ごとに、予約人数の合計数を算出して前記利用者数として予約情報Ｄ２に登録する。予約情報Ｄ２は、制御部２１によって、施設端末４又は利用者端末３からの新規予約又は予約変更が受け付けられるごとに登録又は変更される。なお、予約情報Ｄ２には、利用者に提供されるサービスの内容を示す情報であって、例えば飲食内容のコース（料理コース）の情報が含まれてもよい。また、予約情報Ｄ２には、利用開始時刻及び利用終了時刻を含む予約時間の情報（図９参照）が含まれてもよい。

勤務情報Ｄ３は、施設情報Ｄ１に登録されている飲食店ごとに対応付けて記憶部２２に記憶される。図４には、飲食店Ｓ１の勤務情報Ｄ３を示している。図４に示されるように、勤務情報Ｄ３には、飲食店Ｓ１で勤務する各スタッフの勤務スケジュールの情報が含まれる。図４に示す例では、飲食店Ｓ１で勤務する５人のスタッフＸ１～Ｘ５の勤務スケジュールが登録されている。また、図４に示す例では、調理担当の厨房スタッフＸ１，Ｘ２及びホール担当の接客スタッフＸ３，Ｘ４，Ｘ５の勤務スケジュールが登録されている。

また、勤務情報Ｄ３には、「スタッフ数」及び「受入可能人数」の情報が含まれる。前記スタッフ数は、日ごとのスタッフの合計人数を示す情報である。例えば飲食店Ｓ１において、「２０２０年９月１日」はスタッフＸ１，Ｘ３，Ｘ４が勤務するため、「２０２０年９月１日」の前記スタッフ数には「３」が登録される。また例えば、「２０２０年９月４日」はスタッフＸ１～Ｘ５が勤務するため、「２０２０年９月４日」の前記スタッフ数には「５」が登録される。制御部２１は、日ごとに、出勤予定のスタッフの合計人数を算出して勤務情報Ｄ３に登録する。

前記受入可能人数は、飲食店Ｓ１が受け入れ可能な利用者の合計人数を示す情報である。前記受入可能人数は、前記スタッフ数に応じて算出される。一般的に、飲食店では、勤務するスタッフの人数が多い程、多くの利用者にサービスを提供することが可能になる。このため、前記受入可能人数は、例えば１人のスタッフがサービス対応可能な利用者数（以下、基準利用者数ともいう。）に基づいて算出されてもよい。例えば１人のスタッフがサービス対応可能な利用者数が８人に設定される場合、「２０２０年９月１日」の前記受入可能人数には「２４」（＝３×８）が登録され、「２０２０年９月４日」の前記受入可能人数には「４０」（＝５×８）が登録される。なお、前記基準利用者数は、飲食店Ｓ１の席数に応じて設定されてもよいし、接客担当のスタッフ数に応じて設定されてもよい。例えば飲食店Ｓ１に４人用のテーブルが１０個（４０席）配置されており、最大４０人の利用者を５人のスタッフで対応する場合、スタッフ一人当たりの利用者数（基準利用者数）は８人となる。制御部２１は、前記基準利用者数に基づいて各日の前記受入可能人数を算出して勤務情報Ｄ３に登録する。なお、前記基準利用者数は、飲食店Ｓ１の管理者により設定される。前記管理者は、例えばスタッフの能力、スタッフの人件費、飲食店Ｓ１の売上、予約状況などに基づいて、各日のスタッフ数、前記基準利用者数を決定する。

なお、他の実施形態として、施設情報Ｄ１、予約情報Ｄ２、及び勤務情報Ｄ３の一部又は全部が、情報処理装置２から通信網Ｎ１を介してアクセス可能な他のサーバーに記憶されてもよい。この場合、情報処理装置２の制御部２１は、前記他のサーバーから前記情報を取得して、後述の情報処理（図８参照）などの各処理を実行してもよい。

また、記憶部２２には、利用者端末３に表示される予約サイト（例えば飲食店予約サイト）に含まれる、検索条件設定ページＰ１（図５参照）、検索結果ページＰ２（図６、図７参照）などの各種のウェブページを生成するためのレイアウトデータ及び画像データなども記憶される。なお、本実施形態において、情報処理装置２の制御部２１は、前記各種のウェブページを生成してそのウェブページの情報を利用者端末３に送信することにより、利用者端末３に前記各種のウェブページを表示させることが可能である。また、他の実施形態として、情報処理装置２の制御部２１は、利用者端末３に前記各種のウェブページを表示するために必要なデータを送信することにより、利用者端末３の制御部３１に前記各種のウェブページの表示を実行させてもよい。

なお、前記予約サイトは、予め設定された一つのドメインに属するウェブページの集合体であってもよいが、例えば同一の情報処理装置２の記憶部２２に記憶された複数のドメインに属するウェブページの集合体を前記予約サイトとして捉えてもよい。また、前記予約サイトに含まれる各種のページは、複数のサーバーに分散して記憶されたものであってもよい。

さらに、記憶部２２には、制御部２１に後述の情報処理（図８参照）を実行させるための情報処理プログラムなどの制御プログラムが記憶されている。例えば、前記情報処理プログラムは、ＣＤ又はＤＶＤなどのコンピュータ読取可能な記録媒体に非一時的に記録されており、情報処理装置２が備えるＣＤドライブ又はＤＶＤドライブなどの読取装置（不図示）で読み取られて記憶部２２に記憶される。

制御部２１は、ＣＰＵ、ＲＯＭ、及びＲＡＭなどの制御機器を有する。前記ＣＰＵは、各種の演算処理を実行するプロセッサーである。前記ＲＯＭは、前記ＣＰＵに各種の演算処理を実行させるためのＢＩＯＳ及びＯＳなどの制御プログラムが予め記憶される不揮発性の記憶部である。前記ＲＡＭは、各種の情報を記憶する揮発性又は不揮発性の記憶部であり、前記ＣＰＵが実行する各種の処理の一時記憶メモリー（作業領域）として使用される。そして、制御部２１は、前記ＲＯＭ又は記憶部２２に予め記憶された各種の制御プログラムを前記ＣＰＵで実行することにより情報処理装置２を制御する。

ところで、従来、飲食店では、売上を拡大させるために、飲食店を予約する利用者数を増加させる様々な施策が実施されている。しかし、従来は、利用者数を増加させて売上を拡大することを目的としており、飲食店の利益については考慮されていない。このため、例えば、利用者数が増加しても飲食店のスタッフの人数が多い場合には、人件費が高くなり飲食店の利益が増加しない又は低下する可能性がある。このように、従来の技術では、飲食店の利用者数を増加させつつ利益を拡大させることは困難である。これに対して、本実施形態に係る情報処理装置２では、飲食店の利用者数を増加させつつ利益を拡大させることが可能である。

具体的に、制御部２１は、図１に示されるように、受付処理部２１１、検索処理部２１２、予約処理部２１３、第１取得処理部２１４、第２取得処理部２１５、算出処理部２１６、出力処理部２１７などの各種の処理部を含む。なお、制御部２１は、前記ＣＰＵで前記情報処理プログラムに従った各種の処理を実行することによって前記各種の処理部として機能する。また、一部又は全部の前記処理部が電子回路で構成されていてもよい。なお、前記情報処理プログラムは、複数のプロセッサーを前記処理部として機能させるためのプログラムであってもよい。

受付処理部２１１は、利用者端末３からエリア、利用日（来店日）、及び利用人数などの検索条件を含む検索要求を受け付ける。受付処理部２１１により受け付けられるエリア、利用日、及び利用人数の各情報は、予約可能な飲食店を検索するために検索処理部２１２によって実行される検索処理で用いられる。

例えば、受付処理部２１１は、利用者端末３に検索条件設定ページＰ１（図５参照）を表示させる。検索条件設定ページＰ１には、希望のエリアを入力するエリア入力欄Ｋ１１、希望の利用日（来店日）を入力する来店日入力欄Ｋ１２、利用人数を入力する利用人数入力欄Ｋ１３などが含まれる。検索条件設定ページＰ１は、来店時刻（予約時間）、料理ジャンルなどの情報を入力可能であってもよい。

利用者が検索条件設定ページＰ１において前記各情報を入力して「決定」の決定ボタンＫ１５を押下すると、受付処理部２１１は、利用者端末３から検索要求を受け付ける。

検索処理部２１２は、受付処理部２１１により前記検索要求が受け付けられた場合に飲食店を検索するための検索処理を実行する。具体的に、検索処理部２１２は、前記検索処理において、前記検索条件を満たす飲食店を検索する。例えば、検索処理部２１２は、施設情報Ｄ１（図２参照）に登録された複数の飲食店の中から、前記エリアに存在し、前記来店日及び前記利用人数で予約可能な飲食店を抽出する。

また、検索処理部２１２は、検索処理の検索結果を出力する。具体的に、検索処理部２１２は、前記検索結果を利用者端末３に送信することにより、検索結果ページＰ２（図６、図７参照）を利用者端末３に表示させる。これにより、利用者端末３において、利用者は前記検索結果として表示される飲食店から、予約を希望する飲食店を選択することが可能となる。

検索結果ページＰ２（図６、図７参照）には、前記検索条件を満たす各飲食店の情報（飲食店情報Ｒ２）が一覧表示される。各飲食店情報Ｒ２には、飲食店の概要、画像、飲食店の詳細ページを表示させるための詳細ボタンＫ２２、予約要求を行うための予約ボタンＫ２３などが表示される。利用者は、検索結果ページＰ２に予約希望の飲食店がある場合に、対応する飲食店情報Ｒ２の予約ボタンＫ２３を押下して予約要求を行う。一方、利用者は、検索結果ページＰ２に予約希望の飲食店がない場合には、条件変更ボタンＫ２１を押下する。条件変更ボタンＫ２１が押下されると、受付処理部２１１は、検索条件設定ページＰ１（図５参照）を再表示させて、利用者から検索条件の変更操作を受け付ける。

予約処理部２１３は、利用者から予約対象の飲食店の予約要求を受け付け、当該飲食店の予約が可能な場合に予約処理を実行する。予約処理部２１３は、前記予約処理において、予約対象の飲食店（ここでは飲食店Ｓ１）に対応する予約情報Ｄ２（図３参照）に予約内容を登録する。また、予約処理部２１３は、来店日ごとに予約人数の合計数を算出して、予約情報Ｄ２の前記利用者数に登録する。予約処理部２１３は、予約を受け付けるごと又は予約を取り消すごとに、予約情報Ｄ２の前記利用者数を更新する。

なお、予約処理部２１３は、予約情報Ｄ２に登録されている予約を利用者端末３の操作に応じて取り消すこと又は自動的に取り消すことも可能である。予約処理部２１３は、予約処理が完了すると、例えば予約完了メールを利用者端末３及び施設端末４に送信する。

第１取得処理部２１４は、飲食店の予約対象日の利用者数を取得する。具体的には、第１取得処理部２１４は、予約情報Ｄ２（図３参照）を参照して、受付処理部２１１が受け付けた検索要求に対応する検索条件に含まれる来店日（予約対象日）の前記利用者数を取得する。例えば、利用者が検索条件設定ページＰ１（図５参照）において来店日に「２０２０年９月２日」を入力して、検索処理部２１２が検索条件を満たす飲食店Ｓ１を検索した場合に、第１取得処理部２１４は、飲食店Ｓ１に対応する予約情報Ｄ２（図３参照）を参照して、「２０２０年９月２日」（予約対象日）の飲食店Ｓ１の利用者数として、「１４人」を取得する。第１取得処理部２１４は、検索処理部２１２により検索される飲食店ごとに、前記予約対象日の利用者数を取得する。第１取得処理部２１４は、本発明の第１取得処理部の一例である。

第２取得処理部２１５は、予約対象日の飲食店のスタッフ数を取得する。具体的には、第２取得処理部２１５は、勤務情報Ｄ３（図４参照）を参照して、受付処理部２１１が受け付けた検索要求に対応する検索条件に含まれる来店日（予約対象日）の前記スタッフ数を取得する。例えば、利用者が検索条件設定ページＰ１（図５参照）において来店日に「２０２０年９月２日」を入力して、検索処理部２１２が検索条件を満たす飲食店Ｓ１を検索した場合に、第２取得処理部２１５は、飲食店Ｓ１に対応する勤務情報Ｄ３（図４参照）を参照して、「２０２０年９月２日」（予約対象日）の飲食店Ｓ１のスタッフ数として、「３人」を取得する。第２取得処理部２１５は、検索処理部２１２により検索される飲食店ごとに、前記予約対象日のスタッフ数を取得する。第２取得処理部２１５は、本発明の第２取得処理部の一例である。

算出処理部２１６は、第２取得処理部２１５により取得される前記スタッフ数に基づいて、前記予約対象日に飲食店が受け入れ可能な利用者の人数（前記受入可能人数）を算出する。具体的には、算出処理部２１６は、前記スタッフ数に前記基準利用者数を乗算した結果を前記受入可能人数として算出する。前記基準利用者数は、上述のように、例えば１人のスタッフがサービス対応可能な利用者数である。算出処理部２１６は、算出した前記受入可能人数を勤務情報Ｄ３（図４参照）に登録する。なお、算出処理部２１６は、受付処理部２１１が前記検索要求を受け付けた場合に前記予約対象日の前記受入可能人数を算出してもよいし、各スタッフの勤務スケジュールが勤務情報Ｄ３に登録された時点で各日の前記受入可能人数を算出してもよい。算出処理部２１６は、本発明の算出処理部の一例である。

出力処理部２１７は、第１取得処理部２１４により取得される前記利用者数と、算出処理部２１６により算出される前記受入可能人数とに基づいて、前記予約対象日の飲食店の利用に関する特典情報を出力する。具体的には、出力処理部２１７は、前記予約対象日に対応する割引情報Ｍ２（本発明の特典情報の一例）を検索結果ページＰ２に表示させる。例えば、出力処理部２１７は、前記受入可能人数に対する前記利用者数の割合（以下、利用者割合ともいう。）が閾値未満の場合に割引情報Ｍ２を出力する。出力処理部２１７は、本発明の出力処理部の一例である。

例えば前記閾値が０．５に設定されている場合において、予約対象日（来店日）が「２０２０年９月２日」の場合、出力処理部２１７は、前記受入可能人数（２４人）に対する前記利用者数（１４人）の割合として「０．５８」（＝１４÷２４）を算出する。この場合、出力処理部２１７は、前記利用者割合が前記閾値以上になるため、検索結果ページＰ２における飲食店Ｓ１に対して割引情報Ｍ２を表示させない（図６参照）。

これに対して、例えば前記閾値が０．５に設定されている場合において、予約対象日（来店日）が「２０２０年９月３日」の場合、出力処理部２１７は、前記受入可能人数（３２人）に対する前記利用者数（１２人）の割合として「０．３７」（＝１２÷３２）を算出する。この場合、出力処理部２１７は、前記利用者割合が前記閾値未満となるため、検索結果ページＰ２における飲食店Ｓ１に対して割引情報Ｍ２を表示させる（図７参照）。このように、制御部２１は、前記受入可能人数に対する前記利用者数が少ない場合に割引情報Ｍ２を表示させることにより、利用者に予約を促して飲食店Ｓ１の利用者数の増加を図る。

ここで、前記閾値は、例えば、予約する利用者の予想人数と、予約しないで来店する客（ウォークイン客）の予想人数とのバランスにより飲食店ごとに設定される。例えば、飲食店Ｓ１において、４０席のうち２０席分をウォークイン客用として確保し、残りの２０席分を予約用として予約サイトに登録する場合には、前記閾値が０．５に設定される。また例えば、ウォークイン客よりも予約客を優先する飲食店Ｓ２では、４０席のうち１２席分をウォークイン客用として確保し、残りの２８席分を予約用として予約サイトに登録する場合には、前記閾値が０．７（＝２８÷４０）に設定される。各飲食店の管理者は、予め前記閾値を設定することが可能であり、また設定した前記閾値を変更することが可能である。

本発明の特典情報は、飲食店の飲食代を所定金額（例えば５００円）又は所定割引率（例えば１０％）だけ割り引く割引情報Ｍ２（図７の割引クーポン）であってもよいし、特定の料理（例えばデザート、ドリンク）を無料で提供する料理サービス情報であってもよいし、飲食店が利用者に付与するポイント情報であってもよい。

他の実施形態として、出力処理部２１７は、前記受入可能人数に対する前記利用者数の割合（利用者割合）に応じた割引情報Ｍ２を出力してもよい。具体的には、出力処理部２１７は、前記利用者割合が低い程、割引情報Ｍ２の割引率を高く設定し、前記利用者割合が高い程、割引情報Ｍ２の割引率を低く設定する。例えば飲食店Ｓ１において、「２０２０年９月３日」の前記利用者割合が「０．３７」（＝１２÷３２）の場合、出力処理部２１７は、飲食代を１５％ＯＦＦする割引情報Ｍ２を出力し、「２０２０年９月５日」の前記利用者割合が「０．４５」（＝１８÷４０）の場合、出力処理部２１７は、飲食代を１０％ＯＦＦする割引情報Ｍ２を出力する。このように、出力処理部２１７は、スタッフ数に対応する前記受入可能人数に対する予約数（前記利用者数）が少ない程、利用者に提供するサービスを拡大することにより利用者に予約を促す。

また、他の実施形態として、出力処理部２１７は、前記受入可能人数に対する前記利用者数の割合が前記閾値未満であって、かつ、前記予約対象日が特定日の場合に割引情報Ｍ２を出力してもよい。例えば、飲食店は、毎週の金曜日及び土曜日、毎月の月末、イベント日などの特定日については、早期に予約客を確保したい場合がある。このような場合、出力処理部２１７は、前記予約対象日が特定日の場合に割引情報Ｍ２を出力し、前記予約対象日が特定日以外の場合に割引情報Ｍ２を出力しない構成としてもよい。一方で、飲食店は、毎週の金曜日及び土曜日、毎月の月末、イベント日などの特定日については、ウォークイン客が多く来店する可能性があり、ウォークイン客を多く受け入れたい場合もある。このような場合には、出力処理部２１７は、前記予約対象日が特定日の場合に割引情報Ｍ２を出力せず、前記予約対象日が特定日以外の場合に割引情報Ｍ２を出力する構成としてもよい。

また、他の実施形態として、出力処理部２１７は、割引情報Ｍ２を所定日に出力してもよい。例えば、毎週の金曜日及び土曜日、毎月の月末、イベント日などの特定日については、割引サービスなどの特典がなくても飲食店に対する予約の申し込みが多くなることが考えられる。このため、出力処理部２１７は、前記予約対象日が前記特定日の場合には、前記予約対象日の直前（例えば前日）まで割引情報Ｍ２を出力せず、前記予約対象日の前日（本発明の所定日の一例）に割引情報Ｍ２を出力してもよい。例えば飲食店Ｓ１において、利用者が現時点（「２０２０年９月１日（火曜日）」）に、来店日（図５参照）の条件として「２０２０年９月５日（土曜日）」を設定して検索要求を行った場合には、出力処理部２１７は現時点では割引情報Ｍ２を出力しない。一方、利用者が現時点（「２０２０年９月４日（金曜日）」）に、来店日の条件として「２０２０年９月５日（土曜日）」を設定して検索要求を行った場合には、出力処理部２１７は現時点で割引情報Ｍ２を出力する。これにより、直前に予約枠がある場合には、割引サービスを提供することにより直前の予約を受け入れ易くすることができる。

本発明の所定日は、前記特定日の前日に限定されず、予約対象日に応じて設定されてもよい。例えば前記予約対象日がイベント日である場合には、前記所定日は、前記イベント日の１週間前又は１カ月前の日であってもよい。この場合、出力処理部２１７は、前記所定日よりも前には割引情報Ｍ２を出力せず、前記所定日以降に割引情報Ｍ２を出力する。

図７に示す検索結果ページＰ２において利用者が飲食店Ｓ１の予約ボタンＫ２３を押下して予約要求を行った場合、予約処理部２１３は、飲食店Ｓ１の予約要求を受け付け、飲食店Ｓ１の予約処理を実行する。新たな予約を受け付けて予約情報Ｄ２が更新されると、出力処理部２１７は、更新された前記利用者数に基づいて割引情報Ｍ２を出力する処理を実行する。そして、出力処理部２１７は、前記受入可能人数に対する前記利用者数の割合が前記閾値以上になるまで割引情報Ｍ２を出力する処理を繰り返す。

［利用者端末３］
図１に示されるように、利用者端末３は、制御部３１、記憶部３２、操作表示部３３、及び通信Ｉ／Ｆ３４などを備える。利用者端末３は、例えば携帯電話、スマートフォン、タブレット端末、又はパーソナルコンピューターのような情報処理装置である。

通信Ｉ／Ｆ３４は、利用者端末３を有線又は無線で通信網Ｎ１に接続し、通信網Ｎ１を介して情報処理装置２、施設端末４などの外部機器との間で所定の通信プロトコルに従ったデータ通信を実行するための通信インターフェースである。

操作表示部３３は、各種のウェブページなどの情報を表示する液晶ディスプレイ又は有機ＥＬディスプレイのような表示部と、操作を受け付けるマウス、キーボード、又はタッチパネルのような操作部とを備えるユーザーインターフェースである。

記憶部３２は、各種の情報を記憶するＨＤＤ、ＳＳＤ又はフラッシュメモリーなどの不揮発性の記憶部である。例えば、記憶部３２には、ブラウザプログラム等の制御プログラムが記憶される。具体的に、前記ブラウザプログラムは、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などの通信プロトコルに従って情報処理装置２などの外部装置との間で通信処理を制御部３１に実行させるための制御プログラムである。また、前記ブラウザプログラムは、情報処理装置２との間で予め定められた通信プロトコルに従って通信処理を実行するための専用アプリケーションであることも考えられる。なお、記憶部３２には、地図データ等の他の情報が記憶されていてもよい。

制御部３１は、ＣＰＵ、ＲＯＭ、及びＲＡＭなどの制御機器を有する。前記ＣＰＵは、各種の演算処理を実行するプロセッサーである。前記ＲＯＭは、前記ＣＰＵに各種の処理を実行させるためのＢＩＯＳ及びＯＳなどの制御プログラムが予め記憶された不揮発性の記憶部である。前記ＲＡＭは、各種の情報を記憶する揮発性又は不揮発性の記憶部であり、前記ＣＰＵが実行する各種の処理の一時記憶メモリー（作業領域）として使用される。そして、制御部３１は、前記ＲＯＭ又は記憶部３２に予め記憶された各種の制御プログラムを前記ＣＰＵで実行することにより利用者端末３を制御する。

具体的に、制御部３１は、記憶部３２に記憶されている前記ブラウザプログラムに従って各種の処理を実行することによりブラウザ処理部３１１として機能する。ブラウザ処理部３１１は、情報処理装置２から通信網Ｎ１を介して提供されるウェブページを操作表示部３３に表示させ、操作表示部３３に対する操作を情報処理装置２に入力するブラウザ処理を実行することが可能である。すなわち、利用者端末３は、制御部３１によって前記ブラウザプログラムが実行されることにより、情報処理装置２の操作用端末として機能することが可能である。なお、制御部３１に含まれる一部又は全部の処理部は電子回路で構成されていてもよい。

例えば、利用者端末３では、情報処理システム１で提供される予約サービスの前記予約サイトに対応する所定のＵＲＬへのアクセス要求を行うためのユーザー操作が行われた場合に、制御部３１が、情報処理装置２から前記予約サイトのウェブページのデータを取得して、操作表示部３３に前記予約サイトのウェブページを表示させる。なお、例えば前記所定のＵＲＬへのアクセス要求は、予め登録されたウェブサイトの一覧からの選択操作、情報検索サイトにおける検索結果からの選択操作、又はテキスト入力操作などによって行われる。また、利用者端末３に情報処理装置２に対応する専用アプリケーションがインストールされている場合には、利用者端末３の利用者が当該専用アプリケーションを起動する操作を行うことにより操作表示部３３に前記予約サイトのウェブページが表示される。

そして、利用者は、利用者端末３を操作することにより、前記予約サイトの検索条件設定ページＰ１（図５参照）において所望の検索条件を設定して飲食店の検索を要求し、検索結果ページＰ２（図６、図７参照）を閲覧することができる。さらに利用者は、検索結果として提示された飲食店の中から所望の飲食店を選択して予約の申し込み（予約要求）を行うことができる。

［施設端末４］
図１に示されるように、施設端末４は、制御部４１、記憶部４２、操作表示部４３、及び通信Ｉ／Ｆ４４などを備える。施設端末４は、例えば、タブレット端末又はパーソナルコンピューターのような情報処理装置である。なお、施設端末４は、情報処理装置２と同一の機能をさらに備えてもよいし、情報処理装置２と一体の情報処理装置であってもよい。

通信Ｉ／Ｆ４４は、施設端末４を有線又は無線で通信網Ｎ１に接続し、通信網Ｎ１を介して情報処理装置２、利用者端末３などの外部機器との間で所定の通信プロトコルに従ったデータ通信を実行するための通信インターフェースである。

操作表示部４３は、各種のウェブページなどの情報を表示する液晶ディスプレイ又は有機ＥＬディスプレイのような表示部と、操作を受け付けるマウス、キーボード、又はタッチパネルのような操作部とを備えるユーザーインターフェースである。

記憶部４２は、各種の情報を記憶するＨＤＤ、ＳＳＤ又はフラッシュメモリーなどの不揮発性の記憶部である。例えば、記憶部４２には、ブラウザプログラム等の制御プログラムが記憶される。具体的に、前記ブラウザプログラムは、ＨＴＴＰなどの通信プロトコルに従って情報処理装置２などの外部装置との間で通信処理を制御部４１に実行させるための制御プログラムである。また、前記ブラウザプログラムは、情報処理装置２との間で予め定められた通信プロトコルに従って通信処理を実行するための専用アプリケーションであることも考えられる。

また、記憶部４２には、飲食店に対応する予約を管理する予約管理情報（不図示）が記憶される。前記予約管理情報には、来店日、予約者名、予約人数、テーブルなどの情報が含まれる。前記予約管理情報は、予約情報Ｄ２（図３参照）であってもよい。すなわち、予約情報Ｄ２は、情報処理装置２に記憶されてもよいし、施設端末４に記憶されてもよい。

また、記憶部４２には、飲食店のスタッフの勤務スケジュールに関する情報（シフト情報）が記憶される。前記シフト情報には、各スタッフの名前、出勤予定日などの情報が含まれる。前記シフト情報は、勤務情報Ｄ３（図４参照）であってもよい。すなわち、勤務情報Ｄ３は、情報処理装置２に記憶されてもよいし、施設端末４に記憶されてもよい。

制御部４１は、ＣＰＵ、ＲＯＭ、及びＲＡＭなどの制御機器を有する。前記ＣＰＵは、各種の演算処理を実行するプロセッサーである。前記ＲＯＭは、前記ＣＰＵに各種の処理を実行させるためのＢＩＯＳ及びＯＳなどの制御プログラムが予め記憶された不揮発性の記憶部である。前記ＲＡＭは、各種の情報を記憶する揮発性又は不揮発性の記憶部であり、前記ＣＰＵが実行する各種の処理の一時記憶メモリー（作業領域）として使用される。そして、制御部４１は、前記ＲＯＭ又は記憶部４２に予め記憶された各種の制御プログラムを前記ＣＰＵで実行することにより施設端末４を制御する。

具体的に、制御部４１は、記憶部４２に記憶されている前記ブラウザプログラムに従って各種の処理を実行することによりブラウザ処理部４１１として機能する。ブラウザ処理部４１１は、情報処理装置２から通信網Ｎ１を介して提供されるウェブページを操作表示部４３に表示させ、操作表示部４３に対する操作を情報処理装置２に入力するブラウザ処理を実行することが可能である。すなわち、施設端末４は、制御部４１によって前記ブラウザプログラムが実行されることにより、情報処理装置２の操作用端末として機能することが可能である。なお、制御部４１に含まれる一部又は全部の処理部は電子回路で構成されていてもよい。

例えば、施設端末４では、情報処理システム１で提供される勤務管理サイトに対応する所定のＵＲＬへのアクセス要求を行うためのユーザー操作が行われた場合に、制御部４１が、情報処理装置２から前記勤務管理サイトのウェブページのデータを取得して、操作表示部４３に前記勤務管理サイトのウェブページ（不図示）を表示させる。前記ウェブページにおいて飲食店の管理者が各スタッフの勤務スケジュールを入力すると、情報処理装置２の制御部２１は、入力データを取得して勤務情報Ｄ３に登録する。飲食店の管理者は、施設端末４を操作して勤務情報Ｄ３の勤務スケジュールを登録、変更することができる。

［情報処理］
以下、図８を参照しつつ、情報処理システム１において実行される情報処理について説明する。具体的に、本実施形態では、情報処理装置２の制御部２１によって前記情報処理が実行される。また、制御部２１は、利用者端末３各々からのアクセスに応じて利用者端末３各々に対応して情報処理を並行して実行することが可能である。なお、制御部２１は、利用者端末３の所定の操作によって情報処理を途中で終了することがある。

なお、本発明は、前記情報処理に含まれる一又は複数のステップを実行する情報処理方法の発明として捉えることができる。また、ここで説明する前記情報処理に含まれる一又は複数のステップは適宜省略されてもよい。なお、前記情報処理における各ステップは同様の作用効果を生じる範囲で実行順序が異なってもよい。さらに、ここでは制御部２１によって前記情報処理における各ステップが実行される場合を例に挙げて説明するが、一又は複数のプロセッサーによって当該情報処理における各ステップが分散して実行される情報処理方法も他の実施形態として考えられる。

先ず、ステップＳ１１において、制御部２１は、利用者端末３から飲食店の検索要求を受け付けたか否かを判定する。具体的には、制御部２１は、利用者端末３に表示される予約サイト（例えば、飲食店予約サイト）の検索条件設定ページＰ１（図５参照）において利用者により入力されるエリア、来店日、利用人数を含む検索条件を受け付けたか否かを判定する。なお、前記検索条件に、来店時刻、料理ジャンル、予算などの情報が含まれてもよい。制御部２１が利用者端末３から前記検索要求を受け付けると（Ｓ１１：Ｙｅｓ）、処理はステップＳ１２に移行する。制御部２１は、利用者端末３から前記検索要求を受け付けるまで待機する（Ｓ１１：Ｎｏ）。

次にステップＳ１２において、制御部２１は、施設情報Ｄ１（図２参照）に含まれる複数の飲食店の中から、前記検索条件を満たす飲食店を検索する。図５に示す例では、制御部２１は、「銀座」のエリアに属し、「２０２０年９月２日」に「４人」の利用人数で予約が可能な飲食店を検索する。

次にステップＳ１３において、制御部２１は、前記検索条件で予約可能な飲食店が存在するか否かを判定する。施設情報Ｄ１に予約可能な飲食店が存在する場合（Ｓ１３：Ｙｅｓ）、処理はステップＳ１４に移行する。一方、施設情報Ｄ１に予約可能な飲食店が存在しない場合（Ｓ１３：Ｎｏ）、処理はステップＳ１３１に移行する。例えば、現時点で予約枠に空きがある飲食店は、前記予約可能な飲食店と判断される。なお、現時点で予約枠が埋まっている場合でも、予約方法の設定（不図示）においてリクエスト予約の予約要求の受け付けを許可する設定を行っている飲食店は、予約可能な飲食店と判断されてもよい。

ステップＳ１４では、制御部２１は、施設情報Ｄ１から予約可能な飲食店を抽出する。例えば、制御部２１は、施設情報Ｄ１に登録された複数の飲食店の中から、銀座のエリアに属し、２０２０年９月２日に４人の利用人数で予約が可能な飲食店を抽出する。

次に、ステップＳ１５において、制御部２１は、抽出した飲食店の予約対象日（前記来店日）の利用者数を取得する。具体的には、制御部２１は、予約情報Ｄ２（図３参照）を参照して、前記来店日の各飲食店の前記利用者数を取得する。例えば、前記来店日が「２０２０年９月２日」の場合、制御部２１は、飲食店Ｓ１の利用者数として「１４人」を取得する。制御部２１は、抽出した飲食店ごとに、前記来店日の利用者数を取得する。ステップＳ１５は、第１取得ステップの一例である。

次に、ステップＳ１６において、制御部２１は、抽出した飲食店の予約対象日（前記来店日）のスタッフ数を取得する。具体的には、制御部２１は、勤務情報Ｄ３（図４参照）を参照して、前記来店日の各飲食店の前記スタッフ数を取得する。例えば、前記来店日が「２０２０年９月２日」の場合、制御部２１は、飲食店Ｓ１のスタッフ数として「３人」を取得する。制御部２１は、抽出した飲食店ごとに、前記来店日のスタッフ数を取得する。ステップＳ１６は、第２取得ステップの一例である。

次に、ステップＳ１７において、制御部２１は、取得した前記スタッフ数に基づいて、予約対象日（前記来店日）に飲食店が受け入れ可能な利用者の人数（前記受入可能人数）を算出する。具体的には、制御部２１は、前記スタッフ数に前記基準利用者数を乗算した結果を前記受入可能人数として算出する。例えば飲食店Ｓ１において、１人のスタッフがサービス対応可能な利用者数が８人の場合、前記基準利用者数は８人に設定される。飲食店Ｓ１の前記基準利用者数が８人に設定された場合、制御部２１は、飲食店Ｓ１の「２０２０年９月２日」の前記受入可能人数として「２４人」を算出する。制御部２１は、算出した前記受入可能人数を勤務情報Ｄ３（図４参照）に登録する。ステップＳ１７は、算出ステップの一例である。

次に、ステップＳ１８において、制御部２１は、前記受入可能人数に対する前記利用者数の割合（利用者割合）が前記閾値未満であるか否かを判定する。前記利用者割合が前記閾値未満である場合（Ｓ１８：Ｙｅｓ）、処理はステップＳ１９に移行する。一方、前記利用者割合が前記閾値以上である場合（Ｓ１８：Ｎｏ）、処理はステップＳ１８１に移行する。前記閾値は、各飲食店の管理者により予め設定される。例えば、管理者は、ウォークイン客よりも予約客を優先したい場合、前記閾値を高く設定して、予約検索する利用者に特典を付与し易くする。これに対して、例えば、管理者は、予約客よりもウォークイン客を優先したい場合、前記閾値を低く設定して、予約検索する利用者に特典を付与し難くする。

例えば予約対象日（来店日）が「２０２０年９月２日」の場合、制御部２１は、飲食店Ｓ１について、前記受入可能人数（２４人）に対する前記利用者数（１４人）の割合として「０．５８」を算出する。前記閾値が０．５に設定されている場合、制御部２１は、「２０２０年９月２日」に対応する前記利用者割合が前記閾値以上であると判定する。これに対して、例えば予約対象日（来店日）が「２０２０年９月３日」の場合、制御部２１は、飲食店Ｓ１について、前記受入可能人数（３２人）に対する前記利用者数（１２人）の割合として「０．３７」を算出する。前記閾値が０．５に設定されている場合、制御部２１は、「２０２０年９月３日」に対応する前記利用者割合が前記閾値未満であると判定する。制御部２１は、抽出した飲食店ごとに、前記利用者割合を算出して前記閾値と比較する判定処理を実行する。

ステップＳ１９では、制御部２１は、検索結果ページＰ２に割引情報Ｍを出力する。例えば図７に示すように、制御部２１は、利用者端末３に検索結果ページＰ２を表示させ、検索結果ページＰ２において前記利用者割合が前記閾値未満になる飲食店Ｓ１に対応付けて割引情報Ｍ２を表示させる。ステップＳ１９は、出力ステップの一例である。

これに対して、ステップＳ１８１では、制御部２１は、飲食店Ｓ１について、割引情報Ｍを出力しないで検索結果ページＰ２（図６参照）を利用者端末３に表示させる。制御部２１は、抽出した飲食店のうち前記利用者割合が前記閾値未満になる飲食店に対して、検索結果ページＰ２において割引情報Ｍを表示させる。なお、制御部２１は、抽出した飲食店ごとに、上述のステップＳ１５～Ｓ１９、Ｓ１８１の処理を繰り返し実行してもよい。ステップＳ１９，Ｓ１８１の後、処理はステップＳ２０に移行する。

ステップＳ２０において、制御部２１は、検索結果ページＰ２において利用者から飲食店に対する予約要求を受け付けると、予約処理を実行する。例えば、図７に示す検索結果ページＰ２において利用者が飲食店Ｓ１の飲食店情報Ｒ２に含まれる予約ボタンＫ２３を押下した場合、制御部２１は、飲食店Ｓ１の予約処理を完了させて予約完了メールを利用者端末３と飲食店Ｓ１の施設端末４とに通知する。

なお、ステップＳ１３において、前記検索処理の結果、予約可能な飲食店が存在しない場合には（Ｓ１３：Ｎｏ）、ステップＳ１３１において、制御部２１は、前記予約可能な飲食店が存在しないことを示す検索結果を利用者に提示して検索条件の変更を要求する。その後、処理はステップＳ１３２に移行する。

ステップＳ１３２では、制御部２１は、検索条件の変更を受け付けたか否かを判定する。制御部２１が検索条件の変更を受け付けたと判定した場合（Ｓ１３２：Ｙｅｓ）、処理はステップＳ１２に戻る。ステップＳ１２に戻ると、制御部２１は、変更された検索条件に基づいて再度、検索処理を実行する。一方、制御部２１が検索条件の変更を受け付けない判定した場合（Ｓ１３２：Ｎｏ）、制御部２１は、前記情報処理を終了する。例えば、利用者が検索結果ページＰ２（図７参照）においてキャンセルボタンＫ２４を押下した場合に、制御部２１は前記情報処理を終了する。以上のようにして、制御部２１は、前記情報処理を実行する。

以上説明したように、本実施形態に係る情報処理装置２は、飲食店の予約対象日の利用者数と、前記予約対象日の前記飲食店のスタッフ数とを取得し、前記スタッフ数に基づいて、前記予約対象日に前記飲食店が受け入れ可能な利用者の受入可能人数を算出する。また、情報処理装置２は、前記利用者数と前記受入可能人数とに基づいて前記予約対象日の前記飲食店の利用に関する特典情報を出力する。例えば、情報処理装置２は、前記受入可能人数に対する前記利用者数の割合が閾値未満の場合に割引情報を出力する。この構成によれば、例えば飲食店Ｓ１において、５人のスタッフによって受け入れ可能な利用者の人数（受入可能人数）のうち、予約客の割合が前記閾値未満である場合には、割引情報Ｍを利用者に提示して予約を促すことができる。これにより、スタッフ数に見合った客数を確保することができるため、人件費に見合った売上を確保することができる。よって、飲食店の利用者数を増加させつつ利益を拡大させることが可能になる。

また、例えばスタッフ一人当たりの利用者数が所定数よりも多くなる場合には、割引情報Ｍを出力しない構成とすることもできる。これにより、予約数を抑制することができるため、スタッフのオーバーワークを防ぐことができるとともに、サービスの質の低下を防ぐことができる。

また、割引情報Ｍを利用者に提示することにより利用者が予約し易くなるため、利用者による検索、予約要求などの操作回数を削減することができる。よって、検索処理及び予約処理に関する通信トラフィックの低減、及びコンピュータリソースの有効利用が可能となる。

本発明の情報処理システムは、上述の実施形態に限定されない。本発明の他の実施形態について以下に説明する。

上述の各実施形態では、制御部２１は、予約対象日の利用者数を取得している。他の実施形態として、制御部２１は、過去の利用者数を取得してもよい。例えば、制御部２１は、利用者が検索条件に設定した来店日の前日、来店日と同一の日、曜日、イベント日などの過去の利用者数を取得してもよい。この場合、制御部２１は、前記受入可能人数に対する過去の前記利用者数の割合が前記閾値未満の場合に割引情報Ｍ２を出力する。すなわち、制御部２１は、履歴情報に基づいて、割引情報Ｍ２の出力処理を実行してもよい。

また、上述の各実施形態では、制御部２１は、予約対象日（来店日）の利用者数及びスタッフ数を取得し、当該スタッフ数に基づいて予約対象日の受入可能人数を算出し、前記受入可能人数に対する前記利用者数の割合が前記閾値未満の場合に割引情報Ｍ２を出力している。他の実施形態として、制御部２１は、利用対象日の利用者数及びスタッフ数を取得し、当該スタッフ数に基づいて利用対象日の受入可能人数を算出し、前記受入可能人数に対する前記利用者数の割合が前記閾値未満の場合に割引情報Ｍ２を出力する構成としてもよい。すなわち、本発明の施設は、利用者が予約する予約対象の施設に限定されず、利用者が予約をしないで利用する施設であってもよい。また、前記利用者数は、予約した利用者の人数に限定されず、当日来店している現在の客数であってもよい。例えば、制御部２１は、利用者の検索要求を受け付けることなく、当日予約可能な飲食店を抽出して、当日の利用者数及びスタッフ数を取得し、当該スタッフ数に基づいて当日の受入可能人数を算出し、前記受入可能人数に対する前記利用者数の割合が前記閾値未満の場合に割引情報Ｍ２を出力してもよい。利用者は割引情報Ｍを見て、飲食店を当日予約して来訪してもよいし、飲食店を予約しないで来訪してもよい。上述の前記予約対象日は、本発明の利用対象日の一例である。

また、他の実施形態として、制御部２１は、予約対象時間帯（来店時間帯）の利用者数及びスタッフ数を取得し、当該スタッフ数に基づいて予約対象時間帯の受入可能人数を算出し、前記受入可能人数に対する前記利用者数の割合が前記閾値未満の場合に割引情報Ｍ２を出力してもよい。検索条件に時間帯（予約時間）を設定できる場合には、時間帯ごとに利用者数が異なる場合がある。このため、制御部２１は、予約対象時間帯ごとに割引情報Ｍ２を出力する構成であってもよい。

例えば図９に示すように、予約情報Ｄ２に、予約時間が含まれてもよい。前記予約時間は、利用者が飲食店を利用可能な利用可能時間であって、利用を開始する利用開始時刻と利用を終了する利用終了時刻とが含まれる。飲食店Ｓ１において利用可能時間が２時間制に設定されている場合、利用開始時刻から２時間後の時刻が利用終了時刻に登録される。予約処理部２１３は、利用者の予約要求を受け付けると、利用開始時刻及び利用終了時刻を予約情報Ｄ２に登録する。また予約処理部２１３は、時間帯ごとに、予約人数の合計数を算出して前記利用者数として予約人数情報Ｄ４に登録する。

図１０には、予約人数情報Ｄ４の一例を示している。予約人数情報Ｄ４には、来店日、時間帯、利用者数の情報が含まれる。前記時間帯は、所定の時間間隔に設定される。ここでは、前記時間帯は１時間間隔に設定されている。予約処理部２１３は、図９に示す予約情報Ｄ２に基づいて１時間ごとの各時間帯の予約人数の合計数を算出して、予約人数情報Ｄ４の前記利用者数に登録する。

第１取得処理部２１４は、飲食店の予約対象時間帯の利用者数を取得する。具体的には、第１取得処理部２１４は、予約人数情報Ｄ４（図１０参照）を参照して、受付処理部２１１が受け付けた検索要求に対応する検索条件に含まれる来店日時（予約対象時間帯）の前記利用者数を取得する。例えば、利用者が検索条件設定ページＰ１において来店日に「２０２０年９月２日」を入力し、来店時刻に「１９：００」を入力して、検索処理部２１２が検索条件を満たす飲食店Ｓ１を検索した場合に、第１取得処理部２１４は、飲食店Ｓ１に対応する予約人数情報Ｄ４（図１０参照）を参照して、「２０２０年９月２日 １９：００－２０：００」の飲食店Ｓ１の利用者数として、「１４人」を取得する。また例えば、利用者が検索条件設定ページＰ１において来店日に「２０２０年９月２日」を入力し、来店時刻に「２０：００」を入力して、検索処理部２１２が検索条件を満たす飲食店Ｓ１を検索した場合に、第１取得処理部２１４は、飲食店Ｓ１に対応する予約人数情報Ｄ４（図１０参照）を参照して、「２０２０年９月２日 ２０：００－２１：００」の飲食店Ｓ１の利用者数として、「７人」を取得する。

第２取得処理部２１５は、予約対象時間帯の飲食店のスタッフ数を取得する。時間帯に応じてスタッフ数が異なる場合には、第２取得処理部２１５は、来店時刻に対応するスタッフ数を取得する。

算出処理部２１６は、第２取得処理部２１５により取得される前記スタッフ数に基づいて、前記予約対象時間帯に飲食店が受け入れ可能な利用者の人数（前記受入可能人数）を算出する。

出力処理部２１７は、第１取得処理部２１４により取得される前記利用者数と、算出処理部２１６により算出される前記受入可能人数とに基づいて、前記予約対象時間帯の飲食店の利用に関する特典情報を出力する。具体的には、出力処理部２１７は、前記受入可能人数に対する前記利用者数の割合（利用者割合）が前記閾値未満の場合に、前記予約対象時間帯に対応する割引情報Ｍ２を検索結果ページＰ２に表示させる。

例えば前記閾値が０．５に設定されている場合において、予約対象日時（来店日時）が「２０２０年９月２日 １９：００」の場合、出力処理部２１７は、前記受入可能人数（２４人）に対する前記利用者数（１４人）の割合として「０．５８」を算出する。この場合、出力処理部２１７は、前記利用者割合が前記閾値以上となるため、検索結果ページＰ２における飲食店Ｓ１に対して割引情報Ｍ２を表示させない。

これに対して、例えば前記閾値が０．５に設定されている場合において、予約対象日時（来店日時）が「２０２０年９月２日 ２０：００」の場合、出力処理部２１７は、前記受入可能人数（２４人）に対する前記利用者数（７人）の割合として「０．２９」を算出する。この場合、出力処理部２１７は、前記利用者割合が前記閾値未満となるため、検索結果ページＰ２における飲食店Ｓ１に対して割引情報Ｍ２を表示させる。このように、所定の時間帯に対応する割引情報Ｍ２を表示させることにより、当該時間帯の予約を増加させることができる。また、時間帯ごとの来店者数のばらつきを抑えることができるため、業務の効率化及び売上の拡大を図ることができる。なお、前記予約対象時間帯は、本発明の利用対象時間帯の一例である。

なお、出力処理部２１７は、検索結果ページＰ２において、予約対象日に対応する予約対象時間帯ごとに割引情報Ｍ２を表示させてもよい。例えば、出力処理部２１７は、検索結果ページＰ２の飲食店Ｓ１の飲食店情報Ｒ２に、各時間帯（１８時～１９時、１９時～２０時、２０時～２１時、２１時～２２時）の予約可否の情報（空席情報）と、各時間帯に対応付けた割引情報Ｍ２の有無とを表示させてもよい。

また、出力処理部２１７は、前記利用者数が前記受入可能人数未満であって、かつ、前記予約対象時間帯が特定時間帯の場合に割引情報Ｍ２を出力してもよい。例えば、出力処理部２１７は、前記利用者数が前記受入可能人数未満であって、かつ、前記予約対象時間帯がランチタイム又はディナータイムの時間帯の場合に割引情報Ｍ２を出力する。また、例えば、出力処理部２１７は、前記利用者数が前記受入可能人数未満であって、かつ、前記予約対象時間帯がランチタイム以外の時間帯、又は、ディナータイム以外の時間帯の場合に割引情報Ｍ２を出力してもよい。

上述の各実施形態では、出力処理部２１７は、前記受入可能人数に対する前記利用者数の割合が前記閾値未満の場合に割引情報Ｍ２を出力している。他の実施形態として、出力処理部２１７は、前記利用者数が前記受入可能人数未満の場合に割引情報Ｍ２を出力してもよい。例えば、飲食店Ｓ１において、「２０２０年９月３日」の前記受入可能人数が「３２人」の場合において、前記利用者数が３２人未満である場合に、出力処理部２１７は、割引情報Ｍ２を出力してもよい。ここで、前記受入可能人数は、予約者の受入可能人数であってもよい。例えば、飲食店Ｓ１において「２０２０年９月３日」の予約者の受入可能人数が１５人に設定されている場合において、現時点で予約者が１２人である場合には、出力処理部２１７は、「２０２０年９月３日」に対応する割引情報Ｍ２を出力する。

また、他の実施形態として、出力処理部２１７は、前記予約対象日又は前記予約対象時間帯における、想定合計売上又は想定単位売上に基づいて、割引情報Ｍ２を表示するか否かを決定してもよい。例えば、出力処理部２１７は、前記受入可能人数に対する前記利用者数の割合（利用者割合）が前記閾値未満の場合、又は、前記利用者数が前記受入可能人数未満の場合であって、かつ、前記予約対象日又は前記予約対象時間帯における想定合計売上又は想定単位売上が所定売上未満である場合に割引情報Ｍ２を表示すると決定し、前記予約対象日又は前記予約対象時間帯における想定合計売上又は想定単位売上が所定売上以上である場合には割引情報Ｍ２を表示しないと決定する。すなわち、出力処理部２１７が割引情報Ｍ２を出力する条件に、前記予約対象日又は前記予約対象時間帯における想定合計売上又は想定単位売上が所定売上未満であることを追加してもよい。これにより、例えば売上が低く新規客を確保する必要がある場合には、利用者に割引情報Ｍ２を提示して予約を促すことができる。また例えば売上が高く新規客を確保する必要がない場合には、利用者数を抑制することにより業務の効率化を図ることができる。

また、他の実施形態として、出力処理部２１７は、前記予約対象日又は前記予約対象時間帯における、前記利用者数又は予約数に基づいて、割引情報Ｍ２を表示するか否かを決定してもよい。例えば、出力処理部２１７は、前記受入可能人数に対する前記利用者数の割合（利用者割合）が前記閾値未満の場合、又は、前記利用者数が前記受入可能人数未満の場合であって、かつ、前記予約対象日又は前記予約対象時間帯における前記利用者数又は予約数が所定数未満である場合に割引情報Ｍ２を表示すると決定し、前記予約対象日又は前記予約対象時間帯における前記利用者数又は予約数が所定数以上である場合に割引情報Ｍ２を表示しないと決定する。すなわち、出力処理部２１７が割引情報Ｍ２を出力する条件に、前記予約対象日又は前記予約対象時間帯における前記利用者数又は予約数が所定数未満であることを追加してもよい。これにより、例えば予約数が少なく新規客を確保する必要がある場合には、利用者に割引情報Ｍ２を提示して予約を促すことができる。また例えば予約数が多く新規客を確保する必要がない場合には、予約数を抑制することにより業務の効率化を図ることができる。

また、他の実施形態として、算出処理部２１６は、厨房スタッフのスタッフ数と接客スタッフ（ホールスタッフ）のスタッフ数とに基づいて、前記受入可能人数を算出してもよい。具体的には、算出処理部２１６は、前記厨房スタッフ数に前記基準利用者数を乗算して厨房受入可能人数を算出し、前記接客スタッフ数に前記基準利用者数を乗算して接客受入可能人数を算出し、これらをの算出結果を比較していずれか少ない方を前記受入可能人数に決定する。

図１１は、勤務情報Ｄ３の他の例を示している。例えば、制御部２１は、日ごとに、出勤予定のスタッフについて厨房スタッフ数と接客スタッフとを個別に合計人数を算出して勤務情報Ｄ３に登録する。そして、例えば１人の厨房スタッフがサービス対応可能な利用者数が６人に設定される場合、算出処理部２１６は、「２０２０年９月１日」の厨房受入可能人数に「６」（＝１×６）を登録し、「２０２０年９月４日」の厨房受入可能人数に「１２」（＝２×６）を登録する。また例えば１人の接客スタッフがサービス対応可能な利用者数が８人に設定される場合、算出処理部２１６は、「２０２０年９月１日」の接客受入可能人数に「１６」（＝２×８）を登録し、「２０２０年９月４日」の接客受入可能人数に「２４」（＝３×８）を登録する。なお、厨房スタッフに対応する前記基準利用者数と、接客スタッフに対応する前記基準利用者数とが同一であってもよいし、厨房スタッフに対応する前記基準利用者数が接客スタッフに対応する前記基準利用者数よりも多くてもよい。

算出処理部２１６は、「２０２０年９月１日」の前記受入可能人数を、厨房受入可能人数（「６」）と接客受入可能人数（「１６」）のうち少ない方（「６」）に決定して勤務情報Ｄ３に登録する。また、算出処理部２１６は、「２０２０年９月４日」の前記受入可能人数を、厨房受入可能人数（「１２」）と接客受入可能人数（「２４」）のうち少ない方（「１２」）に決定して勤務情報Ｄ３に登録する。出力処理部２１７は、算出処理部２１６により決定された前記受入可能人数に対する前記利用者数の割合が閾値未満の場合に割引情報Ｍ２を出力する。この構成によれば、厨房スタッフ及び接客スタッフそれぞれの人数に応じた客数を確保することができる。

また、他の実施形態として、算出処理部２１６は、スタッフの人数及び能力に基づいて前記受入可能人数を算出してもよい。例えば、前記基準利用者数は、スタッフの能力に応じて設定される。例えば、スタッフの能力が高レベルの場合、前記基準利用者数は８人に設定され、スタッフの能力が中レベルの場合、前記基準利用者数は６人に設定され、スタッフの能力が低レベルの場合、前記基準利用者数は４人に設定される。

図１２は、勤務情報Ｄ３の他の例を示している。例えば、制御部２１は、日ごとに、出勤予定のスタッフについて、能力別（高レベル、中レベル、低レベル）に合計人数を算出して勤務情報Ｄ３に登録する。そして、算出処理部２１６は、能力別に、スタッフ数に前記基準利用者数を乗算して受入可能人数を算出する。例えば「２０２０年９月１日」では、算出処理部２１６は、高レベルのスタッフ数「２」に高レベルの基準利用者数「８」を乗算した結果「１６」と、中レベルのスタッフ数「１」に中レベルの基準利用者数「６」を乗算した結果「６」とを合計した合計人数「２２」を算出して受入可能人数に登録する。また例えば「２０２０年９月４日」では、算出処理部２１６は、高レベルのスタッフ数「２」に高レベルの基準利用者数「８」を乗算した結果「１６」と、中レベルのスタッフ数「２」に中レベルの基準利用者数「６」を乗算した結果「１２」と、低レベルのスタッフ数「１」に中レベルの基準利用者数「４」を乗算した結果「４」とを合計した合計人数「３２」を算出して受入可能人数に登録する。出力処理部２１７は、算出処理部２１６により決定された前記受入可能人数に対する前記利用者数の割合が閾値未満の場合に割引情報Ｍ２を出力する。この構成によれば、各スタッフの能力に応じた客数を確保することができる。

また、他の実施形態として、算出処理部２１６は、上述した各実施形態において、さらに料理の仕込みを担当するスタッフ（仕込みスタッフ）を考慮して前記受入可能人数を算出してもよい。前記仕込みスタッフは、例えば飲食店の開店前に、利用者に提供する料理の準備などの仕込作業を行う。一般的に、仕込スタッフがいる場合、料理の事前準備が可能になるため、より多くの客を受け入れることが可能にある。

図１３は、勤務情報Ｄ３の他の例を示している。例えば、制御部２１は、日ごとに、仕込スタッフの有無を勤務情報Ｄ３に登録する。なお、図１３に示すスタッフ数には、仕込スタッフの人数は含まれない。前記仕込スタッフは、厨房スタッフであってもよいし、接客スタッフであってもよいし、仕込み専門のスタッフであってもよい。例えば、仕込スタッフは、翌日に客に提供する料理の仕込作業を行う。図１３に示す例では、「２０２０年９月２日」に登録された仕込スタッフは、翌日の「２０２０年９月３日」の仕込作業を行い、「２０２０年９月３日」に登録された仕込スタッフは、翌日の「２０２０年９月４日」の仕込作業を行う。算出処理部２１６は、仕込作業の有無に応じて、翌日の前記受入可能人数を算出する。なお、算出処理部２１６は、仕込作業の有無に応じて、当日の前記受入可能人数を算出してもよい。具体的には、開店前に仕込スタッフが仕込作業を行う場合、算出処理部２１６は、予め設定された前記基準利用者数を増加させて前記受入可能人数を算出する。例えば、１人のスタッフがサービス対応可能な利用者数（前記基準利用者数）が８人に設定されている場合において、「２０２０年９月２日」に仕込スタッフが仕込作業を行う場合、算出処理部２１６は、「２０２０年９月３日」の前記受入可能人数について、前記基準利用者数を「９人」に増加させて「３６人」（＝４×９）を算出する。なお、「２０２０年９月１日」は仕込スタッフによる仕込作業がないため、算出処理部２１６は、「２０２０年９月２日」の前記受入可能人数について、前記基準利用者数「８人」に基づいて「２４人」（＝３×８）を算出する。このように、仕込スタッフによる仕込作業を考慮することにより、仕込スタッフがいない場合と比較して（図4参照）、前記受入可能人数を増加させることができるため、利用者に予約を促して飲食店の利用者数の増加を図ることができる。

他の実施形態として、算出処理部２１６は、さらに仕込スタッフの人数を考慮して前記受入可能人数を算出してもよい。図１４は、勤務情報Ｄ３の他の例を示している。例えば、制御部２１は、日ごとに、出勤予定のスタッフについて厨房スタッフ数と接客スタッフと仕込スタッフとを個別に合計人数を算出して勤務情報Ｄ３に登録する。なお、図１４に示す仕込スタッフは、厨房スタッフ又は接客スタッフが兼任してもよいし、仕込み専門のスタッフであってもよい。そして、例えば１人の厨房スタッフがサービス対応可能な利用者数が６人に設定される場合、算出処理部２１６は、「２０２０年９月１日」の厨房受入可能人数に「６」（＝１×６）を登録し、「２０２０年９月４日」の厨房受入可能人数に「１２」（＝２×６）を登録する。また例えば１人の接客スタッフがサービス対応可能な利用者数が８人に設定される場合、算出処理部２１６は、「２０２０年９月１日」の接客受入可能人数に「１６」（＝２×８）を登録し、「２０２０年９月４日」の接客受入可能人数に「２４」（＝３×８）を登録する。また例えば１人の仕込スタッフがサービス対応可能な利用者数が３人に設定される場合、算出処理部２１６は、「２０２０年９月１日」の仕込受入可能人数に「３」（＝１×３）を登録し、「２０２０年９月４日」の仕込受入可能人数に「６」（＝２×３）を登録する。なお、厨房スタッフに対応する前記基準利用者数と、接客スタッフに対応する前記基準利用者数と、仕込スタッフに対応する前記基準利用者数とが同一であってもよい、互いに異なってもよい。

算出処理部２１６は、「２０２０年９月１日」の前記受入可能人数を、厨房受入可能人数（「６」）及び接客受入可能人数（「１６」）のうち少ない方（「６」）と、仕込受入可能人数（「３」）とを合計した合計人数（「９」）に決定して勤務情報Ｄ３に登録する。また、算出処理部２１６は、「２０２０年９月４日」の前記受入可能人数を、厨房受入可能人数（「１２」）及び接客受入可能人数（「２４」）のうち少ない方（「１２」）と、仕込受入可能人数（「６」）とを合計した合計人数（「１８」）に決定して勤務情報Ｄ３に登録する。出力処理部２１７は、算出処理部２１６により決定された前記受入可能人数に対する前記利用者数の割合が閾値未満の場合に割引情報Ｍ２を出力する。この構成によれば、厨房スタッフ、接客スタッフ、及び仕込スタッフそれぞれの人数に応じた客数を確保することができる。なお、算出処理部２１６は、厨房受入可能人数と接客受入可能人数と仕込受入可能人数とを合計した合計人数を前記受入可能人数に決定してもよい。

本発明に係る情報処理システムは、施設の利用対象日又は利用対象時間帯の利用者数を取得する第１取得処理部と、前記利用対象日又は前記利用対象時間帯の前記施設のスタッフ数を取得する第２取得処理部と、前記第２取得処理部により取得される前記スタッフ数に基づいて、前記利用対象日又は前記利用対象時間帯に前記施設が受け入れ可能な利用者の受入可能人数を算出する算出処理部と、前記第１取得処理部により取得される前記利用者数と、前記算出処理部により算出される前記受入可能人数とに基づいて、前記利用対象日又は前記利用対象時間帯の前記施設の利用に関する特典情報を出力する出力処理部と、を備えるシステムとして構成されてもよい。また、本発明に係る情報処理方法は、施設の利用対象日又は利用対象時間帯の利用者数を取得する第１取得ステップと、前記利用対象日又は前記利用対象時間帯の前記施設のスタッフ数を取得する第２取得ステップと、記第２取得ステップにより取得される前記スタッフ数に基づいて、前記利用対象日又は前記利用対象時間帯に前記施設が受け入れ可能な利用者の受入可能人数を算出する算出ステップと、前記第１取得ステップにより取得される前記利用者数と、前記算出ステップにより算出される前記受入可能人数とに基づいて、前記利用対象日又は前記利用対象時間帯の予約に関する特典情報を出力する出力ステップと、を一又は複数のプロセッサーにより実行する方法であってもよい。

１ ：情報処理システム
２ ：情報処理装置
３ ：利用者端末
４ ：施設端末
２１１ ：受付処理部
２１２ ：検索処理部
２１３ ：予約処理部
２１４ ：第１取得処理部
２１５ ：第２取得処理部
２１６ ：算出処理部
２１７ ：出力処理部

Claims (15)

1. 施設の利用対象日又は利用対象時間帯の利用者数を取得する第１取得処理部と、
   前記利用対象日又は前記利用対象時間帯の前記施設のスタッフ数を取得する第２取得処理部と、
   前記第２取得処理部により取得される前記スタッフ数に基づいて、前記利用対象日又は前記利用対象時間帯に前記施設が受け入れ可能な利用者の受入可能人数を算出する算出処理部と、
   前記第１取得処理部により取得される前記利用者数と、前記算出処理部により算出される前記受入可能人数とに基づいて、前記利用対象日又は前記利用対象時間帯の前記施設の利用に関する特典情報を出力する出力処理部と、
   を備える情報処理システム。
2. 前記出力処理部は、前記特典情報として、前記利用対象日又は前記利用対象時間帯に対応する割引情報を出力する、
   請求項１に記載の情報処理システム。
3. 前記出力処理部は、前記利用者数が前記受入可能人数未満の場合に前記割引情報を出力する、
   請求項２に記載の情報処理システム。
4. 前記出力処理部は、前記受入可能人数に対する前記利用者数の割合が閾値未満の場合に前記割引情報を出力する、
   請求項２に記載の情報処理システム。
5. 前記出力処理部は、前記受入可能人数に対する前記利用者数の割合に応じた前記割引情報を出力する、
   請求項２～４のいずれかに記載の情報処理システム。
6. 前記出力処理部は、前記利用者数が前記受入可能人数未満であって、かつ、前記利用対象日が特定日又は前記利用対象時間帯が特定時間帯の場合に前記割引情報を出力する、
   請求項５に記載の情報処理システム。
7. 前記出力処理部は、前記受入可能人数に対する前記利用者数の割合が閾値未満であって、かつ、前記利用対象日が特定日又は前記利用対象時間帯が特定時間帯の場合に前記割引情報を出力する、
   請求項５に記載の情報処理システム。
8. 前記出力処理部は、前記利用対象日又は前記利用対象時間帯よりも前の所定日に前記特典情報を出力する、
   請求項１～７のいずれかに記載の情報処理システム。
9. 前記所定日は、前記利用対象日又は前記利用対象時間帯に応じて設定される、
   請求項８に記載の情報処理システム。
10. 前記出力処理部は、前記利用対象日に対応する予約対象時間帯ごとに前記特典情報を表示させる、
    請求項１～９のいずれかに記載の情報処理システム。
11. 前記算出処理部は、１人のスタッフがサービス対応可能な利用者数に基づいて、前記受入可能人数を算出する、
    請求項１～１０のいずれかに記載の情報処理システム。
12. 前記出力処理部は、前記利用対象日又は前記利用対象時間帯における、想定合計売上又は想定単位売上に基づいて、前記特典情報を表示するか否かを決定する、
    請求項１～１１のいずれかに記載の情報処理システム。
13. 前記出力処理部は、前記利用対象日又は前記利用対象時間帯における、前記利用者数又は予約数に基づいて、前記特典情報を表示するか否かを決定する、
    請求項１～１１のいずれかに記載の情報処理システム。
14. 施設の利用対象日又は利用対象時間帯の利用者数を取得する第１取得ステップと、
    前記利用対象日又は前記利用対象時間帯の前記施設のスタッフ数を取得する第２取得ステップと、
    記第２取得ステップにより取得される前記スタッフ数に基づいて、前記利用対象日又は前記利用対象時間帯に前記施設が受け入れ可能な利用者の受入可能人数を算出する算出ステップと、
    前記第１取得ステップにより取得される前記利用者数と、前記算出ステップにより算出される前記受入可能人数とに基づいて、前記利用対象日又は前記利用対象時間帯の予約に関する特典情報を出力する出力ステップと、
    を一又は複数のプロセッサーにより実行する情報処理方法。
15. 施設の利用対象日又は利用対象時間帯の利用者数を取得する第１取得ステップと、
    前記利用対象日又は前記利用対象時間帯の前記施設のスタッフ数を取得する第２取得ステップと、
    記第２取得ステップにより取得される前記スタッフ数に基づいて、前記利用対象日又は前記利用対象時間帯に前記施設が受け入れ可能な利用者の受入可能人数を算出する算出ステップと、
    前記第１取得ステップにより取得される前記利用者数と、前記算出ステップにより算出される前記受入可能人数とに基づいて、前記利用対象日又は前記利用対象時間帯の予約に関する特典情報を出力する出力ステップと、
    を一又は複数のプロセッサーに実行させるための情報処理プログラム。

Images