账户状态信息的处理方法、装置、电子设备及存储介质与流程

本申请涉及计算机技术领域，具体而言，涉及一种账户状态信息的处理方法、装置、电子设备及存储介质。

背景技术：

目前信用卡账户的状态包括：申请、审批、核卡、激活、用卡、异动、和注销。其中，一状态与一业务系统相关。在此背景下，若需要知道某一信用卡账户的当前状态，则需要在多个业务系统间进行接口调用，通过分别访问每个业务系统，然后根据从每个业务系统所获得的结果来确定信用卡账户的当前状态。如果数据量较大，该种通过接口调用来分别访问每个业务系统的方法，一方面查询时间久；另一方面，若其中某个系统出现超时，将导致整个链路无法获取到对应的信息。

因此，如何解决为确定信用卡账户的当前状态所存在查询时间久是现有技术中亟待解决的技术问题。

技术实现要素：

本申请的实施例提供了一种账户状态信息的处理方法、装置、电子设备及存储介质，进而至少在一定程度上可以缩短查询确定信用卡账户的当前状态所花费的时间。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

根据本申请实施例的一个方面，提供了一种账户状态信息的处理方法，应用于状态存储系统，所述状态存储系统设有用于存储各账户所对应状态信息的数据仓库，所述状态存储系统接入了至少两个业务系统，注册账户的每一个状态与以业务系统相关，所述方法包括：

接收业务系统为注册账户所下发的状态指示信息，所述状态指示信息用于指示所述注册账户更新至第一状态；

根据所述状态指示信息将所述数据仓库中所述注册账户的当前状态更新为所述第一状态，并将所述注册账户更新前的当前状态作为历史状态进行存储；

接收为目标注册账户发起的状态查询请求；

根据所述状态查询请求在所述数据仓库中查询获得所述目标注册账户的当前状态；

将所述目标注册账户的当前状态返回至所述状态查询请求的发起方。

根据本申请实施例的一个方面，提供了一种账户状态信息的处理装置，应用于状态存储系统，所述状态存储系统设有用于存储各账户所对应状态信息的数据仓库，所述状态存储系统接入了至少两个业务系统，注册账户的每一个状态与一业务系统相关，所述装置包括：

状态指示信息接收模块，用于接收业务系统为注册账户所下发的状态指示信息，所述状态指示信息用于指示所述注册账户更新至第一状态；

状态更新模块，用于根据所述状态指示信息将所述数据仓库中所述注册账户的当前状态更新为所述第一状态，并将所述注册账户更新前的当前状态作为历史状态进行存储；

状态查询请求接收模块，用于接收为目标注册账户发起的状态查询请求；

状态查询模块，用于根据所述状态查询请求在所述数据仓库中查询获得所述目标注册账户的当前状态；

返回模块，用于将所述目标注册账户的当前状态返回至所述状态查询请求的发起方。

在本申请的一些实施例中，所述装置还包括：

第二状态确定模块，用于根据为账户配置的生命状态信息，确定所述目标注册账户的第二状态，所述第二状态是按照所述生命状态信息所指示各个状态之间的时序关系，所述目标注册账户的当前状态所对应的下一状态；

操作指示信息获取模块，用于从所述第二状态所对应的业务系统中获取针对所述第二状态的操作指示信息；

返回信息生成模块，用于根据所述目标注册账户的当前状态、所述第二状态和所述操作指示信息生成返回信息；

所述返回模块被配置为：将所述返回信息发送至所述状态查询请求的发起方。

在本申请的一些实施例中，所述装置还包括：

账户变动请求接收模块，用于接收账户变动请求，所述账户变动请求指示了第一注册账户的第一账户标识和第二注册账户的第二账户标识；

状态数据获取模块，用于根据所述第一账户标识从所述数据仓库中获取所述第一注册账户的状态数据，所述状态数据包括该第一注册账户的历史状态和当前状态；

状态提取模块，用于从所述第一注册账户的历史状态和当前状态中提取属性为可继承的状态；

绑定模块，用于将所述属性为可继承的状态与所述第二注册账户相绑定，以使所述第二注册账户继承所述第一注册账户的状态数据中属性为可继承的状态；

