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

Description

本発明は、ユーザ端末に飲食店等のサービス施設に関するメッセージを送信可能な情報処理装置、情報処理方法及びプログラムに関する。

従来から、飲食店等のサービス施設の利用予約をネットワークを介して受付可能なシステムにおいては、ユーザが利用を所望するサービス施設がユーザの予約条件に合致しない場合には、当該ユーザにその旨を通知している。

例えば、下記特許文献１には、飲食店のＰＯＳレジ端末が、飲食店情報提供サーバから飲食店への予約が要求されたことを通知する情報を受信した場合に、担当者が飲食店のＰＯＳレジ端末上で「断る」を選択すると、飲食店情報提供サーバにその旨が通知され、飲食店情報提供サーバがユーザの電子メールアドレスに予約の断りの電子メールを送信することが記載されている。

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

しかしながら、上記特許文献１に記載の技術では、予約の断りのメールが送信された場合、ユーザは改めて別の飲食店の予約をやり直すことになるが、そのような作業は面倒であることから、別の飲食店の予約も断念することにもなりかねない。

以上のような事情に鑑み、本発明の目的は、ユーザが予約したサービス施設が利用不可となった場合でも、ユーザを他のサービス施設の予約へ誘導することが可能な情報処理装置、情報処理方法及びプログラムを提供することにある。

本発明の一形態に係る情報処理装置は、記憶部と通信部と制御部とを有する。上記記憶部は、複数のサービス施設が所在するエリアに関する情報を含むサービス施設情報を記憶する。上記通信部は、上記サービス施設が有する施設端末及びユーザ端末と通信可能である。上記制御部は、上記ユーザ端末から、日時及び人数に関する情報を含むいずれかのサービス施設への予約要求を受信した場合に、当該予約要求を示す情報を上記施設端末へ送信する。また制御部は、上記施設端末から、上記予約要求を拒否する拒否通知を受信した場合に、上記予約要求に含まれる日時及び人数並びに当該予約を拒否するサービス施設が所在するエリアを検索条件とした上記サービス施設情報の検索結果ページのＵＲＬを示す情報または当該検索結果ページの少なくとも一部を示す情報を掲載したメッセージを、上記ユーザ端末へ送信する。

これにより情報処理装置は、ユーザが予約したサービス施設が利用不可となった場合でも、ユーザを予約時と同じ条件で他のサービス施設の予約に誘導し、システム全体における予約数の減少を防ぐことができる。ここでメッセージは、電子メールでもよいし、ＳＭＳ（Short Message Service）によるメッセージであってもよいし、チャットアプリ等、所定のアプリケーションによるメッセージであってもよい。

上記記憶部は、上記サービス施設毎の上記エリアに関する情報として、広さの異なる複数のエリアに関する情報を記憶してもよい。この場合上記制御部は、上記検索条件のエリアとして、上記予約要求に含まれる人数が少ないほど狭いエリアを選択してもよい。

これにより情報処理装置は、予約人数が少ない場合に他のサービス施設の候補として検索される数が多くなり過ぎ、また予約人数が多い場合に他のサービス施設の候補として検索される数が少なくなり過ぎるのを防ぐことができる。

上記記憶部は、上記エリアに関する情報に加えて、上記施設情報として、上記サービス施設のジャンルに関する情報を記憶してもよい。この場合上記制御部は、上記検索条件のエリアを、上記予約を拒否するサービス施設のジャンルに応じて変更してもよい。

これにより情報処理装置は、予約を拒否するサービス施設と同ジャンルの他のサービス施設の人気度（数）に応じて適切な検索エリアを提供することができる。

上記制御部は、上記検索条件のエリアとして、上記メッセージの送信日時と、上記予約要求に含まれる日時との間の時間が短いほど広いエリアを選択してもよい。

これにより情報処理装置は、現在から利用予定の日時までの残り時間に応じて、候補として適切な数の他のサービス施設が検索されるように検索エリアを調整することができる。

上記制御部は、上記検索条件のエリアを可変して検索した複数の検索結果ページの中から、当該検索結果ページに含まれるサービス施設の数に応じていずれかの検索結果ページを選択してもよい。

