CN110458994A - 一种物业管理自发卡系统及方法 - Google Patents

Abstract

本发明公开了一种物业管理自发卡系统，包括安装在用户手机或计算机的业主端，所述业主端与物业管理平台网络互联，所述物业管理平台还通过网络与各个读卡门禁互联；当用户需要办理门卡时，通过所述业主端向物业管理平台申请，所述物业管理平台经过审核后确定门禁权限，用户再通过业主端选择对应的读卡门禁，然后将门卡在所述读卡门禁上进行刷卡注册，所述读卡门禁读入所述门卡的卡号，传输至所述物业管理平台进行信息绑定，完成自行发卡，为了增强安全性通常是进行两次注册刷卡。另外，本发明还公开了物业管理自发卡方法。

Description

一种物业管理自发卡系统及方法

技术领域

本发明涉及社区物联网技术领域，尤其涉及一种物业管理自发卡系统及方法。

背景技术

社区门禁卡的授权和发放通常是由社区物业客服人员进行人工办理，需要业主进行填表登记，然后再进行身份核对，才能设置门禁卡的权限，再发放给业主。这些工作显然增加了客服人员的工作量，完全可以减少这种重复性的劳动。另外，还有当业主的门禁卡遗失时，常常无法马上进入社区，需要去客服管理处登记授权，才能获取新的门禁卡，这样造成时间浪费和资源浪费，降低了效率，增加了人力成本。

发明内容

本发明主要解决的技术问题是提供一种物业管理自发卡系统及方法，解决现有技术中人工发卡存在的管理流程复杂、效率低、成本高的问题。

为解决上述技术问题，本发明采用的一个技术方案是提供一种物业管理自发卡系统，包括安装在用户手机或计算机的业主端，所述业主端与物业管理平台网络互联，所述物业管理平台还通过网络与各个读卡门禁互联；当需要办理门卡时，通过所述业主端向物业管理平台申请，所述物业管理平台经过审核后确定门禁权限，再通过业主端选择对应的读卡门禁，然后将门卡在所述读卡门禁上进行刷卡注册，所述读卡门禁读入所述门卡的卡号，传输至所述物业管理平台进行信息绑定，完成自行发卡。

在本发明物业管理自发卡系统另一实施例中，所述刷卡注册包括使用同一门卡两次在同一所述读卡门禁上进行刷卡，并且两次刷卡读入的卡号相同才能进行信息绑定。

在本发明物业管理自发卡系统另一实施例中，所述门卡包括IC卡、CPU卡或带有存储卡的身份证件。

在本发明物业管理自发卡系统另一实施例中，所述物业管理平台根据业主端选择的读卡门禁，向门禁工作站以MQTT协议的方式下发指令，所述指令中包括传入对应的读卡门禁的识别号和信息回调URL，所述门禁工作站就向对应识别号的读卡门禁下发读卡指令，而所述对卡门禁收到所述读卡指令后，就对临近的门卡进行读卡，将所述门卡的卡号信息读入到所述读卡门禁中，然后再将所述卡号信息和信息回调URL一同回传给门禁工作站和物业管理平台。

在本发明物业管理自发卡系统另一实施例中，当经过上述两次刷卡成功进行信息绑定后，所述物业管理平台就将所述卡号对应的授权门禁发送给门禁工作站进行存储，或者由对应的读卡门禁进行存储，当使用该门卡进行使用刷卡时，授权开门的权限则是由门禁工作站或对应的读卡门禁完成。

本发明还公开了一种物业管理自发卡方法，包括以下步骤：

填写信息，通过自发卡系统上填写申请信息，然后将所述申请信息提请到物业管理平台进行审核；确定权限，所述物业管理平台根据所述申请信息，确定自发卡对应的门禁权限；选择门禁，通过自发卡系统上选择自发卡的读卡门禁，对应所述读卡门禁的识别号传入到所述物业管理平台；刷卡绑定，使用门卡在所述读卡门禁上进行刷卡，所述门卡的卡号被所述读卡门禁读入并传输到所述物业管理平台进行信息绑定，完成自行发卡。

在本发明物业管理自发卡方法另一实施例中，在所述刷卡绑定步骤中，包括使用同一门卡两次在同一所述读卡门禁上进行刷卡，并且两次刷卡读入的卡号相同才能进行信息绑定。

在本发明物业管理自发卡方法另一实施例中，所述门卡包括IC卡、CPU卡或身份证卡。

在本发明物业管理自发卡方法另一实施例中，所述自发卡系统包括安装在手机的APP或者安装在计算机上的业主端，并且通过网络接入到所述物业管理平台。

在本发明物业管理自发卡方法另一实施例中，在所述刷卡绑定步骤中，还包括人脸识别，通过业主端对申请人进行拍照，得到的照片信息随卡号同步存入到物业管理平台中进行信息绑定。

本发明的有益效果是：本发明公开了一种物业管理自发卡系统，包括安装在用户手机或计算机的业主端，所述业主端与物业管理平台网络互联，所述物业管理平台还通过网络与各个读卡门禁互联；当用户需要办理门卡时，通过所述业主端向物业管理平台申请，所述物业管理平台经过审核后确定门禁权限，用户再通过业主端选择对应的读卡门禁，然后将门卡在所述读卡门禁上进行刷卡注册，所述读卡门禁读入所述门卡的卡号，传输至所述物业管理平台进行信息绑定，完成自行发卡，为了增强安全性通常是进行两次注册刷卡。本发明替代了人工开卡，把空间的往返移动办卡集中到了本系统上，对应的发卡记录、开门记录可以实现即时记录上传、云端共享信息等。有效节省了用户时间，解决人工重复性工作和用户来回奔波不能及时进入园区等的问题。另外，本发明还公开了物业管理自发卡方法。

附图说明

图1是物业综合管理系统一实施例的的组成框图；

图2是物业管理对讲系统一实施例的组成框图；

图3是物业管理对讲系统一实施例中消息类型的说明图；

图4是物业管理对讲系统一实施例中呼叫流程图；

图5是物业管理对讲系统一实施例中门口机/围墙机与房间对讲建立流程图；

图6是物业管理报事系统一实施例中报事处理流程图；

图7是物业管理自发卡系统一实施例的组成图；

图8是物业管理自发卡系统另一实施例中的两次刷卡绑定的流程图；

图9是物业管理自发卡系统另一实施例中的读卡门禁操作流程图；

图10是物业管理自发卡系统另一实施例中的通过设置密码进行刷卡绑定的流程图；

图11是物业管理自发卡方法一实施例的流程图；

图12是物业管理自发卡方法另一实施例中的两次注册流程图；

图13是业主登录管理系统一实施例的登录流程图；

图14是物业登录管理系统一实施例的登录流程图；

图15是物业登录管理系统一实施例的人脸信息采集流程图；

图16是门禁管理系统一实施例的蓝牙开门流程图；

图17是访客管理系统一实施例的访客登记和授权流程图；

图18是云瞳监控系统一实施例的运行流程图；

图19是软对讲管理系统一实施例的操作流程图；

图20是物业管理业主端一实施例的蓝牙模块开门流程图；

图21是物业管理业主端一实施例的人脸录入模块工作流程图；

图22是物业管理业主端一实施例的智能家居管理模块组成示意图。

具体实施方式

为了便于理解本发明，下面结合附图和具体实施例，对本发明进行更详细的说明。附图中给出了本发明的较佳的实施例。但是，本发明可以以许多不同的形式来实现，并不限于本说明书所描述的实施例。相反地，提供这些实施例的目的是使对本发明的公开内容的理解更加透彻全面。