第二状态更新模块，用于将所述第二账户的当前状态更新为所提取状态中的最新状态。

在本申请的一些实施例中，所述状态查询请求包括所述目标注册账户的账户标识，状态查询模块，包括：

主键查询单元，用于根据所述目标注册账户的账户标识进行主键查询，获得对应于所述目标注册账户的主键。

状态数据查询单元，用于按照对应于所述目标注册账户的主键进行状态数据查询，获得所述目标注册账户的状态数据，其中，所述状态数据以所对应的主键作为索引存储于所述数据仓库中。

状态确定单元，用于从所述目标注册账户的状态数据中提取得到所述目标注册账户的当前状态。

在本申请的一些实施例中，所述状态存储系统中设有消息队列，该装置还包括：

暂存模块，用于将所述注册账户对应的状态指示信息暂存于所述消息队列中。

状态更新模块，被配置为：从所述消息队列中提取所述注册账户对应的状态指示信息；按照所述状态指示信息将所述注册账户的当前状态更新为所述第一状态。

根据本申请实施例的一个方面，提供了一种电子设备，包括：

处理器；以及

存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，实现如上所述的方法。

根据本申请实施例的一个方面，提供了一种计算机可读存储介质，其上存储有计算机可读指令，所述计算机可读指令被处理器执行时，实现如上的方法。

在本申请的技术方案中，由于布设了与各个业务系统通信连接的状态存储系统，并在来进行各个注册账户的状态的更新和存储，从而对于需要查询目标注册账户的一方而言，并不需要逐个去查询处理与注册账户相关业务的业务系统，而仅需要在该状态存储系统进行查询即可。

相较于现有技术中需要分别访问各个业务系统才能确定注册账户的当前状态而言，本申请的方案仅需要访问状态存储系统即可确定注册账户的当前状态，大幅缩短了注册账户的当前状态的查询时间。而且，由于并不需要访问业务系统来查询注册账户的当前状态，从而，当前状态的查询过程并不会影响到业务系统所进行的业务处理过程，有效避免了因需要访问业务系统进行当前状态查询所导致业务系统资源紧张的问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1是根据一实施例示出的本申请的实施环境的示意图；

图2是根据一实施例示出的账户状态信息的处理方法的流程图；

图3是根据一实施例示出的步骤240之后步骤在一实施例中的流程图；

图4是根据一实施例示出的步骤220之后步骤在一实施例中的流程图；

图5是根据一实施例示出的步骤240在一实施例中的流程图；

图6是根据一实施例示出的账户状态信息的处理装置的框图；

图7示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

图1是根据一实施例示出的本申请的实施环境的示意图，如图1所示，该实施环境包括状态存储系统110和与状态存储系统110通信连接的多个业务系统120。其中，业务系统120用于针对注册账户相关业务进行处理。与注册账户相关的业务可以是注册账户申请业务、注册账户相关申请信息的审核业务、注册账户的核查业务、注册账户的激活业务、注册账户的用卡业务、注册账户的异动业务、注册账户的注销业务等，在此不进行具体限定。

在本申请的注册账户，为其配置有生命状态信息，该生命状态信息指示了注册账户的各个状态和各个状态之间的时序。

其中，注册账户的状态与业务系统120针对注册账户所进行的业务处理的处理结果相关。具体来说，在业务系统120针对注册账户进行业务处理，得到对应的业务处理结果后，则如果该业务处理结果满足注册账户的状态的更新条件，则为该注册账户生成状态指示信息，并发送至状态存储系统110，以使状态存储系统110根据该状态指示信息更新注册账户的状态。

举例来说，针对注册账户的审核的业务系统120，如果该业务系统120审核注册账户所对应用户的各项申请信息(例如身份证明信息、个人征信信息等)满足开户要求，则得到审核通过的业务处理结果，并根据该业务处理结果指示将该注册账户的状态更新为审核状态的状态指示信息，对应的，状态存储系统110在接收到该状态指示信息后，将该注册账户的当前状态更新为审核状态。

在本实施例中，一业务系统120至少进行一项与注册账户的状态相关业务的处理，从而，一业务系统120与注册账户的至少一状态相关。

