特許 7571738 コンピュータ、カーシェアリングシステム、及びカーシェアリング方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-15

(45)【発行日】2024-10-23

(54)【発明の名称】コンピュータ、カーシェアリングシステム、及びカーシェアリング方法

(51)【国際特許分類】

   G06Q 10/20 20230101AFI20241016BHJP

   B60L 58/16 20190101ALI20241016BHJP

   G06Q 30/0645 20230101ALI20241016BHJP

   G06Q 50/40 20240101ALI20241016BHJP

【ＦＩ】

G06Q10/20

B60L58/16

G06Q30/0645

G06Q50/40

【請求項の数】 8

(21)【出願番号】P 2022011735

(22)【出願日】2022-01-28

(65)【公開番号】P2023110349

(43)【公開日】2023-08-09

【審査請求日】2023-07-11

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】小林 亮介

(72)【発明者】

【氏名】眞屋 朋和

(72)【発明者】

【氏名】岡田 強志

(72)【発明者】

【氏名】藤井 宏光

【審査官】阿部 圭子

(56)【参考文献】

【文献】特開２０２１－０４７５７７（ＪＰ，Ａ）

【文献】特開２０２１－１２３１３９（ＪＰ，Ａ）

【文献】特開２０２１－０４８６８７（ＪＰ，Ａ）

【文献】特開２０１５－０３６８７１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ － ９９／００

Ｂ６０Ｌ ５８／１６

(57)【特許請求の範囲】

【請求項1】

複数のユーザによって使用された１台の車両で部品のメンテナンスが行なわれたときに、そのメンテナンスにかかる費用のユーザごとの負担割合を、メンテナンスされた部品の種類とユーザごとの前記車両の使用態様とに基づいて決定する、コンピュータであって、
前記コンピュータはプロセッサと記憶装置とを備え、
前記記憶装置には、複数の部品区分と複数の用途区分と費用負担割合との関係を示す費用負担情報が記憶されており、
前記プロセッサは、前記複数の部品区分のうち前記メンテナンスされた部品の種類が属する部品区分と、前記複数の用途区分のうち各ユーザの前記車両の用途が属する用途区分とから、各ユーザの費用負担割合を取得し、取得された各ユーザの費用負担割合を用いて、前記メンテナンスにかかる費用のユーザごとの負担割合を決定する、コンピュータ。

【請求項2】

前記複数の部品区分は、内装品に関する第１部品区分と、駆動系の部品に関する第２部品区分と、サスペンションに関する第３部品区分と、蓄電装置に関する第４部品区分とからなる群より選択される２つ以上の部品区分を含み、
前記複数の用途区分は、オフィス用途に関する第１用途区分と、旅客輸送用途に関する第２用途区分と、物流用途に関する第３用途区分と、医療用途に関する第４用途区分とからなる群より選択される２つ以上の用途区分を含む、請求項１に記載のコンピュータ。

【請求項3】

前記記憶装置には、ユーザごとの前記車両の使用時間を示すユーザ情報がさらに記憶されており、
前記プロセッサは、前記費用負担情報によって示される各ユーザの費用負担割合に加えて、前記ユーザ情報によって示される各ユーザの前記車両の使用時間をさらに用いて、前記メンテナンスにかかる費用のユーザごとの負担割合を決定する、請求項１又は２に記載のコンピュータ。

【請求項4】

請求項１～３のいずれか一項に記載のコンピュータと、前記複数のユーザが共用する前記車両とを含むカーシェアリングシステムであって、
前記車両は、内装品を変更することによってユーザの用途に合わせてカスタマイズ可能に構成される多目的車両である、カーシェアリングシステム。

【請求項5】

前記車両は、
制御装置と、
自動運転キットと、
前記制御装置と前記自動運転キットとの間での信号のやり取りを仲介する車両制御インターフェースとを備え、
前記自動運転キットは、自動運転のための指令を、前記車両制御インターフェースを介して前記制御装置へ送るように構成され、
前記制御装置は、前記自動運転キットからの前記指令に従って前記車両を制御するように構成され、
前記制御装置は、前記車両の状態を示す信号を、前記車両制御インターフェースを介して前記自動運転キットへ送るように構成される、請求項４に記載のカーシェアリングシステム。

【請求項6】

車両で部品のメンテナンスが行なわれたときに、コンピュータが、そのメンテナンスにかかる費用のユーザごとの負担割合を、メンテナンスされた部品の種類とユーザごとの前記車両の使用態様とに基づいて決定する、カーシェアリング方法であって、
前記コンピュータはプロセッサと記憶装置とを備え、
前記記憶装置には、複数の部品区分と複数の用途区分と費用負担割合との関係を示す費用負担情報が記憶されており、
前記カーシェアリング方法は、
前記コンピュータが、前記複数の部品区分のうち前記メンテナンスされた部品の種類が属するメンテナンス部品区分を取得することと、
前記コンピュータが、前記複数の用途区分のうち第１ユーザの前記車両の用途が属する第１ユーザ用途区分を取得することと、
前記コンピュータが、前記複数の用途区分のうち第２ユーザの前記車両の用途が属する第２ユーザ用途区分を取得することと、
前記コンピュータが、取得された前記メンテナンス部品区分、前記第１ユーザ用途区分、及び前記第２ユーザ用途区分を用いて、前記第１ユーザと前記第２ユーザとの費用負担割合を取得することと、
前記コンピュータが、取得された前記費用負担割合を用いて、前記メンテナンスにかかる費用のユーザごとの負担割合を決定することと、
を含む、カーシェアリング方法。

【請求項7】

前記複数の部品区分は、内装品に関する第１部品区分と、駆動系の部品に関する第２部品区分と、サスペンションに関する第３部品区分と、蓄電装置に関する第４部品区分とからなる群より選択される２つ以上の部品区分を含み、
前記複数の用途区分は、オフィス用途に関する第１用途区分と、旅客輸送用途に関する第２用途区分と、物流用途に関する第３用途区分と、医療用途に関する第４用途区分とからなる群より選択される２つ以上の用途区分を含む、請求項６に記載のカーシェアリング方法。

【請求項8】

前記記憶装置には、ユーザごとの前記車両の使用時間を示すユーザ情報がさらに記憶されており、
前記プロセッサは、前記費用負担情報によって示される各ユーザの費用負担割合に加えて、前記ユーザ情報によって示される各ユーザの前記車両の使用時間をさらに用いて、前記メンテナンスにかかる費用のユーザごとの負担割合を決定する、請求項６又は７に記載のカーシェアリング方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、コンピュータ、カーシェアリングシステム、及びカーシェアリング方法に関する。

【背景技術】

【0002】

特開２０１５－１３８３９５号公報（特許文献１）には、鉄道又はバスのような予め定められた軌道を車両が走行する交通システムにおいてメンテナンスにかかるコスト（人件費、及び作業に必要な物品のコスト）を算出する技術が開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１５－１３８３９５号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

近年、１台の車両を複数のユーザでシェア（共用）することで、１台の車両を有効に活用することが提案されている。１台の車両について長期間のカーシェアリングが行なわれる形態では、その車両に搭載された部品のメンテナンス（たとえば、検査、修理、又は交換）を行なうときに、メンテナンスにかかる費用を各ユーザが負担することが考えられる。

【0005】

しかしながら、ユーザごとのメンテナンス費用の負担割合をユーザ間の話合いで決めることは困難である。また、人数による単純な按分によってメンテナンス費用の負担割合を決めることは、必ずしも公平ではない。たとえば、部品の劣化を早める態様で車両を使用したユーザと、部品を劣化させない態様で車両を使用したユーザとが、同じ割合で費用を負担することは、公平とはいえない。

【0006】

本開示は、上記課題を解決するためになされたものであり、その目的は、複数のユーザによって使用された１台の車両において部品のメンテナンスが行なわれたときに、そのメンテナンスにかかる費用のユーザごとの負担割合を公平に決めることである。

【課題を解決するための手段】

【0007】

本開示の第１の観点に係るコンピュータは、複数のユーザによって使用された１台の車両で部品のメンテナンスが行なわれたときに、そのメンテナンスにかかる費用のユーザごとの負担割合を、メンテナンスされた部品の種類とユーザごとの車両の使用態様とに基づいて決定するように構成される。

【0008】

上記コンピュータによれば、複数のユーザによって使用された１台の車両において部品のメンテナンスが行なわれたときに、そのメンテナンスにかかる費用のユーザごとの負担割合が、メンテナンスされた部品の種類とユーザごとの車両の使用態様とに基づいて決定される。こうしたコンピュータによれば、ユーザごとの費用負担割合を公平に決めることが可能になる。

【0009】

上記コンピュータは、プロセッサと記憶装置とを備えてもよい。記憶装置には、複数の部品区分と複数の用途区分と費用負担割合との関係を示す費用負担情報が記憶されてもよい。プロセッサは、複数の部品区分のうちメンテナンスされた部品の種類が属する部品区分と、複数の用途区分のうち各ユーザの車両の用途が属する用途区分とから、各ユーザの費用負担割合を取得し、取得された各ユーザの費用負担割合を用いて、メンテナンスにかかる費用のユーザごとの負担割合を決定するように構成されてもよい。こうした構成によれば、ユーザごとの費用負担割合を容易かつ的確に決めることが可能になる。

【0010】

上記複数の部品区分は、内装品に関する第１部品区分と、駆動系の部品に関する第２部品区分と、サスペンションに関する第３部品区分と、蓄電装置に関する第４部品区分とからなる群より選択される２つ以上の部品区分を含んでもよい。上記複数の用途区分は、オフィス用途に関する第１用途区分と、旅客輸送用途に関する第２用途区分と、物流用途に関する第３用途区分と、医療用途に関する第４用途区分とからなる群より選択される２つ以上の用途区分を含んでもよい。

【0011】

上記構成によれば、ユーザごとの費用負担割合を公平に決めやすくなる。たとえば、旅客輸送用途とオフィス用途とを比較すると、駆動系の部品及びサスペンション関連部品の各々は旅客輸送用途のほうが劣化しやすく、蓄電装置の部品はオフィス用途のほうが劣化しやすい傾向がある。旅客輸送用途と物流用途とを比較すると、内装品と駆動系の部品とサスペンション関連部品と蓄電装置の部品とのいずれも物流用途のほうが劣化しやすい傾向がある。旅客輸送用途と医療用途とを比較すると、駆動系の部品及びサスペンション関連部品の各々は旅客輸送用途のほうが劣化しやすく、蓄電装置の部品は医療用途のほうが劣化しやすい傾向がある。オフィス用途と医療用途とを比較すると、駆動系の部品とサスペンション関連部品と蓄電装置の部品とのいずれも医療用途のほうが劣化しやすい傾向がある。

