一种业务处理方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种业务处理方法及装置。

背景技术：

随着互联网技术和计算机技术的迅速发展，越来越多的业务都可以在互联网上进行。具体的，用户可以使用终端连接互联网，并通过互联网与服务器进行业务交互，从而获得服务器提供的服务。

在某些业务交互环节中，针对用户提出的业务处理请求，服务器可以提供的、用于处理该业务请求的业务处理方式可能不止一种，但是用户可能并非对每种业务处理方式都支持，因此，用户一般可以根据自己对各业务处理方式的支持情况以及偏好程度，从所述各业务处理方式选择一种业务处理方式，以便于服务器基于用户选择的业务处理方式，处理用户提出的业务请求。

在现有技术中，为了提高用户选择业务处理方式的效率，服务器一般可以向用户推荐该用户最近一次选择过的业务处理方式，这样的话，用户可能只要直接对服务器的推荐进行确定即可。

但是，在实际应用中，对于不同的场景，用户可能偏好不同的业务处理方式，则当场景的变化比较频繁时，用户可能并不想选择自己最近一次选择过的业务处理方式，这样的话，现有技术中向用户的推荐并没有派上用场，用户可能还需要向服务器查询自己其他的业务处理方式，浪费了服务器的资源。

例如，对于支付业务，上述的业务处理请求可以是支付请求，上述的业务处理方式可以是支付渠道。所述支付渠道可以是用借记卡支付、用信用卡支付、用第三方支付账号支付，等等。假定用户在最近的一次支付业务中，选择了用信用卡支付，而用户在下一次的支付业务中可能是在第三方支付平台上进行 的，因此，用户可能想要选择相应的第三方支付账号支付，而在现有技术中仍然会向用户推荐用信用卡支付的这种支付渠道，浪费了服务器的资源。

技术实现要素：

本申请实施例提供一种业务处理方法及装置，用以解决现有技术中向用户推荐业务处理方式的方式浪费服务器的资源的问题。

本申请实施例提供一种基于支付业务的业务处理方法及装置，用以解决现有技术中向用户推荐支付渠道的方式浪费服务器的资源的问题。

本申请实施例提供一种对历史业务处理数据的预处理方法及装置，用以解决现有技术中向用户推荐业务处理方式的方式浪费服务器的资源的问题。

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

接收用户的业务处理请求；

在预先划分的各历史业务处理数据集合中，确定与所述业务处理请求匹配的历史业务处理数据集合，其中，预先划分的各历史业务处理数据集合是预先根据不同的场景划分方式，从所述用户的各历史业务处理数据中划分得到的；

根据所述匹配的历史业务处理数据集合对应的业务处理方式排序，对所述业务处理请求进行处理。

本申请实施例提供的一种基于支付业务的业务处理方法，包括：

接收用户的支付请求；

在预先划分的各历史支付数据集合中，确定与所述支付匹配的历史支付数据集合，其中，预先划分的各历史支付数据集合是预先根据不同的场景划分方式，从所述用户的各历史支付数据中划分得到的；

根据所述匹配的历史支付数据集合对应的支付渠道排序，向所述用户推荐至少一种支付渠道，以及基于所述用户从所述至少一种支付渠道中选择出的支付渠道，对所述支付请求进行处理。

本申请实施例提供的一种对历史业务处理数据的预处理方法，包括：

获取用户的各历史业务处理数据；

根据不同的场景划分方式，从所述各历史业务处理数据中划分得到不同的历史业务处理数据集合；

分别确定每个所述历史业务处理数据集合对应的业务处理方式排序；

根据确定出的各业务处理方式排序，确定各所述场景划分方式的可信性表征值。

本申请实施例提供的一种业务处理装置，包括：

接收模块，用于接收用户的业务处理请求；

确定模块，在预先划分的各历史业务处理数据集合中，用于确定与所述业务处理请求匹配的历史业务处理数据集合，其中，预先划分的各历史业务处理数据集合是预先根据不同的场景划分方式，从所述用户的各历史业务处理数据中划分得到的；

处理模块，用于根据所述匹配的历史业务处理数据集合对应的业务处理方式排序，对所述业务处理请求进行处理。

本申请实施例提供的一种基于支付业务的业务处理装置，包括：

接收模块，用于接收用户的支付请求；

确定模块，用于在预先划分的各历史支付数据集合中，确定与所述支付匹配的历史支付数据集合，其中，预先划分的各历史支付数据集合是预先根据不同的场景划分方式，从所述用户的各历史支付数据中划分得到的；

