一种电子支付业务处理、电子支付方法及装置与流程

本申请涉及计算机信息技术领域，尤其涉及一种电子支付业务处理、电子支付方法及装置。

背景技术：

随着互联网的蓬勃发展，人们日常生活中越来越多的使用到了计算机远程技术来处理业务。使用计算机远程技术来处理业务时，用户通过电脑、手机以及网络电视等电子终端上发出业务处理指令，通过远程的服务器来实现业务的处理。业务处理的流程包括用户发出业务处理请求，提交业务处理必要的信息，最后接收服务器反馈的业务处理结果，其中提交业务处理必要的信息通常包含提交业务处理渠道的选择信息、提交同意业务处理相关协议的信息以及提交业务处理鉴权信息等。业务处理通常会出现处理失败的现象，这些处理失败的现象是由业务处理的过程出现错误而引起，这些错误可能是由所提交的业务处理必要的信息自身出错而引起，也可能由服务器等外部因素引起。

在现有技术中，以电子支付业务为例，当电子支付业务处理失败时服务器会反馈给用户电子支付业务处理失败的提示页面。电子支付业务处理失败的提示页面中包含电子支付业务处理失败类型的提示信息和重新进行电子支付业务处理的入口，用户需要从所反馈的入口进入电子支付业务处理页面，然后根据电子支付业务处理失败类型的提示信息，重新提交电子支付业务处理必要的信息以再次进行业务处理。

由此可见，在电子支付业务处理失败时，现有技术通过反馈给用户电子支付业务处理失败类型的提示信息和重新进行电子支付业务处理的入口，然后用户通过所反馈的入口重新提交电子支付业务处理必要的信息的方式，再次进行 电子支付业务处理。但是，这种方式需要用户重新提交全部电子支付业务处理必要的信息，使得再次进行电子支付业务处理时的操作较多，这样会造成用户在电子支付业务处理时体验较差。

技术实现要素：

本申请实施例提供一种电子支付业务处理、电子支付方法及装置，用于解决现有技术中在电子支付业务处理失败时，向用户返回电子支付业务处理的入口进行电子支付业务处理的操作较多，从而造成用户在电子支付业务处理时体验较差的问题。

本申请实施例提供一种电子支付业务处理方法，该方法包括：

业务服务器接收进行电子支付业务处理需要的第一业务信息集合，以便进行电子支付业务处理；

业务服务器判断所述电子支付业务处理是否失败，若是，则根据所述电子支付业务处理失败的类型确定是否生成重新支付入口，所述重新支付入口能够关联到第二业务信息集合，所述第二业务信息集合为调整导致电子支付业务处理失败的第一业务信息集合中对应元素后形成的集合；

业务服务器在生成重新支付入口并接收到所述重新支付入口被触发的指令后，利用所述第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理，所述第三业务信息集合为第一业务信息集合和第二业务信息集合的差集。

优选的，所述方法还包括：

业务服务器将所述重新支付入口和所述第三业务信息集合建立对应关系；

业务服务器在接收到所述重新支付入口被触发的指令时，通过所述对应关系获取所述第三业务信息集合。

优选的，所述业务服务器将所述重新支付入口和所述第三业务信息集合建立对应关系具体为：

业务服务器在生成重新支付入口之时或之后生成唯一标识符；

业务服务器将所述唯一标识符和第三业务信息集合建立对应关系，以及将所述重新支付入口和所述唯一标识符建立对应关系；则：

所述业务服务器在接收到所述重新支付入口被触发的指令时，通过所述对应关系获取所述第三业务信息集合具体为：

在接收到所述重新支付入口被触发的指令时，根据所述重新支付入口与唯一标识的对应关系获取所述唯一标识符，并通过所述唯一标识符获取所述第三业务信息集合。

优选的，所述唯一标识符与时间戳具有对应关系，所述时间戳用于记录所述唯一标识符生成时的时间，则所述根据所述重新支付入口与唯一标识的对应关系获取所述唯一标识符，并通过所述唯一标识符获取所述第三业务信息集合具体为：

在获取所述唯一标识符后，通过所述唯一标识符获取时间戳；

判断当前时间和所述时间戳所记录的时间之差是否小于预设时间阈值，若是，则通过所述唯一标识符获取所述第三业务信息集合。

优选的，所述唯一标识符还与状态信息具有对应关系，所述状态信息用于记录是否已经通过所述唯一标识符获取所述第三业务信息集合，则所述根据所述重新支付入口与唯一标识的对应关系获取所述唯一标识符，并通过所述唯一标识符获取所述第三业务信息集合具体为：

在获取所述唯一标识符后，通过所述唯一标识符获取状态信息；

通过所述状态信息判断是否已经通过所述唯一标识符获取所述第三业务信息集合，若否，则通过所述唯一标识符获取所述第三业务信息集合。

优选的，所述业务服务器根据所述电子支付业务处理失败的类型决定是否生成重新支付入口具体包括：

业务服务器判断所述电子支付业务处理失败的类型是否为所述电子支付鉴权信息错误，若否，则生成重新支付入口。

优选的，在判断所述电子支付业务处理是否失败时，所述方法还包括：若否，则发送业务处理成功的提示信息；或，

在根据所述电子支付业务处理失败的类型确定是否生成重新支付入口时，如果确定不生成重新支付入口，所述方法还包括：发送所述电子支付业务处理失败的类型对应的提示信息；或，

在判断所述电子支付业务处理失败的类型是所述电子支付鉴权信息错误时，所述方法还包括：结束所述电子支付业务处理，并发送所述电子支付业务处理失败的类型对应的提示信息。

本申请实施例还提供一种业务处理方法，该方法包括：

客户端提交进行电子支付业务处理需要的第一业务信息集合，以便业务服务器进行电子支付业务处理；

