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

Abstract

ユーザごとの適切なタイミングで情報を提供することを目的とする。このために、情報処理装置は、ユーザごとの推薦プランを抽出するプラン抽出部と、ユーザの予約実績に基づいて前記推薦プランを提示する推薦時間帯を決定する時間帯決定部と、前記推薦プランとして新たな推薦プランが抽出されたことに応じて、前記推薦時間帯に前記新たな推薦プランをユーザに提示するプラン提示部と、を備える。

Description

本発明は、情報処理装置、情報処理方法、プログラム、記憶媒体に関し、具体的には、ユーザへ情報を提示する際の提示タイミングの技術に関する。

特開２００２−３４２３７０号公報

ユーザの嗜好情報に基づいて、ユーザに最適なプランを提示する技術が知られている。例えば、特許文献１では、ユーザの嗜好情報に適合した推薦情報やコンテンツを提供するための技術が記載されている。
嗜好情報は、例えば、ユーザの予約実績を分析することによって得ることができる。

ところが、ユーザの嗜好に適合した情報であっても、情報を送信するタイミングによっては、ユーザの興味を引くことが出来ない場合や、プランの利用に至らない場合がある。
そこで、本発明はこのような状況を考慮し、ユーザごとの適切なタイミングで情報を提供することを目的とする。

本発明に係る情報処理装置は、ユーザごとの推薦プランを抽出するプラン抽出部と、ユーザの予約実績に基づいて前記推薦プランを提示する推薦時間帯を決定する時間帯決定部と、前記推薦プランとして新たな推薦プランが抽出されたことに応じて、前記推薦時間帯に前記新たな推薦プランをユーザに提示するプラン提示部と、を備えるものである。
情報処理装置。
これにより、ユーザごとに抽出された推薦プランが、ユーザにとって都合のよい時間帯に提示される。

上記した情報処理装置の前記プラン提示部は、前記推薦時間帯において、プランに係るプラン関連ページをユーザが閲覧中であると判定された場合に前記提示を行うことが望ましい。
ユーザがプラン詳細ページや予約ページなどのウェブページを閲覧している状態は、プランに対する関心が高い状態と推測できる。このような状態において、推薦プランが提示される。

上記した情報処理装置の前記プラン提示部は、前記推薦時間帯において、プランに係るプラン関連ページに配置されたプラン検索用語入力欄がアクティブになったことに応じて前記提示を行うことが望ましい。
ユーザがプラン詳細ページや予約ページなどのウェブページを閲覧している状態は、プランに対する関心が高い状態と推測できる。更に、そのようなウェブページにおいてプラン検索を行うための検索用語入力欄がアクティブになった状態は、プランに対する関心が更に高い状態と推測できる。このような状況において、推薦プランが提示される。

上記した情報処理装置の前記プラン提示部は、前記推薦プランの内容に応じて決定された時期における前記推薦時間帯に前記提示を行うことが望ましい。
これにより、推薦プランに応じて提示すべき時期を適切に設定することが可能となる。

上記した情報処理装置の前記プラン提示部は、ユーザの予約実績または利用実績の頻度に応じて決定された時期における前記推薦時間帯に前記提示を行うことが望ましい。
これにより、プランの予約または利用の実績に基づいて提示すべき時期を適切に設定することが可能となる。

本発明に係る情報処理方法は、ユーザごとの推薦プランを抽出するプラン抽出ステップと、ユーザの予約実績に基づいて前記推薦プランを提示する推薦時間帯を決定する時間帯決定ステップと、前記推薦プランとして新たな推薦プランが抽出されたことに応じて、前記推薦時間帯においてプランに係るプラン関連ページをユーザが閲覧中であると判定された場合に前記新たな推薦プランをユーザに提示するプラン提示ステップと、を情報処理装置が実行するものである。
この情報処理方法により、ユーザごとの適切なタイミングで情報を提供するための処理が実行される。

本発明に係るプログラムは、上記情報処理方法として実行する処理を演算処理装置に実行させるプログラムである。
本発明に係る記憶媒体は、上記プログラムを記憶した記憶媒体である。

本発明によれば、ユーザごとの適切なタイミングで情報を提供することができる。

本発明の実施の形態の全体の構成を示す図である。 本実施の形態のプラン提示装置のブロック図である。 本実施の形態のコンピュータのブロック図である。 履歴ＤＢに記憶される情報の一例を示す図である。 第１の実施の形態についてのフローチャートである。 推薦時間帯算出処理のフローチャートである。 第２の実施の形態についてのフローチャートである。 第３の実施の形態についてのフローチャートである。 第４の実施の形態についてのフローチャートである。 第５の実施の形態についてのフローチャートである。 第６の実施の形態についてのフローチャートである。

本実施の形態においては、ユーザに提示される情報として、当該ユーザにお勧めするゴルフプランの情報を例に挙げる。また、情報処理装置として、プランを提示するプラン提示装置１を例に挙げる。
以下、実施の形態を次の順序で説明する。