处理模块，用于根据所述匹配的历史支付数据集合对应的支付渠道排序，向所述用户推荐至少一种支付渠道，以及基于所述用户从所述至少一种支付渠道中选择出的支付渠道，对所述支付请求进行处理。

本申请实施例提供的一种对历史业务处理数据的预处理装置，包括：

获取模块，用于获取用户的各历史业务处理数据；

划分模块，用于根据不同的场景划分方式，从所述各历史业务处理数据中划分得到不同的历史业务处理数据集合；

第一确定模块，用于分别确定每个所述历史业务处理数据集合对应的业务处理方式排序；

第二确定模块，用于根据确定出的各业务处理方式排序，确定各所述场景划分方式的可信性表征值。

本申请实施例通过上述至少一种技术方案，基于不同的场景划分方式划分出的各历史业务处理数据所属的场景可以不同，其中，与业务处理请求匹配的集合所属场景，与该业务处理请求所属场景的匹配程度较高，因此，对于所述匹配的集合对应的业务处理方式排序，该业务处理方式排序中顺序靠前的业务处理方式，很可能也是用户针对该业务处理请求，偏好程度较高的业务处理方式，从而，服务器可以将所述顺序靠前的业务处理方式推荐给用户，相比于现有技术中的推荐方式，由于本申请的这种推荐方式考虑了业务处理请求所属场景，因此，推荐准确性更高，减少了服务器的资源浪费。

附图说明

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

图1为本申请实施例提供的业务处理过程；

图2为本申请实施例提供的基于支付业务的业务处理过程；

图3为本申请实施例提供的对历史业务处理数据的预处理过程；

图4为本申请实施例提供的在实际应用中，一种可以实现所述对历史业务处理数据的预处理过程的业务模型；

图5为本申请实施例提供的在实际应用中，一种对于是否执行所述业务处理过程的决策方法；

图6为本申请实施例提供的业务处理装置结构示意图；

图7为本申请实施例提供的基于支付业务的业务处理装置结构示意图；

图8为本申请实施例提供的对历史业务处理数据的预处理装置结构示意图。

具体实施方式

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

在本申请实施例中，为了解决背景技术中提出的问题，服务器当接收到用户的业务处理请求后，可以根据用户的各历史业务处理数据，推测用户在不同的场景下偏好的业务处理方式，并优先向用户推荐该业务处理方式，从而，可以提高用户选择业务处理方式的效率，节省服务器的资源。下面进行详细说明。

在本申请实施例中，对于不同的业务，所述场景的具体信息可能不同。

例如，对于支付业务，所述业务处理请求可以是支付请求，所述业务处理方式可以是支付渠道。在这种情况下，所述场景的具体信息可以是：支付金额的大小，购买的商品的类型，是否是支付失败后重试支付，等等。假定服务器为用户提供了3种支付渠道，分别为：用借记卡支付、用信用卡支付、用第三方支付账号支付。

用户可能会根据支付金额的大小，选择不同的支付渠道。如，当支付金额不大于100元时，用户可能偏好于用借记卡支付，当支付金额大于100元时，用户可能偏好于用信用卡支付；当用户购买食品等小件商品时，可能偏好于用第三方支付账号支付，当购买家电等大件商品时，可能偏好于用信用卡支付；当用户在用借记卡或信用卡支付失败之后，可能偏好于用第三方支付账号重试支付，等等。

图1为本申请实施例提供的业务处理过程，具体包括以下步骤：

S101：接收用户的业务处理请求。

本申请实施例提供的业务处理方法的执行主体可以是服务器，所述服务器包括但不限于：大中型计算机、计算机集群、个人计算机等。所述的执行主体并不构成对本申请的限定。

S102：在预先划分的各历史业务处理数据集合中，确定与所述业务处理请求匹配的历史业务处理数据集合，其中，预先划分的各历史业务处理数据集合是预先根据不同的场景划分方式，从所述用户的各历史业务处理数据中划分得到的。

为了便于描述，以下可以将“历史业务处理数据集合”简称为“集合”。

在本申请实施例中，可以预先根据不同的场景划分方式，从用户的各历史业务处理数据中划分得到不同的集合。其中，各所述历史业务处理数据可以分别用数据库中的一条记录进行表示，在该条记录中可以包含多个键值(Key-Value)对，这些键值对可以记录：用户编号、业务编号、生成时间、业务处理方式，等等。可以将“条”作为所述历史业务处理数据的单位进行描述。

