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

Description

本発明の一形態は、ユーザの施設予約を支援する情報処理装置、情報処理方法、及び情報処理プログラムに関する。

インターネットなどのネットワークを介し、新幹線や飛行機等の座席を指定して予約を行うことができるインターネット予約システムが知られている。また、ユーザ端末からの検索要求に応じて施設の空席情報をそのユーザ端末に送信するシステムが知られている。例えば下記特許文献１には、利用者が施設の時限的な空情報を閲覧することによって、容易に空情報のある施設を閲覧し予約することができる空情報提供システムが記載されている。このシステムは、施設端末から空情報を受信した場合には、空情報と空情報の登録時間とを施設データベースに登録し、施設端末から空情報の登録要請のみを受信した場合には、空情報の登録時間と予め定められた空情報とを施設データベースに登録する空情報受付手段と、ユーザ端末から受信した条件に合致する施設に関する情報、空情報、および空情報の登録時間を抽出して送信する空情報提供手段とを備える。

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

しかし、上記の空情報提供システムのような従来の手法では、座席を指定して予約を行うことができるインターネット予約システムとは異なり、施設側が絶えず施設の空き状況を登録または更新する必要があるため、施設にとってはその作業の負担が大きい。そのため、空き状況を管理する施設の負荷を軽減しつつ、ユーザからの施設予約を受け付けることが可能な仕組みが求められている。

本発明の一形態に係る情報処理装置は、施設情報を提供する情報提供手段に対するユーザ端末からの情報提供要求に応じて、該情報提供要求を受け付ける所定時間前からの施設に対するアクセス数を取得する取得部と、施設の収容可能数と該施設へのアクセス数とに基づいて該施設が予約受付可能か否かを推定する推定部と、推定部による推定結果に基づく情報をユーザ端末に出力する送信部とを備える。

本発明の一形態に係る情報処理方法は、施設情報を提供する情報提供手段に対するユーザ端末からの情報提供要求に応じて、該情報提供要求を受け付ける所定時間前からの施設に対するアクセス数を取得する取得ステップと、施設の収容可能数と該施設へのアクセス数とに基づいて該施設が予約受付可能か否かを推定する推定ステップと、推定ステップにおける推定結果に基づく情報をユーザ端末に出力する送信ステップとを含む。

本発明の一形態に係る情報処理プログラムは、施設情報を提供する情報提供手段に対するユーザ端末からの情報提供要求に応じて、該情報提供要求を受け付ける所定時間前からの施設に対するアクセス数を取得する取得部と、施設の収容可能数と該施設へのアクセス数とに基づいて該施設が予約受付可能か否かを推定する推定部と、推定部による推定結果に基づく情報をユーザ端末に出力する送信部とをコンピュータに実行させる。

このような形態によれば、施設の収容可能数とその施設へのアクセス数とから、その施設が予約受付可能か否かが推定され、その推定結果に基づく情報がユーザに提供される。このように、施設へのアクセス数から施設の空き状況を推定することで、個々の施設が自らその空き状況を登録または更新する手間が省かれる。したがって、空き状況を管理する施設の負荷を軽減しつつ、ユーザからの施設予約を受け付けることができる。

別の形態に係る情報処理装置では、取得部が、施設とユーザとの間で成立した予約の人数の集計値を取得し、推定部が、収容可能数と、１より大きい所定の係数が乗じられた集計値とから施設の空席数を求め、空席数が所定の閾値以上である施設を予約受付可能と推定してもよい。

さらに別の形態に係る情報処理装置では、取得部が、施設ページへのアクセス数を収容可能数で割ることでアクセス率を取得し、推定部が、アクセス率が所定の閾値以下である施設を予約受付可能と推定してもよい。

さらに別の形態に係る情報処理装置では、取得部が集計値を取得できる場合には、推定部が空席数を求めて該空席数が所定の閾値以上である施設を予約受付可能と推定し、取得部が集計値を取得できない場合には、取得部が施設ページへのアクセス数を収容可能数で割ることでアクセス率を取得し、推定部が、アクセス率が所定の閾値以下である施設を予約受付可能と推定してもよい。

さらに別の形態に係る情報処理装置では、申込希望者に関するアクセス履歴に基づいて該申込希望者に推定結果に基づく情報を提供すると判定した場合に、取得部および推定部に処理を指示する指示部を更に備えてもよい。

さらに別の形態に係る情報処理装置では、アクセス履歴が、ユーザが施設ページを閲覧した記録である閲覧履歴を含み、指示部が、閲覧履歴に基づいて、申込希望者が所定時間内に複数の施設ページにアクセスしたと判定した場合に、取得部および推定部に処理を指示してもよい。

さらに別の形態に係る情報処理装置は、アクセス履歴が、ユーザと施設との通信の記録である通信履歴を含み、指示部が、通信履歴に基づいて、申込希望者が所定時間内に複数の施設から予約不可通知を受けたと判定した場合に、取得部および推定部に処理を指示してもよい。

さらに別の形態に係る情報処理装置では、通信履歴が、ユーザと施設との電子メールの記録であるメール履歴であり、指示部が、電子メールの内容を解析することで該電子メールが予約不可通知に該当するか否かを判定してもよい。

さらに別の形態に係る情報処理装置では、通信履歴が、ユーザと施設との通話の記録である通話履歴であり、指示部が、通信履歴に基づいて、申込希望者が所定時間内に複数の施設と電話したことを特定した場合に、該申込希望者が該複数の施設から予約不可通知を受けたと判定してもよい。

さらに別の形態に係る情報処理装置では、推定部が、推定処理により得られた予約受付可能な施設の数が所定数以下である場合に、該推定処理よりも条件を緩和して再度推定処理を実行してもよい。

