JP7387300B2 - 移動プラン提案装置 - Google Patents

Description

本発明は、目的地までの経路を案内・提案するための技術、に関する。

旅行には、事前に旅程を計画する楽しみもあれば、旅先でおもしろそうな観光サービスや特典のある観光サービスを見つけたために旅程を臨機応変に変更する楽しみもある。一方、観光業者（地域サービス業者）は、過去の経験から繁忙期と閑散期を把握していることが多い。観光業者にとって、閑散期に観光客をいかに呼び込めるかは重要な経営課題である。

特開２０１９－８６９６号公報

閑散期であれば割引サービスなどの特典を提供してもよいと考えている観光業者もいる。たとえば、温泉業者が「平日の１２：００～１３：００」に利用料金（入湯料）を割引した場合、この時間帯に温泉近くにいる観光客はせっかくなので温泉にいってみようと思うかもしれない。

また、タクシーや電車、人力車などの運輸業者（運輸サービス業者）にも繁忙期と閑散期がある。運輸業者も、観光業者と同様、閑散期であれば割引サービスなどの特典を提供してもよいと考えていることがある。本発明者らは、観光業者が提供する割引サービスなどの特典と運輸業者が提供する割引サービスなどの特典を観光客にまとめて提供できれば、観光客をいっそう強力に誘引できるのではないかと考えた。

本発明は、上記認識に基づいて完成された発明であり、その主たる目的は、地域に関わるサービスと運輸に関わるサービスそれぞれが提供する特典を組み合わせた移動プランを提案する技術、を提供することにある。

本発明のある態様における移動プラン提案装置は、地域サービスを提供する複数の地域サービス業者それぞれから、地域サービス特典の取得条件を含む地域サービスプランの登録を受け付ける地域サービス登録部と、運輸サービスを提供する複数の運輸サービス業者それぞれから、運輸サービス特典の取得条件を含む運輸サービスプランの登録を受け付ける運輸サービス登録部と、ユーザから、推奨プランの提案要求を受信する提案要求受信部と、提案要求が受信されたとき、複数種類の地域サービスプランおよび複数種類の運輸サービスプランのうち、地域サービス特典の取得条件および運輸サービス特典の取得条件の双方が成立可能な地域サービスプランと運輸サービスプランの組み合わせを推奨プランとして特定する推奨プラン特定部と、推奨プランをユーザに提示する推奨プラン提示部と、を備える。

本発明によれば、複数の事業者とユーザそれぞれに有利な移動プランを提供しやすくなる。

移動プラン提案装置により提供される旅程提案サービスを説明するための概要図である。 移動プラン提案装置の機能ブロック図である。 地域サービスプラン格納部のデータ構造図である。 運輸サービスプラン格納部のデータ構造図である。 利用情報格納部のデータ構造図である。 プラン検索画面の画面図である。 推奨プランの提案過程を示すシーケンス図である。 タクシーの利用状況を示すグラフである。

図１は、移動プラン提案装置１００により提供される旅程提案サービスを説明するための概要図である。
本実施形態における旅程提案サービスにおいては、ユーザ（観光客）に対してメリットのある旅行プランを随時提案する。ここでいう旅行プランは、観光地で提供される観光サービス（地域サービス）と観光地に行くための運輸サービスの組み合わせとして定義される。

図１において、ユーザＸ１は地点Ｐ０に１０：３０に到着したとする。地点Ｐ０は、鉄道駅などが想定される。ユーザＸ１は、地点Ｐ０の近くの観光地をめぐりたいと考えている。地点Ｐ１、Ｐ２はいずれも地点Ｐ０に近い観光地である。地点Ｐ１、Ｐ２としては、海岸や遺跡、公園、神社、寺などが想定される。

地点Ｐ１の近辺では観光サービスＳ１、Ｓ２が提供されている。また、地点Ｐ２では観光サービスＳ３が提供されている。観光サービスとしては、温泉、レストラン、美術館、遊覧船、劇場などが想定される。

観光サービスを提供する観光業者（地域サービス業者）は、観光客にさまざまな特典を提供する。特典としては、利用料金の割引、ドリンク・サービス、クーポン券、ゲストによるトークショー、などが考えられる。図１においては、観光サービスＳ１を「１１：００～１２：００」に利用すれば、ユーザＸ１に特典が提供される（以下、特典が提供される時間帯のことを「特典時間帯」とよぶ）。一方、観光サービスＳ２には特典は設定されていない。観光サービスＳ３には「１４：００～１６：００」が特典時間帯として設定されている。観光業者は、閑散期に特典時間帯を設定することで観光客を誘引する。

