CN105306281B - 信息处理方法及客户端 - Google Patents

Abstract

本发明实施例提供一种信息处理方法及客户端，所述信息处理方法包括：采集输入语音；解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；将所述服务需求和所述第一类需求参数发送给服务器；接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

Description

信息处理方法及客户端

技术领域

本发明涉及信息技术领域，尤其涉及一种信息处理方法、客户端及服务器。

背景技术

随着技术的发展及机器对用户语音识别能力的提升，现在推出了基于机器人对话的网络服务。例如，百度的小度或度秘等机器人。用户通过自然语言向手机等终端设备输入服务需求，小度或度秘机器人在接收到服务需求后，根据服务需求进行信息搜索，在完成搜索后将能够满足所述服务需求的服务接口返回给终端。这个时候，终端上将显示各个能够提供满足该服务需求的服务接口(例如服务链接或图文信息)用户在通过浏览这些信息，通过手动输入或点击等操作，通过服务接口进入第三方服务网站，用户在该第三方服务网站输入获取该服务的需求参数。显然在这个过程中，小度或度秘等机器人尽是充当了一个语音解析及查找对应服务接口的角色，显然智能性还不够，用户操作还比较繁琐且用户满意度依然较低。

发明内容

有鉴于此，本发明实施例期望提供一种信息处理方法及客户端，至少部分解决了语音智能服务还不够智能的问题。

为达到上述目的，本发明的技术方案是这样实现的：

本发明实施例第一方面提供一种信息处理方法，所述方法包括：

采集输入语音；

解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

将所述服务需求和所述第一类需求参数发送给服务器；

接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

基于上述方案，所述接收服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息，包括：

接收所述服务器发送的服务订单；

所述方法还包括：

输出所述服务订单及支付接口；

检测支付操作；

响应所述支付操作，向所述服务器发送支付请求；

其中，所述服务订单在完成支付后生效。

基于上述方案，所述方法还包括：

在所述服务订单生效后，从服务器接收服务跟踪信息；

根据所述服务跟踪信息，输出服务提醒信息。

基于上述方案，满足所述服务需求的参数还包括第二类需求参数；

所述方法还包括：

根据历史记录信息和/或预先设置信息，生成所述第二类需求参数或所述第二类需求参数的确定策略；

将所述第二类需求参数或所述第二类需求参数的确定策略，发送给所述服务器。

基于上述方案，所述方法还包括：

输出所述第二类需求参数或所述第二类需求参数的确定策略；

检测是否同意所述确定策略的输入语音；

所述将所述第二类需求参数或所述第二类需求参数的确定策略发送给所述服务器，包括：

若检测到同意所述第二类需求参数或所述确定策略的输入语音，向所述服务器发送所述第二类需求参数或所述确定策略。

基于上述方案，所述方法还包括：

若所述输入语音中包括指定问题答复请求时，输出服务提供方的客服接口。

基于上述方案，所述接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息，包括：

接收社交服务器利用所述服务需求与对应的社交公众号交互得到的所述服务响应信息。

基于上述方案，所述接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息，包括：

接收社交服务器返回的能够满足所述服务需求的社交公众号的添加指示信息；

基于所述添加指示信息，在与所述社交服务器器的对话框中，引入所述社交公众号，形成多方对话框；所述社交公众号能够用于提供所述服务响应信息。

本发明实施例第二方面提供一种客户端，所述客户端包括：

语音采集单元，用于采集输入语音；

解析单元，用于解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

输出单元，用于当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

发送单元，用于将所述服务需求和所述第一类需求参数发送给服务器；

接收单元，用于接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

基于上述方案，所述接收单元，还用于接收所述服务器发送的服务订单；

所述输出单元，还用于输出所述服务订单及支付接口；

所述客户端还包括：

检测单元，用于检测支付操作；

所述发送单元，还用于响应所述支付操作，向所述服务器发送支付请求；

其中，所述服务订单在完成支付后生效。

基于上述方案，所述接收单元，还用于在所述服务订单生效后，从服务器接收服务跟踪信息；

所述输出单元，还用于根据所述服务跟踪信息，输出服务提醒信息。

基于上述方案，满足所述服务需求的参数还包括第二类需求参数；

所述客户端还包括：

生成单元，用于根据历史记录信息和/或预先设置信息，生成所述第二类需求参数或所述第二类需求参数的确定策略；

发送单元，用于将所述第二类需求参数或所述第二类需求参数的确定策略，发送给所述服务器。

基于上述方案，所述输出单元，还用于输出所述第二类需求参数或所述第二类需求参数的确定策略；

所述语音采集单元，还用于检测是否同意所述确定策略的输入语音；

所述发送单元，还用于若检测到同意所述第二类需求参数或所述确定策略的输入语音，向所述服务器发送所述第二类需求参数或所述确定策略。

基于上述方案，所述输出单元，还用于若所述输入语音中包括指定问题答复请求时，输出服务提供方的客服接口。

基于上述方案，所述接收单元，用于接收社交服务器利用所述服务需求与对应的社交公众号交互得到的所述服务响应信息。

基于上述方案，所述接收单元，具体用于接收社交服务器返回的能够满足所述服务需求的社交公众号的添加指示信息；

所述客户端还包括：

形成单元，用于基于所述添加指示信息，在与所述社交服务器器的对话框中，引入所述社交公众号，形成多方对话框；所述社交公众号能够用于提供所述服务响应信息。

本发明实施例提供的信息处理方法及客户端，在解析语音输入之后，确定是否至少获取了满足服务需求的第一类需求参数；若未获得满足服务需求的第一类参数，则通过输出提示信息，提示用户输入；这样用户通过多次语音的输入，就会将自己所需的货物或服务告知给客户端。客户端再将这些给到服务器，服务器根据这些信息就能直接找到用户所需的服务响应信息，并返送给客户端；客户端通过输出这些服务响应信息，方便用户查看。在这个过程中，用户不用淹没在服务提供方或货物提供方提供的各种数据中，避免了信息查看疲劳，提高了客户端的智能性及用户使用满意度。

附图说明

图1A为本发明实施例提供的第一种信息处理方法的流程示意图；