さらに別の形態に係る情報処理装置では、通信履歴が、ユーザと施設との通話の記録である通話履歴であり、指示部が、通信履歴に基づいて、申込希望者が所定時間内に複数の施設と電話したことを特定した場合に、該申込希望者が該複数の施設から予約不可通知を受けたと判定してもよい。

本発明の一側面によれば、空き状況を管理する施設の負荷を軽減しつつ、ユーザからの施設予約を受け付けることができる。

実施形態に係る予約システムの全体構成を示す図である。 飲食店検索サイトのＷｅｂページの例を示す図である。 飲食店検索サイトのＷｅｂページの例を示す図である。 実施形態における空き情報の提示の概念を示す図である。 飲食店情報の例を示す図である。 アクセス履歴（予約履歴）の例を示す図である。 アクセス履歴（閲覧履歴）の例を示す図である。 アクセス履歴（検索履歴）の例を示す図である。 アクセス履歴（メール履歴）の例を示す図である。 アクセス履歴（通話履歴）の例を示す図である。 ユーザ情報の例を示す図である。 実施形態に係る予約サーバのハードウェア構成を示す図である。 実施形態に係る予約サーバの機能構成を示すブロック図である。 実施形態に係る予約システムの動作を示すシーケンス図である。 実施形態に係る情報処理プログラムの構成を示す図である。

以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。なお、図面の説明において同一又は同等の要素には同一の符号を付し、重複する説明を省略する。以下の実施形態では、本発明に係る情報処理装置を予約サーバに適用する。

図１〜１３を用いて、実施形態に係る予約システム１の機能および構成を説明する。予約システム１は施設利用の予約に関する処理を実行するコンピュータ・システムである。例えば、予約システム１はユーザ端末からの要求（情報提供要求）に応じて、検索クエリに合致する施設を提示したり、施設利用の空き状況を提示したり、施設利用の予約を受け付けたりする。ユーザはこの予約システム１を利用することで、希望する施設を探してその施設に予約を入れることができる。予約システム１の特徴は、まだ席が空いていて予約受付が可能な施設をユーザに提示する点にあるので、以下ではこの特徴について特に説明する。

本実施形態では、予約システム１が飲食店の予約を受け付けることを前提とするが、本発明は飲食店以外の施設の予約を管理するシステムにも適用することができる。例えば、競技場、コンサート会場、映画館、劇場、ホテルなどの様々な施設の予約管理に本発明を適用してもよい。

図１に示すように、予約システム１はユーザ端末Ｔ、予約サーバ（情報処理装置）１０、及びデータベース群（記憶部）２０を備えている。ユーザ端末Ｔと予約サーバ１０とはインターネットなどのネットワークを介して接続されている。予約サーバ１０はインターネットや専用線などのネットワークを介してデータベース群２０にアクセスできる。図１では３台のユーザ端末Ｔを示しているが、ユーザ端末Ｔの台数は限定されない。

ユーザ端末Ｔの種類は限定されず、例えば据置型又は携帯型のパーソナルコンピュータでもよいし、高機能携帯電話機（スマートフォン）や携帯電話機、携帯情報端末（ＰＤＡ）などの携帯端末でもよい。

予約システム１における予約管理の概念を図２〜４に示す。予約システム１は飲食店検索サイト（情報提供手段）をユーザに提供する。ユーザはこのサイトを通じて好みの飲食店を検索したりその飲食店に予約の連絡を入れたりすることができる。

図２の例は、飲食店を絞り込むための条件と飲食店のリストとを含む画面である。この画面は、任意の語句を入力して飲食店を検索するためのテキストボックスおよび検索ボタンと、予約可能な飲食店のみを表示させるためのチェックボックスと、カテゴリまたはエリアで飲食店を絞り込むためのリンクとを含んでいる。また、この画面には、初期値または検索結果として飲食店のリストが表示されている。リスト内の各店名は、その飲食店の詳細情報を示すページへのリンクとして表示されており、ユーザがそのリンクをクリックすると、選択された飲食店の詳細ページが表示される。本明細書ではこの詳細ページを「飲食店ページ（施設ページ）」ともいう。

飲食店ページの例を図３に示す。ユーザはこの詳細ページにアクセスすることで、選択した飲食店の電話番号やメニュー、地図などを知ることができる。また、ユーザは「Ｗｅｂから予約」ボタンを押すことで、その飲食店に予約を申し込むことができる。ユーザ端末Ｔが通話機能を備えていれば、ユーザは「電話をかける」ボタンを押すことで、その飲食店に電話をすることができる。

予約システム１は、連絡した飲食店がどこも満杯で予約を取ることができないユーザに予約可能な飲食店を紹介する。図４は、予約システム１のこのような特徴の概観を示す図である。

飲食店の情報を提供する従来のＷｅｂサイトでは、ユーザはこれから予約しようとする飲食店の空き状況を知ることができない。したがって、ユーザが予約を取ろうした時点で既にその飲食店の席が埋まっていて、ユーザが予約に失敗することがある。この場合、一般にユーザはそのＷｅｂサイト内で別の飲食店を探して電話または当該Ｗｅｂサイト経由でその店に予約を試みる。しかし場合によっては、ユーザがいくつかの飲食店に連絡してもどの店も予約が一杯で、ユーザがなかなか予約を取り付けないことがある。図４は、申込希望者（ａｐｐｌｉｃａｎｔ）がレストランＡ，Ｂ，Ｃに予約を試みたがいずれも失敗したことを示している。

このように予約ができない状況が続くと、ユーザが不満を抱いたり予約を諦めたりする可能性がある。一方、空席がある飲食店は顧客を掴む折角の機会を失うことにもなる。

そこで、このように予約ができない状況が続いている場合に、予約システム１は、予約受付が可能であると推定される飲食店を申込希望者に提示する。具体的には、予約システム１は、各飲食店の収容能力を示す情報（収容能力情報）と、各飲食店ページへのアクセスの履歴とに基づいて、空きがあると推定される飲食店を空き情報（ｖａｃａｎｃｙ ｉｎｆｏｒｍａｔｉｏｎ）としてユーザに紹介する。図４の例では、レストランＰ，Ｑ，Ｒが予約可能な飲食店としてユーザに提示されている。

