CN105590448A - 一种基于打车的警报方法和装置 - Google Patents

Abstract

本申请实施例提供了一种基于打车的警报方法和装置，所述的方法包括：当接收到第一客户端发送的第一打车请求时，根据所述第一打车请求确定匹配的目标第二客户端；监测所述第一客户端所在的位置；根据所述位置判断是否符合预设的毁约规则；若是，则发送警报信息至所述目标第二客户端。本申请实施例使得第二客户端所属的用户可以尽早进行风险处理，以减少燃料资源，降低人力成本和时间成本。

Description

一种基于打车的警报方法和装置

技术领域

本申请涉及交通技术领域，特别是涉及一种基于打车的警报方法和一种基于打车的警报装置。

背景技术

近年来，随着经济的快速发展和人们收入水平的不断提升，越来越多的人选择出租车代步出行。

目前市面上乘客经常使用打车程序呼叫出租车，出租车司机接收到呼叫后便去约定的地方搭乘乘客。

但是，由于乘客与出租车司机达成的搭乘约定一般不具有强制的约束性，用户毁约成本很低，致使乘客使用打车程序呼叫出租车时经常会毁约。

例如，乘客呼叫了出租车，出租车司机也已经确认这笔订单，正在赶去约定地方的路上。这时刚好有未载客的出租车到来，乘客直接搭乘该未载客的出租车离开了，或者，乘客正好等到公交车来了，就搭乘坐公交车离开了。

出租车司机经常在乘客毁约后才到达约定地方，但是乘客已经离开了，出租车司机白白耗费了大量的诸如石油、天然气等燃料资源，人力成本、时间成本也很高。

因此，目前需要本领域技术人员迫切解决的一个技术问题就是：如何提出一种基于打车的警报机制，以减少燃料资源，降低人力成本和时间成本。

发明内容

本申请实施例所要解决的技术问题是提供一种基于打车的警报方法，以减少燃料资源，降低人力成本和时间成本。

相应的，本申请实施例还提供了一种基于打车的警报装置，以减少燃料资源，降低人力成本和时间成本。

为了解决上述问题，本申请实施例公开了一种基于打车的警报方法，包括：

当接收到第一客户端发送的第一打车请求时，根据所述第一打车请求确定匹配的目标第二客户端；

监测所述第一客户端所在的位置；

根据所述位置判断是否符合预设的毁约规则；若是，则发送警报信息至所述目标第二客户端。

优选地，所述根据所述第一打车请求确定匹配的目标第二客户端的步骤包括：

从所述第一打车请求中提取所述第一客户端所在的呼叫地点和打车信息；

基于所述呼叫地点确定寻车范围；

采用所述呼叫地点和/或所述打车信息生成第二打车请求；

将所述第二打车请求发送至在所述寻车范围内的一个或多个第二客户端；

当接收到所述第二客户端针对所述第二打车请求返回的确认指示时，确定所述第二客户端为目标第二客户端。

优选地，所述位置包括原始位置，和，一个或多个目标位置；

其中，所述原始位置为所述第一客户端在确定匹配的目标第二客户端时的位置；

所述一个或多个目标位置为所述第一客户端在确定匹配的目标第二客户端之后的，一个或多个目标时间的一个或多个位置。

优选地，所述毁约规则包括位置毁约规则和移动毁约规则中的至少一个，所述根据所述位置判断是否符合预设的毁约规则的步骤包括：

计算所述一个或多个目标位置与所述原始位置之间的一个或多个距离；

判断所述一个或多个距离是否符合位置毁约规则和移动毁约规则中的至少一个；若是，则判断符合预设的毁约规则。

优选地，所述判断所述一个或多个距离是否符合位置毁约规则和移动毁约规则中的至少一个的步骤包括：

当所述距离大于预设的差距阈值时，判断符合位置毁约规则。

优选地，所述判断所述一个或多个距离是否符合位置毁约规则和移动毁约规则中的至少一个的步骤包括：

当相邻的多个距离递增时，判断符合移动毁约规则；

其中，所述相邻的多个距离为在多个相邻的目标时间的多个目标位置，与所述原始位置之间的多个距离。