图1B为本发明实施例提供的第二种信息处理方法的流程示意图；

图2为本发明实施例提供的一种客户端的结构示意图；

图3A至图3C为基于本发明实施例所述信息处理方法的用户与小微机器人的信息交互示意图；

图4为本发明实施例提供的第三种信息处理方法的流程示意图；

图5为本发明实施例提供的第四种信息处理方法的流程示意图。

具体实施方式

以下结合说明书附图及具体实施例对本发明的技术方案做进一步的详细阐述。

实施例一：

如图1A和图1B所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：采集输入语音；

步骤S120：解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

步骤S130：当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

步骤S140：将所述服务需求和所述第一类需求参数发送给服务器；

步骤S150：接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

本实施例所述的信息处理方法可以应用于用户终端中，例如客户端中。具体的如，手机、平板电脑或可穿戴式设备等用户终端中。

在步骤S110可为当客户显示交互界面时，采集所述输入语音。这里的交互界面可如微信聊天界面等。在所述聊天界面内并没有服务提供方的各种信息，当客户端接收到输入语音之后，会在所述交互界面显示有所述提示信息或输入语音的对话框等。在本实施例中的所述显示交互界面内，并没有各种服务方的网站或广告等信息，这样就能减少对用户的信息干扰。

这里的显示交互界面可为各种社交应用的交互界面，例如，所述步骤S110具体可包括：当客户端显示社交应用的指定公众号的交互页面时，采集所述输入语音。在本实施例中在社交应用的指定公众号的交互页面来采集所述输入语音。这里的社交应用可包括微信、QQ、支付宝钱包等各种社交应用。这的指定公众号可为各种能够提供服务的社交账号，通常为公司、企业或其他组织所持有的服务号或订阅号，能够向所有的社交公众号添加后为其他社交账号提供服务。假设，这里的社交应用为微信等及时通信交互应用，这里的指定公众号即可为所述微信公众号。在所述微信公众号，微信用户能够与所述微信公众号进行信息交互。再假设，所述社交应用为QQ，所述指定公众号可为QQ服务号，在所述社交应用的指定公众号的交互页面，可指的是QQ用户与QQ服务号进行通信的对话框页面。在本实施例中所述社交应用的指定公众号的交互页面设置有语音输入控制按钮，或检测所述输入语音的检测区域等。在本实施例中若所述社交应用为微信，所述指定公众号可为小微机器人的公众账号。这样在步骤S110中可以在微信用户与小微机器人进行信息交互的页面，采集所述输入语音。这样的话，用户可以利用社交应用进行社交，同时利用所述社交应用的指定公众账号进行各种服务需求的获取等操作，提升了客户端的智能性，便捷了用户获取服务需求的操作，提高了用户使用满意度。当然本实施例所述的信息处理方法还可以与前述任意一个实施例中提供的各种技术方案结合使用。在所述步骤S150中接收服务订单，输出服务订单及支付接口等操作。

用户通过自然语音向客户端输入语音。例如“我想订机票”，这个时候客户端会识别并解析所述输入语音，形成解析结果。

根据该解析结果可解析出是否包括服务需求和需求参数。例如，“我想订机票”的输入语音中就包括订机票这一服务需求。但是订机票的起飞地址和目的地址都没有确定，机票的日期这些需求参数都没有确定。在现有技术中，将会将订机票这一需求发送给服务器，服务器将搜索各种能够提供机票订购的网站或应用程序，从而向客户端返回服务接口。用户通过该服务接口进入提供对应服务的网站或应用中，用户在填写信息来完成服务的获取。而在本实施例中，所述步骤S130中将会判断该服务需求的第一类需求参数是否完全从语音输入中获取。例如，订机票服务对应的需求参数包括起飞地址、目的地址、航班日期、航班时间、航线、航空公司等需求参数。可从需求参数中选择全部或部分所述需求参数作为所述第一类需求参数，在本实施例中选择出基本的需求参数作为所述第一类需求参数。例如，在订机票的服务需求中，可以选择起飞地址、目的地址及航班日期作为所述第一类需求参数。客户端判断出目前输入的语音中未包括全部的第一类需求参数，则输出提示信息，该提示信息可为提示语音或提示图文信息。提示用于输入需求参数。例如，客户端在接收到“我要订机票”的输入语音之后，客户端当前仅确定了服务需求，但是还未获取的任何需求参数，这个时候客户端为了引导用户通过输入需求参数，可输出“请输入起飞地址、目的地址、航班日期等信息”。用户看到该提示信息之后，自然就会根据自己的情况输入上述信息，从而使得客户端获取到需求参数。客户端可以输出一次或多次提示信息，直至至少获取到所有的第一类需求参数。在本实施例中所述服务需求可为各种类型的用户需求。

在步骤S140中，将服务需求和第一类需求参数发送给服务器。由于服务器直接接收到了服务需求和第一类需求参数，方便服务器根据所述服务需求和第一类需求参数在能够提供在所述第一类需求参数的限制下，满足所述服务需求的服务方，并根据所述服务需求和所述第一类需求参数获取对应的服务，从而形成服务响应。在步骤S150中将接收所述服务响应信息，方便用户获取所述服务。在本实施例中，显然客户端不用从服务器接收能够满足对应服务需求的服务方的服务接口，用户也不用浏览第三方的网页和应用界面等，显然简化了服务流程，减少了客户端与服务器之间的信息交互，提高了客户端的智能性及用户使用满意度。

在本实施例中所述步骤S150中接收到的服务响应信息可能不止一条，例如，服务器基于所述服务需求及所述第一类需求参数，发现在所述第一类需求参数的限制下，能够提供服务的服务方有不止一个。这个时候，所述服务响应信息可以包括多个服务方的信息及每一个服务方可提供的服务的详细信息，这个时候方便用户通过阅读在第一类需求参数等基本参数限制下，选择最适合的服务方和/或服务。虽然涉及多个服务方的选择，但是相对于现有技术中仅以服务需求提供的服务接口，客户端需要输出的信息量还是大大减少了，且用户需要阅读的信息量也大大减少了，至少去除了哪些不满足所述第一类需求参数的服务方和服务。

