CN105741152A - 一种基于打车的身份信息的验证方法和装置 - Google Patents

Abstract

本申请实施例提供了一种基于打车的身份信息的验证方法和装置，所述方法包括：当接收到第一客户端发送的第一打车请求时，获取第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号；将订单号返回给所述第一客户端；接收第一客户端发送的第一身份信息的验证请求；采用当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号进行验证，获得第一身份信息的验证结果；将所述第一身份信息的验证结果返回所述第一客户端。本申请实施例降低了时间和人力成本，提高了身份信息验证的准确性。

Description

一种基于打车的身份信息的验证方法和装置

技术领域

本申请涉及交通技术领域，特别是涉及一种基于打车的身份信息的验证方法和一种基于打车的身份信息的验证装置。

背景技术

近年来，随着经济的快速发展和人们收入水平的不断提升，越来越多的人选择出租车代步出行。

目前市面上乘客经常使用打车程序呼叫出租车，出租车司机接收到呼叫后便去约定的地方搭乘乘客。

由于是通过打车程序呼叫出租车，出租车司机与乘客并未直接会面，因此在到达搭乘地点时，出租司机需要确认现场中哪个人呼叫了其出租车，

通常，出租车司机只能口头询问是否某人呼叫了其出租车。

这种口头询问的方式往往会带来许多弊端，例如，在繁忙的交通路口，口头询问操作不够便利，可能需要询问多人，而每次询问可能需要有2-3次的来回交互，时间和人力成本很高；如果有某一地段有多个人，可能存在被冒充原乘客上车的风险，如果碰巧多人使用叫车程序呼叫出租车，而他们又位于附近，则确认乘客的操作就十分麻烦了。

因此，目前需要本领域技术人员迫切解决的一个技术问题就是：如何提出一种基于打车的身份信息的验证机制，以提高身份信息验证准确性和效率，降低时间和人力成本，避免冒充的风险。

发明内容

本申请实施例所要解决的技术问题是提供一种基于打车的身份信息的验证方法，以提高身份信息验证准确性和效率，降低时间和人力成本，避免冒充的风险。

相应的，本申请实施例还提供了一种基于打车的身份信息的验证装置，以提高身份信息验证准确性和效率，降低时间和人力成本，避免冒充的风险。

为了解决上述问题，本申请公开了一种基于打车的身份信息的验证方法，包括：

当接收到第一客户端发送的第一打车请求时，获取第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号；所述订单号在所述第一客户端与所述目标第二客户端匹配成功时生成；

将所述订单号返回给所述第一客户端；

接收所述第一客户端发送的第一身份信息的验证请求；所述验证请求中包括第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号；

采用当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号进行验证，获得第一身份信息的验证结果；

将所述第一身份信息的验证结果返回所述第一客户端。

优选地，所述获取第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号的步骤包括：

根据所述第一打车请求生成确定匹配的目标第二客户端；

针对所述第一客户端与所述目标第二客户端生成订单号；

从所述第一打车请求中提取第一客户端对应的第一身份信息；

查询所述目标第二客户端对应的第二身份信息。

优选地，所述根据所述第一打车请求生成确定匹配的目标第二客户端的步骤包括：

从所述第一打车请求中提取所述第一客户端所在的呼叫地点和打车信息；

基于所述呼叫地点确定寻车范围；

采用所述呼叫地点和/或所述打车信息生成第二打车请求；

将所述第二打车请求发送至在所述寻车范围内的一个或多个第二客户端；

当接收到所述第二客户端针对所述第二打车请求返回的确认指示时，确定所述第二客户端为目标第二客户端。

优选地，当前接收的目标第二客户端的第二用户信息通过扫描图形标识符获得。

优选地，所述图形标识符包括二维码。

优选地，所述订单号中包括目标第二客户端对应的第二身份信息；

当前接收的订单号为所述第一客户端根据扫描获得的目标第二客户端对应的第二身份信息筛选出的，最近的订单号。

优选地，所述采用当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号进行验证，获得第一身份信息认的证结果的步骤包括：

