CN104866953B - 一种虚假订单的识别方法及装置 - Google Patents

Abstract

本发明公开了一种虚假订单的识别方法及装置，该方法包括：接收用户设备发送的打车请求，打车请求包括目的地；获取第一预设时间段内与目的地相同的所有订单；确定所有订单中订单的状态为被终端投诉或取消的概率；根据包含目的地的所有订单的数量以及所述概率，判断用户设备发送的打车请求的订单是否为虚假订单；终端为向用户设备提供运营服务的终端。通过获取用户设备发送的打车请求中的目的地，在预设时间段内获取与该目的地相同的所有订单的数量以及与该目的地相同的订单被终端投诉或取消的概率，判断该打车请求的订单是否为虚假订单，通过识别虚假订单，并对虚假订单进行有效过滤，净化了互联网信息传输环境，提升了用户体验。

Description

一种虚假订单的识别方法及装置

技术领域

本发明涉及计算机技术领域，特别涉及一种虚假订单的识别方法及装置。

背景技术

目前乘客可以便捷地通过用户设备(User Equipment，简称UE)发布打车需求，打车平台接收用户设备发送的打车请求，并将该打车请求的订单推送给终端，司机可以根据终端抢单，并与乘客直接沟通，大大提高了打车效率。

现有技术中的打车平台一般是接收用户设备发送的打车请求后，检测打车请求中是否包含政治敏感词、违反法律、法规不文明用语等敏感词语，并滤掉该类打车请求的订单，净化互联网信息传输环境。

然而现在出现了一些虚假订单，该些虚假订单并不通过上述形式发出，一部分为广告类订单，该类订单表现用户设备发布打车请求的目的地相同；还有一部分为刷单订单，该类订单用户设备发布打车请求的目的地可能不同，但订单发出的用户设备的网络通信协议(Internet Protocol，简称IP)地址相同，采用现有方法对于上述订单并不能有效过滤，不仅占用正常订单的信道，导致乘客打车困难，而且给司机带来运输成本的浪费，降低了用户体验。

发明内容

鉴于上述问题，本公开提出了一种虚假订单的识别方法及装置，通过识别虚假订单，并阻止将虚假订单向终端推送，提升了用户体验。

第一方面，本公开提供了一种虚假订单的识别方法，包括：

接收用户设备发送的打车请求，所述打车请求包括目的地；

获取在第一预设时间段内与所述目的地相同的所有订单；

确定所述所有订单中订单的状态为被终端投诉或取消的概率；

根据包含所述目的地的所有订单的数量以及所述概率，判断所述用户设备发送的打车请求的订单是否为虚假订单；

所述终端为向用户设备提供运营服务的终端。

可选的，所述根据包含所述目的地的所有订单的数量以及所述概率，判断所述用户设备发送的打车请求的订单是否为虚假订单，包括：

在所述订单的数量大于等于第一预设阈值，且所述概率大于第二预设阈值时，所述用户设备发送的打车请求的订单为虚假订单，且在第二预设时间段内不向终端推送包括该虚假订单中目的地的所有打车请求的订单。

可选的，所述根据包含所述目的地的所有订单的数量以及所述概率，判断所述用户设备发送的打车请求的订单是否为虚假订单，包括：

在所述订单的数量大于等于第一预设阈值，且所述概率大于第三预设阈值且小于第二预设阈值时，所述用户设备发送的打车请求的订单为待验证虚假订单；

向符合预设条件终端推送包括该虚假订单中目的地的所有打车请求的订单，同时还向订单验证设备推送验证所述待验证虚假订单是否为虚假订单的请求；

接收所述订单验证设备验证的结果，并根据所述结果判断是否继续向终端推送包括该虚假订单中目的地的所有打车请求的订单。

可选的，所述接收所述订单验证设备验证的结果，并根据所述结果判断是否向终端推送包括该虚假订单中目的地的所有打车请求的订单，包括：