需要说明的是，除非另有定义，本说明书所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。在本发明的说明书中所使用的术语只是为了描述具体的实施例的目的，不是用于限制本发明。本说明书所使用的术语“和/或”包括一个或多个相关的所列项目的任意的和所有的组合。

图1显示了小区物业综合管理系统的组成框图实施例。在图1中，该小区物业综合管理系统10包括物业管理业主端系统11、物业管理物业端系统12、物业管理报事系统13和物业管理对讲系统14。

对于物业管理业主端系统11，就是为小区的业主用户提供一个基于智能手机或计算机的管理系统，通过该业主端系统可以接入物业管理平台，依此提升业主住户的用户体验，使得物业为业主的服务能够更加快捷高效。后文中的业主端包括业主用户使用的智能手机或计算机，以及安装其中的该物业管理业主端系统，因此后文中涉及到业主端的功能对应也是由物业管理业主端系统的功能。

与之类似，物业管理物业端系统12是为小区的物业人员提供一个基于智能手机或计算机的管理系统，通过物业端系统可以接入物业管理平台，依此可以大大加强物业人员的服务管理水平，提高服务的精准度和高时效。后文中的物业端包括物业管理人员使用的智能手机或计算机，以及安装其中的该物业管理物业端系统，因此后文中涉及到物业端的功能对应也是由物业管理物业端系统的功能。

物业管理报事系统13和物业管理对讲系统14则进一步属于物业管理中的业务范畴，通过物业管理报事系统物业管理人员对各种事件管理的流程化管理水平，可以增强业主参与物业监督管理的参与度,提高报事的效率和处理能力。物业管理对讲系统14则可以实现跨多个平台之间的音频和视频对讲，并且还可以对门禁进行控制，大大方便的业主住户进出小区的便利性，并且安全性也能够得到充分保障。以下将对这些系统详细举例说明。

优选的，对于物业管理对讲系统14而言，包括业主端、物业端、门口机、室内机和/或围墙机，均可接入到物业管理平台，在其中任意两个设备之间通过网络互连能够进行音频和/或视频对讲，以及实现门禁控制、报事处理和对讲记录。主要是基于各种接入网络，包括局域网、互联网、4G移动通信网、5G移动通信网、WIFI网络将小区中的多种门禁设备，如设置在小区出入口的围墙机、设置在各楼道单元门口的门口机、设置在业主室内的室内机，这些门禁设备不仅具有门禁功能，还具有语音通话功能、视频显示功能、异常报警功能。进一步的，本发明中还通过网络将物业管理平台使用的客服端(包括客服人员使用的计算机或智能手机以及安装其中的应用软件系统)、物业人员使用的物业端(包括物业人员使用的智能手机以及安装其中的物业管理物业端系统)、业主使用的业主端(包括业主使用的个人智能手机以及安装其中的物业管理业主端系统)和室内机、门口机和围墙机互联起来。

优选的，所述业主端、物业端、门口机、室内机和围墙机均可接入公众互联网络而接入物业管理平台，通过公众互联网络实现对讲和门禁控制。

优选的，所述业主端、物业端均可以接入公众互联网络而接入物业管理平台，门口机、室内机和围墙机通过局域网络接入物业管理平台，实现对讲和门禁控制(参考图7所示实施例)。通过这种方式可以兼容早期基于局域网络建成的对讲系统，只是这里的物业管理平台的作用类似网关的作用，虽然不能实现对讲和门禁通过网络数据的直接互通和控制，但是可以通过网关建立起网络联系，能够对讲和门禁控制，实现了不同系统之间的相互兼容。

优选的，如图2所示，在本发明所述的物业管理对讲系统14中，包含了视频对讲模块141、门禁控制模块142、工单报事模块143、对话记录模块144。所述视频对讲模块141能够在多种设备和终端之间进行可视对讲通话；所述门禁控制模块142则是提供了在多种设备和终端的对讲过程中加入了门禁控制功能；工单报事模块143主要是为物业管理和服务人员提供了在多种设备和终端之间的对讲过程中进行工单记录；对讲记录模块144用于记录在多种设备和终端之间所产生的对讲记录。

优选的，这里的门禁控制模块142包括了远程控制门禁、下发指令至门口机和围墙机打开门禁、门禁开启记录等模式。其中，远程控制门禁是指客服端、物业端、业主端、室内机在对讲过程中决定要开启门禁的时候，通过互联网发送指令至远程控制门禁或门口机打开门禁，同时记录本次开门。

进一步的，在业主端操作进行对讲开门时，因门禁存在接入到互联网的联网门禁，或者是没有接入到互联网的非联网门禁，物业管理对讲系统根据门口机的位置信息，同时向系统网络和门口机发送开门信号，分别对应联网开门和非联网开门，其中联网开门是根据门口机的位置信息通过系统调用远程开门接口进行开门，非联网开门则是给门口机连接的门锁发送一个电信号实现开门。其中，一键开门属于非联网开门，是指通过业主端在无需对讲状态下进行电信号开门，可以直接控制门禁进行开门，属于不确定开门门禁，由系统程序自行对最近、信号最强的门禁进行逻辑匹配并开门。而对讲开门通常是双方已连接通信，可实时传输开门信号，并只能打开与之对讲门口机关联的门禁。可见，这是实现了对两种不同开门方式(联网开门和非联网开门)的兼容，因此可以适用于多种物业小区的门禁系统建造或改造。

进一步的，联网开门主要就是通过业主端通过网络将开门请求信号发送给物业管理对讲系统，物业管理对讲系统接收到该开门请求信号后，进行审核鉴权，确认该开门请求信号权限正确后，将向对应的门禁通过网络发送开门指令，而该门禁收到来自物业管理对讲系统的开门指令后打开门锁。

进一步的，对于非联网开门业主端也可以通过网络将开门请求信号发送给物业管理对讲系统，物业管理对讲系统接收到该开门请求信号后，进行审核鉴权，确认该开门请求信号权限正确后，由于对应的门禁没有接入互联网，而是由门禁工作站进行控制，这时物业管理对讲系统将向门禁工作站发送对应的开门指令，门禁工作站与各个门禁是电连接，因此通过电信号控制，即可向对应的门禁发出开门的电信号进行开门。

由此可见，本发明中的物业管理对讲系统不仅是实现多方的通话和视频交流，还可以在这种交流中进行控制和管理，以及对该对讲过程本身的记录。例如对门禁的控制，在视频通话中对访客身份确认后，则可以启动开启门禁的功能。

物业管理人员通过物业端对讲还可以进行工单记录，这样使得物业管理更加灵活高效和增强可控性。本发明所述的物业管理物业端系统中还包括与物业管理对讲系统相关联，其中工单报事模块包括了报事记录、图片截取能、报事记录关联对讲记录。

优选的，报事记录是指在对讲通话过程中，出现报事工单入口，可填写并保存报事表单(包含图片截取)，然后生成报事记录识别号。

优选的，在通话结束后，生成通话记录识别号，同时关闭报事工单入口，但是工单已打开的情况，不受影响，仍然可以提交本次报事。

优选的，对于物业管理对讲系统应全过程监听报事记录识别号、通话记录识别号，若两者都有有效值时，将本次通话记录与报事记录进行关联。