继续参阅图1所示，状态存储系统110中设有消息队列111和数据仓库112。消息队列111作为与业务系统120与状态存储系统110之间的消息容器，以保证状态存储系统110与业务系统120之间消息传递的有序性。

其中，该数据仓库112用于存储各个注册账户的状态。从而，该状态存储系统基于数据仓库可以提供进行注册账户的状态查询服务。

以下对本申请实施例的技术方案的实现细节进行详细阐述：

图2是根据一实施例示出的账户状态信息的处理方法的流程图，图2所示的状态存储系统，状态存储系统设有用于存储各账户所对应状态信息的数据仓库，状态存储系统接入了至少两个业务系统，注册账户的每一个状态与一业务系统相关。参照图2所示，该方法至少包括步骤210至步骤250，详细介绍如下：

步骤210，接收业务系统为注册账户所下发的状态指示信息，状态指示信息用于指示注册账户更新至第一状态。

如上所描述，业务系统用于处理注册账户相关的业务。每一业务系统完成特定的与注册账户相关的业务。例如，针对注册账户申请受理相关的业务，由业务系统a进行处理；针对注册账户相关申请信息的审查业务，由业务系统b进行处理；针对注册账户异动相关的业务，由业务系统c进行处理。

其中，在业务系统在处理完成一注册账户相关的业务后，如果处理结果满足注册账户的状态切换至一状态的条件，则业务系统对应根据处理结果生成状态指示信息，该状态指示信息对应指示注册账户的状态所要切换至的状态，即上述的第一状态。从而，注册账户的每一状态是与一业务系统相关的，即在该业务系统处理完成一注册账户与该状态相关的业务且处理结果满足注册账户进行状态切换的条件时，该注册账户才能更新至该状态。

值得一提的是，第一状态并不特指注册账户的某一状态，而是泛指该业务系统所生成状态指示信息所指示注册账户待更新至的状态。

本申请所涉及的注册账户可以是银行卡账户、信用卡账户、证券账户等金融账户，也可以是其他网络平台上的电子账户，例如在购物平台上的电子账户、在视频平台上的电子账户等，在此不进行具体限定。

步骤220，根据状态指示信息将数据仓库中注册账户的当前状态更新为第一状态，并将注册账户更新前的当前状态作为历史状态进行存储。

也就是说，在任一业务系统针对注册账户生成状态指示信息并将该状态指示信息发送至状态存储系统后，状态存储系统对应进行该注册账户的当前状态的更新，而更新前的状态即作为该注册账户的历史状态，由此实现了数据仓库中各个注册账户的状态的存储和更新。

步骤230，接收为目标注册账户发起的状态查询请求。

目标注册账户并不特指某一注册账户，而是泛指待确定当前状态的注册账户。

可以理解的是，状态查询请求指示了目标注册账户的账户标识。该账户标识可以是账户名称、账户卡号等，例如，若注册账户是信用卡账户，该账户标识可以是信用卡卡号、身份证号等，若注册账户是视频平台上的电子账户，则该账户标识可以是注册时所分配的账户序列号等。

步骤240，根据状态查询请求在数据仓库中查询获得目标注册账户的当前状态。

如上所描述，由于状态存储系统根据各个业务系统为注册账户生成的状态指示信息进行注册账户在数据仓库中的状态更新和存储，从而，在数据仓库中，各个注册账户的状态与业务系统中注册账户的状态是保持一致的。

进而，状态存储系统接收到为目标注册账户发起的状态查询请求后，根据目标注册账户的账号标识即可对应在数据仓库中查询得到目标注册账户的当前状态。

步骤250，将目标注册账户的当前状态返回至状态查询请求的发起方。

在本申请的方案中，由于布设了与各个业务系统通信连接的状态存储系统，并在来进行各个注册账户的状态的更新和存储，从而对于需要查询目标注册账户的一方而言，并不需要逐个去查询处理与注册账户相关业务的业务系统，而仅需要在该状态存储系统进行查询即可。