飲食店の収容能力（座席数）はその施設の基本情報であるから、予約を受け付ける度にその飲食店が更新する情報ではない。また、アクセス履歴は予約システム１にて自動的に蓄積される情報であって各飲食店が登録する性質のものではない。したがって、この予約システム１では、空き情報を提供するために、各飲食店に予約状況または空き状況を登録または更新させる必要がない。

次に、予約サーバ１０によりアクセスされるデータベース群２０内の各データベースについて説明する。データベース群２０は、予約システム１で必要な各種データベースの集まりである。各データベースの設置場所は任意であり、例えば、各データベースが一箇所にまとめられていてもよいし、別々の場所に設置されていてもよい。各データベースの管理者は同一人であってもよいし互いに異なっていてもよい。

飲食店データベース２１は、各飲食店の情報を記憶する装置である。この飲食店情報（施設情報）は、飲食店ページに掲載されるような飲食店の基本情報であると言える。図５に示すように、飲食店情報は、飲食店を一意に特定する飲食店ＩＤとその飲食店の属性とが関連付けられたレコードである。この図の例では名称、所在地、電話番号、メールアドレス、飲食店ページのＵＲＬ、収容能力（収容可能数）、Ｗｅｂ予約の可否、カテゴリ、価格帯などが飲食店属性の項目として示されているが、属性情報の項目はこれらに限定されるものではない。

アクセス履歴データベース２２は、飲食店へのユーザのアクセス履歴を記憶する装置である。ユーザがなんらかの形で飲食店にアクセスしたことを示すデータであれば、アクセス履歴として記録されるデータは限定されない。

アクセス履歴の例を図６〜１０に示す。図６は、各飲食店の確定した予約を示す予約履歴を示す図である。飲食店の席の予約はユーザが電話やＷｅｂ予約などの通信手段を用いて施設にアクセスすることで成立するから、この予約履歴は飲食店へのユーザのアクセス履歴であると言える。図６に示すように、予約履歴は、予約を入れたユーザを一意に特定するユーザＩＤと、飲食店ＩＤと、予約内容とが互いに関連付けられたレコードである。この例では利用予定日時（予約日時）、人数、予約者の連絡先などが予約の詳細として示されているが、予約内容の項目はこれらに限定されるものではない。予約履歴のレコードは、予約がキャンセルされた場合、または予約された利用が終了した場合、または定期的に削除される。

図７は、ユーザが飲食店ページを閲覧したことを示す閲覧履歴を示している。閲覧履歴は、ユーザ端末Ｔ上に飲食店ページが表示されたことを示す記録であると言い換えることができる。Ｗｅｂサイトの閲覧はユーザがユーザ端末Ｔを用いて施設にアクセスしたことを意味するから、この閲覧履歴もアクセス履歴である。図７に示すように、閲覧履歴はユーザＩＤと、ＨＴＴＰセッション（ＨＴＴＰ ｓｅｓｓｉｏｎ）を特定するセッションＩＤと、飲食店ＩＤと、アクセスされた飲食店ページのＵＲＬと、アクセスの開始日時及び終了日時とが互いに関連付けられたレコードである。図７の例では、ユーザ「Ｕ００１」が１セッション「Ｓ００１」内で二つの飲食店ページにアクセスしていることがわかる。閲覧履歴はこれら以外の項目を含んでいてもよい。飲食店ＩＤはアクセスされたＵＲＬに基づいて飲食店データベース２１を参照することで得られる。

図８は、各ユーザ端末Ｔで指定および送信された検索クエリを示すアクセス履歴（検索履歴）を示している。この例では、ユーザＩＤと、セッションＩＤと、商品検索のためのクエリと、検索日時とが互いに関連付けられたレコードがアクセス履歴として蓄積されている。検索クエリは利用を希望する日時と参加予定人数とを含んでいる。これに加えて、検索クエリは飲食店のカテゴリ、飲食店が位置するエリア、価格帯などの他の条件を含んでいてもよい。

図９は、ユーザと飲食店との間で伝達された電子メールの履歴（メール履歴）を示している。メール履歴は、ユーザと飲食店との通信の記録（通信履歴）の一種である。図９に示すように、メール履歴は差出人のメールアドレス、宛先アドレス、送信日時、受信日時、およびメール本文が互いに関連付けられたレコードである。メール履歴はこれら以外の項目を含んでいてもよい。メール履歴は、図示しないメールサーバにより管理されているメールボックスそのものであってもよく、その場合にはそのメールボックスはアクセス履歴データベース２２の一部または全部である。あるいは、メール履歴は、そのメールボックスのコピーであってもよい。

図１０は、ユーザと飲食店との間で為された通話の履歴（通話履歴）を示している。この通話履歴も通信履歴の一種である。図１０に示すように、通話履歴は発信番号、着信番号、通話開始日時、および通話終了日時が互いに関連付けられたレコードである。通話履歴はこれら以外の項目を含んでいてもよい。通信履歴は、通話機能を有するユーザ端末Ｔの通話履歴を所定の記憶装置に蓄積したものであってもよい。あるいは、ユーザ端末Ｔにおいて一つの飲食店ページが所定時間以上（例えば１０分以上）連続して表示されている場合に、ユーザ端末Ｔ、予約サーバ１０、または他の監視サーバが、ユーザが飲食店に電話をしたと判定して、当該ユーザおよび飲食店の電話番号を含む通話履歴を生成しアクセス履歴データベース２２に格納してもよい。

ユーザ・データベース２３は、ユーザ情報を記憶する装置である。図１１に示すように、ユーザ情報はユーザＩＤとユーザの属性とが関連付けられたレコードである。図１１の例では名前、電話番号、およびメールアドレスがユーザ属性の項目として示されているが、属性情報の項目はこれらに限定されるものではない。