これにより情報処理装置は、実際にエリアの広狭を変えて検索してみた結果から、候補として適切な数のサービス施設が含まれている検索結果を選択してユーザに提供することができる。

上記制御部は、上記メッセージに上記検索結果ページの少なくとも一部を示す情報を掲載する場合、上記検索結果ページに含まれる複数のサービス施設情報のうち、上記予約要求に含まれる日時において所定の人数以上の空席数を有するサービス施設に対応するサービス施設情報を優先的に掲載してもよい。

これにより情報処理装置は、メッセージ送信時からユーザによるメッセージの閲覧時までの間に上記検索結果に含まれるサービス施設の空席に減少が生じた場合でも、検索結果に含まれるサービス施設のうち空席数の多いサービス施設に関する情報のメッセージに掲載しておくことで、ユーザが当該サービス施設を予約できなくなる事態を極力防ぐことができる。

本発明の他の形態に係る情報処理方法は、
複数のサービス施設が所在するエリアに関する情報を含むサービス施設情報を記憶し、
上記ユーザ端末から、日時及び人数に関する情報を含むいずれかのサービス施設への予約要求を受信した場合に、当該予約要求を示す情報を、上記サービス施設が有する施設端末へ送信し、
上記施設端末から、上記予約要求を拒否する拒否通知を受信した場合に、上記予約要求に含まれる日時及び人数並びに当該予約を拒否するサービス施設が所在するエリアを検索条件とした上記サービス施設情報の検索結果ページのＵＲＬを示す情報または当該検索結果ページの少なくとも一部を示す情報を掲載したメッセージを、上記ユーザ端末へ送信する、ことを含む。

本発明のまた別の形態に係るプログラムは、情報処理装置に、
複数のサービス施設が所在するエリアに関する情報を含むサービス施設情報を記憶するステップと、
上記ユーザ端末から、日時及び人数に関する情報を含むいずれかのサービス施設への予約要求を受信した場合に、当該予約要求を示す情報を、上記サービス施設が有する施設端末へ送信するステップと、
上記施設端末から、上記予約要求を拒否する拒否通知を受信した場合に、上記予約要求に含まれる日時及び人数並びに当該予約を拒否するサービス施設が所在するエリアを検索条件とした上記サービス施設情報の検索結果ページのＵＲＬを示す情報または当該検索結果ページの少なくとも一部を示す情報を掲載したメッセージを、上記ユーザ端末へ送信するステップと、を実行させる。

以上説明したように、本発明によれば、ユーザが予約したサービス施設が利用不可となった場合でも、ユーザを他のサービス施設の予約へ誘導することができる。しかし、当該効果は本発明を限定するものではない。

本発明の一実施形態に係る飲食店情報提供システムの構成を示した図である。 本発明の一実施形態に係る飲食店情報提供サーバのハードウェア構成を示した図である。 本発明の一実施形態に係る飲食店情報提供サーバが有するデータベースの構成を示した図である。 本発明の一実施形態に係る飲食店情報提供サーバによる、予約要求拒否メッセージ送信処理の流れを示したフローチャートである。 本発明の一実施形態において飲食店情報提供サーバによってユーザ端末に送信され表示されるメッセージの例を示した図である。 本発明の他の実施形態において飲食店情報提供サーバによってユーザ端末に送信され表示されるメッセージの例を示した図である。

以下、図面を参照しながら、本発明の実施形態を説明する。

［システムの構成］
図１は、本実施形態に係る飲食店情報提供システムの構成を示した図である。

同図に示すように、このシステムは、インターネット５０上の飲食店情報提供サーバ１００と、複数のユーザ端末２００と、複数の飲食店端末３００とを含む。

飲食店情報提供サーバ１００は、飲食店に関する情報を掲載したポータルサイトを運営するウェブサーバである。飲食店情報提供サーバ１００は、複数のユーザ端末２００及び複数の飲食店の飲食店端末３００とインターネット５０を介して接続されている。

