一种公共自行车异常还车处理方法及系统与流程

本发明涉及车辆管理技术领域，尤其涉及一种公共自行车还车处理方法及系统。

背景技术：

现代城市中各种交通工具发展迅速，但是在短距离出行问题上，还缺少有效的方法，目前主要的短距离出行方式包括：徒步行走、使用自备车辆(自行车、摩托车、汽车等)、乘坐公交车，但是徒步行走受限于个人体力和行走速度，自备车辆，受限于购买车辆的资金不、停车和防盗等问题，乘坐公交受限于公交线路的建设速度和建设成本，在这样的情况下，提供公共自行车租赁服务是解决短距离出行的有效方法之一。

公共自行车租赁系统，一般都通过中心服务器对所有租赁网点进行管理，在出发地附近的任意租赁网点借车，到目的地附近的任意租赁网点归还车辆；与其它公共交通路线的建设相比，公共自行车的租赁网点建设速度快、投入成本低，因此可以比较好地按需建设，较为及时地满足人们的短距离需要。

但是目前的公共自行车系统，用户还车时，通常需要通过网络与远程的中心服务器进行通讯，且会碰到还车异常问题，即锁车器因不明原因，就是不锁车，如设备出现故障，或者设备读取到了锁车命令但是锁车失败，用户无法自主解决锁车问题，对应的订单无法结束。

技术实现要素：

为了克服上述技术缺陷，本发明的目的在于提供一种公共自行车还车处理方法及系统，用于解决现有用户使用公共自行车，还车时出现异常情况无法锁车，导致影响用户出行或产生额外费用的问题。

本发明公开了一种公共自行车还车处理方法，应用于公共自行车，所述还车处理方法包括：

所述公共自行车进入到锁车器，执行锁车命令，若锁车失败则返回第一执行结果至后台服务器存储在异动数据库下，所述锁车器通过站点控制器连接后台服务器；

用户端反馈包含用户信息的异常还车请求至后台服务器；

后台服务器根据所述用户信息在所述异动数据库中查找，以定位所述锁车器；

采用后台服务器对所述用户信息进行信用分析，获得用户信息对应的用户信用等级；

当所述用户账户对应的用户信用等级低于预设等级，则发送包含建议用户更换锁车器的提示信息至所述用户端；

当所述用户账户对应的用户信用等级不低于预设等级，发送强制锁车命令至所述站点控制器，并由所述站点控制器控制所述锁车器执行所述强制锁车命令，并获取所述锁车器返回的第二执行结果；

所述后台服务器根据所述第二执行结果判断是否结束订单；

若成功执行关锁动作，则结束订单；若关锁动作执行失败，则发送包含建议用户更换锁车器的提示信息。

优选地，所述后台服务器对所述用户信息进行信用分析，获得用户信息对应的用户信用等级，还包括以下：

从预设数据库中根据所述用户账户获取用户信息，其中，所述用户信息包括用户历史订单数据、用户支付数据、用户轨迹数据以及关联数据中的一个或多个；

基于所述用户信息进行数据分析，并根据预设规则基于分析结果对所述用户账户进行信用评级，获得所述用户账户对应的用户信用等级。

优选地，所述基于所述用户信息进行数据分析，并根据预设规则基于分析结果对所述用户账户进行信用评级，获得所述用户账户对应的用户信用等级，包括以下步骤：

采用预训练后的数据处理模型对所述用户信息进行信用度计算，获得带有信用值的分级结果；

基于预设等级映射表获取与所述分析结果对应的信用等级，生成所述用户账户对应的用户信用等级。

优选地，所述后台服务器根据所述用户信息在所述异动数据库中查找，以定位所述锁车器，还包括：

根据用户信息获取用户位置范围和时间信息；

基于所述异动数据库查找所述时间信息下所述用户位置范围内存在异动数据的锁车器，以定位锁车器；其中，存在异动数据的锁车器包括以下：

执行超出预设次数的锁车命令；

和/或，执行重新启动并在重新启动后再次执行锁车命令。

优选地，所述站点控制器控制所述锁车器执行所述强制锁车命令，包括以下：

站点控制器接收到强制锁车命令，并发送所述强制锁车命令至所述锁车器；

判断所述公共自行车是否进入到锁车器；

若是，在则由站点控制器控制所述锁车器执行所述强制锁车命令；

