一种业务操作所属业务类别的识别方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种业务操作所属业务类别的识别方法及装置。

背景技术：

随着信息技术的发展，一种称为个人与个人之间的电子商务(Customer to Customer，C2C)的服务架构得到了广泛应用。与服务提供商(如：网站)直接面向用户提供服务的模式不同，C2C服务架构采用的服务模式为：服务提供商为用户提供业务交互的平台，由一个用户面向另一个用户提供业务服务。

目前，在互联网技术的支持下，C2C服务架构中的用户所注册的账户，已然成为业务服务的接入口：具有服务资源的用户可以通过自身的账户向其他用户提供各类线上或线下业务，相应地，其他用户也可以通过自身的账户向提供服务的账户发出业务操作，获得所需业务。例如：用户使用自身账户向在线售卖商品的账户进行支付操作，获得所需的商品；又例如：用户使用自身账户向另一账户进行转账操作，获得线下的中介服务等。在C2C服务架构下，不仅用户所提供的业务纷繁复杂，而且不同账户之间可根据用户对业务的需求进行多样化的业务操作。基于此，在实际应用中也就可能存在账户间违规操作的现象(如：账户炒信操作，账户炒信是指通过违规支付以累计账户信誉度的操作)。为了降低或避免违规业务操作的出现，也为了对各类业务进行管理，服务提供商通常会针对不同账户间的业务操作进行监控识别。

现有技术中，对账户间业务操作的监控识别，往往是通过识别业务操作所属的业务类别来实现的。具体而言，服务提供商通常会根据进行业务操作的账户、业务操作发生的时间等因素来识别账户之间的业务操作所属的业务类别。 例如：当服务提供商的服务系统监测到某一账户在短时间内接收到大量的不相关账户发出的支付操作时，则服务系统会将这些支付操作识别为可疑操作(其所属的业务类别可能为炒信操作或者是骗款操作)。

但是，通过上述示例可见，根据现有技术中对业务操作的监控识别方式，仅能粗略识别出上述账户间的业务操作可疑，却不能识别出这些可疑操作具体的业务类别，也就是说，采用现有技术中的方式并不能较为准确地识别出业务操作的业务类别。

技术实现要素：

本申请实施例提供一种业务操作所属业务类别的识别方法及装置，用以解决现有技术中对业务操作所属的业务类别进行识别的准确率较低的问题。

本申请实施例提供的一种业务操作所属业务类别的识别方法，所述方法包括：

监测账户接收的业务操作；

当监测到所述账户接收到所述业务操作后，获取所述业务操作的业务信息；

根据预先设置的识别规则以及获取到的所述业务信息，识别所述业务操作所属的业务类别；其中，所述预先设置的识别规则包括：根据业务信息中包含的业务备注信息对所述业务操作进行识别、和/或根据进行所述业务操作的双方账户的业务类别对所述业务操作进行识别。

本申请实施例还提供的一种业务操作所属业务类别的识别装置，包括：

监测模块，用于监测账户接收的业务操作；

获取模块，用于当监测到所述账户接收到所述业务操作后，获取所述业务操作的业务信息；

识别模块，用于根据预先设置的识别规则以及获取到的所述业务信息，识别所述业务操作所属的业务类别；其中，所述预先设置的识别规则包括：根据 业务信息中包含的业务备注信息对所述业务操作进行识别、和/或根据进行所述业务操作的双方账户的业务类别对所述业务操作进行识别。

基于本申请实施例中提供的一种业务操作所属业务类别的识别方法及装置，当不同账户之间进行业务操作时，服务提供商后台的服务系统可以获取业务操作的业务信息，若获取到的业务信息中包含与该业务操作相关的业务备注信息，那么，服务系统可以根据预设的、针对业务备注信息的识别规则，对业务备注信息进行识别，以确定出业务操作的业务类别；此外，服务系统还可以根据预设的、针对业务操作的接收方账户的业务类别的识别规则，识别业务操作的业务类别。与现有技术相比，由于业务备注信息和业务操作的双方账户的业务类别，可以明确地反映出业务操作的目的，因此采用本申请中的识别方式，能够有效提升对业务操作所属的业务类别进行识别的准确性。

附图说明

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

图1为本申请实施例提供的业务操作所属业务类别的识别过程

图2为本申请实施例提供的业务操作所属业务类别的识别方法的具体应用实例的流程图；