飲食店情報提供サーバ１００は、上記ポータルサイトにおいて、ユーザ端末２００のユーザ向けに飲食店情報の検索システムを提供する。具体的には、飲食店情報提供サーバ１００は、ユーザ端末２００からの検索要求に基づいて検索条件に合致する飲食店情報を検索し、検索結果を掲載したＷｅｂページを生成してユーザ端末２００へ送信する。また飲食店情報提供サーバ１００は、当該飲食店情報を閲覧したユーザのユーザ端末２００からの、いずれかの飲食店に対する予約受付処理を代行する。

ユーザ端末２００（２００Ａ，２００Ｂ，２００Ｃ...）は、ユーザにより使用される端末であり、例えばスマートフォン、携帯電話、タブレットＰＣ（Personal Computer）、ノートブックＰＣ、デスクトップＰＣ等である。ユーザ端末２００は、飲食店情報提供サーバ１００へアクセスし、上記Ｗｅｂページを受信してブラウザ等により画面に表示する。

ユーザ端末２００は、ユーザの操作に基づいて飲食店の検索条件を決定し、当該検索条件に基づく飲食店検索要求を飲食店情報提供サーバ１００へ送信する。本実施形態では、飲食店の所在エリア（最寄駅）やジャンル、価格帯等、予め設定された検索条件をユーザ端末２００のユーザが選択することで検索要求の送信が可能である。そしてユーザ端末２００は、ユーザの操作に基づいて、上記検索結果として表示されたいずれかの飲食店に対する予約要求を飲食店情報提供サーバ１００へ送信可能である。

また一方で飲食店情報提供サーバ１００は、上記ポータルサイトに掲載される飲食店（加盟店）向けに、飲食店情報の管理画面（Ｗｅｂページ）を提供している。飲食店端末３００のユーザは、当該管理画面を介して、上記検索結果として一般ユーザに提供されるＷｅｂページ上の飲食店情報（コンテンツ）を編集・更新し、当該Ｗｅｂページを上記ポータルサイト上にアップロードすることができる。

飲食店端末３００（３００Ａ，３００Ｂ，３００Ｃ...）は、各飲食店に設置されている端末であり、タブレットＰＣ、ノートブックＰＣ、デスクトップＰＣ等である。飲食店端末３００は、管理者の操作に基づいて、上記飲食店情報の編集・更新等、自身の飲食店情報に関する処理を飲食店情報提供サーバ１００との通信により実行することが可能である。

本実施形態では、飲食店情報提供サーバ１００は、上記ユーザ端末２００へ、飲食店情報の検索要求に応じて飲食店情報を提供可能なほか、飲食店とユーザとの間の、予約等に関するメッセージの送受信を飲食店に代わって実行する。

このメッセージには、飲食店が何らかの理由によりユーザからの予約要求を拒否する場合に送信する予約要求拒否メールも含まれる。飲食店情報提供サーバ１００は、この予約要求拒否メッセージの送信処理において、ユーザが代わりに他の飲食店を予約できるような情報をメッセージに付加する。この予約要求拒否メッセージの送信処理の詳細については後述する。

［飲食店情報提供サーバのハードウェア構成］
図２は、上記飲食店情報提供サーバ１００のハードウェア構成を示した図である。同図に示すように、飲食店情報提供サーバ１００は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、入出力インタフェース１５、及び、これらを互いに接続するバス１４を備える。

ＣＰＵ１１は、必要に応じてＲＡＭ１３等に適宜アクセスし、各種演算処理を行いながら飲食店情報提供サーバ１００の各ブロック全体を統括的に制御する。ＲＯＭ１２は、ＣＰＵ１１に実行させるＯＳ、プログラムや各種パラメータなどのファームウェアが固定的に記憶されている不揮発性のメモリである。ＲＡＭ１３は、ＣＰＵ１１の作業用領域等として用いられ、ＯＳ、実行中の各種アプリケーション、処理中の各種データを一時的に保持する。

入出力インタフェース１５には、表示部１６、操作受付部１７、記憶部１８、通信部１９等が接続される。

表示部１６は、例えばＬＣＤ（Liquid Crystal Display）、ＯＥＬＤ（Organic ElectroLuminescence Display）、ＣＲＴ（Cathode Ray Tube）等を用いた表示デバイスである。

操作受付部１７は、例えばマウス等のポインティングデバイス、キーボード、タッチパネル、その他の入力装置である。操作受付部１７がタッチパネルである場合、そのタッチパネルは表示部１６と一体となり得る。

