计算机、汽车共享系统以及汽车共享方法

技术领域

本公开涉及计算机、汽车共享系统以及汽车共享方法。

背景技术

在日本特开2015－138395中公开了如下技术：在铁路或公共汽车这样的车辆在预先确定的轨道行驶的交通系统中，计算维护所花费的成本(人工费和作业所需的物品的成本)。

近年来，提出了通过由多个用户共享(共用)一台车辆来有效利用一台车辆。在针对一台车辆进行长期的汽车共享的方式中，可以考虑在进行搭载于该车辆的部件的维护(例如，检查、修理或更换)时，由各用户负担维护所花费的费用。

然而，很难通过用户间的协商来决定按每个用户的维护费用的负担比例。此外，通过基于人数的单纯的比例分配来决定维护费用的负担比例不一定是公平的。例如，以加快部件的劣化的方式使用了车辆的用户和以不使部件劣化的方式使用了车辆的用户按相同的比例来负担费用不能说是公平的。

发明内容

本公开是为了解决上述问题而完成的，其目的在于，在被多个用户使用的一台车辆中进行了部件的维护时，公平地决定该维护所花费的费用的按每个用户的负担比例。

本公开的第一观点的计算机被配置为：在被多个用户使用的一台车辆中进行了部件的维护时，基于被维护的部件的种类和按每个用户的车辆的使用方式来决定该维护所花费的费用的按每个用户的负担比例。

根据上述计算机，在被多个用户使用的一台车辆中进行了部件的维护时，该维护所花费的费用的按每个用户的负担比例是基于被维护的部件的种类和按每个用户的车辆的使用方式来决定的。根据这样的计算机，能公平地决定按每个用户的费用负担比例。

上述计算机可以具备处理器和存储装置。在存储装置中可以存储有表示多个部件分类与多个用途分类与费用负担比例之间的关系的费用负担信息。处理器可以被配置为：根据多个部件分类中被维护的部件的种类所属的部件分类和多个用途分类中各用户的车辆的用途所属的用途分类，来获取各用户的费用负担比例，并使用获取到的各用户的费用负担比例来决定维护所花费的费用的按每个用户的负担比例。根据这样的构成，能容易且准确地决定按每个用户的费用负担比例。

上述多个部件分类可以包括从由与内饰件相关的第一部件分类、与驱动系统的部件相关的第二部件分类、与悬架相关的第三部件分类以及与蓄电装置相关的第四部件分类构成的组中选择的两个以上的部件分类。上述多个用途分类可以包括从由与办公用途相关的第一用途分类、与旅客运送用途相关的第二用途分类、与物流用途相关的第三用途分类以及与医疗用途相关的第四用途分类构成的组中选择的两个以上的用途分类。

根据上述构成，易于公平地决定按每个用户的费用负担比例。例如，若将旅客运送用途与办公用途进行比较，则具有如下倾向：驱动系统的部件和悬架关联部件分别在旅客运送用途中更容易劣化，蓄电装置的部件在办公用途中更容易劣化。若将旅客运送用途与物流用途进行比较，则具有如下倾向：内饰件、驱动系统的部件、悬架关联部件以及蓄电装置的部件均在物流用途中更容易劣化。若将旅客运送用途与医疗用途进行比较，则具有如下倾向：驱动系统的部件和悬架关联部件分别在旅客运送用途中更容易劣化，蓄电装置的部件在医疗用途中更容易劣化。若将办公用途与医疗用途进行比较，则具有如下倾向：驱动系统的部件、悬架关联部件以及蓄电装置的部件均在医疗用途中更容易劣化。

在上述存储装置中也可以还存储有表示按每个用户的车辆的使用时间的用户信息。处理器也可以被配置为：除了使用通过费用负担信息示出的各用户的费用负担比例之外，还使用通过用户信息示出的各用户的车辆的使用时间，来决定维护所花费的费用的按每个用户的负担比例。根据这样的构成，易于更公平地决定按每个用户的费用负担比例。

上述的计算机也可以被配置为：在车辆中进行了部件的维护时，按每个用户获取起因于车辆的使用的该部件的劣化进度，并使用按每个用户的部件的劣化进度来决定部件的维护所花费的费用的按每个用户的负担比例。通过这样的构成，也易于更公平地决定按每个用户的费用负担比例。

本公开的第二观点的汽车共享系统包括上述的任一个计算机和多个用户所共用的车辆。车辆是被配置为能通过变更内饰件来与用户的用途匹配地进行定制的多目的车辆。

上述汽车共享系统包括上述的计算机。因此，根据上述汽车共享系统，在被多个用户使用的一台车辆中进行了部件的维护时，能公平地决定该维护所花费的费用的按每个用户的负担比例。此外，通过采用多目的车辆，易于向各用户提供具有与按每个用户的需求匹配的装备的车辆。

上述的任一个车辆也可以具备：控制装置；自动驾驶套件；以及车辆控制接口，对控制装置与自动驾驶套件之间的信号的交换进行中介。自动驾驶套件可以被配置为经由车辆控制接口向控制装置发送用于自动驾驶的指令。控制装置可以被配置为按照来自自动驾驶套件的指令来控制车辆。控制装置也可以被配置为经由车辆控制接口向自动驾驶套件发送表示车辆的状态的信号。

通过采用上述那样的自动驾驶套件，易于向各用户提供具有与按每个用户的需求匹配的装备的车辆。此外，通过存在车辆控制接口，自动驾驶套件的拆装变得容易，从而易于进行自动驾驶套件的维护(检查、修理、更换等)。

本公开的第三观点的汽车共享方法包括以下所示的第一提供处理、第二提供处理以及决定处理。

在第一提供处理中，计算机向第一用户提供车辆。在第二提供处理中，在第一用户使用完车辆之后，计算机向第二用户提供车辆。在决定处理中，在车辆中进行了部件的维护时，计算机基于被维护的部件的种类和按每个用户的车辆的使用方式来决定该维护所花费的费用的按每个用户的负担比例。

通过上述汽车共享方法，也与上述的计算机同样地，在被多个用户使用的一台车辆中进行了部件的维护时，能公平地决定该维护所花费的费用的按每个用户的负担比例。

根据本公开，在被多个用户使用的一台车辆中进行了部件的维护时，能公平地决定该维护所花费的费用的按每个用户的负担比例。

附图说明

以下，参照附图，对本发明的示例性实施例的特征、优点以及技术和工业意义进行说明，其中，相同的附图标记表示相同的元件，其中：

图1是表示本公开的实施方式的车辆的概略构成的图。

图2是表示图1所示的车辆的构成的详情的图。

图3是表示本公开的实施方式的自动驾驶控制的处理过程的流程图。

图4是用于对本公开的实施方式的车辆所具备的各种部件进行说明的图。

图5是表示本公开的实施方式的车辆的外观的图。

图6是用于对本公开的实施方式的计算机的构成进行说明的图。

图7是表示在本公开的实施方式的汽车共享方法中，计算机为了对被多个用户共用的一台车辆进行管理而执行的处理的流程图。

图8是用于对图7所示的涉及维护的处理的详情进行说明的流程图。

图9是表示图6所示的用户信息和费用负担信息的变形例的图。

图10是表示图8所示的处理的变形例的流程图。

具体实施方式

以下，参照附图对本公开的实施方式详细进行说明。需要说明的是，对图中相同或相当部分标注相同附图标记，并且不重复其说明。

