JP7139164B2 - 共用車管理システム - Google Patents

Description

本発明は、ユーザにカーシェアサービスを提供するための共用車管理システムに関する。

予め登録されたユーザ間において、共用車を共同利用（カーシェアリング）するための共用車管理システムが知られている（例えば、特許文献１）。特許文献１の共用車管理システムでは、共用車として電気自動車が用いられている。共用車管理システムは、共用車の充電が必要であると判断したときに、ユーザに充電施設を提示して共用車の充電施設への移動に協力するように促す。これにより、運用者にとって共用車を充電施設への移送するためのコストを低減することができる。

特許第６１３２０６９号公報

共用車管理システムの運用者は適宜、洗車や車内の清掃などのメンテナンスを行って、各共用車の状態を維持する必要がある。しかし、このようなメンテナンスは共用車管理システムの運用者にとって負担が大きい。

本発明は、以上の背景を鑑み、共用車両管理システムにおいて、運用者の負担を低減することを課題とする。

上記課題を解決するために本発明のある態様は、複数の利用者から貸出予約を受け付けるとともに、共用車（３）の貸出を管理する管理サーバ（６）と、前記管理サーバと通信可能な端末（４）とを有する共用車管理システム（１）であって、前記端末は、前記共用車の情報を送信する情報送信部（１７，１８、７１）と、所定のメンテナンス信号を受信したときに、前記共用車を利用する前記利用者に、前記共用車のメンテナンスを促す通知を行う通知部（１９）とを有し、前記管理サーバは前記情報送信部からの前記共用車の情報に基づいて、前記共用車のメンテナンスの要否を判定する保守判定部（３１）と、メンテナンスが必要であると前記保守判定部が判定したときに、前記端末に前記メンテナンス信号を送信する信号送信部（３２）とを備えることを特徴とする。

この態様によれば、管理サーバは送信された共用車の情報に基づいて、共用車にメンテナンスが必要であるか否かを判定し、必要である場合に利用者にメンテナンスを促す通知が行われる。これにより、利用者によってメンテナンスが行われる頻度を高めることができるため、運用者の負担を低減することができる。

上記の態様において、前記共用車の情報はメンテナンスの実行に対応する情報を含み、前記管理サーバはメンテナンスの実行に対応する情報を受信したときには、メンテナンスを実行した前記利用者にインセンティブを付与するとよい。

この態様によれば、メンテナンスを実行した利用者にインセンティブが付与されるため、利用者によってメンテナンスが行われる頻度を高めることができる。

上記の態様において、前記情報送信部は前記利用者から利用した前記共用車のメンテナンス状態に対する評価値の入力を受け付けて、前記評価値を前記管理サーバに送信し、前記保守判定部は前記評価値を用いて、メンテナンスの要否を判定するとよい。

この態様によれば、共用車を利用する利用者からメンテナンス状態に対応する評価値が送信されるため、共用車にアクセスすることなく、メンテナンスの要否を判定することができる。これにより、運用者への負担を低減することができる。

上記の態様において、前記管理サーバは、前記共用車に対して、前記評価値を同一の基準に基づく絶対評価値に換算する換算部（３０）と、前記絶対評価値を記憶する評価値記憶部（２８）とを備え、前記保守判定部は前記絶対評価値に基づいて、メンテナンスの要否を判定するとよい。

この態様によれば、要否の判定が同一の基準に基づいた絶対評価値に基づいて行われる。これにより、個人差の小さい指標に基づいて要否を判定することができるため、要否の判定をより正確に行うことができる。

上記の態様において、前記端末は前記共用車の利用開始時及び利用終了時のそれぞれおいて前記評価値の受付を行い、前記換算部は、利用終了時の前記評価値を、予め前記評価値記憶部に記憶された前記絶対評価値と利用開始時の前記利用者による前記共用車の前記評価値とに基づいて、前記絶対評価値に換算し、換算された前記絶対評価値によって前記評価値記憶部に記憶された前記絶対評価値を更新し、前記保守判定部は更新後の前記絶対評価値に基づいて要否を判定するとよい。

この態様によれば、利用終了時の絶対評価値は、利用開始時の利用者による評価値と利用終了時の利用者による評価値の比と、利用開始時の絶対評価値の積によって求められる。これにより、利用者の利用開始時及び利用終了時の評価値の相対比に基づいて、利用後の絶対評価値を算出することができるため、メンテナンス状態の評価における個人差を低減することができ、メンテナンスの要否をより正確に判定することができる。

上記の態様において、前記評価値は複数の項目に対応する評価項目値を含み、前記絶対評価値は前記評価項目値のそれぞれに対応する絶対評価項目値を含み、前記保守判定部は更新された前記絶対評価値に基づいて、前記項目のそれぞれに対してメンテナンスの要否を判定するとよい。

この態様によれば、共用車の状態を複数の絶対評価項目値に基づいて複数の観点から判定することができるため、メンテナンスの要否をより正確に判定することができる。

上記の態様において、前記項目は前記共用車の外装の清潔さに対応する外装評価値と前記共用車の車内の清潔さに対応する内装評価値とを含むとよい。

この態様によれば、共用車の外装の清潔さと内装の清潔さとに基づいてメンテナンスの要否を判定することができるため、要否をより正確に判定することができる。

上記の態様において、前記情報送信部は前記共用車に搭載され、前記共用車の使用状態を検出する検出部（７２）と、前記検出部によって検出された検出結果を記録する記録部（７３）と、取得した前記使用状態を前記管理サーバに送信する状態送信部（７４）とを有し、前記保守判定部は前記端末から送信された前記使用状態に基づいて、メンテナンスの要否を判定するとよい。

この態様によれば、共用車の使用状態に基づいて共用車のメンテナンス状態を推定することができるため、共用車にアクセスすることなく、メンテナンスの要否を判定することができる。これにより、運用者の負担を低減することができる。

上記の態様において、前記検出部は加速度センサ（７６）、雨量センサ（７７）、明暗センサ（７８）、走行距離メータ（７９）、及びＧＰＳ（８１）のいずれか１つを含むとよい。

この態様によれば、検出部によって共用車のメンテナンス状態に関連する情報を簡便に且つ容易に取得することができる。

上記の態様において、前記検出部は前記雨量センサを含み、前記保守判定部は前記雨量センサからの信号に基づいて、前記利用者が洗車したことを判定する洗車判定部（９０）を備えるとよい。

