JP2015069222A - 旅行計画作成システム - Google Patents

Abstract

【課題】個人情報保護やプライバシ保護の必要性からコンピュータへの登録が困難な旅行構成要素を組み込んだ旅行計画をコンピュータにより効率的に作成する。【解決手段】イベント提供者端末３はイベント情報を登録する。旅行者端末４は旅行者情報と旅行条件を管理サーバ１へ送信する。管理サーバ１は、旅行条件に従って各時間スロットにイベント情報を割り付けて旅行計画素案を作成する。管理サーバ１は、旅行計画素案から解決課題を抽出する。管理サーバ１は、抽出した解決課題を提案者端末４へ送信する。提案者端末５は、調整結果を管理サーバ１へ返信する。管理サーバ１は調整結果を旅行計画素案へ反映し、旅行計画素案に基づいて作成した旅行計画の承認依頼を旅行者端末４へ送信する。旅行者端末４は承認依頼に対する承認結果を管理サーバ１へ送信する。管理サーバ１は旅行計画を確定する。【選択図】図１

Description

この発明は、旅行者の要望に応じた個別注文の旅行計画をコンピュータにより効率的に作成する技術に関する。

近年、観光に対するニーズが個性化、多様化する傾向があり、従来のような団体旅行から個人旅行へと観光スタイルが変化している。一方、ウェブ上には膨大な観光情報があるが、旅行者自身が多数の観光スポットの中から訪問するスポットを選択し、様々な制約を考慮しながら、旅行計画を立てるのは困難となっている。特に、個人旅行にとって、個人情報保護やプライバシ確保を必要とする条件下での旅行計画策定は極めて困難である。

従来から、コンピュータを用いて旅行計画を作成する方法が開示されている。特許文献１の開示によれば以下のように旅行計画が作成される。まず、旅行者によって入力された旅行期間の各旅行日を複数のスロットに分割する。次に、スロットの各々に付与された特性と適合するように関連付けが定義された複数アクティビティを含む、旅行期間内に利用可能なサービスリストを作成する。次に、サービスの各々を複数スロットの各々に割り付けるにあたっての制約条件を設定する。次に、旅行計画の評価特性を表す目的関数を構成する。そして、制約条件の下で目的関数を最適化するように、サービスリストに含まれるサービスの各々を複数スロットの各々に割り付ける。特許文献１の方法では、このようにして、コンピュータを用いて旅行計画を作成する。

特許第４２６８９７３号公報

従来はインターネットなどで手軽に旅行を選ぼうとすると、予めパッケージ化された旅行計画の中から最も自分の好みに合ったものを選んで購入するのが主流であった。また、旅行計画に組み込まれているイベントが、本当に自分の希望に適合しているものなのかを、現地情報に詳しい人などの意見を参考にして確かめるようなことができなかった。

特許文献１に開示された方法では、旅行期間を単位スロットに分割し、分割したスロットに優先度を考慮してアクティビティを割り当てることで旅行計画を作成し、作成した旅行計画を旅行者に提供する。ここで、スロットにアクティビティを最適に割り当てるために混合整数計画問題を用いている。この方法では、個人情報保護やプライバシ確保などの環境条件に対する対応は考慮されていない。また、整数計画問題では、人間の提案者が評価するのと異なりコンピュータの計算時間の制限のためパラメータの選択が限定され、多種多様な旅行者の好みが反映されない。

このように、従来の技術は予め与えられた旅行構成要素のみを対象とした最適割り当て方法であり、個人情報保護やプライバシ確保の必要性から予めコンピュータへ登録することができない旅行構成要素を組み込んだ旅行計画を策定することは困難であった。

この発明の目的は、詳細な情報をコンピュータへ登録することができない旅行構成要素を組み込んだ旅行計画をコンピュータにより効率的に作成することである。

上記の課題を解決するために、この発明の旅行計画作成システムは、旅行者が利用する少なくとも１台の旅行者端末、提案者が利用する少なくとも１台の提案者端末及び管理サーバを含む。

管理サーバは、イベント情報記憶部、提案者情報記憶部、旅行条件受信部、旅行計画作成部、解決課題抽出部、提案依頼部、承認依頼部及び旅行計画確定部を含む。イベント情報記憶部は、旅行者に提供されるイベントの属性を表すイベント情報を記憶する。提案者情報記憶部は、提案者の属性を表す提案者情報を記憶する。旅行条件受信部は、旅行者の属性を表す旅行者情報と各旅行日を時間帯によって分割した複数の時間スロットそれぞれに対して旅行者が希望条件を設定した旅行条件とを旅行者端末から受信する。旅行計画作成部は、時間スロットそれぞれに対して旅行条件に合致するイベント情報を抽出して割り付けた旅行計画素案を作成する。解決課題抽出部は、旅行計画素案に割り付けられたイベント情報に基づいて解決課題を抽出する。提案依頼部は、解決課題を提案者情報と比較して提案実行者を選出し、提案実行者の利用する提案者端末へ解決課題の提案依頼を送信する。承認依頼部は、提案者端末から受信した調整結果を旅行計画素案へ反映して旅行計画を作成し、旅行計画の承認依頼を旅行者端末へ送信する。旅行計画確定部は、旅行者端末から受信する承認依頼に対する承認結果が肯定的であれば旅行計画を確定する。

提案者端末は、調整結果送信部を含む。調整結果送信部は、管理サーバから受信した提案依頼に応じて解決課題へ割り付けるイベント情報を含む調整結果を生成し、管理サーバへ調整結果を送信する。

この発明の旅行計画作成システムによれば、個人情報保護やプライバシ保護の必要性などからコンピュータへの登録ができない旅行構成要素を組み込んだ旅行計画をコンピュータにより効率的に生成することができる。例えば、旅行先でのボランティア活動や旅行先での一期一会型の団体イベントなど、イベント開催者が詳細な情報の公開を希望していないイベントを旅行計画に組み込むことが可能となり、旅行者の個人的な希望により合致した旅行計画を作成することができる。

図１は、旅行計画作成システムの機能構成を例示する図である。 図２は、管理サーバの機能構成を例示する図である。 図３は、イベント提供者端末の機能構成を例示する図である。 図４は、旅行者端末の機能構成を例示する図である。 図５は、提案者端末の機能構成を例示する図である。 図６は、旅行計画のデータ構造を例示する図である。 図７は、旅行計画の設定内容を例示する図である。 図８は、旅行計画作成システムの処理フローを例示する図である。 図９は、旅行計画作成システムの処理フローを例示する図である。 図１０は、旅行計画作成システムの処理フローを例示する図である。 図１１は、イベント情報のデータ構造を例示する図である。 図１２は、エリア番号を説明するための図である。 図１３は、イベント情報の設定内容を例示する図である。 図１４は、提案者情報のデータ構造を例示する図である。 図１５は、提案者情報の設定内容を例示する図である。 図１６は、旅行者情報及び旅行条件のデータ構造を例示する図である。 図１７は、旅行者情報の設定内容を例示する図である。 図１８は、旅行計画管理情報の設定内容を例示する図である。 図１９は、旅行計画の設定内容を例示する図である。

以下、この発明の実施の形態について詳細に説明する。なお、図面中において同じ機能を有する構成部には同じ番号を付し、重複説明を省略する。

図１を参照して、実施形態に係る旅行計画作成システムの機能構成の一例を説明する。旅行計画作成システムは、旅行を希望する人物に旅行計画を作成して提供する情報処理システムである。以降の説明では、旅行を希望する人物のことを旅行者と呼ぶ。