图3为本申请实施例提供的业务操作所属业务类别的识别装置结构示意图。

具体实施方式

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

如前所述，在采用C2C业务服务架构的服务系统中，不同账户之间可自由进行各类业务操作，也就导致存在违规操作的可能，如：账户之间的炒信操作、虚假交易等。为了避免这类违规操作的现象，保证网络环境的公平性，同时，也为了对正常的账户进行管理，服务提供商就需要对在自身的服务系统内账户间的业务操作进行识别，并尽可能准确地确定出业务操作所属的业务类别。正是基于此，本申请实施例中提供了下述的业务操作所属业务类别的识别方法。如图1所示。

图1为本申请实施例提供的业务操作所属业务类别的识别过程，该过程具体包括以下步骤：

S101：监测账户接收的业务操作。

在本申请实施例中，所述的业务操作具体可以是账户之间为了获取或完成业务服务所进行的操作，包括但不限于：转账操作、付款操作等。不同用户通过自身的账户向提供业务的账户发出上述的业务操作后，便可以获得或完成相应的业务服务，但正如前述，用户所发出的业务操作有可能涉及违规操作，也就需要对接收方账户(为了方便描述，同时区别于发出业务操作的账户，在后续的说明内容中，将接收业务操作的账户称为接收方账户)所接收到的业务操作进行及时监测，以便后续对业务操作的业务类别进行识别。

S102：当监测到所述账户接收到所述业务操作后，获取所述业务操作的业务信息。

用户使用账户发出了业务操作后，通常都会生成相应的业务信息，而业务信息中包含了业务操作所有的明细内容，例如：业务操作发出方账户、接收方账户、转账或支付的额度、时间信息、业务备注信息等等。

换言之，业务信息能够反映出业务操作的多项特征和属性，也就可以通过所述业务信息来识别业务操作的业务类别，具体地，执行下述步骤S103。

S103：根据预先设置的识别规则及获取到的所述业务信息，识别所述业务操作所属的业务类别。

其中，所述预先设置的识别规则包括：根据业务信息中包含的业务备注信息对所述业务操作进行识别、和/或根据进行所述业务操作的双方账户的业务类别对所述业务操作进行识别。

所述的业务操作所属的业务类别，也就是业务操作所要获得或完成的具体业务的类别，例如：网络购物、代充值业务、订票业务、餐饮消费等等。本申请中的业务类别可由服务提供商(如：商品网站)预先定义，这并不构成对本申请的限定。

对于上述预先设置的识别规则而言：在本申请的一种实施例中，可以使用对业务备注信息进行识别的规则，来识别业务操作的业务类别。

在这种情况下，考虑到实际应用中，当用户使用自身账户向另一账户发出业务操作以获得业务服务(线上业务或线下业务)时，用户可能会针对该业务操作编辑输入相应的业务备注信息，具体地，在用户获得线上业务的情况下，用户所编辑输入的业务备注信息中通常包含用户对业务服务的要求，以告知提供业务的用户，例如：在线上购买商品的场景中，用户可能会在业务备注信息中说明所选择的商品的型号、颜色、尺寸，并说明期望的发货时间等，这些业务备注信息将发送给售卖商品的用户，从而为购买者提供相应的商品。相应地，在用户获得线下业务服务的情况下，用户所编辑输入的业务备注信息中通常包含用户的姓名、联系方式、以及本次业务操作的目的等，以便告知对方用户。

可见，如果业务信息中包含业务备注信息，那么对业务备注信息进行识别，就可以较为准确地确定出业务操作所对应的目标业务的类别，进而，也就能够确定出业务操作的业务类别，例如：如果某支付操作的业务备注信息为“黑色纯棉XXL款”，那么，可以根据该业务备注信息识别出用户所发出的本次支付操作是为了购买服装，进而，可以确定本次所发出的业务操作的业务类别为“网络购物(服装)”。这里只是以一示例进行说明，并不构成对本申请的限定。

在本申请的另一种实施例中，可以使用根据接收所述业务操作的账户的业务类别对所述业务操作进行识别的规则，来识别业务操作的业务类别。

