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

Abstract

【課題】ユーザが指定した人数で実際には利用可能な施設であってもユーザが指定した人数と設備の利用者単位の空き数との関係により従来では提示されなかった施設を提示させる。
【解決手段】空き情報記憶手段に、施設の利用者により埋まる設備の利用者単位の空き数を示す空き情報が記憶される。情報処理装置は、ユーザが指定した利用人数を取得する。情報処理装置は、空き情報記憶手段に記憶された空き情報に基づいて、利用人数で利用可能な施設を検索する。このとき、情報処理装置は、利用人数が空き情報に示される空き数を上回る度合いが基準値以下である施設も、利用可能な施設に含める。情報処理装置は、検索された施設を提示させる。
【選択図】図１０

Description

本発明は、利用可能な施設を検索する情報処理装置及び情報処理方法の技術分野に関する。

従来、飲食店の空席数をデータベースに格納し、空席数が検索条件として入力された人数以上である飲食店の情報をユーザに提示するシステムが知られている（例えば、特許文献１参照）。

特開２００３−７６９０２号公報

ところで、実際には、ソファに詰めて座るなどして２人分の席に３人が座る場合がある。しかしながら、上記従来のシステムでは、このようなケースが全く考慮されていないため、空席数が検索条件として入力された人数未満である飲食店の情報まではユーザに提示することができない。

本発明は、以上の点に鑑みてなされたものであり、ユーザが指定した人数で実際には利用可能な施設であってもユーザが指定した人数と設備の利用者単位の空き数との関係により従来では提示されなかった施設を提示させることができる情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。

上記課題を解決するために、請求項１に記載の発明は、ユーザが指定した利用人数を取得する利用人数取得手段と、施設の利用者により埋まる設備の利用者単位の空き数を示す空き情報を記憶する空き情報記憶手段に記憶された前記空き情報に基づいて、前記利用人数取得手段により取得された利用人数で利用可能な施設を検索する検索手段であり、前記利用人数が前記空き情報に示される空き数を上回る度合いが基準値以下である施設も、前記利用可能な施設に含める検索手段と、前記検索手段により検索された施設を提示させる提示制御手段と、を備え、前記検索手段は、施設の利用者により埋まる設備の利用者単位の空き数が前記利用人数以上である施設を検索する第１方法と、施設の利用者により埋まる設備の利用者単位の空き数が前記利用人数より少なく且つ前記利用人数が前記空き情報に示される空き数を上回る度合いが前記基準値以下である施設を検索する第２方法と、の少なくとも何れかの検索方法を用いて施設を検索することを特徴とする。

この発明によれば、設備の利用者単位の空き数が利用人数よりも少なくても、利用人数が空き数を上回る度合いが基準値以下である施設が、利用可能な施設に含まれて検索される。そのため、ユーザが指定した人数で実際には利用可能な施設であってもユーザが指定した人数と設備の利用者単位の空き数との関係により従来では提示されなかった施設を提示させることができる。

請求項２に記載の発明は、請求項１に記載の情報処理装置において、前記検索手段により検索された施設のうち、前記空き情報に示される空き数が前記利用人数取得手段により取得された利用人数より少ない施設を前記ユーザが前記利用人数で利用する意思が確認されることを条件として前記ユーザに付与される特典を決定する特典決定手段を更に備えることを特徴とする。

この発明によれば、設備の利用者単位の空き数が、ユーザが指定した利用人数よりも少ない施設をユーザが利用する意思があることが確認された場合には、ユーザに特典が付与される。そのため、設備の利用者単位の空き数よりも多い人数で施設を利用することをユーザに促すことができる。

請求項３に記載の発明は、請求項２に記載の情報処理装置において、前記特典決定手段は、前記利用人数が多いほど、付与される特典の価値を高くすることを特徴とする。

この発明によれば、設備の利用者単位の空き数よりも多い人数で施設を利用することをよりユーザに促すことができる。

請求項４に記載の発明は請求項１乃至３の何れか１項に記載の情報処理装置において、施設が指定した許容人数であって、前記空き情報に示される空き数よりも多い許容人数を記憶する許容人数記憶手段から、前記空き情報記憶手段に記憶された前記施設の空き情報に示される空き数に対する前記許容人数を取得する許容人数取得手段を更に備え、前記第２方法を用いる場合、前記検索手段は、前記許容人数取得手段により取得された許容人数が前記利用人数以上である施設を検索することを特徴とする。

この発明によれば、空き数に対してどれだけ多い人数を許容するかを施設が指定することができる。そのため、施設に合わせた検索を行うことができる。

請求項５に記載の発明は、請求項１乃至３の何れか１項に記載の情報処理装置において、施設を利用した者の人数と、利用された前記設備の利用者単位の空き数であって前記人数よりも少ない空き数と、を含む施設の予約履歴に基づいて、前記基準値を推定する推定手段を更に備え、前記検索手段は、前記利用人数が前記空き情報に示される空き数を上回る度合いが、前記推定手段により推定された基準値以下である施設も、前記利用可能な施設に含めることを特徴とする。

この発明によれば、予約履歴に基づいて、基準値が推定され、推定された基準値に基づいて施設が検索される。そのため、施設やユーザが、許容する程度を指定する手間を省くことができる。

請求項６に記載の発明は、請求項１乃至５の何れか１項に記載の情報処理装置において、施設が検索される方法として前記施設が指定した施設指定検索方法であって、前記第１方法と前記第２方法との少なくとも何れか一方を含む施設指定検索方法を取得する施設指定検索方法取得手段を更に備え、前記検索手段は、前記施設指定検索方法取得手段により取得された検索方法が、前記検索手段が用いる検索方法と一致する施設を検索することを特徴とする。

この発明によれば、空き数と人数との関係において、施設の検索が許される検索方法を施設自身が指定することができる。そのため、施設の事情を考慮した検索を行うことができる。

請求項７に記載の発明は、請求項１乃至６の何れか１項に記載の情報処理装置において、前記ユーザが指定したユーザ指定検索方法であって、前記第１方法と前記第２方法との少なくとも何れか一方を含むユーザ指定検索方法を取得するユーザ指定検索方法取得手段を更に備え、前記検索手段は、前記ユーザ指定検索方法取得手段により取得されたユーザ指定検索方法を用いて施設を検索することを特徴とする。

この発明によれば、空き数と人数との関係において、施設の検索方法をユーザが指定することができる。そのため、ユーザの事情を考慮した検索を行うことができる。

請求項８に記載の発明は、請求項２又は請求項３に記載の情報処理装置において、前記特典決定手段は、前記検索手段により施設が検索されたときに前記ユーザに付与される特典の価値を決定し、前記特典決定手段により決定された価値を提示させる第１価値提示制御手段と、前記ユーザの位置を取得する位置取得手段と、前記位置取得手段により取得された位置に基づいて、前記ユーザが前記検索手段により検索された施設から遠ざかったと判定された場合、前記特典決定手段により決定された特典の価値を上げる価値制御手段と、前記価値制御手段により上げられた特典の価値を提示させる第２価値提示制御手段と、を更に備えることを特徴とする。

この発明によれば、施設が検索された場合、特典の価値が決定され、決定された価値が提示される。その後、検索された施設からユーザが遠ざかると、一度決定された特典の価値が上昇し、上昇後の価値が提示される。そのため、検索された施設をユーザが利用しないと考えてユーザが施設から遠ざかった場合に特典の価値が上昇するので、施設を利用すると考え直すことをユーザに促すことができる。

請求項９に記載の発明は、コンピュータにより実行される情報処理方法であって、ユーザが指定した利用人数を取得する利用人数取得ステップと、施設の利用者により埋まる設備の利用者単位の空き数を示す空き情報を記憶する空き情報記憶手段に記憶された前記空き情報に基づいて、前記利用人数取得ステップにより取得された利用人数で利用可能な施設を検索する検索ステップであり、前記利用人数が前記空き情報に示される空き数を上回る度合いが基準値以下である施設も、前記利用可能な施設に含める検索ステップと、前記検索ステップにより検索された施設を提示させる提示制御ステップと、を含み、前記検索ステップにおいて、施設の利用者により埋まる設備の利用者単位の空き数が前記利用人数以上である施設を検索する第１方法と、施設の利用者により埋まる設備の利用者単位の空き数が前記利用人数より少なく且つ前記利用人数が前記空き情報に示される空き数を上回る度合いが前記基準値以下である施設を検索する第２方法と、の少なくとも何れかの検索方法を用いて施設を検索することを特徴とする。

請求項１０に記載の発明は、コンピュータを、ユーザが指定した利用人数を取得する利用人数取得手段、施設の利用者により埋まる設備の利用者単位の空き数を示す空き情報を記憶する空き情報記憶手段に記憶された前記空き情報に基づいて、前記利用人数取得手段により取得された利用人数で利用可能な施設を検索する検索手段であり、前記利用人数が前記空き情報に示される空き数を上回る度合いが基準値以下である施設も、前記利用可能な施設に含める検索手段、及び、前記検索手段により検索された施設を提示させる提示制御手段、として機能させ、前記検索手段は、施設の利用者により埋まる設備の利用者単位の空き数が前記利用人数以上である施設を検索する第１方法と、施設の利用者により埋まる設備の利用者単位の空き数が前記利用人数より少なく且つ前記利用人数が前記空き情報に示される空き数を上回る度合いが前記基準値以下である施設を検索する第２方法と、の少なくとも何れかの検索方法を用いて施設を検索することを特徴とする。

本発明によれば、設備の利用者単位の空き数が利用人数よりも少なくても、利用人数が空き数を上回る度合いが基準値以下である施設が、利用可能な施設に含まれて検索される。そのため、ユーザが指定した人数で実際には利用可能な施設であってもユーザが指定した人数と設備の利用者単位の空き数との関係により従来では提示されなかった施設を提示させることができる。

一実施形態に係る情報処理システムＳの概要構成の一例を示す図である。 （ａ）乃至（ｃ）は、テーブルＴ及びテーブルＴの周囲の状況の例を示す図である。 一実施形態に係る飲食店検索サーバ１の概要構成の一例を示すブロック図である。 （ａ）は、会員情報ＤＢ１２ａに登録される内容の一例を示す図であり、（ｂ）は、飲食店情報ＤＢ１２ｂに登録される内容の一例を示す図であり、（ｃ）は、座席情報に設定される内容の一例を示す図であり、（ｄ）は、空席情報ＤＢ１２ｃに登録される内容の一例を示す図であり、（ｅ）は、予約情報ＤＢ１２ｄに登録される内容の一例を示す図である。 一実施形態に係る飲食店検索サーバ１の機能ブロックの一例を示す図である。 一実施形態に係る情報処理システムＳの処理概要を示すシーケンス図である。 （ａ）は、トップページの表示例を示す図であり、（ｂ）は、検索方法選択リストボックス１０４の表示例を示す図である。 （ａ）及び（ｂ）は、検索結果ページの表示例を示す図である。 予約完了ページの表示例を示す図である。 一実施形態に係る飲食店検索サーバ１のシステム制御部１４の検索処理の一例を示すフローチャートである。 本発明に係る飲食店検索サーバ１のシステム制御部１４のポイント計算処理の一例を示すフローチャートである。 トップページの表示例を示す図である。 一実施形態に係る飲食店検索サーバ１のシステム制御部１４の検索処理の一例を示すフローチャートである。 （ａ）は、一実施形態に係る飲食店検索サーバ１の概要構成の一例を示すブロック図であり、（ｂ）は、許容人数ＤＢ１２ｅに登録される内容の一例を示す図である。 一実施形態に係る飲食店検索サーバ１の機能ブロックの一例を示す図である。 一実施形態に係る飲食店検索サーバ１の許容人数推定処理の一例を示すフローチャートである。 一実施形態に係る飲食店検索サーバ１のシステム制御部１４の検索処理の一例を示すフローチャートである。 ユーザの移動によって獲得予定ポイント数が増加する様子を示す図である。 一実施形態に係る飲食店検索サーバ１のシステム制御部１４の飲食店情報送信処理の一例を示すフローチャートである。 一実施形態に係る飲食店検索サーバ１のシステム制御部１４のポイント制御処理の一例を示すフローチャートである。

以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下に説明する実施の形態は、情報処理システムに対して本発明を適用した場合の実施形態である。

［１．第１実施形態］
［１−１．情報処理システムの構成及び機能概要］
先ず、本実施形態に係る情報処理システムＳの構成について、図１を用いて説明する。図１は、本実施形態に係る情報処理システムＳの概要構成の一例を示す図である。

図１に示すように、情報処理システムＳは、飲食店検索サーバ１と、複数の飲食店端末２と、複数のユーザ端末３と、を含んで構成されている。そして、飲食店検索サーバ１と、各飲食店端末２及び各ユーザ端末３とは、ネットワークＮＷを介して、例えば、通信プロトコルにＴＣＰ／ＩＰ等を用いて相互にデータの送受信が可能になっている。なお、ネットワークＮＷは、例えば、インターネット、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、及びゲートウェイ等により構築されている。

飲食店検索サーバ１は、飲食店を検索するための飲食店検索サイトに関する各種処理を実行するサーバ装置である。飲食店検索サーバ１は、本発明における情報処理装置の一例である。飲食店は、本発明における施設の一例である。ユーザは、飲食店検索サイトを利用することにより、複数の飲食店の中から所望の飲食店を探すことができる。また、ユーザは、飲食店検索サイトで、飲食店の予約を行うことができる。飲食店検索サーバ１は、飲食店端末２やユーザ端末３からのリクエストに応じて、飲食店検索サイトのウェブページを送信する。また、飲食店検索サーバ１は、飲食店の空席情報の登録、飲食店の検索、予約等の処理を行ったりする。

