CN111343248B - 在线服务的实现方法、装置、系统、服务器和存储介质 - Google Patents

Abstract

本申请公开了在线服务的实现方法、装置、系统、服务器和存储介质。所述方法包括：接收目标账户上报的用户状态信息；所述用户状态信息包括：身体状态信息和/或业务设备状态信息；根据所述用户状态信息确定账户状态；接收目标账户的服务状态变更请求；若目标账户的账户状态正常，则依据所述服务状态变更请求，相应地变更目标账户的服务状态；否则，拒绝变更目标账户的服务状态。有益效果在于，能够自动地获取到与服务场景相关的用户状态信息，高时效性地确定账户状态，拒绝异常账户提供服务，保障了在线服务的安全性。

Description

在线服务的实现方法、装置、系统、服务器和存储介质

技术领域

本申请涉及网络服务技术领域，具体涉及在线服务的实现方法、装置、系统、服务器和存储介质。

背景技术

在线服务不仅包括B2C(Business to Consumer，商对客)模式，也包括C2C(Customer to Customer，客对客)模式。C2C场景下，平台既对接消费者，如有购物、外卖需求的顾客，也对接服务供给者，如商家、配送员等。由于消费者与服务供给者并不互相了解，保障双方权益一直是平台运营的重点。

目前，许多平台通过资质验证等方式，为消费者的权益提供了保障，相应地也推动了证照识别等技术的发展。然而，对于外卖配送等场景，仅拥有健康证、营业执照等资质，并不能完全保障服务的安全性，例如，如果配送员临时感染了传染性疾病，但隐瞒这一事实，继续进行配送，就为消费者的健康带来了隐患。通过人工的方式进行排查，即使耗费大量人力成本，也不能有效解决这一问题，因此亟需一种保障在线服务安全性的技术手段。

发明内容

鉴于上述问题，提出了本申请以便提供一种克服上述问题或者至少部分地解决上述问题的在线服务的实现方法、装置、系统、服务器和存储介质。

依据本申请的第一方面，提供了一种在线服务的实现方法，包括：接收目标账户上报的用户状态信息；所述用户状态信息包括：身体状态信息和/或业务设备状态信息；根据所述用户状态信息确定账户状态；接收目标账户的服务状态变更请求；若目标账户的账户状态正常，则依据所述服务状态变更请求，相应地变更目标账户的服务状态；否则，拒绝变更目标账户的服务状态。

可选地，所述接收目标账户上报的用户状态信息包括：通过前端页面展示的模板接收目标账户上报的用户状态信息；和/或，对目标账户上报的非结构化数据进行识别，得到结构化的用户状态信息；和/或，通过预设接口接收用户状态信息采集设备上报的用户状态信息，所述用户状态信息采集设备与所述目标账户相关联。

可选地，所述身体状态信息包括如下的至少一种：身份特征信息，健康状态信息，防护信息；所述根据所述用户状态信息确定账户状态包括：依据所述身份特征信息进行身份识别和/或活体检测，若识别出的身份与目标账户不匹配，则确定账户异常；若检测失败，则确定账户异常；依据所述健康状态信息判断用户是否处于健康状态，否则确定账户异常；依据所述防护信息判断用户的着装防护是否符合预设条件，否则确定账户异常。

可选地，所述活体检测包括：获取用户的活体检测的行为数据；将所述行为数据输入风险预测模型，通过所述风险预测模型输出所述行为数据对应的风险值；其中，所述风险预测模型为根据收集的历史活体检测的历史行为数据，以及所述历史行为数据对应的风险值标注信息训练得到；根据所述风险值，调整所述用户的活体检测的检测参数，以提高或者降低所述用户的活体检测的难度。

可选地，所述检测参数至少包括如下任意一项：目标动作个数、目标动作完成时间、最大活体检测次数、动作匹配阈值、以及人脸匹配阈值；所述根据所述风险值，调整所述用户的活体检测的检测参数，包括：随着所述风险值的增大，增大所述用户的如下检测参数中的至少一项：目标动作个数、动作匹配阈值、人脸匹配阈值，以及减小所述用户的如下检测参数中的至少一项：目标动作完成时间和最大活体检测次数。

可选地，所述活体检测还包括：判断预设时间内连续检测失败的次数是否小于最大活体检测次数，若是，则获取所述用户输入的动作数据和人脸数据；根据调整后的目标动作个数和/或调整后的目标动作完成时间，计算所述动作数据中每一个动作与目标动作的第一匹配度；根据预录入的所述用户的目标人脸图像，计算所述人脸数据与所述目标人脸图像的第二匹配度；若所述第一匹配度超过调整后的动作匹配阈值，并且所述第二匹配度超过调整后的人脸匹配阈值，则确定所述用户的检测结果为检测成功。

可选地，所述获取所述用户输入的动作数据和人脸数据之后，所述方法还包括：若确定所述用户输入的动作数据和/或人脸数据满足如下任一条件，则确定所述用户的检测结果为检测失败：所述动作数据中包含的目标动作个数小于所述调整后的目标动作个数；或所述动作数据中包含的任意一个动作的完成时间大于所述调整后的目标动作完成时间；或所述动作数据中包含的任意一个动作与相对应的目标动作的第一匹配度小于所述调整后的动作匹配阈值；或所述人脸数据中存在预设数量的图像帧与所述目标人脸图像的第二匹配度小于所述调整后的人脸匹配阈值。

可选地，所述接收目标账户上报的用户状态信息包括：通过地理位置维度和/或业务维度确定需要上报用户状态信息的账户，在预设时间区间内，初次接收到目标账户上报的服务状态变更请求时，若目标账户为需要上报用户状态信息的账户，是则通知目标账户上报用户状态信息；和/或，接收目标账户在业务抽检过程中上报的用户状态信息；和/或，在已保存的目标账户的用户状态信息过期时，通知目标账户上报用户状态信息。

可选地，所述方法还包括：若确定目标账户的账户异常，则将目标账户的账户状态和至少部分账户信息通知给与目标账户相关的管理账户，和/或，将账户状态提示信息下发给目标账户的关联设备进行展示。

