掌桥专利:专业的专利平台
掌桥专利
首页

发票信息的处理方法、装置、设备及存储介质

文献发布时间:2024-04-18 19:52:40


发票信息的处理方法、装置、设备及存储介质

技术领域

本公开涉及数据处理技术领域,尤其涉及智能客服、办公自动化、智能税务技术领域。

背景技术

开具发票需要填写、选择和确认的信息繁多,流程复杂,导致开票过程中常常需要销售运营人员与用户沟通,人工成本高。

发明内容

本公开提供了一种发票信息的处理方法、装置、设备以及存储介质。

根据本公开的一方面,提供了一种发票信息的处理方法,包括:

响应于用户端的开票请求,获取与用户端对应的目标账户的账务信息;

根据账务信息,向用户端发送第一对话消息;其中,第一对话消息至少包括目标账户的可开票余额;

根据用户端反馈的第二对话消息的语义信息,确定第一开票金额;

在第一开票金额不大于可开票余额的情况下,根据第一开票金额、目标账户的发票基本信息以及预设发票模板,生成待开发票的预览图并将包含预览图的第三对话消息发送至用户端;以及

根据用户端反馈的第四对话消息的语义信息,得到经确认的开票信息。

根据本公开的另一方面,提供了发票信息的处理装置,包括:

信息获取模块,用于响应于用户端的开票请求,获取与用户端对应的目标账户的账务信息;

第一对话模块,用于根据账务信息,向用户端发送第一对话消息;其中,第一对话消息至少包括目标账户的可开票余额;

第二对话模块,用于根据用户端反馈的第二对话消息的语义信息,确定第一开票金额;

第三对话模块,用于在第一开票金额不大于可开票余额的情况下,根据第一开票金额、目标账户的发票基本信息以及预设发票模板,生成待开发票的预览图并将包含预览图的第三对话消息发送至用户端;

第四对话模块,用于根据用户端反馈的第四对话消息的语义信息,得到经确认的开票信息。

根据本公开的另一方面,提供了一种电子设备,包括:

至少一个处理器;以及

与该至少一个处理器通信连接的存储器;其中,

该存储器存储有可被该至少一个处理器执行的指令,该指令被该至少一个处理器执行,以使该至少一个处理器能够执行本公开实施例中任一的方法。

根据本公开的另一方面,提供了一种存储有计算机指令的非瞬时计算机可读存储介质,其中,该计算机指令用于使该计算机执行根据本公开实施例中任一的方法。

根据本公开的另一方面,提供了一种计算机程序产品,包括计算机程序,该计算机程序在被处理器执行时实现根据本公开实施例中任一的方法。

本公开通过引入智能客服,减少了开票流程的耗时和繁琐程度,提升了开票的自助化、自动化程度。

应当理解,本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征,也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案,不构成对本公开的限定。其中:

图1是根据本公开一实施例的发票信息的处理方法的流程示意图;

图2是根据本公开另一实施例的智能客服开票申请流程图;

图3是根据本公开一实施例的发票信息的处理装置的结构示意图;

图4是用来实现本公开实施例的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明,其中包括本公开实施例的各种细节以助于理解,应当将它们认为仅仅是示范性的。因此,本领域普通技术人员应当认识到,可以对这里描述的实施例做出各种改变和修改,而不会背离本公开的范围。同样,为了清楚和简明,以下的描述中省略了对公知功能和结构的描述。

图1是本公开一实施例提供的发票信息的处理方法。如图1所示,该方法至少包括以下步骤:

S101、响应于用户端的开票请求,获取与用户端对应的目标账户的账务信息。

本公开实施例中,开票请求可以是用户端在与智能客服的对话中,发送了具有表达开票意图的对话内容而触发的。也可以是在用户端通过点击预设开票按钮触发的。点击预设开票按钮后,用户端可以跳转至含有与智能客服的对话框的页面。

目标账户是指在用户端上登录账户,也可以是与该用户端或该登录账户具有绑定关系的其它账户。例如,当前登录的账户的员工个人账户,该员工个人账户与企业账户具有绑定关系,则可以获取企业账户的账务信息。绑定关系可以通过被绑定账户的认证得到。