飲食店端末２は、飲食店で料理を提供する料理提供者により利用される端末装置である。料理提供者は、例えば、飲食店のオーナー、従業員等である。料理の提供は、サービスの一例である。飲食店端末２は、料理提供者からの操作に基づいて飲食店検索サーバ１にアクセスすることにより、飲食店検索サーバ１からウェブページを受信して表示する。料理提供者は、飲食店端末２を利用することにより、例えば、飲食店の現在の空席情報を飲食店検索サイトに登録する。飲食店端末２には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。飲食店端末２としては、例えば、パーソナルコンピュータ等が用いられる。

ユーザ端末３は、飲食店検索サイトを利用するユーザの端末装置である。ユーザ端末３は、ユーザからの操作に基づいて飲食店検索サーバ１にアクセスすることにより、飲食店検索サーバ１からウェブページを受信して表示する。ユーザ端末３には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。ユーザ端末３としては、例えば、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistant）、スマートフォン等の携帯情報端末、携帯電話機等が用いられる。

［１−２．空席数と利用人数に基づく飲食店の検索］
次に、飲食店の検索について、図２を用いて説明する。飲食店検索サーバ１は、飲食店の空席数を管理する。具体的に、飲食店検索サーバ１は、飲食店端末２から送信された空席情報を受信し、空席情報を、後述する空席情報ＤＢ１２ｃに登録する。空席情報は、空席数を示す情報である。空席情報は、本発明における空き情報の一例である。また、飲食店検索サーバ１は、飲食店を検索するための検索条件の１つとして、ユーザ端末３から利用人数を受信する。利用人数は、飲食店を利用する人数である。飲食店検索サーバ１は、空席情報が示す空席数と利用人数とに基づいて、利用可能な飲食店を検索する。利用可能な飲食店とは、例えば、検索条件として指定された利用人数分の人が座ることができる程度の空席がある飲食店である。一般的な考え方では、空席数が利用人数以上である飲食店のみが、利用可能な飲食店である。しかしながら、飲食店検索サーバ１は、空席数が利用人数よりも少なくても利用可能な飲食店を検索する。

図２（ａ）乃至（ｃ）は、ある飲食店に配置されたテーブルＴ及びテーブルＴの周囲の状況の例を示す図である。テーブル及びテーブルの周囲に設けられた座席は、飲食店で料理の提供を受けるために顧客が使う場所の一例である。このような場所は、例えば、カウンターや個室等であってもよい。図２（ａ）に示すように、ある飲食店に、あるテーブルＴが配置されている。テーブルＴの周囲には、椅子Ｃ１及びＣ２と、ソファＦが配置されている。椅子Ｃ１及びＣ２は、それぞれ１人掛けの椅子である。ソファＦは、２人がけの椅子である。従って、テーブルＴの座席数は４である。そのため、通常は、４人までの顧客が座ることができると決められている。図２（ａ）の例では、顧客Ｐ１〜Ｐ４が座っている。この場合、テーブルＴの定員は４人である。定員は、例えば、飲食店の料理提供者が決めた人数であって、座ることができる顧客の最大人数の目安である。また、定員は、例えば、テーブル又はテーブルの種類ごとに決められる。テーブルＴが空いている場合、空席数は４である。空席数の計算には空き数が用いられる。椅子Ｃ１が空いている場合、椅子Ｃ１の利用者単位の空き数は１である。ソファＦが空いている場合、ソファＦの利用者単位の空き数は２である。椅子の利用者単位の空き数が空席数である。椅子は、本発明において施設の利用者が埋める設備の一例である。

図２（ｂ）が図２（ａ）と異なる点は、ソファＦに３人の顧客Ｐ３〜Ｐ５が座っていることである。つまり、２人分の席に３人が座っている。従って、４人の定員に対して５人が座っている。ソファＦに座っている顧客Ｐ３〜Ｐ５は窮屈な思いをするかもしれないが、顧客Ｐ１〜Ｐ５は飲食店を利用することができる。

図２（ｃ）が図２（ａ）と異なる点は、椅子Ｃ３及びＣ４が配置されていることである。椅子Ｃ１及びＣ２は、それぞれ１人掛けの椅子である。例えば、顧客Ｐ１の要請に応じて、料理提供者が臨時に椅子Ｃ３及びＣ４を配置したのである。この場合、座席数が一時的に６に増加する。そのため、６人の顧客Ｐ１〜Ｐ６が座ることができる。この場合であっても、定員は４人である。座席と座席との間が狭くなるので、顧客Ｐ１〜Ｐ６は窮屈な思いをするかもしれない。しかしながら、顧客Ｐ１〜Ｐ６は飲食店を利用することができる。

図２（ｂ）の例と図２（ｃ）の例とを組み合わせて、７人の顧客が座ることもできる。図２（ｂ）や図２（ｃ）に示すような座り方を許容するか否かは、飲食店によって異なっていたり、テーブルによって異なっていたりする。また、図２（ｂ）や図２（ｃ）に示すような座り方を許容するか否かは、ユーザによって異なる場合がある。また、座席数に対してどれだけ多くの顧客の利用を許容するかは、飲食店によって異なる場合がある。利用人数に対してどれだけ少ない座席数を許容するかは、ユーザによって異なる場合がある。飲食店検索サーバ１は、図２（ｂ）や図２（ｃ）に示すような座り方が許容されるために、空席数が利用人数よりも少なくてもテーブルの使用が許容される飲食店を検索する。テーブルの使用を許容する態様として、料理提供者が許容する場合と、ユーザが許容する場合とがある。

飲食店検索サーバ１は、利用人数が空席数を上回る度合いが基準値以下である飲食店を、利用可能な飲食店に含めて、検索を行う。基準値以下であれば、テーブルの使用が許容される。本実施形態では、飲食店の料理提供者が飲食店検索サイトに許容人数を登録することができるようになっている。許容人数とは、テーブルの座席数（定員）に対して座ることが許容される最大人数である。許容人数は座席数よりも多い。飲食店検索サーバ１は、空いているテーブルの許容人数が、ユーザが指定した利用人数以上である飲食店を検索する。これにより、ユーザは、利用可能な飲食店を見付けやすくなる。また、飲食店にとって本来であれば料理を提供することができないケースについて、料理を提供する機会が飲食店に与えられる。なお、許容人数に代えて、料理提供者が、例えば、座席数に対する許容人数の比を、倍率として登録したり、許容人数と座席数との差等を登録したりすることができるようになっていてもよい。この場合、倍率や差は、例えば、座席数ごとに登録可能であってもよいし、１つ飲食店で１つの倍率や差を登録可能であってもよい。飲食店検索サーバ１は、例えば、登録された倍率を空席数に掛けて算出される数が利用人数以上である飲食店を検索したり、利用人数から、登録された差を引いて算出される数が空席数以下である飲食店を検索したりしてもよい。許容人数、倍率及び差は、それぞれ本発明における基準値の一例である。

空席数が利用人数以上であるか否かにかかわらず、利用可能な飲食店を検索することを、「柔軟検索」という。空席数が利用人数以上である飲食店のみを検索することを、「厳密検索」という。空席数が利用人数よりも少なく、且つ、利用人数が空席数を上回る度合いが基準値以下である飲食店のみを検索することを、「窮屈検索」という。柔軟検索を行うことは、厳密検索と窮屈検索との両方を行うことと同じである。例えば、ある飲食店において、座席数が６、許容人数が８人であるテーブルがあるとする。このテーブルが空いている場合、空席数は６である。柔軟検索では、利用人数が８人以下である場合に、その飲食店が検索される。厳密検索では、利用人数が６人以下である場合に、その飲食店が検索される。窮屈検索では、利用人数が７人又は８人である場合に、その飲食店が検索される。

あるテーブルの座席のうち一部の座席に、他の顧客が既に座っており、又は、一部の座席について既に予約が入っている場合がある。この場合、残りの座席について、飲食店の料理提供者が空席数を飲食店検索サイトに登録することを許容するか否かは任意である。つまり、相席を許容するか否かは任意である。例えば、飲食店検索サイトにおいて予め定められてもよいし、料理提供者が選択することができるようになっていてもよい。相席を許す場合に、飲食店検索サーバ１は、例えば、座席数に対する許容人数の割合に応じて、許容人数を決定してもよい。例えば、座席数が６、許容人数が９人であるテーブルにおいて、既に２人分の予約が入っているとする。この場合、空席数は４である。座席数に対する許容人数の割合が２分の３であるので、許容人数は６人になる。

飲食店に、空いているテーブルが複数存在する場合がある。このときに、ユーザのグループが複数のテーブルに分かれて座ることを許容しないことを前提として、検索を行うという考え方と、ユーザのグループが複数のテーブルに分かれて座ることを許容することを前提として、検索を行うという考え方とがある。前者の考え方を、分離非許容思考という。後者の考え方を、分離許容思考という。例えば、４人席のテーブルが２つ空いている場合、各テーブルの空席数は４である。各テーブルの許容人数が５人であるとする。これに対し、飲食店全体としての空席数は８である。また、飲食店全体としての許容人数は１０人である。分離非許容思考では、厳密検索の場合、空席数の４と利用人数の６とが比較される。また、窮屈検索では、許容人数の５と利用人数の６とが比較される。そのため、分離非許容思考では、この飲食店は検索されない。分離許容思考では、厳密検索の場合、空席数の８と利用人数の６とが比較される。従って、分離許容思考では、厳密検索又は柔軟検索により、この飲食店が検索される。何れの思考で検索を行うかは、例えば、情報処理システムＳにおいて予め定められていてもよい。あるいは、例えば、ユーザが検索条件を指定するときに、何れの思考で検索を行うかをユーザが指定することができるようになっていてもよい。また、例えば、飲食店検索サーバ１は、互いに隣接する複数のテーブルが空いている場合は、分離許容思考で検索を行い、互いに離れている複数のテーブルが空いている場合は、分離非許容思考で検索を行ってもよい。その理由は、隣接するテーブルであれば、分かれて座ってもよいとユーザが考える場合があるからである。

窮屈検索で検索された飲食店、又は、柔軟検索で検索された飲食店のうち空席数が利用人数よりも少なく且つ利用人数が空席数を上回る度合いが基準値以下である飲食店を、検索条件で指定された利用人数でユーザが利用する意思があることが確認されることを条件として、飲食店検索サーバ１は、ユーザに対して特典を付与すると決定し、付与される特典を決定してもよい。この特典は、例えば、座席数よりも多い人数で窮屈に座ることにより飲食店を利用したユーザに対する謝礼の意味がある。

特典としては、ポイント、飲食店の飲食代の割り引き、電子マネー、金銭、景品等がある。ポイントは、例えば、飲食店検索サイトや他のウェブサイトにおいて、金銭と同等の価値を有するものとして、商品やサービスの購入代金等に充てることができるものである。飲食代の割り引きの場合、例えば、ユーザ端末３の画面に割り引きクーポンが表示される。割り引きクーポンは、例えば、柔軟検索又は窮屈検索で検索された飲食店でのみ使用可能であったり、飲食店検索サイトで予約した飲食店でのみ使用可能であったりしてもよい。また、割り引きクーポンは、例えば、検索条件で指定された人数でユーザのグループが飲食店を利用するときのみその飲食店で使用可能であってもよい。本実施形態においては、特典の一例として、ポイントが付与されるものとする。

飲食店検索サーバ１は、利用人数が多いほど、特典の価値を高く決定してもよい。利用人数が多いほど、飲食店の収益が増加する蓋然性があるからである。このとき、飲食店検索サーバ１は、例えば、利用人数に応じて特典の価値を決定してもよい。あるいは、飲食店検索サーバ１は、利用人数と空席数との差に応じて、特典の価値を決定してもよい。あるいは、飲食店検索サーバ１は、利用人数と空席数との比に応じて、特典の価値を決定してもよい。

また、飲食店検索サーバ１は、ユーザがユーザ端末３を操作して飲食店の検索を要求したときのユーザ端末３の位置から飲食店までの距離が長いほど、特典の価値を高く決定してもよい。ユーザ端末３がＧＰＳ（Global Positioning System）等を利用した現在位置測定機能を備えている場合、飲食店検索サーバ１は、ユーザ端末３から現在位置を取得することができる。ユーザ端末３が現在位置測定機能を備えていない場合、飲食店検索サーバ１は、例えば、ユーザ端末３の位置の代わりに、予め登録されているユーザの住所を用いてもよい。なお、飲食店検索サーバ１は、利用人数や距離にかかわらず、予め定められた特典の価値を付与すると決定してもよい。

飲食店検索サーバ１は、飲食店を利用する意思が確認されるという条件として、ユーザが飲食店検索サイトで飲食店を予約することを条件としてもよい。あるいは、飲食店検索サーバ１は、ユーザのグループが実際に飲食店を利用しに行ったことを条件としてもよい。何れの場合であっても、飲食店を利用する意思を確認することができる。飲食店検索サーバ１は、ユーザが飲食店を予約し且つ利用しに行ったことを条件としてもよい。本実施形態においては、一例として、ユーザが飲食店を予約し且つ利用しに行ったことを条件とする。

