CN111429229A - 一种快速下单及验证方法、服务器及系统 - Google Patents

Abstract

一种快速下单及验证方法、服务器及系统，方法包括：接收用户的卡券使用请求；判断车牌号与卡券是否在预存的关联数据库内；若是，则生成服务订单；当用户车辆到达洗车场所时，验证车辆的车牌号是否与服务订单内的车牌号相同；若是，则将验证通过的服务订单信息发送给服务人员，以便服务人员根据服务订单信息为车辆进行对应的服务。本发明以卡券下单，实现用户在线选卡快速下单，简化下单流程，减少用户操作步骤，提高用户使用好感度，线下验证车牌号的有效性，既能保证持有卡券的用户权益不会被冒用，同时无需用户在现场进行身份验证，解决了用户在地下停车场无信号的情况下验证手机号或其它信息导致收不到验证码的问题。

Description

一种快速下单及验证方法、服务器及系统

技术领域

本发明涉及汽车服务技术领域，特别是涉及一种快速下单及验证方法、服务器及系统。

背景技术

在地下停车场无信号的场景下，当用户在地下停车场进行在线下单时，通常需要先进行登录、手机号验证等操作，以验证用户的身份，而由于其处于无信号环境，无法接收到手机验证码，且登录、验证、下单等一系列操作会让用户感觉繁琐，流程复杂，造成用户使用不便，体验感差。因此，有必要设计一种更好的方法，以解决上述问题。

发明内容

针对现有技术存在的问题，本发明提供一种线上节省下单时间，简化下单流程，在线下对车辆进行验证的快速下单及验证方法、服务器及系统。

本发明解决上述技术问题的技术方案如下：

一种快速下单及验证方法，包括：

接收用户的卡券使用请求，所述卡券使用请求包括用户车牌号，及用户所选的卡券；

判断所述车牌号与所述卡券是否在预存的关联数据库内；

若是，则将所述卡券内用户选择的服务项目次数减一，并生成服务订单；

当用户车辆到达洗车场所时，验证所述车辆的车牌号是否与所述服务订单内的车牌号相同；

若是，则将验证通过的服务订单信息发送给服务人员，以便所述服务人员根据所述服务订单信息为所述车辆进行对应的服务。

本发明的有益效果是：根据用户的卡券使用请求，判断用户车牌号与所选的卡券是否在预存的关联数据库内，若是，则说明该车牌号已绑定有卡券，以该卡券下单，实现用户在线选卡快速下单，简化下单流程，减少用户操作步骤，提高用户使用好感度。生成服务订单后，当用户车辆到达线下洗车场所时，验证车牌号是否与服务订单内的车牌号相同，若是，则说明线上下单与线下要求服务的车辆一致，则将验证通过的服务订单信息发送给服务人员，以便服务人员对该车辆进行服务，线下验证车牌号的有效性，既能保证持有卡券的用户权益不会被冒用，同时无需用户在现场进行身份验证，解决了用户在地下停车场无信号的情况下验证手机号或其它信息导致收不到验证码的问题。

在上述技术方案的基础上，本发明还可以做如下改进。

在优选的实施例中，接收用户的卡券使用请求之前，还包括：

接收用户的登录请求，为用户建立账号；

将用户输入的车牌号和手机号信息存储于所述账号内；

当接收用户的卡券使用请求时，判断用户的账号下是否存在卡券；

若是，显示所述卡券以供用户选择。

采用上述进一步方案的有益效果是：在用户采用卡券下单之前，当用户登录时，为用户建立唯一的账号，并将用户的车牌号和手机号信息存储于该账号内，在用户选卡下单时，判断用户的账号下是否存在卡券，若不存在，则提示用户购买卡券或无法使用卡券，若存在卡券，则显示用户已有卡券供用户选择，从而实现在线快速下单。

在优选的实施例中，判断所述车牌号与所述卡券是否在预存的关联数据库内之前，在售出卡券时，将所述卡券与用户车牌号关联，并存储于所述关联数据库内。

采用上述进一步方案的有益效果是：在售出卡券时，将卡券与用户车牌号关联，并存储于关联数据库内，因此在使用时只有关联的车牌号才能够使用对应的卡券，避免了他人冒用卡券的问题。

在优选的实施例中，验证所述车辆的车牌号是否与所述服务订单内的车牌号相同；

若否，则将所述车辆的车牌号与用户已有的卡券关联；

以所述车牌号及其关联的所述卡券重复上述下单步骤。