所述场景划分方式可以反映：所述场景划分方式对应的每个集合中包含的各历史业务处理数据所属的场景。因此，划分集合也可以认为是在划分场景，所述场景划分方式包括的内容越多，则可能生成越多的集合，相应地可能反映出越多的场景(同时，每个场景的范围可能越小)。

在本申请实施例中，所述场景划分方式具体可以包括：根据重试处理的次数、处理类型和业务参数的大小中的至少一种，对历史业务处理数据进行划分的方式。

在步骤S102中，“确定与所述业务处理请求匹配的历史业务处理数据集合”具体可以包含两组动作，如下：

第一，从预设的各场景划分方式中，为用户确定一种场景划分方式，以使得根据该场景划分方式，划分出的各场景与用户实际的各场景相互对应的程度 较高，这样的话，可以认为该场景划分方式比较适用于该用户。

仍以支付业务为例进行说明，假定用户当支付金额不大于100元时，偏好于用借记卡支付，当支付金额大于100元时，偏好于用信用卡支付。这样的话，可以将“区分支付金额大小”以及“以100元为区分支付金额大小的区分点”作为场景划分方式，可以看到，该场景划分方式下有两种取值组合(一种是支付金额不大于100元，另一种是支付金额大于100元)，根据每一种取值组合都可以划分出一个集合，其中一个集合(称为集合1)中的各历史业务处理数据包含的支付金额不大于100元(属于支付金额不大于100元的场景)，另一个集合(称为集合2)中的各历史业务处理数据包含的支付金额大于100元(属于支付金额大于100元的场景)。可以看到，该例中的场景划分方式是适用于用户的。

需要说明的是，可以将上述根据取值组合划分出的两个集合称为：该场景划分方式对应的集合。

在该例中，由于是对用户的偏好进行了假定，因此，可以比较准确地为用户确定出适用的场景划分方式。但是，在实际应用中，除非用户预先在服务器上设定自己的偏好，否则服务器不一定能直接确定出为用户确定出适用的场景划分方式，因此，服务器可以预设不同的场景划分方式，进而根据各场景划分方式和用户的各历史业务处理数据(具体方法在后面会进行阐述)，从各场景划分方式中确定出一种场景划分方式，作为服务器推测出的适用于用户的场景划分方式。

第二，服务器在确定出场景划分方式后，可以进一步地在该场景划分方式对应的各集合中，确定与用户的业务处理请求匹配的集合。需要说明的是，所述匹配的集合可以指：在该场景划分方式对应的各集合中，所属的场景与用户的业务处理请求所属的场景匹配程度较高(也可能是最高)的至少一个集合。

仍用上例继续说明，假定用户的支付请求中包含的支付金额为500元，则该支付请求属于支付金额大于100元的场景，而并不属于支付金额不大于100 元的场景，因此，对于集合1和集合2，服务器可以将集合2确定为与该支付请求匹配的集合。

需要说明的是，根据上例中的场景划分方式可以划分出两个集合。在实际应用中，所述场景划分方式还可以包含更多内容，相应的，根据所述场景划分方式可以划分出更多个数的集合。

S103：根据所述匹配的历史业务处理数据集合对应的业务处理方式排序，对所述业务处理请求进行处理。

在本申请实施例中，可以预先针对每个集合，分别确定出该集合对应的业务处理方式排序。下面对所述业务处理方式排序进行说明。

所述集合中可以包含有多条历史业务处理数据，对于其中的任一条历史业务处理数据，该历史业务处理数据可以对应于用户曾发送过的一个历史业务处理请求，服务器是基于用户选择的某业务处理方式，对该历史业务请求进行处理后，生成的该历史业务处理数据，该历史业务处理数据中可以包含该业务处理方式。

在所述业务处理方式排序中，可以记录对应的集合中包含的各业务处理方式的顺序；其中，各业务处理方式的顺序可以是根据各业务处理方式的评分确定，例如，评分越高的业务处理方式在业务处理方式排序中的顺序越靠前。

业务处理方式的评分用于反映：基于该集合，可以推测出的用户对各业务处理方式的偏好程度。业务处理方式的评分越高，则用户可能越偏好该业务处理方式。

在本申请实施例中，可以根据步骤S103中的业务处理方式排序中顺序最靠前(或顺序靠前)的业务处理方式，对所述业务处理请求进行处理。在实际应用中，所述处理可以是将顺序最靠前的业务处理方式推荐给用户(在本申请中所述处理主要指这种)，也可以是直接采用该顺序最靠前的业务处理方式，对所述业务处理请求进行处理，等等。

