CN111882720B - 一种基于云操作票的锁具控制方法及装置 - Google Patents

Abstract

本申请提供一种基于云操作票的锁具控制方法及装置，该方法包括：当检测到上一操作阶段的授权执行角色的操作完成反馈时，根据云操作票获取下一操作阶段的授权执行角色；发送下一操作阶段的操作指示信息至该授权执行角色的执行终端，指示其操作目标锁具；接收当前执行角色的执行终端针对所述目标锁具发起的开锁请求；若当前执行角色为该下一操作阶段的授权执行角色，生成用于打开所述目标锁具的控制指令。基于该云操作票，使得各个授权执行角色能按照事务的发展顺序操作锁具，以精准适应其锁具操作场景，提高锁具操作的安全性，避免无关人员操作锁具，且实现多用户协同操作锁具时的有序开锁，防止逻辑性解锁错误。

Description

一种基于云操作票的锁具控制方法及装置

技术领域

本申请涉及锁具控制技术领域，具体而言，涉及一种基于云操作票的锁具控制方法及装置。

背景技术

在现有的快递配送过程中，需要快递送出方、快递配送方和快递接收方协同对装有快递的配送箱的锁具进行操作，但由于无法确保整个配送环节各参与方的有序开锁、闭锁管理，如果锁具出现逻辑性解锁错误，则容易出现快递丢失、损坏、污染以及泄密等问题。当然，不限于快递配送领域，任一需要N个用户协同对M个锁具进行操作的场景都存在此问题。

发明内容

本申请实施例的目的在于提供一种基于云操作票的锁具控制方法及装置，以实现多方有序对锁具进行操作。

第一方面，本申请实施例提供一种基于云操作票的锁具控制方法，所述方法包括：当检测到上一操作阶段的授权执行角色的操作完成反馈时，根据所述操作完成反馈查询预先生成的云操作票，以获取下一操作阶段的授权执行角色；发送下一操作阶段的操作指示信息至所述下一操作阶段的授权执行角色的执行终端，以指示所述下一操作阶段的授权执行角色操作下一操作阶段对应的目标锁具；接收当前执行角色的执行终端针对所述目标锁具发起的开锁请求；判断所述当前执行角色是否为所述下一操作阶段的授权执行角色，若是，生成用于打开所述目标锁具的控制指令。

在上述方案中，基于预先生成的云操作票，使得各个授权执行角色能按照事务的发展顺序操作锁具，以精准适应其锁具操作场景，提高锁具操作的安全性，一方面，避免无关人员操作锁具，另一方面，可以实现多用户协同操作锁具时的有序开锁，防止逻辑性解锁错误，避免出现快递等物品的丢失、损坏、污染或者泄密。

在一种可选的实施方式中，在根据所述操作完成反馈查询预先生成的云操作票之前，所述方法还包括：接收操作票生成请求，所述操作票生成请求包括至少一个授权执行角色的信息；根据所述至少一个授权执行角色的信息和预设的锁具操作逻辑生成云操作票，所述云操作票包括多个具有设定顺序的操作阶段，每一操作阶段设置有允许操作锁具的授权执行角色。

在一种可选的实施方式中，所述方法还包括：接收角色更改指令，所述角色更改指令包括对所述云操作票进行更改的目标操作阶段以及所述目标操作阶段的新授权执行角色；将所述云操作票中目标操作阶段的授权执行角色替换为所述新授权执行角色。

云操作票并非一成不变，管理角色可以通过管理终端对云操作票中的授权执行角色进行更改。

在一种可选的实施方式中，在发送下一操作阶段的操作指示信息至所述下一操作阶段的授权执行角色的执行终端之后，所述方法还包括：若在第一时限内未接收到所述下一操作阶段的授权执行角色的执行终端发送的开锁请求，查询可替代的目标执行角色，并发送所述下一操作阶段的操作指示信息至所述目标执行角色的执行终端。

服务器通过智能识别第一时限内目标锁具的开锁情况，动态调整云操作票中的授权执行角色，为配送订单合理分配授权执行角色，从而优化配送订单的完成效果。

