JP2022064058A - サーバ装置およびプログラム - Google Patents

Abstract

【課題】ユーザが実際に移動した経路をより高い精度で特定するコンピュータシステム、処理方法、プログラム及び／又はデータ構造を提供する。【解決手段】経路データを管理する情報管理システムにおいて、プラットフォーマサーバがプロセッサを備える。プロセッサは、ユーザの移動に係るログ情報を取得し、ユーザの移動経路を特定するためのルールを示すルールデータに基づいて、ユーザが実際に移動した実績経路を特定する。情報管理システムは、任意の事業者にに対して、ユーザに係る経路データを提供し、事業者は、特定された移動実績を利用して広告提供等の各種サービスを提供する。【選択図】図３

Description

本開示の一側面はコンピュータシステム、処理方法、プログラム、および／またはデータ構造に関する。

特許文献１には、ユーザの現在位置、移動速度等の移動に係るログ情報から、ユーザの移動手法を特定し、特定した移動手法に基づいてユーザに対してポイントを付与する方法が開示されている。

特許第５９１１３８８号

本開示の一側面は、ユーザの移動に係るログ情報から、ユーザが実際に移動した実績経路をより高い精度で特定することを目的とする。

本開示の一側面に係るサーバ装置はプロセッサを備える。プロセッサは、ユーザの移動に係るログ情報を取得し、ユーザの移動経路を特定するためのルールを示す所与のルールデータに基づいて、ユーザが実際に移動した実績経路を特定する。

図１は、実施形態に係る情報管理システムの適用の一例を示す図である。 図２は、実施形態に係る情報管理システムで用いられるコンピュータのハードウェア構成の一例を示す図である。 図３は、実施形態に係る情報管理システムの機能構成の一例を示す図である。 図４は、移動コードデータの一例を示す図である。 図５は、移動コードデータの作成および保存に係る処理の一例を示すシーケンス図である。 図６は、実績経路の特定及び決済処理の一例を示すシーケンス図である。 図７は、実績経路の特定方法の一例を示す図である。 図８は、実績経路の特定方法の一例を示す図である。 図９（ａ）、図９（ｂ）は、決済処理の一例を示すフローチャートである。 図１０（ａ）、図１０（ｂ）、図１０（ｃ）は、計画経路からの変更の一例を示す図である。 図１１は、ポイント付与に係る処理の一例を示すフローチャートである。 図１２は、実績経路のコンテンツ化に係る処理の一例を示すシーケンス図である。 図１３（ａ）、図１３（ｂ）はコンテンツ化の一例を示す図である。

以下、添付図面を参照しながら本開示での実施形態を詳細に説明する。図面の説明において同一または同等の要素には同一の符号を付し、重複する説明を省略する。

［システムの概要］
実施形態に係る情報管理システム１は、ユーザの移動経路を示す経路データを管理するコンピュータシステムである。移動経路とは、現実世界における或る地点から別の地点までの移動に関する情報をいい、典型的には出発地から目的地までの移動に関する情報をいう。出発地とは、移動経路を検索するための始点として設定される場所をいい、目的地とはその検索のための終点として設定される場所をいう。出発地および目的地はいずれも経路検索の基準点となり得る場所である。一例では、移動経路は、出発地から目的地までの経路だけでなく、その経路の属性（以下では「経路属性」という）も示すことができる。経路属性とは、経路の性質、特徴、状況、あるいは、経路を移動するユーザの情報（年齢、性別、国籍、体調など）を表す任意の情報である。例えば、経路属性は、交通機関などの移動手段と、経路を移動する日時と、経路を移動するための所要時間または費用と、経路の状況（例えば交通情報）と、経路に関連する地物（すなわち地物情報）と、経路に関連する事業者（すなわち事業者情報）と、経路に関連するサービス情報（例えば広告情報、クーポン情報など）と、経路を移動するユーザに関する情報（年齢、性別、国籍、体温、心拍数、発汗量、血糖値、カロリー消費量など）と、経路を移動するユーザの目的情報（ビジネス、観光、買い物、健康、暇つぶしなど）とのうちの少なくとも一つを含んでもよい。経路データとは移動経路を示す電子データであり、典型的には緯度経度情報で表される時系列の点列座標であるが、これに限られない。経路データにおいて、リンクおよびノードから構成されるネットワークデータに点列座標を照合して得られるリンクＩＤおよびノードＩＤが用いられてもよい。経路データは、経路を移動する日時（時刻）を示すテキストデータを含んでもよい。時刻に関するテキストデータは、リンクＩＤおよびノードＩＤに関連付けられてもよい。ユーザとは自己の経路データを情報管理システム１に提供する人をいう。ユーザは個人でもよいし複数人から成るグループでもよい。

移動手段とは、移動するための方法をいう。移動手段は移動体に限定されず、移動体を用いない方法も含む概念である。移動手段は公共交通機関でもよいし、ユーザが自分で操作する移動体でもよい。移動手段は、地上または地下の移動体でもよいし、空中の移動体でもよいし、水上または水中の移動体でもよい。移動手段の例として徒歩、自転車、バイク、自家用車、バス、タクシー、在来線、高速鉄道、航空機、ドローン、およびフェリーが挙げられるが、当然ながら移動手段はこれらに限定されるものではない。

公共交通機関とは、運行する経路および時刻が決まっており、且つ不特定の一般の人々が共同で利用する交通機関をいう。公共交通機関の例として鉄道（モノレール等を含む）、路面電車、路線バス、航空機、フェリーなどが挙げられるが、公共交通機関はこれらに限定されない。タクシーは公共交通機関ではない。

経路データによって示される移動経路の種類は限定されない。経路データは、候補として検索された移動経路、ユーザにより選択された移動経路、またはユーザにより実際に利用された移動経路を示してもよい。本開示では、候補として検索された移動経路を「候補経路」といい、１以上の候補経路の中からユーザにより選択された移動経路を「計画経路」といい、ユーザにより実際に利用された移動経路を「実績経路」という。一の移動経路が候補経路、計画経路、および実績経路のうちの２以上に該当することがあり得る。

地物とは、地上に存在する任意の有体物または無体物である。地物は自然物でも人工物でもよい。例えば、地物は、山地、農地、住宅地、更地、河川、湖、海、観光地、道路、鉄道、建物、公園、塔、信号機、踏切、横断歩道、歩道橋、浮標などを含み得る。無体物である地物の例として、任意の目的で設定された区域（例えば、撮影禁止区域、一時的な進入禁止区域など）、イベントが開催される区域、集合場所、撮影スポットなどが挙げられる。当然ながら、地物の種類はこれらに限定されない。

情報管理システム１によって管理される１以上のユーザの経路データは任意の目的のために利用され得る。例えば、経路データは、「サービスとしての移動」（Ｍｏｂｉｌｉｔｙ ａｓ ａ Ｓｅｒｖｉｃｅ（ＭａａＳ））、都市計画、交通計画、環境対策、防災対策、防犯対策、需要予測、マーケティング、人流解析などの、人々の生活または地球環境の維持もしくは改善に役立つ様々な目的のために利用されてよい。経路データは任意の事業者および他のユーザによって利用され得る。事業者の例として、鉄道、ロープウェー、バス、タクシー、飛行機、ドローン、船舶などの各種の交通機関の事業者と、自動車、自転車などの各種の移動手段のレンタル事業者と、配車サービスの事業者と、ショッピング、レストラン、駐車場などの各種施設を運営する事業者と、広告、クーポンなどの各種情報を提供する事業者と、決済事業者と、国または自治体の各種の組織とが挙げられる。事業者には、個人事業主も含まれ得る。

一例として、情報管理システム１がユーザに対して「サービスとしての移動」（Ｍｏｂｉｌｉｔｙ ａｓ ａ Ｓｅｒｖｉｃｅ（ＭａａＳ））を提供するとする。ここでは、サービスの１つとして、例えば、情報管理システム１が、ユーザの移動経路に係る経路データを管理し、ユーザの移動に応じて発生する運賃の決済等を管理するとする。この場合、ユーザの移動実績に対応する経路データを情報管理システム１では把握する必要がある。特に、情報管理システム１においてユーザの移動実績に基づいた決済処理またはポイント付与等を行う場合、ユーザの移動実績を正確に把握することが求められる。そこで、情報管理システム１では、移動経路を高い精度で特定するためのルールを予め保持し、当該ルールに基づいてユーザの移動ログから移動実績（実績経路）を精度よく特定する。また、情報管理システム１は、より高い精度で特定された移動実績を利用して、各種サービスを提供する。

また、一例では、情報管理システム１は、ユーザに対して経路探索機能を提供してもよい。また、ユーザが経路探索機能を利用すること等によって特定した、将来に使用し得る移動経路（計画経路）に係る経路データを取得してもよい。ユーザから取得した計画経路は、移動実績の特定に利用され得る。

一例では、情報管理システム１は、様々な目的で用いられ得る経路データを統括的に制御または管理するプラットフォームとしての役割を果たし得る。これに関連して、情報管理システム１の管理者または運営者はプラットフォーマであり得る。一例では、情報管理システム１は任意の事業者に対して、ユーザに係る経路データ（計画経路・実績経路）を提供することができる。事業者はその経路データに基づいて広告提供等のサービスを行ってもよい。

［システムの構成］
図１は情報管理システム１の適用の一例を示す図である。一例では、情報管理システム１はプラットフォーマサーバ１０および１以上のユーザ端末２０を備える。プラットフォーマサーバ１０および個々のユーザ端末２０は通信ネットワークＮＷを介して互いにデータを送受信することができる。プラットフォーマサーバ１０は通信ネットワークＮＷを介してデータベース群３０にアクセスしてデータを読み取ったり書き込んだりすることができる。データベース群３０に記憶されたデータの少なくとも一部は、通信ネットワークＮＷを介して１以上の事業者サーバ４０によってアクセスされ得る。

プラットフォーマサーバ１０（サーバ装置）は経路データを収集するコンピュータである。プラットフォーマサーバ１０として機能するコンピュータは限定されない。一例では、プラットフォーマサーバ１０は業務用サーバなどの大型のコンピュータによって構成される。プラットフォーマサーバ１０は一つまたは複数のコンピュータにより構成され得る。複数のコンピュータが用いられる場合には、通信ネットワークを介してこれらのコンピュータが互いに接続されることで論理的に一つのプラットフォーマサーバ１０が構成される。

