JP2020173807A - 旅行プラン提案システム - Google Patents

Abstract

【課題】旅行者が、宿泊先でのチェックイン、宿泊施設内の案内や観光案内などの旅行に関する一連の作業を容易にする情報処理システムを提供する。【解決手段】旅行地提案システムは、ユーザの旅行中の行動を取得して、その行動の特徴を解析する行動データ解析手段と、ユーザが過去に旅行した場所や旅行中のユーザの行動を基に、ユーザが次に旅行したくなるものを提供する次旅行提案手段と、ユーザ嗜好分析手段と、情報配信管理手段と、ユーザが旅行中に行動したデータを記憶するユーザが過去に旅行した期間や場所を記憶する旅行記録手段と、ユーザが旅行中に行動したデータを記憶するユーザ行動データ記録手段と、ユーザの国籍、年齢、性別などを記憶するユーザ属性記録手段と、相関記録手段と、情報記録手段と、制御手段と、ユーザ通信手段と、を備える。ユーザ行動取得・送信手段と、情報受信手段との間で、任意のデータ通信が可能である。【選択図】図１

Description

本発明は、旅行業務を管理する情報処理システムに関するものであり、特に、宿泊の予約、チェックイン、宿泊に関する各種業務、観光に関する各種サービスを提供するための情報処理に関するものである。また、本発明は、ユーザの嗜好にあう旅行プランを提案するシステムに関するものである。

既存の宿泊業務に関するシステムは、宿泊施設ごとに個別に最適化されているうえに、複数のいわゆるオンプレミス型のシステムが混在して複雑化している。
例えば、チェックインだけを見ても、旅行者から見れば、チェックイン待ちの行列に長い時間待たせられたり、旅行予約サイトに代表されるＯＴＡ（Ｏｎｌｉｎｅ Ｔｒａｖｅｌ Ａｇｅｎｔ）を経由して登録した内容（宿泊者の氏名等）を再度宿泊施設で記入させられたりする。一方、宿泊施設側の従業者も、チェックインのために事前準備や、チェックインのためのシステム入力確認作業や、宿泊客への説明や荷物預かりなどの多岐にわたる作業等を短時間にこなす必要があり、さらに、チェックインをしない旅行者のフォローなどの雑務も多々ある。
上述したような現状は、旅行者と宿泊業者との間のミスコミュニケーションを引き起こすだけではなく、情報の管理・共有の非効率化や属人化も引き起こす。
従来から、ユーザに嗜好にあう旅行プランを提案するシステムは存在する。例えば、特許文献１では、簡単な操作で個人の嗜好に合った旅行プランを作成し、旅行履歴をサーバにアップロードすることによって、自身および他人の旅行プランを有効に活用するシステムが開示されている。旅行プランを提案するにあたっては、ユーザの嗜好を客観的に判断することが重要であるが、従来技術においては、ユーザ自身の嗜好をアンケート形式で答えさせることによって、ユーザの嗜好を特定している。このような方法だと、実質的には、ユーザ自らが行きたい旅行先を探しているにすぎず、また、アンケートに答えている時のユーザの気分に左右されやすく、結果として、客観的にユーザの嗜好を判断していない。

特開２０１０−００３１５８号公報

本発明の一態様によると、旅行者が、宿泊先でのチェックイン、宿泊施設内の案内や観光案内などの旅行に関する一連の作業を容易にする情報処理システムを提供することである。
本発明の別の一態様によると、宿泊に関する情報処理や、観光情報の提供に関する情報処理などの一連の宿泊および旅行業務に関する情報処理を一元管理するための情報処理システムを提供することである。
本発明の更に別の一態様によると、ユーザの嗜好を客観的に判断して、ユーザごとに最適な旅行地や宿泊先を提案するシステムを提供することである。

旅行業務を管理するための情報処理システムにおいて、管理サーバと、宿泊情報を管理する宿泊予約サービス装置と、宿泊施設側装置と、ユーザ端末とが、それぞれネットワークを介して接続されており、前記管理サーバは、ユーザ識別子およびユーザ側ステータスを管理する手段と、宿泊施設識別子および宿泊施設側ステータスを管理する手段と、情報配信の履歴を格納する配信履歴データベースと、を備え、前記ユーザ端末は、前記管理サーバが付与したユーザ識別子を使用して、宿泊予約サービスにログインして、宿泊施設識別子および宿泊日を選択できるように構成されており、前記宿泊予約サービス装置は、前記管理サーバから取得したユーザ識別子と、ユーザ端末が選択した宿泊施設識別子および宿泊日とを関連付けて、前記管理サーバに送信し、前記管理サーバは、さらに、前記ユーザ識別子と、前記宿泊施設識別子と、前記宿泊日と、前記情報配信の履歴と、に基づいて、ユーザ側ステータスおよび宿泊施設側ステータスを決定する手段と、当該決定されたユーザ側ステータスと前記宿泊施設側ステータスとの組み合わせに基づく情報を、情報配信データベースから取得して、前記ユーザ端末に配信する手段と、前記ユーザ識別子との前記宿泊施設識別子の組み合わせごとに、当該決定されたユーザ側ステータスと前記宿泊施設側ステータスとの組み合わせと、前記配信された情報とを関連付けて、時系列で前記配信履歴データベースに記憶する手段と、を備える、ことを特徴とするシステムを提供する。

本発明の一態様によると、サービスを受ける側（ユーザ）はサービスを受けるためにかかる時間を低減することができる。
本発明の別の一態様によると、サービスを提供する側（宿泊施設や観光スポットにある店舗など）がサービスを提供するために必要な作業時間を減らして業務効率を向上させることができる。
本発明の更に別の一態様によると、ユーザの嗜好に基づく旅行プランを提供することにより、顧客満足度を向上させることができるだけでなく、不要な提案を減らすこともできるのでホテル側の業務効率の改善が図れる。また、ユーザの期待度の高い旅行プランを提供することができるので、旅行のキャンセル等による不要な作業を減らすことができるので、旅行プラン提供者も、収益性を向上させることができる。

本発明の別の態様によると、宿泊先でのチェックインをオンラインを介して自動で行えるようになるので、サービスを受ける側（ユーザ）だけでなくサービスを提供する側（宿泊先）でも作業時間を削減することができる。

本発明の他の目的、特徴及び利点は添付図面に関する以下の本発明の実施例の記載から明らかになるであろう。

本発明の一実施例による旅行提案システムのブロック図を示す。 本発明の一実施例による旅行を提案する手順をフローチャートで示す。 本発明の一実施例による旅行提案システムのデータ構造の一例を示す。 本発明の一実施例による宿泊予約接客システムのブロック図を示す。 本発明の一実施例による宿泊予約および接客する手順をフローチャートで示す。 本発明の一実施例による宿泊予約接客システムのデータ構造の一例を示す。 本発明の一実施例による旅行プラン提供システムの概念図を示す。 本発明の一実施例による旅行プラン提供システムの具体例を示す。 本発明の一実施例による管理画面の表示例を示す。 本発明の一実施例によるオンラインチェックインの手順をフローチャートで示す。 本発明の一実施例による観光スポット提案システムのブロック図を示す。 本発明の一実施例による滞在中のプランを提案する手順をフローチャートで示す。 本発明の一実施例による旅行業務管理システムの概念図を示す。 本発明の一実施例による旅行業務を管理する手順をフローチャートで示す。 本発明の一実施例による旅行業務を管理するためのステータスを示す。 本発明の一実施例による旅行業務を管理するための配信履歴データベースのデータ構造を示す。

図７（ａ）および図７（ｂ）は、それぞれ、本発明の一実施例による旅行プラン提供システムの概念図および具体例を示す。図７（ａ）の旅行プラン提供システムは、旅行地提案システム１０００と、宿泊予約接客システム３０００と、旅程提案システム５０００とから構成されており、当該システムは、宿泊施設、Ｔｒａｖｅｌ Ａｇｅｎｔ（実在またはオンラインの旅行代理店）、ユーザ（ユーザ自身の情報端末等）に接続されている。図７（ｂ）は、図７（ａ）の概念図を具体的に示した実施例を示す。

