基于openid的门禁控制方法与流程

本发明涉及微信开门技术领域，具体涉及一种基于openid的门禁控制方法。

背景技术：

微信开门技术的出现，给予了人们极大的便利，使得人们可以不必随身携带传统的钥匙、门禁卡等物品，而仅利用安装有微信的智能手机即可实现诸如小区门、楼宇门、单元门甚至房间门等门禁的开启。特别地，由于微信开门技术是基于微信平台实施的，用户无需专门下载客户端程序，这减少了用户下载安装应用程序导致的流量开销和存储空间开销，使得用户的接受度较高，从而便于该技术的推广。

现有技术的微信开门实现方式中，当有用户通过微信扫描门禁二维码请求开门时，门禁服务器会判断该用户是否被门禁系统所授权，只有在用户被授权有对应门禁的开启权限时，门禁服务器才会控制相应的门禁开启。为了实现该判断，现有的做法是在门禁服务器上预先存储各个门禁的授权用户的信息。然而，由于一个小区通常包括多个小区大门、更多个楼宇大门或单元门等众多的门禁，每个门禁均对应有很多个有通行权的用户，这使得服务器上要预存的数据量很大，例如，对于每个大门的门禁，都需要预存至少整个小区的全部居民的信息，而对于每个单元门，则都需要预存至少对应单元内的全部居民的信息，因此服务器每次进行权限判断时均需要读取大类的数据，这使得服务器的负担居高不下。并且，由于这些数据都需要事先进行人工输入，输入的工作量巨大且容易出错，一旦出错就会影响的某些用户的正常出行。另外，现有技术中，如要预存用户的信息，通常是要获取用户的微信号，这容易造成用户信息的外泄。

技术实现要素：

基于上述现状，本发明的主要目的在于提供一种基于openid的门禁控制方法，能够明显简化服务器判断开门权限时读取的数据量，同时还有利于保护用户信息不外泄。

为实现上述目的，本发明采用的技术方案如下：

一种基于openid的门禁控制方法，所述方法通过门禁服务器进行开门控制，用户通过门禁公众号登录所述门禁服务器以进行操作，包括步骤：

s100、门禁服务器接收到用户通过微信扫描门禁二维码发送的开门请求信息；

s200、门禁服务器读取所述用户的openid和所述门禁二维码的二维码标识，并根据所述openid判断所述用户是否已在门禁公众号上以房主或家庭成员的名义绑定有房间，若是，则进入步骤s300；若否，则进入步骤s500；

s300、门禁服务器根据所述房间的标识确定所述用户的门禁开启权限范围，并基于所述二维码标识确定所述门禁二维码对应的门禁标识；

s400、门禁服务器判断所述门禁标识对应的门禁是否包含于所述门禁开启权限范围内，若是，则发送门禁开启指令控制所述门禁开启；若否，则进入步骤s500；

s500、门禁服务器根据所述openid判断所述用户是否具有对所述门禁标识对应的门禁的临时开启权限，并基于所述临时开启权限的判断结果控制所述门禁开启或不开启。

优选地，所述步骤s200中，门禁服务器在读取所述用户的openid和所述门禁二维码的二维码标识后，先判断门禁公众号是否已开通第三方用户数据对接的服务，然后基于判断的结果，分别采取向第三方用户数据服务器调取与所述openid对应的房间信息和/或查询本地数据库中记录的与所述openid对应的房间信息的方式，确定所述用户是否已在门禁公众号上以房主或家庭成员的名义绑定有房间。

优选地，所述门禁公众号已开通第三方用户数据对接的服务；

所述步骤s200中，门禁服务器利用所述用户的openid向第三方用户数据服务器调取与所述openid对应的房间信息；

若调取成功，则判断为所述用户已在门禁公众号上以房主或家庭成员的名义绑定有所述房间，之后进入步骤s300；

若未调取成功，则判断为所述用户未在门禁公众号上以房主或家庭成员的名义绑定有房间。

优选地，所述门禁公众号已开通第三方用户数据对接的服务；

所述步骤s200中，门禁服务器首先利用所述用户的openid向第三方用户数据服务器调取与所述openid对应的房间信息；

若调取成功，则判断为所述用户已在门禁公众号上以房主的名义绑定有所述房间，之后进入步骤s300；

若未调取成功，则判断为所述用户未在门禁公众号上以房主的名义绑定有房间；随后，门禁服务器再利用所述用户的openid查询本地数据库：