在所述结果确认所述待验证虚假订单为虚假订单时，在第二预设时间段内不向终端推送包括该虚假订单中目的地的所有打车请求的订单。

可选的，所述向符合预设条件的终端推送包括该虚假订单中目的地的所有打车请求的订单：

向距离所述用户设备为预设距离的终端或向预设数量的终端推送包括该虚假订单中目的地的所有打车请求的订单。

可选的，所述方法还包括：

判断所述打车请求中的用户设备的标识是否存储于预设的虚假订单标识数据库中，如果是，则确定该打车请求对应的订单为虚假订单。

第二方面，本发明还提供了一种虚假订单的识别装置，包括：

接收模块，用于接收用户设备发送的打车请求，所述打车请求包括目的地；

获取模块，用于获取在第一预设时间段内与所述目的地相同的所有订单；

第一确定模块，用于确定所述所有订单中订单的状态为被终端投诉或取消的概率；

第一判断模块，用于根据包含所述目的地的所有订单的数量以及所述概率，判断所述用户设备发送的打车请求的订单是否为虚假订单；

所述终端为向用户设备提供运营服务的终端。

可选的，所述第一判断模块，具体用于：

在所述订单的数量大于等于第一预设阈值，且所述概率大于第二预设阈值时，确定所述用户设备发送的打车请求的订单为虚假订单；

相应的，所述装置还包括推送模块；

所述推送模块，用于在所述第一判断模块判断所述用户设备发送的打车请求的订单为虚假订单时，在第二预设时间段内不向终端推送包括该虚假订单中目的地的所有打车请求的订单。

可选的，所述第一判断模块，还用于：

在所述订单的数量大于等于第一预设阈值，且所述概率大于第三预设阈值且小于第二预设阈值时，确定所述用户设备发送的打车请求的订单为待验证虚假订单；

相应的，所述推送模块，还用于：

在所述第一判断模块判断所述用户设备发送的打车请求的订单为待验证虚假订单时，向符合预设条件的终端推送包括该虚假订单中目的地的所有打车请求的订单，同时还向订单验证设备推送验证所述待验证虚假订单是否为虚假订单的请求；

相应的，所述装置还包括第二判断模块；

所述第二判断模块，用于接收所述订单验证设备验证的结果，并根据所述结果判断是否向终端推送包括该虚假订单中目的地的所有打车请求的订单。

可选的，所述第二判断模块，还用于：

在所述结果确认所述待验证虚假订单为虚假订单时，在第二预设时间段内不向终端推送包括该虚假订单中目的地的所有打车请求的订单。

可选的，所述推送模块，还用于：

在所述第一判断模块确定所述用户设备发送的打车请求的订单为待验证虚假订单时，向距离所述用户设备为预设距离的终端或向预设数量的终端推送包括该虚假订单中目的地的所有打车请求的订单。

可选的，所述装置还包括：

第三判断模块，具体用于判断所述打车请求中的用户设备的标识是否属于预设的虚假订单标识数据库；

第二确定模块，用于在所述第三判断模块判断所述打车请求中的用户设备的标识属于预设的虚假订单标识数据库时，确定该打车请求对应的订单为虚假订单。

由上述技术方案可知，本公开提供一种虚假订单的识别方法及装置，通过获取用户设备发送的打车请求中的目的地，在预设时间段内获取与该目的地相同的所有订单的数量以及所有订单中订单的状态为被终端投诉或取消的概率，判断该打车请求的订单是否为虚假订单，通过识别虚假订单，净化了互联网信息传输环境，提升了用户体验。

附图说明

图1为本公开一实施例提供的一种虚假订单的识别方法的流程示意图；

图2为本公开另一实施例提供的一种虚假订单的识别装置的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面结合附图和实施例，对本公开的具体实施方式作进一步详细描述。以下实施例用于说明本公开，但不用来限制本公开的范围。

以下对本公开实施例中提及的部分词语进行举例说明。

