CN110021084B - 一种分布授权架构的扫码开门系统及开门方法 - Google Patents

Abstract

本发明涉及一种分布授权架构的扫码开门系统及开门方法，通过将实现鉴权的数据一部分设置在第三方服务器上，另一部分设置在门禁服务器上，在第三方服务器已存储的个人信息、用户openid、以及权限物信息之间的关联关系的基础上，权限物与权限之间的关联关系可以根据已有的逻辑一次性地门禁应用服务器上建立，即无需为了实现鉴权而在门禁应用服务器建立并维护完整的授权数据库，既可以提升门禁服务的部署速度，也可以提升用户信息的安全性。并且，在用户通过扫描发送的开门请求中与用户相关的信息是用户openid，而非直接的用户信息；在第三方服务器返回给门禁应用服务器的权限物信息同样如此，没有包含直接的用户信息，如此，进一步提升了用户的信息安全。

Description

一种分布授权架构的扫码开门系统及开门方法

技术领域

本发明涉及门禁控制技术领域，具体涉及一种分布授权架构的扫码开门系统及开门方法。

背景技术

为了方便使用门禁服务，现有的一种门禁方案可以使用手机微信即可开门，这种方案的基本步骤包括先期建立授权数据库，以及后期用户利用手机上安装的微信应用程序扫描开启小区门禁实现鉴权的步骤。

然而，现有门禁方案中，第一，需要管理员以及所有要用到该门禁服务的用户的配合在门禁服务器上逐条建立授权数据库，如此需要的时间也比较长，难以实现快速的部署。第二，社区随着互联网的深度应用，除了门禁服务外，还有其他物业服务同样采用类似的授权流程。如此，存在这样的场景，如果门禁服务是相对新近部署的服务，用户为了使用在此之前的社区服务，已重复多次配合完成相应的授权。此时，若仍采用相同的授权流程，则需要再次麻烦用户配合注册绑定等流程，这样，不仅部署时间长，还会遭遇用户的抵触情绪，这种情况会反过来会进一步拖累门禁服务的部署。第三，为了不同的服务而分别搭建个人信息与权限之间的数据库，也容易存在安全隐患。第四，当住户迁入或迁出等变动时，物业需要在多个服务平台增加或删除住户信息，管理上繁琐和麻烦。以上种种影响了门禁服务的部署，以及提升了用户信息的安全风险。

发明内容

本发明要解决的技术问题在于，针对现有技术的上述缺陷，提供一种分布授权架构的扫码开门系统，克服现有的技术中存在的部署效率低，且用户信息安全风险高的缺陷。

本发明解决其技术问题所采用的技术方案是：一种分布授权架构的扫码开门系统，其特征在于，包括：

门禁单元，包括电子锁具、以及电子锁具电连接的门禁控制器；以及

门禁应用服务器、第三方服务器，其中，

门禁应用服务器用于接收用户终端设备通过微信客户端扫描门禁二维码发送的开门请求，所述开门请求包括公众号标识，门禁标识以及用户openid；

门禁应用服务器还用于根据该公众号标识的数据接口向所述第三方服务器发送用户openid请求返回关联该用户openid的权限物信息；

所述第三方服务器用于根据用户openid查询已存储的个人信息、用户openid、以及权限物信息之间的关联关系，并向门禁应用服务器返回与该用户openid对应权限物信息；

门禁应用服务器还用于根据权限物信息查询已建立的权限物信息与权限之间的关联关系、核对对应用户openid的权限；

门禁应用服务器还用于若获取的权限与门禁标识对应的权限一致，则门禁应用服务器向门禁控制器发送开锁指令；

本发明还提供一种分布授权架构的扫码开门系统及开门方法，该方法包括包括:

步骤100：门禁应用服务器接收用户终端设备通过微信客户端扫描门禁二维码发送的开门请求，该开门请求包括公众号标识、门禁标识，以及用户openid；

步骤120：门禁应用服务器根据该公众号标识的数据接口向第三方服务器发送用户openid请求返回关联该用户openid的权限物信息；

步骤140：第三方服务器根据用户openid查询已存储的个人信息、用户openid、以及权限物信息之间的关联关系，并向门禁应用服务器返回与该用户openid对应权限物信息；

步骤160：门禁应用服务器根据权限物信息查询已建立的权限物信息与权限之间的关联关系、核对对应用户openid的权限；

步骤180：若获取的权限与门禁标识对应的权限一致，则门禁应用服务器向门禁控制器发送开锁指令。