ユーザのグループが実際に飲食店を利用しに行ったことを確認する方法は、種々考えられる。例えば、ユーザが、ユーザ端末３を操作して、飲食店の検索結果から、利用する飲食店の飲食店ページを表示させる。飲食店ページは、飲食店の情報が表示されるウェブページである。このとき、飲食店ページには、ユーザが指定した利用人数、空いているテーブルの情報（空席数等）等が表示される。ユーザは、飲食店ページを紙に印刷して、その紙を飲食店の料理提供者に見せる。あるいは、ユーザ端末３がスマートフォンや携帯電話機等の携帯機器である場合、ユーザは、飲食店ページを携帯機器の画面に表示させた状態で、携帯機器の画面を料理提供者に見せる。料理提供者は、例えば、飲食店ページに表示された利用員数と実際に飲食店に来たユーザのグループの人数が一致し、且つ、飲食店ページに表示された空席数と実際に空いているテーブルの座席数とが一致した場合、特典を付与してもよいと判断する。料理提供者はその場でユーザに特典を付与してもよい。例えば、料理提供者は、飲食代を割り引いたり景品を付与したりする。特典を付与するために飲食店検索サーバ１の処理が必要な場合、例えば、料理提供者は、来店したユーザに関する来店情報を飲食店端末２に入力する。来店情報は、例えば、ユーザを識別する情報、飲食店を識別する情報等の情報を含んでいてもよい。飲食店検索サーバ１は、来店情報に基づいて、例えば、ユーザに対してポイント等の特典を付与するための処理を行う。あるいは、来店情報を表す一次元コードや二次元コード等が飲食店ページに表示されてもよい。料理提供者は、コード読み取り装置を使用して飲食店ページから来店情報を読み込む。または、飲食店検索サイトにユーザのクレジットカードが登録されている場合、ユーザは、クレジットカードを飲食代の支払いに利用してもよい。料理提供者は、カード読み取り装置等を使用して、クレジットカードの情報をユーザの識別情報として入力する。飲食店端末２は、クレジットカードの情報を含む来店情報を飲食店検索サーバ１へ送信する。または、ユーザ端末３がＧＰＳなどにより現在位置を取得することができる場合、ユーザ端末３は、定期的に現在位置を飲食店検索サーバ１へ送信してもよい。飲食店検索サーバ１は、ユーザ端末３の位置が飲食店の位置と重なった場合、ユーザのグループが実際に飲食店を利用しに行ったと判断してもよい。

なお、空席数が利用人数以上である飲食店をユーザが予約し又は利用した場合に、ユーザに対して特典が付与されるようにするか否かは任意である。特典が付与される場合、飲食店検索サーバ１は、例えば、空席数が利用人数以上である飲食店に対する特典の価値を、空席数が利用人数よりも少なく且つ利用人数が空き数を上回る度合いが基準値以下である飲食店に対する特典の価値よりも低くすると良い。

［１−３．飲食店検索サーバの構成］
次に、飲食店検索サーバ１の構成について、図３乃至図５を用いて説明する。

図３は、本実施形態に係る飲食店検索サーバ１の概要構成の一例を示すブロック図である。図３に示すように、飲食店検索サーバ１は、通信部１１と、記憶部１２と、入出力インターフェース１３と、システム制御部１４と、を備えている。そして、システム制御部１４と入出力インターフェース１３とは、システムバス１５を介して接続されている。

通信部１１は、ネットワークＮＷに接続してユーザ端末３等との通信状態を制御するようになっている。

記憶部１２は、例えば、ハードディスクドライブ等により構成されている。記憶部１２は、空き情報記憶手段及び許容人数記憶手段の一例である。この記憶部１２には、会員情報ＤＢ１２ａ、飲食店情報ＤＢ１２ｂ、空席情報ＤＢ１２ｃ、予約情報ＤＢ１２ｄ等のデータベースが構築されている。「ＤＢ」は、データベースの略語である。

図４（ａ）は、会員情報ＤＢ１２ａに登録される内容の一例を示す図である。会員情報ＤＢ１２ａには、飲食店検索サイトを利用するユーザに関するユーザ情報が登録される。具体的に、会員情報ＤＢ１２ａには、ユーザＩＤ、パスワード、ニックネーム、氏名、生年月日、性別、郵便番号、住所、電話番号、電子メールアドレス、クレジットカード情報、保有ポイント数等のユーザの属性が、ユーザごとに対応付けて登録される。ユーザＩＤは、ユーザの識別情報である。保有ポイント数は、ユーザが保有しているポイントの数である。

図４（ｂ）は、飲食店情報ＤＢ１２ｂに登録される内容の一例を示す図である。飲食店情報ＤＢ１２ｂには、飲食店に関する飲食店情報が登録されている。飲食店情報は、飲食店の料理提供者により登録される情報である。具体的に、飲食店情報ＤＢ１２ｂには、飲食店ＩＤ、ジャンルＩＤ、飲食店名、郵便番号、住所、電話番号、ＦＡＸ番号、電子メールアドレス、飲食店の説明、座席情報、柔軟検索許可フラグ等が、飲食店ごとに対応付けて登録される。飲食店ＩＤは、飲食店の識別情報である。ジャンルＩＤは、飲食店で提供される料理のジャンルの識別情報である。

図４（ｃ）は、座席情報に設定される内容の一例を示す図である。座席情報は、飲食店の座席に関する情報である。座席情報は、テーブルの種別ごとに登録される。具体的に、座席情報には、テーブル種別ＩＤ、テーブル名、座席数、許容人数等が対応付けて設定される。テーブル種別ＩＤは、テーブルの種別を示す識別情報である。テーブルの種別として、例えば、４人席のテーブル、６人席のテーブル等がある。料理提供者は、テーブルの種別を自由に割り当てることができる。例えば、料理提供者は、同じ座席数のテーブルであっても、異なる種別を割り当ててもよい。また、料理提供者は、テーブルごとに異なる種別を割り当ててもよい。テーブル名として、例えば、「４人席のテーブル」、「６人席のテーブル」等がある。座席数は、テーブル種別ＩＤが示す種別のテーブルの定員である。許容人数は、テーブル種別ＩＤが示す種別のテーブルに対する許容人数である。

柔軟検索許可フラグは、飲食店の料理提供者が、自分の飲食店が検索される条件として選択した検索方法を示す。具体的に、柔軟検索許可フラグは、料理提供者が、自分の飲食店が柔軟検索により検索されることを許可するか否かを示す情報である。柔軟検索許可フラグがＴＲＵＥに設定されている場合、厳密検索、窮屈検索及び柔軟検索の何れの検索も許可される。柔軟検索許可フラグがＦＡＬＳＥに設定されている場合、厳密検索のみが許可される。例えば、飲食店のポリシーや、食材が少ないため座席数を超える予約を受け付けることができない、といった飲食店の事情に応じて、料理提供者は選択を行うことができる。柔軟検索許可フラグの初期値は、ＴＲＵＥであってもＦＡＬＳＥであってもよい。なお、料理提供者が窮屈検索のみでの検索を許可するように設定することが可能であってもよい。また、料理提供者による検索方法の選択は可能ではなくてもよい。例えば、飲食店検索サーバ１は、全ての飲食店を柔軟検索や窮屈検索の対象としてもよい。また、座席情報に、窮屈検索許可フラグが登録されてもよい。窮屈検索許可フラグは、料理提供者が、自分の飲食店が窮屈検索により検索されることを許可するか否かを示す情報である。

図４（ｄ）は、空席情報ＤＢ１２ｃに登録される内容の一例を示す図である。空席情報ＤＢ１２ｃには空席情報が登録されている。空席情報は、本発明における空き情報の一例である。具体的に、飲食店情報ＤＢ１２ｂには、飲食店ＩＤ、テーブル種別ＩＤ、座席数、許容人数、空きテーブル数及び登録日時が対応付けて登録される。料理提供者は、テーブルの種別ごとに空席情報を登録することができる。飲食店ＩＤは、空席情報を登録した飲食店を示す。座席数は、テーブル種別ＩＤが示す種別のテーブルの定員である。許容人数は、テーブル種別ＩＤが示す種別のテーブルに対する許容人数である。空きテーブル数は、テーブル種別ＩＤが示す種別のテーブルのうち空いているテーブルの数である。登録日時は、空席情報が登録された日時である。なお、空席情報に座席数及び許容人数は設定されなくてもよい。空席情報に設定された飲食店ＩＤ及びテーブル種別ＩＤに基づいて、飲食店情報ＤＢ１２ｂに登録されている座席情報から座席数及び許容人数を取得することができるからである。つまり、空席情報に設定されたテーブル種別ＩＤは、空席数を示す情報である。

図４（ｅ）は、予約情報ＤＢ１２ｄに登録される内容の一例を示す図である。予約情報ＤＢ１２ｄには、飲食店の予約内容を示す予約情報が登録される。予約情報は、予約の履歴を示す情報でもある。具体的に、予約情報ＤＢ１２ｄには、予約番号、予約日時、ユーザＩＤ、飲食店ＩＤ、予約人数、予約テーブル種別ＩＤ、予約テーブル数、予約座席数、獲得予定ポイント数等が、予約が受け付けられるごとに対応付けて登録される。予約番号は、予約情報を識別する情報である。予約日時は予約が行われた日時である。ユーザＩＤは、予約したユーザを示す。飲食店ＩＤは、予約された飲食店を示す。予約人数は、予約された利用人数である。予約テーブル種別ＩＤは、予約されたテーブルの種別のテーブルＩＤである。予約テーブル数は、予約されたテーブルの数である。予約座席数は、予約されたテーブルの座席数である。獲得予定ポイント数は、ユーザが飲食店を利用した場合にユーザが獲得するポイントの数である。

次に、記憶部１２に記憶されるその他の情報について説明する。記憶部１２には、ウェブページを表示するためのＨＴＭＬ文書、ＸＭＬ（Extensible Markup Language）文書、画像データ、テキストデータ、電子文書等の各種データが記憶されている。また、記憶部１２には、各種の設定値、閾値、定数等が記憶されている。

また、記憶部１２には、オペレーティングシステム、ＷＷＷ（World Wide Web）サーバプログラム、ＤＢＭＳ（Database Management System）、飲食店検索サイト管理プログラム等の各種プログラムが記憶されている。飲食店検索サイト管理プログラムは、飲食店の検索や予約等に関する各種の処理を実行するためのプログラムである。飲食店検索サイト管理プログラムは、本発明における情報処理プログラムの一例である。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークＮＷを介して取得されるようにしてもよいし、ＤＶＤ（Digital Versatile Disc）等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。また、飲食店検索サイト管理プログラムは、プログラム製品であってもよい。

入出力インターフェース１３は、通信部１１及び記憶部１２とシステム制御部１４との間のインターフェース処理を行うようになっている。

図５は、本実施形態に係る飲食店検索サーバ１の機能ブロックの一例を示す図である。システム制御部１４は、ＣＰＵ１４ａ、ＲＯＭ（Read Only Memory）１４ｂ、ＲＡＭ（Random Access Memory）１４ｃ等により構成されている。そして、システム制御部１４は、ＣＰＵ１４ａが、各種プログラムを読み出し実行することにより、図５に示すように、検索リクエスト取得部１４１、厳密検索部１４２、窮屈検索部１４３、ポイント処理部１４４、検索結果提示部１４５及び予約処理部１４６等として機能する。検索リクエスト取得部１４１は、本発明における利用人数取得手段及びユーザ指定検索方法取得手段の一例である。厳密検索部１４２と窮屈検索部１４３との組み合わせは、本発明における検索手段の一例である。窮屈検索部１４３は、本発明における許容人数取得手段及び施設指定検索方法取得手段の一例である。ポイント処理部１４４は、本発明における特典決定手段の一例である。検索結果提示部１４５は、本発明における提示制御手段の一例である。

検索リクエスト取得部１４１は、ユーザ端末３から送信された検索リクエストを、通信部１１を介して取得する。検索リクエストは、飲食店の検索の要求を示すメッセージである。検索リクエストは、ユーザにより指定された検索条件を含む。検索条件は、利用人数を含む。検索リクエスト取得部１４１は、検索リクエストから検索条件を取得する。

厳密検索部１４２は、検索リクエスト取得部１４１により取得された検索条件に基づいて、厳密検索を行う。具体的に、厳密検索部１４２は、空席数が利用人数以上である飲食店であって、且つ、利用人数以外の検索条件をも満たす飲食店を検索する。

窮屈検索部１４３は、検索リクエスト取得部１４１により取得された検索条件に基づいて、窮屈検索を行う。具体的に、窮屈検索部１４３は、空席数が利用人数よりも少なく、許容人数が利用人数以上であって、且つ、利用人数以外の検索条件をも満たす飲食店を検索する。

ポイント処理部１４４は、窮屈検索部１４３により検索された飲食店をユーザが利用した場合の獲得予定ポイント数を計算する。また、ポイント処理部１４４は、窮屈検索部１４３により検索された飲食店をユーザが利用する意思を示したと判定した場合、獲得予定ポイント数を、ユーザの保有ポイント数に加算する。

検索結果提示部１４５は、厳密検索部１４２及び窮屈検索部１４３の少なくとも何れかにより検索された飲食店を、ユーザ端末３によりユーザへ提示させる。具体的に、検索結果提示部１４５は、検索結果ページを生成する。検索結果ページは、飲食店の検索結果が表示されるウェブページである。このとき、検索結果提示部１４５は、厳密検索部１４２による検索結果と、窮屈検索部１４３による検索結果とが互いに区別可能な態様で表示されるように、検索結果ページを生成する。検索結果提示部１４５は、生成した検索結果ページをユーザ端末３へ送信する。

予約処理部１４６は、飲食店の予約に関する処理を行う。例えば、予約処理部１４６は、ユーザ端末３からのリクエストに基づいて、予約情報を予約情報ＤＢ１２ｄに登録する。また、予約処理部１４６は、予約情報の登録に応じて、空席情報ＤＢ１２ｃに登録されている空席情報を更新する。

［１−４．情報処理システムの動作］
次に、情報処理システムＳの動作について、図６乃至図１１を用いて説明する。

［１−４−１．情報処理システムの全体動作］
図６は、本実施形態に係る情報処理システムＳの処理概要を示すシーケンス図である。例えば、飲食店の料理提供者は、飲食店端末２を操作して、柔軟検索で自分の飲食店が検索されることを許可するか否かを選択する。柔軟検索を許可することが選択された場合、飲食店端末２は、柔軟検索許可設定リクエストを送信する（ステップＳ１）。柔軟検索許可設定リクエストを受信した飲食店検索サーバ１は、対象の飲食店の柔軟検索許可フラグをＴＲＵＥに設定する（ステップＳ２）。一方、料理提供者が柔軟検索を許可しないことが選択された場合、飲食店端末２は、柔軟検索不許可設定リクエストを送信する。この場合、飲食店検索サーバ１は、柔軟検索許可フラグをＦＡＬＳＥに設定する。

