JP7063154B2 - 情報処理装置および情報処理方法 - Google Patents

Description

本発明は、同一の車両に複数のユーザが同乗して移動するための技術に関する。

交通渋滞の緩和や、燃料代の節約、環境対策などの目的で、一台の車両に複数の乗員が相乗りして移動を行う形態（ライドシェア）が、諸外国を中心に広がっている。また、このような移動形態において、複数のユーザをマッチングするための技術が開発されている。

これに関連する技術として、特許文献１には、車両に相乗りして移動した複数のユーザが行ったインタラクションに関するデータを取得し、当該インタラクションに基づいてさらなる情報提供を行うシステムが記載されている。

米国特許出願公開第２０１７／０３５１９９０号明細書

一般的なライドシェアでは、面識の無い者同士が同一の車両に乗車して移動するため、より安心して利用できるように、車両に乗車するユーザに対して、正しい経路によって車両が走行しているかを伝達したいという要請がある。

本発明は上記の課題を考慮してなされたものであり、複数のユーザが同一の車両によって移動する形態において、車両の走行経路の妥当性を検証することを目的とする。

本発明の第一の態様に係る情報処理装置は、
複数のユーザが同乗して走行する車両の、所定の走行経路に関する情報を取得することと、前記車両の現在位置を取得することと、前記車両の現在位置と、前記所定の走行経路と、を比較し、前記車両が、前記所定の走行経路に沿って走行中であるか否かを判定することと、前記車両が前記所定の走行経路を逸脱したと判定した場合に、所定の装置に通知することと、を実行する制御部を備えることを特徴とする。

また、本発明の第二の態様に係る情報処理方法は、
情報処理装置が、複数のユーザが同乗して走行する車両の、所定の走行経路に関する情報を取得するステップと、前記車両の現在位置を取得するステップと、前記車両の現在位置と、前記所定の走行経路と、を比較し、前記車両が、前記所定の走行経路に沿って走行中であるか否かを判定するステップと、前記車両が前記所定の走行経路を逸脱したと判定した場合に、所定の装置に通知するステップと、を実行することを特徴とする。

また、本発明の第三の態様は、上記の情報処理方法をコンピュータに実行させるためのプログラム、または、該プログラムを非一時的に記憶したコンピュータ可読記憶媒体である。

本発明によれば、複数のユーザが同一の車両によって移動する形態において、車両の走
行経路の妥当性を検証することができる。

第一の実施形態に係るライドシェアシステムの構成概略図である。 ユーザ端末１０およびサーバ装置２０のハードウェア構成図である。 第一の実施形態におけるユーザ端末１０の機能構成図である。 第一の実施形態におけるサーバ装置２０の機能構成図である。 第一の実施形態における予約テーブルの例である。 経路からの逸脱を判定する処理のフローチャートである。 経路からの逸脱を判定する方法を説明する図である。 経路からの逸脱を判定する方法を説明する図である。 ライドシェアの概要を説明する図である。

本発明は、複数のユーザが同一の車両に相乗りする形態（ライドシェア）において、各ユーザの使用するユーザ端末と各種情報のやり取りを行うための情報処理装置である。

本発明の第一の態様に係る情報処理装置は、複数のユーザが同乗して走行する車両の、所定の走行経路に関する情報を取得し、車両の現在位置と、前記所定の走行経路と、を比較した結果に基づいて、車両が、前記所定の走行経路に沿って走行中であるか否かを判定する。
所定の走行経路とは、事前に計画された走行経路である。当該経路には、複数のユーザが乗車する地点、および、降車する地点が含まれていてもよい。

複数のユーザが同一の車両に同乗して移動する場合、様々な地点を経由するため、乗車中のユーザは、車両が正しい経路に沿って走行しているかを判断することが難しい。
そこで、本発明の第一の態様に係る情報処理装置では、車両の現在位置と、所定の走行経路とを比較し、予定している経路を走行中であるか否かを判定したうえで、車両が所定の走行経路を逸脱したと判定した場合に、所定の装置に対して通知を行う。

予定された経路を走行中であるか否かは、例えば、所定の走行経路と、実際の車両の走行経路との一致度によって判定してもよいし、予定されている所定の地点（ユーザの降車地点等）に時間内に到着できるかに基づいて判定してもよい。
かかる構成によると、車両が正しい経路を走行しているか否かを判定し、経路を逸脱した場合にユーザに通知することができる。

なお、逸脱の判定には、一定のマージンを持たせてもよい。例えば、当初の経路をリルートした場合であっても、合理的な期間内に目的地に到達可能である場合は、逸脱していないと判定してもよい。

なお、所定の装置とは、ライドシェアシステムや車両を管理する装置であってもよいし、乗車中のユーザが所持している携帯端末であってもよい。また、車両に搭載された車載装置であってもよい。

また、前記車両の、前記所定の走行経路からの逸脱の度合いを示す値である逸脱度を取得し、前記逸脱度が所定の閾値を上回っているか否かに基づいて、経路を逸脱しているか否かの判定を行ってもよい。
逸脱度が閾値を下回っている場合、渋滞の迂回など、正当な理由のある経路変更であることが想定できるためである。