図１は、本発明の一実施例による旅行地提案システム１０００のブロック図を示す。

本実施例の旅行地提案システム１０００は、行動データ解析手段１１１０と、次旅行提案手段１１２０と、ユーザ嗜好分析手段１１３０と、情報配信管理手段１１４０と、旅行記録手段１２１０と、ユーザ行動データ記録手段１２２０と、ユーザ属性記録手段１２３０と、相関記録手段１２４０と、情報記録手段１２５０と、制御手段１３１０と、ユーザ通信手段１３２０とを備え、ユーザ行動取得・送信手段１４１０と、情報受信手段１４２０との間で、任意のデータ通信が可能なように構成されている。

行動データ解析手段１１１０は、ユーザの旅行中の行動を取得して、その行動の特徴を解析する。

次旅行提案手段１１２０は、ユーザが過去に旅行した場所や旅行中のユーザの行動を基に、ユーザが次に旅行したくなるものを提供する。

ユーザ嗜好分析手段１１３０は、ユーザの嗜好を分析する。

情報配信管理手段１１４０は、電子メールなどによりユーザに対して旅行地を提案する際に、複数の旅行地を一度に提案をするのではなく、季節のイベント（開催時期）や割引クーポン（適用可能時期）などの情報とあわせて、これらのイベントやクーポンが適用できる時期の所定期間前（例えば、１〜２ヶ月前）に配信する。イベント等がない場合は、所定の期間毎に（数カ月毎に）配信してもよい。ここで、イベントやクーポンの情報を配信するにあたっては、ユーザの嗜好に適合する可能性が高い（各ユーザの過去の旅行の記録を参照して、相関度が所定値以上の）旅行地に関係するイベントやクーポンのみを配信するように構成されてもよい。

旅行記録手段１２１０は、ユーザが過去に旅行した期間や場所を記憶する。データ構造の一例を図３（ａ）に示す。

ユーザ行動データ記録手段１２２０は、ユーザが旅行中に行動したデータを記憶する。データ構造の一例を図３（ｂ）に示す。

ユーザ属性記録手段１２３０は、ユーザの属性（国籍、年齢、性別など）を記憶する。データ構造の一例を図３（ｃ）に示す。

相関記録手段１２４０は、ある場所を旅行した人が、比較的多く旅行する場所（候補地）を記憶する。また、相関記録手段１２４０は、候補地が複数ある場合には相関度と共に記憶するように構成されてもよい。本実施例の相関度は０〜１の間の値であり、０は相関度が最も低く、１は相関度が最も高い。候補地の中で実際に旅行した場所又は旅行の予約をした場所が多いほど、相関度が高くなるように設定されてもよい。データ構造の一例を図３（ｄ）に示す。なお、相関度の初期値に関しては、任意の値が事前に設定されていてもよく、複数のデータに基づいて計算された値でもよい。

情報記録手段１２５０は、季節のイベント（開催時期）や割引クーポン（適用可能時期）を記録する。

制御手段１３１０は、旅行地提案システム１０００内部の各手段を制御する。

ユーザ通信手段１３２０は、ユーザ行動取得・送信手段１４１０や、情報受信手段１４２０との間でデータを送受信する。

ユーザ行動取得・送信手段１４１０は、ユーザの行動データを取得して、送信する。ここで、ユーザの行動データとは、ＧＰＳなどから得られる移動データ、マイクなどによるユーザの音声データ、リストバンドなどから得られる心拍数データなどである。ユーザ行動取得・送信手段１４１０は、例えば、腕時計型の情報端末などでもよい。

情報受信手段１４２０は、次の旅行の提案などに関するデータを受信する手段であるが、ユーザ入力等により情報を送信できるように構成されてもよい。情報受信手段１４２０は、例えば、スマートフォン、パソコン、タブレット端末などでもよい。また、ユーザ行動取得・送信手段１４１０の機能を兼ね備えてもよい。

図２は、本発明の一実施例による旅行プランを提供するフローチャートを示す。

Ｓ２０１０では、過去にユーザが訪れた旅行地および当該旅行地内の１つまたは複数の観光スポットにおけるユーザの行動データを取得する。本実施例における行動データは、ユーザが有する端末（ユーザ行動取得・送信手段１４１０など）内のＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）などによって取得された位置情報および時間情報である。

Ｓ２０２０では、取得した行動データを解析する。例えば、観光スポットの位置情報を登録しておき、当該観光スポットの位置情報から所定範囲内にユーザの位置情報があれば、ユーザは、登録された観光スポットに訪れたものとして記録される。あわせて、観光スポットの位置情報から所定範囲内に滞在した時間を計測することにより、当該計測された時間が、観光スポットの滞在時間であるとして記録する。更に、ユーザの端末に備えられた身体データ（例えば、脈拍）を測定する手段によって、ユーザの身体データを記録しておくように構成されてもよい。

Ｓ２０３０では、訪れた観光スポットのリストを作成して、ユーザの嗜好を分析する。例えば、ユーザが滞在した時間が長い観光スポットは、ユーザの嗜好が高いと分類してもよい。 また、心拍数データを取得した場合は、ユーザの心拍数が旅行中の平均心拍数（日中などの時間帯の平均でもよい）よりも高い時間帯が長い観光スポットは、ユーザの嗜好が高いスポットであったと判断してもよい。例えば、身体データが脈拍の場合、ある観光スポットに滞在しているとき、（他の観光スポットに滞在しているときと比較して、）脈拍が相対的に多いとする。そのようなときは、ユーザは、当該観光スポットへの興味や嗜好が高いと判断することができる。例えば、ユーザの旅行地が京都であった場合、当該ユーザが京都タワー（観光スポットＡとする）に訪れたときの滞在時間が約１０分であり、脈拍が約５０であったが、清水寺（観光スポットＢ）に訪れたときの滞在時間が約６０分であり、脈拍が約６５であったと仮定する。この場合は、観光スポットＡよりも観光スポットＢの方が、滞在時間も脈拍も相対的に高い値であるので、観光スポットＡの方がユーザの嗜好性が高いと判断することができる。別の実施例として、滞在時間のみや脈拍のみで判断してもよい。また、各観光スポットにおける平均滞在時間を予め記録しておき、当該平均滞在時間よりも長く滞在していた場合には、ユーザの嗜好性が高い観光スポットであると判断してもよい。

Ｓ２０４０では、ユーザの高い嗜好の観光スポットと似たような観光スポットが、今回の旅行とは別の場所にあるか否かを、相関記録手段１２４０に問いあわせる。

Ｓ２０５０では、相関記録手段１２４０から取得した（１つまたは複数の）データから、ユーザが過去に訪れた旅行地の観光スポットにおけるユーザの滞在時間やユーザの身体データなどを基に、ユーザが好む旅行地の候補を選択する。相関記録手段１２４０から複数のデータが取得できた場合は、ユーザの嗜好が高いであろう観光スポットが多く含む旅行地を選択してもよい。例えば、相関記録手段１２４０には、相関値が記録されているので、相関値が相対的に高い（例えば、相関度上位１つでもよく、複数でもよい）旅行地や観光スポットを選択してもよい。なお、新たな旅行地を選択する際には、旅行記録手段に問いあわせて、過去にユーザが訪れた旅行地・観光スポットと重複しないように構成されてもよい。例えば、ユーザの嗜好性の高い観光スポットが京都の清水寺であると判断された場合、図３（ｄ）に示すような相関データベースに対して、京都の清水寺と相関度が高い場所を問いあわせる。相関データベースは、相関度が高い地域を抽出して、データを返送する。図３（ｄ）では、奈良の東大寺の相関度が０．９であり、和歌山の高野山が０．７であったので、奈良の東大寺である旨を返送する。