本公开实施例中提及的用户设备(User Equipment，简称UE)是指服务需求方，如交通工具叫车服务中的乘客所使用的移动终端或个人计算机(Personal Computer，简称PC)等设备。例如智能手机、个人数码助理(PDA)、平板电脑、笔记本电脑、车载电脑(carputer)、掌上游戏机、智能眼镜、智能手表、可穿戴设备、虚拟显示设备或显示增强设备(如Google Glass、Oculus Rift、Hololens、Gear VR)等。

本公开实施例中提及的终端为服务提供方即向用户设备提供运营服务的终端，如交通工具叫车服务中的司机所使用的用于接单的移动终端或PC端等设备。诸如上述呼叫服务方所使用各设备。因此，本实施例中，为了区别乘客和司机，分别采用用户设备UE和终端来分别表示乘客和司机所持的移动终端等设备。

图1示出了本公开一实施例提供的一种虚假订单的识别方法的流程示意图，如图1所示，该方法包括如下步骤：

101、接收用户设备发送的打车请求，所述打车请求包括目的地；

上述用户设备可以为移动终端或PC端等，在实际应用中，上述打车请求除包含目的地之外，还包括：出发地、及所述用户设备的标识、用户设备发送打车请求的时间等等或其中某一信息或组合信息。其中，上述用户设备的标识包含手机号码、身份标识码(Identity，简称id)、用户设备的IP地址、硬件地址(Media Access Control，简称MAC)等或其中某一信息或组合信息。

可理解的是，上述打车请求是用户通过安装在用户设备上的第三方软件识别并发送给打车平台的，打车平台可以理解为处理打车请求的平台，具体的，上述打车请求中的出发地可以理解为用户在通过用户设备发送打车请求时在用户设备的第三方软件中输入的出发地，或者是该第三方软件通过GPS定位当前用户设备所在位置作为出发地；上述打车请求中的目的地，为用户在第三方软件中输入的要求到达的目的地。

102、获取在第一预设时间段内与所述目的地相同的所有订单；

上述第一预设时间段为打车平台预先设定的，具体为统计与打车请求中目的地相同的所有订单的数量的时间段，该第一预设时间段可以为12小时，24小时、48小时等，本实施例不对其进行限定。

103、确定所述所有订单中订单的状态为被终端投诉或取消的概率；在具体应用中，上述步骤102中统计的在第一预设时间段中(例如：24小时)与打车请求中的目的地相同的所有订单中，每一个订单均包含了订单的状态，其中该状态可以包括：被终端投诉、订单取消、订单完成等状态。

上述步骤103可以理解为，通过步骤102中统计的在第一预设时间段内与步骤101中打车请求的目的地相同的所有打车请求的订单的个数，以及步骤102统计的所有打车请求的订单中订单的状态为被终端投诉或订单取消的个数，则上述订单的状态为被终端投诉或取消的概率可以理解为：所有打车请求的订单中订单的状态为被终端投诉或订单取消的个数与所有打车请求的订单的个数的百分比。

104、根据包含所述目的地的所有订单的数量以及所述概率，判断所述用户设备发送的打车请求的订单是否为虚假订单。

上述方法通过获取用户设备发送的打车请求中的目的地，在预设时间段内获取与该目的地相同的所有订单的数量以及所有订单中订单的状态为被终端投诉或取消的概率，判断该打车请求的订单是否为虚假订单，通过识别虚假订单，净化了互联网信息传输环境，提升了用户体验。

上述步骤104在具体应用中具体包括以下两种方案判断所述用户设备发送的打车请求的订单是否为虚假订单：

第一种方案是：在所述订单的数量大于等于第一预设阈值，且所述概率大于第二预设阈值时，可以确定所述用户设备发送的打车请求的订单为虚假订单，且在第二预设时间段内不向终端推送包括该虚假订单中目的地的所有打车请求的订单。

可理解的是，上述第一预设阈值为订单的数量的阈值，也就是说在达不到该第一预设阈值时，例如订单数量特别少只有1个或者2个时，检测其是否为虚假订单对整个打车系统并无多大影响，因此，本实施例中设置该阈值，主要是为了对数量较大，能够对该打车平台产生一定影响的订单进行排查是否为虚假订单，该第一预设阈值可以为50、100等。