若否，则送包含推动所述公共自行车进入到锁车器的提示信息，当所述锁车器监测到所述公共自行车进入所述锁车器时执行所述强制锁车命令。

优选地，所述还车处理方法还包括：

在返回执行结果后，锁车器触发用于检测硬件使用状态的自检流程，获取自检结果，并将所述自检结果发送至后台服务器；

若所述自检结果异常，则后台服务器发出带有维修数据的警示信息。

优选地，所述还车处理方法还包括：

在结束订单后，后台服务器自主生成包含所述异常还车请求的订单信息，并将所述订单信息存储在预设数据库中与所述用户账户关联的用户信息下。

本发明公开了一种公共自行车还车处理系统，所述系统包括用户端、锁车器端、站点控制器端以及后台服务器端；

所述锁车器端包括：

监测与执行模块，用于公共自行车进入所述锁车器时执行锁车命令；

第一发送模块，用于返回第一执行结果至后台服务器存储在异动数据库下；

接收与执行模块，用于接收强制锁车命令，并获取所述锁车器返回的第二执行结果；

所述用户端包括：

反馈模块，用于反馈包含用户信息的异常还车请求至后台服务器；

第一接收模块，用于接收后台服务器端发出的包含建议用户更换锁车器的提示信息；

所述后台服务器端包括：

分析模块，用于对所述用户信息进行信用分析，获得用户信息对应的用户信用等级；

第二发送模块，用于当所述用户账户对应的用户信用等级低于预设等级，则发送包含建议用户更换锁车器的提示信息至所述用户端；

第三发送模块，用于当所述用户账户对应的用户信用等级不低于预设等级，发送强制锁车命令至所述站点控制器；

接收和判断模块，用于接收站点控制器返回的第二执行结果，根据所述第二执行结果判断是否强制闭锁；

第一执行模块，用于返回的执行结果显示成功执行关锁动作，结束订单；

第二执行模块，用于返回的执行结果显示关锁动作执行失败，发送包含建议用户更换锁车器的提示信息至所述用户端；

站点控制器端包括：

处理模块，用于控制所述锁车器执行所述强制锁车命令，并在获取所述锁车器返回的执行结果后发送至所述后台服务器。

采用了上述技术方案后，与现有技术相比，具有以下有益效果：

本方案中，当锁车器锁车失败时，用户在用户移动终端操作反馈问题，后台服务器根据接收到的异常还车请求，基于锁车器异动数据对锁车器进行定位并通过站点控制器选择性地对部分信用度较高用户账户对应的锁车器进行强制锁车，以提高强制锁车的安全性，通过后台服务器操作解决锁车失败的问题，解决现有用户使用公共自行车，还车时出现异常情况无法锁车，导致影响用户出行或产生额外费用的问题，同时提高强制锁车的安全性。

附图说明

图1为本发明所述一种公共自行车还车处理方法及系统实施例一的流程图；

图2为本发明所述一种公共自行车还车处理方法及系统实施例一中用于体现述后台服务器根据所述用户信息在所述异动数据库中查找，以定位所述锁车器的流程图；

图3为本发明所述一种公共自行车还车处理方法及系统实施例一中用于体现采用后台服务器对所述用户信息进行信用分析，获得用户信息对应的用户信用等级的流程图；

图4为本发明所述一种公共自行车还车处理方法及系统实施例一中用于体现所述基于用户信息进行数据分析，并根据预设规则基于分析结果对用户账户进行信用评级，获得用户账户对应的用户信用等级流程图；

图5为本发明所述一种公共自行车还车处理方法及系统实施例一中用于体现所述由站点控制器控制锁车器执行强制锁车命令的流程图；

图6为本发明所述一种公共自行车还车处理方法及系统实施例一中用于体现在返回执行结果后的流程图；

图7为本发明所述一种公共自行车还车处理方法及系统实施例二模块示意图。

附图标记：

8-公共自行车还车处理系统；81-用户端；811-反馈模块；

812-第一接收模块；82-锁车器端；

821-监测与执行模块；822-第一发送模块；823-接收与执行模块；

83-站点控制器端；831-处理模块；84-后台服务器端；

841-分析模块；842-第二发送模块843-第三发送模块

844-接收和判断模块；845-第一执行模块；846-第二执行模块；

847-异动数据处理模块；848-警示模块；849-存储模块。

具体实施方式

