CN112037383A - 一种智能门锁及其权限判定方法和应用*** - Google Patents

Abstract

本申请提供了一种智能门锁及其权限判定方法和应用***，该方法在获取载体卡所携带的开锁密码之后，按照与该开锁密码相同的生成方式，基于预存数据和开锁密码中的随机数据，采用预设加密算法，得到智能门锁的目标开锁密码，然后判断该开锁密码是否与目标开锁密码相同，进而判定该载体卡是否具有开锁权限；也即，本发明无需智能门锁中的NB模组投入工作状态，就能得知该载体卡是否具有开锁权限，进而避免了使用NB模组所增加的电流，且无需提前将载体卡的信息提交至云平台，对于用户的使用体验无差别。

Description

一种智能门锁及其权限判定方法和应用***

技术领域

本发明涉及检测技术领域，具体涉及一种智能门锁及其权限判定方法和应用***。

背景技术

智能门锁是指区别于传统机械锁，在其基础上改进的，在应用安全性、识别、管理性能方面更加智能化简便化的锁具。智能门锁对电流的要求极其严苛，在休眠状态下，电流一般维持在20～30uA，而在工作状态时，电流会维持在50～100mA。一旦开启智能门锁中的NB(Narrow Band Internet of Things，窄带物联网)模组，则会叠加NB模组的工作消耗，使得整个智能门锁的电流达到400mA。

由于现有NB模组自身的低功耗技术还不能满足智能门锁的低电流要求，因此，NB模组只有在特定的情况下，例如发生告警和离线密码开锁时，才会启用电源进行联网，并且限制每天联网的次数。当联网次数达到上限之后，NB模组需等待次日才能联网。若是智能门锁不发生任何操作，则需间隔24小时才会向云平台上报一次智能门锁的状态。

现有技术中，如果需要通过携带开锁密码的门卡打开智能门锁，比如公寓应用场景下，则需要及时开启NB模组以使智能门锁能够得知相应门卡具有开锁权限，则不可避免的导致功耗上升；或者需要提前通过NB模组通知智能门锁，显然不适用于该场景。

发明内容

对此，本申请提供一种智能门锁及其权限判定方法和应用***，以使智能门锁可以以低功耗及时得知门卡是否具有开锁权限。

为实现上述目的，本发明实施例提供如下技术方案：

本申请第一方面公开了一种智能门锁的权限判定方法，包括：

获取载体卡所携带的开锁密码；

基于预存数据和所述开锁密码中的随机数据，采用预设加密算法，得到所述智能门锁的目标开锁密码；所述目标开锁密码与所述开锁密码的生成方式相同；

判断所述开锁密码是否与所述目标开锁密码相同；

若所述开锁密码与所述目标开锁密码相同，则判定所述载体卡具有开锁权限。

可选地，在上述的智能门锁的权限判定方法中，所述开锁密码包括：按照预设顺序排列的所述随机数据和混合加密数据；

所述混合加密数据是基于所述随机数据和保密数据进行加密后生成的数据；所述保密数据与所述预存数据为相同的数据。

可选地，在上述的智能门锁的权限判定方法中，所述基于预存数据和所述开锁密码中的随机数据，采用预设加密算法，得到所述智能门锁的目标开锁密码，包括：

对所述随机数据和所述保密数据进行多次加密，生成多个目标加密数据；

对于多个所述目标加密数据，分别与所述随机数据按照所述预设顺序进行排列，生成多个密码，均作为所述目标开锁密码。

可选地，在上述的智能门锁的权限判定方法中，判断所述开锁密码是否与所述目标开锁密码相同，包括：

判断所述开锁密码是否与所述目标开锁密码中的任意一个密码相同；

若所述开锁密码与所述目标开锁密码中的任意一个密码相同，则判定所述开锁密码与所述目标开锁密码相同。

可选地，在上述的智能门锁的权限判定方法中，所述保密数据包括所述智能门锁自身的根密钥、时间戳及锁设备ID；

