(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-13
(45)【発行日】2024-08-21
(54)【発明の名称】サーバ装置、処理方法、およびプログラム
(51)【国際特許分類】
G01C 21/26 20060101AFI20240814BHJP
G01C 21/34 20060101ALI20240814BHJP
G08G 1/005 20060101ALI20240814BHJP
G06Q 30/04 20120101ALI20240814BHJP
G06Q 50/40 20240101ALI20240814BHJP
G16Y 10/45 20200101ALI20240814BHJP
【FI】
G01C21/26 P
G01C21/34
G08G1/005
G06Q30/04
G06Q50/40
G16Y10/45
(21)【出願番号】P 2020172564
(22)【出願日】2020-10-13
【審査請求日】2023-10-02
(73)【特許権者】
【識別番号】597151563
【氏名又は名称】株式会社ゼンリン
(74)【代理人】
【識別番号】100095407
【氏名又は名称】木村 満
(74)【代理人】
【識別番号】100181618
【氏名又は名称】宮脇 良平
(74)【代理人】
【識別番号】100162259
【氏名又は名称】末富 孝典
(74)【代理人】
【識別番号】100146916
【氏名又は名称】廣石 雅紀
(74)【代理人】
【識別番号】100147924
【氏名又は名称】美恵 英樹
(72)【発明者】
【氏名】荒井 翔己
(72)【発明者】
【氏名】田副 寛太郎
(72)【発明者】
【氏名】木村 文則
【審査官】田中 将一
(56)【参考文献】
【文献】特開2020-166608(JP,A)
【文献】特許第6666507(JP,B1)
【文献】特開2014-191681(JP,A)
【文献】特開2016-030473(JP,A)
【文献】特開2009-298541(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G01C 21/00 - 21/36
G01C 23/00 - 25/00
G08G 1/00 - 99/00
G06Q 30/00 - 30/08
G06Q 50/00 - 50/20
G06Q 50/26 - 99/00
G16Z 99/00
G16Y 10/00 - 40/60
(57)【特許請求の範囲】
【請求項1】
プロセッサを備え、
前記プロセッサが、
ユーザが移動する前に作成された前記ユーザの計画経路であって、前記ユーザが利用する予定の路線を示す情報を含む計画経路と、前記ユーザの移動に係るログ情報
であって、前記ユーザの位置の履歴を示す位置情報を含むログ情報とを取得し、
前記ログ情報を、地図を構成する地図要素を示す地図データと照合することにより、前記ユーザが移動した移動経路を推定する経路推定処理を実行し、
取得した前記計画経路及び前記経路推定処理で推定した前記移動経路と、前記ユーザ
が実際に移動した実績経路を特定するためのルールを示す所与のルールデータ
とに基づいて、前記ユーザが実際に移動した
前記実績経路を
前記ルールに従って特定する、
サーバ装置
であって、
前記ルールデータは、
前記経路推定処理で推定した前記移動経路に、互いに並行する複数の路線が含まれる場合に、前記複数の路線のうちの前記計画経路が示す前記路線を、前記実績経路を構成するものとして選定する、という前記ルールを示す、
サーバ装置。
【請求項2】
前記計画経路には、前記ユーザが改札を通過する予定の駅を示す情報が含まれ、
前記ログ情報には、前記ユーザが
改札を通過した駅を特定することができる通過ログ
が含まれ、
前記ルールデータは、
前記計画経路が示す前記駅と、前記通過ログによって特定される前記駅とが一致しない場合に、前記通過ログによって特定される前記駅を、前記実績経路を構成するものとして選定する、という前記ルールを示す、
請求項1に記載のサーバ装置。
【請求項3】
前記プロセッサが、特定された前記実績経路に基づいて、前記ユーザの移動に要した費用の決済処理を行う、請求項1
又は2に記載のサーバ装置。
【請求項4】
ユーザが移動する前に作成された前記ユーザの計画経路であって、前記ユーザが利用する予定の路線を示す情報を含む計画経路と、前記ユーザの移動に係るログ情報であって、前記ユーザの位置の履歴を示す位置情報を含むログ情報とを取得するステップと、
前記ログ情報を、地図を構成する地図要素を示す地図データと照合することにより、前記ユーザが移動した移動経路を推定する経路推定処理を実行するステップと、
取得した前記計画経路及び前記経路推定処理で推定した前記移動経路と、前記ユーザが実際に移動した実績経路を特定するためのルールを示す所与のルールデータとに基づいて、前記ユーザが実際に移動した前記実績経路を前記ルールに従って特定するステップと、
をコンピュータが実行する処理方法であって、
前記ルールデータは、
前記経路推定処理で推定した前記移動経路に、互いに並行する複数の路線が含まれる場合に、前記複数の路線のうちの前記計画経路が示す前記路線を、前記実績経路を構成するものとして選定する、という前記ルールを示す、
処理方法。
【請求項5】
ユーザが移動する前に作成された前記ユーザの計画経路であって、前記ユーザが利用する予定の路線を示す情報を含む計画経路と、前記ユーザの移動に係るログ情報
であって、前記ユーザの位置の履歴を示す位置情報を含むログ情報とを取得するステップと、
前記ログ情報を、地図を構成する地図要素を示す地図データと照合することにより、前記ユーザが移動した移動経路を推定する経路推定処理を実行するステップと、
取得した前記計画経路及び前記経路推定処理で推定した前記移動経路と、前記ユーザ
が実際に移動した実績経路を特定するためのルールを示す所与のルールデータ
とに基づいて、前記ユーザが実際に移動した
前記実績経路を
前記ルールに従って特定するステップと、
をサーバ装置に実行させるプログラム
であって、
前記ルールデータは、
前記経路推定処理で推定した前記移動経路に、互いに並行する複数の路線が含まれる場合に、前記複数の路線のうちの前記計画経路が示す前記路線を、前記実績経路を構成するものとして選定する、という前記ルールを示す、
プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示の一側面はコンピュータシステム、処理方法、プログラム、および/またはデータ構造に関する。
【背景技術】
【0002】
特許文献1には、ユーザの現在位置、移動速度等の移動に係るログ情報から、ユーザの移動手法を特定し、特定した移動手法に基づいてユーザに対してポイントを付与する方法が開示されている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
本開示の一側面は、ユーザの移動に係るログ情報から、ユーザが実際に移動した実績経路をより高い精度で特定することを目的とする。
【課題を解決するための手段】
【0005】
本開示の一側面に係るサーバ装置はプロセッサを備える。プロセッサは、ユーザが移動する前に作成されたユーザの計画経路であって、ユーザが利用する予定の路線を示す情報を含む計画経路と、ユーザの移動に係るログ情報であって、ユーザの位置の履歴を示す位置情報を含むログ情報とを取得し、ログ情報を、地図を構成する地図要素を示す地図データと照合することにより、ユーザが移動した移動経路を推定する経路推定処理を実行し、取得した計画経路及び経路推定処理で推定した移動経路と、ユーザが実際に移動した実績経路を特定するためのルールを示す所与のルールデータとに基づいて、ユーザが実際に移動した実績経路をルールに従って特定する。ルールデータは、経路推定処理で推定した移動経路に、互いに並行する複数の路線が含まれる場合に、複数の路線のうちの計画経路が示す路線を、実績経路を構成するものとして選定する、というルールを示す。
【図面の簡単な説明】
【0006】
【
図1】
図1は、実施形態に係る情報管理システムの適用の一例を示す図である。
【
図2】
図2は、実施形態に係る情報管理システムで用いられるコンピュータのハードウェア構成の一例を示す図である。
【
図3】
図3は、実施形態に係る情報管理システムの機能構成の一例を示す図である。
【
図4】
図4は、移動コードデータの一例を示す図である。
【
図5】
図5は、移動コードデータの作成および保存に係る処理の一例を示すシーケンス図である。
【
図6】
図6は、実績経路の特定及び決済処理の一例を示すシーケンス図である。
【
図7】
図7は、実績経路の特定方法の一例を示す図である。
【
図8】
図8は、実績経路の特定方法の一例を示す図である。
【
図9】
図9(a)、
図9(b)は、決済処理の一例を示すフローチャートである。
【
図11】
図11は、ポイント付与に係る処理の一例を示すフローチャートである。
【
図12】
図12は、実績経路のコンテンツ化に係る処理の一例を示すシーケンス図である。
【発明を実施するための形態】
【0007】
以下、添付図面を参照しながら本開示での実施形態を詳細に説明する。図面の説明において同一または同等の要素には同一の符号を付し、重複する説明を省略する。
【0008】
[システムの概要]
実施形態に係る情報管理システム1は、ユーザの移動経路を示す経路データを管理するコンピュータシステムである。移動経路とは、現実世界における或る地点から別の地点までの移動に関する情報をいい、典型的には出発地から目的地までの移動に関する情報をいう。出発地とは、移動経路を検索するための始点として設定される場所をいい、目的地とはその検索のための終点として設定される場所をいう。出発地および目的地はいずれも経路検索の基準点となり得る場所である。一例では、移動経路は、出発地から目的地までの経路だけでなく、その経路の属性(以下では「経路属性」という)も示すことができる。経路属性とは、経路の性質、特徴、状況、あるいは、経路を移動するユーザの情報(年齢、性別、国籍、体調など)を表す任意の情報である。例えば、経路属性は、交通機関などの移動手段と、経路を移動する日時と、経路を移動するための所要時間または費用と、経路の状況(例えば交通情報)と、経路に関連する地物(すなわち地物情報)と、経路に関連する事業者(すなわち事業者情報)と、経路に関連するサービス情報(例えば広告情報、クーポン情報など)と、経路を移動するユーザに関する情報(年齢、性別、国籍、体温、心拍数、発汗量、血糖値、カロリー消費量など)と、経路を移動するユーザの目的情報(ビジネス、観光、買い物、健康、暇つぶしなど)とのうちの少なくとも一つを含んでもよい。経路データとは移動経路を示す電子データであり、典型的には緯度経度情報で表される時系列の点列座標であるが、これに限られない。経路データにおいて、リンクおよびノードから構成されるネットワークデータに点列座標を照合して得られるリンクIDおよびノードIDが用いられてもよい。経路データは、経路を移動する日時(時刻)を示すテキストデータを含んでもよい。時刻に関するテキストデータは、リンクIDおよびノードIDに関連付けられてもよい。ユーザとは自己の経路データを情報管理システム1に提供する人をいう。ユーザは個人でもよいし複数人から成るグループでもよい。
【0009】
移動手段とは、移動するための方法をいう。移動手段は移動体に限定されず、移動体を用いない方法も含む概念である。移動手段は公共交通機関でもよいし、ユーザが自分で操作する移動体でもよい。移動手段は、地上または地下の移動体でもよいし、空中の移動体でもよいし、水上または水中の移動体でもよい。移動手段の例として徒歩、自転車、バイク、自家用車、バス、タクシー、在来線、高速鉄道、航空機、ドローン、およびフェリーが挙げられるが、当然ながら移動手段はこれらに限定されるものではない。
【0010】
公共交通機関とは、運行する経路および時刻が決まっており、且つ不特定の一般の人々が共同で利用する交通機関をいう。公共交通機関の例として鉄道(モノレール等を含む)、路面電車、路線バス、航空機、フェリーなどが挙げられるが、公共交通機関はこれらに限定されない。タクシーは公共交通機関ではない。
【0011】
経路データによって示される移動経路の種類は限定されない。経路データは、候補として検索された移動経路、ユーザにより選択された移動経路、またはユーザにより実際に利用された移動経路を示してもよい。本開示では、候補として検索された移動経路を「候補経路」といい、1以上の候補経路の中からユーザにより選択された移動経路を「計画経路」といい、ユーザにより実際に利用された移動経路を「実績経路」という。一の移動経路が候補経路、計画経路、および実績経路のうちの2以上に該当することがあり得る。
【0012】
地物とは、地上に存在する任意の有体物または無体物である。地物は自然物でも人工物でもよい。例えば、地物は、山地、農地、住宅地、更地、河川、湖、海、観光地、道路、鉄道、建物、公園、塔、信号機、踏切、横断歩道、歩道橋、浮標などを含み得る。無体物である地物の例として、任意の目的で設定された区域(例えば、撮影禁止区域、一時的な進入禁止区域など)、イベントが開催される区域、集合場所、撮影スポットなどが挙げられる。当然ながら、地物の種類はこれらに限定されない。
【0013】
情報管理システム1によって管理される1以上のユーザの経路データは任意の目的のために利用され得る。例えば、経路データは、「サービスとしての移動」(Mobility as a Service(MaaS))、都市計画、交通計画、環境対策、防災対策、防犯対策、需要予測、マーケティング、人流解析などの、人々の生活または地球環境の維持もしくは改善に役立つ様々な目的のために利用されてよい。経路データは任意の事業者および他のユーザによって利用され得る。事業者の例として、鉄道、ロープウェー、バス、タクシー、飛行機、ドローン、船舶などの各種の交通機関の事業者と、自動車、自転車などの各種の移動手段のレンタル事業者と、配車サービスの事業者と、ショッピング、レストラン、駐車場などの各種施設を運営する事業者と、広告、クーポンなどの各種情報を提供する事業者と、決済事業者と、国または自治体の各種の組織とが挙げられる。事業者には、個人事業主も含まれ得る。
【0014】
一例として、情報管理システム1がユーザに対して「サービスとしての移動」(Mobility as a Service(MaaS))を提供するとする。ここでは、サービスの1つとして、例えば、情報管理システム1が、ユーザの移動経路に係る経路データを管理し、ユーザの移動に応じて発生する運賃の決済等を管理するとする。この場合、ユーザの移動実績に対応する経路データを情報管理システム1では把握する必要がある。特に、情報管理システム1においてユーザの移動実績に基づいた決済処理またはポイント付与等を行う場合、ユーザの移動実績を正確に把握することが求められる。そこで、情報管理システム1では、移動経路を高い精度で特定するためのルールを予め保持し、当該ルールに基づいてユーザの移動ログから移動実績(実績経路)を精度よく特定する。また、情報管理システム1は、より高い精度で特定された移動実績を利用して、各種サービスを提供する。
【0015】
また、一例では、情報管理システム1は、ユーザに対して経路探索機能を提供してもよい。また、ユーザが経路探索機能を利用すること等によって特定した、将来に使用し得る移動経路(計画経路)に係る経路データを取得してもよい。ユーザから取得した計画経路は、移動実績の特定に利用され得る。
【0016】
一例では、情報管理システム1は、様々な目的で用いられ得る経路データを統括的に制御または管理するプラットフォームとしての役割を果たし得る。これに関連して、情報管理システム1の管理者または運営者はプラットフォーマであり得る。一例では、情報管理システム1は任意の事業者に対して、ユーザに係る経路データ(計画経路・実績経路)を提供することができる。事業者はその経路データに基づいて広告提供等のサービスを行ってもよい。
【0017】
[システムの構成]
図1は情報管理システム1の適用の一例を示す図である。一例では、情報管理システム1はプラットフォーマサーバ10および1以上のユーザ端末20を備える。プラットフォーマサーバ10および個々のユーザ端末20は通信ネットワークNWを介して互いにデータを送受信することができる。プラットフォーマサーバ10は通信ネットワークNWを介してデータベース群30にアクセスしてデータを読み取ったり書き込んだりすることができる。データベース群30に記憶されたデータの少なくとも一部は、通信ネットワークNWを介して1以上の事業者サーバ40によってアクセスされ得る。
【0018】
プラットフォーマサーバ10(サーバ装置)は経路データを収集するコンピュータである。プラットフォーマサーバ10として機能するコンピュータは限定されない。一例では、プラットフォーマサーバ10は業務用サーバなどの大型のコンピュータによって構成される。プラットフォーマサーバ10は一つまたは複数のコンピュータにより構成され得る。複数のコンピュータが用いられる場合には、通信ネットワークを介してこれらのコンピュータが互いに接続されることで論理的に一つのプラットフォーマサーバ10が構成される。
【0019】
ユーザ端末20はユーザによって操作されるコンピュータである。一例では、ユーザ端末20は、プラットフォーマサーバ10にアクセスしてプラットフォーマサーバ10が提供する経路データを利用した各種サービスに係るデータを取得することができる。本実施形態では、本発明の一側面に係る端末をユーザ端末20に適用する。ユーザ端末20は固定端末でもよいし携帯端末でもよい。ユーザ端末20の例として、携帯電話機、スマートフォン、タブレット端末、ウェアラブル端末、およびパーソナルコンピュータなどのデバイスが挙げられる。しかし、ユーザ端末20の種類はこれらに限定されない。ユーザ端末20は、一つの筐体から構成されるデバイスでもよいし、複数のデバイスによって構成されてもよい。例えば、ユーザ端末20はウェアラブル端末とスマートフォンとの組合せでもよい。この場合には、ウェアラブル端末がユーザの移動経路に係る移動ログを取得し、そのデータをスマートフォンに送信する。スマートフォンはウェアラブル端末において取得された移動ログをプラットフォーマサーバ10に送信する。情報管理システム1にアクセスするユーザ端末20の台数は限定されない。
【0020】
データベース群30は、情報管理システム1において用いられるデータを記憶するデータベースの集合である。一例では、データベース群30は地図データベース31、移動コードデータベース32、ユーザデータベース33、および広告データベース34を含む。それぞれのデータベースは情報管理システム1の一部として構築されてもよいし、情報管理システム1とは別のコンピュータシステムに設けられてもよい。地図データベース31は、地図を構成する地図要素を示す地図データを永続的に記憶する非一時的な記憶媒体または記憶装置である。移動コードデータベース32は、プラットフォーマサーバ10で取り扱う経路データを永続的に記憶する非一時的な記憶媒体または記憶装置である。ユーザデータベース33は、プラットフォーマサーバ10を使用するユーザ毎のユーザデータを永続的に記憶する非一時的な記憶媒体または記憶装置である。広告データベース34は広告データを永続的に記憶する非一時的な記憶媒体または記憶装置である。
【0021】
事業者サーバ40は事業者によって管理または運用されるコンピュータである。一例では、事業者サーバ40は移動コードデータベース32にアクセスして移動コードデータを取得することができる。また、事業者サーバ40は広告データベース34にアクセスして広告データを保存することができる。事業者サーバ40として機能するコンピュータは限定されない。例えば、事業者サーバ40は業務用サーバなどの大型のコンピュータによって構成されてもよいし、パーソナルコンピュータによって構成されてもよい。情報管理システム1にアクセスする事業者サーバ40の台数は限定されない。
【0022】
一例では、情報管理システム1では、ユーザ端末20は自端末の移動に係る経路データをプラットフォーマサーバ10に向けて送信する。送信のタイミングは、典型的にはユーザが目的地に到着した後であるが、目的地に到着する前でもよい。また、移動経路の種類が計画経路または候補経路である場合には、送信のタイミングはユーザが出発地から移動を開始する前でもよい。移動経路の種類が実績経路である場合でも、ユーザ端末20は、目的地に到着する途中までの実績経路をそのタイミングで送信してもよい。
【0023】
一例では、プラットフォーマサーバ10は、経路データを取得すると、移動コードデータを生成する。そして、移動コードデータを移動コードデータベース32に登録する。移動コードデータは、ユーザ端末20から取得した1つの計画経路毎に1つ生成される。また、プラットフォーマサーバ10がユーザ端末20から計画経路を取得した後、ユーザ端末20から当該計画経路に対応する実績経路に係る経路データを取得した場合には、プラットフォーマサーバ10は、当該経路データを、作成済みの移動コードデータに追加する。また、作成済みの移動コードデータが存在しない、すなわちユーザ端末20において予め計画経路が作成されず、ユーザが移動した実績経路に係る経路データをユーザ端末20から取得した場合には、プラットフォーマサーバ10は、新たに移動コードデータを生成して移動コードデータベース32に登録してもよい。このように、プラットフォーマサーバ10は、ユーザ端末20の1回の移動に対して1つの移動コードデータを生成し、移動コードデータベース32へ登録する。
【0024】
一例では、情報管理システム1では、ユーザ端末20から移動実績に係る移動ログ(ログ情報)を取得した場合には、当該経路データからユーザ端末20から実際に通った経路(実績経路)を特定する。ここで、実績経路を特定するとは、ユーザが実際に通った道路や路線に関する情報を取得することを意味する。広義には、実績経路を特定するとは、徒歩、自転車、自家用車、バス、電車など、ユーザが移動に際して実際に使用した移動手段に関する情報を取得することを意味する。ログ情報は、移動経路に係る経路データを含む。ユーザ端末20において予め計画経路を作成していた場合でも、道路状況・公共交通の運行状況等によって計画経路から変更した経路でユーザが移動する場合がある。情報管理システム1では、ユーザ端末20から移動実績に係る移動ログを取得した場合に、ユーザ端末20が実際に移動した経路(実績経路)を特定する処理を行ってもよい。この場合、情報管理システム1は、例えば、ログ情報(GPSの位置情報履歴)と地図データベース31に記憶される地図データとの照合等(いわゆる、マップマッチング)を行った上で、更にユーザの計画経路、ユーザの通過ログ、公共交通機関の時刻表を用いて実績経路の特定の少なくとも一つを用いて行ってもよい。ここで、マップマッチングとは、GPSの位置情報を地図データ(ノードデータやリンクデータ)と照合させ、地図上における道路を特定することである。GPSの位置情報には誤差(例えば、5m)が含まれるため、マップマッチングを行った際、誤った移動経路(例えば、複数の路線が並走しており、ユーザが通過していない路線を移動経路としてしまう等)を実績経路として特定する可能性がある。そのため、ユーザの計画経路、ユーザの通過ログ、公共交通機関の時刻表の少なくとも一つを用いて、特定した移動経路を補正し、実績経路を確定させるのである。
【0025】
図2は、情報管理システム1で用いられるコンピュータ110のハードウェア構成の一例を示す図である。例えば、コンピュータ110は制御回路100を有する。一例では、制御回路100は、一つまたは複数のプロセッサ101と、メモリ102と、ストレージ103と、通信ポート104と、入出力ポート105とを有する。プロセッサ101はオペレーティングシステムおよびアプリケーションプログラムを実行する。ストレージ103はハードディスク、不揮発性の半導体メモリ、または取り出し可能な媒体(例えば、磁気ディスク、光ディスクなど)の記憶媒体で構成され、オペレーティングシステムおよびアプリケーションプログラムを記憶する。メモリ102は、ストレージ103からロードされたプログラム、またはプロセッサ101による演算結果を一時的に記憶する。プロセッサ101は、メモリ102と協働してプログラムを実行することで、個々の機能モジュールとして機能する。通信ポート104は、プロセッサ101からの指令に従って、通信ネットワークNWを介して他の装置との間でデータ通信を行う。入出力ポート105は、プロセッサ101からの指令に従って、キーボード、マウス、モニタ、タッチパネルなどの入出力装置(ユーザインタフェース)との間で電気信号の入出力を実行する。
【0026】
搭載されるハードウェアモジュールはコンピュータの種類によって異なり得る。例えば、プラットフォーマサーバ10に搭載されるCPU、メモリ、ネットワークカードなどのモジュールはユーザ端末20のものよりも高性能であり得る。プラットフォーマサーバ10の入力装置としては一般にキーボードおよびマウスが用いられ、出力装置としてはモニタが用いられる。ユーザ端末20がパーソナルコンピュータである場合には、入力装置としては一般にキーボードおよびマウスが用いられ、出力装置としてはモニタが用いられる。ユーザ端末20が携帯端末である場合には、一般にはタッチパネルが入出力装置として用いられる。
【0027】
図3は情報管理システム1の機能構成の一例を示す図である。より具体的には、
図3はプラットフォーマサーバ10およびユーザ端末20の機能構成の一例を示す。
【0028】
プラットフォーマサーバ10は機能モジュールとして検索部11、計画経路設定部12、運行関連情報通知部13、移動ログ取得部14、実績経路特定部15、経路ルールデータベース16、コンテンツ管理部17、ポイント管理部18、および決済部19を備える。検索部11はユーザ端末20からの要求に応答して移動経路を検索する機能モジュールである。計画経路設定部12は、ユーザ端末20から取得した将来移動予定の経路を計画経路として移動コードデータを生成する機能モジュールである。運行関連情報通知部13は移動コードデータに計画経路を登録したユーザ端末20に対して、計画経路に係る交通手段の運行情報等を通知する機能モジュールである。移動ログ取得部14は、ユーザ端末20が実際に移動した経路に係る移動ログを取得する機能モジュールである。実績経路特定部15は、ユーザ端末20から取得した移動ログに基づいてユーザ端末20の実際の移動経路を特定する機能モジュールである。経路ルールデータベース16は、実績経路特定部15において実績経路を特定するためのルールを記憶する機能モジュール(記憶領域)である。コンテンツ管理部17は、ユーザ端末20からの要求に基づいて実績経路に係るコンテンツを生成する機能モジュールである。ポイント管理部18は、ユーザ端末20の実績経路に応じてユーザに対して付与するポイントを管理する機能モジュールである。決済部19は、ユーザ端末20の実績経路に応じた決済を行う機能モジュールである。
【0029】
ユーザ端末20は機能モジュールとして計画経路選定部21、運行関連情報取得部22、移動ログ取得部23、送信部24、および表示部25を備える機能モジュールである。計画経路選定部21は、ユーザが将来移動する移動の経路に係る計画経路を選定する。一例では、計画経路選定部21は、プラットフォーマサーバ10の検索部11と連携して、ユーザにより設定された検索条件に合致する移動経路(候補経路)から、特定の移動経路を選択して計画経路とする。一例として、ユーザ端末20において選定された計画経路は、プラットフォーマサーバ10に対して送信される。運行関連情報取得部22は、プラットフォーマサーバ10の運行関連情報通知部13と連携して、計画経路に係る交通手段の運行情報等を取得し、ユーザに対して通知する機能モジュールである。移動ログ取得部23は、ユーザ端末20の現在位置の履歴を実績経路として取得する機能モジュールである。一例では、移動ログ取得部23は全地球測位システム(GPS)機能を利用する。また、一例として、移動ログ取得部23は、特定の場所を通過したことを特定することができる通過ログを移動ログの一種として取得してもよい。通過ログは、例えば、駅の改札を通過したことを示す情報、特定の施設に設けられたQRコード(登録商標)等をユーザ端末20で読み取ったことを示す情報等が含まれ得る。送信部24は、プラットフォーマサーバ10に対して移動ログを送信する機能モジュールである。表示部25は、プラットフォーマサーバ10から取得した情報等を表示することでユーザに対して機能モジュールである。一例として、プラットフォーマサーバ10から取得する情報には、移動の経路に係る情報、計画経路に係る交通手段の運行情報、プラットフォーマサーバ10から提供される広告、コンテンツデータ等が含まれる。
【0030】
[地図データ]
地図データは、例えば候補経路の検索や移動ログとの照合(いわゆる、マップマッチング)のために用いられる。地図データのデータ構造は限定されない。地図データにより示される地図要素の種類および表現方法は限定されず、任意の方針で設計されてよい。地図要素の例としてノードおよびリンクが挙げられる。ノードとは、経路を特徴づける位置をいい、より具体的には、移動体の移動方法(例えば方向、速度など)を変えることができる位置、または該移動方法が変わる位置をいう(例えば、駅、バス停、駐車場等の移動手段や公共交通機関の乗り換え地点、交差点など)。リンクとは、経路を示すために設定される仮想的な線であって、隣接するノード間を結ぶ線である(例えば、交差点間を構成する道路や路線等)。リンクの形状は直線でも曲線でもよく、あるいは、直線と曲線との組合せでもよい。地上においては、リンクの形状は道路または軌道の形状に依存し得る。ノードおよびリンクが設定される位置は限定されず、例えば、ノードおよびリンクは地上、地下、空中、水上、または水中に設定され得る。二つのノードを結ぶリンクが複数個存在してもよい。例えば、二つのノードが鉄道に関するリンクと道路に関するリンクとの双方によって結ばれる場合があり得る。
【0031】
一例では、地図データは、複数のノードを示すノードデータと、複数のリンクを示すリンクデータとを含んで構成される。
【0032】
一例では、ノードデータはデータ項目としてノードID、座標、およびノード属性を含む。ノードIDは個々のノードを一意に特定する識別子である。座標は、ノードの2次元(緯度、経度)または3次元(緯度、経度、高度)の地理的位置を示す値である。座標の設定方法は限定されず、例えば、座標は緯度および経度を用いて表現されてもよいし、他の任意の座標系に従って設定されてもよい。ノード属性とは、ノードの性質、特徴、または状況を表す任意の情報である。例えば、ノード属性は、ノードに関連する地物に関する地物情報を含んでもよいし、ノードに関連する事業者に関する事業者情報を含んでもよい。
【0033】
一例では、リンクデータはデータ項目としてリンクID、第1ノードID、第2ノードID、およびリンク属性を含む。リンクIDは個々のリンクを一意に特定する識別子である。第1ノードIDおよび第2ノードIDはいずれも、リンクの端に位置するノードを特定するノードIDである。リンク属性とは、リンクの性質、特徴、または状況を表す任意の情報である。例えば、リンク属性は、交通機関などの移動手段と、リンクを移動するための所要時間または費用と、リンクの状況(例えば交通情報)と、リンクに関連する地物(すなわち地物情報)と、リンクに関連する事業者(すなわち事業者情報)と、リンクに関連するサービス情報(例えば広告情報、クーポン情報など)のうちの少なくとも一つを含んでもよい。
【0034】
一例では、地図データは、交通結節点および交通施設を示すデータをさらに含んで構成される。この場合には、ノード属性は交通結節点または交通施設に関する情報を含んでもよい。
【0035】
交通結節点とは移動手段の変更が実施される場所(要するに、移動手段が変わる場所)をいう。より具体的には、交通結節点は、複数の同種あるいは異種の移動手段の接続が行われる場所をいう。交通結節点は複数の交通施設を含む。「移動手段の変更」とは或る移動手段から別の移動手段に変えることをいう。移動手段が限定されないことに対応して、移動手段の変更も限定されない。或る移動手段から別の移動手段への乗換は、移動手段の変更の一例である。移動手段の変更の例として、タクシーから在来線への乗換、或る路線(鉄道路線、バス路線など)から別の路線(鉄道路線、バス路線など)への乗換、自家用車から徒歩への変更、徒歩から在来線への変更などが挙げられる。
【0036】
交通施設とは、移動手段を変更するためにユーザに利用される施設をいう。交通施設は、交通結節点を構成する要素として情報管理システム1により処理される。交通施設はノードの一種であり得る。交通施設の例として、駅、バス停、タクシー乗り場、港、空港、レンタカーの営業所、レンタサイクルのサイクルポート、駐車場、および駐輪場が挙げられるが、交通施設はこれらに限定されない。一つの交通施設が複数の交通結節点と関連付けられてもよい。したがって、交通結節点および交通施設は多対多の関係(言い換えるとM:Nの関係)にある。それぞれの交通結節点では、該交通結節点を代表する一つの交通施設が設定される。本開示ではその代表の交通施設を「代表施設」という。また、本開示では、それぞれの交通結節点において代表施設以外の交通施設を「構成施設」という。
【0037】
代表施設は任意の手法によって設定されてよい。例えば、代表施設は、交通結節点または特定の区域の中で最も中心的な役割を果たす施設、最も利用者が多い交通施設、あるいはランドマークの役割を持つ交通施設でもよい。
【0038】
構成施設も任意の方針で設定されてよい。或る交通施設を構成施設としていずれかの交通結節点に所属させる場合には、その交通施設にいちばん近い代表施設が特定され、その交通施設が、該特定された代表施設と同じ交通結節点に構成施設として追加されてもよい。あるいは、異なる交通手段を利用するユーザの利用実績または地形上の関係に基づいて、交通施設をどの交通結節点に所属させるかが決定されてもよい(例えば、或る交通施設を、川向いにある代表施設に所属させないように構成施設が決定されてもよい)。
【0039】
交通結節点は、交通結節点に関する情報を示す交通結節点データによって管理されてもよい。一例では、交通結節点データの各レコードは、個々の交通結節点を一意に特定する交通結節点IDと、交通結節点の名称(交通結節点名)と、を含んでいてもよい。また、交通結節点での乗換に関しては、乗換データにおいて管理してもよい。一例では、乗換データの各レコードは、個々の乗換方法を一意に特定する乗換IDと、乗換に用いられる二つの交通施設のIDと、移動コスト(移動に係る時間等の負荷)とを含む。
【0040】
地図データの個々のデータ項目は静的に設定されてもよいし動的に設定されてもよい。「静的に設定される」とは、値が予め設定され、人手の介入がない限りはその設定が変更されないことをいう。一方、「動的に設定される」とは、値が任意の事象に応じて人手の介入無しに変更され得ることをいう。動的な設定は、所与のデータ項目を制御するプログラムが所定のコンピュータ上で実行されることで実現される。動的な設定は情報管理システム1により実行されてもよいし、別のコンピュータシステムにより実行されてもよい。
【0041】
[経路データ]
経路データのデータ構造は限定されない。例えば、経路データは複数のノードIDおよび複数のリンクIDによって表現されてもよい。より具体的には、経路データは、交通施設または交通結節点に対応するノードのノードIDと、そのノード間(すなわち交通施設間または交通結節点間)を結ぶリンクのリンクIDとによって表現されてもよい。上述したように移動経路は経路属性を示すことができるので、経路データはその経路属性に対応するデータ項目を含み得る。例えば、経路データは、経路上での移動に関する日時(本開示ではこれを「移動日時」という)を示してもよい。移動日時の例として、個々のノードでの出発日時、通過日時、乗換日時、または到着日時が挙げられる.しかし、移動日時の種類はこれらに限定されない。移動日時は、候補経路および計画経路では予定の日時を示し、実績経路では実際の日時を示す。別の例では、経路データは移動経路における交通費の見込額または実額を示してもよい。この交通費は交通手段ごとに示されてもよいし、移動経路の全体における総額として示されてもよい。
【0042】
[移動コードデータ]
移動コードデータのデータ構造は限定されない。
図4では移動コードデータD1の一例を示している。
図4に示すように、移動コードデータD1の各レコードは、基本情報D11、計画経路情報D12、および実績経路情報D13を含んでいてもよい。
【0043】
基本情報D11は、移動コードデータを特定するための情報を含む。一例として、基本情報D11は、移動ID、ユーザID、経路発行事業者ID(経路検索を主管した事業者のID)、開始ノード(出発地に係るノード)、および終了ノード(目的地に係るノード)を含んでいてもよい。
【0044】
計画経路情報D12は、ユーザ端末20によって設定された計画経路に係る情報を含む.一例として、計画経路情報D12は、経路コード(移動する経路を特定したリンク情報;経路データ)、移動手段(経路コードに沿った移動を行う際に利用する交通手段を特定する情報)、出発予定時間、到着予定時間、およびリンクリストを含んでいてもよい。一例として、リンクリストは、リンクID、移動手段、運賃、出発予定時間、および到着予定時間を含んでいてもよい。
【0045】
実績経路情報D13は、ユーザ端末20の移動ログに基づいて特定されたユーザ端末の実績経路に係る情報を含む.一例として、実績経路情報D13は、経路コード、移動状況(「移動中」または「到着済み」等を示す情報)、滞在中リンク(現在地を含むリンクを示す情報)、およびリンク情報を含んでいてもよい。一例として、リンク情報は、リンクID、出発実績時間、および到着実績時間を含んでいてもよい。
【0046】
[システムでの処理手順]
(移動コードデータの生成)
図5を参照しながら、ユーザ端末20により設定された計画経路に基づいて移動コードデータを生成する処理について説明する。
【0047】
ステップS01では、ユーザがユーザ端末20を操作することで経路の検索に係る情報を入力する。ユーザ端末20の計画経路選定部21は経路の検索条件に係る情報を取得する。経路の検索条件には、例えば、出発地点(スタート)および目標地点(ゴール)、移動を行う日時、優先して使用する交通手段等を特定する情報が含まれる。ステップS02では、ユーザ端末20の計画経路選定部21からプラットフォーマサーバ10に対して検索条件が送信され、経路検索のリクエストが行われる。
【0048】
ステップS03では、プラットフォーマサーバ10の検索部11が、検索条件に基づいた経路検索を行う。一例では、ユーザ端末20がユーザから目的地の入力を受け付ける。目的地の入力は、電話番号による検索、住所による検索、地図上に表示した施設や地点を直接選択する等の周知の方法により行う。検索部11は、出発地点(例えば、ユーザ端末20の現在位置、ユーザの指定する出発地点等)から目的地まで至る交通手段の経路検索処理を行う。一例では、ユーザ端末20の現在位置(出発地点)が東京駅であり目的地が品川駅である場合、東京駅から品川駅まで至る交通手段として、東海道新幹線、東海道線、横須賀線、山手線、京浜東北線等の経路が検索される。そして、ステップS04では、プラットフォーマサーバ10の検索部11からユーザ端末20に対して検索結果として、1以上の経路の候補(上記の一例では、東海道新幹線、東海道線、横須賀線、山手線、京浜東北線)が送信される。必要に応じて上記のステップS01~S04は繰り返される。
【0049】
ステップS05では、ユーザ端末20において、ユーザの操作によって、使用する予定の経路候補が選択される(上記の一例では、ユーザ端末20において京浜東北線が経路候補として選択されるとする)。
ステップS06では、ユーザ端末20の計画経路選定部21が選択された結果をプラットフォーマサーバ10に対して送信する。プラットフォーマサーバ10は、ユーザ端末20から送信された選択結果を取得する。
【0050】
ステップS07では、プラットフォーマサーバ10の計画経路設定部12が、ユーザ端末20からの選択結果に基づいて移動コードデータを生成する。この段階では、プラットフォーマサーバ10は、移動コードデータに係る情報として、基本情報D11および計画経路情報D12に対応する情報を保持している。したがって、計画経路設定部12は、これらの情報に基づいて、移動コードデータを1つ生成する。すなわち、生成される移動コードデータD1には、実績経路情報D13が含まれていないことになる。
【0051】
なお、移動コードデータの生成(S07)またはユーザ端末20による計画経路の選択(S06)を契機としてプラットフォーマサーバ10とユーザ端末20との間で、ユーザ端末20による計画経路に沿った移動に係る決済をプラットフォーマサーバ10が行うという契約を行ってもよい。一例として、ユーザ端末20は計画経路に沿った移動を行い、当該移動に伴って発生した費用についてはプラットフォーマサーバ10を経由して各交通事業者に対して支払うということを規定した契約を締結することとしてもよい。この場合、後段で説明する決済処理をプラットフォーマサーバ10が行うこととなる。また、上記のような契約を行う場合、一例として、計画経路を登録した段階でプラットフォーマサーバ10がユーザ端末20から計画経路に沿った移動を行った場合の費用を預かるという構成としてもよい。なお、上記のステップ(S06またはS07)を進めることが、費用決済に係る契約の締結を意味する場合には、事前に約款等でプラットフォーマサーバ10からユーザ端末20へ当該内容が通知されてもよい。
【0052】
ステップS08では、生成された移動コードデータがデータベース群30の移動コードデータベース32へ送られる。そして、ステップS09では、データベース群30の移動コードデータベース32において移動コードデータが保存される。なお、この際に、移動コードデータを作成したユーザに係る情報がユーザデータベース33に保存されてもよい。一例として、ユーザに係る情報には、例えば、ユーザの個人情報、決済に使用する口座等の決済関連情報、ユーザが利用しているポイントプログラムを特定する情報等が含まれる。
【0053】
ステップS10以降は、移動コードデータベース32に保存された移動コードデータを利用した処理の一例を示している。ステップS10では、事業者サーバ40が移動コードデータベース32に対してアクセスをすることで、移動コードデータを取得する。一例として、事業者サーバ40が特定の地域に係る広告を提供する事業者のサーバである場合、例えば、事業者サーバ40から移動コードデータベース32に対して問い合わせることで特定の地域を通過する計画経路が含まれている移動コードデータを取得する。上記は一例であり、事業者サーバ40が取得する移動コードデータの選択の方法は限定されず、移動コードデータに含まれるいずれかの情報を用いてデータの選択を行うことができる。
【0054】
ステップS11では、事業者サーバ40は、取得した移動コードデータを参照してターゲットとなるユーザ端末20を選定し、広告・交通情報等をプラットフォーマサーバ10に対して送信する。一例として、上記の特定の地域に係る広告を提供する事業者の場合には、当該地域を通過する計画経路を含む移動コードデータが保持されているユーザ端末20に対してプラットフォーマサーバ10を経由して広告データの配信をするようにプラットフォーマサーバ10に対して要求してもよい。また、事業者が例えば鉄道会社等の交通機関の管理者である場合には、当該交通機関を利用する計画経路を含む移動コードデータが保持されているユーザ端末20に対して、プラットフォーマサーバ10を経由して交通機関の運行情報の配信を要求してもよい。なお、これらの情報の提供はプラットフォーマサーバ10を経由せずに行うこともできる。また、事業者サーバ40からの広告・交通情報の提供は、対象となる移動コードデータの選択(S10)の後に行ってもよいし、移動コードデータの選択(S10)を省略してもよい。この場合、事業者サーバ40から広告・交通情報等の情報の配信条件を指定してプラットフォーマサーバ10に対して情報の配信を要求してもよい。
【0055】
ステップS12では、プラットフォーマサーバ10では、事業者サーバ40から取得した交通情報を保存する。この処理は省略してもよい。プラットフォーマサーバ10において交通情報を保存した場合、例えば、プラットフォーマサーバ10側の判断で、事業者サーバ40から指定されたユーザ端末20とは異なるユーザ端末20に対して交通情報を提供してもよい。また、一例として、検索部11において当該交通情報を保持し、経路検索を行うユーザ端末20に対して交通情報を同時に通知する構成としてもよい。
【0056】
ステップS13では、プラットフォーマサーバ10は、ユーザ端末20に対して広告・交通情報を通知する。一例として、プラットフォーマサーバ10の運行関連情報通知部13は、事業者サーバ40から指定された特定の経路を通る計画経路を設定したユーザ端末20に対して当該経路に係る交通情報を配信してもよい。交通情報の配信は、例えば、プラットフォーマサーバ10からのプッシュ通知等を利用して行ってもよい。
【0057】
なお、ステップS10~S13に示す手順は一例であって、適宜変更することができる。上述したように、移動コードデータベース32の検索および情報の取得(S10)を契機として、事業者サーバ40からユーザ端末20に対して直接情報を通知する構成としてもよい。また、経路コードデータの生成に係る一連の処理(S01~S09)に基づいて、プラットフォーマサーバ10の基準に基づいて特定のユーザ端末20に対して広告・交通情報の配信を行う構成としてもよい。
【0058】
なお、選択されたユーザ端末20に対して配信する交通情報には、例えば、計画経路に基づいた移動が困難なことを示す情報(例えば、遅延情報・不通情報)と、計画経路に対する代替案に係る情報とが含まれていてもよい。特に、プラットフォーマサーバ10とユーザ端末20との間で、計画経路に沿った移動に係るユーザの移動に係る費用の決済をプラットフォーマサーバ10が一括して行うような契約を締結している場合、プラットフォーマサーバ10は、交通手段を提供する事業者(事業者サーバ40)から当該計画経路に係る交通手段の運行情報を適切な時期に取得することが求められる。さらにプラットフォーマサーバ10は、取得した運行情報をユーザ端末20に対して通知し、必要に応じて計画経路の代替となる経路を提示する構成としてもよい。
【0059】
(実績経路の特定・決済・ポイント付与)
図6~
図11を参照しながら、ユーザ端末20の移動実績に基づく実績経路の特定と、特定された実績経路に基づく決済と、ユーザに対するポイント付与に係る処理とについて説明する。まず、
図6を参照しながら、ユーザ端末20の移動実績に基づく上記の処理の一連の流れを説明し、同時に各ステップで行われる処理の詳細について説明する。
【0060】
まず、ステップS21では、ユーザは例えば計画経路に沿って、出発地から目的地までの移動を行う。このとき、ユーザ端末20の移動ログ取得部23は、自端末の移動に伴った移動ログを取得する。移動ログとしては、上述のGPSを利用した位置情報のほか、所定の地点(例えば、駅、バス停、駐車場、交差点等)を通過したことを示す通過ログが含まれる。
【0061】
ステップS22では、ユーザ端末20の送信部24が、移動ログ取得部23で取得された移動ログをプラットフォーマサーバ10に対して送信する。上述したように、移動ログの送信タイミングは特に限定されず、例えば、目的地への移動が完了した後でもよいし、移動中でもよい。プラットフォーマサーバ10では、移動ログ取得部14がユーザ端末20からの移動ログを取得する。
【0062】
ステップS23では、プラットフォーマサーバ10の実績経路特定部15によって、ユーザ端末20が実際に移動した移動経路を特定する。具体的には、移動ログ(GPSの位置情報履歴)を地図データベース31にマップマッチングさせ、ユーザ端末20が実際に移動した道路や路線を特定する。一例では、ユーザ端末20のGPSの位置情報の履歴が地図データベース31のリンクAにある場合、ユーザ端末20はリンクAに対応する道路や路線を実際に移動したものとして特定する。さらに、ステップS24では、プラットフォーマサーバ10の実績経路特定部15によって、ユーザ端末20が実際に移動した経路を示す実績経路が確定される。具体的には、経路ルールデータベース16を用いて、ステップS23で特定した移動経路を適宜修正し、ユーザ端末20が実際に移動した道路や路線を確定させる。
【0063】
このように、実績経路特定部15による実績経路の確定には、経路ルールデータベース16において記憶されるルールが使用される。ここで、
図7および
図8を参照しながら、経路ルールデータベース16を用いた実績経路の特定方法について説明する。なお、
図7および
図8の経路ルールデータベース16を用いた実績経路の特定方法は一例に過ぎず、実績経路の特定方法は何らこれらに限定されない。
【0064】
図7では、ユーザ端末20が出発地Aから目的地Fまで、B,C,D地点を経由して移動した場合について説明する。
図7では、地図上に、出発地Aおよび目的地Fが示されている。また、A-F間には、ある鉄道のB,C,D,E駅が存在していたとする。さらに、B-E間には、並行する2つの路線(α、β)が走っていて、例えば、どちらの路線に乗ったかによって運賃が変わるとする。ここで、
図7に示すように、ユーザ端末20は、計画経路では、A-B-C-E-Fの予定であったが、実際はA-B-C-D-Fを辿っていたとする。また、移動ログに含まれる通過ログとして、B駅およびD駅で改札を通ったことを示す情報が取得されていたとする。このとき、プラットフォーマサーバ10の実績経路特定部15では、まず、移動ログのうちGPSによる位置情報に基づく移動経路を、地図データベース31に記憶されている地図情報と比較(いわゆるマップマッチング)して、ユーザ端末20の移動経路を推定する。この結果、ユーザ端末20の移動経路を、A-B-C-E-Fと特定したとする。ただし、E駅ではなくD駅で改札を通過したという通過ログが存在する場合、E駅ではなくD駅を利用したことが分かる。また、GPSによる位置情報からは、α、βのいずれの種別の路線を使用したかが特定し難く、通過ログからも特定ができないとする。このとき、実績経路特定部15は、例えば、計画経路において種別αの路線を使用することが特定されていることに基づいて、実績経路として、B-D間は種別αの路線を使用したことを確定する。
【0065】
上記の一連の手順では、まず、実績経路特定部15は、まず移動ログのうちGPSによる位置情報と地図データとの照合に基づいてユーザ端末20の移動経路を特定する。その後、例えば、通過ログや計画経路に含まれる情報に基づいて適宜補正を行う。このように、地図データに基づいて移動経路を特定した後に、通過ログや計画経路を利用して実績経路の確定を行っている。このような手順は、経路特定のルールとして定められていてもよい。
【0066】
図8では、ユーザ端末20が出発地Aから目的地Eまで、B,C,D地点を経由して移動した場合を示している。
図8では、地図上に、出発地Aおよび目的地Eが示されている。また、A-E間には、ある鉄道のB,C,D駅が存在していたとする。さらに、B-D間には、種別α(一例では、在来線)の路線が存在するが、B-C間にはそのほかに種別β(一例では、新幹線)の路線も存在するとする。ここで、
図8に示すように、ユーザ端末20は、実際はA-B-C-D-Eを辿っていたとする。GPSによる位置情報には、一般的に情報の取得日時が紐付けられている。今回の事例では、B駅付近でのGPS位置情報が10時に取得され、C駅付近でのGPS位置情報が10時15分に取得されたことを移動ログから特定できたとする。また、移動ログに含まれる通過ログとして、B駅およびD駅で改札を通ったことを示す情報が取得されていたとする。このとき、プラットフォーマサーバ10の実績経路特定部15では、まず、GPSによる位置情報に基づく移動経路を、地図データベース31に記憶されている地図情報と比較(いわゆるマップマッチング)して、ユーザ端末20の移動経路を特定する。この結果、B駅-D駅の間で鉄道を利用したことは特定することができたとする。ただし、B-C間ではどちらの種別を利用したかの特定ができなかったとする。ここで、この鉄道に係る時刻表情報を参照すると、B駅を10時に出発し、C駅に10時15分に到着する種別β(一例では、新幹線)の路線の電車が存在しており、C駅に10時15分に到着する種別α(一例では、在来線)の路線の電車が存在しないとする。この場合、時刻表情報に基づいて、実績経路として、B-C間は種別βの路線を使用したことを特定する。
【0067】
上記の一連の手順では、まず、実績経路特定部15は、まず移動ログと地図データとの照合に基づいてユーザ端末20の移動経路を特定する。その後、地図データとの照合および計画経路との比較によって特定が困難な部分の経路(ここでは、利用する交通手段の種別)は、例えば、時刻表情報等の交通手段が網羅されている情報を組み合わせて特定を行う。このように、地図データに基づいて経路を特定した後に、特定が困難な部分については、時刻表情報を参照して実績経路の確定を行っている。このような手順は、経路特定のルールとして定められていてもよい。
【0068】
このように、実績経路特定部15が実績経路を特定する際には、通過ログを含む移動ログ、計画経路、時刻表情報等を利用することができる。また、経路ルールデータベース16では、実績経路特定部15が使用できる各種情報に基づいて実績経路を特定するためのルールが保持される。一例として、実績経路を特定するためのルールは、実績経路特定部15が使用できる種々の情報のうち、経路の特定に使用する情報の優先順序を定めていてもよい。他の例として、一例として、実績経路を特定するためのルールは、実績経路特定部15が実績経路を特定する際に、データベース群30等を参照して取得する情報の種類を特定していてもよい。このように、実績経路を特定するためのルールは、実績経路特定部15が経路の特定を行う際に係る種々のルールを含んでいてもよい。
【0069】
図6に戻り、ステップS25では、プラットフォーマサーバ10の実績経路特定部15は、特定された実績経路に係る情報をデータベース群30の移動コードデータベース32に保持される移動コードデータに対して追加する。また、ステップS26では、移動コードデータに対してプラットフォーマサーバ10から送信された実績経路に係る情報が追加される。具体的には、
図4に示す移動コードデータD1のうち実績経路情報D13が追加されることになる。
【0070】
ステップS27では、プラットフォーマサーバ10の決済部19は、実績経路に基づく決済処理を行う。
【0071】
決済処理は、予め定められたプラットフォーマサーバ10とユーザ端末20との間の契約、または、プラットフォーマサーバ10と事業者(交通手段を提供する事業者)との間の契約に基づいて行われる。
図9では、決済処理に関する2種類の手順を示している。ここでは、上述したように、予めプラットフォーマサーバ10とユーザ端末20とに間で、計画経路に基づいてユーザ(ユーザ端末20)が移動した際に発生する費用をプラットフォーマサーバ10が一括して回収し、実際に使用した交通手段の運賃毎に分配する場合について説明する。
【0072】
まず、
図9(a)に示す手順では、ステップS31において、計画経路に基づきユーザ(ユーザ端末20)から当該経路に沿った移動に係る費用を回収する。「回収」とは、プラットフォーマサーバ10がユーザ端末20から費用を預かることを意味する。これは、例えば、ユーザが実際の移動を開始する前(一例として、計画経路の設定時)に行われていてもよい。次に、ステップS32において、プラットフォーマサーバ10の実績経路特定部15により、ユーザ端末20が実際に移動した後に、実績経路を特定する。その後、ステップS33において、プラットフォーマサーバ10の決済部19により、実績経路に含まれる交通手段間で、実績経路に基づいた費用の分配と差額の調整とを行う。なお、「差額の調整」には、不足分のユーザからの回収、計画経路における交通手段とは異なる代替交通手段を使用した場合の交通手段間での費用の調整等が含まれ得る。
【0073】
一方、
図9(b)に示す手順では、ステップS41において、計画経路に基づきユーザ(ユーザ端末20)から当該経路に沿った移動に係る費用を回収する。次に、ステップS42において、プラットフォーマサーバ10の決済部19により、回数した費用を計画経路に基づいて交通手段間で分配を行う。次に、ステップS43において、プラットフォーマサーバ10の実績経路特定部15により、ユーザ端末20が実際に移動した後に、実績経路を特定する。その後、ステップS44において、プラットフォーマサーバ10の決済部19により、実績経路に含まれる交通手段間で、先に分配した費用と実際にかかった費用との差額の調整を行う。
【0074】
図9(a)に示す手順と
図9(b)に示す手順とでは、ユーザ(ユーザ端末20)から回収した費用をどのタイミングで分配するかが異なる。
図9(a)に示す手順では、実績経路を特定(S32)した後に、実績経路に基づいて費用を分配している。一方、
図9(b)に示す手順では、計画経路に基づいて費用を分配し(S42)、その後に特定された実績経路に基づいた調整(S44)を行っている。何れの手順を採用する場合であっても、最終的にはユーザ(ユーザ端末20)の実績経路に基づいて費用の分配が行われる。
【0075】
図10を参照しながら、ユーザ端末20の計画経路と実績経路との差分に基づく差額の調整について説明する。
図10(a)は、あるユーザの計画経路を示している。一例として、ユーザは、A駅を8時に出発し、バスによってB空港まで移動する。その後B空港を9時に出発して飛行機でC空港に到着する。さらに、C空港を10時40分に出発してモノレールを利用してD駅に11時40分に到着する。上記のような計画経路に対して、
図10(b)、
図10(c)では、経路の一部が交通事情等によって変更となった例を示している。
【0076】
図10(b)では、上記A-B間の交通渋滞によって、バスを利用するとB空港から9時に出発できない状態を示している。このとき、ユーザは、バスに代えてタクシーを利用してB空港へ到着し、以降の行程は計画経路と同様に移動したとする。A-B間をバス移動からタクシー移動に切り替えた場合、運賃が800円から1800円に増額する。ただし、A-B間をバス移動からタクシー移動に切り替えたのは、ユーザの事情ではなく交通状況に基づく変更である。したがって、差額の調整は、ユーザからの回収ではなく、バス会社とタクシー会社の間で行われる。例えば、バス会社は計画経路に基づいてユーザから回収した800円を受け取らず、さらに、タクシー運賃との差額の1000円をタクシー会社へ支払う。一方、タクシー会社は、ユーザから回収している(バス運賃としての)800円と、バス会社からの1000円とを、タクシー運賃として受け取る。これにより、ユーザの実績経路に基づく費用の分配を行うことができる。
【0077】
図10(c)では、飛行機の遅延によって、C空港を10時40分に出発するモノレールにユーザが到着できない状況が発生したとする。このとき、ユーザが代替手段として10時50分にC空港を出発する鉄道を利用してD駅に到着したとする。また、この移動にかかった鉄道運賃は、モノレールの運賃と同額(600円)であったとする。C-D間をモノレール移動から鉄道移動に切り替えたのは、ユーザの事情ではなく交通事情に基づく変更である。したがって、差額の調整は、ユーザからの回収ではなく、交通機関に係る事業者間で行われる。この例の場合には、モノレールの運賃と鉄道の運賃とが同額であるため、ユーザから回収したモノレールの運賃がそのまま鉄道の運賃として鉄道会社に支払われる。なお、鉄道の運賃がモノレールの運賃よりも高額である場合には、例えば、交通手段の変更の原因となった飛行機を運航する航空会社に対して鉄道の運賃とモノレールの運賃との支払いを求めることにより、差額の調整をしてもよい。
【0078】
プラットフォーマサーバ10とユーザ端末20との間で、上記のように計画経路に基づいた移動を行うことに係る契約を締結し、当該移動に係る決済をプラットフォーマサーバ10が一括して行う場合、
図10に示すように、交通事情に基づく変更が発生した場合の調整はプラットフォーマサーバ10が主体的に行ってもよい。また、ユーザ(ユーザ端末20)側が交通事情に応じて主体的に経路を変更することをプラットフォーマサーバ10が許容する構成としてもよい。プラットフォーマサーバ10とユーザ端末20との関係は、事前に決める契約等に応じて適宜変更することができる。また、ユーザの計画経路と実績経路との差分によって生じる運賃の調整に関しては、プラットフォーマサーバ10を提供する事業者と、交通手段に係る事業者との間で予め定めておくことができる。
【0079】
図6に戻り、ステップS28では、プラットフォーマサーバ10のポイント管理部18は、実績経路に基づくポイント算出を行う。また、ステップS29では、プラットフォーマサーバ10のポイント管理部18は、算出されたポイントをユーザ端末20に対して付与する。一例として、ユーザ端末20に対して紐付けられるポイント数に対して付与するポイントを加算する処理を行う。この処理は、例えば、事業者サーバ40からの指示に基づいたルールに則って行われる。
【0080】
ユーザに対するポイントの付与は、例えば、ユーザの健康促進、特定の交通手段の利用の推進、特定の地域への訪問等を推奨することを目的として行われ得る。これらの目的は一例であって、これらに限定するものではない。ここでは、一例として、ユーザの健康促進を目的として、ユーザの徒歩移動時の歩数に応じてポイントを付与する場合の処理について説明する。ユーザの健康促進に対してポイントを付与する場合、ポイント付与に係るサービスを提供する事業者は、例えば自治体である。例えば、特定の地域に在住するユーザの徒歩移動に対して、自治体がポイントを付与し、さらにポイント数に応じたサービス(景品の授与等)を提供することで、当該地域のユーザの健康促進が期待される。
【0081】
図11では、ユーザ端末20の移動ログから特定された実績経路から、さらに徒歩移動に係るポイントを付与する際の手順を示している。
【0082】
まず、ステップS51では、プラットフォーマサーバ10のポイント管理部18は、ユーザ端末20の実績経路のうち、公共交通機関を使用していない区間を特定する。
図7、
図8等で説明したように、実績経路を特定する際に、鉄道等の公共交通機関を使用した区間を特定することができる。したがって、公共交通機関を使用した区間と特定されなかった区間が、非使用区間となる。
【0083】
ステップS52では、プラットフォーマサーバ10のポイント管理部18は、公共交通機関の非使用区間からポイント付与の対象となる区間を特定する。ユーザの徒歩移動に対してポイントを付与する場合には、ユーザが公共交通機関を使用していない区間のうち、徒歩移動とみなされる区間を特定する。徒歩移動とみなされる区間を特定する方法としては、例えば、ユーザ端末20の移動速度が徒歩移動に相当する速度である区間を特定する方法が挙げられる。具体的には、GPSの位置情報に基づいて移動速度を算出し、所定の移動速度以下(例えば、時速4.5km以下)の区間を徒歩移動区間として特定してもよい。また、徒歩移動区間を特定するためのサポート情報としてユーザ端末20の加速度センサの記録を移動ログとして取得する構成としてもよい。
【0084】
ステップS53では、プラットフォーマサーバ10のポイント管理部18は、ポイント付与区間に基づいて付与するポイントを算出する。例えば、徒歩移動時の歩数に応じてポイントを付与する場合には、例えば、徒歩移動区間の距離を一歩あたりの距離で割ることで歩数を算出することができる。これにより、歩数に応じた付与ポイントを特定することができる。
【0085】
ステップS54では、プラットフォーマサーバ10のポイント管理部18は、ユーザ端末20へのポイント付与処理を行う。一例として、ユーザ端末20に対して紐付けられるポイント数に対して付与するポイントを加算する処理を行う。
【0086】
上記のポイント付与に係る処理は、ポイントを付与する対象(付与条件)等に応じて変更され得る。また、ポイントを付与するための条件として、実績経路以外の情報(例えば、ユーザの属性)が含まれる場合には、それらの情報も加味した上で、ポイント付与に係る処理が行われる。
【0087】
(データのコンテンツ化およびコミュニケーションツールとしての活用)
図12および
図13を参照しながら、上記の一連の処理に基づいて得られたデータをプラットフォーマサーバ10がコンテンツとしてユーザに対して提供する場合の処理について説明する。ここでは、プラットフォーマサーバ10がユーザ端末20の移動ログに基づいて特定された実績経路をコンテンツ化し、他のユーザに対して提示する場合について説明する。すなわち、本実施形態における「コンテンツとしてユーザに対して提供する」とは、移動ログから特定されたあるユーザに係る実績経路を、他のユーザ(ユーザ端末20)が利用可能となる状態とすることをいう。また、あるユーザの実績経路を他のユーザが利用した場合には、コンテンツ化したユーザに対して対価(例えば、ポイント)を提供することで、プラットフォーマサーバ10の利用が促進され得るという側面がある。ここで、コンテンツ化とは、具体的には、経路をリンクデータとノードデータとで定義することをいう。このうち、リンクデータは、道路や路線を表すものであり、IDで管理され、道路の地理的な座標を含むデータである。また、ノードデータは、交差点や交通結節点を表すものであり、IDで管理され、交差点の地理的な座標を含むデータである。こうすることにより、コンテンツを利用する他のユーザは、コンテンツをダウンロードすることにより、直ちに対象の経路を特定することが可能となる。その意味では、本コンテンツ群は、他のユーザにとって候補経路であり、候補経路のうち他のユーザが選択した経路は計画経路といえる。
【0088】
図12は、コンテンツ化の一例として、あるユーザの実績経路を利用して、他のユーザが計画経路を作成するような状況を想定する。なお、以下の説明では、このような他のユーザの実績経路を利用して計画経路を作成することを実現するためのレイアウト情報等をプラットフォーマサーバ10が予め保持していることを前提とする。また、以下の説明では、2つのユーザ端末20A(ユーザ1)およびユーザ端末20B(ユーザ2)が存在することを想定する。
【0089】
まず、ステップS61では、ユーザ端末20Aの移動ログに基づく実績経路をプラットフォーマサーバ10において移動コードデータに登録する。このとき、ユーザ1は、ユーザ端末20Aを登録することで、実績経路に係る詳細の情報を登録してもよい。また、ユーザ端末20Aの指示によって、プラットフォーマサーバ10のコンテンツ管理部17は、この実績経路が他者によって利用可能となるように、コンテンツ化を行う。
【0090】
ステップS62では、ユーザ端末20Aのユーザとは異なるユーザが、ユーザ端末20Bにおいて検索条件に係る情報を入力する。ステップS63では、検索条件がプラットフォーマサーバ10へ送られ、経路検索がリクエストされる。そして、ステップS64では、プラットフォーマサーバ10の検索部11において検索条件に基づく計画経路の候補が選択される。
【0091】
ステップS65では、プラットフォーマサーバ10の検索部11が検索結果をユーザ端末20Bに対して提示する。このときに、プラットフォーマサーバ10は、コンテンツ管理部17によってコンテンツ化された状態でユーザ端末20Bに対して提示される。
図13(a)は、ユーザ端末20Bへの提示方法の一例である。
図13(a)に示す例では、3つの移動経路の候補(候補A~C)を出発地(S)から目的地(G)までそれぞれ地図上に表した状況を模式的に示している。また、候補A~Cはそれぞれ経由地の有無が分かるようになっていて、例えば、候補Aは地点Xを経由することが示されている。さらに、候補A~Cはそれぞれ作者(候補の経路となる実績経路を登録したユーザ)が示されていて、例えば、候補Aは作者1の実績経路に基づくものであることが示されている。このように、計画経路の候補を実績経路に基づいて提示をすることで、これから計画経路を選択するユーザ(ユーザ端末20B)にとっては視覚的にも候補の概略を把握することができる。
【0092】
さらに、計画経路の候補となる実績経路には、それぞれ詳細情報が含まれていてもよい。例えば、
図13(b)は、候補Aに係る経路の詳細情報の一例である。一例として、
図13(b)では、移動経路を示すとともに、経路の途中に関して作者であるユーザ1が登録した詳細情報が示されている。詳細情報としては、例えば、経路の説明が文章または画像で登録されていてもよい。また、経由地の地点Xについては、例えば、より詳細な情報が登録されていてもよい。さらに、詳細情報としては、ユーザ1が実際に行動した日付(または日時も含む)、移動に要した費用等が登録されていてもよい。このように、プラットフォーマサーバ10を利用するユーザが実際に移動した実績経路に基づく情報と、ユーザが登録したさらに詳細な情報を計画経路の候補として提示することしてもよい。
【0093】
ステップS66では、計画経路の候補を閲覧したユーザ2が候補の中から計画経路とする経路を選択する。ステップS67では、ユーザ端末20Bからプラットフォーマサーバ10に対して選択結果が送信される。ここでは、ユーザ1が作成した経路(候補Aに相当)がユーザ2によって計画経路として選択されたとする。
【0094】
ステップS68では、プラットフォーマサーバ10において、計画経路に対応する移動コードデータが作成される。移動コードデータは、ユーザ1の実績経路に基づいて生成されてもよい。また、ステップS69では、ユーザ2が計画経路に基づいた移動をすることで、ユーザ端末20Bにおいて移動ログが取得される。そして、ステップS70では、ユーザ端末20Bにおいて取得された移動ログに基づいて実績経路が確定される。これらの手順は、上記実施形態で説明した手順と同様である。
【0095】
ステップS71では、ユーザ2がユーザ端末20Bを操作し、プラットフォーマサーバ10のコンテンツ管理部17と通信を行うことで、実績経路に基づいた新規コンテンツを作成する。一例として、
図13(b)に示した例に類する情報を登録することで、別のユーザが計画経路を選択する際の候補として提示することが可能となる。
【0096】
以降のステップは、上記のコンテンツの活用を促進するための処理の一例である。ステップS72では、プラットフォーマサーバ10のコンテンツ管理部17において、ユーザ1の作成した経路Aを評価するカウント(例えば、当該コンテンツを利用したユーザの数を示す情報)を付与する。例えば、コンテンツ管理部17では、計画経路の候補を閲覧したユーザが、当該候補を計画経路として選択し、さらに計画経路に基づいた実績経路が登録された場合に、計画経路の元となるコンテンツを登録したユーザ(ここでは、ユーザ1)に対してカウントを与えるというルールを決めておいてもよい。そして、上記のルールに基づいてプラットフォーマサーバ10を利用するユーザの行動に基づいて所定のカウントを与えてもよい。
【0097】
ステップS73では、プラットフォーマサーバ10のポイント管理部18が、コンテンツ中でカウントされたカウント数に応じて、ユーザ端末20Aに対して付与するポイント数を算出する。一例として、カウント数と同数のポイントを付与する構成としてもよいし、所定のルールに基づいてカウント数をポイント数に換算する処理を行ってもよい。
【0098】
ステップS74では、プラットフォーマサーバ10のポイント管理部18がユーザ端末20Aに対するポイント付与処理を行う。ポイント付与に係る処理の手順は上述した手順と同様とすることができる。
【0099】
このように、ユーザ端末20からの移動ログに基づいて作成された実績経路に対して、必要に応じてさらなる情報を追加してコンテンツ化し、他のユーザに提示する計画経路として提示する構成とすることで、プラットフォーマサーバ10の利用者(ユーザ)が継続してプラットフォーマサーバ10を利用することが促進され得る。また、単なる計画経路の提示と比較して、ユーザ発信の補足情報等が追加された状態で他のユーザに対して提示をすることが可能となり、ユーザにとっても利便性が高まる可能性がある。
【0100】
なお、コンテンツ化する際に、ユーザ間のコミュニケーションを活発化させること等を目的として、他のユーザが登録した実績経路(計画経路として利用され得るコンテンツ)に対してコメント等を追加する機能等を設けてもよい。また、公知のSNS(Social Networking Service)で用いられている各種機能を追加してもよい。
【0101】
[プログラム]
コンピュータ110をプラットフォーマサーバ10として機能させるためのプログラムは、コンピュータ110を検索部11、計画経路設定部12、運行関連情報通知部13、移動ログ取得部14、実績経路特定部15、経路ルールデータベース16、コンテンツ管理部17、ポイント管理部18、および決済部19として機能させるためのプログラムコードを含む。コンピュータ110をユーザ端末20として機能させるためのプログラムは、コンピュータ110を計画経路選定部21、運行関連情報取得部22、移動ログ取得部23、送信部24、および表示部25として機能させるためのプログラムコードを含む。それぞれのプログラムは、CD-ROM、DVD-ROM、半導体メモリなどの非一時的な記録媒体に固定的に記録された上で提供されてもよい。あるいは、それぞれのプログラムは、搬送波に重畳されたデータ信号として通信ネットワークを介して提供されてもよい。提供されたプログラムはストレージ103に記憶される。プロセッサ101がメモリ102と協働してそのプログラムを実行することで、対応する機能モジュールが実現する。
【0102】
[作用]
以上説明したように、本開示の一側面に係るサーバ装置はプロセッサを備える。プロセッサは、ユーザの移動に係るログ情報を取得し、ユーザの移動経路を特定するためのルールを示す所与のルールデータに基づいて、ユーザが実際に移動した実績経路を特定する。
【0103】
本開示の一側面に係るプログラムは、ユーザの移動に係るログ情報を取得するステップと、ユーザの移動経路を特定するためのルールを示す所与のルールデータに基づいて、ユーザが実際に移動した実績経路を特定するステップと、をサーバ装置に実行させる。
【0104】
このような側面においては、ログ情報から実績経路を特定する際に、ルールデータに基づいて実績経路が特定される。そのため、ルールデータに基づいてユーザが実際に移動した経路をより高い精度で特定することができる。
【0105】
他の側面に係るサーバ装置では、ルールデータが、ユーザが移動する前に作成されたユーザの計画経路に基づいてユーザの移動経路を特定するルールを示し、プロセッサが、ユーザが移動する前に作成されたユーザの計画経路を取得し、ルールデータに基づいて実績経路を特定する。この場合、ユーザの計画経路に基づいた実績経路の特定が可能となり、より高い精度での特定が可能となる。
【0106】
他の側面に係るサーバ装置では、ルールデータが、ユーザが特定の場所を通過したことを特定することができる通過ログに基づいてユーザの移動経路を特定するルールを示し、プロセッサが、ログ情報としてユーザの通過ログを取得し、ルールデータに基づいて実績経路を特定する。この場合、ユーザが特定の場所を通過したことを特定することができる通過ログに基づいた実績経路の特定が可能となり、より高い精度での特定が可能となる。
【0107】
他の側面に係るサーバ装置では、ルールデータが、ユーザが利用し得る交通手段の運行時刻を示す情報に基づいてユーザの移動経路を特定するルールを示し、プロセッサが、ルールデータに基づいて実績経路を特定する。この場合、ユーザが利用し得る交通手段の運行時刻を示す情報に基づいた実績経路の特定が可能となり、より高い精度での特定が可能となる。
【0108】
他の側面に係るサーバ装置では、プロセッサが、特定された実績経路に基づいて、ユーザの移動に要した費用の決済処理を行う。この場合、高い精度で特定された実績経路に基づいて決済処理を行うことができ、サーバ装置を使用するユーザの利便性が高められる。
【0109】
[変形例]
以上、本開示をその実施形態に基づいて詳細に説明した。しかし、本開示は上記実施形態に限定されるものではない。本開示は、その要旨を逸脱しない範囲で様々な変形が可能である。
【0110】
[変形例1]
上記実施形態のうち、
図11を用いて説明したポイント付与について、ユーザ端末20(ユーザ)の徒歩移動に対してのみポイントを付与する場合について説明したが、これに限られない。例えば、自転車での移動、自家用車での移動、バスでの移動、電車での移動など、徒歩以外のユーザ端末20の移動について任意のポイントを付与することとしてもよい。一例では、徒歩で2km移動する毎にユーザ端末20に対して100ポイントを付与するものとし、自転車で2km移動する毎にユーザ端末20に対して50ポイントを付与するものとしてもよい。また、自家用車で2km移動する毎にユーザ端末20に対して10ポイントを付与するものとし、バスまたは電車で2km移動する毎にユーザ端末20に対して30ポイントを付与するものとしてもよい。このように、移動手段と移動距離に応じて任意のポイントを付与するものとすることができる。また、付与するポイント数は、移動手段毎に予め設定した「倍率」に比例して行ってもよい。一例では、倍率は、自家用車「1」、バス「3」、電車「3」、自転車「5」、徒歩「10」とすることが考えられる。このように、移動手段毎にポイント付与率を異ならせることで、プラットフォーマサーバ10は、付与率が高い移動手段を選択するようにユーザを誘導することが可能となる。なお、倍率は、日時や時刻、季節の少なくとも一つによって変更してもよい。
【0111】
ユーザ端末20が使用した移動手段を判別する方法は、たとえば、複数のネットワークとユーザ端末20のログ情報とのマッチングに応じて移動手段を判別するものとしてもよい。すなわち、地図データベース31は、徒歩ネットワークデータ、自転車ネットワークデータ、自動車ネットワーク、バスネットワーク、電車ネットワークの各種の移動手段に関するネットワークデータを含む。そして、ユーザ端末20のGPSのログ情報と各種ネットワークデータをマップマッチングさせ、いずれの経路を移動したかで移動手段を判別するのである。一例では、ユーザ端末20のログ情報が徒歩ネットワーク上にある場合、そのユーザ端末20の移動手段は徒歩であると判別する。ユーザ端末20のログ情報が自転車ネットワーク上にある場合、そのユーザ端末20の移動手段は自転車であると判別する。ユーザ端末20のログ情報が自動車ネットワーク上にある場合、そのユーザ端末20の移動手段は自動車であると判別する。ユーザ端末20のログ情報がバスネットワーク上にある場合、そのユーザ端末20の移動手段はバスであると判別する。ユーザ端末20のログ情報が電車ネットワーク上にある場合、そのユーザ端末20の移動手段は電車であると判別する。この場合、判別の精度を上げるために、ユーザ端末20の移動速度を算出し、補完してもよい。例えば、ユーザ端末20の移動速度が時速4.5kmの場合、そのユーザ端末20の移動手段は徒歩であると判別する。ユーザ端末20の移動速度が時速10km-20kmである場合、そのユーザ端末20の移動手段は自転車であると判別する。ユーザ端末20の移動速度が時速30km-80kmである場合、そのユーザ端末20の移動手段は自動車、バス、電車のいずれかであると判別する。また、ユーザの計画経路、ユーザの通過ログ(例えば、改札等の経由地)、公共交通機関の時刻表の少なくとも一つを用いて補完してもよい。
【0112】
ポイント付与は、ユーザ端末20の移動だけに限らず、所定スポットに立ち寄った場合に行ってもよい。ここで、所定スポットとは、典型的には、飲食店や雑貨店、テーマパークなどの商業施設、博物館、美術館、図書館、学校などの公共施設であるが、これに限らず、上述した地上に存在する任意の有体物または無体物である。所定ステップが博物館、美術館、図書館、学校などの施設の場合には、当該施設への立ち寄りがポイント付与に繋がることから、ユーザ端末20に対して、学習へのモチベーションを高めることができる。その意味では、工場など民間施設や、石碑や城跡、古墳などもポイント付与の対象となるスポットとして好適である。このように、所定スポットへの立ち寄りにポイントを付与することで、プラットフォーマサーバ10は、所定スポットに立ち寄るようにユーザを誘導することが可能となる。付与するポイント数は、所定スポットに滞在した滞在時間に比例して行ってもよい。また、スポット毎に異ならせてもよいし、立ち寄り日時や時刻、季節の少なくとも一つによって変更してもよい。プラットフォーマサーバ10からユーザ端末20に対して、所定スポットに関する情報を配信し、ユーザ端末20の回答内容に応じてポイントを追加するようにしてもよい。
【0113】
ユーザ端末20が立ち寄ったスポットを判別する方法は、たとえば、複数のポリゴンデータとユーザ端末20のログ情報とのマッチングに応じてユーザの立寄ったスポットを判別するものとしてもよい。すなわち、地図データベース31は、各スポットが存在する敷地に対応するポリゴンデータを含む。そして、ユーザ端末20のGPSのログ情報とポリゴンデータをマップマッチングさせ、当該ログ情報とポリゴンデータとの内外判定により、立ち寄ったスポットを判別するのである。一例では、ユーザ端末20のログ情報が特定のスポットの敷地に対応するポリゴンデータ上にある場合、そのユーザ端末20はその特定のスポットに立ち寄ったと判別する。この場合、判別の精度を上げるために、ユーザの計画経路、ユーザの通過ログを用いて補完してもよい。なお、立ち寄ったスポットを判別する手段は、ポリゴンデータを用いたものに限らず、ジオフェンスを用いたものであってもよい。ジオフェンスとは、各スポットが存在する敷地に対応させて、仮想の境界線を定義し、その圏内への出入りを検出することで、立ち寄ったスポットを判別するのである。
【0114】
さらに、特定の地域をテーマパークとみなして、特定テーマに沿った特定地域内の移動、スポット立ち寄りにポイントを付与するようにしてもよい。ここで、テーマは、観光、健康、学習体験など種々考えられる。テーマが学習体験の場合には、上述の博物館、美術館、図書館、学校、工場、石碑、城跡、古墳などの施設を、ポイント付与の対象となるスポットと設定することが考えられる。この場合、参加者としてのユーザ端末20は、学習体験にあたり、チケットを購入し、学習体験後には、コメントや写真、動画を残すようにしてもよい。この場合、チケット購入、コメント付与等に対して、それぞれポイントを付与するようにしてもよい。
【0115】
ユーザ端末20が獲得したポイントに関する情報を、学習体験への参加者間で共有するようにしてもよい。この場合、獲得したポイント数をランキング形式で表示すれば、さらに学習意欲を高めることが可能である。ランキング上位者には、プラットフォーマサーバ10からお土産をプレゼントしてもよい。また、獲得したポイントに応じて、その地域のみで使える地域通貨を付与してもよい。
【0116】
ユーザ端末20が使用した移動手段は、複数の交通機関における移動ログに含まれる通過ログから判別してもよい。例えば、
図8のユーザ端末20が出発地Aから目的地Eまで、B、C、D地点を経由する場合において、ユーザ端末20がB駅において種別α(一例では、在来線)から種別β(一例では、新幹線)に至る改札を通過したという通過ログが存在する場合、ユーザ端末20の移動手段は種別β(一例では、新幹線)であると判別する。
また、ユーザ端末20がC駅において種別β(一例では、新幹線)から種別α(一例では、在来線)に至る改札を通過したという通過ログが存在する場合、ユーザ端末20の移動手段は種別α(一例では、在来線)であると判別する。また、ユーザ端末20が出発地Aから目的地GまでF地点を経由する場合において、ユーザ端末20がF地点において種別γ(一例では、モノレール)から種別Δ(一例では、飛行機)に至る改札を通過したという通過ログが存在する場合、ユーザ端末20の移動手段は種別Δ(一例では、飛行機)であると判別する。
【0117】
[変形例2]
上記実施形態では、ユーザ端末20が、プラットフォーマサーバ10を利用して経路検索を行った後に計画経路をプラットフォーマサーバ10へ送信する。ただし、計画経路は、プラットフォーマサーバ10を用いた経路検索とは異なる方法で作成されていてもよい。例えば、ユーザ端末20が利用可能な他のサービス等を利用して作成した計画経路をプラットフォーマサーバ10に対して登録することで、プラットフォーマサーバ10が提供するサービスを利用してもよい。
【0118】
[変形例3]
上記実施形態ではデータベース群30を示すが、各データベースのコピーがプラットフォーマおよび複数の事業者のそれぞれに配置されてもよい。この場合には、プラットフォーマおよび複数の事業者の間でデータベースの同期が実行され、これにより各種のデータの整合性が保証される。抽象経路データを記憶するシステムにおいて、ブロックチェーン技術ないし分散型台帳技術が適用されてもよい。
【0119】
[変形例4]
本開示において、第1コンピュータが第2コンピュータ“に向けて”データまたは情報を送信するとは、第1コンピュータが、直接に、または少なくとも一つの通信装置を介して(すなわち間接的に)、第2コンピュータにデータまたは情報を送信することを意味する。
【0120】
[変形例5]
本開示において、「少なくとも一つのプロセッサが、第1の処理を実行し、第2の処理を実行し、…第nの処理を実行する。」との表現、またはこれに対応する表現は、第1の処理から第nの処理までのn個の処理の実行主体(すなわちプロセッサ)が途中で変わる場合を含む概念を示す。すなわち、この表現は、n個の処理のすべてが同じプロセッサで実行される場合と、n個の処理においてプロセッサが任意の方針で変わる場合との双方を含む概念を示す。
【0121】
[変形例6]
コンピュータシステム内で二つの数値の大小関係を比較する際には、「以上」および「よりも大きい」という二つの基準のどちらを用いてもよく、「以下」および「未満」の二つの基準のうちのどちらを用いてもよい。このような基準の選択は、二つの数値の大小関係を比較する処理についての技術的意義を変更するものではない。
【0122】
[変形例7]
少なくとも一つのプロセッサにより実行される方法の処理手順は上記実施形態での例に限定されない。例えば、上述したステップ(処理)の一部が省略されてもよいし、別の順序で各ステップが実行されてもよい。また、上述したステップのうちの任意の2以上のステップが組み合わされてもよいし、ステップの一部が修正または削除されてもよい。あるいは、上記の各ステップに加えて他のステップが実行されてもよい。
【0123】
以上の実施形態の全部または一部に記載された態様は、移動経路に関する制御、処理速度の向上、処理精度の向上、使い勝手の向上、データを利用した機能の向上または適切な機能の提供その他の機能向上または適切な機能の提供、データおよび/またはプログラムの容量の削減、装置および/またはシステムの小型化等の適切なデータ、プログラム、記録媒体、装置および/またはシステムの提供、並びにデータ、プログラム、装置またはシステムの制作・製造コストの削減、制作・製造の容易化、制作・製造時間の短縮等のデータ、プログラム、記録媒体、装置および/またはシステムの制作・製造の適切化のいずれか一つの課題を解決する。
【符号の説明】
【0124】
1…情報管理システム、10…プラットフォーマサーバ、11…検索部、12…計画経路設定部、13…運行関連情報通知部、14…移動ログ取得部、15…実績経路特定部、16…経路ルールデータベース、17…コンテンツ管理部、18…ポイント管理部、19…決済部、20,20A,20B…ユーザ端末、21…計画経路選定部、22…運行関連情報取得部、23…移動ログ取得部、24…送信部、25…表示部、30…データベース群、31…地図データベース、32…移動コードデータベース、33…ユーザデータベース、34…広告データベース、40…事業者サーバ。