JP6139037B1 - 情報処理装置、情報処理方法、プログラム、記憶媒体 - Google Patents

Abstract

本発明では、天候のため予約プランをキャンセルしたと考えられる場合は、代わりとなるプランを予約者に提供することを目的とする。本実施の形態のウェブサーバ１(情報処理装置)は、天候に関する予報情報である天候予報情報を取得する取得部１ｂと、既予約プランのキャンセル情報を受信した場合、キャンセル情報が天候を理由に送信されたか否かを推定する推定部１ｃと、キャンセル情報が天候を理由に送信されたと推定した場合、取得した天候予報情報に基づいて推奨プランを抽出する抽出部１ｄと、推奨プランを予約者端末２に提示させる提示制御部１ｅと、を備える。

Description

本発明は、情報処理装置、情報処理方法、プログラム、記憶媒体に関し、特に推奨プランを提示するための技術に関する。

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

従来、旅行プランや宿泊プラン、ゴルフプランなどについて、インターネットを介して予約者の希望するプランを予約するといったシステムが知られている。
ゴルフプランについては、上記特許文献１に、携帯端末を用いることでインターネットを介してゴルフプランの予約を場所を選ばず気軽にかつ簡単に行え、その予約結果に関する情報が至る所で常時取得可能となるシステムが開示されている。

ところで、予約されたゴルフプランがキャンセルされた場合、当該キャンセルは予約した予約者の判断によるものであるから、当該予約者はゴルフのプレイをあきらめたとも考えられる。
しかし、予約者の当該キャンセルの要因としては、例えば「ケガをしたため予約の当日にゴルフができなくなった」といったやむを得ないものだけでなく、「予約の当日の天気予報が雨であるため仕方なく断念した」などの要因も多々見受けられる。またこのような要因で予約をキャンセルした予約者は、その原因が解消されればゴルフをプレイしたい予約者であると推測できる。
そこで、本発明では、天候のため予約プランをキャンセルしたと考えられる場合は、代わりとなるプランを予約者に提供することを目的とする。

本発明に係る情報処理装置は、天候に関する予報情報である天候予報情報を取得する取得部と、既予約プランのキャンセル情報を受信した場合、前記キャンセル情報が天候を理由に送信されたか否かを推定する推定部と、前記キャンセル情報が天候を理由に送信されたと前記推定部が推定した場合、前記取得部が取得した天候予報情報を用いて推奨プランを抽出する抽出部と、前記推奨プランを予約者端末に提示させる処理を行う提示制御部と、を備え、前記取得部は、キャンセルされた予約プランのプレイ日、地域における天候予報情報を取得し、前記推定部は、取得された前記天候予報情報があらかじめ設定した条件の天候に該当するか否かの判定結果から、前記キャンセル情報が天候を理由に送信されたか否かを推定するものである。
既予約プランのキャンセル理由が天候であると推定した場合は、予約者は理由となった天候以外の他の天候であればプランを決行したいものと推定できる。そのため当該他の天候のプランを推奨プランとして提供することにより、予約者の当該プランへの予約が期待できる。

上記した情報処理装置においては、前記抽出部は、前記キャンセル情報によってキャンセル対象となった既予約プランであるキャンセルプランに基づいた条件を用いて検索することにより前記推奨プランを抽出することが考えられる。
取得した天候予報情報を用いて抽出したプランから、さらにキャンセルプランに基づいた条件を用いて検索することで推奨プランの絞り込みを行う。

上記した情報処理装置においては、前記条件は、前記キャンセルプランの利用日情報を含むことが考えられる。
取得した天候予報情報を用いて抽出したプランから、さらにキャンセルプランの利用日情報に基づいた条件を用いて検索することで推奨プランの絞り込みを行う。

上記した情報処理装置においては、前記条件は、前記キャンセルプランの移動時間情報を含むことが考えられる。
取得した天候予報情報を用いて抽出したプランから、さらにキャンセルプランの移動時間情報に基づいた条件を用いて検索することで推奨プランの絞り込みを行う。

上記した情報処理装置においては、前記条件は、前記キャンセルプランの検索時の検索クエリを含むことが考えられる。
取得した天候予報情報を用いて抽出したプランから、さらにキャンセルプランの検索時の検索クエリに基づいた条件を用いて検索することで推奨プランの絞り込みを行う。

上記した情報処理装置においては、前記抽出部は、キャンセルプランと他のプランの天候スコアを算出し、前記キャンセルプランと他のプランの天候スコアの比較に基づいて前記推奨プランを抽出することが考えられる。
これにより、より適した天候スコアを有するプランを推奨プランとして提示する。

上記した情報処理装置においては、前記抽出部は、前記理由となった天候要素が少なくとも天気、気温、風速のうちの何れであるかを推定し、前記推定した天候要素の比較に基づいて前記推奨プランを抽出することが考えられる。
キャンセル理由となった天候の詳細な原因を推定し、その原因となった天候要素に基づいて推奨プランを抽出する。

上記した情報処理装置においては、前記抽出部は、天候要素に関する前記キャンセルプランに係る予約者の実績情報を用いて前記推奨プランを抽出することが考えられる。
これにより、予約者が実際にプランを実行したときの天候情報を用いて推奨プランを抽出することができる。

上記した情報処理装置においては、天候要素に関する前記キャンセルプランに係る予約者の実績情報を用いて前記キャンセル情報が天候を理由に送信されたか否かを推定することが考えられる。
予約者が実際にプランを実行したときの天候情報を用いてキャンセル情報が天候を理由に送信されたか否かを推定する。

上記した情報処理装置においては、前記取得部は、天候予報情報を逐次取得し、天候予報情報において前記キャンセルプランに対応する天候予報が変化した場合、前記提示制御部は、前記キャンセルプランを前記予約者端末に提示させる処理を行うことが考えられる。
予約者によりキャンセルされた予約プランであっても、その後天候が回復した場合は、当該予約プランの情報を再び予約者に通知する。

上記した情報処理装置においては、前記提示制御部は、前記推奨プランごとの天候予報情報を前記予約者端末に提示させることが考えられる。
推奨プランを提示するとともに、推奨プランごとの天候予報情報も提示させる。

本発明に係る情報処理方法は、天候に関する予報情報である天候予報情報のうちキャンセルされた予約プランのプレイ日、地域における天候予報情報を取得するステップと、既予約プランのキャンセル情報を受信した場合、前記取得した天候予報情報があらかじめ設定した条件の天候に該当するか否かの判定結果から、前記キャンセル情報が天候を理由に送信されたか否かを推定するステップと、前記キャンセル情報が天候を理由に送信されたと推定した場合、前記取得した天候予報情報を用いて推奨プランを抽出するステップと、前記推奨プランを予約者端末に提示させる処理を行うステップとを情報処理装置が実行する情報処理方法である。
既予約プランのキャンセル理由が天候であると推定した場合は、予約者は理由となった天候以外の他の天候であればプランを決行したいものと推定できる。そのため当該他の天候のプランを推奨プランとして提供することにより、予約者の当該プランへの予約が期待できる。
本発明に係るプログラムは、上記情報処理方法の各ステップとしての処理を情報処理装置に実行させるプログラムである。
本発明に係る記憶媒体は、上記プログラムを記憶した記憶媒体である。
これらのプログラムや記憶媒体により上記の情報処理装置を実現する。

本発明によれば、予約者は、天候を理由としてやむを得ずプランをキャンセルすることになっても、天候の良い他のプランの情報を容易に確認することができる。また、キャンセル理由を天候であると推定し、よりプランに適した天候のプランを推奨プランとして提示することで、予約者の意向をより反映した推奨プランを提案することができる。

実施の形態のネットワークシステムの構成例についての説明図である。 実施の形態のハードウェア構成についての説明図である。 実施の形態のウェブサーバについての説明図である。 実施の形態のユーザデータベースに記憶される情報の一部の説明図である。 実施の形態の天候データベースに記憶される情報の一部の説明図である。 実施の形態のプランデータベースに記憶される情報の一部の説明図である。 実施の形態のゴルフ場データベースに記憶される情報の一部の説明図である。 実施の形態の予約履歴データベースに記憶される情報の一部の説明図である。 実施の形態の天候スコアデータベースに記憶される情報の一部の説明図である。 実施の形態のプレイ実績データベースに記憶される情報の一部の説明図である。 実施の形態の予約者端末に提示される提示画面の説明図である。 実施の形態の予約者端末に提示される提示画面の説明図である。 実施の形態の予約者端末に提示される提示画面の説明図である。 実施の形態の処理の流れの一例を示す説明図である。 実施の形態の処理の流れの一例を示す説明図である。 実施の形態のウェブサーバが実行する処理を示すフローチャートである。 実施の形態のバッチ処理の第１例を示すフローチャートである。 実施の形態のキャンセル理由推定処理の第１例を示すフローチャートである。 実施の形態の推奨プラン抽出処理の第１例を示すフローチャートである。 実施の形態のキャンセル理由推定処理の第２例を示すフローチャートである。 実施の形態の推奨プラン抽出処理の第２例を示すフローチャートである。 実施の形態の推奨プラン抽出処理の第３例を示すフローチャートである。 実施の形態の推奨プラン抽出処理の第４例を示すフローチャートである。 実施の形態の推奨プラン抽出処理の第５例を示すフローチャートである。 実施の形態の推奨プラン抽出処理の第６例を示すフローチャートである。 実施の形態の推奨プラン抽出処理の第７例を示すフローチャートである。 実施の形態の推奨プラン抽出処理の第８例を示すフローチャートである。 実施の形態の推奨プラン抽出処理の第９例を示すフローチャートである。 実施の形態のバッチ処理の第２例を示すフローチャートである。

以下、実施の形態を次の順序で説明する。
＜１．全体構成＞
＜２．サーバの機能構成及びデータベース＞
［２−１．サーバの機能構成］
［２−２．データベース］
＜３．予約者端末の提示画面の概要＞
＜４．ウェブサーバに関する処理＞
［４−１．全体の処理］
［４−２．ウェブサーバの処理］
＜５．他の実施例及び変形例＞
［５−１．キャンセル理由判定処理の第２例］
［５−２．推奨プラン抽出処理の第２例］
［５−３．推奨プラン抽出処理の第３例］
［５−４．推奨プラン抽出処理の第４例］
［５−５．推奨プラン抽出処理の第５例］
［５−６．推奨プラン抽出処理の第６例］
［５−７．推奨プラン抽出処理の第７例］
［５−８．推奨プラン抽出処理の第８例］
［５−９．推奨プラン抽出処理の第９例］
［５−１０．バッチ処理の第２例］
＜６．まとめ＞
＜７．プログラム及び記憶媒体＞

＜１．全体構成＞
図１に実施の形態のネットワークシステムの構成例を示す。この例では、当該ネットワークシステムは、ネットワークを利用してゴルフのプランを予約する予約システムであって、予約プランがキャンセルされた場合に推奨プランを提示する推奨プラン提示システムとして機能する。図１におけるウェブサーバが本発明請求項の情報処理装置の実施の形態に相当する。
なお、以下ではゴルフプランについての予約プランを単に「予約プラン」という。
また予約者とは、ゴルフプラン予約サービスにおいてゴルフプランを予約する人をいい、管理者とは、ゴルフ場を管理する人のことをいう。

図１に示すように、本実施の形態に係るネットワークシステムは、ウェブサーバ１、複数の予約者端末２、複数の管理者端末３、天候情報管理サーバ４がネットワークＮにより相互に通信可能な状態で接続されている。また、ウェブサーバ１は、データベース５にアクセス可能とされている。以下「データベース（Database）」を「ＤＢ」と表記する。

