CN109584011A - 一种非机动车辆管理装置及方法 - Google Patents

Abstract

本发明公开了一种非机动车辆管理方法，用于服务器端，所述方法包括接收客户；发送的非机动车辆寄存请求；所述寄存请求包括非机动车锁车器端信息和客户端信息；判断所述客户端发送的非机动车辆寄存请求是否合法；所述判断所述客户端发送的非机动车辆寄存请求是否合法包括对非机动车锁车器端信息和客户端信息的判断；向客户端发送允许或不允许寄存非机动车辆的响应；获得在非机动车辆寄存成功后非机动车锁车器端或者客户端发送的寄存信息。本发明通过设计用于非机动车临时寄存的非机动车辆管理装置，解决了市民自有非机动车乱停乱放的问题，达到了规范管理非机动车辆的目的。

Description

一种非机动车辆管理装置及方法

技术领域

本发明涉及信息与通信领域，尤其涉及一种非机动车辆管理装置及方法。

背景技术

公共自行车的出现，对于方便人们环保出行，解决最后一公里的问题有极大正面意义。而且公共自行车系统能够规范车辆的停放，不会带来类似共享单车的乱停乱放、影响城市环境的问题。目前的公共自行车系统的停车装置仅能够停放运营商的公共自行车。

我国是自行车大国，自行车、电动车保有量非常巨大。由于城市中很少专门设置市民自有自行车、电动车的停放区域，造成了乱停乱放，影响城市美观，且有时堵塞路口，影响人们正常生活。然而市民自有非机动车辆都自带锁具，难以借外力进行管理。

发明内容

本发明的目的是解决现有技术中非机动车辆乱停放的技术问题，达到对非机动车辆进行规范管理的效果。

实现本发明目的的技术方案是提供了一种非机动车管理装置及方法。

第一方面，本发明提供了一种非机动车辆管理方法，用于服务器端，所述方法包括

接收客户端发送的非机动车辆寄存请求；所述寄存请求包括非机动车锁车器端信息和客户端信息；

判断所述客户端发送的非机动车辆寄存请求是否合法；所述判断所述客户端发送的非机动车辆寄存请求是否合法包括对非机动车锁车器端信息和客户端信息的判断；

向客户端发送允许或不允许寄存非机动车辆的响应；

获得在非机动车辆寄存成功后非机动车锁车器端或者客户端发送的寄存信息。

优选地，还包括向客户端发送非机动车辆寄存成功的提示信息。

以上技术方案主要针对市民的非机动车辆的寄存。

优选地，还包括接收客户端发送的非机动车辆取车请求；

判断所述客户端发送的非机动车辆取车请求是否合法；所述判断所述客户端发送的非机动车辆取车请求是否合法包括对非机动车锁车器端信息和客户端信息的判断；

向客户端发送允许或不允许取车的响应；

获得在非机动车辆取车成功后非机动车锁车器端或者客户端发送的取车信息。

优选地，还包括向客户端发送非机动车辆取车成功的提示信息。

以上技术方案主要针对市民的非机动车辆寄存后如何取车。

第二方面，在前述能够对市民非机动车辆提供寄存和取车功能的技术上，还可以用于运营商自己的公共自行车的租赁，同样用于服务器端。

技术方案为一种非机动车辆管理方法，包括

接收客户端发送的非机动车辆租车请求；所述租车请求包括非机动车锁车器端信息、客户端信息和非机动车辆信息；

判断所述客户端发送的非机动车辆租车请求是否合法；所述判断所述客户端发送的非机动车辆租车请求是否合法包括对非机动车锁车器端信息、客户端信息和非机动车辆信息的判断；

向客户端发送允许或不允许租车的响应；

接收客户端发送的生成租车订单请求；

判断是否可以生成租车订单；

向客户端发送允许或不允许生成租车订单的响应；

获得在非机动车辆租车成功后非机动车锁车器端或者客户端发送的租车信息。

具体来说，所述判断是否可以生成租车订单包括：

判断非机动车辆类型是否可以出借；

判断客户端用户是否为合法租车用户；

判断非机动车辆状态是否可以出借。

作为优选，还包括向客户端发送非机动车辆租车成功的提示信息。

还车方法则为包括获得在非机动车辆还车成功后非机动车锁车器端或者客户端发送的还车记录；

向客户端发送非机动车辆还车成功的提示信息。

第三方面，提供一种能够对市民非机动车辆提供寄存服务的非机动车辆管理装置，用于服务器端，包括

第一接收模块；用于接收客户端发送的非机动车辆寄存请求；所述寄存请求包括非机动车锁车器端信息和客户端信息；

第一判断模块；用于判断所述客户端发送的非机动车辆寄存请求是否合法；所述判断所述客户端发送的非机动车辆寄存请求是否合法包括对非机动车锁车器端信息和客户端信息的判断；

第一发送模块；用于向客户端发送允许或不允许寄存非机动车辆的响应；

第一获得模块；用于获得在非机动车辆寄存成功后非机动车锁车器端或者客户端发送的寄存信息。

第四方面，提供一种非机动车辆管理装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，用于服务器端，所述处理器执行所述程序时实现以下步骤：