以下结合附图与具体实施例进一步阐述本发明的优点。

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在本发明的描述中，需要理解的是，术语“纵向”、“横向”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。

在本发明的描述中，除非另有规定和限定，需要说明的是，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是机械连接或电连接，也可以是两个元件内部的连通，可以是直接相连，也可以通过中间媒介间接相连，对于本领域的普通技术人员而言，可以根据具体情况理解上述术语的具体含义。

实施例一：本实施例公开了一种公共自行车还车处理方法，参阅图1和图6应用于公共自行车，所述公共自行车包括但不限于普通自行车、电力自行车以及公共自行车，需要说明的是，本实施方式使用的公共自行车在还车区域设有若干固定的锁车器，每一公共自行车由用户推动进入锁车器内后执行锁车，且本方案用于解决公共自行车进入到锁车器内而锁车失败的问题，具体的，参阅图1，所述还车处理方法包括：

s100：所述公共自行车进入到锁车器，执行锁车动作，若锁车失败则返回第一执行结果至后台服务器存储在异动数据库下，所述锁车器通过站点控制器连接后台服务器；

在上述步骤中，公共自行车由用户推动进入到锁车器内，用于公共自行车的锁车区域为预设区域，在该锁车区域内包括若干锁车器，各个锁车器固定设置在锁车区域内，可间隔均匀分布，以最大效率的设置锁车器。锁车器一端用于固定在锁车区域内，另一端用于在执行锁车命令时将公共自行车锁住使该公共自行车与锁车器固定。

具体的，在本实施方式中，每一公共自行车上均设置有车卡，当公共自行车进入锁车器内时，锁车器识别该公共自行车上的唯一车卡，该唯一车卡还用于与用户端关联，锁车器上设有用于识别该类车卡的监测装置，包括但不限于射频传感器等，还可在用户端设置还车操作入口，以便解决由于车卡损坏而无法自动识别的情况。

具体的，所述公共自行车进入到锁车器，执行锁车动作，若锁车失败，则锁车器异动数据经站点控制器上传至后台服务器，存储在锁车器异动数据库下。进一步的，所述异动数据包括但不限于站点编码、锁车器编码、失败时间、锁车失败状态等信息。

s200：用户通过移动终端反馈包含用户信息的异常还车请求至后台服务器；

具体的，用户信息包含用户账户，可以是用户id，也可以是用于区别用户的其他唯一标识。用户通过移动终端反馈包含用户信息的异常还车请求至后台服务器，用户无需使用移动终端扫描锁车器二维码，只需在移动终端界面上操作。进一步的，移动终端界面上设置异常还车按键，用户只需点击一下即完成异常还车请求。

s300：后台服务器根据所述用户信息在所述异动数据库中查找，以定位所述锁车器；

具体的，所述后台服务器根据所述用户信息在所述异动数据库中查找，以定位所述锁车器，参阅图2，还包括：

s310：根据用户信息获取用户位置范围和时间信息；

具体的，通过用户手机的定位来匹配公共自行车站点的定位，即可确定锁车器的位置范围，通过用户发送还车请求的时间点来筛选锁车器异动数据的时间段，即可作为筛选条件从而能够确定锁车器，从而能够执行强制锁车。

s320：基于所述异动数据库查找所述时间信息下所述用户位置范围内存在异动数据的锁车器，以定位锁车器；

其中，具体的，存在异动数据包括以下：执行超出预设次数的锁车命令；和/或，执行重新启动并在重新启动后再次执行锁车命令。

在上述步骤中，判断是否执行超出预设次数的锁车命令，即是否存在多次操作锁车动作但锁车失败的情况，以此体现用户多次尝试但依然无法锁车，可由后台服务器强制锁车，进而减少由于用户误操作导致的无法锁车；判断是否执行重新启动并在重新启动后再次执行锁车命令，即可能会产生锁车器长时间暴露在外界中而导致识别车卡时灵敏度较差的情况，此时通过重新启动重新唤醒锁车器，减少前述情况下导致的无法锁车，由此确保强制锁车的安全问题，减少误操作或识别度低的情况下也调用后台服务器造成的资源浪费。

s400：采用后台服务器对所述用户信息进行信用分析，获得用户信息对应的用户信用等级；

在上述步骤中，后台服务器接收到异常还车请求后，可结合于用户画像大数据技术和/或者信用积分体系技术等对锁车器进行选择性地强制锁车，具体的，参阅图1和图3，采用后台服务器对所述用户信息进行信用分析，获得用户信息对应的用户信用等级，还包括以下：

