JP2019008660A - カーシェアリング管理システム - Google Patents

Abstract

【課題】効率的にカーシェアリング事業を行い得るカーシェアリング管理システムを提供する。【解決手段】カーシェアリング管理システム１００は、予約車両の利用計画を作成する計画作成部４３２と、予約車両のメンテナンス終了前に、予約車両の車両状態に応じたメンテナンス予定時間に関する情報を取得するメンテナンス情報取得部４３３と、取得されたメンテナンス予定時間に関する情報と作成された利用計画とに基づいて代替車両の要否を判定する代車要否判定部４３４と、代替車両が必要と判定されると、複数の事業体が保有する複数の共有車両の中から代替車両を検索する車両検索部４３５と、検索された代替車両を新たな予約車両として利用計画を変更する計画変更部４３６とを備える。【選択図】図３

Description

本発明は、カーシェアリング事業を効率的に行い得るカーシェアリング管理システムに関する。

カーシェアリング事業においては、運転技術や運転態様が異なる様々なユーザが種々の目的で共通の車両を利用する。したがって、常にユーザに良好な状態で車両を貸し出すことが可能となるように車両の貸出の前、すなわち、車両が所定の駐車スペースに返却されてから次の利用に供されるまでの空き時間に、車両のメンテナンスが行われることが好ましい。この点に関し、従来より、ディーラがアクセス可能なサーバにメンテナンス情報を履歴形式で記憶し、ディーラ側でその情報を参照することで、車両のメンテナンスを適宜行うようにしたシステムが知られている（例えば特許文献１参照）。

特開２００８−１１７０７６号公報

しかしながら、上記特許文献１記載のシステムは、車両が駐車スペースに返却される度にメンテナンスを行うものではないため、次に車両を利用するユーザに正常状態で車両を貸し出すことができるとは限らず、ユーザに損害を与えるおそれがある。

一方、車両が駐車スペースに返却される度にメンテナンスを行う場合、カーシェアリング事業を効率的に行うためには、メンテナンスが終了してから車両予約の受付を開始するのではなく、予め所定のメンテナンス時間を確保した上で、メンテナンス終了予定時刻以降の車両予約を随時受け付けることが好ましい。しかしながら、実際のメンテナンス時間は個々の車両状態に応じて定まるため、メンテナンス終了時刻がメンテナンス終了予定時刻を超えるおそれがあり、その場合には、既に受け付けられた予約の対応に支障を来たすおそれがある。

本発明の一態様は、地理的所定範囲内に点在する複数の事業体であって、それぞれがカーシェアリングに供される共用車両を保有するとともに、共用車両のメンテナンスを行うメンテナンス拠点と共用車両が駐車されるステーションとを有する複数の事業体を含む組織体系の下で行われるカーシェアリング事業を管理するカーシェアリング管理システムであって、共有車両の利用予約の申し込みを受け付ける予約受付部と、予約受付部により受け付けられた予約車両の利用開始時刻よりも前に実行されるメンテナンス計画を含む予約車両の利用計画を作成する計画作成部と、予約車両のメンテナンス終了前に、予約車両の車両状態に応じたメンテナンス予定時間に関する情報を取得するメンテナンス情報取得部と、メンテナンス情報取得部により取得されたメンテナンス予定時間に関する情報と、計画作成部により作成された利用計画とに基づいて、代替車両の要否を判定する代車要否判定部と、代車要否判定部により代替車両が必要と判定されると、複数の事業体が保有する複数の共有車両の中から代替車両を検索する車両検索部と、車両検索部により検索された代替車両を新たな予約車両として利用計画を変更する計画変更部と、を備える。

本発明によれば、予約車両のメンテナンス時間が延びたとしても、代替車両の手配により予約の対応に支障を来たすことなく、効率的にカーシェアリング事業を行うことができる。

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