また、前記所定の閾値は、第一の閾値と、前記第一の閾値よりも大きい第二の閾値からなり、前記逸脱度が前記第一の閾値以上かつ前記第二の閾値未満である場合に、前記車両が第一の状態にあると判定し、前記逸脱度が前記第二の閾値以上である場合に、前記車両が第二の状態にあると判定してもよい。

このように、逸脱度に閾値を二つ設け、逸脱が軽微なものであるか否かを判定してもよい。かかる構成によると、逸脱の度合いに応じて処理を異ならせることができる。
例えば、前記車両が前記第一の状態にある場合と、前記第二の状態にある場合とで、異なる方法によって通知を行ってもよい。これにより、例えば、逸脱が軽微な場合は視覚的な通知を行うことで経路の修正を促し、完全に逸脱したと判定された場合は警報を発するといった動作が可能になる。

また、前記車両が、前記第一の状態にある場合と、前記第二の状態にある場合とで、それぞれ異なる装置に対して前記通知を送信してもよい。これにより、例えば、逸脱が軽微な場合は車両内（車載端末、または、車両の運転者や乗員が所持する携帯端末など）にのみ通知を行い、完全に逸脱したと判定された場合はシステム管理者に通知を行うといった動作が可能になる。

逸脱度は、前記所定の走行経路上に存在する、前記ユーザの降車地点までの推定所要時間の増減率に基づいて算出してもよい。
例えば、渋滞を回避するためのリルートが発生した場合、ユーザの降車地点までの推定所要時間は、一時的に増加するが、その後は減少に転じる。一方、車両が無関係の経路を走行し始めた場合、ユーザの降車地点までの推定所要時間は増加し続けるか、減少しなくなることが予想される。よって、降車地点までの推定所要時間の推移によって、逸脱度を好適に判定することができる。

以下、本発明の具体的な実施形態について図面に基づいて説明する。各実施形態に記載されているハードウェア構成、モジュール構成、機能構成等は、特に記載がない限りは発明の技術的範囲をそれらのみに限定する趣旨のものではない。

（第一の実施形態）
まず、第一の実施形態に係るライドシェアシステムの概要について説明する。図９は、ユーザ同士が相乗りを行って移動を行う交通形態であるライドシェアについて説明するための図である。図９は、通勤によって移動を行う利用者が３人いる場合の、それぞれの自宅および職場の位置を例示した図である。

それぞれが別々に通勤を行うと、３台の車が必要となるが、相乗りを行うことによって、走行する車の台数を減らすことができる。例えば、ユーザＡ，ユーザＢ，ユーザＣは自宅と職場が共に近いため、出勤時間や退勤時間が近ければ、相乗りをすることができる。

このようなライドシェアでは、道路を走行する車両の台数を削減することができ、これにより、交通渋滞が抑制されうる。また、例えば、車両を用いた移動に要する交通費（燃料代等）を該車両のユーザでシェアして負担する（コストシェアする）ことによって、該ユーザが各々の車両で別々に移動する場合と比較して、ユーザ一人当たりの交通費を削減することができる。

第一の実施形態に係るライドシェアシステムの構成概略を図１に示す。本実施形態に係るライドシェアシステムは、ユーザが携帯するユーザ端末１０と、サーバ装置２０を含んで構成される。

本実施形態では、車両の運行を行うユーザを運転ユーザと称し、運転ユーザが運行する車両に同乗するユーザを同乗ユーザと称する。
ユーザ端末１０は、同乗ユーザが利用するモード（以下、第一のモード）と、運転ユーザが利用するモード（以下、第二のモード）に切り替え可能に構成される。以下、必要に応じて、第一のモードで動作しているユーザ端末１０をユーザ端末１０Ａと称する。また、第二のモードで動作しているユーザ端末をユーザ端末１０Ｂと称する。また、モードを区別する必要がない場合は、ユーザ端末１０と総称する。各モードにおける動作の詳細については後述する。

同乗ユーザは、ユーザ端末１０Ａを介して、相乗りを行う際の条件等に関する情報をサーバ装置２０に登録する。同乗ユーザがサーバ装置に登録する情報は、例えば、同乗ユーザの出発地、目的地、乗車希望日時、降車希望日時などである。
また、運転ユーザは、ユーザ端末１０Ｂを介して、同乗ユーザと同様に、相乗りを行う際の条件等に関する情報をサーバ装置２０に登録する。運転ユーザがサーバ装置に登録する情報は、運転ユーザが運行する車両の移動に関する情報を含み、例えば、運転ユーザの出発地、目的地、運行開始日時、到着予定日時、走行経路などである。
以降、同乗ユーザの移動に関する情報を移動スケジュールと称し、運転ユーザが行う車両の走行に関する情報を走行スケジュールと称する。また、これらをスケジュールと総称する。