＜１．全体構成＞
＜２．ハードウェア構成＞
＜３．ＤＢ＞
［３−１．ユーザＤＢ］
［３−２．提供者ＤＢ］
［３−３．プランＤＢ］
［３−４．予約ＤＢ］
［３−５．履歴ＤＢ］
［３−６．ウェブページＤＢ］
＜４．処理の流れ＞
［４−１．第１の実施の形態］
［４−２．推薦時間帯算出処理］
［４−３．第２の実施の形態］
［４−４．第３の実施の形態］
［４−５．第４の実施の形態］
［４−６．第５の実施の形態］
［４−７．第６の実施の形態］
＜５．まとめ＞
＜６．プログラム＞

＜１．全体構成＞

本実施の形態としてのプラン提示装置１を含むネットワークシステム全体の構成について、図１及び図２を用いて説明する。
図１に示すように、本実施の形態のプラン提示装置１は、通信ネットワーク２を介して、プランの閲覧や予約等を行うユーザが利用するユーザ端末３，３，３，・・・と、プランを提供するプラン提供者が利用する提供者端末４，４，４，・・・と相互に通信可能な状態で接続されている。

プラン提示装置１は、通信ネットワーク２を利用して提示されるプランに関する各種の機能を提供する情報処理装置である。
具体的には、提供者端末４から受信したプラン情報を管理する機能を備える。また、管理しているプランからユーザが所望するプランを検索する機能や、検索結果として抽出されたプラン情報をユーザ端末３を利用するユーザへ提示する機能を備える。更に、プランの予約を受け付ける機能や、予約情報を管理する機能を備える。
更に、管理しているプランの販売が成立した際の代金のやりとりを仲介する決済処理機能や、ユーザ端末３や提供者端末４へ各種の通知を行う機能を備える。
更にまた、プラン提供者の情報やユーザの情報を管理する機能を備える。

そして、プラン提示装置１は、上記の各種機能を実現するためのユーザインタフェースとしてのウェブページを他の情報処理装置（例えばユーザ端末３）上に表示させるために、ウェブページデータの生成と送信を行う。
ウェブページデータは、例えば、ＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible HyperText Markup Language）などの構造化文書ファイルである。構造化文書ファイルには、プランの説明などのテキストデータやプランに関する画像などの画像データと、それらの配置や表示態様（文字色やフォントや大きさや装飾など）が記述されている。
ウェブページとしては、例えば、ユーザにログイン情報を入力させるためのログインページや、プランの検索を行うための検索ページや、プランの詳細情報を表示するためのプラン詳細ページなどである。
また、プラン提示装置１は、ユーザやの認証機能や各種データベースへの情報の登録機能、各種データベースから情報を取得する機能などを備える。

更に、プラン提示装置１は、ユーザにリコメンドする推薦プランの情報を提供する。具体的には、ユーザの嗜好情報などの属性情報に基づいてユーザに推薦プランを選択して提示する。そのためにプラン提示装置１が備える各部については後述する。

通信ネットワーク２の構成は特に限定されるものではなく、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（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）、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。

図２を参照して、プラン提示装置１が備える各部の説明を行う。
プラン提示装置１は、プラン抽出部１ａ、時間帯決定部１ｂ、プラン提示部１ｃを備える。
プラン抽出部１ａは、ユーザに提示する推薦プランを抽出する処理を実行する。推薦プランは、ユーザによって入力された各種ユーザ情報や履歴情報から推定した嗜好情報に基づいて抽出される。履歴情報は、例えば、ユーザの閲覧履歴、予約履歴、利用履歴等である。

時間帯決定部１ｂは、ユーザの予約実績に基づいて、ユーザに推薦プラン情報を提示するのに最適な時間帯を推薦時間帯として決定する処理を実行する。推薦時間帯としては、例えば、日付情報や曜日情報を含めずに定められた時間の幅（例えば、２０時〜２２時など）であってもよいし、日付情報や曜日情報を含めて定められた時間の幅（例えば、日曜日の１８時〜１９時や、水曜日の１２時〜１３時や、休日の２２時〜２３時など）であってもよい。また、日付情報や曜日情報のみによって定められた時間の幅（例えば、日曜日終日や、土曜日から日曜日や、毎月１０日など）であってもよい。

プラン提示部１ｃは、時間帯決定部１ｂが決定した推薦時間帯において、プラン抽出部１ａが抽出した推薦プランをユーザに提示する処理を実行する。このとき、推薦時間帯であっても、推薦プランが抽出されなければ提示処理は行わない。
尚、提示処理を行う条件として、他の条件が付加される例についても後述する。

これまで説明してきた各種機能を実現するために、プラン提示装置１は、ユーザ情報が記憶されるユーザＤＢ（Database）５０、プランを提供するプラン提供者の情報が記憶される提供者ＤＢ５１、プラン提供者が提供したプランの情報が記憶されるプランＤＢ５２、プランの予約情報が記憶される予約ＤＢ５３、プランの検索履歴やプランの閲覧履歴やプランの利用履歴などの履歴情報が記憶される履歴ＤＢ５４、各種ウェブページのウェブページデータが記憶されるウェブページＤＢ５５を管理する。

＜２．ハードウェア構成＞

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

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

＜３．ＤＢ＞

プラン提示装置１が管理する各種ＤＢについて説明する。

