CN111369012A - 一种用于在线上到线下服务中识别受损车辆的系统和方法 - Google Patents

Abstract

一种用于识别受损车辆的方法可以包括接收检查车辆的请求。该方法还可以包括获得与所述车辆相关的多个第一确定特征的特征值。该方法还可以包括基于第一预测模型和第一确定特征的特征值来确定车辆是否被损坏。其中，基于包含所述第一确定特征的多个历史损坏车辆，获得所述第一预测模型。该方法还可以包括第一电子信号发送到电子设备，指示所述电子设备显示与所述车辆是否损坏相关的至少一个第一消息。本申请利用机器学习模型预测O2O服务中车辆是否受损，可以有效和准确地识别受损车辆，提升了服务过程中用户的体验。

Description

一种用于在线上到线下服务中识别受损车辆的系统和方法

技术领域

本申请涉及线上到线下(O2O)服务领域，特别涉及一种在O2O服务平台中识别虚假车辆报修请求和/或识别的受损车辆的系统和方法。

背景技术

随着互联网技术的发展，在线按需或共享服务等O2O服务在人们的日常生活中发挥着越来越重要的作用。以车辆按需服务或车辆共享服务为例，在一些情况下，用户想要在开始使用车辆前知道车辆是否已损坏。O2O服务平台需要在车辆被使用之前识别出是否损坏。在其他一些情况下，O2O服务平台的用户可以在用户操作车辆期间或之前向O2O服务平台提交车辆报修请求。在一些情况下，O2O服务平台需要确定车辆报修请求是真实报修请求还是虚假报修请求后，再开始进一步处理。因此，有必要提供一种用于识别虚假车辆报修请求的系统和方法以避免潜在的恶意虚假报修请求和/或一种用于在O2O服务平台中识别受损车辆的系统和方法，以改善O2O服务平台的用户体验。

发明内容

本申请实施例之一提供一种用于在线上到线下服务中识别虚假车辆报修请求的方法。所述方法在至少一个处理器和至少一个存储器上实现。所述方法包括从用户处接收车辆报修请求。所述方法还包括基于该车辆报修请求，获得与该用户或该车辆相关的多个确定特征的特征值。所述方法还包括基于预测模型和该特征值，判断该车辆报修请求是否为虚假报修请求，其中，基于包含该确定特征的多个历史车辆报修请求，获得该预测模型。所述方法还包括将电子信号发送给与该用户相关的移动设备，其中，该电子信号指示该移动设备显示与该车辆报修请求是否为虚假报修请求相关的至少一个消息。

在一些实施例中，所述车辆报修请求包括所述用户获得的至少一个车辆图像。所述基于所述预测模型和所述特征值，判断所述车辆报修请求是否为虚假报修请求包括：判断所述车辆图像是否与所述车辆对应；基于所述车辆图像与所述车辆对应，利用所述预测模型，判断所述车辆图像中的所述车辆是否损坏；以及基于所述车辆图像中的所述车辆是否损坏的判断，确定所述车辆报修请求是否为虚假报修请求。

在一些实施例中，所述车辆报修请求是在所述用户试图操作所述车辆之后产生的，其中，所述确定特征包括以下中的至少一个：所述用户操作所述车辆的时长、所述用户使用所述车辆行驶的距离、所述用户开始操作所述车辆的时间点、所述车辆被操作的次数、与所述车辆相关的车辆报修请求次数、所述车辆的投放时间、与所述线上到线下服务的历史订单相关的信息、与所述历史订单中已完成订单相关的信息、所述用户行驶的总距离、所述用户车辆报修请求的总数、所述历史车辆报修请求中真实报修请求的数量或所述真实报修请求在所述历史车辆报修请求中的比率。

在一些实施例中，所述车辆是自行车。

在一些实施例中，基于所述车辆报修请求是虚假报修请求，所述电子信号还指示所述移动设备禁止所述用户操作与所述线上到线下服务相关的任何车辆。

在一些实施例中，基于所述车辆报修请求是真实报修请求，所述至少一个消息还包括至少一个电子优惠券。

本申请实施例之一提供一种用于在线上到线下服务中识别虚假车辆报修请求的系统。所述系统包括获取模块，确定模块和传输模块。所述获取模块用于从用户处接收车辆报修请求，并获得与所述用户或所述车辆相关的多个确定特征的特征值。所述确定模块用于基于预测模型和所述特征值，判断所述车辆报修请求是否为虚假报修请求，其中，基于包含所述确定特征的多个历史车辆报修请求，获得所述预测模型。所述传输模块用于将电子信号发送给与所述用户相关的移动设备，其中，所述电子信号指示所述移动设备显示与所述车辆报修请求是否为虚假报修请求相关的至少一个消息。

本申请实施例之一提供一种用于在线上到线下服务中识别虚假车辆报修请求的装置，包括处理器，所述处理器用于执行用于在线上到线下服务中识别虚假车辆报修请求的方法。

本申请实施例之一提供一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行用于在线上到线下服务中识别虚假车辆报修请求的方法。

本申请实施例之一提供一种用于在线上到线下服务中识别虚假车辆报修请求的系统。所述系统包括至少一个存储设备和与所述至少一个存储设备通信的至少一个处理器。所述存储设备包括一组指令集。当执行所述指令集时，所述至少一个处理器用于：从用户处接收车辆报修请求；基于所述车辆报修请求,获得与所述用户或所述车辆相关的多个确定特征的特征值；基于预测模型和所述特征值，判断所述车辆报修请求是否为虚假报修请求，其中，基于包含所述确定特征的多个历史车辆报修请求，获得所述预测模型；以及将电子信号发送给与所述用户相关的移动设备，其中，所述电子信号指示所述移动设备显示与所述车辆报修请求是否为虚假报修请求相关的至少一个消息。

本申请实施例之一提供一种用于识别受损车辆的方法。所述方法在至少一个处理器和至少一个存储器上实现。所述方法包括接收检查车辆请求。所述方法还包括基于该检查车辆请求，获得与该车辆相关的多个第一确定特征的特征值。所述方法还包括基于第一预测模型和该第一确定特征的特征值，判断该车辆是否损坏，其中，基于包含该第一确定特征的多个历史损坏车辆，获得该第一预测模型。所述方法还包括将第一电子信号发送到电子设备，指示该电子设备显示与该车辆是否损坏相关的至少一个第一消息。

在一些实施例中，所述接收检查车辆请求包括：接收第一用户打开所述车辆车锁的请求。

在一些实施例中，所述接收检查车辆请求包括：确定第一用户准备在线上到线下服务中发起订单，其中，所述车辆位于所述第一用户的预设距离内。

在一些实施例中，所述电子设备与所述第一用户或运维人员相关。

在一些实施例中，与所述车辆相关的所述第一确定特征包括车辆报修请求，所述车辆报修请求从第二用户接收。基于所述车辆已损坏，所述方法还包括：基于所述车辆报修请求，确定所述车辆的至少一个损坏部位；以及将第二电子信号发送到所述电子设备，指示所述电子设备显示与所述车辆的至少一个损坏部位相关的至少一个第二消息。

在一些实施例中，所述接收所述检查车辆请求包括：从第二用户接收所述车辆的车辆报修请求；以及确定所述车辆报修请求是真实车辆报修请求。

在一些实施例中，所述确定所述车辆报修请求是否为真实车辆报修请求，包括：获得与所述第二用户或所述车辆相关的多个第二确定特征的特征值；以及基于第二预测模型和所述第二确定特征的特征值，判断所述车辆报修请求是否为真实车辆报修请求，其中，基于包含所述第二确定特征的多个历史车辆报修请求，获得所述第二预测模型。

在一些实施例中，所述车辆报修请求包括所述第二用户获得的至少一个车辆图像。所述基于所述第二预测模型和所述第二确定特征的特征值，判断所述车辆报修请求是否为真实报修请求包括：判断所述至少一个车辆图像是否与所述车辆对应；基于所述至少一个车辆图像与所述车辆对应，利用所述第二预测模型，判断所述至少一个车辆图像中的所述车辆是否损坏；以及基于所述至少一个车辆图像中的所述车辆是否损坏的判断，确定所述车辆报修请求是否为真实报修请求。

在一些实施例中所述车辆是自行车。

本申请实施例之一提供一种用于识别受损车辆的系统。所述系统包括获取模块，确定模块和传输模块。所述获取模块用于接收检查车辆请求，并获得与所述车辆相关的多个第一确定特征的特征值。所述确定模块用于基于第一预测模型和所述第一确定特征的特征值，判断所述车辆是否损坏，其中，基于包含所述第一确定特征的多个历史损坏车辆，获得所述第一预测模型。所述传输模块用于将第一电子信号发送到电子设备，指示所述电子设备显示与所述车辆是否损坏相关的至少一个第一消息。

本申请实施例之一提供一种用于识别受损车辆的装置，包括处理器，所述处理器用于执行用于识别受损车辆的方法。

本申请实施例之一提供一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行用于识别受损车辆的方法。

本申请实施例之一提供一种用于识别受损车辆的系统。所述系统包括至少一个存储设备和与所述至少一个存储设备通信的至少一个处理器。所述存储设备包括一组指令集。当执行所述指令集时，所述至少一个处理器用于：接收检查车辆请求；基于所述检查车辆请求，获得与所述车辆相关的多个第一确定特征的特征值；基于第一预测模型和所述第一确定特征的特征值，判断所述车辆是否损坏，其中，基于包含所述第一确定特征的多个历史损坏车辆，获得所述第一预测模型；以及将第一电子信号发送到电子设备，指示所述电子设备显示与所述车辆是否损坏相关的至少一个第一消息。

本发明的有益效果表现如下：

利用机器学习模型预测O2O服务中车辆报修请求的真假以及车辆是否受损，有效避免了潜在的恶意虚假报修和准确地识别受损车辆，提升了服务过程中用户的体验。

附图说明

本申请将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：

图1是根据本申请的一些实施例所示的示例性O2O服务系统的示意图；

图2是根据本申请的一些实施例所示的可以在其上实现处理引擎的计算设备的示例性硬件和软件组件的示意图；

图3是根据本申请的一些实施例所示的可以在其上实现终端设备的移动设备的示例性硬件和/或软件组件的示意图；