图1是表示本公开的实施方式的车辆的概略构成的图。参照图1，车辆1具备自动驾驶套件(以下，表述为“ADK(Autonomous Driving Kit)”)200和车辆平台(以下，表述为“VP(Vehicle Platform)”)2。

VP2包括基础车辆100的控制系统和设于基础车辆100内的车辆控制接口箱(以下，表述为“VCIB(Vehicle Control Interface Box)”)111。VCIB111可以通过CAN(ControllerArea Network：控制器局域网)这样的车内网络与ADK200进行通信。需要说明的是，虽然在图1中基础车辆100和ADK200被示于分离的位置，但实际上ADK200装配于基础车辆100。在本实施方式中，ADK200装配于基础车辆100的车顶。不过，ADK200的装配位置可以适当地变更。

基础车辆100例如是市售的xEV(电动车)。xEV是利用电力作为动力源的全部或一部分的车辆。在本实施方式中，采用BEV(纯电动汽车)来作为基础车辆100。不过不限于此，基础车辆100也可以是BEV以外的xEV(HEV、PHEV、FCEV等)。基础车辆100所具备的车轮的数量例如是四轮。不过不限于此，基础车辆100所具备的车轮的数量也可以是三轮，还可以是五轮以上。

除了综合控制管理器115之外，基础车辆100的控制系统还包括用于对基础车辆100进行控制的各种系统和各种传感器。综合控制管理器115基于来自基础车辆100中所包括的各种传感器的信号(传感器检测信号)来对与基础车辆100的动作相关的各种系统进行综合控制。

在本实施方式中，综合控制管理器115包括控制装置150。控制装置150包括处理器151、RAM(Random Access Memory：随机存取存储器)152以及存储装置153。作为处理器151，例如可以采用CPU(Central Processing Unit：中央处理器)。RAM152作为临时存储由处理器151处理的数据的作业用存储器发挥功能。存储装置153被配置为能保存所储存的信息。存储装置153例如包括ROM(Read Only Memory：只读存储器)和可重写的非易失性存储器。在存储装置153中，除了程序之外，还存储有在程序中使用的信息(例如，映射图、公式以及各种参数)。在本实施方式中，通过处理器151执行存储于存储装置153的程序来执行各种车辆控制(例如，按照来自ADK200的指示的自动驾驶控制)。不过，这些处理也可以通过专用的硬件(电子电路)来执行而不通过软件执行。需要说明的是，控制装置150所具备的处理器的数量是任意的，可以按每个规定的控制来准备处理器。

基础车辆100包括制动器系统121、操舵系统122、动力传动系统123、主动安全系统125以及车身系统126。这些系统由综合控制管理器115进行综合控制。在本实施方式中，各系统具备计算机。并且，每个系统的计算机通过车内网络(例如，CAN)与综合控制管理器115进行通信。以下，将各系统所具备的计算机称为“ECU(Electronic Control Unit：电子控制单元)”。

制动器系统121包括设于基础车辆100的各车轮的制动装置和对制动装置进行控制的ECU。在本实施方式中，采用液压式盘形制动器装置来作为制动装置。基础车辆100具备车轮速度传感器127A、127B。车轮速度传感器127A设于基础车辆100的前轮，检测前轮的转速。车轮速度传感器127B设于基础车辆100的后轮，检测后轮的转速。制动器系统121的ECU向综合控制管理器115输出通过车轮速度传感器127A、127B检测到的各车轮的旋转方向和转速。

操舵系统122包括基础车辆100的转向装置和对转向装置进行控制的ECU。转向装置例如包括能通过致动器进行转向角的调整的齿轮齿条式的EPS(Electric PowerSteering：电动助力转向)。基础车辆100具备小齿轮角传感器128。小齿轮角传感器128对连结于构成转向装置的致动器的旋转轴的小齿轮的旋转角(小齿轮角)进行检测。操舵系统122的ECU向综合控制管理器115输出通过小齿轮角传感器128检测到的小齿轮角。

动力传动系统123包括：EPB(Electric Parking Brake：电动驻车制动器)，设于基础车辆100所具备的车轮中的至少一个；P-Lock装置，设于基础车辆100的变速器；换挡装置，被配置为能选择挡位；基础车辆100的驱动源；以及ECU，对动力传动系统123中所包括的各装置进行控制。EPB与上述的制动装置分开设置，通过电动致动器来使车轮成为固定状态。P-Lock装置例如通过能由致动器驱动的驻车锁止爪来使变速器的输出轴的旋转位置成为固定状态。详情将在后文叙述，但在实施方式中，采用从蓄电装置接受电力的供给的马达来作为基础车辆100的驱动源。动力传动系统123的ECU向综合控制管理器115输出由EPB和P-Lock装置分别实现的固定化的有无、通过换挡装置选择出的挡位以及蓄电装置和马达(参照后述的图4)各自的状态。

主动安全系统125包括对行驶中的车辆1判定碰撞的可能性的ECU。基础车辆100具备对包括车辆1的前方和后方的周边状况进行检测的摄像机129A和雷达传感器129B、129C。主动安全系统125的ECU使用从摄像机129A和雷达传感器129B、129C接收到的信号来判定是否存在碰撞的可能性。在通过主动安全系统125判定为存在碰撞的可能性的情况下，综合控制管理器115对制动器系统121输出制动指令来使车辆1的制动力增加。本实施方式的基础车辆100从初始(出厂时)起具备主动安全系统125。但并不限于此，也可以采用能加装至基础车辆的主动安全系统。

车身系统126具备车身系统部件(例如，方向指示器、喇叭以及刮水器)和对车身系统部件进行控制的ECU。车身系统126的ECU在手动模式下，按照用户操作来控制车身系统部件，在自主模式下，按照经由VCIB111和综合控制管理器115从ADK200接收的指令来控制车身系统部件。

车辆1被配置为能进行自动驾驶。VCIB111作为车辆控制接口发挥功能。在车辆1通过自动驾驶进行行驶时，综合控制管理器115和ADK200经由VCIB111相互进行信号的交换，并且综合控制管理器115按照来自ADK200的指令来执行通过自主模式(Autonomous Mode)实现的行驶控制(即，自动驾驶控制)。需要说明的是，ADK200也能从基础车辆100拆下。即使在ADK200被拆下的状态下，基础车辆100也能通过用户的驾驶以基础车辆100单体进行行驶。在以基础车辆100单体进行行驶的情况下，基础车辆100的控制系统执行通过手动模式实现的行驶控制(即，与用户操作相应的行驶控制)。

在本实施方式中，ADK200按照对通信的各信号进行定义的API(ApplicationProgram Interface：应用程序接口)，在与VCIB111之间进行信号的交换。ADK200被配置为对通过上述API定义出的各种信号进行处理。ADK200例如制作车辆1的行驶计划，并按照上述API向VCIB111输出请求用于使车辆1按照所制作出的行驶计划进行行驶的控制的各种命令。以下，也将从ADK200向VCIB111输出的上述各种命令的每一个称为“API命令”。此外，ADK200按照上述API，从VCIB111接收表示基础车辆100的状态的各种信号，并将接收到的基础车辆100的状态反映至行驶计划的制作。以下，也将ADK200从VCIB111接收的上述各种信号的每一个称为“API信号”。API命令和API信号均相当于通过上述API定义出的信号。关于ADK200的构成的详情，将在后文叙述(参照图2)。