可选地，所述方法还包括：根据各账户的服务状态进行业务调度，根据业务调度结果，建立各账户与服务对象的关联关系；根据服务对象的业务请求，提供相应的业务页面；为所述业务页面提供展示接口，以使业务页面通过所述展示接口获取与所述服务对象相关联的账户的至少部分用户状态信息并展示。

可选地，所述根据业务调度结果，建立各账户与服务对象的关联关系包括：在业务调度结果发生变更时，相应调整各账户与服务对象的关联关系；所述提供相应的业务页面包括：根据调整后的关联关系，对业务页面进行刷新。

可选地，所述方法还包括：将所述用户状态信息写入信息卡模板的对应字段中，生成信息卡；所述根据服务对象的业务请求，提供相应的业务页面包括：在业务页面中添加生成的信息卡以进行展示，和/或在业务页面中添加信息卡控件，以使生成的信息卡根据所述信息卡控件的触发事件进行展示。

可选地，所述业务页面包括如下的至少一种：订单页面，配送详情页面，在线沟通页面。

可选地，所述配送详情页面包括地图，所述地图用于展示配送员的当前位置，所述配送员的账户为与所述服务对象相关联的账户；所述地图中用于标识配送员的元素是根据所述配送员的账户的用户状态信息确定的。

依据本申请的第二方面，提供了一种在线服务的实现装置，包括：数据交互单元，用于接收目标账户上报的用户状态信息；所述用户状态信息包括：身体状态信息和/或业务设备状态信息；账户状态单元，用于根据所述用户状态信息确定账户状态；所述数据交互单元，还用于接收目标账户的服务状态变更请求；服务状态单元，用于若目标账户的账户状态正常，则依据所述服务状态变更请求，相应地变更目标账户的服务状态；否则，拒绝变更目标账户的服务状态。

可选地，所述数据交互单元，用于通过前端页面展示的模板接收目标账户上报的用户状态信息；和/或，对目标账户上报的非结构化数据进行识别，得到结构化的用户状态信息；和/或，通过预设接口接收用户状态信息采集设备上报的用户状态信息，所述用户状态信息采集设备与所述目标账户相关联。

可选地，所述身体状态信息包括如下的至少一种：身份特征信息，健康状态信息，防护信息；所述账户状态单元，用于依据所述身份特征信息进行身份识别和/或活体检测，若识别出的身份与目标账户不匹配，则确定账户异常；若检测失败，则确定账户异常；依据所述健康状态信息判断用户是否处于健康状态，否则确定账户异常；依据所述防护信息判断用户的着装防护是否符合预设条件，否则确定账户异常。

可选地，所述账户状态单元，用于获取用户的活体检测的行为数据；将所述行为数据输入风险预测模型，通过所述风险预测模型输出所述行为数据对应的风险值；其中，所述风险预测模型为根据收集的历史活体检测的历史行为数据，以及所述历史行为数据对应的风险值标注信息训练得到；根据所述风险值，调整所述用户的活体检测的检测参数，以提高或者降低所述用户的活体检测的难度。

可选地，所述检测参数至少包括如下任意一项：目标动作个数、目标动作完成时间、最大活体检测次数、动作匹配阈值、以及人脸匹配阈值；所述账户状态单元，用于随着所述风险值的增大，增大所述用户的如下检测参数中的至少一项：目标动作个数、动作匹配阈值、人脸匹配阈值，以及减小所述用户的如下检测参数中的至少一项：目标动作完成时间和最大活体检测次数。

可选地，所述账户状态单元，用于判断预设时间内连续检测失败的次数是否小于最大活体检测次数，若是，则获取所述用户输入的动作数据和人脸数据；根据调整后的目标动作个数和/或调整后的目标动作完成时间，计算所述动作数据中每一个动作与目标动作的第一匹配度；根据预录入的所述用户的目标人脸图像，计算所述人脸数据与所述目标人脸图像的第二匹配度；若所述第一匹配度超过调整后的动作匹配阈值，并且所述第二匹配度超过调整后的人脸匹配阈值，则确定所述用户的检测结果为检测成功。

可选地，所述账户状态单元，用于若确定所述用户输入的动作数据和/或人脸数据满足如下任一条件，则确定所述用户的检测结果为检测失败：所述动作数据中包含的目标动作个数小于所述调整后的目标动作个数；或所述动作数据中包含的任意一个动作的完成时间大于所述调整后的目标动作完成时间；或所述动作数据中包含的任意一个动作与相对应的目标动作的第一匹配度小于所述调整后的动作匹配阈值；或所述人脸数据中存在预设数量的图像帧与所述目标人脸图像的第二匹配度小于所述调整后的人脸匹配阈值。

可选地，所述数据交互单元，用于通过地理位置维度和/或业务维度确定需要上报用户状态信息的账户，在预设时间区间内，初次接收到目标账户上报的服务状态变更请求时，若目标账户为需要上报用户状态信息的账户，是则通知目标账户上报用户状态信息；和/或，接收目标账户在业务抽检过程中上报的用户状态信息；和/或，在已保存的目标账户的用户状态信息过期时，通知目标账户上报用户状态信息。

可选地，所述数据交互单元，还用于若确定目标账户的账户异常，则将目标账户的账户状态和至少部分账户信息通知给与目标账户相关的管理账户，和/或，将账户状态提示信息下发给目标账户的关联设备进行展示。

可选地，所述装置还包括：业务单元，用于根据各账户的服务状态进行业务调度，根据业务调度结果，建立各账户与服务对象的关联关系；根据服务对象的业务请求，提供相应的业务页面；为所述业务页面提供展示接口，以使业务页面通过所述展示接口获取与所述服务对象相关联的账户的至少部分用户状态信息并展示。

可选地，所述业务单元，用于在业务调度结果发生变更时，相应调整各账户与服务对象的关联关系；根据调整后的关联关系，对业务页面进行刷新。

可选地，所述业务单元，还用于将所述用户状态信息写入信息卡模板的对应字段中，生成信息卡；在业务页面中添加生成的信息卡以进行展示，和/或在业务页面中添加信息卡控件，以使生成的信息卡根据所述信息卡控件的触发事件进行展示。