例如，接收的输入语音“我要下载电子书”；采用本实施例中所述信息处理方法，则客户端将判断该输入语音是否包括所有的服务需求和第一类需求参数，显然不包括需求参数。这个时候，客户端输出“请输入电子书书名和/或作者等标识信息”。这个时候，用户就会根据自己想要下载的电子书的信息，输入这些信息，客户端获取这些信息之后，将发送给服务器，服务器直接根据客户端发送的下载电子书的需求及需求参数下载对应的电子书，并下载的电子书作为所述服务响应信息的一部分发送给客户端。显然客户端通过输出提示信息，提示用户输入相对完整的获取对应服务所需的需求参数，从而直接给出服务响应信息，简化了用户操作流程，且提高了响应速率。

本实施例所述的信息处理方法，可以全部在一个信息处理界面内，该信息处理界面可以用于接收用户的语音输入，同时可以通过语音或显示方式来输出所述语音提示，并且在该信息界面内输出所述服务响应信息，这样客户端不用在多个显示界面内进行信息跳转。例如，客户端不用从语音输入界面跳转到与语音输入界面完全不同的服务方的网页页面，显然这样还能够减少客户端信息显示和处理所消耗的功耗，延长了客户端的待机时长，同时用户看到的信息处理界面，信息清晰明了，不用用户在海量的信息中查找自己需要的信息，缓解了用户视觉疲劳，提升了用户使用满意度。

值得注意的是：在本实施例中所述的服务器可以泛指一台或多台服务器，例如在图1B中就显示有至少两台服务器。这些服务器可形成服务平台。在本实施例中所述服务平台可以通过检索服务方的提供的各种信息，能够在所述第一类需求参数限制下，查找到能够满足所述服务需求的服务提供方，并形成服务响应信息，最后所述服务器在将所述服务响应信息发送给客户端。

实施例二：

如图1A和图1B所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：采集输入语音；

步骤S120：解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

步骤S130：当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

步骤S140：将所述服务需求和所述第一类需求参数发送给服务器；

步骤S150：接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

所述步骤S150可包括：

接收所述服务器发送的服务订单；

所述方法还包括：

输出所述服务订单。

在本实施例中满足所述服务需求的服务可能是有偿服务，这里的有偿服务，可为需要支付实体或虚拟货币的任何一种需要支付对价的服务。这个时候，所述客户端将直接从服务器接收服务订单。所述服务订单通常可包括根据所述服务需求及至少包括第一类需求参数形成的需求参数，生成的订单。例如，该订单为预定的10月20日从北京飞上海的服务订单。

客户端接收到所述服务订单之后，将输出所述服务订单，所述服务订单作为所述服务响应信息输出，相当于告知用户订单生成，相关服务订单已经生成。显然在这个过程中，所述客户端通过一次或多次提示信息的输出，从而提示用户输入自己服务需求的各种需求信息，服务器根据服务需求和至少第一类需求参数，就能通过与服务方之间的交互直接生成服务订单。这个操作过程，相对于现有技术客户端获取到服务订单的过程，大大的提升客户端接收到服务订单的速率，简化了用户操作，更好的利用了客户端的软硬件资源，提升了客户端的智能性及用户使用满意度。

实施例三：

如图1A和图1B所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：采集输入语音；

步骤S120：解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

步骤S130：当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

步骤S140：将所述服务需求和所述第一类需求参数发送给服务器；

步骤S150：接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

所述步骤S150可包括：

接收所述服务器发送的服务订单；

所述方法还包括：输出所述服务订单。

所述方法还包括：

在输出所述服务订单之后，输出支付接口；

检测支付操作；

响应所述支付操作，向所述服务器发送支付请求；

其中，所述服务订单在完成支付后单生效。

在本实施例中所述方法还包括，输入支付接口。该支付接口可为语音支付接口，也可以为手动支付接口。这样的话，用户可以通过语音和一键式的手动操作实现支付。

在本实施例中所述的信息处理方法中，用户可以通过与客户端的多次信息交互，就能实现服务订单的确定和支付，不用再在海量的提供服务的服务方中进行服务的人工挑选和支付，大大的提升了通过客户端下订单及进行订单支付的效率。

作为本实施例的进一步改进，当所述订单生效后，客户端会将生效订单归纳整理到记录界面，当客户端切换到记录界面之后，首先显示的最近的几个生效的订单。这些订单的服务方可能是相同的或不同的，这样用户就不用到各个服务提供方去查询看自己的订单的信息，也不用在各个服务提供方中去注册账号才能生成订单。

实施例四：

如图1A和图1B所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：采集输入语音；

步骤S120：解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

步骤S130：当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

步骤S140：将所述服务需求和所述第一类需求参数发送给服务器；

步骤S150：接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

所述步骤S150可包括：

接收所述服务器发送的服务订单；

在所述服务订单生效后，从服务器接收服务跟踪信息；

根据所述服务跟踪信息，输出服务提醒信息。

这里的服务跟踪信息，包括在服务过程中出现变更的信息，例如航班起飞提示信息及航班延误提示信息等信息，显然为用户提供了更加人性化的服务。

再比如所述服务跟踪信息可包括购物订单的发货物流信息，还包括其他订单的售后信息的跟踪等信息，这样的话，一方面能够在服务状态出现更新，及时提醒用户，另一方面的话能够通过这种提醒，让作为消费者的用户更加满意商家的服务，也简化了商家的提醒操作，更好的促进这种基于本实施例所述信息处理方法形成的交互频繁度。

实施例五：

如图1A和图1B所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：采集输入语音；

步骤S120：解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

步骤S130：当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

步骤S140：将所述服务需求和所述第一类需求参数发送给服务器；

步骤S150：接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

满足所述服务需求的参数还包括第二类需求参数；

所述方法还包括：

步骤S160：根据历史记录信息和/或预先设置信息，生成所述第二类需求参数或所述第二类需求参数的确定策略；

步骤S170：将所述第二类需求参数或所述第二类需求参数的确定策略，发送给所述服务器。

