一种多业务节点型业务的处理方法及装置与流程

文档序号:12278818阅读:197来源:国知局
一种多业务节点型业务的处理方法及装置与流程

本申请涉及互联网技术领域,尤其涉及一种多业务功能节点型业务的处理方法及装置。



背景技术:

随着互联网技术的发展,越来越多的业务可以通过各种类型的终端设备进行线上业务处理,比如,通过互联网注册账号后获取有关信息推送服务;身份认证后开启某项业务功能;登录账号后修改下一业务周期的预付费业务等。在线上处理的众多业务中,实现某些业务往往不止需要一个业务指令(或进行一次操作、或回答一个问题等),而可能需要按照预定的业务流程完成多个业务指令(或进行多次操作、或回答多个问题等),才能达到最终的业务目的,这种业务属于多业务节点型业务。

在现有技术中,一种处理多业务节点型业务的方法是:预设业务的整套流程,该整套流程中包含多个业务节点,每个业务节点对应某个业务指令,当用户在一个页面中处理完一个业务节点对应的业务指令后,加载业务流程指向的下一个业务节点对应的页面,用户又在该新加载的页面中完成业务节点对应的业务指令如此进行下去,直到处理完成所有业务,从而达到对多业务节点型业务进行处理的目的。

上述这种方法虽然能够实现多业务节点型业务的处理,但是,如果多业务节点型业务的业务节点越多,则需要加载的页面就越多,而每次加载页面都会耗费时间,从而使得处理完整业务所耗费的总时长就越长,降低了业务处理效率。此外,在需要服务器协助业务处理的情形下,如果网络质量不佳,将会使页面加载时间更长,进一步降低了业务处理效率。



技术实现要素:

本申请实施例提供一种多业务节点型业务的处理方法,用于提高多业务节点型业务处理效率。

本申请实施例提供一种多业务节点型业务的处理装置,用于提高多业务节点型业务处理效率。

本申请实施例采用下述技术方案:

一种多业务节点型业务的处理方法,所述多业务节点型业务包含按照预设业务流程确定的至少两个业务节点,在预设业务流程上的全部业务节点对应的业务指令处理完后,实现对多业务节点型业务的处理,其中,对预设业务流程上的至少两个业务节点按照如下方式处理:在一个页面中对预设业务流程上的一个业务节点对应的业务指令进行处理;根据预设业务流程确定所述一个业务节点的下一个业务节点;当所述一个业务节点对应的业务指令处理完后,在所述页面中对所述下一个业务节点对应的业务指令进行处理。

一种多业务节点型业务的处理装置,所述多业务节点型业务包含按照预设业务流程确定的至少两个业务节点,所述装置包括:第一处理单元、业务确定单元、第二处理单元、业务判断单元,其中,所述第一处理单元,用于在一个页面中对预设业务流程上的一个业务节点对应的业务指令进行处理;所述业务确定单元,用于根据预设业务流程确定所述一个业务节点的下一个业务节点;所述第二处理单元,用于当所述一个业务节点对应的业务指令处理完后,在所述页面中对所述下一个业务节点对应的业务指令进行处理;所述业务判断单元,用于判断预设业务流程上的全部业务节点对应的业务指令是否处理完毕,如果是,则结束流程,如果否,则调用业务确定单元。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:由于将多业务节点型业务中的每个业务节点对应的业务指令,都在同一个页面中进行处理,在业务过程中,无需创建新的页面,即可在一个页面中展示所有业务节点的完成过程,从而省去了现有技术中,每个业务节点都需要加载的页面消 耗时间,提高了对多业务节点型业务处理效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:

图1为多业务节点型业务的处理方法流程示意图;

图2-1为现有技术提供的一种多业务节点型业务的处理方法具体实现流程示意图;

图2-2为本申请实施例1提供的一种多业务节点型业务的处理方法具体实现流程示意图;

图2-3为本申请实施例1提供的处理一个业务节点对应的问题的截图;

