发明创造名称：电梯智能监控系统与方法
外观设计名称：
决定号：196694
决定日：2019-09-06
委内编号：1F265749
优先权日：
申请（专利）号：201710664322.X
申请日：2017-08-04
复审请求人：郑州轻工业学院
无效请求人：
授权公告日：
审定公告日：
专利权人：
主审员：李燕东
合议组组长：田志刚
参审员：李宁
国际分类号：G06F17/30,G08C17/02,H04W84/18,H04L29/06,B66B5/00
外观设计分类号：
法律依据：专利法第22条第3款
决定要点
：如果一项权利要求所要求保护的技术方案与作为最接近的现有技术的对比文件相比存在区别技术特征，但是上述区别技术特征或者属于本领域的公知常识，或者被其他对比文件公开，即其他现有技术中给出了将上述区别技术特征应用到该最接近的现有技术以解决其技术问题的启示，从而使得本领域技术人员在现有技术的基础上得到该权利要求的技术方案是显而易见的，那么该权利要求所要求保护的技术方案不具备创造性。
全文：
本复审请求涉及申请号为201710664322.X，名称为“电梯智能监控系统与方法”的发明专利申请（下称本申请）。申请人为郑州轻工业学院。本申请的申请日为2017年08月04日，公开日为2017年10月20日。
经实质审查，国家知识产权局原审查部门于2018年08月14日发出驳回决定，驳回了本申请，其理由是：权利要求1-5不具备专利法第22条第3款规定的创造性。驳回决定具体指出：权利要求1与对比文件1（CN104944240A）的区别技术特征在于：（1）数据接收模块用于多线程数据解析，数据存储模块对多线程解析的数据进行存储；（2）后台管理模块对电梯的维保进行管理；（3）数据采集模块采用ZigBee与多个传感器所构建的无线传感网络，对电梯运行状态的数据进行实时采集，数据传输模块采用UDP协议进行传输，将数据发送到IP和端口上。对于区别技术特征（1），对比文件2（CN106339892A）公开了“采用NoSQL数据库和MySQL数据库完成数据存储”以及“将数据存储至NoSQL数据库中，并将NoSQL数据库中的数据保存到MySQL数据库中”。对比文件2同时给出了对处理后的中间数据进行相关存储的启示，而对数据进行多线程的解析（例如，设置相应的模块）属于常见的数据处理方式。本领域技术人员能够想到对接收到的电梯运行相关数据进行多线程解析和存储，并在多线程解析的基础上，采用对比文件2中先存储在NoSQL数据库中以提升存储效率，后续转存至MySQL数据库中提升存储数据安全性的方式。其中，由于电梯的故障数据相对较少且需要长期或永久保存以便后续查看和分析，故对故障数据采用现有的方式直接存储至MySQL数据库中，此为本领域技术人员根据电梯监控数据的特点容易想到并实现的方式。针对区别技术特征（2），为了对电梯进行全面的监控，后台管理模块还对电梯的维保进行管理，这属于本领域技术人员的常用技术手段。对于区别技术特征（3），对比文件3（CN103051708A）公开了“采用ZigBee与多个传感器所构建的传感网络，对电梯数据进行实时采集”）。采用无线传感网络进行数据的传输属于本领域技术人员的常用技术手段。同时，Socket为常用的传输协议，采用其对数据进行传输为本领域技术人员可以根据实际应用需求进行选择的方式。因此权利要求1不具备创造性。从属权利要求2、3的附加技术特征或者是本领域的公知常识，或者已被对比文件1所公开，因此权利要求2、3不具备创造性。
权利要求4与对比文件1的区别技术特征在于：（1）进行多线程数据解析，对多线程解析的数据进行存储；（2）对电梯的维保进行管理。对于区别技术特征（1），对比文件2公开了“采用NoSQL数据库和MySQL数据库完成数据存储”以及“将数据存储至NoSQL数据库中，并将NoSQL数据库中的数据保存到MySQL数据库中”。对比文件2同时给出了对处理后的中间数据进行相关存储的启示，而对数据进行多线程的解析属于常见的数据处理方式。本领域技术人员能够想到对接收到的电梯运行相关数据进行多线程解析和存储，并在多线程解析的基础上，采用对比文件2中先存储在NoSQL数据库中以提升存储效率，后续转存至MySQL数据库中提升存储数据安全性的方式。其中，由于电梯的故障数据相对较少且需要长期或永久保存以便后续查看和分析，故对故障数据采用现有的方式直接存储至MySQL数据库中，此为本领域技术人员根据电梯监控数据的特点容易想到并实现的方式，其实现不需要付出创造性劳动。针对区别技术特征（2），为了对电梯进行全面的监控，还对电梯的维保进行管理，这属于本领域技术人员的常用技术手段。因此权利要求4不具备创造性。从属权利要求5的附加技术特征或者在对比文件1中公开，或者在对比文件3中公开，或者是本领域的公知常识，因此权利要求5不具备创造性。
驳回决定所依据的文本为申请日2017年08月04日提交的摘要附图、说明书摘要、说明书第1-39段、说明书附图图1-4，2018年04月08日提交的权利要求第1-5项。驳回决定所针对的权利要求书如下：
“1. 一种电梯智能监控系统，其特征在于，包括数据采集模块、数据传输模块、数据接收模块、数据存储模块和后台管理模块；
所述数据采集模块用于实时采集电梯运行状态的数据；
所述数据传输模块用于将采集到的电梯运行状态的数据通过传输协议进行传输；
所述数据接收模块用于对传输的数据进行接收和多线程数据解析；
所述数据存储模块用于对接收和多线程解析的数据进行存储，采用NoSQL数据库和MySQL数据库完成数据存储，在上述多线程数据解析过程中，如果电梯运行状态正常，则将所解析好的数据存储至NoSQL数据库中，利用Redis将电梯运行状态数据实时存储在所述NoSQL数据库中，并将NoSQL数据库中的数据周期性地保存到MySQL数据库中，如果发现电梯有故障，将故障电梯的信息存储至MySQL数据库中，MySQL数据库用于永久化存储电梯运行状态数据；
所述后台管理模块用于实时监测电梯运行状态，并对电梯的维保进行管理、对电梯运行状态的数据进行管理和对电梯运行状态数据的历史查询；
所述数据采集模块采用ZigBee与多个传感器所构建的无线传感网络，对电梯运行状态的数据进行实时采集；
所述数据传输模块采用UDP协议进行传输，将数据发送到IP和端口上。
2. 如权利要求1所述的电梯智能监控系统，其特征在于，所述数据接收模块采用Socket编程模型和数据解析程序，通过监听数据传输时的端口，分别将所传输过来的数据进行数据接收和多线程数据解析。
3. 如权利要求1所述的电梯智能监控系统，其特征在于，所述后台管理模块包括后台管理首页和报警模块；
所述后台管理首页通过Socket编程模型对存储在所述NoSQL数据库中的数据进行实时读取，实时监测电梯的运行状态，如电梯有故障发生，则所述报警模块将故障信息弹窗至所述后台管理首页，并将故障信息及时通知相关人员，以及将故障信息存储在MySQL数据库中，所述后台管理首页还采用了Web服务程序用于查询MySQL数据库中的数据，对电梯的维保进行管理、对电梯运行状态的数据进行管理和对电梯运行状态数据的历史查询。
4. 一种电梯智能监控方法，其特征在于，包括如下步骤：
步骤1：实时采集电梯运行状态的数据；
步骤2：将采集到的电梯运行状态的数据通过传输协议进行传输；
步骤3：对传输的数据进行接收和多线程数据解析；
步骤4：对接收和多线程解析的数据进行存储，采用NoSQL数据库和MySQL数据库完成数据存储，在上述多线程数据解析过程中，如果电梯运行状态正常，则将所解析好的数据存储至NoSQL数据库中，利用Redis将电梯运行状态数据实时存储在所述NoSQL数据库中，并将NoSQL数据库中的数据周期性地保存到MySQL数据库中，如果发现电梯有故障，将故障电梯的信息存储至MySQL数据库中，MySQL数据库用于永久化存储电梯运行状态数据；
步骤5：实时监测电梯运行状态，并对电梯的维保进行管理、对电梯运行状态的数据进行管理和对电梯运行状态数据的历史查询。
5. 如权利要求4所述的电梯智能监控方法，其特征在于，包括：
所述的步骤1中采用ZigBee与多个传感器所构建的无线传感网络，对电梯运行状态的数据进行实时采集；
所述的步骤2中采用UDP协议进行传输，将数据发送到IP和端口上；
所述的步骤3中采用Socket编程模型和数据解析程序，通过监听数据传输时的端口，分别将所传输过来的数据进行数据接收和多线程数据解析；
所述的步骤5，具体操作方法如下：
步骤5.1：通过Socket编程模型对存储在NoSQL数据库中的数据进行实时读取，实时监测电梯的运行状态；
步骤5.2：如电梯有故障发生，将故障信息存储在MySQL数据库中；
步骤5.3：采用Web服务程序查询MySQL数据库中的数据，对电梯的维保进行管理、对电梯运行状态的数据进行管理和对电梯运行状态数据的历史查询。”
申请人（下称复审请求人）对上述驳回决定不服，于2018年11月12日向国家知识产权局提出了复审请求，同时修改了权利要求书，主要修改在于：将原权利要求4和原权利要求5进行合并，形成新的权利要求4。
复审请求人认为：权利要求1与对比文件1相比区别技术特征为：（1）数据接收模块用于对传输的数据进行多线程数据解析；（2）数据存储模块对多线程解析的数据进行存储，在上述多线程数据解析过程中，如果电梯运行状态正常，则将所解析好的数据存储至NoSQL数据库中，利用Redis将电梯运行状态数据实时存储在所述NoSQL数据库中，并将NoSQL数据库中的数据周期性地保存到MySQL数据库中，如果发现电梯有故障，将故障电梯的信息存储至MySQL数据库中，MySQL数据库用于永久化存储电梯运行状态数据；（3）后台管理模块对电梯的维保进行管理；（4）所述数据采集模块采用ZigBee与多个传感器所构建的无线传感网络，对电梯运行状态的数据进行实时采集；（5）所述数据传输模块采用UDP协议进行传输，将数据发送到IP和端口上。
以上区别不是公知常识，且与对比文件2和3中所公开的内容不同。本申请的各项权利要求符合专利法创造性的规定。
复审请求时新修改的权利要求书如下：
“1. 一种电梯智能监控系统，其特征在于，包括数据采集模块、数据传输模块、数据接收模块、数据存储模块和后台管理模块；
所述数据采集模块用于实时采集电梯运行状态的数据；
所述数据传输模块用于将采集到的电梯运行状态的数据通过传输协议进行传输；
所述数据接收模块用于对传输的数据进行接收和多线程数据解析；
所述数据存储模块用于对接收和多线程解析的数据进行存储，采用NoSQL数据库和MySQL数据库完成数据存储，在上述多线程数据解析过程中，如果电梯运行状态正常，则将所解析好的数据存储至NoSQL数据库中，利用Redis将电梯运行状态数据实时存储在所述NoSQL数据库中，并将NoSQL数据库中的数据周期性地保存到MySQL数据库中，如果发现电梯有故障，将故障电梯的信息存储至MySQL数据库中，MySQL数据库用于永久化存储电梯运行状态数据；
所述后台管理模块用于实时监测电梯运行状态，并对电梯的维保进行管理、对电梯运行状态的数据进行管理和对电梯运行状态数据的历史查询；
所述数据采集模块采用ZigBee与多个传感器所构建的无线传感网络，对电梯运行状态的数据进行实时采集；
所述数据传输模块采用UDP协议进行传输，将数据发送到IP和端口上。
2. 如权利要求1所述的电梯智能监控系统，其特征在于，所述数据接收模块采用Socket编程模型和数据解析程序，通过监听数据传输时的端口，分别将所传输过来的数据进行数据接收和多线程数据解析。
3. 如权利要求1所述的电梯智能监控系统，其特征在于，所述后台管理模块包括后台管理首页和报警模块；
所述后台管理首页通过Socket编程模型对存储在所述NoSQL数据库中的数据进行实时读取，实时监测电梯的运行状态，如电梯有故障发生，则所述报警模块将故障信息弹窗至所述后台管理首页，并将故障信息及时通知相关人员，以及将故障信息存储在MySQL数据库中，所述后台管理首页还采用了Web服务程序用于查询MySQL数据库中的数据，对电梯的维保进行管理、对电梯运行状态的数据进行管理和对电梯运行状态数据的历史查询。
4. 一种电梯智能监控方法，其特征在于，包括如下步骤：
步骤1：实时采集电梯运行状态的数据；
步骤2：将采集到的电梯运行状态的数据通过传输协议进行传输；
步骤3：对传输的数据进行接收和多线程数据解析；
步骤4：对接收和多线程解析的数据进行存储，采用NoSQL数据库和MySQL数据库完成数据存储，在上述多线程数据解析过程中，如果电梯运行状态正常，则将所解析好的数据存储至NoSQL数据库中，利用Redis将电梯运行状态数据实时存储在所述NoSQL数据库中，并将NoSQL数据库中的数据周期性地保存到MySQL数据库中，如果发现电梯有故障，将故障电梯的信息存储至MySQL数据库中，MySQL数据库用于永久化存储电梯运行状态数据；
步骤5：实时监测电梯运行状态，并对电梯的维保进行管理、对电梯运行状态的数据进行管理和对电梯运行状态数据的历史查询；
所述的步骤1中采用ZigBee与多个传感器所构建的无线传感网络，对电梯运行状态的数据进行实时采集；
所述的步骤2中采用UDP协议进行传输，将数据发送到IP和端口上；
所述的步骤3中采用Socket编程模型和数据解析程序，通过监听数据传输时的端口，分别将所传输过来的数据进行数据接收和多线程数据解析；
所述的步骤5，具体操作方法如下：
步骤5.1：通过Socket编程模型对存储在NoSQL数据库中的数据进行实时读取，实时监测电梯的运行状态；
步骤5.2：如电梯有故障发生，将故障信息存储在MySQL数据库中；
步骤5.3：采用Web服务程序查询MySQL数据库中的数据，对电梯的维保进行管理、对电梯运行状态的数据进行管理和对电梯运行状态数据的历史查询。”
经形式审查合格，国家知识产权局于2019年01月04日依法受理了该复审请求，并将其转送至原审查部门进行前置审查。
原审查部门在前置审查意见书中认为，针对区别特征（1）对电梯数据进行采集和分析/解析属于本领域的公知常识。其中，对数据进行多线程的并行处理以提升处理效率也属于本领域的常规处理方式。针对区别特征（2），对比文件1已经给出了“数据存储可基于NoSQL数据库和MySQL数据库实现”的思想。对比文件2公开了“采用NoSQL数据库和MySQL数据库完成数据存储”以及“将数据存储至NoSQL数据库中，并将NoSQL数据库中的数据保存到MySQL数据库中”。在电梯正常运行时，对电梯的运行状态数据进行及时监控属于本领域的公知常识。本领域技术人员能够想到对对比文件1公开的方法进行改进，以对电梯运行数据进行实时（例如，需对电梯运行状态数据进行实时监控）或定期（例如，需对电梯进行定期维保）的数据库转存，进而实现上述功能。面对如何存储故障数据的问题时，本领域技术人员能够想到将其直接存储至MySQL数据库中，以保证故障数据的及时发现及处理。针对区别特征（3），对电梯的维保进行管理属于本领域的公知常识。针对区别特征（4），对比文件3已经公开了与“采用ZigBee与多个传感器所构建的传感网络，对电梯数据进行实时采集”相应的技术特征。针对区别特征（5），对比文件1给出了“将采集到的数据通过传输协议进行传输”的思想，对比文件3给出了（参见说明书第20段）“基于TCP/IP协议传输数据”的启示。本领域技术人员能够想到选用合适的传输协议进行。而根据OSI参考模型，UDP与TCP均属于传输层协议。因此，权利要求不具备创造性，坚持驳回决定。
随后，国家知识产权局成立合议组对本案进行审理。
合议组于2019年06月21日向复审请求人发出复审通知书，指出：权利要求1-4不具备专利法第22条第3款规定的创造性。复审通知书具体指出权利要求1与对比文件1的区别在于：（1）数据接收模块用于多线程数据解析，数据存储模块对多线程解析的数据进行存储，如果电梯运行状态正常，则将所解析好的数据实时存储至NoSQL数据库中，并将NoSQL数据库中的数据周期性地保存到MySQL数据库中，如果发现电梯有故障，将故障电梯的信息存储至MySQL数据库中，MySQL数据库用于永久化存储电梯运行状态数据；（2）后台管理模块对电梯的维保进行管理；（3）数据采集模块采用ZigBee与多个传感器所构建的无线传感网络，对电梯运行状态的数据进行实时采集，数据传输模块采用UDP协议进行传输，将数据发送到IP和端口上。
对于区别技术特征（1），对比文件2公开了“采用NoSQL数据库和MySQL数据库完成数据存储”以及“将数据存储至NoSQL数据库中，并将NoSQL数据库中的数据保存到MySQL数据库中”，而对电梯数据进行采集和分析/解析属于本领域的公知常识，本领域技术人员能够想到对接收到的电梯运行相关数据进行多线程解析和存储，并在多线程解析的基础上，采用对比文件2中先实时存储在NoSQL数据库中以提升存储效率，后续周期性转存至MySQL数据库中永久存储以提升存储数据安全性的方式。为了提高处理电梯的故障的时效性，并且故障数据相对较少，不宜采用分布式存储再转存的方式，对故障数据采用现有的方式直接存储至MySQL数据库中是本领域技术人员根据电梯监控数据的特点容易想到并实现的方式。
对于区别技术特征（2），后台管理模块还对电梯的维保进行管理，这属于本领域技术人员的常用技术手段。对电梯的维保进行管理属于本领域的公知常识，而具体实现该功能的硬件模块可以根据实际应用需求具体设定。
对于区别技术特征（3），对比文件3公开了“采用ZigBee与多个传感器所构建的传感网络，对电梯数据进行实时采集”，采用无线传感网络进行数据的传输属于本领域技术人员的常用技术手段，本领域技术人员能够想到选用合适的传输协议进行。UDP与TCP均属于传输层协议。在使用UDP协议支持数据传输时，其位于IP层之上，可通过访问UDP层后使用IP层的方式传送数据。同时，UDP协议使用端口号设置数据传输通道。因此其属于本领域的公知常识。因此权利要求1不具备创造性。从属权利要求2、3的附加技术特征或者是本领域的公知常识，或者已被对比文件1所公开，因此权利要求2、3不具备创造性。
权利要求4与对比文件1的区别在于：（1）多线程数据解析，对多线程解析的数据进行存储，如果电梯运行状态正常，则将所解析好的数据实时存储至NoSQL数据库中，并将NoSQL数据库中的数据周期性地保存到MySQL数据库中，如果发现电梯有故障，将故障电梯的信息存储至MySQL数据库中，MySQL数据库用于永久化存储电梯运行状态数据；（2）对电梯的维保进行管理；（3）采用ZigBee与多个传感器所构建的无线传感网络，对电梯运行状态的数据进行实时采集，数据传输模块采用UDP协议进行传输，将数据发送到IP和端口上；（4）采用Socket编程模型和数据解析程序，通过监听数据传输时的端口，分别将所传输过来的数据进行数据接收和多线程数据解析；通过Socket编程模型对存储在NoSQL数据库中的数据进行实时读取，实时监测电梯的运行状态；如电梯有故障发生，将故障信息存储在MySQL数据库中；采用Web服务程序查询MySQL数据库中的数据，对电梯的维保进行管理、对电梯运行状态的数据进行管理和对电梯运行状态数据的历史查询。
对于区别技术特征（1），对比文件2公开了“采用NoSQL数据库和MySQL数据库完成数据存储”以及“将数据存储至NoSQL数据库中，并将NoSQL数据库中的数据保存到MySQL数据库中”，对电梯数据进行采集和分析/解析属于本领域的公知常识，而数据解析采用多线程方式以提高处理效率属于常见的数据处理方式。在电梯正常运行时，对电梯的运行状态数据进行及时监控属于本领域的公知常识。本领域技术人员能够想到对接收到的电梯运行相关数据进行多线程解析和存储，并在多线程解析的基础上，采用对比文件2中先实时存储在NoSQL数据库中以提升存储效率，后续周期性转存至MySQL数据库中永久存储以提升存储数据安全性的方式。同时为了提高处理电梯的故障的时效性，并且故障数据相对较少，不宜采用分布式存储再转存的方式，对故障数据采用现有的方式直接存储至MySQL数据库中是本领域技术人员根据电梯监控数据的特点容易想到并实现的方式。
对于区别技术特征（2），为了对电梯进行全面的监控，后台管理模块还对电梯的维保进行管理，这属于本领域技术人员的常用技术手段。
对于区别技术特征（3），对比文件3公开了“采用ZigBee与多个传感器所构建的传感网络，对电梯数据进行实时采集”，采用无线传感网络进行数据的传输属于本领域技术人员的常用技术手段，本领域技术人员能够想到选用合适的传输协议进行。而根据OSI参考模型，UDP与TCP均属于传输层协议。在使用UDP协议支持数据传输时，其位于IP层之上，可通过访问UDP层后使用IP层的方式传送数据。同时，UDP协议使用端口号设置数据传输通道。因此其属于本领域的公知常识。
对于区别技术特征（4），Socket编程模型和数据解析程序均为常用的编程程序,采用Socket编程模型对存储在数据库中的数据进行读取、将故障通知给相关人员以及采用Web服务程序查询数据库中的数据均属于本领域技术人员的常用技术手段。因此权利要求4不具备创造性。
复审请求人于2019年08月06日提交了意见陈述书，未对申请文件进行修改。复审请求人认为本申请权利要求1与对比文件1相比的区别在于：（1）数据接收模块用于对传输的数据进行多线程数据解析；（2）数据存储模块对多线程解析的数据进行存储，在上述多线程数据解析过程中，如果电梯运行状态正常，则将所解析好的数据存储至NoSQL数据库中，利用Redis将电梯运行状态数据实时存储在所述NoSQL数据库中，并将NoSQL数据库中的数据周期性地保存到MySQL数据库中，如果发现电梯有故障，将故障电梯的信息存储至MySQL数据库中，MySQL数据库用于永久化存储电梯运行状态数据；（3）后台管理模块对电梯的维保进行管理；（4）所述数据采集模块采用ZigBee与多个传感器所构建的无线传感网络，对电梯运行状态的数据进行实时采集；（5）所述数据传输模块采用UDP协议进行传输，将数据发送到IP和端口上。
区别（1）不是公知常识，对于区别（2），本申请与对比文件2在数据存储方面存在明显不同，采用了不同的技术手段，且解决了不同的技术问题，带来了不同的技术效果。审查员之所以认为区别特征（2）是容易想到的，是在本申请技术特征的前提下推理的结果。区别（3）为本申请的必要技术特征，和其他区别技术特征一起共同解决本申请的技术问题。对于区别（4），本申请和对比文件3采用ZigBee解决的技术问题不同，本申请保护的是区别特征（1）至区别特征（5）的整个发明构思，而非其中单个技术特征。因此权利要求具备创造性。
在上述程序的基础上，合议组认为本案事实已经清楚，可以作出审查决定。
二、决定的理由
1、审查文本的认定
复审请求人在2019年08月06日答复复审通知书时，未对申请文件进行修改。因此，本决定所依据的审查文本为申请日2017年08月04日提交的摘要附图、说明书摘要、说明书第1-39段、说明书附图图1-4；2018年11月12日提交的权利要求第1-4项。
2、关于专利法第22条第3款
专利法第22条第3款规定：创造性，是指与现有技术相比，该发明具有突出的实质性特点和显著的进步，该实用新型具有实质性特点和进步。
如果一项权利要求所要求保护的技术方案与作为最接近的现有技术的对比文件相比存在区别技术特征，但是上述区别技术特征或者属于本领域的公知常识，或者被其他对比文件公开，即其他现有技术中给出了将上述区别技术特征应用到该最接近的现有技术以解决其技术问题的启示，从而使得本领域技术人员在现有技术的基础上得到该权利要求的技术方案是显而易见的，那么该权利要求所要求保护的技术方案不具备创造性。
本复审决定中引用原审查部门在驳回决定以及复审通知书中所引用的对比文件1-3作为现有技术，即：
对比文件1：CN104944240A，公开日为2015年09月30日；
对比文件2：CN106339892A，公开日为2017年01月18日；
对比文件3：CN103051708A，公开日为2013年04月17日。
其中，对比文件1作为最接近的现有技术。
（1）权利要求1不符合专利法第22条第3款有关创造性的规定
独立权利要求1请求保护一种电梯智能监控系统。对比文件1公开了一种基于大数据技术的电梯设备的状态监测系统，其中涉及一种电梯智能监控系统，并具体公开了以下内容（参见说明书第5-19段）：数据采集单元由电梯监控数据采集器、多个传感器组等设备组成，电梯系统的传感器组与电梯监控数据采集器组队电梯运行状态数据信息进行实时采集（相当于“数据采集模块用于实时采集电梯运行状态的数据”）；并实时地将数据信息传送给通信系统，通过通信系统单元的GPRS或CDMA、移动通信、卫星通信，将原始数据传入基于open Plant实时数据库系统（相当于“数据传输模块用于将采集到的电梯运行状态的数据通过传输协议进行传输”）；利用open Plant实时数据库系统，采用当今先进的技术和架构，对采集来的数据进行高效的数据压缩和长期的历史存储；存储服务层提供了数据处理层需要的各类分布式存储，包括分布式SQL数据库(MySQL)、分布式NoSQL数据库(Redis、MongoDB、HBase)（相当于“数据接收模块用于对传输的数据进行接收”以及“数据存储模块用于对接收的数据进行存储，采用NoSQL数据库和MySQL数据库完成数据存储，利用Redis将电梯运行状态数据存储在所述NoSQL数据库中”）；可视化展现单元主要包括实时监测模块、历史事件查询模块、数据分析与预警模块（相当于“后台管理模块用于实时监测电梯运行状态，对电梯运行状态的数据进行管理和对电梯运行状态数据的历史查询”）
该权利要求请求保护的技术方案与对比文件1相比，其区别技术特征为：（1）数据接收模块用于多线程数据解析，数据存储模块对多线程解析的数据进行存储，如果电梯运行状态正常，则将所解析好的数据实时存储至NoSQL数据库中，并将NoSQL数据库中的数据周期性地保存到MySQL数据库中，如果发现电梯有故障，将故障电梯的信息存储至MySQL数据库中，MySQL数据库用于永久化存储电梯运行状态数据；（2）后台管理模块对电梯的维保进行管理；（3）数据采集模块采用ZigBee与多个传感器所构建的无线传感网络，对电梯运行状态的数据进行实时采集，数据传输模块采用UDP协议进行传输，将数据发送到IP和端口上。基于上述区别技术特征，该权利要求实际解决的技术问题分别为：如何针对不同数据进行数据的存储；如何对电梯进行全面的监控；如何进行数据采集传输。
对于区别技术特征（1），对比文件2公开了一种基于大数据的实时监测和准确评估方法及系统，并具体公开了以下内容（参见说明书第39-43段）：将处理后的请求数据作为中间数据，并存储在Nosql数据库，极好的满足了对高并发的需求；将中间数据从Nosql数据库转存在Mysql数据库，用于前端页面呈现，实现监测的可视化（相当于“采用NoSQL数据库和MySQL数据库完成数据存储”以及“将数据存储至NoSQL数据库中，并将NoSQL数据库中的数据保存到MySQL数据库中”）。因此，上述有关数据存储的技术特征已经被对比文件2公开，且该特征在对比文件2中所起的作用与其在本发明中所起的作用相同，均是用于“进行数据的存储”，即对比文件2给出了将上述技术特征应用到对比文件1中以进一步解决其技术问题的启示。此外，对比文件2同时给出了对处理后的中间数据进行相关存储的启示，而对电梯数据进行采集和分析/解析属于本领域的公知常识（参见“上海市企业信息化与工业化整合实践与探索”，刘健，复旦大学出版社，2011年12月，第80页“5.电梯远程服务系统”部分：REMES系统是上海三菱自主开发的远程监视和急修服务系统，功能上集成了远程电梯数据采集和统计分析等多种电梯维修保养业务），而数据解析采用多线程方式（例如，设置相应的模块）以提高处理效率属于常见的数据处理方式。“电梯安全管理人员培训考核必读” （夏国柱，机械工业出版社，2010年6月）一书中记载了如下内容（参见第181页）：借助于远程监控智能系统对电梯进行每天24h的运行状况监控，并通过对监控数据的统计分析，…，确保电梯的正常运行。由此可知，在电梯正常运行时，对电梯的运行状态数据进行及时监控属于本领域的公知常识。进一步地，本领域技术人员也能够知道，在电梯正常运行时，需要进行定期的维修保养，此时也要求与电梯运行数据之间的及时交互。由此，在对比文件1公开内容的基础上结合对比文件2及本领域的公知常识，综合考虑采集传输的电梯监控数据的特点，本领域技术人员能够想到对接收到的电梯运行相关数据进行多线程解析和存储，并在多线程解析的基础上，采用对比文件2中先实时存储在NoSQL数据库中以提升存储效率，后续周期性转存至MySQL数据库中永久存储以提升存储数据安全性的方式。同时，“电梯安全管理人员培训考核必读”一书中还记载了如下内容（参见第181页）：通过对电梯所发生的故障进行故障成因、状态、分类、零部件等一系列分析统计。在电梯发生故障时，需及时调出其相关运行状态数据进行分析以排除相应故障。为了提高处理电梯的故障的时效性，并且故障数据相对较少，不宜采用分布式存储再转存的方式，对故障数据采用现有的方式直接存储至MySQL数据库中是本领域技术人员根据电梯监控数据的特点容易想到并实现的方式。
对于区别技术特征（2），为了对电梯进行全面的监控，后台管理模块还对电梯的维保进行管理，这属于本领域技术人员的常用技术手段。参见“电梯安全管理人员培训考核必读”一书中记载了如下内容（参见第181-183页）：由上海新时达软件公司开发的电梯服务管理系统，可提供全面的电梯信息管理平台，该软件主要功能有五大模块；3）大、中修记录表：记载大、中修时间、次数、维修内容等；4）维修合同资料：包括维修单、维修保养记录表等。由此可知，对电梯的维保进行管理属于本领域的公知常识，而具体实现该功能的硬件模块可以根据实际应用需求具体设定。
对于区别技术特征（3），对比文件3公开了一种基于Zigbee技术的电梯物联网系统，并具体公开了以下内容（参见说明书第18、20、25-26段）：Zigbee终端路由节点13将实时采集到的电梯控制器12的信号反馈给Zigbee协调器14，参考图5，每一Zigbee个域网包括设置在每部电梯的轿厢中的红外感应传感器111、与红外感应传感器111的数量相等的电力载波调制模块112及电力载波解调模块113；通过电力载波和随行电缆传输的方式把检测信息传输给Zigbee终端路由节点13，再上传至Zigbee协调器14，通过通信网络把信息传输给监控中心（相当于“采用ZigBee与多个传感器所构建的传感网络，对电梯数据进行实时采集”）。因此，上述技术特征已经被对比文件3公开，且该特征在对比文件3中所起的作用与其在本发明中所起的作用相同，均是用于“进行数据采集”，即对比文件3给出了将上述技术特征应用到对比文件1中以进一步解决其技术问题的启示。其中，采用无线传感网络进行数据的传输属于本领域技术人员的常用技术手段。同时，对比文件3公开了Zigbee协调器14与协议转换器17耦接，协议转换器17用于将Zigbee协调器传送的数据转换成TCP/IP协议的数据，并通过因特网传送给监控中心的应用服务器33（即，基于TCP/IP协议传输数据）”。在此基础上，面对如何传输数据的问题时，本领域技术人员能够想到选用合适的传输协议进行。而根据OSI参考模型，UDP与TCP均属于传输层协议。在使用UDP协议支持数据传输时，其位于IP层之上，可通过访问UDP层后使用IP层的方式传送数据。同时，UDP协议使用端口号设置数据传输通道。因此其属于本领域的公知常识。
由此可知，在对比文件1的基础上结合对比文件2、3以及本领域的公知常识得出权利要求1所要求保护的技术方案对本领域的技术人员来说是显而易见的。因此权利要求1所要求保护的技术方案不具有突出的实质性特点和显著的进步，不具备创造性。
（2）权利要求2-3不符合专利法第22条第3款有关创造性的规定
权利要求2是权利要求1的从属权利要求。Socket编程模型和数据解析程序均为常用的编程程序，采用其对数据进行解析为本领域技术人员可以根据实际应用需求进行选择的方式。因此，当其引用的权利要求不具备创造性时，该从属权利要求所要求保护的技术方案也不具备创造性。
权利要求3是权利要求1的从属权利要求。对比文件1进一步公开了（参见说明书第5-19段）：将存储的数据推送到消息队列Kafka中，Kafka中的数据会被两个处理平台BDM CEP和Storm并行处理，采用现有电梯故障诊断算法对此数据进行分析，从而对设备进行实时监测与故障诊断；若诊断结果为有故障，一方面将分析结果在可视化界面显示，清晰有效地传达与沟通交互，从而实现对冗余且复杂数据集的深入洞察以及时报警处理；另一方面通过通信系统将故障信息传输到设备监测单元，并更新监测状态；若监测为无故障，则继续实时监测（即，对存储数据库中的数据进行实时读取，实时监测电梯的运行状态，如电梯有故障发生，则将故障信息进行显示）。其中，实现相关功能的硬件模块可以根据实际应用需求具体设定。同时，采用Socket编程模型对存储在数据库中的数据进行读取、将故障通知给相关人员以及采用Web服务程序查询数据库中的数据均属于本领域技术人员的常用技术手段。因此，当其引用的权利要求不具备创造性时，该从属权利要求所要求保护的技术方案也不具备专利法第二十二条第三款规定的创造性。
（3）权利要求4不符合专利法第22条第3款有关创造性的规定
独立权利要求4请求保护一种电梯智能监控方法。对比文件1公开了一种基于大数据技术的电梯设备的状态监测系统，其中涉及一种电梯智能监控方法，并具体公开了以下内容（参见说明书第5-19段）：数据采集单元由电梯监控数据采集器、多个传感器组等设备组成，电梯系统的传感器组与电梯监控数据采集器组队电梯运行状态数据信息进行实时采集（相当于“实时采集电梯运行状态的数据”）；并实时地将数据信息传送给通信系统，通过通信系统单元的GPRS或CDMA、移动通信、卫星通信，将原始数据传入基于open Plant实时数据库系统（相当于“将采集到的电梯运行状态的数据通过传输协议进行传输”）；利用open Plant实时数据库系统，采用当今先进的技术和架构，对采集来的数据进行高效的数据压缩和长期的历史存储；存储服务层提供了数据处理层需要的各类分布式存储，包括分布式SQL数据库(MySQL)、分布式NoSQL数据库(Redis、MongoDB、HBase)（相当于“对传输的数据进行接收”以及“对接收的数据进行存储，采用NoSQL数据库和MySQL数据库完成数据存储，利用Redis将电梯运行状态数据存储在所述NoSQL数据库中”）；可视化展现单元主要包括实时监测模块、历史事件查询模块、数据分析与预警模块（相当于“实时监测电梯运行状态，对电梯运行状态的数据进行管理和对电梯运行状态数据的历史查询”）
该权利要求请求保护的技术方案与对比文件1相比，其区别技术特征为：（1）多线程数据解析，对多线程解析的数据进行存储，如果电梯运行状态正常，则将所解析好的数据实时存储至NoSQL数据库中，并将NoSQL数据库中的数据周期性地保存到MySQL数据库中，如果发现电梯有故障，将故障电梯的信息存储至MySQL数据库中，MySQL数据库用于永久化存储电梯运行状态数据；（2）对电梯的维保进行管理；（3）采用ZigBee与多个传感器所构建的无线传感网络，对电梯运行状态的数据进行实时采集，数据传输模块采用UDP协议进行传输，将数据发送到IP和端口上；（4）采用Socket编程模型和数据解析程序，通过监听数据传输时的端口，分别将所传输过来的数据进行数据接收和多线程数据解析；通过Socket编程模型对存储在NoSQL数据库中的数据进行实时读取，实时监测电梯的运行状态；如电梯有故障发生，将故障信息存储在MySQL数据库中；采用Web服务程序查询MySQL数据库中的数据，对电梯的维保进行管理、对电梯运行状态的数据进行管理和对电梯运行状态数据的历史查询。基于上述区别技术特征，该权利要求实际解决的技术问题分别为：如何针对不同数据进行数据的存储；如何对电梯进行全面的监控；如何进行数据采集传输。
对于区别技术特征（1），对比文件2公开了一种基于大数据的实时监测和准确评估方法及系统，并具体公开了以下内容（参见说明书第39-43段）：将处理后的请求数据作为中间数据，并存储在Nosql数据库，极好的满足了对高并发的需求；将中间数据从Nosql数据库转存在Mysql数据库，用于前端页面呈现，实现监测的可视化（相当于“采用NoSQL数据库和MySQL数据库完成数据存储”以及“将数据存储至NoSQL数据库中，并将NoSQL数据库中的数据保存到MySQL数据库中”）。因此，上述有关数据存储的技术特征已经被对比文件2公开，且该特征在对比文件2中所起的作用与其在本发明中所起的作用相同，均是用于“进行数据的存储”，即对比文件2给出了将上述技术特征应用到对比文件1中以进一步解决其技术问题的启示。此外，对比文件2同时给出了对处理后的中间数据进行相关存储的启示，而对电梯数据进行采集和分析/解析属于本领域的公知常识，而数据解析采用多线程方式以提高处理效率属于常见的数据处理方式。在电梯正常运行时，对电梯的运行状态数据进行及时监控属于本领域的公知常识。进一步地，本领域技术人员也能够知道，在电梯正常运行时，需要进行定期的维修保养，此时也要求与电梯运行数据之间的及时交互。由此，在对比文件1公开内容的基础上结合对比文件2及本领域的公知常识，综合考虑采集传输的电梯监控数据的特点，本领域技术人员能够想到对接收到的电梯运行相关数据进行多线程解析和存储，并在多线程解析的基础上，采用对比文件2中先实时存储在NoSQL数据库中以提升存储效率，后续周期性转存至MySQL数据库中永久存储以提升存储数据安全性的方式。同时为了提高处理电梯的故障的时效性，并且故障数据相对较少，不宜采用分布式存储再转存的方式，对故障数据采用现有的方式直接存储至MySQL数据库中是本领域技术人员根据电梯监控数据的特点容易想到并实现的方式。
对于区别技术特征（2），为了对电梯进行全面的监控，后台管理模块还对电梯的维保进行管理，这属于本领域技术人员的常用技术手段。
对于区别技术特征（3），对比文件3公开了一种基于Zigbee技术的电梯物联网系统，并具体公开了以下内容（参见说明书第18、20、25-26段）：Zigbee终端路由节点13将实时采集到的电梯控制器12的信号反馈给Zigbee协调器14，参考图5，每一Zigbee个域网包括设置在每部电梯的轿厢中的红外感应传感器111、与红外感应传感器111的数量相等的电力载波调制模块112及电力载波解调模块113；通过电力载波和随行电缆传输的方式把检测信息传输给Zigbee终端路由节点13，再上传至Zigbee协调器14，通过通信网络把信息传输给监控中心（相当于“采用ZigBee与多个传感器所构建的传感网络，对电梯数据进行实时采集”）。因此，上述技术特征已经被对比文件3公开，且该特征在对比文件3中所起的作用与其在本发明中所起的作用相同，均是用于“进行数据采集”，即对比文件3给出了将上述技术特征应用到对比文件1中以进一步解决其技术问题的启示。其中，采用无线传感网络进行数据的传输属于本领域技术人员的常用技术手段。同时，对比文件3公开了Zigbee协调器14与协议转换器17耦接，协议转换器17用于将Zigbee协调器传送的数据转换成TCP/IP协议的数据，并通过因特网传送给监控中心的应用服务器33（即，基于TCP/IP协议传输数据）”。在此基础上，面对如何传输数据的问题时，本领域技术人员能够想到选用合适的传输协议进行。而根据OSI参考模型，UDP与TCP均属于传输层协议。在使用UDP协议支持数据传输时，其位于IP层之上，可通过访问UDP层后使用IP层的方式传送数据。同时，UDP协议使用端口号设置数据传输通道。因此其属于本领域的公知常识。
对于区别技术特征（4），Socket编程模型和数据解析程序均为常用的编程程序，采用其对数据进行解析为本领域技术人员可以根据实际应用需求进行选择的方式。对比文件1进一步公开了（参见说明书第5-19段）：将存储的数据推送到消息队列Kafka中，Kafka中的数据会被两个处理平台BDM CEP和Storm并行处理，采用现有电梯故障诊断算法对此数据进行分析，从而对设备进行实时监测与故障诊断；若诊断结果为有故障，一方面将分析结果在可视化界面显示，清晰有效地传达与沟通交互，从而实现对冗余且复杂数据集的深入洞察以及时报警处理；另一方面通过通信系统将故障信息传输到设备监测单元，并更新监测状态；若监测为无故障，则继续实时监测（即，对存储数据库中的数据进行实时读取，实时监测电梯的运行状态，如电梯有故障发生，则将故障信息进行显示）。其中，实现相关功能的硬件模块可以根据实际应用需求具体设定。同时，采用Socket编程模型对存储在数据库中的数据进行读取、将故障通知给相关人员以及采用Web服务程序查询数据库中的数据均属于本领域技术人员的常用技术手段。
由此可知，在对比文件1的基础上结合对比文件2、3以及本领域的公知常识得出权利要求4所要求保护的技术方案对本领域的技术人员来说是显而易见的。因此权利要求4所要求保护的技术方案不具有突出的实质性特点和显著的进步，不具备创造性。
3、对复审请求人相关意见的评述
针对复审请求人的相关意见，合议组认为：对电梯数据进行采集和分析/解析属于本领域的公知常识。其中，对数据进行多线程的并行处理以提升处理效率也属于本领域的常规处理方式。
对比文件2公开了“采用NoSQL数据库和MySQL数据库完成数据存储”以及“将数据存储至NoSQL数据库中，并将NoSQL数据库中的数据保存到MySQL数据库中”。虽然对比文件2中将中间数据从Nosql数据库转存在Mysql数据库，用于前端页面呈现，实现监测的可视化，但其公开了将海量数据作为中间数据先存储在Nosql数据库中，再从Nosql数据库转存在Mysql数据库的数据存储机制，其同样应用于海量数据的存储。此外，对比文件2同时给出了对处理后的中间数据进行相关存储的启示。由此可知，在电梯正常运行时，对电梯的运行状态数据进行及时监控属于本领域的公知常识。进一步地，本领域技术人员也能够知道，在电梯正常运行时，需要进行定期的维修保养，此时也要求与电梯运行数据之间的及时交互。由此，在对比文件1公开内容的基础上结合对比文件2及本领域的公知常识，综合考虑采集传输的电梯监控数据的特点，本领域技术人员能够想到对接收到的电梯运行相关数据进行多线程解析和存储，并在多线程解析的基础上，采用对比文件2中先实时存储在NoSQL数据库中以提升存储效率，后续周期性转存至MySQL数据库中永久存储以提升存储数据安全性的方式。为了提高处理电梯的故障的时效性，并且故障数据相对较少，不宜采用分布式存储再转存的方式，对故障数据采用现有的方式直接存储至MySQL数据库中是本领域技术人员根据电梯监控数据的特点容易想到并实现的方式。
为了对电梯进行全面的监控，后台管理模块还对电梯的维保进行管理，这属于本领域技术人员的常用技术手段。
对比文件3公开了“采用ZigBee与多个传感器所构建的传感网络，对电梯数据进行实时采集”。其中，采用无线传感网络进行数据的传输属于本领域技术人员的常用技术手段。同时，对比文件3公开了Zigbee协调器14与协议转换器17耦接，协议转换器17用于将Zigbee协调器传送的数据转换成TCP/IP协议的数据，并通过因特网传送给监控中心的应用服务器33（即，基于TCP/IP协议传输数据）”。在此基础上，面对如何传输数据的问题时，本领域技术人员能够想到选用合适的传输协议进行。而根据OSI参考模型，UDP与TCP均属于传输层协议。在使用UDP协议支持数据传输时，其位于IP层之上，可通过访问UDP层后使用IP层的方式传送数据。同时，UDP协议使用端口号设置数据传输通道。因此其属于本领域的公知常识。
因此，合议组不能接受复审请求人的意见陈述。
三、决定
维持国家知识产权局于2018年08月 14日对本申请作出的驳回决定。
如对本复审请求审查决定不服，根据专利法第41条第2款的规定，复审请求人可自收到本决定之日起三个月内向北京知识产权法院起诉。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