以下、図１〜図６Ｂを参照して本発明の一実施形態について説明する。レンタカー事業は、対面での車両の貸出を行うのに対し、カーシェアリング事業は、予め登録したＩＣカードを用いて無人での車両の貸出を行う。本発明の実施形態に係るカーシェアリング管理システムは、車両の販売やメンテナンス（点検、整備）を行う販売店（カーディーラ）等の事業体が主体となってカーシェアリング事業を行う場合に適したシステムとして構成される。事業体の敷地内には、事業体が保有し、カーシェアリング事業に供される車両（共用車両）が駐車される。このような共有車両が駐車される場所をステーションと呼ぶ。

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

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

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

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

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

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

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

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

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

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

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

入出力部１２は、いわゆるヒューマンインターフェース（ＨＭＩ）であり、ユーザが操作可能なキーボード、マウス、モニタ、タッチパネル、プリンタ等を有する。各事業体の従事者（社員）は、入出力部１２を介して車両Ｃ１〜Ｃ７の各種情報を入力することができるとともに、代替車両の手配に関する情報を取得することができる。社員により入力されるメンテナンス情報には、メンテナンスが終了するまでに要すると予想される時間（メンテナンス予定時間）が含まれる。メンテナンス予定時間は、ステーションに返却された車両Ｃ１〜Ｃ７をメンテナンス拠点において社員（作業員）が実際にメンテナンスを開始した後、その社員自身によって判断される時間であり、メンテナンス予定時間に基づいてサーバ装置４で代替車両の要否が判断される。なお、メンテナンス予定時間の代わりに、メンテナンスの予定終了時刻を、社員により入力されるメンテナンス情報としてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

計画作成部４３２は、共用車両の現在および将来の利用計画を作成し、利用計画を車両データベース４４１に登録する。より具体的には、予約受付部４３１により受け付けられた予約車両の利用計画を作成し、これを車両データベース４４１に登録する。利用計画には、予約車両の利用開始日時および利用終了日時と、利用開始日時よりも前に実行されるメンテナンス計画とが含まれる。例えば図４に示すように、ユーザにより予約された車両Ｃ１の利用開始時刻ｔ３および利用終了時刻ｔ４と、時点ｔ３よりも前の時点ｔ１〜ｔ２に予定されるメンテナンス計画とが利用計画に含まれる。なお、本実施形態では、車両Ｃ１がステーションに返却された直後、すなわち車両Ｃ１の利用終了時刻ｔ１を起点として計画作成部４３２がメンテナンス計画を組み込む。車両がステーションに返却されてから所定時間後にメンテナンス計画が組み込まれるようにしてもよい。

メンテナンス計画は、予め標準的なメンテナンス時間を考慮して作成される。すなわち、計画作成部４３２は、予約車両の利用終了時刻ｔ１をメンテナンス開始時刻（予定時刻）とするとともに、そこから予め定めた標準的なメンテナンス時間ΔＴ０が経過した時点ｔ２をメンテナンス終了時刻（予定時刻）として、メンテナンス計画を作成する。標準メンテナンス時間ΔＴ０は、実際の作業時間、ステーションとメンテナンス拠点との間の車両Ｃ１の移動時間、および所定の予備的時間を含む。なお、予備的時間は、作業時間に多少のばらつきが生じる点を考慮して定められるものであり、車両の利用効率を高める観点からは、予備的時間は短い方が好ましい。

メンテナンス拠点の作業員は、車両のメンテナンス開始後、できる限り速やかに実際の車両状態をチェックする。そして、メンテナンス終了までに要するメンテナンス予定時間を予測し、そのメンテナンス予定時間あるいはメンテナンスの予定終了時刻等のメンテナンス情報を事業体端末１の入出力部１２を介して入力する。作業員は、メンテナンス予定時間を数値で入力するのではなく、例えば入出力部１２（モニタ）に表示された複数のメンテナンス予定時間の候補の中から１つを選択し、これによりメンテナンス予定時間を入力してもよい。メンテナンス情報取得部４３３は、このように入出力部１２を介して作業員により入力されたメンテナンス情報を取得する。