ネットワークＮの構成は多様な例が想定される。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）、通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網などが想定される。
またネットワークＮの全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線などの有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網などの無線でも使用可能である。

ウェブサーバ１は、予約者が希望するゴルフプランを予約し、当該予約プランが天候を理由にキャンセルされた場合、他のプランを推奨プランとして提示するサーバである。
ウェブサーバ１は、予約者端末２や管理者端末３から受信した処理要求に基づく処理を行う。例えば予約者端末２から受信したゴルフプランの予約情報に応じて当該プランを予約する処理、予約者端末２から受信した予約プランのキャンセル情報に応じて当該プランをキャンセルする処理、当該キャンセルしたプランの代わりとなる推奨プランを抽出する処理、予約者端末２に推奨プランの提示画面情報などのウェブページデータを送信する処理、天候情報管理サーバ４に天候情報の送信を要求する処理などを行う。

予約者端末２は、ゴルフプラン予約サービスを利用してゴルフプランの予約や予約したゴルフプランのキャンセルを要求する予約者によって操作される情報処理装置である。
予約者端末２は、ウェブサーバ１から送信された情報を受信する処理を行う。例えばウェブサーバ１から提供されるゴルフプランの予約画面や予約プランのキャンセル画面、推奨プラン提示画面などのウェブページデータを受信し、提示する処理などを行う。
予約者端末２は、例えば通信機能を備えたＰＣ（Personal Computer）やフィーチャーフォンやＰＤＡ（Personal Digital Assistant）、或いはスマートフォンやタブレット端末などのスマートデバイスなどにより実現される。

管理者端末３は、ゴルフプラン予約サービスで提示するためのプラン内容等を新規に提供したり、当該プラン内容等を変更する管理者によって入力操作される情報処理装置である。管理者端末３は、作成、変更したゴルフ内容等の情報をウェブサーバ１に送信し、ウェブサーバ１は受信した当該情報をＤＢに記憶する。
管理者端末３は、例えばある店舗に設置されたコンピュータ装置や、管理者が使用する携帯型或いは据え置き型などの情報処理装置である。

本実施の形態の場合、例えば、ウェブサーバ１ではＨＴＴＰ（Hypertext Transfer Protocol）デーモンが起動される。また予約者端末２ではブラウザが起動され、予約者端末２からは、ブラウザを介して処理要求（ＨＴＴＰリクエスト）がウェブサーバ１に送信される。ウェブサーバ１からは、上記の処理要求に対応する処理結果（ＨＴＴＰレスポンス）が予約者端末２に送信される。例えば、ウェブページ記述言語で記載されたページデータが予約者端末２に送信される。そして、このページデータに基づいて、処理結果に基づくウェブページ（画面）が予約者端末２の提示制御部に提示される。
ウェブサーバ１は、このような動作により予約者端末２へのゴルフプランの予約画面のウェブページデータの送信、予約プランのキャンセル画面のウェブページデータの送信、推奨プラン提示画面のウェブページデータの送信、予約者端末２からの要求に応じた処理などを行う。

これらのウェブページデータは、例えば、ＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible Hyper Text Markup Language）などの構造化文書ファイルである。構造化文書ファイルには、記事などのテキストデータや記事に添付された画像などの画像データと、それらの配置や提示態様（文字色、フォント、大きさ及び装飾など）が記述されている。

天候予報管理サーバ４は、各地の地域の天候予報情報を管理する情報処理装置である。例えば、各地の地域の気象情報を提供している会社が管理しているサーバ装置などである。具体的には、天候予報管理サーバ４は、ウェブサーバ１の天候予報情報の送信要求に応じて、当該天気予報情報をウェブサーバ１に送信する処理などを行う。

ＤＢ５は、ウェブサーバ１が様々な処理を実行するために必要な情報が格納されたＤＢを包括的に示している。ＤＢ５の詳細は後述する。

続いて、図１に示したウェブサーバ１、予約者端末２、管理者端末３、天候予報管理サーバ４、ＤＢ５を構成する情報処理装置のハードウェア構成を図２に示す。ウェブサーバ１、予約者端末２、管理者端末３、天候予報管理サーバ４、ＤＢ５として示した各装置は、情報処理及び情報通信が可能な図２に示すようなコンピュータ装置として実現できる。

図２において、コンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ( Read Only Memory)１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ( Random Access Memory )１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１０１、ＲＯＭ１０２、及びＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インターフェース１０５も接続されている。
入出力インターフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力部１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどよりなる出力部１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、ネットワーク１を介しての通信処理や機器間通信を行う通信部１０９が接続されている。
入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア１１１を介してデータやプログラムを受け渡したりすることが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、ウェブサーバ１、予約者端末２、管理者端末３、天候予報管理サーバ４、ＤＢ５としての必要な情報処理や通信が実行される。
なお、ウェブサーバ１、予約者端末２、管理者端末３、天候予報管理サーバ４、ＤＢ５を構成する情報処理装置は、図２のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮなどによりシステム化されていてもよいし、インターネットなどを使用したＶＰＮなどにより遠隔地に通信可能な状態で配置されたものでもよい。

＜２．サーバの機能構成及びデータベース＞
［２−１．サーバの機能構成］

図３に１又は複数の情報処理装置で構成されるウェブサーバ１としての機能構成を示す。
ウェブサーバ１としての各機能は、情報処理装置においてＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し以下説明する全部又は一部の各構成の処理をハードウェアにより実現してもよい。
また各機能をソフトウェアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。一つのプログラムにより複数の機能の処理が実行されてもよいし、一つの機能が複数のプログラムモジュールの連携で実現されてもよい。

ウェブサーバ１は、予約処理部１ａ、取得部１ｂ、推定部１ｃ、抽出部１ｄ、提示制御部１ｅを有する。

予約処理部１ａは、予約者が予約操作したゴルフプランに応じて、ゴルフプランの予約処理を実行する。具体的には、予約処理部１ａは、予約者端末２から予約情報を受信すると、プランＤＢ５ｃの予約者によって選択されたゴルフプランの予約フラグをオンにし、予約履歴ＤＢ５ｅに当該予約情報を記憶する。予約フラグは、ある予約者が当該プランを予約したか否かを示すフラグである。予約フラグがオンになると、当該プランは予約されたものとみなされる。

取得部１ｂは、天候に関する予報情報である天候予報情報を取得する。具体的には、取得部１ｂは、任意のタイミングに天候予報管理サーバ４に天候予報情報を要求することで、天候予報管理サーバ４から天候予報情報を取得する。
なお、本実施の形態では、取得部１ｂは、天候予報管理サーバ４から天候予報情報を取得するが、インターネット等に公開される情報から、天候予報情報を取得してもよい。
また、天候予報情報は、例えば取得した時から「一週間」や「一月」などある程度先の天候を示す情報である。ただし、当該天候予報情報は、現在以降の天候を示す情報であればよく、現在の天候を含んでいてもよい。

推定部１ｃは、既予約プランのキャンセル情報を受信した場合、キャンセル情報が天候を理由に送信されたか否かを推定する。つまりユーザが天候予報を確認した結果、当日の天候を嫌ってキャンセルしたか否かの推定である。推定部１ｃのキャンセル情報が天候を理由に送信されたか否かを推定する処理の詳細については後述する。

抽出部１ｄは、取得した天候情報に基づいて推奨プランを抽出する。具体的には、抽出部１ｄは、推定部１ｃがキャンセル情報が天候を理由に送信されたと推定した場合に、当該推奨プランの抽出を行う。抽出部１ｄの推奨プランを抽出する処理の詳細については後述する。

提示制御部１ｅは、予約システムを構成する各種ウェブページデータの生成（ＨＴＭＬデータ生成）を行う。例えば提示制御部１ｅは、ログイン画面やプランの予約画面、推奨プランの提示画面などの各種ウェブページデータの生成を行う。そして提示制御部１ｅは、予約者端末２に当該ウェブページデータを送信して提示させる。

［２−２．データベース］

以下、これらの機能を備えたウェブサーバ１が、キャンセル理由の推定や推奨プランの抽出、予約者端末２へのウェブページデータの提示などを行うために用いるＤＢ５について説明する。

ＤＢ５は、例えばユーザＤＢ５ａ、天候ＤＢ５ｂ、プランＤＢ５ｃ、ゴルフ場ＤＢ５ｄ、予約履歴ＤＢ５ｅ、天候スコアＤＢ５ｆ、プレイ実績ＤＢ５ｇ、ウェブページＤＢ５ｈなどで構成される。もちろんこれ以外にもＤＢ５は、インターネットのウェブサーバ１として機能するために必要なＤＢを含んで構成されていてもよい。

ユーザＤＢ５ａには、例えば図４に示すように、ゴルフプランの予約システムを利用するユーザに関するデータが記憶される。ユーザＤＢ５ａには、例えば記憶されたユーザごとに、予約者識別情報であるユーザＩＤ（identification）、ログインのパスワード、住所、氏名、性別や年齢などの属性情報、電子メールアドレスなどが記憶される。
なお、ユーザＤＢ５ａに記憶されるユーザは、例えばウェブサーバ１が提供するゴルフプランの予約などのサービスを受けるために会員登録等をしたユーザなどであり、ユーザＩＤは当該登録に応じて付与されるものとすればよい。ユーザは、ゴルフプランの予約者となり得る人である。

天候ＤＢ５ｂは、例えば図５に示すように、天候予報管理サーバ４から取得した天候予報に関するデータが記憶される。天候ＤＢ５ｂには、例えば記憶された都道府県ごとに、天候予報情報を受信した日時や地域ごとの天候予報情報などが記憶される。天候予報情報の内容としては、例えば「天気」、「気温」、「風速」があげられる。説明上、これらの内容のことを「天候要素」と呼ぶ。「天候」とは、これらの「天気」、「気温」、「風速」等の天候要素の総称として用いている。
また天候予報情報は、例えば都道府県の地域ごとに記憶され、千葉であれば「千葉」、「柏」、「君津」、「館山」、「銚子」などの地域ごとに記憶される。
なお、天候予報情報は天候の予報であり、各種の天候要素の予報を示す情報であればよい。天候要素は「天気」、「気温」、「風速」に限られず、他にも「湿度」、「花粉情報」、「降水確率（降水量）」、「注意報」や台風警報や暴風警報などの「警報」、「噴火情報」、「紫外線情報」、「黄砂情報」など様々な天候要素を用いてもよい。

プランＤＢ５ｃには、各ゴルフ場が提供するプランの内容が記憶される。例えば図６に示すように、例えばゴルフ場ごとのプランに関する情報がゴルフ場ＩＤに紐付けられて記憶される。プランＤＢ５ｃには、例えばプランの識別情報であるプランＩＤ、当該プランのプラン内容、当該プランを予約した予約者の情報である予約者情報、予約フラグなどが記憶される。
なお、プラン内容としては、例えばプレイ日やスタート時間などの日時、料金、一人予約や２サム保証などの予約人数に関するもの、乗用カート付又は歩き、宿泊付、ハーフプレイ又は１．５ラウンドなどのコースの長さ、セルフ又はキャディ付、スループレイか昼食付かなどの条件、早期割引や抽選付き等の期間限定特別プランなどが考えられる。
また、プランＤＢ５ｃには、各プランについて予約済みか否かを示す予約フラグの領域が設けられている。
なお、プランＤＢ５ｃのデータ管理形態は多様に考えられる。必ずしもゴルフ場毎のプランとする必要は無く、例えば日付順に各プランを管理したり、地域毎に各プランを管理するようにしてもよい。
いずれにしてもプランＤＢ５ｃは、地域、日にち、ゴルフ場名、プラン内容、その他の検索条件でプランの検索ができる情報群であればよい。