【0012】

上記記憶装置には、ユーザごとの車両の使用時間を示すユーザ情報がさらに記憶されてもよい。プロセッサは、費用負担情報によって示される各ユーザの費用負担割合に加えて、ユーザ情報によって示される各ユーザの車両の使用時間をさらに用いて、メンテナンスにかかる費用のユーザごとの負担割合を決定するように構成されてもよい。こうした構成によれば、ユーザごとの費用負担割合をより公平に決めやすくなる。

【0013】

前述のコンピュータは、車両で部品のメンテナンスが行なわれたときに、ユーザごとに、車両の使用に起因した当該部品の劣化進行度を取得し、ユーザごとの部品の劣化進行度を用いて、部品のメンテナンスにかかる費用のユーザごとの負担割合を決定するように構成されてもよい。こうした構成によっても、ユーザごとの費用負担割合をより公平に決めやすくなる。

【0014】

本開示の第２の観点に係るカーシェアリングシステムは、上述したいずれかのコンピュータと、複数のユーザが共用する車両とを含む。車両は、内装品を変更することによってユーザの用途に合わせてカスタマイズ可能に構成される多目的車両である。

【0015】

上記カーシェアリングシステムは、前述したコンピュータを含む。このため、上記カーシェアリングシステムによれば、複数のユーザによって使用された１台の車両において部品のメンテナンスが行なわれたときに、そのメンテナンスにかかる費用のユーザごとの負担割合を公平に決めることが可能になる。また、多目的車両が採用されることによって、ユーザごとのニーズに合った装備を有する車両を各ユーザに提供しやすくなる。

【0016】

上述したいずれかの車両は、制御装置と、自動運転キットと、制御装置と自動運転キットとの間での信号のやり取りを仲介する車両制御インターフェースとを備えてもよい。自動運転キットは、自動運転のための指令を、車両制御インターフェースを介して制御装置へ送るように構成されてもよい。制御装置は、自動運転キットからの指令に従って車両を制御するように構成されてもよい。制御装置は、車両の状態を示す信号を、車両制御インターフェースを介して自動運転キットへ送るように構成されてもよい。

【0017】

上記のような自動運転キットが採用されることによって、ユーザごとのニーズに合った装備を有する車両を各ユーザに提供しやすくなる。また、車両制御インターフェースが存在することで、自動運転キットの着脱が容易になり、自動運転キットのメンテナンス（検査、修理、交換など）を行ないやすくなる。

【0018】

本開示の第３の観点に係るカーシェアリング方法は、次に示す第１提供処理、第２提供処理、及び決定処理を含む。

【0019】

第１提供処理では、コンピュータが第１ユーザに車両を提供する。第２提供処理では、第１ユーザが車両を使用した後、コンピュータが、第２ユーザに車両を提供する。決定処理では、車両で部品のメンテナンスが行なわれたときに、コンピュータが、そのメンテナンスにかかる費用のユーザごとの負担割合を、メンテナンスされた部品の種類とユーザごとの車両の使用態様とに基づいて決定する。

【0020】

上記カーシェアリング方法によっても、前述したコンピュータと同様、複数のユーザによって使用された１台の車両において部品のメンテナンスが行なわれたときに、そのメンテナンスにかかる費用のユーザごとの負担割合を公平に決めることが可能になる。

【発明の効果】

【0021】

本開示によれば、複数のユーザによって使用された１台の車両において部品のメンテナンスが行なわれたときに、そのメンテナンスにかかる費用のユーザごとの負担割合を公平に決めることが可能になる。

【図面の簡単な説明】

【0022】

【図1】本開示の実施の形態に係る車両の概略構成を示す図である。

【図2】図１に示した車両の構成の詳細を示す図である。

【図3】本開示の実施の形態に係る自動運転制御の処理手順を示すフローチャートである。

【図4】本開示の実施の形態に係る車両が備える各種部品について説明するための図である。

【図5】本開示の実施の形態に係る車両の外観を示す図である。

【図6】本開示の実施の形態に係るコンピュータの構成について説明するための図である。

【図7】本開示の実施の形態に係るカーシェアリング方法において、複数のユーザで共用される１台の車両をコンピュータが管理するために実行する処理を示すフローチャートである。

【図8】図７に示したメンテナンスに係る処理の詳細について説明するためのフローチャートである。

【図9】図６に示したユーザ情報及び費用負担情報の変形例を示す図である。

【図10】図８に示した処理の変形例を示すフローチャートである。

【発明を実施するための形態】

【0023】

以下、本開示の実施の形態について、図面を参照しながら詳細に説明する。なお、図中同一又は相当部分には同一符号を付してその説明は繰り返さない。

【0024】

図１は、本開示の実施の形態に係る車両の概略構成を示す図である。図１を参照して、車両１は、自動運転キット（以下、「ＡＤＫ（Autonomous Driving Kit）」と表記する）２００と、車両プラットフォーム（以下、「ＶＰ（Vehicle Platform）」と表記する）２とを備える。

【0025】

ＶＰ２は、ベース車両１００の制御システムと、ベース車両１００内に設けられた車両制御インターフェースボックス（以下、「ＶＣＩＢ（Vehicle Control Interface Box）」と表記する）１１１とを含む。ＶＣＩＢ１１１は、ＣＡＮ（Controller Area Network）のような車内ネットワークを通じてＡＤＫ２００と通信してもよい。なお、図１では、ベース車両１００とＡＤＫ２００とが離れた位置に示されているが、ＡＤＫ２００は、実際にはベース車両１００に取り付けられている。この実施の形態では、ベース車両１００のルーフトップにＡＤＫ２００が取り付けられる。ただし、ＡＤＫ２００の取り付け位置は適宜変更可能である。

【0026】

ベース車両１００は、たとえば市販されるｘＥＶ（電動車）である。ｘＥＶは、電力を動力源の全て又は一部として利用する車両である。この実施の形態では、ベース車両１００としてＢＥＶ（電気自動車）を採用する。ただしこれに限られず、ベース車両１００は、ＢＥＶ以外のｘＥＶ（ＨＥＶ、ＰＨＥＶ、ＦＣＥＶなど）であってもよい。ベース車両１００が備える車輪の数は、たとえば４輪である。ただしこれに限られず、ベース車両１００が備える車輪の数は、３輪であってもよいし、５輪以上であってもよい。

【0027】

ベース車両１００の制御システムは、統合制御マネージャ１１５に加えて、ベース車両１００を制御するための各種システムおよび各種センサを含む。統合制御マネージャ１１５は、ベース車両１００に含まれる各種センサからの信号（センサ検出信号）に基づいて、ベース車両１００の動作に関わる各種システムを統合して制御する。

【0028】

この実施の形態では、統合制御マネージャ１１５が制御装置１５０を含む。制御装置１５０は、プロセッサ１５１、ＲＡＭ（Random Access Memory）１５２、及び記憶装置１５３を含む。プロセッサ１５１としては、たとえばＣＰＵ（Central Processing Unit）を採用できる。ＲＡＭ１５２は、プロセッサ１５１によって処理されるデータを一時的に記憶する作業用メモリとして機能する。記憶装置１５３は、格納された情報を保存可能に構成される。記憶装置１５３は、たとえばＲＯＭ（Read Only Memory）及び書き換え可能な不揮発性メモリを含む。記憶装置１５３には、プログラムのほか、プログラムで使用される情報（たとえば、マップ、数式、及び各種パラメータ）が記憶されている。この実施の形態では、記憶装置１５３に記憶されているプログラムをプロセッサ１５１が実行することで、各種の車両制御（たとえば、ＡＤＫ２００からの指示に従う自動運転制御）が実行される。ただし、これらの処理は、ソフトウェアではなく、専用のハードウェア（電子回路）によって実行されてもよい。なお、制御装置１５０が備えるプロセッサの数は任意であり、所定の制御ごとにプロセッサが用意されてもよい。

【0029】

ベース車両１００は、ブレーキシステム１２１と、ステアリングシステム１２２と、パワートレーンシステム１２３と、アクティブセーフティシステム１２５と、ボディシステム１２６とを含む。これらのシステムは、統合制御マネージャ１１５によって統合制御される。この実施の形態では、各システムがコンピュータを備える。そして、システムごとのコンピュータが車内ネットワーク（たとえば、ＣＡＮ）を通じて統合制御マネージャ１１５と通信する。以下では、各システムが備えるコンピュータを、「ＥＣＵ（Electronic Control Unit）」と称する。

【0030】

ブレーキシステム１２１は、ベース車両１００の各車輪に設けられた制動装置と、制動装置を制御するＥＣＵとを含む。この実施の形態では、制動装置として油圧式ディスクブレーキ装置が採用される。ベース車両１００は、車輪速センサ１２７Ａ，１２７Ｂを備える。車輪速センサ１２７Ａは、ベース車両１００の前輪に設けられ、前輪の回転速度を検出する。車輪速センサ１２７Ｂは、ベース車両１００の後輪に設けられ、後輪の回転速度を検出する。ブレーキシステム１２１のＥＣＵは、車輪速センサ１２７Ａ，１２７Ｂで検出された各車輪の回転方向及び回転速度を統合制御マネージャ１１５へ出力する。

【0031】

ステアリングシステム１２２は、ベース車両１００の操舵装置と、操舵装置を制御するＥＣＵとを含む。操舵装置は、たとえば、アクチュエータにより操舵角の調整が可能なラック＆ピニオン式のＥＰＳ（Electric Power Steering）を含む。ベース車両１００は、ピニオン角センサ１２８を備える。ピニオン角センサ１２８は、操舵装置を構成するアクチュエータの回転軸に連結されたピニオンギヤの回転角（ピニオン角）を検出する。ステアリングシステム１２２のＥＣＵは、ピニオン角センサ１２８で検出されたピニオン角を統合制御マネージャ１１５へ出力する。

【0032】

パワートレーンシステム１２３は、ベース車両１００が備える車輪の少なくとも１つに設けられたＥＰＢ（Electric Parking Brake）と、ベース車両１００のトラッスミッションに設けられたＰ－Ｌｏｃｋ装置と、シフトレンジを選択可能に構成されるシフト装置と、ベース車両１００の駆動源と、パワートレーンシステム１２３に含まれる各装置を制御するＥＣＵとを含む。ＥＰＢは、前述の制動装置とは別に設けられ、電動アクチュエータによって車輪を固定状態にする。Ｐ－Ｌｏｃｋ装置は、たとえば、アクチュエータにより駆動可能なパーキングロックポールによってトランスミッションの出力軸の回転位置を固定状態にする。詳細は後述するが、この実施の形態では、ベース車両１００の駆動源として、蓄電装置から電力の供給を受けるモータを採用する。パワートレーンシステム１２３のＥＣＵは、ＥＰＢとＰ－Ｌｏｃｋ装置との各々による固定化の有無、シフト装置によって選択されたシフトレンジ、並びに蓄電装置及びモータ（後述する図４参照）の各々の状態を、統合制御マネージャ１１５へ出力する。