对所述随机数据和所述保密数据进行多次加密，包括：

基于所述根密钥、所述时间戳、所述锁设备ID及所述随机数据，采用相同算法进行计算，得到当前时间戳之后的N个预设时间段的对应密码，均作为所述目标加密数据；

其中，N为正整数。

可选地，在上述的智能门锁的权限判定方法中，N为3，所述预设时间段为8小时。

可选地，在上述的智能门锁的权限判定方法中，云平台持有所述保密数据，所述开锁密码是所述云平台接收到密码申请请求后生成的。

可选地，在上述的智能门锁的权限判定方法中，在判断所述开锁密码是否与所述目标开锁密码相同之后，若所述开锁密码与所述目标开锁密码不相同，则还包括：

判定所述载体卡不具有开锁权限。

可选地，在上述的智能门锁的权限判定方法中，在判定所述载体卡具有开锁权限之后，还包括：

将所述载体卡的信息写入所述智能门锁的白名单。

可选地，在上述的智能门锁的权限判定方法中，在获取载体卡所携带的开锁密码之后，还包括：

判断所述载体卡的信息是否属于所述智能门锁白名单；其中，所述智能门锁的白名单在所述智能门锁与所述云平台联网时被更新；

若所述载体卡的信息不属于所述白名单，则执行所述基于预存数据和所述开锁密码中的随机数据，采用预设加密算法，得到所述智能门锁的目标开锁密码的步骤；

若所述载体卡的信息属于所述白名单，则判定所述载体卡具有开锁权限。

本申请第二方面公开了一种智能门锁，包括：锁体、电池、NB模组、存储器和处理器；其中：

所述电池用于为所述智能门锁供电；

所述NB模组用于实现所述处理器与云平台之间的通信；

所述处理器用于控制所述锁体，以及运行所述存储器中存储的程序；

所述存储器中存储的程序，包括如上述第一方面公开的任一所述的智能门锁的权限判定方法。

本申请第三方面公开了一种智能门锁的应用***，包括：处理终端、云平台、至少一个载体卡及至少一个如第二方面公开的智能门锁；其中：

所述云平台分别与所述处理终端以及所述智能门锁中的NB模组通信相连；

所述处理终端，用于响应用户操作，向所述云平台发送密码申请请求，以索要相应智能门锁的开锁密码；接收云平台反馈的开锁密码，并将所述开锁密码写入载体卡；

所述云平台，用于响应所述密码申请请求，根据随机数据及所述智能门锁与所述云平台共同持有的保密数据，计算得到所述开锁密码，并将所述开锁密码反馈至所述处理终端。

可选地，在上述智能门锁的应用***中，在所述智能门锁中的NB模组与所述云平台联网时，所述云平台还用于：将所述开锁密码下发至所述智能门锁；

所述智能门锁还用于：接收所述开锁密码，并对自身中的白名单进行更新。

基于上述本发明提供的智能门锁的权限判定方法，该方法在获取载体卡所携带的开锁密码之后，按照与该开锁密码相同的生成方式，基于预存数据和开锁密码中的随机数据，采用预设加密算法，得到智能门锁的目标开锁密码，然后判断该开锁密码是否与目标开锁密码相同，进而判定该载体卡是否具有开锁权限；也即，本发明能够在智能门锁中的NB模组无需投入工作状态时，就能通过智能门锁自身采用与开锁密码相同的生成方式，来验算其开锁密码是否正确，进而得知该载体卡是否具有开锁权限，相较于现有使用NB模组来实现智能门锁与云平台之间信息互换，以判定该载体卡是否具有开锁权限的方式，能够减少使用NB模组所增加的电流，且无需提前将载体卡的信息提交至云平台，就能实现智能门锁对载体卡信息的及时获取，对于用户的使用体验无差别。

附图说明

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

图1为本申请实施例提供的一种智能门锁的权限判定方法的流程图；