在当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号匹配成功时，获得第一身份信息通过验证的验证结果；

在当前接收的第一身份信息、第二身份信息和订单号，与在先获取的第一身份信息、第二身份信息和订单号至少一项匹配失败时，获得第一身份信息未通过验证的验证结果。

优选地，所述将所述第一身份信息的验证结果返回所述第一客户端的步骤包括：

将所述第一身份信息通过验证的验证结果返回所述第一客户端；

或者，

将所述第一身份信息未通过验证的验证结果返回所述第一客户端。

本申请实施例还公开了一种基于打车的身份信息的验证装置，包括：

登记信息获取模块，用于在接收到第一客户端发送的第一打车请求时，获取第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号；所述订单号在所述第一客户端与所述目标第二客户端匹配成功时生成；

订单号返回模块，用于将所述订单号返回给所述第一客户端；

验证请求接收模块，用于接收所述第一客户端发送的第一身份信息的验证请求；所述验证请求中包括第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号；

身份信息验证模块，用于采用当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号进行验证，获得第一身份信息的验证结果；

验证结果返回模块，用于将所述第一身份信息的验证结果返回所述第一客户端。

优选地，所述登记信息获取模块包括：

目标确定子模块，用于根据所述第一打车请求生成确定匹配的目标第二客户端；

订单号生成子模块，用于针对所述第一客户端与所述目标第二客户端生成订单号；

身份信息提取子模块，用于从所述第一打车请求中提取第一客户端对应的第一身份信息；

身份信息查询子模块，用于查询所述目标第二客户端对应的第二身份信息。

优选地，所述目标确定子模块包括：

提取子模块，用于从所述第一打车请求中提取所述第一客户端所在的呼叫地点和打车信息；

第一确定子模块，用于基于所述呼叫地点确定寻车范围；

生成子模块，用于采用所述呼叫地点和/或所述打车信息生成第二打车请求；

发送子模块，用于将所述第二打车请求发送至在所述寻车范围内的一个或多个第二客户端；

第二确定子模块，用于在接收到所述第二客户端针对所述第二打车请求返回的确认指示时，确定所述第二客户端为目标第二客户端。

优选地，当前接收的目标第二客户端的第二用户信息通过扫描图形标识符获得。

优选地，所述图形标识符包括二维码。

优选地，所述订单号中包括目标第二客户端对应的第二身份信息；

当前接收的订单号为所述第一客户端根据扫描获得的目标第二客户端对应的第二身份信息筛选出的，最近的订单号。

优选地，所述身份信息验证模块包括：

第一获得子模块，用于在当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号匹配成功时，获得第一身份信息通过验证的验证结果；

第二获得子模块，用于在当前接收的第一身份信息、第二身份信息和订单号，与在先获取的第一身份信息、第二身份信息和订单号至少一项匹配失败时，获得第一身份信息未通过验证的验证结果。

优选地，所述验证结果返回模块包括：

第一返回子模块，用于将所述第一身份信息通过验证的验证结果返回所述第一客户端；

或者，

第二返回子模块，用于将所述第一身份信息未通过验证的验证结果返回所述第一客户端。

与现有技术相比，本申请实施例包括以下优点：

本申请实施例在接收到第一客户端发送的第一打车请求时，获取第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号，并返回订单号，在接收第一客户端发送的身份信息的验证请求，采用当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号进行验证，获得第一身份信息的验证结果，并将第一身份信息的验证结果返回第一客户端，第二客户端所属的用户无需在现场采用口头询问的方式复确认用户身份，降低了时间和人力成本，提高了身份信息验证的准确性，避免了冒充的风险，同时，身份信息的验证操作简便，大大提高了身份信息的验证效率。

附图说明

图1是本申请的一种基于打车的身份信息的验证方法实施例的步骤流程图；

图2是本申请的一种基于打车的身份信息的验证装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

参照图1，示出了本申请的一种基于打车的身份信息的验证方法实施例的步骤流程图，具体可以包括如下步骤：

步骤101，当接收到第一客户端发送的第一打车请求时，获取第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号；所述订单号在所述第一客户端与所述目标第二客户端匹配成功时生成；

