CN112817789B - 一种基于浏览器传输的建模方法及装置 - Google Patents

Abstract

本发明实施例提供了一种基于浏览器传输的建模方法及装置，该方法包括建模端接收Web端发送的建模状况获取请求，将Web端的建模状况发送给Web端，根据Web端针对建模状况的建模响应确定是否继续Web端的建模。如此，由于建模端可以准确地将在Web端异常之前收到的建模数据的建模状况发送给Web端，因此可以便于Web端及时准确地获知建模数据的建模状况，并基于建模数据的建模状况确定是否继续在建模端进行建模数据的建模，以避免存在现有技术中Web端不知道建模数据的建模状况而需要重新传输浏览器异常之前的建模数据给建模端的情况，并有助于提高针对建模状况的建模响应确定是否继续Web端的建模的灵活性。

Description

一种基于浏览器传输的建模方法及装置

技术领域

本发明实施例涉及数据存储技术领域，尤其涉及一种基于浏览器传输的建模方法及装置。

背景技术

现阶段，随着计算机技术的快速发展，越来越多的用户开始使用Web浏览器进行网页访问，比如通过访问的网页进行上传数据等。然而，由于Web浏览器负载过多或本身出现故障等，会导致用户在使用Web浏览器进行数据上传的过程中会出现Web浏览器异常关闭的情况，使得用户无法进行正常的数据上传，即使用户重新打开Web浏览器，可能也只是恢复至之前所打开的访问网页，导致用户需要重新上传之前已经上传的数据。

综上，目前亟需一种基于浏览器传输的建模方法，用以及时准确地获知建模数据的建模状况，以避免重新传输浏览器异常之前的建模数据。

发明内容

本发明实施例提供了一种基于浏览器传输的建模方法及装置，用以及时准确地获知建模数据的建模状况，以避免重新传输浏览器异常之前的建模数据。

第一方面，本发明实施例提供了一种基于浏览器传输的建模方法，包括：

建模端接收Web端发送的建模状况获取请求；所述建模状况获取请求是所述Web端在传输建模数据至所述建模端的过程中发生异常重启后发送的；

所述建模端将所述Web端的建模状况发送给所述Web端；所述建模状况用于指示所述建模端在所述Web端异常之前收到的建模数据的建模状况；

所述建模端根据所述Web端针对所述建模状况的建模响应确定是否继续所述Web端的建模。

上述技术方案中，Web端在传输建模数据至建模端的过程中发生异常重启后会向建模端发送建模状况获取请求，以使建模端可以将Web端的建模状况发送给Web端，并根据Web端针对建模状况的建模响应确定是否继续Web端的建模。如此，由于建模端可以准确地将在Web端异常之前收到的建模数据的建模状况发送给Web端，因此可以便于Web端及时准确地获知建模数据的建模状况，并基于建模数据的建模状况确定是否继续在建模端进行建模数据的建模，以避免存在现有技术中Web端不知道建模数据的建模状况而需要重新传输浏览器异常之前的建模数据给建模端的情况，如此可以给用户带来极大的便利，以提升用户的体验，并有助于提高针对建模状况的建模响应确定是否继续Web端的建模的灵活性。

可选地，在建模端接收Web端发送的建模状况获取请求之前，还包括：

所述建模端记录从所述Web端获取的各建模数据；

所述建模端记录所述各建模数据的建模状态，所述建模状态包括已建模和未建模；

所述建模端将记录的所述各建模数据的建模状态作为所述Web端的建模状况。

上述技术方案中，建模端会记录从Web端获取的各建模数据，并针对各建模数据进行建模，同时会记录各建模数据的建模状况。如此，由于建模端对各建模数据的建模状况进行存储，因此在Web端因异常重启而需要获知建模数据的建模状况时，可以及时准确地将建模数据的建模状况反馈给Web端，以便Web端可以灵活地选择是否继续进行建模数据的建模。

可选地，所述建模响应为继续建模；

所述建模端根据所述Web端针对所述建模状况的建模响应确定是否继续所述Web端的建模，包括：

所述建模端确定已收到的建模数据中存在尚未进行建模的建模数据；

所述建模端对所述尚未进行建模的建模数据进行建模。

上述技术方案中，基于Web端给出的建模响应为继续建模，则建模端可以在确定已收到的建模数据中存在尚未进行建模的建模数据时，对尚未进行建模的建模数据进行建模，如此可以增加用户在数据建模过程中的参与度，以提高针对Web端选择是否继续进行数据建模的灵活性，同时可以确保建模端中尚未进行建模的建模数据的顺利建模。

可选地，所述建模响应为停止建模；

所述建模端根据所述Web端针对所述建模状况的建模响应确定是否继续所述Web端的建模，包括：

所述建模端在确定所述建模响应为停止建模时，对本地存储的所述建模状况进行初始化。

上述技术方案中，在确定建模响应为停止建模时，对本地存储的建模状况进行初始化处理，可以释放建模端的缓存空间，以减轻建模端的缓存压力。同时，可以避免本次的建模状况影响后续的再次建模，并可以便于后续能够及时准确地建模。

第二方面，本发明实施例提供了一种基于浏览器传输的建模方法，包括：

Web端在传输建模数据至建模端的过程中检测到自身异常关闭并重启后，生成建模状况获取请求；

所述Web端将所述建模状况获取请求发送给所述建模端；所述建模状况获取请求用于从所述建模端获取所述Web端的建模状况；所述建模状况用于指示所述建模端在所述Web端异常之前收到的建模数据的建模状况；

