CN110717797A - 订单分配方法、装置、服务器和存储介质 - Google Patents

Abstract

本申请提供了订单分配方法、装置、服务器和存储介质，涉及网约车领域。本申请提供的订单分配方法，在订单发生了修改的时候，首选询问了正在为服务请求方提供服务的第一服务提供方的意见，并根据第一服务提供方的意见确定如果对第一订单的服务进行调整，正是由于第一服务提供方是正在为服务请求方提供服务，第一服务提供方有更大的概率继续为服务请求方提供服务，从而提高了订单分配的效率。

Description

订单分配方法、装置、服务器和存储介质

技术领域

本申请涉及网约车领域，具体而言，涉及订单分配方法、装置、 服务器和存储介质。

背景技术

近些年，随着互联网技术的兴盛，传统行业也得到了快速的发展， 比如传统的出租车行业中出现了网约车业务。

网约车的出现，给乘客和司机都带来了极大的便利，乘客可以在 自己出行前就下达订单，来提前预约出行时间和出行地点，以免在出 行时需要花费大量时间在路边等待出租车；同时，出租车司机也可以 在乘客上车前提前预知乘客的目的地，进而选择自己期望的方式乘客 来服务。

发明内容

本申请的目的在于提供订单分配方法、装置、服务器和存储介质。

第一方面，本申请实施例提供了一种订单分配方法，包括：

获取第一客户端发送的针对第一订单的订单修改信息；第一客户 端为服务请求方使用的客户端；

根据订单修改信息，向第二客户端发送提示信息；第二客户端为 接受第一订单的第一服务提供方使用的客户端；提示信息中携带有订 单修改信息；

根据第二客户端返回的针对提示信息的回复信息，对针对第一订 单的服务进行调整。

结合第一方面，本申请实施例提供了第一方面的第一种可能的实 施方式，其中，根据第二客户端返回的针对提示信息的回复信息，对 针对第一订单的服务进行调整，包括：

若回复信息指示第一服务提供方同意接受订单修改信息，则根据 订单修改信息，更新第一服务提供方接受的第一订单的订单信息。

结合第一方面，本申请实施例提供了第一方面的第二种可能的实 施方式，其中，更新第一服务提供方接受的第一订单的订单信息之后， 还包括：

根据订单修改信息，向第一服务提供方推送更新后的导航信息。

结合第一方面，本申请实施例提供了第一方面的第三种可能的实 施方式，其中，根据第二客户端返回的针对提示信息的回复信息，对 针对第一订单的服务进行调整，包括：

若回复信息指示第一服务提供方拒绝接受订单修改信息，则将根 据订单修改信息生成的第二订单派发给其他服务提供方。

结合第一方面，本申请实施例提供了第一方面的第四种可能的实 施方式，其中，若回复信息指示第一服务提供方拒绝接受订单修改信 息，方法还包括：

向第一客户端发送拒绝提示信息；拒绝提示信息用于表示第一服 务提供方拒绝接受修改后的订单信息，且当前处于等待新的司机接单 的状态。

结合第一方面，本申请实施例提供了第一方面的第五种可能的实 施方式，其中，订单修改信息中携带有：目的地更新信息和出发地更 新信息中的至少一种。

结合第一方面，本申请实施例提供了第一方面的第六种可能的实 施方式，其中，根据订单修改信息，向第二客户端发送提示信息，包 括：

判断第一订单是否已被接单，在确定第一订单已被接单后，向接 收第一订单的第二客户端发送提示信息。

结合第一方面，本申请实施例提供了第一方面的第七种可能的实 施方式，其中，方法还包括：

若第一订单未被接单，则根据订单修改信息，更新第一订单的订 单信息，并重新派发更新订单信息后的第一订单。

结合第一方面，本申请实施例提供了第一方面的第八种可能的实 施方式，其中，获取第一客户端发送的针对第一订单的订单修改信息， 包括：

在接收到第二客户端发送的确认乘客上车指示后，获取第一客户 端发送的针对第一订单的订单修改信息。

结合第一方面，本申请实施例提供了第一方面的第九种可能的实 施方式，其中，若在接收到第二客户端发送的确认乘客上车指示后， 获取到第一客户端发送的针对第一订单的订单修改信息，则方法还包 括：

确定在接收到第一客户端发送的订单修改信息时，第二客户端自 发送确认乘客上车指示开始已经行驶的路程；

根据已经行驶的路程，为接受第一订单的司机确定补偿金额。

结合第一方面，本申请实施例提供了第一方面的第是种可能的实 施方式，其中，根据已经行驶的路程，为接受第一订单的司机确定补 偿金额，包括：

若回复信息指示第一服务提供方同意接受订单修改信息，则根据 已经行驶的路程、第一订单对应的修改前的订单信息和订单修改信 息，确定第一服务提供方行驶的额外路程；根据确定的额外路程，确 定补偿金额；

若回复信息指示第一服务提供方拒绝接受订单修改信息，则为第 一服务提供方确定与已经行驶的路程对应的补偿金额。

结合第一方面，本申请实施例提供了第一方面的第十一种可能的 实施方式，其中，已经行驶的路程是按照如下方式得到的：

获取第一客户端的移动路线和第二客户端的移动路线；

根据第一客户端的移动路线和第二客户端的移动路线的重叠部 分，确定共同行驶的路线；

根据共同行驶的路线计算已经行驶的路程。

结合第一方面，本申请实施例提供了第一方面的第十二种可能的 实施方式，其中，在步骤将根据订单修改信息生成的第二订单派发给 其他服务提供方后还包括：

获取第三客户端的当前位置、第二客户端的当前位置和路况信 息；第二客户端为接受第二订单的第二服务提供方使用的客户端；

根据第三客户端的当前位置、第二客户端的当前位置和路况信息 确定交接策略；

将交接策略分别向第二客户端和第三客户端发送。

第二方面，本申请实施例还提供了一种订单分配装置，包括：

第一获取模块，用于获取第一客户端发送的针对第一订单的订单 修改信息；第一客户端为服务请求方使用的客户端；