需要说明的是，本申请实施例可以应用于服务器(如云服务器)中，该服务器可以与一个或多个电子设备通过网络连接，该电子设备具体可以包括手机、PDA(PersonalDigitalAssistant，个人数字助理)、膝上型计算机、掌上电脑等等，本申请实施例对此不加以限制。

这些电子设备可以支持包括Windows、Android(安卓)、IOS、WindowsPhone等操作系统，通常可以运行通过语音、键盘(包括物理键盘、虚拟键盘)等方式进行输入、显示电子地图等功能的客户端，例如第一客户端和第二客户端。

其中，第一客户端可以由乘客角色的用户登录账号，第二客户端可以由司机角色的用户登录账号。

当乘客角色的用户需要打车服务时，可以通过语音输入、文字输入等方式触发第一打车请求。该第一打车请求可以是指乘客角色的用户发出的呼叫汽车(例如，出租车)提供汽车搭乘服务的指示，俗称打车。

在具体实现中，乘客角色的用户可以通过输入一段语言(如“我在中山一路，想去黄埔大道”)来触发第一打车请求，或者，输入一段文字(如搭乘地点为“中山一路”，目的地点为“黄埔大道”)，或者，输入一段视频等方式来触发第一打车请求，等等。

在本申请的一种优选实施例中，步骤101可以包括如下子步骤：

子步骤S11，根据所述第一打车请求生成确定匹配的目标第二客户端；

当服务器接收到乘客角色的用户发出的语音或文字等信息时，就相当于接收到了呼叫汽车(例如出租车)的指示，则可以寻找合适的司机角色的用户，以提供汽车搭乘服务。

在本申请的一种优选实施例中，子步骤S11进一步可以包括如下子步骤：

子步骤S111，从所述第一打车请求中提取所述第一客户端所在的呼叫地点和打车信息；

在本申请实施例中，第一打车请求可以携带第一客户端在发出第一打车请求时所在的呼叫地点。由于手机等电子设备一般为私人物品，通常只会有一名用户随身携带并使用，因此，第一客户端所在的呼叫地点可以表征乘客角色的用户发出第一打车请求所在的位置。

在实际应用中，该呼叫地点可以通过卫星定位、基站定位等方式获取。

其中，卫星定位的方式可以将电子设备的位置信号发送到定位后台来进行定位。目前可使用的卫星定位系统包括GPS、GLONASS、北斗系统、Galileo系统等等。

基站定位方式可以是利用通信运营商(如移动运营商、联通运营商、电信运营商等)的基站对电子设备的距离的测算距离来确定电子设备的位置。

以GPS为例，所获得的GPS数据GPRMC的格式示例可以如下：

$GPRMC,<1>,<2>,<3>,<4>,<5>,<6>,<7>,<8>,<9>,<10>,<11>,<12>；

其中，字段<1>为标准定位时间(UTCtime)，其格式可以为：时时分分秒秒.秒秒秒(hhmmss.sss)；

字段<2>为定位状态，包括A＝数据可用，V＝数据不可用；

字段<3>为纬度，其格式可以为：度度分分.分分分分(ddmm.mmmm)；

字段<4>为纬度区分，包括北半球(N)或南半球(S)；

字段<5>为经度，其格式可以为：度度分分.分分分分；

字段<6>为经度区分，包括东(E)半球或西(W)半球；

字段<7>为相对位移速度，包括0.0至1851.8knots；

字段<8>为相对位移方向，包括000.0至359.9度；

字段<9>为日期，其格式可以为：日日月月年年(ddmmyy)；

字段<10>为磁偏角，包括000.0°～180.0°；

字段<11>为磁偏角方向，包括E(东)或W(西)；

字段<12>为Checksum(检查位)。

在示例中，通过纬度、纬度区分、经度和经度区分可以确定呼叫地点。

此外，第一打车请求中也可以包括打车信息，该打车信息可以为记录乘客角色的用户所需的汽车搭乘服务的信息，具体可以包括搭乘地点、目的地点、预约搭乘的时间、小费等等。

