JP7648487B2 - 旅行プラン提案装置および旅行プラン提案方法 - Google Patents

Description

本発明は、利用者の嗜好傾向に沿った旅行プランの提案に結び付け、予約、購入動作を実行可能とする旅行プラン提案装置、旅行プラン提案システムおよび旅行プラン提案方法に関する。

従来、ウェブサイトにアクセスしたアクセス履歴やオンラインショッピングにおいて商品を購入した購入履歴等の行動履歴に基づいて、利用者の嗜好を推定する技術の研究が進められている。例えば、このような利用者の嗜好を推定する技術を用いて、利用者の関心度が高い商品を利用者に提示することが可能になると考えられる。しかしながら、上記の従来技術では、利用者の嗜好の変化を予測することが困難であった。具体的には、上記の従来技術は、あくまで利用者の過去の情報を示す行動履歴等に基づいて利用者の嗜好を漠然と推定するだけであるので、利用者が将来に関心を示す商品やサービス等の分野を推定することが困難であった。

上記課題に対して、特開2013－171500号公報（特許文献１）がある。この特許文献１には、「実施形態に係る分析装置は、抽出部と、算出部と、予測部とを有する。抽出部は、利用者に関する利用者属性情報又は利用者端末によってコンテンツが送受信された履歴情報から利用者が関心を示している分野に関する関心情報を抽出するとともに、コンテンツの送受が行われた利用者端末間の関係を示すフロー情報を抽出する。算出部は、フロー情報に基づいて、利用者端末毎に、受信されたコンテンツに関する関連コンテンツが利用者端末から他の利用者端末に送信される送信確率を算出する。

予測部は、送信確率に基づいて、所定の利用者端末に所定のコンテンツの関連コンテンツが伝播する伝播確率を予測するとともに、所定の利用者における関心情報に基づいて、関連コンテンツに対する利用者の関心度を予測する。」と記載されている。

特開2013－171500号公報

特許文献１に示す技術では、利用者のコンテンツ利用履歴から利用者間の類似度を計算しグルーピングを実行するとともに、利用者の利用遷移予測フロー(樹形図)を作成することで、コンテンツレコメンド精度を上げる動作を開示している。このような利用者間の類似度を正確に計算するためには、一定量以上の利用者履歴の蓄積が必要と想定される。一方で、サービス開始直後等でサービス利用者が少ない場合には、十分な履歴情報が得られず、精度の良い分析が難しい場合がある。

特に、旅行プラン作成のように、多業種に渡る情報を取得し、予約、または購入動作を行う手順を想定すると、それぞれ別個に多業種にわたる事業者サイトにアクセスし、予約、または購入動作を実行しなければならず、非常に煩雑な操作が必要となる。

また、各事業者が利用者の嗜好傾向を把握するには、多くの利用者の使用履歴が収集された段階で自社サイト上の各利用者の操作履歴を参照し、参照された情報から利用者の嗜好傾向を分析して、自社サイトから提供する公開情報を検討する必要がある。これらの自社サイトへの各利用者の操作分析は、非常に困難を極める。

本発明は、多種多様な事業者サイトにアクセスし、予約、購入動作を行う煩雑な操作を容易に実施可能であり、少ない利用者の情報を効率的に活用し、利用者の嗜好に適した旅行プランを提示すると共に、事業者が利用者の嗜好傾向の効率的な分析作業を可能とする旅行プラン提案装置、旅行プラン提案システム及び旅行プラン提案方法を提供することを課題とする。

上記課題を解決するために、旅行プラン提案装置の一例を挙げるならば、旅行プランの提案を受ける利用者から設定される利用者設定情報と、前記利用者の嗜好傾向を示す利用者特徴タグと、を前記利用者の識別情報に対応付けて利用者レコード単位として記憶される利用者構造記憶部と、外部サイトから取得された前記旅行プランの候補となるスポットに関するスポット設定情報と、前記スポットの嗜好傾向を示すスポット特徴タグと、を前記スポットの識別情報に対応付けてスポットレコード単位として記憶されるスポット構造記憶部と、前記スポット設定情報の所在地に対応付けられた交通機関と、前記所在地に近在する関連スポットと、を前記交通機関の識別情報に対応付けて移動手段レコード単位として記憶される移動手段構造記憶部と、前記利用者構造記憶部に記憶される、前記旅行プランの提案を受ける特定の利用者レコード単位のデータ群と、前記スポット構造記憶部に記憶されるデータ群を、スポットレコード単位毎に類似度を演算し、前記類似度の高いスポットレコード単位と、前記類似度の高いスポットレコード単位に対応付けられた前記移動手段レコード単位を前記旅行プランの候補として前記利用者に提案する提案画面を生成する提案情報処理部と、を備えた構成を有する。

本発明によれば、多種多様な事業者サイトにアクセスし、予約、購入動作を行う煩雑な操作を容易に実施可能であり、少ない利用者の情報を効率的に活用し、利用者の嗜好に適した旅行プランを提示すると共に、事業者が利用者の嗜好傾向の効率的な分析作業を可能とする。

実施例１における旅行プラン提案システム１０００のブロック図である。 実施例１における旅行プラン提案システム１０００のハードウェア構成を示すブロック図である。 実施例１における旅行プラン提案装置１１００の利用者設定画面３０００を示す図である。 実施例１における利用者特徴ＤＢ１１１１内の構造記憶形態を示す図である。 実施例１における旅行プラン提案装置１１００のスポット設定画面４０００である。 実施例１におけるスポット特徴ＤＢ１１１２内の構造記憶形態を示す図である。 実施例１におけるタグ辞書ＤＢ１１１４内の構造記憶形態を示す図である。 実施例１におけるスポット特徴タグ編集画面６０００を示す図である。 実施例１における移動手段特徴ＤＢ１１１３内の構造記憶形態を示す図である。 実施例１における旅行プラン提案システム１０００全体の処理フローを示す図である。 実施例１における利用者側提案画面８０００の一例を示す図である。 実施例１における寄り道提案画面８０８０の一例を示す図である。 実施例１におけるＤＢ管理部１１１９による利用者特徴ＤＢ/スポット特徴ＤＢの更新フローチャートである。 実施例１におけるタグ共有処理部１１１６によるタグ共有処理フローチャートである。 実施例１における提案情報処理部１１１５による提案処理フローチャートである。 実施例２における旅行プラン提案システム１８００のブロック図である。

以下に、本実施形態に係る旅行プラン提案装置、旅行プラン提案システム及び旅行プラン提案方法の実施例を図面に基づいて詳細に説明する。なお、この実施例により本実施形態に係る旅行プラン提案装置、旅行プラン提案システム及び旅行プラン提案方法が限定されるものではない。

実施例１では、旅行プラン提案装置の利用者Ｕと同類と推定される履歴情報を分析し、利用者Ｕの嗜好傾向を示す特徴情報と、旅行プランの訪問先（以下、スポットＳと称する）の特徴情報の類似度を基に関連性を判定し、利用者Ｕの特徴情報に相応しい旅行プランを提案する旅行プラン提案システム１０００の例を説明する。

図１は、実施例１における旅行プラン提案システム１０００のブロック図である。旅行プラン提案システム１０００は、複数の利用者端末１３００、事業者サイト１２００、１２１０、１２２０、１２３０が、それぞれネットワーク１４００、１５００を介して旅行プラン提案装置１１００と接続するブロック図を示している。

旅行プラン提案装置１１００は、利用者端末１３００からのアクセスにより多数の利用者Ｕの特徴情報と、事業者サイト１２００、１２１０、１２２０、１２３０から提供されるスポットＳの特徴情報と移動手段に関する特徴情報のマッチングを検索し、検索結果から利用者Ｕの嗜好傾向に基づいて適切な旅行プランを提案表示する。この提案により、旅行プランに含まれるスポットＳのチケットの購入を促し、利用者Ｕは、飲食店サイト、宿泊サイト、観光先サイト、移動手段サイト等別個に旅行プランに関する情報を収集しなくともストレスなく効率的に旅行プランを計画し、スムーズに進行させることができる。

一方、事業者サイトを運営する事業者側は、旅行プラン提案装置内のデータベースの特徴情報を参照することにより、自社に対する利用者の嗜好傾向を把握することが可能となり、利用者の利用傾向によりマッチしたスポット情報を提供可能となるように、提供するスポット情報をよりカスタマイズ可能となる。