相较于现有技术中需要分别访问各个业务系统才能确定注册账户的当前状态而言，本申请的方案仅需要访问状态存储系统即可确定注册账户的当前状态，大幅缩短了注册账户的当前状态的查询时间。而且，由于并不需要访问业务系统来查询注册账户的当前状态，从而，当前状态的查询过程并不会影响到业务系统所进行的业务处理过程，有效避免了因需要访问业务系统进行当前状态查询所导致业务系统资源紧张的问题。

在一实施例中，如图3所示，步骤240之后，该方法还包括：

步骤310，根据为账户配置的生命状态信息，确定目标注册账户的第二状态，第二状态是按照生命状态信息所指示各个状态之间的时序关系，目标注册账户的当前状态所对应的下一状态。

在本实施例中，在状态存储系统中还存储另外为账户配置的生命状态信息，该生命状态信息指示了注册账户所可能经历各个状态之间的时序关系。举例来说，若注册账户为信用卡账户，假设信用卡账户按照先后顺序需要经历的状态依次为：申请、审批、核卡、激活、用卡、异动和注销，则该生命状态信息即用于指示上述申请→审批→核卡→激活→用卡→异动→注销这一时序。

在确定目标注册账户的当前状态的基础上，结合该生命状态信息即可确定对应于目标注册账户的当前状态的下一状态，即第二状态。

步骤320，从第二状态所对应的业务系统中获取针对第二状态的操作指示信息。

第二状态所对应的操作指示信息用于指示使目标注册账户的当前状态切换到第二状态所需要用户进行的操作，例如所需要用户访问的业务系统。

步骤330，根据目标注册账户的当前状态、第二状态和操作指示信息生成返回信息。

在该实施例中，步骤250，包括：将返回信息发送至状态查询请求的发起方。

在本实施例中，返回信息包含的三方面的内容：一是目标注册账户的当前状态；二是目标注册账户的当前状态所对应的下一状态(即第二状态)；三是对应于第二状态的操作指示信息。

从而，在状态查询请求的发起方接收到返回信息后，一方面可以获知到所要查询的目标注册账户的当前状态，而且还可以取确定对应于当前状态的第二状态，和切换到第二状态所需要进行的操作，从而向用户进行操作指导，便于用户针对性地进行操作，减少用户因不知道如何从当前状态切换到第二状态所导致的时间花费。

在图3所示实施例中，状态查询请求的发起方可以是客户端，从而，在接收到返回信息后，客户端所在用户可以对应了解到从当前状态切换到下一状态所要进行的操作。

在其他实施例中，状态查询请求的发起方还可以是一业务系统，而对于该业务系统而言，其仅仅需要获取到目标注册账户的当前状态，而并不需要了解到该当前状态对应的下一状态以及对应于第二状态的操作指示信息，在此场景下，还可以直接将目标注册账户的当前状态发送至状态查询请求的发起方，而并不需要进行上述步骤310-330的过程。

进一步的，状态存储系统可以根据状态查询请求中所包括状态查询请求发起方的标识来针对性的进行处理。具体来说，如果状态查询请求发起方的标识指示状态查询请求的发起方是业务系统，则在确定目标注册账户的当前状态后，直接将该当前状态发送至发起状态查询请求的业务系统；如果状态查询请求发起方的标识指示状态查询请求的发起方是客户端用户，则在确定目标注册账户的当前状态后，按照上述步骤310-330的过程生成返回信息，并将返回信息发送给客户端用户。

在一实施例中，如图4所示，步骤220之后，该方法还包括：

步骤410，接收账户变动请求，账户变动请求指示了第一注册账户的第一账户标识和第二注册账户的第二账户标识。

若注册账户为配置实体卡片的账户，例如信用卡账户，由于可能存在信用卡遗失或者损坏的情况，对应的，如果进行信用卡补办，则需要为用户重新配置新的信用卡。在此应用场景下，为用户配置新的信用卡即相当于为用户重新开设一个注册账户。

而对于用户而言，用户所遗失或损坏的信用卡可能已经经历过申请、审核等流程，为了针对该用户重新进行申请、审核等流程，则可以将所遗失或损坏信用卡对应的状态数据复制到所新配置的信用卡中，以此避免进行重复的申请和审核等流程。

