业务处理方法及装置与流程

本发明涉及互联网技术，尤其涉及一种业务处理方法及装置。

背景技术：

随着通信技术和计算机技术的不断发展，越来越多的用户选择使用终端设备上的出行平台来呼叫车辆，以方便用户出行。

目前，用户在进行车辆预约时，通常在打开安装于终端设备上的出行平台后，在出行平台的界面上输入出行信息，如输入出发地、目的地以及出发时间等。在服务器为用户派单成功后，出行平台的操作界面上将显示有用户预约到的车辆的相关信息，以便用户进行出行。

然而，在现有技术中，当用户有一些特殊的偏好时，服务器在为用户派单时，将很难派到符合用户特殊偏好的司机，来为用户进行服务，这样导致用户的体验不好。

技术实现要素：

为解决现有技术中存在的问题，本发明提供一种业务处理方法及装置，以提高用户体验。

第一方面，本发明实施例提供一种业务处理方法，所述方法应用于出行业务的处理，所述方法，包括：

接收第一用户在所述出行业务的操作界面上触发的订单请求，所述订单请求中包括至少一项第一用户的偏好信息；

根据所述订单请求，在所述操作界面上显示车辆信息，所述车辆信息为第二用户对应的车辆的信息，所述第二用户满足所述第一用户的预设数量的偏好信息。

在一种可能的实现方式中，所述接收第一用户在所述出行业务的操作界面上触发的订单请求之前，所述方法还包括：

接收所述第一用户在所述出行业务的设置界面上输入的所述偏好信息。

在一种可能的实现方式中，所述接收所述第一用户在所述出行业务的设置界面上输入的所述偏好信息，包括：

在所述设置界面上显示多个预设的偏好信息，接收所述第一用户在所述设置界面上选择的偏好信息。

在一种可能的实现方式中，所述接收第一用户在所述出行业务的操作界面上触发的订单请求之后，所述方法还包括：

向服务器发送所述订单请求；

接收所述服务器发送的所述车辆信息。

在一种可能的实现方式中，所述偏好信息包括如下信息中的至少一项：用户的行为习惯信息或用户需要的服务信息。

第二方面，本发明实施例提供一种业务处理方法，所述方法应用于出行业务的处理，所述方法，包括：

在所述出行业务的派单界面上显示订单信息；

接收第二用户在所述派单界面上触发的确认操作请求；

根据所述确认操作请求，在所述出行业务的出行显示界面上显示弹窗，所述弹窗中显示有至少一项第一用户的偏好信息。

在一种可能的实现方式中，所述根据所述确认操作请求，在所述出行业务的出行显示界面上显示弹窗之后，所述方法还包括：

接收所述第二用户对所述弹窗的触控操作；

根据所述触控操作，在所述出行显示界面上显示所述偏好信息的隐藏标签。

在一种可能的实现方式中，所述在所述出行显示界面上显示所述偏好信息的隐藏标签之后，所述方法还包括：

接收所述第二用户对所述隐藏标签的触控操作；

根据所述触控操作，在所述出行显示界面上显示所述偏好信息。

在一种可能的实现方式中，所述在所述出行业务的派单界面上显示订单信息之前，所述方法还包括：

接收服务器发送的派单请求，所述派单请求中包括所述订单信息和所述偏好信息。

在一种可能的实现方式中，所述接收第二用户在所述派单界面上发送的确认操作请求之后，所述方法还包括：

根据所述确认操作请求，向服务器发送确认响应，所述确认响应用于指示所述第二用户接单。

在一种可能的实现方式中，所述偏好信息包括如下信息中的至少一项：用户的行为习惯信息或用户需要的服务信息。

第三方面，本发明实施例提供一种业务处理方法，所述方法应用于出行业务处理，所述方法，包括：

接收第一终端发送的订单请求，所述订单请求中包括至少一项第一用户的偏好信息；

根据所述偏好信息，匹配满足预设数量的所述偏好信息的第二用户；

向所述第二用户对应的第二终端发送派单请求，所述派单请求中包括订单信息和所述偏好信息。

在一种可能的实现方式中，所述方法还包括：

接收所述第一终端发送的评价信息，所述评价信息为第一用户对所述第二用户的服务的评价信息；

根据所述评价信息，创建表示所述第一用户偏好的至少一项预设的偏好信息；

将所述预设的偏好信息发送给所述第一终端。

在一种可能的实现方式中，所述根据所述偏好信息，匹配满足预设数量的所述偏好信息的第二用户，包括：

根据所述偏好信息和预先存储的多个第三用户的特征信息，确定所述第二用户。

在一种可能的实现方式中，所述向所述第二用户对应的第二终端发送派单请求之后，所述方法还包括：

接收所述第二终端发送的确认响应，所述确认响应用于指示所述第二用户接单；

根据所述确认响应，向所述第一终端发送车辆信息。

在一种可能的实现方式中，所述偏好信息包括如下信息中的至少一项：用户的行为习惯信息或用户需要的服务信息。

第四方面，本发明实施例提供一种业务处理装置，包括：