在一种可选的实施方式中，所述查询可替代的目标执行角色，并发送所述下一操作阶段的操作指示信息至所述目标执行角色的执行终端，包括：获取目标锁具预设位置范围内的至少一个待选执行角色的任务清单；根据所述任务清单从所述至少一个待选执行角色中选出目标执行角色；发送所述下一操作阶段的操作指示信息至所述目标执行角色的执行终端，以指示所述目标执行角色操作所述下一操作阶段对应的目标锁具。

在一种可选的实施方式中，在生成用于打开所述目标锁具的控制指令之后，所述方法还包括：发送所述控制指令至所述当前执行角色的执行终端，以使所述当前执行角色的执行终端通过与所述目标锁具建立的近距离通信连接控制所述目标锁具打开。

目标锁具为智能锁，执行终端通过近距离通信连接可以直接控制目标锁具的开锁和闭锁。

在一种可选的实施方式中，所述目标锁具内设有远传模块，在生成用于打开所述目标锁具的控制指令之后，所述方法还包括：发送所述控制指令至所述目标锁具的远传模块，以控制所述目标锁具打开。

通过远传模块，服务器可直接向目标锁具下达开锁的控制指令。

第二方面，本申请实施例提供一种基于云操作票的锁具控制装置，所述装置包括：执行角色查询模块，用于在检测到上一操作阶段的授权执行角色的操作完成反馈时，根据所述操作完成反馈查询预先生成的云操作票，以获取下一操作阶段的授权执行角色；操作指示下达模块，用于发送下一操作阶段的操作指示信息至所述下一操作阶段的授权执行角色的执行终端，以指示所述下一操作阶段的授权执行角色操作下一操作阶段对应的目标锁具；开锁请求接收模块，用于接收当前执行角色的执行终端针对所述目标锁具发起的开锁请求；开锁权限判定模块，用于判断所述当前执行角色是否为所述下一操作阶段的授权执行角色，若是，生成用于打开所述目标锁具的控制指令。

第三方面，本申请实施例提供一种服务器，包括处理器以及存储器，所述存储器存储有计算机可读取指令，当所述计算机可读取指令由所述处理器执行时，运行如第一方面、第一方面中任一可选实施方式所述的方法。

第四方面，本申请实施例提供一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时运行如第一方面、第一方面中任一可选实施方式所述的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的基于云操作票的锁具控制方法的流程图；

图2为本申请实施例提供的基于云操作票的锁具控制方法的又一流程图；

图3为实例一的一种货架的示意图；

图4为本申请实施例提供的基于云操作票的锁具控制装置的示意图；

图5为本申请实施例提供的服务器的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

本申请实施例提供一种基于云操作票的锁具控制方法，通过预先生成的云操作票，实现整个锁具操作过程的有序开锁、闭锁管理，防止由于逻辑性解锁错误导致出现快递丢失、损坏、污染以及泄密等问题。下文主要从服务器的角度描述该锁具控制方法，并以快餐配送的场景为例对方案进行说明。请参照图1，其包括如下步骤：

步骤110：当检测到上一操作阶段的授权执行角色的操作完成反馈时，根据该操作完成反馈查询预先生成的云操作票，以获取下一操作阶段的授权执行角色。

在步骤110之前，该锁具控制方法还包括生成云操作票的过程。具体的，服务器接收一执行终端发起的操作票生成请求，该操作票生成请求包括至少一个授权执行角色的信息；服务器根据该至少一个授权执行角色的信息和预设的锁具操作逻辑生成云操作票。云操作票中包括多个具有设定顺序的操作阶段，每一操作阶段设置有允许操作锁具的授权执行角色。例如，在一云操作票中，第一个操作阶段设置授权执行角色为“商家A”，表示允许“商家A”在第一个操作阶段操作锁具。上述锁具操作逻辑是预先配置好的，可以针对不同的锁具操作场景配置不同的锁具操作逻辑，如用于快餐配送的锁具操作逻辑和用于银行保险箱管理的锁具操作逻辑不同。服务器以该锁具操作逻辑为模板生成云操作票，在云操作票生成后，其中每一操作阶段的信息还可以由管理角色进行更改，或者由服务器自动进行更改。