在这种情况下，对于提供业务服务的接收方账户而言，可以认为，其他用户向该接收方账户发出的业务操作，就是为了获得该接收方账户所提供的业务服务，那么，如果能够确定出接收方账户所提供的业务服务所对应的业务类别，也就可以识别出向该账户发出的业务操作的类别，例如：如果已经确定出某账户提供代充值业务，那么，当该账户作为支付操作的接收方账户时，可以认为其接收到的支付操作是为了获得代充值业务，也即，可以将支付操作的业务类别确定为“在线代充值”。

从上述内容中可知，若对业务类别的定义足够详细，那么，采用本申请中的上述识别规则，不仅可以识别出账户间的违规的业务操作，还可以明确地识别出每一次业务操作所属的业务类别。此外，本申请中预设的识别规则，还可以包括针对接收方账户、发出方账户的位置信息进行识别、业务操作对象的类目(如：商品类目等)进行识别等等，这里并不构成对本申请的限定。

针对本申请的上述步骤需要说明是，考虑到实际应用时，发出业务操作的账户是在服务提供商的服务系统中所注册的，无论用户所进行的业务属于线上业务或线下业务，都需要通过账户间所进行的业务操作以完成业务，也就是说，这些业务操作需要服务系统的支持，故本申请中对账户所发出的业务操作的监测、识别，均可由服务提供商后台的服务系统完成。这里并不构成对本申请的限定。

通过上述步骤，当不同账户之间进行业务操作时，服务提供商后台的服务系统可以获取业务操作的业务信息，若获取到的业务信息中包含与该业务操作相关的业务备注信息，那么，服务系统可以根据预设的、针对业务备注信息的识别规则，对业务备注信息进行识别，以确定出业务操作的业务类别；此外，服务系统还可以根据预设的、针对业务操作的接收方账户的业务类别的识别规则，识别业务操作的业务类别。与现有技术相比，由于业务备注信息和业务操 作的双方账户的业务类别，可以明确地反映出业务操作的目的，因此，采用本申请中的识别方式，能够有效提升对业务操作所属的业务类别进行识别的准确性。

为了能够清楚地阐述本申请中针对业务操作所属业务类别的识别方法，下面将结合上述的识别规则进行详细说明。

一、预设的识别规则为根据业务信息中包含的业务备注信息对所述业务操作进行识别的情况

在该情况下，识别规则主要针对业务信息中所包含的业务备注信息。正如前述，在用户使用自身账户向提供服务的账户发起的业务操作中，可能会携带有用户所编辑输入的业务备注信息，同时，考虑到用户所编辑输入的业务备注信息通常是一种文本格式的信息，那么，对于上述步骤S103而言，当所述业务信息中包含业务备注信息时，根据预先设置的识别规则以及获取到的所述业务信息，识别所述业务操作的业务类别，具体包括：从所述业务信息中提取的所述业务备注信息，对所述业务备注信息进行文本识别处理，确定所述业务备注信息中包含的业务关键词，根据确定出的所述业务关键词，识别所述业务操作的业务类别。

在单次业务操作情况下，其业务备注信息中，可能会含有较为明确地与业务类别相关的文本信息，也即，业务关键词。所述的业务关键词，可以是反映不同业务类别的词组或文字，例如：业务关键词为“机票”、“改签”等，通过这两个业务关键词，可以明确地反映出业务的类别为“机票业务”。

对于服务系统而言，若要通过业务关键词确定出业务类别，就需要预先建立一种业务关键词与业务类别之间的对应关系，作为本申请实施例中的一种较优方式，服务系统中可以预先设备业务关键词库。那么，当所述账户在设定时间段内接收到单个携带有业务备注信息的业务信息时，上述步骤中，根据生成的所述业务关键词，识别所述业务操作的业务类别，具体包括：根据所述业务 关键词，在预先建立的业务关键词库中，确定与所述业务关键词相匹配的标准关键词，确定所述标准关键词在所述业务关键词库中所属的业务类别，将所述标准关键词所属的业务类别，确定为所述业务关键词所属的业务类别，根据所述业务关键词所属的业务类别，确定所述业务操作所对应的业务类别。

其中，所述标准关键词是所述业务关键词库中，分别针对每一业务类别预先定义的标准化的业务关键词。

从上述内容中可见，针对不同的业务类别，均可以预先定义与各个业务类别相关联的业务关键词(为了进行区别，将预先定义的业务关键词称为标准关键词)，形成业务关键词库。基于业务关键词库，就可以对业务备注信息中的业务关键词进行识别。