本发明的有益效果在于，通过将实现鉴权的数据一部分设置在第三方服务器上，另一部分设置在门禁服务器上，如此形成分布授权的架构。具体的，在第三方服务器已存储的个人信息、用户openid、以及权限物信息之间的关联关系的基础上，权限物信息与权限之间的关联关系可以根据已有的逻辑一次性地门禁应用服务器上建立，即无需为了实现鉴权而在门禁应用服务器建立并维护完整的授权数据库，既可以提升门禁服务的部署速度，也可以提升用户信息的安全性。并且，在用户通过扫描发送的开门请求中与用户相关的信息是用户openid，而非直接的用户信息；在第三方服务器返回给门禁应用服务器的权限物信息同样如此，没有包含直接的用户信息，如此，进一步提升了用户的信息安全。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1是为发明分布授权架构的扫码开门系统的一实施例的架构示意图

图2为本发明分布授权架构的扫码开门方法第一实施例的流程示意图；

图3为本发明分布授权架构的扫码开门方法第二实施例的流程示意图；

图4为本发明分布授权架构的扫码开门方法第三实施例的流程示意图；

图5为本发明分布授权架构的扫码开门方法第四实施例的流程示意图；

图6为本发明分布授权架构的扫码开门方法第五实施例的流程示意图；

图7为本发明分布授权架构的扫码开门方法第六实施例的流程示意图；

图8为本发明分布授权架构的扫码开门方法第七实施例的流程示意图；

图9为本发明分布授权架构的扫码开门方法第八实施例的流程示意图；

图10为本发明分布授权架构的扫码开门方法第九实施例的流程示意图。

具体实施方式

现结合附图，对本发明的较佳实施例作详细说明。

如图1所示，本发明的分布授权架构的扫码开门系统的一实施例包括：

门禁单元，包括电子锁具、与电子锁具电连接的门禁控制器；

门禁应用服务器以及第三方服务器、微信服务器，预装有微信客户端的用户终端设备，其中，

门禁应用服务器用于接收用户终端设备通过微信客户端扫描门禁二维码发送的开门请求，所述开门请求包括公众号标识，门禁标识以及用户openid；

门禁应用服务器用于根据该公众号标识的数据接口向所述第三方服务器发送用户openid请求返回关联该用户openid的权限物信息；

所述第三方服务器用于根据用户openid查询已存储的个人信息、用户openid、以及权限物信息之间的关联关系，并向门禁应用服务器返回与该用户openid对应权限物信息；

门禁应用服务器还用于根据权限物信息查询已建立的权限物信息与权限之间的关联关系、核对对应用户openid的权限；

门禁应用服务器还用于若获取的权限与门禁标识对应的权限一致，则门禁应用服务器向门禁控制器发送开锁指令。

电子锁具是一种采用电力上锁或开锁的装置，例如通过电力驱动可动部件实现上锁和开锁的切换，常见的有电磁伸缩锁。门禁控制器用于控制电子锁具的动作，例如其主控板设有与电子锁具匹配的驱动电路或指令收发模块。

门禁应用服务器一般由服务商提供，例如微开互联科技。门禁应用服务器可以为云服务器，如此，可方便为不同的小区同时服务。通过与门禁控制器电连接或通讯连接可以达到远程控制门禁控制器的目的。

微信服务器是保障用户终端上微信客户端正常使用的网络平台，第三方服务器一般由腾讯的海纳社区平台或小区物业配置，用户终端设备可以为手机、平板电脑等便携终端，该便携终端可以安装并运行微信客户端，并具有用以扫描的扫描模块。

用户为权限物的权限人，例如业主为某一小区某单元某房产的权限人，根据已有的逻辑，他/她拥有该小区及楼栋单元的门禁权限。

用户openid是一种隐性标识,公众无法直接利用而接触到用户的信息，个人信息则属于公众可直接利用而接触到用户的信息。例如微信号、手机号属于个人信息。用户用微信号登陆微信公众号，微信平台为该微信号分配关联该微信公众号的openid则属于用户openid，公众无法利用该openid直接接触到用户。

用户扫描二维码时，若未关注公众号则跳转至关注页面；在用户第一次访问公众号时，微信服务器为用户分配一个关联该公众号的openid。

公众号配置文件中预先设立了对接第三方服务器的数据接口，携带openid向第三方服务器发出获取信息的请求。在该步骤中，门禁应用服务器仅接触到用户openid，如此了避免了暴露用户的个人信息。例如门禁应用服务器在仅有openid的情形下，无法向用户发起“加微信好友”的请求。

举一个例子，若一个小区有1000个房主，每个房主都在作为第三方服务器的海纳服务器注册并绑定房产信息，个人信息可以包括微信号和手机号，那么对于每一个房主，第三方服务器都将建立这样一条关联记录；

字段1	字段2	字段3	字段4
				微信号……	openid……	手机号……	权限物……

假设第三方服务器上存在这样一条记录；

字段1	字段2	字段3	字段4
				微信号用户A	openid用户A	手机号135……	星星小区1栋-102房

则利用字段2“openid用户A”查询，可以向门禁应用服务器返回“星星小区1栋-102房”这样的字符串。

权限物可以对应于小区房间、实验室、酒店房间等；小区房间可以用对应小区的大门，和楼栋单元大门的开门权限；实验室对应实验室的大门；酒店房间对应房间门；