图2为本申请实施例提供的一种智能门锁的权限判定方法的部分流程图；

图3-5为本申请实施例提供的另外三种智能门锁的权限判定方法的流程图；

图6为本申请实施例提供的一种智能门锁的应用***的结构示意图。

具体实施方式

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

本申请实施例提供了一种智能门锁的权限判定方法，应用于智能门锁的处理器，以使智能门锁可以以低功耗及时得知门卡是否具有开锁权限。

请参见图1，该权限判定方法主要包括以下步骤：

S101、获取载体卡所携带的开锁密码。

在智能门锁的应用***中，载体卡是指与智能门锁相匹配，并且携带有智能门锁开锁密码的用户卡。

在实际应用中，该载体卡可以是射频卡，也可以是非接触式的TM卡；当然，还可以现有技术中其他能够应用于智能门锁***中的门卡。本申请对载体卡的具体形式不作限定，均属于本申请的保护范围。

具体的，该开锁密码包括：按照预设顺序排列的随机数据和混合加密数据。其中，混合加密数据是基于随机数据和保密数据进行加密后生成的数据。实际应用中，该开锁密码可以是云平台负责生成的，而且云平台与智能门锁共同持有该保密数据。

当智能门锁获取到该开锁密码之后，即可获取该随机数据，且自身内部又预存有该保密数据，因此，可以执行步骤S102。

S102、基于预存数据和开锁密码中的随机数据，采用预设加密算法，得到智能门锁的目标开锁密码。

其中，预存数据，即为智能门锁中预存的保密数据。

实际应用中，步骤S102、采用预设加密算法，得到智能门锁的目标开锁密码的具体过程，可参见图2。

S201、对随机数据和保密数据进行多次加密，生成多个目标加密数据。

具体的，若保密数据包括智能门锁自身的根密钥、时间戳及锁设备ID，则对随机数据和保密数据进行多次加密的具体过程包括：

基于根密钥、时间戳、锁设备ID及随机数据，采用相同算法进行计算，得到当前时间戳之后的N个预设时间段的对应密码，均作为目标加密数据。其中，N为正整数。

在实际应用中，根据NB联网间隔决定N的取值以及预设时间段间隔，比如NB联网间隔为24小时，那么取N为3，预设时间段为8小时，如果NB联网间隔为12小时，那么取N为3，预设时间为4小时，依此类推。当然，N和预设时间段的具体取值，还可视其具体应用环境和用户需求确定，本申请不作具体限定，均属本申请的保护范围。

S202、对于多个目标加密数据，分别与随机数据按照预设顺序进行排列，生成多个密码，均作为目标开锁密码。

其中，预设顺序可以是随机数据在前、目标加密数据在后的拼接顺序；当然，还可以是目标加密数据在前、随机数据在后的拼接顺序。本申请对预设顺序的具体方式不作限定，均属于本申请的保护范围。

实际上，目标开锁密码与开锁密码的生成方式相同，即目标开锁密码中的各个密码的生成方式均与开锁密码的生成方式相同；下面以一具体实例，对得到开锁密码和目标开锁密码的过程作进一步的解释说明：

首先，当智能门锁的应用***中的处理终端，比如酒店的前台电脑，响应用户操作之后，将会向云平台发送密码申请请求，以索要相应智能门锁的开锁密码。此时，云平台响应密码申请请求，根据随机数据和智能门锁与云平台共同持有的保密数据，采用预设加密算法，计算得到开锁密码。

假设开锁密码的位数为六位，则云平台生成开锁密码的具体过程为：

a、云平台首先生成2位数的随机数据，例如28。

b、云平台根据保密数据中的时间戳、智能门锁的根密钥、锁设备ID以及生成的随机数据，采用预设加密算法进行计算，得到混合加密数据4685。

c、将随机数据和混合加密数据按照随机数据在前、混合加密数据在后进行排列，得到开锁密码284685。

然后云平台将该开锁密码返回到处理终端，由处理终端写入载体卡。

