(57)【要約】【課題】旅行計画遂行中の急な事情の変更に応じた旅行計画の変更案をコンピュータにより効率的に作成する。【解決手段】イベント提供者端末３はイベント情報を登録する。旅行者端末４は旅行者情報と旅行条件を管理サーバ１へ送信する。管理サーバ１は、旅行条件に従って各時間スロットにイベント情報を割り付けて旅行計画を作成する。旅行者端末４は旅行計画変更依頼を管理サーバ１へ送信する。管理サーバ１は、旅行計画変更依頼に従って変更支援実行者を選出し、変更支援者端末６へ変更支援依頼を送信する。変更支援者端末６は、変更支援依頼に基づいて旅行条件を変更する。管理サーバ１は、変更された旅行条件に基づいて旅行計画変更案を作成する。【選択図】図１
2015049736.tif 000002
【特許請求の範囲】
【請求項１】
旅行者が利用する少なくとも１台の旅行者端末、変更支援者が利用する複数台の変更支援者端末及び管理サーバを含む旅行計画変更支援システムであって、
上記管理サーバは、
上記旅行者に提供されるイベントの属性を表すイベント情報を記憶するイベント情報記憶部と、
上記変更支援者の属性を表す変更支援者情報を記憶する変更支援者情報記憶部と、
上記旅行者の属性を表す旅行者情報と各旅行日を時間帯によって分割した複数の時間スロットそれぞれに対して上記旅行者が希望条件を設定した旅行条件とを上記旅行者端末から受信する旅行条件受信部と、
上記複数の時間スロットそれぞれに対して上記旅行条件に合致する上記イベント情報を抽出して割り付けた旅行計画を作成する旅行計画作成部と、
上記旅行者が旅行計画の変更を必要とする変更対象時間スロットを含む旅行計画変更依頼を上記旅行者端末から受信する変更依頼受信部と、
上記旅行計画変更依頼及び上記旅行計画を上記変更支援者情報と比較して上記旅行条件を変更する変更支援実行者を選出し、上記変更支援実行者の利用する上記変更支援者端末へ上記旅行計画の変更支援依頼を送信する変更支援依頼部と、
上記変更対象時間スロットに対して上記変更支援者端末から受信した変更後の旅行条件に合致する上記イベント情報を抽出して割り付けた旅行計画変更案を作成する旅行計画変更部と、
を含む旅行計画変更支援システム。
【請求項２】
請求項１に記載の旅行計画変更支援システムであって、
上記変更支援者情報は、対応可能な支援可能日、支援事由、支援分野、支援地域及び上記変更支援者の居住地域を含み、
上記旅行計画変更依頼は、上記旅行者が旅行計画の変更を希望する時間スロット及び旅行計画の変更を希望する支援事由を含み、
上記変更支援依頼部は、上記旅行計画変更依頼を参照して上記変更対象時間スロットの活動分野及び開催エリアを抽出し、上記変更対象時間スロットと上記変更支援者情報の支援可能日、上記旅行計画変更依頼の支援事由と上記変更支援者情報の支援事由、上記抽出した活動分野と上記変更支援者情報の支援分野、上記抽出した開催エリアと上記変更支援者情報の支援地域もしくは居住地域のそれぞれが合致するか否かを判定し、合致する項目が多い順に予め定めた人数の上記変更支援実行者を選出するものである
旅行計画変更支援システム。
【請求項３】
請求項１または２に記載の旅行計画変更支援システムであって、
上記変更支援依頼部は、上記旅行計画変更依頼及び上記旅行計画へのハイパーリンクを含む電子メールとして上記変更支援実行者の利用する上記変更支援者端末へ上記変更支援依頼を送信するものである
旅行計画変更支援システム。
【請求項４】
請求項１から３のいずれかに記載の旅行計画変更支援システムであって、
上記イベント情報は、開始日時、終了日時、開催エリア及び活動分野を含み、
上記時間スロットは、開始日時、終了日時、エリア及び活動分野を含み、
上記旅行条件は、希望エリア及び希望活動分野を含み、
上記旅行計画変更部は、上記時間スロットの開始日時及び終了日時と上記イベント情報の開始日時及び終了日時、上記変更後の旅行条件の希望活動分野と上記イベント情報の活動分野、上記変更後の旅行条件の希望エリアと上記イベント情報の開催エリアのそれぞれが合致するか否かを判定し、上記変更対象時間スロットに割り付けるイベント情報を抽出するものである
旅行計画変更支援システム。
【請求項５】
請求項１から４のいずれかに記載の旅行計画変更支援システムであって、
上記管理サーバは、
上記旅行計画変更案の承認依頼を上記旅行者端末へ送信する承認依頼部と、
上記旅行者端末から受信する上記承認依頼に対する承認結果が肯定的であれば上記旅行計画変更案を確定する旅行計画確定部と、
をさらに含む旅行計画変更支援システム。
【請求項６】
請求項５に記載の旅行計画変更支援システムであって、
上記イベント情報は、定員数、仮予約数、準予約数及び本予約数をさらに含み、
上記旅行計画変更部は、上記時間スロットに割り付ける上記イベント情報に定員数が設定されていれば上記仮予約数に上記旅行者の人数を加算するものであり、
上記承認依頼部は、上記旅行計画変更案に含まれる上記イベント情報に定員数が設定されていなければ上記仮予約数から上記旅行者の人数を減算した上で上記準予約数に上記旅行者の人数を加算するものであり、
上記旅行計画確定部は、上記旅行計画変更案に含まれる上記イベント情報に定員数が設定されていれば上記準予約数から上記旅行者の人数を減算した上で上記本予約数に上記旅行者の人数を加算するものである
旅行計画変更支援システム。
【請求項７】
請求項１から６のいずれかに記載の旅行計画変更支援システムであって、
上記旅行計画変更支援システムは、
評価者が利用する複数台の評価者端末をさらに含み、
上記管理サーバは、
上記評価者の属性を表す評価者情報を記憶する評価者情報記憶部と、
上記旅行者情報及び上記旅行計画変更案を上記評価者情報と比較して上記旅行計画変更案の評価を行う評価実行者を選出し、上記評価実行者の利用する上記評価者端末へ上記旅行計画変更案の評価依頼を送信する評価依頼部と、
上記評価者端末から受信する上記評価依頼に対する評価結果に基づいて上記旅行計画変更案の上記時間スロットそれぞれに対する総合評価値を求め、上記総合評価値が予め定めた基準値以上であるか否かを判定する評価判定部と、
をさらに含む旅行計画変更支援システム。
【請求項８】
請求項７に記載の旅行計画変更支援システムであって、
上記評価者情報は、上記評価者の性別、年齢、趣味、居住地域及び詳しい地域を含み、
上記旅行者情報は、上記旅行者の性別、年齢及び趣味を含み、
上記時間スロットは、開催エリア及び活動分野を含み、
上記評価依頼部は、上記旅行者情報の性別と上記評価者情報の性別、上記旅行者情報の年齢と上記評価者情報の年齢、上記旅行者情報の趣味と上記評価者情報の趣味、上記旅行計画変更案の開催エリアと上記評価者情報の居住地域または詳しい地域、上記旅行計画変更案の活動分野と上記評価者情報の趣味のそれぞれが合致するか否かを判定し、合致する項目が多い順に予め定めた人数の上記評価実行者を選出するものである
旅行計画変更支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、旅行者の要望に応じた個別注文の旅行計画をコンピュータにより効率的に作成する技術に関し、特に、旅行計画遂行中の急な事情の変更に応じて旅行計画の変更案を効率的に作成する技術に関する。
【背景技術】
【０００２】
近年、観光に対するニーズが個性化、多様化する傾向があり、従来のような団体旅行から個人旅行へと観光スタイルが変化している。一方、ウェブ上には膨大な観光情報があるが、旅行者自身が多数の観光スポットの中から訪問するスポットを選択し、様々な制約を考慮しながら旅行計画を立てるのは困難となっている。特に、旅行中に遭遇したトラブルに対しては、個人毎の個別の旅行計画に適した計画変更や代替手段を立案するためには多様な制約条件を取捨選択して変更案を考える必要があり、組合せ数の大幅な増加や状況に応じた変更方針、判断基準の策定など、演算量が膨大となりコンピュータで実施することは現実的には極めて困難であった。
【０００３】
従来から、コンピュータを用いて旅行計画を作成する方法が開示されている。特許文献１の開示によれば以下のように旅行計画が作成される。まず、旅行者によって入力された旅行期間の各旅行日を複数のスロットに分割する。次に、スロットの各々に付与された特性と適合するように関連付けが定義された複数アクティビティを含む、旅行期間内に利用可能なサービスリストを作成する。次に、サービスの各々を複数スロットの各々に割り付けるにあたっての制約条件を設定する。次に、旅行計画の評価特性を表す目的関数を構成する。そして、制約条件の下で目的関数を最適化するように、サービスリストに含まれるサービスの各々を複数スロットの各々に割り付ける。特許文献１の方法では、このようにして、コンピュータを用いて旅行計画を作成する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第４２６８９７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来はインターネットなどで手軽に旅行を選ぼうとすると、パッケージ化された旅行の中から最も自分の好みに合ったものを選んで購入するのが主流であった。また、旅行計画に組み込まれているイベントが、本当に自分の希望に適合しているものなのかを、現地情報に詳しい人などの意見を参考にして確かめるようなことができなかった。
【０００６】
特許文献１に開示された技術は、コンピュータを使用して旅行者の提示する旅行条件に合致するように旅行計画を作成するための技術である。特許文献１の方法では、旅行期間を単位スロットに分割し、分割したスロットに優先度を考慮してアクティビティを割り当てることで旅行計画を作成し、作成した旅行計画を旅行者に提供する。ここで、スロットにアクティビティを最適に割り当てるために混合整数計画問題を用いている。整数計画問題では、人間の評価者が評価するのとは異なりコンピュータの計算時間の制限のためパラメータの選択が限定され、多種多様な旅行者の好みが反映されない。
【０００７】
さらに、一旦作成した旅行計画の遂行中にトラブルの発生などにより旅行計画を変更する場合にも、多様な制約条件を取捨選択した多くの代替案の中からトラブルの状況と旅行者の希望条件を勘案した最適な代替案を提示することは、同様の理由により困難である。
【０００８】
この発明の目的は、旅行者の要望に応じてコンピュータにより効率的に作成した旅行計画に対して、旅行計画遂行中の急な事情の変更に応じた旅行計画の変更案をコンピュータにより効率的に作成することである。
【課題を解決するための手段】
【０００９】
上記の課題を解決するために、この発明の旅行計画変更支援システムは、旅行者が利用する少なくとも１台の旅行者端末、変更支援者が利用する複数台の変更支援者端末及び管理サーバを含む。管理サーバは、イベント情報記憶部、変更支援者情報記憶部、旅行条件受信部、旅行計画作成部、変更依頼受信部、変更支援依頼部、旅行計画変更部を含む。
【００１０】
イベント情報記憶部は、旅行者に提供されるイベントの属性を表すイベント情報を記憶する。変更支援者情報記憶部は、変更支援者の属性を表す変更支援者情報を記憶する。旅行条件受信部は、旅行者の属性を表す旅行者情報と各旅行日を時間帯によって分割した複数の時間スロットそれぞれに対して旅行者が希望条件を設定した旅行条件とを旅行者端末から受信する。旅行計画作成部は、時間スロットそれぞれに対して旅行条件に合致するイベント情報を抽出して割り付けた旅行計画を作成する。変更依頼受信部は、旅行者が旅行計画の変更を必要とする変更対象時間スロットを含む旅行計画変更依頼を旅行者端末から受信する。変更支援依頼部は、旅行計画変更依頼及び旅行計画を変更支援者情報と比較して旅行条件を変更する変更支援実行者を選出し、変更支援実行者の利用する変更支援者端末へ旅行計画の変更支援依頼を送信する。旅行計画変更部は、変更対象時間スロットに対して変更支援者端末から受信した変更後の旅行条件に合致するイベント情報を抽出して割り付けた旅行計画変更案を作成する。
【発明の効果】
【００１１】
この発明の旅行計画変更支援システムによれば、旅行者の要望に応じてコンピュータにより効率的に作成した旅行計画に対して、旅行計画遂行中の急な事情の変更に応じた旅行計画の変更案を効率的に作成することができる。特に、コンピュータによる機械的なイベントの変更のみでなく、地域の事情やイベントの性質に精通した変更支援者が旅行条件の変更を行うことで、効率的に旅行計画の変更案を提示することが可能になる。
【図面の簡単な説明】
【００１２】
【図１】図１は、旅行計画変更支援システムの機能構成を例示する図である。
【図２】図２は、管理サーバの機能構成を例示する図である。
【図３】図３は、イベント提供者端末の機能構成を例示する図である。
【図４】図４は、旅行者端末の機能構成を例示する図である。
【図５】図５は、評価者端末の機能構成を例示する図である。
【図６】図６は、変更支援者端末の機能構成を例示する図である。
【図７】図７は、旅行計画のデータ構造を例示する図である。
【図８】図８は、旅行計画の設定内容を例示する図である。
【図９】図９は、旅行計画変更支援システムの処理フローを例示する図である。
【図１０】図１０は、イベント情報のデータ構造を例示する図である。
【図１１】図１１は、エリア番号を説明するための図である。
【図１２】図１２は、イベント情報の設定内容を例示する図である。
【図１３】図１３は、評価者情報のデータ構造を例示する図である。
【図１４】図１４は、評価者情報の設定内容を例示する図である。
【図１５】図１５は、変更支援者情報のデータ構造を例示する図である。
【図１６】図１６は、変更支援者情報の設定内容を例示する図である。
【図１７】図１７は、旅行計画変更支援システムの処理フローを例示する図である。
【図１８】図１８は、旅行計画変更支援システムの処理フローを例示する図である。
【図１９】図１９は、旅行計画変更支援システムの処理フローを例示する図である。
【図２０】図２０は、旅行者情報及び旅行条件のデータ構造を例示する図である。
【図２１】図２１は、旅行者情報の設定内容を例示する図である。
【図２２】図２２は、旅行計画管理情報の設定内容を例示する図である。
【図２３】図２３は、旅行計画管理情報の設定内容を例示する図である。
【図２４】図２４は、旅行計画素案の設定内容を例示する図である。
【図２５】図２５は、旅行計画の設定内容を例示する図である。
【図２６】図２６は、旅行計画変更支援システムの処理フローを例示する図である。
【図２７】図２７は、旅行計画変更支援システムの処理フローを例示する図である。
【図２８】図２８は、旅行計画変更支援システムの処理フローを例示する図である。
【図２９】図２９は、旅行計画変更依頼の設定内容を例示する図である。
【図３０】図３０は、旅行計画変更案の設定内容を例示する図である。
【図３１】図３１は、旅行計画変更案の評価結果を例示する図である。
【発明を実施するための形態】
【００１３】
以下、この発明の実施の形態について詳細に説明する。なお、図面中において同じ機能を有する構成部には同じ番号を付し、重複説明を省略する。
【００１４】
図１を参照して、実施形態に係る旅行計画変更支援システムの機能構成の一例を説明する。旅行計画変更支援システムは、旅行を希望する人物に旅行計画を作成して提供する情報処理システムである。以降の説明では、旅行を希望する人物のことを旅行者と呼ぶ。
【００１５】
旅行計画変更支援システムは、管理サーバ１、少なくとも１台のイベント提供者端末３、少なくとも１台の旅行者端末４、M（≧2）台の評価者端末５1,…,５M、N（≧2）台の変更支援者端末６1,…,６Nを含む。評価者端末５と変更支援者端末６とは兼用することが可能である。兼用する場合には、評価者端末５に含まれる各部と変更支援者端末６に含まれる各部とを重複無く含む１台の端末を評価者兼変更支援者端末として用意すればよい。管理サーバ１、イベント提供者端末３、旅行者端末４、評価者端末５1,…,５M及び変更支援者端末６1,…,６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、ＲＡＭ）等を有する公知又は専用のコンピュータに特別なプログラムが読み込まれて構成された特別な装置である。評価者端末５は、例えば、制御部５０１の制御のもとで各処理を実行する。評価者端末５に入力されたデータや各処理で得られたデータは、例えば、メモリ５０２に格納され、メモリ５０２に格納されたデータは必要に応じて読み出されて他の処理に利用される。評価者端末５は、具体的には、パーソナル・コンピュータや携帯電話、スマートフォン、タブレット端末などである。
【００２０】
図６を参照して、旅行計画変更支援システムに含まれる変更支援者端末６の機能構成の一例を説明する。変更支援者端末６は、制御部６０１、メモリ６０２、変更支援者情報送信部６０、変更支援依頼受信部６１及び変更結果送信部６２を含む。変更支援者端末６は、例えば、中央演算処理装置（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時から18時まで参加する。夕食はイベントＩＤとして「EVT0003」を割り当てられたイベントに、18時から21時まで参加する。通常、午前中と午後のイベントは美術鑑賞、観劇、コンサートなどのイベントが割り当てられ、昼食と夕食のイベントは食事のイベントが割り当てられるが、旅行者の希望により自由に設定可能でありこの限りではない。
【００２５】
図９を参照して、旅行計画変更支援システムの動作に必要な情報の登録について、処理フローの一例を実際に行われる手続きの順に従って説明する。
【００２６】
ステップＳ３０において、イベント提供者はイベント提供者端末３を用いてイベント情報を作成し、そのイベント情報を旅行計画変更支援システムへ登録する。イベント情報は、旅行者へ提供するイベントの属性を記述した情報である。イベント提供者は、例えば、イベント提供者端末３に表示される入力画面から必要な情報を入力することでイベント情報を作成する。具体的には、入力画面は、イベント提供者端末３にインストールされたウェブブラウザにロードされたウェブページ、もしくはイベント提供者端末３にインストールされた独自のアプリケーションのウィンドウである。イベント提供者端末３に含まれるイベント情報送信部３０は作成したイベント情報を管理サーバ１へ送信する。
【００２７】
図１０にイベント情報の入力項目の一例を示す。「入力項目」欄は、入力項目の名称を表す。「入力形式」欄は、その入力項目を入力する際の入力方法を表す。「説明」欄には、その入力項目の詳細な内容を記載している。「データ例」欄には、各入力項目に実際に設定される値の一例を示している。
【００２８】
「入力形式」欄における「メニュー選択」は、操作者がプルダウン形式のメニュー選択やチェックボックス形式の項目選択により、予め定められた候補値の中から適切な入力値を選択する入力方法である。「定型入力」は、日時や人数、金額などの数字を直接入力する入力方法である。「自由記入」は、操作者が例えばキーボードなどを用いて任意の文字列を入力する入力方法である。以降の説明においても、「入力形式」欄における各記載は同様の操作を表すものとする。
【００２９】
各入力項目の入力画面上での配置や入力形式については、操作者の利便性を考慮して適宜設計すればよい。以降の入力項目に関する説明においても同様である。
【００３０】
以下、イベント情報の入力項目についてより詳細に説明する。「イベント提供者ＩＤ」は、あらかじめ旅行計画変更支援システムにより割り当てられた、イベント提供者を一意に識別するための識別番号である。「活動分野」は、旅行に組み込まれるイベントの大まかな活動の種類を表す情報である。例えば、食事や美術鑑賞、観劇、コンサート、スポーツなどが該当する。「活動分野」は、メニュー選択の形式で入力される。「イベント名」は、活動分野をさらに細分化した区分を表す情報である。例えば、活動分野が食事の場合、イタリア料理やフランス料理、和食などが該当する。「活動分野」は、メニュー選択の形式で入力される。「開催場所」は、そのイベントの開催場所（例えば、会場名など）が自由記入で入力される。ただし、事前登録された情報を参照することによって、活動分野、イベント名、開催場所を限定して候補名や地図上の場所を示してもよい。「開催エリア」は、地理的な場所を所定の区画に区切って識別できるようにしたものである。「イベントタイプ」は、登録しようとするイベントの開催期間が特定期間に限定されているか否かを識別するためのフィールドであり、期間に限定がある場合に「期間限定あり」、期間に限定がない場合に「期間限定なし」が設定される。「期間限定あり」のタイプのイベントでは、開始日時及び終了日時のフィールドに特定の年月日の特定の時刻が設定される。一定の期間、同一内容の活動が繰り返し開催される形態のイベントの場合は、イベントタイプを「期間限定あり」とし、一回の開催を一つのイベントとして登録する。例えば、複数回開催されるミュージカルの場合、一つの演目が一日に複数回、それが複数の日にわたって開催されるが、公演一回ずつが一つのイベントとして登録される。美術館、テーマパークを利用したり、ショッピングをしたりする活動のように参加する開始時刻及び終了時刻が任意である場合、イベントタイプを「期間限定なし」と設定して、開始日時及び終了日時のフィールドには利用可能時間（開館時間や閉館時間など）のみが設定される。「参加資格」には、そのイベントに参加するために旅行者が満たすべき条件（例えば年齢制限など）が設定される。「推奨条件」には、そのイベントに参加するために旅行者が満たしていることが望ましい条件（例えば対象年齢など）が設定される。「参加定員数」にはそのイベントに参加可能な人数が設定される。参加可能数に制限がない場合には「制限なし」を示す数字として「0」が設定される。なお、イベント情報にはイベント提供者が任意に写真などのファイルを添付してもよい。
【００３１】
「開催エリア」の設定内容の一例をより詳細に説明する。図１１に示すように、携帯電話網７は、例えば、複数の基地局７０１〜７３２から構成される。エリアとは、一つ以上の近接する基地局からなる通信可能領域を区画の単位として分割した地理的範囲である。各エリアにはエリア番号と呼ばれる一意の識別番号を割り当てておき、「開催エリア」には開催場所の施設が属するエリアのエリア番号を設定する。以降の説明においても、エリア番号とは、図１１に示すように、通信可能領域により地理的に分割した区画に割り当てられた識別番号を示している。また、開催エリアは国土地理院の地域メッシュ、日本郵便の郵便番号、市区町村などでもよい。
【００３２】
図９に示すステップＳ１０において、管理サーバ１に含まれるイベント情報登録部１０は、イベント提供者端末３から受信したイベント情報をイベント情報記憶部１１０へ記憶する。イベント情報記憶部１１０へ記憶されたイベント情報は、イベント提供者ＩＤ等により特定されたイベント提供者によって編集や削除を行うことができるものとする。
【００３３】
図１２にイベント情報記憶部１１０に記憶されたイベント情報の一例を示す。図１２の例は、イベント提供者ＩＤとして「EV1030」を割り当てられたイベント提供者が、図１０のデータ例に示した新たなイベントを登録した状態を表している。イベント情報登録部１０は、イベント情報送信部３０からのイベント情報を取得すると、旅行計画変更支援システム内でそのイベントを一意に識別するためのイベントＩＤを生成し、「イベントＩＤ」フィールドへ設定する。この例では、イベントＩＤは「EVT1005」が生成されたものとする。続いて、イベント情報登録部１０は、取得したイベント情報の各入力値を対応するフィールドへ設定する。この例では、活動内容が「コンサート」であり、イベント名は「室内楽CC」であり、イベントタイプは開催期間に制限があることを表す「期間限定あり」であり、イベント期間は「2013年2月24日15時」から「2013年2月24日18時」であり、開催場所は「FF劇場」であり、開催エリアは「エリア４」である。また、利用料金は「10,000（円）」であり、参加定員は「200（名）」である。さらに、参加資格に関して「年齢が6歳以上」という制約が設定されている。
【００３４】
図１２に示すイベント情報の登録例では参加定員数が定められているため、イベントへの参加者の予約状況を管理するために、仮予約数、準予約数及び本予約数のフィールドが作成される。これらのフィールドの使用方法は後述するが、イベント情報が登録された初期状態では各フィールドの値はゼロに設定される。イベントに参加定員が定められていない場合には予約状況を管理する必要がないため、仮予約数、準予約数及び本予約数のフィールドを作成しなくともよい。
【００３５】
図９に示すステップＳ５０において、評価者は評価者端末５を用いて評価者情報を作成し、その評価者情報を旅行計画変更支援システムへ登録する。評価者情報は、評価者の属性を記述した情報である。評価者は、例えば、評価者端末５に表示される入力画面から必要な情報を入力することで評価者情報を作成する。具体的には、入力画面は、評価者端末５にインストールされたウェブブラウザにロードされたウェブページ、もしくは評価者端末５にインストールされた独自のアプリケーションのウィンドウである。評価者端末５に含まれる評価者情報送信部５０は作成した評価者情報を管理サーバ１へ送信する。
【００３６】
図１３に評価者情報の入力項目の一例を示す。「性別」は、評価者の性別であり、男／女から選択する。「年齢」は、評価者の年齢であり、数値を入力する。「居住地域」は、評価者の居住する地域のエリア番号である。「詳しい地域」は、評価者が豊富な知識を持っており詳しい判断ができる地域のエリア番号である。「趣味」は、評価者が趣味としており豊富な知識を持つため詳しい判断ができる活動分野を選択する。「身体特徴」は、評価者の特別な身体的特徴があれば設定する。例えば、評価者が車椅子使用者であれば車椅子使用時の設備の利便性が判断できると考えられる。また、評価者がアレルギー体質であればレストランの選択などで適切な判断が可能であると考えられる。これらの事情を考慮して旅行計画を評価することができれば、旅行者にとってより適切な旅行計画を作成することができる。
【００３７】
図９に示すステップＳ１１において、管理サーバ１に含まれる評価者情報登録部１１は、評価者端末５から受信した評価者情報を評価者情報記憶部１１１へ記憶する。評価者情報記憶部１１１へ記憶された評価者情報は、後述する評価者ＩＤ等により特定された評価者によって編集や削除を行うことができるものとする。
【００３８】
図１４に評価者情報記憶部１１１に記憶された評価者情報の一例を示す。図１４の例は、評価者情報が登録されていない新たな評価者が、図１３のデータ例に示した新たな評価者情報を登録した状態を表している。評価者情報登録部１１は、評価者情報送信部５０からの評価者情報を取得すると、旅行計画変更支援システム内でその評価者を一意に識別するための評価者ＩＤを生成し、「評価者ＩＤ」フィールドへ設定する。この例では、評価者ＩＤは「10003」が生成されたものとする。続いて、評価者情報登録部１１は、取得した評価者情報の各入力値を対応するフィールドへ設定する。この例では、新たな評価者は55歳の女性であり、「エリア２」に居住しており、「エリア４」の詳しい知識を持っており、「音楽」を趣味としている。また、身体的特徴として「車椅子使用」を登録しており、車椅子を必要とする旅行スタイルに詳しいことがわかる。
【００３９】
評価者情報に含まれる居住地域や詳しい地域、趣味、身体特徴などの登録内容は、評価者により編集することが可能である。評価者情報が更新された場合には更新前の情報を異なる領域に記憶する。更新前の情報は過去全ての情報を保持するように構成してもよいし、一定の世代数（例えば、五世代分など）もしくは一定期間の情報（例えば、一年間分など）を保持するように構成してもよい。過去の情報は評価者情報の追加のフィールドとして保持してもよいし、例えば評価者情報履歴として時系列に記憶するように構成してもよい。
【００４０】
評価者情報には、その評価者が実施した評価の履歴を格納するための「評価履歴」フィールドが設けられる。「評価履歴」には、管理サーバ１がその評価者に評価依頼を送信した旅行計画を示す旅行ＩＤ、管理サーバ１がその評価者に評価依頼を送信した日時を示す依頼日時、管理サーバ１がその評価者から評価結果を受信した日時を示す回答日時、旅行者が旅行計画の承認時に入力する評価値を示す利用者評価が格納される。この評価値は、例えば、旅行者により入力される五段階の得点である。「評価履歴」は、管理サーバ１からその評価者に新たに評価依頼が送信される度にフィールドが追加されていく。図１４の例では、評価者ＩＤが「10003」の評価者は新たに登録されたばかりであって未だ旅行計画の評価をおこなっていないため評価履歴がない。評価者ＩＤが「10001」の評価者は過去に二つの旅行計画を評価しており、評価者ＩＤが「10002」の評価者は過去に一つの旅行計画を評価していることがわかる。
【００４１】
図９に示すステップＳ６０において、変更支援者は変更支援者端末６を用いて変更支援者情報を作成し、その変更支援者情報を旅行計画変更支援システムへ登録する。変更支援者情報は、変更支援者の属性を記述した情報である。変更支援者は、例えば、変更支援者端末６に表示される入力画面から必要な情報を入力することで変更支援者情報を作成する。具体的には、入力画面は、変更支援者端末６にインストールされたウェブブラウザにロードされたウェブページ、もしくは変更支援者端末６にインストールされた独自のアプリケーションのウィンドウである。変更支援者端末６に含まれる変更支援者情報送信部６０は作成した変更支援者情報を管理サーバ１へ送信する。
【００４２】
図１５に変更支援者情報の入力項目の一例を示す。「性別」は、変更支援者の性別であり、男／女から選択する。「年齢」は、変更支援者の年齢であり、数値を入力する。「居住地域」は、変更支援者の居住する地域のエリア番号である。「支援地域」は、変更支援者が豊富な知識を持っており詳しい判断ができる地域のエリア番号である。「支援分野」は、変更支援者が豊富な知識を持っており詳しい判断ができる活動分野を選択する。「身体特徴」は、変更支援者の特別な身体的特徴があれば設定する。例えば、変更支援者が車椅子使用者であれば車椅子使用時の設備の利便性が判断できると考えられる。また、変更支援者がアレルギー体質であればレストランの選択などで適切な判断が可能であると考えられる。「支援事由」は、変更支援者が詳しい知識を有しており適切な判断ができるトラブルの種類を選択する。例えば、変更支援者が交通網の事情に詳しければ交通トラブルに遭遇した際に適切な判断ができると考えられる。「支援可能日」は、変更支援者がリアルタイムに変更支援を行うことが可能な日にち及びタイムスロットを選択する。これらの事情を考慮して旅行計画の変更案を作成することができれば、旅行者にとってより適切な旅行計画の変更案を作成することができる。
【００４３】
図９に示すステップＳ１２において、管理サーバ１に含まれる変更支援者情報登録部１２は、変更支援者端末６から受信した変更支援者情報を変更支援者情報記憶部１１２へ記憶する。変更支援者情報記憶部１１２へ記憶された変更支援者情報は、後述する変更支援者ＩＤ等により特定された変更支援者によって編集や削除を行うことができるものとする。
【００４４】
図１６に変更支援者情報記憶部１１２に記憶された変更支援者情報の一例を示す。図１６の例は、変更支援者情報が登録されていない新たな変更支援者が、図１５のデータ例に示した新たな変更支援者情報を登録した状態を表している。変更支援者情報登録部１２は、変更支援者情報送信部６０からの変更支援者情報を取得すると、旅行計画変更支援システム内でその変更支援者を一意に識別するための変更支援者ＩＤを生成し、「変更支援者ＩＤ」フィールドへ設定する。この例では、変更支援者ＩＤは「11003」が生成されたものとする。続いて、変更支援者情報登録部１２は、取得した変更支援者情報の各入力値を対応するフィールドへ設定する。この例では、新たな変更支援者は55歳の女性であり、「エリア２」に居住しており、「エリア４」の詳しい知識を持っており、「音楽」の詳しい知識を持っている。また、身体的特徴として「車椅子使用」を登録しており、車椅子を必要とする旅行スタイルに詳しいことがわかる。支援事由は「交通トラブル」を登録しており、地域の交通網の事情に詳しいことがわかる。支援可能日は2013年2月24日の終日（タイムスロット１〜４）並びに2013年2月25日の午後及び夕食（タイムスロット３、４）を登録しており、これらの時間帯はリアルタイムに変更支援が可能であることがわかる。
【００４５】
変更支援者情報に含まれる居住地域や支援地域、支援分野、身体特徴、支援事由、支援可能日などの登録内容は、変更支援者により編集することが可能である。変更支援者情報が更新された場合には更新前の情報を異なる領域に記憶する。更新前の情報は過去全ての情報を保持するように構成してもよいし、一定の世代数（例えば、五世代分など）もしくは一定期間（例えば、一年間分など）の情報を保持するように構成してもよい。過去の情報は変更支援者情報の追加のフィールドとして保持してもよいし、例えば変更支援者情報履歴として時系列に記憶するように構成してもよい。
【００４６】
変更支援者情報には、その変更支援者が実施した変更支援の履歴を格納するための「支援履歴」フィールドが設けられる。「支援履歴」には、管理サーバ１がその変更支援者に変更支援依頼を送信した旅行計画を示す旅行ＩＤ、管理サーバ１がその変更支援者に変更支援依頼を送信した日時を示す依頼日時、管理サーバ１がその変更支援者から変更結果を受信した日時を示す回答日時、旅行者が旅行計画の承認時に入力する評価値を示す利用者評価が格納される。この評価値は、例えば、旅行者により入力される五段階の得点である。「支援履歴」は、管理サーバ１からその変更支援者に新たに変更支援依頼が送信される度にフィールドが追加されていく。図１６の例では、変更支援者ＩＤが「11003」の変更支援者は新たに登録されたばかりであって未だ旅行計画の評価を行っていないため評価履歴がない。変更支援者ＩＤが「11001」の変更支援者は過去に二つの旅行計画を評価しており、変更支援者ＩＤが「11002」の変更支援者は過去に一つの旅行計画を評価していることがわかる。
【００４７】
図１７〜１９を参照して、旅行計画変更支援システムが旅行者の依頼に応じて新規に旅行計画を作成する動作について、処理フローの一例を実際に行われる手続きの順に従って説明する。なお、図１７に示す「A1」「B1」「D1」の各符号は、図１８に示す「A1」「B1」「D1」の各符号へそれぞれ処理が継続することを表している。図１７に示す「C1」の符号は、図１９に示す「C1」の符号へ処理が継続することを表している。図１８及び図１９に示す「B2」の符号は、図１７に示す「B2」の符号へ処理が継続することを表している。図１８に示す「A2」「B3」の各符号は、図１９に示す「A2」「B3」の各符号へそれぞれ処理が継続することを表している。
【００４８】
図１７に示すステップＳ４０において、旅行者は旅行者端末４を用いて旅行者情報及び旅行条件を作成し、その旅行者情報及び旅行条件を管理サーバ１へ送信する。旅行者情報は、旅行者の属性を記述した情報である。旅行条件は、旅行者が旅程の中で参加したいイベントの条件を記述した情報である。旅行者は、例えば、旅行者端末４に表示される入力画面から必要な情報を入力することで旅行者情報及び旅行条件を作成する。具体的には、入力画面は、旅行者端末４にインストールされたウェブブラウザにロードされたウェブページ、もしくは旅行者端末４にインストールされた独自のアプリケーションのウィンドウである。旅行者端末４に含まれる旅行条件送信部４０は作成した旅行者情報及び旅行条件を管理サーバ１へ送信する。
【００４９】
図２０に旅行者情報及び旅行条件の入力項目の一例を示す。入力項目は、旅行者情報と旅行条件に分けられる。旅行者情報には旅行者の属性に関する情報を入力する。旅行条件は、旅行日ごとにブロック分けされる。各ブロックにはその旅行日の基本情報と複数の時間スロットが含まれる。
【００５０】
以下、旅行者情報の入力項目についてより詳細に説明する。「氏名」は、旅行者の氏名を入力する。「連絡先」は、旅行者の住所等の連絡先を入力する。「性別」は旅行者の性別であり、男／女から選択する。「年齢」は旅行者の年齢であり、数値を入力する。「趣味」は、旅行者の趣味を選択する。「旅行費用上限」は、旅行全体の予算の上限額であり、数値を入力する。「要望事項」は、旅行者が旅行に対して要望する特別な事項を入力する自由記入欄である。図２０の例では、旅行者「A山B子」は「○○町」に居住する「53（歳）」の「女性」であり、「美術鑑賞」と「音楽」を趣味とし、旅行の予算が「70,000（円）」であり、車椅子を使用していることがわかる。
【００５１】
以下、旅行条件の入力項目についてより詳細に説明する。「年月日」は、その旅行日の日付である。「出発地」は、その旅行日の旅程を開始する地域である。「到着地」は、その旅行日の旅程を終了する地域である。この例では、時間スロットは、午前、昼食、午後及び夕食の四種類が用意されている。各時間スロットには、その時間帯に訪問したいエリアと、参加したい活動分野を入力する。図２０では一日目のみが記載されているが、旅行が複数日に及ぶ場合には、日数分の旅行日のブロックが追加される。
【００５２】
図１７に示すステップＳ１３において、管理サーバ１に含まれる旅行条件受信部１３は、旅行者端末４から受信した旅行者情報を旅行者情報記憶部１１３へ記憶し、旅行者端末４から受信した旅行条件に基づいて作成した旅行計画管理情報を旅行計画記憶部１１４へ記憶する。旅行者情報記憶部１１３へ記憶された旅行者情報及び旅行計画記憶部１１４へ記憶された旅行計画管理情報は、後述する旅行者ＩＤ等により本人特定された旅行者のみが参照可能なように記憶される。この際、セキュリティの観点から参照可能な情報を限定するように構成してもよい。
【００５３】
図２１に旅行者情報記憶部１１３に記憶された旅行者情報の一例を示す。図２１の例は、図２０のデータ例に示した新たな旅行者情報を登録した状態を表している。旅行条件受信部１３は、旅行条件送信部４０からの旅行者情報を取得すると、旅行計画変更支援システム内でその旅行者を一意に識別するための旅行者ＩＤを生成し、「旅行者ＩＤ」フィールドへ設定する。図２１の例では、旅行者ＩＤは「TRT9001」が生成されたものとする。続いて、旅行条件受信部１３は、取得した旅行者情報の各入力値を対応するフィールドへ設定する。
【００５４】
図２２に旅行条件記憶部１１４に記憶された旅行計画管理情報の一例を示す。図２２のデータ例（１）は、旅行者ＩＤが「TRT9001」である旅行者が作成した、図２０のデータ例に示した旅行条件に従って登録された旅行計画管理情報を表している。旅行条件受信部１３は、旅行条件送信部４０からの旅行条件を取得すると、旅行計画変更支援システム内でその旅行計画管理情報を一意に識別するための旅行ＩＤを生成し、「旅行ＩＤ」フィールドへ設定する。図２２の例では、旅行ＩＤは「TR0001」が生成されたものとする。続いて、旅行条件受信部１３は、取得した旅行条件の各入力値を対応するフィールドへ設定する。この例では、この旅行計画管理情報に紐づく旅行者ＩＤは「TRT9001」であり、午前中の行動を表す時間スロット１は希望エリアが「エリア４」であり、希望活動分野が「美術鑑賞」である。また、昼食を表す時間スロット２は希望エリアが「エリア２」であり、希望活動分野が「食事」である。つまり、旅行者「TRT9001」は午前中にエリア４が割り当てられた区画で美術鑑賞を行い、エリア２が割り当てられた区画に移動して昼食にすることを希望していることがわかる。
【００５５】
旅行条件受信部１３は、後の処理に用いられる「イベントＩＤ」「評価データ」「総合評価」の各フィールドを追加する。この段階では、これらのフィールドには値が設定されない。これらのフィールドの用途については後述する。
【００５６】
図１７に示すステップＳ１４ａにおいて、管理サーバ１に含まれる旅行計画作成部１４は、旅行計画管理情報の各時間スロットに対して旅行条件に合致するイベント情報を抽出して割り付ける。イベントの割り付けが終了した旅行計画管理情報の例を、図２２のデータ例（２）に示す。登録時の旅行計画管理情報である図２２のデータ例（１）との相違点は、各時間スロットのイベントＩＤに値が設定されていることである。
【００５７】
イベントの割り付け方法は、具体的には、以下のように行う。すなわち、旅行計画管理情報の各時間スロットについて、開始日時、終了日時、希望エリア及び希望活動分野を取得し、これらをキーとして以下の四つの条件をすべて満たすイベント情報を抽出する。
（１）時間の合致判定
旅行計画管理情報の時間スロットの開始日時及び終了日時の値を、イベント情報記憶部１１０に記憶されている個々のイベント情報の開始日時及び終了日時の値と照合する。照合対象のイベント情報に含まれるイベントタイプが「期間限定あり」の場合は、イベントの開始日時から終了日時までの期間が、時間スロットの開始日時から終了日時までの期間に包含されることを合致の条件とする。イベントタイプが「期間限定なし」の場合は、時間スロットの開始日時及び終了日時とイベント情報の開始日時及び終了日時とを、時間部分のみで比較する。すなわち、時間スロットの開始時刻から終了時刻までの時間帯がイベント情報の開始時刻から終了時刻までの時間帯に包含されることを合致の条件とする。
（２）活動エリアの合致判定
旅行計画管理情報の希望エリアの値がイベント情報の開催エリアの値と一致することを合致の条件とする。
（３）活動分野の合致判定
旅行計画管理情報の希望活動分野の値がイベント情報の活動分野の値と一致することを合致の条件とする。
（４）定員数の確認
イベント情報に前述の定員数が設定されている場合には、定員に空きがあることを合致の条件とする。定員に空きがある状態とは、仮予約数、準予約数及び本予約数の合計数が定員数を超えていない状態である。
【００５８】
合致するイベント情報が複数抽出された場合は、例えば、抽出されたイベント情報の利用料金に基づいて一つのイベントを選択するとよい。具体的には、抽出された複数のイベント情報の利用料金の平均値を算出し、利用料金がその平均値に最も近いイベント情報を選択する方法をとることができる。
【００５９】
もしくは、合致するイベント情報が複数抽出された場合に、選択可能なイベント候補として複数のイベント情報を割り付けてもよい。詳しくは後述するが、この場合には、複数のイベント候補から評価実行者が適切なイベントを選択するようにする。
【００６０】
このようにしてイベント情報の選択が完了すると、そのイベントＩＤを対象の時間スロットの「イベントＩＤ」フィールドに書き込む。例えば、図２２のデータ例（１）に示した時間スロット１の旅行条件を図１２に示したイベント情報と照合すると、活動分野が「美術鑑賞」であり「エリア４」で開催されるイベントＩＤが「EVT1001」であるイベント情報が抽出される。
【００６１】
ステップＳ１４ａの処理は、旅行者やイベント提供者などが実行するように構成してもよい。作成される旅行計画素案は旅程全体を一度に作成してもよいし、日単位や時間帯単位のように一部分のみを作成して保留しておくなど、追記、変更などの数度の操作を繰り返して最終的に旅行計画素案を完成してもよい。旅行者やイベント提供者が旅行計画素案を作成する場合には、ステップＳ１０以降の任意のタイミングで実行することができる。
【００６２】
ステップＳ１４ｂにおいて、旅行計画作成部１４は、時間スロットに割り当てたイベント情報に定員数が設定されていた場合、そのイベントの仮予約を行う。具体的には、イベント情報記憶部１１０に記憶されたイベント情報の仮予約数フィールドの値に旅行者の人数を加算する。また、ステップＳ３１において、イベント提供者端末３に含まれるイベント仮予約部３１を通じて、イベントの仮予約を実行することも可能である。
【００６３】
ステップＳ１５ａにおいて、管理サーバ１に含まれる評価依頼部１５は、旅行者情報及び旅行計画管理情報に基づいて旅行計画素案を作成し、その旅行計画素案の評価を行う評価実行者を評価者情報に登録されている評価者から選出する。旅行計画素案の一例を、図２４のデータ例（１）に示す。この例は、図２１に示す旅行者情報と図２２のデータ例（２）に示すイベント割り付け後の旅行計画管理情報とに基づいて作成された旅行計画素案である。旅行計画素案は、旅行者情報及び旅行計画管理情報から評価に必要なフィールドを選択して結合した情報である。図２４に示す各フィールドの具体的な設定内容については、上述の旅行者情報及び旅行計画管理情報において説明した内容と同様である。
【００６４】
評価実行者の選出方法は具体的には以下のように行う。すなわち、旅行計画素案の性別、年齢、趣味、関心のある領域、各時間スロットに設定された希望エリア及び希望活動分野を取得し、これらをキーとして以下の五つの条件のいずれかを満たす評価者情報を抽出する。
（１）活動分野の合致性
旅行計画素案に含まれる希望活動分野フィールドのうち少なくとも一つの値が、評価者情報の趣味フィールドに設定された値と一致することを合致の条件とする。
（２）エリアの合致性
旅行計画素案に含まれる希望エリアフィールドのうち少なくとも一つの値が、評価者情報の居住地域フィールドあるいは詳しい地域フィールドの少なくとも一つの値と一致することを合致の条件とする。
（３）性別の合致性
旅行計画素案に含まれる性別フィールドに設定された値が、評価者情報の性別フィールドに設定された値と一致することを合致の条件とする。
（４）年齢の合致性
旅行計画素案に含まれる年齢フィールドに設定された値と評価者情報の年齢フィールドに設定された値の世代が一致することを合致の条件とする。ここで、世代とは、例えば10歳刻みでの年齢のように、ある基準で丸めた年齢の範囲である。
（５）趣味の合致性
旅行計画素案に含まれる趣味フィールドに設定された値のいずれか一つが、評価者情報の趣味フィールドに設定された値と一致することを合致の条件とする。
【００６５】
以上の合致性の判定に基づいて、一致する項目数の多い順に上位から予め定めた数の評価者を抽出して評価実行者を選出する。このとき、評価者情報の評価履歴フィールドを参照して、評価実施回数が多く、旅行者の評価が高い評価者を優先的に抽出してもよい。
【００６６】
例えば、図２４のデータ例（１）に示す旅行計画素案の評価を行う評価実行者を図１４に示す評価者情報から抽出するのであれば、女性であり美術鑑賞と音楽に関心が高い評価者「10002」及び「10003」が評価実行者として抽出されることになる。
【００６７】
ステップＳ１５ｂにおいて、評価依頼部１５は、選出した一人以上の評価実行者が利用する評価者端末５へ旅行計画素案の評価依頼を送信する。評価依頼は例えば評価実行者のメールアドレスへその旅行計画素案のＵＲＬ（Uniform Resource Location）がハイパーリンクとして記載された通知メールを送信するなどの方法により行われる。評価依頼部１５は、さらに、評価依頼を送信した評価実行者に関する評価者情報の評価履歴フィールドへ評価依頼を行った旅行ＩＤ及び依頼日時を設定する。
【００６８】
この際、旅行計画素案をすべての評価者端末５から参照可能な方法で公開してもよい。例えば、評価者端末５にインストールされたウェブブラウザにロードされたウェブページ、もしくは評価者端末５にインストールされた独自のアプリケーションのウィンドウとして構成された評価一覧画面から参照可能とする。旅行計画素案の内容は不特定の評価者から参照可能とし、その旅行計画素案が参照された回数（以下、ページビュー数とも言う）をカウントする。もしくは個々の旅行計画素案に対してボタンを用意し、ボタンが押下された回数（以下、いいね数とも言う）をカウントする。旅行計画素案の参照は、評価者情報が登録されている評価者に限定せず、不特定のユーザとしてもよい。このようにして収集したページビュー数やいいね数は、後述する総合評価値の判定において利用できる。
【００６９】
ステップＳ５１において、評価者端末５に含まれる評価依頼受信部５１は、管理サーバ１から受信した評価依頼が示す旅行計画素案の内容を、例えば、評価者端末５に表示される評価画面に表示する。評価依頼の受信は、例えば評価実行者が受信した通知メールに記載されたＵＲＬ（Uniform Resource Location）をクリックするなどの方法により実行される。具体的には、評価画面は、評価者端末５にインストールされたウェブブラウザにロードされたウェブページ、もしくは評価者端末５にインストールされた独自のアプリケーションのウィンドウである。
【００７０】
図１８に示すステップＳ５２において、評価実行者は、評価者端末５に表示される評価画面から旅行計画素案の評価を実施する。旅行計画素案の評価は、各自の経験や知識に基づいて、各時間スロットに割り付けられた各イベントに対して五段階の評価値を設定することで行う。評価者により評価値が設定された後の旅行計画素案の一例を、図２４のデータ例（２）に示す。この例では、評価実行者は提示された旅行計画素案の時間スロット１（午前中）に対して評価値「４」を、時間スロット２（昼食）に対して評価値「１」を与えている。図１４に示すとおり、評価実行者「10003」は車椅子利用者であって、エリア２とエリア４に関して詳しい知識を持っている。評価実行者「10003」は時間スロット２（昼食）に割り当てられたレストランが車椅子での利用には不適であることを知っており、この知識を活用して、時間スロット２のイベントに低い評価を与えている。このように、コンピュータが下した判断を人間のより総合的な判断で再評価することにより、旅行計画の質を高めることが可能になる。
【００７１】
旅行計画素案のいずれかの時間スロットに複数のイベント候補が割り付けられている場合には、評価実行者は適切なイベントを選択した上で、五段階の評価値を設定するものとする。
【００７２】
すべてのイベントの評価が終わると、評価者端末５に含まれる評価結果送信部５２は、評価者が評価画面上で入力した評価結果を管理サーバ１へ送信する。
【００７３】
図１８に示すステップＳ１６ａにおいて、管理サーバ１に含まれる評価判定部１６は、評価者端末５から受信した評価結果を旅行計画管理情報に登録する。評価判定部１６は、さらに、評価結果を受信した評価実行者に関する評価者情報の評価履歴フィールドへ回答日時を設定する。
【００７４】
ステップＳ１６ｂにおいて、評価判定部１６は、評価依頼を送信したいずれかの評価者端末５から評価結果を受信しているか否かを確認する。いずれかの評価者端末５から評価結果を受信しており、予め定めた受信待ち時間を経過した場合、もしくはすべての評価依頼を送信した評価者端末５から評価結果を受信した場合には、次のステップＳ１６ｃへ処理を続行する。いずれの評価者端末５からも評価結果を受信せずに受信待ち時間が経過した場合には、ステップＳ１７ａへ処理を進める。受信待ち時間は、例えば、一日（24時間）などに設定する。
【００７５】
ステップＳ１６ｃにおいて、評価判定部１６は、評価者端末５から受信した評価結果に含まれる評価値に基づいて旅行計画素案の総合評価値を求める。評価者端末５から受信した評価値が設定された後の旅行計画管理情報の一例を、図２２のデータ例（３）に示す。この例では、ある評価実行者の時間スロット１（午前中）に対する評価値は５であり、他の評価実行者の時間スロット１に対する評価値は４である。評価判定部１６は、例えば、これらの評価値の単純平均を計算して総合評価値を４．５とする。他の時間スロットについても同様に総合評価値を求め、旅行計画管理情報に設定する。総合評価値が設定された後の旅行計画管理情報の一例を、図２２のデータ例（４）に示す。評価値が設定された後の旅行計画管理情報である図２２のデータ例（３）との相違点は、各時間スロットの総合評価に値が設定されていることである。この例では、時間スロット１（午前中）の総合評価値は４．５であり、時間スロット２（昼食）の総合評価値は２．５であったことがわかる。
【００７６】
ステップＳ１６ｄにおいて、評価判定部１６は、旅行計画管理情報に設定されたすべての総合評価値が予め定めた基準値以上であるか否かを判定する。いずれかの時間スロットの総合評価値が基準値未満であれば、ステップＳ１４ａへ処理を戻す。一方、すべての時間スロットの総合評価値が基準値以上であれば、ステップＳ１７ａへ処理を進める。例えば、基準値を３．０に定めていたとすると、図２２のデータ例（４）に示す旅行計画管理情報は、時間スロット１（午前中）は適正であるが、時間スロット２（昼食）は不適と判定されることになる。
【００７７】
なお、総合評価値の判定において、上述のページビュー数やいいね数を考慮するように構成することもできる。例えば、ページビュー数の範囲に応じて予め定めた評価値を総合評価値に加算させればよい。例えば、ページビュー数100を超える毎に評価値を0.1加算するなどである。
【００７８】
評価判定部１６は、いずれかの時間スロットの総合評価値が基準値未満であり、ステップＳ１４ａへ処理を戻す場合であり、いずれかの時間スロットに割り付けられたイベント情報に定員数の設定があった場合には、イベント情報記憶部１１０に記憶されたイベント情報の仮予約数フィールドを旅行者の人数だけ減算することで、仮予約の解除を行う。また、イベント提供者の運用する予約管理システム等と連携して仮予約を実行していた場合には、同様にして仮予約を解除する。
【００７９】
再度実行するステップＳ１４ａにおいて、旅行計画作成部１４は、旅行計画管理情報の各時間スロットに対して旅行条件に合致するイベント情報を抽出して割り付ける。この際、総合評価値が基準値未満である時間スロットには、現在割り付けられているイベントとは異なるイベントが割り付けられるようにしなければならない。イベント情報の再割り付けが終了した旅行計画管理情報の例を、図２３のデータ例（５）に示す。
【００８０】
再度実行するステップＳ１４ｂからステップＳ１６ｄの処理は、上述の処理内容と同様である。ステップＳ１５ａにおいて選出される評価実行者は、前回と同一であってもよいし、前回とは異なる評価実行者を選出してもよい。再度評価者端末４から受信した評価値が設定された後の旅行計画管理情報の一例を、図２３のデータ例（６）に示す。再度総合評価値が設定された後の旅行計画管理情報の一例を、図２３のデータ例（７）に示す。この例では、時間スロット１（午前中）の総合評価値は４．５であり、時間スロット２（昼食）の総合評価値は４．０であったことがわかる。いずれの時間スロットの総合評価値も基準値３．０以上であるため、ステップＳ１７ａへ処理を進めることになる。
【００８１】
ステップＳ１７ａにおいて、管理サーバ１に含まれる承認依頼部１７は、旅行計画管理情報に基づいて旅行計画を作成し、その承認依頼を旅行者端末４へ送信する。承認依頼は例えば旅行者のメールアドレスへその旅行計画のＵＲＬ（Uniform Resource Location）がハイパーリンクとして記載された通知メールを送信するなどの方法により行われる。旅行計画の一例を、図２５のデータ例に示す。この例は、図２３のデータ例（７）に示す最終的な旅行計画管理情報に対して、図１２に示すイベント情報からイベント名、開催場所などの情報を補完することで、旅行者にとって内容を理解し易いように整形した情報である。
【００８２】
ステップＳ１７ｂにおいて、承認依頼部１７は、時間スロットに割り当てたイベント情報に定員数が設定されていた場合、イベント情報の仮予約数フィールドの値から旅行者の人数を減算し、準予約数フィールドの値に旅行者の人数を加算する。また、ステップＳ３２において、イベント提供者端末３に含まれるイベント準予約部３２を通じて、イベントの準予約を実行することも可能である。
【００８３】
ステップＳ４１において、旅行者端末４に含まれる承認依頼受信部４１は、受信した承認依頼が示す旅行計画の内容を、例えば、旅行者端末４に表示される承認画面に表示する。承認依頼の受信は、例えば旅行者が受信した通知メールに記載されたＵＲＬ（Uniform Resource Location）をクリックするなどの方法により実行される。承認画面は、旅行者端末４にインストールされたウェブブラウザにロードされたウェブページ、もしくは旅行者端末４にインストールされた独自のアプリケーションのウィンドウである。
【００８４】
ステップＳ４２において、旅行者は、旅行者端末４に表示される承認画面を用いて旅行計画の内容を確認し、承認するか否かを決定する。このとき、旅行者が報酬を支払うことで旅行計画の詳細が確認可能としてもよい。すなわち、無課金で旅行計画を確認した場合には旅行計画の概要のみが表示されたり、イベント名のみが確認できイベント情報の詳細を確認するために別の画面で表示しなければいけないなど手間が掛かる画面構成にしたりしておき、旅行者により報酬が支払われて初めて旅行計画の詳細が容易に確認可能な承認画面が表示されるように構成する。旅行者は旅行計画が適正であると判断した場合には、肯定的な承認結果を入力し、旅行計画が不適であると判断した場合には、否定的な承認結果を入力する。このとき、旅行者は旅行計画に対する満足度を、例えば五段階で入力する。評価値は様々な評価軸による複数の評価値の集合としてもよい。例えば、お手軽度、自慢度、マニアック度などを評価軸として、それぞれについて複数段階の評価値を入力するように構成する。承認結果の入力が終わると、旅行者端末４に含まれる承認結果送信部４２は、入力した承認結果及び満足度を管理サーバ１へ送信する。
【００８５】
ステップＳ１８ａにおいて、管理サーバ１に含まれる旅行計画確定部１８は、承認結果が肯定的であるか否定的であるかを判定する。承認結果が否定的である場合には、ステップＳ１４ａへ処理を戻す。一方、承認結果が肯定的である場合には、ステップＳ１８ｂへ処理を進める。
【００８６】
旅行計画確定部１８は、いずれかの時間スロットの総合評価値が基準値未満であり、ステップＳ１４ａへ処理を戻す場合で、いずれかの時間スロットに割り付けられたイベント情報に定員数の設定があった場合には、イベント情報記憶部１１０に記憶されたイベント情報の準予約数フィールドを旅行者の人数だけ減算することで、準予約の解除を行う。再度行うステップＳ１４ａからステップＳ１８ａの処理は、上述の処理内容と同様である。
【００８７】
ステップＳ１８ｂにおいて、旅行計画確定部１８は、旅行計画を確定する。旅行計画確定部１８は、承認結果とともに受信する満足度を、評価実行者に関する評価者情報の評価履歴フィールドへ利用者評価として設定する。
【００８８】
ステップＳ１８ｃにおいて、旅行計画確定部１８は、時間スロットに割り当てたイベント情報に定員数が設定されていた場合、そのイベントの本予約を行う。具体的には、イベント情報記憶部１１０に記憶されたイベント情報の準予約数フィールドの値から旅行者の人数を減算し、本予約数フィールドの値に旅行者の人数を加算する。また、ステップＳ３３において、イベント提供者端末３に含まれるイベント本予約部３３を通じて、イベントの本予約を実行することも可能である。
【００８９】
また、旅行計画確定部１８は、承認された旅行計画を評価した評価実行者に対して報酬を支払うように構成してもよい。例えば、イベント提供者は旅行計画に含まれるイベント情報に予めポイントを設定しておき、承認された旅行計画に含まれていたイベント情報に設定されたポイントを評価者のアカウントに蓄積する。そして、蓄積されたポイントが一定のポイントを超過するたびに評価者が事前に指定した口座へ金銭の支払い処理を行うようにする。
【００９０】
図２６〜２８を参照して、旅行計画遂行中にトラブル等により事情の変更が発生した際に旅行計画の変更案を作成する動作について、処理フローの一例を実際に行われる手続きの順に従って説明する。なお、図２６に示す「A3」「B4」「D2」の各符号は、図２７に示す「A3」「B4」「D2」の各符号へそれぞれ処理が継続することを表している。図２６に示す「C2」の符号は、図２８に示す「C2」の符号へ処理が継続することを表している。図２７及び図２８に示す「B5」の符号は、図２６に示す「B5」の符号へ処理が継続することを表している。図２７に示す「A4」「B6」の各符号は、図２８に示す「A4」「B6」の各符号へそれぞれ処理が継続することを表している。
【００９１】
図２６に示すステップＳ４３において、旅行者は旅行者端末４を用いて旅行計画変更依頼を作成し、その旅行計画変更依頼を管理サーバ１へ送信する。旅行者は、例えば、旅行者端末４に表示される入力画面から必要な情報を入力することで旅行計画変更依頼を作成する。具体的には、入力画面は、旅行者端末４にインストールされたウェブブラウザにロードされたウェブページ、もしくは旅行者端末４にインストールされた独自のアプリケーションのウィンドウである。旅行者端末４に含まれる変更依頼送信部４３は作成した旅行計画変更依頼を管理サーバ１へ送信する。
【００９２】
図２９に旅行計画変更依頼の入力項目の一例を示す。旅行計画変更依頼の入力項目は、明示入力項目と自動入力項目に分けられる。明示入力項目は旅行者が自ら画面操作により入力値を設定する項目である。自動入力項目は旅行者端末４が入力画面の表示に先立ってその旅行者端末４または管理サーバ１から自動的に取得した上で設定する項目である。
【００９３】
以下、旅行計画変更依頼の入力項目についてより詳細に説明する。「変更依頼理由」は旅行者が遭遇したトラブルの内容を示す情報であり、例えば、交通トラブル／体調不良など予め用意された選択肢から選択する。「変更時の優先事項」は変更後の旅行計画においても優先的に含めたい活動分野を選択する。「条件緩和項目」は元の旅行条件よりも質が下がっても許容できる内容について設定する。「旅行者ＩＤ」は旅行者を一意に特定するＩＤである。「旅行者名」は旅行者の氏名である。「遭遇日時」はトラブルに遭遇した日時であり、入力画面を最初に開いた際のシステム時刻が自動的に設定される。この例では、旅行者ＩＤが「TRT9001」である旅行者「A山B子」が「2013年2月24日11時30分」に「交通トラブル」に遭遇し、変更案の作成にあたっては活動分野が「観劇」のイベントが優先的に含まれることを希望しており、そのために「食事グレード」を下げても構わないと考えていることがわかる。
【００９４】
図２６に示すステップＳ１９において、管理サーバ１に含まれる変更依頼受信部１９は、旅行者端末４から旅行計画変更依頼を受信する。変更依頼受信部１９は、旅行計画変更依頼に含まれる旅行者ＩＤを参照して旅行者情報記憶部１１３から旅行者情報を読み込む。また、変更依頼受信部１９は、旅行計画記憶部１１４に記憶されている旅行計画からその旅行者が現在遂行中の旅行計画を特定し、変更対象の時間スロットとして現在の時間スロット及び次の時間スロットを抽出する。例えば、図２５のデータ例に示した旅行計画が旅行計画記憶部１１４に記憶されており、図２９のデータ例に示した旅行計画変更依頼を受信した場合であれば、2013年2月24日の時間スロット１及び時間スロット２が抽出される。
【００９５】
図２６に示すステップＳ２０ａにおいて、管理サーバ１に含まれる変更支援依頼部２０は、旅行計画変更依頼に基づいて旅行条件の変更を行う変更支援実行者を変更支援者情報に登録されている変更支援者から選出する。
【００９６】
変更支援実行者の選出方法は具体的には以下のように行う。すなわち、旅行計画の変更対象時間スロットに設定されたエリア及び活動分野を取得し、これらをキーとして以下の四つの条件のいずれかを満たす変更支援者情報を抽出する。
（１）支援可能日の合致性
旅行計画の変更対象時間スロットのすべてが、変更支援者情報の支援可能日フィールドに設定された時間スロットのいずれかと一致することを合致の条件とする。
（２）支援事由の合致性
旅行計画変更依頼に含まれる支援事由が、変更支援者情報の支援事由フィールドに設定された値のいずれかと一致することを合致の条件とする。
（３）エリアの合致性
変更対象時間スロットに含まれるエリアフィールドのうち少なくとも一つの値が、変更支援者情報の居住地域フィールドあるいは支援地域フィールドの少なくとも一つの値と一致することを合致の条件とする。
（４）活動分野の合致性
変更対象時間スロットに含まれる活動分野フィールドのうち少なくとも一つの値が、変更支援者情報の支援分野フィールドに設定された値と一致することを合致の条件とする。
【００９７】
以上の合致性の判定に基づいて、一致する項目数の多い順に上位から予め定めた数の変更支援者を抽出して変更支援実行者を選出する。このとき、変更支援者情報の支援履歴フィールドを参照して、支援実施回数が多く、旅行者の評価が高い変更支援者を優先的に抽出してもよい。
【００９８】
例えば、図２９に示す旅行計画変更依頼に対して支援を行う評価実行者を図１６に示す変更支援者情報から抽出するのであれば、支援可能日に2013年2月24日の時間スロット１が含まれ、支援事由に交通トラブルが含まれ、支援地域にエリア２またはエリア４が含まれ、趣味に美術鑑賞または食事が含まれる変更支援者ＩＤ「11001」及び「11003」の変更支援者が変更支援実行者として選出されることになる。
【００９９】
図２６に示すステップＳ２０ｂにおいて、変更支援依頼部２０は、選出した一人以上の変更支援実行者が利用する変更支援者端末６へ旅行計画変更依頼、旅行者情報、旅行計画を含む変更支援依頼を送信する。変更支援依頼は例えば変更支援実行者のメールアドレスへその旅行計画変更依頼のＵＲＬ（Uniform Resource Location）がハイパーリンクとして記載された通知メールを送信するなどの方法により行われる。変更支援依頼部２０は、さらに、変更支援依頼を送信した変更支援実行者に関する変更支援者情報の支援履歴フィールドへ変更支援依頼を行った旅行ＩＤ及び依頼日時を設定する。
【０１００】
ステップＳ６２において、変更支援実行者は、変更支援者端末６に表示される変更支援画面から変更後の旅行条件を入力し、変更後の旅行条件を管理サーバ１へ送信する。旅行条件の変更は、各自の経験や知識に基づいて、次の時間スロットの活動分野、開催エリアを選択することにより行われる。例えば、支援事由が交通トラブルであり、変更支援実行者がこれまでの経験から次次時間スロットの開始時間までに次次時間スロットの開催エリアへ到達可能な代替移動手段が存在しないと判断したとする。その場合、変更支援実行者は、次の時間スロットの開催エリアを、次次時間スロットの開始時間までに次次時間スロットの開催エリアへ到達可能なエリアへ変更することが考えられる。もしくは、次の時間スロットの活動分野が食事であれば、食事時間を短くできる店、例えばファーストフード店へ変更することも考えられる。
【０１０１】
ステップＳ２１において、管理サーバ１に含まれる変更結果受信部２１は、変更支援者端末６から受信した変更後の旅行条件に基づいて作成した旅行計画管理情報を旅行計画記憶部１１４へ記憶する。旅行計画記憶部１１４へ記憶された旅行条件は、旅行者ＩＤ等により本人特定された旅行者のみが参照可能なように記憶される。この際、セキュリティの観点から参照可能な情報を限定するように構成してもよい。
【０１０２】
ステップＳ２２ａにおいて、管理サーバ１に含まれる旅行計画変更部２２は、変更後の旅行条件に基づいて追加された旅行計画管理情報の各時間スロットに対して旅行条件に合致するイベント情報を抽出して割り付ける。このとき、旅行条件が変更された変更対象時間スロットのみをイベントを割り付ける対象とすればよい。
【０１０３】
イベントの割り付け方法は具体的には以下のように行う。すなわち、旅行計画管理情報の各時間スロットについて、開始日時、終了日時、希望エリア及び希望活動分野を取得し、これらをキーとして以下の四つの条件をすべて満たすイベント情報を抽出する。
（１）時間の合致判定
旅行計画管理情報の時間スロットの開始日時及び終了日時の値を、イベント情報記憶部１１０に記憶されている個々のイベント情報の開始日時及び終了日時の値と照合する。照合対象のイベント情報に含まれるイベントタイプが「期間限定あり」の場合は、イベントの開始日時から終了日時までの期間が、時間スロットの開始日時から終了日時までの期間に包含されることを合致の条件とする。イベントタイプが「期間限定なし」の場合は、時間スロットの開始日時及び終了日時とイベント情報の開始日時及び終了日時とを、時間部分のみで比較する。すなわち、時間スロットの開始時刻から終了時刻までの時間帯がイベント情報の開始時刻から終了時刻までの時間帯に包含されることを合致の条件とする。
（２）活動エリアの合致判定
旅行計画管理情報の希望エリアの値がイベント情報の開催エリアの値と一致することを合致の条件とする。
（３）活動分野の合致判定
旅行計画管理情報の希望活動分野の値がイベント情報の活動分野の値と一致することを合致の条件とする。
（４）定員数の確認
イベント情報に前述の定員数が設定されている場合には、定員に空きがあることを合致の条件とする。定員に空きがある状態とは、仮予約数、準予約数及び本予約数の合計数が定員数を超えていない状態である。
【０１０４】
合致するイベント情報が複数抽出された場合は、例えば、抽出されたイベント情報の利用料金に基づいて一つのイベントを選択するとよい。具体的には、抽出された複数のイベント情報の利用料金の平均値を算出し、利用料金がその平均値に最も近いイベント情報を選択する方法をとることができる。
【０１０５】
もしくは、合致するイベント情報が複数抽出された場合に、選択可能なイベント候補として複数のイベント情報を割り付けてもよい。詳しくは後述するが、この場合には、複数のイベント候補から評価実行者が適切なイベントを選択するようにする。
【０１０６】
このようにしてイベント情報の選択が完了すると、そのイベントＩＤを対象の時間スロットの「イベントＩＤ」フィールドに書き込む。
【０１０７】
図３０に変更後の旅行条件に基づいて作成された旅行計画の変更案の一例を示す。「当初旅行計画」は旅行者が旅行計画変更依頼を送信する直前に遂行していた旅行計画である。「変更案１」及び「変更案２」はそれぞれ異なる変更支援者から受信した変更結果に基づいて作成された旅行計画の変更案である。「変更案１」では移動時間を確保するために食事時間が短くて済むファーストフード店で食事を行うように変更されている。「変更案２」では次次時間スロットの開催エリアへ移動しやすいエリアで食事を行うように変更されている。
【０１０８】
図２６に示すステップＳ２２ｂにおいて、旅行計画変更部２２は、時間スロットに割り当てたイベント情報に定員数が設定されていた場合、そのイベントの仮予約を行う。具体的には、イベント情報記憶部１１０に記憶されたイベント情報の仮予約数フィールドの値に旅行者の人数を加算する。また、ステップＳ３１において、イベント提供者端末３に含まれるイベント仮予約部３１を通じて、イベントの仮予約を実行することも可能である。
【０１０９】
ステップＳ１５ａ以降の処理は、上述した旅行計画を新規に作成する場合の処理と同様である。ただし、旅行計画の変更案が複数存在する場合には、ステップＳ１５ａからステップＳ１６ｂまでの処理において、すべての変更案についてそれぞれ処理を行う。また、ステップＳ１６ｃにおいて、総合評価値が最も高い変更案の総合評価値に基づいて判定を行う。
【０１１０】
図３１に旅行計画の変更案が複数存在する場合の総合評価値の例を示す。この例では、変更案１は三人の評価者がそれぞれ４、１、３の評価値を与えていることがわかる。総合評価値はその単純平均であるため、２．６６６…となる。変更案２は三人の評価者がそれぞれ４、４、４の評価値を与えており、総合評価値は４．０となる。ここで、基準値を３．０に定めていたとすると、変更案２は基準値を上回っているため適正と判定されることになる。
【０１１１】
なお、上述した一連の過程において、旅行者と評価者が同一のユーザであっても構わない。すなわち、旅行者は他の旅行者のための旅行計画素案を評価してもよいし、評価者は旅行者として旅行計画の作成依頼を行なってもよい。同様に、旅行者と変更支援者が同一のユーザであっても構わない。すなわち、旅行者は他の旅行者のための旅行計画変更支援を行ってもよいし、変更支援者は旅行者として旅行計画の作成依頼を行なってもよい。また、評価者と変更支援者が同一のユーザであっても構わない。すなわち、旅行条件変更依頼に従って旅行条件の変更を行ったユーザが評価者として変更案の評価を行ってもよい。
【０１１２】
このように、実施形態の旅行計画変更支援システムは、旅行者の要望に応じてコンピュータにより効率的に作成した旅行計画に対して、旅行計画遂行中の急な事情の変更に応じた旅行計画の変更案を効率的に作成することができる。特に、コンピュータによる機械的なイベントの変更のみでなく、地域の事情やイベントの特質に精通した変更支援者が旅行条件の変更を行うことで、効率的に旅行計画の変更案を提示することが可能になる。
【０１１３】
［プログラム、記録媒体］
この発明は上述の実施形態に限定されるものではなく、この発明の趣旨を逸脱しない範囲で適宜変更が可能であることはいうまでもない。上記実施例において説明した各種の処理は、記載の順に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。
【０１１４】
また、上記実施形態で説明した各装置における各種の処理機能をコンピュータによって実現する場合、各装置が有すべき機能の処理内容はプログラムによって記述される。そして、このプログラムをコンピュータで実行することにより、上記各装置における各種の処理機能がコンピュータ上で実現される。
【０１１５】
この処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等どのようなものでもよい。
【０１１６】
また、このプログラムの流通は、例えば、そのプログラムを記録したＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体を販売、譲渡、貸与等することによって行う。さらに、このプログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することにより、このプログラムを流通させる構成としてもよい。
【０１１７】
このようなプログラムを実行するコンピュータは、例えば、まず、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、一旦、自己の記憶装置に格納する。そして、処理の実行時、このコンピュータは、自己の記録媒体に格納されたプログラムを読み取り、読み取ったプログラムに従った処理を実行する。また、このプログラムの別の実行形態として、コンピュータが可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することとしてもよく、さらに、このコンピュータにサーバコンピュータからプログラムが転送されるたびに、逐次、受け取ったプログラムに従った処理を実行することとしてもよい。また、サーバコンピュータから、このコンピュータへのプログラムの転送は行わず、その実行指示と結果取得のみによって処理機能を実現する、いわゆるＡＳＰ（Application Service Provider）型のサービスによって、上述の処理を実行する構成としてもよい。なお、本形態におけるプログラムには、電子計算機による処理の用に供する情報であってプログラムに準ずるもの（コンピュータに対する直接の指令ではないがコンピュータの処理を規定する性質を有するデータ等）を含むものとする。
【０１１８】
また、この形態では、コンピュータ上で所定のプログラムを実行させることにより、本装置を構成することとしたが、これらの処理内容の少なくとも一部をハードウェア的に実現することとしてもよい。
【符号の説明】
【０１１９】
１  管理サーバ
３  イベント提供者端末
４  旅行者端末
５  評価者端末
６  変更支援者端末
１０  イベント情報登録部
１１  評価者情報登録部
１２  変更支援者情報登録部
１３  旅行条件受信部
１４  旅行計画作成部
１５  評価依頼部
１６  評価判定部
１７  承認依頼部
１８  旅行計画確定部
１９  変更依頼受信部
２０  変更支援依頼部
２１  変更結果受信部
２２  旅行計画変更部
１１０  イベント情報記憶部
１１１  評価者情報記憶部
１１２  変更支援者情報記憶部
１１３  旅行者情報記憶部
１１４  旅行計画記憶部
３０  イベント情報送信部
３１  イベント仮予約部
３２  イベント準予約部
３３  イベント本予約部
４０  旅行条件送信部
４１  承認依頼受信部
４２  承認結果送信部
４３  変更依頼送信部
５０  評価者情報送信部
５１  評価依頼受信部
５２  評価結果送信部
６０  変更支援者情報送信部
６１  変更支援依頼受信部
６２  変更結果送信部
１０１，３０１，４０１，５０１，６０１  制御部
１０２，３０２，４０２，５０２，６０２  メモリ
【図１】
2015049736.tif 000003
【図２】
2015049736.tif 000004
【図３】
2015049736.tif 000005
【図４】
2015049736.tif 000006
【図５】
2015049736.tif 000007
【図６】
2015049736.tif 000008
【図７】
2015049736.tif 000009
【図８】
2015049736.tif 000010
【図９】
2015049736.tif 000011
【図１０】
2015049736.tif 000012
【図１１】
2015049736.tif 000013
【図１２】
2015049736.tif 000014
【図１３】
2015049736.tif 000015
【図１４】
2015049736.tif 000016
【図１５】
2015049736.tif 000017
【図１６】
2015049736.tif 000018
【図１７】
2015049736.tif 000019
【図１８】
2015049736.tif 000020
【図１９】
2015049736.tif 000021
【図２０】
2015049736.tif 000022
【図２１】
2015049736.tif 000023
【図２２】
2015049736.tif 000024
【図２３】
2015049736.tif 000025
【図２４】
2015049736.tif 000026
【図２５】
2015049736.tif 000027
【図２６】
2015049736.tif 000028
【図２７】
2015049736.tif 000029
【図２８】
2015049736.tif 000030
【図２９】
2015049736.tif 000031
【図３０】
2015049736.tif 000032
【図３１】
2015049736.tif 000033