CN110444200A - 信息处理方法、电子设备、服务器、计算机***及介质 - Google Patents

Abstract

本公开提供了一种信息处理方法，应用于电子设备，该信息处理方法包括：获取用户输入的语音缴费请求；对语音缴费请求进行语音识别，得到对应的文本缴费请求；将文本缴费请求发送给第一服务器，其中，第一服务器用于响应于文本缴费请求并向电子设备返回对应的响应结果；以及接收第一服务器返回的响应结果，并基于响应结果播报第一语音信息。本公开还提供了另一种信息处理方法、一种电子设备、一种服务器、一种计算机***及一种计算机可读存储介质。

Description

信息处理方法、电子设备、服务器、计算机***及介质

技术领域

本公开涉及互联网技术领域，更具体地，涉及一种信息处理方法、 另一种信息处理方法、电子设备、服务器、计算机***及计算机可读 存储介质。

背景技术

在现代生活中，水和燃气是用户进行正常生产生活的刚性需求。 随着互联网技术的飞速发展，缴纳水费和燃气费的流程也逐渐从银行 排队的缴费模式过度到利用手机APP的线上缴费模式。

但是，在相关技术中，利用手机APP线上缴费时，一般需要用户 手动完成筛选缴费城市、筛选缴费单位、输入用户编号、绑定缴费银 行卡、查询缴费账单、完成缴费等一系列操作，且当出现新的缴费账 单后，用户需要再次手动打开APP，找到生活缴费入口，并重复执行 查询缴费账单、完成缴费等一系列操作。

在实现本公开构思的过程中，发明人发现现有技术中至少存在如 下问题：现有的缴费方式对用户双手和手机的依赖性过高，在用户双 手被占用或不方便操作手机时，便无法完成缴费操作。

发明内容

有鉴于此，本公开提供了一种基于语音缴费请求执行缴费相关操 作以解决现有的缴费方式对用户双手和手机的依赖性过高，在用户双 手被占用或不方便操作手机时，便无法完成缴费操作的缺陷的信息处 理方法和***。

本公开的一个方面提供了一种信息处理方法，应用于电子设备， 该信息处理方法包括：获取用户输入的语音缴费请求；对上述语音缴 费请求进行语音识别，得到对应的文本缴费请求；将上述文本缴费请 求发送给第一服务器，其中，上述第一服务器用于响应于上述文本缴 费请求并向上述电子设备返回对应的响应结果；以及接收上述第一服 务器返回的上述响应结果，并基于上述响应结果播报第一语音信息。

根据本公开的实施例，上述信息处理方法还包括：在获取用户输 入的语音缴费请求之后，判断上述电子设备是否已开通上述缴费服务； 以及若上述电子设备尚未开通上述缴费服务，则播报第二语音信息以 通知用户开通上述缴费服务再缴费。

根据本公开的实施例，基于上述响应结果播报第一语音信息包括： 在上述响应结果中包含有账单信息的情况下，先语音播报上述账单信 息的详情，再播报第一语音提示信息以询问用户是否确认缴费。

根据本公开的实施例，上述信息处理方法还包括：若接收到用户 输入的语音确认指令，则播报第二语音提示信息以向用户询问支付口 令。

根据本公开的实施例，上述信息处理方法还包括：在播报第二语 音提示信息以向用户询问支付口令之后，若接收到用户输入的支付口 令，则将用户输入的支付口令发送给第二服务器，其中，上述第二服 务器用于验证用户输入的支付口令并在验证通过时将验证通过信息发 送给上述第一服务器，其中，上述第一服务器用于接收上述验证通过 信息并完成对应的缴费操作。

本公开的另一个方面提供了一种信息处理方法，应用于服务器， 该信息处理方法包括：获取来自电子设备的文本缴费请求，其中，上 述文本缴费请求为上述电子设备在获取用户输入的语音缴费请求后对 上述语音缴费请求进行语音识别得到的；以及响应于上述文本缴费请 求，并向上述电子设备返回对应的响应结果，其中，上述电子设备用 于接收上述服务器返回的上述响应结果，并基于上述响应结果播报第 一语音信息。

根据本公开的实施例，响应于上述文本缴费请求，并向上述电子 设备返回对应的响应结果包括：基于上述文本缴费请求，查询对应的 第一账单信息；以及将上述第一账单信息返回给上述电子设备，使得 上述电子设备语音播报上述第一账单信息的详情，并播报第一语音提 示信息以询问用户是否确认缴费。

根据本公开的实施例，上述信息处理方法还包括：在将上述第一 账单信息返回给上述电子设备之前，将上述第一账单信息转换为上述 电子设备能够识别的第二账单信息。

本公开的另一个方面提供了一种电子设备，用于进行信息处理， 上述电子设备包括：第一获取模块，用于获取用户输入的语音缴费请 求；识别模块，用于对上述语音缴费请求进行语音识别，得到对应的 文本缴费请求；第一发送模块，用于将上述文本缴费请求发送给第一 服务器，其中，上述第一服务器用于响应于上述文本缴费请求并向上 述电子设备返回对应的响应结果；以及处理模块，用于接收上述第一 服务器返回的上述响应结果，并基于上述响应结果播报第一语音信息。

根据本公开的实施例，上述电子设备还包括：判断模块，用于在 获取用户输入的语音缴费请求之后，判断上述电子设备是否已开通上 述缴费服务；以及第一输出模块，用于在上述电子设备尚未开通上述 缴费服务的情况下，播报第二语音信息以通知用户开通上述缴费服务 再缴费。

根据本公开的实施例，上述处理模块还用于，在上述响应结果中 包含有账单信息的情况下，先语音播报上述账单信息的详情，再播报 第一语音提示信息以询问用户是否确认缴费。

根据本公开的实施例，上述电子设备还包括：第二输出模块，用 于在接收到用户输入的语音确认指令的情况下，播报第二语音提示信 息以向用户询问支付口令。

根据本公开的实施例，上述电子设备还包括：第二发送模块，用 于在播报第二语音提示信息以向用户询问支付口令之后，若接收到用 户输入的支付口令，则将用户输入的支付口令发送给第二服务器，其 中，上述第二服务器用于验证用户输入的支付口令并在验证通过时将 验证通过信息发送给上述第一服务器，其中，上述第一服务器用于接 收上述验证通过信息并完成对应的缴费操作。

本公开的另一个方面提供了一种服务器，用于进行信息处理，上 述服务器包括：第二获取模块，用于获取来自电子设备的文本缴费请 求，其中，上述文本缴费请求为上述电子设备在获取用户输入的语音 缴费请求后对上述语音缴费请求进行语音识别得到的；以及响应模块， 用于响应于上述文本缴费请求，并向上述电子设备返回对应的响应结 果，其中，上述电子设备用于接收上述服务器返回的上述响应结果， 并基于上述响应结果播报第一语音信息。

根据本公开的实施例，上述响应模块包括：查询单元，用于基于 上述文本缴费请求，查询对应的第一账单信息；以及返回单元，用于 将上述第一账单信息返回给上述电子设备，使得上述电子设备语音播 报上述第一账单信息的详情，并播报第一语音提示信息以询问用户是 否确认缴费。