上述第二预设阈值为上述在预设时间段内获取与该目的地相同的所有订单的数量的订单中订单的状态为被终端投诉或取消的概率的阈值，也可以理解为在第一预设时间段内，与打车请求中的目的地相同的所有订单中被终端投诉或取消的个数占总订单个数的百分比的阈值，该第二预设阈值可以为75％、80％等。

上述第二预设时间段为暂停推送打车请求订单的时间段，在该时间段内，将该虚假订单进行有效过滤，净化了互联网信息传输环境，提升了用户体验，避免包括该虚假订单中目的地的所有打车请求的订单被推送，该第二预设时间段可以为24小时、72小时等，该第二预设时间段可以根据终端的运营力以及用户的出行高峰期等进行适应性调整，比如在高峰期缩短暂停推送订单的时间，本实施例不对其进行限定。

当然，如果在该第二预设时间段之后，又接收到了目的地相同的打车请求，则再按照上述步骤重新验证该打车请求的订单是否为虚假订单。

举例来说，如果某个相同目的地当天的订单的数量大于n(如：100)且订单的状态为被终端投诉或取消的概率(例如：80％)大于某一阈值α1(如：75％)，则认为到达该目的地的所有打车请求的订单都是虚假订单，在未来的预设的一段时间内(如：24小时)不给司机推送该目的地的订单。

例如：相同目的地均为A的订单在20150401出现了200次，其中订单的状态为订单取消的订单有90个，被终端投诉的订单有70个，则被终端投诉或取消的概率为(90+70)/200＝80％，认为以该目的地为打车请求的订单均为虚假订单，在24小时内暂停向终端推送包括该虚假订单中目的地的所有打车请求的订单。

第二种方案是包括以下步骤：

1041、在所述订单的数量大于等于第一预设阈值，且所述概率大于第三预设阈值且小于第二预设阈值时，可以确定所述用户设备发送的打车请求的订单为待验证虚假订单；

上述第三预设阈值与第二预设阈值一样，也为在预设时间段内获取与打车请求中的目的地相同的所有订单的数量的订单中订单的状态为被终端投诉或取消的概率的阈值，也可以理解为在第一预设时间段内，与打车请求中的目的地相同的所有订单中被终端投诉或取消的个数占总订单个数的百分比的阈值，该第三预设阈值可以为60％、50％等。

1042、向符合预设条件的终端推送包括该虚假订单中目的地的所有打车请求的订单，同时还向订单验证设备推送验证所述待验证虚假订单是否为虚假订单的请求；

在上述步骤1041中由于确定用户设备发送的打车请求的订单为待验证虚假订单，故还需要向订单验证设备发送验证该待验证虚假订单是否且虚假订单，在未确定该待验证虚假订单为虚假订单之前，这时为了保证正常运营，本公开采用的方法是向符合预设条件的终端推送该订单，该预设条件的终端可以理解为向距离所述用户设备为预设距离的终端或向预设数量的终端推送包括该虚假订单中目的地的所有打车请求的订单。

1043、接收所述订单验证设备验证的结果，并根据所述结果判断是否向终端推送包括该虚假订单中目的地的所有打车请求的订单。

具体的，上述步骤1043包括以下两个方案：

第一种方案是：在所述结果确认所述待验证虚假订单不为虚假订单时，则向终端推送包括该虚假订单中目的地的所有打车请求的订单

具体可以理解为可以根据打车平台中预先设置的策略或条件向终端推送包括该虚假订单中目的地的所有打车请求的订单，因为打车平台在接收到打车请求时，为了保证运营力，以及为了防止终端到达打车请求的目的地路程过长等，打车平台会根据打车请求的出发地、目的地、打车请求的时间等信息、以及预先设置的策略向符合该策略对应的终端推送相应打车请求的订单，在实际应用中，打车平台可以根据运营高峰期或运营力等因素对改策略进行调整。