ユーザ端末２０はユーザによって操作されるコンピュータである。一例では、ユーザ端末２０は、プラットフォーマサーバ１０にアクセスしてプラットフォーマサーバ１０が提供する経路データを利用した各種サービスに係るデータを取得することができる。本実施形態では、本発明の一側面に係る端末をユーザ端末２０に適用する。ユーザ端末２０は固定端末でもよいし携帯端末でもよい。ユーザ端末２０の例として、携帯電話機、スマートフォン、タブレット端末、ウェアラブル端末、およびパーソナルコンピュータなどのデバイスが挙げられる。しかし、ユーザ端末２０の種類はこれらに限定されない。ユーザ端末２０は、一つの筐体から構成されるデバイスでもよいし、複数のデバイスによって構成されてもよい。例えば、ユーザ端末２０はウェアラブル端末とスマートフォンとの組合せでもよい。この場合には、ウェアラブル端末がユーザの移動経路に係る移動ログを取得し、そのデータをスマートフォンに送信する。スマートフォンはウェアラブル端末において取得された移動ログをプラットフォーマサーバ１０に送信する。情報管理システム１にアクセスするユーザ端末２０の台数は限定されない。

データベース群３０は、情報管理システム１において用いられるデータを記憶するデータベースの集合である。一例では、データベース群３０は地図データベース３１、移動コードデータベース３２、ユーザデータベース３３、および広告データベース３４を含む。それぞれのデータベースは情報管理システム１の一部として構築されてもよいし、情報管理システム１とは別のコンピュータシステムに設けられてもよい。地図データベース３１は、地図を構成する地図要素を示す地図データを永続的に記憶する非一時的な記憶媒体または記憶装置である。移動コードデータベース３２は、プラットフォーマサーバ１０で取り扱う経路データを永続的に記憶する非一時的な記憶媒体または記憶装置である。ユーザデータベース３３は、プラットフォーマサーバ１０を使用するユーザ毎のユーザデータを永続的に記憶する非一時的な記憶媒体または記憶装置である。広告データベース３４は広告データを永続的に記憶する非一時的な記憶媒体または記憶装置である。

事業者サーバ４０は事業者によって管理または運用されるコンピュータである。一例では、事業者サーバ４０は移動コードデータベース３２にアクセスして移動コードデータを取得することができる。また、事業者サーバ４０は広告データベース３４にアクセスして広告データを保存することができる。事業者サーバ４０として機能するコンピュータは限定されない。例えば、事業者サーバ４０は業務用サーバなどの大型のコンピュータによって構成されてもよいし、パーソナルコンピュータによって構成されてもよい。情報管理システム１にアクセスする事業者サーバ４０の台数は限定されない。

一例では、情報管理システム１では、ユーザ端末２０は自端末の移動に係る経路データをプラットフォーマサーバ１０に向けて送信する。送信のタイミングは、典型的にはユーザが目的地に到着した後であるが、目的地に到着する前でもよい。また、移動経路の種類が計画経路または候補経路である場合には、送信のタイミングはユーザが出発地から移動を開始する前でもよい。移動経路の種類が実績経路である場合でも、ユーザ端末２０は、目的地に到着する途中までの実績経路をそのタイミングで送信してもよい。

一例では、プラットフォーマサーバ１０は、経路データを取得すると、移動コードデータを生成する。そして、移動コードデータを移動コードデータベース３２に登録する。移動コードデータは、ユーザ端末２０から取得した１つの計画経路毎に１つ生成される。また、プラットフォーマサーバ１０がユーザ端末２０から計画経路を取得した後、ユーザ端末２０から当該計画経路に対応する実績経路に係る経路データを取得した場合には、プラットフォーマサーバ１０は、当該経路データを、作成済みの移動コードデータに追加する。また、作成済みの移動コードデータが存在しない、すなわちユーザ端末２０において予め計画経路が作成されず、ユーザが移動した実績経路に係る経路データをユーザ端末２０から取得した場合には、プラットフォーマサーバ１０は、新たに移動コードデータを生成して移動コードデータベース３２に登録してもよい。このように、プラットフォーマサーバ１０は、ユーザ端末２０の１回の移動に対して１つの移動コードデータを生成し、移動コードデータベース３２へ登録する。

一例では、情報管理システム１では、ユーザ端末２０から移動実績に係る移動ログ（ログ情報）を取得した場合には、当該経路データからユーザ端末２０から実際に通った経路（実績経路）を特定する。ここで、実績経路を特定するとは、ユーザが実際に通った道路や路線に関する情報を取得することを意味する。広義には、実績経路を特定するとは、徒歩、自転車、自家用車、バス、電車など、ユーザが移動に際して実際に使用した移動手段に関する情報を取得することを意味する。ログ情報は、移動経路に係る経路データを含む。ユーザ端末２０において予め計画経路を作成していた場合でも、道路状況・公共交通の運行状況等によって計画経路から変更した経路でユーザが移動する場合がある。情報管理システム１では、ユーザ端末２０から移動実績に係る移動ログを取得した場合に、ユーザ端末２０が実際に移動した経路（実績経路）を特定する処理を行ってもよい。この場合、情報管理システム１は、例えば、ログ情報（ＧＰＳの位置情報履歴）と地図データベース３１に記憶される地図データとの照合等（いわゆる、マップマッチング）を行った上で、更にユーザの計画経路、ユーザの通過ログ、公共交通機関の時刻表を用いて実績経路の特定の少なくとも一つを用いて行ってもよい。ここで、マップマッチングとは、ＧＰＳの位置情報を地図データ（ノードデータやリンクデータ）と照合させ、地図上における道路を特定することである。ＧＰＳの位置情報には誤差（例えば、５ｍ）が含まれるため、マップマッチングを行った際、誤った移動経路（例えば、複数の路線が並走しており、ユーザが通過していない路線を移動経路としてしまう等）を実績経路として特定する可能性がある。そのため、ユーザの計画経路、ユーザの通過ログ、公共交通機関の時刻表の少なくとも一つを用いて、特定した移動経路を補正し、実績経路を確定させるのである。

図２は、情報管理システム１で用いられるコンピュータ１１０のハードウェア構成の一例を示す図である。例えば、コンピュータ１１０は制御回路１００を有する。一例では、制御回路１００は、一つまたは複数のプロセッサ１０１と、メモリ１０２と、ストレージ１０３と、通信ポート１０４と、入出力ポート１０５とを有する。プロセッサ１０１はオペレーティングシステムおよびアプリケーションプログラムを実行する。ストレージ１０３はハードディスク、不揮発性の半導体メモリ、または取り出し可能な媒体（例えば、磁気ディスク、光ディスクなど）の記憶媒体で構成され、オペレーティングシステムおよびアプリケーションプログラムを記憶する。メモリ１０２は、ストレージ１０３からロードされたプログラム、またはプロセッサ１０１による演算結果を一時的に記憶する。プロセッサ１０１は、メモリ１０２と協働してプログラムを実行することで、個々の機能モジュールとして機能する。通信ポート１０４は、プロセッサ１０１からの指令に従って、通信ネットワークＮＷを介して他の装置との間でデータ通信を行う。入出力ポート１０５は、プロセッサ１０１からの指令に従って、キーボード、マウス、モニタ、タッチパネルなどの入出力装置（ユーザインタフェース）との間で電気信号の入出力を実行する。

搭載されるハードウェアモジュールはコンピュータの種類によって異なり得る。例えば、プラットフォーマサーバ１０に搭載されるＣＰＵ、メモリ、ネットワークカードなどのモジュールはユーザ端末２０のものよりも高性能であり得る。プラットフォーマサーバ１０の入力装置としては一般にキーボードおよびマウスが用いられ、出力装置としてはモニタが用いられる。ユーザ端末２０がパーソナルコンピュータである場合には、入力装置としては一般にキーボードおよびマウスが用いられ、出力装置としてはモニタが用いられる。ユーザ端末２０が携帯端末である場合には、一般にはタッチパネルが入出力装置として用いられる。

図３は情報管理システム１の機能構成の一例を示す図である。より具体的には、図３はプラットフォーマサーバ１０およびユーザ端末２０の機能構成の一例を示す。

プラットフォーマサーバ１０は機能モジュールとして検索部１１、計画経路設定部１２、運行関連情報通知部１３、移動ログ取得部１４、実績経路特定部１５、経路ルールデータベース１６、コンテンツ管理部１７、ポイント管理部１８、および決済部１９を備える。検索部１１はユーザ端末２０からの要求に応答して移動経路を検索する機能モジュールである。計画経路設定部１２は、ユーザ端末２０から取得した将来移動予定の経路を計画経路として移動コードデータを生成する機能モジュールである。運行関連情報通知部１３は移動コードデータに計画経路を登録したユーザ端末２０に対して、計画経路に係る交通手段の運行情報等を通知する機能モジュールである。移動ログ取得部１４は、ユーザ端末２０が実際に移動した経路に係る移動ログを取得する機能モジュールである。実績経路特定部１５は、ユーザ端末２０から取得した移動ログに基づいてユーザ端末２０の実際の移動経路を特定する機能モジュールである。経路ルールデータベース１６は、実績経路特定部１５において実績経路を特定するためのルールを記憶する機能モジュール（記憶領域）である。コンテンツ管理部１７は、ユーザ端末２０からの要求に基づいて実績経路に係るコンテンツを生成する機能モジュールである。ポイント管理部１８は、ユーザ端末２０の実績経路に応じてユーザに対して付与するポイントを管理する機能モジュールである。決済部１９は、ユーザ端末２０の実績経路に応じた決済を行う機能モジュールである。