VCIB111从ADK200接收各种API命令。当从ADK200接收到API命令时，VCIB111将该API命令转换成综合控制管理器115能处理的信号的形式。以下，也将被转换成综合控制管理器115能处理的信号的形式的API命令称为“控制命令”。当从ADK200接收到API命令时，VCIB111向综合控制管理器115输出与该API命令对应的控制命令。

综合控制管理器115的控制装置150经由VCIB111向ADK200发送表示在基础车辆100的控制系统中检测到的基础车辆100的状态的各种信号(例如，传感器信号或状况信号)。VCIB111从综合控制管理器115依次接收表示基础车辆100的状态的信号。VCIB111基于从综合控制管理器115接收到的信号来决定API信号的值。此外，VCIB111根据需要将从综合控制管理器115接收到的信号转换成API信号的形式。然后，VCIB111向ADK200输出得到的API信号。从VCIB111向ADK200实时地依次输出表示基础车辆100的状态的API信号。

在本实施方式中，在综合控制管理器115与VCIB111之间例如交换由汽车制造商定义出的通用性低的信号，在ADK200与VCIB111之间交换通用性更高的信号(例如，通过公开的API(Open API)定义出的信号)。VCIB111能通过在ADK200与综合控制管理器115之间进行信号的转换使综合控制管理器115按照来自ADK200的指令进行车辆控制。不过，VCIB111的功能不仅限定于进行上述信号的转换的功能。例如，VCIB111也可以进行规定的判断，并向综合控制管理器115和ADK200中的至少一方发送基于该判断结果的信号(例如，进行通知、指示或请求的信号)。关于VCIB111的构成的详情，将在后文叙述(参照图2)。

基础车辆100还具备通信装置130。通信装置130包括各种通信I/F(接口)。控制装置150被配置为通过通信装置130与车辆1的外部的装置(例如，后述的移动终端UT1、UT2和服务器500)进行通信。通信装置130包括能访问移动通信网(车载信息服务(telematics))的无线通信器(例如，DCM(Data Communication Module：数据通信模块))。通信装置130经由移动通信网与服务器500进行通信。无线通信器可以包括与5G(第五代移动通信系统)对应的通信I/F。此外，通信装置130包括用于与存在于车内或车辆周边的范围内的移动终端UT1、UT2直接进行通信的通信I/F。通信装置130与移动终端UT1、UT2也可以进行无线LAN(Local Area Network：局域网)、NFC(Near Field Communication：近场通信)或蓝牙(Bluetooth；注册商标)这样的近距离通信。

移动终端UT1、UT2是分别由车辆1的第一用户、第二用户携带的终端。在本实施方式中，采用具备触摸面板显示器的智能手机来分别作为移动终端UT1和UT2。移动终端UT1和UT2的每一个内置有对该终端的当前位置进行检测的位置传感器。位置传感器可以是利用了GPS(Global Positioning System：全球定位系统)的传感器。需要说明的是，作为移动终端UT1和UT2的每一个，可以采用任意的移动终端，也可以采用笔记本电脑、平板终端、可穿戴式设备(例如，智能手表或智能眼镜)或电子钥匙等。

上述的车辆1可以作为MaaS(Mobility as a Service：出行即服务)系统的构成要素之一而被采用。MaaS系统例如包括MSPF(Mobility Service Platform：出行服务平台)。MSPF是连接有各种出行服务(例如，由拼车提供商、汽车共享提供商、保险公司、租赁汽车提供商、出租车提供商等提供的各种出行服务)的统一平台。服务器500是在MSPF中进行用于出行服务的信息的管理和公开的计算机。服务器500对各种出行的信息进行管理，并根据来自提供商的请求来提供信息(例如，API和与出行间的合作相关的信息)。提供服务的提供商能使用在MSPF上公开的API来利用MSPF所提供的各种各样的功能。例如，ADK的开发所需的API在MSPF上被公开。

图2是表示车辆1的构成的详情的图。参照图1和图2，ADK200包括用于进行车辆1的自动驾驶的自动驾驶系统(以下，表述为“ADS(Autonomous Driving System)”)202。ADS202包括计算机210、HMI(Human Machine Interface：人机接口)230、识别用传感器260、姿势用传感器270以及传感器清洁器290。

计算机210具备处理器和存储利用了API的自动驾驶软件的存储装置，并被配置为能通过处理器来执行自动驾驶软件。通过自动驾驶软件执行与自动驾驶相关的控制(参照后述的图3)。自动驾驶软件可以通过OTA(Over The Air：空中下载)来依次更新。计算机210还具备通信模块210A和210B。

HMI230是用于供用户与计算机210交换信息的装置。HMI230包括输入装置和报告装置。用户能通过HMI230对计算机210进行指示或请求，或者变更在自动驾驶软件中使用的参数(不过，仅限于允许变更的参数)的值。HMI230可以是兼具输入装置和报告装置两方的功能的触摸面板显示器。

识别用传感器260包括获取用于识别车辆1的外部环境的信息(以下，也称为“环境信息”)的各种传感器。识别用传感器260获取车辆1的环境信息，并向计算机210输出该环境信息。环境信息用于自动驾驶控制。在本实施方式中，识别用传感器260包括：摄像机，对车辆1的周围(包括前方和后方)进行拍摄；以及障碍物感测器(例如，毫米波雷达和/或激光雷达)，通过电磁波或声波来感测障碍物。计算机210例如能使用从识别用传感器260接收的环境信息来识别存在于能从车辆1识别的范围内的人、物体(其他的车辆、柱、护栏等)以及道路上的线(例如，中心线)。为了进行识别，也可以使用人工智能(AI)或图像处理用处理器。

姿势用传感器270获取与车辆1的姿势相关的信息(以下，也称为“姿势信息”)，并向计算机210输出该信息。姿势用传感器270包括对车辆1的加速度、角速度以及位置进行检测的各种传感器。在本实施方式中，姿势用传感器270包括IMU(Inertial MeasurementUnit：惯性测量单元)和GPS传感器。IMU对车辆1的前后方向、左右方向以及上下方向的各个加速度和车辆1的侧倾方向、俯仰方向以及偏航方向的各个角速度进行检测。GPS传感器使用从多个GPS卫星接收的信号来检测车辆1的位置。在汽车和飞机的领域中，将IMU与GPS进行组合来以高精度计测姿势的技术是公知的。计算机210例如可以利用这样的公知的技术，根据上述姿势信息来计测车辆1的姿势。

传感器清洁器290是去除在车外暴露于外部空气的传感器(例如，识别用传感器260)的污垢的装置。例如，传感器清洁器290也可以被配置为使用清洗液和擦拭器来对摄像机的镜头和障碍物感测器的射出口进行清洁。

在车辆1中，为了提高安全性，使规定的功能(例如，制动、操舵以及车辆固定)具有冗余性。基础车辆100的控制系统102具备多个实现同等的功能的系统。具体而言，制动器系统121包括制动器系统121A和121B。操舵系统122包括操舵系统122A和122B。动力传动系统123包括EPB系统123A和P-Lock系统123B。各系统具备ECU。即使实现同等的功能的多个系统中的一方产生异常，另一方也正常地动作，由此，在车辆1中该功能正常工作。

VCIB111包括VCIB111A和VCIB111B。VCIB111A和VCIB111B的每一个包括计算机。计算机210的通信模块210A、210B被配置为能分别与VCIB111A、VCIB111B的计算机进行通信。VCIB111A和VCIB111B以能相互通信的方式连接。VCIB111A和VCIB111B的每一个能单独地动作，即使一方产生异常，另一方也正常地动作，由此，VCIB111正常地动作。VCIB111A和VCIB111B均经由综合控制管理器115连接于上述各系统。不过，如图2所示，在VCIB111A和VCIB111B中，连接目的地有一部分不同。