この態様によれば、共用車に洗車が行われたことを検出部によって検出することができるため、共用車のメンテナンス状態をより正確に推定することができる。

上記の態様において、前記管理サーバは、前記利用者の洗車履歴を含む利用者情報を記憶する利用者情報記憶部（２７）を有し、前記保守判定部は、前記共用車にメンテナンスが必要であると判断したときに、前記利用者情報に基づいて、メンテナンスが必要であることを通知する前記利用者を選択するとよい。

この態様によれば、洗車履歴に基づいてメンテナンスの実行が期待できる利用者を選択し、その利用者にメンテナンスが必要であることを通知することができる。これにより、より効果的に通知を行うことができる。

上記の態様において、前記管理サーバは、前記利用者の前記貸出予約の受付を実行するとともに、前記貸出予約を受け付けるときに、前記利用者に走行予定経路の入力を要求し、前記保守判定部は、前記共用車にメンテナンスが必要であると判断したときに、前記走行予定経路に基づいて、メンテナンスが必要であることを通知する前記利用者を選択するとよい。

この態様によれば、走行予定経路に基づいてメンテナンスの実行が期待できる利用者を選択し、その利用者にメンテナンスが必要であることを通知することができる。これにより、より効果的に通知を行うことができる。

以上の構成によれば、共用車両管理システムにおいて、共用車管理システムの運用者の負担を低減することができる。

第１実施形態に係る共用車両管理システムの構成図 第１実施形態に係る共用車両管理システムにおいて、（Ａ）利用開始前及び（Ｂ）利用終了時の車載端末の画面表示を表す模式図 更新処理のフローチャート 絶対評価値の変化を示す説明図 第２実施形態に係る共用車両管理システムにおいて、（Ａ）利用開始前及び（Ｂ）利用終了時の車載端末の画面表示を表す模式図 第３実施形態に係る共用車両管理システムの構成図

以下、図面を参照して、共用車管理システムの実施形態について説明する。共用車管理システムは複数の共用車を所有する企業によって運用され、カーシェアリングサービスを提供する。本実施形態におけるカーシェアリングサービスとは、予め登録された複数の利用者（ユーザ）から申込の受付を行い、申込を行ったユーザに共用車を貸し出すサービスのことである。

企業はユーザが共用車の借受及び返却を行ための複数のステーションを有している。共用車の利用を希望するユーザは申込を行った後、いずれかのステーションを訪れて、共用車を借り受ける。利用後は、ユーザは再び同じステーションを訪れて、共用車を返却する。各共用車にはそれぞれを識別するための番号として共用車識別番号が割り振られ、各ステーションにはそれぞれを識別するための番号としてステーション識別番号が割り振られている。また、各利用者にはそれぞれを識別するための番号としてユーザ識別番号が割り振られている。

このようなカーシェアリングサービスでは、利用を促進するため、洗車や車室の清掃（以下、メンテナンス）を行って、共用車の状態を維持する必要がある。共用車の外装の汚れ度合は走行エリア、天候及び季節等に依存する。車室（内装）の汚れ度合は利用人数、利用時間、及び利用者の利用状況等に依存する。

＜＜第１実施形態＞＞
図１に示すように、共用車管理システム１は、複数のユーザ端末２と、共用車３それぞれに搭載された車載端末４と、複数のユーザから貸出予約を受け付けるとともに、共用車３の貸出を管理する管理サーバ６とを有する。ユーザ端末２はそれぞれユーザに所有されている。管理サーバ６は共用車管理システム１を運営する企業の建屋内に設けられ、ユーザ端末２及び車載端末４のそれぞれにネットワーク７を介して通信可能に接続されている。ネットワーク７は例えば、インターネットである。

ユーザ端末２は入力画面やメッセージを表示すると共にユーザからの入力を受け付けるユーザインタフェース９と、ユーザインタフェース９からの入力を処理する処理部１０とを備えている。ユーザ端末２は例えば、スマートフォンや携帯電話である。処理部１０は、ユーザインタフェース９に入力された申込情報を管理サーバ６に送信する予約実行部１１と、管理サーバ６から予約情報を受信したときにユーザインタフェース９に表示させる予約表示部１２とを備えている。本実施形態では、予約実行部１１及び予約表示部１２は、処理部１０において実行されるソフトウエアによって構成されている。

予約実行部１１はユーザインタフェース９に所定の入力があったときに、ユーザ識別番号、共用車３の借受場所として希望するステーションのステーション識別番号、利用開始日時及び利用終了日時を含む申込情報を入力する入力欄をユーザインタフェース９に表示させる。ユーザからの申込情報の入力が完了すると、予約実行部１１は申込情報を管理サーバ６に送信する。

予約表示部１２は、管理サーバ６から共用車３の借受可能なステーションのステーション識別番号、貸出予定の共用車３の共用車識別番号、利用開始日時、及び利用終了日時を含む予約情報を受信すると、ユーザインタフェース９に予約情報を表示させる。

車載端末４は例えばカーナビゲーション装置であり、入力画面やメッセージを表示すると共にユーザからの入力を受け付けるユーザインタフェース１５と、中央演算処理装置及び記憶装置を含み、ユーザインタフェース１５からの入力を処理する処理部１６とを備えている。処理部１６は利用開始時の共用車３の情報を送信する開始処理部１７と、利用終了時の共用車３の情報を送信する終了処理部１８と、共用車３のメンテナンスが必要であるときに利用者に通知を行うメンテナンス通知部１９とを備えている。開始処理部１７、終了処理部１８、及びメンテナンス通知部１９はそれぞれ、中央演算処理装置において実行されるソフトウエアによって構成され、ユーザインタフェース１５はタッチパネルによって構成されている。開始処理部１７及び終了処理部１８はそれぞれ、利用開始時及び利用終了時の共有車の情報送信を行う情報送信部として機能する。

開始処理部１７は管理サーバ６から所定の信号（開始信号）を受信すると、ユーザインタフェース１５に共用車３のメンテナンス状態の評価値の入力を受け付ける評価値入力欄２０と入力完了ボタン２１とを表示させる。本実施形態ではメンテナンス状態は共用車３の外装の清潔さを示し、清潔さは１～５の５段階の評価値によって表現される。評価値は清潔になるほど大きくなるように設定されている。評価値入力欄２０としては、図２（Ａ）に示すように、チェックボックスを用いたものであってもよく、また、ダイヤルやスライダーを用いたものであってもよい。入力完了ボタン２１が押圧されると、開始処理部１７は入力された評価値、及び車載端末４が搭載された共用車３の共用車識別番号を含む開始時評価情報を管理サーバ６に送信する。

