JP6841729B2

JP6841729B2 - 車両管理システム

Info

Publication number: JP6841729B2
Application number: JP2017125455A
Authority: JP
Inventors: 聡朝枝; 諭大久保
Original assignee: Honda Motor Co Ltd
Current assignee: Honda Motor Co Ltd
Priority date: 2017-06-27
Filing date: 2017-06-27
Publication date: 2021-03-10
Anticipated expiration: 2037-06-27
Also published as: JP2019008658A

Description

本発明は、カーシェアリング事業などで用いられる車両を管理する車両管理システムに関する。

カーシェアリング事業で用いられる車両に、例えば外力が作用して損傷が生じたとき、その車両を後続の予約者にそのまま利用させることはできないため、速やかに代車を手配する必要がある。この点に関し、例えば特許文献１には、事故連絡を受けた損害保険会社の担当員が、レンタカー会社のホームページにアクセスして空車情報を確認し、所望の代車を発注するようにしたシステムが記載されている。

特開２００１−３４４４９０号公報

しかしながら、上記特許文献１記載のシステムは、事故連絡を受けた担当員の行為を介して代車の手配が行われるため、後続の予約者に対し車両を貸出不能となったときに、代車を迅速に手配することが困難である。

本発明の一態様である車両管理システムは、ユーザに貸出可能な複数の共用車両にそれぞれ設けられ、各共用車両の車両状態を検出する状態検出部と、複数の共用車両の現在および将来の利用計画を作成する計画作成部と、複数の共有車両の前記利用計画を含む車両情報を記憶する記憶部と、状態検出部により検出された車両状態と記憶部に記憶された利用計画とに基づき、複数の共用車両のうちユーザにより予約された予約車両の代替となる代替車両の要否を判定する代車要否判定部と、代車要否判定部により代替車両が必要と判定されると、記憶部に記憶された複数の共用車両の車両情報に基づいて代替車両を検索する車両検索部と、を備える。状態検出部は、予約車両に作用する加速度を検出する加速度センサを有し、代車要否判定部は、予約車両の利用開始予定時刻よりも前に加速度センサの検出値が所定値以上になると、代替車両が必要と判定する。

本発明によれば、後続の予約者に対して車両を貸出不能となったとき、代替車両を迅速に手配することができる。

本発明の実施形態に係る車両管理システムが適用される組織体系を示すイメージ図。図１の複数の事業体の地理的配置を示す図。本発明の実施形態に係る車両管理システムの全体構成を示すブロック図。カーシェアリング事業に用いられる車両の利用計画の一例を示す図。図３のサーバ装置の演算部で実行される処理の一例を示すフローチャート。本発明の実施形態に係る車両管理システムの主要な動作の一例を説明する図。本発明の実施形態に係る車両管理システムの主要な動作の他の例を説明する図。

以下、図１〜図６Ｂを参照して本発明の一実施形態について説明する。本発明の実施形態に係る車両管理システムは、カーシェアリング事業やレンタカー事業等においてユーザに貸し出される車両を管理するシステムである。レンタカー事業は、対面での車両の貸出を行うのに対し、カーシェアリング事業は、予め登録したＩＣカードを用いて無人での車両の貸出を行う点でレンタカー事業と異なる。

本発明の車両管理システムは、カーシェアリング事業とレンタカー事業のいずれにも適用可能であるが、以下では、カーシェアリング事業に適用する例を説明する。特に、本実施形態に係る車両管理システムは、車両の販売やメンテナンス（点検、整備）を行う販売店（カーディーラ）等の事業体が主体となってカーシェアリング事業を行う場合に適したシステムとして構成される。事業体の敷地内には、事業体が保有し、カーシェアリング事業に供される車両（共用車両）が駐車される。このような共有車両が駐車される場所をステーションと呼ぶ。

事業体の敷地内には、ステーションだけでなく、事業体に属する作業員が共有車両をメンテナンスするメンテナンス拠点も設けられる。ステーションは、例えばメンテナンス拠点と同一の敷地内、あるいは塀や道路等を隔てて互いに隣り合う敷地内に設けられる。なお、メンテナンス拠点からステーションまでの距離が所定距離内である等、メンテナンス拠点の近傍にステーションが設けられるのであれば、メンテナンス拠点と同一または隣接する敷地以外にステーションが設けられてもよい。

ユーザが共用車両を使用するとき、ステーションが共用車両の出発地および返却地となる。共有車両は、例えばステーションに返却される度に、作業員によってメンテナンス拠点に移送され、メンテナンス拠点においてメンテナンスが行われる。すなわち、カーシェアリング事業においては、運転技術や運転態様が異なる様々なユーザが種々の目的で共有車両を運転する。したがって、共有車両を良好な状態でユーザに貸し出すために、ユーザの利用が終了する度に共有車両のメンテナンスが行われる。

図１は、本発明の実施形態に係る車両管理システムが適用される組織体系を示すイメージ図である。図１に示すように、組織体系は、最上位の第１階層、第１階層よりも下位の第２階層、および第２階層よりも下位の第３階層に分類される。第３階層は、複数の事業体（例えば車両の販売店であるＡ店、Ｂ店、Ｃ店、Ｄ店）により構成される。