ゴルフ場ＤＢ５ｄには、例えば図７に示すように、ゴルフ場に関する情報が記憶される。ゴルフ場ＤＢ５ｄには、例えばゴルフ場の識別情報であるゴルフ場ＩＤ、ゴルフ場の名称や所在地などのゴルフ場の属性情報であるゴルフ場属性、コースの難易度などが記憶される。
ゴルフ場属性は、丘陵、林間、河川敷、山岳、シーサイド、高原などの条件である。またコースの難易度は、初級者向け、中級者向け、上級者向けや、難易度「５」〜「１」などの区分である。

予約履歴ＤＢ５ｅには、例えば図８に示すように、予約者のゴルフプランの予約履歴に関する情報が予約者ごとに記憶される。予約履歴ＤＢ５ｅには、例えばプランＩＤ、そのプランについて予約者が予約操作した予約日時、当該予約者が当該プランの予約をキャンセルした場合のキャンセル日時、キャンセル時の天候予報情報等が記憶される。キャンセル時の天候予報情報とは、予約者のキャンセル操作時点において、プレイ当日の天候の予報の情報である。これは、天候予報情報は当日に向けて逐次変化しているが、ユーザがキャンセルを決心したときに、プレイ当日の予報がどのような天候であったかを記憶する。これは天候理由のキャンセルであるか否かの推定に利用する情報である。
また予約履歴ＤＢ５ｅには、検索情報が記憶される。これは、或るプランを予約した時に、予約者がそのプランの閲覧にたどり着くまでの検索条件である。

天候スコアＤＢ５ｆには、例えば図９に示すように、天候要素ごとに天候に対応するスコアが記録される。天候スコアＤＢ５ｆには、例えば天候要素の「天気」については「快晴」、「晴」、「曇り」、「雨」、「雪」についてそれぞれ「５」、「４」、「３」、「２」、「１」の天候スコアが記憶される。この例では、天候スコアの値が高いほどゴルフに適した天候であることを示すものとしている。
なお、天候スコアについては天候要素の重要度に応じて天候スコアの比重を変更してもよい。例えばゴルフをプレイするにあたり、天候要素の「風速」はあまり影響を受けないと考えられる場合は、「風速」については天候スコアを低く設定することとしてもよい。

プレイ実績ＤＢ５ｇには、例えば図１０に示すように、実際に予約者がプレイしたゴルフプランに関する情報が予約者ごとに記憶される。プレイ実績ＤＢ５ｇには、ゴルフ場情報（例えばゴルフ場ＩＤ）、ゴルフ場の所在地の地域、実際にプレイしたプランのプラン内容（スタート時間、キャディ付き、食事付きなどの具体的内容）、プレイ当日の天候情報などが記憶される。
なお、プレイ当日の天候情報は、ウェブサーバ１が天候予報管理サーバ４から取得した現在又は過去の実際の天候情報に基づいて記憶すればよい。

ウェブページＤＢ５ｈには、ゴルフプランの予約サービスを構成する様々なウェブページデータがウェブページのリンク情報（ＵＲＬ）に紐付けられて記憶されている。ウェブページＤＢ５ｈには、例えばログイン画面のウェブページデータやウェブサイトのウェブページデータ、ゴルフプランの予約画面のウェブページデータ、予約プランがキャンセルされた場合の推奨プラン提示画面のウェブページデータなどが記憶される。

以上の各ＤＢを有するＤＢ５は、ウェブサーバ１とは別のサーバコンピュータ内に構築されていてもよいし、ウェブサーバ１内に構築されていてもよい。
また図示及び説明の便宜上、ＤＢ５として示したが、ユーザＤＢ５ａ、天候ＤＢ５ｂ、プランＤＢ５ｃ、ゴルフ場ＤＢ５ｄ、予約履歴ＤＢ５ｅ、天候スコアＤＢ５ｆ、プレイ実績ＤＢ５ｇ、ウェブページＤＢ５ｈの各ＤＢは、ウェブサーバ１がアクセス可能とされていればどのような形態で実現されていてもよい。例えばウェブサーバ１と同一システム内の記憶部に各ＤＢのすべてが形成されていてもよいし、各ＤＢの一部又は全部が別体、遠隔地などのコンピュータシステムに設けられていてもよい。もちろん各ＤＢが一つの装置（例えば一つのＨＤＤなど）内に形成されている必要はない。また各ＤＢのそれぞれが、それぞれ１つのＤＢとして構成される必要もない。例えばユーザＤＢ５ａとして記憶される情報が、複数のユーザＤＢ（例えばログイン用のユーザＤＢと取引用のユーザＤＢなど）により記憶管理されてもよい。実施の形態で説明する上記各ＤＢは、実施の形態の処理に関連する情報の記憶部を、それぞれ１つのＤＢの形態で例示したものに過ぎない。

＜３．予約者端末の提示画面の概要＞

以下本実施の形態の店舗がゴルフプラン予約システムを使用する場合に、ウェブサーバ１によって予約者端末２に提示される画面の一例について図１１乃至図１３を参照して説明する。

図１１を参照して、予約者がゴルフプランを予約する場合に、ウェブサーバ１によって予約者端末２に提示される画面の一例について説明する。

まず予約者端末２には、図１１に示すように、予約者がゴルフプランを予約する画面である予約画面１０が提示される。
予約画面１０は、ゴルフプランのプラン名を表示するプラン名表示エリア１１、ゴルフプランの内容を表示するプラン内容表示エリア１２、ゴルフプランの予約情報を送信する予約送信ボタン１３を有する。

プラン名表示エリア１１には、ゴルフプランごとのプラン名が表示されている。
内容表示エリア１２には、ゴルフプランごとのプラン内容が表示されている。内容表示エリアには、例えば「キャディ付」、「カート付」、「昼食付」などの条件や、「料金」、「プレイ日時」、「人数」などの情報が表示される。このとき「プレイ日時」や「人数」の項目は例えばプルダウンが用いられ、予約者がプルダウンに提示された項目から情報を選択入力することができる。
予約送信ボタン１３は、ゴルフプランを予約するときに、予約情報を送信するために予約者により操作されるボタンである。

予約者は、プラン名表示エリア１１や内容表示エリア１２からプレイしたいゴルフプランを選び、必要に応じて内容表示エリア１２で「プレイ日時」や「人数」を入力し、予約送信ボタン１３を操作(タッチ、クリック、キーボード操作等)することで予約情報をウェブサーバ１に送信する。
その後、図示しないが、予約の処理が適切に行われたか否かの結果画面が予約者端末２に表示される。

図１２及び図１３を参照して、予約者が予約したゴルフプランをキャンセルする場合に、ウェブサーバ１によって予約者端末２に提示される画面の一例について説明する。

予約者端末２には、図１２に示すように、予約者が予約したプランを表示する画面である予約プラン提示画面２０が提示される。予約プラン提示画面２０は、予約したプランの詳細を表示する詳細エリア２１と予約プランのキャンセル情報をウェブサーバ１に送信するキャンセルボタン２２を有する。
詳細エリア２１には、予約者が予約したプランの受付番号、ゴルフ場名、プレイ日時、料金、予約人数などが表示されている。キャンセルボタン２２は、予約者の操作（タッチ、クリック、キーボード操作等）により予約プランをキャンセルするボタンである。
例えば、プレイ当日の天候予報が雨などの理由により予約プランをキャンセルしようとする予約者は、詳細エリア２１で予約プランの詳細を確認し、キャンセルボタンを操作することで予約プランをキャンセルする。

なお、図示しないが、予約プランをキャンセルするにあたり、予約者にキャンセル理由を操作（タッチ、クリック、キーボード操作等）により入力させるエリアを設けてもよい。キャンセル理由としては、「同伴者が集まらなかった」、「用事が入ってしまった」、「他のゴルフ場に変更した」、「日程を変更した」、「天候が良くないから」などが挙げられる。後述するキャンセル理由推定処理において、ウェブサーバ１は、これらの入力されたキャンセル理由に基づいて予約プランのキャンセル理由が天候であるか否かを推定してもよい。

キャンセル操作が行われた場合、予約者端末２では、図１３に示すように、予約者の予約プランのキャンセル処理が完了した旨を表示する画面であるキャンセル完了画面３０が提示される。
このとき、ウェブサーバ１が当該キャンセルの理由が天候であると推定した場合、予約者端末２に提示されるキャンセル完了画面３０には、当該完了した旨の表示に加えて、他のゴルフ場のプランが推奨プランとして提示される。例えばキャンセル完了画面３０には、キャンセルしたプランよりも天気の良い他の地域のゴルフ場が推奨プランとして提示される。
推奨プランについては、例えばゴルフ場、プラン内容、日程、スタート時間、料金などとともに、天候予報情報が表示される。天候予報情報は、例えば天気、気温、風速を示している。これ以外に例えば天気等をマークで表示したり、さらには湿度、紫外線情報、熱中症情報等の各種の天候要素を提示してもよい。
なお、推奨プランの提示画面は、キャンセル完了画面３０と一緒に表示するものに限られず、キャンセル完了画面３０と別の画面に表示してもよいし、次のログイン時など、別の機会に表示されてもよい。また電子メールその他の通信によって推奨プラン情報を送信することも考えられる。
また推奨プランの通知タイミングにおいても、キャンセル完了画面３０と同時に通知するものに限られることはない。例えばキャンセル完了画面３０から他の画面に遷移した後に通知してもよいし、後日、電子メール等によって通知してもよい。

＜４．ウェブサーバに関する処理＞
［４−１．全体の処理］

以下、ウェブサーバ１によるゴルフプランの予約サービスに関する処理例を説明する。なお、以下の説明におけるウェブサーバ１の処理は、図３に示した予約処理部１ａ、取得部１ｂ、推定部１ｃ、抽出部１ｄ、提示制御部１ｅとしての各機能が連携して実行されるものである。

図１４、図１５は、プランの予約が行われる場合と、予約のキャンセルが行われる場合におけるウェブサーバ１と予約者端末２が実行する処理の流れの一例を示している。

まず図１４を参照して、ウェブサーバ１が提供する各種サービスを受けるために、予約者が予約者端末２を用いてログイン操作を行い、ゴルフプランを予約する例を説明する。

ゴルフプラン予約サービスによるサービスを求める予約者は、予約者端末２からウェブサーバ１が提供するウェブサイトにアクセスし、ログイン処理を行う。予約者端末２はステップＳ１１においてログイン要求情報をウェブサーバ１に送信し、ウェブサーバ１側ではステップＳ２１においてログイン処理を行う。例えば新規予約者登録や、すでに登録されている予約者の認証処理などが行われる。

ログイン処理を適正に完了した後、予約者端末２はステップＳ１２においてウェブページデータをウェブサーバ１に要求するウェブページデータ要求処理を行う。これに応じてウェブサーバ１は、ステップＳ２２において、ウェブページデータを予約者端末２に送信するウェブページデータ送信処理を行う。
これにより予約者はウェブページデータを閲覧する。このとき、例えばポータル画面情報の要求やポータル画面情報の送信、詳細ページ情報の要求や詳細ページ情報の送信、ゴルフプランの検索条件情報の送信や検索結果画面情報の送信などが行われる。

そして予約者が予約したいゴルフプランを見つけた場合、予約操作を行う。この場合、予約者端末２は、ステップＳ１３として、予約者が希望するゴルフプランの予約情報をウェブサーバ１に送信する。

続いてステップＳ２３において、当該ゴルフプランの予約情報をウェブサーバ１から受信すると、ウェブサーバ１は、当該ゴルフプランの予約処理を実行する。