之后，用户携带该载体卡进行第一次开门操作，智能门锁执行步骤S101和S102；与开锁密码生成方式相同的，假设N为3、预设时间段为8小时，则智能门锁得到目标开锁密码的具体过程为：

1、智能门锁首先获取开锁密码中的随机数据，例如上文中的28。

2、智能门锁根据保密数据中的时间戳、智能门锁的根密钥、锁设备ID以及该随机数据，采用预设加密算法进行计算，得到当前时间戳之后的3个、预设时间段为8小时对应密码，分别为：4685、5326、9643，均作为目标加密数据。

3、将随机数据和各个目标数据，分别按照随机数据在前、目标数据在后进行排列，得到3个六位数的目标开锁密码，分别为：284685、285326、289643。

换言之，当N为3，预设时间段为8小时时，智能门锁可以根据自身的根密钥、时间戳、锁设备ID及开锁密码中的前两位随机数据，采用预设加密算法分别进行3次计算，进而能够得到当前时间戳之后、每隔8小时对应的密码。也即，通过上述方式，能够得到智能门锁未来24小时内、每个8小时对应的智能门锁的开锁密码，作为目标开锁密码。即可执行步骤S103。

S103、判断开锁密码是否与目标开锁密码相同。

同样，假设N为3，预设时间段为8小时，若是载体卡所携带的开锁密码是智能门锁当前时间戳之后24小时内的密码中的任意一个，则可视为判断出开锁密码与目标开锁密码相同，则执行步骤S104。

S104、判定载体卡具有开锁权限。

实际应用中，只要载体卡携带的开锁密码与当前时间戳之前24小时内，智能门锁对应的目标开锁密码中的任意一个相同，换言之，若是载体卡所携带的开锁密码与智能门锁中采用预设加密算法得到的目标开锁密码中的任意一个相同，就能判定出该载体卡具有开锁权限。

在本实施中，通过上述过程即可在由用户在第一次使用载体卡打开智能门锁的过程中直接实现对载体卡的权限判断；也即，本发明能够在智能门锁中的NB模组无需投入工作状态时，就能通过智能门锁自身采用与开锁密码相同的生成方式，来验算其开锁密码是否正确，进而得知该载体卡是否具有开锁权限，相较于现有使用NB模组来实现智能门锁与云平台之间信息互换，以判定该载体卡是否具有开锁权限的方式，能够减少使用NB模组所增加的功耗，且无需提前将载体卡的信息提交至云平台，就能实现智能门锁对载体卡信息的及时获取，对于用户的使用体验无差别。

可选地，在本申请提供的另一实施例中，请参见图3，在执行步骤S103、判断开锁密码是否与目标开锁密码中的任意一个相同之后，若开锁密码与目标开锁密码中的全部密码均不相同，则还包括步骤S301。

S301、判定载体卡不具有开锁权限。

同样假设N为3，预设时间段为8小时，当载体卡所携带的开锁密码与当前时间戳之后24小时内，智能门锁对应的开锁密码均不同时，就能够得知载体卡所携带的开锁密码，不是使用该智能门锁与云平台共同持有的保密数据及随机数据得到的，进而就能够判定出该载体卡不具有开锁权限。

可选地，在上述任一实施例的基础之上，请参见图4(以在图1的基础上为例进行展示)，在执行步骤S104、判定载体卡具有开锁权限之后，还包括：

S401、将载体卡的信息写入智能门锁的白名单。

需要说明的是，采用与生成开锁密码相同的加密算法得到目标开锁密码的方式，判定载体卡具有开锁权限之后，可以将载体卡的信息写入智能门锁的白名单中，使得该载体卡成为智能门锁合法授权的用户卡，后续用户使用该载体卡时，能够直接通过智能门锁的验证。

可选地，在上述任一实施例的基础之上，请参见图5(以在图1的基础上为例进行展示)，在执行步骤S101、获取载体卡所携带的开锁密码之后，还包括：