料理提供者は、飲食店端末２に対して、例えば、テーブルの種別ごとに、許容人数を入力する。飲食店端末２は、テーブル種別ＩＤと許容人数との組ごとに、空席情報を飲食店検索サーバ１へ送信する（ステップＳ３）。飲食店検索サーバ１は、受信した空席情報に設定された飲食店ＩＤとテーブル種別ＩＤとに対応する座席情報を飲食店情報ＤＢ１２ｂから検索する。そして、飲食店検索サーバ１は、検索された座席情報中に、空席情報に設定された許容人数を登録する（ステップＳ４）。

料理提供者は、随時店内の状況を確認して、飲食店端末２に対して空席情報を登録する。例えば、料理提供者は、空いているテーブルの種別と空きテーブル数とを入力する。あるいは、飲食店端末２の画面にテーブルの種別の一覧が表示されてもよい。そして、料理提供者が一覧の中から種別を選択して空きテーブル数を選択することが可能であってもよい。あるいは、画面に店内のテーブルの配置図が表示されてもよい。そして、料理提供者が配置図から空いているテーブルを選択することにより、飲食店端末２が、空いているテーブルの種別と空きテーブル数とを認識してもよい。飲食店端末２は、飲食店ＩＤ、テーブル種別ＩＤ、空きテーブル数を含む空席情報を飲食店検索サーバ１へ送信する（ステップＳ５）。飲食店検索サーバ１は、受信した空席情報を、空席情報ＤＢ１２ｃに登録する（ステップＳ６）。このとき、飲食店検索サーバ１は、受信した空席情報に設定された飲食店ＩＤ及びテーブル種別ＩＤに対応する座席数及び許容人数を、飲食店情報ＤＢ１２ｂに登録された座席情報から取得する。また、飲食店検索サーバ１は、現在日時を登録日時として取得する。そして、飲食店検索サーバ１は、座席数、許容人数及び登録日時を空席情報中に追加する。飲食店検索サーバ１は、空席情報を登録してから所定時間（例えば、３０分等）が経過した場合、登録した空席情報を削除してもよい。その理由は、古い空席情報は、最新の空席状況を反映していない場合があるからである。

一方、ユーザは、ユーザ端末３を操作して飲食店検索サーバ１にアクセスすると、飲食店検索サーバ１は、飲食店検索サイトのトップページをユーザ端末３へ送信する。ユーザ端末３は、トップページを画面に表示する。

図７（ａ）は、トップページの表示例を示す図である。トップページは、飲食店検索サイトの最上位のウェブページである。図７に示すように、トップページは、条件設定領域１００及び地域選択領域１１０等を含む。条件設定領域１００は、検索条件を設定するための領域である。条件設定領域１００には、キーワード入力欄１０１、ジャンル選択リストボックス１０２、人数入力欄１０３、検索方法選択リストボックス１０４、検索ボタン１０５等が表示される。キーワード入力欄１０１は、キーワードを入力するための領域である。ジャンル選択リストボックス１０２は、飲食店で提供される料理のジャンルを選択するためのリストボックスである。人数入力欄１０３は、利用人数を入力するための領域である。

検索方法選択リストボックス１０４は、検索方法を選択するためのリストボックスである。ユーザが検索方法選択リストボックス１０４を選択すると、図７（ｂ）に示すように、検索方法を示す情報の一覧が表示される。例えば、「人数分の空席があるお店」、「空席数にかかわらず入れるお店」、「人数分の空席はないが入れるお店」が表示される。「人数分の空席があるお店」は、厳密検索で検索を行うことを示す。「空席数にかかわらず入れるお店」は、柔軟検索で検索を行うことを示す。「人数分の空席はないが入れるお店」は、窮屈検索で検索を行うことを示す。例えば、接待で飲食店を利用するため、空席数が利用人数以上でないと困る、友人同士の宴会で飲食店を利用するため、座ることができればよい、といったユーザの事情に基づいて、ユーザは検索方法を選択することができる。

なお、例えば、厳密検索と柔軟検索との中からのみユーザが選択可能であってもよい。また、ユーザによる検索方法の選択は可能ではなくてもよい。例えば、飲食店検索サーバ１は、常に柔軟検索を行ってもよい。または、飲食店検索サーバ１は、例えば、最初に厳密検索で飲食店を検索してもよい。このときに検索された飲食店が予め設定された閾値未満である場合、飲食店検索サーバ１は、例えば、次に柔軟検索で飲食店を検索してもよい。そして、飲食店検索サーバ１は、厳密検索による検索結果と柔軟検索による検索結果とを提示させてもよい。飲食店検索サーバ１の管理者は、閾値を自由に設定してもよい。例えば、閾値は１であってもよいし、２以上であってもよい。または、飲食店検索サーバ１は、例えば、最初に厳密検索で飲食店を検索してもよい。このときに検索された飲食店が予め設定された閾値未満である場合、飲食店検索サーバ１は、例えば、次に窮屈検索で飲食店を検索してもよい。

検索ボタン１０５は、飲食店検索サーバ１に検索を要求するためのボタンである。地域選択領域１１０には、都道府県等の地域の名称の一覧が表示される。ユーザは、検索条件として地域を選択することができる。

ユーザは、検索条件として、例えば、人数入力欄１０３に利用人数を入力し、検索方法選択リストボックス１０４から柔軟検索を選択したとする（ステップＳ７）。また、ユーザは、他の検索条件を必要に応じて指定する。そして、ユーザが検索ボタン１０５を選択すると、ユーザ端末３は、指定された検索条件を含む検索リクエストを飲食店検索サーバ１へ送信する（ステップＳ８）。

検索リクエストを受信した飲食店検索サーバ１は、検索条件に基づいて、利用可能な飲食店を検索する。検索方法として柔軟検索が指定されているため、飲食店検索サーバ１は、柔軟検索を行う。具体的に、飲食店検索サーバ１は、空席情報ＤＢ１２ｃに登録された空席情報に設定された空席数と、検索条件として指定された利用人数とに基づいて、厳密検索を行う。つまり、飲食店検索サーバ１は、空席数が利用人数以上である飲食店を検索する（ステップＳ９）。また、飲食店検索サーバ１は、空席情報ＤＢ１２ｃに登録された空席情報に設定された許容人数と、検索条件として指定された利用人数とに基づいて、窮屈検索を行う。つまり、飲食店検索サーバ１は、空席数が利用人数よりも少なく、且つ、利用人数が空席数を上回る度合いが基準値以下である飲食店を検索する（ステップＳ１０）。また、飲食店検索サーバ１は、検索された飲食店ごとに獲得予定ポイント数を計算する。

次いで、飲食店検索サーバ１は、柔軟検索の検索結果に基づいて、検索結果ページを生成する。そして、飲食店検索サーバ１は、検索結果ページをユーザ端末３へ送信する（ステップＳ１１）。ユーザ端末３は、受信した検索結果ページを画面に表示する（ステップＳ１２）。

図８（ａ）は、検索結果ページの表示例を示す図である。図８（ａ）に示すように、検索結果ページには、厳密検索タブ２００、窮屈検索タブ２５０、厳密検索結果領域２１０等が表示される。厳密検索タブ２００は、厳密検索による検索結果に対応するタブである。窮屈検索タブ２５０は、窮屈検索による検索結果に対応するタブである。初期状態では、厳密検索タブ２００及び窮屈検索タブ２５０のうち、厳密検索タブ２００が選択された状態になっている。厳密検索結果領域２１０には、厳密検索による検索結果が表示される。厳密検索タブ２００が選択されているので、厳密検索結果領域２１０が表示される。厳密検索結果領域２１０には、窮屈検索で検索された飲食店ごとに、検索飲食店情報２２０が表示される。検索飲食店情報２２０は、検索された飲食店の情報である。検索飲食店情報２２０として、例えば、飲食店の画像、飲食店名、予算、飲食店への行き方等の情報が表示される。

図８（ａ）は、ユーザが利用人数として６人を指定した場合の例を示す。従って、空席数が６席以上ある飲食店の検索飲食店情報２２０が表示される。なお、空席数が６席以上ある飲食店は、分離非許容思考と分離許容思考とで意味が異なる。分離非許容思考では、６席以上の座席があるテーブルが少なくとも１つ空いている飲食店を示す。分離許容思考では、例えば、空いている全てのテーブルの座席数（または、空いているテーブルのうち隣接し合うテーブルの座席数）を足し合わせた場合に、座席が６席以上の空いている飲食店を示す。

ユーザが窮屈検索タブ２５０を選択すると、図８（ｂ）に示すように、厳密検索結果領域２１０が消去され、窮屈検索結果領域２６０が表示される。窮屈検索結果領域２６０には、窮屈検索による検索結果が表示される。窮屈検索結果領域２６０には、窮屈検索で検索された飲食店ごとに、検索飲食店情報２７０が表示される。検索飲食店情報２７０は、検索された飲食店の情報である。検索飲食店情報２７０として、例えば、飲食店の画像、飲食店名、予算、飲食店への行き方、空席状況２７１、ポイント情報２７２等が表示される。空席状況２７１は、空いている席の状況が表示される。例えば、空席状況２７１として、「４人席のテーブルが空いています」などの情報が表示される。ポイント情報２７２として、例えば、ユーザが飲食店を予約して利用した場合にユーザにポイントが付与されること、及び獲得予定ポイント数が表示される。

図８（ａ）及び図８（ｂ）に示すように、厳密検索による検索結果と、窮屈検索による検索結果とが互いに区別可能な態様で表示される。ユーザが検索方法選択リストボックス１０４で厳密検索を選択した場合、検索結果ページには、厳密検索タブ２００及び厳密検索結果領域２１０が表示され、窮屈検索タブ２５０は表示されない。ユーザが検索方法選択リストボックス１０４で窮屈検索を選択した場合、検索結果ページには、窮屈検索タブ２５０及び窮屈検索結果領域２６０が表示され、厳密検索タブ２００は表示されない。なお、ユーザが厳密検索を選択したことにより、飲食店検索サーバ１が厳密検索で検索を行った結果、検索された飲食店が予め設定された閾値未満である場合、飲食店検索サーバ１は、柔軟検索や窮屈検索で飲食店を検索してもよい。この場合、検索結果ページには、厳密検索タブ２００及び窮屈検索タブ２５０が表示され、ユーザのタブの操作に応じて、厳密検索結果領域２１０又は窮屈検索結果領域２６０が表示される。

なお、厳密検索による検索結果と、窮屈検索による検索結果とが互いに区別可能な態様は、図８（ａ）及び図８（ｂ）に示した態様に限られない。例えば、飲食店検索サーバ１は、厳密検索結果領域２１０と窮屈検索結果領域２６０とが同時に表示されるように、検索結果ページを生成してもよい。また、飲食店検索サーバ１は、例えば、１つの領域に検索飲食店情報２２０と検索飲食店情報２７０とが混在して表示されるように、検索結果ページを生成してもよい。空席状況２７１の有無により、ユーザは、厳密検索及び窮屈検索の何れの方法で検索された飲食店の情報かを識別することができる。また、飲食店検索サーバ１は、例えば、検索飲食店情報２２０と検索飲食店情報２７０との間で、例えば、領域の背景色、領域の大きさ、文字の色、文字の大きさ、文字のスタイル等の何れかのうち少なくとも１つが異なるように、検索結果ページを生成してもよい。このとき、飲食店検索サーバ１は、検索飲食店情報２２０の表示態様を検索飲食店情報２７０の表示態様よりも視認しやすい表示態様となるように、検索結果ページを生成してもよい。

検索結果ページにおいて、ユーザ何れかの検索飲食店情報２２０及び検索飲食店情報２７０を選択すると、対応する飲食店の飲食店ページがユーザ端末３の画面に表示される。例えば、ユーザは、窮屈検索結果領域２６０から所望の飲食店の検索飲食店情報２７０を選択したとする（ステップＳ１３）。すると、飲食店Ｄの飲食店ページが表示される。飲食店ページにおいて、ユーザが予約の操作を行うと、ユーザ端末３は、予約手続を行うためのウェブページを表示する。そこで、ユーザが必要な情報を入力すると（ステップＳ１４）、ユーザ端末３は、予約リクエストを飲食店検索サーバ１へ送信する（ステップＳ１５）。

予約リクエストを受信した飲食店検索サーバ１は、予約情報を登録する（ステップＳ１６）。具体的に、飲食店検索サーバ１は、空席情報ＤＢ１２ｃにおいて、予約対象の飲食店の空席情報のうち空きテーブル数が１以上である空席情報から、テーブル種別ＩＤ及び座席数を取得する。また、飲食店検索サーバ１は、新しい予約番号を生成する。飲食店検索サーバ１は、予約番号、予約したユーザのユーザＩＤ、予約対象の飲食店の飲食店ＩＤ、検索条件として指定された利用人数（予約人数）、空席情報から取得されたテーブル種別ＩＤ（予約テーブル種別ＩＤ）、座席情報から取得された座席数（予約座席数）、予約対象の飲食店について計算された獲得予定ポイント数等を含む予約情報を生成する。また、飲食店検索サーバ１は、予約対象の飲食店の空席情報を更新する。具体的に、飲食店検索サーバ１は、予約テーブル種別ＩＤに対応する空きテーブル数を減らす。

