CN101582776A

CN101582776A - 服务计费的方法及服务计费系统

Info

Publication number: CN101582776A
Application number: CNA2008100975951A
Authority: CN
Inventors: 郑小林; 周涛; 何徐辉; 陈德人
Original assignee: Zhejiang University ZJU
Current assignee: Zhejiang University ZJU
Priority date: 2008-05-15
Filing date: 2008-05-15
Publication date: 2009-11-18
Anticipated expiration: 2028-05-15
Also published as: CN101582776B

Abstract

本发明提供了一种服务计费的方法，包括：定制服务计费规则元数据；按照预设的规则模型使用所述规则元数据生成满足业务需求的服务计费规则；依据用户选择的服务，建立用户信息与相应的服务计费规则的关联；依据用户的服务请求数据，匹配相应的服务计费规则生成计费信息。本发明可以在将计费流程与计费规则分离的基础上，提高计费规则的可定制性，并满足复杂的服务计费需求。

Description

服务计费的方法及服务计费系统

技术领域

本发明涉及一种计算机服务领域，特别涉及一种服务计费的方法及一种服务计费系统。

背景技术

服务计费，是指在有偿服务的条件下，服务供应商根据服务使用者的使用情况以及该服务的计费规则向服务使用者收取相应的费用，服务计费是服务提供商与服务使用者之间进行服务交易结算的关键步骤之一。目前的各种服务计费模式包括以下几种：

第1种，基于时间的计费模式：

这种模式根据用户使用服务的时间来计算，对每个单位时间采用不同的价格策略。如电信业务中按通讯时间来计算通讯费用，还可以进一步演变为包月和包年的计费模式。

第2种，基于流量的计费模式：

在网络应用领域，由于根据时间不能很好的体现不同用户之间的服务差距，因此在强调网络差异化服务的今天，出现了基于流量控制的网络实时定价计费模式。这种计费模式根据用户实际占用的服务资源来计算最终的费用，可以包括：“基本费+基本用量+计量制”、“基本费+基本用量”、“基本费+跳档制”、“包月制”、“计量制+费用封顶”、“计量制”、“赠送用量+计量制”等。计量模式明显比包月的方式合理得多，将用户的使用与收费挂钩，并满足各种的优惠策略。但这种计费的方式是基于一个前提——所有用量都是等同的价值。

第3种，基于内容的计费模式：

在数字媒体、远程教育、电子金融等领域，根据时间和流量来计费往往不能体现用户在享受内容、品牌上的差异性，因此针对用量计费的模式的不足，于是引入了基于内容的计费模式。基于内容的计费模式以内容为中心，针对不同的服务内容收取不同的费用，能够很好地体现服务内容和服务品牌上的差异。

第4种，以上三种模式的组合运用。

上述几种服务计费模式在网络租用服务、移动通信服务、金融服务、网络教育服务、数字媒体服务(数字电视、视频点播、KTV等)中都存在广泛的应用。在实际使用过程中，不仅需要根据单种计费模式定义计费规则，同时也需要将几种计费模式组合运用定义综合计费规则。例如在移动通信领域，国际上目前的计费系统市场竞争非常激烈，各类厂商云集，包括大型专家级别的(如Amdocs，Convergys)、小型专家级别的(如Portal，Xacct)、电信IT平台卖主(如Comverse，LogicaCMG)、运营网络卖主(如爱立信、阿尔卡特)、IT服务公司(如IBM Global Service，惠普)、金融软件卖主(如SAP，Oracle).国内市场上移动梦网、联通在线和电信的互联星空等都推出了相应的SP计费服务。在数字媒体方面，由“互联天下”公司牵头，“视讯梦网”推出了基于IP网络的集“视频+语音+数据+IM+VOIP+计费+后台管理”于一体的视讯服务平台。这其中，计费服务对这些平台参与方的利益进行了详细的计算，是平台成功和健康运营的关键。

造成这种计费系统繁多的原因在于，各个计费系统均针对于各自的服务领域，因为计费的具体实施规则不同，不同的服务类别往往需要不同的计费规则来实施计费，也就是说，现有的服务计费系统通常将计费规则固化在计费流程之中，即计费规则同计费过程是高耦合的。由于不同服务有不同的计费要求，故各个服务供应商需要为各自的服务系统设计和开发相应的计费系统。

显然，这种不同的服务供应商都必须分别对自己的系统开发计费系统的情况，造成了不同供应商之间的大量资源浪费。再者，由于这种计费系统中的计费规则是由程序员来实现的，而实际上，对于一个服务来说，如何计费，最为清楚的是服务供应商，而非程序员。传统的计费模型最终的计费规则由程序员来实现，则首先需要程序员来熟悉和理解这套计费规则，如果理解出现了偏差，就会最终影响该套计费系统的正确性。

总之，目前需要本领域技术人员迫切解决的一个技术问题就是：如何能够创新的提出一种通用性强的服务计费机制，用以在将计费流程与计费规则分离的基础上，提高计费规则的可定制性，并满足复杂的服务计费需求。

发明内容

本发明所要解决的技术问题是提供一种服务计费的方法，用以在将计费流程与计费规则分离的基础上，提高计费规则的可定制性，并满足复杂的服务计费需求。

本发明的另一个目的是提供了一种服务计费系统，用以保证上述方法在实际中的实现及应用。

为解决上述技术问题，本发明实施例提供了一种服务计费的方法，包括：

定制服务计费规则元数据；