需要说明的是，搭乘地点可以默认为呼叫地点，也可以为与呼叫地点不同的地点，例如，乘客角色的用户指定在某个地点搭乘汽车(例如，出租车)，本申请实施例对此不加以限制。

子步骤S112，基于所述呼叫地点确定寻车范围；

在本申请实施例的一个示例中，可以以该呼叫地点为圆心，指定距离(例如，2千米、3千米等等)为半径，确定圆形的寻车范围。

当然，上述寻车范围只是作为示例，在实施本申请实施例时，可以根据实际情况设置其他寻车范围，例如，可以以该呼叫地点为中心，确定矩形、三角形、棱形等形状的寻车范围，也可以在该呼叫地点的前方、后方、左侧、右侧等方位确定寻车范围，等等，本申请实施例对此不加以限制。另外，除了上述寻车范围外，本领域技术人员还可以根据实际需要采用其它寻车范围，本申请实施例对此也不加以限制。

子步骤S113，采用所述呼叫地点和/或所述打车信息生成第二打车请求；

在实际应用中，服务器可以将呼叫地点、乘客角色的用户所需的汽车搭乘服务的信息，例如搭乘地点、目的地点、预约搭乘的时间、小费等等，按照第二客户端的格式要求进行整理，以生成第二打车请求。该第一打车请求可以是指服务器发出的某个乘客角色的用户呼叫汽车(例如，出租车)提供汽车搭乘服务的指示。

例如，乘客角色的用户(用户ID为10000)在中山一路(呼叫位置)通过输入一段语音“我在中山一路，想去黄埔大道”触发了第一打车请求，并提供10元小费，则服务器接收到该第一打车请求时，提取该呼叫位置、语音和小费数额生成第二打车请求，如“用户10000就在附近，他在中山一路等待打车”，并附带该语音和小费数额。

子步骤S114，将所述第二打车请求发送至在所述寻车范围内的一个或多个第二客户端；

在实际应用中，第二客户端所在的电子设备可以通过卫星定位、基站定位等方式获取其所在的位置，间隔相同的时间(例如，30秒)上传给服务器，服务器可以使用一个线程维护第二客户端的位置。

由于手机等电子设备一般为私人物品，通常只会有一名用户随身携带并使用，并且，司机角色的用户大多数时间在汽车(如出租车)内，因此，第二客户端所在的位置可以表征司机角色的用户以及汽车所在的位置。

服务器将第二打车请求发送至在寻车范围内的一个或多个第二客户端，可以使得司机角色的用户快速到达搭乘地点，让乘客角色的用户获得快捷的汽车搭乘服务。

子步骤S115，当接收到所述第二客户端针对所述第二打车请求返回的确认指示时，确定所述第二客户端为目标第二客户端。

在具体实现中，乘客角色的用户请求汽车搭乘服务，一般可以称其为订单。由于该订单一般只能有一个司机角色的用户接收，则服务器将第二打车请求发送至在寻车范围内的一个或多个第二客户端，司机角色的用户需要按照一定的规则接收该订单。一般可以以最先确认第二打车请求的第二客户端接收订单，即俗称抢单。

当第二客户端针对第二打车请求进行确认时，可以表示司机角色的用户接单成功，汽车搭乘服务的约定成立，即由第一客户端所属的用户请求汽车搭乘服务，由目标第二客户端所属的用户提供汽车搭乘服务。

子步骤S12，针对所述第一客户端与所述目标第二客户端生成订单号；

当订单成立时，服务器可以对这笔订单生成唯一标识该订单的订单号。

在本申请实施例的一个示例中，订单号可以包括时间、第二客户端对应的第二用户信息和N个信息位(N为正整数)等等。

其中，时间可以包括日期和时间戳，日期的格式可以年月日，例如，日期20141022可以表示2014年10月22日，时间戳的格式可以为时分秒，例如，时间戳152334可以表示15点23分34秒。由于订单是每天增加的，而且数量十分庞大，因此加上时间要素可以避免订单号被用完。