記憶部１８は、例えばＨＤＤ（Hard Disk Drive）や、フラッシュメモリ（ＳＳＤ；Solid State Drive）、その他の固体メモリ等の不揮発性メモリである。当該記憶部１８には、上記ＯＳや各種アプリケーション、各種データが記憶される。

後述するが、特に本実施形態において、記憶部１８は、後述する予約要求拒否メッセージ送信処理に必要なアプリケーション等のプログラムの他、飲食店情報データベース、ユーザ情報データベース、及びメッセージ情報データベースを有している。

通信部１９は、例えばEthernet用のＮＩＣ（Network Interface Card）や無線ＬＡＮ等の無線通信用の各種モジュールであり、上記ユーザ端末２００との間の通信処理を担う。

なお、図示しないが、ユーザ端末２００及び飲食店端末３００の基本的なハードウェア構成も上記飲食店情報提供サーバ１００のハードウェア構成と略同様である。

［飲食店情報提供サーバのデータベース構成］
図３は、上記飲食店情報提供サーバ１００が有するデータベースの構成を示した図である。

同図に示すように、飲食店情報提供サーバ１００は、記憶部１８に、飲食店情報データベース３１、ユーザ情報データベース３２、メッセージ情報データベース３３を有している。

飲食店情報データベース３１は、飲食店毎に、その飲食店の店名、所在位置（住所または緯度経度）情報、エリア情報、アクセス情報（最寄り駅情報、最寄り駅からの徒歩距離情報）電話番号、その飲食店を識別するＩＤ（店舗ＩＤ）、その飲食店の業態・サービスのカテゴリ情報、その飲食店を紹介する情報（店舗のＰＲ文等の店舗の特徴を示す情報、飲食店が行うイベント情報等）、飲食店に関する（飲食店を紹介する）画像データ、飲食店が提供するメニューに関するメニュー情報、平均予算情報、営業時間、ウェブサイトＵＲＬ等の情報等を記憶している。これらの情報は、各飲食店の飲食店端末３００から、飲食店情報提供サーバ１００が提供する管理画面を介して入力されたものである。また飲食店情報データベース３１には、各飲食店における予約受付状況を示す情報（予約台帳情報）が記憶されていてもよい。

上記メニュー情報は、上記ポータルサイト上の各飲食店のサイトに掲載されるメニューに対応する情報であり、各飲食店が提供可能な複数のメニューのメニュー名を、飲食店毎に記憶している。当該メニュー情報は、例えば前菜／メイン、ランチ／ディナー／コース等のメニューカテゴリ毎に記憶されてもよい。またメニュー情報としては、メニュー名や値段、説明等を示す文字情報の他、当該メニューを撮影した写真等の画像情報も対応付けて記憶される。

上記エリア情報としては、広さ単位の異なる複数のエリアに関する情報が含まれる。広いエリアとしては例えば都道府県や市区町村、狭いエリアとしては例えば駅から数百ｍ以内（例えば、「銀座エリア」）、それらの間の広さのエリアとして、例えば駅から１ｋｍ以内のエリアや、複数の駅周辺エリアがまとまったエリア（例えば、「銀座・新橋・有楽町エリア」）等が挙げられるが、これらに限られない。これにより、同じ飲食店でも、その広さによって複数のエリアに紐付けられていることになる。

上記カテゴリ情報は、例えば和食、中華、イタリアン、フレンチ、焼肉等のメインカテゴリの他、和食における焼き鳥・天ぷら等、イタリアンにおけるパスタ・ピザ等のより詳細なサブカテゴリを含んでいてもよい。

ユーザ情報データベース３２は、ユーザ端末２００を所有する、上記飲食店情報提供サーバ１００が提供する上記ポータルサイトを介した飲食店情報サービスの利用者（会員）であるユーザに関する情報を記憶する。具体的には、ユーザ情報データベース３２は、ユーザＩＤ、パスワード、氏名、メールアドレス（その他のメッセージの宛先となる情報）、電話番号、住所、年齢（層）、性別、誕生日等の情報をユーザ毎に記憶している。