接收客户端发送的非机动车辆寄存请求；所述寄存请求包括非机动车锁车器端信息和客户端信息；

判断所述客户端发送的非机动车辆寄存请求是否合法；所述判断所述客户端发送的非机动车辆寄存请求是否合法包括对非机动车锁车器端信息和客户端信息的判断；

向客户端发送允许或不允许寄存非机动车辆的响应；

获得在非机动车辆寄存成功后非机动车锁车器端或者客户端发送的寄存信息。

采用了上述技术方案后，本发明具有以下的积极的效果：

本发明通过设计用于非机动车临时寄存的非机动车辆管理装置，解决了市民自有非机动车乱停乱放的问题，达到了规范管理非机动车辆的目的。当这种装置设置在现有的公共自行车管理系统中时，更是方便了部署。

附图说明

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

图1为本发明的装置一个实施例的结构框架图。

图2为本发明的装置另一个实施例的结构框架图。

图3为本发明的装置另一个实施例的结构框架图。

图4为本发明的装置另一个实施例的结构框架图。

图5为本发明的方法在寄存场景下的流程图。

图6为本发明的方法在寄存车辆取车场景下的流程图。

图7为本发明的方法在租车场景下的流程图。

图8为本发明的方法在还车场景下的流程图。

具体实施方式

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

本发明提供了一种，用于解决现有技术中，为了解决上述问题，本发明的总体思路如下：

一种非机动车辆管理方法，用于服务器端，所述方法包括

接收客户端发送的非机动车辆寄存请求；所述寄存请求包括非机动车锁车器端信息和客户端信息；

判断所述客户端发送的非机动车辆寄存请求是否合法；所述判断所述客户端发送的非机动车辆寄存请求是否合法包括对非机动车锁车器端信息和客户端信息的判断；

向客户端发送允许或不允许寄存非机动车辆的响应；

获得在非机动车辆寄存成功后非机动车锁车器端或者客户端发送的寄存信息。

向客户端发送非机动车辆寄存成功的提示信息。

接收客户端发送的非机动车辆取车请求；

判断所述客户端发送的非机动车辆取车请求是否合法；所述判断所述客户端发送的非机动车辆取车请求是否合法包括对非机动车锁车器端信息和客户端信息的判断；

向客户端发送允许或不允许取车的响应；

获得在非机动车辆取车成功后非机动车锁车器端或者客户端发送的取车信息。

向客户端发送非机动车辆取车成功的提示信息。

通过设计一种能够用于非机动车临时寄存的非机动车辆管理装置，解决了市民自有非机动车乱停乱放的问题，达到了规范管理非机动车辆的目的。

首先需要说明的是，在本发明各个实施例中，所涉及的术语为：

客户端：能够安装运营商APP或者能够提供扫码功能或者能够有键盘输入功能的智能设备，具有蓝牙通信和远程通信模块，能够与非机动车锁车器蓝牙通信，并能与服务器端远程通信。

非机动车锁车器端：具有运算、传输能力的锁定非机动车辆的锁车器，一般可以固定在地面。它至少具有：锁具、锁具电机、锁具电机驱动电路、MCU微控制器、蓝牙模块(用于与客户端以及车辆上的智能锁通信)、GPRS模块(用于与服务器端通信)、锁具检测电路、车辆停放到位检测电路。当车辆推入非机动车锁车器后，能够通过比如霍尔元件等方式判断车辆是否已推到合适的位置，当锁具进行锁定动作时，能够通过比如光耦等方式判断锁具是否闭合到位。MCU微控制器用于前述部件的控制。

服务器端：运营商远程的服务器或者云服务器，作为总控中心。

社会车辆：市民自有非机动车，由市民自己保有，其上不设置能够被运营商读取身份信息的智能锁和电子车卡。

社会车辆编号：市民自有非机动车的编号(如自行车或者电动车的车牌号，若没有车牌号也可以在进行用户注册时为自己的车请求给与一编号)，各个编号唯一，用于身份区分。

运营商车辆：提供本发明的非机动车管理装置的运营商自己经营或者允许在其提供的装置上进行租赁的公共自行车，该类公共自行车配置有智能锁和电子车卡，能与普通市民自有非机动车进行区分识别。

运营商车辆编号：每辆运营商车辆有唯一编号，用于身份区分。

非机动车锁车器编号：非机动车锁车器端可以有多个非机动车锁车器，每个锁车器有唯一编号，用于身份区分。在非机动车锁车器上一般设有二维码(粘贴、印刷等方式)，在二维码中含有非机动车锁车器编码。

用户编号：使用者通过在运营商APP或者官网或者其他途径注册成为合法用户后的唯一编号，用于身份区分。

智能锁：能够进行通信控制的锁，比如蓝牙智能锁。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。同时，下述的各个实施例中，当有判断的情况下，下一步的触发都源自上一步的判断获得正向的结果。

下面，通过几个具体的实施例对本发明的技术方案进行详细介绍和说明。

见图1，其示出了本发明一个实施例提供的非机动车辆管理装置的结构框架图，该非机动车辆管理装置可以应用于后台服务器端中，在本实施例中适用于社会车辆寄存服务。该非机动车辆管理装置，包括：