第二用户信息可以为够代表一个唯一确定的司机角色的用户的信息，例如手机号码、车牌号等等，可以用于标识该订单与司机角色的用户关联。

信息位可以为随机获得的字符，可以用于避免订单号被用完。

子步骤S13，从所述第一打车请求中提取第一客户端对应的第一身份信息；

第一用户信息可以为够代表一个唯一确定的乘客角色的用户的信息，例如手机号码、身份证等等。

以手机号码为例，在Android(安卓)操作系统的电子设备(如手机)中，可以调用getPhoneNumber方法返回当前电子设备(如手机)的手机号码。

子步骤S14，查询所述目标第二客户端对应的第二身份信息。

应用本申请实施例，司机角色的用户在注册账号时，可以录入了相关的第二用户信息，例如，出租车公司、准驾证号、车牌号、姓名、手机号码等等。

服务器可以根据在目标第二客户端登陆的账号，查询到该账号关联的第二用户信息。

步骤102，将所述订单号返回给所述第一客户端；

服务器可以分别发送消息给第一客户端和第二客户端，分别告知乘客角色的用户和司机角色的用户订单成立。其中，该消息可以包括订单号。

步骤103，接收所述第一客户端发送的第一身份信息的验证请求；所述验证请求中包括第一客户端对应的第一身份信息、第二身份信息和订单号；

当订单成立时，司机角色的用户遵守约定，驾驶汽车(如出租车)前往约定的搭乘地点。当司机角色的用户到达搭乘地点时，需要对乘客角色的用户进行身份信息的验证。

第一客户端可以触发第一身份信息的验证请求，请求服务器对第一身份信息进行验证，以确定当前用户是否可以获得当前司机提供的汽车搭乘服务。

在本申请实施例的一个优选示例中，当前接收目标第二客户端对应的第二用户信息通过扫描图形标识符获得。该图形标识符可以用某种特定的几何图形按一定规律在平面(二维方向上)分布的图形记录数据符号信息，具体可以包括二维码(Two-dimensionalcode)、条形码(barcode)等等。

应用本申请实施例，可以预先获取第二身份信息(例如，司机角色的用户的手机号码)，将该第二身份信息制作为图形标识符。

该图形标识符可以在汽车的相应位置(例如，车窗、车门)用纸、电子屏幕等方式展示该二维码，以方便乘客角色的用户扫描获取第二身份信息。

由于第一客户端已经获得了在先的订单号，第一用户信息可以在本地提取，乘客角色的用户在通过第一客户端扫描该图形标识符，解码获得第二用户信息后，可以触发身份信息的验证请求。

需要说明的是，所述订单号中包括目标第二客户端对应的第二身份信息；

当前接收的订单号可以为所述第一客户端根据扫描获得的目标第二客户端对应的第二身份信息筛选出的，最近的订单号。

具体而言，由于订单号中包括第二客户端对应的第二身份信息和时间，第一客户端获得第二用户信息后，可以筛选出具有该第二用户信息的订单号，提取时间最大(即距离现在最近)的订单号发送到服务器。

由于一个乘客角色的用户可能有多个订单，比如2小时前发出打车请求生成了一个订单号了，但是没有上车，这个旧的订单号可能没有失效，当前又重新发出了新的打车请求生成一个新的订单号，而这两个订单可能同时有效。

由于同一时间的两笔订单都有同一个第二客户端接受一般是不可能的，因此，本申请实施例可以通过订单号中的第二用户信息对订单号进行区分，以防止订单号的串用。

当然，上述通过扫描图形标识符获取第二身份信息只是作为示例，本申请实施例还可以采用其他方式获取第二身份信息，例如直接输入第二身份信息(如车牌号)等等，本申请实施例对此不加以限制。

步骤104，采用当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号进行验证，获得第一身份信息的验证结果；

验证，可以是指把一个现场采集到的信息与一个己经登记的信息进行一对一的比对，来确认身份的过程。

其中，现场采集的信息可以为当前接收的第一身份信息、第二身份信息和订单号，即在验证场景(步骤103)中验证请求所携带的第一客户端对应的第一身份信息、第二身份信息和订单号。