采用上述进一步方案的有益效果是：当线下验证车牌号与服务订单内的车牌号不同时，即下单车牌号与实际要求服务的车辆车牌号不一致，可根据用户的请求，核对用户身份后，将用户当前车辆的车牌号与用户已有的卡券关联，然后以该车牌号及其关联的卡券重复上述下单步骤完成下单，再次下单时，则可直接选卡下单，通过上述步骤可以使家庭内多车可使用同一张卡券，为一人或一家多车的用户提供了便利。

在优选的实施例中，生成服务订单之后还包括：

将所述服务订单发送给用户及服务人员；

当服务完成后，将订单完成信息发送给用户，所述订单完成信息包括所述卡券内剩余的服务项目及次数。

采用上述进一步方案的有益效果是：生成服务订单后，将服务订单发送给用户和服务人员，既能方便用户查看，又能使服务人员及时做好服务准备，当服务完成后，将订单完成信息发送给用户，便于用户查看卡券内剩余的服务项目及次数，使用户的每次消费可查询、有记录。

本发明解决上述技术问题的另一种技术方案如下：

一种服务器，包括：

接收模块，用于接收用户的卡券使用请求，所述卡券使用请求包括用户车牌号，及用户所选的卡券；

判断模块，用于判断所述车牌号与所述卡券是否在预存的关联数据库内；

处理模块，用于将所述卡券内用户选择的服务项目次数减一，并生成服务订单；

验证模块，用于当用户车辆到达洗车场所时，验证所述车辆的车牌号是否与所述服务订单内的车牌号相同；

发送模块，用于将验证通过的服务订单信息发送给服务人员，以便所述服务人员根据所述服务订单信息为所述车辆进行对应的服务。

在上述技术方案的基础上，本发明还可以做如下改进。

在优选的实施例中，所述接收模块，还用于接收用户的登录请求，为用户建立账号；

存储模块，用于将用户输入的车牌号和手机号信息存储于所述账号内；

所述判断模块，用于当接收用户的卡券使用请求时，判断用户的账号下是否存在卡券；

显示模块，用于显示所述卡券以供用户选择。

在优选的实施例中，还包括第一关联模块，用于在售出卡券时，将所述卡券与用户车牌号关联，并存储于所述关联数据库内。

在优选的实施例中，还包括第二关联模块，用于在验证所述车辆的车牌号与所述服务订单内的车牌号不同时，将所述车辆的车牌号与用户已有的卡券关联。

本发明解决上述技术问题的另一种技术方案如下：

一种快速下单及验证系统，包括用户端、服务端及服务器；

所述用户端，用于供用户发起卡券使用请求，所述卡券使用请求包括用户车牌号，及用户所选的卡券；

所述服务器，用于接收用户的卡券使用请求；

判断所述车牌号与所述卡券是否在预存的关联数据库内；

若是，则将所述卡券内用户选择的服务项目次数一，并生成服务订单；

当用户车辆到达洗车场所时，验证所述车辆的车牌号是否与所述服务订单内的车牌号相同；

若是，则将验证通过的服务订单信息发送给服务人员，以便所述服务人员根据所述服务订单信息为所述车辆进行对应的服务；

所述服务端，用于接收所述服务器发送的服务订单信息。

本发明的有益效果：

根据用户的卡券使用请求，判断用户车牌号与所选的卡券是否在预存的关联数据库内，若是，则说明该车牌号已绑定有卡券，以该卡券下单，实现用户在线选卡快速下单，简化下单流程，减少用户操作步骤，提高用户使用好感度。生成服务订单后，当用户车辆到达线下洗车场所时，验证车牌号是否与服务订单内的车牌号相同，若是，则说明线上下单与线下要求服务的车辆一致，则将验证通过的服务订单信息发送给服务人员，以便服务人员对该车辆进行服务，线下验证车牌号的有效性，既能保证持有卡券的用户权益不会被冒用，同时无需用户在现场进行身份验证，解决了用户在地下停车场无信号的情况下验证手机号或其它信息导致收不到验证码的问题。

附图说明

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

图1为本发明实施例提供的一种快速下单及验证方法的示意性流程图；

图2为本发明另一实施例提供的一种快速下单及验证方法的示意性流程图；

图3为本发明实施例提供的一种服务器的示意性结构框图；

图4为本发明实施例提供的一种快速下单及验证系统的示意性结构框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

下面通过具体的实施例进行描述。

如图1所示，本发明的一个实施例提供的一种快速下单及验证方法100，具体的，在本实施例中，上述快速下单及验证方法方法的执行主体可以是服务平台或者服务器。快速下单及验证方法100包括如下步骤：