利用者端末１３００は、利用者Ｕが旅行プラン提案装置１１００による提供サービスを受けるための端末であり、利用者Ｕが年齢、性別、嗜好といった特徴情報や、今回の旅行の目的、重視したい項目等を利用者の登録情報として予め初期設定、もしくは入力設定することによって、旅行中その時々でのスポット候補や寄り道情報を得られ、またその情報を得てスポットＳの予約を行える。

なお、利用者端末１３００は、主にパーソナルコンピュータ、または携帯端末が想定されるが、コンビニエンスストア、公共施設等に設置されたチケット購入機、チケット発券機でもよい。また、コンビニエンスストア、公共施設等に設置された複合機でチケットや予約情報を印刷することとしてもよい。また、旅行プラン提案装置１１００が操作部（不図示）を有し、利用者Ｕが直接、旅行プラン提案装置１１００上で操作可能としてもよい。

事業者サイト１２００～１２３０は、観光スポット、飲食店、宿泊所やモビリティ等を運営および管理する事業者が維持管理するサイトであり、各事業者が提供するサービス情報を利用者Ｕに提供し、利用者Ｕにより選択されたサービス情報に従い、チケットの予約情報、購入情報を発行する。例えば、実施例１では、事業者サイト１２００は和食店、洋食店、喫茶店の飲食店サイトを示す。事業者サイト１２１０はホテル、旅館、ログハウスの宿泊施設サイトを示す。事業者サイト１２２０は遊園地、博物館、美術館の観光サイトを示す。事業者サイト１２３０は鉄道会社、バス会社、レンタカー会社の移動手段サイトを示す。このように、さまざまな業種のサイトと情報通信を行う。事業者サイトは、上述の事業者に限定されず、更に多種多様な事業者を対象としてもよい。

以下に、旅行プラン提案装置１１００の各機能部を説明する。図１において、旅行プラン提案装置１１００は、タグ生成エンジン部１１１０と、利用者端末I／Ｆ１１３０と、事業者管理I／Ｆ１１４０と、権利情報記憶部１１２０を有している。

また、タグ生成エンジン部１１１０の内部は、利用者特徴ＤＢ１１１１と、スポット特徴ＤＢ１１１２と、移動手段特徴ＤＢ１１１３と、タグ辞書ＤＢ１１１４と、ＤＢ管理部１１１９と、タグ共有処理部１１１６と、提案情報処理部１１１５と、タグ設定管理部１１１７と、類似度演算部１１１８を備えている。なお、利用者特徴ＤＢ１１１１と、スポット特徴ＤＢ１１１２と、移動手段特徴ＤＢ１１１３と、タグ辞書ＤＢ１１１４は、それぞれ設定部分と、特徴タグを蓄積、格納するデータベースであり、各部の機能および動作の詳細を後述する。

利用者特徴ＤＢ１１１１は、各利用者Ｕの年代、性別、旅行目的といった利用者設定情報と、利用者設定情報と類似項目が多いスポット情報を記述する利用者特徴タグを対応付けて格納するデータベースであり、随時、データベース内部のデータを更新、管理される。後述する利用者設定画面で予め初期設定、もしくは入力設定された設定値と、タグ共有処理部１１１６、提案情報処理部１１１５によって付与された利用者特徴タグを対応付けて保持する。

スポット特徴ＤＢ１１１２は、各スポットＳの来訪目的、ロケーションといったスポット設定情報と、スポット設定情報と類似項目の多い利用者情報を記述するスポット特徴タグを対応付けて格納するデータベースであり、随時、データベース内部のデータを更新、管理される。後述するスポット設定画面で予め初期設定、もしくは入力設定された設定値と、タグ共有処理部１１１６、提案情報処理部１１１５によって付与されたスポット特徴タグを対応付けて保持する。各スポットＳの混雑状況を各事業者サイト１２００～１２２０から取得し、リアルタイムで更新する。

移動手段特徴ＤＢ１１１３は、公共交通機関、レンタカー等移動手段の特徴情報を対応付けて記憶すると共に、随時更新するデータベースである。後述する提案情報処理部１１１５による利用者側提案画面で提案される旅行プラン内に提示される。移動手段の移動時間、混雑状況を移動手段サイト１２３０から取得し、リアルタイムで更新する。

タグ辞書ＤＢ１１１４は、事業者サイト１２００、１２１０、１２２０から提供されるスポットＳのスポット設定情報で定義された言葉の派生語、類義語を定義するデータベースであり、類似した概念で微妙に表現の差異があり、旅行プラン検索の際に検索の抜け漏れを防ぐ。利用者ＵとスポットＳの特徴情報の対応づけを表面的な言葉の一致、もしくは類似だけでなく、本質的な意味も含めて検索するための類義語辞書である。以上、各データベースの構成は、詳細を後述する。

タグ設定管理部１１１７は、旅行プラン提案装置１１００上で事業者サイト１２００、１２１０、１２２０、１２３０において事業者が管理するスポットＳの特徴情報を編集可能とする構成としているが、タグ設定管理部１１１７を事業者サイト１２００、１２１０、１２２０、１２３０側に設け、事業者サイト内部で設定可能としてもよい。この場合、事業者サイト内部で設定された特徴情報が旅行プラン提案装置１１００に送信され、スポット特徴ＤＢ１１１２の該当スポット情報を更新する。また、事業者による初期特徴情報の設定だけでなく、後述する旅行プラン提案装置のタグ共有処理によって追加付与された特徴情報に基づいて自動編集されてもよい。

更に、タグ設定管理部１１１７は、データベース内の利用者特徴タグ３０８０およびスポット特徴タグ４０８０の嗜好傾向を分析する機能を有することにより、事業者が利用者の嗜好傾向を把握し、自社サイトの記述や構成に反映することが可能となる。分析方法としては、分析項目を指定することで、ヒストグラム作成、時系列データ分析、統計解析等を実行可能とすれば、利用者の嗜好分析を行う上でより有効である。

タグ共有処理部１１１６は、利用者特徴ＤＢ１１１１と、スポット特徴ＤＢ１１１２間で、データベース内部のデータの共有を図ることによって、よりそれぞれの特徴にマッチングした特徴情報を検索可能とする。タグ共有処理部１１１６が実行するタグ共有処理フローについては、詳細を後述する。

類似度演算部１１１８は、利用者特徴ＤＢ１１１１の該当利用者Ｕのレコードと、スポット特徴ＤＢの各レコードの類似度を算出する機能を有する。類似度の演算方法に関しては、レコード内に合致する項目が存在するか否かの存否を判定し、各存否の総合判定値として算出する手法が考えられる。例えば、各判定項目の二乗和平方根により算出されるユークリッド距離算出法、統計的な距離を算出するマハラノビス距離算出法、ピアソンの積率相関係数、コサイン類似度等種々の手法により算出可能である。これらの算出法は、公知技術であるため、ここでは説明を省略する。一例として、ユークリッド距離算出法により類似度を算出する場合、ｎ項目の判定項目に関して項目有を０、項目無を１と判定すると仮定した場合、全項目同一で類似度０、全項目不一致で類似度√ｎとなり、数値が低いほど類似度が高い指標となる。

提案情報処理部１１１５は、上述の類似度演算部１１１８で演算された類似度に基づき、旅行プランの候補を抽出し、利用者に提案する提案画面を生成し、利用者Ｕに提示する。更に、提案された旅行プランが選択された場合、より利用者Ｕの嗜好傾向に一致したプランとして特徴情報の優先度を上げるタグ恒常化処理を実行する。タグ恒常化処理フローについては、詳細を後述する。なお、提案画面の表示は、利用者端末１３００に提案画面データを送信して表示させる、もしくは旅行プラン提案装置１１００の表示部（不図示）で表示させてもよい。ＤＢ管理部１１１９は、上述した各データベースのデータを新規追加すると共に、特徴タグの重みを算出して、更新管理する。

権利情報記憶部１１２０は、実施例１により提案された旅行プランから選択され、購入、もしくは予約したチケット情報に関する権利情報を格納する。また、各事業者サイトに直接アクセスして取得された購入、もしくは予約したチケット情報に関する権利情報も格納する。また、これらの購入、もしくは予約したチケット情報に関する権利情報は、利用者Ｕの利用者端末１３００の一例である携帯端末に送信され、スポットＳを利用時に事業者に提示されることにより、スポットＳを利用可能としてもよい。

