确定派单司机的方法、装置以及存储介质与流程

文档序号:17590724发布日期:2019-05-03 21:47阅读:266来源:国知局
确定派单司机的方法、装置以及存储介质与流程

本申请涉及网约车领域,特别是涉及一种确定派单司机的方法、装置以及存储介质。



背景技术:

随着社会的发展与进步,网约车出行已经成为了一种主流的出行方式。利用网约车出行不仅能够降低出行的成本,还能提高出行的效率。乘客利用出行软件下单,很快就会有司机进行接单,非常方便快捷。但是,网约车过程中的订单分配存在一定的问题,例如:网约车平台在分配订单的时候,对于同一个订单有超过1名司机愿意接受,此时就存在订单分配给哪位司机最合理的问题。现有的技术包括:派给距离乘客最近的司机或者派给抢单速度最快的司机,但是派给距离乘客最近的司机的技术缺点是对于先抢单的司机不公平,容易引起投诉,而派给抢单速度最快的司机的技术缺点是相比于较近的司机,存在较大的浪费。因此,难以实现从超过1名司机中筛选出最合理的司机进行绑定订单的操作。

针对上述的现有技术中存在的网约车平台分配订单的过程中,难以实现从多名司机中确定出最合理的司机进行派单的技术问题,目前尚未提出有效的解决方案。



技术实现要素:

本公开的实施例提供了一种确定派单司机的方法、装置以及存储介质,以至少解决现有技术中存在的网约车平台分配订单的过程中,难以实现从多名司机中确定出最合理的司机进行派单的技术问题。

根据本公开实施例的一个方面,提供了一种确定派单司机的方法,包括:从对约车订单执行抢单操作的司机中确定多个候选司机;获取多个候选司机的抢单信息,其中抢单信息包括多个候选司机的在线时长、多个候选司机的抢单速度以及多个候选司机与约车订单的起点之间的行驶距离;以及根据抢单信息,从多个候选司机中确定作为派单对象的派单司机。

根据本公开实施例的另一个方面,还提供了一种存储介质,所述存储介质包括存储的程序,其中,在所述程序运行时由处理器执行以上任意一项所述的方法。

根据本公开实施例的另一个方面,还提供了一种确定派单司机的装置,包括:第一确定模块,用于从对约车订单执行抢单操作的司机中确定多个候选司机;获取模块,用于获取多个候选司机的抢单信息,其中抢单信息包括多个候选司机的在线时长、多个候选司机的抢单速度以及多个候选司机与约车订单的起点之间的行驶距离;以及第二确定模块,用于根据抢单信息,从多个候选司机中确定作为派单对象的派单司机。

根据本公开实施例的另一个方面,还提供了一种确定派单司机的装置,包括:处理器;以及存储器,与处理器连接,用于为处理器提供处理以下处理步骤的指令:从对约车订单执行抢单操作的司机中确定多个候选司机;获取多个候选司机的抢单信息,其中抢单信息包括多个候选司机的在线时长、多个候选司机的抢单速度以及多个候选司机与约车订单的起点之间的行驶距离;以及根据抢单信息,从多个候选司机中确定作为派单对象的派单司机。

在本公开实施例中,通过网约车平台的服务器首先确定多个候选司机,然后服务器根据多个候选司机的抢单信息(包括:在线时长、抢单速度以及与所述约车订单的起点的距离等因素),从多个候选司机中确定派单司机。从而,达到了从多个维度确定派单司机的目的,并且还能够提高司机积极性,实现了为广大司机提供一个相对公平的抢单环境的技术效果。进而解决了现有技术中存在的网约车平台分配订单的过程中,难以实现从多名司机中确定出最合理的司机进行派单的技术问题。

附图说明

此处所说明的附图用来提供对本公开的进一步理解,构成本申请的一部分,本公开的示意性实施例及其说明用于解释本公开,并不构成对本公开的不当限定。在附图中:

图1是用于实现根据本公开实施例1所述的方法的【计算机终端(或移动设备)】的硬件结构框图;

图2是根据本公开实施例1所述的确定派单司机的系统的示意图;

图3是根据本公开实施例1的第一个方面所述的确定派单司机的方法的流程示意图;