第一发送模块，用于根据订单修改信息，向第二客户端发送提示 信息；第二客户端为接受第一订单的第一服务提供方使用的客户端； 提示信息中携带有订单修改信息；

调整模块，用于根据第二客户端返回的针对提示信息的回复信 息，对针对第一订单的服务进行调整。

结合第二方面，本申请实施例提供了第二方面的第一种可能的实 施方式，其中，调整模块包括：

第一更新单元，若回复信息指示第一服务提供方同意接受订单修 改信息，则用于根据订单修改信息，更新第一服务提供方接受的第一 订单的订单信息。

结合第二方面，本申请实施例提供了第二方面的第而种可能的实 施方式，其中，还包括：

推送单元，用于根据订单修改信息，向第一服务提供方推送更新 后的导航信息。

结合第二方面，本申请实施例提供了第二方面的第三种可能的实 施方式，其中，调整模块包括：

派发单元，若回复信息指示第一服务提供方拒绝接受订单修改信 息，则用于将根据订单修改信息生成的第二订单派发给其他服务提供 方。

结合第二方面，本申请实施例提供了第二方面的第四种可能的实 施方式，其中，还包括：

第一发送单元，用于向第一客户端发送拒绝提示信息；拒绝提示 信息用于表示第一服务提供方拒绝接受修改后的订单信息，且当前处 于等待新的司机接单的状态。

结合第二方面，本申请实施例提供了第二方面的第五种可能的实 施方式，其中，订单修改信息中携带有：目的地更新信息和出发地更 新信息中的至少一种。

结合第二方面，本申请实施例提供了第二方面的第六种可能的实 施方式，其中，第一发送模块包括：

第二发送单元，用于判断第一订单是否已被接单，在确定第一订 单已被接单后，向接收第一订单的第二客户端发送提示信息。

结合第二方面，本申请实施例提供了第二方面的第七种可能的实 施方式，其中，装置还包括：

重新派发单元，若第一订单未被接单，则用于根据订单修改信息， 更新第一订单的订单信息，并重新派发更新订单信息后的第一订单。

结合第二方面，本申请实施例提供了第二方面的第八种可能的实 施方式，其中，第一获取模块包括：

获取单元，用于在接收到第二客户端发送的确认乘客上车指示 后，获取第一客户端发送的针对第一订单的订单修改信息。

结合第二方面，本申请实施例提供了第二方面的第九种可能的实 施方式，其中，还包括：

第一确定单元，用于确定在接收到第一客户端发送的订单修改信 息时，第二客户端自发送确认乘客上车指示开始已经行驶的路程；

第二确定单元，用于根据已经行驶的路程，为接受第一订单的司 机确定补偿金额。

结合第二方面，本申请实施例提供了第二方面的第十种可能的实 施方式，其中，第二确定单元包括：

第一确定子单元，若回复信息指示第一服务提供方同意接受订单 修改信息，则用于根据已经行驶的路程、第一订单对应的修改前的订 单信息和订单修改信息，确定第一服务提供方行驶的额外路程；根据 确定的额外路程，确定补偿金额；

第二确定子单元，若回复信息指示第一服务提供方拒绝接受订单 修改信息，则用于为第一服务提供方确定与已经行驶的路程对应的补 偿金额。

结合第二方面，本申请实施例提供了第二方面的第十一种可能的 实施方式，其中，还包括：

第二获取模块，用于获取第一客户端的移动路线和第二客户端的 移动路线；

第一确定模块，用于根据第一客户端的移动路线和第二客户端的 移动路线的重叠部分，确定共同行驶的路线；

计算模块，用于根据共同行驶的路线计算已经行驶的路程。

结合第二方面，本申请实施例提供了第二方面的第十二种可能的 实施方式，其中，还包括：

第三获取模块，用于获取第三客户端的当前位置、第二客户端的 当前位置和路况信息；第二客户端为接受第二订单的第二服务提供方 使用的客户端；

第二确定模块，用于根据第三客户端的当前位置、第二客户端的 当前位置和路况信息确定交接策略；

第二发送模块，用于将交接策略分别向第二客户端和第三客户端 发送。

第三方面，本申请实施例还提供了一种具有处理器可执行的非易 失的程序代码的计算机可读介质，程序代码使处理器执行如第一方面 中任一方法。

第四方面，本申请实施例还提供了一种服务器包括：处理器、存 储器和总线，存储器存储有执行指令，当计算设备运行时，处理器与 存储器之间通过总线通信，处理器执行存储器中存储的如第一方面中 任一方法。

本申请实施例提供的一种网约车订单分配方法，在获取到服务请 求方操作第一客户端发出的针对第一订单的订单修改信息时，首先根 据订单修改信息，向第二客户端发送提示信息，其中，第二客户端是 接受第一订单的第一服务提供方使用的客户端；而后，根据第二客户 端返回的针对提示信息的回复信息对第一订单的服务进行调整。也就 是，在订单发生了修改的时候，首选询问了正在为服务请求方提供服 务的第一服务提供方的意见，并根据第一服务提供方的意见确定如果 对第一订单的服务进行调整，正是由于第一服务提供方是正在为服务 请求方提供服务，第一服务提供方有更大的概率继续为服务请求方提 供服务，从而提高了订单分配的效率。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较 佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中 所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申 请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通 技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图 获得其他相关的附图。

图1示出了本申请实施例所提供的一种订单分配方法的基本流 程图；

图2示出了本申请实施例所提供的网约车订单分配方法中，第一 客户端和第二客户端的移动路线的示意图；

图3示出了本申请实施例所提供的网约车订单分配方法中，第一 种优选方案的细节流程图；

图4示出了本申请实施例所提供的网约车订单分配方法中，第二 种优选方案的细节流程图；

图5示出了本申请实施例所提供的一种订单分配装置的基本模 块图；

图6示出了本申请实施例所提供的服务器的示意图。

具体实施方式

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

近些年，网约车业务增长量十分迅速，给居民的生活带来了极大 的方便。

