CN109767230A - 一种支付方法、装置及交通支付设备 - Google Patents

Abstract

本发明实施例公开了一种支付方法、装置及交通支付设备，属于信息处理技术领域，用于对掌脉支付进行验证。该方法中，获取乘客的掌脉信息；所述乘客的掌脉信息是所述乘客乘坐的车辆中的掌脉仪采集的；获取所述车辆的掌脉信息集合；所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的；若从所述车辆的掌脉信息集合中确定出与所述乘客的掌脉信息匹配的掌脉信息，则确定所述乘客乘车验证成功。

Description

一种支付方法、装置及交通支付设备

技术领域

本发明涉及信息处理技术领域，尤其涉及一种支付方法、装置及交通支付设备。

背景技术

为了减少携带实体交通卡(例如公交卡或地铁卡)的不便，目前推出了使用各种不需要实体交通卡支付搭乘公共交通的交通方式，例如在乘坐地铁时，用户可以向地铁闸机展示手机中的支付码，地铁闸机在扫描支付码之后可以允许用户通过或禁止通过，通过这种新兴的互联网交通产品，可以实现快速、便捷的交通体验。

随着掌脉支付的广泛发展，在保证掌脉支付的安全性的前提下，提高掌脉支付的适用性的问题也越来越值得关注。

发明内容

本发明实施例提供一种支付方法、装置及交通支付设备，以提高掌脉支付的验证效率。

一方面，提供一种支付方法，所述方法包括：

获取乘客的掌脉信息；所述乘客的掌脉信息是所述乘客乘坐的车辆中的掌脉仪采集的；

获取所述车辆的掌脉信息集合；所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的；

若从所述车辆的掌脉信息集合中确定出与所述乘客的掌脉信息匹配的掌脉信息，则确定所述乘客乘车验证成功。

一种可能的实现方式，所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的，包括：

接收所述客户端在检测到用户操作符合设定条件时，发送的所述用户的登录信息；

根据所述登录信息获取所述用户的掌脉信息。

一种可能的实现方式，所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的，包括：

接收所述客户端发送的定位信息；

在确定所述定位信息与车站信息匹配时，获取所述客户端对应的用户的信息；

根据所述用户的信息获取所述活跃用户的掌脉信息。

一种可能的实现方式，所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的，包括：

在获取所述客户端上报的路线查询信息后，预测所述用户可能乘坐的公交车并获取所述用户的信息；

根据所述用户的信息获取所述用户的掌脉信息；

将所述用户的掌脉信息确定为所述公交车的掌脉信息集合中的一个。

一种可能的实现方式，所述车辆的掌脉信息集合是根据客户端上报的活跃用户的登录信息确定的，包括：

在获取所述客户端上报的预约车辆信息后，获取所述客户端的登录信息；所述预约车辆信息包括预约公交车的车次、预约时间、预约车站中的至少一项或多项；

根据所述登录信息获取所述活跃用户的掌脉信息；

根据所述预约车辆信息，确定所述活跃用户乘坐的公交车；

将所述活跃用户的掌脉信息确定为所述公交车的掌脉信息集合中的一个。

一种可能的实现方式，所述获取乘客的掌脉信息，包括：

云端服务器接收车辆服务器发送的乘客的掌脉信息；

所述方法还包括：

所述云端服务器若从所述车辆的掌脉信息集合中未确定出与所述乘客的掌脉信息匹配的掌脉信息，则从所述云端服务器的全库掌脉信息中查询匹配的掌脉信息。

一种可能的实现方式，所述获取所述车辆的掌脉信息集合，包括：

车辆服务器接收云端服务器发送的所述车辆的掌脉信息集合；

所述方法还包括：

所述车辆服务器若从所述车辆的掌脉信息集合中未确定出与所述乘客的掌脉信息匹配的掌脉信息，则向所述云端服务器发送所述乘客的掌脉信息，以使所述云端服务器从全库掌脉信息中查询匹配的掌脉信息。

一方面，本发明实施例提供一种支付装置，所述装置包括：

获取模块，用于获取乘客的掌脉信息；所述乘客的掌脉信息是所述乘客乘坐的车辆中的掌脉仪采集的；获取所述车辆的掌脉信息集合；所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的；