在本实施例中所述需求参数还包括第二类需求参数，该第二类需求参数可为不那么重要的需求参数。例如，订机票过程中的航空公司。在本实施例中所述客户端还会根据用户信息和/或预先设置的第二需求参数设置策略和/或历史记录信息来生成第二类需求信息。

例如，航班时间信息，所述客户端可以根据历史记录信息，确定用户在晚上飞的概率大还是在晚上飞的概率大，确定所述航班时间信息。例如，用户从未在晚上飞过，可认为用户不喜欢晚上的航班，可确定航班时间为白天的时间段内。显然，这是一种简便确定所述第二类需求参数的方式。

再比如，预先设置信息可为实现根据用户指示设置的信息。再以航班时间信息为例，用户A经常出差，一般情况下用户A都习惯白天飞，为了简化后续定航班的，用户可以在客户端内将航班时间信息默认设置为白天的时间段。这样的话，也简便的根据用户信息确定了航班时间信息。

例如，根据历史信息记录发现确定出所述航班时间信息比较零散，从时间规律性来规律性很小，但是却发历史记录中航班时间信息都为价格最低航班的航班时间。这个时候，可以生成航班时间信息选择策略，该策略为选择价格最低航班的航班时间信息作为所述航班时间信息。客户端将所述第二类需求参数的确定策略发送给服务器，则服务器在进行航班预定时，显然可以根据所述确定策略确定所述第二类需求参数。

本实施例中所述客户端还会智能的确定第二类需求参数或第二类需求参数的确定策略，并将第二类需求参数或第二类需求参数的确定策略发送给服务器，这样方便服务器直接根据所述第二类需求参数或第二类需求参数的确定策略来获取服务响应信息；再次提高了客户端的智能性及用户使用满意度。

当然本实施例所述的信息处理方法，可以与前述任意一个信息处理方法结合使用，例如所述客户端还会从服务订单和/或输出支付接口等操作，从而方便用户在一个操作界面内完成预定对应服务或获取对应服务的所有操作。

实施例六：

如图1A和图1B所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：采集输入语音；

步骤S120：解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

步骤S130：当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

步骤S140：将所述服务需求和所述第一类需求参数发送给服务器；

步骤S150：接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

满足所述服务需求的参数还包括第二类需求参数；

所述方法还包括：

步骤S160：根据历史记录信息和/或预先设置信息，生成所述第二类需求参数或所述第二类需求参数的确定策略；

步骤S170：将所述第二类需求参数或所述第二类需求参数的确定策略，发送给所述服务器。

在本实施例中，为了明确第二类参数和第二类参数的确定策略是否是用户期待的，在本实施例中所述方法还包括：

输出所述第二类需求参数或所述第二类需求参数的确定策略；

检测是否同意所述确定策略的输入语音；

所述步骤S170可包括：

若检测到同意所述第二类需求参数或所述确定策略的输入语音，向所述服务器发送所述第二类需求参数或所述确定策略。

在本实施例中所述输出所述第二类需求参数或所述确定策略，优选采用显示输出的方式，当然也可以语音输出。在本实施例中还检测所述是否同意所述确定策略的输入语音。在步骤S170中在检测到表示用户同意上述第二类需求参数或确定策略的指定之后，才向所述服务器发送所述第二类需求参数或确定策略。这样就确保了第二类需求参数或确定策略是用户期待的。若步骤S160中解析输入语音发现用户表示不同意，所述客户端可以输出提示信息，提示用户给出第二类需求参数或给出确定策略。当然客户端也可以解析表示不同意的输入语音确定出用户期望的第二类需求参数或所述确定策略。例如，航班时间信息，客户端给出的时间为早上7：30至12：30优先，用户看到之后输入自然语音，将航班时间信息修改为下午3：00至7：30优先。该语音输入显然暗含了两层意思，首先不同意客户端自行确定的第二类需求参数，同时用户期望的航班时间信息为下午3：00至7：30优先。这个时候，所述客户端可以根据语输入语音调整所述第二类需求参数，将调整后的第二类需求参数发送给服务器。

再比如，第二类需求参数的确定策略为价格最低优先策略，这个时候用户看到了客户端输出的价格最低优先策略，认可可能航班会很晚，旅行不会太舒适，输入语音“将价格最低优先策略更改为白天时间段优先策略”。显然该输入语音也否定了所述确定策略，并给出了用户期望的确定策略。

当然在具体的实现过程中，所述客户端也可以不向服务器发送第二类需求参数或所述第二类需求参数的确定策略，由服务器自行确定第二类需求参数或第二类需求参数的确定策略，或者服务器不理会第二类需求参数，向客户端发送在第一类需求参数限制下的多个服务方等响应信息。

总之客户端将直接确定所述第二类需求参数或协助所述服务器确定所述第二类参数，方便服务器快速的确定服务响应。

实施例七：

如图1A和图1B所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：采集输入语音；

步骤S120：解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

步骤S130：当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

步骤S140：将所述服务需求和所述第一类需求参数发送给服务器；

步骤S150：接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

所述方法还包括：

若所述输入语音中包括指定问题答复请求时，输出服务提供方的客服接口。

在本实施例中为了避免一些特殊情况下，在设备或服务平台无法通过设备之间的交互和设备的信息查询来给用户提供其所需要的服务或信息时，这个时候为了方便用户操作，所述客户端将输出服务提供方的客服接口，该客服接口可用于直接联系到提供该项服务的人工呼叫平台等设备。例如，在微信等即时通信社交平台中输出的客服接口的联系电话，这样的话，用户看到该联系电话之后，就能够通过拨打该联系电话去了解自己想要的信息。

在本实施例中所述客服接口可为直连触发接口，在所述交换界面显示了所述客户服接口之后，用户通过语音说出“确定连接客服”或者点击所述客服接口，这个时候客户端将连接到服务提供方的人工平台。例如，假设本实施例中所述交互界面为微信界面，若微信界面显示了所述客服接口，然后检测到用户点击了所述客服接口，则通过建立该当前微信用户与服务提供方的微信之间的文字、语音和/或视频通话；方便用户获得人工服务。

实施例八：

如图1A和图1B所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：采集输入语音；

步骤S120：解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

步骤S130：当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