ユーザＸ１が、地点Ｐ０から地点Ｐ１に向かうには運輸サービスＭ１、Ｍ２のいずれかを利用する。運輸サービスとしては、タクシー、人力車、バス、レンタカー、電車などが考えられる。本実施形態における旅程提案サービスにおいては、観光業者だけでなく、運輸サービスを提供する運輸業者（運輸サービス業者）もさまざまな特典を提供できる。観光業者の特典と同様、運輸業者が提供する特典も任意である。
以下においては、観光業者の提供する特典を「観光特典（地域サービス特典）」、運輸業者の提供する特典を「運輸特典（運輸サービス特典）」、両者を特に区別しないときには単に「特典」とよぶ。

図１においては、運輸サービスＭ１については「１０：００～１１：００」が特典時間帯である。運輸サービスＭ２については「１３：００～１４：００」が特典時間帯である。また、運輸サービスＭ１による想定移動時間は１時間、運輸サービスＭ２による想定移動時間は３０分である。

ユーザＸ１は、１０：３０に運輸サービスＭ１を利用すれば、運輸サービスＭ１の運輸特典を得られる。また、運輸サービスＭ１を利用した場合、１時間後の１１：３０に地点Ｐ１に到着するため、観光サービスＳ１（特典時間帯「１１：００～１２：００」）の観光特典も得られる。一方、運輸サービスＭ２の運輸特典を受けるには１３：００まで待たなくてはならないし、その場合には観光サービスＳ１の観光特典を受けることはできない。

地点Ｐ０から地点Ｐ２に向かうには運輸サービスＭ５を利用することになる。運輸サービスＭ５の特典時間帯は「１０：００～１１：００」であるため、運輸特典を受けることはできる。しかし、運輸サービスＭ５の想定移動時間は１．５時間なので、ユーザは運輸サービスＭ５を利用した場合、地点Ｐ２に１２：００に到着することになる。地点Ｐ２の観光サービスＳ３は１４：００以降に利用しないと特典を得られないため旅の効率が悪い。
以上を総合判断すると、ユーザＸ１にとっては、運輸サービスＭ１を利用して地点Ｐ１に向かい、観光サービスＳ１を堪能することが「運輸特典と観光特典の双方を受けることができる上手な旅行プラン」となる。

地点Ｐ１に到達したユーザＸ１は、同様にして、運輸サービスＭ３を利用すれば、運輸サービスＭ３の運輸特典をもらった上に、地点Ｐ２において観光サービスＳ３の観光特典ももらうことができる。

さまざまな運輸特典と観光特典をもらうことはユーザに有利なことではあるが、ユーザに複雑な検討作業を強いることにもなりかねない。本実施形態における移動プラン提案装置１００は、このような特典を受けやすい旅行プランを「推奨プラン」として、ユーザに提案する。推奨プランを提案することにより、ユーザは多くの特典をもらいながら上手な旅行できたという満足感が得られるとともに、観光業者と運輸業者も観光客をいっそう誘引しやすくなる。

図２は、移動プラン提案装置１００の機能ブロック図である。
移動プラン提案装置１００の各構成要素は、ＣＰＵ（Central Processing Unit）および各種コプロセッサなどの演算器、メモリやストレージといった記憶装置、それらを連結する有線または無線の通信線を含むハードウェアと、記憶装置に格納され、演算器に処理命令を供給するソフトウェアによって実現される。コンピュータプログラムは、デバイスドライバ、オペレーティングシステム、それらの上位層に位置する各種アプリケーションプログラム、また、これらのプログラムに共通機能を提供するライブラリによって構成されてもよい。以下に説明する各ブロックは、ハードウェア単位の構成ではなく、機能単位のブロックを示している。

移動プラン提案装置１００は、インターネット１０２を介してユーザ端末１０４、観光端末１０６、運輸端末１０８および決済システム１１０と接続される。
ユーザ端末１０４は、ユーザ（観光客）が利用するスマートフォンやラップトップＰＣなどの通信端末である。観光端末１０６は観光業者が利用する通信端末であり、運輸端末１０８は運輸業者が利用する通信端末である。決済システム１１０は、クレジットカード会社や銀行などの金融機関が提供するシステムである。

移動プラン提案装置１００は、通信部１２０、データ処理部１２２およびデータ格納部１２４を含む。
通信部１２０は、ユーザ端末１０４等の外部装置との通信処理を担当する。データ格納部１２４は各種データを格納する。データ処理部１２２は、通信部１２０により取得されたデータおよびデータ格納部１２４に格納されているデータに基づいて各種処理を実行する。データ処理部１２２は、通信部１２０およびデータ格納部１２４のインタフェースとしても機能する。

通信部１２０は、地域サービス登録部１２６、運輸サービス登録部１２８、提案要求受信部１３０、推奨プラン提示部１３２、利用情報提示部１３４および決済通信部１４８を含む。

地域サービス登録部１２６は、観光端末１０６から「観光特典プラン（地域サービスプラン）」の登録を受け付ける。観光特典プランは、観光特典とその観光特典を取得するための条件を対応づけたものである。
運輸サービス登録部１２８は、運輸端末１０８から「運輸特典プラン（運輸サービスプラン）」の登録を受け付ける。運輸特典プランは、運輸特典とその運輸特典を取得するための条件を対応づけたものである。