处理模块，用于若从所述车辆的掌脉信息集合中确定出与所述乘客的掌脉信息匹配的掌脉信息，则确定所述乘客乘车验证成功。

一种可能的实现方式，所述获取模块，具体用于：

接收所述客户端在检测到用户操作符合设定条件时，发送的所述用户的登录信息；根据所述登录信息获取所述用户的掌脉信息。

一种可能的实现方式，所述获取模块，具体用于：

接收所述客户端发送的定位信息；在确定所述定位信息与车站信息匹配时，获取所述客户端对应的用户的信息；根据所述用户的信息获取所述活跃用户的掌脉信息。

一种可能的实现方式，所述获取模块，具体用于：

在获取所述客户端上报的路线查询信息后，预测所述用户可能乘坐的公交车并获取所述用户的信息；根据所述用户的信息获取所述用户的掌脉信息；将所述用户的掌脉信息确定为所述公交车的掌脉信息集合中的一个。

一种可能的实现方式，所述获取模块，具体用于：

在获取所述客户端上报的预约车辆信息后，获取所述客户端的登录信息；所述预约车辆信息包括预约公交车的车次、预约时间、预约车站中的至少一项或多项；根据所述登录信息获取所述活跃用户的掌脉信息；根据所述预约车辆信息，确定所述活跃用户乘坐的公交车；将所述活跃用户的掌脉信息确定为所述公交车的掌脉信息集合中的一个。

一种可能的实现方式，所述获取模块，还用于：接收车辆服务器发送的乘客的掌脉信息；

所述处理模块，还用于：若从所述车辆的掌脉信息集合中未确定出与所述乘客的掌脉信息匹配的掌脉信息，则从所述云端服务器的全库掌脉信息中查询匹配的掌脉信息。

一种可能的实现方式，所述获取模块，还用于：接收云端服务器发送的所述车辆的掌脉信息集合；

所述处理模块，还用于：若从所述车辆的掌脉信息集合中未确定出与所述乘客的掌脉信息匹配的掌脉信息，则向所述云端服务器发送所述乘客的掌脉信息，以使所述云端服务器从全库掌脉信息中查询匹配的掌脉信息。

一方面，本发明实施例提供一种交通支付设备，所述交通支付设备包括：

采集器，用于扫描乘客的掌脉信息；

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序指令执行各个方面所述的方法包括的步骤。

一方面，提供一种终端设备，所述终端设备包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序指令执行上述各个方面所述的方法包括的步骤。

一方面，提供一种存储介质，所述存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行上述各个方面所述的方法包括的步骤。

本发明实施例中，在掌脉支付之前，根据客户端上报的活跃用户的信息确定的车辆的掌脉信息集合，通过从所述车辆的掌脉信息集合中确定出与所述乘客的掌脉信息匹配的掌脉信息，可以缩小乘车验证的范围，进而提高对掌脉支付是否合法使用的有效验证，提高验证效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

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

图1a为本发明实施例中的一种应用场景的示意图；

图1b为本发明实施例中的另一种应用场景的示意图；

图2为本发明实施例中的另一种应用场景的示意图；

图3为本发明实施例中的支付方法的流程图；

图4为本发明实施例中的支付装置的结构框图；

图5为本发明实施例中的交通支付设备的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本发明的说明书和权利要求书及上述附图中的术语“第一”和“第二”是用于区别不同对象，而非用于描述特定顺序。此外，术语“包括”以及它们任何变形，意图在于覆盖不排他的保护。例如包含了一系列步骤或单元的过程、方法、***、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

本发明实施例中，“多个”可以表示至少两个，例如可以是两个、三个或者更多个，本申请实施例不做限制。

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，在不做特别说明的情况下，一般表示前后关联对象是一种“或”的关系。

以下对本文中涉及的部分用语进行说明，以便于本领域技术人员理解。

1、掌脉信息，用户用来乘坐公交或地铁等交通工具进行支付的特征数据，即掌脉支付的手掌静脉的特征图像，例如手机中扫描并获取的用户的手掌静脉的特征图像，以及交通支付设备通过摄像头扫描用户手掌静脉而获得的特征图像。在掌脉信息中可包含用户的身份标识等信息。另外，掌脉信息中还可以为通过加密的方式进行传输与验证。