通过上述方法，根据在上述步骤S102中的说明，由于与业务处理请求匹 配的集合所属场景，与该业务处理请求所属场景的匹配程度较高(也可能是最高)，因此，对于所述匹配的集合对应的业务处理方式排序，该业务处理方式排序中顺序靠前的业务处理方式，很可能也是用户针对该业务处理请求，偏好程度较高的业务处理方式，从而，服务器可以将所述顺序靠前的业务处理方式推荐给用户，相比于现有技术中的推荐方式，由于本申请的这种推荐方式考虑了业务处理请求所属场景，因此，推荐准确性更高，减少了服务器的资源浪费。

继续对所述业务处理方式排序进行说明。

在本申请实施例中，可以按照如下方法，确定历史业务处理数据集合对应的业务处理方式排序：根据所述历史业务处理数据集合中的各历史业务处理数据的生成时间，以及所述各历史业务处理数据包含的业务处理方式，确定所述业务处理方式的评分；根据各业务处理方式的评分，确定所述历史业务处理数据集合对应的业务处理方式排序。

其中，历史业务处理数据集合对应的业务处理方式排序可以是服务器预先确定的，也可以是服务器在接收到用户的业务处理请求后确定的。

进一步的，为了便于理解，采用具体公式对确定业务处理方式的评分的方法进行说明。

将今天(也即，当前这一天)记作第T天，将昨天记作第T-1天，以此类推，将在今天之前N天(例如，在实际应用中，N的取值一般可以为180或90，等等)的那一天记作第T-N天。

假定某个历史业务处理数据集合是根据场景划分方式i划分得到的，则将该历史业务处理数据集合记作D_i。假定D_i中包含有用户j从第T-N天至第T-1天的历史业务处理数据，D_i中包含有C种业务处理方式(可以是对应于D_i包含的各历史业务处理数据的、该用户在第T-N天至第T-1天内选择过的业务处理方式)。

对于所述C种业务处理方式中的业务处理方式k，在D_i中包含的用户j在第t天的各历史业务处理数据中，有l_t条历史业务处理数据包含有业务处理方式 k，其中，T，t，N均为整数，T-180≤t≤T-1。那么，对于用户j，可以采用下面的公式(称为公式1)确定在第T天时，业务处理方式k在D_i中的评分

$f_{jk}^i=\underset{t=T-N}{\overset{T-1}{\Σ}}\frac{l_t}{T-t};$

其中，实际上是业务处理方式k在D_i中出现的加权次数之和，其中，为加权所使用的权重(也可以称为遗忘因子)，所述遗忘因子的意义是：对于用户在第t天选择业务处理方式k的次数，若第t天与第T天相隔越远，则用户在第t天选择业务处理方式k的次数对评分的影响更小。

需要说明的是，仅为所述遗忘因子的其中一种表示形式，所述遗忘因子也可以有其他的表示形式。例如，所述遗忘因子还可以表示为等等；其中，a为正整数。在实际应用中，符合所述遗忘因子的意义的所述遗忘因子的表现形式均可以采用。

在本申请实施例中，服务器可以基于各场景划分方式的信用性表征值，从各场景划分方式中确定出一种场景划分方式(所述确定的具体实施方法在后面进行阐述)，作为服务器推测出的适用于用户的场景划分方式。下面进行具体说明。

场景划分方式的可信性表征值用于表征该场景划分方式对用户的适用程度，场景划分方式的可信性表征值越大，该场景划分方式对用户的适用程度越高，相应的，后续根据按照该场景划分方式划分出的各集合，确定出的、用于推荐给用户的业务处理方式可能越符合用户的偏好。

根据上述说明，对于上述步骤S102，确定与所述业务处理请求匹配的历史业务处理数据集合，具体可以包括：根据各场景划分方式的可信性表征值，从可信性表征值最大的场景划分方式对应的各历史业务处理数据集合中，确定出与所述业务处理请求匹配的历史业务处理数据集合；其中，场景划分方式的 可信性表征值是根据所述场景划分方式对应的各历史业务处理数据集合确定出的。

进一步的，可以按照如下方法，确定场景划分方式的可信性表征值：获取保存的所述用户的历史业务处理请求，以及对所述历史业务处理请求的处理结果，将对所述历史业务处理请求的处理结果作为标准结果；根据由所述场景划分方式划分出的各历史业务处理数据集合对应的业务处理方式排序，对所述历史业务处理请求进行处理，得到处理结果，作为测试结果；将所述标准结果与所述测试结果进行比对，得到比对结果；根据所述比对结果确定所述场景划分方式的可信性表征值。