これらの情報は、例えば、ユーザ端末１０にインストールされた、ライドシェアサービスを利用するためのアプリケーションソフトウェアによって生成され、サーバ装置２０に登録される。ただし、これらの情報は、必ずしも携帯端末を利用して登録されなくてもよい。例えば、ネットワークに接続可能な任意の端末（スマートフォン、携帯電話、タブレット端末、個人情報端末、ウェアラブルコンピュータ等）やパーソナルコンピュータを利用して登録されてもよい。

サーバ装置２０は、同乗ユーザおよび運転ユーザからスケジュールを取得し、各ユーザから送信されたスケジュールに基づいて、同乗ユーザと運転ユーザとの組み合わせを仮決定する。そして、決定した情報をユーザ端末１０Ａおよび１０Ｂに送信し、承諾を要求する。サーバ装置２０は、ユーザ端末１０Ａおよび１０Ｂから、相乗りの条件に承諾する情報を受信すると、ユーザの組み合わせを確定させる。以下の説明では、上記した手順でサーバ装置２０がユーザの組み合わせを生成する処理を、マッチング処理と称する。
マッチング処理によって、運転ユーザが運行する車両の経路（以下、走行予定経路）、同乗ユーザを乗車させる地点（以下、乗車地点）、同乗ユーザを降車させる地点（以下、降車地点）などが決定される。

マッチングの結果得られた情報（以下、マッチング情報）は、ユーザ端末１０Ａおよびユーザ端末１０Ｂに送信される。マッチング情報は、例えば、運転ユーザが運行する車両に関する情報（車種、色、ナンバープレート情報等）、同乗ユーザおよび運転ユーザに関する情報（性別、年齢等）、移動に関する情報（乗車地点、降車地点、乗車予定時刻、降車予定時刻、移動経路、他の同乗者の有無、移動にかかるコスト等）などを含む。そして、マッチング情報を取得した各々のユーザがマッチングを承認することによって、同乗ユーザと運転ユーザとのマッチングが確定する。これにより、車両を運行するユーザと、同乗を希望するユーザが合流して移動する事が可能になる。

本実施形態に係るライドシェアシステムにおいては、ユーザ端末１０Ａ、ユーザ端末１０Ｂ、およびサーバ装置２０が、ネットワークによって相互に接続される。ネットワークには、例えば、インターネット等の世界規模の公衆通信網であるＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）やその他の通信網が採用されてもよい。また、ネットワークは、
携帯電話等の電話通信網、Ｗｉ－Ｆｉ（登録商標）等の無線通信網を含んでもよい。

＜ハードウェア構成＞
次に、ユーザ端末１０の構成について説明する。図２は、ユーザ端末１０およびサーバ装置２０のハードウェア構成を示した図である。
ユーザ端末１０は、例えばスマートフォン、携帯電話、タブレットコンピュータ、個人情報端末、ノートブックコンピュータ、ウェアラブルコンピュータ（スマートウォッチ等）といった小型のコンピュータである。ユーザ端末１０は、制御部１０１、主記憶部１０２、補助記憶部１０３、入出力部１０４、位置取得部１０５、通信部１０６を含んで構成される。

制御部１０１は、ユーザ端末１０が行う制御を司る演算装置である。制御部１０１は、ＣＰＵ（Central Processing Unit）などの演算処理装置によって実現することができる
。

主記憶部１０２は、制御部１０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。
補助記憶部１０３は、制御部１０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。補助記憶部１０３には、制御部１０１で実行されるプログラムをアプリケーションとしてパッケージ化したものを記憶してもよい。また、これらのアプリケーションを実行するためのオペレーティングシステムを記憶してもよい。補助記憶部１０３に記憶されたプログラムが主記憶部１０２にロードされ、制御部１０１によって実行されることで、以降に説明する処理が行われる。

主記憶部１０２は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）を含んでもよい。また、補助記憶部１０３は、ＥＰＲＯＭ（Erasable Programmable ROM）
やハードディスクドライブ（ＨＤＤ、Hard Disk Drive）を含んでもよい。さらに、補助
記憶装置は、リムーバブルメディア、すなわち可搬記録媒体を含んでもよい。リムーバブルメディアは、例えば、ＵＳＢ（Universal Serial Bus）メモリ、あるいは、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）のようなディスク記録媒体である。

入出力部１０４は、利用者が行った入力操作を受け付け、利用者に対して情報を提示する手段である。本実施形態では一つのタッチパネルディスプレイからなる。すなわち、液晶ディスプレイとその制御手段、タッチパネルとその制御手段から構成される。
位置取得部１０５は、装置に備えられたＧＰＳモジュールから、ユーザ端末１０の現在位置（例えば、緯度および経度）を取得する手段である。
通信部１０６は、ユーザ端末１０をネットワークに接続するための無線通信インタフェースである。通信部１０６は、例えば、無線ＬＡＮや３Ｇ、ＬＴＥ等の移動体通信サービスを介して、ネットワークへのアクセスを提供する。