2、客户端，用户的掌脉信息可以通过终端设备的客户端进行注册使用的，而客户端可以理解为是一个应用客户端，由于每个应用客户端可以对应一个应用服务器，所以不同的客户端可以分别对应不同的应用服务器。在实际中，客户端可以是一个独立的应用程序(Application，APP)，例如某地铁公司或某公交公司发布的专用于乘坐该地铁公司或该公交公司下辖的交通工具而使用的客户端，或者，客户端也可以是一个嵌入在现有的APP中的功能模块。以微信客户端为例，其中的掌脉支付功能可以以小程序的方式嵌入在微信客户端中，通过内嵌小程序的方式可以节约流量，并且可以快速运行，当用户需要使用掌脉支付之前，可以通过下拉微信主界面或者通过查找的方式找到掌脉支付小程序，进而进入到掌脉支付小程序的运行界面，然后在掌脉支付的界面中进行注册，并获取用户的掌脉信息；用户可以通过客户端查询交通信息、预约车辆等。

3、掌脉仪，为扫描掌脉信息的交通支付设备，是指可以扫描掌脉信息以获得掌脉支付特征图像的设备，掌脉仪可以通过摄像头以扫描的方式得到用户掌脉的特征图像。

根据掌脉支付的使用场景的不同，交通支付设备也可以区分为进站扫描设备和出站扫描设备，以地铁为例，在进站时扫描进站的掌脉信息的交通支付设备可以理解为是进站扫描设备，以及在出站时扫描出站的掌脉信息的交通支付设备可以理解为是出站扫描设备。还有另外一种交通场景，比如公交车，由于没有明显的进站出站的区分，所以公交车上的交通支付设备可以只有一个，当然也可以有多个，用于多站不同计费的场景。根据交通场景的不同，交通支付设备可以对应于不同的设备，例如在地铁、快速公交***(BusRapidTransit，BRT)、轻轨等交通场景中，交通支付设备可以是闸机(包括进站闸机和出站闸机)，又例如在公交车等交通场景中，交通支付设备可以是设置于公交车上的扫描工具。

另外，为了使得能够适用于多种方式的乘车，在某些情形下例如也可以与现有的扫码设备、扫码枪、验票机具、支付设备结合，实现多功能的支付。在交通支付设备中还可以集成近场通信(Near Field Communication，NFC)功能，通过NFC功能来感应识别常规的实体公交卡或临时地铁票，以及还可以设置有车票投递口以便于回收临时车票，以交通支付设备是地铁里的闸机为例，一种可能的交通支付设备(即地铁闸机)，以及用户使用该交通支付设备的摄像头扫描手掌。

为了更好地理解本发明实施例提供的技术方案，下面先介绍本发明实施例的技术背景。

在介绍完本发明实施例的设计思想之后，下面对本发明实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本发明实施例而非限定。在具体实施时，可以根据实际需要灵活地应用本发明实施例提供的技术方案。

请参见图1a所示的一种应用场景示意图，图1a所示的应用场景是以通过掌脉支付乘坐公交车的场景为例进行说明，在该应用场景中包括终端设备101、公交车支付设备102、终端服务器103、车辆服务器104和云端服务器105。其中，终端设备101是能够运行掌脉支付的客户端的设备，如前面介绍的，由于终端设备101中运行有掌脉支付的客户端，进而确定用户是否为掌脉支付的活跃用户等信息，所以与该掌脉支付的客户端可以对应设置有一个应用服务器，即终端服务器103。公交车中包括公交车支付设备102，公交车支付设备对应一个车辆服务器104，位于公交车本地。终端服务器103和云端车服务器105可以为同一个服务器，在此不做限定。公交车支付设备102可以是掌脉仪，公交车支付设备102还可以包括告警装置，当确定某次掌脉支付使用不合法时，则可以通过告警的方式进而通知用户重新支付，当确定掌脉支付使用是合法的，则可以通知用户支付成功，以便用户能够快速实现上车。