其中，场景划分方式的可信性表征值可以是服务器预先确定的，也可以是服务器在接收到用户的业务处理请求后确定的。

为了便于理解，也采用具体公式对确定场景划分方式的可信性表征值的方法进行说明。在此，沿用上述对确定业务处理方式的评分的方法进行说明时，使用的各假定条件。

对于用户j，可以采用下面的公式(称为公式2)确定在第T天时，场景划分方式i的可信性表征值

$p_j^i=\underset{t=T-N}{\overset{T-1}{\Σ}}\frac{s_{jt}^i}{T-t};$

下面对公式2进行说明。在实际应用，用户每天可能向服务器发送业务处理请求，因此，由于用户的历史业务处理数据可能是逐日增加的，相应的，服务器获取到的用户的各历史业务处理数据也在增加，服务器可以定期地(如每天一次)根据在当前时间获取的用户的各历史业务处理数据，划分集合以及确定各集合对应的业务处理方式排序。为了便于描述，可以将在第t天确定出的业务处理方式排序简称为：第t天的业务处理方式排序。

对于公式2，以t＝T-1为例，说明的含义。

获取保存的所述用户在第T-1天的历史业务处理请求，以及对所述历史业 务处理请求的处理结果(基于所述处理结果，可以确定对于第T-1天的历史业务处理请求，所述用户选择的业务处理方式)，将对所述历史业务处理请求的处理结果作为标准结果。

根据第T-2天的业务处理方式排序，针对第T-1天的历史业务处理请求，向用户推荐第T-2天的业务处理方式排序中评分最高的业务处理方式，作为测试结果。

通过比对各标准结果(用户实际选择的业务处理方式)与对应的测试结果(基于本申请的方法，向用户推荐的业务处理方式)，可以得到比对结果，所述比对结果可以是所述标准结果与对应的测试结果相同(也即，推荐成功)的次数，该次数记作也即，将上述中的t赋值为t＝T-1。

以上t＝T-1为例，说明了的含义，类似的，对于t在取值区间[T-N,T-1]内的各个取值，均可以计算出对应的在此不再赘述。

另外，可以看到，与公式1类似，在公式2中也加入了遗忘因子该遗忘因子的意义与公式1中的遗忘因子的意义是类似的。

在本申请实施例中，对于上述步骤S103，根据所述匹配的历史业务处理数据集合对应的业务处理方式排序，对所述业务处理请求进行处理，具体可以包括：在各业务处理方式中，按照所述业务处理方式排序从前至后的顺序，选择至少一种业务处理方式，推荐给所述用户；基于所述用户从推荐的各业务处理方式中选择出的业务处理方式，对所述业务处理请求进行处理。

在实际应用中，可以将本申请提供的业务处理方法应用于各种业务。例如，当应用于支付业务时，所述业务处理请求包括支付请求，所述历史业务处理数据包括历史支付数据，所述业务处理方式包括支付渠道；所述场景划分方式具体包括：根据是否为支付失败后的重试支付、是否为特定支付类型和支付金额中的至少一种，对历史业务处理数据进行划分的方式；其中，所述特定支付类型包括信用卡支付类型。

以上为本申请实施例提供的业务处理方法，基于同样的思路，本申请实施例还提供一种基于支付业务的业务处理方法。

图2为本申请实施例提供的支付过程，具体包括以下步骤：

S201：接收用户的支付请求。

S202：在预先划分的各历史支付数据集合中，确定与所述支付匹配的历史支付数据集合，其中，预先划分的各历史支付数据集合是预先根据不同的场景划分方式，从所述用户的各历史支付数据中划分得到的。

S203：根据所述匹配的历史支付数据集合对应的支付渠道排序，向所述用户推荐至少一种支付渠道，以及基于所述用户从所述至少一种支付渠道中选择出的支付渠道，对所述支付请求进行处理。

本申请实施例提供的支付方法的执行主体可以是服务器。

通过上述方法，服务器可以将所述支付渠道排序中顺序靠前的支付渠道推荐给用户，推荐的支付渠道有较高的可能性符合用户的偏好，可以减少服务器的资源浪费。