S501、判断载体卡的信息是否属于智能门锁白名单。

其中，智能门锁的白名单在智能门锁与云平台联网时被更新。

若载体卡的信息不属于白名单，则执行步骤S102、基于预存数据和开锁密码中的随机数据，采用预设加密算法，得到智能门锁的目标开锁密码。也即，在采用智能门锁的白名单对载体卡的开锁权限的判定结果为不具有开锁权限之后，通过执行后续步骤，采用预设加密算法得到目标开锁密码的方式，对该载体卡是否具有开锁权限进行二次判定，以实现在智能门锁未启动NB模组与云平台联网对自身中的白名单进行更新时，依然能够通过智能门锁自身对载体卡所携带的开锁密码进行权限判定，使得用户使用体验感与启动NB模组与云平台联网对智能门锁白名单进行更新后再进行权限判定的方式无差。

若开锁密码属于白名单中的密码，则执行步骤S104、判定载体卡具有开锁权限。

实际应用中，若是智能门锁能够在获取载体卡所携带的开锁密码之前，就通过自身中的NB模组与云平台进行联网、对自身中的白名单进行更新，则通过该白名单就能够实现对载体卡的信息验证，进而能够直接判定出该载体卡是否具有开锁权限。

在上述示出的智能门锁的权限判定方法的基础之上，本申请另一实施例还提供了一种智能门锁，该智能门锁主要包括：

锁体、电池、NB模组、存储器和处理器。

其中，电池用于为智能门锁供电。

NB模组用于实现处理器与云平台之间的通信。

处理器用于控制锁体，以及运行存储器中存储的程序。

存储器中存储的程序，包括如上述任一实施例所述的智能门锁的权限判定方法。

需要说明的是，智能门锁中锁体、电池、NB模组、存储器和处理器的原理和相关说明，可参见现有技术，本申请不再赘述。

还需要说明的是，存储器中所存储程序中的智能门锁的权限判定方法的原理和相关说明，可参见本申请图1至图5对应的实施例，此处不再赘述。

可选地，在上述的基础之上，本申请实施例还提供了一种智能门锁的应用***，请参见图6，该智能门锁的应用***主要包括：处理终端101、云平台102、至少一个载体卡104及至少一个执行智能门锁的权限判定方法的智能门锁103。

其中，云平台102分别与处理终端101以及智能门锁103中的NB模组通信相连。

处理终端101，用于响应用户操作，向云平台102发送密码申请请求，以索要相应智能门锁的开锁密码；接收云平台102反馈的开锁密码，并将开锁密码写入载体卡104。

云平台102，用于响应密码申请请求，根据随机数据及智能门锁103与云平台102共同持有的保密数据，计算得到开锁密码，并将开锁密码反馈至处理终端101。

实际应用中，云平台102可以是用于实现对处理终端101和智能门锁103进行管理的服务器。

处理终端101可以是电脑前端，也可以是智能门锁的应用***中任意一个具有处理功能的终端服务器。本申请对其具体形式不作限定，均属本申请的保护范围。

在实际应用中，载体卡104可以是射频卡，处理终端101通过射频读卡器可将开锁密码写入该射频卡。

需要说明的是，若是智能门锁的应用***的应用场景为酒店、载体卡104为射频卡，则处理终端101为酒店前台、用于办理入住的电脑。在酒店管理人员为客人办理入住手续时，该电脑能够响应酒店管理人员的操作，向云平台发送密码申请请求，以索要相应智能门锁的开锁密码。当接收到云平台102反馈的开锁密码后，酒店管理人员就可通过操纵处理终端101，并通过射频读卡器将开锁密码写入射频卡，以使用户能够在预设时间段内，例如24小时内，使用该射频卡对智能门锁实现开门。

结合图6和上述说明，下面再以一个具体实例，对智能门锁的应用***作进一步的解释和说明：