なお、メンテナンス予定時間が標準メンテナンス時間ΔＴ０以下のとき、作業員はメンテナンス予定時間の入力を省略してもよい。例えば、事業体端末１は、作業員によるメンテナンス予定時間の入力が所定時間以上ないとき、メンテナンス予定時間が標準メンテナンス時間ΔＴ０であるとの情報をサーバ装置４に送信してもよい。あるいは、作業員によるメンテナンス予定時間の入力がないことにより、サーバ装置４がメンテナンス開始時刻から所定時間メンテナンス時間に関する信号を受信しないとき、例えばサーバ装置４の内部処理によりメンテナンス情報取得部４３３が、メンテナンス予定時間が標準メンテナンス時間ΔＴ０であるとの情報を取得するようにしてもよい。

代車要否判定部４３４は、メンテナンス情報取得部４３３により取得されたメンテナンス情報と、計画作成部４３２により作成された利用計画とに基づいて、代替車両の要否を判定する。具体的には、代車要否判定部４３４は、メンテナンスの予定終了時刻と予約車両の利用開始時刻との先後に応じて車両の要否を判定する。例えば図４に示すように、メンテナンス開始後に判断されたメンテナンス予定時間がΔＴ１であり、メンテナンスの予定終了時刻が利用開始時刻ｔ３よりも後であるとき、予約車両Ｃ１を利用開始時刻ｔ３に貸し出すことができないため、代車要否判定部４３４は、代替車両を必要と判定する。一方、メンテナンス予定時間が標準メンテナンス時間ΔＴ０であるとき、メンテナンスの予定終了時刻が利用開始時刻ｔ３よりも後でないため、代車要否判定部４３４は、代替車両を不要と判定する。

車両検索部４３５は、例えばメンテナンス予定時間が図４に示すΔＴ１で、代車要否判定部４３４により予約車両Ｃ１の代替車両が必要と判定されると、車両データベース４４１を参照して代替車両を検索する。すなわち、予約車両Ｃ１と同一車種の車両Ｃ２〜Ｃ７の中から代替車両を検索する。代替車両は、既にメンテナンスが完了し、かつ、予約車両Ｃ１の利用時間ｔ３〜ｔ４内に未だ予約が入っていない車両の中から検索される。

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

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

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

図５は、予めサーバ装置４の記憶部４４に記憶されたプログラムに従い、演算部４３で実行される処理の一例を示すフローチャートである。このフローチャートに示す処理は、例えばユーザ端末３を介してユーザにより入力された共有車両の利用予約の申し込みの指令を、通信部４１を介して受信すると開始され、所定時間毎に繰り返される。

まず、ステップＳ１で、予約受付部４３１での処理により、共有車両の利用予約の申し込みを受け付ける。次いで、ステップＳ２で、計画作成部４３２での処理により、予約車両の利用計画を作成する。この利用計画には、予約車両の利用開始時刻（例えば図４のｔ３）よりも前に実行されるメンテナンス計画（例えば図４のｔ１〜ｔ２）が含まれる。

次いで、ステップＳ３で、メンテナンス情報取得部４３３での処理により、事業体端末１から予約車両のメンテナンス情報、すなわちメンテナンス予定時間に関する情報を取得したか否かを判定する。この情報は、予約車両のメンテナンスが開始されたときに、入出力部１２を介して作業員により入力されて、通信部４１を介して受信された情報である。ステップＳ３は肯定されるまで繰り返され、ステップＳ３で肯定されるとステップＳ４に進む。

ステップＳ４では、代車要否判定部４３４での処理により、メンテナンス終了予定時刻が予約車両の利用開始時刻（例えば図４のｔ３）よりも後か否かを判定し、これにより代替車両が必要か否かを判定する。ステップＳ４で肯定されると、ステップＳ５に進み、否定されると、利用計画を変更する必要がないため、処理を終了する。

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

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

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

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

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

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

まず、図６Ａの例について説明する。図６Ａの時点ｔ１で、Ａ店の作業員により予約車両Ｃ１のメンテナンスが開始され、メンテナンス予定時間ΔＴ１が標準メンテナンス時間ΔＴ０を超え、メンテナンスの予定終了時刻が予約車両Ｃ１の利用開始時刻ｔ３よりも後になったと仮定する。このとき、演算部４３により代替車両が必要と判定され（ステップＳ４）、図６Ａの例では、既にメンテナンスが完了し、かつ、時点ｔ３〜ｔ４において予約が入っていない空き車両Ｃ３，Ｃ４，Ｃ５，Ｃ７が代替車両として検索される（ステップＳ５）。

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

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

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

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