按照预设的规则模型使用所述规则元数据生成满足业务需求的服务计费规则；

依据用户选择的服务，建立用户信息与相应的服务计费规则的关联；

依据用户的服务请求数据，匹配相应的服务计费规则生成计费信息。

优选的，所述定制元数据的步骤包括：

生成包含所述服务计费规则元数据的XML文件，所述服务计费规则元数据包括：计费信息对象、所述计费信息对象的属性、和所述对象属性的类型；

解析所述XML文件，创建对应的业务对象模型，并针对所述业务对象模块创建别名；

将所述业务对象模型以外的其它对象设置为全局对象。

优选的，所述生成服务计费规则的步骤包括：

生成所述规则元数据的条件集合和操作集合；

按照“如果满足第一条件则执行第一操作，否则执行第二操作”的规则模型，针对相应的业务需求生成服务计费规则。

优选的，所述生成服务计费规则的步骤还包括：

根据所述业务需求对所述服务计费规则定义执行属性。

优选的，所述生成服务计费规则的步骤还包括：

将多条服务计费规则按照预设条件封装为服务计费规则包。

优选的，所述生成服务计费规则的步骤还包括：

对所述服务计费规则和/或服务计费规则包分配名称。

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

依据所述计费信息进行计费处理。

优选的，所述用户信息包括用户账户信息，所述计费处理的步骤包括：

依据所述计费信息判断用户的账户信息是否满足计费执行的条件；

如果满足，则冻结所述用户账户中计费信息所示的金额，若冻结成功，则触发执行所述用户请求的服务；

若服务执行成功，则依据所述冻结金额更新所述用户的账户信息。

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

依据用户退订服务的请求，消除相应用户信息与所述服务计费规则的关联。

本发明实施例还公开了一种服务计费系统，包括：

规则定制模块，包括：

规则元数据定制子模块，用于定制服务计费规则元数据；

规则生成子模块，用于按照预设的规则模型使用所述规则元数据生成满足业务需求的服务计费规则；

计费规则引擎，包括

规则载入子模块，用于依据用户选择的服务，建立用户信息与相应的服务计费规则的关联；

计费信息生成子模块，用于依据用户的服务请求数据，匹配相应的服务计费规则生成计费信息。

优选的，所述计费规则引擎还包括：

规则执行模块，用于依据所述计费信息进行计费处理。

优选的，所述规则元数据定制子模块包括：

元数据描述文件生成单元，用于生成包含所述服务计费规则元数据的XML文件，所述服务计费规则元数据包括：计费信息对象、所述计费信息对象的属性、和所述对象属性的类型；

BOM创建单元，用于解析所述XML文件，创建对应的业务对象模型；

别名创建单元，用于针对所述业务对象模块创建别名；

全局对象设置单元，用于将所述业务对象模型以外的其它对象设置为全局对象。

优选的，所述规则生成子模块包括：

集合生成单元，用于分别生成所述规则元数据的条件集合和操作集合；

模型定制单元，用于按照“如果满足第一条件则执行第一操作，否则执行第二操作”的规则模型，针对相应的业务需求生成服务计费规则。

优选的，所述规则生成子模块还包括：

属性定义单元，用于根据所述业务需求对所述服务计费规则定义执行属性。

优选的，所述规则生成子模块还包括：

规则包封装单元，用于将多条服务计费规则按照预设条件封装为服务计费规则包。

优选的，所述生成服务计费规则的步骤还包括：

标识单元，用于对所述服务计费规则和/或服务计费规则包分配名称。

优选的，所述规则定制模块位于服务提供商平台。

与现有技术相比，本发明具有以下优点：

第一、本发明提供了一个通用计费规则模型，能够实现对复杂计费规则的翻译，以适应复杂的服务计费要求。

第二、将规则的具体定制任务交给服务供应商，从而不同的服务供应商可以定制相应的计费规则，而不需程序员参与。

第三，本发明采用规则元数据作为最小计费单元，例如网内或网外通话等，这些细粒度的计费信息给服务定制过程带来了极大的灵活性，可以满足不同行业的计费需求。

第四、本发明不但可以支持传统的“服务使用者-服务供应商间计费”双方模式外，还支持“服务使用者-服务供应商-计费管理方”的三方模式，在此模式的基础上，计费管理方可以对其计费细节和流程进行管理和监督，服务供应商可以专注于高质量的服务供应，还有利于监督部门对整个计费市场的监督管理。

第五、由于采用了新的计费融合算法，本发明支持绝大部分的计费服务，而不仅仅局限于某个行业或者某个领域，并且可以针对某一行业进行优化，满足该行业的特殊需要。本系统也可以支持跨行业间的多服务之间的融合计费，使得服务供应商能提出更具灵活性的套餐，捆绑销售(包括多产品，多业务)、交叉优惠等，有助于供应商赢取更多的商机。

第六、应用本发明可以在预付费和后付费业务之间自由切换，一个用户的不同账户可以采用不同的付费方式。传统的计费方案中，对于后付费用户在计费账务系统中处理，而对于预付费用户的处理一般只能在智能网中实现，系统间存在数据统一和业务统一的问题，导致在用户使用感受、客户服务、运营商业务管理、业务扩展和收入保障方面存在着巨大差异。而本发明利用计费融合方案消除了这些差异，实现了预付费和后付费的自由切换，统一了业务模型以便于管理，为客户和供应商创造更多的价值。

附图说明

