CN110520877B - 维护通知系统及其控制方法以及介质 - Google Patents

Abstract

维护通知系统具有：积存单元，其收集并积存多台车辆各自的车辆状况信息和针对所述多台车辆各自的驾驶历史信息；生成单元，其使用由所述积存单元积存的信息来生成为了预测应进行维护的时机而使用的指标信息；确定单元，其基于成为维护对象的对象车辆的状况信息以及驾驶历史信息和由所述生成单元生成的指标信息，确定该对象车辆的应进行维护的时机；以及通知单元，其基于由所述确定单元确定的应进行维护的时机来进行与该维护相关的通知。

Description

维护通知系统及其控制方法以及介质

技术领域

本发明涉及维护通知系统及其控制方法以及介质。

背景技术

以往，公开有如下发明(专利文献1等)：通过积存车辆数据并将该数据以及维护(故障修理)信息登录于服务器，从而对具有类似数据的驾驶员进行故障预测。

现有技术文献

专利文献

专利文献1：日本特开2004-272375号公报

发明内容

发明所要解决的问题

如专利文献1所示，已知有如下技术：通过使用发生过故障的车辆的数据，并通过向具有类似的数据的车辆通知来进行故障预测。但是，不仅因车辆的数据，还会因驾驶员的驾驶特性(驾驶方式等)的不同，使车辆的适当的维护时机产生差异。

因此，在本发明中，其目的在于，能够基于车辆数据和驾驶员的操作信息判断针对车辆的适当的维护时机，进而提供对于车辆的操作者而言更高精度的维护通知。

用于解决问题的方法

为了解决上述问题，本发明具有以下的构成。即，一种维护通知系统，其特征在于，具有：

积存单元，其收集并积存多台车辆各自的车辆状况信息和针对所述多台车辆各自的驾驶历史信息；

生成单元，其使用由所述积存单元积存的信息来生成为了确定应进行维护的时机而使用的指标信息；

第一推断单元，其基于成为维护对象的对象车辆的状况信息以及驾驶历史信息中的至少任一者来推断该对象车辆的状态；

第二推断单元，其基于所述对象车辆的状况信息来推断该对象车辆的用户的维修的倾向；

确定单元，其基于所述对象车辆的状况信息以及驾驶历史信息中的至少任一者，从由所述生成单元生成的指标信息之中选择在确定该对象车辆的应进行维护的时机时使用的指标信息，并使用由所述第一推断单元推断出的状态、由所述第二推断单元推断出的所述车辆对象的用户的维修的倾向、和选择出的所述指标信息来确定所述对象车辆的应进行维护的时机以及内容；以及

通知单元，其基于由所述确定单元确定的应进行维护的时机以及内容来进行与该维护相关的通知。

发明效果

根据本发明，能够提供对于车辆的操作者而言更高精度的维护通知。

发明的其它特征以及优点以附图为参照并由以下的说明予以明确。此外，在附图中，对相同或者同样的构成标注相同的附图标记。

附图说明

附图包含于说明书而构成其一部分，表示本发明的实施方式，与其记述一并用于说明本发明的原理。

图1是表示本发明所涉及的系统构成的例子的图。

图2是表示本发明所涉及的服务器以及信息处理装置的硬件构成的例子的图。

图3是表示本发明所涉及的车辆的硬件构成的例子的图。

图4是表示本发明所涉及的服务器的软件构成的例子的图。

图5是本发明所涉及的系统的时序图。

图6是表示本发明所涉及的服务器中的处理的流程图。

具体实施方式

以下，使用附图对本发明所涉及的一实施方式进行说明。此外，以下所示的构成等仅是一例，并不限于此。

＜第一实施方式＞

[系统构成]

图1是表示本实施方式所涉及的维护通知系统中的系统整体的构成例的图。本实施方式所涉及的维护通知系统构成为包括服务器10、信息处理装置20以及多台车辆30。服务器10、信息处理装置20经由因特网60而连接为能够通信。另外，车辆30也通过经由接入点50的无线通信而能够通信地连接于因特网60。

此外，为了使车辆30能够进行无线通信，也可以通过车载或车辆30的操作者能够保存的便携终端来实现通信功能。此处的便携终端相当于智能手机、平板电脑等设备，但并不限于此，也可以是其它设备。另外，在车辆30(或便携终端)中构成为，以移动介质40保存各种信息，从而除经由接入点50的通信以外，还能够将移动介质40的信息提供给信息处理装置20等。信息处理装置20例如是PC(Personal Computer)等普通的计算机，对于其构成没有特别的限定。在本实施方式中，举出自动两轮车(所谓的摩托车)为例来说明车辆30。