次に、サーバ装置２０のハードウェア構成について説明する。
サーバ装置２０は、一般的なコンピュータにより構成される。すなわち、サーバ装置２０は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータである。なお、リムーバブルメディアは、例えば、ＵＳＢメモリ、あるいは、ＣＤやＤＶＤのようなディスク記録媒体であってもよい。

サーバ装置２０は、制御部２０１、主記憶部２０２、補助記憶部２０３、入出力部２０４、通信部２０５を含んで構成される。
サーバ装置２０が有する補助記憶部２０３には、オペレーティングシステム（ＯＳ）、
各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを主記憶部２０２の作業領域にロードして制御部２０１が実行することによって、後述するような、所定の目的に合致した各機能を実現することができる。
制御部２０１、主記憶部２０２および補助記憶部２０３については、ユーザ端末１０と同様であるため、詳細な説明は省略する。

入出力部２０４は、システム管理者が行った入力操作を受け付け、システム管理者に対して情報を提示する手段である。入出力部２０４は、例えば、表示装置、キーボード、ポインティングデバイス等を含んで構成される。
通信部２０５は、サーバ装置２０をネットワークに接続するための通信インタフェースである。通信部２０５は、例えば、ネットワークインタフェースボードや、無線通信のための無線通信回路を含んで構成される。

なお、図２に示した構成は一例であり、図示した機能の全部または一部は、専用に設計された回路を用いて実行されてもよい。また、図示した以外の、主記憶装置および補助記憶装置の組み合わせによってプログラムの記憶ないし実行を行ってもよい。
また、図示した一部または全部の機能は、ＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。また、サーバ装置２０は、単一のコンピュータで構成されてもよいし、互いに連携する複数台のコンピュータによって構成されてもよい。

＜機能構成＞
次に、ユーザ端末１０およびサーバ装置２０の機能構成について説明する。
図３は、ユーザ端末１０によって実現される機能モジュールを示した図である。本実施形態に係るユーザ端末１０は、機能モジュールとして、スケジュール取得部１０１１、案内部１０１２、位置情報送信部１０１３、通知部１０１４を有して構成される。各機能モジュールは、記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

スケジュール取得部１０１１は、ユーザの移動に関する情報を取得する。スケジュール取得部１０１１は、ユーザ端末１０のモードに応じて、走行スケジュールまたは移動スケジュールを取得する。
具体的には、ユーザ端末１０が、第一のモード（すなわち、同乗ユーザ向けのモード）にある場合、同乗ユーザの出発地および目的地、移動を開始する日時などに関する情報を取得する。これらの情報は、移動スケジュールとして、同乗ユーザに関する情報とともにサーバ装置２０へ送信される。

また、ユーザ端末１０が、第二のモード（すなわち、運転ユーザ向けのモード）にある場合、運転ユーザの出発地および目的地、車両の運行を開始する日時、走行経路などに関する情報を取得する。これらの情報は、走行スケジュールとして、運転ユーザに関する情報とともにサーバ装置２０へ送信される。

サーバ装置２０は、複数のユーザ情報同士をマッチング（すなわち、車両を運行するユーザと、当該車両に乗車するユーザとをマッチング）し、その結果得られたマッチング情報を、対応するユーザが所持するユーザ端末１０へ送信する。
案内部１０１２は、サーバ装置２０から送信されたマッチング情報に基づいて、車両の運行についての情報をユーザに提供する。具体的には、ユーザ端末１０が第一のモードにある場合、入出力部１０４を介して、乗車地点、降車地点、車両の運行経路、運転ユーザについての情報、他の同乗ユーザについての情報、車両の特徴などを通知する。また、ユーザ端末１０が第二のモードにある場合、入出力部１０４を介して、同乗ユーザについての情報、同乗ユーザごとの乗車地点および降車地点などを通知する。

位置情報送信部１０１３は、サーバ装置２０からの要求があった場合に、位置取得部１０５を介して端末の現在位置を取得し、サーバ装置２０に送信する。
通知部１０１４は、サーバ装置２０から送信された情報に基づいて、運行中の車両が、予定されていた経路から逸脱したことを通知する。
具体的な処理内容については後述する。

図４は、サーバ装置２０によって実現される機能モジュールを示した図である。本実施形態に係るサーバ装置２０は、その機能構成要素として、マッチング部２０１１、経路照合部２０１２、通知部２０１３、予約データベース２０３１、会員データベース２０３２の機能モジュールを有して構成される。各機能モジュールは、記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

予約データベース２０３１および会員データベース２０３２は、制御部２０１によって実行されるデータベース管理システム（Database Management System）のプログラムが、補助記憶部２０３に記憶されているデータを管理することで構築される。これらのデータベースは、リレーショナルデータベースであってもよい。

予約データベース２０３１は、ライドシェアサービスの予約情報が格納されるデータベースである。具体的には、運転ユーザに関する情報と、運転ユーザが運転する車両に同乗する予定の同乗ユーザに関する情報との紐付けが行われている。
予約データベース２０３１に格納される予約情報の一例について、図５を参照して説明する。図５は、予約データベースが有するテーブル（予約テーブル）の構成を例示する図である。なお、予約テーブルに登録される情報は、図５に示す例に限られず、適宜フィールドの追加、変更、削除が可能である。