可选地，所述业务页面包括如下的至少一种：订单页面，配送详情页面，在线沟通页面。

可选地，所述配送详情页面包括地图，所述地图用于展示配送员的当前位置，所述配送员的账户为与所述服务对象相关联的账户；所述地图中用于标识配送员的元素是根据所述配送员的账户的用户状态信息确定的。

依据本申请的第三方面，提供了一种在线服务的实现系统，包括：服务器，服务供给客户端，服务消费客户端；所述服务器中部署有如上述任一所述的在线服务的实现装置；所述服务供给客户端，用于向所述服务器发送目标账户的用户状态信息以及目标账户的服务状态变更请求，以及接收服务器下发的业务调度结果；所述服务消费客户端，用于向所述服务器发送业务请求，以及接收服务器返回的业务页面。

依据本申请的第四方面，提供了一种服务器，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行如上述任一所述的方法。

依据本申请的第五方面，提供了一种计算机可读存储介质，其中，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被处理器执行时，实现如上述任一所述的方法。

由上述可知，本申请的技术方案，通过接收目标账户上报的身体状态信息、业务设备状态信息等用户状态信息，确定账户状态，在接收目标账户的服务状态变更请求后，若目标账户的账户状态正常，则依据服务状态变更请求，相应地变更目标账户的服务状态；否则，拒绝变更目标账户的服务状态。该技术方案的有益效果在于，能够自动地获取到与服务场景相关的用户状态信息，高时效性地确定账户状态，拒绝异常账户提供服务，保障了在线服务的安全性。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本申请一个实施例的一种在线服务的实现方法的流程示意图；

图2示出了根据本申请一个实施例的外卖安心卡示意图；

图3示出了根据本申请一个实施例的一种在线服务的实现装置的结构示意图；

图4示出了根据本申请一个实施例的一种在线服务的实现系统的结构示意图；

图5示出了根据本申请一个实施例的服务器的结构示意图；

图6示出了根据本申请一个实施例的计算机可读存储介质的结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的示例性实施例。虽然附图中显示了本申请的示例性实施例，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。

本申请的技术构思在于，拓展服务端，如C2C平台的功能，获取服务供给客户端等设备上传的用户状态信息，确保服务供给者的状态符合业务标准，从而实现了安全的在线服务。

图1示出了根据本申请一个实施例的一种在线服务的实现方法的流程示意图。如图1所示，该方法包括：

步骤S110，接收目标账户上报的用户状态信息；用户状态信息包括：身体状态信息和/或业务设备状态信息。

这里，目标账户可以是服务提供者的账户，例如配送员、商家的账户，用户也就是指配送员或是商家等。身体状态信息可以包括体温、是否咳嗽等，业务设备可以是用于提供线下服务的设备，例如洗碗机、配送箱、厨具等，业务设备状态信息可以包括是否清洗、是否消毒等。

步骤S120，根据用户状态信息确定账户状态。

本步骤中可以对用户状态信息进行校验，根据校验结果确定账户状态。这里的校验可以包括来源校验，例如是否是已报备过的设备上传；可以包括真实性校验，例如是否有作弊行为；可以包括合理性校验，例如身体不健康的用户，账户状态可以被确定为异常，以拒绝用户进行服务。

步骤S130，接收目标账户的服务状态变更请求。

这里的服务状态，是指通过平台等方式在线提供服务的状态，以外卖场景为例，商家可以选择在指定时段接单，否则可能出现忙不过来的情况，同样地，配送员也可以根据自己的实际需求，变更自己的服务状态为开工或休息。

这里需要说明的是，步骤S130与步骤S110在具体场景下，没有执行先后顺序的限制，例如用户可以先上报用户状态信息，再请求变更目标账户的服务状态，也可以先请求目标账户的服务状态，服务器再要求用户上报用户状态信息，等到根据用户状态信息确定账户状态后，再确认是否变更目标账户的服务状态。

步骤S140，若目标账户的账户状态正常，则依据服务状态变更请求，相应地变更目标账户的服务状态；否则，拒绝变更目标账户的服务状态。

也就是说，仅允许账户状态正常的用户提供服务，这样就“隔离”了存在健康等风险的服务提供者与普通消费者，确保了在线服务的安全性。

可见，图1所示的方法，能够自动地获取到与服务场景相关的用户状态信息，高时效性地确定账户状态，拒绝异常账户提供服务，保障了在线服务的安全性。

在本申请的一个实施例中，上述方法中，接收目标账户上报的用户状态信息包括：通过前端页面展示的模板接收目标账户上报的用户状态信息；和/或，对目标账户上报的非结构化数据进行识别，得到结构化的用户状态信息；和/或，通过预设接口接收用户状态信息采集设备上报的用户状态信息，用户状态信息采集设备与目标账户相关联。

这类的模板是一个宽泛的概念，例如，可以用户自由填入信息的表格，或是包括多个可选项的页面。如对于体温这类容易规范的数据，就可以设置在人体体温范围内的多个候选项，避免各用户填入36、36.5度、36度8等格式各异，不容易统计的情况。

非结构化数据是指照片、视频、没有预设格式的文档等，这些数据不能直接提供可以的用户状态信息，因此，需要进行识别，具体的识别方式包括但不限于图像识别、正则表达式提取等。一个具体的例子为，用户对体温计进行拍照，将拍好的照片进行上报，则需要从中识别出用户测量的体温。

用户状态信息采集设备具体可以是物联网(IoT)设备，如带有数据传输功能的体温计、消毒设备、清洁设备，带有智能采集人体生物信息的骑手头盔，等等。用服务器可以为这些设备分别提供通信的预设接口，来接收用户状态信息。当然，用户状态信息采集设备可以不直接与服务器通过移动网络通信，而是可以参考现有可穿戴设备，与移动设备如手机通过蓝牙、WiFi等方式通信，由移动设备作为用户状态信息的中转，发送给服务器。