例如：假设某业务备注信息为“15日的UZ7308航班改签为16日的UZ3607航班”，通过对该业务备注信息进行文本处理，可以提取出“航班”、“改签”等业务关键词。同时假设，在业务关键词库中，业务类别为“机票业务”的业务所对应的标准关键词中包含“航班”、“改签”，从而，可以确定出业务关键词“航班”、“改签”的业务类别属于“机票业务”，进一步地，可以确定上述业务备注信息所对应的业务类别就为“机票业务”。

上述内容以及上例是在接收方账户接收到单个业务操作、且该业务操作的业务备注信息中包含明确的业务关键词的情况，在实际应用中，业务备注信息中所包含的某些业务关键词，可能并不会非常明确地反映出相应的业务类别，正如上例中的反映日期的词组“15日”、“16日”，以及航班号“UZ7308”、“UZ3607”，这些词组虽然不能较为明确地反映出业务类别“机票服务”，但若与上例中的业务关键词“航班”、“改签”结合，可强化业务备注信息与“机票服务”的相关性。因此，在本申请实施例中，所述的业务关键词库中，每一业务类别所对应的标准关键词还可以细分为下述三种类型：核心关键词、辅助关键词、剔除关键词。

具体而言，核心关键词是能够直观反映业务类别的词组，如：上例中的“航 班”、“改签”等；辅助关键词是与核心关键词同时出现能够强化业务类别相关性的词组，如：日期、航班号等；剔除关键词是与核心关键词同时出现能够弱化业务类别相关性的词组。通过对标准关键词种类的划分，可以更加准确地识别出不同的业务备注信息所属的业务类别。

需要说明的是，在实际应用场景下，接收方账户可能会在一段时间内接收到来自不同账户的多个业务操作，并不是每一个业务操作的业务信息中，都包含用户编辑输入的业务备注信息，某些用户使用账户发出业务操作时，并不会编辑输入业务备注信息，在所接收到的这些业务操作中，可能只有部分业务操作携带有业务备注信息，并且，所携带的业务备注信息所包含的业务关键词之间也可能具有一定的差异。那么，为了能够确定出业务操作所属的业务类别，在本申请实施例中，当所述账户在设定时间段内接收到多个携带有业务备注信息的业务信息时，根据确定出的所述业务关键词，识别所述业务操作的业务类别，具体包括：在预先建立的业务关键词库中，分别选定各业务类别对应的各标准关键词集合，根据选定的所述各标准关键词集合，统计所有业务备注信息中的业务关键词分别在所述各标准关键词集合中的命中次数，针对所述业务关键词库中的每一业务类别，确定统计出的所述命中次数与所述账户所接收到的多个携带有业务备注信息的业务信息的数量的比值，根据统计出的各命中次数以及所述比值，识别各业务关键词共同所属的业务类别，根据所述各业务关键词共同所属的业务类别，确定所述各业务操作共同所属的业务类别。

在业务关键词库中，每一业务类别都对应着多个标准关键词，故可以看作一个标准关键词集合。对于接收方账户所接收到的多个业务操作的业务备注信息而言，可能会命中业务关键词库内不同业务类别的标准关键词集合中的标准关键词，如果出现这类情况，那么，可以通过上述步骤确定出这些业务操作最有可能所属的业务类别。

下面以一具体应用实例对上述账户在设定时间段内接收到多个携带有业务备注信息的业务信息的情况下，对业务操作类别进行识别的过程进行说明、 分析。

在本实例的场景下，假设某接收方账户在一个月内接收到了60次业务操作，其中，有20次业务操作的业务信息中携带有业务备注信息。那么，对于服务系统而言，将具体执行如图2所示的下述步骤：

S201：在预先建立的业务关键词库中，分别选定各业务类别对应的各标准关键词集合。

本实例中，业务关键词库中的各业务类别，具体可以如下表1所示。

表1

其中，表1中仅示例性示出了不同的业务类别，在实际应用场景中，可以根据实际应用的需要，定义不同的业务类别，这里并不构成对本申请的限定。

如表1中所示出的各类业务类别，分别对应着各自的标准关键词集合(正如前述，每一标准关键词集合中都包含有多个核心关键词、辅助关键词以及剔除关键词)。

在本实例中，针对“汽车交易”和“专车服务”两个业务类别为例进行说明：