図２は、複数の事業体Ａ店〜Ｄ店の地理的配置を示す図である。図２に示すように、複数の事業体Ａ店〜Ｄ店のうち、Ａ店およびＢ店は、第１範囲ＡＲ１内に点在し、Ｃ店およびＤ店は、第１範囲ＡＲ１に隣接する第２範囲ＡＲ２内に点在する。なお、各範囲ＡＲ１，ＡＲ２に含まれる第３階層の事業体の数は１つでもよく、３つ以上でもよい。図２では、第１範囲ＡＲ１と第２範囲ＡＲ２とが隣接する範囲として示されるが、互いに離れていてもよい。図２において、Ｃ１〜Ｃ７は、互いに同一車種の共有車両であり、Ａ店は車両Ｃ１〜Ｃ３を、Ｂ店は車両Ｃ４を、Ｃ店は車両Ｃ５，Ｃ６を、Ｄ店は車両Ｃ７を、それぞれ保有する。

図１に示すように、第２階層は、第３階層の複数の事業体Ａ店，Ｂ店およびＣ店，Ｄ店の業務を管理する事業体（例えば車両の販売会社であるＥ社およびＦ社）により構成される。Ｅ社は、第１範囲ＡＲ１内に点在するＡ店およびＢ店を管理し、Ｆ社は、第２範囲ＡＲ２内に点在するＣ店およびＤ店を管理する。なお、第２階層の事業体の数は１つでもよく、３つ以上でもよい。Ｅ社およびＦ社は、例えば第１範囲ＡＲ１内および第２範囲ＡＲ２内にそれぞれ位置する。

第１階層は、第２階層の複数の事業体Ｅ社およびＦ社の業務を管理する事業体（例えば車両の製造メーカーであるＧ社）により構成される。Ｇ社は、例えばユーザからの電話やメール等に応答するコールセンタを有する。Ｇ社とＥ社およびＦ社との関係は、例えば親会社と子会社との関係に相当する。なお、第１階層の事業体の数は２つ以上でもよい。第１階層の上位にさらなる事業体があってもよい。

このような組織体系の下、本実施形態では、第３階層の事業体Ａ店〜Ｄ店が保有する車両Ｃ１〜Ｃ７がカーシェアリング事業のための共用車両として用いられる。なお、共用車両には、カーシェアリング事業のみに用いられるカーシェアリング専用の車両だけではなく、試乗車等、他の目的に用いる車両を含めることもできる。第３階層の事業体だけでなく、第２階層または第１階層の事業体が保有する車両の一部を、カーシェアリング事業のための共用車両として用いることもできる。

図３は、本発明の実施形態に係る車両管理システム１００の全体構成を示すブロック図である。図３に示すように、車両管理システム１００は、第１階層〜第３階層の各事業体に設けられた事業体端末１と、各事業体が保有する車両Ｃ１〜Ｃ７に設けられた車載端末２と、車両Ｃ１〜Ｃ７を利用する顧客（ユーザ）が有するユーザ端末３と、サーバ装置４とを有する。

事業体端末１と車載端末２とユーザ端末３とサーバ装置４とは、無線通信網、インターネット網、電話回線網などの通信ネットワーク５に接続される。図３には、便宜上、事業体端末１と車載端末２とユーザ端末３とがそれぞれ１つずつ示されるが、これらの端末１〜３は実際にはそれぞれ複数設けられる。また、図３では、単一のサーバ装置４が示されるが、図３のサーバ装置４に示す機能を、複数のサーバ装置に分散させてもよい。通信径路の少なくとも一部は、無線でなく有線であってもよい。

事業体端末１は、各事業体に設けられたパーソナルコンピュータと、各事業体の従事者（社員）により操作される携帯無線端末とを含む。事業体端末１は、通信部１１と、入出力部１２と、演算部１３と、記憶部１４と、を有する。

通信部１１は、通信ネットワーク５を介してサーバ装置４と無線通信可能に構成される。通信部１１は、事業体の社員を識別する社員ＩＤとともに、車両Ｃ１〜Ｃ７の利用情報とメンテナンス情報とをサーバ装置４に送信する。

入出力部１２は、いわゆるヒューマンインターフェース（ＨＭＩ）であり、ユーザが操作可能なキーボード、マウス、モニタ、タッチパネル、プリンタ等を有する。各事業体の従事者（社員）は、入出力部１２を介して車両Ｃ１〜Ｃ７の各種情報を入力することができるとともに、代替車両の手配に関する情報を取得することができる。

演算部１３はＣＰＵ（プロセッサ）を有し、入出力部１２を介して入力された信号、通信部１１を介して事業体端末１の外部から受信した信号、および記憶部１４に記憶されたデータ等に基づいて所定の処理を実行し、通信部１１と、入出力部１２と、記憶部１４とに制御信号を出力する。演算部１３での処理により、自己が属する事業体が保有する車両が代替車両として用いられるか否かが、入出力部１２（例えばモニタ）を介して社員に報知される。

演算部１３は、サーバ装置４から車両の各種情報（車両情報）を取得する車両情報取得部１３ａを有する。取得する車両情報は、各事業体に属する車両の情報、およびその事業体よりも下位の事業体に属する車両の情報である。例えば第３階層の事業体Ａ店は、Ａ店に属する車両Ｃ１〜Ｃ３の情報を取得することができ、第２階層の事業体Ｅ社は、Ａ店およびＢ店に属する車両Ｃ１〜Ｃ４の情報を取得することができ、第１階層の事業体Ｇ社は、Ａ店〜Ｄ店に属する車両Ｃ１〜Ｃ７の情報を取得することができる。演算部１３は、これらの車両情報を社員が認識可能な態様で入出力部１２に出力（例えば表示）させることができる。

記憶部１４は、図示しない揮発性または不揮発性メモリを有する。記憶部１４には、演算部１３が実行する各種のプログラムや、各種のデータが記憶される。

車載端末２は、例えば車載ナビゲーション装置を含んで構成される。車載端末２は、通信部２１と、入出力部２２と、ロック機構２３と、センサ群２４と、演算部２５と、記憶部２６と、を有する。