为了确保用户状态信息与目标账户具有关联性，可以通过将用户状态信息采集设备注册到目标账户，或是直接在用户状态信息采集设备上登录目标账户等方式实现。

在一些实施例中，用户状态信息还可以复用到其他场景，例如报表统计，人员筛查，信息公示等。具体来说，外卖场景的服务提供者不仅有配送员，还有商家，而配送员与商家通常分属不同的组织，用户状态信息也是分别采集上报。而对于消费者而言，其一个订单往往既涉及配送员，也涉及商家，那么就可以将配送员的用户状态信息与商家的用户状态信息进行汇总，例如以模板生成“安心卡”推送给消费者。

在本申请的一个实施例中，上述方法中，身体状态信息包括如下的至少一种：身份特征信息，健康状态信息，防护信息；根据用户状态信息确定账户状态包括：依据身份特征信息进行身份识别和/或活体检测，若识别出的身份与目标账户不匹配，则确定账户异常；若检测失败，则确定账户异常；依据健康状态信息判断用户是否处于健康状态，否则确定账户异常；依据防护信息判断用户的着装防护是否符合预设条件，否则确定账户异常。

举例来说，身份特征信息可以是人脸照片，则可以对人脸照片进行识别，确定用户的身份。再举例来说，身份特征信息可以是一段视频，拍摄了用户按提示做出的指定动作，如点头、朗读文本等，则可以根据动作与提示的匹配度，文本与提示的一致性等方式，判断用户是真的做出了动作，还是以照片做欺骗。具体的身份识别和活体检测方式可以参考现有技术实现，在后续的实施例中也将介绍本申请实施例所使用的活体检测方法，但不代表对本申请的限制。

健康状态的判断，可以以正常人的标准，或是服务要求的特殊标准进行判断，如传染病暴发时期，以体温作为是否健康的判断标准，要求用户体温不能高于37.3°。

着装防护是否符合预设条件可以根据实际场景确定，例如，要求打包员在处理食品时佩戴手套，如果上传的防护信息是一张打包员工作时的照片，而对其识别后发现打包员没有佩戴手套或是手套破损，那么着装防护就不符合预设条件。

在本申请的一个实施例中，上述方法中，活体检测包括：获取用户的活体检测的行为数据；将行为数据输入风险预测模型，通过风险预测模型输出行为数据对应的风险值；其中，风险预测模型为根据收集的历史活体检测的历史行为数据，以及历史行为数据对应的风险值标注信息训练得到；根据风险值，调整用户的活体检测的检测参数，以提高或者降低用户的活体检测的难度。

活体检测顾名思义，是在一些身份验证场景下确定对象真实生理特征的方法。例如，在人脸识别的场景下，如果攻击者以一张照片代替真实人脸，很可能就会成功欺骗检测方，这种情况下，要求用户做几个动作，那么攻击者就会露馅。

显然，提高活体检测难度，就能减小攻击者检测通过的可能性。然而，这对于正常用户而言，也降低了用户体验。比如，要求用户短时间内做出多个不同表情，这确实使得攻击难度加大，但是正常用户也有做不出来的可能。

因此，如何找到这之中的平衡是需要解决的问题。

本申请的实施例，基于风险预测模型，对这个问题给出了一种效果较佳的解决方案。其中，根据收集的历史活体检测的历史行为数据，以及历史行为数据对应的风险值标注信息训练得到风险预测模型，使得风险预测模型能够准确学习到各种行为数据的特征，如果是攻击行为的行为数据，那么风险就高，如果是正常行为的行为数据，那么风险就低，最终根据输出的风险值动态调整活体检测的检测参数。

也就是说，如果认为当前进行活体检测是一个攻击者，那么就加大难度；反之，如果是正常用户，那也没有必要为难。

在本申请的一个实施例中，上述方法中，检测参数至少包括如下任意一项：目标动作个数、目标动作完成时间、最大活体检测次数、动作匹配阈值、以及人脸匹配阈值；根据风险值，调整用户的活体检测的检测参数，包括：随着风险值的增大，增大用户的如下检测参数中的至少一项：目标动作个数、动作匹配阈值、人脸匹配阈值，以及减小用户的如下检测参数中的至少一项：目标动作完成时间和最大活体检测次数。

具体地，可以从如下角度定义活体检测的难度：要求用户连续做n个动作，且每个动作仅允许用户在m秒内完成。若任何动作在指定时间内检测不到，则检测失败。允许用户做k次活体检测，超过次数以后不允许再进行人脸识别。理论上存在攻击者按照引导，使用n个动作对应的照片、视频、3D面具，攻击成功的可能性。

从攻击难度上看：要求连续做的动作的数量n越大，攻击难度越大；每个动作允许的完成时间m越小，攻击难度越大；允许的最大活体检测次数k越小，攻击难度越大；动作判断和人脸比对的判断阈值f1、f2(在[0,1]区间内取浮点数)越大，攻击难度越大。

从用户体验角度看：增大n、f1、f2，减小m、k，可以称之为提高活体检测难度，反之，则为降低活体检测难度。也就是说，要求用户在更短的时间内完成更多的动作且不能有太多的错误，就是加大难度，反之就是降低难度。

在本申请的一个实施例中，上述方法中，活体检测还包括：判断预设时间内连续检测失败的次数是否小于最大活体检测次数，若是，则获取用户输入的动作数据和人脸数据；根据调整后的目标动作个数和/或调整后的目标动作完成时间，计算动作数据中每一个动作与目标动作的第一匹配度；根据预录入的用户的目标人脸图像，计算人脸数据与目标人脸图像的第二匹配度；若第一匹配度超过调整后的动作匹配阈值，并且第二匹配度超过调整后的人脸匹配阈值，则确定用户的检测结果为检测成功。

该实施例示出了调整用户的活体检测的检测参数之后，根据调整后的检测参数，对用户进行活体检测的具体过程。具体地，在本申请的一个实施例中，上述方法中，获取用户输入的动作数据和人脸数据之后，方法还包括：若确定用户输入的动作数据和/或人脸数据满足如下任一条件，则确定用户的检测结果为检测失败：动作数据中包含的目标动作个数小于调整后的目标动作个数；或动作数据中包含的任意一个动作的完成时间大于调整后的目标动作完成时间；或动作数据中包含的任意一个动作与相对应的目标动作的第一匹配度小于调整后的动作匹配阈值；或人脸数据中存在预设数量的图像帧与目标人脸图像的第二匹配度小于调整后的人脸匹配阈值。