提案要求受信部１３０は、ユーザ端末１０４から推奨プランの提案要求を受け付ける。推奨プラン提示部１３２は、ユーザ端末１０４に対して推奨プランを提示する。利用情報提示部１３４は、各種サービスの利用状況を示す「利用情報」を観光端末１０６と運輸端末１０８に提供する。利用情報の詳細は後述する。決済通信部１４８は、決済システム１１０との通信処理を担当する。

データ格納部１２４は、地域サービスプラン格納部１４２、運輸サービスプラン格納部１４４および利用情報格納部１４６を含む。
地域サービスプラン格納部１４２は観光特典プランを格納する。地域サービスプラン格納部１４２については図３に関連して詳述する。運輸サービスプラン格納部１４４は、運輸特典プランを格納する。運輸サービスプラン格納部１４４については図４に関連して詳述する。利用情報格納部１４６は、利用情報を格納する。

データ処理部１２２は、推奨プラン特定部１３６、決済処理部１３８およびプラン集計部１４０を含む。
推奨プラン特定部１３６は、観光特典プランおよび運輸特典プランに基づいて、後述の方法により推奨プランを生成する。決済処理部１３８は、ユーザが推奨プランを選んだときの決済処理を実行する。プラン集計部１４０は各種プランの利用状況を集計し、利用情報として利用情報格0納部１４６に登録する。

図３は、地域サービスプラン格納部１４２のデータ構造図である。
観光業者は、観光特典プランを移動プラン提案装置１００に設定する。地域サービス登録部１２６は、観光端末１０６から観光特典プランを受信し、地域サービスプラン格納部１４２に登録する。図３によれば、地点Ｐ１で「足湯サービス（観光サービス）」を提供する観光業者Ｖ１は、「平日の１５：００～１５：３０」に訪れた観光客に対して利用料金の２０％オフという観光特典を提供している。観光業者Ｖ１は、また、「雨の日」に訪れた観光客に対しては利用料金を４０％オフとしている。地点Ｐ１で史跡Ａを管理する観光業者Ｖ２は「１０月１７日の１６：００～１７：００」に「有名人Ｙが来る」という観光特典を提供する。このように観光特典プランは、集客のためのさまざまな観光特典と、観光特典の取得条件を定義する。

図４は、運輸サービスプラン格納部１４４のデータ構造図である。
運輸業者は、運輸特典プランを移動プラン提案装置１００に設定する。運輸サービス登録部１２８は、運輸端末１０８から運輸特典プランを受信し、運輸サービスプラン格納部１４４に登録する。図４によれば、運輸業者Ｔ１はタクシー会社であり、地点Ｐ０を出発点とした場合、「１６：００～１７：００」に乗車したユーザに対して運輸特典として利用料金が５％オフとなる。

運輸業者Ｔ３は、バス会社であり、地点Ｐ２を出発点とした場合、女性客に対しては利用料金が３％オフとなる。運輸業者Ｔ４（一般人）は、自家用車の運転手であり、相乗りをオファーしている。１０月１６日の「５：３０～５：４０」に地点Ｐ０に行けば、５００円で時点Ｐ１まで連れて行ってもらえる。

図５は、利用情報格納部１４６のデータ構造図である。
ユーザ（観光客）は、後述の方法により、移動プラン提案装置１００から提案される推奨プランを予約選択する。プラン集計部１４０は、ユーザによって利用された推奨プランを集計し、利用情報格納部１４６に登録する。たとえば、プランＩＤ＝Ｒ０１の推奨プラン（以下、「推奨プラン（Ｒ０１）」のように表記する）は、ユーザＸ２によって利用されている。推奨プラン（Ｒ０１）の利用に際して、ユーザＸ２は地点Ｐ０においてタクシー業者Ｔ１のタクシーに時刻１１：１３に乗車し、地点Ｐ１に１１：４５に到着し、観光業者Ｖ１の足湯サービスを堪能している。

利用情報格納部１４６のデータである利用情報は、観光端末１０６および運輸端末１０８に提供される。観光業者や運用業者は利用情報を参照することにより、どの推奨プランがどのくらい人気があるのかを知ることができる。たとえば、多くの観光客が地点Ｐ０においてタクシーを利用している場合には、人力車サービスを提供する運輸業者Ｔ２は新たな特典を設定するなどの対策をするかもしれない。このように、利用情報を参照することにより、観光業者や運輸業者は集客対策を効率的に行うことができる。このような仕組みにより、観光業者や運輸業者が移動プラン提案装置１００の提供する旅程提案サービスに参加する意欲を喚起できる。

