CN101374280B - 一种业务开通提示系统及方法 - Google Patents

Abstract

本发明提供一种业务开通提示系统和方法，所述方法包括：接收用户的业务开通申请，获得所述业务上下文信息，或者获取用户上下文信息；根据所述业务上下文信息或用户上下文信息，获得该业务上下文信息或用户上下文信息所对应的业务相关信息；根据业务过滤策略对所述业务相关信息进行处理和过滤，生成业务需求信息；将所述业务需求信息反馈给所述用户。根据本发明提供的系统和方法，可以有效地发掘用户的业务需求，提升用户使用业务感受，并提高业务用户ARPU值。

Description

一种业务开通提示系统及方法

技术领域

本发明涉及电信领域的业务开通，尤其涉及一种基于上下文感知的用户业务开通提示系统及方法。

背景技术

随着第三代网络(3G：3rd Generation Network)和下一代网络(NGN：Next Generation Network)技术的不断发展，3G和NGN日益成为未来网络发展的必然趋势。在3G和NGN网络时代，针对个人用户和集团用户的新型增值电信业务将成为电信运营商大力发展的对象，被视为运营商未来收入的主要来源。

目前，增值业务的种类越来越多，运营商对业务的提供能力也越来越强。但是，目前的业务提供现状和用户的真正需求之间仍具有很大的差距，运营商无法准确掌握用户真正的业务需求，不能根据用户的不同需求定向开通业务或者向用户发送个性化的相关业务信息。在这种情况下，一方面，用户往往收到大量无用的业务信息，影响了用户的满意度；另一方面，面对繁杂的业务，用户无法方便快捷地找到适合自己需求的业务，导致潜在用户的流失，从而影响了运营商的业务使用收益。因此，运营商迫切的希望能够充分挖掘和反映用户需求的业务开通提示系统。

发明内容

本发明的主要目的在于，根据用户申请开通的业务，挖掘用户的业务上下文信息，并推断该用户的潜在业务需求。

本发明的另一目的在于，根据用户的上下文信息，挖掘用户的行为习惯，并推断出该用户的潜在业务需求。

本发明的另一目的在于，根据业务上下文模型的调整，动态灵活的调整用户需求业务的推断逻辑。

本发明的另一目的在于，根据业务过滤策略的调整，动态灵活的调整对业务需求进行过滤的方法和条件。

为了达成上述发明目的，本发明提供了一种基于上下文感知的用户业务开通提示系统和方法，该系统或方法是通过如下技术方案实现的：

一种业务开通提示系统，该系统包括：业务开通模块，用于向用户发送业务需求信息，应答用户提出的业务申请，为用户开通所述业务，并向业务上下文感知模块发送所述业务的业务信息；业务上下文感知模块或综合信息获取模块，业务上下文感知模块用于根据所述业务信息获取该业务对应的业务上下文信息发送到业务上下文分析模块，综合信息获取模块用于感知用户上下文信息，并发送到业务上下文分析模块；业务上下文分析模块，用于根据所述业务上下文信息或用户上下文信息获取所述业务上下文信息或用户上下文信息所对应的业务相关信息，发送到业务过滤模块；业务过滤模块，用于根据业务过滤策略对所述业务相关信息过滤，生成业务需求信息发送到业务开通模块，以便业务开通模块将该业务需求信息发送到用户，供用户选择需要开通的业务。

一种业务开通提示方法，该方法包括下列步骤：接收用户的业务开通申请，获得所述业务上下文信息，或者获取用户上下文信息；根据所述业务上下文信息或用户上下文信息，获得该业务上下文信息或用户上下文信息所对应的业务相关信息；根据业务过滤策略对所述业务相关信息进行处理和过滤，生成业务需求信息；将所述业务需求信息反馈给所述用户。

本发明的有益效果在于，可以有效地发掘用户的业务需求，提升用户感受，并提高用户ARPU值(ARPU：Average Revenue Per User，每用户平均收入)。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1为本发明实施例的系统结构框图；