此外，在图1中，车辆30以外的各设备仅各示出了一个，但并不限于该构成，可以根据需要而具备多个设备。另外，并非由一台服务器10来处理各处理，而可以根据功能、服务而在多个设备中进行分散处理。对于车辆30也并不限于图1所示的构成，而可以包括更多的车辆，另外，这些特性(车种、装备品等)可以不一定相同。

[硬件构成]

图2是表示本发明所涉及的服务器10以及信息处理装置20的硬件构成的例子的图。此外，在此，将服务器10与信息处理装置20的硬件构成设为相同，并以服务器10为例进行说明。

服务器10构成为包括CPU101、ROM102、RAM103、外部存储部104、显示部105、输入部106以及通信部107。各部位被连接为能够经由总线100进行通信。

CPU101负责服务器10的整体控制，通过读出并执行外部存储部104等中所储存的程序，来实现本发明所涉及的处理等。ROM102是非易失性的存储区域，保存各种程序、数据。RAM103是易失性的存储区域，被用作程序的执行时的工作区等。外部存储部104是非易失性的存储区域，例如保存在本发明所涉及的处理中使用的各种程序、数据。显示部105是用于显示各种画面的部位。输入部106是用于供用户等输入各种信息、设定的部位。通信部107是进行与外部装置的通信的部位，通信方法不限有线/无线。

图3是表示本发明所涉及的车辆30的硬件构成的例子的图。车辆30构成为包括处理部301、存储部302、检测部303、UI部304、通信部305以及驱动部306。处理部301负责本实施方式所涉及的处理的整体控制。此外，如上述那样，在本实施方式中，举出车辆30为自动两轮车的例子而进行说明，但是自动两轮车的行驶等的控制可以构成为独立于处理部301中的处理。

存储部302是非易失性的存储区域，保存本实施方式所涉及的各种数据。在本实施方式中，存储部302构成为能够相对于车辆30装拆的移动介质，例如，与还能够连接于信息处理装置20的USB连接等对应。检测部303是本实施方式所涉及的车辆30具备的对各种动作进行检测的检测单元(传感器)，其种类以及功能、检测方法不限。作为检测单元检测的信息的例子，可举出加速踏板或制动器的动作、燃料的余量、车身的倾斜度、行驶中或停止中的环境信息(气温、湿度等)、对车身的冲击、把手的朝向、消耗构件(轮胎、燃料等)的状态等。由检测部303检测到的信息可以作为原始数据而保存于存储部302，也可以在由处理部301处理为加工数据的基础上保存于存储部302。

UI部304是用于从车辆30中的用户等接受各种信息、指示的部位。通信部305是进行与外部装置的无线通信的部位，其通信方式没有特别地限定。另外，经由通信部305收发的数据、通信时机也没有特别地限定。驱动部306是负责与车辆的行驶等相关的驱动以及操作的部位。此外，驱动部306包括把手、制动器等部位，省略此处的详细的说明。

此外，在本实施方式中，虽然将处理部301、存储部302、UI部304、或通信部305作为车辆30具备的构成而进行了说明，但并不限于此。例如，也可以使用车载的装置(汽车导航装置等)、智能手机等便携终端等来实现这些功能。

[软件构成]

图4是表示本发明所涉及的服务器10的软件构成的例子的图。服务器10构成为包括车辆状况信息获取部201、驾驶历史信息获取部202、积存数据处理部203、部件管理部204、车辆信息管理部205、用户信息管理部206、维护预测部207、以及维护通知部208。

车辆状况信息获取部201从车辆30(或经由信息处理装置20)获取车辆状况信息。车辆状况信息是指，与安装于车辆30的部件相关的信息(包括更换时期、消耗程度)、与管理车辆30的用户实际进行的维护相关的信息。此外，与维护相关的信息也可以包括与给油的时机、量相关的信息。另外，此处的与维护相关的信息的提供者并不限于车辆30的管理者(所有者)，例如，也可以是负责维护作业的销售店、进行车检的工厂等的负责人。车辆状况信息获取部201在经由信息处理装置20获取信息的情况下，可以向信息处理装置20提供作为Web应用的输入画面，并经由该输入画面接受数据的输入。

驾驶历史信息获取部202从车辆30(或经由信息处理装置20)获取驾驶历史信息。驾驶历史信息是指，与用户对车辆30进行的驾驶的历史相关的信息(包括行驶路线、行驶距离、驾驶频率、操作历史等)。另外，操作历史也可以包括制动器和加速踏板的控制、齿轮的变更、对把手的操作、速度的变化、车身的倾斜方式、连续乘车时间、驾驶时的天气等。驾驶历史信息获取部202在经由信息处理装置20获取信息的情况下，可以向信息处理装置20提供作为Web应用的输入画面，并经由该输入画面接受数据的输入。