次にステップＳ２４において、ウェブサーバ１は、予約が完了した場合、その旨を表示する、例えば図１３のような結果画面のページデータを予約者端末２に送信する。
ステップＳ１４において、予約者端末２は、ウェブサーバ１から受信したページデータに基づいて結果画面を表示する。ユーザは当該画面を閲覧することで、予約内容や予約が行われたか否かについて確認することができる。
なお、何らかの事情で予約が完了できなかった場合、ウェブサーバ１はその旨を表示する結果画面のページデータを予約者端末２に送信し、表示させる。

次に図１５を参照して、予約者が予約者端末２を用いて予約したゴルフプランをキャンセルする場合の処理例を説明する。なお、予約者は予約者端末２を用いてウェブサーバ１が提供するサービスにログインしている状態であるものとする。

まずステップＳ３１において、予約者端末２は、予約プランのキャンセル情報をウェブサーバ１に送信する。
例えば予約者は、キャンセルを行いたい場合は、ゴルフプラン提供サービスのポータルサイトにアクセスし、予約済みプランの提示画面を閲覧する。そしてキャンセルする予約済みプランについてキャンセルボタンを押すなどして入力操作を行う。これに応じて予約者端末２は、ステップＳ３１として予約プランのキャンセル情報をウェブサーバ１に送信することになる。

続いてステップＳ４１において、当該キャンセル情報を受信すると、ウェブサーバ１は予約プランをキャンセルする処理を行う。例えばプランＤＢ５ｃにおいて当該プランの予約フラグをオフとし、閲覧者が予約可能な状態とする。

次にステップＳ４２において、ウェブサーバ１は、受信した当該キャンセル情報が天候を理由に送信されたものであるか否かを推定する。ウェブサーバ１の当該処理の詳細については後述する。

次にステップＳ４３において、当該キャンセル情報が天候を理由に送信されたものであると推定した場合、ウェブサーバ１は、天候ＤＢ５ｂの天候予報情報を参照し、当該天候予報情報に基づいてプランＤＢ５ｃから推奨プランを抽出する。推奨プランを抽出する処理の詳細については後述する。

次にステップＳ４４において、ウェブサーバ１は、抽出した推奨プランを提示する画面（推奨プラン提示画面）のページデータを予約者端末２に送信する。
ステップＳ３２において、予約者端末２は、ウェブサーバ１から受信した当該ページデータに基づいて推奨プラン提示画面を表示する。

以上が、ウェブサーバ１が提供するゴルフプラン予約サービスにおける処理の流れとなる。本実施の形態では、図１５に示したように、キャンセルに応じた他の推奨プランの抽出、提示が行われる。

［４−２．ウェブサーバの処理］

以上のようなゴルフプラン予約サービスを実現するために配信サーバが行う処理の第１例について図１６を参照して説明する。
ウェブサーバ１は、ステップＳ１０１〜Ｓ１０４において、予約者端末２や管理者端末３から送信される予約者や管理者の操作情報などを受信したか否かを判定する。

ステップＳ１０１において、ウェブサーバ１が、プランを予約する画面（予約画面）情報の要求（予約画面情報要求）を予約者端末２から受信したと判定した場合、ウェブサーバ１は、ステップＳ１０１からステップＳ１０５に処理を進める。

ステップＳ１０５において、ウェブサーバ１は、予約者端末２に予約画面情報を送信する。具体的には、ウェブサーバ１は、ウェブページＤＢ５ｈから予約画面の画面情報（ウェブページデータ）を取得し、予約者端末２に当該画面情報を送信する。予約者端末２は、当該画面情報の受信に応じて、予約画面を表示する。
なお、実際には、予約者端末２からの予約画面の要求に至るまでには、ポータルサイトの要求に対する送信、検索条件入力、検索結果ページの送信、プラン詳細ページの送信などが行われ、図１６ではこれらの処理は割愛している。

ステップＳ１０２において、予約者端末２からゴルフプランの予約情報を受信したと判定した場合、ウェブサーバ１は、ステップＳ１０２からステップＳ１０６に処理を進める。
なお、ゴルフプランの予約情報は予約画面１０において、予約者が予約者端末２を操作する（クリック、タップ、タッチ等）ことによって入力された情報である。

ステップＳ１０６において、ウェブサーバ１は、予約者端末２から受信した予約情報に基づいて予約処理を行う。具体的にはウェブサーバ１は、プランＤＢ５ｃにおいて、予約者情報として予約者情報を記憶し、予約したと判定されたプランについての予約フラグをオンにする処理を行う。
なお、このときウェブサーバ１は、管理者端末３へプランの予約情報を通知するようにしてもよい。
またウェブサーバ１は、当該予約者についての予約履歴が生じたため、予約したプランに関する情報を当該予約者に対応させて予約履歴ＤＢ５ｅに記憶する。プランに関する情報は、例えばゴルフ場ＩＤやプレイ日時、プラン内容、検索条件を記憶する。検索条件は、当該プランを検索する際に用いた検索ワードや地域、料金、プレイ内容などの検索に用いる条件である。

ステップＳ１０７において、ウェブサーバ１は、予約完了の結果画面情報送信処理を行う。具体的には、ウェブサーバ１は、ウェブページＤＢ５ｈから予約完了の結果画面の画面情報（ウェブページデータ）を取得し、予約者端末２に当該画面情報を送信する。予約者端末２では当該画面情報を受信することに応じて予約完了画面を表示する。
なお、予約手続の間に他の予約者が先に予約が完了したなどの理由により、適正に予約処理が行われなかった場合、ウェブサーバ１は、予約者端末２に予約ができなかった旨を通知する画面情報を送信する。

ステップＳ１０３において、予約プランのキャンセル情報を予約者端末２から受信したと判定した場合、ウェブサーバ１は、ステップＳ１０３からステップＳ１０８に処理を進める。

ステップＳ１０８において、ウェブサーバ１は、予約プランのキャンセル処理を行う。具体的にはウェブサーバ１は、プランＤＢ５ｃにおいて、予約者情報から予約者情報を消去し、キャンセルしたと判定されたプランに予約フラグをオフにする処理を行う。予約フラグをオフにすることで、当該プランは誰も予約していない状態となる。
また当該キャンセルを行ったプラン及び予約者に関して、予約履歴ＤＢ５ｅの更新を行う。ウェブサーバ１は、上記ステップＳ１０６の予約処理内で、当該予約者について当該プランの予約実績を予約履歴ＤＢ５ｅに記憶させたものであるが、このステップＳ１０８のキャンセル処理ではキャンセル履歴を追加する。即ちキャンセルされた対象のプランについて、予約履歴ＤＢ５ｅにおいてプランＩＤに対応させて、キャンセル日時、キャンセル時の天候予報情報を記憶する。
キャンセル時の天候予報情報について予約履歴ＤＢ５ｅに記憶しておくことで、時間が経過してもキャンセル時にユーザが認識していたプレイ時の天候を把握することができる。これにより、ユーザのキャンセル理由の推定の精度を上げることができる。またこの情報をそのユーザに対する推奨プランの選択に利用できる。例えばどのような天候をユーザが嫌うかを推定する情報となるからである。
なお、このステップＳ１０８の処理内で、ウェブサーバ１は、管理者端末３へ予約のキャンセル情報を通知するようにしてもよい。

次にステップＳ１０９において、ウェブサーバ１は、当該キャンセル理由が天候を理由とするものであるかを推定するキャンセル理由推定処理を行う。キャンセル理由推定処理の詳細については後述する。

次にステップＳ１１０において、当該キャンセルが天候を理由とするものであると推定した場合、ウェブサーバ１は、ステップＳ１１０からステップＳ１１１に処理を進める。

次にステップＳ１１１において、ウェブサーバ１は、当該キャンセルされたプランの代わりとなる代替プランを推奨プランとして抽出する推奨プラン抽出処理を行う。推奨プラン抽出処理については後述する。

次にステップＳ１１２において、ウェブサーバ１は、推奨プラン提示制御処理を行う。具体的には、ウェブサーバ１は、ウェブページＤＢ５ｈから取得したキャンセル完了画面３０の画面情報と抽出した推奨プランの内容に応じて推奨プラン提示画面情報（ウェブページデータ）を生成する。そしてウェブサーバ１は、予約者端末２に推奨プラン提示画面情報を送信する。予約者端末２では当該画面情報を受信することに応じて推奨プラン提示画面表示する。

なお、キャンセル完了画面３０に当該推奨プランを提示する際に、図１３に示したように、天候情報を表示する態様で提示することが考えられる。具体的には、ウェブサーバ１は、推奨プラン提示画面を生成するにあたり、上記に加え、プランＤＢ５ｃの地域情報に紐付けられた天候ＤＢ５ｂの天候情報が表示されるように推奨プラン提示画面情報（ウェブページデータ）を生成する。

これにより、予約者が、推奨プランがキャンセルした予約プランよりも天候が良いことが視覚的に判断しやすくなる。また複数の推奨プランが提示された場合、プランごとの天候情報が視覚的に判断できる結果、表示された推奨プランを比較し、どのプランが最も適しているのかを予約者自身が判断しやすくなるため、予約者の利便性の向上を図ることができる。

ステップＳ１０４において、ウェブサーバ１が、管理者端末３からプラン更新情報を受信したと判定した場合、ウェブサーバ１は、ステップＳ１０４からステップＳ１１３に処理を進める。

次にステップＳ１１３において、ウェブサーバ１は、プランＤＢ更新処理を行う。具体的にはウェブサーバ１は、管理者端末３からのプラン更新情報に応じてプランＤＢ５ｃを更新する。これにより、ゴルフ場の店舗側がプランの内容を新規に提供したり、プラン内容を変更したい場合に、管理者が管理者端末３を操作することにより変更内容を入力することで、ゴルフプラン予約サービスで提供するプラン内容を更新することができる。

ステップＳ１１３のプランＤＢ更新処理の後、或いはステップＳ１０４においてプラン更新情報を受信していないと判定した後、ウェブサーバ１はステップＳ１０１に戻り、ステップＳ１０１〜Ｓ１０４を順に実行することにより、各種処理を継続して行う。

ウェブサーバ１が各処理を実行するために、ウェブサーバ１があらかじめ行っておくことが考えられる処理がいくつかある。ここでは、それらの処理をバッチ処理によって定期的に行う例について、図１７を参照して説明する。

まずステップＳ２０１において、ウェブサーバ１は、天候予報情報取得処理を実行する。具体的には、ウェブサーバ１は、例えば天候予報管理サーバ４に所定の地域の天気予報情報の送信を定期的に要求し、天候予報管理サーバ４から当該天候予報情報を取得する。

次にステップＳ２０２において、ウェブサーバ１は、天候ＤＢ更新処理を行う。具体的には、ウェブサーバ１は、当該取得した天候予報情報を天候ＤＢ５ｂに記憶する。

バッチ処理を実行するタイミングとしては、例えば１時間ごとにバッチ処理を実行することが考えられる。この場合、ウェブサーバ３は、１時間ごとに図１７のステップＳ２０１の天候予報情報取得処理、ステップＳ２０２の天候ＤＢ更新処理を実行する。即ち、天候ＤＢ５ｂが定期的に最新の天候予報情報に更新され、それに基づいてキャンセル理由推定処理や推奨プラン提示処理を行う。これにより、キャンセル理由が天候であるか否かの判定の信頼性が高まる。また予約者に対してより天候予報の信頼度が高い推奨プランを提示することができる。
なお、バッチ処理を実行する間隔については特に限定されることはなく、例えば１日ごとや１０分ごと等に設定することが考えられる。