步骤S140：将所述服务需求和所述第一类需求参数发送给服务器；

步骤S150：接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

所述步骤S150的实现方法有多种，以下提供两种可实现方式：

第一种：所述步骤S150可包括：

接收社交服务器利用所述服务需求与对应的社交公众号交互得到的所述服务响应信息。

本实施例所述方法应用于客户端，客户端是与社交服务器进行信息交互，在社交平台中包括一个或多个社交服务器，本实施例所述社交服务器可为运行小微机器人等提供这种信息处理的社交服务器。本实施例所述中所述服务器在接收到所述服务需求及第一类需求参数之后，将自动查询运行在其所在的社交平台内的各种社交公众号。这里的社交公众号可包括订阅号和服务号等能够满足各种服务需求的社交账号。

所述社交服务器在后台与社交公众号进行信息交互，得到满足所述服务需求的服务响应信息。这样的话，对于客户端而言在将诶手到所述服务响应信息之后，将直接显示所述服务响应信息，而对于社交服务器与社交公众号之间的交互对于客户端来说是透明的。但是这样，所述社交服务器就很好的利用了社交平台的平台资源，能够提升资源整合率，和信息处理效率。

第二种：

所述步骤S150可包括：

接收社交服务器返回的能够满足所述服务需求的社交公众号的添加指示信息；

基于所述添加指示信息，在与所述社交服务器器的对话框中，引入所述社交公众号，形成多方对话框；所述社交公众号能够用于提供所述服务响应信息。

在本实施例中所述社交服务器根据所述服务需求及所述第一类需求参数，查找到对应的社交公众号，向客户端发送添加所述社交公众号添加指示信息，这样在客户端与服务器的对方框中就引入了能够满足服务需求的社交公众号，社交公众号，可以直接参与客户端与社交服务器的对话，并及时的向客户端提供服务响应信息。在具体实现时，所述社交公众号被添加到对话框或对话页面之后，会直接基于所述服务需求和所述第一类需求参数提供对应的服务响应消息，或在简短的信息介绍之后，将同样基于服务需求和第一类需求参数提供对应的服务响应消息，以简化交互流程，提升交互的便捷性。在具体的实现过程中，例如社交公众号加入对话框之后的第一条消息可为招呼消息，用于社交公众号的简介，第二条消息即可为服务需求和第一类需求参数提供对应的服务响应消息。当然，所述社交公众号在加入对话框之后发送的第一条消息的前S个字内是简介消息，随后就是服务需求和第一类需求参数提供对应的服务响应消息。

总之，本实施例提供了至少两种所述客户端获取的服务响应信息的信息来源或信息获取方式，具有实现简单，信息处理效率高等特点。

实施例九：

如图2所示，本实施例提供了一种客户端，所述客户端包括：

语音采集单元110，用于采集输入语音；

解析单元120，用于解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

输出单元130，用于当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

发送单元140，用于将所述服务需求和所述第一类需求参数发送给服务器；

接收单元150，用于接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

本实施例中所述的客户端可对应于各种类型的终端设备，例如，手机、平板、可穿戴式设备等具有通信功能的电子设备。

所述语音采集单元110可包括录音器等采集声音的结构。具体地，所述语音采集单元110，具体用于当客户端显示社交应用的指定公众号的交互页面时，采集所述输入语音。在本实施例中，所述语音采集单元110在客户端显示社交应用的指定公众好的交互页面时，采集所述输入语音，这样的话，所述客户端将利用所述社交应用的指定公众号来获取所述服务需求的响应。这里的社交应用可包括前述提到的微信、QQ或社区等提供社交服务的应用。所述交互页面，可对应于微信的对话页面，或QQ的对话框页面。这样的话，本实施例所述的客户端能够方便用户一边利用社交应用进行社交，另一方面能够方便利用社交应用满足用户的其他需求。

所述解析单元120可对应于处理器或处理电路；所述处理器可包括中央处理器、微处理器、数字信号处理器、可编程阵列等处理结构。所述处理电路可包括专用集成电路。所述处理器或处理电路可通过执行指定代码完成对所述输入语音的解析，该输出语音可为用户输入的自然语句。解析单元120通过解析自然语句提取用户输入语音中的语义，从而确定出服务需求及各类需求参数等。

在本实施例中所述输出单元130可对应于显示屏，这里的显示屏可包括液晶显示屏、电子墨水显示屏、投影显示屏或有机发光二级管OLED显示屏等显示结果。所述输出单元130还可对应于语音输出结构，这里的语音输出结构可包括扬声器、耳麦输出电路等结果，能够输出音频的各种结果。

本实施例所述发送单元140和接收单元150都对应着各种通信接口，这里的通信接口可包括电缆接口、光缆接口或收发天线等能够交互数据的结构；具体如，WiFi天线等。

本实施例所述的客户端在采集的输入语音没有包括必要的服务需求及基本的第一类需求参数时，将通过输出提示信息，提示用户继续输入所需的信息，直至包括了所述第一类需求参数，这样的话，服务器自然就可以根据所述服务需求和第一类需求参数自动生成订单或提供服务等。本实施例所述的客户端在进行信息交互的同时，能够简化基于语音服务响应信息，这样可以更加便捷的实现人机交互，提高了客户端的智能性及用户使用满意度。

实施例十：

如图2所示，本实施例提供了一种客户端，所述客户端包括：

语音采集单元110，用于采集输入语音；

解析单元120，用于解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

输出单元130，用于当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

发送单元140，用于将所述服务需求和所述第一类需求参数发送给服务器；

接收单元150，用于接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

所述接收单元140，还用于接收所述服务器发送的服务订单；

所述输出单元130，还用于输出所述服务订单。