在应用于小区门禁时，由于具体的房间与小区大门或小区门权限关系是固定的，因此这样关联关系表可以很快建立。

接着上面海纳服务器已认证用户A的例子，假设门禁应用服务器已建立关联关系表：

字段1	权限
		星星小区1栋-102房	1栋单元门、大门1、大门2
星星小区2栋-101房	2栋单元门、大门1、大门2

那么根据海纳服务器返回的“权限物1-102房”，可以查询到相应的权限，即核对了“openid用户A”的权限“1栋单元门、大门1、大门2”，换句话说“openid用户A”可以使用“1栋单元门、大门1、大门2”中的任何一个权限。

例如，openid用户A返回的权限包括1栋单元门、大门1、大门2，如果门禁标识对应的权限2栋单元门，则说明获取的权限与门禁标识对应的权限不一致，用户A最终无法开启2栋单元门。可以理解的是，若openid用户A返回的权限为空同样会判断为与门禁标识不一致。

本发明的有益效果在于，通过将实现鉴权的数据一部分设置在第三方服务器上，另一部分设置在门禁服务器上，如此形成分布授权的架构。具体的，在第三方服务器已存储的个人信息、用户openid、以及权限物信息之间的关联关系的基础上，权限物信息与权限之间的关联关系可以根据已有的逻辑一次性地门禁应用服务器上建立，即无需为了实现鉴权而在门禁应用服务器建立并维护完整的授权数据库，既可以提升门禁服务的部署速度，也可以提升用户信息的安全性。并且，在用户通过扫描发送的开门请求中与用户相关的信息是用户openid，而非直接的用户信息；在第三方服务器返回给门禁应用服务器的权限物信息同样如此，没有包含直接的用户信息，如此，进一步提升了用户的信息安全。

关于第三方服务器上已存储的个人信息、隐性标识、以及权限物信息之间的关联关系，这些关联关系的数据为小区物业部门开展其他业务时，在住户配合下存储的，这些数据由第三方(或者物业部门)进行管理和维护，具有准确、全面等特点，例如，物业部门收取物业费、代收水电煤气等生活费用时获取的住户相关信息，这些信息通常会覆盖整个小区的几乎全部房产，并且一般会包括房主个人信息、隐性标识、和对应的房产信息，有时也会包括主要家庭成员(如房主配偶)的个人信息，并且主要家庭成员的个人信息也是与对应房产相关联的。

可见，通过与第三方服务器的用户数据进行对接，能够省去用户为使用门禁服务而再次配合进行授权的过程，提高了用户的使用体验。同时，通过与第三方服务器的用户数据进行对接，还能够免除门禁应用服务器在本地进行数据存储和维护的需求，节省服务器的存储和运算开销。

举例来说，用户甲为某一小区的住户，并且是房主或家庭成员的身份，该小区的门禁服务开通了第三方用户数据对接服务，而用户甲此前办理其他业务时已经留存了个人信息、隐性标识(用户openid)和房产信息的关联关系。于是，用户甲进入门禁服务公众号时，就可以在不进行任何注册绑定的操作就可实现鉴权。

现有技术中，用户在进行使用门禁服务所需的鉴权时，总是需要先行手动输入家庭地址、个人信息并经审核后方能实现自身的绑定，相比之下，本发明的鉴权方法在快速性和操作便捷性等方面的优势是现有技术所无法比拟的，因此用户的接受度也更高，更易于推广普及。

关于门禁服务的分布授权架构，设第三方服务器上个人信息、用户openid、以及权限物信息之间的关联关系为第一关联关系，设门禁应用服务器上建立的权限物信息与权限之间的关联关系为第二关联关系，第一关联关系的核心在于需要认证并建立个人信息与权限物信息之间的关联关系，第一关联关系由于用户使用时间上先于门禁服务已建立，由此可以免去大多数用户或全部用户的再次认证，具体地，第一关联关系中的权限物信息与第二关联关系中的权限物信息一致的信息条数大致接近或等于第二关联关系中权限物信息的条数。也就是说在门禁应用服务器上事先已认证过的用户，在首次使用本发明的开门系统时，无需用户再次去认证。此外，由于第二关联关系的重点在于建立权限物信息与权限之间的关联关系，而这种关系的建立可以依据已知的逻辑一次性建立。总的来说，第一关联关系在门禁服务部署前已认证，第二关联关系可以无需用户的参与一次性建立，正是这样的分布授权架构才使得门禁服务的部署速度得以提升。

下面将对本发明的分布授权架构的扫码开门方法各实施例详细地阐述。

本发明提供一种分布授权架构的扫码开门方法，请参照图2，在本发明的第一实施例中，该分布授权架构的扫码开门方法包括：

步骤100：用户终端设备通过微信客户端扫描门禁二维码，向门禁应用服务器发送开门请求，该开门请求包括公众号标识、门禁标识，以及用户openid；