一个具体的例子中，检测通过的必要条件是：1、预设时间内连续检测失败的次数小于k；2、连续做n个目标动作，且每个目标动作在m秒内完成；3、每个目标动作的第一匹配度大于f1；4、用户人脸图像的第二匹配度大于f2。

在本申请的一个实施例中，上述方法中，接收目标账户上报的用户状态信息包括：通过地理位置维度和/或业务维度确定需要上报用户状态信息的账户，在预设时间区间内，初次接收到目标账户上报的服务状态变更请求时，若目标账户为需要上报用户状态信息的账户，是则通知目标账户上报用户状态信息；和/或，接收目标账户在业务抽检过程中上报的用户状态信息；和/或，在已保存的目标账户的用户状态信息过期时，通知目标账户上报用户状态信息。

该实施例介绍了上报用户状态信息的几种时机示例。

一种情况下，可以先根据需求，确定哪些账户需要上报用户状态信息。具体地，可以在服务器侧通过配置一个上报开关来实现。

例如，某流行病仅在某几个地区流行，那么可以按照地理位置维度，仅将与这几个地区相关的账户设置为需要上报用户状态信息的账户。又例如，业务A需要在外部环境进行交互，而业务B仅需要在内部环境进行简单处理，那么业务B的危险系数低，相关账户也不需要上班用户状态信息，只有业务A的相关账户需要。

并且，实际场景中，在一段时间内(例如一天)，用户上报的用户状态信息都是有效的，那么没有必要要求每次目标账户上报的服务状态变更请求时都上报一次用户状态信息。预设时间区间可以根据用户状态信息的时效性来确定。

另一种情况下，在服务时可以进行业务抽检，该业务抽检可以通过人工方式进行，也可以通过服务器下发通知。例如，在指定时间向随机的账户下发通知，要求其上报用户状态信息，这样既避免了用户可能遗漏通知，也通过随机性避免了预知性作弊。当然，在另一些实施例中抽检时间也可以是随机的。

再一种情况下，可以为用户状态信息设置有效期，如果用户状态信息过期，就通知相应目标账户重新上报用户状态信息。

具体地，可以通过弹窗等方式提示上报用户状态信息，也可以将其与服务状态变更请求联动，举例而言，在配送员请求上线开工时，通过弹窗告知其需要上报用户状态信息，如果配送员关闭弹窗，则直接退出请求上线开工的页面，使其无法上线开工，接收服务器的配送任务。

在本申请的一个实施例中，上述方法还包括：若确定目标账户的账户异常，则将目标账户的账户状态和至少部分账户信息通知给与目标账户相关的管理账户，和/或，将账户状态提示信息下发给目标账户的关联设备进行展示。

例如，可以通知身体状况不佳的配送员，“亲爱的骑手：根据骑手健康申报显示，您近期身体不适，为了您自身健康安全考虑，我们将对您的骑手账号暂时进行停止接单操作，请您及时就医。在当您康复后，可向站长报备健康状况，重新接单，感谢您的理解与支持。”另外，还可以向该配送员组织上的主管人员(如站长)进行通报，以通过人工方式加以协助，通报方式可以是将账户状态提示信息下发给目标账户的关联设备，如通过短信下发给站长的手机，或者通过APP内消息通知。

在本申请的一个实施例中，上述方法还包括：根据各账户的服务状态进行业务调度，根据业务调度结果，建立各账户与服务对象的关联关系；根据服务对象的业务请求，提供相应的业务页面；为业务页面提供展示接口，以使业务页面通过展示接口获取与服务对象相关联的账户的至少部分用户状态信息并展示。

以外卖场景举例，当消费者在某一商家下单后，服务器会根据已上线开工的各配送员的当前位置、已接单量等因素进行配送调度，配送员也可以进行抢单等操作。当将某一订单分配给某一配送员后，就形成了配送员-商家-消费者-订单的关联关系。

用户可以查看订单、配送详情，与商家或是配送员进行沟通，即在本申请的一个实施例中，上述方法中，业务页面包括如下的至少一种：订单页面，配送详情页面，在线沟通页面。除此之外，还可以包括配送员的个人详情页面，商家详情页面，推广页面等等。

在这些业务页面中展示用户状态信息，从技术的角度上讲，容易实现，不需要对现有架构或功能做过多变更，只需要给业务页面提供一个展示接口拉取信息即可；从产品的角度上将，可以使消费者感知到信息透明，增强安心感，并且符合用户的实际需求，因为用户在点击业务页面时，是确实有着了解订单详情，查看配送员位置等需求，相较于以弹窗方式推送用户状态信息，更不易使消费者反感。

另外，当用户状态信息中包含仅需管理使用的敏感信息时，可以不对普通消费者仅需展示，因此展示接口可以具有数据过滤功能，数据过滤功能也可以以独立于展示接口外的其他组件实现，本申请对此不作限制。另外，如果有效的用户状态信息有多条，也可以仅展示最新的一条。

在本申请的一个实施例中，上述方法中，配送详情页面包括地图，地图用于展示配送员的当前位置，配送员的账户为与服务对象相关联的账户；地图中用于标识配送员的元素是根据配送员的账户的用户状态信息确定的。

例如，配送员的用户状态信息中，包含穿戴口罩的信息，那么在地图中可以以戴有口罩的配送员头像标识配送员的当前位置。配送员头像可以是统一配置的卡通头像，也可以是根据用户状态信息中，配送员自己拍摄的戴口罩照片生成的。

在本申请的一个实施例中，上述方法中，根据业务调度结果，建立各账户与服务对象的关联关系包括：在业务调度结果发生变更时，相应调整各账户与服务对象的关联关系；提供相应的业务页面包括：根据调整后的关联关系，对业务页面进行刷新。