图1是本发明一种服务计费的方法实施例的流程图；

图2是本发明的一种服务计费系统实施例的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

本发明可用于众多通用或专用的计算系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、包括以上任何系统或设备的分布式计算环境等等。

本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本发明实施例的核心构思之一在于，将服务计费流程与计费规则相分离，实现服务计费规则的可定制性和通用性。应用本发明实施例，服务提供商可以依据各自的业务需求定制服务计费规则元数据及相应的计费规则，本发明将这种用类自然语言表达的计费规则解析转换成专家系统的规则形式，然后将它们放入到规则空间中。进行计费时，首先读取计费记录，将其封装成事实因子放入工作空间，然后将事实因子和规则在模式匹配模块中进行匹配，如果匹配成功，则将匹配上的规则和因子成对放入规则触发计划模块中。全部匹配完成后，则触发规则进行计费，完成整个计费流程。

参考图1，示出了本发明的一种服务计费的方法实施例的流程图，可以包括以下步骤：

步骤101、定制服务计费规则元数据；

步骤102、按照预设的规则模型使用所述规则元数据生成满足业务需求的服务计费规则；

步骤103、依据用户选择的服务，建立用户信息与相应的服务计费规则的关联；

步骤104、依据用户的服务请求数据，匹配相应的服务计费规则生成计费信息。

所谓元数据，通常是指关于数据的数据；在程序中元数据不是被加工的对象，而是通过其值的改变来改变程序的行为的数据。它在运行过程中起着以解释方式控制程序行为的作用。例如，在设计期，技术人员可以对应用需求中的数据查询格式进行抽象建模，用面向对象的语言对数据查询进行描述，并保存为XML格式的元数据。该XML文件主要是对原有平台的数据查询格式的一种抽象归类后形成的描述性数据。在本实施例中，所述服务计费规则元数据可以由服务提供商根据服务领域定制。例如，电话业务计费业务的元数据可能包括“地理区域：本地、漫游”，而互联网业务计费业务可能就不定义上述元数据，对于服务提供商而言，由于可以自定义相应的计费规则元数据，因而提高了计费规则的可定制性。

优选的，在本发明中，可以通过以下子步骤定制所述服务计费规则元数据：

子步骤1011、生成包含所述服务计费规则元数据的XML文件，所述服务计费规则元数据包括：计费信息对象、所述计费信息对象的属性、和所述对象属性的类型；

子步骤1012、解析所述XML文件，创建对应的业务对象模型，并针对所述业务对象模块创建别名；

子步骤1013、将所述业务对象模型以外的其它对象设置为全局对象。

例如，假设服务提供商根据现有的服务资源制定出两条特定领域的服务计费规则，如下表所示的：

规则关联的业务	规则名称	规则变量	规则所要满足的条件	规则表达式“/”为计算机中的“/”	规则举例/描述
规则关联的业务	规则名称	规则变量	规则所要满足的条件	规则表达式“/”为计算机中的“/”	规则举例/描述	视频点播、网络电视直播	包日制	天数，每天的费用	用户登陆；该用户已购买包日业务；用户点播视频。	周六：2.00元/日；周日：2.00元/日；其余的时间是1.20元/日注：从第一次点播时间起，以24小时为点播有效期。	在约定时间内，不限次数、内容的观看全部视频服务
征信和信用服务	免费使用+单次扣费	使用次数，套餐类型	用户购买了该规则；用户使用征信服务	预付10元，前100次使用免费，超过100次的按照每次使用扣费0.2元的规则计费	使用的流量，以及耗费的系统资源等不受限制。	视频点播、网络电视直播	包日制	天数，每天的费用	用户登陆；该用户已购买包日业务；用户点播视频。	周六：2.00元/日；周日：2.00元/日；其余的时间是1.20元/日注：从第一次点播时间起，以24小时为点播有效期。	在约定时间内，不限次数、内容的观看全部视频服务

基于上述规则定制规则元数据的过程可以为：

(一)分析，提取上表中的规则变量，这些变量的组合构成计费规则的元数据信息。可以采用xsd文件描述为：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<xs:schema xmlns:xs＝″http://www.w3.org/2001/XMLSchema″

elementFormDefault＝″qualified″attributeFormDefault＝″unqualified″>

<xs:complexType name＝″TTrustingInfo″>

<xs:sequence>

<xs:element name＝″chargeType″type＝″xs:string″/>

<xs:element name＝″count″type＝″xs:int″/>

<xs:element name＝″startDate″type＝″xs:date″/>

</xs:sequence>

</xs:complexType>

<xs:complexType name＝″TVodElement″>

<xs:sequence>

<xs:element name＝″subscribeType″type＝″xs:string″/>

<xs:element name＝″week″type＝″xs:date″/>

<xs:element name＝″valid″type＝″xs:boolean″/>

</xs:sequence>

</xs:complexType>

<xs:element name＝″VodElement″type＝″TVodElement″/>

<xs:element name＝″TrustingInfo″type＝″TTrustingInfo″/>

</xs:schema>

可以看出，上述XML文件中描述了计费信息的所有元数据，包括：

1、计费信息对象：

将相应的计费信息包装在某些对象中，例如针对，如下表所示的所述的计费方案，包含了VodElement(视屏点播对象)，TrustingInfo(征信和信用信息)这样2个对象，作为xsd描述文件中的2个次根节点。

2、所述计费信息对象包含的所有属性：