客户端在所述电子支付业务处理失败时，触发重新支付入口，以便业务服务器利用所述第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理，所述重新支付入口为业务服务器根据所述电子支付业务处理失败的类型确定生成的能够关联到第二业务信息集合的入口，所述第二业务信息集合为业务服务器调整导致电子支付业务处理失败的第一业务信息集合中对应元素后形成的集合，所述第三业务信息集合为第一业务信息集合和第二业务信息集合的差集。

优选的，所述触发重新支付入口包括：

点击重新支付入口对应的网页超链接，和/或，

触控重新支付入口对应的触摸屏按钮，和/或，

通过摇一摇、手势识别，或表情识别的方式触发重新支付入口。

本申请实施例还提供一种电子支付方法，该方法包括：

接收进行电子支付所需要的支付要素信息集合，以进行电子支付；

判断所述电子支付是否失败，若是，则根据所述电子支付失败的类型决定是否生成重新支付入口，所述重新支付入口能够关联到调整导致电子支付失败 的支付要素后形成的新的支付要素；

在生成重新支付入口并接受到所述重新支付入口被触发的指令时，利用所述新的支付要素以及所述支付要素信息集合中导致电子支付失败的支付要素以外的要素实现重新支付。

优选地，所述根据所述电子支付失败的类型决定是否生成重新支付入口具体包括：

如果电子支付失败类型为支付渠道余额不足，则生成能够关联到余额充足的支付渠道的重新支付入口，则：所述在接收到重新支付入口被触发的指令后，利用所述新的支付要素以及所述支付要素集合中导致电子支付失败的支付要素以外的要素实现重新支付，具体包括：

在接收到重新支付入口被触发的指令后，利用所述余额充足的支付聚到以及支付要素信息集合中支付渠道以外的要素实现重新支付；和/或，

如果电子支付失败类型为支付渠道业务繁忙，则生成能够关联到业务空闲的支付渠道的重新支付入口，则：所述在接收到重新支付入口被触发的指令后，利用所述新的支付要素以及所述支付要素信息集合中导致电子支付失败的支付要素以外的要素实现重新支付，具体包括：

在接收到重新支付入口被触发的指令后，利用所述业务空闲的支付渠道以及所述支付要素信息集合中业务繁忙的支付渠道以外的要素实现重新支付。

本申请实施例还提供一种业务处理装置，该装置包括：第一接收单元、第一判断单元、第一确定单元、第二接收单元和第一处理单元，其中：

所述第一接收单元，用于接收进行电子支付业务处理需要的第一业务信息集合，以便进行电子支付业务处理；

所述第一判断单元，用于判断所述电子支付业务处理是否失败，若是，则触发第一确定单元；

所述第一确定单元，用于在所述电子支付业务处理失败时，根据所述电子支付业务处理失败的类型确定是否生成重新支付入口，所述重新支付入口能够 关联到第二业务信息集合，所述第二业务信息集合为调整导致电子支付业务处理失败的第一业务信息集合中对应元素后形成的集合；

所述第二接收单元，用于接收所述重新支付入口被触发的指令；

所述第一处理单元，用于利用所述第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理，所述第三业务信息集合为第一业务信息集合和第二业务信息集合的差集。

本申请实施例还提供一种电子支付业务处理装置，该装置包括：提交单元和触发单元，其中：

所述提交单元，用于提交进行业务处理需要的第一业务信息集合，以便进行电子支付业务处理；

所述触发单元，用于在所述电子支付业务处理失败时，触发重新支付入口，以便业务服务器利用所述第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理，所述重新支付入口为业务服务器根据所述电子支付业务处理失败的类型确定生成的能够关联到第二业务信息集合的入口，所述第二业务信息集合为业务服务器调整导致电子支付业务处理失败的第一业务信息集合中对应元素后形成的集合，所述第三业务信息集合为第一业务信息集合和第二业务信息集合的差集。

本申请实施例还提供一种电子支付装置，该装置包括：第三接收单元、第二判断单元、第二确定单元、第四接收单元和第二处理单元，其中：

所述第三接收单元，用于接收进行电子支付所需要的支付要素信息集合，以进行电子支付；

所述第二判断单元，用于判断所述电子支付是否失败，若是，则触发第二确定单元；

所述第二确定单元，用于根据所述电子支付失败的类型决定是否生成重新支付入口，所述重新支付入口能够关联到调整导致电子支付失败的支付要素后形成的新的支付要素；

所述第四接收单元，用于接受到所述重新支付入口被触发的指令；

所述第二处理单元，用于利用所述新的支付要素以及所述支付要素信息集合中导致电子支付失败的支付要素以外的要素实现重新支付。本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

本发明用户提交第一业务信息集合进行电子支付业务处理，当根据第一业务信息集合进行的电子支付业务处理失败时，业务服务器可根据业务处理失败的类型生成重新支付入口，接收用户通过重新支付入口提交的第二业务信息集合，第二业务信息集合为调整导致电子支付业务处理失败的第一业务信息集合中对应元素后形成的集合，并利用第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理，第三业务信息集合为第一业务信息集合和第二业务信息集合的差集。因此解决了现有技术中，当电子支付业务处理失败时，用户需要重新提交进行电子支付业务处理需要的全部业务信息，才能再次进行电子支付业务处理的问题，提高了用户的体验。

附图说明

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

图1为本申请实施例1提供的一种电子支付业务处理方法的具体实现流程示意图；

图2为本申请实施例2提供的唯一标识符关联的具体实现流程示意图；

图3为本申请实施例3提供的时间戳控制唯一标识符的具体实现流程示意图；

图4为本申请实施例5提供的通过电子支付鉴权信息控制电子支付业务处理的具体实现流程示意图；

图5为本申请实施例7提供的一种电子支付业务处理方法的具体实现流程 示意图；

图6为本申请实施例8提供的一种电子支付业务处理方法的具体实现流程示意图；