s411：从预设数据库中根据用户账户获取用户信息，其中，用户信息包括但不限于用户历史订单数据、用户支付数据、用户轨迹数据以及关联数据中的一个或多个；

在上述步骤中，用户历史订单数据可用于体现用户使用公共自行车的频繁程度，用户支付数据可反映用户的支付习惯，如每次均即时支付或少量次数下即时支付，用户轨迹数据可反映用户的出行习惯，用于辅助判断是否达到常用目的地，关联数据包括除前述三种数据外的其他数据，包括但不限于订单支付提醒服务数据等。

s412：基于用户信息进行数据分析，并根据预设规则基于分析结果对用户账户进行信用评级，获得用户账户对应的用户信用等级；

在上述步骤中，根据上述用户信息包括的一个或多个维度数据进行信用评级，每一维度数据对应唯一权重，进而获得用户信用等级，同时也可基于各个用户账号对应的用户信息进行用户画像，以获取用户出行习惯和支付习惯，以进一步更新用户等级。具体的，上述步骤s412中所述基于用户信息进行数据分析，并根据预设规则基于分析结果对用户账户进行信用评级，获得用户账户对应的用户信用等级，参阅图4，包括以下步骤：

s4121：采用预训练后的数据处理模型对用户信息进行信用度计算，获得带有信用值的分级结果；

在上述步骤中，可采用多层神经网络建立数据处理模型，也可采用现有的信用分析模型(作为举例的，如kmv模型)作为数据处理模型，在基于上述用户信息进行信用度计算时需要对数据处理模型进行训练，训练过程中对模型参数进行调整，以获得用于上述步骤的数据处理模型，可以采用预设数据库中的历史数据进行训练，也可建立新的训练样本，最终数据处理模型输出该用户信息对应的信用值作为输出结果。

s4122：基于预设等级映射表获取与分析结果对应的信用等级，生成用户账户对应的用户信用等级。

在上述步骤中，基于上述步骤s4122可知，通过数据处理模型处理后获得该用户账户对应的信用值，因此根据预设等级映射表判断该信用值所处于的数据范围，获得该数值范围对应的信用等级即可，作为距离的预设等级映射表包括信用很差(1)、较差(2)、一般(3)、较好(4)、很好(5)，每一等级均对应长度20％的数值范围，则当用户信用值为68％，则其信用等级为一般(3)，结合下述步骤，此时若预设等级为较好(4)则可强制关锁，若预设等级为一般(3)，则发送包含建议用户更换锁车器的提示信息至用户端。

在本实施方式中，也可能会发生由于用户误操作，在将公共自行车推入锁车器时位置偏离，导致锁车器无法准确识别而执行锁车命令，因此为了进一步减少此类情况而造成的无法锁车的情况，在发送强制锁车命令至站点控制器前，还包括：

在上述步骤s400中，强制锁车需要确保公共自行车进入锁车器内，以使得公共自行车锁住在锁车器内，具体的，上述步骤中所述由站点控制器控制锁车器执行强制锁车命令，参阅图5，包括以下：

s431：站点控制器接收到强制锁车命令，并发送强制锁车命令至锁车器；

在上述步骤中，由于锁车器分布数量较多，因此使每一锁车器连接至后台服务器压力较大，因此在每一锁车区域均设置一站点控制器，该站点控制器用于控制该锁车区域的所有锁车器，后台服务器通过该站点控制器控制该锁车区域内的锁车器。

s432：判断所述公共自行车是否进入到锁车器；

在上述步骤中，所述锁车器自主监测到所述公共自行车进入以发出车辆到位确认信号，通过判断车辆到位信号是否被触发，可对应判断该公共自行车是否处于锁车器内，或者通过用户自主观察后由用户端发出用于确认所述公共自行车位于所述锁车器内的确认信号，可与下述步骤s434中所述在所述公共自行车进入所述锁车器后执行所述强制锁车命令中的判断方式一致。

s433：若是，则由站点控制器控制锁车器执行强制锁车命令；

s434：若否，则发送包含推动公共自行车进入到锁车器的提示信息，当所述公共自行车进入锁车器时执行强制锁车命令。

具体的，若判断该公共自行车不在锁车器内，则锁车器将发出语音信息，提示用户推动所述公共自行车进入到锁车器。