第一接收模块101，用于接收客户端发送的寄存非机动车辆请求。服务器端接收的寄存请求的方式有多种，比如由客户端APP扫描非机动车锁车器端上的二维码后，向服务器端发送寄存请求；也可以利用客户端微信公众号、微信小程序、支付宝APP，输入锁车器编号，点击“寄存车辆”按钮的方式，向服务器端发送寄存请求；且不限于前述的方式，只要是由客户端发送，由服务器端接收即可。寄存请求包括非机动车锁车器端的信息(如锁车器编号)和客户端的用户信息(如用户编号)；

第一判断模块102，用于判断客户端发送的寄存非机动车辆的请求是否合法。寄存请求是否合法的判断包括对非机动车锁车器端端信息和客户端信息的判断。若非机动车锁车器端为非正常状态，比如非机动车锁车器端损坏或非机动车锁车器端上已经停放有车辆，则判断返回值为不允许；若客户端用户为非正常状态，比如用户没有寄存权限(用户因失信列入寄存黑名单等)、或用户不合法(没有注册相关账户等)或用户已经有车辆寄存(比如在服务器端中设定一个用户名下只允许寄存一辆非机动车辆时，则发现用户已经有车辆寄存的就判定用户不合法，这样可以避免一人占据过多公共资源)，则判断返回值为不允许；当锁车器和用户状态都为正常，则判断返回值为允许，在此的判断是与运算模式，任何一个不正常都代表请求不合法，都得到不允许的判断返回值。

第一发送模块103，用于向客户端发送允许或不允许寄存非机动车的响应；将第一判断模块102的判断返回值(允许或不允许)返回给客户端。

第一获得模块201，用于获得在车辆寄存成功后锁车器或者客户端发送的寄存信息；有两种方式可以获得寄存信息，第一种寄存信息通过非机动车锁车器自带的GPRS模块上传；第二种则是通过客户端上传；寄存信息包括：存车时间、用户编号、非机动车锁车器编号，社会车辆编号中的至少一种，当然全部包含为最佳。

作为可选的，非机动车辆管理装置还包括：

第一提示模块301，用于向客户端发送车辆寄存成功的提示信息。

见图5，本实施例构建了非机动车辆管理系统，系统包括客户端、非机动车锁车端和服务器端，前述图1的非机动车辆管理装置就用于服务器端。非机动车辆管理系统，系统包括客户端、非机动车锁车端和服务器端三者之间进行信息的交互和处理。

图5清楚地展示了在社会车辆寄存的场景下非机动车辆管理系统，系统包括客户端、非机动车锁车端和服务器端的控制方法：

非机动车锁车器端的各非机动车锁车器通过蓝牙播放广播，广播内容至少包括非机动车锁车器编码，还可以包括该非机动车锁车器上是否停放有车以及所停车辆的类型(社会车辆还是运营商车辆，运营商车辆则表明可以出租)。

首先客户端发送寄存请求，服务器端接收前述寄存请求；比如用户在其手机上安装了运营商的APP，并在APP上注册账号，成为合法的寄存用户，服务器端中存储用户的编号信息(注册时填的相关信息结合服务器端给与用户的ID信息)。当他需要对自己的一辆自行车进行寄存时，将自行车骑至非机动车锁车器附近，打开APP后，扫描一未停放有自行车的非机动车锁车器上的二维码，则建立起手机与非机动车锁车器蓝牙的一对一连接，得到该非机动车锁车器的编码以及锁车器上无车的信息，然后借由他的手机的网络链接到远程云服务器，向服务器发送寄存请求。寄存请求包括非机动车锁车器编号和用户编号信息。

服务器端进行寄存请求判断；服务器端会进行非机动车锁车器是否正常以及用户是否正常的判断。在前述场景下，该用户为合法注册的用户，若其信用良好，未被列入黑名单，则用户判断为正常。若非机动车锁车器未损坏(服务器端中无该锁车器损坏的记录)，且非机动车锁车器上未停放非机动车(前述场景中，用户是扫描的无车的锁车器，但服务器端仍需进行判断，避免出现虽然锁车器上无车，但服务器端的记录停放有车的情况)，则服务器端判断允许寄存。

服务器端向客户端返回允许或者不允许寄存的响应，用户手机上显示允许寄存或者下一步操作提示等，告知用户得到了系统的允许。

车辆进锁，用户将自有社会车辆推入非机动车锁车器中。

检测车辆是否到位，非机动车锁车器通过比如霍尔元件进行车辆是否推到要求的位置，如果霍尔检测结果为否，会提示请调整非机动车位置。

MCU模块判断车辆是否可以寄存，在此，非机动车锁车器的MCU微控制器判断推入的车是否是允许寄存的社会车辆。逻辑关系为：运营商车辆不允许寄存，只允许租赁。社会车辆才可以寄存。判断方式有多种，比如，能否读取到自行车车卡信息，是否读取到智能锁信息等，如果读取不到，则表明是社会车辆，否则表明是运营商车辆。