其中，假设“汽车交易”的标准关键词集合中，核心关键词包括：各类汽车品牌名称(这里不一一列出)、尊享型、舒适型、价格等等，辅助关键词包括：锁芯、钥匙适配、喷漆颜色等等。

假设“专车服务”的标准关键词集合中，核心关键词包括：各类汽车品牌名称、舒适型、司机姓名等等，辅助关键词包括：预约时间、预约地点、订单等等。

S202：针对各业务备注信息，进行文本格式化处理，得到待识别备注信息。

业务备注信息中可能包含由符号、文字、数字、标点等字符构成的文本信息，并且，这些文本信息的格式(如：大小写)各不相同，故在本步骤中将对业务备注信息进行文本格式处理，经过文本格式处理后的业务备注信息将形成统一的文本格式。

S203：根据选定的各标准关键词集合，统计待识别备注信息分别在各标准关键词集合中的命中次数。

以前述内容中的“汽车交易”和“专车服务”两个业务类别为例。首先，针对“汽车交易”的标准关键词集合，假设某一待识别备注信息中，包含有某一汽车品牌的名称，也就是说，该待识别备注信息命中了“汽车交易”的标准关键词集合中的核心关键词，因此，该核心关键词的命中次数+1。同理，根据待识别备注信息，统计出“汽车交易”这个业务类别下，核心关键词的命中次数以及辅助关键词的命中次数。

相类似地，还将统计出待识别备注信息在“专车服务”这个业务类别下，核心关键词的命中次数以及辅助关键词的命中次数(这里不再举例详细说明)。

这里需要说明的是，在某业务类别的标准关键词集合中，如果核心关键词的命中次数大于设定的核心命中阈值，那么，待识别备注信息在这个标准关键词集合中的总命中次数＝核心关键词命中次数+辅助关键词命中次数；

反之，若核心关键词的命中次数不大于设定的核心命中阈值，那么，待识别备注信息在这个标准关键词集合中的总命中次数＝核心关键词命中次数。

上述设定的核心命中阈值，反映了待识别备注信息整体落入标准关键词集合的分布趋势，设定的核心命中阈值的具体取值将根据实际应用的需要进行设定，这里并不构成对本申请的限定。

这里假设本实例中20个业务备注信息经过了文本处理后，在“汽车交易”这个业务类别下的命中次数为10，而在“专车服务”这个业务类别下的命中次数为3。

S204：确定每一业务类别下，统计出的所述命中次数与携带有业务备注信息的业务信息数量的比值。

在本实例中，携带有业务备注信息的业务信息的数量为20，在“汽车交易”和“专车服务”两个业务类别下，比值分别为10/20以及3/20。该比值也可以反映出业务备注信息在各业务类别下，命中可能性的分布。

S205：结合统计出的各命中次数以及所述比值，识别各业务备注信息共同所属的业务类别。

在本实例中，针对统计出的各命中次数以及所述比值，可以使用如下规则：在某一业务类别下，如果命中次数大等于第一命中阈值、且所述比值大等于第一比例阈值，那么，可以认为，该业务类别就是业务备注信息共同所属的业务类别；

或者，在某一业务类别下，如果命中次数大等于第二命中阈值、且所述比值大等于第二比例阈值，那么，也可以认为，该业务类别就是业务备注信息共同所属的业务类别。其中，这四种阈值可以根据实际统计的历史业务操作进行测算后得到，对阈值的测算并不构成对本申请的限定。

这里假设第一命中阈值为15、第一比例阈值为0.1、第二命中阈值为5、第二比例阈值0.2。在此条件下，针对本实例中20个业务备注信息，在“汽车交易”这个业务类别下的命中次数10大于第二命中阈值为5、且比值10/20＝0.5大于第二比例阈值0.2，从而，可以认为，本实例中的接收方账户在一个月内所接收到的60次业务操作所属的业务类型均为“汽车交易”。

以上是根据业务信息中包含的业务备注信息对所述业务操作进行识别的规则的说明。

二、识别规则为根据进行所述业务操作的双方账户的业务类别对所述业务操作进行识别的情况