予約テーブルは、予約ＩＤ、運転者のユーザＩＤ、車両情報、同乗者のユーザＩＤ、乗車地点、乗車予定日時、降車地点、降車予定日時、走行予定経路、およびステータスのフィールドを有する。
予約ＩＤフィールドは、予約を一意に識別するための識別子が格納される。
運転者ＩＤフィールドには、相乗り可能な車両を運転するユーザ（運転ユーザ）のユーザＩＤが格納される。同様に、同乗者ＩＤフィールドには、車両に同乗するユーザ（同乗ユーザ）のユーザＩＤが格納される。なお、一つの予約（例：R002）に複数の同乗者を関連付けてもよい。

車両情報フィールドには、運転ユーザが運行する車両についての情報が格納される。車両についての情報は、車種、登録番号（ナンバープレート情報）、車体色等の情報であってもよいし、車両の識別子のみであってもよい。

乗車地点フィールドには、運転ユーザが運転する車両に同乗ユーザが乗車する場所を示す情報が格納される。また、降車地点フィールドには、同乗ユーザが車両から降車する場所を示す情報が格納される。乗車地点および降車地点は、緯度および経度で表されてもよいが、地点を特定することができれば、どのような形式で表されてもよい。例えば、住所で表されてもよいし、ランドマークの名称等で表されてもよい。
また、乗車予定日時フィールドには、対応する乗車地点において同乗ユーザが乗車する予定日時を示す情報が格納される。降車予定日時フィールドには、同乗ユーザが降車する予定日時を示す情報が格納される。

走行予定経路フィールドには、運転ユーザが運転する車両が走行する予定経路（以下、走行予定経路）を示す情報が格納される。走行予定経路は、運転ユーザが運行する車両の走行経路を特定する情報である。走行予定経路は、例えば、道路ネットワークに対応する
ノードやリンクの集合で表されてもよいし、通過する地点の集合で表されてもよい。走行予定経路は、後述するマッチングの結果に基づいて決定される。

ステータスフィールドには、相乗り状況を示す情報が格納される。例えば、同乗者がまだ乗車していない場合、「乗車前」を示す値が格納される。同乗者が乗車している場合、「乗車中」を示す値が格納され、同乗者が既に降車している場合は、「降車済み」を示す値が格納される。

会員データベース２０３２は、ライドシェアサービスに会員登録しているユーザの情報を格納するデータベースである。会員データベースには、会員の連絡先、属性、車両に関する情報などが、ユーザＩＤと関連付けられた状態で格納される。会員の連絡先は、例えば、電子メールアドレスや電話番号などである。また、会員の属性は、氏名、ハンドルネーム、年齢、性別、職業などである。これらの情報は、マッチングにおいて利用されてもよい。また、会員データベースには、ユーザが認証を行うための情報がさらに登録されていてもよい。車両に関する情報には、例えば、ナンバープレート情報、車種、色に関する情報が登録されてもよいし、車両ＩＤが登録されてもよい。また、対応するユーザが車両を有していない場合、その旨の情報が登録されてもよい。

次に、マッチング部２０１１について説明する。
マッチング部２０１１は、同乗ユーザから送信された移動スケジュールと、運転ユーザから送信された走行スケジュールと、に基づいて、ユーザ同士をマッチングする。
本実施形態におけるマッチング処理は、同乗ユーザが、運転ユーザが運行する車両に乗車して目的地に移動することが可能となるように、同乗ユーザと運転ユーザとを組み合わせる処理である。

マッチングは、運転ユーザが運行する車両の走行スケジュールと、同乗ユーザの移動スケジュールに基づいて行われる。
詳細には、同乗ユーザのユーザ端末１０Ａから送信される移動スケジュールと、運転ユーザのユーザ端末１０Ｂから送信される走行スケジュールを受信し、運転ユーザの走行スケジュールと同乗ユーザの移動スケジュールとを比較して、適合するスケジュール同士をマッチングさせる。

例えば、同乗ユーザの出発地および目的地が、運転ユーザが運行する車両の走行経路上にあり、それぞれの移動日時が互いに適合した場合、当該同乗ユーザと運転ユーザがマッチングされる。

マッチングによって、運転ユーザが運行する車両の走行予定経路が確定する。
なお、走行予定経路は、走行スケジュールに経路が含まれる場合、当該経路に基づいて生成してもよいし、運転ユーザから経路が提供されていない場合、マッチング部２０１１が動的に生成してもよい。走行予定経路を生成する場合、渋滞予測情報や通行規制情報等に基づいて、最も早く移動することができると予測される経路を選出し、選出された経路を走行予定経路に設定してもよい。