接收模块，用于接收第一用户在所述出行业务的操作界面上触发的订单请求，所述订单请求中包括至少一项第一用户的偏好信息；

显示模块，用于根据所述订单请求，在所述操作界面上显示车辆信息，所述车辆信息为第二用户对应的车辆的信息，所述第二用户满足所述第一用户的预设数量的偏好信息。

在一种可能的实现方式中，所述接收模块，还用于接收所述第一用户在所述出行业务的设置界面上输入的所述偏好信息。

在一种可能的实现方式中，在所述设置界面上显示多个预设的偏好信息，所述接收模块，还用于接收所述第一用户在所述设置界面上选择的偏好信息。

在一种可能的实现方式中，所述装置还包括发送模块，其中，

所述发送模块，用于向服务器发送所述订单请求；

所述接收模块，还用于接收所述服务器发送的所述车辆信息。

在一种可能的实现方式中，所述偏好信息包括如下信息中的至少一项：用户的行为习惯信息或用户需要的服务信息。

第五方面，本发明实施例提供一种业务处理装置，包括：

显示模块，用于在所述出行业务的派单界面上显示订单信息；

接收模块，用于接收第二用户在所述派单界面上触发的确认操作请求；

所述显示模块，还用于根据所述确认操作请求，在所述出行业务的出行显示界面上显示弹窗，所述弹窗中显示有至少一项第一用户的偏好信息。

在一种可能的实现方式中，所述接收模块，还用于接收所述第二用户对所述弹窗的触控操作；

所述显示模块，还用于根据所述触控操作，在所述出行显示界面上显示所述偏好信息的隐藏标签。

在一种可能的实现方式中，所述接收模块，还用于接收所述第二用户对所述隐藏标签的触控操作；

所述显示模块，还用于根据所述触控操作，在所述出行显示界面上显示所述偏好信息。

在一种可能的实现方式中，所述接收模块，还用于接收服务器发送的派单请求，所述派单请求中包括所述订单信息和所述偏好信息。

在一种可能的实现方式中，所述装置还包括：发送模块；其中，

所述发送模块，用于根据所述确认操作请求，向服务器发送确认响应，所述确认响应用于指示所述第二用户接单。

在一种可能的实现方式中，所述偏好信息包括如下信息中的至少一项：用户的行为习惯信息或用户需要的服务信息。

第六方面，本发明实施例提供一种业务处理装置，包括：

接收模块，用于接收第一终端发送的订单请求，所述订单请求中包括至少一项第一用户的偏好信息；

处理模块，用于根据所述偏好信息，匹配满足预设数量的所述偏好信息的第二用户；

发送模块，用于向所述第二用户对应的第二终端发送派单请求，所述派单请求中包括订单信息和所述偏好信息。

在一种可能的实现方式中，所述接收模块，还用于接收所述第一终端发送的评价信息，所述评价信息为第一用户对所述第二用户的服务的评价信息；

所述处理模块，还用于根据所述评价信息，创建表示所述第一用户偏好的至少一项预设的偏好信息；

所述发送模块，还用于将所述预设的偏好信息发送给所述第一终端。

在一种可能的实现方式中，所述处理模块，具体用于：

根据所述偏好信息和预先存储的多个第三用户的特征信息，确定所述第二用户。

在一种可能的实现方式中，所述接收模块，还用于接收所述第二终端发送的确认响应，所述确认响应用于指示所述第二用户接单；

所述发送模块，还用于根据所述确认响应，向所述第一终端发送车辆信息。

在一种可能的实现方式中，所述偏好信息包括如下信息中的至少一项：用户的行为习惯信息或用户需要的服务信息。

本发明实施例提供的业务处理方法及装置，应用于出行业务的处理，第一终端接收第一用户在出行业务的操作界面上触发的订单请求，并根据订单请求，在操作界面上显示车辆信息，该车辆信息为第二用户对应的车辆的信息，该第二用户满足第一用户的预设数量的偏好信息，订单请求中包括至少一项第一用户的偏好信息。由于第一终端接收到的第一用户触发的订单请求中包括有至少一项第一用户的偏好信息，则服务器在进行派单时，将会匹配能够满足第一用户的预设数量的偏好信息的第二用户，在第一终端中，会在操作界面上显示第二用户对应的车辆的信息，这样即可避免现有技术中乘客只能在预约到车辆之后，通过交流告知司机其自身的偏好信息的现象，由此可以提高用户的体验。

附图说明

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

图1为本发明实施例提供的业务处理方法的应用场景示意图；

图2为本发明实施例提供的业务处理方法实施例一的流程示意图；

图3a为出行业务的操作界面的一示意图；

图3b为出行业务的操作界面的另一示意图；

图4a为设置界面的一示意图；

图4b为设置界面的另一示意图；

图5为本发明实施例提供的业务处理方法实施例二的流程示意图；

图6为派单界面的示意图；

图7为出行显示界面的一示意图；

图8为出行显示界面的另一示意图；

图9为出行显示界面的又一示意图；

图10为本发明实施例提供的业务处理方法实施例三的流程示意图；

图11为本发明实施例提供的业务处理方法实施例三的流程示意图；