图2为本发明实施例的工作流程示意图；

图3为本发明一应用实施例的流程图；

图4为本发明另一应用实施例的流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。

图1所示为本发明实施例的系统结构框图，请参照图1，本发明的业务开通提示系统包括：综合信息获取模块11、业务开通模块12、业务上下文感知模块13、业务上下文分析模块14、业务过滤模块15、业务上下文模型库16、业务上下文模型维护模块17、业务过滤策略库18、业务过滤策略维护模块19，其中：

综合信息获取模块11用于感知用户的上下文信息并传递给业务上下文分析模块，以供该业务上下文分析模块根据该用户上下文信息确定业务相关信息。该用户上下文信息包括：用户位置(时间、地点、采集频率)、漫游信息(时段、地点、漫游前位置)、用户基础电信业务使用信息(时间、对方号码、通信时长)等。根据本发明的实施例，该综合信息获取模块11可以通过传感器来实现。

业务开通模块12用于应答用户提出的业务申请，开通用户所需的业务；同时其可以用于向用户发送业务需求信息，供用户根据需要选择业务，进行业务开通申请；其还可以用于向业务上下文感知模块13传递用户所开通业务的业务信息。

业务上下文感知模块13用于根据业务开通模块12传递的业务信息，查询业务上下文模型库16，获取该业务所对应的业务上下文信息，并将该业务上下文信息发送至业务上下文分析模块14。

业务上下文分析模块14用于根据综合信息获取模块11传递的用户上下文信息，或者根据业务上下文感知模块13传递来的业务上下文信息，查询业务上下文模型库16，获取该业务上下文和/或用户上下文所对应的业务相关信息，并将该业务相关信息发送至业务过滤模块15。

业务过滤模块15用于将业务上下文分析模块14传递来的业务相关信息下对应的业务进行分类，生成业务分类信息，根据该业务分类信息查询业务过滤策略库18，根据查询得到的业务过滤策略对业务相关信息下的业务进行处理，生成业务需求信息发送给业务开通模块12。

需要说明的是，将业务分类的目的是为了匹配业务过滤策略库中的“业务策略的适用范围”，以便根据该适用范围选择过滤策略。由于业务的种类多种多样，并且还在持续增长中，因此，为了使过滤策略能够后向兼容新增业务在本发明中的应用，从而保持过滤策略在本发明系统中的稳定性。根据本发明实施例，可以对业务进行分组，每个分组对应一组过滤策略，每个过滤策略适用范围为一个或多个业务分组，每当增加新的业务时，将其划入对应的分类中，应用该分类中的过滤策略，在这种情况下，过滤策略可以不随着业务种类和数量的增加而发生变化。根据该实施例，可以将业务分组分成几大类，如公益类、广告类、单用户类、群用户类等等。新的业务开发出来后，根据该业务信息将该业务归属到对应业务分组中。举例说明，某业务被划分为公益类业务中，该业务只能被适用范围是公益类的过滤策略处理，对某一个适用范围是个体类业务的策略，该策略无法对该业务进行处理。

业务上下文模型库16用于保存业务上下文模型，并根据上下文感知模块13传递的业务信息，返回该业务的上下文信息；还根据业务上下文分析模块14传递的业务上下文信息，返回与业务上下文相关的业务相关信息；另外，其还根据业务上下文模型维护模块17的业务上下文模型的输入信息，动态调整保存的业务上下文模型。根据本发明的实施例，业务上下文信息包括：业务开通时间、业务有效时间、业务形式、业务资费、业务依托实物(如车辆违章罚款短信提示业务的依托实物为业务开通者有车)等。根据本发明的实施例，业务上下文模型库中的业务上下文模型采取“业务信息-业务上下文信息/用户上下文信息-业务相关信息”的形式进行标识，该形式标识表示业务上下文模型包含了业务信息、与业务信息相关联的业务上下文信息/用户上下文信息、以及与业务上下文信息/用户上下文信息相关联的业务相关信息，例如“车辆违章罚款短信提示业务(业务信息)-拥有车辆(业务上下文信息)-车辆维修广告(业务相关信息)等”。