在该情况下，首先将确定出双方账户所属的业务类别。作为本申请实施例 中的一种方式，可以采用概率的方式，来表示双方账户可能所属的业务类别，相应地，这个概率值也就可以反映出双方账户间所进行的业务操作所属的业务类别的可能性，具体而言，本申请实施例中，当所述预设的识别规则包括：根据进行所述业务操作的双方账户的业务类别对所述业务操作进行识别时，根据预先设置的识别规则以及获取到的所述业务信息，识别所述业务操作所属的业务类别，具体包括：根据所述业务信息，确定所述业务操作对应的待识别接收方账户和待识别发送方账户，确定所述待识别接收方账户和待识别发送方账户，分别在每一业务类别下的概率，根据所述概率，确定所述待识别接收方账户和待识别发送方账户共同所属的业务类别，将所述待识别接收方账户和待识别发送方账户共同所属的业务类别，识别为所述业务操作所属的业务类别。

为了便于清楚地阐述，现以识别“炒信操作”为例进行说明、分析。

在本示例中，双方账户所属的业务类别并不能够准确确定是否为“炒信操作”。

首先，针对接收方账户而言，为了得到其业务类别属于“炒信操作”的概率，将选定已识别为“炒信操作”的其他接收方账户。同时，考虑到实际应用中，不同的账户在历史上往往都进行过业务操作，就会生成相应的历史属性信息，如：最近一个月内在线购物次数、账户常用收货地所在省份等等。进行了相同业务类别的业务操作的账户之间，其历史属性信息就存在一定的共性。所以，在本示例中，针对所述待识别接收方账户执行以下操作：获取所述待识别接收方账户的各第一历史属性信息，以及已识别为所述业务类别的所有接收方账户的各第二历史属性信息，根据所述第一历史属性信息和第二历史属性信息，确定所述待识别接收方账户所属所述业务类别的概率。

具体而言，本示例中可以采用逻辑回归模型，来预测待识别接收方账户的业务类别是否属于“炒信操作”。其中，第一历史属性信息和第二历史属性信息，可以是：

1.最近一个月账户的购物笔数；

2.最近一个月账户净收入(收款获得的金额-购物的金额)；

3.最近一个月账户作为收款方的总收入；

4.购物覆盖的类目个数；

5.最近一个月账户总资金流水；

6.消费分群(根据账户的消费金额与频次进行的分群)；

7.最近一个月有多少账户给该账户付过款；

8.最近一个月给该账户付款的笔数；

9.最近三个月实物类消费笔数；

10.最近一次登录账户距今天数；

11.用户常用收获地址所在省份；

12.最近一个月给多少账户付过款。

在逻辑回归模型中，上述的12种历史属性信息可以作为模型的变量，经过模型的运算后，就可以得到待识别接收方账户的业务类别为“炒信操作”的概率。当然，本申请中对逻辑回归模型的使用不作出具体限定。同时，采用逻辑回归模型也仅是本申请实施例中的一种实现方式，这里并不构成对本申请的限定。

对于待识别发送方账户而言，针对所述待识别发送方账户执行以下操作：

确定历史上与所述待识别发送方账户进行过相同业务类别的业务操作的所有历史接收方账户，确定各历史接收方账户属于该业务类别的概率，并进行平均计算处理，将处理后生成的平均概率确定为所述待识别发送方账户所属所述业务类别的概率。

也就是说，将确定历史上与该待识别发送方账户进行过业务操作的所有接收方账户，并且可以按照上述待识别接收方账户确定概率的方式，来确定这些历史接收方账户属于“炒信操作”的概率，并且进行平均计算后，将概率均值作为该待识别发送方账户属于“炒信操作”的概率。

基于上述内容，如果双方账户属于“炒信操作”的概率之和大于某一设定 值(如：100％)，那么，也就可以认为，双方账户间所进行的业务操作的业务类型为“炒信操作”。

除了以上两种主要的识别方式外，本申请中的识别规则还可以包括根据账户的位置信息进行识别，以及根据业务操作对象的类目进行识别等。

具体而言，在实际应用场景中，存在着大量的实体店铺，这些实体店铺往往也会在相应的商品网站中注册自身的账户，在这种情况下，当消费者用户在实体店铺中购买了商品后，消费者用户可以使用自身的账户向该实体店铺的账户发起支付操作，从而完成整个购买过程。显然，在这种场景下，进行支付操作的双方账户的位置较为接近，并且，接收方账户(实体店铺对应的账户)的位置往往是固定的，那么，通过收集接收方账户和发送方账户之间的位置信息，可以确定出接收方账户是否为实体店铺对应的账户，若是，则可以进一步确定出该接收方账户所接收到的所有支付操作的业务类型均为“线下支付”。