［３−１．ユーザＤＢ］
ユーザＤＢ５０にはプラン提示装置１が提供するプランに関する各種サービス（例えば、プラン管理サービスやプラン予約サービスなど）を利用するユーザの情報が記憶される。例えば、一つのユーザＩＤ（Identification）に対して、ログインパスワード、氏名、年齢、性別、住所、メールアドレス、年収、趣味などの個人的な情報が紐付けられて記憶される。
また、ユーザＤＢ５０には、ユーザの嗜好情報などが記憶される。
更に、ユーザＤＢ５０には、ユーザごとの推薦時間帯が記憶される。推薦時間帯は、推薦プランの提示に適した時間帯情報であり、ユーザの行動履歴によって算出される。

［３−２．提供者ＤＢ］
提供者ＤＢ５１には、プランを提供するプラン提供者（例えばゴルフ場の管理者）の情報が記憶される。例えば、一つの提供者ＩＤに対して、ログインパスワード、氏名、ゴルフ場名（またはゴルフ場ＩＤ）、住所、電話番号、メールアドレス、ゴルフ場のウェブページのＵＲＬ（Uniform Resource Locator）情報、各種コース情報（例えば、ホール数の情報、ホールの難易度、コースレーティング、ホールの攻略情報、規定スコア情報、ヤーデージ情報）などが紐付けられて記憶される。

［３−３．プランＤＢ］
プランＤＢ５２には、プラン提供者によって提供されるプランの情報が記憶される。例えば、プランごとに付与されるプランＩＤに対して、プラン提供者ＩＤ、ゴルフ場ＩＤ、枠情報（日時情報とスタート時間を含む情報）、各種オプション情報（食事付き、キャディ付き、ゴルフカート付きなどの各種オプションの有無を表す情報）などが記憶される。

［３−４．予約ＤＢ］
予約ＤＢ５３には、プラン提示装置１が提供するゴルフのプランに対する予約状況が記憶される。具体的には、一つの予約情報を一意に特定可能な予約ＩＤに対して、予約を行ったユーザＩＤ、予約対象となったプランＩＤ、プレイ予定日時情報、予約を受け付けた日時情報、同伴者情報などが記憶される。
尚、予約ＤＢ５３は、利用前の予約情報が記憶されるＤＢであり、利用済みの予約情報は削除される。

［３−５．履歴ＤＢ］
履歴ＤＢ５４には、プラン提供装置１が提供したプランに対する予約履歴や利用履歴がユーザＩＤごとに記憶される。
具体的に、図４を参照して説明する。

図４に示す履歴ＤＢ５４には、ユーザＩＤが「Ｕ＿００００１」とされたユーザと、ユーザＩＤが「Ｕ＿００００２」とされたユーザの各種履歴情報が記憶されている。
各種履歴情報としては、履歴種別と操作日時情報と対象プランとスタート時間の情報が記憶されている。
履歴種別は、履歴が予約操作の履歴であるのか、予約取消操作の履歴であるのか、予約したプランを実際に利用したことを示す履歴であるのかを識別可能な情報である。尚、これらの履歴種別はあくまで一例であり、他の種別があってもよい。
操作日時情報は、履歴情報が生成された日時情報を示している。即ち、予約履歴であれば、予約操作に基づいた予約情報をプラン提示装置１が受け付けた日時の情報である。
対象プランは、各操作が何れのプランを対象としたものであるかを示す情報である。

スタート時間は、ユーザが選択したスタート時間の情報が記憶される。各プランは、複数のスタート時間が選択可能とされており、予約の際にユーザによって選択される。
これ以外にも、スタートホール情報（即ち「ＩＮスタート」と「ＯＵＴスタート」の何れであるのかを示す情報）が記憶されてもよい。
また、スタート時間以外の選択可能なオプションの情報がある場合には、それらの選択情報も履歴ＤＢ５４に記憶される。一方、プランによって自ずと決まるオプションについては、記憶する必要は無い。例えば、昼食付きプランであれば、当該プランを選択した時点で昼食付きのオプションが自動で付与されるため、履歴ＤＢ５４に記憶する必要は無い。但し、その場合には、プランＤＢ５２に昼食付きのオプションについての情報が記憶される。

尚、利用前の予約履歴には、予約ＤＢ５３に記憶された予約情報（例えば予約ＩＤ）が紐付けられていてもよい。即ち、利用前の予約情報は予約ＤＢ５３に記憶されているため、その情報が予約履歴に紐付けられていてもよい。

［３−６．ウェブページＤＢ］
ウェブページＤＢ５５には、プラン提示装置１がユーザやプラン提供者に提供する各種ウェブページのデータが記憶される。具体的には、ログインページや予約ページやプラン一覧ページや検索ページやプラン詳細ページなどのウェブページデータである。
以降の説明においては、プラン提示装置１が提供するプランに関するウェブページをプラン関連ページと記載する。
ウェブページデータとしては、ウェブページのＵＲＬ情報と各ウェブページ上に配置されるオブジェクト（画像やテキストやバナーなど）の配置情報が記憶される。配置情報とは、ウェブページ上における各オブジェクトの配置態様（位置や大きさ、色等）が記載された情報である。
尚、ウェブページＤＢ５３に記憶される情報は、例えば、ＨＴＭＬなどの構造化文書ファイルで記憶されてもよい。