作为可选的方案，非机动车锁车器端发送“是否确认寄存”的请求给客户端，在进行了前述多步判断后，已经可以确定用户可以寄存，在此发确认信息给客户端，由客户再次进行确认，避免误操作。

客户端向非机动车锁车器端发送“确认寄存”。当然“是否确认寄存”以及“确认寄存”这两步也可以省略，能够减少运算量。

非机动车锁车器锁具驱动电路启动，驱动锁具电机，使锁具关锁。

非机动车锁车器通过比如光耦检测锁具是否锁定到位。

非机动车锁车器向客户端发送寄存成功的提示信息，用户手机上将显示比如“成功寄存”之类的指示信息；非机动车锁车器通过自带的GPRS模块向服务器端发送寄存信息，所述寄存信息包括：存车时间、用户编号、锁车器编号，社会车辆编号中的至少一种，当然全部包含为最佳。

或者非机动车锁车器向客户端发送寄存成功的提示信息，用户手机上将显示比如“成功寄存”之类的指示信息；然后由客户端用其自带的通信模块向服务器端发送寄存信息，所述寄存信息包括：存车时间、用户编号、锁车器编号，社会车辆编号中的至少一种，当然全部包含为最佳，这样的方法可以节省运营商的数据流量，更进一步充分利用社会资源。

也可以是由非机动车锁车器通过自带的GPRS模块向服务器端发送寄存信息后，由服务器端向客户端发送寄存成功的提示信息。

也就是说，可以根据具体情况，选择非机动车锁车器端、客户端以及服务器端三端互通的方式。

请参考图2，其示出了本发明一个实施例提供的非机动车辆管理装置的结构框架图，该非机动车辆管理装置可以应用于后台服务器端中，在本实施例中适用于社会车辆取车服务。该非机动车辆管理装置，包括：

第一接收模块101，用于接收客户端发送的取车请求；用户在客户端APP或微信公众号、微信小程序、支付宝上点击“取车”按钮，并将取车请求发送至服务器端。需要注意的是，在本实施例中，与图1的第一接收模块101功能竞合，由同一个模块接收来自客户端的寄存/取车请求；当然，也可以是各自独立的两个接收模块，分别接收来自客户端的寄存以及取车请求。

第一判断模块102，用于判断客户端发送的取车请求是否合法；取车请求是否合法包括对非机动车锁车器端信息和客户端信息的判断。若非机动车锁车器为非正常状态(比如锁车器损坏或锁车器上没有车)，则判断返回值为不允许；若用户为非正常状态，比如用户没有取车权限(未注册用户账号等)或用户不合法(如列入黑名单等)或用户没有车辆寄存，则判断返回值为不允许；如非机动车锁车器和用户状态都为正常，则判断返回值为允许；同样的，在本实施例中，与图1的第一判断模块102，由同一个模块判断来自客户端的寄存/取车请求；当然，也可以是各自独立的两个判断模块，分别判断来自客户端的寄存以及取车请求。

第一发送模块103，用于向客户端发送允许或不允许取车的响应；将第一判断模块102的判断返回值(允许或不允许)返回给客户端；同样的，在本实施例中，与图1的第一发送模块103，由同一个模块向客户端发送允许或不允许寄存/取车请求；当然，也可以是各自独立的两个发送模块，分别向客户端发送允许或不允许寄存和取车请求。

第一获得模块201，用于接收在取车成功后非机动车锁车器或者客户端发送的取车信息；一种方式是取车信息通过锁车器自带的GPRS模块上传；或者非机动车锁车器发送取车成功的提示信息给客户端，客户端由其自带远程通信模块发给服务器端；取车信息包括：取车时间、用户编号、锁车器编号，社会车辆编号中的至少一种，当然全部包含为最佳。同样的，在本实施例中，与图1的第一获得模块201，由同一个模块接收寄存/取车成功后非机动车锁车器或者客户端向客户端发送的信息；当然，也可以是各自独立的两个获得模块，分别获得来自非机动车锁车器或者客户端的寄存成功和取车成功的信息。

作为可选的，非机动车辆管理装置还包括：

第一提示模块301，用于向客户端发送取车成功的提示信息。同样的，在本实施例中，与图1的第一提示模块301，由同一个模块向客户端发送提示信息；当然，也可以是各自独立的两个提示模块，分别提示寄存成功和取车成功的信息。

见图6，本实施例构建了非机动车辆管理系统，系统包括客户端、非机动车锁车端和服务器端，前述图2的非机动车辆管理装置就用于服务器端。非机动车辆管理系统，系统包括客户端、非机动车锁车端和服务器端三者之间进行信息的交互和处理。

图6清楚地展示了在社会车辆寄存后取车的场景下非机动车辆管理系统，系统包括客户端、非机动车锁车端和服务器端的控制方法，在下述详细举例阐述中，用户为前述图5阐述中寄存有社会车辆的用户：

同样的，非机动车锁车器端的各非机动车锁车器通过蓝牙播放广播，广播内容至少包括非机动车锁车器编码，还可以包括该非机动车锁车器上是否停放有车以及所停车辆的类型(社会车辆还是运营商车辆，运营商车辆则表明可以出租)。