Ｓ２０６０では、返送された観光スポットの情報を、情報受信手段を介して受信し、当該受信した情報を基に、旅行地の候補をユーザに提示する。ここで、旅行記録手段１２１０を検索して、ユーザの過去に訪問した記録がある場合には、候補から除外するように構成されてもよい。また、ユーザの嗜好に関するが事前にデータベースに登録されている場合は、その情報を加味して、相関度を修正し、その修正された相関度を基に、ユーザへの候補を決定しもよい。例えば、ユーザの嗜好として、山にある観光スポットよりも平地（盆地）や街中にある観光スポットを好む場合は、図３（ｄ）の奈良の東大寺の相関度を上げて、和歌山の高野山の相関度を下げた上で、候補を選定してもよい。

別の実施例として、Ｓ２０１０で取得するユーザの行動データが、ＧＰＳなどによる位置情報および時間情報に加えて、備え付けられたマイクから得られる音声データや、ユーザが腕に取り付けているリストバンドから得られる心拍数や血圧などのデータを含んでもよい。
例えば、音声データを取得した場合は、ユーザが楽しそうな言葉（「いいね！」「すごい！」）を発した数が多い観光スポットは、ユーザの嗜好が高い観光スポットであったと判断してもよい。

更に、Ｓ２０６０でユーザに提案した旅行地に対して、ユーザが当該提案を受け入れたか否かに基づいて、相関関係を修正して、ユーザ毎に相関値を修正するように構成されてもよい。例えば、図３（ｄ）において、京都の清水寺と奈良の東大寺の相関度は０．９であると記録されている。しかし、京都の清水寺を訪問したユーザＡに提案したところ、奈良の東大寺に関しては興味がない（例えば、旅行プランの予約がされなかったとか、お気に入りに登録されなかったなど）と扱われた。かかる場合には、ユーザＡにおける相関度を、０．９から、例えば０．７に下げる。次に、和歌山の高野山を提案したところ、興味がある（例えば、旅行プランの予約がされたとか、お気に入りに登録されたなど）と扱われたので、ユーザＡにおける相関度を０．７から、例えば、旅行プランの予約がされた場合には０．９に上げて、お気に入りに登録された場合には、０．８に上げてもよい。そして、これら修正された相関度を、ユーザごとに相関記録手段に記憶してもよい。

なお、相関記録手段１２４０に記憶される相関度のデータを作成するにあたっては、データベースに記録された全てのユーザまたは所定の複数のユーザについて、当該ユーザが訪れた複数の旅行地または複数の観光スポットの関係を所定の計算手法（例えば、単純平均、統計処理または機械学習）をして、ある観光スポットと別の観光スポットとの相関関係を計算して相関度（以下、全体の相関度と称する）を記録するように構成されてもよい。簡単な例を挙げて説明すると、旅行地Ａと旅行地Ｂとの相関が、ユーザＡは０．８、ユーザＢは０．６だったとする。その場合は、両者の平均である０．７が旅行地Ａと旅行地Ｂとに関する全体の相関度になる。その後、ユーザＢに対する相関が０．６から０．８へ変化した場合は、全体の相関度は０．８になる。なお、別の実施例として、（例えば、人気のある）旅行地Ａに対する（例えば、穴場の）旅行地Ｂへの相関度と、旅行地Ｂに対する旅行地Ａへの相関度が異なっていてもよい。

なお、Ｓ２０６０においては、ユーザの嗜好に基づいて相関度が修正される実施例を説明したが、別の実施例においては、ユーザが旅行したい時期を考慮して、相関度が調整されてもよい。例えば、ユーザの嗜好が、夏の時期には沖縄などの南方に訪れる傾向がある一方で、冬の時期には北海道などの北方に訪れる傾向があれば、このような傾向を考慮して、相関度を時期的に調整してもよい。

本実施例の相関度については、データベースに記録された複数のユーザについて、当該ユーザが訪れた複数の旅行地または複数の観光スポットの関係を機械学習や統計的な手法に基づいて計算されてもよい。また、ユーザ毎に修正された相関度を用いて、各観光スポットの相関関係を新たに機械学習や統計的に処理してもよい。

図４は、別の発明の一実施例による宿泊予約接客システム３０００のブロック図を示す。特に、本実施例では、前述の実施例に追加することにより、旅行に対する満足度が更に高くなるシステムを提供する。具体的には、対話形式でユーザに問いかけて、ユーザの希望を引き出したり、旅行に付帯するもの（例えば、食事やお土産など）を提案するような自動接客をしたりする。

本実施例の宿泊予約接客システム３０００は、宿泊候補受付手段３１１０と、Ｃｈａｔ（チャット）手段３１２０と、自動接客手段３１３０と、旅行付帯提案手段３１４０と、ユーザ情報管理手段３１５０と、予約受付手段３１６０と、宿泊記録手段３２１０と、自動接客記録手段３２２０と、旅行付帯記録手段３２３０と、ユーザ登録情報記録手段３２４０と、宿泊施設通信手段３３３０と、制御手段３３１０と、ユーザ通信手段３３２０と、宿泊施設通信手段３３３０とから構成される。

更に、宿泊予約接客システム３０００は、宿泊施設４０００と連携するように構成されており、当該宿泊施設４０００は、宿泊施設管理手段４０１０と、オンラインチェックイン手段４０２０とを備える。

宿泊候補受付手段３１１０は、ユーザの使用端末から宿泊の予約を受け付ける。

Ｃｈａｔ手段３１２０は、チャット等の対話形式の手段を使ってユーザ端末と通信をして、ユーザに対して情報を送信したり、ユーザ端末から受信したデータを宿泊予約接客システム内の必要な情報を受信したりする。

自動接客手段３１３０は、ユーザを接客するための情報を処理する。

旅行付帯提案手段３１４０は、旅行に付帯するもの、例えば、おすすめの換金場所は、おすすめスポット、お土産の販売場所などを提案する。提案する条件は、例えば、宿泊施設またはユーザの所在地から所定範囲内であって、換金場所などの営業時間内であってもよい。

ユーザ情報管理手段３１５０は、ユーザの情報を管理する。例えば、ユーザの生年月日が登録されている場合は、現在の日時を基にユーザの年齢を計算する。また、ユーザの宿泊予約に関する記録、宿泊先への事前連絡によるキャンセルに関する記録、宿泊先への事前連絡無しによるキャンセルに関する記録などがあれば、これらの記録を基に、各ユーザのリピート率、キャンセル率、ＮＯＳＨＯＷ率などが計算できるように構成されてもよい。更に、ユーザ情報管理手段３１５０は、ユーザが宿泊先でチェックインを容易するための識別コード（例えば、ＱＲコード（登録商標））を生成して、ユーザ通信手段３３２０経由で、情報受信手段１４２０に送信してもよい。

予約受付手段３１６０は、ユーザが情報受信手段１４２０などを介して、宿泊予約をする際に、ユーザの宿泊予約を補助する。例えば、予約受付手段３１６０経由で、ユーザの所望するＯＴＡ（オンライン旅行代理店）のウェブサイトにアクセスする。そして、ＯＴＡのウェブサイトでユーザが入力する必要のある項目（例えば、名前など）を予め入力内容を表示したり、選択肢をしたりする。

宿泊記録手段３２１０は、ユーザの宿泊を記録する。データ構造の一例を、図６（ａ）に示す。

自動接客記録手段３２２０は、宿泊施設での接客を行うために、Ｃｈａｔ手段等を介して、ユーザの希望を問いあわせる。データ構造の一例を図６（ｂ）に示す。

旅行付帯記録手段３２３０は、旅行に付帯する様々な提案をする。データ構造の一例を図６（ｃ）に示す。