＜４．処理の流れ＞

各実施の形態における処理の流れについて、説明する。

［４−１．第１の実施の形態］
第１の実施の形態における処理の流れについて、図５を参照して説明する。
第１の実施の形態では、推薦プランを抽出した後、推薦時間帯であることを確認して推薦プランを提示する例を説明する。

先ず、プラン提示装置１は、ステップＳ１０１において、推薦プランを抽出する処理を実行する。この処理は、例えばユーザの嗜好情報に応じて推薦プランを抽出する処理である。
具体的には、ユーザが土日にプランを利用する傾向が高い場合には、土日のプランを推薦プランとして抽出する。他にも、ユーザがよく利用するプランの価格帯を考慮して推薦プランを抽出することや、ユーザがよく利用するゴルフ場（或いはよく利用する地域に位置するゴルフ場）を考慮して推薦プランを抽出することや、ユーザが好むゴルフ場の特性（池が少ないゴルフコースを好むのか、起伏が激しいゴルフコースを好むのかなど）を考慮して推薦プランを抽出することや、ユーザがよく利用するサービス（電動カートの有無や昼食付きなど）を考慮して推薦プランを抽出することなどが考えられる。勿論、これらの情報を複合的に用いて推薦プランを抽出することにより、ユーザにとって利用価値の高い高優先度の推薦プランを抽出することもできる。
これらの嗜好（傾向）情報は、予約履歴から抽出してもよいし、利用履歴から抽出してもよい。また、他のユーザの同伴履歴（即ち他のユーザが予約したプランに参加したことを示す履歴情報）から嗜好情報を抽出してもよい。

続いて、プラン提示装置１はステップＳ１０２において、推薦プランが抽出されたか否かを判定する処理を実行する。
先の推薦プラン抽出処理の結果、推薦プランが抽出されていないと判定した場合、プラン提示装置１は図５に示す一連の処理を終了する。
一方、推薦プランが抽出されたと判定した場合、プラン提示装置１は続くステップＳ１０３において、推薦時間帯算出処理を実行する。
推薦時間帯算出処理では、ユーザに推薦プランを提示するのにふさわしい時間帯を推薦時間帯として算出する処理である。詳しくは後述する。

続いて、プラン提示装置１はステップＳ１０４において、現時刻が推薦時間帯であるか否かを判定する処理を実行する。
推薦時間帯でないと判定した場合、プラン提示装置１はステップＳ１０５において、推薦プランは妥当か否かを判定する処理を実行する。推薦プランが妥当であると判定した場合は、ステップＳ１０４の処理を再度実行する。即ち、現時刻が推薦時間帯ではない場合において、推薦プランが妥当と判定されている限りは、ステップＳ１０４，Ｓ１０５の各処理を継続的に実行する。

ここで、推薦プランが妥当でないと判定する場合について説明する。推薦プランが妥当でないとは、例えば、ステップＳ１０４，Ｓ１０５の各処理を継続的に実行している間に推薦しようとしているプランの予約枠が埋まってしまった場合や、予約可能な時間が経過してしまった場合などである。
このような場合には、現時刻が推薦時間帯となり推薦プランをユーザに提示したとしても、推薦プランに対するユーザの予約操作を受け付けることができず、推薦することが不適当となってしまう可能性がある。
そこで、ステップＳ１０５において推薦プランが妥当でないと判定した場合については、プラン提示装置１はステップＳ１０１の処理を再度実行し、推薦プランを抽出し直す。

現時刻が推薦時間帯であり、且つ、推薦プランが妥当である場合、プラン提示装置１はステップＳ１０６において、推薦プラン提示処理を実行する。この処理により、ユーザ端末３に対してプラン提示装置１が抽出した推薦プランが提示される。

本実施の形態によれば、先ず推薦プランの抽出が行われるため、推薦時間帯まで待つことができないがユーザに対して推薦した方がよい推薦プランが抽出された場合には、例外的に推薦時間帯でない時間帯に推薦プランを提示することもできる。

［４−２．推薦時間帯算出処理］
先の図５のステップＳ１０３の推薦時間帯算出処理について、図６を参照して説明する。
先ず、プラン提示装置１はステップＳ２０１において、予約履歴取得処理を実行する。具体的には、推薦時間帯の算出対象とされたユーザの予約履歴を履歴ＤＢ５３から取得する。

続いて、プラン提示装置１はステップＳ２０２において、分析処理を実行する。
分析処理では、ユーザがプランの予約をするための操作を行う時間帯を分析する処理である。例えば、平日の昼休みと思われる時間帯にあるユーザの予約操作が集中している場合は、平日の当該時間帯を当該ユーザの推薦時間帯として設定する。
尚、プランの予約をするための予約操作だけでなく、予約取消操作も含めて分析してもよい。予約取消操作も含めて分析した場合には、ユーザが操作可能な時間帯を推薦時間帯として算出することとなる。
一方、予約取消操作を含めない場合には、ユーザの予約操作のみに基づいて推薦時間帯を算出することとなる。これは、予約操作は利用日の１０日以上前に行うが、取消操作は利用日の３日前に行うことが多いユーザに対しては有効である。即ち、取消操作が行われる利用日の３日前にプランを提示しても、当該プランを予約する可能性は低いと考えられるためである。