1、用户完成入住手续后，处理终端101通过网络向云平102台申请24小时临时密码。

2、云平台102首先生成两位数的随机数，再利用所生成的随机数据，结合时间戳、智能门锁103的根密钥及锁设备ID，经过一定的算法得到其他四位数，进而将两位数和四位数进行合并，拼成一个六位数的密码，也即开锁密码。

3、处理终端101通过射频读卡器将开锁密码写入射频卡(也即载体卡101)，当用户在24小时内使用该射频卡第一次开门时，若云平台102已经通过智能门锁NB模组的联网窗口把射频卡的信息发送至智能门锁103，则智能门锁103比对射频卡白名单信息，验证通过则开锁；若是射频卡不在智能门锁白名单之内，则智能门锁103根据自身的根密钥、时间戳、锁设备ID及射频卡所携带开锁密码的前两位随机数据，采用相同算法计算当前时间戳后面每8个小时的密码，一共计算3次，只要有一个8小时密码与射频卡的开锁密码相同，就认为该射频卡得到过合法授权，把该射频卡信息写入智能门锁103成为一张正式卡，否则就认为该射频卡为非法卡。

需要说的是，利用随机数据，能够防止云平台101保密数据的泄露。并且，射频卡内的数据具有一定的时效性，超过一定时间，该数据就作废。以人作为信息搬运工，把信息中的随机数据部分告诉智能门锁103，智能门锁103再利用云平台102与自身共同持有的保密数据，经过相同算法得到目标开锁密码，并将两者进行比对得到最终的判定结果。

还需要说明的是，设置短时间内载体卡104中信息有效，相当于通过该载体卡104把数据写入智能门锁103。超过载体卡104内信息的时效范围，云平台102即可通过NB模组通道下发至智能门锁103，再使用原载体卡内的信息，依然可以通过验证，让用户体验无差别。也即，本方案利用人作为携带信息的传递者，弥补NB模组通信方式的非实时性短缺，在短时间内实现信息安全地从云平台102至智能门锁103的传递。

换言之，本方案利用用户会携带载体卡到智能门锁103上进行刷卡的这一操作，相当于用户在交流过程中起到了一种传输数据的作用，成为NB模组通信通道的关键备份，并且能够保证数据安全。

并且，本应用***中的智能门锁103在得知该载体卡具有开锁权限之后，还能将开锁密码写入智能门锁103的白名单中，使得该载体卡成为智能门锁合法授权的用户卡，以保证后续用户使用该载体卡时，能够直接通过智能门锁103的验证。

实际应用中，在智能门锁103中的NB模组与云平台102联网时，云平台102还用于：将开锁密码下发至智能门锁。

智能门锁103还用于：接收开锁密码，并对自身中的白名单进行更新。

需要说明的是，通过智能门锁103中的NB模组与云平台102进行联网，能够实现智能门锁103与云平台102的信息的同步。

还需要说明的是，应用***中智能门锁103和智能门锁103所执行的权限判定方法的原理和相关说明，还可参见上述实施例，此处不再赘述。

本说明书中的各个实施例中记载的特征可以相互替换或者组合，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***或***实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的***及***实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (13)

1.一种智能门锁的权限判定方法，其特征在于，包括：

获取载体卡所携带的开锁密码；

基于预存数据和所述开锁密码中的随机数据，采用预设加密算法，得到所述智能门锁的目标开锁密码；所述目标开锁密码与所述开锁密码的生成方式相同；

判断所述开锁密码是否与所述目标开锁密码相同；

若所述开锁密码与所述目标开锁密码相同，则判定所述载体卡具有开锁权限。

2.根据权利要求1所述的智能门锁的权限判定方法，其特征在于，所述开锁密码包括：按照预设顺序排列的所述随机数据和混合加密数据；

所述混合加密数据是基于所述随机数据和保密数据进行加密后生成的数据；所述保密数据与所述预存数据为相同的数据。