メッセージ情報データベース３３は、上記予約要求拒否メッセージを含む、ユーザ端末２００または飲食店端末３００へ送信される（未送信の）及び送信済みのメッセージ情報を、例えばその宛先や日付、対象飲食店毎に記憶している。

これら各データベースは、後述する飲食店情報提供サーバ１００による予約要求拒否メッセージ送信処理において、必要に応じて相互に参照されて用いられる。

［飲食店情報提供サーバの動作］
次に、以上のように構成された飲食店情報提供サーバ１００の動作について説明する。当該動作は、飲食店情報提供サーバ１００のＣＰＵ１１及び通信部１９等のハードウェアと、記憶部１８に記憶されたソフトウェアとの協働により実行される。以下の説明では、便宜上、ＣＰＵ１１を動作主体とする。

図４は、飲食店情報提供サーバ１００による、予約要求拒否メッセージ送信処理の流れを示したフローチャートである。

同図に示すように、飲食店情報提供サーバ１００のＣＰＵ１１は、まず、ユーザ端末２００から、上記ポータルサイト上の飲食店情報に含まれる飲食店の予約要求を受信したか否かを判断する（ステップ４１）。

当該予約要求は、上記ユーザ端末２００のユーザを識別する情報（ユーザＩＤ、メールアドレス等）の他、少なくとも予約日時及び予約人数に関する情報を含み、また予約コース等の情報が含まれてもよい。

当該予約要求は、上記ポータルサイト上で例えばエリア、日時、人数、ジャンル、予算等の条件で検索された結果の検索結果（飲食店）一覧ページを介して送信されたものであってもよいし、飲食店情報の検索を経ずに（例えば該当飲食店のページに直接アクセスすることで）送信されたものであっても構わない。

上記予約要求を受信したと判断した場合（Ｙｅｓ）、ＣＰＵ１１は、予約ユーザに関する情報の他、上記日時及び人数の情報を特定した上で、上記予約要求を予約対象の飲食店の飲食店端末３００へ送信する（ステップ４２）。

続いてＣＰＵ１１は、いずれかの飲食店端末３００から、上記予約要求を拒否する予約拒否通知を受信したか否かを判断する（ステップ４３）。当該予約拒否通知には、例えば予約要求したユーザを識別する情報（または予約を識別する情報）が含まれる。

上記予約拒否通知を受信したと判断した場合（Ｙｅｓ）、ＣＰＵ１１は、当該予約拒否の対象となった予約要求に含まれる予約人数に応じて、上記予約要求を拒否する飲食店が所在する、広さの異なる複数のエリア（例えば広域エリア・中域エリア・狭域エリア等）の中からいずれかのエリアを検索エリアとして選択する（ステップ４４）。具体的には、ＣＰＵ１１は、人数が少ないほど狭いエリア（多いほど広いエリア）を選択する。エリアの数は２つでもよいし４つ以上であってもよい。

続いてＣＰＵ１１は、上記選択したエリアと、上記予約要求に含まれる予約日時及び予約人数を検索条件として、上記ポータルサイト上で飲食店を検索した場合の検索結果ページのＵＲＬを生成する（ステップ４５）。ＣＰＵ１１は、当該ＵＲＬの生成に際して、検索処理自体は実際には行なわない。

そしてＣＰＵ１１は、上記生成したＵＲＬを含む予約要求拒否メッセージを生成し（ステップ４６）、当該予約要求拒否メッセージを上記予約者であるユーザのユーザ端末２００へ送信する（ステップ４７）。

図５は、飲食店情報提供サーバ１００が生成しユーザ端末２００上で表示される上記予約要求拒否メッセージの例を示した図である。

同図に示すように、予約要求拒否メッセージは、飲食店からのメッセージや、拒否された予約の内容等の情報に加えて、上述の通り、予約日時、予約人数、及び当該飲食店の所在エリアのうち当該人数に対応する広さのエリアを検索条件として飲食店を検索した場合の検索結果ページのＵＲＬ５０を含む。

ここで当該予約要求拒否メッセージは、電子メールでもよいし、ＳＭＳ（Short Message Service）によるメッセージであってもよいし、チャットアプリ等、所定のアプリケーションによるメッセージであってもよい。またＵＲＬ５０の掲載態様も図示されたものに限られない。