图7为本申请实施例9提供的一种电子支付方法的具体实现流程示意图；

图8为本申请实施例10提供的一种电子支付业务处理装置的具体结构示意图；

图9为本申请实施例11提供的一种电子支付业务处理装置的具体结构示意图；

图10为本申请实施例12提供的一种电子支付装置的具体结构示意图。

具体实施方式

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

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

实施例1

实施例1提供了一种电子支付业务处理方法，用于解决现有技术中在电子支付业务处理失败时，向用户返回重新支付入口进行电子支付业务处理的操作较多，从而造成用户在电子支付业务处理时体验较差的问题。该方法的具体流程示意图如附图1所示，包括下述步骤：

步骤11：业务服务器接收进行电子支付业务处理需要的第一业务信息集合，以便进行电子支付业务处理。

所述第一业务信息集合指进行所述电子支付业务处理所需要的业务信息 集合。

实际应用中的业务处理，通常需要接收进行该业务处理所需要的业务信息，以便进行该业务处理。一般来说根据所需要处理的业务类型的不同，所需的业务信息集合通常也不同；另外，即使是所要处理的业务类型相同，所需的业务信息集合通常也可以不同。例如，电子支付业务的业务处理和文件加密的业务处理各自所需的业务信息集合不同，即使是电子支付业务的业务处理根据支付的类型不同，比如网银支付、扫码支付等，所需的业务信息集合(也即，第一业务信息集合)也可以不同。

对于电子支付业务的业务处理，服务器要完成该支付需要接收用户提交的支付渠道信息、支付鉴权信息以及同意支付相关协议的信息等，其中，支付渠道是指资金流动的载体，在实际应用中可以为工行借机卡渠道，农行信用卡渠道等，支付鉴权信息用于校验用户的身份和/或权限，在实际应用中可以为密码、指纹、智能卡等。在处理该电子支付业务的过程中，进行该电子支付业务的业务处理所需要的信息就是第一业务信息集合。在实际应用中，在接收第一业务信息后，既可以是根据第一业务信息集合实时地进行电子支付业务处理，在特殊的应用场景下也可以是非实时的进行电子支付业务处理，例如预约支付等。

步骤12：业务服务器判断所述电子支付业务处理是否失败，若是，则根据所述电子支付业务处理失败的类型确定是否生成重新支付入口，所述重新支付入口能够关联到第二业务信息集合，所述第二业务信息集合为调整导致电子支付业务处理失败的第一业务信息集合中对应元素后形成的集合。

电子支付业务处理过程中通常会出现业务处理失败的现象，这些失败现象可以由第一业务信息集合未通过验证引起，也可以由服务器等其它原因引起。因此，在实际应用中进行电子支付业务处理时，服务器通常需要监测该电子支付业务处理是否失败，并在电子支付业务处理失败时还可以记录电子支付业务处理失败的类型，以用于确定是否生成重新支付入口。

若生成了重新支付入口，则用户可以通过该重新支付入口，提交可与该重 新支付入口关联的第二业务信息集合，以便重新进行电子支付业务处理。第二业务信息集合即是指通过该重新支付入口进行电子支付业务处理时，用户所需要提交的业务信息的集合。在实际操作中用户可以通过电脑、手机、智能电视以及ipad等不同方式向服务器提交电子支付业务处理请求，因此服务器可生成的重新支付入口的形式可以包括：网页超链接和/或摇一摇感应器和/或手势识别器和/或表情识别器和/或触摸屏按钮等。

步骤13：业务服务器在生成重新支付入口并接收到所述重新支付入口被触发的指令后，利用所述第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理，所述第三业务信息集合为第一业务信息集合和第二业务信息集合的差集。

电子支付业务处理失败的类型有多种，例如，所选择的支付渠道余额不足、支付鉴权信息错误、操作超时、服务器异常、网络中断等。当电子支付业务处理失败时，业务服务器一方面根据电子支付业务处理失败的类型生成重新支付入口；另一方面业务服务器还需要确定用户通过该重新支付入口进行电子支付业务处理时，所需要用到的包含在第一业务信息集合中的第三业务信息集合，所述第三业务信息集合是所述第一业务信息集合的非空子集。通常第一业务信息集合的非空子集可以有多种，甚至第三业务信息也可以为第一业务信息本身，但是需要说明的是，所述第三业务信息不为空集。

例如，在电子支付业务处理的过程中，业务服务器通常需要接收用户提交的支付渠道信息、支付鉴权信息以及同意支付相关协议的信息以便进行该电子支付业务处理。当该电子支付业务处理失败的类型为该支付渠道的余额不足时，那么第三业务信息集合有多种选取方式，例如可以选取第三业务信息集合为第一业务信息集合，或者选取第三业务信息集合为第一业务信息集合中除支付渠道信息之外的其它信息，或者也可以选取第三业务信息集合为支付鉴权信息和同意支付相关协议的信息中的任意一个。

在实际应用中，一种优选的方案是，所述第三业务信息集合是由所述电子 支付业务处理失败的类型所确定的所述第一业务信息集合的子集，也就是说所述第三业务信息集合是第一业务信息集合中导致电子支付业务处理失败的业务信息之外的其它业务信息。这样由电子支付业务处理失败的类型来确定第一业务信息集合中包含的，用户通过重新支付入口进行电子支付业务处理时所需要用到的第三业务信息集合。对于电子支付业务业务处理，第三业务信息集合的优选方案为支付鉴权信息和同意支付相关协议的信息的集合。

当重新支付入口被用户触发后，业务服务器接收用户通过重新支付入口提交的第二业务信息集合，并获取包含在第一业务信息集合中的第三业务信息集合，然后利用该第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理。