終了処理部１８は管理サーバ６から所定の信号（終了信号）を受信すると、ユーザインタフェース１５に共用車３のメンテナンス状態に対応する評価値の入力を受け付ける評価値入力欄２３と、ユーザが利用中に洗車したか否かが入力される洗車入力欄２４と、返却ボタン２５とを表示させる（図２（Ｂ））。評価値入力欄２３としては利用開始時に表示されるものと同様であってよい。本実施形態では、洗車入力欄２４としてチェックボックスが用いられている。終了処理部１８は返却ボタン２５が押圧されると、洗車入力欄がチェックされているときには、洗車フラグを１とし、チェックされていないときには０として、入力された評価値、洗車フラグ、及び車載端末４が搭載された共用車３の共用車識別番号を含む終了時評価情報を管理サーバ６に送信する。

メンテナンス通知部１９は管理サーバ６から所定の信号（以下、メンテナンス信号）を受信すると、ユーザインタフェース１５に、車載端末４が搭載された共用車３に対するメンテナンス（洗車）をユーザに実行するように促すメッセージを表示させる。

管理サーバ６は中央演算処理装置、メモリ、ハードディスク等を備えたコンピュータである。管理サーバ６は各ユーザの情報を保持するユーザ情報管理部２７と、共用車３に関連する情報を保持する共用車情報管理部２８と、共用車３の予約を管理する予約管理部２９と、ユーザ端末２から受信した評価値をそれぞれ換算して、共用車情報管理部２８が保持する共用車３の情報を更新する情報更新部３０（換算部）と、メンテナンスの要否を共用車３ごとに判定する保守判定部３１と、保守判定部３１によってメンテナンスが必要であると判定されたときにメンテナンス信号を車載端末４に送信する信号送信部３２とを備えている。

ユーザ情報管理部２７（利用者情報記憶部）は、ユーザごとにユーザに関連する情報をユーザ情報（利用者情報）としてユーザ情報テーブル３４に記憶している。ユーザ情報は、ユーザ識別番号、ユーザ氏名、及び、所有するポイント数、及び洗車履歴を含む。ポイントは現金化に換えることができるものや、共用車３の利用時間の延長や商品の購入に使用できるものであってもよい。また、ポイントはグレードの高い車両やメンテナンス状態のよい車両を優先して予約できるものであってもよい。洗車履歴には、カーシェアサービスの利用時にユーザが行った洗車の回数や時間、場所等の情報が含まれるとよい。

共用車情報管理部２８（評価値記憶部）は、共用車ごとに共用車３に関連する情報（共用車情報）を共用車情報テーブル３５に記憶している。共用車情報は、共用車識別番号と、共用車が配置されているステーション識別番号、予約したユーザのユーザ識別番号（以下、予約ユーザ番号）、利用開始日時、利用終了日時、各共用車の清潔さを同一の基準に基づいて示す絶対評価値と、利用開始時の清潔さについてのユーザの評価を示す評価値（以下、利用前ユーザ評価値）とを含む。また、共用車情報は更に、共用車の型番、乗車定員、走行履歴等を含んでいてもよい。

予約管理部２９は、申込情報を受信すると、共用車情報テーブル３５を参照して、申込情報に適合する共用車を探索（マッチング）を行い、予約の可否を判定する。予約できる場合には、予約管理部２９は申込情報に含まれるユーザ識別番号、利用開始日時、及び利用終了日時を共用車情報テーブル３５の適合した共用車に対応する予約ユーザ番号、利用開始日時、及び利用終了日時にそれぞれ書き込む。その後、予約管理部２９は適合した共用車のステーション識別番号、適合した共用車の共用車識別番号、利用開始日時、及び利用終了日時を含む予約情報を作成し、対応するユーザ端末２に送信する。予約できない場合には、予約管理部２９は予約できなかったことを示すメッセージを含む予約情報を作成し、対応するユーザ端末２に送信する。

また、予約管理部２９は共用車情報テーブル３５を参照し、利用開始日時になると、対応する共用車３に搭載された車載端末４に開始信号を送信する。予約管理部２９は利用終了日時になると対応する共用車３に搭載された車載端末４に終了信号を送信する。

情報更新部３０は車載端末４から開始時評価信号を受信すると、受信した開始時評価信号に含まれる評価値を、開始時評価信号に含まれる共用車識別番号に対応する共用車３の利用前ユーザ評価値として、共用車情報テーブル３５に書き込む。

情報更新部３０は車載端末４から終了時評価信号を受信すると、更新処理を行う。以下では、更新処理について、図３を参照して説明する。

情報更新部３０は終了評価信号を受信すると、ステップＳＴ１を実行する。情報更新部３０はステップＳＴ１において、終了評価信号に含まれる洗車フラグが０であるか否かを判定する。洗車フラグが０であるときには、ステップＳＴ２を実行し、洗車フラグが１であるときには、ステップＳＴ３を実行する。

情報更新部３０はステップＳＴ２において、共用車情報テーブル３５から、終了時評価信号に含まれる共用車識別番号に対応する絶対評価値（以下、利用前絶対評価値）及び利用前ユーザ評価値を抽出する。抽出後、情報更新部３０はステップＳＴ４を実行する。

情報更新部３０はステップＳＴ４において、抽出された利用前絶対評価値を抽出された利用前ユーザ評価値で割って比を算出する。その後、情報更新部３０はステップＳＴ５を実行し、ステップＳＴ４において算出した比と終了評価信号に含まれる利用終了時の評価値（以下、利用後ユーザ評価値）との積を求めて、利用後ユーザ評価値を絶対評価値（以下、利用後絶対評価値）に換算する。次に、情報更新部３０は終了評価信号に含まれる共用車識別番号に対応する共用車情報テーブル３５の絶対評価値を、利用後絶対評価値によって更新する。利用後絶対評価値は、利用後ユーザ評価値と利用前ユーザ評価値の比に利用前絶対評価値を積算したものに相当する。その後、情報更新部３０はステップＳＴ６を実行する。