根据本公开的实施例，上述服务器还包括：转换模块，用于在将 上述第一账单信息返回给上述电子设备之前，将上述第一账单信息转 换为上述电子设备能够识别的第二账单信息。

本公开的另一个方面提供了一种计算机***，包括：一个或多个 处理器；计算机可读存储介质，用于存储一个或多个程序，其中，当 上述一个或多个程序被上述一个或多个处理器执行时，使得上述一个 或多个处理器实现如上任一项所述的信息处理方法。

本公开的另一个方面提供了一种计算机可读存储介质，其上存储 有可执行指令，该指令被处理器执行时使上述处理器实现如上任一项 所述的信息处理方法。

根据本公开的实施例，因为采用了基于语音缴费请求执行缴费相 关操作的技术手段，可以至少部分地解决现有的缴费方式对用户双手 和手机的依赖性过高，在用户双手被占用或不方便操作手机时，便无 法完成缴费操作的技术问题，并因此可以实现通过语音进行缴费的技 术效果。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其 他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的可以应用信息处理方法及电 子设备的应用场景；

图2A示意性示出了根据本公开实施例的信息处理方法的流程图；

图2B示意性示出了根据本公开实施例的电子设备的示意图；

图2C示意性示出了根据本公开实施例的语音缴费的示意图；

图2D示意性示出了根据本公开另一实施例的语音缴费的示意图；

图2E示意性示出了现有技术的缴费方式的示意图；

图3A示意性示出了根据本公开另一实施例的信息处理方法的流程 图；

图3B示意性示出了根据本公开实施例的开通缴费服务的流程图；

图3C示意性示出了根据本公开实施例的电子设备、第一服务器和 第二服务器交互的流程图；

图3D示意性示出了根据本公开实施例的判断用户类型的流程图；

图4示意性示出了根据本公开另一实施例的信息处理方法的流程图；

图5A示意性示出了根据本公开实施例的响应于文本缴费请求并向 电子设备返回对应的响应结果的流程图；

图5B示意性示出了根据本公开实施例的服务器的示意图；

图6示意性示出了根据本公开实施例的电子设备的框图；

图7A示意性示出了根据本公开另一实施例的电子设备的框图；

图7B示意性示出了根据本公开另一实施例的电子设备的框图；

图7C示意性示出了根据本公开另一实施例的电子设备的框图；

图8示意性示出了根据本公开实施例的服务器的框图；

图9A示意性示出了根据本公开实施例的响应模块的框图；

图9B示意性示出了根据本公开另一实施例的服务器的框图；以及

图10示意性示出了根据本公开实施例的适于实现信息处理方法的 计算机***的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些 描述只是示例性的，而并非要限制本公开的范围。此外，在以下说明 中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的 概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本 公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、 操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、 步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人 员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解 释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于 刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下， 一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释 (例如，“具有A、B和C中至少一个的***”应包括但不限于单独 具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有 B和C、和/或具有A、B、C的***等)。在使用类似于“A、B或C 等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术 人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中 至少一个的***”应包括但不限于单独具有A、单独具有B、单独具 有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C 的***等)。本领域技术人员还应理解，实质上任意表示两个或更多 可选项目的转折连词和/或短语，无论是在说明书、权利要求书还是附 图中，都应被理解为给出了包括这些项目之一、这些项目任一方、或 两个项目的可能性。例如，短语“A或B”应当被理解为包括“A” 或“B”、或“A和B”的可能性。

需要说明的是，智能语音技术是一种基于语音输入的新型自然的 交互方式，与传统的通过文本输入方式相比，用户只需要通过自然的 语言与带有语音交互功能的智能设备进行对话，就可以获取海量服务。 通过语音交互的方式获取服务的优势在于，1、大幅度降低用户使用电 子设备的成本，优化交互流程，缩短获取服务的时间；2、丰富了用户 获取服务的方式，彻底解放双手，当用户的双手被占用时，也可以通 过语音获取服务；3、针对一些有特殊需求的人群，例如老人、孩子、 残疾人等人群，降低了他们获取服务的门槛。

在现代生活中，水和燃气是人们进行正常生产生活的刚需。而随 着互联网技术的飞速发展，缴纳水费和燃气费的流程也越来越简化， 从排队到银行缴纳，到现在通过各种手机App完成线上缴纳，用户只 需在手机中选择缴费城市、缴费单位，输入用户编号、绑定银行卡， 就可以轻松完成缴费，提高了效率。然而，现有的缴费方式对用户双 手和手机的依赖性过高，在用户双手被占用或不方便操作手机时，便 无法完成缴费操作。基于此，对于广大用户来说，实现语音缴费，如 缴纳水费、燃气费等成为亟待解决的问题。

本公开的实施例提供了一种信息处理方法，应用于电子设备，包括： 获取用户输入的语音缴费请求；对语音缴费请求进行语音识别，得到对 应的文本缴费请求；将文本缴费请求发送给第一服务器，其中，第一服 务器用于响应于文本缴费请求并向电子设备返回对应的响应结果；以及 接收第一服务器返回的响应结果，并基于响应结果播报第一语音信息。

图1示意性示出了根据本公开实施例的可以应用信息处理方法及电 子设备的应用场景。需要注意的是，图1所示仅为可以应用本公开实施 例的应用场景的示例，以帮助本领域技术人员理解本公开的技术内容， 但并不意味着本公开实施例不可以用于其他设备、***、环境或场景。

在本公开实施例的应用场景中，假设电子设备包括智能音箱102， 在用户101需要缴纳费用(例如缴纳水费、电费)或者充值时，可以如 图1所示，用户101可以向智能音箱102发送用于缴费的语音缴费请求， 该智能音箱102可以获取并识别该语音缴费请求，以得到文本缴费请求， 然后可以将该文本缴费请求送给第一服务器，例如缴费单位服务器，并 接收该第一服务器针对该文本缴费请求反馈的响应结果，然后智能音箱 102可以基于该响应结果输出对应的第一语音信息，以通知用户101是 否需要执行其他缴费操作。

换言之，在本公开的实施例的应用场景中，用户可以实现通过语音 缴纳费用的目的，进而可以避免现有的缴费方式对用户双手和手机的依 赖性过高，在用户双手被占用或不方便操作手机时，便无法完成缴费操 作的缺陷。

图2A示意性示出了根据本公开实施例的信息处理方法的流程图。

如图2A所示，该信息处理方法可以包括操作S201～操作S204，其 中：

在操作S201，获取用户输入的语音缴费请求。

在操作S202，对语音缴费请求进行语音识别，得到对应的文本缴 费请求。

在操作S203，将文本缴费请求发送给第一服务器，其中，第一服 务器用于响应于文本缴费请求并向电子设备返回对应的响应结果。

在操作S204，接收第一服务器返回的响应结果，并基于响应结果 播报第一语音信息。

本公开提供的信息处理方法可以应用于电子设备，该电子设备可 以包括但不限于具有语音交互功能的电子设备，例如智能语音设备， 该智能语音设备可以包括智能音箱(可简称为音箱)。基于语音交互功 能，电子设备可以与用户进行语音交互。例如，用户可以向该电子设 备发出语音缴费请求，该电子设备可以接收该用户输入的语音缴费请 求。