ユーザ登録情報記録手段３２４０は、ユーザ自身の情報を記録する。ユーザ自身の情報とは、例えば、ユーザ名（ニックネーム）、パスワード、氏名（漢字および／またはカナ表記）、生年月日（年齢は自動計算）、住所、連絡先（携帯電話番号やｅｍａｉｌ）などである。なお、上記の情報の中で、必須登録情報と任意登録情報とを事前に設定してもよい。例えば、氏名と生年月日と連絡先は登録が必須であるが、それ以外は任意で登録できるように設定してもよい。

宿泊施設通信手段３３３０は、宿泊施設管理手段４０１０に対して、宿泊予定のユーザの希望を送信したり、宿泊施設から自動接客できる項目を受信したりする。なお、宿泊施設管理手段４０１０は、ホテルなどの宿泊施設４０００に、それぞれ少なくとも１つ以上設置されている。

制御手段３３１０は、宿泊予約接客システム３０００内部の各手段を制御する。制御手段は、プロセッサやＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などでもよい。

ユーザ通信手段３３２０は、ユーザ行動取得・送信手段１４１０や、情報受信手段１４２０との間でデータを送受信する。

宿泊施設通信手段３３３０は、宿泊施設と必要な情報を送受信する。

宿泊施設管理手段４０１０は、宿泊施設通信手段３３３０と所定の情報を送受信する。
オンラインチェックイン手段４０２０は、ユーザが宿泊施設４０００にチェックインをするときに、ユーザが所有する情報携帯端末に表示された識別コード（例えば、ＱＲコード（登録商標））を読み取ることにより、宿泊者であるユーザの氏名や年齢などの情報が判別できるようになる。
別の実施例として、ユーザがスマホ上に表示した識別コードを読み取る以外にユーザが送信した情報が施設の管理画面で確認・承認してもよい。

本発明の一実施例による宿泊予約および接客する手順を図５のフローチャートで示す。

Ｓ５０１０では、定期的にユーザに旅行を提案する。ここで、本実施例の「定期的」とは、期間を空けて複数回ユーザに提案することを意味しており、前回の提案と今回の提案との間は、ある程度の時間的な間隔（１日〜数カ月程度）が空いていればよく、当該間隔も毎回異なっていてもよい。

Ｓ５０２０では、ユーザは、提案された旅行に興味があれば、所定のアプリケーションやインターネット上の予約サイトを通じて、宿泊予約をする。

Ｓ５０３０では、予約した宿泊施設で対応可能な接客情報を取得する。

Ｓ５０４０では、ユーザが宿泊予約を入れると、ユーザの更なる要望を引き出すために、電子メールなどを送り、電子メールに記載のＵＲＬ経由で誘導等をして、チャット手段につなげる。本実施例のチャット手段では、Ｓ５０３０で取得した接客情報を基にして、ユーザに対して問いあわせをする。例えば、図６（ｂ）を例に挙げて説明すると、ホテルＡを予約した場合は、枕の好みを択一形式でユーザに問いあわせ、次に、入浴剤の好みを問いあわせるような手順を実行する。

Ｓ５０５０は、（オプションの処理であるが、）ユーザに対して付帯的な提案をしてもよい。例えば、外国への旅行で、換金が必要な可能性がある場合は、換金レートの良いお店を紹介したり、宿泊施設のお薦めスポットを紹介したり、任期のあるお土産を紹介するようにしてもよい。ここで、これらの付帯的な提案が発生する条件は、例えば、ユーザが宿泊する施設またはユーザが訪問する場所から徒歩数分で行けるような範囲に入った場合または入る予定がある場合であって、且つ、提案するお店の営業時間内でユーザが訪問できると判断できた場合に、ユーザに対して提案できるように構成されてもよい。なお、付帯的な提案をするにあたっては、予め、旅行付帯記録手段のようなデータベースから、提案可能な一覧を取得できるように構成されてもよい。この提案可能な一覧を作成するにあたっては、前述したような、旅行地や観光スポットの相関値の考え方を利用して、ユーザが好む付帯的な提案を相関度が高い順に提案できるように構成されてもよい。

Ｓ５０６０では、チャット手段経由で取得した、ユーザの希望に関する情報を、宿泊施設等に送信する。

図８は、本発明の一実施例による宿泊施設管理手段４０１０に表示される管理画面の表示例を示す。

本実施例の管理画面の機能について説明する。
ＯＴＡ（Ｏｎｌｉｎｅ Ｔｒａｖｅｌ Ａｇｅｎｃｙ：オンライン旅行代理店）を介して取得したユーザのチェックイン、チェックアウトなどのデータを管理する。別の実施例として、ＯＴＡだけでなく、サイトコントローラから、ユーザのチェックイン、チェックアウトのデータを取得してもよい。
ＫＰＩ（ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒｓ：重要目標達成指標）は、本実施例においては、売上目標に対する進捗率が表示されている。別の実施例として、チェックアウト時に取得したユーザーの評価を表示し、顧客満足度の推移を表示してもよい。
在庫管理では、アメニティグッズや備品などの在庫数量を管理すると共に、次回発注時期を予測して表示されるように構成されている。在庫が残り少ない場合や急激に減少した場合には、例えば、在庫数量の色が赤色に変わってもよい。
ＮＯＳＨＯＷ率は、連絡なしで無断キャンセルされた割合を示す。
ユーザ（旅行者）から質問の多い、ホテル近隣のお勧めのレストランや近隣のイベント情報が表示されるように構成されてもよい。

ホテルマネージャーが顧客からもらった質問と、それに対する回答を入力していくことで、Ｃｈａｔ手段内のチャットボットの回答精度を向上させることが可能になる。例えば、当該回答に基づいて、相関関係を修正して、ユーザ毎に相関値を修正するように構成されてもよい。

例えば、ユーザが、チャットボットに、おすすめのレストランに関する情報を問いあわせたとする。チャットボットは、質問のキーワードと相関性の高いレストランを検索して、ユーザに返答する。

本発明の一実施例による旅程提案システム５０００について説明する。

実施例１で提案された旅行プランは、旅行者に対して、主に、場所や観光スポットを紹介するものである。実施例３では、これらの場所や観光スポットおよび移動手段（旅行地内の移動手段や、旅行者の居住地から旅行先までの移動手段）を含めた旅行パッケージプランを提供する。例えば、ユーザの旅行地が京都であり、出発地が東京である場合は、東京から京都までの移動手段（新幹線など）を、出発時間、移動時間、滞在時間などを考慮して決定してもよい。

図９は、本発明の一実施例によるオンラインチェックインの手順をフローチャートで示す。

Ｓ９０１０では、ユーザが、ユーザ自身の端末（スマートフォンなど）を使用して、ＯＴＡ（オンライン旅行代理店）などの所定のウェブサイトにインターネット経由でアクセスし、所望の宿泊先を予約する。

Ｓ９０２０では、予約内容に基づいて、宿泊予約接客システム（図４参照）を使用して、宿泊予約をしたユーザを検索し、特定する。ユーザを特定するための情報とは、例えば、氏名（漢字および／又はカタカナ）、電話番号、性別などから選ばれたひとつ又は複数のものであり、このユーザを特定するための情報が一致することが、ユーザを特定したことになる。ユーザが特定されると、例えば、当該特定されたユーザの宿泊情報が、宿泊記録手段３２１０から取得できるようになる。

Ｓ９０３０では、Ｓ９０２０で検索されたユーザの登録個人情報や宿泊情報を検索して、宿泊先に通知する。ここで、登録個人情報とは、例えば、宿泊者の氏名、年齢、住所などである。宿泊者の宿泊情報とは、例えば、過去の宿泊履歴に基づくリピート率（同一ホテルまたは同一チェーン店のホテルに宿泊した回数／宿泊回数）、キャンセル率（宿泊予約後に宿泊前日までにキャンセル手続をした割合：キャンセル回数／予約回数）、ＮＯＳＨＯＷ率（連絡なしで無断キャンセルされた割合：無断キャンセル回数／予約回数）などである。また、ユーザの嗜好に関する情報が登録されている場合には、当該情報を宿泊先に通知してもよい。なお、オプションの処理として、例えば、ＮＯＳＨＯＷ率が高いユーザが予約をしてきた場合には、所定の警告を宿泊先に連絡するようにするなど、宿泊情報に基づく警告などができるように構成されてもよい。宿泊施設は、このような情報を基に、どの程度オーバーブッキング（Ｏｖｅｒ Ｂｏｏｋｉｎｇ）をするかを決定することができる。