每个计费信息对象可以包含多项计费信息，例如，针对上述的TrustingInfo对象，包含了计费类型(chargeType)，消费次数(count)，开始时间(startDate)等属性。这些属性以TrustingInfo对象的子结点的方式定义，对于一些公有的属性值，在xsd描述文件的次根节点定义，通过名称为ref的attribute节点进行引用。

3、所述对象属性的类型：

前述属性的类型可以是原始类型，也可以是对象。对于原始类型，如Date等类型，可以直接在属性的attribute节点中定义；对于对象，则可以在XML文件的次根节点定义对象的类型，并通过ref的atttribute导入该类型。可以支持的对象类型包括：Integer(整型)、Double(双精度浮点型)、String(字符串)、Date(日期，按照yyyy-mm-dd hh:mm:ss方式描述)、Collection(容器)、RegEx(正则表达式)、Object(对象)。

(二)导入上述包含XOM信息的XML文件，生成BOM对象。

XOM(执行对象模型)指定了执行规则时所依据的执行对象。可以理解的是，如果要定义的是Java对象，则该数据可以为Jar文件；如果是从XML数据派生出的对象，则该数据可以为XML Schema文件。使用XOM能够提供统一的接口，以相同的方式处理不同来源的数据对象。XOM可以通过绑定过程提供指向各类不同对象的通用接口。来源于Java类的信息使用的是Java绑定，而XML Schema和Web服务模式则可以通过XML绑定转换为类似Java的对象。

BOM(业务对象模型)是业务策略操作的基本单元，BOM的定义在包含XOM信息的XML文件中完成，这一步的任务主要是解析上述xsd文件，提取其中的BOM信息，创建相应的BOM对象。

整个计费信息描述页面的解析过程为：

1、获取所有次根节点的xs:element元素，作为BOM对象，可标记为E；

2、根据E的type类型去搜索整个XML文件，判断E属于复杂类型或简单类型，并找出所有E的子元素，可标记为subE；

3、判断所述subE的类型，如果为简单类型，则跳转到4；如果为复杂类型，则跳转到2；

4、根据xsd描述类型和程序中原始类型之间的转换关系，将简单类型转换成程序支持的字段类型，保存解析完成后的信息；

5、继续处理下一个E对象，跳转到1。

作为一个典型的JavaBean，程序需要自动生成所有属性的get和set方法，同时要严格满足属性和方法名的命名规范。对用户而言，只需要将XOM信息导入，选取需要创建BOM的对象，以及对象的特定属性，选择完毕后，程序会根据用户选择的对象和属性创建新的BOM。

(三)创建别名。

将上述BOM通过直观的名称来表示，在规则中可以使用定义的别名来替代该对象。

(四)预设全局对象。

当规则的条件，或action操作中需要用到一些BOM以外的对象时，可以预先设定这些对象为全局对象。全局对象独立于规则之外，可以在每条规则的执行过程中使用。

当然，上述定制元数据的方法仅仅用作示例，本领域技术人员根据实际需要或经验采用任一种元数据定制方法都是可行的，本发明对此不作限制。

在定制完成所述服务计费规则元数据后，即可使用这些元数据生成满足业务需求的服务计费规则，本发明还提供了一种通用计费规则模型，按照这个模型生成规则，可以满足实际中大部分服务计费的需求。

优选的，可以通过以下子步骤生成服务计费规则：

子步骤1021、生成所述规则元数据的条件集合和操作集合；

子步骤1022、按照“如果满足第一条件则执行第一操作，否则执行第二操作”，或者，“当满足第一条件时执行第一操作，否则执行第二操作”的规则模型，针对相应的业务需求生成服务计费规则。

具体地，所述规则模型可以包括如下定义：

基本规则1：IF<Condition1>

THEN<Operation1>

ELSE

这是本发明规则结构的一种简单表现形式。可以叫做业务操作规则(BAR)，BAR采用了直观的自然语言的语法形式，在BAR业务规则中，条件和操作是用“如果(If)...那么(Then)”语句表示的。

基本条件1：ATTRIBUTE OF<Object>

COMPARE TO<Value>

所述基本条件1是指某个对象的某个属性值是大于、小于或者等于某个值。这个是服务计费中最常用的价格规则。

基本条件2：AT LEAST EXIST ONE<Object>

SATIFIES<Validation>

所述基本条件2是指至少存在一个对象满足某个校验。这是一个复合规则条件，因为校验同时又存在一个条件和基本规则的组合。

基本条件3：AMOUNT OF<Object>

SATIFIES<Validation>

所述基本条件3是指某个对象的数量满足某个校验。这也是一个复合规则条件。

基本条件4：NO<Object>

SATIFIES<Validation>

所述基本条件4是指没有任何一个对象满足某个校验。

基本操作1：SET ATTRIBUTE OF<Object>TO<Value>

所述基本操作1是指设置某个对象的某个属性为某个值，这个是所有计费规则的最后动作。

基本操作2：DO<Action>

所述基本操作2是指除了设置属性值之外的其他操作，比如显示一个消息或者执行某个动作，严格来说基本操作2也是属于基本操作1的，只是为了理解的方便和形式化定义的需要将其单独拿出来作为一条基本操作。