业务上下文模型维护模块17用于对业务上下文模型库16进行维护，调整已有的业务上下文模型，增加新的业务上下文模型。

业务过滤策略库18用于存储业务过滤策略，并根据业务过滤模块15提供的业务分类信息，返回相应的业务过滤策略；该业务过滤策略库18还根据业务过滤策略维护模块19的业务过滤策略的输入信息，动态调整保存的业务过滤策略。根据本发明的实施例，业务过滤策略包括：策略名称、策略适用范围、过滤条件以及策略执行方式，其中过滤条件包括单过滤条件和复杂过滤条件。单过滤条件表示由单个过滤属性构成的过滤限制，如业务的某属性取值大于某个数；复杂过滤条件表示由多个过滤属性组合构成的过滤限制，如业务的某属性取值等于某个值，同时另外一个属性取值大于某个值。而策略执行方式包括：过滤该业务或推荐该业务。例如，业务过滤策略可以为：与广告无关的过滤策略，即将与广告相关的潜在业务需求过滤掉，仅向用户发送一些免费的业务需求，当认为用户处在较低消费意愿状态下，可以使用该策略；用户消费的过滤策略，选择与用户消费相关的业务需求，过滤掉其他无关的业务需求信息，当认为用户处在较高的消费意愿状态下，使用该策略；较多业务需求的过滤策略，将尽可能多的业务需求发送给用户，不做或少做过滤；较少业务需求的过滤策略，将尽可能少的业务需求发送给用户，将绝大多数的业务需求进行过滤。

这里需要说明的是，根据本发明的实施例，针对同一类业务分类信息，过滤策略的数量原则上是没有上限的，这也是为什么需要对策略进行维护的原因之一。而过滤策略的选择方式可以是随机的，而且可以是多轮的，只要不选择互斥的策略即可；也可以根据预定任意标准进行选择，本发明并不以此作为限制。根据本发明一实施例，针对同一类业务分类信息，选择业务过滤策略的方法可以包括下列步骤：

步骤1：接收业务信息和该业务信息对应的业务分类信息；

步骤2：根据该业务分类信息随机选择一策略对所述业务相关信息对应的业务进行过滤；

步骤3：判断过滤后获得的业务数量是否为零；如果结果为零，则进行步骤3，否则进行步骤5；

步骤4：原有业务信息不变，进行上述步骤2；

步骤5：判断过滤后的业务数量是否在系统预定范围内；如果结果为是，则进行步骤6，否则进行步骤7；

步骤6：将过滤后的业务对应的业务需求信息发送到用户端；

步骤7：将过滤后获得的业务信息作为新的业务信息，进行上述步骤2；

其中，多轮随机选择的策略相互之间不冲突。

举例说明，有10个相关业务，通过第一轮随机选择的策略过滤掉2个，假设系统预定业务需求的个数为小于等于5，则系统会再随机选择一个与之前的策略不冲突的策略进行过滤，过滤掉5个，剩余3个业务被认为是符合用户需求的，发送到用户端。

业务过滤策略维护模块19用于对业务过滤策略库18进行维护，调整已有的过滤策略，增加新的业务过滤策略。

图2所示为本发明实施例的工作流程示意图，以下结合图2对本发明的业务开通提示方法的流程进行说明。

首先，用户申请开通某业务，向业务开通模块发出定制业务请求；

业务开通模块接收所述定制业务请求，为所述用户开通所定制的业务，同时将该业务信息发送到业务上下文感知模块；

业务上下文感知模块根据所述业务信息查询业务上下文模型库，获得该业务对应的业务上下文信息，并将该业务上下文信息发送到业务上下文分析模块；