Ｓ９０４０では、ユーザ（宿泊者）が宿泊当日に、宿泊先でユーザ認証をする。このときに、ユーザは、ユーザ自身の端末（スマートフォンなど）で識別コード（例えば、ＱＲコード（登録商標））を表示させて、宿泊先に設置されている読み取り器（スマートフォンなど携帯電話端末を含む）に読み取らせることにより、ユーザ（宿泊者）および宿泊内容が判別できるようになる。これにより、ユーザは、宿泊先で、筆記用具を使って、備え付けの用紙に、ユーザ自身の名前や住所を書く手間が省けるようになる。
別の実施例として、ユーザがスマートフォンから送信した情報が宿泊施設の管理画面（ＰＣ）上に表示される。ユーザが到着時に口頭で、名前もしくはチェックインＩＤをスタッフに伝える事で、管理画面上から判別してもよい。

Ｓ９０５０では、宿泊施設は、判別されたユーザの登録情報（氏名など）と宿泊内容（朝食の有無や泊数などの宿泊プラン）とを確認し、確認した内容に問題がなければチェックインが完了になる。

Ｓ９０６０では、チェックインをしたという情報をフィードバックして、データベース（例えば、宿泊記録手段３２１０など）を更新する。これにより、例えば、ユーザの宿泊履歴、キャンセル率、ＮＯＳＨＯＷ率などの各値を更新できる。

図１０は、本発明の一実施例による観光スポット提案システム６０００のブロック図を示す。本実施例の観光スポット提案システム６０００は、観光スポット側システム７０００（飲食店や美術館など）およびユーザが使用する情報端末手段１４２０と相互にデータ通信できるように構成されている。

観光スポット提案システム６０００は、行動データ解析手段６１１０と、Ｃｈａｔ手段６１２０と、自動接客手段６１３０と、識別コード解析手段６１４０と、ユーザ情報管理手段６１５０と、外部環境情報取得手段６１６０と、観光スポット記録手段６２１０と、自動接客記録手段６２２０と、旅行付帯記録手段６２３０と、ユーザ登録情報記録手段６２４０と、相関記録手段６２５０と、制御手段６３１０と、ユーザ通信手段６３２０と、観光スポット側システム通信手段６３３０とを備える。

行動データ解析手段６１１０は、ユーザの旅行中の行動を取得して、その行動の特徴を解析する。

Ｃｈａｔ手段６１２０は、チャット等の対話形式の手段を使ってユーザ端末と通信をして、ユーザに対して情報を送信したり、ユーザ端末から受信したデータをシステム内の必要な情報を受信したりする。

自動接客手段６１３０は、ユーザを接客するための情報を処理する。

識別コード解析手段６１４０は、識別コードを解析して、ユーザの行動の情報を取得する。

ユーザ情報管理手段６１５０は、ユーザの情報を管理する。例えば、ユーザの生年月日が登録されている場合は、現在の日時を基にユーザの年齢を計算する。

外部環境情報取得手段６１６０は、天気予報や気温などの情報を取得する。

観光スポット記録手段６２１０は、おすすめの観光スポットなどを記憶する。

自動接客記録手段６２２０は、宿泊施設での接客を行うために、Ｃｈａｔ手段等を介して、ユーザの希望を問いあわせる。

旅行付帯記録手段６２３０は、旅行に付帯する様々な提案をする。

ユーザ登録情報記録手段６２４０は、ユーザ自身の情報を記録する。ユーザ自身の情報とは、例えば、ユーザ名（ニックネーム）、パスワード、氏名（漢字および／またはカナ表記）、生年月日（年齢は自動計算）、住所、連絡先（携帯電話番号やｅｍａｉｌ）などである。なお、上記の情報の中で、必須登録情報と任意登録情報とを事前に設定してもよい。例えば、氏名と生年月日と連絡先は登録が必須であるが、それ以外は任意で登録できるように設定してもよい。

相関記録手段６２５０は、ある観光スポット訪れた人が、比較的多く訪れる観光スポット（候補地）を記憶する。

制御手段６３１０は、システム内部の各手段を制御する。

ユーザ通信手段６３２０は、外部のシステム等とデータを送受信する。

観光スポット側システム通信手段６３３０は、観光スポット側システムとの間でデータを送受信する。

観光スポット側システム７０００は、情報管理手段７０１０と識別コード読込手段７０２０とを備える。情報管理手段７０１０は、識別コード読込手段７０２０から取得した情報を観光スポット提案システム６０００に送信したり、または、必要な情報を受信したりする。

識別コード読込手段７０２０は、情報端末手段１４２０の表示画面上に表示される識別コード（例えば、ＱＲコード（登録商標））や印刷された識別コードを読み取り、読み取った情報（ユーザを識別する情報など）を情報管理手段７０１０に送信する。

図１１は、本発明の一実施例による滞在中のプランを提案する手順をフローチャートで示す。

ユーザが、実際に旅行の目的地に滞在しているとき、天気が急変したりする等の事情により、当初想定していた観光地等への訪問が難しくなることがある。また、ユーザが旅行計画当初では把握していなかったが、スポンサー企業等からの新たな紹介やユーザの趣向等を考慮することにより、地域のスポット的なイベント（地域のお祭り等）や、観光地から観光地への移動の間に立ち寄れるような小さなおすすめスポット（綺麗な景色が見られる場所等）など、新たにおすすめできる観光スポットが生じている場合もある。このような場合において、本実施例は適用した端末を宿泊施設内に設置することが可能である。

Ｓ６０１０では、ユーザの滞在当日に、その日の天気（予報を含む）や気温などの外部環境と、ユーザの属性（国籍、年齢など）、ユーザの趣向（例えば、地域の神社仏閣等を巡る傾向がある等）に関するデータとから、ユーザ滞在当日のおすすめスポット（観光地や、飲食店など）を検索する。例えば、ユーザの滞在当日に、天気が急変して午後から雨になるという予報を情報受信手段が取得したとする。この場合、本システムが、ユーザの趣向を考慮して、雨が降っても楽しめる観光スポットやイベントを検索して、その結果を情報受信手段を介してユーザに提示する。

Ｓ６０２０では、ユーザの属性や趣向等に基づき、スポット紹介の優先順位を決定する。

例えば、飲食店をおすすめとして紹介する場合には、ユーザの属性データ中に、ユーザ自身の食物アレルギーなどの情報が含まれている場合には、食物アレルギーが避けられそうな飲食店を優先的に紹介する。該当する飲食店が提供するメニューの中にはアレルギーとなる食物が含まれている旨もお知らせする。

さらに、観光スポットをおすすめとして紹介する場合には、ユーザの属性データ中に、年齢（世代）、障害等の健康に関する情報が含まれている場合には、バリアフリー等に配慮されている観光スポットを優先的に紹介する。該当する観光スポットにおけるバリアフリーの情報もお知らせする。

Ｓ６０３０では、おすすめスポットの紹介に加えて、そのスポットに関するクーポン（例えば、博物館や飲食店における割引券）も検索して紹介する。

Ｓ６０４０では、ユーザは、紹介されたクーポンを印刷端末から印刷することにより、またはＱＲコード（登録商標）等を介してクーポンのデータを情報受信手段１４２０などに読み込むことにより、クーポンを取得することができる。このクーポンには、紹介されたスポットの情報と共に、一意の識別符号が付されている。この一意の識別符号には、ユーザを特定するための情報が付されている。