所述Web端接收用户针对所述建模状况的建模响应并将所述建模响应发送至所述建模端；所述建模响应用于指示所述建模端是否继续所述Web端的建模。

上述技术方案中，Web端在传输建模数据至建模端的过程中检测到自身异常关闭并重启后，生成建模状况获取请求，并基于建模状况获取请求从建模端获取建模状况。再将用户针对建模状况的建模响应发送给建模端，以使建模端基于建模响应确定是否继续Web端的建模。如此，由于建模端可以准确地将在Web端异常之前收到的建模数据的建模状况发送给Web端，因此可以便于Web端及时准确地获知建模数据的建模状况，并基于建模数据的建模状况确定是否继续在建模端进行建模数据的建模，以避免存在现有技术中Web端不知道建模数据的建模状况而需要重新传输浏览器异常之前的建模数据给建模端的情况，如此可以给用户带来极大的便利，以提升用户的体验，并有助于提高针对建模状况的建模响应确定是否继续Web端的建模的灵活性。

可选地，所述Web端接收用户针对所述建模状况的建模响应并将所述建模响应发送至所述建模端，包括：

所述Web端若确定所述建模响应为继续建模，则生成继续建模指令，并将所述继续建模指令发送给所述建模端；所述继续建模指令用于指示所述建模端基于已收到的建模数据中存在尚未进行建模的建模数据进行建模。

上述技术方案中，在确定建模响应为继续建模时，生成继续建模指令，并将该继续建模指令发送给建模端，以使建模端可以基于继续建模指令及时准确地对尚未进行建模的建模数据进行建模。如此，可以增加用户的参与度，并给予用户更灵活的选择性，使得用户可以根据自身实际需求确定针对尚未进行建模的建模数据是否继续进行建模。

可选地，所述Web端接收用户针对所述建模状况的建模响应并将所述建模响应发送至所述建模端，包括：

所述Web端若确定所述建模响应为停止建模，则生成停止建模指令，并将所述停止建模指令发送给所述建模端；所述停止建模指令用于指示所述建模端对本地存储的所述建模状况进行初始化。

上述技术方案中，在确定建模响应为停止建模时，生成停止建模指令，并将停止建模指令发送给建模端，以使建模端可以基于停止建模指令及时地停止建模。如此，可以给予用户更灵活的选择性，使得建模端可以在用户选择停止建模的指示下及时地停止建模，从而增加用户的参与度。

第三方面，本发明实施例提供了一种基于浏览器传输的建模装置，包括：

接收单元，用于接收Web端发送的建模状况获取请求；所述建模状况获取请求是所述Web端在传输建模数据至所述建模端的过程中发生异常重启后发送的；

第一处理单元，用于将所述Web端的建模状况发送给所述Web端；所述建模状况用于指示所述建模端在所述Web端异常之前收到的建模数据的建模状况；根据所述Web端针对所述建模状况的建模响应确定是否继续所述Web端的建模。

可选地，所述第一处理单元还用于：

在接收Web端发送的建模状况获取请求之前，记录从所述Web端获取的各建模数据；

记录所述各建模数据的建模状态，所述建模状态包括已建模和未建模；

将记录的所述各建模数据的建模状态作为所述Web端的建模状况。

可选地，所述建模响应为继续建模；

所述第一处理单元具体用于：

确定已收到的建模数据中存在尚未进行建模的建模数据；

对所述尚未进行建模的建模数据进行建模。

可选地，所述建模响应为停止建模；

所述第一处理单元具体用于：

在确定所述建模响应为停止建模时，对本地存储的所述建模状况进行初始化。

第四方面，本发明实施例提供了一种基于浏览器传输的建模装置，包括：

生成单元，用于在传输建模数据至建模端的过程中检测到自身异常关闭并重启后，生成建模状况获取请求；

第二处理单元，用于将所述建模状况获取请求发送给所述建模端；所述建模状况获取请求用于从所述建模端获取所述Web端的建模状况；所述建模状况用于指示所述建模端在所述Web端异常之前收到的建模数据的建模状况；接收用户针对所述建模状况的建模响应并将所述建模响应发送至所述建模端；所述建模响应用于指示所述建模端是否继续所述Web端的建模。

可选地，所述第二处理单元具体用于：

若确定所述建模响应为继续建模，则生成继续建模指令，并将所述继续建模指令发送给所述建模端；所述继续建模指令用于指示所述建模端基于已收到的建模数据中存在尚未进行建模的建模数据进行建模。

可选地，所述第二处理单元具体用于：

若确定所述建模响应为停止建模，则生成停止建模指令，并将所述停止建模指令发送给所述建模端；所述停止建模指令用于指示所述建模端对本地存储的所述建模状况进行初始化。

第五方面，本发明实施例提供一种计算设备，包括至少一个处理器以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行上述第一方面和第二方面任意所述的基于浏览器传输的建模方法。

第六方面，本发明实施例提供一种计算机可读存储介质，其存储有可由计算设备执行的计算机程序，当所述程序在所述计算设备上运行时，使得所述计算设备执行上述第一方面和第二方面任意所述的基于浏览器传输的建模方法。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种系统架构的示意图；

图2为本发明实施例提供的一种基于浏览器传输的建模方法的流程示意图；

图3为本发明实施例提供的一种基于浏览器传输的建模装置的结构示意图；