积存数据处理部203根据从多台车辆30收集(获取)而积存的数据来生成与对车辆(以及车辆具备的各部件)的维护相关的指标。此处的指标相当于与操作历史和部件的消耗相关的相关关系、用于确定适合操作历史的部件的种类的判断基准等。例如，积存数据处理部203从所积存的数据之中确定并获取具有相同或者类似的车辆且车辆的利用目的、频率或操作方法(操作的倾向)相近的其他用户所进行的维护历史。然后，积存数据处理部203基于这些信息来求出(生成)用于判断合适的维护的时期、对象的基准。此外，相关关系的求法、适合操作历史的部件的种类的求法没有特别地限定，可以通过公知的统计方法、机器学习、深度学习、与预先定义的阈值(消耗期限信息、与经年性老化相关的信息)的比较等来决定。另外，指标并不限于一个，可以根据对积存数据的处理而设置多个指标。另外，可以设为由车辆的用户指定所使用的积存数据的种类、指标的种类。

部件管理部204管理能够安装于各车辆的各部件的信息。作为部件信息，例如相当于部件的类别(种类)、性能、用途、消耗程度的倾向、普及程度、价格、制造商等。另外，此处的部件信息并不限于轮胎、车镜等部件，可以包括机油、燃料的性能等。另外，对于部件信息，除了例如制造商提供的信息以外，还可以根据由积存数据处理部203处理过的信息来进行更新。

车辆信息管理部205管理各车辆的车辆信息。此处的车辆信息相当于车辆所固有的信息(制造编号、机种)等信息。另外，车辆信息包括每台车辆的、由车辆状况信息获取部201获取到的车辆状况信息、以及由驾驶历史信息获取部202获取到的驾驶历史信息。

用户信息管理部206管理作为各车辆的管理者的用户的用户信息。作为用户信息，可以包括用户的嗜好、目前具有的车辆的信息、到目前为止具有过的(或操作过的)车辆的信息。或者也可以包括与感兴趣的车辆相关的信息。关于用户信息，也可以包括用户预先设定的内容，例如，包括后述的维护通知的通知目的地信息。

维护预测部207基于由部件管理部204、车辆信息管理部205以及用户信息管理部206管理的信息以及由积存数据处理部203处理过的指标，进行与对车辆30的维护相关的预测。关于此处的详情将在后面叙述，例如，预测维护对象的部件、部位、时机(时期)等。

维护通知部208基于由维护预测部207预测的信息来对用户进行维护信息的通知。此处的通知目的地被在由用户信息管理部206管理的用户信息中示出。作为通知方法可举出邮件、信件等，但并不限于这些。

[处理时序]

图5是表示本实施方式所涉及的维护通知系统中的处理的时序的图。

在S501中，车辆30适时记录车辆状况信息以及驾驶历史信息。此外，各信息的记录并非必须同时进行，记录的周期、记录的时机可以各自不同。就记录的时机而言，可以按照预先定义的间隔进行记录，也可以在进行规定的动作(操作)后进行记录。例如，可以在车辆30侧对进行了维护(例如，更换了部件)的情况进行检测并记录该信息。

在S502中，车辆30将所记录的车辆状况信息以及驾驶历史信息发送给服务器10。此外，各信息的发送并非必须同时进行，可以仅发送任一方信息。另外，就发送的时机而言，例如可以在积存了规定量的数据的情况下、或在从上次的发送起经过了规定期间的时机下进行发送。另外，可以在能够进行无线通信的时机下集中发送，也可以分割地进行发送。

在S511中，信息处理装置20通过来自用户的输入或者经由移动介质40的连接的输入来接受车辆状况信息以及驾驶历史信息的输入。

在S512中，信息处理装置20对服务器10发送所输入的各信息。此外，也可以在信息处理装置20内管理发送历史。如上述那样，也可以由服务器10对信息处理装置20提供用于输入各信息的画面(例如，基于Web应用的画面)。

在S531中，服务器10在任意的时机下接受来自用户的用户信息以及车辆信息的输入以及更新，并进行登录。用户信息以及车辆信息的更新时机并没有特别地限定，用户根据需要进行即可。

在S532中，服务器10获取部件信息。就部件信息而言，可以获取由服务器10的管理者、制造商等提供的信息，也可以通过与外部服务器(未图示)进行通信而定期地获取。

在S533中，服务器10获取从车辆30或信息处理装置20发送来的各种信息。对于所获取的信息，除了在车辆信息管理部205中与车辆30关联地进行保存以外，还根据信息的种类分类而作为积存数据进行保存。