图4是根据本申请的一些实施例的示例性处理引擎的框图；

图5是根据本申请的一些实施例所示的用于识别虚假车辆报修请求的示例性过程的流程图；以及

图6是根据本申请的一些实施例所示的用于识别受损车辆的示例性过程的流程图。

具体实施方式

为了更清楚地说明本申请的实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。然而，本领域技术人员应该明白，可以在没有这些细节的情况下实施本申请。在其他情况下，为了避免不必要地模糊本发明的各方面，已经在相对较高的级别上概略地描述了众所周知的方法、过程、系统、组件和/或电路。对于本领域的普通技术人员来讲，显然可以对所披露的实施例作出各种改变，并且在不偏离本申请的原则和范围的情况下，本申请中所定义的普遍原则可以适用于其他实施例和应用场景。因此，本申请不限于所示的实施例，而是符合与申请专利范围一致的最广泛范围。

本申请中所使用的术语仅仅用来描述特定的示例性实施例，并不旨在对其进行。如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可以包括复数。可以进一步理解的是，术语“包括”与“包含”是指存在多个明确标识的特征、整数、步骤、步骤、元件和/或组件，但并不排除呈现或添加至少一个其他特征、整数、步骤、步骤、元件和/或组件，和/或它们的组合。

应当理解，这里使用的术语“系统”、“引擎”、“单元”、“模块”和/或“块”是以降序区分不同级别的不同组件、元件、部件、部分或组件的一种方法。但是，若这些术语达到同样的目的，则可能会被另一个术语所取代。

通常，这里使用的词语“模块”、“单元”或“块”是指体现在硬件或固件中的逻辑，或者是软件指令的集合。这里描述的模块，单元或块可以实现为软件和/或硬件，并且可以存储在任何类型的非暂时性计算机可读介质或其他存储设备中。在一些实施例中，可以编译软件模块/单元/块并将其链接到可执行程序中。应当理解，软件模块可以从其他模块/单元/块或从它们自身调用，和/或可以响应检测到的事件或中断来调用。被配置用于在计算设备上执行的软件模块/单元/块可以在计算机可读介质上提供，例如光盘、数字视频光盘、闪存驱动器、磁盘或任何其他有形介质，或作为数字下载(并且最初可以以压缩或可安装的格式存储，在执行之前需要安装，解压缩或解密)。这里的软件代码可以被部分的或全部的储存在执行操作的计算设备的存储设备中，并应用在计算设备的操作之中。软件指令可以嵌入固件中，例如可擦除可编程只读存储器(EPROM)。还应当理解，硬件模块/单元/块可以包括在连接的逻辑组件中，例如门和触发器，和/或可以包括在可编程单元中，例如可编程门阵列或处理器。这里描述的模块/单元/块或计算设备功能可以实现为软件模块/单元/块，但是可以用硬件或固件表示。通常，这里描述的模块/单元/块指的是逻辑模块/单元/块，其可以与其他模块/单元/块组合或者分成子模块/子单元/子块，不管它们的物理组织或存储。该描述可适用于系统、引擎或其一部分。

应当理解，当单元、引擎、模块或块被称为“接通”、“连接到”或“耦合到”另一个单元、引擎、模块或块时，除非上下文另有明确说明，否则它可以直接位于其他单元、引擎、模块或块上，连接或耦合或与其通信，或者可以存在中间单元、引擎、模块或块。在本申请中，术语“和/或”可以包括任何至少一个相关所列条目或其组合。

通过以下对附图的描述，本申请的这些和其他的特征、特点以及相关结构元件的功能和操作方法，以及部件组合和制造经济性，可以变得更加显而易见，这些附图都构成本申请说明书的一部分。然而，应当理解的是，附图仅仅是为了说明和描述的目的，并不旨在限制本申请的范围。应当理解的是，附图并不是按比例绘制的。

本申请中使用流程图用来说明根据本申请的一些实施例的系统所执行的操作。应当理解的是，流程图中的操作可以不按顺序执行。相反，可以按照相反的顺序或同时处理各种步骤。此外，可以向流程图添加至少一个其他操作。也可以从流程图中删除至少一个操作。

本申请的系统或方法可以应用于任何类型的O2O服务，例如按需服务和/或共享服务。例如，本申请的系统和方法可以应用于不同的运输系统，包括陆地、海洋、航空航天等或其任意组合。运输系统中使用的车辆可以包括出租车、私家车、顺风车、公共汽车、火车、动车、高铁、地铁、船舶、飞机、宇宙飞船、热气球、无人驾驶车辆、自行车、三轮车、推车、轮椅、独轮车、双人自行车、摩托车、电动自行车、轻便摩托车、机动三轮车、电动三轮车等或其任何组合。在一些实施方案中，本申请所述车辆是指自行车或电动自行车。又例如，O2O按需或共享服务的服务对象可以是例如保险箱、行李箱、雨伞、健身器材等或其任何组合的任何其他东西，。本申请的系统或方法的应用场景可以包括网页、浏览器插件、客户端、客户系统、内部分析系统、人工智能机器人等或其任意组合。

本申请的一个方面，提供了一种用于在O2O服务平台中识别虚车辆假报修请求的系统和方法。从服务请求者收到车辆的报修请求后，系统可以基于与该服务请求者或该车辆相关的多个确定特征的特征值和第一预测模型，来判断该车辆报修请求是否为虚假报修请求。若该车辆报修请求为真实报修请求，系统可以向服务请求者提供奖励。例如，系统可以向服务请求者发送免费乘坐的电子优惠券。若该车辆报修请求为虚假报修请求，系统可以向服务请求者提供警报。例如，系统可以将电子信号发送到服务请求者的终端，以指示终端禁止服务请求者请求O2O服务。

本申请的另一方面，提供了一种用于在O2O服务平台中识别受损车辆的系统和方法。在收到检查车辆的请求后，系统可以基于第二预测模型和与车辆相关的特征值来确定车辆是否被损坏。系统还可以将电子信号发送到服务请求者或运维人员的电子设备。电子信号可以指示电子设备显示与车辆是否损坏有关的至少一个的消息。

图1是根据本申请的一些实施例所示的示例性O2O服务系统的示意图。O2O服务系统100可以包括服务器110、网络120、至少一个终端设备130、至少一个服务设备140、存储设备150和定位设备160。服务设备140可以通过锁170保护。O2O服务系统100可以是用于提供按需或共享服务的线上到线下系统。

在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。服务器组可以是经由分别经由一个接入点连接到网络120的集中式服务器组或由一个或多个接入点连接到网络120的分布式服务器组。在一些实施例中，服务器110可以本地连接到网络120或者与网络120远程连接。例如，服务器110可以经由网络120访问存储在终端设备130、服务设备140、存储设备150和/或锁170中的信息和/或数据。又例如，存储设备150可以用作服务器110的后端数据存储。在一些实施例中，服务器110可以在云平台上实施。仅作为示例，该云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。

在一些实施例中，服务器110可以包括处理引擎112。处理引擎112可以处理与本申请中执行至少一个功能相关的信息和/或数据。例如，处理引擎112可以确定从终端设备130发送的服务设备140(例如，自行车)的报修请求是否为虚假报修请求。又例如，处理引擎112可识别服务设备140是否已损坏。在一些实施例中，处理引擎112可以包括至少一个处理单元(例如，单核处理引擎或多核处理引擎)。例如，处理引擎112可以包括中央处理器(CPU)、专用集成电路(ASIC)、应用专用指令集处理器(ASIP)、图像处理器(GPU)、物理处理单元(PPU)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑设备(PLD)、控制器、微控制器单元、精简指令集计算机(RISC)、微处理器等或其任意组合。

网络120可以促进信息和/或数据的交换。在一些实施例中，O2O服务系统100的至少一个组件(例如，服务器110、终端设备130、服务设备140、存储设备150或锁170)可以经由网络120将信息和/或数据发送到O2O服务系统100中的另一个组件。例如，服务器110可以经由网络120向终端设备130发送指示服务设备140是否已经损坏的消息。

在一些实施例中，网络120可以是任何类型的有线网络或无线网络或其任意组合。仅作为示例，网络120可以包括电缆网络、有线网络、光纤网络、电信网络、内部网络、互联网、局域网络(LAN)、广域网络(WAN)、无线局域网络(WLAN)、城域网(MAN)、公共开关电话网络(PSTN)、蓝牙网络、紫蜂(Zigbee)网络、近场通信(NFC)网络等或其任意组合。在一些实施例中，网络120可以包括至少一个网络接入点。例如，网络120可以包括有线或无线网络接入点，例如基站和/或互联网交换点120-1、120-2、...，O2O服务系统100的至少一个组件可以通过该网络接入点连接到网络120以交换数据和/或信息。

在一些实施例中，终端设备130可以包括移动设备130-1、平板计算机130-2、便携式计算机130-3等或其任何组合。在一些实施例中，移动设备130-1可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器控制设备、智能监控设备、智能电视、智能摄像机、对讲机等，或其任意组合。在一些实施例中，可穿戴设备可以包括智能手环、智能鞋带、智能眼镜、智能头盔、智能手表、智能服装、智能背包、智能配件等或其任何组合。在一些实施例中，智能移动设备可以包括智能手机、个人数字助理(PDA)、游戏设备、导航设备、销售点(POS)设备、人工智能机器人等或其任何组合。在一些实施例中，虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强现实头盔、增强现实眼镜、增强现实眼罩等，或其任意组合。例如，虚拟现实设备和/或增强现实设备可以包括GoogleGlass^TM、OculusRift^TM、Hololens^TM或GearVR^TM等。在一些实施例中，终端设备130可以包括信号发送器和信号接收器，用于与定位设备160通信以定位用户和/或终端设备130的位置。例如，终端设备130可以向定位设备160发送指令以定位用户和/或终端设备130的位置。

服务设备140可以被配置用于在O2O服务系统100中使用。服务设备140可以是任何对象。例如，服务设备140可以是车辆，例如出租车、私家车、顺风车、公共汽车、火车、动车、高铁、地铁、船舶、飞机、宇宙飞船、热气球、无人驾驶车辆、自行车、三轮车、推车、轮椅、独轮车、双人自行车、摩托车、电动自行车、轻便摩托车、机动三轮车、电动三轮车等或其任何组合。又例如，服务设备140可以是保险箱、行李箱、雨伞、健身器材等。