优选的，物业管理对讲系统在对讲过程中决定要将事件记录下来，可以进行信息填写、图片截取，将工单上报，同时系统将本次工单与通话记录关联在一起，以便于查询、追溯。该过程包括：通话接通前，通话记录识别号与报事记录识别号都设为空值；通话过程中，提交报事记录，保存报事记录识别号；通话结束后，保存通话记录识别号；全过程监听报事记录识别号、通话记录识别号，若两者都有值时，将本次通话记录与报事记录关联。

本发明所述的物业管理对讲系统中，视频对讲模块包括了呼叫信息推送、忙音推送、接听回馈推送、连通音视频流等接续过程，作为物业管理对讲系统的核心模块，提供音视频对讲功能。

优选的，对讲通话操作的接续状态包括：

对于呼叫方：主要有呼叫等待、接通两个状态，其中，呼叫等待时，只有一个取消功能；接通状态时，有静音、挂断、切换前后置摄像头功能。

对于接听方：主要有等待接听、接通两个状态，其中，等待接听时，有拒绝、挂断两个功能；接通状态时，有静音、挂断、切换前后置摄像头、门口机开门功能。

优选的，在视频对讲接续过程中，为了简化流程，制定了较少的状态消息也能满足接续需求。如图3所示，接续过程及对应状态消息包括：当主动呼叫门口机、围墙机或轮呼客服端时，呼叫等待状态对应的消息类型msgType代码为1，呼叫过程中主动挂断取消呼叫对应的消息类型msgType代码为2，对方接听后挂断对应的消息类型msgType代码为3，对方拒绝接听的消息类型msgType代码为4，对方接听对应的消息类型msgType代码为5，对方占线忙对应的消息类型msgType代码为6。进一步的，如果在视频对讲中包括对门禁的操作，则有对讲过程中开门对应的消息类型msgType代码为7，对讲过程中开门成功对应的消息类型msgType代码为8。

进一步优选的，如图4所示，该对讲的呼叫接续过程包括：当主动发出实时通信呼叫时，主呼方发出呼叫后就进入了呼叫等待状态，如果这时取消呼叫，则向系统发出消息类型msgType代码为2；而当呼叫接通后，可以进行静音操作，当有前后两个摄像头时，还可以对摄像头进行前后切换，通话后挂断，则向系统发出消息类型msgType代码为3。在通话过程中，对方主动挂断，则向系统发出消息类型msgType代码为3。在呼叫过程中，对方始终未接听或者说是对方拒绝接听，则向系统发出消息类型msgType代码为4。在呼叫过程中，对方处于在线状态，则向系统发出消息类型msgType代码为6。

优选的，从图4中还可以看出，在发起呼叫时，发送的消息还包括设备类型，如业主端或物业端的操作系统为iOS或Android，或者是室内机或门口机；选择是视频对讲还是语音对讲；当是物业端时，还可以进行角色选择，如安管主任、门岗、项目经理、工程、业主、门口机；可以输入姓名，房间号，手机号，门口机所在位置(区分是业主传来的位置信息还是物业人员传来的位置信息)，用户类型(包括室内机、业主端、物业端)。

进一步优选的，如图5所示，当在门口机或围墙机呼叫业主房号时，首先是该门口机或围墙机通过网络登录物业管理对讲系统，如果登录失败则重新登录。若登录成功以后，在门口机服务端创建一个该项目的虚拟房间，则发起对讲，如果发起对讲失败则重新创建该虚拟房间，发起对讲成功以后则随机发送IM(Invite Message,邀请加入消息)消息给在业主端或物业端。若业主端或物业端接听，则点击接听加入房间，若成功加入该房间则可以进行对讲，对讲结束后挂断即结束。若业主端或物业端未接听或拒接，则对讲结束；若业主端或物业端加入房间失败，则对讲结束。对讲结束后，对讲信息记录将在物业管理对讲系统存储。

进一步的，在业主端、客服端、物业端相互之间对讲，则可以直接通过对讲记录或在线人员列表呼出即可，在对讲接听状态下可以进行开门。

通过该对讲系统，可以在以下场景中进行对讲应用：

优选的，当访客呼叫业主远程开门时，需要业主确定来访人员并开门进入，该过程包括业主接听门口机呼叫，与访客对讲、远程开门，主要是在围墙机、门口机、室内机和业主端之间建立对讲接续流程。

优选的，这里可用业主端手机代替室内机，访客可通过门口机向业主发起开门申请，业主手机收到开门申请时，可随时随地与访客进行可视通话，住户确认后可远程开启单元门的门口机。

优选的，该系统可实现视频通话及语音电话；当住户网络信号不好或者住户视频通话未及时接通时，会自动切换到语音电话。双向通话灵活切换，第一时间解决来访问题。

优选的，当访客呼叫客服端时，主要是访客无法联系到业主时，需要咨询客服端帮忙联系业主和开门。访客使用门口机呼叫客服端，客服端核实访客信息和开门，主要是在围墙机、门口机和客服端之间建立对讲接续流程。

优选的，当业主呼叫另一业主时，例如业主A拜访另一单元楼号的业主B，需要进入另一单元楼，这样在门口机、室内机、第一业主端和第二业主端之间的远程开门。

优选的，当门口机查看监控时，例如访客进入小区后，业主想要确定访客是否已经到达楼下单元门口时，这就需要在门口机、业主端之间进行远程开门。

优选的，当业主呼叫客服时，例如当业主有事要联系物业客服时，业主可以使用业主端或室内机一键呼叫客服端，这就需要在业主端、室内机和客服端之间进行一键呼叫，当业主端对客服端进行一键呼叫时，客服人员已在客服端配置到客服人员列表中，呼叫时无需选择呼叫哪一位客服人员，而是轮呼已完成列表配置的客服人员。

优选的，当有任务调度时，例如物业人员需要协调人员完成物业工作或远程可视沟通，可以使用物业端可视对讲与其他物业人员实时视频对讲，主要是在物业端、客服端之间建立对讲。该应用与物业管理物业端系统对应关联。

优选的，当有紧急事故时，例如物业人员遇到紧急情况需要联系业主，如漏水或失火，可使用物业端呼叫对应房号的业主端，主要是在物业端、客服端和业主端建立云对讲。

优选的，当有客服反馈时，例如物业人员向业主进行客服反馈征集时，物业人员可通过对讲呼叫业主端，主要是在物业端、客服端和业主端建立云对讲。

优选的，对于工程人员，当有工程配置时，例如门口机初始化时在设备端操作较为复杂，工程人员通过物业端扫描设备端二维码，配置设备信息并提交到系统，完成设备信息配置，主要是在物业端之间建立云对讲。

通过以上物业管理对讲系统，可以为楼宇新/旧实时音视频对讲提供整体云对讲系统解决方案及实施部署，可进行访客、业主、物业管理人员、工程、客服等多场景互动进行实时音视频对讲。该系统支持跨平台，包括计算机、具有不同操作系统的智能手机、平板、门口机、围墙机、其他安卓系统终端之间实现对讲通信，能够进行多品牌接入，实现一套对讲多终端适配。另外，该系统可实现提供打包成SDK方式供第三方接入集成并提供技术解决方案。相较于传统楼宇对讲方式布线少、简单，无须单独安装室内对讲机，从而降低维护成本。

进一步的，为了明确业主和物业报事处理工作流程，解决报事难，不能实时解决和信息共享等问题，确保用户所报事得以快速有效解决，并具有对所报事具有进度跟踪功能，建立了物业管理报事系统。