また、スポットＳを利用時に提示される場合、利用者端末１３００において、購入、もしくは予約したチケット情報に関する権利情報の使用前、使用後の管理を行う。使用後には、権利情報を消去し、二重利用不可となるように権利情報管理を行う。更に、スポットＳへの来訪を旅行プラン提案装置１１００に通知し、提示された旅行プランに追加される二次的サービスを受けるといった使い方も利用可能である。

利用者端末I／Ｆ１１３０は、旅行プラン提案装置１１００と利用者端末１３００の情報交換を司るインターフェースである。利用者端末１３００からの利用者情報を旅行プラン提案装置１１００に送信すると共に、旅行プラン提案装置１１００からの利用者向け提案情報を利用者端末１３００に提供する。利用者端末I／Ｆ１１３０が、旅行プラン提案装置１１００に対して遠隔地にある場合、ネットワーク１５００は公衆回線を使用され、旅行プラン提案装置１１００と同一施設内にある場合、ローカルエリアネットワーク（ＬＡＮ）を活用される。また、無線ＬＡＮや近距離通信（ＮＦＣ）を活用してもよい。

事業者管理I／Ｆ１１４０は、旅行プラン提案装置１１００と各事業者サイト１２００～１２３０の情報交換を司るインターフェースである。事業者管理I／Ｆ１１４０は、旅行プラン提案装置１１００と多数の事業者サイトを接続するため、ネットワーク１４００は公衆回線を使用する形態が想定されるが、上述する他の通信手段でもよい。

図２は、実施例１における旅行プラン提案システム１０００のハードウェア構成を示すブロック図である。図２における旅行プラン提案装置１１００は、中央処理装置２００２と、主記憶装置２００３と、内部バス２００４と、バスＩ／Ｆ２００５と、外部バス２００６と、画面出力装置Ｉ／Ｆ２００７と、ユーザ入力装置Ｉ／Ｆ２００８と、大容量記憶装置Ｉ／Ｆ２００９と、通信装置Ｉ／Ｆ２０１０と、入出力装置Ｉ／Ｆ２０１１から構成される。

中央処理装置２００２は、後述するタグ共有処理、提案情報処理、類似度演算等のプログラムを実行し、演算を行うと共に、旅行プラン提案装置１１００全体の動作を制御する装置である。

主記憶装置２００３は、後述するタグ共有処理、提案情報処理、類似度演算等のプログラムを実行する際の処理領域および、例えばＯＳ（Ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）などの基本プログラムの一時格納領域として使用される。

中央処理装置２００２と、主記憶装置２００３は、内部バス２００４により接続されており、内部バス２００４はバスＩ／Ｆ２００５を介して外部バス２００６に接続されている。

外部バス２００６は、画面出力装置Ｉ／Ｆ２００７、ユーザ入力装置Ｉ／Ｆ２００８、大容量記憶装置Ｉ／Ｆ２００９、通信装置Ｉ／Ｆ２０１０、入出力装置Ｉ／Ｆ２０１１と接続されており、これらのＩ／Ｆと中央処理装置２００２や主記憶装置２００３とのデータ入出力をバスＩ／Ｆ２００５、内部バス２００４を用いて実行する。

画面出力装置Ｉ／Ｆ２００７は、ディスプレイ２１００と接続するためのＩ／Ｆであり、外部バス２００６を通じて得た情報をディスプレイ２１００に出力する。ディスプレイ２１００は例えば、実施例１における旅行プラン提案装置１１００の設定画面や提案画面等を表示可能な装置であり、そのほかにも基本プログラムを操作するための情報等が表示できる。

ユーザ入力装置Ｉ／Ｆ２００８は、ユーザ入力装置２２００と接続するためのＩ／Ｆであり、外部バス２００６にユーザ入力装置から入力された情報を出力する。ユーザ入力装置はキーボード、マウスなど、ユーザからの入力を受け取るための装置であり、ユーザ入力装置から入力された情報はユーザ入力装置Ｉ／Ｆ２００８を介して、主記憶装置２００３や大容量記憶装置２３００に格納され、中央処理装置２００２で上記プログラムが実行される際に活用される。

大容量記憶装置Ｉ／Ｆ２００９は、大容量記憶装置２３００と接続するためのＩ／Ｆであり、大容量記憶装置２３００からのデータ入出力を外部バス２００６に仲介する。大容量記憶装置２３００は、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）といった装置であり、上記プログラム実行時の一時保管情報、権利情報等のデータを保持すると共に、利用者特徴ＤＢ１１１１、スポット特徴ＤＢ１１１２、移動手段特徴ＤＢ１１１３、タグ辞書ＤＢ１１１４のデータベースを構築してデータを保持する。

通信装置Ｉ／Ｆ２０１０は、通信装置２４００と接続するためのＩ／Ｆであり、通信装置からのデータ入出力を外部バス２００６に仲介する。通信装置は例えばＥｔｈｅｒｎｅｔ（登録商標）を介して各事業者サイト１２００、１２１０、１２２０、利用者端末１３００等と接続するための装置であり、接続することにより通信を行い、データ交換を行う。

入出力装置Ｉ／Ｆ２０１１は、入出力装置２５００と接続するためのＩ／Ｆであり、入出力装置２５００からのデータ入出力を外部バス２００６に仲介する。入出力装置２５００は、可搬性記憶媒体に読み書き可能なドライブ装置やユーザ認証を行うためのＩＣカードリーダ、指紋認証装置等である。

実施例１における旅行プラン提案装置１１００の一連の処理を実行する際には、大容量記憶装置２３００に格納された旅行プラン提案装置１１００の各データベース内のデータと一連の処理プログラムを主記憶装置２００３に呼び出し、中央処理装置２００２が処理演算を実行することにより、主記憶装置２００３上に仮想的に図１に示す各機能部を構築することで各機能を実行する。

以下に、設定画面とデータベースの構成に関して詳細を後述する。図３は、実施例１における旅行プラン提案装置１１００の利用者設定画面３０００を示す図である。利用者Ｕが、利用者設定画面３０００を用いて予め初期設定、もしくは入力設定を行う。利用者設定画面３０００は、ペルソナ設定欄３０１０と、旅行目的欄３０２０と、履歴呼出ボタン３０３０と、設定完了ボタン３０４０を有している。

ペルソナ設定欄３０１０は、利用者Ｕの年齢や性別等基本的な情報を入力する設定である。また、「好み（フリーワード）」として、個別の嗜好情報を入力可能とする。実施例１においては、年齢、性別のみを特徴情報として扱う制御例を説明する。上記年齢と性別の入力は、年齢と性別に基づく複数の選択肢をプルダウンメニューで表示し、プルダウンメニューの中から選択可能としてもよく、利用者にとってより操作性が向上する。

旅行目的欄３０２０は、主目的と、重視したい項目等旅行目的について入力する設定である。また、「重視したい項目（フリーワード）」として、追加情報を入力可能とする。実施例１においては、主目的のみを特徴情報として扱う制御例を説明する。上記主目的の入力は、主目的に基づく複数の選択肢をプルダウンメニューで表示し、プルダウンメニューの中から選択可能としてもよく、利用者にとってより操作性が向上する。

履歴呼出ボタン３０３０は、過去に設定した履歴情報を呼び出すボタンであり、自身で設定した項目の他に、旅行プラン提案装置１１００によって自動で設定された特徴情報を呼び出してもよい。設定完了ボタン３０４０は、利用者設定画面３０００の入力情報を確定し、利用者特徴ＤＢ１１１１への格納、または更新処理を行うためのボタンである。

なお、利用者設定画面３０００で設定される各項目は、利用者端末１３００に予め初期設定、もしくは入力設定された情報が、旅行プラン提案装置１１００にアクセスすると同時に、利用者特徴ＤＢ１１１１、スポット特徴ＤＢ１１１２、タグ辞書ＤＢ１１１４内の情報を参照する動作でもよく、アクセス時に設定する動作でもよい。

図４は、実施例１における利用者特徴ＤＢ１１１１内の構造記憶形態を示す図である。利用者特徴ＤＢ１１１１は、利用者ＩＤ３０５０、ペルソナ設定３０６０、旅行目的３０７０からなる利用者設定情報１１１１ａと、利用者特徴タグ３０８０と、重み３０９０の各項目から構成される。