通常电子支付业务处理的第一业务信息集合可以包括：支付渠道信息、支付鉴权信息以及同意支付相关协议的信息等，如果在第一业务信息集合中由于支付渠道而导致支付失败，通常可以选取该支付鉴权信息以及该同意支付相关协议的信息等为第三业务信息集合，在重新支付入口被生成及触发后接收第二业务信息集合，并获取该第三业务信息集合，利用所述第二业务信息集合以及所述第三业务信息集合进行业务处理，需要说明的是，该第二业务信息集合通常可以为新的支付渠道信息。

特别的，业务服务器从第一业务信息集合中筛选出第三业务信息集合之后，通常会将第三业务信息集合进行存储。当重新支付入口入口被触发后，服务器接收用户提交的第二业务信息集合，并且获取所存储的第三业务信息集合，进行电子支付业务处理。在实际应用中，获取所存储的第三业务信息集合的方式有多种，其中一种优选的方案是：将所述重新支付入口和所述第三业务信息集合建立对应关系，当所述重新支付入口被触发时，通过所述对应关系获取所述第三业务信息集合。

采用实施例1提供的一种电子支付业务处理的方法进行电子支付业务处理，当根据第一业务信息集合进行的电子支付业务处理失败时，业务服务器可 根据业务处理失败的类型生成重新支付入口，接收用户通过重新支付入口提交的第二业务信息集合，第二业务信息集合为调整导致电子支付业务处理失败的第一业务信息集合中对应元素后形成的集合，并利用第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理，第三业务信息集合为第一业务信息集合和第二业务信息集合的差集。因此解决了现有技术中，当电子支付业务处理失败时，用户需要重新提交进行电子支付业务处理需要的全部业务信息，才能再次进行电子支付业务处理的问题，提高了用户的体验。

实施例2

在实施例1的步骤13中提到，业务服务器在生成重新支付入口并接收到所述重新支付入口被触发的指令后，利用所述第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理，所述第三业务信息集合为第一业务信息集合和第二业务信息集合的差集。其实在所述重新支付入口被触发之前，实施例还可以包括业务服务器将所述重新支付入口和所述第三业务信息集合建立对应关系；业务服务器在接收到所述重新支付入口被触发的指令时，通过所述对应关系获取所述第三业务信息集合。因此就构成了本申请的实施例2，本申请的实施例2与实施例1相比，除了实施例1中的步骤13之前多了步骤231、232和233，相应的步骤13变化为步骤23之外，其它步骤均相同，参考附图2。

步骤231：业务服务器在生成重新支付入口之时或之后生成唯一标识符。

唯一标识符是根据该电子支付业务处理生成的一串唯一的编号，通常可以通过guid生成唯一标识符，也可以通过递加的方式生成唯一标识符。

步骤232：业务服务器将所述唯一标识符和第三业务信息集合建立对应关系，以及将所述重新支付入口和所述唯一标识符建立对应关系。

业务服务器确定第三业务信息集合后，在所述唯一标识符和所述第三业务信息集合之间建立对应关系，这样当业务服务器获取该唯一标识符之后，可以 通过对应关系获取该第三业务信息集合。在实际应用中，所建立的这种对应关系有多种方式，可以是简单的将唯一标识符和第三业务信息集合关联，也可以是将唯一标示符添加在第三业务信息集合中，也可以是其它的方式，但只要将唯一标识符和第三业务信息集合之间建立对应关系，使得业务服务器获取该唯一标识符之后，可以通过对应关系获取该第三业务信息集合就不会影响本实施例的技术效果，因此本实施例在此并不对怎样建立对应关系以及建立什么样的对应关系作出限定。

业务服务器将所述重新支付入口和所述唯一标识符建立对应关系之后，当重新支付入口被触发时，业务服务器可以通过对应关系获取该唯一标识符。

需要说明的是，步骤232中的建立唯一标识符和第三业务信息集合对应关系，与建立重新支付入口和唯一标识符的对应关系所采用的方式可以不同，也可以相同。甚至在电子支付等实际应用中，当支付失败时，业务服务器通常还可以将重新支付入口和对应的唯一标识符一起返回给用户，再通过用户触发重新支付入口，将该唯一标示符返回给业务服务器。步骤232需要达到的技术效果之一是将重新支付入口和唯一标识符建立对应关系，当该重新支付入口被触发时，服务器能够通过这种对应关系获取该唯一标识符。

步骤23：业务服务器在生成重新支付入口并接收到所述重新支付入口被触发的指令后，利用所述第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理，所述第三业务信息集合为第一业务信息集合和第二业务信息集合的差集。

需要说明的是步骤231、232，将所述重新支付入口和所述第三业务信息集合通过唯一标识符相互关联，使得在重新支付入口被触发后，业务服务器能够获取所述第三业务信息集合。因此，步骤231、232可以在根据所述电子支付业务处理失败的类型生成重新支付入口之前，也可以在根据所述业务处理失败的类型生成重新支付入口之后，只要所述重新支付入口被触发时，已经执行步骤231、232，将第三业务信息和所述重新支付入口通过唯一标识符相互关联， 就不会影响本实施例的效果。

采用实施例2提供的一种电子支付业务处理的方法进行业务处理，通过生成的唯一标识符将重新支付入口和第三业务信息集合之间相互关联，使得该重新支付入口被触发时，业务服务器能够直接获取第三业务信息集合，而不需要用户进行提交。因此解决了现有技术中，当电子支付业务处理失败时，用户需要重新提交进行电子支付业务处理需要的全部业务信息，才能再次进行电子支付业务处理的问题，提高了用户的体验。

实施例3

在实施例2的步骤232中提到将所述唯一标识符和所述第三业务信息集合建立对应关系。其实，为了确保唯一标识符在一段时间内有效，还可以将唯一标识符和时间戳建立对应关系，所述时间戳用于记录所述唯一标识符生成时的时间，进而，可以基于唯一标识符与时间戳的对应关系获取第三业务信息集合。因此就构成了本申请的实施例3，本申请的实施例3与实施例2相比，“所述根据所述重新支付入口与唯一标识的对应关系获取所述唯一标识符，并通过所述唯一标识符获取所述第三业务信息集合”(记作步骤34)可以变化为步骤34a、34b、33c，其它步骤均相同，参考附图3。