首先客户端发送取车请求，服务器端接收前述取车请求；当用户需要取走自己寄存的自行车时，可来到非机动车锁车器附近，打开APP后，点击诸如“取车”界面，由此借由他的手机的网络链接到远程云服务器，向服务器发送取车请求。

或者用户直接找到停放有自己寄存的自行车的非机动车锁车器前，在客户端APP或微信公众号、微信小程序、支付宝上扫描非机动锁车器上的二维码，建立起手机与非机动车锁车器蓝牙的一对一连接，得到该非机动车锁车器的编码以及锁车器上有社会车辆的信息，然后借由他的手机的网络链接到远程云服务器，向服务器发送取车请求。取车请求包括非机动车锁车器编号和用户编号信息。

服务器端进行取车请求判断；服务器端会进行非机动车锁车器是否正常以及用户是否正常的判断。在前述场景下，该用户为合法注册的用户，若其信用良好，未被列入黑名单，且确实有寄存车辆的记录，则用户判断为正常。若非机动车锁车器未损坏(服务器中无该锁车器损坏的记录)，且非机动车锁车器上确有停放非机动车，则服务器端判断允许取车。当然还可以在此提供寄存车辆位置的查询，针对用户不是在自己寄存车辆的锁车器上扫码的情况，而是在APP中点击取车时，服务器进行搜索后，在其手机上展示出其寄存车辆的位置和导航路线，这对于现实生活中，难找车的情况的解决将非常有益。

服务器端向客户端返回允许或者不允许取车的响应，用户手机上显示允许取车或者下一步操作提示等，告知用户得到了系统的允许。

客户端通过蓝牙向非机动车锁车器发送开锁指令。

非机动车锁车器尝试读取车卡，若未得到响应，则判断该锁车器上停放的车辆为社会车辆，否则为运营商车辆，不允许取走。

MCU模块判断车辆是否可以取车，逻辑关系为：取车用户与非机动车锁车器中存储的该车的寄存信息中的寄存用户是否为同一人。

若可以取车，非机动车锁车器执行开锁，非机动车锁车器采用比如光耦的方式检测锁具是否打开到位。

非机动车锁车器向客户端发送取车成功的提示信息，用户手机上将显示比如“成功取车”之类的指示信息；非机动车锁车器通过自带的GPRS模块向服务器端发送取车信息，所述取车信息包括：取车时间、用户编号、锁车器编号，社会车辆编号中的至少一种，当然全部包含为最佳。

或者非机动车锁车器向客户端发送取车成功的提示信息，用户手机上将显示比如“成功取车”之类的指示信息；然后由客户端用其自带的通信模块向服务器端发送取车信息，所述取车信息包括：取车时间、用户编号、锁车器编号，社会车辆编号中的至少一种，当然全部包含为最佳，这样的方法可以节省运营商的数据流量，更进一步充分利用社会资源。

也可以是由非机动车锁车器通过自带的GPRS模块向服务器端发送取车信息后，由服务器端向客户端发送取车成功的提示信息。

请参考图3，其示出了本发明一个实施例提供的非机动车辆管理装置的结构框架图，该非机动车辆管理装置可以应用于后台服务器中，在本实施例中适用于运营商车辆的租赁服务。该非机动车辆管理装置，包括：

第一接收模块101，用于接收客户端发送的租车请求；所述租车请求包括非机动车锁车器端信息、客户端信息和非机动车辆信息；服务器端接收的租车请求的方式有多种，比如由客户端APP扫描非机动车锁车器端上的二维码后，向服务器发送租车请求；也可以利用客户端微信公众号、微信小程序、支付宝APP，输入锁车器编号，点击“租车”按钮的方式，向服务器发送寄存请求；且不限于前述的方式，只要是由客户端发送，由服务器接收即可。租车请求包括非机动车锁车器端的信息(如锁车器编号)、客户端的用户信息(如用户编号)和车辆信息(如车辆编号)。需要注意的是，在本实施例中，与图1以及图2的第一接收模块101功能竞合，由同一个模块接收来自客户端的寄存/取车/租车请求；当然，也可以是各自独立的三个接收模块，分别接收来自客户端的寄存、取车以及租车请求。

第一判断模块102，用于判断客户端发送的租车请求是否合法；所述判断所述客户端发送的非机动车辆租车请求是否合法包括对非机动车锁车器端信息、客户端信息和非机动车辆信息的判断；若非机动车锁车器为非正常状态(比如锁车器损坏或锁车器上没有车)，则判断返回值为不允许；若用户为非正常状态，比如用户没有取车权限(未注册用户账号等)或用户不合法(如列入黑名单等)或用户已经租车还未还车，则判断返回值为不允许；如非机动车锁车器和用户状态都为正常，则判断返回值为允许；同样的，在本实施例中，与图1和图2的第一判断模块102，由同一个模块判断来自客户端的寄存/取车/租车请求；当然，也可以是各自独立的三个判断模块，分别判断来自客户端的寄存、取车以及租车请求。

第一发送模块103，用于向客户端发送允许或不允许租车的响应；将第一判断模块102的判断返回值(允许或不允许)返回给客户端；同样的，在本实施例中，与图1和图2的第一发送模块103，由同一个模块向客户端发送允许或不允许寄存/取车/租车请求；当然，也可以是各自独立的三个发送模块，分别向客户端发送允许或不允许寄存、取车和租车请求。