マッチングは、ユーザの承諾を条件として成立させてもよい。この場合、仮のマッチング結果をユーザ端末１０Ａおよび１０Ｂに送信し、全てのユーザから承諾が得られた場合に、正式なマッチングを成立させてもよい。
正式なマッチングが成立すると、マッチング部２０１１は、マッチング情報を生成する。マッチング情報には、マッチングの成立可否に関する情報のほか、マッチング相手に関する個人情報（例えば、名前、電話番号、メールアドレス等）等が含まれている。

マッチング情報には、このほか、一人以上の同乗ユーザの乗車地点および降車地点、予定経路、同乗ユーザおよび運転ユーザについての情報、車両の特徴などが含まれる。
生成されたマッチング情報は、ユーザ端末１０Ａおよびユーザ端末１０Ｂへ送信され、案内部１０１２を介してユーザに提示される。これにより、マッチングが成立した同乗ユーザおよび運転ユーザには、マッチング相手に関する個人情報が提供されることになる。これにより、マッチングが成立した同乗ユーザおよび運転ユーザが互いに連絡を取ることが可能となる。
マッチングが成立すると、マッチング部２０１１は、関連する情報を予約データベースに格納する。

なお、マッチング部２０１１によるマッチング処理の実行方法は、上記した方法に限られるものではなく、周知の技術を用いる他の方法でマッチング処理が行われてもよい。

経路照合部２０１２は、マッチングが成立し、同乗ユーザおよび運転ユーザが移動を開始した後で、車両が予定経路に沿って走行しているか否かを照合する。本実施形態では、周期的にユーザ端末１０の位置情報を収集して、車両の実際の走行経路と、走行予定経路との一致度を算出し、算出の結果に基づいて、車両が走行予定経路から逸脱したと判定した場合に通知を行う。
通知部２０１３は、車両が走行予定経路から逸脱したと判定した場合に、通知を行う手段である。具体的な方法については後述する。

＜処理フロー＞
次に、第一の実施形態に係るライドシェアシステムにおいてサーバ装置２０が行う処理の内容について説明する。図６は、運転ユーザと同乗ユーザが乗車した車両が走行中において実行される処理のフローチャートである。図示した処理は、予約テーブルのステータスが「乗車中」である場合に、経路照合部２０１２によって実行される。

まず、ステップＳ１１で、車両の走行予定経路を取得する。車両の走行予定経路は、予約データベース（予約テーブル）を参照することで取得できる。
次に、ステップＳ１２で、車両の現在位置を取得する。車両の現在位置は、当該車両に乗車中のユーザが所持するユーザ端末１０から位置情報を収集することで特定することができる。具体的には、予約データベースを参照して、車両に乗車中のユーザを特定し、会員データベースを参照して、当該ユーザが所持するユーザ端末１０を特定する。そして、該当するユーザ端末１０の位置情報送信部１０１３に対して位置情報の送信を要求し、当該要求に応答して送信された位置情報を収集する。
なお、車両の現在位置は、運転ユーザが所持するユーザ端末１０Ｂの位置情報に基づいて決定してもよいし、複数のユーザ端末１０から収集した複数の位置情報に基づいて決定してもよい。取得した車両の現在位置は、一時的に記憶される。

次に、ステップＳ１３で、同乗ユーザが降車を予定している地点までの推定所要時間を算出する。なお、同乗ユーザが複数人である場合、いずれかの同乗ユーザを対象として処理を行ってもよいし、推定所要時間を複数算出したうえで、その代表値を求めてもよい。
所要時間の推定は、既知の方法によって行うことができる。算出した推定所要時間は、時系列形式で一時的に記憶される。例えば、ｎタイムステップ前から、現在時刻までに算出したｎ個の推定所要時間が記憶される。

次に、ステップＳ１４で、推定所要時間の増減率を算出する。
ここで、推定所要時間の増減について説明する。図７は、時間の経過とともに変化する推定所要時間を示した図である。目的地（降車地点）までの推定所要時間は、車両が目的地に近づくにつれて減少する。よって、期間１のように、時間の経過とともに推定所要時
間が単調に減少している場合、目的地に向けて車両が順調に走行していることが推定される。
なお、期間２のように、一時的に推定所要時間が増加した後で減少に転じた場合、走行経路をリルートしたことが推定される。
一方、期間３のように、推定所要時間が下げ止まった場合、車両が走行する方向が、目的地に近づく方向から、目的地から離れる方向に変わりつつあることが推定される。
また、期間４のように、時間の経過とともに推定所要時間が増加している場合、目的地から離れる方向に車両が走行していることが推定される。
このように、車両が目的地に向けて走行しているか否かは、目的地（降車地点）までの推定所要時間の増減率に基づいて判定することができる。