参见图1b所示的另一应用场景示意图，相对于图1a来说，图1b中增加了支付平台106，在公交车支付设备102完成扫码之后，可以将扫描记录上传给云端服务器105，云端服务器105可以根据接收到的扫描记录为用户生成交通账单，并且可以将生成的交通账单发送给支付平台106以请求支付平台对交通账单付费，也就是说，云端服务器105可以根据生成的交通账单向支付平台106请款，以实现交通运营方和向支付方的请款支付。在具体实施过程中，支付平台106可以是与交通运营方(例如地铁公司)合作的支付机构，支付平台106例如是掌脉支付服务方自身开设的支付机构，或者，支付平台106也可以是与交通运营方具有合作关系的支付机构，例如可以是支付宝支付平台，或者可以是银联支付平台，或者还可以是其它的第三方支付平台，等等。

另一应用场景中，如图2所示，为通过掌脉支付乘坐地铁的场景为例进行说明，在该应用场景中包括终端设备201、地铁闸机202、终端服务器203、车辆服务器204、云端服务器205和支付平台206。其中，终端设备201和终端服务器203与前述的终端设备101和终端服务器103可以按照相同的理解方式理解，地铁闸机202可以按照前述的公交车支付设备102理解，支付平台206可以按照前述的支付平台106理解，例如，地铁闸机202能够扫描终端设备201中展示的掌脉支付以得到掌脉支付的特征图像，进而根据掌脉支付的特征图像判断当前使用的掌脉支付是否是合法使用，地铁闸机202还可以包括例如闸机扇门、闸机摆式门等通行阻挡装置，当确定某次乘车支付使用不合法时，则可以禁止该通行阻挡装置打开进而阻挡用户通过地铁闸机202，当确定乘车支付使用是合法的，则可以打开通行阻挡装置，以便用户能够通过通行阻挡装置而实现进站或出站。以及，地铁闸机202还可以根据掌脉支付图像生成扫描记录，并将扫描记录上传给云端服务器205，使得云端服务器205可以根据接收到的扫描记录为用户生成交通账单，云端服务器205可以根据生成的交通账单向支付平台206请款。

前述的终端设备101和终端设备201均可以是手机、平板电脑、掌上电脑(PersonalDigital Assistant，PDA)，笔记本电脑、智能穿戴式设备(例如智能手表和智能头盔)、个人计算机，等等，无论是哪种设备，在该设备中均可以运行掌脉支付的客户端，进而确定用户是否为掌脉支付活跃用户的信息等等。以及，前述的服务器103、服务器203、地铁服务器104、公交服务器204、支付平台106和支付平台205均可以是个人计算机、大中型计算机、计算机集群，等等。

为进一步说明本发明实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本发明实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本发明实施例提供的执行顺序。所述方法在实际的处理过程中或者装置执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的应用环境)。

请参见图3所示的支付方法的交互图，以下结合图3对本发明实施例中的技术方案进行说明。所述方法包括：

步骤301：获取乘客的掌脉信息；

其中，所述乘客的掌脉信息是所述乘客乘坐的车辆中的掌脉仪采集的；

在具体实施过程中，乘客的掌脉信息可以为云端服务器接收车辆服务器发送的乘客的掌脉信息；也可以为车辆服务器获取的。所述云端服务器可以为前述的云端服务器，也可以为车辆服务器，在此不做限定。

步骤302：获取所述车辆的掌脉信息集合；

其中，所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的；

在具体实施过程中，所述车辆的掌脉信息集合还可以为车辆服务器接收云端服务器发送的所述车辆的掌脉信息集合；也可以为云端服务器获取的所述车辆的掌脉信息集合。

以下以云端服务器获取车辆的掌脉信息集合为例进行描述，一种可能的实现方式，车辆的掌脉信息集合可以根据以下方式确定：

云端服务器接收所述客户端在检测到用户操作符合设定条件时，发送的所述用户的登录信息；根据所述登录信息获取所述用户的掌脉信息。

其中，设定条件可以通过以下方式确定：

所述客户端若确定用户操作所述客户端的操作时长超过第一阈值，和/或所述用户登录所述客户端的频率大于第二阈值，则可以确定所述用户为活跃用户。

在一种具体的实施例中，设定条件还可以为：

云端服务器接收所述客户端发送的定位信息；