图2-4为本申请实施例1提供的处理一个业务节点对应的操作的截图;

图2-5为本申请实施例1提供的处理下一个业务节点对应的问题的截图;

图2-6为本申请实施例1提供的处理下一个业务节点对应的操作的截图;

图2-7为本申请实施例1提供的完成业务的处理的截图;

图2-8为本申请实施例1提供的完成业务的处理的截图;

图3为本申请实施例2提供的一种多业务节点型业务处理装置的具体结构示意图;

图4为本申请实施例3提供的一种多业务节点型业务处理方法的示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施 例,都属于本申请保护的范围。

在进行本申请的技术方案的详细介绍之前,为了明确起见,这里先对几个术语作简要说明。在本申请实施例中将涉及联系人页面、联系人列表等术语,其中,“业务指令”,可以表示一种特定的操作、对问题的回答等,是指在一个业务节点上需要完成某个指令。如图1所示,为某一多业务节点型业务的流程示意图,其中,业务指令1~4为每个业务节点对应的业务指令,业务指令可以是操作或问题,当完成4个业务指令,业务结束后,会根据操作的完成情况,对于问题的回答情况,得出成功或失败的结果。“页面”,可以包括两种情况,一是不需要网络参与的,比如,一个页面跳转到本地的另一个页面;二是需要网络的参与,即一个网络页面跳转到另一个网络页面;“加载”,也可以包括两种含义,对应于第一种页面,可以是从本地内存中加载页面,对于第二种网络页面,可以表示从网络下载并呈现出网络页面。

以下结合附图,详细说明本申请各实施例提供的技术方案。

实施例1

如前文所述,现有技术中,当用户处理某个多业务节点型业务时,每个业务节点对应的某个业务指令,都存在一个新的页面来承载,当用户通过终端在一个页面中处理完一个业务节点对应的业务指令后,终端就会加载业务流程指向的下一个业务节点对应的页面,如图2-1所示,每个业务节点对应的业务指令都需要在不同的页面中显示,即每处理一个业务节点,就会加载该业务节点相应的页面,业务节点越多,需要加载的页面就越多。如果从本地内存中加载页面,就需要事先将所有的页面内容都缓存在本地,以便在处理过程中,提升加载速度,但即使这样,加载也需要消耗时间,以及处理资源;如果从网络下载并呈现出网络页面,在每次处理不同业务节点时都要消耗下载、呈现页面的时间,这两种方式都会降低业务处理效率。此外,在需要服务器协助业务处理的情形下,如果网络质量不佳,将会使页面加载时间更长,进一步降低了业务 处理效率;并且,在需要本地终端协助业务处理的情形下,如果处理性能不佳,还将会使页面加载时间更长,更进一步降低了业务处理效率。对于用户一侧,如果消耗时间过长,就会增加用户的烦躁情绪,不利于这种多业务节点型业务的完成。本申请提供一种多业务节点型业务的处理方法,用于提高多业务节点型业务的处理效率。该方法的具体流程示意图如图2-2所示,包括下述步骤:

步骤11,在一个页面中对预设业务流程的一个业务节点对应的业务指令进行处理;

针对步骤11而言,由于本发明是针对多业务节点型业务的处理方法,所以,多业务节点型业务包含按照预设业务流程确定的至少两个业务节点。

在前文对术语作简要说明时,已经介绍了“业务指令”,可以表示一种特定的操作、对问题的回答等。所以,业务指令可以为请求提供完成业务所需要的信息,或请求进行预定操作。

具体地,请求提供完成业务所需要的信息,如:账号信息(您的账号/手机号)、密码保护问题(您的出生地)等;请求进行预定操作,如:去注册(注册指定账号)、去登录账户(登录指定账号)等。

首先,介绍业务指令为请求提供完成业务所需要的信息的情况:

当一个业务节点对应的业务指令为请求提供完成业务所需要的信息时,在一个页面中对预设业务流程的一个业务节点对应的业务指令进行处理,可以包括:

在一个页面中展示针对预设业务流程上的一个业务节点请求提供完成业务所需要的信息的请求消息;

接收响应于请求消息的信息;

将信息展示在页面的指定位置。

具体地,一个页面可以是指为该多业务节点型业务预设的业务流程新建的页面,该页面可以是聊天窗口形式的对话页面,也可以是用于加载接收到的信息的网页页面。比如,如图2-3所示,终端的应用程序为某一多业务节点型业 务新建一个对话页面,将预设业务流程的一个业务节点对应的请求提供完成业务所需要的信息,即问题(问题一?),在对话页面中进行展示;并将请求信息,即问题一的选项(“问题一选择A”和“问题一选择B”)展示在指定位置,用户会根据问题及选项,进行选择,当该应用程序接收到用户的选择结果,将该选择结果发送至指定位置,等待接收响应于该请求信息的信息(对于选择结果的响应,正确、错误等等),并将信息展示在页面的指定位置。从而实现了对该问题的处理。比如,问题一为该用户预先设置的密码保护问题“我的出生地?”,“问题一选择A”和“问题一选择B”的选项分别为“北京”和“天津”,当应用程序接收到用户对“北京”选项发送的点击指令后,应用程序将该选择结果发送至指定服务器,服务器通过匹配用户的预先设置,反馈给终端用户对于该问题的回答是否正确,从而实现了对该问题的处理。

需要说明的是,针对请求提供完成业务所需要的信息的请求消息,可以是独立的选项,比如前文介绍的“北京”或“天津”,也可以是由用户自定义输入的文字输入框、语音输入框等等。比如,问题可以是“请阅读预先设定的语音”,则针对该问题的选项可以是语音输入按钮,以便用户输入语音。

在介绍完业务指令为请求提供完成业务所需要的信息的情况,下面介绍业务指令为请求进行预定操作的情况:

当一个业务节点对应的业务指令为请求进行预定操作时,在一个页面中对预设业务流程的一个业务节点对应的业务指令进行处理,可以包括:

在一个页面中展示针对预设业务流程上的一个业务节点请求进行预定操作的请求消息,所述请求进行预定操作的请求消息包含进行预定操作的操作入口;

在完成预定操作后,将进行预定操作的结果展示在所述页面的指定位置。

具体地,请求进行预定操作可以是需要通过该业务流程以外的操作(如:登录、注册等),也可以是该业务流程中需要用户阅读、知悉的规章制度等(如,用户须知、注意事项等),所以,往往会通过操作入口跳转到其它的地址,以 便完成操作。

所以,在一种实施方式中,操作入口包含:进行预定操作的操作窗口地址,则

在完成预定操作后,将进行预定操作的结果展示在所述页面的指定位置,可以包括:

接收针对操作入口的触发指令;

根据操作入口中包含的操作窗口地址加载操作窗口;

在操作窗口完成预定操作后,将进行预定操作的结果反馈给所述页面;

将进行预定操作的结果展示在所述页面的指定位置。

具体地,比如,如图2-4所示,终端的应用程序为某一多业务节点型业务新建的一个对话页面中,将预设业务流程的一个业务节点对应的请求进行预定操作(简称操作)(步骤1说明),在对话页面中进行展示;并将操作的操作入口(“去完成步骤1”)展示在指定位置,应用程序通过接收用户针对操作入口的触发指令(如点击),根据操作入口中包含的操作窗口地址,加载操作窗口,比如,应用程序根据操作窗口的地址,展示操作窗口(登录、注册的页面或用户须知、注意事项)等,当用户在操作窗口中完成操作(登陆完成、注册完成、确认用户须知或注意事项)后,应用程序会接收到针对该操作反馈的结果,将该结果展示在对话页面的指定位置,从而实现对操作的处理。

步骤12,根据预设业务流程确定一个业务节点的下一个业务节点;

针对步骤12而言,预设的业务流程,往往包含了每一个业务节点之间的逻辑关系,比如,一个预设的业务流程:业务开始→问题1→问题2→业务结束,那么问题1就对应了一个业务节点,问题2就对应了问题1的下一个业务节点。