此外，该电子设备还可以与其对应的应用程序相关联，例如APP， 该应用程序可以是安装在其他电子设备上的，例如手机，且用户可以 在该应用程序上开通用户所需要的服务，例如，缴费服务。

根据本公开的实施例，在电子设备获取用户输入的语音缴费请求 后，可以按照预设规则对该语音缴费请求进行语音识别，得到对应的 文本缴费请求。其中，该预设规则可以包括自动语音识别(Auto Speech Recognition，简称为ASR)。

进一步，电子设备可以将该文本缴费请求发送给第一服务器，其 中，该第一服务器可以包括缴费单位服务器，进而，第一服务器可以 响应该文本缴费请求，得到对应的响应结果，并将该响应结果返回给 电子设备。

需要说明的是，在第一服务器将响应结果返回给电子设备之前， 还需要将该响应结果转换为电子设备可以识别的文本，具体地，可以 通过自然语言处理(NaturalLanguage Processing，简称为NLP)进行 转换。

根据本公开的实施例，电子设备可以接收该第一服务器返回的响 应结果，然后通过文本转语音(Text To Speech，简称为TTS)技术将 该响应结果转换为对应的第一语音信息，还可以播报该第一语音信息 以通知用户是否需要执行其他缴费操作。其中，该其他缴费操作可以 包括确认缴费操作、拒绝交费操作、确认充值操作、拒绝充值操作等 等。

需要说明的是，电子设备与第一服务器的通信可以通过第三方完 成，该第三方可以包括第二服务器(又称为语音云端，可简称为云端)。

图2B示意性示出了根据本公开实施例的电子设备的示意图。

如图2B所示，在本公开的一种示例性应用场景中，电子设备210 可以包括语音输入单元211、语音输出单元212、通讯单元213和综合 处理单元214，在语音服务情形下，电子设备210既需要接收语音(用 户发出的指令)，也需要输出语音(给用户反馈)，并进行相应的综合处 理。

图2C示意性示出了根据本公开实施例的语音缴费的示意图。

如图2C所示，在本公开的实施例中，电子设备210可以与第一服 务器230及第二服务器220交互形成一个智能语音***，以满足用户101 的常规语音服务需要。而在语音缴纳水费、燃气费服务的情形下，第二 服务器220(也可以称为云端)与第一服务器230以云云对接的方式实现连接，他们之间可以协同实现语音缴纳水费、燃气费的需求。

图2D示意性示出了根据本公开另一实施例的语音缴费的示意图。

如图2D所示，在本公开的实施例中，在操作S301，用户向电子 设备发出用户指令后，该电子设备可以执行操作S302，利用ASR将 用户指令中的语音缴费请求转换成文本缴费请求。在操作S303和操作 S304，电子设备将该文本缴费请求发送给第一服务器，该第一服务器 可以利用NLP将该文本缴费请求转换成自己能够识别的语言，并进行 语义分析，然后根据语义分析结果进行缴费。进一步，在操作S305， 第一服务器可以将缴费结果返回给电子设备，在操作S306，该电子设 备可以利用TTS将缴费结果转换成语音反馈给用户。

图2E示意性示出了现有技术的缴费方式的示意图。

与本公开的实施例不同，如图2E所示，在现有的技术方案中，用 户大都是利用手机App在线上完成选择缴费城市、缴费单位、输入用 户编号、绑定银行卡、手动查询账单、完成缴纳这一系列操作。在出 现新的缴费账单后，用户需要打开手机App，找到生活缴费的入口， 然后重复查询账单、完成缴纳的操作。并且，缴纳账单和使用手机是 强相关的，即想完成缴费操作，必须依赖于手机使用。所以，当用户 身边没有手机，或者双手被占用不方便操作手机时，就无法完成上述 操作。因此，仅仅利用手机完成缴费操作，使缴费的使用场景有很大 的局限性，且用户使用体验也难以保障。

通过本公开的实施例，因为采用了基于语音缴费请求执行缴费相 关操作的技术手段，可以至少部分地解决现有的缴费方式对用户双手 和手机的依赖性过高，在用户双手被占用或不方便操作手机时，便无 法完成缴费操作的技术问题，并因此可以实现通过语音进行缴费的技 术效果。

下面参考图3A～图3D，结合具体实施例对图2A～图2D所示的方法 做进一步说明。

图3A示意性示出了根据本公开另一实施例的信息处理方法的流程 图。

如图3A所示，该信息处理方法还可以包括操作S401～操作S402， 其中：

在操作S401，在获取用户输入的语音缴费请求之后，判断电子设 备是否已开通缴费服务。

在操作S402，若电子设备尚未开通缴费服务，则播报第二语音信 息以通知用户开通缴费服务再缴费。

在本公开的实施例中，用户若想通过电子设备实现缴费的目的， 可以提前利用电子设备对应的应用程序开通缴费服务。其中，该应用 程序可以是安装在该电子设备中，也可以是安装在其他电子设备中， 在此不做限定。为了便于说明，下面以电子设备为智能音箱(例如叮 咚音箱)作为示例展开描述。

图3B示意性示出了根据本公开实施例的开通缴费服务的流程图。

如图3B所示，用户利用智能音箱(电子设备的一种示例)对应的 音箱App开通缴费服务的操作流程如下：

在操作S501，点击生活缴费。

在操作S502，点击水费或燃气费。

在操作S503，是否已有信息。

在操作S504，选择缴费单位。

在操作S505，填写用户编号。

在操作S506，是否可以拉取用户信息。

在操作S507，自动弹出用户信息.

在操作S508，点击立即开通。

根据本公开的实施例，用户打开音箱App后，进入生活缴费模块 后，点击水费或燃气费，然后音箱App判断用户信息是否已经存在， 如果存在，则用户可以直接点击立即开通，即可完成开通缴费服务， 如果不存在，则需要用户手动选择缴费单位、缴费城市等，并输入用 户编号。之后，音箱App会判断是否可以自动拉取用户信息，如果可 以，则自动弹出用户信息，然后用户点击立即开通，即可完成开通生 活缴费服务，如果不可以，则不必在拉取用户信息，用户直接点击立 即开通即可。

应该理解，用户只需在信息预设时用到音箱App，只要设置完成， 且用户没有关闭其请求开通的服务(例如缴费服务)，之后用户的所有 查询缴纳操作，均可以利用语音交互的形式在音箱端完成。

需要说明的是，用户可以是以个人、家庭或公司为单位，每个用 户对应一个用户编号，电子设备可以与该用户编号绑定，以实现电子 设备与用户编号、用户之间的一一对应关系。

根据本公开的实施例，判断电子设备是否开通了缴费服务，可以 通过判断该电子设备对应的用户编号在应用程序上是否开通了缴费服 务。若该电子设备对应的用户编号在应用程序上没有开通该缴费服务， 则表明该电子设备没有开通该缴费服务。此时，电子设备可以播报第 二语音信息，该第二语音信息可用于通知用户开通缴费服务再缴费。

通过本公开的实施例，在判断出电子设备未开通缴费服务的情况 下，通知用户先开通缴费服务再进行缴费，提高了语音缴费的准确性。

