CN110751530B - 身份信息安全校验方法、服务器、乘客端及司机端 - Google Patents

身份信息安全校验方法、服务器、乘客端及司机端 Download PDF

Info

Publication number
CN110751530B
CN110751530B CN201810953064.1A CN201810953064A CN110751530B CN 110751530 B CN110751530 B CN 110751530B CN 201810953064 A CN201810953064 A CN 201810953064A CN 110751530 B CN110751530 B CN 110751530B
Authority
CN
China
Prior art keywords
driver
passenger
identity information
server
order
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
CN201810953064.1A
Other languages
English (en)
Other versions
CN110751530A (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 CN201810953064.1A priority Critical patent/CN110751530B/zh
Publication of CN110751530A publication Critical patent/CN110751530A/zh
Application granted granted Critical
Publication of CN110751530B publication Critical patent/CN110751530B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0609—Buyer or seller confidence or verification
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • 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)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明实施例提供一种身份信息安全校验方法、服务器、乘客端及司机端，属于智能交通技术领域。方法包括：接收乘客端发送的订单信息，以及对应接单的司机端标识；将所述司机端标识对应的司机身份信息卡发送至所述乘客端。服务器用于执行上述方法。本发明实施例通过将接单司机的司机身份信息卡发送至乘客端，使得乘客可以根据在乘客端接收到的司机身份信息卡与司机的实际信息进行校验，从而提高了乘客乘车的安全性。

Description