本申请实施例还公开了一种基于打车的警报装置，包括：

目标确定模块，用于在接收到第一客户端发送的第一打车请求时，根据所述第一打车请求确定匹配的目标第二客户端；

位置监测模块，用于监测所述第一客户端所在的位置；

毁约规则判断模块，用于根据所述位置判断是否符合预设的毁约规则；若是，则调用警报模块；

警报模块，用于发送警报信息至所述目标第二客户端。

优选地，所述目标确定模块包括：

提取子模块，用于从所述第一打车请求中提取所述第一客户端所在的呼叫地点和打车信息；

第一确定子模块，用于基于所述呼叫地点确定寻车范围；

生成子模块，用于采用所述呼叫地点和/或所述打车信息生成第二打车请求；

发送子模块，用于将所述第二打车请求发送至在所述寻车范围内的一个或多个第二客户端；

第二确定子模块，用于在接收到所述第二客户端针对所述第二打车请求返回的确认指示时，确定所述第二客户端为目标第二客户端。

优选地，所述位置包括原始位置，和，一个或多个目标位置；

其中，所述原始位置为所述第一客户端在确定匹配的目标第二客户端时的位置；

所述一个或多个目标位置为所述第一客户端在确定匹配的目标第二客户端之后的，一个或多个目标时间的一个或多个位置。

优选地，所述毁约规则包括位置毁约规则和移动毁约规则中的至少一个，所述毁约规则判断模块包括：

距离计算子模块，用于计算所述一个或多个目标位置与所述原始位置之间的一个或多个距离；

距离判断子模块，用于判断所述一个或多个距离是否符合位置毁约规则和移动毁约规则中的至少一个；若是，则调用符合判断子模块；

符合判断子模块，用于判断符合预设的毁约规则。

优选地，所述距离判断子模块包括：

位置毁约规则判断子模块，用于在所述距离大于预设的差距阈值时，判断符合位置毁约规则。

优选地，所述位置毁约规则包括：

移动毁约规则判断子模块，用于在相邻的多个距离递增时，判断符合移动毁约规则；

其中，所述相邻的多个距离为在多个相邻的目标时间的多个目标位置，与所述原始位置之间的多个距离。

本申请实施例根据第一客户端发送的第一打车请求确定匹配的目标第二客户端，监测第一客户端所在的位置，以判断是否符合预设的毁约规则，若是，则发送警报信息至目标第二客户端，使得第二客户端所属的用户可以尽早进行风险处理，以减少燃料资源，降低人力成本和时间成本。

本申请实施例从位置状态、移动状态等设置位置毁约规则、移动毁约规则，以静态、动态地进行毁约风险的评估，提高了判断毁约风险的准确性。

附图说明

图1是本申请的一种基于打车的警报方法实施例的步骤流程图；

图2是本申请的一种基于打车的警报装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

参照图1，示出了本申请的一种基于打车的警报方法实施例的步骤流程图，具体可以包括如下步骤：

步骤101，当接收到第一客户端发送的第一打车请求时，根据所述第一打车请求确定匹配的目标第二客户端；

需要说明的是，本申请实施例可以应用于服务器(如云服务器)中，该服务器可以与一个或多个电子设备通过网络连接，该电子设备具体可以包括手机、PDA(PersonalDigitalAssistant，个人数字助理)、膝上型计算机、掌上电脑等等，本申请实施例对此不加以限制。

这些电子设备可以支持包括Windows、Android(安卓)、IOS、WindowsPhone等操作***，通常可以运行通过语音、键盘(包括物理键盘、虚拟键盘)等方式进行输入、显示电子地图等功能的客户端，例如第一客户端和第二客户端。

其中，第一客户端可以由乘客角色的用户登录账号，第二客户端可以由司机角色的用户登录账号。

当乘客角色的用户需要打车服务时，可以通过语音输入、文字输入等方式触发第一打车请求。该第一打车请求可以是指乘客角色的用户发出的呼叫汽车(例如，出租车)提供汽车搭乘服务的指示，俗称打车。