图4为本发明实施例提供的另一种基于浏览器传输的建模装置的结构示意图；

图5为本发明实施例提供的一种计算设备的结构示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

图1为本发明实施例提供的一种系统架构。如图1所示，该系统架构可以为服务器100，包括处理器110、通信接口120和存储器130。

其中，通信接口120用于与终端设备进行通信，收发该终端设备传输的信息，实现通信。

处理器110是服务器100的控制中心，利用各种接口和线路连接整个服务器100的各个部分，通过运行或执行存储在存储器130内的软件程序/或模块，以及调用存储在存储器130内的数据，执行服务器100的各种功能和处理数据。可选地，处理器110可以包括一个或多个处理单元。

存储器130可用于存储软件程序以及模块，处理器110通过运行存储在存储器130的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器130可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据业务处理所创建的数据等。此外，存储器130可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

需要说明的是，上述图1所示的结构仅是一种示例，本发明实施例对此不做限定。

基于上述描述，图2示例性的示出了本发明实施例提供的一种基于浏览器传输的建模方法的流程，该流程可以由基于浏览器传输的建模装置执行。

如图2所示，该流程具体包括：

步骤201，Web端在传输建模数据至建模端的过程中检测到自身异常关闭并重启后，生成建模状况获取请求。

步骤202，所述Web端将所述建模状况获取请求发送给所述建模端。

步骤203，所述建模端基于所述建模状况获取请求从本地记录中获取所述Web端的建模状况。

步骤204，所述建模端将所述Web端的建模状况发送给所述Web端。

步骤205，所述Web端接收用户针对所述建模状况的建模响应。

步骤206，所述Web端将所述建模响应发送给所述建模端。

步骤207，所述建模端根据所述Web端针对所述建模状况的建模响应确定是否继续所述Web端的建模。

上述步骤201和步骤202中，Web端在传输建模数据至建模端的过程中检测到自身异常关闭并重启后，生成建模状况获取请求，并将建模状况获取请求发送给建模端，如此，可以便于Web端及时准确地获知建模数据的建模状况，以供Web端的用户基于该建模状况可选择是否继续进行建模，从而提升用户选择的灵活性，并增加用户的参与度。其中，建模状况获取请求用于从建模端获取Web端的建模状况；建模状况用于指示建模端在Web端异常之前收到的建模数据的建模状况。

上述步骤203和步骤204中，建模端基于建模状况获取请求从本地记录中获取Web端的建模状况，并将Web端的建模状况发送给Web端。具体地，在建模端接收Web端发送的建模状况获取请求之前，建模端记录从Web端获取的各建模数据，并记录各建模数据的建模状态。再将记录的各建模数据的建模状态作为Web端的建模状况。然后在接收到建模状况获取请求后从本地记录中获取Web端的建模状况并将该Web端的建模状况发送给Web端。如此，由于建模端对各建模数据的建模状况进行存储，因此在Web端因异常重启而需要获知建模数据的建模状况时，可以及时准确地将建模数据的建模状况反馈给Web端，以便Web端可以灵活地选择是否继续进行建模数据的建模。其中，建模状态包括已建模和未建模。

上述步骤205和步骤206中，Web端接收用户针对建模状况的建模响应，并将该建模响应发送给建模端。具体地，Web端若确定建模响应为继续建模，则生成继续建模指令，并将继续建模指令发送给建模端，以使建模端基于已收到的建模数据中存在尚未进行建模的建模数据及时准确地进行建模。如此，可以增加用户的参与度，并给予用户更灵活的选择性，使得用户可以根据自身实际需求确定针对尚未进行建模的建模数据是否继续进行建模。此外，Web端若确定建模响应为停止建模，则生成停止建模指令，并将停止建模指令发送给建模端，以使建模端可以基于停止建模指令及时地停止建模。如此，可以给予用户更灵活的选择性，使得建模端可以在用户选择停止建模的指示下及时地停止建模，从而增加用户的参与度。其中，该停止建模指令用于指示建模端对本地存储的建模状况进行初始化。

上述步骤207中，建模端根据Web端针对建模状况的建模响应确定是否继续Web端的建模。具体地，若确定该建模状况的建模响应为继续建模，则建模端在确定已收到的建模数据中存在尚未进行建模的建模数据时，对尚未进行建模的建模数据进行建模。如此可以增加用户在数据建模过程中的参与度，以提高针对Web端选择是否继续进行数据建模的灵活性，同时可以确保建模端中尚未进行建模的建模数据的顺利建模。若确定该建模状况的建模响应为停止建模，则建模端在确定建模响应为停止建模时，对本地存储的所述建模状况进行初始化。如此，可以释放建模端的缓存空间，以减轻建模端的缓存压力。同时，可以避免本次的建模状况影响后续的再次建模，并可以便于后续能够及时准确地建模。

需要说明的是，无论使用哪个浏览器登录建模端的Web端，均可以在浏览器异常关闭时，选择恢复浏览器异常关闭之前的状态，因为建模相关的数据不是存储在浏览器的缓存里面或相关配置列表里面，而是存储在建模端，可以从建模端的数据库进行数据的提取，并且该建模相关的数据保持实时更新，因此也可以保证数据的有效性。此外，由于浏览器异常关闭的原因有很多(比如Web浏览器负载过多、本身出现故障或Web浏览器所在终端设备的电源突然断开或Web浏览器的程序出错等)，本发明实施例的技术方案可以确保所有建模相关的数据直接取决于建模端，是否需要恢复浏览器异常关闭之前的建模相关的数据取决于建模端的标志位，直接将建模相关的数据和浏览器进行一对一对话，如此可以保证数据的真实有效性。当然，采用该方法，可以将建模相关的数据存储在建模端，而不是存储在浏览器的缓存列表，因此，在浏览器异常关闭并重启时，就可以从建模端获取浏览器异常关闭之前的建模相关的数据并在Web端进行显示，如此可以尽可能地排除意外情况(浏览器异常关闭致使缓存列表中的数据被清除等)对数据建模的干扰。