作为一种可选的实施例，基于响应结果播报第一语音信息可以包 括：在响应结果中包含有账单信息的情况下，先语音播报账单信息的 详情，再播报第一语音提示信息以询问用户是否确认缴费。

在本公开的实施例中，在电子设备向第一服务器(例如缴费单位 服务器)发送文本缴费请求后，第一服务器响应于该文本缴费请求， 并向电子设备返回对应的响应结果，该响应结果中可能包含第一服务 器返回的账单信息，该账单信息可以是用户在一段时间范围内的账单 详情，例如，6月到8月。

根据本公开的实施例，电子设备可以将该账单信息通过TTS技术 转换为语音并进行播报，进一步，再播报用于询问用户是否确认缴费 的第一语音提示信息。

通过本公开的实施例，先语音播报账单信息再播报第一语音提示 信息，询问用户是否确认缴费，可以使用户基于账单信息发出相关语 音指令，不仅可以进一步提高语音缴费的准确性，还可以提高用户的 体验效果。

作为一种可选的实施例，该信息处理方法还可以包括：若接收到 用户输入的语音确认指令，则播报第二语音提示信息以向用户询问支 付口令。

需要说明的是，用户还可以向电子设备输入语音反馈信息，该语 音反馈信息可以包括用于确认缴费的语音信息，也可以包括用于拒绝 缴费的语音信息。

根据本公开的实施例，电子设备在接收到该语音反馈信息后，可 以利用ASR技术将语音反馈信息转换为对应的文本反馈信息，并将该 文本反馈信息发送到第二服务器(例如云端)，该第二服务器中可以包 含有预先设定的语料库，第二服务器可以将文本反馈信息与语料库进 行对比，以确认该文本反馈信息中是否包含有确认指令，并将确认结 果返回给电子设备。

根据本公开的实施例，若确认结果为该文本反馈信息中是否包含 有确认指令，则表明电子设备接收到了用户输入的语音确认指令，进 而，电子设备可以播报第二语音提示信息以向用户询问支付口令。

通过本公开的实施例，在接收到用户输入的语音确认指令后，再 播报第二语音提示信息以向用户询问支付口令，如此连贯的操作，可 以进一步提高用户的体验效果。

作为一种可选的实施例，该信息处理方法还可以包括：在播报第二 语音提示信息以向用户询问支付口令之后，若接收到用户输入的支付口 令，则将用户输入的支付口令发送给第二服务器，其中，第二服务器用 于验证用户输入的支付口令并在验证通过时将验证通过信息发送给第 一服务器，其中，第一服务器用于接收验证通过信息并完成对应的缴费操作。

在本公开的实施例中，在播报第二语音提示信息以向用户询问支付 口令之后，用户可以向电子设备输入语音形式的支付口令，该语音形式 的支付口令可以包括正确的支付口令，也可以包括错误的支付口令。

根据本公开的实施例，电子设备在接收到该语音形式的支付口令 后，可以利用ASR技术将语音形式的支付口令转换为对应的文本形式 的支付口令，并将该文本形式的支付口令发送到第二服务器进行验证， 第二服务器可以向电子设备返回验证结果。其中，该验证结果可以包 括验证通过信息和验证不通过信息。

进一步，若该验证结果为验证通过信息，则第二服务器将该验证 通过信息发送给第一服务器，第一服务器可以接收该验证通过信息并 完成对应的缴费操作。

通过本公开的实施例，在支付口令验证通过后，第一服务器可以接 收该验证通过信息并完成缴费操作，进而实现了用户可以通过语音缴费 的目的，克服了现有的缴费方式对用户双手和手机的依赖性过高，在用 户双手被占用或不方便操作手机时，便无法完成缴费操作的缺陷。

图3C示意性示出了根据本公开实施例的电子设备、第一服务器 和第二服务器交互的流程图。

在本公开的实施例中，电子设备可以包括智能音箱，第一服务器可 以包括缴费单位服务器，第二服务器可以包括语音云端。

根据本公开的实施例，在电子设备处于休眠状态时，用户可以通过 输入特征指令来唤醒该电子设备，比如用户可以通过输入“叮咚叮咚” 语音指令唤醒该电子设备。

如图3C所示，用户可以通过操作S601唤醒电子设备，并向电子设 备输入语音缴费请求，例如“叮咚叮咚(用于唤醒电子设备)，帮我交 水费(或者其他类似词句)”。此时，电子设备可以通过操作S602识别 出相应信息例如识别该语音缴费请求并判断电子设备是否已经开通了 缴费服务，如果未开通，则通过操作S603告知用户“请先开通电子设 备的缴费服务”，如果判断已开通，则可以通过操作S604云云对接通道 以及操作S605将识别得到的相应词句信息例如文本缴费请求发送给第 一服务器，第一服务器可以进行操作S606语义比对处理和服务查询， 然后通过操作S607云云对接通道向电子设备返回查询结果，电子设备据此进行TTS处理并通过操作S608告知用户账单详情，并询问用户是 否确认缴纳。用户通过与电子设备的操作S609交互确认缴纳账单信息 后，如用户说：“确认缴费”，电子设备可以通过操作S610询问用户口 令支付密码，用户通过与电子设备的操作S611交互，输入支付口令， 电子设备通过操作S612将支付口令送达第二服务器进行验证，如果验 证通过，则通过操作S613云云对接通道将信息发送给第一服务器，此 时第一服务器通过操作S614完成缴费操作。

可选地，如果用户只输入了两个缴费类型(例如水费、燃气费) 中的一项的信息，但是通过操作S601说了缴纳另一项费用，则电子 设备通过操作S602识别出相应信息并判断电子设备是否已经开通了 该种缴费类型，如果不支持，则通过操作S603告知用户“对不起， 未查询到您的缴费信息，请到电子设备(例如智能音箱)的客户端(又 称为应用程序)完善信息后再试”。

可选地，如果用户通过操作S601发出了缴费请求，但是电子设 备通过操作S602识别出用户没有开通免密支付，则通过操作S603告 知用户“对不起，您还没有开通免密支付，请到电子设备客户端开通 免密支付后再试”。

可选地，如果用户通过操作S601发出了缴费请求，但是电子设 备通过操作S602识别出当前时间不在缴费时段内，则通过操作S603 告知用户“对不起，当前时段不可缴费，可缴费时间段为XX点XX 分至XX点XX分”。

可选地，如果电子设备返回账单信息并询问用户是否需要缴纳时， 用户通过操作S609发出了拒绝的指令，如“取消”，则电子设备可以 退出缴费操作。

可选地，如果用户确认缴纳，并说出了支付口令，且经操作S612 传送给第二服务器并判断口令正确，但是第二服务器判断用户卡内余 额不足时，将通过操作S615将此信息反馈给电子设备，并通过操作 S616告知用户：“由于您绑定的支付账户余额不足，无法完成缴费”。

可选地，出于风险控制的考虑，如果用户通过与电子设备的操作 S609交互确认缴纳账单后，电子设备判断用户今天通过电子设备语音 缴费已经超过三单，则通过操作S610告知用户：“您今日已在电子设 备(例如叮咚音箱)使用缴费服务超过3单，为保障您的支付安全， 请您前往手机客户端缴费。”