Ｓ６０５０では、クーポンを受け取ったユーザが、当該クーポンを観光スポットで使用することで、すなわち、観光スポット先の読み取り端末でクーポンの識別符号を読み取ることで、実際にユーザがクーポンを使用したという情報が取得できる。別の実施例として、観光スポット先の読み取り端末ではなく、ユーザーの端末上での処理でもよい。

また、クーポンを受け取った飲食店では、ユーザの食物アレルギーに関する情報も取得することができるので、予め食物アレルギーを避けた料理を提供することもできるし、注文を受ける際には、食物アレルギーに関する注意喚起をすることができるようになる。

さらに、クーポンを受け取った観光スポットでは、健康に関する情報も取得することができるので、バリアフリーに関する情報を現場でもあらためてお知らせすることができる。

なお、ユーザが複数のスポットを選択（クーポンを取得）した場合には、複数のスポットの所在地に基づいて、おすすめの優先順位や最短経路やユーザのクーポン取得順序などのひとつまたは複数の観点から、ユーザが訪問できる周回経路を提案してもよい。

Ｓ６０６０では、ユーザがクーポンを使用した情報が記録されると、ユーザ個別の趣向を記録したデータベースが更新される。その後は、更新されたデータベースに基づいて、ユーザに対して、おすすめの観光スポットを紹介することができるようになる。

図１２は、本発明の一実施例による旅行業務管理システム８０００の概念図を示す。
本実施例の旅行業務管理システムは、ユーザ端末８１００と、管理サーバ８２００と、宿泊施設側端末８３００と、宿泊予約装置８４００と、ネットワーク８５００とから構成される。
ユーザ端末８１００は、ユーザが旅行や宿泊を予約するための装置である。
管理サーバ８２００は、ユーザ識別子およびユーザ側ステータスを管理すると共に、宿泊施設識別子および宿泊施設側ステータスを管理している。更に、情報配信の履歴を格納する配信履歴データベース（図示せず）を備えてもよい。
宿泊施設側端末８３００は、ユーザ（旅行者）が、宿泊施設に宿泊するときに、いわゆるチェックインに関する処理や、宿泊料金の支払い（決済）に関する処理を操作できるように構成されている。
宿泊予約装置８４００は、ユーザ端末から選択された宿泊情報を管理している。宿泊情報は、ユーザ識別子、宿泊施設識別子および宿泊日が関連付けられて管理されている。
ネットワーク８５００は、ユーザ端末８１００と、管理サーバ８２００と、宿泊施設側端末８３００と、宿泊予約装置８４００と、有線または無線で、電気的、磁気的、および／または光学的に相互に接続することによって、互いにデータを送受信ができるように構成されている。
なお、ユーザ識別子は、ユーザの属性（国籍、年齢、性別など）に関する情報を含み、宿泊施設識別子は、宿泊施設の属性（名称、宿泊場所の緯度経度情報など）に関する情報を含んでもよい。

図１３は、本発明の一実施例による旅行業務を管理する手順をフローチャートで示す。
Ｓ９０１０において、ユーザ端末８１００は、管理サーバ８２００が付与したユーザ識別子を使用して（必要であれば、パスワードも使用して）、宿泊予約装置８４００が提供している宿泊予約サービスにログインして、宿泊施設および宿泊日を選択する。このときに、図１５に示すように、ユーザ側ステータスを「予約」（予約手続きを行ったことを意味する）にする。管理サーバ８２００は、ユーザ側ステータスが「予約」状態にあるときに、予約された情報が正しければ、宿泊施設側ステータスを「予約受付」（予約受付完了を意味する）にする。更に、管理サーバ８２００は、ユーザ端末８１００に対して、予約受付完了通知を送信する。ここで、各宿泊施設には、個別の宿泊施設識別子が割り当てられている。例えば、チェーン展開をしている宿泊施設の場合には、各営業拠点に、個別の宿泊施設識別子を割り当ててもよい。
Ｓ９０２０において、宿泊予約装置８４００は、管理サーバ８２００から取得したユーザ識別子と、ユーザ端末８１００が選択した宿泊施設識別子および宿泊日とを関連付けて、管理サーバ８２００に送信する。このときに、図１５の配信履歴データベースのデータ構造に示すようなデータ構造を用いて、識別子の組み合わせをキーとして、互いに関連付けられたステータスや情報を記憶してもよい。
Ｓ９０３０において、管理サーバ８２００は、ユーザ識別子と、宿泊施設識別子と、宿泊日と、情報配信の履歴と、に基づいて、次のユーザ側ステータスおよび宿泊施設側ステータスを決定する。例えば、ユーザ側ステータスが予約であり、宿泊施設側ステータスが予約受付であり、配信された情報が、予約完了通知の場合には、次のユーザ側ステータスは、チェックイン（チェックインをする）であり、次の宿泊施設側ステータスは（チェックインを待つ）である。次のステータスの決定方法については後述する。
Ｓ９０４０において、Ｓ９０３０において決定されたユーザ側ステータスと宿泊施設側ステータスとの組み合わせに基づく情報を、情報配信データベースから取得して、ユーザ端末８１００に配信する。例えば、ユーザ側ステータスがチェックイン（チェックインをする）であり、宿泊施設側ステータスが（チェックインを待つ）である場合には、チェックインをするための情報（本実施例では、チェックイン用コード）を、管理サーバ８２００がユーザ端末８１００に送信する。 Ｓ９０５０において、ユーザ識別子と宿泊施設識別子の組み合わせをキーとして、Ｓ９０３０において決定されたユーザ側ステータスと宿泊施設側ステータスとの組み合わせと、ユーザ端末に配信された情報とを関連付けて、時系列で配信履歴データベースに記憶する。例えば、図１５の配信履歴データベースのデータ構造に示すように、ユーザ識別子（例：ＡＢＣ０１２３４）と宿泊施設識別子（例：ＸＹＺ９８７６）をキーとして、ユーザ側ステータス（例：チェックイン）および宿泊施設側ステータス（例：チェックイン）を関連付けて記憶する。ここで、オプションの処理として、日時（例：２０２０年４月２日１８時）も関連付けて記憶させてもよい。
この後は、必要に応じて、Ｓ９０３０からＳ９０５０の処理を繰り返してもよい。例えば、ルームキー用コードの情報が配信された後には、ユーザ側ステータスがチェックインであるが、チェックイン手続きが済んでいるので、宿泊施設側で決済が済めば、宿泊施設側ステータスが決済（済み）となり、ルームキー用コードを、管理サーバ８２００がユーザ端末８１００に配信する。ユーザ側ステータスと宿泊施設側ステータスの一例は、図１４に示すが、配信したい情報の内容にあわせて、ステータスの組み合わせを任意に設定できるように、任意のデータベース（図示せず）に、その組み合わせを記憶させてもよい。これにより、ユーザに対して、配信したい情報を、きめ細かく設定することが可能となる。ユーザごとに配信したい情報を設定することもできる。

管理サーバは、前記ユーザ識別子に関する宿泊情報を格納する宿泊情報データベース（図示せず）を備えてもよい。

以下、チェックインの処理について説明する。
管理サーバは、宿泊施設側端末に対して、ユーザ識別子に関する個人情報を提供するとともに、過去の宿泊履歴に基づく宿泊情報を提供する。
ここで、ユーザ端末に配信される情報は、ユーザが宿泊する宿泊施設へのチェックインを促すための識別コードであり、識別コードの一例は、ＱＲコード（登録商標）のような二次元コードでもよい。
前記ユーザ端末上で前記ユーザ識別子に基づいてチェックインをすると、前記宿泊施設側装置と前記宿泊予約サービス装置の双方で前記ユーザ識別子を照合処理することにより、照合結果が一致の場合には、チェックイン完了とする。
更に具体的には、前記照合処理において、前記ユーザ端末に記憶されているユーザ識別子と、宿泊施設識別子と、時間情報とを、前記宿泊予約システムおよび前記宿泊施設の端末に記憶されているユーザ識別子と、宿泊施設識別子とが一致しているときに、前記ステータスがチェックイン完了としてもよい。