ユーザ端末２０は機能モジュールとして計画経路選定部２１、運行関連情報取得部２２、移動ログ取得部２３、送信部２４、および表示部２５を備える機能モジュールである。計画経路選定部２１は、ユーザが将来移動する移動の経路に係る計画経路を選定する。一例では、計画経路選定部２１は、プラットフォーマサーバ１０の検索部１１と連携して、ユーザにより設定された検索条件に合致する移動経路（候補経路）から、特定の移動経路を選択して計画経路とする。一例として、ユーザ端末２０において選定された計画経路は、プラットフォーマサーバ１０に対して送信される。運行関連情報取得部２２は、プラットフォーマサーバ１０の運行関連情報通知部１３と連携して、計画経路に係る交通手段の運行情報等を取得し、ユーザに対して通知する機能モジュールである。移動ログ取得部２３は、ユーザ端末２０の現在位置の履歴を実績経路として取得する機能モジュールである。一例では、移動ログ取得部２３は全地球測位システム（ＧＰＳ）機能を利用する。また、一例として、移動ログ取得部２３は、特定の場所を通過したことを特定することができる通過ログを移動ログの一種として取得してもよい。通過ログは、例えば、駅の改札を通過したことを示す情報、特定の施設に設けられたＱＲコード（登録商標）等をユーザ端末２０で読み取ったことを示す情報等が含まれ得る。送信部２４は、プラットフォーマサーバ１０に対して移動ログを送信する機能モジュールである。表示部２５は、プラットフォーマサーバ１０から取得した情報等を表示することでユーザに対して機能モジュールである。一例として、プラットフォーマサーバ１０から取得する情報には、移動の経路に係る情報、計画経路に係る交通手段の運行情報、プラットフォーマサーバ１０から提供される広告、コンテンツデータ等が含まれる。

［地図データ］
地図データは、例えば候補経路の検索や移動ログとの照合（いわゆる、マップマッチング）のために用いられる。地図データのデータ構造は限定されない。地図データにより示される地図要素の種類および表現方法は限定されず、任意の方針で設計されてよい。地図要素の例としてノードおよびリンクが挙げられる。ノードとは、経路を特徴づける位置をいい、より具体的には、移動体の移動方法（例えば方向、速度など）を変えることができる位置、または該移動方法が変わる位置をいう（例えば、駅、バス停、駐車場等の移動手段や公共交通機関の乗り換え地点、交差点など）。リンクとは、経路を示すために設定される仮想的な線であって、隣接するノード間を結ぶ線である（例えば、交差点間を構成する道路や路線等）。リンクの形状は直線でも曲線でもよく、あるいは、直線と曲線との組合せでもよい。地上においては、リンクの形状は道路または軌道の形状に依存し得る。ノードおよびリンクが設定される位置は限定されず、例えば、ノードおよびリンクは地上、地下、空中、水上、または水中に設定され得る。二つのノードを結ぶリンクが複数個存在してもよい。例えば、二つのノードが鉄道に関するリンクと道路に関するリンクとの双方によって結ばれる場合があり得る。

一例では、地図データは、複数のノードを示すノードデータと、複数のリンクを示すリンクデータとを含んで構成される。

一例では、ノードデータはデータ項目としてノードＩＤ、座標、およびノード属性を含む。ノードＩＤは個々のノードを一意に特定する識別子である。座標は、ノードの２次元（緯度、経度）または３次元（緯度、経度、高度）の地理的位置を示す値である。座標の設定方法は限定されず、例えば、座標は緯度および経度を用いて表現されてもよいし、他の任意の座標系に従って設定されてもよい。ノード属性とは、ノードの性質、特徴、または状況を表す任意の情報である。例えば、ノード属性は、ノードに関連する地物に関する地物情報を含んでもよいし、ノードに関連する事業者に関する事業者情報を含んでもよい。

一例では、リンクデータはデータ項目としてリンクＩＤ、第１ノードＩＤ、第２ノードＩＤ、およびリンク属性を含む。リンクＩＤは個々のリンクを一意に特定する識別子である。第１ノードＩＤおよび第２ノードＩＤはいずれも、リンクの端に位置するノードを特定するノードＩＤである。リンク属性とは、リンクの性質、特徴、または状況を表す任意の情報である。例えば、リンク属性は、交通機関などの移動手段と、リンクを移動するための所要時間または費用と、リンクの状況（例えば交通情報）と、リンクに関連する地物（すなわち地物情報）と、リンクに関連する事業者（すなわち事業者情報）と、リンクに関連するサービス情報（例えば広告情報、クーポン情報など）のうちの少なくとも一つを含んでもよい。

一例では、地図データは、交通結節点および交通施設を示すデータをさらに含んで構成される。この場合には、ノード属性は交通結節点または交通施設に関する情報を含んでもよい。

交通結節点とは移動手段の変更が実施される場所（要するに、移動手段が変わる場所）をいう。より具体的には、交通結節点は、複数の同種あるいは異種の移動手段の接続が行われる場所をいう。交通結節点は複数の交通施設を含む。「移動手段の変更」とは或る移動手段から別の移動手段に変えることをいう。移動手段が限定されないことに対応して、移動手段の変更も限定されない。或る移動手段から別の移動手段への乗換は、移動手段の変更の一例である。移動手段の変更の例として、タクシーから在来線への乗換、或る路線（鉄道路線、バス路線など）から別の路線（鉄道路線、バス路線など）への乗換、自家用車から徒歩への変更、徒歩から在来線への変更などが挙げられる。

交通施設とは、移動手段を変更するためにユーザに利用される施設をいう。交通施設は、交通結節点を構成する要素として情報管理システム１により処理される。交通施設はノードの一種であり得る。交通施設の例として、駅、バス停、タクシー乗り場、港、空港、レンタカーの営業所、レンタサイクルのサイクルポート、駐車場、および駐輪場が挙げられるが、交通施設はこれらに限定されない。一つの交通施設が複数の交通結節点と関連付けられてもよい。したがって、交通結節点および交通施設は多対多の関係（言い換えるとＭ：Ｎの関係）にある。それぞれの交通結節点では、該交通結節点を代表する一つの交通施設が設定される。本開示ではその代表の交通施設を「代表施設」という。また、本開示では、それぞれの交通結節点において代表施設以外の交通施設を「構成施設」という。

代表施設は任意の手法によって設定されてよい。例えば、代表施設は、交通結節点または特定の区域の中で最も中心的な役割を果たす施設、最も利用者が多い交通施設、あるいはランドマークの役割を持つ交通施設でもよい。

構成施設も任意の方針で設定されてよい。或る交通施設を構成施設としていずれかの交通結節点に所属させる場合には、その交通施設にいちばん近い代表施設が特定され、その交通施設が、該特定された代表施設と同じ交通結節点に構成施設として追加されてもよい。あるいは、異なる交通手段を利用するユーザの利用実績または地形上の関係に基づいて、交通施設をどの交通結節点に所属させるかが決定されてもよい（例えば、或る交通施設を、川向いにある代表施設に所属させないように構成施設が決定されてもよい）。

交通結節点は、交通結節点に関する情報を示す交通結節点データによって管理されてもよい。一例では、交通結節点データの各レコードは、個々の交通結節点を一意に特定する交通結節点ＩＤと、交通結節点の名称（交通結節点名）と、を含んでいてもよい。また、交通結節点での乗換に関しては、乗換データにおいて管理してもよい。一例では、乗換データの各レコードは、個々の乗換方法を一意に特定する乗換ＩＤと、乗換に用いられる二つの交通施設のＩＤと、移動コスト（移動に係る時間等の負荷）とを含む。

地図データの個々のデータ項目は静的に設定されてもよいし動的に設定されてもよい。「静的に設定される」とは、値が予め設定され、人手の介入がない限りはその設定が変更されないことをいう。一方、「動的に設定される」とは、値が任意の事象に応じて人手の介入無しに変更され得ることをいう。動的な設定は、所与のデータ項目を制御するプログラムが所定のコンピュータ上で実行されることで実現される。動的な設定は情報管理システム１により実行されてもよいし、別のコンピュータシステムにより実行されてもよい。

［経路データ］
経路データのデータ構造は限定されない。例えば、経路データは複数のノードＩＤおよび複数のリンクＩＤによって表現されてもよい。より具体的には、経路データは、交通施設または交通結節点に対応するノードのノードＩＤと、そのノード間（すなわち交通施設間または交通結節点間）を結ぶリンクのリンクＩＤとによって表現されてもよい。上述したように移動経路は経路属性を示すことができるので、経路データはその経路属性に対応するデータ項目を含み得る。例えば、経路データは、経路上での移動に関する日時（本開示ではこれを「移動日時」という）を示してもよい。移動日時の例として、個々のノードでの出発日時、通過日時、乗換日時、または到着日時が挙げられる．しかし、移動日時の種類はこれらに限定されない。移動日時は、候補経路および計画経路では予定の日時を示し、実績経路では実際の日時を示す。別の例では、経路データは移動経路における交通費の見込額または実額を示してもよい。この交通費は交通手段ごとに示されてもよいし、移動経路の全体における総額として示されてもよい。

［移動コードデータ］
移動コードデータのデータ構造は限定されない。図４では移動コードデータＤ１の一例を示している。図４に示すように、移動コードデータＤ１の各レコードは、基本情報Ｄ１１、計画経路情報Ｄ１２、および実績経路情報Ｄ１３を含んでいてもよい。

基本情報Ｄ１１は、移動コードデータを特定するための情報を含む。一例として、基本情報Ｄ１１は、移動ＩＤ、ユーザＩＤ、経路発行事業者ＩＤ（経路検索を主管した事業者のＩＤ）、開始ノード（出発地に係るノード）、および終了ノード（目的地に係るノード）を含んでいてもよい。

計画経路情報Ｄ１２は、ユーザ端末２０によって設定された計画経路に係る情報を含む．一例として、計画経路情報Ｄ１２は、経路コード（移動する経路を特定したリンク情報；経路データ）、移動手段（経路コードに沿った移動を行う際に利用する交通手段を特定する情報）、出発予定時間、到着予定時間、およびリンクリストを含んでいてもよい。一例として、リンクリストは、リンクＩＤ、移動手段、運賃、出発予定時間、および到着予定時間を含んでいてもよい。

実績経路情報Ｄ１３は、ユーザ端末２０の移動ログに基づいて特定されたユーザ端末の実績経路に係る情報を含む．一例として、実績経路情報Ｄ１３は、経路コード、移動状況（「移動中」または「到着済み」等を示す情報）、滞在中リンク（現在地を含むリンクを示す情報）、およびリンク情報を含んでいてもよい。一例として、リンク情報は、リンクＩＤ、出発実績時間、および到着実績時間を含んでいてもよい。

［システムでの処理手順］
（移動コードデータの生成）
図５を参照しながら、ユーザ端末２０により設定された計画経路に基づいて移動コードデータを生成する処理について説明する。

ステップＳ０１では、ユーザがユーザ端末２０を操作することで経路の検索に係る情報を入力する。ユーザ端末２０の計画経路選定部２１は経路の検索条件に係る情報を取得する。経路の検索条件には、例えば、出発地点（スタート）および目標地点（ゴール）、移動を行う日時、優先して使用する交通手段等を特定する情報が含まれる。ステップＳ０２では、ユーザ端末２０の計画経路選定部２１からプラットフォーマサーバ１０に対して検索条件が送信され、経路検索のリクエストが行われる。