可选地，出于风险控制的考虑，如果用户通过操作S601～操作S605 将缴费指令发送给第一服务器，且第一务器判断用户欠费超过三期， 则通过操作S607～操作S608告知用户：“由于您欠费账期超过3期， 为保障您的支付安全，请您前往手机客户端缴费。”

可选地，出于风险控制的考虑，如果用户通过操作S601～操作S605 将缴费指令发送给第一服务器，且第一服务器返回账单后第二服务器 判断用户欠费超过免密支付限额，则通过操作S607～操作S608告知用 户：“此金额超出免密支付单笔额度，为保障您的支付安全，请您前往 手机客户端缴费。”

可选地，如果用户通过与电子设备的操作S611交互，输入支付 口令，电子设备通过操作S612将支付口令送达第二服务器进行验证， 且验证没有通过，则操作S615～操作S616告知用户重新输入，如果错 误次数超过三次，则直接退出缴费操作。

图3D示意性示出了根据本公开实施例的判断用户类型的流程图。

如图3D所示，其中：

在操作S701，用户发出缴费请求。

在操作S702，是否已满足所有输入域。

在操作S703，判断为何种用户。

在操作S704，缴费用户。

在操作S705，充值用户。

在操作S706，后台查询最近3个月账单。

需要说明的是，本公开实施例的基于智能语音交互的缴纳水费和 燃气费的方案，可以应用但不限于缴费场景、充值场景等。

根据本公开的实施例，在电子设备开通缴费服务后，用户可以直 接对电子设备发出查询指令(例如缴费请求)，电子设备可以根据用户 选择的缴费城市、缴费单位、用户编号等，判断用户是缴费用户还是 充值用户。

具体地，在用户发出缴费请求后，电子设备可以判断根据用户之 前在电子设备关联的APP中输入的信息是否已满足所有输入域，其中， 该输入域可以包括缴费城市、缴费单位、用户编号等。若满足，电子 设备可以进一步判断用户是何种类型的用户，如缴费用户、充值用户 等。若不满足，电子设备可以根据预设操作，向用户返回最近3个月 的账单，例如，当前月份为9月，则第一服务器可以查询并通过电子 设备向用户返回6月的账单、7月的账单和8月的账单，且电子设备 可以默认该用户为缴费用户。

为了更好地解释上述语音缴纳水费、燃气费机制，假设电子设备 包括音箱，下面分别针对缴费类型的用户和充值类型的用户予以具体 实例说明。

根据本公开的实施例，以通过“叮咚叮咚”唤醒电子设备为例， 针对缴费类型的用户以具体实例进行说明如下。需要说明的是，以下 实施例中的用户信息可以包括用户编号。

实例一：(用户无欠费记录)

用户：叮咚叮咚，帮我交水费。

音箱：未查询到用户信息为XXX的欠费记录。

实例二：(用户缴费成功，用户欠费一个月)

用户：叮咚叮咚，帮我交水费。

音箱：正在查询用户信息为XXX的账单：您2017年6月欠费 50元，是否确认缴纳？

用户：确认。

音箱：您已开通免密支付，请说出您的免密支付口令。

用户：12346。

音箱：口令验证成功，2017年6月水费账单共计50元支付成功。 ***已为您提交缴费请求。

实例三：(用户缴费成功，用户欠费多个月)

用户：叮咚叮咚，帮我交水费。

音箱：正在查询用户信息为XXX的账单：您2017年4月欠费20 元，2017年5月欠费30元，2017年6月欠费50元，累计欠费100 元，是否确认缴纳？

用户：确认。

音箱：您已开通免密支付，请说出您的免密支付口令。

用户：123456。

音箱：口令验证成功，2017年4月、2017年5月、2017年6月 水费账单共计100元支付成功。***已为您提交缴费请求。

实例四：(用户主动取消缴费)

用户：叮咚叮咚，帮我交水费。

音箱：正在查询用户信息为XXX的账单：您2017年6月欠费50 元，是否确认缴纳？

用户：取消。

音箱：支付已取消。

实例五：(余额不足，用户被动取消缴费，用户欠费一个月)

用户：叮咚叮咚，帮我交水费。

音箱：正在查询用户信息为XXX的账单：您2017年6月欠费50 元，是否确认缴纳？

用户：确认。

音箱：您已开通免密支付，请说出您的免密支付口令。

用户：123456。

音箱：由于您绑定的支付账户余额不足，无法完成缴费。

实例六：(余额不足支付第一个月欠费，用户被动取消，用户欠费 多个月)

用户：叮咚叮咚，帮我交水费。

音箱：正在查询用户信息为XXX的账单：您2017年4月欠费20 元，2017年5月欠费30元，2017年6月欠费50元，累计欠费100 元，是否确认缴纳？

用户：确认。

音箱：您已开通免密支付，请说出您的免密支付口令。

用户：123456。

音箱：由于您绑定的支付账户余额不足，无法完成缴费。

实例七：(余额不足支付所有月的欠费，但可以支付部分月份的账 单，用户欠费多月)

用户：叮咚叮咚，帮我交水费。

音箱：正在查询用户信息为XXX的账单：您2017年4月欠费20 元，2017年5月欠费30元，2017年6月欠费50元，累计欠费100 元，是否确认缴纳？

用户：确认。

音箱：您已开通免密支付，请说出您的免密支付口令。

用户：123456。

音箱：口令验证成功，2017年4月水费账单共计20元支付成功。 由于您绑定的支付账户余额不足，无法支付2017年5月、2017年6 月水费账单。

根据本公开的实施例，以通过“叮咚叮咚”唤醒电子设备为例， 针对充值类型的用户以具体实例进行说明如下。

实例一：(用户明确充值金额，充费成功)

用户：叮咚叮咚，帮我充100元水卡。

音箱：正在为XXX充值100元水费，是否确认充值？

用户：确认。

音箱：您已开通免密支付，请说出您的免密支付口令。

用户：123456。

音箱：口令验证成功，支付成功。***已为您提交缴费请求。

实例二：(用户未明确充值金额)

用户：叮咚叮咚，帮我充水卡。

音箱：好的，本次充值限额500元，请问充值多少钱？

用户：100元。

音箱：正在为XXX充值100元水费，是否确认充值？

用户：确认。

实例三：(用户主动取消充值)

用户：叮咚叮咚，帮我充值100元水卡。

音箱：正在为XXX充值100元水费，是否确认充值？

用户：取消。

音箱：充值已取消。

实例四：(余额不足，用户被动取消充值)

用户：叮咚叮咚，帮我充值100元水卡。

音箱：正在为XXX充值100元水费，是否确认充值？

用户：确认。

音箱：您已开通免密支付，请说出您的免密支付口令。

用户：123456。

音箱：对不起，由于您绑定的支付账户余额不足，无法完成充值。

需要说明的是，在上述示例中，以音箱作为电子设备进行举例， 但在其他示例中，并不局限于此，例如对于很多电子设备而言，其本 身可能还带有屏幕，此时可以在带屏的电子设备上统一集成实现相应 的功能。更具体地，以配置有各种智能语音模块的智能手机为例，该 智能手机本身可以实现前述音箱的所有功能，在这种情形下，上述实 例的方案也需要相应拓展变形，最终也能实现通过智能手机与第一服 务器的语音缴纳水费、燃气费的功能，其主要的功能流程可以参考前 述实施例的描述，在此不再展开。