分析処理によって得られた推薦時間帯は、ユーザＤＢ５０に記憶される。

［４−３．第２の実施の形態］
第２の実施の形態における処理の流れについて、図７を参照して説明する。
第２の実施の形態では、推薦時間帯であることを確認した後、推薦プランを抽出して推薦プランを提示する例を説明する。
尚、第１の実施の形態と同様の処理については、同じ符号を付し、適宜説明を簡略化（或いは省略）する。

先ず、プラン提示装置１はステップＳ１０３において、推薦時間帯算出処理を実行する。推薦時間帯算出処理の例は、先の図６を用いて説明した処理である。
続いて、プラン提示装置１はステップＳ１０４において、現時刻が推薦時間帯か否かを判定する処理を実行する。現時刻が推薦時間帯となるまで、プラン提示装置１はステップＳ１０４の処理を実行する。
現時刻が推薦時間帯と判定した場合、プラン提示装置１はステップＳ１０１において、推薦プラン抽出処理を実行する。抽出処理では、前述したように、ユーザの嗜好情報などを用いて推薦プランを抽出する。

続いて、プラン提示装置１はステップＳ１０２において、推薦プランが抽出できたか否かを判定する処理を実行する。
推薦プランを抽出できなかった場合には、図７に示す一連の処理を終了する。
一方、推薦プランを抽出できた場合、プラン提示装置１はステップＳ１０６において、抽出された推薦プランをユーザ端末３に提示する処理を実行する。

本例によれば、推薦時間帯であることを確認した後に推薦プランを抽出するため、第１の実施の形態のように、現時刻が推薦時間帯になるまでの間に推薦プランが不適当となってしまうことがない。

［４−４．第３の実施の形態］
第３の実施の形態における処理の流れについて、図８を参照して説明する。
第３の実施の形態では、推薦時間帯の中でも、特にユーザがプラン関連ページを閲覧しているときに推薦プランを提示する。
尚、図８に示す各処理を実行する前に推薦時間帯算出処理を実行済みとする。

具体的には、先ず、プラン提示装置１はステップＳ３０１において、プラン関連ページの送信要求を受信する。プラン関連ページとは、前述したように、プランの検索ページやプランの検索結果が表示されるプラン一覧ページや、プランの詳細が記載されたプラン詳細ページなどのウェブページである。

これらのプラン関連ページの送信要求を受信したプラン提示装置１は、続くステップＳ３０２において、現時刻が推薦時間帯であるか否かを判定する処理を実行する。この処理は、先の図５や図７に示したステップＳ１０４の処理と同様の処理である。
現時刻が推薦時間帯でない場合、プラン提示装置１は図８に示した一連の処理を終了する。
一方、現時刻が推薦時間帯である場合、プラン提示装置１はステップＳ３０３において、推薦プラン抽出処理を実行する。この処理は、図５や図７のステップＳ１０１の処理と同様の処理である。

続いて、プラン提示装置１はステップＳ３０４において、推薦プランが抽出できたか否かを判定する処理を実行する。この処理は、図５や図７のステップＳ１０２の処理と同様である。

推薦プランが抽出できなかった場合、プラン提示装置１は図８に示した一連の処理を終了する。
一方、推薦プランを抽出できた場合、プラン提示装置１はステップＳ３０５において、推薦プランをユーザ端末３に提示する処理を実行する。

［４−５．第４の実施の形態］
第４の実施の形態における処理の流れについて、図９を参照して説明する。
第４の実施の形態では、推薦時間帯においてユーザがプラン関連ページを閲覧しており、且つ、検索用語入力欄がアクティブになったときに推薦プランを提示する。即ち、ユーザがプランを検索しようと操作しているときに、推薦プランを提示する。
尚、図９に示す各処理を実行する前に推薦時間帯算出処理を実行済みとする。

具体的には、先ず、プラン提示装置１はステップＳ３０６において、プランを検索するための検索用語入力欄のアクティブ化を検知する処理を実行する。この処理は、例えば、ユーザ端末３が検索用語入力欄のアクティブ化を検知したときにプラン提示装置１へ向けて送信される情報をプラン提示装置１が受信することにより実現される。

続いて、プラン提示装置１はステップＳ３０２乃至Ｓ３０５の各処理を実行する。
各処理内容については、図８に示した各処理内容と同じであるため、説明を省略する。

［４−６．第５の実施の形態］
第５の実施の形態における処理の流れについて、図１０を参照して説明する。
第５の実施の形態では、推薦プランを推薦することが可能な推薦時間帯が複数ある場合についての例を説明する。
尚、図１０に示す各処理を実行する前に推薦時間帯算出処理を実行済みであり、例えば、あるユーザには、平日の１２時〜１３時が推薦時間帯として設定されているとする。

プラン提示装置１は図１０に示すステップＳ３０２乃至Ｓ３０４の各処理を実行する。各処理は、図８に示した同符号を付した各処理と同じ処理であるため、説明を省略する。