第二接收模块104，用于接收客户端发送的生成租车订单请求；客户端接收到非机动车锁车器的蓝牙广播，得到非机动车锁车器允许借车的响应，向服务器请求生成租车订单。

第二判断模块105，用于判断是否可以生成租车订单，包括：

车辆类型判断模块1051，用于判断车辆类型是否可以出借；对第二接收模块104接收到的车辆信息(如车辆编号)进行匹配后，可以获得该车辆的类型；由此可以判断该车辆类型是否可以出借；如果不能出借，则检测返回值为不允许；

用户判断模块1052，用于判断用户是否为合法租车用户；如用户为非合法用户，则判断返回值为不允许；

车辆状态判断模块1053，用于判断车辆状态是否可以出借；对第二接收模块104接收到的车辆信息(如车辆编号)进行匹配后，可以获得该车辆的状态；如果该车辆状态为非正常，则判断返回值为不允许；

第一运算模块1054，用于将第一判断模块1051、第二判断模块1052、第三判断模块1053的结果做“与运算”；只有上述三个判断模块的返回值都为允许时，第一运算模块1054返回值为允许；否则返回值为不允许；

将第一运算模块1054的返回值作为第二判断模块105的判断返回值；

第二发送模块106，用于向客户端发送允许或不允许生成租车订单的响应；将第二判断模块105的判断返回值(允许或不允许)返回给客户端；

第一获得模块201，用于接收非机动车锁车器或者客户端发送的租车信息；在租车成功之后，非机动车锁车器通过自带的GPRS模块向服务器发送租车信息，或者借由客户端上传租车信息。租车信息包括：租车时间、锁车器信息、租赁车辆信息、用户信息中的至少一种，当然全部包含为最佳。同样的，在本实施例中，与图1和图2的第一获得模块201，由同一个模块接收寄存/取车/租车成功后非机动车锁车器或者客户端向服务器端发送的信息；当然，也可以是各自独立的三个获得模块，分别获得来自非机动车锁车或者客户端器的寄存成功、取车成功、租车成功的信息。

作为可选的，非机动车辆管理装置还包括：

第一提示模块301，用于向客户端发送租车成功的提示信息；同样的，在本实施例中，与图1和图2的第一提示模块301，由同一个模块向客户端发送提示信息；当然，也可以是各自独立的三个提示模块，分别提示寄存成功、取车成功和租车成功的信息。

见图7，本实施例构建了非机动车辆管理系统，系统包括客户端、非机动车锁车端、车辆端(带智能锁)和服务器端，前述图3的非机动车辆管理装置就用于服务器端。非机动车辆管理系统，系统包括客户端、非机动车锁车端、智能锁端和服务器端四者之间进行信息的交互和处理。

图7清楚地展示了在运营商车辆租赁的场景下非机动车辆管理系统，系统包括客户端、非机动车锁车端、车辆端和服务器端的控制方法：

在本实施例中，租车前假设的场景是：用户扫描的非机动车锁车器上锁有非机动车(可以是社会车辆或者运营商车辆)，如果是运营商车辆则前一次还车时有将还车信息上传到服务器，且还车信息在车载智能锁中有存储。同样的，非机动车锁车器端的各非机动车锁车器通过蓝牙播放广播，广播内容至少包括非机动车锁车器编码，还可以包括该非机动车锁车器上是否停放有车以及所停车辆的类型(社会车辆还是运营商车辆，运营商车辆则表明可以出租)。

首先客户端发送租车请求，服务器端接收前述租车请求；租车请求包括非机动车锁车器端信息、客户端信息和非机动车辆信息；比如用户在其手机上安装了运营商的APP，并在APP上注册账号，成为合法的租车用户，服务器中存储用户的编号信息(注册时填的相关信息结合服务器给与用户的ID信息)。当他需要租车时，来到非机动车锁车器附近，打开APP后，扫描一停放有自行车的非机动车锁车器上的二维码，建立起手机与非机动车锁车器蓝牙的一对一连接，得到该非机动车锁车器的编码以及锁车器上有运营商车辆的信息，然后借由他的手机的网络链接到远程云服务器，向服务器发送租车请求。

服务器端进行租车请求判断；服务器会进行非机动车锁车器是否正常、用户是否正常、车辆是否正常的判断。在前述场景下，该用户为合法注册的用户，若其信用良好，未被列入黑名单，则用户判断为正常。若非机动车锁车器为非正常状态(比如锁车器损坏或锁车器上没有车)，则判断返回值为不允许。若车辆为非正常状态(如车辆损坏有报损记录，如检测不到智能锁等，都视为车辆为非正常状态)，则判断返回值为不允许。

服务器端向客户端返回允许或者不允许租车的响应，用户手机上显示允许租车或者下一步操作提示等，告知用户得到了系统的允许。

为了能够让用户的蓝牙迅速接收信息，当运营商车辆归还到非机动车锁车器上后，非机动车锁车器主动不间断地进行蓝牙广播，播放可以租车的消息。此动作对于与服务器通信出现故障或者服务器数据缺失的情况能起到辅助的效果。