分離非許容思考と分離許容思考とで、予約情報中に設定される予約テーブル種別ＩＤと予約座席数とが異なる場合がある。分離非許容思考において、空席数が利用人数よりも少なく且つ利用人数が空席数を上回る度合いが基準値以下である飲食店は、例えば、空いているテーブルのうち許容人数が最も多いテーブルの許容人数が利用人数以上である飲食店である。そのため、予約対象の飲食店の空席情報が複数登録されている場合、飲食店検索サーバ１は、複数の空席情報のうち、許容人数が最も多い空席情報を選択する。そして、飲食店検索サーバ１は、選択した空席情報に設定されているテーブル種別ＩＤ及び座席数を、予約テーブル種別ＩＤ及び予約座席数に決定する。また、飲食店検索サーバ１は、予約テーブル数として１を設定する。

分離許容思考において、空席数が利用人数よりも少なく且つ利用人数が空席数を上回る度合いが基準値以下である飲食店は、例えば、空いている全てのテーブルの許容人数の合計値が利用人数以上である飲食店である。そのため、飲食店検索サーバ１は、予約対象の飲食店の空席情報に設定されている座席数と空きテーブル数を掛け合わせて、１つのテーブルの種別に対する空席数の合計値を計算する。予約対象の飲食店の空席情報が１つのみ取得された場合、計算された合計値が飲食店全体の空席数である。一方、予約対象の飲食店の空席情報が複数登録されている場合、飲食店検索サーバ１は、各空席情報の空席数の合計値を足し合わせて、飲食店全体の空席数を計算する。飲食店検索サーバ１は、飲食店全体の空席数を、予約座席数に決定する。また、予約対象の飲食店の空席情報が複数登録されている場合、飲食店検索サーバ１は、各空席情報に設定されたテーブル種別ＩＤ及び空きテーブル数を、それぞれ予約テーブル種別ＩＤ及び予約テーブル数に決定する。つまり、予約情報中に、予約テーブル種別ＩＤと予約テーブル数との組み合わせが複数設定される。

予約が完了すると、飲食店検索サーバ１は、予約完了ページをユーザ端末３へ送信する（ステップＳ１７）。ユーザ端末３は、受信した予約完了ページを画面に表示する。図９は、予約完了ページの表示例を示す図である。図９に示すように、予約完了ページには、例えば、予約が完了した旨のメッセージ、引換券情報３００等が表示される。引換券情報３００は、ユーザが予約した飲食店を利用してポイントを獲得するために必要な情報である。引換券情報３００として、例えば、予約番号、予約日時、予約された飲食店の名称、予約したユーザの氏名、ポイントを獲得するための条件、獲得予定ポイント数、来店情報を表す１次元又は２次元のコードが表示される。来店情報は、例えば、予約番号を含む。ポイントを獲得するための条件として、予約人数と予約座席数とが表示される。

また、飲食店検索サーバ１は、予約対象の飲食店に対して、予約内容を通知する（ステップＳ１８）。通知の内容としては、例えば、予約番号、予約日時、予約したユーザの氏名、ポイントを獲得するための条件等がある。飲食店検索サーバ１は、例えば、予約対象の飲食店宛ての電子メールを送信することにより、予約内容を通知してもよい。

その後、ユーザのグループが、予約した飲食店に来店し、料理提供者に引換券情報３００を見せる。料理提供者は、引換券情報３００を確認する。料理提供者は、ユーザのグループの人数が予約人数と一致すると判断し、且つ、予約座席数分の座席があるテーブルが空いていると確認すると、引換券情報３００のコードから来店情報を入力する。飲食店端末２は、入力された来店情報を飲食店検索サーバ１へ送信する（ステップＳ２０）。

飲食店検索サーバ１は、受信した来店情報に基づいて、来店したユーザに対してポイントを付与する処理を行う（ステップＳ２１）。具体的に、飲食店検索サーバ１は、来店情報から予約番号を取得する。飲食店検索サーバ１は、予約情報ＤＢ１２ｄから予約番号に対応する予約情報を取得する。飲食店検索サーバ１は、予約情報から、ユーザＩＤ及び獲得予定ポイント数を取得する。そして、飲食店検索サーバ１は、会員情報ＤＢ１２ａにおいて、ユーザＩＤに対応する保有ポイント数に、獲得予定ポイント数を加算する。

［１―４−２．飲食店検索サーバの動作］
図１０は、本実施形態に係る飲食店検索サーバ１のシステム制御部１４の検索処理の一例を示すフローチャートである。検索処理は、飲食店検索サーバ１がユーザ端末３から検索リクエストを受信したときに開始される。

図１０に示すように、検索リクエスト取得部１４１は、検索リクエストから検索条件を取得する（ステップＳ３１）。次いで、検索リクエスト取得部１４１は、検索条件として指定された検索方法が窮屈検索であるか否かを判定する（ステップＳ３２）。このとき、検索リクエスト取得部１４１は、検索方法が窮屈検索ではないと判定した場合には（ステップＳ３２：ＮＯ）、ステップＳ３３に進む。この場合、検索方法は、厳密検索又は柔軟検索である。一方、検索リクエスト取得部１４１は、検索方法が窮屈検索であると判定した場合には（ステップＳ３２：ＹＥＳ）、ステップＳ３５に進む。

ステップＳ３３において、厳密検索部１４２は、厳密検索を行う。具体的に、厳密検索部１４２は、飲食店情報ＤＢ１２ｂに登録された飲食店情報に基づいて、利用人数及び検索方法を除く他の検索条件を満たす飲食店を検索する。次いで、厳密検索部１４２は、検索された飲食店の中から、空席数が利用人数以上である飲食店を検索する。分離非許容思考と分離許容思考とで、検索方法が異なる。分離非許容思考の場合、厳密検索部１４２は、他の検索条件を満たす飲食店の空席情報のうち、空きテーブル数が１以上である空席情報を空席情報ＤＢ１２ｃから取得する。厳密検索部１４２は、取得した空席情報に設定された座席数が利用人数以上であるか否かを判定する。同一の飲食店の空席情報が複数取得された場合、厳密検索部１４２は、複数の空席情報にそれぞれ設定されている座席数のうち、例えば、最も多い座席数に基づいて判定を行う。厳密検索部１４２は、座席数が利用人数以上であると判定された飲食店の飲食店ＩＤを、厳密検索の検索結果リストに登録する。分離許容思考の場合、厳密検索部１４２は、他の検索条件を満たす飲食店の空席情報を空席情報ＤＢ１２ｃから取得する。厳密検索部１４２は、空席情報に設定された座席数と空きテーブル数とを掛け合わせて、１つのテーブルの種別に対する空席数の合計値を計算する。同一の飲食店の空席情報が１つのみ取得された場合、計算された合計値が飲食店全体の空席数である。一方、同一の飲食店の空席情報が複数取得された場合、厳密検索部１４２は、各空席情報の空席数の合計値を足し合わせて、飲食店全体の空席数を計算する。厳密検索部１４２は、飲食店全体の空席数が利用人数以上であるか否かを判定する。そして、厳密検索部１４２は、飲食店全体の空席数が利用人数以上であると判定した飲食店の飲食店ＩＤを、厳密検索の検索結果リストに登録する。

ステップＳ３３の後、検索リクエスト取得部１４１は、検索条件として指定された検索方法が厳密検索であるか否かを判定する（ステップＳ３４）。このとき、検索リクエスト取得部１４１は、検索方法が厳密検索であると判定した場合には（ステップＳ３４：ＹＥＳ）、ステップＳ４６に進む。一方、検索リクエスト取得部１４１は、検索方法が厳密検索ではないと判定した場合には（ステップＳ３４：ＹＥＳ）、ステップＳ３５に進む。この場合、検索方法は柔軟検索である。

ステップＳ４６において、厳密検索部１４２は、検索された飲食店の数が閾値未満であるか否かを判定する。このとき、厳密検索部１４２は、検索された飲食店の数が閾値未満であると判定した場合には（ステップＳ４６：ＹＥＳ）、ステップＳ３５に進む。一方、厳密検索部１４２は、検索された飲食店の数が閾値以上であると判定した場合には（ステップＳ４６：ＮＯ）、ステップＳ４５に進む。

ステップＳ３５〜Ｓ４４において、窮屈検索部１４３は、窮屈検索を行う。ステップＳ３５において、窮屈検索部１４３は、飲食店情報ＤＢ１２ｂに登録された飲食店情報に基づいて、利用人数及び検索方法を除く他の検索条件を満たす飲食店を検索する。次いで、窮屈検索部１４３は、他の検索条件を満たす飲食店の中から、柔軟検索を許可する飲食店を検索する。具体的に、窮屈検索部１４３は、柔軟検索許可フラグがＴＲＵＥに設定されている飲食店ＩＤを飲食店情報ＤＢ１２ｂから検索する。次いで、窮屈検索部１４３は、柔軟検索を許可する飲食店のうち１つを選択する（ステップＳ３６）。次いで、窮屈検索部１４３は、選択した飲食店の空席情報であって、空きテーブル数が１以上に設定されている空席情報が空席情報ＤＢ１２ｃに登録されているか否かを判定する（ステップＳ３７）。このとき、窮屈検索部１４３は、空席情報が登録されていると判定した場合には（ステップＳ３７：ＹＥＳ）、ステップＳ３８に進む。一方、窮屈検索部１４３は、空席情報が登録されていないと判定した場合には（ステップＳ３７：ＮＯ）、ステップＳ４３に進む。

ステップＳ３８において、窮屈検索部１４３は、選択した飲食店の空席情報のうち、空きテーブル数が１以上に設定されている空席情報を空席情報ＤＢ１２ｃから取得する。次いで、窮屈検索部１４３は、取得した空席情報に基づいて、空席数が利用人数以上であるか否かを判定する（ステップＳ３９）。判定方法は、ステップＳ３３の場合と同様である。このとき、窮屈検索部１４３は、空席数が利用人数以上であると判定した場合には（ステップＳ３９：ＹＥＳ）、ステップＳ４３に進む。一方、窮屈検索部１４３は、空席数が利用人数未満であると判定した場合には（ステップＳ３９：ＮＯ）、ステップＳ４０に進む。

ステップＳ４０において、窮屈検索部１４３は、取得した空席情報に基づいて、許容人数が利用人数以上であるか否かを判定する。分離非許容思考と分離許容思考とで、判定方法が異なる。分離非許容思考の場合、窮屈検索部１４３は、取得した空席情報に設定された許容人数が利用人数以上であるか否かを判定する。同一の飲食店の空席情報が複数取得された場合、窮屈検索部１４３は、複数の空席情報にそれぞれ設定されている許容人数のうち、例えば、最も多い許容人数に基づいて判定を行う。分離許容思考の場合、窮屈検索部１４３は、空席情報に設定された許容人数と空きテーブル数とを掛け合わせて、１つのテーブルの種別に対する許容人数の合計値を計算する。同一の飲食店の空席情報が１つのみ取得された場合、計算された合計値が飲食店全体の許容人数である。一方、同一の飲食店の空席情報が複数取得された場合、窮屈検索部１４３は、各空席情報の許容人数の合計値を足し合わせて、飲食店全体の許容人数を計算する。窮屈検索部１４３は、飲食店全体の許容人数が利用人数以上であるか否かを判定する。窮屈検索部１４３は、許容人数が利用人数以上であると判定した場合には（ステップＳ４０：ＹＥＳ）、ステップＳ４１に進む。一方、窮屈検索部１４３は、許容人数が利用人数未満であると判定した場合には（ステップＳ４０：ＮＯ）、ステップＳ４３に進む。

ステップＳ４１において、ポイント処理部１４４は、ポイント計算処理を実行する。図１１は、本発明に係る飲食店検索サーバ１のシステム制御部１４のポイント計算処理の一例を示すフローチャートである。図１１に示すように、ポイント処理部１４４は、検索条件として指定された利用人数に応じてポイント数を計算する。例えば、ポイント処理部１４４は、利用人数が多いほど、ポイント数を多くする。そして、ポイント処理部１４４は、計算したポイント数を、獲得予定ポイント数として設定する（ステップＳ６１）。

次いで、ポイント処理部１４４は、ユーザ端末３から、選択された飲食店までの距離を計算する（ステップＳ６２）。例えば、ユーザ端末３が、現在位置測定機能を備えている場合、ユーザ端末３は、例えば、ユーザ端末３の現在位置の位置情報を含む検索リクエストを送信する。位置情報は、例えば、経緯度を示す情報である。ポイント処理部１４４は、選択した飲食店の住所に基づいて、飲食店の位置の位置情報を特定する。そして、ポイント処理部１４４は、ユーザ端末３の位置情報と飲食店の位置情報とに基づいて、距離を計算する。なお、ユーザ端末３が現在位置測定機能を備えていない場合、ポイント処理部１４４は、ユーザの住所を用いてもよい。

ステップＳ６２の後、ポイント処理部１４４は、計算した距離に応じてポイント数を計算する。例えば、ポイント処理部１４４は、距離が長いほど、ポイント数を多くする。そして、ポイント処理部１４４は、計算したポイント数を、獲得予定ポイント数に加算する（ステップＳ６３）。そして、ポイント処理部１４４は、ポイント計算処理を終了させる。

ポイント計算処理が終わると、図１０に示すように、窮屈検索部１４３は、選択した飲食店の飲食店ＩＤ、空席情報に設定されているテーブル種別ＩＤ及び計算された獲得予定ポイント数を、窮屈検索用の検索結果リストに登録する（ステップＳ４２）。登録されるテーブル種別ＩＤは、ステップＳ３９の判定に用いられた許容人数に対応するテーブル種別ＩＤである。次いで、窮屈検索部１４３は、ステップＳ４３に進む。