服务器预先生成云操作票，且云操作票与订单具有一一对应关系。服务器在检测到上一操作阶段的操作完成反馈时，根据该操作完成反馈查询预先生成的云操作票，以获取下一操作阶段的授权执行角色。其中，检测到上一操作阶段的操作完成反馈的步骤包括但不限于以下方式：

方式一：每一锁具内设有传感器，其用于检测对应锁具内的开锁状态变化，获得状态变化信息，在任一操作阶段中，若获取到该操作阶段需操作的目标锁具的状态变化信息，且该状态变化信息与该操作阶段对锁具的操作相匹配，则认为检测到该操作阶段的操作完成反馈。状态变化信息可由锁具内的远传模块直接上传到服务器，也可以由锁具发送给授权执行角色的执行终端，执行终端将状态变化信息上传到服务器。

方式二：每一锁具为智能锁，其可与授权执行角色的执行终端建立近距离通信连接，例如建立蓝牙连接、NFC连接、WIFI连接等，授权执行角色可通过执行终端上的APP、小程序或网页等方式控制目标锁具的开锁和闭锁。如授权执行角色在对应的操作阶段中通过执行终端的APP上点击“闭锁”或者“开锁”，则执行终端通过近距离通信连接控制目标锁具闭锁或开锁，同时，执行终端将对锁具的操作反馈给服务器，服务器在收到该反馈后，认为检测到该操作阶段的操作完成反馈。

步骤120：发送下一操作阶段的操作指示信息至该下一操作阶段的授权执行角色的执行终端，以指示该下一操作阶段的授权执行角色操作下一操作阶段对应的目标锁具。

在云操作票中包括多个具有设定顺序的操作阶段，该下一操作阶段为该上一操作阶段的下一个阶段。当检测到上一操作阶段完成后，将进入下一操作阶段，服务器在云操作票中查询到下一操作阶段的授权执行角色后，将下一操作阶段的操作指示信息发给授权执行角色的执行终端，如指示授权执行角色“用户B”可以去开锁“2号链条锁”。

在本实施例中，可以在生成云操作票时为每一操作阶段分配具体的锁具标识，例如分配第一个操作阶段的授权执行角色“商家A”操作“2号配送箱锁”，分配第二个操作阶段的授权执行角色“用户B”操作“2号链条锁”，分配第三个操作阶段的授权执行角色“用户B”操作“3号链条锁”，依此类推。当然，也可以在生成云操作票时暂不分配具体的锁具标识，服务器在检测到上一操作阶段的操作完成反馈之后，再具体选出一空闲锁具，根据该空闲锁具的标识生成下一操作阶段的操作指示信息，但该下一操作阶段需操作的锁具与上一操作阶段操作的锁具具有关联的情况除外，即此情况可以无须选择空闲锁具。

步骤130：接收当前执行角色的执行终端针对目标锁具发起的开锁请求。

在发送下一操作阶段的操作指示信息至授权执行角色的执行终端后，服务器接收到当前执行角色的执行终端针对目标锁具发起的开锁请求，此处的当前执行角色可能是该下一操作阶段的授权执行角色，也可能不是该下一操作阶段的授权执行角色。

步骤140：判断当前执行角色是否为该下一操作阶段的授权执行角色，若是，生成用于打开目标锁具的控制指令。

服务器收到一执行终端针对目标锁具发起的开锁请求后，根据该开锁请求校验请求发起方是否具有开启该目标锁具的权限，若请求发起方(即当前执行角色)为该下一操作阶段中设置的可允许操作目标锁具的授权执行角色，则确定其具有开启目标锁具的权限，予以授权，若当前执行角色不为该下一操作阶段中设置的可允许操作目标锁具的授权执行角色，则确定其不具有开启目标锁具的权限，不予授权。