上記の各データベースおよび各レコードの構成は上記で示すものに限定されず、各データベースに対して任意の正規化又は冗長化を行ってよい。例えば、飲食店のＩＤとそのＷｅｂサイトのＵＲＬとは１対１の対応関係を有し、これら２項目の一方から他方を導くことができるので、閲覧履歴において飲食店ＩＤを省略してもよい。あるいは、メール履歴または通話履歴にユーザＩＤおよび飲食店ＩＤを付加してもよい。

次に、予約サーバ１０について説明する。予約サーバ１０のハードウェア構成は図１２に示す通りである。予約サーバ１０は、オペレーティングシステムやアプリケーション・プログラムなどを実行するＣＰＵ１０１と、ＲＯＭ及びＲＡＭで構成される主記憶部１０２と、ハードディスクやフラッシュメモリなどで構成される補助記憶部１０３と、ネットワークカードあるいは無線通信モジュールで構成される通信制御部１０４と、キーボードやマウスなどの入力装置１０５と、ディスプレイなどの出力装置１０６とを備えている。

後述する予約サーバ１０の各機能的構成要素は、ＣＰＵ１０１又は主記憶部１０２の上に所定のソフトウェアを読み込ませ、ＣＰＵ１０１の制御の下で通信制御部１０４や入力装置１０５、出力装置１０６などを動作させ、主記憶部１０２又は補助記憶部１０３におけるデータの読み出し及び書き込みを行うことで実現される。処理に必要なデータやデータベースは主記憶部１０２又は補助記憶部１０３内に格納される。

図１２では予約サーバ１０が１台のコンピュータで構成されているが、予約サーバ１０は複数台のコンピュータで構成されていてもよい。

図１３に示すように、予約サーバ１０は機能的構成要素として指示部１１、推定部（取得部も兼ねる）１２、および送信部１３を備えている。

指示部１１は、ユーザ（申込希望者）への空き情報の提供が必要であるか否かを判定し、それが必要であると判定した場合に空き情報の作成を指示する機能要素である。空き情報を作成するか否かの判定方法は限定されず、指示部１１は例えば下記の手法によりその判定を行うことができる。空き情報の作成が必要であると判定した場合には、指示部１１は指示信号を推定部１２に出力する。

［閲覧履歴の利用］
指示部１１は、飲食店検索サイトにアクセスしているユーザの行動を閲覧履歴に基づいて推定し、空き情報をそのユーザに提供するか否かを判定してもよい。具体的には、指示部１１は、ユーザが１セッションにおいて所定数以上の飲食店ページにアクセスしている場合に、そのユーザに空き情報を提供する。この判定に用いる閾値ＴＨａは限定されない。例えばその閾値ＴＨａは２〜１０の間の任意の数であってもよい。指示部１１はアクセス履歴データベース２２を参照して、現在継続中のセッションにおいて閾値ＴＨａ以上の飲食店ページにアクセスしているユーザを特定する。あるいは、指示部１１は、飲食店検索サイト全体での滞在時間が所定時間以上の場合に、空き情報をそのユーザに提供すると判定してもよい。

一以上のユーザを特定できた場合には、指示部１１はその各ユーザが用いた検索クエリを特定する。具体的には、指示部１１はユーザＩＤおよび現在のセッションＩＤに対応する検索クエリを読み出す。そして、指示部１１はユーザＩＤおよび検索クエリのペアを１以上生成し、生成したそのデータを指示信号として推定部１２に出力する。なお、ユーザの検索クエリを取得できなかった場合には、指示部１１はそのユーザの検索クエリを空値（ＮＵＬＬ）に設定すればよい。

一人のユーザも特定できなかった場合には、指示部１１はその指示信号を生成することなく処理を終了する。

［メール履歴の利用］
指示部１１は、飲食店検索サイトにアクセスしているユーザの行動をメール履歴に基づいて推定し、空き情報をそのユーザに提供するか否かを判定してもよい。具体的には、指示部１１は、予約の受付ができない旨の連絡を飲食店から受信したユーザに空き情報を提供する。

指示部１１は、現在時刻から所定時間だけ遡る間に生成されたアクセス履歴データベース２２内のメール履歴をすべて参照し、予約受付ができないことを示すテキストを本文に含むメールを特定する。以下ではこのメールを「予約不可通知」という。指示部１１は、予め設定したキーワードを用いたテキスト検索によりその特定処理を実行する。メール履歴の検索範囲、すなわち現在からどれくらい過去までのメール履歴を参照するかは任意に設定してよい。例えばその時間間隔は１０分〜３時間の間の任意の値であってよい。続いて、指示部１１は特定したメール履歴で示される差出人または宛先のアドレスに基づいてユーザ・データベース２３を参照することで、空き情報を提供すべきユーザを特定する。

指示部１１はメール履歴を用いることで、最近一回でも飲食店から予約を断られたユーザを特定することになる。別の手法として、指示部１１は複数の予約不可通知を受信したユーザのみを抽出してもよい。その閾値ＴＨｂは任意に設定可能であり、例えば２〜５の間のいずれかに設定してもよい。

一以上のユーザを特定できた場合には、指示部１１は検索履歴を参照して、ユーザＩＤおよび現在のセッションＩＤに対応する検索クエリを読み出す。そして、指示部１１はユーザＩＤおよび検索クエリのペアを１以上生成し、生成したそのデータを指示信号として推定部１２に出力する。ユーザの検索クエリを取得できなかった場合には、指示部１１はそのユーザの検索クエリを空値（ＮＵＬＬ）に設定する。

一人のユーザも特定できなかった場合には、指示部１１はその指示信号を生成することなく処理を終了する。