云端服务器在确定所述定位信息与车站信息匹配时，获取所述客户端对应的用户的信息；

具体的，所述定位信息与车站信息匹配可以为确定所述终端设备位于所述乘坐车辆所在的车站的预定范围内；

云端服务器根据所述用户的信息获取所述活跃用户的掌脉信息。

一种可能的实现方式，所述车辆的掌脉信息集合还可以根据以下方式确定：

云端服务器在获取所述客户端上报的路线查询信息后，预测所述用户可能乘坐的公交车并获取所述用户的信息；

云端服务器根据所述用户的信息获取所述用户的掌脉信息；

云端服务器将所述用户的掌脉信息确定为所述公交车的掌脉信息集合中的一个。

为提高预测用户可能乘坐的公交车的准确性，一种可能的实现方式，所述预测所述用户可能乘坐的公交车并获取所述用户的信息还可以根据以下方式确定：

云端服务器在获取所述客户端上报的路线查询信息后，根据所述客户端对应的终端的定位信息，以及所述路线查询信息，预测所述用户可能乘坐的公交车并获取所述用户的信息。

另一种可能的实现方式，所述车辆的掌脉信息集合还可以根据以下方式确定：

步骤一、云端服务器在获取所述客户端上报的预约车辆信息后，获取所述客户端的登录信息；

其中，所述预约车辆信息包括预约公交车的车次、预约时间、预约车站中的至少一项或多项；

步骤二、云端服务器根据所述登录信息获取所述活跃用户的掌脉信息；

步骤三、云端服务器根据所述预约车辆信息，确定所述活跃用户乘坐的公交车；

步骤四、云端服务器将所述活跃用户的掌脉信息确定为所述公交车的掌脉信息集合中的一个。

步骤303：若从所述车辆的掌脉信息集合中确定出与所述乘客的掌脉信息匹配的掌脉信息，则确定所述乘客乘车验证成功。

本发明实施例中，在掌脉支付之前，根据客户端上报的活跃用户的信息确定的车辆的掌脉信息集合，通过从所述车辆的掌脉信息集合中确定出与所述乘客的掌脉信息匹配的掌脉信息，可以缩小乘车验证的范围，进而提高对掌脉支付是否合法使用的有效验证，提高验证效率。

在步骤303的具体执行过程中，可以为所述车辆确定车辆服务器接收云端服务器发送的所述车辆的掌脉信息集合后执行的；在步骤303之后，一种可能的实现方式，所述云端服务器若从所述车辆的掌脉信息集合中未确定出与所述乘客的掌脉信息匹配的掌脉信息，则从所述云端服务器的全库掌脉信息中查询匹配的掌脉信息。

在乘车人数较少时，有云端服务器执行本发明实施例中的支付方法，可以极大的减少需要占用的网络带宽，提高验证效率。

在步骤303的具体执行过程中，也可以为云端服务器确定获取所述车辆的掌脉信息集合后执行的；在步骤303之后，一种可能的实现方式，所述车辆服务器若从所述车辆的掌脉信息集合中未确定出与所述乘客的掌脉信息匹配的掌脉信息，则向所述云端服务器发送所述乘客的掌脉信息，以使所述云端服务器从全库掌脉信息中查询匹配的掌脉信息。

在乘车人数较多时，由车辆服务器在乘客乘车之前，预先获取所述车辆的掌脉信息集合，在获取乘客的掌脉信息后，执行步骤303，可以在不占用过多的网络带宽的前提下，在车辆本地，即可完成掌脉的验证，有效的提高乘车效率。

下面以云端服务器为例的实施例进行说明，包括：

步骤一、云端服务器获取所述活跃用户在所述客户端查找的路线信息；

或者，云端服务器在获取所述客户端上报的预约车辆信息后，获取所述客户端的登录信息；所述预约车辆信息包括预约公交车的车次、预约时间、预约车站中的至少一项或多项；

步骤二、云端服务器根据所述路线信息、预约车辆信息、定位信息等，预测所述活跃用户可能乘坐的公交车；

步骤三、云端服务器将所述活跃用户的掌脉信息确定为所述公交车的掌脉信息集合中的一个。