若本地数据库中存储有所述用户的openid和对应的房间，则判断为所述用户已在门禁公众号上以家庭成员的名义绑定有所述房间，之后进入步骤s300；

若本地数据库中未查到所述用户的openid或者所述用户的openid没有对应的房间，则判断为所述用户未在门禁公众号上以家庭成员的名义绑定有房间。

优选地，所述门禁公众号未开通第三方用户数据对接的服务；

所述步骤s200中，门禁服务器利用所述用户的openid查询本地数据库：

若本地数据库中存储有所述用户的openid和对应的房间，则判断为所述用户已在门禁公众号上以房主或家庭成员的名义绑定有所述房间，之后进入步骤s300；

若本地数据库中未查到所述用户的openid或者所述用户的openid没有对应的房间，则判断为所述用户未在门禁公众号上以房主或家庭成员的名义绑定有房间。

优选地，所述步骤s300中，门禁服务器根据所述房间的标识确定所述用户的门禁开启权限范围的方式为：将从小区外部到达所述房间所能经过的所有门禁的门禁开启权限一次性赋予所述用户。

优选地，所述步骤s400中，门禁服务器以无线通信的方式向所述门禁的控制器发送门禁开启指令。

优选地，所述步骤s200中，门禁服务器在判断所述用户是否已在门禁公众号上以房主或家庭成员的名义绑定有房间之前，先根据所述openid判断所述用户是否被设置为门禁所属小区的管理员，若是，则直接发送门禁开启指令控制所述门禁二维码对应的门禁开启。

优选地，门禁服务器上存储有临时用户开门权限数据表，其中记录有临时用户的openid、与所述临时用户关联的房间标识、以及所述临时用户被赋予的开门权限的有效期；

所述步骤s500中，门禁服务器根据所述openid查询所述临时用户开门权限数据表，如查询到所述openid，则基于所关联的房间标识和所述有效期判断所述用户是否具有所述门禁的临时开启权限。

优选地，所述临时用户开门权限数据表中记录的临时开门权限由所关联的房间的房主或家庭成员授予；

所述步骤s500中，门禁服务器基于所述临时开启权限控制所述门禁开启的同时，向授予所述临时开门权限的用户发送开门信息，所述开门信息包括开门时间和所述openid对应的用户信息。

本发明的门禁控制方法以用户的openid与房间的绑定关系来确定当前用户的门禁开启权限范围，进而确定其是否有开启对应门禁的权限，不需要具体存储每个门禁和每个用户的关联关系，能够明显减少数据输入的工作量和门禁服务器在工作过程中读取的数据量，既避免了数据输入时出错的几率，同时也减轻了门禁服务器的负担。另外，由于门禁服务器仅读取用户的openid，而不涉及用户的微信号，使得用户无需担心其微信号因使用门禁系统而被泄露，有利于保护用户的个人信息，提高门禁系统的用户接受度。

特别地，通过与第三方用户数据进行对接，能够极大地简化用户绑定房间的过程，提高用户的使用体验。同时，通过与第三方用户数据进行对接，还能够免除门禁服务器在本地进行数据存储和维护的需求，节省服务器的存储和运算开销。

附图说明

以下将参照附图对根据本发明的基于openid的门禁控制方法的优选实施方式进行描述。图中：

图1为根据本发明的一种优选实施方式的基于openid的门禁控制方法的流程图；

图2为图1中步骤s200的优选实施方式的流程图；

图3为根据本发明的另一种优选实施方式的基于openid的门禁控制方法的流程图。

具体实施方式

针对现有技术的微信开门方法中存在的前述问题，本发明提供了一种基于openid的门禁控制方法，能够明显简化服务器判断开门权限时读取的数据量，同时还有利于保护用户信息不外泄。本发明的门禁控制方法主要是根据用户在门禁公众号上的绑定房间情况判断其对相应的门禁是否具有开启权限，服务器读取的数据量小且不易出错。

本发明中所称的房间，通常应理解为房屋的最小产权单元，例如居民区中的一户房产，然而，在某些情况下，也可以理解为一个产权单元中的具体房间，例如写字楼中的一个产权单元中分隔出的多个房间之一。

本发明的基于openid的门禁控制方法通过门禁服务器进行开门控制，用户通过门禁公众号登录所述门禁服务器以进行操作。其中，以小区门禁系统为例，门禁公众号可以是一个小区专有的公众号，也可以是多个小区共用的公众号，并且，门禁服务器可以是独立的物理服务器，也可以是云服务器。