［通話履歴の利用］
指示部１１は、飲食店検索サイトにアクセスしているユーザの行動を通話履歴に基づいて推定し、空き情報をそのユーザに提供するか否かを判定してもよい。具体的には、指示部１１は、現在時刻から所定時間だけ遡る間に複数の飲食店に電話したユーザに空き情報を提供する。

指示部１１はアクセス履歴データベース２２にアクセスして、現在時刻から所定時間だけ遡る間に生成された通話履歴をすべて参照し、その時間の間に複数の飲食店に電話したユーザを特定する。この特定に用いる飲食店数の閾値ＴＨｃは任意に設定可能であり、例えば２〜５のいずれかに設定してもよい。通話履歴の検索範囲、すなわち現在からどれくらい過去までの通話履歴を参照するかは任意に設定してよい。例えばその時間間隔は１０分〜３時間の間の任意の値であってよい。続いて、指示部１１は通話履歴で示される発信番号または着信番号に基づいてユーザ・データベース２３を参照することで、空き情報を提供すべきユーザを特定する。

一以上のユーザを特定できた場合には、指示部１１は検索履歴を参照して、ユーザＩＤおよび現在のセッションＩＤに対応する検索クエリを読み出す。そして、指示部１１はユーザＩＤおよび検索クエリのペアを１以上生成し、生成したそのデータを指示信号として推定部１２に出力する。ユーザの検索クエリを取得できなかった場合には、指示部１１はそのユーザの検索クエリを空値（ＮＵＬＬ）に設定する。

一人のユーザも特定できなかった場合には、指示部１１はその指示信号を生成することなく処理を終了する。

メール履歴とは異なり通話履歴は通信内容を持たないので、通話履歴そのものを見ても、その電話により予約が成立したか否かを判定することができない。そこで、指示部１１は、複数の飲食店に電話したユーザは予約をまだ完了していない可能性がある（予約不可通知を受けた可能性がある）との前提に立って、空き情報を送るべきユーザを特定する。

推定部１２は、各飲食店の空き状況を推定し、申込希望者の予約を受付可能な飲食店をその推定結果に基づいて抽出する機能要素である。推定部１２は指示信号を受け付けるとその抽出処理を開始する。

上述したように、指示信号はユーザＩＤおよび検索クエリのペアを一つまたは複数含む。推定部１２は予約を受付可能な飲食店の検索をユーザ毎に実行する。以下では、一つのユーザＩＤに対する抽出処理の流れを説明する。推定部１２は以下に示すような様々な方法を用いて空きのある飲食店を抽出することができる。

［予約履歴の利用］
推定部１２は、希望日時に相当する各飲食店の空席数を算出することで空席を有する飲食店を抽出してもよい。具体的には、推定部１２は予約履歴を参照して、ユーザの希望日時に相当する各飲食店の予約人数を集計する。続いて、推定部１２は各飲食店の空席数を下記式により求める。収容能力は飲食店情報から得ることができる。
（空席数）＝（収容能力）−（合計予約人数）

例えば、レストランＡの収容能力が８０（人）であり、ユーザの希望日時においてレストランＡに予約Ｒ１，Ｒ２，Ｒ３が入っており、各予約の人数がそれぞれ１０、４、２であれば、空席数は８０−（１０＋４＋２）＝６４である。

飲食店の予約が予約システム１以外の他の予約システムからも可能である場合には、飲食店の空席数が上記の式で求まる値よりも少ないことが考えられる。そこで、推定部１２は、アクセス履歴データベース２２内の予約履歴から求まる予約人数に係数αを乗じた上で空席数を求めてもよい。ここで、α＞１である。係数αの決定方法は任意である。例えば、他のウェブサイトの個数や各ウェブサイトのアクセス数などに基づいて係数αを決めてよい。

例えば、上記レストランＡに関する例においてα＝３とすれば、推定空席数は８０−３×（１０＋４＋２）＝３２となる。

このように各飲食店の空席数を求めた後、推定部１２は、空席数が所定の閾値ＴＨｄ以上である飲食店に対して「予約可能フラグ＝ＯＮ」を関連付け、空席数が閾値ＴＨｄ未満である飲食店に対して「予約可能フラグ＝ＯＦＦ」を関連付ける。ここで、この閾値ＴＨｄはユーザの検索クエリで指定されている人数であってもよいし、固定値（例えば２〜１０の間の任意の値）であってもよい。閾値ＴＨｄは飲食店毎または飲食店の属性（ジャンル、エリア、価格帯など）毎に異ならせてもよい。検索クエリで指定されている人数を用いれば、ユーザの希望に合致する飲食店を抽出することができる。一方、固定値を用いた場合には、検索クエリに人数が指定されていなくても飲食店を絞り込むことができる。

検索クエリにカテゴリやエリアなどの他の条件が指定されている場合には、推定部１２は、予約可能フラグがＯＮである飲食店のうちその条件を満たす飲食店に「一致フラグ＝ＯＮ」を関連付け、その条件を満たさなかった飲食店に「一致フラグ＝ＯＦＦ」を関連付ける。他の条件が指定されていなければ、推定部１２はすべての飲食店について一致フラグをＯＮに設定する。

続いて、推定部１２は最終的に抽出した飲食店のリストを、算出した各飲食店の空席数と共に送信部１３に出力する。

［閲覧履歴の利用］
飲食店の予約履歴を取得できない場合には、推定部１２はその飲食店のＷｅｂページの閲覧履歴に基づいて当該飲食店の予約の可否を判定してもよい。具体的には、推定部１２は現在時刻から所定時間だけ遡る間に生成された閲覧履歴を飲食店毎に数えることで、各飲食店ページへのアクセス数を求める。ここで、その所定時間は任意に設定してよく、例えば１日、１週間、１ヵ月でもよい。一般に飲食店には繁忙期および閑散期があるので、その時期に応じてその所定時間を変更してもよい。続いて、推定部１２は各飲食店についてそのアクセス数を収容能力で割った値をアクセス率として求める。すなわち、本明細書において、アクセス率は下記式により求まる。
（アクセス率）＝（アクセス数）／（収容能力）