优选的，在该物业管理报事系统中包括基于物业管理平台，通过网络与物业端、业主端、报警设备和其他来源进行网络互联，由此可以接收多种途径的报事，包括线上业主报事、物业管理报事、设备自动告警报事(如周界、云瞳、机房)、视频巡检报事、门禁报事等。

优选的，物业管理平台负责调度、分配下发、跟进报事进度的情况。物业端提供物业人员使用的手机应用，可提供物业人员实时接收、及时处理报事事件与进度的应用端；业主端提供业主下载安装使用的应用，其中的报事报修模块提供业主随时随地，第一时间拍照、上传视频，填写报事报修内容以及紧急程度；告警设备是在小区中部署具备监控和告警的设备，物业管理平台接收到告警后进行报事报修、事件分配下发等操作；其他来源是指该系统可提供Html5的业主端被第三方接入，接入的第三方业主端上报的数据也同样上传到该物业管理报事系统进行统一的分配、管理。

优选的，对于报事类型而言，分为系统告警和事件告警：系统告警是指小区内使用的设备自动上报的报事；事件告警是指用户(业主或物业人员)上报的事事件。

优选的，如图6所示，对于系统告警，物业管理报事系统会自动根据报事类型分配到相应的专业条线，如系统故障报事会自动上报到工程条线，暴力闯入的设备报事会自动上报到安防条线。

优选的，对于事件告警，当业主或物业人员报事之后，物业管理报事系统会提示有报事产生，此时客服人员会根据事件类型调度到相关条线，各条线主任在接收到分配的报事后，根据报事详情分配给相关人员，相关人员在接收到报事后，进行处理，处理完毕后，条线主任核实处理情况，根据处理详情判断是否需要重新处理，若需要重新处理，则重新分配，若不需要重新处理，则进行事件销项。此流程中，若相关人员(包括客服人员、条线主任和条线人员)遇到重大事件，不能解决的事件，可上传重大事件到项目经理处进行处理，项目经理在处理完重大事件后，事件状态变为已销项。可见，这里把事件的处理按条线进行的分类处理，在每一个条线上又进行等级划分，并通过该系统建立起高效的处理和监控体系，有利于清楚划分人员责任和快速解决问题。

优选的，依托该物业管理报事系统，可以对整个报事处理流程中的相关人员的职责进行明确划分，包括：客服人员对于待调度的事件告警，可以分配事件告警到对应的处理条线；各条线的主任对于待分配的事件告警，可以指派处理事件人员进行处理；各条线的指定人员对于待处理的事件告警，只有被指派的人员可操作处理；各条线的指定人员处理完毕后，由对应主任查阅结果，来决定是否销项；而对于重大事件则是项目经理等高级人员处理的事件。优选的，当条线主任确认所报事件不是对应的管辖范围时可以请求转移条线，这样客服人员接受该反馈后重新分配事件到其他对应的条线中。这里，项目经理负责处理重大事件，可查看项目下所有的报事记录以及和自己相关的报事职责权限；各条线主任负责分配该条线相关人员进行处理报事事项及事件处理后的销项操作，可查看自己条线的事件以及和自己相关的报事；各条线人员负责处理被分配到的事件以及查看和自己相关的事件。可以看出，上述的报事状态主要包括：待调度、待分配、待处理、待销项、已销项、重大事件。

优选的，在物业管理报事系统处理事件后，该事件的状态会同步到物业端，物业端处理完事件后该事件的状态也会同步到物业管理报事系统，两端同步操作，方便物业人员灵活处理报事，且信息同步。

优选的，报事条线包括安防条线、工程条线、客服条线、环境条线。

进一步优选的，物业人员对发现的异常物业事件进行上报，主要包含自行处理、上报主任、上报重大事件三个功能。非主任级别的条线人员主要包括客服人员、工程人员、安防人员、环境人员；主任级别的人员：客服主任、工程主任、安防主任、环境主任。

由此可见，上述物业管理报事系统可集成多种途径的报事来源，包括物业端、业主端、机房告警、视频告警等，物业管理报事系统集合各类报事；同时又是独立的模块，兼容各种报事场景，采用Html5语言程序形式和软件开发工具包(SDK，software developmentkit)的形式被第三方接入并报事至物业管理报事系统。采用该系统，有利于提高效率，是事件内容统一管理平台，内容可以共享；人员的职责明确，分配处理流程合理，对于每一个环节都有相应的流程把控，节点责任人明确，相关节点负责人只需处理相关节点即可，各司其职，提高工作效率。记录永久保存，具有可追溯性，角色处理权限可灵活配置，使用环境要求低，兼容电脑和APP端大部分浏览器，无需安装任何插件，即可使用。

优选的，该物业综合管理系统还包括物业管理自发卡系统，图7显示了本发明物业管理自发卡系统一实施例的组成图。在图7中，包括安装在用户手机或计算机的业主端1，所述业主端与物业管理平台2网络互联，例如移动通信网络或计算机互联网，所述物业管理平台2还通过内部网络(主要是基于小区物业的局域网)与各个读卡门禁3互联；当用户需要办理门卡4时，通过所述业主端1向物业管理平台2申请，这种申请过程优选是通过网络进行，无需用户面对面的向物业客服人员提出申请，这样大大提高了效率。所述物业管理平台2对申请经过审核后确定门禁权限，用户再通过业主端1选择对应的读卡门禁3，然后将门卡4在所述读卡门禁3上进行刷卡注册，所述读卡门禁3读入所述门卡4的卡号，传输至所述物业管理平台2进行信息绑定，完成自行发卡。

优选的，所述刷卡注册包括使用同一门卡两次在同一所述读卡门禁上进行刷卡，并且两次刷卡读入的卡号相同才能进行信息绑定。该过程可以通过图8所示流程进一步说明。

在图8中，用户通过业主端1向物业管理平台2填写发卡申请信息后，物业管理平台根据该用户的权限获取对应的门禁信息，例如该用户对应的门禁信息只能是在小区公共场所的门禁和该用户所居住的单元楼门禁，因此在下一步的选择读卡门禁时，用户只能在门禁信息中选择对应的读卡门禁。进一步的，用于使用一个新的门卡在选择的读卡门禁上刷卡，这样就把该门卡的卡号通过该读卡门禁传输到物业管理平台中，物业管理平台将该卡号与申请信息、门禁信息进行审核绑定，即为刷卡成功，若本次刷卡不成功则返回到重新填写发卡信息步骤，若本次绑定成功，则读卡门禁提示第二次刷卡，用户则再次刷卡后，将卡号信息传输到物业管理平台，物业管理平台将该卡号与申请信息、门禁信息进行审核绑定，即为第二次刷卡成功，并且这两次对应的卡号也是一致的，这样经过两次刷卡都成功以后，才完成最终的发卡成功。这里，如果第二次刷卡不成功，则比较两次刷卡得到的卡号是否一致，如果卡号一致则返回到第一次刷卡步骤，重新开始第一次刷卡操作；如果比较两次刷卡得到的卡号不一致，则返回到重新填写发卡信息步骤。

通过图8中的两次刷卡验证可以进一步增强自行发卡的安全性和可靠性。

进一步优选的，如图9所示，物业管理平台根据业主端在门禁信息中选择的读卡门禁，向门禁工作站以MQTT协议的方式下发指令，该指令中包括传入对应的读卡门禁的识别号(即ID号)和信息回调URL，门禁工作站是具体对读卡门禁进行控制的监控平台，此时门禁工作站就向对应识别号的读卡门禁下发读卡指令，而该对卡门禁收到该读卡指令后，就对临近的门卡进行读卡(或称之为刷卡)，将该门卡的卡号信息读入到门禁中，然后再将该卡号信息和信息回调URL一同回传给门禁工作站和物业管理平台。该过程进一步反应了物业管理平台对读卡门禁操控进行读卡的过程。