以上为本申请实施例提供的业务处理方法，以及基于支付业务的业务处理方法，基于同样的思路，本申请实施例还提供一种对历史业务处理数据的预处理方法，通过该预处理方法，服务器可以确定在业务处理方法需要用到的：历史业务处理数据集合对应的业务处理方式排序、场景划分方式的可信性表征值等数据。需要说明的是，所述预处理方法在可以执行所述业务处理方法之前预先执行完成，也可以在执行所述业务处理方法过程中执行。

图3为本申请实施例提供的对历史业务处理数据的预处理过程，具体包括以下步骤：

S301：获取用户的各历史业务处理数据。

S302：根据不同的场景划分方式，从所述各历史业务处理数据中划分得到不同的历史业务处理数据集合。

S303：分别确定每个所述历史业务处理数据集合对应的业务处理方式排 序。

S304：根据确定出的各业务处理方式排序，确定各所述场景划分方式的可信性表征值。

本申请实施例提供的对历史业务处理数据的预处理方法的执行主体可以是服务器。

通过上述方法，服务器可以获取到执行图1中的业务处理过程中所需要用到的数据(业务处理方式排序、各场景划分方式的可信性表征值等)，进而基于所述业务处理过程，可以解决背景技术中提到的问题。

对于图3中各步骤的具体实施方式，在对图1中的业务处理过程的说明中已经进行了详细的阐述，因此，在此仅简单地进行阐述。

在本申请实施例中，对于上述步骤S303，可以按照如下方法，确定历史业务处理数据集合对应的业务处理方式排序：根据所述历史业务处理数据集合中的各历史业务处理数据的生成时间，以及所述各历史业务处理数据包含的各业务处理方式，确定各业务处理方式的评分；根据各业务处理方式的评分，确定所述历史业务处理数据集合对应的业务处理方式排序。

在本申请实施例中，对于上述步骤S304，可以按照如下方法，确定场景划分方式的可信性表征值：获取保存的所述用户的历史业务处理请求，以及对所述历史业务处理请求的处理结果，将对所述历史业务处理请求的处理结果作为标准结果；根据由所述场景划分方式划分出的各历史业务处理数据集合对应的业务处理方式排序，对所述历史业务处理请求进行处理，得到处理结果，作为测试结果；将所述标准结果与所述测试结果进行比对，得到比对结果；根据所述比对结果确定所述场景划分方式的可信性表征值。

在实际应用中，可以采用相应的业务模型，实现本申请提供的对历史业务处理数据的预处理方法。下面仍以支付业务为例，对一种在实际应用中，可以实现所述预处理方法的业务模型进行说明。在这种情况下，所述业务处理请求可以是支付请求，所述历史业务处理数据可以是历史支付数据，所述业务处理 方式可以是支付渠道。

图4示出了该业务模型中包含的各个模块(用矩形方框表示)，各个模块之间的连接关系(用箭头线段表示)，以及各个模块可以输出的数据(用圆角方框表示)。

可以看到，图4中包含有1～N个划分模块、1～N个支付渠道排序模块、场景划分方式可信性表征值确定模块、场景划分方式优选模块。

每个划分模块可以用于：根据一种场景划分方式，从用户的各历史支付数据中划分出至少一个历史支付数据集合(为了便于描述，在图3中，针对每种场景划分方式，只示出了根据该场景划分方式，划分出的各历史支付数据集合中的一个历史支付数据集合，其他的历史支付数据集合未示出)。

每个支付渠道排序模块可以用于：确定其对应的历史支付数据集合的支付渠道排序。

场景划分方式可信性表征值确定模块可以用于：确定各种场景划分方式的可信性表征值。

场景划分方式优选模块可以用于：根据各种场景划分方式的可信性表征值，确定出一种优选的场景划分方式，这种优选的场景划分方式相比于其他场景划分方式，可能更适用于用户。一般的，场景划分方式优选模块可以将可信性表征值最大的场景划分方式，作为优选的场景划分方式。

场景划分方式优选模块在确定出优选的场景划分方式后，可以获取该优选的场景划分方式对应的各支付渠道排序，用于向用户推荐支付渠道。

在实际应用中，图4中的业务模型可以每天都进行训练，从而可能提高为用户推荐支付渠道的准确性。

为了进一步的帮助理解所述场景划分方式，下面举例对在实际应用中，可能会用到的场景划分方式进行说明，如下表1所示：

表1

可以看到在表1中一共示出了3种场景划分方式。

表1中的“二次支付数据”可以指：对于某笔交易，用户第一次支付时可能支付失败了，于是可以进行第二次支付(也即，重新支付)，假定第二次支付成功，则后续生成的支付数据可以称为：二次支付数据。