s500：当所述用户账户对应的用户信用等级低于预设等级，则发送包含建议用户更换锁车器的提示信息至所述用户端；

在上述步骤中，用户账户对应的用户信用等级低于预设等级，则由于该用户账户信用程度较低，强制关锁可能产生逃避行程费用的风险，此时不予执行强制关锁，而是提醒用户更换锁车器进行锁车。

s600：当所述用户账户对应的用户信用等级不低于预设等级，发送强制锁车命令至所述站点控制器，并由所述站点控制器控制所述锁车器执行所述强制锁车命令，并获取所述锁车器返回的第二执行结果；

在本方案中，为了解决上述所述锁车失败造成的问题，用户端反馈异常还车请求后，采用后台服务器对锁车器进行定位并通过站点控制器选择性控制锁车器执行强制解锁，区别于现有技术中常用的仅仅反馈故障而不锁车的情况，减少由于锁车失败而不锁车，导致其他用户直接使用该锁车失败的公共自行车而给公共自行车服务平台造成的损失，同时减少无法锁车而导致车辆丢失的情况。

s700：后台服务器根据第二执行结果判断是否结束订单；

在上述步骤s400，在执行强制锁车命令需要返回执行结果，以确保是否锁车成功，若由于锁车器设备故障，则即使确保公共自行车在锁车器内时执行强制锁车命令，也可能会导致锁车失败，因此需要返回执行结果并再次确认。

s800：若成功执行关锁动作，则结束订单；

在本实施方式，通过上述后台服务器强制关锁解决现有技术中用户锁车失败的情况，锁车完成后用户订单结束，可生成行程费用发送至用户端，此时也减少出现产生其他费用的情况。

s900：若关锁动作执行失败，则发送包含建议用户更换锁车器的提示信息。

在上述步骤中，若关锁动作执行失败，无法锁车成功，则可能会是硬件设备出现问题，或数据传输路线出现问题，此时无法通过指令解决问题，此时建议用户更换锁车器以解决无法锁车的问题。

进一步的，为了确认是否为硬件设备问题导致的锁车失败，参阅图6，本实施方式中所述还车处理方法还包括：

s910：在返回执行结果后，锁车器触发用于检测硬件使用状态的自检流程，获取自检结果，并将自检结果发送至后台服务器；

在上述步骤中，锁车器触发用于检测硬件使用状态的自检流程，可以通过在锁车器内设置检测元件实现，具体的如：电流、电压检测元件等，可在每一器件周围均设置检测元件，用于确定故障问题的位置。

s920：若自检结果异常，则后台服务器发出带有维修数据的警示信息。

在上述步骤中，自检结果异常，则说明硬件设备出现问题，此时需要人工介入维修，此时可发出警示信息，该警示信息中可包括上述步骤中所述故障问题的位置数据。

本实施方式中，在上述步骤s400中，可通过用户信用评级来选择性地执行强制锁车命令，为了进一步提高用户信用评级的准确度，所述还车处理方法还包括：在结束订单后，后台服务器自主生成包含异常还车请求的订单信息，并将订单信息存储在预设数据库中与用户账户关联的用户信息下。

在上述步骤中，将该执行强制关锁过程的订单信息增加在与用户账户关联的用户信息，进而用于更新对用户信用值计算，作为举例而非限定的，如某一用户出现过强制关锁成功的订单信息，则适当增加该用户账户的信用值，如某一用户在某一段时间内频繁出现强制关锁的订单信息，则可适当减少该用户账户的信用值，用于减少用户通过强制关锁逃避订单费用的风险。

在本实施方式中，锁车失败可能由很多原因造成，包括但不限于外界环境干扰无法识别卡片，上述监测装置的损坏等，但是造成锁车失败会影响到用户，用户无法即时解决，会影响行程，同时无法结束订单，未上锁的公共自行车可能会被其他用户使用，但此时产生的费用还会附加在该用户未结束的订单上，因此会造成用户的损失，因此当锁车器锁车失败，用户在用户端操作反馈问题，后台服务根据接收到的异常还车请求通过站点控制器对锁车器进行定位后，选择性地对部分用户账户(信用度较高)锁车器进行强制锁车，通过后台服务器操作解决锁车失败的问题，解决现有用户使用公共自行车，还车时出现异常情况无法锁车，导致影响用户出行或产生额外费用的问题，同时还通过获取异动数据，进而减少由于用户误操作或锁车器长时间暴露在外界中而导致无法识别车卡导致的无法锁车，由此确保强制锁车的安全问题。

