(57)【要約】【課題】ユーザの負担を軽減できる乗車管理装置を提供すること。【解決手段】乗車管理装置は、管理データベースと、位置更新ユニットと、要求受信ユニットと、乗車判断ユニットと、乗車許可送信ユニットと、を備える。管理データベースは、少なくとも、車両ＩＤ、ユーザＩＤ、乗車地点、及び車両の位置情報を関連付けた管理情報を記憶する。位置更新ユニットは、車載端末が送信する、車両の位置情報等を受信し、管理データベースにおいて、車両の位置情報を更新する。要求受信ユニットは、乗車確認要求を受信する。乗車判断ユニットは、乗車確認要求と、管理情報とを照合して、以下のＪ１〜Ｊ３の条件を充足するか否かを判断する。乗車許可送信ユニットは、Ｊ１〜Ｊ３の条件を充足すると判断した場合、乗車許可を送信する。【選択図】図２
2018128773.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも、車両ＩＤ、ユーザＩＤ、乗車地点、及び車両の位置情報を関連付けた管理情報を記憶した管理データベースと、
車載端末が送信する、その車載端末を搭載する車両の車両ＩＤ、及びその車両の位置情報を受信し、前記管理データベースにおいて、受信した車両ＩＤに関連付けられた車両の位置情報を、受信した車両の位置情報に更新する位置更新ユニットと、
前記車載端末が送信する、前記車両ＩＤ及びユーザＩＤを含む乗車確認要求を受信する要求受信ユニットと、
前記乗車確認要求と、前記管理情報とを照合して、ユーザの乗車可否を判断する乗車判断ユニットと、
前記乗車判断ユニットが乗車可と判断した場合、前記乗車確認要求を送信した前記車載端末に乗車許可を送信する乗車許可送信ユニットと、
を備える乗車管理装置。
【請求項２】
少なくとも、車両ＩＤ、ユーザＩＤ、乗車地点、及び車両の位置情報を関連付けた管理情報を記憶した管理データベースと、
車載端末が送信する、その車載端末を搭載する車両の車両ＩＤ、及びその車両の位置情報を受信し、前記管理データベースにおいて、受信した車両ＩＤに関連付けられた車両の位置情報を、受信した車両の位置情報に更新する位置更新ユニットと、
前記車載端末が送信する、前記車両ＩＤ及びユーザＩＤを含む乗車確認要求を受信する要求受信ユニットと、
前記乗車確認要求と、前記管理情報とを照合して、以下のＪ１〜Ｊ３の条件を充足するか否かを判断する乗車判断ユニットと、
前記Ｊ１〜Ｊ３の条件を充足すると前記乗車判断ユニットが判断した場合、前記乗車確認要求を送信した前記車載端末に乗車許可を送信する乗車許可送信ユニットと、
を備える乗車管理装置。
Ｊ１：前記乗車確認要求に含まれるユーザＩＤが、前記管理データベースに記憶されている。
Ｊ２：前記乗車確認要求に含まれるユーザＩＤに前記管理情報で関連付けられた車両の位置情報が、前記乗車確認要求に含まれるユーザＩＤに前記管理情報で関連付けられた乗車地点に一致する。
Ｊ３：前記乗車確認要求に含まれる車両ＩＤに前記管理情報で関連付けられた車両の位置情報が、前記乗車確認要求に含まれるユーザＩＤに前記管理情報で関連付けられた乗車地点に一致する。
【請求項３】
請求項１又は２に記載の乗車管理装置であって、
前記管理情報に含まれる車両の位置情報が、それに関連付けられた乗車地点に一致したとき、その乗車地点に関連付けられたユーザＩＤを有する携帯端末に到着通知を送信する到着通知送信ユニットをさらに備える乗車管理装置。
【請求項４】
請求項３に記載の乗車管理装置であって、
前記到着通知送信ユニットは、予め登録されたユーザＩＤを有する携帯端末には、他のユーザＩＤを有する携帯端末よりも先に前記到着通知を送信するように構成された乗車管理装置。
【請求項５】
請求項１〜４のいずれか１項に記載の乗車管理装置であって、  
前記管理情報は、乗車予定時刻をさらに含み、
携帯端末から、ユーザＩＤ及びユーザの位置情報を含むユーザ情報を受信するユーザ情報受信ユニットと、
前記ユーザ情報に含まれるユーザの位置情報と、前記ユーザ情報に含まれるユーザＩＤに関連付けられた乗車地点とから、ユーザが乗車地点に到着する予測時刻を算出する予測時刻算出ユニットと、
前記ユーザ情報に含まれるユーザＩＤに関連付けられた前記乗車予定時刻に対して、前記予測時刻の遅れが所定の閾値以上である場合、前記ユーザ情報に含まれるユーザＩＤに予め対応付けられた送信先に警告を送信する警告送信ユニットと、
をさらに備える乗車管理装置。
【請求項６】
請求項１〜５のいずれか１項に記載の乗車管理装置であって、
ユーザＩＤと、そのユーザＩＤに関する乗車予定の変更を表す変更情報と、を含む変更通知を受信する変更通知受信ユニットと、
少なくとも前記変更通知に含まれるユーザＩＤに関する前記管理情報を、前記変更情報に応じて更新する管理情報更新ユニットと、
前記管理情報の更新により生じる費用を算出する費用算出ユニットと、
をさらに備え、
前記費用算出ユニットは、更新前の前記管理情報に含まれていたが、更新後の前記管理情報には含まれない車両ＩＤが存在する場合は、それ以外の場合よりも、前記費用を高く算出するように構成された乗車管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は乗車管理装置に関する。
【背景技術】
【０００２】
特許文献１には、以下の技術が開示されている。ユーザは、配車管理サーバに配車要求を送信する。配車管理サーバは、配車要求に応じて、ユーザが指定した乗車地点に配車する。配車管理サーバは、ユーザを認証できた場合は、配車された車両の利用を可能にする。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１６−１１５３６４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
例えば、ショッピングモールや駅等の乗車地点において、複数のユーザが配車要求を送信し、複数の車両がその乗車地点に配車されることがある。特許文献１記載の技術では、ユーザは、配車された複数の車両の中から、自分に対応する１のみの車両を発見しなければならないため、車両の利用に困難が伴う。本開示の一局面は、ユーザの負担を軽減できる乗車管理装置を提供することを目的とする。
【課題を解決するための手段】
【０００５】
本開示の一態様は、少なくとも、車両ＩＤ、ユーザＩＤ、乗車地点、及び車両の位置情報を関連付けた管理情報を記憶した管理データベースと、車載端末が送信する、その車載端末を搭載する車両の車両ＩＤ、及びその車両の位置情報を受信し、前記管理データベースにおいて、受信した車両ＩＤに関連付けられた車両の位置情報を、受信した車両の位置情報に更新する位置更新ユニットと、前記車載端末が送信する、前記車両ＩＤ及びユーザＩＤを含む乗車確認要求を受信する要求受信ユニットと、前記乗車確認要求と、前記管理情報とを照合して、ユーザの乗車可否を判断する乗車判断ユニットと、前記乗車判断ユニットが乗車可と判断した場合、前記乗車確認要求を送信した前記車載端末に乗車許可を送信する乗車許可送信ユニットと、を備える乗車管理装置である。本開示の一態様である乗車管理装置は上述した課題を解決できる。
【０００６】
本開示の別の態様は、少なくとも、車両ＩＤ、ユーザＩＤ、乗車地点、及び車両の位置情報を関連付けた管理情報を記憶した管理データベースと、車載端末が送信する、その車載端末を搭載する車両の車両ＩＤ、及びその車両の位置情報を受信し、前記管理データベースにおいて、受信した車両ＩＤに関連付けられた車両の位置情報を、受信した車両の位置情報に更新する位置更新ユニットと、前記車載端末が送信する、前記車両ＩＤ及びユーザＩＤを含む乗車確認要求を受信する要求受信ユニットと、前記乗車確認要求と、前記管理情報とを照合して、以下のＪ１〜Ｊ３の条件を充足するか否かを判断する乗車判断ユニットと、前記Ｊ１〜Ｊ３の条件を充足すると前記乗車判断ユニットが判断した場合、前記乗車確認要求を送信した前記車載端末に乗車許可を送信する乗車許可送信ユニットと、を備える乗車管理装置である。
【０００７】
Ｊ１：前記乗車確認要求に含まれるユーザＩＤが、前記管理データベースに記憶されている。
Ｊ２：前記乗車確認要求に含まれるユーザＩＤに前記管理情報で関連付けられた車両の位置情報が、前記乗車確認要求に含まれるユーザＩＤに前記管理情報で関連付けられた乗車地点に一致する。
【０００８】
Ｊ３：前記乗車確認要求に含まれる車両ＩＤに前記管理情報で関連付けられた車両の位置情報が、前記乗車確認要求に含まれるユーザＩＤに前記管理情報で関連付けられた乗車地点に一致する。
【０００９】
本開示の別の態様である乗車管理装置によれば、ユーザは、乗車地点において、自分のユーザＩＤに関連付けられている車両ＩＤを有する車両（以下では予約車両とする）だけではなく、それ以外の車両（以下では予約外車両とする）にも乗車することができる。そのため、ユーザは、乗車地点において、予約車両を探す必要が無い。その結果、ユーザの負担を軽減できる。
【００１０】
また、乗車管理装置が乗車許可を送信する条件として、Ｊ１が含まれる。そのため、予約をしていないユーザが車両に乗車してしまうことを抑制できる。
また、乗車管理装置が乗車許可を送信する条件として、Ｊ２が含まれる。そのため、例えば、第１のユーザが予約外車両に乗車した場合でも、乗車地点には、第１のユーザの予約車両が到着している。第１のユーザが乗車した予約外車両を予約していた第２のユーザは、第１のユーザの予約車両に乗車することができる。
【００１１】
また、乗車管理装置が乗車許可を送信する条件として、Ｊ３が含まれる。そのため、ユーザが、本来の乗車地点以外の場所で乗車してしまうことを抑制できる。
【図面の簡単な説明】
【００１２】
【図１】乗車管理システム１及び乗車管理装置３の構成を表すブロック図である。
【図２】制御部１１の機能的構成を表すブロック図である。
【図３】管理情報４７を表す説明図である。
【図４】乗車管理装置３が実行する予約処理を表すフローチャートである。
【図５】乗車管理装置３が実行する予約変更処理を表すフローチャートである。
【図６】乗車管理装置３が実行する乗車遅れ警告処理を表すフローチャートである。
【図７】乗車管理装置３が実行する到着通知送信処理を表すフローチャートである。
【図８】乗車管理装置３が実行する乗車確認処理を表すフローチャートである。
【図９】更新前と更新後の管理情報４７を表す説明図である。
【発明を実施するための形態】
【００１３】
本開示の実施形態を図面に基づき説明する。
＜第１実施形態＞
１．乗車管理システム１及び乗車管理装置３の構成
乗車管理システム１及び乗車管理装置３の構成を図１〜図３に基づき説明する。図１に示すように、乗車管理システム１は、乗車管理装置３と、車載端末５と、第１の携帯端末７と、第２の携帯端末９と、を備える。
【００１４】
乗車管理装置３は一定の場所に固定設置される。乗車管理装置３は、制御部１１と、通信部１３と、地図ＤＢ（データベース）１５と、管理ＤＢ（データベース）１７と、を備える。
【００１５】
制御部１１は、ＣＰＵ１９と、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の半導体メモリ（以下、メモリ２１とする）と、を有する周知のマイクロコンピュータを中心に構成される。制御部１１の各種機能は、ＣＰＵ１９が非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、メモリ２１が、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムが実行されることで、プログラムに対応する方法が実行される。なお、制御部１１を構成するマイクロコンピュータの数は１つでも複数でもよい。
【００１６】
制御部１１は、ＣＰＵ１９がプログラムを実行することで実現される機能の構成として、図２に示すように、位置更新ユニット２３と、要求受信ユニット２５と、乗車判断ユニット２７と、乗車許可送信ユニット２９と、到着通知送信ユニット３１と、ユーザ情報受信ユニット３３と、予測時刻算出ユニット３５と、警告送信ユニット３７と、変更通知受信ユニット３９と、管理情報更新ユニット４１と、費用算出ユニット４３と、予約ユニット４５と、を備える。
【００１７】
制御部１１を構成するこれらの要素を実現する手法はソフトウェアに限るものではなく、その一部又は全部の要素について、一つあるいは複数のハードウェアを用いて実現してもよい。例えば、上記機能がハードウェアである電子回路によって実現される場合、その電子回路は多数の論理回路を含むデジタル回路、又はアナログ回路、あるいはこれらの組合せによって実現してもよい。
【００１８】
通信部１３は、車載端末５、第１の携帯端末７、及び第２の携帯端末９と無線通信を行う。地図ＤＢ１５は、地図情報を記憶している。
管理ＤＢ１７は管理情報を記憶している。図３に示すように、管理情報４７は、ユーザＩＤ、車両ＩＤ、乗車地点、車両の位置情報、到着までの予測所要時間、乗車予定時刻、到着フラグ、及び乗車フラグを相互に関連付けた情報である。管理ＤＢ１７は、複数の管理情報４７を記憶することができる。車両の利用に関する１つの予約に応じて、１つの管理情報４７が存在する。
【００１９】
ユーザＩＤは、ユーザの識別情報である。ユーザとは、車両に乗車する者である。車両ＩＤは車両の識別情報である。乗車地点は、ユーザが車両に乗車する地点である。車両の位置情報は、車両のリアルタイムでの位置を表す情報である。到着までの予測所要時間は、現時点から、車両が乗車地点に到着するまでの予測所要時間である。乗車予定時刻は、ユーザが車両に乗車する予定時刻である。到着フラグは、車両が乗車地点に到着していればオンになり、それ以外の場合はオフになるフラグである。乗車フラグは、ユーザが車両に乗車済みであればオンになり、それ以外の場合はオフになるフラグである。
【００２０】
車載端末５は車両に搭載されている。車載端末５及びそれを搭載する車両の数は、単数でも複数でもよい。車載端末５は、制御部４９と、通信部５１と、位置取得部５３と、ユーザＩＤ入力部５５と、表示部５６と、を備える。制御部４９は、周知のマイクロコンピュータを中心に構成され、後述する処理を実行する。また、制御部４９は、車載端末５を搭載する車両の車両ＩＤを記憶している。
【００２１】
通信部５１は、乗車管理装置３との間で無線通信を行う。位置取得部５３は、車載端末５を搭載している車両の位置情報を取得する。位置取得部５３として、例えば、ＧＰＳ等が挙げられる。ユーザＩＤ入力部５５は、第１の携帯端末７から、ユーザＩＤを読み取る。ユーザＩＤ入力部５５として、例えば、カードリーダ等が挙げられる。また、ユーザＩＤ入力部５５は、例えば、ユーザＩＤを構成する数字や文字を入力するユーザの操作を受け付けるものであってもよい。なお、第１の携帯端末７は、予め、それを保持するユーザのユーザＩＤを記憶している。ユーザＩＤ入力部５５は、車両の外表面に取り付けられている。表示部５６は、制御部４９から送られる信号に基づき、画像を表示する。
【００２２】
制御部４９は、所定時間ごとに、位置取得部５３を用いて車両の位置情報を取得する。そして、制御部４９は、車載端末５を搭載する車両の車両ＩＤと、取得した車両の位置情報とを、通信部５１を用いて、乗車管理装置３に送信する。乗車管理装置３の位置更新ユニット２３は、通信部１３を用いて、車載端末５が送信する車両ＩＤ及び車両の位置情報を受信する。そして、位置更新ユニット２３は、受信した車両ＩＤに関連付けられた車両の位置情報を、受信した車両の位置情報に更新する。また、受信した車両ＩＤがいずれかの管理情報４７に含まれている場合は、車両の位置情報の更新に応じて、到着までの予測所要時間も更新する。
【００２３】
第１の携帯端末７は、ユーザにより保持される。第１の携帯端末７及びそれを保持するユーザの数は単数でも複数でもよい。第１の携帯端末７は、制御部５７と、通信部５９と、ＨＭＩ部６１と、位置取得部６２と、を備える。制御部５７は、周知のマイクロコンピュータを中心に構成され、後述する処理を実行する。また、制御部５７は、第１の携帯端末７を保持するユーザのユーザＩＤを記憶している。通信部５９は、乗車管理装置３との間で無線通信を行う。ＨＭＩ部６１は、ユーザによる入力操作を受け付ける。また、ＨＭＩ部６１は、各種情報を表示する。位置取得部６２は、第１の携帯端末７を保持しているユーザの位置情報を取得する。位置取得部６２として、例えば、ＧＰＳ等が挙げられる。
【００２４】
第２の携帯端末９は、第３者により保持される。第３者とは、後述する予約、予約の変更等を行う者である。第２の携帯端末９及びそれを保持する第３者の数は単数でも複数でもよい。第２の携帯端末９は、制御部６３と、通信部６５と、ＨＭＩ部６７と、を備える。制御部６３は、周知のマイクロコンピュータを中心に構成され、後述する処理を実行する。また、制御部６３は、第２の携帯端末９を保持する第３者のＩＤ（以下では第３者ＩＤとする）を記憶している。通信部６５は、乗車管理装置３との間で無線通信を行う。ＨＭＩ部６７は、第３者による入力操作を受け付ける。また、ＨＭＩ部６１は、各種情報を表示する。
【００２５】
２．乗車管理装置３が実行する予約処理
乗車管理装置３の予約ユニット４５が実行する予約処理を図４に基づき説明する。図４のステップ１では、予約依頼を受信したか否かを判断する。予約依頼とは、第２の携帯端末９が送信する情報である。予約依頼は、ユーザＩＤ、乗車地点、及び乗車予定時刻を含む。なお、第３者は、ＨＭＩ部６７を用いて、ユーザＩＤ、乗車地点、及び乗車予定時刻を入力することができる。制御部６３は、入力されたユーザＩＤ、乗車地点、及び乗車予定時刻を含む予約依頼を、通信部６５を用いて送信することができる。
【００２６】
ステップ２では、空き車両が有るか否かを予約ユニット４５が判断する。空き車両とは、いずれの管理情報４７にも含まれていない車両ＩＤを有する車両である。空き車両が有る場合はステップ３に進み、空き車両が無い場合はステップ８に進む。
【００２７】
ステップ３では、予約案を作成する。予約案とは、予約依頼で指定された乗車地点に空き車両が到着するまでの予測所要時間を含む情報である。乗車地点に空き車両が到着するまでの予測所要時間は、空き車両の現在位置と、乗車地点と、地図ＤＢ１５に記憶された地図情報と、を用いて算出する。空き車両が複数ある場合は、乗車地点に最も近い空き車両を選択して、予測所要時間を算出する。
【００２８】
ステップ４では、前記ステップ３で作成した予約案を、予約依頼を送信した第２の携帯端末９に対し送信する。なお、第３者は、送信された予約案を見て、承認、又は拒否の回答を、第２の携帯端末９から送信することができる。
【００２９】
ステップ５では、第２の携帯端末９から、承認の回答を受信したか否かを判断する。承認の回答を受信した場合はステップ６に進み、それ以外の場合は本処理を終了する。
ステップ６では、予約依頼と予約案とに対応する管理情報４７を作成し、管理ＤＢ１７に記憶する。作成する管理情報４７におけるユーザＩＤ、乗車地点、及び乗車予定時刻は、予約依頼に含まれていたものである。作成する管理情報４７における車両ＩＤ、及び車両の位置情報は、予約案の作成に用いた空き車両のものである。作成する管理情報４７における、到着までの予測所要時間は、予約案に含まれていたものである。作成する管理情報４７における到着フラグと乗車フラグはいずれもオフである。
【００３０】
ステップ７では、予約が確定した旨の通知を、予約依頼を送信した第２の携帯端末９に対し送信する。
ステップ８では、予約不可の通知を、予約依頼を送信した第２の携帯端末９に対し送信する。
【００３１】
３．乗車管理装置３が実行する予約変更処理
乗車管理装置３が実行する予約変更処理を図５に基づき説明する。図５のステップ１１では、変更通知を受信したか否かを変更通知受信ユニット３９が判断する。変更通知とは、ユーザＩＤと、そのユーザＩＤに関する乗車予定の変更を表す変更情報と、を含む情報である。変更通知は、第２の携帯端末９から送信される。乗車予定の変更としては、乗車予定のキャンセル、乗車地点の変更、乗車予定時刻の変更等が挙げられる。
【００３２】
なお、第３者は、ＨＭＩ部６７を用いて、ユーザＩＤ、及び変更情報を入力することができる。制御部６３は、入力されたユーザＩＤ、及び変更情報を含む変更通知を、通信部６５を用いて送信することができる。
【００３３】
ステップ１２では、管理情報更新ユニット４１が、前記ステップ１１で受信した変更通知に応じて、管理情報４７を更新する。例えば、乗車予定の変更が、乗車予定のキャンセルである場合は、変更通知に含まれるユーザＩＤに対応する管理情報４７を削除する。そして、削除した管理情報４７に含まれていた車両ＩＤの車両（以下では新規の空き車両とする）を、他の管理情報４７において使用すれば、到着までの予測所要時間を短縮できるか否かを判断する。到着までの予測所要時間を短縮できる場合は、他の管理情報４７における車両ＩＤを、新規の空き車両の車両ＩＤに差し替える。到着までの予測所要時間も、車両ＩＤの差し替えに応じて更新する。
【００３４】
また、乗車予定の変更が、乗車地点の変更、又は乗車予定時刻の変更である場合は、乗車予定の変更の対象である管理情報４７を含む複数の管理情報４７において、車両の割り当てを最適化して、複数の管理情報４７を更新する。
【００３５】
ステップ１３では、前記ステップ１２における管理情報４７の更新により生じる費用を費用算出ユニット４３が算出する。この費用は、新規の空き車両が不要に走行した時間が長いほど、高くなるように算出される。
【００３６】
更新前の管理情報４７に含まれていたが、更新後の管理情報４７には含まれない車両ＩＤが存在する場合、その車両ＩＤの車両は、更新後の管理情報４７では有効活用できず、不要に走行した距離が長くなる。そのため、更新前の管理情報４７に含まれていたが、更新後の管理情報４７には含まれない車両ＩＤが存在する場合は、それ以外の場合よりも、算出する費用は高くなる。
【００３７】
ステップ１４では、管理情報更新ユニット４１が、変更通知を送信した第２の携帯端末９に対し、変更完了通知を送信する。変更完了通知には、前記ステップ１３で算出した費用が含まれる。なお、第２の携帯端末９は、受信した変更完了通知をＨＭＩ部６７に表示する。
【００３８】
４．乗車管理装置３が実行する乗車遅れ警告処理
乗車管理装置３が実行する乗車遅れ警告処理を図６に基づき説明する。図６のステップ２１では、ユーザ情報受信ユニット３３がユーザ情報を受信する。ユーザ情報は、第１の携帯端末７が所定時間ごとに繰り返し送信する情報である。ユーザ情報には、第１の携帯端末７を保持するユーザのユーザＩＤと、そのユーザの位置情報とが含まれる。第１の携帯端末７は、位置取得部６２を用いてユーザの位置情報を取得する。
【００３９】
ステップ２２では、予測時刻算出ユニット３５が、管理ＤＢ１７に記憶された管理情報４７を参照して、前記ステップ２１で受信したユーザ情報に含まれるユーザＩＤに関連付けられた乗車地点を読み出す。次に、予測時刻算出ユニット３５は、読み出した乗車地点と、前記ステップ２１で受信したユーザ情報に含まれるユーザの位置情報とから、ユーザが乗車地点に到着する予測時刻を算出する。なお、予測時刻算出ユニット３５は、地図ＤＢ１５に記憶された地図情報で規定される経路を、ユーザが所定の速度で進むと仮定して予測時刻を算出する。
【００４０】
ステップ２３では、予測時刻算出ユニット３５が、管理ＤＢ１７に記憶された管理情報４７を参照して、前記ステップ２１で受信したユーザ情報に含まれるユーザＩＤに関連付けられた乗車予定時刻を読み出す。
【００４１】
ステップ２４では、前記ステップ２３で読み出した乗車予定時刻に対する、前記ステップ２２で算出した予測時刻の遅れ（以下では到着遅れとする）が予め設定された所定の閾値以上であるか否かを警告送信ユニット３７が判断する。遅れが閾値以上である場合はステップ２５に進み、それ以外の場合は本処理を終了する。
【００４２】
ステップ２５では、費用算出ユニット４３が、到着遅れの長さに応じて追加課金量を算出する。
ステップ２６では、第３者への警告が必要であるか否かを警告送信ユニット３７が判断する。なお、ユーザＩＤごとに、第３者への警告が必要であるか否かと、警告する第３者が誰であるかとが、予めメモリ２１に記憶されている。警告送信ユニット３７は、前記ステップ２１で受信したユーザ情報に含まれるユーザＩＤと、メモリ２１の記憶内容とを照合して、第３者への警告が必要であるか否かを判断する。第３者への警告が必要である場合はステップ２７に進み、第３者への警告が不要の場合はステップ２８に進む。
【００４３】
ステップ２７では、前記ステップ２１で受信したユーザ情報に含まれるユーザＩＤに対応する第１の携帯端末７と、メモリ２１に記憶されている第３者に対応する第２の携帯端末９とに、警告送信ユニット３７が警告を送信する。警告には、前記ステップ２５で算出した追加課金量が含まれる。なお、警告の送信先である第３者は、ユーザ情報に含まれるユーザＩＤに予め対応付けられた送信先に対応する。
【００４４】
ステップ２８では、前記ステップ２１で受信したユーザ情報に含まれるユーザＩＤに対応する第１の携帯端末７に、警告送信ユニット３７が警告を送信する。警告には、前記ステップ２５で算出した追加課金量が含まれる。
【００４５】
５．乗車管理装置３が実行する到着通知送信処理
乗車管理装置３が実行する到着通知送信処理を図７に基づき説明する。図７のステップ３１では、いずれかの管理情報４７において、車両の位置情報が、それに関連付けられた乗車地点に一致したか否かを到着通知送信ユニット３１が判断する。車両の位置情報が、それに関連付けられた乗車地点に一致することは、車両が、それに関連付けられた乗車地点に到着することを意味する。車両の位置情報が、それに関連付けられた乗車地点に一致した場合はステップ３２に進み、それ以外の場合はステップ３１の前に戻る。
【００４６】
ステップ３２では、まず、到着通知送信ユニット３１が、前記ステップ３１において車両が到着したと判断した乗車地点（以下では到着乗車地点とする）を特定する。次に、到着通知送信ユニット３１は、管理ＤＢ１７に記憶されている全ての管理情報４７のうち、到着乗車地点を乗車地点としている全ての管理情報４７を選択する。次に、到着通知送信ユニット３１は、上記のように選択した管理情報４７に含まれる全てのユーザＩＤ（以下では通知対象ユーザＩＤとする）を読み出す。通知対象ユーザＩＤは、以下の２つの条件（ア）、（イ）をそれぞれ充足するユーザＩＤである。
【００４７】
（ア）通知対象ユーザＩＤは管理情報４７において到着乗車地点に関連付けられている。
（イ）管理情報４７において通知対象ユーザＩＤに関連付けられた車両の位置情報が、到着乗車地点に一致する。
【００４８】
なお、通知対象ユーザＩＤは、前記（ア）の条件のみを満たすものであってもよい。
次に、到着通知送信ユニット３１は、通知対象ユーザＩＤを、先に到着通知を送信するユーザＩＤと、後で到着通知を送信するユーザＩＤとに区分する。なお、メモリ２１には、先に到着通知を送信するユーザＩＤが予め登録されている。任意の通知対象ユーザＩＤが、その登録されたユーザＩＤに該当すれば、先に到着通知を送信するユーザＩＤとなり、登録されたユーザＩＤに該当しなければ、後で到着通知を送信するユーザＩＤとなる。
【００４９】
次に、到着通知送信ユニット３１は、先に到着通知を送信するユーザＩＤに対応する第１の携帯端末７に、到着通知を送信する。
ステップ３３では、前記ステップ３２で到着通知を送信してから所定時間が経過したか否かを到着通知送信ユニット３１が判断する。所定時間が経過した場合はステップ３４に進み、未だ所定時間が経過していない場合はステップ３３の前に戻る。
【００５０】
ステップ３４では、前記ステップ３２で決定した、後で到着通知を送信するユーザＩＤに対応する第１の携帯端末７に、到着通知送信ユニット３１が到着通知を送信する。
６．乗車管理装置３が実行する乗車確認処理
乗車管理装置３が実行する乗車確認処理を図８、図９に基づき説明する。図８のステップ４１では、乗車確認要求を受信したか否かを要求受信ユニット２５が判断する。乗車確認要求は、車載端末５が送信する情報である。乗車確認要求は、車載端末５を搭載する車両の車両ＩＤと、その車両に乗車しようとするユーザのユーザＩＤとを含む。
【００５１】
乗車確認要求は、以下のように作成され、送信される。ユーザは、乗車しようとする車両に近づき、第１の携帯端末７に記憶されたユーザＩＤを、車載端末５のユーザＩＤ入力部５５に入力する。車載端末５は、入力されたユーザＩＤと、車両ＩＤとを組み合わせて乗車確認要求を作成し、通信部５１を用いて送信する。なお、車両は、自動運転により、管理情報４７で規定された乗車地点に向かってもよいし、ドライバの手動運転により乗車地点に向かってもよい。
【００５２】
乗車確認要求を受信した場合はステップ４２に進み、受信していない場合はステップ４１の前に戻る。
ステップ４２では、乗車判断ユニット２７が、前記ステップ４１で受信したと判断した乗車確認要求と、管理ＤＢ１７に記憶された全ての管理情報４７とを照合する。
【００５３】
ステップ４３では、前記ステップ４２における照合の結果、以下のＪ１〜Ｊ３の条件を充足するか否かを乗車判断ユニット２７が判断する。
Ｊ１：乗車確認要求に含まれるユーザＩＤが、管理ＤＢ１７に記憶されている。
【００５４】
Ｊ２：乗車確認要求に含まれるユーザＩＤに管理情報４７で関連付けられた車両の位置情報が、乗車確認要求に含まれるユーザＩＤに管理情報４７で関連付けられた乗車地点に一致する。
【００５５】
Ｊ３：乗車確認要求に含まれる車両ＩＤに管理情報４７で関連付けられた車両の位置情報が、乗車確認要求に含まれるユーザＩＤに管理情報４７で関連付けられた乗車地点に一致する。
【００５６】
例えば、管理ＤＢ１７に記憶されている各管理情報４７が、図９における「更新前」である場合において、ユーザＩＤが「Ａ００１」であるユーザが、車両ＩＤが「２２」である車両に乗車しようとしている場合を想定する。車両ＩＤが「８」、「１５」、「２２」である車両は、到着フラグがオンであるから、乗車地点に到着している。すなわち、車両ＩＤが「８」、「２２」である車両の位置情報は、「Ａ駅」を表し、車両ＩＤが「１５」である車両の位置情報は、「Ｂ公園」を表す。
【００５７】
上記の事例において、乗車確認要求に含まれるユーザＩＤは「Ａ００１」であり、乗車確認要求に含まれる車両ＩＤは「２２」である。乗車確認要求に含まれるユーザＩＤ（「Ａ００１」）に管理情報４７で関連付けられた車両の位置情報は、車両ＩＤが「８」である車両の位置情報であって、「Ａ駅」である。乗車確認要求に含まれるユーザＩＤ（「Ａ００１」）に管理情報４７で関連付けられた乗車地点は、「Ａ駅」である。乗車確認要求に含まれる車両ＩＤ（「２２」）に管理情報４７で関連付けられた車両の位置情報は、「Ａ駅」である。
【００５８】
上記の事例の場合、乗車確認要求に含まれるユーザＩＤ（「Ａ００１」）は管理ＤＢ１７に記憶されているから、Ｊ１を充足する。
また、乗車確認要求に含まれるユーザＩＤに管理情報４７で関連付けられた車両の位置情報（「Ａ駅」）が、乗車確認要求に含まれるユーザＩＤに管理情報４７で関連付けられた乗車地点（「Ａ駅」）に一致するから、Ｊ２を充足する。
【００５９】
また、乗車確認要求に含まれる車両ＩＤに管理情報４７で関連付けられた車両の位置情報（「Ａ駅」）が、乗車確認要求に含まれるユーザＩＤに管理情報４７で関連付けられた乗車地点（「Ａ駅」）に一致するから、Ｊ３を充足する。よって、上記の事例の場合、Ｊ１〜Ｊ３の全てを充足する。
【００６０】
条件Ｊ１〜Ｊ３の全てを充足する場合はステップ４４に進み、それ以外の場合はステップ４７に進む。
ステップ４４では、乗車確認処理を送信した車載端末５に対し、乗車許可送信ユニット２９が乗車許可を送信する。なお、車載端末５は、表示部５６に乗車許可の表示を行う。また、車載端末５は、例えば、それが搭載されている車両への乗車を可能にする処理を行う。そのような処理として、例えば、ドアロックを解除する処理、エンジンの始動を許可する処理等が挙げられる。
【００６１】
ステップ４５では、前記ステップ４１で受信したと判断した乗車確認要求に含まれる車両ＩＤと、ユーザＩＤとが、１つの管理情報４７において関連付けられているか否かを判断する。例えば、上記の事例において、図９における「更新前」に示すように、ユーザＩＤである「Ａ００１」と、車両ＩＤである「２２」とは、１つの管理情報４７において関連付けられていないから、本ステップ４５では否定判断される。肯定判断の場合は本処理を終了し、否定判断の場合はステップ４６に進む。
【００６２】
ステップ４６では、管理情報更新ユニット４１が、管理情報４７の更新を行う。例えば、図９における（更新後）に示すとおり、乗車確認要求に含まれるユーザＩＤに、乗車確認要求に含まれる車両ＩＤを関連付ける。そして、乗車フラグをオンにする。
【００６３】
ステップ４７では、乗車確認処理を送信した車載端末５に対し、乗車許可送信ユニット２９が乗車不許可を送信する。なお、車載端末５は、表示部５６に乗車不許可の表示を行う。また、車載端末５は、例えば、それが搭載されている車両への乗車を禁止する処理を行う。そのような処理として、例えば、ドアロックを解除しない処理、エンジンの始動を禁止する処理等が挙げられる。
【００６４】
７．乗車管理装置３が奏する効果
（１Ａ）ユーザは、乗車地点において、自分のユーザＩＤに関連付けられている車両ＩＤを有する車両（予約車両）だけではなく、それ以外の車両（予約外車両）にも乗車することができる。そのため、ユーザは、乗車地点において予約車両を探す必要が無い。その結果、ユーザの負担を軽減できる。
【００６５】
（１Ｂ）乗車管理装置３が乗車許可を送信する条件として、Ｊ１が含まれる。そのため、予約をしていないユーザが車両に乗車してしまうことを抑制できる。
（１Ｃ）乗車管理装置３が乗車許可を送信する条件として、Ｊ２が含まれる。そのため、例えば、第１のユーザが予約外車両に乗車した場合でも、乗車地点には、第１のユーザの予約車両が到着している。第１のユーザが乗車した予約外車両を予約していた第２のユーザは、第１のユーザの予約車両に乗車することができる。
【００６６】
（１Ｄ）乗車管理装置３が乗車許可を送信する条件として、Ｊ３が含まれる。そのため、ユーザが、本来の乗車地点以外の場所で乗車してしまうことを抑制できる。
（１Ｅ）乗車管理装置３は、車両が乗車地点に到着したとき、その乗車地点に関連付けられたユーザＩＤを有する第１の携帯端末７に到着通知を送信する。そのため、ユーザは、乗車可能な車両が乗車地点に到着したことを容易に知ることができる。
【００６７】
（１Ｆ）乗車管理装置３は、予め登録されたユーザＩＤを有する第１の携帯端末７には、他のユーザＩＤを有する第１の携帯端末７よりも先に到着通知を送信する。そのため、予め登録されたユーザＩＤを有するユーザを、優先的に乗車させることができる。
【００６８】
（１Ｇ）乗車管理装置３は、乗車予定時刻に対して、予測時刻の遅れが所定の閾値以上である場合、ユーザや第３者に警告を送信する。そのため、ユーザが乗車の機会を失うことを抑制できる。
【００６９】
（１Ｈ）乗車管理装置３は、乗車予定の変更を行った場合、管理情報４７を更新し、更新のための費用を算出する。乗車管理装置３は、更新前の管理情報４７に含まれていたが、更新後の管理情報４７には含まれない車両ＩＤが存在する場合は、それ以外の場合よりも、費用を高く算出する。そのため、車両の稼動に応じて適切に費用を算出することができる。
【００７０】
なお、上記の各効果は、例えば、以下の観点から有用性が高い。IT技術の進化により、今後、予約型のモビリティの活用が進む。さらに、高齢者、幼い子供等もモビリティを活用するようになるが、特に高齢者や幼い子供は、たくさんのモビリティの中から自身の予約したモビリティを探し出すのは、非常に難しい。また、予約時間に間に合わない場合等、自身で予約変更できず、第３者からのサポートが必要になる。上記の各効果を奏することで、そのような問題を低減できる。
＜他の実施形態＞
以上、本開示の実施形態について説明したが、本開示は上述の実施形態に限定されることなく、種々変形して実施することができる。
【００７１】
（１）ユーザと第３者とは同一の者であってもよいし、別の者であってもよい。
（２）前記ステップ１３における費用の算出は行わなくてもよい。
（３）前記到着通知送信処理において、後の到着通知を送信するタイミングは、他のタイミングであってもよい。例えば、先の到着通知の送信対象であるユーザの乗車が完了してから、後の到着通知を送信してもよい。
【００７２】
（４）乗車管理装置３は、例えばクラウドサーバ上等におかれてもよい。この場合、乗車管理装置３の位置は変動し得る。
（５）第２の携帯端末は、携帯されない端末であってもよい。そのような端末として、例えば、据え置き型のＰＣ等が挙げられる。
【００７３】
（６）ユーザＩＤ入力部５５は、車両の内部に設置されていてもよい。
（７）上記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。なお、特許請求の範囲に記載した文言から特定される技術思想に含まれるあらゆる態様が本開示の実施形態である。
【００７４】
（８）上述した乗車管理装置３の他、当該乗車管理装置３を構成要素とするシステム、当該乗車管理装置３の制御部１１としてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実態的記録媒体、乗車管理方法等、種々の形態で本開示を実現することもできる。
【符号の説明】
【００７５】
１…乗車管理システム、３…乗車管理装置、５…車載端末、７…第１の携帯端末、９…第２の携帯端末、１１、４９、５７、６３…制御部、１３、５１、５９、６５…通信部、１５…地図ＤＢ、１７…管理ＤＢ、１９…ＣＰＵ、２１…メモリ、２３…位置更新ユニット、２５…要求受信ユニット、２７…乗車判断ユニット、２９…乗車許可送信ユニット、３１…到着通知送信ユニット、３３…ユーザ情報受信ユニット、３５…予測時刻算出ユニット、３７…警告送信ユニット、３９…変更通知受信ユニット、４１…管理情報更新ユニット、４３…費用算出ユニット、４５…予約ユニット、４７…管理情報、５３、６２…位置取得部、５５…ユーザＩＤ入力部、５６…表示部、６１、６７…ＨＭＩ部
【図１】
2018128773.tif 000003
【図２】
2018128773.tif 000004
【図３】
2018128773.tif 000005
【図４】
2018128773.tif 000006
【図５】
2018128773.tif 000007
【図６】
2018128773.tif 000008
【図７】
2018128773.tif 000009
【図８】
2018128773.tif 000010
【図９】
2018128773.tif 000011