例如，在该下一操作阶段中设置“用户C”可开锁“3号配送箱锁”，当收到针对“3号配送箱锁”的开锁请求后，若请求发起方为“用户C”，则生成控制指令，以用于开启“3号配送箱锁”。

在步骤140之后，即生成控制指令之后，利用该控制指令控制目标锁具打开。具体的，目标锁具的打开包括但不限于如下两种方式：

方式一：目标锁具与当前执行角色的执行终端建立近距离通信连接，例如建立蓝牙连接、NFC连接或WIFI连接等，服务器发送该控制指令至当前执行角色的执行终端，当前执行角色的执行终端在收到该控制指令后，具有开锁权限，于是，当前执行角色可通过执行终端上的APP、小程序或网页等方式控制目标锁具开锁。例如，执行终端的APP在收到该控制指令后，页面上的“开锁”图标由灰色不可点击状态变为可点击状态，当前执行角色点击“开锁”图标，APP生成开锁指令，通过近距离通信发给目标锁具，目标锁具收到开锁指令后开锁。

方式二：每一锁具内设有远传模块，锁具通过该远传模块可与服务器通信，服务器将该控制指令发给目标锁具的远传模块，目标锁具收到控制指令后开锁。

可以理解的，在上述方案中，基于预先生成的云操作票，使得各个授权执行角色能按照事务的发展顺序操作锁具，以适应其锁具操作场景，提高锁具操作的安全性，避免无关人员操作锁具。

前文提到，管理角色可对已生成的云操作票进行更改操作，在生成云操作票后的任一时间节点，请参照图2，该方法还包括如下步骤：

步骤210：接收角色更改指令，该角色更改指令包括对云操作票进行更改的目标操作阶段以及目标操作阶段的新授权执行角色。

步骤220：将云操作票中目标操作阶段的授权执行角色替换为该新授权执行角色。

在管理角色认为有必要更改云操作票的情况下，或者执行角色向管理角色提出更改请求且管理角色认为符合更改条件的情况下，管理角色通过管理终端向服务器发送角色更改指令，用于更改目标操作阶段的授权执行角色。在角色更改指令中包括对云操作票进行更改的目标操作阶段以及目标操作阶段的新授权执行角色，服务器收到该角色更改指令后，将云操作票中目标操作阶段的授权执行角色替换为该新授权执行角色，从而完成云操作票的更改，在更改云操作票后，服务器基于更改后的云操作票执行后续过程。

除此之外，在服务器内还可预设云操作票的智能调整逻辑，可智能对云操作票进行更改，以优化配送订单的完成效果。在步骤120之后，即发送下一操作阶段的操作指示信息至下一操作阶段的授权执行角色的执行终端之后，该方法还包括：判断第一时限内是否接收到该下一操作阶段的授权执行角色的执行终端发送的开锁请求，若未接收到，则服务器查询可替代该授权执行角色的目标执行角色，并发送该下一操作阶段的操作指示信息至目标执行角色的执行终端，以指示目标执行角色操作该下一操作阶段对应的目标锁具。

具体的，在云操作票的每一操作阶段可设置该操作阶段对应的第一时限，例如，第二个操作阶段的第一时限设置为15分钟，那么其对应的授权执行角色“配送员D”应当在15分钟内打开“3号链条锁”，当服务器检测到“配送员D”未在15分钟内打开“3号链条锁”时，查询可替代“配送员D”的其他配送员，并选出一个目标配送员，发送打开“3号链条锁”的操作指示信息至目标配送员的执行终端。

其中，服务器查询可替代该授权执行角色的目标执行角色的步骤包括：获取目标锁具预设位置范围内的至少一个待选执行角色的任务清单；根据至少一个待选执行角色的任务清单从至少一个待选执行角色中选出目标执行角色。在选出目标执行角色后，发送该下一操作阶段的操作指示信息至目标执行角色的执行终端。