业务上下文分析模块根据所述业务上下文信息查询业务上下文模型库，获得该业务上下文信息对应的业务相关信息，并将该业务相关信息发送到业务过滤模块；

业务过滤模块将所述业务相关信息对应的业务进行分类，生成业务分类信息，并根据该业务分类信息查询业务过滤策略库，得到该用户的业务过滤策略，使用该业务过滤策略对所述业务相关信息对应的业务进行处理和过滤，并生成业务需求信息发送到业务开通模块；

业务开通模块将所述业务需求信息发送给所述用户。

其中，业务上下文模型库可以通过业务上下文模型维护模块对其进行维护，调整已有的业务上下文模型，或增加新的业务上下文模型等。

其中，业务过滤策略库可以通过业务过滤策略维护模块对其进行维护，调整已有的过滤策略，或增加新的业务过滤策略等。

其中，业务上下文分析模块还可以接收综合信息获取模块获取的用户上下文信息，并根据该用户上下文信息查询业务上下文模型库，获得该用户上下文信息对应的业务相关信息，发送到业务过滤模块。

下面列举两个实际应用中的例子以对本发明进行进一步详细说明。

图3为本发明一应用实施例的流程图，请参照图3，其是本发明根据业务上下文信息挖掘出用户潜在业务需求的一个实施例。如图3所示，用户开通“交通违章信息提醒”业务后，可以通过该业务的业务上下文模型定位出该用户拥有车辆，进而通过对“拥有车辆”这样的业务上下文进行分析，发现与该上下文相关的业务包括“车辆维修广告”、“车友俱乐部”、“汽车配件团购”等，将这些业务需求按照“广告无关”的策略(该策略的选择可以是随机的，也可以根据其他预定标准进行选择，本发明并不以此作为限制)进行过滤，得出“车友俱乐部”的业务需求。将该业务信息通过短信或其它方式传递给用户，供用户选择是否开通该业务。

图4为本发明另一应用实施例的流程图，请参照图4，其是本发明根据用户上下文信息挖掘出用户潜在业务需求的一个实施例。如图4所示，根据传感器对用户位置信息的定位，得到“用户地理位置”这一用户上下文，经过分析和抽取，获得“用户周末地理位置”的用户上下文信息，该用户上下文显示用户周末经常逛商场。查询业务上下文模型，获得“商场打折促销”、“商场附近饮食”、“股市行情-零售板块行情”等业务相关信息，使用“用户消费”的过滤策略(该策略的选择可以是随机的，也可以根据其他预定标准进行选择，本发明并不以此作为限制)，获得“商场打折促销”、“商场附近饮食”两个最终业务需求。将这两个业务需求信息通过短信或其它方式传递给用户，供用户选择是否开通这两个业务。

本发明使用建立业务关联模型的方法构建上下文感知系统，灵活地定制业务上下文/用户上下文和业务之间逻辑关系，其构造的上下文感知系统和方法可以根据模型的调整而动态调整上下文感知算法逻辑，具有更强的扩展性和灵活性。根据本发明提供的系统和方法，可以有效地发掘用户潜在的业务需求，提升用户满意度，从而提高业务ARPU值(ARPU：Average RevenuePer User，每用户平均收入)。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种业务开通提示系统，其特征在于，该系统包括：

业务开通模块，用于向用户发送业务需求信息，应答用户提出的业务申请，为用户开通所述业务；

业务上下文感知模块或者综合信息获取模块，业务上下文感知模块用于根据所述业务开通模块发送的所述业务的业务信息获取所述业务对应的业务上下文信息，并发送到业务上下文分析模块，综合信息获取模块用于感知用户上下文信息，并发送到业务上下文分析模块；

业务上下文分析模块，用于根据所述业务上下文信息或者用户上下文信息获取所述业务上下文信息或者用户上下文信息所对应的业务相关信息，并发送到业务过滤模块；