通信部２１は、通信ネットワーク５を介してサーバ装置４と無線通信可能に構成される。通信部２１は、車両Ｃ１〜Ｃ７を識別する車両ＩＤとともに、車両Ｃ１〜Ｃ７の現在位置情報を示す信号およびセンサ群２４からの信号を、所定時間毎にサーバ装置４に送信する。

入出力部２２は、ユーザが操作可能な各種スイッチやボタン、マイク、スピーカ、モニタ等を有する。この他、入出力部２２は、ユーザが有する認証カードからユーザ情報を読み取るカードリーダ２２ａを有する。認証カードには、例えば集積回路（ＩＣ）が組み込まれてユーザの個人情報が格納された運転免許証（ＩＣカード免許証）が用いられる。カードリーダ２２ａは、車両外部から近づけられた認証カードを認識可能なように、車両Ｃ１〜Ｃ７の所定部位（例えばリアウインドの下方）に設けられる。

ロック機構２３は、ドアロックアクチュエータ（例えば電動モータ）を有し、ドアロックアクチュエータの駆動により、ドアロックを解錠または施錠する。すなわち、ドアロックアクチュエータは演算部２５から解錠信号が出力されると、ドアロックを解錠し、施錠信号が出力されると、ドアロックを施錠する。

センサ群２４は、各車両Ｃ１〜Ｃ７に搭載され、車両状態を検出する各種センサを含む。センサ群２４は、一例として、車両Ｃ１〜Ｃ７に作用する加速度を検出する加速度センサ２４ａを含む。なお、車両の位置を検出するＧＰＳセンサ、車速を検出する車速センサ、車両の角速度を検出するジャイロセンサ、走行距離を検出する走行距離センサ、残燃料量を検出する残燃料検出センサ、残バッテリ容量を検出する残バッテリ容量検出センサなどもセンサ群２４に含まれる。

演算部２５はＣＰＵを有し、入出力部２２を介して入力された信号、センサ群２４で検出された信号、通信部２１を介して車載端末の外部から受信した信号、および記憶部２６に記憶されたデータに基づいて所定の処理を実行し、車両Ｃ１〜Ｃ７の各部のアクチュエータ、入出力部２２、および記憶部２６に制御信号を出力する。演算部２５は、さらに通信部２１に制御信号を出力し、車載端末２とサーバ装置４との間の信号の送受信を制御する。例えば、演算部２５は、カードリーダ２２ａを介して読み取ったユーザ情報を、通信部２１を介してサーバ装置４に送信する。サーバ装置４は、受信したユーザ情報に対応する予約情報の有無を判定し、対応する予約情報があれば演算部２５に解錠指令を送信し、対応する予約情報がなければ施錠信号を送信する。演算部２５は、解錠指令を受信すると解錠信号を、施錠指令を受信すると施錠信号を、それぞれドアロックアクチュエータに出力する。

記憶部２６は、図示しない揮発性または不揮発性メモリを有する。記憶部２６には、演算部２５が実行する各種のプログラムや、各種のデータが記憶される。例えばセンサ群２４による検出データが一時的に記憶される。記憶された検出データは、演算部２５での処理により、通信部２１を介して所定時間毎にサーバ装置４に送信される。

ユーザ端末３は、ユーザにより操作されるパーソナルコンピュータや、スマートフォンに代表される携帯無線端末等により構成される。ユーザ端末３は、通信部３１と、入出力部３２と、演算部３３と、記憶部３４と、を有する。

通信部３１は、通信ネットワーク５を介してサーバ装置４と無線通信可能に構成される。通信部３１は、ユーザを識別するユーザＩＤとともに、車両Ｃ１〜Ｃ７の予約申し込みやキャンセル等を指令する信号をサーバ装置４に送信する。

入出力部３２は、例えばキーボード、マウス、モニタ、タッチパネル等を有する。ユーザは、入出力部３２を介してユーザ情報の入力や、車両予約の申し込み、変更、キャンセル等の指令を入力することができる。ユーザ情報には、ユーザの住所、氏名、連絡先、免許証番号、決済に必要な情報（例えばクレジットカード番号）等が含まれる。ユーザは、ユーザ情報を入力して会員登録した後に、共用車両の利用が可能となる。

車両予約の申し込み時には、車種、利用するステーション、および車両の利用日時（利用開始日時と利用終了日時）がユーザにより指令される。このとき、サーバ装置４（車両検索部４３５）は、指令された車種、ステーション、利用日時のいずれかまたは全ての条件を満たす予約可能な車両を検索するとともに、検索された車両の情報をユーザ端末３に送信する。この車両情報は入出力部３２に表示される。表示された車両の中から入出力部３２を介してユーザが所望の車両を選択すると、あるいは表示された車両をユーザが承諾すると、車両予約が確定する。

演算部３３はＣＰＵを有し、入出力部３２を介して入力された信号、通信部３１を介してユーザ端末３の外部から受信した信号、および記憶部３４に記憶されたデータに基づいて所定の処理を実行し、通信部３１と入出力部３２と記憶部３４とに制御信号を出力する。演算部３３での処理により、ユーザは入出力部３２（モニタなど）を介して予約車両の変更や確認を行うことができる。

記憶部３４は、図示しない揮発性または不揮発性メモリを有する。記憶部３４には、演算部３３が実行する各種のプログラムや、各種のデータが記憶される。

サーバ装置４は、例えば第１階層の事業体Ｇ社に設けられる。クラウド上で仮想サーバ機能を利用して、サーバ装置４を構成することもできる。サーバ装置４は、通信部４１と、入出力部４２と、演算部４３と、記憶部４４と、を有する。

通信部４１は、通信ネットワーク５を介して事業体端末１、車載端末２およびユーザ端末３とそれぞれ無線通信可能に構成される。入出力部４２は、例えばキーボード、マウス、モニタ、タッチパネル等を有する。演算部４３はＣＰＵを有し、入出力部４２を介して入力された信号、通信部４１を介してサーバ装置４の外部から受信した信号、および記憶部４４に記憶されたデータに基づいて所定の処理を実行し、入出力部４２や記憶部４４に制御信号を出力する。演算部４３の機能的構成は後述する。

記憶部４４は、図示しない揮発性または不揮発性メモリを有する。記憶部４４には、演算部４３が実行する各種のプログラムや、各種のデータが記憶される。記憶部４４は、メモリが担う機能的構成として車両データベース４４１と、ユーザデータベース４４２と、社員データベース４４３とを有する。

車両データベース４４１は、各車両Ｃ１〜Ｃ７が属する事業体、各車両Ｃ１〜Ｃ７の車種、年式、車体番号、車両番号、走行距離、メンテナンス履歴、稼働率等の車両状態や車両特性を表す車両情報と、各車両Ｃ１〜Ｃ７の利用計画とを記憶する。利用計画には、各車両Ｃ１〜Ｃ７の過去、現在および未来の時系列の予約情報と、予約情報の合間に既に実行された車両Ｃ１〜Ｃ７のメンテナンスの実績と、現在実行中あるいは将来実行される予定のメンテナンス計画とが含まれる。

図４は、車両Ｃ１の利用計画の一例を示す図である。図４では、時点ｔ０〜ｔ１（実線矢印）にユーザによる予約が組み込まれ、その後、時点ｔ１〜ｔ２（点線矢印）に車両のメンテナンス計画が組み込まれ、さらにその後、時点ｔ３〜ｔ４（実線矢印）に、再びユーザによる予約が組み込まれている。車両データベース４４１の利用計画は、予約の申し込み、変更、取消、およびメンテナンスの実行、メンテナンス計画の変更に応じて更新される。

ユーザデータベース４４２は、ユーザ端末３（入出力部３２）を介して入力された各ユーザのユーザＩＤ，住所，氏名，連絡先，免許証番号等のユーザ情報、および各ユーザの車両Ｃ１〜Ｃ７の利用履歴情報等を記憶する。

社員データベース４４３は、各社員の社員ＩＤ，住所，氏名，連絡先等の社員情報を記憶する。社員情報には、各社員がどの事業体に属するかの所属先情報も含まれる。社員情報は、特定の事業体端末１（例えばＧ社の事業体端末）でのみ入力可能とすることができる。

演算部４３は、プロセッサが担う機能的構成として、予約受付部４３１と、計画作成部４３２と、車両情報取得部４３３と、代車要否判定部４３４と、車両検索部４３５と、計画変更部４３６と、出力部４３７と、クーポン処理部４３８とを有する。

予約受付部４３１は、ユーザ端末３（入出力部３２）を介してユーザにより入力された車両の利用予約の申し込みを受け付ける。具体的には、演算部４３（車両検索部４３５）が、車両の利用日時、車種、利用する事業体等、ユーザにより入力された予約条件に合致する予約可能な車両の一覧を車両データベース４４１から検索してユーザ端末３に送信した後、通信部４１が、送信された車両一覧の中からユーザにより選択された車両あるいはユーザにより承諾された車両の情報を受信する。予約受付部４３１は、これを予約車両として利用予約の申し込みを受け付ける。

計画作成部４３２は、共用車両の現在および将来の利用計画を作成し、利用計画を車両データベース４４１に登録する。より具体的には、予約受付部４３１により受け付けられた予約車両の利用計画を作成し、これを車両データベース４４１に登録する。利用計画には、予約車両の利用開始日時および利用終了日時と、メンテナンス計画とが含まれる。

車両情報取得部４３３は、各車両Ｃ１〜Ｃ７の車両状態を表すデータ、すなわちセンサ群２４により検出され、通信部４１を介して受信した検出データを取得する。検出データには、加速度センサ２４ａによる検出データが含まれる。

代車要否判定部４３４は、車両情報取得部４３３により取得された検出データと、計画作成部４３２により作成された利用計画とに基づいて、予約車両の代替となる代替車両の要否を判定する。例えば貸出中の車両に外力が作用して車両が損傷すると、その車両を次の予約者に対しそのまま貸し出すことが困難であるため、代替車両を手配する必要がある。このとき、車両に衝撃が作用するため、加速度センサ２４ａの検出値Ｇが所定値Ｇ１以上となる。

そこで、代車要否判定部４３４は、貸出中の車両の利用計画を参照して当該車両に次の予約が入っているか否かを判定するとともに、当該車両の加速度センサ２４ａの検出値Ｇが所定値Ｇ１以上か否かを判定する。そして、貸出中の車両に既に予約が入っており、かつ、加速度センサ２４ａの検出値Ｇが所定値Ｇ１以上と判定すると、代替車両が必要と判定する。一方、貸出中の車両に未だ予約が入っていないと判定されると、代車要否判定部４３４は、加速度センサ２４ａの検出値Ｇが所定値Ｇ１以上であっても、代替車両を不要と判定する。この場合には、貸出中の車両が予約不能であるとして、車両データベース４４１における当該車両の車両情報が構成される。