図６は、ユーザが旅先を検討するときに表示されるプラン検索画面２０４の画面図である。
ユーザＸ１は、地点Ｐ０にいるとき、足湯に行きたいと考えたとする。ユーザＸ１がユーザ端末１０４から移動プラン提案装置１００にアクセスしたとき、移動プラン提案装置１００の通信部１２０はプラン検索画面２０４のウェブページをユーザ端末１０４に送信する。

ユーザＸ１は、ユーザ端末１０４に表示されたプラン検索画面２０４の検索入力領域２００に観光サービス「足湯」を入力して検索する。このとき、ユーザ端末１０４から「足湯」、「ユーザＸ１のＩＤ」および「ユーザＸ１の現在位置」を含む提案要求が移動プラン提案装置１００に送信される。ユーザＸ１の現在位置は、ユーザ端末１０４が有する一般的な位置検出機能により特定される。移動プラン提案装置１００は、ユーザＸ１のＩＤに対して、ユーザＸ１の属性情報、たとえば、名前、性別、利用履歴などをあらかじめ対応づけておいてもよい。

推奨プラン特定部１３６は、地点Ｐ０から所定範囲内、たとえば、３０キロメートル以内の範囲で足湯サービスを提供している観光業者を検索する。観光業者はあらかじめ移動プラン提案装置１００に観光サービスの内容と場所を登録しておいてもよいし、推奨プラン特定部１３６は一般的な地図情報を検索することで足湯サービスを提供する観光業者を特定してもよい。

地点Ｐ１において足湯サービスを検出したときには、推奨プラン特定部１３６は地点Ｐ０から地点Ｐ１までの運輸手段を検索する。運輸業者はあらかじめ移動プラン提案装置１００に対して運輸サービスを提供可能な範囲を登録しておいてもよいし、推奨プラン特定部１３６は一般的な交通情報を検索することで指定ルートにおいて運輸サービスを提供可能な運輸業者を特定してもよい。

推奨プラン特定部１３６は、次に、地域サービスプラン格納部１４２に登録されている観光特典プランと運輸サービスプラン格納部１４４に登録されている運輸特典プランを検索し、運輸サービスと観光サービス（上記例では足湯サービス）の組み合わせを総当たりで作り、正規の利用料金と享受可能な特典にともなう合計割引率を計算する。たとえば、運輸サービスＭ５と観光サービスＳ８を組み合わせるとき、推奨プラン特定部１３６は運輸サービスＭ５で運輸特典を受けられるか、観光サービスＳ８の観光特典を受けられるかを判定する。推奨プラン特定部１３６は、両方を受けられるときにはそれぞれの特典のうちの「割引率」に関わる部分を合計して合計割引率を算出する。

本実施形態においては、推奨プラン特定部１３６は運輸サービスと観光サービスの双方による合計割引率が最も大きくなる組み合わせを「（最高の）推奨プラン」として選ぶ。推奨プラン特定部１３６は合計割引率が大きくなる順に複数の推奨プランを特定し、合計割引率が大きい複数の推奨プランをユーザ端末１０４に並べて表示させる。図６によれば「足湯の里」の推奨プラン（Ｒ０１）は、タクシーを利用して地点Ｐ１に行き「足湯の里」を利用する旅行プランであり、現在地点・現在時点においてもっとも合計割引率が大きい。

プラン検索画面２０４には、足湯サービスに関わる推奨プランとして「足湯の里」と「極上湯」が提案されている。推奨プラン（Ｒ０１：足湯の里：タクシー）の正規の利用料金は２，５００円である。この料金は、観光サービス（足湯の里）の料金（５００円）と運輸サービス（タクシー）の料金（２，０００円）の合計額である。「足湯の里」を対象とした観光特典サービスとタクシーの運輸特典サービスを考慮すると、合計割引率は４０％となる。このため、合計利用料金は、１，５００円（＝２，０００×０．６）となる。なお、内訳はタクシーが４５％オフで２，０００円から１，１００円となり、「足湯の里」が２０％オフで５００円から４００円となる。すなわち、タクシーで「足湯の里」にいく推奨プラン（Ｒ０１）を利用すれば、タクシーの割引と「足湯の里」の割引をどちらも受けることができるので、観光客にとって大きな割引となる。

評点領域２０２には、「足湯の里」を利用したことのある観光客による評点が表示される。評点は５段階である。ユーザはレビューボタン２０６をタッチすることにより、観光客の「足湯の里」に対するレビュー、すなわち、利用経験者の感想を表示させることができる。なお、評点およびレビューは、「足湯の里」という観光サービスではなく、推奨プランに対して設定されてもよい。

ユーザがプラン検索画面２０４において推奨プラン（Ｒ０１：足湯の里）をタッチすると決済画面（図示せず）が表示される。ユーザは、クレジットカードなどの既存の決済方法により利用料金を支払う。決済処理部１３８は、決済通信部１４８を介して利用料金の決済処理を行う。決済完了後、決済通信部１４８はユーザ端末１０４に決済完了通知を送信する。ユーザＸ１は、地点Ｐ０にいるタクシーにこの決済完了画面を表示することで、推奨プラン（Ｒ０１）のサービスを受けることができる。