利用者特徴ＤＢ１１１１は、利用者Ｕの年代、性別、旅行目的、嗜好傾向といった特徴情報を対応付けて格納するデータベースであり、随時、データベース内部のデータを更新、管理される。利用者特徴ＤＢ１１１１は、上述した利用者設定画面３０００で予め初期設定、もしくは入力設定された設定値を格納する利用者設定情報１１１１ａと、該当利用者に関する嗜好の特徴を集約した利用者特徴タグ３０８０と、利用者特徴タグ３０８０を集約した重み３０９０を、利用者ＩＤ３０５０に対応付けて利用者レコード単位ＵＲとして記憶する利用者構造記憶部である。

利用者ＩＤ３０５０は、個々の利用者Ｕを識別するための識別情報であり、旅行プラン提案装置１１００内の認証部（不図示）で認証されることによって、利用者Ｕを特定する。利用者ＩＤ３０５０は単一の利用者だけでなく、家族や社員といったグループ単位でも設定できる。認証しようとする利用者ＩＤ３０５０が利用者特徴ＤＢ１１１１内に存在しない場合、利用者ＩＤ３０５０を新規作成する。利用者ＩＤ３０５０の新規作成に関しては、詳細を後述する。

利用者設定情報１１１１ａは、ペルソナ設定３０６０と、旅行目的３０７０から構成される。ペルソナ設定３０６０は、図３の利用者設定画面３０００のペルソナ設定欄３０１０において設定された利用者Ｕの年齢や性別等基本的な情報を記憶する項目である。旅行目的３０７０は、図３の利用者設定画面３０００の旅行目的欄３０２０において設定された情報を記憶する項目である。旅行目的３０７０は、旅行毎の目的について記載される項目であり、プライベートでの家族旅行やビジネストリップなど利用者個人であっても状況によって変化する目的について記す。この情報によって、個人性質が目的や状況によって変化する場合に対応する。

利用者特徴タグ３０８０は、後述するタグ共有処理により転記されたスポット特徴情報を記憶する項目である。利用者特徴タグ３０８０、訪問先のスポット特徴や移動手段の特徴を共有した特徴情報であり、この情報を参照することで、訪問先に訪れた嗜好傾向の類似した他の利用者の情報についても情報共有がなされる。

重み３０９０は、利用者特徴タグ３０８０でタグ共有された情報を集約して記憶する項目である。重み３０９０は、図１に示すＤＢ管理部１１１９で算出される数値である。重みの算出方法については、タグ共有処理を実行した後、利用者特徴タグ３０８０に記憶される同一スポットＩＤをカウントする。更に、カウントされた数値を全スポット数で正規化される。図４に示すデータでは、スポットＳ０３：０.１、Ｓ０１：０.1、スポットＳ０２：０.３と算出され、算出された重みを考慮して類似度を演算する。

図５は、実施例１における旅行プラン提案装置１１００のスポット設定画面４０００である。図５に示すように、スポット設定画面４０００を用いて事業者が設定を入力することで、スポット特徴ＤＢ１１１２における該当スポットの初期設定や更新を実行する。また、旅行プラン提案装置１１００によって後述するタグ共有処理でつけられた特徴タグを事業者側で編集可能としてもよい。スポット設定画面４０００は、来訪目的欄４０１０、タグ辞書利用設定４０２０、設定完了ボタン４０３０を有している。また、オプション設定として、フリー入力設定メニューを設けてもよい。

来訪目的欄４０１０は、カテゴリ１とカテゴリ２に分類されており、業種や業態などスポットＳの基本的な情報を入力することでスポットの特徴をスポット特徴ＤＢ１１１２に登録する。タグ辞書利用設定４０２０は、後述するタグ辞書ＤＢ１１１４内に定義されるどのカテゴリを使用するかを指定する項目である。タグ辞書利用設定４０２０は、事業者サイト１２００、１２１０、１２２０、１２３０から提供されるスポットＳの業種、業態等、スポットＳの特徴を拡張する定義を示し、タグ辞書ＤＢ１１１４のカテゴリ３、４への拡張を指定する。上記来訪目的欄４０１０とタグ辞書利用設定４０２０の入力は、来訪目的とタグ辞書利用設定に基づく複数の選択肢をプルダウンメニューで表示し、プルダウンメニューの中から選択可能としてもよく、事業者にとってより操作性が向上する。

オプション設定は、フリーにタグを追加できる項目である。オプション設定は、タグ辞書ＤＢ１１１４で定義される登録項目以外の内容を入力できるようにするものであり、スポットＳに関するインターネット等で得られる電子情報があった場合には、これを用いたタグ情報の自動入力機能を備えても良い。

設定完了ボタン４０３０は、スポット設定画面４０００の入力情報を確定し、スポット特徴ＤＢ１１１２への格納、または更新処理を行うためのボタンである。

図６は、実施例１におけるスポット特徴ＤＢ１１１２内の構造記憶形態を示す図である。スポット特徴ＤＢ１１１２は、スポットＩＤ４０４０、来訪目的４０５０、ロケーション４０６０、スポットリアルタイムタグ４０７０、スポット特徴タグ４０８０、重み４０９０の各項目から構成される。

スポット特徴ＤＢ１１１２は、各スポットＳの特徴情報を対応付けて格納するデータベースであり、随時、データベース内部のデータを更新、管理される。スポット特徴ＤＢ１１１２は、図５で示したスポット設定画面４０００で予め初期設定、もしくは入力設定された設定値を格納するスポット設定情報１１１２ａと、該当スポットのリアルタイム情報を取得するスポットリアルタイムタグ４０７０と、該当スポットに関する嗜好の特徴を集約したスポット特徴タグ４０８０と、スポット特徴タグ４０８０を集約した重み４０９０を、スポットＩＤ４０４０に対応付けてスポットレコード単位ＳＲとして記憶するスポット構造記憶部である。

スポット設定情報１１１２ａは、スポットＩＤ４０４０、来訪目的４０５０、ロケーション４０６０から構成される。スポットＩＤ４０４０は、個々のスポットＳを識別するための識別情報であり、スポット設定画面４０００で予め初期設定、もしくは入力設定される際に付与され、スポットＳを特定する。該当するスポットＩＤ４０４０がスポット特徴ＤＢ１１１２内に存在しない場合、スポットＩＤ４０４０を新規作成する場合もある。スポットＩＤ４０４０の新規作成に関しては、詳細を後述する。

来訪目的４０５０は、スポットＳの特徴を表すものであり、主に後述するタグ辞書ＤＢ１１１４内のカテゴリを参照してスポットＳの管理者によって予め定められる。更に、訪問した利用者の特徴のうち、特に利用者の選択によってスポットの特徴をよく表す可能性が高いものが、旅行プラン提案装置１１００によって追加される場合もある。

ロケーション４０６０は、スポットＳの所在地情報であり、各事業者が各事業者サイト上で入力設定された情報を予め取得しておく。スポットリアルタイムタグ４０７０は、スポットＳの混雑状況や待ち時間等の情報を予め各事業者サイトから取得し、リアルタイムに更新する。利用者Ｕは、スポットリアルタイムタグ４０７０の表示情報を見て、スポットＳの選択を行う場合も想定している。例えば、人の多い人気スポットが好き、静かな場所が好きといった嗜好の情報にも読み替えられる。

スポット特徴タグ４０８０は、後述するタグ共有処理、もしくはタグ恒常化処理によって、利用者の嗜好傾向が共有された結果得られる項目である。スポット特徴タグ４０８０は、スポットの特徴として今まで見えていなかった嗜好傾向が含まれる可能性がある。

重み４０９０は、スポット特徴タグ４０８０でタグ共有された特徴情報を集約して記憶する項目である。重み４０９０は、図１に示すＤＢ管理部１１１９で算出される数値である。重みの算出方法については、タグ共有処理を実行した後、スポット特徴タグ４０８０に記憶される同一利用者ＩＤをカウントする。更に、カウントされた数値を全利用者数で正規化される。図６に示すデータでは、利用者Ｕ０３：０．１、利用者Ｕ０３：０．１、利用者Ｕ０３：０．３と算出され、算出された重みを考慮して類似度を演算する。

図７は、実施例１におけるタグ辞書ＤＢ１１１４内の構造記憶形態を示す図である。タグ辞書ＤＢ１１１４は、カテゴリ１～４のデータ構造を有しており、カテゴリ１～４はそれぞれ７００１、７００２、７００３、７００４の符号で示す。タグ辞書ＤＢ１１１４は、カテゴリ１が大分類に相当し、カテゴリ１から右列に行くに従い、小分類に移行していくデータ構造となっている。従って、小分類のカテゴリ４の記載内容は、神社、キャンプ場、自然公園、Ｄ店、Ｅ店等の実在する固有名称となる。