在具体实现中，乘客角色的用户可以通过输入一段语言(如“我在中山一路，想去黄埔大道”)来触发第一打车请求，或者，输入一段文字(如搭乘地点为“中山一路”，目的地点为“黄埔大道”)，或者，输入一段视频等方式来触发第一打车请求，等等。

当服务器接收到乘客角色的用户发出的语音或文字等信息时，就相当于接收到了呼叫汽车(例如出租车)的第一打车请求，则可以寻找合适的司机角色的用户，以提供汽车搭乘服务。

在本申请的一种优选实施例中，步骤101可以包括如下子步骤：

子步骤S11，从所述第一打车请求中提取所述第一客户端所在的呼叫地点和打车信息；

在本申请实施例中，第一打车请求可以携带第一客户端在发出第一打车请求时所在的呼叫地点。由于手机等电子设备一般为私人物品，通常只会有一名用户随身携带并使用，因此，第一客户端所在的呼叫地点可以表征乘客角色的用户发出第一打车请求所在的位置。

在实际应用中，该呼叫地点可以通过卫星定位、基站定位等方式获取。

其中，卫星定位的方式可以将电子设备的位置信号发送到定位后台来进行定位。目前可使用的卫星定位***包括GPS、GLONASS、北斗***、Galileo***等等。

基站定位方式可以是利用通信运营商(如移动运营商、联通运营商、电信运营商等)的基站对电子设备的距离的测算距离来确定电子设备的位置。

以GPS为例，所获得的GPS数据GPRMC的格式示例可以如下：

$GPRMC,<1>,<2>,<3>,<4>,<5>,<6>,<7>,<8>,<9>,<10>,<11>,<12>；

其中，字段<1>为标准定位时间(UTCtime)，其格式可以为：时时分分秒秒.秒秒秒(hhmmss.sss)；

字段<2>为定位状态，包括A＝数据可用，V＝数据不可用；

字段<3>为纬度，其格式可以为：度度分分.分分分分(ddmm.mmmm)；

字段<4>为纬度区分，包括北半球(N)或南半球(S)；

字段<5>为经度，其格式可以为：度度分分.分分分分；

字段<6>为经度区分，包括东(E)半球或西(W)半球；

字段<7>为相对位移速度，包括0.0至1851.8knots；

字段<8>为相对位移方向，包括000.0至359.9度；

字段<9>为日期，其格式可以为：日日月月年年(ddmmyy)；

字段<10>为磁偏角，包括000.0°～180.0°；

字段<11>为磁偏角方向，包括E(东)或W(西)；

字段<12>为Checksum(检查位)

在示例中，通过纬度、纬度区分、经度和经度区分可以确定呼叫地点。

此外，第一打车请求中也可以包括打车信息，该打车信息可以为记录乘客角色的用户所需的汽车搭乘服务的信息，具体可以包括搭乘地点、目的地点、预约搭乘的时间、小费等等。

需要说明的是，搭乘地点可以默认为呼叫地点，也可以为与呼叫地点不同的地点，例如，乘客角色的用户指定在某个地点搭乘汽车(例如，出租车)，本申请实施例对此不加以限制。

子步骤S12，基于所述呼叫地点确定寻车范围；

在本申请实施例的一个示例中，可以以该呼叫地点为圆心，指定距离(例如，2千米、3千米等等)为半径，确定圆形的寻车范围。

当然，上述寻车范围只是作为示例，在实施本申请实施例时，可以根据实际情况设置其他寻车范围，例如，可以以该呼叫地点为中心，确定矩形、三角形、棱形等形状的寻车范围，也可以在该呼叫地点的前方、后方、左侧、右侧等方位确定寻车范围，等等，本申请实施例对此不加以限制。另外，除了上述寻车范围外，本领域技术人员还可以根据实际需要采用其它寻车范围，本申请实施例对此也不加以限制。

子步骤S13，采用所述呼叫地点和/或所述打车信息生成第二打车请求；

在实际应用中，服务器可以将呼叫地点、乘客角色的用户所需的汽车搭乘服务的信息，例如搭乘地点、目的地点、预约搭乘的时间、小费等等，按照第二客户端的格式要求进行整理，以生成第二打车请求。该第一打车请求可以是指服务器发出的某个乘客角色的用户呼叫汽车(例如，出租车)提供汽车搭乘服务的指示。