車両検索部４３５は、代車要否判定部４３４により代替車両が必要と判定されると、車両データベース４４１を参照して代替車両を検索する。代替車両は、予約車両の利用時間内に未だ予約が入っていない予約車両と同一車種の車両の中から検索される。例えば図４の時点ｔ０〜ｔ１に車両Ｃ１が貸し出されている途中に、車両Ｃ１の代替車両が必要と判断されると、次の予約時間である時点ｔ３〜ｔ４に予約が入っていない車両の中から代替車両を検索する。

計画変更部４３６は、車両検索部４３５により検索された代替車両を新たな予約車両として利用計画を変更する。複数の代替車両が検索されたときには、予約車両と代替車両との地理的近接性に基づいてそれらの優先順位を決定し、優先順位の最も高い代替車両を予約車両として利用計画を変更する。具体的には、代替車両を有する複数の事業体（ステーション）が存在するとき、同一の地理的範囲内の事業体が代替車両を有するならば、第１に、その代替車両を優先する。同一の地理的範囲内に複数の代替車両が存在するとき、第２に、これらの代替車両を有する各事業体と予約車両を有する事業体との間の距離や両者間の移動時間が短いものほど優先順位を高くする。計画変更部４３６は、車両検索部４３５により検索され、優先順位の最も高い代替車両を、新たな予約車両として仮予約する。その後、仮予約された車両がユーザにより承諾されると、代替車両の予約を確定する。このとき、計画変更部４３６は、元の予約車両の予約を取り消す。

出力部４３７は、計画変更部４３６により変更された利用計画に含まれる新たな予約車両の情報（仮予約された代替車両の情報）を、通信部４１を介してユーザ端末３に送信する。この情報を受信したユーザは、入出力部３２を介して予約車両の変更を承諾するか否かを指令する。このユーザによる指令は、利用計画の変更に対する承諾または非承諾を含む応答信号としてサーバ装置４に送信される。このとき、通信部４１が承諾の応答信号を受信すると、利用計画の変更が確定し、計画変更部４３６は代替車両を本予約して車両データベース４４１を更新する。

出力部４３７は、利用計画の変更が確定した後、さらに利用計画の変更情報を少なくとも関連する事業体の事業体端末１に送信する。すなわち、元の予約車両を有する事業体の事業体端末１と、新たな予約車両を有する事業体の事業体端末１とに、利用計画の変更情報を送信する。この変更情報には、新たな予約車両を有する事業体の作業員に対する指令、すなわち、新たな予約車両を所定時刻（例えば利用開始時刻）までに所定ステーションへと移送すべき旨の指令が含まれる。なお、元の予約車両と新たな予約車両とが同一の事業体に属する場合には、新たな予約車両は元の予約車両と同一のステーションに位置するため、新たな予約車両を移送する必要はない。したがって、この場合には、作業員に対する車両の移送指令を利用計画の変更情報に含めなくてもよい。

クーポン処理部４３８は、カーシェアリング利用料の割引サービスを受けることが可能なクーポンの利用に関する処理を行う。すなわち、カーシェアリング事業においては、例えば車両の清掃がなされていない等、車両が適正な貸出可能状態にない場合があり、ユーザはステーションで実際の車両状態を確認した後に、予約車両の利用を取りやめることがある。このような場合に、例えば車両の利用開始時刻においてクーポン利用の処理がなされると、ユーザは不利益を被る。そこで、クーポン処理部４３８は、予約車両がステーションに位置した状態で、ユーザ端末３（入出力部３２）を介してユーザにより予約車両の取り消しの申し込みが入力されると、既になされたクーポン利用を取り消すような処理を行う。このとき、計画変更部４３６は、予約車両の予約を取り消す。

このようなユーザ端末３を介した予約車両の取り消しの申し込み時に、ユーザは、ユーザ端末３（入出力部３２）を介して予約車両の代替車両をリクエストすることができる。代替車両のリクエストが指令されると、演算部４３（車両検索部４３５）は代替車両を検索するとともに、検索された代替車両をユーザ端末に送信する。そして、代替車両をユーザが承諾すると、予約車両の利用計画を変更する。このとき、クーポン処理部４３８は、代替車両にクーポンが適用されるようにクーポン利用に関する処理を行う。

図５は、予めサーバ装置４の記憶部４４に記憶されたプログラムに従い、演算部４３で実行される処理の一例を示すフローチャートである。このフローチャートに示す処理は、例えばユーザ端末３を介してユーザにより入力された共有車両の利用予約の申し込みの指令が、通信部４１を介して演算部４３に入力されると開始される。すなわち、予約受付部４３１で共有車両の利用予約の申し込みが受け付けられた予約車両について図５の処理が開始され、所定時間毎に処理が繰り返される。予約車両については、計画作成部４３２での処理により、予約受付部４３１で受け付けられた利用予約の申し込み内容に応じて、例えば図４に示すような利用計画が作成される。作成された利用計画は、車両データベース４４１に記憶される。

まず、ステップＳ１で、車両情報取得部４３３での処理により、通信部４１を介して予約車両のセンサ群２４からの信号、すなわち車両情報を取得する。次いで、ステップＳ２で、代車要否判定部４３４での処理により、ステップＳ１で取得された情報（例えば加速度センサ２４ａの検出値）に基づき、予約車両の代替となる代替車両の要否を判定する。具体的には、加速度センサ２４ａの検出値Ｇが所定値Ｇ１以上か否かを判定し、所定値Ｇ１以上のときに代替車両が必要と判定する。ステップＳ２で肯定されるとステップＳ３に進み、否定されると処理を終了する。

ステップＳ３では、車両検索部４３５での処理により、複数の事業体が保有する複数の共有車両の中から、予約車両と同一車種の代替車両を検索する。代替車両は、既にメンテナンスが完了し、かつ、予約車両の利用時間（例えば図４のｔ３〜ｔ４）内に未だ予約が入っていない空き車両の中から検索される。