图12为本发明实施例提供的业务处理方法实施例四的信令流程图；

图13为本申请业务处理装置实施例一的结构示意图；

图14为本申请业务处理装置实施例二的结构示意图；

图15为本申请业务处理装置实施例三的结构示意图；

图16为本申请业务处理装置实施例四的结构示意图；

图17为本申请业务处理装置实施例五的结构示意图。

具体实施方式

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

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

本发明实施例提供的业务处理方法，应用于出行业务的处理，具体的，可以应用于用户通过出行平台进行车辆预约的系统中，其中，本发明实施例中的出行平台指的是可以实现预约网约车功能的应用程序(application，app)。图1为本发明实施例提供的业务处理方法的应用场景示意图，如图1所示，该系统中包括服务器11、第一终端12和第二终端13，本发明实施例中以第一终端12为第一用户对应的终端，即乘客端的终端，第二终端13为第二用户对应的终端，即司机端的终端为例进行说明。当第一用户通过出行平台进行车辆预约时，可能会有一些偏好信息，如喜欢全程静音，喜欢听音乐，或者身体状况不好需要特殊的帮助等等，此时，第一用户可以通过第一终端12设置自己的偏好信息，在发单时，第一终端12将接收第一用户在出行业务的操作界面上触发的订单请求，该订单请求中包括至少一项第一用户的偏好信息，第一终端12将订单请求发送给服务器后，服务器将从本地存储的各个司机的特征信息中，匹配符合第一用户的偏好信息的司机，即匹配符合的第二用户，匹配到之后，将向该第二用户对应的第二终端13发送派单请求，第二终端13根据接收到的派单请求，在出行业务的派单界面上显示订单信息，其中，订单信息中包括出发地、目的地以及与乘客之间的距离等，第二用户根据自己的情况选择接单还是拒单，若第二用户选择接单，将会在派单界面上触发确认操作请求，此时，第二终端的出行业务的出行显示界面上会显示弹窗，该弹窗中显示有至少一项第一用户的偏好信息，以使第二用户根据显示的偏好信息对第一用户进行服务。另外，当服务器为第一用户派单成功之后，会向第一终端发送预约成功的车辆的车辆信息，即第二用户对应的车辆的信息，此时，在第一终端的操作界面上将显示该车辆信息。本发明实施例中的方法，相较于现有技术中司机很难满足每一位乘客的需求，或者乘客只能通过口头表达偏好信息与司机之间进行沟通协商的方式，可以根据第一用户的偏好信息匹配相应的第二用户对应的车辆，以使第二用户为第一用户进行服务，从而可以提高用户的体验。

需要进行说明的是，在图1中，第一终端12也可以为司机端的终端，第二终端13也可以为乘客端的终端，本发明实施例对此不作限制。

下面以具体的实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图2为本发明实施例提供的业务处理方法实施例一的流程示意图，本发明实施例提供了一种业务处理方法，该方法可以由任意执行业务处理方法的装置来执行，该装置可以通过软件和/或硬件实现。本实施例中，该装置可以集成在第一终端中。如图2所示，在图1所示应用场景的基础上，本发明实施例提供的业务处理方法包括如下步骤：

步骤201：接收第一用户在出行业务的操作界面上触发的订单请求，该订单请求中包括至少一项第一用户的偏好信息。

在本实施例中，第一终端中安装有出行平台，其中，出行平台为能够实现预约网约车功能的各种app。第一终端可以是手持设备、车载设备、可穿戴设备、计算设备，以及各种形式的用户设备(userequipment，ue)，移动台(mobilestation，ms)及终端(terminal)等。

图3a为出行业务的操作界面的一示意图，如图3a所示，当第一用户需要通过第一终端预约车辆时，可以在出行业务的操作界面301上触发订单请求，具体的，可以通过点击操作界面301上的按钮，或者通过点击其他按键或者通过触控屏幕等方式触发订单请求，例如，可以通过点击操作界面301上的“呼叫快车”302来触发订单请求，其中，订单请求中包括至少一项第一用户的偏好信息。

可选地，偏好信息可以包括如下信息中的至少一项：用户的行为习惯信息或用户需要的服务信息，其中，用户的行为习惯信息例如可以为用户是否喜欢聊天、用户是否喜欢听音乐、用户喜欢坐的位置或者用户是否能够接受车内有味道等等，用户需要的服务信息例如可以为用户身体状况不好需要帮助、用户年龄较大需要帮助或者用户需要喝水等等。

步骤202：根据订单请求，在操作界面上显示车辆信息，该车辆信息为第二用户对应的车辆的信息，该第二用户满足第一用户的预设数量的偏好信息。