在S534中，服务器10进行对积存数据的处理。具体而言，通过积存数据处理部203并使用积存数据来生成在判断维护的内容、时期时使用的指标。此外，本处理步骤并不限于在接收到各种信息的时机进行。例如，可以在从上次处理起经过了规定的时间后进行处理，也可以在接到服务器10的管理者的指示时执行。另外，也可以在有规定量的数据更新(追加)后执行。即，随着时间的经过，从多台车辆依次收集并更新数据，因此根据该数据的收集状况以及处理状况来使后述的维护预测中使用的信息(指标)逐渐进行变化。

在S535中，对于成为维护预测的对象的某一车辆30(对象车辆)，服务器10基于根据车辆30的各种信息以及在S533中进行的处理求出的信息(指标)来进行与维护相关的预测处理。关于本处理的详细内容将在后面使用图6进行叙述。本步骤可以与S534的处理的执行时机分别进行，可以按照规定的时间间隔执行，也可以在S532中接收到各种信息时执行。本实施方式的预测处理除了决定维护的内容以外，还决定通知的时机(时期)。

在S536中，服务器10对用户通知由S535的处理求出的维护信息通知。在此，向与车辆30的信息关联的用户信息所表示的通知目的地发送维护信息。例如，在作为通知目的地而在用户信息登录有邮件地址的情况下，服务器10向通知目的地发送包括维护信息的邮件。本通知的时机可以按照用户所设定的间隔进行通知(例如，每天一次)，针对紧急度高的通知，也可以即时通知。

在S541中，用户在任意的时机下进行用户信息以及车辆信息的输入以及更新。如上述那样，用户信息以及车辆信息的更新时机并没有特别限定，用户根据需要进行即可。另外，在进行了对车辆的维护后，进行适时输入。另外，此处的输入/更新并不一定限于车辆的管理者(所有者)，也可以由车辆的销售者等来进行。另外，各信息的输入画面也可以作为应用(例如，Web应用)由服务器10进行提供。另外，在本实施方式中的以维护通知为起因而进行了维护的情况下，也可以一并登录该信息。

在S542中，用户接收从服务器10通知的维护信息。例如，利用便携终端(未图示)来接收邮件。进一步地，用户显示所接收的维护信息。

[处理流程]

(维护预测处理)

以下，使用图6对本实施方式所涉及的服务器10中的维护预测处理进行说明。通过在服务器10中由CPU101读取并执行外部存储部104等所储存的程序来实现本处理流程。此外，以下所示的处理的流程仅为一例，可以根据需要更换顺序。

在S601中，服务器10从由车辆信息管理部205管理的信息之中获取作为进行维护预测处理的对象的车辆的车辆状况信息。作为在此获取的信息，可以仅获取最新的信息，也可以获取包括规定的范围内的过程信息。

在S602中，服务器10从由车辆信息管理部205管理的信息之中获取作为进行维护预测处理的对象的车辆的驾驶历史信息。

在S603中，服务器10获取积存数据处理部203根据积存数据而生成的指标信息。作为指标信息，可以从车辆的车辆状况信息、驾驶历史信息之中将规定的项目作为关键字而仅获取相关的信息。

在S604中，服务器10基于所获取的各信息推断车辆的状态。就此处的车辆的状态而言，可以将由车辆状况信息表示的信息直接处理为车辆的状态，也可以从多个项目推断某一部位(零件)、功能的状态。例如，可以根据与轮胎相关的上次的更换时期、行驶距离、用户的车辆的利用目的、以及用户的操作倾向来推断轮胎的状态(例如，消耗程度)。进一步地，在本步骤中，可以确定操作车辆的用户的特性。例如，可以根据驾驶历史信息所表示的行驶路线、频率来推断该车辆的使用目的，也可以对用户的驾驶技术的变化(提高、降低)进行推断。另外，也可以根据过去的用户的维护状况、部件的更换历史等来推断用户对车辆的收支(花费情况)，从而推断对车辆的经济负担的期待值。

在S605中，服务器10基于在S604中推断出的车辆的状态和在S603中获取到的指标信息，确定对车辆的维护的时期以及内容的候选。作为此处的候选，在“X日以内”进行“制动油的补给”、在“Y个月以内”进行“轮胎的更换”等不限于相同的部位(部件、消耗品)而对多个维护内容的候选进行确定。

在S606中，服务器10从由用户信息管理部206管理的信息之中获取作为进行维护预测处理的对象的车辆的用户的用户信息。