情報更新部３０はステップＳＴ６において、共用車情報テーブル３５を参照し、終了時評価信号に含まれる共用車識別番号に対応する共用車の予約ユーザ番号、利用前ユーザ評価値、利用開始日時及び利用終了日時を消去し、更新処理を終了する。

情報更新部３０はステップＳＴ３において、終了時評価信号に含まれる共用車識別番号を用いて、共用車情報テーブル３５から予約ユーザ番号を抽出し、共用車を利用したユーザのユーザ識別番号を取得する。その後、ユーザ情報テーブル３４を参照し、共用車を利用したユーザの洗車履歴を更新する。次に、情報更新部３０はステップＳＴ７を実行する。ステップＳＴ７において、情報更新部３０は共用車を利用したユーザのポイント数に所定のポイント数を加える。これにより、ユーザの所有するポイント数が増加し、洗車を行ったユーザにインセンティブが付与される。その後、情報更新部３０はステップＳＴ８を実行する。ステップＳＴ８において、情報更新部３０は終了時評価信号に含まれる共用車識別番号に対応する絶対評価値をユーザが評価値として入力することのできる値の最大値（本実施形態では５）に更新する。更新が完了すると、情報更新部３０はステップＳＴ６を実行する。

保守判定部３１は開始時評価信号を受信すると、開始時評価信号に含まれる共用車識別番号に対応する絶対評価値を参照し、判定処理を行う。保守判定部３１は判定処理において、絶対評価値が評価閾値以下である場合には、保守判定部３１はメンテナンスが必要であると判定し、絶対評価値が評価閾値より大きい場合には、メンテナンスは不要であると判定する。

評価閾値は企業に所属する一名の基準者が共用車３にメンテナンスが必要であると判断する評価値に基づいて定められる。本実施形態では、評価閾値は２に定められている。

信号送信部３２はメンテナンスが必要であると保守判定部３１が判定したときに、開始時評価信号に含まれた共用車識別番号に対応する車載端末４にメンテナンス信号を送信する。

次に、図４を参照して、共用車管理システム１の動作について説明する。利用者（ユーザＡ）がユーザ端末２を用いて、共用車３の借受場所として希望するステーション、利用開始日時及び利用終了日時を含む申込情報を入力し、管理サーバ６に送信する。管理サーバ６の予約管理部２９は申込情報を受信すると、共用車情報テーブル３５を参照して、申込情報に適合する共用車を探索し、共用車情報テーブル３５を更新するとともに、予約情報を返信する。ユーザ端末２は予約情報を受信すると、ユーザインタフェース９には借受を行うステーションのステーション識別番号、貸出予定の共用車３の共用車識別番号、利用開始日時、及び利用終了日時が表示される。

ここでは、申込情報に適合する共用車３として企業が取得した共用車３が初めて貸出される場合を想定する。共用車３の貸出が開始されるときには共用車３は洗車され、共用車の絶対評価値は５に設定されている。

利用開始日時になると、予約管理部２９は貸し出される共用車３の車載端末４に開始信号を送信する。車載端末４は開始信号を受信すると、車載端末４のユーザインタフェース１５には評価値入力欄２０及び入力完了ボタン２１が表示される。ユーザが評価値入力欄２０に利用開始時の評価値を入力して入力完了ボタン２１を押圧すると、開始時評価信号が管理サーバ６に送信される。ここでは、ユーザＡは利用開始時の評価値として４を入力したとする（図２（Ａ））。

情報更新部３０は開始時評価信号を受信すると、情報更新部３０は開始時評価信号から評価値を抽出し、その評価値を貸し出される共用車３の利用前ユーザ評価値として共用車情報テーブル３５に記入する。

また、同時に保守判定部３１は開始時評価信号を受信する。保守判定部３１は開始時評価信号を受信すると判定処理を行う。保守判定部３１は判定処理において、貸し出される共用車３の絶対評価値が評価閾値以下であるかを判定する。絶対評価値は５であり、評価閾値は２であるため、保守判定部３１は絶対評価値が評価閾値よりも大きいと判定し、判定処理を終える。

利用終了日時になると、予約管理部２９は終了信号を車載端末４に送信する。車載端末４が終了信号を受信すると、車載端末４のユーザインタフェース１５には、評価値入力欄２３、洗車入力欄２４、及び返却ボタン２５が表示される。ユーザが共用車３を返却するときには、利用終了時の評価値を評価値入力欄２３に入力するとともに、洗車入力欄２４に入力して、返却ボタン２５を押圧する。これにより、終了時評価信号が管理サーバ６に送信される。ここでは、ユーザＡは利用中に洗車することなく共用車３を返却するものとし、ユーザＡは洗車入力欄２４にチェックを入れず、かつ利用終了時の評価値として３を評価値入力欄２３に入力したものとする（図２（Ｂ））。

情報更新部３０は終了時評価信号を受信すると、更新処理を実行する。情報更新部３０は終了時評価信号に含まれる評価値を絶対評価値に換算し、その絶対評価値を用いて共用車情報テーブル３５の絶対評価値を更新する。更新後、情報更新部３０は、対応する共用車の予約ユーザ番号、利用前ユーザ評価値、利用開始日時及び利用終了日時を消去して、更新処理を終える。

ユーザＡは利用開始時に評価値として４を送信し、利用終了時に評価値として３を送信したため、利用終了時の絶対評価値は、５／４×３＝３．７５となっている。

次に共用車３が他のユーザＢに貸し出される場合にも、同様の処理が行われる。利用開始日時になると、車載端末４のユーザインタフェース１５には評価値入力欄２０及び入力完了ボタン２１が表示される。ユーザが評価値を入力して入力完了ボタン２１を押圧すると、開始時評価信号が管理サーバ６に送信される。ここでは、ユーザＢは評価値として４を入力したとする。情報更新部３０は開始時評価信号を受信すると、共用車３の利用前ユーザ評価値を４に更新する。同時に、保守判定部３１は開始時評価信号を受信すると、判定処理を行う。保守判定部３１は判定処理において、絶対評価値は３．７５であり、評価閾値は２であるため、保守判定部３１は絶対評価値が評価閾値よりも大きいと判定し、判定処理を終える。