可以理解的是，任意多个条件即可组成每条规则的条件集合，规则的条件表示计费对象中字段需要满足的约束条件，这些字段约束主要包括：操作符约束，字面值约束，绑定变量约束，谓词约束和返回值约束，可以用”，”隔开，表示这些条件为并列关系。规则执行过程中会判断计费消息对象中的字段是否满足这些约束条件，只有当所有的条件都被满足时，才能执行操作集合中的流程。操作集合则定义了对计费对象的操作，包括费用计算，计费对象状态的改变等内容，具体描述方式诸如：

费用1：计算表达式1；......费用N＝计算表达式N

消费量1＝计算表达式I；......消费量N＝计算表达式N

状态1(计费对象)＝新状态1；......状态N(计费对象)＝新状态N；

例如，设P＝{基本条件1，基本条件2，基本条件3，基本条件4，AND，OR，}，即表示基本条件1-4以及空集在AND和OR上所有组合情况的集合空间；Q＝{基本操作1，基本操作2，AND，OR，

}，即表示基本操作1-2以及空集在AND和OR上所有组合情况的集合空间。设BAR表示基本规则1，TRR表示基本规则2，且满足：

(1)对任意的X∈P，Y∈Q；

(2)则所有的计费规则都属于F的子集，也即是通用规则的形式化定义。其中F＝{BAR，TRR，X，Y}^*，即F是BAR规则和TRR规则以及X，Y在自身的无穷递归的组合的集合空间。其具体形式可以表示为：

IF<Condition1>

THEN<Operation1>

ELSE

其中，Condition1又可以表示为：

IF<Condition1_1>

THEN<Operation1_1>

ELSE

<Operation2_1>

其中，Condition又可以表示为P空间的任意子元素，即基本条件1-4以及空集在AND和OR上任一种组合情况，而Operation又可以表示为Q空间的任意子元素，即基本操作1-2以及空集在AND和OR上的任一种组合情况。

如此递归可以获得通用计费规则的一种基本形式如下所示：

IF<Condition1>

IF<Condition2>

THEN<Operation3>

ELSE

......

THEN<Operation1>

ELSE

IF<Condition3>

THEN<Operation5>

ELSE

......

可以看出，本发明提供的通用规则模型具有：(1)无穷递归性。显而易见的是，在Condition中永远都是可以递归进行下去；(2)结果唯一性。对于该模型生成的规则结果一定是唯一的，而不可能对于某一个输入可能会产生两种不同的结果。对于IF-THEN-ELSE的规则结构，因此对于任何一个输入它必然只会到IF和ELSE中的一侧，假设到了IF这一侧，同理往下推，他也只会到下一级IF和ELSE中的一侧，一直到最后，它肯定在某一级的IF和ELSE中的一侧停下，最后执行其对应的一个Operation。因此对于任何一个输入不可能产生两种不同的结果。

优选的，所述生成服务计费规则的步骤还可以包括以下子步骤：

子步骤1023、根据所述业务需求对所述服务计费规则定义执行属性。

例如，可以定义如下规则属性：

a、优先级(salience)

默认值：0

类型：int

每条规则都可以设置一个优先级整数值，默认为0，可以设为正整数或负整数。Salience是优先级的一种形式。当处于激活队列中时，拥有高salience值的规则将具有更高的优先级。

b、延时(duration)

默认值：无

类型：long

延迟是指计费规则处于激活队列中，规则的操作部分经过一段时间的延迟以后开始执行。

当然，上述属性定义仅仅用于示例，本领域技术人员根据实际需要任意定义相应属性都是可行的，本发明对此不作限制。

优选的，还可以进一步定义所述计费规则的补偿操作。在实际中，如果计费信息出错，则需要对计费操作进行回滚，而计费操作不仅包括了扣除费用，而且可能对计费对象本身的属性进行了修改，例如，对于流媒体用户，赠送了VIP会员卡，这样的操作执行结果无法通过简单的取消操作来消除该条计费规则执行所造成的影响，因此需要在计费规则中定义相应的补偿操作。

例如，一种设置补偿操作的规则执行过程可以为：

S1、执行规则，匹配条件集合；

S2、判断条件中是否包括回滚标识，若有，则执行步骤S3；若否，则执行步骤S4；

S3、执行补偿操作；

S4、执行原子操作。

与原子操作相比，补偿操作往往是它的一个逆向过程，消除原子操作对计费对象造成的影响，例如减少使用次数，偿还多扣的金额，对于计费规则之间相互依赖的补偿关系，也可以在补偿操作中定义。

子步骤1024、将多条服务计费规则按照预设条件封装为服务计费规则包。

对于一个计费服务来说，它可能会拥有多种计费规则，比如移动的优惠套餐或者电信的普通话费加长途套餐等。而对于一个服务来说，它有可能同时满足多条计费规则，这就可能带来计费规则冲突的问题。

为了解决这个问题，本发明还提供了规则包(Rule Package)的解决方式。也就是说每个服务都对应一个规则包，在这个规则包内的规则是不能冲突的，对于每条规则都对应了一个优先级，且同一个规则包内的规则的优先级是不重复的。若某个服务同时满足规则包内的不同规则，则按优先级高的规则进行计费。

例如：设有规则包A，内有规则B，C，D。若B，C，D中出现了规则的前提条件一样而操作不一样(相反)为规则冲突。这种情况在规则包中是不允许的。具体的做法是当用户为某一个服务添加完规则后，系统会自动检查同一个规则包中的计费规则是否有冲突，若有冲突则提示用户该规则不符合要求。若用户当前使用的服务情况符合B，C，D中多条规则，则根据B，C，D的优先级别来选择需要执行的操作。因此，在本发明中，不管规则有多复杂，计费构件总是能够得到很好和正确的执行。