旅行計画作成システムは、管理サーバ１、少なくとも１台のイベント提供者端末３、少なくとも１台の旅行者端末４、N（≧1）台の提案者端末５₁,…,５_Nを含む。管理サーバ１、イベント提供者端末３、旅行者端末４及びN台の提案者端末５₁,…,５_Nはネットワーク９に接続される。ネットワーク９は、接続される各装置が相互に通信可能なように構成されていればよく、例えばインターネットやＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などで構成することができる。また、ネットワーク９を構成する物理媒体は有線／無線の別を問わず、無線ＬＡＮ、Ｗ−ＣＤＭＡ（Wideband Code Division Multiplexing Access、広帯域符号分割多重接続）やＬＴＥ（Long Term Evolution）などに代表される携帯電話回線、Bluetooth（登録商標）のような近距離無線通信などを一部に利用していてもよい。

図２を参照して、旅行計画作成システムに含まれる管理サーバ１の機能構成の一例を説明する。管理サーバ１は、制御部１０１、メモリ１０２、イベント情報登録部１０、提案者情報登録部１１、旅行条件受信部１２、旅行計画作成部１３、解決課題抽出部１４、提案依頼部１５、提案結果受信部１６、連絡手段通知部１７、調整結果受信部１８、承認依頼部１９、旅行計画確定部２０、イベント情報記憶部１１０、提案者情報記憶部１１１、旅行者情報記憶部１１２及び旅行計画記憶部１１３を含む。管理サーバ１は、例えば、中央演算処理装置（Central Processing Unit、ＣＰＵ）、主記憶装置（Random Access Memory、ＲＡＭ）等を有する公知又は専用のコンピュータに特別なプログラムが読み込まれて構成された特別な装置である。管理サーバ１は、例えば、制御部１０１の制御のもとで各処理を実行する。管理サーバ１に入力されたデータや各処理で得られたデータは、例えば、メモリ１０２に格納され、メモリ１０２に格納されたデータは必要に応じて読み出されて他の処理に利用される。管理サーバ１が備える各記憶部は、例えば、ＲＡＭ（Random Access Memory）などの主記憶装置、ハードディスクや光ディスクもしくはフラッシュメモリ（Flash Memory）のような半導体メモリ素子により構成される補助記憶装置、またはリレーショナルデータベースやキーバリューストアなどのミドルウェアにより構成することができる。管理サーバ１が備える各記憶部は、それぞれ論理的に分割されていればよい。例えば、一つの物理的な記憶装置に個々のファイルとして記憶されてもよいし、リレーショナルデータベースの一つのインスタンスに構成された個々のテーブルとして記憶されてもよい。

図３を参照して、旅行計画作成システムに含まれるイベント提供者端末３の機能構成の一例を説明する。イベント提供者端末３は、制御部３０１、メモリ３０２及びイベント情報送信部３０を含む。イベント提供者端末３は、例えば、中央演算処理装置（Central Processing Unit、ＣＰＵ）、主記憶装置（Random Access Memory、ＲＡＭ）等を有する公知又は専用のコンピュータに特別なプログラムが読み込まれて構成された特別な装置である。イベント提供者端末３は、例えば、制御部３０１の制御のもとで各処理を実行する。イベント提供者端末３に入力されたデータや各処理で得られたデータは、例えば、メモリ３０２に格納され、メモリ３０２に格納されたデータは必要に応じて読み出されて他の処理に利用される。イベント提供者端末３は、具体的には、パーソナル・コンピュータや携帯電話、スマートフォン、タブレット端末などである。

図４を参照して、旅行計画作成システムに含まれる旅行者端末４の機能構成の一例を説明する。旅行者端末４は、制御部４０１、メモリ４０２、旅行条件送信部４０、連絡手段受信部４１、調整回答部４２、承認依頼受信部４３及び承認結果送信部４４を含む。旅行者端末４は、例えば、中央演算処理装置（Central Processing Unit、ＣＰＵ）、主記憶装置（Random Access Memory、ＲＡＭ）等を有する公知又は専用のコンピュータに特別なプログラムが読み込まれて構成された特別な装置である。旅行者端末４は、例えば、制御部４０１の制御のもとで各処理を実行する。旅行者端末４に入力されたデータや各処理で得られたデータは、例えば、メモリ４０２に格納され、メモリ４０２に格納されたデータは必要に応じて読み出されて他の処理に利用される。旅行者端末４は、具体的には、パーソナル・コンピュータや携帯電話、スマートフォン、タブレット端末などである。

図５を参照して、旅行計画作成システムに含まれる提案者端末５の機能構成の一例を説明する。提案者端末５は、制御部５０１、メモリ５０２、提案者情報送信部５０、提案依頼受信部５１、提案結果送信部５２、連絡手段受信部５３、調整連絡部５４及び調整結果送信部５５を含む。提案者端末５は、例えば、中央演算処理装置（Central Processing Unit、ＣＰＵ）、主記憶装置（Random Access Memory、ＲＡＭ）等を有する公知又は専用のコンピュータに特別なプログラムが読み込まれて構成された特別な装置である。提案者端末５は、例えば、制御部５０１の制御のもとで各処理を実行する。提案者端末５に入力されたデータや各処理で得られたデータは、例えば、メモリ５０２に格納され、メモリ５０２に格納されたデータは必要に応じて読み出されて他の処理に利用される。提案者端末５は、具体的には、パーソナル・コンピュータや携帯電話、スマートフォン、タブレット端末などである。

実施形態に係る旅行計画作成システムは、図６に例示するようなデータ構造により構成される旅行計画を作成する。図６（Ａ）に示すように、旅行計画は共通データ及び少なくとも一つの旅行日ブロックから構成される。共通データにはその旅行計画を一意に識別するための識別情報である旅行ＩＤが含まれる。旅行日ブロックは旅行期間の各旅行日の旅程を記述するための領域である。図６（Ａ）の例では、二泊三日の旅行の場合を示しており、三つの旅行日ブロックから構成されている。旅行期間がより長い場合には旅行日ブロックが日数に応じて追加される。各旅行日ブロックは一つの旅行日情報及び複数の時間スロットから構成される。時間スロットは一つの旅行日を時間帯により分割したものであり、イベントを割り当てるための領域である。この例では、各旅行日ブロックは、午前中の行動を表す午前用時間スロット、昼食時の行動を表す昼食用時間スロット、午後の行動を表す午後用時間スロット、夕食時の行動を表す夕食用時間スロットの四種類の時間スロットから構成されている。イベントについては後述するが、割り当て可能なイベントには食事、観光施設、スポーツなど様々な活動分野の行動が含まれる。

図６（Ｂ）に示すように、旅行日ブロックは出発地、到着地、開始日時及び終了日時を含む。出発地はその旅行日の旅程を開始する地点を示す。到着地はその旅行日の旅程を終了する地点を示す。開始日時はその旅行日の旅程を開始する時刻を示す。終了日時はその旅行日の旅程を終了する時刻を示す。

図６（Ｃ）に示すように、時間スロットは時間スロットＩＤ、開始日時、終了日時及びイベントＩＤを含む。時間スロットＩＤはその時間スロットを一意に識別するための識別番号である。開始日時はその時間スロットの開始する時刻を示す。終了日時はその時間スロットの終了する時刻を示す。イベントＩＤはその時間スロットに割り当てられたイベントを識別するための識別情報である。この実施形態では、開始時間及び終了時間は、午前用時間スロットでは9時から12時、昼食用時間スロットでは12時から14時、午後用時間スロットでは14時から19時、夕食用時間スロットでは19時から21時が固定的に割り当てられるものとするが、旅行者により任意に設定できるように構成しても構わない。

図７に旅行計画作成システムにより作成された最終的な旅行計画の一例を示す。図７の例は、旅行ＩＤとして「TR0001」を割り当てられた旅行計画の一日目の旅程を表している。この例では、「2013年2月24日7時30分」に「京都」から旅程を開始し、「2013年2月24日21時30分」に「大阪」で旅程を終了する。午前中は、イベントＩＤとして「EVT1001」を割り当てられたイベントに、9時から12時まで参加する。昼食はイベントＩＤとして「EVT0001」を割り当てられたイベントに、12時から14時まで参加する。午後はイベントＩＤとして「EVT1004」を割り当てられたイベントに、14時から19時まで参加する。夕食はイベントＩＤとして「EVT0003」を割り当てられたイベントに、19時から21時まで参加する。通常、午前中と午後のイベントは美術鑑賞、観劇、コンサートなどのイベントが割り当てられ、昼食と夕食のイベントは食事のイベントが割り当てられるが、旅行者の希望により自由に設定可能でありこの限りではない。