3.根据权利要求2所述的智能门锁的权限判定方法，其特征在于，所述基于预存数据和所述开锁密码中的随机数据，采用预设加密算法，得到所述智能门锁的目标开锁密码，包括：

对所述随机数据和所述保密数据进行多次加密，生成多个目标加密数据；

对于多个所述目标加密数据，分别与所述随机数据按照所述预设顺序进行排列，生成多个密码，均作为所述目标开锁密码。

4.根据权利要求3所述的智能门锁的权限判定方法，其特征在于，判断所述开锁密码是否与所述目标开锁密码相同，包括：

判断所述开锁密码是否与所述目标开锁密码中的任意一个密码相同；

若所述开锁密码与所述目标开锁密码中的任意一个密码相同，则判定所述开锁密码与所述目标开锁密码相同。

5.根据权利要求3所述的智能门锁的权限判定方法，其特征在于，所述保密数据包括所述智能门锁自身的根密钥、时间戳及锁设备ID；

对所述随机数据和所述保密数据进行多次加密，包括：

基于所述根密钥、所述时间戳、所述锁设备ID及所述随机数据，采用相同算法进行计算，得到当前时间戳之后的N个预设时间段的对应密码，均作为所述目标加密数据；

其中，N为正整数。

6.根据权利要求5所述的智能门锁的权限判定方法，其特征在于，N为3，所述预设时间段为8小时。

7.根据权利要求2-6任一所述的智能门锁的权限判定方法，其特征在于，云平台持有所述保密数据，所述开锁密码是所述云平台接收到密码申请请求后生成的。

8.根据权利要求1所述的智能门锁的权限判定方法，其特征在于，在判断所述开锁密码是否与所述目标开锁密码相同之后，若所述开锁密码与所述目标开锁密码不相同，则还包括：

判定所述载体卡不具有开锁权限。

9.根据权利要求1所述的智能门锁的权限判定方法，其特征在于，在判定所述载体卡具有开锁权限之后，还包括：

将所述载体卡的信息写入所述智能门锁的白名单。

10.根据权利要求7所述的智能门锁的权限判定方法，其特征在于，在获取载体卡所携带的开锁密码之后，还包括：

判断所述载体卡的信息是否属于所述智能门锁白名单；其中，所述智能门锁的白名单在所述智能门锁与所述云平台联网时被更新；

若所述载体卡的信息不属于所述白名单，则执行所述基于预存数据和所述开锁密码中的随机数据，采用预设加密算法，得到所述智能门锁的目标开锁密码的步骤；

若所述载体卡的信息属于所述白名单，则判定所述载体卡具有开锁权限。

11.一种智能门锁，其特征在于，包括：锁体、电池、NB模组、存储器和处理器；其中：

所述电池用于为所述智能门锁供电；

所述NB模组用于实现所述处理器与云平台之间的通信；

所述处理器用于控制所述锁体，以及运行所述存储器中存储的程序；

所述存储器中存储的程序，包括如权利要求1-10任一所述的智能门锁的权限判定方法。

12.一种智能门锁的应用***，其特征在于，包括：处理终端、云平台、至少一个载体卡及至少一个如权利要求11所述的智能门锁；其中：

所述云平台分别与所述处理终端以及所述智能门锁中的NB模组通信相连；

所述处理终端，用于响应用户操作，向所述云平台发送密码申请请求，以索要相应智能门锁的开锁密码；接收云平台反馈的开锁密码，并将所述开锁密码写入载体卡；

所述云平台，用于响应所述密码申请请求，根据随机数据及所述智能门锁与所述云平台共同持有的保密数据，计算得到所述开锁密码，并将所述开锁密码反馈至所述处理终端。

13.根据权利要求12所述的智能门锁的应用***，其特征在于，在所述智能门锁中的NB模组与所述云平台联网时，所述云平台还用于：将所述开锁密码下发至所述智能门锁；

所述智能门锁还用于：接收所述开锁密码，并对自身中的白名单进行更新。

Images