身份信息安全校验方法、服务器、乘客端及司机端
技术领域
本发明涉及互联网技术领域，具体而言，涉及一种身份信息安全校验方法、服务器、乘客端及司机端。
背景技术
目前，随着互联网用车平台技术的迅速发展和普及，人们可以根据用车需求利用手机终端生成用车订单，为日常出行提供了便利。
现有技术中，当有司机接到乘客发送的订单请求后，可以在乘客端显示接单司机的注册车辆型号，注册车辆车牌号，司机手机号等信息，方便乘客找到接单车辆。但现实中，可能存在其他人冒用注册司机的信息进行接单载客，实施不法行为，从而导致乘客的人身安全受到威胁，降低了乘客乘车的安全性。
发明内容
有鉴于此，本发明实施例的目的在于提供一种身份信息安全校验方法、服务器、乘客端及司机端，以解决上述技术问题。
第一方面，本发明实施例提供了一种身份信息安全校验方法，包括：
接收乘客端发送的订单信息，以及对应接单的司机端标识；
将所述司机端标识对应的司机身份信息卡发送至所述乘客端。
进一步地，所述方法，还包括：
接收所述乘客端返回的第一校验结果，所述第一校验结果为接单司机与所述司机身份信息卡的一致性校验结果。
进一步地，在接收所述乘客端返回的第一校验结果之后，还包括：
若所述第一校验结果为校验不一致，则取消订单。
进一步地，在接收所述乘客端返回的第一校验结果之后，还包括：
若所述第一校验结果为校验不一致，且接收到所述乘客端发送的取消订单请求，则取消订单且免收订单取消费。
进一步地，在接收所述乘客端返回的第一校验结果之后，还包括：
若所述第一校验结果为校验不一致，且接收到所述乘客端发送的取消订单请求，则取消订单并向所述乘客端收取取消订单费；
审核所述第一校验结果是否属实；若属实，将所述取消订单费退回至所述乘客端。
进一步地，若审核确定所述第一校验结果不属实，则向所述司机端发放订单取消补偿费。
进一步地，在接收所述乘客端返回的第一校验结果之后，还包括：
若所述第一校验结果为校验不一致，则中止所述司机端接单；并
获取所述第一校验结果中包含的信息不一致的第一投诉类型；
根据所述第一投诉类型生成对应的第一申诉消息，将所述第一申诉消息发送至所述司机端，以使所述司机端进行申诉。
进一步地，在将所述申诉消息发送至所述司机端之后，所述方法，还包括：
若在第一预设时间段内所述司机端申诉未通过，则停用所述司机端。
进一步地，所述方法，还包括：
接收所述司机端发送的司机身份信息更新请求，所述司机身份信息更新请求包括第一待更新信息；
根据所述第一待更新信息更新所述司机端对应的司机身份信息卡。
进一步地，所述方法，还包括：
向司机端发送订单取消消息，所述订单取消消息中的订单取消理由为司机身份信息校验不一致之外的理由。
进一步地，在将所述司机端标识对应的司机身份信息卡发送至所述乘客端之前，所述方法，还包括：
若所述司机端未创建所述司机身份信息卡，则向所述司机端发送第一建卡指令。
进一步地，所述方法，还包括：
接收所述司机端发送的司机身份信息，根据所述司机身份信息创建所述司机身份信息卡。
进一步地，所述司机身份信息卡包括司机头像、性别、手机号、注册车牌、注册车辆型号和第一已验真次数中任意一个或其组合。
进一步地，所述方法，还包括：
若所述第一校验结果为校验一致，则更新所述司机身份信息卡中的第一已验真次数。
进一步地，所述方法，还包括：
判断当前场景是否为第一高危场景，若是，则向所述乘客端发送司机身份信息卡弹出指令；其中，判断为所述第一高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述司机身份信息卡的第一已验真次数低于第一预设次数；
所述司机端发生身份信息与司机身份信息卡不一致的次数大于第二预设次数。
进一步地，在将所述司机端标识对应的司机身份信息卡发送至所述乘客端之前，还包括：
接收所述乘客端发送的查看所述司机身份信息卡的请求。
进一步地，所述方法，还包括：
向所述司机端标识对应的司机端发送所述乘客端对应的乘客身份信息卡。
进一步地，所述方法，还包括：
接收所述司机端返回的第二校验结果，所述第二校验结果为发单乘客与所述乘客身份信息卡的一致性校验结果。
进一步地，在接收所述司机端返回的第二校验结果之后，所述方法，还包括：
若所述第二校验结果为校验不一致，且接收到所述司机端发送的取消订单请求，则取消订单。
进一步地，在接收所述司机端返回的第二校验结果之后，所述方法，还包括：
若所述第二校验结果为校验不一致，则中止所述乘客端发单；并
获取所述第二校验结果中包含的信息不一致的第二投诉类型；
根据所述第二投诉类型生成对应的第二申诉消息，将所述第二申诉消息发送至所述乘客端，以使所述乘客端进行申诉。
进一步地，所述方法，还包括：
接收所述乘客端发送的乘客身份信息更新请求，所述乘客身份信息更新请求包括第二待更新信息；
根据所述第二待更新信息更新所述乘客端对应的乘客身份信息卡。
进一步地，所述方法，还包括：
若所述乘客端未创建所述乘客身份信息卡，则向所述乘客端发送第二建卡指令。
进一步地，所述方法，还包括：
接收所述乘客端发送的乘客身份信息，根据所述乘客身份信息创建所述乘客身份信息卡，其中，
所述乘客身份信息卡包括乘客头像、性别、手机号、乘车人数和第一已验真次数中任意一项或其组合。
进一步地，所述方法，还包括：
若所述第二校验结果为校验一致，则更新所述乘客身份信息卡中的第二已验真次数。
进一步地，所述方法，还包括：
判断当前场景是否为第二高危场景，若是，则向所述司机端发送乘客身份信息卡弹出指令；其中，判断为所述第二高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述乘客身份信息卡的第二已验真次数低于第三预设次数；
所述乘客端发生身份信息与乘客身份信息卡不一致的次数大于第四预设次数。
进一步地，在向所述司机端标识对应的司机端发送所述乘客端对应的乘客身份信息卡之前，所述方法，还包括：
接收所述司机端发送的查看所述乘客身份信息卡的请求。
进一步地，所述方法，还包括：
若接收到所述乘客端返回的第一校验结果和所述司机端返回的第二校验结果均为校验一致，则开始行程。
进一步地，所述方法，还包括：
若所述第一校验结果为校验不一致，且接收到所述乘客端发送的开始行程请求，则向所述乘客端发送安全告警提示，并开始行程。
进一步地，所述方法，还包括：
接收所述乘客端发送的第一护航模式开启请求；
实时获取所述订单信息对应的车辆的行驶轨迹，将所述行驶轨迹发送至所述乘客端预先设置的第一紧急联系终端。
进一步地，在接收所述乘客端发送的第一护航模式开启请求之后，所述方法，还包括：
根据所述行驶轨迹判断是否处于第三高危场景，若是，则向所述乘客端发送第一安全询问提示；
若在第二预设时间段内没有接收到所述乘客端返回的第一安全确认消息或接收到所述乘客端返回的第一紧急求助消息，则向所述第一紧急联系终端发送报警提示；其中，
判断为所述第三高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于第三预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
进一步地，所述方法，还包括：
接收所述司机端发送的第二护航模式开启请求；
实时获取所述订单信息对应的车辆的行驶轨迹，将所述行驶轨迹发送至所述司机端预先设置的第二紧急联系终端。
进一步地，在接收所述司机端发送的第二护航模式开启请求之后，所述方法，还包括：
根据所述行驶轨迹判断是否处于第四高危场景，若是，则向所述司机端发送第二安全询问提示；
若在第四预设时间段内没有接收到所述司机端返回的第二安全确认消息或接收到所述司机端返回的第二紧急求助消息，则向所述第二紧急联系终端发送报警提示；其中，
判断为所述第四高危场景所满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于第二预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
本发明实施例通过将接单司机的司机身份信息卡发送至乘客端，使得乘客可以根据在乘客端接收到的司机身份信息卡与司机的实际信息进行校验，从而提高了乘客乘车的安全性。
第二方面，本发明实施例提供一种身份信息安全校验方法，包括：
接收乘客端发送的订单信息，以及对应接单的司机端标识；
将所述乘客端对应的乘客身份信息卡发送至所述司机端标识对应的司机端。
本发明实施例通过将发单乘客的乘客身份信息卡发送至司机端，使得司机可以根据在司机端接收到的乘客身份信息卡与乘客的实际信息进行校验，从而提高了司机出行的安全性。
第三方面，一种身份信息安全校验方法，包括：
向服务器发送订单信息；
接收所述服务器返回的接单司机的司机身份信息卡。
进一步地，在接收所述服务器返回的接单司机的司机身份信息卡之后，所述方法，还包括：
在显示界面上显示查看所述司机身份信息卡的入口；
接收针对所述入口的触发操作，显示司机身份信息卡。
进一步地，所述方法，还包括：
向所述服务器发送第一校验结果，所述第一校验结果为接单司机与所述司机身份信息卡的一致性校验结果，所述第一校验结果包括校验一致和校验不一致。
进一步地，所述方法，还包括：
接收服务器发送的乘客身份信息卡创建指令；
将乘客身份信息发送至所述服务器，所述乘客身份信息包括乘客头像、性别、手机号、乘车人数和第一已验真次数中任意一项或其组合。
进一步地，所述方法，还包括：
接收所述服务器发送的第二申诉消息，所述第二申诉消息是根据接单的司机端发送的第二投诉类型生成的；
根据所述第二申诉消息向所述服务器发送第二申诉请求，所述第二申诉请求包括第二申诉证明信息。
进一步地，所述方法，还包括：
若行程结束，则关闭所述司机身份信息卡的入口。
进一步地，所述方法，还包括：
向所述服务器发送第一护航模式开启请求，以使所述服务器实时将所述订单信息对应的车辆的位置信息发送至预先设置的第一紧急联系终端。
进一步地，所述方法，还包括：
接收所述服务器发送的第一安全询问提示，所述第一安全询问提示为服务器判断处于第三高危场景时发送的；
根据所述第一安全询问提示向所述服务器发送第一应答消息；其中，
所述第三高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
进一步地，所述方法，还包括：
接收针对第一安全模式下的安全保障功能的触发操作，根据所述安全保障功能进行相应的安全操作，其中，所述安全保障功能包括录音、录像和拨打紧急救助电话。
本发明实施例通过接收司机身份信息卡，将司机身份信息卡与接单司机的实际身份进行校验，从而来判断来接单的司机是否与注册司机的身份一致，以此来保障乘客乘车的安全。
第四方面，本发明实施例提供一种身份信息安全校验方法，包括：
向服务器发送接单请求，所述接单请求包括所接乘客的订单信息；
接收所述服务器返回的所述订单信息对应的乘客身份信息卡。
进一步地，在接收所述服务器返回的所述订单信息对应的乘客身份信息卡之后，所述方法，还包括：
向所述服务器发送第二校验结果，所述第二校验结果为发单乘客与所述乘客身份信息卡的一致性校验结果，所述第二校验结果包括校验一致和校验不一致并取消订单。
进一步地，所述方法，还包括：
接收服务器发送的司机身份信息卡创建指令；
将司机身份信息发送至所述服务器，所述司机身份信息包括司机头像、性别、手机号、注册车牌、注册车辆型号和第一已验真次数中任意一个或其组合。
进一步地，所述方法，还包括：
接收所述服务器发送的第一申诉消息，所述第一申诉消息是根据发单的乘客端发送的第一投诉类型生成的；
根据所述第一申诉消息向所述服务器发送第一申诉请求，所述第一申诉请求包括第一申诉证明信息。
进一步地，所述方法，还包括：
向所述服务器发送第二护航模式开启请求，以使所述服务器实时将所述订单信息对应的车辆的位置信息发送至预先设置的第二紧急联系终端。
进一步地，所述方法，还包括：
接收所述服务器发送的第二安全询问提示，所述第二安全询问提示为服务器判断处于第四高危场景时发送的；
根据所述第二安全询问提示向所述服务器发送第二应答消息；其中，
所述第四高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
进一步地，所述方法，还包括：
接收针对第二安全模式下的安全保障功能的触发操作，根据所述安全保障功能进行相应的安全操作，其中，所述安全保障功能包括录音、摄像和拨打紧急救助电话。
本发明实施例通过将发单乘客的乘客身份信息卡发送至司机端，使得司机可以根据在司机端接收到的乘客身份信息卡与乘客的实际信息进行校验，从而提高了司机出行的安全性。
第五方面，本发明实施例提供一种服务器，包括：
第一接收模块，用于接收乘客端发送的订单信息，以及对应接单的司机端标识；
第一发送模块，用于将所述司机端标识对应的司机身份信息卡发送至所述乘客端。
进一步地，所述服务器，还包括：
第二接收模块，用于接收所述乘客端返回的第一校验结果，所述第一校验结果为接单司机与所述司机身份信息卡的一致性校验结果。进一步地，所述服务器，还包括：
第一订单取消模块，用于若所述第一校验结果为校验不一致，则取消订单。
进一步地，所述服务器，还包括：
第二订单取消模块，用于若所述第一校验结果为校验不一致，且接收到所述乘客端发送的取消订单请求，则取消订单且免收订单取消费。
进一步地，所述服务器，还包括：
第三订单取消模块，用于若所述第一校验结果为校验不一致，且接收到所述乘客端发送的取消订单请求，则取消订单并向所述乘客端收取取消订单费；
审核所述第一校验结果是否属实；若属实，将所述取消订单费退回至所述乘客端。
进一步地，所述第三订单取消模块，具体用于：
若审核确定所述第一校验结果不属实，则向所述司机端发放订单取消补偿费。
进一步地，所述服务器，还包括：
第一投诉模块，用于若所述第一校验结果为校验不一致，则中止所述司机端接单；并
获取所述第一校验结果中包含的信息不一致的第一投诉类型；
根据所述第一投诉类型生成对应的第一申诉消息，将所述第一申诉消息发送至所述司机端，以使所述司机端进行申诉。
进一步地，所述服务器，还包括：
停用模块，用于若在第一预设时间段内所述司机端申诉未通过，则停用所述司机端。
进一步地，所述服务器，还包括：
第三接收模块，用于接收所述司机端发送的司机身份信息更新请求，所述司机身份信息更新请求包括第一待更新信息；
根据所述第一待更新信息更新所述司机端对应的司机身份信息卡。
进一步地，所述服务器，还包括：
第二发送模块，用于向司机端发送订单取消消息，所述订单取消消息中的订单取消理由为司机身份信息校验不一致之外的理由。
进一步地，所述服务器，还包括：
第三发送模块，用于若所述司机端未创建所述司机身份信息卡，则向所述司机端发送第一建卡指令。
进一步地，所述服务器，还包括：
司机卡创建模块，用于接收所述司机端发送的司机身份信息，根据所述司机身份信息创建所述司机身份信息卡。
进一步地，所述司机身份信息卡包括司机头像、性别、手机号、注册车牌、注册车辆型号和第一已验真次数中任意一个或其组合。
进一步地，所述服务器，还包括：
第一更新模块，用于若所述第一校验结果为校验一致，则更新所述司机身份信息卡中的第一已验真次数。
进一步地，所述服务器，还包括：
第一弹出模块，用于判断当前场景是否为第一高危场景，若是，则向所述乘客端发送司机身份信息卡弹出指令；其中，判断为所述第一高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述司机身份信息卡的第一已验真次数低于第一预设次数；
所述司机端发生身份信息与司机身份信息卡不一致的次数大于第二预设次数。
进一步地，所述服务器，还包括：
第四接收模块，用于接收所述乘客端发送的查看所述司机身份信息卡的请求。
进一步地，所述服务器，还包括：
第四发送模块，用于向所述司机端标识对应的司机端发送所述乘客端对应的乘客身份信息卡。
进一步地，所述服务器，还包括：
第五接收模块，用于接收所述司机端返回的第二校验结果，所述第二校验结果为发单乘客与所述乘客身份信息卡的一致性校验结果。
进一步地，所述服务器，还包括：
第四取消订单模块，用于若所述第二校验结果为校验不一致，且接收到所述司机端发送的取消订单请求，则取消订单。
进一步地，所述服务器，还包括：
第二投诉模块，用于若所述第二校验结果为校验不一致，则中止所述乘客端发单；并
获取所述第二校验结果中包含的信息不一致的第二投诉类型；
根据所述第二投诉类型生成对应的第二申诉消息，将所述第二申诉消息发送至所述乘客端，以使所述乘客端进行申诉。
进一步地，所述服务器，还包括：
第二更新模块，用于接收所述乘客端发送的乘客身份信息更新请求，所述乘客身份信息更新请求包括第二待更新信息；
根据所述第二待更新信息更新所述乘客端对应的乘客身份信息卡。
进一步地，所述服务器，还包括：
第五发送模块，用于若所述乘客端未创建所述乘客身份信息卡，则向所述乘客端发送第二建卡指令。
进一步地，所述服务器，还包括：
乘客卡创建模块，用于接收所述乘客端发送的乘客身份信息，根据所述乘客身份信息创建所述乘客身份信息卡，其中，
所述乘客身份信息卡包括乘客头像、性别、手机号、乘车人数和第一已验真次数中任意一项或其组合。
进一步地，所述服务器，还包括：
第三更新模块，用于若所述第二校验结果为校验一致，则更新所述乘客身份信息卡中的第二已验真次数。
进一步地，所述服务器，还包括：
第二弹出模块，用于判断当前场景是否为第二高危场景，若是，则向所述司机端发送乘客身份信息卡弹出指令；其中，判断为所述第二高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述乘客身份信息卡的第二已验真次数低于第三预设次数；
所述乘客端发生身份信息与乘客身份信息卡不一致的次数大于第四预设次数。
进一步地，所述服务器，还包括：
第六接收模块，用于接收所述司机端发送的查看所述乘客身份信息卡的请求。
进一步地，所述服务器，还包括：
第一行程开始模块，用于若接收到所述乘客端返回的第一校验结果和所述司机端返回的第二校验结果均为校验一致，则开始行程。
进一步地，所述服务器，还包括：
第二行程开始模块，用于若所述第一校验结果为校验不一致，且接收到所述乘客端发送的开始行程请求，则向所述乘客端发送安全告警提示，并开始行程。
进一步地，所述服务器，还包括：
第一护航模块，用于接收所述乘客端发送的第一护航模式开启请求；
实时获取所述订单信息对应的车辆的行驶轨迹，将所述行驶轨迹发送至所述乘客端预先设置的第一紧急联系终端。
进一步地，所述服务器，还包括：
第一询问模块，用于根据所述行驶轨迹判断是否处于第三高危场景，若是，则向所述乘客端发送第一安全询问提示；
若在第二预设时间段内没有接收到所述乘客端返回的第一安全确认消息或接收到所述乘客端返回的第一紧急求助消息，则向所述第一紧急联系终端发送报警提示；其中，
判断为所述第三高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于第三预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
进一步地，所述服务器，还包括：
第二护航模块，用于接收所述司机端发送的第二护航模式开启请求；
实时获取所述订单信息对应的车辆的行驶轨迹，将所述行驶轨迹发送至所述司机端预先设置的第二紧急联系终端。
进一步地，所述服务器，还包括：
第二询问模块，用于根据所述行驶轨迹判断是否处于第四高危场景，若是，则向所述司机端发送第二安全询问提示；
若在第四预设时间段内没有接收到所述司机端返回的第二安全确认消息或接收到所述司机端返回的第二紧急求助消息，则向所述第二紧急联系终端发送报警提示；其中，
判断为所述第四高危场景所满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于第二预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
第六方面，本发明实施例提供一种服务器，包括：
订单信息接收模块，用于接收乘客端发送的订单信息，以及对应接单的司机端标识；
乘客信息发送模块，用于将所述乘客端对应的乘客身份信息卡发送至所述司机端标识对应的司机端。
第七方面，本发明实施例提供一种乘客端，包括：
第六发送模块，用于向服务器发送订单信息；
第七接收模块，用于接收所述服务器返回的接单司机的司机身份信息卡。
进一步地，所述乘客端，还包括：
显示模块，用于在显示界面上显示查看所述司机身份信息卡的入口；
接收针对所述入口的触发操作，显示司机身份信息卡。
进一步地，所述乘客端，还包括：
第一校验模块，用于向所述服务器发送第一校验结果，所述第一校验结果为接单司机与所述司机身份信息卡的一致性校验结果，所述第一校验结果包括校验一致和校验不一致。
进一步地，所述乘客端，还包括：
第一收发模块，用于接收服务器发送的乘客身份信息卡创建指令；
将乘客身份信息发送至所述服务器，所述乘客身份信息包括乘客头像、性别、手机号、乘车人数和第一已验真次数中任意一项或其组合。
进一步地，所述乘客端，还包括：
第二收发模块，用于接收所述服务器发送的第二申诉消息，所述第二申诉消息是根据接单的司机端发送的第二投诉类型生成的；
根据所述第二申诉消息向所述服务器发送第二申诉请求，所述第二申诉请求包括第二申诉证明信息。
进一步地，所述乘客端，还包括：
入口关闭模块，用于若行程结束，则关闭所述司机身份信息卡的入口。
进一步地，所述乘客端，还包括：
第一护航请求模块，用于向所述服务器发送第一护航模式开启请求，以使所述服务器实时将所述订单信息对应的车辆的位置信息发送至预先设置的第一紧急联系终端。
进一步地，所述乘客端，还包括：
第三询问模块，用于接收所述服务器发送的第一安全询问提示，所述第一安全询问提示为服务器判断处于第三高危场景时发送的；
根据所述第一安全询问提示向所述服务器发送第一应答消息；其中，
所述第三高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
进一步地，所述乘客端，还包括：
安全保障模块，用于接收针对第一安全模式下的安全保障功能的触发操作，根据所述安全保障功能进行相应的安全操作，其中，所述安全保障功能包括录音、录像和拨打紧急救助电话。
第八方面，本发明实施例提供一种司机端，包括：
接单请求发送模块，用于向服务器发送接单请求，所述接单请求包括所接乘客的订单信息；
乘客信息接收模块，用于接收所述服务器返回的所述订单信息对应的乘客身份信息卡。
进一步地，所述司机端，还包括：
第二校验模块，用于向所述服务器发送第二校验结果，所述第二校验结果为发单乘客与所述乘客身份信息卡的一致性校验结果，所述第二校验结果包括校验一致和校验不一致并取消订单。
进一步地，所述司机端，还包括：
第二收发模块，用于接收服务器发送的司机身份信息卡创建指令；
将司机身份信息发送至所述服务器，所述司机身份信息包括司机头像、性别、手机号、注册车牌、注册车辆型号和第一已验真次数中任意一个或其组合。
进一步地，所述司机端，还包括：
申诉模块，用于接收所述服务器发送的第一申诉消息，所述第一申诉消息是根据发单的乘客端发送的第一投诉类型生成的；
根据所述第一申诉消息向所述服务器发送第一申诉请求，所述第一申诉请求包括第一申诉证明信息。
进一步地，所述司机端，还包括：
第二护航请求模块，用于向所述服务器发送第二护航模式开启请求，以使所述服务器实时将所述订单信息对应的车辆的位置信息发送至预先设置的第二紧急联系终端。
进一步地，所述司机端，还包括：
第四询问模块，用于接收所述服务器发送的第二安全询问提示，所述第二安全询问提示为服务器判断处于第四高危场景时发送的；
根据所述第二安全询问提示向所述服务器发送第二应答消息；其中，
所述第四高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
进一步地，所述司机端，还包括：
第二安全保障模块，用于接收针对第二安全模式下的安全保障功能的触发操作，根据所述安全保障功能进行相应的安全操作，其中，所述安全保障功能包括录音、摄像和拨打紧急救助电话。
第九方面，本发明实施例提供一种电子设备，包括：处理器、存储器和总线，其中，
所述处理器和所述存储器通过所述总线完成相互间的通信；
所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行第一方面或第二方面的方法步骤。
第十方面，本发明实施例提供一种非暂态计算机可读存储介质，包括：
所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行第一方面或第二方面的方法步骤。
第十一方面，本发明实施例提供一种电子设备，包括：处理器、存储器和总线，其中，
所述处理器和所述存储器通过所述总线完成相互间的通信；
所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行第三方面的方法步骤。
第十二方面，本发明实施例提供一种非暂态计算机可读存储介质，包括：
所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行第三方面的方法步骤。
第十三方面，本发明实施例提供一种电子设备，包括：处理器、存储器和总线，其中，
所述处理器和所述存储器通过所述总线完成相互间的通信；
所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行第四方面的方法步骤。
第十四方面，本发明实施例提供一种非暂态计算机可读存储介质，包括：
所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行第四方面的方法步骤。
本发明的其他特征和优点将在随后的说明书阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明实施例了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1为本发明实施例提供的一种身份信息安全校验方法流程示意图；
图2为本发明实施例提供的一种司机身份信息卡弹出示意图；
图3为本发明实施例提供的一种乘客校验司机身份流程示意图；
图4为本发明实施例提供的一种司机端申诉流程示意图；
图5为本发明实施例提供的一种司机端验证乘客身份流程示意图；
图6为本发明实施例提供的乘客端第一安全模式入口示意图；
图7为本发明实施例提供的乘客端开启护航模式界面示意图；
图8为本发明实施例提供的安全询问界面示意图；
图9为本发明实施例提供的另一种身份信息安全校验方法流程示意图；
图10为本发明实施例提供的又一种身份信息安全校验方法流程示意图；
图11为本发明实施例提供的又一种身份信息安全校验方法流程示意图；
图12为本发明实施例提供的一种服务器结构示意图；
图13为本发明实施例提供的一种乘客端结构示意图；
图14为本发明实施例提供的一种司机端结构示意图；
图15为本发明实施例提供的电子设备实体结构示意图；
图16为本发明实施例提供的电子设备实体结构示意图；
图17为本发明实施例提供的电子设备实体结构示意图；
图18为本发明实施例提供的乘客端与服务器进行交互的示意图；
图19为本发明实施例提供的司机端与服务器进行交互的示意图。
具体实施方式
下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本发明的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
图1为本发明实施例提供的一种身份信息安全校验方法流程示意图，如图1所示，该方法包括：
步骤101：服务器接收乘客端发送的订单信息，以及对应接单的司机端标识；
在具体的实施过程中，乘客需要通过打车软件进行打车时，首先通过乘客端向服务器发送订单信息，此时，服务器接收到乘客端发送的订单信息，并将订单信息发送至相应的司机端，应当说明的是，服务器在向司机端发送该订单信息时，可以根据内置算法选择满足条件的司机端进行发送，也可以以广播的方式发送至司机端，还可以是直接将订单分配给某个司机端。当某个司机端接到该订单信息后，服务器会接收到对应接单的司机端标识，其中，司机端标识可以是司机的注册账号，也可以是其他能够唯一标识该司机的信息，本发明实施例对此不作具体限定。
步骤102：服务器将所述司机端标识对应的司机身份信息卡发送至所述乘客端。
在具体的实施过程中，服务器在接收到接单司机的司机标识之后，将该司机标识对应的司机身份信息卡发送至乘客端，以使乘客能够通过乘客端接收的司机身份信息卡对接单司机进行校验，判断接收到的司机身份信息卡中的司机身份信息与实际开车来接该乘客的司机信息是否一致。应当说明的是，服务器可以在接收到司机端标识之后主动向乘客端发送司机身份信息卡，也可以是在乘客端发送要查看司机身份的请求后，再向乘客端发送对应的司机身份信息卡。可以理解的是，图2为本发明实施例提供的一种司机身份信息卡弹出示意图，如图2所示，司机身份信息卡中可以包括：司机的头像、性别、手机、注册车牌、注册车辆型号以及第一已验真次数等等，当司机到达乘客所要乘车地点时，乘客可以将乘客端接收到的司机身份信息卡中的各个信息与司机的实际信息进行校验，例如：查看头像与司机的面部特征是否一致、性别是否一致、注册车牌是否一致、注册车辆型号是否一致等等。
本发明实施例通过将接单司机的司机身份信息卡发送至乘客端，使得乘客可以根据在乘客端接收到的司机身份信息卡与司机的实际信息进行校验，从而提高了乘客乘车的安全性。
在上述实施例的基础上，所述方法，还包括：
服务器接收所述乘客端返回的第一校验结果，所述第一校验结果为接单司机与所述司机身份信息卡的一致性校验结果。
在具体的实施过程中，当乘客对司机身份信息卡和接单司机的实际信息进行校验后，通过乘客端向服务器发送第一校验结果，此时，服务器能够接收到该乘客端返回的第一校验结果。应当说明的是，如果乘客校验后发现司机身份信息卡中的司机身份信息与司机实际信息一致，则第一校验结果为校验一致；如果乘客校验后发现司机身份信息卡中的司机身份信息与司机实际信息不一致，则第一校验结果为校验不一致。如图2所示，如果校验不一致，则乘客可以点击“投诉信息不符”的按钮，使得乘客端将校验不一致的第一校验结果返回至服务器。
本发明实施例通过接收乘客端返回的第一校验结果来对司机身份信息卡进行校验，一方面提高了乘客的乘车安全性，另一方面起到了对身份信息卡中信息进行监督的作用。
在上述实施例的基础上，在接收所述乘客端返回的第一校验结果之后，还包括：
若所述第一校验结果为校验不一致，则取消订单。
在具体的实施过程中，乘客在对司机身份信息卡进行校验后，如果发现司机身份信息卡与司机的实际信息不符，则可以将服务器发送校验不一致的第一校验结果，当服务器接收到的第一校验结果为校验不一致时，则对该订单进行取消操作，以此来保证乘客的出行安全。
图3为本发明实施例提供的一种乘客校验司机身份流程示意图，如图3所示，包括：
步骤301：发送订单信息；乘客端向服务器发送订单信息，其中订单信息中可以包括始发地、目的地、乘车时间、乘车人数、乘客ID等等；
步骤302：接收接单司机信息；服务器接收接单司机的信息，包括接单司机的司机端标识、司机身份信息卡等等；
步骤303：是否已建卡；服务器判断该乘客端是否已经创建乘客身份信息卡，如果已经创建，则执行步骤305；如果没有创建，则执行步骤304；
步骤304：创建乘客身份信息卡；服务器向乘客端发送创建乘客身份信息卡的提示；
步骤305：是否高危场景；服务器判断当前场景是否是第一高危场景，如果是，则执行步骤306；如果不是，则执行步骤307；
步骤306：司机身份信息卡弹出；服务器向乘客端发送司机身份信息卡弹出指令，使得在乘客端主动弹出司机身份信息卡，让乘客进行校验；
步骤307：显示查看司机身份信息卡入口；可以在乘客端显示查看司机身份信息卡入口，使得乘客可以通过该入口进行查看；
步骤308：校验是否一致；乘客通过司机身份信息卡对接单的司机进行校验，并向服务器发送第一校验结果，如果第一校验结果为校验不一致，则执行步骤309，否则执行步骤311；
步骤309：投诉信息；乘客端向服务器发送投诉信息，投诉信息中包括司机端的信息不一致的第一投诉类型；
步骤310：取消订单；服务器将该订单取消；
步骤311：行程开始；服务器开始行程监控。
应当说明的是，如果服务器在接收到的乘客端发送的第一校验结果为不一致，并且发送了取消订单请求，则服务器将该订单进行取消操作，并且不向乘客端收取订单取消费。一方面保护了乘客的出行安全，另一方面不会因为司机端的问题使得乘客在要求取消订单后受到经济损失。
在上述实施例的基础上，在接收所述乘客端返回的第一校验结果之后，还包括：
若所述第一校验结果为校验不一致，且接收到所述乘客端发送的取消订单请求，则取消订单并向所述乘客端收取取消订单费；
服务器审核所述第一校验结果是否属实；若属实，将所述取消订单费退回至所述乘客端。
在具体的实施过程中，乘客在对司机身份信息卡进行校验后，如果发现司机身份信息卡与司机的实际信息不符，则可以将服务器发送校验不一致的第一校验结果，并且可以选择取消订单，当服务器接收到的第一校验结果为校验不一致，并且该乘客要求取消订单时，服务器需要向乘客端收取相应的取消订单费，可以在乘客向服务器发送取消订单请求之后，向乘客端提示如果取消订单会收取一定的取消订单费，并且在审核第一校验结果属实之后将取消订单费退回至乘客端。如果乘客仍然选择取消订单，则服务器需要审核第一校验结果是否属实，应当说明的是，在乘客端发送的校验不一致的第一校验结果中，还可以包括校验不一致的相关证据，可以是拍的照片等，服务器在审核时具体可以是人工审核，也可以是通过人工智能进行审核。如果审核后，第一校验结果是属实的，则将之前收取的取消订单费退回至乘客端，应当说明的是，可以按照乘客支付取消订单费的路径原路退回，也可以通过乘客端发送的指定账户退回。
另外，如果服务器审核第一校验结果不属实，则不会将之前收取的乘客端的取消订单费退回至乘客端，并且由于司机开车到乘客的始发地，会消耗一些时间及车辆能源，因此服务器还会向司机端发放订单取消补偿费。应当说明的是，向司机端发放的订单取消补偿费可以全部来自收取乘客端的取消订单费。
本发明实施例通过接收到第一校验结果为校验不一致，且接收到取消订单请求后，预先向乘客端收取取消订单费，如果服务器核实第一校验结果后，再将之前收取的取消订单费退回至乘客端，从而一方面避免了由于乘客端恶意取消订单，另一方面保证了给司机端的利益。
在上述实施例的基础上，在接收所述乘客端返回的第一校验结果之后，还包括：
若所述第一校验结果为校验不一致，则服务器中止所述司机端接单；并获取所述第一校验结果中包含的信息不一致的第一投诉类型；
根据所述第一投诉类型生成对应的第一申诉消息，将所述第一申诉消息发送至所述司机端，以使所述司机端进行申诉。
在具体的实施过程中，如果服务器接收到了乘客端发送的校验不一致的第一校验结果后，先中止司机端的接单行为，并且获取第一校验结果中包含的信息不一致的第一投诉类型，例如：司机身份校验卡中的头像与司机实际长相不同、注册车牌号与司机实际驾驶的车辆的车牌号不一致等等。服务器将第一投诉类型生成第一申诉消息，用来告知司机有哪些信息需要进行申诉。假设是头像不一致，则在第一申诉消息中告知司机头像不一致，请上传自证信息，此时，司机端在接收到第一申诉消息后，将重新上传头像用以证明。应当说明的是，还可以通过其他的自证方式，本发明实施例对此不作具体限定。还应当说明的是，也可以对第一校验结果进行审核，如果审核属实后再中止司机端的接单行为。
另外，还可以设定申诉的第一预设时间段，如果司机端在第一预设时间段内没有申诉通过，则停用该司机端，此时需要司机终端重新创建司机身份信息卡，创建完成后才能够重新使用司机端接单。可以理解的是，司机端在第一预设时间段内没有申诉通过的情况可以是司机端在第一预设时间段内没有提交自证信息；也可以是，司机端在第一预设时间段内提交了自证信息，但是所提交的自证信息未通过。
图4为本发明实施例提供的一种司机端申诉流程示意图，如图4所示，包括：
步骤401：投诉生效；服务器在接收到乘客端发送的投诉消息后，则投诉生效；
步骤402：中止司机接单；服务器为了保障乘客安全，先中止司机接单；
步骤403：发送申诉消息；服务器向司机端发送第一申诉消息，第一申诉消息中包括校验不一致的第一投诉类型，以告知司机需要提供哪些自证材料；
步骤404：自证；司机端根据第一申诉消息向服务器发送自证材料，从而进行申诉；
步骤405：申诉是否成功；服务器在第一预设时间段内接收到司机端发送的自证材料后，判断是否申诉成功，若成功则执行步骤406，否则执行步骤407；
步骤406：开启司机身份信息卡；申诉成功后，开启司机身份信息卡，此时，司机端能够重新接单。
步骤407：停止接单；如果司机端没有在第一预设时间段内申诉成功，则停止该司机端接单，并且需要司机端重新创建司机身份信息卡。
本发明实施例通过在接收到校验不一致的第一校验结果后，向司机端发送第一申诉消息，在申诉通过之前中止司机端接单，从而来保障乘客乘车安全。
在上述实施例的基础上，所述方法，还包括：
服务器接收所述司机端发送的司机身份信息更新请求，所述司机身份信息更新请求包括第一待更新信息；
服务器根据所述第一待更新信息更新所述司机端对应的司机身份信息卡。
在具体的实施过程中，在司机端接单之前或者在司机端注册之后，需要创建司机身份信息卡，如果服务器判断得知司机端没有创建司机身份信息卡，则向司机端发送第一建卡指令，使其进行创建司机身份信息卡。可以理解的是，在司机创建司机身份信息卡之前，服务器可以不允许该司机端进行接单操作。
在司机端进行建卡时，服务器可以接收到司机端发送的司机身份信息，然后根据司机身份信息进行创建对应的司机身份信息卡。应当说明的是，服务器在接收到司机端发送的司机身份信息后，还可以先对司机身份信息进行合法性校验，如果校验通过，则创建对应的司机身份信息卡。可以理解的是，合法性校验为，司机端上传的头像是否为人脸头像、手机号是否符合手机号的正则表达式等等。
当之后司机的身份信息发生变化后，可以向服务器发送司机身份信息更新请求，服务器在接收到司机身份更新请求后对应更新该司机身份信息卡中的信息。应当说明的是，司机身份信息更新请求中可以包括第一待更新信息，还可以包括司机端标识。例如：司机的手机号有变更时，可以通过司机端向服务器端发送司机身份信息更新请求，司机身份信息更新请求中包括了将手机号A变更为B，当服务器接收到该司机身份信息更新请求后，对司机身份信息卡中的手机号进行变更操作。
本发明实施例通过接收司机端发送的司机身份信息更新请求，根据第一待更新信息更新司机端对应的司机身份信息卡，使得当司机身份信息有变动时，可以方便的对应更新，提高司机端的用户体验。
在上述实施例的基础上，所述方法，还包括：
服务器向司机端发送订单取消消息，所述订单取消消息中的订单取消理由为司机身份信息校验不一致之外的理由。
在具体的实施过程中，当服务器接收到乘客端发送的订单取消请求后，需要告知司机端该乘客已经取消了订单，但是为了保护乘客的人身安全，或者司机身份信息在被审核之前销毁不一致的信息，在向司机发送订单取消消息是，其订单取消消息中的订单取消理由可以是除司机身份信息校验不一致以外的其他理由，例如：可以是乘客行程有变等。
在上述实施例的基础上，所述方法，还包括：
若所述第一校验结果为校验一致，则服务器更新所述司机身份信息卡中的第一已验真次数。
在具体的实施过程中，服务器在接收到乘客端发送的校验一致的第一校验结果后，可以更新该司机端对应的司机身份信息卡中的第一已验真次数，即服务器接收到一次对该司机端的校验一致的第一校验结果，则对该司机身份信息卡中的第一已验证次数加1，通过在司机身份信息卡中显示第一已验真次数，可以使得乘客在看到这个司机身份信息卡之后，对该司机有一个初步的安全评估，从而提高用户体验。
在上述实施例的基础上，所述方法，还包括：
服务器判断当前场景是否为第一高危场景，若是，则向所述乘客端发送司机身份信息卡弹出指令；其中，判断为所述第一高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述司机身份信息卡的第一已验真次数低于第一预设次数；
所述司机端发生身份信息与卡片不一致的次数大于第二预设次数。
在具体的实施过程中，服务器在接收到乘客端发送的订单信息和接单司机的司机终端标识后，判断该订单信息所处的当前场景是否为第一高危场景，如果是第一高危场景，则向乘客端发送司机身份信息卡弹出指令，通过主动弹出的形式，来使乘客注意安全，并对司机的身份进行校验。应当说明的是，订单信息所处的当前场景满足以下任意一项，则服务器认为是第一高危场景：
1、乘客端发送订单信息时是处于预设高危时间段内；具体可以人工预先设定一天的中晚上11点到第二天凌晨6点之间为预设高危时间段，如果乘客端在该时间段内发送订单信息，或者订单信息中的乘车时间在该时间段内，则属于第一高危场景；
2、所述司机身份信息卡的第一已验真次数低于第一预设次数；当接单的司机身份信息卡中第一已验真次数低于第一预设次数时也认为是第一高危场景，其中第一预设次数可以根据实际情况进行设定，本发明实施例对此不作具体限定。
3、所述司机端发生身份信息与司机身份信息卡不一致的次数大于第二预设次数；当接单的司机身份信息与司机身份信息卡上的信息不一致的发生次数大于第二预设次数时，也认为是第一高危场景。应当说明的是，发生次数为有效的次数，而不是乘客端上报的次数，所谓有效的次数是乘客发送的校验不一致的第一校验结果审核属实的次数。
本发明实施例通过判断处于第一高危场景时，主动弹出司机身份校验卡来提示乘客要对司机的身份进行校验，从而降低了乘客乘车时发生危险的概率。
在上述实施例的基础上，在将所述司机端标识对应的司机身份信息卡发送至所述乘客端之前，还包括：
服务器接收所述乘客端发送的查看所述司机身份信息卡的请求。
在具体的实施过程中，服务器也可以不主动向乘客端发送接单司机的司机身份信息卡，而是接收到乘客端发送的查看司机身份信息卡的请求之后，向将该司机身份信息卡发送至乘客端，这样做的好处是，可以降低服务器的工作量。
在上述实施例的基础上，除了乘客可以查看接单司机的司机身份信息卡外，为了保障司机的人身安全，服务器也可以接收司机端标识对应的司机端发送的发单乘客的乘客身份信息卡，从而当司机到达乘客指定的上车点时，对乘客的身份信息进行校验。
在上述实施例的基础上，所述方法，还包括：
服务器接收所述司机端返回的第二校验结果，所述第二校验结果为发单乘客与所述乘客身份信息卡的一致性校验结果。
在具体的实施过程中，当司机对乘客身份信息卡和发单乘客的实际信息进行校验后，通过司机端向服务器发送第二校验结果，此时，服务器能够接收到该司机端返回的第二校验结果。应当说明的是，如果司机校验后发现乘客身份信息卡中的乘客身份信息与乘客实际信息一致，则第二校验结果为校验一致；如果司机校验后发现乘客身份信息卡中的乘客身份信息与乘客实际信息不一致，则第二校验结果为校验不一致。
本发明实施例通过接收司机端返回的第二校验结果来对乘客身份信息卡进行校验，一方面提高了司机安全性，另一方面起到了对乘客身份信息卡中信息进行监督的作用。
在上述实施例的基础上，在接收所述司机端返回的第二校验结果之后，所述方法，还包括：
若所述第二校验结果为校验不一致，且服务器接收到所述司机端发送的取消订单请求，则取消订单。
在具体的实施过程中，司机在对乘客身份信息卡进行校验后，如果发现乘客身份信息卡与乘客的实际信息不符，则可以将服务器发送校验不一致的第二校验结果，并且可以选择取消订单，当服务器接收到的第二校验结果为校验不一致，并且该司机要求取消订单时，则对该订单进行取消操作，以此来保证司机的出行安全。
在上述实施例的基础上，在接收所述司机端返回的第二校验结果之后，所述方法，还包括：
若所述第二校验结果为校验不一致，则服务器中止所述乘客端发单；并
服务器获取所述第二校验结果中包含的信息不一致的第二投诉类型；
根据所述第二投诉类型生成对应的第二申诉消息，将所述第二申诉消息发送至所述乘客端，以使所述乘客端进行申诉。
在具体的实施过程中，如果服务器接收到了司机端发送的校验不一致的第二校验结果后，先中止乘客端的发单行为，并且获取第二校验结果中包含的信息不一致的第二投诉类型，例如：乘客身份校验卡中的头像与乘客实际长相不不一致等等。服务器将第二投诉类型生成第二申诉消息，用来告知乘客有哪些信息需要进行申诉。假设是头像不一致，则在第一申诉消息中告知乘客头像不一致，请上传自证信息，此时，乘客端在接收到第二申诉消息后，将重新上传头像用以证明。应当说明的是，还可以通过其他的自证方式，本发明实施例对此不作具体限定。还应当说明的是，也可以对第二校验结果进行审核，如果审核属实后再中止乘客端的接单行为。
本发明实施例通过在接收到校验不一致的第二校验结果后，向乘客端发送第二申诉消息，在申诉通过之前中止乘客端接单，从而来保障司机乘车安全。
在上述实施例的基础上，所述方法，还包括：
服务器接收所述乘客端发送的乘客身份信息更新请求，所述乘客身份信息更新请求包括第二待更新信息；
根据所述第二待更新信息更新所述乘客端对应的乘客身份信息卡。
在具体的实施过程中，在乘客端发单之前或者在乘客端注册之后，需要创建乘客身份信息卡，如果服务器判断得知乘客端没有创建乘客身份信息卡，则向乘客端发送第二建卡指令，使其进行创建乘客身份信息卡。可以理解的是，在乘客创建司机身份信息卡之前，服务器可以不允许该乘客端进行发单操作。
在乘客端进行建卡时，服务器可以接收到乘客端发送的乘客身份信息，然后根据乘客身份信息进行创建对应的乘客身份信息卡。应当说明的是，服务器在接收到司机端发送的司机身份信息后，还可以先对乘客身份信息进行合法性校验，如果校验通过，则创建对应的乘客身份信息卡。可以理解的是，合法性校验为，乘客端上传的头像是否为人脸头像、手机号是否符合手机号的正则表达式等等。应当说明的是，乘客身份信息卡包括乘客头像、性别、手机号、乘车人数和第一已验真次数中任意一项或其组合，可以理解的是，乘客身份信息卡中还可以包括其他信息，本发明实施例对此不作具体限定。
当之后乘客的身份信息发生变化后，可以向服务器发送乘客身份信息更新请求，服务器在接收到乘客身份更新请求后对应更新该乘客身份信息卡中的信息。应当说明的是，乘客身份信息更新请求中可以包括第一待更新信息，还可以包括乘客端标识。例如：乘客的手机号有变更时，可以通过乘客端向服务器端发送乘客身份信息更新请求，乘客身份信息更新请求中包括了将手机号A变更为B，当服务器接收到该乘客身份信息更新请求后，对乘客身份信息卡中的手机号进行变更操作。
本发明实施例通过接收乘客端发送的乘客身份信息更新请求，根据第二待更新信息更新乘客端对应的乘客身份信息卡，使得当乘客身份信息有变动时，可以方便的对应更新，提高乘客端的用户体验。
在上述实施例的基础上，所述方法，还包括：
若所述第二校验结果为校验一致，则服务器更新所述乘客身份信息卡中的第二已验真次数。
在具体的实施过程中，服务器在接收到司机端发送的校验一致的第二校验结果后，可以更新该乘客端对应的乘客身份信息卡中的第二已验真次数，即服务器接收到一次对该乘客端的校验一致的第一校验结果，则对该乘客身份信息卡中的第一已验证次数加1，通过在乘客身份信息卡中显示第一已验真次数，可以使得司机在看到这个乘客身份信息卡之后，对该乘客有一个初步的安全评估，从而提高用户体验。
在上述实施例的基础上，所述方法，还包括：
服务器判断当前场景是否为第二高危场景，若是，则向所述司机端发送乘客身份信息卡弹出指令；其中，判断为所述第二高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述乘客身份信息卡的第二已验真次数低于第三预设次数；
所述乘客端发生身份信息与乘客身份信息卡不一致的次数大于第四预设次数。
在具体的实施过程中，服务器在接收到乘客端发送的订单信息和接单司机的司机终端标识后，判断该订单信息所处的当前场景是否为第二高危场景，如果是第二高危场景，则向司机端发送乘客身份信息卡弹出指令，通过主动弹出的形式，来使司机注意安全，并对乘客的身份进行校验。应当说明的是，订单信息所处的当前场景满足以下任意一项，则服务器认为是第二高危场景：
1、乘客端发送订单信息时是处于预设高危时间段内；具体可以人工预先设定一天的中晚上11点到第二天凌晨6点之间为预设高危时间段，如果乘客端在该时间段内发送订单信息，或者订单信息中的乘车时间在该时间段内，则属于第二高危场景；
2、所述乘客身份信息卡的第二已验真次数低于第三预设次数；当发单的乘客身份信息卡中第二已验真次数低于第三预设次数时也认为是第二高危场景，其中第三预设次数可以根据实际情况进行设定，本发明实施例对此不作具体限定。
3、所述乘客端发生身份信息与乘客身份信息卡不一致的次数大于第四预设次数；当发单的乘客身份信息与乘客身份信息卡上的信息不一致的发生次数大于第四预设次数时，也认为是第二高危场景。应当说明的是，发生次数为有效的次数，而不是司机端上报的次数，所谓有效的次数是司机发送的校验不一致的第一校验结果审核属实的次数。
图5为本发明实施例提供的一种司机端验证乘客身份流程示意图，如图5所示，包括：
步骤501：司机到达始发地；司机端到达乘客发送的订单信息中的始发地后，向服务器发送到达始发地的消息；
步骤502：是否为高危场景；服务器判断当前是否处于第二高位场景，如果是则执行步骤504，否则执行步骤503；
步骤503：显示乘客身份信息卡；向司机端发送乘客身份信息卡显示消息，使得在司机端显示查看乘客身份信息卡入口；
步骤504：弹出乘客身份信息卡；弹出乘客身份信息卡，提醒司机对乘客身份信息进行校验；
步骤505：返回第二校验结果；若司机校验后，向服务器发送第二校验结果，其中，第二校验结果包括校验一致和校验不一致。
本发明实施例通过判断处于第二高危场景时，主动弹出乘客身份校验卡来提示司机要对乘客的身份进行校验，从而降低了司机工作时发生危险的概率。
在上述实施例的基础上，在向所述司机端标识对应的司机端发送所述乘客端对应的乘客身份信息卡之前，所述方法，还包括：
服务器接收所述司机端发送的查看所述乘客身份信息卡的请求。
在具体的实施过程中，服务器也可以不主动向司机端发送发单乘客的乘客身份信息卡，而是接收到司机端发送的查看乘客身份信息卡的请求之后，向将该乘客身份信息卡发送至司机端，这样做的好处是，可以降低服务器的工作量。
在上述实施例的基础上，所述方法，还包括：
若服务器接收到所述乘客端返回的第一校验结果和所述司机端返回的第二校验结果均为校验一致，则开始行程。
在具体的实施过程中，在服务器接到的乘客端返回的第一校验结果和司机端返回的第二校验结果都为校验一致时，则认为乘客和司机都是安全的，此时开始行程。另外，在开始行程之前，服务器也可以接收到乘客端和司机端均发送的开始行程的请求后再开始行程。从而能够同时提高乘客和司机的出行安全性。
在上述实施例的基础上，所述方法，还包括：
若所述第一校验结果为校验不一致，且接收到所述乘客端发送的开始行程请求，则服务器向所述乘客端发送安全告警提示，并开始行程。
在具体的实施过程中，如果服务器接收到的乘客端发送的校验不一致的第一校验结果，同时，也收到的乘客端发送的开始行程请求，则表示即便是乘客认为司机的身份与司机身份信息卡不一致，但仍然要乘车，此时，服务器向乘客终端发送安全告警提示，并开始行程。
本发明实施例通过在接收到校验不一致的第一校验结果，且接收到乘客端发送的开始行程请求后，对其进行安全告知提示，使其能够提高安全防范意识，降低事故发生的概率。
在上述实施例的基础上，所述方法，还包括：
服务器接收所述乘客端发送的第一护航模式开启请求；
服务器实时获取所述订单信息对应的车辆的行驶轨迹，将所述行驶轨迹发送至所述乘客端预先设置的第一紧急联系终端。
在具体的实施过程中，当乘客端向服务器发送了订单信息后，在乘客端的显示屏上显示第一安全模式入口，图6为本发明实施例提供的乘客端第一安全模式入口示意图，如图6所示，乘客可以点击该第一安全模式入口，然后弹出是否开启第一安全模式的提示框，当乘客选择开启后，在第一安全模式下，乘客可以选择开始多个安全功能供其选择，其中，安全功能可以包括第一护航模式、录音、摄像、拍照以及拨打紧急电话等功能。图7为本发明实施例提供的乘客端开启护航模式界面示意图，如图7所示，若服务器接收到乘客端发送的第一护航模式开启请求，则实时获取订单信息对应的车辆的行驶轨迹，并且将该行驶轨迹发送至该乘客终端预先设置的第一紧急联系终端，从而实现乘客端与第一紧急联系终端之间的位置共享，使得第一紧急联系人能够实时掌握乘客的位置信息。
应当说明的是，在乘客端发送第一护航模式开启请求之后，服务器判断得知乘客端中没有预先设置第一紧急联系终端，则向乘客端发送添加第一紧急联系终端的指令，在接收到乘客端发送的第一紧急联系终端的标识后，将该乘客端与第一紧急联系终端进行绑定。其中，第一紧急联系终端可以有一个，也可以有多个。
在上述实施例的基础上，在接收所述乘客端发送的第一护航模式开启请求之后，所述方法，还包括：
服务器根据所述行驶轨迹判断是否处于第三高危场景，若是，则向所述乘客端发送第一安全询问提示；
若在第二预设时间段内服务器没有接收到所述乘客端返回的第一安全确认消息或接收到所述乘客端返回的第一紧急求助消息，则向所述第一紧急联系终端发送报警提示；其中，
判断为所述第三高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于第三预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
在具体的实施过程中，图8为本发明实施例提供的安全询问界面示意图，如图8所示，在行程开始，并且服务器接收到乘客端发送的第一护航模式开启请求后，服务器实时获取车辆的行驶轨迹，如果服务器根据行驶轨迹判断得知当前乘客处于第三高危场景，则向乘客端发送第一安全询问提示，其中，可以是以弹出框的形式提示，告知乘客“监测到行驶异常，是否发生事故，如果在第二预设时间段内没有收到回复，则为其报警”。
如果服务器在第二预设时间段内没有接收到乘客端返回的第一安全确认消息，或者接收到乘客端返回的第一紧急求助消息，则获知该乘客发生了事故，此时，服务器向该乘客端对应的第一紧急联系终端发送报警提示，同时，也可以进行110或120报警。
应当说明的是，当服务器判断行驶轨迹出现下述任意一种情况时，即为得知处于第三高危场景：
1、在开始行程之前，服务器可以为订单信息规划至少一条路线，司机和乘客可以从中选择一条路线进行行驶，如果服务器监测到行驶轨迹偏离预设路线，则判断为处于第三高危场景；
2、当前车辆行驶的距离超过的预设距离，其中，预设距离可以是预先设定的固定距离，也可以是根据规划的路线设定的，例如：当超过规划路线距离5km后，则判断为处于第三高危场景；
3、在到达目的地之前，如果司机端所开的车辆停留时长大于第三预设时间段，则说明处于第三高危场景。应当说明的是，若出现堵车情况，可能在路上停留的时间较长，如果服务器从电子地图上判断车辆所处的路段为拥堵路段，则可以不认为是第三高危场景，当然，为了更好地保证乘客安全，也可以认为是处于第三高危场景，向乘客端发送第一安全询问提示；
4、预先设定一天中的晚上11点到第二天凌晨6点之前为高危时间段，如果乘客端在该时间段内乘车，则认为是第三高危场景；
5、在服务器获取到预设路线后，还可以为该预设路线计算预估到达时长，如果行驶时长大于预估到达时长和预留时长之和，则认为处于第三高危场景。
本发明实施例在乘客开启第一安全模式的情况下，当判断当前场景处于第三高危场景时，则向乘客端发送第一安全询问提示，从而提高了乘客乘车的安全系数。
在上述实施例的基础上，所述方法，还包括：
服务器接收所述司机端发送的第二护航模式开启请求；
服务器实时获取所述订单信息对应的车辆的行驶轨迹，将所述行驶轨迹发送至所述司机端预先设置的第二紧急联系终端。
在具体的实施过程中，在实际中，司机也可能会遇到危险，因此当司机端向服务器发送了接单信息后，在司机端的显示屏上显示第二安全模式入口，司机可以点击该第二安全模式入口，然后弹出是否开启第二安全模式的提示框，当司机选择开启后，在第二安全模式下，司机可以选择开始多个安全功能供其选择，其中，安全功能可以包括第二护航模式、录音、摄像、拍照以及拨打紧急电话等功能。若服务器接收到司机端发送的第二护航模式开启请求，则实时获取订单信息对应的车辆的行驶轨迹，并且将该行驶轨迹发送至该司机终端预先设置的第二紧急联系终端，从而实现司机端与第二紧急联系终端之间的位置共享，使得第二紧急联系人能够实时掌握司机的位置信息。
应当说明的是，在司机端发送第二护航模式开启请求之后，服务器判断得知司机端中没有预先设置第二紧急联系终端，则向司机端发送添加第二紧急联系终端的指令，在接收到司机端发送的第二紧急联系终端的标识后，将该司机端与第二紧急联系终端进行绑定。其中，第二紧急联系终端可以有一个，也可以有多个。
在上述实施例的基础上，在接收所述司机端发送的第二护航模式开启请求之后，所述方法，还包括：
服务器根据所述行驶轨迹判断是否处于第四高危场景，若是，则向所述司机端发送第二安全询问提示；
若在预设时间段内没有服务器接收到所述司机端返回的第二安全确认消息或接收到所述司机端返回的第二紧急求助消息，则向所述第二紧急联系终端发送报警提示；其中，
判断为所述第四高危场景所满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
在具体的实施过程中，在行程开始，并且服务器接收到司机端发送的第二护航模式开启请求后，服务器实时获取车辆的行驶轨迹，如果服务器根据行驶轨迹判断得知当前司机处于第四高危场景，则向司机端发送第二安全询问提示，其中，可以是以弹出框的形式提示，告知司机“监测到行驶异常，是否发生事故，如果在第四预设时间段内没有收到回复，则为其报警”。
如果服务器在第四预设时间段内没有接收到司机端返回的第二安全确认消息，或者接收到司机端返回的第二紧急求助消息，则获知该司机发生了事故，此时，服务器向该司机端对应的第二紧急联系终端发送报警提示，同时，也可以进行110或120报警。
应当说明的是，服务器在判断当前场景是否处于第四高危场景的条件与第三高危场景类似，此处不再赘述。
本发明实施例在司机开启第二安全模式的情况下，当判断当前场景处于第四高危场景时，则向司机端发送第二安全询问提示，从而提高了司机出行的安全系数。
图9为本发明实施例提供的另一种身份信息安全校验方法流程示意图，如图9所示，该方法包括：
步骤901：服务器接收乘客端发送的订单信息，以及对应接单的司机端标识；
在具体的实施过程中，乘客需要通过打车软件进行打车时，首先通过乘客端向服务器发送订单信息，此时，服务器接收到乘客端发送的订单信息，并将订单信息发送至相应的司机端，应当说明的是，服务器在向司机端发送该订单信息时，可以根据内置算法选择满足条件的司机端进行发送，也可以以广播的方式发送至司机端，还可以是直接将订单分配给某个司机端。当某个司机端接到该订单信息后，服务器会接收到对应接单的司机端标识，其中，司机端标识可以是司机的注册账号，也可以是其他能够唯一标识该司机的信息，本发明实施例对此不作具体限定。
步骤902：服务器将所述乘客端对应的乘客身份信息卡发送至所述司机端标识对应的司机端。
在具体的实施过程中，服务器在接收到接单司机的司机标识之后，将该订单信息对应的乘客身份信息卡发送至司机端，以使司机能够通过司机端接收的乘客身份信息卡对发单乘客进行校验，判断接收到的乘客身份信息卡中的乘客身份信息与实际乘车的乘客信息是否一致。应当说明的是，服务器可以在接收到司机端标识之后主动向司机端发送乘客身份信息卡，也可以是在司机端发送要查看乘客身份的请求后，再向司机端发送对应的乘客身份信息卡。可以理解的是，乘客身份信息卡中可以包括：乘客头像、性别、手机号、乘车人数和第一已验真次数等等，当司机到达乘客所要乘车地点时，司机可以将司机端接收到的乘客身份信息卡中的各个信息与乘客的实际信息进行校验，例如：查看头像与乘客的面部特征是否一致、性别是否一致、乘车人数是否一致等等。
本发明实施例通过将发单乘客的乘客身份信息卡发送至司机端，使得司机可以根据在司机端接收到的乘客身份信息卡与乘客的实际信息进行校验，从而提高了司机出行的安全性。
图10为本发明实施例提供的又一种身份信息安全校验方法流程示意图，如图10所示，该方法包括：
步骤1001：乘客端向服务器发送订单信息；
在具体的实施过程中，乘客需要乘车时，通过乘客端向服务器发送订单信息，其中，订单信息中可以包括乘客端标识、乘车时间、始发地、目的地、乘车人数等信息。
步骤1002：乘客端接收所述服务器返回的接单司机的司机身份信息卡。
在具体的实施过程中，服务器在接收到乘客端发送的订单信息后，将该订单信息发布到司机端，其发布的方式可以是经过内部算法后发布给满足预设条件的司机端，也可以分配给某一个司机端，还可以进行广播，使所有的司机端根据自身情况进行抢单，因此，对于发布订单消息的方式本发明实施例对此不作具体限定。当有司机端接单后，会向服务器发送接单请求，接单请求中可以包括司机端标识，服务器可以根据司机端标识获取对应的司机身份信息卡，并将获取到的司机身份信息卡发送至乘客端，乘客端在接收到服务器发送的司机身份信息卡之后，可以通过司机身份信息卡与接单司机的实际信息进行校验。
由于司机在打车软件中进行注册时，是需要进行身份审核的，因此，注册司机的身份信息都是真实的，相对来说比较安全，但是如果其他人冒用注册司机的身份来接单，这时，接单司机的身份是无法保证的，并且当发生事故后，追诉这个接单司机的难度也比较大，因此，需要为注册司机创建对应的司机身份信息卡，然后将司机身份信息卡与接单司机的实际身份进行校验，从而来判断来接单的司机是否与注册司机的身份一致，以此来保障乘客乘车的安全。
在上述实施例的基础上，在接收所述服务器返回的接单司机的司机身份信息卡之后，所述方法，还包括：
乘客端在显示界面上显示查看所述司机身份信息卡的入口；
乘客端接收针对所述入口的触发操作，显示司机身份信息卡。
在具体的实施过程中，在服务器将司机身份信息卡发送至乘客端后，可以在乘客端的显示界面上显示查看司机身份信息卡的入口，从而可以使乘客点击该入口来实现查看司机身份信息的操作，具体为当乘客点击该入口后，乘客端可以接收到该触发操作，此时将接收到的司机身份信息卡进行显示。可以理解的是，该入口可以是以条形弹窗的形式出现在显示屏幕的顶部，也可以以浮窗的形式出现，本发明实施例对此不作具体限定。
应当说明的是，当该订单的行程结束后，乘客端需关闭查看司机身份信息卡的入口，此时，该入口从乘客端的显示界面上消失。
在上述实施例的基础上，所述方法，还包括：
乘客端向所述服务器发送第一校验结果，所述第一校验结果为接单司机与所述司机身份信息卡的一致性校验结果，所述第一校验结果包括校验一致和校验不一致。
在具体的实施过程中，在乘客端接收到服务器发送的司机身份信息卡，并校验后，将第一校验结果通过乘客端发送至服务器，具体为在乘客端显示界面上以弹出悬浮窗的形式将司机身份信息卡弹出，在乘客校验完成后可以选择校验一致或校验不一致，并将第一校验结果发送至服务器，从而完成校验。应当说明的是，在司机身份信息卡弹出的情况下，当乘客点击司机身份信息卡之外的屏幕区域时，司机身份信息卡的弹窗消失。
另外，为了实现互相校验，当乘客端要查看司机身份信息卡时，服务器还可以判断乘客端是否已创建对应的乘客身份信息卡，如果没有创建，则向该乘客端发送乘客身份信息卡创建指令，在乘客端接收到该乘客身份信息卡创建指令后，将所需要的乘客身份信息发送至服务器，以使服务器根据乘客身份信息创建对应的乘客身份信息卡。应当说明的是，在创建乘客身份信息卡之前，服务器还可以对接收到的乘客身份信息进行合法校验，如果校验通过再进行建卡操作。可以理解的是，乘客身份信息包括乘客头像、性别、手机号、乘车人数和第一已验真次数中任意一项或其组合，也可以包括其他信息，本发明实施例对此不作具体限定。
本发明实施例通过向乘客端发送司机身份信息卡使其进行校验提高了乘客的乘车安全性，通过创建乘客身份信息卡可以供司机查看校验，提高了司机出行安全性。
在上述实施例的基础上，所述方法，还包括：
乘客端接收所述服务器发送的第二申诉消息，所述第二申诉消息是根据接单的司机端发送的第二投诉类型生成的；
乘客端根据所述第二申诉消息向所述服务器发送第二申诉请求，所述第二申诉请求包括第二申诉证明信息。
在具体的实施过程中，如果服务器接收到了司机端发送的校验不一致的第二校验结果后，可以先中止乘客端的发单行为，并且获取第二校验结果中包含的信息不一致的第二投诉类型，例如：乘客身份校验卡中的头像与乘客实际长相不不一致等等。服务器将第二投诉类型生成第二申诉消息，用来告知乘客有哪些信息需要进行申诉。假设是头像不一致，则在第一申诉消息中告知乘客头像不一致，请上传自证信息，此时，乘客端在接收到第二申诉消息后，将重新上传头像用以证明。应当说明的是，还可以通过其他的自证方式，本发明实施例对此不作具体限定。还应当说明的是，也可以对第二校验结果进行审核，如果审核属实后再中止乘客端的接单行为。
本发明实施例通过在接收到校验不一致的第二校验结果后，向乘客端发送第二申诉消息，在申诉通过之前中止乘客端接单，从而来保障司机乘车安全。
在上述实施例的基础上，所述方法，还包括：
乘客端向所述服务器发送第一护航模式开启请求，以使所述服务器实时将所述订单信息对应的车辆的位置信息发送至预先设置的第一紧急联系终端。
在具体的实施过程中，当乘客端向服务器发送了订单信息后，在乘客端的显示屏上显示第一安全模式入口，乘客可以点击该第一安全模式入口，然后弹出是否开启第一安全模式的提示框，当乘客选择开启后，在第一安全模式下，乘客可以选择开始多个安全功能供其选择，其中，安全功能可以包括第一护航模式、录音、摄像、拍照以及拨打紧急电话等功能。若乘客通过乘客端选择了开启第一护航模式，则向服务器发送第一护航模式开启请求，服务器接收到该第一护航模式开启请求后实时获取订单信息对应的车辆的行驶轨迹，并且将该行驶轨迹发送至该乘客端预先设置的第一紧急联系终端，从而实现乘客端与第一紧急联系终端之间的位置共享，使得第一紧急联系人能够实时掌握乘客的位置信息。
应当说明的是，在乘客端发送第一护航模式开启请求之后，服务器判断得知乘客端中没有预先设置第一紧急联系终端，则向乘客端发送添加第一紧急联系终端的指令，在接收到乘客端发送的第一紧急联系终端的标识后，将该乘客端与第一紧急联系终端进行绑定。其中，第一紧急联系终端可以有一个，也可以有多个。
在上述实施例的基础上，所述方法，还包括：
乘客端接收所述服务器发送的第一安全询问提示，所述第一安全询问提示为服务器判断处于第三高危场景时发送的；
乘客端根据所述第一安全询问提示向所述服务器发送第一应答消息；其中，
所述第三高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
在具体的实施过程中，在行程开始时，并且服务器接收到乘客端发送的第一护航模式开启请求后，服务器实时获取车辆的行驶轨迹，如果服务器根据行驶轨迹判断得知当前乘客处于第三高危场景，则向乘客端发送第一安全询问提示，其中，可以是以弹出框的形式提示，告知乘客“监测到行驶异常，是否发生事故，如果在第二预设时间段内没有收到回复，则为其报警”。乘客端在接收到第一安全询问提示后，乘客根据当前实际情况通过乘客端返回第一应答消息，其中，第一应答消息可以包括安全或不安全。
如果服务器在第二预设时间段内没有接收到乘客端返回的第一应答消息，或者接收到乘客端返回的第一应答消息为第一紧急求助消息，则获知该乘客发生了事故，此时，服务器向该乘客端对应的第一紧急联系终端发送报警提示，同时，也可以进行110或120报警。
应当说明的是，当服务器判断处于第三高危场景的条件与上述实施例一致，此处不再赘述。
本发明实施例在乘客开启第一安全模式的情况下，当判断当前场景处于第三高危场景时，则向乘客端发送第一安全询问提示，从而提高了乘客乘车的安全系数。
在上述实施例的基础上，所述方法，还包括：
乘客端接收针对第一安全模式下的安全保障功能的触发操作，根据所述安全保障功能进行相应的安全操作，其中，所述安全保障功能包括录音、录像和拨打紧急救助电话。
在具体的实施过程中，乘客端处于第一安全模式下，如果接收到乘客点击安全保障功能的触发操作时，可以根据乘客的触发执行相应的安全操作。可以理解的是，安全模式下提供给乘客一些安全保障功能，例如：录音、录像、拨打紧急救助电话、拍照等等。例如：乘客端接收到乘客点击录音的安全保障功能后，则开启录音功能。应当说明的是，安全保障功能还可以为其他在紧急情况下所需的功能，本发明实施例对此不作具体限定。
本发明实施例通过在第一安全模式下设置安全保障功能，当乘客在乘车时发生紧急情况下能够方便快捷的进行相应的紧急救助操作，从而提高乘客乘车的安全性。
图11为本发明实施例提供的又一种身份信息安全校验方法流程示意图，如图11所示，该方法包括：
步骤1101：司机端向服务器发送接单请求，所述接单请求包括所接乘客的订单信息；
在具体的实施过程中，当司机端想要接收乘客发送的订单信息时，向服务器发送接单请求，其中，接单请求中包括所接乘客的订单信息，以告知服务器要接哪个乘客的单，另外，在接单请求中还可以包括司机端标识，以使服务器获知是哪个司机端在接单。
步骤1102：司机端接收所述服务器返回的所述订单信息对应的乘客身份信息卡。
在具体的实施过程中，服务器在接收到接单司机的接单请求后，将该订单信息对应的乘客身份信息卡发送至司机端，以使司机能够通过司机端接收的乘客身份信息卡对发单乘客进行校验，判断接收到的乘客身份信息卡中的乘客身份信息与实际乘车的乘客信息是否一致。应当说明的是，服务器可以在接收到司机端标识之后主动向司机端发送乘客身份信息卡，也可以是在司机端发送要查看乘客身份的请求后，再向司机端发送对应的乘客身份信息卡。可以理解的是，乘客身份信息卡中可以包括：乘客头像、性别、手机号、乘车人数和第一已验真次数等等，当司机到达乘客所要乘车地点时，司机可以将司机端接收到的乘客身份信息卡中的各个信息与乘客的实际信息进行校验，例如：查看头像与乘客的面部特征是否一致、性别是否一致、乘车人数是否一致等等。
本发明实施例通过将发单乘客的乘客身份信息卡发送至司机端，使得司机可以根据在司机端接收到的乘客身份信息卡与乘客的实际信息进行校验，从而提高了司机出行的安全性。
在上述实施例的基础上，在接收所述服务器返回的所述订单信息对应的乘客身份信息卡之后，所述方法，还包括：
司机端向所述服务器发送第二校验结果，所述第二校验结果为发单乘客与所述乘客身份信息卡的一致性校验结果，所述第二校验结果包括校验一致和校验不一致并取消订单。
在具体的实施过程中，当司机对乘客身份信息卡和发单乘客的实际信息进行校验后，通过司机端向服务器发送第二校验结果。应当说明的是，如果司机校验后发现乘客身份信息卡中的乘客身份信息与乘客实际信息一致，则第二校验结果为校验一致；如果司机校验后发现乘客身份信息卡中的乘客身份信息与乘客实际信息不一致，则第二校验结果为校验不一致，并且可以要求取消订单。
本发明实施例通过司机端向服务器返回的第二校验结果来对乘客身份信息卡进行校验，一方面提高了司机安全性，另一方面起到了对乘客身份信息卡中信息进行监督的作用。
在具体的实施过程中，在司机端接单之前或者在司机端注册之后，需要创建司机身份信息卡，如果服务器判断得知司机端没有创建司机身份信息卡，则向司机端发送司机身份信息卡创建指令，当司机端接收到司机身份信息卡创建指令后进行创建司机身份信息卡。可以理解的是，在司机创建司机身份信息卡之前，服务器可以不允许该司机端进行接单操作。
在司机端进行建卡时，司机端将司机身份信息发送至服务器，服务器在接收到司机身份信息后创建对应的司机身份信息卡。应当说明的是，服务器在接收到司机端发送的司机身份信息后，还可以先对司机身份信息进行合法性校验，如果校验通过，则创建对应的司机身份信息卡。可以理解的是，合法性校验为，司机端上传的头像是否为人脸头像、手机号是否符合手机号的正则表达式等等。
当之后司机的身份信息发生变化后，可以向服务器发送司机身份信息更新请求，服务器在接收到司机身份更新请求后对应更新该司机身份信息卡中的信息。应当说明的是，司机身份信息更新请求中可以包括第一待更新信息，还可以包括司机端标识。例如：司机的手机号有变更时，可以通过司机端向服务器端发送司机身份信息更新请求，司机身份信息更新请求中包括了将手机号A变更为B，当服务器接收到该司机身份信息更新请求后，对司机身份信息卡中的手机号进行变更操作。
本发明实施例通过司机端接收服务器发送的司机身份信息卡创建指令进行司机身份信息卡的创建，使得乘客在乘车之前能够对司机身份进行校验，提高了乘客乘车的安全性。
在上述实施例的基础上，所述方法，还包括：
司机端接收所述服务器发送的第一申诉消息，所述第一申诉消息是根据发单的乘客端发送的第一投诉类型生成的；
根据所述第一申诉消息向所述服务器发送第一申诉请求，所述第一申诉请求包括第一申诉证明信息。
在具体的实施过程中，如果服务器接收到了乘客端发送的校验不一致的第一校验结果后，先中止司机端的接单行为，并且获取第一校验结果中包含的信息不一致的第一投诉类型，例如：司机身份校验卡中的头像与司机实际长相不同、注册车牌号与司机实际驾驶的车辆的车牌号不一致等等。服务器将第一投诉类型生成第一申诉消息，用来告知司机有哪些信息需要进行申诉，此时司机端可以根据第一申诉消息向服务器发送第一申诉请求，其中，在第一申诉请求中包括有第一申诉证明信息。假设是头像不一致，则在第一申诉消息中告知司机头像不一致，请上传自证信息，此时，司机端在接收到第一申诉消息后，将重新上传头像用以证明。应当说明的是，还可以通过其他的自证方式，本发明实施例对此不作具体限定。还应当说明的是，也可以对第一校验结果进行审核，如果审核属实后再中止司机端的接单行为。
另外，还可以设定申诉的第一预设时间段，如果司机端在第一预设时间段内没有申诉通过，则停用该司机端，此时需要司机终端重新创建司机身份信息卡，创建完成后才能够重新使用司机端接单。可以理解的是，司机端在第一预设时间段内没有申诉通过的情况可以是司机端在第一预设时间段内没有提交自证信息；也可以是，司机端在第一预设时间段内提交了自证信息，但是所提交的自证信息未通过。
本发明实施例通过在接收到校验不一致的第一校验结果后，向司机端发送第一申诉消息，在申诉通过之前中止司机端接单，从而来保障乘客乘车安全。
在上述实施例的基础上，所述方法，还包括：
司机端向所述服务器发送第二护航模式开启请求，以使所述服务器实时将所述订单信息对应的车辆的位置信息发送至预先设置的第二紧急联系终端。
在具体的实施过程中，当司机端向服务器发送了接单请求后，在司机端的显示屏上显示第二安全模式入口，司机可以点击该第二安全模式入口，然后弹出是否开启第二安全模式的提示框，当司机选择开启后，在第二安全模式下，司机可以选择开始多个安全功能供其选择，其中，安全功能可以包括第二护航模式、录音、摄像、拍照以及拨打紧急电话等功能。若司机通过司机端选择了开启第二护航模式，则向服务器发送第二护航模式开启请求，服务器接收到该第二护航模式开启请求后实时获取订单信息对应的车辆的行驶轨迹，并且将该行驶轨迹发送至该司机端预先设置的第二紧急联系终端，从而实现司机端与第二紧急联系终端之间的位置共享，使得第二紧急联系人能够实时掌握司机的位置信息。
应当说明的是，在司机端发送第二护航模式开启请求之后，服务器判断得知司机端中没有预先设置第二紧急联系终端，则向司机端发送添加第二紧急联系终端的指令，在接收到司机端发送的第二紧急联系终端的标识后，将该司机端与第二紧急联系终端进行绑定。其中，第二紧急联系终端可以有一个，也可以有多个。
在上述实施例的基础上，所述方法，还包括：
司机端接收所述服务器发送的第二安全询问提示，所述第二安全询问提示为服务器判断处于第四高危场景时发送的；
司机端根据所述第二安全询问提示向所述服务器发送第二应答消息；其中，
所述第四高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
在具体的实施过程中，在行程开始时，并且服务器接收到司机端发送的第二护航模式开启请求后，服务器实时获取车辆的行驶轨迹，如果服务器根据行驶轨迹判断得知当前司机处于第三高危场景，则向司机端发送第二安全询问提示，其中，可以是以弹出框的形式提示，告知司机“监测到行驶异常，是否发生事故，如果在第二预设时间段内没有收到回复，则为其报警”。司机端在接收到第二安全询问提示后，司机根据当前实际情况通过司机端返回第二应答消息，其中，第二应答消息可以包括安全或不安全。
如果服务器在预设时间段内没有接收到司机端返回的第二应答消息，或者接收到司机端返回的第二应答消息为第二紧急求助消息，则获知该司机发生了事故，此时，服务器向该司机端对应的第二紧急联系终端发送报警提示，同时，也可以进行110或120报警。
应当说明的是，当服务器判断处于第四高危场景的条件与上述实施例一致，此处不再赘述。
本发明实施例在司机开启第二安全模式的情况下，当判断当前场景处于第四高危场景时，则向司机端发送第二安全询问提示，从而提高了司机出行的安全系数。
在上述实施例的基础上，所述方法，还包括：
司机端接收针对第二安全模式下的安全保障功能的触发操作，根据所述安全保障功能进行相应的安全操作，其中，所述安全保障功能包括录音、摄像和拨打紧急救助电话。
在具体的实施过程中，司机端处于第二安全模式下，如果接收到司机点击安全保障功能的触发操作时，可以根据司机的触发执行相应的安全操作。可以理解的是，安全模式下提供给司机一些安全保障功能，例如：录音、录像、拨打紧急救助电话、拍照等等。例如：司机端接收到司机点击录音的安全保障功能后，则开启录音功能。应当说明的是，安全保障功能还可以为其他在紧急情况下所需的功能，本发明实施例对此不作具体限定。
本发明实施例通过在第二安全模式下设置安全保障功能，当司机在驾驶时发生紧急情况下能够方便快捷的进行相应的紧急救助操作，从而提高司机出行的安全性。
图12为本发明实施例提供的一种服务器结构示意图，如图12所示，该服务器，包括：第一接收模块1201和第一发送模块1202，其中：
第一接收模块1201用于接收乘客端发送的订单信息，以及对应接单的司机端标识；
第一发送模块1202用于将所述司机端标识对应的司机身份信息卡发送至所述乘客端。
在上述实施例的基础上，所述服务器，还包括：
第二接收模块，用于接收所述乘客端返回的第一校验结果，所述第一校验结果为接单司机与所述司机身份信息卡的一致性校验结果。
在上述实施例的基础上，所述服务器，还包括：
第一订单取消模块，用于若所述第一校验结果为校验不一致，则取消订单。
在上述实施例的基础上，所述服务器，还包括：
第二订单取消模块，用于若所述第一校验结果为校验不一致，且接收到所述乘客端发送的取消订单请求，则取消订单且免收订单取消费。
在上述实施例的基础上，所述服务器，还包括：
第三订单取消模块，用于若所述第一校验结果为校验不一致，且接收到所述乘客端发送的取消订单请求，则取消订单并向所述乘客端收取取消订单费；
审核所述第一校验结果是否属实；若属实，将所述取消订单费退回至所述乘客端。
在上述实施例的基础上，所述第三订单取消模块，具体用于：
若审核确定所述第一校验结果不属实，则向所述司机端发放订单取消补偿费。
在上述实施例的基础上，所述服务器，还包括：
第一投诉模块，用于若所述第一校验结果为校验不一致，则中止所述司机端接单；并
获取所述第一校验结果中包含的信息不一致的第一投诉类型；
根据所述第一投诉类型生成对应的第一申诉消息，将所述第一申诉消息发送至所述司机端，以使所述司机端进行申诉。
在上述实施例的基础上，所述服务器，还包括：
停用模块，用于若在第一预设时间段内所述司机端申诉未通过，则停用所述司机端。
在上述实施例的基础上，所述服务器，还包括：
第三接收模块，用于接收所述司机端发送的司机身份信息更新请求，所述司机身份信息更新请求包括第一待更新信息；
根据所述第一待更新信息更新所述司机端对应的司机身份信息卡。
在上述实施例的基础上，所述服务器，还包括：
第二发送模块，用于向司机端发送订单取消消息，所述订单取消消息中的订单取消理由为司机身份信息校验不一致之外的理由。
在上述实施例的基础上，所述服务器，还包括：
第三发送模块，用于若所述司机端未创建所述司机身份信息卡，则向所述司机端发送第一建卡指令。
在上述实施例的基础上，所述服务器，还包括：
司机卡创建模块，用于接收所述司机端发送的司机身份信息，根据所述司机身份信息创建所述司机身份信息卡。
在上述实施例的基础上，所述司机身份信息卡包括司机头像、性别、手机号、注册车牌、注册车辆型号和第一已验真次数中任意一个或其组合。
在上述实施例的基础上，所述服务器，还包括：
第一更新模块，用于若所述第一校验结果为校验一致，则更新所述司机身份信息卡中的第一已验真次数。
在上述实施例的基础上，所述服务器，还包括：
第一弹出模块，用于判断当前场景是否为第一高危场景，若是，则向所述乘客端发送司机身份信息卡弹出指令；其中，判断为所述第一高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述司机身份信息卡的第一已验真次数低于第一预设次数；
所述司机端发生身份信息与司机身份信息卡不一致的次数大于第二预设次数。
在上述实施例的基础上，所述服务器，还包括：
第四接收模块，用于接收所述乘客端发送的查看所述司机身份信息卡的请求。
在上述实施例的基础上，所述服务器，还包括：
第四发送模块，用于向所述司机端标识对应的司机端发送所述乘客端对应的乘客身份信息卡。
在上述实施例的基础上，所述服务器，还包括：
第五接收模块，用于接收所述司机端返回的第二校验结果，所述第二校验结果为发单乘客与所述乘客身份信息卡的一致性校验结果。
在上述实施例的基础上，所述服务器，还包括：
第四取消订单模块，用于若所述第二校验结果为校验不一致，且接收到所述司机端发送的取消订单请求，则取消订单。
在上述实施例的基础上，所述服务器，还包括：
第二投诉模块，用于若所述第二校验结果为校验不一致，则中止所述乘客端发单；并
获取所述第二校验结果中包含的信息不一致的第二投诉类型；
根据所述第二投诉类型生成对应的第二申诉消息，将所述第二申诉消息发送至所述乘客端，以使所述乘客端进行申诉。
在上述实施例的基础上，所述服务器，还包括：
第二更新模块，用于接收所述乘客端发送的乘客身份信息更新请求，所述乘客身份信息更新请求包括第二待更新信息；
根据所述第二待更新信息更新所述乘客端对应的乘客身份信息卡。
在上述实施例的基础上，所述服务器，还包括：
第五发送模块，用于若所述乘客端未创建所述乘客身份信息卡，则向所述乘客端发送第二建卡指令。
在上述实施例的基础上，所述服务器，还包括：
乘客卡创建模块，用于接收所述乘客端发送的乘客身份信息，根据所述乘客身份信息创建所述乘客身份信息卡，其中，
所述乘客身份信息卡包括乘客头像、性别、手机号、乘车人数和第一已验真次数中任意一项或其组合。
在上述实施例的基础上，所述服务器，还包括：
第三更新模块，用于若所述第二校验结果为校验一致，则更新所述乘客身份信息卡中的第二已验真次数。
在上述实施例的基础上，所述服务器，还包括：
第二弹出模块，用于判断当前场景是否为第二高危场景，若是，则向所述司机端发送乘客身份信息卡弹出指令；其中，判断为所述第二高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述乘客身份信息卡的第二已验真次数低于第三预设次数；
所述乘客端发生身份信息与乘客身份信息卡不一致的次数大于第四预设次数。
在上述实施例的基础上，所述服务器，还包括：
第六接收模块，用于接收所述司机端发送的查看所述乘客身份信息卡的请求。
在上述实施例的基础上，所述服务器，还包括：
第一行程开始模块，用于若接收到所述乘客端返回的第一校验结果和所述司机端返回的第二校验结果均为校验一致，则开始行程。
在上述实施例的基础上，所述服务器，还包括：
第二行程开始模块，用于若所述第一校验结果为校验不一致，且接收到所述乘客端发送的开始行程请求，则向所述乘客端发送安全告警提示，并开始行程。
在上述实施例的基础上，所述服务器，还包括：
第一护航模块，用于接收所述乘客端发送的第一护航模式开启请求；
实时获取所述订单信息对应的车辆的行驶轨迹，将所述行驶轨迹发送至所述乘客端预先设置的第一紧急联系终端。
在上述实施例的基础上，所述服务器，还包括：
第一询问模块，用于根据所述行驶轨迹判断是否处于第三高危场景，若是，则向所述乘客端发送第一安全询问提示；
若在第二预设时间段内没有接收到所述乘客端返回的第一安全确认消息或接收到所述乘客端返回的第一紧急求助消息，则向所述第一紧急联系终端发送报警提示；其中，
判断为所述第三高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于第三预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
在上述实施例的基础上，所述服务器，还包括：
第二护航模块，用于接收所述司机端发送的第二护航模式开启请求；
实时获取所述订单信息对应的车辆的行驶轨迹，将所述行驶轨迹发送至所述司机端预先设置的第二紧急联系终端。
在上述实施例的基础上，所述服务器，还包括：
第二询问模块，用于根据所述行驶轨迹判断是否处于第四高危场景，若是，则向所述司机端发送第二安全询问提示；
若在第四预设时间段内没有接收到所述司机端返回的第二安全确认消息或接收到所述司机端返回的第二紧急求助消息，则向所述第二紧急联系终端发送报警提示；其中，
判断为所述第四高危场景所满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于第二预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置的具体工作过程，可以参考前述方法中的对应过程，在此不再过多赘述。
综上所述，本发明实施例通过将接单司机的司机身份信息卡发送至乘客端，使得乘客可以根据在乘客端接收到的司机身份信息卡与司机的实际信息进行校验，从而提高了乘客乘车的安全性。
图13为本发明实施例提供的一种乘客端结构示意图，如图13所示，该乘客端包括：第六发送模块1301和第七接收模块1302，其中：
第六发送模块1301用于向服务器发送订单信息；
第七接收模块1302用于接收所述服务器返回的接单司机的司机身份信息卡。
在上述实施例的基础上，所述乘客端，还包括：
显示模块，用于在显示界面上显示查看所述司机身份信息卡的入口；
接收针对所述入口的触发操作，显示司机身份信息卡。
在上述实施例的基础上，所述乘客端，还包括：
第一校验模块，用于向所述服务器发送第一校验结果，所述第一校验结果为接单司机与所述司机身份信息卡的一致性校验结果，所述第一校验结果包括校验一致和校验不一致。
在上述实施例的基础上，所述乘客端，还包括：
第一收发模块，用于接收服务器发送的乘客身份信息卡创建指令；
将乘客身份信息发送至所述服务器，所述乘客身份信息包括乘客头像、性别、手机号、乘车人数和第一已验真次数中任意一项或其组合。
在上述实施例的基础上，所述乘客端，还包括：
第二收发模块，用于接收所述服务器发送的第二申诉消息，所述第二申诉消息是根据接单的司机端发送的第二投诉类型生成的；
根据所述第二申诉消息向所述服务器发送第二申诉请求，所述第二申诉请求包括第二申诉证明信息。
在上述实施例的基础上，所述乘客端，还包括：
入口关闭模块，用于若行程结束，则关闭所述司机身份信息卡的入口。
在上述实施例的基础上，所述乘客端，还包括：
第一护航请求模块，用于向所述服务器发送第一护航模式开启请求，以使所述服务器实时将所述订单信息对应的车辆的位置信息发送至预先设置的第一紧急联系终端。
在上述实施例的基础上，所述乘客端，还包括：
第三询问模块，用于接收所述服务器发送的第一安全询问提示，所述第一安全询问提示为服务器判断处于第三高危场景时发送的；
根据所述第一安全询问提示向所述服务器发送第一应答消息；其中，
所述第三高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
在上述实施例的基础上，所述乘客端，还包括：
安全保障模块，用于接收针对第一安全模式下的安全保障功能的触发操作，根据所述安全保障功能进行相应的安全操作，其中，所述安全保障功能包括录音、录像和拨打紧急救助电话。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置的具体工作过程，可以参考前述方法中的对应过程，在此不再过多赘述。
综上所述，本发明实施例通过接收司机身份信息卡，将司机身份信息卡与接单司机的实际身份进行校验，从而来判断来接单的司机是否与注册司机的身份一致，以此来保障乘客乘车的安全。
图14为本发明实施例提供的一种司机端结构示意图，如图14所示，该司机端包括：接单请求发送模块1401和乘客信息接收模块1402，其中：
接单请求发送模块1401用于向服务器发送接单请求，所述接单请求包括所接乘客的订单信息；
乘客信息接收模块1402用于接收所述服务器返回的所述订单信息对应的乘客身份信息卡。
在上述实施例的基础上，所述司机端，还包括：
第二校验模块，用于向所述服务器发送第二校验结果，所述第二校验结果为发单乘客与所述乘客身份信息卡的一致性校验结果，所述第二校验结果包括校验一致和校验不一致并取消订单。
在上述实施例的基础上，所述司机端，还包括：
第二收发模块，用于接收服务器发送的司机身份信息卡创建指令；
将司机身份信息发送至所述服务器，所述司机身份信息包括司机头像、性别、手机号、注册车牌、注册车辆型号和第一已验真次数中任意一个或其组合。
在上述实施例的基础上，所述司机端，还包括：
申诉模块，用于接收所述服务器发送的第一申诉消息，所述第一申诉消息是根据发单的乘客端发送的第一投诉类型生成的；
根据所述第一申诉消息向所述服务器发送第一申诉请求，所述第一申诉请求包括第一申诉证明信息。
在上述实施例的基础上，所述司机端，还包括：
第二护航请求模块，用于向所述服务器发送第二护航模式开启请求，以使所述服务器实时将所述订单信息对应的车辆的位置信息发送至预先设置的第二紧急联系终端。
在上述实施例的基础上，所述司机端，还包括：
第四询问模块，用于接收所述服务器发送的第二安全询问提示，所述第二安全询问提示为服务器判断处于第四高危场景时发送的；
根据所述第二安全询问提示向所述服务器发送第二应答消息；其中，
所述第四高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
在上述实施例的基础上，所述司机端，还包括：
第二安全保障模块，用于接收针对第二安全模式下的安全保障功能的触发操作，根据所述安全保障功能进行相应的安全操作，其中，所述安全保障功能包括录音、摄像和拨打紧急救助电话。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置的具体工作过程，可以参考前述方法中的对应过程，在此不再过多赘述。
综上所述，本发明实施例通过将发单乘客的乘客身份信息卡发送至司机端，使得司机可以根据在司机端接收到的乘客身份信息卡与乘客的实际信息进行校验，从而提高了司机出行的安全性。
图15为本发明实施例提供的电子设备实体结构示意图，如图15所示，所述电子设备，包括：处理器(processor)1501、存储器(memory)1502和总线1503；其中，
所述处理器1501和存储器1502通过所述总线1503完成相互间的通信；
所述处理器1501用于调用所述存储器1502中的程序指令，以执行上述各方法实施例所提供的方法，例如包括：接收乘客端发送的订单信息，以及对应接单的司机端标识；将所述司机端标识对应的司机身份信息卡发送至所述乘客端。
本实施例公开一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法，例如包括：接收乘客端发送的订单信息，以及对应接单的司机端标识；将所述司机端标识对应的司机身份信息卡发送至所述乘客端。
本实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述各方法实施例所提供的方法，例如包括：接收乘客端发送的订单信息，以及对应接单的司机端标识；将所述司机端标识对应的司机身份信息卡发送至所述乘客端。
图16为本发明实施例提供的电子设备实体结构示意图，如图16所示，所述电子设备，包括：处理器(processor)1601、存储器(memory)1602和总线1603；其中，
所述处理器1601和存储器1602通过所述总线1603完成相互间的通信；
所述处理器1601用于调用所述存储器1602中的程序指令，以执行上述各方法实施例所提供的方法，例如包括：向服务器发送订单信息；接收所述服务器返回的接单司机的司机身份信息卡。
本实施例公开一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法，例如包括：向服务器发送订单信息；接收所述服务器返回的接单司机的司机身份信息卡。
本实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述各方法实施例所提供的方法，例如包括：向服务器发送订单信息；接收所述服务器返回的接单司机的司机身份信息卡。
图17为本发明实施例提供的电子设备实体结构示意图，如图17所示，所述电子设备，包括：处理器(processor)1701、存储器(memory)1702和总线1703；其中，
所述处理器1701和存储器1702通过所述总线1703完成相互间的通信；
所述处理器1701用于调用所述存储器1702中的程序指令，以执行上述各方法实施例所提供的方法，例如包括：向服务器发送接单请求，所述接单请求包括所接乘客的订单信息；接收所述服务器返回的所述订单信息对应的乘客身份信息卡。
本实施例公开一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法，例如包括：向服务器发送接单请求，所述接单请求包括所接乘客的订单信息；接收所述服务器返回的所述订单信息对应的乘客身份信息卡。
本实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述各方法实施例所提供的方法，例如包括：向服务器发送接单请求，所述接单请求包括所接乘客的订单信息；接收所述服务器返回的所述订单信息对应的乘客身份信息卡。
图18为本发明实施例提供的乘客端与服务器进行交互的示意图，所述服务器1802通过网络1803与一个或多个用户终端1801进行通信连接，以进行数据通信或交互。所述服务器1802可以是网络服务器、数据库服务器等。所述用户终端1801可以是个人电脑(personal computer，PC)、平板电脑、智能手机、个人数字助理(personal digitalassistant，PDA)、可穿戴设备等终端。
图19为本发明实施例提供的司机端与服务器进行交互的示意图，所述服务器1902通过网络1903与一个或多个用户终端1901进行通信连接，以进行数据通信或交互。所述服务器1902可以是网络服务器、数据库服务器等。所述用户终端1901可以是个人电脑(personal computer，PC)、平板电脑、智能手机、个人数字助理(personal digitalassistant，PDA)、可穿戴设备等终端。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本发明的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
另外，在本发明各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (53)