図７は、タグ辞書ＤＢ１１１４の例であり、上述の利用者設定画面３０００やスポット設定画面４０００における初期設定値の入力設定値を保持する。タグ辞書ＤＢ１１１４を用いることにより、様々な利用者、事業者が特徴情報を設定する場合に、類似した概念を異なる語句で表してしまい、旅行プラン提案の提案範囲が狭くなる状況を回避する。タグ辞書ＤＢ１１１４にはカテゴリ毎に特徴情報が記されており、カテゴリに従って特徴情報を設定できる。また、旅行プラン提案装置１１００の管理者が、タグ辞書ＤＢ１１１４を編集可能としてもよい。

実際の操作例としては、図５における示したスポット設定画面４０００のタグ辞書利用設定４０２０において、カテゴリ３、４を指定することにより、カテゴリ１、２よりも更に特定した情報を指定して旅行プランを検索可能となる。

更に、図８は、実施例１におけるスポット特徴タグ編集画面６０００を示す図である。スポット特徴タグ編集画面６０００は、タグ設定状況６０１０、来訪タグ分析６０２０から構成される。

タグ設定状況６０１０は、スポット特徴ＤＢ１１１２や移動手段特徴ＤＢ１１１３に記載された特徴情報を編集するためのものであり、スポットや移動手段に対応して、後述する恒常タグとして設定されている特徴情報が表示され、各事業者サイトの管理者によって編集可能である。スポットや移動手段を管理する事業者は、この画面を用いて必要に応じてタグの編集が可能である。事業者サイトが提供するスポット特徴タグを編集することにより、事業者サイトの管理者がより利用者の嗜好傾向を把握しつつ、利用者にスポットの特徴情報を提供可能となる。

来訪タグ分析６０２０は、利用者の予約、または購入によるタグの共通度を分析し表示するものであり、利用者の旅程において共通するスポット、移動手段や共通タグの項目が示される。各事業者サイトの管理者は、来訪タグ分析６０２０の分析情報を参照して、タグ設定状況６０１０を編集可能である。

図５に示すスポット設定画面４０００、図８に示すスポット特徴タグ編集画面６０００は、図１に示すタグ設定管理部１１１７によって表示機能、編集機能を実行される。事業者サイトの管理者が旅行プラン提案装置１１００にアクセスし、編集を実行する形態を想定しているが、事業者サイトの管理者が設定ファイルを送信し、受信すると自動的に設定される形態でもよい。

図９は、実施例１における移動手段特徴ＤＢ１１１３内の構造記憶形態を示す図である。移動手段特徴ＤＢ１１１３は、交通機関、レンタカー等移動手段の特徴情報を移動手段サイト１２３０から取得し、関連付けて記憶すると共に、随時更新するデータベースである。移動手段特徴ＤＢ１１１３は、機関名７０２０と、ルートリアルタイムタグ７０３０と、関連スポット７０４０を、ルートＩＤ７０１０に対応付けて移動手段レコード単位として記憶する移動手段構造記憶部である。

ルートＩＤ７０１０は、目的地となるスポットＳへのルートを示す識別情報である。機関名７０２０は、鉄道、バス等交通機関を示す情報であり、レンタカーの予約情報、もしくは道路情報等を収集してもよい。

ルートリアルタイムタグ７０３０は、機関名７０２０の移動時間、混雑状況等を示す情報であり、移動手段サイト１２３０から移動時間、混雑状況等の情報をリアルタイムに取得し、リアルタイムに更新する。関連スポット７０４０は、ルートＩＤ７０１０の到着地におけるスポットＩＤと、名称等が取得された情報である。

例えば、スポットＩＤ０２の「飲食：洋食」は、Ｂ市のロケーションであるため、図９における移動手段特徴ＤＢ１１１３内のＢ市へのルートＩＤ：Ｍ０１のルートリアルタイムタグ７０３０の混雑：８０％を取得し、図６におけるスポットＩＤ０２のスポットリアルタイムタグ４０７０に入力され、スポットＩＤ０２のスポットレコードに記憶される情報は、後述する提案情報処理部１１１５による利用者側提案画面８０００で提案される旅行プラン内に提示される。また、関連スポット７０４０に記憶される情報は、後述する寄り道提案画面８０８０で提案される旅行プラン内に提示される。

図１０は、実施例１における旅行プラン提案システム１０００全体の処理フローを示す図である。利用者端末１３００は、利用者設定画面３０００で設定した旅行プラン提案装置１１００にＩＤおよび設定情報はシステム構成図の旅行プラン提案装置１１００の動作を示す。また、図１１Ａは、実施例１における利用者側提案画面８０００の一例を示す図である。図１１Ａの利用者側提案画面８０００は、条件選択欄８０１０、旅行目的欄８０２０、目的別抑制ＯＮボタン８０２５、設定完了ボタン８０３０、提案候補欄８０４０、待ち時間表示欄８０４５、予約ボタン８０５０、寄り道ボタン８０６０、抽出条件変更ボタン８０７０を有している。

以下、図１０において、旅行プラン提案システム１０００の動作について説明する。利用者端末１３００から利用者ＵのＩＤと年齢、性別といったペルソナ設定３０６０、旅行目的３０７０、追加設定情報も含めて旅行プラン提案装置１１００に送信する（ステップ１００）。

旅行プラン提案装置１１００内部の認証部（不図示）で認証が実行された後、旅行プラン提案装置１１００にアクセスし利用可能となる。利用者端末１３００によって送信された利用者ＩＤ３０５０、ペルソナ設定３０６０、旅行目的３０７０の利用者設定情報１１１１ａが利用者特徴ＤＢ１１１１に存在するか否かを判断し、その可否判断によって利用者特徴ＤＢ１１１１を更新する（ステップ１０１）。

更に、図１１Ａの条件選択欄８０１０の旅行目的欄８０２０、目的別抑制ＯＮボタン８０２５で選択される条件選択情報を選択し、設定完了ボタン８０３０を押下することにより、上記条件選択情報を旅行プラン提案装置１１００に送信する（ステップ１０２）。

旅行プラン提案装置１１００は、選択されたスポット設定情報が自装置のスポット特徴ＤＢ１１１２内に有していないと判断すれば、タグ辞書ＤＢ１１１４を参照する（ステップ１０３）。図７に示すタグ辞書ＤＢ１１１４の各カテゴリを参照してスポット特徴ＤＢ１１１２を更新する（ステップ１０４）。利用者特徴ＤＢ１１１１と、スポット特徴ＤＢ１１１２のデータベース更新に関しては、図１２を用いて詳細を後述する。

次に、更新された利用者特徴ＤＢ１１１１の利用者特徴タグ３０８０と、スポット特徴ＤＢ１１１２のスポット特徴タグ４０８０のタグ共有処理を実行する（ステップ１０５）。更に、利用者特徴ＤＢ１１１１の利用者特徴タグ３０８０の内容から各スポットの重みを算出する。また、スポット特徴ＤＢ１１１２のスポット特徴タグ４０８０の内容から各利用者の重みを算出する。タグ共有処理と重みの算出に関しては、図１３を用いて詳細を後述する。

次に、利用者特徴ＤＢ１１１１の該当利用者のレコードと、スポット特徴ＤＢ１１１２の各レコードの類似度を算出し、類似度の高いスポット情報から２か所を提案候補として選出する（ステップ１０６）。類似度の算出を含む提案処理については、図１４を用いて詳細を後述する。

選出された提案候補のスポット情報を利用者端末１３００に送信する（ステップ１０７）。上記ステップ１０７において送信されたスポット情報を、図１１Ａのように利用者側提案画面８０００を利用者端末１３００に表示する。

利用者Ｕが、表示された利用者側提案画面８０００の提案候補欄８０４０の内容を採用すると判断すれば、予約ボタン８０５０を押下することにより、旅行プラン提案装置１１００に予約指示情報が送信される（ステップ１０８）。予約指示情報に基づき、旅行プラン提案装置１１００が提案候補となるスポットの各事業者サイトと交信し、予約処理、または購入処理を実行することとなる。なお、予約処理、または購入処理の詳細および手順は、本実施例においては説明を省略する。

更に、送信された予約指示情報が利用中の利用者Ｕとの関連性が高いと判断し、タグ恒常化処理を実行する（ステップ１０９）。タグ恒常化処理については、詳細を後述する。