在本实施方式中，使车辆1加速的功能不具有冗余性。动力传动系统123包括推进系统123C来作为用于使车辆1加速的系统。

车辆1被配置为能在自主模式与手动模式之间进行切换。ADK200从VCIB111接收的API信号中包括表示车辆1为自主模式和手动模式中的哪一个状态的信号(以下，表述为“自主状态”)。用户能通过规定的输入装置(例如，HMI230或移动终端UT1、UT2)来选择自主模式和手动模式中的任一个。当由用户选择了任一个驾驶模式时，车辆1成为所选择出的驾驶模式，并且选择结果被反映至自主状态。不过，如果车辆1未成为能自动驾驶的状态，则即使用户选择自主模式也不会转移至自主模式。车辆1的驾驶模式的切换可以通过综合控制管理器115来进行。综合控制管理器115也可以根据车辆1的状况在自主模式与手动模式之间进行切换。

在车辆1为自主模式时，计算机210从VP2获取车辆1的状态，并对车辆1的下一个动作(例如，加速、减速以及转弯)进行设定。然后，计算机210输出用于实现所设定的车辆1的下一个动作的各种指令。通过计算机210执行API软件(即，利用了API的自动驾驶软件)，与自动驾驶控制相关的指令从ADK200通过VCIB111被发送向综合控制管理器115。

图3是表示在本实施方式的自动驾驶控制中ADK200所执行的处理的流程图。该流程图所示的处理在车辆1为自主模式时，以与API对应的周期(API周期)被反复执行。当车辆1的驾驶模式从手动模式被切换至自主模式时，表示自动驾驶开始的开始信号与车辆1的辨别信息一起从车辆1(通信装置130)被发送向服务器500，并且开始以下说明的图3所示的一系列处理。以下，将流程图中的各步骤仅表述为“S”。

参照图1、图2以及图3，在S101中，计算机210获取当前的车辆1的信息。例如，计算机210从识别用传感器260和姿势用传感器270获取车辆1的环境信息和姿势信息。而且，计算机210获取API信号。在本实施方式中，在车辆1为自主模式和手动模式中的任一个的情况下，也从VCIB111向ADK200实时地依次输出表示车辆1的状态的API信号。为了提高自动驾驶控制的精度，也可以在自主模式下，以比手动模式短的周期从综合控制管理器115朝向ADK200依次发送车辆1的状态。在计算机210所获取的API信号中，除了上述的自主状态之外，还包括表示通过车轮速度传感器127A、127B检测到的各车轮的旋转方向和转速的信号等。

在S102中，计算机210基于在S101中获取到的车辆1的信息来制作行驶计划。例如，计算机210计算车辆1的行为(例如，车辆1的姿势)，并制作适于车辆1的状态和外部环境的行驶计划。行驶计划是表示规定期间内的车辆1的行为的数据。在行驶计划已存在的情况下，也可以在S102中修改该行驶计划。

在S103中，计算机210从在S102中制作出的行驶计划中提取控制性的物理量(加速度、轮胎转角等)。在S104中，计算机210按每个API周期对在S103中提取出的物理量进行分割。在S105中，计算机210使用在S104中分割出的物理量来执行API软件。如此，通过API软件被执行，请求用于实现按照行驶计划的物理量的控制的API命令(推进方向命令、推进命令、制动命令、车辆固定命令等)从ADK200被发送向VCIB111。VCIB111向综合控制管理器115发送与所接收到的API命令对应的控制命令，综合控制管理器115按照该控制命令来进行车辆1的自动驾驶控制。自动驾驶中的车辆1的状态被依次记录于计算机210的存储装置。

在接下来的S106中，计算机210对车辆1是否为自主模式进行判断。在自主模式持续的期间(在S106中为“是(YES)”)，通过反复执行上述S101～S105的处理来执行车辆1的自动驾驶。另一方面，当车辆1成为手动模式时(在S106中为“否(NO)”)，在S107中，在将表示自动驾驶结束的结束信号与车辆1的辨别信息一起从车辆1(通信装置130)发送向服务器500之后，图3所示的一系列处理结束。在本实施方式中，计算机210、VCIB111以及综合控制管理器115协作来执行用于使车辆1通过自动驾驶进行行驶的控制。车辆1在有人/无人中的任一个状态下均能进行自动驾驶。需要说明的是，自动驾驶控制不限于图3所示的控制，也可以采用其他的控制(公知的自动驾驶控制)。

图4是用于对车辆1所具备的各种部件进行说明的图。参照图1、图2以及图4，车辆1还具备电池160和悬架170。推进系统123C包括MG(Motor Generator：电动发电机)20、ECU21以及PCU(Power Control Unit：功率控制单元)22。电池160对推进系统123C供给电力。可以采用公知的车辆用蓄电装置(例如，液式二次电池、全固体二次电池或电池组)来作为电池160。作为车辆用二次电池的例子，可以举出锂离子电池、镍氢电池。悬架170可以是空气悬架装置。

在电池160设有监视模块160a。监视模块160a包括对电池160的状态(例如，电压、电流以及温度)进行检测的各种传感器，并向综合控制管理器115输出检测结果。监视模块160a也可以是除了上述传感器功能之外还具有SOC(State Of Charge：荷电状态)推定功能的BMS(Battery Management System：电池管理系统)。控制装置150能基于监视模块160a的输出来获取电池160的状态(例如，温度、电流、电压以及SOC)。SOC表示蓄电余量，例如用0％～100％来表示当前的蓄电量相对于充满电状态的蓄电量的比例。

推进系统123C使用蓄存于电池160的电力来产生车辆1的行驶驱动力。MG20例如是三相交流电动发电机。PCU22例如包括逆变器(inverter)、转换器(convertor)以及继电器(以下，称为“SMR(System Main Relay：系统主继电器)”)。PCU22由ECU21控制。SMR被配置为切换从电池160到MG20的电路的连接/断开。SMR在车辆1的行驶时被设为闭合状态(连接状态)。

MG20由PCU22驱动，使车辆1的驱动轮W旋转。此外，MG20进行再生发电，并将发电所产生的电力供给至电池160。PCU22使用从电池160供给的电力来驱动MG20。车辆1所具备的行驶用的马达(MG20)的数量是任意的，既可以是一个，也可以是两个，还可以是三个以上。行驶用的马达也可以是轮内马达。图4中仅示意性地示出了一个驱动轮W，但车辆1中的驱动轮W的数量和驱动方式是任意的。车辆1的驱动方式可以是前轮驱动、后轮驱动、四轮驱动中的任一个。

在车辆1所具备的各车轮(包括驱动轮W)设有：制动装置180，包括在制动器系统121(图1)中；以及制动器传感器180a，对由制动装置180赋予至车轮的制动力进行检测。制动器传感器180a可以是对施加于制动垫块(或轮缸)的液压进行检测的液压传感器。通过四个制动器传感器180a分别检测到的每个车轮的制动力(例如，与制动力对应的液压)被输出向综合控制管理器115。

图5是表示车辆1的外观的图。参照图5，车辆1是被配置为能通过变更内饰件来与用户的用途匹配地进行定制的多目的车辆。根据这样的多目的车辆，易于向各用户提供具有与按每个用户的需求匹配的装备的车辆。在本实施方式中，通过车辆1和服务器500来构建汽车共享系统。在第一用户和第二用户中共享(共用)车辆1。