本実施形態によれば以下のような作用効果を奏することができる。
（１）本実施形態のカーシェアリング管理システム１００は、地理的所定範囲ＡＲ１，ＡＲ２内に点在する複数の事業体であって、それぞれがカーシェアリングに供される車両Ｃ１〜Ｃ７を保有するとともに、車両Ｃ１〜Ｃ７のメンテナンスを行うメンテナンス拠点と車両Ｃ１〜Ｃ７が駐車されるステーションとを有する複数の事業体を含む組織体系の下で行われるカーシェアリング事業を管理するものである（図１，２）。このカーシェアリング管理システム１００は、車両の利用予約の申し込みを受け付ける予約受付部４３１と、予約受付部４３１により受け付けられた予約車両（例えば車両Ｃ１）の利用開始時刻（例えば図４のｔ３）よりも前に実行されるメンテナンス計画（例えば図４のｔ１〜ｔ２）を含む予約車両Ｃ１の利用計画を作成する計画作成部４３２と、予約車両Ｃ１のメンテナンス終了前に、予約車両Ｃ１の車両状態に応じたメンテナンス予定時間ΔＴ０，ΔＴ１に関する情報を取得するメンテナンス情報取得部４３３と、メンテナンス情報取得部４３３により取得されたメンテナンス予定時間ΔＴ０，ΔＴ１に関する情報と、計画作成部４３２により作成された利用計画とに基づいて、メンテナンス終了時刻が車両Ｃ１の利用開始時刻（例えば図４のｔ３）よりも後か否かにより、代替車両の要否を判定する代車要否判定部４３４と、代車要否判定部４３４により代替車両が必要と判定されると、複数の事業体が保有する複数の車両Ｃ２〜Ｃ７の中から代替車両を検索する車両検索部４３５と、車両検索部４３５により検索された代替車両を新たな予約車両として利用計画を変更する計画変更部４３６と、を備える（図３）。

このような構成により、例えば予約車両Ｃ１のメンテナンス時間が標準メンテナンス時間ΔＴ０よりも長くなって、次の利用開始時刻ｔ３までにメンテナンスが終了しない状況であるとき、予約車両Ｃ１の代替車両を容易に準備することができる。このため、メンテナンス時間が当初の見込みよりも長くかかったとしても、ユーザは支障なく共用車両を利用することができ、共用車両の空き時間を短縮した効率的なカーシェアリング事業を行うことができる。また、共用車両の返却の度にメンテナンスを行うように利用計画を作成するので、常に良好な状態で共用車両をカーシェアリングに供することができる。すなわち、本実施形態のカーシェアリング管理システム１００は、地理的所定範囲ＡＲ１，ＡＲ２内に点在し、メンテナンス拠点を有するカーディラー等の事業体が主体となって行うので、車両のメンテナンスを容易に行うことができるとともに、代替車両の手配も容易である。

（２）カーシェアリング管理システム１００は、計画変更部４３６により変更された利用計画に含まれる新たな予約車両の情報を出力し、通信部４１を介して当該情報をユーザに報知する出力部４３７をさらに備える（図３）。これにより予約車両の変更に関する情報をユーザは認識することができる。

（３）カーシェアリング管理システム１００は、出力部４３７からの情報出力によりユーザに予約車両の変更に関する情報を報知したときに、ユーザ端末３から送信された応答信号、すなわち予約車両の変更に対する承諾または非承諾を含むユーザの指令による応答信号を受信する通信部４１をさらに備える（図３）。計画変更部４３６は、通信部４１により承諾の応答信号が受信されることを条件として、利用計画を変更（変更を確定）する。このようにユーザの承諾を条件として予約車両の変更を行うことで、ユーザの意思を尊重した予約車両の変更が可能である。

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

（５）計画変更部４３６は、車両検索部４３５により予約車両Ｃ１と同一車種の複数の代替車両Ｃ２〜Ｃ７が検索されると、予約車両Ｃ１が駐車されたステーションから複数の代替車両Ｃ２〜Ｃ７それぞれが駐車されたステーションまでの地理的近接性に基づいて、複数の代替車両Ｃ２〜Ｃ７の優先順位を決定し、優先順位の最も高い代替車両を予約車両として利用計画を変更する（図２）。これにより代替車両を効率よく予約車両Ｃ１と同一のステーションに手配することができる。