図８〜１０を参照して、旅行計画作成システムが実行する旅行計画作成方法の処理フローの一例を、実際に行われる手続きの順に従って説明する。図８に示す「A1」「B1」「C1」「D1」の各符号は、図９に示す「A1」「B1」「C1」「D1」の各符号へそれぞれ処理が継続することを表している。図９に示す「B2」の符号は、図８に示す「B2」の符号に処理が継続することを表している。図９に示す「A2」「B3」「C2」「D2」の各符号は、図１０に示す「A2」「B3」「C2」「D2」の各符号へそれぞれ処理が継続することを表している。図１０に示す「B2」「B4」の符号は、図８に示す「B2」「B4」の符号に処理が継続することを表している。

ステップＳ３０において、イベント提供者はイベント提供者端末３を用いてイベント情報を作成し、そのイベント情報を旅行計画作成システムへ登録する。イベント情報は、旅行者へ提供するイベントの属性を記述した情報である。イベント提供者は、例えば、イベント提供者端末３に表示される入力画面から必要な情報を入力することでイベント情報を作成する。具体的には、入力画面は、イベント提供者端末３にインストールされたウェブブラウザにロードされたウェブページ、もしくはイベント提供者端末３にインストールされた独自のアプリケーションのウィンドウである。イベント提供者端末３に含まれるイベント情報送信部２０は作成したイベント情報を管理サーバ１へ送信する。

図１１にイベント情報の入力項目の一例を示す。「入力項目」欄は、入力項目の名称を表す。「入力形式」欄は、その入力項目を入力する際の入力方法を表す。「説明」欄には、その入力項目の詳細な内容を記載している。「データ例」欄には、各入力項目に実際に設定される値の一例を示している。

「入力形式」欄における「メニュー選択」は、操作者がプルダウン形式のメニュー選択やチェックボックス形式の項目選択により、予め定められた候補値の中から適切な入力値を選択する入力方法である。「定型入力」は、日時や人数、金額などの数字を直接入力する入力方法である。「自由記入」は、操作者が例えばキーボードなどを用いて任意の文字列を入力する入力方法である。以降の説明においても、「入力形式」欄における各記載は同様の操作を表すものとする。

各入力項目の入力画面上での配置や入力形式については、操作者の利便性を考慮して適宜設計すればよい。以降の入力項目に関する説明においても同様である。

以下、イベント情報の入力項目についてより詳細に説明する。「イベント提供者ＩＤ」は、イベント提供者を一意に識別するための識別番号である。「イベント提供者ＩＤ」は、あらかじめ旅行計画作成システムにより割り当てられている。「活動分野」は、旅行に組み込まれるイベントの大まかな活動の種類を表す情報である。例えば、食事や美術鑑賞、観劇、コンサート、スポーツなどが該当する。「活動分野」は、メニュー選択の形式で入力される。「イベント名」は、活動分野をさらに細分化した区分を表す情報である。例えば、活動分野が食事の場合、イタリア料理やフランス料理、中華料理、和食などが該当する。「イベント名」は、メニュー選択の形式で入力される。「開催場所」は、そのイベントの開催場所（例えば、会場名など）が自由記入で入力される。ただし、事前登録された情報を参照することによって、活動分野、イベント名、開催場所を限定して候補名や地図上の場所を示してもよい。「開催エリア」は、地理的な場所を所定の区画に区切って識別できるようにしたものである。「イベントタイプ」は、登録しようとするイベントの開催期間が特定期間に限定されているか否かを識別するためのフィールドであり、情報を公開可能な「公開型」と個人情報やセキュリティの関係で公開できない「非公開型」に分類される。「公開型」のイベントタイプは、さらに、期間に限定がある場合を表す「個別型」、期間に限定がない場合を表す「任意型」に分類される。すなわち、イベントタイプには「個別型」「任意型」「非公開型」のいずれかが設定される。「参加資格」には、そのイベントに参加するために旅行者が満たすべき条件（例えば、年齢制限など）が設定される。「推奨条件」には、そのイベントに参加するために旅行者が満たしていることが望ましい条件（例えば、対象年齢など）が設定される。「参加定員数」にはそのイベントに参加可能な人数が設定される。参加可能数に制限がない場合には「制限なし」を示す数字として「0」が設定される。なお、イベント情報にはイベント提供者が任意に写真などのファイルを添付してもよい。

「開催エリア」の設定内容の一例をより詳細に説明する。図１２に示すように、携帯電話網６は、例えば、複数の基地局６０１〜６０７から構成される。エリアとは、一つ以上の近接する基地局からなる通信可能領域を区画の単位として分割した地理的範囲である。図１２の例では、エリア６１は基地局６０１〜６０３からなり、エリア６２は基地局６０４からなり、エリア６３は基地局６０５からなり、エリア６３は基地局６０６〜６０７からなる。各エリアにはエリア番号と呼ばれる一意の識別番号を割り当てておき、「開催エリア」には開催場所の施設が属するエリアのエリア番号を設定する。以降の説明においても、エリア番号とは、図１２に示すように、通信可能領域により地理的に分割した区画に割り当てられた識別番号を示している。また、開催エリアは国土地理院の地域メッシュ、日本郵便の郵便番号、市区町村などでもよい。

「イベントタイプ」の設定内容をより詳細に説明する。「個別型」のイベントタイプでは、開始日時及び終了日時のフィールドに特定の年月日の特定の時刻が設定される。一定の期間、同一内容の活動が繰り返し開催される形態のイベントの場合は、イベントタイプを「任意型」とし、一回の開催を一つのイベントとして登録する。例えば、複数回開催されるミュージカルの場合、一つの演目が一日に複数回、それが複数の日にわたって開催されるが、公演一回ずつが一つのイベントとして登録される。美術館、テーマパークを利用したり、ショッピングをしたりする活動のように参加する開始時刻及び終了時刻が任意である場合、イベントタイプを「任意型」と設定して、開始日時及び終了日時のフィールドには利用可能時間（例えば、開館時間や閉館時間など）のみが設定される。

「非公開型」のイベントタイプでは、イベントの詳細な情報を公開せずに登録する。「非公開型」に設定されたイベントは、後述する解決課題の要請に基づき、提案者を介して詳細なイベントの開催条件が調整される。例えば、ボランティア活動のイベントでは介護支援や瓦礫撤去などが考えられる。このようなイベントの調整に必要な情報には、支援に必要なスキルや支援先の置かれている状況、支援を必要とする場所の住所、依頼者の氏名など機密性の高い個人情報が多数含まれるため、詳細な情報は公開せず調整窓口のみを公開する場合がある。その他に「非公開型」で登録するイベントとしては、茶道教室や華道教室など格式をもったコーディネートを必要とするため、詳細は公開せず調整窓口のみを公開する場合もあるし、イベントの主催者の自宅など公共施設ではない場所や住宅街の隠れ家的な施設などセキュリティ上の観点から公開を望まない場合もある。どのような場合に「非公開型」と設定するかは、そのイベントの情報を登録するイベント提供者が決定すべき事項であるため、「非公開型」に設定されるイベントは上述に限定されない。

ステップＳ１０において、管理サーバ１に含まれるイベント情報登録部１０は、イベント提供者端末３から受信したイベント情報をイベント情報記憶部１１０へ記憶する。イベント情報記憶部１１０へ記憶されたイベント情報は、イベント提供者ＩＤ等により特定されたイベント提供者によって編集や削除を行うことができるものとする。