本实施方式的车辆1被配置为能分别定制为移动办公用途(第一用途)和旅客运送用途(第二用途)。在本实施方式中，将在第一用途和第二用途这两方中使用的通用的内饰件简称为“通用的内饰件”。此外，在第一用途和第二用途中，将仅在第一用途中使用的按用途区分的内饰件称为“第一用途内饰件”，将仅在第二用途中使用的按用途区分的内饰件称为“第二用途内饰件”。

在第一使用期间中，第一用户以移动办公用途(第一用途)使用车辆1。在设定于第一使用期间之后的第二使用期间内，第二用户以旅客运送用途(第二用途)使用车辆1。也可以是，车辆1在第一使用期间和第二使用期间中的至少一方进行自动驾驶。在车辆1的自动驾驶中执行图3所示的处理，控制装置150按照来自ADK200的指令来控制车辆1的各种系统(例如，图2所示的制动器系统121、操舵系统122、动力传动系统123、主动安全系统125以及车身系统126)。

在本实施方式中，车辆1被每天使用。车辆1从早到晚被使用。当到了晚上，当天的车辆1的使用结束，对车辆1进行部件检验。在部件检验中，通过按照规定的顺序的客观的检查来按每个对象部件(检查项目)确认车辆1是否具有规定的基准以上的性能。在部件检验中，控制装置150也可以基于搭载于车辆1的各种传感器的输出来判断每个对象部件的良否。或者，也可以使用检查设备(测试仪)来进行部件检验。

在部件检验中任何对象部件均未发现异常的情况下，使用EVSE(ElectricVehicle Supply Equipment：电动汽车供电设备)来对车辆1的电池160(蓄电装置)进行充电。通过该充电，用于下一次使用的电力被蓄存至车辆1。EVSE的充电方式既可以是接触方式也可以是非接触方式。电池160的充电在车辆1的使用结束后开始，在使用日的第二天早上之前完成。当到了早上，开始车辆1的下一次使用。

在本实施方式中，每经过一周时，第一使用期间和第二使用期间被再次设定。在规定的汽车共享期间中，第一用户和第二用户交替地使用车辆1。汽车共享期间可以任意地设定(或更新)，既可以是一个月，也可以是一年。

可以在使用期间的间隙设置用于交付车辆1的交付期间。例如，可以在从第一使用期间的结束起至第二使用期间的开始为止的期间设置用于将车辆1从第一用户交付给第二用户的第一交付期间。此外，也可以在从第二使用期间的结束起至第一使用期间的开始为止的期间设置用于将车辆1从第二用户交付给第一用户的第二交付期间。

第一交付期间也可以设定为从第一使用期间的最后一天的傍晚起至第二使用期间的第一天的白天为止的至少一部分。在第一交付期间，车辆1可以执行用于向第二用户所指定的场所移动的自动驾驶。服务器500也可以向移动终端UT1发送如下信号：请求第一用户在第一交付期间的开始时刻之前预先完成用于车辆1的上述自动驾驶的充电。

第二交付期间也可以设定为从第二使用期间的最后一天的傍晚起至第一使用期间的第一天的白天为止的至少一部分。在第二交付期间，车辆1可以执行用于向第一用户所指定的场所移动的自动驾驶。服务器500也可以向移动终端UT2发送如下信号：请求第二用户在第二交付期间的开始时刻之前预先完成用于车辆1的上述自动驾驶的充电。

图6是对服务器500的构成进行说明的图。参照图1、图2以及图6，服务器500包括处理器501、RAM502、存储装置503以及HMI504。HMI(Human Machine Interface：人机接口)504包括输入装置和显示装置。HMI504也可以是触摸面板显示器。HMI504也可以包括受理声音输入的智能音箱。服务器500被配置为能与车辆1和移动终端UT1、UT2的每一个进行通信。通过车辆1的姿势用传感器270获取的位置信息(表示车辆1的当前位置的信息)从车辆1被依次发送向服务器500。此外，表示移动终端UT1和UT2各自的当前位置的信息也从各终端被依次发送向服务器500。本实施方式的服务器500相当于本公开的“计算机”的一个例子。

存储装置503被配置为能保存所储存的信息。在存储装置503中存储有与第一用户和第二用户的每一个相关的信息以及与车辆1相关的信息。例如，服务器500从车辆1和移动终端UT1、UT2的每一个接收到的信息(例如，位置信息)被保存于存储装置503。而且，在存储装置503中存储有程序和在程序中使用的信息(例如，映射图、公式以及各种参数)。在本实施方式中，通过处理器501执行存储于存储装置503的程序来执行后述的涉及车辆管理的处理(参照图7)。不过，这样的处理也可以通过专用的硬件(电子电路)来执行而不通过软件执行。

服务器500对与用户相关的信息(以下，表述为“用户信息”)和与费用相关的信息(以下，表述为“费用负担信息”)进行管理。用户信息和费用负担信息存储于存储装置503。

用户信息通过图6中的表T1示出。在用户信息中，通过用于辨别用户的辨别信息(用户ID)来区分各用户的信息。在表T1中，“U－1”、“U－2”分别相当于第一用户、第二用户的用户ID。针对第一用户和第二用户的每一个，用户信息示出车辆1的使用期间(即，上述的第一使用期间和第二使用期间)和车辆1的用途(即，上述的第一用途和第二用途)。在本实施方式中，第一用途、第二用途分别是移动办公用途、旅客运送用途。此外，第一使用期间是工作日(星期一～星期五)，第二使用期间是周末(星期六/星期天)。第一用户对车辆1的使用时间是5天/周，第二用户对车辆1的使用时间是2天/周。如此，按每个用户的车辆1的使用时间通过用户信息示出。虽然在本实施方式中将单位期间设为一周，但单位期间是任意的。

在本实施方式中，费用负担信息示出如以下说明那样的多个部件分类与多个用途分类与费用负担比例之间的关系。费用负担信息通过图6中的表T2示出。

由费用负担信息规定的多个部件分类包括与通用的内饰件相关的第一部件分类、与驱动系统的部件相关的第二部件分类、与悬架170相关的第三部件分类、与电池160相关的第四部件分类、与第一用途内饰件相关的第五部件分类以及与第二用途内饰件相关的第六部件分类。

驱动系统的部件中包括用于使车辆1行驶的各种部件。不仅对车辆1赋予动力的部件(例如，MG20)包括在驱动系统的部件中，控制车辆1的行驶的部件也包括在驱动系统的部件中。例如，ADK200、制动器系统121、操舵系统122以及推进系统123C各自所包括的部件相当于驱动系统的部件。第一用途内饰件例如是办公用品。第二用途内饰件例如是旅客运送用座椅。

由费用负担信息规定的多个用途分类包括与办公用途相关的第一用途分类和与旅客运送用途相关的第二用途分类。即，第一用户的用途(第一用途)属于第一用途分类，第二用户的用途(第二用途)属于第二用途分类。

费用负担信息所示的费用负担比例是部件维护所花费的费用的各用户的负担比例。作为部件维护的例子，可以举出部件的修理或更换。在本实施方式中，费用负担信息示出办公用途的用户(第一用户)与旅客运送用途的用户(第二用户)的费用负担比例。具体而言，通过费用负担信息示出的费用负担比例(第一用户∶第二用户)如图6中的表T2所示，针对第一部件分类是“5∶5”，针对第二部件分类是“2∶8”，针对第三部件分类是“3∶7”，针对第四部件分类是“7∶3”，针对第五部件分类是“10∶0”，针对第六部件分类是“0∶10”。