账务信息可以包括商品信息、客户信息、消费信息和开票信息。商品信息指:已购买的商品名称、税率、规格、价格等数据。客户信息指:客户名称、实名认证、纳税人识别号、地址等信息。消费信息指:预付费订单数据,后付费账单数据。开票信息指:已开出的发票数据,可开票的消费数据。

S102、根据账务信息,向用户端发送第一对话消息。其中,第一对话消息至少包括目标账户的可开票余额。

第一对话消息可以理解为用于告知可开票余额,并询问需要开票的金额。在一种示例中,第一对话消息可以是:“先生/女士,当前您可开票余额为XX元,您需要开多少钱的发票?”在另一种示例中,第一对话消息可以使用自然语言生成模型根据可开票余额生成得到,具体内容在此不作限定。

S103、根据用户端反馈的第二对话消息的语义信息,确定第一开票金额。

用户端可以在与智能客服的对话框中发送第二对话消息,从而表达其需要开票的金额。第二对话消息可以包含文本内容,也可以包含语音内容。获取到第二对话消息后,可以使用本领域技术人员已掌握的语义识别模型、自然语言处理模型等语义识别方法,从第二对话消息中确定第一开票金额。如果第二对话消息为语音内容,可以先对其进行语音识别,得到对应的文本信息,再确定文本信息包含的语义信息。

S104、在第一开票金额不大于可开票余额的情况下,根据第一开票金额、目标账户的发票基本信息以及预设发票模板,生成待开发票的预览图并将包含预览图的第三对话消息发送至用户端。

目标账户的发票基本信息可以包括发票抬头名称、纳税人识别号等。将第一开票金额、目标账户的发票基本信息,渲染生成在预设发票模板上,从而得到待开发票的预览图。

将包含预览图的第三对话消息发送至用户端,可以在用户端上查看待开发票的预览图。通过预览图可以最大限度的还原真实发票的内容,以便于用户尽可能地发现发票中存在的问题,例如公司名称错误、金额错误、发票类型错误等,减少发生错漏和失误的概率。

S105、根据用户端反馈的第四对话消息的语义信息,得到经确认的开票信息。

用户端在预览根据第一开票金额、目标账户的发票基本信息及预设发票模板生成的发票图片后,可以在对话框中输入第四对话消息,以表达信息无误或需要修改的意图。获取到第四对话消息后,可以使用上述语义识别模型、自然语言处理模型等识别方式,识别第四对话消息的语义信息。例如,第四对话消息可以是“没问题”、“可以”、“就这么开”等。也可以是“有问题”、“XX不对”、“XX需要改成XX”等。

经过确认后,可以将生成该预览图的开票信息,作为最终的开票信息。

根据本公开实施例的方案,通过智能客服的对话引导,从用户端获取和确认待开发票的开票信息,开票过程精简、高效,减少了人工成本。在对话中向用户端展示待开发票的预览图,便于直观地确认各项信息,有效避免了信息错误。

在一种可能的实施方式中,S102根据账务信息,向用户端发送第一对话消息,进一步包括步骤:

S1021、根据账务信息所包含的消费信息和已开票信息,确定目标账户的可开票余额。

S1022、生成包含可开票余额的第一对话消息。

S1023、将第一对话消息发送至用户端。

本公开实施例中,从消息信息中可以获得目标账户的消费金额,根据已开票信息金额可以获得目标账户的已开票金额,可开票余额为已开票金额与消费金额的差值。

根据本公开实施例的方案,明确向用户端告知可开票余额,可以引导用户申请在合理的金额范围内开票。

在一种可能的实施方式中,S1022生成包含可开票余额的第一对话消息,进一步包括步骤:

根据账务信息所包含的商品信息,确定订单展示信息。其中,订单展示信息包括商品名称、商品税率、商品规格、商品价格中的至少一种。

根据订单展示信息,渲染生成展示图表。

根据展示图表和可开票余额,生成第一对话消息。