锁170可以用于保护服务设备140。锁170可以包括实现其功能的任何一个或组合的机构。锁170可以是机械锁、智能锁、电子锁等。服务设备140和锁170可以是彼此机械连接的单独部件。例如，服务设备140和锁170可以是单独的部件，并且锁170可以安装在服务设备140上。附加地或可选地，服务设备140和锁可以形成整体设备。可以用唯一标识符(ID)识别服务设备140和/或锁170。唯一ID可以包括条形码、快速响应(QR)码、包括字母和/或数字的序列号等或其任何组合。

在一些实施例中，服务设备140和/或锁170可以与或不与O2O服务系统100的至少一个组件(例如，服务器110、终端设备130和/或定位设备160)通信。例如，锁170可以是机械锁，并且不与O2O服务系统100的至少一个组件通信。又例如，服务设备140和/或锁170可以包括全球定位系统(GPS)组件。服务设备140和/或锁170可以与定位设备160通信以定位服务设备140和/或锁170的位置，并经由网络120实时地将锁170和/或服务设备140的位置发送到服务器110。

存储设备150可以存储数据和/或指令。在一些实施例中，存储设备150可以存储从终端设备130、服务器110、服务设备140或锁170获得的数据。例如，存储设备150可以存储从终端设备130获得的服务设备140的报修请求。在一些实施例中，存储设备150可以存储服务器110用来执行或使用来完成本申请中描述的示例性方法的数据和/或指令。例如，存储设备150可以存储服务器110可以执行或使用的数据和/或指令，以确定服务设备140是否被损坏。在一些实施例中，存储设备150可以包括大容量存储器、可移动存储器、易失性读写内存、只读存储器(ROM)等或其任意组合。示例性的大容量存储器可以包括磁盘、光盘、固态磁盘等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘、磁带等。示例性易失性读写存储器可以包括随机存取存储器(RAM)。示例性RAM可以包括动态随机存取存储器(DRAM)、双倍数据速率同步动态随机存取存储器(DDRSDRAM)、静态随机存取存储器(SRAM)、晶闸管随机存取存储器(T-RAM)和零电容随机存取存储器(Z-RAM)等。示例性ROM可以包括掩模型只读存储器(MROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(PEROM)、电可擦除可编程只读存储器(EEPROM)、光盘只读存储器(CD-ROM)和数字多功能磁盘只读存储器等。在一些实施例中，该存储设备150可以在云平台上实现。仅作为示例，该云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。在一些实施例中，存储设备150可以是服务器110的一部分。

定位设备160可以确定与对象相关的信息，例如，至少一个终端设备130、锁170或服务设备140(例如，自行车)。例如，定位设备160可以确定终端设备130、锁170和/或服务设备140的当前时间和当前位置。在一些实施例中，定位设备160可以是全球定位系统(GPS)、全球导航卫星系统(GLONASS)、罗盘导航系统(COMPASS)、北斗导航卫星系统、伽利略定位系统、准天顶卫星系统(QZSS)等。该信息可以包括对象的位置、高度、速度或加速度，和/或当前时间。该位置可以是坐标的形式，例如纬度坐标和经度坐标等。定位设备160可以包括至少一个的卫星，例如卫星160-1、卫星160-2和卫星160-3。卫星160-1至卫星160-3可以独立地或共同地确定上述信息。定位设备160可以经由网络120将上述信息发送到终端设备130、锁170或服务设备140。

在一些实施例中，O2O服务系统100的至少一个组件可以经由网络120访问存储设备150中存储的数据和/或指令。在一些实施例中，存储设备150可以作为后端存储器直接连接到服务器110。在一些实施例中，O2O服务系统100的至少一个组件(例如，服务器110、终端设备130或服务设备140)可以具有访问存储设备150的权限。在一些实施例中，当满足至少一个条件时，O2O服务系统100的至少一个组件可以读取和/或修改与用户和/或服务设备140有关的信息。例如，服务器110可以在完成自行车骑行之后读取和/或修改至少一个用户的信息。

仅作为示例，服务设备140可以是自行车。O2O服务系统100可以提供自行车共享或按需租赁服务，允许用户使用自行车进行骑行。O2O服务系统100的至少一个组件之间的信息交换可以通过在终端设备130上启动O2O服务系统100的应用，发起对自行车共享或按需自行车租赁服务的服务请求(也被称为服务订单或订单)或通过终端设备130输入查询(例如，寻找可用的自行车)来触发。例如，终端设备130可以获得服务设备140和/或锁170的唯一ID(例如，服务请求者可以通过终端设备130上的应用程序的接口输入唯一ID或者通过终端设备130的相机扫描唯一ID)，并将包括唯一ID的服务请求发送到服务器100。可选地或附加地，服务请求还可以包括出发地点、目的地、出发时间等或其任何组合。服务器100可以将用于解锁服务设备140的消息发送到终端设备130、服务设备140或锁170。例如，服务器100可以将密码发送到终端设备130。服务请求者可以基于密码手动解锁服务设备140。又例如，服务器100可以向锁170发送解锁指令。锁170可以基于解锁指令自动解锁服务设备140。在服务设备140被解锁之后，服务请求者可以操作服务设备140以进行骑行。当服务请求者完成骑行并且想要返还服务设备140时，用户可以将服务设备140留在允许停放服务设备140的区域中并使用锁170锁定服务设备140。服务请求者可以支付操作车辆的费用。然后，服务设备140可以供下一个用户使用。

O2O按需或共享服务的服务请求可以是实时服务请求或预订服务请求。

实时服务请求可以是服务请求者希望在当前时刻或在对本领域技术人员来说合理地接近当前时刻的规定时间(例如，在当前时刻之后1分钟、2分钟或5分钟)接收O2O按需或共享服务(例如，解锁服务设备140)的服务请求。

预约服务请求可以指服务请求者希望在对本领域技术人员来说比当前时刻合理延长的时间(例如，当前时刻之后的15分钟、30分钟、1小时、2小时或1天)接收O2O按需或共享服务(例如，解锁服务设备140)的服务请求。

本领域的普通技术人员将理解，当O2O服务系统100的组件执行时，该组件可以通过电信号和/或电磁信号执行。例如，当处理引擎112处理任务时，例如进行确定或识别信息，处理引擎112可以在其处理器中操作逻辑电路以处理这样的任务。当处理引擎112从终端设备130接收数据(例如，服务设备140的报修请求)时，处理引擎112的处理器可以接收编码/包括数据的电信号。处理引擎112的处理器可以通过至少一个信息交换端口接收电信号。若终端设备130通过有线网络与处理引擎112通信，信息交换端口可以物理连接到电缆。若终端设备130通过无线网络与处理引擎112通信，处理引擎112的信息交换端口可以是至少一个天线，其可以将电信号转换为电磁信号。在电子设备中，例如终端设备130和/或服务器110，当处理器处理指令、发出指令和/或执行动作时，指令和/或动作通过电信号进行。例如，当处理器从存储设备(例如存储设备150)检索或保存数据时，处理器可以向存储设备的读/写设备发送电信号，该读/写设备可以在存储设备中读取或写入结构化数据。该结构数据可以通过电子设备的总线，以电信号的形式传输至处理器。该电信号可以指一个电信号、一系列电信号和/或多个不连续的电信号。

图2是根据申请的一些实施例所示的一种可以实现处理引擎112示例性计算设备的示例性硬件和软件组件的示意图。如图2所示，计算设备200可以包括处理器210、存储器220、输入/输出(I/O)230和通信端口240。

处理器210(例如，逻辑电路)可以执行计算机指令(例如，程序代码)并且根据本申请描述的技术来执行处理引擎112的功能。例如，处理器210可以包括接口电路210-a和处理电路210-b。接口电路可以用于接收来自总线(图2中未示出)的电子信号，其中电子信号编码用于处理电路的结构化数据和/或指令。处理电路可以进行逻辑计算，然后将结论、结果和/或指令编码确定为电信号。然后，接口电路可以经由总线从处理电路发出电信号。

该计算机指令可以包括例如执行在此描述的特定功能的常规、程序、对象、组件、数据结构、过程、模块和功能。例如，处理器210可以确定与终端设备130发送的与服务设备140(例如，自行车)相关的车辆报修请求是否为虚假报修请求。又例如，处理器210可识别服务设备140(例如，自行车)是否损坏并确定服务设备140(例如，自行车)的损坏部位。在一些实施例中，处理器210可以包括至少一个硬件处理器，诸如微控制器、微处理器、精简指令集计算机(RISC)、专用集成电路(ASIC)、应用专用指令集处理器(ASIP)、中央处理单元(CPU)、图形处理单元(GPU)、物理处理单元(PPU)、微控制器单元、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、高阶RISC机器(ARM)、可编程逻辑设备(PLD)、能够执行至少一个功能的任何电路或处理器等或其任何组合。

仅仅为了说明，在计算设备200中仅描述了一个处理器。然而，应该注意的是，本揭露中的计算设备200还可以包括多个处理器，由此执行的操作和/或方法步骤如本申请中所描述的一个处理器也可以由多个处理器联合地或单独地执行。例如，若在本申请中，计算设备200的处理器执行步骤A和步骤B，应当理解的是，步骤A和步骤B也可以由计算设备200的多个不同的处理器共同地或独立地执行(例如，第一处理器执行步骤A，第二处理器执行步骤B，或者第一和第二处理器共同地执行步骤A和步骤B)。

存储器220可以存储从用户终端140、存储设备150和/或O2O服务系统100的任何其他组件获得的数据/信息。在一些实施例中，存储器220可以包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器(ROM)等或其任意组合。例如，大容量存储器可以包括一磁盘、光盘、固态硬盘等。可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘和磁带等。易失性读取和写入存储器可以包括随机存取存储器(RAM)。RAM可以包括动态RAM(DRAM)、双倍速率同步动态RAM(DDRSDRAM)、静态RAM(SRAM)、晶闸管RAM(T-RAM)和零电容(Z-RAM)等。ROM可以包括掩模型只读存储器(MROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(PEROM)、电可擦除可编程只读存储器(EEPROM)、光盘只读存储器(CD-ROM)和数字多功能磁盘只读存储器等。在一些实施例中，存储器220可以存储至少一个程序和/或指令以执行在本申请中描述的示例性方法。例如，存储器220可以存储用于处理引擎112的程序，用于确定服务设备140是否已经损坏。

I/O230可以输入和/或输出信号、数据、信息等。在一些实施例中，I/O230可以使用户与处理引擎112交互。例如，O2O服务系统100的用户可以通过I/O230输入预定参数。在一些实施例中，I/O230可以包括输入设备和输出设备。示例性的输入设备可以包括键盘、鼠标、触控屏幕、麦克风等或其任何组合。示例性的输出设备可以包括显示设备、扬声器、打印机、投影仪等或其任何组合。示例性显示设备可以包括液晶显示器(LCD)、基于发光二极管(LED)的显示器、平板显示器、曲面显示器、电视设备、阴极射线管(CRT)、触控屏幕等或其任意组合。

通信端口240可以连接到网络(例如，网络120)以促进数据通信。通信端口240可以在处理引擎112、用户终端140、定位系统160或存储设备150之间建立连接。连接可以是有线连接、无线连接、可以启用数据传输和/或接收的任何其他通信连接，和/或这些连接的任何组合。有线连接可以包括例如电缆、光缆、电话线等或其任何组合。有线连接可以包括例如电缆、光缆、电话线等或其任意组合。该无线连接可以包括例如蓝牙连接、无线网连接、WiMax连接、WLAN连接、ZigBee连接、移动网络连接(例如，3G、4G、5G网络等)等或其任意组合。在一些实施例中，通信端口240可以是和/或包括标准化通信端口，诸如RS232、RS485等。

图3是根据本申请的一些实施例所示的可以实现终端设备130的移动设备的示例性硬件和/或软件组件的示意图。如图3所示，移动设备300可以包括通信平台310、显示器320、图形处理单元(GPU)330、中央处理单元(CPU)340、I/O350、内存360和存储器390。在一些实施例中，任何其他合适的组件包括但不限于系统总线或控制器(未示出)，也可以包括在移动设备300内。在一些实施例中，操作系统370(例如，iOS^TM、Android^TM、WindowsPhone^TM等)和至少一个应用程序380可从存储器390下载至内存360以及由CPU340执行。应用程序380可以包括浏览器或任何其他合适的移动应用程序，用于接收及呈现与图像处理相关的信息或处理引擎112中的其他信息。用户与信息流的交互可以通过I/O350实现，并通过网络120提供给处理引擎112和/或O2O服务系统100的其他组件。

为了实施本申请描述的各种模块、单元及其功能，计算机硬件平台可用作本文中描述之至少一个元素的硬件平台。具有用户接口元素的计算机可用于实施个人计算机(PC)或任何其他类型的工作站或终端设备。若程控得当，计算机亦可用作服务器。

图4是示出根据本申请的一些实施例的示例性处理引擎的框图。处理引擎112可以包括获取模块401、确定模块402、训练模块403和传输模块404。

获取模块401可以被配置为获得与O2O服务系统100的至少一个组件有关的信息。例如，获取模块401可以从O2O服务系统100的服务请求者处接收车辆报修请求。在一些实施例中，车辆报修请求可以通过服务请求者的终端设备130产生。车辆报修请求可以包括车辆的唯一ID、车辆的位置、服务请求者的唯一ID、车辆的损坏部位的名称、车辆的故障状况、故障等级等或其任何组合。在一些实施例中，获取模块401还可以获取与服务请求者或车辆相关的多个第一确定特征的特征值。又例如，获取模块401可以接收检查车辆请求。在一些实施例中，获取模块401还可以获得在检查车辆请求中与车辆相关的多个第二确定特征的特征值。多个第二确定特征可以包括至少一个车辆特征、至少一个车辆的历史服务订单特征、至少一个车辆的维护特征、至少一个车辆的历史车辆报修请求特征等或其任何组合。

确定模块402可以用于确定报修请求是否为虚假和/或车辆是否损坏。例如，确定模块401可以基于第一预测模型和第一确定特征的特征值来确定报修请求是否为虚假。在一些实施例中，第一确定特征的特征值可以输入到第一预测模型。第一预测模型可以输出车辆报修请求是虚假报修请求还是真实报修请求的结果。又例如，确定模块402可以基于第二预测模型和第二确定特征的特征值来确定车辆是否以损坏。在一些实施例中，第二确定特征的特征值可以输入到第二预测模型。第二预测模型可以输出与车辆是否损坏有关的结果。

训练模块403可以用于生成第一预测模型和/或第二预测模型。例如，训练模块403可以通过使用不同用户、车辆或服务订单相关的多个训练历史车辆报修请求(例如，有标记的历史车辆报修请求)训练第一初始模型(例如，极限梯度提升(XGBoost)模型)来生成第一预测模型。对于每个训练历史车辆报修请求，训练模块403可以获得与训练历史车辆报修请求有关的用户、车辆或服务订单的多个第一训练特征的特征值。在一些实施例中，训练模块403可将标记为真实历史车辆报修请求标记为1并将标记为虚假历史车辆报修请求标记为0。训练模块403可以将第一训练特征的特征值和标记的训练历史车辆报修请求输入到第一初始模型中训练，来生成第一预测模型。在一些实施例中，训练模块403可以使用多个测试历史车辆报修请求(例如，标记为历史车辆报修请求)来测试第一预测模型的准确性。又例如，训练模块403可以通过使用与训练车辆(例如，有标记的车辆)有关的历史车辆损坏信息训练第二初始模型来产生第二预测模型。对于每个训练车辆，训练模块403可以获得训练车辆的多个第二训练特征的特征值。在一些实施例中，训练模块403可将标记为损坏车辆的车辆标记为1并将标记为未损坏车辆的车辆标记为0。训练模块403可以将第二训练特征的特征值和训练车辆的标记结果输入到第二初始模型中训练，来生成第二预测模型。在一些实施例中，训练模块403可以使用测试车辆(例如，有标记的车辆)的历史车辆损坏信息来测试第二预测模型的准确性。

传输模块404可以用于在处理引擎112与O2O服务系统100的至少一个其他组件之间建立连接。连接可以是有线连接、无线连接、可以实现数据传输和/或接收的任何其他通信连接，和/或这些连接的任何组合。例如，传输模块404可以将第一电信号发送到与服务请求者相关的移动设备(例如，终端设备130)。第一电信号可以指示终端设备130显示与报修请求是否为虚假有关的至少一个第一消息。又例如，传输模块404可以将第二电信号传输到电子设备。第二电信号可以指示电子设备显示与车辆是否损坏有关的至少一个第二消息。电子设备可以与O2O服务系统100的服务请求者或运维人员相关。

这些模块可以是处理引擎112的全部或部分的硬件电路。这些模块也可以作为一个应用程序或一组由处理引擎112读取和执行的指令实现。此外，模块可以是硬件电路和应用/指令的任何组合。例如，当处理引擎112执行应用程序/一组指令时，模块可以是处理引擎112的一部分。

应当注意以上对处理引擎112的描述是出于说明的目的而提供的，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，变化和修改不会背离本申请的范围。在一些实施例中，上述任何模块可以以多个单独的单元实现。例如，确定模块402可以被分成两个单元，其中一个用于确定车辆的报修请求是否为虚假，而另一个用来以确定车辆是否被损坏。在一些实施例中，处理引擎112还可以包括至少一个附加模块(例如，存储模块)。

图5是根据本申请的一些实施例所示的用于识别虚假车辆报修请求的示例性过程的流程图。过程500的至少一部分可以在如图2所示的计算设备200或如图3所示的移动设备300上实现。在一些实施例中，过程500的至少一个操作可以在O2O服务系统100中实现，如图1所示。在一些实施例中，过程500中的至少一个操作可以作为指令的形式存储在存储设备(例如，存储设备150、存储器220、存储器390)中，并且由服务器110(例如，服务器110中的处理引擎112、计算设备200的处理器210，或图4中所示的处理引擎112中的至少一个模块)调用和/或执行。在一些实施例中，指令可以以电子电流或电信号的形式传输。以下呈现的所示过程500的操作旨在用来说明。在一些实施例中，过程500在实施时可以添加至少一个本申请未描述的额外操作，和/或删减至少一个此处所描述的操作。另外，如图5所示和下面描述的过程500的操作的顺序不是限制性的。

为简洁起见，过程500的描述可以采用车辆(例如，服务设备140是车辆)共享或租赁作为示例。应当注意下面描述的车辆共享或租赁仅仅是示例。对于本领域的普通技术人员，过程500可以应用于其他类似的情况，例如保险箱共享/租赁、伞共享/租赁等。在一些实施例中，车辆可以是自行车或电动自行车。

在510中，获取模块401(或处理引擎112，和/或接口电路210-a)可以从O2O服务系统100的服务请求者(例如，服务请求者的终端设备130)处接收服务设备140(例如，车辆)的车辆报修请求。在一些实施例中，车辆可以包括出租车、私家车、顺风车、公共汽车、火车、动车、高铁、地铁、船舶、飞机、宇宙飞船、热气球、无人驾驶车辆、自行车、三轮车、推车、轮椅、独轮车、双人自行车、摩托车、电动自行车、轻便摩托车、机动三轮车、电动三轮车等或其任何组合。

在一些实施例中，车辆的报修请求可以通过服务请求者的终端设备130产生。例如，服务请求者可以通过安装在终端设备130中的应用程序的界面输入文本、语音、图片、视频等或其任何组合，以生成报修请求。终端设备130可以经由网络120将报修请求发送到处理引擎112。

车辆报修请求可以包括车辆的唯一ID、车辆的位置、服务请求者的唯一ID、车辆的损坏部位的名称、车辆的故障状况、故障等级等或其任何组合。

以自行车为例，自行车的损坏部位可以包括轮子、链条、刹车(例如，后刹车或前刹车)、锁(例如，锁170)、QR码、车把、踏板、车座、脚撑、铃、反射器、车篮、挡泥板等或其任何组合。车辆的故障状况可以是损坏部位的详细描述。车辆的故障状况可以是文本、语音、图像、视频等或其任何组合。例如，用户可以使用终端设备130拍摄车辆的至少一个图像来描述车辆的故障状况。又例如，用户可以在终端设备130中选择至少一个模板来描述车辆的故障状况。

在一些实施例中，可以使用等级来估计车辆的损坏程度。等级可由O2O服务系统100定义。例如，故障等级可能包括轻微故障、中度故障和严重故障。轻微故障可以指不会导致车辆失去至少一个功能的故障。例如，自行车筐的轻微变形和车把套的缺失可以是轻微的故障。中度故障可以指导致车辆失去至少一个功能的故障，但是车辆仍然可以用于实现基本目的(例如，便于从一个点行驶到另一个点)。例如，铃或刹车(例如，后刹车或自行车的前刹车)不起作用的故障可以是中度故障。严重故障可以指使车辆不能使用，甚至不能用于其基本功能的故障。例如，缺少自行车的车轮或车座、自行车链条脱落的故障可以是严重故障。在一些实施例中，应用程序可以分别显示故障等级的定义和/或属于轻微故障、中度故障和严重故障的示例性故障。用户可以基于所显示的定义和/或示例性故障，来确定她/他想要报修的故障等级。

在一些实施例中，当服务请求者试图操作车辆时，服务请求者可以将车辆报修请求发送到处理引擎112。例如，若服务请求者想要操作车辆并且在服务请求者发出操作车辆的服务请求之前(例如，在车辆解锁之前)发现车辆已经损坏，服务请求者可以提出车辆报修请求并将车辆的报修请求发送到处理引擎112。又例如，在操作车辆的过程中，若服务请求者发现车辆已损坏，则服务请求者可提出报修请求并将车辆的报修请求发送至处理引擎112。作为另一个例子，若服务请求者在服务请求者完成车辆操作后发现车辆已损坏(例如，在服务请求者锁定车辆之后)，则服务请求者可以提出报修请求并将车辆的报修请求发送到处理引擎112。

在520中，获取模块401(或处理引擎112和/或接口电路210-a)可以响应于所述报修请求，获得与该服务请求者或该车辆相关的多个第一确定特征的特征值。

在一些实施例中，与服务请求者相关的第一确定特征可以是包括服务请求者发起的O2O服务系统100的历史订单(例如，包括完成的历史订单和取消的历史订单)总数、已完成的历史订单数量、取消的历史订单数量、已完成的历史订单数在历史订单总数的比率、已取消的历史订单数在历史订单总数的比率、服务请求者发送的历史车辆报修请求(例如，包括真实历史车辆报修请求和虚假历史车辆报修请求)总数、真实历史车辆报修请求(已经核实的历史车辆报修请求)的数量、虚假历史车辆报修请求(例如经检查，已证明是错误的历史车辆报修请求)的数量、真实历史车辆报修请求数量占历史车辆报修请求总数的比率、虚假历史车辆报修请求数量占历史车辆报修请求总数的比率、包含至少一个车辆图像的历史车辆报修请求的数量、包含至少一个车辆图像的历史车辆报修请求的数量占历史车辆报修请求总数的比率、服务请求者在O2O服务系统100中使用车辆的总里程数、服务请求者在O2O服务系统100中使用车辆的总时间、在报修请求中是否包含至少一个车辆图像、至少一个车辆图像是否与该车辆对应、至少一个车辆图像中的车辆是否被损坏、车辆报修请求中的车辆图像数量、对应车辆的车辆图像数量、损坏车辆的车辆图像数量、服务请求者的信用评分、服务请求者最后一次发送历史车辆报修请求的时间与当前时间之间的时间间隔等或其任何组合。

在一些实施例中，与车辆相关的第一确定特征可以是包括在O2O服务系统100中被服务请求者操作的总时间、操作的次数、与车辆对应的历史车辆报修请求(例如，包括真实历史车辆报修请求和虚假历史车辆报修请求)的数量、与车辆对应的真实历史车辆报修请求的数量、与车辆对应的虚假历史车辆报修请求的数量、真实历史车辆报修请求数量占车辆对应的历史车辆报修请求总数的比率、虚假历史车辆报修请求的数量占车辆对应的历史车辆报修请求总数的比率、车辆的标识符(ID)、车辆的总里程数、与车辆对应的包含至少一个车辆图像的历史车辆报修请求的数量、与车辆对应的包含至少一个车辆图像的历史车辆报修请求的数量占历史车辆报修请求总数的比率、车辆被操作的区域、在O2O服务系统100中车辆第一次投入使用的时间、车辆由O2O服务系统100运营的总时间、车辆运营的城市或区域、管理车辆的工作人员、车辆维修的总次数、最后一次维修与当前时间之间的间隔、车辆的最后历史车辆报修请求时间和当前时间之间的时间间隔等或其任何组合。

在一些实施例中，服务请求者可以基于服务订单在操作车辆时将报修请求发送到处理引擎112。在这种情况下，获取模块401还可以获得与服务订单相关的第一确定特征的特征值。服务订单的第一确定特征可以是包括服务请求者根据服务订单操作车辆的持续时间、服务请求者根据服务订单操作车辆的距离、服务请求者发起服务订单的时间、服务请求者操作车辆的行驶路线等或其任何组合。

在一些实施例中，第一确定特征的特征值可以与从特定时间点到当前时间(例如，获取模块401接收报告的时间)的时间段相关。例如，第一确定特征中的车辆的总里程可以指从车辆在O2O服务系统100中第一次投入使用的时间到当前时间的车辆的总里程。

在一些实施例中，第一确定特征的特征值可以是第一确定特征的特定值。例如，历史订单总数的特征值可以是总数的特定值(例如，50、100、200等)。又例如，报修请求中是否存在至少一个车辆图像的特征值可以是1(例如，表示在报修请求中存在至少一个车辆图像)或0(例如，表示报修请求中没有车辆图像)

在一些实施例中，获取模块401可以从存储设备(例如，存储设备150或处理引擎112的存储器220)获得第一确定特征的特征值。

在一些实施例中，获取模块401可以通过使用例如图像识别技术识别报修请求中的至少一个图像，来确定报修请求是否包括至少一个车辆图像。获取模块401可以确定车辆图像是否与该车辆对应。例如，获取模块401可以识别车辆图像并确定车辆的唯一ID是否在车辆图像中。若车辆的唯一ID在车辆图像中，获取模块401可以确定车辆图像与该车辆对应。若车辆的唯一ID不在车辆图像中，获取模块401可以确定车辆图像与该车辆不对应。

在一些实施例中，关于车辆图像是否与该车辆对应，车辆图像的存在可能是也可能不是决定因素，其可以由其他因素决定，例如但不限于车辆图像中的周围信息是否与该报修请求中车辆的位置对应。在一些实施例中，当难以或不可能确定车辆图像是否与该车辆对应时，可以使用默认设置(例如，存在对应关系)。

若车辆图像与该车辆对应，获取模块401可以使用例如分类模型来确定车辆图像中的车辆是否被损坏。在一些实施例中，可以通过使用未损坏车辆的车辆图像和已损坏车辆的车辆图像训练初始分类模型，来获得该分类模型。

在530中，确定模块402(或处理引擎112，和/或处理电路210-b)可以基于第一预测模型和第一确定特征的特征值，来确定报修请求是否为虚假。

在一些实施例中，第一确定特征的特征值可以输入到第一预测模型。第一预测模型可以输出车辆报修请求是虚假报修请求还是真实报修请求的结果。在一些实施例中，第一预测模型可以输出车辆报修请求为真实报修请求的概率。确定模块402可以确定概率是否大于第一概率阈值(例如，50％、60％、70％、80％等)。若概率大于第一概率阈值，确定模块402可确定车辆报修请求为真实报修请求。若概率小于或等于第一概率阈值，确定模块402可确定车辆报修请求为虚假报修请求。第一概率阈值可以由运营商或根据O2O服务系统100的默认设置来设置。

在一些实施例中，确定模块402可以基于不同类型的多个第一确定特征，来选择不同的预测模型。例如，用于处理包含至少一个车辆图像的报修请求相关的多个第一确定特征的预测模型和用于处理与没有包含车辆图像的报修请求相关的多个第一确定特征的预测模型可以是不同的。在一些实施例中，确定模块402可以使用同一个预测模型来处理不同类型的多个第一确定特征，以确定车辆报修请求是否为虚假报修请求。

在一些实施例中，上述分类模型可以与第一预测模型相同或不同。例如，分类模型可以是第一预测模型的一部分。

在一些实施例中，第一预测模型可以在线或离线生成。在一些实施例中，第一预测模型可以由处理引擎112(例如，训练模块403)或与O2O服务系统100通信的第三方设备生成。在一些实施例中，训练模块403可以预先生成第一预测模型，并将第一预测模型存储在存储设备(例如，存储设备150、处理引擎112的存储器220)中。当获取模块401接收到车辆报修请求时，确定模块402可以从存储设备获得第一预测模型。在一些实施例中，当获取模块401接收到车辆报修请求时，训练模块403可以在线生成第一预测模型。在一些实施例中，第三方设备可以预先生成第一预测模型，并在本地或在O2O服务系统100的存储设备(例如，存储设备150、处理引擎112的存储器220)中存储第一预测模型。当获取模块401接收到报修请求时，确定模块402可以从O2O服务系统100或第三方设备的存储设备获得第一预测模型。在一些实施例中，当获取模块401接收到车辆报修请求时，第三方设备可以在线生成第一预测模型，并将第一预测模型发送到确定模块402。

在一些实施例中，在处理引擎112确定车辆报修请求为真实报修请求之后，处理引擎112可以指派运维人员来修理车辆，例如通过将包含报修请求的消息发送到运维人员的终端来。若运维人员确认车辆已损坏，则报修请求可标记为已确认的真实报修请求。若运维人员确认车辆未损坏，则报修请求可被标记为已确认的虚假报修请求，并指示出第一预测模型的错误。已确认的报修请求的标记结果可以存储在存储设备(例如，存储设备150或处理引擎112的存储器220)中，并用于训练和/或更新预测模型。

仅作为示例，训练模块403可以通过使用不同用户、车辆或服务订单相关的多个训练历史车辆报修请求(例如，标记的历史车辆报修请求)训练第一初始模型来生成第一预测模型。对于每个训练历史车辆报修请求，训练模块403可以获得与训练历史车辆报修请求有关的用户、车辆或服务订单的多个第一训练特征的特征值。第一训练特征可以与第一确定特征类似。在一些实施例中，每个历史车辆报修请求的第一训练特征与从特定时间点到获取模块401接收历史车辆报修请求的时间的时间段相关。

在一些实施例中，训练模块403可将标记的真实历史车辆报修请求标记为1，并将标记的虚假历史车辆报修请求标记为0。

第一初始模型可以包括机器学习模型，例如梯度提升决策树(GBDT)模型或极限梯度提升(XGBoost)模型。以第一初始模型是XGBoost模型为例，第一初始模型可以包括至少一个第一初步参数，例如，booster类型(例如，树模型或线性模型)、booster参数(例如，最大深度、叶节点的最大数量)、学习任务参数(例如，训练的目标函数)等或其任何组合。

在一些实施例中，训练模块403可以将第一训练特征的特征值和标记的训练历史车辆报修请求输入到第一初始模型中训练，以生成第一预测模型。

在一些实施例中，训练模块403可以使用多个测试历史车辆报修请求(例如，标记为历史车辆报修请求)来测试第一预测模型的准确性。训练模块403可以将与测试历史车辆报修请求有关的服务请求者、车辆或服务订单的第一测试特征的特征值输入到第一预测模型中，以确定测试历史车辆报修请求是真还是虚假。第一测试特征可能与第一训练特征类似。

在一些实施例中，若第一预测模型的准确度大于或等于第一精度阈值(例如，50％、60％、70％、80％、90％等)，训练模块403可以直接使用第一预测模型。若第一预测模型的准确度低于第一精度阈值，则训练模块403可以基于新的初始模型和/或新训练特征生成第一预测模型。

在一些实施例中，训练历史车辆报修请求可以与测试历史车辆报修请求不同。训练历史车辆报修请求的数量与测试历史车辆报修请求的数量的比率可以是任何值，例如但不限于7：3。

在一些实施例中，训练模块403可以在训练第一初始模型之前预处理第一训练特征，以便提高第一预测模型的准确性。训练模块403可以确定第一训练特征的每个特征值是否异常。若第一训练特征的特征值异常，训练模块403可以将第一训练特征的异常特征值修改为正常特征值。例如，O2O服务系统100可以具有默认设置，即服务请求者在一年中发起的历史订单的数量是从500到1000。在一些实施例中，当服务请求者在一年中发起的历史订单的数量在500到1000的范围之外时，可以确定历史订单的数量的特征值是异常的。训练模块403可以将历史订单的异常数量修改为在500到1000的范围内，并且修改为最接近异常值的值。例如，若历史订单的数量是1200，则训练模块403可以将历史订单的数量修改为1000。在一些实施例中，训练模块403可以移除异常特征值。

可选地或附加地，训练模块403可以在测试第一预测模型的准确性之前预处理第一测试特征，以便提高第一预测模型的准确性。在一些实施例中，第一测试特征的预处理可以与第一训练特征的预处理类似。

可选地或附加地，确定模块402可以在确定报修请求是否为真之前预处理第一确定特征，以便提高第一预测模型的准确性。在一些实施例中，第一确定特征的预处理可以与第一训练特征的预处理类似。

在一些实施例中，用于生成第一预测模型的过程还可以由其他设备执行，例如与O2O服务系统100通信的第三方设备。

在540中，传输模块404(或处理引擎112和/或接口电路210-a)可以将第一电信号传输到与服务请求者相关的移动设备(例如，终端设备130)。第一电信号可以指示终端设备130显示与所述车辆报修请求是否为虚假报修请求相关的至少一个消息。至少一个第一消息可以是任何形式，例如文本、图像、语音、视频等或其组合。

在一些实施例中，若确定模块402确定车辆报修请求为真实报修请求，则O2O服务系统100可以向服务请求者提供奖励。例如，传输模块404可以将第一电信号发送到服务请求者的终端设备130，以指示终端设备130显示包括至少一个电子优惠券的至少一个第一消息。又例如，O2O服务系统100可以增加服务请求者的信用评分。若服务请求者的信用评分大于第一评分阈值(例如，最大值的80％)，则O2O服务系统100可以将至少一个电子优惠券发送给服务请求者。至少一个电子优惠券可以包括免费订单的优惠券、折扣优惠券(例如，20％或50％折扣优惠券)、现金优惠券等。至少一个电子优惠券可能有使用期限或永久可用。例如，当服务请求者在根据服务订单操作车辆期间发送车辆的报修请求时，若确定模块402确定车辆报修请求为真实报修请求，则传输模块404可以发送当前服务订单可用的免费订单电子优惠券。又例如，当服务请求者发送车辆的报修请求时，若确定模块402确定车辆报修请求为真实报修请求，则传输模块404可以在当前时间发送五折电子优惠券，以使得服务请求者可以在接下来的三个月内使用。若确定模块402确定车辆报修请求为虚假报修请求，则O2O服务系统100可以向服务请求者提供警告。例如，传输模块404可以将第一电信号发送到服务请求者的终端设备130以指示终端设备130禁止服务请求者操作O2O服务系统100中任何车辆一定次数(例如，5次)和/或一段时间(例如，从当前时间算起的下一个月)和/或降低用户的信用评分。若服务请求者的信用评分低于第二评分阈值(例如10)，则O2O服务系统100可以禁止服务请求者操作O2O服务系统100中任何车辆一定次数(例如，5次)和/或一段时间(例如，从当前时间算起的下一个月)。

在一些实施例中，确定车辆报修请求为虚假报修请求，则第一消息还可以包括用于询问服务请求者是否同意报修请求是错误的询问。处理引擎112可以等待用户对所述询问的响应一段时间(例如，5分钟)。若处理引擎112在该时间段内从服务请求者的终端设备130接收到不同意报修请求错误的用户响应，处理引擎112可以通过例如将包括报修请求的消息发送到与运维人员相关的终端来指派运维人员来确认车辆报修请求。在一些实施例中，处理引擎112不向服务请求者提供任何奖励或警告，直到运维人员确定车辆报修请求是否为真实报修请求。若运维人员确定车辆报修请求是真实报修请求(例如车辆损坏)，则处理引擎112可以向服务请求者提供更大的奖励，例如大于正常奖励。若运维人员确定车辆报修请求是虚假报修请求(例如，车辆未损坏)，则处理引擎112可以向服务请求者发送警告。

应当理解的是，以上关于过程500的描述的仅仅是出于说明的目的而提供的，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而变化和修改不会背离本申请的范围。在一些实施例中，可以省略和/或添加至少一个操作。例如，在操作540后，若车辆报修请求是真实报修请求，则处理引擎112可以将电子信号发送到与负责维护车辆的运维人员相关的移动设备。电子信号可以指示运维人员的移动设备显示包括报修请求的至少一个消息。

图6是根据本申请的一些实施例所示的用于识别受损车辆的示例性过程的流程图。过程600的至少一部分可以在如图2所示的计算设备200或如图3所示的移动设备300上实现。在一些实施例中，过程600的至少一个操作可以在O2O服务系统100中实现，如图1所示。在一些实施例中，过程600中的至少一个操作可以作为指令的形式存储在存储设备(例如，存储设备150、存储器220、存储器390)中，并且由服务器110(例如，服务器110中的处理引擎112，或计算设备200的处理器210)调用和/或执行。在一些实施例中，指令可以以电子电流或电信号的形式传输。下面呈现的所示过程600的操作旨在说明性的。在一些实施例中，过程600在实施时可以添加至少一个本申请未描述的额外操作，和/或删减至少一个此处所描述的操作。另外，如图6所示和下面描述的过程600的操作的顺序不是限制性的。

为简洁起见，过程600的描述可以采用车辆(例如，服务设备140是车辆)共享或租赁作为示例。应当注意下面描述的车辆共享或租赁仅仅是示例。对于本领域的普通技术人员，过程600可以应用于其他类似的情况，例如但不限于安全箱共享/租赁、伞共享/租赁等。

在610中，获取模块401(或处理引擎112和/或接口电路210-a)可以接收检查车辆的请求。

在一些实施例中，当服务请求者通过与服务请求者有关的终端(例如终端设备130)向处理引擎112发送用于操作车辆的服务订单(例如，打开车辆的锁(如锁170)的请求)时，终端设备130也将用于检查车辆的请求发送到处理引擎112。例如，当服务请求者使用终端设备130扫描车辆的QR码时，终端设备130可以将用于打开车辆锁的请求和用于检查车辆的请求发送到处理引擎112。

在一些实施例中，当服务请求者想要发起O2O服务系统100的服务订单时，检查车辆的请求可以由服务请求者的终端设备130发送。例如，当服务请求者在终端设备130上打开O2O服务系统100的应用程序时，应用程序可以指示终端设备130发送检查最靠近终端设备130(也是服务请求者)的车辆的请求，或者在远离终端设备130(也是服务请求者)的预定距离(例如，1km)内检查至少一个车辆的请求。又例如，当服务请求者输入出发地点的至少一部分时，应用程序可以指示终端设备130发送检查最靠近出发地点的车辆的请求，或者要求在距离出发地点预定距离(例如，1km)内检查至少一个的车辆。作为又一示例，当服务请求者输入与车辆相关的至少一部分信息(例如，唯一ID，位置等)时，应用程序可以指示终端设备130发送检查车辆的请求。

在一些实施例中，O2O服务系统100可以周期性地(例如，每天一次或每周一次)将检查由O2O服务系统100管理的车辆的请求发送到获取模块401。

在一些实施例中，服务请求者可以发起包括出发地点和出发时间的预订服务订单。在距离出发时间的预定时间段(例如，5分钟)之前，应用程序可以指示终端设备130发送检查最接近出发地点的车辆的请求，或者检查从出发地点预定距离(例如，1km)内检查至少一个车辆的请求。

在一些实施例中，当处理引擎112基于例如，过程500的操作510-530确定车辆的报修请求是真实的报修请求时，处理引擎112可以发送检查车辆的请求。

在620中，获取模块401(或处理引擎112，和/或接口电路210-a)可以基于检查车辆请求，获得与所述车辆相关的多个第二确定特征的特征值。

多个第二确定特征可以包括至少一个车辆的特征、至少一个车辆历史服务订单的特征、至少一个车辆的维护特征、至少一个车辆的历史车辆报修请求的特征等或其任何组合。

在一些实施例中，车辆的特征可以包括在O2O服务系统100中车辆首次投入使用的时间、车辆由O2O服务系统100运营的总时间、车辆运营的城市或区域、管理车辆的工作人员、处理引擎112确定的车辆被损坏的次数、处理引擎112确定的车辆未损坏的次数等或其任何组合。

在一些实施例中，车辆的历史订单的特征可以包括用于请求操作车辆的历史订单的总数、已完成的历史订单的数量、取消历史订单的数量、已完成的历史订单总数占历史订单总数的比率、取消的历史订单数量占历史订单总数的比率、历史订单中的车辆总里程数、历史订单中服务请求者操作的总时间、历史订单中服务请求者操作车辆的区域、历史订单中操作车辆的总收入、基于最后完成的历史订单的车辆里程等或其任何组合。

在一些实施例中，车辆维护的特征可以包括车辆的总维护次数、维护后确定车辆未损坏的次数、维护后确定车辆被损坏的次数、最后维护时间与当前时间之间的时间间隔等或其任何组合。

在一些实施例中，车辆的历史车辆报修请求的特征可以包括车辆的历史车辆报修请求的总数、车辆的虚假历史车辆报修请求数量、车辆的真实历史车辆报修请求数量、虚假历史车辆报修请求数量占车辆历史车辆报修请求总数中的比率、真实历史车辆报修请求数占车辆历史车辆报修请求总数中的比率、发送车辆历史车辆报修请求的服务请求者的信用评分、车辆的最后一次历史车辆报修请求时间和当前时间之间的时间间隔等或其任何组合。

在一些实施例中，第二确定特征可以涉及从某个时间点到当前时间(例如，获取模块401接收到检查车辆的请求的时间)的时间段。例如，第二确定特征中的车辆的总里程可以指从车辆在O2O服务系统100中第一次投入使用时到当前时间内的车辆总里程。

在一些实施例中，第二确定特征的特征值可以是第二确定特征的特定值。例如，历史订单总数的特征值可以是总数的特定值(例如，50、100、200等)。又例如，车辆运营的城市或区域的特征值可以是城市或区域的序列号。作为又一示例，管理车辆的人员的特征值可以是包括一组数字的标识符。

在一些实施例中，获取模块401可以从存储设备(例如，存储设备150或处理引擎112的存储器220)获得第二确定特征的特征值。

在630中，确定模块402(或处理引擎112，和/或处理电路210-b)可以基于第二预测模型和第二确定特征的特征值来确定车辆是否被损坏。

在一些实施例中，第二确定特征的特征值可以输入到第二预测模型。第二预测模型可以输出车辆是否损坏的结果。在一些实施例中，第二预测模型可输出车辆受损的概率。确定模块402可以确定概率是否大于第二概率阈值(例如，50％、60％、70％、80％等)。若所述概率大于第二概率阈值，确定模块402可确定车辆已损坏。若所述概率小于或等于第二概率阈值，确定模块402可确定车辆未损坏。第二概率阈值可以由运营商或根据O2O服务系统100的默认设置来设置。

若车辆已损坏，第二预测模型还可以基于第二确定特征的特征值，输出车辆的故障等级和/或至少一个损坏部位的指示符(例如，部件名称)。

可选地或附加地，若车辆已损坏，确定模块402还可以基于车辆的历史车辆报修请求确定车辆的故障等级和/或至少一个损坏部位。在一些实施例中，确定模块402可以获得在最近的时段(例如，最近5天、最近30天等)中发送到处理引擎112的车辆的历史车辆报修请求。确定模块402可以选择真实的历史车辆报修请求(例如，标记的真实历史车辆报修请求和/或确定的真实历史车辆报修请求)。在一些实施例中，确定报修请求是否为真实报修请求的细节可以在本申请的其他地方找到，例如，在操作520-530及其描述中。确定模块402可以基于真实的历史车辆报修请求确定车辆的故障等级和/或至少一个损坏部位。例如，在车辆的5个真实历史车辆报修请求中，提到3次中度故障、2次轻微故障、0次严重故障，确定模块402可以将车辆的故障等级确定为中度故障。又例如，在车辆的5个真正的历史车辆报修请求中，提到车铃的故障4次，并且提到刹车的故障1次，确定模块402可以确定车辆的损坏部位是车铃。

在一些实施例中，可以在线或离线生成第二预测模型。在一些实施例中，第二预测模型可以由处理引擎112(例如，训练模块403)或与O2O服务系统100通信的第三方设备生成。在一些实施例中，训练模块403可以预先生成第二预测模型，并将第二预测模型存储在存储设备(例如，存储设备150、处理引擎112的存储器220)中。当获取模块401接收到检查车辆的请求时，确定模块402可以从存储设备获得第二预测模型。在一些实施例中，当获取模块401接收到检查车辆的请求时，训练模块403可以在线生成第二预测模型。在一些实施例中，第三方设备可以预先生成第二预测模型，并将第二预测模型存储在本地或存储在O2O服务系统100的存储设备(例如，存储设备150、处理引擎112的存储器220)中。当获取模块401接收到检查车辆的请求时，确定模块402可以从O2O服务系统100或第三方设备的存储设备获得第二预测模型。在一些实施例中，当获取模块401接收到检查车辆的请求时，第三方设备可以在线生成第二预测模型，并将第二预测模型发送到确定模块402。

在一些实施例中，在维护车辆之后，可以创建车辆损坏信息并将其存储在存储设备(例如，存储设备150或处理引擎112的存储220)中。若运维人员确认车辆未损坏，则车辆可以被标记为在维护时间内的未损坏车辆。若运维人员确认车辆已损坏，车辆可以标记为在维护时间内的损坏车辆。

仅作为示例，训练模块403可通过使用与训练车辆(例如，标记的车辆)相关的历史车辆损坏信息训练第二初始模型来产生第二预测模型。对于每个训练车辆，训练模块403可以获得训练车辆的多个第二训练特征的特征值。第二训练特征可以与第二确定特征类似。在一些实施例中，每个训练车辆的第二训练特征可以涉及从训练车辆的特定时间点到维护时间的时间段。历史车辆损坏信息可以包括第二训练特征的特征值。

在一些实施例中，训练模块403可将标记为损坏车辆的车辆标记为1并将标记为未损坏车辆的车辆标记为0。

第二初始模型可以包括机器学习模型，例如梯度提升决策树(GBDT)模型或极限梯度提升(XGBoost)模型。以XGBoost模型为第二初始模型为例，第二初始模型可以包括至少一个第二初步参数，例如booster类型(例如，基于树的模型或线性模型)、booster参数(例如，最大深度、叶节点的最大数量)、学习任务参数(例如，训练的目标函数)等或其任何组合。

训练模块403可以将第二训练特征的特征值和训练车辆的标记结果输入到第二初始模型中训练，以生成第二预测模型。

训练模块403可以使用测试车辆(例如，标记的车辆)的历史车辆损坏信息来测试第二预测模型的准确性。训练模块403可以将测试车辆的第二测试特征的特征值输入到第二预测模型中，以确定测试车辆是否损坏。第二测试特征可能与第二训练特征类似。若第二预测模型的准确度大于或等于第二精度阈值(例如，50％、60％、70％、80％、90％等)，训练模块403可以直接使用训练的第二预测模型。若第二预测模型的精度低于第二精度阈值，则训练模块403可基于新的初始模型和/或新训练特征生成第二预测模型。历史车辆损坏信息可能包括第二测试特征的特征值。

在一些实施例中，训练车辆可以与测试车辆不同。训练车辆的数量与测试车辆的数量的比率可以是任何值，例如但不限于7：3。

在一些实施例中，训练模块403可以在训练第二初始模型之前预处理第二训练特征，以便提高第二预测模型的准确性。可选地或附加地，训练模块403可以在测试第二预测模型的准确性之前预处理第二测试特征，以便提高第二预测模型的准确度。可选地或附加地，确定模块402可以在确定车辆是否被损坏之前预处理第二确定特征，以便提高第二预测模型的准确度。第二训练特征、第二测试特征或第二确定特征的预处理可以类似于过程500的操作530中描述的第一训练特征的预处理。

在一些实施例中，用于生成第二预测模型的过程还可以由其他设备执行，例如与O2O服务系统100通信的第三方设备。

在一些实施例中，处理引擎112可以通过重复操作620-630来确定多个车辆是否被损坏。

在640中，传输模块404(或处理引擎112和/或接口电路210-a)可以将第二电信号传输到电子设备。第二电信号可以指示电子设备显示与车辆是否损坏有关的至少一个第二消息。至少一个第二消息可以是任何形式，例如文本、图像、语音、视频等或其组合。电子设备可以与O2O服务系统100的服务请求者或运维人员相关。

在一些实施例中，O2O服务系统100可以周期性地(例如，每天一次或每周一次)将检查车辆的请求发送到获取模块401。处理引擎112可以基于例如操作620-630确定由O2O服务系统100管理的车辆是否被损坏。处理引擎112可以将第二电子信号发送到至少一个运维人员的终端设备130，以指示终端设备130显示第二消息。第二消息可能包括受损车辆的位置、受损车辆的唯一ID、受损车辆的故障等级、受损车辆的损坏部位等或其任何组合。有了第二消息，运维人员可以检查被处理引擎112确定的损坏车辆，而不是O2O服务系统100中所有车辆，这减少了管理O2O服务系统100中车辆的时间成本和人力成本，提高了维护效率。

在一些实施例中，若服务请求者使用终端设备130扫描车辆的QR码，终端设备130可以将用于打开车锁(例如，锁170)的请求和用于检查车辆的请求发送到处理引擎112。处理引擎112可执行操作610-620以确定车辆是否已损坏。若车辆未损坏，处理引擎112可将用于打开车锁的指令发送到终端设备130和/或车辆(或锁170)。若车辆已损坏，处理引擎112可以将第二电信号发送到终端设备130，以指示终端设备130显示指示车辆损坏的警报、车辆的故障等级或车辆的损坏部位的第二消息。第二消息还可以包括是否继续解锁车辆的询问。若处理引擎112从服务请求者接收到继续解锁车辆，则处理引擎112可以将用于打开车辆锁的指令发送到终端设备130和/或车辆(或锁170)。若处理引擎112从服务请求者接收到不继续解锁车辆，则车辆不会被解锁。

在一些实施例中，若服务请求者想要通过在终端设备130上打开O2O服务系统100的应用程序来发起订单，则应用程序可以指示终端设备130发送在终端设备130(也是服务请求者)的预定距离(例如，1km)内检查至少一个车辆的请求。处理引擎112可以基于操作620-630确定至少一个车辆是否被损坏。处理引擎112可以将第二电子信号发送到终端设备130，以指示终端设备130显示第二消息。第二消息可以包括受损车辆和/或未损坏车辆的位置、受损车辆和/或未损坏车辆的符号(例如，以文本、图像、语音、视频、颜色等形式)、受损车辆的故障等级、受损车辆的损坏部位、推荐车辆、至少一个从服务请求者的当前位置(或出发地点)到推荐车辆的路线、从服务请求者的当前位置(或出发地点)到推荐车辆的距离、从服务请求者的当前位置(或出发地点)到推荐车辆的时间等或其任何组合。

在一些实施例中，服务请求者可以发起包括出发地点和出发时间的预订服务订单。在距离出发时间的预定时间段(例如，5分钟)之前，应用程序可以指示终端设备130发送检查最接近出发地点的车辆的请求，或者在出发地点预定距离(例如，1km)内检查至少一个车辆的请求。处理引擎112可以基于操作620-630确定至少一个车辆是否被损坏。处理引擎112可以将第二电子信号发送到终端设备130，以指示终端设备130显示第二消息。第二消息可以包括受损车辆和/或未损坏车辆的位置、受损车辆和/或未损坏车辆的符号(例如，以文本、图像、语音、视频、颜色等形式)、受损车辆的故障等级、受损车辆的损坏部位、推荐车辆、至少一个从服务请求者的出发地点到推荐车辆的路线、从服务请求者的出发地点到推荐车辆的距离、从服务请求者的出发地点到推荐车辆的时间等或其任何组合。在一些实施例中，处理引擎112可以为服务请求者在预定时间段(例如，10分钟)内保留推荐车辆。

在一些实施例中，当处理引擎112基于例如，过程500的操作510-530，确定车辆报修请求是真实报修请求时，处理引擎112可以发送检查车辆的请求。处理引擎112可以基于操作620-630确定车辆是否被损坏。若车辆已损坏，处理引擎112可将第二电子信号发送到运维人员的终端设备130，以指示终端设备130显示第二消息。第二消息可以包括车辆的位置、车辆的唯一ID、车辆的故障等级、车辆的损坏部位等或其任何组合。

应当注意以上对过程600的描述仅仅是出于说明的目的而提供的，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，变化和修改不会背离本申请的范围。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述申请披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，本领域技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。

计算机可读信号介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等、或合适的组合形式。计算机可读信号介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令集执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机可读信号介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF、或类似介质、或任何上述介质的组合。

本申请各部分步骤所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向主体编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、VisualBasic、Fortran2003、Perl、COBOL2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。

此外，除非权利要求中明确说明，本申请处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的申请实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，例如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个申请实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请主体所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

Claims (21)

1.一种用于在线上到线下服务中识别虚假车辆报修请求的方法，所述方法在至少一个处理器和至少一个存储器上实现，其特征在于，所述方法包括：

从用户处接收车辆报修请求；

基于所述车辆报修请求，获得与所述用户或所述车辆相关的多个确定特征的特征值；

基于预测模型和所述特征值，判断所述车辆报修请求是否为虚假报修请求，其中，基于包含所述确定特征的多个历史车辆报修请求，获得所述预测模型；以及

将电子信号发送给与所述用户相关的移动设备，其中，所述电子信号指示所述移动设备显示与所述车辆报修请求是否为虚假报修请求相关的至少一个消息。

2.根据权利要求1所述的方法，其特征在于，所述车辆报修请求包括所述用户获得的至少一个车辆图像；以及

所述基于所述预测模型和所述特征值，判断所述车辆报修请求是否为虚假报修请求包括：

判断所述车辆图像是否与所述车辆对应；

基于所述车辆图像与所述车辆对应，利用所述预测模型，判断所述车辆图像中的所述车辆是否损坏；以及

基于所述车辆图像中的所述车辆是否损坏的判断，确定所述车辆报修请求是否为虚假报修请求。

3.根据权利要求1所述的方法，其特征在于，所述车辆报修请求是在所述用户试图操作所述车辆之后产生的，其中，所述确定特征包括以下中的至少一个：

所述用户操作所述车辆的时长；

所述用户使用所述车辆行驶的距离；

所述用户开始操作所述车辆的时间点；

所述车辆被操作的次数；

与所述车辆相关的车辆报修请求次数；

所述车辆的投放时间；

与所述线上到线下服务的历史订单相关的信息；

与所述历史订单中已完成订单相关的信息；

所述用户行驶的总距离；

所述用户车辆报修请求的总数；

所述历史车辆报修请求中真实报修请求的数量；或

所述真实报修请求在所述历史车辆报修请求中的比率。

4.根据权利要求1所述的方法，其特征在于，所述车辆是自行车。

5.根据权利要求1所述的方法，其特征在于，基于所述车辆报修请求是虚假报修请求，所述电子信号还指示所述移动设备禁止所述用户操作与所述线上到线下服务相关的任何车辆。

6.根据权利要求1所述的方法，其特征在于，基于所述车辆报修请求是真实报修请求，所述至少一个消息还包括至少一个电子优惠券。

7.一种用于在线上到线下服务中识别虚假车辆报修请求的系统，其特征在于，所述系统包括：

获取模块，用于从用户处接收车辆报修请求，并基于所述车辆报修请求，获得与所述用户或所述车辆相关的多个确定特征的特征值；

确定模块，用于基于预测模型和所述特征值，判断所述车辆报修请求是否为虚假报修请求，其中，基于包含所述确定特征的多个历史车辆报修请求，获得所述预测模型；

传输模块，用于将电子信号发送给与所述用户相关的移动设备，其中，所述电子信号指示所述移动设备显示与所述车辆报修请求是否为虚假报修请求相关的至少一个消息。

8.一种用于在线上到线下服务中识别虚假车辆报修请求的装置，包括处理器，其特征在于，所述处理器用于执行权利要求1～6中任一项所述的用于在线上到线下服务中识别虚假车辆报修请求的方法。

9.一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行如权利要求1～6任一项所述的用于在线上到线下服务中识别虚假车辆报修请求的方法。

10.一种用于识别受损车辆的方法，所述方法在至少一个处理器和至少一个存储器上实现，其特征在于，包括：

接收检查车辆请求；

基于所述检查车辆请求，获得与所述车辆相关的多个第一确定特征的特征值；

基于第一预测模型和所述第一确定特征的特征值，判断所述车辆是否损坏，其中，基于包含所述第一确定特征的多个历史损坏车辆，获得所述第一预测模型；以及

将第一电子信号发送到电子设备，指示所述电子设备显示与所述车辆是否损坏相关的至少一个第一消息。

11.根据权利要求10所述的方法，其特征在于，所述接收检查车辆请求包括：

接收第一用户打开所述车辆车锁的请求。

12.根据权利要求10所述的方法，其特征在于，所述接收检查车辆请求包括：

确定第一用户准备在线上到线下服务中发起订单，其中，所述车辆位于所述第一用户的预设距离内。

13.根据权利要求11或12所述的方法，其特征在于，所述电子设备与所述第一用户或运维人员相关。

14.根据权利要求10所述的方法，其特征在于，与所述车辆相关的所述第一确定特征包括车辆报修请求，所述车辆报修请求从第二用户处接收；以及

基于所述车辆已损坏，所述方法还包括：

基于所述车辆报修请求，确定所述车辆的至少一个损坏部位；以及

将第二电子信号发送到所述电子设备，指示所述电子设备显示与所述车辆的至少一个损坏部位相关的至少一个第二消息。

15.根据权利要求10所述的方法，其特征在于，所述接收所述检查车辆请求包括：

从第二用户接收所述车辆的车辆报修请求；以及

确定所述车辆报修请求是真实车辆报修请求。

16.根据权利要求15所述的方法，其特征在于，所述确定所述车辆报修请求是否为真实车辆报修请求，包括：

获得与所述第二用户或所述车辆相关的多个第二确定特征的特征值；以及

基于第二预测模型和所述第二确定特征的特征值，判断所述车辆报修请求是否为真实车辆报修请求，其中，基于包含所述第二确定特征的多个历史车辆报修请求，获得所述第二预测模型。

17.根据权利要求16所述的方法，其特征在于，所述车辆报修请求包括所述第二用户获得的至少一个车辆图像；以及

所述基于所述第二预测模型和所述第二确定特征的特征值，判断所述车辆报修请求是否为真实报修请求包括：

判断所述至少一个车辆图像是否与所述车辆对应；

基于所述至少一个车辆图像与所述车辆对应，利用所述第二预测模型，判断所述至少一个车辆图像中的所述车辆是否损坏；以及

基于所述至少一个车辆图像中的所述车辆是否损坏的判断，确定所述车辆报修请求是否为真实报修请求。

18.根据权利要求10所述的方法，其特征在于，所述车辆是自行车。

19.一种用于识别受损车辆的系统，其特征在于，所述系统包括：

获取模块，用于接收检查车辆请求，并获得与所述车辆相关的多个第一确定特征的特征值；

确定模块，用于基于第一预测模型和所述第一确定特征的特征值，判断所述车辆是否损坏，其中，基于包含所述第一确定特征的多个历史损坏车辆，获得所述第一预测模型；以及

传输模块，用于将第一电子信号发送到电子设备，指示所述电子设备显示与所述车辆是否损坏相关的至少一个第一消息。

20.一种用于识别受损车辆的装置，包括处理器，其特征在于，所述处理器用于执行权利要求10～18中任一项所述的用于识别受损车辆的方法。

21.一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行如权利要求10～18任一项所述的用于识别受损车辆的方法。

Images