用户为权限物的权限人，例如业主为某一小区某单元某房产的权限人，他/她拥有该小区及楼栋单元的门禁权限。

用户终端设备一般指用户常用的手机，利用手机固有的功能或在手机上安装应用程序例如微信可以发送权限核对请求。

门禁应用服务器一般由服务商提供，例如微开互联科技。门禁应用服务器可以为云服务器，如此，可方便为不同的小区同时服务。通过与门禁控制器电连接或通讯连接可以达到远程控制门禁控制器的目的。

用户openid是一种隐性标识，公众无法直接利用而接触到用户的信息，个人信息则属于公众可直接利用而接触到用户的信息。例如微信号、手机号属于个人信息。用户用微信号登陆微信公众号，微信平台为该微信号分配关联该微信公众号的openid则属于隐性标识，公众无法利用该openid直接接触到用户。

优选地，用户扫描二维码时，若未关注公众号则跳转至关注页面；在用户第一次访问公众号时，微信服务器为用户分配一个关联该公众号的openid。

步骤120：门禁应用服务器根据该公众号标识的数据接口向第三方服务器发送用户openid请求返回关联该用户openid的权限物信息；然后微信服务器将开门请求发送至门禁应用服务器。

公众号配置文件中预先设立了对接第三方服务器的数据接口，携带openid向第三方服务器发出获取信息的请求。在该步骤中，门禁应用服务器仅接触到用户openid，如此了避免了暴露用户的个人信息。例如门禁应用服务器在仅有openid的情形下，无法向用户发起“加微信好友”的请求。

第三方服务器一般由腾讯的海纳社区平台或小区物业配置。举一个例子，若一个小区的有1000个房主，每个房主都在作为第三方服务器的海纳服务器注册并绑定房产信息，个人信息可以包括微信号和手机号，用户openid为openid，那么对于每一个房主，第三方服务器都将建立这样一条关联记录；

字段1	字段2	字段3	字段4
				微信号……	openid……	手机号……	权限物……

步骤140：第三方服务器根据用户openid查询已存储的个人信息、用户openid、以及权限物信息之间的关联关系，并向门禁应用服务器返回与该用户openid对应权限物信息；

假设第三方服务器上存在这样一条记录；

字段1	字段2	字段3	字段4
				微信号用户A	openid用户A	手机号135……	星星小区1栋-102房

则利用字段2“openid用户A”查询，可以返回“权限物1-102房”。

步骤160：门禁应用服务器根据权限物信息查询已建立的权限物信息与权限之间的关联关系、核对对应用户openid的权限；

权限物可以对应于小区房间、实验室、酒店房间等；小区房间可以用对应小区的大门，和楼栋单元大门的开门权限；实验室对应实验室的大门；酒店房间对应房间门；

在应用于小区门禁时，由于具体的房间与小区大门或小区门权限关系是固定的，因此这样关联关系表可以很快建立。

接着上面海纳服务器已认证用户A的例子，假设门禁应用服务器已建立关联关系表：

字段1	权限
		星星小区1栋-102房	1栋单元门、大门1、大门2
星星小区2栋-101房	2栋单元门、大门1、大门2

那么根据海纳服务器返回的“权限物1-102房”，可以查询到相应的权限，即核对了“openid用户A”的权限“1栋单元门、大门1、大门2”，换句话说“openid用户A”可以使用“1栋单元门、大门1、大门2”中的任何一个权限。

步骤180：若获取的权限与门禁标识对应的权限一致，则门禁应用服务器向门禁控制器发送开锁指令。

例如，openid用户A返回的权限包括1栋单元门、大门1、大门2，如果门禁标识对应的权限2栋单元门，则说明获取的权限与门禁标识对应的权限不一致，用户A最终无法开启2栋单元门。可以理解的是，若openid用户A返回的权限为空同样会判断为与门禁标识不一致。

具体的，门禁应用服务器上关于权限物与权限之间的关联表，可以由两个表组成，其中一个表是根据第三方服务器返回的权限物建立用户权限物表，另一个标识门禁安装完成时建立门禁表。

当用户开门时判断用户用户权限物表是否拥有门禁表对应门禁字段3和字段4、字段5的权限物判断权限，权限物根据id查询。用户开星星小区1栋大门需要在权限物表拥有星星小区和1栋字段值。用户开星星小区大门只需要在权限物表拥有星星小区的字段值。

用户权限物表示例：

字段1	字段2	字段3	字段4	字段5
					用户A	openid用户A	星星小区(id)	1栋(id)	102(id)
用户A	openid用户A	星星小区(id)	2栋(id)	101(id)
					用户B	openid用户B	星星小区(id)	2栋(id)	101(id)

门禁表示例：

字段1	字段2(门禁名称)	字段3	字段4	字段5
					门禁id1	星星小区东门	星星小区(id)
门禁id2	星星小区1栋大门	星星小区(id)	1栋(id)
					门禁id3	星星小区2栋大门	星星小区(id)	2栋(id)