1.一种身份信息安全校验方法，其特征在于，包括：
接收乘客端发送的订单信息，以及对应接单的司机端标识；
将所述司机端标识对应的司机身份信息卡发送至所述乘客端；所述司机身份信息卡包括司机头像、性别、手机号、注册车牌、注册车辆型号和第一已验真次数；其中，所述第一已验真次数用于表征乘客端对所述司机身份信息卡进行校验，且校验一致的次数；
所述方法，还包括：
判断当前场景是否为第一高危场景，若是，则向所述乘客端发送司机身份信息卡弹出指令；其中，判断为所述第一高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述司机身份信息卡的第一已验真次数低于第一预设次数；
所述司机端发生身份信息与司机身份信息卡不一致的次数大于第二预设次数。
2.根据权利要求1所述的方法，其特征在于，所述方法，还包括：
接收所述乘客端返回的第一校验结果，所述第一校验结果为接单司机与所述司机身份信息卡的一致性校验结果。
3.根据权利要求2所述的方法，其特征在于，在接收所述乘客端返回的第一校验结果之后，所述方法，还包括：
若所述第一校验结果为校验不一致，则取消订单。
4.根据权利要求2所述的方法，其特征在于，在接收所述乘客端返回的第一校验结果之后，所述方法，还包括：
若所述第一校验结果为校验不一致，且接收到所述乘客端发送的取消订单请求，则取消订单且免收订单取消费。
5.根据权利要求2所述的方法，其特征在于，在接收所述乘客端返回的第一校验结果之后，所述方法，还包括：
若所述第一校验结果为校验不一致，且接收到所述乘客端发送的取消订单请求，则取消订单并向所述乘客端收取取消订单费；
审核所述第一校验结果是否属实；若属实，将所述取消订单费退回至所述乘客端。
6.根据权利要求5所述的方法，其特征在于，若审核确定所述第一校验结果不属实，则向所述司机端发放订单取消补偿费。
7.根据权利要求2所述的方法，其特征在于，在接收所述乘客端返回的第一校验结果之后，还包括：
若所述第一校验结果为校验不一致，则中止所述司机端接单；并
获取所述第一校验结果中包含的信息不一致的第一投诉类型；
根据所述第一投诉类型生成对应的第一申诉消息，将所述第一申诉消息发送至所述司机端，以使所述司机端进行申诉。
8.根据权利要求7所述的方法，其特征在于，在将所述申诉消息发送至所述司机端之后，所述方法，还包括：
若在第一预设时间段内所述司机端申诉未通过，则停用所述司机端。
9.根据权利要求1所述的方法，其特征在于，所述方法，还包括：
接收所述司机端发送的司机身份信息更新请求，所述司机身份信息更新请求包括第一待更新信息；
根据所述第一待更新信息更新所述司机端对应的司机身份信息卡。
10.根据权利要求3-6任一项所述的方法，其特征在于，所述方法，还包括：
向司机端发送订单取消消息，所述订单取消消息中的订单取消理由为司机身份信息校验不一致之外的理由。
11.根据权利要求2所述的方法，其特征在于，在将所述司机端标识对应的司机身份信息卡发送至所述乘客端之前，所述方法，还包括：
若所述司机端未创建所述司机身份信息卡，则向所述司机端发送第一建卡指令。
12.根据权利要求11所述的方法，其特征在于，所述方法，还包括：
接收所述司机端发送的司机身份信息，根据所述司机身份信息创建所述司机身份信息卡。
13.根据权利要求2所述的方法，其特征在于，所述方法，还包括：
若所述第一校验结果为校验一致，则更新所述司机身份信息卡中的第一已验真次数。
14.根据权利要求1所述的方法，其特征在于，在将所述司机端标识对应的司机身份信息卡发送至所述乘客端之前，还包括：
接收所述乘客端发送的查看所述司机身份信息卡的请求。
15.根据权利要求1所述的方法，其特征在于，所述方法，还包括：
向所述司机端标识对应的司机端发送所述乘客端对应的乘客身份信息卡。
16.根据权利要求15所述的方法，其特征在于，所述方法，还包括：
接收所述司机端返回的第二校验结果，所述第二校验结果为发单乘客与所述乘客身份信息卡的一致性校验结果。
17.根据权利要求15所述的方法，其特征在于，在接收所述司机端返回的第二校验结果之后，所述方法，还包括：
若所述第二校验结果为校验不一致，且接收到所述司机端发送的取消订单请求，则取消订单。
18.根据权利要求16所述的方法，其特征在于，在接收所述司机端返回的第二校验结果之后，所述方法，还包括：
若所述第二校验结果为校验不一致，则中止所述乘客端发单；并
获取所述第二校验结果中包含的信息不一致的第二投诉类型；
根据所述第二投诉类型生成对应的第二申诉消息，将所述第二申诉消息发送至所述乘客端，以使所述乘客端进行申诉。
19.根据权利要求15所述的方法，其特征在于，所述方法，还包括：
接收所述乘客端发送的乘客身份信息更新请求，所述乘客身份信息更新请求包括第二待更新信息；
根据所述第二待更新信息更新所述乘客端对应的乘客身份信息卡。
20.根据权利要求15所述的方法，其特征在于，所述方法，还包括：
若所述乘客端未创建所述乘客身份信息卡，则向所述乘客端发送第二建卡指令。
21.根据权利要求20所述的方法，其特征在于，所述方法，还包括：
接收所述乘客端发送的乘客身份信息，根据所述乘客身份信息创建所述乘客身份信息卡，其中，
所述乘客身份信息卡包括乘客头像、性别、手机号、乘车人数和第二已验真次数中任意一项或其组合。
22.根据权利要求16所述的方法，其特征在于，所述方法，还包括：
若所述第二校验结果为校验一致，则更新所述乘客身份信息卡中的第二已验真次数。
23.根据权利要求15所述的方法，其特征在于，所述方法，还包括：
判断当前场景是否为第二高危场景，若是，则向所述司机端发送乘客身份信息卡弹出指令；其中，判断为所述第二高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述乘客身份信息卡的第二已验真次数低于第三预设次数；
所述乘客端发生身份信息与乘客身份信息卡不一致的次数大于第四预设次数。
24.根据权利要求15所述的方法，其特征在于，在向所述司机端标识对应的司机端发送所述乘客端对应的乘客身份信息卡之前，所述方法，还包括：
接收所述司机端发送的查看所述乘客身份信息卡的请求。
25.根据权利要求15所述的方法，其特征在于，所述方法，还包括：
若接收到所述乘客端返回的第一校验结果和所述司机端返回的第二校验结果均为校验一致，则开始行程。
26.根据权利要求2所述的方法，其特征在于，所述方法，还包括：
若所述第一校验结果为校验不一致，且接收到所述乘客端发送的开始行程请求，则向所述乘客端发送安全告警提示，并开始行程。
27.根据权利要求1所述的方法，其特征在于，所述方法，还包括：
接收所述乘客端发送的第一护航模式开启请求；
实时获取所述订单信息对应的车辆的行驶轨迹，将所述行驶轨迹发送至所述乘客端预先设置的第一紧急联系终端。
28.根据权利要求27所述的方法，其特征在于，在接收所述乘客端发送的第一护航模式开启请求之后，所述方法，还包括：
根据所述行驶轨迹判断是否处于第三高危场景，若是，则向所述乘客端发送第一安全询问提示；
若在第二预设时间段内没有接收到所述乘客端返回的第一安全确认消息或接收到所述乘客端返回的第一紧急求助消息，则向所述第一紧急联系终端发送报警提示；其中，
判断为所述第三高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于第三预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
29.根据权利要求1所述的方法，其特征在于，所述方法，还包括：
接收所述司机端发送的第二护航模式开启请求；
实时获取所述订单信息对应的车辆的行驶轨迹，将所述行驶轨迹发送至所述司机端预先设置的第二紧急联系终端。
30.根据权利要求29所述的方法，其特征在于，在接收所述司机端发送的第二护航模式开启请求之后，所述方法，还包括：
根据所述行驶轨迹判断是否处于第四高危场景，若是，则向所述司机端发送第二安全询问提示；
若在第四预设时间段内没有接收到所述司机端返回的第二安全确认消息或接收到所述司机端返回的第二紧急求助消息，则向所述第二紧急联系终端发送报警提示；其中，
判断为所述第四高危场景所满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于第二预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
31.一种身份信息安全校验方法，其特征在于，包括：
向服务器发送订单信息；
接收所述服务器返回的接单司机的司机身份信息卡；所述司机身份信息卡包括司机头像、性别、手机号、注册车牌、注册车辆型号和第一已验真次数；其中，所述第一已验真次数用于表征乘客端对所述司机身份信息卡进行校验，且校验一致的次数；
所述方法还包括：
接收所述服务器在判断当前场景处于第一高危场景的情况下发送的司机身份信息卡弹出指令；其中，所述第一高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述司机身份信息卡的第一已验真次数低于第一预设次数；
司机端发生身份信息与司机身份信息卡不一致的次数大于第二预设次数。
32.根据权利要求31所述的方法，其特征在于，在接收所述服务器返回的接单司机的司机身份信息卡之后，所述方法，还包括：
在显示界面上显示查看所述司机身份信息卡的入口；
接收针对所述入口的触发操作，显示司机身份信息卡。
33.根据权利要求31所述的方法，其特征在于，所述方法，还包括：
向所述服务器发送第一校验结果，所述第一校验结果为接单司机与所述司机身份信息卡的一致性校验结果，所述第一校验结果包括校验一致和校验不一致。
34.根据权利要求31所述的方法，其特征在于，所述方法，还包括：
接收服务器发送的乘客身份信息卡创建指令；
将乘客身份信息发送至所述服务器，所述乘客身份信息包括乘客头像、性别、手机号、乘车人数和第二已验真次数中任意一项或其组合。
35.根据权利要求31所述的方法，其特征在于，所述方法，还包括：
接收所述服务器发送的第二申诉消息，所述第二申诉消息是根据接单的司机端发送的第二投诉类型生成的；
根据所述第二申诉消息向所述服务器发送第二申诉请求，所述第二申诉请求包括第二申诉证明信息。
36.根据权利要求32所述的方法，其特征在于，所述方法，还包括：
若行程结束，则关闭所述司机身份信息卡的入口。
37.根据权利要求31所述的方法，其特征在于，所述方法，还包括：
向所述服务器发送第一护航模式开启请求，以使所述服务器实时将所述订单信息对应的车辆的位置信息发送至预先设置的第一紧急联系终端。
38.根据权利要求37所述的方法，其特征在于，所述方法，还包括：
接收所述服务器发送的第一安全询问提示，所述第一安全询问提示为服务器判断处于第三高危场景时发送的；
根据所述第一安全询问提示向所述服务器发送第一应答消息；其中，
所述第三高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
39.根据权利要求31所述的方法，其特征在于，所述方法，还包括：
接收针对第一安全模式下的安全保障功能的触发操作，根据所述安全保障功能进行相应的安全操作，其中，所述安全保障功能包括录音、录像和拨打紧急救助电话。
40.一种身份信息安全校验方法，其特征在于，包括：
向服务器发送接单请求，所述接单请求包括所接乘客的订单信息；
接收所述服务器返回的所述订单信息对应的乘客身份信息卡；所述乘客身份信息卡包括乘客头像、性别、手机号、乘车人数和第二已验真次数；所述第二已验真次数用于表征司机端对所述乘客身份信息卡进行校验，且校验一致的次数；
所述方法还包括：
向所述服务器发送第二护航模式开启请求，以使所述服务器实时将所述订单信息对应的车辆的位置信息发送至预先设置的第二紧急联系终端；
接收所述服务器发送的第二安全询问提示，所述第二安全询问提示为服务器判断处于第四高危场景时发送的；
根据所述第二安全询问提示向所述服务器发送第二应答消息；其中，
所述第四高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
41.根据权利要求40所述的方法，其特征在于，在接收所述服务器返回的所述订单信息对应的乘客身份信息卡之后，所述方法，还包括：
向所述服务器发送第二校验结果，所述第二校验结果为发单乘客与所述乘客身份信息卡的一致性校验结果，所述第二校验结果包括校验一致和校验不一致并取消订单。
42.根据权利要求40所述的方法，其特征在于，所述方法，还包括：
接收服务器发送的司机身份信息卡创建指令；
将司机身份信息发送至所述服务器，所述司机身份信息包括司机头像、性别、手机号、注册车牌、注册车辆型号和第一已验真次数中任意一个或其组合。
43.根据权利要求40所述的方法，其特征在于，所述方法，还包括：
接收所述服务器发送的第一申诉消息，所述第一申诉消息是根据发单的乘客端发送的第一投诉类型生成的；
根据所述第一申诉消息向所述服务器发送第一申诉请求，所述第一申诉请求包括第一申诉证明信息。
44.根据权利要求40所述的方法，其特征在于，所述方法，还包括：
接收针对第二安全模式下的安全保障功能的触发操作，根据所述安全保障功能进行相应的安全操作，其中，所述安全保障功能包括录音、摄像和拨打紧急救助电话。
45.一种服务器，其特征在于，包括：
第一接收模块，用于接收乘客端发送的订单信息，以及对应接单的司机端标识；
第一发送模块，用于将所述司机端标识对应的司机身份信息卡发送至所述乘客端；所述司机身份信息卡包括司机头像、性别、手机号、注册车牌、注册车辆型号和第一已验真次数中任意一个或其组合；其中，所述第一已验真次数用于表征乘客端对所述司机身份信息卡进行校验，且校验一致的次数；
所述服务器还包括第一弹出模块，用于：
判断当前场景是否为第一高危场景，若是，则向所述乘客端发送司机身份信息卡弹出指令；其中，判断为所述第一高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述司机身份信息卡的第一已验真次数低于第一预设次数；
所述司机端发生身份信息与司机身份信息卡不一致的次数大于第二预设次数。
46.一种乘客端，其特征在于，包括：
第六发送模块，用于向服务器发送订单信息；
第七接收模块，用于接收所述服务器返回的接单司机的司机身份信息卡；所述司机身份信息卡包括司机头像、性别、手机号、注册车牌、注册车辆型号和第一已验真次数中任意一个或其组合；其中，所述第一已验真次数用于表征乘客端对所述司机身份信息卡进行校验，且校验一致的次数；
所述乘客端还包括指令接收模块，用于：
接收所述服务器在判断当前场景处于第一高危场景的情况下发送的司机身份信息卡弹出指令；其中，所述第一高危场景的条件包括以下任意一项：
当前时刻处于预设高危时间段内；
所述司机身份信息卡的第一已验真次数低于第一预设次数；
司机端发生身份信息与司机身份信息卡不一致的次数大于第二预设次数。
47.一种司机端，其特征在于，包括：
接单请求发送模块，用于向服务器发送接单请求，所述接单请求包括所接乘客的订单信息；
乘客信息接收模块，用于接收所述服务器返回的所述订单信息对应的乘客身份信息卡；所述乘客身份信息卡包括乘客头像、性别、手机号、乘车人数和第二已验真次数；所述第二已验真次数用于表征司机端对所述乘客身份信息卡进行校验，且校验一致的次数；
所述司机端还包括：
第二护航请求模块，用于向所述服务器发送第二护航模式开启请求，以使所述服务器实时将所述订单信息对应的车辆的位置信息发送至预先设置的第二紧急联系终端；
第四询问模块，用于接收所述服务器发送的第二安全询问提示，所述第二安全询问提示为服务器判断处于第四高危场景时发送的；
根据所述第二安全询问提示向所述服务器发送第二应答消息；其中，
所述第四高危场景满足的条件包括以下任意一种：
行驶轨迹偏离预设路线；
车辆行驶距离超过预设距离；
车辆停留时长大于预设时间段；
所述订单信息对应的乘车时间在预设高危时间段内；
行驶时长大于预估到达时长和预留时长之和。
48.一种电子设备，其特征在于，包括：处理器、存储器和总线，其中，
所述处理器和所述存储器通过所述总线完成相互间的通信；
所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行如权利要求1-30任一项所述的方法。
49.一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行如权利要求1-30任一项所述的方法。
50.一种电子设备，其特征在于，包括：处理器、存储器和总线，其中，
所述处理器和所述存储器通过所述总线完成相互间的通信；
所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行如权利要求31-39任一项所述的方法。
51.一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行如权利要求31-39任一项所述的方法。
52.一种电子设备，其特征在于，包括：处理器、存储器和总线，其中，
所述处理器和所述存储器通过所述总线完成相互间的通信；
所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行如权利要求40-44任一项所述的方法。
53.一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行如权利要求40-44任一项所述的方法。
CN201810953064.1A 2018-08-20 2018-08-20 身份信息安全校验方法、服务器、乘客端及司机端 Active CN110751530B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810953064.1A CN110751530B (zh) 2018-08-20 2018-08-20 身份信息安全校验方法、服务器、乘客端及司机端

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810953064.1A CN110751530B (zh) 2018-08-20 2018-08-20 身份信息安全校验方法、服务器、乘客端及司机端