那么，对于表1中的“是否只使用二次支付数据”，若选择是，则可以从用户的各历史支付数据中，划分出各二次支付数据构成一个历史支付数据集合，若选择否，则用户的各历史支付数据构成一个历史支付数据集合。

表1中的“是否区分信用支付场景”可以指：是否根据用户的各历史支付数据包含的支付渠道(该支付渠道是否是用信用卡支付)，从所述各历史支付数据中划分集合。若选择是，可以将用包含的支付渠道为用信用卡支付的各历史支付数据，作为划分出的一个历史支付数据集合，将包含的支付渠道不为用信用卡支付的各历史支付数据，作为划分出的另一个历史支付数据集合。

在实际应用中，也可以采用另外一种方式区分信用支付场景。具体的，可以基于各历史支付数据的所属的业务场景进行划分，若用户在某业务场景下曾经用信用卡支付过，则可以将属于该业务场景的历史支付数据，均划分在对应的场景为“用信用卡支付”的支付数据集合中，从而可以加快服务器的处理速度。其中，历史支付数据的所属的业务场景一般可以根据历史支付数据中包含的业务编号确定。

表1中的“是否区分支付金额的大小”可以指：是否根据用户的各历史支付数据包含的支付金额的大小，从所述各历史支付数据中划分集合。若选择是，则还可以指定区分支付金额的大小的区分点。例如，在表1中的第一种场景划 分方式下指定的区分点为100元。

在实际应用中，根据第1种划分方式，可能可以划分出4个对应于第1种划分方式的历史支付数据集合；类似的，根据第2种划分方式，可能可以划分出2个对应于第2种划分方式的历史支付数据集合；根据第N种划分方式，可能可以划分出1个对应于第2种划分方式的历史支付数据集合。

在本申请实施例中，若服务器未保存有用户的历史业务处理数据，或者，若服务器在较长一段时间没有与用户进行过业务交互，则由于历史业务处理数据数量不足，可能降低后续推荐业务处理方式时的准确率。在这种情况下，则也可以不采用本申请提供的方法，而是可以随机地为用户推荐业务处理方式，从而可以降低服务器的处理负担。进一步的，服务器可以在获取到用户的设定数量的历史业务处理数据后，再开始执行本申请提供的方法。

图5为本申请实施例提供的在实际应用中，一种对于是否执行所述业务处理过程的决策方法。所述决策方法的执行主体可以是服务器，所述决策方法具体可以包括以下步骤：

S501：获取生成时间在设定日期范围内某用户的历史业务处理数据。

在实际应用中，所述设定日期范围可以是近1个月内、或近半年内、或近一年内，等等。

S502：判断获取到的历史业务处理数据的数量是否不小于预设阈值，若是，则执行步骤S503，否则，执行步骤S504。

S503：通过执行本申请提供的业务处理过程，向用户推荐业务处理方式。

S504：采用其他的推荐方法，向用户推荐业务处理方式。

以上为本申请实施例提供的业务处理方法、基于支付业务的业务处理方法、以及对历史业务处理数据的预处理方法，基于同样的思路，本申请实施例还提供相应的业务处理装置、基于支付业务的业务处理装置、以及对历史业务处理数据的预处理装置，如图6、图7、图8所示。

图6为本申请实施例提供的业务处理装置结构示意图，具体包括：

接收模块601，用于接收用户的业务处理请求；

确定模块602，用于在预先划分的各历史业务处理数据集合中，确定与所述业务处理请求匹配的历史业务处理数据集合，其中，预先划分的各历史业务处理数据集合是预先根据不同的场景划分方式，从所述用户的各历史业务处理数据中划分得到的；

处理模块603，用于根据所述匹配的历史业务处理数据集合对应的业务处理方式排序，对所述业务处理请求进行处理。

所述确定模块602具体用于：根据各场景划分方式的可信性表征值，从可信性表征值最大的场景划分方式对应的各历史业务处理数据集合中，确定与所述业务处理请求匹配的历史业务处理数据集合；其中，场景划分方式的可信性表征值是根据所述场景划分方式对应的各历史业务处理数据集合确定的。

所述确定模块602还用于按照如下方法，确定场景划分方式的可信性表征值：获取保存的所述用户的历史业务处理请求，以及对所述历史业务处理请求的处理结果，将对所述历史业务处理请求的处理结果作为标准结果；根据由所述场景划分方式划分出的各历史业务处理数据集合对应的业务处理方式排序，对所述历史业务处理请求进行处理，得到处理结果，作为测试结果；将所述标准结果与所述测试结果进行比对，得到比对结果；根据所述比对结果确定所述场景划分方式的可信性表征值。