以下、チェックイン後の処理について説明する。
前記決定されたユーザ側ステータスが、チェックイン完了の場合には、
前記ユーザ識別子と前記宿泊施設識別子とに基づいて、ユーザ専用のルームキーに相当するコードを前記ユーザ端末に配信する。

以下、チェックイン後に、ユーザ（旅行者または宿泊者）が、配信されたルームキーを使って宿泊する部屋の鍵を解除したときなどをトリガーとして、宿泊施設に関する情報や観光情報をユーザ端末に配信してもよい。具体的には、以下である。
ルームキーに相当するコードの利用状況に基づき、ユーザ側ステータスを決定し、
ユーザ側ステータスが宿泊施設に滞在中であることを示す場合には、サーバは、宿泊施設に関する情報および観光情報を前記ユーザ端末に配信する。

以下、チェックイン後に、ユーザが部屋から出たことが検知できた場合には、ユーザは観光に出かけたと判断してもよい。具体的には、以下である。
ルームキーに相当するコードの利用状況に基づき、ユーザ側ステータスを決定し、
ユーザ側ステータスが観光中であることを示す場合には、サーバは、観光情報をユーザ端末に配信し、
前記配信される観光情報は、前記データベースに記憶された情報、旅行の目的の少なくとも１つに基づいて決定されてもよい。

チェックアウト後の処理の一例は、以下である。
チェックアウトをすると、ユーザ側ステータスがチェックアウトになり、その後、宿泊施設側ステータスがチェックアウトになると、ユーザ側ステータスがアイドルになる。

図１４は、本発明の一実施例による旅行業務を管理するためのステータスを示す。
ユーザのステータスの推移の一例は、予約、チェックイン前、チェックイン完了、滞在、観光、チェックアウトなどである。
宿泊施設のステータスの推移の一例は、予約受付、チェックイン（宿泊日前のチェックインまたは宿泊日当日のチェックイン）、決済、宿泊施設案内、観光案内などである。
本実施例のシステムは、ユーザ側ステータスと宿泊施設側ステータスとが推移する中で、その組み合わせに基づいて、実施する情報処理（例えば、ユーザ端末に配信する情報の種類）を決定するように構成されている。
（次の）ユーザ側ステータスや宿泊施設側ステータスの判定にあたっては、所定の条件を満たすか否かに基づいてもよく、何らかのトリガに基づいてもよいが、予め任意のデータベース（図示せず）に記憶された判定条件に基づく。例えば、複数日にわたって宿泊施設に滞在する場合には、滞在と観光のユーザ側ステータスは交互に入れ替わる可能性が高い。その場合には、例えば、ルームキーを使って宿泊する部屋に入室したと判定できた場合には、ユーザ側ステータスは、滞在になる。また、図示してはいないが、ユーザ側ステータスが滞在中であって、かつ所定の時間帯（例えば、夜間）において、部屋の照明が消灯された場合には、ユーザ側ステータスは、睡眠中であると判定して、情報の配信がとまるように構成されてもよい。

図１５は、本発明の一実施例による旅行業務を管理するための配信履歴データベースのデータ構造を示す。
ユーザ識別子と宿泊施設識別子との組み合わせをキーとすることにより、例えば、同一ユーザが、所定の期間内に複数の宿泊施設に滞在しても、宿泊施設ごとに適切に管理することができる。

なお、各実施例で示したブロック図等で示したハードウェア資源の構成は、一例にすぎず、例えば、いわゆるコンピュータの五大装置（制御装置、演算装置、入力装置、出力装置、記憶装置）で実現してもよい。

なお、各実施例で個別の事例について説明したが、任意の実施例を組み合わせても本発明を実施することも可能である。

以上のように本発明の実施態様について説明したが、上述の説明に基づいて当業者にとって種々の代替例、修正又は変形が可能であり、本発明はその趣旨を逸脱しない範囲で前述の種々の代替例、修正又は変形を包含するものである。

以上のように説明した本発明の実施態様から、以下のような発明の態様が提供できる。

（１）過去にユーザが訪れた旅行地および当該旅行地内の観光スポットをデータベースから取得する手段と、
旅行中のユーザの身体データを測定して、観光スポットの位置情報と関連付けて、記憶する手段と、
旅行中のユーザの位置情報データを測定して、測定された位置情報データに相当する観光スポットにおける滞在時間を記憶する手段と、
ユーザが訪れた旅行地内の観光スポットと相関度の高い観光スポットがある旅行地の候補をデータベースから複数選択する手段と、
観光スポットにおけるユーザの滞在時間やユーザの身体データに基づいて、ユーザが訪れた観光スポットと相関性の高い観光スポットがある旅行地を候補の中から推定する手段と、
を備えたことを特徴とするシステムを提供する。

（２）更に、データベースに記録された複数のユーザについて、当該ユーザが訪れた複数の旅行地または複数の観光スポットの関係を所定の統計処理または機械学習をして、ある観光スポットと別の観光スポットとの相関関係を相関値として計算して記録する手段を備えたことを特徴とする（１）のシステムを提供する。

（３）更に、ユーザに提案した旅行地に対して、ユーザが当該提案を受け入れたか否かに基づいて、相関関係を修正して、ユーザ毎に相関値を修正する手段を備えたことを特徴とする（１）のシステムを提供する。

（４）更に、観光スポットに関係するイベントや施設を提案する手段を備えたことを特徴とする（１）のシステムを提供する。

（５）更に、相関度の高い旅行地に関係するイベントを選択して、当該イベントの開催日時より所定期間前にユーザに当該イベントの情報を連絡する手段を備えたことを特徴とする（１）のシステムを提供する。

（６）更に、選択された旅行地から、ユーザの嗜好に基づいて、旅行プランを生成してユーザに提案する手段を備えたことを特徴とする（１）のシステムを提供する。

（７）旅行業務を管理するための情報処理システムにおいて、
管理サーバと、
宿泊情報を管理する宿泊予約装置と、
宿泊施設側装置と、
ユーザ端末とが、それぞれネットワークを介して接続されており、
前記管理サーバは、
ユーザ識別子およびユーザ側ステータスを管理する手段と、
宿泊施設識別子および宿泊施設側ステータスを管理する手段と、
情報配信の履歴を格納する配信履歴データベースと、
を備え、
前記ユーザ端末は、前記管理サーバが付与したユーザ識別子を使用して、宿泊予約装置にログインして、宿泊施設識別子および宿泊日を選択できるように構成されており、
前記宿泊予約装置は、前記管理サーバから取得したユーザ識別子と、ユーザ端末が選択した宿泊施設識別子および宿泊日とを関連付けて、前記管理サーバに送信し、
前記管理サーバは、さらに、
前記ユーザ識別子と、前記宿泊施設識別子と、前記宿泊日と、前記情報配信の履歴と、に基づいて、ユーザ側ステータスおよび宿泊施設側ステータスを決定する手段と、
当該決定されたユーザ側ステータスと前記宿泊施設側ステータスとの組み合わせに基づく情報を、情報配信データベースから取得して、前記ユーザ端末に配信する手段と、
前記ユーザ識別子との前記宿泊施設識別子の組み合わせをキーとして、当該決定されたユーザ側ステータスと前記宿泊施設側ステータスとの組み合わせと、前記配信された情報とを関連付けて、時系列で前記配信履歴データベースに記憶する手段と、
を備える、ことを特徴とするシステムを提供する。