ステップＳ０３では、プラットフォーマサーバ１０の検索部１１が、検索条件に基づいた経路検索を行う。一例では、ユーザ端末２０がユーザから目的地の入力を受け付ける。目的地の入力は、電話番号による検索、住所による検索、地図上に表示した施設や地点を直接選択する等の周知の方法により行う。検索部１１は、出発地点（例えば、ユーザ端末２０の現在位置、ユーザの指定する出発地点等）から目的地まで至る交通手段の経路検索処理を行う。一例では、ユーザ端末２０の現在位置（出発地点）が東京駅であり目的地が品川駅である場合、東京駅から品川駅まで至る交通手段として、東海道新幹線、東海道線、横須賀線、山手線、京浜東北線等の経路が検索される。そして、ステップＳ０４では、プラットフォーマサーバ１０の検索部１１からユーザ端末２０に対して検索結果として、１以上の経路の候補（上記の一例では、東海道新幹線、東海道線、横須賀線、山手線、京浜東北線）が送信される。必要に応じて上記のステップＳ０１～Ｓ０４は繰り返される。

ステップＳ０５では、ユーザ端末２０において、ユーザの操作によって、使用する予定の経路候補が選択される（上記の一例では、ユーザ端末２０において京浜東北線が経路候補として選択されるとする）。
ステップＳ０６では、ユーザ端末２０の計画経路選定部２１が選択された結果をプラットフォーマサーバ１０に対して送信する。プラットフォーマサーバ１０は、ユーザ端末２０から送信された選択結果を取得する。

ステップＳ０７では、プラットフォーマサーバ１０の計画経路設定部１２が、ユーザ端末２０からの選択結果に基づいて移動コードデータを生成する。この段階では、プラットフォーマサーバ１０は、移動コードデータに係る情報として、基本情報Ｄ１１および計画経路情報Ｄ１２に対応する情報を保持している。したがって、計画経路設定部１２は、これらの情報に基づいて、移動コードデータを１つ生成する。すなわち、生成される移動コードデータＤ１には、実績経路情報Ｄ１３が含まれていないことになる。

なお、移動コードデータの生成（Ｓ０７）またはユーザ端末２０による計画経路の選択（Ｓ０６）を契機としてプラットフォーマサーバ１０とユーザ端末２０との間で、ユーザ端末２０による計画経路に沿った移動に係る決済をプラットフォーマサーバ１０が行うという契約を行ってもよい。一例として、ユーザ端末２０は計画経路に沿った移動を行い、当該移動に伴って発生した費用についてはプラットフォーマサーバ１０を経由して各交通事業者に対して支払うということを規定した契約を締結することとしてもよい。この場合、後段で説明する決済処理をプラットフォーマサーバ１０が行うこととなる。また、上記のような契約を行う場合、一例として、計画経路を登録した段階でプラットフォーマサーバ１０がユーザ端末２０から計画経路に沿った移動を行った場合の費用を預かるという構成としてもよい。なお、上記のステップ（Ｓ０６またはＳ０７）を進めることが、費用決済に係る契約の締結を意味する場合には、事前に約款等でプラットフォーマサーバ１０からユーザ端末２０へ当該内容が通知されてもよい。

ステップＳ０８では、生成された移動コードデータがデータベース群３０の移動コードデータベース３２へ送られる。そして、ステップＳ０９では、データベース群３０の移動コードデータベース３２において移動コードデータが保存される。なお、この際に、移動コードデータを作成したユーザに係る情報がユーザデータベース３３に保存されてもよい。一例として、ユーザに係る情報には、例えば、ユーザの個人情報、決済に使用する口座等の決済関連情報、ユーザが利用しているポイントプログラムを特定する情報等が含まれる。

ステップＳ１０以降は、移動コードデータベース３２に保存された移動コードデータを利用した処理の一例を示している。ステップＳ１０では、事業者サーバ４０が移動コードデータベース３２に対してアクセスをすることで、移動コードデータを取得する。一例として、事業者サーバ４０が特定の地域に係る広告を提供する事業者のサーバである場合、例えば、事業者サーバ４０から移動コードデータベース３２に対して問い合わせることで特定の地域を通過する計画経路が含まれている移動コードデータを取得する。上記は一例であり、事業者サーバ４０が取得する移動コードデータの選択の方法は限定されず、移動コードデータに含まれるいずれかの情報を用いてデータの選択を行うことができる。

ステップＳ１１では、事業者サーバ４０は、取得した移動コードデータを参照してターゲットとなるユーザ端末２０を選定し、広告・交通情報等をプラットフォーマサーバ１０に対して送信する。一例として、上記の特定の地域に係る広告を提供する事業者の場合には、当該地域を通過する計画経路を含む移動コードデータが保持されているユーザ端末２０に対してプラットフォーマサーバ１０を経由して広告データの配信をするようにプラットフォーマサーバ１０に対して要求してもよい。また、事業者が例えば鉄道会社等の交通機関の管理者である場合には、当該交通機関を利用する計画経路を含む移動コードデータが保持されているユーザ端末２０に対して、プラットフォーマサーバ１０を経由して交通機関の運行情報の配信を要求してもよい。なお、これらの情報の提供はプラットフォーマサーバ１０を経由せずに行うこともできる。また、事業者サーバ４０からの広告・交通情報の提供は、対象となる移動コードデータの選択（Ｓ１０）の後に行ってもよいし、移動コードデータの選択（Ｓ１０）を省略してもよい。この場合、事業者サーバ４０から広告・交通情報等の情報の配信条件を指定してプラットフォーマサーバ１０に対して情報の配信を要求してもよい。

ステップＳ１２では、プラットフォーマサーバ１０では、事業者サーバ４０から取得した交通情報を保存する。この処理は省略してもよい。プラットフォーマサーバ１０において交通情報を保存した場合、例えば、プラットフォーマサーバ１０側の判断で、事業者サーバ４０から指定されたユーザ端末２０とは異なるユーザ端末２０に対して交通情報を提供してもよい。また、一例として、検索部１１において当該交通情報を保持し、経路検索を行うユーザ端末２０に対して交通情報を同時に通知する構成としてもよい。

ステップＳ１３では、プラットフォーマサーバ１０は、ユーザ端末２０に対して広告・交通情報を通知する。一例として、プラットフォーマサーバ１０の運行関連情報通知部１３は、事業者サーバ４０から指定された特定の経路を通る計画経路を設定したユーザ端末２０に対して当該経路に係る交通情報を配信してもよい。交通情報の配信は、例えば、プラットフォーマサーバ１０からのプッシュ通知等を利用して行ってもよい。

なお、ステップＳ１０～Ｓ１３に示す手順は一例であって、適宜変更することができる。上述したように、移動コードデータベース３２の検索および情報の取得（Ｓ１０）を契機として、事業者サーバ４０からユーザ端末２０に対して直接情報を通知する構成としてもよい。また、経路コードデータの生成に係る一連の処理（Ｓ０１～Ｓ０９）に基づいて、プラットフォーマサーバ１０の基準に基づいて特定のユーザ端末２０に対して広告・交通情報の配信を行う構成としてもよい。

なお、選択されたユーザ端末２０に対して配信する交通情報には、例えば、計画経路に基づいた移動が困難なことを示す情報（例えば、遅延情報・不通情報）と、計画経路に対する代替案に係る情報とが含まれていてもよい。特に、プラットフォーマサーバ１０とユーザ端末２０との間で、計画経路に沿った移動に係るユーザの移動に係る費用の決済をプラットフォーマサーバ１０が一括して行うような契約を締結している場合、プラットフォーマサーバ１０は、交通手段を提供する事業者（事業者サーバ４０）から当該計画経路に係る交通手段の運行情報を適切な時期に取得することが求められる。さらにプラットフォーマサーバ１０は、取得した運行情報をユーザ端末２０に対して通知し、必要に応じて計画経路の代替となる経路を提示する構成としてもよい。

（実績経路の特定・決済・ポイント付与）
図６～図１１を参照しながら、ユーザ端末２０の移動実績に基づく実績経路の特定と、特定された実績経路に基づく決済と、ユーザに対するポイント付与に係る処理とについて説明する。まず、図６を参照しながら、ユーザ端末２０の移動実績に基づく上記の処理の一連の流れを説明し、同時に各ステップで行われる処理の詳細について説明する。

まず、ステップＳ２１では、ユーザは例えば計画経路に沿って、出発地から目的地までの移動を行う。このとき、ユーザ端末２０の移動ログ取得部２３は、自端末の移動に伴った移動ログを取得する。移動ログとしては、上述のＧＰＳを利用した位置情報のほか、所定の地点（例えば、駅、バス停、駐車場、交差点等）を通過したことを示す通過ログが含まれる。

ステップＳ２２では、ユーザ端末２０の送信部２４が、移動ログ取得部２３で取得された移動ログをプラットフォーマサーバ１０に対して送信する。上述したように、移動ログの送信タイミングは特に限定されず、例えば、目的地への移動が完了した後でもよいし、移動中でもよい。プラットフォーマサーバ１０では、移動ログ取得部１４がユーザ端末２０からの移動ログを取得する。

ステップＳ２３では、プラットフォーマサーバ１０の実績経路特定部１５によって、ユーザ端末２０が実際に移動した移動経路を特定する。具体的には、移動ログ（ＧＰＳの位置情報履歴）を地図データベース３１にマップマッチングさせ、ユーザ端末２０が実際に移動した道路や路線を特定する。一例では、ユーザ端末２０のＧＰＳの位置情報の履歴が地図データベース３１のリンクＡにある場合、ユーザ端末２０はリンクＡに対応する道路や路線を実際に移動したものとして特定する。さらに、ステップＳ２４では、プラットフォーマサーバ１０の実績経路特定部１５によって、ユーザ端末２０が実際に移動した経路を示す実績経路が確定される。具体的には、経路ルールデータベース１６を用いて、ステップＳ２３で特定した移動経路を適宜修正し、ユーザ端末２０が実際に移動した道路や路線を確定させる。