図１６のステップＳ１０９で行うキャンセル理由推定処理（Ｓ４２、Ｓ１０９）の第１例について図１８を参照して説明する。
ウェブサーバ１は、予約者端末２からキャンセル情報が天候を理由に送信されたか否かを図１８に示す処理を実行することにより推定する。

まずステップＳ３０１において、ウェブサーバ１は、キャンセルプランの天候予報情報を取得する処理を行う。具体的にはウェブサーバ１は、予約履歴ＤＢ５ｅを参照し、キャンセル時において最新の天候予報情報であって、キャンセルされた予約プランのプレイ日、地域における天候予報情報を取得する。

次にステップＳ３０２において、ウェブサーバ１は、取得した天候予報情報が予約プランのキャンセルの理由であるか否かを判定する。当該キャンセルが天候が原因と推認できる天候は、例えば天気であれば「雨」、「雪」、「霧」、気温であれば「１０度以下」、「３０度以上」、風速であれば「１０ｍ／ｓ以上」などである。例えばこれらの条件を、天候理由としてのキャンセルと推定できる条件として設定しておく。
ウェブサーバ１は、取得した天候予報情報が当該あらかじめ設定した条件の天候に該当するかを判定する。例えばウェブサーバ１は、当該取得した天候予報情報が「雨」であれば、予約者端末２からキャンセル情報が天候を理由に送信されたと推定する。
なお、本実施の形態ではキャンセル天候情報を天気、気温、風速としているが、キャンセル天候情報は天気、気温、風速に限られず、湿度や降水確率、警報などでもよく、湿度であれば「８０％以上」、降水確率であれば「８０％以上」、「警報、注意報」であれば「波浪警報」、「台風警報」、「高温注意報」などであってもよい。またこれらの天候は「雨」、「気温１０度以下」のように単独で設定してもよいし、「雨かつ気温１０度以下」、「気温３０度以上かつ湿度８０％以上」のように２以上の天候予報情報を組み合わせて設定してもよい。

取得した天候予報情報が当該あらかじめ設定した天候に該当すると判定した場合、ステップＳ３０３において、ウェブサーバ１は、予約者端末２からキャンセル情報が天候を理由に送信されたと推定する。
取得した天候予報情報が当該あらかじめ設定した天候に該当しないと判定した場合、ステップＳ３０４において、ウェブサーバ１は、予約者端末２からキャンセル情報が天候を理由に送信されたものではないと推定する。
なお、キャンセル操作時に予約者にキャンセル理由を求めるようにした場合、その理由の回答が天候によるものであるか否かということを天候理由であるか否かの推定に用いてもよい。例えば図１８の天候理由推定と合わせてアンド条件又はオア条件として用いる。

次に推奨プラン抽出処理（Ｓ４４、Ｓ１１１）の第１例について図１９を参照して説明する。
ウェブサーバ１は、キャンセル情報が天候を理由に送信されたと推定した場合、取得した天候予報情報に基づいて図１９に示す処理を実行することにより推奨プランを抽出する。

ステップＳ４０１において、ウェブサーバ１は、ゴルフに適した天候予報情報を有するプランである好適プランを抽出する。具体的にはウェブサーバ１は、あらかじめ設定しておいたゴルフに適した天候予報情報に該当する地域を最新の天候ＤＢ５ｂから取得し、当該取得した地域の予約プランを好適プランとしてプランＤＢ５ｃから取得する。
ゴルフに適した天候は、例えば天気であれば「晴」、気温であれば「２０度〜３０度」、風速であれば「４ｍ／ｓ以下」などがゴルフプラン予約サービス上であらかじめ設定されている。
なお、ゴルフに適した天候は天気、気温、風速に限られず、湿度や降水確率などでもよく、湿度であれば「４０％〜６０％」、降水確率であれば「２０％以下」などであってもよい。またこれらの天候は「晴」、「気温２０度〜３０度」のように単独で設定してもよいし、「曇りかつ降水確率２０％以下」、「気温２０度〜３０度かつ湿度４０％〜６０％」のように２以上の天候予報情報を組み合わせて設定してもよい。
また好適プランの抽出にあたっては、天候の条件に加えてキャンセルした利用日程と同じ日のプランを抽出することとしてもよい。またキャンセルしたプランと同地域、或いはキャンセルしたプランとユーザの自宅からゴルフ場までの移動時間が同程度のプランを抽出してもよい。ウェブサーバ１は、当該処理をプランＤＢ５ｃを参照することで行う。
またキャンセルプランと同日、或いは自宅からの移動距離が同程度のプランなどを条件として抽出する場合、天候がキャンセルプランと似ていることが多いと想定される。そこで、天候条件を緩くすることが考えられる。例えばキャンセルプランの予報が「雨」の場合に、「曇り」や「曇り時々小雨」なら、好適プランに加えるような例である。

次にステップＳ４０２において、ウェブサーバ１は、好適プランを推奨プランと設定する。このように抽出された推奨プランが図１６のステップＳ１１２の処理で予約者端末２において提示される。

以上、第１の実施の形態としての処理を説明したが、処理の具体例は各種考えられる。
キャンセル理由推定処理（Ｓ１０９）、推奨プラン抽出処理（Ｓ１１１）、推奨プラン提示制御処理（Ｓ１１２）は、ステップＳ１０８のキャンセル処理に続いて実行される例としたが、これらを別の時点に行ってもよい。例えばキャンセル操作から所定時間後であったり、当該予約者の次のログイン時などである。即ち、キャンセル後であればいつでもよい。

＜５．他の実施例及び変形例＞
［５−１．キャンセル理由推定処理の第２例］
キャンセル理由推定処理（Ｓ４２、Ｓ１０９）の第２例について図２０を参照して説明する。なお、図１８と同様の処理については同一符号を付し、説明を省略する。

まずステップＳ３０１において、ウェブサーバ１は、予約履歴ＤＢ５ｅからキャンセルプランの天候予報情報、即ちキャンセル時におけるプレイ日の該当地域の天候予報情報を取得する。なお、図１６のステップＳ１０９としてキャンセル処理直後に実行する場合は、現在が「キャンセル時」であるため、現在のプレイ日の該当地域の天候予報情報を天候ＤＢ５ｂから取得すればよい。

次にステップＳ３１１において、ウェブサーバ１は、キャンセルした予約者のプレイ実績の天候情報を取得する。具体的にはウェブサーバ１は、プレイ実績ＤＢ５ｇから当該予約者のプレイ実績情報を取得する。特にこの場合は、実際にプレイしたときの天候情報を取得する。例えば天候情報として、プレイした日の「天気」、「気温」、「風速」などの天候要素の情報を取得する。

次にステップＳ３１２において、ウェブサーバ１は、取得したキャンセルプランの天候予報情報の天候要素がプレイ実績の天候情報の天候要素に全てが実績として残されているか否かについて判定する。
例えばキャンセルプランについての天候予報が「雨」「気温１８度」「風速１ｍ」であった場合に、その予約者の過去の実績として、「雨」「気温１８度前後」「風速１ｍ前後」のものが存在するか否かを確認する。

ウェブサーバ１は、一部が実績として含まれていない場合は、ステップＳ３１２からステップＳ３０３に処理を進め、ウェブサーバ１は、予約者端末２からキャンセル情報が天候を理由に送信されたと推定する。
例えば予報が「雨」であって、当該予約者が、過去に「雨」のときにはプレイしていない場合、その予約者は「雨」を嫌って天候理由でキャンセルしたと推定する。

またウェブサーバ１は、全てが実績としてある場合は、ステップＳ３１２からステップＳ３０３に処理を進め、ウェブサーバ１は、予約者端末２からキャンセル情報が天候を理由に送信されたものでないと推定する。
例えば予報が「雨」であっても、当該予約者が、過去に「雨」のときにもプレイしているのであれば、その予約者は「雨」を苦にしないとして、天候以外の理由でキャンセルしたと推定する。

即ち実績情報は、当該キャンセルした予約者が、どのような天候の場合に、ゴルフをプレイしているかを示すため、例えば「雨でも平気」「３０度以上だとプレイしない」などといった、個人毎の天候に対する傾向を推定する材料となる。例えば予報が「雨」でも、ユーザによってキャンセル理由となったり、ならなかったりする。本例では、このような点を考慮して、ユーザの傾向に応じたキャンセル理由推定が可能となる。
なお、この例では、取得したキャンセルプランの天候予報情報の内容がプレイ実績の天候情報に全て含まれている場合には、天候理由のキャンセルではないと推定することとしたが、これに限られない。例えば３つの天候要素のうち２つが含まれていれば天候理由ではないとしてもよい。
またキャンセルプランの天候予報情報とプレイ実績の天候情報のそれぞれに天候スコアＤＢ５ｆに基づいて天候スコアを算出し、算出した天候スコアの比較に基づいてキャンセル理由が天候であるか否かについて判断してもよい。この場合、例えばそれぞれの天候について平均スコアを比較し、キャンセルプランの天候予報情報の平均スコアがプレイ実績の天候情報の平均スコアよりも高いときにはキャンセル理由が天候であると推定する。

［５−２．推奨プラン抽出処理の第２例］

推奨プラン抽出処理（Ｓ４４、Ｓ１１１）の第２例について図２１を参照して説明する。なお、図１９と同様の処理については同一符号を付し、説明を省略する。
ウェブサーバ１は、キャンセル情報が天候を理由に送信されたと推定した場合、取得した天候予報情報に基づいて図２１に示す処理を実行することにより推奨プランを抽出する。

まずステップＳ４０１において、ウェブサーバ１は、図１９の第１例の場合と同様に好適プランを抽出する。
次にステップＳ４１１において、ウェブサーバ１は、キャンセルプランの検索条件を取得する処理を行う。具体的にはウェブサーバ１は、予約履歴ＤＢ５ｅから、当該キャンセルを行った予約者が、当該プランを予約した時に用いた検索情報を取得する。記憶されている検索情報は、例えば地域、プレイ日時、料金、乗用カート付、キャディ付、宿泊、昼食付やスループレイなどのプレイスタイル、ハーフプレイや１．５ラウンド等のコースの長さ、丘陵、林間、山岳等のコースタイプなどである。また検索情報として、キャンセルプランの検索時の検索クエリもある。
またその中でも、プラン日時等のプランの利用日情報を検索条件とすることが望ましい。また例えば予約したゴルフ場までの移動時間情報を検索条件とすることも考えられる。

次にステップＳ４１２において、ウェブサーバ１は、当該取得した検索条件を今回の検索条件に設定する。
次にステップＳ４１３において、ウェブサーバ１は、ステップＳ４０１で抽出した好適プランのうちで、当該設定した条件に該当するプランを抽出し、推奨プランとする。従って、キャンセルプランの検索時と同じ検索条件でヒットした推奨プランが、好適プランのうちから抽出される。
このように得られた推奨プランが例えば図１６のステップＳ１１２の処理で予約者端末２において提示される。

［５−３．推奨プラン抽出処理の第３例］

推奨プラン抽出処理（Ｓ４４、Ｓ１１１）の第３例について図２２を参照して説明する。なお、図１９と同様の処理については同一符号を付し、説明を省略する。
ウェブサーバ１は、キャンセル情報が天候を理由に送信されたと推定した場合、取得した天候予報情報に基づいて図２２に示す処理を実行することにより推奨プランを抽出する。