相关技术中，乘客乘坐网约车时，一般是先由乘客向服务器提交 约车订单(包含上车地点、上车时间和目的地)，服务器将约车订单 向多个司机发布，司机根据上车地点、上车时间和目的地来判断自己 是否期望完成该约车订单，而后，某个司机向服务器发出接单请求， 之后，服务器将该约车订单分配给该发出接单请求的司机(接单司 机)，进而完成网约车订单的分配。后续过程中，需要接单司机从上 车地点接到乘客，并将乘客运送至目的地，即完成该次网约车订单。

但实际上，乘客乘坐网约车的过程中(乘客所下达的网约车订单 已经分配到指定的司机之后，在司机完成网约车订单之前)，可能因 为种种原因需要变更目的地，针对该种情况，相关技术中，乘客只能 取消已经下达的网约车订单，并重新发起新的网约车订单，而新的网 约车订单又需要重新按照前文中所说的步骤重新向全体司机进行广 播并进行分配，降低的乘客感受度。

针对上述情况，本申请提供了网约车订单分配方法，如图1所示， 该方法包括如下步骤：

S101，获取第一客户端发送的针对第一订单的订单修改信息； 所述第一客户端为服务请求方使用的客户端；

S102，根据所述订单修改信息，向第二客户端发送提示信息； 所述第二客户端为接受所述第一订单的第一服务提供方使用的客户 端；所述提示信息中携带有所述订单修改信息；

S103，根据所述第二客户端返回的针对所述提示信息的回复信 息，对针对所述第一订单的服务进行调整。

需要说明的是，本申请所提供的方法的执行主体一般是不受第一 客户端(服务请求方使用的客户端，即由乘客所使用的客户端)和第 二客户端(接受所述第一订单的第一服务提供方使用的客户端，通常 是接单司机所操作的客户端)所控制的服务器，当然，该执行主体也 可以是指任意一个能够接入网络的，具有计算能力的网络设备。

上述步骤S101-S103中，第一订单和订单修改信息均是由乘客所 操作的第一客户端发出的。订单修改信息与第一订单是相对应的，该 对应指的是订单修改信息是针对该第一订单生成的。比如，第一订单 是将乘客A从A地运载至B地(第一目的地信息所指向的地点)的 订单，则订单修改信息一般是表明将乘客A从A地运载至C地。当 然，除了目的地改变之外，订单修改信息还可以将其他要素进行修改 (比如运载路线、上车时间等)。准确来说，订单修改信息的作用是 修改第一订单。

步骤S101中，第一订单和订单修改信息均是由第一客户端发出 的，第一订单中通常携带有第一目的地信息；订单修改信息中通常携 带有目的地更新信息或者是第二目的地信息，第一目的地信息表明了 操作第一客户端的乘客原本期望去的地点，目的地更新信息或第二目 的地信息表明了操作第一客户端的乘客变更期望后，所要去的地点。 相对应的，除了变更目的地之外，还可以是变更出发地(乘客上车地 点)，也就是，订单修改信息中携带有目的地更新信息(用来标识新 的目的地)或出发地更新信息(用来标识新的上车地点)；当然，订 单修改信息中还可以同时携带有：目的地更新信息和出发地更新信 息。

步骤S102中，系统在向第二客户端发送提示消息后，由于提示 信息中携带有订单修改信息，进而第二客户端也能够知晓乘客期望进 行的修改，从而，第二客户端也能够依据该订单修改信息判断自己能 否承接修改后的订单。由于订单修改信息的作用是对第一订单进行变 更和调整，因此，一般情况下，第一订单是由第一客户端在发出订单 修改信息前发出的。

某种情况下，在接收到订单修改信息后，就可以认为第一订单失 效了，也就是第一服务提供方不再需要按照原始的第一订单来运载服 务请求方了。

订单修改信息不是任何时候都能起到修改第一订单的作用的，应 当是在第一订单处于生效期的时候，订单修改信息才能够起作用。也 就是只有系统(步骤S101-S103的执行主体)在第二客户端的操作者 (第一服务提供方，即接单司机)没有完成第一订单(没有将第一订 单所对应的乘客拉到第一订单所对应的位置)前或者是第一客户端的 操作者(服务请求方，即乘客)取消第一订单之前，接收到第一客户 端所发出的订单修改信息，才会向第二客户端发送提示消息。如果第 一订单已经失效，则不需要触发向第二客户端发送提示消息的步骤。 其中，如第一订单已经完成，即第二客户端已经将乘客运载到第一订 单所对应的目的地，则可以认为第一订单失效(第一订单不在生效 期)；还可以在第一客户端或第二客户端将第一订单取消后，也可以 认为第一订单已经失效。

在第二客户端接收提示消息后，第一服务提供方可以根据提示消 息中的订单修改信息来判断自己能否承接对应的订单修改信息，如果 第一服务提供方能够承接新订单(使用订单修改信息对第一订单进行 修改后所得到的订单)，则系统直接使用订单修改信息对第一订单进 行修改，以得到新订单，并将新订单向第二客户端分配即可。如果第 二客户端不能承接该新订单，则系统可以将新订单(使用订单修改信 息对第一订单进行修改后所得到的订单)向其他司机进行广播，以将 该新订单向其他司机进行派发。

也就是，步骤根据所述第二客户端返回的针对所述提示信息的回 复信息，对针对所述第一订单的服务进行调整，包括：

若所述回复信息指示所述第一服务提供方同意接受所述订单修 改信息，则根据所述订单修改信息，更新所述第一服务提供方接受的 第一订单的订单信息。

即，如果司机(第一服务提供方)针对提示信息进行的回复是同 意接收订单修改信息，则系统可以根据订单修改信息对第一订单进行 更新(如根据订单修改信息对第一订单进行修改)。在对第一订单进 行更新之后，司机就需要按照更新后的第一订单来运送乘客了。