在本实施例中，第一终端接收到第一用户触发的订单请求之后，第一终端会将该订单请求发送给服务器，服务器将从本地存储的多个第三用户的特征信息中，匹配符合第一用户的偏好信息的第二用户，其中，第三用户例如可以为司机，特征信息例如可以为各司机的特征，如是否喜欢和乘客聊天，是否喜欢听音乐等。当服务器匹配到第二用户之后，将向该第二用户对应的第二终端发送派单请求。在第二用户接单后，服务器会向第一终端发送预约成功的车辆的车辆信息，即第二用户对应的车辆的信息，此时，在第一终端的操作界面上将显示该车辆信息，其中，车辆信息包括如下信息中的至少一项：车辆型号、车辆颜色、车牌号、累积接单数量或司机的服务星级。例如：图3b为出行业务的操作界面的另一示意图，如图3b所示，当第一用户触发订单请求，且服务器为第一用户派单成功后，将在操作界面301上显示预约成功的车辆信息，如“车辆型号为s60l、车辆颜色为白色、车牌号为京xxx、累积接单数量为2000单、司机为吴师傅、司机的服务星级为4.8”。

另外，预设数量的具体取值与第一用户的偏好信息的数量有关，例如，若第一用户的偏好信息的数量为5，则预设数量可以为4，若第一用户的偏好信息的数量为4，则预设数量可以为3等，对于预设数量的具体取值，本发明实施例在此不作限制。

本发明实施例提供的业务处理方法，第一终端接收第一用户在出行业务的操作界面上触发的订单请求，并根据订单请求，在操作界面上显示车辆信息，该车辆信息为第二用户对应的车辆的信息，该第二用户满足第一用户的预设数量的偏好信息，订单请求中包括至少一项第一用户的偏好信息。由于第一终端接收到的第一用户触发的订单请求中包括有至少一项第一用户的偏好信息，则服务器在进行派单时，将会匹配能够满足第一用户的预设数量的偏好信息的第二用户，在第一终端中，会在操作界面上显示第二用户对应的车辆的信息，这样即可避免现有技术中乘客只能在预约到车辆之后，通过交流告知司机其自身的偏好信息的现象，由此可以提高用户的体验。

可选地，在图2所示实施例的基础上，在接收第一用户在出行业务的操作界面上触发的订单请求之前，第一终端还将接收第一用户在出行业务的设置界面上输入的偏好信息。

其中，第一终端接收第一用户在出行业务的设置界面上输入的偏好信息包括：在设置界面上显示多个预设的偏好信息，接收第一用户在设置界面上选择的偏好信息；和/或，接收第一用户在设置界面上输入的自定义的偏好信息。具体地，在出行业务的设置界面上可以显示有多个预设的偏好信息，第一用户可以直接在设置界面上选择至少一项偏好信息。当用户还有其他除预设的偏好信息之外的偏好时，也可以在设置界面上输入自定义的偏好信息。

另外，第一用户在设置界面上输入偏好信息时，可以根据实际情况在出行业务的不同阶段进行输入，如可以在个人设置中心进行输入，也可以在呼叫车辆的过程中进行输入，下面将详细介绍这几种输入方式：

第一种：在个人设置中心进行输入。

图4a为设置界面的一示意图，如图4a所示，对于一些固定的偏好信息，可以在个人设置中心进行设置，如在设置界面401中通过点击“乘车偏好”的标签，第一终端会向第一用户显示设置界面402，其中，设置界面402中上显示有多个预设的偏好信息，如“不爱聊天”、“不爱说话”、“播放音乐”、“关闭音乐”、“慢点开”、“味道过敏”和“坐后座”等，第一用户可以直接在设置界面402上进行偏好信息的选择。若用户还有其他的偏好信息，则可以在设置界面402的输入标签403中进行输入，如输入“视力不好，烦请给予帮助”等。由于用户可以直接在显示界面选择偏好信息，也可以在设置界面上输入偏好信息，还可以通过两者结合的方式输入偏好信息，因此这种实现方式可以根据用户的需求对偏好信息进行设置，进一步提高了用户体验。

需要说明的是，在个人设置中心设置的偏好信息，用户每次通过出行平台进行车辆预约时，该偏好信息都是有效的，即第一终端会将该偏好信息携带在订单请求中发送给服务器。

第二种：在呼叫车辆的过程中输入。

图4b为设置界面的另一示意图，如图4b所示，第一用户也可以在呼叫车辆的过程中输入偏好信息，如在设置界面404中点击“乘车偏好”的标签405，第一终端会向第一用户显示设置界面406，其中，设置界面406中上显示有多个预设的偏好信息，如“不爱聊天”、“不爱说话”、“播放音乐”、“关闭音乐”、“慢点开”、“味道过敏”和“坐后座”等，第一用户可以直接在设置界面406上进行偏好信息的选择。若用户还有其他的偏好信息，则可以在设置界面406的输入标签407中进行输入，如输入“视力不好，烦请给予帮助”等。由于用户可以直接在显示界面选择偏好信息，也可以在设置界面上输入偏好信息，还可以通过两者结合的方式输入偏好信息，因此这种实现方式可以根据用户的需求对偏好信息进行设置，进一步提高了用户体验。

需要说明的是，在呼叫车辆的过程中输入的偏好信息，只针对每次呼叫车辆有效，即第一用户下一次进行车辆预约时，将需要重新输入偏好信息。

值得注意的是，第一用户还可以在服务营卡片入口输入偏好信息，当然，还可以在其他入口输入偏好信息，只要是在服务器派单成功之前输入即可。