ステップＳ４３において、窮屈検索部１４３は、柔軟検索を許可する飲食店の中にまだ選択していない飲食店があるか否かを判定する。このとき、窮屈検索部１４３は、まだ選択していない飲食店があると判定した場合には（ステップＳ４３：ＹＥＳ）、ステップＳ４４に進む。ステップＳ４４において、窮屈検索部１４３は、まだ選択していない飲食店のうち１つを選択する。次いで、窮屈検索部１４３は、ステップＳ３７に進む。一方、窮屈検索部１４３は、全ての飲食店を選択したと判定した場合には（ステップＳ４３：ＮＯ）、ステップＳ４５に進む。

ステップＳ４５において、検索結果提示部１４５は、検索結果リストに基づいて、検索結果ページのＨＴＭＬ文書を生成する。具体的に、厳密検索が行われた場合、検索結果提示部１４５は、厳密検索の検索結果リストに登録された飲食店ＩＤに対応する飲食店情報を飲食店ＤＢ１２ｂから取得する。検索結果提示部１４５は、飲食店情報に基づいて、検索飲食店情報２２０を表示するためのデータを生成する。そして、検索結果提示部１４５は、生成したデータを、検索結果ページのＨＴＭＬ文書に追加する。窮屈検索が行われた場合、検索結果提示部１４５は、窮屈検索の検索結果リストに登録された飲食店ＩＤに対応する飲食店情報を飲食店ＤＢ１２ｂから取得する。検索結果提示部１４５は、飲食店情報と、窮屈検索の検索結果リストに登録されたテーブル種別ＩＤ及び獲得予定ポイント数とに基づいて、検索飲食店情報２７０を表示するためのデータを生成する。そして、検索結果提示部１４５は、生成したデータを、検索結果ページのＨＴＭＬ文書に追加する。検索結果提示部１４５は、生成したＨＴＭＬ文書を、検索リクエストの送信元のユーザ端末３へ送信する。そして、検索結果提示部１４５は、検索処理を終了させる。

ユーザ端末３は、受信したＨＴＭＬ文書に基づいて、例えば図８に示すような検索結果ページを画面に表示させる。検索結果提示部１４５は、検索結果ページのＨＴＭＬ文書をユーザ端末３へ送信することにより、検索された飲食店をユーザ端末３によりユーザへ提示させる。

以上説明したように、本実施形態によれば、システム制御部１４が、ユーザが指定した利用人数を取得し、飲食店の利用者により埋まる椅子の利用者単位の空席数を示す空席情報を記憶する記憶部１２に記憶された空席情報に基づいて、取得された利用人数で利用可能な飲食店を検索し、利用人数が空席情報に示される空席数を上回る度合いが基準値以下である飲食店も利用可能な飲食店に含め、検索された飲食店を提示させる。従って、ユーザが指定した人数で実際には利用可能な飲食店であってもユーザが指定した人数と空席数との関係により従来では提示されなかった飲食店を提示させることができる。

また、システム制御部１４が、検索された飲食店のうち、空いているテーブルの座席数が利用人数より少ない飲食店をユーザが利用人数で利用する意思が確認されることを条件としてユーザに付与される特典を決定する。従って、空席数よりも多い人数で飲食店を利用することをユーザに促すことができる。

また、システム制御部１４が、利用人数が多いほど、付与される特典の価値を高くする。従って、空席数よりも多い人数で飲食店を利用することをよりユーザに促すことができる。

また、システム制御部１４が、飲食店が指定した許容人数であって空席数よりも多い許容人数を記憶する記憶部１２から、記憶部１２に記憶された飲食店の空席情報が示す空席数に対する許容人数を取得し、取得された許容人数が利用人数以上である飲食店を検索する。従って、空席数に対してどれだけ多い人数を許容するかを飲食店が指定することができる。そのため、飲食店に合わせた検索を行うことができる。

また、システム制御部１４が、飲食店が検索される方法として飲食店が指定した検索方法であって、厳密検索、窮屈検索及び柔軟検索のうち何れかの方法を、例えば柔軟検索許可設定リクエストや柔軟検索不許可設定リクエスト等として取得し、又は、柔軟検索許可フラグとして取得し、厳密検索、窮屈検索及び柔軟検索のうち何れかの検索方法を用いて飲食店を検索し、飲食店が指定した検索方法が、検索に用いる検索方法と一致する飲食店の中から飲食店を検索する。従って、空席数と人数との関係において、飲食店の検索が許される検索方法を飲食店自身が指定することができる。従って、飲食店の事情を考慮した検索を行うことができる。

また、システム制御部１４が、ユーザが指定した検索方法であって、厳密検索、窮屈検索及び柔軟検索のうち何れかの方法を取得し、取得された検索方法を用いて飲食店を検索する。従って、空席数と人数との関係において、飲食店の検索方法をユーザが指定することができる。従って、ユーザの事情を考慮した検索を行うことができる。

なお、本実施形態においては、テーブル種別ＩＤが用いられていた。しかしながら、テーブル種別ＩＤは必須の情報ではない。分離非許容思考の場合、例えば、テーブルの座席数に対応付けて、許容人数や空席数を登録することができるように飲食店検索サーバ１が構成されればよい。分離許容思考の場合、例えば、飲食店全体の座席数に対応付けて許容人数を登録することができるように飲食店検索サーバ１が構成されればよい。また、空席情報として、飲食店全体の空席数を登録することができるように飲食店検索サーバ１が構成されればよい。

［２．第２実施形態］
第１実施形態においては、飲食店の料理提供者が座席数に対する許容人数を設定することができた。そして、飲食店検索サーバ１は、許容人数が利用人数以上である飲食店を検索した。一方、以下に説明する第２実施形態においては、検索条件の指定時に、ユーザは、許容座席数を指定することができる。許容座席数は、利用人数に対してユーザが許容する座席数の最小値である。許容座席数は利用人数よりも少ない。飲食店検索サーバ１は、空席数が許容座席数数以上である飲食店を検索する。

図１２は、トップページの表示例を示す図である。図１２において、図７と同様の要素については同様の符号が付されている。図１２に示すように、トップページは、条件設定領域１００及び地域選択領域１１０等を含む。条件設定領域１００には、キーワード入力欄１０１、ジャンル選択リストボックス１０２、人数入力欄１０３、座席数入力欄１０６、検索ボタン１０５等が表示される。

座席数入力欄１０６は、許容座席数を入力するための領域である。例えば、ユーザは、人数入力欄１０３に入力された利用人数よりも少ない許容座席数を座席数入力欄１０６に入力することができる。なお、利用人数に対して非現実的な許容座席数の入力ができないようになっていてもよい。例えば、利用人数が１０人であるのに対して許容座席数が２である場合、許容座席数が少なすぎる蓋然性がある。例えば、飲食店検索サーバ１の管理者が、利用人数に対して入力可能な許容座席数の最低値の割合を予め設定してもよい。

ユーザが許容座席数を入力しなかった場合、飲食店検索サーバ１は、検索方法としてユーザが厳密検索を選択したとみなす。ユーザが許容座席数を入力した場合、飲食店検索サーバ１は、検索方法としてユーザが柔軟検索を選択したとみなす。なお、条件設定領域１００に、ジャンル選択リストボックス１０２が表示されてもよい。そして、ユーザがジャンル選択リストボックス１０２から柔軟検索又は窮屈検索を選択した場合にのみ、座席数入力欄１０６に対する入力が可能であってもよい。ユーザが検索ボタン１０５を選択すると、ユーザ端末３は、利用人数及び許容座席数を含む検索条件を設定した検索リクエストを飲食店検索サーバ１へ送信する。検索リクエスト取得部１４１は、利用人数及び許容座席数を含む検索条件を、検索リクエストから取得する。検索リクエスト取得部１４１は、本発明における許容定員取得手段の一例である。

本実施形態においては、飲食店情報ＤＢ１２ｂに登録される座席情報に、許容人数は含まれていなくてもよい。また、空席情報ＤＢ１２ｃに登録される座席情報に、許容人数は含まれていなくてもよい。

図１３は、本実施形態に係る飲食店検索サーバ１のシステム制御部１４の検索処理の一例を示すフローチャートである。図１３において、図１０と同様の要素については同様の符号が付されている。

図１３に示すように、ステップＳ３１及びＳ３３が実行された後、検索リクエスト取得部１４１は、検索条件として許容座席数が指定されたか否かを判定する（ステップＳ８１）。このとき、検索リクエスト取得部１４１は、許容座席数が指定されていないと判定した場合には（ステップＳ８１：ＮＯ）、ステップＳ４５に進む。一方、検索リクエスト取得部１４１は、許容座席数が指定されていると判定した場合には（ステップＳ８１：ＹＥＳ）、ステップＳ３５に進む。第１実施形態の場合と同様に、ステップＳ３５〜Ｓ３９が実行される。ステップＳ３９において、窮屈検索部１４３は、空席数が利用人数未満であると判定した場合には（ステップＳ３９：ＮＯ）、ステップＳ８２に進む。

ステップＳ８２において、窮屈検索部１４３は、取得した空席情報に基づいて、空席数が許容座席数以上であるか否かを判定する。許容人数の代わりに空席情報に設定された座席数が用いられ、利用人数の代わりに許容座席数が用いられる点を除いて、ステップＳ８２における判定方法は、図１０のステップＳ４０における判定方法と同様である。窮屈検索部１４３は、空席数が許容座席数以上であると判定した場合には（ステップＳ８２：ＹＥＳ）、ステップＳ４１に進む。一方、窮屈検索部１４３は、空席数が利用人許容座席数数未満であると判定した場合には（ステップＳ８２：ＮＯ）、ステップＳ４３に進む。第１実施形態の場合と同様に、ステップＳ４１〜Ｓ４５が実行される。

これまで説明した点を除き、第２実施形態は第１実施形態と同様である。以上説明したように、本実施形態によれば、システム制御部１４が、利用人数に対する定員としてユーザが指定した許容定員であって利用人数よりも少ない許容定員を取得し、空席情報が示す定員が、取得された許容定員以上である飲食店を検索する。従って、ユーザのグループの人数に対してどれだけ少ない定員を許容するかをユーザが指定することができる。従って、ユーザに合わせた検索を行うことができる。

［３．第３実施形態］
第１実施形態においては、料理提供者が許容人数を指定し、第２実施形態においては、ユーザが許容定員を指定していた。以下に説明する第３実施形態では、飲食店検索サーバ１が、予約情報ＤＢ１２ｄに登録された予約情報を予約の履歴として用いて、基準値を推定する。

例えば、飲食店検索サーバ１は、座席数ごとに許容人数を推定する。座席数に対して許容人数が推定されることで、テーブルの使用が許容される座席数と人数との関係が推定される。飲食店検索サーバ１は、予約座席数が予約人数よりも少ない予約履歴を用いる。例えば、飲食店検索サーバ１は、ある座席数に対して今までに予約された人数の最大値を、その座席数に対する許容人数であると推定してもよい。また、飲食店検索サーバ１は、例えば、今までに予約された人数の平均値を、その座席数に対する許容人数であると推定してもよい。また、飲食店検索サーバ１は、例えば、今までに予約された人数のうちＮパーセンタイル値を、許容人数であると推定してもよい。飲食店検索サーバ１の管理者は、Ｎの値を自由に決定してもよい。なお、許容人数に代えて、飲食店検索サーバ１は、例えば、座席数に対する許容人数の比を、倍率として推定したり、許容人数と座席数との差を推定したりしてもよい。

飲食店検索サーバ１は、全ての飲食店の予約情報に基づいて、全ての飲食店で共通する許容人数を推定する。その理由は、一つの飲食店の予約情報では、許容人数を推定するための予約情報としては少ないことがあるからである。なお、飲食店検索サーバ１は、飲食店ごとに許容人数を推定してもよい。

許容人数を推定するためには、座席数よりも多い人数で飲食店が予約されている必要がある。そのためには、飲食店検索サーバ１が、空席数が利用人数よりも少ない飲食店を検索して、検索された飲食店の情報を検索結果ページに表示させる必要がある。例えば、ユーザが検索方法として厳密検索を選択したことによって、飲食店検索サーバ１が厳密検索を行った結果、検索された飲食店の数が予め設定された閾値未満である場合、空いているテーブルがある飲食店の中から空席数以外の検索条件を満たす飲食店を検索してもよい。飲食店検索サーバ１の管理者は、閾値を自由に設定してもよい。例えば、閾値は１であってもよいし、２以上であってもよい。飲食店検索サーバ１は、こうして検索された飲食店の情報の１つとして、「４人席のテーブルが空いています」というような空席状況が表示されるように、検索結果ページを生成してもよい。検索された飲食店をユーザが予約することにより、座席数よりも多い人数で飲食店が予約される。なお、本実施形態においては、図７（ａ）が示すトップページと同じウェブページで検索条件を指定することができるようになっていてもよい。

図１４（ａ）は、本実施形態に係る飲食店検索サーバ１の概要構成の一例を示すブロック図である。１４（ａ）において、図３と異なる点は、記憶部１２に許容人数ＤＢ１２ｅが追加されていることである。図１４（ｂ）は、許容人数ＤＢ１２ｅに登録される内容の一例を示す図である。許容人数ＤＢ１２ｅには、推定許容人数が登録される。推定許容人数は、推定された許容人数である。具体的に、許容人数ＤＢ１２ｅには、座席数と推定許容人数とが対応付けて、座席数ごとに登録される。本実施形態においては、飲食店情報ＤＢ１２ｂに登録される座席情報に、許容人数は含まれていなくてもよい。また、空席情報ＤＢ１２ｃに登録される座席情報に、許容人数は含まれていなくてもよい。

図１５は、本実施形態に係る飲食店検索サーバ１の機能ブロックの一例を示す図である。図１５において、図５と異なる点は、許容人数推定部１４７が追加されていることである。許容人数推定部１４７は、本発明における推定手段の一例である。許容人数推定部１４７は、予約情報ＤＢ１２ｄに登録された予約情報に基づいて推定許容人数を推定する。