本公开实施例中,提取目标账户的各类账务信息中与开票相关的内容,并将相关内容生成为展示图表。在一种示例中,展示图表中可以包括:商品名称、税率、可开票余额。

根据本公开实施例的方案,将部分账务信息与可开票余额图文并茂地发送给用户端,有助于用户更加明确消费金额、已开票金额与可开票余额的具体数值和关系,无需额外确认可开票余额,提高开票效率。

在一种可能的实施方式中,S104在第一开票金额不大于可开票余额的情况下,根据第一开票金额、目标账户的发票基本信息以及预设发票模板,生成待开发票的预览图并将包含预览图的第三对话消息发送至用户端,进一步包括步骤:

S1041、在第一开票金额不大于可开票余额的情况下,确定目标账户的发票基本信息。其中,发票基本信息包括发票类型、发票抬头和纳税人识别号。

S1042、根据发票类型,确定预设发票模板。

S1043、根据第一开票金额、发票抬头、纳税人识别号以及预设发票模板,生成待开发票的预览图。

S1044、将包含预览图的第三对话消息发送至用户端。

本公开实施例中,发票基本信息可以是在历史开票过程中输入保存的,也可以是根据客户信息得到的。发票类型可以包括增值税普通发票和增值税专用发票,根据发票类型,选取对应的预设发票模板。

根据第一开票金额、发票抬头、纳税人识别号以及预设发票模板,可以生成待开发票的预览图。如果发票基本信息中包含公司地址、联系方式、开户行、备注信息等其它非必要信息,也可以一并生成在预览图中。

在一种示例中,如图2所示,第三对话消息的内容可以是“客服:您可开具增值税专用发票。请确认以下信息:(待开发票的预览图,图中内容包括:发票金额:XXX元、发票信息:抬头、纳税人识别号、邮寄地址:XX市XX路XX街道、收件人姓名:XX、收件人电话:XXX)”。在第三对话消息中还可以加入引导用户确认或修改的文字信息,告知在信息有误的情况下如何修改。例如,方式一:“如果发票内容存在错误,请告知错误的项目及更正后的内容。”也可以是方式二:“如果想要更改邮寄地址及联系人方式,请至htup://…新增或更改现有地址,并将其设置为默认地址,然后重新申请。”前一种方式可以进一步通过与用户的对话,获取发票内容错误的项目及更正后的内容,后一种方式可以引导用户跳转至相关页面重新编辑输入发票信息。两种方式也可以结合使用,例如先采用前一种方式与用户端对话,尝试获取错误的项目及更正后的内容,如果超过多轮对话后仍未明确得到需要更正的发票内容,则通过后一种方式,向用户端发送链接,重新手动输入需要更正的发票信息。

根据本公开实施例的方案,根据采集到的发票相关信息生成发票的预览图,有助于用户直观地对发明内容进行确认。

在一种可能的实施方式中,S1043根据第一开票金额、发票抬头、纳税人识别号以及预设发票模板,生成待开发票的预览图,进一步包括步骤:

根据第一开票金额和账务信息所包含的商品信息,确定对应的商品税率。

根据第一开票金额、商品税率以及发票拆分规则,确定至少一张待开发票的第二开票金额。其中,至少一张待开发票的第二开票金额之和等于第一开票金额。

根据至少一张待开发票的第二开票金额、发票抬头、纳税人识别号以及预设发票模板,生成至少一张待开发票的预览图。

本公开实施例中,当商品、发票的税率不同,或是第一开票金额超过了一张发票的最大金额,或是基于其它业务要求,可以将第一开票金额拆分到多张发票中。根据不同税率、单张发票的最大金额及其它发票拆分规则,确定拆分后待开发票的张数以及每张发票对应的第二开票金额,然后分别生成每张发票的预览图。

根据本公开实施例的方案,可以将第一开票金额自动拆分成多张发票进行开票,提高了开票流程的自动化程度。

在一种可能的实施方式中,本公开实施例的发票信息的处理方法,还包括步骤:

在发票基本信息中的开票方式为纸质发票且不存在邮寄地址的情况下,生成用于采集邮寄地址的第五对话消息并发送至用户端。