已经登记的信息可以为在先获取的第一身份信息、第二身份信息和订单号，即在订单场景(步骤101)中所获取的第一身份信息、第二身份信息和订单号。

一般情况下，乘客角色的用户只允许同时下一笔订单请求汽车搭乘服务，不允许同时下两笔订单请求不同的汽车搭乘服务，但是也可能存在两笔订单同时有效的情形。因此，服务器在接收到验证请求时，可以提取该乘客角色的用户的账号关联的，订单号中包括第二用户信息的最近的一笔订单进行验证。

订单号中具有第二用户信息，而第一客户端有直接上传第二用户信息，可以对订单号进行筛选。订单号中也可以具有时间要素，与当前时间最近的时间要素所属的订单号，为最近的一笔订单。当然，若订单号中没有时间要素，则可以采用订单号生成的时间提取最近的一笔订单，本申请实施例对此不加以限制。

在本申请的一种优选实施例中，步骤104可以包括如下子步骤：

子步骤S21，在当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号匹配成功时，获得第一身份信息通过验证的验证结果；

在本申请实施例中，当前接收的第一身份信息与在先获取的第一身份信息、当前接收的第二身份信息与在先获取的第二身份信息、当前接收的订单号与在先获取的订单号分别相同时，可以认为匹配成功，第一身份信息通过身份验证。

子步骤S22，在当前接收的第一身份信息、第二身份信息和订单号，与在先获取的第一身份信息、第二身份信息和订单号至少一项匹配失败时，获得第一身份信息未通过验证的验证结果。

在本申请实施例中，当前接收的第一身份信息与在先获取的第一身份信息、当前接收的第二身份信息与在先获取的第二身份信息、当前接收的订单号与在先获取的订单号至少有一项不相同时，可以认为匹配识别，第一身份信息未通过身份验证。

步骤105，将所述第一身份信息的验证结果返回所述第一客户端。

服务器将第一身份信息的验证结果返回第一客户端，第一客户端所属的用户可以向第二客户端所属的用户出示该验证结果，第二客户端所属的用户可以依此判断当前的用户是否与下订单的用户相同。

在本申请的一种优选实施例中，步骤105可以包括如下子步骤：

子步骤S31，将所述第一身份信息通过验证的验证结果返回所述第一客户端；

在本申请实施例中，若第一身份信息通过验证，则可以表明当前的用户与下订单的用户相同，当前的用户可以获得第二客户端所属的用户提供汽车搭乘服务。

或者，

子步骤S32，将所述第一身份信息未通过验证的验证结果返回所述第一客户端。

在本申请实施例中，若第一身份信息未通过验证，则可以表明当前的用户与下订单的用户不相同，当前的用户不可以获得第二客户端所属的用户提供汽车搭乘服务。

本申请实施例在接收到第一客户端发送的第一打车请求时，获取第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号，并返回订单号，在接收第一客户端发送的身份信息的验证请求，采用当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号进行验证，获得第一身份信息的验证结果，并将第一身份信息的验证结果返回第一客户端，第二客户端所属的用户无需在现场采用口头询问的方式复确认用户身份，降低了时间和人力成本，提高了身份信息验证的准确性，避免了冒充的风险，同时，身份信息的验证操作简便，大大提高了身份信息的验证效率。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图2，示出了本申请一种基于打车的身份信息的验证装置实施例的结构框图，具体可以包括如下模块：

登记信息获取模块201，用于在接收到第一客户端发送的第一打车请求时，获取第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号；所述订单号在所述第一客户端与所述目标第二客户端匹配成功时生成；

订单号返回模块202，用于将所述订单号返回给所述第一客户端；

验证请求接收模块203，用于接收所述第一客户端发送的第一身份信息的验证请求；所述验证请求中包括第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号；

身份信息验证模块204，用于采用当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号进行验证，获得第一身份信息的验证结果；

验证结果返回模块205，用于将所述第一身份信息的验证结果返回所述第一客户端。