在S607中，服务器10基于用户信息从在S606中确定的候选之中决定应在当前时间点向用户提供的维护的内容。例如，可以必须对紧急度高的维护的内容进行通知，也可以对用户在上次的维护中进行的部分降低通知的优先度而使其它通知优先。另外，在用户在当前时间点完成暂时不利用车辆的意思的设定的情况下，可以不进行通知。

在S608中，服务器10判断是否进行与所决定的维护的内容相关的进一步的信息的提供。此处的判断例如可以基于用户的设定，也可以根据维护的内容来进行判断。在本实施方式中，作为进一步的信息，对提供能够在维护中利用的(可更换的)部件的信息的例子进行说明。在判断为提供进一步的信息的情况(在S608中为是)下进入到S609，在判断为不提供进一步的信息的情况(在S608中为否)下结束本处理流程。

在S609中，服务器10获取部件管理部204管理的部件信息。在此，可以根据维护的内容、用户信息来决定要获取的信息。例如，在S605中确定为需要轮胎的维护的情况下，获取与轮胎相关的信息(例如，产品名、销售店、性能信息)。

在S610中，服务器10从所获取的部件信息之中决定与维护信息一并提供的信息。例如，根据在用户设定中设定的用户的喜好、所推断的用户的特性(技术水平、使用目的)等来决定合适的部件的信息。另外，可以基于积存数据来确定与推断的用户的特性相同或者类似的用户，并将该用户正在使用的部件决定为推荐部件。之后，结束本处理流程。

[本实施方式所涉及的信息的例子]

对在本实施方式所涉及的系统中处理的信息的一个例子进行说明。如上述那样在本实施方式中，为了进行与车辆相关的维护通知，使用本车辆的车辆状况信息以及驾驶历史信息。进一步地，使用通过对从本车辆以外收集到的车辆状况信息以及驾驶历史信息进行处理而得到的信息(指标)以及与部件相关的信息。

作为车辆状况信息，可举出以下那样的信息。各部件的更换历史、安装的部件的种类以及性能、给油的时机以及次数等。

作为驾驶历史信息，可举出以下那样的信息。加速踏板、制动器的操作历史、齿轮的变更次数、车身的倾斜方式、操作中的姿态、操作中的重心移动、操作次数、操作时间、行驶距离、事故(冲击、振动)的有无、操作频率、从上次操作起到下次操作为止的时间间隔、行驶场所、在道路上的行驶位置等。

作为指标信息，可举出用于根据操作者的驾驶历史信息来确定该驾驶员的驾驶倾向的类别分类。例如，可举出将操作者分为多个类别A(安全驾驶倾向)、类别B(速度优先倾向)、以及类别C(追尾驾驶倾向)等那样的类别。这通过对积存数据进行处理而根据操作历史生成多个类别。类别的分类可以由人预先给予，也可以自动生成。进一步地，与各类别建立关联，根据积存数据来求出维护的倾向、利用的部件等。由此，对于进行某一维护预测的对象的用户，能够根据该用户的操作倾向和指标信息来确定适当的维护时期、推荐的部件等。

根据上述，作为指标信息，例如可以是“对于具有某一操作倾向的用户(类别A)，在消耗部件A(例如，轮胎)的消耗程度被推断为X％的情况下，推荐在Y日以内进行更换”这样的信息。另外，也可以是“在从上次操作起经过了Z个月以上的情况下，推荐部件W的更换”这样的信息。另外，也可以使用“将相对于加速的次数而制动的次数为规定比例以上的倾向的用户的与操作相关的特性设为类别C”这样的类别划分的操作倾向的类似性来作为指标信息。

作为部件信息，相当于部件的性能以及功能、制造商等。此外，在维护通知中，通知的内容并不限于部件，因此例如可以根据服务内容等通知内容来变更管理的信息。

以上，根据本实施方式，通过基于车辆数据和驾驶员的操作信息来判断对车辆的适当的维护时机，能够提供对于车辆的操作者而言更高精度的维护通知。

＜第二实施方式＞

在第一实施方式中，作为维护信息的通知目的地，是对于在用户信息中被设定为通知目的地的车辆的用户(管理者)来进行通知。并不限于此，也可以向其它规定的通知目的地进行通知(信息共享)。例如，也可以向车辆的制造商、能够进行维护的工厂、销售店等进行通知。在该情况下，一并提供过去的维护信息、用户信息(喜好等)。

另外，作为通知目的地，除了用户所登录的通知目的地以外，还可以基于用户的操作倾向、频率等，向类似性高的其他用户利用的店铺进行通知。

进一步地，接受了该通知的通知目的地也可以利用该信息来提供与维护相关的进一步的服务(例如，符合喜好的部件信息的提供、针对维护日程的预约处理的效率化等)。