有鉴于此，下面以用户在进行人脸图片注册上传且设备端正在提取人脸图片的特征值时，Web浏览器出现异常关闭的情况为例，针对Web浏览器异常关闭并重启后，本发明实施例中基于浏览器传输的建模方法的实施过程进行具体描述。

Step1：Web端界面初始化时，向设备端发送用于获取Web端界面异常关闭之前数据建模信息的请求。

示例性地，企业(比如公司或工厂等)为了确保企业相关信息(比如财产信息等)的安全性或为了及时追踪到对企业进性非正常操作给企业带来损害的人员，因此需要针对进入企业的人员进行人脸识别，以确保进入企业的人员为本企业的员工。如此，需要采集或收集企业员工的人脸图片，并将采集或收集来的大量人脸图片进行注册上传至设备端，以便设备端可以及时准确地识别进入企业的人员是否为本企业的员工，从而可以为企业起到安全防护的作用，以确保企业相关信息的安全性。

需要说明的是，在对人脸图片进行提取特征值(比如可以用建模表示提取人脸图片特征值)之前，处理用户需要将人脸图片导入到设备端进行建模。在人脸图片的导入过程中，本发明实施例是在人脸图片上传到设备端后延迟3秒开始建模。其中，导入人脸图片数量、导入成功人脸图片数量以及针对人脸图片的建模成功失败数量可以由设备端实时更新，并将导入人脸图片数量、导入成功人脸图片数量以及针对人脸图片的建模成功失败数量等发送给Web端，以便在Web端界面进行显示。此外，会在设备端设置一个状态标识位，用于判定所有人脸图片的建模是否已全部完成，以及一些变量(比如需要导入数量、建模数量、导入成功失败数量、建模成功失败数量、图片路径等)，用来实时记录人脸图片建模相关的数据情况。而且设备端设置有提取人脸图片的特征值的模型，以便针对导入进来的人脸图片进行特征值的提取。如此，由于将人脸图片的建模信息存储在设备端，并基于状态标识位来确定是否继续执行建模未完成的人脸图片的建模，而无需重新上传浏览器异常关闭之前已经上传的人脸图片，有助于节省设备端与Web端之间的网络传输负荷，并可以提高用户的使用体验。

其中，以企业需要对企业员工的人脸图片进行建模为例，Web端为该企业所拥有的Web界面端，可以位于终端设备(比如笔记本电脑或台式电脑等)的Web浏览器中；设备端(建模端)为该企业需要对企业员工的人脸图片进行建模的数据处理端，可以安装在该企业需要监控的位置区域中，当然，设备端(比如远程监控摄像头或网络人远程监控摄像机等)也可以用于采集进入该企业监控区域的人员的人脸图片；Web端与设备端之间可以通过有线方式或无线方式进行通信连接。此外，应当理解，建模端可以为设备端中的处理单元，即，建模端可以为集成芯片、系统芯片或中央处理器等，或者也可以认为建模端即为设备端。

在将企业员工的人脸图片进行采集或收集到服务端(比如台式电脑、笔记本电脑、平板电脑等)的本地(比如硬盘等)进行存储后，处理用户从服务端本地将需要注册上传的人脸图片上传到Web端，再从Web端将人脸图片进行注册上传到设备端进行人脸图片的建模。然而，在进行人脸图片注册上传的过程中，Web浏览器突然出现异常关闭的情况，导致人脸图片无法正常的进行注册上传。此时，处理用户会在Web浏览器异常关闭后，重新打开Web浏览器，并进入到之前上传人脸图片的Web端界面(比如可以通过Web浏览器缓存的历史记录进入之前上传人脸图片的Web端界面或者在Web浏览器上重新输入之前上传人脸图片的Web端界面的网址进入)。Web端界面进行初始化时，会向设备端发送用于获取Web端界面异常关闭之前人脸图片建模信息(即获取Web端界面异常关闭之前导入人脸图片和建模的情况)的请求，以便处理用户可选择性地恢复Web端界面异常关闭之前人脸图片的注册建模相关情况。如此，可以增加用户的参与度，并可以提高对人脸图片进行注册建模的灵活性。

需要说明的是，在Web浏览器突然出现异常关闭的情况时，设备端会停止执行针对人脸图片的建模(此时可能会有部分人脸图片的建模未完成，也有可能人脸图片的建模全部完成)。即，设备端会定时(比如1秒、2秒、3秒等)的向Web浏览器发送心跳请求，该心跳请求用于确定设备端与Web浏览器之间的通信状态，如果在指定时间内(比如1秒、2秒、3秒等)未接收到Web浏览器的心跳响应，则判断设备端与Web浏览器的通信连接已经中断。基于此，在Web浏览器突然出现异常关闭的情况时，则设备端在指定时间内接收不到Web浏览器的心跳响应，则确定与Web浏览器的通信连接已经中断，此时会停止执行针对人脸图片的建模，以等待Web浏览器发送继续建模指令，直到接收到Web浏览器发送的继续建模指令时，才会继续执行人脸图片的建模。

