CN111178567B - 信息处理方法和设备 - Google Patents

Abstract

本申请公开了一种信息处理方法和设备，本方案在用户通过用户客户端向控制中心发送了约车订单之后，如果控制中心向该约车订单的起始位置调度了车辆，则确认该约车订单响应成功，这样，该用户具备从该约车订单对应的起始位置处乘坐空乘车辆并使得该空乘车辆作为该用户的服务车辆的权限，使得约车订单响应成功且已到达该约车订单的起始位置处的用户可以优先登车，从而既有利于减少用户等待车辆的等待时长，也有利于减少车辆登车用户登车的等待时长，进而实现了资源的合理分配，减少了资源浪费。

Description

信息处理方法和设备

技术领域

本申请涉及信息处理技术领域，更具体地说，涉及一种信息处理方法和设备。

背景技术

网络约车已经十分普遍。如，用户在出门之前先通过终端设备向约车平台发送约车订单，并在约车平台为用户分派了平台车辆且平台车辆到达之后，直接乘坐该平台车辆。

然而，如果一个区域内网络约车的用户较多，那么就很容易出现一部分用户已经到达约定的乘车地点但是分派的平台车辆却尚未到达，而有些平台车辆已经到达但是待乘车的用户却尚未抵达乘车地点，从而导致平台车辆以及乘车用户等待时间较长，造成资源浪费。

发明内容

本申请的目的是提供一种信息处理方法和设备，以实现更为合理的约车服务，减少约车服务中的资源浪费。

为实现上述目的，本申请提供了如下技术方案：

一方面，本申请提供了一种信息处理方法，包括：

接收用户客户端发送的约车订单，所述约车订单指示有：起始位置和目的位置；

基于所述约车订单，如果向所述起始位置调度了空乘车辆，将所述约车订单加入订单响应成功列表；

向所述用户客户端发送反馈指示，以使得所述用户客户端提示约车用户的约车订单响应成功；

接收车载控制端发送的登车用户的同步信息，所述同步信息至少包括所述登车用户的约车订单；

如果所述登车用户的约车订单属于所述订单响应成功列表，向所述车载控制端发送响应指示，所述响应指示用于指示所述车载控制端响应所述登车用户的约车订单，以使得具有所述车载控制端的空乘车辆作为服务车辆载所述登车用户至所述登车用户的目的位置。

优选的，所述基于所述约车订单，如果向所述起始位置调度了空乘车辆，将所述约车订单加入订单响应成功列表，包括：

基于所述约车订单，如果向空乘车辆的车载控制端派发了调度指示，将所述约车订单加入订单响应成功列表，所述调度指示至少用于指示所述空乘车辆以所述起始位置作为待载乘客的乘车位置；

或者，

在发布了所述约车订单且接收到空乘车辆上的车载控制端针对所述约车订单的接单指示，将所述约车订单加入订单响应成功列表。

优选的，在所述向所述车载控制端发送响应指示的同时或者之后，还包括：

如果所述车载控制端关联有与所述登车用户的约车订单具有相同起始位置的其他约车订单，控制取消所述车载控制端关联的所述其他约车订单。

又一方面，本申请还提供了一种信息处理方法，包括：

发送约车订单，所述约车订单指示有：起始位置及目的位置；

获得提示信息，所述提示信息用于提示所述约车订单响应成功；

获得并发送空乘车辆的车辆信息，以使得控制中心将所述空乘车辆标定为服务所述约车订单的服务车辆。

优选的，所述获得并发送空乘车辆的车辆信息，包括：

获得空乘车辆的车辆信息；

向控制中心发送登车指示，所述登车指示携带有所述空乘车辆的车辆信息，且所述登车指示用于请求控制中心将所述空乘车辆标定为服务所述约车订单的服务车辆。

又一方面，本申请还提供了一种信息处理方法，包括：

获得登车用户的身份信息；

向控制中心发送所述登车用户的身份信息，以使得控制中心基于所述登车用户的身份信息，检测所述登车用户是否属于约车订单响应成功的用户；

如所述控制中心确认所述登车用户属于约车订单响应成功的用户，获得所述登车用户的目的位置；

将所述目的位置设置为车载控制端所在的车辆的目的位置，以将所述车辆作为所述登车用户的服务车辆并载所述登车用户至所述目的位置。

优选的，所述获得所述登车用户的目的位置，包括：

获得所述登车用户的约车订单，确定所述约车订单中指示的目的位置；

或者，

获得所述登车用户输入的目的位置。

优选的，还包括：

如所述控制中心确认所述登车用户属于约车订单响应成功的用户，控制车载控制端所在的车辆的车门解锁，以使得所述登车用户乘坐所述车辆。

优选的，还包括：

获得所述控制中心返回的车辆标定指示，所述车辆标定指示用于指示所述登车用户属于约车订单响应成功的用户，且指示所述车载控制端将所述车载控制端所在的车辆作为所述登车用户的服务车辆；

所述将所述目的位置设置为车载控制端所在的车辆的目的位置，包括：

响应于所述车辆标定指示，将所述目的位置设置为车载控制端所在的车辆的目的位置。

又一方面，本申请还提供了一种服务器，包括：

通信接口和处理器；

其中，所述通信接口，用于接收用户客户端发送的约车订单，所述约车订单指示有：起始位置和目的位置；

所述处理器，用于基于所述约车订单，如果向所述起始位置调度了空乘车辆，将所述约车订单加入订单响应成功列表；并控制所述通信接口向所述用户客户端发送反馈指示，以使得所述用户客户端提示约车用户的约车订单响应成功；

所述通信接口，还用于接收车载控制端发送的登车用户的同步信息，所述同步信息至少包括所述登车用户的约车订单；

所述处理器，还用于如果所述登车用户的约车订单属于所述订单响应成功列表，控制所述通信接口向所述车载控制端发送响应指示，所述响应指示用于指示所述车载控制端响应所述登车用户的约车订单，以使得具有所述车载控制端的空乘车辆作为服务车辆载所述登车用户至所述登车用户的目的位置。

又一方面，本申请还提供了一种用户客户端，包括：

通信接口和处理器；

其中，所述通信接口，用于发送约车订单，所述约车订单指示有：起始位置及目的位置；获得提示信息，所述提示信息用于提示所述约车订单响应成功；

所述处理器，用于获得空乘车辆的车辆信息，并控制所述通信接口向控制中心发送所述空乘车辆的车辆信息，以使得控制中心将所述空乘车辆标定为服务所述约车订单的服务车辆。

又一方面，本申请还提供了一种车载控制终端，包括：