次いで、ステップＳ４で、計画変更部４３６での処理により、ステップＳ３で検索された代替車両を新たな予約車両として仮予約する。特に、ステップＳ３で複数の代替車両が検索された場合には、複数の代替車両に優先順位をつけて、優先順位の最も高い代替車両を新たな予約車両として仮予約する。優先順位は、予約車両が存在するステーションと代替車両が存在するステーションとが図２の同一範囲ＡＲ１，ＡＲ２内にあるか否か、および予約車両が存在するステーションと代替車両が存在するステーションとの地理的近接性を考慮して決定する。

次いで、ステップＳ５で、出力部４３７での処理により、ステップＳ４で仮予約された代替車両の情報を、通信部４１を介してユーザ端末３に送信する。次いで、ステップＳ６で、例えば計画変更部４３６での処理により、仮予約した代替車両を新たな予約車両として承諾するか否かのユーザ端末３からの信号（応答信号）を、通信部４１を介して受信したか否かを判定する。ステップＳ６は肯定されるまで繰り返され、ステップＳ６で肯定されるとステップＳ７に進む。

ステップＳ７では、計画変更部４３６での処理により、通信部４１を介して受信した応答信号が承諾の信号であるか否かを判定する。ステップＳ７で否定されるとステップＳ４に戻り、検索された複数の代替車両のうち、前回の処理で最も優先順位の高いとされた代替車両の優先順位を繰り下げ、かつ、２番目に優先順位の高いとされた代替車両の優先順位を繰り上げる。すなわち、代替車両の優先順位を変更する。そして、最も優先順位の高くなった代替車両を新たな予約車両として仮予約し、ステップＳ７で肯定されるまで、同様の処理を繰り返す。ステップＳ７で肯定されるとステップＳ８に進む。

ステップＳ８では、計画変更部４３６での処理により、仮予約した代替車両を本予約してその車両の利用計画の変更を確定し、車両データベース４４１を更新する。さらに、元の予約車両の予約を取り消すとともに、その予約車両を予約不能として車両データベース４４１の車両情報を更新する。次いで、ステップＳ９で、出力部４３７での処理により、利用計画の変更に関連する車両を有する事業体の事業体端末１、つまり元の予約車両（貸出中の車両）を有する事業体の事業体端末１と、新たな予約車両を有する事業体の事業体端末１とに、利用計画の変更の情報を送信し、処理を終了する。

本実施形態に係る車両管理システムの主要な動作をより具体的に説明する。図６Ａ，図６Ｂは、車両Ｃ１〜Ｃ７の利用計画の一例を示す図である。なお、図６Ａ，図６Ｂには、互いに異なる利用計画のパターンが示される。

まず、図６Ａの例について説明する。図６Ａの時点ｔ０〜ｔ１において現在貸出中で、かつ時点ｔ３〜ｔ４において次の利用予約が入っている予約車両Ｃ１については、加速度センサ２４ａの検出値が所定時間毎に車載端末２からサーバ装置４に送信される（ステップＳ１）。このとき、時点ｔ０〜ｔ１のある時点で、予約車両Ｃ１が障害物等に接触して加速度センサ２４ａの検出値Ｇが所定値Ｇ１以上になると、予約車両が損傷したと予想される。したがって、予約車両Ｃ１をそのままユーザに使用させることは困難であり、演算部４３により予約車両Ｃ１の代替車両が必要と判定される（ステップＳ２）。このとき、時点ｔ３〜ｔ４において予約が入っていない空き車両Ｃ３，Ｃ４，Ｃ５，Ｃ７が代替車両として検索される（ステップＳ３）。

図２に示すように、予約車両Ｃ１から車両Ｃ３，Ｃ４，Ｃ５，Ｃ７までの各距離を比較すると、車両Ｃ３は車両Ｃ１と同一の事業体Ａ店に属することから、車両Ｃ３までの距離が最も短い。したがって、代替車両としての車両Ｃ３の優先順位が最も高い。次いで、車両Ｃ５，Ｃ４，Ｃ７の順に予約車両Ｃ１からの距離が長くなるが（Ｌ２＜Ｌ１＜Ｌ３）、車両Ｃ４は車両Ｃ１と同一の地理的範囲ＡＲ１に存在するのに対し、車両Ｃ５は車両Ｃ７とは異なる地理的範囲ＡＲ２に存在する。このため、車両Ｃ４が２番目に優先順位が高く、以降の優先順位は車両Ｃ５，Ｃ７の順となる。

以上より、図６Ａに示すように、優先順位の最も高い車両Ｃ３が新たな予約車両として仮予約される（ステップＳ４）。予約車両の変更がユーザにより承諾されると、車両Ｃ３の予約が確定し（ステップＳ８）、利用計画の変更情報がＡ店の事業体端末１に送信される（ステップＳ９）。このとき、元の予約車両Ｃ１の予約が取り消される。なお、車両Ｃ３への予約の変更がユーザにより承諾されないときは、次に優先順位の高い車両Ｃ４の優先順位が繰り上がり、車両Ｃ４が仮予約される。

次に、図６Ｂの例について説明する。図６Ｂの例では、代替車両が必要と判定されたとき（ステップＳ２）、既にメンテナンスが完了し、かつ、時刻ｔ３〜ｔ４の範囲において予約が入っていない空き車両Ｃ４，Ｃ５，Ｃ７が代替車両として検索される（ステップＳ３）。このとき、車両Ｃ４，Ｃ５，Ｃ７の中では車両Ｃ４の優先順位が最も高いため、車両Ｃ４が新たな予約車両として仮予約され（ステップＳ４）、ユーザにより予約車両の変更が承諾されると、車両Ｃ４の予約が確定する（ステップＳ８）。

