(57)【特許請求の範囲】
【請求項１】
対象施設の識別子および利用予定日を含む検索条件を受け付ける受付部と、
施設、利用予定日、および予約受付日を含む予約受付情報を記憶する記憶部を参照して、前記検索条件の利用予定日に基づく過去の判定対象期間に対応する前記対象施設の予約受付情報を抽出する抽出部と、
抽出された前記予約受付情報に基づいて前記過去の判定対象期間における前記対象施設の初期在庫数からの減少度合を求め、該判定対象期間において在庫数が所定の閾値未満に変化した変化日が存在する場合には、前記検索条件の利用予定日に施設を利用するための予約申込の目安日を該変化日を用いて設定する設定部と、
前記設定部により設定された値を予約申込の目安情報として出力する提示部と
を備える情報提供装置。
【請求項２】
前記設定部が、前記変化日が存在しない場合には、直前予約が可能であることを示すメッセージを設定する、
請求項１に記載の情報提供装置。
【請求項３】
前記抽出部が、前記検索条件の利用予定日に基づく現在の判定対象期間に対応する前記対象施設の予約受付情報をさらに抽出し、
前記設定部が、前記現在の判定対象期間における前記対象施設の在庫数の変化と、前記過去の判定対象期間における前記在庫数の変化との差分を求め、前記過去の判定対象期間における前記変化日の有無に基づいて設定した前記値を該差分を用いて調整する、
請求項１または２に記載の情報提供装置。
【請求項４】
前記設定部が、前記現在の判定対象期間において前記対象施設の在庫数が現在の値になった第１の日付を求め、前記過去の判定対象期間において前記対象施設の在庫数が前記現在の値になった第２の日付を求め、前記設定した値を前記第１及び第２の日付の差分を用いて調整する、
請求項３に記載の情報提供装置。
【請求項５】
前記抽出部が、複数の過去の判定対象期間のそれぞれについて前記対象施設の予約受付情報を抽出し、
前記設定部が、前記複数の過去の判定対象期間のそれぞれについて前記変化日から該判定対象期間の終点までの日数を求め、該日数が最も長い前記過去の判定対象期間における前記変化日に基づいて前記目安日を設定する、
請求項１〜４のいずれか一項に記載の情報提供装置。
【請求項６】
前記設定部により設定される情報の種類を決定するモード決定部をさらに備え、
前記予約受付情報が、施設の利用プラン、該利用プランの予約者、該利用プランの前記利用予定日、および前記予約受付日を含み、
前記検索条件がユーザＩＤをさらに含み、
前記モード決定部が、前記ユーザＩＤに対応する前記予約受付情報で示される前記利用予定日および前記予約受付日の差分を求め、該差分が所定の閾値未満であれば予約優先モードで目安情報を設定すると決定し、該差分が該閾値以上であればプラン優先モードで目安情報を設定すると決定し、
前記設定部が、
前記予約優先モードの場合には、前記予約申込の目安情報を設定し、
前記プラン優先モードの場合には、前記抽出された予約受付情報に基づいて前記過去の判定対象期間における前記対象施設の利用プランの総数からの減少度合を求め、該判定対象期間において残数が所定の閾値未満に変化した変化日が存在する場合には、複数の利用プランから選択できる目安日を該変化日を用いて設定する、
請求項１〜５のいずれか一項に記載の情報提供装置。
【請求項７】
施設の位置と、該施設の利用者が投稿したコメントと、該利用者による該施設の利用日とが関連付けられたデータをさらに記憶する前記記憶部を参照して、前記施設が位置するエリアと、前記コメントから抽出したキーワードと、前記利用日に対応する時期とのセットを取得する取得部と、
前記エリアおよび前記キーワードのペア毎に所定の期間内の各時期における前記セットの個数を集計することで、該個数の分布を求める集計部と、
前記個数が他の時期よりも所定の基準以上多いバースト時期が存在する前記ペアについての情報を該バースト時期と関連付けて出力する提示部と
を更に備え、
前記受付部が、前記ペアについての情報の出力に応じて行われたユーザ操作に基づいて生成された前記検索条件を受け付ける、
請求項１〜６のいずれか一項に記載の情報提供装置。
【請求項８】
前記ペアについての情報が、前記キーワードで示されるイベントの開催日を含み、
前記受付部が、前記開催日以前の第１の利用予定日と、該開催日より後の第２の利用予定日とを含む検索条件を受け付け、
前記抽出部および前記設定部が、前記第１および第２の利用予定日のそれぞれについて処理を実行し、
前記提示部が、前記第１および第２の利用予定日のそれぞれについての前記目安情報を出力する、
請求項７に記載の情報提供装置。
【請求項９】
情報提供装置により実行される情報提供方法であって、
対象施設の識別子および利用予定日を含む検索条件を受け付ける受付ステップと、
施設、利用予定日、および予約受付日を含む予約受付情報を記憶する記憶部を参照して、前記検索条件の利用予定日に基づく過去の判定対象期間に対応する前記対象施設の予約受付情報を抽出する抽出ステップと、
抽出された前記予約受付情報に基づいて前記過去の判定対象期間における前記対象施設の初期在庫数からの減少度合を求め、該判定対象期間において在庫数が所定の閾値未満に変化した変化日が存在する場合には、前記検索条件の利用予定日に施設を利用するための予約申込の目安日を該変化日を用いて設定する設定ステップと、
前記設定ステップにおいて設定された値を予約申込の目安情報として出力する提示ステップと
を含む情報提供方法。
【請求項１０】
対象施設の識別子および利用予定日を含む検索条件を受け付ける受付部と、
施設、利用予定日、および予約受付日を含む予約受付情報を記憶する記憶部を参照して、前記検索条件の利用予定日に基づく過去の判定対象期間に対応する前記対象施設の予約受付情報を抽出する抽出部と、
抽出された前記予約受付情報に基づいて前記過去の判定対象期間における前記対象施設の初期在庫数からの減少度合を求め、該判定対象期間において在庫数が所定の閾値未満に変化した変化日が存在する場合には、前記検索条件の利用予定日に施設を利用するための予約申込の目安日を該変化日を用いて設定する設定部と、
前記設定部により設定された値を予約申込の目安情報として出力する提示部と
をコンピュータに実行させる情報提供プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の一側面は、施設予約に資する情報を提供する装置、方法、およびプログラムに関する。
【背景技術】
【０００２】
従来から、施設利用の予約を受け付けるサービスが知られている。このようなサービスの一例として、下記特許文献１に記載のインターネット宿泊予約システムがある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−１６７１６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ユーザは施設を利用したい日のスケジュールを確保した上で予約を入れるのが通常であり、一般的には、利用予定日が近くになってから予約を入れることが多い。しかし、利用予定日間近に予約を入れようとするとその時点で施設に空きがない可能性がある。また、潤沢な種類の施設利用プランから所望のプランを選択したいユーザにとっては、利用予定日に近づいた時点で予約を入れようとすると予約可能なプランの選択肢がない場合がある。そのため、いつまでに施設の利用予約を申し込めばよいかをユーザに提示することができれば便利である。
【課題を解決するための手段】
【０００５】
本発明の一側面に係る情報提供装置は、対象施設の識別子および利用予定日を含む検索条件を受け付ける受付部と、施設、利用予定日、および予約受付日を含む予約受付情報を記憶する記憶部を参照して、検索条件の利用予定日に基づく過去の判定対象期間に対応する対象施設の予約受付情報を抽出する抽出部と、抽出された予約受付情報に基づいて過去の判定対象期間における対象施設の初期在庫数からの減少度合を求め、該判定対象期間において在庫数が所定の閾値未満に変化した変化日が存在する場合には、検索条件の利用予定日に施設を利用するための予約申込の目安日を該変化日を用いて設定する設定部と、設定部により設定された値を予約申込の目安情報として出力する提示部とを備える。【０００６】
本発明の一側面に係る情報提供方法は、情報提供装置により実行される情報提供方法であって、対象施設の識別子および利用予定日を含む検索条件を受け付ける受付ステップと、施設、利用予定日、および予約受付日を含む予約受付情報を記憶する記憶部を参照して、検索条件の利用予定日に基づく過去の判定対象期間に対応する対象施設の予約受付情報を抽出する抽出ステップと、抽出された予約受付情報に基づいて過去の判定対象期間における対象施設の初期在庫数からの減少度合を求め、該判定対象期間において在庫数が所定の閾値未満に変化した変化日が存在する場合には、検索条件の利用予定日に施設を利用するための予約申込の目安日を該変化日を用いて設定する設定ステップと、設定ステップにおいて設定された値を予約申込の目安情報として出力する提示ステップとを含む。【０００７】
本発明の一側面に係る情報提供プログラムは、対象施設の識別子および利用予定日を含む検索条件を受け付ける受付部と、施設、利用予定日、および予約受付日を含む予約受付情報を記憶する記憶部を参照して、検索条件の利用予定日に基づく過去の判定対象期間に対応する対象施設の予約受付情報を抽出する抽出部と、抽出された予約受付情報に基づいて過去の判定対象期間における対象施設の初期在庫数からの減少度合を求め、該判定対象期間において在庫数が所定の閾値未満に変化した変化日が存在する場合には、検索条件の利用予定日に施設を利用するための予約申込の目安日を該変化日を用いて設定する設定部と、設定部により設定された値を予約申込の目安情報として出力する提示部とをコンピュータに実行させる。【０００８】
このような側面においては、対象施設に関する過去の予約情報に基づいて、過去の所定期間における当該施設での初期在庫数からの減少度合が算出され、その期間において在庫数が一定の基準を下回ったか否かが判定される。そして、在庫数がその基準を下回った場合には、その変化日に基づいて予約申込の目安日が設定される。このように、予約申込を保証できると推定される日付（目安日）を過去の在庫数の減少傾向を参酌して求めることで、いつまでに施設の利用予約を申し込めばよいかをユーザに提示することできる。【０００９】
他の側面に係る情報提供装置では、設定部が、変化日が存在しない場合には、直前予約が可能であることを示すメッセージを設定してもよい。【００１０】
他の側面に係る情報提供装置では、抽出部が、検索条件の利用予定日に基づく現在の判定対象期間に対応する対象施設の予約受付情報をさらに抽出し、設定部が、現在の判定対象期間における対象施設の在庫数の変化と、過去の判定対象期間における在庫数の変化との差分を求め、過去の判定対象期間における変化日の有無に基づいて設定した値を該差分を用いて調整してもよい。【００１１】
他の側面に係る情報提供装置では、設定部が、現在の判定対象期間において対象施設の在庫数が現在の値になった第１の日付を求め、過去の判定対象期間において対象施設の在庫数が現在の値になった第２の日付を求め、設定した値を第１及び第２の日付の差分を用いて調整してもよい。【００１２】
他の側面に係る情報提供装置では、抽出部が、複数の過去の判定対象期間のそれぞれについて対象施設の予約受付情報を抽出し、設定部が、複数の過去の判定対象期間のそれぞれについて変化日から該判定対象期間の終点までの日数を求め、該日数が最も長い過去の判定対象期間における変化日に基づいて目安日を設定してもよい。【００１３】
他の側面に係る情報提供装置では、設定部により設定される情報の種類を決定するモード決定部をさらに備え、予約受付情報が、施設の利用プラン、該利用プランの予約者、該利用プランの利用予定日、および予約受付日を含み、検索条件がユーザＩＤをさらに含み、モード決定部が、ユーザＩＤに対応する予約受付情報で示される利用予定日および予約受付日の差分を求め、該差分が所定の閾値未満であれば予約優先モードで目安情報を設定すると決定し、該差分が該閾値以上であればプラン優先モードで目安情報を設定すると決定し、設定部が、予約優先モードの場合には、予約申込の目安情報を設定し、プラン優先モードの場合には、抽出された予約受付情報に基づいて過去の判定対象期間における対象施設の利用プランの総数からの減少度合を求め、該判定対象期間において残数が所定の閾値未満に変化した変化日が存在する場合には、複数の利用プランから選択できる目安日を該変化日を用いて設定してもよい。【００１４】
他の側面に係る情報提供装置では、施設の位置と、該施設の利用者が投稿したコメントと、該利用者による該施設の利用日とが関連付けられたデータをさらに記憶する記憶部を参照して、施設が位置するエリアと、コメントから抽出したキーワードと、利用日に対応する時期とのセットを取得する取得部と、エリアおよびキーワードのペア毎に所定の期間内の各時期におけるセットの個数を集計することで、該個数の分布を求める集計部と、個数が他の時期よりも所定の基準以上多いバースト時期が存在するペアについての情報を該バースト時期と関連付けて出力する提示部とを更に備え、受付部が、ペアについての情報の出力に応じて行われたユーザ操作に基づいて生成された検索条件を受け付けてもよい。【００１５】
他の側面に係る情報提供装置では、ペアについての情報が、キーワードで示されるイベントの開催日を含み、受付部が、開催日以前の第１の利用予定日と、該開催日より後の第２の利用予定日とを含む検索条件を受け付け、抽出部および設定部が、第１および第２の利用予定日のそれぞれについて処理を実行し、提示部が、第１および第２の利用予定日のそれぞれについての目安情報を出力してもよい。
【発明の効果】
【００１６】
本発明の一側面によれば、いつまでに施設の利用予約を申し込めばよいかをユーザに提示することできる。
【図面の簡単な説明】
【００１７】
【図１】実施形態に係る情報提供システムにより提供される目安情報の例を示す図である。
【図２】目安日の予測の概念を説明する図である。
【図３】第１〜第３実施形態に係る情報提供システムの全体構成を示す図である。
【図４】実施形態に係る情報提供装置のハードウェア構成を示す図である。
【図５】第１及び第２実施形態に係る情報提供装置の機能構成を示すブロック図である。
【図６】第１実施形態に係る情報提供装置の動作を示すフローチャートである。
【図７】第１及び第２実施形態に係る情報提供プログラムの構成を示すブロック図である。
【図８】目安日の調整の概念を説明する図である。
【図９】第２実施形態に係る情報提供装置の動作を示すフローチャートである。
【図１０】第３実施形態に係る情報提供装置の機能構成を示すブロック図である。
【図１１】第３実施形態に係る情報提供装置の動作を示すフローチャートである。
【図１２】第３実施形態に係る情報提供プログラムの構成を示すブロック図である。
【図１３】第４実施形態に係る情報提供システムにより提供される画面の例を示す図である。
【図１４】第４実施形態に係る情報提供システムの全体構成を示す図である。
【図１５】第４実施形態に係る情報提供装置の機能構成を示すブロック図である。
【図１６】バースト時期の概念を示す図である。
【図１７】エリアおよびキーワードのペアについてのセット数の分布の例を示す図である。
【図１８】第４実施形態に係る情報提供装置の動作の一部を示すフローチャートである。
【図１９】第４実施形態に係る情報提供プログラムの構成を示すブロック図である。
【発明を実施するための形態】
【００１８】
以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。なお、図面の説明において同一又は同等の要素には同一の符号を付し、重複する説明を省略する。
【００１９】
（第１実施形態）
図１〜５を用いて、第１実施形態に係る情報提供システム１の機能及び構成を説明する。情報提供システム１は、施設利用の予約をいつまでに行うのが望ましいのかをユーザに提示するコンピュータ・システムである。
【００２０】
情報提供システム１からユーザに提供される画面の一例を図１に示す。この画面は宿泊施設および宿泊プランの検索結果の一覧であり、各施設の各プランについて、例えば「７月３１日までにご予約を」のような、予約の目安が示されている。この予約申込の目安日（以下では単に「目安日」ともいう）は、その日までに予約申込をすれば当該申込が確実に受け付けられると予想される推定値である。目安日は、施設にまだ在庫がある日のことであるから、このシステム１は在庫切れの時期を推定するのではない。ユーザはこのような目安情報から、施設利用の予約をいつまでに申し込めばよいかを知ることができる。
【００２１】
情報提供システム１は、過去における在庫の減少傾向に基づいて目安日を予測する。図２を用いてこの予測の概念を説明する。
【００２２】
情報提供システム１は、ユーザが施設利用を希望する日付（利用予定日）に相当する過去の日を対応過去日として設定する。そして、情報提供システム１は、施設に全く予約が入っていない時点（在庫数が収容能力に等しい時点）を始点とし当該対応過去日を終点とする所定の期間を、在庫数の減少度合を見るための判定対象期間として設定する。当然ながら、この判定対象期間は過去における時間間隔であり、その長さは任意に定めてよい（例えば、１ヵ月、２ヵ月など）。
【００２３】
続いて、情報提供システム１は判定対象期間における施設の在庫数の減少度合を求め、その在庫数が所定の閾値未満になった日を変化日として特定する。当然ながら、この変化日は過去の日である。そして、情報提供システム１はこの変化日に基づいて予約申込の目安日を決定する。この目安日は将来の日である。
【００２４】
図３に示すように、情報提供システム１はユーザ端末Ｔ、情報提供装置１０、及びデータベース群（記憶部）２０を備える。ユーザ端末Ｔと情報提供装置１０とはインターネットなどのネットワークを介して接続されている。情報提供装置１０はインターネットや専用線などのネットワークを介してデータベース群２０にアクセスできる。図３では３台のユーザ端末Ｔを示しているが、ユーザ端末Ｔの台数は限定されない。
【００２５】
ユーザ端末Ｔは、ユーザが所持するコンピュータである。ユーザ端末Ｔの種類は限定されず、例えば据置型又は携帯型のパーソナルコンピュータでもよいし、高機能携帯電話機（スマートフォン）や携帯電話機、携帯情報端末（ＰＤＡ）などの携帯端末でもよい。
【００２６】
データベース群２０は、情報提供システム１で必要な各種データベースの集まりである。各データベースの設置場所は任意であり、例えば、各データベースが一箇所にまとめられていてもよいし、別々の場所に設置されていてもよい。各データベースの管理者は同一人であってもよいし互いに異なっていてもよい。
【００２７】
予約受付データベース２１は、ユーザからの施設利用の予約申込を受け付けた履歴を記憶する装置である。施設の例としては宿泊施設、商業施設、公共施設、レジャー施設などが挙げられるが、施設の種類は限定されない。
【００２８】
ユーザが施設予約サイトを介して利用の予約を申し込んでその申込が受け付けられると、すなわち予約が可能であると判定されると、そのサイトを管理するサーバが予約受付情報を生成して予約受付データベース２１に格納する。例えば、ユーザが宿泊予約サイト上で宿泊先や利用期間、人数、宿泊プランなどを選択して送信ボタンを押すことで予約申込の要求が所定のサーバに送ると、そのサーバが予約受付処理を実行して予約受付情報を予約受付データベース２１に格納する。なお、本発明は一定量の予約受付情報が蓄積されたことを前提とするものなので、予約受付情報が最終的に予約受付データベース２１に格納されさえすれば、予約受付情報の生成および格納の手順は何ら限定されない。
【００２９】
本実施形態では、予約受付情報のレコードは以下の項目を含むものとする。ただし、予約受付情報は他の項目を含んでいてもよい。また、本実施形態ではユーザＩＤを用いないので、この項目は省略可能である。
【００３０】
・予約者を識別するユーザＩＤ
・ユーザが予約した施設を識別する施設ＩＤ
・利用数。この数は例えば部屋数、テーブル数、座席数などで示される。
・予約において申請された利用予定日
・予約申込を受け付けた日付（予約受付日）
【００３１】
ここで、利用予定日に関していうと、宿泊などのように利用期間が２日以上である場合には、この項目は利用の開始日および終了日を特定可能な任意の態様で記録される。例えば、利用予定日は「２０１３年６月１日〜２０１３年６月３日」、「２０１３年６月１日から２泊」というように記録されてもよい。あるいは、一つの予約に対して利用日数分のレコードが生成されて予約受付データベース２１に格納されてもよい。
【００３２】
施設データベース２２は、各施設の情報を記憶する装置である。本実施形態では、施設情報のレコードは少なくとも以下の項目を含むものとする。施設情報は電話番号、住所、ホームページのＵＲＬ（Uniform Resource Locator）、宿泊プランなどの他の施設属性を含んでもよい。
【００３３】
・施設ＩＤ
・施設名
・収容能力（総在庫数）。この数は例えば部屋数、テーブル数、座席数などで示される。
【００３４】
各データベースおよび各レコードの構成は上記で示すものに限定されず、各データベースに対して任意の正規化又は冗長化を行ってよい。例えば、予約受付情報の各レコードが、当該レコードで示される予約を受け付けた後の施設の在庫数を一つの項目として含んでもよい。
【００３５】
次に、情報提供装置１０について説明する。情報提供装置１０のハードウェア構成は図４に示す通りである。情報提供装置１０は、オペレーティングシステムやアプリケーション・プログラムなどを実行するＣＰＵ１０１と、ＲＯＭ及びＲＡＭで構成される主記憶部１０２と、ハードディスクやフラッシュメモリなどで構成される補助記憶部１０３と、ネットワークカードあるいは無線通信モジュールで構成される通信制御部１０４と、キーボードやマウスなどの入力装置１０５と、ディスプレイなどの出力装置１０６とを備えている。
【００３６】
後述する情報提供装置１０の各機能的構成要素は、ＣＰＵ１０１又は主記憶部１０２の上に所定のソフトウェアを読み込ませ、ＣＰＵ１０１の制御の下で通信制御部１０４や入力装置１０５、出力装置１０６などを動作させ、主記憶部１０２又は補助記憶部１０３におけるデータの読み出し及び書き込みを行うことで実現される。処理に必要なデータやデータベースは主記憶部１０２又は補助記憶部１０３内に格納される。
【００３７】
情報提供装置１０は１台のコンピュータで構成されてもよいし、複数台のコンピュータで構成されてもよい。
【００３８】
図５に示すように、情報提供装置１０は機能的構成要素として受付部１１、抽出部１２、設定部１３、および提示部１４を備える。
【００３９】
受付部１１は目安日を求める対象の施設の識別子（以下では「対象施設ＩＤ」という）と利用予定日とを含む検索条件を受け付ける機能要素である。本実施形態では受付部１１はユーザにより指定された検索条件をユーザ端末Ｔから受信するものとするが、受付部１１は情報提供装置１０において任意の基準で自動的に設定された検索条件を受け付けてもよい。対象施設ＩＤの個数は一つでもよいし複数でもよい。受付部１１は検索条件を抽出部１２に出力する。
【００４０】
抽出部１２は、検索条件に対応する過去の予約受付情報を予約受付データベース２１から抽出する機能要素である。
【００４１】
まず、抽出部１２は対応過去日および判定対象期間を設定する。対応過去日の設定方法は限定されない。例えば、抽出部１２は検索条件の利用予定日の１年前の日を対応過去日としてもよい。検索条件の利用予定日が「２０１３年８月１０日」であれば、抽出部１２は対応過去日を「２０１２年８月１０日」と設定する。この場合に、もし判定対象期間の始点が「２０１２年６月１日」であれば、抽出部１２は判定対象期間を「２０１２年６月１日〜２０１２年８月１０日」と設定する。
【００４２】
抽出部１２は２年以上の範囲内で複数の判定対象期間を設定してもよい。検索条件の利用予定日が「２０１３年８月１０日」であれば、抽出部１２は例えば「２０１２年８月１０日」および「２０１１年８月１１日」という二つの対応過去日を設定する。この場合、抽出部１２は例えば「２０１２年６月１日〜２０１２年８月１０日」および「２０１１年６月１日〜２０１１年８月１０日」という二つの判定対象期間を設定する。
【００４３】
日付が同じであっても曜日が毎年ずれていく点を考慮して、抽出部１２は検索条件の利用予定日と曜日が同じでありかつ月日が当該利用予定日のものと最も近い日を対応過去日として設定してもよい。例えば、検索条件の利用予定日が「２０１３年８月１０日」であれば、この日は土曜日である。そして、２０１２年８月１０日に最も近い土曜日は２０１２年８月１１日であるので、対応過去日は「２０１２年８月１１日」となる。この場合、判定対象期間を便宜的に２ヵ月としたならば、判定対象期間は「２０１２年６月１１日〜２０１２年８月１１日」となる。２０１１年についても判定対象期間を設定するのであれば、２０１１年８月１０日に最も近い土曜日が２０１１年８月１３日であるので、その期間は「２０１１年６月１３日〜２０１１年８月１３日」となる。
【００４４】
続いて、抽出部１２は、各対象施設について、施設ＩＤが一致し、利用予定日が対応過去日を含み、且つ予約受付日が判定対象期間内である予約受付情報を予約受付データベース２１から抽出する。そして、抽出部１２は各対象施設の予約受付情報を設定部１３に出力する。
【００４５】
設定部１３は、ユーザ端末Ｔに送信する目安情報を設定する機能要素である。設定部１３は、抽出された予約受付情報に基づいて判定対象期間における対象施設の初期在庫数からの減少度合を求め、この判定対象期間において在庫数が所定の閾値未満に変化した変化日が存在するか否かを判定する。設定部１３は、変化日が存在する場合には目安日を設定し、変化日が存在しなければ直前予約可能のメッセージを設定する。設定部は各対象施設についてこの処理を実行する。
【００４６】
設定部１３はこの判定に用いる閾値を予め内部に保持している。この閾値は、施設の在庫が少なくなったために早めに予約を済ませた方がよいと想定される時点での在庫数であるといえる。設定部１３は施設毎に設定された閾値を保持してもよいし、複数の施設で共通の閾値を保持してもよい。
【００４７】
以下では、一つの対象施設についての処理を説明する。まず、設定部１３は施設データベース２２にアクセスして対象施設の施設情報を参照することでその対象施設の収容能力を初期在庫数として取得する。また、設定部１３はその対象施設の予約受付情報を予約受付日の昇順に並べる。
【００４８】
続いて、設定部１３は対象施設の在庫数を減らす処理を予約受付情報の先頭のレコードから順に実行する。１レコード目の処理において、設定部１３は収容能力を在庫数の初期値として設定した上で、そのレコードで示される利用数を在庫数から減ずる。減算後の在庫数が閾値未満になった場合には、設定部１３はそのレコードで示される予約受付日を、在庫数が所定の閾値未満に変化した変化日として取得し、現在の対象施設についての処理を終了する。一方、減算後の在庫数が閾値以上であれば、設定部１３は１レコード目の処理を終了し、次のレコードの処理に移る。２レコード目以降についての処理は１レコード目の処理と同じである。設定部１３は、一の対象施設について、変化日を取得するかまたは最後のレコードを処理し終えるまでこの処理を繰り返す。
【００４９】
変化日が存在する場合には、設定部１３はその変化日から対応過去日までの日数を求め、利用予定日からその日数分だけ遡った日を対象施設の目安日として設定する。例えば、利用予定日が「２０１３年８月１０日」であり、対応過去日が「２０１２年８月１１日」であり、変化日が「２０１２年７月１５日」であった場合には、変化日から対応過去日までの日数は２７日であるので、目安日は「２０１３年７月１４日」となる。あるいは、設定部１３は変化日と月日が同じ現在または将来の日付を目安日として設定してもよい。この場合には、利用予定日が「２０１３年８月１０日」であり、対応過去日が「２０１２年８月１１日」であり、変化日が「２０１２年７月１５日」であれば、目安日は「２０１３年７月１５日」となる。
【００５０】
一方、変化日が存在しない場合には、設定部１３は目安日を設定することなく、直前予約が可能であることを示すメッセージを対象施設に対して設定する。「直前予約が可能である」とは、ユーザが利用予定日までの日数を気にせずにいつでも（例えば、利用予定日の前日まで）予約を申し込むことができることを意味する。
【００５１】
複数の判定対象期間が設定されている場合には、設定部１３は各判定対象期間について変化日の有無を判定し、取得した１以上の変化日のそれぞれについて対応過去日までの日数を求め、その日数が最も長い判定対象期間を選択する。そして、設定部１３は、選択した判定対象期間における変化日から対応過去日までの日数の分だけ利用予定日から遡った日を、対象施設の目安日として設定する。変化日を一つも取得できなかった場合には、設定部１３は直前予約が可能であることを示すメッセージを対象施設に対して設定する。
【００５２】
例えば、利用予定日が「２０１３年８月１０日」であり、判定対象期間Ａについての対応過去日および変化日がそれぞれ「２０１２年８月１１日」、「２０１２年７月１５日」であり、判定対象期間Ｂについての対応過去日および変化日がそれぞれ「２０１１年８月１３日」、「２０１１年７月１０日」であったとする。この場合には、判定対象期間Ａにおける変化日から対応過去日までの日数は２７日であり、判定対象期間Ｂについては３４日である。したがって、設定部１３は目安日を「２０１３年７月７日」に設定する。
【００５３】
このように利用予定日から最も離れている時点を目安日として設定することで、予約申込の受付をより確実に保証することができる。
【００５４】
設定部１３は目安日またはメッセージを設定する処理を各対象施設について実行すると、これらの目安情報を提示部１４に出力する。
【００５５】
提示部１４は、対象施設の予約をいつまでに済ませるのが望ましいかを示す目安情報をユーザに提供する機能要素である。提示部１４はその目安情報が掲載されるウェブページを生成してユーザ端末Ｔに送信し、ユーザ端末Ｔはそのウェブページを表示する。目安情報は目安日の昇順または降順に、すなわち目安日が現時点から近い順または遠い順に表示されてもよい。これにより、ユーザは各施設の予約の目安を知ることができる。図１の画面から、ユーザは例えばホテルＰのプランＡは７月３１日までに予約するのが望ましいことを知ることができ、予約ボタンを押してその宿泊プランを予約することもできる。このような画面において、直前予約が可能であることを示す「いつでも予約可能」というメッセージが表示されることもあり得る。
【００５６】
なお、画面を生成するための具体的な技術は限定されない。提示部１４は任意のスクリプトおよびプログラム言語を用いて画面を生成し、その画面のデータをユーザ端末Ｔに送信してよい。
【００５７】
次に、図６を用いて、情報提供装置１０の動作を説明するとともに本実施形態に係る情報提供方法について説明する。
【００５８】
まず、受付部１１が対象施設ＩＤおよび利用予定日を含む検索条件を受け付ける（ステップＳ１１、受付ステップ）。
【００５９】
続いて、抽出部１２がその検索条件に対応する過去の予約受付情報を抽出する（ステップＳ１２、抽出ステップ）。具体的には、抽出部１２は利用予定日に基づいて対応過去日および判定対象期間を設定する。そして、抽出部１２は各対象施設について、施設ＩＤが一致し、利用予定日が対応過去日を含み、且つ予約受付日が判定対象期間内である予約受付情報を予約受付データベース２１から抽出する。
【００６０】
続いて、設定部１３が各対象施設について予約の目安を設定する（設定ステップ）。具体的には、設定部１３は判定対象期間における一の対象施設の初期在庫数からの減少度合を予約受付情報に基づいて求め、その判定対象期間においてその在庫数が所定の閾値未満に変化した変化日が存在するか否かを判定する（ステップＳ１３）。続いて、設定部１３は変化日の判定結果に基づいて目安情報を設定する（ステップＳ１４）。具体的には、提示部１４は変化日が存在した場合には検索条件の利用予定日とその変化日とに基づいて目安日を設定し、変化日が存在しない場合には、直前予約が可能であることを示すメッセージを設定する。設定部１３はすべての対象施設についてこの一連の処理を実行する（ステップＳ１５参照）。
【００６１】
そして、提示部１４が設定された目安情報をユーザ端末Ｔに送信する（ステップＳ１６、提示ステップ）。ユーザ端末Ｔはその目安情報を表示し、これによりユーザはいつまでに予約を申し込むのが望ましいのかを対象施設毎に知ることができる。
【００６２】
次に、図７を用いて、情報提供装置１０を実現するための情報提供プログラムＰ１を説明する。
【００６３】
情報提供プログラムＰ１は、メインモジュールＰ１０、受付モジュールＰ１１、抽出モジュールＰ１２、設定モジュールＰ１３、および提示モジュールＰ１４を備えている。
【００６４】
メインモジュールＰ１０は、情報提供機能を統括的に制御する部分である。受付モジュールＰ１１、抽出モジュールＰ１２、設定モジュールＰ１３、および提示モジュールＰ１４を実行することにより実現される機能はそれぞれ、上記の受付部１１、抽出部１２、設定部１３、および提示部１４の機能と同様である。
【００６５】
情報提供プログラムＰ１は、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ、半導体メモリ等の有形の記録媒体に固定的に記録された上で提供されてもよい。また、情報提供プログラムＰ１は、搬送波に重畳されたデータ信号として通信ネットワークを介して提供されてもよい。
【００６６】
以上説明したように、本実施形態によれば、対象施設に関する過去の予約情報に基づいて、過去の所定期間における当該施設での初期在庫数からの減少度合が算出され、その期間において在庫数が一定の基準を下回ったか否かが判定される。そして、在庫数がその基準を下回った場合には、その変化日に基づいて予約申込の目安日が算出され、そうでない場合には直前予約が可能である旨が出力される。このように、予約申込を保証できると推定される日付（目安日）を過去の在庫数の減少傾向を参酌して求めることで、いつまでに施設の利用予約を申し込めばよいかをユーザに提示することできる。
【００６７】
在庫数を見ればその時点で予約が可能か否かを知ることができるが、ユーザは自分の予定が決まってから予約を入れるのが一般的であるから、在庫数を確認した時点で直ぐに予約を申し込むとは限らない。しかし、ユーザが決めかねている間に所望の施設の在庫が無くなる可能性がある。ある時点での在庫数を見るだけでは在庫の減少ペース（減少度合）を求めることができないので、いつ頃までに予約をすればよいかの目安も計算することができない。このような技術的課題を解決するために、本実施形態では、利用予定日に対応する過去の期間における在庫数の変化を求め、その変化に基づいて目安情報を設定する。
【００６８】
（第２実施形態）
情報提供装置１０は、過去の実績に基づいて求めた目安日を今年の在庫状況を考慮して修正した上で、修正後の目安日をユーザに提示してもよい。以下では、第１実施形態と異なる点について特に説明し、第１実施形態と同様の点については説明を省略する。
【００６９】
抽出部１２は、まず、第１実施形態と同様に過去の予約受付情報を抽出する。さらに、抽出部１２は各対象施設について、施設ＩＤが一致し、且つ利用予定日が検索条件で示される日付を含む予約受付情報を予約受付データベース２１から抽出する。この処理は、対象施設の今年の（現在の）予約状況を取得することを意味する。このように、抽出部１２は個々の対象施設について２種類の予約受付情報を抽出し、その情報を設定部１３に出力する。
【００７０】
設定部１３は各対象施設について以下の処理を実行する。まず、設定部１３は施設データベース２２にアクセスして対象施設の収容能力を取得する。また、設定部１３は入力された過去および今年の予約受付情報のそれぞれを予約受付日の昇順に並べる。
【００７１】
続いて、設定部１３は今年の判定対象期間における対象施設の在庫数を減らす処理を今年の予約受付情報の先頭のレコードから順に実行することで、現時点での在庫数Ｋと、在庫がその数Ｋになった日付（予約受付日）Ｄｃとを取得する。
【００７２】
続いて、設定部１３は過去の判定対象期間における対象施設の在庫数の変化を得るために、対象施設の在庫数を減らす処理を過去の予約受付情報の先頭のレコードから順に実行することで、在庫数がＫになった日付（予約受付日）Ｄｐを取得する。
【００７３】
そして、設定部１３は二つの日付Ｄｃ，Ｄｐの日数の差分Ｄを求める。図８にその差分の例を示す。この図では、過去の判定対象期間における在庫数の変化を実線Ｖｐで示し、現在の判定対象期間における在庫数の変化を破線Ｖａ，Ｖｂの２パターンで示している。差分Ｄａは今年の在庫の減少ペースが過去よりも遅いことを示し、差分Ｄｂは今年の在庫の減少ペースが過去よりも早いことを示している。
【００７４】
続いて、設定部１３は第１実施形態と同様に、過去の判定対象期間における対象施設の在庫数の変化を求め、この判定対象期間においてその在庫数が閾値未満に変化した変化日が存在するか否かを判定する。
【００７５】
変化日が存在する場合には、設定部１３はその変化日から対応過去日までの日数を求め、利用予定日からその日数分だけ遡った日をその対象施設の目安日として仮決めする。この処理は第１実施形態と同様である。続いて、設定部１３は仮決めした目安日に差分Ｄを適用して最終的な目安日を求める。今年の在庫の減少ペースが過去よりも遅ければ最終的な目安日は仮決めしたものよりも遅い日付になり、その減少ペースが過去よりも早ければ最終的な目安日は仮決めしたものよりも早い日付になる。
【００７６】
例えば、利用予定日が「２０１３年８月１０日」であり、対応過去日が「２０１２年８月１１日」であり、変化日が「２０１２年７月１５日」であった場合には、上記の通り仮の目安日は「２０１３年７月１４日」となる。設定部１３は、今年の減少ペースが過去よりも３日遅ければ目安日を「２０１３年７月１７日」にずらし、今年の減少ペースが過去よりも３日早ければ目安日を２０１３年７月１１日にずらす。
【００７７】
仮決めの目安日を差分Ｄだけずらして得られた日付が検索条件の利用予定日と同じかまたはそれより後になる場合には、設定部１３は直前予約が可能であることを示すメッセージを対象施設に対して設定する。
【００７８】
一方、ある対象施設について変化日が存在しない場合には、設定部１３は第１実施形態と同様に目安日を算出しなくてもよいし、今年の減少ペースが過去よりも早い場合のみ目安日を設定してもよい。目安日を設定する場合には、設定部１３は検索条件の利用予約日を差分Ｄだけずらすことで最終的な目安日を得る。すなわち、設定部１３は検索条件の利用予定日を仮の目安日として設定した上で最終的な目安日を求める。例えば、利用予定日が「２０１３年８月１０日」であり、今年の減少ペースが過去よりも３日早ければ、目安日は「２０１３年８月７日」となる。
【００７９】
次に、図９を用いて、本実施形態に係る情報提供方法について説明する。
【００８０】
まず、受付部１１が対象施設ＩＤおよび利用予定日を含む検索条件を受け付ける（ステップＳ２１、受付ステップ）。
【００８１】
続いて、抽出部１２がその検索条件に対応する過去および今年の予約受付情報を抽出する（ステップＳ２２、抽出ステップ）。過去の予約受付情報の抽出条件は第１実施形態と同じである。今年の予約受付情報については、抽出部１２は、施設ＩＤが一致し且つ利用予定日が検索条件のものを含む予約受付情報を予約受付データベース２１から抽出する。
【００８２】
続いて、設定部１３が各対象施設について予約の目安を設定する（設定ステップ）。具体的には、設定部１３は今年の予約受付情報に基づいて、在庫数が現在の値Ｋになった日付を求め（ステップＳ２３）、過去の予約受付情報に基づいて、在庫数がその値Ｋになった日付を求め（ステップＳ２４）、これら二つの日付の差分を求める（ステップＳ２５）。続いて、設定部１３は過去の予約受付情報に基づいて変化日の有無を判定し（ステップＳ２６）、変化日の判定結果と差分とに基づいて目安情報（目安日、または直前予約可能のメッセージ）を設定する（ステップＳ２７）。設定部はこの一連の処理をすべての対象施設について実行する（ステップＳ２８参照）。最後に、提示部１４が目安情報をユーザ端末Ｔに送信する（ステップＳ２９）。
【００８３】
以上説明したように、本実施形態においても、いつまでに施設の利用予約を申し込めばよいかをユーザに提示することできる。加えて、本実施形態では現在の判定対象期間における在庫数の変化も求め、過去の判定対象期間における在庫数の変化から求めた目安日を現在の在庫の減少傾向に基づいて調整することで、適切な目安日をユーザに提示することができる。
【００８４】
（第３実施形態）
第３実施形態に係る情報提供装置３０は、ユーザが利用予定日の近くになってから施設を予約する傾向があるか、それとも早い時点で多くの利用プランから一つを選んで予約する傾向があるかを判定し、その判定結果に応じて目安情報の種類を変える。具体的には、情報提供装置３０は、利用予定日の近くになってから施設を予約する傾向があるユーザには、第１および第２実施形態と同様に予約申込の目安日を提示する。一方、早めに施設を予約する傾向があるユーザには、ある程度豊富な数の利用プランから所望のプランを選ぶことができる目安日（プラン選択の目安日）を提示する。本実施形態では、各施設が複数の利用プランを提供することを前提とする。利用プランの例としてはホテルの宿泊プランが挙げられるが、利用プランの種類はこれに限定されない。以下では、第１実施形態と異なる点について特に説明し、第１実施形態と同様の点については説明を省略する。
【００８５】
本実施形態では、予約受付データベース２１内の予約受付情報の各レコードは、ユーザが予約した利用プランを一意に特定するプランＩＤを更に有するものとする。施設ＩＤおよびプランＩＤの組合せにより、ユーザがどの施設のどの利用プランを予約したかを特定することができる。
【００８６】
また、施設データベース２２内の施設情報の各レコードは、複数の利用プランに関するプラン情報を含むものとする。個々のプラン情報はプランＩＤおよび初期在庫数を含む。したがって、この施設情報を参照すれば、各施設においてプランがいくつあるか、および、各プランの初期在庫数がいくつかを知ることができる。
【００８７】
このようなデータベースの構成を前提として、情報提供装置３０の機能を説明する。図１０に示すように、情報提供装置３０は機能的構成要素として受付部３１、抽出部３２、モード決定部３３、設定部３４、および提示部３５を備えている。
【００８８】
受付部３１は対象施設ＩＤ、利用予定日、およびユーザＩＤを含む検索条件をユーザ端末Ｔから受信し、その検索条件を抽出部３２に出力する。
【００８９】
抽出部３２は、対象施設ＩＤおよび利用予定日に対応する過去の予約受付情報を予約受付データベース２１から抽出する。この抽出処理は第１実施形態と同様である。
【００９０】
モード決定部３３は、ユーザに提示する目安情報の種類を決定する機能要素である。モード決定部３３は、利用予定日の近くになってから施設を予約する傾向があるユーザには予約申込の目安情報を提示すると決定する。以下ではこの場合を「予約優先モード」という。一方、早めに施設を予約する傾向があるユーザには、モード決定部３３は、プラン選択の目安情報を提示すると決定する。以下ではこの場合を「プラン優先モード」という。
【００９１】
モード決定部３３は検索条件のユーザＩＤに対応する予約受付情報を予約受付データベース２１から読み出し、各レコードについて利用予定日と予約受付日との差分を求め、その差分の統計値（例えば平均値や中央値など）を求める。そして、モード決定部３３は、その統計値が所定の閾値未満であれば予約優先モードで処理を実行すると判定し、その統計値がその閾値以上であればプラン優先モードで処理を実行すると決定する。そして、モード決定部３３は判定結果を検索条件と共に設定部３４に出力する。
【００９２】
設定部３４は、決定されたモードに応じて２種類の設定処理のどちらか一方を実行する。予約優先モードでの処理は第１または第２実施形態と同様なので説明を省略し、以下では、プラン優先モードでの処理について説明する。
【００９３】
設定部３４はプラン数の変化日に用いる閾値を予め内部に保持している。この閾値は、ある程度豊富な数の利用プランが残っているといえる時点でのプラン数であるといえる。設定部３４は施設毎に設定された閾値を保持してもよいし、複数の施設で共通の閾値を保持してもよい。
【００９４】
以下では一つの対象施設についての処理を説明する。まず、設定部３４は施設データベース２２にアクセスして対象施設の施設情報を参照することで利用プランの総数と各利用プランの初期在庫数とを取得する。また、設定部３４は入力された予約受付情報を予約受付日の昇順に並べる。
【００９５】
続いて、設定部３４は対象施設の個々の利用プランの在庫数を減らす処理を予約受付情報の先頭のレコードから順に実行する。１レコード目の処理において、設定部３４はそのレコードで示される利用プランの利用数を、対応する初期在庫数から減ずる。減算後の在庫数が０になった場合には、設定部３４は利用プランの総数から１つ引いた数を利用プランの残数とする。更新後の残数が閾値未満になった場合には、設定部３４はそのレコードで示される予約受付日を、プラン数が所定の閾値未満に変化した変化日として取得し、現在の対象施設についての処理を終了する。一方、減算後の在庫数が１以上であれば、設定部３４は１レコード目の処理を終了し、次のレコードの処理に移る。また、利用プランの残数が所定の閾値より大きい場合も、設定部３４は１レコード目の処理を終了して次のレコードの処理に移る。２レコード目以降についての処理は１レコード目の処理と同じである。設定部３４は、一の対象施設について、変化日を取得するかまたは最後のレコードを処理し終えるまでこの処理を繰り返す。
【００９６】
変化日が存在する場合には、設定部３４はその変化日から対応過去日までの日数を求め、利用予定日からその日数分だけ遡った日を、プラン選択の目安日として設定する。
【００９７】
一方、変化日が存在しない場合には、設定部３４は目安日を設定することなく、プラン選択が直前まで可能であることを示すメッセージを対象施設に対して設定する。「プラン選択が直前まで可能」とは、ユーザが利用予定日までの日数を気にせずにいつでも（例えば、利用予定日の前日まで）多くのプランから一つのプランを申し込むことができることを意味する。
【００９８】
設定部３４は目安日またはメッセージを設定する処理を各対象施設について実行すると、その目安情報を提示部３５に出力する。
【００９９】
提示部３５は、対象施設の予約に関する目安情報、またはプラン選択に関する目安情報をユーザに提供する機能要素である。提示部３５は目安情報を示すウェブページを生成してユーザ端末Ｔに送信し、ユーザ端末Ｔはそのウェブページを表示する。
【０１００】
次に、図１１を用いて、情報提供装置３０の動作を説明するとともに本実施形態に係る情報提供方法について説明する。
【０１０１】
まず、受付部３１がユーザＩＤ、対象施設ＩＤ、および利用予定日を含む検索条件を受け付ける（ステップＳ３１）。続いて、抽出部３２が第１実施形態と同様に各対象施設の過去の予約受付情報を抽出する（ステップＳ３２）。続いて、モード決定部３３が目安情報の種類（モード）を決定する（ステップＳ３３）。モード決定部３３は利用予定日と予約受付日との差分の統計値を求めることで、ユーザが利用の何日前に予約を入れるかの傾向を求める。そして、モード決定部３３はその統計値が所定の閾値未満であれば予約優先モードを選択し、統計値がその閾値以上であればプラン優先モードを選択する。
【０１０２】
予約優先モードの場合には（ステップＳ３３；予約優先）、設定部３４が第１実施形態におけるステップＳ１３〜Ｓ１５と同様の処理を実行し（ステップＳ３４〜Ｓ３６）、提示部３５が目安情報をユーザ端末Ｔに送信する（ステップＳ４０）。
【０１０３】
一方、プラン優先モードの場合には（ステップＳ３３；プラン優先）、設定部３４は、抽出された予約受付情報に基づいて判定対象期間における対象施設のプラン数の変化を求め、この判定対象期間においてそのプラン数が所定の閾値未満に変化した変化日が存在するか否かを判定する（ステップＳ３７）。続いて、設定部３４は変化日の判定結果に基づいて目安情報を設定する（ステップＳ３８）。設定部３４はステップＳ３７，Ｓ３８の処理をすべての対象施設について実行する（ステップＳ３９参照）。最後に、提示部３５が目安情報をユーザ端末Ｔに送信する（ステップＳ４０）。
【０１０４】
次に、図１２を用いて、情報提供装置３０を実現するための情報提供プログラムＰ２を説明する。
【０１０５】
情報提供プログラムＰ２は、メインモジュールＰ１０、受付モジュールＰ２１、抽出モジュールＰ２２、モード決定モジュールＰ２３、設定モジュールＰ２４、および提示モジュールＰ２５を備えている。
【０１０６】
メインモジュールＰ２０は、情報提供機能を統括的に制御する部分である。受付モジュールＰ２１、抽出モジュールＰ２２、モード決定モジュールＰ２３、設定モジュールＰ２４、および提示モジュールＰ２５を実行することにより実現される機能はそれぞれ、上記の受付部３１、抽出部３２、モード決定部３３、設定部３４、および提示部３５の機能と同様である。
【０１０７】
情報提供プログラムＰ２は、第１実施形態における情報提供プログラムＰ１と同様に提供することができる。
【０１０８】
以上説明したように、本実施形態においても、いつまでに施設の利用予約を申し込めばよいかをユーザに提示することできる。加えて、本実施形態ではユーザの予約受付情報に基づいて予約優先とプラン優先という２種類の目安情報を出し分けるので、ユーザの予約傾向に応じた目安情報を提供することができる。
【０１０９】
（第４実施形態）
第４実施形態に係る情報提供システム２は、ユーザに行動のきっかけを与えることを目的として、いつ、どこで、どのような事象があるかをそのユーザに提示し、その上で、施設利用の予約をいつまでに行うのが望ましいのかをさらに提示するコンピュータ・システムである。以下では、第１実施形態と異なる点について特に説明し、第１実施形態と同様の点については説明を省略する。
【０１１０】
情報提供システム２からユーザに提供される画面の一例を図１３に示す。画面Ｍは日本地図と時間軸Ｊを含んでおり、時間軸ＪのスライダＬで示される時期に起こる事象が吹き出しで示される。吹き出しの表示位置はその事象が起こる場所を示す。図１３の例は、８月に、青森県でねぶた祭りが開催され、新潟県で花火大会が開催されることを示している。画面Ｍ内の情報は多くのユーザからのコメントに基づいて生成される。ユーザはこの画面から、いつ、どこで、どのような事象があるかを知ることができる。
【０１１１】
図１４に示すように、情報提供システム２はユーザ端末Ｔ、情報提供装置４０、及びデータベース群（記憶部）２０を備える。データベース群２０は、予約受付データベース２１および施設データベース２２に加えてレビューデータベース２３を備える。
【０１１２】
レビューデータベース２３は、施設の利用者がインターネットを介して投稿したコメントを記憶する装置である。投稿されたコメントはレビュー情報としてレビューデータベース２３に記録される。例えば、ユーザが滞在したホテルの感想を宿泊予約サイトで入力して送信ボタンを押すと、ユーザ端末Ｔが入力データを所定のサーバに送信し、サーバがそのコメントを含むレビュー情報を生成してレビューデータベース２３に格納する。なお、レビュー情報が最終的にレビューデータベース２３に格納されさえすれば、レビュー情報の生成および格納の手順は何ら限定されない。
【０１１３】
本実施形態では、レビュー情報のレコードは以下の項目を含むものとする。ただし、レビュー情報は他の項目を含んでいてもよい。また、後述の処理ではユーザＩＤを用いないので、この項目は省略可能である。
【０１１４】
・投稿者を一意に特定するユーザＩＤ
・投稿者が利用した施設を一意に特定する施設ＩＤ
・投稿者が施設を利用した日（利用日）
・コメント
【０１１５】
図１５に示すように、情報提供装置４０は機能的構成要素として取得部４１、集計部４２、第１提示部（追加の提示部）４３、受付部４４、抽出部４５、設定部４６、および第２提示部４７を備えている。
【０１１６】
取得部４１は、レビューデータベース２３および施設データベース２２を参照して、施設が位置するエリアと、その施設の利用者のコメントに含まれているキーワードと、その利用者による施設の利用日に対応する時期とのセット（以下では単に「セット」という）を取得する機能要素である。取得部４１は、図１３に示すような画面を要求する信号をユーザ端末Ｔから受信したことを契機として以下の処理を実行する。
【０１１７】
まず、取得部４１は処理に必要なレビュー情報のレコードをレビューデータベース２３から読み出す。取得部４１は全レコードを読み出してもよいし、検索条件に合致するレコードのみを読み出してもよい。例えば、取得部４１は利用日が過去の所定の期間内（過去１年以内、過去２年以内、過去半年以内など）であるレコードのみを読み出してもよい。あるいは、取得部４１は特定のエリア（日本国内、東北地方など）にある施設に関するレコードのみを読み出してもよい。あるいは、取得部４１は期間およびエリアの双方の検索条件に合致するレコードを読み出してもよい。レコードの抽出条件はユーザにより指定されてもよく、この場合には、取得部４１はユーザ端末Ｔからその条件を受信すればよい。
【０１１８】
続いて、取得部４１はレビュー情報の各レコードからセットを生成する。以下では、一つのレコードからセットを生成する処理について説明する。
【０１１９】
まず、取得部４１は施設データベース２２を参照して施設の住所を読み出し、その住所に対応するエリアを特定する。取得部４１は住所とエリアとの対応表を予め内部に保持している。取得部４１はこの対応表を用いて施設の住所をエリアに変換し、セットのエリア項目を決定する。例えば施設の位置が「山梨県甲府市…」であり、各都道府県が一つのエリアとして予め定義されているのであれば、取得部４１はエリア項目が「山梨県」であると判定する。
【０１２０】
ここで、セットの一項目として用意されるエリアはある程度の広がりを有する地理的範囲である。例えば、一つのエリアは一つの地方、一つの都道府県、一つの市町村などに対応し得る。もっとも、エリアの広さはこれに限定されず、任意の基準でエリアを設定してよい。例えば、エリア内の施設の数が所定値以上（例えば１０以上）になるように各エリアを定めてもよい。
【０１２１】
また、取得部４１は利用日に対応する時期を特定する。セットの一項目として用意される時期は、ある程度の長さを有する時間範囲である。例えば、一つの時期は一つの月（あるいは特定の年の一つの月）、一つの週（あるいは特定の年の一つの週）、一つの月日（あるいは特定の年の一日）などに対応し得るが、時期の設定方法はこれに限定されない。例えば利用日が「２０１２年８月５日」であり、一つの月が一つの時期として予め定義されているのであれば、取得部４１は時期が「８月」であると判定する。一つの時期が年月で定義されているのであれば、その利用日に対応する時期は「２０１２年８月」である。
【０１２２】
さらに、取得部４１は形態素解析によりコメントからキーワードを抽出する。本実施形態では取得部４１は名詞（「花火」、「紅葉」など）または名詞句（「壮大な花火」「美しい紅葉」）をキーワードとして取得するものとする。ただし、キーワードは行動プランの判断に資する情報として使える語句であればよいので、この要件を満たす限り、キーワードとして抽出する語句の品詞は限定されない。例えばコメントが「ホテルに向かう途中の農園でぶどう狩りを楽しんだ」であれば、取得部４１はこのコメントから「ホテル」「農園」「ブドウ狩り」という名詞を取得する。あるいは、取得部４１は「ホテルに向かう途中の農園」を名詞句として取得してもよい。このように、コメントから抽出されるキーワードは一つとは限らず、複数のキーワードが抽出される可能性がある。一方、コメントが「とても楽しかった」であれば、この中に名詞または名詞句が存在しないので、本実施形態では取得部４１はこのコメントからキーワードを抽出しない。
【０１２３】
続いて、取得部４１は、取得できたキーワードの個数分だけセットを生成する。例えば、エリア「山梨県」および時期「８月」を特定するとともに３個のキーワード「ホテル」「農園」「ブドウ狩り」を得たとする。この場合に取得部４１は、｛山梨県、８月、ホテル｝、｛山梨県、８月、農園｝、｛山梨県、８月、ブドウ狩り｝という３個のセットを生成する。なお、一つのセットを｛エリア、時期、キーワード｝で表す。一つのコメント内に同じキーワードが複数回出現した場合には、取得部４１はそのキーワードについては一つのセットのみを生成する。
【０１２４】
取得部４１はセットを生成すると次のレコードの処理に移る。一つもキーワードを抽出できなかった場合には、取得部４１はセットを生成することなく次のレコードの処理に移る。そして、読み出したすべてのレコードについての処理を終えると、取得部４１は生成したすべてのセットを集計部４２に出力する。
【０１２５】
集計部４２は、エリアおよびキーワードのペア毎にセット数の分布を求める機能要素である。なお、各ペアのセット数は、エリアおよびキーワードの組合せに対応するレビューの個数であるともいえる。
【０１２６】
まず、集計部４２は入力されたセットを、エリアおよびキーワードのペア毎にグループ化する。例えば、集計部４２がエリア「山梨県」およびキーワード「ホテル」のペアについて処理をすると、１以上の｛山梨県、１月、ホテル｝というセットや、1以上の｛山梨県、２月、ホテル｝というセットなどが、ペア｛山梨県、ホテル｝という一つのグループにまとめられる。なお、一つのペアを｛エリア、キーワード｝で表す。
【０１２７】
続いて、集計部４２は各ペアについて、所定の期間における各時期のセット数を集計することで、当該期間におけるセット数の分布を求める。所定の期間および各時期の設定方法は限定されない。例えば、所定の期間を１年間とし各月を各時期としてもよいし、所定の期間を１週間とし各曜日を各時期としてもよい。
【０１２８】
セット数の分布の例を図１６，１７に示す。図１６は、１年間におけるペアＰａ，Ｐｂそれぞれについての各月のセット数を集計してその分布を示したグラフである。図１７では、所定の期間を１年間とし各月を一つの時期として、｛エリアＡ，キーワードＫａ｝、｛エリアＡ，キーワードＫｂ｝という二つのペアについての分布を表で示している。
【０１２９】
集計部４２は各ペアについてのセット数の分布を示すデータを第１提示部４３に出力する。
【０１３０】
第１提示部４３は、バースト時期が存在する、エリアおよびキーワードのペアについての情報を、該バースト時期と関連付けて出力する機能要素である。
【０１３１】
まず、第１提示部４３は各ペアについてバースト時期の有無を判定する。本明細書における「バースト時期」とは、セットの個数が他の時期よりも所定の基準（以下ではこれを「バースト基準」ともいう）以上多い時期である。バースト時期は特定のエリアにおける特定のキーワードの出現頻度が突出して多い時期のことであるともいえる。
【０１３２】
バースト時期の概念を図１６を用いて説明する。ペアＰａについては、７月および８月のセット数が突出しているので、これら二つの時期がバースト時期として設定される。また、このペアＰａについては６月および１１月のセット数も多いので、これら二つの時期もバースト時期として設定される可能性がある。一方、ペアＰｂについては、１年を通してセット数にあまり変化がないので、バースト時期は無いと判定される。
【０１３３】
第１提示部４３は一つのペアにおける各時期について、バースト時期に該当するか否かを判定する。第１提示部４３は判定対象の時期Ｔｘにおけるセット数Ｎｘと、それ以外のｎ個の時期Ｔ１，Ｔ２，…，Ｔｎのセット数の統計値Ｎａとを比較する。そして第１提示部４３は、セット数Ｎｘが統計値Ｎａより所定の基準以上多ければその時期Ｔｘがバースト時期であると判定し、そうでなければその時期Ｔｘはバースト時期でないと判定する。ここで、バースト基準は任意の倍数または百分率により示すことができる（例えば、５倍、１０倍、１５０％など）。統計値の例としては平均値および中央値が挙げられるが、統計値の種類はこれらに限定されない。
【０１３４】
このような判定処理を図１７の例に適用すると以下の通りとなる。なお、バースト基準については５倍と１０倍の２種類を考える。
【０１３５】
まず、ペア｛エリアＡ、キーワードＫａ｝の場合を示す。１月のセット数は４５であり、他の月（２月〜１２月）のセット数の平均値は（５２＋６０＋…＋４７）／１１≒５３．４である。また、他の月のセット数の中央値は５４である。統計値として平均値と中央値のどちらを採用したとしても、１月のセット数はその統計値の５倍でも１０倍でもないから、第１提示部４３は１月がバースト時期でないと判定する。
【０１３６】
２月について見ると、その月のセット数は５２であり、他の月（１月および３月〜１２月）のセット数の平均値は（４５＋６０＋４８＋…＋４７）≒５２．７である。また、他の月のセット数の中央値は５４である。統計値として平均値と中央値のどちらを採用したとしても、２月のセット数はその統計値の５倍でも１０倍でもないので、第１提示部４３は２月もバースト時期でないと判定する。
【０１３７】
ペア｛エリアＡ、キーワードＫａ｝については、３月〜１２月のいずれもバースト時期でない。したがって、第１提示部４３はこのペア｛エリアＡ、キーワードＫａ｝にはバースト時期が存在しないと判定する。
【０１３８】
次に、ペア｛エリアＡ、キーワードＫｂ｝の場合を示すが、ここでは、相対的にセット数が多い７月および８月に限って説明する。
【０１３９】
７月のセット数は１５０であり、他の月のセット数の平均値は約３８．４である。また、他の月のセット数の中央値は１０である。したがって、平均値を採用した場合には、７月のセット数はその平均値の５倍でも１０倍でもないから、第１提示部４３は７月がバースト時期でないと判定する。一方、中央値を採用した場合には、７月のセット数はその中央値の５倍以上でもあり１０倍以上でもあるので、バースト基準がそのどちらであったとしても、第１提示部４３は７月がバースト時期であると判定する。
【０１４０】
８月のセット数は１８０であり、他の月のセット数の平均値は３５．６である。また、他の月のセット数の中央値は１０である。したがって、平均値を採用した場合には、バースト基準を５倍に設定した場合にのみ、第１提示部４３は７月がバースト時期であると判定する。一方、中央値を採用した場合には、バースト基準が５倍であっても１０倍であっても、第１提示部４３は７月がバースト時期であると判定する。
【０１４１】
したがって、第１提示部４３はこのペア｛エリアＡ、キーワードＫｂ｝にはバースト時期が存在すると判定する。ただし、具体的にどの月がバースト時期であるかは、採用する統計値およびバースト基準により変わる。
【０１４２】
第１提示部４３はバースト時期についての判定処理をすべてのペアについて実行する。そして、第１提示部４３は、バースト時期が存在したペアについてのみそのバースト時期を設定し、バースト時期が存在しないペアの情報を棄却する。なお、本明細書では、あるエリアにおいてバースト時期を有するキーワードを「バーストワード」ともいう。
【０１４３】
続いて、第１提示部４３は、バースト時期が存在するペアのデータを用いて、例えば図１３に示すようなウェブページを生成し、このウェブページを応答信号としてユーザ端末Ｔに送信する。ユーザ端末Ｔはそのウェブページを表示し、これによりユーザはいつ、どこで、どのような事象があるのかを知ることができる。
【０１４４】
再び図１３を参照しながら、そのウェブページの機能を説明する。ユーザ操作により時間軸Ｊ上で一つの時期が選択されると、ウェブページのプログラム（以下では「表示制御プログラム」という）はその時期がバースト時期であるペアの情報を表示する。具体的には図１に示すように、表示制御プログラムは、ペアのエリア項目に対応する位置に吹き出しを描画し、その吹き出し内にキーワード（バーストワード）を記述する。なお、エリアとキーワードとの対応を表現する方法は吹き出しに限定されず、他の任意の図形または視覚効果を用いてもよい。
【０１４５】
表示制御プログラムは時間軸上にスライダＬを設定する。ユーザはこのスライダＬを動かすことで時期を変更することができる。この操作が行われると、表示制御プログラムはそれまで表示されていたペアの情報を消去し、変更後の時期がバースト時期であるペアの情報を表示する。なお、時期を変更するためのユーザインタフェースはスライダに限定されず、テキストボックスやラジオボタンなどの他のＧＵＩ（Graphical User Interface）でもよい。
【０１４６】
ユーザは吹き出しをクリックすることで（キーワードを選択することで）、その吹き出し（キーワード）に対応するエリアに位置する施設の目安情報を画面上に表示させることができる。表示制御プログラムは、クリックされた吹き出しに対応するエリアと、現在選択されている時期とを検索条件として情報提供装置４０に送信する。その後、表示制御プログラムはその送信に応じて情報提供装置４０から送られてくる目安情報を受信して、画面Ｍ上にまたは別のウィンドウ上にその目安情報を表示する。例えば、表示制御プログラムは図１のように目安情報を表示する。
【０１４７】
目安情報を生成および提示する処理については、検索条件を受け付ける処理が第１実施形態と異なるが、その後の処理は第１実施形態と同様である。
【０１４８】
受付部４４はユーザ端末Ｔから受信した検索条件で示されるエリアに対応する１以上の施設ＩＤを施設データベース２２から対象施設ＩＤとして読み出す。また、受付部４４は検索条件で示される時期に基づいて利用予定日を決定する。その時期が具体的な日付であれば、受付部４４は検索条件をそのまま利用予定日として得る。その時期が月単位または週単位で示されている場合には、受付部４４は任意の基準で利用予定日を決定してよい。ただし、利用予定日は将来の日付である必要がある。
【０１４９】
例えば、現在日が２０１３年６月１日であり、検索条件の時期が「８月」であれば、受付部４４はその時期の初日（２０１３年８月１日）、その時期の末日（２０１３年８月３１日）、あるいは他の日（２０１３年８月１０日、２０１３年８月１５日など）を利用予定日として設定してもよい。あるいは受付部４４はユーザ端末Ｔに利用予定日の指定を要求し、その要求に応じて送信されてきたデータを受け付けてもよい。受付部４４は対象施設ＩＤおよび利用予定日を取得すると、これらのデータを抽出部４５に出力する。
【０１５０】
抽出部４５、設定部４６、および第２提示部４７の処理は第１実施形態における抽出部１２、設定部１３、および提示部１４の処理と同様である。この一連の処理により、図１のような目安情報がユーザ端末Ｔ上に表示される。
【０１５１】
次に、図１８を用いて、情報提供装置４０がバーストワードの情報をユーザに提示する処理を説明する。
【０１５２】
まず、取得部４１がレビューデータベース２３および施設データベース２２を参照してエリア、キーワード、および時期のセットを取得する（ステップＳ５１）。この処理において、取得部４１はコメントを形態素解析することでキーワードを抽出し、施設情報からエリアを特定し、利用日から時期を特定する。
【０１５３】
続いて、集計部４２が、エリアおよびキーワードのペア毎に、所定の期間におけるセットの個数の分布を求める。
【０１５４】
続いて、第１提示部４３が、バースト時期が存在するか否かを判定する（ステップＳ５２）。第１提示部４３は、判定対象の時期におけるセット数が、それ以外の時期のセット数の統計値より所定の基準以上多ければ、判定対象の時期をバースト時期として設定し、そうでなければ、判定対象の時期はバースト時期でないと判定する。第１提示部４３はこの処理を各ペアについて実行する。
【０１５５】
そして、第１提示部４３は、バースト時期が存在する、エリアおよびキーワードのペアについての情報をユーザに提示する（ステップＳ５３）。この処理において、第１提示部４３は図１３に示すような画面（ウェブページ）をユーザ端末Ｔに送信し、ユーザ端末Ｔはその画面を表示する。この画面はエリアおよびキーワードのペアをバースト時期と関連付けて表示する。したがって、ユーザはこの画面を操作して、いつ、どこで、どのような事象があるかを知ることができる。
【０１５６】
ユーザは、画面内の吹き出しをクリックすることで、その吹き出しに対応するエリア内の施設の目安情報を調べることができる。吹き出しがクリックされた場合の処理手順は第１実施形態と同様なので説明を省略する。
【０１５７】
次に、図１９を用いて、情報提供装置４０を実現するための情報提供プログラムＰ３を説明する。
【０１５８】
情報提供プログラムＰ３は、メインモジュールＰ３０、取得モジュールＰ３１、集計モジュールＰ３２、第１提示モジュールＰ３３、受付モジュールＰ３４、抽出モジュールＰ３５、設定モジュールＰ３６、および第２提示モジュールＰ３７を備えている。
【０１５９】
メインモジュールＰ３０は、情報提供機能を統括的に制御する部分である。取得モジュールＰ３１、集計モジュールＰ３２、第１提示モジュールＰ３３、受付モジュールＰ３４、抽出モジュールＰ３５、設定モジュールＰ３６、および第２提示モジュールＰ３７を実行することにより実現される機能はそれぞれ、上記の取得部４１、集計部４２、第１提示部４３、受付部４４、抽出部４５、設定部４６、および第２提示部４７の機能と同様である。
【０１６０】
情報提供プログラムＰ３は、第１実施形態における情報提供プログラムＰ１と同様に提供することができる。
【０１６１】
以上説明したように、本実施形態においては、いつ、どこで、どのような特徴的な事象が起こるかを提示することで、行動プランの判断に資する情報をユーザに提供することができる。その上で、上記の各実施形態と同様に、いつまでに施設の利用予約を申し込めばよいかをユーザに提示することできる。
【０１６２】
この第４実施形態において、吹き出しに記述されるイベントの開催日を所定のデータベースから取得可能であれば、受付部４４はその開催日以前の日と、当該開催日より後の日（例えば当該開催日の１週間後）とを二つの利用予定日として取得してもよい。この場合には各対象施設について、抽出部４５、設定部４６、および第２提示部４７が、二つの利用予定日のそれぞれの目安情報を生成しユーザ端末Ｔに送信する。この処理により、ある施設について例えば「イベント開催日に予約する場合には２０１３年１１月１０日までに。イベント開催日の一週間後に予約する場合には２０１４年１月５日までに」などという目安情報がユーザに提示される。この場合には、イベントに参加する場合およびイベントを避ける場合の双方についての予約の目安をユーザに提示することができる。
【０１６３】
以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で様々な変形が可能である。
【０１６４】
第３実施形態として示したモード選択処理は、第２および第４実施形態にも適用することができる。また、第４実施形態として示した、ユーザに行動のきっかけを与える手法は、第１〜第３実施形態のいずれにも適用することができる。このように、上記各実施形態は互いに組合せ可能である。
【０１６５】
直前予約が可能であることを示すメッセージの出力、および、利用プランの選択が直前まで可能であることを示すメッセージの出力は共に省略してもよい。すなわち、情報提供装置は予約申込のまたはプラン選択の目安日を設定した場合に限って目安情報をユーザに提供してもよい。
【符号の説明】
【０１６６】
１，２…情報提供システム、１０…情報提供装置、１１…受付部、１２…抽出部、１３…設定部、１４…提示部、２０…データベース群、２１…予約受付データベース、２２…施設データベース、２３…レビューデータベース、３０…情報提供装置、３１…受付部、３２…抽出部、３３…モード決定部、３４…設定部、３５…提示部、４０…情報提供装置、４１…取得部、４２…集計部、４３…第１提示部、４４…受付部、４５…抽出部、４６…設定部、４７…第２提示部、Ｐ１…情報提供プログラム、Ｐ１０…メインモジュール、Ｐ１１…受付モジュール、Ｐ１２…抽出モジュール、Ｐ１３…設定モジュール、Ｐ１４…提示モジュール、Ｐ２…情報提供プログラム、Ｐ２０…メインモジュール、Ｐ２１…受付モジュール、Ｐ２２…抽出モジュール、Ｐ２３…モード決定モジュール、Ｐ２４…設定モジュール、Ｐ２５…提示モジュール、Ｐ３…情報提供プログラム、Ｐ３０…メインモジュール、Ｐ３１…取得モジュール、Ｐ３２…集計モジュール、Ｐ３３…提示モジュール、Ｐ３４…受付モジュール、Ｐ３５…抽出モジュール、Ｐ３６…設定モジュール、Ｐ３７…提示モジュール。
【要約】
一実施形態に係る情報提供装置は受付部、抽出部、設定部、および提示部を備える。受付部は、対象施設の識別子および利用予定日を含む検索条件を受け付ける。抽出部は、施設、利用予定日、および予約受付日を含む予約受付情報を記憶する記憶部を参照して、検索条件の利用予定日に基づく過去の判定対象期間に対応する対象施設の予約受付情報を抽出する。設定部は、抽出された予約受付情報に基づいて過去の判定対象期間における対象施設の初期在庫数からの減少度合を求め、該判定対象期間において在庫数が所定の閾値未満に変化した変化日が存在する場合には、検索条件の利用予定日に施設を利用するための予約申込の目安日を該変化日を用いて設定する。提示部は、設定部により設定された値を予約申込の目安情報として出力する。【図１】
0005394599.tif 000002
【図２】
0005394599.tif 000003
【図３】
0005394599.tif 000004
【図４】
0005394599.tif 000005
【図５】
0005394599.tif 000006
【図６】
0005394599.tif 000007
【図７】
0005394599.tif 000008
【図８】
0005394599.tif 000009
【図９】
0005394599.tif 000010
【図１０】
0005394599.tif 000011
【図１１】
0005394599.tif 000012
【図１２】
0005394599.tif 000013
【図１３】
0005394599.tif 000014
【図１４】
0005394599.tif 000015
【図１５】
0005394599.tif 000016
【図１６】
0005394599.tif 000017
【図１７】
0005394599.tif 000018
【図１８】
0005394599.tif 000019
【図１９】
0005394599.tif 000020