另外，对于不同的业务线来说，设置界面上展示的偏好信息的标签可以相同，也可以不同，例如：对于专车，设置界面上展示的偏好信息的标签可以包括“播放音乐”、“开的稳”和“提供饮料”等，对于快车，设置界面上展示的偏好信息的标签可以包括“播放音乐”、“慢点开”和“坐后座”等。在实际应用中，可以根据实际的车型、服务情况或者业务线进行设置，这样可以提高偏好信息设置的灵活性。

本发明实施例提供的业务处理方法，第一终端接收第一用户在出行业务的操作界面上触发的订单请求，并根据订单请求，在操作界面上显示车辆信息，该车辆信息为第二用户对应的车辆的信息，该第二用户满足第一用户的预设数量的偏好信息，订单请求中包括至少一项第一用户的偏好信息。由于第一终端接收到的第一用户触发的订单请求中包括有至少一项第一用户的偏好信息，则服务器在进行派单时，将会匹配能够满足第一用户的预设数量的偏好信息的第二用户，在第一终端中，会在操作界面上显示第二用户对应的车辆的信息，这样即可避免现有技术中乘客只能在预约到车辆之后，通过交流告知司机其自身的偏好信息的现象，由此可以提高用户的体验。

图5为本发明实施例提供的业务处理方法实施例二的流程示意图，本发明实施例提供了一种业务处理方法，该方法可以由任意执行业务处理方法的装置来执行，该装置可以通过软件和/或硬件实现。本实施例中，该装置可以集成在第二终端中。如图5所示，在图1所示应用场景的基础上，本发明实施例提供的业务处理方法包括如下步骤：

步骤501：在出行业务的派单界面上显示订单信息。

在本实施例中，第二终端中安装有出行平台，其中，出行平台为能够实现预约网约车功能的各种app。第二终端可以是手持设备、车载设备、可穿戴设备、计算设备，以及各种形式的ue，ms及终端(terminal)等。

当第一用户通过第一终端触发订单请求，且第一终端向服务器发送该订单请求后，服务器会将订单请求中包括的第一用户的偏好信息和本地存储的多个第三用户的特征信息进行匹配，以确定满足预设数量的偏好信息的第二用户，确定出第二用户后，将向第二用户对应的第二终端发送派单请求，其中，该派单请求中包括订单信息和偏好信息。图6为派单界面的示意图，如图6所示，第二终端在接收到订单信息和偏好信息后，会将订单信息显示在出行业务的派单界面601上，其中，订单信息包括出发地、目的地以及与乘客之间的距离。

步骤502：接收第二用户在派单界面上触发的确认操作请求。

在本实施例中，继续参照图6所示，第二终端在派单界面601上显示订单信息后，第二用户将根据自己的实际情况选择是否接单，若第二用户选择接单时，将在派单界面601上触发确认操作请求，如可以通过点击派单界面601上的“接单”标签进行触发。

步骤503：根据确认操作请求，在出行业务的出行显示界面上显示弹窗，弹窗中显示有至少一项第一用户的偏好信息。

在本实施例中，第二终端在接收到第二用户触发的确认操作请求后，将在出行业务的显示界面上显示弹窗，以在弹窗中显示至少一项第一用户的偏好信息。例如：图7为出行显示界面的一示意图，如图6-图7所示，当第二终端在接收到第二用户触发的确认操作请求后，第二终端的界面将会由派单界面601跳转到出行显示界面701，且出行显示界面701上将显示弹窗702，在弹窗702上显示有第一用户的偏好信息，如“不爱聊天”、“慢点开”和“视力不好，请给予帮助”，以使第二用户根据弹窗中显示的偏好信息为第一用户提供服务。

可选地，偏好信息可以包括如下信息中的至少一项：用户的行为习惯信息或用户需要的服务信息，其中，用户的行为习惯信息例如可以为用户是否喜欢聊天、用户是否喜欢听音乐、用户喜欢坐的位置或者用户是否能够接受车内有味道等等，用户需要的服务信息例如可以为用户身体状况不好需要帮助、用户年龄较大需要帮助或者用户需要喝水等等。

本发明实施例提供的业务处理方法，第二终端通过在出行业务的派单界面上显示订单信息，并接收第二用户在派单界面上触发的确认操作请求，根据该确认操作请求，在出行业务的出行显示界面上显示弹窗，该弹窗中显示有至少一项第一用户的偏好信息。由于第二终端在接收到第二用户触发的确认操作请求后，将在出行显示界面上显示至少一项第一用户的偏好信息，以使第二用户能够更好的为第一用户服务，这样即可避免现有技术中乘客只能通过口头交流方式告知司机其自身的偏好信息的现象，由此可以提高用户的体验。

可选地，在图5所示实施例的基础上，在根据确认操作请求，在出行业务的出行显示界面上显示弹窗之后，还包括：接收第二用户对弹窗的触控操作，根据该触控操作，在出行显示界面上显示偏好信息的隐藏标签。