［まとめ］
以上説明したように、本実施形態によれば、飲食店情報提供サーバ１００は、ユーザが予約した飲食店が利用不可となった場合でも、ユーザの予約時と同じ条件で検索した飲食店の検索結果のＵＲＬをユーザへ提供することで、ユーザを他の飲食店の予約に誘導し、システム全体における予約数の減少を防ぐことができる。また飲食店情報提供サーバ１００は、予約要求拒否メッセージと共に上記ＵＲＬを提供することで、予約要求拒否とＵＲＬとを別個にユーザへ伝える場合に比べてネットワークの輻輳やメールサーバの負荷の増大を抑えることができる。

さらに飲食店情報提供サーバ１００は、上記ＵＲＬを生成する際に、予約拒否をした飲食店の所在エリアである広さの異なる複数のエリアから、予約人数に応じたエリアを検索エリアとして選択することで、予約人数が少ない場合に他の飲食店の候補として検索される数が多くなり過ぎ、また予約人数が多い場合に他の飲食店の候補として検索される数が少なくなり過ぎるのを防ぐことができる。

［変形例］
本発明は上述の実施形態にのみ限定されるものではなく、本開示の要旨を逸脱しない範囲内において種々変更され得る。

上述の実施形態では、飲食店情報提供サーバ１００は、上記ＵＲＬ５０を生成する際に用いる検索エリアを、広さの異なる複数のエリアから、予約人数に応じて選択していた。しかし、飲食店情報提供サーバ１００は、予約人数に代えてまたは加えて、上記飲食店情報データベース３１に含まれるジャンル情報を用いて、上記ＵＲＬ５０を生成する際に用いる検索エリアを、上記飲食店のジャンルに応じて選択してもよい。例えば飲食店情報提供サーバ１００は、エリア内で人気のある（予約総数が多い）ジャンルほど、または、ポータルサイト上での掲載数が少ないジャンルほど、広いエリアを選択してもよい。これにより飲食店情報提供サーバ１００は、予約を拒否した飲食店のジャンルに応じて、ユーザに代替の予約飲食店としての候補を十分な数だけ提供することができる。

また、飲食店情報提供サーバ１００は、上記予約人数に代えてまたは加えて、上記メッセージの送信日時と、上記予約日時との間の残り時間が短いほど広いエリアを選択してもよい。例えば飲食店情報提供サーバ１００は、当該残り時間が１日〜２日であれば広いエリア、３〜１週間であれば中程度のエリア、１週間以上であれば狭いエリアといったようにエリアを選択してもよい。これにより飲食店情報提供サーバ１００は、現在からユーザが利用予定の日時までの残り時間に応じて、候補として適切な数の他のサービス施設が検索されるように検索エリアを調整することができる。

上記ＵＲＬ５０を生成するための検索エリアの選択（変更）に関する上述の実施形態及び上記変形例の構成は、互いに矛盾しない限り、如何様にも組み合わせることが可能である。例えば、ＵＲＬ５０を生成するための検索エリア（の広狭）が、予約人数、ジャンル、メッセージ送信日時から予約日時までの残り時間の全てに基づいて選択されてもよいし、それらのうちいずれか１つまたは２つに基づいて選択されてもよい。

上述の実施形態において、飲食店情報提供サーバ１００は、上記ＵＲＬ５０を生成するにあたり、上記予約日時、予約人数に加えて、予約を拒否した飲食店が所在するエリア（の広狭）を可変して検索条件として実際に検索した複数の検索結果ページに含まれる飲食店の検索数をそれぞれ確認し、ユーザに提示するのに最適な数を検索数として含む検索結果ページを上記ＵＲＬ５０の生成用に選択してもよい。最適な検索数とは、例えば、１０件、３０件、５０件、１００件等であるが、これらに限られない。