由此，不仅是车辆的用户，其他相关者也能够得到与维护相关的部件等的信息，从而能够提高维护的效率。另外，能够实现基于车辆的操作历史及其操作倾向的信息的共享，能够提高用户的便利性。

＜其它实施方式＞

在上述的实施方式中，虽然进行了与部件的消耗等相应的维护，但并不限于此。例如，可以提供与事故历史、驾照的等级相应的维护信息。另外，可以考虑用户自身的维护的频率、工厂等用户以外的维护的频率的比例，并考虑用户是否自行维护来切换通知内容。进一步地，也可以基于该信息，不仅推断操作倾向，还推断维护的倾向(维护技术)来切换通知内容。例如，针对即便乘车本身的频率低而维护(例如改造等)的频率高这样的用户，可以进行与该内容相应的通知。

另外，也可以从用户预先接受对车辆能够支出的预算的信息，并基于该信息来提供部件的信息。

另外，也可以考虑车检、汽车损伤赔偿责任保险的期间等预先确定的期间，在临近该期间的情况下发送维护信息、或者相反地不发送维护信息。

另外，也可以在车辆为二手车(所有者变更数次的车辆)的情况等下，能够基于底盘编号等将该车辆本身的历史移交给新的用户。

另外，也可以在车辆之间进行通信，并包括其通信频率、行驶间隔(车间距离)等而记录驾驶历史信息。

另外，在第二实施方式中，作为信息的共享目的地的例子，举出了制造商、维护工厂等，但是除此以外，例如还可以是进行与用于进行因特网购物的EC站点之间的协作那样的构成。在该情况下，相当于与用户的操作历史、喜好、操作倾向匹配地从EC站点提供各种商品的信息。

＜实施方式的总结＞

1.上述实施方式的维护通知系统(例如，10)的特征在于，

所述维护通知系统具有：

积存单元(例如，201、202、205)，其收集并积存多台车辆各自的车辆状况信息和针对所述多台车辆各自的驾驶历史信息；

生成单元(例如，203)，其使用由所述积存单元积存的信息来生成为了预测应进行维护的时机而使用的指标信息；

确定单元(例如，207)，其基于成为维护对象的对象车辆的状况信息以及驾驶历史信息和由所述生成单元生成的指标信息，确定该对象车辆的应进行维护的时机；以及

通知单元(例如，208)，其基于由所述确定单元确定的应进行维护的时机来进行与该维护相关的通知。

根据该实施方式，对于车辆的用户而言能够提供更高精度的维护通知。

2.上述实施方式的维护通知系统的特征在于，

所述状况信息包括对车辆进行维护的历史，

所述生成单元基于所述驾驶历史信息和进行所述维护的历史，生成用于推断车辆具备的部件的消耗程度的指标信息。

根据该实施方式，能够进行反映了维护的历史的更高精度的维护通知。

3.上述实施方式的维护通知系统的特征在于，

所述生成单元基于所述驾驶历史信息来生成用于进行与用户的操作的倾向对应的多个类别划分的一个或者多个指标信息。

根据该实施方式，能够进行按照用户的操作的每个特性的维护通知。

4.上述实施方式的维护通知系统的特征在于，

所述确定单元基于所述驾驶历史信息和所述指标信息来确定具有与所述对象车辆的用户相同或者类似的操作的倾向的用户。

根据该实施方式，能够基于与自身相同或者类似的用户的信息来接受维护通知。

5.上述实施方式的维护通知系统的特征在于，

所述确定单元基于所述具有相同或者类似的操作的倾向的用户进行维护的历史来确定所述对象车辆的应进行维护的时机。

根据该实施方式，能够基于与自身相同或者类似的用户的信息来接受维护通知。

6.上述实施方式的维护通知系统的特征在于，

所述积存单元经由因特网(例如，60)而从所述多台车辆分别收集所述状况信息以及所述驾驶历史信息。

根据该实施方式，能够经由外部网络而更多地收集在维护通知时使用的数据。

7.上述实施方式的维护通知系统的特征在于，

所述状况信息包括是否对与所述维护相关的通知进行了应对的信息。

根据该实施方式，能够收集用户对维护通知的应对结果，从而能够实现反映了该信息的进一步的维护通知。

8.上述实施方式的维护通知系统的特征在于，

所述确定单元根据用户的设定来切换在确定应进行维护的时机时使用的指标信息。

根据该实施方式，能够进行按照用户的意向的维护通知。

9.上述实施方式的维护通知系统的特征在于，

所述确定单元进一步地基于所述对象车辆的状况信息以及驾驶历史信息来确定与维护相关的部件的信息(例如，204)，