利用終了日時になると、車載端末４のユーザインタフェース１５には評価値入力欄２３、洗車入力欄２４及び返却ボタン２５が表示される。ユーザＢは評価値入力欄２３及び洗車入力欄２４に入力し、返却ボタン２５を押圧すると、終了時評価信号が管理サーバ６に送信される。ここでは、ユーザＢは利用中に洗車することなく共用車３を返却するものとし、ユーザＢは洗車入力欄２４にチェックを入れず、かつ利用終了時の評価値として２を評価値入力欄２３に入力したものとする。

情報更新部３０は終了時評価信号を受信すると更新処理を実行する。利用開始時には評価値として４が送信され、利用終了時に評価値として２が送信されているため、利用終了時の絶対評価値は、３．７５／４×２＝１．８７５となる。情報更新部３０は、共用車情報テーブル３５の絶対評価値を利用終了時の絶対評価値１．８７５に更新した後、更新処理を終える。

その次に共用車３が他のユーザＣに貸し出される場合にも、同様の処理が行われる。利用開始日時になると、車載端末４のユーザインタフェース１５には評価値入力欄２０及び入力完了ボタン２１が表示され、ユーザＣが評価値入力欄２０に評価値を入力して入力完了ボタン２１を押圧する。ここでは、ユーザＣは評価値として２を入力したとする。これにより、開始時評価信号が管理サーバ６に送信され、情報更新部３０は共用車３の利用前ユーザ評価値を２に更新する。同時に、保守判定部３１が判定処理を行う。保守判定部３１は判定処理において、絶対評価値１．８７５が評価閾値である２よりも小さいため、メンテナンスが必要であると判定し、信号送信部３２が車載端末４にメンテナンス信号を送信する。車載端末４はメンテナンス信号を受信すると、ユーザＣに洗車の実行を促すメッセージが表示される。ここでは、ユーザＣはメッセージに従って洗車を実行したものとする。

利用終了日時になると、車載端末４のユーザインタフェース１５には評価値入力欄２３、洗車入力欄２４及び返却ボタン２５が表示される。ユーザＣは評価値入力欄２３に評価値を入力し、洗車入力欄２４にチェックを入れて、返却ボタン２５を押圧する。これにより、終了時評価信号が管理サーバ６に送信される。但し、洗車入力欄２４にチェックが入力されているため、洗車フラグは１となっている。管理サーバ６が終了時評価信号を受信すると、情報更新部３０が更新処理を実行する。情報更新部３０はユーザの洗車履歴を更新し、ユーザＣのポイント数に所定のポイント数を加え、ユーザＣにインセンティブを付与する。更に、情報更新部３０は、共用車情報テーブル３５の絶対評価値を５に更新して、更新処理を終える。

次に、共用車管理システム１の効果について説明する。共用車３にメンテナンスが必要であるか否かを、絶対評価値が評価閾値以下となっているかによって判定することができ、共用車３にメンテナンスが必要であるときに、車載端末４にメッセージが表示され、ユーザに洗車を促す通知が行われる。これにより、ユーザによって洗車が行われる頻度を高めることができる。これにより、共用車管理システム１の運用者の負担を低減することができる。

また、洗車を行ったユーザには所定のポイント数が与えられる。これにより、ユーザに洗車を行おうとするインセンティブを付与することができるため、共用車管理システム１の運用者の負担をより低減することができる。

管理サーバ６はメンテナンスの要否を判定するために要する共用車３のメンテナンス状態を、ユーザから送信される評価値に基づいて取得する。そのため、共用車管理システム１の運営者は共用車３に直接アクセスし、その外装の汚れ具合を目視する必要がない。そのため、共用車管理システム１の運用者への負担を低減することができる。

ユーザから送信される評価値は個人的な指標に依存しやすく個人差が大きい。特に、利用開始時のユーザの評価値や利用終了時のユーザの評価値そのものは、評価値が５（最も高い）ときのメンテナンス状態や評価値が１（最も低い）ときのメンテナンス状態を各ユーザがどのように想定するかに依存しやすく、個人差が大きい。一方、利用開始時のユーザの評価値と利用終了時のユーザの評価値の比は利用によるメンテナンス状態の変化に依存するため、評価値そのものよりも、個人差が小さい。本実施形態では、情報更新部３０は利用開始時のユーザの評価値と利用終了時のユーザの評価値の比に基づいて絶対評価値を貸出ごとに更新し、保守判定部３１がその絶対評価値に基づいてメンテナンスの要否を判定している。これにより、評価値の個人差を低減することができ、メンテナンスの要否をより正確に判定することができる。

＜＜第２実施形態＞＞
第２実施形態に係る共用車管理システムは、第１実施形態に比べて、評価値が複数の項目に対応する評価項目値を含み、絶対評価値がそれらの項目のそれぞれに対応する複数の絶対評価項目値を含む点が異なる。本実施形態では、評価値は車室内の清潔さを示す内装評価値と共用車３の外装の清潔さを示す外装評価値とを含む。図５（Ａ）及び（Ｂ）に示すように、利用開始時には車載端末４のユーザインタフェース１５には、内装に対応する評価項目値である内装評価値が入力される内装評価値入力欄５１、５２、及び外装に対応する評価項目値である外装評価値が入力される外装評価値入力欄５３、５４が表示される。

絶対評価値は、内装評価値を同一の基準に基づいて換算した内装絶対評価値と、外装評価値を同一の基準に基づいて換算した外装絶対評価値とを含む。内装絶対評価値は車内清掃後に所定の最大値に設定され、情報更新部３０は第１実施形態と同様に、貸出ごとに、内装絶対評価値をユーザの利用前後の内装評価値の比に基づいて更新する。外装評価値は洗車後に所定の最大値に設定され、情報更新部３０は第１実施形態と同様に、貸出ごとに、外装絶対評価値をユーザの利用前後の外装評価値の比に基づいて更新する。

保守判定部３１は更新された内装絶対評価値及び外装絶対評価値に基づいて、それぞれに対してメンテナンスの要否を判定する。より具体的には、保守判定部３１は内装絶対評価値が所定の内装評価閾値以下となったときに、車載端末４に所定の信号（内装メンテナンス信号）を送信する。車載端末４は内装メンテナンス信号を受信すると、ユーザインタフェース１５に車内の清掃が必要であることを示すメッセージを表示する。保守判定部３１は外装絶対評価値が所定の外装評価閾値以下となったときに、車載端末４に所定の信号（外装メンテナンス信号）を送信する。車載端末４は外装メンテナンス信号を受信すると、ユーザインタフェース１５に洗車が必要であることを示すメッセージを表示する。利用終了時には、車載端末４のユーザインタフェース１５には、車内の清掃を行った場合にチェックを入れる清掃入力欄５５と、洗車を行った場合にチェックを入れる洗車入力欄５６とが表示される。