在本申请的一种优选实施例中，所述登记信息获取模块201可以包括如下子模块：

目标确定子模块，用于根据所述第一打车请求生成确定匹配的目标第二客户端；

订单号生成子模块，用于针对所述第一客户端与所述目标第二客户端生成订单号；

身份信息提取子模块，用于从所述第一打车请求中提取第一客户端对应的第一身份信息；

身份信息查询子模块，用于查询所述目标第二客户端对应的第二身份信息。

在本申请的一种优选实施例中，所述目标确定子模块进一步可以包括如下子模块：

提取子模块，用于从所述第一打车请求中提取所述第一客户端所在的呼叫地点和打车信息；

第一确定子模块，用于基于所述呼叫地点确定寻车范围；

生成子模块，用于采用所述呼叫地点和/或所述打车信息生成第二打车请求；

发送子模块，用于将所述第二打车请求发送至在所述寻车范围内的一个或多个第二客户端；

第二确定子模块，用于在接收到所述第二客户端针对所述第二打车请求返回的确认指示时，确定所述第二客户端为目标第二客户端。

在本申请实施例的一种优选示例中，当前接收的目标第二客户端的第二用户信息通过扫描图形标识符获得。

在本示例中，所述图形标识符可以包括二维码。

在本申请实施例的一种优选示例中，所述订单号中可以包括目标第二客户端对应的第二身份信息；

当前接收的订单号可以为所述第一客户端根据扫描获得的目标第二客户端对应的第二身份信息筛选出的，最近的订单号。

在本申请的一种优选实施例中，所述身份信息验证模块204可以包括如下子模块：

第一获得子模块，用于在当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号匹配成功时，获得第一身份信息通过验证的验证结果；

第二获得子模块，用于在当前接收的第一身份信息、第二身份信息和订单号，与在先获取的第一身份信息、第二身份信息和订单号至少一项匹配失败时，获得第一身份信息未通过验证的验证结果。

在本申请的一种优选实施例中，所述验证结果返回模块205可以包括如下子模块：

第一返回子模块，用于将所述第一身份信息通过验证的验证结果返回所述第一客户端；

或者，

第二返回子模块，用于将所述第一身份信息未通过验证的验证结果返回所述第一客户端。

本申请实施例可以应用于服务器(如云服务器)中，对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种基于打车的身份信息的验证方法和一种基于打车的身份信息的验证装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (16)

1.一种基于打车的身份信息的验证方法，其特征在于，包括：

当接收到第一客户端发送的第一打车请求时，获取第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号；所述订单号在所述第一客户端与所述目标第二客户端匹配成功时生成；

将所述订单号返回给所述第一客户端；

接收所述第一客户端发送的第一身份信息的验证请求；所述验证请求中包括第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号；

采用当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号进行验证，获得第一身份信息的验证结果；

将所述第一身份信息的验证结果返回所述第一客户端。

2.根据权利要求1所述的方法，其特征在于，所述获取第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号的步骤包括：

根据所述第一打车请求生成确定匹配的目标第二客户端；

针对所述第一客户端与所述目标第二客户端生成订单号；

从所述第一打车请求中提取第一客户端对应的第一身份信息；

查询所述目标第二客户端对应的第二身份信息。

3.根据权利要求2所述的方法，其特征在于，所述根据所述第一打车请求生成确定匹配的目标第二客户端的步骤包括：

从所述第一打车请求中提取所述第一客户端所在的呼叫地点和打车信息；

基于所述呼叫地点确定寻车范围；

采用所述呼叫地点和/或所述打车信息生成第二打车请求；

将所述第二打车请求发送至在所述寻车范围内的一个或多个第二客户端；

当接收到所述第二客户端针对所述第二打车请求返回的确认指示时，确定所述第二客户端为目标第二客户端。

4.根据权利要求1或2或3所述的方法，其特征在于，当前接收的目标第二客户端的第二用户信息通过扫描图形标识符获得。

5.根据权利要求4所述的方法，其特征在于，所述图形标识符包括二维码。