図７は、推奨プランの提案過程を示すシーケンス図である。
ユーザは、まず、「足湯」のように観光サービスを指定した提案要求を移動プラン提案装置１００に送信する（Ｓ１０）。推奨プラン特定部１３６は、指定された観光サービスを検索する（Ｓ１２）。次に、推奨プラン特定部１３６は、ユーザが現在地点から目的地に到達するために利用可能な運輸サービスを検索する（Ｓ１４）。推奨プラン特定部１３６は、観光サービスと運輸サービスそれぞれの観光特典プランと運輸特典プランを検索し、１以上の推奨プランを作成する（Ｓ１６）。推奨プラン提示部１３２は、推奨プランを示すウェブページ（プラン検索画面２０４）をインターネット１０２に送信し（Ｓ１８）、ユーザ端末１０４はプラン検索画面２０４を画面表示させる（Ｓ２０）。このあと、ユーザは、推奨プランを予約選択し、決済処理を実行する。決済金額は、決済システム１１０により、実際に推奨プランに対応した運輸業者と観光業者に配賦される。

ユーザは、「足湯」のような観光サービスを検索してもよいし、「地点Ｐ１」のように目的地を検索対象としてもよい。この場合には、推奨プラン特定部１３６は地点Ｐ１の周辺にある観光サービスを検索するとともに、地点Ｐ０から地点Ｐ１に向かうための運輸サービスを検索する。

図８は、タクシーの利用状況を示すグラフである。
プラン集計部１４０は、推奨プランの予約状況とそれに対する運輸手段の利用状況をまとめて運輸端末１０８に表示させることができる。図８は、ある日曜日に地点Ｐ０を出発した観光客数と、地点Ｐ０に到着したタクシーの台数を示す。地点Ｐ０で観光客を乗せた運輸業者は、乗車人数と出発時刻を移動プラン提案装置１００に通知する。また、タクシーは、地点Ｐ０に到着したときには、到着時刻を移動プラン提案装置１００に通知する。

時刻ｔ１～ｔ２においては、４０人の観光客が地点Ｐ０から出発しているが、この時間帯に地点Ｐ０に到着したタクシーの台数は５台しかいない。このため、時刻ｔ１～ｔ２はタクシー不足（需要過多）であることがわかる。４０人の観光客の多くはタクシーではなく、別の運輸手段を利用したと考えられる。

時刻ｔ３～ｔ４においては、５人の観光客が地点Ｐ０から出発しているが、この時間帯に地点Ｐ０に到着したタクシーの台数は２０台である。したがって、時刻ｔ３～ｔ４はタクシー過剰（供給過多）であることがわかる。

タクシー会社はこのような利用情報を得ることにより、タクシーの配車を合理的に考えることができる。上述の例の場合、タクシー会社は時刻ｔ１～ｔ２にはタクシーを地点Ｐ０に重点的に配置し、時刻ｔ３～ｔ４ではタクシーを別の地点に回すとしてもよい。あるいは、時刻ｔ３～ｔ４の閑散時間帯においては特典を設定することで観光客のタクシー需要を喚起してもよい。

以上、実施形態に基づいて移動プラン提案装置１００について説明した。
本実施形態の移動プラン提案装置１００によれば、観光業者は観光客を戦略的かつ効率的に集客できる。たとえば、地点Ｐ７は紅葉が有名なスポットであるとき、地点Ｐ７に近い地点Ｐ８の観光業者は秋シーズンに観光特典を設定すれば、地点Ｐ７を訪れた観光客の一部は地点Ｐ８まで足を伸ばすかもしれない。

運輸業者も閑散期に割引などの運輸特典をつけることで、効率的に集客できる。飛行機と新幹線、人力車とタクシーのように競合関係になりやすい運輸サービスもある。運輸業者は集客をしたい時間帯や客層などに応じた運輸特典をつけることで、観光客を誘引しやすくなる。

今後はMaaS（Mobility as a Service）が一般化すると予想される。MaaSは、あらゆる運輸手段をクラウド化し、これらをシームレスにつなぐことで乗客を目的地に運ぶ仕組みである。本実施形態の移動プラン提案装置１００によれば、MaaSにおいてもあらゆる運輸サービスがさまざまな運輸機会を提供するだけでなく、運輸特典によって乗客を積極的に誘引することで運輸手段の稼働率を高めるやすくなると考えられる。