门禁id3	星星小区2栋101门	星星小区(id)	2栋(id)	101(id)

请进一步参照图3，在本发明的第二实施例中，该方法还包括：

步骤200：若步骤160的判断结果为否，则判断用户是否已在第三方服务器注册；

若步骤160的判断结果为否，则说明有可能当前用户还未注册，为了方便用户顺利使用门禁服务，设置该判断流程，从而可以起到补充的作用。一般来说，一个小区内仅有少数用户尚未在第三方服务器认证，因此该用户在第三方服务器不会有记录；例如在小区购买的房子空置一段时间后或购买该小区的二手房而第一次入住小区的用户，因为未使用小区的任何物业服务，因此没有在第三方服务器注册或绑定房产。

步骤220：若步骤200的判断结果为是，门禁应用服务器向用户终端设备发送第三方服务器的绑定地址；

已注册但是权限与所要核对的权限不一致，说明用户或未绑定任何权限物，或绑定的权限物不正确。接着前面小区的情景，若用户A分别在1栋和2栋拥有房产，若一开始他/她仅绑定了1栋的房产，那么在想要进入2栋的单元门时需要预先绑定2栋的房产。通过给用户发送绑定地址可方便用户进行更正绑定或补充绑定。

步骤240：第三方服务器接收用户终端设备根据绑定地址发送的绑定请求，绑定请求包括个人信息、用户openid、权限物信息；

用户在第三方服务器注册时就已经关联了个人信息与用户openid信息；确认权限物的权限信息则需要认证个人信息，请求绑定请求是通过绑定个人信息与权限物信息，进而绑定用户openid与权限物信息。

步骤260：第三方服务器审核绑定请求；

可以将绑定请求转发给管理员，让管理员对绑定请求的内容进行核实、认证。例如手机号与具体的房产之间的绑定，管理员通过给用户的这个手机号打电话，要求用户提交其他必要的资料，或者根据备案的资料审核是否应该手机号与具体的房产绑定。

步骤280：审核是否通过；

如果管理员认为用户提供的个人信息与权限物信息不对应，则可以拒绝绑定，即相应的审核结果为不通过。手机号一般都实名验证，如果手机号的对应的用户名称，与房产的所有权人名称一致则通过审核。管理员通过向第三方服务器转发审核结果，以便第三方服务器进一步处理。

步骤300：第三方服务器根据绑定请求，建立个人信息、用户openid、权限物信息之间的关联关系；

审核通过后，则建立个人信息、用户openid、权限物信息之间的关联关系，方便应用门禁服务器进行调用。至此，通过应用门禁服务器的引导绑定，第三方服务器的绑定数据更为完整，如此可以为更广泛的用户服务。

优选地，还包括步骤320：若步骤280的判断结果为否，向门禁应用服务器或用户终端设备发送提示信息。

门禁应用服务器可以根据提示信息为用户作进一步地服务。例如告知用户不通过权限核对的具体原因或指引用户作进一步地工作；审核不通过，有可能是因为用户提交的权限物信息有错误；或者用户属于恶意绑定等。直接发给用户终端设备也方便用户知道权限核对的结果。

请进一步参照图4，在第二实施例的基础上，该方法的第三实施例还包括：

步骤340：若步骤200的判断结果为否，门禁应用服务器向用户终端设备发送第三方服务器的注册地址；

门禁应用服务器向用户终端设备发送第三方服务器的注册地址可以引导用户去第三方服务器注册，如此，还有利于使第三方服务器的注册数据更为完整。

步骤360：第三方服务器接收用户终端设备根据注册地址发送的注册请求，注册请求包括用户openid和个人信息；

用户为了进一步实现权限核对，需要配合向第三方服务器进行注册，以方便进一步的绑定权限物信息。

步骤380：第三方服务器根据注册请求，建立个人信息、用户openid之间的关联关系；

由于绑定用户openid和个人信息一般不涉及实质的权利，因此，第三方服务器可以自动建立个人信息、用户openid之间的关联关系。

步骤400：第三方服务器向用户终端设备发送第三方服务器的绑定地址；然后再跳转至步骤240。

绑定地址也可以直接由第三方服务器发送给用户终端设备，如此可以减少跳转流程；绑定地址可以通过网页跳转的形式完成。

进一步地，请进一步参照图5，在第二实施例的基础上，本发明的第四实施例中，

步骤120具体包括：门禁应用服务器根据该公众号标识的数据接口向第三方服务器发送用户openid请求返回关联该用户openid的权限物信息，以及个人信息；

请求返回的个人信息可以为手机号、姓名或身份证号，利用返回的个人信息可以方便核对用户是否已在第三方服务器完成注册。

步骤140具体包括：第三方服务器根据用户openid查询已存储的个人信息、用户openid、以及权限物信息之间的关联关系，并向门禁应用服务器返回与该用户openid对应权限物信息，以及个人信息标识；