6.根据权利要求4所述的方法，其特征在于，所述订单号中包括目标第二客户端对应的第二身份信息；

当前接收的订单号为所述第一客户端根据扫描获得的目标第二客户端对应的第二身份信息筛选出的，最近的订单号。

7.根据权利要求1或2或3或4或5所述的方法，其特征在于，所述采用当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号进行验证，获得第一身份信息认的证结果的步骤包括：

在当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号匹配成功时，获得第一身份信息通过验证的验证结果；

在当前接收的第一身份信息、第二身份信息和订单号，与在先获取的第一身份信息、第二身份信息和订单号至少一项匹配失败时，获得第一身份信息未通过验证的验证结果。

8.根据权利要求7所述的方法，其特征在于，所述将所述第一身份信息的验证结果返回所述第一客户端的步骤包括：

将所述第一身份信息通过验证的验证结果返回所述第一客户端；

或者，

将所述第一身份信息未通过验证的验证结果返回所述第一客户端。

9.一种基于打车的身份信息的验证装置，其特征在于，包括：

登记信息获取模块，用于在接收到第一客户端发送的第一打车请求时，获取第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号；所述订单号在所述第一客户端与所述目标第二客户端匹配成功时生成；

订单号返回模块，用于将所述订单号返回给所述第一客户端；

验证请求接收模块，用于接收所述第一客户端发送的第一身份信息的验证请求；所述验证请求中包括第一客户端对应的第一身份信息、目标第二客户端对应的第二身份信息和订单号；

身份信息验证模块，用于采用当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号进行验证，获得第一身份信息的验证结果；

验证结果返回模块，用于将所述第一身份信息的验证结果返回所述第一客户端。

10.根据权利要求9所述的装置，其特征在于，所述登记信息获取模块包括：

目标确定子模块，用于根据所述第一打车请求生成确定匹配的目标第二客户端；

订单号生成子模块，用于针对所述第一客户端与所述目标第二客户端生成订单号；

身份信息提取子模块，用于从所述第一打车请求中提取第一客户端对应的第一身份信息；

身份信息查询子模块，用于查询所述目标第二客户端对应的第二身份信息。

11.根据权利要求10所述的装置，其特征在于，所述目标确定子模块包括：

提取子模块，用于从所述第一打车请求中提取所述第一客户端所在的呼叫地点和打车信息；

第一确定子模块，用于基于所述呼叫地点确定寻车范围；

生成子模块，用于采用所述呼叫地点和/或所述打车信息生成第二打车请求；

发送子模块，用于将所述第二打车请求发送至在所述寻车范围内的一个或多个第二客户端；

第二确定子模块，用于在接收到所述第二客户端针对所述第二打车请求返回的确认指示时，确定所述第二客户端为目标第二客户端。

12.根据权利要求9或10或11所述的装置，其特征在于，当前接收的目标第二客户端的第二用户信息通过扫描图形标识符获得。

13.根据权利要求12所述的装置，其特征在于，所述图形标识符包括二维码。

14.根据权利要求12所述的装置，其特征在于，所述订单号中包括目标第二客户端对应的第二身份信息；

当前接收的订单号为所述第一客户端根据扫描获得的目标第二客户端对应的第二身份信息筛选出的，最近的订单号。

15.根据权利要求9或10或11或13或14所述的装置，其特征在于，所述身份信息验证模块包括：

第一获得子模块，用于在当前接收的第一身份信息、第二身份信息和订单号，分别与在先获取的第一身份信息、第二身份信息和订单号匹配成功时，获得第一身份信息通过验证的验证结果；

第二获得子模块，用于在当前接收的第一身份信息、第二身份信息和订单号，与在先获取的第一身份信息、第二身份信息和订单号至少一项匹配失败时，获得第一身份信息未通过验证的验证结果。

16.根据权利要求15所述的装置，其特征在于，所述验证结果返回模块包括：

第一返回子模块，用于将所述第一身份信息通过验证的验证结果返回所述第一客户端；

或者，

第二返回子模块，用于将所述第一身份信息未通过验证的验证结果返回所述第一客户端。