例えば、レストランＡの収容能力が８０（人）であり、集計されたレストランＡのＷｅｂページのアクセス数が１２０であったならば、アクセス率は１２０／８０＝１．５である。

このように各飲食店のアクセス率を求めた後、推定部１２は、アクセス率が所定の閾値ＴＨｅ未満である飲食店に対して「予約可能フラグ＝ＯＮ」を関連付け、アクセス率が閾値ＴＨｅ以上である飲食店に対して「予約可能フラグ＝ＯＦＦ」を関連付ける。閾値ＴＨｅの設定方法は限定されない。例えば、アクセス数に対する予約申込数の一般的な割合を推定した上で閾値ＴＨｅを設定してもよい。この場合には、アクセスしたユーザの全員が予約を申し込むとは考えにくいことから、閾値ＴＨｅを１より大きな値（たとえば２〜１０の間の任意の値）にしてもよい。このように閲覧履歴を用いることで、予約数を特定できない場合にも飲食店の空き状況を推定することができる。閾値ＴＨｅは飲食店毎または飲食店の属性（ジャンル、エリア、価格帯など）毎に異ならせてもよい。

検索クエリにカテゴリやエリアなどの他の条件が指定されている場合には、推定部１２は、予約可能フラグがＯＮである飲食店のうちその条件を満たす飲食店に「一致フラグ＝ＯＮ」を関連付け、その条件を満たさなかった飲食店に「一致フラグ＝ＯＦＦ」を関連付ける。他の条件が指定されていなければ、推定部１２はすべての飲食店について一致フラグをＯＮに設定する。

続いて、推定部１２は最終的に抽出した飲食店のリストを出力する。この際に、推定部１２は、各飲食店のアクセス数から予約数を推定し、収容能力からその予約数を引いた値を空席数としてリストと共に送信部１３に出力してもよい。例えば、上記レストランＡでは８件に１件の割合で予約が成立していると仮定し、アクセス数が１２０であったならば、推定部１２は予約数を１２０／８＝１５であると推定して、空席数を８０−１５＝６５と推定する。

予約可能フラグおよび一致フラグが共にＯＮである飲食店の個数が所定数以下であれば、推定部１２は、実行した推定処理よりも条件を緩和して再度同じ推定処理を実行してもよい。

例えば、推定部１２は一致フラグをＯＮにする条件を緩和することで、予約受付可能な場所としてユーザに示す飲食店の個数を増やしてもよい。条件を緩和する手段としては、飲食店のエリアを拡張するかまたは変更したり、価格帯を拡張するかまたは変更したりすることが考えられる。ユーザが１セッション内で複数回検索したのであれば、推定部１２は複数の検索クエリの少なくとも一つに該当する飲食店の一致フラグをＯＮにしてもよい。

あるいは、推定部１２は予約可能フラグをＯＮにする条件を緩和することで、予約受付可能な場所としてユーザに示す飲食店の個数を増やしてもよい。例えば、推定部１２は閾値ＴＨｄの値を前回よりも下げるか、または閾値ＴＨｅの値を前回よりも上げた上で、再度推定処理を実行してもよい。

推定部１２は、予約可能な飲食店のリストを各ユーザＩＤについて生成し、送信部１３に出力する。この処理において推定部１２は、各飲食店の基本情報もユーザ端末Ｔに送信するために、その情報を飲食店データベース２１から抽出してリストに含める。

送信部１３は、抽出された飲食店、すなわち予約受付が可能であると推定される飲食店を示す空き情報（推定結果に基づく情報）をユーザ端末Ｔに送信する機能要素である。送信部１３は入力されたリストを空き情報として、ユーザＩＤに対応するユーザ端末Ｔに送信する。複数のユーザに空き情報を提示する場合には、送信部１３は各ユーザの端末Ｔに向けて、対応する空き情報を送信する。

次に、図１４を用いて、予約システム１の動作を説明するとともに本実施形態に係る情報処理方法について説明する。以下では、ユーザが端末Ｔを介して飲食店予約サイトにアクセスし、店を検索したり、各飲食店のページを閲覧したり、Ｗｅｂ予約を試みたりしているが、なかなか予約できないでいることを前提として、その後の処理を説明する。この場合には、飲食店検索サイトにおいてユーザ端末Ｔと予約サーバ１０との間に何度かＨＴＴＰリクエスト／ＨＴＴＰレスポンス（ＨＴＴＰ ｒｅｑｕｅｓｔ／ＨＴＴＰ ｒｅｓｐｏｎｓｅ）が発生している（ステップＳ１１）。

このとき予約サーバ１０では、指示部１１が、予約できないでいるユーザを特定して、そのユーザのために予約可能な飲食店のリストを生成するように推定部１２に指示する（ステップＳ１２）。上述したように、指示部１１は閲覧履歴、メール履歴、あるいは通話履歴に基づいてそのようなユーザを特定することができる。

続いて、推定部１２が各飲食店の空席数を推定する（ステップＳ１３）。上述したように、推定部１２は予約履歴または閲覧履歴に基づいて空席数を求めることができる。すべての店舗について空席数の推定を行うと（ステップＳ１４；ＹＥＳ）、推定部１２は予約受付可能な飲食店を選択する（ステップＳ１５）。この選択に関しても、上記の通り様々な手法が考えられる。これらステップＳ１３〜Ｓ１５は取得ステップおよび推定ステップに相当する。

続いて、送信部１３が、必要であれば表示のための空き情報の編集（例えば、後述するような並べ替え）を行った上で（ステップＳ１６）、その空き情報をユーザ端末Ｔに送信する（ステップＳ１７、送信ステップ）。

