业务处理方法、装置、计算机设备和存储介质与流程

1.本技术涉及人工智能技术领域，特别是涉及一种业务处理方法、装置、计算机设备和存储介质。


背景技术：

2.随着社保业务的不断发展，社保业务的种类越来越丰富，例如社保政策咨询、保险购买等。为便于用户办理社保业务，社保业务的处理逐渐转移到线上。
3.然而，目前已有的线上社保业务处理方式，需要依赖专属终端设备(比如pos机)对用户的社保卡进行识别或者针对一些社保服务进行业务结算，存在社保业务办理不便捷，且成本高等问题，亟需改进。


技术实现要素：

4.基于此，有必要针对上述技术问题，提供一种能够低成本且便捷办理社保业务的业务处理方法、装置、计算机设备和存储介质。
5.第一方面，本技术提供了一种业务处理方法，该方法包括：
6.响应于服务需求方的社保业务申请操作，向社保服务端发起携带社保信息和服务需求信息的社保业务处理请求；其中，所述社保业务处理请求用于请求所述社保服务端根据所述社保信息和所述服务需求信息进行社保业务处理，并反馈社保业务处理结果；
7.获取所述社保服务端反馈的社保业务处理结果。
8.在其中一个实施例中，所述社保信息中包括所述服务需求方输入的可用激励元素；
9.所述社保业务处理请求具体用于请求所述社保服务端对所述可用激励元素的有效性进行验证，并在有效性验证通过的情况下，根据所述服务需求信息以及所述可用激励元素，进行社保业务处理。
10.在其中一个实施例中，该方法还包括：
11.响应于所述社保服务端发送的社保卡图像获取请求，采集所述服务需求方的社保卡图像并发送至所述社保服务端，以供所述社保服务端基于所述社保卡图像、所述社保信息和所述服务需求信息，进行社保业务处理。
12.在其中一个实施例中，所述社保信息还包括所述服务需求方输入的身份信息；
13.该方法还包括：
14.响应于所述社保服务端发送的生物特征获取请求，采集所述服务需求方的生物特征并发送至所述社保服务端，所述生物特征用于供所述社保服务端基于所述生物特征对所述身份信息进行身份验证，且在身份验证通过的情况下，根据所述社保卡图像、所述社保信息和所述服务需求信息，进行社保业务处理。
15.在其中一个实施例中，所述生物特征包括所述服务需求方的面部图像；
16.所述面部图像用于供所述社保服务端将所述面部图像与从所述社保卡图像中提
取的用户图像进行比对，且在确定所述面部图像与所述用户图像一致的情况下，基于所述社保卡图像提取社保文本信息，并根据所述社保文本信息、所述社保信息和所述服务需求信息，进行社保业务处理。
17.在其中一个实施例中，该方法还包括：
18.接收所述社保服务端发送的所述社保文本信息和所述服务需求信息，以供所述服务需求方进行信息确认。
19.在其中一个实施例中，该方法还包括：
20.响应于服务需求方的账户注册操作，向所述社保服务端发起账户注册请求；
21.接收所述社保服务端响应于所述账户注册请求反馈的生物特征采集请求；
22.响应于所述生物特征采集请求，采集所述服务需求方的生物特征，并反馈至所述社保服务端，用于供所述社保服务端将所述服务需求方的生物特征和身份信息关联存储。
23.第二方面，本技术还提供了一种业务处理方法，该方法包括：
24.获取终端发起的社保业务处理请求，所述社保业务处理请求中携带有携带社保信息和服务需求信息；
25.根据所述社保信息和所述服务需求信息，进行社保业务处理，并向所述终端反馈社保业务处理结果。
26.在其中一个实施例中，所述社保信息包括所述服务需求方输入的可用激励元素；
27.所述根据所述社保信息和所述服务需求信息，进行社保业务处理，包括：
28.对所述可用激励元素的有效性进行验证；
29.在有效性验证通过的情况下，根据所述服务需求信息以及所述可用激励元素，进行社保业务处理。
30.在其中一个实施例中，所述对所述可用激励元素的有效性进行验证，包括：
31.生成所述社保业务处理请求的密钥；
32.采用哈希算法和所述密钥，对所述可用激励元素进行处理，得到第一加密数据，并向可信第三方发送所述第一加密数据；
33.通过可信第三方向社保卡中心发起包括所述密钥的元素联合学习任务，以使所述社保卡中心基于所述密钥、哈希算法和扰动参数，对本地激励元素数据进行处理，得到第二加密数据，且将所述第二加密数据发送至所述可信第三方，以使所述可信第三方对所述第一加密数据和所述第二加密数据进行求交运算，并向所述社保服务端反馈求交结果；
34.获取所述求交结果，并将所述求交结果作为对所述可用激励元素有效性的验证结果。
35.在其中一个实施例中，所述通过可信第三方向社保卡中心发起包括所述密钥的元素联合学习任务，以使所述社保卡中心基于所述密钥、哈希算法和扰动参数，对本地激励元素数据进行处理，得到第二加密数据，且将所述第二加密数据发送至所述可信第三方，包括：
36.通过所述可信第三方获取所述社保卡中心发送的所述第二加密数据，并采用所述密钥对所述第二加密数据进行加密，得到第三加密数据；
37.通过所述可信第三方向所述社保卡中心发送所述第三加密数据，以使所述社保卡中心对所述第三加密数据进行哈希和去扰动处理，得到第四加密数据，并将所述第四加密
数据发送至所述可信第三方，由所述可信第三方对所述第一加密数据和所述第四加密数据进行求交运算，并向所述社保服务端反馈求交结果。
38.在其中一个实施例中，所述根据所述社保信息和所述服务需求信息，进行社保业务处理，包括：
39.向所述终端发送所述服务需求方的社保卡图像获取请求；其中，所述社保卡图像获取请求用于请求所述终端采集并反馈所述服务需求方的社保卡图像；
40.获取所述终端反馈的所述服务需求方的社保卡图像；
41.基于所述社保卡图像、所述社保信息和所述服务需求信息，进行社保业务处理。
42.在其中一个实施例中，所述社保信息中包括所述服务需求方输入的身份信息；
43.所述根据所述基于所述社保卡图像、所述社保信息和所述服务需求信息，进行社保业务处理之前，所述方法还包括：
44.向所述终端发送所述服务需求方的生物特征获取请求；其中，所述生物特征获取请求用于请求所述终端采集并反馈所述服务需求方的生物特性；
45.获取所述终端反馈的所述服务需求方的生物特征，并根据所述生物特征，对所述身份信息进行身份验证。
46.在其中一个实施例中，所述生物特征包括所述服务需求方的面部图像；
47.所述基于所述社保卡图像、所述社保信息和所述服务需求信息，进行社保业务处理之前，所述方法包括：
48.将所述面部图像与从所述社保卡图像中提取的用户图像进行比对；
49.所述基于所述社保卡图像、所述社保信息和所述服务需求信息，进行社保业务处理，包括：
50.在确定所述面部图像与所述用户图像一致的情况下，从所述社保卡图像中提取社保文本信息；
51.根据所述社保文本信息、所述社保信息和所述服务需求信息，进行社保业务处理。
52.在其中一个实施例中，该方法还包括：
53.向所述终端发送所述社保文本信息和所述服务需求信息，以供所述服务需求方进行信息确认。
54.在其中一个实施例中，该方法还包括：
55.响应于所述终端发送的账户注册请求，向所述终端反馈生物特征采集请求；其中，所述生物特征采集请求用于请求所述终端采集并反馈所述服务需求方的生物特征；
56.将所述服务需求方的生物特征和身份信息关联存储。
57.在其中一个实施例中，所述根据所述服务需求信息以及所述可用激励元素，进行社保业务处理，包括：
58.根据所述服务需求信息，进行社保业务服务处理；
59.向所述终端发送确认请求，所述确认请求用于请求所述服务需求方对社保业务服务事项和社保业务结算事项的正确性进行确认，并在确认正确的情况下，反馈确认文件；
60.获取所述终端反馈的确认文件，并根据所述可用激励元素，进行社保业务结算处理。
61.在其中一个实施例中，该方法还包括：
62.将所述社保业务处理请求、所述确认文件和结算结果关联存储于区块链中。
63.第三方面，本技术还提供了一种业务处理装置，该装置包括：
64.业务发起模块，用于响应于服务需求方的社保业务申请操作，向社保服务端发起携带社保信息和服务需求信息的社保业务处理请求；其中，所述社保业务处理请求用于请求所述社保服务端根据所述社保信息和所述服务需求信息，进行社保业务处理，并反馈社保业务处理结果；
65.结果获取模块，用于获取所述社保服务端反馈的社保业务处理结果。
66.第四方面，本技术还提供了一种业务处理装置，该装置包括：
67.业务获取模块，用于获取终端发起的社保业务处理请求，所述社保业务处理请求中携带有携带社保信息和服务需求信息；
68.业务处理模块，用于根据所述社保信息和所述服务需求信息，进行社保业务处理；
69.结果反馈模块，用于向所述终端反馈社保业务处理结果。
70.第五方面，本技术还提供了一种计算机设备，该计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：
71.响应于服务需求方的社保业务申请操作，向社保服务端发起携带社保信息和服务需求信息的社保业务处理请求；其中，所述社保业务处理请求用于请求所述社保服务端根据所述社保信息和所述服务需求信息进行社保业务处理，并反馈社保业务处理结果；
72.获取所述社保服务端反馈的社保业务处理结果。
73.第六方面，本技术还提供了一种计算机设备，该计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：
74.获取终端发起的社保业务处理请求，所述社保业务处理请求中携带有携带社保信息和服务需求信息；
75.根据所述社保信息和所述服务需求信息，进行社保业务处理，并向所述终端反馈社保业务处理结果。
76.第七方面，本技术还提供了一种计算机可读存储介质，该计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
77.响应于服务需求方的社保业务申请操作，向社保服务端发起携带社保信息和服务需求信息的社保业务处理请求；其中，所述社保业务处理请求用于请求所述社保服务端根据所述社保信息和所述服务需求信息进行社保业务处理，并反馈社保业务处理结果；
78.获取所述社保服务端反馈的社保业务处理结果。
79.第八方面，本技术还提供了一种计算机可读存储介质，该计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
80.获取终端发起的社保业务处理请求，所述社保业务处理请求中携带有携带社保信息和服务需求信息；
81.根据所述社保信息和所述服务需求信息，进行社保业务处理，并向所述终端反馈社保业务处理结果。
82.第九方面，本技术还提供了一种计算机程序产品，该计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：
83.响应于服务需求方的社保业务申请操作，向社保服务端发起携带社保信息和服务
需求信息的社保业务处理请求；其中，所述社保业务处理请求用于请求所述社保服务端根据所述社保信息和所述服务需求信息进行社保业务处理，并反馈社保业务处理结果；
84.获取所述社保服务端反馈的社保业务处理结果。
85.第十方面，本技术还提供了一种计算机程序产品，该计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：
86.获取终端发起的社保业务处理请求，所述社保业务处理请求中携带有携带社保信息和服务需求信息；
87.根据所述社保信息和所述服务需求信息，进行社保业务处理，并向所述终端反馈社保业务处理结果。
88.上述业务处理方法、装置、计算机设备和存储介质，终端通过向社保服务端发送社保业务处理请求，由社保服务端基于社保业务处理请求中所携带的服务需求信息和社保信息进行社保业务处理，并反馈社保业务处理结果。上述方案，在进行社保业务处理的整个过程中，无需依赖专属终端设备，降低了社保业务办理成本；同时，还省去了专属终端设备与社保卡中心等的交互过程，即降低了社保业务办理的复杂度，提高了社保业务办理的便捷性，进而促进了社保业务的推广。
附图说明
89.图1为一个实施例中业务处理方法的应用环境图；
90.图2为一个实施例中业务处理方法的流程示意图；
91.图3为一个实施例中账户注册的流程示意图；
92.图4为另一个实施例中业务处理方法的流程示意图；
93.图5为一个实施例中验证可用激励元素有效性的流程示意图；
94.图6为一个实施例中验证可用激励元素有效性的原理示意图；
95.图7为另一个实施例中验证可用激励元素有效性的流程示意图；
96.图8为一个实施例中进行社保业务处理处理的流程示意图；
97.图9为另一个实施例中进行社保业务处理处理的流程示意图；
98.图10为一个实施例中业务处理方法的信令图；
99.图11为一个实施例中业务处理装置的结构框图；
100.图12另为一个实施例中业务处理装置的结构框图；
101.图13为一个实施例中服务器的内部结构图；
102.图14为一个实施例中终端的内部结构图。
具体实施方式
103.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
104.本技术实施例提供的业务处理方法，可适用于社保业务处理场景，例如养老业务处理场景。可选的，整套的业务处理方法可以由社保服务端和终端配合实现。其中，社保服务端可以是承担社保业务处理相关事宜的服务器；终端可以是具有社保业务需求的一方
(即服务需求方)所持有的计算设备，或者可以是上门为服务需求方提供社保服务的服务提供方所持的计算设备。可选的，终端中可集成有社保服务端提供的社保业务处理工具；进一步的，社保业务处理工具可以以小程序、网页或者独立app等形式呈现。
105.图1是本技术的业务处理方法所适用的一种应用环境。其中，终端102通过网络与社保服务端104进行通信。数据存储系统可以存储社保服务端104需要处理的数据。数据存储系统可以集成在社保服务端104上，也可以放在云上或其他网络服务器上。可选的，本实施例中，终端可以向社保服务端发起社保业务处理请求，社保服务端响应社保业务处理请求，进行社保业务处理，并向终端反馈社保业务处理结果。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑、物联网设备和便携式可穿戴设备，物联网设备可为智能音箱、智能电视、智能空调、智能车载设备等。便携式可穿戴设备可为智能手表、智能手环、头戴设备等。社保服务端104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。进一步的，本实施例中的社保服务端可以是区块链网络中的一个区块链节点，也可以不是，若社保服务端不是区块链网络节点，则其可以通过某一区块链节点与区块链网络交互，将社保业务处理的相关数据存储于区块链网络中。
106.在一个实施例中，如图2所示，提供了一种业务处理方法，以该方法应用于图1中的终端为例进行说明，包括以下步骤：
107.s201，响应于服务需求方的社保业务申请操作，向社保服务端发起携带社保信息和服务需求信息的社保业务处理请求。
108.其中，社保业务申请操作可以是在服务需求方具有社保业务处理需求时，由终端操作者(如服务需求方本人或者上门为服务需求方提供社保服务的服务提供方)，通过语音或者手动输入等方式在终端上触发的服务需求方的社保业务申请操作。
109.例如，服务需求方在具有社保业务处理需求的情况下，通过终端登录社保业务处理工具，且在登录成功之后，根据社保业务处理工具所呈现的社保业务处理界面上的提示信息，输入相关信息，比如社保信息和服务需求信息等，并点击提交按钮。其中，服务需求方在社保业务处理界面上输入相关信息，以及点击提交按钮的操作，即为社保业务申请操作。
110.又或者，服务需求方通过电话或者社保业务处理工具，向社保服务端提交社保业务预约申请；社保服务端响应于社保业务预约申请，向服务提供方推送社保业务服务任务；服务提供方在获取到社保业务服务任务之后，上门为服务需求方提供服务。具体的，服务提供方可以通过终端进入社保业务处理工具，并根据社保服务端推送的社保业务服务任务等，在社保业务处理工具所呈现的社保业务处理界面上，输入相关信息，比如服务需求方的社保信息和服务需求信息等，并点击提交按钮。此时，服务提供方在社保业务处理界面上输入相关信息，以及点击提交按钮的操作，即为社保业务申请操作。
111.可选的，终端根据作用在社保业务处理界面上的社保业务申请操作，获取社保信息和服务需求信息；并按照设定格式，对社保信息和服务需求信息进行封装，得到社保业务处理请求；之后，向社保服务端发起社保业务处理请求。
112.其中，社保业务处理请求中可以包括服务需求方的社保信息和服务需求信息。其中，服务需求信息可以包括服务需求方所需要社保服务端提供的社保业务，比如养老保险购买业务，或者养老保险咨询业务等；社保信息可以包括但不限于服务需求方的身份信息、服务需求方的社保卡相关信息等。
113.进一步的，社保业务处理请求中还可以包括发起时间戳，以供社保服务端在社保业务处理压力较大的情况下，可以根据发起时间戳，依次对社保业务处理请求进行响应。
114.进一步的，在社保业务处理请求是由服务提供方触发的情况下，社保业务处理请求中还可以包括服务提供方的身份信息，以供社保服务端验证服务提供方的身份的真实性，进而保证社保上门服务的安全性。
115.可选的，社保业务处理请求用于请求社保服务端根据社保信息和服务需求信息，进行社保业务处理，并反馈社保业务处理结果。其中，社保业务处理结果可以包括社保业务处理完成情况，比如社保业务处理成功，或者社保业务处理失败。
116.s202，获取社保服务端反馈的社保业务处理结果。
117.具体的，终端可以获取社保服务端响应社保业务处理请求反馈的社保业务处理结果，并可以对社保业务处理结果进行展示。
118.进一步的，终端可以按照其所集成的显示屏的分辨率等，确定对社保业务处理结果的展示方式，并按照所确定的展示方式，对社保业务处理结果进行展示。
119.或者，终端还可以根据社保业务处理结果，确定展示方式；并采用所确定的展示方式，对社保业务处理结果进行展示。例如，若社保业务处理结果为社保业务处理成功，则可以以背景色为绿色的形式，来展示社保业务处理结果；若社保业务处理结果为社保业务处理失败，则可以以背景色为红色或是黄色的形式，来展示社保业务处理结果。
120.上述业务处理方法，终端通过向社保服务端发送社保业务处理请求，由社保服务端基于社保业务处理请求中所携带的服务需求信息和社保信息进行社保业务处理，并反馈社保业务处理结果。上述方案，在进行社保业务处理的整个过程中，无需依赖专属终端设备，降低了社保业务办理成本；同时，还省去了专属终端设备与社保卡中心等的交互过程，即降低了社保业务办理的复杂度，提高了社保业务办理的便捷性，进而促进了社保业务的推广。
121.需要指出的是，随着社保业务的不断发展，社保业务的种类越来越丰富，有些社保业务的办理需要结算服务，比如养老保险购买等，有些社保业务则不需要结算，比如养老保险咨询等。
122.对于需要结算服务的社保业务而言，需要服务需求方提供可用激励元素。所谓激励元素即为社保服务(比如养老服务)的一种电子津贴，可以以积分的形式呈现，比如重阳分。进一步的，本实施例中可用激励元素即为服务需求方提供的其社保账户下可用于对社保业务服务进行结算的激励元素。
123.也就是说，社保信息中还可以包括服务需求方输入的可用激励元素。
124.进一步的，在社保信息包括可用激励元素的情况下，社保业务处理请求具体可用于请求社保服务端对可用激励元素的有效性进行验证，并在有效性验证通过的情况下，根据服务需求信息以及可用激励元素，进行社保业务处理。
125.由于可用激励元素是服务需求方所提供的，而实际场景中可能存在服务需求方记错可用激励元素的情况，因此为保证结算的准确性，以及避免产生与服务需求方之间不必要的纠纷等，本实施例中社保服务端在进行社保业务处理之前，需要对服务需求方输入的可用激励元素的有效性进行验证。可选的，对可用激励元素的有效性进行验证的方式可以有很多种，本实施例对此不做限定。例如可以是将社保服务端本地最新存储的服务需求方
的可用激励元素，与服务需求方输入的可用激励元素进行一致性比较；根据一致性比对结果，来确定可用激励元素的有效性。又或者可以是通过与社保卡中心和可信第三方等进行联邦学习，来对可用激励元素的有效性进行验证等。进一步的，通过联邦学习来对可用激励元素的有效性进行验证的方式，将在后续实施例中进行详细介绍，在此不进行赘述。
126.具体的，终端向社保服务端发送携带社保信息和服务需求方信息的社保业务处理请求；由社保服务端对社保信息中的可用激励元素的有效性进行验证，并在有效性验证通过的情况下，按照预先设定的社保业务处理逻辑，根据服务需求信息以及可用激励元素，进行社保业务处理。比如，根据服务需求信息，进行社保业务服务处理，并在社保业务服务处理完成之后，根据可用激励元素，进行社保业务结算处理。
127.可以理解的是，在需要结算的社保业务场景下，本实施例中的可用激励元素由服务需求方直接提供，并由终端直接发送给社保服务端，无需依赖专属终端设备与社保卡中心进行交互来获取可用激励元素，进一步降低了社保业务办理的复杂度，以及降低了社保业务办理成本。此外，本实施例中在进行社保业务处理之前，还对可用激励元素的有效性进行验证，进而保证了后续社保业务结算的准确度，以及避免了社保服务端与服务需求方之间不必要的纠纷。
128.还需要指出的是，社保服务端要办理服务需求方所需要的任一社保业务，均需要服务需求方提供社保卡的相关信息。
129.在一可实施方式中，在社保信息中不包含服务需求方的社保卡的相关信息的场景下，社保服务端可以向终端发送社保卡图像获取请求，此时终端响应于社保服务端发送的社保卡图像获取请求，采集服务需求方的社保卡图像并发送至社保服务端，以供社保服务端基于社保卡图像、社保信息和服务需求信息，进行社保业务处理。
130.其中，社保卡图像获取请求用于请求终端采集服务需求方的社保卡图像，并反馈。
131.具体的，终端获取到社保服务端发送的社保卡图像获取请求之后，可以调用终端中所集成的图像采集装置，采集服务需求方的社保卡图像；之后通过终端中所集成的社保业务处理工具，将所采集的服务需求方的社保卡图像发送至社保服务端。由社保服务端从社保卡图像中提取办理社保业务所需的社保卡相关信息，并基于所提取的社保卡相关信息，以及社保信息和服务需求信息，进行社保业务处理。
132.进一步的，在社保信息中包括可用激励元素的情况下，社保服务端可以基于所提取的社保卡相关信息，以及可用激励元素和服务需求信息，进行社保业务处理。此时需要说明的是，终端与社保服务端交互获取社保卡图像的过程，与社保服务端对可用激励元素的有效性进行验证的过程，无先后之分，例如社保服务端可以先对可用激励元素的有效性进行验证，在有效性验证通过的情况下，再与终端进行交互获取社保卡图像，而后再基于社保卡图像、可用激励元素和服务需求信息进行社保业务处理。又或者，社保服务端在确定社保信息中无社保卡相关信息的情况下，可以先与终端进行交互获取社保卡图像，再对可用激励元素的有效性进行验证，且在有效性验证通过的情况下，基于社保卡图像、可用激励元素和服务需求信息进行社保业务处理。
133.可以理解的是，本实施例中终端直接通过与社保服务端进行交互，即可向社保服务端提供服务需求方的社保卡图像，来供社保服务端进行社保业务处理，进一步优化了社保业务处理过程，保证了社保业务处理过程的正常进行。
134.示例性的，在申请的一个实施例中，在社保信息还包括服务需求方输入的身份信息的情况下，为避免服务需求方假冒他人身份进行社保业务办理现象，社保服务端还可以向终端发送生物特征获取请求，此时终端响应于社保服务端发送的生物特征获取请求，采集服务需求方的生物特征并发送至社保服务端，生物特征用于供社保服务端基于生物特征对身份信息进行身份验证，且在身份验证通过的情况下，根据社保卡图像、社保信息和服务需求信息，进行社保业务处理。
135.其中，服务需求方输入的身份信息可以包括但不限于服务需求方的身份证号、姓名和手机号等信息。
136.生物特征获取请求用于请求终端采集服务需求方的生物特征，并反馈。可选的，生物特征获取请求中可以包括服务需求方的身份标识，比如身份id。进一步的，生物特征可以包括但不限于服务需求方的面部图像、指纹、虹膜和掌纹等。
137.具体的，终端获取到社保服务端发送的生物特征获取请求之后，可以根据生物特征获取请求中所包括的身份标识，定位服务需求方，并调用终端中所集成的采集装置(比如图像采集装置或指纹采集装置)，采集服务需求方的生物特征；之后通过终端中所集成的社保业务处理工具，将所采集的服务需求方的生物特征发送至社保服务端。由社保服务端基于生物特征对身份信息进行身份验证，且在身份验证通过的情况下，根据社保卡图像、社保信息和服务需求信息，进行社保业务处理。
138.本实施例中，社保服务端基于生物特征对身份信息进行身份验证可以是，社保服务端基于生物特征，从预先存储的身份数据库中查询并获取生物特征对应的身份信息，而后将所获取的身份信息，与社保信息中的身份信息进行一致性比对；若两者一致，则确定身份验证通过；否则确定身份验证未通过。
139.可以理解的是，本实施例中通过采用生物特征，来对社保信息中服务需求方输入的身份信息进行验证，可避免服务需求方假冒他人身份进行社保业务办理现象，保证了社保业务办理的规范性和有序性。
140.可选的，社保卡图像的用途并不局限于提取社保卡的相关信息，进行社保业务办理，还可以用来对服务需求方进行验证。
141.例如，在生物特征包括服务需求方的面部图像的场景下，面部图像可用于供社保服务端将面部图像与从社保卡图像中提取的用户图像进行比对，且在确定面部图像与用户图像一致的情况下，基于社保卡图像提取社保文本信息，并根据社保文本信息、社保信息和服务需求信息，进行社保业务处理。其具体实现过程，将在后续实施例中进行详细介绍，在此不进行赘述。其中，社保文本信息可以是采用文本识别技术(比如ocr技术)，从社保卡图像中所提取的文本信息；可选的，社保文本信息可以包括但不限于社保卡的持卡者的姓名、社保卡的有效期、序列号和社会保障号码等。
142.另外，还需要说明的是，社保服务端基于生物特征对身份信息进行身份验证的过程，与社保服务端将面部图像与用户图像进行比对的过程，无先后之分，两者可以并行执行，也可以先进行身份验证，并在身份验证通过的情况下，再进行图像比对过程。或者，还可以先进行图像比对，在比对一致的情况下，再进行身份验证的过程。
143.可以理解的是，在社保信息中不包含服务需求方的社保卡的相关信息的场景下，本实施例中终端直接通过与社保服务端进行交互，向社保服务端提供服务需求方的社保卡
图像，以供社保服务端基于社保卡图像中的社保文本信息进行社保业务处理，整个过程无需依赖专属终端设备对社保卡进行识别来获取社保文本信息，在保证社保业务处理过程正常进行的情况下，降低了社保业务办理的成本。同时，本实施例还引入图像对比的过程，来对服务需求方进行验证，可避免服务需求方盗用他人社保卡办理社保业务的现象，进一步规范了社保业务处理流程。
144.此外，为确保社保业务处理的可靠性，在一可实施方式中，社保服务端在从社保卡图像中提取到社保文本信息之后，可以向终端发送社保文本信息和服务需求信息，以供服务需求方进行信息确认。此时终端接收社保服务端发送的社保文本信息和服务需求信息，并向服务需求方展示社保文本信息和服务需求信息，以供服务需求方进行信息确认。
145.进一步的，终端还可以向社保服务端发送信息确认结果；由社保服务端在识别到信息确认结果为信息正确的情况下，基于社保文本信息、社保信息和服务需求信息，进行社保业务处理。
146.可以理解的是，操作者要使用终端中集成的社保业务处理工具，办理相关社保事宜，首先需要成为社保服务端的用户。如果操作者不是社保服务端的用户，那么在进行社保业务处理之前(即在s201之前)，需要进行注册，成为社保服务端的用户。图3为一个实施例中账户注册的流程示意图。在上述实施例的基础上，本实施例涉及如何进行账户注册的过程。如图3所示，具体可以包括以下步骤：
147.s301，响应于服务需求方的账户注册操作，向社保服务端发起账户注册请求。
148.其中，账户注册操作可以是操作者根据社保业务处理工具所提供的注册界面上的提示信息，输入相关信息，并点击提交按钮的操作。
149.具体的，终端根据作用在注册界面上的服务需求方的账户注册操作，获取服务需求方的注册信息；并按照设定格式，对注册信息进行封装，得到账户注册请求；之后，向社保服务端发起账户注册请求。进一步的，账户注册请求中可以包括服务需求方的身份信息。
150.可选的，账户注册请求可用于指示社保服务端基于服务需求方的注册信息，为服务需求方分配账户，且在账户分配完成之后，向终端反馈生物特征采集请求。其中，生物特征采集请求用于指示终端采集服务需求方的生物特征，并反馈。可选的，生物特征采集请求中可以包括服务需求方的身份标识，用于供终端定位服务需求方。
151.s302，接收社保服务端响应于账户注册请求反馈的生物特征采集请求。
152.s303，响应于生物特征采集请求，采集服务需求方的生物特征，并反馈至社保服务端，用于社保服务端将服务需求方的生物特征和身份信息关联存储。
153.具体的，终端在接收到社保服务端反馈的生物特征采集请求之后，可以根据生物特征采集请求中所包括的身份标识，定位服务需求方，并调用终端中所集成的采集装置(比如图像采集装置或指纹采集装置)，采集服务需求方的生物特征；之后通过终端中所集成的社保业务处理工具，将所采集的服务需求方的生物特征发送至社保服务端。由社保服务端将服务需求方的生物特征，与从账户注册请求中提取的服务需求方的身份信息进行关联存储。
154.进一步的，社保服务端可以将服务需求方的生物特征和身份信息关联存储于本地身份数据库中，用于供社保业务处理过程中，基于终端提供的生物特征，从本地身份数据库中抓取身份信息，来对服务需求方输入的身份信息进行身份验证。
155.可以理解的是，本实施例中所提供的账户注册流程，为服务需求方能够通过终端快捷进行社保业务办理提供了保障。
156.在一个实施例中，如图4所示，提供了一种业务处理方法，以该方法应用于图1中的社保服务端为例进行说明，包括以下步骤：
157.s401，获取终端发起的社保业务处理请求，社保业务处理请求中携带有携带社保信息和服务需求信息。
158.s402，根据社保信息和服务需求信息，进行社保业务处理，并向终端反馈社保业务处理结果。
159.具体的，社保服务端在获取到终端发起的社保业务处理请求之后，可以基于预先设定的社保业务处理逻辑，根据社保业务处理请求中携带的社保信息和服务需求信息，进行社保业务处理，并向终端反馈社保业务处理结果，以供服务需求方查看。
160.上述业务处理方法，社保服务端基于终端发送的社保业务处理请求中所携带的服务需求信息和社保信息进行社保业务处理，并向终端反馈社保业务处理结果。上述方案，在进行社保业务处理的整个过程中，无需依赖专属终端设备，降低了社保业务办理成本；同时，还省去了专属终端设备与社保卡中心等的交互过程，即降低了社保业务办理的复杂度，提高了社保业务办理的便捷性，进而促进了社保业务的推广。
161.进一步的，在上述实施例的基础上，在社保信息包括服务需求方输入的可用激励元素的情况下，社保服务端执行s402中根据社保信息和服务需求信息，进行社保业务处理的过程可以是，对可用激励元素的有效性进行验证；在有效性验证通过的情况下，根据服务需求信息以及可用激励元素，进行社保业务处理。
162.具体的，可以按照预先设定的验证逻辑，对可用激励元素的有效性进行验证，并在有效性验证通过的情况下，根据服务需求信息，进行社保业务服务处理。比如服务需求信息包括养老保险购买业务，那么可以根据养老保险购买业务的执行逻辑，为服务需求方提供养老保险购买业务服务。
163.在社保业务服务处理完成之后，可以根据可用激励元素，进行社保业务结算处理。具体可以是，确定社保业务服务所需激励元素，若所需激励元素小于可用激励元素，则从可用激励元素中扣除所需激励元素；若所需激励元素大于可用激励元素，则根据所需激励元素和可用激励元素，确定待扣金额，扣除所有可用激励元素，并从服务需求方的社保卡余额中扣除待扣金额。
164.可以理解的是，在需要结算的社保业务场景下，本实施例中的可用激励元素由服务需求方直接提供，并由终端直接发送给社保服务端，无需依赖专属终端设备与社保卡中心进行交互来获取可用激励元素，进一步降低了社保业务办理的复杂度，以及降低了社保业务办理成本。此外，本实施例中在进行社保业务处理之前，还对可用激励元素的有效性进行验证，进而保证了后续社保业务结算的准确度，以及避免了社保服务端与服务需求方之间不必要的纠纷。
165.可选的，社保服务端对可用激励元素的有效性进行验证的方式可以有很多种，本实施例对此不做限定。其中，一种可实施方式是，将社保服务端本地最新存储的服务需求方的可用激励元素，与服务需求方输入的可用激励元素进行一致性比较；根据一致性比对结果，来确定可用激励元素的有效性。
166.又一种可实施方式是，通过与社保卡中心和可信第三方等进行联邦学习，来对可用激励元素的有效性进行验证。其中，社保卡中心即为提供社保卡办理相关事宜的中心；可信第三方即为社保卡中心和社保服务端共同信任的第三方机构。
167.结合图5和图6所示，社保服务端通过同社保卡中心和可信第三方进行联邦学习，来对可用激励元素的有效性进行验证的过程，具体可以通过以下步骤实现：
168.s501，生成社保业务处理请求的密钥。
169.可选的，本实施例中可以基于预先设定的密钥生成逻辑，来生成社保业务处理请求的密钥。需要说明的是，本实施例中社保业务处理请求与密钥之间具有一一对应关系，即每一社保业务处理请求对应唯一的密钥。这样设置的好处在于，可保证社保业务处理过程的安全性。
170.s502，采用哈希算法和密钥，对可用激励元素进行处理，得到第一加密数据，并向可信第三方发送第一加密数据。
171.具体的，本实施例中社保服务端可以利用密钥和设定的哈希算法，对可用激励元素和服务需求方的身份信息进行处理，得到第一加密数据，并将第一加密数据发送至可信第三方。
172.s503，通过可信第三方向社保卡中心发起包括密钥的元素联合学习任务，以使社保卡中心基于密钥、哈希算法和扰动参数，对本地激励元素数据进行处理，得到第二加密数据，且将第二加密数据发送至可信第三方，以使可信第三方对第一加密数据和第二加密数据进行求交运算，并向社保服务端反馈求交结果。
173.本实施例中，所谓元素联合学习任务用于指示社保卡中心同可信第三方和社保服务端交互，对社保服务端提供的数据进行联合验证；进一步的，元素联合学习任务的形式可区别于其他联合任务，以便社保卡中心通过识别元素联合学习任务的形式能够快速确定需要对哪些数据进行处理。其中，扰动参数可以是可信第三方、社保服务端和社保卡中心三方预先联合训练得到的一个参数，用于在联合验证过程中保证社保卡中心数据的安全性。
174.本地激励元素数据即为社保卡中心所存储的所有社保账户下实际具有的激励元素数据。可选的，本地激励元素中包括每一社保账户下的实际激励元素；其中，社保账户即为社保卡的账户。
175.具体的，如图6所示，社保服务端与社保卡中心，通过可信第三方交互。因此，社保服务端通过可信第三方向社保卡中心发起包括密钥的元素联合学习任务可以是，社保服务端可以向可信第三方发起包括密钥的元素联合学习任务，由可信第三方将元素联合学习任务转发至社保卡中心；或者，社保服务端可以向可信第三方发送包括密钥的元素联邦学习通知，由可信第三方基于元素联邦学习通知，生成一个元素联邦学习任务，并发送至社保卡中心。
176.进一步的，社保卡中心在获取到元素联合学习任务之后，可以采用密钥和扰动参数，以及与社保服务端相同的哈希算法，对本地激励元素数据和对应的社保账户的身份信息进行处理，得到第二加密数据。具体可以是，对于社保卡中心所存储的每一社保账户，社保卡中心均会采用密钥和扰动参数，以及与社保服务端相同的哈希算法，对该社保账户对应的身份信息和实际激励元素进行处理，得到一个第二加密数据。也就是说，第二加密数据的数量，与社保卡中心所具有的社保账户的数量相同。
177.进一步的，社保卡中心在获得第二加密数据之后，可以将所获得的第二加密数据发送至可信第三方。由可信第三方可以对第一加密数据和第二加密数据进行求交运算，并将求交结果反馈至社保服务端。
178.可选的，求交结果可以是第一加密数据和第二加密数据存在交集，或者可以是第一加密数据和第二加密数据不存在交集。
179.需要说明的是，本实施例中社保服务端向可信第三方发送第一加密数据的过程，以及通过可信第三方向社保卡中心发起元素联合学习任务的过程，无先后之后，两者可以并行执行。或者还可以先执行通过可信第三方向社保卡中心发起元素联合学习任务的过程，再执行向可信第三方发送第一加密数据的过程。
180.s504，获取求交结果，并将求交结果作为对可用激励元素有效性的验证结果。
181.具体的，社保服务端在获取到可信第三方发送的求交结果之后，可以直接将求交结果作为对可用激励元素有效性的验证结果。可选的，若求交结果为不存在交集，则确定可用激励元素的无效；若求交结果为存在交集，则确定可用激励元素有效。
182.需要说明的是，本实施例社保服务端通过同社保卡中心和可信第三方进行交互，来对可用激励元素进行验证的过程，实质是一种基于隐私求交进行数据验证的过程，该过程能够在保证社保卡中心数据安全的情况下，实现对可用激励元素的验证。进一步的，本实施例中在此验证过程中，还引入了扰动参数，进一步保证了社保卡中心数据的安全性。
183.在一可实施方式中，如果社保服务端所生成的密钥为非对称密钥对，即包括私钥和公钥，此时结合图7，对可用激励元素的有效性进行验证的过程，具体可以包括：
184.s701，生成社保业务处理请求的密钥。
185.s702，采用哈希算法和密钥，对可用激励元素进行处理，得到第一加密数据，并向可信第三方发送第一加密数据。
186.具体的，本实施例中社保服务端可以利用密钥(如私钥)和设定的哈希算法，对可用激励元素和服务需求方的身份信息进行多次(比如2次)哈希处理，得到第一加密数据，并将第一加密数据发送至可信第三方。
187.例如，非对称密钥中的私钥用b来表示，公钥用a来表示。服务需求方的身份信息和可用激励元素采用id1来表示，则第一加密数据可以表示为，d1＝hash(b(hash(id1)))。
188.s703，通过可信第三方向社保卡中心发起包括密钥的元素联合学习任务，以使社保卡中心基于密钥、哈希算法和扰动参数，对本地激励元素数据进行处理，得到第二加密数据，并反馈。
189.具体的，社保服务端通过可信第三方向社保卡中心发送包括密钥(比如公钥)的元素联合学习任务。社保卡中心在获取到元素联合学习任务之后，可以采用密钥(比如公钥)和扰动参数，以及与社保服务端相同的哈希算法，对本地激励元素数据和对应的社保账户的身份信息进行处理，得到第二加密数据。
190.例如，对于本地激励元素中任一社保账户下的实际激励元素，和该社保账户对应的身份信息，采用id2来表示，则对应的第二加密数据可以表示为，z＝a(扰动)*hash(id2)
191.进一步的，社保卡中心在获得第二加密数据之后，可以通过可信第三方将第二加密数据反馈至社保服务端。
192.s704，通过可信第三方获取社保卡中心发送的第二加密数据，并采用密钥对第二
加密数据进行加密，得到第三加密数据。
193.具体的，社保服务端在获取到第二加密数据的情况下，可以采用密钥(比如私钥)对第二加密数据进行加密，得到第三加密数据。
194.例如，社保服务端对上述第二加密数据z进行处理，得到对应的第三加密数据可以表示为，y＝b(a(扰动)*hash(id2))。
195.s705，通过可信第三方向社保卡中心发送第三加密数据，以使社保卡中心对第三加密数据进行哈希和去扰动处理，得到第四加密数据，并将第四加密数据发送至可信第三方，由可信第三方对第一加密数据和第四加密数据进行求交运算，并向社保服务端反馈求交结果。
196.具体的，社保服务端在得到第三加密数据之后，可以通过可信第三方将第三加密数据发送至社保卡中心。此时，社保卡中心可以按照设定的逻辑，对第三加密数据进行去扰动，且再次采用哈希算法对去扰动后的第三加密数据进行哈希处理，得到第四加密数据。例如对上述y进行去扰动和哈希处理，得到对应的第四加密数据可以表示为，d2＝hash(b(hash(id2)))。
197.之后，社保卡中心将所得到的第四加密数据发送至可信第三方，由可信第三方对第一加密数据和第四加密数据进行求交运算，并向社保服务端反馈求交结果。
198.s706，获取求交结果，并将求交结果作为对可用激励元素有效性的验证结果。
199.本实施例中，通过对隐私求交进行数据验证的过程进行细化，进一步保证了社保卡中心数据的安全性。
200.可以理解的是，社保服务端要办理服务需求方所需要的任一社保业务，均需要服务需求方提供社保卡的相关信息。在一可实施方式中，在社保信息中不包含服务需求方的社保卡的相关信息的场景下，提供了一种对s402中进行社保业务处理过程的可选方式。如图8所示，具体可以通过以下步骤实现：
201.s801，向终端发送服务需求方的社保卡图像获取请求。
202.其中，社保卡图像获取请求用于请求终端采集并反馈服务需求方的社保卡图像。
203.s802，获取终端反馈的服务需求方的社保卡图像。
204.s803，基于社保卡图像、社保信息和服务需求信息，进行社保业务处理。
205.具体的，社保服务端在确定社保信息中不包含社保卡相关信息的情况下，可以向终端发送服务需求方的社保卡图像获取请求；由终端响应社保卡图像获取请求，采用服务需求方的社保卡图像，并反馈。
206.社保服务端在获取到社保卡图像之后，可以从社保卡图像中提取社保卡相关信息，比如可以采用ocr识别技术从社保卡图像中提取社保文本信息，而后基于社保文本信息、社保信息和服务需求信息，进行社保业务处理。
207.例如，在社保信息包括可用激励元素的情况下，社保服务端可以基于社保文本信息和服务需求信息，进行社保业务服务处理。比如服务需求信息包括养老保险购买业务，那么社保服务端可以基于养老保险购买业务的执行逻辑，以及社保文本信息，为服务需求方提供养老保险购买业务服务。
208.在社保业务服务处理完成之后，可以根据可用激励元素，进行社保业务结算处理。
209.本实施例中，终端直接通过与社保服务端进行交互，即可向社保服务端提供服务
需求方的社保卡图像，来供社保服务端进行社保业务处理，进一步优化了社保业务处理过程，保证了社保业务处理过程的正常进行。
210.需要说明的是，在社保信息包括可用激励元素的情况下，终端与社保服务端交互获取社保卡图像的过程，与社保服务端对可用激励元素的有效性进行验证的过程，无先后之分，例如社保服务端可以先对可用激励元素的有效性进行验证，在有效性验证通过的情况下，再与终端进行交互获取社保卡图像，而后再基于社保卡图像、可用激励元素和服务需求信息进行社保业务处理。又或者，社保服务端在确定社保信息中无社保卡相关信息的情况下，可以先与终端进行交互获取社保卡图像，再对可用激励元素的有效性进行验证，且在有效性验证通过的情况下，基于社保卡图像、可用激励元素和服务需求信息进行社保业务处理。
211.在一实施例中，在社保信息还包括服务需求方输入的身份信息的情况下，为避免服务需求方假冒他人身份进行社保业务办理现象，在进行社保业务处理之前，即在执行s402的过程之前，或者在执行s803的过程之前，社保服务端还可以向终端发送服务需求方的生物特征获取请求，其中，生物特征获取请求用于请求终端采集并反馈服务需求方的生物特性；获取终端反馈的服务需求方的生物特征，并根据生物特征，对身份信息进行身份验证。
212.具体的，社保服务端向终端发送包括服务需求方的身份标识的生物特征获取请求；由终端根据生物特征获取请求中所包括的身份标识，定位服务需求方，并调用终端中所集成的采集装置(比如图像采集装置或指纹采集装置)，采集服务需求方的生物特征；之后通过终端中所集成的社保业务处理工具，将所采集的服务需求方的生物特征发送至社保服务端。
213.社保服务端基于生物特征对身份信息进行身份验证。例如社保服务端基于生物特征，从预先存储的身份数据库中查询并获取生物特征对应的身份信息，而后将所获取的身份信息，与社保信息中的身份信息进行一致性比对；若两者一致，则确定身份验证通过；否则确定身份验证未通过。
214.进一步的，在身份验证通过的情况下，社保服务端执行社保业务处理过程。例如，在身份验证通过的情况下，社保服务端可以执行s402的过程，即根据社保信息和服务需求信息，进行社保业务处理。
215.进一步的，在对身份验证的过程位于s803之前时，对身份验证的过程，与s801和s802获取社保卡图像的过程没有先后之分，两者可以并行执行，也可以先执行获取社保卡图像的过程，再执行身份验证，而后在身份验证通过的情况下，执行s803的过程，即根据社保卡图像、社保信息和服务需求信息，进行社保业务处理。或者，还可以先执行身份验证的过程，而后在身份验证通过的情况下，执行s801-s803的过程。
216.可以理解的是，本实施例中通过采用生物特征，来对社保信息中服务需求方输入的身份信息进行验证，可避免服务需求方假冒他人身份进行社保业务办理现象，保证了社保业务办理的规范性和有序性。
217.在一实施例中，若生物特征包括服务需求方的面部图像，则在对社保业务进行处理之前，即在执行s803的过程之前，社保服务端还可以将面部图像与社保卡图像中提取的用户图像进行比对，来实现对服务需求方的进一步验证。具体的，社保服务端可以采用图像
识别技术，从社保卡图像中识别并提取用户图像；将面部图像与所提取的用户图像进行比对；若两者一致，则说明社保卡是服务需求方本人的；若两者不一致，则说明社保卡不是服务需求方本人的。
218.为避免服务需求方盗用他人社保卡办理社保业务的现象，进一步规范社保业务处理流程。进一步的，在两者一致，即确定面部图像与用户图像一致的情况下，本实施例中的社保服务端才继续执行对社保业务进行处理的过程。比如，社保服务端继续执行s803基于社保卡图像、社保信息和服务需求信息，进行社保业务处理过程。进一步可以是，社保服务端从社保卡图像中提取社保文本信息，并根据社保文本信息、社保信息和服务需求信息，进行社保业务处理。例如，社保服务端采用文本识别技术(比如ocr技术)，从社保卡图像中所提取的文本信息，并根据社保文本信息和服务需求信息，进行社保业务服务处理；且在社保业务服务处理完成之后，根据社保信息中的可用激励元素，进行社保业务结算处理。
219.另外，还需要说明的是，社保服务端基于生物特征对身份信息进行身份验证的过程，与社保服务端将面部图像与用户图像进行比对的过程，无先后之分，两者可以并行执行，也可以先进行身份验证，并在身份验证通过的情况下，再进行图像比对过程。或者，还可以先进行图像比对，在比对一致的情况下，再进行身份验证的过程。
220.可以理解的是，在社保信息中不包含服务需求方的社保卡的相关信息的场景下，本实施例中终端直接通过与社保服务端进行交互，向社保服务端提供服务需求方的社保卡图像，以供社保服务端基于社保卡图像中的社保文本信息进行社保业务处理，整个过程无需依赖专属终端设备对社保卡进行识别来获取社保文本信息，在保证社保业务处理过程正常进行的情况下，降低了社保业务办理的成本。同时，本实施例还引入图像对比的过程，来对服务需求方进行验证，可避免服务需求方盗用他人社保卡办理社保业务的现象，进一步规范了社保业务处理流程。
221.此外，为确保社保业务处理的可靠性，在一可实施方式中，社保服务端在从社保卡图像中提取到社保文本信息之后，可以向终端发送社保文本信息和服务需求信息，以供服务需求方进行信息确认。此时终端接收社保服务端发送的社保文本信息和服务需求信息，并向服务需求方展示社保文本信息和服务需求信息，以供服务需求方进行信息确认。
222.进一步的，终端还可以向社保服务端发送信息确认结果；社保服务端在识别到信息确认结果为信息正确的情况下，再基于社保文本信息、社保信息和服务需求信息，进行社保业务处理。
223.需要说明的是，本实施例中所涉及的任一验证操作，比如对可用激励元素有效性的验证、对身份信息的身份验证、以及面部图像和用户图像比对等。若该验证操作的结果为未通过，比如有效性验证未通过，或者身份验证未通过等，则社保服务端将停止执行后续操作，比如后续验证过程，或者社保业务处理过程等。
224.可以理解的是，操作者要使用终端中集成的社保业务处理工具，办理相关社保事宜，首先需要成为社保服务端的用户。如果操作者不是社保服务端的用户，那么在进行社保业务处理(即在s401)之前，需要进行注册，成为社保服务端的用户。示例性的，在上述实施例的基础上，社保服务端进行账户注册的过程具体可以是：响应于终端发送的账户注册请求，向终端反馈生物特征采集请求；其中，生物特征采集请求用于请求终端采集并反馈服务需求方的生物特征；将服务需求方的生物特征和身份信息关联存储。
225.其中，账户注册请求是终端响应于服务需求方的账户注册操作向社保服务端所发起的请求。
226.具体的，终端向社保服务端发起账户注册请求；社保服务端响应于终端发送的账户注册请求，为服务需求方分配账户，且在账户分配完成之后，向终端反馈生物特征采集请求；终端在接收到社保服务端反馈的生物特征采集请求之后，采集服务需求方的生物特征，并向社保服务端反馈；社保服务端获取到终端反馈的服务需求方的生物特征之后，将服务需求方的生物特征，与从账户注册请求中提取的服务需求方的身份信息进行关联存储。
227.进一步的，社保服务端可以将服务需求方的生物特征和身份信息关联存储于本地身份数据库中，用于供社保业务处理过程中，基于终端提供的生物特征，从本地身份数据库中抓取身份信息，来对服务需求方输入的身份信息进行身份验证。
228.可以理解的是，本实施例中所提供的账户注册流程，为服务需求方能够通过终端快捷进行社保业务办理提供了保障。
229.图9为另一个实施例中进行社保业务处理处理的流程示意图；本实施例在上述实施例的基础上，又提供了一种对s402中进行社保业务处理过程进行细化的可选方式。如图9所示，具体可以通过以下步骤实现：
230.s901，根据服务需求信息，进行社保业务服务处理。
231.s902，向终端发送确认请求。
232.本实施例中，确认请求可以是社保服务端在确定社保业务服务处理完成的情况下，向终端所发送的请求，用于请求服务需求方对社保业务服务事项和社保业务结算事项的正确性进行确认，并确认正确的情况下，反馈确认文件。
233.可选的，确认请求中可以包括以电子文档的形式呈现的详情单，具体可以包括社保业务服务事项和社保业务结算事项。其中，社保业务服务事项即为社保服务端实际为服务需求方所提供的社保业务服务的具体内容，社保业务结算事项即为社保服务端实际为服务需求方所提供的社保业务服务的费用详情。
234.一种可实现方式为，社保服务端向终端发送确认请求；终端接收确认请求之后，通过所集成的蓝牙模块连接热敏打印机，将确认请求中的详情单进行打印，供服务需求方确认并签字。进一步的，在服务需求方签字确认之后，终端可以通过所集成的图像采集装置对签字后详情单进行采集，并发送至社保服务端。
235.又一种实现方式为，社保服务端向终端发送确认请求；终端接收到确认请求之后，直接打开确认请求中的详情单，供服务需求方阅读并在线签字确认；进一步的，终端在接收到服务需求方对详情单的签字后，直接将签字后的详情单反馈至社保服务端。
236.本实施例中，确认文件即为服务需求方签字确认后的详情单。
237.s903，获取终端反馈的确认文件，并根据可用激励元素，进行社保业务结算处理。
238.可选的，社保服务端在接收到终端发送的确认文件之后，将进行结算事宜，即根据可用激励元素，进行社保业务结算。
239.进一步的，为便于后续溯源，本实施例还可以将社保业务处理请求、确认文件和结算结果关联存储于区块链中。
240.可以理解的是，本实施例在社保业务处理过程中，引入确认过程，为社保业务处理过程留下了凭证，便于后续追溯。
241.在一个实施例中，给出了一种终端和社保服务端交互实现业务处理方法的可选实例。结合图10所示的业务处理方法的信令交互流程示意图，该方法具体可以通过以下步骤实现：
242.s1001，终端响应于服务需求方的社保业务申请操作，向社保服务端发起携带社保信息和服务需求信息的社保业务处理请求；社保信息包括服务需求方输入的可用激励元素和身份信息。
243.s1002，社保服务端对可用激励元素的有效性进行验证。
244.s1003，在有效性验证通过的情况下，社保服务端向终端发送服务需求方的面部图像获取请求。
245.s1004，终端响应于社保服务端发送的面部图像获取请求，采集服务需求方的面部图像并发送至社保服务端。
246.s1005，社保服务端根据面部图像，对身份信息进行身份验证。
247.s1006，在身份验证通过的情况下，社保服务端向终端发送服务需求方的社保卡图像获取请求。
248.s1007，终端响应于社保服务端发送的社保卡图像获取请求，采集服务需求方的社保卡图像并发送至社保服务端。
249.s1008，社保服务端从社保卡图像中提取用户图像，并将用户图像与面部图像进行比对。
250.s1009，社保服务端在确定面部图像与用户图像一致的情况下，从社保卡图像中提取社保文本信息，并根据社保文本信息和服务需求信息，进行社保业务服务处理。
251.s1010，社保服务端在确定社保业务服务处理完成的情况下，向终端发送确认请求。
252.s1011，终端响应于确认请求，调用终端中所集成的蓝牙模块连接热敏打印机，对确认请求中的详情单进行打印，供服务需求方对社保业务服务事项和社保业务结算事项的正确性进行确认，并在确认正确的情况下，向社保服务端反馈确认文件。
253.s1012，社保服务端在接收到确认文件之后，根据可用激励元素，进行社保业务结算处理。
254.s1013，社保服务端将社保业务处理请求、确认文件和结算结果关联存储于区块链中。
255.上述s1001-s1013的具体过程可以参见上述方法实施例的描述，其实现原理和技术效果类似，在此不再赘述。
256.应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
257.基于同样的发明构思，本技术实施例还提供了一种用于实现上述所涉及的业务处
理方法的业务处理装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个业务处理装置实施例中的具体限定可以参见上文中对于业务处理方法的限定，在此不再赘述。
258.在一个实施例中，如图11所示，提供了一种业务处理装置1，该装置可配置于终端中，包括：业务发起模块10和结果获取模块11，其中：
259.业务发起模块10，用于响应于服务需求方的社保业务申请操作，向社保服务端发起携带社保信息和服务需求信息的社保业务处理请求；其中，社保业务处理请求用于请求社保服务端根据社保信息和服务需求信息，进行社保业务处理，并反馈社保业务处理结果；
260.结果获取模块11，用于获取社保服务端反馈的社保业务处理结果。
261.在其中一个实施例中，社保信息中包括服务需求方输入的可用激励元素；
262.社保业务处理请求具体用于请求社保服务端对可用激励元素的有效性进行验证，并在有效性验证通过的情况下，根据服务需求信息以及可用激励元素，进行社保业务处理。
263.在其中一个实施例中，上述业务处理装置还包括：
264.第一响应模块，用于响应于社保服务端发送的社保卡图像获取请求，采集服务需求方的社保卡图像并发送至所述社保服务端，以供社保服务端基于社保卡图像、社保信息和服务需求信息，进行社保业务处理。
265.在其中一个实施例中，所述社保信息还包括所述服务需求方输入的身份信息；上述业务处理装置还包括：
266.第二响应模块，响应于社保服务端发送的生物特征获取请求，采集服务需求方的生物特征并发送至所述社保服务端，生物特征用于供所述社保服务端基于生物特征对身份信息进行身份验证，且在身份验证通过的情况下，根据社保卡图像、社保信息和服务需求信息，进行社保业务处理。
267.在其中一个实施例中，生物特征包括所述服务需求方的面部图像；面部图像用于供社保服务端将所述面部图像与从社保卡图像中提取的用户图像进行比对，且在确定面部图像与用户图像一致的情况下，基于社保卡图像提取社保文本信息，并根据社保文本信息、社保信息和服务需求信息，进行社保业务处理。
268.在其中一个实施例中，上述业务处理装置还包括：
269.第一接收模块，用于接收社保服务端发送的社保文本信息和所述服务需求信息，以供服务需求方进行信息确认。
270.在其中一个实施例中，上述业务处理装置还包括：
271.注册发起模块，用于响应于服务需求方的账户注册操作，向社保服务端发起账户注册请求；
272.第二接收模块，用于接收社保服务端响应于账户注册请求反馈的生物特征采集请求；
273.第三响应模块，用于响应于生物特征采集请求，采集服务需求方的生物特征，并反馈至社保服务端，用于供社保服务端将服务需求方的生物特征和身份信息关联存储。
274.在其中一个实施例中，如图12所示，提供了一种业务处理装置2，该装置可配置于社保服务端中，包括：业务获取模块20、业务处理模块21和结果反馈模块22，其中：
275.业务获取模块20，用于获取终端发起的社保业务处理请求，社保业务处理请求中
携带有携带社保信息和服务需求信息；
276.业务处理模块21，用于根据社保信息和服务需求信息，进行社保业务处理；
277.结果反馈模块22，用于向终端反馈社保业务处理结果。
278.在其中一个实施例中，社保信息包括所述服务需求方输入的可用激励元素；业务处理模块21具体可以包括：
279.验证单元，用于对可用激励元素的有效性进行验证；
280.第一处理单元，用于在有效性验证通过的情况下，根据服务需求信息以及可用激励元素，进行社保业务处理。
281.在其中一个实施例中，第一验证单元可以包括：
282.密钥生成子单元，用于生成社保业务处理请求的密钥；
283.第一交互子单元，用于采用哈希算法和密钥，对可用激励元素进行处理，得到第一加密数据，并向可信第三方发送第一加密数据；
284.第二交互子单元，用于通过可信第三方向社保卡中心发起包括密钥的元素联合学习任务，以使社保卡中心基于密钥、哈希算法和扰动参数，对本地激励元素数据进行处理，得到第二加密数据，且将第二加密数据发送至可信第三方，以使可信第三方对第一加密数据和第二加密数据进行求交运算，并向社保服务端反馈求交结果；
285.结果处理子单元，用于获取求交结果，并将求交结果作为对可用激励元素有效性的验证结果。
286.在其中一个实施例中，第二交互子单元具体用于：
287.通过可信第三方获取社保卡中心发送的第二加密数据，并采用密钥对第二加密数据进行加密，得到第三加密数据；
288.通过可信第三方向社保卡中心发送第三加密数据，以使社保卡中心对所述第三加密数据进行哈希和去扰动处理，得到第四加密数据，并将第四加密数据发送至可信第三方，由可信第三方对第一加密数据和第四加密数据进行求交运算，并向社保服务端反馈求交结果。
289.在其中一个实施例中，业务处理模块21还具体可以包括：
290.第一发送单元，用于向终端发送所述服务需求方的社保卡图像获取请求；其中，社保卡图像获取请求用于请求终端采集并反馈服务需求方的社保卡图像；
291.图像获取单元，用于获取终端反馈的服务需求方的社保卡图像；
292.第二处理单元，用于基于社保卡图像、社保信息和服务需求信息，进行社保业务处理。
293.在其中一个实施例中，若社保信息中包括服务需求方输入的身份信息，则上述业务处理装置还可以包括：
294.第二发送单元，用于根据基于社保卡图像、社保信息和服务需求信息，进行社保业务处理之前，向终端发送服务需求方的生物特征获取请求；其中，生物特征获取请求用于请求终端采集并反馈服务需求方的生物特性；
295.特性处理单元，用于获取终端反馈的服务需求方的生物特征，并根据生物特征，对身份信息进行身份验证。
296.在其中一个实施例中，若生物特征包括服务需求方的面部图像，则上述业务处理
装置还可以包括：
297.比对单元，用于基于社保卡图像、社保信息和服务需求信息，进行社保业务处理之前，将面部图像与从社保卡图像中提取的用户图像进行比对；
298.第二处理单元，还用于在确定面部图像与所述用户图像一致的情况下，从社保卡图像中提取社保文本信息；根据社保文本信息、社保信息和服务需求信息，进行社保业务处理。
299.在其中一个实施例中，上述业务处理装置还包括：
300.第三发送单元，用于向终端发送社保文本信息和服务需求信息，以供服务需求方进行信息确认。
301.在其中一个实施例中，上述业务处理装置还包括：
302.注册响应模块，用于响应于终端发送的账户注册请求，向终端反馈生物特征采集请求；其中，生物特征采集请求用于请求终端采集并反馈服务需求方的生物特征；
303.第一存储模块，用于将服务需求方的生物特征和身份信息关联存储。
304.在其中一个实施例中，业务处理模块21具体可以用于：
305.根据服务需求信息，进行社保业务服务处理；
306.向终端发送确认请求，确认请求用于请求服务需求方对社保业务服务事项和社保业务结算事项的正确性进行确认，并在确认正确的情况下，反馈确认文件；
307.获取终端反馈的确认文件，并根据可用激励元素，进行社保业务结算处理。
308.在其中一个实施例中，上述业务处理装置还包括：
309.第二存储模块，用于将社保业务处理请求、确认文件和结算结果关联存储于区块链中。
310.上述业务处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
311.在一个实施例中，提供了一种计算机设备，该计算机设备可以是承载社保服务端的业务处理功能的服务器，其内部结构图可以如图13所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储服务需求方的身份信息和面部图像的数据，以及社保业务处理请求、确认文件和结算结果的数据等。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种业务处理方法。
312.在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图14所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过
wifi、移动蜂窝网络、nfc(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种业务处理方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。
313.本领域技术人员可以理解，图13和图14中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
314.在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。
315.在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述各方法实施例中的步骤。
316.在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。
317.需要说明的是，本技术所涉及的用户信息(包括但不限于服务需求方的身份信息、生物特征(比如面部特征)和可用激励元素等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。
318.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(read-only memory，rom)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(reram)、磁变存储器(magnetoresistive random access memory，mram)、铁电存储器(ferroelectric random access memory，fram)、相变存储器(phase change memory，pcm)、石墨烯存储器等。易失性存储器可包括随机存取存储器(random access memory，ram)或外部高速缓冲存储器等。作为说明而非局限，ram可以是多种形式，比如静态随机存取存储器(static random access memory，sram)或动态随机存取存储器(dynamic random access memory，dram)等。本技术所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本技术所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。
319.以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
320.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本技术专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术的保护范围应以所附权利要求为准。