第一の実施形態では、単位時間（例えば３分，５分，１０分など）における推定所要時間の増減率に基づいて、車両が所定の走行予定経路に沿って運行しているか否かを判定する。図８は、単位時間における推定所要時間の増減率を説明する図である。図示したように、単位時間における推定所要時間の増減率が大きいほど、車両が走行予定経路から逸脱していることが推定される。
ステップＳ１４では、単位時間における推定所要時間の増減率が算出される。例えば、５分が経過する間に、推定所要時間が５分減少した場合、増減率は－１００％となる。なお、複数の単位時間のそれぞれについて増減率を算出し、その代表値（平均値など）を取得してもよい。このようにして求めた値が、走行予定経路からの逸脱度を表す値となる。

次に、ステップＳ１５で、算出した増減率が、第一の閾値を超過しているか否かを判定する。第一の閾値は、経路の軽微な逸脱が推定された場合に、その旨を運転ユーザに通知するための閾値である。例えば、第一の閾値が「０％」である場合、増減率が０％を超えた場合（正の値となった場合）に肯定判定となる。

算出した増減率が、第一の閾値を超過している場合、ステップＳ１６で、算出した増減率が、第二の閾値を超過しているか否かを判定する。第二の閾値は、経路の甚大な逸脱が推定された場合に、その旨をシステム管理者に通知するための閾値である。例えば、第二の閾値が「＋５０％」である場合、増減率が５０％を超えた場合に肯定判定となる。

算出した増減率が、第一の閾値を超過しており、かつ、第二の閾値を超過していない場合、ステップＳ１８で、ユーザ端末１０への通知を行う。具体的には、運転ユーザが所持しているユーザ端末１０Ｂに対して、第一の閾値を超過した旨の通知を送信し、ユーザ端末１０Ｂの通知部１０１４が、車両が予定通りに走行していない旨を通知する。
第一の閾値は、軽微な逸脱を通知するための閾値である。よって、運転ユーザが経路を誤ったような場合、通知によってその旨を把握させることができ、本来の経路への復帰を促すことができる。

一方、算出した増減率が、第一の閾値および第二の閾値の双方を超過した場合、ステップＳ１７で、システム管理者への通知を行う。具体的には、通知部２０１３を介して警報を出力し、車両が予定通りに走行していない旨を通知する。
第二の閾値は、重度の逸脱を通知するための閾値である。ステップＳ１８で行った通知によっても経路が修正されなかった場合、システム管理者への通知が行われる。

なお、ステップＳ１７では、システム管理者に対してのみ通知を行ってもよいし、車両に乗車しているユーザにも通知を行ってもよい。例えば、運転ユーザや同乗ユーザが所持するユーザ端末１０に通知を行ってもよい。これにより、運転ユーザに対して、システム管理者に連絡を取るよう促すことができる。

以上説明したように、第一の実施形態に係るライドシェアシステムでは、走行予定経路と車両の現在位置を照合することで、予定された経路からの逸脱度を算出し、逸脱度の大小に基づいて、異なる装置へ通知を行う。かかる構成によると、軽微な逸脱であれば運転ユーザのみに通知を行い、完全な逸脱が発生した場合にのみ警報を発するといった運用が可能になる。特に、完全な逸脱が発生したと判定される前に通知を受け取ることができるため、運転ユーザの負担を軽減することができる。

なお、本実施形態では、ステップＳ１８で、運転ユーザが所持しているユーザ端末１０Ｂに対して通知を送信したが、通知は、同乗ユーザが所持しているユーザ端末１０Ａに対して送信してもよい。また、通知は、車両に備わっている車載端末に対して送信してもよい。

また、本実施形態では、同乗ユーザが降車する地点までの推定所要時間を算出したが、当該降車地点までの残り距離を算出し、判定に用いてもよい。車両が予定通りに降車地点に接近しているか否かを判定できれば、他の値を用いてもよい。

（第一の実施形態の変形例１）
第一の実施形態では、サーバ装置２０の経路照合部２０１２が車両の経路を照合したが、経路の照合は、同乗ユーザが所持するユーザ端末１０Ａ、もしくは、運転ユーザが所持するユーザ端末１０Ｂによって行ってもよい。
例えば、ユーザ端末１０が、マッチング情報に含まれている走行予定経路と、位置取得部１０５によって周期的に取得された位置情報とを照合して、経路からの逸脱度を算出するようにしてもよい。すなわち、図６に示した処理をユーザ端末１０が行ってもよい。この場合、閾値に関する情報をマッチング情報に含めてサーバ装置２０からユーザ端末１０に送信してもよい。また、推定所要時間は、外部サービスを利用して算出してもよい。

本変形例では、推定所要時間の増減率が第一の閾値を超過し、第二の閾値を超過していない場合、ユーザ端末１０が通知部１０１４を介して通知を行う。また、推定所要時間の増減率が第一の閾値と第二の閾値の双方を超過していた場合、その旨をサーバ装置２０に通知し、サーバ装置２０に通知部２０１３が警報を出力する。