在本实施例中所述服务器将可能根据所述服务需求和所述第一类需求参数等生成服务订单；这样所述客户端还会从服务器接收所述服务订单并输出订单，这样的用户可以从服务订单知道获取的服务的各种信息，例如服务提供方、支付方式等各种信息。这样的话，用户通过语音在自己不用流量大量的服务提供方的页面下就能够完成服务下单。当然这里的服务订单订购各种货物及服务等。例如，用户预定电影票，用户可向本实施例中所述的客户端说出“我要看电影《xxx》等”；若在客户端中默认设置的第一类需求参数还包括影院地址的话，则所述客户端的输出单元130会输出“请输入想看电影的影院范围”。这样的用户可能在北京海淀北四环附近，客户端检测到了上述语音，则会把电影名称、影院的地址范围发送给服务器；服务器可能会根据电影名称及所述地址范围检测到适合可以提供对应电影观影的影院的名录等服务响应信息给到客户端，客户端输出上述信息，客户端可以通过与用户的再次语音交互，可以最终确定选择哪一家影院预定电影票。这样的话，能够简化用户操作，更好的利用客户端的软硬件资源，提高客户端软硬件资源的利用率及客户端的智能性。

实施例十一：

如图2所示，本实施例提供了一种客户端，所述客户端包括：

语音采集单元110，用于采集输入语音；

解析单元120，用于解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

输出单元130，用于当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

发送单元140，用于将所述服务需求和所述第一类需求参数发送给服务器；

接收单元150，用于接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

所述接收单元140，还用于接收所述服务器发送的服务订单；

所述输出单元130，还用于输出所述服务订单及支付接口；

所述客户端还包括：

检测单元，用于检测支付操作；

所述发送单元，还用于响应所述支付操作，向所述服务器发送支付请求；

其中，所述服务订单在完成支付后生效。

在本实施例中通过所述服务订单，表示已经向服务提供方或货物提供方下了订单，这个时候订单是否生效可能还需要支付。故在本实施例中所述客户端将输出所述服务订单。这样的话，用户就可以看到待支付的服务订单及支付接口。若用户看到所述服务订单之后，认为所述服务订单提供的服务满意，则可以通过所述输出单元130输出的所述支付接口实现一键支付等操作，通常支付之后所述订单生效。显然采用本实施例所述的客户端形成一个服务订单，并且使订单生效时，用户不用在服务方提供的海量信息中去一一浏览或注意检索，这样减少了用户的操作疲劳，提高了客户端的智能性及用户使用满意度。利用本实施例所述的客户端，用户只需将自己的服务需求及满足这些服务需求的需求参数(这的需求参数至少包括第一类需求参数)说出来，客户端将通过语音采集等操作，通过与服务器的一次或多次信息交互完成订单的生成和生效。

实施例十二：

如图2所示，本实施例提供了一种客户端，所述客户端包括：

语音采集单元110，用于采集输入语音；

解析单元120，用于解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

输出单元130，用于当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

发送单元140，用于将所述服务需求和所述第一类需求参数发送给服务器；

接收单元150，用于接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

所述接收单元150，还用于在所述服务订单生效后，从服务器接收服务跟踪信息；

所述输出单元130，还用于根据所述服务跟踪信息，输出服务提醒信息。

在本实施例中所述接收单元150还将在所述服务订单生效后，从服务器接收服务跟踪信息，并由所述输出单元130输出服务跟踪信息这样更好的为用户提供服务。显然在本实施例中所述客户端可以通过一个服务界面，通过采集语音的用户的输入语音就能够完成各种服务订单的生成及生效等操作，并且会从服务器获取服务跟踪信息。这样的话，用户可以在一个服务界面查看各个服务订单的状态；避免了用户在多个服务提供方所在的页面之间的切换。

实施例十三：

如图2所示，本实施例提供了一种客户端，所述客户端包括：

语音采集单元110，用于采集输入语音；

解析单元120，用于解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

输出单元130，用于当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

发送单元140，用于将所述服务需求和所述第一类需求参数发送给服务器；

接收单元150，用于接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

满足所述服务需求的参数还包括第二类需求参数；

所述客户端还包括：

生成单元，用于根据历史记录信息和/或预先设置信息，生成所述第二类需求参数或所述第二类需求参数的确定策略；

发送单元，用于将所述第二类需求参数或所述第二类需求参数的确定策略，发送给所述服务器。

本实施例所述生成单元可对应于处理器或处理电路等结构，所述第二类需求参数可为所述第一类需求参数以外的能够确定服务订单生成的参数。且所述第二类需求参数可能为用户不是十分关注的信息。例如，在机票的预定过程中，用户可能不太关注航空公司。但是某些用户可能是某一个航空公司的金卡会员等，这个时候所述客户端中可能记录有用户设置的所述金卡会员的会员号、航空公司等信息，这个时候所述生成单元，可根据会员号及航空公司等信息，确认A航空公司作为所述第二类需求参数。这个时候，所述客户端会将A航空公司作为第二类需求参数发送给服务器，这样服务器将会在预定机票时确定预定A航空公司的机票或优先预定A航空公司的机票。所述第二类需求策略可包括例如折扣最多，时间做早策略等等信息。这里的历史记录信息为用户同一类服务需求的历史记录信息。例如，当前时间为10月30日，则这里的历史记录信息可为10月30日以前的用户预定航班的信息。这里的预先设置信息，例如用户在预定电影票时，事先在客户端中设置有电影院的区域信息等。

总之，本实施例为了减少用户与客户端之间的交互次数，在本实施例中所述客户端还可以通过历史记录信息和预先设置信息的至少其中之一，来直接确定所述第二类需求参数或第二类需求参数的确定策略。所述发送单元140将所述第二类需求参数与所述第二类需求参数的确定策略，这样方便服务器更快更便捷的形成服务订单。

实施例十四：

如图2所示，本实施例提供了一种客户端，所述客户端包括：

语音采集单元110，用于采集输入语音；

解析单元120，用于解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

输出单元130，用于当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

发送单元140，用于将所述服务需求和所述第一类需求参数发送给服务器；

接收单元150，用于接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

满足所述服务需求的参数还包括第二类需求参数；

所述客户端还包括：

生成单元，用于根据历史记录信息和/或预先设置信息，生成所述第二类需求参数或所述第二类需求参数的确定策略；

发送单元140，用于将所述第二类需求参数或所述第二类需求参数的确定策略，发送给所述服务器。

所述输出单元130，还用于输出所述第二类需求参数或所述第二类需求参数的确定策略；

所述语音采集单元110，还用于检测是否同意所述确定策略的输入语音；

