CN111861081B - 一种订单分配方法、装置、电子设备及存储介质 - Google Patents

一种订单分配方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN111861081B
CN111861081B CN201911337216.6A CN201911337216A CN111861081B CN 111861081 B CN111861081 B CN 111861081B CN 201911337216 A CN201911337216 A CN 201911337216A CN 111861081 B CN111861081 B CN 111861081B
Authority
CN
China
Prior art keywords
service request
order
candidate
information
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201911337216.6A
Other languages
English (en)
Other versions
CN111861081A (zh
Inventor
黄玉坤
牟宝宁
郄小虎
万昊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Didi Infinity Technology and Development Co Ltd
Original Assignee
Beijing Didi Infinity Technology and Development Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Didi Infinity Technology and Development Co Ltd filed Critical Beijing Didi Infinity Technology and Development Co Ltd
Priority to CN201911337216.6A priority Critical patent/CN111861081B/zh
Publication of CN111861081A publication Critical patent/CN111861081A/zh
Application granted granted Critical
Publication of CN111861081B publication Critical patent/CN111861081B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311—Scheduling, planning or task assignment for a person or group
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06315—Needs-based resource requirements planning or analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • Marketing (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Health & Medical Sciences (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Traffic Control Systems (AREA)

Abstract

本申请提供了一种订单分配方法、装置、电子设备及存储介质，其中，该方法包括：响应服务请求端发起的服务请求，为所述服务请求端确定候选服务提供端，并生成与所述候选服务提供端对应的接驾等待信息；将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端；基于所述服务请求端针对所述接驾等待信息的反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端。采用上述订单分配方案，能够通过乘客对接驾等待信息的反馈进行订单分配，有效减少订单被接单后又取消的情况，提升了网约车服务平台的服务质量，也节省了司乘资源。

Description

一种订单分配方法、装置、电子设备及存储介质
技术领域
本申请涉及计算机处理技术领域，具体而言，涉及一种订单分配方法、装置、电子设备及存储介质。
背景技术
近些年，由于网约车的便捷性和实用性，网约车规模迅速扩张。乘客可以通过网约车服务平台发起出行订单，以便司机接单后到达指定地点接送乘客到目的地，从而方便乘客出行。
在目前的网络车服务过程中，在将乘客的订单分配给司机后，由于诸如接驾时间较长、接驾距离较远等原因会出现乘客取消订单的情况，这严重浪费了乘客等待时长和司机空驶距离，降低了网约车服务平台的服务质量。
发明内容
有鉴于此，本申请的目的在于提供至少一种订单分配方案，能够通过乘客对接驾等待信息的反馈进行订单分配，有效减少订单被接单后又取消的情况，提升了网约车服务平台的服务质量，也节省了司乘资源。
主要包括以下几个方面：
第一方面，本申请提供了一种订单分配方法，所述方法包括：
响应服务请求端发起的服务请求，为所述服务请求端确定候选服务提供端，并生成与所述候选服务提供端对应的接驾等待信息；
将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端；
基于所述服务请求端针对所述接驾等待信息的反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在一种实施方式中，将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端之前，还包括：
确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率；
所述将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端，包括：
若所述订单取消概率满足预设条件，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
在一种实施方式中，所述方法还包括：
若所述订单取消概率不满足预设条件，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在一种实施方式中，所述确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率，包括：
获取所述服务请求端的当前出行特征数据和历史出行订单信息；
基于所述服务请求端的当前出行特征数据和历史出行订单信息、以及预先训练好的订单取消模型，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
在一种实施方式中，可以根据以下一种或多种方式，确定所述服务请求端的当前出行特征数据：
将所述服务请求端对应的当前出行订单信息，确定为所述服务请求端的一种当前出行特征数据；
将距离所述服务请求端的预设范围内的当前供需数据，确定为所述服务请求端的一种当前出行特征数据；
将与所述服务请求端匹配的候选服务提供端由该候选服务提供端当前所处的位置行驶至所述服务请求端当前所处的位置的行驶数据，确定为所述服务请求端的一种当前出行特征数据。
在一种实施方式中，所述基于所述服务请求端的当前出行特征数据和历史出行订单信息、以及预先训练好的订单取消模型，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率，包括：
对所述服务请求端的历史出行订单信息进行统计分析，确定历史订单取消数据；
将所述服务请求端的当前出行特征数据以及所述历史订单取消数据输入至预先训练好的订单取消模型中，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
在一种实施方式中，按照如下步骤训练所述订单取消模型：
获取参考服务请求端的各个历史出行订单信息以及与每个历史出行订单信息对应的是否取消订单的确认信息；
将所述参考服务请求端的每个历史出行订单信息输入至待训练的订单取消模型中，得到模型输出的针对该历史出行订单信息的取消确认信息；将模型输出的所述取消确认信息与该历史出行订单信息对应的是否取消订单的确认信息进行对比，若对比不一致，则调整所述待训练的订单取消模型的训练参数，直至对比一致。
在一种实施方式中，若所述订单取消概率满足预设条件，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端，包括：
若所述订单取消概率大于预设概率阈值，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
在一种实施方式中，若所述订单取消概率满足预设条件，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端，包括：
获取距离所述服务请求端的预设范围内的可用车辆数量；
若所述可用车辆数量大于预设数量阈值、且所述订单取消概率大于预设概率阈值，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
在一种实施方式中，若所述订单取消概率不满足预设条件，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端，包括：
若所述订单取消概率小于或等于预设概率阈值，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在一种实施方式中，若所述订单取消概率不满足预设条件，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端，包括：
获取距离所述服务请求端的预设范围内的可用车辆数量；
若所述可用车辆数量小于或等于预设数量阈值、且所述订单取消概率大于预设概率阈值，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端，并向所述服务请求端推送提醒信息；所述提醒信息用于指示距离所述服务请求端的预设范围内不存在可分配的其它候选服务提供端。
在一种实施方式中，所述根据所述服务请求端针对所述接驾等待信息的反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端，包括：
若根据所述服务请求端针对所述接驾等待信息的反馈信息确定出所述服务请求端确定等待其它候选服务提供端，则将所述服务请求对应的当前出行订单分配至所述其它候选服务提供端；
若根据所述服务请求端针对所述接驾等待信息的反馈信息确定出所述服务请求端取消等待其它候选服务提供端，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
第二方面，本申请还提供了一种订单分配方法，所述方法包括：
发送服务请求至服务器；
接收所述服务器生成的与候选服务提供端对应的接驾等待信息；所述候选服务提供端为所述服务器基于所述服务请求确定的服务提供端；
发送针对所述接驾等待信息的反馈信息给所述服务器，以使所述服务器根据所述反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
第三方面，本申请还提供了一种订单分配装置，所述装置包括：
响应模块，用于响应服务请求端发起的服务请求，为所述服务请求端确定候选服务提供端，并生成与所述候选服务提供端对应的接驾等待信息；
发送模块，用于将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端；
第一分配模块，用于基于所述服务请求端针对所述接驾等待信息的反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在一种实施方式中，所述发送模块，用于按照如下步骤将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端：
将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端之前，确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率；
若所述订单取消概率满足预设条件，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
在一种实施方式中，所述装置还包括：
第二分配模块，用于若所述订单取消概率不满足预设条件，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在一种实施方式中，所述发送模块，用于按照步骤确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率：
获取所述服务请求端的当前出行特征数据和历史出行订单信息；
基于所述服务请求端的当前出行特征数据和历史出行订单信息、以及预先训练好的订单取消模型，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
在一种实施方式中，所述发送模块，用于根据以下一种或多种方式，确定所述服务请求端的当前出行特征数据：
将所述服务请求端对应的当前出行订单信息，确定为所述服务请求端的一种当前出行特征数据；
将距离所述服务请求端的预设范围内的当前供需数据，确定为所述服务请求端的一种当前出行特征数据；
将与所述服务请求端匹配的候选服务提供端由该候选服务提供端当前所处的位置行驶至所述服务请求端当前所处的位置的行驶数据，确定为所述服务请求端的一种当前出行特征数据。
在一种实施方式中，所述发送模块，用于按照步骤预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率：
对所述服务请求端的历史出行订单信息进行统计分析，确定历史订单取消数据；
将所述服务请求端的当前出行特征数据以及所述历史订单取消数据输入至预先训练好的订单取消模型中，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
在一种实施方式中，所述发送模块，用于按照如下步骤训练所述订单取消模型：
获取参考服务请求端的各个历史出行订单信息以及与每个历史出行订单信息对应的是否取消订单的确认信息；
将所述参考服务请求端的每个历史出行订单信息输入至待训练的订单取消模型中，得到模型输出的针对该历史出行订单信息的取消确认信息；将模型输出的所述取消确认信息与该历史出行订单信息对应的是否取消订单的确认信息进行对比，若对比不一致，则调整所述待训练的订单取消模型的训练参数，直至对比一致。
在一种实施方式中，所述发送模块，用于按照如下步骤将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端：
若所述订单取消概率大于预设概率阈值，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
在一种实施方式中，所述发送模块，用于按照如下步骤将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端：
获取距离所述服务请求端的预设范围内的可用车辆数量；
若所述可用车辆数量大于预设数量阈值、且所述订单取消概率大于预设概率阈值，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
在一种实施方式中，所述第二分配模块，用于按照如下步骤将所述服务请求对应的当前出行订单分配至所述候选服务提供端：
若所述订单取消概率小于或等于预设概率阈值，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在一种实施方式中，所述第二分配模块，用于按照如下步骤将所述服务请求对应的当前出行订单分配至所述候选服务提供端：
获取距离所述服务请求端的预设范围内的可用车辆数量；
若所述可用车辆数量小于或等于预设数量阈值、且所述订单取消概率大于预设概率阈值，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端，并向所述服务请求端推送提醒信息；所述提醒信息用于指示距离所述服务请求端的预设范围内不存在可分配的其它候选服务提供端。
在一种实施方式中，所述第一分配模块，用于按照如下步骤确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端：
若根据所述服务请求端针对所述接驾等待信息的反馈信息确定出所述服务请求端确定等待其它候选服务提供端，则将所述服务请求对应的当前出行订单分配至所述其它候选服务提供端；
若根据所述服务请求端针对所述接驾等待信息的反馈信息确定出所述服务请求端取消等待其它候选服务提供端，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
第四方面，本申请还提供了一种订单分配装置，所述装置包括：
第一发送模块，用于发送服务请求至服务器；
接收模块，用于接收所述服务器生成的与候选服务提供端对应的接驾等待信息；所述候选服务提供端为所述服务器基于所述服务请求确定的服务提供端；
第二发送模块，用于发送针对所述接驾等待信息的反馈信息给所述服务器，以使所述服务器根据所述反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
第五方面，本申请还提供了一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如第一方面及其各种实施方式任一所述订单分配方法的步骤。
第六方面，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如第一方面及其各种实施方式任一所述订单分配方法的步骤。
采用上述订单分配方案，服务器在响应服务请求端发起的服务请求之后，首先可以为该服务请求端确定候选服务提供端，并生成与所述候选服务提供端对应的接驾等待信息，然后将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端，并能够基于服务请求端针对所述接驾等待信息的反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
上述方案在将服务请求端(对应乘客)的当前出行订单分配至候选服务提供端(对应司机)之前，可以先反馈接驾等待信息给服务请求端，这样，服务请求端即可以根据该接驾等待信息反馈自己是否愿意接受服务器当前预分配的候选服务提供端，例如，乘客认为当前接驾等待时间过长，则可以拒绝接受当前预分配的司机。也即，综合乘客的等待意愿和预分配司机实现最终的订单分配，这有效的降低了后续订单分配后的取消率，节约了网约车服务平台调度的人力和物力成本，进一步提升了服务质量。
为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1示出了本申请实施例提供的一种服务系统的架构示意图；
图2示出了本申请实施例一提供的一种订单分配方法的流程图；
图3示出了本申请实施例一提供的订单分配方法中，预测订单取消概率的具体方法的流程图；
图4示出了本申请实施例一提供的订单分配方法中，训练订单取消模型的具体方法的流程图；
图5示出了本申请实施例二提供的一种订单分配方法的流程图；
图6示出了本申请实施例三提供的一种订单分配装置的结构示意图；
图7示出了本申请实施例三提供的另一种订单分配装置的结构示意图；
图8示出了本申请实施例四提供的一种电子设备的结构示意图；
图9示出了本申请实施例四提供的另一种电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。
另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。
为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“网约车出行服务中的订单分配”，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕网约车出行服务中的订单分配进行描述，但是应该理解，这仅是一个示例性实施例。除此之外，本申请还可以应用于其它服务中的订单分配，例如，订餐、物流配送等服务场景中，本申请实施例对比不做具体的限制。
需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。
本申请中的术语“乘客”、“请求方”、“服务请求方”和“客户”可互换使用，以指代可以请求或订购服务的个人、实体或工具。本申请中的术语“司机”、“提供方”、“服务提供方”和“供应商”可互换使用，以指代可以提供服务的个人、实体或工具。本申请中的术语“用户”可以指代请求服务、订购服务、提供服务或促成服务的提供的个人、实体或工具。例如，用户可以是乘客、驾驶员、操作员等，或其任意组合。在本申请中，“乘客”、“乘客终端”、“服务请求端”可以互换使用，“驾驶员”、“驾驶员终端”、“司机”、“司机终端”、“服务提供端”可以互换使用。
本申请中的术语“服务请求”和“订单”可互换使用，以指代由乘客、服务请求方发起的请求。接受该“服务请求”或“订单”的可以是司机、服务提供方。服务请求可以是收费的或免费的。
值得注意的是，在提出本申请之前，相关技术中在将乘客的订单分配给司机后，由于诸如接驾时间较长、接驾距离较远等原因会出现乘客取消订单的情况，这严重浪费了乘客等待时长和司机空驶距离，降低了网约车服务平台的服务质量。有鉴于此，本申请的一个方面涉及一种服务系统，该系统能够通过乘客对接驾等待信息的反馈进行订单分配，有效减少订单被接单后又取消的情况，提升了网约车服务平台的服务质量，也节省了司乘资源。
图1是本申请实施例提供的一种服务系统的架构示意图。例如，服务系统可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。服务系统可以包括服务器101、网络102、服务请求端103、服务提供端104、和数据库105中的一种或多种。
在一些实施例中，服务器101可以包括处理器。处理器可以处理与服务请求有关的信息和/或数据，以执行本申请中描述的一个或多个功能。例如，处理器可以基于从服务请求端103获得的服务请求来确定目标车辆。在一些实施例中，处理器可以包括一个或多个处理核(例如，单核处理器(S)或多核处理器(S))。仅作为举例，处理器可以包括中央处理单元(Central Processing Unit,CPU)、专用集成电路(Application Specific IntegratedCircuit,ASIC)、专用指令集处理器(Application Specific Instruction-setProcessor,ASIP)、图形处理单元(Graphics Processing Unit,GPU)、物理处理单元(Physics Processing Unit,PPU)、数字信号处理器(Digital Signal Processor,DSP)、现场可编程门阵列(Field Programmable Gate Array,FPGA)、可编程逻辑器件(Programmable Logic Device,PLD)、控制器、微控制器单元、简化指令集计算机(ReducedInstruction Set Computing,RISC)、或微处理器等，或其任意组合。
在一些实施例中，服务请求端103和服务提供端104对应的设备类型可以是移动设备，比如可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等，也可以是平板计算机、膝上型计算机、或机动车辆中的内置设备等。
在一些实施例中，数据库105可以连接到网络102以与服务系统中的一个或多个组件(例如，服务器101，服务请求端103，服务提供端104等)通信。服务系统中的一个或多个组件可以经由网络102访问存储在数据库105中的数据或指令。在一些实施例中，数据库105可以直接连接到服务系统中的一个或多个组件，或者，数据库105也可以是服务器101的一部分。
下面结合上述图1示出的服务系统中描述的内容，通过如下几个实施例对本申请提供的至少一种订单分配方案进行详细说明。
实施例一
参照图2所示，为本申请实施例一提供的一种订单分配方法的流程示意图，该方法可以由服务系统中的服务器来执行，具体执行过程为：
S201、响应服务请求端发起的服务请求，为所述服务请求端确定候选服务提供端，并生成与所述候选服务提供端对应的接驾等待信息。
这里，为了便于理解本申请提供的订单分配方法，首先对网约车出行服务对应的应用场景进行简单说明。目前，在乘客需要利用网约车服务平台出行时，一旦启动发单按钮发出服务请求，网约车平台的后台服务器便能够基于乘客的打车信息生成对应的出行订单，将出行订单派送给司机以方便司机为乘客提供网约车出行服务。
本申请实施例中，在将出行订单派送给司机之前，针对乘客发出的服务请求中携带的打车信息为该乘客确定候选司机，也即，可以为服务请求端确定候选服务提供端。该候选服务提供端可以是当前网约车出行服务场景中距离服务请求端最近的服务提供端，还可以是基于距离因素以及其它因素(如天气信息、交通信息等)从服务提供端周边选择出的服务提供端，本申请实施例对此不做具体的限制。
在确定候选服务提供端时，还可以生成与该候选服务提供端对应的接驾等待信息，该接驾等待信息可以指示候选服务提供端提供出行服务时，服务请求端等待服务的相关信息，该相关信息可以是候选服务提供端由当前所处位置到达服务请求端的发单位置(可以是服务请求端的当前所处位置)所需的时间、距离等信息。随着接驾等待距离越远、接驾等待时间越长，一定程度上意味着乘客对当前预分配司机的满意度越低。
值得说明的是，有关候选服务提供端和服务请求端的位置信息可以是基于定位技术确定的，本申请中使用的定位技术可以基于全球定位系统(Global PositioningSystem,GPS)、全球导航卫星系统(Global Navigation Satellite System,GLONASS)，罗盘导航系统(COMPASS)、伽利略定位系统、准天顶卫星系统(Quasi-Zenith SatelliteSystem,QZSS)、无线保真(Wireless Fidelity,WiFi)定位技术等，或其任意组合。一个或多个上述定位系统可以在本申请中互换使用。
S202、将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
这里，本申请实施例在生成接驾等待信息之后，可以直接将接驾等待信息发送给所述服务请求端，也可以在确定在将服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率之后，再确定将接驾等待信息发送给服务请求端。
为了减少信息推送所可能对乘客带来的不佳体验，本申请实施例可以基于订单取消概率与预设条件的对比结果，将接驾等待信息发送给服务请求端。
S203、基于所述服务请求端针对所述接驾等待信息的反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
这里，在服务请求端接收到服务器发送的接驾等待信息之后，可以针对该接驾等待信息进行反馈，服务器利用反馈信息即可以初步判断服务请求端对当前预分配的候选服务提供端的接受情况。为了在确保乘客体验的前提下，降低乘客取消订单的情况，可以在根据反馈信息确定用户的等待意愿之后，为用户确定相应的分配方案。
例如，在确定用户对当前预分配的候选服务提供端的等待意愿较低时，可以重新为用户查找其它候选服务提供端，例如，随着时间的推进，距离服务请求端更近的服务提供端。再如，在确定用户对当前预分配的候选服务提供端的等待意愿较高时，可以直接将预分配的候选服务提供端作为最终的服务提供端以进行订单分配，确保了订单分配的效率。
本申请实施例中，确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率之后，可以根据订单取消概率与预设条件的对比结果来实现订单分配。接下来通过如下两个方面进行具体说明。
第一方面：若确定出订单取消概率满足预设条件，如订单取消概率高于预设概率阈值(如0.85)，可以将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。也即，本申请实施例可以在确定一个服务请求端针对当前预分配的候选服务提供端的订单取消概率较大时，向该服务请求端推送接驾等待信息以确定其反馈的等待意愿，再进行订单分配。
在进行订单分配的过程中，如果根据服务请求端的反馈信息确定乘客等待意愿较高(即，确定等待其它候选服务提供端)，这时可以持续寻找更适合的车辆，如果根据服务请求端的反馈信息确定乘客拒绝等待(即，取消等待其它候选服务提供端)时，可以将当前出行订单分配给预分配的服务提供端。
第二方面：若确定出订单取消概率不满足预设条件，如订单取消概率小于或等于预设概率阈值，可以直接将所述服务请求对应的当前出行订单分配至所述候选服务提供端。也即，本申请实施例可以在确定一个服务请求端针对当前预分配的候选服务提供端的订单取消概率较小时，直接将预分配的候选服务提供端匹配给服务请求端。
考虑到本申请实施例提供的网约车服务应用场景的复杂性，本申请实施例除了可以直接基于订单取消概率来确定分配方案，还可以结合订单取消概率和可用车辆数量来确定分配方案。其中，可用车辆数量可以指的是距离所述服务请求端的预设范围内的可用车辆数量，该可用车辆数量不仅可以通过服务请求端当前所处位置范围(如以服务请求端为中心，以5千米所构成的圆形范围)内的历史可用车辆数量来确定，还可以通过当前网约车出行服务场景下，未来预设时长内能够驶入服务请求端当前所处位置范围内的可用车辆数量，例如，在服务请求端发出服务请求之后的5分钟内，行驶终点落入服务请求端当前所处位置范围的可用车辆数量。
接下来通过如下两个方面分别对上述结合订单取消概率和可用车辆数量来确定订单分配的方法进行具体说明。
第一方面：本申请实施例可以在确定出订单取消概率高于预设概率阈值、且可用车辆数量大于预设数量阈值(如5辆)时，可以将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。也即，本申请实施例可以在确定一个服务请求端针对当前预分配的候选服务提供端的订单取消概率较大、且周边存在可用车辆(对应乘客有较大概率通过等待能够获取一个更近距离的车辆)时，向该服务请求端推送接驾等待信息以确定其反馈的等待意愿，再进行订单分配。
在进行订单分配的过程中，如果根据服务请求端的反馈信息确定乘客等待意愿较高(即，确定等待其它候选服务提供端)，这时可以持续寻找更适合的车辆，如果根据服务请求端的反馈信息确定乘客拒绝等待(即，取消等待其它候选服务提供端)时，可以将当前出行订单分配给预分配的服务提供端。
第二方面：若确定出订单取消概率大于预设概率阈值、且可用车辆数量小于或等于预设数量阈值，可以直接将所述服务请求对应的当前出行订单分配至所述候选服务提供端。也即，本申请实施例可以在确定一个服务请求端针对当前预分配的候选服务提供端的订单取消概率较大、但周边不存在可用车辆或可用车辆不足时，可以直接将预分配的候选服务提供端匹配给服务请求端，则主要是考虑到短期内无法获得更合适(如距离更近)的司机。
为了兼顾乘客的用车需求和服务质量，本申请实施例可以在进行订单分配的过程中，推送提醒信息以提醒距离所述服务请求端的预设范围内不存在可分配的其它候选服务提供端，从而缓解用户等待车辆(特别是较远距离等待)所存在的不良情绪。
其中，订单取消概率的确定过程作为本申请实施例提供的订单分配方法的关键步骤，接下来结合图3进行具体说明。
如图3所示，为本申请实施例提供的一种确定订单取消概率的方法流程图，该方法包括如下步骤：
S301、获取服务请求端的当前出行特征数据和历史出行订单信息；
S302、基于所述服务请求端的当前出行特征数据和历史出行订单信息、以及预先训练好的订单取消模型，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
这里，本申请实施例可以首先获取服务请求端的当前出行特征数据和历史出行订单信息，然后基于预先训练好的订单取消模型以及上述获取的当前出行特征数据和历史出行订单信息，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
其中，上述当前出行特征数据，可以是与服务请求端当前出行环境对应的各种特征数据，该特征数据可以是服务请求端对应的当前出行订单信息，如下单时间、订单起始点等信息，该信息可以由用户在用户端输入的打车信息来确定。
此外，上述特征数据还可以是距离所述服务请求端的预设范围内的当前供需数据，该供需数据可以由服务请求端预设范围内的车辆供给情况与车辆需求情况来确定，其中，车辆供给可以由可载客空车数量来确定，车辆需求可以由周边发单数量来确定。本申请实施例中，当前供需数据一定程度上反应了乘客周边的出行环境，出行环境的优良程度一定程度上反应了乘客取消订单再打车的意愿。例如，在出行环境比较恶劣的情况下，周边需求远远大于供给，这时，原本取消意向很大的乘客可能会降低其取消意愿。
再者，上述特征数据还可以是与所述服务请求端匹配的候选服务提供端由该候选服务提供端当前所处的位置行驶至所述服务请求端当前所处的位置的行驶数据，该行驶数据可以是行驶时长、行驶距离、行驶环境等信息，本申请实施例对此不做具体的限制。本申请实施例中，行驶信息一定程度上反应了乘客当前的出行环境，出行环境的优良程度一定程度上反应了乘客的等车意愿。例如，在出行环境比较恶劣的情况下，需要等待时间过长，这时，乘客很大概率可能会降低其等待意愿，而更愿意等待距离更近的其它车辆。
值得说明的是，本申请实施例中，上述特征数据可以是上述任一种特征数据，还可以是各种特征数据的组合，还可以是其它与服务请求端当前出行环境对应的各种特征数据，本申请实施例对此不做具体的限制。
本申请实施例中，为了确定用户历史打车行为对当前订单取消意愿的影响程度，可以对获取的服务请求端的历史出行订单信息进行统计分析，以确定其历史取消数据。该历史取消数据可以是服务请求端近期(例如发起服务请求之前的近四周)的订单完成数量、订单取消数量及应答后取消所对应的平均接驾距离和平均接驾时长等数据。
其中，订单取消数量一定程度上表征了用户应答后取消订单的行为，例如，在针对A用户存在10个订单的情况下，有6个是未完单，4个完单，这时，可以基本确定该A用户的订单取消概率比较大，再结合其平均接驾距离和平均接驾时长等数据可以评估该用户对接驾等待的容忍度。
值得说明的是，不同用户对接驾等待的容忍度不同，例如，A用户对于5分钟可到达其所在位置的预分配的候选服务提供端是可以接受的，即按照预分配策略进行订单分配之后，应答后取消的可能性较小，而B用户对于3分钟可到达其所在位置的预分配的候选服务提供端是不可以接受的，即按照预分配策略进行订单分配之后，应答后取消的可能性较高。此外，同一用户在不同时段对接驾等待的容忍度也不同。例如，针对A用户而言，在天气比较良好的情况下，对于8分钟可到达其所在位置的预分配的候选服务提供端是不可以接受的，而在天气比较恶劣的情况下，对于8分钟可到达其所在位置的预分配的候选服务提供端却是可以接受的。因此，本申请实施例可以综合各种出行特征进行订单取消概率的预测，从而提升其预测的准确度。
为了进一步订单取消概率预测的准确度，本申请实施例可以基于预先训练好的订单取消模型对当前发起服务请求的服务请求端进行订单取消概率的预测。这主要是考虑到利用大量的训练样本训练得到的订单取消模型，能够更大程度上挖掘出用户的订单取消意向，确保预测的准确度。
如图4所示，本申请实施例可以按照如下步骤训练上述订单取消模型：
S401、获取参考服务请求端的各个历史出行订单信息以及与每个历史出行订单信息对应的是否取消订单的确认信息；
S402、将所述参考服务请求端的每个历史出行订单信息输入至待训练的订单取消模型中，得到模型输出的针对该历史出行订单信息的取消确认信息；将模型输出的所述取消确认信息与该历史出行订单信息对应的是否取消订单的确认信息进行对比，若对比不一致，则调整所述待训练的订单取消模型的训练参数，直至对比一致。
这里，训练订单取消模型的过程，即是基于参考服务请求端的历史出行订单信息与该历史出行订单信息对应的是否取消订单的确认信息之间的对应关系，训练模型参数的过程。
本申请实施例中，在进行订单取消模型的训练之前，可以首先从网约车服务平台中获取的各个历史出行订单信息，将其作为样本集。上述历史出行订单信息可以包括：用户下单时间、车辆到达上车点的时间、接驾距离、接驾时长、订单始点、订单终点、是否取消订单、当时堵车情况、运力需求比等信息，还可以包括统计后的历史出行订单信息，如近期的订单完成数量、订单取消数量及应答后取消所对应的平均接驾距离和平均接驾时长等信息。然后，逐条对样本集进行标注，将其标识为是否取消订单(如，取消订单标识为1，完成订单标识为0)。最后，将带有标注的样本集输入待训练的订单取消模型中进行训练。
上述参考服务请求端即对应样本集所对应的服务请求端，其可以有一个，也可以有多个。在本申请实施例中，为了提升订单取消概率预测的鲁棒性，可以获取多个参考服务请求端对应的历史出行订单信息，针对每个参考服务请求端，可以获取多个历史出行订单信息。这样，在进行模型训练的过程中，可以针对一个参考服务请求端的一个历史出行订单信息进行多轮训练，还可以是针对一个参考服务请求端的一个历史出行订单信息进行一轮训练，本申请实施例对此不做具体的限制。
在基于上述模型训练方法训练得到订单取消模型之后，即可以基于当前发起服务请求的服务请求端进行订单取消概率的预测了，取消的订单取消概率越大，一定程度上说明用户对于当前预分配的服务提供端的等待意愿较低，订单取消概率越小，一定程度上说明用户对于当前预分配的服务提供端的等待意愿较高，也即，本申请实施例综合乘客的等待意愿和预分配司机实现最终的订单分配，这有效的降低了后续订单分配后的取消率，节约了网约车服务平台调度的人力和物力成本，进一步提升了服务质量。
实施例二
参照图5所示，为本申请实施例二提供的一种订单分配方法的流程示意图，该方法可以由服务系统中的服务请求端来执行，具体执行过程为：
S501、发送服务请求至服务器；
S502、接收所述服务器生成的与候选服务提供端对应的接驾等待信息；所述候选服务提供端为所述服务器基于所述服务请求确定的服务提供端；
S503、发送针对所述接驾等待信息的反馈信息给所述服务器，以使所述服务器根据所述反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
这里，服务请求端可以基于发单按钮发出服务请求，服务器在接收到该服务请求之后，即可以为所述服务请求端确定候选服务提供端，并生成与所述候选服务提供端对应的接驾等待信息，并可以将生成的接驾等待信息发送给服务请求端。服务请求端在结合到接驾等待信息之后，可以返回针对该信息的反馈信息以便服务器根据反馈信息进行订单分配。
其中，有关接驾等待信息的确定过程、反馈信息的相关方式具体参见本申请实施例一中的相关描述，在此不再赘述。
实施例三
基于同一发明构思，本申请实施例中还提供了与订单分配方法对应的订单分配装置，由于本申请实施例中的装置解决问题的原理与本申请实施例上述订单分配方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。
参照图6示，为本申请实施例三提供的一种订单分配装置的示意图，所述装置包括：
响应模块601，用于响应服务请求端发起的服务请求，为所述服务请求端确定候选服务提供端，并生成与所述候选服务提供端对应的接驾等待信息；
发送模块602，用于将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端；
第一分配模块603，用于基于所述服务请求端针对所述接驾等待信息的反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在一种实施方式中，所述发送模块602，用于按照如下步骤将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端：
将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端之前，确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率；
若所述订单取消概率满足预设条件，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
在一种实施方式中，所述装置还包括：
第二分配模块604，用于若所述订单取消概率不满足预设条件，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在一种实施方式中，所述发送模块602，用于按照步骤确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率：
获取所述服务请求端的当前出行特征数据和历史出行订单信息；
基于所述服务请求端的当前出行特征数据和历史出行订单信息、以及预先训练好的订单取消模型，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
在一种实施方式中，所述发送模块602，用于根据以下一种或多种方式，确定所述服务请求端的当前出行特征数据：
将所述服务请求端对应的当前出行订单信息，确定为所述服务请求端的一种当前出行特征数据；
将距离所述服务请求端的预设范围内的当前供需数据，确定为所述服务请求端的一种当前出行特征数据；
将与所述服务请求端匹配的候选服务提供端由该候选服务提供端当前所处的位置行驶至所述服务请求端当前所处的位置的行驶数据，确定为所述服务请求端的一种当前出行特征数据。
在一种实施方式中，所述发送模块602，用于按照步骤预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率：
对所述服务请求端的历史出行订单信息进行统计分析，确定历史订单取消数据；
将所述服务请求端的当前出行特征数据以及所述历史订单取消数据输入至预先训练好的订单取消模型中，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
在一种实施方式中，所述发送模块602，用于按照如下步骤训练所述订单取消模型：
获取参考服务请求端的各个历史出行订单信息以及与每个历史出行订单信息对应的是否取消订单的确认信息；
将所述参考服务请求端的每个历史出行订单信息输入至待训练的订单取消模型中，得到模型输出的针对该历史出行订单信息的取消确认信息；将模型输出的所述取消确认信息与该历史出行订单信息对应的是否取消订单的确认信息进行对比，若对比不一致，则调整所述待训练的订单取消模型的训练参数，直至对比一致。
在一种实施方式中，所述发送模块602，用于按照如下步骤将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端：
若所述订单取消概率大于预设概率阈值，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
在一种实施方式中，所述发送模块602，用于按照如下步骤将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端：
获取距离所述服务请求端的预设范围内的可用车辆数量；
若所述可用车辆数量大于预设数量阈值、且所述订单取消概率大于预设概率阈值，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
在一种实施方式中，所述第二分配模块604，用于按照如下步骤将所述服务请求对应的当前出行订单分配至所述候选服务提供端：
若所述订单取消概率小于或等于预设概率阈值，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在一种实施方式中，所述第二分配模块604，用于按照如下步骤将所述服务请求对应的当前出行订单分配至所述候选服务提供端：
获取距离所述服务请求端的预设范围内的可用车辆数量；
若所述可用车辆数量小于或等于预设数量阈值、且所述订单取消概率大于预设概率阈值，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端，并向所述服务请求端推送提醒信息；所述提醒信息用于指示距离所述服务请求端的预设范围内不存在可分配的其它候选服务提供端。
在一种实施方式中，所述第一分配模块603，用于按照如下步骤确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端：
若根据所述服务请求端针对所述接驾等待信息的反馈信息确定出所述服务请求端确定等待其它候选服务提供端，则将所述服务请求对应的当前出行订单分配至所述其它候选服务提供端；
若根据所述服务请求端针对所述接驾等待信息的反馈信息确定出所述服务请求端取消等待其它候选服务提供端，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
参照图7所示，为本申请实施例三提供的另一种订单分配装置的示意图，所述装置包括：
第一发送模块701，用于发送服务请求至服务器；
接收模块702，用于接收所述服务器生成的与候选服务提供端对应的接驾等待信息；所述候选服务提供端为所述服务器基于所述服务请求确定的服务提供端；
第二发送模块703，用于发送针对所述接驾等待信息的反馈信息给所述服务器，以使所述服务器根据所述反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
实施例四
本申请实施例四提供了一种电子设备，该电子设备可以是服务器，还可以是服务请求端，在服务器作为电子设备时，如图8所示为本申请实施例提供的一种电子设备的结构示意图，该电子设备可以包括：处理器801、存储介质802、和总线803。所述存储介质802存储有所述处理器801可执行的机器可读指令(比如，图中的订单分配装置中响应模块601、发送模块602、以及第一分配模块603对应的执行指令)，当电子设备运行时，所述处理器801与所述存储介质802之间通过总线803通信，所述机器可读指令被所述处理器801执行时执行如上述实施例一所述的订单分配方法的如下指令：
响应服务请求端发起的服务请求，为所述服务请求端确定候选服务提供端，并生成与所述候选服务提供端对应的接驾等待信息；
将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端；
基于所述服务请求端针对所述接驾等待信息的反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在一种实施方式中，将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端之前，上述处理器801执行的指令还包括：
确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率；
所述将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端，包括：
若所述订单取消概率满足预设条件，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
在一种实施方式中，上述处理器801执行的指令还包括：
若所述订单取消概率不满足预设条件，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在一种实施方式中，上述处理器801执行的指令中，所述确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率，包括：
获取所述服务请求端的当前出行特征数据和历史出行订单信息；
基于所述服务请求端的当前出行特征数据和历史出行订单信息、以及预先训练好的订单取消模型，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
在一种实施方式中，上述处理器801执行的指令中，可以根据以下一种或多种方式，确定所述服务请求端的当前出行特征数据：
将所述服务请求端对应的当前出行订单信息，确定为所述服务请求端的一种当前出行特征数据；
将距离所述服务请求端的预设范围内的当前供需数据，确定为所述服务请求端的一种当前出行特征数据；
将与所述服务请求端匹配的候选服务提供端由该候选服务提供端当前所处的位置行驶至所述服务请求端当前所处的位置的行驶数据，确定为所述服务请求端的一种当前出行特征数据。
在一种实施方式中，上述处理器801执行的指令中，所述基于所述服务请求端的当前出行特征数据和历史出行订单信息、以及预先训练好的订单取消模型，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率，包括：
对所述服务请求端的历史出行订单信息进行统计分析，确定历史订单取消数据；
将所述服务请求端的当前出行特征数据以及所述历史订单取消数据输入至预先训练好的订单取消模型中，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
在一种实施方式中，上述处理器801执行的指令中，按照如下步骤训练所述订单取消模型：
获取参考服务请求端的各个历史出行订单信息以及与每个历史出行订单信息对应的是否取消订单的确认信息；
将所述参考服务请求端的每个历史出行订单信息输入至待训练的订单取消模型中，得到模型输出的针对该历史出行订单信息的取消确认信息；将模型输出的所述取消确认信息与该历史出行订单信息对应的是否取消订单的确认信息进行对比，若对比不一致，则调整所述待训练的订单取消模型的训练参数，直至对比一致。
在一种实施方式中，上述处理器801执行的指令中，若所述订单取消概率满足预设条件，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端，包括：
若所述订单取消概率大于预设概率阈值，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
在一种实施方式中，上述处理器801执行的指令中，若所述订单取消概率满足预设条件，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端，包括：
获取距离所述服务请求端的预设范围内的可用车辆数量；
若所述可用车辆数量大于预设数量阈值、且所述订单取消概率大于预设概率阈值，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
在一种实施方式中，上述处理器801执行的指令中，若所述订单取消概率不满足预设条件，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端，包括：
若所述订单取消概率小于或等于预设概率阈值，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在一种实施方式中，上述处理器801执行的指令中，若所述订单取消概率不满足预设条件，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端，包括：
获取距离所述服务请求端的预设范围内的可用车辆数量；
若所述可用车辆数量小于或等于预设数量阈值、且所述订单取消概率大于预设概率阈值，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端，并向所述服务请求端推送提醒信息；所述提醒信息用于指示距离所述服务请求端的预设范围内不存在可分配的其它候选服务提供端。
在一种实施方式中，上述处理器801执行的指令中，所述根据所述服务请求端针对所述接驾等待信息的反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端，包括：
若根据所述服务请求端针对所述接驾等待信息的反馈信息确定出所述服务请求端确定等待其它候选服务提供端，则将所述服务请求对应的当前出行订单分配至所述其它候选服务提供端；
若根据所述服务请求端针对所述接驾等待信息的反馈信息确定出所述服务请求端取消等待其它候选服务提供端，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
在服务请求端作为电子设备时，如图9所示为本申请实施例提供的另一种电子设备的结构示意图，该电子设备可以包括：处理器901、存储介质902、和总线903。所述存储介质902存储有所述处理器901可执行的机器可读指令(比如，图中的订单分配装置中第一发送模块701、接收模块702、以及第二发送模块703对应的执行指令)，当电子设备运行时，所述处理器901与所述存储介质902之间通过总线903通信，所述机器可读指令被所述处理器901执行时执行如上述实施例二所述的订单分配方法的如下指令：
发送服务请求至服务器；
接收所述服务器生成的与候选服务提供端对应的接驾等待信息；所述候选服务提供端为所述服务器基于所述服务请求确定的服务提供端；
发送针对所述接驾等待信息的反馈信息给所述服务器，以使所述服务器根据所述反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器801运行时执行上述实施例一所述的订单分配方法步骤，以及被处理器901运行时执行上述实施例二所述的订单分配方法步骤。
具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述订单分配方法，能够达到通过乘客对接驾等待信息的反馈进行订单分配，有效减少订单被接单后又取消的情况，提升了网约车服务平台的服务质量，也节省了司乘资源的技术效果。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (24)

1.一种订单分配方法，其特征在于，所述方法包括：
响应服务请求端发起的服务请求，为所述服务请求端确定候选服务提供端，并生成与所述候选服务提供端对应的接驾等待信息；
确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率；
若所述订单取消概率满足预设条件，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端；
基于所述服务请求端针对所述接驾等待信息的反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端；
其中，所述确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率，包括：
获取所述服务请求端的当前出行特征数据和历史出行订单信息；所述当前出行特征数据包括距离所述服务请求端的预设范围内的当前供需数据；
基于所述服务请求端的当前出行特征数据和历史出行订单信息、以及预先训练好的订单取消模型，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
若所述订单取消概率不满足预设条件，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
3.根据权利要求2所述的方法，其特征在于，根据以下一种或多种方式，确定所述服务请求端的当前出行特征数据：
将所述服务请求端对应的当前出行订单信息，确定为所述服务请求端的一种当前出行特征数据；
将与所述服务请求端匹配的候选服务提供端由该候选服务提供端当前所处的位置行驶至所述服务请求端当前所处的位置的行驶数据，确定为所述服务请求端的一种当前出行特征数据。
4.根据权利要求1所述的方法，其特征在于，所述基于所述服务请求端的当前出行特征数据和历史出行订单信息、以及预先训练好的订单取消模型，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率，包括：
对所述服务请求端的历史出行订单信息进行统计分析，确定历史订单取消数据；
将所述服务请求端的当前出行特征数据以及所述历史订单取消数据输入至预先训练好的订单取消模型中，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
5.根据权利要求1所述的方法，其特征在于，按照如下步骤训练所述订单取消模型：
获取参考服务请求端的各个历史出行订单信息以及与每个历史出行订单信息对应的是否取消订单的确认信息；
将所述参考服务请求端的每个历史出行订单信息输入至待训练的订单取消模型中，得到模型输出的针对该历史出行订单信息的取消确认信息；将模型输出的所述取消确认信息与该历史出行订单信息对应的是否取消订单的确认信息进行对比，若对比不一致，则调整所述待训练的订单取消模型的训练参数，直至对比一致。
6.根据权利要求1所述的方法，其特征在于，若所述订单取消概率满足预设条件，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端，包括：
若所述订单取消概率大于预设概率阈值，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
7.根据权利要求1所述的方法，其特征在于，若所述订单取消概率满足预设条件，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端，包括：
获取距离所述服务请求端的预设范围内的可用车辆数量；
若所述可用车辆数量大于预设数量阈值、且所述订单取消概率大于预设概率阈值，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
8.根据权利要求2所述的方法，其特征在于，若所述订单取消概率不满足预设条件，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端，包括：
若所述订单取消概率小于或等于预设概率阈值，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
9.根据权利要求2所述的方法，其特征在于，若所述订单取消概率不满足预设条件，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端，包括：
获取距离所述服务请求端的预设范围内的可用车辆数量；
若所述可用车辆数量小于或等于预设数量阈值、且所述订单取消概率大于预设概率阈值，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端，并向所述服务请求端推送提醒信息；所述提醒信息用于指示距离所述服务请求端的预设范围内不存在可分配的其它候选服务提供端。
10.根据权利要求1所述的方法，其特征在于，所述根据所述服务请求端针对所述接驾等待信息的反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端，包括：
若根据所述服务请求端针对所述接驾等待信息的反馈信息确定出所述服务请求端确定等待其它候选服务提供端，则将所述服务请求对应的当前出行订单分配至所述其它候选服务提供端；
若根据所述服务请求端针对所述接驾等待信息的反馈信息确定出所述服务请求端取消等待其它候选服务提供端，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
11.一种订单分配方法，其特征在于，所述方法包括：
发送服务请求至服务器；所述服务请求用于指示所述服务器为服务请求端确定候选服务提供端，以及确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率；
接收所述订单取消概率满足预设条件的情况下所述服务器生成的与所述候选服务提供端对应的接驾等待信息；所述候选服务提供端为所述服务器基于所述服务请求确定的服务提供端；
发送针对所述接驾等待信息的反馈信息给所述服务器，以使所述服务器根据所述反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端；
其中，所述确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率，包括：
获取所述服务请求端的当前出行特征数据和历史出行订单信息；所述当前出行特征数据包括距离所述服务请求端的预设范围内的当前供需数据；
基于所述服务请求端的当前出行特征数据和历史出行订单信息、以及预先训练好的订单取消模型，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
12.一种订单分配装置，其特征在于，所述装置包括：
响应模块，用于响应服务请求端发起的服务请求，为所述服务请求端确定候选服务提供端，并生成与所述候选服务提供端对应的接驾等待信息；
发送模块，用于确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率；若所述订单取消概率满足预设条件，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端；
第一分配模块，用于基于所述服务请求端针对所述接驾等待信息的反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端；
其中，所述发送模块，用于按照步骤确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率，包括：
获取所述服务请求端的当前出行特征数据和历史出行订单信息；所述当前出行特征数据包括距离所述服务请求端的预设范围内的当前供需数据；
基于所述服务请求端的当前出行特征数据和历史出行订单信息、以及预先训练好的订单取消模型，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
13.根据权利要求12所述的装置，其特征在于，所述装置还包括：
第二分配模块，用于若所述订单取消概率不满足预设条件，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
14.根据权利要求12所述的装置，其特征在于，所述发送模块，用于根据以下一种或多种方式，确定所述服务请求端的当前出行特征数据：
将所述服务请求端对应的当前出行订单信息，确定为所述服务请求端的一种当前出行特征数据；
将与所述服务请求端匹配的候选服务提供端由该候选服务提供端当前所处的位置行驶至所述服务请求端当前所处的位置的行驶数据，确定为所述服务请求端的一种当前出行特征数据。
15.根据权利要求12所述的装置，其特征在于，所述发送模块，用于按照步骤预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率：
对所述服务请求端的历史出行订单信息进行统计分析，确定历史订单取消数据；
将所述服务请求端的当前出行特征数据以及所述历史订单取消数据输入至预先训练好的订单取消模型中，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
16.根据权利要求12所述的装置，其特征在于，所述发送模块，用于按照如下步骤训练所述订单取消模型：
获取参考服务请求端的各个历史出行订单信息以及与每个历史出行订单信息对应的是否取消订单的确认信息；
将所述参考服务请求端的每个历史出行订单信息输入至待训练的订单取消模型中，得到模型输出的针对该历史出行订单信息的取消确认信息；将模型输出的所述取消确认信息与该历史出行订单信息对应的是否取消订单的确认信息进行对比，若对比不一致，则调整所述待训练的订单取消模型的训练参数，直至对比一致。
17.根据权利要求12所述的装置，其特征在于，所述发送模块，用于按照如下步骤将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端：
若所述订单取消概率大于预设概率阈值，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
18.根据权利要求12所述的装置，其特征在于，所述发送模块，用于按照如下步骤将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端：
获取距离所述服务请求端的预设范围内的可用车辆数量；
若所述可用车辆数量大于预设数量阈值、且所述订单取消概率大于预设概率阈值，则将与所述候选服务提供端对应的接驾等待信息发送给所述服务请求端。
19.根据权利要求13所述的装置，其特征在于，所述第二分配模块，用于按照如下步骤将所述服务请求对应的当前出行订单分配至所述候选服务提供端：
若所述订单取消概率小于或等于预设概率阈值，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
20.根据权利要求13所述的装置，其特征在于，所述第二分配模块，用于按照如下步骤将所述服务请求对应的当前出行订单分配至所述候选服务提供端：
获取距离所述服务请求端的预设范围内的可用车辆数量；
若所述可用车辆数量小于或等于预设数量阈值、且所述订单取消概率大于预设概率阈值，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端，并向所述服务请求端推送提醒信息；所述提醒信息用于指示距离所述服务请求端的预设范围内不存在可分配的其它候选服务提供端。
21.根据权利要求12所述的装置，其特征在于，所述第一分配模块，用于按照如下步骤确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端：
若根据所述服务请求端针对所述接驾等待信息的反馈信息确定出所述服务请求端确定等待其它候选服务提供端，则将所述服务请求对应的当前出行订单分配至所述其它候选服务提供端；
若根据所述服务请求端针对所述接驾等待信息的反馈信息确定出所述服务请求端取消等待其它候选服务提供端，则将所述服务请求对应的当前出行订单分配至所述候选服务提供端。
22.一种订单分配装置，其特征在于，所述装置包括：
第一发送模块，用于发送服务请求至服务器；所述服务请求用于指示所述服务器为服务请求端确定候选服务提供端，以及确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率；
接收模块，用于接收所述订单取消概率满足预设条件的情况下所述服务器生成的与候选服务提供端对应的接驾等待信息；所述候选服务提供端为所述服务器基于所述服务请求确定的服务提供端；
第二发送模块，用于发送针对所述接驾等待信息的反馈信息给所述服务器，以使所述服务器根据所述反馈信息，确定是否将所述服务请求对应的当前出行订单分配至所述候选服务提供端；
其中，所述确定在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率，包括：
获取所述服务请求端的当前出行特征数据和历史出行订单信息；所述当前出行特征数据包括距离所述服务请求端的预设范围内的当前供需数据；
基于所述服务请求端的当前出行特征数据和历史出行订单信息、以及预先训练好的订单取消模型，预测在将所述服务请求分配给所述候选服务提供端的情况下，对应的订单取消概率。
23.一种电子设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如权利要求1至11任一所述订单分配方法的步骤。
24.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如权利要求1至11任一所述订单分配方法的步骤。
CN201911337216.6A 2019-12-23 2019-12-23 一种订单分配方法、装置、电子设备及存储介质 Active CN111861081B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911337216.6A CN111861081B (zh) 2019-12-23 2019-12-23 一种订单分配方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911337216.6A CN111861081B (zh) 2019-12-23 2019-12-23 一种订单分配方法、装置、电子设备及存储介质

Publications (2)

Publication Number Publication Date
CN111861081A CN111861081A (zh) 2020-10-30
CN111861081B true CN111861081B (zh) 2024-06-21

Family

ID=72970804

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911337216.6A Active CN111861081B (zh) 2019-12-23 2019-12-23 一种订单分配方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN111861081B (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220188958A1 (en) * 2020-12-16 2022-06-16 Uber Technologies, Inc. Network system for controlling communications based on user context
CN113129102B (zh) * 2021-04-20 2022-04-12 南京领行科技股份有限公司 一种延迟派单方法、装置、电子设备及存储介质
CN113610258A (zh) * 2021-08-16 2021-11-05 重庆愉客行网络有限公司 一种可接入多个运营平台的网约车车机系统
CN114067597B (zh) * 2021-11-17 2023-01-31 哈尔滨工业大学 一种基于强化学习的不同合乘意愿下出租车调度方法
CN114004546A (zh) * 2021-12-30 2022-02-01 南京领行科技股份有限公司 网约车分配方法、装置、电子设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107122866A (zh) * 2017-05-03 2017-09-01 百度在线网络技术（北京）有限公司 预估乘客取消订单行为的方法、设备及存储介质
CN108090645A (zh) * 2016-11-23 2018-05-29 北京嘀嘀无限科技发展有限公司 用于调配服务资源的方法及装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016119749A1 (zh) * 2015-01-29 2016-08-04 北京嘀嘀无限科技发展有限公司 一种订单分配系统及方法
KR102441168B1 (ko) * 2015-05-08 2022-09-07 삼성전자주식회사 차량 서비스를 위한 자원 할당 장치 및 방법
CN108009841A (zh) * 2017-03-29 2018-05-08 北京嘀嘀无限科技发展有限公司 网约车服务请求处理方法、装置和服务器
CN107610458B (zh) * 2017-09-21 2019-12-17 珠海好的软件有限公司 一种打车订单信息生成方法及装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108090645A (zh) * 2016-11-23 2018-05-29 北京嘀嘀无限科技发展有限公司 用于调配服务资源的方法及装置
CN107122866A (zh) * 2017-05-03 2017-09-01 百度在线网络技术（北京）有限公司 预估乘客取消订单行为的方法、设备及存储介质

Also Published As

Publication number Publication date
CN111861081A (zh) 2020-10-30

Similar Documents

Publication Publication Date Title
CN111861081B (zh) 一种订单分配方法、装置、电子设备及存储介质
CN111832788B (zh) 一种服务信息生成的方法、装置、计算机设备及存储介质
WO2016135652A1 (en) Systems and methods for vehicle resource management
CN110998648A (zh) 一种分配订单的系统和方法
EP3262831B1 (en) Telephone call placement
CN110633815A (zh) 一种拼车方法和装置、电子设备、存储介质
CN111859172B (zh) 信息推送方法、装置、电子设备和计算机可读存储介质
CN112344949A (zh) 计算机可读记录介质、控制装置、系统、装置和车辆
CN116843166B (zh) 一种打车方法、装置、设备及介质
CN117636681A (zh) 一种停车场推荐方法、装置、电子设备及存储介质
CN111859176B (zh) 一种信息推荐方法、装置、电子设备及存储介质
CN110826943B (zh) 判断是否需要进行配车及确定公交配车数的方法及相关设备
CN111260840B (zh) 信息推送方法、装置、电子设备及计算机存储介质
CN111612184B (zh) 行驶支援装置、车辆、行驶管理装置、终端装置和行驶支援方法
CN111651687A (zh) 上车点信息推送方法及装置、下车点信息推送方法及装置
CN112001516B (zh) 一种信息处理方法、装置、电子设备及存储介质
CN114493236A (zh) 服务车辆分派方法、装置、设备、介质及程序产品
CN111866051B (zh) 一种资源信息的分配方法、装置、设备及介质
CN111651686B (zh) 一种测试处理方法、装置、电子设备及存储介质
CN110254284B (zh) 电动出租车充电提醒方法、电子设备及存储介质
CN107808296A (zh) 一种车载娱乐设备信息推送方法、装置及车载娱乐设备
CN108229708B (zh) 基于无人机的预约充电方法和装置
CN111507753A (zh) 信息推送方法、装置和电子设备
CN111915043A (zh) 服务数据处理方法、装置、服务器及存储介质
CN113271248B (zh) 控制装置、控制系统、计算机可读非暂时性存储介质和控制方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant