信息交互方法及装置与流程

本申请涉及信息交互领域，具体而言，涉及一种信息交互方法及装置。

背景技术：

目前，随着移动通信技术的发展，人们对服务的需求越来越多，尤其是在线下产生买东西、打车、吃饭等服务项目，然后通过无现金支付，给人们带来了很大的方便。

现有技术中，尤其是在线下集散场景进行服务项目的线上信息交互时，如：购物中心、火车站、足球场、大型演唱会等地方，通常是通过线上的一些应用选择相应的服务，然后在服务完成后，获取服务提供方如：商户、车主、饭店等的收款码来对服务项目进行支付。

但是，采用现有技术，用户终端与服务提供方终端之间的服务交互过程很难保证交互安全性。

技术实现要素：

有鉴于此，本申请实施例的目的在于提供一种信息交互方法、装置、电子设备及计算机可读存储介质，能够建立服务请求方和服务提供方的联系，在验证信息的安全措施下完成服务内容信息的交互。

第一方面，本申请实施例提供一种信息交互方法，应用于服务请求方终端，该方法包括：

获取服务提供方的识别信息；解析识别信息，获取并显示服务提供方的验证信息；接收服务请求方根据验证信息输入的服务内容信息；发送服务内容信息给服务提供方。

可选地，上述获取服务提供方的识别信息，包括：

获取服务提供方的识别码，或者获取服务提供方的识别码和辅助验证信息。

可选地，上述获取服务提供方的识别码和辅助验证信息之后，该方法还包括：

验证辅助验证信息是否与预设的辅助验证信息一致；

相应地，解析识别信息，获取并显示服务提供方的验证信息，包括：

若辅助验证信息与预设的辅助验证信息一致，则解析识别码，获取并显示服务提供方的验证信息。

可选地，服务提供方的验证信息包括：服务提供方的服务人员和/或服务工具的验证信息。

可选地，服务内容信息包括下述一项或多项：服务请求信息、服务支付方式、服务类型。

可选地，获取服务提供方的识别信息之前，该方法还包括：

获取服务请求方的类型；根据服务请求方的类型，推送服务请求方的类型对应的指引信息。

可选地，获取服务提供方的识别信息之后，该方法还包括：

根据识别信息确认是否安装识别信息对应的服务应用程序；若确认未安装，则显示提示信息，提示信息用于提示下载服务应用程序。

可选地，解析识别信息，获取并显示服务提供方的验证信息之后，该方法还包括：

向服务器发送验证信息；接收服务器根据验证信息发送的服务提供方的安全信息；若确认安全信息属于高风险，则推送服务不成功信息。

可选地，在接收输入的服务内容信息之后，该方法还包括：

向服务器发送服务内容信息；接收服务器根据服务内容信息发送的服务安全信息，服务安全信息用于指示服务内容信息是否有安全隐患；若服务安全信息指示有安全隐患，则推送服务不成功信息。

第二方面，本申请实施例提供一种信息交互方法，应用于服务提供方终端，该方法包括：

显示服务提供方的识别信息；接收根据识别信息发送的服务内容信息，识别信息用于指示服务提供方的验证信息。

可选地，显示服务提供方的识别信息，包括：

显示服务提供方的识别码，或者显示服务提供方的识别码和辅助验证信息。

可选地，显示服务提供方的识别信息，包括：

显示服务提供方的识别信息，并向服务器发送服务通知，服务通知用于指示当前处于服务状态。

可选地，在接收根据识别信息发送的服务内容信息之前，该方法还包括：

接收服务器根据验证信息发送的服务请求方的安全信息；若确认安全信息属于高风险，则推送服务不成功信息。

第三方面，本申请实施例提供一种信息交互装置，应用于服务请求方终端，该装置包括：

第一获取模块，用于获取服务提供方的识别信息；解析模块，用于解析识别信息，获取并显示服务提供方的验证信息；第一接收模块，用于接收服务请求方根据验证信息输入的服务内容信息；第一发送模块，用于发送服务内容信息给服务提供方。

可选地，第一获取模块用于获取服务提供方的识别信息，包括：

获取服务提供方的识别码，或者获取服务提供方的识别码和辅助验证信息。

可选地，该装置还包括：

验证模块，用于验证辅助验证信息是否与预设的辅助验证信息一致；相应地，解析模块用于解析识别信息，获取并显示服务提供方的验证信息，包括：

若辅助验证信息与预设的辅助验证信息一致，则解析识别码，获取并显示服务提供方的验证信息。

可选地，服务提供方的验证信息包括：服务提供方的服务人员和/或服务工具的验证信息。

可选地，服务内容信息包括下述一项或多项：服务请求信息、服务支付方式、服务类型。

可选地，该装置还包括：第二获取模块和第一推送模块；在第一获取模块获取服务提供方的识别信息之前，第二获取模块用于获取服务请求方的类型；第一推送模块用于根据服务请求方的类型，推送服务请求方的类型对应的指引信息。

可选地，该装置还包括：识别模块和提示模块；在第一获取模块获取服务提供方的识别信息之后，识别模块用于根据识别信息确认是否安装识别信息对应的服务应用程序；提示模块用于若确认未安装，则显示提示信息，提示信息用于提示下载服务应用程序。

可选地，该装置还包括：第二发送模块、第二接收模块和第二推送模块；在解析模块解析识别信息，获取并显示服务提供方的验证信息之后，第二发送模块用于向服务器发送验证信息；第二接收模块用于接收服务器根据验证信息发送的服务提供方的安全信息；第二推送模块用于若确认安全信息属于高风险，则推送服务不成功信息。

可选地，该装置还包括：第三发送模块、第三接收模块和第三推送模块；在第一接收模块接收输入的服务内容信息之后，第三发送模块用于向服务器发送服务内容信息；第三接收模块用于接收服务器根据服务内容信息发送的服务安全信息，服务安全信息用于指示服务内容信息是否有安全隐患；第三推送模块用于若服务安全信息指示有安全隐患，则推送服务不成功信息。

第四方面，本申请实施例提供一种信息交互装置，应用于服务提供方终端，该装置包括：

显示模块，用于显示服务提供方的识别信息；第一接收模块，用于接收根据识别信息发送的服务内容信息，识别信息用于指示服务提供方的验证信息。

可选地，显示模块用于显示服务提供方的识别信息，包括：

显示服务提供方的识别码，或者显示服务提供方的识别码和辅助验证信息。

可选地，该装置还包括：

通知模块，用于显示模块显示服务提供方的识别信息时，向服务器发送服务通知，服务通知用于指示当前处于服务状态。

可选地，该装置还包括：第二接收模块和推送模块；在第一接收模块接收根据识别信息发送的服务内容信息之前，第二接收模块用于接收服务器根据验证信息发送的服务请求方的安全信息；推送模块用于若确认安全信息属于高风险，则推送服务不成功信息。

第五方面，本申请实施例提供一种电子设备，包括：处理器、存储介质和总线，存储介质存储有处理器可执行的机器可读指令，当电子设备运行时，处理器与存储介质之间通过总线通信，处理器执行机器可读指令，以执行时执行如第一方面或第二方面所述的信息交互方法的步骤。

第六方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如第一方面或第二方面所述的信息交互方法的步骤。

基于上述任一方面，通过服务请求方与服务提供方可以分别通过服务请求方终端和服务提供方终端确认识别信息的一致性，从而保证了服务请求方与服务提供方之间通过服务请求方终端和服务提供方终端进行服务交互过程的安全性。

附图说明

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

图1示出了本申请一些实施例中信息交互系统的结构示意图；

图2示出了本申请实施例所提供的电子设备的结构示意图；

图3示出了本申请实施例所提供的一种信息交互方法的流程图；

图4示出了本申请实施例所提供的又一种信息交互方法的流程图；

图5示出了本申请实施例所提供的又一种信息交互方法的流程图；

图6示出了本申请实施例所提供的又一种信息交互方法的流程图；

图7示出了本申请实施例所提供的又一种信息交互方法的流程图；

图8示出了本申请实施例所提供的另一种信息交互方法的流程图；

图9示出了本申请实施例所提供的另一种信息交互方法的流程图；

图10示出了本申请实施例所提供的另一种信息交互方法的流程图；

图11示出了本申请实施例所提供的一种信息交互装置的结构示意图；

图12示出了本申请实施例所提供的另一种信息交互装置的结构示意图；

图13示出了本申请实施例所提供的另一种信息交互装置的结构示意图；

图14示出了本申请实施例所提供的另一种信息交互装置的结构示意图；

图15示出了本申请实施例所提供的另一种信息交互装置的结构示意图；

图16示出了本申请实施例所提供的另一种信息交互装置的结构示意图；

图17示出了本申请实施例所提供的又一种信息交互装置的结构示意图；

图18示出了本申请实施例所提供的又一种信息交互装置的结构示意图；

图19示出了本申请实施例所提供的又一种信息交互装置的结构示意图；

图20示出了本申请实施例所提供的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

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

为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“线下集散场景的服务过程中的信息交互过程”，该服务可以是：出租车服务、快车服务、单车服务、支付服务等，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕线下集散场景的出租车服务进行描述，但是应该理解，这仅是一个示例性实施例。本申请可以应用于任何其他交通运输类型。例如，本申请可以应用于不同的运输系统环境，包括陆地，海洋，或航空等，或其任意组合。本申请还可以用于包括外卖、快递、购物、物品租赁等的任何服务系统，例如，用于发送和/或接收快递的系统、用于买卖双方交易的服务系统等。本申请的系统或方法的应用可以包括网页、浏览器的插件、客户端终端、定制系统、内部分析系统、或人工智能机器人等，或其任意组合。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

本申请中的术语“乘客”、“请求方”、“服务人员”、“服务请求方”和“客户”可互换使用，以指代可以请求或订购服务的个人、实体或工具。本申请中的术语“司机”、“提供方”、“服务提供方”和“供应方”可互换使用，以指代可以提供服务的个人、实体或工具。本申请中的术语“用户”可以指代请求服务、订购服务、提供服务或促成服务的提供的个人、实体或工具。例如，用户可以是乘客、驾驶员、操作员等，或其任意组合。在本申请中，“乘客”和“乘客终端”可以互换使用，“驾驶员”和“驾驶员终端”可以互换使用。

本申请中的术语“服务请求”和“订单”可互换使用，以指代由乘客、服务请求方、司机、服务提供方、或供应方等、或其任意组合发起的请求。接受该“服务请求”或“订单”的可以是乘客、服务请求方、司机、服务提供方、或供应方等、或其任意组合。服务请求可以是收费的或免费的。

在本申请提出申请之前，现有的技术方案为：目前，足球赛事举办地、大型演唱会举办地、机场、购物中心、火车站等集散场所人员密集，乘客在使用网约车线上服务的时候，乘客是通过手动筛选附近司机的列表中对应的司机发起乘车服务订单，而司机在接到订单后，根据乘客的定位地点等待乘客上车，从而使得乘客完成乘车服务。

其所导致的技术问题为：乘客很难选中指定的司机，司机也很难在拥挤的人群中找到乘客，使得乘客和司机之间的服务交互过程变得复杂，同时，也很难保证信息交互的安全性。

为了解决上述技术问题，本申请实施例提供一种信息交互方法。其核心改进点在于：通过服务请求方验证服务提供方的识别信息，从而建立两者的联系，并在获取验证信息的安全措施下，进行服务内容信息的交互。下面通过可能的实现方式对本申请的技术方案进行说明。

本申请的一个方面涉及一种信息交互系统，该系统中服务请求方终端与服务提供方终端之间可以通过识别信息建立联系，在验证信息的安全措施下能够完成服务内容信息的交互。

图1示出了本申请一些实施例中信息交互系统的结构示意图。如图1所示，信息交互系统100可以包括服务器110、网络120、服务请求方终端130、服务提供方终端140和数据库150中的一种或多种，服务器110中可以包括执行指令操作的处理器。

其中，信息交互系统100可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。

在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式系统)。在一些实施例中，服务器110相对于终端，可以是本地的、也可以是远程的。例如，服务器110可以经由网络120访问存储在服务请求方终端130、服务提供方终端140、或数据库150、或其任意组合中的信息和/或数据。作为另一示例，服务器110可以直接连接到服务请求方终端130、服务提供方终端140和数据库150中至少一个，以访问存储的信息和/或数据。在一些实施例中，服务器110可以在云平台上实现；仅作为示例，云平台可以包括私有云、公有云、混合云、社区云(communitycloud)、分布式云、跨云(inter-cloud)、多云(multi-cloud)等，或者它们的任意组合。在一些实施例中，服务器110可以在具有本申请中图2所示的一个或多个组件的电子设备200上实现。

在一些实施例中，服务器110可以包括处理器。处理器可以处理与服务请求有关的信息和/或数据，以执行本申请中描述的一个或多个功能。例如，处理器可以基于从服务请求方终端130获得的服务请求来确定目标车辆。在一些实施例中，处理器可以包括一个或多个处理核(例如，单核处理器(s)或多核处理器(s))。仅作为举例，处理器可以包括中央处理单元(centralprocessingunit，cpu)、专用集成电路(applicationspecificintegratedcircuit，asic)、专用指令集处理器(applicationspecificinstruction-setprocessor，asip)、图形处理单元(graphicsprocessingunit，gpu)、物理处理单元(physicsprocessingunit，ppu)、数字信号处理器(digitalsignalprocessor，dsp)、现场可编程门阵列(fieldprogrammablegatearray，fpga)、可编程逻辑器件(programmablelogicdevice，pld)、控制器、微控制器单元、简化指令集计算机(reducedinstructionsetcomputing，risc)、或微处理器等，或其任意组合。

网络120可以用于信息和/或数据的交换。在一些实施例中，信息交互系统100中的一个或多个组件(例如，服务器110，服务请求方终端130，服务提供方终端140和数据库150)可以向其他组件发送信息和/或数据。例如，服务器110可以经由网络120从服务请求方终端130获取服务请求。在一些实施例中，网络120可以是任何类型的有线或者无线网络，或者是他们的结合。仅作为示例，网络130可以包括有线网络、无线网络、光纤网络、远程通信网络、内联网、因特网、局域网(localareanetwork，lan)、广域网(wideareanetwork，wan)、无线局域网(wirelesslocalareanetworks，wlan)、城域网(metropolitanareanetwork，man)、广域网(wideareanetwork，wan)、公共电话交换网(publicswitchedtelephonenetwork，pstn)、蓝牙网络、zigbee网络、或近场通信(nearfieldcommunication，nfc)网络等，或其任意组合。在一些实施例中，网络120可以包括一个或多个网络接入点。例如，网络120可以包括有线或无线网络接入点，例如基站和/或网络交换节点，信息交互系统100的一个或多个组件可以通过该接入点连接到网络120以交换数据和/或信息。

在一些实施例中，服务请求方终端130的用户可以是除服务实际需求者之外的其他人。例如，服务请求方终端130的用户a可以使用服务请求方终端130来为服务实际需求者b发起服务请求(比如，用户a可以为自己的朋友b叫车)，或者从服务器110接收服务信息或指令等。在一些实施例中，服务提供方终端140的用户可以是服务实际提供者，也可以是除服务实际提供者之外的其他人。例如，服务提供方终端140的用户c可以使用服务提供方终端140接收由服务实际提供者d提供服务的服务请求(比如用户c可以为自己雇用的司机d接单)，和/或来自服务器110的信息或指令。在一些实施例中，“服务请求方”和“服务请求方终端”可以互换使用，“服务提供方”和“服务提供方终端”可以互换使用。

在一些实施例中，服务请求方终端130可以包括移动设备、平板计算机、膝上型计算机、或机动车辆中的内置设备等，或其任意组合。在一些实施例中，移动设备可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器设备的控制设备、智能监控设备、智能电视、智能摄像机、或对讲机等，或其任意组合。在一些实施例中，可穿戴设备可包括智能手环、智能头盔、智能手表、智能服装、智能背包、智能配件等、或其任何组合。在一些实施例中，智能移动设备可以包括智能手机、个人数字助理(personaldigitalassistant，pda)、游戏设备、导航设备、或销售点(pointofsale，pos)设备等，或其任意组合。在一些实施例中，虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实玻璃、虚拟现实贴片、增强现实头盔、增强现实玻璃、或增强现实贴片等，或其任意组合。例如，虚拟现实设备和/或增强现实设备可以包括各种虚拟现实产品等。在一些实施例中，机动车辆中的内置设备可以包括车载计算机、车载电视等。在一些实施例中，服务请求方终端130可以是具有用于定位服务请求方和/或服务请求方终端的位置的定位技术的设备。

在一些实施例中，服务提供方终端140可以是与服务请求方终端130类似或相同的设备。在一些实施例中，服务提供方终端140可以是具有定位技术的设备，用于定位服务提供方和/或服务提供方终端的位置。在一些实施例中，服务请求方终端130和/或服务提供方终端140可以与其他定位设备通信以确定服务请求方、服务请求方终端130、服务提供方、或服务提供方终端140、或其任意组合的位置。在一些实施例中，服务请求方终端130和/或服务提供方终端140可以将定位信息发送给服务器110。

数据库150可以存储数据和/或指令。在一些实施例中，数据库150可以存储从服务请求方终端130和/或服务提供方终端140获得的数据。在一些实施例中，数据库150可以存储在本申请中描述的示例性方法的数据和/或指令。在一些实施例中，数据库150可以包括大容量存储器、可移动存储器、易失性读写存储器、或只读存储器(read-onlymemory，rom)等，或其任意组合。作为举例，大容量存储器可以包括磁盘、光盘、固态驱动器等；可移动存储器可包括闪存驱动器、软盘、光盘、存储卡、zip磁盘、磁带等；易失性读写存储器可以包括随机存取存储器(randomaccessmemory，ram)；ram可以包括动态ram(dynamicrandomaccessmemory，dram)，双倍数据速率同步动态ram(doubledate-ratesynchronousram，ddrsdram)；静态ram(staticrandom-accessmemory，sram)，晶闸管ram(thyristor-basedrandomaccessmemory，t-ram)和零电容器ram(zero-ram)等。作为举例，rom可以包括掩模rom(maskread-onlymemory，mrom)、可编程rom(programmableread-onlymemory，prom)、可擦除可编程rom(programmableerasableread-onlymemory，perom)、电可擦除可编程rom(electricallyerasableprogrammablereadonlymemory，eeprom)、光盘rom(cd-rom)、以及数字通用磁盘rom等。在一些实施例中，数据库150可以在云平台上实现。仅作为示例，云平台可以包括私有云、公有云、混合云、社区云、分布式云、跨云、多云或者其它类似的等，或其任意组合。

在一些实施例中，数据库150可以连接到网络120以与信息交互系统100(例如，服务器110，服务请求方终端130，服务提供方终端140等)中的一个或多个组件通信。信息交互系统100中的一个或多个组件可以经由网络120访问存储在数据库150中的数据或指令。在一些实施例中，数据库150可以直接连接到信息交互系统100中的一个或多个组件(例如，服务器110，服务请求方终端130，服务提供方终端140等)；或者，在一些实施例中，数据库150也可以是服务器110的一部分。

在一些实施例中，信息交互系统100中的一个或多个组件(例如，服务器110，服务请求方终端130，服务提供方终端140等)可以具有访问数据库150的权限。在一些实施例中，当满足一定条件时，信息交互系统100中的一个或多个组件可以读取和/或修改与服务请求方、服务提供方、或公众、或其任意组合有关的信息。例如，服务器110可以在接收服务请求之后读取和/或修改一个或多个用户的信息。

在一些实施例中，可以通过请求服务来实现信息交互系统100中的一个或多个组件的信息交换。服务请求的对象可以是任何产品。在一些实施方案中，产品可以是有形产品或非物质产品。有形产品可包括食品、药品、方品、化学产品、电器、服装、汽车、房屋、或奢侈品等，或其任意组合。非物质产品可以包括服务产品、金融产品、知识产品、或互联网产品等，或其任意组合。互联网产品可以包括单独的主机产品、网络产品、移动互联网产品、方业主机产品、或嵌入式产品等，或其任意组合。互联网产品可以用在移动终端的软件、程序、或系统等，或者它们的任意组合中。移动终端可以包括平板电脑、笔记本电脑、移动电话、个人数字助理(personaldigitalassistant，pda)、智能手表、销售点(pointofsales，pos)设备、车载电脑、车载电视、或可穿戴设备等，或其任意组合。例如，互联网产品可以是计算机或移动电话中使用的任何软件和/或应用程序。软件和/或应用程序可以涉及社交、购物、运输、娱乐时间、学习、或投资等，或其任意组合。在一些实施例中，与运输有关的软件和/或应用程序可以包括旅行软件和/或应用程序、车辆调度软件和/或应用程序、绘图软件和/或应用程序等。在车辆调度软件和/或应用程序中。

图2示出了本申请实施例提供的电子设备的结构示意图。该电子设备200可以实现本申请思想的服务器110、服务请求方终端130、服务提供方终端140。例如，处理器220可以用于电子设备200上，并且用于执行本申请中的功能。

电子设备200可以是通用计算机或特殊用途的计算机，两者都可以用于实现本申请的信息交互方法。本申请尽管仅示出了一个计算机，但是为了方便起见，可以在多个类似平台上以分布式方式实现本申请描述的功能，以均衡处理负载。

例如，电子设备200可以包括连接到网络的网络端口210、用于执行程序指令的一个或多个处理器220、通信总线230、和不同形式的存储介质240，例如，磁盘、rom、或ram，或其任意组合。示例性地，计算机平台还可以包括存储在rom、ram、或其他类型的非暂时性存储介质、或其任意组合中的程序指令。根据这些程序指令可以实现本申请的方法。电子设备200还包括计算机与其他输入输出设备(例如键盘、显示屏)之间的输入/输出(input/output，i/o)接口250。

为了便于说明，在电子设备200中仅描述了一个处理器。然而，应当注意，本申请中的电子设备200还可以包括多个处理器，因此本申请中描述的一个处理器执行的步骤也可以由多个处理器联合执行或单独执行。例如，若电子设备200的处理器执行步骤a和步骤b，则应该理解，步骤a和步骤b也可以由两个不同的处理器共同执行或者在一个处理器中单独执行。例如，第一处理器执行步骤a，第二处理器执行步骤b，或者第一处理器和第二处理器共同执行步骤a和b。

图3是示出本申请实施例提供的一种信息交互方法流程示意图，应用于服务请求方终端，该服务请求方终端可以是智能手机、平板电脑等终端设备，如图3所示，本申请提供的信息交互方法，包括：

s101、获取服务提供方的识别信息。

本申请中，服务提供方是可以为服务请求方提供服务的应用程序的使用者，例如，以乘坐出租车为例，服务请求方为乘客时，对应的服务提供方可以为司机；以送快递为例，服务请求方为寄件人时，对应的服务提供方可以为送件人或者商家等，服务提供方的识别信息，该识别信息中携带有服务提供方的标识，如：服务提供人员的身份信息、服务提供人员在该应用程序app的识别码、服务工具的识别码、服务工具类型的识别码等，用于能够识别服务提供方即可，另外，该识别信息可以是二维码、条形码、数字码、动态口令、声音口令、动画等表现形式，但并不以此为限。

需要说明的是，通过获取服务提供方的识别信息，可以便于服务请求方获取服务提供方的标识，例如：乘客可以通过扫描二维码，获取到该司机的标识，该标识可以是司机在应用程序平台注册的账号、名称、身份证、驾驶证、车牌号、车型、终端标识等，在此不作限制，这个识别标识可以是二维码、条形码、数字码等表现形式，从而使得在大型集散场景中，方便了乘客与司机之间建立联系，提高了乘客乘车服务的体验度。可选地，服务提供方可以通过自己的终端显示屏向服务请求方提供该识别信息，也可以是打印的纸质版等，本申请不具体限制。

另外，服务提供方和服务请求方可以通过应用程序进行关联，服务请求方和服务提供方均可以在应用程序进行账号的注册，通过服务账号和/或服务信息等进行关联，例如：乘客和司机可以在滴滴、美团、支付宝等应用程序注册账号后，通过账号和/或乘车订单进行关联，从而使得服务提供方和服务请求方可以在任意一种终端上进行登录，获取相应的服务内容信息。

s102、解析识别信息，获取并显示服务提供方的验证信息。

本申请中，服务请求方是需要服务提供方提供服务的应用程序的使用者，继续以乘坐出租车为例，服务请求方为乘客时，对应的服务提供方可以为司机，乘客通过服务请求方终端获取到司机的识别信息之后，会对该识别信息进行解析，获取并显示司机的验证信息，该验证信息可以是服务提供方的服务人员和/或服务工具的验证信息，用于验证是否与所获取的司机的识别信息一致，其中，验证信息与该识别信息的表现形式可以一致，也可以不一致，即均可以是一样的二维码，也可以是一样的数字码，但其所能体现或者携带的内容是一致的，其中，对于识别信息的具体内容可参见上述步骤s101中的举例说明，在此不再赘述，验证信息的内容可参照识别信息，具体可以包括服务提供方的服务人员和/或服务工具的验证信息。

可选的，在显示服务提供方的验证信息之后，服务请求方会根据显示的验证信息进行验证核对，并将验证结果发送给该应用程序的服务器或者发送给服务提供方，从而可以精准匹配到相应的服务提供方，例如：乘客通过服务请求方终端扫描服务提供方终端显示的司机的二维码，解析获取到该二维码包含的信息(具体也可以是发送至服务器，由服务器反馈该二维码包含的信息)，例如司机照片、年龄，车辆的车牌号码和类型等，乘客确认根据这些信息确认是否与服务提供方实际情况一致，如果一致，即确认在该应用程序平台匹配到了司机，并与之建立联系。

s103、接收服务请求方根据验证信息输入的服务内容信息。

本申请中，在服务请求方与服务提供方建立好联系之后，服务请求方会根据验证信息验证核对后，会在服务请求方终端输入所需服务的服务内容信息，例如：在乘车服务时，乘客输入的目的地、支付方式和服务类型等，其中，服务类型可以是出租车、快车、顺风车、代驾车和单车等，在快递服务时，寄件人输入的收件地址、支付方式和邮寄类型等，在此不作限定。

s104、发送服务内容信息给服务提供方。

本申请中，服务请求方终端将上述服务请求方输入的服务内容信息，如：乘客输入的目的地、支付方式和服务类型发送给服务提供方，以便司机根据服务内容信息为乘客提供乘车服务。

需要说明的是，服务请求方终端和服务提供方终端通过平台服务器交互，该服务请求方终端先将服务内容信息发送给服务器，服务器收到后将服务内容信息发送给对应的服务提供方终端，服务提供方终端的应用程序界面上可以显示服务内容信息便于服务提供方查看，具体显示方式在此不做限制。可选地，服务提供方可以注册账号，服务器将服务内容信息发送给服务提供方通过自己账号登录的终端，例如手机、平板电脑等。

本申请实施例提供的一种信息交互方法，服务请求方通过服务请求方终端获取服务提供方终端显示的服务提供方的识别信息，并解析该识别信息，得到并显示服务提供方的验证信息，经过服务请求方验证通过后，从而方便了服务请求方匹配到精准的服务提供方，并与服务提供方之间建立连接，接收服务请求方输入的服务内容信息，并通过服务请求方终端将服务内容发送给服务提供方终端，由于服务请求方与服务提供方可以分别通过服务请求方终端和服务提供方终端确认识别信息的一致性，从而保证了服务请求方与服务提供方之间通过服务请求方终端和服务提供方终端进行服务交互过程的安全性。

进一步地，上述获取服务提供方的识别信息，包括：

获取服务提供方的识别码，或者，

获取服务提供方的识别码和辅助验证信息。

具体的，服务请求方终端获取服务提供方的识别信息，该识别信息可以是服务提供方的识别码，即二维码、条形码等图形码，还可以是动态图形码，如：动画图形码、声音图形码等，例如：当服务请求方通过服务请求方终端扫描服务提供方的二维码时，即可以通过解析的二维码信息来判断是否与服务提供方情况一致，如果一致再通过确认指令与该服务提供方建立连接。该识别信息还可以包括辅助验证信息，该辅助验证信息可以是数字码、字母码等码文，还可以是动态口令、动画口令和声音口令等，例如：当服务请求方通过服务请求方终端获取到服务提供方的二维码和数字码后，服务请求方将该二维码和数字码传输给服务器，进而服务器会发送该二维码和数字码对应的服务提供方信息，进而服务请求方人工确认该服务提供方信息与实际现场的服务提供方是否一致；或者，先扫描获取二维码信息并发送给服务器，接收服务器根据二维码信息反馈的服务提供方信息，进而服务请求方人工确认该服务提供方信息与实际现场的服务提供方是否一致，如果一致，还可以再通过输入服务提供方给出的数字码，并发送给服务器进行再次确认，使得服务请求方和服务提供方之间的连接更加可靠，对于上述图形码和辅助验证信息的表现形式，在此不作限定。

可选的，获取服务提供方的识别码和辅助验证信息之后，方法还包括：

验证辅助验证信息是否与预设的辅助验证信息一致。

在本申请中，服务请求方终端获取服务提供方的识别码和辅助验证信息之后，对于图形码可以通过人工验证，辅助验证信息可以通过服务请求方输入服务提供方终端显示的预设的辅助验证信息，其中，该预设的辅助验证信息可以是数字码、字母码等码文，还可以是动态口令、动画口令和声音口令等口令，其中，该预设的辅助验证信息可以是服务提供方终端自动生成的，也可以是服务提供方人工设置的，在此不做限定，但服务请求方终端在服务请求方输入辅助验证信息之后，验证辅助验证信息是否与预设的辅助验证信息一致。可选地，预设的辅助验证信息可以是服务器根据服务提供方信息发送给服务请求方终端的，由服务请求方终端来验证辅助验证信息是否与预设的辅助验证信息一致；也可以是终端将辅助验证信息发送给服务器，服务器比较辅助验证信息是否与预设的辅助验证信息一致。预设的辅助验证信息可以是跟服务提供方关联的，也可以是服务器随机生成再发送给服务提供方终端的，本申请不具体限制。

相应地，解析识别信息，获取并显示服务提供方的验证信息，包括：

若辅助验证信息与预设的辅助验证信息一致，则解析识别码，获取并显示服务提供方的验证信息。

在本申请中，若辅助验证信息与预设的辅助验证信息一致，则会对该识别信息进行解析，获取并显示服务提供方的验证信息，该验证信息用于验证是否与所获取的服务提供方的识别信息一致，从而便于服务请求方与服务提供方建立安全可靠地连接，从而能够保证两者服务过程信息交互的安全性。

可选的，服务提供方的验证信息包括：服务提供方的服务人员和/或服务工具的验证信息。

在本申请中，上述服务提供方的验证信息包括服务提供方的服务人员和/或服务工作的验证信息，例如：在乘车场景中，服务人员如果是司机，司机的验证信息，可以是司机的身份证、驾照、行驶证、注册应用程序平台的账户等，服务工具如果是出租车，可以是车牌、车型、出租车管理牌等，并不以此为限。

可选的，服务内容信息包括下述一项或多项：服务请求信息、服务支付方式、服务类型。

在本申请中，服务内容信息包括服务请求信息、服务支付方式、服务类型中的一项或多项，该服务请求信息可以是服务的目的地、服务人员、服务工具等，例如：乘车的目的地、邮寄快递的目的地、订餐的目的地等等，司机、快递员、外卖员等，汽车、快递车、外卖车等，该服务支付方式可以是线上支付方式、现金支付方式、刷卡支付方式等等，服务类型可以根据服务的内容或者场景来设定，例如在乘车场景中，可以是快车、拼车、顺风车、单车等服务类型，但并不以此为限。

可选的，如图4所示，获取服务提供方的识别信息之前，所述方法还包括：

s201、获取服务请求方的类型。

在本申请中，服务请求方终端在获取服务提供方的识别信息之前，获取服务请求方的类型，该服务请求方的类型可以根据服务应用程序app来具体设定，例如：新用户和老用户、是否开通线上支付功能、是否开通相机权限功能等，针对不同类型的服务请求方，会提供的相应的操作指引信息，从而便于各个类型的服务请求方使用该服务应用程序。

s202、根据服务请求方的类型，推送服务请求方的类型对应的指引信息。

在本申请中，根据服务请求方的类型，推送每个类型对应的指引信息，即针对上述不同的服务请求方的类型，例如：针对新用户，会推送新用户注册该服务应用程序的指引信息，针对没有开通支付能力的用户，会推送针对开通支付功能的指引信息，针对没有开通相机权限能力的用户，会推送针对开通相机权限能力的指引信息，该指引信息可以是文字指引、声音指引、动画指引中的一种或多种，便于服务请求方根据这些指引信息完成相应的操作。

可选地，如图5所示，获取服务提供方的识别信息之后，该方法还包括：

s301、根据识别信息确认是否安装识别信息对应的服务应用程序。

在本申请中，服务请求方终端可以通过服务应用程序获取服务提供方的识别信息，也可以通过第三方应用程序来获取服务提供方的识别信息，但获取到该服务提供方的识别信息之后，因此，服务请求方终端可以根据识别信息来确认是否安装识别信息对应的服务应用程序，若识别信息是可以通过服务请求方终端中对应的服务应用程序来获取的，即可以确定该服务请求方终端安装该服务应用程序，若识别信息是以一种链接的方式获取来的，即可以确定该服务请求方终端未安装该服务应用程序。

s302、若确认未安装，则显示提示信息，提示信息用于提示下载服务应用程序。

在本申请中，服务请求终端若确认未安装该服务应用程序，则显示提示信息，该提示信息用于提示服务请求方下载该服务应用程序，例如：可以引导用户到应用商店的页面，去下载对应的服务应用程序，从而方便用户后续使用，并提高了用户的体验度。

可选地，如图6所示，解析识别信息，获取并显示服务提供方的验证信息之后，该方法还包括：

s401、向服务器发送验证信息。

在本申请中，服务请求方终端解析识别信息，获取并显示服务提供方的验证信息之后，向服务器发送验证信息，其中，该验证信息可以是服务提供方的服务人员和/或服务工具的验证信息，具体的验证信息已在前面说明，再此不再赘述。

需要说明的是，也可以直接将识别信息发送给服务器，由服务器直接根据该识别信息获取验证信息，本申请不做限制。

s402、接收服务器根据验证信息发送的服务提供方的安全信息。

在本申请中，服务请求方终端接收服务器根据验证信息发送的服务提供方的安全信息，该安全信息用于指示服务提供方是否有不安全的因素，例如：高风险的司机、高风险的汽车等等，对于该安全信息可以是服务器根据验证信息与服务提供方的数据库进行匹配得到的，在此不做限定。

s403、若确认安全信息属于高风险，则推送服务不成功信息。

在本申请中，若确认安全信息属于高风险，则推送服务不成功信息，便于服务请求方识别出服务的安全隐患，从而保证服务请求方的人身安全。

可选地，如图7所示，在接收输入的服务内容信息之后，该方法还包括：

s501、向服务器发送服务内容信息。

在本申请中，服务请求方终端解析识别信息，获取并显示服务提供方的验证信息之后，向服务器发送服务内容信息，其中，该服务内容信息包括下述一项或多项：服务请求信息、服务支付方式和服务类型，具体的服务内容信息已在前面说明，再此不再赘述。

s502、接收服务器根据服务内容信息发送的服务安全信息，服务安全信息用于指示服务内容信息是否有安全隐患。

在本申请中，服务请求方终端接收服务器根据服务内容信息发送的服务提供方的服务安全信息，该安全信息用于指示服务提供方需要服务的内容是否有不安全的因素，例如：高风险的目的地、高风险的服务类型等等，对于该服务内容信息可以是服务器根据服务内容信息与服务请求方的服务数据库进行匹配得到的，在此不做限定。

s503、若服务安全信息指示有安全隐患，则推送服务不成功信息。

在本申请中，若确认服务安全信息属于高风险，则推送服务不成功信息，便于服务请求方识别出服务过程可能存在的安全隐患，从而保证服务请求方的人身安全。

第二方面，本申请实施例提供一种信息交互方法，应用于服务提供方终端，该服务提供方终端可以是智能手机、平板电脑等终端设备，如图8所示，本申请提供的信息交互方法，包括：

s601、显示服务提供方的识别信息。

在本申请中，服务提供方是可以为服务请求方提供服务的应用程序的使用者，例如，以打出租车为例，服务请求方为乘客时，对应的服务提供方可以为司机；以送快递为例，服务请求方为寄件人时，对应的服务提供方可以为送件人或者商家等，服务提供方的识别信息，该识别信息中携带有服务提供方的基本信息，如：服务提供人员的身份信息、服务提供人员在该应用程序app的识别码、服务工具的识别码、服务工具类型等，用于能够识别服务提供方即可，另外，该识别信息可以是二维码、条形码、数字码、动态口令、声音口令、动画等表现形式，但并不以此为限。

需要说明的是，服务提供方的识别信息，可以便于服务请求方获取服务提供方的标识，例如：乘客可以通过扫描二维码，获取到该司机的标识，该标识可以是司机在应用程序平台注册的账号、名称、身份证、驾驶证、车牌号、车型、终端标识等，在此不作限制，这个识别标识可以是二维码、条形码、数字码等，从而使得在大型集散场景中，方便了乘客与司机之间建立联系，提高了乘客乘车服务的体验度。

另外，服务提供方和服务请求方可以通过应用程序进行关联，服务请求方和服务提供方均可以在应用程序进行账号的注册，通过服务账号和/或服务信息等进行关联，例如：乘客和司机可以在滴滴、美团、支付宝等应用程序注册账号后，通过账号和/或乘车订单进行关联，从而使得服务提供方和服务请求方可以在任意一种终端上进行登录，获取相应的服务内容信息。

s602、接收根据识别信息发送的服务内容信息，识别信息用于指示服务提供方的验证信息。

在本申请中，接收根据识别信息发送的服务内容信息，该服务内容信息具体包括下述一项或多项：服务请求信息、服务支付方式、服务类型，例如：在乘车服务时，乘客输入的目的地、支付方式和服务类型等，其中，服务类型可以是出租车、快车、顺风车、代驾车和单车等，在快递服务时，寄件人输入的收件地址、支付方式和邮寄类型等，在此不作限定。

需要说明的是，服务请求方终端和服务提供方终端可以通过平台服务器交互，该服务请求方终端先将服务内容信息发送给服务器，服务器收到后将服务内容信息发送给对应的服务提供方终端，服务提供方终端的应用程序界面上可以显示服务内容信息便于服务提供方查看，具体显示方式在此不做限制。

本申请实施例提供的一种信息交互方法，服务提供方通过服务提供方终端显示服务提供方的识别信息，通过服务请求方终端解析该识别信息，并经过服务请求方验证通过后，从而使得服务请求方匹配到精准的服务提供方，并与之间建立连接，并接收服务请求方通过服务请求方终端输入的服务内容信息，便于服务提供方为服务请求方提供服务，由于服务请求方与服务提供方可以分别通过服务请求方终端和服务提供方终端确认识别信息的一致性，从而保证了服务请求方与服务提供方之间通过服务请求方终端和服务提供方终端进行服务交互过程的安全性。

可选地，显示服务提供方的识别信息，包括：

显示服务提供方的识别码，或者显示服务提供方的识别码和辅助验证信息。

在本申请中，服务提供方终端显示服务提供方的识别信息，该识别信息可以是服务提供方的识别码，即二维码、条形码等图形码，还可以是动态图形码，如：动画图形码、声音图形码等，例如：可以通过服务提供方终端显示服务提供方的二维码，主要用于服务请求方通过服务请求方终端获取该二维码，并经过服务请求方确认是否与服务提供方终端给出二维码一致，如果一致，则服务请求方可以与该服务提供方可以建立连接。该识别信息还可以包括辅助验证信息，该辅助验证信息可以是数字码、字母码等码文，还可以是动态口令、动画口令和声音口令等口令，例如：可以通过服务提供方终端显示服务提供方的二维码和数字码时，主要用于服务请求方通过服务请求方终端获取该二维码和数字码，并经过服务请求方确认是否与服务提供方终端给出二维码是否一致，如果一致，还可以通过服务请求方输入服务提供方给出的数字码，进行再次确认，从而可以防止误操作导致服务请求方和服务提供方建立错误的连接，使得服务请求方和服务提供方之间的连接更加可靠，对于上述图形码和辅助验证信息的表现形式，在此不作限定。

可选地，显示服务提供方的识别信息，包括：

显示服务提供方的识别信息，并向服务器发送服务通知，服务通知用于指示当前处于服务状态。

在本申请中，服务提供方终端显示服务提供方的识别信息时，会向服务器发送服务通知，该服务通知用于指示该服务提供方终端处于服务状态，例如：在乘车服务场景中，该服务应用程序既可以让司机线上接单，也可以让司机线下接单，但如果司机使用的终端已经显示二维码页面时，服务器能获知司机使用的终端处于服务状态，从而不再给服务提供方终端发送线上订单了。

可选地，在接收根据识别信息发送的服务内容信息之前，如图9所示，该方法还包括：

s701、接收服务器根据验证信息发送的服务请求方的安全信息。

在本申请中，服务提供方终端接收服务器根据验证信息发送的服务请求方的安全信息，该安全信息用于指示服务请求方是否有不安全的因素，例如：高风险的乘客、高风险的服务类型等等，对于该安全信息可以是服务器根据验证信息与服务请求方的数据库进行匹配得到的，在此不做限定。

s702、若确认安全信息属于高风险，则推送服务不成功信息。

在本申请中，若确认安全信息属于高风险，则推送服务不成功信息，便于服务请求方识别出服务的安全隐患，从而保证服务请求方的人身安全。

下面以线下派单为例进行对本申请提供的信息交互方法进行详细说明如下：

线下派单是指司机和乘客在线下已经见面，一对一地定向派单的匹配模式。它和当前主流的线上派单不一样，用户能基于线下集散场景的需要，选择最适合自己的司机。该线下集散场景可以是狂欢节、足球赛事、大型演唱会、机场、购物中心、火车站等场景。在这些场景下，常规的线上派单很难把合适的司机指派给乘客，司机接到订单后，很难在拥挤人群中找到乘客，为了解决这种复杂的“车找人”场景，以及司机和乘客已经见面的派单需求，需要一种新型的线下派单模式。现有的派单模式，例如：出租车线下派单模式是通过提供附近司机列表，用户手动筛选相对应的司机。但是，这种模式对于乘客的筛选成本较高，而且依赖于司机、乘客定位的准确度，不能很好地解决线下派单的问题。

如图10所示，本申请实施例提供一种信息交互方法，能够让司机和乘客在线下建立准确安全的连接，从而可以实现乘客和司机在进行乘车服务过程中信息交互的安全性，其中，线下乘车服务场景可以包括线下出租车场景、线下快车场景、线下单车场景和线下支付场景等，具体的交互过程如下：

s801、司机通过服务提供方终端进入到该乘车服务应用程序。

具体的，司机可以通过点击该乘车服务应用程序的图标、链接网址或第三方应用等进入到该乘车服务应用程序，该乘车服务应用程序例如可以是滴滴、支付宝、微信等。

s802、服务提供方终端获取该司机的用户类型。

具体的，该乘车服务应用程序可以根据该司机登录的账号获取该司机的用户类型，确认该乘客是新用户还是老用户，是否有开通线上收款功能，是否有开启摄像头功能等等。

s803、服务提供方终端根据该司机的用户类型，推送用户类型对应的指引信息。

具体的，服务提供方终端判断该司机属于哪种用户类型，如：新用户-没有线上收款功能，新用户-已有线上收款功能，老用户-未开通相机权限，老用户-开通相机权限等，会分别根据不同的用户类型，匹配该用户类型对应的指引信息，即不同的弹窗或者操作流程等等，例如：无线上收款功能，会弹出绑卡引导页面，在司机完成绑卡操作后，还可以弹出服务过程中的安全教育弹屏，用于司机学习，保证司机提供乘车服务的安全性。

s804、乘客通过服务请求方终端进入到该乘车服务应用程序。

具体的，乘客可以通过点击该乘车服务应用程序的图标、链接网址或第三方应用等进入到该乘车服务应用程序，该乘车服务应用程序例如可以是滴滴、支付宝、微信等。

s805、服务请求方终端获取该乘客的用户类型。

具体的，该乘车服务应用程序可以根据该乘客登录的账号获取该乘客的用户类型，确认该乘客是新用户还是老用户，是否有开通线上支付功能，是否有开启摄像头功能等等。

s806、服务请求方终端根据该乘客的用户类型，推送用户类型对应的指引信息。

具体的，服务请求方终端判断该乘客属于哪种用户类型，如：新用户-没有线上支付功能，新用户-已有线上支付功能，老用户-未开通相机权限，老用户-开通相机权限等，会分别根据不同的用户类型，匹配该用户类型对应的指引信息，即不同的弹窗或者操作流程等等，例如：无线上支付功能，会弹出绑卡引导页面，在乘客完成绑卡操作后，还可以弹出服务过程中的安全教育弹屏，用于乘客学习，保证乘客乘车的安全性。

s807、在乘客遇到合适的司机时，司机通过服务提供方终端生成并显示司机的二维码和8位数字码给乘客。

具体的，司机的二维码可以携带有司机和车辆的验证信息，例如：司机的头像和姓名，车辆的车牌号和车型等，8位数字码是辅助验证信息，用于乘客通过服务请求方终端扫描获取到司机的二维码时，可以通过该8位数字码进行校验。

需要说明的是，该二维码还可以携带该乘车服务应用程序的下载链接，可以在乘客的服务请求方终端没有安装该乘车服务应用程序时，通过扫描该二维码进入到应用商店，下载该乘车应用程序。

s808、服务提供方终端在显示司机的二维码时，会向服务器发送服务通知。

具体的，该服务通知用于指示该司机正处于服务状态，停止向该服务提供方终端发送线上的乘车服务订单，另外，当该服务提供方不在显示该司机的二维码时，也会向服务器发送服务通知，此时的服务通知用于指示司机处于乘车行程服务状态还是司机处于空闲的服务状态等，但并不以此为限。

s809、服务器根据服务通知，确定是否向服务提供方停止线上乘车服务订单的派送。

具体的，如果服务通知指示的是司机正处于线下乘车服务状态时，则停止线上乘车服务订单的派送，如果服务通知指示的是司机正处于空闲状态时，则可以派送乘车服务订单。

s810、服务请求方终端获取司机使用的服务提供方终端显示的二维码和8位数字码。

具体的，司机的二维码可以携带有司机和车辆的验证信息，例如：司机的头像和姓名，车辆的车牌号和车型等，8位数字码是辅助验证信息，用于乘客通过服务请求方终端扫描获取到司机的二维码时，可以查看司机使用的服务提供方终端显示的8位数字码进行校验。

需要说明的是，该8位数字码可以是直接从服务提供方终端获取的，也可以是乘客根据服务提供方终端显示的8位数字码输入到服务请求方终端的，另外，对于数字码的校验也可能存在，具体的错误情况进行如下说明：

1)司机服务提供方终端没有使用该乘车服务应用程序；

2)乘客输入的数字有误或者不存在；

3)当前网络存在故障；

4)反作弊限制；

5)基于安全屏蔽。

s811、服务请求方终端根据该二维码确认是否有安装乘车服务应用程序，若确认没有安装乘车服务应用程序，则执行步骤s812，确认有安装乘车服务应用程序，则执行步骤s813。

s812、服务请求方终端显示提示信息，该提示信息用于提示下载该乘车服务应用程序。

s813、服务请求方终端解析该二维码，获取并显示该司机的验证信息。

具体的，服务请求方终端获取到二维码后，会对该二维码进行解析，可以获取到司机的验证信息，并显示出来，该验证信息可以包括司机的头像和姓名，以及车辆的车牌号和车型等，便于乘客进行验证。

s814、服务请求方终端向服务器发送验证信息。

具体的，服务请求方终端向服务器发送验证信息，该验证信息可以是关于司机和/或车辆的验证信息，具体的验证信息已在前面说明，再此不在赘述。

s815、服务器根据验证信息生成该验证信息对应的安全信息。

具体的，服务器可以根据司机的头像、姓名等信息，车辆的车牌号和车型等信息，与预设的司机数据库和/或车辆数据库进行匹配，生成对应的安全信息，用于指示该司机和/或车辆是否有安全隐患。

s816、服务器向服务请求方终端发送安全信息。

s817、服务请求方终端根据该安全信息确认司机和/或车辆是否有安全隐患。

具体的，乘客通过服务请求方终端确认司机和/或车辆是否有安全隐患，例如：高风险的司机、高风险的汽车等等，若指示不安全，则执行步骤s818，若指示安全，则执行步骤s819，从而确保了乘客的乘车服务安全体验。

s818、服务请求方终端推送服务不成功信息。

具体的，如果识别到司机属于高风险司机，则服务请求方终端会显示服务失败的界面，用以指示乘客停止乘车服务。

s819、服务请求方终端接收乘客根据验证信息输入的乘车服务信息。

具体的，乘客确定显示的司机的验证信息与线下的司机和车辆的信息一致时，服务请求方终端会推送一个乘车服务界面，该乘车服务界面用于接收乘客输入的乘车目的地、支付方式等，确认支付方式、预估价格等乘车服务信息，在这个过程中，允许乘客根据自身的情况，进行相关项目的修改，直至最终显示的乘车服务信息经过乘客确认，其中，对于某些乘车服务信息内容也可以是不允许修改的，例如：不支持起点修改，不支持现金支付或线下支付等，具体可以根据乘车的实际场景来确定，并不以此为限。

s820、服务请求方终端向服务器发送乘车服务信息。

具体的，向服务器发送乘车服务信息，其中，该乘车服务信息可以包括目的地、在线支付和出租车等信息。

s821、服务器根据乘车服务信息生成服务安全信息。

具体的，服务器可以根据乘客输入的目的地、支付方式等信息，与预设的地图数据库和/或支付方式数据库进行匹配，生成对应的服务安全信息，用于指示该乘车服务是否有安全隐患。

s822、服务器向服务请求方终端发送服务安全信息。

s823、服务请求方终端根据服务安全信息确认乘客的乘车服务是否有安全隐患，若确认不安全，则执行步骤s824，若确认安全，则执行步骤s825。

具体的，乘客通过服务请求方终端确认目的地、支付方式是否有安全隐患，例如：高风险的目的地、高风险的支付方式等等，若指示不安全，则执行步骤s824，若指示安全，则执行步骤s825，从而确保了乘客的乘车服务安全体验。

s824、服务请求方终端推送服务不成功信息。

具体的，如果识别到目的地属于高风险目的地，则服务请求方终端会显示服务失败的界面，用以指示乘客停止乘车服务。

s825、服务请求方终端发送乘客的乘车服务信息给司机。

具体的，乘客与司机建立了准确安全的连接后，乘客进行乘车服务时，会将上述步骤s819输入的目的地、支付方式等乘车服务信息发送给司机，便于司机根据乘车服务信息开始行程。

需要说明的是，服务请求方终端可以将乘客服务信息发送给服务器，再由服务器发送给服务提供方终端，也可以直接发送给服务提供方终端，在此不作限定。

s826、司机通过服务提供方终端接收乘客输入的乘车服务信息。

具体的，司机可以通过服务提供方终端接收到乘客输入的乘车服务信息。

需要说明的是，乘客和司机可以通过应用程序进行关联，乘客和司机均可以在应用程序进行账号的注册，通过账号和/或乘车订单进行关联，从而使得司机和乘客可以在任意一种终端上进行登录，获取相应的乘车服务信息。另外，上述司机通过服务提供方终端执行的步骤s801、s802、s803和乘客通过服务请求方终端执行的步骤s804、s805、s806是可以同时进行或者有前后顺序的，具体可以根据乘客和司机的操作习惯来，另外，对于步骤s811、s812、s814、s815、s816、s817、s818、s820、s821、s822、s823、s824均为可选步骤，可以根据实际的应用场景来执行，在此不做限制。

本申请实施例提供一种信息交互装置，应用于服务请求方终端，该信息交互装置实现的功能对应上述方法执行的步骤。该装置可以理解为上述服务器，或服务器的处理器，也可以理解为独立于上述服务器或处理器之外的在服务器控制下实现本申请功能的组件。图11示出了本申请实施例所提供的一种信息交互装置的结构示意图，如图11所示，信息交互装置可以包括：

第一获取模块11，用于获取服务提供方的识别信息；解析模块12，用于解析识别信息，获取并显示服务提供方的验证信息；第一接收模块13，用于接收服务请求方根据验证信息输入的服务内容信息；第一发送模块14，用于发送服务内容信息给服务提供方。

可选地，第一获取模块11用于获取服务提供方的识别信息，包括：

获取服务提供方的识别码，或者获取服务提供方的识别码和辅助验证信息。

可选地，如图12所示，该装置还包括：

验证模块15，用于验证辅助验证信息是否与预设的辅助验证信息一致；相应地，解析模块12用于解析识别信息，获取并显示服务提供方的验证信息，包括：

若辅助验证信息与预设的辅助验证信息一致，则解析识别码，获取并显示服务提供方的验证信息。

可选地，服务提供方的验证信息包括：服务提供方的服务人员和/或服务工具的验证信息。

可选地，服务内容信息包括下述一项或多项：服务请求信息、服务支付方式、服务类型。

可选地，如图13所示，该装置还包括：第二获取模块16和第一推送模块17；在第一获取模块11获取服务提供方的识别信息之前，第二获取模块16用于获取服务请求方的类型；第一推送模块17用于根据服务请求方的类型，推送服务请求方的类型对应的指引信息。

可选地，如图14所示，该装置还包括：识别模块18和提示模块19；在第一获取模块11获取服务提供方的识别信息之后，识别模块18用于根据识别信息确认是否安装识别信息对应的服务应用程序；提示模块19用于若确认未安装，则显示提示信息，提示信息用于提示下载服务应用程序。

可选地，如图15所示，该装置还包括：第二发送模块20、第二接收模块21和第二推送模块22；在解析模块12解析识别信息，获取并显示服务提供方的验证信息之后，第二发送模块20用于向服务器发送验证信息；第二接收模块21用于接收服务器根据验证信息发送的服务提供方的安全信息；第二推送模块22用于若确认安全信息属于高风险，则推送服务不成功信息。

可选地，如图16所示，该装置还包括：第三发送模块23、第三接收模块24和第三推送模块25；在第一接收模块13接收输入的服务内容信息之后，第三发送模块23用于向服务器发送服务内容信息；第三接收模块24用于接收服务器根据服务内容信息发送的服务安全信息，服务安全信息用于指示服务内容信息是否有安全隐患；第三推送模块25用于若服务安全信息指示有安全隐患，则推送服务不成功信息。

本申请还实施例提供一种信息交互装置，应用于服务提供方终端。如图17所示，该装置包括：

显示模块31，用于显示服务提供方的识别信息；第一接收模块32，用于接收根据识别信息发送的服务内容信息，识别信息用于指示服务提供方的验证信息。

可选地，显示模块31用于显示服务提供方的识别信息，包括：

显示服务提供方的识别码，或者显示服务提供方的识别码和辅助验证信息。

可选地，如图18所示，该装置还包括：

通知模块33，用于显示模块31显示服务提供方的识别信息时，向服务器发送服务通知，服务通知用于指示当前处于服务状态。

可选地，如图19所示，该装置还包括：第二接收模块34和推送模块35；在第一接收模块32接收根据识别信息发送的服务内容信息之前，第二接收模块34用于接收服务器根据验证信息发送的服务请求方的安全信息；推送模块35用于若确认安全信息属于高风险，则推送服务不成功信息。

上述模块可以经由有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合线缆等，或其任意组合。无线连接可以包括通过lan、wan、蓝牙、zigbee、或nfc等形式的连接，或其任意组合。两个或更多个模块可以组合为单个模块，并且任何一个模块可以分成两个或更多个单元。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

需要说明的是，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(applicationspecificintegratedcircuit，简称asic)，或，一个或多个微处理器(digitalsingnalprocessor，简称dsp)，或，一个或者多个现场可编程门阵列(fieldprogrammablegatearray，简称fpga)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(centralprocessingunit，简称cpu)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，简称soc)的形式实现。

图20示出了本申请实施例所提供的一种电子设备的结构示意图，如图20所示，该装置包括：处理器41和存储器42，其中：

存储器42用于存储程序，处理器41调用存储器42存储的程序，以执行上述方法实施例。具体实现方式和技术效果类似，这里不再赘述。

可选地，本申请还提供一种程序产品，例如计算机可读存储介质，包括程序，该程序在被处理器执行时用于执行上述方法实施例。

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