实施例二：本实施方式公开了一种公共自行车还车处理系统8，参阅图7，本实施方式中的公共自行车包括但不限于普通自行车、电力自行车以及公共自行车，需要说明的是，本实施方式使用的公共自行车在还车区域设有若干固定的锁车器，每一公共自行车由用户推动进入锁车器内后执行锁车，所述系统包括用户端81、锁车器端82、站点控制器端83以及后台服务器端84；

锁车器端82包括：

监测与执行模块821，用于公共自行车进入所述锁车器时执行锁车命令；

第一发送模块822，用于返回第一执行结果至后台服务器存储在异动数据库下；

接收与执行模块823，用于接收强制锁车命令，并获取所述锁车器返回的第二执行结果；

作为补充的，每一公共自行车上均设置有车卡，当公共自行车进入锁车器内时，锁车器识别该公共自行车上的唯一车卡，该唯一车卡可与用户端关联。

用户端81包括：

反馈模块811，用于反馈包含用户信息的异常还车请求至后台服务器；

第一接收模块812，用于接收后台服务器端发出的包含建议用户更换锁车器的提示信息；

用户端为智能终端，可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、pda(个人数字助理)、pad(平板电脑)、等等的智能终端以及诸如数字tv、台式计算机等等的固定终，本领域技术人员将理解的是，该智能终端可以包括各种用于移动目的的元件。

后台服务器端84包括：

分析模块841，用于于对所述用户信息进行信用分析，获得用户信息对应的用户信用等级；

于从预设数据库中根据用户账户获取用户信息，其中，用户信息包括但不限于用户历史订单数据、用户支付数据、用户轨迹数据以及关联数据中的一个或多个，基于用户信息进行数据分析，并根据预设规则基于分析结果对用户账户进行信用评级，获得用户账户对应的用户信用等级，根据用户信用等级选择性地发送强制锁车命令至站点控制器，以进一步确保执行强制关锁的安全性，该预设数据库可以与该后台服务器关联，也可设置在该后台服务器内。

第二发送模块842，用于当所述用户账户对应的用户信用等级低于预设等级，则发送包含建议用户更换锁车器的提示信息至所述用户端；

第三发送模块843，用于当所述用户账户对应的用户信用等级不低于预设等级，发送强制锁车命令至所述站点控制器；

接收和判断模块844，用于接收站点控制器返回的执行结果，根据执行结果判断是否强制闭锁；

第一执行模块845，用于返回的执行结果显示成功执行关锁动作，结束订单；

第二执行模块846，用于返回的执行结果显示关锁动作执行失败，发送包含建议用户更换锁车器的提示信息至用户端；

除上述外，该后台服务器还包括异动数据处理模块847，记录锁车器的第一执行结果和第二执行结果，用户发送还车请求时，不需要扫描锁车器二维码，通过用户手机的定位来匹配公共自行车站点的定位，用户发送还车请求的时间点来筛选锁车器异动数据的时间段，从而确定出锁车器，从而能够执行强制锁车；还包括警示模块848，用于接收到自检结果生成警示信息用于提醒维修人员对由于硬件设备造成无法锁车的情况进行处理；还包括存储模块849，可在结束订单后，生成包含异常还车请求的订单信息，并将订单信息存储在预设数据库中与用户账户关联的用户信息下，用于进一步提高用户信用评级的准确度。

站点控制器端83包括：

处理模块831，用于控制锁车器执行强制锁车命令，并在获取锁车器返回的执行结果后发送至后台服务器。

由于锁车器分布数量较多，因此使每一锁车器连接至后台服务器压力较大，因此在每一锁车区域均设置一站点控制器，该站点控制器用于控制该锁车区域的所有锁车器，并与后台服务器连接，用于使通过后台服务器操作解决锁车失败的问题，解决现有用户使用公共自行车，还车时出现异常情况无法锁车，导致影响用户出行或产生额外费用的问题。

应当注意的是，本发明的实施例有较佳的实施性，且并非对本发明作任何形式的限制，任何熟悉该领域的技术人员可能利用上述揭示的技术内容变更或修饰为等同的有效实施例，但凡未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何修改或等同变化及修饰，均仍属于本发明技术方案的范围内。