Step2：设备端在接收到请求后，基于状态标识位，确定所有需要建模的数据是否已全部完成建模。

示例性地，设备端在接收到请求后，根据状态标识位，确定人脸图片导入设备端是否全部完成，如果确定人脸图片导入设备端已全部完成，则根据状态标识位，确定人脸图片的建模是否全部完成。

Step3：若设备端确定人脸图片导入设备端和人脸图片的建模均已全部完成，则将当前的注册建模结果(比如人脸图片导入设备端和人脸图片的建模均已全部完成的消息等)发送给Web端，以便在Web端界面进行显示。同时，设备端将自动根据该当前的注册建模结果对所有相关实时变量(比如所需注册数赋为零、所需建模数赋为零等)进行初始化处理。

需要说明的是，在Web端界面进行显示，可以显示需要导入数量、建模数量、导入成功失败数量、建模成功失败数量等，也可以显示导入成功失败数量百分占比以及建模成功失败数量百分占比等，本发明实施例对此并不作限定。

Step4：若设备端确定人脸图片导入设备端已全部完成，但人脸图片的建模未全部完成，则将当前的注册建模结果(比如人脸图片导入设备端已全部完成且人脸图片的建模未全部完成的消息等)发送给Web端，以便Web端界面增加提示语，让处理用户选择是否需要恢复Web端界面异常关闭之前人脸图片的注册建模相关情况。

示例性地，如果用户选择不需要恢复Web端界面异常关闭之前人脸图片的注册建模相关情况，则Web端会将用户选择的不需要恢复指令下发给设备端，以便设备端不再对设备端已存储的多张人脸图片中建模未完成的人脸图片进行建模。同时，设备端将根据用户选择的不需要恢复指令对所有相关实时变量(比如所需注册数赋为零、所需建模数赋为零等)进行初始化处理。如果用户选择需要恢复Web端界面异常关闭之前人脸图片的注册建模相关情况，则设备端会将用户选择的需要恢复指令下发给设备端，设备端根据用户选择的需要恢复指令，将当前的注册建模进度数据(比如人脸图片导入数量、当前的建模成功失败数量)发送给Web端，以便在Web端界面进行显示。同时，Web端会下发针对设备端已存储的多张人脸图片中建模未完成的人脸图片的继续建模指令给设备端，或者Web端下发从次序号为多少的人脸图片开始进行继续建模的指令给设备端，以便设备端在接收到继续建模指令后，通知设备端的底层系统开始进行建模，底层系统会实时通知设备端人脸图片的建模情况，同时由设备端实时通知Web端进行同步更新并显示人脸图片的建模情况(比如建模成功一张人脸图片，Web端显示会实时增加并显示)。如此，可以实现直接将人脸图片的建模信息在设备端与Web端之间进行一对一交互，以确保人脸图片的建模信息的真实有效性。

例如，在Web端界面异常关闭时，服务端已经将100张人脸图片全部导入到设备端，设备端只对其中70张人脸图片进行了建模，还有30张人脸图片未进行建模。则如果用户选择不需要恢复Web端界面异常关闭之前人脸图片的注册建模相关情况，则Web端会将用户选择的不需要恢复指令下发给设备端，以便设备端不再对30张未进行建模的人脸图片进行建模。同时，设备端将根据用户选择的不需要恢复指令对所有相关实时变量进行初始化处理。如果用户选择需要恢复Web端界面异常关闭之前人脸图片的注册建模相关情况，则设备端会将用户选择的需要恢复指令下发给设备端，设备端根据用户选择的需要恢复指令，将当前的注册建模进度数据(比如导入100张人脸图片到设备端、100张人脸图片中有70张人脸图片已建模和30张人脸图片未建模)发送给Web端，以便在Web端界面进行显示。同时，Web端会下发针对30张未进行建模的人脸图片进行继续建模的指令给Web端，或者下发从顺序号为71的人脸图片开始进行继续建模的指令(即继续进行针对顺序号为71到100的人脸图片的建模)给Web端，以便设备端在接收到继续建模指令后，通知底层系统针对30张未进行建模的人脸图片(或顺序号为71到100的人脸图片)进行继续建模。同时设备端会实时通知Web端进行同步更新并显示人脸图片的建模情况(比如建模成功一张人脸图片，Web端显示会实时增加并显示)。

当然，70张已建模的人脸图片中也有可能存在建模失败的人脸图片，即该70张已建模的人脸图片包括建模成功的人脸图片和建模失败的人脸图片。针对该建模失败的人脸图片，可以基于该建模失败的人脸图片对应的图片路径从设备端的人脸图片存储区域中提取出该建模失败的人脸图片，并利用人脸图片特征提取模型对该建模失败的人脸图片进行重新建模。示例性地，该70张已建模的人脸图片包括65张建模成功的人脸图片和5张建模失败的人脸图片，针对5张建模失败的人脸图片，可以基于该5张建模失败的人脸图片对应的图片路径，从设备端的人脸图片存储区域中提取出该5张建模失败的人脸图片，并利用人脸图片特征提取模型对该5张建模失败的人脸图片进行重新建模(即重新提取人脸图片特征值)，直至建模成功。