然而,在一些业务流程中,存在这样的逻辑关系:如果问题回答错误,则重复该问题,比如,如果接收到用户对于问题1的回答是错误的,则重复问题1,使用户再次回答,而非直接进入问题2。

所以,在一种实施方式中,在一个页面中对预设业务流程上的一个业务节点对应的业务指令进行处理后,方法还可以包括:

对处理结果进行判断,如果处理结果不正确,则在根据预设业务流程确定所述一个业务节点的下一个业务节点中,确定的下一个业务节点与所述一个业务节点相同。

具体地,依旧以上文“业务开始→问题1→问题2→业务结束”为例,一个业务节点为“问题1”,当用户对于问题1的回答是错误时,下一个业务节点与一个业务节点相同,依旧是“问题1”。

即,下一个业务节点在根据业务流程中,对于每个业务节点的完成情况,预先设定的,是可以随着整体业务流程中的局部流程而变化,比如,有下述业务流程:“业务开始→问题1→问题2→业务结束;且,当任一问题回答错误时,从问题1开始”。

当业务开始时,一个业务节点为“问题1”;

当“问题1”回答错误时,下一个业务依旧为“问题1”;

当“问题1”回答正确时,下一个业务依旧为“问题2”,此时,一个业务节点为“问题2”。

当“问题2”回答错误时,下一个业务为“问题1”。

仅以此例说明,下一个业务节点在根据业务流程中,对于每个业务节点的完成情况,预先设定的,是可以随着整体业务流程中的局部流程而变化了。

需要说明的是,在对处理结果进行判断时,对于处理结果的不正确是不限于问题与答案之间一一对应的对错关系上。还可以是逻辑关系上。比如,在进行身份认证时,会连续回答3个同样的问题,以进行身份认证,当该问题仅回答1次时,对于处理结果的不正确,是基于逻辑上,没有回答3次,从而不能进行下一个问题的关系。而非由于问题1回答错误导致的。

步骤13,当一个业务节点对应的业务指令处理完后,在所述页面中对下一个业务节点对应的业务指令进行处理。

具体地,在步骤12中介绍了一个业务节点到下一个业务节点的变化过程后,当需要进行下一个业务节点后,在步骤11中处理一个业务节点的的页面中,对该下一个业务节点对应的业务指令进行处理。

步骤13中的页面,是与步骤11中的页面是相同的,即,在步骤11处理一个业务节点后,在相同的页面,处理步骤13,不需再次加载或跳转到新的页面。

如图2-5,即为在步骤11如图2-3的页面中对下一个业务节点对应的业务指令进行处理;如图2-6,即为在步骤11如图2-4的页面中对下一个业务节点对应的业务指令进行处理。

需要说明的是,在某些情况中,下一业务节点的业务指令可以与步骤11中一个业务节点的业务指令相同,也可以相异。比如,步骤11中的一个业务节点对应的业务指令为请求提供完成业务所需要的信息,该步骤中的下一个业务节点对应的业务指令为请求进行预定操作。

所以,在一种实施方式中,当一个业务节点对应的业务指令为请求进行预定操作,而另一个业务节点对应的业务指令为请求提供完成业务所需要的信息时,则在一个页面中对预设业务流程上的另一个业务节点对应的业务指令进行处理,可以包括:

在一个页面中展示针对预设业务流程上的另一个业务节点请求提供完成业务所需要的信息的请求消息;接收响应于请求消息的信息;将信息展示在所述页面的指定位置。

当预设业务流程上的全部业务节点对应的业务指令处理完后,实现对多业务节点型业务的处理。

具体地,判断所有业务节点对应的业务指令是否完成,当判断出所有业务节点对应的业务指令处理完后,可以根据对每个业务节点的处理结果,生成对该多业务节点型业务的处理结果(成功、失败等)。