上述费用负担比例根据部件的劣化倾向来确定。例如，若将旅客运送用途与办公用途进行比较，则具有如下倾向：驱动系统的部件和悬架关联部件分别在旅客运送用途中更容易劣化，蓄电装置的部件在办公用途中更容易劣化。按用途区分的内饰件仅在对应的用途中使用，因此，按用途区分的内饰件的维护所花费的费用由以对应的用途使用了车辆1的用户全额负担。

服务器500被配置为：在被多个用户使用的一台车辆中进行了部件的维护时，基于被维护的部件的种类和按每个用户的车辆的使用方式来决定该维护所花费的费用的按每个用户的负担比例。

具体而言，服务器500(更确定地说，处理器501)参照上述费用负担信息(图6中的表T2)，从第一部件分类～第六部件分类中被维护的部件的种类所属的部件分类、第一用途分类～第二用途分类中第一用户的车辆1的用途所属的用途分类(第一用途分类)以及第二用户的车辆1的用途所属的用途分类(第二用途分类)中获取各用户的费用负担比例，并使用获取到的各用户的费用负担比例来决定部件维护所花费的费用的按每个用户的负担比例。

在本实施方式中，服务器500(更确定地说，处理器501)除了使用通过上述费用负担信息示出的各用户的费用负担比例(以下，也称为“第一比例”)之外，还使用通过上述的用户信息(图6中的表T1)示出的各用户的车辆1的使用时间，来决定部件维护所花费的费用的按每个用户的负担比例。用户信息示出第一用户和第二用户的使用时间的比例(以下，也称为“第二比例”)。在本实施方式中，第二比例(第一用户∶第二用户)为5∶2。服务器500基于第一比例和第二比例来决定第一用户和第二用户各自的负担比例。服务器500增大车辆1的使用时间长的用户的负担比例。

图7是表示服务器500为了对由第一用户和第二用户共享(共用)的车辆1进行管理而执行的处理的流程图。该流程图所示的处理在第一用户和第二用户的汽车共享期间被反复执行。

参照图1～图6以及图7，在S11中，服务器500判断当前时刻是否为第一使用期间内。在当前时刻为第一使用期间内的情况下(在S11中为“是”)，处理进入S12。在S12中，服务器500获取车辆1的使用状况，并判断车辆1是否正被第一用户使用。

在本实施方式中，服务器500使用车辆1的当前位置、移动终端UT1的当前位置以及移动终端UT2的当前位置中的至少一个来获取车辆1的使用状况。例如，在车辆1存在于移动终端UT1的当前位置的周边的情况下，服务器500判断为车辆1正被第一用户使用。此外，在车辆1存在于移动终端UT2的当前位置的周边的情况下，服务器500判断为车辆1正被第二用户使用。并且，在任何移动终端的周边均不存在车辆1的情况下，服务器500判断为车辆1为不使用状态(车辆1未被任何用户使用)。

需要说明的是，车辆1的使用状况的判断方法不限于上述内容，可以适当变更。例如，也可以是，在车辆1存在于第一用户的使用区域内(例如，第一用户的自己家或工作场所的周边)的情况下，服务器500判断为车辆1正被第一用户使用。此外，也可以是，在车辆1存在于第二用户的使用区域内(例如，第二用户的自己家或工作场所的周边)的情况下，服务器500判断为车辆1正被第二用户使用。并且，也可以是，在车辆1存在于各用户的使用区域外的情况下，服务器500判断为车辆1为不使用状态。

在车辆1正被第一用户使用的情况下(在S12中为“是”)，服务器500在S13中判断第一使用期间的结束时刻是否接近。第一使用期间的结束时刻可以是第一使用期间的最后一天的傍晚(例如，17点)。服务器500也可以在S13中判断是否超过了第一使用期间的最后一天的规定时刻。规定时刻可以是从第一使用期间的结束时刻起回溯了规定时间的时刻(例如，16点)。另一方面，在车辆1为不使用状态的情况下，或者车辆1正被第二用户使用的情况下，在S12中判断为“否”。在S12中判断为“否”或在S13中判断为“是”的情况下，处理进入S14。

在S14中，服务器500通知第一用户。服务器500例如对移动终端UT1进行通知。在车辆1正被第一用户使用(在S12中为“是”)且第一使用期间的结束时刻接近的情况下(在S13中为“是”)，服务器500通过S14的通知来请求第一用户进行将车辆1交付给第二用户的准备。在车辆1为不使用状态的情况下，服务器500通过S14的通知来催促第一用户使用车辆1。在车辆1正被第二用户使用的情况下(在后述的S25中为“是”)，服务器500通过S14的通知来使第一用户获知车辆1的使用状况。在通过后述的S26的处理从移动终端UT2接收到第二用户的状况的情况下，服务器500通过S14的通知来使第一用户获知第二用户的状况。

当上述S14的处理被执行时，处理进入S21。此外，在车辆1正被第一用户使用(在S12中为“是”)且到第一使用期间的结束时刻为止时间上有富余的情况下(在S13中为“否”)，处理进入S21而不进行对第一用户的通知(S14)。

在当前时刻为第一使用期间外的情况下(在S11中为“否”)，处理进入S15。在S15中，与S12同样地，服务器500获取车辆1的使用状况，并判断车辆1是否正被第一用户使用。然后，在车辆1正被第一用户使用的情况下(在S15中为“是”)，处理进入S16。

在S16中，服务器500通知第一用户。服务器500例如对移动终端UT1进行通知。服务器500通过S16的通知来请求第一用户将车辆1交付给第二用户。此外，服务器500通过S16的通知来请求第一用户回复车辆1和第一用户各自的状况。

当上述S16的处理被执行时，处理进入S21。此外，在当前时刻为第一使用期间外(在S11中为“否”)且车辆1未被第一用户使用的情况下(在S15中为“否”)，处理进入S21而不进行对第一用户的通知(S16)。

在S21中，服务器500判断当前时刻是否为第二使用期间内。在当前时刻为第二使用期间内的情况下(在S21中为“是”)，处理进入S22。在S22中，服务器500获取车辆1的使用状况，并判断车辆1是否正被第二用户使用。

在车辆1正被第二用户使用的情况下(在S22中为“是”)，服务器500在S23中判断第二使用期间的结束时刻是否接近。第二使用期间的结束时刻可以是第二使用期间的最后一天的傍晚(例如，17点)。服务器500也可以在S23中判断是否超过了第二使用期间的最后一天的规定时刻。规定时刻可以是从第二使用期间的结束时刻起回溯了规定时间的时刻(例如，16点)。另一方面，在车辆1为不使用状态的情况下，或者车辆1正被第一用户使用的情况下，在S22中判断为“否”。在S22中判断为“否”或在S23中判断为“是”的情况下，处理进入S24。

在S24中，服务器500通知第二用户。服务器500例如对移动终端UT2进行通知。在车辆1正被第二用户使用(在S22中为“是”)且第二使用期间的结束时刻接近的情况下(在S23中为“是”)，服务器500通过S24的通知来请求第二用户进行将车辆1交付给第一用户的准备。在车辆1为不使用状态的情况下，服务器500通过S24的通知来催促第二用户使用车辆1。在车辆1正被第一用户使用的情况下(在S15中为“是”)，服务器500通过S24的通知来使第二用户获知车辆1的使用状况。在通过S16的处理从移动终端UT1接收到第一用户的状况的情况下，服务器500通过S24的通知来使第二用户获知第一用户的状况。