进一步的，在确定司机同意接受订单修改信息后，系统就可以将 对应的导航信息向司机发送了。也就是，订单修改信息标识了乘客所 期望到达的新地点，系统需要根据司机的当前位置和新地点的位置， 生成新的导航信息(该新的导航信息是从司机的当前位置指向新地点 的)，并且将该新的导航信息向司机发送。

也就是，本申请所提供的方法中，在步骤更新所述第一服务提供 方接受的第一订单的订单信息之后，还包括：

根据所述订单修改信息，向所述第一服务提供方推送更新后的导 航信息。

司机按照更新后的导航信息可以直接将乘客运送到更新后的第 一订单所指向的目的地。这避免了司机在执行更新后的第一订单时， 还需要手动的确定当前位置与新目的地之间的导航线路，降低了发生 交通事故的可能性。

一般来说，导航信息至少反应了道路连通状况(不同地点之间通 过哪些道路连通)，还可以进一步反应了道路拥堵状况。或者说，导 航信息中的导航线路已经进行了躲避拥堵的设计。

为了更加直观的向第二客户端进行提示，导航信息可以包括通行 线路和通行时间。其中，通行线路表示了从第二客户端的当前位置到 新目的地之间的最快到达路线，通行时间表示了预估的第二客户端按 照通行线路运送乘客所需要的时间。

对应的，如果司机(第一服务提供方)针对提示信息进行的回复 是不同意接收订单修改信息，此时，系统就可以将根据修订单修改信 息所生成的新订单向其他的服务提供方进行广播，以使其他的服务提 供方能够完成该新订单。

也就是，本申请所提供的方法中，步骤根据所述第二客户端返回 的针对所述提示信息的回复信息，对针对所述第一订单的服务进行调 整，包括：

若所述回复信息指示所述第一服务提供方拒绝接受所述订单修 改信息，则将根据所述订单修改信息生成的第二订单派发给其他服务 提供方。

具体的，将根据所述订单修改信息生成的第二订单派发给其他服 务提供方可以按照如下方式实现：

将订单修改信息向候选服务提供方广播，以使候选服务提供方针 对订单修改信息反馈抢单消息；

根据抢单消息，将订单修改信息分配给候选服务提供方中指定的 一个服务提供方。

实现时，如果只有一个候选服务提供方反馈抢单消息，则可以直 接将第二订单分配给该反馈抢单消息的候选服务提供方；如果有多个 候选服务提供方同时反馈抢单消息，则可以按照既定的规则，将第二 订单分配给反馈抢单消息的多个候选服务提供方中的一个。比如，可 以将第二订单分配给反馈抢单消息最快的候选服务提供方。

系统在将根据订单修改信息生成的第二订单派发给其他服务提 供方时，如果某一个服务提供方同意接受该第二订单，则该司机需要 回复抢单信息，以使系统将该第二订单分配给该服务提供方。

此时，系统需要将该第一订单标识为已完成。更准确的是将第一 订单标识为：由于第一客户端对第一订单进行修改，导致第一订单被 完成，以使后续查询该第一订单状态的时候，能够确定出第一订单的 完成原因。

同时，为了让乘客准确的知晓其发出订单修改信息后情况，系统 应当在第一服务提供方拒绝接受订单修改信息后，将该情况向乘客进 行告知，也就是，本申请所提供的方法还包括：

若所述回复信息指示所述第一服务提供方拒绝接受所述订单修 改信息，所述方法还包括：

向所述第一客户端发送拒绝提示信息；拒绝提示信息用于表示所 述第一服务提供方拒绝接受修改后的订单信息，且当前处于等待新的 司机接单的状态。

该拒绝提示信息的作用是向乘客告知发出订单修改信息后的处 理结果，该处理结果是原本负责运载乘客的司机拒绝按照订单修改信 息所生成的新订单继续运载乘客，按照订单修改信息所生成的第二订 单需要有其他的司机来完成，但目前尚未找到新的司机来完成该第二 订单。

如前文中所说，只有在第一订单处于生效期的过程中，系统接收 到第一客户端所发出的针对第一订单的订单修改信息，才可能会触发 执行步骤S102，但考虑到违约成本，可以将系统接收到订单修改信 息的时段分为2个阶段，分别是：第一阶段，第一客户端已经将第一 订单发出，但第二客户端尚未接受第一订单的阶段(没有将第一订单 派发给指定司机的阶段)；第二阶段，第二客户端已经接受第一订单， 但尚未完成第一订单(司机尚未将乘客运载至目的地)的阶段。

对于上述第一个阶段，由于此时尚未确定第二客户端是谁，因此， 系统无法直接发送提示信息，只有在确定由哪个第二客户端接单后， 才能够将提示信息发送给对应的第二客户端，考虑到实际情况，本申 请所提供的方法中，步骤S102包括：

判断所述第一订单是否已被接单，在确定所述第一订单已被接单 后，向接收第一订单的所述第二客户端发送所述提示信息。

也就是，如果系统在接收到订单修改信息的时候，第一订单已经 某个司机被接单，才会向接受第一订单的司机所操作的第二客户端发 送提示信息，以告知操作第二客户端的司机乘客将第一订单进行了修 改。

对应的，如果系统在接收到订单修改信息的时候，第一订单尚未 被任何一个司机所接受，则可以不再广播原始的第一订单，而是使用 订单修改信息对第一订单进行更新，并将更新后的第一订单向司机进 行广播。可以预想到的，如果将第一订单分配给指定的一个司机后， 马上向该司机发送订单修改信息，则司机感受度必然受到影响，伴随 而来的是司机很大概率不会接受该修改后的第一订单。

进而，本申请所提供的方法还包括如下步骤：

若所述第一订单未被接单，则根据所述订单修改信息，更新所述 第一订单的订单信息，并重新派发更新订单信息后的第一订单。按照 此种方式，司机所接收到的订单已经是更新后的第一订单的，不会影 响司机的感受度，并且，一定程度上提高了司机正确辨识自己能否接 受该订单的概率。