例如，乘客角色的用户(用户ID为10000)在中山一路(呼叫位置)通过输入一段语音“我在中山一路，想去黄埔大道”触发了第一打车请求，并提供10元小费，则服务器接收到该第一打车请求时，提取该呼叫位置、语音和小费数额生成第二打车请求，如“用户10000就在附近，他在中山一路等待打车”，并附带该语音和小费数额。

子步骤S14，将所述第二打车请求发送至在所述寻车范围内的一个或多个第二客户端；

在实际应用中，第二客户端所在的电子设备可以通过卫星定位、基站定位等方式获取其所在的位置，间隔相同的时间(例如，30秒)上传给服务器，服务器可以使用一个线程维护第二客户端的位置。

由于手机等电子设备一般为私人物品，通常只会有一名用户随身携带并使用，并且，司机角色的用户大多数时间在汽车(如出租车)内，因此，第二客户端所在的位置可以表征司机角色的用户以及汽车所在的位置。

服务器将第二打车请求发送至在寻车范围内的一个或多个第二客户端，可以使得司机角色的用户快速到达搭乘地点，让乘客角色的用户获得快捷的汽车搭乘服务。

子步骤S15，当接收到所述第二客户端针对所述第二打车请求返回的确认指示时，确定所述第二客户端为目标第二客户端。

在具体实现中，乘客角色的用户请求汽车搭乘服务，一般可以称其为订单。由于该订单一般只能有一个司机角色的用户接收，则服务器将第二打车请求发送至在寻车范围内的一个或多个第二客户端，司机角色的用户需要按照一定的规则接收该订单。一般可以以最先确认第二打车请求的第二客户端接收订单，即俗称抢单。

当第二客户端针对第二打车请求进行确认时，可以表示司机角色的用户接单成功，汽车搭乘服务的约定成立，即由第一客户端所属的用户请求汽车搭乘服务，由目标第二客户端所属的用户提供汽车搭乘服务。服务器可以分别发送消息给第一客户端和第二客户端，分别告知乘客角色的用户和司机角色的用户订单成立。

步骤102，监测所述第一客户端所在的位置；

在具体实现中，所述位置包括原始位置，和，一个或多个目标位置；

其中，所述原始位置为所述第一客户端在确定匹配的目标第二客户端时的位置；

所述一个或多个目标位置为所述第一客户端在确定匹配的目标第二客户端之后的，一个或多个目标时间的一个或多个位置。

在实际应用中，第一客户端所在的电子设备可以通过卫星定位、基站定位等方式获取其位置，第一客户端可以间隔相同的时间(例如，10秒)向服务器发送位置，服务器可以使用一个线程监听第一客户端发送的位置。

第一客户端接收到服务器发送的订单成立的消息时，向服务器返回的位置信息，可以识别为乘客角色的用户在订单成立时的原始位置，其后，服务器可以从第一客户端隔相同的时间(例如，10秒)发送的其他位置中选取一个或多个合适的目标位置进行毁约规则的判断。

需要说明的是，目标时间可以为第一客户端上传位置的时间中的一个或多个时间点，例如，第2、3、5分钟。

步骤103，根据所述位置判断是否符合预设的毁约规则；若是，则执行步骤104；

应用本申请实施例，可以预先设置表征撕毁汽车搭乘服务的约定的规则(即毁约规则)，若第一客户端的位置符合该毁约规则，则可以表明第一客户端所属的用户有一定的几率毁约，不接受目标第二客户端所属的用户提供的汽车搭乘服务；若第一客户端的位置未符合该毁约规则，则可以表明第一客户端所属的用户有一定的几率遵守约定，接受目标第二客户端所属的用户提供的汽车搭乘服务。

在本申请的一种优选实施例中，所述毁约规则包括位置毁约规则和移动毁约规则中的至少一个，则在本申请实施例中，步骤103可以包括如下子步骤：

子步骤S21，计算所述一个或多个目标位置与所述原始位置之间的一个或多个距离；