其中，每一待选执行角色的任务清单中包括待选执行角色对应的多个待执行的配送任务，每一配送任务包括配送时限和配送地点，服务器根据每一待选执行角色的配送时限和配送地点计算每一待选执行角色在执行完所有待执行的配送任务后到达目标锁具的位置需耗费的最长时间，根据计算获得的多个最长时间选出时间最短的一个待选执行角色，作为目标执行角色。或者，服务器可根据每一待选执行角色的配送时限和配送地点确定可在第一时限内到达目标锁具所在位置的一个待选执行角色，作为目标执行角色。

基于上述实施例，服务器通过智能识别第一时限内目标锁具的开锁情况，动态调整云操作票中的授权执行角色，为配送订单合理分配授权执行角色。

本实施例下文以具体的应用实例对技术方案进行详细说明，该方案可任意用于N个用户协同对M个锁具进行操作的场景，其中，N和M为大于等于1的整数，且N和M在取值范围内可以任意取值。

实例一：快餐配送

第一步，用户B在商家A处购买了一份快餐，配送平台分配配送员C负责该订单的配送，商家A通过其执行终端向服务器发起操作票生成请求，该操作票生成请求包括商家A、用户B以及配送员C的信息，服务器收到操作票生成请求后，根据预设的锁具操作逻辑生成该笔订单对应的云操作票，在云操作票中设置了多个具有顺序的操作阶段，并设置了商家A、用户B以及配送员C应当在哪一操作阶段操作锁具。

图3示出了该实例中一种货架300的示意图，在货架300上设有多个配送箱310以及与每一配送箱310对应的链条锁320，在每一配送箱310上设有配送箱锁330，其中，配送箱锁330用于锁住配送箱310中的物品，链条锁320用于固定配送箱。

第二步，服务器根据云操作票中的第一个操作阶段，发送操作指示信息指示商家A：请商家A申请权限打开配送箱B的配送箱锁。商家A准备好快餐后，通过其执行终端向服务器发起配送箱B的配送箱锁的开锁请求，服务器根据该开锁请求校验其是否具有开启该配送箱锁的权限，若确定具有权限，则授权商家A可开锁配送箱B的配送箱锁，商家A开锁后，将快餐放入，然后上锁。此时，配送箱B的配送箱锁与2号链条锁同时上锁。

第三步，服务器在检测到商家A对应的操作阶段的操作完成反馈后，查询云操作票中的下一操作阶段，发送操作指示信息指示配送员C：商家A已放入快餐到配送箱B中，且已闭锁成功，请配送员C申请权限打开配送箱B对应的2号链条锁进行配送。

第四步，配送员C到达商家货架后，通过其执行终端向服务器发起2号链条锁的开锁请求，服务器根据该开锁请求校验其是否具有开启2号链条锁的权限，若确定具有权限，则授权配送员C可开锁2号链条锁。配送员C开锁后，取走配送箱B，并开始配送。

第五步，配送员C达到收件货架后，通过其执行终端向服务器申请权限打开用户B指定的收件货架上的3号链条锁，在授权通过后，开锁3号链条锁，并通过3号链条锁将该配送箱B锁定。

第六步，服务器查询下一操作阶段的授权执行角色，向用户B的执行终端发送操作指示信息，以提醒用户B及时取走快餐。在第六步后用户B可分别选择第七步或者第八步的方式进行取餐，在云操作票中设置不同选择分支所对应的后续操作阶段，服务器根据用户B的选择跳转至对应的下一操作阶段。

第七步，用户B在收到操作指示信息后，通过其执行终端向服务器申请权限打开该配送箱B，并取走配送箱B中的快餐，然后闭锁配送箱B的配送箱锁。之后跳转第十一步。

第八步，用户B在收到操作指示信息后，通过其执行终端向服务器申请权限打开锁定该配送箱B的3号链条锁，在授权通过后，开锁3号链条锁，并将该配送箱B带走。

第九步，在取走配送箱B后，用户B在规定时间内通过其执行终端向服务器申请权限打开该配送箱B的配送箱锁，在授权通过后，打开配送箱锁，取出其中的快餐，之后，将配送箱锁闭锁，服务器在检测到配送箱锁闭锁后，可自动分配收件货架上的空闲链条锁，向用户B的执行终端发送操作指示信息，指示用户B将配送箱B锁定在4号链条锁。