采集模块，用于获得登车用户的身份信息；

通信接口，用于向控制中心发送所述登车用户的身份信息，以使得控制中心基于所述登车用户的身份信息，检测所述登车用户是否属于约车订单响应成功的用户；

处理器，用于如所述控制中心确认所述登车用户属于约车订单响应成功的用户，获得所述登车用户的目的位置；将所述目的位置设置为车载控制端所在的车辆的目的位置，以将所述车辆作为所述登车用户的服务车辆并载所述登车用户至所述目的位置。

通过以上方案可知，在用户通过用户客户端向控制中心发送了约车订单之后，如果控制中心向该约车订单的起始位置调度了车辆，则确认该约车订单响应成功，在该种情况下，该用户便具备从该约车订单对应的起始位置处乘坐空乘车辆并使得该空乘车辆作为该用户的服务车辆的权限，这样，有利于使得约车订单响应成功且已到达该约车订单的起始位置处的用户可以优先登车，从而既有利于减少用户等待车辆的等待时长，也有利于减少车辆登车用户登车的等待时长，进而实现了资源的合理分配，减少了资源浪费。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的信息处理***的一种组成架构示意图；

图2为本申请实施例提供的一种信息处理方法的一种流程示意图；

图3为本申请实施例提供的一种信息处理方法的一种流程交互示意图；

图4为本申请实施例提供的一种信息处理方法又一种流程示意图；

图5为本申请实施例提供的一种信息处理方法的一种流程交互示意图；

图6为本申请实施例提供的一种信息处理方法又一种流程示意图；

图7为本申请实施例提供的一种信息处理方法的又一种流程交互示意图；

图8为本申请实施例提供的一种服务器的一种组成结构示意图；

图9为本申请实施例提供的一种车载控制终端的一种组成结构示意图。

说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的部分，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示的以外的顺序实施。

具体实施方式

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

本申请的方案适用于约车控制，以实现更为合理的为用户提供约车服务，减少车辆和用户的等待时长，并减少约车服务过程中的资源浪费。

为了便于理解本申请的方案，下面对本申请的方案所适用的信息处理***进行介绍。

如图1所示，其示出了本申请的一种信息处理***的一种组成架构示意图。

由图1可知，该***包括控制中心10、车载控制终端20和用户客户端30。

其中，控制中心10可以由一台或者多台服务器101构成。

车载控制终端20为设置于车辆上的控制装置。其中，该车载控制终端通过网络与控制中心建立通信连接。如，车载控制终端可以响应控制中心的调度指示，并向控制中心上报车辆的位置信息以及乘坐车辆的乘客信息等等。

用户客户端30为用户侧实现约车操作的约车应用所在的终端，如具有约车应用的手机、平板电脑等等。其中，该用户客户端可以通过网络与该控制中心建立通信连接。如，用户客户端可以向控制中心发送用户的约车订单，并获得控制中心对该约车订单的响应结果等。

需要说明的是，本申请实施例中设置有车载控制终端的车辆是指控制中心可调度的车辆，该车辆可以为无人驾驶车辆，也可以是常规的有人驾驶车辆。同时，该车辆可以是控制中心直接控制的车辆，也可以是经过不同约车平台间接控制的车辆。

下面结合流程图对本申请的信息处理方法进行介绍。

针对本申请的信息处理方法的一种实现可能，首先从控制中心侧对信息处理方法进行介绍。如，参见图2，其示出了本申请的一种信息处理方法的一种流程示意图，本实施例应用于控制中心，该流程可以包括：

S201，接收用户客户端发送的约车订单，该约车订单指示有：起始位置和目的位置。

其中，该起始位置为用户客户端的用户请求乘车的位置；而该目的位置为该用户请求到达的位置。

可选的，为了区分出不同用户发送的约车订单，该约车订单还可以指示有用户的用户标识以及用户客户端的客户端标识中的一种或者多种。其中，用户标识可以为用户的姓名或者账号等；而客户端标识可以为用户客户端的IP地址或者设备编码等。

S202，基于该约车订单，如果向该起始位置调度了空乘车辆，将该约车订单加入订单响应成功列表。

其中，向该起始位置调度的空乘车辆是指没有乘客乘坐，且目前未接受控制中心的调度任务的车辆。

可以理解的是，约车订单中包含有用户乘车的起始位置，为了保证用户有车可乘，控制中心需要向起始位置调度空乘车辆。但是需要说明的是，在本申请实施例中，控制中心并不关心该空乘车辆是否已经到达该约车订单的起始位置，只要是已经针对该约车订单调度了空乘车辆，则可以将该约车订单作为成功响应的约车订单，并将该约车订单加入订单响应成功列表。

其中，基于约车订单向起始位置调度空乘车辆的方式可以有多种可能，下面以几种情况为例说明。

在一种可能的情况中，控制中心可以基于该约车订单，向空乘车辆的车载控制端派发调度指示，该调度指示至少用于指示空乘车辆以该约车订单的起始位置作为待载乘客的乘车位置。该种情况为控制中心指定某台空乘车辆作为需要针对该约车订单调度的车辆。

如，控制中心可以获得所有可调度的空乘车辆。然后，结合各个可调度的空乘车辆当前所处的位置与该约车订单的约车位置，确定距离该约车订单的起始位置最近或者到达该起始位置所需时间最短的空乘车辆，向确定出的该空乘车辆派发调度指示。

其中，控制中心向空乘车辆派发该调度指示可以是控制中心直接向空乘车辆下发调度指示，如，控制中心可以与该控制中心控制下的各个无人驾驶车辆或者有人驾驶车辆上的车载控制终端直接通信的情况下，控制中心可以直接向适合的空乘车辆派发调度指示。在将一个或者多个约车平台接入该控制中心的情况下，控制中心可以经过约车平台的服务器向适合的空乘车辆下发调度指示。

相应的，在向车载控制端派发了调度指示，则确认针对该约车订单调度了空乘车辆，从而可以将该约车订单加入订单响应成功列表。

在又一种可能的情况中，控制中心可以在发布了该约车订单且接收到空乘车辆上的车载控制端针对该约车订单的接单指示后，确认向该约车订单的起始位置调度了空乘车辆。

其中，发布约车订单是指将该约车订单的信息发送给空乘车辆的车载控制端。如，控制中心发布约车订单可以为向该控制中心直接或者间接管理的车辆(如全部车辆或者仅满足可调度的空乘车辆)发送订单发布指示，该订单发布指示至少指示有该约车订单的起始位置。