具体地，参见图1，本发明的基于openid的门禁控制方法包括步骤：

s100、门禁服务器接收到用户通过微信扫描门禁二维码(例如张贴在门禁旁边或者显示于门禁设备上)发送的开门请求信息；

s200、门禁服务器读取所述用户的openid和所述门禁二维码的二维码标识，并根据所述openid判断所述用户是否已在门禁公众号上以房主或家庭成员的名义绑定有房间，若是，则进入步骤s300；若否，则进入步骤s500；

s300、门禁服务器根据所述房间的标识确定所述用户的门禁开启权限范围，并基于所述二维码标识确定所述门禁二维码对应的门禁标识；

s400、门禁服务器判断所述门禁标识对应的门禁是否包含于所述门禁开启权限范围内，若是，则发送门禁开启指令控制所述门禁开启；若否，则进入步骤s500；

s500、门禁服务器根据所述openid判断所述用户是否具有对所述门禁标识对应的门禁的临时开启权限，并基于所述临时开启权限的判断结果控制所述门禁开启或不开启。

由于房主和家庭成员均是小区内相应房间的常住用户，二者在门禁开启权限方面的需求是相同的，因而门禁服务器可以不特意区分二者，只要与相应的房间之间存在绑定关系，即可基于房间的标识确定其门禁开启权限范围。例如，房间的标识可以包括楼栋号、单元号、楼层号等信息，基于对这些信息的合理编排，服务器很容易确定该房间的住户的日常出行需要经过哪些门禁；同样，门禁标识也可以包括楼栋号、单元号等，从而方便地识别出具体的门禁属于小区大门还是楼栋单元门等。

本发明的门禁控制方法以用户的openid与房间的绑定关系来确定当前用户的门禁开启权限范围，进而确定其是否有开启对应门禁的权限，不需要具体存储每个门禁和每个用户的关联关系，能够明显减少数据输入的工作量和门禁服务器在工作过程中读取的数据量，既避免了数据输入时出错的几率，同时也减轻了门禁服务器的负担。另外，由于门禁服务器仅读取用户的openid，而不涉及用户的微信号，使得用户无需担心其微信号因使用门禁系统而被泄露，有利于保护用户的个人信息，提高门禁系统的用户接受度。

本发明的门禁控制方法在具体应用时，用户可通过手机等移动终端登录微信，扫描相应的门禁二维码向门禁服务器发送开门请求，门禁服务器接收到开门请求后，利用用户的openid进行查询，以确定该用户的房间绑定情况，从而可快速得到查询结果，并确定是否为该用户开启门禁。如该用户的openid没有绑定房间，再判断其是否具有临时开启权限(例如物业或业主授权的临时访客权限等)，最终确定是否为该用户开启门禁。

现有技术中，房主和家庭成员(尤其是房主)与相应的房间的关联关系需要手工输入，并需要经审核后方能确认这种关系，这个输入的过程显然是费时费力的，尤其是在手机等移动终端上操作时更是如此，同时，审核工作通常也只能由人工(例如物业管理员等)来完成，难以做到随时输入随时审核的时效性，这在很大程度上会影响用户对于此类门禁系统的接受度。

针对上述情况，本发明率先考虑到利用相应小区住户的已有的有效数据，例如存储在第三方用户数据服务器上的数据，来简化甚至省略前述输入与审核过程。

其中，第三方用户数据服务器存储有例如小区物业部门开展其他业务(可称为第三方应用服务)时记录的与住户相关的信息，其中，第三方应用服务和门禁服务接入同一个公众号，即本发明中所称的门禁公众号(或者统称为物业公众号)，这些信息例如包括用户的openid、姓名、手机号、房产信息等。第三方用户数据服务器上存储的这些信息由第三方(或者物业部门)进行管理和维护，通常为经过物业部门审核过的数据，具有准确可信的特点；另外，这些信息往往还具有覆盖率高的特点，例如，物业部门收取物业费、代收水电煤气等生活费用时获取的住户相关信息，这些信息通常会覆盖整个小区的几乎全部房产，并且一般会包括房主个人信息和对应的房产信息，有时也会包括主要家庭成员(如房主配偶)的个人信息，并且主要家庭成员的个人信息也是与对应房产相关联的。更为重要的是，第三方用户数据服务器上的已有数据对于实施本发明的门禁控制方法的门禁系统来说是不可更改的，无论是用户端还是服务器端，都不能对其进行更改。