また、提案候補欄８０４０は、後述する提案処理により抽出された旅行プランの候補を表示する。提案候補欄８０４０の中には、待ち時間表示欄８０４５、予約ボタン８０５０、寄り道ボタン８０６０を含んでいる。待ち時間表示欄８０４５は、スポット特徴ＤＢ１１１２のスポットリアルタイムタグ４０７０、または移動手段特徴ＤＢ１１１３のルートリアルタイムタグ７０３０の情報を取得して表示する。

予約ボタン８０５０は、利用者Ｕによって提案候補を選択して押下されることにより、予約処理を実行する指示ボタンである。予約処理は、予約対象の事業者サイト１２００～１２３０と情報通信することにより、実行される。予約処理された利用者の権利情報は、図１に示す権利情報記憶部１１２０に記憶する。権利情報記憶部１１２０に記憶された後、予約処理を実行した利用者端末１３００に送信され、利用者Ｕに通知し利用を促すこととしてもよい。

また、寄り道候補の提案を表示したい場合、図１１Ａの寄り道ボタン８０６０を押下することにより、図１１Ｂのように寄り道提案画面８０８０に移行する。図１１Ｂは、実施例１における寄り道提案画面８０８０の一例を示す図である。図１１Ｂにおいて、寄り道を含めて予約したい場合、図１１Ｂの寄り道込み予約ボタン８０９０を押下することにより、寄り道を含めて一括予約することが可能となる。

なお、利用者側提案画面８０００に印刷指示ボタン（不図示）を設け、提案内容、予約情報、もしくは購入情報を、ネットワークを介して印刷実行可能としてもよい。その際、バーコートを印刷し、印刷物を当該スポットに持参し、バーコードを読み込まれることでチケットの代用物として活用されるようにしてもよい。

更に、図１１Ａにおいて、表示された提案候補欄８０４０以外の提案候補を望む場合、抽出条件変更ボタン８０７０を押下することにより、「混雑回避」「広い」「自然の景観」といった観点で抽出条件を変更して提案候補の再抽出を指示することが可能となる。抽出条件変更については、図１４のフローチャートにて動作を後述する。

次に、図１０のステップ１０１～１０４に示されるＤＢ管理部１１１９によるデータベース更新フローに関して詳細に説明する。図１２は、実施例１におけるＤＢ管理部１１１９による利用者特徴ＤＢ/スポット特徴ＤＢの更新フローチャートである。

利用者端末１３００から旅行プラン提案装置１１００にアクセスされた際、アクセスされた利用者ＩＤが利用者特徴ＤＢ１１１１内に存在するか否かを判定する（ステップ２００）。利用者ＩＤが存在する場合、利用者端末１３００から取得された図１１Ａの旅行目的欄８０２０と、目的別抑制ＯＮ８０２５の設定を参照する（ステップ２０１）。目的別抑制ＯＮ８０２５がチェックされていない場合、利用者特徴ＤＢ１１１１に格納される利用者Ｕのレコードから対象スポットを検索する（ステップ２０２）。また、目的別抑制ＯＮ８０２５がチェックされている場合、旅行目的欄８０２０に合致するレコードに限定する（ステップ２０３）。利用者特徴ＤＢ１１１１に格納される限定された利用者Ｕのレコードから対象スポットを検索する（ステップ２０２）。

なお、ステップ２０２において、利用者Ｕの事前に予約された情報、もしくは滞在情報がある場合、スポット特徴ＤＢ１１１２のロケーション４０６０を基に、利用者Ｕの所在情報を取得し、検索対象を限定することでより利用者Ｕの利用目的に合致した対象スポットを抽出可能となる。

ステップ２００において、利用者ＩＤが存在しない場合、利用者ＩＤを新規作成する（ステップ２０４）。利用者端末１３００から入力されるペルソナ設定欄３０１０と、旅行目的欄３０２０を基に、スポット特徴ＤＢ１１１２内のレコードを検索する（ステップ２０５）。上記ステップ２０２、またはステップ２０５の実行により、対象スポットを予備検索する。

上記ステップ２０２、またはステップ２０５の処理の結果、対象スポットＩＤの有無を判定する（ステップ２０６）。対象スポットＩＤが存在する場合、ステップ２０９に進む。一方、対象スポットＩＤが存在しない場合、ステップ２０７に進む。タグ辞書ＤＢ１１１４を参照してスポット特徴ＤＢ１１１２内のレコードを再検索する（ステップ２０７）。検索結果を基にスポットＩＤを新規作成する（ステップ２０８）。

上記ステップ２００～２０８の処理の結果、利用者特徴ＤＢ１１１１の利用者設定情報１１１１ａおよびスポット特徴ＤＢ１１１２のスポット設定情報１１１２ａを更新し、対象スポットＩＤを取得する（ステップ２０９）。なお、この時点では、多数の（例えば、３以上の）対象スポットＩＤを取得していてもよい。

次に、タグ共有処理について詳細を説明する。図１２で説明したデータベース更新フローで取得された対象スポットＩＤを基にタグ共有処理を実行し、データベースの特徴タグと重みを更新する。図１３は、実施例１におけるタグ共有処理部１１１６によるタグ共有処理フローチャートである。

最初に、データベース更新フローで取得された対象スポットＩＤを取得する（ステップ３００）。次に、利用者特徴ＤＢ１１１１の利用者レコード単位ＵＲをスポット特徴ＤＢ１１１２の対象スポットＩＤに対応するスポット特徴タグ４０８０に転記する（ステップ３０１）。同時に、スポット特徴ＤＢ１１１２の対象スポットＩＤに対応するスポットレコード単位ＳＲを利用者特徴ＤＢ１１１１の利用者特徴タグ３０８０に転記する（ステップ３０２）。

次に、利用者特徴ＤＢ１１１１の利用者特徴タグ３０８０のデータを基に、各スポットＩＤの重みを算出する（ステップ３０３）。ＤＢ管理部１１１９は、利用者特徴タグ３０８０に記憶される同一スポットＩＤをカウントする。更に、カウントされた数値を全スポット数で正規化する。

次に、スポット特徴ＤＢ１１１２のスポット特徴タグ４０８０のデータを基に、各利用者ＩＤの重みを算出する（ステップ３０４）。ＤＢ管理部１１１９は、スポット特徴タグ４０８０に記憶される同一利用者ＩＤをカウントする。更に、カウントされた数値を全利用者数で正規化する。ステップ３０３で算出されたスポット重みと、ステップ３０４で算出された利用者重みを含めて利用者特徴ＤＢ１１１１およびスポット特徴ＤＢ１１１２を更新する（ステップ３０５）。

次に、旅行プラン提案処理について詳細を説明する。図１４は、実施例１における提案情報処理部１１１５による提案処理フローチャートである。

利用者特徴ＤＢ１１１１における利用者ＩＤに対応する利用者レコード単位ＵＲと、スポット特徴ＤＢ１１１２の各スポットレコード単位ＳＲの類似度演算を実行する（ステップ４００）。図１に示す類似度演算部１１１８が、レコードの類似度を算出する。

利用者特徴ＤＢ１１１１と、スポット特徴ＤＢ１１１２のレコード内に合致する項目が存在するか否かの存否を判定し、各存否の総合判定値として算出する手法が考えられる。更に、項目の存否を全て等分ではなく、重みを考慮する算出方法も算出可能である。図１３に示すタグ共有処理フローのステップ３０３、３０４で算出されたスポット重み、利用者重みを用いることにより、過去の情報量の多いレコードを集約して類似度を算出可能となる。

なお、ステップ４００における類似度の算出は、スポット特徴ＤＢ１１１２の全レコードに対して算出することが好ましいが、図１２のステップ２０９で予備検索を行った対象スポットのみに対して算出した場合、検索範囲が限定されるが処理時間の短縮という利点を得られる。

類似度の算出結果から、類似度の高いスポットＩＤを２レコード抽出する（ステップ４０１）。抽出された２レコードのスポット情報を提案候補として、図１１Ａに示す利用者側提案画面８０００を生成し表示する（ステップ４０２）。この際、待ち時間表示欄８０４５は、スポット特徴ＤＢ１１１２のスポットリアルタイムタグ４０７０、および移動手段特徴ＤＢ１１１３のルートリアルタイムタグ７０３０の情報を取得して表示する。