このように、実績経路特定部１５による実績経路の確定には、経路ルールデータベース１６において記憶されるルールが使用される。ここで、図７および図８を参照しながら、経路ルールデータベース１６を用いた実績経路の特定方法について説明する。なお、図７および図８の経路ルールデータベース１６を用いた実績経路の特定方法は一例に過ぎず、実績経路の特定方法は何らこれらに限定されない。

図７では、ユーザ端末２０が出発地Ａから目的地Ｆまで、Ｂ，Ｃ，Ｄ地点を経由して移動した場合について説明する。図７では、地図上に、出発地Ａおよび目的地Ｆが示されている。また、Ａ－Ｆ間には、ある鉄道のＢ，Ｃ，Ｄ，Ｅ駅が存在していたとする。さらに、Ｂ－Ｅ間には、並行する２つの路線（α、β）が走っていて、例えば、どちらの路線に乗ったかによって運賃が変わるとする。ここで、図７に示すように、ユーザ端末２０は、計画経路では、Ａ－Ｂ－Ｃ－Ｅ－Ｆの予定であったが、実際はＡ－Ｂ－Ｃ－Ｄ－Ｆを辿っていたとする。また、移動ログに含まれる通過ログとして、Ｂ駅およびＤ駅で改札を通ったことを示す情報が取得されていたとする。このとき、プラットフォーマサーバ１０の実績経路特定部１５では、まず、移動ログのうちＧＰＳによる位置情報に基づく移動経路を、地図データベース３１に記憶されている地図情報と比較（いわゆるマップマッチング）して、ユーザ端末２０の移動経路を推定する。この結果、ユーザ端末２０の移動経路を、Ａ－Ｂ－Ｃ－Ｅ－Ｆと特定したとする。ただし、Ｅ駅ではなくＤ駅で改札を通過したという通過ログが存在する場合、Ｅ駅ではなくＤ駅を利用したことが分かる。また、ＧＰＳによる位置情報からは、α、βのいずれの種別の路線を使用したかが特定し難く、通過ログからも特定ができないとする。このとき、実績経路特定部１５は、例えば、計画経路において種別αの路線を使用することが特定されていることに基づいて、実績経路として、Ｂ－Ｄ間は種別αの路線を使用したことを確定する。

上記の一連の手順では、まず、実績経路特定部１５は、まず移動ログのうちＧＰＳによる位置情報と地図データとの照合に基づいてユーザ端末２０の移動経路を特定する。その後、例えば、通過ログや計画経路に含まれる情報に基づいて適宜補正を行う。このように、地図データに基づいて移動経路を特定した後に、通過ログや計画経路を利用して実績経路の確定を行っている。このような手順は、経路特定のルールとして定められていてもよい。

図８では、ユーザ端末２０が出発地Ａから目的地Ｅまで、Ｂ，Ｃ，Ｄ地点を経由して移動した場合を示している。図８では、地図上に、出発地Ａおよび目的地Ｅが示されている。また、Ａ－Ｅ間には、ある鉄道のＢ，Ｃ，Ｄ駅が存在していたとする。さらに、Ｂ－Ｄ間には、種別α（一例では、在来線）の路線が存在するが、Ｂ－Ｃ間にはそのほかに種別β（一例では、新幹線）の路線も存在するとする。ここで、図８に示すように、ユーザ端末２０は、実際はＡ－Ｂ－Ｃ－Ｄ－Ｅを辿っていたとする。ＧＰＳによる位置情報には、一般的に情報の取得日時が紐付けられている。今回の事例では、Ｂ駅付近でのＧＰＳ位置情報が１０時に取得され、Ｃ駅付近でのＧＰＳ位置情報が１０時１５分に取得されたことを移動ログから特定できたとする。また、移動ログに含まれる通過ログとして、Ｂ駅およびＤ駅で改札を通ったことを示す情報が取得されていたとする。このとき、プラットフォーマサーバ１０の実績経路特定部１５では、まず、ＧＰＳによる位置情報に基づく移動経路を、地図データベース３１に記憶されている地図情報と比較（いわゆるマップマッチング）して、ユーザ端末２０の移動経路を特定する。この結果、Ｂ駅－Ｄ駅の間で鉄道を利用したことは特定することができたとする。ただし、Ｂ－Ｃ間ではどちらの種別を利用したかの特定ができなかったとする。ここで、この鉄道に係る時刻表情報を参照すると、Ｂ駅を１０時に出発し、Ｃ駅に１０時１５分に到着する種別β（一例では、新幹線）の路線の電車が存在しており、Ｃ駅に１０時１５分に到着する種別α（一例では、在来線）の路線の電車が存在しないとする。この場合、時刻表情報に基づいて、実績経路として、Ｂ－Ｃ間は種別βの路線を使用したことを特定する。

上記の一連の手順では、まず、実績経路特定部１５は、まず移動ログと地図データとの照合に基づいてユーザ端末２０の移動経路を特定する。その後、地図データとの照合および計画経路との比較によって特定が困難な部分の経路（ここでは、利用する交通手段の種別）は、例えば、時刻表情報等の交通手段が網羅されている情報を組み合わせて特定を行う。このように、地図データに基づいて経路を特定した後に、特定が困難な部分については、時刻表情報を参照して実績経路の確定を行っている。このような手順は、経路特定のルールとして定められていてもよい。

このように、実績経路特定部１５が実績経路を特定する際には、通過ログを含む移動ログ、計画経路、時刻表情報等を利用することができる。また、経路ルールデータベース１６では、実績経路特定部１５が使用できる各種情報に基づいて実績経路を特定するためのルールが保持される。一例として、実績経路を特定するためのルールは、実績経路特定部１５が使用できる種々の情報のうち、経路の特定に使用する情報の優先順序を定めていてもよい。他の例として、一例として、実績経路を特定するためのルールは、実績経路特定部１５が実績経路を特定する際に、データベース群３０等を参照して取得する情報の種類を特定していてもよい。このように、実績経路を特定するためのルールは、実績経路特定部１５が経路の特定を行う際に係る種々のルールを含んでいてもよい。

図６に戻り、ステップＳ２５では、プラットフォーマサーバ１０の実績経路特定部１５は、特定された実績経路に係る情報をデータベース群３０の移動コードデータベース３２に保持される移動コードデータに対して追加する。また、ステップＳ２６では、移動コードデータに対してプラットフォーマサーバ１０から送信された実績経路に係る情報が追加される。具体的には、図４に示す移動コードデータＤ１のうち実績経路情報Ｄ１３が追加されることになる。

ステップＳ２７では、プラットフォーマサーバ１０の決済部１９は、実績経路に基づく決済処理を行う。

決済処理は、予め定められたプラットフォーマサーバ１０とユーザ端末２０との間の契約、または、プラットフォーマサーバ１０と事業者（交通手段を提供する事業者）との間の契約に基づいて行われる。図９では、決済処理に関する２種類の手順を示している。ここでは、上述したように、予めプラットフォーマサーバ１０とユーザ端末２０とに間で、計画経路に基づいてユーザ（ユーザ端末２０）が移動した際に発生する費用をプラットフォーマサーバ１０が一括して回収し、実際に使用した交通手段の運賃毎に分配する場合について説明する。

まず、図９（ａ）に示す手順では、ステップＳ３１において、計画経路に基づきユーザ（ユーザ端末２０）から当該経路に沿った移動に係る費用を回収する。「回収」とは、プラットフォーマサーバ１０がユーザ端末２０から費用を預かることを意味する。これは、例えば、ユーザが実際の移動を開始する前（一例として、計画経路の設定時）に行われていてもよい。次に、ステップＳ３２において、プラットフォーマサーバ１０の実績経路特定部１５により、ユーザ端末２０が実際に移動した後に、実績経路を特定する。その後、ステップＳ３３において、プラットフォーマサーバ１０の決済部１９により、実績経路に含まれる交通手段間で、実績経路に基づいた費用の分配と差額の調整とを行う。なお、「差額の調整」には、不足分のユーザからの回収、計画経路における交通手段とは異なる代替交通手段を使用した場合の交通手段間での費用の調整等が含まれ得る。

一方、図９（ｂ）に示す手順では、ステップＳ４１において、計画経路に基づきユーザ（ユーザ端末２０）から当該経路に沿った移動に係る費用を回収する。次に、ステップＳ４２において、プラットフォーマサーバ１０の決済部１９により、回数した費用を計画経路に基づいて交通手段間で分配を行う。次に、ステップＳ４３において、プラットフォーマサーバ１０の実績経路特定部１５により、ユーザ端末２０が実際に移動した後に、実績経路を特定する。その後、ステップＳ４４において、プラットフォーマサーバ１０の決済部１９により、実績経路に含まれる交通手段間で、先に分配した費用と実際にかかった費用との差額の調整を行う。

図９（ａ）に示す手順と図９（ｂ）に示す手順とでは、ユーザ（ユーザ端末２０）から回収した費用をどのタイミングで分配するかが異なる。図９（ａ）に示す手順では、実績経路を特定（Ｓ３２）した後に、実績経路に基づいて費用を分配している。一方、図９（ｂ）に示す手順では、計画経路に基づいて費用を分配し（Ｓ４２）、その後に特定された実績経路に基づいた調整（Ｓ４４）を行っている。何れの手順を採用する場合であっても、最終的にはユーザ（ユーザ端末２０）の実績経路に基づいて費用の分配が行われる。

図１０を参照しながら、ユーザ端末２０の計画経路と実績経路との差分に基づく差額の調整について説明する。図１０（ａ）は、あるユーザの計画経路を示している。一例として、ユーザは、Ａ駅を８時に出発し、バスによってＢ空港まで移動する。その後Ｂ空港を９時に出発して飛行機でＣ空港に到着する。さらに、Ｃ空港を１０時４０分に出発してモノレールを利用してＤ駅に１１時４０分に到着する。上記のような計画経路に対して、図１０（ｂ）、図１０（ｃ）では、経路の一部が交通事情等によって変更となった例を示している。

図１０（ｂ）では、上記Ａ－Ｂ間の交通渋滞によって、バスを利用するとＢ空港から９時に出発できない状態を示している。このとき、ユーザは、バスに代えてタクシーを利用してＢ空港へ到着し、以降の行程は計画経路と同様に移動したとする。Ａ－Ｂ間をバス移動からタクシー移動に切り替えた場合、運賃が８００円から１８００円に増額する。ただし、Ａ－Ｂ間をバス移動からタクシー移動に切り替えたのは、ユーザの事情ではなく交通状況に基づく変更である。したがって、差額の調整は、ユーザからの回収ではなく、バス会社とタクシー会社の間で行われる。例えば、バス会社は計画経路に基づいてユーザから回収した８００円を受け取らず、さらに、タクシー運賃との差額の１０００円をタクシー会社へ支払う。一方、タクシー会社は、ユーザから回収している（バス運賃としての）８００円と、バス会社からの１０００円とを、タクシー運賃として受け取る。これにより、ユーザの実績経路に基づく費用の分配を行うことができる。