步骤34a：在获取所述唯一标识符后，通过所述唯一标识符获取时间戳。

步骤34b：判断当前时间和所述时间戳所记录的时间之差是否小于预设时间阈值，若是，则执行34c。

特别的，在实际应用中时间阈值可以设置为5分钟(或者3分钟)，通过所述唯一标识符获取时间戳之后，在当前时间和时间戳所记录的时间之差小于5分钟时，说明唯一标识符有效，则执行步骤34c。

步骤34c：通过所述唯一标识符获取所述第三业务信息集合。

采用实施例3提供的一种电子支付业务处理的方法进行电子支付业务处理，通过唯一标识符与时间戳建立对应关系，使得该重新支付入口被触发时， 能够通过当前时间和所述时间戳所记录的时间之差是否小于预设时间阈值来判断唯一标识符是否有效，只有当唯一标识符有效时才能通过所述唯一标识符获取所述第三业务信息集合。因此在解决了当电子支付业务处理失败时，用户需要重新提交进行电子支付业务处理需要的全部业务信息，才能再次进行电子支付业务处理的问题之外，还通过为唯一标识符设置有效时间，解决了唯一标识符的时效问题。

实施例4

在实施例2的步骤232中提到将所述唯一标识符和所述第三业务信息集合建立对应关系。其实，为了确保任务只被处理一次，还可以将唯一标识符和状态信息建立对应关系，所述状态信息用于记录是否已经通过所述唯一标识符获取所述第三业务信息集合。因此就构成了本申请的实施例4，本申请的实施例4与实施例2相比，步骤232变化为步骤432，相应的步骤23变化为步骤43a、43b、43c、43d和43e，其它步骤均相同。

步骤432：将所述第三业务信息集合和状态信息分别与所述唯一标识符建立对应关系。

步骤43a：在所述重新支付入口被触发后，通过所述唯一标识符获取状态信息。

步骤43b：通过所述状态信息判断是否已经通过所述唯一标识符获取所述第三业务信息集合，若否，则执行45c；若是，则执行45d。

步骤43c：通过所述唯一标识符获取所述第三业务信息集合，然后执行步骤45e。

步骤43d：发送任务正在处理的提示信息。

步骤43e：利用第三业务信息集合以及接收的第二业务信息集合进行业务处理。

将第三业务信息集合和状态信息集合分别与唯一标识符建立对应关系，用 户触发重新支付入口之后，业务服务器能够获取唯一标识符，并通过该唯一标识符获取该状态信息，当该状态信息记录没有通过唯一标识符获取第三业务信息集合时，则获取第三业务信息集合并继续进行电子支付业务处理，当该状态信息记录已经通过唯一标识符获取过第三业务信息集合时，则可以向用户发送任务正在处理的提示信息。

在实际应用中，通过唯一标识符获取所述第三业务信息后，通常还需要将状态信息做原子更新，这样能够确保该重新支付入口被用户多次触发时操作的幂等性。也就是，通过唯一标识符获取所述第三业务信息集合后，需要及时对状态信息做出更新，记录第三业务信息集合已经被获取，这样能够确保用户多次触发该重新支付入口时，电子支付业务处理的操作只被执行一次，使得用户不会通过该重新支付入口多次支付。

采用实施例4提供的一种电子支付业务处理的方法进行电子支付业务处理，通过唯一标识符与状态信息建立对应关系，使得该重新支付入口被触发时，能够通过所述状态信息判断是否已经获取所述第三业务信息集合，只有当判断为否时才能通过所述唯一标识符获取所述第三业务信息集合。因此在解决了当电子支付业务处理失败时，用户需要重新提交进行电子支付业务处理需要的全部业务信息，才能再次进行电子支付业务处理的问题之外，还通过状态信息保证了业务只能被处理一次，解决了业务可能被多次处理的问题。

实施例5

在实施例1的步骤12中提到根据所述电子支付业务处理失败的类型决定是否生成重新支付入口，由于电子支付业务处理失败的类型有多种，因此这种根据所述电子支付业务处理失败的类型决定是否生成重新支付入口有多种方式。当所接收的第一业务信息包括业务处理鉴权信息时，提到根据所述业务处理失败的类型决定是否发送重新支付入口具体为，根据业务处理失败的类型是否包括业务处理鉴权信息错误决定是否发送重新支付入口。因此就构成了本申 请的又一实施例，实施例1的步骤11在本实施例变化为步骤51，实施例1的步骤13在本实施例变化为步骤53，相应的实施例1的步骤12在本实施例变化为步骤521、522和523，其它步骤均相同，参考附图4。

步骤51：接收进行电子支付业务处理需要的第一业务信息集合进行业务处理。

步骤521：判断所述电子支付业务处理失败的类型是否为所述电子支付鉴权信息错误，若否，则执行步骤532；若是则执行533。

步骤522：生成重新支付入口。

步骤523：结束所述电子支付业务处理并发送所述电子支付业务处理失败的类型对应的提示信息。

当所提交的第一业务信息集合中包含电子支付处理鉴权信息时，在电子支付业务处理失败的情况下，为了保证电子支付业务处理的安全，需要判断引起该电子支付业务处理失败的电子支付业务处理失败的类型是否包含电子支付鉴权信息错误，如果包含，则结束电子支付业务处理并向用户发送电子支付业务处理失败的类型的提示信息；如果不包含，则生成重新支付入口。另外，在实际操作中如果电子支付业务处理失败的类型包括操作超时等另外一些需要终止电子支付业务处理的电子支付业务处理失败的类型时，业务服务器通常也会结束电子支付业务处理并向用户发送电子支付业务处理失败的类型对应的提示信息。

采用实施例5提供的一种电子支付业务处理的方法进行业务处理，当第一业务信息集合中包含电子支付鉴权信息时，在电子支付业务处理失败的情况下需要检验电子支付业务处理失败的类型是否为电子支付鉴权信息错误，根据检验的结果确定是否生成重新支付入口，保证了电子支付业务处理的安全。因此在解决了当电子支付业务处理失败时，用户需要重新提交进行电子支付业务处理需要的全部业务信息，才能再次进行电子支付业务处理的问题之外，还解决了电子支付业务处理过程中安全性的问题。

实施例6

在实施例5的步骤51中提到接收进行电子支付业务处理需要的第一业务信息集合进行电子支付业务处理。第一业务信息集合可以包含第一业务处理渠道的信息，因此在步骤522生成重新支付入口之前，还可以包括判断所述电子支付业务处理是否有第二业务处理渠道，并根据判断结果生成及返回重新支付入口。因此就构成了本申请的又一实施例，实施例5的步骤51在本实施例变化为步骤61，相应的实施例5的步骤522在本实施例变化为步骤6221、6222和6223，其它步骤均相同。

步骤61：接收进行电子支付业务处理需要的第一业务信息集合进行电子支付业务处理，所述第一业务信息集合包含电子支付鉴权信息和第一业务处理渠道的信息。

步骤6221：判断所述电子支付业务处理是否有第二业务处理渠道，若是，则执行步骤6222；若否，则执行步骤6323。

步骤6222：将所述第一业务信息集合中的所述第一业务处理渠道的信息更改为所述第二业务处理渠道的信息并生成及返回重新支付入口。

所述第二业务处理渠道指所述电子支付业务处理能够使用的所述第一业务处理渠道之外的其它业务处理渠道。

步骤6223：结束所述电子支付业务处理并发送所述电子支付业务处理失败的类型对应的提示信息。

在本实施例中，用户提交的第一业务信息中包含业务处理鉴权信息和第一业务处理渠道的信息，当任务处理失败时，如果服务器检测任务失败的类型不包括业务处理鉴权信息错误，并且所述业务处理有可供替用的第二业务处理渠道，那么，服务器将第一业务信息中的第一业务处理渠道的信息更改为第二业务处理渠道的信息并发送重新支付入口给用户，则用户在触发重新支付入口进行业务处理时不需要输入业务处理鉴权信息和关于业务处理渠道的信息，也就 是说第二业务信息中不包含业务处理鉴权信息和关于业务处理渠道的信息。另外，服务器向用户发送重新支付入口时，还可以发送业务处理渠道更改的提示信息，用于提示用户业务处理渠道已经更改。

特别的，当业务处理失败的类型只是与第一业务处理渠道的信息相关，并且所述业务处理有可供替用的第二业务处理渠道时，服务器向用户发送重新支付入口，用户通过该重新支付入口进行业务处理，所需要提交的第二业务信息为空集，所述第二业务信息为空集包括用户通过该重新支付入口进行业务处理时，不需要向服务器提交第二业务信息。

对于电子支付业务业务处理，用户在电子支付时需要提交支付渠道的信息、支付鉴权信息以及同意支付相关协议的信息，在支付失败的条件下，如果支付失败的类型不包括电子支付鉴权信息错误，并且用户有资金额充足的第二支付渠道，则业务服务器将支付渠道更改为该第二支付渠道，并生成重新支付入口。这时，用户只需触发该重新支付入口就可以通过服务器完成电子支付。

采用实施例6提供的一种电子支付业务处理的方法进行电子支付业务处理，当第一业务信息集合中包含电子支付鉴权信息和第一业务处理渠道的信息时，在电子支付业务处理失败的情况下，如果电子支付业务处理失败的类型不包括电子支付鉴权信息错误并且有可供使用的第二业务处理渠道，那么用户通过业务服务器生成的重新支付入口进行电子支付业务处理时，所要输入的第二业务信息集合不包括电子支付鉴权信息和业务处理渠道信息。因此在解决了当电子支付业务处理失败时，用户需要重新提交进行电子支付业务处理需要的全部业务信息，才能再次进行电子支付业务处理的问题之外，还解决了电子支付业务处理过程中安全性的问题。

实施例7

实施例1的步骤11中提到接收进行电子支付业务处理需要的第一业务信息集合以便进行电子支付业务处理，其实在步骤11之前，实施例还可以包括 接收电子支付业务处理请求等步骤，这就构成了本申请的实施例7，实施例7与实施例1相比，除了步骤11之前增加步骤71a和步骤71b之外，其它步骤均相同，如附图5所示。

步骤71a：接收电子支付业务处理请求。

业务服务器接收用户提交的电子支付业务处理申请，通常用户会通过电脑、手机、智能电视以及ipad等不同方式向业务服务器提交电子支付业务处理请求。

步骤71b：根据所述电子支付业务处理请求返回第一业务信息入口。

第一业务信息入口为通过该第一业务信息入口提交第一业务信息集合进行所述电子支付业务处理。

业务服务器根据所接收的电子支付业务处理请求，向用户返回第一业务信息入口，用户通过第一业务信息入口来提交第一业务信息集合以便进行电子支付业务处理。第一业务信息集合是指处理所接收的业务所需要的用户信息，包括业务处理渠道的信息、电子支付鉴权信息以及同意相关协议信息等。业务服务器接收用户提交的电子支付业务处理请求后，向用户返回支付入口，用户通过该支付入口选择支付渠道、提交支付鉴权以及提交同意支付的相关协议等，这里的支付入口就是第一业务信息入口，相应的支付渠道信息、支付鉴权信息以及同意支付相关协议的信息等就是第一业务信息集合。另外，在实际应用中第一业务信息集合可以通过多次来提交，例如，用户可以先同意支付的相关协议，然后提交选择支付渠道的信息，之后再提交支付鉴权信息。