まずステップＳ４０１において、ウェブサーバ１は、好適プランを抽出する。
次にステップＳ４２１において、ウェブサーバ１は、予約履歴ＤＢ５ｅからキャンセルプランのプラン内容の条件を取得する処理を行う。具体的にはウェブサーバ１は、予約履歴ＤＢ５ｅからキャンセルプランのプラン内容の条件情報を取得する。プラン内容の条件は、例えば地域、プレイ日時、料金、乗用カート付、キャディ付、宿泊、昼食付やスループレイなどのプレイスタイル、ハーフプレイや１．５ラウンド等のコースの長さ、丘陵、林間、山岳等のコースタイプなど様々な条件が考えられる。

次にステップＳ４２２において、ウェブサーバ１は、当該取得したプラン内容の条件を再度検索するための条件に設定する。例えば予約者がキャンセルしたプランの内容が「キャディ付、昼食付、宿泊」であった場合、ウェブサーバ１は、「キャディ付、昼食付、宿泊」の条件を用いて推奨プランを抽出する。
次にステップＳ４２３において、ウェブサーバ１は、好適プランから当該設定した条件に該当するプランを推奨プランとして抽出する。従って、キャンセルプランのプラン内容と同様のプラン内容の推奨プランが、好適プランのうちから抽出される。

［５−４．推奨プラン抽出処理の第４例］

推奨プラン抽出処理（Ｓ４４、Ｓ１１１）の第４例について図２３を参照して説明する。なお、図１９と同様の処理については同一符号を付し、説明を省略する。
ウェブサーバ１は、キャンセル情報が天候を理由に送信されたと推定した場合、取得した天候予報情報に基づいて図２３に示す処理を実行することにより推奨プランを抽出する。

まずステップＳ４０１において、ウェブサーバ１は、好適プランを抽出する。
次にステップＳ４１１において、ウェブサーバ１は、キャンセルプランの検索条件を取得する処理を行う。
次にステップＳ４１２において、ウェブサーバ１は、当該取得した検索条件を再度検索するための条件に設定する。
次にステップＳ４１３において、ウェブサーバ１は、好適プランから当該設定した条件に該当するプランを第１プランとして抽出する。
ここまでは図２１の処理と同様である。図２１の処理の際に推奨プランとしたものが、この例では第１プランとなる。

ステップＳ４３１において、ウェブサーバ１は、第１プランが複数抽出されたか否かについて判定する。第１プランが複数のプランを有する場合、ウェブサーバ１は、ステップＳ４３１からステップＳ４２１に処理を進める。
第１プランが複数のプランを有しない場合、ウェブサーバ１は、ステップＳ４３１からステップＳ４３４に処理を進め、第１プランを推奨プランと設定する。

ステップＳ４２１において、ウェブサーバ１は、キャンセルプランのプラン内容の条件を取得する処理を行う。
次にステップＳ４２２において、ウェブサーバ１は、当該取得したプラン内容の条件を再度検索するための条件に設定する。
次にステップＳ４２３において、ウェブサーバ１は、第１プランから当該設定した条件に該当するプランを第２プランとして抽出する。

ステップＳ４３２において、ウェブサーバ１は、第２プランを有するか否かについて判定する。第２プランを有する場合、ウェブサーバ１は、ステップＳ４３２からステップＳ４３３に処理を進め、ステップＳ４３３において第２プランを推奨プランと設定する。
第２プランを有しない場合、ウェブサーバ１は、ステップＳ４３２からステップＳ４３４に処理を進め、第１プランを推奨プランと設定する。
ステップＳ４２１〜Ｓ４２３は図２２と同様の処理である。従って、この例の場合、第２プランは、キャンセルプランの検索条件が同一（第１プラン）のうちで、さらにプラン内容も合致しているものとなる。
このような第２プラン、もしくは第１プランが１つの場合や、第２プランに該当するプランが存在しないは、第１プランが、推奨プランとされることになる。

［５−５．推奨プラン抽出処理の第５例］

推奨プラン抽出処理（Ｓ４４、Ｓ１１１）の第５例について図２４を参照して説明する。

まずステップＳ５０１において、ウェブサーバ１は、キャンセルプランについてのキャンセル時の天候予報情報から天候要素ごとの天候スコアを算出する。具体的には、ウェブサーバ１は、予約履歴ＤＢ５ｅから取得した天候予報情報の天候要素ごとの天候スコアを、天候スコアＤＢ５ｆの情報を用いて算出する。例えば天候予報情報の天候要素が天気「雪」、気温「２０度」、風速「５ｍ／ｓ」とすると、それぞれの天気スコアは「１」、「５」、「３」となる（図９参照）。

次にステップＳ５０２において、ウェブサーバ１は、当該算出した天候スコアから一番良くない天候スコアの天候要素を抽出する。例えば上述の例でいうなら、天候予報情報の中で一番天候スコアが低いのは「１」である。そこで天候スコアが「１」の天候要素「雪」をキャンセルの理由であるとして抽出する。

次にステップＳ５０３において、ウェブサーバ１は、同日の他のプランについても天候スコアを算出し、キャンセルプランの天候スコアと比較する。そしてウェブサーバ１は、キャンセルプランについての最も低い天候スコアよりも高いスコアを有する他のプランを推奨プランとして抽出する。例えば、ウェブサーバ１は、天候スコアが「１」より高い天候要素である「雨（２）」、「曇り（３）」、「晴（４）」、「快晴（５）」のプランを推奨プランとしてプランＤＢ５ｃから抽出する。

［５−６．推奨プラン抽出処理の第６例］

推奨プラン抽出処理（Ｓ４４、Ｓ１１１）の第６例について図２５を参照して説明する。

まずステップＳ５１１において、ウェブサーバ１は、キャンセルプランについてのキャンセル時の天候予報情報から天候要素ごとの天候スコアを算出し、天候要素全体の合計スコアを算出する。具体的には、ウェブサーバ１は、予約履歴ＤＢ５ｅから取得した天候予報情報の天候要素ごとの天候スコアを、天候スコアＤＢ５ｆの情報を用いて算出し、天候要素全体の合計スコアを算出する。例えば天候予報情報の天候要素が天気「雪」、気温「２０度」、風速「５ｍ／ｓ」とすると、それぞれの天気スコアは「１」、「５」、「３」となり、天候要素全体の天候スコアの合計値である合計スコアは「９」となる（図９参照）。

次にステップＳ５１２において、ウェブサーバ１は、同様に他のプランの天候予報情報から天候要素ごとの天候スコアを算出し、天候要素全体の合計スコアを算出する。具体的には、ウェブサーバ１は、プランＤＢ５ｃから取得した天候予報情報の天候要素ごとの天候スコアを、天候スコアＤＢ５ｆから算出し、天候要素全体の合計スコアを算出する。

次にステップＳ５１３において、ウェブサーバ１は、当該抽出した天候要素において当該天候スコアの合計スコアよりも高い合計スコアを有するプランを推奨プランとして抽出する。
例えばある他のプランの天候予報情報の天候要素が天気「快晴」、気温「２７度」、風速「７ｍ／ｓ」とすると、それぞれの天気スコアは「５」、「４」、「３」となり、天候要素全体の合計スコアは「１２」となる（図９）。この場合、他のプランの合計スコア「１２」はキャンセルプランの合計スコア「９」よりも高いため、当該プランは推奨プランとしてプランＤＢ５ｃから抽出する。
またある他のプランの天候予報情報の天候要素が天気「雨」、気温「７度」、風速「１２ｍ／ｓ」とすると、それぞれの天気スコアは「２」、「２」、「２」となり、天候要素全体の合計スコアは「６」となる（図９）。この場合、他のプランの合計スコア「６」はキャンセルプランの合計スコア「９」よりも低いため、当該プランは推奨プランとして抽出しない。

［５−７．推奨プラン抽出処理の第７例］

推奨プラン抽出処理（Ｓ４４、Ｓ１１１）の第７例について図２６を参照して説明する。

まずステップＳ５２１において、ウェブサーバ１は、キャンセルプランについてのキャンセル時の天候予報情報から天候要素ごとの天候スコアを算出し、天候要素全体の平均値を算出する。具体的には、ウェブサーバ１は、予約履歴ＤＢ５ｅから取得した天候予報情報の天候要素ごとの天候スコアを、天候スコアＤＢ５ｆの情報を用いて算出し、天候要素全体の平均値を算出する。例えば天候予報情報の天候要素が天気「雨」、気温「２０度」、風速「５ｍ／ｓ」とすると、それぞれの天気スコアは「１」、「５」、「３」となり、天候要素全体の平均値は「３」となる（図９参照）。

次にステップＳ５２２において、ウェブサーバ１は、同様に他のプランの天候予報情報から天候要素ごとの天候スコアを算出し、天候要素全体の平均値を算出する。具体的には、ウェブサーバ１は、プランＤＢ５ｃから取得した天候予報情報の天候要素ごとの天候スコアを、天候スコアＤＢ５ｆから算出し、天候要素全体の天候スコアの平均値である平均スコアを算出する。

次にステップＳ５２３において、ウェブサーバ１は、当該抽出した天候要素において当該天候スコアの平均値よりも高い平均値を有するプランを推奨プランとして抽出する。
例えばある他のプランの天候予報情報の天候要素が天気「快晴」、気温「２７度」、風速「７ｍ／ｓ」とすると、それぞれの天気スコアは「５」、「４」、「３」となり、天候要素全体の平均スコアは「４」となる（図９参照）。この場合、他のプランの平均スコア「４」はキャンセルプランの平均スコア「３」よりも高いため、当該プランは推奨プランとしてプランＤＢ５ｃから抽出する。
またある他のプランの天候予報情報の天候要素が天気「雨」、気温「７度」、風速「１２ｍ／ｓ」とすると、それぞれの天気スコアは「２」、「２」、「２」となり、天候要素全体の平均スコアは「２」となる（図９）。この場合、他のプランの平均スコア「２」はキャンセルプランの合計スコア「３」よりも低いため、当該プランは推奨プランとして抽出しない。

［５−８．推奨プラン抽出処理の第８例］
推奨プラン抽出処理（Ｓ４４、Ｓ１１１）の第８例について図２７を参照して説明する。

まずステップＳ６０１において、ウェブサーバ１は、キャンセルの理由となった天候要素を判定する。例えばウェブサーバ１は、キャンセルプランの天候予報情報に基づいて天候要素ごとに天候スコアを算出する。そしてウェブサーバ１は、当該算出した天候スコアのなかで最も天候スコアの低い天候要素をキャンセルの理由となった天候要素と判定する。
なお、キャンセルの理由となった天候要素を判定するにあたり、予約者の過去の予約履歴情報におけるキャンセル時の天候予報情報を参照してキャンセル理由を判定してもよい。例えば過去の予約履歴情報に、天気が「雨」の場合は既予約プランをキャンセルする傾向があると判断できるときは、他の天候要素よりも「雨」を優先して理由となった天候情報を天気と判定してもよい。また予約者の実績情報を参照することもできる。例えば天候が「雨」であったとしても、実績情報に「雨」でも参加する傾向が見受けられるときは、キャンセルされた理由から「天気」を除いて他の天候要素が理由であるとして判定してもよい。

次にステップＳ６０２において、ウェブサーバ１は、ステップＳ６０１の処理に基づいてキャンセル理由となった天候要素が天気であるか否かを判定する。

キャンセル理由となった天候要素が天気であった場合、ウェブサーバ１は、ステップＳ６０２からステップＳ６０３に処理を進める。
ステップＳ６０３において、ウェブサーバ１は、キャンセル理由となった天気以外の天気のプランを抽出する。
例えば、キャンセル理由となった天気が「雪」であった場合は「雪」以外の天気である「雨」、「曇り」、「晴れ」などの天気のプランを抽出する。