客户端接收到非机动车锁车器的蓝牙广播，获取非机动锁车器及车辆信息，并得到非机动车锁车器允许借车的响应，向服务器请求生成租车订单。

服务器收到租车订单请求后，进行租车订单判断。在此进行三次判断，分别是第一次判断(车辆类型判断)、第二次判断(用户合法性判断)和第三次判断(车辆状态判断)，将三次判断的结果做“与运算”；只有上述三个判断的返回值都为允许时，才判断允许生成订单；否则返回值为不允许。

服务器端向客户端返回允许或不允许生成订单的响应。客户端向非机动车锁车器发送开锁指令。

非机动车锁车器判断智能锁状态是否正常及是否为该车辆本身。进行此次判断的目的是进一步进行信息匹配和确认，考虑到的场景为：借车还车可能不在同一个位置，因此借车信息存储于车载智能锁能确保有最新的信息，而服务器中的信息可能不是最新信息，因此通过此次判断以确定智能锁的状态(是否损坏)，以及车辆的最近一次租赁状态。

若可以租车，非机动车锁车器执行开锁，非机动车锁车器采用比如光耦的方式检测锁具是否打开到位。用户将车辆从非机动车锁车器中推出，非机动车锁车器采用比如霍尔元件的方式检测车辆是否出车到位。

非机动车锁车器向客户端发送租车成功的提示信息，用户手机上将显示比如“成功租车”之类的指示信息。

非机动车锁车器生成租车记录，并向智能锁发送本次租车订单记录。所述租车订单记录包括：租车时间、锁车器信息、租赁车辆信息、用户信息。

非机动车锁车器发送租车成功的提示信息给客户端，客户端上传租车信息给服务器。

或者非机动车锁车器发送租车成功的提示信息给客户端，同时通过自带的GPRS模块向服务器端发送租车信息。

再或者，非机动车锁车器通过自带的GPRS模块向服务器端发送租车信息，服务器算发送租车成功信息给客户端。

所述租车信息包括：租车时间、锁车器信息、租赁车辆信息、用户信息中的至少一种，当然全部包含为最佳。

请参考图4，其示出了本发明一个实施例提供的非机动车辆管理装置的结构框架图，该非机动车辆管理装置可以应用于后台服务器中，在本实施例中适用于运营商车辆的租车后的还车服务。该非机动车辆管理装置，包括：

第一获得模块201，用于接收非机动车锁车器或者客户端发送的还车记录；还车记录包括还车时间、锁车器信息(如锁车器编号)、车辆信息(如车辆编号)、用户信息(如用户编号)；同样的，在本实施例中，与图1、图2和图3的第一获得模块201，由同一个模块接收寄存/取车/租车/还车成功后非机动车锁车器或者客户端向客户端发送的信息；当然，也可以是各自独立的四个获得模块，分别获得来自非机动车锁车器或者客户端的寄存成功、取车成功、租车成功、还车成功的信息。

第一提示模块301，用于还车成功后向客户端发送还车成功的提示信息。同样的，在本实施例中，与图1、图2和图3的第一提示模块301，由同一个模块向客户端发送提示信息；当然，也可以是各自独立的四个提示模块，分别提示寄存成功、取车成功、租车成功以及还车成功的信息。

见图8，本实施例构建了非机动车辆管理系统，系统包括客户端、非机动车锁车端、车辆端(含智能锁)和服务器端，前述图4的非机动车辆管理装置就用于服务器端。非机动车辆管理系统，系统包括客户端、非机动车锁车端、智能锁端和服务器端四者之间进行信息的交互和处理。

图8清楚地展示了在运营商车辆租赁的还车场景下非机动车辆管理系统，系统包括客户端、非机动车锁车器端、车辆端和服务器端的控制方法：

车辆进锁，用户将运营商车辆推入非机动车锁车器中。

非机动车锁车器检测车辆是否到位，非机动车锁车器通过比如霍尔元件进行车辆是否推到要求的位置，如果霍尔检测结果为否，会提示请调整非机动车位置。

非机动车锁车器尝试读取车卡，能够读取车卡信息，则表明是运营商车辆，将该车辆信息返回给非机动车锁车器，若未得到响应，则判断该锁车器上停放的车辆为社会车辆。

MCU模块判断车辆是否可以还车，逻辑关系为：运营商车辆可以还，社会车辆不允许还。

非机动车锁车器执行关锁，锁具驱动电路启动，驱动锁具电机，使锁具关锁。

非机动车锁车器通过比如光耦检测锁具是否锁定到位。锁具未到位则循环锁车操作。

非机动车锁车器连接智能锁，获取前次借车的租车记录。

智能锁将租车记录发送给非机动车锁车器。

非机动车锁车器生成还车记录、存储还车记录，同时更新广播报文。

非机动车锁车器返回还车成功信息给客户端，由客户端发送还车纪录给服务器。

或者由非机动车锁车器通过自带的GPRS将还车记录发送给服务器，服务器返回还车成功信息给客户端。

或者非机动车锁车器返回还车成功信息给客户端，非机动锁车器将发送还车纪录给服务器。