相应的，如果车载控制端确认接受该约车订单，则可以向控制中心发送接单指示。如，车载控制端可以根据该车载控制端所在的车辆所在的位置以及是否属于空乘车辆等，确认当前是否适合接受该约车订单。又如，车载控制端也可以是在车辆驾驶者输入针对该约车订单的接受指令后，向控制中心发送接单指示。

可选的，在该约车订单携带有约车用户的用户标识的情况下，该控制中心还可以基于该用户标识检测该约车用户是否具备约车权限等，在确认约车用户具备约车权限的情况下，基于该约车订单进行车辆调度。

S203，向该用户客户端发送反馈指示，以使得该用户客户端提示约车用户的约车订单响应成功。

其中，该反馈指示为控制中心将约车订单加入响应成功列表之后向用户客户端发送的。通过该反馈指示可以提示用户该约车订单已经被成功响应，在该种情况下，该用户客户端的约车用户具备在约车订单的起始位置处乘坐空乘车辆的权限，相应的，该约车用户可以在该约车订单的起始位置处选择空乘车辆登车。

可以理解的是，为了区分非提供约车服务的车辆和提供约车服务的车辆，以使得用户可以确认在该起始位置处哪些车辆是可以选择乘坐的空乘车辆，本申请可以结合不同的应用场景有不同的实现方式。

如，在一种可能的实现方式中，所有提供约车服务的车辆可以具有特定的区分信息。如，提供约车服务的车辆可以为无人驾驶车辆；或者是，提供约车服务的车辆上可以设置有特定的标识信息等。在该种情况下，如果在用户的约车订单的起始位置处存在提供约车服务的车辆且该车辆尚无人乘坐，则该用户便可以登车。

在又一种可能的实现方式中，可以预先设置提供约车服务的车辆等待乘客乘坐的等候位置点。在该种情况下，如果在用户的约车订单的起始位置处对应的等候位置点存在提供约车服务的空乘车辆，则用户便可以直接乘坐该空乘车辆。如，各个被调度到该起始位置的空乘车辆在抵达该起始位置对应的等候位置点处可以按照抵达该等候位置点的先后顺序依次排队等候乘客乘车，而乘客也可以选择排序靠前的空乘车辆乘坐，以减少车辆拥堵的可能性，并降低各个车辆的等待时长。

当然，以上是以几种情况为例对用户的约车订单响应成功后，该用户选择乘坐空乘车辆的过程进行说明，在实际应用中，还可以有其他可能，本申请对此不加限制。

与现有的约车服务相比，在本申请实施例中，只要用户的约车订单属于订单响应成功列表中的约车订单，则该用户便具有选择空乘车辆作为该用户的服务车辆的权限，而无需关心控制中心基于该用户的约车订单所调度的车辆是否已经到达该用户的约车订单中的起始位置。

S204，接收车载控制端发送的登车用户的同步信息，该同步信息至少包括该登车用户的约车订单。

其中，车载控制端为前面提到的设置于车辆上的车载控制终端。

其中，该同步信息表征存在用户登录该车载控制端所在的空乘车辆。

该车载控制端向控制中心发送该登车用户的同步信息的目的是为了使得验证该登车用户是否乘车的权限，即验证该登车用户的约车订单是否属于订单响应成功的用户。

其中，车载控制端获得登车用户的同步信息的方式可以有多种，如，车载控制端获得登车用户输入或者提供的约车订单的标识信息，并生成包含该约车订单的订单编号的同步信息。其中，该约车订单的标识信息可以为约车订单的订单编号，约车订单的二维码等编码信息等。

S205，如果该登车用户的约车订单属于该订单响应成功列表，向该车载控制端发送响应指示。

其中，该响应指示用于指示该车载控制端响应该登车用户的约车订单，以使得具有该车载控制端的空乘车辆作为服务车辆载该登车用户至该登车用户的目的位置。

相应的，该车载控制端在接收到该响应指示后，便可以将该约车订单作为该车载控制端需要服务的约车订单，并将具有该车载控制端所在的车辆的目的地址设置为该约车订单的目的位置。

与现有技术每个空乘车辆只能服务建立有关联的约车订单的用户相比，本申请实施例中，该车载控制端无需关心乘坐车辆的登车用户与该车载控制端的车辆之间是否建立有关联关系，只要将登车用户的同步信息发送给控制中心且控制中心返回响应指示，该车载控制端边可以响应该登车用户的约车订单为该登车用户服务。在该种情况下，只要在该车载控制端的车辆所在的等候乘车位置处有需要登车的用户，且该用户的约车订单属于响应成功的约车订单，则车载控制端的车辆便无需等待，有利于减少车载控制端的车辆等待乘客乘车的时长。

可见，在本申请实施例中，控制中心在基于用户客户端发送的约车订单，调度了空乘车辆之后，便可以提示用户客户端该约车订单响应成功，使得用户客户端的用户具有在该约车订单的起始位置乘坐空乘车辆的权限，有利于减少用户等待乘坐车辆的时长。而且，控制中心在获得车载控制端发送的登车用户的同步信息后，如果验证出该同步信息中的约车订单属于响应成功订单，则可以指示车载控制端将该车载控制端所在的车辆确定为该登车用户的服务车辆，只要在该车载控制端的车辆所在的等候乘车位置处有需要登车的用户，且该用户的约车订单属于响应成功的约车订单，则车载控制端的车辆便无需等待，有利于减少车载控制端的车辆等待乘客乘车的时长。

而且，由于本申请可以降低约车用户和空乘车辆的等待时长，有利于减少由于提供约车服务器的车辆大量拥堵的情况，从而进一步减少了用户乘车所需耗费的时长。

在图2实施例的基础上，下面结合控制中心、用户客户端与车载控制端之间交互流程对本申请的方案进行介绍，如图3所示，其示出了本申请一种信息处理方法又一个实施例的流程示意图，本实施例的方法可以包括：

S301，用户客户端向控制中心发送约车用户的约车订单，该约车订单至少指示有起始位置和目的位置。

S302，控制中心在基于该约车订单向该起始位置调度了空乘车辆，则将该约车订单加入约车成功列表，并向用户客户端发送反馈指示。

该反馈指示用于提示该约车用户的约车订单响应成功。

S303，用户客户端基于该反馈指示，输出约车订单响应成功的提示，以提示约车用户在该起始位置处选择空乘车辆乘坐。

如，用户客户端提示用户距离该起始位置处最近的等候位置点按顺序选择提供约车服务的空乘车辆乘坐。当然，对于具体提示方式可以与实际应用场景有关，对此不加限制。

S304，在车载控制端确认该车载控制端所在的车辆存在登车用户的情况下，获得登车用户的约车订单的信息，并向控制中心发送同步信息，该同步信息携带有该约车订单的信息。