キャンセル理由となった天候要素が天気でない場合、ウェブサーバ１は、ステップＳ６０２からステップＳ６０４に処理を進める。
次にステップＳ６０４において、ウェブサーバ１は、ステップＳ６０１の処理に基づいてキャンセル理由となった天候要素が気温であるか否かを判定する。

キャンセル理由となった天候要素が気温であった場合、ウェブサーバ１は、ステップＳ６０４からステップＳ６０５に処理を進める。
ステップＳ６０５において、ウェブサーバ１は、キャンセル理由となった気温以外の気温のプランを抽出する。
例えば、キャンセル理由となった気温が「０度〜１０度」であった場合は「０度〜１０度」以外の気温である「１０度〜２０度」、「２０度〜３０度」、「３０度以上」などの天気のプランを抽出する。

キャンセル理由となった天候要素が気温でない場合、ウェブサーバ１は、ステップＳ６０４からステップＳ６０６に処理を進め、ウェブサーバ１は、キャンセル理由となった風速以外の風速のプランを抽出する。
例えば、キャンセル理由となった風速が「１５ｍ／ｓ」であった場合は「１５ｍ／ｓ」未満の風速であるプランを抽出する。

なお、本実施の形態では天気、気温、風速を例として説明したが、それらの天候要素に限られることなく、湿度や降水確率、花粉情報など様々な天候要素を用いることが考えられる。
またキャンセル理由となった天候要素以外の天候要素のプランを抽出する際に、天候要素の条件に加えてキャンセルした利用日程と同じ日のプランを抽出することとしてもよいし、キャンセルしたプランの自宅からゴルフ場までの移動時間が同程度のプランを抽出してもよい。ウェブサーバ１は、当該処理をプランＤＢ５ｃを参照することで行う。

［５−９．推奨プラン抽出処理の第９例］
推奨プラン抽出処理（Ｓ４４、Ｓ１１１）の第９例について図２８を参照して説明する。

まずステップＳ７０１において、ウェブサーバ１は、天候に関する実績情報を取得する。具体的にはウェブサーバ１は、プレイ実績ＤＢ５ｇから実際に予約者がプレイした天候についての情報を取得する。

次にステップＳ７０２において、ウェブサーバ１は、プレイ実績ＤＢ５ｇから取得した天候に関する実績情報に基づいて推奨プランの抽出条件を設定する。
例えば「天気」が「雨」であるにも関わらず、予約をキャンセルせずにプレイすることが多い予約者には抽出条件に「雨」を追加してもよい。また「気温」がどの気温であっても満遍なくプレイをしている予約者については抽出条件から「気温」を除外してもよい。またいつも「気温」が「２０度〜３０度」の日にプレイしている予約者については「気温」について「２０度〜３０度」であることを抽出条件に加えることができる。
このように、ウェブサーバ１は、予約者の天候ごとのプレイ実績情報に基づいて抽出条件を設定する。

次にステップＳ７０３において、ウェブサーバ１は、設定した抽出条件に基づいてプランＤＢ５ｃから推奨プランを抽出する。

［５−１０．バッチ処理の第２例］
バッチ処理の第２例について図２９を参照して説明する。なお、図１７と同様の処理については同一符号を付し、説明を省略する。

まずステップＳ２０１において、ウェブサーバ１は、天候予報情報取得処理を実行し、ステップＳ２０２において、天候ＤＢ更新処理を行う。ここまでは第１例と同様である。

次にステップＳ２１１において、ウェブサーバ１は、前回のバッチ処理で記憶した天候情報よりも天候が好転している地域を特定する。具体的には、ウェブサーバ１は、天候予報情報管理サーバ４から受信した天候予報情報に基づいて天候ＤＢ５ｂを更新するときに、天候が好転している地域情報を取得する。
天候情報が好転しているか否かは、あらかじめゴルフをプレイするのによい天候と悪い天候を設定しておき、天候ＤＢ５ｂを更新するときに悪い天候から良い天候に変化している場合は天候が好転していると判定することが考えられる。例えば良い天候を「快晴」、「晴」に、悪い天気を「雨」、「雪」に設定する。このときウェブサーバ１は、天候ＤＢ５ｂを更新するときに、天候予報情報が「雨」から「晴」などに変化した場合、天候が好転したと判定する。
またウェブサーバ１は、天候スコアＤＢ５ｆを用いて、天候ＤＢ５ｂを更新するときの天候スコアの比較によって天候が好転しているか否かを判定することも考えられる。具体的にはウェブサーバ１は、天候ＤＢ５ｂを更新するときに、更新前と更新後の天候予報情報の天候スコアを算出し、それらの比較によって天候が好転しているか否かを判定する。例えばウェブサーバ１は、天候予報情報の中で一番天候スコアが低い天候要素「雪」を抽出し、更新後の天候スコアが「雪（１）」より高い天候要素である「雨（２）」、「曇り（３）」、「晴（４）」、「快晴（５）」であった場合は、天候が好転したと判定する。

次にステップＳ２１２において、ウェブサーバ１は、全ユーザについてそれぞれ予約履歴ＤＢ５ｅから当該取得した地域情報、つまり天気が好転した地域情報を有する予約プランのうちキャンセルを行ったプランを抽出する。
つまりユーザ毎に、予約履歴ＤＢ５ｅにおいてキャンセル日時が記憶されているプランを確認し、そのプランの地域（ゴルフ場の場所）をプランＤＢ５ｃ、ゴルフ場ＤＢ５ｄ等を参照しながら確認する。また他の予約者によって予約されていないこと（予約フラグがオフであること）も確認する。
そして、ユーザ毎に、過去にキャンセルしたプランであって、そのプランが好転した地域のゴルフ場であって現在も予約可能であることを確認できたら、そのプランを推奨プランとして抽出する。
なおさらに、この場合、天候理由によってキャンセルされたと推定されていたことも抽出の条件に加えることが望ましい。

ステップＳ２１３においては、ウェブサーバ１は、当該抽出したプランを推奨プランとしてユーザ毎に提示制御する。
即ち、ユーザがいったんキャンセルしたプランについて、天候予報が好転した場合に、そのプランを当該ユーザに提案する処理を行うものである。
例えばキャンセルしたユーザに対して電子メールで通知を行ったり、当該ユーザが次にログインしたときに、ウェブページ上に表示したり、プッシュ通知を行ったりする。

＜６．まとめ＞

以上の実施の形態では、次のような効果が得られる。
本実施の形態のウェブサーバ１(情報処理装置)は、天候に関する予報情報である天候予報情報を取得する取得部１ｂを有する。またウェブサーバ１は、既予約プランのキャンセル情報を受信した場合、キャンセル情報が天候を理由に送信されたか否かを推定する推定部１ｃを有する。またウェブサーバ１は、キャンセル情報が天候を理由に送信されたと推定した場合、取得した天候予報情報を用いて推奨プランを抽出する抽出部１ｄを有する。またウェブサーバ１は、推奨プランを予約者端末２に提示させる処理を行う提示制御部１ｅを有する（図１５乃至図１９）。
既予約プランのキャンセル理由が天候であると推定した場合は、予約者は理由となった天候以外の他の天候であればプランを決行したいものと推定できる。そのため当該他の天候のプランを推奨プランとして提供することで、予約者の当該プランへの予約が期待できる。
これにより、予約者は、天候を理由としてやむを得ずプランをキャンセルすることになっても、天候の良い他のプランの情報を容易に確認することができる。
また、キャンセル理由を天候であると推定し、よりプランに適した天候のプランを推奨プランとして提示することで、予約者の意向をより反映した推奨プランを提案することができる。またその結果、予約者は効率的に代わりとなるプランを取得することができる。
例えばゴルフプランにおいて、天候が原因となってプランをキャンセルする予約者は、天気さえ良ければゴルフをプレイしたい人であり、その予約者にその原因が解消している代替プランを提供することは予約者にとって有益である。また本来余っていたプランを効率的に予約者に利用してもらうことができるためゴルフ場の管理人からしても有益である。また予約プランをキャンセルしたものの再度予約を取り直そうとする予約者にとっても推奨プランを提示することは有益である。
さらに、予約者のキャンセル理由の要因を解消する形で代わりとなるプランを推奨することで、予約者の予約の可能性を高めることができる。またその結果、予約者に対する推奨プランの提案回数を減らすことが可能となり、情報処理装置の処理負担を軽減することができる。

またウェブサーバ１（抽出部１ｄ）は、キャンセル情報によってキャンセル対象となった既予約プランであるキャンセルプランに基づいた条件を用いて検索することにより推奨プランを抽出する（図２１乃至図２３）。
取得した天候予報情報を用いて抽出したプランから、さらにキャンセルプランに基づいた条件を用いて検索することで推奨プランの絞り込みを行う。
従って、例えばキャンセルプランを予約した際に、当該予約したプランの検索条件や、当該予約したプランの内容を用いて推奨プランを提示することで、天候予報情報だけでなく、予約者がプランを予約する際に基準となった条件を用いて絞り込みを行うことで、より予約者の意向を反映させた推奨プランを提示することが可能となる。

また推奨プランを検索するために用いるキャンセルプランに基づいた条件は、キャンセルプランの利用日情報を含む（図２１乃至図２３）。
取得した天候予報情報を用いて抽出したプランから、さらにキャンセルプランの利用日情報に基づいた条件を用いて検索することで推奨プランの絞り込みを行う。
推奨プランを提示するにしても、プランを予約したユーザは、その日が都合が良いから予約したのであって、他の日では仕事や学校、行事などの理由により予約できないことも考えられる。また、土日が休日で都合の良い人がいる反面、平日が休みの人もいる。従って、天候予報情報だけでなく、利用日情報を用いて絞り込みを行うことで、例えば土日が休日の人には土日のプラン、毎週平日の木曜日が休みの人にはその日のプランといったように、予約者の都合のよい日を推奨プランとして提供することができる。こうして、より一層予約者の意向を反映させた推奨プランを提示することが可能となる。

また推奨プランを検索するために用いるキャンセルプランに基づいた条件は、キャンセルプランの移動時間情報を含む（図２１乃至図２３）。
取得した天候予報情報を用いて抽出したプランから、さらにキャンセルプランの移動時間情報に基づいた条件を用いて検索することで推奨プランの絞り込みを行う。
天候が良ければプランを予約したいという場合であっても、移動時間等の関係で現実的に再度の予約が困難な場合が考えられる。例えば東京に住んでいる予約者が、東京近郊のプランをキャンセルしたにも関わらず、推奨プランとして沖縄のプランを提案された場合などである。こういった場合、本来予定していたゴルフ場と同じくらいの移動時間、距離の範囲のプランを提案したほうが、キャンセルした予約者にとって便利であるし、提案されたプランを再度予約する可能性も高まる。本件においては、千葉や埼玉、神奈川などが推奨プランとして提示されると考えられる。
従って、予約者が当初想定していた移動時間の範囲内で代わりのプランを推奨することで、より一層予約者の意向を反映させた推奨プランを提示するが可能となる。

また推奨プランを検索するために用いるキャンセルプランに基づいた条件は、キャンセルプランの検索時の検索クエリを含む（図２１、図２３）。 取得した天候予報情報を用いて抽出したプランから、さらにキャンセルプランの検索時の検索クエリに基づいた条件を用いて検索することで推奨プランの絞り込みを行う。
予約者の予約プランを予約するために用いた検索クエリは、予約にあたってのユーザの希望を反映しているものと考えられる。従って、予約者が予約時にプランの検索に用いた検索クエリを用いることで、予約者の希望がより反映されたプランを推奨プランとして提供することができる。これにより、予約者の利便性の向上を図ることができる。