その後、利用計画の変更情報が車両Ｃ４を有するＢ店の事業体端末１に送信される（ステップＳ９）。この変更情報には、事業体Ｂ店の作業員が遅くとも利用開始時刻ｔ３までに車両Ｃ４をＡ店のステーションに移送すべき指令が含まれる。なお、事業体Ａ店の事業体端末１に送信される変更情報に、事業体Ａ店の作業員に対し事業体Ｂ店まで車両Ｃ４を取りに行かせるような指令を含めてもよい。

本実施形態によれば以下のような作用効果を奏することができる。
（１）本実施形態の車両管理システム１００は、ユーザに貸出可能な複数の共用車両Ｃ１〜Ｃ７にそれぞれ設けられ、各共用車両Ｃ１〜Ｃ７の車両状態を検出するセンサ群２４（特に加速度センサ２４ａ）と、複数の共用車両Ｃ１〜Ｃ７の現在および将来の利用計画を作成する計画作成部４３２と、複数の共有車両Ｃ１〜Ｃ７の利用計画を含む車両情報を記憶する車両データベース４４１と、加速度センサ２４ａの検出値Ｇと車両データベース４４１に記憶された利用計画とに基づき、複数の共用車両Ｃ１〜Ｃ７のうちユーザにより予約された予約車両の代替となる代替車両の要否を判定する代車要否判定部４３４と、代車要否判定部４３４により代替車両が必要と判定されると、車両データベース４４１に記憶された複数の共用車両Ｃ１〜Ｃ７の車両情報に基づいて代替車両を検索する車両検索部４３５とを備える（図３）。

このような構成により、貸出中の車両（例えば車両Ｃ１）に外力が作用して後続の予約者に車両Ｃ１を貸出不能となったとき、車両利用中のユーザ等からの通報を待たずに即座に代替車両の要否を判定することができる。このため、予約車両Ｃ１のステーションに余裕をもって代替車両を手配することができ、後続のユーザに支障なく新たな予約車両を利用させることができる。また、迅速な代替車両の手配が可能なことから、車両の予約を随時受け付けることができ、効率的なカーシェアリング事業を行うことができる。

（２）車両管理システム１００は、車両検索部４３５により検索された代替車両を新たな予約車両として利用計画を変更する計画変更部４３６をさらに備える（図３）。このため、コールセンタ等による人手を介さずに、必要に応じて自動的に予約車両を変更することができ、予約車両の変更が容易である。

（３）車両管理システム１００は、車両検索部４３５により検索された代替車両の情報を出力し、通信部４１を介して当該情報をユーザに報知する出力部４３７と、報知された代替車両への予約変更を承諾するか否かについてのユーザの指令による応答信号を受信する通信部４１とをさらに備える（図３）。計画変更部４３６は、通信部４１により予約変更の承諾の応答信号が受信されると、代替車両を新たな予約車両として利用計画を変更する。これにより予約車両の変更に関する情報をユーザは認識することができる。また、ユーザの承諾を条件として予約車両の変更を行うため、ユーザの意思を尊重した適切な予約車両の変更が可能である。

（４）センサ群２４は、共用車両に作用する加速度を検出する加速度センサ２４ａを有する（図３）。代車要否判定部４３４は、加速度センサ２４ａの検出値Ｇが所定値Ｇ１以上になると、代替車両が必要と判定する。このようにセンサ群２４のうち特に加速度センサ２４ａの検出値を用いることで、代替車両の要否を容易かつ適切に判定することができる。

（５）車両検索部４３５は、予約車両Ｃ１と同一車種の車両Ｃ２〜Ｃ７の中から代替車両を検索する。これにより、予約車両の変更を行った場合にユーザに不利益を与える可能性は小さく、予約車両を適切に変更することができる。

（６）車両管理システム１００は、地理的所定範囲ＡＲ１，ＡＲ２内に点在し、複数の共用車両のいずれかを保有する複数の事業体Ａ店〜Ｄ店を備える（図２）。計画変更部４３６は、車両検索部４３５により複数の代替車両Ｃ２〜Ｃ７が検索されると、予約車両Ｃ１が駐車されたステーションから複数の代替車両Ｃ２〜Ｃ７それぞれが駐車されたステーションまでの地理的近接性に基づいて、複数の代替車両Ｃ２〜Ｃ７の優先順位を決定し、優先順位の最も高い代替車両を予約車両として利用計画を変更する（図２）。これにより代替車両を効率よく予約車両Ｃ１と同一のステーションに手配することができる。

なお、上記実施形態では、代替車両の情報を出力部４３７から出力してユーザに報知するようにしたが、コールセンタからこの情報をユーザに報知するようにしてもよい。また、新たな予約車両と元の予約車両とが同一車種であれば、ユーザにとって不利益は少ないため、この場合には代替車両の情報をユーザ端末３に出力せずに、計画変更部４３６予約車両を変更するようにしてもよい。すなわち、車両検索部４３５により検索された代替車両の情報をユーザに報知する報知部としての出力部４３７を省略することができる。また、代替車両への予約変更を承諾するか否かについてのユーザの指令による応答信号を受信する受信部としての通信部４１を、省略することもできる。検索された代替車両への予約変更を手動で行うようにしてもよく、上述した計画変更部４３６は必須ではない。