上述の実施形態では、飲食店情報提供サーバ１００は、上記予約拒否メッセージに、予約を拒否した飲食店からの通知情報や、拒否された予約の内容等、予約の拒否に関する情報を掲載した上で、ＵＲＬ５０を掲載していたが、予約の拒否に関する情報とＵＲＬ５０とは別個のメッセージとして異なるタイミングで送信されてもよい。例えば、予約の拒否を通知するメッセージが送信された所定時間経過後（数時間後、数日後等）に上記ＵＲＬ５０を掲載したメッセージが送信されてもよい。

上述の実施形態では、飲食店情報提供サーバ１００は、上記メッセージに、ユーザの予約時と同じ条件で検索した飲食店の検索結果のＵＲＬ５０を掲載していたが、当該ＵＲＬ５０に代えて、当該検索結果ページの少なくとも一部（例えば検索結果から抽出された所定数の飲食店情報）を掲載してもよい。当該掲載される飲食店情報には、各飲食店のメニュー情報ページ、地図情報ページ、予約要求受付ページ等の詳細ページへのハイパーリンクが設定されていてもよい。

図６は当該メッセージの例を示した図である。同図に示すように、メッセージには複数の飲食店情報表示欄６０が含まれる。当該飲食店情報表示欄６０は、上記検索結果ページから抽出されたものであり、例えば飲食店名、紹介テキスト情報、最寄駅情報、席数情報、平均予算情報、代表写真等が含まれる。各飲食店情報表示欄６０には、各飲食店のメニュー情報ページや予約受付ページを含む詳細ページへのハイパーリンクが設定されており、ユーザが飲食店情報表示欄６０をクリックまたはタップすると、上記詳細ページへ遷移する。また、各飲食店情報表示欄６０に、各飲食店への予約要求を送信するための予約要求ボタン６１が設けられていてもよい。

この際、飲食店情報提供サーバ１００は、上記検索結果ページに含まれる複数の飲食店情報のうち、ユーザの予約要求に含まれる日時において所定の人数以上の空席数を有する飲食店に対応する飲食店情報欄を優先的に掲載してもよい。「優先的に掲載」とは、所定の人数以上の空席数を有する飲食店のみを抽出し、それを全てまたは一部掲載する場合の他、当該飲食店をより多く掲載する場合や、メッセージ中のユーザにより閲覧されやすい位置（例えば上部）に掲載する場合等を含む。上記空席数は上記飲食店情報データベース３２の予約台帳情報から取得される。これにより飲食店情報提供サーバ１００は、メッセージ送信時からユーザによるメッセージの閲覧時までの間に上記検索結果に含まれる飲食店の空席に減少が生じた場合でも、検索結果に含まれる飲食店のうち空席数の多い飲食店に関する情報のメッセージに掲載しておくことで、ユーザが当該飲食店を予約できなくなる事態を極力防ぐことができる。

上述の実施形態では、サービス施設として飲食店が例に挙げられたが、サービス施設は飲食店に限られず、例えば、ホテル・旅館等の宿泊施設、テニス、バスケットボール、ゴルフ等の各種スポーツ施設、カラオケ・ボーリング等の娯楽施設、マッサージ・エステ等の施術施設等の様々なサービス施設についても、本発明は同様に適用可能である。

本願の特許請求の範囲に記載された発明のうち、「情報処理方法」と記載された発明は、その各ステップを、ソフトウェアによる情報処理によりコンピュータ等の少なくとも１つの装置が自動的に行うものであり、人間がコンピュータ等の装置を用いて行うものではない。すなわち、当該「情報処理方法」は、コンピュータ・ソフトウェアによる情報処理方法であって、コンピュータという計算道具を人間が操作する方法ではない。

１１…ＣＰＵ
１８…記憶部
１９…通信部
３１…飲食店情報データベース
３２…ユーザ情報データベース
３３…メッセージ情報データベース
５０…ＵＲＬ
６０…飲食店情報表示欄
１００…飲食店情報提供サーバ
２００…ユーザ端末
３００…飲食店端末

Claims (8)