またウェブサーバ１（抽出部１ｄ）は、キャンセルプランと他のプランの天候スコアを算出し、キャンセルプランと他のプランの天候スコアの比較に基づいて推奨プランを抽出する（図２４乃至図２６）。
これにより、より適した天候スコアを有するプランを推奨プランとして提示する。
天候スコアに基づいて推奨プランを抽出することで、天候の良し悪しの基準が明確となり、より一貫性のある推奨プランの提示が可能となる。

またウェブサーバ１（抽出部１ｄ）は、理由となった天候要素が少なくとも天気、気温、風速のうちの何れであるかを推定し、推定した天候要素の比較に基づいて推奨プランを抽出する（図２７）。
キャンセル理由となった天候の詳細な原因を推定し、その原因となった天候要素に基づいて推奨プランを抽出する。
従って、より詳細な天候要素を用いてゴルフプランを推奨することで、より一層予約者の意向を反映させた推奨プランを提示することが可能となる。

またウェブサーバ１（抽出部１ｄ）は、天候要素に関するキャンセルプランに係る予約者の実績情報を用いて推奨プランを抽出する（図２８）。
これにより、予約者が実際にプランをプレイしたときの天候情報を用いて推奨プランを抽出する。
プランを決行するか否かの判断は、予約者それぞれの裁量に委ねられている部分であり、予約者ごとに基準が異なるものである。例えば、雨が降るといっただけで決行することをあきらめる予約者もいれば、例え雨であっても小雨くらいであれば気にせず決行する予約者もいる。従って、例えばゴルフプランにおいて、天候が「雨」であっても多少の雨ならプレイする予約者であれば、「雨」も推奨プランの検索条件に追加するといったように、予約者の過去のプレイ状況に応じた推奨プランを提示することが可能となり、予約者ごとに適したプランを推奨プランとして提案することができる。

またウェブサーバ１（推定部１ｃ）は、天候要素に関するキャンセルプランに係る予約者の実績情報を用いてキャンセル情報が天候を理由に送信されたか否かを推定する（図２０）。
予約者が実際にプランを実行したときの天候情報を用いてキャンセル情報が天候を理由に送信されたか否かを推定する。
上述の通り、プランを決行するか否かの判断は、予約者それぞれの裁量に委ねられている部分であるため、プランをキャンセルした理由が天候であるか否かも予約者によって基準が異なるものである。
従って、プランにおいて、過去の実績情報を確認したときに、天候が「雨」であっても多少の雨なら決行するする予約者であれば、「雨」をキャンセル理由の天候とは推定しないといったように、予約者の過去のプレイ状況に応じてキャンセル理由となる天候の基準を変更することが可能となる。これにより、より正確にキャンセル理由が天候であるか否かについて推定することができる。

またウェブサーバ１（取得部１ｂ）は、天候予報情報を逐次取得し、天候予報情報においてキャンセルプランに対応する天候予報が変化した場合、ウェブサーバ１（提示制御部１ｅ）は、キャンセルプランを予約者端末２に提示させる処理を行う（図２９）。
予約者によりキャンセルされた予約プランであっても、その後天候が回復した場合は、当該予約プランの情報を再び予約者に通知する。
従って、本来予約者がプレイしたかったが天候が悪天候だったためにやむを得ずキャンセルしたプランについて、天候が回復したことを通知することで、再び予約者に当該キャンセルした予約プランを予約する機会を設けることができる。これにより予約者のキャンセルしたプランを調べる手間を省くことができ、より一層の予約者の利便性の向上を図ることができる。また、プランの管理人からしても、結果的にプランが決行される可能性が高まることで、空きプランが生じることを減らすことができる。

またウェブサーバ１（提示制御部１ｅ）は、推奨プランごとの天候予報情報を予約者端末２に提示させる（図１３、図１６）。
推奨プランを提示するとともに、推奨プランごとの天候予報情報も提示させる。
従って、予約者は推奨されたプランの予約を決める際に、天候予報情報を参考にしながら予約するプランを選ぶことができる。また提示された推奨プランが複数ある場合は、それぞれの推奨プランを比較しながらプランを予約することができ、予約者の選択の幅を広げ、予約者の利便性を向上させることができる。

なお、本実施の形態においては、プラン予約サービスの一例としてゴルフプランを用い、ゴルフプラン予約システムとして説明したが、本発明の予約システムはゴルフプランに限られることはなく、所定の事項に関するプランであれば特に限定されることはない。プランとしては、例えば旅行プランや宿泊プラン、ウェディングプラン、食事プラン、スポーツ観戦プランなど各種予約プランが挙げられる。

また推奨プラン抽出処理の第１例〜第９例は、それぞれを組み合わせることも可能である。例えば第５例と第２例の組み合わせが考えられる。この場合、まず第５例の処理でキャンセルプランについてのキャンセル時の天候予報情報から天候要素ごとの天候スコアを算出し、キャンセルプランについての最も低い天候スコアよりも高いスコアを有するプランを他のプランの中から絞り込む。その後、第２例の処理を行うことで、予約者がプランを予約したときに用いた検索条件によって、当該絞り込んだプランから推奨プランを抽出することが考えられる。
このように、推奨プラン抽出処理の第１例〜第９例は、様々な組み合わせが考えられる。

＜７．プログラム及び記憶媒体＞

以上、本発明の情報処理装置の実施の形態としてのウェブサーバ１を説明してきたが、実施の形態のプログラムは、ウェブサーバ１における少なくとも予約処理部１ａ、取得部１ｂ、推定部１ｃ、抽出部１ｄ、提示制御部１ｅの処理を情報処理装置（ＣＰＵなど）に実行させるプログラムである。

実施の形態のプログラムは、天候に関する予報情報である天候予報情報を取得する機能を情報処理装置に実行させる。また既予約プランのキャンセル情報を受信した場合、キャンセル情報が天候を理由に送信されたか否かを推定する機能を情報処理装置に実行させる。またキャンセル情報が天候を理由に送信されたと推定した場合、取得した天候予報情報を用いて推奨プランを抽出する機能を情報処理装置に実行させる。また推奨プランを予約者端末２に提示させる処理を行う機能を情報処理装置に実行させる。
即ちこのプログラムは、ウェブサーバ１に対して図１４〜図２９で説明した処理を実行させるプログラムである。

このようなプログラムにより、上述したウェブサーバ１としての情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置などの機器に内蔵されている記録媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭなどに予め記録しておくことができる。或いはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記録媒体に、一時的或いは永続的に格納（記録）しておくことができる。またこのようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記録媒体からパーソナルコンピュータなどにインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。

最後に、上述した各実施の形態の説明は本発明の一例であり、本発明は上述の実施の形態に限定されることはない。このため、上述した各実施の形態以外であっても、本発明に係る技術的思想を逸脱しない範囲であれば、設計などに応じて種々の変更が可能であることはもちろんである。

Ｎ…ネットワーク、１…ウェブサーバ、２…予約者端末、３…管理者端末、４…天候情報管理サーバ、５…ＤＢ、１ａ…予約処理部、１ｂ…取得部、１ｃ…推定部、１ｄ…抽出部、１ｅ…提示制御部

Claims (14)

1. 天候に関する予報情報である天候予報情報を取得する取得部と、
   既予約プランのキャンセル情報を受信した場合、前記キャンセル情報が天候を理由に送信されたか否かを推定する推定部と、
   前記キャンセル情報が天候を理由に送信されたと前記推定部が推定した場合、前記取得部が取得した天候予報情報を用いて推奨プランを抽出する抽出部と、
   前記推奨プランを予約者端末に提示させる処理を行う提示制御部と、を備え、
   前記取得部は、キャンセルされた予約プランのプレイ日、地域における天候予報情報を取得し、
   前記推定部は、取得された前記天候予報情報があらかじめ設定した条件の天候に該当するか否かの判定結果から、前記キャンセル情報が天候を理由に送信されたか否かを推定する
   情報処理装置。
2. 前記抽出部は、前記キャンセル情報によってキャンセル対象となった既予約プランであるキャンセルプランに基づいた条件を用いて検索することにより前記推奨プランを抽出する
   請求項１に記載の情報処理装置。
3. 前記条件は、前記キャンセルプランの利用日情報を含む
   請求項２に記載の情報処理装置。
4. 前記条件は、前記キャンセルプランの移動時間情報を含む
   請求項２に記載の情報処理装置。
5. 前記条件は、前記キャンセルプランの検索時の検索クエリを含む
   請求項２に記載の情報処理装置。
6. 前記抽出部は、キャンセルプランと他のプランの天候スコアを算出し、前記キャンセルプランと他のプランの天候スコアの比較に基づいて前記推奨プランを抽出する
   請求項１に記載の情報処理装置。
7. 前記抽出部は、前記理由となった天候要素が少なくとも天気、気温、風速のうちの何れであるかを推定し、前記推定した天候要素の比較に基づいて前記推奨プランを抽出する
   請求項１に記載の情報処理装置。
8. 前記抽出部は、天候要素に関するキャンセルプランに係る予約者の実績情報を用いて前記推奨プランを抽出する
   請求項１に記載の情報処理装置。
9. 前記推定部は、天候要素に関するキャンセルプランに係る予約者の実績情報を用いて前記キャンセル情報が天候を理由に送信されたか否かを推定する
   請求項１に記載の情報処理装置。
10. 前記取得部は、天候予報情報を逐次取得し、
    天候予報情報においてキャンセルプランに対応する天候予報が変化した場合、
    前記提示制御部は、前記キャンセルプランを前記予約者端末に提示させる処理を行う
    請求項１に記載の情報処理装置。
11. 前記提示制御部は、前記推奨プランごとの天候予報情報を前記予約者端末に提示させる
    請求項１に記載の情報処理装置。
12. 天候に関する予報情報である天候予報情報のうちキャンセルされた予約プランのプレイ日、地域における天候予報情報を取得するステップと、
    既予約プランのキャンセル情報を受信した場合、前記取得した天候予報情報があらかじめ設定した条件の天候に該当するか否かの判定結果から、前記キャンセル情報が天候を理由に送信されたか否かを推定するステップと、
    前記キャンセル情報が天候を理由に送信されたと推定した場合、前記取得した天候予報情報を用いて推奨プランを抽出するステップと、
    前記推奨プランを予約者端末に提示させる処理を行うステップとを
    情報処理装置が実行する情報処理方法。
13. 天候に関する予報情報である天候予報情報のうちキャンセルされた予約プランのプレイ日、地域における天候予報情報を取得する機能と、
    既予約プランのキャンセル情報を受信した場合、前記取得した天候予報情報があらかじめ設定した条件の天候に該当するか否かの判定結果から、前記キャンセル情報が天候を理由に送信されたか否かを推定する機能と、
    前記キャンセル情報が天候を理由に送信されたと推定した場合、前記取得した天候予報情報に基づいて推奨プランを抽出する機能と、
    前記推奨プランを予約者端末に提示させる機能とを
    情報処理装置に実行させるプログラム。
14. 天候に関する予報情報である天候予報情報のうちキャンセルされた予約プランのプレイ日、地域における天候予報情報を取得する機能と、
    既予約プランのキャンセル情報を受信した場合、前記取得した天候予報情報があらかじめ設定した条件の天候に該当するか否かの判定結果から、前記キャンセル情報が天候を理由に送信されたか否かを推定する機能と、
    前記キャンセル情報が天候を理由に送信されたと推定した場合、前記取得した天候予報情報に基づいて推奨プランを抽出する機能と、
    前記推奨プランを予約者端末に提示させる機能とを
    情報処理装置に実行させるプログラムを記憶した記憶媒体。

Images