图4示意性示出了根据本公开另一实施例的信息处理方法的流程图。

如图4所示，该信息处理方法可以包括操作S801～操作S802，其中：

在操作S801，获取来自电子设备的文本缴费请求，其中，文本缴 费请求为电子设备在获取用户输入的语音缴费请求后对语音缴费请求 进行语音识别得到的。

在操作S802，响应于文本缴费请求，并向电子设备返回对应的响 应结果，其中，电子设备用于接收服务器返回的响应结果，并基于响应 结果播报第一语音信息。

在本公开的实施例中，服务器可以包括上述实施例中的第一服务器， 在电子设备向服务器发送文本缴费请求后，服务器可以接受该文本缴费 请求并响应于该文本缴费请求。

根据本公开的实施例，服务器可以将响应结果返回电子设备，进而， 电子设备可以将该响应结果转换为第一语音信息并进行播报。

通过本公开的实施例，通过对来自电子设备的文本缴费请求进行响 应，并返回响应结果，可以使电子设备基于该返回的响应结果执行后续 操作，以便可以实现语音缴费的目的。

图5A示意性示出了根据本公开实施例的响应于文本缴费请求并向 电子设备返回对应的响应结果的流程图。

如图5A所示，响应于文本缴费请求，并向电子设备返回对应的响 应结果可以包括操作S901～操作S902，其中：

在操作S901，基于文本缴费请求，查询对应的第一账单信息。

在操作S902，将第一账单信息返回给电子设备，使得电子设备语 音播报第一账单信息的详情，并播报第一语音提示信息以询问用户是否 确认缴费。

在本公开的实施例中，在查询第一账单信息之前，服务器可以将文 本缴费请求与预存标准语句进行比对。在比对结果满足预设条件的情况 下，服务器可以查询与该文本缴费请求对应的第一账单信息。在比对结 果不满足预设条件的情况下，服务器可以向电子设备返回识别失败信息。

根据本公开的实施例，服务器还可以将查询到的第一账单信息返回 电子设备，其中，该第一账单信息可以是文本结构形式的。电子设备在 接收到第一账单信息后，还可以将其转换为语音形式，以向用户语音播 报第一账单信息的详情。进一步，电子设备还可以播报第一语音提示信 息，例如“是否确认缴费？”。

通过本公开的实施例，基于文本缴费请求查询对应的第一账单信息， 并将查询到的第一账单信息返回电子设备，以便电子设备可以基于该第 一账单信息进行语音播报，这种连续的智能化的流程，可以极大地减少 用户不必要的操作，提高缴费效率。作为一种可选的实施例，该信息处 理方法还可以包括：在将第一账单信息返回给电子设备之前，将第一账 单信息转换为电子设备能够识别的第二账单信息。

在本公开的实施例中，有时电子设备和服务器所能识别的文本格式 可能不同。此时，若电子设备具有文本转换的功能，则服务器可以直接 将查询到的第一账单信息返回给电子设备，进一步，电子设备可以基于 自身的文本转换功能将第一账单信息转换为其能够识别的第三账单信 息。

根据本公开的实施例，若电子设备不具有文本转换功能，或者即便 电子设备具有文本转换功能，服务器可以在将第一账单信息返回给电子 设备之前，将第一账单信息转换为电子设备能够识别的第二账单信息， 并将该第二账单信息返回给电子设备。

图5B示意性示出了根据本公开实施例的服务器的示意图。

如图5B所示，根据本公开的实施例，服务器可以包括语义处理单 元和缴费处理单元。该服务器可以执行图3C中描述的操作S606语义比 对处理和服务查询。具体地，语义处理单元中的语义分析引擎可以将语 句信息例如文本缴费请求与预存在语义库中的预存标准语句进行比对， 如果比对结果(例如模糊隶属值)满足预定条件(例如模糊隶属值大于等于0.7)，则表示比对通过。此时，可以将该文本缴费请求发送给缴费 处理单元，缴费处理单元可以基于该文本缴费请求进行查询处理，并将 查询到的第一账单信息返回给语义处理单元，语义处理单元中的结构化 文本输出可以将第一账单结果转化为对应的文本信息例如第二账单信 息，并将其通过操作S607云云对接通道发送回电子设备例如音箱。此 外，语义处理单元还可以接收用户通过电子设备发送的结果反馈，并将 该结果反馈发送至缴费处理单元，该缴费处理单元可以基于该结果反馈 完成缴费操作。

需要说明的是，语音缴纳水费、燃气费的过程，均可以采用多轮语 音会话的形式完成，且对于图5B中描述的语义比对处理可以采用模糊 方式。

具体地，模糊方式可以采用模糊数学进行模糊量化。例如，在模糊 数学中，一般采用模糊集合的方式。在该模糊集合中，给定范围内的元 素对它的隶属关系不一定只有“是”或“否”两种情况，而是用介于0 和1之间的实数来表示隶属程度，同时还可能存在中间过渡状态。比如 “老人”是个模糊概念，70岁的肯定属于老人，它的隶属程度是1，40 岁的人肯定不算老人，它的隶属程度为0。按照查德给出的公式，55岁 属于“老”的隶属程度为0.5，即“半老”，60岁属于“老”的隶属程度 为0.8。根据本公开的实施例，指明各个元素的隶属集合，就等于指定 了一个集合。当隶属程度隶属于0和1之间的数值时，就是模糊集合。

相应地，在语义识别上，可以将满足预定标准的标准词句的隶属函 数值定为1。那么，其它近义的以及能表达相仿的思想(语义)的词句， 就可以用以0到1之间的连续数值来表征它隶属于“正确句子”的隶属 程度。这样，就把模糊语言进行定量描述，并定出一套运算、变换规则。

通过本公开的实施例，通过用户和电子设备的多伦对话，以及电子 设备和服务器之间智能操作，用户可以在智能场景下完成缴费例如缴纳 水费、缴纳燃气费的需求，解决了传统模式中当用户身边没有手机或者 双手被占用不方便操作手机的情况下，无法完成缴费操作的场景局限性。

图6示意性示出了根据本公开实施例的电子设备的框图。

如图6所示，该电子设备300可以包括第一获取模块310、识别模 块320、第一发送模块330和处理模块340，其中：

第一获取模块310用于获取用户输入的语音缴费请求。

识别模块320用于对语音缴费请求进行语音识别，得到对应的文 本缴费请。

第一发送模块330用于将文本缴费请求发送给第一服务器，其中， 第一服务器用于响应于文本缴费请求并向电子设备返回对应的响应结 果。

处理模块340用于接收第一服务器返回的响应结果，并基于响应 结果播报第一语音信息。

通过本公开的实施例，因为采用了基于语音缴费请求执行缴费相 关操作的技术手段，可以至少部分地解决现有的缴费方式对用户双手 和手机的依赖性过高，在用户双手被占用或不方便操作手机时，便无 法完成缴费操作的技术问题，并因此可以实现通过语音进行缴费的技 术效果。