需要说明的是，服务端会将人脸图片导入到设备端进行存储(比如存储到缓存列表里或存储在本地的文件夹里或者存储到本地的内存里等)，因此在需要对人脸图片进行建模时，需要从人脸图片对应的图片路径里提取出图片进行下一步的建模操作。

Step5：若设备端确定人脸图片导入设备端未全部完成，则将当前的注册建模结果(比如人脸图片导入设备端未全部完成的消息，以及人脸图片导入成功失败数量、建模成功失败数量等)发送给Web端，以便Web端界面增加提示语，让处理用户选择是否需要恢复Web端界面异常关闭之前人脸图片的注册建模相关情况。

需要说明的是，针对人脸图片导入设备端未全部完成的情况，人脸图片建模的总量为已经导入到设备端的人脸图片。由于导入人脸图片是存储在设备端本地(即人脸图片的存储路径已知，在对人脸图片进行建模时，需要从人脸图片对应的图片路径里提取出图片进行建模)，因此如果导入人脸图片时，未能全部完成(即人脸图片未能全部导入到设备端)，理论上应该不能继续导入剩下的图片。示例性地，如果处理用户需要导入100张人脸图片到设备端，却在Web端界面异常关闭时只导入70张人脸图片到设备端，因此，对于设备端来说，人脸图片的建模总量为只导入到设备端的70张人脸图片，而另外30张人脸图片由于未存储在设备端，所以这30张人脸图片放入图片路径是未知的，所以设备端不能对这30张人脸图片进行建模。倘若，处理用户想要针对这30张人脸图片进行建模，需要从服务端本地将这30张人脸图片上传到Web端，再从Web端将这30张人脸图片上传到设备端进行建模。

Step6：如果用户选择不需要恢复Web端界面异常关闭之前人脸图片的注册建模相关情况，则Web端会将用户选择的不需要恢复指令下发给设备端，以便设备端不再对设备端中建模未完成的人脸图片进行建模。如果用户选择需要恢复Web端界面异常关闭之前人脸图片的注册建模相关情况，则设备端会将用户选择的需要恢复指令下发给设备端，设备端根据用户选择的需要恢复指令，将当前的注册建模进度数据发送给Web端，并下发针对设备端中建模未完成的人脸图片的继续建模指令给设备端，以使设备端基于继续建模指令执行针对建模未完成的人脸图片的建模。

示例性地，处理用户需要导入100张人脸图片到设备端，却在Web端界面异常关闭时只导入70张人脸图片到设备端，还有30张人脸图片未导入到设备端。而且，该70张人脸图片中有50张人脸图片已经进行了建模，剩下的20张人脸图片未进行建模。则设备端会将当前的注册建模结果(比如人脸图片导入设备端未全部完成的消息，以及只导入70张人脸图片到设备端，还有30张人脸图片未导入到设备端、70张人脸图片中有50张人脸图片已建模和20张人脸图片未建模等)发送给Web端，以便Web端界面增加提示语，让处理用户选择是否需要恢复Web端界面异常关闭之前人脸图片的注册建模相关情况。如果用户选择不需要恢复Web端界面异常关闭之前人脸图片的注册建模相关情况，则Web端会将用户选择的不需要恢复指令下发给设备端，以便设备端不再对设备端中20张未进行建模的人脸图片进行建模。同时，设备端将根据用户选择的不需要恢复指令对所有相关实时变量进行初始化处理。

如果用户选择需要恢复Web端界面异常关闭之前人脸图片的注册建模相关情况，则设备端会将用户选择的需要恢复指令下发给设备端，设备端根据用户选择的需要恢复指令，将当前的注册建模进度数据(比如导入70张人脸图片到设备端、70张人脸图片中有50张人脸图片已建模和20张人脸图片未建模)发送给Web端，以便在Web端界面进行显示。同时，Web端会下发针对20张未进行建模的人脸图片进行继续建模的指令给Web端，或者下发从顺序号为51的人脸图片开始进行继续建模的指令(即继续进行针对顺序号为51到70的人脸图片的建模)给Web端，以便设备端在接收到继续建模指令后，通知底层系统针对20张未进行建模的人脸图片(或顺序号为51到70的人脸图片)进行继续建模。同时设备端会实时通知Web端进行同步更新并显示人脸图片的建模情况(比如建模成功一张人脸图片，Web端显示会实时增加并显示)。倘若，处理用户想要针对未导入到设备端的30张人脸图片(顺序号为71到100的人脸图片)进行建模，需要从服务端本地将这30张人脸图片上传到Web端，再从Web端将这30张人脸图片上传到设备端进行建模。其中，50张已建模的人脸图片中也有可能存在建模失败的人脸图片，即该50张已建模的人脸图片包括建模成功的人脸图片和建模失败的人脸图片。针对该建模失败的人脸图片，可以基于该建模失败的人脸图片对应的图片路径从设备端的人脸图片存储区域中提取出该建模失败的人脸图片，并利用人脸图片特征提取模型对该建模失败的人脸图片进行重新建模。示例性地，该50张已建模的人脸图片包括45张建模成功的人脸图片和5张建模失败的人脸图片，针对5张建模失败的人脸图片，可以基于该5张建模失败的人脸图片对应的图片路径，从设备端的人脸图片存储区域中提取出该5张建模失败的人脸图片，并利用人脸图片特征提取模型对该5张建模失败的人脸图片进行重新建模，直至建模成功。