具体的，图8为出行显示界面的另一示意图，如图7和图8所示，第二用户对图7中的弹窗进行触控操作之后，第二终端将在出行显示界面801上显示偏好信息的隐藏标签802，这样，第一用户的偏好信息将会被隐藏。其中，触控操作包括点击操作或滑动操作等，如通过点击图7中的“x”标签，即可隐藏第一用户的偏好信息。

可选地，在图8所示实施例的基础上，在出行显示界面上显示偏好信息的隐藏标签之后，还包括：接收第二用户对隐藏标签的触控操作，根据触控操作，在出行显示界面上显示偏好信息。

具体的，图9为出行显示界面的又一示意图，如图8和图9所示，第二用户通过对图8中的隐藏标签进行触控操作之后，第二终端将在出行显示界面901上显示偏好信息902，这样，第一用户的偏好信息将会被展开显示。其中，触控操作包括点击操作或滑动操作等，如通过点击图8中的隐藏标签，或者向上滑动隐藏标签等。通过设置隐藏标签，可以使第二用户方便的查看第一用户的偏好信息，从而可以提高用户的体验。

图10为本发明实施例提供的业务处理方法实施例三的流程示意图，本发明实施例提供了一种业务处理方法，该方法可以由任意执行业务处理方法的装置来执行，该装置可以通过软件和/或硬件实现。本实施例中，该装置可以集成在服务器中。如图10所示，在图1所示应用场景的基础上，本发明实施例提供的业务处理方法包括如下步骤：

步骤1001：接收第一终端发送的订单请求，该订单请求中包括至少一项第一用户的偏好信息。

在本实施例中，第一终端中安装有出行平台，其中，出行平台为能够实现预约网约车功能的各种app。第一终端可以是手持设备、车载设备、可穿戴设备、计算设备，以及各种形式的ue，ms及终端(terminal)等。当第一用户需要通过第一终端预约车辆时，可以在出行业务的操作界面上触发订单请求，第一终端在接收到第一用户触发的订单请求之后，会将该订单请求发送给服务器。其中，该订单请求中包括至少一项第一用户的偏好信息，可选地，偏好信息可以包括如下信息中的至少一项：用户的行为习惯信息或用户需要的服务信息，其中，用户的行为习惯信息例如可以为用户是否喜欢聊天、用户是否喜欢听音乐、用户喜欢坐的位置或者用户是否能够接受车内有味道等等，用户需要的服务信息例如可以为用户身体状况不好需要帮助、用户年龄较大需要帮助或者用户需要喝水等等。

步骤1002：根据偏好信息，匹配满足预设数量的偏好信息的第二用户。

在本实施例中，服务器在接收到第一终端发送的订单请求后，将根据订单请求中携带的偏好信息，匹配满足预设数量的偏好信息的第二用户。在具体的实现过程中，服务器将根据偏好信息和预先存储的多个第三用户的特征信息，确定第二用户，其中，第三用户例如可以为司机，特征信息例如可以为各司机的特征，如是否喜欢和乘客聊天，是否喜欢听音乐等。

另外，第二用户可以为一个，也可以为多个，当有多个第三用户的特征信息均同时满足第一用户的偏好信息时，服务器会将这多个第三用户均确定为第二用户。

步骤1003：向第二用户对应的第二终端发送派单请求，该派单请求中包括订单信息和偏好信息。

在本实施例中，服务器在匹配到第二用户后，会向第二用户对应的第二终端发送派单请求，其中，派单请求中包括订单信息和偏好信息，订单信息中包括出发地、目的地和与乘客之间的距离等。第二终端在接收到派单请求后，会将订单信息显示在出行业务的派单界面上，以供第二用户根据自己的实际情况选择是否接单。

值得注意的是，由于每个第一用户的偏好信息不同，且偏好信息的数量也不同，因此，服务器在向第二用户对应的第二终端发送派单请求时，将根据如下两种模式进行：

第一种：将第一用户发送的订单请求发送给能够满足第一用户的偏好信息的第二用户。

具体地，若第一用户的偏好信息数量较少，服务器通过与本地存储的多个第三用户(司机)的特征信息进行匹配，发现有第二用户能够满足第一用户所有的偏好信息时，则可以将订单派给该第二用户。其中，第二用户的数量可以为一个，也可以为多个。

另外，若服务器发现存在第二用户能够满足第一用户所有的偏好信息，但是该第二用户与乘客的距离较远，或者第二用户此时正在业务出行过程中时，服务器可以将与乘客距离较近，且能够满足第一用户的预设数量的偏好信息的用户确定为第二用户，并将订单派给该第二用户。

第二种：若第一用户的偏好信息数量较多，服务器将很难匹配到能够满足所有偏好信息的第二用户，此时，服务器将第一用户的偏好信息进行拆分，将订单请求发送给能够满足第一用户的预设数量的偏好信息的多个第二用户。