（８）前記管理サーバは、さらに、前記ユーザ識別子に関する宿泊情報を格納する宿泊情報データベースを備え、
前記管理サーバは、宿泊施設側端末に対して、前記ユーザ識別子に関する個人情報を提供するとともに、過去の宿泊履歴に基づく宿泊情報を提供し、
前記ユーザ端末に配信される情報は、ユーザが宿泊する宿泊施設へのチェックインを促すための識別コードであり、
前記ユーザ端末上で前記ユーザ識別子に基づいてチェックインをすると、前記宿泊施設側装置と前記宿泊予約サービス装置の双方で前記ユーザ識別子を照合処理することにより、チェックイン完了となり、
ここで、前記照合処理において、前記ユーザ端末に記憶されているユーザ識別子と、宿泊施設識別子と、時間情報とを、前記宿泊予約システムおよび前記宿泊施設の端末に記憶されているユーザ識別子と、宿泊施設識別子とが一致しているときに、前記ステータスがチェックイン完了となることを特徴とする（７）のシステムを提供する。

（９）前記決定されたユーザ側ステータスが、チェックイン完了の場合には、
前記ユーザ識別子と前記宿泊施設識別子とに基づいて、ユーザ専用のルームキーに相当するコードを前記ユーザ端末に配信することを特徴とする（８）のシステムを提供する。

（１０）前記ルームキーに相当するコードの利用状況に基づき、ユーザ側ステータスを決定し、
前記ユーザ側ステータスが宿泊施設に滞在中であることを示す場合には、前記サーバは、宿泊施設に関する情報および観光情報を前記ユーザ端末に配信することを特徴とする（９）のシステムを提供する。

（１１）更に、前記ルームキーに相当するコードの利用状況に基づき、ユーザ側ステータスを決定し、
前記ユーザ側ステータスが観光中であることを示す場合には、前記サーバは、観光情報を前記ユーザ端末に配信し、
前記配信される観光情報は、前記データベースに記憶された情報、旅行の目的の少なくとも１つに基づいて決定されることを特徴とする（１０）のシステムを提供する。

（１２）チェックアウトをすると、前記ユーザ側ステータスがチェックアウトになり、その後、宿泊施設側ステータスがチェックアウトになると、前記ユーザ側ステータスがアイドルになることを特徴とする（１１）のシステムを提供する。

（１３）前記ユーザ識別子は、旅行者の属性に関する情報を含み、
前記宿泊施設識別子は、宿泊施設の属性に関する情報を含むことを特徴とする（７）のシステムを提供する。

１０００ 旅行地提案システム
１１１０ 行動データ解析手段
１１２０ 次旅行提案手段
１１３０ ユーザ嗜好分析手段
１１４０ 情報配信管理手段
１２１０ 旅行記録手段
１２２０ ユーザ行動データ記録手段
１２３０ ユーザ属性記録手段
１２４０ 相関記録手段
１２５０ 情報記録手段
１３１０ 制御手段
１３２０ ユーザ通信手段
１４１０ ユーザ行動取得・送信手段
１４２０ 情報受信手段
３０００ 宿泊予約接客システム
３１１０ 宿泊候補受付手段
３１２０ Ｃｈａｔ手段
３１３０ 自動接客手段
３１４０ 旅行付帯提案手段
３２１０ 宿泊記録手段
３２２０ 自動接客記録手段
３２３０ 旅行付帯記録手段
３３１０ 制御手段
３３２０ ユーザ通信手段
３３３０ 宿泊施設通信手段
４０００ 宿泊施設
４０１０ 宿泊施設管理手段
５０００ 旅程提案システム

Claims (7)

1. 旅行業務を管理するための情報処理システム（図１２）において、
   管理サーバ（８２００）と、
   宿泊情報を管理する宿泊予約装置（８４００）と、
   宿泊施設側装置（８３００）と、
   ユーザ端末（８１００）とが、それぞれネットワーク（８５００）を介して接続されており、
   前記管理サーバ（８２００）は、
   ユーザ識別子およびユーザ側ステータスを管理する手段（図１４）と、
   宿泊施設識別子および宿泊施設側ステータスを管理する手段（図１４）と、
   情報配信の履歴を格納する配信履歴データベース（図１５）と、
   を備え、
   前記ユーザ端末（８１００）は、前記管理サーバが付与したユーザ識別子を使用して、宿泊予約装置にログインして、宿泊施設識別子および宿泊日を選択できるように構成されており（図１３：Ｓ９０１０）、
   前記宿泊予約装置（８４００）は、前記管理サーバから取得したユーザ識別子と、ユーザ端末が選択した宿泊施設識別子および宿泊日とを関連付けて、前記管理サーバに送信し（Ｓ９０２０）、
   前記管理サーバ（８２００）は、さらに、
   前記ユーザ識別子と、前記宿泊施設識別子と、前記宿泊日と、前記情報配信の履歴と、に基づいて、ユーザ側ステータスおよび宿泊施設側ステータスを決定する手段（Ｓ９０３０）と、
   当該決定されたユーザ側ステータスと前記宿泊施設側ステータスとの組み合わせに基づく情報を、情報配信データベースから取得して、前記ユーザ端末に配信する手段（Ｓ９０４０）と、
   前記ユーザ識別子との前記宿泊施設識別子の組み合わせをキーとして、当該決定されたユーザ側ステータスと前記宿泊施設側ステータスとの組み合わせと、前記配信された情報とを関連付けて、時系列で前記配信履歴データベースに記憶する手段（Ｓ９０５０）と、
   を備える、ことを特徴とするシステム。
2. 前記管理サーバは、さらに、前記ユーザ識別子に関する宿泊情報を格納する宿泊情報データベースを備え、
   前記管理サーバは、宿泊施設側端末に対して、前記ユーザ識別子に関する個人情報を提供するとともに、過去の宿泊履歴に基づく宿泊情報を提供し、
   前記ユーザ端末に配信される情報は、ユーザが宿泊する宿泊施設へのチェックインを促すための識別コードであり、
   前記ユーザ端末上で前記ユーザ識別子に基づいてチェックインをすると、前記宿泊施設側装置と前記宿泊予約サービス装置の双方で前記ユーザ識別子を照合処理することにより、チェックイン完了となり、
   ここで、前記照合処理において、前記ユーザ端末に記憶されているユーザ識別子と、宿泊施設識別子と、時間情報とを、前記宿泊予約システムおよび前記宿泊施設の端末に記憶されているユーザ識別子と、宿泊施設識別子とが一致しているときに、前記ステータスがチェックイン完了となることを特徴とする請求項１に記載のシステム。
3. 前記決定されたユーザ側ステータスが、チェックイン完了の場合には、
   前記ユーザ識別子と前記宿泊施設識別子とに基づいて、ユーザ専用のルームキーに相当するコードを前記ユーザ端末に配信することを特徴とする、請求項２に記載のシステム。
4. 前記ルームキーに相当するコードの利用状況に基づき、ユーザ側ステータスを決定し、
   前記ユーザ側ステータスが宿泊施設に滞在中であることを示す場合には、前記サーバは、宿泊施設に関する情報および観光情報を前記ユーザ端末に配信することを特徴とする、請求項３に記載のシステム。
5. 更に、前記ルームキーに相当するコードの利用状況に基づき、ユーザ側ステータスを決定し、
   前記ユーザ側ステータスが観光中であることを示す場合には、前記サーバは、観光情報を前記ユーザ端末に配信し、
   前記配信される観光情報は、前記データベースに記憶された情報、旅行の目的の少なくとも１つに基づいて決定されることを特徴とする請求項４に記載のシステム。
6. チェックアウトをすると、前記ユーザ側ステータスがチェックアウトになり、その後、宿泊施設側ステータスがチェックアウトになると、前記ユーザ側ステータスがアイドルになることを特徴とする、請求項５に記載のシステム。
7. 前記ユーザ識別子は、旅行者の属性に関する情報を含み、
   前記宿泊施設識別子は、宿泊施設の属性に関する情報を含むことを特徴とする請求項１に記載のシステム。