业务过滤模块，用于根据业务过滤策略对所述业务相关信息过滤，生成业务需求信息，并发送到所述业务开通模块，以便所述业务开通模块将所述业务需求信息发送给用户，供用户选择需要开通的业务。

2.根据权利要求1所述的系统，其特征在于，该系统还包括：

业务上下文模型库，与所述业务上下文感知模块相耦合，用于接收所述业务上下文感知模块传送的业务信息，并向所述业务上下文感知模块返回所述业务信息对应的业务上下文信息；

所述业务上下文模型库还与所述业务上下文分析模块相耦合，用于接收所述业务上下文分析模块传送的业务上下文信息或者用户上下文信息，并向所述业务上下文分析模块返回所述业务上下文信息或用户上下文信息对应的业务相关信息；

所述业务上下文模型库还用于存储业务上下文模型，所述业务上下文模型包括：业务信息，与所述业务信息对应的业务上下文信息，与所述业务信息对应的用户上下文信息，与所述业务上下文信息对应的业务相关信息，以及与所述用户上下文信息对应的业务相关信息。

3.根据权利要求2所述的系统，其特征在于，该系统还包括：

业务上下文模型维护模块，用于对所述业务上下文模型库进行维护，调整已有的业务上下文模型，和/或增加新的业务上下文模型。

4.根据权利要求3所述的系统，其特征在于，该系统还包括：

业务过滤策略库，与所述业务过滤模块相耦合，用于存储业务过滤策略，以便业务过滤模块根据业务相关信息的分类选择业务过滤策略，所述业务过滤策略包括：策略名称、策略适用范围、过滤条件、策略执行方式。

5.根据权利要求4所述的系统，其特征在于，该系统还包括：

业务过滤策略维护模块，用于对所述业务过滤策略库进行维护，调整已有的过滤策略，和/或增加新的业务过滤策略。

6.一种业务开通提示方法，其特征在于，该方法包括下列步骤：

接收用户的业务开通申请，获取业务上下文信息，或者获取用户上下文信息；

根据所述业务上下文信息或用户上下文信息，获取所述业务上下文信息或所述用户上下文信息所对应的业务相关信息；

根据业务过滤策略对所述业务相关信息进行处理和过滤，生成业务需求信息；

将所述业务需求信息反馈给所述用户。

7.根据权利要求6所述的方法，其特征在于，所述获取业务上下文信息的步骤包括：

应答用户提出的业务申请，获得该用户的业务信息；

根据所述业务信息，查询业务上下文模型库，获得所述业务所对应的业务上下文信息；

其中，所述业务上下文信息包括：业务开通时间、业务有效时间、业务形式、业务资费、业务依托实物。

8.根据权利要求6所述的方法，其特征在于，所述获取用户上下文信息的步骤是通过综合信息获取模块感知用户上下文信息来实现，该用户的上下文信息包括：

用户位置，包括：时间、地点、采集频率；

漫游信息，包括：时段、地点、漫游前位置；

用户基础电信业务使用信息，包括：时间、对方号码、通信时长。

9.根据权利要求6所述的方法，其特征在于，所述获取业务相关信息的步骤包括：

根据所述业务上下文信息或者用户上下文信息查询业务上下文模型库，获取该业务上下文信息或用户上下文信息所对应的业务相关信息；

其中，所述上下文模型库中存储的上下文模型采取“业务信息-业务上下文信息/用户上下文信息-业务相关信息”进行标识。

10.根据权利要求6所述的方法，其特征在于，所述根据业务过滤策略对所述业务相关信息进行处理和过滤，生成业务需求信息的步骤包括：

将业务相关信息进行分类，生成业务分类信息，以根据业务分类信息选择业务过滤策略；

根据所述业务分类信息查询业务过滤策略库，选择与所述业务分类信息对应的业务过滤策略，使用所述业务过滤策略对所述业务相关信息下的业务进行处理，生成业务需求信息；

其中，所述业务过滤策略包括：策略名称、策略适用范围、过滤条件、策略执行方式。

Images