具体地，当第一用户的偏好信息的数量较多，服务器无法匹配到合适的司机时，会将偏好信息进行拆分，即拆分为不同的类型，并将包含拆分后的偏好信息的订单请求发送给不同的第二用户。例如：若第一用户的偏好信息包括“不爱聊天、不爱打电话、速度慢、关闭音乐和味道过敏”，服务器在接收到第一终端发送的包含上述偏好信息的订单请求之后，将与本地存储的第三用户的特征信息进行匹配，发现没有满足上述偏好信息的司机，服务器会将上述偏好信息进行拆分，如拆分为四组，分别为“不爱聊天、不爱打电话、速度慢和关闭音乐”、“不爱聊天、不爱打电话、速度慢和味道过敏”、“不爱聊天、速度慢、关闭音乐和味道过敏”和“不爱打电话、速度慢、关闭音乐和味道过敏”，再匹配是否有满足拆分后的偏好信息的第二用户，如果有，则将订单请求发送给该第二用户。

本发明实施例提供的业务处理方法，服务器接收第一终端发送的订单请求，该订单请求中包括至少一项第一用户的偏好信息，根据该偏好信息，匹配满足预设数量的偏好信息的第二用户，并向第二用户对应的第二终端发送派单请求，该派单请求中包括订单信息和偏好信息。由于第一终端向服务器发送的订单请求中包括有至少一项第一用户的偏好信息，则服务器在进行派单时，将会匹配能够满足第一用户的预设数量的偏好信息的第二用户，并向该第二用户发送派单请求，这样即可避免现有技术中乘客只能在预约到车辆之后，通过交流告知司机其自身的偏好信息的现象，由此可以提高用户的体验。

图11为本发明实施例提供的业务处理方法实施例三的流程示意图，在上述图10所示实施例的基础上，对服务器根据第一用户对第二用户的服务的评价信息中分析第一用户的偏好信息的实施例，做详细说明。如图11所示，本实施例的方法可以包括：

步骤1101、接收第一终端发送的评价信息，该评价信息为第一用户对第二用户的服务的评价信息。

在本实施例中，当第二用户对第一用户进行服务之后，第一用户可能会对第二用户的服务进行相关的评价，此时，第一用户将通过第一终端向服务器发送评价信息。

步骤1102、根据评价信息，创建表示第一用户偏好的至少一项预设的偏好信息。

在本实施例中，服务器将根据第一终端发送的评价信息，分析第一用户的偏好信息，在实际应用中，服务器可以通过提取关键字，并对关键字进行分析，以创建表示第一用户偏好的至少一项预设的偏好信息。例如：若服务器接收到第一终端发送的评价信息为“司机全程放着音乐，很吵”，服务器通过提取关键字“音乐、吵”，即可分析出该第一用户不喜欢听音乐，则将“关闭音乐”创建为第一用户的偏好信息。

步骤1103、将预设的偏好信息发送给第一终端。

在本实施例中，服务器在根据评价信息创建出表示第一用户偏好的至少一项预设的偏好信息后，会将预设的偏好信息发送给第一终端，则第一终端将在出行业务的设置界面上显示服务器发送的多个预设的偏好信息，以供第一用户进行设置。

本发明实施例提供的业务处理方法，服务器通过接收第一终端发送的评价信息，该评价信息为第一用户对第二用户的服务的评价信息，根据该评价信息，创建表示第一用户偏好的至少一项预设的偏好信息，将预设的偏好信息发送给第一终端。由于服务器会根据第一终端发送的评价信息分析第一用户的偏好信息，并将分析出的偏好信息发送给第一终端，以供第一终端进行显示并供第一用户选择，由此可以提高用户的体验。

可选地，向第二用户对应的第二终端发送派单请求之后，还包括：接收第二终端发送的确认响应，该确认响应用于指示第二用户接单，根据确认响应，向第一终端发送车辆信息。

具体地，服务器向第二用户对应的第二终端发送派单请求之后，第二用户若选择接单，则将在派单界面上触发确认操作请求，第二终端根据接收到的确认操作请求，向服务器发送确认响应，以告知服务器第二用户已经接单。此时，服务器会根据确认响应，向第一终端发送车辆信息，第一终端将在操作界面上显示接收到的车辆信息。其中，车辆信息包括如下信息中的至少一项：车辆型号、车辆颜色、车牌号、累积接单数量或司机的服务星级。

图12为本发明实施例提供的业务处理方法实施例四的信令流程图，如图12所示，本实施例的方法可以包括：

步骤1201、第一终端接收第一用户在出行业务的操作界面上触发的订单请求。

其中，订单请求中包括至少一项第一用户的偏好信息。

步骤1202、第一终端向服务器发送订单请求。

步骤1203、服务器根据偏好信息，匹配满足预设数量的偏好信息的第二用户。

步骤1204、服务器向第二用户对应的第二终端发送派单请求。

其中，派单请求中包括订单信息和偏好信息。

步骤1205、第二终端在出行业务的派单界面上显示订单信息。

步骤1206、第二终端接收第二用户在派单界面上触发的确认操作请求。

步骤1207、第二终端根据确认操作请求，在出行业务的出行显示界面上显示弹窗。

其中，弹窗中显示有至少一项第一用户的偏好信息。

步骤1208、第二终端向服务器发送确认响应。

其中，确认响应用于指示第二用户接单。

步骤1209、服务器根据确认响应，向第一终端发送车辆信息。

步骤1210、第一终端在操作界面上显示车辆信息。