図１０（ｃ）では、飛行機の遅延によって、Ｃ空港を１０時４０分に出発するモノレールにユーザが到着できない状況が発生したとする。このとき、ユーザが代替手段として１０時５０分にＣ空港を出発する鉄道を利用してＤ駅に到着したとする。また、この移動にかかった鉄道運賃は、モノレールの運賃と同額（６００円）であったとする。Ｃ－Ｄ間をモノレール移動から鉄道移動に切り替えたのは、ユーザの事情ではなく交通事情に基づく変更である。したがって、差額の調整は、ユーザからの回収ではなく、交通機関に係る事業者間で行われる。この例の場合には、モノレールの運賃と鉄道の運賃とが同額であるため、ユーザから回収したモノレールの運賃がそのまま鉄道の運賃として鉄道会社に支払われる。なお、鉄道の運賃がモノレールの運賃よりも高額である場合には、例えば、交通手段の変更の原因となった飛行機を運航する航空会社に対して鉄道の運賃とモノレールの運賃との支払いを求めることにより、差額の調整をしてもよい。

プラットフォーマサーバ１０とユーザ端末２０との間で、上記のように計画経路に基づいた移動を行うことに係る契約を締結し、当該移動に係る決済をプラットフォーマサーバ１０が一括して行う場合、図１０に示すように、交通事情に基づく変更が発生した場合の調整はプラットフォーマサーバ１０が主体的に行ってもよい。また、ユーザ（ユーザ端末２０）側が交通事情に応じて主体的に経路を変更することをプラットフォーマサーバ１０が許容する構成としてもよい。プラットフォーマサーバ１０とユーザ端末２０との関係は、事前に決める契約等に応じて適宜変更することができる。また、ユーザの計画経路と実績経路との差分によって生じる運賃の調整に関しては、プラットフォーマサーバ１０を提供する事業者と、交通手段に係る事業者との間で予め定めておくことができる。

図６に戻り、ステップＳ２８では、プラットフォーマサーバ１０のポイント管理部１８は、実績経路に基づくポイント算出を行う。また、ステップＳ２９では、プラットフォーマサーバ１０のポイント管理部１８は、算出されたポイントをユーザ端末２０に対して付与する。一例として、ユーザ端末２０に対して紐付けられるポイント数に対して付与するポイントを加算する処理を行う。この処理は、例えば、事業者サーバ４０からの指示に基づいたルールに則って行われる。

ユーザに対するポイントの付与は、例えば、ユーザの健康促進、特定の交通手段の利用の推進、特定の地域への訪問等を推奨することを目的として行われ得る。これらの目的は一例であって、これらに限定するものではない。ここでは、一例として、ユーザの健康促進を目的として、ユーザの徒歩移動時の歩数に応じてポイントを付与する場合の処理について説明する。ユーザの健康促進に対してポイントを付与する場合、ポイント付与に係るサービスを提供する事業者は、例えば自治体である。例えば、特定の地域に在住するユーザの徒歩移動に対して、自治体がポイントを付与し、さらにポイント数に応じたサービス（景品の授与等）を提供することで、当該地域のユーザの健康促進が期待される。

図１１では、ユーザ端末２０の移動ログから特定された実績経路から、さらに徒歩移動に係るポイントを付与する際の手順を示している。

まず、ステップＳ５１では、プラットフォーマサーバ１０のポイント管理部１８は、ユーザ端末２０の実績経路のうち、公共交通機関を使用していない区間を特定する。図７、図８等で説明したように、実績経路を特定する際に、鉄道等の公共交通機関を使用した区間を特定することができる。したがって、公共交通機関を使用した区間と特定されなかった区間が、非使用区間となる。

ステップＳ５２では、プラットフォーマサーバ１０のポイント管理部１８は、公共交通機関の非使用区間からポイント付与の対象となる区間を特定する。ユーザの徒歩移動に対してポイントを付与する場合には、ユーザが公共交通機関を使用していない区間のうち、徒歩移動とみなされる区間を特定する。徒歩移動とみなされる区間を特定する方法としては、例えば、ユーザ端末２０の移動速度が徒歩移動に相当する速度である区間を特定する方法が挙げられる。具体的には、ＧＰＳの位置情報に基づいて移動速度を算出し、所定の移動速度以下（例えば、時速４．５ｋｍ以下）の区間を徒歩移動区間として特定してもよい。また、徒歩移動区間を特定するためのサポート情報としてユーザ端末２０の加速度センサの記録を移動ログとして取得する構成としてもよい。

ステップＳ５３では、プラットフォーマサーバ１０のポイント管理部１８は、ポイント付与区間に基づいて付与するポイントを算出する。例えば、徒歩移動時の歩数に応じてポイントを付与する場合には、例えば、徒歩移動区間の距離を一歩あたりの距離で割ることで歩数を算出することができる。これにより、歩数に応じた付与ポイントを特定することができる。

ステップＳ５４では、プラットフォーマサーバ１０のポイント管理部１８は、ユーザ端末２０へのポイント付与処理を行う。一例として、ユーザ端末２０に対して紐付けられるポイント数に対して付与するポイントを加算する処理を行う。

上記のポイント付与に係る処理は、ポイントを付与する対象（付与条件）等に応じて変更され得る。また、ポイントを付与するための条件として、実績経路以外の情報（例えば、ユーザの属性）が含まれる場合には、それらの情報も加味した上で、ポイント付与に係る処理が行われる。

（データのコンテンツ化およびコミュニケーションツールとしての活用）
図１２および図１３を参照しながら、上記の一連の処理に基づいて得られたデータをプラットフォーマサーバ１０がコンテンツとしてユーザに対して提供する場合の処理について説明する。ここでは、プラットフォーマサーバ１０がユーザ端末２０の移動ログに基づいて特定された実績経路をコンテンツ化し、他のユーザに対して提示する場合について説明する。すなわち、本実施形態における「コンテンツとしてユーザに対して提供する」とは、移動ログから特定されたあるユーザに係る実績経路を、他のユーザ（ユーザ端末２０）が利用可能となる状態とすることをいう。また、あるユーザの実績経路を他のユーザが利用した場合には、コンテンツ化したユーザに対して対価（例えば、ポイント）を提供することで、プラットフォーマサーバ１０の利用が促進され得るという側面がある。ここで、コンテンツ化とは、具体的には、経路をリンクデータとノードデータとで定義することをいう。このうち、リンクデータは、道路や路線を表すものであり、ＩＤで管理され、道路の地理的な座標を含むデータである。また、ノードデータは、交差点や交通結節点を表すものであり、ＩＤで管理され、交差点の地理的な座標を含むデータである。こうすることにより、コンテンツを利用する他のユーザは、コンテンツをダウンロードすることにより、直ちに対象の経路を特定することが可能となる。その意味では、本コンテンツ群は、他のユーザにとって候補経路であり、候補経路のうち他のユーザが選択した経路は計画経路といえる。

図１２は、コンテンツ化の一例として、あるユーザの実績経路を利用して、他のユーザが計画経路を作成するような状況を想定する。なお、以下の説明では、このような他のユーザの実績経路を利用して計画経路を作成することを実現するためのレイアウト情報等をプラットフォーマサーバ１０が予め保持していることを前提とする。また、以下の説明では、２つのユーザ端末２０Ａ（ユーザ１）およびユーザ端末２０Ｂ（ユーザ２）が存在することを想定する。

まず、ステップＳ６１では、ユーザ端末２０Ａの移動ログに基づく実績経路をプラットフォーマサーバ１０において移動コードデータに登録する。このとき、ユーザ１は、ユーザ端末２０Ａを登録することで、実績経路に係る詳細の情報を登録してもよい。また、ユーザ端末２０Ａの指示によって、プラットフォーマサーバ１０のコンテンツ管理部１７は、この実績経路が他者によって利用可能となるように、コンテンツ化を行う。

ステップＳ６２では、ユーザ端末２０Ａのユーザとは異なるユーザが、ユーザ端末２０Ｂにおいて検索条件に係る情報を入力する。ステップＳ６３では、検索条件がプラットフォーマサーバ１０へ送られ、経路検索がリクエストされる。そして、ステップＳ６４では、プラットフォーマサーバ１０の検索部１１において検索条件に基づく計画経路の候補が選択される。

ステップＳ６５では、プラットフォーマサーバ１０の検索部１１が検索結果をユーザ端末２０Ｂに対して提示する。このときに、プラットフォーマサーバ１０は、コンテンツ管理部１７によってコンテンツ化された状態でユーザ端末２０Ｂに対して提示される。図１３（ａ）は、ユーザ端末２０Ｂへの提示方法の一例である。図１３（ａ）に示す例では、３つの移動経路の候補（候補Ａ～Ｃ）を出発地（Ｓ）から目的地（Ｇ）までそれぞれ地図上に表した状況を模式的に示している。また、候補Ａ～Ｃはそれぞれ経由地の有無が分かるようになっていて、例えば、候補Ａは地点Ｘを経由することが示されている。さらに、候補Ａ～Ｃはそれぞれ作者（候補の経路となる実績経路を登録したユーザ）が示されていて、例えば、候補Ａは作者１の実績経路に基づくものであることが示されている。このように、計画経路の候補を実績経路に基づいて提示をすることで、これから計画経路を選択するユーザ（ユーザ端末２０Ｂ）にとっては視覚的にも候補の概略を把握することができる。

さらに、計画経路の候補となる実績経路には、それぞれ詳細情報が含まれていてもよい。例えば、図１３（ｂ）は、候補Ａに係る経路の詳細情報の一例である。一例として、図１３（ｂ）では、移動経路を示すとともに、経路の途中に関して作者であるユーザ１が登録した詳細情報が示されている。詳細情報としては、例えば、経路の説明が文章または画像で登録されていてもよい。また、経由地の地点Ｘについては、例えば、より詳細な情報が登録されていてもよい。さらに、詳細情報としては、ユーザ１が実際に行動した日付（または日時も含む）、移動に要した費用等が登録されていてもよい。このように、プラットフォーマサーバ１０を利用するユーザが実際に移動した実績経路に基づく情報と、ユーザが登録したさらに詳細な情報を計画経路の候補として提示することしてもよい。