在本申请实施例的一种示例中，地球基本上近似一个球形，从赤道到极点平均的分为90个纬度，每个纬度之间的单位距离基本上是111.133km，随着纬度的升高或降低，单位距离有微弱的减少或增加。

在确定纬度下，纬度的单位距离的计算公式可以是：

和纬度计算方式相比，经度的算法有很大的不同。因为所有的经线在南北两极交汇到极点，所以，纬度越高，每个经度的单位距离越小，到了极点，单位距离为零。一个经度的单位距离可以和根据经度所在的纬度确定。

在确定纬度下，经度的单位距离的计算公式可以是：

经由上述公式(1)和(2)，可以确定两点之间(例如原始位置和目标位置)在经纬度的大致距离。

例如，在北京附近，经纬度的大致距离如下：

纬度改变一度合110.94千米、改变一分合1.849千米、改变一秒合30.8米；

经度改变一度合85.2千米、改变一分合1.42千米、改变一秒合23.69米。

由于第一客户端在短时间内移动的范围较小，则可以将第一客户端所在的地区近似地看成平面，在计算获得原始位置和目标位置在经纬度的大致距离后，可以根据三角函数(如正弦、余弦、正切、余切、正割、余割等等)、勾股定理等方式计算出目标位置信息与原始位置信息之间的一个或多个距离。

当然，上述距离的计算方式只是作为示例，在实施本申请实施例时，可以根据实际情况设置其他距离的计算方式，例如，计算从原始位置沿街道移动至目标位置的最小距离等等，本申请实施例对此不加以限制。

子步骤S22，判断所述一个或多个距离是否符合位置毁约规则和移动毁约规则中的至少一个；若是，则执行子步骤S23；

在具体实现中，单个目标位置与原始位置之间的单个距离可以表征在单个目标时间上乘客角色的用户的位置状态，本申请实施例可以针对该位置状态设置位置毁约规则，以根据位置状态判断乘客角色的用户是否存在毁约风险。

而多个目标位置与原始位置之间的多个距离可以表征在多个目标时间上乘客角色的用户的移动状态，本申请实施例也可以针对该移动状态设置移动毁约规则，以根据移动状态判断乘客角色的用户是否存在毁约风险。

在本申请实施例的一种优选示例中，子步骤S22进一步可以包括如下子步骤：

子步骤S221，当所述距离大于预设的差距阈值时，判断符合位置毁约规则。

在本申请实施例的另一种优选示例中，子步骤S22进一步可以包括如下子步骤：

子步骤S222，当相邻的多个距离递增时，判断符合移动毁约规则；

其中，所述相邻的多个距离为在多个相邻的目标时间的多个目标位置，与所述原始位置之间的多个距离。

在实际中，由于乘客角色的用户已经发出了第一打车请求，因此乘客角色的用户存在汽车搭乘服务的需求，在此种情况下，乘客角色的用户一般出现几种违约情况，例如在等待第二客户端所属的用户到来的时候，有未载客的其他出租车(俗称“空车”)到来，或者有公交交通工具(如公交、地铁等)到来，该乘客角色的用户直接乘坐该出租车或者坐公交交通工具走了。在这些毁约情况下，该乘客角色的用户很快就能离开原始位置，朝着目的地点出发，一般会出现目标位置与原始位置的距离超过差距阈值(例如，50米)、相邻的多个距离(例如，第2、3、5分钟的目标位置信息)递增等现象。

需要说明的是，位置毁约规则和移动毁约规则一般情况下可以单个使用，为了提高判断的准确度，也可以同时使用，本申请实施例对此不加以限制。

此外，为了提高判断的准确性，本领域技术人员可以根据实际情况设置和调整差距阈值和目标时间，例如，可以考虑司机角色的用户的反馈，也可以考虑推送出违约风险(即警报信息)后实际汽车搭乘服务的约定成交几率共同做调整。

本申请实施例从位置状态、移动状态等设置位置毁约规则、移动毁约规则，以静态、动态地进行毁约风险的评估，提高了判断毁约风险的准确性。

子步骤S23，判断符合预设的毁约规则。

当出现目标位置与原始位置的距离超过差距阈值、相邻的多个距离递增等现象时，则可以判断该乘客角色的用户符合预设的毁约规则，存在毁约风向。