步骤11：接收用户的卡券使用请求，卡券使用请求包括用户车牌号，及用户所选的卡券。

用户在用户端上在线下单，下单时输入车牌号会选择已注册的车牌号，并选择一卡券进行下单，用户端一般为智能手机，用户可以通过手机APP或微信公众号或微信小程序等应用程序进行在线选卡下单。服务器则接收用户的卡券使用请求，获取用户的车牌号及选择的卡券，卡券一般为洗车卡或保养卡等。

步骤12：判断车牌号与卡券是否在预存的关联数据库内。

根据用户的卡券使用请求，判断用户车牌号与所选的卡券是否在预存的关联数据库内，若是，则说明该车牌号已绑定有卡券，以该卡券下单，实现用户在线选卡快速下单，简化下单流程，减少用户操作步骤，提高用户使用好感度。若车牌号或所选卡券不在关联数据库内，则说明该用户为非持卡用户，则无法使用卡券下单。

步骤13：若步骤12判断结果为是，则将卡券内用户选择的服务项目次数减一，并生成服务订单。

用户选择卡券后，并在该卡券内选择自己所需的服务项目，则服务器根据用户的选择，将卡券内用户选择的服务项目次数减一，生成服务订单。服务订单内包括用户的车辆信息、用户的卡券信息及用户选择的服务项目等。

步骤14：当用户车辆到达洗车场所时，验证车辆的车牌号是否与服务订单内的车牌号相同。

在一实施例中，用户车辆到达洗车场所后，由服务人员人工查验到场车辆的车牌号是否与服务订单的车牌号相同，并将查验结果上传到服务器。具体可以是，服务人员采用服务端(智能手机或其它手持终端)扫描车牌获取车牌号，服务器接收车牌号后，根据该车牌号搜索是否有对应的服务订单，若有，则说明车牌号与服务订单相匹配，验证通过，则服务人员在服务端点击验证通过选项；若无，则说明该车牌号与服务订单的车牌号不一致，验证不通过，则服务人员在服务端点击验证不通过选项。通过扫描车牌的方式，可避免人工输入车牌号的麻烦及可能输错的问题。

在另一实施例中，也可以通过洗车场所的摄像头拍摄车辆车牌号照片后上传到服务器，服务器识别车牌号后，自动判断到场车辆的车牌号是否与服务订单的车牌号相同，若是，则验证通过。通过摄像头拍照，服务器自动识别车牌号并进行验证，更加智能化。

步骤15：若步骤14的验证结果为是，则将验证通过的服务订单信息发送给服务人员，以便服务人员根据服务订单信息为车辆进行对应的服务。

当验证通过时，服务器实时反馈验证结果，并发送给服务人员的服务端，服务人员则可以根据验证通过的服务订单信息为用户提供对应的服务。

上述实施例提供的快速下单及验证方法，根据用户的卡券使用请求，判断用户车牌号与所选的卡券是否在预存的关联数据库内，若是，则说明该车牌号已绑定有卡券，以该卡券下单，实现用户在线选卡快速下单，简化下单流程，减少用户操作步骤，提高用户使用好感度。生成服务订单后，当用户车辆到达线下洗车场所时，验证车牌号是否与服务订单内的车牌号相同，若是，则说明线上下单与线下要求服务的车辆一致，则将验证通过的服务订单信息发送给服务人员，以便服务人员对该车辆进行服务，线下验证车牌号的有效性，既能保证持有卡券的用户权益不会被冒用，同时无需用户在现场进行身份验证，解决了用户在地下停车场无信号的情况下验证手机号或其它信息导致收不到验证码的问题。

本发明另一实施例还提供一种快速下单及验证方法100，在步骤11之前，还包括如下步骤：

接收用户的登录请求，为用户建立账号；

将用户输入的车牌号和手机号信息存储于所述账号内；

当接收用户的卡券使用请求时，判断用户的账号下是否存在卡券；

若是，显示所述卡券以供用户选择。

在用户采用卡券下单之前，当用户登录APP或公众号或小程序时，一般采用手机号登录，此时服务器根据该手机号为用户建立唯一的账号，并将用户的车牌号和手机号信息存储于该账号内。在用户选卡下单时，判断用户的账号下是否存在卡券，若不存在，则提示用户需购买卡券或无法使用卡券，若存在卡券，则显示用户已有的卡券供用户选择，从而实现在线快速选卡下单。