需要说明的是，设备端基于本地设置的提取人脸图片的特征值的模型，针对Web端传输进来的人脸图片进行建模。即，由于针对人脸图片的建模是在人脸图片上传到设备端后延迟3秒进行，因此设备端会将Web端传输进来的人脸图片在缓存队列进行缓存或者将Web端传输进来的人脸图片依次存储到内存中，并按照先进先出的规则，利用人脸图片特征提取模型针对缓存队列或内存中的人脸图片依次进行建模(即按照人脸图片存储时间的先后顺序依次进行建模)。

在对人脸图片进行建模全部完成后，设备端会将人脸图片特征提取模型提取出的人脸特征值存储在本地。然后，在设备端采集到某个人员的人脸图片后，会基于人脸图片特征提取模型提取出该人员的人脸图片的特征值，并将该特征值与本地存储的多个特征值进行匹配，以确定该人员是否为本企业的员工，从而为确保企业相关信息的安全性提供支持。

上述实施例表明，Web端在传输建模数据至建模端的过程中发生异常重启后会向建模端发送建模状况获取请求，以使建模端可以将Web端的建模状况发送给Web端，并根据Web端针对建模状况的建模响应确定是否继续Web端的建模。如此，由于建模端可以准确地将在Web端异常之前收到的建模数据的建模状况发送给Web端，因此可以便于Web端及时准确地获知建模数据的建模状况，并基于建模数据的建模状况确定是否继续在建模端进行建模数据的建模，以避免存在现有技术中Web端不知道建模数据的建模状况而需要重新传输浏览器异常之前的建模数据给建模端的情况，如此可以给用户带来极大的便利，以提升用户的体验，并有助于提高针对建模状况的建模响应确定是否继续Web端的建模的灵活性。

基于相同的技术构思，图3示例性的示出了本发明实施例提供的一种基于浏览器传输的建模装置，该装置可以执行基于浏览器传输的建模方法的流程。

如图3所示，该装置包括：

接收单元301，用于接收Web端发送的建模状况获取请求；所述建模状况获取请求是所述Web端在传输建模数据至所述建模端的过程中发生异常重启后发送的；

第一处理单元302，用于将所述Web端的建模状况发送给所述Web端；所述建模状况用于指示所述建模端在所述Web端异常之前收到的建模数据的建模状况；根据所述Web端针对所述建模状况的建模响应确定是否继续所述Web端的建模。

可选地，所述第一处理单元302还用于：

在接收Web端发送的建模状况获取请求之前，记录从所述Web端获取的各建模数据；

记录所述各建模数据的建模状态，所述建模状态包括已建模和未建模；

将记录的所述各建模数据的建模状态作为所述Web端的建模状况。

可选地，所述建模响应为继续建模；

所述第一处理单元302具体用于：

确定已收到的建模数据中存在尚未进行建模的建模数据；

对所述尚未进行建模的建模数据进行建模。

可选地，所述建模响应为停止建模；

所述第一处理单元302具体用于：

在确定所述建模响应为停止建模时，对本地存储的所述建模状况进行初始化。

基于相同的技术构思，图4示例性的示出了本发明实施例提供的另一种基于浏览器传输的建模装置，该装置可以执行基于浏览器传输的建模方法的流程。

如图4所示，该装置包括：

生成单元401，用于在传输建模数据至建模端的过程中检测到自身异常关闭并重启后，生成建模状况获取请求；

第二处理单元402，用于将所述建模状况获取请求发送给所述建模端；所述建模状况获取请求用于从所述建模端获取所述Web端的建模状况；所述建模状况用于指示所述建模端在所述Web端异常之前收到的建模数据的建模状况；接收用户针对所述建模状况的建模响应并将所述建模响应发送至所述建模端；所述建模响应用于指示所述建模端是否继续所述Web端的建模。

可选地，所述第二处理单元402具体用于：

若确定所述建模响应为继续建模，则生成继续建模指令，并将所述继续建模指令发送给所述建模端；所述继续建模指令用于指示所述建模端基于已收到的建模数据中存在尚未进行建模的建模数据进行建模。

可选地，所述第二处理单元402具体用于：

若确定所述建模响应为停止建模，则生成停止建模指令，并将所述停止建模指令发送给所述建模端；所述停止建模指令用于指示所述建模端对本地存储的所述建模状况进行初始化。

基于相同的技术构思，本发明实施例还提供了一种计算设备，如图5所示，包括至少一个处理器501，以及与至少一个处理器连接的存储器502，本发明实施例中不限定处理器501与存储器502之间的具体连接介质，图5中处理器501和存储器502之间通过总线连接为例。总线可以分为地址总线、数据总线、控制总线等。

在本发明实施例中，存储器502存储有可被至少一个处理器501执行的指令，至少一个处理器501通过执行存储器502存储的指令，可以执行前述的基于浏览器传输的建模方法中所包括的步骤。

其中，处理器501是计算设备的控制中心，可以利用各种接口和线路连接计算设备的各个部分，通过运行或执行存储在存储器502内的指令以及调用存储在存储器502内的数据，从而实现数据处理。可选的，处理器501可包括一个或多个处理单元，处理器501可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理下发指令。可以理解的是，上述调制解调处理器也可以不集成到处理器501中。在一些实施例中，处理器501和存储器502可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器501可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本发明实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合基于浏览器传输的建模实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器502作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器502可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器502是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本发明实施例中的存储器502还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

基于相同的技术构思，本发明实施例还提供了一种计算机可读存储介质，其存储有可由计算设备执行的计算机程序，当所述程序在所述计算设备上运行时，使得所述计算设备执行上述基于浏览器传输的建模方法的步骤。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (7)