因此，如果能与第三方用户数据进行对接，那么在判断相应的用户是否绑定有房间的过程中，可以简单地利用第三方用户数据进行判断，如果第三方用户数据中包括该用户的个人信息和对应的房间，则门禁服务器可直接判定为该用户已绑定至其对应的房间，使得该用户根本无需手动输入信息进行房间绑定，即使是第一次使用相应的门禁系统。

可见，通过与第三方用户数据进行对接，能够极大地简化用户绑定房间的过程，提高用户的使用体验。同时，通过与第三方用户数据进行对接，还能够免除门禁服务器在本地进行数据存储和维护的需求，节省服务器的存储和运算开销。

举例来说，用户甲为某一小区的住户，并且是房主身份，该小区的门禁公众号开通了第三方用户数据对接服务，而用户甲此前办理其他业务时已经留存了个人信息和房产信息。于是，当该小区的门禁系统采用本发明的门禁控制方法时，用户甲只要进入门禁公众号，服务器就能通过第三方用户数据确定其房间绑定情况，进而确定该用户应当享有的门禁开启权限，由此达到的效果就是：该用户甲在不进行任何手动输入信息的情况下就能够自动获得其日常出行所必须的那一部分门禁的开启权限。

同时，本发明的门禁控制方法中，当用户访问门禁公众号时，门禁公众号会为用户分配一个专有的openid，门禁服务器接入该门禁公众号，因此能够获得用户的openid；在门禁公众号对接第三方用户数据的情况下，意味着该第三方用户数据服务器同样接入该门禁公众号，第三方用户数据服务器同样能够获得用户的openid，由于同一用户访问同一公众号时对应的openid是一致的，因此，门禁服务器可以利用用户的openid向第三方用户数据服务器请求调取用户的第三方信息，以便进行相应的判断。第三方用户数据服务器的一个示例为海纳服务器。

为此，优选地，如图2所示，所述步骤s200中，门禁服务器在读取所述用户的openid和所述门禁二维码的二维码标识后，先判断门禁公众号是否已开通第三方用户数据对接的服务，然后基于判断的结果，分别采取向第三方用户数据服务器调取与所述openid对应的房间信息和/或查询本地数据库中记录的与所述openid对应的房间信息的方式(具体分别详述如下)，确定所述用户是否已在门禁公众号上以房主或家庭成员的名义绑定有房间。

如果门禁公众号已开通第三方用户数据对接的服务，则可以存在如下两种情况：

(1)第三方用户数据服务器上同时存储有房主和家庭成员的个人信息及与房间的关联关系；

(2)第三方用户数据服务器上仅存储有房主的个人信息及与房间的关联关系，而家庭成员的个人信息及与房间的关联关系则存储在本地数据库中。

针对上述第(1)种情况，所述步骤s200中，门禁服务器仅需要利用所述用户的openid向第三方用户数据服务器调取与所述openid对应的房间信息；

若调取成功，则判断为所述用户已在门禁公众号上以房主或家庭成员的名义绑定有所述房间，之后进入步骤s300；

若未调取成功，例如第三方用户数据服务器中无该openid，或者有该openid但没有与之关联的房间，则判断为所述用户未在门禁公众号上以房主或家庭成员的名义绑定有房间，之后进入步骤s500。

当然，根据第三方用户数据服务器的权限开放程度，即是否接受用户数据的补充，在未调取成功的情况下，门禁服务器还可以引导用户前往第三方用户数据服务器的注册地址进行注册和输入信息，以便补充相关数据，从而在第三方用户数据服务器上进行房间绑定，而输入的数据可由第三方用户数据管理员(针对房主和家庭成员)或相应的房主(仅针对家庭成员)进行审核。这种情况例如适用于：如果当前用户为小区的实际住户(房主或家庭成员)，但此前未能在第三方用户数据服务器上存储必要信息，此时便可以在使用门禁系统时及时完成数据补充，从而不仅获得了门禁系统的应有权限，同时还完善了第三方用户数据服务器上的应有信息。

针对上述第(2)种情况，所述步骤s200中，门禁服务器可先后向第三方用户数据服务器调取与所述openid对应的房间信息(即先判断房主)、查询本地数据库中记录的与所述openid对应的房间信息(即后判断家庭成员)，来判断用户的房间绑定情况：

门禁服务器首先利用所述用户的openid向第三方用户数据服务器调取与所述openid对应的房间信息；