进一步优选的，如图10所示，为了增强安全性，用户通过业主端向物业管理平台选择读卡门禁后，物业管理平台将该读卡门禁号发送给门禁工作站，当门禁工作站对所述读卡门禁进行控制时，门禁工作站先向对应的读卡门禁发送读卡密码，然后又向物业管理平台反馈同一个读卡密码，物业管理平台又向业主端发出该读卡密码，当业主端收到该密码后，用户则可以通过对应的读卡门禁输入该密码，这样门禁工作站就可以进一步确认是在对应的读卡门禁上是由对应的用户进行刷卡绑定，确保了该门卡自行发放时对应用户的唯一性和准确性，并且该过程的时效性比较强，也确保了安全性。

优选的，当经过上述两次读卡成功进行绑定后，物业管理平台就将该卡号对应的授权门禁发送给门禁工作站进行存储，或者由对应的读卡门禁进行存储，这样当该门卡进行使用刷卡时，授权开门的权限则是由门禁工作站或对应的读卡门禁完成，这样可以提高工作效率以及减轻物业管理平台在后期门卡使用过程中负担，而是交给门禁工作站或对应的读卡门禁来完成日常门禁管理。

优选的，业主端中主要包括专用的门卡发放应用软件，用于登陆业主端后就可以与物业管理平台进行信息沟通，而在填写申请信息时，通常需要把用户的姓名、手机、证件类型、证件号、住址等申请信息通过业主端发送给物业管理平台。由于物业管理平台中已登记注册有业主的相关信息，因此可以对申请信息进行核验审核。

优选的，为了提高安全性，还可以对用户申请进行人脸识别，即是在申请门卡时，通过业主端对申请人进行拍照，该照片信息随申请信息同步存入到物业管理平台中。后期，当门禁系统通过门卡开门时，可以对持卡人进行人脸识别，即门禁系统将所持门卡的开门人进行拍照，然后与申请阶段的申请人照片信息进行比对，当比对相同时才可以通过该门卡进行开门。这种方式增强了使用这种门卡开门的安全性，确保了该门卡的使用对象具有唯一性，即专人使用专卡。

优选的，所述门卡包括IC卡(例如UID、ISO14443A/B)、CPU卡(例如类型为FM1208-09、FM1208-10的卡)或带有存储卡的身份证件(如中国二代身份证)。可以看出，由于使用的门卡取材具有广泛性，用户可以使用常用的卡作为门卡，因此无需再向物业申请购买专用的门卡，这种方式大大节省了门卡资源。

优选的，用户通过业主端还可以对门卡进行注销，例如当用户发现门卡丢失后，可以登录该业主端向物业管理平台发出注销请求，然后选择对应的门卡信息，经过物业管理平台审核确认以后，就将该门卡号对应的门卡作为无效门卡，当有人使用该门卡在读卡门禁上刷卡时将不被识别而失去开门的功效。

优选的，用户通过业主端还可以对门卡进行重新授权，就是针对同一个门卡，用户在注销以后还可以向物业管理平台申请重新授权，从而恢复对应门卡的开门功效。

优选的，用户通过业主端还可以对发卡记录进行查询，当进行查询时，物业管理平台可以向用户推送与该用户相关的门卡发放记录，供用户查询相关信息。

基于同一构思，本发明还提供了一种物业管理自发卡方法，如图11所示，包括以下步骤：

填写信息S101，用户在自发卡系统上填写申请信息，然后将所述申请信息提请到物业管理平台进行审核；

确定权限S102，所述物业管理平台根据所述申请信息，确定自发卡对应的门禁权限；

选择门禁S103，用户在自发卡系统上选择自发卡的读卡门禁，对应所述读卡门禁的识别号传入到所述物业管理平台；

刷卡绑定S104，用户使用门卡在所述读卡门禁上进行刷卡，所述门卡的卡号被所述读卡门禁读入并传输到所述物业管理平台进行信息绑定，完成自行发卡。

优选的，在填写信息步骤S101中，所述自发卡系统包括安装在手机的APP或者安装在计算机上的业主端，并且通过网络接入到所述物业管理平台。

优选的，在所述刷卡绑定步骤S104中，包括使用同一门卡两次在同一所述读卡门禁上进行刷卡，并且两次刷卡读入的卡号相同才能进行信息绑定。

优选的，在所述刷卡绑定步骤S104中，还包括人脸识别，通过业主端对申请人进行拍照，得到照片信息随卡号同步存入到物业管理平台中进行信息绑定。

进一步优选的，如图12所示两次刷卡进行信息绑定的过程，还可以将图11中的步骤S104进一步对应细化为图12中的注册读卡和读卡。图12中，第一注册读卡是指所述物业管理平台根据用户选择的读卡门禁，控制该读卡门禁开设工作，相当于远程启动该读卡门禁，而第一读卡则是在该读卡门禁启动后，对临近的门卡读取卡号，因此该过程要求用户持卡临近该读卡门禁才能进行读卡。如果没有持有门卡或者持有的门卡类型不符合要求，则会造成无效读卡，即第一次读卡失败。图11中，在完成第一次注册读卡和第一次读卡以后，则重复再进行第二次注册读卡和第二次读卡，该过程与第一次注册读卡和第一次读卡相同，那么在两次读卡完成以后，就可以对两次读入的卡号进行比对，如果卡号一致则表明成功，否则需要返回重新进行第二次注册读卡和第二次读卡。

由于与前述的物业管理自发卡系统属于同一构思，该物业管理自发卡方法中也对应包括前述相关内容，这里不再赘述。

由此可见，物业管理自发卡系统包括安装在用户手机或计算机的业主端，所述业主端与物业管理平台网络互联，所述物业管理平台还通过网络与各个读卡门禁互联；当用户需要办理门卡时，通过所述业主端向物业管理平台申请，所述物业管理平台经过审核后确定门禁权限，用户再通过业主端选择对应的读卡门禁，然后将门卡在所述读卡门禁上进行刷卡注册，所述读卡门禁读入所述门卡的卡号，传输至所述物业管理平台进行信息绑定，完成自行发卡，为了增强安全性通常是进行两次注册刷卡。本发明替代了人工开卡，把空间的往返移动办卡集中到了本系统上，对应的发卡记录、开门记录可以实现即时记录上传、云端共享信息等。有效节省了用户时间，解决人工重复性工作和用户来回奔波不能及时进入园区等的问题。

进一步的，该物业管理业主端系统还包括业主登录管理系统，用于业主通过业主端登录进入物业管理平台，主要包括密码登录、验证码登录、游客登录和第三方登录，如图13所示。

密码登录是指用户通过预先注册绑定的手机号输入登录密码进行登录。如果忘记密码，则向物业管理平台输入预先绑定的手机号，这时可以重新设置密码，设置密码成功后，使用该新密码在该手机上进行登录即可。

验证码登录是指根据手机号和短信验证码登录，如已注册，则直接跳转进入物业管理平台，如未注册用户，跳转到设置密码后再进入物业管理平台。

第三方登录是指通过微信登录、QQ登录，当确认绑定手机后则直接跳转进入物业管理平台，若没有绑定手机