在配送场景下，还容易出现转单的情况，即配送员可能因为堵车等原因，无法派送已被分配的某些商品，这种情况下就会调度其他配送员接单。那么在这种情况下，业务页面中的相应数据就会被刷新，例如原接单的配送员没有戴口罩，而接手转单的配送员戴有口罩，那么刷新后的业务页面中，标识配送员位置的元素可以从没戴口罩的配送员头像变成戴有口罩的配送员头像，地理位置等也可以被刷新，等等。

在本申请的一个实施例中，上述方法还包括：将用户状态信息写入信息卡模板的对应字段中，生成信息卡；根据服务对象的业务请求，提供相应的业务页面包括：在业务页面中添加生成的信息卡以进行展示，和/或在业务页面中添加信息卡控件，以使生成的信息卡根据信息卡控件的触发事件进行展示。

在一个具体业务场景下，生成的信息卡为外卖安心卡。图2示出了根据本申请一个实施例的外卖安心卡示意图。该实施例中，用户状态信息包括一名叫小红的厨师的体温记录，具体为36.8°，以及一名叫小黑的打包员的体温记录，具体为36.6°。小红和小黑均隶属于餐馆“大食堂”，当天日期为2020年2月6日，那么生成的外卖安心卡内容可以如图2所示。

举例来说，商家的首页、推广页、详情页、订单页等都可以展示信息卡，如外卖场景，用户在进入商家页面后，可以首先看到该商家的外卖安心卡，例如以弹窗的形式出现。为了避免其他内容的正常展示，也可以以信息卡控件的方式展示，当其被触发后展示生成的信息卡。

图3示出了根据本申请一个实施例的一种在线服务的实现装置的结构示意图。如图3所示，在线服务的实现装置300包括：

数据交互单元310，用于接收目标账户上报的用户状态信息；用户状态信息包括：身体状态信息和/或业务设备状态信息。

这里，目标账户可以是服务提供者的账户，例如配送员、商家的账户，用户也就是指配送员或是商家等。身体状态信息可以包括体温、是否咳嗽等，业务设备可以是用于提供线下服务的设备，例如洗碗机、配送箱、厨具等，业务设备状态信息可以包括是否清洗、是否消毒等。

账户状态单元320，用于根据用户状态信息确定账户状态。

账户状态单元320可以对用户状态信息进行校验，根据校验结果确定账户状态。这里的校验可以包括来源校验，例如是否是已报备过的设备上传；可以包括真实性校验，例如是否有作弊行为；可以包括合理性校验，例如身体不健康的用户，账户状态可以被确定为异常，以拒绝用户进行服务。

数据交互单元310，还用于接收目标账户的服务状态变更请求。

这里的服务状态，是指通过平台等方式在线提供服务的状态，以外卖场景为例，商家可以选择在指定时段接单，否则可能出现忙不过来的情况，同样地，配送员也可以根据自己的实际需求，变更自己的服务状态为开工或休息。

服务状态单元330，用于若目标账户的账户状态正常，则依据服务状态变更请求，相应地变更目标账户的服务状态；否则，拒绝变更目标账户的服务状态。

也就是说，仅允许账户状态正常的用户提供服务，这样就“隔离”了存在健康等风险的服务提供者与普通消费者，确保了在线服务的安全性。

可见，图3所示的装置，能够自动地获取到与服务场景相关的用户状态信息，高时效性地确定账户状态，拒绝异常账户提供服务，保障了在线服务的安全性。

在本申请的一个实施例中，上述装置中，数据交互单元310，用于通过前端页面展示的模板接收目标账户上报的用户状态信息；和/或，对目标账户上报的非结构化数据进行识别，得到结构化的用户状态信息；和/或，通过预设接口接收用户状态信息采集设备上报的用户状态信息，用户状态信息采集设备与目标账户相关联。

在本申请的一个实施例中，上述装置中，身体状态信息包括如下的至少一种：身份特征信息，健康状态信息，防护信息；账户状态单元320，用于依据身份特征信息进行身份识别和/或活体检测，若识别出的身份与目标账户不匹配，则确定账户异常；若检测失败，则确定账户异常；依据健康状态信息判断用户是否处于健康状态，否则确定账户异常；依据防护信息判断用户的着装防护是否符合预设条件，否则确定账户异常。

在本申请的一个实施例中，上述装置中，账户状态单元320，用于获取用户的活体检测的行为数据；将行为数据输入风险预测模型，通过风险预测模型输出行为数据对应的风险值；其中，风险预测模型为根据收集的历史活体检测的历史行为数据，以及历史行为数据对应的风险值标注信息训练得到；根据风险值，调整用户的活体检测的检测参数，以提高或者降低用户的活体检测的难度。

在本申请的一个实施例中，上述装置中，检测参数至少包括如下任意一项：目标动作个数、目标动作完成时间、最大活体检测次数、动作匹配阈值、以及人脸匹配阈值；账户状态单元，用于随着风险值的增大，增大用户的如下检测参数中的至少一项：目标动作个数、动作匹配阈值、人脸匹配阈值，以及减小用户的如下检测参数中的至少一项：目标动作完成时间和最大活体检测次数。

在本申请的一个实施例中，上述装置中，账户状态单元320，用于判断预设时间内连续检测失败的次数是否小于最大活体检测次数，若是，则获取用户输入的动作数据和人脸数据；根据调整后的目标动作个数和/或调整后的目标动作完成时间，计算动作数据中每一个动作与目标动作的第一匹配度；根据预录入的用户的目标人脸图像，计算人脸数据与目标人脸图像的第二匹配度；若第一匹配度超过调整后的动作匹配阈值，并且第二匹配度超过调整后的人脸匹配阈值，则确定用户的检测结果为检测成功。

在本申请的一个实施例中，上述装置中，账户状态单元320，用于若确定用户输入的动作数据和/或人脸数据满足如下任一条件，则确定用户的检测结果为检测失败：动作数据中包含的目标动作个数小于调整后的目标动作个数；或动作数据中包含的任意一个动作的完成时间大于调整后的目标动作完成时间；或动作数据中包含的任意一个动作与相对应的目标动作的第一匹配度小于调整后的动作匹配阈值；或人脸数据中存在预设数量的图像帧与目标人脸图像的第二匹配度小于调整后的人脸匹配阈值。