更に、抽出条件変更ボタン８０７０が押下されたか否かを判定する（ステップ４０３）。抽出条件変更ボタン８０７０が押下された場合、ステップ４０４に移行し、利用者レコード単位ＵＲに抽出条件変更ボタン８０７０に入力された条件を追加して、ステップ４００の類似度演算に戻る。抽出条件変更ボタン８０７０が押下されていない場合、利用者側提案画面８０００の寄り道ボタン８０６０を押下されたか否かを判定する（ステップ４０５）。寄り道ボタン８０６０を押下された場合、寄り道要求ありと判定し、ステップ４０６に移行し、寄り道候補を検索し、抽出された寄り道候補を図１１Ｂの寄り道提案画面８０８０を生成し表示する（ステップ４０６）。寄り道候補の検索は、移動手段特徴ＤＢ１１１３の該当ルートＩＤの関連スポット７０４０を参照し、参照された内容を寄り道提案画面８０８０に表示する。

その後、ステップ４０７に移行し、利用者側提案画面８０００の予約ボタン８０５０、または寄り道提案画面８０８０の寄り道込み予約ボタン８０９０が押下されたか否かを判定する（ステップ４０７）。

予約ボタン８０５０、または寄り道込み予約ボタン８０９０のいずれかが押下された場合、ステップ４０８に移行し、各事業者サイト１２００～１２３０と情報交換することで予約処理を実行すると共に、予約処理を実行されたスポット特徴ＤＢ１１１２のレコードを利用者ＩＤに対応するレコードに転記することにより、タグ恒常化処理を実行する（ステップ４０８）。タグ恒常化処理とは、次回以降、旅行プラン提案装置１１００にアクセスする際に、当該利用者Ｕの嗜好傾向として定常的に検索可能なように、利用者設定情報１１１１ａに転記する。一例としては、図４の恒常化タグ３１００のように、利用者特徴ＤＢ１１１１のペルソナ設定３０６０に自動入力される。従って、利用者Ｕ０４が次回、旅行プランの提案を受ける際に、恒常化タグ３１００を利用者レコード単位ＵＲの一部として類似度演算時に加えられる。このようなタグ恒常化処理は、スポットＳについて適用しても良い。つまり、スポットＳの嗜好傾向として定常的に検索可能なように、来訪目的４０５０に転記する。一例としては、図６の恒常化タグ３２００のように、スポット特徴ＤＢ１１１２の来訪目的４０５０に自動入力される。従って、スポットＳ０３について次回、旅行プランの提案対象となる際に、恒常化タグ３２００をスポットレコードＳＲの一部として類似度演算時に加えられても良い。

最後に、利用者特徴タグ３０８０およびスポット特徴タグ４０８０のデータをリセットする（ステップ４０９）。このリセットの処理のタイミングは、事業者が任意に設定しても良い。また、上記タグ情報は、旅行プラン提案装置１１００にアクセスする機会毎にリセットするのではなく、利用者が終了時にリセットを選択可能としてもよい。また、次の予約処理を実行するまでは、上記タグ情報を転記した状態でもよい。

図１２のデータベース更新フローと、図１３のタグ共有処理フローを繰り返すことにより、初めて利用する利用者、または利用回数の少ない利用者は、利用者特徴ＤＢ１１１１、およびスポット特徴ＤＢ１１１２に蓄積された他の利用者の情報を基に、自身の嗜好傾向によりマッチングした旅行プラン提案情報を入手可能となる。

他方、事業者は、旅行プラン提案装置１１００の利用者特徴ＤＢ１１１１およびスポット特徴ＤＢ１１１２内の嗜好傾向の強いスポットや移動手段の情報を把握し、図５におけるスポット設定画面４０００、および図８におけるスポット特徴タグ編集画面６０００を用いて自社サイトの提供情報をより利用者の嗜好傾向に合わせてマッチングさせることが可能となり、より高い顧客誘引効果を有することが可能となる。

実施例１によれば、利用者の嗜好傾向をデータベースとして格納する利用者特徴ＤＢ１１１１と、スポットの特徴情報をデータベースとして格納するスポット特徴ＤＢ１１１２を構築し、それぞれのデータベースの関連付けられたレコードを特徴タグとして共有し、それぞれのデータベース間の類似度の高いレコードを旅行プランとして提案することにより、多種多様な事業者サイトにアクセスし、予約、購入動作を行う煩雑な操作を容易に実施可能であり、少ない利用者の情報を効率的に活用し、利用者の嗜好に適した旅行プランを提示すると共に、事業者が利用者の嗜好傾向の効率的な分析作業を可能とする。

以下に、実施例２に関して詳細を説明する。実施例１において、各事業者サイト１２００～１２３０から入手された情報は、一律に旅行プラン提案装置１１００上で取り扱われた形態を示していた。この場合、各事業者サイトの情報が、旅行プラン提案装置上で公開情報として取り扱われる。異業種の事業者間、もしくは同一業界の直接的な競合となる事業者間においては、自社の情報を他社に対して公開情報として扱われた場合、企業の機密保持の観点から問題となる場合もある。

実施例２においては、某事業者サイトの情報を他事業者に秘匿可能であるようにセキュリティ管理機能を有する旅行プラン提案システム１８００に関して説明する。

図１５は、実施例２における旅行プラン提案システム１８００のブロック図である。図１５においては、旅行プラン提案装置１６００、Ｗ市観光課サイト１６６０、複数の利用者端末１６７０から構成されるネットワークと、旅行プラン提案装置１７００、Ｙ市観光課サイト１７６０、複数の利用者端末１７７０から構成されるネットワークで構成される旅行プラン提案システム１８００を示している。

旅行プラン提案装置１６００、旅行プラン提案装置１７００は、同様の構成と機能を有しているため、旅行プラン提案装置１６００のみについて構成と機能を説明する。旅行プラン提案装置１６００は、タグ生成エンジン部１６１０、権利情報記憶部１６２０、利用者端末Ｉ／Ｆ１６３０、事業者管理Ｉ／Ｆ１６４０、事業者連携Ｉ／Ｆ１６５０から構成される。タグ生成エンジン部１６１０、権利情報記憶部１６２０、利用者端末Ｉ／Ｆ１６３０、事業者管理Ｉ／Ｆ１６４０に関しては、実施例１における図１に示されるタグ生成エンジン部１１１０、権利情報記憶部１１２０、利用者端末Ｉ／Ｆ１６３０、事業者管理Ｉ／Ｆ１６４０と同様の機能を有する。

実施例１と同様、利用者端末１６７０から旅行プラン提案装置１６００にアクセスすることで、図１５ではＷ市観光課サイト１６６０から情報提供を受けたスポット情報を検索対象として、検索結果のスポット情報を利用者に情報提供する。

一方、利用者端末１７７０から旅行プラン提案装置１７００にアクセスすることで、図１５ではＹ市観光課サイト１７６０から情報提供を受けたスポット情報を検索対象として、検索結果のスポット情報を利用者に情報提供する。

実施例２においては、Ｗ市観光課サイト１６６０の事業者と、Ｙ市観光課サイト１７６０の事業者は、お互いに秘匿したい情報があるため、利用者が旅行プラン提案装置上で提案を受けたい場合にも、旅行プラン提案装置に提供するスポット情報のセキュリティ管理を実行したいという意向がある。

この場合、事業者連携Ｉ/Ｆ１６５０は、Ｗ市観光課サイト１６６０の事業者から提供されるスポット情報の公開情報と秘匿情報を選別した上で、旅行プラン提案装置１６００上で旅行プラン提案サービスを実行する。

一方、事業者連携Ｉ/Ｆ１７５０は、Ｙ市観光課サイト１７６０の事業者から提供されるスポット情報の公開情報と秘匿情報を選別した上で、旅行プラン提案装置１７００上で旅行プラン提案サービスを実行する。

以上のように、事業者連携Ｉ／Ｆ１６５０、および事業者連携Ｉ／Ｆ１７５０は、それぞれ事業者サイトからの提供情報のセキュリティ管理を設定する機能を有し、更に設定されたセキュリティ管理に基づいて、スポット情報の公開情報と秘匿情報を選別する事業連携部である。事業者連携Ｉ／Ｆ１６５０、および事業者連携Ｉ／Ｆ１７５０によってセキュリティ管理された状態で、利用者端末１６７０、利用者端末１７７０それぞれからＷ市観光課サイト１６６０、Ｙ市観光課サイト１７６０双方のスポット特徴情報を参照した上で、それぞれの旅行プラン提案装置から旅行プラン提案サービスを提供される。