而对于根据业务操作对象的类目进行识别的规则而言，以在线购买商品(或服务)为例，接收方账户会提供各类在线商品，每一种商品均具有相应的类目信息，那么，当用户使用账户针对某一种商品发出支付操作后，也就可以根据该商品的类目信息，确定出本次支付操作所属的业务类别。

通过本申请中所示出的以上不同的识别规则，可以有效且准确地识别出账户之间所进行的业务操作所属的业务类别，既能够识别出各类违规操作，也可以实现对不同业务类别的正常业务操作的管控。

此外，需要说明的是，在采用C2C业务服务架构的服务系统中，会设置一种专门用于为其他用户提供商品或服务的服务账户(如：商品网站中的卖方账户)，其他的用户通过自身的账户可向服务账户发出业务操作(如：支付操作)，以获得所需的商品或服务(如：通过卖方账户购买所需商品)。对于向服务账户发出的业务操作而言，服务提供商可根据该服务账户所提供的业务服务 的类型，较准确地确定出向该服务账户发出的业务操作的类型，例如：假设某一服务账户提供售卖商品，那么，服务提供商可以将其他账户向该服务账户发出的支付操作的类型确定为“购买操作”。然而，未注册为服务账户的普通账户(也即，非服务账户)之间也可以进行相应的业务操作，由于非服务账户并没有提供固定的业务服务，因此服务提供商也就不能准确地确定出向该非服务账户发出的业务操作的类型。

那么，在本申请实施例中，服务提供商会针对其中的所有账户进行监控，如：统计一个月内所有账户接收到的业务操作的数量，如果统计出非服务账户的一个月内所有账户接收到的业务操作的数量大于设定的阈值(如：50)，那么，服务提供商就会将这些非服务账户标记为异常账户(未标记为异常的账户均为正常账户)。那么，采用本申请中的方法，针对正常账户，可以使用上述第一种识别规则以及基于账户位置信息的识别规则，来识别业务操作所属的业务类型；针对异常账户，可以使用上述第一种以及第二种识别规则进行结合，来识别业务操作所属的业务类型。这里并不构成对本申请的限定。

至此，在本申请实施例中，使用上述所列出的识别规则，可以针对账户间的业务操作，可能得到多组识别结果：

1、单次业务操作中针对业务关键词的识别结果；

2、同一接收方账户在设定的时间段内接收到的多次业务操作的业务关键词的识别结果；

3、对于一次业务操作，接收方账户以及发送方账户所属某业务类别的概率；

4、根据业务操作的双方账户的位置信息的识别结果；

5、根据业务操作的操作对象类目的识别结果等等。

在这些识别结果中，1～3的识别结果将主要决定业务操作所属的业务类别，4～5的识别结果将在前3种识别结果的基础上，提供辅助作用。在1～3这三种 识别结果中，具有不同的判断优先级：1>2>3。当然，这并不构成对本申请的限定。

以上为本申请实施例提供的业务操作所属业务类别的识别方法，基于同样的思路，本申请实施例还提供一种业务操作所属业务类别的识别装置，如图3所示，包括：

监测模块U301，用于监测账户接收的业务操作。

获取模块U302，用于当监测到所述账户接收到所述业务操作后，获取所述业务操作的业务信息。

识别模块U303，用于根据预先设置的识别规则以及获取到的所述业务信息，识别所述业务操作所属的业务类别；其中，所述预先设置的识别规则包括：根据业务信息中包含的业务备注信息对所述业务操作进行识别、和/或根据进行所述业务操作的双方账户的业务类别对所述业务操作进行识别。

通过本申请的上述装置，当不同账户之间进行业务操作时，本装置可以获取业务操作的业务信息，若获取到的业务信息中包含与该业务操作相关的业务备注信息，那么，本装置中的识别模块303可以根据预设的、针对业务备注信息的识别规则，对业务备注信息进行识别，以确定出业务操作的业务类别；此外，本装置中的识别模块303还可以根据预设的、针对业务操作的双方账户的业务类别的识别规则，识别业务操作的业务类别。于现有技术不同的是，业务备注信息和业务操作的双方账户的业务类别，可以明确地反映出业务操作的目的，因此，采用本申请中的识别方式，能够有效提升对业务操作所属的业务类别进行识别的准确性。