一般情况下，在上述第一阶段中，乘客可以无顾虑的发出的订单 修改信息，因为，司机尚未接单，司机就没有产生运行成本(司机没 有向第一订单中约定的上车地点移动)。但，在第二阶段中，乘客发 出订单修改信息是所考虑的因素是有所一定顾虑的。从最基本的角度 来看，如果乘客尚未上车，那么车辆就的行驶成本就比较低(司机虽 然向约定的上车地点运动，但没有消耗燃油来运载乘客)，此时乘客 发出订单修改信息不会支付很多的违约费用；当乘客已经上车，并且 运载乘客行驶了一段时间之后，车辆的行驶成本就会变得较高，乘客 再发出订单修改信息就需要支付更多的违约费用。

也就是，在乘客已经上车之后，如果乘客操作第一客户端发出的 订单修改信息的话，则应当为司机提供一定的补偿金额。

具体实现时，可以根据司机的反馈来判断乘客是否已经上车。即， 司机在接到乘客后一般会向系统发送已接到乘客的告知消息，该告知 消息表示操作第二客户端的司机已经接到操作第一客户端的乘客。

进而，本申请所提供的方法中，步骤S101可以按照如下方式执 行：

在接收到所述第二客户端发送的确认乘客上车指示后，获取所述 第一客户端发送的针对第一订单的订单修改信息。

确认乘客上车指示是由司机操作第二客户端所发出的，用以表示 司机已经接到乘客，或者是乘客已经上车。

对应的，此时，如果接收到订单修改信息后，第一客户端发出针 对第一订单的订单修改信息，则应当给予司机一定的补偿，补偿的数 量应当视司机所支出的成本来确定。

也就是，本申请所提供的方法还包括：

若在接收到所述第二客户端发送的确认乘客上车指示后，获取到 所述第一客户端发送的针对第一订单的订单修改信息，则所述方法还 包括：

确定在接收到所述第一客户端发送的订单修改信息时，所述第二 客户端自发送所述确认乘客上车指示开始已经行驶的路程；

根据所述已经行驶的路程，为接受所述第一订单的司机确定补偿 金额。

也就是，首先需要确定司机为了运载乘客所行驶的路程。一般情 况下，只有第二客户端发出确定乘客上车指示后，才认为乘客已经上 车，之后，司机行驶的路程都是为运载乘客而付出的成本。进而，可 以根据该成本来计算司机的补偿，一般情况下，司机行驶的路程越长， 则补偿金额越大。比如，可以为司机每公里补偿3-4元。

更具体的，由于操作第二客户端的司机可以接受根据订单修改信 息所更新的第一订单，也可以不接受该更新的第一订单，因此，为了 使补偿金额确定的更加准确，确定补偿金额的过程可以分为两种情况 来确定。也就是，本申请所提供的方法中，步骤根据所述已经行驶的 路程，为接受所述第一订单的司机确定补偿金额，包括：

若所述回复信息指示所述第一服务提供方同意接受所述订单修 改信息，则根据所述已经行驶的路程、所述第一订单对应的修改前的 订单信息和所述订单修改信息，确定所述第一服务提供方行驶的额外 路程；根据确定的额外路程，确定所述补偿金额；

若所述回复信息指示所述第一服务提供方拒绝接受所述订单修 改信息，则为所述第一服务提供方确定与已经行驶的路程对应的补偿 金额。

其中，已经行驶的路程指的是司机在接乘到乘客后所行驶的路 程。第一订单对应的修改前的订单信息指的是第一客户端首次发出的 第一订单中所包含的订单信息，该订单信息中通常包括出发地信息 (原始出发地)和目的地信息(原始目的地)。

具体的，额外路程指的是第一路程和第二路程的差值；其中，第 一路程是从原始出发地到达当前位置的路程与从当前位置到新目的 地(订单修改信息中所携带的新的目的地)的路程之和；第二路程是 从原始出发地直接到达新目的地的路程。

如果司机(第一服务提供方)同意接受修改订单信息，就可以根 据上述额外路程计算对应的补偿金额，一般情况下，额外路程越长， 则补偿金额越大。

对应的，如果司机不同意接受修改订单信息，则只计算司机已经 行驶的路程即可。

更具体的，为了准确的确定已经行驶的路程，可以根据司机和乘 客的位置来判断，也就是，只有司机和乘客共同行驶过的路程才可以 作为已经行驶的路程。比如，第一客户端和第二客户端在10点20 分均出现在了地点A；在10点21分均出现在了地点B；在10点22分均出现在了地点C，则说明路线A-B-C是第一客户端和第二客户 端共同行驶过的路程。进而，路线A-B-C所对应的路程就是已经行 驶的路程。也就是，本申请所提供的方法中，已经行驶的路程是按照 如下方式得到的：

获取第一客户端的移动路线和第二客户端的移动路线；

根据第一客户端的移动路线和第二客户端的移动路线的重叠部 分，确定共同行驶的路线；

根据共同行驶的路线计算已经行驶的路程。

其中，移动路线通常是由至少两个按照时间先后顺序的坐标点组 成的，比如，第一客户端的移动路线为：在五点十分-五点十五分的 时间段中，顺序经过了A地-B地-C地，第二客户端的移动路线也为： 在五点十分-五点十五分的时间段中，顺序经过了A地-B地-C地，则 说明第一客户端和第二客户端的移动路线是完全重叠的，进而，可以 根据A地-B地-C地的长度来计算已经行驶的路程。

又如，如图2所示，示出了第一客户端的移动路线和第二客户端 的移动路线的示意图。应对与该图，第一客户端在12:25-12:30之间， 顺序经过了ACDEFG几个地点，第二客户端在12:25-12:30之间，顺 序经过了BCDEFH几个地点，则可以确定由CDEF所形成的路线是 共同行驶的路线，而AC所形成的路线、BC所形成的路线、FG所形 成的路线和FH所形成的路线则不是共同行驶的路线。

承接前文中的说明，如果系统将第二订单派发给其他服务提供 方，则同样需要将导航线路发送给都接收第二订单的第二服务提供方 但，除了发送导航线路以外，还应当提供对应的交接策略，进而，如 图3所示，步骤将根据所述订单修改信息生成的第二订单派发给其他 服务提供方后，还包括：