続いて、プラン提示装置１はステップＳ３０７において、推薦プランの提示が妥当であるか否かを判定する処理を実行する。
ここで、当該判定処理の一例を示す。
例えば、提示プランが地域Ａに位置するゴルフコースＢのプランＣであったとする。また、プランＣは、通常のプラン販売では売れなかった枠を直前に割り引いて販売するプランであるため、利用日の１週間前から推薦プランとして抽出されるものとする。
ユーザの推薦時間帯が平日の１２時〜１３時であるため、月曜日の１２時に当該プランＣが抽出されたとする（ステップＳ３０３）。即ち、推薦時間帯としては、月曜日でもよいし、火曜日でもよいため、推薦時間帯が複数あることになる。

このとき、プランＣの利用日（例えば土曜日）における地域Ａの天気予報がゴルフに適した天気でない場合（或いは、台風が近づいてきていて、判定が難しい場合）、推薦プランの提示を見送り、天気が好転した場合に（或いは、台風がより近づき、地域Ａの天気予報の確度が増した場合に）再度提示するか否かを判定することが考えられる。
ステップＳ３０７の判定処理はこのような場合に行われる処理である。
即ち、推薦プランとして提示することが好ましくない可能性がある場合には、このような判定処理を行うことによって、提示処理を後日（即ち、他の推薦時間帯）に行ってもよい。

また、ゴルフに相応しいか否かを段階的に表し、それに基づいてステップＳ３０７の判定処理を実行してもよい。
具体的には、天気について、ゴルフに相応しい度合いが高い方から、「快晴」、「晴れ」、「晴れ時々曇り」、「曇り時々晴れ」、「曇り」、「曇り時々雨」、「雨時々曇り」、「雨」、「豪雨」、「雷雨」と設定する例を考える。このとき、プランを推薦することが望ましくない天気を「曇り時々雨」、「雨時々曇り」、「雨」、「豪雨」、「雷雨」とする。また、天気予報と実際の利用日における天気が上記段階から１段階ずれると考える。即ち、「晴れ」の予報であれば、実際の天気は「快晴」、「晴れ」、「晴れ時々曇り」の何れかとなると考える。
このとき、１段階ずれたとしても推薦することが望ましくない天気とならない場合は、ステップＳ３０７の判定処理において推薦プランの提示が妥当であると判定する。一方、１段階ずれることを考慮すると、推薦することが望ましくない天気となる可能性がある場合は、ステップＳ３０７の判定処理において推薦プランの提示が妥当でないと判定する。

推薦プランの提示が妥当でないと判定した場合、プラン提示装置１は図１０に示す一連の処理を終了する。
また、推薦プランの提示が妥当であると判定した場合、プラン提示装置１は続くステップＳ３０５の推薦プラン提示処理を実行する。

尚、ステップＳ３０７において推薦プランの提示が妥当でないと判定した場合、プラン提示装置１は再びステップＳ３０３の推薦プラン抽出処理を実行して、推薦プランを抽出し直してもよい。
また、天気予報の情報を取得した日からプラン利用日までの期間の長さによって、予報からのずれの大きさを変えてもよい。例えば、５日後の天気は、予報と１段階ずれる可能性があるが、１０日後の天気は、予報と２段階ずれる可能性があるなどとしてもよい。

［４−７．第６の実施の形態］
第６の実施の形態における処理の流れについて、図１１を参照して説明する。
第６の実施の形態では、推薦時間帯の中でも推薦プランに応じた最適な推薦時間帯に提示する例について説明する。
先ず、ステップＳ１０１乃至Ｓ１０３において、プラン提示装置１は、推薦プランを抽出して推薦時間帯を算出する。これらの各処理は、図５に示した処理と同じである。

続いて、プラン提示装置１はステップＳ１０７において、最適な推薦時間帯を算出する処理を実行する。
例えば、ステップＳ１０３の処理において、推薦時間帯として平日の２０時〜２２時が算出されたとする。
平日の２０時〜２２時という条件を満たすためには、利用日とされた土曜日の３日前の水曜日であってもよいし、２週間前の金曜日であってもよい。本例では、この中から、最適な推薦時間帯を算出（選択）する。

即ち、プラン提示装置１は、続くステップＳ１０７において、最適な推薦時間帯を算出する処理を実行する。
例えば、抽出した推薦プランが利用日までの日数が短い「直前割り」などのプランであった場合、抽出された時点で利用日までの日数が少ないため、可能な限り早めに提示することが望ましい。具体的には、現時刻から一番近い推薦時間帯を最適な推薦時間帯とする。
また、抽出した推薦プランの利用日が休日（例えば土日）である場合についても、予約が早めに埋まる可能性があるため、現時刻から一番近い推薦時間帯（例えば、２週間前や１ヶ月前など）を最適な推薦時間帯とする。

更に、抽出した推薦プランの利用日が平日である場合については、天気予報の情報を得ることが可能な１週間前を最適な推薦時間帯としてもよい。
他にも、推薦プランの残り予約数によって決定してもよい。具体的には、推薦プランの残り予約枠数が所定数以下（例えば５枠以下）となった場合には、現時刻から一番近い推薦時間帯を最適な推薦時間帯とし、所定数以上である場合には、２週間前を最適な推薦時間帯とする。