其中，获得登车用户的约车订单的信息可以为扫描登车用户提供的二维码，或者是获得用户输入的约车订单的编码标识或具体详情等，具体可以参见前面实施例的相关介绍，在此不再赘述。

S305，控制中心如果基于该同步信息，确认该登车用户的约车订单属于该订单响应成功列表，向该车载控制端发送响应指示。

该响应指示用于指示该车载控制端响应该登车用户的约车订单。

可以理解的是，正常情况下，用户客户端的用户发起约车订单之后，只会在约车订单中的起始位置处乘坐空乘车辆。但是如果用户的乘车位置与该用户的约车订单中的起始位置不一致，则可能会导致该乘车位置处出现其他乘客无车可乘的情况，为了减少该种情况出现，本申请还可以在确认该登车用户的约车订单属于响应成功列表之后，检测该约车订单的起始位置与该车载控制端被调度到的位置(或者说该车载控制端对应的起始位置或者当前所处的位置)是否匹配，如果匹配，则向车载控制端发送响应指示。

其中，约车订单的起始位置与该车载控制端被调度到的位置匹配可以为这两个位置的距离小于预设距离，或者是，这两个位置处于预设范围内等。

相应的，如果该约车订单的起始位置与该车载控制端被调度到的位置不匹配，该控制中心可以向用户客户端发送乘车位置错误提示，以便该登车用户到正确位置乘车。另外，控制中心还可以向车载控制端发送错误提示，该错误提示用于提示该登车用户不具备承载该车载控制端所在的车辆。

可选的，在向车载控制端发送了响应指示之后，控制中心还可以将该约车订单标记为处于服务状态的约车订单。其中，处于服务状态的约车订单是指表征该约车订单被成功响应且已经确定了服务该约车订单的空乘车辆。其如，可以将约车订单从订单响应成功列表转移到处于服务状态的约车订单列表，以避免出现基于该约车订单重复乘车的情况。

S306，车载控制端基于该响应指示，将该登车用户的约车订单设置为需要服务的约车订单，以使得该车载控制端所在的车辆作为该登车用户的服务车辆，并通过该服务车辆载该登车用户至该登车用户的目的位置。

如，在控制中心控制各个可提供约车服务的车辆为无人驾驶车辆的情况下，车载控制端可以将该车载控制端所在的无人驾驶车辆的目的地设置为该登车用户的约车订单对应的目的位置，并控制无人驾驶车辆驶向该目的地。

又如，在控制中心控制各个可提供约车服务的车辆为有人驾驶车辆的情况下，则可以车载控制端将该登车用户的约车订单设置为需要服务的约车订单，并输出该约车订单，以便驾驶员获得该约车订单的信息。当然，该车载控制端还可以按照该约车订单的目的位置输出导航线路信息。

可以理解的是，在控制中心基于约车订单调度空乘车辆后，可能会建立了该空乘车辆的车载控制端与约车订单的关联关系。如，为了兼容目前常规的约车服务的方式，可能会在向车载控制端派发了针对约车订单的调度指示或者接收到车载控制端发送的接受该约车订单的指示后，建立该车载控制端与该约车订单的关联关系。

为了保证在该空乘车辆达到该约车订单的起始位置之后，处于该起始位置且具备在该起始位置乘车的乘客均可以乘坐该空乘车辆，本申请以上实施例中，在向车载控制端发送响应指示的同时或者之后，如果控制中心检测到该车载控制端关联有与该登车用户的约车订单具有相同起始位置的其他约车订单，可以控制取消该车载控制端关联的该其他约车订单。

在以上实施例是以控制中心根据车载控制端提供的登车用户的信息，指示车载控制端将该车载控制端的车辆作为登车用户的服务车辆为例说明，在实际应用中，还可以是由用户客户端向控制中心发送该用户客户端的约车用户所乘坐的车辆信息，以使得控制中心控制该约车用户所乘坐的车辆作为该约车用户的服务车辆。针对该种情况下，先从用户客户端侧进行介绍。

如，参见图4，其示出了本申请一种信息处理方法又一个实施例的流程示意图，本实施例的方法应用于用户客户端，包括：

S401，发送约车订单，该约车订单指示有：起始位置及目的位置。

其中，约车订单为用户客户端向控制中心请求提供车辆服务的订单。相应的，用户客户端会向控制中心发送约车订单。

如，用户客户端可以获得约车用户发起的约车请求，该约车请求携带有起始位置和目的位置，则该用户客户端可以生成约车订单并发送给控制中心。

可选的，该约车订单还可以携带该用户客户端的约车用户的用户标识。

可以理解的是，控制中心接收到该约车订单之后，控制中心对约车订单的处理可以参见前面实施例的相关介绍，在此不再赘述。

S402，获得提示信息，该提示信息用于提示该约车订单响应成功。

与前面实施例相似，在控制中心在基于约车订单向该约车订单的起始位置调度了空乘车辆之后，控制中心可以向用户客户端返回提示信息，该提示信息与前面的反馈指示的含义相同。

可选的，用户客户端在获得提示信息之后，还可以输出该提示信息，以提示用户当前已经可以在约车订单的起始位置处选择空乘车辆乘坐。

S403，获得并发送空乘车辆的车辆信息，以使得控制中心将该空乘车辆标定为服务该约车订单的服务车辆。

其中，用户客户端获得的空乘车辆的车辆信息是指用户客户端的约车用户选择乘坐的空乘车辆的车辆信息，如，在用户客户端的约车用户确认所选择的空乘车辆后或者登入空乘车辆后，触发用户客户端获取该空乘车辆的车辆信息。

其中，空乘车辆的车辆信息至少包括：空乘车辆的唯一标识，如空乘车辆的车牌号码；或者，空乘车辆的车辆编号等等。当然，该空乘车辆的车辆信息还可以有该空乘车辆的车型等等其他信息，在此不加限制。

在本申请中，用户客户端可以通过多种方式获得该空乘车辆的车辆信息。为了便于理解，以两种情况举例说明：

在一种可能的情况中，用户客户端可以获得用户输入的空乘车辆的车辆信息。

在又一种可能的情况中，用户客户端采集包含空乘车辆的车辆信息的图像，例如，扫描该空乘车辆上用于表征车辆信息的二维码信息，或者车牌号码的图像等等。

其中，向控制中心发送给空乘车辆的车辆信息的具体形式可以有多种，如，用户客户端可以向控制中心发送登车指示，该登车指示携带有该空乘车辆的车辆信息，且该登车指示用于请求控制中心将该空乘车辆标定为服务该约车订单的服务车辆。