上記実施形態では、車両検索部４３５が予約車両と同一車種の代替車両を検索するようにしたが、同一車種だけでなくあるいは同一車種に代えて類似車種の代替車両を検索するようにしてもよい。上記実施形態では、車両検索部４３５で複数の代替車両が検索されたときに、計画変更部４３６は、予約車両が位置するステーション（第１ステーション）と代替車両が位置するステーション（第２ステーション）との地理的近接性に基づいて複数の代替車両の優先順位を決定した。ここで、地理的近接性とは、第１ステーションと第２ステーションとの間の直線距離の短さや、第２ステーションから第１ステーションまでの移動時間の短さを意味する。

上記実施形態では、ユーザ端末３の入出力部３２を介して予約受付部４３１により受け付けられる利用予約の申し込みを行うようにしたが、例えばコールセンタを経由して利用予約の申し込みが行われるようにしてもよい。上記実施形態では、加速度センサ２４ａの検出値Ｇが所定値Ｇ１以上か否かにより、代替車両の要否を判定するようにしたが、代車要否判定部４３４は他のセンサ群２４の検出値に基づいて代替車両の要否を判定するようにしてもよい。すなわち、例えば予約開始時刻までに車両を貸出可能状態に復旧させることが困難となるような車両状態を検出するのであれば、状態検出部の構成はいかなるものでもよい。

上記実施形態では、例えば、第１共有車両としての車両Ｃ１〜Ｃ３を有する事業体Ａ店（第１事業体）と、第２共有車両としての車両Ｃ４を有する事業体Ｂ店（第２事業体）と、これら事業体を管理する事業体Ｅ社（第３事業体）とを含んで複数の事業体を構成するようにしたが、第１事業体〜第３事業体の構成は上述したものに限らない。

上記実施形態では、事業体端末１と車載端末２とユーザ端末３とサーバ装置４とで構成し、サーバ装置４が、予約受付部４３１と計画作成部４３２と車両情報取得部４３３と代車要否判定部４３４と車両検索部４３５と計画変更部４３６と出力部４３７とクーポン処理部とを備えて、車両管理システムの主たる機能を担うようにしたが、これらの機能の一部あるいは全部をサーバ装置以外（例えば事業体端末）に備えるようにしてもよい。上記実施形態では、センサ群２４の検出データを所定時間毎に車載端末２から送信するようにしたが、例えば検出値が所定値以上であるときには、検出データを即座に送信するようにしてもよい。

上記実施形態は、車両の販売やメンテナンス等を行う販売店を事業体としてカーシェアリング事業を行う場合について説明したが、本発明の車両管理システムは、このような販売店だけでなく、他の事業体（例えばガソリンスタンドを運営する事業体等）がカーシェアリング事業を行う場合にも同様に適用することができる。また、カーシェアリング事業に限らず、事業体が車両のレンタル事業を行う場合にも同様に適用することができる。車両管理システムが適用される組織体系は、３階層ではなく上位層および下位層の２階層でもよく、４階層以上でもよい。

以上の説明はあくまで一例であり、本発明の特徴を損なわない限り、上述した実施形態および変形例により本発明が限定されるものではない。上記実施形態と変形例の１つまたは複数を任意に組み合わせることも可能であり、変形例同士を組み合わせることも可能である。

１事業体端末、２車載端末、３ユーザ端末、４サーバ装置、２４センサ群、２４ａ加速度センサ、４１通信部、１００車両管理システム、４３２計画作成部、４３４代車要否判定部、４３５車両検索部、４３６計画変更部、４３７出力部

Claims

ユーザに貸出可能な複数の共用車両にそれぞれ設けられ、各共用車両の車両状態を検出する状態検出部と、
複数の共用車両の現在および将来の利用計画を作成する計画作成部と、
複数の共有車両の前記利用計画を含む車両情報を記憶する記憶部と、
前記状態検出部により検出された車両状態と前記記憶部に記憶された前記利用計画とに基づき、複数の共用車両のうちユーザにより予約された予約車両の代替となる代替車両の要否を判定する代車要否判定部と、
前記代車要否判定部により代替車両が必要と判定されると、前記記憶部に記憶された複数の共用車両の車両情報に基づいて代替車両を検索する車両検索部と、を備え、
前記状態検出部は、前記予約車両に作用する加速度を検出する加速度センサを有し、
前記代車要否判定部は、前記予約車両の利用開始予定時刻よりも前に前記加速度センサの検出値が所定値以上になると、前記代替車両が必要と判定することを特徴とする車両管理システム。
請求項１に記載の車両管理システムにおいて、
前記車両検索部により検索された代替車両を新たな予約車両として前記利用計画を変更する計画変更部をさらに備えることを特徴とする車両管理システム。
請求項２に記載の車両管理システムにおいて、
前記車両検索部により検索された代替車両をユーザに報知する報知部と、
前記報知部により報知された代替車両への予約変更を承諾するか否かについてのユーザの指令による応答信号を受信する受信部と、をさらに備え、
前記計画変更部は、前記受信部が予約変更を承諾するとの応答信号を受信すると、前記代替車両を新たな予約車両として前記利用計画を変更することを特徴とする車両管理システム。
請求項１〜３のいずれか１項に記載の車両管理システムにおいて、
前記車両検索部は、前記予約車両と同一車種または類似車種の共有車両の中から代替車両を検索することを特徴とする車両管理システム。
請求項２または３に記載の車両管理システムにおいて、
地理的所定範囲内に点在し、複数の共用車両のいずれかを保有する複数の事業体を備え、
前記計画変更部は、前記車両検索部により複数の代替車両が検索されると、予約車両が駐車されたステーションから複数の代替車両それぞれが駐車されたステーションまでの地理的近接性に基づいて、複数の代替車両の優先順位を決定し、優先順位の最も高い代替車両を予約車両として利用計画を変更することを特徴とする車両管理システム。