第十步，用户B将闭锁后的配送箱B送至收件货架，并通过其执行终端向服务器申请权限打开4号链条锁，在授权通过后，将配送箱B锁定在4号链条锁上。之后跳转第十一步。

第十一步，服务器在检测到上一操作阶段中指定锁具的操作完成反馈后，发送操作指示信息指示配送员C：用户B已取走快餐，请配送员C申请权限打开配送箱B对应的链条锁。

第十二步，配送员C到达该收件货架，通过执行终端申请权限打开指定的链条锁，在授权通过后，取走该配送箱B送回商家A的货架上。

第十三步，配送员C通过执行终端申请权限打开商家货架上指定的链条锁，在授权通过后，使用该指定的链条锁锁定配送箱B。

以上为一次完整的快餐配送的过程，在上述过程中，与该订单相关联的授权执行角色(包括商家A、配送员C以及用户B)均可使用APP登录云端，并查看当前订单对应的云操作票进行到哪一操作阶段，以了解该订单的实际状态。在对锁具进行操作时，服务器利用云操作票对各当前执行角色的开锁请求进行校验，并决定是否授权通过，如果申请开锁的当前执行角色并非本次操作阶段的授权执行角色，或者本次申请操作的锁具不是该授权执行角色在当前操作阶段对应的锁具，均无法开锁。

可以理解的，本实施例中的锁具控制方法并不限于快餐配送，任一配送相关的场景均可适用，比如还可用于快递包裹的配送。而且，中间的配送员不限于一个，也可以为多个。

在本实施例中，每一操作阶段的授权执行角色的数量可以为一个或者多个，例如，在快递包裹的配送时，可能存在多个配送员参与配送，因此，某些操作阶段可能设置多个授权执行角色，每一授权角色均具有操作锁具的权限。在授权执行角色的数量为多个的情况下，在步骤140中，若当前执行角色为该下一操作阶段的至少一个授权执行角色中的任一个时，可生成用于打开目标锁具的控制指令。

基于该实例一，本申请提供一种快餐配送系统，该系统包括：商家执行终端、至少一个配送执行终端、用户执行终端以及服务器，商家执行终端、配送执行终端以及用户执行终端均可通过网页、APP、小程序等方式访问服务器，商家执行终端、至少一个配送执行终端、用户执行终端以及服务器分别用于执行上述实例一中各自对应的步骤。

实例二：银行保险箱管理

第一步，用户A有一个贵重物品需要交给用户B，出于安全考虑，决定将该贵重物品放入银行保险箱中，该保险箱上设有锁具。用户A通过执行终端向服务器发起操作票生成请求，该操作票生成请求包括用户A和用户B的信息，服务器收到操作票生成请求后，根据预设的锁具操作逻辑生成该笔订单对应的云操作票，在云操作票中设置了多个具有顺序的操作阶段，并设置了用户A和用户B应当在哪一操作阶段操作锁具。

第二步，服务器根据云操作票中的第一个操作阶段，发送操作指示信息指示用户A：请用户A申请权限打开保险箱上的锁具，并将物品放入到保险箱中。

第三步，用户A通过其执行终端向服务器发起该锁具的开锁请求，服务器根据开锁请求校验其是否具有开启该锁具的权限，若具有权限，则授权通过，用户A可通过执行终端开锁该锁具，放入贵重物品，然后闭锁。

第四步，服务器在检测到上一操作阶段的操作完成反馈后，查询云操作票的下一操作阶段，获取下一操作阶段的授权执行角色“用户B”，向用户B发送操作指示信息，指示其前往开锁。

第五步，用户B到达保险箱处，通过其执行终端向服务器发起该锁具的开锁请求，服务器根据开锁请求校验其是否具有开启该锁具的权限，若具有权限，则授权通过，锁具打开，用户B可取出其中的贵重物品，然后闭锁。