在本申请的一个实施例中，上述装置中，数据交互单元310，用于通过地理位置维度和/或业务维度确定需要上报用户状态信息的账户，在预设时间区间内，初次接收到目标账户上报的服务状态变更请求时，若目标账户为需要上报用户状态信息的账户，是则通知目标账户上报用户状态信息；和/或，接收目标账户在业务抽检过程中上报的用户状态信息；和/或，在已保存的目标账户的用户状态信息过期时，通知目标账户上报用户状态信息。

在本申请的一个实施例中，上述装置中，数据交互单元310，还用于若确定目标账户的账户异常，则将目标账户的账户状态和至少部分账户信息通知给与目标账户相关的管理账户，和/或，将账户状态提示信息下发给目标账户的关联设备进行展示。

在本申请的一个实施例中，上述装置还包括：业务单元，用于根据各账户的服务状态进行业务调度，根据业务调度结果，建立各账户与服务对象的关联关系；根据服务对象的业务请求，提供相应的业务页面；为业务页面提供展示接口，以使业务页面通过展示接口获取与服务对象相关联的账户的至少部分用户状态信息并展示。

在本申请的一个实施例中，上述装置中，业务单元，用于在业务调度结果发生变更时，相应调整各账户与服务对象的关联关系；根据调整后的关联关系，对业务页面进行刷新。

在本申请的一个实施例中，上述装置中，业务单元，还用于将用户状态信息写入信息卡模板的对应字段中，生成信息卡；在业务页面中添加生成的信息卡以进行展示，和/或在业务页面中添加信息卡控件，以使生成的信息卡根据信息卡控件的触发事件进行展示。

在本申请的一个实施例中，上述装置中，业务页面包括如下的至少一种：订单页面，配送详情页面，在线沟通页面。

在本申请的一个实施例中，上述装置中，配送详情页面包括地图，地图用于展示配送员的当前位置，配送员的账户为与服务对象相关联的账户；地图中用于标识配送员的元素是根据配送员的账户的用户状态信息确定的。

需要说明的是，上述各装置实施例的具体实施方式可以参照前述对应方法实施例的具体实施方式进行，在此不再赘述。

图4示出了根据本申请一个实施例的一种在线服务的实现系统的结构示意图。如图4所示，在线服务的实现系统400包括：服务器410，服务供给客户端420，服务消费客户端430。

服务器410中部署有如上述任一实施例所述在线服务的实现装置300。

服务供给客户端420，用于向服务器410发送目标账户的用户状态信息以及目标账户的服务状态变更请求，以及接收服务器410下发的业务调度结果。

服务消费客户端430，用于向服务器410发送业务请求，以及接收服务器返回的业务页面。

以外卖场景为例，当配送员准备上线开工时，进入其服务供给客户端上的开工页面，服务器判断出该配送员需要上报用户状态信息，以弹窗的形式在服务供给客户端上展示通知。配送员上报用户状态信息，服务器验证通过并保存后，配送员正式上线开工，接收服务器分配的配送任务。

一个场景下，配送员大力通过上述方式上线开工。此时消费者大伟在某商家下单，点了一份炒面，生成了订单，配送员大力通过系统调度接到这个订单的配送任务，建立起了大力与大伟之间的关联关系。当大伟希望查看自己的炒面被送到哪儿时，进入了配送详情页，地图中以大力的戴口罩头像显示出，大力距离自己还有1公里。此时配送详情页中还有一个条形状态栏，显示出大力今天体温是37度，配送箱已消毒。

综上所述，本申请的技术方案，通过接收目标账户上报的身体状态信息、业务设备状态信息等用户状态信息，确定账户状态，在接收目标账户的服务状态变更请求后，若目标账户的账户状态正常，则依据服务状态变更请求，相应地变更目标账户的服务状态；否则，拒绝变更目标账户的服务状态。该技术方案的有益效果在于，能够自动地获取到与服务场景相关的用户状态信息，高时效性地确定账户状态，拒绝异常账户提供服务，保障了在线服务的安全性。

需要说明的是：

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本申请也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本申请实施例的在线服务的实现装置和系统中的一些或者全部部件的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

例如，图5示出了根据本申请一个实施例的服务器的结构示意图。该服务器500包括处理器510和被安排成存储计算机可执行指令(计算机可读程序代码)的存储器520。存储器520可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。存储器520具有存储用于执行上述方法中的任何方法步骤的计算机可读程序代码531的存储空间530。例如，用于存储计算机可读程序代码的存储空间530可以包括分别用于实现上面的方法中的各种步骤的各个计算机可读程序代码531。计算机可读程序代码531可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，紧致盘(CD)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为例如图6所述的计算机可读存储介质。图6示出了根据本申请一个实施例的一种计算机可读存储介质的结构示意图。该计算机可读存储介质600存储有用于执行根据本申请的方法步骤的计算机可读程序代码531，可以被服务器500的处理器510读取，当计算机可读程序代码531由服务器500运行时，导致该服务器500执行上面所描述的方法中的各个步骤，具体来说，该计算机可读存储介质存储的计算机可读程序代码531可以执行上述任一实施例中示出的方法。计算机可读程序代码531可以以适当形式进行压缩。

应该注意的是上述实施例对本申请进行说明而不是对本申请进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (10)

1.一种在线服务的实现方法，包括：

接收目标账户上报的用户状态信息；所述用户状态信息包括：身体状态信息和业务设备状态信息，所述目标账户为服务提供者的账户，所述用户状态信息包括配送员的状态信息和商家的状态信息，所述身体状态信息包括体温以及是否咳嗽，所述业务设备状态信息包括业务设备是否清洗以及是否消毒，所述业务设备包括洗碗机、配送箱以及厨具中至少一种；

根据所述用户状态信息确定账户状态；

接收目标账户的服务状态变更请求，所述服务状态变更请求包括将目标账户的服务状态变更为上线状态的请求，所述上线状态是指能够提供在线服务的状态；