ユーザは車内の清掃を行う場合には、企業によって予め契約されたガソリンスタンドに共用車３を移動させ、車内の清掃を依頼する。その後、ユーザは利用終了時に、ユーザは内装入力欄にチェックを入れて、返却ボタン２５を押す。これによって、車内端末から終了時評価信号が送信される。情報更新部３０は第１実施形態と同様に更新処理を実行し、ステップＳＴ８において内装絶対評価値のみを５に更新する。

ユーザは洗車を行う場合には、企業によって予め契約されたガソリンスタンドに共用車３を移動させて、洗車を実行する。その後、ユーザは利用終了時に、ユーザは外装入力欄にチェックを入れて、返却ボタン２５を押す。これによって、車内端末から終了時評価信号が送信される。情報更新部３０は第１実施形態と同様に更新処理を実行し、ステップＳＴ８において外装絶対評価値のみを５に更新する。

次に、第２実施形態に係る共用車管理システムの効果について説明する。メンテナンスの要否は内装及び外装のそれぞれに対する２つの絶対評価項目値に基づいて判定される。そのため、共用車３の外装の清潔さ及び車室内の清潔さの２つの観点から共用車３の状態を把握することができ、メンテナンスの要否をより正確に判定することができる。

＜＜第３実施形態＞＞
第３実施形態に係る共用車管理システムは、図６に示すように、第１実施形態及び第２実施形態に比べて共用車３に搭載される車載端末４の構成が異なる。車載端末４は第１実施形態の構成に加えて、共用車３の使用状態を検出して、管理サーバ６に使用状態を送信する状態送信部７１を含む。状態送信部７１は共用車３の使用状態を検出する検出部７２と、検出部７２によって検出された検出結果を走行ログとして記録する記録部７３と、取得した走行ログを管理サーバ６に送信する記録送信部７４とを含む。検出部７２は公知の加速度センサ７６、雨量センサ７７、明暗センサ７８、走行距離メータ７９、ドライブレコーダ８０、及びＧＰＳ８１を含む。記録部７３は走行ログの記録を開始することを指示する信号（開始信号）を受信すると、走行ログの記録を開始し、管理サーバ６から走行ログの記録を終えることを指示する信号（終了信号）を受信すると、記録送信部７４に取得した走行ログを管理サーバ６に送信するように指示する。本実施形態では、状態送信部７１は共用車３の車体において、ユーザインタフェース１５及び処理部１６とは異なる位置に配置されている。

管理サーバ６は、共用車３の状態を管理する共用車情報管理部２８と、ユーザの申込を受け付け、利用開始時間及び利用終了時間を含む予約情報を管理する予約管理部２９と、メンテナンスの要否を判定する保守判定部３１と、メンテナンスが必要と判定された共用車３の車載端末４にメンテナンス信号を送信する信号送信部３２とを備えている。管理サーバ６は、ネットワーク７を介して、リアルタイムに渋滞状況を取得する道路情報サーバ８２や各地域での天候や風速を取得する天気情報サーバ８３に接続されている。保守判定部３１は貸出ごとに終了時の共用車３の汚れ具合に対する評価値（汚れ評価値）を保持している。

予約管理部２９は利用開始日時になると車載端末４に開始信号を送信する。車載端末４は開始信号を受信すると走行ログの記録を開始する。予約管理部２９は利用終了日時になると車載端末４に終了信号を送信する。車載端末４は終了信号を受信すると、利用開始日時から利用終了日時までの走行ログを管理サーバ６に送信する。保守判定部３１は前回の利用終了時の共用車３の汚れ評価値と受信した走行ログとに基づいて、利用終了時の共用車３の汚れ評価値を推定する推定処理を実行する。推定処理を実行した後、保守判定部３１は推定された汚れ評価値に基づいて、メンテナンスの要否を判定する。メンテナンスが必要と判定され、且つその共用車３が貸し出される利用開始日時になったときに、送信部は車載端末４に所定の信号（メンテナンス信号）を送信する。車載端末４はメンテナンス信号を受信すると、ユーザインタフェース１５にメンテナンスが必要であることを示すメッセージを表示する。

次に、保守判定部３１によって行われる推定処理について説明する。本実施形態では、汚れ評価値は汚れ度合が大きくなるにつれて値が大きくなるように設定されている。推定処理において、保守判定部３１は走行ログに基づいて、道路情報サーバ８２及び天気情報サーバ８３を参照して、利用開始日時から利用終了日時までの共用車３の全走行距離や、その間の天候の変化（天候履歴）や季節、走行エリア等を取得する。次に、保守判定部３１は前回の利用終了時の共用車３の汚れ評価値に、走行時の天候が雨又は雪である場合に大きくなるパラメータとそれぞれの天候に対応する走行距離との積と、走行エリアに依存するパラメータとその走行エリア内での走行距離との積と、季節に依存するパラメータと全走行距離との積との和を加えることによって、利用終了時の汚れ評価値を推定する。走行エリアに依存するパラメータは例えば、路面が舗装されていないエリアに対して高くなるように設定されているとよい。季節に依存するパラメータは例えば、利用開始日時及び利用終了日時が梅雨の期間に該当する場合に他の期間に比べて高くなるように設定されているとよい。

本実施形態では、保守判定部３１は雨量センサ７７の検出結果に基づいて、利用者が洗車したことを判定する洗車判定部９０を備えている。より具体的には、保守判定部３１は天気情報サーバ８３を参照して、雨量センサ７７によって所定の雨量が検出されたときには、その雨量が雨によるものであるか洗車によるものなのかを判定する。保守判定部３１は、雨でない場合には洗車が行われたと判定し、汚れ評価値をリセット（例えば零）にするとよい。

次に、第３実施形態に係る共用車管理システムの効果について説明する。共用車３の走行履歴や走行環境などを含む使用状態は共用車３に搭載された検出部７２によって検出される。その使用状態は記録送信部７４から管理サーバ６に送信され、保守判定部３１は受信した使用状態に基づいて、共用車３のメンテナンス状態を推定することができる。そのため、運営者は共用車３が載置された場所や共用車３が返却されるステーションを直接訪れることなく、メンテナンスの要否を判定することができる。これにより、運用者への負担を低減することができる。