また、観光業者と運輸業者が特典を工夫することにより、観光サービスと運輸サービスの質がいっそう向上すると考えられる。その一方、特典やそのための取得条件が複雑化すると、ユーザは運輸サービスや観光サービスを上手に選ぶのが難しくなる可能性がある。移動プラン提案装置１００は、ユーザの現在地点、現在時刻、各運輸サービスの移動時間等を考慮した上で、ユーザにとってメリットの大きな推奨プランを提案できる。このため、「近くの足湯に行きたい」「海岸の近くでどこかおもしろいところに行きたい」という漠然としたニーズに対して、満足度の高い旅行プランを随時提案できる。特に、各種運輸手段の乗車時刻だけでなく、想定移動時間を想定した上で観光サービスの利用予定時刻を想定することで、ユーザは運輸サービスの特典と観光サービスの特典を効率よくもらうことができる。
移動プラン提案装置１００を利用することにより、ユーザは「上手な旅」を気軽に楽しむことができる。

一例として、ある駅から徒歩２０分の距離に温泉があるとする。通常、温泉の入湯料は１，０００円であり、タクシーを使うとすれば１，５００円の交通費かかる。ユーザは、歩いて温泉に行けば交通費がかからないので合計コストは１，０００円だが、タクシーをつかって温泉に行くと２，５００円かかる。この場合、ユーザはタクシーを使うのはお金がもったいないと感じて徒歩で温泉に向かうかもしれない。あるいは温泉行きそのものを断念するかもしれない。

もし、時間帯によっては温泉が５００円、タクシーが１，０００円に割引なったとすると、ユーザは１，５００円のコストにより、タクシー付きで温泉に行くことができる。このときには、普段に比べて１，０００円（＝２，５００－１，５００）も安いので、ユーザが温泉を行き先として選ぶ可能性が高くなる。また、ユーザがタクシーを使ってくれれば、時間と予算に余裕のできたこのユーザは温泉近くの別の観光サービス、たとえば、レストランや美術館などを利用してくれるかもしれない。推奨プランによっては、推奨プランに関わる運輸業者や観光業者だけでなく、関連する運輸業者や観光業者にも経済的利益が及ぶ可能性がある。推奨プランを起点とした連鎖的な経済効果を期待できる。

交通不便なところにある寺社仏閣であっても、タクシーを使ったとしてもそれほど合計料金が高くないのであれば、ユーザはせっかくなので足を伸ばしてみようと思うかもしれない。普段であれば高額な観光サービスであっても、特別に安く利用できる機会があれば、ユーザは利用してみようと思うかもしれない。運輸サービスと観光サービスそれぞれが提供する特典の双方を利用することにより、ユーザの割安感（メリット）を高めることができる。観光業者と運輸業者それぞれが独自に設定した特典が相乗効果を発揮する方式であるため、観光業者や運輸業者の一方に過度な負担がかかりにくい。複数の業者が可能な範囲で特典を工夫することにより、ユーザに対する大きなメリットを提案できる。
たとえば、ある観光地近辺の観光業者や運輸業者が全体として特典を提供することにより、この観光地の他の観光地に対する魅力を高めることもできる。

また、利用情報を参照し、推奨プランの人気に応じて、運輸業者や観光業者は特典の設定方法を柔軟に変更できる。たとえば、１１月が閑散期であるため、各業者は１１月に手厚い特典を設定したとする。特典のおかげで１１月の旅行に人気が出てきたときには、１１月の特典を減らしてもよい。１１月の旅行人気の継続を期待しつつ、別の閑散期である２月に今度は特典を設定してもよい。このように、特典時間帯を変化させることで、閑散期と繁忙期の落差を小さくできる。また、このような調整は観光地の混雑緩和にも寄与すると考えられる。

冬が閑散期の観光地でも、冬景色の魅力を知ってもらいたいときもある。広告によってこういった冬の魅力をアピールする方法もあるが、運輸業者と観光業者それぞれができる範囲で冬の特典を提供し合うことにより、結果的に冬旅行の魅力を高めることができる。このように複数の業者が提供する複数の特典をからめた推奨プランを提案することにより、観光客に大きなメリットを与えることで観光地の訪問意欲を高めることができる。

なお、本発明は上記実施形態や変形例に限定されるものではなく、要旨を逸脱しない範囲で構成要素を変形して具体化することができる。上記実施形態や変形例に開示されている複数の構成要素を適宜組み合わせることにより種々の発明を形成してもよい。また、上記実施形態や変形例に示される全構成要素からいくつかの構成要素を削除してもよい。

移動プラン提案装置１００は、単一の装置として構成されてもよいし、移動プラン提案装置１００の機能の一部が他の装置に割り当てられてもよい。

［変形例］
特典は、割引以外にもさまざまなものが考えられる。たとえば、クーポン券やくじ、景品であってもよい。タクシーであれば優良ドライバーや女性ドライバーによるサービスであることを運輸特典としてもよいし、電気自動車や高級車などの特別な車種を運輸特典としてもよい。