S201，获取第三客户端的当前位置、第二客户端的当前位置和 路况信息；第三客户端为接受所述第二订单的第二服务提供方使用的 客户端；

S202，根据第三客户端的当前位置、第二客户端的当前位置和 路况信息确定交接策略；交接策略包括行驶线路，和/或交接地点；

S203，将交接策略分别向第二客户端和第三客户端发送。

步骤S201中，路况信息反应了道路连通状况和拥堵状况，道路 连通状况表示道路是连接哪两个地点的，拥堵状况表示某条道路的拥 堵程度。进而，步骤S202中，根据路况信息，系统可以确定出来适 合的地点作为交接乘客的地点，或者是确定出交接路线(第一服务提 供方的行驶线路和/或第二服务提供方的行驶线路)，该交接路线有两 个，这两个交接路线反应了两个服务提供方各自应当前进的路线，这 两个交接路线的终点一般是指向了同一个地点(即乘客的下车地点和 乘客的上车地点可以是同一个地点)，而后，步骤S203中，系统可以 将交接地点和/或交接路线分别向两个司机所操作的客户端发送，以 使这两个司机分别按照交接策略进行移动，并最终完成乘客的交接。

具体使用时，可以是第一服务提供方将乘客直接运送到第二服务 提供方所在的位置(第二服务提供方不需要移动，即第二服务提供方 行驶路线可以是0，乘客上车地点和乘客下车地点均可以是第二服务 提供方当前所在的位置)。

一般情况下，交接地点中乘客上车地点和乘客下车地点是同一个 地点。也就是，乘客从第一服务提供方所驾驶的车辆上下车后，就可 以直接上到第一服务提供方所驾驶的车辆上。但某些情况下，两个司 机相距较近，如果驾车前往相同地点进行乘客交接的话，则两个司机 都需要行驶很远的一段路。比如第一个司机驾驶车辆在主路上由西向 东行驶，第二个司机驾驶车辆在主路上由东向西行驶，则第一个车辆 如果向行驶到第二个车辆所在的位置上的话，就需要先行驶到辅路， 再调头到由东向西行驶的道路上才行，如果调头地点很远，则第一个 车辆的司机要行驶很长一段时间才能够将第一客户端交接给第二个 车辆的司机，这消耗了过多的资源。

针对这种情况，本申请的发明人认为，可以采用车辆行驶路线与 乘客行走路线相结合的方式来解决该问题。此时，乘客下车地点和乘 客上车地点也就是不同的地点了，具体而言，步骤S202包括如下步 骤：

根据第一服务提供方的当前位置、第二服务提供方的当前位置和 路况信息确定第一交接策略、第二交接策略和第三交接策略；第一交 接策略包括第一服务提供方行驶线路，和/或乘客下车地点；第二交 接策略包括第二服务提供方行驶线路，和/或乘客上车地点；第三交 接策略包括服务请求方行走目的地，和/或服务请求方行走路线；

本申请所提供的方法还包括：

将第三交接策略向第一客户端发送。

其中，第一交接策略和第二交接策略的理解方式与步骤 S201-S202中的理解方式基本相同，即第一服务提供方行驶线路反应 了第一服务提供方应当驾车行驶的路线，第二服务提供方行驶线路反 应了第二服务提供方应当驾车行驶的路线，服务请求方行走线路反应 了服务请求方应当徒步行走的路线。实际使用的时候，这三个线路可 以只使用其中的任意一个，也可以使用其中的至少两个，或者全部都 使用。

该方案中，通过乘客的少量行走来替代司机长时间的行驶，从时 间最优的角度来看是合理的，但不同的乘客会有不同的考量(比如有 些乘客不愿意走路，而愿意承担司机交接乘客所行驶路程的费用)， 因此，本申请所提供的方案中，还可以在步骤S202中同时确定多个 候选策略，并根据乘客的选择来确定候选策略中的一个作为交接策 略。

也就是，如图4所示，步骤S202包括如下步骤：

S2021，根据第一服务提供方的当前位置、第二服务提供方的当 前位置和路况信息确定多个候选策略，候选策略包括交接路线，和/ 或交接地点；

S2022，将多个候选策略向第一客户端发送，以使第一客户端反 馈与候选策略相对应的选择指令；

S2023，根据与选择指令相对应的候选策略确定交接策略。

通过这三个步骤，使得交接策略在确定的时候，是经过客户确认 的，该交接线路更符合乘客的实际需求。

整体来看本申请所提供的订单分配方法，在用户操作第一客户端 发出第一订单后，又追加了针对第一订单的订单修改信息时，系统首 先将该订单修改信息发送给了接受该第一订单的第二客户端，并根据 第二客户端的回复，确定后续的处理方式，由于第二客户端的操作人 员正在为操作第一客户端的用户提供服务，因此，第二客户端的操作 人员接受该订单修改信息的概率较大，也就是可以为用户很快捷的找 到服务提供者(第二客户端的操作者)，此种方式提高了处理订单修 改信息的效率。

与上述方法相对应的，如图5所示，本申请还提供了一种网约车 订单分配装置，包括：

第一获取模块501，用于获取第一客户端发送的针对第一订单的 订单修改信息；所述第一客户端为服务请求方使用的客户端；

第一发送模块502，用于根据所述订单修改信息，向第二客户端 发送提示信息；所述第二客户端为接受所述第一订单的第一服务提供 方使用的客户端；所述提示信息中携带有所述订单修改信息；

调整模块503，用于根据所述第二客户端返回的针对所述提示信 息的回复信息，对针对所述第一订单的服务进行调整。

优选的，调整模块503包括：

第一更新单元，若所述回复信息指示所述第一服务提供方同意接 受所述订单修改信息，则用于根据所述订单修改信息，更新所述第一 服务提供方接受的第一订单的订单信息。

优选的，该装置还包括：

推送单元，用于根据所述订单修改信息，向所述第一服务提供方 推送更新后的导航信息。