在本实施例中，账户变动请求是为实现将一注册账户中的状态数据复制到另一注册账户中而发起的请求。

其中，第一注册账户并不特指某一注册账户，而是泛指需要进行状态数据复制的注册账户；同理，第二注册账户并不特指某以注册账户，而是泛指待接收被复制状态数据的注册账户。

步骤420，根据第一账户标识从数据仓库中获取第一注册账户的状态数据，状态数据包括该第一注册账户的历史状态和当前状态。

第一注册账户的状态数据包括第一注册账户所经历过的全部状态，具体包括第一注册账户的历史状态和最新状态。

步骤430，从第一注册账户的历史状态和当前状态中提取属性为可继承的状态。

在本实施例中，为注册账户的状态配置了继承属性，该继承属性用于指示该状态是否可被继承，如果一状态的继承属性指示该状态可以被继承，则表明可以将第一注册账户中的该状态复制到第二注册账户中；反之，如果一状态的继承属性指示该状态不可以被继承，则表明不可以将第一注册账户中的该状态复制到第二注册账户中。

因此，为了实现状态的复制，先从第一注册账户所经历的全部状态，即全部历史状态和当前状态中提取属性为可继承的状态。

对于信用卡账户而言，其申请、审批、核卡、激活、用卡、异动等状态的继承属性可以是可以被继承的属性；而注销状态可以是不可被继承的属性。

步骤440，将属性为可继承的状态与第二注册账户相绑定，以使第二注册账户继承第一注册账户的状态数据中属性为可继承的状态。

在将所提取属性为可继承的状态与第二注册账户相绑定后，则所提取属性为可继承的状态对应作为第二注册账户所经历的状态。

步骤450，将第二账户的当前状态更新为所提取状态中的最新状态。

其中，所提取状态中的最新状态是根据生命状态信息所指示各个状态之间的时序关系而在所提取状态中确定的状态。

通过如上的过程实现了将第一注册账户的状态数据中可被继承的状态复制到第二注册账户中，快速实现了第二注册账户的状态的更新和存储。

在一实施例中，如图5所示，步骤240包括：

步骤510，根据目标注册账户的账户标识进行主键查询，获得对应于目标注册账户的主键。

步骤520，按照对应于目标注册账户的主键进行状态数据查询，获得目标注册账户的状态数据，其中，状态数据以所对应的主键作为索引存储于数据仓库中。

在本实施例中，数据仓库中包括用于存储主键的仓库和用于存储状态数据的仓库，在存储状态数据的仓库中，以主键作为索引。

在一具体实施例中，数据仓库中用于存储主键的仓库可以是elasticsearch系统，用于存储状态数据的仓库可以是hbase系统。

步骤530，从目标注册账户的状态数据中提取得到目标注册账户的当前状态。

在本实施例中，在数据仓库中，以主键作为索引来进行各注册账户所对应状态数据的存储，从而，提高状态数据查询的速度。

在一实施例中，状态存储系统中设有消息队列，步骤210之后，该方法还包括：将注册账户对应的状态指示信息暂存于消息队列中。在该实施例中，步骤230包括：从消息队列中提取注册账户对应的状态指示信息；按照状态指示信息将注册账户的当前状态更新为第一状态。

在本实施例中，在状态存储系统中设置消息队列，并将该消息队列作为进行状态指示信息存储的容器，从而，便于状态存储系统有序地从消息队列中提取状态指示信息，对应进行注册账户的状态的更新。特别在注册账户较多，状态存储系统中接入的业务系统较多的场景时，可能同时有多个业务系统发送状态指示信息至状态存储系统中，如果不能进行状态指示信息的有效管理，则可能导致注册账户的状态的更新发生混乱。而通过设置消息队列，按照先入先出的顺序进行状态指示信息的存入和取出，保证了状态指示信息存入和取出的有序性。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的方法实施例。

本公开提供了一种账户状态信息的处理装置600，应用于状态存储系统，状态存储系统设有用于存储各账户所对应状态信息的数据仓库，状态存储系统接入了至少两个业务系统，注册账户的每一个状态与一业务系统相关，如图6所示，该装置包括：