当判断出未完成所有业务节点对应的业务指令后,重复步骤13,在所述页 面中对再下一个业务节点对应的业务指令进行处理,直至所有业务节点对应的业务指令处理完后,实现对多业务节点型业务的处理。

如图2-7,即为如图2-3和如图2-5,处理了两个业务节点后,实现对多业务节点型业务的处理;如图2-6,即为如图2-4和如图2-6后,处理了两个业务节点后,实现对多业务节点型业务的处理。

在一种实施方式中,业务指令,表现为下述至少一种形式:文本;语音;图像;视频。具体地,当业务指令为请求提供完成业务所需要的信息(如问题)时,可以利用文本、语音、图像或视频中的一种或多种形式表现。比如,以图像的形式,展示验证码图像,并接收用户通过终端输入的验证码;又如,以文本和视频的形式,展示一段视频,并提问该视频中的人物、代表的事件、或发生年代等等。

当业务指令为请求进行预定操作时,也可以利用利用文字、文本、语音、图像或视频中的一种或多种形式进行注意事项、用户须知的展示等等。

采用实施例1提供的该方法,由于将多业务节点型业务中的每个业务节点对应的业务指令,都在同一个页面中进行处理,在业务过程中,无需创建新的页面,即可在一个页面中展示所有业务节点的完成过程,从而省去了现有技术中,每个业务节点都需要加载的页面消耗时间,提高了对多业务节点型业务处理效率。此外,站在用户一侧,在处理多业务节点型业务时,不再需要加载每个业务节点对应的业务指令的页面,也就在一定程度上避免了出现烦躁感,而是愿意将业务进行下去,间接地减少了用户了流失率。

需要说明的是,实施例1所提供方法的各步骤的执行主体均可以是同一设备,或者,该方法的各步骤也可以由不同设备作为执行主体。比如,步骤11和步骤12的执行主体可以为设备1,步骤13的执行主体可以为设备2;又比如,步骤11的执行主体可以为设备1,步骤12和步骤13的执行主体可以为设备2;等等。

实施例2

基于相同的发明构思,实施例2提供了一种多业务节点型业务的处理装置,用于提高多业务节点型业务的处理效率。多业务节点型业务包含按照预设业务流程确定的至少两个业务节点,如图3所示,该装置包括:

第一处理单元21、业务确定单元22、第二处理单元23、业务判断单元24,其中,

第一处理单元21,可以用于在一个页面中对预设业务流程的一个业务节点对应的业务指令进行处理;其中,预设业务流程包含至少两个业务节点;

业务确定单元22,可以用于根据预设业务流程确定一个业务节点的下一个业务节点;

第二处理单元23,可以用于当一个业务节点对应的业务指令处理完后,在页面中对下一个业务节点对应的业务指令进行处理;

业务判断单元24,可以用于判断预设业务流程上的全部业务节点对应的业务指令是否处理完毕,如果是,则结束流程,如果否,则调用业务确定单元。

在一种实施方式中,当一个业务节点对应的业务指令为请求提供完成业务所需要的信息时,第一处理单元21包括:信息请求子单元、信息接收子单元和信息展示子单元,其中:

信息请求子单元,可以用于在一个页面中展示针对预设业务流程上的一个业务节点请求提供完成业务所需要的信息的请求消息;

信息接收子单元,可以用于接收响应于请求消息的信息;

信息展示子单元,可以用于将信息展示在所述页面的指定位置。

在一种实施方式中,当一个业务节点对应的业务指令为请求进行预定操作时,第一处理单元21包括:操作请求子单元、结果展示子单元,其中:

操作请求子单元,可以用于在一个页面中展示针对预设业务流程上的一个业务节点请求进行预定操作的请求消息,所述请求进行预定操作的请求消息包含进行预定操作的操作入口;

结果展示子单元,可以用于在完成预定操作后,将进行预定操作的结果展示在所述页面的指定位置。

在一种实施方式中,操作入口包含进行预定操作的操作窗口地址,则

结果展示子单元,可以用于:

接收针对所述操作入口的触发指令;根据所述操作入口中包含的操作窗口地址加载所述操作窗口;在所述操作窗口完成所述预定操作后,将进行预定操作的结果反馈给所述页面;将所述进行预定操作的结果展示在所述页面的指定位置。

在一种实施方式中,当一个业务节点对应的业务指令为请求进行预定操作,另一个业务节点对应的业务指令为请求提供完成业务所需要的信息时,第一处理单元21包括:信息请求子单元、信息接收子单元和信息展示子单元,其中:

信息请求子单元,用于在一个页面中展示针对预设业务流程上的一个业务节点请求提供完成业务所需要的信息的请求消息;

信息接收子单元,用于接收响应于请求消息的信息;

信息展示子单元,用于将所述信息展示在所述页面的指定位置。

在一种实施方式中,在一个页面中对预设业务流程上的一个业务节点对应的业务指令进行处理后,业务确定单元22,还可以用于:

对处理结果进行判断,如果处理结果不正确,则在根据预设业务流程确定所述一个业务节点的下一个业务节点中,确定的下一个业务节点与所述一个业务节点相同。

在一种实施方式中,业务指令,可以表现为下述至少一种形式:文本;语音;图像;视频。

采用实施例2提供的该装置,由于将多业务节点型业务中的每个业务节点对应的业务指令,都在同一个页面中进行处理,在业务过程中,无需创建新的 页面,即可在一个页面中展示所有业务节点的完成过程,从而省去了现有技术中,每个业务节点都需要加载的页面消耗时间,提高了业务处理效率。

实施例3

基于相同的发明构思,实施例3提供了一种多业务节点型业务的处理方法,用于提高多业务节点型业务的处理效率。假设该多业务节点型业务的预设业务流程中包含了3个业务节点。该方法的示意图如图4所示,包括下述步骤:

步骤31,为该业务新建对话页面,在对话页面中对预设业务流程的第i个业务节点对应的业务指令进行处理;此时i=1。

步骤32,判断所有节点对应的业务指令是否完成,当判断结果为否时,执行步骤33;当判断结果为是时,业务结束。

步骤33,根据预设业务流程确定第i个业务节点的下一个业务节点,即第i+1个业务节点,此时i=1,i+1=2。

步骤34,在该对话页面中对第i+1个业务节点对应的业务指令进行处理,此时,i=1,i+1=2。

重复步骤32,因为仅完成了第2个业务节点,所以判断结果为否,执行步骤33。

步骤33,此时i=2,根据预设业务流程确定第i个业务节点的下一个业务节点,即第i+1个业务节点,i=2,i+1=3。

步骤34,在该对话页面中对第i+1个业务节点对应的业务指令进行处理,此时,i=2,i+1=3。

重复步骤32,因为完成了第3个业务节点,所以判断结果为是,业务结束。

需要说明的是,本实施例以某一多业务节点型业务的预设业务流程中包含了3个业务节点为例,进行解释说明,然而,本发明适用于多业务节点型业务包含按照预设业务流程确定的至少两个业务节点的情况,即在某一多业务节点型业务中,在局部的至少两个业务节点,使用本发明的技术方案即可提高该类 型业务节点的处理效率,最优的,是将这种类型的业务中每两个业务相邻业务节点都按照本发明的技术方案处理,从而实现业务处理效率的提高。

采用实施例3提供的该方法,由于将多业务节点型业务中的每个业务节点对应的业务指令,都在同一个对话页面中进行处理,在业务过程中,无需创建新的对话页面,即可在一个页面中展示所有业务节点的完成过程,从而省去了现有技术中,每个业务节点都需要加载的页面消耗时间,提高了业务处理效率。此外,站在用户一侧,在处理多业务节点型业务时,不再需要加载每个业务节点对应的业务指令的页面,也就在一定程度上避免了出现烦躁感,而是愿意将业务进行下去,间接地减少了用户了流失率。

本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个 流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。

还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1