（６）カーシェアリング管理システム１００は、車両Ｃ１〜Ｃ７を利用する予定のユーザが有し、予約受付部４３１により受け付けられる利用予約を申し込むための入出力部３２を有するユーザ端末３と、複数の事業体がそれぞれ有し、メンテナンス情報取得部４３３により取得されるメンテナンス予定時間に関する情報が事業体の社員により入力される入出力部１２をそれぞれが有する複数の事業体端末１と、複数の事業体端末１およびユーザ端末３と通信可能に接続され、上述の予約受付部４３１と、計画作成部４３２と、メンテナンス情報取得部４３３と、代車要否判定部４３４と、車両検索部４３５と、計画変更部４３６とを有するサーバ装置４と、を備える。このように事業体端末１とユーザ端末３とサーバ装置４とを含んでカーシェアリング管理システム１００を構成することで、カーシェアリング事業を効率よく行うことができる。

（７）複数の事業体は、車両Ｃ１〜Ｃ３を有する事業体Ａ店と、車両Ｃ１〜Ｃ３と同一車種の車両Ｃ４を有する事業体Ｂ店と、事業体Ａ店およびＢ店の業務を管理する事業体Ｅと、を含む（図１，２）。事業体Ａ店が有する事業体端末１は、車両Ｃ１〜Ｃ３の車両情報を取得する車両情報取得部１３ａを有し、事業体Ｂ店が有する事業体端末１は、車両Ｃ４の車両情報を取得する車両情報取得部１３ａを有し、事業体Ｅ社が有する事業体端末１は、車両Ｃ１〜Ｃ３および車両Ｃ４の車両情報を取得する車両情報取得部１３ａを有する。これにより、事業体が有する車両情報がその事業体と同列の他の事業体に取得されることを防止することができる。また、上位の事業体は下位の事業体が有する車両情報を取得することができ、取得した車両情報に基づいて車両を適切に管理することができる。

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

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

上記実施形態では、ユーザ端末３の入出力部３２を介して予約受付部４３１により受け付けられる利用予約の申し込みを行うようにしたが、申し込み部の構成はこれに限らない。コールセンタを経由して利用予約の申し込みが行われるようにしてもよい。上記実施形態では、事業体端末１の入出力部１２を介してメンテナンス予定時間に関する情報が入力されるようにしたが、メンテナンス入力部の構成はこれに限らない。例えば、メンテナンスの開始時刻から所定時間が経過したにも拘らずメンテナンス予定時間に関する情報が事業体端末１から出力されないとき、メンテナンス予定時間が標準メンテナンス時間ΔＴ０を超えないとの情報をメンテナンス情報取得部が取得するようにしてもよい。

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

上記実施形態では、事業体端末１と車載端末２とユーザ端末３とサーバ装置４とでカーシェアリング管理システム１００を構成し、サーバ装置４が、予約受付部４３１と計画作成部４３２とメンテナンス情報取得部４３３と代車要否判定部４３４と車両検索部４３５と計画変更部４３６とを備えて、カーシェアリング管理システムの主たる機能を担うようにしたが、これらの機能の一部あるいは全部をサーバ装置以外（例えば事業体端末）に備えるようにしてもよい。

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

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

１ 事業体端末、２ 車載端末、３ ユーザ端末、４ サーバ装置、１２ 入出力部、１３ａ 車両情報取得部、３２ 入出力部、４１ 通信部、１００ カーシェアリング管理システム、４３１ 予約受付部、４３２ 計画作成部、４３３ メンテナンス情報取得部、４３４ 代車要否判定部、４３５ 車両検索部、４３６ 計画変更部、４３７ 出力部

Claims (7)