可以看出，一个规则包是由多个规则包和规则通过一定的逻辑关系组合而成，在实际中，还可以提供规则包定制页面，用户可以在规则包的定制页面上选择需要继承的规则包，排除的规则包，以及包含的规则和排除的规则，通过非常直观的操作完成整个定制工作。继承的规则包表示包含了该规则包的所有规则，排除的规则包表示不包含这些规则包的所有规则。而单条规则的包含和排除是对规则包的补充，使得规则包的定制性更强。最后制定完成的规则包则由多条规则组合而成。

为便于操作，还可以对所述服务计费规则和/或服务计费规则包分配名称。

以下以一组移动通信业务的计费规则的定制过程为例进一步说明本发明的规则定制过程。

假设计费规则如下表所示：

规则关联的业务	规则变量	规则所要满足的条件	规则表达式“/”为计算机中的“/”	规则举例
规则关联的业务	规则变量	规则所要满足的条件	规则表达式“/”为计算机中的“/”	规则举例	全球通基本月租费	所属品牌	所属品牌为全球通。	50元/月
全球通本地基本通话费	所属品牌、主叫方所属网络、主叫方所在网络、被叫方所在网络、通话起始时间、通话时间	所属品牌为全球通；电话接通；主叫方所在网络、所属网络和被叫方所在网络相同。	通话时间/分钟^*0.40元注：双向计费		全球通基本月租费	所属品牌	所属品牌为全球通。	50元/月
全球通本地基本通话费	所属品牌、主叫方所属网络、主叫方所在网络、被叫方所在网络、通话起始时间、通话时间	所属品牌为全球通；电话接通；主叫方所在网络、所属网络和被叫方所在网络相同。	通话时间/分钟^*0.40元注：双向计费		全球通漫游基本通话费	所属品牌、主叫方所属网络、主叫方所在网络、被叫方所在网络、通话起始时间、通话时间	所属品牌为全球通；电话接通；主叫方和被叫方所在网络相同；主叫方或者被叫方所在网络不是所属网络。	通话时间/分钟^*0.60元注：双向计费	如主叫方是杭州号码，而被叫方是绍兴号码，现在主叫方在绍兴，拨打被叫方。或者如主叫方是杭州号码，而被叫方是绍兴号码，现在被叫方在杭州，被呼叫。
国内长途费		所属品牌为全球通或神州行；电话接通；主叫方和被叫方同属国内；主叫方和被叫方所在网络不同。	0.07元/6秒钟		全球通漫游基本通话费	所属品牌、主叫方所属网络、主叫方所在网络、被叫方所在网络、通话起始时间、通话时间	所属品牌为全球通；电话接通；主叫方和被叫方所在网络相同；主叫方或者被叫方所在网络不是所属网络。	通话时间/分钟^*0.60元注：双向计费
国内长途费		所属品牌为全球通或神州行；电话接通；主叫方和被叫方同属国内；主叫方和被叫方所在网络不同。	0.07元/6秒钟		国际长途费		所属品牌为全球通或神州行；电话接通；主叫方属于国内；被叫方属于国外；主叫方和被叫方所在网络不同。	0.80元/6秒钟

按照本发明提供的通用计费模型生成的服务计费规则可以包括：

IF所属品牌为全球通THEN使用全球通基本月租费规则。

IF所属品牌为全球通AND电话接通AND主叫方在本地网内AND被叫方在本地网内THEN主叫方AND被叫方基本通话费＝通话时间/分钟*0.40元。

IF所属品牌为全球通AND电话接通AND主叫方在本地网内AND被叫方在本地网内AND((主叫方是外地号码AND被叫方是本地号码)OR(被叫方是外地号码AND主叫方是本地号码))THEN主叫方AND被叫基本通话费＝通话时间/分钟*0.60元。

IF所属品牌为全球通OR所属品牌为神州行AND电话接通AND主叫方在本地网内AND被叫方不在本地网内AND被叫方区号属于国内THEN主叫方长途费＝通话时间/6秒钟*0.07元。

IF所属品牌为全球通OR所属品牌为神州行AND电话接通AND主叫方在本地网内AND被叫方不在本地网内AND被叫方区号属于港澳台THEN主叫方长途费＝通话时间/6秒钟*0.2元。

IF所属品牌为全球通OR所属品牌为神州行AND电话接通AND主叫方在本地网内AND被叫方不在本地网内AND被叫方区号属于国外THEN主叫方长途费＝通话时间/6秒钟*0.8元。

由于上述计费规则包都是由手工制定完成，因此规则进入部署运行环节之前，还可以对其进行测试和验证。本发明对此也不作限制。

对于同一种服务，可能会有多种计费形式，例如对于短消息服务，可能会按条计费，也可能包月，即使是按条计费，对于VIP客户和普通客户计费标准可能又不一样，所以在进行实际计费之前，需要首先确认用户对应的计费规则或规则包，这样才知道需要匹配哪条规则进行计费。

用户选择一个或者多个计费规则包(一个计费规则包中的计费规则既可以只针对于一个服务，也可以针对于多个服务)，确认提交后，订阅开始生效。依据用户订阅的服务，会在用户信息与相应的服务计费规则之间建立关联，以便在用户请求服务时，匹配该服务计费规则生成计费信息。

优选的，本实施例还可以包括步骤105：