また、共用車３の使用状態を取得する検出部７２は加速度センサ７６、雨量センサ７７、明暗センサ７８、走行距離メータ７９、ドライブレコーダ８０、及びＧＰＳ８１によって構成されているため、共用車３の使用状態に関連する情報を簡便に且つ容易に取得することができる。また、本実施形態では、検出部７２は加速度センサ７６、雨量センサ７７、明暗センサ７８、走行距離メータ７９、ドライブレコーダ８０、及びＧＰＳ８１を全て含んでいたが、検出部７２はこれらのうち少なくとも１つを含んでいれば良い。

＜＜第４実施形態＞＞
第４実施形態に係る共用車管理システムは、第１実施形態に比べて、申込情報にユーザの走行予定経路を含む点が異なる。ユーザ端末２は予約時にユーザインタフェース９に走行予定経路の記入欄を表示し、ユーザに走行予定経路の入力を要求する。共用車情報は、第１実施形態と同様に、共用車識別番号、ステーション識別番号、予約ユーザ番号、利用開始日時、利用終了日時、絶対評価値、及び利用前ユーザ評価値を含み、更に走行予定経路を含んでいる。予約管理部２９は受信した走行予定経路をユーザ情報テーブル３４に保存する。

保守判定部３１は、共用車３にメンテナンスが必要であると判断したときに、ユーザ情報テーブル３４を参照し、共用車３の走行予定経路を取得する。保守判定部３１はその走行予定経路上に洗車を行うことができる場所（例えば、企業が予め契約したガソリンスタンド等）がある場合には、車載端末４にメンテナンス信号を送信する。走行経路上に洗車を行うことができる場所が無い場合には、車載端末４にメンテナンス信号を送信しない。

次にこのように構成した共用車管理システムの効果について説明する。保守判定部３１は走行経路上に洗車を行うことができる場所があるユーザを選択して、そのユーザに洗車を促す通知を行うことができる。これによって、共用車管理システムは洗車を行う可能性のあるユーザを選択することができ、洗車を促す通知をより効率的に行うことができる。

＜＜第５実施形態＞＞
第５実施形態に係る共用車管理システムは、第１実施形態に比べて、保守判定部３１の動作が異なる。保守判定部３１は、共用車３にメンテナンスが必要であると判断したときに、ユーザ情報テーブル３４を参照し、その共用車３を利用するユーザの洗車履歴を取得する。次に保守判定部３１はその洗車履歴に基づいて、ユーザの洗車可能性を算出する。ユーザの洗車可能性が所定の閾値（以下、洗車判定閾値）よりも高い場合には、車載端末４にメンテナンス信号を送信する。ユーザの洗車可能性が洗車判定閾値よりも低い場合には、車載端末４にメンテナンス信号を送信しない。

ユーザの洗車可能性は、ユーザの洗車回数に比例して高くなるように算出されるとよい。更に、ユーザの洗車可能性は、ユーザの洗車回数に加えて、天気情報サーバ８３から取得されたユーザの走行経路上の降水確率と、ユーザの利用開始日時及び利用終了日時の少なくとも一方とに基づいて算出されることが好ましい。このとき、ユーザの洗車可能性は、走行経路上における降水確率の最大値が小さいほど、高くなるように算出されるとよい。また、ユーザの洗車可能性は、当該ユーザの利用開始日時（又は利用終了日時）が午前０時から午前６時まで又は午後６時から午前０時までにあるときが最も低く、次に午前６時から午後０時までにあるときが低く、午後０時から午後６時までの間であるときが最も高くなるように算出されるとよい。

次にこのように構成した共用車管理システムの効果について説明する。洗車履歴、ユーザの利用開始日時及び利用終了日時の少なくとも一方、及び利用時の天候に基づいて洗車の実行が期待できるユーザを選択し、そのユーザに洗車が必要であることを通知して、洗車を促すことができる。これにより、より効果的に洗車が必要であることの通知を行うことができる。

以上で具体的実施形態の説明を終えるが、本発明は上記実施形態に限定されることなく幅広く変形実施することができる。上記第１実施形態では、ユーザから送信された利用前評価値、及び利用後評価値は絶対評価値を算出するために用いられていたが、管理サーバ６はユーザごとに絶対評価値と利用前評価値との比（係数）をユーザ情報テーブル３４に保存し、ユーザごとの評価の傾向を取得し、絶対評価値を予測するように構成してもよい。また、第２実施形態において、管理サーバ６はユーザごとに、ユーザから送信された項目別の評価値と、ユーザの利用前の項目別の絶対評価値との比（項目別の係数）を保存するように構成してもよい。管理サーバ６は新たにユーザが登録されたときには、そのユーザの年齢、性別、運転特性などの属性に基づいて、項目別の係数を予測し、予測された係数に基づいて、ユーザから送信された評価値を換算して絶対評価値を推定するとよい。また、管理サーバはユーザから送信された評価値を絶対評価値に換算したときに、その換算値が所定値以下となった場合には、その換算値ではなく、他の評価値に基づいてメンテナンスの要否の判定を行ってもよい。

第１実施形態の共用車管理システム１では利用終了時にユーザによって洗車を行ったか否かが入力されるように構成されていたが、第３実施形態と同様に、車載端末４が雨量センサ７７を含み、保守判定部３１が雨量センサ７７の検出結果に基づいて、利用者が洗車したことを判定する洗車判定部９０を含むように構成してもよい。

第５実施形態において、ユーザの利用開始日時及び利用終了日時の少なくとも一方が、洗車が必要であることを通知されたユーザの中で実際に洗車を行うユーザの割合が減少することが予測される期間内であるときには、洗車判定閾値を下げることによって、より多くの車載端末４にメンテナンス信号を送信するように構成してもよい。このように、メンテナンス信号を受信する車載端末４を増やすことによって、洗車を行うユーザの総数が減少することを防止することができる。洗車が必要であることを通知されたユーザの中で、実際に洗車を行うユーザの割合が減少することが予測される期間は、夏（７月～９月）及び冬（１１月～２月）の少なくとも一方を含むとよい。