図１３にイベント情報記憶部１１０に記憶されたイベント情報の一例を示す。図１３の例は、イベント提供者ＩＤとして「EV1030」を割り当てられたイベント提供者が、図１１のデータ例に示した新たなイベントを登録した状態を表している。イベント情報登録部１０は、イベント情報送信部２０からのイベント情報を取得すると、旅行計画作成システム内でそのイベントを一意に識別するためのイベントＩＤを生成し、「イベントＩＤ」フィールドへ設定する。この例では、イベントＩＤは「EVT1003」が生成されたものとする。続いて、イベント情報登録部１０は、取得したイベント情報の各入力値を対応するフィールドへ設定する。この例では、活動内容が「観劇」であり、イベント名は「ミュージカルBB」であり、イベントタイプは開催期間に制限があることを表す「個別型」であり、イベント期間は「2013年2月23日15時」から「2013年2月23日18時」であり、開催場所は「EE劇場」であり、開催エリアは「エリア２」である。また、利用料金は「20,000（円）」であり、参加定員は「500（名）」である。さらに、参加資格に関して「年齢が12歳以上」という制約が設定されている。

図１３に示すイベント情報の登録例では参加定員数が定められているため、イベントへの参加者の予約状況を管理するために、仮予約数、準予約数及び本予約数のフィールドが作成される。これらのフィールドの使用方法は後述するが、イベント情報が登録された初期状態では各フィールドの値はゼロに設定される。イベントに参加定員が定められていない場合には予約状況を管理する必要がないため、仮予約数、準予約数及び本予約数のフィールドを作成しなくともよい。

ステップＳ５０において、提案者は提案者端末５を用いて提案者情報を作成し、その提案者情報を旅行計画作成システムへ登録する。提案者情報は、提案者の属性を記述した情報である。提案者は、例えば、提案者端末５に表示される入力画面から必要な情報を入力することで提案者情報を作成する。具体的には、入力画面は、提案者端末５にインストールされたウェブブラウザにロードされたウェブページ、もしくは提案者端末５にインストールされた独自のアプリケーションのウィンドウである。提案者端末５に含まれる提案者情報送信部５０は作成した提案者情報を管理サーバ１へ送信する。

図１４に提案者情報の入力項目の一例を示す。「性別」は、提案者の性別であり、男／女から選択する。「年齢」は、提案者の年齢であり、数値を入力する。「居住地域」は、提案者の居住する地域のエリア番号である。「支援地域」は、提案者が豊富な知識を持っており詳しい判断ができる地域のエリア番号である。「支援活動分野」は、提案者が豊富な知識を持っており詳しい判断ができる活動分野を選択する。「連絡用通信手段」は、提案者が旅行者とイベントの詳細な内容について調整するために用いる通信手段を選択する。例えば、固定電話、携帯電話、メールなどが選択可能である。「連絡手順」は、提案者が旅行者と連絡する際に、いずれから連絡を行うことを希望するかを選択する。例えば、提案者から連絡する（「提案者から」）、旅行者から連絡する（「旅行者から」）、いずれから連絡してもよい（「自由」）などが選択可能である。「連絡時間帯」は、提案者が連絡可能な時間帯を入力する。「通信アドレス」は、調整連絡に用いる通信手段において提案者を識別するためのアドレスである。例えば、固定電話や携帯電話であれば電話番号であり、メールであればメールアドレスとなる。

ステップＳ１１において、管理サーバ１に含まれる提案者情報登録部１１は、提案者端末５から受信した提案者情報を提案者情報記憶部１１１へ記憶する。提案者情報記憶部１１１へ記憶された提案者情報は、後述する提案者ＩＤ等により特定されたイベント提供者によって編集や削除を行うことができるものとする。

図１５に提案者情報記憶部１１１に記憶された提案者情報の一例を示す。図１５の例は、提案者情報が登録されていない新たな提案者が、図１４のデータ例に示した新たな提案者情報を登録した状態を表している。提案者情報登録部１１は、提案者情報送信部５０からの提案者情報を取得すると、旅行計画作成システム内でその提案者を一意に識別するための提案者ＩＤを生成し、「提案者ＩＤ」フィールドへ設定する。この例では、提案者ＩＤは「10003」が生成されたものとする。続いて、提案者情報登録部１１は、取得した提案者情報の各入力値を対応するフィールドへ設定する。この例では、新たな提案者は「55歳」の「女性」であり、「エリア２」に居住しており、「エリア４」の詳しい知識を持っており、「ボランティア活動」の豊富な知識を有している。また、「固定電話」を用いて「提案者から」調整のための連絡を行うことを希望しており、「20時から21時の間」に調整連絡を行うことができる。連絡に用いる固定電話の電話番号は「0774-54-XXXX」である。

提案者情報に含まれる居住地域や支援地域、連絡用通信手段、連絡手順、連絡時間帯、通信アドレスなどの登録内容は、提案者により編集することが可能である。提案者情報が更新された場合には更新前の情報を異なる領域に記憶する。更新前の情報は過去全ての情報を保持するように構成してもよいし、一定の世代数（例えば、五世代分など）もしくは一定期間の情報を保持するように構成してもよい。過去の情報は提案者情報の追加のフィールドとして保持してもよいし、例えば提案者情報履歴として時系列に記憶するように構成してもよい。

提案者情報には、その提案者が旅行構成要素を提案した履歴を格納するための「提案履歴」フィールドが設けられる。「提案履歴」には、管理サーバ１がその提案者に提案依頼を送信した旅行計画を示す旅行ＩＤ、管理サーバ１がその提案者に提案依頼を送信した日時を示す依頼日時、管理サーバ１がその提案者から提案結果を受信した日時を示す回答日時、旅行者が旅行計画の承認時に入力する評価値を示す利用者評価が格納される。この評価値は、例えば、旅行者により入力される五段階の得点である。「提案履歴」は、管理サーバ１からその提案者に新たに提案依頼が送信される度にフィールドが追加されていく。図１５の例では、提案者ＩＤが「10003」の提案者は新たに登録されたばかりであって未だ旅行計画への提案を行なっていないため提案履歴がない。提案者ＩＤが「10001」の提案者は過去に二つの旅行計画へ提案を行っており、提案者ＩＤが「10002」の提案者は過去に一つの旅行計画へ提案を行っていることがわかる。

ステップＳ４０において、旅行者は旅行者端末４を用いて旅行者情報及び旅行条件を作成し、その旅行者情報及び旅行条件を管理サーバ１へ送信する。旅行者情報は、旅行者の属性を記述した情報である。旅行条件は、旅行者が旅程の中で参加したいイベントの条件を記述した情報である。旅行者は、例えば、旅行者端末４に表示される入力画面から必要な情報を入力することで旅行者情報及び旅行条件を作成する。具体的には、入力画面は、旅行者端末４にインストールされたウェブブラウザにロードされたウェブページ、もしくは旅行者端末４にインストールされた独自のアプリケーションのウィンドウである。旅行者端末４に含まれる旅行条件送信部４０は作成した旅行者情報及び旅行条件を管理サーバ１へ送信する。

図１６に旅行者情報及び旅行条件の入力項目の一例を示す。入力項目は、旅行者情報と旅行条件に分けられる。旅行者情報には旅行者の属性に関する情報を入力する。旅行条件は、旅行日ごとにブロック分けされる。各ブロックにはその旅行日の基本情報と複数の時間スロットが含まれる。

以下、旅行者情報の入力項目についてより詳細に説明する。「氏名」は、旅行者の氏名を入力する。「連絡先」は、旅行者の住所、電話番号等の連絡先を入力する。「性別」は旅行者の性別であり、男／女から選択する。「年齢」は旅行者の年齢であり、数値を入力する。「趣味」は、旅行者の趣味を選択する。「旅行費用上限」は、旅行全体の予算の上限額であり、数値を入力する。「要望事項」は、旅行者が旅行に対して要望する特別な事項を入力する自由記入欄である。この例では、旅行者「A山B子」は「○○町」に居住する「53（歳）」の「女性」であり、「美術鑑賞」と「音楽」を趣味とし、旅行の予算が「70,000（円）」であり、車椅子を使用していることがわかる。