图4是根据本公开实施例2所述的确定派单司机的装置的示意图;以及

图5是根据本公开实施例3所述的确定派单司机的装置的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本公开的技术方案,下面将结合本公开实施例中的附图,对本公开实施例中的技术方案进行清楚、完整地描述。显然,所描述的实施例仅仅是本公开一部分的实施例,而不是全部的实施例。基于本公开中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本公开保护的范围。

需要说明的是,本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本实施例,还提供了一种确定派单司机的方法实施例,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。

本实施例所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。图1示出了一种用于实现确定派单司机的方法的计算机终端(或移动设备)的硬件结构框图。如图1所示,计算机终端10(或移动设备10)可以包括一个或多个(图中采用102a、102b,……,102n来示出)处理器102(处理器102可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输模块106。除此以外,还可以包括:显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解,图1所示的结构仅为示意,其并不对上述电子装置的结构造成限定。例如,计算机终端10还可包括比图1中所示更多或者更少的组件,或者具有与图1所示不同的配置。

应当注意到的是上述一个或多个处理器102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外,数据处理电路可为单个独立的处理模块,或全部或部分的结合到计算机终端10(或移动设备)中的其他元件中的任意一个内。如本公开实施例中所涉及到的,该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器104可用于存储应用软件的软件程序以及模块,如本公开实施例中的确定派单司机的方法对应的程序指令/数据存储装置,处理器102通过运行存储在存储器104内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述的应用程序的确定派单司机的方法。存储器104可包括高速随机存储器,还可包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器104可进一步包括相对于处理器102远程设置的存储器,这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中,传输装置106包括一个网络适配器(networkinterfacecontroller,nic),其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中,传输装置106可以为射频(radiofrequency,rf)模块,其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(lcd),该液晶显示器可使得用户能够与计算机终端10(或移动设备)的用户界面进行交互。

此处需要说明的是,在一些可选实施例中,上述图1所示的计算机设备(或移动设备)可以包括硬件元件(包括电路)、软件元件(包括存储在计算机可读介质上的计算机代码)、或硬件元件和软件元件两者的结合。应当指出的是,

图1仅为特定具体实例的一个实例,并且旨在示出可存在于上述计算机设备(或移动设备)中的部件的类型。

图2是根据本实施例所述的确定派单司机的系统的示意图。参照图2所示,该系统可以是网约车平台系统,该系统包括:服务器210。其中,司机231、司机232、司机233以及司机234可以是在该约车平台服务器210注册的网约车司机,用户220可以在该约车平台进行约车。需要说明的是,系统中的服务器210可适用上面所述的硬件结构。

在上述运行环境下,根据本实施例的第一个方面,提供了一种确定派单司机的方法,该方法由图2中所示的服务器210实现。图3示出了该方法的流程示意图,参考图3所示,该方法包括:

s302:从对约车订单执行抢单操作的司机中确定多个候选司机;

s304:获取多个候选司机的抢单信息,其中抢单信息包括多个候选司机的在线时长、多个候选司机的抢单速度以及多个候选司机与约车订单的起点之间的行驶距离;以及

s306:根据抢单信息,从多个候选司机中确定作为派单对象的派单司机。

正如前面背景技术中所述的,随着社会的发展与进步,网约车出行已经成为了一种主流的出行方式。利用网约车出行不仅能够降低出行的成本,还能提高出行的效率。乘客利用出行软件下单,很快就会有司机进行接单,非常方便快捷。但是,网约车过程中的订单分配存在一定的问题,例如:网约车平台在分配订单的时候,对于同一个订单有超过1名司机愿意接受,此时就存在订单分配给哪位司机最合理的问题。现有的技术包括:派给距离乘客最近的司机或者派给抢单速度最快的司机,但是派给距离乘客最近的司机的技术缺点是对于先抢单的司机不公平,容易引起投诉,而派给抢单速度最快的司机的技术缺点是相比于较近的司机,存在较大的浪费。因此,难以实现从超过1名司机中筛选出最合理的司机进行绑定订单的操作。

具体地,参考图2所示,针对上述背景技术中存在的问题,本实施例的技术方案所提供的服务器210从对约车订单执行抢单操作的司机中确定多个候选司机。例如:对于用户220的约车订单,有多个司机进行抢单操作(例如,司机231、司机232、司机233以及司机234),此时服务器210从多个执行抢单操作的司机(即,司机231、司机232、司机233以及司机234)中确定多个候选司机,例如候选司机可以是司机231、司机232以及司机233。

进一步地,服务器210获取多个候选司机(即,司机231、司机232以及司机233)的抢单信息,其中抢单信息包括多个候选司机的在线时长、抢单速度以及与约车订单的起点的距离。

最终,服务器210根据抢单信息(包括在线时长、抢单速度以及与约车订单的起点的距离),从多个候选司机(司机231、司机232以及司机233)中确定作为派单对象的派单司机,例如派单司机可以是司机231,即:约车平台将用户220的订单信息派送给司机231,此时司机231对用户220的约车订单进行服务。

其中,在线时长体现了网约车司机在线提供网约车服务的时间长度。因此在线时长越长,说明网约车司机在线提供网约车服务的时间越长。因此,将在线时长作为确定派单司机的一个因素,有利于提高司机提供服务的积极性。抢单速度能够体现出司机对客户的请求进行反馈的速度,因此将抢单速度作为确定派单司机的一个因素,有利于提高司机对客户的请求进行反馈的积极性,从而减少客户等待的时间,提高服务质量。司机与约车订单的起点的距离,体现出司机到达客户的距离。司机距离客户越远,则客户等待的时间越长;司机距离客户越近,则客户等待的时间越短。从而选择距离合适的司机,有利于提高服务质量,减少客户等待的时间。

从而通过这种方式,服务器210首先从对约车订单执行抢单操作的司机中确定多个候选司机,然后服务器210根据多个候选司机的抢单信息(包括:在线时长、抢单速度以及与所述约车订单的起点的距离等因素),从多个候选司机中确定派单司机。从而,达到了从多个维度确定派单司机的目的,既能提高司机提供服务的积极性,又能缩短客户的等待时间。实现了为广大司机提供一个相对公平的抢单环境的技术效果。进而解决了现有技术中存在的网约车平台分配订单的过程中,难以实现从多名司机中确定出最合理的司机进行派单的技术问题。

此外,可选地,所述的在线时长、抢单速度以及与约车订单的起点的距离为经过统一化计算的统一化数据。其中:

在线时长的统一化数据的计算公式可以是:其中y1为候选司机的在线时长的统一化数据,x1为候选司机的实际在线时长,例如司机231的在线时长为3000秒,此时x1值为3000。

与约车订单的起点的行驶距离的统一化数据的计算公式可以是:其中y2为候选司机与约车订单的起点之间的行驶距离的统一化数据,x2的值为候选司机距离用户220的约车订单起点之间的实际行驶距离,例如500米。

抢单速度的统一化数据的计算公式可以是:其中其中y3为候选司机的抢单速度的统一化数据,x3为所述候选司机的实际抢单速度,其中抢单速度为从订单发布时间计算,例如:服务器210发布用户220的订单时间为10:00,而司机231的抢单时间为10:05,此时司机的抢单速度为5秒(即,x3的值);

此外,经过上述公式得出的y1、y2以及y3的值小于0时按0计算,大于100时按100计算。

上述公式中的max与min值如下表所示,并且max值为可变值,如表1所示:

表1

从而,由于采用了统一化的数据,从而可以简化后续的计算,有利于后续的数据处理。

可选地,根据抢单信息,从多个候选司机中确定作为派单对象的派单司机的操作,包括:根据抢单信息以及与抢单信息中的参数相关的权重,从多个候选司机中确定作为派单对象的派单司机。

具体地,在服务器210根据抢单信息,从多个候选司机中确定作为派单对象的派单司机的操作中,服务器210根据抢单信息以及与抢单信息中的参数相关的权重,从多个候选司机中确定作为派单对象的派单司机。例如:候选司机231的抢单信息中的多个参数(抢单速度、在线时长以及行驶距离)分别对应不同的权重,此时服务器210根据抢单信息以及与抢单信息中的参数对应的权重,从多个候选司机中确定作为派单对象的派单司机。从而通过这种方式,利用权重确定派单司机,可以从不同方面衡量抢单信息中的参数的重要程度,对各个参数区别对待,使得确定派单司机的过程更加严谨。

可选地,根据抢单信息以及与抢单信息中的参数相关的权重,从多个候选司机中确定作为派单对象的派单司机的操作,包括:分别针对多个候选司机,根据与在线时长对应的第一权重、与抢单速度对应的第二权重以及与行驶距离对应的第三权重,对在线时长、抢单速度以及行驶距离进行加权求和,确定多个候选司机的分值;以及根据所确定的分值,从多个候选司机中确定作为派单对象的派单司机。

具体地,在服务器210根据抢单信息以及与抢单信息中的参数相关的权重,从多个候选司机中确定作为派单对象的派单司机的操作中,服务器210分别针对各个候选司机(即,司机231、司机232以及司机233),根据与在线时长对应的第一权重、与抢单速度对应的第二权重以及与行驶距离对应的第三权重,对在线时长、抢单速度以及行驶距离进行加权求和,确定多个候选司机的分值。例如:经过上述的在线时长计算公式、抢单速度计算公式以及行驶距离计算公式得出候选司机231的在线时长y1=96.5,行驶距离y2=97.5,抢单速度y3=99.7。例如:与在线时长对应的第一权重为30%,与抢单速度对应的第二权重为20%,与行驶距离对应的第三权重为50%。此时服务器210对在线时长、抢单速度以及行驶距离进行加权求和,确定多个候选司机的分值。例如:加权计算公式为:y1*第一权重+y2*第二权重+y3*第三权重。候选司机231的分值为y1*30%+y2*20%+y3*50%=98.3,同理例如候选司机232的分值为95,同理例如候选司机233的分值为90。然后,服务器210根据所确定的分值(即,98.3、95以及90),从多个候选司机中确定作为派单对象的派单司机。其中候选司机231的分值最高,此时候选司机231为派单司机。从而加权计算的方式得到多个候选司机的分值,然后根据分值得出派单司机。采用分值的形式确定派单司机,可以使结果更加显而易见,简化了分析的过程,进一步优化了计算分析过程。

可选地,还包括:根据约车订单的提交时间,确定第一权重;和/或根据与约车订单相对应的时间段内的约车订单数量,确定第二权重;和/或根据约车订单的起点附近的交通状况,确定第三权重。

具体地,服务器210根据约车订单的提交时间,确定第一权重。例如:订单的提交时间可以分为不同的时间段(早晨、中午以及晚上),如果订单的提交时间是晚上的话,此时考虑到在线时长,第一权重的所占的比例会增大。服务器210根据与约车订单相对应的时间段内的约车订单数量,确定第二权重。其中与该约车订单(即,用户220的约车订单)相对应的时间段的订单数量,例如:订单的时间为17:55,与之相对应的时间段可以确定为18:00左右,此时的订单数量可能会相对较大,考虑到抢单速度的因素,第二权重所占的比例会增大。以及服务器210根据约车订单的起点附近的交通状况,确定第三权重。例如:用户220的订单的起点位置的交通状况比较拥堵,为了能够准时为用户220提供服务,此时第三权重所占的比例会相应增大。从而通过这种方式,可以在不同的时间段、根据不同的路况确定出不同的权重方案,因此使得网约车平台可以应对不同的环境与场景,满足用户的需求并且为用户带来优质体验,使得平台更加人性化。

可选地,还包括:在分值中的最高分值对应的候选司机为多个司机的情况下,从最高分对应的多个候选司机中确定注册id的id值最小的候选司机为派单司机。

具体地,例如候选司机231的分值为90、候选司机232的分值为90、候选司机233的分值为85,所以最高分90对应的候选司机为司机231与司机232。此时,服务器210考虑候选司机的注册id,例如:司机231的注册id为100,司机232的注册id为101,服务器210可能选择注册id小的(注册时间早)作为派单司机。通过这种方式,可以更加照顾资格老的司机,使得确定派单司机的方式更加合理。

可选地,还包括:接收派单司机的反馈信息,其中反馈信息记录派单司机是否接单成功;以及在派单司机没有接单成功的情况下,对权重进行修正。

具体地,服务器210接收派单司机(司机231)的反馈信息,会分析是在哪个维度出现了问题。从而服务器210会根据反馈信息对权重进行修正。从而可以使网约车平台实时了解该权重方案是否分配合理,以及能否应对当时的场景,使得确定派单司机的方式更加严谨。

可选地,从对约车订单执行抢单操作的司机中确定多个候选司机的操作,包括:确定首个对约车订单执行抢单操作的司机的抢单时间;以及将抢单时间之后的预定时间内执行抢单操作的司机确定为多个候选司机。

具体地,在服务器210从对约车订单执行抢单操作的司机中确定多个候选司机的操作中,服务器210首先确定首个对约车订单执行抢单操作的司机的抢单时间。其中,约车平台发布用户220的约车订单后会有多个司机进行抢单操作,此时服务器210会确定第一个执行抢单操作的司机的抢单时间,例如:司机321的抢单时间为10:01、司机232的抢单时间为10:02、司机233的抢单时间为10:03、司机234的抢单时间为10:10,所以首个抢单的司机为司机231,并且抢单时间为10:01。然后,服务器210将抢单时间(10:01)之后的预定时间(5分钟)内执行抢单操作的司机确定为多个候选司机,所以候选司机为:司机231、司机232以及司机233。从而通过这种方式,可以初步确定出候选司机,缩小了派单司机的确定范围,并且确定预定时间内的抢单司机为候选司机,考虑到了用户的等车时间的因素,为用户带来优质体验。

此外,参考图1所示,根据本实施例的第二个方面,提供了一种存储介质104。所述存储介质104包括存储的程序,其中,在所述程序运行时由处理器执行以上任意一项所述的方法。

从而根据本实施例,通过服务器210首先从对约车订单执行抢单操作的司机中确定多个候选司机,然后服务器210根据多个候选司机的抢单信息(包括:在线时长、抢单速度以及与所述约车订单的起点的距离等因素),从多个候选司机中确定派单司机。从而,达到了从多个维度确定派单司机的目的,并且对长时间在线工作的司机进行了相应的补偿,提高司机的积极性。实现了为广大司机提供一个相对公平的抢单环境的技术效果。进而解决了现有技术中存在的网约车平台分配订单的过程中,难以实现从多名司机中确定出最合理的司机进行派单的技术问题。

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

通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

图4示出了根据本实施例所述的确定派单司机的装置400,该装置400与根据实施例1的第一个方面所述的方法相对应。参考图4所示,该装置400包括:第一确定模块410,用于从对约车订单执行抢单操作的司机中确定多个候选司机;获取模块420,用于获取多个候选司机的抢单信息,其中抢单信息包括多个候选司机的在线时长、多个候选司机的抢单速度以及多个候选司机与约车订单的起点之间的行驶距离;以及第二确定模块430,用于根据抢单信息,从多个候选司机中确定作为派单对象的派单司机。

可选地,第二确定模块430,包括:确定子模块,用于根据抢单信息以及与抢单信息中的参数相关的权重,从多个候选司机中确定作为派单对象的派单司机。

可选地,确定子模块,包括:第一确定单元,用于分别针对多个候选司机,根据与在线时长对应的第一权重、与抢单速度对应的第二权重以及与行驶距离对应的第三权重,对在线时长、抢单速度以及行驶距离进行加权求和,确定多个候选司机的分值;以及第二确定单元,用于根据所确定的分值,从多个候选司机中确定作为派单对象的派单司机。

可选地,第一确定单元,包括:第一确定子单元,用于根据约车订单的提交时间,确定第一权重;和/或第二确定子单元,用于根据与约车订单相对应的时间段内的约车订单数量,确定第二权重;和/或第三确定子单元,用于根据约车订单的起点附近的交通状况,确定第三权重。

可选地,第二确定单元,包括:确定子单元,用于在分值中的最高分值对应的候选司机为多个司机的情况下,从最高分对应的多个候选司机中确定注册id的id值最小的候选司机为派单司机。

可选地,还包括:接收子模块,用于接收派单司机的反馈信息,其中反馈信息记录派单司机是否接单成功;以及修正子模块,用于在派单司机没有接单成功的情况下,对权重进行修正。

可选地,第一确定模块410,包括:时间确定子模块,用于确定首个对约车订单执行抢单操作的司机的抢单时间;以及对象确定子模块,用于将抢单时间之后的预定时间内执行抢单操作的司机确定为多个候选司机。

从而根据本实施例,通过确定派单司机的装置400首先从对约车订单执行抢单操作的司机中确定多个候选司机,然后确定派单司机的装置400根据多个候选司机的抢单信息(包括:在线时长、抢单速度以及与所述约车订单的起点的距离等因素),从多个候选司机中确定派单司机。从而,达到了从多个维度确定派单司机的目的,并且对长时间在线工作的司机进行了相应的补偿,提高司机的积极性。实现了为广大司机提供一个相对公平的抢单环境的技术效果。进而解决了现有技术中存在的网约车平台分配订单的过程中,难以实现从多名司机中确定出最合理的司机进行派单的技术问题。

实施例3

图5示出了根据本实施例所述的确定派单司机的装置500,该装置500与根据实施例1的第一个方面所述的方法相对应。参考图5所示,该装置500包括:处理器510;以及存储器520,与处理器510连接,用于为处理器510提供处理以下处理步骤的指令:从对约车订单执行抢单操作的司机中确定多个候选司机;获取多个候选司机的抢单信息,其中抢单信息包括多个候选司机的在线时长、多个候选司机的抢单速度以及多个候选司机与约车订单的起点之间的行驶距离;以及根据抢单信息,从多个候选司机中确定作为派单对象的派单司机。

可选地,根据抢单信息,从多个候选司机中确定作为派单对象的派单司机的操作,包括:根据抢单信息以及与抢单信息中的参数相关的权重,从多个候选司机中确定作为派单对象的派单司机。

可选地,根据抢单信息以及与抢单信息中的参数相关的权重,从多个候选司机中确定作为派单对象的派单司机的操作,包括:分别针对多个候选司机,根据与在线时长对应的第一权重、与抢单速度对应的第二权重以及与行驶距离对应的第三权重,对在线时长、抢单速度以及行驶距离进行加权求和,确定多个候选司机的分值;以及根据所确定的分值,从多个候选司机中确定作为派单对象的派单司机。

可选地,存储器520还配置用于为处理器510处理以下指令:根据约车订单的提交时间,确定第一权重;和/或根据与约车订单相对应的时间段内的约车订单数量,确定第二权重;和/或根据约车订单的起点附近的交通状况,确定第三权重。

可选地,存储器520还配置用于为处理器510处理以下指令:在分值中的最高分值对应的候选司机为多个司机的情况下,从最高分对应的多个候选司机中确定注册id的id值最小的候选司机为派单司机。

可选地,存储器520还配置用于为处理器510处理以下指令:接收派单司机的反馈信息,其中反馈信息记录派单司机是否接单成功;以及在派单司机没有接单成功的情况下,对权重进行修正。

可选地,从对约车订单执行抢单操作的司机中确定多个候选司机的操作,包括:确定首个对约车订单执行抢单操作的司机的抢单时间;以及将抢单时间之后的预定时间内执行抢单操作的司机确定为多个候选司机。

从而根据本实施例,通过确定派单司机的装置500首先从对约车订单执行抢单操作的司机中确定多个候选司机,然后确定派单司机的装置500根据多个候选司机的抢单信息(包括:在线时长、抢单速度以及与所述约车订单的起点的距离等因素),从多个候选司机中确定派单司机。从而,达到了从多个维度确定派单司机的目的,并且对长时间在线工作的司机进行了相应的补偿,提高司机的积极性。实现了为广大司机提供一个相对公平的抢单环境的技术效果。进而解决了现有技术中存在的网约车平台分配订单的过程中,难以实现从多名司机中确定出最合理的司机进行派单的技术问题。

上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。

在本发明的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中,应该理解到,所揭露的技术内容,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:u盘、只读存储器(rom,read-onlymemory)、随机存取存储器(ram,randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1