采用实施例7提供的一种电子支付业务处理的方法进行业务处理请求业务处理，服务器根据所接收的业务处理请求向用户返回第一业务信息入口，当业务处理失败时，根据业务处理失败的类型向用户返回重新支付入口，用户在通过重新支付入口进行业务处理的过程中，所提交的第二业务信息集合少于第一业务信息集合。从而。因此解决了现有技术中，当电子支付业务处理失败时，用户需要重新提交进行电子支付业务处理需要的全部业务信息，才能再次进行 电子支付业务处理的问题，提高了用户的体验。

实施例8

实施例8提供了一种电子支付业务处理方法，用于解决现有技术中在电子支付业务处理失败时，重新进行电子支付业务处理所需的操作较多，从而造成用户在电子支付业务处理时体验较差的问题。该方法的具体流程示意图如附图6所示，包括下述步骤：

步骤81：客户端提交进行电子支付业务处理需要的第一业务信息集合，以便业务服务器进行电子支付业务处理；

步骤82：客户端在所述电子支付业务处理失败时，触发重新支付入口，以便业务服务器利用所述第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理，所述重新支付入口为业务服务器根据所述电子支付业务处理失败的类型确定生成的能够关联到第二业务信息集合的入口，所述第二业务信息集合为业务服务器调整导致电子支付业务处理失败的第一业务信息集合中对应元素后形成的集合，所述第三业务信息集合为第一业务信息集合和第二业务信息集合的差集。

用户提交业务处理需要的第一业务信息集合以便业务服务器进行电子支付业务处理，当电子支付业务处理失败时，根据电子支付业务处理失败的类型生成并向用户呈现重新支付入口，用户触发该重新支付入口并提交第二业务信息集合，以便业务服务器利用该第二业务信息集合以及第三业务信息集合进行电子支付业务处理。

采用实施例8提供的一种电子支付业务处理的方法进行电子支付业务处理，当电子支付业务处理失败时，根据电子支付业务处理失败的类型生成并呈现重新支付入口，并通过该重新支付入口提交第二业务信息集合，以便业务服务器利用该第二业务信息集合以及包含在第一业务信息集合中的第三业务信息集合进行电子支付业务处理。因此解决了现有技术中，当电子支付业务处理 失败时，用户需要重新提交进行电子支付业务处理需要的全部业务信息，才能再次进行电子支付业务处理的问题，提高了用户的体验。

实施例9

实施例9提供了一种电子支付方法，用于解决现有技术中在电子支付失败时，重新进行电子支付所需要提交的信息较多，从而造成用户体验较差的问题。该方法的具体流程示意图如附图7所示，包括下述步骤：

步骤91：接收进行电子支付所需要的支付要素信息集合，以进行电子支付。

支付要素信息为进行该支付业务的业务处理所需要的信息。在实际应用中，根据支付业务的不同，对应的支付要素信息也可以不同。例如，通过信用卡支付时支付要素信息通常可以为该信用可的卡号、密码以及支付金额等；通过网银支付时支付要素信息通常可以为网银卡号、网银密码以及验证码等；通过扫描手机二维码支付时，支付要素信息通常可以用户账号信息、二维码信息以及金额等。在实际应用中，该支付要素信息通常可以为支付渠道信息、支付鉴权信息以及同意支付相关协议的信息等，其中，支付渠道是指资金流动的载体，在实际应用中可以为工行借机卡渠道，农行信用卡渠道等，支付鉴权信息用于校验用户的身份和/或权限，在实际应用中可以为密码、指纹、智能卡等。

在接收进行电子支付所需要的支付要素信息之后，进行电子支付。

步骤92：判断所述电子支付是否失败，若是，则执行步骤93。

在支付的过程中，通常会由于各种原因造成支付失败，例如所选择支付的银行卡余额不足、所选择支付的信用卡有额度限制、支付鉴权信息错误、网络中断等都会造成支付失败。因此，实际应用中，通常需要监控支付业务的业务处理是否失败，并且在电子支付失败时，还可以确定失败的类型。

步骤93：则根据所述电子支付失败的类型决定是否生成重新支付入口，所述重新支付入口能够关联到调整导致电子支付失败的支付要素后形成的新的支付要素。

在支付失败后，通常业务服务器需要根据该电子支付失败的类型，发送重新支付入口，以便用户重新进行支付。

在支付的过程中，为了加强支付的安全性，通常会对支付进行鉴权，因此支付要素信息中通常会包括支付鉴权信息。当电子支付失败的类型包括支付鉴权信息错误时，通常为了保证支付的安全性，不会生成重新支付入口。在实际应用中，如果用户才操作超时，通常也不会向生成重新支付入口。在电子支付失败时，通常可以根据具体的导致失败的类型，以及实际的需要判断是否需要生成重新支付入口。

步骤94：在生成重新支付入口并接受到所述重新支付入口被触发的指令时，利用所述新的支付要素以及所述支付要素信息集合中导致电子支付失败的支付要素以外的要素实现重新支付。

例如，步骤91中的支付要素信息可以为银行号、密码和支付金额，当由于该银行卡的余额不足而导致电子支付失败时，通常可以将该密码和该支付金额作为导致电子支付失败的支付要素以外的要素，用户通过重新支付入口重新进行支付时，只需要输入新的银行卡号即可，该新的银行卡号即为所述新的支付要素。