游客登录是指没有帐号的用户可以点击游客登录进入物业管理平台，对应游客登录而言具有较少的权限。

进一步的，该物业管理物业端系统还包括物业登录管理系统，用于物业管理人员通过物业端登录进入物业管理平台，主要包括密码登录、访客登录和人脸登录，如图14所示。

当选择密码登录时，则先判断是否登录成功，若没有成功，则给出对应的操作提示，若登录成功，则进入物业管理平台的首页。

当选择游客登录时，则进入物业管理平台的首页。

当选择人脸登录时，则需要先判断工号是否有输入的内容，如果输入了工号，则判断是否录入物业人脸信息，若没有录入对应的人脸信息，则登录界面为无人脸登录入口，若已录入对应的人脸信息，则刷脸登录进入物业管理平台的首页；如果未输入工号，则判断是否录入游客人脸信息，若没有录入游客人脸信息，则登录界面是无人脸登录入口，若已录入对应的游客人脸信息，则刷脸登录进入物业管理平台的首页。

优选的，这里由于进行了人脸登录，这就需要事先进行人脸信息采集。该过程如图15所示包括：首先，初始化相关数据，开始扫描人脸；然后，判断是否有人脸特征，若没有人脸信息，则进行提示，如“未监测到人类”，若有人脸信息，则判断是否正在识别人脸，若是则继续扫描，若否则开始识别人脸；接着，识别完后，判断是否是所需的人脸信息，若是，则停止采集，并提示“人像录入成功”；若否则继续扫描。

进一步的，该物业管理业主端系统和物业管理物业端系统均还包括前述的对讲管理系统中的门禁控制模块。该门禁控制模块主要是为业主的业主端提供对应的管理功能，也可以为物业管理人员的物业端提供对应的管理功能，主要包含蓝牙配置、蓝牙开门和远程开门。其中蓝牙配置用于配置蓝牙开门的相关信息，如密码等；蓝牙开门主要是开对应的蓝牙门禁；远程开门主要用于开非蓝牙门禁或蓝牙门禁不能成功开门时的第二选择。

优选的，对于蓝牙配置而言，包括获取用户可配置的蓝牙门禁列表、获取门禁详细信息、配置门禁列表。蓝牙配置流程包括：

首先，获取所有门禁列表；然后，选择一个门禁，获取其详细信息，并编辑配置相关门禁信息，其中配置信息参数，包括密码，如24位(使用数字0～9和字母a～f或A～F)，小区标识，如32位或20位，其他字段均获取得来；编辑完成后，按下门禁模块(包括蓝牙模块或一体机模块)后，再按下“匹配设备”，开始扫描蓝牙模块，获取信号最强的门禁设备，请求后台绑定门禁设备；判断后台绑定设备与否，若未绑定，则提示“设置失败”，若已经绑定，根据返回值更新密码字段。优选的，还包括继续绑定第三方蓝牙设备接口，例如判断第三方厂商绑定设备与否，若没有绑定，则提示“设置失败”；若已经绑定，提示“设置成功”，同时更新门禁列表。对其他门禁的蓝牙配置也是按照相同的步骤进行配置。

优选的，对于蓝牙开门，流程如图16所示，包括：第一步，初始化可开门禁列表数组openDoorList；第二步，开始扫描；第三步，扫描到一个门禁设备dev，判断该门禁设备是否是在可开门禁数组openDoorList中，若该门禁设备在可开门禁数组openDoorList中，则存储到对应的openDoorList索引值中，并判断是否可开门禁数组大于0，且还未开门；第四步，若该门禁设备不在可开门禁数组openDoorList中，判断是否是有权限的门，若是有权限，则存入到openDoorList中，然后判断是否可开门禁数组大于0，且还未开门；若是没有权限，直接判断是否可开门禁数组大于0，且还未开门；第五步，若可开门禁数组大于0，且还未开门，则默认开openDoorList第一个对应的门。第六步，判断是否开门成功，若没有成功的话，则提示“开门失败”，若开门成功则提示“门已开，5s后再操作”。第七步，若可开门禁数组数组大于0且还未开门的条件不成立，则判断扫描时间是否超时，若没有超时，则重新走一次第二步至第五步；若已经超时，则扫描结束，返回openDoorList。

对于远程开门，主要包含获取当前项目下所有有权限的门禁、然后通过网络开门门禁。

进一步的，该物业管理物业端系统还包括访客管理系统，主要包括访客登记、访客记录、名单管理。其中，访客登记用于登记出入小区的访客信息、授权开门权限；访客记录用于查看进入的访客信息；名单管理用于显示出入人员的安全级别信息。

访客登记是在访客登录进入到系统以后，对访客进行登记和授权的过程，如图17所示，包括步骤有：

首先，输入访客身份信息，判断身份类型，如身份证、护照、军官证、学生证等，若通过身份类型识别出访客已落入黑名单，则进行提示，并填充类型字段为黑名单；若访客的身份类型识别出为灰名单或黄名单，则直接填充类型字段为灰名单或黄名单，选择进出方式，切换不同格式离开时间。

然后，在提交时，根据不同进出方式，跳转不同页面。其中，若为门岗开门，则直接提交访客登记；若为二维码开门，则调转对应选择门禁页面，选完门禁后，直接提交访客登记；若为IC卡开门，则跳转对应选择门禁页面，选完门禁后，对IC卡进行授权，授权成功后，直接提交访客登记。

名单管理主要记录访客的类型，可以将访客类型划分为黑名单、黄名单和灰名单，对名单管理的具体操作包括显示名单列表、添加人员名单、删除人员名单功能。

进一步的，该物业管理物业端系统还包括云瞳监控系统，用于监控现场各个位置的运行状态，包括获取监控列表、显示监控视频、抓拍异常并上报事件、获取云瞳上报事件列表。

如图18所示，对于云瞳显示监控流程的运行步骤包括：

第一步，输入密码，登录云瞳监控系统，如果登录失败，则进行提示；

第二步，登录成功后，获取云瞳监控列表，并判断是否获取到列表，若没有获取，则提示“请联系管理员开通项目权限”；

第三步，若获取了云瞳监控列表，则默认显示第一个监控点，同时可以切换显示其他监控点。

进一步的，该物业管理物业端系统还包括消息推送系统，是由系统向物业管理人员推送的各种消息，主要包括平台通知、事件管理、出入管理、设备管理。

平台通知是面向所有物业人员，由系统平台统一推送到相关人员，对应的消息字段包括：消息类型、消息主题、消息内容(文字+图片)和时间。

事件管理是面向安防、工程、客服条线人员，消息来源是当事件管理节点到达需要处理时，推送到相关物业人员；对应的消息字段包括：消息类型、项目名称、消息内容和时间，这里的消息内容举例如：您有一个待处理事件，请及时处理。

出入管理是面向客服条线人员，消息来源是当有重点关注、紧急关注人员出入项目时，推送提示；对应的消息字段包括：消息类型、项目名称、消息内容、时间、重点或紧急关注标识，这里的消息内容举例如：访客xx从东门(门禁名称)进入，请及时跟进。

设备管理是面向工程条线人员，消息来源是操控设备，若设备离线需要推送到相应的项目工程人员；推送频率是当设备在离线发现状态变化后才推送，如离线变为在线不推送，在线变为离线后重新推送；对应的消息字段包括：消息类型、项目名称、消息内容、时间，这里的消息内容举例如：XXX(设备名称)离线了，请及时处理，或者XXX(设备名称)对讲离线，请及时处理，例如设备网络连接但未成功登录到第三方音频服务器。