具体地，当所述业务信息中包含业务备注信息时，所述识别模块U303，具体包括：提取子模块U3031、文本识别子模块U3032以及业务类别识别子模块U3033；当所述业务信息中包含业务备注信息时，所述提取子模块U3031，用于从所述业务信息中提取所述业务备注信息；

所述文本识别子模块U3032，用于对所述业务备注信息进行文本识别处 理，确定所述业务备注信息中包含的业务关键词；

所述业务类别识别子模块U3033，用于根据确定出的所述业务关键词，识别所述业务操作所属的业务类别。

在本申请的一种实施例中，所述业务类别识别子模块U3033，具体包括：标准关键词确定子模块、第一确定子模块、第二确定子模块、业务类别子模块。当所述账户在设定时间段内接收到单个携带有业务备注信息的业务信息时，所述标准关键词确定子模块，用于根据所述业务关键词，在预先建立的业务关键词库中，确定与所述业务关键词相匹配的标准关键词。其中，所述标准关键词是所述业务关键词库中，分别针对每一业务类别预先定义的标准化的业务关键词。

所述第一确定子模块，用于确定所述标准关键词在所述业务关键词库中所属的业务类别。

所述第二确定子模块，用于将所述标准关键词所属的业务类别，确定为所述业务关键词所属的业务类别。

所述业务类别子模块，用于根据所述业务关键词所属的业务类别，确定所述业务操作所属的业务类别。

在本申请的一种实施例中，所述业务类别识别子模块U3033，具体包括：标准关键词确定子模块、统计子模块、比值确定子模块、第一业务类别子模块、第二业务类别子模块。

当所述账户在设定时间段内接收到多个携带有业务备注信息的业务信息时，所述标准关键词确定子模块，用于在预先建立的业务关键词库中，分别选定各业务类别对应的各标准关键词集合。

所述统计子模块，用于根据选定的所述各标准关键词集合，统计所有业务备注信息中的业务关键词分别在所述各标准关键词集合中的命中次数。

所述比值确定子模块，用于针对所述业务关键词库中的每一业务类别，确定统计出的所述命中次数与所述账户所接收到的多个携带有业务备注信息的 业务信息的数量的比值。

所述第一业务类别子模块，用于根据统计出的各命中次数以及所述比值，识别各业务关键词共同所属的业务类别。

所述第二业务类别子模块，用于根据所述各业务关键词共同所属的业务类别，确定所述各业务操作共同所属的业务类别。

在本申请的一种实施例中，所述识别模块U303，具体包括：账户确定子模块、概率确定子模块、第一业务类别子模块、第二业务类别子模块。

当所述预设的识别规则包括：根据进行所述业务操作的双方账户的业务类别对所述业务操作进行识别时，所述账户确定子模块，用于根据所述业务信息，确定所述业务操作对应的待识别接收方账户和待识别发送方账户。

所述概率确定子模块，用于确定所述待识别接收方账户和待识别发送方账户分别在每一业务类别下的概率。

所述第一业务类别子模块，用于根据所述概率，确定所述待识别接收方账户和待识别发送方账户共同所属的业务类别。

所述第二业务类别子模块，用于将所述待识别接收方账户和待识别发送方账户共同所属的业务类别，识别为所述业务操作所属的业务类别。

在本申请的一种实施例中，所述识别模块U303，具体包括：接收方账户处理子模块以及发送方账户处理子模块。

所述接收方账户处理子模块用于在任一业务类别下，针对所述待识别接收方账户执行以下操作：

获取所述待识别接收方账户的各第一历史属性信息，以及已识别为所述业务类别的所有接收方账户的各第二历史属性信息，根据所述第一历史属性信息和第二历史属性信息，确定所述待识别接收方账户所属所述业务类别的概率；

所述发送方账户处理子模块，用于在任一业务类别下，针对所述待识别发送方账户执行以下操作：

确定历史上与所述待识别发送方账户进行过相同业务类别的业务操作的 所有历史接收方账户，确定各历史接收方账户属于该业务类别的概率，并进行平均计算处理，将处理后生成的平均概率确定为所述待识别发送方账户所属所述业务类别的概率。

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

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

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

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

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

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