更にまた、ユーザのプランの利用頻度に応じて最適な推薦時間帯を算出してもよい。
例えば、プランの利用頻度が１ヶ月に１度のユーザと、半年に１回のユーザとで、算出される最適な推薦時間帯が異なるようにしてもよい。
具体的には、平日プラン（平日であれば、月によらず利用可能なプラン）を推薦プランとした場合に、２０１５年１月にプランを利用したユーザの利用頻度が１ヶ月に１度の場合には、１月の最終週を最適な推薦時間帯として算出する。また、２０１５年１月にプランを利用したユーザの利用頻度が半年に１度の場合には、６月の最終週を最低な推薦時間帯として算出する。
尚、利用頻度ではなく、予約頻度に応じて最適な推薦時間帯を算出してもよい。

最適な推薦時間帯を算出（選択）したプラン提示装置１は、続くステップＳ１０８において、現時刻が最適な推薦時間帯であるか否かを判定する処理を実行する。
現時刻が最適な推薦時間帯である場合、プラン提示装置１はステップＳ１０６で推薦プランをユーザに提示する処理を実行する。
一方、現時刻が最適な推薦時間帯でない場合、プラン提示装置１は再度ステップＳ１０８の処理を実行する。

尚、残り予約枠数に応じて最適な推薦時間帯を算出する場合、現時刻が最適な推薦時間帯となるまで、ステップＳ１０７及びＳ１０８の処理を実行してもよい。先の説明では、ステップＳ１０８のみを繰り返し実行していたが、その間に予約枠数が減ってしまい、推薦プランを提示する機会を逸してしまう可能性がある。
これを防止するために、現時刻が最適な推薦時間帯でない場合には、ステップＳ１０７の処理を実行して、最適な推薦時間帯を再度算出してもよい。

＜５．まとめ＞

上記したプラン提示装置１は、ユーザごとの推薦プランを抽出するプラン抽出部１ａと、ユーザの予約実績に基づいて推薦プランを提示する推薦時間帯を決定する時間帯決定部１ｂと、推薦プランとして新たな推薦プランが抽出されたことに応じて、推薦時間帯に新たな推薦プランをユーザに提示するプラン提示部１ｃと、を備える。
これにより、ユーザごとに抽出された推薦プランが、ユーザにとって都合のよい時間帯に提示される。
従って、推薦プランの利用数（或いは予約数）を増加させることができる。
特に、新規推薦プランが抽出されなければ、ユーザに推薦プランが提示されないため、提示に係る情報処理装置の処理負担を軽減することができる。尚、提示処理を行うプラン提示処理装置１だけでなく、提示された推薦プランを受信するユーザ端末３についても、処理負担の軽減が図られる。
また、定期的に情報が送られてくることは、情報に対する感度が低下することに繋がる。本発明によれば、定期的に情報が提供されるのではなく、新規推薦プランが抽出されたことに応じて情報が提供されるため、情報に対する感度を低下させることなく、興味を引き出すことができる。
更に、ゴルフプランなどのプランは通常の商品と異なり利用日が決まっていることから、推薦可能な回数が限られている場合が多い。即ち、通常の商品は、２年間毎日レコメンドをしても問題がないが、ゴルフプランに関しては、それが難しい。
従って、有効な推薦プランを有効な推薦時間帯に提示することは、非常に効果的である。

また、第３の実施の形態で説明したように、プラン提示装置１のプラン提示部１ｃは、推薦時間帯において、プランに係るプラン関連ページをユーザが閲覧中であると判定された場合に提示を行う。
ユーザがプラン詳細ページや予約ページなどのウェブページを閲覧している状態は、プランに対する関心が高い状態と推測できる。このような状態において、推薦プランが提示される。
従って、推薦プランの訴求力を高めることができる。
また、プランに係るプラン関連ページをユーザが閲覧中であるときに限って推薦プランを提示することによって、提示回数は減少することとなる。これは、定期的に情報が送られてくることによる情報に対する感度低下を防止することができると共に、推薦プランがユーザの記憶に残りやすいものとなる。これにより、予約操作に繋がる可能性を高めることができる。

更に、第４の実施の形態で説明したように、プラン提示装置１のプラン提示部１ｃは、推薦時間帯において、プランに係るプラン関連ページに配置されたプラン検索用語入力欄がアクティブになったことに応じて提示を行う。
ユーザがプラン詳細ページや予約ページなどのウェブページを閲覧している状態は、プランに対する関心が高い状態と推測できる。更に、そのようなウェブページにおいてプラン検索を行うための検索用語入力欄がアクティブになった状態は、プランに対する関心が更に高い状態と推測できる。このような状況において、推薦プランが提示される。
従って、推薦プランの訴求力を更に高めることができる。
また、プランに係るプラン関連ページをユーザが閲覧中であり、且つ、検索用語入力欄がアクティブになった状態に推薦プランを提示することによって、提示回数は更に減少することとなる。しかし、これによって、定期的に情報が送られてくることによる情報に対する感度低下を更に防止することができると共に、推薦プランがユーザの記憶に一層残りやすいものとすることができ、予約操作に繋がる可能性を更に高めることができる。