【0033】

アクティブセーフティシステム１２５は、走行中の車両１について衝突の可能性を判定するＥＣＵを含む。ベース車両１００は、車両１の前方及び後方を含む周辺状況を検出するカメラ１２９Ａ及びレーダセンサ１２９Ｂ，１２９Ｃを備える。アクティブセーフティシステム１２５のＥＣＵは、カメラ１２９Ａ及びレーダセンサ１２９Ｂ，１２９Ｃから受信した信号を用いて、衝突の可能性があるか否かを判定する。アクティブセーフティシステム１２５によって衝突の可能性があると判定された場合には、統合制御マネージャ１１５が、ブレーキシステム１２１に制動指令を出力して、車両１の制動力を増加させる。この実施の形態に係るベース車両１００が初期（出荷時）からアクティブセーフティシステム１２５を備える。しかしこれに限られず、ベース車両に対して後付け可能なアクティブセーフティシステムが採用されてもよい。

【0034】

ボディシステム１２６は、ボディ系部品（たとえば、方向指示器、ホーン、及びワイパー）と、ボディ系部品を制御するＥＣＵとを備える。ボディシステム１２６のＥＣＵは、マニュアルモードでは、ユーザ操作に従ってボディ系部品を制御し、自律モードでは、ＡＤＫ２００からＶＣＩＢ１１１及び統合制御マネージャ１１５を経て受信する指令に従ってボディ系部品を制御する。

【0035】

車両１は自動運転可能に構成される。ＶＣＩＢ１１１は、車両制御インターフェースとして機能する。車両１が自動運転で走行するときには、統合制御マネージャ１１５とＡＤＫ２００とがＶＣＩＢ１１１を介して相互に信号のやり取りを行ない、ＡＤＫ２００からの指令に従って統合制御マネージャ１１５が自律モード（Autonomous Mode）による走行制御（すなわち、自動運転制御）を実行する。なお、ＡＤＫ２００は、ベース車両１００から取り外すことも可能である。ベース車両１００は、ＡＤＫ２００が取り外された状態でも、ユーザの運転によりベース車両１００単体で走行することができる。ベース車両１００単体で走行する場合には、ベース車両１００の制御システムが、マニュアルモードによる走行制御（すなわち、ユーザ操作に応じた走行制御）を実行する。

【0036】

この実施の形態では、ＡＤＫ２００が、通信される各信号を定義するＡＰＩ（Application Program Interface）に従ってＶＣＩＢ１１１との間で信号のやり取りを行なう。ＡＤＫ２００は、上記ＡＰＩで定義された各種信号を処理するように構成される。ＡＤＫ２００は、たとえば、車両１の走行計画を作成し、作成された走行計画に従って車両１を走行させるための制御を要求する各種コマンドを、上記ＡＰＩに従ってＶＣＩＢ１１１へ出力する。以下、ＡＤＫ２００からＶＣＩＢ１１１へ出力される上記各種コマンドの各々を、「ＡＰＩコマンド」とも称する。また、ＡＤＫ２００は、ベース車両１００の状態を示す各種信号を上記ＡＰＩに従ってＶＣＩＢ１１１から受信し、受信したベース車両１００の状態を走行計画の作成に反映する。以下、ＡＤＫ２００がＶＣＩＢ１１１から受信する上記各種信号の各々を、「ＡＰＩシグナル」とも称する。ＡＰＩコマンド及びＡＰＩシグナルはどちらも、上記ＡＰＩで定義された信号に相当する。ＡＤＫ２００の構成の詳細については後述する（図２参照）。

【0037】

ＶＣＩＢ１１１は、ＡＤＫ２００から各種ＡＰＩコマンドを受信する。ＶＣＩＢ１１１は、ＡＤＫ２００からＡＰＩコマンドを受信すると、そのＡＰＩコマンドを、統合制御マネージャ１１５が処理可能な信号の形式に変換する。以下、統合制御マネージャ１１５が処理可能な信号の形式に変換されたＡＰＩコマンドを、「制御コマンド」とも称する。ＶＣＩＢ１１１は、ＡＤＫ２００からＡＰＩコマンドを受信すると、そのＡＰＩコマンドに対応する制御コマンドを統合制御マネージャ１１５へ出力する。

【0038】

統合制御マネージャ１１５の制御装置１５０は、ベース車両１００の制御システムにおいて検出されたベース車両１００の状態を示す各種信号（たとえば、センサ信号、又はステータス信号）を、ＶＣＩＢ１１１を介してＡＤＫ２００へ送る。ＶＣＩＢ１１１は、ベース車両１００の状態を示す信号を統合制御マネージャ１１５から逐次受信する。ＶＣＩＢ１１１は、統合制御マネージャ１１５から受信した信号に基づいてＡＰＩシグナルの値を決定する。また、ＶＣＩＢ１１１は、必要に応じて、統合制御マネージャ１１５から受信した信号をＡＰＩシグナルの形式に変換する。そして、ＶＣＩＢ１１１は、得られたＡＰＩシグナルをＡＤＫ２００へ出力する。ＶＣＩＢ１１１からＡＤＫ２００へは、ベース車両１００の状態を示すＡＰＩシグナルがリアルタイムで逐次出力される。

【0039】

この実施の形態において、統合制御マネージャ１１５とＶＣＩＢ１１１との間では、たとえば自動車メーカーによって定義された汎用性の低い信号がやり取りされ、ＡＤＫ２００とＶＣＩＢ１１１との間では、より汎用性の高い信号（たとえば、公開されたＡＰＩ（Ｏｐｅｎ ＡＰＩ）で定義された信号）がやり取りされる。ＶＣＩＢ１１１は、ＡＤＫ２００と統合制御マネージャ１１５との間で信号の変換を行なうことにより、ＡＤＫ２００からの指令に従って統合制御マネージャ１１５が車両制御を行なうことを可能にする。ただし、ＶＣＩＢ１１１の機能は、上記信号の変換を行なう機能のみには限定されない。たとえば、ＶＣＩＢ１１１は、所定の判断を行ない、その判断結果に基づく信号（たとえば、通知、指示、又は要求を行なう信号）を、統合制御マネージャ１１５とＡＤＫ２００との少なくとも一方へ送ってもよい。ＶＣＩＢ１１１の構成の詳細については後述する（図２参照）。

【0040】

ベース車両１００は、通信装置１３０をさらに備える。通信装置１３０は、各種通信Ｉ／Ｆ（インターフェース）を含む。制御装置１５０は、通信装置１３０を通じて車両１の外部の装置（たとえば、後述するモバイル端末ＵＴ１，ＵＴ２及びサーバ５００）と通信を行なうように構成される。通信装置１３０は、移動体通信網（テレマティクス）にアクセス可能な無線通信機（たとえば、ＤＣＭ（Data Communication Module））を含む。通信装置１３０は移動体通信網を介してサーバ５００と通信する。無線通信機は、５Ｇ（第５世代移動通信システム）対応の通信Ｉ／Ｆを含んでもよい。また、通信装置１３０は、車内又は車両周辺の範囲内に存在するモバイル端末ＵＴ１，ＵＴ２と直接通信するための通信Ｉ／Ｆを含む。通信装置１３０とモバイル端末ＵＴ１，ＵＴ２とは、無線ＬＡＮ（Local Area Network）、ＮＦＣ（Near Field Communication）、又はＢｌｕｅｔｏｏｔｈ（登録商標）のような近距離通信を行なってもよい。

【0041】

モバイル端末ＵＴ１、ＵＴ２は、それぞれ車両１の第１ユーザ、第２ユーザによって携帯される端末である。この実施の形態では、モバイル端末ＵＴ１及びＵＴ２の各々として、タッチパネルディスプレイを具備するスマートフォンを採用する。モバイル端末ＵＴ１及びＵＴ２の各々は、当該端末の現在位置を検出する位置センサを内蔵する。位置センサは、ＧＰＳ（Global Positioning System）を利用したセンサであってもよい。なお、モバイル端末ＵＴ１及びＵＴ２の各々としては、任意のモバイル端末を採用可能であり、ラップトップ、タブレット端末、ウェアラブルデバイス（たとえば、スマートウォッチ又はスマートグラス）、又は電子キーなども採用可能である。

【0042】

上述の車両１は、ＭａａＳ（Mobility as a Service）システムの構成要素の１つとして採用され得る。ＭａａＳシステムは、たとえばＭＳＰＦ（Mobility Service Platform）を含む。ＭＳＰＦは、各種モビリティサービス（たとえば、ライドシェア事業者、カーシェア事業者、保険会社、レンタカー事業者、タクシー事業者等により提供される各種モビリティサービス）が接続される統一プラットフォームである。サーバ５００は、ＭＳＰＦにおいてモビリティサービスのための情報の管理及び公開を行なうコンピュータである。サーバ５００は、各種モビリティの情報を管理し、事業者からの要求に応じて情報（たとえば、ＡＰＩ、及び、モビリティ間の連携に関する情報）を提供する。サービスを提供する事業者は、ＭＳＰＦ上で公開されたＡＰＩを用いて、ＭＳＰＦが提供する様々な機能を利用することができる。たとえば、ＡＤＫの開発に必要なＡＰＩは、ＭＳＰＦ上に公開されている。

【0043】

図２は、車両１の構成の詳細を示す図である。図１とともに図２を参照して、ＡＤＫ２００は、車両１の自動運転を行なうための自動運転システム（以下、「ＡＤＳ（Autonomous Driving System）」と表記する）２０２を含む。ＡＤＳ２０２は、コンピュータ２１０と、ＨＭＩ（Human Machine Interface）２３０と、認識用センサ２６０と、姿勢用センサ２７０と、センサクリーナ２９０とを含む。

【0044】

コンピュータ２１０は、プロセッサと、ＡＰＩを利用した自動運転ソフトウェアを記憶する記憶装置とを備え、プロセッサによって自動運転ソフトウェアを実行可能に構成される。自動運転ソフトウェアにより、自動運転に関する制御（後述する図３参照）が実行される。自動運転ソフトウェアは、ＯＴＡ（Over The Air）によって逐次更新されてもよい。コンピュータ２１０は、通信モジュール２１０Ａ及び２１０Ｂをさらに備える。

【0045】

