公交支付方法、装置和公交支付系统与流程

本申请涉及通讯
技术领域：
，尤其涉及一种公交支付方法、装置和公交支付系统。
背景技术：
：公交服务是人们日常出行的主要方式，已经成为了人们生活中重要的一部分。乘客在乘坐公交时，可以通过随身携带的各种交通卡(例如，公交卡、市民卡等)进行刷卡支付；或者通过手机等移动终端使用相关联的app(例如，微信、支付宝等)进行扫码支付。然而，刷卡支付依赖于乘客必须携带交通卡；扫码支付依赖于乘客必须使用手机打开app进行扫码。以上的支付方式均降低了支付的效率，也给乘客带来了许多不便，用户体验较差。技术实现要素：有鉴于此，本申请提供一种公交支付方法、装置和公交支付系统，可以提高支付的效率以及安全性，有助于提升用户体验。为实现上述目的，本申请提供技术方案如下：根据本申请的第一方面，提出了一种公交支付系统，包括：乘客客户端、公交客户端和服务端；所述公交客户端向所述服务端发送待支付乘客人脸信息和公交位置信息；所述服务端查找与所述待支付乘客人脸信息相匹配的用户，将查找结果确定为候选用户；以及，所述服务端根据候选用户的乘客客户端上报的位置信息，从候选用户中确定出一名待支付用户，并对所述待支付用户的账户进行扣款处理；其中，所述待支付用户对应的位置信息与所述公交位置信息相匹配。根据本申请的第二方面，提出了一种公交支付方法，应用于服务端；所述方法包括：接收公交客户端发送的待支付乘客人脸信息和公交位置信息；查找与所述待支付乘客人脸信息相匹配的用户，并将查找结果确定为候选用户；根据候选用户的乘客客户端上报的位置信息，从候选用户中确定出一名待支付用户，其中，所述待支付用户对应的位置信息与所述公交位置信息相匹配；对所述待支付用户的账户进行扣款处理。根据本申请的第三方面，提出了一种公交支付装置，应用于服务端；所述装置包括：接收单元，接收公交客户端发送的待支付乘客人脸信息和公交位置信息；查找单元，查找与所述待支付乘客人脸信息相匹配的用户，并将查找结果确定为候选用户；第一确定单元，根据候选用户的乘客客户端上报的位置信息，从候选用户中确定出一名待支付用户，其中，所述待支付用户对应的位置信息与所述公交位置信息相匹配；扣款单元，对所述待支付用户的账户进行扣款处理。根据本申请的第四方面，提出了一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如上述技术方案中任一项所述方法的步骤。由以上技术方案可见，本申请通过将人脸识别应用到公交支付的场景中，使得用户只需要在上车时进行刷脸即可完成车费的支付，而无需用户携带任何交通卡或者对相关联的客户端进行操作，有助于简化用户操作，提升支付的效率和用户体验。同时，在根据人脸识别确定候选用户的基础上，通过进一步比较候选用户和公交的位置信息来最终确定待支付用户，可以提高识别待支付用户的准确度，从而进一步提高支付的安全性。附图说明图1是本申请一示例性实施例示出的一种公交支付系统的架构示意图。图2是本申请一示例性实施例示出的一种公交支付方法的流程图。图3是本申请一示例性实施例示出的绑定用户的流程图。图4是本申请一示例性实施例示出的另一种公交支付方法的流程图。图5是本申请一示例性实施例示出的服务端确定待支付用户的流程图。图6是本申请一示例性实施例示出的一种电子设备的结构示意图。图7是本申请一示例性实施例示出的一种公交支付装置的框图。具体实施方式这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。图1是本申请一示例性实施例示出的一种公交支付系统的架构示意图。如图1所示，该系统可以包括服务器11、网络12、若干乘客设备(比如手机13、手机14等)以及公交设备(比如车载终端15、车载终端16等)。服务器11可以包含一独立主机的物理服务器，或者该服务器11可以为主机集群承载的虚拟服务器，或者该服务器11可以为云服务器。在运行过程中，服务器11可以运行某一应用的服务器侧的程序，以实现该应用的相关业务功能。比如，当该服务器11运行公交支付方法的程序时，可以被配置为用于实现公交交付功能的服务端。手机13-14只是用户可以使用的一种类型的乘客设备。实际上，用户显然还可以使用诸如下述类型的电子设备：平板设备、笔记本电脑、掌上电脑(personaldigitalassistant，pda)、可穿戴设备(如智能手表、智能手环、智能眼镜等)等，本申请并不对此进行限制。在运行过程中，该乘客设备可以运行某一应用的乘客客户端侧的程序，以实现该应用的相关业务功能。比如，当该乘客设备运行公交支付方法的程序时，可以被配置为用于实现公交支付功能的乘客客户端。车载终端15-16只是可以用于实现公交交付功能的一种公交设备。在运行过程中，该公交设备可以运行某一应用的公交客户端侧的程序，以实现该应用的相关业务功能。比如，当该公交设备运行公交支付方法的程序时，可以被配置为用于实现公交支付功能的公交客户端。而对于手机13-14、车载终端15-16和服务器11之间进行交互的网络12，可以包括多种类型的有线或无线网络。比如，该网络12可以包括公共交换电话网络(publicswitchedtelephonenetwork，pstn)和因特网，本申请并不对此进行限制。可见，在本申请的技术方案的实施过程中，涉及到服务端、乘客客户端、公交客户端之间的三方数据交互；下面分别结合服务端侧的处理逻辑和三方的交互过程，对本申请的技术方案进行描述。请参见图2，图2是本申请一示例性实施例示出的一种公交支付方法的流程图，该方法应用于服务端，可以包括以下步骤：步骤202，接收公交客户端发送的待支付乘客人脸信息和公交位置信息。在本实施例中，公交客户端获取待支付乘客人脸信息和公交位置信息并发送至服务端。具体的，待支付乘客人脸信息可由公交客户端配置的摄像头采集获得，公交位置信息可由公交客户端配置的gps模块或者北斗卫星导航模块采集获得。其中，本领域技术人员应当理解的是：由于公交客户端配置于公交中，那么该公交客户端采集的位置信息即可用于表示该公交的位置信息(即公交位置信息)。步骤204，查找与所述待支付乘客人脸信息相匹配的用户，并将查找结果确定为候选用户。在本实施例中，可以基于机器学习模型进行人脸识别从而确定候选用户。具体的，首先将所述待支付乘客人脸信息输入预配置的人脸向量模型以得到所述待支付乘客人脸信息的人脸向量数据，所述人脸向量模型用于将人脸信息转换成相应的人脸向量数据；再将得到的人脸向量数据输入用户匹配模型，并选取输出结果中置信度在预设排名之前的用户作为候选用户。例如，可以选取输出结果中置信度最高的前五位用户作为候选用户。需要说明的是，使用本申请技术方案进行公交支付的用户需要预先通过乘客客户端进行实人认证和人脸录入。具体的，乘客客户端在采集到用户的人脸信息后将该人脸信息和用户账号上传至服务端，服务端使用预先训练完成的人脸向量模型将该人脸信息转换成相应的人脸向量数据，并与用户账号进行绑定，通过上述绑定操作，服务端中记录了用户(用户账号)与人脸向量数据的对应关系。基于上述服务端记录的对应关系，所述用户匹配模型可由乘客客户端上传的用户信息生成训练集训练得到，所述用户信息包含用户和用户的人脸信息的对应关系。具体的，所述训练集由以下方式生成：将用户信息中的人脸信息经所述人脸向量模型转换为相应的人脸向量数据，并将转换得到的人脸向量数据与账户信息中的用户的对应关系作为训练集。考虑到服务端存在更新用户(用户账号)和人脸向量数据的情况(例如，存在新用户进行实人认证和人脸录入，或者老用户修改用户账号或重新进行人脸录入)，为了提高用户匹配模型匹配用户的准确性，可以定时根据更新后的用户及其人脸向量数据进行训练以更新所述用户匹配模型。具体的，可以按照预设周期基于乘客客户端上传的用户信息生成训练集，并根据生成的训练集更新所述用户匹配模型。步骤206，根据候选用户的乘客客户端上报的位置信息，从候选用户中确定出一名待支付用户。在本实施例中，所述待支付用户对应的位置信息与所述公交位置信息相匹配。具体的，在确定唯一的待支付用户时，可以将候选用户的乘客客户端上报的位置信息与公交位置信息进行比较，当候选用户中存在唯一用户的乘客客户端上报的位置信息与公交位置信息之间的差距在预设范围之内时，确定该唯一用户为待支付用户。本领域技术人员应当理解的是：当用户使用的手机安装有乘客客户端且该用户随身携带手机时，该乘客客户端上报的位置信息即可表示该用户的位置信息。在本申请的技术方案中，由于基于机器学习模型进行人脸识别，而该人脸识别的方式在小规模人脸数据集上可以达到较高的准确率，但是随着人脸数据集的扩大，准确率会有明显的下降。因此，本申请通过先利用人脸识别确定候选用户，再进一步比较候选用户和公交的位置信息来最终确定待支付用户，可以提高识别待支付用户的准确度，从而进一步提高支付的安全性。而针对候选用户的位置信息，在一实施例中，所述候选用户的位置信息由所述候选用户的乘客客户端按照预设频率上报；在另一实施例中，所述候选用户的位置信息由所述服务端在确定出所述候选用户后向所述候选用户的乘客客户端请求获得。在本实施例中，所述服务端存储有用户的历史乘车记录。因此，当候选用户的位置信息和公交位置信息不相匹配(例如，采集的位置信息存在较大误差)，或者候选用户中存在多位用户满足位置信息相匹配的要求时，可以根据历史乘车记录来确定待支付用户。具体的，当所述候选用户中不存在位置信息与所述公交位置信息相匹配的用户，或者存在多个位置信息与所述公交位置信息相匹配的用户时，可以获取所述候选用户的历史乘车记录；其中，当所述候选用户中任一用户的历史乘车记录中包含一个或多个乘车位置信息与所述公交位置信息相匹配，且所述任一用户唯一时，确定所述任一用户为所述待支付用户。由于公交的行驶路线往往比较固定，用户乘坐同一公交的位置也就相应的比较固定。因此，通过结合历史乘车记录来确定待支付用户，可以有效提高确定待支付用户的准确率，从而提高用户支付的安全性。步骤208，对所述待支付用户的账户进行扣款处理。在本实施例中，可以先根据所述公交客户端发送的公交标识确定相应的公交线路价格，再按照所述公交线路价格对所述待支付用户的账户进行扣款处理。其中，所述公交标识与所述待支付乘客人脸信息以及所述公交位置信息相关联。具体的，在一种情况下，公交客户端可以将待支付乘客人脸信息、公交位置信息和公交标识一起发送至服务端；在另一种情况下，公交客户端可以单独发送公交标识，并标明该公交标识与相关联的待支付乘客人脸信息和公交位置信息的对应关系。由以上技术方案可见，本申请通过将人脸识别应用到公交支付的场景中，使得用户只需要在上车时进行刷脸即可完成车费的支付，而无需用户携带任何交通卡或者对相关联的客户端进行操作，有助于简化用户操作，提升支付的效率和用户体验。同时，在根据人脸识别确定候选用户的基础上，通过进一步比较候选用户和公交的位置信息来最终确定待支付用户，可以提高识别待支付用户的准确度，从而进一步提高支付的安全性。为了便于理解，下面结合附图对本申请的技术方案进行详细说明。而在实现基于本申请的技术方案时，可以分为两个阶段的处理过程：1)第一阶段：绑定用户；2)第二阶段：刷脸支付。下面分别对这两个阶段进行详细描述。1、绑定用户请参见图3，图3是本申请一示例性实施例示出的绑定用户的流程图。如图3所示，绑定用户的过程可以包括以下步骤：步骤302，用户通过乘客客户端向服务端注册对应的用户账号。在本实施例中，用户需要在服务端上拥有对应的用户账号，该用户账号可以与该用户的资金账户相关联，以便于服务端通过该用户账号从该用户的资金账户中扣除/支付相应的资金。通常来说，乘客客户端可以在首次运行时引导用户完成账号的注册，其中包括实人认证和人脸录入。当然，用户也可以根据实际情况，在其他时机或场景下完成注册操作，本申请并不对此进行限制。步骤304，服务端将人脸信息转换成人脸向量数据。在本实施例中，当用户通过乘客客户端注册用户账号时，乘客客户端可以在注册过程中获取用户的人脸信息(即人脸录入)，并将获取的人脸信息上传至服务端。服务端通过预先训练完成的人脸向量模型将接收到的人脸信息转换成相应的人脸向量数据。其中，人脸向量模型的输入为人脸信息，输出为输入的人脸信息对应的人脸向量数据。步骤306，服务端将人脸向量数据与对应的用户账号进行绑定。在本实施例中，所有乘客客户端的用户均可以通过上述方式注册获取相应的用户账号，并在服务端上实现人脸向量数据与用户账号的绑定。步骤308，服务端训练用户匹配模型并定时更新该用户匹配模型，以用于后续用户刷脸支付时匹配用户账号进行扣款。在本实施例中，通过上述绑定操作，服务端记录了各个用户(用户账号)与人脸向量数据的对应关系。根据该对应关系作为训练集，服务端可以训练得到一个用于根据人脸向量数据匹配用户账号的用户匹配模型；其中，该用户匹配模型的输入为人脸向量数据，输出为与输入的人脸向量数据相匹配的用户账号以及对应的置信度。同时，由于服务端存在更新用户(用户账号)和人脸向量数据的情况(例如，存在新用户进行实人认证和人脸录入，或者老用户修改用户账号或重新进行人脸录入)，为了提高用户匹配模型匹配用户的准确性，可以定时(即按照预设周期)根据更新后的用户及其人脸向量数据进行训练以更新所述用户匹配模型。例如，可以在每天的凌晨24:00基于更新后的用户(用户账号)和人脸向量数据的对应关系，重新训练用户匹配模型以更新该用户匹配模型。当然，更新用户匹配模型的周期可以根据实际情况灵活设定，本申请并不对此进行限制。基于上述绑定用户以及训练用户匹配模型的过程，用户后续便可通过乘客客户端、公交客户端和服务端之间的交互来进行刷脸支付。2)刷脸支付请参见图4，图4是本申请一示例性实施例示出的另一种公交支付方法的流程图。如图4所示，该方法可以包括以下步骤：步骤402，公交客户端采集待支付乘客人脸信息。步骤404，公交客户端采集公交位置信息。在本实施例中，待支付乘客人脸信息可由公交客户端配置的摄像头采集获得，公交位置信息可由公交客户端配置的gps模块或者北斗卫星导航模块采集获得。其中，本领域技术人员应当理解的是：由于公交客户端配置于公交中，那么该公交客户端采集的位置信息即可用于表示该公交的位置信息(即公交位置信息)。步骤406，公交客户端将采集到的待支付乘客人脸信息、公交位置信息和公交标识上传至服务端。在本实施例中，在一种情况下，公交客户端可以将待支付乘客人脸信息、公交位置信息和公交标识一起上传至服务端；在另一种情况下，公交客户端也可以单独发送公交标识，并标明该公交标识与相关联的待支付乘客人脸信息和公交位置信息的对应关系。步骤408，服务端将接收到的待支付乘客人脸信息输入人脸向量模型，以获得该待支付乘客人脸信息的人脸向量数据。在本实施例中，人脸向量模型即为上述“绑定用户”阶段中的人脸向量模型，通过获得人脸向量模型可用于后续使用用户匹配模型来匹配待支付乘客人脸信息对应的用户。步骤410，服务端将得到的人脸向量数据输入用户匹配模型，并选取输出结果中置信度在预设排名之前的用户作为候选用户。在本实施例中，用户匹配模型即为在上述“绑定用户”阶段中训练得到的用户匹配模型。另外，还可以选取输出结果中置信度超过预设阈值的用户作为候选用户；或者选取输出结果中置信度在预设排名之前且超过预设阈值的用户作为候选用户。举例而言，假定输出结果如表1所示：用户置信度用户a30％用户b16％用户c20％用户d18％用户e10％……表1那么，可以选取置信度位于前三的用户作为候选用户，即用户a、用户c和用户d。也可以选取置信度超过15％的用户作为候选用户，即用户a、用户b、用户c和用户d。还可以选取置信度位于前三，且置信度超过19％的用户作为候选用户，即用户a和用户c。当然，预设排名和预设阈值的具体取值可以根据实际情况灵活设置，本申请并不对此进行限制。步骤412，服务端从候选用户中确定一名待支付用户。在本实施例中，结合图5对服务端确定待支付用户的过程进行详细描述。如图5所示，该过程可以包括以下步骤：在步骤502中，获取候选用户的位置信息。其中，在一实施例中，每个乘客客户端均按照预设频率主动获取乘客设备的位置信息并上传至服务端。本领域技术人员应当理解的是：当用户使用的乘客设备安装有乘客客户端且该用户随身携带手机时，该乘客客户端上报的位置信息即可表示该用户的位置信息。那么，基于该上传位置信息的机制，候选用户的位置信息即可由候选用户中各个用户使用的乘客客户端按照预设频率主动上报至服务端。当然，乘客客户端上传位置信息的频率可根据实际情况灵活设定，本申请并不对此进行限制。通过使乘客客户端按照预设频率上传位置信息的方式来获取候选用户的位置信息，可提高获取候选用户的位置信息的效率，从而进一步加快匹配待支付用户的速度，有效减少延迟。在另一实施例中，候选用户的位置信息可由服务端在确定出候选用户后向该候选用户的乘客客户端请求获得。比如，承接于上述举例，服务端在确定候选用户为用户a、c、d后，分别向用户a、c、d的乘客客户端下发获取其位置信息的请求，以使得用户a、c、d的乘客客户端获取位置信息并返回至服务端。通过服务端主动获取位置信息的方式，可以有效减少乘客客户端采集位置信息的频率以及服务端与乘客客户端之间的数据交互，从而提高服务端的性能，降低乘客客户端的功耗。在步骤504中，计算候选用户的位置信息与公交位置信息之间的差距。在步骤506中，判断候选用户中是否存在唯一的用户的位置信息与公交位置信息之间的差距在预设范围之内，若存在，则转入步骤512，否则转入步骤508。其中，考虑到公交客户端和乘客客户端采集的位置信息均可能存在一定的误差，可以根据实际情况设置一个合理的预设范围，当然，本申请并不对预设范围的具体数值进行限制。由于本申请基于机器学习模型进行人脸识别，而该人脸识别的方式在小规模人脸数据集上可以达到较高的准确率，但是随着人脸数据集的扩大，准确率会有明显的下降。因此，本申请通过先利用人脸识别确定候选用户，再进一步比较候选用户和公交的位置信息来最终确定待支付用户，可以提高识别待支付用户的准确度，从而进一步提高支付的安全性。在步骤508中，获取候选用户的历史乘车记录。其中，当候选用户的位置信息和公交位置信息不相匹配(例如，采集的位置信息存在较大误差)，或者候选用户中存在多位用户满足位置信息相匹配的要求时，可以根据历史乘车记录来确定待支付用户。在步骤510中，判断候选用户中是否存在任一用户的历史乘车记录中包含一个或多个乘车位置信息与公交位置信息相匹配，且该任一用户唯一；若存在，则转入步骤512，否则转入步骤514。其中，还可以设置一个阈值用于衡量候选用户的历史乘车记录与当前公交位置信息的相似度。例如，当候选用户中存在唯一的用户的历史乘车记录中包含超过预设阈值个乘车位置信息与公交位置信息相匹配时，则判定该唯一的用户为待支付用户。当然，预设阈值可根据实际情况灵活设定，本申请并不对此进行限制。由于公交的行驶路线往往比较固定，用户乘坐同一公交的位置也就相应的比较固定。因此，通过结合历史乘车记录来确定待支付用户，可以有效提高确定待支付用户的准确率，从而提高用户支付的安全性。在步骤512中，承接于步骤506，确定该唯一用户为待支付用户；承接于步骤510，确定该任一用户为待支付用户。在步骤514中，当候选用户中不存在满足步骤510中要求的用户，或满足该要求的用户存在多个时，则判定匹配待支付用户失败。以上步骤502-514为服务端确定待支付用户的过程。步骤414，服务端对待支付用户的账户进行扣款处理。在本实施例中，服务端可以根据公交标识确定相应的公交线路价格，从而按照该公交线路价格对确定出的待支付用户进行扣款处理。在一种情况下，服务端可以对待支付用户相关联的资金账户进行扣款。在另一种情况下，用户可以预先在自身的用户账号中进行充值；那么服务端可以直接从待支付用户的用户账号的余额中进行扣款。同时，服务端在扣款成功后，可以记录下该待支付用户的本次乘车记录以及扣款账单。步骤416，服务端向公交客户端返回处理结果。在本实施例中，当未确定出唯一的待支付用户时，向公交客户端返回“刷脸失败”的消息；当确定出的待支付用户的账户余额不足时，向公交客户端返回“余额不足，扣款失败”的消息；当对待支付用户的账户扣款成功时，向公交客户端返回“扣款成功”的消息。步骤418，公交客户端语音播报接收到的处理结果。在本实施例中，服务端还可以将处理结果发送至待支付用户的乘客客户端，以便于待支付用户通过乘客客户端查看本次乘车记录以及相应的支付结果。如果该用户对支付结果存在异议，可以通过乘客客户端提出在线申诉。由以上技术方案可见，本申请通过将人脸识别应用到公交支付的场景中，使得用户只需要在上车时进行刷脸即可完成车费的支付，而无需用户携带任何交通卡或者对相关联的客户端进行操作，有助于简化用户操作，提升支付的效率和用户体验。同时，在根据人脸识别确定候选用户的基础上，通过进一步比较候选用户和公交的位置信息来最终确定待支付用户，可以提高识别待支付用户的准确度，从而进一步提高支付的安全性。图6示出了根据本申请的一示例性实施例的电子设备的结构示意图。请参考图6，在硬件层面，该电子设备包括处理器602、内部总线604、网络接口606、内存608以及非易失性存储器610，当然还可能包括其他业务所需要的硬件。处理器602从非易失性存储器610中读取对应的计算机程序到内存608中然后运行，在逻辑层面上形成公交支付装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。请参考图7，在软件实施方式中，该公交支付装置可以包括接收单元701、查找单元702、第一确定单元703和扣款单元704。其中：接收单元701，接收公交客户端发送的待支付乘客人脸信息和公交位置信息；查找单元702，查找与所述待支付乘客人脸信息相匹配的用户，并将查找结果确定为候选用户；第一确定单元703，根据候选用户的乘客客户端上报的位置信息，从候选用户中确定出一名待支付用户，其中，所述待支付用户对应的位置信息与所述公交位置信息相匹配；扣款单元704，对所述待支付用户的账户进行扣款处理。可选的，所述查找单元702具体用于：将所述待支付乘客人脸信息输入预配置的人脸向量模型以得到所述待支付乘客人脸信息的人脸向量数据，所述人脸向量模型用于将人脸信息转换成相应的人脸向量数据；将得到的人脸向量数据输入用户匹配模型，并选取输出结果中置信度在预设排名之前的用户作为候选用户；其中，所述用户匹配模型由乘客客户端上传的用户信息生成训练集训练得到，所述用户信息包含用户和用户的人脸信息的对应关系。可选的，所述训练集由以下方式生成：将用户信息中的人脸信息经所述人脸向量模型转换为相应的人脸向量数据，并将转换得到的人脸向量数据与账户信息中的用户的对应关系作为训练集。可选的，还包括：生成单元705，按照预设周期基于乘客客户端上传的用户信息生成训练集；更新单元706，根据生成的训练集更新所述用户匹配模型。可选的，所述候选用户的位置信息由所述候选用户的乘客客户端按照预设频率上报；或者，所述候选用户的位置信息由所述服务端在确定出所述候选用户后向所述候选用户的乘客客户端请求获得。可选的，所述扣款单元具体用于：根据所述公交客户端发送的公交标识确定相应的公交线路价格，所述公交标识与所述待支付乘客人脸信息以及所述公交位置信息相关联；按照所述公交线路价格对所述待支付用户的账户进行扣款处理。可选的，所述服务端存储有用户的历史乘车记录；所述装置还包括：获取单元707，当所述候选用户中不存在位置信息与所述公交位置信息相匹配的用户，或者存在多个位置信息与所述公交位置信息相匹配的用户时，获取所述候选用户的历史乘车记录；第二确定单元708，当所述候选用户中任一用户的历史乘车记录中包含一个或多个乘车位置信息与所述公交位置信息相匹配，且所述任一用户唯一时，确定所述任一用户为所述待支付用户。上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器，上述指令可由上述公交支付装置的处理器执行以完成上述方法，该方法可以包括：接收公交客户端发送的待支付乘客人脸信息和公交位置信息；查找与所述待支付乘客人脸信息相匹配的用户，并将查找结果确定为候选用户；根据候选用户的乘客客户端上报的位置信息，从候选用户中确定出一名待支付用户，其中，所述待支付用户对应的位置信息与所述公交位置信息相匹配；对所述待支付用户的账户进行扣款处理。可选的，所述查找与所述待支付乘客人脸信息相匹配的用户，并将查找结果确定为候选用户，包括：将所述待支付乘客人脸信息输入预配置的人脸向量模型以得到所述待支付乘客人脸信息的人脸向量数据，所述人脸向量模型用于将人脸信息转换成相应的人脸向量数据；将得到的人脸向量数据输入用户匹配模型，并选取输出结果中置信度在预设排名之前的用户作为候选用户；其中，所述用户匹配模型由乘客客户端上传的用户信息生成训练集训练得到，所述用户信息包含用户和用户的人脸信息的对应关系。可选的，所述训练集由以下方式生成：将用户信息中的人脸信息经所述人脸向量模型转换为相应的人脸向量数据，并将转换得到的人脸向量数据与账户信息中的用户的对应关系作为训练集。可选的，还包括：按照预设周期基于乘客客户端上传的用户信息生成训练集；根据生成的训练集更新所述用户匹配模型。可选的，所述候选用户的位置信息由所述候选用户的乘客客户端按照预设频率上报；或者，所述候选用户的位置信息由所述服务端在确定出所述候选用户后向所述候选用户的乘客客户端请求获得。可选的，所述对所述待支付用户的账户进行扣款处理，包括：根据所述公交客户端发送的公交标识确定相应的公交线路价格，所述公交标识与所述待支付乘客人脸信息以及所述公交位置信息相关联；按照所述公交线路价格对所述待支付用户的账户进行扣款处理。可选的，所述服务端存储有用户的历史乘车记录；所述方法还包括：当所述候选用户中不存在位置信息与所述公交位置信息相匹配的用户，或者存在多个位置信息与所述公交位置信息相匹配的用户时，获取所述候选用户的历史乘车记录；当所述候选用户中任一用户的历史乘车记录中包含一个或多个乘车位置信息与所述公交位置信息相匹配，且所述任一用户唯一时，确定所述任一用户为所述待支付用户。其中，所述非临时性计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等，本申请并不对此进行限制。以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。当前第1页12