若调取成功，则判断为所述用户已在门禁公众号上以房主的名义绑定有所述房间，之后进入步骤s300；

若未调取成功，例如第三方用户数据服务器中无该openid，或者有该openid但没有与之关联的房间，则判断为所述用户未在门禁公众号上以房主的名义绑定有房间；随后，门禁服务器可再利用所述用户的openid查询本地数据库，并执行如下操作：

若本地数据库中存储有所述用户的openid和对应的房间，则判断为所述用户已在门禁公众号上以家庭成员的名义绑定有所述房间，之后进入步骤s300；

若本地数据库中未查到所述用户的openid或者所述用户的openid没有对应的房间，则判断为所述用户未在门禁公众号上以家庭成员的名义绑定有房间，之后进入步骤s500。

同样，对于身份为房主的用户，根据第三方用户数据服务器的权限开放程度，即是否接受用户数据的补充，在未调取成功的情况下，门禁服务器也可以引导用户(需用户选择是否为房主身份)前往第三方用户数据服务器的注册地址进行注册和输入信息，以便补充相关数据，从而在第三方用户数据服务器上进行房间绑定。而对于身份为家庭成员的用户，在未查询到相关数据的情况下，门禁服务器则可以引导用户(仍需要用户选择是否为家庭成员)在本地进行注册和数据输入，从而在本地数据库中实现房间绑定。

如果门禁公众号未开通第三方用户数据对接的服务，则门禁服务器需要在本地存储相关数据，例如房主的个人信息及房间信息、家庭成员的个人信息及关联的房间信息等，而这些数据存入门禁服务器的过程可以采用多种方式，包括但不限于：物业管理终端导入、房主个人手动输入等等。这种情况下，门禁服务器查阅本地数据，也很容易获知用户的绑定情况：例如，如果查询到用户的个人信息和对应间，则判定为用户已绑定至其对应房间；如果查询不到用户的个人信息，则判定为用户尚未绑定房间。

因此，在所述门禁公众号未开通第三方用户数据对接的服务的情况下，所述步骤s200中，门禁服务器仅利用所述用户的openid查询本地数据库，并执行如下操作：

若本地数据库中存储有所述用户的openid和对应的房间，则判断为所述用户已在门禁公众号上以房主或家庭成员的名义绑定有所述房间，之后进入步骤s300；

若本地数据库中未查到所述用户的openid或者所述用户的openid没有对应的房间，则判断为所述用户未在门禁公众号上以房主或家庭成员的名义绑定有房间。

本实施方式中，在判断为所述用户未在门禁公众号上以房主或家庭成员的名义绑定有房间的情况下，对于相应小区的实际住户(房主或家庭成员)，门禁服务器也可以引导用户(需要用户选择是否为房主或家庭成员)在本地进行注册和数据输入，从而在本地数据库中实现房间绑定，而输入的数据可由物业管理员(针对房主和家庭成员)或相应的房主(仅针对家庭成员)进行审核。

优选地，所述步骤s300中，门禁服务器根据所述房间的标识确定所述用户的门禁开启权限范围的方式为：将从小区外部到达所述房间所能经过的所有门禁的门禁开启权限一次性赋予所述用户。例如，门禁服务器可以根据房间标识确定其所属的楼栋和单元，进而可确定其应当具备的门禁开启权限，由此根本不需要如现有技术那样预先存储每个门禁的已授权用户。

优选地，所述步骤s400中，门禁服务器以无线通信的方式向所述门禁的控制器发送门禁开启指令。例如，门禁服务器可以是云服务器或物理服务器，各门禁控制器则优选以有线方式连接至临近的基站，门禁服务器与基站之间采用无线通信方式进行通信，从而一方面节省了大量通讯线路的部署成本，另一方面又有效避免了局部区域信号强度不足导致的门禁控制器通讯不畅的问题。

优选地，所述步骤s200中，门禁服务器在判断所述用户是否已在门禁公众号上以房主或家庭成员的名义绑定有房间之前，可以先根据所述openid判断所述用户是否被设置为门禁所属小区的管理员，若是，则直接发送门禁开启指令控制所述门禁二维码对应的门禁开启，如图3所示。也即，本发明的门禁控制方法中，还可以在系统中设置管理员这样的功能角色，使其具有例如开启整个小区所有门禁(当然不包括入户门)的权限，并且在系统中预先存储具有管理员身份的用户的openid与之对应，这样，当有用户扫码开门时，服务器首先判断该用户是否为管理员，若是，则直接控制该门禁开启，而不需要判断是否为该门禁的授权用户，也不需要判断其是否绑定房产等等，从而达到最为快捷地开启门禁的目的。