本实施例所提供的基于云操作票的锁具控制方法，在云操作票中，将不同的授权执行角色以及不同锁具关联到不同的操作阶段中，各个授权执行角色需在对应的操作阶段操作锁具，且操作的结果又与下一操作阶段存在关联，例如，在上述实例二中，必须由用户A先将物品放入到保险箱中，之后才能进入用户B前去取件的阶段，如果用户B在收到操作指示信息之前向服务器申请权限打开保险箱上的锁具，则服务器无法授权其开锁，相同的，如果用户A在放入物品并闭锁成功后又重新申请权限打开该锁具，则服务器也无法授权其开锁，又或者，有其他的非相关用户申请权限打开该锁具，其并非云操作票中设置的可允许操作锁具的授权执行角色，则服务器更无法授权其开锁。云操作票在云端存储，对操作空间和时间有很强的兼容性，即不受空间和时间的限制；基于该云操作票，使得各个授权执行角色能按照事务的发展顺序操作锁具，以精准适应其锁具操作场景，提高锁具操作的安全性，一方面，避免无关人员操作锁具，另一方面，可以实现多用户协同操作锁具时的有序开锁，防止逻辑性解锁错误，避免出现快递等物品的丢失、损坏、污染或者泄密。

基于同一发明构思，本申请实施例还提供一种基于云操作票的锁具控制装置，请参照图4，该装置包括：执行角色查询模块410、操作指示下达模块420、开锁请求接收模块430以及开锁权限判定模块440。

其中，执行角色查询模块410，用于在检测到上一操作阶段的授权执行角色的操作完成反馈时，根据所述操作完成反馈查询预先生成的云操作票，以获取下一操作阶段的授权执行角色。

操作指示下达模块420，用于发送下一操作阶段的操作指示信息至所述下一操作阶段的授权执行角色的执行终端，以指示所述下一操作阶段的授权执行角色操作下一操作阶段对应的目标锁具。

开锁请求接收模块430，用于接收当前执行角色的执行终端针对所述目标锁具发起的开锁请求。

开锁权限判定模块440，用于判断所述当前执行角色是否为所述下一操作阶段的授权执行角色，若是，生成用于打开所述目标锁具的控制指令。

本申请实施例提供的基于云操作票的锁具控制装置，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法实施例中的相应内容。

图5示出了本申请实施例提供的服务器500的一种可能的结构。请参照图5，服务器500包括：处理器510、存储器520以及通信接口530，这些组件通过通信总线540和/或其他形式的连接机构(未示出)互连并相互通讯。