图7A示意性示出了根据本公开另一实施例的电子设备的框图。

如图7A所示，该电子设备300还可以包括判断模块410和第一输 出模块420，其中：

判断模块410用于在获取用户输入的语音缴费请求之后，判断电 子设备是否已开通缴费服务；以及

第一输出模块420用于在电子设备尚未开通缴费服务的情况下， 播报第二语音信息以通知用户开通缴费服务再缴费。

通过本公开的实施例，在判断出电子设备未开通缴费服务的情况 下，通知用户先开通缴费服务再进行缴费，提高了语音缴费的准确性。

作为一种可选的实施例，处理模块还用于，在响应结果中包含有 账单信息的情况下，先语音播报账单信息的详情，再播报第一语音提 示信息以询问用户是否确认缴费。

通过本公开的实施例，先语音播报账单信息再播报第一语音提示 信息，询问用户是否确认缴费，可以使用户基于账单信息发出相关语 音指令，不仅可以进一步提高语音缴费的准确性，还可以提高用户的 体验效果。

图7B示意性示出了根据本公开另一实施例的电子设备的框图。

如图7B所示，该电子设备300还可以包括第二输出模块510，其 中：

第二输出模块510用于在接收到用户输入的语音确认指令的情况下， 播报第二语音提示信息以向用户询问支付口令。

通过本公开的实施例，在接收到用户通过所述电子设备输入的语音 确认指令后，再播报第二语音提示信息以向用户询问支付口令，如此连 贯的操作，可以进一步提高用户的体验效果。

图7C示意性示出了根据本公开另一实施例的电子设备的框图。

如图7C所示，该电子设备300还可以包括第二发送模块610，其 中：

第二发送模块610用于在播报第二语音提示信息以向用户询问支付 口令之后，若接收到用户输入的支付口令，则将用户输入的支付口令发 送给第二服务器，其中，第二服务器用于验证用户输入的支付口令并在 验证通过时将验证通过信息发送给第一服务器，其中，第一服务器用于 接收验证通过信息并完成对应的缴费操作。

通过本公开的实施例，在支付口令验证通过后，第一服务器可以接 收该验证通过信息并完成缴费操作，进而实现了用户可以通过语音缴费 的目的，克服了现有的缴费方式对用户双手和手机的依赖性过高，在用 户双手被占用或不方便操作手机时，便无法完成缴费操作的缺陷。

图8示意性示出了根据本公开实施例的服务器的框图。

如图8所示，该服务器700可以包括第二获取模块710和响应模块 720，其中：

第二获取模块710用于获取来自电子设备的文本缴费请求，其中， 文本缴费请求为电子设备在获取用户输入的语音缴费请求后对语音缴 费请求进行语音识别得到的；以及

响应模块720用于响应于文本缴费请求，并向电子设备返回对应 的响应结果，其中，电子设备用于接收服务器返回的响应结果，并基 于响应结果播报第一语音信息。

通过本公开的实施例，通过对来自电子设备的文本缴费请求进行响 应，并返回响应结果，可以使电子设备基于该返回的响应结果执行后续 操作，以便可以实现语音缴费的目的。

图9A示意性示出了根据本公开实施例的响应模块的框图。

如图9A所示，该响应模块720可以包括查询单元721和返回单元 722，其中：

查询单元721用于基于文本缴费请求，查询对应的第一账单信息。

返回单元722用于将第一账单信息返回给电子设备，使得电子设 备语音播报第一账单信息的详情，并播报第一语音提示信息以询问用 户是否确认缴费。

通过本公开的实施例，基于文本缴费请求查询对应的第一账单信息， 并将查询到的第一账单信息返回电子设备，以便电子设备可以基于该第 一账单信息进行语音播报，这种连续的智能化的流程，可以极大地减少 用户不必要的操作，提高缴费效率。

图9B示意性示出了根据本公开另一实施例的服务器的框图。

如图9B所示，该服务器700还可以包括转换模块810，其中：

转换模块810用于在将第一账单信息返回给电子设备之前，将第一 账单信息转换为电子设备能够识别的第二账单信息。

通过本公开的实施例，通过用户和电子设备的多伦对话，以及电子 设备和服务器之间智能操作，用户可以在智能场景下完成缴费例如缴纳 水费、缴纳燃气费的需求，解决了传统模式中当用户身边没有手机或者 双手被占用不方便操作手机的情况下，无法完成缴费操作的场景局限性。