优选的，调整模块503包括：

派发单元，若所述回复信息指示所述第一服务提供方拒绝接受所 述订单修改信息，则用于将根据所述订单修改信息生成的第二订单派 发给其他服务提供方。

优选的，该装置还包括：

第一发送单元，用于向所述第一客户端发送拒绝提示信息；拒绝 提示信息用于表示所述第一服务提供方拒绝接受修改后的订单信息， 且当前处于等待新的司机接单的状态。

优选的，所述订单修改信息中携带有：目的地更新信息和出发地 更新信息中的至少一种。

优选的，所述第一发送模块502包括：

第二发送单元，用于判断所述第一订单是否已被接单，在确定所 述第一订单已被接单后，向接收第一订单的所述第二客户端发送所述 提示信息。

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

重新派发单元，若所述第一订单未被接单，则用于根据所述订单 修改信息，更新所述第一订单的订单信息，并重新派发更新订单信息 后的第一订单。

优选的，所述第一获取模块501包括：

获取单元，用于在接收到所述第二客户端发送的确认乘客上车指 示后，获取所述第一客户端发送的针对第一订单的订单修改信息。

优选的，该装置还包括：

第一确定单元，用于确定在接收到所述第一客户端发送的订单修 改信息时，所述第二客户端自发送所述确认乘客上车指示开始已经行 驶的路程；

第二确定单元，用于根据所述已经行驶的路程，为接受所述第一 订单的司机确定补偿金额。

优选的，第二确定单元包括：

第一确定子单元，若所述回复信息指示所述第一服务提供方同意 接受所述订单修改信息，则用于根据所述已经行驶的路程、所述第一 订单对应的修改前的订单信息和所述订单修改信息，确定所述第一服 务提供方行驶的额外路程；根据确定的额外路程，确定所述补偿金额；

第二确定子单元，若所述回复信息指示所述第一服务提供方拒绝 接受所述订单修改信息，则用于为所述第一服务提供方确定与已经行 驶的路程对应的补偿金额。

优选的，该装置还包括：

第二获取模块，用于获取第一客户端的移动路线和第二客户端的 移动路线；

第一确定模块，用于根据第一客户端的移动路线和第二客户端的 移动路线的重叠部分，确定共同行驶的路线；

计算模块，用于根据共同行驶的路线计算已经行驶的路程。

优选的，该装置还包括：

第三获取模块，用于获取第三客户端的当前位置、第二客户端的 当前位置和路况信息；第三客户端为接受所述第二订单的第二服务提 供方使用的客户端；

第二确定模块，用于根据第三客户端的当前位置、第二客户端的 当前位置和路况信息确定交接策略；

第二发送模块，用于将所述交接策略分别向第二客户端和第三客 户端发送。

与上述方法相对应的，本申请还提供了一种具有处理器可执行的 非易失的程序代码的计算机可读介质，程序代码使所述处理器执行前 文中所提供的网约车订单分配方法。

如图6所示，为本申请实施例所提供的计算设备示意图，该计算 设备60包括：处理器61、存储器62和总线63，存储器62存储有执 行指令，当计算设备运行时，处理器61与存储器62之间通过总线 63通信，处理器61执行存储器62中存储的如订单分配方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁， 上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中 的对应过程，在此不再赘述。

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

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不 局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范 围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。 因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (28)

1.一种订单分配方法，其特征在于，包括：

获取第一客户端发送的针对第一订单的订单修改信息；所述第一客户端为服务请求方使用的客户端；

根据所述订单修改信息，向第二客户端发送提示信息；所述第二客户端为接受所述第一订单的第一服务提供方使用的客户端；所述提示信息中携带有所述订单修改信息；

根据所述第二客户端返回的针对所述提示信息的回复信息，对针对所述第一订单的服务进行调整。

2.根据权利要求1所述的方法，其特征在于，根据所述第二客户端返回的针对所述提示信息的回复信息，对针对所述第一订单的服务进行调整，包括：

若所述回复信息指示所述第一服务提供方同意接受所述订单修改信息，则根据所述订单修改信息，更新所述第一服务提供方接受的第一订单的订单信息。

3.根据权利要求2所述的方法，其特征在于，更新所述第一服务提供方接受的第一订单的订单信息之后，还包括：

根据所述订单修改信息，向所述第一服务提供方推送更新后的导航信息。

4.根据权利要求1所述的方法，其特征在于，根据所述第二客户端返回的针对所述提示信息的回复信息，对针对所述第一订单的服务进行调整，包括：

若所述回复信息指示所述第一服务提供方拒绝接受所述订单修改信息，则将根据所述订单修改信息生成的第二订单派发给其他服务提供方。

5.根据权利要求4所述的方法，其特征在于，若所述回复信息指示所述第一服务提供方拒绝接受所述订单修改信息，所述方法还包括：

向所述第一客户端发送拒绝提示信息；拒绝提示信息用于表示所述第一服务提供方拒绝接受修改后的订单信息，且当前处于等待新的司机接单的状态。

6.根据权利要求1所述的方法，其特征在于，所述订单修改信息中携带有：目的地更新信息和出发地更新信息中的至少一种。

7.根据权利要求1所述的方法，其特征在于，所述根据所述订单修改信息，向第二客户端发送提示信息，包括：

判断所述第一订单是否已被接单，在确定所述第一订单已被接单后，向接收第一订单的所述第二客户端发送所述提示信息。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

若所述第一订单未被接单，则根据所述订单修改信息，更新所述第一订单的订单信息，并重新派发更新订单信息后的第一订单。

9.根据权利要求1所述的方法，其特征在于，所述获取第一客户端发送的针对第一订单的订单修改信息，包括：

在接收到所述第二客户端发送的确认乘客上车指示后，获取所述第一客户端发送的针对第一订单的订单修改信息。

10.根据权利要求9所述的方法，其特征在于，若在接收到所述第二客户端发送的确认乘客上车指示后，获取到所述第一客户端发送的针对第一订单的订单修改信息，则所述方法还包括：