以下、旅行条件の入力項目についてより詳細に説明する。「年月日」は、その旅行日の日付である。「出発地」は、その旅行日の旅程を開始する地域である。「到着地」は、その旅行日の旅程を終了する地域である。この例では、時間スロットは、午前、昼食、午後及び夕食の四種類が用意されている。各時間スロットには、その時間帯に訪問したいエリアと、参加したい活動分野を入力する。図１６では一日目のみが記載されているが、旅行が複数日に及ぶ場合には、日数分の旅行日のブロックが追加される。この例では、旅行の一日目にあたる「2013年2月24日」には、「京都」を出発して「大阪」へ到着し、午前中は「エリア４」において「ボランティア活動」に参加することを希望していることがわかる。

ステップＳ１２において、管理サーバ１に含まれる旅行条件受信部１２は、旅行者端末４から受信した旅行者情報を旅行者情報記憶部１１２へ記憶し、旅行者端末４から受信した旅行条件に基づいて作成した旅行計画管理情報を旅行計画記憶部１１３へ記憶する。旅行者情報記憶部１１２へ記憶された旅行者情報及び旅行計画記憶部１１３へ記憶された旅行計画管理情報は、後述する旅行者ＩＤ等により本人特定された旅行者のみが参照可能なように記憶される。この際、セキュリティの観点から参照可能な情報を限定するように構成してもよい。

図１７に旅行者情報記憶部１１２に記憶された旅行者情報の一例を示す。図１７の例は、図１６のデータ例に示した新たな旅行者情報を登録した状態を表している。旅行条件受信部１２は、旅行条件送信部３０からの旅行者情報を取得すると、旅行計画作成システム内でその旅行者を一意に識別するための旅行者ＩＤを生成し、「旅行者ＩＤ」フィールドへ設定する。この例では、旅行者ＩＤは「TRT9001」が生成されたものとする。続いて、旅行条件受信部１２は、取得した旅行者情報の各入力値を対応するフィールドへ設定する。

図１８に旅行条件記憶部１１３に記憶された旅行計画管理情報の一例を示す。図１８のデータ例（１）は、旅行者ＩＤが「TRT9001」である旅行者が作成した、図１６のデータ例に示した旅行条件に従って登録された旅行計画管理情報を表している。旅行条件受信部１２は、旅行条件送信部４０からの旅行条件を取得すると、旅行計画作成システム内でその旅行計画管理情報を一意に識別するための旅行ＩＤを生成し、「旅行ＩＤ」フィールドへ設定する。この例では、旅行ＩＤは「TR0001」が生成されたものとする。続いて、旅行条件受信部１２は、取得した旅行条件の各入力値を対応するフィールドへ設定する。この例では、この旅行計画管理情報に紐づく旅行者ＩＤは「TRT9001」であり、午前中の行動を表す時間スロット１は希望エリアが「エリア４」であり、希望活動分野が「ボランティア活動」である。また、昼食を表す時間スロット２は希望エリアが「エリア２」であり、希望活動分野が「食事」である。つまり、旅行者「TRT9001」は午前中にエリア４が割り当てられた区画でボランティア活動を行い、エリア２が割り当てられた区画に移動して昼食にすることを希望していることがわかる。

旅行条件受信部１２は、後の処理に用いられる「イベントＩＤ」「解決課題ＩＤ」「提案者ＩＤ」「集合場所」「集合時間」などの各フィールドを追加する。この段階では、これらのフィールドには値が設定されない。これらのフィールドの用途については後述する。

ステップＳ１３ａにおいて、管理サーバ１に含まれる旅行計画作成部１３は、旅行計画管理情報の各時間スロットに対して旅行条件に合致するイベント情報を抽出して割り付けることで旅行計画素案を作成する。イベント割り付け後の旅行計画管理情報の例を図１８のデータ例（２）に示す。登録時の旅行計画管理情報である図１８のデータ例（１）との相違点は、各時間スロットのイベントＩＤに値が設定されていることである。

イベントの割り付け方法は、具体的には、以下のように行う。すなわち、旅行計画管理情報の各時間スロットについて、開始日時、終了日時、希望エリア及び希望活動分野を取得し、これらをキーとして以下の四つの条件をすべて満たすイベント情報を抽出する。
（１）時間の合致判定
旅行計画管理情報の時間スロットの開始日時及び終了日時の値を、イベント情報記憶部１１０に記憶されている個々のイベント情報の開始日時及び終了日時の値と照合する。照合対象のイベント情報に含まれるイベントタイプが「個別型」の場合は、イベントの開始日時から終了日時までの期間が、時間スロットの開始日時から終了日時までの期間に包含されることを合致の条件とする。イベントタイプが「任意型」の場合は、時間スロットの開始日時及び終了日時とイベント情報の開始日時及び終了日時とを、時間部分のみで比較する。すなわち、時間スロットの開始時刻から終了時刻までの時間帯がイベント情報の開始時刻から終了時刻までの時間帯に包含されることを合致の条件とする。
（２）活動エリアの合致判定
旅行計画管理情報の希望エリアの値がイベント情報の開催エリアの値と一致することを合致の条件とする。
（３）活動分野の合致判定
旅行計画管理情報の希望活動分野の値がイベント情報の活動分野の値と一致することを合致の条件とする。
（４）定員数の確認
イベント情報に前述の定員数が設定されている場合には、定員に空きがあることを合致の条件とする。定員に空きがある状態とは、仮予約数、準予約数及び本予約数の合計数が定員数を超えていない状態である。

合致するイベント情報が複数抽出された場合は、例えば、抽出されたイベント情報の利用料金に基づいて一つのイベントを選択するとよい。具体的には、抽出された複数のイベント情報の利用料金の平均値を算出し、利用料金がその平均値に最も近いイベント情報を選択する方法をとることができる。

もしくは、合致するイベント情報が複数抽出された場合に、選択可能なイベント候補として複数のイベント情報を割り付けてもよい。詳しくは後述するが、この場合には、複数のイベント候補から提案実行者が適切なイベントを選択するようにする。

このようにしてイベント情報の選択が完了すると、そのイベントＩＤを対象の時間スロットの「イベントＩＤ」フィールドに書き込む。例えば、図１８に示した時間スロット１を図１３に示したイベント情報と照合すると、活動分野が「ボランティア活動」であり、イベントＩＤが「EVT9001」であるイベント情報が抽出される。また、図１８に示した時間スロット２を図１３に示したイベント情報と照合すると、活動分野が「食事」であり「エリア２」で開催される、イベントＩＤが「EVT0001」であるイベント情報が抽出される。

ステップＳ１３ａの処理は、旅行者やイベント提供者などが実行するように構成してもよい。作成される旅行計画素案は旅程全体を一度に作成してもよいし、日単位や時間帯単位のように一部分のみを作成して保留しておくなど、追記、変更などの数度の操作を繰り返して最終的に旅行計画素案を完成してもよい。旅行者やイベント提供者が旅行計画素案を作成する場合には、ステップＳ１０以降の任意のタイミングで実行することができる。

ステップＳ１３ｂにおいて、旅行計画作成部１３は、時間スロットに割り当てたイベント情報に定員数が設定されていた場合、そのイベントの仮予約を行う。具体的には、イベント情報記憶部１１０に記憶されたイベント情報の仮予約数フィールドの値に旅行者の人数を加算する。また、必要に応じて、イベント提供者の運用する予約管理システム等と連携して、仮予約を実行してもよい。