当上述S24的处理被执行时，处理进入S31。此外，在车辆1正被第二用户使用(在S22中为“是”)且到第二使用期间的结束时刻为止时间上有富余的情况下(在S23中为“否”)，处理进入S31而不进行对第二用户的通知(S24)。

在当前时刻为第二使用期间外的情况下(在S21中为“否”)，处理进入S25。在S25中，与S22同样地，服务器500获取车辆1的使用状况，并判断车辆1是否正被第二用户使用。然后，在车辆1正被第二用户使用的情况下(在S25中为“是”)，处理进入S26。

在S26中，服务器500通知第二用户。服务器500例如对移动终端UT2进行通知。服务器500通过S26的通知来请求第二用户将车辆1交付给第一用户。此外，服务器500通过S26的通知来请求第二用户回复车辆1和第二用户各自的状况。

当上述S26的处理被执行时，处理进入S31。此外，在当前时刻为第二使用期间外(在S21中为“否”)且车辆1未被第二用户使用的情况下(在S25中为“否”)，处理进入S31而不进行对第二用户的通知(S26)。

在S31中，服务器500判断是否需要车辆1的维护。在本实施方式中，在上述的车辆1的使用后(例如，晚上)进行的部件检验中，在任一个部件中发现了异常的情况下，在S31中判断为“是”，在任何部件中均未发现异常的情况下，在S31中判断为“否”。

在判断为需要车辆1的维护的情况下(在S31中为“是”)，服务器500在S32中执行车辆1的涉及维护的处理。另一方面，在判断为不需要车辆1的维护的情况下(在S31中为“否”)，图7所示的一系列处理结束，处理返回至最初的步骤(S11)而不进行车辆维护(S32)。

在S32中，执行以下说明的图8所示的一系列处理。图8是用于对由服务器500执行的车辆1的涉及维护的处理的详情进行说明的流程图。

参照图1～图6以及图8，在S201中，针对发现了异常的车辆1的部件(参照图7的S31)，服务器500进行维护的委托和报告。

具体而言，服务器500在S201中发送对发现了异常的车辆1的部件的维护(例如，修理或更换)进行委托的信号(以下，也称为“委托信号”)。服务器500也可以向维护商的终端发送委托信号。服务器500也可以向正使用车辆1的用户所携带的移动终端UT1或UT2发送委托信号。并且，正使用车辆1的用户可以向维护商委托维护。

此外，服务器500在S201中使规定的报告装置(例如，HMI230)执行报告进行车辆1的维护的意思的报告处理。服务器500也可以使移动终端UT1和UT2分别执行上述报告处理。

在接下来的S202中，服务器500判断在S201中委托的维护是否完成。然后，服务器500等待直至维护完成为止(在S202中为“否”)。在等待中，服务器500也可以受理维护的结果(履历)的输入。服务器500也可以基于维护的结果是否被输入至服务器500来判断维护是否完成。在维护完成的情况下(在S202中为“是”)，服务器500在S203中将维护的履历(例如，维护的日期时间、被维护的部件以及维护的内容)记录于存储装置503。维护商可以通过HMI504向服务器500输入维护的结果(履历)。

在接下来的S204中，服务器500获取上述维护所花费的费用(维护费用)。服务器500可以从维护商的终端接收维护费用。或者，服务器500也可以基于规定的费用表来求出维护费用。费用表可以预先存储于存储装置503。

在接下来的S205中，服务器500获取图6中的表T2所示的第一部件分类～第六部件分类中被维护的部件(例如，被修理或更换的部件)的种类所属的部件分类(维护部件分类)。

在接下来的S206中，服务器500获取各用户的车辆1的用途所属的用途分类。在本实施方式中，获取第一用途分类来作为第一用户的用途分类(第一用户用途分类)，获取第二用途分类来作为第二用户的用途分类(第二用户用途分类)。

在接下来的S207中，服务器500使用在S205中获取到的维护部件分类、在S206中获取到的各用户的用途分类、图6中的表T1所示的用户信息以及图6中的表T2所示的费用负担信息来决定维护费用的按每个用户的负担比例。具体而言，服务器500从在S205中获取到的维护部件分类以及在S206中获取到的第一用户用途分类和第二用户用途分类中获取第一比例(通过费用负担信息示出的各用户的费用负担比例)。例如，在S205中获取到的维护部件分类是第二部件分类的情况下，服务器500获取“2∶8”来作为第一比例(第一用户∶第二用户)。此外，服务器500获取“5∶2”来作为用户信息所示的第二比例(第一用户∶第二用户)。然后，服务器500将第一比例与第二比例相乘，由此获得“10∶16(＝5∶8)”这一比例。服务器500将该计算结果(比例“5∶8”)决定为最终的费用负担比例(第一用户∶第二用户)。

在接下来的S208中，服务器500基于在S207中决定出的各用户的费用负担比例来对第一用户和第二用户中的至少一方进行维护费用的请求。服务器500例如对移动终端UT1和UT2中的至少一方进行费用请求的通知。例如，在S204中获取到的维护费用为13万日元，并且在S207中决定出的费用负担比例(第一用户∶第二用户)为“5∶8”的情况下，服务器500通过对移动终端UT1的上述通知来对第一用户请求5万日元，通过对移动终端UT2的上述通知来对第二用户请求8万日元。各用户也可以按照无现金结算的引导来操作移动终端UT1或UT2，由此通过无现金结算来进行维护费用的支付。需要说明的是，在被维护的部件是按用途区分的内饰件的情况下，服务器500仅对第一用户或第二用户中的一方进行维护费用的请求。

当上述S208的处理被执行时，图8所示的一系列处理结束。然后，处理返回至图7的最初的步骤(S11)。

如以上说明的那样，本实施方式的汽车共享方法包括图7和图8各自所示的处理。

在图7所示的处理中，服务器500执行用于向第一用户提供车辆1的第一提供处理(S11～S14、S21、S25以及S26)。此外，在第一用户使用了车辆1之后，服务器500执行用于向第二用户提供车辆1的第二提供处理(S21～S24、S11、S15以及S16)。

上述第一提供处理包括：在第一使用期间内第一用户未使用车辆1的情况下(在S11中为“是”且在S12中为“否”)，服务器500催促第一用户使用车辆1(S14)；以及在第一使用期间内第二用户正使用车辆1的情况下(在S21中为“否”且在S25中为“是”)，服务器500请求第二用户将车辆1交付给第一用户(S26)。

上述第二提供处理包括：在设定于第一使用期间之后的第二使用期间内第二用户未使用车辆1的情况下(在S21中为“是”且在S22中为“否”)，服务器500催促第二用户使用车辆1(S24)；以及在第二使用期间内第一用户正使用车辆1的情况下(在S11中为“否”且在S15中为“是”)，服务器500请求第一用户将车辆1交付给第二用户(S16)。

在图8所示的处理中，在车辆1中进行了部件的维护时，服务器500执行用于基于被维护的部件的种类和按每个用户的车辆1的使用方式来决定该维护所花费的费用的按每个用户的负担比例的处理(决定处理)(S205～S207)。