ＨＭＩ２３０は、ユーザとコンピュータ２１０とが情報をやり取りするための装置である。ＨＭＩ２３０は、入力装置及び報知装置を含む。ユーザは、ＨＭＩ２３０を通じて、コンピュータ２１０に指示又は要求を行なったり、自動運転ソフトウェアで使用されるパラメータ（ただし、変更が許可されているものに限る）の値を変更したりすることができる。ＨＭＩ２３０は、入力装置及び報知装置の両方の機能を兼ね備えるタッチパネルディスプレイであってもよい。

【0046】

認識用センサ２６０は、車両１の外部環境を認識するための情報（以下、「環境情報」とも称する）を取得する各種センサを含む。認識用センサ２６０は、車両１の環境情報を取得し、コンピュータ２１０へ出力する。環境情報は、自動運転制御に用いられる。この実施の形態では、認識用センサ２６０が、車両１の周囲（前方及び後方を含む）を撮像するカメラと、電磁波又は音波によって障害物を検知する障害物検知器（たとえば、ミリ波レーダ及び／又はライダー）とを含む。コンピュータ２１０は、たとえば、認識用センサ２６０から受信する環境情報を用いて、車両１から認識可能な範囲に存在する人、物体（他の車両、柱、ガードレールなど）、及び道路上のライン（たとえば、センターライン）を認識できる。認識のために、人工知能（ＡＩ）又は画像処理用プロセッサが用いられてもよい。

【0047】

姿勢用センサ２７０は、車両１の姿勢に関する情報（以下、「姿勢情報」とも称する）を取得し、コンピュータ２１０へ出力する。姿勢用センサ２７０は、車両１の加速度、角速度、及び位置を検出する各種センサを含む。この実施の形態では、姿勢用センサ２７０が、ＩＭＵ（Inertial Measurement Unit）及びＧＰＳセンサを含む。ＩＭＵは、車両１の前後方向、左右方向、及び上下方向の各々の加速度、並びに車両１のロール方向、ピッチ方向、及びヨー方向の各々の角速度を検出する。ＧＰＳセンサは、複数のＧＰＳ衛星から受信する信号を用いて車両１の位置を検出する。自動車及び航空機の分野においてＩＭＵとＧＰＳとを組み合わせて高い精度で姿勢を計測する技術が公知である。コンピュータ２１０は、たとえば、こうした公知の技術を利用して、上記姿勢情報から車両１の姿勢を計測してもよい。

【0048】

センサクリーナ２９０は、車外で外気にさらされるセンサ（たとえば、認識用センサ２６０）の汚れを除去する装置である。たとえば、センサクリーナ２９０は、洗浄液及びワイパーを用いて、カメラのレンズ及び障害物検知器の出射口をクリーニングするように構成されてもよい。

【0049】

車両１においては、安全性を向上させるため、所定の機能（たとえば、ブレーキ、ステアリング、及び車両固定）に冗長性を持たせている。ベース車両１００の制御システム１０２は、同等の機能を実現するシステムを複数備える。具体的には、ブレーキシステム１２１はブレーキシステム１２１Ａ及び１２１Ｂを含む。ステアリングシステム１２２はステアリングシステム１２２Ａ及び１２２Ｂを含む。パワートレーンシステム１２３は、ＥＰＢシステム１２３ＡとＰ－Ｌｏｃｋシステム１２３Ｂとを含む。各システムがＥＣＵを備える。同等の機能を実現する複数のシステムのうち、一方に異常が生じても、他方が正常に動作することで、車両１において当該機能は正常に働く。

【0050】

ＶＣＩＢ１１１は、ＶＣＩＢ１１１ＡとＶＣＩＢ１１１Ｂとを含む。ＶＣＩＢ１１１Ａ及び１１１Ｂの各々はコンピュータを含む。コンピュータ２１０の通信モジュール２１０Ａ、２１０Ｂは、それぞれＶＣＩＢ１１１Ａ、１１１Ｂのコンピュータと通信可能に構成される。ＶＣＩＢ１１１とＶＣＩＢ１１１Ｂとは、相互に通信可能に接続されている。ＶＣＩＢ１１１Ａ及び１１１Ｂの各々は、単独で動作可能であり、一方に異常が生じても、他方が正常に動作することで、ＶＣＩＢ１１１は正常に動作する。ＶＣＩＢ１１１Ａ及び１１１Ｂはどちらも統合制御マネージャ１１５を介して上記各システムに接続されている。ただし、図２に示すように、ＶＣＩＢ１１１ＡとＶＣＩＢ１１１Ｂとでは接続先が一部異なっている。

【0051】

この実施の形態では、車両１を加速させる機能については、冗長性を持たせていない。パワートレーンシステム１２３は、車両１を加速させるためのシステムとして、推進システム１２３Ｃを含む。

【0052】

車両１は、自律モードとマニュアルモードとを切替え可能に構成される。ＡＤＫ２００がＶＣＩＢ１１１から受信するＡＰＩシグナルには、車両１が自律モードとマニュアルモードとのいずれの状態かを示す信号（以下、「自律ステート」と表記する）が含まれる。ユーザは、所定の入力装置（たとえば、ＨＭＩ２３０、又はモバイル端末ＵＴ１，ＵＴ２）を通じて、自律モードとマニュアルモードとのいずれかを選択できる。ユーザによっていずれかの運転モードが選択されると、選択された運転モードに車両１がなり、選択結果が自律ステートに反映される。ただし、車両１が自動運転可能な状態になっていなければ、ユーザが自律モードを選択しても自律モードに移行しない。車両１の運転モードの切替えは、統合制御マネージャ１１５によって行なわれてもよい。統合制御マネージャ１１５は、車両１の状況に応じて自律モードとマニュアルモードとを切り替えてもよい。

【0053】

車両１が自律モードであるときには、コンピュータ２１０が、ＶＰ２から車両１の状態を取得して、車両１の次の動作（たとえば、加速、減速、及び曲がる）を設定する。そして、コンピュータ２１０は、設定された車両１の次の動作を実現するための各種指令を出力する。コンピュータ２１０がＡＰＩソフトウェア（すなわち、ＡＰＩを利用した自動運転ソフトウェア）を実行することにより、自動運転制御に関する指令がＡＤＫ２００からＶＣＩＢ１１１を通じて統合制御マネージャ１１５へ送信される。

【0054】

図３は、この実施の形態に係る自動運転制御においてＡＤＫ２００が実行する処理を示すフローチャートである。このフローチャートに示される処理は、車両１が自律モードであるときに、ＡＰＩに対応する周期（ＡＰＩ周期）で繰り返し実行される。車両１の運転モードがマニュアルモードから自律モードに切り替わると、自動運転開始を示す開始信号が車両１の識別情報とともに車両１（通信装置１３０）からサーバ５００へ送信されるとともに、以下に説明する図３に示す一連の処理が開始される。以下では、フローチャート中の各ステップを、単に「Ｓ」と表記する。

【0055】

図１及び図２とともに図３を参照して、Ｓ１０１では、コンピュータ２１０が現在の車両１の情報を取得する。たとえば、コンピュータ２１０は、認識用センサ２６０及び姿勢用センサ２７０から車両１の環境情報及び姿勢情報を取得する。さらに、コンピュータ２１０はＡＰＩシグナルを取得する。この実施の形態では、車両１が自律モード及びマニュアルモードのいずれである場合にも、車両１の状態を示すＡＰＩシグナルがＶＣＩＢ１１１からＡＤＫ２００へリアルタイムで逐次出力されている。自動運転制御の精度を向上させるために、自律モードにおいてはマニュアルモードよりも短い周期で統合制御マネージャ１１５からＡＤＫ２００に向けて車両１の状態が逐次送信されてもよい。コンピュータ２１０が取得するＡＰＩシグナルには、前述の自律ステートのほか、車輪速センサ１２７Ａ，１２７Ｂで検出された各車輪の回転方向及び回転速度を示す信号などが含まれる。

【0056】

Ｓ１０２では、コンピュータ２１０が、Ｓ１０１で取得した車両１の情報に基づいて走行計画を作成する。たとえば、コンピュータ２１０が、車両１の挙動（たとえば、車両１の姿勢）を計算し、車両１の状態及び外部環境に適した走行計画を作成する。走行計画は、所定期間における車両１の挙動を示すデータである。すでに走行計画が存在する場合には、Ｓ１０２においてその走行計画が修正されてもよい。

【0057】

Ｓ１０３では、コンピュータ２１０が、Ｓ１０２で作成された走行計画から制御的な物理量（加速度、タイヤ切れ角など）を抽出する。Ｓ１０４では、コンピュータ２１０が、Ｓ１０３で抽出された物理量をＡＰＩ周期ごとに分割する。Ｓ１０５では、コンピュータ２１０が、Ｓ１０４で分割された物理量を用いてＡＰＩソフトウェアを実行する。このようにＡＰＩソフトウェアが実行されることにより、走行計画に従う物理量を実現するための制御を要求するＡＰＩコマンド（推進方向コマンド、推進コマンド、制動コマンド、車両固定コマンドなど）がＡＤＫ２００からＶＣＩＢ１１１へ送信される。ＶＣＩＢ１１１は、受信したＡＰＩコマンドに対応する制御コマンドを統合制御マネージャ１１５へ送信し、統合制御マネージャ１１５は、その制御コマンドに従って車両１の自動運転制御を行なう。自動運転中の車両１の状態は、コンピュータ２１０の記憶装置に逐次記録される。

【0058】

続くＳ１０６では、車両１が自律モードであるか否かを、コンピュータ２１０が判断する。自律モードが継続している間は（Ｓ１０６にてＹＥＳ）、上記Ｓ１０１～Ｓ１０５の処理が繰り返し実行されることにより、車両１の自動運転が実行される。他方、車両１がマニュアルモードになると（Ｓ１０６にてＮＯ）、Ｓ１０７において、自動運転終了を示す終了信号が車両１の識別情報とともに車両１（通信装置１３０）からサーバ５００へ送信された後、図３に示す一連の処理は終了する。この実施の形態では、コンピュータ２１０とＶＣＩＢ１１１と統合制御マネージャ１１５とが協働して車両１を自動運転で走行させるための制御を実行する。車両１は、有人／無人のいずれの状態においても自動運転を行なうことができる。なお、自動運転制御は、図３に示した制御に限られず、他の制御（公知の自動運転制御）が採用されてもよい。

【0059】

図４は、車両１が備える各種部品について説明するための図である。図１及び図２とともに図４を参照して、車両１は、バッテリ１６０とサスペンション１７０とをさらに備える。推進システム１２３Ｃは、ＭＧ（Motor Generator）２０と、ＥＣＵ２１と、ＰＣＵ（Power Control Unit）２２とを含む。バッテリ１６０は、推進システム１２３Ｃに電力を供給する。バッテリ１６０としては、公知の車両用蓄電装置（たとえば、液式二次電池、全固体二次電池、又は組電池）を採用できる。車両用二次電池の例としては、リチウムイオン電池、ニッケル水素電池が挙げられる。サスペンション１７０は、エアサスペンション装置であってもよい。