ステップＳ１４において、管理サーバ１に含まれる解決課題抽出部１４は、旅行計画素案から解決課題を抽出する。具体的には、旅行計画素案に含まれる各時間スロットに割り付けられたイベントのうち、イベントタイプが「非公開」であるものを抽出し、一意に識別するための解決課題ＩＤを生成する。解決課題を抽出した後の旅行計画管理情報の例を図１８のデータ例（３）に示す。イベント割り付け後の旅行計画管理情報である図１８のデータ例（２）との相違点は、「非公開」タイプのイベントが割り付けられた時間スロットの課題解決ＩＤフィールドに値が設定されていることである。この例では、時間スロット１に非公開のイベントである「ボランティア活動」が割り付けられており、解決課題ＩＤ１に「TRS0001」が設定されていることがわかる。

ステップＳ１５ａにおいて、管理サーバ１に含まれる提案依頼部１５は、解決課題に対して旅行構成要素の提案を行う提案実行者を提案者情報に登録されている提案者から選出する。具体的には、提案実行者の選出方法は以下のように行う。すなわち、解決課題ＩＤが設定された時間スロットの希望活動分野及び希望開催エリアを取得し、これらをキーとして以下の三つの条件のいずれかを満たす提案者情報を抽出する。
（１）活動分野の合致性
解決課題ＩＤが設定された時間スロットの希望活動分野フィールドのうち少なくとも一つの値が、提案者情報の支援活動分野フィールドに設定された値と一致することを合致の条件とする。
（２）エリアの合致性
解決課題ＩＤが設定された時間スロットの希望エリアフィールドのうち少なくとも一つの値が、提案者情報の居住地域フィールドあるいは支援地域フィールドの少なくとも一つの値と一致することを合致の条件とする。
（３）通信手段の合致性
さらに、プライバシに配慮した運用として、通信手段の合致性を含めることもできる。旅行計画管理情報の希望通信手段フィールドに設定された値が、提案者情報の連絡用通信手段フィールドの値と一致することを合致の条件とする。

以上の合致性の判定に基づいて、一致する項目数の多い提案者を抽出して提案実行者として選出する。このとき優先順位は、活動分野、エリア、通信手段の順とする。つまり、二つの項目が合致する二名の提案者が抽出されたとして、一方は活動分野及び通信手段が合致し、他方はエリア及び通信手段が合致した場合であれば、優先順位の高い活動分野が一致している前者が優先的に抽出されることになる。その上でさらに複数の提案者が抽出された場合には、その複数の提案者全員を選出してもよいし、提案者情報の提案履歴フィールドを参照して、提案実施回数が多く、旅行者の評価が高い提案者を優先的に抽出してもよい。例えば、図１８のデータ例（３）に示す時間スロット１の解決課題へ提案を行う提案実行者を図１５に示す提案者情報から抽出するのであれば、活動分野が「ボランティア活動」であり、支援地域が「エリア４」である提案者「10003」が提案実行者として抽出されることになる。

ステップＳ１５ｂにおいて、提案依頼部１５は、選出した提案実行者が利用する提案者端末５へ解決課題の提案依頼を送信する。提案依頼は例えば提案実行者のメールアドレスへその解決課題を含む旅行計画素案のＵＲＬ（Uniform Resource Location）がハイパーリンクとして記載された通知メールを送信するなどの方法により行われる。

提案依頼部１５は、さらに、提案依頼を送信した提案実行者に関する提案者情報の提案履歴フィールドへ提案依頼を行った旅行ＩＤ及び依頼日時を設定する。

ステップＳ５１において、提案者端末５に含まれる提案依頼受信部５１は、管理サーバ１から受信した提案依頼が示す旅行計画素案の内容を、例えば、提案者端末５に表示される提案画面に表示する。提案依頼の受信は、例えば、提案実行者が受信した通知メールに記載されたＵＲＬ（Uniform Resource Location）をクリックするなどの方法により実行される。具体的には、提案画面は、提案者端末５にインストールされたウェブブラウザにロードされたウェブページ、もしくは提案者端末５にインストールされた独自のアプリケーションのウィンドウである。

ステップＳ５２において、提案実行者は、提案者端末５に表示される提案画面から旅行計画素案を確認し、解決課題への提案が可能か否かを回答する。提案者端末５に含まれる提案結果送信部５２は、提案者が提案画面上で入力した提案可否を示す提案結果を管理サーバ１へ送信する。

ステップＳ１６ａにおいて、管理サーバ１に含まれる提案結果受信部１６は、提案者端末５から提案結果を受信する。提案結果が提案可能であった場合、旅行計画管理情報の提案者ＩＤフィールドへ提案結果を受信した提案実行者の提案者ＩＤを設定する。提案結果受信部１６は、さらに、提案結果を受信した提案実行者に関する提案者情報の提案履歴フィールドへ回答日時を設定する。

ステップＳ１６ｂにおいて、提案結果受信部１６は、受信した提案結果が提案可能であったか否かを確認する。提案結果が提案可能であった場合、次のステップＳ１７へ処理を進める。提案結果が提案不可であった場合、もしくは提案者端末５から提案結果を受信せずに予め定めた受信待ち時間を経過した場合には、ステップＳ１５ａへ処理を戻す。受信待ち時間は、例えば、一日（24時間）などに設定する。再度実行するステップＳ１５ａにおいて、提案依頼部１５は、解決課題に対して旅行構成要素の提案を行う提案実行者を提案者情報に登録されている提案者から選出する。この際、前回選出した提案者とは異なる提案者が選出されるようにしなければならない。

ステップＳ１７において、管理サーバ１に含まれる連絡手段通知部１７は、旅行者情報に含まれる調整連絡手段を提案実行者の利用する提案者端末５へ通知する。また、連絡手段通知部１７は、提案者情報に含まれる調整連絡手段を旅行者の利用する旅行者端末４へ通知する。調整連絡手段とは、旅行者と提案実行者との間で行われる調整連絡の条件を規定する情報である。以降では、提案者端末５へ送信する調整連絡手段は提案者向け連絡手段と呼び、旅行者端末４へ送信する調整連絡手段は旅行者向け連絡手段と呼ぶ。

提案者向け連絡手段と旅行者向け連絡手段の具体的な内容は、連絡手順により異なる。例えば、連絡手順が「提案者から」であった場合、提案者向け連絡手段には、旅行者情報に含まれる希望通信手段及び連絡先が設定され、旅行者向け連絡手段には、提案者から連絡があることを示す情報が設定される。また例えば、連絡手順が「旅行者から」であった場合、旅行者向け連絡手段には、提案者から連絡があることを示す情報が設定され、旅行者向け連絡手段には、提案者情報に含まれる連絡用通信手段、連絡時間帯及び通信アドレスが設定される。

ステップＳ５３において、提案者端末５に含まれる連絡手段受信部５３は、管理サーバ１から送信された提案者向け連絡手段を受信する。また、ステップＳ４１において、旅行者端末４に含まれる連絡手段受信部４１は、管理サーバ１から送信された旅行者向け調整連絡手段を受信する。

ステップＳ５４及びステップＳ４２において、提案者端末５に含まれる調整連絡部５４及び旅行者端末４に含まれる調整回答部４２は、受信した提案者向け連絡手段及び旅行者向け連絡手段の情報に基づいて、通信手段を確保する。通信手段を確保する方法は、通信手段及び連絡手順により異なる。例えば、通信手段が「固定電話」であり連絡手順が「提案者から」であった場合、旅行者は提案者から固定電話へ電話がかかってくるまで待機し、提案者は提案者向け連絡手段の連絡先へ固定電話から電話をかける。また例えば、通信手段が「メール」であり連絡手順が「旅行者から」であった場合、提案者は旅行者からメールを受信するまで待機し、旅行者は旅行者向け連絡手段の通信アドレスを宛先にしてメールを送信する。