为了保证用户隐私，在门禁应用服务器请求返回个人信息时，仅返回与该个人信息关联的个人信息标识。例如个人信息为11位的手机号，那么返回省略若干位数字的手机号，即将省略数字的手机号作为手机号的标识，具体，开头为135，尾号为3356的手机号的标识为135****3356。

步骤160具体包括：

步骤161：门禁应用服务器判断权限物信息的返回结果是否为空；若用户未绑定权限物，则对应权限物信息的返回结果为空。

步骤162：门禁应用服务器判断与权限信息对应的权限是否与门禁标识一致；若权限物信息不为空，则还需要核对权限物信息是否与门禁标识一致，才能开启正确的门禁。

步骤200具体包括：若步骤161的判断结果为是，则门禁应用服务器进一步判断个人信息的返回结果是否空，若个人信息的返回结果为空则确认用户未在第三方服务器注册，若个人信息的返回结果不为空则确认用户已在第三方服务器注册；

若个人信息为空，则说明个人信息和权限物信息均未空，这种情况应该属于用户尚未在第三方服务器注册。

请进一步参照图6，在第四实施例的基础上，本发明的第五实施例该还包括：

还包括：

步骤340：若步骤200的判断结果为个人信息标识的返回结果是空，门禁应用服务器向用户终端设备发送第三方服务器的注册地址；

门禁应用服务器向用户终端设备发送第三方服务器的注册地址可以引导用户去第三方服务器注册，如此，还有利于使第三方服务器的注册数据更为完整。

步骤360：第三方服务器接收用户终端设备根据注册地址发送的注册请求，注册请求包括用户openid和个人信息

用户为了进一步实现权限核对，需要配合向第三方服务器进行注册，以方便进一步的绑定权限物信息。

步骤380：第三方服务器根据注册请求，建立个人信息、用户openid之间的关联关系；

由于绑定用户openid和个人信息一般不涉及实质的权利，因此，第三方服务器可以自动建立个人信息、用户openid之间的关联关系。

步骤400：第三方服务器向用户终端设备发送第三方服务器的绑定地址；然后再跳转至步骤240。

绑定地址也可以直接由第三方服务器发送给用户终端设备，如此可以减少跳转流程；绑定地址可以通过网页跳转的形式完成。

请进一步参照图7，在第一实施例的基础上，本发明的第六实施例该还包括：

步骤120具体包括：门禁应用服务器根据该公众号标识的数据接口向第三方服务器发送用户openid请求返回关联该用户openid的权限物信息，以及个人信息；

请求返回的个人信息可以为手机号、姓名或身份证号，利用返回的个人信息可以方便核对用户是否已在第三方服务器完成注册；

步骤140具体包括：第三方服务器根据用户openid查询已存储的个人信息、用户openid、以及权限物信息之间的关联关系，并向门禁应用服务器返回与该用户openid对应权限物信息，以及个人信息；

为了保证用户隐私，在门禁应用服务器请求返回个人信息时，仅返回与该个人信息关联的个人信息标识。例如个人信息为11位的手机号，那么返回省略若干位数字的手机号，即将省略数字的手机号作为手机号的标识，具体，开头为135，尾号为3356的手机号的标识为135****3356。

步骤160具体包括：

步骤161：门禁应用服务器判断权限物信息的返回结果是否为空；若用户未绑定权限物，则对应权限物信息的返回结果为空。

步骤162：门禁应用服务器判断与权限信息对应的权限是否与门禁标识一致；若权限物信息不为空，则还需要核对权限物信息是否与门禁标识一致，才能开启正确的门禁。

步骤200具体包括：若步骤161的判断结果为是，则门禁应用服务器进一步判断个人信息的返回结果是否空，若个人信息的返回结果为空则确认用户未在第三方服务器注册，若个人信息的返回结果不为空则确认用户已在第三方服务器注册；若个人信息为空，则说明个人信息和权限物信息均未空，这种情况应该属于用户尚未在第三方服务器注册。

步骤420：若步骤200的判断结果为是，则门禁应用服务器进一步判断该用户openid是否绑定有权限；

为了方便提供门禁服务，一些临时访客无法在第三方服务器注册绑定，此时可通过关联已绑定并具有相应权限的用户为临时访客提供访客通行证，该通信证包括具体的开门权限。访客获颁访客通信证时，门禁应用服务器建立访客openid、权限之间的关联关系表。为了方便管理访客可，门禁应用服务器可以为访客openid分配一个内部的身份标识，并建立该身份标识与权限之间的关联关系表。

步骤440：若步骤420的判断结果为是，则门禁应用服务器进一步判断与用户openid绑定的权限是否与门禁标识一致；

通过设置核对步骤，可以保证各门禁被正确地开启。

步骤460：若步骤440的判断结果为是，门禁应用服务器向门禁控制器发送开锁指令；

请进一步参照图8，在第六实施例的基础上，本发明的第七实施例还包括：