（第一の実施形態の変形例２）
第一の実施形態では、目的地（降車地点）までの推定所要時間の増減率に基づいて、経路からの逸脱を判定したが、他の方法によって判定を行ってもよい。例えば、周期的に取得した車両の位置情報に基づいて、既に走行した経路（走行実績経路）を生成し、走行実績経路と走行予定経路との一致度を算出して、一致度が所定の閾値を下回った場合に、逸脱が発生したと判定してもよい。
この他にも、車両の位置と、走行予定経路との距離を算出し、当該距離に基づいて逸脱の発生を判定してもよい。例えば、車両の位置と、走行予定経路との距離が閾値を上回った状態が所定の時間を超えた場合に、逸脱が発生したと判定してもよい。
なお、これらの変形例においても、二段階の閾値を設定し、それぞれにおいて異なる方法で（または、異なる装置に）通知を行うようにすることが好ましい。

（変形例）
上記の実施形態はあくまでも一例であって、本発明はその要旨を逸脱しない範囲内で適宜変更して実施しうる。

また、実施形態の説明では、運転ユーザが車両を運行する形態を例示したが、同乗ユーザが乗車する車両は、自律走行車両であってもよい。

また、実施形態の説明では、ステップＳ１７とＳ１８とで異なる装置に通知を送信したが、同一の装置に通知を送信するようにしてもよい。また、この場合、それぞれ異なる方法（表示と警報音など）によって通知を行うようにしてもよい。また、ステップＳ１７とＳ１８とで異なる装置に通知を送信する場合、通知の送信先は例示した装置に限られない。

また、実施形態の説明では、車両が走行予定経路を逸脱した場合に通知を行ったが、逸脱が発生していない状況において、その旨を通知してもよい。かかる構成によると、ユーザに対して安心感を与えることができる。

また、同乗ユーザが不安を覚えた場合に、ユーザ端末１０からサーバ装置２０に対して通知を送信する構成を導入してもよい。かかる構成によると、システム管理者が運転ユーザに連絡を取り、状況の確認などを行わせることが可能になる。

本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本発明は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１０・・・ユーザ端末
２０・・・サーバ装置
１０１，２０１・・・制御部
１０２，２０２・・・主記憶部
１０３，２０３・・・補助記憶部
１０４，２０４・・・入出力部
１０５・・・位置取得部
１０６，２０５・・・通信部

Claims (10)

1. 複数のユーザが同乗して走行する車両について、前記複数のユーザの移動計画をマッチングすることで事前に生成され、かつ、前記複数のユーザ間で事前に共有された所定の走行経路に関する情報を取得することと、
   前記車両の現在位置を取得することと、
   前記車両の現在位置と、前記所定の走行経路と、を比較し、前記車両が、前記所定の走行経路に沿って走行中であるか否かを判定することと、
   前記車両が前記所定の走行経路を逸脱したと判定した場合に、所定の装置に通知することと、
   を実行する制御部を備える、情報処理装置。
2. 前記制御部は、前記逸脱の度合いに基づいて決定された前記所定の装置に対して前記通知を行う、
   請求項１に記載の情報処理装置。
3. 前記制御部は、前記車両の、前記所定の走行経路からの逸脱の度合いを示す値である逸脱度を取得し、前記逸脱度が所定の閾値を上回っているか否かに基づいて、前記判定を行う、
   請求項１または２に記載の情報処理装置。
4. 前記所定の閾値は、第一の閾値と、前記第一の閾値よりも大きい第二の閾値からなり、
   前記制御部は、前記逸脱度が前記第一の閾値以上かつ前記第二の閾値未満である場合に、前記車両が第一の状態にあると判定し、前記逸脱度が前記第二の閾値以上である場合に、前記車両が第二の状態にあると判定する、
   請求項３に記載の情報処理装置。
5. 前記制御部は、前記車両が前記第一の状態にある場合と、前記第二の状態にある場合とで、それぞれ異なる方法によって前記所定の装置への通知を行う、
   請求項４に記載の情報処理装置。
6. 前記制御部は、前記車両が、前記第一の状態にある場合と、前記第二の状態にある場合とで、それぞれ異なる装置に対して前記通知を送信する、
   請求項４または５に記載の情報処理装置。
7. 前記制御部は、前記車両が前記第一の状態にある場合に、前記車両の運転者が所持する端末に対して前記通知を送信する、
   請求項６に記載の情報処理装置。
8. 前記逸脱度は、前記所定の走行経路上に存在する、前記ユーザの降車地点までの推定所要時間の増減率に基づいて算出される、
   請求項３から７のいずれかに記載の情報処理装置。
9. 情報処理装置が、
   複数のユーザが同乗して走行する車両について、前記複数のユーザの移動計画をマッチングすることで事前に生成され、かつ、前記複数のユーザ間で事前に共有された所定の走行経路に関する情報を取得するステップと、
   前記車両の現在位置を取得するステップと、
   前記車両の現在位置と、前記所定の走行経路と、を比較し、前記車両が、前記所定の走行経路に沿って走行中であるか否かを判定するステップと、
   前記車両が前記所定の走行経路を逸脱したと判定した場合に、所定の装置に通知するステップと、
   を実行する、情報処理方法。
10. 請求項９に記載の情報処理方法をコンピュータに実行させるためのプログラム。

Images