ユーザ端末Ｔは、その空き情報を受信して画面上に表示する（ステップＳ１８）。これにより、予約可能な飲食店がその空席数と共に画面上に表示されるので、ユーザはこの空き情報に基づいて、予約が可能と思われる飲食店に連絡することができる。

ユーザ端末Ｔは下記のような様々な態様により空き情報を表示してよい。

例えば、ユーザ端末Ｔは予約可能であると判定された飲食店のみを含むリストを表示してもよい。この場合には、ユーザ端末Ｔは予約可能フラグがＯＮである飲食店のみを表示する。

あるいは、ユーザ端末Ｔは、予約を確保しやすい飲食店を優先的に表示させるために、空席数の降順またはアクセス率の昇順に飲食店を表示してもよい。また、ユーザ端末Ｔは上位に位置する飲食店のみ（例えば上位１０位までの飲食店のみ）を表示してもよい。

あるいは、ユーザ端末Ｔは申込希望者により指定された検索クエリとの合致度が高い飲食店ほど上位に表示してもよい。この場合には、ユーザ端末Ｔは予約可能フラグおよび一致フラグが共にＯＮである飲食店を、それ以外の飲食店よりも上位に表示する。

あるいは、ユーザ端末Ｔの現在位置に近い飲食店ほど上位に表示したりしてもよい。この場合には、ユーザ端末ＴはＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）機能などにより自端末の現在位置を求め、その現在位置と各飲食店情報（所在地）とを比較することでリスト内の飲食店情報を並べ替える。

あるいは、ユーザ端末Ｔは予約可能であると判定された飲食店と予約不可能であると判定された飲食店の双方を含むリストを表示してもよい。この場合にはユーザ端末Ｔは、予約可能フラグがＯＮである飲食店が、予約可能フラグがＯＦＦである飲食店よりも上位になるように表示順を設定する。この場合にも、ユーザ端末Ｔは空席数の降順またはアクセス率の昇順に飲食店を並べ替えてもよい。

あるいは、ユーザ端末Ｔは予約不可能であると判定された飲食店を強調表示することなく、予約可能であると判定された飲食店のみを強調表示してもよい。強調表示の方法は限定されず，例えば背景色の変更、目印の不可、ポップアップ表示などの様々な手法が利用可能である。

あるいは、ユーザ端末Ｔは、ユーザがアクセスした当時は予約できなかったが、その後に空席が生じて予約受付が可能になった飲食店を上位に表示してもよい。この場合には、予約サーバ１０において推定部１２または送信部１３が、空き情報の履歴を所定のデータベース（図示せず）に記録する。そして、推定部１２は、今回生成した空き情報と過去に生成した空き情報とを比較することで、予約可能フラグがＯＦＦからＯＮに変わった飲食店についてのみ、予約受付可能に変更になったことを示す情報を付加する。

ユーザ端末Ｔは、空き情報を表示する際に、画面上に表示されている現在ページからその空き情報のページに表示を切り替えてもよいし、その現在ページを残しつつ空き情報をポップアップ表示してもよい。この際にユーザ端末Ｔは、ページ切替またはポップアップ表示の前にその制御を実行してよいか否かをメッセージ表示によりユーザに問い合わせ、ユーザから許可の旨の入力を受け付けた場合に初めてそのページ切替またはポップアップ表示を実行してもよい。

このように空き情報の表示態様は様々であるが、いずれにしても申込希望者に訴えるような態様で空き情報が表示されるので、申込希望者は予約受付が可能な飲食店を簡単に見つけることができる。

次に、図１５を用いて、コンピュータを予約サーバ１０として機能させるための情報処理プログラムＰについて説明する。

情報処理プログラムＰは、メインモジュールＰ１０、指示モジュールＰ１１、推定モジュールＰ１２、および送信モジュールＰ１３を備えている。

メインモジュールＰ１０は、予約管理を統括的に制御する部分である。指示モジュールＰ１１、推定モジュールＰ１２、および送信モジュールＰ１３を実行することにより実現される機能はそれぞれ、上記の指示部１１、推定部１２、および送信部１３の機能と同様である。

情報処理プログラムＰは、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ、半導体メモリ等の有形の記録媒体に固定的に記録された上で提供されてもよい。また、情報処理プログラムは、搬送波に重畳されたデータ信号として通信ネットワークを介して提供されてもよい。

以上説明したように、本実施形態によれば、飲食店の収容能力情報とその飲食店へのアクセス履歴とから各飲食店の空き状況が推定され、ユーザの予約を受付可能な飲食店がその推定結果に基づいて抽出されてユーザに提供される。このように、飲食店へのアクセス状況から飲食店の空き状況を推定することで、個々の飲食店が自らその空き状況を登録または更新する手間が省かれる。したがって、空き状況を管理する飲食店の負荷を軽減しつつ、ユーザからの飲食店予約を受け付けることができる。

また、本実施形態によれば、予約を取れないでいる申込希望者がユーザの閲覧履歴、メール履歴、あるいは通話履歴に基づいて推定され、その申込希望者に対して空き情報が提示される。したがって、ユーザが予約を途中で諦めてしまう自体を回避でき、空席を有する飲食店は予約を受ける機会を得られる。このように、予約システム１はユーザにとっても飲食店にとっても便利である。

以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で様々な変形が可能である。

ユーザ端末Ｔにおける空き情報の表示の制御は予約サーバ１０が行ってもよいし、ユーザ端末Ｔで行ってもよいし、これらの双方が協働して実行してもよい。

空き情報を表示する際には空席数を省略してもよい。