【0060】

バッテリ１６０には、監視モジュール１６０ａが設けられている。監視モジュール１６０ａは、バッテリ１６０の状態（たとえば、電圧、電流、及び温度）を検出する各種センサを含み、検出結果を統合制御マネージャ１１５へ出力する。監視モジュール１６０ａは、上記センサ機能に加えて、ＳＯＣ（State Of Charge）推定機能をさらに有するＢＭＳ（Battery Management System）であってもよい。制御装置１５０は、監視モジュール１６０ａの出力に基づいてバッテリ１６０の状態（たとえば、温度、電流、電圧、及びＳＯＣ）を取得することができる。ＳＯＣは、蓄電残量を示し、たとえば、満充電状態の蓄電量に対する現在の蓄電量の割合を０～１００％で表わしたものである。

【0061】

推進システム１２３Ｃは、バッテリ１６０に蓄えられた電力を用いて車両１の走行駆動力を発生させる。ＭＧ２０は、たとえば三相交流モータジェネレータである。ＰＣＵ２２は、たとえば、インバータと、コンバータと、リレー（以下、「ＳＭＲ（System Main Relay）」と称する）とを含む。ＰＣＵ２２は、ＥＣＵ２１によって制御される。ＳＭＲは、バッテリ１６０からＭＧ２０までの電路の接続／遮断を切り替えるように構成される。ＳＭＲは、車両１の走行時に閉状態（接続状態）にされる。

【0062】

ＭＧ２０は、ＰＣＵ２２によって駆動され、車両１の駆動輪Ｗを回転させる。また、ＭＧ２０は、回生発電を行ない、発電した電力をバッテリ１６０に供給する。ＰＣＵ２２は、バッテリ１６０から供給される電力を用いてＭＧ２０を駆動する。車両１が備える走行用のモータ（ＭＧ２０）の数は任意であり、１つでも２つでも３つ以上でもよい。走行用のモータはインホイールモータであってもよい。図４には、１つの駆動輪Ｗのみを模式的に示しているが、車両１における駆動輪Ｗの数及び駆動方式は任意である。車両１の駆動方式は、前輪駆動、後輪駆動、４輪駆動のいずれであってもよい。

【0063】

車両１が備える各車輪（駆動輪Ｗを含む）には、ブレーキシステム１２１（図１）に含まれる制動装置１８０と、制動装置１８０によって車輪に付与される制動力を検出するブレーキセンサ１８０ａとが設けられている。ブレーキセンサ１８０ａは、ブレーキパッド（又は、ホイールシリンダ）に加わる油圧を検出する油圧センサであってもよい。４つのブレーキセンサ１８０ａによってそれぞれ検出された車輪ごとの制動力（たとえば、制動力に対応する油圧）は統合制御マネージャ１１５へ出力される。

【0064】

図５は、車両１の外観を示す図である。図５を参照して、車両１は、内装品を変更することによってユーザの用途に合わせてカスタマイズ可能に構成される多目的車両である。こうした多目的車両によれば、ユーザごとのニーズに合った装備を有する車両を各ユーザに提供しやすくなる。この実施の形態では、車両１とサーバ５００とによってカーシェアリングシステムが構築される。第１ユーザと第２ユーザとで車両１がシェア（共用）される。

【0065】

この実施の形態に係る車両１は、移動オフィス用途（第１用途）と旅客輸送用途（第２用途）との各々にカスタマイズ可能に構成される。この実施の形態では、第１用途と第２用途との両方で使用される共通の内装品を、単に「共通の内装品」とも称する。また、第１用途と第２用途とのうち、第１用途のみで使用される用途別内装品を「第１用途内装品」、第２用途のみで使用される用途別内装品を「第２用途内装品」とも称する。

【0066】

第１使用期間においては、第１ユーザが移動オフィス用途（第１用途）で車両１を使用する。第１使用期間の後に設定された第２使用期間においては、第２ユーザが旅客輸送用途（第２用途）で車両１を使用する。第１使用期間と第２使用期間との少なくとも一方において車両１が自動運転を行なってもよい。車両１の自動運転中は、図３に示した処理が実行され、制御装置１５０がＡＤＫ２００からの指令に従って車両１の各種システム（たとえば、図２に示したブレーキシステム１２１、ステアリングシステム１２２、パワートレーンシステム１２３、アクティブセーフティシステム１２５、及びボディシステム１２６）を制御する。

【0067】

この実施の形態では、車両１が毎日使用される。車両１は朝から夜まで使用される。夜になると、その日の車両１の使用が終了し、車両１について部品チェックが行なわれる。部品チェックでは、所定の手順に従う客観的な検査によって車両１が所定の基準以上の性能を有しているか否かが、対象部品（検査項目）ごとに確認される。部品チェックでは、制御装置１５０が、車両１に搭載された各種センサの出力に基づいて対象部品ごとの良否を判断してもよい。あるいは、検査設備（テスター）を用いて部品チェックが行なわれてもよい。

【0068】

部品チェックでいずれの対象部品にも異常が発見されない場合には、ＥＶＳＥ（Electric Vehicle Supply Equipment）を用いて車両１のバッテリ１６０（蓄電装置）が充電される。この充電により、次の使用のための電力が車両１に蓄えられる。ＥＶＳＥの充電方式は、接触方式でも非接触方式でもよい。バッテリ１６０の充電は、車両１の使用終了後に開始され、使用日の翌日の朝までには完了する。朝になると、車両１の次の使用が開始される。

【0069】

この実施の形態では、１週間経過するたびに第１使用期間及び第２使用期間が再設定される。所定のカーシェアリング期間において第１ユーザと第２ユーザとが交互に車両１を使用する。カーシェアリング期間は、任意に設定（又は、更新）可能であり、１ヶ月であってもよいし、１年間であってもよい。

【0070】

使用期間の合間に、車両１を引き渡すための引渡し期間が設けられてもよい。たとえば、第１使用期間の終了から第２使用期間の開始までの間に、第１ユーザから第２ユーザへ車両１を引き渡すための第１引渡し期間が設けられてもよい。また、第２使用期間の終了から第１使用期間の開始までの間に、第２ユーザから第１ユーザへ車両１を引き渡すための第２引渡し期間が設けられてもよい。

【0071】

第１引渡し期間は、第１使用期間の最終日の夕方から第２使用期間の初日の昼までの少なくとも一部に設定されてもよい。第１引渡し期間においては、第２ユーザが指定した場所へ移動するための自動運転を車両１が実行してもよい。サーバ５００は、車両１の上記自動運転のための充電を第１引渡し期間の開始時刻までに完了させておくことを第１ユーザに要求する信号をモバイル端末ＵＴ１へ送信してもよい。

【0072】

第２引渡し期間は、第２使用期間の最終日の夕方から第１使用期間の初日の昼までの少なくとも一部に設定されてもよい。第２引渡し期間においては、第１ユーザが指定した場所へ移動するための自動運転を車両１が実行してもよい。サーバ５００は、車両１の上記自動運転のための充電を第２引渡し期間の開始時刻までに完了させておくことを第２ユーザに要求する信号をモバイル端末ＵＴ２へ送信してもよい。

【0073】

図６は、サーバ５００の構成について説明するための図である。図１及び図２とともに図６を参照して、サーバ５００は、プロセッサ５０１、ＲＡＭ５０２、記憶装置５０３、及びＨＭＩ５０４を含む。ＨＭＩ（Human Machine Interface）５０４は入力装置及び表示装置を含む。ＨＭＩ５０４は、タッチパネルディスプレイであってもよい。ＨＭＩ５０４は、音声入力を受け付けるスマートスピーカを含んでもよい。サーバ５００は、車両１及びモバイル端末ＵＴ１，ＵＴ２の各々と通信可能に構成される。車両１の姿勢用センサ２７０によって取得される位置情報（車両１の現在位置を示す情報）は、車両１からサーバ５００へ逐次送信される。また、モバイル端末ＵＴ１及びＵＴ２の各々の現在位置を示す情報も、各端末からサーバ５００へ逐次送信される。この実施の形態に係るサーバ５００は、本開示に係る「コンピュータ」の一例に相当する。

【0074】

記憶装置５０３は、格納された情報を保存可能に構成される。記憶装置５０３には、第１ユーザ及び第２ユーザの各々に関する情報と、車両１に関する情報とが記憶されている。たとえば、車両１及びモバイル端末ＵＴ１，ＵＴ２の各々からサーバ５００が受信した情報（たとえば、位置情報）は、記憶装置５０３に保存される。さらに、記憶装置５０３には、プログラムと、プログラムで使用される情報（たとえば、マップ、数式、及び各種パラメータ）とが記憶されている。この実施の形態では、記憶装置５０３に記憶されているプログラムをプロセッサ５０１が実行することで、後述する車両管理に係る処理（図７参照）が実行される。ただし、こうした処理は、ソフトウェアではなく、専用のハードウェア（電子回路）によって実行されてもよい。

【0075】

サーバ５００は、ユーザに関する情報（以下、「ユーザ情報」と表記する）と、費用に関する情報（以下、「費用負担情報」と表記する）とを管理する。ユーザ情報及び費用負担情報は、記憶装置５０３に記憶されている。

【0076】

ユーザ情報は、図６中の表Ｔ１によって示される。ユーザ情報では、各ユーザの情報が、ユーザを識別するための識別情報（ユーザＩＤ）によって区別されている。表Ｔ１において、「Ｕ－１」、「Ｕ－２」は、それぞれ第１ユーザ、第２ユーザのユーザＩＤに相当する。ユーザ情報は、第１ユーザ及び第２ユーザの各々に関して、車両１の使用期間（すなわち、前述した第１使用期間及び第２使用期間）と、車両１の用途（すなわち、前述した第１用途及び第２用途）とを示す。この実施の形態では、第１用途、第２用途が、それぞれ移動オフィス用途、旅客輸送用途である。また、第１使用期間が平日（月～金曜日）であり、第２使用期間が週末（土・日曜日）である。第１ユーザによる車両１の使用時間は５日／週であり、第２ユーザによる車両１の使用時間は２日／週である。このように、ユーザごとの車両１の使用時間は、ユーザ情報によって示される。この実施の形態では、単位期間を１週間にしているが、単位期間は任意である。

【0077】

この実施の形態では、費用負担情報が、以下に説明するような、複数の部品区分と複数の用途区分と費用負担割合との関係を示す。費用負担情報は、図６中の表Ｔ２によって示される。

【0078】