可理解的是，上述策略为距离用户设备打车请求的出发地为1公里以内的终端推送打车请求的订单；或者在运营力不足或者高峰期等时间段内，则向距离用户设备打车请求的出发地为5公里以内的终端推送打车请求的订单；或者在运营力或者不是在运营高峰期的情况下，向距离用户设备打车请求的出发地为1公里且仅向1公里内的100个终端推送打车请求的订单。

第二种方案是：在所述结果确认所述待验证虚假订单为虚假订单时，在第二预设时间段内不向终端推送包括该虚假订单中目的地的所有打车请求的订单。

上述第二预设时间段为暂停推送打车请求中的目的地与所述虚假订单目的地相同的打车请求的订单的时间段，在该时间段内，将该虚假订单进行有效过滤，净化了互联网信息传输环境，提升了用户体验，避免包括该虚假订单中目的地的所有打车请求的订单被推送，该第二预设时间段可以为24小时、72小时等，该第二预设时间段可以根据终端的运营力以及用户的出行高峰期等进行适应性调整，比如在高峰期缩短暂停推送订单的时间，本实施例不对其进行限定。

当然，如果在该第二预设时间段之后，又接收到了目的地相同的打车请求，则再按照上述步骤重新验证该打车请求的订单是否为虚假订单。

举例来说，如果某个相同目的地当天的订单的数量大于n(如：100)且订单的状态为被终端投诉或取消的概率(例如：60％)大于某一阈值α2(如：50％)且小于某一阈值α1(如：75％)，则认为到达该目的地的所有打车请求的订单为待验证虚假订单，因此需要对该类型的订单做处理，比如：暂时降级该类订单的播送(如：仅仅播送给附近500米内司机，或仅仅播送给30％的司机)，并将相关订单推送至订单验证设备确认；经订单验证设备确认为虚假订单后暂停推送该类订单，或者是在订单验证设备确认为正常订单后取消该类订单降级。

上述订单验证设备可以为人工服务的终端，通过人工识别来进行确认，也可以为其他终端，本实施例不对其进行限定。

例如：相同目的地均为B的订单在20150401出现了200次，其中订单的状态为订单取消的订单有50个，被终端投诉的订单有70个，则被终端投诉或取消的概率为(50+70)/200＝60％，认为以该该目的地B订单有可能是虚假订单即待验证虚假订单，对该类订单的推送过程进行处理，具体可以理解为对该类订单进行降级，降级策略为：仅播送给最近的10名司机(原策略为播送给附近的100名司机)，并且将该类订单发送订单验证设备，以使订单验证设备对该类订单进行审核，如果在订单验证设备确认该类订单为广告订单，在24小时内暂停向终端推送包括该虚假订单中目的地的所有打车请求的订单。

在另一个可实现的方式中，还可以通过以下方法识别虚假订单，所述方法还包括：

判断所述打车请求中的用户设备的标识是否存储于预设的虚假订单标识数据库中，如果是，则确定该打车请求对应的订单为虚假订单。

可理解的是，打车系统内会存储有虚假订单标识数据库，该数据库中记录有经常发送虚假订单用户设备的标识，也即用户设备的IP地址、用户设备的电话号码等信息，可以根据发送打车请求的用户设备的IP地址或用户设备的电话号码进行判断，如果该IP地址或用户设备的电话号码等信息在该数据库中已存储，则可以对该用户设备标识对应的用户设备发送的订单请求的订单直接进行拦截，即不向任何终端推送打车请求中包含该IP地址或用户设备的电话号码的订单，具体的，该数据库也会在一段时间内进行更新或者修改。

图2示出了本公开实施例提供的一种虚假订单的识别装置的结构示意图，如图2所示，该装置包括：

接收模块21，用于接收用户设备发送的打车请求，所述打车请求包括目的地；

获取模块22，用于获取在第一预设时间段内与所述目的地相同的所有订单；