确定在接收到所述第一客户端发送的订单修改信息时，所述第二客户端自发送所述确认乘客上车指示开始已经行驶的路程；

根据所述已经行驶的路程，为接受所述第一订单的司机确定补偿金额。

11.根据权利要求10所述的方法，其特征在于，根据所述已经行驶的路程，为接受所述第一订单的司机确定补偿金额，包括：

若所述回复信息指示所述第一服务提供方同意接受所述订单修改信息，则根据所述已经行驶的路程、所述第一订单对应的修改前的订单信息和所述订单修改信息，确定所述第一服务提供方行驶的额外路程；根据确定的额外路程，确定所述补偿金额；

若所述回复信息指示所述第一服务提供方拒绝接受所述订单修改信息，则为所述第一服务提供方确定与已经行驶的路程对应的补偿金额。

12.根据权利要求10所述的方法，其特征在于，所述已经行驶的路程是按照如下方式得到的：

获取第一客户端的移动路线和第二客户端的移动路线；

根据第一客户端的移动路线和第二客户端的移动路线的重叠部分，确定共同行驶的路线；

根据共同行驶的路线计算已经行驶的路程。

13.根据权利要求4所述的方法，其特征在于，在步骤将根据所述订单修改信息生成的第二订单派发给其他服务提供方后还包括：

获取第三客户端的当前位置、第二客户端的当前位置和路况信息；第三客户端为接受所述第二订单的第二服务提供方使用的客户端；

根据第三客户端的当前位置、第二客户端的当前位置和路况信息确定交接策略；

将所述交接策略分别向第二客户端和第三客户端发送。

14.一种订单分配装置，其特征在于，包括：

第一获取模块，用于获取第一客户端发送的针对第一订单的订单修改信息；所述第一客户端为服务请求方使用的客户端；

第一发送模块，用于根据所述订单修改信息，向第二客户端发送提示信息；所述第二客户端为接受所述第一订单的第一服务提供方使用的客户端；所述提示信息中携带有所述订单修改信息；

调整模块，用于根据所述第二客户端返回的针对所述提示信息的回复信息，对针对所述第一订单的服务进行调整。

15.根据权利要求14所述的装置，其特征在于，调整模块包括：

第一更新单元，若所述回复信息指示所述第一服务提供方同意接受所述订单修改信息，则用于根据所述订单修改信息，更新所述第一服务提供方接受的第一订单的订单信息。

16.根据权利要求15所述的装置，其特征在于，还包括：

推送单元，用于根据所述订单修改信息，向所述第一服务提供方推送更新后的导航信息。

17.根据权利要求14所述的装置，其特征在于，调整模块包括：

派发单元，若所述回复信息指示所述第一服务提供方拒绝接受所述订单修改信息，则用于将根据所述订单修改信息生成的第二订单派发给其他服务提供方。

18.根据权利要求17所述的装置，其特征在于，还包括：

第一发送单元，用于向所述第一客户端发送拒绝提示信息；拒绝提示信息用于表示所述第一服务提供方拒绝接受修改后的订单信息，且当前处于等待新的司机接单的状态。

19.根据权利要求14所述的装置，其特征在于，所述订单修改信息中携带有：目的地更新信息和出发地更新信息中的至少一种。

20.根据权利要求14所述的装置，其特征在于，所述第一发送模块包括：

第二发送单元，用于判断所述第一订单是否已被接单，在确定所述第一订单已被接单后，向接收第一订单的所述第二客户端发送所述提示信息。

21.根据权利要求20所述的装置，其特征在于，所述装置还包括：

重新派发单元，若所述第一订单未被接单，则用于根据所述订单修改信息，更新所述第一订单的订单信息，并重新派发更新订单信息后的第一订单。

22.根据权利要求14所述的装置，其特征在于，所述第一获取模块包括：

获取单元，用于在接收到所述第二客户端发送的确认乘客上车指示后，获取所述第一客户端发送的针对第一订单的订单修改信息。

23.根据权利要求22所述的装置，其特征在于，还包括：

第一确定单元，用于确定在接收到所述第一客户端发送的订单修改信息时，所述第二客户端自发送所述确认乘客上车指示开始已经行驶的路程；

第二确定单元，用于根据所述已经行驶的路程，为接受所述第一订单的司机确定补偿金额。

24.根据权利要求23所述的装置，其特征在于，第二确定单元包括：

第一确定子单元，若所述回复信息指示所述第一服务提供方同意接受所述订单修改信息，则用于根据所述已经行驶的路程、所述第一订单对应的修改前的订单信息和所述订单修改信息，确定所述第一服务提供方行驶的额外路程；根据确定的额外路程，确定所述补偿金额；

第二确定子单元，若所述回复信息指示所述第一服务提供方拒绝接受所述订单修改信息，则用于为所述第一服务提供方确定与已经行驶的路程对应的补偿金额。

25.根据权利要求23所述的装置，其特征在于，还包括：

第二获取模块，用于获取第一客户端的移动路线和第二客户端的移动路线；

第一确定模块，用于根据第一客户端的移动路线和第二客户端的移动路线的重叠部分，确定共同行驶的路线；

计算模块，用于根据共同行驶的路线计算已经行驶的路程。

26.根据权利要求17所述的装置，其特征在于，还包括：

第三获取模块，用于获取第三客户端的当前位置、第二客户端的当前位置和路况信息；第三客户端为接受所述第二订单的第二服务提供方使用的客户端；

第二确定模块，用于根据第三客户端的当前位置、第二客户端的当前位置和路况信息确定交接策略；

第二发送模块，用于将所述交接策略分别向第二客户端和第三客户端发送。

27.一种具有处理器可执行的非易失的程序代码的计算机可读介质，其特征在于，所述程序代码使所述处理器执行所述权利要求1-13任一所述方法。

28.一种服务器包括：处理器、存储器和总线，存储器存储有执行指令，当计算设备运行时，处理器与存储器之间通过总线通信，处理器执行存储器中存储的如权利要求1-13任一所述方法。

Images