依据所述计费信息进行计费处理。

其中，所述用户信息包括用户账户信息，所述计费处理的步骤可以包括以下子步骤：

子步骤1051、依据所述计费信息判断用户的账户信息是否满足计费执行的条件；

子步骤1052、如果满足，则冻结所述用户账户中计费信息所示的金额，若冻结成功，则触发执行所述用户请求的服务；

子步骤1053、若服务执行成功，则依据所述冻结金额更新所述用户的账户信息。

在实际中，如果用户的账户信息不满足计费执行的条件，则可以返回计费失败的信息。此外，当服务执行失败时，则撤消所述冻结信息。

当然，本领域技术人员根据实际需要采用任一种计费处理方法都是可行的，本发明对此不需要进行限定。

综上，本发明所带来的技术效果主要体现在以下方面：

参考图2，示出了本发明的一种服务计费系统实施例的结构框图，可以包括以下模块：

规则定制模块21，可以包括：

规则元数据定制子模块211，用于定制服务计费规则元数据；

规则生成子模块212，用于按照预设的规则模型使用所述规则元数据生成满足业务需求的服务计费规则；

计费规则引擎22，可以包括：

规则载入子模块221，用于依据用户选择的服务，建立用户信息与相应的服务计费规则的关联；

计费信息生成子模块222，用于依据用户的服务请求数据，匹配相应的服务计费规则生成计费信息。

优选的，所述计费规则引擎还包括：

规则执行模块223，用于依据所述计费信息进行计费处理。

在本实施例中，所述规则元数据定制子模块可以包括以下单元：

别名创建单元，用于针对所述业务对象模块创建别名；

在本实施例中，所述规则生成子模块可以包括以下单元：

模型定制单元，用于按照“如果满足第一条件则执行第一操作，否则执行第二操作”，或者，“当满足第一条件时执行第一操作，否则执行第二操作”的规则模型，针对相应的业务需求生成服务计费规则。

优选的，所述规则生成子模块还可以包括以下单元：

和/或，

在实际中，所述服务计费系统可以与服务提供商平台、服务使用者平台和系统管理平台连接。

具体地，服务提供商平台用于供服务的提供者(SP)进行相关的服务增加、发布等操作，以及对服务的用户进行相关的报表统计操作。服务提供商平台主要包括服务供应商基本信息管理、服务计费规则定制管理和用户管理三部分。其中，服务供应商基本信息管理是服务供应商自身的基本信息的登记和管理模块，包含服务供应商注册、服务供应商登陆、服务基本信息管理、服务收款管理和注册信息管理，可以包括新增、修改、删除、提审、查询、发布服务等功能。服务计费规则定制管理是本发明的重点，它提供标准化的界面让服务提供商对自己的服务进行计费规则的定制，让服务能够有效地计费。包含服务计费规则添加、修改、删除等子功能模块。其主要业务模块及其主要功能包括：

1)规则定制器：

该模块的主要功能是提供一个界面供服务提供商对自己的服务进行计费规则的设置。

2)规则模板定制器：

该模块的主要功能是提供规则定制器定制规则的模板。

3)规则模板库：

该模块的主要功能是存储规则模板。

4)规则库：

该模块的主要功能是存储服务提供商定制的计费规则。

5)日志模块：

该模块的主要功能是提供一些接口等，以供其他模块调用，进行相关日志的记录。

6)日志库：

该模块的主要功能是存储用户各种操作的记录信息。

用户管理是让服务提供商可以查看自己的服务订阅者的基本信息等的功能模块，包含查看订阅用户、服务消费情况报表等子功能模块。

服务使用者平台是针对服务的使用者来说的。它可以让服务的使用者自用的订阅和修改服务，以及进行相应的费用管理和自我的基本信息管理等。服务使用者平台主要包括基本信息管理、服务订阅和用户费用管理三部分。

系统管理平台是针对服务计费系统管理员而言的，它提供对所有服务的运行等生命周期的管理、以及对服务提供商服务、相关操作等的审核以及用户信息的管理等。该平台的有效性关系到整个计费系统的公平性和有效性。系统管理平台包括规则模板定制平台、服务供应商生命周期管理和监督、用户生命周期管理和监督、基本信息管理四部分组成。

需要说明的是，本发明的计费规则引擎主要功能是收集服务使用记录和根据计费规则进行计费运算，即把服务提供商定制的计费规则翻译成自己能够理解的规则语言，然后通过计费算法来进行相关的规则匹配和计算来保证计费操作的正确性和有效性。计费规则引擎包括规则翻译、规则载入、规则判断数据接收以及规则执行四部分的操作。计费规则引擎的计费规则运行流程主要包括：

Z1、规则翻译：提供一个接口把服务提供商定制的规则翻译成规则引擎所能识别的规则语言。

Z2、规则载入：提供一个接口把用户正在使用的服务的计费规则装载至规则引擎中。

Z3、计费消息生成：提供一个接口实时的接收系统监控模块传送过来的用户使用服务的时间、流量等计费相关信息并转换成规则引擎计费所需要的数据。

Z4、规则执行：通过接收实时的规则判断数据，每到一个计费时间周期，规则引擎便开始把这些数据同相应的计费规则结合进行计算，算出相应的计费金额。