費用負担情報によって規定される複数の部品区分は、共通の内装品に関する第１部品区分と、駆動系の部品に関する第２部品区分と、サスペンション１７０に関する第３部品区分と、バッテリ１６０に関する第４部品区分と、第１用途内装品に関する第５部品区分と、第２用途内装品に関する第６部品区分とを含む。

【0079】

駆動系の部品には、車両１を走行させるための各種部品が含まれる。車両１に動力を与える部品（たとえば、ＭＧ２０）だけでなく、車両１の走行を制御する部品も、駆動系の部品に含まれる。たとえば、ＡＤＫ２００、ブレーキシステム１２１、ステアリングシステム１２２、及び推進システム１２３Ｃの各々に含まれる部品は、駆動系の部品に該当する。第１用途内装品は、たとえばオフィス用品である。第２用途内装品は、たとえば旅客輸送用シートである。

【0080】

費用負担情報によって規定される複数の用途区分は、オフィス用途に関する第１用途区分と、旅客輸送用途に関する第２用途区分とを含む。すなわち、第１ユーザの用途（第１用途）は第１用途区分に属し、第２ユーザの用途（第２用途）は第２用途区分に属する。

【0081】

費用負担情報が示す費用負担割合は、部品メンテナンスにかかる費用の各ユーザの負担割合である。部品メンテナンスの例としては、部品の修理又は交換が挙げられる。この実施の形態では、費用負担情報が、オフィス用途のユーザ（第１ユーザ）と旅客輸送用途のユーザ（第２ユーザ）との費用負担割合を示す。具体的には、費用負担情報によって示される費用負担割合（第１ユーザ：第２ユーザ）は、図６中の表Ｔ２が示すように、第１部品区分について「５：５」、第２部品区分について「２：８」、第３部品区分について「３：７」、第４部品区分について「７：３」、第５部品区分について「１０：０」、第６部品区分について「０：１０」である。

【0082】

上記費用負担割合は、部品の劣化傾向に応じて定められている。たとえば、旅客輸送用途とオフィス用途とを比較すると、駆動系の部品及びサスペンション関連部品の各々は旅客輸送用途のほうが劣化しやすく、蓄電装置の部品はオフィス用途のほうが劣化しやすい傾向がある。用途別内装品については対応する用途のみで使用されるため、用途別内装品のメンテナンスにかかる費用は、対応する用途で車両１を使用したユーザの全額負担となる。

【0083】

サーバ５００は、複数のユーザによって使用された１台の車両で部品のメンテナンスが行なわれたときに、そのメンテナンスにかかる費用のユーザごとの負担割合を、メンテナンスされた部品の種類とユーザごとの車両の使用態様とに基づいて決定するように構成される。

【0084】

具体的には、サーバ５００（より特定的には、プロセッサ５０１）は、上記費用負担情報（図６中の表Ｔ２）を参照して、第１～第６部品区分のうち、メンテナンスされた部品の種類が属する部品区分と、第１～第２用途区分のうち、第１ユーザの車両１の用途が属する用途区分（第１用途区分）と、第２ユーザの車両１の用途が属する用途区分（第２用途区分）とから、各ユーザの費用負担割合を取得し、取得された各ユーザの費用負担割合を用いて、部品メンテナンスにかかる費用のユーザごとの負担割合を決定する。

【0085】

この実施の形態では、サーバ５００（より特定的には、プロセッサ５０１）が、上記費用負担情報によって示される各ユーザの費用負担割合（以下、「第１割合」とも称する）に加えて、前述のユーザ情報（図６中の表Ｔ１）によって示される各ユーザの車両１の使用時間をさらに用いて、部品メンテナンスにかかる費用のユーザごとの負担割合を決定する。ユーザ情報は、第１ユーザと第２ユーザとの使用時間の割合（以下、「第２割合」とも称する）を示す。この実施の形態では、第２割合（第１ユーザ：第２ユーザ）が５：２である。サーバ５００は、第１割合と第２割合とに基づいて、第１ユーザ及び第２ユーザの各々の負担割合を決定する。サーバ５００は、車両１の使用時間が長いユーザの負担割合を大きくする。

【0086】

図７は、第１ユーザと第２ユーザとでシェア（共用）される車両１をサーバ５００が管理するために実行する処理を示すフローチャートである。このフローチャートに示される処理は、第１ユーザ及び第２ユーザによるカーシェアリング期間において繰り返し実行される。

【0087】

図１～図６とともに図７を参照して、Ｓ１１では、現在時刻が第１使用期間内か否かを、サーバ５００が判断する。現在時刻が第１使用期間内である場合には（Ｓ１１にてＹＥＳ）、処理がＳ１２に進む。Ｓ１２では、サーバ５００が、車両１の使用状況を取得し、第１ユーザによって車両１が使用されているか否かを判断する。

【0088】

この実施の形態では、サーバ５００が、車両１の現在位置と、モバイル端末ＵＴ１の現在位置と、モバイル端末ＵＴ２の現在位置との少なくとも１つを用いて、車両１の使用状況を取得する。たとえば、車両１がモバイル端末ＵＴ１の現在位置の周辺に存在する場合には、サーバ５００は、第１ユーザによって車両１が使用されていると判断する。また、車両１がモバイル端末ＵＴ２の現在位置の周辺に存在する場合には、サーバ５００は、第２ユーザによって車両１が使用されていると判断する。そして、いずれのモバイル端末の周辺にも車両１が存在しない場合には、車両１は不使用状態である（車両１はいずれのユーザにも使用されていない）とサーバ５００が判断する。

【0089】

なお、車両１の使用状況の判断方法は、上記に限られず適宜変更可能である。たとえば、車両１が第１ユーザの使用エリア内（たとえば、第１ユーザの自宅又は職場の周辺）に存在する場合に、第１ユーザによって車両１が使用されているとサーバ５００が判断してもよい。また、車両１が第２ユーザの使用エリア内（たとえば、第２ユーザの自宅又は職場の周辺）に存在する場合に、第２ユーザによって車両１が使用されているとサーバ５００が判断してもよい。そして、車両１が各ユーザの使用エリア外に存在する場合に、車両１は不使用状態であるとサーバ５００が判断してもよい。

【0090】

第１ユーザによって車両１が使用されている場合には（Ｓ１２にてＹＥＳ）、サーバ５００が、Ｓ１３において、第１使用期間の終了時刻が近いか否かを判断する。第１使用期間の終了時刻は、第１使用期間の最終日の夕方（たとえば、１７時）であってもよい。サーバ５００は、Ｓ１３において、第１使用期間の最終日の所定時刻を過ぎたか否かを判断してもよい。所定時刻は、第１使用期間の終了時刻から所定時間さかのぼった時刻（たとえば、１６時）であってもよい。他方、車両１が不使用状態である場合、又は第２ユーザによって車両１が使用されている場合には、Ｓ１２においてＮＯと判断される。Ｓ１２にてＮＯ又はＳ１３にてＹＥＳと判断された場合には、処理がＳ１４に進む。

【0091】

Ｓ１４では、サーバ５００が第１ユーザに通知する。サーバ５００は、たとえばモバイル端末ＵＴ１に対して通知を行なう。第１ユーザによって車両１が使用されており（Ｓ１２にてＹＥＳ）、かつ、第１使用期間の終了時刻が近い場合には（Ｓ１３にてＹＥＳ）、サーバ５００は、Ｓ１４の通知により、車両１を第２ユーザへ引き渡す準備を行なうことを第１ユーザに要求する。車両１が不使用状態である場合には、サーバ５００は、Ｓ１４の通知により、車両１の使用を第１ユーザに促す。第２ユーザによって車両１が使用されている場合には（後述するＳ２５にてＹＥＳ）、サーバ５００は、Ｓ１４の通知により、車両１の使用状況を第１ユーザに知らせる。後述するＳ２６の処理によりモバイル端末ＵＴ２から第２ユーザの状況を受信した場合には、サーバ５００は、Ｓ１４の通知により、第２ユーザの状況を第１ユーザに知らせる。

【0092】

上記Ｓ１４の処理が実行されると、処理はＳ２１に進む。また、第１ユーザによって車両１が使用されており（Ｓ１２にてＹＥＳ）、かつ、第１使用期間の終了時刻まで時間的に余裕がある場合には（Ｓ１３にてＮＯ）、第１ユーザに対する通知（Ｓ１４）が行なわれることなく、処理がＳ２１に進む。

【0093】

現在時刻が第１使用期間外である場合には（Ｓ１１にてＮＯ）、処理がＳ１５に進む。Ｓ１５では、Ｓ１２と同様に、サーバ５００が、車両１の使用状況を取得し、第１ユーザによって車両１が使用されているか否かを判断する。そして、第１ユーザによって車両１が使用されている場合には（Ｓ１５にてＹＥＳ）、処理がＳ１６に進む。

【0094】

Ｓ１６では、サーバ５００が第１ユーザに通知する。サーバ５００は、たとえばモバイル端末ＵＴ１に対して通知を行なう。サーバ５００は、Ｓ１６の通知により、車両１を第２ユーザへ引き渡すことを第１ユーザに要求する。また、サーバ５００は、Ｓ１６の通知により、車両１及び第１ユーザの各々の状況を返信することを第１ユーザに要求する。

【0095】

上記Ｓ１６の処理が実行されると、処理はＳ２１に進む。また、現在時刻が第１使用期間外であり（Ｓ１１にてＮＯ）、かつ、第１ユーザによって車両１が使用されていない場合には（Ｓ１５にてＮＯ）、第１ユーザに対する通知（Ｓ１６）が行なわれることなく、処理がＳ２１に進む。

【0096】

Ｓ２１では、現在時刻が第２使用期間内か否かを、サーバ５００が判断する。現在時刻が第２使用期間内である場合には（Ｓ２１にてＹＥＳ）、処理がＳ２２に進む。Ｓ２２では、サーバ５００が、車両１の使用状況を取得し、第２ユーザによって車両１が使用されているか否かを判断する。

【0097】

第２ユーザによって車両１が使用されている場合には（Ｓ２２にてＹＥＳ）、サーバ５００が、Ｓ２３において、第２使用期間の終了時刻が近いか否かを判断する。第２使用期間の終了時刻は、第２使用期間の最終日の夕方（たとえば、１７時）であってもよい。サーバ５００は、Ｓ２３において、第２使用期間の最終日の所定時刻を過ぎたか否かを判断してもよい。所定時刻は、第２使用期間の終了時刻から所定時間さかのぼった時刻（たとえば、１６時）であってもよい。他方、車両１が不使用状態である場合、又は第１ユーザによって車両１が使用されている場合には、Ｓ２２においてＮＯと判断される。Ｓ２２にてＮＯ又はＳ２３にてＹＥＳと判断された場合には、処理がＳ２４に進む。

【0098】