本公开实施例中,如果用户默认的开票方式为纸质发票,则开票时需要发票的邮寄地址。当发票基本信息中不存在邮寄地址的情况下,可以通过智能客服询问邮寄地址,通过用户端反馈的对话消息识别得到邮寄地址。也可以向用户端发送用于采集邮寄地址的页面链接,同时,通过第五对话消息引导用户点击该链接跳转至页面中输入邮寄地址。例如,如图2所示,第五对话消息可以是“无法获取您的邮寄地址信息,请至http://......新增或更改现有地址,并将其设置为默认地址,然后重新申请。”

根据本公开实施例的方案,通过对话引导用户输入邮寄地址。

在一种可能的实施方式中,S1041在第一开票金额不大于可开票余额的情况下,确定目标账户的发票基本信息,进一步包括步骤:

在第一开票金额不大于可开票余额的情况下,从数据库查询目标账户的发票基本信息。

在发票基本信息中不包括发票类型、发票抬头或纳税人识别中任一项的情况下,生成用于采集发票基本信息的第六对话消息并发送至用户端。

根据用户端反馈的第七对话消息的语义信息,确定发票基本信息。

本公开实施例中,如果现有发票基本信息中缺少开票所需的必备信息,则可以生成用于采集发票基本信息的第六对话消息并发送至用户端。识别用户端反馈的第七对话消息所包含的文本信息,得到对应的发票基本信息。

在另一种示例中,也可以向用户端发送用于采集发票基本信息的页面链接,同时,通过第六对话消息引导用户点击该链接跳转至页面中输入发票类型、发票抬头或纳税人识别。

根据本公开实施例的方案,可以通过对话引导用户输入开票所需的各项信息,从而在对话消息中识别得到开票信息。

在一种可能的实施方式中,S105根据用户端反馈的第四对话消息的语义信息,得到经确认的开票信息,包括:

确定用户端反馈的第四对话消息的语义信息。

在第四对话消息的语义信息为确认待开发票的发票内容的情况下,将待开发票的发票内容作为经确认的开票信息。

本公开实施例中,如果用户在待开发票的预览图中没有发现任何错误或需要更改的内容,则在第四对话消息中可以发送包含确认语义的消息。在确定第四对话消息的语义信息为确认待开发票的发票内容的情况下,则可以将当前预览图所展示的待开发票的发票内容作为经确认的开票信息。

根据本公开实施例的方案,在对话式的开票过程中,通过识别对话消息中的语义信息,对开票信息进行确认。

在一种可能的实施方式中,S105根据用户端反馈的第四对话消息的语义信息,得到经确认的开票信息,包括:

确定用户端反馈的第四对话消息的语义信息。

在第四对话消息的语义信息为更新待开发票的发票内容的情况下,根据第四对话的语义信息和/或后续对话的语义信息中包含的待变更内容,重新生成待开发票的预览图。

将包含预览图的第八对话消息发送至用户端。

在用户端反馈的第九对话消息的语义信息为确认重新生成的待开发票的发票内容的情况下,将重新生成的待开发票的发票内容作为经确认的开票信息。

本公开实施例中,如果用户在待开发票的预览图中发现错误或需要更改的内容,则可以在第四对话消息中输入表达需要更改意图的文字。此时,智能客服可以从第四对话消息中识别获取待变更内容。如果用户在第四对话消息中没有完全说明需要变更的项目以及变更后的内容,则可以进一步生成引导消息,提示用户输入相应的内容。再通过后续对话的语义信息,确定待变更内容。

在一种示例中,可以在第四对话消息的语义信息为更新待开发票的发票内容的情况下,向用户端发送用于更改发票信息的页面链接,并引导用户在该页面中编辑发票信息。

在更改完成待变更内容后,可以重新生成待开发票的预览图,然后再次将新生成的预览图发送至用户端,再次进行确认。

根据本公开实施例的方案,在对话式的开票过程中,通过识别对话消息中的语义信息,对开票信息进行更改,更改后再次进行确认,从而得到正确的开票信息。