ステップＳ６６では、計画経路の候補を閲覧したユーザ２が候補の中から計画経路とする経路を選択する。ステップＳ６７では、ユーザ端末２０Ｂからプラットフォーマサーバ１０に対して選択結果が送信される。ここでは、ユーザ１が作成した経路（候補Ａに相当）がユーザ２によって計画経路として選択されたとする。

ステップＳ６８では、プラットフォーマサーバ１０において、計画経路に対応する移動コードデータが作成される。移動コードデータは、ユーザ１の実績経路に基づいて生成されてもよい。また、ステップＳ６９では、ユーザ２が計画経路に基づいた移動をすることで、ユーザ端末２０Ｂにおいて移動ログが取得される。そして、ステップＳ７０では、ユーザ端末２０Ｂにおいて取得された移動ログに基づいて実績経路が確定される。これらの手順は、上記実施形態で説明した手順と同様である。

ステップＳ７１では、ユーザ２がユーザ端末２０Ｂを操作し、プラットフォーマサーバ１０のコンテンツ管理部１７と通信を行うことで、実績経路に基づいた新規コンテンツを作成する。一例として、図１３（ｂ）に示した例に類する情報を登録することで、別のユーザが計画経路を選択する際の候補として提示することが可能となる。

以降のステップは、上記のコンテンツの活用を促進するための処理の一例である。ステップＳ７２では、プラットフォーマサーバ１０のコンテンツ管理部１７において、ユーザ１の作成した経路Ａを評価するカウント（例えば、当該コンテンツを利用したユーザの数を示す情報）を付与する。例えば、コンテンツ管理部１７では、計画経路の候補を閲覧したユーザが、当該候補を計画経路として選択し、さらに計画経路に基づいた実績経路が登録された場合に、計画経路の元となるコンテンツを登録したユーザ（ここでは、ユーザ１）に対してカウントを与えるというルールを決めておいてもよい。そして、上記のルールに基づいてプラットフォーマサーバ１０を利用するユーザの行動に基づいて所定のカウントを与えてもよい。

ステップＳ７３では、プラットフォーマサーバ１０のポイント管理部１８が、コンテンツ中でカウントされたカウント数に応じて、ユーザ端末２０Ａに対して付与するポイント数を算出する。一例として、カウント数と同数のポイントを付与する構成としてもよいし、所定のルールに基づいてカウント数をポイント数に換算する処理を行ってもよい。

ステップＳ７４では、プラットフォーマサーバ１０のポイント管理部１８がユーザ端末２０Ａに対するポイント付与処理を行う。ポイント付与に係る処理の手順は上述した手順と同様とすることができる。

このように、ユーザ端末２０からの移動ログに基づいて作成された実績経路に対して、必要に応じてさらなる情報を追加してコンテンツ化し、他のユーザに提示する計画経路として提示する構成とすることで、プラットフォーマサーバ１０の利用者（ユーザ）が継続してプラットフォーマサーバ１０を利用することが促進され得る。また、単なる計画経路の提示と比較して、ユーザ発信の補足情報等が追加された状態で他のユーザに対して提示をすることが可能となり、ユーザにとっても利便性が高まる可能性がある。

なお、コンテンツ化する際に、ユーザ間のコミュニケーションを活発化させること等を目的として、他のユーザが登録した実績経路（計画経路として利用され得るコンテンツ）に対してコメント等を追加する機能等を設けてもよい。また、公知のＳＮＳ（Social Networking Service）で用いられている各種機能を追加してもよい。

［プログラム］
コンピュータ１１０をプラットフォーマサーバ１０として機能させるためのプログラムは、コンピュータ１１０を検索部１１、計画経路設定部１２、運行関連情報通知部１３、移動ログ取得部１４、実績経路特定部１５、経路ルールデータベース１６、コンテンツ管理部１７、ポイント管理部１８、および決済部１９として機能させるためのプログラムコードを含む。コンピュータ１１０をユーザ端末２０として機能させるためのプログラムは、コンピュータ１１０を計画経路選定部２１、運行関連情報取得部２２、移動ログ取得部２３、送信部２４、および表示部２５として機能させるためのプログラムコードを含む。それぞれのプログラムは、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、半導体メモリなどの非一時的な記録媒体に固定的に記録された上で提供されてもよい。あるいは、それぞれのプログラムは、搬送波に重畳されたデータ信号として通信ネットワークを介して提供されてもよい。提供されたプログラムはストレージ１０３に記憶される。プロセッサ１０１がメモリ１０２と協働してそのプログラムを実行することで、対応する機能モジュールが実現する。

［作用］
以上説明したように、本開示の一側面に係るサーバ装置はプロセッサを備える。プロセッサは、ユーザの移動に係るログ情報を取得し、ユーザの移動経路を特定するためのルールを示す所与のルールデータに基づいて、ユーザが実際に移動した実績経路を特定する。

本開示の一側面に係るプログラムは、ユーザの移動に係るログ情報を取得するステップと、ユーザの移動経路を特定するためのルールを示す所与のルールデータに基づいて、ユーザが実際に移動した実績経路を特定するステップと、をサーバ装置に実行させる。

このような側面においては、ログ情報から実績経路を特定する際に、ルールデータに基づいて実績経路が特定される。そのため、ルールデータに基づいてユーザが実際に移動した経路をより高い精度で特定することができる。

他の側面に係るサーバ装置では、ルールデータが、ユーザが移動する前に作成されたユーザの計画経路に基づいてユーザの移動経路を特定するルールを示し、プロセッサが、ユーザが移動する前に作成されたユーザの計画経路を取得し、ルールデータに基づいて実績経路を特定する。この場合、ユーザの計画経路に基づいた実績経路の特定が可能となり、より高い精度での特定が可能となる。

他の側面に係るサーバ装置では、ルールデータが、ユーザが特定の場所を通過したことを特定することができる通過ログに基づいてユーザの移動経路を特定するルールを示し、プロセッサが、ログ情報としてユーザの通過ログを取得し、ルールデータに基づいて実績経路を特定する。この場合、ユーザが特定の場所を通過したことを特定することができる通過ログに基づいた実績経路の特定が可能となり、より高い精度での特定が可能となる。

他の側面に係るサーバ装置では、ルールデータが、ユーザが利用し得る交通手段の運行時刻を示す情報に基づいてユーザの移動経路を特定するルールを示し、プロセッサが、ルールデータに基づいて実績経路を特定する。この場合、ユーザが利用し得る交通手段の運行時刻を示す情報に基づいた実績経路の特定が可能となり、より高い精度での特定が可能となる。

他の側面に係るサーバ装置では、プロセッサが、特定された実績経路に基づいて、ユーザの移動に要した費用の決済処理を行う。この場合、高い精度で特定された実績経路に基づいて決済処理を行うことができ、サーバ装置を使用するユーザの利便性が高められる。

［変形例］
以上、本開示をその実施形態に基づいて詳細に説明した。しかし、本開示は上記実施形態に限定されるものではない。本開示は、その要旨を逸脱しない範囲で様々な変形が可能である。

［変形例１］
上記実施形態のうち、図１１を用いて説明したポイント付与について、ユーザ端末２０（ユーザ）の徒歩移動に対してのみポイントを付与する場合について説明したが、これに限られない。例えば、自転車での移動、自家用車での移動、バスでの移動、電車での移動など、徒歩以外のユーザ端末２０の移動について任意のポイントを付与することとしてもよい。一例では、徒歩で２ｋｍ移動する毎にユーザ端末２０に対して１００ポイントを付与するものとし、自転車で２ｋｍ移動する毎にユーザ端末２０に対して５０ポイントを付与するものとしてもよい。また、自家用車で２ｋｍ移動する毎にユーザ端末２０に対して１０ポイントを付与するものとし、バスまたは電車で２ｋｍ移動する毎にユーザ端末２０に対して３０ポイントを付与するものとしてもよい。このように、移動手段と移動距離に応じて任意のポイントを付与するものとすることができる。また、付与するポイント数は、移動手段毎に予め設定した「倍率」に比例して行ってもよい。一例では、倍率は、自家用車「１」、バス「３」、電車「３」、自転車「５」、徒歩「１０」とすることが考えられる。このように、移動手段毎にポイント付与率を異ならせることで、プラットフォーマサーバ１０は、付与率が高い移動手段を選択するようにユーザを誘導することが可能となる。なお、倍率は、日時や時刻、季節の少なくとも一つによって変更してもよい。

ユーザ端末２０が使用した移動手段を判別する方法は、たとえば、複数のネットワークとユーザ端末２０のログ情報とのマッチングに応じて移動手段を判別するものとしてもよい。すなわち、地図データベース３１は、徒歩ネットワークデータ、自転車ネットワークデータ、自動車ネットワーク、バスネットワーク、電車ネットワークの各種の移動手段に関するネットワークデータを含む。そして、ユーザ端末２０のＧＰＳのログ情報と各種ネットワークデータをマップマッチングさせ、いずれの経路を移動したかで移動手段を判別するのである。一例では、ユーザ端末２０のログ情報が徒歩ネットワーク上にある場合、そのユーザ端末２０の移動手段は徒歩であると判別する。ユーザ端末２０のログ情報が自転車ネットワーク上にある場合、そのユーザ端末２０の移動手段は自転車であると判別する。ユーザ端末２０のログ情報が自動車ネットワーク上にある場合、そのユーザ端末２０の移動手段は自動車であると判別する。ユーザ端末２０のログ情報がバスネットワーク上にある場合、そのユーザ端末２０の移動手段はバスであると判別する。ユーザ端末２０のログ情報が電車ネットワーク上にある場合、そのユーザ端末２０の移動手段は電車であると判別する。この場合、判別の精度を上げるために、ユーザ端末２０の移動速度を算出し、補完してもよい。例えば、ユーザ端末２０の移動速度が時速４.５ｋｍの場合、そのユーザ端末２０の移動手段は徒歩であると判別する。ユーザ端末２０の移動速度が時速１０ｋｍ－２０ｋｍである場合、そのユーザ端末２０の移動手段は自転車であると判別する。ユーザ端末２０の移動速度が時速３０ｋｍ－８０ｋｍである場合、そのユーザ端末２０の移動手段は自動車、バス、電車のいずれかであると判別する。また、ユーザの計画経路、ユーザの通過ログ（例えば、改札等の経由地）、公共交通機関の時刻表の少なくとも一つを用いて補完してもよい。