本发明系统引入规则引擎的好处是降低实现复杂业务逻辑的组件的复杂性，降低应用程序的维护和可扩展性成本。计费规则复杂的业务逻辑如果采用Java代码的形式来实现的话，限于灵活性和代码的错综复杂性，使得维护和更新应用程序的业务逻辑成为一项令人畏惧的任务。同时Java程序产生重编译和重部署成本也相当可观。而规则引擎使用动态语言来描述规则，采用If-Then-Else等关键字来表达业务逻辑，允许使用专用的类似英语的自然语言描述规则。采用动态编译加载的机制，并且可以对规则进行循环复用。同时计费引擎引入了Cache机制，包括一些常用规则以及规则包的缓存，这样进一步提升了系统性能。

以下通过实际中各平台与系统的操作进一步说明本发明实施例。

一、发布服务计费规则

计费规则的发布主要涉及到系统管理员和服务供应商的操作。系统管理员主要提供规则的模板，以及在发布服务供应商提供的计费规则前进行逻辑性和安全性的检查。具体的操作模型可以为：系统管理员首先需要进行身份认证，通过认证进入系统之后方能进行规则元数据的定制。规则元数据的定制可以通过使用计费系统提供的用户接口进行，定制完成后，规则元数据保存于计费系统，发布后提供给服务供应商使用。服务供应商在进行身份验证之后即可进行规则定制。服务供应商首先在系统发布的规则元数据的基础上定制自己个性化的规则元数据，然后根据规则元数据定制计费规则，最后将多条计费规则组合，形成计费规则包供服务使用者订阅。定制完成后还可以向系统提交审核申请。

二、用户订阅/退订服务

用户对服务的使用主要包括订阅和退订的操作。进行操作之前需要用户登陆服务使用者平台进行身份确认，之后进行订阅或退订操作。进行订阅操作时，系统列出所有的可用计费规则包，用户选择感兴趣的计费规则包进行订阅；进行退订操作时，系统列出该用户已经订阅的计费规则包，用户选择需要退订的计费规则包进行退订。

三、计费消息处理

计费消息的处理涉及到三方的处理，分别为计费消息发送方、计费引擎、授权管理(CA中心和权限管理)。具体流程可以为：服务者在使用需收费服务时，该服务作为计费消息发送方将向计费引擎发送该服务的计费请求，该请求包含了加密的计费消息，包括使用者的身份信息以及使用的服务信息。该请求可能因为网络拥挤等通讯问题导致发送失败，出现这种情况时需要重复发送过程。该消息到达计费引擎后首先需要通过授权管理系统的认证，判断是否为有效的计费消息。若无效，则向计费消息发送方返回错误码。若有效，则接着验证用户是否有权限完成此次服务访问，例如，查询用户的服务订阅情况和账户余额，判断是否可以完成计费；若无权限完成此次服务访问，则返回错误码。否则首先进行服务预计费，如对用户账户中使用该服务的款项进行冻结，即预计费为标志扣除费用，并非真实扣除费用。预计费成功后，返回给消息发送方预计费成功消息。计费消息发送方收到预计费成功消息后，可以对用户进行服务。在服务完成后，向计费引擎发送计费确认消息，确认消息首先需验证有效，如果确认消息是进行服务扣费，则执行扣费操作，如果确认消息是撤销扣费，则撤销预计费操作。完成执行后最终返回扣费成功消息给计费消息发送方。

对于系统实施例而言，由于其基本相应于其方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本发明所提供的一种服务计费的方法及一种服务计费系统进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims

1、一种服务计费的方法，其特征在于，包括：

定制服务计费规则元数据；

2、如权利要求1所述的方法，其特征在于，所述定制元数据的步骤包括：

将所述业务对象模型以外的其它对象设置为全局对象。

3、如权利要求2所述的方法，其特征在于，所述生成服务计费规则的步骤包括：

生成所述规则元数据的条件集合和操作集合；

4、如权利要求3所述的方法，其特征在于，所述生成服务计费规则的步骤还包括：

根据所述业务需求对所述服务计费规则定义执行属性。

5、如权利要求4所述的方法，其特征在于，所述生成服务计费规则的步骤还包括：

将多条服务计费规则按照预设条件封装为服务计费规则包。

6、如权利要求3、4或5所述的方法，其特征在于，所述生成服务计费规则的步骤还包括：

对所述服务计费规则和/或服务计费规则包分配名称。

7、如权利要求1所述的方法，其特征在于，还包括：

依据所述计费信息进行计费处理。

8、如权利要求7所述的方法，其特征在于，所述用户信息包括用户账户信息，所述计费处理的步骤包括：

9、如权利要求1所述的方法，其特征在于，还包括：

10、一种服务计费系统，其特征在于，包括：

规则定制模块，包括：

规则元数据定制子模块，用于定制服务计费规则元数据；

计费规则引擎，包括

11、如权利要求10所述的系统，其特征在于，所述计费规则引擎还包括：

规则执行模块，用于依据所述计费信息进行计费处理。

12、如权利要求10或11所述的系统，其特征在于，所述规则元数据定制子模块包括：

别名创建单元，用于针对所述业务对象模块创建别名；

13、如权利要求12所述的系统，其特征在于，所述规则生成子模块包括：

14、如权利要求13所述的系统，其特征在于，所述规则生成子模块还包括：

15、如权利要求14所述的系统，其特征在于，所述规则生成子模块还包括：

16、如权利要求13、14或15所述的系统，其特征在于，所述生成服务计费规则的步骤还包括：

17、如权利要求10所述的系统，其特征在于，所述规则定制模块位于服务提供商平台。