步骤220：若步骤200的判断结果为否，门禁应用服务器向用户终端设备发送第三方服务器的绑定地址；

步骤240：第三方服务器接收用户终端设备根据绑定地址发送的绑定请求，绑定请求包括个人信息、用户openid、权限物信息；

步骤260：第三方服务器审核绑定请求；

步骤280：审核是否通过；

步骤300：第三方服务器根据绑定请求，建立个人信息、用户openid、权限物信息之间的关联关系；

请进一步参照图9，在第七实施例的基础上，本发明的第八实施例还包括：

步骤340：若步骤420的判断结果为否，门禁应用服务器向用户终端设备发送第三方服务器的注册地址；

门禁应用服务器向用户终端设备发送第三方服务器的注册地址可以引导用户去第三方服务器注册，如此，还有利于使第三方服务器的注册数据更为完整。

步骤360：第三方服务器接收用户终端设备根据注册地址向发送的注册请求，注册请求包括用户openid和个人信息；

用户为了进一步实现权限核对，需要配合向第三方服务器进行注册，以方便进一步的绑定权限物信息。

步骤380：第三方服务器根据注册请求，建立个人信息、用户openid之间的关联关系

由于绑定用户openid和个人信息一般不涉及实质的权利，因此，第三方服务器可以自动建立个人信息、用户openid之间的关联关系。

步骤400：第三方服务器向用户终端设备发送第三方服务器的绑定地址；然后，跳转至步骤240；

绑定地址也可以直接由第三方服务器发送给用户终端设备，如此可以减少跳转流程；绑定地址可以通过网页跳转的形式完成。

优选地，该方法还包括：

步骤480：若步骤440或步骤162的判断结果为否，门禁应用服务器向用户终端设备发送无开锁权限通知；

请进一步参照图10，在第一实施例的基础上，本发明的第九实施例的步骤180具体包括：门禁应用服务器向门禁控制器发送开锁指令，以及向用户终端设备发送已开锁通知。

应当理解的是，以上实施例仅用以说明本发明的技术方案，而非对其限制，对本领域技术人员来说，可以对上述实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而所有这些修改和替换，都应属于本发明所附权利要求的保护范围。

Claims (10)

1.一种分布授权架构的扫码开门系统，其特征在于，包括：

门禁单元，包括电子锁具、以及与电子锁具电连接的门禁控制器；

门禁应用服务器以及第三方服务器，其中，

门禁应用服务器用于接收用户终端设备通过微信客户端扫描门禁二维码发送的开门请求，所述开门请求包括公众号标识，门禁标识以及用户openid，其中，在用户第一次访问公众号时，微信服务器为用户分配一个关联该公众号的openid；

门禁应用服务器还用于根据该公众号标识的数据接口向所述第三方服务器发送用户openid请求返回关联该用户openid的权限物信息；

所述第三方服务器用于根据用户openid查询已存储的个人信息、用户openid、以及权限物信息之间的关联关系，并向门禁应用服务器返回与该用户openid对应权限物信息；

门禁应用服务器还用于根据权限物信息查询已建立的权限物信息与权限之间的关联关系、核对对应用户openid的权限；

门禁应用服务器还用于若获取的权限与门禁标识对应的权限一致，则门禁应用服务器向门禁控制器发送开锁指令。

2.一种分布授权架构的扫码开门方法，其特征在于，包括:

步骤100：门禁应用服务器接收用户终端设备通过微信客户端扫描门禁二维码发送的开门请求，该开门请求包括公众号标识、门禁标识，以及用户openid；

其中，在用户第一次访问公众号时，微信服务器为用户分配一个关联该公众号的openid；

步骤120：门禁应用服务器根据该公众号标识的数据接口向第三方服务器发送用户openid，请求返回关联该用户openid的权限物信息；

步骤140：第三方服务器根据用户openid查询已存储的个人信息、用户openid、以及权限物信息之间的关联关系，并向门禁应用服务器返回与该用户openid对应权限物信息；

步骤160：门禁应用服务器根据权限物信息查询已建立的权限物与权限之间的关联关系、核对对应用户openid的权限；

步骤180：若获取的权限与门禁标识对应的权限一致，则门禁应用服务器向门禁控制器发送开锁指令。

3.如权利要求2所述的分布授权架构的扫码开门方法，其特征在于，所述方法还包括：

步骤200：若步骤160的判断结果为否，则判断用户是否已在第三方服务器注册；

步骤220：若步骤200的判断结果为是，则门禁应用服务器向用户终端设备发送第三方服务器的绑定地址；

步骤240：第三方服务器接收用户终端设备根据绑定地址发送的绑定请求，绑定请求包括个人信息、用户openid、权限物信息；

步骤260：第三方服务器审核绑定请求；

步骤280：第三方服务器根据步骤260的审核结果判断审核是否通过；