ポイント付与は、ユーザ端末２０の移動だけに限らず、所定スポットに立ち寄った場合に行ってもよい。ここで、所定スポットとは、典型的には、飲食店や雑貨店、テーマパークなどの商業施設、博物館、美術館、図書館、学校などの公共施設であるが、これに限らず、上述した地上に存在する任意の有体物または無体物である。所定ステップが博物館、美術館、図書館、学校などの施設の場合には、当該施設への立ち寄りがポイント付与に繋がることから、ユーザ端末２０に対して、学習へのモチベーションを高めることができる。その意味では、工場など民間施設や、石碑や城跡、古墳などもポイント付与の対象となるスポットとして好適である。このように、所定スポットへの立ち寄りにポイントを付与することで、プラットフォーマサーバ１０は、所定スポットに立ち寄るようにユーザを誘導することが可能となる。付与するポイント数は、所定スポットに滞在した滞在時間に比例して行ってもよい。また、スポット毎に異ならせてもよいし、立ち寄り日時や時刻、季節の少なくとも一つによって変更してもよい。プラットフォーマサーバ１０からユーザ端末２０に対して、所定スポットに関する情報を配信し、ユーザ端末２０の回答内容に応じてポイントを追加するようにしてもよい。

ユーザ端末２０が立ち寄ったスポットを判別する方法は、たとえば、複数のポリゴンデータとユーザ端末２０のログ情報とのマッチングに応じてユーザの立寄ったスポットを判別するものとしてもよい。すなわち、地図データベース３１は、各スポットが存在する敷地に対応するポリゴンデータを含む。そして、ユーザ端末２０のＧＰＳのログ情報とポリゴンデータをマップマッチングさせ、当該ログ情報とポリゴンデータとの内外判定により、立ち寄ったスポットを判別するのである。一例では、ユーザ端末２０のログ情報が特定のスポットの敷地に対応するポリゴンデータ上にある場合、そのユーザ端末２０はその特定のスポットに立ち寄ったと判別する。この場合、判別の精度を上げるために、ユーザの計画経路、ユーザの通過ログを用いて補完してもよい。なお、立ち寄ったスポットを判別する手段は、ポリゴンデータを用いたものに限らず、ジオフェンスを用いたものであってもよい。ジオフェンスとは、各スポットが存在する敷地に対応させて、仮想の境界線を定義し、その圏内への出入りを検出することで、立ち寄ったスポットを判別するのである。

さらに、特定の地域をテーマパークとみなして、特定テーマに沿った特定地域内の移動、スポット立ち寄りにポイントを付与するようにしてもよい。ここで、テーマは、観光、健康、学習体験など種々考えられる。テーマが学習体験の場合には、上述の博物館、美術館、図書館、学校、工場、石碑、城跡、古墳などの施設を、ポイント付与の対象となるスポットと設定することが考えられる。この場合、参加者としてのユーザ端末２０は、学習体験にあたり、チケットを購入し、学習体験後には、コメントや写真、動画を残すようにしてもよい。この場合、チケット購入、コメント付与等に対して、それぞれポイントを付与するようにしてもよい。

ユーザ端末２０が獲得したポイントに関する情報を、学習体験への参加者間で共有するようにしてもよい。この場合、獲得したポイント数をランキング形式で表示すれば、さらに学習意欲を高めることが可能である。ランキング上位者には、プラットフォーマサーバ１０からお土産をプレゼントしてもよい。また、獲得したポイントに応じて、その地域のみで使える地域通貨を付与してもよい。

ユーザ端末２０が使用した移動手段は、複数の交通機関における移動ログに含まれる通過ログから判別してもよい。例えば、図８のユーザ端末２０が出発地Ａから目的地Ｅまで、Ｂ、Ｃ、Ｄ地点を経由する場合において、ユーザ端末２０がＢ駅において種別α（一例では、在来線）から種別β（一例では、新幹線）に至る改札を通過したという通過ログが存在する場合、ユーザ端末２０の移動手段は種別β（一例では、新幹線）であると判別する。
また、ユーザ端末２０がＣ駅において種別β（一例では、新幹線）から種別α（一例では、在来線）に至る改札を通過したという通過ログが存在する場合、ユーザ端末２０の移動手段は種別α（一例では、在来線）であると判別する。また、ユーザ端末２０が出発地Ａから目的地ＧまでＦ地点を経由する場合において、ユーザ端末２０がＦ地点において種別γ（一例では、モノレール）から種別Δ（一例では、飛行機）に至る改札を通過したという通過ログが存在する場合、ユーザ端末２０の移動手段は種別Δ（一例では、飛行機）であると判別する。

［変形例２］
上記実施形態では、ユーザ端末２０が、プラットフォーマサーバ１０を利用して経路検索を行った後に計画経路をプラットフォーマサーバ１０へ送信する。ただし、計画経路は、プラットフォーマサーバ１０を用いた経路検索とは異なる方法で作成されていてもよい。例えば、ユーザ端末２０が利用可能な他のサービス等を利用して作成した計画経路をプラットフォーマサーバ１０に対して登録することで、プラットフォーマサーバ１０が提供するサービスを利用してもよい。

［変形例３］
上記実施形態ではデータベース群３０を示すが、各データベースのコピーがプラットフォーマおよび複数の事業者のそれぞれに配置されてもよい。この場合には、プラットフォーマおよび複数の事業者の間でデータベースの同期が実行され、これにより各種のデータの整合性が保証される。抽象経路データを記憶するシステムにおいて、ブロックチェーン技術ないし分散型台帳技術が適用されてもよい。

［変形例４］
本開示において、第１コンピュータが第２コンピュータ“に向けて”データまたは情報を送信するとは、第１コンピュータが、直接に、または少なくとも一つの通信装置を介して（すなわち間接的に）、第２コンピュータにデータまたは情報を送信することを意味する。

［変形例５］
本開示において、「少なくとも一つのプロセッサが、第１の処理を実行し、第２の処理を実行し、…第ｎの処理を実行する。」との表現、またはこれに対応する表現は、第１の処理から第ｎの処理までのｎ個の処理の実行主体（すなわちプロセッサ）が途中で変わる場合を含む概念を示す。すなわち、この表現は、ｎ個の処理のすべてが同じプロセッサで実行される場合と、ｎ個の処理においてプロセッサが任意の方針で変わる場合との双方を含む概念を示す。

［変形例６］
コンピュータシステム内で二つの数値の大小関係を比較する際には、「以上」および「よりも大きい」という二つの基準のどちらを用いてもよく、「以下」および「未満」の二つの基準のうちのどちらを用いてもよい。このような基準の選択は、二つの数値の大小関係を比較する処理についての技術的意義を変更するものではない。

［変形例７］
少なくとも一つのプロセッサにより実行される方法の処理手順は上記実施形態での例に限定されない。例えば、上述したステップ（処理）の一部が省略されてもよいし、別の順序で各ステップが実行されてもよい。また、上述したステップのうちの任意の２以上のステップが組み合わされてもよいし、ステップの一部が修正または削除されてもよい。あるいは、上記の各ステップに加えて他のステップが実行されてもよい。

以上の実施形態の全部または一部に記載された態様は、移動経路に関する制御、処理速度の向上、処理精度の向上、使い勝手の向上、データを利用した機能の向上または適切な機能の提供その他の機能向上または適切な機能の提供、データおよび／またはプログラムの容量の削減、装置および／またはシステムの小型化等の適切なデータ、プログラム、記録媒体、装置および／またはシステムの提供、並びにデータ、プログラム、装置またはシステムの制作・製造コストの削減、制作・製造の容易化、制作・製造時間の短縮等のデータ、プログラム、記録媒体、装置および／またはシステムの制作・製造の適切化のいずれか一つの課題を解決する。

１…情報管理システム、１０…プラットフォーマサーバ、１１…検索部、１２…計画経路設定部、１３…運行関連情報通知部、１４…移動ログ取得部、１５…実績経路特定部、１６…経路ルールデータベース、１７…コンテンツ管理部、１８…ポイント管理部、１９…決済部、２０，２０Ａ，２０Ｂ…ユーザ端末、２１…計画経路選定部、２２…運行関連情報取得部、２３…移動ログ取得部、２４…送信部、２５…表示部、３０…データベース群、３１…地図データベース、３２…移動コードデータベース、３３…ユーザデータベース、３４…広告データベース、４０…事業者サーバ。

Claims (6)

1. プロセッサを備え、
   前記プロセッサが、
   ユーザの移動に係るログ情報を取得し、
   前記ユーザの移動経路を特定するためのルールを示す所与のルールデータに基づいて、前記ユーザが実際に移動した実績経路を特定する、
   サーバ装置。
2. 前記ルールデータが、前記ユーザが移動する前に作成された前記ユーザの計画経路に基づいて前記ユーザの前記移動経路を特定するルールを示し、
   前記プロセッサが、前記ユーザが移動する前に作成された前記ユーザの計画経路を取得し、前記ルールデータに基づいて前記実績経路を特定する、請求項１に記載のサーバ装置。
3. 前記ルールデータが、前記ユーザが特定の場所を通過したことを特定することができる通過ログに基づいて前記ユーザの前記移動経路を特定するルールを示し、
   前記プロセッサが、前記ログ情報として前記ユーザの通過ログを取得し、前記ルールデータに基づいて前記実績経路を特定する、請求項１または２に記載のサーバ装置。
4. 前記ルールデータが、前記ユーザが利用し得る交通手段の時刻表に基づいて前記ユーザの前記移動経路を特定するルールを示し、
   前記プロセッサが、前記ルールデータに基づいて前記実績経路を特定する、請求項１～３のいずれか一項に記載のサーバ装置。
5. 前記プロセッサが、特定された前記実績経路に基づいて、前記ユーザの移動に要した費用の決済処理を行う、請求項１～４のいずれか一項に記載のサーバ装置。
6. ユーザの移動に係るログ情報を取得するステップと、
   前記ユーザの移動経路を特定するためのルールを示す所与のルールデータに基づいて、前記ユーザが実際に移動した実績経路を特定するステップと、
   をサーバ装置に実行させるプログラム。
   

Images