可以理解的是，在用户客户端向控制中心发送了该空乘车辆的车辆信息之后，该控制中心在确认该用户客户端已发送的该约车订单属于成功响应的约车订单，则可以确认该用户客户端的约车用户具备乘坐空乘车辆的权限，在该种情况下，控制中心可以基于该用户客户端发送的空乘车辆的车辆信息，将该空乘车辆标定为服务该约车订单的服务车辆。

相应的，为了使得该空乘车辆可以为服务该约车订单，该控制中心还可以依据该空乘车辆的车辆信息，控制该空乘车辆的车载控制端将该约车订单设置为给空乘车辆所需服务的约车订单，以使得该车载控制端将该约车订单的目的位置设置为该空乘车辆的目的地址。

可选的，在控制中心将该空乘车辆设置为服务该约车订单的服务车辆之后，该控制中心还可以向该用户客户端发送车辆配置成功指示，以提示该约车用户可以将该空乘车辆作为该约车订单的服务车辆。

在本申请实施例中，用户客户端向控制中心发送了约车订单之后，如果获得了提示该约车订单成功响应的提示信息之后，该用户客户端的约车用户便可以在约车订单的起始位置处选择没有乘客乘坐的空乘车辆，在该基础上，用户客户端将空乘车辆的信息发送给控制中心之后，使得控制中心便会将该空乘车辆设置为服务该约车订单的服务车辆，从而可以实现在约车用户的约车订单被控制中心成功响应之后便可以选择空乘车辆乘坐，而无需关心针对该约车订单调度的车辆是否已经到达，从而有利于减少用户等待乘车的等待时长。

为了便于理解本申请的好处，那么结合现有的约车服务的乘车方式与本申请约车用户的约车方式进行对比说明：

假设用户A和用户B都需要在大厦M的门口乘车。假设用户A在8:02发起了起始位置为大厦M的约车订单A，而用户B在8:04分也发起了起始位置为大厦M的约车订单B。由于用户B赶时间，用户B在8：05已经到达大厦M的门口，以准备乘坐服务车辆；而用户A则可会在8：08分才到达大厦M的门口。

那么假设针对该约车订单A向该大厦M调度的空乘车辆1在8：05到达大厦M；而针对约车订单B向该大厦M调度的空乘车辆2会在8：07分到达大厦M。

在以上假设的情况下，如果按照现有的约车方式，虽然用户B在8点05分已经到达大厦M的门口，且在大厦M的门口停靠有一辆空乘车辆1，但是由于该空乘车辆不是针对用户B调度的空乘车辆，则用户B没有乘坐该空乘车辆的权利，因此，用户B需要等待两分钟，直至针对用户B的约车订单B所调度的空乘车辆2到达该大厦M，在该种情况下，需要用户耗费2分钟的等待时长。与此同时，由于空乘车辆1到达大厦M时，该空乘车辆1对应的约车用户A尚未到达大厦M的门口，因此，该空乘车辆1也需要从8：05等待到8:08分才可以完成载客，从而使得空乘车辆1等待载客的时长为3分钟。

而采用本申请的方案，由于用户B发起了约车订单B之后，控制中心基于该约车订单B向大厦M调度了空乘车辆2之后，控制中心会指示用户B约车订单B响应成功，在该种情况下，用户B无需关心针对该约车订单B调度的空乘车辆为哪一辆以及该空乘车辆是否已达到该大厦M，只要在用户B到达该大厦M的门口后，发现存在等待乘客的空乘车辆，则用户便可以乘坐该空乘车辆。因此，用户B可以在8点05分通过用户客户端将停靠在大厦M的空乘车辆1的车辆信息发送给控制中心，在控制中心将该空乘车辆设置服务约车订单B的服务车辆之后，用户B便可以乘坐该空乘车辆1，以赶往目的地，从而使得用户B无需等待车辆到达便可以及时乘车。同时，该空乘车辆1也可以在到达大厦M之后便可以实现载客，也无需等待。

相应的，由于空乘车辆2会在8点07分到达大厦M，因此，用户A在8点08分到达该大厦M的门口时，也可乘坐空乘车辆2，而不存在无车可乘的情况，也不需要额外的候车时间。

在图4实施例的基础上，为了便于理解，下面从控制中心、车载控制端和用户客户端的交互的角度进行介绍，如参见图5，其示出了本申请一种信息处理方法又一个实施例的流程示意图，本实施例的方法可以包括：

S501，用户客户端向控制中心发送约车用户的约车订单，该约车订单至少指示有起始位置和目的位置。

S502，控制中心在基于该约车订单向该起始位置调度了空乘车辆，将该约车订单加入约车成功列表，并向用户客户端发送提示信息。

该提示指示用于提示该约车用户的约车订单响应成功。

S503，用户客户端基于该提示信息，输出约车订单响应成功的提示，以提示约车用户在该起始位置处选择空乘车辆乘坐。

可以理解的是，该步骤S503为可选步骤，在实际应用中，用户客户端在获得控制中心的提示信息之后，也可以直接执行步骤S504，如输出提示用户输入或者扫描所需登载的空乘车辆的车辆信息的提示，以获得空乘车辆的车辆信息。

S504，用户客户端获得空乘车辆的车辆信息。

该步骤S504可以参见前面图4实施例的相关介绍，在此不再赘述。

S505，用户客户端向控制中心发送登车指示。

其中，该登车指示携带有空乘车辆的车辆信息，且该登车指示用于请求控制中心将该空乘车辆标定为服务该约车订单的服务车辆。

可选的，为了便于后续控制中心验证该用户客户端发起的约车订单，该登车指示还可以携带有该约车订单的标识信息，或者该用户客户端的标识信息等。

需要说明的是，该步骤S505为用户客户端向控制中心发送空乘车辆的车辆信息的一种实现方式，对于其他实现向控制中心发送空乘车辆的车辆信息的方式也同样适用于本实施例。

S506，控制中心在确认该用户客户端发送的约车订单属于该订单响应成功列表，依据该空乘车辆的车辆信息，向该空乘车辆的车载控制端发送服务指示。

如，控制中心可以确认用户客户端发送的约车订单，然后，检测该约车订单是否属于订单响应成功列表中的约车单元。其中，确认用户客户端发送的约车订单可以是控制中心获得该用户客户端关联的约车订单的信息，或者是，基于登车指示携带有约车订单的标识，确定该用户客户端发送的约车订单等。

其中，该服务指示用于指示车载控制端将该车载控制端所在的空乘车辆作为服务该约车订单的服务车辆。