步骤四、云端服务器将所述公交车的掌脉仪获取的用户的手掌静脉特征信息，与所述掌脉信息集合进行比对，确定所述用户在乘坐所述公交车的掌脉支付是否验证成功。

基于同一发明构思，本发明实施例还提供一种支付装置，如图4所示，所述装置包括：

获取模块401，用于获取乘客的掌脉信息；所述乘客的掌脉信息是所述乘客乘坐的车辆中的掌脉仪采集的；获取所述车辆的掌脉信息集合；所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的；

处理模块402，用于若从所述车辆的掌脉信息集合中确定出与所述乘客的掌脉信息匹配的掌脉信息，则确定所述乘客乘车验证成功。

一种可能的实现方式，获取模块401，具体用于：

接收所述客户端在检测到用户操作符合设定条件时，发送的所述用户的登录信息；根据所述登录信息获取所述用户的掌脉信息。

一种可能的实现方式，获取模块401，具体用于：

接收所述客户端发送的定位信息；在确定所述定位信息与车站信息匹配时，获取所述客户端对应的用户的信息；根据所述用户的信息获取所述活跃用户的掌脉信息。

一种可能的实现方式，获取模块401，具体用于：

在获取所述客户端上报的路线查询信息后，预测所述用户可能乘坐的公交车并获取所述用户的信息；根据所述用户的信息获取所述用户的掌脉信息；将所述用户的掌脉信息确定为所述公交车的掌脉信息集合中的一个。

一种可能的实现方式，获取模块401，具体用于：

在获取所述客户端上报的预约车辆信息后，获取所述客户端的登录信息；所述预约车辆信息包括预约公交车的车次、预约时间、预约车站中的至少一项或多项；根据所述登录信息获取所述活跃用户的掌脉信息；根据所述预约车辆信息，确定所述活跃用户乘坐的公交车；将所述活跃用户的掌脉信息确定为所述公交车的掌脉信息集合中的一个。

一种可能的实现方式，获取模块401，还用于：接收车辆服务器发送的乘客的掌脉信息；

处理模块402，还用于：若从所述车辆的掌脉信息集合中未确定出与所述乘客的掌脉信息匹配的掌脉信息，则从所述云端服务器的全库掌脉信息中查询匹配的掌脉信息。

一种可能的实现方式，获取模块401，还用于：接收云端服务器发送的所述车辆的掌脉信息集合；

处理模块402，还用于：若从所述车辆的掌脉信息集合中未确定出与所述乘客的掌脉信息匹配的掌脉信息，则向所述云端服务器发送所述乘客的掌脉信息，以使所述云端服务器从全库掌脉信息中查询匹配的掌脉信息。

本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本发明各个实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

基于同一发明构思，本发明实施例还提供一种交通支付设备，该交通支付设备例如是前述方法实施例中的支付设备具，具体来说，例如可以是如图1a-图2中的公交支付设备102，或者可以是如图5中的地铁闸机202，请参见图5所示，该交通支付设备包括处理器1001、存储器1002和采集器1003，在一种可能的实施方式中，该交通支付设备还可以包括NFC模块1004，通过该NFC模块可以感应实体公交卡。另外，该交通支付设备还可以包括外壳，其中的处理器1001、存储器1002、NFC模块1004可以集成设置在该外壳之内，而采集器1003可以嵌入式地设置于外壳之中。采集器1003可以扫描用户的手掌以获得掌脉信息。

处理器1001可以是通用处理器，例如中央处理器(CPU)、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本发明实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器1002作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random Access Memory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本发明实施例中的存储器1002还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

处理器1001是交通支付设备的控制中心，可以利用各种接口和线路连接整个交通支付设备的各个部分，通过运行或执行存储在存储器1002内的指令以及调用存储在存储器内的数据，交通支付设备的各种功能和处理数据，从而对交通支付设备进行整体监控。

基于同一发明构思，本发明实施例还提供一种存储介质，该存储介质存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行如前述的支付方法的步骤。

基于同一发明构思，本发明实施例还提供一种支付装置，该支付装置包括至少一个处理器及可读存储介质，当该可读存储介质中包括的指令被该至少一个处理器执行时，可以执行前述的支付方法的步骤。