更にまた、第６の実施の形態で説明したように、プラン提示装置１のプラン提示部１ｃは、推薦プランの内容に応じて決定された時期における推薦時間帯に提示を行う。
これにより、推薦プランに応じて提示すべき時期を適切に設定することが可能となる。
従って、推薦プランの内容に応じた適切な時期に推薦プランを提示することができる。

加えて、第６の実施の形態で説明したように、プラン提示装置１のプラン提示部１ｃは、ユーザの予約実績または利用実績の頻度に応じて決定された時期における推薦時間帯に提示を行う。
これにより、プランの予約または利用の実績に基づいて提示すべき時期を適切に設定することが可能となる。
従って、ユーザの予約態様または利用態様に応じた適切な時期に推薦プランを提示することができる。

上記した各例では、ゴルフプランを対象としたプラン提示装置１を説明したが、それ以外のプランを対象としたプラン提示装置１であってもよい。例えば、日帰り旅行プランや、イベントプランや、宿泊プランなどを対象としてもよい。また、イベントプランと宿泊プランなどのように、複数のプランを合わせたものであってもよいを対象としてもよい。

＜６．プログラム＞

各実施の形態におけるプログラムは、プラン提示装置１が備える演算処理装置（ＣＰＵなど）に実行させるプログラムである。

このプログラムは、ユーザごとの推薦プランを抽出するプラン抽出手順を演算処理装置に実行させる。
また、ユーザの予約実績に基づいて前記推薦プランを提示する推薦時間帯を決定する時間帯決定手順を演算処理装置に実行させる。
更に、前記推薦プランとして新たな推薦プランが抽出されたことに応じて、前記推薦時間帯においてプランに係るプラン関連ページをユーザが閲覧中であると判定された場合に前記新たな推薦プランをユーザに提示するプラン提示手順を演算処理装置に実行させる。
即ちこのプログラムは、演算処理装置に対して、図５乃至図１１で説明した各処理を実行させるプログラムである。

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

１ プラン提示装置、１ａ プラン抽出部、１ｂ 時間帯決定部、１ｃ プラン提示部、２ 通信ネットワーク、３ ユーザ端末、４ 提供者端末、５０ ユーザＤＢ、５１ 提供者ＤＢ、５２ プランＤＢ、５３ 予約ＤＢ、５４ 履歴ＤＢ、５５ ウェブページＤＢ

Claims (7)

1. ユーザごとの推薦プランを抽出するプラン抽出部と、
   ユーザの予約実績に基づいて前記推薦プランを提示する推薦時間帯を決定する時間帯決定部と、
   前記推薦プランとして新たな推薦プランが抽出されたことに応じて、前記推薦時間帯においてプランに係るプラン関連ページをユーザが閲覧中であると判定された場合に前記新たな推薦プランをユーザに提示するプラン提示部と、を備える
   情報処理装置。
2. 前記プラン提示部は、前記推薦時間帯において、プランに係るプラン関連ページに配置されたプラン検索用語入力欄がアクティブになったことに応じて前記提示を行う
   請求項１に記載の情報処理装置。
3. 前記プラン提示部は、前記推薦プランの内容に応じて決定された時期における前記推薦時間帯に前記提示を行う
   請求項１に記載の情報処理装置。
4. 前記プラン提示部は、ユーザの予約実績または利用実績の頻度に応じて決定された時期における前記推薦時間帯に前記提示を行う
   請求項１に記載の情報処理装置。
5. ユーザごとの推薦プランを抽出するプラン抽出ステップと、
   ユーザの予約実績に基づいて前記推薦プランを提示する推薦時間帯を決定する時間帯決定ステップと、
   前記推薦プランとして新たな推薦プランが抽出されたことに応じて、前記推薦時間帯においてプランに係るプラン関連ページをユーザが閲覧中であると判定された場合に前記新たな推薦プランをユーザに提示するプラン提示ステップと、を
   情報処理装置が実行する情報処理方法。
6. ユーザごとの推薦プランを抽出するプラン抽出手順と、
   ユーザの予約実績に基づいて前記推薦プランを提示する推薦時間帯を決定する時間帯決定手順と、
   前記推薦プランとして新たな推薦プランが抽出されたことに応じて、前記推薦時間帯においてプランに係るプラン関連ページをユーザが閲覧中であると判定された場合に前記新たな推薦プランをユーザに提示するプラン提示手順と、を
   情報処理装置に実行させるプログラム。
7. ユーザごとの推薦プランを抽出するプラン抽出手順と、
   ユーザの予約実績に基づいて前記推薦プランを提示する推薦時間帯を決定する時間帯決定手順と、
   前記推薦プランとして新たな推薦プランが抽出されたことに応じて、前記推薦時間帯においてプランに係るプラン関連ページをユーザが閲覧中であると判定された場合に前記新たな推薦プランをユーザに提示するプラン提示手順と、を
   情報処理装置に実行させるプログラムを記憶した記憶媒体。

Images