确定模块23，用于确定所述所有订单中订单的状态为被终端投诉或取消的概率；

第一判断模块24，用于根据包含所述目的地的所有订单的数量以及所述概率，判断所述用户设备发送的打车请求的订单是否为虚假订单；

在本公开的一个可选的实施例中，所述第一判断模块24，具体用于：

在所述订单的数量大于等于第一预设阈值，且所述概率大于第二预设阈值时，确定所述用户设备发送的打车请求的订单为虚假订单；

相应的，所述装置还包括图2中未示出的推送模块25；

所述推送模块，用于在所述第一判断模块判断所述用户设备发送的打车请求的订单为虚假订单时，在第二预设时间段内不向终端推送包括该虚假订单中目的地的所有打车请求的订单。

在本公开的一个可选的实施例中，所述第一判断模块24，还用于：

在所述订单的数量大于等于第一预设阈值，且所述概率大于第三预设阈值且小于第二预设阈值时，确定所述用户设备发送的打车请求的订单为待验证虚假订单；

相应的，所述推送模块25，还用于：

在所述第一判断模块判断所述用户设备发送的打车请求的订单为待验证虚假订单时，向符合预设条件的终端推送包括该虚假订单中目的地的所有打车请求的订单，同时还向订单验证设备推送验证所述待验证虚假订单是否为虚假订单的请求；

相应的，所述装置还包括图2中未示出的第二判断模块26；

所述第二判断模块，用于接收所述订单验证设备验证的结果，并根据所述结果判断是否向终端推送包括该虚假订单中目的地的所有打车请求的订单。

在本公开的一个可选的实施例中，所述第二判断模块26，具体用于：

在所述结果确认所述待验证虚假订单为虚假订单时，在第二预设时间段内不向终端推送目的地与所述虚假订单目的地相同的打车请求的订单。

在本公开的一个可选的实施例中，所述推送模块25，还用于：

在所述第一判断模块确定所述用户设备发送的打车请求的订单为待验证虚假订单时，向距离所述用户设备为预设距离的终端或向预设数量的终端推送包括该虚假订单中目的地的所有打车请求的订单。

在本公开的一个可选的实施例中，所述装置还包括图2中未示出的：第三判断模块27和第二确定模块28；

第三判断模块27，具体用于判断所述打车请求中的用户设备的标识是否属于预设的虚假订单标识数据库；

第二确定模块28，用于在所述第三判断模块27判断所述打车请求中的用户设备的标识属于预设的虚假订单标识数据库时，确定该打车请求对应的订单为虚假订单。对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本公开实施例并不受所描述的动作顺序的限制，因为依据本公开实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本公开实施例所必须的。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

应当注意的是，在本公开的系统的各个部件中，根据其要实现的功能而对其中的部件进行了逻辑划分，但是，本公开不受限于此，可以根据需要对各个部件进行重新划分或者组合，例如，可以将一些部件组合为单个部件，或者可以将一些部件进一步分解为更多的子部件。

本公开的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本公开实施例的系统中的一些或者全部部件的一些或者全部功能。本公开还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本公开的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本公开进行说明而不是对本公开进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本公开可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (8)

1.一种虚假订单的识别方法，其特征在于，包括：

接收用户设备发送的打车请求，所述打车请求包括目的地；

获取在第一预设时间段内与所述目的地相同的所有订单；

根据所述所有订单的总个数，以及所述所有订单中订单的状态为被终端投诉或取消的订单个数，确定所述所有订单中订单的状态为被终端投诉或取消的概率；所述终端为向用户设备提供运营服务的终端；

根据包含所述目的地的所有订单的数量以及所述概率，判断所述用户设备发送的打车请求的订单是否为虚假订单；

所述根据包含所述目的地的所有订单的数量以及所述概率，判断所述用户设备发送的打车请求的订单是否为虚假订单，包括：

在所述订单的数量大于等于第一预设阈值，且所述概率大于第二预设阈值时，所述用户设备发送的打车请求的订单为虚假订单；