１ ：共用車管理システム
３ ：共用車
４ ：車載端末
６ ：管理サーバ
１７ ：開始処理部（情報送信部）
１８ ：終了処理部（情報送信部）
１９ ：メンテナンス通知部（通知部）
２７ ：ユーザ情報記憶部（利用者情報記憶部）
２８ ：共用車情報管理部（評価値記憶部）
３０ ：情報更新部（換算部）
３１ ：保守判定部
３２ ：信号送信部
７１ ：状態送信部（情報送信部）
７２ ：検出部
７３ ：記録部
７６ ：加速度センサ
７７ ：雨量センサ
７８ ：明暗センサ
７９ ：走行距離メータ
８１ ：ＧＰＳ
９０ ：洗車判定部

Claims (8)

1. 複数の利用者から貸出予約を受け付けるとともに、共用車の貸出を管理する管理サーバと、前記管理サーバと通信可能な端末とを有する共用車管理システムであって、
   前記端末は、前記利用者から利用した前記共用車のメンテナンス状態に対する評価値の入力を受け付けて、前記評価値を前記管理サーバに送信する情報送信部と、所定のメンテナンス信号を受信したときに、前記共用車を利用する前記利用者に、前記共用車のメンテナンスを促す通知を行う通知部と、を有し、
   前記管理サーバは前記情報送信部からの前記共用車の情報に基づいて、前記共用車のメンテナンスの要否を判定する保守判定部と、メンテナンスが必要であると前記保守判定部が判定したときに、前記端末に前記メンテナンス信号を送信する信号送信部と、前記共用車に対して、前記情報送信部から送信された前記評価値を同一の基準に基づく絶対評価値に換算する換算部とを備え、
   前記保守判定部は、前記換算部によって換算された前記絶対評価値に基づいて、メンテナンスの要否を判定することを特徴とする共用車管理システム。
2. 前記共用車の情報はメンテナンスの実行に対応する情報を含み、
   前記管理サーバはメンテナンスの実行に対応する情報を受信したときには、メンテナンスを実行した前記利用者にインセンティブを付与することを特徴とする請求項１に記載の共用車管理システム。
3. 前記管理サーバは、前記絶対評価値を記憶する評価値記憶部を備え、
   前記端末は前記共用車の利用開始時及び利用終了時のそれぞれおいて前記評価値の受付を行い、
   前記換算部は、利用終了時の前記評価値を、予め前記評価値記憶部に記憶された前記絶対評価値と利用開始時の前記利用者による前記共用車の前記評価値とに基づいて、前記絶対評価値に換算し、換算された前記絶対評価値によって前記評価値記憶部に記憶された前記絶対評価値を更新し、
   前記保守判定部は更新後の前記絶対評価値に基づいて要否を判定することを特徴とする請求項１又は請求項２に記載の共用車管理システム。
4. 前記評価値は複数の項目に対応する評価項目値を含み、
   前記絶対評価値は前記評価項目値のそれぞれに対応する絶対評価項目値を含み、
   前記保守判定部は更新された前記絶対評価値に基づいて、前記項目のそれぞれに対してメンテナンスの要否を判定することを特徴とする請求項１～請求項３のいずれか１つの項に記載の共用車管理システム。
5. 前記項目は前記共用車の外装の清潔さに対応する外装評価値と前記共用車の車内の清潔さに対応する内装評価値とを含むことを特徴とする請求項４に記載の共用車管理システム。
6. 前記管理サーバは、前記利用者の洗車履歴を含む利用者情報を記憶する利用者情報記憶部を有し、
   前記保守判定部は、前記共用車にメンテナンスが必要であると判断したときに、前記洗車履歴に基づいて、洗車回数に比例して高くなるように前記利用者の洗車可能性を算出し、前記洗車可能性が所定の閾値よりも高い前記利用者の利用する前記共用車に搭載された前記端末に対して、メンテナンスが必要であることを通知する信号を送信することを特徴とする請求項１～請求項５のいずれか１つの項に記載の共用車管理システム。
7. 前記管理サーバは、前記利用者の前記貸出予約の受付を実行するとともに、前記貸出予約を受け付けるときに、前記利用者に走行予定経路の入力を要求し、
   前記保守判定部は、前記共用車にメンテナンスが必要であると判断したときに、前記走行予定経路に基づいて、前記走行予定経路に洗車を行うことができる場所がある前記利用者を選択し、選択された前記利用者の利用する前記共用車に搭載された前記端末に対して、メンテナンスが必要であることを通知する信号を送信することを特徴とする請求項１～請求項５のいずれか１つの項に記載の共用車管理システム。
8. 複数の利用者から貸出予約を受け付けるとともに、共用車の貸出を管理する管理サーバと、前記管理サーバと通信可能な端末とを有する共用車管理システムであって、
   前記端末は、前記共用車の情報を送信する情報送信部と、所定のメンテナンス信号を受信したときに、前記共用車を利用する前記利用者に、前記共用車のメンテナンスを促す通知を行う通知部とを有し、
   前記管理サーバは前記情報送信部からの前記共用車の情報に基づいて、前記共用車のメンテナンスの要否を判定する保守判定部と、メンテナンスが必要であると前記保守判定部が判定したときに、前記端末に前記メンテナンス信号を送信する信号送信部とを備え、
   前記管理サーバはネットワークを介して、天候に係る情報を保持する天気情報サーバに接続可能に構成され、
   前記情報送信部は前記共用車に搭載され、前記共用車の使用状態を検出する検出部と、前記検出部によって検出された検出結果を記録する記録部と、取得した前記使用状態を前記管理サーバに送信する状態送信部とを有し、
   前記検出部は雨量センサと、前記共用車の位置を特定するＧＰＳとを含み、
   前記保守判定部は
   前記端末から送信された前記共用車の前記位置に基づいて前記共用車の走行距離を取得し、前記天気情報サーバに接続することによって前記共用車の走行時の前記天候を取得し、前回利用終了時の前記共用車の評価値に、前記走行距離と、前記天候に基づくパラメータとの積を加えることにより、利用後の前記評価値を推定し、推定された前記評価値に基づいてメンテナンスの要否を判定し、且つ、
   前記天気情報サーバから取得された前記天候に係る情報と前記雨量センサからの信号とに基づいて、洗車の有無を判定し、洗車したと判定した場合には、前記共用車の前記評価値をリセットすることを特徴とする共用車管理システム。

Images