実施例２によれば、タグ生成エンジン部１６１０と、タグ生成エンジン部１７１０のそれぞれにおいて、実施例１で述べたようなデータベースの更新処理、提案処理を実行する際に、相互的にデータベース内の情報を提供し合い、スポット情報の公開情報と秘匿情報を選別した上で、利用者にとっては事業者間の隔たりのないシームレスな旅行プラン提案サービスを提供する旅行プラン提供システムを提供することが可能となる。

なお、実施例１における旅行プラン提案装置１１００は、権利情報記憶部１１２０、利用者端末Ｉ／Ｆ１６３０、事業者管理Ｉ／Ｆ１６４０、利用者特徴ＤＢ１１１１、スポット特徴ＤＢ１１１２と、移動手段特徴ＤＢ１１１３と、タグ辞書ＤＢ１１１４と、ＤＢ管理部１１１９と、タグ共有処理部１１１６と、提案情報処理部１１１５と、タグ設定管理部１１１７と、類似度演算部１１１８を基本構成として各機能部を構成しているが、複数の機能を兼用する機能部を設けてもよい。

また、図２の説明で述べたように、中央処理装置２００２上に旅行プラン提案プログラムを読み出し、上記各機能部を仮想的に構築することにより、本実施形態における機能、動作を実現可能である。

なお、実施例１では旅行プラン提案装置、実施例２では旅行プラン提案システムに関する構成と動作に関して説明を行った。しかし、実施例１、実施例２に記載される提案サービスは、利用者情報が少ない中においても、利用者の嗜好傾向に沿った提案サービスを提供するという観点で、旅行プラン提案に限らず、多種多様なオンラインショッピングの商品提案システムとして活用可能である。

１０００、１８００ ：旅行プラン提案システム
１１００、１６００、１７００ ：旅行プラン提案装置
１２００～１２３０ ：事業者サイト
１３００、１６７０、１７７０ ：利用者端末
１１１０、１６１０、１７１０ ：タグ生成エンジン部
１１１１ ：利用者特徴ＤＢ
１１１１ａ ：利用者設定情報
３０８０ ：利用者特徴タグ
３０９０ ：利用者重み
１１１２ ：スポット特徴ＤＢ
１１１２ａ ：スポット設定情報
４０７０ ：スポットリアルタイムタグ
４０８０ ：スポット特徴タグ
４０９０ ：スポット重み
１１１３ ：移動手段特徴ＤＢ
７０３０ ：ルートリアルタイムタグ
１１１４ ：タグ辞書ＤＢ
１１１５ ：提案情報処理部
１１１６ ：タグ共有処理部
１１１７ ：タグ設定管理部
１１１８ ：類似度演算部
１１１９ ：ＤＢ管理部
１１２０ ：権利情報記憶部
１６５０、１７５０ ：事業者連携Ｉ／Ｆ

Claims (8)

1. 旅行プランの提案を受ける利用者から設定される利用者設定情報と、前記利用者の嗜好傾向を示す利用者特徴タグと、を前記利用者の識別情報に対応付けて利用者レコード単位として記憶される利用者構造記憶部と、
   外部サイトから取得された前記旅行プランの候補となるスポットに関するスポット設定情報と、前記スポットの嗜好傾向を示すスポット特徴タグと、を前記スポットの識別情報に対応付けてスポットレコード単位として記憶されるスポット構造記憶部と、
   前記スポット設定情報の所在地に対応付けられた交通機関と、前記所在地に近在する関連スポットと、を前記交通機関の識別情報に対応付けて移動手段レコード単位として記憶される移動手段構造記憶部と、
   前記スポット構造記憶部に記憶される特定のスポットレコード単位を前記利用者特徴タグに転記し、前記利用者特徴タグから利用者重みを算出すると共に、前記利用者構造記憶部に記憶される特定の利用者レコード単位を前記スポット特徴タグに転記し、前記スポット特徴タグからスポット重みを算出するタグ共有処理部と、
   前記旅行プランの提案を受ける利用者に対して、前記利用者構造記憶部に記憶される前記利用者の利用者レコード単位と前記スポット構造記憶部に記憶されるスポットレコード単位との間で前記利用者重みと前記スポット重みを考慮して類似度を演算し、前記類似度の高いスポットレコード単位と前記類似度の高いスポットレコード単位に対応付けられた前記移動手段レコード単位とを前記旅行プランの候補として提案する提案画面を生成する提案情報処理部と、を備え、
   前記タグ共有処理部は、前記利用者特徴タグにおける同一利用者数をカウントし、全利用者数で正規化することにより、前記利用者重みを算出するとともに、前記スポット特徴タグにおける同一スポット数をカウントし、全スポット数で正規化することにより、前記スポット重みを算出することを特徴とする旅行プラン提案装置。
2. 前記提案情報処理部は、前記類似度を演算された前記利用者レコード単位に含まれる利用者設定情報が変更された場合、前記変更された利用者設定情報に基づいて前記類似度を再演算し、前記旅行プランの候補として再提案することを特徴とする請求項１に記載の旅行プラン提案装置。
3. 前記スポット構造記憶部に記憶されるスポットレコード単位のデータ群を参照し、統計解析機能を有するタグ設定管理部を更に備え、
   前記タグ設定管理部は、前記スポットレコード単位のデータ群を編集操作可能とすることを特徴とする請求項１に記載の旅行プラン提案装置。
4. 前記移動手段構造記憶部は、前記交通機関の所要時間を前記交通機関の識別情報に対応付けて更に記憶し、
   前記提案情報処理部は、前記交通機関の所要時間を含めて前記提案画面を生成することを特徴とする請求項１に記載の旅行プラン提案装置。
5. 前記提案情報処理部は、前記提案画面で表示されるスポットの予約処理を指示する予約指示部を前記提案画面内に生成することを特徴とする請求項１に記載の旅行プラン提案装置。
6. 前記提案情報処理部は、前記提案画面で表示されるスポットに近在する寄り道を提案する寄り道提案画面を生成することを特徴とする請求項１に記載の旅行プラン提案装置。
7. 前記スポット設定情報の類義語および派生語を複数階層で対応付けて記憶するタグ辞書構造記憶部を更に備え、
   前記タグ辞書構造記憶部を参照することにより変更されたスポット設定情報に基づいて前記旅行プランの候補を再提案することを特徴とする請求項１に記載の旅行プラン提案装置。
8. 旅行プランの提案を受ける利用者から設定される利用者設定情報と、前記利用者の嗜好傾向を示す利用者特徴タグと、を前記利用者の識別情報に対応付けて利用者レコード単位として記憶される利用者構造記憶部と、
   外部サイトから取得された前記旅行プランの候補となるスポットに関するスポット設定情報と、前記スポットの嗜好傾向を示すスポット特徴タグと、を前記スポットの識別情報に対応付けてスポットレコード単位として記憶されるスポット構造記憶部と、
   前記スポット構造記憶部に記憶される特定のスポットレコード単位を前記利用者特徴タグに転記し、前記利用者特徴タグから利用者重みを算出すると共に、前記利用者構造記憶部に記憶される特定の利用者レコード単位を前記スポット特徴タグに転記し、前記スポット特徴タグからスポット重みを算出するタグ共有処理部と、
   前記スポット設定情報に対応付けられた交通機関と、前記スポットに近在する関連スポットと、を前記交通機関の識別情報に対応付けて移動手段レコード単位として記憶される移動手段構造記憶部と、を備え、
   前記タグ共有処理部により、前記利用者特徴タグにおける同一利用者数をカウントし、全利用者数で正規化することにより、前記利用者重みを算出するとともに、前記スポット特徴タグにおける同一スポット数をカウントし、全スポット数で正規化することにより、前記スポット重みを算出する重み算出ステップと、
   前記旅行プランの提案を受ける利用者に対して、前記利用者構造記憶部に記憶される前記利用者の利用者レコード単位と前記スポット構造記憶部に記憶されるスポットレコード単位との間で前記利用者重みと前記スポット重みを考慮して類似度を演算する類似度演算ステップと、
   前記類似度の高いスポットレコード単位と、前記類似度の高いスポットレコード単位に対応付けられた前記移動手段レコード単位を前記旅行プランの候補として前記利用者に提案する提案画面を生成する提案情報処理ステップと、
   を実行することを特徴とする旅行プラン提案方法。

Images