步骤104，发送警报信息至所述目标第二客户端。

当判断第一客户端所述的用户存在毁约风险时，服务器可以发送警报信息至第二客户端，以警告第一客户端所属的用户符合预设的毁约规则，告知第二客户端所属的用户其接收的订单潜在的毁约风险。

其中，该警报信息可以是语音信息(如声量大的警报声)、文字信息(如色彩效果较为明显的警报字体)、图片信息(如色彩效果较为明显的警报图片)等等，本申请实施例对此不加以限制。

第二客户端所属的用户接收到该警报信息，获知潜在的毁约风险后，可以进行相应的风险处理，例如，与第一客户端所属的用户进行电话沟通以确认实际情况、停止到达搭乘地点等等，以减少损失。

本申请实施例根据第一客户端发送的第一打车请求确定匹配的目标第二客户端，监测第一客户端所在的位置，以判断是否符合预设的毁约规则，若是，则发送警报信息至目标第二客户端，使得第二客户端所属的用户可以尽早进行风险处理，以减少燃料资源，降低人力成本和时间成本。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图2，示出了本申请一种基于打车的警报装置实施例的结构框图，具体可以包括如下模块：

目标确定模块201，用于在接收到第一客户端发送的第一打车请求时，根据所述第一打车请求确定匹配的目标第二客户端；

位置监测模块202，用于监测所述第一客户端所在的位置；

毁约规则判断模块203，用于根据所述位置判断是否符合预设的毁约规则；若是，则调用警报模块204；

警报模块204，用于发送警报信息至所述目标第二客户端。

在本申请的一种优选实施例中，所述目标确定模块201可以包括如下子模块：

提取子模块，用于从所述第一打车请求中提取所述第一客户端所在的呼叫地点和打车信息；

第一确定子模块，用于基于所述呼叫地点确定寻车范围；

生成子模块，用于采用所述呼叫地点和/或所述打车信息生成第二打车请求；

发送子模块，用于将所述第二打车请求发送至在所述寻车范围内的一个或多个第二客户端；

第二确定子模块，用于在接收到所述第二客户端针对所述第二打车请求返回的确认指示时，确定所述第二客户端为目标第二客户端。

在具体实现中，所述位置可以包括原始位置，和，一个或多个目标位置；

其中，所述原始位置可以为所述第一客户端在确定匹配的目标第二客户端时的位置；

所述一个或多个目标位置可以为所述第一客户端在确定匹配的目标第二客户端之后的，一个或多个目标时间的一个或多个位置。

在本申请的一种优选实施例中，所述毁约规则可以包括位置毁约规则和移动毁约规则中的至少一个，所述毁约规则判断模块203可以包括如下子模块：

距离计算子模块，用于计算所述一个或多个目标位置与所述原始位置之间的一个或多个距离；

距离判断子模块，用于判断所述一个或多个距离是否符合位置毁约规则和移动毁约规则中的至少一个；若是，则调用符合判断子模块；

符合判断子模块，用于判断符合预设的毁约规则。

在本申请的一种优选实施例中，所述距离判断子模块进一步可以包括如下子模块：

位置毁约规则判断子模块，用于在所述距离大于预设的差距阈值时，判断符合位置毁约规则。

在本申请的一种优选实施例中，所述位置毁约规则进一步可以包括如下子模块：

移动毁约规则判断子模块，用于在相邻的多个距离递增时，判断符合移动毁约规则；

其中，所述相邻的多个距离为在多个相邻的目标时间的多个目标位置，与所述原始位置之间的多个距离。

本申请实施例可以应用于服务器(如云服务器)中，对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种基于打车的警报方法和一种基于打车的警报装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (12)

1.一种基于打车的警报方法，其特征在于，包括：

当接收到第一客户端发送的第一打车请求时，根据所述第一打车请求确定匹配的目标第二客户端；

监测所述第一客户端所在的位置；

根据所述位置判断是否符合预设的毁约规则；若是，则发送警报信息至所述目标第二客户端。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一打车请求确定匹配的目标第二客户端的步骤包括：

从所述第一打车请求中提取所述第一客户端所在的呼叫地点和打车信息；