所述通知单元进一步地通知所确定的所述部件的信息。

根据该实施方式，能够进行用户的便利性更高的维护通知。

10.上述实施方式的维护通知系统的特征在于，

所述通知单元进一步地基于所述对象车辆的状况信息以及驾驶历史信息向所述对象车辆的用户以外的通知目的地通知与该维护相关的信息。

根据该实施方式，还能够在与车辆的用户不同的用户等中进行与维护相关的信息共享。

11.上述实施方式的维护通知系统的控制方法的特征在于，

所述维护通知系统的控制方法具有如下步骤：

积存步骤，在该积存步骤中，收集并积存多台车辆各自的车辆状况信息和针对所述多台车辆各自的驾驶历史信息；

生成步骤，在该生成步骤中，使用在所述积存步骤中积存的信息来生成为了预测应进行维护的时机而使用的指标信息；

确定步骤，在该确定步骤中，基于成为维护对象的对象车辆的状况信息以及驾驶历史信息和在所述生成步骤中生成的指标信息，确定该对象车辆的应进行维护的时机；以及

通知步骤，在该通知步骤中，基于在所述确定步骤中确定的应进行维护的时机来进行与该维护相关的通知。

根据该实施方式，能够提供对于车辆的用户而言更高精度的维护通知。

12.上述实施方式的程序的特征在于，

该程序使计算机作为积存单元、生成单元、确定单元、通知单元而发挥功能，

所述积存单元收集并积存多台车辆各自的车辆状况信息和针对所述多台车辆各自的驾驶历史信息，

所述生成单元使用由所述积存单元积存的信息来生成为了预测应进行维护的时机而使用的指标信息，

所述确定单元基于成为维护对象的对象车辆的状况信息以及驾驶历史信息和由所述生成单元生成的指标信息，确定该对象车辆的应进行维护的时机，

所述通知单元基于由所述确定单元确定的应进行维护的时机来进行与该维护相关的通知。

根据该实施方式，能够提供对于车辆的用户而言更高精度的维护通知。

本发明并不限于上述实施方式，在不脱离本发明的精神以及范围的前提下，能够加以各种变更以及变形。因此，为了公开本发明的范围，附加以下的技术方案。

Claims (14)

1.一种维护通知系统，其特征在于，

所述维护通知系统具有：

积存单元，其收集并积存多台车辆各自的车辆状况信息和针对所述多台车辆各自的驾驶历史信息，所述车辆状况信息包括与所述多台车辆各自的维护历史相关的信息；

生成单元，其使用由所述积存单元积存的信息来生成为了确定应进行维护的时机而使用的指标信息，所述指标信息包括所述驾驶历史信息和车辆的部件的消耗之间的相关关系；

第一推断单元，其基于成为维护对象的对象车辆的状况信息以及驾驶历史信息中的至少任一者来推断该对象车辆的状态；

第二推断单元，其基于所述对象车辆的状况信息来推断该对象车辆的用户的维修的倾向；

确定单元，其基于所述对象车辆的状况信息以及驾驶历史信息中的至少任一者，从由所述生成单元生成的指标信息之中选择在确定该对象车辆的应进行维护的时机时使用的指标信息，并使用由所述第一推断单元推断出的所述对象车辆的状态、由所述第二推断单元推断出的所述对象车辆的用户的维修的倾向、和选择出的所述指标信息来确定所述对象车辆的应进行维护的时机以及内容；以及

通知单元，其基于由所述确定单元确定的应进行维护的时机以及内容来进行与该维护相关的通知，

所述通知的内容根据所述用户自身的维护的频率和工厂等所述用户以外的维护的频率的比例来进行切换。

2.根据权利要求1所述的维护通知系统，其特征在于，

所述生成单元基于所述驾驶历史信息来生成用于进行与用户的操作的倾向对应的多个类别划分的一个或者多个指标信息。

3.根据权利要求1所述的维护通知系统，其特征在于，

所述确定单元基于所述驾驶历史信息和所述指标信息来确定具有与所述对象车辆的用户相同或者类似的操作的倾向的用户。

4.根据权利要求3所述的维护通知系统，其特征在于，

所述确定单元基于所述具有相同或者类似的操作的倾向的用户进行维护的历史来确定所述对象车辆的应进行维护的时机。

5.根据权利要求1所述的维护通知系统，其特征在于，

所述积存单元经由因特网而从所述多台车辆分别收集所述状况信息以及所述驾驶历史信息。

6.根据权利要求1所述的维护通知系统，其特征在于，

所述状况信息包括是否对与所述维护相关的通知进行了应对的信息。