旅行者端末４と提案者端末５との間の通信手段が確保されると、調整連絡部５４及び調整回答部４２は、その通信手段を用いて、協調してイベントの詳細条件を調整する。例えば、解決課題の活動分野が「ボランティア活動」であれば、ボランティア内容、ボランティア場所への案内人、その際の集合場所、集合時間、目印などの諸条件を調整する。

ステップＳ５５において、提案者端末５に含まれる調整結果送信部５５は、旅行者端末４との間で調整した結果を管理サーバ１へ送信する。この際、調整が不成立であった場合であっても、その旨を示す調整結果を送信する。調整が成立した場合には、決定したイベントの詳細条件を調整結果に設定する。

ステップＳ１８ａにおいて、管理サーバ１に含まれる調整結果受信部１８は、提案者端末５から調整結果を受信する。調整結果受信部１８は、受信した調整結果が調整の成立を示す場合には、調整結果に含まれるイベントの詳細条件を旅行計画素案へ反映する。調整結果を反映した後の旅行計画管理情報の例を図１８のデータ例（４）に示す。解決課題を抽出した後の旅行計画管理情報である図１８のデータ例（３）との相違点は、課題解決ＩＤが設定された時間スロット１にイベントの詳細条件が設定されていることである。具体的には、提案を行った提案実行者の提案者ＩＤとして「10003」が、ボランティ活動の集合場所として「エリア４内Ｂ地点」が、ボランティ活動の集合時間として「8時30分」が、それぞれ設定されていることがわかる。調整結果受信部１８は、さらに、調整結果を送信した提案実行者に関する提案者情報の提案履歴フィールドへ回答日時を設定する。

ステップＳ１８ｂにおいて、調整結果受信部１８は、調整結果が成立であったか不成立であったかを判定する。調整結果が成立を示す場合には、次のステップＳ１９ａへ処理を進める。一方、調整結果が不成立を示す場合には、ステップＳ１５ａへ処理を戻す。再度実行するステップＳ１５ａにおいて、提案依頼部１５は、解決課題に対して旅行構成要素の提案を行う提案実行者を提案者情報に登録されている提案者から選出する。この際、前回選出した提案者とは異なる提案者が選出されるようにしなければならない。

ステップＳ１９ａにおいて、管理サーバ１に含まれる承認依頼部１９は、旅行計画素案に基づいて旅行計画を作成し、その承認依頼を旅行者端末４へ送信する。承認依頼は、例えば、旅行者のメールアドレスへその旅行計画のＵＲＬ（Uniform Resource Location）がハイパーリンクとして記載された通知メールを送信するなどの方法により行われる。旅行計画の一例を図１９のデータ例に示す。この例は、図１８のデータ例（４）に示す最終的な旅行計画管理情報に対して、図１３に示すイベント情報からイベント名、開催場所などの情報を補完することで、旅行者にとって内容を理解し易いように整形した情報である。

ステップＳ１９ｂにおいて、承認依頼部１９は、時間スロットに割り当てたイベント情報に定員数が設定されていた場合、イベント情報の仮予約数フィールドの値から旅行者の人数を減算し、準予約数フィールドの値に旅行者の人数を加算する。また、必要に応じて、イベント提供者の運用する予約管理システム等と連携して、準予約を実行してもよい。

ステップＳ４３において、旅行者端末４に含まれる承認依頼受信部４３は、受信した承認依頼が示す旅行計画の内容を、例えば、旅行者端末４に表示される承認画面に表示する。承認依頼の受信は、例えば、旅行者が受信した通知メールに記載されたＵＲＬ（Uniform Resource Location）をクリックするなどの方法により実行される。承認画面は、旅行者端末４にインストールされたウェブブラウザにロードされたウェブページ、もしくは旅行者端末４にインストールされた独自のアプリケーションのウィンドウである。

ステップＳ４４において、旅行者は、旅行者端末４に表示される承認画面を用いて旅行計画の内容を確認し、承認するか否かを決定する。このとき、旅行者が報酬を支払うことで旅行計画の詳細が確認可能としてもよい。すなわち、無課金で旅行計画を確認した場合には旅行計画の概要のみが表示されたり、イベント名のみが確認できイベント情報の詳細を確認するために別の画面で表示しなければいけないなど手間が掛かる画面構成にしたりしておき、旅行者により報酬が支払われて初めて旅行計画の詳細が容易に確認可能な承認画面が表示されるように構成する。旅行者は旅行計画が適正であると判断した場合には、肯定的な承認結果を入力し、旅行計画が不適であると判断した場合には、否定的な承認結果を入力する。このとき、旅行者は旅行計画に対する満足度を、例えば五段階で入力する。評価値は様々な評価軸による複数の評価値の集合としてもよい。例えば、お手軽度、自慢度、マニアック度などを評価軸として、それぞれについて複数段階の評価値を入力するように構成する。承認結果の入力が終わると、旅行者端末４に含まれる承認結果送信部４４は、入力した承認結果及び満足度を管理サーバ１へ送信する。

ステップＳ２０ａにおいて、管理サーバ１に含まれる旅行計画確定部２０は、承認結果が肯定的であるか否定的であるかを判定する。承認結果が否定的である場合には、ステップＳ１３ａへ処理を戻す。一方、承認結果が肯定的である場合には、ステップＳ２０ｂへ処理を進める。

旅行計画確定部２０は、承認結果が否定的でありステップＳ１３ａへ処理を戻す場合で、いずれかの時間スロットに割り付けられたイベント情報に定員数の設定があった場合には、イベント情報記憶部１１０に記憶されたイベント情報の準予約数フィールドを旅行者の人数だけ減算することで、準予約の解除を行う。再度行うステップＳ１３ａからステップＳ４３の処理は、上述の処理内容と同様である。

ステップＳ２０ｂにおいて、旅行計画確定部２０は、旅行計画を確定する。旅行計画確定部２０は、承認結果とともに受信する満足度を、提案実行者に関する提案者情報の提案履歴フィールドへ利用者評価として設定する。

ステップＳ２０ｃにおいて、旅行計画確定部２０は、時間スロットに割り当てたイベント情報に定員数が設定されていた場合、そのイベントの本予約を行う。具体的には、イベント情報記憶部１１０に記憶されたイベント情報の準予約数フィールドの値から旅行者の人数を減算し、本予約数フィールドの値に旅行者の人数を加算する。また、必要に応じて、イベント提供者の運用する予約管理システム等と連携して、本予約を実行してもよい。

また、旅行計画確定部２０は、承認された旅行計画へ旅行構成要素の提案を行った提案実行者に対して報酬を支払うように構成してもよい。例えば、イベント提供者は旅行計画に含まれるイベント情報に予めポイントを設定しておき、承認された旅行計画に含まれていたイベント情報に設定されたポイントを提案者のアカウントに蓄積する。そして、蓄積されたポイントが一定のポイントを超過するたびに提案者が事前に指定した口座へ金銭の支払い処理を行うようにする。

なお、上述した一連の過程において、旅行者と提案者が同一のユーザであっても構わない。すなわち、旅行者は他の旅行者のための旅行構成要素の提案を行ってもよいし、提案者は旅行者として旅行計画の作成依頼を行なってもよい。

このように、実施形態の旅行計画作成システムは、旅行者から旅行者情報及び旅行条件を取得し、それに合致する旅行計画をコンピュータにより効率的に生成することができる。特に、個人情報保護やプライバシ確保の必要性などからコンピュータへの登録ができない旅行構成要素を組み込んだ旅行計画を策定することが可能となり、より旅行者の個人的な希望に合致した旅行計画を作成することができる。

［プログラム、記録媒体］
この発明は上述の実施形態に限定されるものではなく、この発明の趣旨を逸脱しない範囲で適宜変更が可能であることはいうまでもない。上記実施例において説明した各種の処理は、記載の順に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。