根据本公开的实施例的模块、单元中的任意多个、或其中任意多个 的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、单 元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施 例的模块、单元中的任意一个或多个可以至少被部分地实现为硬件电路， 例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC)，或可以通过对 电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以 软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当 组合来实现。或者，根据本公开实施例的模块、单元中的一个或多个可 以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，第一获取模块310、识别模块320、第一发送模块330、处理 模块340、判断模块410、第一输出模块420、第二输出模块510、第二 发送模块610、第二获取模块710、响应模块720、转换模块810、查询 单元721以及返回单元722中的任意多个可以合并在一个模块中实现， 或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的 一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结 合，并在一个模块中实现。根据本公开的实施例，第一获取模块310、 识别模块320、第一发送模块330、处理模块340、判断模块410、第一 输出模块420、第二输出模块510、第二发送模块610、第二获取模块 710、响应模块720、转换模块810、查询单元721以及返回单元722中 的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列 (FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装 上的***、专用集成电路(ASIC)，或可以通过对电路进行集成或封装 的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件 三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者， 第一获取模块310、识别模块320、第一发送模块330、处理模块340、 判断模块410、第一输出模块420、第二输出模块510、第二发送模块610、第二获取模块710、响应模块720、转换模块810、查询单元721 以及返回单元722中的至少一个可以至少被部分地实现为计算机程序模 块，当该计算机程序模块被运行时，可以执行相应的功能。

图10示意性示出了根据本公开实施例的适于实现信息处理方法的 计算机***的框图。图10示出的计算机***仅仅是一个示例，不应对 本公开实施例的功能和使用范围带来任何限制。

如图10所示，根据本公开实施例的计算机***900包括处理器901， 其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908 加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和 处理。处理器901例如可以包括通用微处理器(例如CPU)、指令集处 理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器901还可以包括用于缓存用途的板载存储器。处理器901 可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处 理单元或者是多个处理单元。

在RAM 903中，存储有计算机***900操作所需的各种程序和数 据。处理器901、ROM 902以及RAM 903通过总线904彼此相连。处 理器901通过执行ROM 902和/或RAM 903中的程序来执行根据本公开 实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 902和RAM 903以外的一个或多个存储器中。处理器901也可以 通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实 施例的方法流程的各种操作。

根据本公开的实施例，计算机***900还可以包括输入/输出(I/O) 接口905，输入/输出(I/O)接口905也连接至总线904。计算机*** 900还可以包括连接至I/O接口905的以下部件中的一项或多项：包括 键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示 器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908； 以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通 信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需 要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半 导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的 计算机程序根据需要被安装入存储部分908。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为 计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其 包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执 行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可 以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911 被安装。在该计算机程序被处理器901执行时，执行本公开实施例的系 统中限定的上述功能。根据本公开的实施例，上文描述的***、设备、 装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读介质，该计算机可读介质可以是上 述实施例中描述的设备/装置/***中所包含的；也可以是单独存在，而 未装配入该设备/装置/***中。上述计算机可读介质承载有一个或者多 个程序，当上述一个或者多个程序被执行时，实现：获取用户输入的语 音缴费请求；对语音缴费请求进行语音识别，得到对应的文本缴费请求； 将文本缴费请求发送给第一服务器，其中，第一服务器用于响应于文本 缴费请求并向电子设备返回对应的响应结果；以及接收第一服务器返回 的响应结果，并基于响应结果播报第一语音信息。

根据本公开的实施例，计算机可读介质可以是计算机可读信号介质 或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储 介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导 体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的 更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、 可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只 读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合 适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与 其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中 或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代 码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、 光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发 送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结 合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介 质传输，包括但不限于：无线、有线、光缆、射频信号等等，或者上述 的任意合适的组合。

例如，根据本公开的实施例，计算机可读介质可以包括上文描述的 ROM 902和/或RAM 903和/或ROM 902和RAM 903以外的一个或多 个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的***、方 法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上， 流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部 分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定 的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两 个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相 反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图 中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的 功能或操作的专用的基于硬件的***来实现，或者可以用专用硬件与计 算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记 载的特征可以进行多种组合或/或结合，即使这样的组合或结合没有明确 记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公 开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结 合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了 说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各 实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。 本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围， 本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本 公开的范围之内。

Claims (18)

1.一种信息处理方法，应用于电子设备，所述方法包括：

获取用户输入的语音缴费请求；

对所述语音缴费请求进行语音识别，得到对应的文本缴费请求；

将所述文本缴费请求发送给第一服务器，其中，所述第一服务器用于响应于所述文本缴费请求并向所述电子设备返回对应的响应结果；以及

接收所述第一服务器返回的所述响应结果，并基于所述响应结果播报第一语音信息。

2.根据权利要求1所述的方法，其中，所述方法还包括：

在获取用户输入的语音缴费请求之后，判断所述电子设备是否已开通所述缴费服务；以及

若所述电子设备尚未开通所述缴费服务，则播报第二语音信息以通知用户开通所述缴费服务再缴费。

3.根据权利要求1所述的方法，其中，基于所述响应结果播报第一语音信息包括：

在所述响应结果中包含有账单信息的情况下，先语音播报所述账单信息的详情，再播报第一语音提示信息以询问用户是否确认缴费。

4.根据权利要求1或3所述的方法，其中，所述方法还包括：

若接收到用户输入的语音确认指令，则播报第二语音提示信息以向用户询问支付口令。

5.根据权利要求4所述的方法，其中，所述方法还包括：

在播报第二语音提示信息以向用户询问支付口令之后，若接收到用户输入的支付口令，则将用户输入的支付口令发送给第二服务器，其中，所述第二服务器用于验证用户输入的支付口令并在验证通过时将验证通过信息发送给所述第一服务器，其中，所述第一服务器用于接收所述验证通过信息并完成对应的缴费操作。

6.一种信息处理方法，应用于服务器，包括：

获取来自电子设备的文本缴费请求，其中，所述文本缴费请求为所述电子设备在获取用户输入的语音缴费请求后对所述语音缴费请求进行语音识别得到的；以及

响应于所述文本缴费请求，并向所述电子设备返回对应的响应结果，其中，所述电子设备用于接收所述服务器返回的所述响应结果，并基于所述响应结果播报第一语音信息。

7.根据权利要求6所述的方法，其中，响应于所述文本缴费请求，并向所述电子设备返回对应的响应结果包括：

基于所述文本缴费请求，查询对应的第一账单信息；以及

将所述第一账单信息返回给所述电子设备，使得所述电子设备语音播报所述第一账单信息的详情，并播报第一语音提示信息以询问用户是否确认缴费。

8.根据权利要求7所述的方法，其中，所述方法还包括：

在将所述第一账单信息返回给所述电子设备之前，将所述第一账单信息转换为所述电子设备能够识别的第二账单信息。

9.一种电子设备，用于进行信息处理，所述电子设备包括：

第一获取模块，用于获取用户输入的语音缴费请求；

识别模块，用于对所述语音缴费请求进行语音识别，得到对应的文本缴费请求；

第一发送模块，用于将所述文本缴费请求发送给第一服务器，其中，所述第一服务器用于响应于所述文本缴费请求并向所述电子设备返回对应的响应结果；以及

处理模块，用于接收所述第一服务器返回的所述响应结果，并基于所述响应结果播报第一语音信息。

10.根据权利要求9所述的电子设备，其中，所述电子设备还包括：

判断模块，用于在获取用户输入的语音缴费请求之后，判断所述电子设备是否已开通所述缴费服务；以及

第一输出模块，用于在所述电子设备尚未开通所述缴费服务的情况下，播报第二语音信息以通知用户开通所述缴费服务再缴费。

11.根据权利要求9所述的电子设备，其中，所述处理模块还用于，在所述响应结果中包含有账单信息的情况下，先语音播报所述账单信息的详情，再播报第一语音提示信息以询问用户是否确认缴费。

12.根据权利要求9或11所述的电子设备，其中，所述电子设备还包括：

第二输出模块，用于在接收到用户输入的语音确认指令的情况下，播报第二语音提示信息以向用户询问支付口令。

13.根据权利要求12所述的电子设备，其中，所述电子设备还包括：

第二发送模块，用于在播报第二语音提示信息以向用户询问支付口令之后，若接收到用户输入的支付口令，则将用户输入的支付口令发送给第二服务器，其中，所述第二服务器用于验证用户输入的支付口令并在验证通过时将验证通过信息发送给所述第一服务器，其中，所述第一服务器用于接收所述验证通过信息并完成对应的缴费操作。

14.一种服务器，用于进行信息处理，所述服务器包括：

第二获取模块，用于获取来自电子设备的文本缴费请求，其中，所述文本缴费请求为所述电子设备在获取用户输入的语音缴费请求后对所述语音缴费请求进行语音识别得到的；以及

响应模块，用于响应于所述文本缴费请求，并向所述电子设备返回对应的响应结果，其中，所述电子设备用于接收所述服务器返回的所述响应结果，并基于所述响应结果播报第一语音信息。

15.根据权利要求14所述的服务器，其中，所述响应模块包括：

查询单元，用于基于所述文本缴费请求，查询对应的第一账单信息；以及

返回单元，用于将所述第一账单信息返回给所述电子设备，使得所述电子设备语音播报所述第一账单信息的详情，并播报第一语音提示信息以询问用户是否确认缴费。

16.根据权利要求15所述的服务器，其中，所述服务器还包括：

转换模块，用于在将所述第一账单信息返回给所述电子设备之前，将所述第一账单信息转换为所述电子设备能够识别的第二账单信息。

17.一种计算机***，包括：

一个或多个处理器；

计算机可读存储介质，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现权利要求1至5中任一项所述的信息处理方法，和/或实现权利要求6至8中任一项所述的信息处理方法。

18.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使所述处理器实现权利要求1至5中任一项所述的信息处理方法，和/或实现权利要求6至8中任一项所述的信息处理方法。