另外，考虑到外部用户(如业主的亲属、朋友等)来访时、以及业主之间互相串门时能够方便开启门禁的需求，本发明的门禁控制方法中，门禁服务器在判断用户没有绑定房间、或者尽管绑定有房间但所请求开启的门禁并不属于进出其房间所必须经过的门禁时，便可以执行步骤s500，也即，判断该用户是否具有对应门禁的临时开启权限，若是，则控制所述门禁开启，否则，不予开启。

由此，本发明的门禁控制方法的一个优选实施方式中，如图3所示，门禁服务器在判断用户的门禁开启权限时，首先判断用户是否为小区管理员，然后判断用户是否在公众号上绑定有房间以便根据房间确定可开启的门禁，最后判断用户是否具有对应门禁的临时开启权限。由此可提高判断的效率，减少判断的步骤，降低门禁服务器的工作负荷。

优选地，门禁服务器上存储有临时用户开门权限数据表，其中记录有临时用户的openid、与所述临时用户关联的房间标识(即该临时用户要访问的房间的表示)、以及所述临时用户被赋予的开门权限的有效期(例如半小时)。这种情况下，所述步骤s500中，门禁服务器根据所述openid查询所述临时用户开门权限数据表，如查询到所述openid，则基于所关联的房间标识和所述有效期判断所述用户是否具有所述门禁的临时开启权限，例如，一方面根据所关联的房间的标识确定当前门禁是否在应予开启之列，另一方面还要判断临时开启权限是否在规定的有效期内，只有这两个条件同时满足时才会控制门禁开启。

临时用户的临时开门权限可以由小区管理员授予，也可以由小区业主(包括房主和家庭成员)授予。

优选地，所述临时用户开门权限数据表中记录的临时开门权限由所关联的房间的房主或家庭成员(即业主)授予；此时，所述步骤s500中，门禁服务器基于所述临时开启权限控制所述门禁开启的同时，向授予所述临时开门权限的用户发送开门信息，所述开门信息包括开门时间和所述openid对应的用户信息。

也即，如果临时开门权限是由业主授予，则门禁服务器可以在控制门禁开启的同时，将基于该临时开门权限开门的事件(包括临时用户的身份信息、开启的门禁以及开门时间等)告知相应的业主，以确保业主能够在第一时间掌握相应信息。

小区管理员或业主(在此称为第一用户)向临时用户(在此称为第二用户)授予临时开门权限时，可以采用现有技术的各种合适方法。然而，优选地，第一用户可以在门禁公众号上请求生成临时访客授权二维码，门禁服务器接收到该请求时，向该第一用户返回临时访客授权二维码，其中，该二维码可以包括该第一用户的信息和该第一用户已绑定的房间信息，还可以包括临时开门权限的有效时间(例如规定的具体开门时间段、或者自临时开门权限正式生效后的一段时间内)，同时，门禁公众号将在临时用户开门权限数据表中记录这些信息；之后，第一用户可以将临时访客授权二维码分享或出示给第二用户，在第二用户识别或扫描该临时访客授权二维码时，门禁服务器将收到第二用户的信息(如openid等)，并记录到临时用户开门权限数据表中，与之前记录的信息形成一条完整记录。当第二用户扫描门禁二维码发送开门请求时，门禁服务器便可在临时用户开门权限数据表中找到第二用户的openid，从而确定其获得的临时用户开门权限，做出开启或不开启相应门禁的决定。

需要说明的是，本发明中的用户(包括第一用户、第二用户等)，指的是用户的手机等移动终端设备，更为确切地，还包括在该移动终端设备上处于登录状态的用户微信账号，例如，第一用户、第二用户分别为第一移动终端设备及其上处于登录状态的第一微信账号、第二移动终端设备及其上处于登录状态的第二微信账号。默认地，相应的移动终端设备(如手机)、该移动终端设备上登录的微信号、该移动终端设备关联的手机号和手持该移动终端设备的人应是统一的。

本领域的技术人员容易理解的是，在不冲突的前提下，上述各优选方案可以自由地组合、叠加。

应当理解，上述的实施方式仅是示例性的，而非限制性的，在不偏离本发明的基本原理的情况下，本领域的技术人员可以针对上述细节做出的各种明显的或等同的修改或替换，都将包含于本发明的权利要求范围内。