状态指示信息接收模块610，用于接收业务系统为注册账户所下发的状态指示信息，状态指示信息用于指示注册账户更新至第一状态。

状态更新模块620，用于根据状态指示信息将数据仓库中注册账户的当前状态更新为第一状态，并将注册账户更新前的当前状态作为历史状态进行存储。

状态查询请求接收模块630，用于接收为目标注册账户发起的状态查询请求。

状态查询模块640，用于根据状态查询请求在数据仓库中查询获得目标注册账户的当前状态。

返回模块650，用于将目标注册账户的当前状态返回至状态查询请求的发起方。

在一实施例中，该装置还包括：

第二状态确定模块，用于根据为账户配置的生命状态信息，确定目标注册账户的第二状态，第二状态是按照生命状态信息所指示各个状态之间的时序关系，目标注册账户的当前状态所对应的下一状态；

操作指示信息获取模块，用于从第二状态所对应的业务系统中获取针对第二状态的操作指示信息；

返回信息生成模块，用于根据目标注册账户的当前状态、第二状态和操作指示信息生成返回信息；

返回模块被配置为：将返回信息发送至状态查询请求的发起方。

在一实施例中，该装置还包括：

账户变动请求接收模块，用于接收账户变动请求，账户变动请求指示了第一注册账户的第一账户标识和第二注册账户的第二账户标识。

状态数据获取模块，用于根据第一账户标识从数据仓库中获取第一注册账户的状态数据，状态数据包括该第一注册账户的历史状态和当前状态。

状态提取模块，用于从第一注册账户的历史状态和当前状态中提取属性为可继承的状态。

绑定模块，用于将属性为可继承的状态与第二注册账户相绑定，以使第二注册账户继承第一注册账户的状态数据中属性为可继承的状态。

第二状态更新模块，用于将第二账户的当前状态更新为所提取状态中的最新状态。

在一实施例中，状态查询请求包括目标注册账户的账户标识，状态查询模块640，包括：

主键查询单元，用于根据目标注册账户的账户标识进行主键查询，获得对应于目标注册账户的主键。

状态数据查询单元，用于按照对应于目标注册账户的主键进行状态数据查询，获得目标注册账户的状态数据，其中，状态数据以所对应的主键作为索引存储于数据仓库中。

状态确定单元，用于从目标注册账户的状态数据中提取得到目标注册账户的当前状态。

在一实施例中，状态存储系统中设有消息队列，该装置还包括：

暂存模块，用于将注册账户对应的状态指示信息暂存于消息队列中。

状态更新模块620，被配置为：从消息队列中提取注册账户对应的状态指示信息；按照状态指示信息将注册账户的当前状态更新为第一状态。

上述装置中各个模块/单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

可以理解，这些模块可以通过硬件、软件、或二者结合来实现。当以硬件方式实现时，这些模块可以实施为一个或多个硬件模块，例如一个或多个专用集成电路。当以软件方式实现时，这些模块可以实施为在一个或多个处理器上执行的一个或多个计算机程序。

图7示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图7示出的电子设备的计算机系统700仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图7所示，计算机系统700包括中央处理单元(centralprocessingunit，cpu)701，其可以根据存储在只读存储器(read-onlymemory，rom)702中的程序或者从存储部分708加载到随机访问存储器(randomaccessmemory，ram)703中的程序而执行各种适当的动作和处理，例如执行上述实施例中的方法。在ram703中，还存储有系统操作所需的各种程序和数据。cpu701、rom702以及ram703通过总线704彼此相连。输入/输出(input/output，i/o)接口705也连接至总线704。

以下部件连接至i/o接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(cathoderaytube，crt)、液晶显示器(liquidcrystaldisplay，lcd)等以及扬声器等的输出部分708；包括硬盘等的存储部分708；以及包括诸如lan(localareanetwork，局域网)卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至i/o接口705。可拆卸介质77，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质77被安装。在该计算机程序被中央处理单元(cpu)701执行时，执行本申请的系统中限定的各种功能。

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

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

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读存储介质存储有计算机可读指令，当上述计算机可读指令被处理器执行时，例如上述电子设备中的处理器执行时，实现上述任一方法实施例中的方法。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。

在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。