在一种可能的实施方式中,本公开实施例的发票信息的处理方法,还包括步骤:

将经确认的开票信息发送至开票平台。

根据开票平台的进度查询页面的链接,生成第十对话消息。

将第十对话消息发送至用户端。

本公开实施例中,智能客服在开票的流程中可以引导用户输入开票所需的信息,最终得到正确的开票信息。而实际开票需要将正确的开票信息发送至开票平台。开票平台用于对接业务系统交易数据与国家税务机关,完成发票开具和收款对账。

根据本公开实施例的方案,可以通过智能客服系统在线提交开票申请,从而实现自动处理并开具电子发票,简化了开票流程,提高了开票效率。

图3是本公开一实施例提供的发票信息的处理装置的结构示意图。如图3所示,该装置包括:

信息获取模块301,用于响应于用户端的开票请求,获取与用户端对应的目标账户的账务信息。

第一对话模块302,用于根据账务信息,向用户端发送第一对话消息。其中,第一对话消息至少包括目标账户的可开票余额。

第二对话模块303,用于根据用户端反馈的第二对话消息的语义信息,确定第一开票金额。

第三对话模块304,用于在第一开票金额不大于可开票余额的情况下,根据第一开票金额、目标账户的发票基本信息以及预设发票模板,生成待开发票的预览图并将包含预览图的第三对话消息发送至用户端。以及

第四对话模块305,用于根据用户端反馈的第四对话消息的语义信息,得到经确认的开票信息。

在一种可能的实施方式中,第一对话模块302包括:

余额确定子模块,用于根据账务信息所包含的消费信息和已开票信息,确定目标账户的可开票余额。

生成子模块,用于生成包含可开票余额的第一对话消息。

第一发送子模块,用于将第一对话消息发送至用户端。

在一种可能的实施方式中,生成子模块用于:

根据账务信息所包含的商品信息,确定订单展示信息。其中,订单展示信息包括商品名称、商品税率、商品规格、商品价格中的至少一种。

根据订单展示信息,渲染生成展示图表。

根据展示图表和可开票余额,生成第一对话消息。

在一种可能的实施方式中,第三对话模块304包括:

信息确定子模块,用于在第一开票金额不大于可开票余额的情况下,确定目标账户的发票基本信息。其中,发票基本信息包括发票类型、发票抬头和纳税人识别号。

模块确定子模块,用于根据发票类型,确定预设发票模板。

预览子模块,用于根据第一开票金额、发票抬头、纳税人识别号以及预设发票模板,生成待开发票的预览图。

第二发送子模块,用于将包含预览图的第三对话消息发送至用户端。

在一种可能的实施方式中,预览子模块用于:

根据第一开票金额和账务信息所包含的商品信息,确定对应的商品税率。

根据第一开票金额、商品税率以及发票拆分规则,确定至少一张待开发票的第二开票金额。其中,至少一张待开发票的第二开票金额之和等于第一开票金额。

根据至少一张待开发票的第二开票金额、发票抬头、纳税人识别号以及预设发票模板,生成至少一张待开发票的预览图。

在一种可能的实施方式中,该装置还包括:

第一采集模块,用于在发票基本信息中的开票方式为纸质发票且不存在邮寄地址的情况下,生成用于采集邮寄地址的第五对话消息并发送至用户端。

在一种可能的实施方式中,信息确定子模块用于:

在第一开票金额不大于可开票余额的情况下,从数据库查询目标账户的发票基本信息。

在发票基本信息中不包括发票类型、发票抬头或纳税人识别中任一项的情况下,生成用于采集发票基本信息的第六对话消息并发送至用户端。

根据用户端反馈的第七对话消息的语义信息,确定发票基本信息。

在一种可能的实施方式中,第四对话模块305用于:

确定用户端反馈的第四对话消息的语义信息。

在第四对话消息的语义信息为确认待开发票的发票内容的情况下,将待开发票的发票内容作为经确认的开票信息。

在一种可能的实施方式中,第四对话模块305还用于:

确定用户端反馈的第四对话消息的语义信息。