所述发送单元140，还用于若检测到同意所述第二类需求参数或所述确定策略的输入语音，向所述服务器发送所述第二类需求参数或所述确定策略。

在本实施例中为了获得一次性生成更能精确满足用户所需的服务订单，在本实施例中所述输出单元130将输出所述第二类需求参数或所述第二类需求参数的确定策略，并通过所述语音采集单元110采集用户的输入语音，在用户同意所述第二类需求参数或所述第二类需求参数的确定策略之后，向服务器发送所述第二类需求参数或确定策略。这样可以减少所述第二类需求参数或确定策略出现错误的概率。

实施例十五：

如图2所示，本实施例提供了一种客户端，所述客户端包括：

语音采集单元110，用于采集输入语音；

解析单元120，用于解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

输出单元130，用于当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

发送单元140，用于将所述服务需求和所述第一类需求参数发送给服务器；

接收单元150，用于接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

所述输出单元130，还用于若所述输入语音中包括指定问题答复请求时，输出服务提供方的客服接口。

在本实施例中所述输出单元130还可以输出客服接口，这样的话，用户可以通过所述客户端获得自己客服接口，可供用户确定是否需要联系到客服接口。

总之本实施例所述的客户端不仅能够通过检测用户的输入语音和提示信息的输出获取到服务需求及第一类需求参数和/或第二类需求参数，自动到各个服务方提供的数据中获取到服务响应信息，同时还会能够根据用户指示，从服务器查找到所述客服接口，方便用户利用所述服务接口与服务提供方的人工平台建立连接，获得人工服务。

实施例十六：

如图2所示，本实施例提供了一种客户端，所述客户端包括：

语音采集单元110，用于采集输入语音；

解析单元120，用于解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

输出单元130，用于当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

发送单元140，用于将所述服务需求和所述第一类需求参数发送给服务器；

接收单元150，用于接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息。

以下提供两种所述接收单元150的具体结构：

结构一：所述接收单元150，用于接收社交服务器利用所述服务需求与对应的社交公众号交互得到的所述服务响应信息。在这种结构中首先由社交服务器与社交公众号进行交互，得到服务响应信息，再由社交服务器向客户端转发所述服务响应信息。

结构二：所述接收单元150，具体用于接收社交服务器返回的能够满足所述服务需求的社交公众号的添加指示信息；所述客户端还包括：形成单元，用于基于所述添加指示信息，在与所述社交服务器器的对话框中，引入所述社交公众号，形成多方对话框；所述社交公众号能够用于提供所述服务响应信息。在本实施例中所述社交服务器根据所述服务需求及第一类需求参数定位到在满足所述第一类需求参数的限制条件下还可以提供对应社交公众号，将社交公众号添加到对话框中，由所述社交公众号直接提供所述服务响应消息，避免消息的中转，同时响应了客户端的服务需求。

以上两种接收单元150均具有结构简单，更好的利用了社交平台的平台资源等特点。

以下基于上述任意实施例提供几个具体示例：

示例一：

图3A至图3C展示的利用微信平台的小微机器人进行计票预定的流程图。在图3A至图3C中为了方便显示，将用户利用语音输入的内容，用文字的形式展示出来了。在图3A至图3C中，小微指代的是微信的小微机器人。另一个图标指代的是用户。

在图3A中用户对着手机或平板电脑中的微信界面语音输入“你好，我想预定从北京到广州的机票”。小微机器人将解析该输入语音，发现缺少机票的日期；这个时候小微输出提示信息：请问您预订哪天的机票，有其他要求吗？用户看到提示之后，自然会把机票的日期及自己的其他要求一并通过语音告诉微信。这个时候用户输入“后天吧，别太早的，我起不来，最好是折扣多的那种。”小微机器人通过对该自然语音的解析，确定机票的日期为2015-11-1，按照价格最低及时间优先原则机型订票。微信将预定2015-11-1从北京到广州的机票及不需要太早的信息传输给服务器，服务器通过查询服务提供方的提供的各种航班信息，返回了三条航班信息。这三条航班信息分别如图3A所示。为了避免用户对服务器优先推荐的3条航班信息都不满意，还设置有查看其它航班信息的接口信息。若微信检测到用户点击了对应的区域，则微信从服务器获取其他满足从北京到广州，日期在11月1日的航班信息。在图3A中用户的输入语音为：11点的那个就行。微信通过解析确定选择了从11：10分从手段机场T2起飞，14：00到白云机场降落，价格为906元的航班。这个时候需要进行航班预订，需要乘客的一些个人信息。如图3B所示，小微显示提示信息：好的，请把登机人的姓名、身份证号码和手机号码发给我，我帮您记录下登机信息。用户通过语音告诉微信登机人的信息。接下来，涉及到一些关于用户利用的其他提示信息。这样微信的小微机器人和用户通过多次的对话，能够方便用户在不用浏览服务提供方的服务页面的基础上，完成机票的预定。最终在图3C中，输出订单信息及支付接口。在本示例中，所述图3C输出的微信支付的支付接口。用户通过点击所述微信支付，就可以通过微信完成对该订单的支付，从而使该机票订单生效，完成了机票的预定。

显然，本示例的机票预定过程中，用户仅是在微信界面内通过与小微机器人的多次对话，就完成了机票的预定，用户根本就不用浏览机票预定网站或在海量的信息中查找自己所需的信息，简化了满足用户的服务需求的操作流程，提高了客户端的智能性及用户使用满意度。

示例二：

如图4所示，本示例提供一种信息处理方法，所述方法包括：

步骤S11：从用户处接收服务需求；

步骤S12：与用户进行多轮对话。

步骤S13：基于多轮对话与第三方数据接口或通用知识库进行信息交互，获得服务响应信息。这里的第三方数据接口可包括服务方或信息提供方网站或服务器的接口。

步骤S14：判断用户是否有特殊需求，若有进入步骤S15，如无进入步骤S16。

步骤S15：获取用户资料信息，例如服务器或客户端通过查询本地数据库，获取实现存储的信息，或通过与用户的交互获取所述用户资料信息。

步骤S17：生成订单。