在上述各实施例中，判断车牌号与卡券是否在预存的关联数据库内之前，在售出卡券时，将卡券与用户车牌号关联，并存储于关联数据库内。

在售出卡券时，将卡券与用户车牌号关联，并存储于关联数据库内，因此在使用时只有关联的车牌号才能够使用对应的卡券，避免了他人冒用卡券的问题。

如图2所示，本发明另一实施例还提供一种快速下单及验证方法100，若步骤14验证车辆的车牌号与服务订单内的车牌号不同，则进入步骤16：将车辆的车牌号与用户已有的卡券关联，然后以该车牌号及其关联的卡券重复上述下单步骤11至步骤15。

当线下验证车牌号与服务订单内的车牌号不同时，即下单车牌号与实际要求服务的车辆车牌号不一致，可根据用户的请求，核对用户身份后，将用户当前车辆的车牌号与用户已有的卡券关联，然后以该车牌号及其关联的卡券重复上述下单步骤完成下单，再次下单时，则可直接选卡下单，通过上述步骤可以使家庭内多车可使用同一张卡券，为一人或一家多车的用户提供了便利。

在另一实施例中，生成服务订单之后还包括：

将服务订单发送给用户及服务人员；

当服务完成后，将订单完成信息发送给用户，订单完成信息包括卡券内剩余的服务项目及次数。

生成服务订单后，将服务订单发送给用户和服务人员，既能方便用户查看，又能使服务人员及时做好服务准备，当服务完成后，将订单完成信息发送给用户，便于用户查看卡券内剩余的服务项目及次数，使用户的每次消费可查询、有记录。

应理解，在本发明的上述各实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

本发明还提供了一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如上述任一项实施例中的方法。

如图3所示，基于同一发明构思，本发明实施例还提供一种服务器200，包括接收模块21、判断模块22、处理模块23、验证模块24及发送模块25。

接收模块21，用于接收用户的卡券使用请求，卡券使用请求包括用户车牌号，及用户所选的卡券。

判断模块22，用于判断车牌号与卡券是否在预存的关联数据库内。

处理模块23，用于将卡券内用户选择的服务项目次数减一，并生成服务订单。

验证模块24，用于当用户车辆到达洗车场所时，验证车辆的车牌号是否与服务订单内的车牌号相同。

发送模块25，用于将验证通过的服务订单信息发送给服务人员，以便服务人员根据服务订单信息为车辆进行对应的服务。

本发明服务器，通过接收模块21，接收用户在用户端发起的卡券使用请求，通过判断模块22判断卡券使用请求中的车牌号与卡券是否在预存的关联数据库内，若判断结果为是，则处理模块23将卡券内用户选择的服务项目次数减一，并生成服务订单，当用户车辆到达洗车场所时，验证模块24验证车辆的车牌号是否与服务服务订单内的车牌号相同，若验证结果为是，则发送模块25将验证通过的服务订单信息发送给服务人员的服务端，以便服务人员根据服务订单信息为车辆进行对应的服务。本发明可以供用户线上采用卡券快速下单，简化下单流程，同时线下对用户车辆进行验证，以确保持有卡券用户的权益，避免冒用。

可选的，在另一实施例中，接收模块21，还用于接收用户的登录请求，为用户建立账号。

存储模块，用于将用户输入的车牌号和手机号信息存储于账号内。

判断模块，用于当接收用户的卡券使用请求时，判断用户的账号下是否存在卡券。

显示模块，用于显示卡券以供用户选择。

在用户端上提供下单页面，方便用户选择卡券及服务项目。

可选的，在另一实施例中，服务器200还包括第一关联模块，用于在售出卡券时，将卡券与用户车牌号关联，并存储于关联数据库内。

可选的，在另一实施例中，服务器200还包括第二关联模块，用于在验证车辆的车牌号与服务订单内的车牌号不同时，将车辆的车牌号与用户已有的卡券关联。

如图4所示，本发明实施例还提供一种快速下单及验证系统，包括用户端300、服务端400及服务器200。

用户端300，用于供用户发起卡券使用请求，卡券使用请求包括用户车牌号，及用户所选的卡券。

服务器200如上述实施例所述，不再赘述。

服务端400，用于接收服务器发送的服务订单信息，服务人员根据服务端400接收的服务订单信息，为用户提供相应的服务。