所述确定模块602还用于按照如下方法，确定历史业务处理数据集合对应的业务处理方式排序：根据所述历史业务处理数据集合中的各历史业务处理数据的生成时间，以及所述各历史业务处理数据包含的各业务处理方式，确定所述各业务处理方式的评分；根据各业务处理方式的评分，确定所述历史业务处理数据集合对应的业务处理方式排序。

所述处理模块603具体用于：在各业务处理方式中，按照所述业务处理方式排序从前至后的顺序，选择至少一种业务处理方式，推荐给所述用户；基于所述用户从推荐的各业务处理方式中选择出的业务处理方式，对所述业务处理 请求进行处理。

所述场景划分方式具体包括：根据重试处理的次数、处理类型和业务参数的大小中的至少一种，对历史业务处理数据进行划分的方式。

具体的上述如图6所示的装置可以位于服务器上。

图7为本申请实施例提供的基于支付业务的业务处理装置结构示意图，具体包括：

接收模块701，用于接收用户的支付请求；

确定模块702，用于在预先划分的各历史支付数据集合中，确定与所述支付匹配的历史支付数据集合，其中，预先划分的各历史支付数据集合是预先根据不同的场景划分方式，从所述用户的各历史支付数据中划分得到的；

处理模块703，用于根据所述匹配的历史支付数据集合对应的支付渠道排序，向所述用户推荐至少一种支付渠道，以及基于所述用户从所述至少一种支付渠道中选择出的支付渠道，对所述支付请求进行处理。

具体的上述如图7所示的装置可以位于服务器上。

图8为本申请实施例提供的对历史业务处理数据的预处理装置结构示意图，具体包括：

获取模块801，用于获取用户的各历史业务处理数据；

划分模块802，用于根据不同的场景划分方式，从所述各历史业务处理数据中划分得到不同的历史业务处理数据集合；

第一确定模块803，用于分别确定每个所述历史业务处理数据集合对应的业务处理方式排序；

第二确定模块804，用于根据确定出的各业务处理方式排序，确定各所述场景划分方式的可信性表征值。

所述第一确定模块803具体用于按照如下方法，确定历史业务处理数据集合对应的业务处理方式排序：根据所述历史业务处理数据集合中的各历史业务处理数据的生成时间，以及所述各历史业务处理数据包含的各业务处理方式， 确定各业务处理方式的评分；根据各业务处理方式的评分，确定所述历史业务处理数据集合对应的业务处理方式排序。

所述第二确定模块804具体用于按照如下方法，确定场景划分方式的可信性表征值：获取保存的所述用户的历史业务处理请求，以及对所述历史业务处理请求的处理结果，将对所述历史业务处理请求的处理结果作为标准结果；根据由所述场景划分方式划分出的各历史业务处理数据集合对应的业务处理方式排序，对所述历史业务处理请求进行处理，得到处理结果，作为测试结果；将所述标准结果与所述测试结果进行比对，得到比对结果；根据所述比对结果确定所述场景划分方式的可信性表征值。

具体的上述如图8所示的装置可以位于服务器上。

本申请实施例提供一种业务处理方法及装置，该方法包括：接收用户的业务处理请求；在预先划分的各历史业务处理数据集合中，确定与所述业务处理请求匹配的历史业务处理数据集合，其中，预先划分的各历史业务处理数据集合是预先根据不同的场景划分方式，从所述用户的各历史业务处理数据中划分得到的；根据所述匹配的历史业务处理数据集合对应的业务处理方式排序，对所述业务处理请求进行处理。通过上述方法，基于不同的场景划分方式划分出的各历史业务处理数据所属的场景可以不同，其中，与业务处理请求匹配的集合所属场景，与该业务处理请求所属场景的匹配程度较高，因此，对于所述匹配的集合对应的业务处理方式排序，该业务处理方式排序中顺序靠前的业务处理方式，很可能也是用户针对该业务处理请求，偏好程度较高的业务处理方式，从而，服务器可以将所述顺序靠前的业务处理方式推荐给用户，相比于现有技术中的推荐方式，由于本申请的这种推荐方式考虑了业务处理请求所属场景，因此，推荐准确性更高，减少了服务器的资源浪费。

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

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

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

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

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

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

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

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

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

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