若目标账户的账户状态正常，则依据所述服务状态变更请求，相应地变更目标账户的服务状态，以使账户状态正常的服务提供者提供在线服务；否则，拒绝变更目标账户的服务状态；

所述身体状态信息还包括如下的至少一种：

身份特征信息，健康状态信息，防护信息；

所述根据所述用户状态信息确定账户状态包括：

依据所述身份特征信息进行身份识别和/或活体检测，若识别出的身份与目标账户不匹配，则确定账户异常；若检测失败，则确定账户异常；

依据所述健康状态信息判断用户是否处于健康状态，否则确定账户异常；

依据所述防护信息判断用户的着装防护是否符合预设条件，否则确定账户异常；

所述方法还包括：

根据各账户的服务状态进行业务调度，根据业务调度结果，建立各账户与服务对象的关联关系；

根据服务对象的业务请求，提供相应的业务页面；

为所述业务页面提供展示接口，以使业务页面通过所述展示接口获取与所述服务对象相关联的账户的至少部分用户状态信息并展示；

所述业务页面包括如下的至少一种：

订单页面，配送详情页面，在线沟通页面；

所述配送详情页面包括地图，所述地图用于展示配送员的当前位置，所述配送员的账户为与所述服务对象相关联的账户；

所述地图中用于标识配送员的元素是根据所述配送员的账户的用户状态信息确定的。

2.如权利要求1所述的方法，其特征在于，所述接收目标账户上报的用户状态信息包括：

通过前端页面展示的模板接收目标账户上报的用户状态信息；

和/或，

对目标账户上报的非结构化数据进行识别，得到结构化的用户状态信息；

和/或，

通过预设接口接收用户状态信息采集设备上报的用户状态信息，所述用户状态信息采集设备与所述目标账户相关联。

3.如权利要求1所述的方法，其特征在于，所述接收目标账户上报的用户状态信息包括：

通过地理位置维度和/或业务维度确定需要上报用户状态信息的账户，在预设时间区间内，初次接收到目标账户上报的服务状态变更请求时，若目标账户为需要上报用户状态信息的账户，是则通知目标账户上报用户状态信息；

和/或，

接收目标账户在业务抽检过程中上报的用户状态信息；

和/或，

在已保存的目标账户的用户状态信息过期时，通知目标账户上报用户状态信息。

4.如权利要求1所述的方法，其特征在于，所述方法还包括：

若确定目标账户的账户异常，则将目标账户的账户状态和至少部分账户信息通知给与目标账户相关的管理账户，和/或，将账户状态提示信息下发给目标账户的关联设备进行展示。

5.如权利要求1所述的方法，其特征在于，所述根据业务调度结果，建立各账户与服务对象的关联关系包括：

在业务调度结果发生变更时，相应调整各账户与服务对象的关联关系；

所述提供相应的业务页面包括：根据调整后的关联关系，对业务页面进行刷新。

6.如权利要求1所述的方法，其特征在于，所述方法还包括：将所述用户状态信息写入信息卡模板的对应字段中，生成信息卡；

所述根据服务对象的业务请求，提供相应的业务页面包括：在业务页面中添加生成的信息卡以进行展示，和/或在业务页面中添加信息卡控件，以使生成的信息卡根据所述信息卡控件的触发事件进行展示。

7.一种在线服务的实现装置，包括：

数据交互单元，用于接收目标账户上报的用户状态信息；所述用户状态信息包括：身体状态信息和业务设备状态信息，所述目标账户为服务提供者的账户；

账户状态单元，用于根据所述用户状态信息确定账户状态；

所述数据交互单元，还用于接收目标账户的服务状态变更请求，所述服务状态变更请求包括将目标账户的服务状态变更为上线状态的请求，所述上线状态是指能够提供在线服务的状态，所述用户状态信息包括配送员的状态信息和商家的状态信息，所述身体状态信息包括体温以及是否咳嗽，所述业务设备状态信息包括业务设备是否清洗以及是否消毒，所述业务设备包括洗碗机、配送箱以及厨具中至少一种；

服务状态单元，用于若目标账户的账户状态正常，则依据所述服务状态变更请求，相应地变更目标账户的服务状态，以使账户状态正常的服务提供者提供在线服务；否则，拒绝变更目标账户的服务状态；

所述身体状态信息还包括如下的至少一种：

身份特征信息，健康状态信息，防护信息；

所述账户状态单元用于：

依据所述身份特征信息进行身份识别和/或活体检测，若识别出的身份与目标账户不匹配，则确定账户异常；若检测失败，则确定账户异常；

依据所述健康状态信息判断用户是否处于健康状态，否则确定账户异常；

依据所述防护信息判断用户的着装防护是否符合预设条件，否则确定账户异常；

所述装置还包括：业务单元，用于根据各账户的服务状态进行业务调度，根据业务调度结果，建立各账户与服务对象的关联关系；根据服务对象的业务请求，提供相应的业务页面；为所述业务页面提供展示接口，以使业务页面通过所述展示接口获取与所述服务对象相关联的账户的至少部分用户状态信息并展示；

所述业务页面包括如下的至少一种：

订单页面，配送详情页面，在线沟通页面；

所述配送详情页面包括地图，所述地图用于展示配送员的当前位置，所述配送员的账户为与所述服务对象相关联的账户；

所述地图中用于标识配送员的元素是根据所述配送员的账户的用户状态信息确定的。

8.一种在线服务的实现系统，包括：服务器，服务供给客户端，服务消费客户端；

所述服务器中部署有如权利要求7所述的在线服务的实现装置；

所述服务供给客户端，用于向所述服务器发送目标账户的用户状态信息以及目标账户的服务状态变更请求，以及接收服务器下发的业务调度结果；

所述服务消费客户端，用于向所述服务器发送业务请求，以及接收服务器返回的业务页面。

9.一种服务器，其中，该服务器包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行如权利要求1-6中任一项所述的方法。

10.一种计算机可读存储介质，其中，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被处理器执行时，实现如权利要求1-6中任一项所述的方法。

Images