在第四对话消息的语义信息为更新待开发票的发票内容的情况下,根据第四对话的语义信息和/或后续对话的语义信息中包含的待变更内容,重新生成待开发票的预览图。

将包含预览图的第八对话消息发送至用户端。

在用户端反馈的第九对话消息的语义信息为确认重新生成的待开发票的发票内容的情况下,将重新生成的待开发票的发票内容作为经确认的开票信息。

在一种可能的实施方式中,该装置还包括第五对话模块,用于:

将经确认的开票信息发送至开票平台。

根据开票平台的进度查询页面的链接,生成第十对话消息。

将第十对话消息发送至用户端。

本公开实施例的装置的各模块、子模块的具体功能和示例的描述,可以参见上述方法实施例中对应步骤的相关描述,在此不再赘述。

本公开的技术方案中,所涉及的用户个人信息的获取,存储和应用等,均符合相关法律法规的规定,且不违背公序良俗。

根据本公开的实施例,本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图4示出了可以用来实施本公开的实施例的示例电子设备400的示意性框图。电子设备旨在表示各种形式的数字计算机,诸如,膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置,诸如,个人数字助理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例,并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图4所示,设备400包括计算单元401,其可以根据存储在只读存储器(ROM)402中的计算机程序或者从存储单元408加载到随机访问存储器(RAM)403中的计算机程序,来执行各种适当的动作和处理。在RAM 403中,还可存储设备400操作所需的各种程序和数据。计算单元401、ROM 402以及RAM 403通过总线404彼此相连。输入/输出(I/O)接口405也连接至总线404。

设备400中的多个部件连接至I/O接口405,包括:输入单元406,例如键盘、鼠标等;输出单元407,例如各种类型的显示器、扬声器等;存储单元408,例如磁盘、光盘等;以及通信单元409,例如网卡、调制解调器、无线通信收发机等。通信单元409允许设备400通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元401可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元401的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元401执行上文所描述的各个方法和处理,例如发票信息的处理方法。例如,在一些实施例中,发票信息的处理方法可被实现为计算机软件程序,其被有形地包含于机器可读介质,例如存储单元408。在一些实施例中,计算机程序的部分或者全部可以经由ROM 402和/或通信单元409而被载入和/或安装到设备400上。当计算机程序加载到RAM 403并由计算单元401执行时,可以执行上文描述的发票信息的处理方法的一个或多个步骤。备选地,在其他实施例中,计算单元401可以通过其他任何适当的方式(例如,借助于固件)而被配置为执行发票信息的处理方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括:实施在一个或者多个计算机程序中,该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释,该可编程处理器可以是专用或者通用可编程处理器,可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令,并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器,使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行,作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中,机器可读介质可以是有形的介质,其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备,或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互,可以在计算机上实施此处描述的系统和技术,该计算机具有:用于向用户显示信息的显示装置(例如,CRT(阴极射线管)或者LCD(液晶显示器)监视器);以及键盘和指向装置(例如,鼠标或者轨迹球),用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互;例如,提供给用户的反馈可以是任何形式的传感反馈(例如,视觉反馈、听觉反馈、或者触觉反馈);并且可以用任何形式(包括声输入、语音输入、或者触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如,作为数据服务器)、或者包括中间件部件的计算系统(例如,应用服务器)、或者包括前端部件的计算系统(例如,具有图形用户界面或者网络浏览器的用户计算机,用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如,通信网络)来将系统的部件相互连接。通信网络的示例包括:局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器,也可以为分布式系统的服务器,或者是结合了区块链的服务器。

应该理解,可以使用上面所示的各种形式的流程,重新排序、增加或删除步骤。例如,本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行,只要能够实现本公开公开的技术方案所期望的结果,本文在此不进行限制。

上述具体实施方式,并不构成对本公开保护范围的限制。本领域技术人员应该明白的是,根据设计要求和其他因素,可以进行各种修改、组合、子组合和替代。任何在本公开的原则之内所作的修改、等同替换和改进等,均应包含在本公开保护范围之内。

技术分类

06120116333924