步骤300：若步骤280的判断结果为是，则第三方服务器根据绑定请求，建立个人信息、用户openid、权限物信息之间的关联关系。

4.如权利要求3所述的分布授权架构的扫码开门方法，其特征在于，所述方法还包括：

步骤340：若步骤200的判断结果为否，则门禁应用服务器向用户终端设备发送第三方服务器的注册地址；

步骤360：第三方服务器接收用户终端设备根据注册地址发送的注册请求，注册请求包括用户openid和个人信息；

步骤380：第三方服务器根据注册请求，建立个人信息、用户openid之间的关联关系；

步骤400：第三方服务器向用户终端设备发送第三方服务器的绑定地址；然后再跳转至步骤240。

5.如权利要求3所述的分布授权架构的扫码开门方法，其特征在于，

步骤120具体包括：门禁应用服务器根据该公众号标识的数据接口向第三方服务器发送用户openid请求返回关联该用户openid的权限物信息，以及个人信息；

步骤140具体包括：

第三方服务器根据用户openid查询已存储的个人信息、用户openid、以及权限物信息之间的关联关系，并

向门禁应用服务器返回与该用户openid对应权限物信息，以及与该个人信息对应的个人信息标识；

步骤160具体包括：

步骤161：门禁应用服务器判断权限物信息的返回结果是否为空；

步骤162：门禁应用服务器判断与权限信息对应的权限是否与门禁标识一致；

步骤200具体包括：

若步骤161的判断结果为是，则门禁应用服务器进一步判断个人信息标识的返回结果是否空；

若个人信息标识的返回结果为空则确认用户未在第三方服务器注册；

若个人信息标识的返回结果不为空则确认用户已在第三方服务器注册。

6.如权利要求5所述的分布授权架构的扫码开门方法，其特征在于，所述方法还包括：

步骤340：若步骤200的判断结果为个人信息标识的返回结果是空，门禁应用服务器向用户终端设备发送第三方服务器的注册地址；

步骤360：第三方服务器接收用户终端设备根据注册地址发送的注册请求，注册请求包括用户openid和个人信息；

步骤380：第三方服务器根据注册请求，建立个人信息、用户openid之间的关联关系；

步骤400：第三方服务器向用户终端设备发送第三方服务器的绑定地址；然后再跳转至步骤240。

7.如权利要求2所述的分布授权架构的扫码开门方法，其特征在于，

步骤120具体包括：门禁应用服务器根据该公众号标识的数据接口向第三方服务器发送用户openid请求返回关联该用户openid的权限物信息，以及个人信息；

步骤140具体包括：第三方服务器根据用户openid查询已存储的个人信息、用户openid、以及权限物信息之间的关联关系，并向门禁应用服务器返回与该用户openid对应权限物信息，以及个人信息标识；

步骤160具体包括：

步骤161：门禁应用服务器判断权限物信息的返回结果是否为空；

步骤162：门禁应用服务器判断与权限信息对应的权限是否与门禁标识一致；

步骤200具体包括：若步骤161的判断结果为是，则门禁应用服务器进一步判断个人信息标识的返回结果是否空；

若个人信息的返回结果为空则确认用户未在第三方服务器注册；

若个人信息的返回结果不为空则确认用户已在第三方服务器注册；

步骤420：若步骤200的判断结果为是，则门禁应用服务器进一步判断该用户openid是否绑定有权限；

步骤440：若步骤420的判断结果为是，则门禁应用服务器进一步判断与用户openid绑定的权限是否与门禁标识一致；

步骤460：若步骤440的判断结果为是，门禁应用服务器向门禁控制器发送开锁指令。

8.如权利要求7所述的分布授权架构的扫码开门方法，其特征在于，所述方法还包括：

步骤220：若步骤200的判断结果为否，门禁应用服务器向用户终端设备发送第三方服务器的绑定地址；

步骤240：第三方服务器接收用户终端设备根据绑定地址发送的绑定请求，绑定请求包括个人信息、用户openid、权限物信息；

步骤260：第三方服务器审核绑定请求；

步骤280：审核是否通过；

步骤300：第三方服务器根据绑定请求，建立个人信息、用户openid、权限物信息之间的关联关系。

9.如权利要求8所述的分布授权架构的扫码开门方法，其特征在于，所述方法还包括：

步骤340：若步骤420的判断结果为否，门禁应用服务器向用户终端设备发送第三方服务器的注册地址；

步骤360：第三方服务器接收用户终端设备根据注册地址发送的注册请求，注册请求包括用户openid和个人信息；

步骤380：第三方服务器根据注册请求，建立个人信息、用户openid之间的关联关系；

步骤400：第三方服务器向用户终端设备发送第三方服务器的绑定地址；然后，跳转至步骤240。

10.如权利要求2所述的分布授权架构的扫码开门方法，其特征在于，

步骤180具体包括：门禁应用服务器向门禁控制器发送开锁指令，以及向用户终端设备发送已开锁通知。

Images