図１６は、本実施形態に係る飲食店検索サーバ１の許容人数推定処理の一例を示すフローチャートである。許容人数推定処理は、例えば、定期的に実行される。

図１６に示すように、許容人数推定部１４７は、許容人数ＤＢ１２ｅを初期化する（Ｓ１０１）。次いで、許容人数推定部１４７は、予約情報ＤＢ１２ｄから、予約座席数が予約人数よりも少ない予約情報を検索する（ステップＳ１０２）。次いで、許容人数推定部１４７は、検索された予約情報を、予約座席数ごとにグループ分けする（ステップＳ１０３）。次いで、許容人数推定部１４７は、予約情報のグループを１つ選択する（ステップＳ１０４）。

次いで、許容人数推定部１４７は、選択したグループに含まれる予約情報に設定された予約人数に基づいて、選択したグループに対応する予約座席数に対する許容人数を推定する（ステップＳ１０５）。そして、許容人数推定部１４７は、選択したグループに対応する予約座席数を座席数とし、推定した許容人数を推定許容人数とする。次いで、許容人数推定部１４７は、座席数と推定許容人数とを対応付けて、許容人数ＤＢ１２ｅに登録する（ステップＳ１０６）。

次いで、許容人数推定部１４７は、また選択していないグループがあるか否かを判定する（ステップＳ１０７）。このとき、許容人数推定部１４７は、また選択していないグループがあると判定した場合には（ステップＳ１０７：ＹＥＳ）、ステップＳ１０８に進む。ステップＳ１０８において、許容人数推定部１４７は、また選択していないグループのうち１つを選択する。次いで、許容人数推定部１４７は、ステップＳ１０５に進む。一方、許容人数推定部１４７は、全てのグループを選択したと判定した場合には（ステップＳ１０７：ＮＯ）、許容人数推定処理を終了させる。

図１７は、本実施形態に係る飲食店検索サーバ１のシステム制御部１４の検索処理の一例を示すフローチャートである。図１７において、図１０と同様の要素については同様の符号が付されている。

図１７に示すように、第１実施形態の場合と同様に、ステップＳ３１〜Ｓ３９が実行される。ステップＳ３４において、検索リクエスト取得部１４１は、検索方法が厳密検索であると判定した場合には（ステップＳ３４：ＹＥＳ）、ステップＳ１２１に進む。ステップＳ１２１において、厳密検索部１４２は、検索された飲食店の数が閾値未満であるか否かを判定する。このとき、厳密検索部１４２は、検索された飲食店の数が閾値未満であると判定した場合には（ステップＳ１２１：ＹＥＳ）、ステップＳ１２２に進む。一方、厳密検索部１４２は、検索された飲食店の数が閾値以上であると判定した場合には（ステップＳ１２１：ＮＯ）、ステップＳ４５に進む。

ステップＳ１２２において、厳密検索部１４２は、利用人数及び検索方法を除く他の検索条件を満たす飲食店の中から、空きテーブル数が１以上に設定されている空席情報が空席情報ＤＢ１２ｃに登録されている飲食店を検索する。そして、厳密検索部１４２は、検索された飲食店の飲食店ＩＤを、代替検索用の検索結果リストに登録する。次いで、厳密検索部１４２は、ステップＳ４５に進む。この場合、検索結果提示部１４５は、代替検索用の検索結果リストに基づいて、検索結果ページのＨＴＭＬ文書を生成する。

ステップＳ３９において、窮屈検索部１４３は、空席数が利用人数未満であると判定した場合には（ステップＳ３９：ＮＯ）、ステップＳ１２３に進む。ステップＳ１２３において、窮屈検索部１４３は、選択した飲食店の空席数に対応する推定許容人数を、許容人数ＤＢ１２ｅから取得する。このときに、空席数に対応する推定許容人数が許容人数ＤＢ１２ｅに登録されていない場合がある。選択した飲食店の空席数と同じ予約座席数による予約のうち、その予約座席数よりも多い予約人数での予約の実績がない場合である。この場合、窮屈検索部１４３は、許容人数ＤＢ１２ｅに登録されている座席数及び推定許容人数に基づいて、選択した飲食店の空席数に対応する推定許容人数を計算してもよい。例えば、予約座席数が４である予約の実績はあるが、予約座席数が６である予約の実績がなかったとする。そして、座席数が４に対する推定許容人数が６人であるとする。この場合、窮屈検索部１４３は、座席数と推定許容人数との比に基づいて、座席数が６に対する推定許容人数を９人としてもよい。

次いで、窮屈検索部１４３は、取得した推定許容人数が利用人数以上であるか否かを判定する（ステップＳ１２４）。窮屈検索部１４３は、推定許容人数が利用人数以上であると判定した場合には（ステップＳ１２４：ＹＥＳ）、ステップＳ４１に進む。一方、窮屈検索部１４３は、推定許容人数が利用人数未満であると判定した場合には（ステップＳ１２４：ＮＯ）、ステップＳ４３に進む。第１実施形態の場合と同様に、ステップＳ４１〜Ｓ４５が実行される。

なお、飲食店検索サーバ１は、テーブルの使用が許容される座席数と人数との関係を推定するとき、許容人数を推定するのではなく、予約利用人数ごとに許容定員を推定してもよい。人数に対して許容定員が推定されることで、テーブルの使用が許容される座席数と人数との関係が推定される。そして、飲食店検索サーバ１は、空席数が、検索条件として指定された利用人数に対応する許容定員以上である飲食店を検索してもよい。

これまで説明した点を除き、第３実施形態は第１実施形態と同様である。以上説明したように、本実施形態によれば、システム制御部１４が、飲食店を利用した者の予約人数と、予約人数よりも少ない予約座席数と、を含む飲食店の予約履歴に基づいて、基準値を推定し、利用人数が空席数を上回る度合いが、推定された基準値以下である飲食店も、利用可能な飲食店に含める。従って、飲食店やユーザが許容する程度を指定する手間を省くことができる。

［４．第４実施形態］
第１乃至第３実施形態においては、飲食店の検索時に計算された特典の価値（獲得したポイント数）は、その後変化しなかった。以下に説明する第４実施形態においては、飲食店の検索の後、検索された飲食店からユーザが遠ざかると、飲食店検索サーバ１は、特典の価値を高くする。

ユーザが指定した検索条件に基づいて検索された飲食店の情報が検索結果ページに表示されても、検索された飲食店の中にユーザが利用したい飲食店がない場合がある。あるいは、ユーザは検索された飲食店の中に興味がある飲食店はあるが、ユーザが獲得することができるポイント数が少ないために、ユーザは飲食店を利用しなくてもよいと考えるかもしれない。すると、ユーザは、検索された飲食店がある場所とは別の場所に向かって移動する。しかしながら、ユーザは飲食店検索サイトで飲食店を検索したのであるから、ユーザは飲食店に行きたいと考えている蓋然性がある。このときに、ユーザが獲得することができるポイント数が増えれば、ユーザは飲食店を利用しようと考え直すかもしれない。そこで、飲食店の検索の後、ユーザが飲食店から遠ざかった場合、飲食店検索サーバ１は、検索された飲食店を利用しないとユーザが考えていると判断し、又は、検索された飲食店を利用することをユーザが躊躇していると判断する。このときに、飲食店検索サーバ１は、獲得予定ポイント数を増加させる。これにより、ユーザを引き止める効果を期待することができる。つまり、ユーザが飲食店を利用しようと考え直す機会をユーザに与えることができる。また、ユーザが飲食店を利用しようと考え直すことにより、飲食店は、料理を提供する機会を増やすことができる。

ユーザの位置を特定するため、対象となるユーザ端末３は、現在位置測定機能を有する携帯機器である。また、本実施形態においては、ユーザの位置から飲食店との位置までの距離が所定値以下になった場合、飲食店検索サーバ１は、ユーザが実際に飲食店に行ったと判定する。つまり、飲食店検索サーバ１は、ユーザが飲食店を利用する意思を示したと判定する。なお、飲食店検索サーバ１は、例えば、第１実施形態と同様の方法で、ユーザによる飲食店を利用する意思を確認してもよい。

図１８は、ユーザの移動によって獲得予定ポイント数が増加する様子を示す図である。図１８に示すように、ユーザは飲食店検索サイトで飲食店の検索を行い、検索結果の中から、例えば飲食店Ｄを選択したとする。このとき、ユーザ端末３の画面には飲食店Ｄの情報が表示される。飲食店検索サーバ１は、飲食店Ｄの獲得予定ポイント数として、例えば１００ポイントを仮に決定する。従って、ユーザ端末３の画面には、獲得予定ポイント数として１００ポイントが表示される。その後、ユーザが移動することにより、ユーザが飲食店Ｄから遠ざかったとする。このとき、獲得予定ポイント数が、例えば５０ポイント増加する。そして、ユーザ端末３の画面には、獲得予定ポイント数として１５０ポイントが表示される。その後、ユーザが移動することにより、ユーザが飲食店Ｄに近づいたとする。このとき、獲得予定ポイント数は変化しない。その後、ユーザが移動することにより、ユーザが飲食店Ｄから遠ざかったとする。このとき、獲得予定ポイント数が、例えば１００ポイント増加し、ユーザ端末３の画面には、獲得予定ポイント数として２５０ポイントが表示される。その後、ユーザが飲食店Ｄに来店すると、ユーザは２５０ポイントを獲得する。飲食店ごとに、このような獲得予定ポイント数の増加を許可するか否かの設定が可能になっていてもよい。

上述のように、ユーザ端末３は、獲得予定ポイント数が増加したことをユーザに随時通知することができることが望ましい。そこで、ユーザ端末３には、例えば、飲食店検索サイトで飲食店を検索するための専用のアプリケーションがインストールされる。ユーザ端末３が専用のアプリケーションを実行すると、ユーザの操作に応じて、ユーザ端末３は、飲食店検索サーバ１のトップページ、検索結果ページ、飲食店ページ等に表示される情報と同様の情報を画面に表示させることができる。専用のアプリケーションは、例えば、常駐アプリケーションである。専用のアプリケーションは、例えば、飲食店検索サーバ１からダウンロードすることができる。ユーザ端末３は、定期的にユーザ端末３の現在位置を飲食店検索サーバ１へ送信したり、更新された獲得予定ポイント数を飲食店検索サーバ１から受信したりする。そして、ユーザ端末３は、例えば、更新された獲得予定ポイント数を、ポップアップウインドウ等で画面に表示させたり、バイブレーション機能によりユーザ端末３を振動させたりすることにより、ユーザへの通知を行う。検索された飲食店の全てについて、獲得予定ポイント数が増加するたびにユーザ端末３がユーザに通知すると、ユーザは煩わしい。そこで、検索結果が表示される画面の中からユーザが選択した飲食店についてのみ、ユーザ端末３が通知を行うように、アプリケーションがプログラムされてもよい。

なお、ブラウザでも同様のことを行うことは可能である。例えば、検索結果ページからユーザが何れかの飲食店を選択して、飲食店ページを表示させる。飲食店ページには、飲食店の情報とともに、獲得予定ポイント数が表示される。例えば、飲食店ページのＨＴＭＬ文書に記述されたスクリプトに基づいて、ユーザ端末３は、専用のアプリケーションによる処理と同様の処理を行う。ユーザがブラウザを終了させない限りは、ユーザ端末３は、ユーザへの通知を行うことができる。

本実施形態においては、飲食店検索サイトでの飲食店の予約は可能ではなくてもよい。従って、予約情報ＤＢ１２ｄは必要ではない。また、飲食店検索サーバ１は、厳密検索で検索された飲食店をユーザが利用した場合にも、ユーザに特典を付与すると決定してもよい。また、飲食店検索サーバ１が、柔軟検索や窮屈検索を行うことができるような構成にはなっていなくてもよい。

図１９は、本実施形態に係る飲食店検索サーバ１のシステム制御部１４の飲食店情報送信処理の一例を示すフローチャートである。ユーザが飲食店を検索するための検索条件を指定すると、ユーザ端末３は、検索リクエストを飲食店検索サーバ１へ送信する。検索リクエストは、例えば、検索条件、ユーザ端末３を利用するユーザのユーザＩＤ及びユーザ端末３の現在位置を示す位置情報を含む。飲食店検索サーバ１は、検索処理により飲食店を検索し、検索結果を示す情報（または、検索結果ページ）をユーザ端末３へ送信する。また、飲食店検索サーバ１は、検索リクエストに設定されたユーザＩＤと位置情報とを対応付けてＲＡＭ１４ｃに記憶させる。ユーザ端末３は、検索結果を示す情報を画面に表示する。ユーザは、画面の中から何れかの飲食店を選択する。すると、ユーザ端末３は、飲食店情報リクエストを飲食店検索サーバ１へ送信する。飲食店情報リクエストは、例えば、ユーザＩＤ、選択された飲食店の飲食店ＩＤを含む。飲食店情報送信処理は、飲食店検索サーバ１が飲食店情報リクエストを受信したときに開始される。

図１９に示すように、検索結果提示部１４５は、飲食店情報リクエストに設定された飲食店ＩＤが示す飲食店の情報（または、飲食店ページ）をユーザ端末３へ送信する（ステップＳ１４１）。このとき、検索結果提示部１４５は、検索処理において飲食店ＩＤが示す飲食店を検索したときにポイント計算処理において計算した獲得予定ポイント数を、飲食店の情報に含める。検索結果提示部１４５は、飲食店の情報を送信することにより、ユーザ端末３によりユーザへ獲得予定ポイント数を提示させる。次いで、ポイント処理部１４４は、飲食店情報リクエストに設定されたユーザＩＤに対応する位置情報をＲＡＭ１４ｃから取得する（ステップＳ１４２）。次いで、ポイント処理部１４４は、取得した位置情報に基づいて、ユーザ端末３から飲食店ＩＤが示す飲食店までの距離を計算する（ステップＳ１４３）。次いで、ポイント処理部１４４は、飲食店情報リクエストに設定されたユーザＩＤ及び飲食店ＩＤと、獲得予定ポイント数と、計算された距離とを対応付けてＲＡＭ１４ｃに記憶させる（ステップＳ１４４）。そして、ポイント処理部１４４は、飲食店情報送信処理を終了させる。