采用实施例9提供的一种电子支付方法，当根据支付要素信息集合进行的电子支付失败时，可根据该电子支付失败的类型决定是否生成重新支付入口，重新支付入口能够关联到调整导致电子支付失败的支付要素后形成的新的支付要素，然后接收用户通过该重新支付入口提交调整导致电子支付失败的支付要素后形成的新的支付要素，并利用所述新的支付要素以及所述支付要素信息集合中导致电子支付失败的支付要素以外的要素实现重新支付。因此解决了现有技术中，当电子支付失败时，用户需要重新提交进行电子支付需要的全部支付要素信息，才能再次进行该电子支付的问题，提高了用户的体验。

进一步地，对于步骤93，可以有多种实施方式，以下列举两种作为示例。

如果电子支付失败类型为支付渠道余额不足，则生成能够关联到余额充足 的支付渠道的重新支付入口。相应地，在这种情况下，对于步骤94，所述在接收到重新支付入口被触发的指令后，利用所述新的支付要素以及所述支付要素集合中导致电子支付失败的支付要素以外的要素实现重新支付，具体可以包括：在接收到重新支付入口被触发的指令后，利用所述余额充足的支付聚到以及支付要素信息集合中支付渠道以外的要素实现重新支付。

如果电子支付失败类型为支付渠道业务繁忙，则生成能够关联到业务空闲的支付渠道的重新支付入口，相应地，在这种情况下，对于步骤94，所述在接收到重新支付入口被触发的指令后，利用所述新的支付要素以及所述支付要素信息集合中导致电子支付失败的支付要素以外的要素实现重新支付，具体可以包括：在接收到重新支付入口被触发的指令后，利用所述业务空闲的支付渠道以及所述支付要素信息集合中业务繁忙的支付渠道以外的要素实现重新支付。

实施例10

基于与实施例1相同的发明构思，实施例10提供了一种电子支付业务处理装置。如附图8所示，该装置10包括：第一接收单元101、第一判断单元102、第一确定单元103、第二接收单元104、第一处理单元105，其中：

第一接收单元101，用于接收进行电子支付业务处理需要的第一业务信息集合，以便进行电子支付业务处理；

第一判断单元102，用于判断所述电子支付业务处理是否失败，若是，则触发第一确定单元103；

第一确定单元103，用于在所述电子支付业务处理失败时，根据所述电子支付业务处理失败的类型确定是否生成重新支付入口，所述重新支付入口能够关联到第二业务信息集合，所述第二业务信息集合为调整导致电子支付业务处理失败的第一业务信息集合中对应元素后形成的集合；

第二接收单元104，用于接收所述重新支付入口被触发的指令；

第一处理单元105，用于利用所述第二业务信息集合以及第三业务信息集 合中的元素进行电子支付业务处理，所述第三业务信息集合为第一业务信息集合和第二业务信息集合的差集；

采用实施例10提供的一种电子支付业务处理的装置进行电子支付业务处理，当根据第一业务信息集合进行的电子支付业务处理失败时，业务服务器可根据业务处理失败的类型生成重新支付入口，接收用户通过重新支付入口提交的第二业务信息集合，第二业务信息集合为调整导致电子支付业务处理失败的第一业务信息集合中对应元素后形成的集合，并利用第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理，第三业务信息集合为第一业务信息集合和第二业务信息集合的差集。因此解决了现有技术中，当电子支付业务处理失败时，用户需要重新提交进行电子支付业务处理需要的全部业务信息，才能再次进行电子支付业务处理的问题，提高了用户的体验。

实施例11

基于与实施例8相同的发明构思，实施例11提供了一种电子支付业务处理装置。如附图9所示，该装置20包括：提交单元201、触发单元202，其中：

提交单元201，用于提交进行业务处理需要的第一业务信息集合，以便进行电子支付业务处理；

触发单元202，用于在所述电子支付业务处理失败时，触发重新支付入口，以便业务服务器利用所述第二业务信息集合以及第三业务信息集合中的元素进行电子支付业务处理，所述重新支付入口为业务服务器根据所述电子支付业务处理失败的类型确定生成的能够关联到第二业务信息集合的入口，所述第二业务信息集合为业务服务器调整导致电子支付业务处理失败的第一业务信息集合中对应元素后形成的集合，所述第三业务信息集合为第一业务信息集合和第二业务信息集合的差集；

采用实施例11提供的一种电子支付业务处理的装置进行电子支付业务处理，当电子支付业务处理失败时，用户通过重新支付入口提交第二业务信息集 合，以便利用所述第二业务信息集合以及第三业务信息集合进行业务处理，第二业务信息集合为业务服务器调整导致电子支付业务处理失败的第一业务信息集合中对应元素后形成的集合，所述第三业务信息集合为第一业务信息集合和第二业务信息集合的差集。因此解决了现有技术中，当电子支付业务处理失败时，用户需要重新提交进行电子支付业务处理需要的全部业务信息，才能再次进行电子支付业务处理的问题，提高了用户的体验。

实施例12

基于与实施例9相同的发明构思，实施例12提供了一种电子支付装置。如图10所示，该装置30包括：第三接收单元301、第二判断单元302、第二确定单元303、第四接收单元304、第二处理单元305，其中：

第三接收单元301，用于接收进行电子支付所需要的支付要素信息集合，以进行电子支付；

第二判断单元302，用于判断所述电子支付是否失败，若是，则触发第二确定单元；

第二确定单元303，用于根据所述电子支付失败的类型决定是否生成重新支付入口，所述重新支付入口能够关联到调整导致电子支付失败的支付要素后形成的新的支付要素；

第四接收单元304，用于接受到所述重新支付入口被触发的指令；

第二处理单元305，用于利用所述新的支付要素以及所述支付要素信息集合中导致电子支付失败的支付要素以外的要素实现重新支付。

采用实施例12提供的一种电子支付装置，除了拥有实施例9中所提到的效果外，在实际应用中结合具体的设备还可以有一些其它的效果，比如当该装置结合手机时可以通过将功能相近的单元进行整合，可以进一步节省手机上的处理资源。

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

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

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

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

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

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

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

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

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

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