其中，存储器520包括一个或多个(图中仅示出一个)，其可以是，但不限于，随机存取存储器(Random Access Memory，简称RAM)，只读存储器(Read Only Memory，简称ROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，电可擦除可编程只读存储器(Electric Erasable Programmable Read-Only Memory，简称EEPROM)等。处理器510以及其他可能的组件可对存储器520进行访问，读和/或写其中的数据。

处理器510包括一个或多个(图中仅示出一个)，其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器510可以是通用处理器，包括中央处理器(CentralProcessing Unit，简称CPU)、微控制单元(Micro Controller Unit，简称MCU)、网络处理器(Network Processor，简称NP)或者其他常规处理器；还可以是专用处理器，包括数字信号处理器(Digital Signal Processor,简称DSP)、专用集成电路(Application SpecificIntegrated Circuits，简称ASIC)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

通信接口530包括一个或多个(图中仅示出一个)，可以用于和其他设备进行直接或间接地通信，以便进行数据的交互。通信接口530可以是以太网接口；可以是移动通信网络接口，例如3G、4G、5G网络的接口；还是可以是具有数据收发功能的其他类型的接口。

在存储器520中可以存储一个或多个计算机程序指令，处理器510可以读取并运行这些计算机程序指令，以实现本申请实施例提供的基于云操作票的锁具控制方法的步骤以及其他期望的功能。

可以理解，图5所示的结构仅为示意，服务器500还可以包括比图5中所示更多或者更少的组件，或者具有与图5所示不同的配置。图5中所示的各组件可以采用硬件、软件或其组合实现。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被计算机的处理器读取并运行时，执行本申请实施例提供的基于云操作票的锁具控制方法的步骤。例如，计算机可读存储介质可以实现为图5中服务器500中的存储器520。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (9)

1.一种基于云操作票的锁具控制方法，其特征在于，所述方法包括：

接收操作票生成请求，所述操作票生成请求包括至少一个授权执行角色的信息；

根据所述至少一个授权执行角色的信息和预设的锁具操作逻辑生成云操作票，所述云操作票包括多个具有设定顺序的操作阶段，每一操作阶段设置有允许操作锁具的授权执行角色和具体的锁具标识，每一操作阶段的所述锁具标识在多个锁具中进行选定；

当检测到上一操作阶段的授权执行角色的操作完成反馈时，根据所述操作完成反馈查询预先生成的所述云操作票，以获取下一操作阶段的授权执行角色；

发送下一操作阶段的操作指示信息至所述下一操作阶段的授权执行角色的执行终端，以指示所述下一操作阶段的授权执行角色操作下一操作阶段对应的目标锁具；

接收当前执行角色的执行终端针对所述目标锁具发起的开锁请求；

判断所述当前执行角色是否为所述下一操作阶段的授权执行角色，若是，生成用于打开所述目标锁具的控制指令。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收角色更改指令，所述角色更改指令包括对所述云操作票进行更改的目标操作阶段以及所述目标操作阶段的新授权执行角色；

将所述云操作票中目标操作阶段的授权执行角色替换为所述新授权执行角色。

3.根据权利要求1所述的方法，其特征在于，在发送下一操作阶段的操作指示信息至所述下一操作阶段的授权执行角色的执行终端之后，所述方法还包括：

若在第一时限内未接收到所述下一操作阶段的授权执行角色的执行终端发送的开锁请求，查询可替代的目标执行角色，并发送所述下一操作阶段的操作指示信息至所述目标执行角色的执行终端。

4.根据权利要求3所述的方法，其特征在于，所述查询可替代的目标执行角色，并发送所述下一操作阶段的操作指示信息至所述目标执行角色的执行终端，包括：

获取目标锁具预设位置范围内的至少一个待选执行角色的任务清单；

根据所述任务清单从所述至少一个待选执行角色中选出目标执行角色；

发送所述下一操作阶段的操作指示信息至所述目标执行角色的执行终端，以指示所述目标执行角色操作所述下一操作阶段对应的目标锁具。

5.根据权利要求1所述的方法，其特征在于，在生成用于打开所述目标锁具的控制指令之后，所述方法还包括：

发送所述控制指令至所述当前执行角色的执行终端，以使所述当前执行角色的执行终端通过与所述目标锁具建立的近距离通信连接控制所述目标锁具打开。

6.根据权利要求1所述的方法，其特征在于，所述目标锁具内设有远传模块，在生成用于打开所述目标锁具的控制指令之后，所述方法还包括：

发送所述控制指令至所述目标锁具的远传模块，以控制所述目标锁具打开。

7.一种基于云操作票的锁具控制装置，其特征在于，所述装置包括：

执行角色查询模块，用于在检测到上一操作阶段的授权执行角色的操作完成反馈时，根据所述操作完成反馈查询预先生成的云操作票，以获取下一操作阶段的授权执行角色；

操作指示下达模块，用于发送下一操作阶段的操作指示信息至所述下一操作阶段的授权执行角色的执行终端，以指示所述下一操作阶段的授权执行角色操作下一操作阶段对应的目标锁具；

开锁请求接收模块，用于接收当前执行角色的执行终端针对所述目标锁具发起的开锁请求；

开锁权限判定模块，用于判断所述当前执行角色是否为所述下一操作阶段的授权执行角色，若是，生成用于打开所述目标锁具的控制指令。

8.一种服务器，其特征在于，包括处理器以及存储器，所述存储器存储有计算机可读取指令，当所述计算机可读取指令由所述处理器执行时，运行如权利要求1-6任一项所述的方法。

9.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时运行如权利要求1-6任一项所述的方法。

Images