7.根据权利要求1所述的维护通知系统，其特征在于，

所述确定单元根据用户的设定来切换在确定应进行维护的时机时使用的指标信息。

8.根据权利要求1所述的维护通知系统，其特征在于，

所述确定单元进一步地基于所述对象车辆的状况信息以及驾驶历史信息来确定与维护相关的部件的信息，

所述通知单元进一步地通知所确定的所述部件的信息。

9.根据权利要求1所述的维护通知系统，其特征在于，

所述通知单元进一步地基于所述对象车辆的状况信息以及驾驶历史信息向所述对象车辆的用户以外的通知目的地通知与该维护相关的信息。

10.根据权利要求1所述的维护通知系统，其特征在于，

所述通知单元将与所述维护相关的通知向能够应对该维护的通知目的地进行通知，由此请求该通知目的地中的所述维护的预约处理。

11.根据权利要求1所述的维护通知系统，其特征在于，

基于如下信息中的至少任一者来控制与所述维护相关的通知的时机以及内容：所述对象车辆的用户的事故历史、驾照的信息、所述对象车辆的保险信息、所述对象车辆的车检信息、所述对象车辆的过去的用户的信息。

12.根据权利要求1所述的维护通知系统，其特征在于，

所述通知单元将与所述维护相关的通知向能够提供在该维护中使用的部件的通知目的地进行通知，由此请求向所述对象车辆的用户提供与该通知目的地所能够提供的能够在所述维护中使用的部件相关的信息。

13.一种维护通知系统的控制方法，其特征在于，

所述维护通知系统的控制方法具有如下步骤：

积存步骤，在该积存步骤中，收集并积存多台车辆各自的车辆状况信息和针对所述多台车辆各自的驾驶历史信息，所述车辆状况信息包括与所述多台车辆各自的维护历史相关的信息；

生成步骤，在该生成步骤中，使用在所述积存步骤中积存的信息来生成为了确定应进行维护的时机而使用的指标信息，所述指标信息包括所述驾驶历史信息和车辆的部件的消耗之间的相关关系；

第一推断步骤，在该第一推断步骤中，基于成为维护对象的对象车辆的状况信息以及驾驶历史信息中的至少任一者来推断该对象车辆的状态；

第二推断步骤，在该第二推断步骤中，基于所述对象车辆的状况信息来推断该对象车辆的用户的维修的倾向；

确定步骤，在该确定步骤中，基于所述对象车辆的状况信息以及驾驶历史信息中的至少任一者，从在所述生成步骤中生成的指标信息之中选择在确定该对象车辆的应进行维护的时机时使用的指标信息，并使用在所述第一推断步骤中推断出的所述对象车辆的状态、在所述第二推断步骤中推断出的所述对象车辆的用户的维修的倾向、和选择出的所述指标信息来确定所述对象车辆的应进行维护的时机以及内容；以及

通知步骤，在该通知步骤中，基于在所述确定步骤中确定的应进行维护的时机以及内容来进行与该维护相关的通知，

所述通知的内容根据所述用户自身的维护的频率和工厂等所述用户以外的维护的频率的比例来进行切换。

14.一种介质，其存储程序，其特征在于，

该程序使计算机作为积存单元、生成单元、第一推断单元、第二推断单元、确定单元、通知单元而发挥功能，

所述积存单元收集并积存多台车辆各自的车辆状况信息和针对所述多台车辆各自的驾驶历史信息，所述车辆状况信息包括与所述多台车辆各自的维护历史相关的信息，

所述生成单元使用由所述积存单元积存的信息来生成为了确定应进行维护的时机而使用的指标信息，所述指标信息包括所述驾驶历史信息和车辆的部件的消耗之间的相关关系，

所述第一推断单元基于成为维护对象的对象车辆的状况信息以及驾驶历史信息中的至少任一者来推断该对象车辆的状态，

所述第二推断单元基于所述对象车辆的状况信息来推断该对象车辆的用户的维修的倾向，

所述确定单元基于所述对象车辆的状况信息以及驾驶历史信息中的至少任一者，从由所述生成单元生成的指标信息之中选择在确定该对象车辆的应进行维护的时机时使用的指标信息，并使用由所述第一推断单元推断出的所述对象车辆的状态、由所述第二推断单元推断出的所述对象车辆的用户的维修的倾向、和选择出的所述指标信息来确定所述对象车辆的应进行维护的时机以及内容，

所述通知单元基于由所述确定单元确定的应进行维护的时机以及内容来进行与该维护相关的通知，

所述通知的内容根据所述用户自身的维护的频率和工厂等所述用户以外的维护的频率的比例来进行切换。

Images