S507，车载控制端响应于该服务指示，依据该约车订单设置该车载控制端所在的空乘车辆的目的位置。

车载控制端响应于该服务指示，则可以基于该约车订单为登车用户提供服务，以实现通过车载控制端所在的车辆载该登车用户驶向该目的位置。如，以无人驾驶车辆为例，车载控制端可以将无人驾驶车辆的目的地址设置为该登车用户的约车订单中的目的位置，并控制该无人驾驶车辆向该目的位置行驶。

可选的，控制中心在向车载控制端发送了服务指示之后，还可以向用户客户端发送服务配置成功指示，该服务配置成功指示用于指示将该登车用户乘坐的该空乘车辆标定为服务该约车订单的服务车辆，以使得登车用户可以获知该空乘车辆可以作为该登车用户的服务车辆的信息。

进一步的，在车载控制端响应了该服务指示之后，还可以向控制中心返回一个服务响应指示，相应的，该控制中心还可以是在接收到该服务响应指示之后，向用户客户端发送该服务配置成功指示。

需要说明的是，该步骤S506和S507仅仅是控制中心将登车用户乘坐的空乘车辆标定为服务该登车用户的约车订单的服务车辆的一种实现方式，在实际应用中，还可以有其他实现可能，对此不加限制。

可以理解的是，本申请还可以是由车载控制端基于登车用户的身份信息，确认是否将该车载控制端所在的车辆作为该登车用户的服务车辆，下面针对该种情况，先对车载控制端侧进行介绍。如，参见图6，其示出了本申请一种信息处理方法又一个实施例的流程示意图，本实施例应用于车载控制端，本实施例的方法可以包括：

S601，获得登车用户的身份信息。

如，可以获得登车用户输入的身份信息，如登车用户的用户姓名、登车用户在控制中心注册的用户账号等等。

又如，还可以采集登车用户的生物特征信息，将采集到的生物特征信息作为登车用户的身份信息。如，采集登车用户的人脸图像、登车用户的指纹信息或者虹膜信息等等。

又如，还可以是采集登车用户提供的表征该登车用户的身份信息的二维码等编码。

当然，还可以有其他获得登车用户的身份信息的方式，对此不加限制。

需要说明的是，获得登车用户的身份信息可以是在登车用户乘坐该车载控制端所在的车辆之后执行，如，在登车用户打开车门进入车辆车厢之后；也可以是在请求登车的登车用户发起登车请求时执行，此时该登车用户尚未进入车载控制端所在的车辆内。

S602，向控制中心发送该登车用户的身份信息，以使得控制中心基于该登车用户的身份信息，检测该登车用户是否属于约车订单响应成功的用户。

如，车载控制端直接向控制中心发送该登车用户的身份信息，以触发控制中心对该登车用户的身份信息进行验证。

又如，车载控制端可以向控制中心发送用户身份验证请求，该身份验证请求携带该登车用户的身份信息，且该用户身份验证请求用于请求控制中心验证该登车用户是否属于约车订单响应成功的用户。

其中，控制中心获得该登车用户的身份信息之后，可以依据该登车用户的身份信息，确定该登车用户的约车订单，即登车用户通过用户客户端向控制中心发送的约车订单。如，根据登车用户的用户账号，检测该登车用户发起的约车订单。

可以理解的是，在控制中心确认了登车用户的约车订单之后，检测该约车订单是否属于约车订单响应成功的过程与前面实施例中相关过程相同，在此不再赘述。

S603，如该控制中心确认该登车用户属于约车订单响应成功的用户，获得该登车用户的目的位置。

可以理解的是，在控制中心确认登车用户属于约车订单响应成功的用户，则车载控制终端确认该登车用户是具备登车权限的用户，从而可以针对该登车用户提供登车服务，因此，需要获得登车用户的的目的位置。

其中，获得登车用户的目的位置的方式可以有多种。如：

在一种可能的情况下，获得登车用户的约车订单，由于该约车订单中指示有目的位置，则车载控制端将约车订单中指示的目的位置确定为该登车用户的目的位置。在该种情况下，登车用户的约车订单可以是控制中心发送给该车载控制端的，如，在控制中心确认登车用户属于约车订单响应成功的用户之后，向该车载控制端返回该登车用户的约车订单。该登车用户的约车订单还可以从车载控制端获得，如采集车载控制端显示出的该登车用户的约车订单的二维码等标识信息，并基于约车订单的二维码等标识信息从控制中心请求该约车订单。

在又一种可能的情况中，车载控制端可以获得输入的登车用户的目的位置。其中，登车用户输入的目的位置可以为驾驶员或者登车用户输入的该登车用户发起的约车订单中的目的位置；也可以是驾驶员或者登车用户输入的其他目的位置，如，用户发现约车订单中的目的位置不是自己实际想去的位置或者用户希望改变路线等，则可以自己或者通过驾驶员重新输入一个新的目的位置。

当然，车载控制端也可以获得控制中心返回的该登车用户的目的位置，该目的位置可以是登车用户的约车订单中的目的位置，也可以是登车用户通过用户客户端向控制中心反馈的更改后的目的位置等。以上以两种情况为例说明，对于其他情况也同样适用。

需要说明的是，在实际应用中，以上几种获得登车用户的目的位置的方式也可以同时执行，比如，在无人驾驶车辆场景中，车载控制端在获得登车用户的约车订单的同时，获得用户输入的目的位置，如果约车订单中的目的位置与用户输入的目的位置不一致，则可以输出是否修改目的位置的提示，如果登车用户确认修改目的位置，则以修改后的目的位置作为登车用户的目的位置。在该种情况下，车载控制端还可以将登车用户修改后的目的位置发送给控制中心。

可以理解的是，如果在该步骤S603之前登车用户尚未乘坐车辆，如，车载控制端所在的车辆的车门仍处于锁定状态，那么在确认所述控制中心确认所述登车用户属于约车订单响应成功的用户的情况下，还可以控制车载控制端所在的车辆的车门解锁，以使得登车用户可以乘坐该车辆。

例如，以无人驾驶车辆的场景为例，为了避免不具备该无人驾驶车辆的登车权限的用户乘坐车辆，而影响到其他具有权限的用户，无人驾驶车辆的车载控制端需要在确认该登车用户属于约车订单响应成功的用户的情况下，才会打开该无人驾驶车辆的车门，使得用户可以乘坐车辆。

S604，将该目的位置设置为车载控制端所在的车辆的目的位置，以将该车辆作为该登车用户的服务车辆并载该登车用户至该目的位置。