1.一种基于浏览器传输的建模方法，其特征在于，包括：

建模端接收Web端发送的建模状况获取请求；所述建模状况获取请求是所述Web端在传输建模数据至所述建模端的过程中发生异常重启后发送的；所述建模端为服务端；

所述建模端将所述Web端的建模状况发送给所述Web端；所述建模状况用于指示所述建模端在所述Web端异常之前收到的建模数据的建模状况；所述Web端的建模状况是各建模数据的建模状态，所述建模状态包括已建模和未建模；

所述建模端根据所述Web端针对所述建模状况的建模响应确定是否继续所述Web端的建模；其中,

所述建模端根据所述Web端针对所述建模状况的建模响应确定是否继续所述Web端的建模，包括：

所述建模响应为继续建模；

所述建模端确定已收到的建模数据中存在尚未进行建模的建模数据；

所述建模端对所述尚未进行建模的建模数据进行建模；或

所述建模响应为停止建模；

所述建模端在确定所述建模响应为停止建模时，对本地存储的所述建模状况进行初始化。

2.如权利要求1所述的方法，其特征在于，在建模端接收Web端发送的建模状况获取请求之前，还包括：

所述建模端记录从所述Web端获取的各建模数据；

所述建模端记录所述各建模数据的建模状态，所述建模状态包括已建模和未建模；

所述建模端将记录的所述各建模数据的建模状态作为所述Web端的建模状况。

3.一种基于浏览器传输的建模方法，其特征在于，包括：

Web端在传输建模数据至建模端的过程中检测到自身异常关闭并重启后，生成建模状况获取请求；所述建模端为服务端；

所述Web端将所述建模状况获取请求发送给所述建模端；所述建模状况获取请求用于从所述建模端获取所述Web端的建模状况；所述建模状况用于指示所述建模端在所述Web端异常之前收到的建模数据的建模状况；所述Web端的建模状况是各建模数据的建模状态，所述建模状态包括已建模和未建模；

所述Web端接收用户针对所述建模状况的建模响应并将所述建模响应发送至所述建模端；所述建模响应用于指示所述建模端是否继续所述Web端的建模；其中，

所述Web端接收用户针对所述建模状况的建模响应并将所述建模响应发送至所述建模端，包括：

所述Web端若确定所述建模响应为继续建模，则生成继续建模指令，并将所述继续建模指令发送给所述建模端；所述继续建模指令用于指示所述建模端基于已收到的建模数据中存在尚未进行建模的建模数据进行建模；

所述Web端若确定所述建模响应为停止建模，则生成停止建模指令，并将所述停止建模指令发送给所述建模端；所述停止建模指令用于指示所述建模端对本地存储的所述建模状况进行初始化。

4.一种基于浏览器传输的建模装置，其特征在于，包括：

接收单元，用于接收Web端发送的建模状况获取请求；所述建模状况获取请求是所述Web端在传输建模数据至建模端的过程中发生异常重启后发送的；所述建模端为服务端；

第一处理单元，用于将所述Web端的建模状况发送给所述Web端；所述建模状况用于指示所述建模端在所述Web端异常之前收到的建模数据的建模状况；所述Web端的建模状况是各建模数据的建模状态，所述建模状态包括已建模和未建模；根据所述Web端针对所述建模状况的建模响应确定是否继续所述Web端的建模，其中，所述建模端根据所述Web端针对所述建模状况的建模响应确定是否继续所述Web端的建模，包括：

所述建模响应为继续建模；

所述建模端确定已收到的建模数据中存在尚未进行建模的建模数据；

所述建模端对所述尚未进行建模的建模数据进行建模；或

所述建模响应为停止建模；

所述建模端在确定所述建模响应为停止建模时，对本地存储的所述建模状况进行初始化。

5.一种基于浏览器传输的建模装置，其特征在于，包括：

生成单元，用于在传输建模数据至建模端的过程中检测到自身异常关闭并重启后，生成建模状况获取请求；所述建模端为服务端；

第二处理单元，用于将所述建模状况获取请求发送给所述建模端；所述建模状况获取请求用于从所述建模端获取Web端的建模状况；所述建模状况用于指示所述建模端在所述Web端异常之前收到的建模数据的建模状况；所述Web端的建模状况是各建模数据的建模状态，所述建模状态包括已建模和未建模；接收用户针对所述建模状况的建模响应并将所述建模响应发送至所述建模端；所述建模响应用于指示所述建模端是否继续所述Web端的建模；其中，所述Web端接收用户针对所述建模状况的建模响应并将所述建模响应发送至所述建模端，包括：

所述Web端若确定所述建模响应为继续建模，则生成继续建模指令，并将所述继续建模指令发送给所述建模端；所述继续建模指令用于指示所述建模端基于已收到的建模数据中存在尚未进行建模的建模数据进行建模；

所述Web端若确定所述建模响应为停止建模，则生成停止建模指令，并将所述停止建模指令发送给所述建模端；所述停止建模指令用于指示所述建模端对本地存储的所述建模状况进行初始化。

6.一种计算设备，其特征在于，包括至少一个处理器以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行权利要求1至3任一权利要求所述的方法。

7.一种计算机可读存储介质，其特征在于，其存储有可由计算设备执行的计算机程序，当所述程序在所述计算设备上运行时，使得所述计算设备执行权利要求1至3任一权利要求所述的方法。

Images