本发明提供的一种快速下单及验证方法、服务器及系统，根据用户的卡券使用请求，判断用户车牌号与所选的卡券是否在预存的关联数据库内，若是，则说明该车牌号已绑定有卡券，以该卡券下单，实现用户在线选卡快速下单，简化下单流程，减少用户操作步骤，提高用户使用好感度。生成服务订单后，当用户车辆到达线下洗车场所时，验证车牌号是否与服务订单内的车牌号相同，若是，则说明线上下单与线下要求服务的车辆一致，则将验证通过的服务订单信息发送给服务人员，以便服务人员对该车辆进行服务，线下验证车牌号的有效性，既能保证持有卡券的用户权益不会被冒用，同时无需用户在现场进行身份验证，解决了用户在地下停车场无信号的情况下验证手机号或其它信息导致收不到验证码的问题。

读者应理解，在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

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

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (10)

1.一种快速下单及验证方法，其特征在于，包括：

接收用户的卡券使用请求，所述卡券使用请求包括用户车牌号，及用户所选的卡券；

判断所述车牌号与所述卡券是否在预存的关联数据库内；

若是，则将所述卡券内用户选择的服务项目次数减一，并生成服务订单；

当用户车辆到达洗车场所时，验证所述车辆的车牌号是否与所述服务订单内的车牌号相同；

若是，则将验证通过的服务订单信息发送给服务人员，以便所述服务人员根据所述服务订单信息为所述车辆进行对应的服务。

2.根据权利要求1所述的快速下单及验证方法，其特征在于，接收用户的卡券使用请求之前，还包括：

接收用户的登录请求，为用户建立账号；

将用户输入的车牌号和手机号信息存储于所述账号内；

当接收用户的卡券使用请求时，判断用户的账号下是否存在卡券；

若是，显示所述卡券以供用户选择。

3.根据权利要求1所述的快速下单及验证方法，其特征在于，判断所述车牌号与所述卡券是否在预存的关联数据库内之前，在售出卡券时，将所述卡券与用户车牌号关联，并存储于所述关联数据库内。

4.根据权利要求1所述的快速下单及验证方法，其特征在于，验证所述车辆的车牌号是否与所述服务订单内的车牌号相同；

若否，则将所述车辆的车牌号与用户已有的卡券关联；

以所述车牌号及其关联的所述卡券重复上述下单步骤。

5.根据权利要求1所述的快速下单及验证方法，其特征在于，生成服务订单之后还包括：

将所述服务订单发送给用户及服务人员；

当服务完成后，将订单完成信息发送给用户，所述订单完成信息包括所述卡券内剩余的服务项目及次数。

6.一种服务器，其特征在于，包括：

接收模块，用于接收用户的卡券使用请求，所述卡券使用请求包括用户车牌号，及用户所选的卡券；

判断模块，用于判断所述车牌号与所述卡券是否在预存的关联数据库内；

处理模块，用于将所述卡券内用户选择的服务项目次数减一，并生成服务订单；

验证模块，用于当用户车辆到达洗车场所时，验证所述车辆的车牌号是否与所述服务订单内的车牌号相同；

发送模块，用于将验证通过的服务订单信息发送给服务人员，以便所述服务人员根据所述服务订单信息为所述车辆进行对应的服务。

7.根据权利要求6所述的服务器，其特征在于，

所述接收模块，还用于接收用户的登录请求，为用户建立账号；

存储模块，用于将用户输入的车牌号和手机号信息存储于所述账号内；

所述判断模块，用于当接收用户的卡券使用请求时，判断用户的账号下是否存在卡券；

显示模块，用于显示所述卡券以供用户选择。

8.根据权利要求6所述的服务器，其特征在于，还包括第一关联模块，用于在售出卡券时，将所述卡券与用户车牌号关联，并存储于所述关联数据库内。

9.根据权利要求6所述的服务器，其特征在于，还包括第二关联模块，用于在验证所述车辆的车牌号与所述服务订单内的车牌号不同时，将所述车辆的车牌号与用户已有的卡券关联。

10.一种快速下单及验证系统，其特征在于，包括用户端、服务端及服务器；

所述用户端，用于供用户发起卡券使用请求，所述卡券使用请求包括用户车牌号，及用户所选的卡券；

所述服务器，用于接收用户的卡券使用请求；

判断所述车牌号与所述卡券是否在预存的关联数据库内；

若是，则将所述卡券内用户选择的服务项目次数一，并生成服务订单；

当用户车辆到达洗车场所时，验证所述车辆的车牌号是否与所述服务订单内的车牌号相同；

若是，则将验证通过的服务订单信息发送给服务人员，以便所述服务人员根据所述服务订单信息为所述车辆进行对应的服务；

所述服务端，用于接收所述服务器发送的服务订单信息。

Images