如，对于有人驾驶车辆的场景中，车载控制端只需要设置该车辆的目的位置，并输出提示导航或者目的位置的提示即可，以使得驾驶员按照该目的位置驾驶车辆向该目的位置行驶。

又如，在无人驾驶车辆的场景中，车载控制端将获得的的目的位置设置为车辆的目的位置，并控制车辆向目的位置行驶。

可见，在本实施例中，车载控制端在获得登车用户的身份信息之后，如果基于该登车用户的身份信息，通过控制中心确认该登车用户属于约车订单成功响应的用户，则会设置车载控制端所在的车辆的目的位置与该登车用户的目的位置，使得该车辆可以载登车用户至该目的位置，从而使得只要登车用户发起的约车订单被成功响应，车载控制端的车辆便可以作为该登车用户的服务车辆为用户服务，而不受限于用户的发起约车订单的时间，从而有利于先到达该车辆停靠位置的用户优先乘坐车辆，有利于减少车辆等候乘客的时间，以及乘客等待乘车的时间。

为了便于理解图6所示的实施例，下面以一种情况为例从控制中心、用户客户端和车载客户端之间的交互角度进行介绍。如，参见图7，其示出了本申请一种信息处理方法又一个实施例的流程示意图，本实施例的方法可以包括：

S701，用户客户端向控制中心发送约车用户的约车订单，该约车订单至少指示有起始位置和目的位置。

S702，控制中心在基于该约车订单向该起始位置调度了空乘车辆，将该约车订单加入约车成功列表，并向用户客户端发送提示信息。

该提示指示用于提示该约车用户的约车订单响应成功。

S703，用户客户端基于该提示信息，输出约车订单响应成功的提示，以提示约车用户在该起始位置处选择空乘车辆乘坐。

以上步骤S701到S703可以参见前面实施例的相关介绍，在此不再赘述。

S704，车载控制端获得登车用户的身份信息。

如，在用户根据用户客户端输出的订单响应成功的提示之后，用户可以选择所需乘坐的空乘车辆，在乘坐空乘车辆后，可以通过空乘车辆上的身份信息采集区输入身份信息，如，手动输入信息，或者使得身份信息采集区可以采集指纹或者人脸图像等。

又如，用户选择了所需乘坐的空乘车辆之后，如果空乘车辆的车门处于锁定状态，那么为了解锁车门并乘坐该空乘车辆，则可以在空乘车辆的信息采集区输入指纹、人脸图像或者账号等等。

相应的，车载控制端可以检测到身份信息采集区采集到身份信息时，获得登车用户的身份信息。

S705，车载控制端向控制中心发送该登车用户的身份信息。

S706，控制中心基于该登车用户的身份信息，检测该登车用户是否属于约车订单响应成功的用户。

该步骤S705和S706可以参见图6中的相关介绍，在此不再赘述。

S707，在控制中心确认该登车用户属于约车订单响应成功的用户的情况下，向车载控制端返回车辆标定指示。

其中，该车辆标定指示用于指示该登车用户属于约车订单响应成功的用户，且指示该车载控制端将该车载控制端所在的车辆作为该登车用户的服务车辆。

可选的，控制中心在向车载控制端发送车辆标定指示之后，还可以存储该登车用户与该车载控制端所在的车辆之间的绑定关系，以避免其他乘客重复登录该车辆。

S708，车载控制端响应于车辆标定指示，将该目的位置设置为车载控制端所在的车辆的目的位置，以通过该车辆载登车用户至该目的位置。

如，在车载控制端所在的车辆的车门处于锁定状态下，还可以先解锁车门，然后设置该车辆的目的位置，以使得可以通过车辆载乘客到目的位置。

具体的该步骤可以参见前面实施例的相关介绍，在此不再赘述。

又一方面，本申请还提供了一种服务器，该服务器可以为控制中心的服务器。如图8所示，其示出了本申请的服务器的一种组成架构示意图。

由图8可知，该服务器至少包括通信接口801和处理器802。

其中，通信接口801，用于接收用户客户端发送的约车订单，所述约车订单指示有：起始位置和目的位置；

该处理器802，用于基于所述约车订单，如果向所述起始位置调度了空乘车辆，将所述约车订单加入订单响应成功列表；并控制所述通信接口向所述用户客户端发送反馈指示，以使得所述用户客户端提示约车用户的约车订单响应成功；

该通信接口801，还用于接收车载控制端发送的登车用户的同步信息，所述同步信息至少包括所述登车用户的约车订单；

该处理器802，还用于如果所述登车用户的约车订单属于所述订单响应成功列表，控制所述通信接口向所述车载控制端发送响应指示，所述响应指示用于指示所述车载控制端响应所述登车用户的约车订单，以使得具有所述车载控制端的空乘车辆作为服务车辆载所述登车用户至所述登车用户的目的位置。

可选的，该服务器还可以包括存储器803，该存储器用于存储处理器执行操作所需的程序。

当然，图8仅仅是服务器的一种简单构成示意图，在实际应用中，该服务器还可以包括通信总线、输入单元和显示单元等等，在此不加限制。

在一种可能的实现方式中，该处理器在基于所述约车订单，如果向所述起始位置调度了空乘车辆，将所述约车订单加入订单响应成功列表时，具体为：

基于所述约车订单，如果向空乘车辆的车载控制端派发了调度指示，将所述约车订单加入订单响应成功列表，所述调度指示至少用于指示所述空乘车辆以所述起始位置作为待载乘客的乘车位置；

或者，

在发布了所述约车订单且接收到空乘车辆上的车载控制端针对所述约车订单的接单指示，将所述约车订单加入订单响应成功列表。

在又一种可能的实现方式中，该处理器，还用于在通信接口向所述车载控制端发送响应指示的同时或者之后，如果所述车载控制端关联有与所述登车用户的约车订单具有相同起始位置的其他约车订单，控制取消所述车载控制端关联的所述其他约车订单。

又一方面，本申请还提供了一种用户客户端，该用户客户端至少包括通信接口和处理器，其中，通信接口和处理器之间的连接关系可以参见图8所示。

在该用户客户端中，该通信接口，用于发送约车订单，所述约车订单指示有：起始位置及目的位置；获得提示信息，所述提示信息用于提示所述约车订单响应成功；

该处理器，用于获得空乘车辆的车辆信息，并控制所述通信接口向控制中心发送所述空乘车辆的车辆信息，以使得控制中心将所述空乘车辆标定为服务所述约车订单的服务车辆。

可选的，该处理器具体用于，获得空乘车辆的车辆信息；控制通信接口向控制中心发送登车指示，所述登车指示携带有所述空乘车辆的车辆信息，且所述登车指示用于请求控制中心将所述空乘车辆标定为服务所述约车订单的服务车辆。