1. 地理的所定範囲内に点在する複数の事業体であって、それぞれがカーシェアリングに供される共用車両を保有するとともに、共用車両のメンテナンスを行うメンテナンス拠点と共用車両が駐車されるステーションとを有する複数の事業体を含む組織体系の下で行われるカーシェアリング事業を管理するカーシェアリング管理システムであって、
   共有車両の利用予約の申し込みを受け付ける予約受付部と、
   前記予約受付部により受け付けられた予約車両の利用開始時刻よりも前に実行されるメンテナンス計画を含む前記予約車両の利用計画を作成する計画作成部と、
   前記予約車両のメンテナンス終了前に、前記予約車両の車両状態に応じたメンテナンス予定時間に関する情報を取得するメンテナンス情報取得部と、
   前記メンテナンス情報取得部により取得された前記メンテナンス予定時間に関する情報と、前記計画作成部により作成された前記利用計画とに基づいて、代替車両の要否を判定する代車要否判定部と、
   前記代車要否判定部により代替車両が必要と判定されると、前記複数の事業体が保有する複数の共有車両の中から代替車両を検索する車両検索部と、
   前記車両検索部により検索された代替車両を新たな予約車両として前記利用計画を変更する計画変更部と、を備えることを特徴とするカーシェアリング管理システム。
2. 請求項１に記載のカーシェアリング管理システムにおいて、
   前記計画変更部により変更された利用計画に含まれる新たな予約車両の情報をユーザに報知する報知部をさらに備えることを特徴とするカーシェアリング管理システム。
3. 請求項２に記載のカーシェアリング管理システムにおいて、
   前記報知部により報知された予約車両の変更に対する承諾または非承諾を含むユーザの指令による応答信号を受信する受信部をさらに備え、
   前記計画変更部は、前記受信部により承諾の応答信号が受信されることを条件として、前記利用計画を変更することを特徴とするカーシェアリング管理システム。
4. 請求項１〜３のいずれか１項に記載のカーシェアリング管理システムにおいて、
   前記車両検索部は、前記予約受付部により利用予約が受け付けられた前記予約車両と同一車種または類似車種の共有車両の中から代替車両を検索することを特徴とするカーシェアリング管理システム。
5. 請求項４に記載のカーシェアリング管理システムにおいて、
   前記計画変更部は、前記車両検索部により前記予約車両と同一車種または類似車種の複数の代替車両が検索されると、前記予約車両が駐車された第１ステーションから前記複数の代替車両それぞれが駐車された第２ステーションまでの地理的近接性に基づいて、前記複数の代替車両の優先順位を決定し、優先順位の最も高い代替車両を予約車両として前記利用計画を変更することを特徴とするカーシェアリング管理システム。
6. 請求項１〜５のいずれか１項に記載のカーシェアリング管理システムにおいて、
   共有車両を利用する予定のユーザが有するユーザ端末であって、前記予約受付部により受け付けられる利用予約の申し込み部を有するユーザ端末と、
   前記複数の事業体がそれぞれ有する複数の事業体端末であって、それぞれが前記メンテナンス情報取得部により取得されるメンテナンス予定時間に関する情報が事業体の従事者により入力されるメンテナンス入力部を有する複数の事業体端末と、
   前記複数の事業体端末および前記ユーザ端末と通信可能に接続されたサーバ装置であって、前記予約受付部と、前記計画作成部と、前記メンテナンス情報取得部と、前記代車要否判定部と、前記車両検索部と、前記計画変更部とを有するサーバ装置と、を備えることを特徴とするカーシェアリング管理システム。
7. 請求項６に記載のカーシェアリング管理システムにおいて、
   前記複数の事業体は、第１共用車両を有する第１事業体と、前記第１共用車両と同一車種または類似車種の第２共用車両を有する第２事業体と、前記第１事業体および前記第２事業体の業務を管理する第３事業体と、を含み、
   前記第１事業体が有する前記事業体端末は、前記第１共用車両の車両情報を取得する第１車両情報取得部を有し、
   前記第２事業体が有する前記事業体端末は、前記第２共用車両の車両情報を取得する第２車両情報取得部を有し、
   前記第３事業体が有する前記事業体端末は、前記第１共用車両および前記第２共有車両の車両情報を取得する第３車両情報取得部を有することを特徴とするカーシェアリング管理システム。

Images