进一步的，该物业管理物业端系统还包括巡更管理系统，主要用于显示在小区内的物业人员的巡检记录及轨迹，能够更好的查看工作进度。包括获取所有巡更人员、搜索人员；查看人员的轨迹(通过地图上显示大头针的方式显示)、查看人员轨迹回放(通过地图上显示轨迹连线的方式进行展示)、巡更进度、某日巡更进度详情(通过页面展示的方式显示)。安防条线、项目经理、管理员可查看相同巡更数据记录，不做数据权限；巡更记录是可查看该项目下巡更成员当日及历史的巡更记录；当选择某一巡更人员时，可查看该成员的轨迹及轨迹回放，若该成员当日无任务则提示“该日无巡检任务”，无法进行其余操作。优选的，包括视频巡检报事，由物业管理物业端系统生成巡检任务，再由物业工作人员对应时间点上查看对应点位的视频监控，若在视频监控中发现异常，则可通过视频巡检报事，记录相关异常。

进一步的，该物业管理物业端系统还包括软对讲管理系统，主要包括频道管理和对讲两部分。其中，频道管理是将需要通话的成员加入到一个群组中，实现只有群中的成员才能够收到对讲内容。对讲主要用于替代传统的呼叫机，实现多个功能集成到一个app中，便于物业人员携带。

在频道管理中，主要包括显示频道列表、选择成员并新增频道、修改频道信息、删除频道。其中修改频道信息包含修改频道名称、新增频道成员、删除频道成员。

在软对讲操作中，如图19所示，主要步骤包括：

第一步，按下软对讲按钮时，判断用户是不是游客，若是，则提示“游客模式无法体验”；

第二步，若不是游客，则判断是否有麦克风权限，若否，则提示“请在‘设置-隐私-麦克风’中允许访问麦克风”；

第三步，若具有麦克风权限，则开始录音，同时判断录音时长是否大于30秒，若否，则实时更新显示数据；

第四步，若录音时长大于30秒，则停止录音，并发送录音文件。

进一步优选的，所述物业管理业主端系统包括与物业管理对讲系统中的视频对讲模块相关联，用于业主与物业端、门口机、室内机和/或围墙机，通过物业管理平台，在其中任意两个设备之间通过网络互连能够进行音频和/或视频对讲。具体参见对视频对讲模块的说明，这里不再赘述。

优选的，所述物业管理业主端系统与物业管理对讲系统中的门禁控制模块相关联，为业主提供对应的门禁管理，包括蓝牙配置、蓝牙开门和远程开门。具体参见对门禁控制模块的说明，这里不再赘述。

除此之外，在物业管理业主端系统中还进一步包括：心情天气模块：可根据用户当前定位的位置来获取当地的天气信息；访客邀请模块：需填写访客信息，设置访客来访时间和次数，可来访的房号和开门门禁，可生成二维码或者远程开门链接，访客可根据二维码或远程开门链接来开门；公区监控模块：获取当前所需的监控点，可以切换监控点查看监控视频，可抓拍，抓拍的图片可保存到相册并查看；点歌服务模块：业主可以在指定局域网内搜索歌曲、点播歌曲、切歌等操作；物业公告模块：业主可查看物业发来的物业通知；远程开门模块：业主可以获取门禁列表，设置常用门，实现远程开门；蓝牙开门模块：摇一摇蓝牙开门，扫描周边蓝牙设备开门。这里的远程开门模块和蓝牙开门模块与前述的门禁管理系统相对应，其中，在蓝牙开门中，如图20所示，进入蓝牙开门流程后，开启蓝牙扫描门禁设备，同时检查是否有缓存门禁，如果有缓存门禁则判断是否扫描到对应可以蓝牙开门的设备，如果存在则获取开门权限的门禁，如果可开的门禁数是唯一的，即等于1则直接开门，如果小于1则表示没有可开的门禁，如果大于1则表明有多个门禁可供选择，可以进一步选择需要蓝牙开门的门禁。其中，在检查是否有缓存门禁时，如果显示没有缓存门禁，则进一步检查是否有工作站，如果有工作站，则调用后台接口getDoorByPhone()，门禁权限只能统一在工作站授权，用户无法更改门禁权限，故getDoorByPhone()接口获取的是工作站授权门禁列表。如果没有工作站，则调用后台接口getDoorByUser()，用户门禁权限可以自行分配授权，故getDoorByUser()接口可以获取用户自行授权门禁列表。这里的工作站是指线下统一管理门禁信息的平台。通过这两个接口如果分别调用成功的话则进入到下一步的判断是否扫描到对应可以蓝牙开门的设备，如果通过这两个接口均没有调用成功的话，则提示获取门禁失败。如果扫描蓝牙设备失败则重新开启蓝牙扫描门禁设备。

进一步的，在物业管理业主端系统中还包括：

基础信息模块：用户可以设置头像、昵称、性别并查看手机号。

我的小区模块：用户可以申请房屋，业主可以给家属、租客授权房产和相关门禁，可以同意或拒绝房产申请；传统方式是走线下流程，业主自行到物业管理处进行业主登记，流程复杂，不便利。现采用线上申请流程方式，业主在线上向物业申请对应房号的业主权限，通过之后，业主可以将此权限授权给租户、保姆、家人(访客也可以主动向业主发起权限申请)，便于访客的出入。授权时，可以选择授权可开门禁，控制权限，在授权期间，可以随时取消授权，确保安全，权限自动到期后，访客可以自主的向业主申请权限，业主也可以主动给访客授权。

进一步的，在我的小区模块中进一步包括我的认证模块和我的管理模块。

在我的认证模块中，包括已认证条目，在该条目下可以查看已认证详情，包括被授权人、被授权人电话、用户类型、门禁、已认证项目名和房号，通过填写授权房产对应的授权信息和门禁，调用后台业主主动授权接口进行查询，包括授权成功和失败两种情况；申请中条目，可以查看申请中的详情，如申请项目名和房号；被驳回条目，可以查看被驳回的详情，如被驳回理由、申请项目名和房号以及重新申请对应的申请房屋；已过期条目，表明认证已过期；在管理房屋条目中，包括已过期列表删除按钮，可以确认是否删除，如果需要删除则调用后台删除已过期列表接口，实现删除，还可以取消删除。

进一步的，在申请房屋条目中，可以在本小区搜索申请房屋，也可以扩大范围在所在城市申请房屋。其中，在本小区搜索申请房屋的过程是，可以先选中楼栋，如果楼栋选取成功后再选取该楼栋中的房号，判断该房号是否已经申请过或者该房号对应的就是该业主的住房，如果还没有申请过并且也不是对应的业主，则调用后台提交申请接口，可以实现提交申请成功。在所在城市搜索申请房屋的过程是，也是先选中一个具体小区的一个楼栋，并填写申请人姓名和申请项目名，如果楼栋选取成功后再选取该楼栋中的房号，判断该房号是否已经申请过或者该房号对应的就是该业主的住房，如果还没有申请过并且也不是对应的业主，则调用后台提交申请接口，可以实现提交申请成功。如果上述申请没有成功，还可以重新进行定位，在定位好的小区中继续选取楼栋和房号。

在我的管理模块中，包括已授权、待审核和已驳回三个条目。