Ｓ２４では、サーバ５００が第２ユーザに通知する。サーバ５００は、たとえばモバイル端末ＵＴ２に対して通知を行なう。第２ユーザによって車両１が使用されており（Ｓ２２にてＹＥＳ）、かつ、第２使用期間の終了時刻が近い場合には（Ｓ２３にてＹＥＳ）、サーバ５００は、Ｓ２４の通知により、車両１を第１ユーザへ引き渡す準備を行なうことを第２ユーザに要求する。車両１が不使用状態である場合には、サーバ５００は、Ｓ２４の通知により、車両１の使用を第２ユーザに促す。第１ユーザによって車両１が使用されている場合には（Ｓ１５にてＹＥＳ）、サーバ５００は、Ｓ２４の通知により、車両１の使用状況を第２ユーザに知らせる。Ｓ１６の処理によりモバイル端末ＵＴ１から第１ユーザの状況を受信した場合には、サーバ５００は、Ｓ２４の通知により、第１ユーザの状況を第２ユーザに知らせる。

【0099】

上記Ｓ２４の処理が実行されると、処理はＳ３１に進む。また、第２ユーザによって車両１が使用されており（Ｓ２２にてＹＥＳ）、かつ、第２使用期間の終了時刻まで時間的に余裕がある場合には（Ｓ２３にてＮＯ）、第２ユーザに対する通知（Ｓ２４）が行なわれることなく、処理がＳ３１に進む。

【0100】

現在時刻が第２使用期間外である場合には（Ｓ２１にてＮＯ）、処理がＳ２５に進む。Ｓ２５では、Ｓ２２と同様に、サーバ５００が、車両１の使用状況を取得し、第２ユーザによって車両１が使用されているか否かを判断する。そして、第２ユーザによって車両１が使用されている場合には（Ｓ２５にてＹＥＳ）、処理がＳ２６に進む。

【0101】

Ｓ２６では、サーバ５００が第２ユーザに通知する。サーバ５００は、たとえばモバイル端末ＵＴ２に対して通知を行なう。サーバ５００は、Ｓ２６の通知により、車両１を第１ユーザへ引き渡すことを第２ユーザに要求する。また、サーバ５００は、Ｓ２６の通知により、車両１及び第２ユーザの各々の状況を返信することを第２ユーザに要求する。

【0102】

上記Ｓ２６の処理が実行されると、処理はＳ３１に進む。また、現在時刻が第２使用期間外であり（Ｓ２１にてＮＯ）、かつ、第２ユーザによって車両１が使用されていない場合には（Ｓ２５にてＮＯ）、第２ユーザに対する通知（Ｓ２６）が行なわれることなく、処理がＳ３１に進む。

【0103】

Ｓ３１では、車両１のメンテナンスの要否を、サーバ５００が判断する。この実施の形態では、前述した車両１の使用後（たとえば、夜）に行なわれる部品チェックで、いずれかの部品に異常が発見された場合には、Ｓ３１においてＹＥＳと判断され、いずれの部品にも異常が発見されない場合には、Ｓ３１においてＮＯと判断される。

【0104】

車両１のメンテナンスが必要と判断された場合には（Ｓ３１にてＹＥＳ）、サーバ５００が、Ｓ３２において、車両１のメンテナンスに係る処理を実行する。他方、車両１のメンテナンスが不要と判断された場合には（Ｓ３１にてＮＯ）には、車両メンテナンス（Ｓ３２）が行なわれることなく、図７に示す一連の処理は終了し、処理は最初のステップ（Ｓ１１）に戻る。

【0105】

Ｓ３２においては、以下に説明する図８に示す一連の処理が実行される。図８は、サーバ５００によって実行される車両１のメンテナンスに係る処理の詳細について説明するためのフローチャートである。

【0106】

図１～図６とともに図８を参照して、Ｓ２０１では、異常が発見された車両１の部品（図７のＳ３１参照）について、サーバ５００がメンテナンスの依頼と報知を行なう。

【0107】

具体的には、サーバ５００は、Ｓ２０１において、異常が発見された車両１の部品のメンテナンス（たとえば、修理又は交換）を依頼する信号（以下、「依頼信号」とも称する）を送信する。サーバ５００は、メンテナンス業者の端末へ依頼信号を送信してもよい。サーバ５００は、車両１を使用中のユーザが携帯するモバイル端末ＵＴ１又はＵＴ２へ依頼信号を送信してもよい。そして、車両１を使用中のユーザがメンテナンス業者にメンテナンスを依頼してもよい。

【0108】

また、サーバ５００は、Ｓ２０１において、車両１のメンテナンスを行なう旨を報知する報知処理を所定の報知装置（たとえば、ＨＭＩ２３０）に実行させる。サーバ５００は、モバイル端末ＵＴ１及びＵＴ２の各々に上記報知処理を実行させてもよい。

【0109】

続くＳ２０２では、Ｓ２０１で依頼したメンテナンスが完了したか否かを、サーバ５００が判断する。そして、メンテナンスが完了するまで（Ｓ２０２にてＮＯ）、サーバ５００は待機する。待機中、サーバ５００は、メンテナンスの結果（履歴）の入力を受け付けてもよい。サーバ５００は、メンテナンスの結果がサーバ５００に入力されたか否かに基づいて、メンテナンスが完了したか否かを判断してもよい。メンテナンスが完了した場合には（Ｓ２０２にてＹＥＳ）、サーバ５００が、Ｓ２０３において、メンテナンスの履歴（たとえば、メンテナンスの日時、メンテナンスされた部品、及びメンテナンスの内容）を記憶装置５０３に記録する。メンテナンス業者がＨＭＩ５０４を通じてサーバ５００にメンテナンスの結果（履歴）を入力してもよい。

【0110】

続くＳ２０４では、上記メンテナンスにかかった費用（メンテナンス費用）を、サーバ５００が取得する。サーバ５００は、メンテナンス業者の端末からメンテナンス費用を受信してもよい。あるいは、サーバ５００は、所定の料金表に基づいてメンテナンス費用を求めてもよい。料金表は予め記憶装置５０３に記憶されてもよい。

【0111】

続くＳ２０５では、サーバ５００が、図６中の表Ｔ２が示す第１～第６部品区分のうち、メンテナンスされた部品（たとえば、修理又は交換された部品）の種類が属する部品区分（メンテナンス部品区分）を取得する。

【0112】

続くＳ２０６では、サーバ５００が、各ユーザの車両１の用途が属する用途区分を取得する。この実施の形態では、第１ユーザの用途区分（第１ユーザ用途区分）として第１用途区分が取得され、第２ユーザの用途区分（第２ユーザ用途区分）として第２用途区分が取得される。

【0113】

続くＳ２０７では、サーバ５００が、Ｓ２０５で取得されたメンテナンス部品区分と、Ｓ２０６で取得された各ユーザの用途区分と、図６中の表Ｔ１が示すユーザ情報と、図６中の表Ｔ２が示す費用負担情報とを用いて、メンテナンス費用のユーザごとの負担割合を決定する。具体的には、サーバ５００は、Ｓ２０５で取得されたメンテナンス部品区分と、Ｓ２０６で取得された第１及び第２ユーザ用途区分とから、第１割合（費用負担情報によって示される各ユーザの費用負担割合）を取得する。たとえば、Ｓ２０５で取得されたメンテナンス部品区分が第２部品区分である場合には、サーバ５００は、第１割合（第１ユーザ：第２ユーザ）として「２：８」を取得する。また、サーバ５００は、ユーザ情報が示す第２割合（第１ユーザ：第２ユーザ）として「５：２」を取得する。そして、サーバ５００は、第１割合と第２割合とを乗算することにより、「１０：１６（＝５：８）」という割合を得る。サーバ５００は、この算出結果（割合「５：８」）を、最終的な費用負担割合（第１ユーザ：第２ユーザ）として決定する。

【0114】

続くＳ２０８では、サーバ５００が、Ｓ２０７で決定された各ユーザの費用負担割合に基づいて、第１ユーザと第２ユーザとの少なくとも一方に対してメンテナンス費用の請求を行なう。サーバ５００は、たとえばモバイル端末ＵＴ１及びＵＴ２の少なくとも一方に対して費用請求の通知を行なう。たとえば、Ｓ２０４で取得されたメンテナンス費用が１３万円であり、Ｓ２０７で決定された費用負担割合（第１ユーザ：第２ユーザ）が「５：８」である場合には、サーバ５００は、モバイル端末ＵＴ１に対する上記通知により、第１ユーザに対して５万円を請求し、モバイル端末ＵＴ２に対する上記通知により、第２ユーザに対して８万円を請求する。各ユーザは、キャッシュレス決済の案内に従ってモバイル端末ＵＴ１又はＵＴ２を操作することによって、キャッシュレス決済によりメンテナンス費用の支払いを行なってもよい。なお、メンテナンスされた部品が用途別内装品である場合には、サーバ５００は、第１ユーザ又は第２ユーザの一方のみに対してメンテナンス費用の請求を行なう。

【0115】

上記Ｓ２０８の処理が実行されると、図８に示す一連の処理は終了する。そして、処理は、図７の最初のステップ（Ｓ１１）に戻る。

【0116】

以上説明したように、この実施の形態に係るカーシェアリング方法は、図７及び図８の各々に示した処理を含む。

【0117】

図７に示した処理では、サーバ５００が、第１ユーザに車両１を提供するための第１提供処理を実行する（Ｓ１１～Ｓ１４、Ｓ２１、Ｓ２５、及びＳ２６）。また、第１ユーザが車両１を使用した後、サーバ５００が、第２ユーザに車両１を提供するための第２提供処理を実行する（Ｓ２１～Ｓ２４、Ｓ１１、Ｓ１５、及びＳ１６）。

【0118】

上記第１提供処理は、第１使用期間内において第１ユーザが車両１を使用していない場合に（Ｓ１１にてＹＥＳかつＳ１２にてＮＯ）、サーバ５００が車両１の使用を第１ユーザに促すこと（Ｓ１４）と、第１使用期間内において第２ユーザが車両１を使用している場合に（Ｓ２１にてＮＯかつＳ２５にてＹＥＳ）、サーバ５００が、車両１を第１ユーザへ引き渡すことを第２ユーザに要求すること（Ｓ２６）とを含む。

【0119】

上記第２提供処理は、第１使用期間の後に設定された第２使用期間内において第２ユーザが車両１を使用していない場合に（Ｓ２１にてＹＥＳかつＳ２２にてＮＯ）、サーバ５００が車両１の使用を第２ユーザに促すこと（Ｓ２４）と、第２使用期間内において第１ユーザが車両１を使用している場合に（Ｓ１１にてＮＯかつＳ１５にてＹＥＳ）、サーバ５００が、車両１を第２ユーザへ引き渡すことを第１ユーザに要求すること（Ｓ１６）とを含む。