在第二预设时间段内不向终端推送包括该虚假订单中目的地的所有打车请求的订单。

2.根据权利要求1所述的方法，其特征在于，所述根据包含所述目的地的所有订单的数量以及所述概率，判断所述用户设备发送的打车请求的订单是否为虚假订单，包括：

在所述订单的数量大于等于第一预设阈值，且所述概率大于第三预设阈值且小于第二预设阈值时，所述用户设备发送的打车请求的订单为待验证虚假订单；

向符合预设条件的终端推送包括该虚假订单中目的地的所有打车请求的订单，同时还向订单验证设备推送验证所述待验证虚假订单是否为虚假订单的请求；

接收所述订单验证设备验证的结果，并根据所述结果判断是否向终端推送包括该虚假订单中目的地的所有打车请求的订单。

3.根据权利要求2所述的方法，其特征在于，所述接收所述订单验证设备验证的结果，并根据所述结果判断是否向终端推送包括该虚假订单中目的地的所有打车请求的订单，包括：

在根据所述结果确认所述待验证虚假订单为虚假订单时，在第二预设时间段内不向终端推送包括该虚假订单中目的地的所有打车请求的订单。

4.根据权利要求2所述的方法，其特征在于，所述向符合预设条件的终端推送包括该虚假订单中目的地的所有打车请求的订单，包括：

向距离所述用户设备为预设距离的终端或向预设数量的终端推送包括该虚假订单中目的地的所有打车请求的订单。

5.一种虚假订单的识别装置，其特征在于，包括：

接收模块，用于接收用户设备发送的打车请求，所述打车请求包括目的地；

获取模块，用于获取在第一预设时间段内与所述目的地相同的所有订单；

第一确定模块，用于根据所述所有订单的总个数，以及所述所有订单中订单的状态为被终端投诉或取消的订单个数，确定所述所有订单中订单的状态为被终端投诉或取消的概率；所述终端为向用户设备提供运营服务的终端；

第一判断模块，用于根据包含所述目的地的所有订单的数量以及所述概率，判断所述用户设备发送的打车请求的订单是否为虚假订单；

所述第一判断模块，具体用于在所述订单的数量大于等于第一预设阈值，且所述概率大于第二预设阈值时，确定所述用户设备发送的打车请求的订单为虚假订单；

所述装置还包括推送模块；

所述推送模块，用于在所述第一判断模块判断所述用户设备发送的打车请求的订单为虚假订单时，在第二预设时间段内不向终端推送包括该虚假订单中目的地的所有打车请求的订单。

6.根据权利要求5所述的装置，其特征在于，所述第一判断模块，还用于：

在所述订单的数量大于等于第一预设阈值，且所述概率大于第三预设阈值且小于第二预设阈值时，确定所述用户设备发送的打车请求的订单为待验证虚假订单；

相应的，推送模块，还用于：

在所述第一判断模块判断所述用户设备发送的打车请求的订单为待验证虚假订单时，向符合预设条件的终端推送包括该虚假订单中目的地的所有打车请求的订单，同时还向订单验证设备推送验证所述待验证虚假订单是否为虚假订单的请求；

相应的，所述装置还包括第二判断模块；

所述第二判断模块，用于接收所述订单验证设备验证的结果，并根据所述结果判断是否向终端推送包括该虚假订单中目的地的所有打车请求的订单。

7.根据权利要求6所述的装置，其特征在于，所述第二判断模块，还用于：

在根据所述结果确认所述待验证虚假订单为虚假订单时，在第二预设时间段内不向终端推送包括该虚假订单中目的地的所有打车请求的订单。

8.根据权利要求6所述的装置，其特征在于，所述推送模块，还用于：

在所述第一判断模块确定所述用户设备发送的打车请求的订单为待验证虚假订单时，向距离所述用户设备为预设距离的终端或向预设数量的终端推送包括该虚假订单中目的地的所有打车请求的订单。

Images