上述决定处理包括：服务器500获取费用负担信息(图6)所示的多个部件分类中被维护的部件的种类所属的维护部件分类(S205)；服务器500获取费用负担信息(图6)所示的多个用途分类中第一用户的车辆1的用途所属的第一用户用途分类(S206)；服务器500获取费用负担信息(图6)所示的多个用途分类中第二用户的车辆1的用途所属的第二用户用途分类(S206)；服务器500使用获取到的维护部件分类、第一用户用途分类以及第二用户用途分类来获取第一用户和第二用户的费用负担比例(S207)；以及服务器500使用获取到的费用负担比例来决定维护所花费的费用的按每个用户的负担比例(S207)。

根据上述的汽车共享方法，在被多个用户共用的一台车辆中进行了部件的维护时，能公平地决定按每个用户的费用负担比例。

在上述实施方式中，由两个用户共用一台车辆。但不限于此，汽车共享中的用户的人数可以适当变更，也可以是三人以上。也可以与汽车共享的形式匹配地分别变更上述实施方式中的用户信息和费用负担信息。图9是表示图6所示的用户信息和费用负担信息的变形例的图。

该变形例的用户信息通过图9中的表T3示出。在表T3中，“U－1”、“U－2”、“U－3”、“U－4”分别相当于第一用户、第二用户、第三用户、第四用户的用户ID。针对第一用户～第四用户的每一个，用户信息示出车辆1的使用期间(第一使用期间～第四使用期间)和车辆1的用途(第一用途～第四用途)。在本实施方式中，第一用途、第二用途、第三用途、第四用途分别是移动办公用途、旅客运送用途、物流用途、医疗用途。此外，第一使用期间是星期一，第二使用期间是星期二/星期三，第三使用期间是星期四/星期五，第四使用期间是周末(星期六/星期天)。第一用户对车辆1的使用时间为1天/周，第二用户对车辆1的使用时间为2天/周，第三用户对车辆1的使用时间为2天/周，第四用户对车辆1的使用时间为2天/周。如此，按每个用户的车辆1的使用时间通过用户信息示出。

该变形例的费用负担信息通过图9中的表T4示出。由费用负担信息规定的多个部件分类包括与通用的内饰件相关的第一部件分类、与驱动系统的部件相关的第二部件分类、与悬架170相关的第三部件分类、与电池160相关的第四部件分类、与第一用途内饰件相关的第五部件分类、与第二用途内饰件相关的第六部件分类、与第三用途内饰件相关的第七部件分类以及与第四用途内饰件相关的第八部件分类。需要说明的是，通用的内饰件是在第一用途～第四用途的全部中使用的内饰件。

由费用负担信息规定的多个用途分类包括与办公用途相关的第一用途分类、与旅客运送用途相关的第二用途分类、与物流用途相关的第三用途分类以及与医疗用途相关的第四用途分类。即，第一用户的用途(第一用途)属于第一用途分类，第二用户的用途(第二用途)属于第二用途分类，第三用户的用途(第三用途)属于第三用途分类，第四用户的用途(第四用途)属于第四用途分类。

在该变形例中，费用负担信息示出办公用途的用户(第一用户)、旅客运送用途的用户(第二用户)、物流用途的用户(第三用户)以及医疗用途的用户(第四用户)的费用负担比例。该费用负担比例如图9中的表T4所示，根据部件的劣化倾向来确定。例如，若将旅客运送用途与物流用途进行比较，则具有如下倾向：内饰件、驱动系统的部件、悬架关联部件以及蓄电装置的部件均在物流用途中更容易劣化。若将旅客运送用途与医疗用途进行比较，则具有如下倾向：驱动系统的部件和悬架关联部件分别在旅客运送用途中更容易劣化，蓄电装置的部件在医疗用途中更容易劣化。若将办公用途与医疗用途进行比较，则具有如下倾向：驱动系统的部件、悬架关联部件以及蓄电装置的部件均在医疗用途中更容易劣化。按用途区分的内饰件的维护所花费的费用由以对应的用途使用了车辆1的用户全额负担。

根据上述变形例的用户信息和费用负担信息，在由第一用户～第四用户共用的一台车辆中进行了部件的维护时，能公平地决定第一用户～第四用户的费用负担比例。

在上述实施方式中，在决定处理(决定维护所花费的费用的按每个用户的负担比例的处理)中，将各用户的车辆1的使用方式(更确定地说，用途)分类为费用负担信息(图9)所示的任一个用途分类。但是，在决定处理中不一定使用费用负担信息。例如，服务器500也可以执行以下说明的图10所示的一系列处理来代替图8所示的处理。

图10是表示图8所示的处理的变形例的流程图。在图10所示的处理中，除了采用S207A来代替S205～S207(图8)以外，以图8所示的处理为准。以下，对S207A进行说明。

参照图1～图6以及图10，在S207A中，服务器500基于各用户的车辆1的使用方式来决定维护所花费的费用的按每个用户的负担比例。具体而言，服务器500针对第一用户和第二用户各自的车辆1的使用方式，评价使被维护的部件劣化了何种程度。然后，服务器500增大以使被维护的部件容易劣化的方式使用了车辆1的用户(即，使被维护的部件劣化的程度大的用户)的费用负担比例。

服务器500也可以从车辆1接收在自动驾驶中(参照图3)记录的车辆1的状态。服务器500也可以基于在被第一用户使用时通过车辆1的各种传感器检测到的车辆1的状态的推移，来推定起因于第一用户的使用的部件的劣化进度。此外，服务器500也可以基于在被第二用户使用时通过车辆1的各种传感器检测到的车辆1的状态的推移，来推定起因于第二用户的使用的部件的劣化进度。例如，急起步或急制动的频度越高，驱动系统的部件越容易劣化。此外，充放电频度越高，电池160越容易劣化。也可以是，服务器500还使用各用户的用途来推定起因于各用户的使用的部件的劣化进度。

在上述变形例的汽车共享方法中，服务器500在车辆1中进行了部件的维护时，按每个用户获取起因于车辆1的使用的该部件的劣化进度，并使用按每个用户的部件的劣化进度来决定部件的维护所花费的费用的按每个用户的负担比例(S207A)。通过这样的汽车共享方法，也能公平地决定按每个用户的费用负担比例。

在上述实施方式和变形例中，采用内部部署(on-premises)服务器来作为服务器500(参照图1)。但是不限于此，也可以通过云计算在云上实现服务器500的功能的至少一部分。此外，服务器500的功能的至少一部分也可以在车辆或移动终端中实现。

车辆的构成不限于上述实施方式中说明的构成(参照图1、图2、图4以及图5)。基础车辆也可以在无加装的状态下具有自动驾驶功能。自动驾驶的等级既可以是完全自动驾驶(等级5)，也可以是附带条件的自动驾驶(例如，等级4)。车辆的构成也可以适当变更为无人行驶专用的构成。例如，无人行驶专用的车辆也可以不具备用于供人对车辆进行操作的部件(方向盘等)。不过，应用上述的汽车共享系统和汽车共享方法的车辆不限定于自动驾驶车辆。

车辆可以具备太阳能板，也可以具备飞行功能。车辆不限于轿车，也可以是公共汽车或卡车。车辆也可以是个人所有的车辆(POV)。车辆也可以是根据用户的使用目的而定制的多目的车辆。车辆也可以是移动店铺车辆、无人输送车(AGV)或农业机械。车辆也可以是无人或单人乘坐的小型BEV(例如微型托盘车(Micro-Palette))。

上述的实施方式和各变形例也可以任意地组合来实施。

应该认为此次公开的实施方式在所有方面均为示例性的而非限制性的。通过本公开示出的技术的范围通过权利要求书示出，而不通过上述的实施方式的说明示出，意图在于包括与权利要求书等同的意义和范围内的所有变更。