在本发明的构思下，前述四种非机动车辆管理装置分别实现寄存、取车、租车、还车的功能，当作为一个提供四项功能的非机动车辆管理系统时，这四项功能可以分别独立存在，在客户端设定不同的入口。当然，为了更好的用户体验，可以按照图3的装置结进行部署，第一接收模块接收四项请求，在实际使用中，可以在服务器接收信号之前，就进行是社会车辆寄存取车场景还是运营商车辆租赁场景，根据不同的场景进入不同的功能流程。

基于与上述装置和方法同样的发明构思，本发明还提供一种非机动车辆管理装置，设置在服务器中，其上存储有计算机程序，该程序被处理器执行时实现前文所述的非机动车辆管理方法中的任一方法的步骤。

其中，采用总线架构，总线可以包括任意数量的互联的总线和桥，总线将包括由处理器代表的一个或多个处理器和存储器代表的存储器的各种电路链接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和接收器和发送器之间提供接口。接收器和发送器可以是同一个元件，即收发机，提供用于在传输介质上与各种其他装置通信的单元。

处理器负责管理总线和通常的处理，而存储器可以被用于存储处理器302在执行操作时所使用的数据。

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

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

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

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

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种非机动车辆管理方法，其特征在于：用于服务器端，所述方法包括

接收客户端发送的非机动车辆寄存请求；所述寄存请求包括非机动车锁车器端信息和客户端信息；

判断所述客户端发送的非机动车辆寄存请求是否合法；所述判断所述客户端发送的非机动车辆寄存请求是否合法包括对非机动车锁车器端信息和客户端信息的判断；

向客户端发送允许或不允许寄存非机动车辆的响应；

获得在非机动车辆寄存成功后非机动车锁车器端或者客户端发送的寄存信息。

2.根据权利要求1所述的一种非机动车辆管理方法，其特征在于：还包括

向客户端发送非机动车辆寄存成功的提示信息。

3.根据权利要求1所述的一种非机动车辆管理方法，其特征在于：还包括

接收客户端发送的非机动车辆取车请求；

判断所述客户端发送的非机动车辆取车请求是否合法；所述判断所述客户端发送的非机动车辆取车请求是否合法包括对非机动车锁车器端信息和客户端信息的判断；

向客户端发送允许或不允许取车的响应；

获得在非机动车辆取车成功后非机动车锁车器端或者客户端发送的取车信息。

4.根据权利要求3所述的一种非机动车辆管理方法，其特征在于：还包括

向客户端发送非机动车辆取车成功的提示信息。

5.根据权利要求1所述的一种非机动车辆管理方法，其特征在于：还包括

接收客户端发送的非机动车辆租车请求；所述租车请求包括非机动车锁车器端信息、客户端信息和非机动车辆信息；

判断所述客户端发送的非机动车辆租车请求是否合法；所述判断所述客户端发送的非机动车辆租车请求是否合法包括对非机动车锁车器端信息、客户端信息和非机动车辆信息的判断；

向客户端发送允许或不允许租车的响应；

接收客户端发送的生成租车订单请求；

判断是否可以生成租车订单；

向客户端发送允许或不允许生成租车订单的响应；

获得在非机动车辆租车成功后非机动车锁车器端或者客户端发送的租车信息。

6.根据权利要求5所述的一种非机动车辆管理方法，其特征在于：所述判断是否可以生成租车订单包括：

判断非机动车辆类型是否可以出借；

判断客户端用户是否为合法租车用户；

判断非机动车辆状态是否可以出借。

7.根据权利要求5所述的一种非机动车辆管理方法，其特征在于：还包括

向客户端发送非机动车辆租车成功的提示信息。

8.根据权利要求5所述的一种非机动车辆管理方法，其特征在于：还包括

获得在非机动车辆还车成功后非机动车锁车器端或者客户端发送的还车记录；

向客户端发送非机动车辆还车成功的提示信息。

9.一种非机动车辆管理装置，其特征在于：用于服务器端，包括

第一接收模块；用于接收客户端发送的非机动车辆寄存请求；所述寄存请求包括非机动车锁车器端信息和客户端信息；

第一判断模块；用于判断所述客户端发送的非机动车辆寄存请求是否合法；所述判断所述客户端发送的非机动车辆寄存请求是否合法包括对非机动车锁车器端信息和客户端信息的判断；

第一发送模块；用于向客户端发送允许或不允许寄存非机动车辆的响应；

第一获得模块；用于获得在非机动车辆寄存成功后非机动车锁车器或者客户端端发送的寄存信息。

10.一种非机动车辆管理装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于：用于服务器端，所述处理器执行所述程序时实现以下步骤：

接收客户端发送的非机动车辆寄存请求；所述寄存请求包括非机动车锁车器端信息和客户端信息；

判断所述客户端发送的非机动车辆寄存请求是否合法；所述判断所述客户端发送的非机动车辆寄存请求是否合法包括对非机动车锁车器端信息和客户端信息的判断；

向客户端发送允许或不允许寄存非机动车辆的响应；

获得在非机动车辆寄存成功后非机动车锁车器端或者客户端发送的寄存信息。