指示部１１は、空き情報を要求する信号をユーザ端末Ｔから受信した場合に指示信号を出力してもよい。この要求信号は少なくともユーザＩＤを含んでおり、飲食店を絞り込むための検索クエリを含んでいてもよい。この場合には、指示部１１はそのユーザＩＤか、またはユーザＩＤおよび検索クエリのペアを指示信号として推定部１２に出力する。なお、要求信号が検索クエリを含んでいない場合には、指示部１１はアクセス履歴データベース２２の検索履歴から検索クエリを取得してもよい。具体的には、指示部１１はユーザＩＤおよび最新のセッションＩＤに対応する検索クエリを読み出して、その検索クエリを指示信号に含めてもよい。

１…予約システム、１０…予約サーバ（情報処理装置）、１１…指示部、１２…推定部（取得部も兼ねる）、１３…送信部、２０…データベース群（記憶部）、２１…飲食店データベース、２２…アクセス履歴データベース、２３…ユーザ・データベース、Ｐ…情報処理プログラム、Ｐ１０…メインモジュール、Ｐ１１…指示モジュール、Ｐ１２…推定モジュール、Ｐ１３…送信モジュール、Ｔ…ユーザ端末。

Claims (10)

1. 申込希望者が施設にアクセスしたことを示すアクセス履歴に基づいて、前記申込希望者が所定時間内に複数の施設ページにアクセスしたと判定したか、または前記申込希望者が所定時間内に前記複数の施設から電子メールもしくは電話で予約不可通知を受けたと判定した場合に、対象施設が予約受付可能か否かの推定結果に基づく情報を前記申込希望者に提供すると判定する指示部と、
   前記指示部が前記情報を前記申込希望者に提供すると判定した場合に、前記対象施設の収容可能数と所定時間前からの該対象施設に対するアクセス数とに基づいて該対象施設が予約受付可能か否かを推定する推定部と、
   前記推定部による推定結果に基づく前記情報を前記申込希望者のユーザ端末に出力する送信部と
   を備える情報処理装置。
2. 前記推定部が、前記対象施設とユーザとの間で成立した予約の人数の集計値を取得し、前記収容可能数と、１より大きい所定の係数が乗じられた前記集計値とから該対象施設の空席数を求め、前記空席数が所定の閾値以上である場合に該対象施設を予約受付可能と推定する、
   請求項１に記載の情報処理装置。
3. 前記推定部が、前記対象施設の施設ページへのアクセス数を前記収容可能数で割ることでアクセス率を取得し、該アクセス率が所定の閾値以下である場合に該対象施設を予約受付可能と推定する、
   請求項１に記載の情報処理装置。
4. 前記推定部が、
   前記集計値を取得できる場合には、前記空席数を求めて該空席数が所定の閾値以上である場合に前記対象施設を予約受付可能と推定し、
   前記集計値を取得できない場合には、前記対象施設の施設ページへのアクセス数を前記収容可能数で割ることでアクセス率を取得し、該アクセス率が所定の閾値以下である場合に前記対象施設を予約受付可能と推定する、
   請求項２に記載の情報処理装置。
5. 前記アクセス履歴が、前記申込希望者が前記施設ページを閲覧した記録である閲覧履歴を含み、
   前記指示部が、前記閲覧履歴に基づいて、前記申込希望者が前記所定時間内に前記複数の施設ページにアクセスしたと判定した場合に、前記情報を前記申込希望者に提供すると判定する、
   請求項１〜４のいずれか一項に記載の情報処理装置。
6. 前記アクセス履歴が、前記申込希望者と前記施設との電子メールの記録であるメール履歴を含み、
   前記指示部が、前記電子メールの内容を解析することで該電子メールが前記予約不可通知に該当するか否かを判定する、
   請求項１〜４のいずれか一項に記載の情報処理装置。
7. 前記アクセス履歴が、前記申込希望者と前記施設との通話の記録である通話履歴を含み、
   前記指示部が、前記通話履歴に基づいて、前記申込希望者が所定時間内に複数の前記施設と電話したことを特定した場合に、該申込希望者が該複数の施設から前記予約不可通知を受けたと判定する、
   請求項１〜４のいずれか一項に記載の情報処理装置。
8. 前記推定部が、推定処理により得られた予約受付可能な対象施設の数が所定数以下である場合に、該推定処理よりも条件を緩和して再度推定処理を実行する、
   請求項１〜７のいずれか一項に記載の情報処理装置。
9. プロセッサを備える情報処理装置により実行される情報処理方法であって、
   申込希望者が施設にアクセスしたことを示すアクセス履歴に基づいて、前記申込希望者が所定時間内に複数の施設ページにアクセスしたと判定したか、または前記申込希望者が所定時間内に前記複数の施設から電子メールもしくは電話で予約不可通知を受けたと判定した場合に、対象施設が予約受付可能か否かの推定結果に基づく情報を前記申込希望者に提供すると判定する指示ステップと、
   前記指示ステップにおいて前記情報を前記申込希望者に提供すると判定した場合に、前記対象施設の収容可能数と所定時間前からの該対象施設に対するアクセス数とに基づいて該対象施設が予約受付可能か否かを推定する推定ステップと、
   前記推定ステップにおける推定結果に基づく前記情報を前記申込希望者のユーザ端末に出力する送信ステップと
   を含む情報処理方法。
10. 申込希望者が施設にアクセスしたことを示すアクセス履歴に基づいて、前記申込希望者が所定時間内に複数の施設ページにアクセスしたと判定したか、または前記申込希望者が所定時間内に前記複数の施設から電子メールもしくは電話で予約不可通知を受けたと判定した場合に、対象施設が予約受付可能か否かの推定結果に基づく情報を前記申込希望者に提供すると判定する指示部と、
    前記指示部が前記情報を前記申込希望者に提供すると判定した場合に、前記対象施設の収容可能数と所定時間前からの該対象施設に対するアクセス数とに基づいて該対象施設が予約受付可能か否かを推定する推定部と、
    前記推定部による推定結果に基づく前記情報を前記申込希望者のユーザ端末に出力する送信部と
    としてコンピュータを機能させる情報処理プログラム。

Images