其中，车辆信息为第二用户对应的车辆的信息，所述第二用户满足所述第一用户的预设数量的偏好信息。

本发明实施例提供的业务处理方法，第一终端接收第一用户在出行业务的操作界面上触发的订单请求，并根据订单请求，在操作界面上显示车辆信息，该车辆信息为第二用户对应的车辆的信息，该第二用户满足第一用户的预设数量的偏好信息，订单请求中包括至少一项第一用户的偏好信息。由于第一终端接收到的第一用户触发的订单请求中包括有至少一项第一用户的偏好信息，则服务器在进行派单时，将会匹配能够满足第一用户的预设数量的偏好信息的第二用户，在第一终端中，会在操作界面上显示第二用户对应的车辆的信息，这样即可避免现有技术中乘客只能在预约到车辆之后，通过交流告知司机其自身的偏好信息的现象，由此可以提高用户的体验。

图13为本申请业务处理装置实施例一的结构示意图，该装置可以位于终端，参见图13，该装置包括：接收模块21和显示模块22，其中：

接收模块21用于接收第一用户在所述出行业务的操作界面上触发的订单请求，所述订单请求中包括至少一项第一用户的偏好信息；

显示模块22用于根据所述订单请求，在所述操作界面上显示车辆信息，所述车辆信息为第二用户对应的车辆的信息，所述第二用户满足所述第一用户的预设数量的偏好信息。

可选地，所述接收模块21还用于接收所述第一用户在所述出行业务的设置界面上输入的所述偏好信息。

可选地，在所述设置界面上显示多个预设的偏好信息，所述接收模块21还用于接收所述第一用户在所述设置界面上选择的偏好信息。

图14为本申请业务处理装置实施例二的结构示意图，在图13所示实施例的基础上，该装置还包括发送模块23，其中：

所述发送模块23用于向服务器发送所述订单请求；

所述接收模块21还用于接收所述服务器发送的所述车辆信息。

可选地，所述发送模块，用于向服务器发送所述订单请求；

所述接收模块，还用于接收所述服务器发送的所述车辆信息。

上述装置可用于执行上述对应方法实施例提供的方法，具体实现方式和技术效果类似，这里不再赘述。

图15为本申请业务处理装置实施例三的结构示意图，该装置可以位于终端，参见图15，该装置包括：显示模块31和接收模块32，其中：

显示模块31用于在所述出行业务的派单界面上显示订单信息；

接收模块32用于接收第二用户在所述派单界面上触发的确认操作请求；

所述显示模块31还用于根据所述确认操作请求，在所述出行业务的出行显示界面上显示弹窗，所述弹窗中显示有至少一项第一用户的偏好信息。

可选地，所述接收模块32还用于接收所述第二用户对所述弹窗的触控操作；

所述显示模块31还用于根据所述触控操作，在所述出行显示界面上显示所述偏好信息的隐藏标签。

可选地，所述接收模块32还用于接收所述第二用户对所述隐藏标签的触控操作；

所述显示模块31还用于根据所述触控操作，在所述出行显示界面上显示所述偏好信息。

可选地，所述接收模块32还用于接收服务器发送的派单请求，所述派单请求中包括所述订单信息和所述偏好信息。

图16为本申请业务处理装置实施例四的结构示意图，在图15所示实施例的基础上，该装置还包括发送模块33，其中：

所述发送模块33用于根据所述确认操作请求，向服务器发送确认响应，所述确认响应用于指示所述第二用户接单。

可选地，所述偏好信息包括如下信息中的至少一项：用户的行为习惯信息或用户需要的服务信息。

上述装置可用于执行上述对应方法实施例提供的方法，具体实现方式和技术效果类似，这里不再赘述。

图17为本申请业务处理装置实施例五的结构示意图，该装置可以位于服务器，参见图17，该装置包括：接收模块41、处理模块42和发送模块43，其中：

接收模块41用于接收第一终端发送的订单请求，所述订单请求中包括至少一项第一用户的偏好信息；

处理模块42用于根据所述偏好信息，匹配满足预设数量的所述偏好信息的第二用户；

发送模块43用于向所述第二用户对应的第二终端发送派单请求，所述派单请求中包括订单信息和所述偏好信息。

可选地，所述接收模块41还用于接收所述第一终端发送的评价信息，所述评价信息为第一用户对所述第二用户的服务的评价信息；

所述处理模块42还用于根据所述评价信息，创建表示所述第一用户偏好的至少一项预设的偏好信息；

所述发送模块43还用于将所述预设的偏好信息发送给所述第一终端。

可选地，所述处理模块42具体用于：

根据所述偏好信息和预先存储的多个第三用户的特征信息，确定所述第二用户。

可选地，所述接收模块41还用于接收所述第二终端发送的确认响应，所述确认响应用于指示所述第二用户接单；

所述发送模块43还用于根据所述确认响应，向所述第一终端发送车辆信息。

可选地，所述偏好信息包括如下信息中的至少一项：用户的行为习惯信息或用户需要的服务信息。

上述装置可用于执行上述对应方法实施例提供的方法，具体实现方式和技术效果类似，这里不再赘述。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。