基于所述呼叫地点确定寻车范围；

采用所述呼叫地点和/或所述打车信息生成第二打车请求；

将所述第二打车请求发送至在所述寻车范围内的一个或多个第二客户端；

当接收到所述第二客户端针对所述第二打车请求返回的确认指示时，确定所述第二客户端为目标第二客户端。

3.根据权利要求1或2所述的方法，其特征在于，所述位置包括原始位置，和，一个或多个目标位置；

其中，所述原始位置为所述第一客户端在确定匹配的目标第二客户端时的位置；

所述一个或多个目标位置为所述第一客户端在确定匹配的目标第二客户端之后的，一个或多个目标时间的一个或多个位置。

4.根据权利要求3所述的方法，其特征在于，所述毁约规则包括位置毁约规则和移动毁约规则中的至少一个，所述根据所述位置判断是否符合预设的毁约规则的步骤包括：

计算所述一个或多个目标位置与所述原始位置之间的一个或多个距离；

判断所述一个或多个距离是否符合位置毁约规则和移动毁约规则中的至少一个；若是，则判断符合预设的毁约规则。

5.根据权利要求4所述的方法，其特征在于，所述判断所述一个或多个距离是否符合位置毁约规则和移动毁约规则中的至少一个的步骤包括：

当所述距离大于预设的差距阈值时，判断符合位置毁约规则。

6.根据权利要求4所述的方法，其特征在于，所述判断所述一个或多个距离是否符合位置毁约规则和移动毁约规则中的至少一个的步骤包括：

当相邻的多个距离递增时，判断符合移动毁约规则；

其中，所述相邻的多个距离为在多个相邻的目标时间的多个目标位置，与所述原始位置之间的多个距离。

7.一种基于打车的警报装置，其特征在于，包括：

目标确定模块，用于在接收到第一客户端发送的第一打车请求时，根据所述第一打车请求确定匹配的目标第二客户端；

位置监测模块，用于监测所述第一客户端所在的位置；

毁约规则判断模块，用于根据所述位置判断是否符合预设的毁约规则；若是，则调用警报模块；

警报模块，用于发送警报信息至所述目标第二客户端。

8.根据权利要求7所述的装置，其特征在于，所述目标确定模块包括：

提取子模块，用于从所述第一打车请求中提取所述第一客户端所在的呼叫地点和打车信息；

第一确定子模块，用于基于所述呼叫地点确定寻车范围；

生成子模块，用于采用所述呼叫地点和/或所述打车信息生成第二打车请求；

发送子模块，用于将所述第二打车请求发送至在所述寻车范围内的一个或多个第二客户端；

第二确定子模块，用于在接收到所述第二客户端针对所述第二打车请求返回的确认指示时，确定所述第二客户端为目标第二客户端。

9.根据权利要求7或8所述的装置，其特征在于，所述位置包括原始位置，和，一个或多个目标位置；

其中，所述原始位置为所述第一客户端在确定匹配的目标第二客户端时的位置；

所述一个或多个目标位置为所述第一客户端在确定匹配的目标第二客户端之后的，一个或多个目标时间的一个或多个位置。

10.根据权利要求9所述的装置，其特征在于，所述毁约规则包括位置毁约规则和移动毁约规则中的至少一个，所述毁约规则判断模块包括：

距离计算子模块，用于计算所述一个或多个目标位置与所述原始位置之间的一个或多个距离；

距离判断子模块，用于判断所述一个或多个距离是否符合位置毁约规则和移动毁约规则中的至少一个；若是，则调用符合判断子模块；

符合判断子模块，用于判断符合预设的毁约规则。

11.根据权利要求10所述的装置，其特征在于，所述距离判断子模块包括：

位置毁约规则判断子模块，用于在所述距离大于预设的差距阈值时，判断符合位置毁约规则。

12.根据权利要求10所述的装置，其特征在于，所述位置毁约规则包括：

移动毁约规则判断子模块，用于在相邻的多个距离递增时，判断符合移动毁约规则；

其中，所述相邻的多个距离为在多个相邻的目标时间的多个目标位置，与所述原始位置之间的多个距离。