本実施形態においては、割引率に基づいて推奨プランを生成するとして説明した。推奨プラン特定部１３６は、運輸サービスと観光サービスの組み合わせごとに推奨度を設定してもよい。たとえば、運輸サービスの割引率が１０％以上なら１０ポイント、観光サービスの割引率が１０％以上なら更に１０ポイントを加算してもよい。２０％以上なら２０ポイントを加算してもよい。また、観光サービスとして踊りなどのイベントが特典として提供されるときにはそのイベントの価値に応じて推奨プラン特定部１３６は推奨度を加算してもよい。イベントの価値は開催回数が少ないほど、いいかえれば、希少なイベントほど高くなるとしてもよい。推奨プラン特定部１３６は、観光サービスのレビュー評点に応じて推奨度を増減させてもよい。推奨プラン特定部１３６は、さまざまな査定基準により各特典をポイント換算し、推奨度を計算する。そして、推奨度が所定値以上となる旅行プランを推奨プランとして提案してもよい。あるいは、推奨度による順位が所定順位以内、たとえば、１～３位の旅行プランを推奨プランとして提案してもよい。

ユーザは、複数の観光地、複数の観光サービスをあらかじめ「行き先候補」として登録してもよい。たとえば、ユーザは地点Ｐ１、Ｐ２の双方をあらかじめ移動プラン提案装置１００に登録しておく。まず、ユーザは、地点Ｐ０において地点Ｐ１を対象とした推奨プランの提案要求を移動プラン提案装置１００に送信する。ユーザは提案プランにしたがって地点Ｐ１で観光サービスを楽しむ。続いて、ユーザは地点Ｐ１において次の提案を求める提案要求を移動プラン提案装置１００に送信する。この提案要求には地点Ｐ２が設定されており、移動プラン提案装置１００は地点Ｐ２を対象とした推奨プランを提案する。

ユーザは、移動プラン提案装置１００が提案する推奨プランを「お気に入り」としてユーザ端末１０４に登録してもよい。プラン集計部１４０はこの「お気に入り」の登録状況を集計し、利用情報提示部１３４はこれを利用情報として観光端末１０６および運輸端末１０８に提供してもよい。運輸業者と観光業者はお気に入りの登録状況、推奨プランの成約状況により、どの推奨プランに人気があるか、人気が出そうかを推測できる。

ユーザが推奨プランを選択したとき、該当する運輸業者はユーザを迎えに行くとしてもよい。たとえば、ユーザが地点Ｐ０でタクシーを含む推奨プランを予約選択したとき、タクシー会社はユーザを迎えるために地点Ｐ０にタクシーを向かわせてもよい。あるいは、本実施形態において説明したように、ユーザは推奨プランを申し込んだあと、決済完了画面を地点Ｐ０のタクシーで提示することで、推奨プランの運輸特典を受けられるとしてもよい。

ユーザは、推奨プランを予約選択するとき、クレジットカードなどの既知の決済手段により利用料金を前払いする。ユーザは、推奨プランの利用をキャンセルできてもよい。具体的には、ユーザ端末１０４からキャンセル指示を移動プラン提案装置１００に送信する。キャンセル料を取らない場合には、決済処理部１３８は既知の決済手段による前払い処理をキャンセルする。キャンセルしたときでも、利用料金の全部または一部をキャンセル料として決済してもよい。

キャンセル料を全額返還する場合には、冷やかしで推奨プランが予約されるのを抑制するため、推奨プランの予約に条件をつけてもよい。たとえば、ユーザは地点Ｐ０にいなければ、地点Ｐ０を出発地点とする推奨プランを予約できないとしてもよい。あるいは、１０：００以降の乗車を想定した推奨プランの場合、１０：００から１時間前の９：００以降でないと予約できないとしてもよい。

推奨プランの料金は後払いであってもよい。たとえば、ユーザは推奨プラン（Ｒ０９）を予約したとする。このときには、ユーザは推奨プラン（Ｒ０９）の運輸サービスを利用したとき、推奨プラン（Ｒ０９）の提案に基づいて料金を支払い、運輸特典を受ける。次に、推奨プラン（Ｒ０９）の観光サービスを利用したときにも利用料金を支払い、観光特典を受けるとしてもよい。

推奨プラン特定部１３６は、推奨プランを自動的に停止してもよい。たとえば、タクシー会社が月曜日の早朝が閑散期であると想定してこの時間帯に運輸特典を設定したとする。しかし、この運輸特典に関わる推奨プラン（Ｒ１０）の予約が意外にも多いとき、たとえば、推奨プラン（Ｒ１０）の予約数が閾値以上となったときには、推奨プラン特定部１３６は推奨プラン（Ｒ１０）の新規予約受付を自動停止してもよい。このような制御方法によれば、閑散期になるという読みが外れたとき、タクシー会社は予約分の推奨プラン（Ｒ１０）には対応するものの、乗客が多いのに運輸特典を提供し続けるという事態を回避できる。推奨プラン特定部１３６は、上述の事態が生じたときには、推奨プラン（Ｒ１０）に関わるタクシー会社に対応不要を示すＮＧ通知をしてもよい。