1. 複数のサービス施設が所在するエリアに関する情報を含むサービス施設情報を記憶する記憶部と、
   前記サービス施設が有する施設端末及びユーザ端末と通信可能な通信部と、
   前記ユーザ端末から、日時及び人数に関する情報を含むいずれかのサービス施設への予約要求を受信した場合に、当該予約要求を示す情報を前記施設端末へ送信し、
   前記施設端末から、前記予約要求を拒否する拒否通知を受信した場合に、前記予約要求に含まれる日時及び人数並びに当該予約を拒否するサービス施設が所在するエリアを検索条件として予約可能な前記サービス施設情報を検索した場合のアクセス時の検索結果を示す検索結果ページのＵＲＬを前記記憶部の前記サービス施設情報を参照して生成し、当該ＵＲＬを示す情報を掲載したメッセージを、前記ユーザ端末へ送信する
   制御部と
   を具備する情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記記憶部は、前記サービス施設毎の前記エリアに関する情報として、広さの異なる複数のエリアに関する情報を記憶し、
   前記制御部は、前記検索条件のエリアとして、前記予約要求に含まれる人数が少ないほど狭いエリアを選択する
   情報処理装置。
3. 請求項１または２に記載の情報処理装置であって、
   前記記憶部は、前記施設情報として、前記サービス施設のジャンルに関する情報を記憶し、前記サービス施設毎の前記エリアに関する情報として、広さの異なる複数のエリアに関する情報を記憶し、
   前記制御部は、前記検索条件のエリアを、前記予約を拒否するサービス施設のジャンルに応じて変更する
   情報処理装置。
4. 請求項１乃至３のいずれかに記載の情報処理装置であって、
   前記記憶部は、前記サービス施設毎の前記エリアに関する情報として、広さの異なる複数のエリアに関する情報を記憶し、
   前記制御部は、前記検索条件のエリアとして、前記メッセージの送信日時と、前記予約要求に含まれる日時との間の時間が短いほど広いエリアを選択する
   情報処理装置。
5. 請求項１乃至４のいずれかに記載の情報処理装置であって、
   前記記憶部は、前記サービス施設毎の前記エリアに関する情報として、広さの異なる複数のエリアに関する情報を記憶し、
   前記制御部は、前記検索条件のエリアを可変して検索した複数の検索結果ページの中から、当該検索結果ページに含まれるサービス施設の数に応じていずれかの検索結果ページを選択する
   情報処理装置。
6. 請求項１に記載の情報処理装置であって、
   前記制御部は、前記メッセージに前記検索結果ページの少なくとも一部を示す情報を掲載する場合、前記検索結果ページに含まれる複数のサービス施設情報のうち、前記予約要求に含まれる日時において所定の人数以上の空席数を有するサービス施設に対応するサービス施設情報を優先的に掲載する
   情報処理装置。
7. 複数のサービス施設が所在するエリアに関する情報を含むサービス施設情報を記憶し、
   ユーザ端末から、日時及び人数に関する情報を含むいずれかのサービス施設への予約要求を受信した場合に、当該予約要求を示す情報を、前記サービス施設が有する施設端末へ送信し、
   前記施設端末から、前記予約要求を拒否する拒否通知を受信した場合に、前記予約要求に含まれる日時及び人数並びに当該予約を拒否するサービス施設が所在するエリアを検索条件として予約可能な前記サービス施設情報を検索した場合のアクセス時の検索結果を示す検索結果ページのＵＲＬを前記記憶された前記サービス施設情報を参照して生成し、当該ＵＲＬを示す情報を掲載したメッセージを、前記ユーザ端末へ送信する
   コンピュータが実行する情報処理方法。
8. 情報処理装置に、
   複数のサービス施設が所在するエリアに関する情報を含むサービス施設情報を記憶するステップと、
   ユーザ端末から、日時及び人数に関する情報を含むいずれかのサービス施設への予約要求を受信した場合に、当該予約要求を示す情報を、前記サービス施設が有する施設端末へ送信するステップと、
   前記施設端末から、前記予約要求を拒否する拒否通知を受信した場合に、前記予約要求に含まれる日時及び人数並びに当該予約を拒否するサービス施設が所在するエリアを検索条件として予約可能な前記サービス施設情報を検索した場合のアクセス時の検索結果を示す検索結果ページのＵＲＬを前記記憶された前記サービス施設情報を参照して生成し、当該ＵＲＬを示す情報を掲載したメッセージを、前記ユーザ端末へ送信するステップと
   を実行させるプログラム。

Images