【0120】

図８に示した処理では、車両１で部品のメンテナンスが行なわれたときに、サーバ５００が、そのメンテナンスにかかる費用のユーザごとの負担割合を、メンテナンスされた部品の種類とユーザごとの車両１の使用態様とに基づいて決定するための処理（決定処理）を実行する（Ｓ２０５～Ｓ２０７）。

【0121】

上記決定処理は、サーバ５００が、費用負担情報（図６）が示す複数の部品区分のうちメンテナンスされた部品の種類が属するメンテナンス部品区分を取得すること（Ｓ２０５）と、サーバ５００が、費用負担情報（図６）が示す複数の用途区分のうち第１ユーザの車両１の用途が属する第１ユーザ用途区分を取得すること（Ｓ２０６）と、サーバ５００が、費用負担情報（図６）が示す複数の用途区分のうち第２ユーザの車両１の用途が属する第２ユーザ用途区分を取得すること（Ｓ２０６）と、サーバ５００が、取得されたメンテナンス部品区分、第１ユーザ用途区分、及び第２ユーザ用途区分を用いて、第１ユーザと第２ユーザとの費用負担割合を取得すること（Ｓ２０７）と、サーバ５００が、取得された費用負担割合を用いて、メンテナンスにかかる費用のユーザごとの負担割合を決定すること（Ｓ２０７）とを含む。

【0122】

上記のカーシェアリング方法によれば、複数のユーザで共用される１台の車両において部品のメンテナンスが行なわれたときに、ユーザごとの費用負担割合を公平に決めることが可能になる。

【0123】

上記実施の形態では、２人のユーザによって１台の車両が共用されている。しかしこれに限られず、カーシェアリングにおけるユーザの人数は適宜変更可能であり、３人以上であってもよい。上記実施の形態におけるユーザ情報及び費用負担情報の各々は、カーシェアリングの形態に合わせて変更されてもよい。図９は、図６に示したユーザ情報及び費用負担情報の変形例を示す図である。

【0124】

この変形例に係るユーザ情報は、図９中の表Ｔ３によって示される。表Ｔ３において、「Ｕ－１」、「Ｕ－２」、「Ｕ－３」、「Ｕ－４」は、それぞれ第１ユーザ、第２ユーザ、第３ユーザ、第４ユーザのユーザＩＤに相当する。ユーザ情報は、第１～第４ユーザの各々に関して、車両１の使用期間（第１～第４使用期間）と、車両１の用途（第１～第４用途）とを示す。この実施の形態では、第１用途、第２用途、第３用途、第４用途が、それぞれ移動オフィス用途、旅客輸送用途、物流用途、医療用途である。また、第１使用期間が月曜日、第２使用期間が火・水曜日、第３使用期間が木・金曜日、第４使用期間が週末（土・日曜日）である。第１ユーザによる車両１の使用時間は１日／週、第２ユーザによる車両１の使用時間は２日／週、第３ユーザによる車両１の使用時間は２日／週、第４ユーザによる車両１の使用時間は２日／週である。このように、ユーザごとの車両１の使用時間は、ユーザ情報によって示される。

【0125】

この変形例に係る費用負担情報は、図９中の表Ｔ４によって示される。費用負担情報によって規定される複数の部品区分は、共通の内装品に関する第１部品区分と、駆動系の部品に関する第２部品区分と、サスペンション１７０に関する第３部品区分と、バッテリ１６０に関する第４部品区分と、第１用途内装品に関する第５部品区分と、第２用途内装品に関する第６部品区分と、第３用途内装品に関する第７部品区分と、第４用途内装品に関する第８部品区分とを含む。なお、共通の内装品は、第１～第４用途の全てで使用される内装品である。

【0126】

費用負担情報によって規定される複数の用途区分は、オフィス用途に関する第１用途区分と、旅客輸送用途に関する第２用途区分と、物流用途に関する第３用途区分と、医療用途に関する第４用途区分とを含む。すなわち、第１ユーザの用途（第１用途）は第１用途区分に属し、第２ユーザの用途（第２用途）は第２用途区分に属し、第３ユーザの用途（第３用途）は第３用途区分に属し、第４ユーザの用途（第４用途）は第４用途区分に属する。

【0127】

この変形例では、費用負担情報が、オフィス用途のユーザ（第１ユーザ）と旅客輸送用途のユーザ（第２ユーザ）と物流用途のユーザ（第３ユーザ）と医療用途のユーザ（第４ユーザ）との費用負担割合を示す。この費用負担割合は、図９中の表Ｔ４に示されるように、部品の劣化傾向に応じて定められている。たとえば、旅客輸送用途と物流用途とを比較すると、内装品と駆動系の部品とサスペンション関連部品と蓄電装置の部品とのいずれも物流用途のほうが劣化しやすい傾向がある。旅客輸送用途と医療用途とを比較すると、駆動系の部品及びサスペンション関連部品の各々は旅客輸送用途のほうが劣化しやすく、蓄電装置の部品は医療用途のほうが劣化しやすい傾向がある。オフィス用途と医療用途とを比較すると、駆動系の部品とサスペンション関連部品と蓄電装置の部品とのいずれも医療用途のほうが劣化しやすい傾向がある。用途別内装品のメンテナンスにかかる費用は、対応する用途で車両１を使用したユーザの全額負担となる。

【0128】

上記変形例に係るユーザ情報及び費用負担情報によれば、第１～第４ユーザで共用される１台の車両において部品のメンテナンスが行なわれたときに、第１～第４ユーザの費用負担割合を公平に決めることが可能になる。

【0129】

上記実施の形態では、決定処理（メンテナンスにかかる費用のユーザごとの負担割合を決定する処理）において、各ユーザの車両１の使用態様（より特定的には、用途）を、費用負担情報（図６）が示すいずれかの用途区分に分類している。しかし、決定処理において費用負担情報を用いることは必須ではない。たとえば、サーバ５００は、図８に示した処理に代えて、以下に説明する図１０に示す一連の処理を実行してもよい。

【0130】

図１０は、図８に示した処理の変形例を示すフローチャートである。図１０に示す処理は、Ｓ２０５～Ｓ２０７（図８）に代えてＳ２０７Ａが採用されたこと以外は、図８に示した処理に準ずる。以下、Ｓ２０７Ａについて説明する。

【0131】

図１～図６とともに図１０を参照して、Ｓ２０７Ａでは、サーバ５００が、各ユーザの車両１の使用態様に基づいて、メンテナンスにかかる費用のユーザごとの負担割合を決定する。具体的には、サーバ５００は、第１ユーザと第２ユーザとの各々の車両１の使用態様について、メンテナンスされた部品をどの程度劣化させるものであったかを評価する。そして、サーバ５００は、メンテナンスされた部品を劣化させやすい態様で車両１を使用したユーザ（すなわち、メンテナンスされた部品を劣化させた程度が大きいユーザ）の費用負担割合を大きくする。

【0132】

サーバ５００は、自動運転中（図３参照）に記録された車両１の状態を、車両１から受信してもよい。サーバ５００は、第１ユーザに使用されているときに車両１の各種センサで検出された車両１の状態の推移に基づいて、第１ユーザの使用に起因した部品の劣化進行度を推定してもよい。また、サーバ５００は、第２ユーザに使用されているときに車両１の各種センサで検出された車両１の状態の推移に基づいて、第２ユーザの使用に起因した部品の劣化進行度を推定してもよい。たとえば、急発進又は急ブレーキの頻度が高いほど駆動系の部品は劣化しやすくなる。また、充放電頻度が高いほどバッテリ１６０は劣化しやすくなる。サーバ５００は、各ユーザの用途をさらに用いて、各ユーザの使用に起因した部品の劣化進行度を推定してもよい。

【0133】

上記変形例に係るカーシェアリング方法では、サーバ５００が、車両１で部品のメンテナンスが行なわれたときに、ユーザごとに、車両１の使用に起因した当該部品の劣化進行度を取得し、ユーザごとの部品の劣化進行度を用いて、部品のメンテナンスにかかる費用のユーザごとの負担割合を決定する（Ｓ２０７Ａ）。こうしたカーシェアリング方法によっても、ユーザごとの費用負担割合を公平に決めることが可能になる。

【0134】

上記実施の形態及び変形例では、サーバ５００としてオンプレミスサーバが採用されている（図１参照）。しかしこれに限られず、クラウドコンピューティングによってクラウド上にサーバ５００の機能の少なくとも一部が実装されてもよい。また、サーバ５００の機能の少なくとも一部は、車両又はモバイル端末に実装されてもよい。

【0135】

車両の構成は、上記実施の形態で説明した構成（図１、図２、図４、及び図５参照）に限られない。ベース車両が後付けなしの状態で自動運転機能を有してもよい。自動運転のレベルは、完全自動運転（レベル５）であってもよいし、条件付きの自動運転（たとえば、レベル４）であってもよい。車両の構成は、無人走行専用の構成に適宜変更されてもよい。たとえば、無人走行専用の車両は、人が車両を操作するための部品（ステアリングホイールなど）を備えなくてもよい。ただし、上述したカーシェアリングシステム及びカーシェアリング方法が適用される車両は、自動運転車両に限定されない。

【0136】

車両は、ソーラーパネルを備えてもよいし、飛行機能を備えてもよい。車両は、乗用車に限られず、バス又はトラックであってもよい。車両は、個人が所有する車両（ＰＯＶ）であってもよい。車両は、ユーザの使用目的に応じてカスタマイズされる多目的車両であってもよい。車両は、移動店舗車両、無人搬送車（ＡＧＶ）、又は農業機械であってもよい。車両は、無人又は１人乗りの小型ＢＥＶ（たとえば、マイクロパレット）であってもよい。

【0137】

上述した実施の形態及び各変形例は任意に組み合わせて実施されてもよい。
今回開示された実施の形態は、全ての点で例示であって制限的なものではないと考えられるべきである。本開示により示される技術的範囲は、上記した実施の形態の説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内での全ての変更が含まれることが意図される。

【符号の説明】

【0138】

１ 車両、２ ＶＰ、２０ ＭＧ、１００ ベース車両、１０２ 制御システム、１１５ 統合制御マネージャ、１３０ 通信装置、１５０ 制御装置、１６０ バッテリ、１７０ サスペンション、１８０ 制動装置、２００ ＡＤＫ、２０２ ＡＤＳ、２１０ コンピュータ、２６０ 認識用センサ、２７０ 姿勢用センサ、５００ サーバ、５０１ プロセッサ、５０３ 記憶装置、５０４ ＨＭＩ、ＵＴ１，ＵＴ２ モバイル端末。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】