交互、获取用户信息的方法及其装置
技术领域
本申请涉及信息交互技术领域,尤其涉及一种交互、获取用户信息的方法及其装置。
背景技术
在相关技术中,客服人员通过web方式向用户提供服务。在服务过程中,若某项业务的完成需要用户信息,则客服人员采用直接向用户询问的方式来获得。
然而,用户信息往往涉及到用户的个人隐私,比如身份证号码、家庭住址、银行卡号码等。由于客服人员能够直接接触这些信息,存在信息外泄的可能性,甚至可能通过这些用户信息来恶意篡改用户的其他信息,使得存在很大的安全隐患。
发明内容
有鉴于此,本申请提供一种交互、获取用户信息的方法及其装置,通过推屏的方式,由网络信息交互平台来获取具体的用户业务信息,避免客服人员接触用户业务信息,有助于提升用户业务信息的安全性。
为实现上述目的,本申请提供技术方案如下:
一种交互用户信息的方法,用于网络信息交互平台,包括:根据接收到的客服端针对特定业务发起的推屏请求,向用户端请求对应于所述特定业务的用户业务信息;接收并存储所述用户端返回的所述用户业务信息;当所述客服端触发所述特定业务时,调用存储的所述用户业务信息完成所述特定业务的执行流程。
相应地,本申请还提出了一种交互用户信息的装置,用于网络信息交互平台,包括:信息请求单元,用于根据接收到的客服端针对特定业务发起的推屏请求,向用户端请求对应于所述特定业务的用户业务信息;消息收发单元,用于接收所述用户端返回的所述用户业务信息;信息存储单元,用于存储所述用户业务信息;业务执行单元,用于在所述客服端触发所述特定业务的情况下,调用缓存的所述业务信息完成所述特定业务的执行流程。
根据本申请的另一方面,还提出了一种获取用户信息的方法,用于网络信息交互的客服端,包括:生成针对特定业务的推屏请求,并发送至网络信息交互平台,以请求对应于所述特定业务的用户业务信息;接收所述网络信息交互平台返回的确认消息和/或待展现内容;其中,所述确认消息用于确认所述网络信息交互平台已从所述用户端获取所述用户业务信息;以及,所述待展现内容为已被所述网络信息交互平台屏蔽了预设敏感项目的用户业务信息。
相应地,本申请还提出了一种获取用户信息的装置,用于网络信息交互的客服端,包括:请求生成单元,用于生成针对特定业务的推屏请求,以请求对应于所述特定业务的用户业务信息;消息收发单元,用于将所述推屏请求发送至网络信息交互平台,并接收所述网络信息交互平台返回的确认消息和/或待展现内容;其中,所述确认消息用于确认所述网络信息交互平台已从所述用户端获取所述用户业务信息;以及,所述待展现内容为已被所述网络信息交互平台屏蔽了预设敏感项目的用户业务信息。
由以上技术方案可见,本申请通过推屏的方式,由网络信息交互平台来获取具体的用户业务信息,避免客服人员接触用户业务信息,有助于提升用户业务信息的安全性。
附图说明
图1示出了根据本申请的一个实施例的交互用户信息的方法的流程示意图;
图2A-2B示出了根据本申请的一个实施例的用户端的界面示意图;
图3A示出了根据本申请的一个实施例的向用户端发送推屏消息的示意图;
图3B示出了根据本申请的另一个实施例的向用户端发送推屏消息的示意图;
图4示出了根据本申请的一个实施例的对获取的用户业务信息进行处理的流程示意图;
图5示出了根据本申请的一个实施例的交互用户信息的装置的结构示意图;
图6示出了根据本申请的一个实施例的获取用户信息的装置的结构示意图;
图7示出了根据本申请的一个实施例的在客服端、网络信息交互平台和用户端之间交互业务信息的流程示意图。
具体实施方式
本申请通过推屏的方式,由网络信息交互平台来获取具体的用户业务信息,避免客服人员接触用户业务信息,有助于提升用户业务信息的安全性。
为对本申请进行进一步说明,提供下列实施例:
图1示出了根据本申请的一个实施例的交互用户信息的方法的流程示意图。
如图1所示,根据本申请的一个实施例的交互用户信息的方法,用于网络信息交互平台,包括:
步骤102,根据接收到的客服端针对特定业务发起的推屏请求,向用户端请求对应于所述特定业务的用户业务信息。
步骤104,接收并存储所述用户端返回的所述用户业务信息。
步骤106,当所述客服端触发所述特定业务时,调用存储的所述业务信息完成所述特定业务的执行流程。
在该技术方案中,通过网络信息交互平台来获取、存储和调用由用户填写的用户业务信息,在客服端与用户业务信息之间实现隔离,从而确保了用户业务信息、尤其是可能存在的隐私信息的安全性,避免客服端人员可能造成的用户业务信息泄露或滥用。
其中,对于需要执行的不同业务,所需填写的用户业务信息也可能不同,比如用户姓名、年龄、身份证号码、银行卡号等。因此,针对每项业务所需的用户业务信息,需要预先将其配置于相应的推屏消息中,并预存储每项业务与相应的推屏消息之间的关联关系,从而针对客服端发起的推屏请求,就能够根据该推屏请求所针对的特定业务,确定相应的推屏消息,以确保用户端的准确填写。
具体地,步骤102中对用户端的用户业务信息进行请求时,可以通过多种方式来实现。下面将结合图2A-2B和图3A-3B,分别从请求的形式方面和信息交互的方式方面,对其中的几种较为具体的优选实施例进行详细描述。
1、请求的形式
以用户端A通过图2A所示的web页面与客服端B进行信息交互的过程为例进行说明。当用户端A和客服端B之间需要生成该web页面时,由网络信息交互平台将相应的界面生成数据发送至用户端A,该界面生成数据被用户端A加载时,生成用户端A用于与客服端B进行信息交互的界面(即上述的web页面)。
在该web页面上,历史消息记录的左侧为来自客服端B(即图中所示的客服12345)的通讯消息,右侧为来自用户端A的通讯消息。
假定用户端A的用户提出了“更改支付密码”的需求,则客服端B相应地发起了“更改支付密码”的业务,并且需要对用户的一些身份信息进行验证,以确保业务的顺利完成,也保证用户信息和经济(比如由于客服人员获取“支付密码”而造成经济损失)的安全性。
基于本申请的技术方案,由于客服端B存在人为因素的不确定性,因而需要通过网络信息交互平台来避免客服端B与用户端A输入的用户业务信息的直接接触,尤其是其中包含的敏感信息。因此,在请求和获取用户的身份信息时,具体可以通过下述实施例来实现。
根据本申请的一种实施例,可以生成专用的推屏信息填写界面,其独立于用户端A与客服端B进行信息交互的web页面。具体地,在界面生成数据中包含有预设脚本,该预设脚本被所述用户端A加载时,就生成图2B所示的用于填写用户业务信息的推屏信息填写界面。其中,为了表示该web页面与客服端B之间的关联,还可以在web页面的上方标示出客服端的信息,如头像和账户(客服12345)等。
网络信息交互平台在接收到来自客服端B的推屏请求时,通过触发用户端A的预设脚本,即可生成如图2B所示的推屏信息填写界面。假定以“自助机器人”来代表网络信息交互平台,可以在原有的web页面上方重叠显示推屏信息填写界面,以表现出两者间的关联关系。其中,通过在该推屏信息填写界面上显示出“自助机器人”及其头像,使得用户端A直观地了解到信息交互主体的变化;并且,还可以通过如“为确保信息安全,以下内容的交互对象为自助机器人。客服人员不会接触敏感信息,请您按照要求放心填写~”,从而直接告知用户端A当前情况,有助于用户获得更好的使用体验。在该推屏信息填写界面上,显示出所有需要用户填写的项目,并通过表单的方式,生成每个项目对应的输入框,以供用户输入具体的用户业务信息。
其中,预设脚本可以为js(Javascript)脚本;但本领域技术人员应该理解的是,此处并不限定脚本的具体编译方式,其他格式的预设脚本显然也能够用于本申请的技术方案中。
当然,自助机器人可以采用图2B所示的方式,即将所有的待填写项目同时显示于推屏信息填写界面;或者,也可以每次仅请求一项信息,并在用户端A返回相应的用户业务信息之后,继续请求下一项信息,直至获取所需的全部用户业务信息。
此外,由于用户端A与客服端B、网络信息交互平台分别进行交互时,采用了不同界面,因而网络信息交互平台在接收到来自用户端A的数据时,可以根据该数据的界面来源确定其传输目标。具体地,比如该数据来自web页面时,确定其传输目标为客服端B,因而将其转发至客服端B,实现用户端A与客服端B之间的正常信息交互;而当该数据来自推屏信息填写界面时,确定其传输目标为网络信息交互平台自身,因而确定该数据即为用户端返回的用户业务信息。
2、信息交互的方式
实施例一
作为一种较为具体的实施例,网络信息交互平台可以根据预配置的关联关系,直接将相应的推屏消息告知用户端。具体地,图3A示出了根据本申请的一个实施例的向用户端发送推屏消息的示意图。
如图3A所示,根据本申请的一个实施例的向用户端发送推屏消息的过程包括:
步骤302,网络信息交互平台接收到来自客服端的推屏请求,该推屏请求具体针对特定业务而发起。
步骤304,网络信息交互平台根据该特定业务以及预配置的关联关系,确定相应的推屏消息,并将该推屏消息直接发送至用户端。此时,该推屏消息需要包含两方面的内容:一、告知用户端发起对用户业务信息的获取流程;二、告知用户端需要填写的具体内容,以便执行相应的页面渲染等操作。
在该技术方案中,由网络信息交互平台执行推屏消息的匹配查找操作,而用户端仅需接收具体的推屏消息即可,有助于降低用户端的设备性能需求。
实施例二
在如图3A所示的步骤304中,除了直接将推屏消息发送至用户端,还可以采用下述技术方案(图中未示出):
网络信息交互平台根据该特定业务以及预配置的关联关系,确定相应的推屏消息,并将该推屏消息对应的唯一标识发送至所述用户端。
其中,用户端应当预先存储有对应于每项业务的推屏消息,使得用户端能够根据该唯一标识确定相应的推屏消息。
相比于实施例一,该技术方案中由于仅需要发送“唯一标识”,其相比于直接发送“推屏消息”显然需要传输的数据量更小,从而一方面有助于提升传输效率,缩短整个推屏过程的处理时间,另一方面则当用户端处于移动数据通信的环境下时,有助于减小数据传输所消耗的流量,节省移动数据传输的费用。
实施例三
基于上述针对实施例二的描述,即移动数据通信的环境下,用户端可能对数据传输流量更加敏感,因而在本申请的技术方案中,为了尽可能地减小数据传输量,可以优选采用实施例二的技术方案。
然而,用户端很可能并没有预存储每项业务对应的推屏消息,或者预存储的推屏消息不全,无法与当前接收到的唯一标识进行匹配。在上述情况下,基于良好的用户使用体验,本申请进一步提出了下述技术方案,具体地,图3B示出了根据本申请的另一个实施例的向用户端发送推屏消息的示意图。
如图3B所示,根据本申请的另一个实施例的向用户端发送推屏消息的过程包括:
步骤302’,网络信息交互平台接收到来自客服端的推屏请求,该推屏请求具体针对特定业务而发起。
步骤304’,网络信息交互平台根据该特定业务以及预配置的关联关系,确定相应的推屏消息,并将该推屏消息对应的唯一标识发送至所述用户端。
步骤306’,由于用户端无法直接确定该唯一标识对应的推屏消息,因而网络信息交互平台接收到所述用户端返回的包含所述唯一标识的加载请求。
步骤308’,网络信息交互平台将对应于该唯一标识的推屏消息反馈至用户端,以便用户端顺利执行推屏处理流程。
在该技术方案中,针对用户端内没有预存储推屏消息或未成功匹配的情况,通过添加一次交互过程,使得网络信息交互平台能够根据用户端的请求,准确推送具体的推屏消息,以便用户端顺利反馈相应的用户业务信息。可见,在实施例二中尽可能降低交互数据流量的基础上,进一步确保了用户信息交互过程的完整性。
此外,在图1所示的处理流程中,网络信息交互平台还可以对获取的用户业务信息执行进一步的处理,具体地,图4示出了根据本申请的一个实施例的对获取的用户业务信息进行处理的流程示意图。
如图4所示,可以对获取的用户业务信息执行下述处理中的一项或多项:
1、信息校验
步骤402,网络信息交互平台接收用户端返回的用户业务信息。
步骤404,校验所述用户端返回的用户业务信息。若通过校验,则进入步骤406,否则进入步骤408。
通过对用户业务信息的校验,及时查找出用户填写错误,避免日后使用时无法与用户真实信息相匹配的情况;或者,通过辨识出用户提供的虚假信息,比如谎报年龄,避免向用户提供不适龄的业务。
具体地,比如可以对用户业务信息中的每项内容进行格式校验、内容有效性校验等。例如对于格式校验,包括如银行卡号、身份证号码的位数等;而对于有效性校验,包括如身份证号码是否真实有效,比如与用户姓名、籍贯是否匹配等。其中,可以基于本地数据包进行校验,也可以联网校验来提高校验的准确度。
步骤406,存储该用户业务信息。
具体地,可以将该用户业务信息以“键值对(key-value)”的方式存放在分布式缓存中,则外界可以通过提供具体的“键(key)”来调用相应“值(value)”的用户业务信息。
步骤408,将未通过校验的结果告知用户端。
具体地,可以仅向用户端返回“错误”消息;也可以将具体存在问题的一项或多项内容告知用户端,以便于用户端实现有针对性的内容修改和调整。
2、内容屏蔽
由于网络信息交互平台对于用户业务信息的获取,是由客服端发起的,因而网络信息交互平台在获取用户端提供的用户业务信息之后,应当向客服端反馈该处理状态。
具体地,比如网络信息交互平台可以仅返回确认消息,确认已从所述用户端获取对应于推屏请求的用户业务信息,以便客服端执行后续流程;或者,基于更好的使用体验,网络信息交互平台也可以直接返回用户业务信息,但由于用户业务信息中可能包含的敏感信息,因而需要执行下述处理:
步骤410,屏蔽所述用户业务信息中的预设敏感项目,并向所述客服端展现屏蔽后的用户业务信息。
具体地,网络信息交互平台在预配置每项业务与推屏消息之间的关联关系时,还可以对推屏消息中包含的“敏感项目”和“非敏感项目”进行区分,则在步骤410时,即可对用户业务信息中对应于“敏感项目”的内容进行屏蔽,并将剩余的非敏感的内容展现给客服端。
针对上述的交互用户信息的方法,图5相应地示出了根据本申请的一个实施例的交互用户信息的装置的结构示意图。
如图5所示,根据本申请的一个实施例的交互用户信息的装置,用于网络信息交互平台,包括:
信息请求单元502,用于根据接收到的客服端针对特定业务发起的推屏请求,向用户端请求对应于所述特定业务的用户业务信息。
消息收发单元504,用于接收所述用户端返回的所述用户业务信息。
信息存储单元506,用于存储所述用户业务信息。
业务执行单元508,用于在所述客服端触发所述特定业务的情况下,调用存储的所述业务信息完成所述特定业务的执行流程。
在该技术方案中,通过网络信息交互平台来获取、存储和调用由用户填写的用户业务信息,在客服端与用户业务信息之间实现隔离,从而确保了用户业务信息、尤其是可能存在的隐私信息的安全性,避免客服端人员可能造成的用户业务信息泄露或滥用。
优选地,还包括:预配置单元510,用于预先配置每项业务与相应的推屏消息之间的关联关系;以及,所述信息请求单元502在触发推屏处理流程时,可以通过下述技术手段来实现:
实施方式一
根据所述关联关系确定所述特定业务对应的推屏消息,并通过所述消息收发单元504发送至所述用户端。
在该技术方案中,由网络信息交互平台执行推屏消息的匹配查找操作,而用户端仅需接收具体的推屏消息即可,有助于降低用户端的设备性能需求。
实施方式二
根据所述关联关系确定所述特定业务对应的推屏消息,通过所述消息收发单元504将该推屏消息对应的唯一标识发送至所述用户端。
其中,用户端应当预先存储有对应于每项业务的推屏消息,使得用户端能够根据该唯一标识确定相应的推屏消息。
在该技术方案中,由于仅需要发送“唯一标识”,其相比于直接发送“推屏消息”显然需要传输的数据量更小,从而一方面有助于提升传输效率,缩短整个推屏过程的处理时间,另一方面则当用户端处于移动数据通信的环境下时,有助于减小数据传输所消耗的流量,节省移动数据传输的费用。
实施方式三
当然,若用户端并未预存储每项业务对应的推屏消息,则所述消息收发单元504还用于:
将所述唯一标识发送至所述用户端之后,若接收到所述用户端返回的包含所述唯一标识的加载请求,则将相应的推屏消息发送至所述用户端。
在该技术方案中,针对用户端内没有预存储推屏消息或未成功匹配的情况,通过添加一次交互过程,使得网络信息交互平台能够根据用户端的请求,准确推送具体的推屏消息,以便用户端顺利反馈相应的用户业务信息。可见,在实施例二中尽可能降低交互数据流量的基础上,进一步确保了用户信息交互过程的完整性。
优选地,所述消息收发单元504还用于:将界面生成数据发送至所述用户端,该界面生成数据被所述用户端加载时,生成所述用户端用于与所述客服端进行信息交互的界面;以及,所述装置还包括:脚本触发单元512,用于触发所述界面生成数据中包含的预设脚本,该预设脚本被所述用户端加载时,生成用于填写所述用户业务信息的推屏信息填写界面。
在该技术方案中,界面生成数据可以通过用户端的浏览器进行加载后,生成相应的web页面,以用于用户端与客服端之间的正常信息交互;而通过对预设脚本的加载,则能够生成专用于请求用户业务信息的推屏信息填写界面,使得web页面与推屏信息填写界面之间相互区分和独立,避免客服端直接接触用户端返回的用户业务信息,提高信息交互的安全性。
其中,预设脚本可以为js(Javascript)脚本;但本领域技术人员应该理解的是,此处并不限定脚本的具体编译方式,其他格式的预设脚本显然也能够用于本申请的技术方案中。
优选地,所述装置还可以包括:数据识别单元514,用于识别来自所述用户端的数据的界面来源;数据处理单元516,用于在所述数据来自所述用户端用于与所述客服端进行信息交互的界面的情况下,将所述数据转发至所述客服端;以及,在所述数据来自所述推屏信息填写界面的情况下,确定所述数据为所述用户业务信息。
在该技术方案中,由于存在不同的交互界面,因而通过对数据的界面来源进行识别,即可准确区分来自用户端的数据传输目标,并且确定数据的具体类型,避免将用户业务信息直接发送至客服端而导致数据安全隐患。
优选地,所述装置还可以包括:内容校验单元518,用于校验所述用户端返回的用户业务信息;其中,所述信息存储单元506还用于:在所述用户业务信息通过校验的情况下,缓存所述用户业务信息;以及,所述消息收发单元504还用于:在所述用户业务信息未通过校验的情况下,将校验结果告知所述用户端。
通过对用户业务信息的校验,及时查找出用户填写错误,避免日后使用时无法与用户真实信息相匹配的情况;或者,通过辨识出用户提供的虚假信息,比如谎报年龄,避免向用户提供不适龄的业务。
优选地,在网络信息交互平台成功获取来自用户端的用户业务信息之后,可以向客服端进行反馈,具体可以通过下述技术手段进行反馈:
实施方式一
所述消息收发单元504还用于:在所述信息存储单元506缓存所述用户业务信息之后,向所述客服端发送确认消息,确认已从所述用户端获取对应于所述推屏请求的用户业务信息。
在该技术方案中,由于网络信息交互平台对于用户业务信息的获取,是由客服端发起的,因而网络信息交互平台在获取用户端提供的用户业务信息之后,应当向客服端反馈该处理状态,以便客服人员通过客服端执行后续操作。
实施方式二
所述装置还包括:内容屏蔽单元520,用于对所述用户业务信息中的预设敏感项目进行屏蔽,并向所述客服端展现屏蔽后的用户业务信息。
在该技术方案中,通过反馈屏蔽后的用户业务信息,即直接对应于“推屏请求”的信息,使得客服人员在视觉感受和应用过程中得到更好的体验。
其中,网络信息交互平台可以通过在预配置每项业务与推屏消息之间的关联关系时,对推屏消息中包含的“敏感项目”和“非敏感项目”进行区分,从而在需要时,就能够对用户业务信息中对应于“敏感项目”的内容进行屏蔽,并将剩余的非敏感的内容展现给客服端。
实施方式三
此外,还可以在发送实施方式一中采用的确认消息的同时,将实施方式二中采用的屏蔽后的用户业务信息也发送至客服端。具体地,比如在确认消息中的数据部分,添加屏蔽后的用户业务信息;当然,本领域技术人员应该理解的是,此处仅用于举例说明,比如显然也可以将确认消息和屏蔽后的用户业务信息分别进行独立传输。
优选地,所述信息存储单元506具体用于:将所述用户业务信息存放在分布式缓存中。当然,本领域技术人员应该理解的是,显然也可以通过其他方式进行存储,比如任一连接至网络信息交互平台的存储设备。
对应于图5所示的装置,图6还提供了对应于客服端的功能装置,下面分别进行详细介绍。
图6示出了根据本申请的一个实施例的获取用户信息的装置的结构示意图。
如图6所示,根据本申请的一个实施例的获取用户信息的装置,用于网络信息交互的客服端,包括:
请求生成单元602,用于生成针对特定业务的推屏请求,以请求对应于所述特定业务的用户业务信息。
消息收发单元604,用于将所述推屏请求发送至网络信息交互平台,并接收所述网络信息交互平台返回的确认消息和/或待展现内容;
其中,所述确认消息用于确认所述网络信息交互平台已从所述用户端获取所述用户业务信息;以及,所述待展现内容为已被所述网络信息交互平台屏蔽了预设敏感项目的用户业务信息。
在该技术方案中,通过网络信息交互平台来触发用户端,并直接获得用户端反馈的用户业务信息,而客服端不会接触用户业务信息(接收到网络信息交互平台返回的确认消息)或不会直接接触用户业务信息(接收到网络信息交互平台返回的待展现内容),有助于隔离客服端与用户业务信息。其中,当客服端接收到待展现内容时,该待展现内容是经过网络信息交互平台的屏蔽处理的,其中并未包含可能存在的敏感内容(如用户的隐私信息),从而有助于提升用户业务信息的安全性。
图7示出了根据本申请的一个实施例的在客服端、网络信息交互平台和用户端之间交互业务信息的流程示意图。
如图7所示,根据本申请的一个实施例的在客服端、网络信息交互平台和用户端之间交互业务信息的流程包括:
步骤702,客服端为用户端用户办理特定业务时,则可能需要部分用户业务信息(比如用户姓名、身份证号、银行卡号等),向网络信息交互平台发起推屏请求。
步骤704,网络信息交互平台预存储有每项业务与相应的推屏请求之间的关联关系。网络信息交互平台根据预存储的关联关系,确定对应于当前的特定业务的推屏请求,并将其对应的唯一标识发送给用户端。
当然,网络信息交互平台可以直接将对应于特定业务的推屏请求发送至用户端,以降低对用户端的用户设备的性能需求;但通过发送唯一标识,则传输的数据量相对更小,尤其是用户端的用户设备使用移动数据网络进行数据传输时,显然有助于减少相应的数据传输的流量及相应的费用。
步骤706,用户端接收到唯一标识后,执行相应的推屏处理流程。
在一种情况下,如果用户端预存储了每项业务与相应的推屏消息之间的关联关系,则可以根据唯一标识确定相应的推屏消息;而在另一种情况下,如果用户端未存储上述的关联关系,或基于已存储的关联关系并没有查找到相应的推屏消息,则生成包含接收到的唯一标识的加载请求,并返回网络信息交互平台。
步骤708,如果网络信息交互平台接收到用户端返回的加载请求,则将对应于唯一标识的推屏消息发送至用户端。
步骤710,用户端根据接收或查找到的推屏消息,生成相应的信息填写界面。
具体地,比如用户端和客服端通过web页面进行信息交互;而当网络信息交互平台向用户端请求用户业务信息时,则可以通过独立的信息填写界面,以避免客服端直接接触用户业务信息。
其中,网络信息交互平台可以通过向用户端发送相应的界面生成数据,以由用户端加载而生成上述的web页面;而在该界面生成数据中携带有预设脚本,且网络信息交互平台通过触发该预设脚本,从而根据推屏消息中包含的待填写项目,生成相应的信息填写界面,并由用户针对其中的待填写项目,填写相应的用户业务信息。
步骤712,优选地,用户端可以对用户填写的内容进行校验。具体地,比如校验填写内容的格式是否符合规范(如银行卡号码的位数是否不足或过多),或者检验填写内容的有效性(如身份证号码的真实性)等。
如果内容校验通过,则用户端据此生成相应的用户业务信息;如果内容校验未通过,则用户端可以告知用户,以提示用户修改或重新输入。
步骤714,用户端提交填写内容,即将所有生成的用户业务信息上传至网络信息交互平台。
步骤716,优选地,网络信息交互平台可以对用户端上传的用户业务信息进行校验。具体地,类似于用户端执行的校验操作,可以对用户业务信息执行格式校验、内容有效性校验等。
为了提高效率,网络信息交互平台可以在本地建立并存储校验数据包,以用于对用户业务信息进行校验,并且可以定期触发或业务触发该校验数据包的内容更新,有助于对校验准确性的保障。或者,为了提高准确性,网络信息交互平台也可以对用户业务信息进行在线校验,比如通过银行的数据库来对银行卡号、用户姓名等用户业务信息进行校验。
步骤718,网络信息交互平台对接收到的用户业务信息进行存储。具体地,比如可以将用户业务信息存放在分布式缓存中。当然,其他存储介质显然也可以用户实现对用户业务信息的存储。
步骤720,优选地,网络信息交互平台可以对接收和存储的用户业务信息进行屏蔽处理,即屏蔽其中的敏感项目,如用户隐私信息等。具体地,可以预先对各项用户业务信息进行分类,比如分为敏感项目和非敏感项目,从而通过对敏感项目的屏蔽,确保用户业务信息的安全性。
步骤722,网络信息交互平台可以仅向客服端反馈确认消息,告知其自身已经获取了对应于步骤702上的推屏请求的用户业务信息。
而为了提升客服端的使用体验,可以将步骤720中执行了内容屏蔽后的用户业务信息作为待展现内容,并发送至客服端。当然,也可以既发送确认消息,又发送待展现内容。
步骤724,客服端在确定网络信息交互平台已经获取了所需的用户业务信息时,可以触发相应的特征业务的处理流程。
步骤726,在确定特定业务的处理流程被触发后,网络信息交互平台调用存储的相应的用户业务信息,用于执行对该特定业务的处理流程。
步骤728,在特定业务处理完成后,网络信息交互平台将相应的业务执行结果反馈至客服端,从而无需客服端关心该特定业务的执行,也避免了客服端对内容敏感的用户业务信息的接触,保证了较高的信息安全性。
因此,本申请通过推屏的方式,由网络信息交互平台来获取具体的用户业务信息,避免客服人员接触用户业务信息,有助于提升用户业务信息的安全性。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。