Publications (2)

Publication Number Publication Date
CN110751530A CN110751530A (zh) 2020-02-04
CN110751530B true CN110751530B (zh) 2020-12-22

Family

ID=69275656

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810953064.1A Active CN110751530B (zh) 2018-08-20 2018-08-20 身份信息安全校验方法、服务器、乘客端及司机端

Country Status (1)

Country Link
CN (1) CN110751530B (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111967725A (zh) * 2020-07-23 2020-11-20 汉海信息技术(上海)有限公司 输出提示信息的方法、终端、服务器、设备及存储介质
CN112101955B (zh) * 2020-11-16 2021-02-02 北京快成科技股份公司 并发支付方法、系统及装置
CN112819670A (zh) * 2021-01-08 2021-05-18 北京嘀嘀无限科技发展有限公司 信息处理方法、装置、可读存储介质和电子设备
CN113327150A (zh) * 2021-05-27 2021-08-31 广州宸祺出行科技有限公司 一种防违规的顺风车行程验证方法及系统
CN113240206B (zh) * 2021-06-21 2024-03-26 拼途(北京)信息技术有限公司 扫码打车方法、扫码打车装置、电子设备和可读存储介质
WO2023080840A2 (en) * 2021-11-03 2023-05-11 Grabtaxi Holdings Pte. Ltd. System and method to monitor trip and detect unsafe events
WO2023101601A1 (en) * 2021-12-01 2023-06-08 Grabtaxi Holdings Pte. Ltd. Method and device for authenticating a driver of a vehicle

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102270386A (zh) * 2010-06-07 2011-12-07 华东师范大学 基于双向定位的出租车叫车系统
CN102780813A (zh) * 2012-06-27 2012-11-14 宇龙计算机通信科技(深圳)有限公司 基于移动终端的报警方法和系统
CN103544820A (zh) * 2012-07-11 2014-01-29 张凯杰 出租车的安全监控系统及其方法
CN104021656A (zh) * 2014-05-16 2014-09-03 王勇 通过监控设备及网络实施公共安全监控的出租车安全监控系统及方法
CN106056839A (zh) * 2016-06-30 2016-10-26 武汉斑马快跑科技有限公司 网约车安全监测系统及方法
CN106209876A (zh) * 2016-07-18 2016-12-07 廖嘉泓 网约车安全服务认证方法及车辆身份识别系统
CN106600083A (zh) * 2015-10-14 2017-04-26 腾讯科技（深圳）有限公司 一种司机接单的管理方法和设备
CN107767196A (zh) * 2016-08-16 2018-03-06 北京嘀嘀无限科技发展有限公司 一种司机身份验证方法及服务器

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103179290B (zh) * 2012-03-10 2016-12-14 重庆智韬信息技术中心 出租车的智能招租和监控管理系统
US9157748B2 (en) * 2012-07-31 2015-10-13 Flatiron Apps LLC System and method for hailing taxicabs
EP3182684A4 (en) * 2014-07-18 2018-05-23 Shanghai Chule (Cootek) Information Technology Co., Ltd. Intelligent service interaction platform apparatus, system and realizing method thereof
CN107016849A (zh) * 2017-04-26 2017-08-04 北京聚利科技股份有限公司 网络预约车辆的方法、装置及系统
CN108162975A (zh) * 2017-12-11 2018-06-15 厦门蓝斯通信股份有限公司 一种驾驶员身份识别与监管方法及系统

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102270386A (zh) * 2010-06-07 2011-12-07 华东师范大学 基于双向定位的出租车叫车系统
CN102780813A (zh) * 2012-06-27 2012-11-14 宇龙计算机通信科技(深圳)有限公司 基于移动终端的报警方法和系统
CN103544820A (zh) * 2012-07-11 2014-01-29 张凯杰 出租车的安全监控系统及其方法
CN104021656A (zh) * 2014-05-16 2014-09-03 王勇 通过监控设备及网络实施公共安全监控的出租车安全监控系统及方法
CN106600083A (zh) * 2015-10-14 2017-04-26 腾讯科技（深圳）有限公司 一种司机接单的管理方法和设备
CN106056839A (zh) * 2016-06-30 2016-10-26 武汉斑马快跑科技有限公司 网约车安全监测系统及方法
CN106209876A (zh) * 2016-07-18 2016-12-07 廖嘉泓 网约车安全服务认证方法及车辆身份识别系统
CN107767196A (zh) * 2016-08-16 2018-03-06 北京嘀嘀无限科技发展有限公司 一种司机身份验证方法及服务器

Also Published As

Publication number Publication date
CN110751530A (zh) 2020-02-04

Similar Documents

Publication Publication Date Title
CN110751530B (zh) 身份信息安全校验方法、服务器、乘客端及司机端
CN109712387B (zh) 网约车、出租车的乘客和司机的安全保护系统
US20220180450A1 (en) Evidence oracles
US11734770B2 (en) Using a distributed ledger to determine fault in subrogation
US20210342946A1 (en) Using a Distributed Ledger for Line Item Determination
CN108431839A (zh) 用来标识交通工具的系统
US11657460B2 (en) Using historical data for subrogation on a distributed ledger
US11658830B2 (en) Systems and method for ridesharing using blockchain
CN107111937A (zh) 用于交通流量优化的受管理使用权系统
CN108876522A (zh) 车辆监控方法、装置和计算机可读存储介质
US11507079B2 (en) Active safety control system
WO2008001125A1 (en) Drive performance monitoring and enhancement
EP3886072A1 (en) Transport event severity analysis
JP2022059574A (ja) 輸送機の安全なデータ共有
EP3886006A1 (en) Consensus-based transport event severity
CN107004352B (zh) 交通违章管理系统和交通违章管理方法
KR20210126189A (ko) 이륜차 운전의 ict 기반 운전자 특정 평가 분석 및 보상 플랫폼을 제공하기 위한 장치 및 방법
JP7379424B2 (ja) 状況固有の輸送手段パワー割り当て
CN113240920A (zh) 车辆通行方法及装置、认证服务器和紧急救援系统
JP2023179716A (ja) システム、及びプログラム等
CN117236974B (zh) 订单车辆的欺诈识别方法、装置、存储介质及计算机设备
JP6670973B1 (ja) 安全運転ポイント報奨システム
JP7451821B2 (ja) 動的に適応させる運転モードセキュリティ制御
US20230046203A1 (en) Protecting living objects in transports
US20220138810A1 (en) Transport use determination

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
GR01 Patent grant