この運輸特典の予約数の閾値、つまり、運輸サービスの提供可能件数は、運輸会社も設定可能である。提示された推奨プランをエンドユーザが成約した場合には、成約通知が運輸会社に予約通知として通知され、また、成約した推奨プランがキャンセルされた場合にはキャンセル通知が運輸会社にキャンセル通知として通知されてもよい。運輸会社は独自の配車システムを構築していることが多い。運輸会社の配車担当者が配車システムの配車可能数を参照し、本システムにおける運輸サービスの提供可能件数を設定する。これに加え、本システムと既存の配車システムとが連動する構成であってもよく、配車システムが特定時間の配車可能数または配車可能数から所定数を差し引いた残数を本システムに特定のタイミングで通知し（本システムが配車システム側に定期的にリクエストしてもよい）、本システムはその配車可能数または残数を運輸サービスの提供可能件数に自動的に反映してもよい。
特定のタイミングとは、たとえば、上述の配車可能数または残数が変化した時などである。

各運輸サービスプランにはそれを識別可能な識別情報が付与されており、通知に際してはその運輸サービスプランの識別情報も含めて通知する。地域サービスプランまたは運輸サービスプランに上限数があるということは、推奨プラン数にも上限があることになり（地域サービスプラン数と対応する運輸サービスプラン数のいずれか低い数）、ユーザに提示する際には推奨プラン数の残数を提示する構成とすることもできる。

特典の取得条件は、時間帯であってもよいし、天候などの環境に基づく条件であってもよい。たとえば、観光業者は４月２９日の天気予報が雨のときには、４月２９日に「雨の日の観光特典」を設定することで観光客の誘引を図ってもよい。このほかにも、お年寄りや女性、子ども、リピーターなど、観光客のユーザ属性に応じて特典を設定してもよい。

本実施形態においては、旅行を想定して説明した。移動プラン提案装置１００は所定地域で提供される地域サービスと、その地域までユーザを運ぶ運輸サービスの組み合わせを推奨プランとして提案するものであり旅行以外にも応用可能である。たとえば、ユーザが複数の病院のいずれかを選ぶときにも、移動プラン提案装置１００は特典に基づいて病院（地域サービス）と運輸サービスの組み合わせを推奨プランとして提案してもよい。地域サービスとしては、このほかにも遊園地、映画館、百貨店、銀行などさまざまなものが考えられる。

１００ 移動プラン提案装置、１０２ インターネット、１０４ ユーザ端末、１０６ 観光端末、１０８ 運輸端末、１１０ 決済システム、１２０ 通信部、１２２ データ処理部、１２４ データ格納部、１２６ 地域サービス登録部、１２８ 運輸サービス登録部、１３０ 提案要求受信部、１３２ 推奨プラン提示部、１３４ 利用情報提示部、１３６ 推奨プラン特定部、１３８ 決済処理部、１４０ プラン集計部、１４２ 地域サービスプラン格納部、１４４ 運輸サービスプラン格納部、１４６ 利用情報格納部、１４８ 決済通信部、２００ 検索入力領域、２０２ 評点領域、２０４ プラン検索画面、２０６ レビューボタン

Claims (2)

1. 地域サービスを提供する複数の地域サービス業者それぞれから、地域サービスの利用料金の割引を示す地域サービス特典の取得条件を含む地域サービスプランの登録を受け付ける地域サービス登録部と、
   運輸サービスを提供する複数の運輸サービス業者それぞれから、運輸サービスの利用料金の割引を示す運輸サービス特典の取得条件を含む運輸サービスプランの登録を受け付ける運輸サービス登録部と、
   ユーザから、推奨プランの提案要求を受信する提案要求受信部と、
   前記提案要求が受信されたとき、複数種類の地域サービスプランおよび複数種類の運輸サービスプランのうち、地域サービスの割引率と運輸サービスの割引率に基づく合計割引率が最大となるときの地域サービスプランと運輸サービスプランの組み合わせを前記推奨プランとして特定する推奨プラン特定部と、
   前記推奨プランを前記ユーザに提示する推奨プラン提示部と、を備え、
   前記運輸サービス特典の取得条件は、第１利用時間帯において運輸サービスを利用することであり、
   前記地域サービス特典の取得条件は、第２利用時間帯において地域サービスを利用することであり、
   前記推奨プラン特定部は、更に、出発地点から地域サービスが提供される地点までの運輸サービスに応じた移動時間を想定し、前記第１利用時間帯に運輸サービスを利用し、かつ、想定される移動時間の経過後に前記第２利用時間帯において地域サービスを利用可能なプランを推奨プランとして特定することを特徴とする移動プラン提案装置。
2. ユーザから推奨プランの予約選択を受け付けたとき、推奨プランの利用料金を決済する決済処理部、を更に備え、
   前記決済処理部は、決済後に推奨プランのキャンセルが受け付けられたときには、利用料金の全部または一部をユーザに返還することを特徴とする請求項１に記載の移動プラン提案装置。

Images