在已授权条目中，包括具体的授权详情，如授权项目名和房号、被授权人电话、被授权人、用户类型、授权门禁。在这里可以取消授权或重新授权，取消授权时，调用后台授权接口，输入对应的取消授权标识，则可以取消授权；在重新授权时，可以根据授权项目名和房号，选择用户类型、授权门禁，如果用户类型、授权门禁均为空，则需要重新选择用户类型、授权门禁，如果用户类型、授权门禁均不为空，调用后台授权接口，输入对应的重新授权标识，则可以重新授权。

在待审核条目中，包括具体的授权详情，如授权项目名和房号、选择用户类型和授权门禁。在这里可以同意授权或拒绝授权，同意授权时，判断用户类型或者授权门禁是否为空，如果用户类型或者授权门禁为空，则需要重新选择用户类型或者授权门禁，如果用户类型和授权门禁均不为空，调用后台授权接口，输入对应的同意授权标识，则同意授权成功。拒绝授权时，则需要填写拒绝理由，调用后台授权接口，输入对应的拒绝授权标识，则可以拒绝授权。

进一步的，在物业管理业主端系统中还包括：版本查询模块：用户可查看该app的版本和隐私协议，并检测是否有新版本，如果有新版本，可以下载安装。信息反馈模块：用户可以通过文字和图片反馈app存在的不足之处。勿扰设置模块：业主可以根据房产设置勿扰模式，打开勿扰模式，则门口机和围墙机不能呼到该业主。人脸录入模块：如图21所示，进入人脸录入后，判断该用户是否录入过人脸，如果已经录入，则表明存在于人脸列表中，否则就需要录入人脸操作，通过手机摄像头进行人脸拍照，然后确认照片是否满足要求，如果不满足要求则重新进行人脸拍照，如果满足要求则要选择门禁并填写信息，就是要把该用户对应的门禁权限与其脸部照片进行关联，同时把该拍照存入人脸列表中，完成录入成功后，可在对应门口机开指定门禁。

还进一步包括我的设备模块：可查看当前家庭下网关中的入网设备；帐号安全模块：用户可以绑定微信、QQ、修改密码、退出登录；我的家庭模块：用户可以查看已有家庭列表，修改家庭名称，新增家庭，删除家庭，删除家庭中所绑定网关。

进一步的，在物业管理业主端系统中还包括智能家居管理模块，具体又包括家庭、设备、场景和房间条目。

家庭：用户可以切换家庭，切换之后会登录该家庭的网关，获取网关中的设备、场景、房间。如果切换的家庭没有绑定网关，则显示默认的房间、场景。

设备：如果家庭已绑定网关，用户可以直接入网设备，如果没绑定网关，用户需登录网关后入网设备。用户可对已入网设备进行操控。

场景：如果当前家庭已绑定网关，可获取网关中的场景，如果没有绑定网关，则显示默认的场景；用户可以增加和删除场景，修改场景名字和图片；场景中可以添加可控制开关状态的设备，通过点击该场景可控制该场景中设备的开关。

房间：如果当前家庭已绑定网关，可获取网关中的房间，如果没有绑定网关，则显示默认的房间；用户可以增加和删除房间，修改房间名字和图片；房间可添加可控制开关状态的设备；一个设备只能被添进一个房间，两个房间不能添入同一设备。

对家庭的操作如图22所示，包括：增加家庭、修改家庭和删除家庭。其中，在增加家庭包括绑定网关。当未绑定网关时，对应的默认场景包括：离家模式、归家模式、度假模式、睡眠模式和起床模式，默认房间包括包括主卧、次卧和客厅；当绑定网关时，网关中的模式包括新增模式、修改模式和删除模式，在新增模式中，包括绑定设备、选择模式图片和设置模式名称，在修改模式中包括修改模式名称、删除该模式设备、修改模式图片和添加设备。网关中的房间包括新增房间、修改房间和删除房间，在新增房间中，包括设置房间名称、选择房间图片和绑定房间设备，在修改房间中，包括修改房间名称、修改房间图片、添加设备、删除已绑定设备。网关中的设备包括操控设备、新增设备、解绑设备、修改设备名称和设置设备所属位置，其中，在操控设备时包括控制开关和查看设备状态，新增设备是指按照设备的入围规则增加入网设备。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种物业管理自发卡系统，其特征在于，包括安装在用户手机或计算机的业主端，所述业主端与物业管理平台网络互联，所述物业管理平台还通过网络与各个读卡门禁互联；当需要办理门卡时，通过所述业主端向物业管理平台申请，所述物业管理平台经过审核后确定门禁权限，再通过业主端选择对应的读卡门禁，然后将门卡在所述读卡门禁上进行刷卡注册，所述读卡门禁读入所述门卡的卡号，传输至所述物业管理平台进行信息绑定，完成自行发卡。

2.根据权利要求1所述的物业管理自发卡系统，其特征在于，所述刷卡注册包括使用同一门卡两次在同一所述读卡门禁上进行刷卡，并且两次刷卡读入的卡号相同才能进行信息绑定。

3.根据权利要求1所述的物业管理自发卡系统，其特征在于，所述门卡包括IC卡、CPU卡或带有存储卡的身份证件。

4.根据权利要求2或3所述的物业管理自发卡系统，其特征在于，所述物业管理平台根据业主端选择的读卡门禁，向门禁工作站以MQTT协议的方式下发指令，所述指令中包括传入对应的读卡门禁的识别号和信息回调URL，所述门禁工作站就向对应识别号的读卡门禁下发读卡指令，而所述对卡门禁收到所述读卡指令后，就对临近的门卡进行读卡，将所述门卡的卡号信息读入到所述读卡门禁中，然后再将所述卡号信息和信息回调URL一同回传给门禁工作站和物业管理平台。

5.根据权利要求4所述的物业管理自发卡系统，其特征在于，当经过上述两次刷卡成功进行信息绑定后，所述物业管理平台就将所述卡号对应的授权门禁发送给门禁工作站进行存储，或者由对应的读卡门禁进行存储，当使用该门卡进行使用刷卡时，授权开门的权限则是由门禁工作站或对应的读卡门禁完成。

6.一种物业管理自发卡方法，其特征在于，包括以下步骤：

填写信息，通过物业管理自发卡系统上填写申请信息，然后将所述申请信息提请到物业管理平台进行审核；

确定权限，所述物业管理平台根据所述申请信息，确定自发卡对应的门禁权限；

选择门禁，通过自发卡系统上选择自发卡的读卡门禁，对应所述读卡门禁的识别号传入到所述物业管理平台；

刷卡绑定，使用门卡在所述读卡门禁上进行刷卡，所述门卡的卡号被所述读卡门禁读入并传输到所述物业管理平台进行信息绑定，完成自行发卡。

7.根据权利要求6所述的物业管理自发卡方法，其特征在于，在所述刷卡绑定步骤中，包括使用同一门卡两次在同一所述读卡门禁上进行刷卡，并且两次刷卡读入的卡号相同才能进行信息绑定。

8.根据权利要求6所述的物业管理自发卡方法，其特征在于，所述门卡包括IC卡、CPU卡或身份证卡。

9.根据权利要求6所述的物业管理自发卡方法，其特征在于，所述物业管理自发卡系统包括安装在手机的APP或者安装在计算机上的业主端，并且通过网络接入到所述物业管理平台。

10.根据权利要求6所述的物业管理自发卡方法，其特征在于，在所述刷卡绑定步骤中，还包括人脸识别，通过业主端对申请人进行拍照，得到的照片信息随卡号同步存入到物业管理平台中进行信息绑定。