その後、ユーザ端末３は、位置通知メッセージを定期的に飲食店検索サーバ１へ送信する。位置通知メッセージは、ユーザ端末３を利用するユーザのユーザＩＤ、ユーザが選択した飲食店の飲食店ＩＤ、ユーザ端末３の現在位置を示す位置情報を含む。

図２０は、本実施形態に係る飲食店検索サーバ１のシステム制御部１４のポイント制御処理の一例を示すフローチャートである。ポイント制御処理は、飲食店検索サーバ１が位置通知メッセージを受信するごとに開始される。

図２０に示すように、ポイント処理部１４４は、位置通知メッセージから、ユーザＩＤ、飲食店ＩＤ及び位置情報を取得する（ステップＳ１５１）。次いで、ポイント処理部１４４は、ユーザＩＤ及び飲食店ＩＤに対応する獲得予定ポイント数及び距離をＲＡＭ１４ｃから取得する（ステップＳ１５２）。次いで、ポイント処理部１４４は、取得した位置情報に基づいて、ユーザ端末３から飲食店ＩＤが示す飲食店の位置情報までの距離を計算する（ステップＳ１５３）。次いで、ポイント処理部１４４は、計算した距離が所定値以下であるか否かを判定する（ステップＳ１５４）。このとき、ポイント処理部１４４は、計算した距離が所定値以下であると判定した場合には（ステップＳ１５４：ＹＥＳ）、ステップＳ１６１に進む。一方、ポイント処理部１４４は、計算した距離が所定値より大きいと判定した場合には（ステップＳ１５４：ＮＯ）、ステップＳ１５５に進む。

ステップＳ１５５において、ポイント処理部１４４は、今回計算した距離から、ＲＡＭ１４ｃから取得した距離を減算して、距離差を計算する。次いで、ポイント処理部１４４は、距離差が０よりも大きいか否かを判定する（ステップＳ１５６）。このとき、ポイント処理部１４４は、距離差が０よりも大きいと判定した場合には（ステップＳ１５６：ＹＥＳ）、ステップＳ１５８に進む。一方、ポイント処理部１４４は、距離差が０以下であると判定した場合には（ステップＳ１５６：ＮＯ）、ステップＳ１５７に進む。ステップＳ１５７において、ポイント処理部１４４は、ユーザＩＤ及び飲食店ＩＤに対応してＲＡＭ１４ｃに記憶されている距離を、新しい距離に書き換える。そして、ポイント処理部１４４は、ポイント制御処理を終了させる。

ステップＳ１５８において、ポイント処理部１４４は、増加するポイント数を決定する。例えば、ポイント処理部１４４は、距離差が大きいほどポイント数を高くする。そして、ポイント処理部１４４は、決定したポイント数を、獲得予定ポイント数に加算する。次いで、ポイント処理部１４４は、ユーザＩＤ及び飲食店ＩＤに対応してＲＡＭ１４ｃに記憶されている獲得予定ポイント数及び距離を、新しい獲得予定ポイント数及び距離に書き換える（ステップＳ１５９）。次いで、ポイント処理部１４４は、新しい獲得予定ポイント数を、位置通知リクエストを送信してきたユーザ端末３へ送信する（ステップＳ１６０）。そして、ポイント処理部１４４は、ポイント制御処理を終了させる。獲得予定ポイント数を受信したユーザ端末３は、受信した獲得予定ポイント数を画面に表示させる。ポイント処理部１４４は、獲得予定ポイント数を送信することにより、ユーザ端末３によりユーザへ獲得予定ポイント数を提示させる。

ステップＳ１６１において、ポイント処理部１４４は、ポイントをユーザに付与する。具体的に、ポイント処理部１４４は、会員情報ＤＢ１２ａにおいて、ユーザＩＤに対応する保有ポイント数に、ＲＡＭ１４ｃから取得した獲得予定ポイント数を加算する。そして、ポイント処理部１４４は、ポイント制御処理を終了させる。

これまで説明した点を除き、第４実施形態は第１乃至第３実施形態と同様である。以上説明したように、本実施形態によれば、システム制御部１４が、飲食店が検索されたとき、ユーザに付与される特典の価値を仮に決定し、決定された価値を提示させ、ユーザ端末３から位置情報を取得し、飲食店が検索された後、取得された位置情報に基づいて、ユーザが、検索された飲食店から遠ざかったと判定された場合、仮に決定された特典の価値を上げ、上げられた特典の価値を提示し、検索された飲食店をユーザが利用する意思が確認された場合、ユーザに付与される特典の価値を確定させる。従って、検索された飲食店をユーザが利用しないと考えてユーザが飲食店から遠ざかった場合に特典の価値が上昇するので、飲食店を利用すると考え直すことをユーザに促すことができる。

なお、上記各実施形態においては、本発明の施設が飲食店に適用され、本発明が飲食店の検索に適用されていた。しかしながら、飲食店以外の施設の検索に本発明が適用されてもよい。例えば、ユーザにより埋まる設備がある施設であって、設備の利用者単位の空き数よりも多い人数でその設備を埋めることができる可能性がある施設に、本発明を適用することができる。このような施設としては、例えば、カラオケボックス、ホテル等がある。カラオケボックスの場合、カラオケボックスの利用者が埋める設備は、例えば椅子である。カラオケルームの定員は、例えば、カラオケルームに配置された椅子（ソファ）の種類や数に応じて決まる。ホテルの場合、ホテルの利用者が埋める設備は、例えばベッドや布団である。シングルベッドの利用者単位の空き数は、１である。ダブルベッドの利用者単位の空き数は、２である。１人用の布団の利用者単位の空き数は、１である。客室の定員は、例えば、客室に配置されたベッドの種類や数に応じて決まったり、客室に配備されている布団の数に応じて決まったりする。ホテルでは、例えば、臨時でエキストラベッドや布団が追加されること等により、定員よりも多い人数の顧客が宿泊することができる場合がある。

また、上記各実施形態においては、本発明の情報処理装置が、クライアントサーバシステムにおけるサーバ装置に適用されていた。しかしながら、本発明の情報処理装置が、サーバ装置以外の情報処理装置に適用されてもよい。例えば、本発明の情報処理装置がユーザ端末３等に適用されてもよい。そして、例えば、情報処理装置が備える制御部が本発明における手段として機能することにより、制御部が、ディスプレイ等の表示手段により、本発明に係る検索結果を提示させてもよい。この場合、表示手段は、情報処理装置に備えられていてもよい。または、表示手段は、情報処理装置とは別個の装置であってもよい。

１ 飲食店検索サーバ
２ 飲食店端末
３ ユーザ端末
１１ 通信部
１２ 記憶部
１２ａ 会員情報ＤＢ
１２ｂ 飲食店情報ＤＢ
１２ｃ 空席情報ＤＢ
１２ｄ 予約情報ＤＢ
１２ｅ 許容人数ＤＢ
１３ 入出力インターフェース
１４ システム制御部
１４ａ ＣＰＵ
１４ｂ ＲＯＭ
１４ｃ ＲＡＭ
１５ システムバス
１４１ 検索リクエスト取得部
１４２ 厳密検索部
１４３ 窮屈検索部
１４４ ポイント処理部
１４５ 検索結果提示部
１４６ 予約処理部
１４７ 許容人数推定部
ＮＷ ネットワーク
Ｓ 情報処理システム

Claims (10)

1. ユーザが指定した利用人数を取得する利用人数取得手段と、
   施設の利用者により埋まる設備の利用者単位の空き数を示す空き情報を記憶する空き情報記憶手段に記憶された前記空き情報に基づいて、前記利用人数取得手段により取得された利用人数で利用可能な施設を検索する検索手段であり、前記利用人数が前記空き情報に示される空き数を上回る度合いが基準値以下である施設も、前記利用可能な施設に含める検索手段と、
   前記検索手段により検索された施設を提示させる提示制御手段と、を備え、
   前記検索手段は、施設の利用者により埋まる設備の利用者単位の空き数が前記利用人数以上である施設を検索する第１方法と、施設の利用者により埋まる設備の利用者単位の空き数が前記利用人数より少なく且つ前記利用人数が前記空き情報に示される空き数を上回る度合いが前記基準値以下である施設を検索する第２方法と、の少なくとも何れかの検索方法を用いて施設を検索することを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置において、
   前記検索手段により検索された施設のうち、前記空き情報に示される空き数が前記利用人数取得手段により取得された利用人数より少ない施設を前記ユーザが前記利用人数で利用する意思が確認されることを条件として前記ユーザに付与される特典を決定する特典決定手段を更に備えることを特徴とする情報処理装置。
3. 請求項２に記載の情報処理装置において、
   前記特典決定手段は、前記利用人数が多いほど、付与される特典の価値を高くすることを特徴とする情報処理装置。
4. 請求項１乃至３の何れか１項に記載の情報処理装置において、
   施設が指定した許容人数であって、前記空き情報に示される空き数よりも多い許容人数を記憶する許容人数記憶手段から、前記空き情報記憶手段に記憶された前記施設の空き情報に示される空き数に対する前記許容人数を取得する許容人数取得手段を更に備え、
   前記第２方法を用いる場合、前記検索手段は、前記許容人数取得手段により取得された許容人数が前記利用人数以上である施設を検索することを特徴とする情報処理装置。
5. 請求項１乃至３の何れか１項に記載の情報処理装置において、
   施設を利用した者の人数と、利用された前記設備の利用者単位の空き数であって前記人数よりも少ない空き数と、を含む施設の予約履歴に基づいて、前記基準値を推定する推定手段を更に備え、
   前記検索手段は、前記利用人数が前記空き情報に示される空き数を上回る度合いが、前記推定手段により推定された基準値以下である施設も、前記利用可能な施設に含めることを特徴とする情報処理装置。
6. 請求項１乃至５の何れか１項に記載の情報処理装置において、
   施設が検索される方法として前記施設が指定した施設指定検索方法であって、前記第１方法と前記第２方法との少なくとも何れか一方を含む施設指定検索方法を取得する施設指定検索方法取得手段を更に備え、
   前記検索手段は、前記施設指定検索方法取得手段により取得された検索方法が、前記検索手段が用いる検索方法と一致する施設を検索することを特徴とする情報処理装置。
7. 請求項１乃至６の何れか１項に記載の情報処理装置において、
   前記ユーザが指定したユーザ指定検索方法であって、前記第１方法と前記第２方法との少なくとも何れか一方を含むユーザ指定検索方法を取得するユーザ指定検索方法取得手段を更に備え、
   前記検索手段は、前記ユーザ指定検索方法取得手段により取得されたユーザ指定検索方法を用いて施設を検索することを特徴とする情報処理装置。
8. 請求項２又は請求項３に記載の情報処理装置において、
   前記特典決定手段は、前記検索手段により施設が検索されたときに前記ユーザに付与される特典の価値を決定し、
   前記特典決定手段により決定された価値を提示させる第１価値提示制御手段と、
   前記ユーザの位置を取得する位置取得手段と、
   前記位置取得手段により取得された位置に基づいて、前記ユーザが前記検索手段により検索された施設から遠ざかったと判定された場合、前記特典決定手段により決定された特典の価値を上げる価値制御手段と、
   前記価値制御手段により上げられた特典の価値を提示させる第２価値提示制御手段と、
   を更に備えることを特徴とする情報処理装置。
9. コンピュータにより実行される情報処理方法であって、
   ユーザが指定した利用人数を取得する利用人数取得ステップと、
   施設の利用者により埋まる設備の利用者単位の空き数を示す空き情報を記憶する空き情報記憶手段に記憶された前記空き情報に基づいて、前記利用人数取得ステップにより取得された利用人数で利用可能な施設を検索する検索ステップであり、前記利用人数が前記空き情報に示される空き数を上回る度合いが基準値以下である施設も、前記利用可能な施設に含める検索ステップと、
   前記検索ステップにより検索された施設を提示させる提示制御ステップと、を含み、
   前記検索ステップにおいて、施設の利用者により埋まる設備の利用者単位の空き数が前記利用人数以上である施設を検索する第１方法と、施設の利用者により埋まる設備の利用者単位の空き数が前記利用人数より少なく且つ前記利用人数が前記空き情報に示される空き数を上回る度合いが前記基準値以下である施設を検索する第２方法と、の少なくとも何れかの検索方法を用いて施設を検索することを特徴とする情報処理方法。
10. コンピュータを、
    ユーザが指定した利用人数を取得する利用人数取得手段、
    施設の利用者により埋まる設備の利用者単位の空き数を示す空き情報を記憶する空き情報記憶手段に記憶された前記空き情報に基づいて、前記利用人数取得手段により取得された利用人数で利用可能な施設を検索する検索手段であり、前記利用人数が前記空き情報に示される空き数を上回る度合いが基準値以下である施設も、前記利用可能な施設に含める検索手段、及び、
    前記検索手段により検索された施設を提示させる提示制御手段、として機能させ、
    前記検索手段は、施設の利用者により埋まる設備の利用者単位の空き数が前記利用人数以上である施設を検索する第１方法と、施設の利用者により埋まる設備の利用者単位の空き数が前記利用人数より少なく且つ前記利用人数が前記空き情報に示される空き数を上回る度合いが前記基準値以下である施設を検索する第２方法と、の少なくとも何れかの検索方法を用いて施設を検索することを特徴とする情報処理プログラム。

Images