また、上記実施形態で説明した各装置における各種の処理機能をコンピュータによって実現する場合、各装置が有すべき機能の処理内容はプログラムによって記述される。そして、このプログラムをコンピュータで実行することにより、上記各装置における各種の処理機能がコンピュータ上で実現される。

この処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等どのようなものでもよい。

また、このプログラムの流通は、例えば、そのプログラムを記録したＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体を販売、譲渡、貸与等することによって行う。さらに、このプログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することにより、このプログラムを流通させる構成としてもよい。

このようなプログラムを実行するコンピュータは、例えば、まず、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、一旦、自己の記憶装置に格納する。そして、処理の実行時、このコンピュータは、自己の記録媒体に格納されたプログラムを読み取り、読み取ったプログラムに従った処理を実行する。また、このプログラムの別の実行形態として、コンピュータが可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することとしてもよく、さらに、このコンピュータにサーバコンピュータからプログラムが転送されるたびに、逐次、受け取ったプログラムに従った処理を実行することとしてもよい。また、サーバコンピュータから、このコンピュータへのプログラムの転送は行わず、その実行指示と結果取得のみによって処理機能を実現する、いわゆるＡＳＰ（Application Service Provider）型のサービスによって、上述の処理を実行する構成としてもよい。なお、本形態におけるプログラムには、電子計算機による処理の用に供する情報であってプログラムに準ずるもの（コンピュータに対する直接の指令ではないがコンピュータの処理を規定する性質を有するデータ等）を含むものとする。

また、この形態では、コンピュータ上で所定のプログラムを実行させることにより、本装置を構成することとしたが、これらの処理内容の少なくとも一部をハードウェア的に実現することとしてもよい。

１ 管理サーバ
３ イベント提供者端末
４ 旅行者端末
５ 提案者端末
１０ イベント情報登録部
１１ 提案者情報登録部
１２ 提案者情報登録部
１３ 旅行条件受信部
１４ 旅行計画作成部
１５ 解決課題抽出部
１６ 提案依頼部
１７ 提案結果受信部
１８ 連絡手段通知部
１９ 調整結果受信部
２０ 承認依頼部
２１ 旅行計画確定部
１１０ イベント情報記憶部
１１１ 提案者情報記憶部
１１２ 旅行者情報記憶部
１１３ 旅行計画記憶部
３０ イベント情報送信部
４０ 旅行条件送信部
４１ 連絡手段受信部
４２ 調整回答部
４３ 承認依頼受信部
４４ 承認結果送信部
５０ 提案者情報送信部
５１ 提案依頼受信部
５２ 提案結果送信部
５３ 連絡手段受信部
５４ 調整連絡部
５５ 調整結果送信部
１０１，３０１，４０１，５０１ 制御部
１０２，３０２，４０２，５０２ メモリ

Claims (8)

1. 旅行者が利用する少なくとも１台の旅行者端末、提案者が利用する少なくとも１台の提案者端末及び管理サーバを含む旅行計画作成システムであって、
   上記管理サーバは、
   上記旅行者に提供されるイベントの属性を表すイベント情報を記憶するイベント情報記憶部と、
   上記提案者の属性を表す提案者情報を記憶する提案者情報記憶部と、
   上記旅行者の属性を表す旅行者情報と各旅行日を時間帯によって分割した複数の時間スロットそれぞれに対して上記旅行者が希望条件を設定した旅行条件とを上記旅行者端末から受信する旅行条件受信部と、
   上記時間スロットそれぞれに対して上記旅行条件に合致する上記イベント情報を抽出して割り付けた旅行計画素案を作成する旅行計画作成部と、
   上記旅行計画素案に割り付けられたイベント情報に基づいて解決課題を抽出する解決課題抽出部と、
   上記解決課題を上記提案者情報と比較して提案実行者を選出し、上記提案実行者の利用する上記提案者端末へ上記解決課題の提案依頼を送信する提案依頼部と、
   上記提案者端末から受信した調整結果を上記旅行計画素案へ反映して旅行計画を作成し、上記旅行計画の承認依頼を上記旅行者端末へ送信する承認依頼部と、
   上記旅行者端末から受信する上記承認依頼に対する承認結果が肯定的であれば上記旅行計画を確定する旅行計画確定部と、
   を含み、
   上記提案者端末は、
   上記管理サーバから受信した上記提案依頼に応じて上記解決課題へ割り付けるイベント情報を含む上記調整結果を生成し、上記管理サーバへ上記調整結果を送信する調整結果送信部
   を含む旅行計画作成システム。
2. 請求項１に記載の旅行計画作成システムであって、
   上記イベント情報は、当該イベントに関する情報を公開可能とする公開型若しくは当該イベントに関する情報を公開不可とする非公開型を示すイベントタイプを含み、
   上記解決課題抽出部は、上記旅行計画素案に割り付けられたイベント情報のうちイベントタイプが非公開型であるイベント情報を上記解決課題として抽出するものである
   旅行計画作成システム。
3. 請求項１または２に記載の旅行計画作成システムであって、
   上記管理サーバは、
   上記旅行者との連絡手段を表す提案者向け連絡手段を上記提案実行者の利用する上記提案者端末へ通知し、上記提案者との連絡手段を表す旅行者向け連絡手段を上記旅行者端末へ通知する連絡手段通知部をさらに含む
   旅行計画作成システム。
4. 請求項３に記載の旅行計画作成システムであって、
   上記提案者端末は、
   上記提案者向け連絡手段を用いて上記旅行者端末と通信手段を確立し、上記調整結果を上記旅行者端末と協調して生成する調整連絡部をさらに含み、
   上記旅行者端末は、
   上記旅行者向け連絡手段を用いて上記提案者端末と通信手段を確立し、上記調整結果を上記提案者端末と協調して生成する調整回答部を含む
   旅行計画作成システム。
5. 請求項１から４のいずれかに記載の旅行計画作成システムであって、
   上記イベント情報は、開始日時、終了日時、開催エリア及び活動分野を含み、
   上記時間スロットは、開始日時、終了日時、エリア及び活動分野を含み、
   上記旅行条件は、希望エリア及び希望活動分野を含み、
   上記旅行計画作成部は、上記時間スロットの開始日時及び終了日時と上記イベント情報の開始日時及び終了日時、上記旅行条件の希望活動分野と上記イベント情報の活動分野、上記旅行条件の希望エリアと上記イベント情報の開催エリアのそれぞれが合致するか否かを判定し、上記旅行計画の時間スロットそれぞれに割り付けるイベント情報を抽出するものである
   旅行計画作成システム。
6. 請求項１から５のいずれかに記載の旅行計画作成システムであって、
   上記イベント情報は、定員数、仮予約数、準予約数及び本予約数を含み、
   上記旅行計画作成部は、上記時間スロットに割り付ける上記イベント情報に定員数が設定されていれば上記仮予約数に上記旅行者の人数を加算するものであり、
   上記承認依頼部は、上記旅行計画に含まれる上記イベント情報に定員数が設定されていれば上記仮予約数から上記旅行者の人数を減算した上で上記準予約数に上記旅行者の人数を加算するものであり、
   上記旅行計画確定部は、上記旅行計画に含まれる上記イベント情報に定員数が設定されていれば上記準予約数から上記旅行者の人数を減算した上で上記本予約数に上記旅行者の人数を加算するものである
   旅行計画作成システム。
7. 請求項１から６のいずれかに記載の旅行計画作成システムであって、
   上記提案依頼部は、上記旅行計画素案へのハイパーリンクを含む電子メールとして上記提案実行者の利用する上記提案者端末へ上記提案依頼を送信するものである
   旅行計画作成システム。
8. 請求項１から７のいずれかに記載の旅行計画作成システムであって、
   上記旅行計画確定部は、上記承認結果が肯定的であれば上記提案実行者及び上記旅行計画に含まれる上記イベント情報を登録したイベント提供者へ上記旅行計画の内容に応じた報酬を支払うものである
   旅行計画作成システム。

Images