步骤S18：客户端从服务器接收到订单，并输出订单，这样用户就能够看到订单。显然这样的话，用户在不用查看进入服务提供方的服务页面的情况下，就能够完成下单和订单的生成。

示例三：

如图5所示，本示例提供一种信息处理方法，在本实施例中以小微航班为例，这里的小微航班可为利用小微机器人预定航班的一种专项服务。在这里预定航班可包括4个阶段；第一阶段为开始；第二阶段为查询；第三阶段为形成订单；第四阶段为后续服务。

在第一阶段中，将获得买家需求；这里的买家需求即为用户需求。

在第二阶段中，将获取到起始地址、达到地址和出发日期作为所述第一类需求信息；当然也会获取航班时间、航班价格及其他非基本的第二类需求参数的确定策略。图5中的确定策略为:价格时间比最优的选择。

在第三阶段中，首先确定需求，这里确定是机票预定需求，则填写订单。包括个人信息的填写。这里的个人信息包括身份证号和手机号等。当然还可以包括发票信息以及延误险、意外险等。当然在第三阶段还会再次确认填写的信息是否正确。若确认信息正确，则进入第四阶段。

在第四阶段中包括订单支付、出发前提醒、延误险兑现及发票邮寄查询等各种后续跟踪服务。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (14)

1.一种信息处理方法，其特征在于，应用于同一信息处理界面中，所述方法包括：

在社交应用的交互界面中采集输入语音；

解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出至少一次提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

将所述服务需求和所述第一类需求参数发送给服务器；

接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息；

所述方法还包括：若所述输入语音中包括指定问题答复请求时，输出服务提供方的客服接口。

2.根据权利要求1所述的方法，其特征在于，

所述接收服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息，包括：

接收所述服务器发送的服务订单；

所述方法还包括：

输出所述服务订单及支付接口；

检测支付操作；

响应所述支付操作，向所述服务器发送支付请求；

其中，所述服务订单在完成支付后生效。

3.根据权利要求2所述的方法，其特征在于，

所述方法还包括：

在所述服务订单生效后，从服务器接收服务跟踪信息；

根据所述服务跟踪信息，输出服务提醒信息。

4.根据权利要求2或3所述的方法，其特征在于，

满足所述服务需求的参数还包括第二类需求参数；

所述方法还包括：

根据历史记录信息和/或预先设置信息，生成所述第二类需求参数或所述第二类需求参数的确定策略；

将所述第二类需求参数或所述第二类需求参数的确定策略，发送给所述服务器。

5.根据权利要求4所述的方法，其特征在于，

所述方法还包括：

输出所述第二类需求参数或所述第二类需求参数的确定策略；

检测是否同意所述确定策略的输入语音；

所述将所述第二类需求参数或所述第二类需求参数的确定策略发送给所述服务器，包括：

若检测到同意所述第二类需求参数或所述确定策略的输入语音，向所述服务器发送所述第二类需求参数或所述确定策略。

6.根据权利要求1或2所述的方法，其特征在于，

所述接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息，包括：

接收社交服务器利用所述服务需求与对应的社交公众号交互得到的所述服务响应信息。

7.根据权利要求1或2所述的方法，其特征在于，

所述接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息，包括：

接收社交服务器返回的能够满足所述服务需求的社交公众号的添加指示信息；

基于所述添加指示信息，在与所述社交服务器的对话框中，引入所述社交公众号，形成多方对话框；所述社交公众号能够用于提供所述服务响应信息。

8.一种客户端，其特征在于，应用于同一信息处理界面中，所述客户端包括：

语音采集单元，用于在社交应用的交互界面中采集输入语音；

解析单元，用于解析所述输入语音，确定服务需求及满足所述服务需求的第一类需求参数；

输出单元，用于当确定出至少有一个所述第一类需求参数不包括在输入语音中时输出至少一次提示信息，直至获取到满足所述服务需求的所有所述第一类需求参数；

发送单元，用于将所述服务需求和所述第一类需求参数发送给服务器；

接收单元，用于接收所述服务器基于所述服务需求及所述第一类需求参数返回的服务响应信息；

所述输出单元，还用于若所述输入语音中包括指定问题答复请求时，输出服务提供方的客服接口。

9.根据权利要求8所述的客户端，其特征在于，

所述接收单元，还用于接收所述服务器发送的服务订单；

所述输出单元，还用于输出所述服务订单及支付接口；

所述客户端还包括：

检测单元，用于检测支付操作；

所述发送单元，还用于响应所述支付操作，向所述服务器发送支付请求；

其中，所述服务订单在完成支付后生效。

10.根据权利要求8或9所述的客户端，其特征在于，

所述接收单元，还用于在所述服务订单生效后，从服务器接收服务跟踪信息；

所述输出单元，还用于根据所述服务跟踪信息，输出服务提醒信息。

11.根据权利要求8或9所述的客户端，其特征在于，

满足所述服务需求的参数还包括第二类需求参数；

所述客户端还包括：

生成单元，用于根据历史记录信息和/或预先设置信息，生成所述第二类需求参数或所述第二类需求参数的确定策略；

发送单元，用于将所述第二类需求参数或所述第二类需求参数的确定策略，发送给所述服务器。

12.根据权利要求11所述的客户端，其特征在于，

所述输出单元，还用于输出所述第二类需求参数或所述第二类需求参数的确定策略；

所述语音采集单元，还用于检测是否同意所述确定策略的输入语音；

所述发送单元，还用于若检测到同意所述第二类需求参数或所述确定策略的输入语音，向所述服务器发送所述第二类需求参数或所述确定策略。

13.根据权利要求8或9所述的客户端，其特征在于，

所述接收单元，用于接收社交服务器利用所述服务需求与对应的社交公众号交互得到的所述服务响应信息。

14.根据权利要求8或9所述的客户端，其特征在于，

所述接收单元，具体用于接收社交服务器返回的能够满足所述服务需求的社交公众号的添加指示信息；

所述客户端还包括：

形成单元，用于基于所述添加指示信息，在与所述社交服务器的对话框中，引入所述社交公众号，形成多方对话框；所述社交公众号能够用于提供所述服务响应信息。