基于同一发明构思，本发明实施例还提供一种芯片***，该芯片***包括处理器，还可以包括存储器，用于实现如前述的支付方法的步骤。该芯片***可以由芯片构成，也可以包含芯片和其他分立器件。

在一些可能的实施方式中，本发明提供的支付方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机上运行时，所述程序代码用于使所述计算机执行前文述描述的根据本发明各种示例性实施方式的支付方法中的步骤。

基于同一发明构思，本发明实施例还提供一种乘车支付验证装置，该乘车支付验证装置包括：存储器，用于存储程序指令；处理器，用于调用所述存储器中存储的程序指令，按照获得的程序指令执行前文述描述的根据本发明各种示例性实施方式的支付方法中的步骤。

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

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

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

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

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种支付方法，其特征在于，所述方法包括：

获取乘客的掌脉信息；所述乘客的掌脉信息是所述乘客乘坐的车辆中的掌脉仪采集的；

获取所述车辆的掌脉信息集合；所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的；

若从所述车辆的掌脉信息集合中确定出与所述乘客的掌脉信息匹配的掌脉信息，则确定所述乘客乘车验证成功。

2.如权利要求1所述的方法，其特征在于，所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的，包括：

接收所述客户端在检测到用户操作符合设定条件时，发送的所述用户的登录信息；

根据所述登录信息获取所述用户的掌脉信息。

3.如权利要求1所述的方法，其特征在于，所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的，包括：

接收所述客户端发送的定位信息；

在确定所述定位信息与车站信息匹配时，获取所述客户端对应的用户的信息；

根据所述用户的信息获取所述活跃用户的掌脉信息。

4.如权利要求1所述的方法，其特征在于，所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的，包括：

在获取所述客户端上报的路线查询信息后，预测所述用户可能乘坐的公交车并获取所述用户的信息；

根据所述用户的信息获取所述用户的掌脉信息；

将所述用户的掌脉信息确定为所述公交车的掌脉信息集合中的一个。

5.如权利要求1所述的方法，其特征在于，所述车辆的掌脉信息集合是根据客户端上报的活跃用户的登录信息确定的，包括：

在获取所述客户端上报的预约车辆信息后，获取所述客户端的登录信息；所述预约车辆信息包括预约公交车的车次、预约时间、预约车站中的至少一项或多项；

根据所述登录信息获取所述活跃用户的掌脉信息；

根据所述预约车辆信息，确定所述活跃用户乘坐的公交车；

将所述活跃用户的掌脉信息确定为所述公交车的掌脉信息集合中的一个。

6.如权利要求1至5任一项所述的方法，其特征在于，获取乘客的掌脉信息，包括：

云端服务器接收车辆服务器发送的乘客的掌脉信息；

所述方法，还包括：

所述云端服务器若从所述车辆的掌脉信息集合中未确定出与所述乘客的掌脉信息匹配的掌脉信息，则从所述云端服务器的全库掌脉信息中查询匹配的掌脉信息。

7.如权利要求1至5任一项所述的方法，其特征在于，获取所述车辆的掌脉信息集合，包括：

车辆服务器接收云端服务器发送的所述车辆的掌脉信息集合；

所述方法，还包括：

所述车辆服务器若从所述车辆的掌脉信息集合中未确定出与所述乘客的掌脉信息匹配的掌脉信息，则向所述云端服务器发送所述乘客的掌脉信息，以使所述云端服务器从全库掌脉信息中查询匹配的掌脉信息。

8.一种支付装置，其特征在于，所述装置包括：

获取模块，用于获取乘客的掌脉信息；所述乘客的掌脉信息是所述乘客乘坐的车辆中的掌脉仪采集的；获取所述车辆的掌脉信息集合；所述车辆的掌脉信息集合是根据客户端上报的活跃用户的信息确定的；

处理模块，用于若从所述车辆的掌脉信息集合中确定出与所述乘客的掌脉信息匹配的掌脉信息，则确定所述乘客乘车验证成功。

9.一种交通支付设备，其特征在于，所述交通支付设备包括：

采集器，用于扫描乘客的掌脉信息；

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序指令执行权利要求1-6任一所述的方法包括的步骤。

10.一种存储介质，其特征在于，所述存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行权利要求1-7任一所述的方法包括的步骤。