又一方面，本申请还提供了一种车载控制终端。如图9为本申请的车载控制终端的一种组成架构示意图，该车载控制终端至少包括采集模块901、通信接口902和处理器903。

其中，采集模块和通信接口均与处理器存在通信连接。

其中，采集模块901，用于获得登车用户的身份信息。如，采集模块可以为指纹采集模块、图像采集模块或者信息输入模块等。

通信接口902，用于向控制中心发送所述登车用户的身份信息，以使得控制中心基于所述登车用户的身份信息，检测所述登车用户是否属于约车订单响应成功的用户；

处理器903，用于如所述控制中心确认所述登车用户属于约车订单响应成功的用户，获得所述登车用户的目的位置；将所述目的位置设置为车载控制端所在的车辆的目的位置，以将所述车辆作为所述登车用户的服务车辆并载所述登车用户至所述目的位置。

当然，车载控制终端同样可以包括显示单元和存储器等其他部件，对此不加限制。

可选的，处理器在所述获得所述登车用户的目的位置时，具体为，

获得所述登车用户的约车订单，确定所述约车订单中指示的目的位置；

或者，获得所述登车用户输入的目的位置。

可选的，该处理器，还用于如所述控制中心确认所述登车用户属于约车订单响应成功的用户，控制车载控制端所在的车辆的车门解锁，以使得所述登车用户乘坐所述车辆。

可选的，该通信接口，还用于获得所述控制中心返回的车辆标定指示，所述车辆标定指示用于指示所述登车用户属于约车订单响应成功的用户，且指示所述车载控制端将所述车载控制端所在的车辆作为所述登车用户的服务车辆；

该处理器在将所述目的位置设置为车载控制端所在的车辆的目的位置时，具体用于，响应于所述车辆标定指示，将所述目的位置设置为车载控制端所在的车辆的目的位置。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种信息处理方法，包括：

接收用户客户端发送的约车订单，所述约车订单指示有：起始位置和目的位置；

基于所述约车订单，如果向所述起始位置调度了空乘车辆，将所述约车订单加入订单响应成功列表；

向所述用户客户端发送反馈指示，以使得所述用户客户端提示约车用户的约车订单响应成功；

接收车载控制端发送的登车用户的同步信息，所述同步信息至少包括所述登车用户的约车订单；

如果所述登车用户的约车订单属于所述订单响应成功列表，向所述车载控制端发送响应指示，所述响应指示用于指示所述车载控制端响应所述登车用户的约车订单，以使得具有所述车载控制端的空乘车辆作为服务车辆载所述登车用户至所述登车用户的目的位置。

2.根据权利要求1所述的信息处理方法，所述基于所述约车订单，如果向所述起始位置调度了空乘车辆，将所述约车订单加入订单响应成功列表，包括：

基于所述约车订单，如果向空乘车辆的车载控制端派发了调度指示，将所述约车订单加入订单响应成功列表，所述调度指示至少用于指示所述空乘车辆以所述起始位置作为待载乘客的乘车位置；

或者，

在发布了所述约车订单且接收到空乘车辆上的车载控制端针对所述约车订单的接单指示，将所述约车订单加入订单响应成功列表。

3.根据权利要求1或2所述的信息处理方法，在所述向所述车载控制端发送响应指示的同时或者之后，还包括：

如果所述车载控制端关联有与所述登车用户的约车订单具有相同起始位置的其他约车订单，控制取消所述车载控制端关联的所述其他约车订单。

4.一种信息处理方法，应用于用户客户端，所述信息处理方法包括：

发送约车订单，所述约车订单指示有：起始位置及目的位置；

获得提示信息，所述提示信息用于提示所述约车订单响应成功；

获得空乘车辆的车辆信息；

向控制中心发送所述空乘车辆的车辆信息，以使得控制中心将所述空乘车辆标定为服务所述约车订单的服务车辆。

5.根据权利要求4所述的信息处理方法，所述向控制中心发送所述空乘车辆的车辆信息，包括：

向控制中心发送登车指示，所述登车指示携带有所述空乘车辆的车辆信息，且所述登车指示用于请求控制中心将所述空乘车辆标定为服务所述约车订单的服务车辆。

6.一种信息处理方法，包括：

获得登车用户的身份信息；

向控制中心发送所述登车用户的身份信息，以使得控制中心基于所述登车用户的身份信息，检测所述登车用户是否属于约车订单响应成功的用户；

如所述控制中心确认所述登车用户属于约车订单响应成功的用户，获得所述登车用户的目的位置；

将所述目的位置设置为车载控制端所在的车辆的目的位置，以将所述车辆作为所述登车用户的服务车辆并载所述登车用户至所述目的位置。

7.根据权利要求6所述的信息处理方法，所述获得所述登车用户的目的位置，包括：

获得所述登车用户的约车订单，确定所述约车订单中指示的目的位置；

或者，

获得所述登车用户输入的目的位置。

8.根据权利要求6所述的信息处理方法，还包括：

如所述控制中心确认所述登车用户属于约车订单响应成功的用户，控制车载控制端所在的车辆的车门解锁，以使得所述登车用户乘坐所述车辆。

9.根据权利要求6所述的信息处理方法，还包括：

获得所述控制中心返回的车辆标定指示，所述车辆标定指示用于指示所述登车用户属于约车订单响应成功的用户，且指示所述车载控制端将所述车载控制端所在的车辆作为所述登车用户的服务车辆；

所述将所述目的位置设置为车载控制端所在的车辆的目的位置，包括：

响应于所述车辆标定指示，将所述目的位置设置为车载控制端所在的车辆的目的位置。

10.一种服务器，包括：

通信接口和处理器；

其中，所述通信接口，用于接收用户客户端发送的约车订单，所述约车订单指示有：起始位置和目的位置；

所述处理器，用于基于所述约车订单，如果向所述起始位置调度了空乘车辆，将所述约车订单加入订单响应成功列表；并控制所述通信接口向所述用户客户端发送反馈指示，以使得所述用户客户端提示约车用户的约车订单响应成功；

所述通信接口，还用于接收车载控制端发送的登车用户的同步信息，所述同步信息至少包括所述登车用户的约车订单；

所述处理器，还用于如果所述登车用户的约车订单属于所述订单响应成功列表，控制所述通信接口向所述车载控制端发送响应指示，所述响应指示用于指示所述车载控制端响应所述登车用户的约车订单，以使得具有所述车载控制端的空乘车辆作为服务车辆载所述登车用户至所述登车用户的目的位置。