CN101072114A

CN101072114A - 电信系统中计费的实现

Info

Publication number: CN101072114A
Application number: CNA2007101121747A
Authority: CN
Inventors: 菲利普·金兹布尔格; 詹－埃里克·艾克伯格; 安蒂·伊尔拉－加斯基
Original assignee: Nokia Telecommunications Oy
Current assignee: Nokia Oyj
Priority date: 1996-11-11
Filing date: 1997-11-11
Publication date: 2007-11-14
Also published as: EP1445913A2; NZ335701A; CN1240523A; BR9713014A; CA2271779C; CN1332550C; CA2271779A1; AU730689B2; AU4871297A; US6047051A; FI964524A; EP1012760A1; FI964524A0; WO1998021676A1; EP1445913A3; RU2212057C2; FI113224B

Abstract

本发明涉及电信系统中的一种计费实现方法，前述电信系统包括客户用以定购业务的客户终端，以及用以向客户提供业务的服务器。为了容易地实现，尤其是在多媒体环境中容易地实现业务的计费，网络中至少使用一个独立的账单处理服务器，使每个客户终端具有一个指定的账单处理服务器。向客户发送一个契约消息，说明客户必须就选择的业务签订契约，将客户对该契约的接受从客户终端发送到网络中的账单处理服务器。网络中的账单处理服务器用于将计费记录传送到账单处理系统，使得有关选定业务的计费记录的传送涉及至少一个账单处理服务器。

Description

电信系统中计费的实现

本申请是于1997年11月11日提出的、题为“电信系统中计费的实现”的中国专利申请No.97180604.7的分案申请。

技术领域

本发明一般涉及电信系统中计费的实现，尤其涉及多媒体业务的计费实现。

背景技术

业务计费是业务提供者和客户之间契约的实现。原则上，计费有两种类型：分布式和集中式。

在分布式计费中，客户在每次使用厂商所提供的业务时将费用支付给该厂商(vendor)。支付可以以现金形式进行，或者通过其它的相当方法进行。例如，邮件的交付通过使用邮票来支付。分布式计费中支付方法的一个较新的例子是电子现金。电子现金的每个“硬币”包含加密的二进制序列，它必须由银行的服务器加以验证。

在集中式计费中，厂商或第三方监控业务的使用。客户被定期计费，例如一个月一次。账单基于前一计费周期期间收集的数据。集中式计费的三个众所周知的例子是电，电话和信用卡计费。集中计费由3阶段组成。第一阶段是用户和业务提供者之间签订关于业务和业务计费的契约。第二阶段是监控(或测量)和存储使用数据。第三阶段是为客户生成和分发账单。账单处理系统中根据所存储的信息生成账单。

例如，电话网络中使用的集中式账单处理系统基于租用者和电话公司之间的契约。契约的本质在于该租用者可以接入电话业务，即他/她可以发出和接收呼叫。作为回报，他/她根据预定费率付钱给电话公司。账单一般包含两种类型的费用：固定费用和使用费用。固定费用无论是否使用了业务都需要计费。使用费用则取决于租用者进行了多少呼叫，可能还取决于他/她接收了多少呼叫。为了能对使用计费，电话公司必须监控发出和接收的呼叫。这种监控是基于连接的；即它由网络中的交换机完成。

图1示出了公用电话网的一部分，用以说明电话网所使用的众所周知的集中式计费方法。网络交换机SW(租用者的本地交换机)为每个发出的呼叫创建一个或多个计费记录CDR(计费数据记录)。这些记录首先存储在存储器中，然后发送到集中的账单处理系统，后者将它们存储在大容量存储器中，例如磁带或硬盘中。交换机和账单处理系统之间可以有附加的处理阶段。在该阶段对计费记录进行预处理，即为账单处理系统做准备。预处理可以包括，例如将费率类别域转换成另一种格式。账单处理系统的大容量存储器可以包含数百万个记录。这些记录形成了“原始数据”，账单处理系统对这些“原始数据”进行处理。因此，计费记录的处理以独立的批处理形式在记录生成日期之后的某个日期进行。应当注意，实际上计费可能比此处给出的例子复杂得多。例如，在蜂窝网络中，每个参与的蜂窝网络交换机可以产生计费记录。但是，计费原理类似于前述原理。

后文中将计费记录称为“CDR”，生成这些计费记录的程序称为“CDR生成器”。

电话业务的集中式计费基于离线计费，以及网络中有记录建立和释放时间的CDR生成器。但是，这种类型的计费在技术上并不适合网络中提供多媒体业务的情况。这有两个基本的原因。首先，目前大多数多媒体业务使用IP(Internet协议)，而IP用于提供无连接业务。基于电话网连接的计费不适合这类系统。其次，显然多媒体业务的计费必须基于传送信息的内容。目前的电话网可以监控建立和释放时间，但却无法监控正在传送的内容。在采用CDR生成器时，网络运营者必须在两种方案中选择：或者(a)计费基于连接，而与内容无关，或者(b)在每次传送时，从业务提供者那里得到传送信息的内容信息。第一种方案意味着运营者无法提供针对内容的计费；无法有效地利用已有的集中式电话网账单处理系统。对客户而言，这意味着他/她从该运营者那里得到一张张单，除此之外，还从每个业务提供者那里得到不同的账单。第二种方案需要高度集成的，技术上复杂的系统，其中服务器和CDR生成器之间存在大量业务量。

欧洲专利申请EP-A-0647052中描述了一种通信网的账单处理系统。该系统具有独立的账单处理服务器，用于处理网络中业务提供者的账单。在该系统中，客户终端总是首先向账单处理服务器报告它自身的标识，以及所需业务的标识。然后，账单处理服务器确定该客户是否有权接收该业务(例如是否可以给出该业务所需的信用)。如果有权，则账单处理服务器向提供该业务的服务器和客户终端发送一个临时的业务密钥，该密钥允许客户终端接入提供该业务的服务器。之后，客户终端发送连接请求消息给提供该业务的服务器，之后，这两者可以在业务交付之前就业务进行协商。在交付该业务之后，提供该业务的服务器发送有关提供的业务的报告消息给账单处理服务器，后者根据该消息为客户准备账单。账单可以例如通过E-mail或邮寄发送。

这类系统的主要缺陷在于，除了传输连接之外，它无法利用现有系统。为此，建立账单处理业务是一个相当复杂的操作。此外，例如就防抵赖而言，系统的信息安全得不到充分保证。这意味着，客户必须完全信任账单处理终端所生成的账单上的数目的精确性。客户也无法对结果账单上的数目有任何意见，例如因为网络中时延或其它不良因素的影响，造成客户终端的业务质量较差的情况，因为服务器已按约定交付了业务。这在持续的长期业务中尤为重要。

发明内容

本发明的目的是消除前述缺陷，提出一种解决方案，该方案可以例如在多媒体业务的账单处理过程中，尽可能有效地利用已有系统进行集中计费。

该目标通过独立专利权利要求中定义的方案来实现。

本发明的基本思想在于，在系统中使用至少一个独立的设备(称为“账单处理服务器”)，它基于客户所选择的业务，与客户协商一个在线契约；或者至少可以验证客户接受了该业务的具体条款。账单处理服务器充当将计费记录发送到实际计费系统的点，此外，它们可以在存储和/或将客户终端生成的计费记录发送到账单系统之前，验证这些记录的正确性。因此，实际上该方案很大程度上基于电话网中已有的实现，不同点在于，网络中不再测量业务使用并生成与其相关的计费记录或消息，而是由客户终端来进行这些操作，客户终端将这些计费记录发送到不同的账单处理服务器。

基于本发明的系统易于实现，因为它尽可能地采用了已有方案。此外，系统的原则是，它易于实现对数据安全重要的所有因素：认证，数据完整性，防抵赖性(数据传送的一方无法否认曾参与事务处理)和保密性(窃听者无法解释任何捕获的数据)，

该系统还使得新业务提供者更容易启动运营，因为已有现成的账单处理方案(即电话网的账单处理系统)。他们不需要投资计费的实现。

客户也可以对结果账单施加直接影响，例如因为网络中时延或其它不良因素的影响，造成客户所接收的业务质量较差的情况。

该系统还允许使用并行的支付方法，例如电子货币可以作为一种可选实现，或者基于本发明的系统中并行的支付方法。此外，该系统可以监控用户所使用的业务等级。因为监控在客户终端中进行，客户终端还产生计费记录，所以产生计费记录的处理可以对业务等级的变化作出快速反应。此外，系统易于调整。

该方案还适用于移动或蜂窝网络，所以业务的使用不受地理区域的限制。

按照本发明的方案可以用于相差很大的通信方案，因为它独立于数据传送协议和方法。

附图说明

下面参看附图中例子2-10详细描述本发明及其优选实施例：

图1说明了电话网中使用的已知计费方法；

图2说明了可以应用本发明的网络环境；

图3a说明了在启动实际计费之前，系统的不同部件之间的消息传递；

图3b说明了对应于图3a的情况，其中网络在账单处理服务器和提供业务的服务器之间使用了一个网关；

图4说明了客户终端上显示的契约窗口；

图5a说明了一个计费会话期间，客户终端和账单处理服务器之间消息传递的一个例子；

图5b说明了账单处理服务器和客户终端的时钟之间出现偏差的情况；

图6说明了计费记录的内容和结构；

图7a以功能框图的形式说明了客户终端的结构；

图7b详细说明了图7a所示CDR生成器的结构；

图8以功能框图的形式说明了账单处理服务器的结构；

图9a说明了客户使用服务器的业务的情况，该服务器不属于客户自己的账单处理服务器所管理的区域；

图9b说明了图9a中所示情况下账单处理服务器之间的消息传递；以及

图10说明了客户终端位于有线电视网时消息传递的一个例子。

具体实施方式

下面参看图2的例子详细描述本发明，图2说明了一般工作环境下基于本发明的系统。

该系统包括位于客户前端的客户终端(CT)。这些客户终端可以是例如连接到常规终端设备的个人计算机，移动台或单独的客户终端。终端设备也可以集成到例如调制解调器中。

此外，该系统包括至少一个账单处理服务器WD，它收集并验证客户终端所产生的计费记录。账单处理服务器可以位于例如因特网的边缘，与因特网业务提供者ISP的服务器相连。账单处理服务器的位置在逻辑上没有什么意义，但实际上，该位置的选择受以下因素的影响。首先，最好将账单处理服务器放置在与公用电话网相连或接近公用电话网的地方，使得它易于接入电话网的已有账单处理系统。从效率方面考虑，客户终端和账单处理服务器之间的连接必须尽可能快，时延易于控制(目前如果账单处理服务器例如位于因特网的深处，则不是这种情况)。因为该系统的目的是也提供本地业务(在地理上受限的区域)，使得能够对客户使用业务进行例如一月一次的账单处理，将账单处理服务器定位在远离客户的地方是不明智的。

账单处理服务器包括存储器MS，例如一盒磁带，用于存储账单处理服务器已接受的所有计费记录。收集的计费记录定期传送到账单处理系统BS，BS是公用业务电话网PSTN中已有的账单处理系统，或者位于宽带网络的类似于已有账单处理系统的系统。在传送到账单处理系统之前，计费记录临时存储在大容量存储器设备MS1中。

此外，该系统包括业务提供者，这些业务提供者提供的业务采用按照本发明的系统对客户进行计费。为了简化，图2仅包括了一个业务提供者(SP1)。该业务提供者可以例如通过因特网提供视频点播业务。

客户终端(CT)可以以图2所示的不同方式连接到网络。例如，ISDN连接是一种可能的选择。ISDN连接可以例如通过普通的路由器(R)来实现，这种情况下，ISDN连接上使用TCP/IP协议，或者通过ISDN卡和ISDN基群接入(BRI)实现。客户终端也可以通过调制解调器和模拟用户线路连接到网络交换机。此外，目前异步数字用户线路(ADSL)和高比特率数字用户线路(HDSL)技术提供了通过电话网双绞线向用户终端快速传送数据和视频的新的可能性。以后，系统可以用于例如ATM连接。客户终端也可以位于例如公司或其它组织的本地网络，或者它可以是有线电视网终端。因特网业务提供者也可以例如通过ISDN一次群接入(PRI)连接到网络交换机。

下面详细描述按照本发明的系统的操作。该例假定账单处理业务提供者是一个独立的组织机构，它仅利用所控制的账单处理服务器WD进行业务的账单处理。因此，账单处理业务提供者具有它自己的账单处理系统。

最初，账单处理业务提供者与每个业务提供者签订长期契约。在该契约中，账单处理业务提供者应允监控业务的使用，并进行针对使用的计费。作为对此的回报，账单处理业务提供者可以得到业务利润中的某一部分，或者固定费用。在契约实施之后，业务提供者所提供的每个业务得到一个唯一的标识符，该标识符在账单处理服务器(WD)和该业务提供者的服务器(SP1)中是相同的。此外，每个标识符都有给定的账单处理参数，由账单处理服务器加以利用。这样，在本发明的主要实施例中，账单处理服务器具有一个数据库，它包含了每个业务提供者的每个业务标识符的账单处理参数。后面将会提到，这种实现方法可以变成例如在每个会话开始时，将这些参数从业务提供者的服务器传送到账单处理服务器。

此后，账单处理业务提供者与客户(使用业务提供者所提供的业务的那些人)签订长期契约。每个客户得到一个唯一的客户标识符，它存储在账单处理服务器中，可能还存储在业务提供者的服务器中。此外，每个客户得到一对密钥，包括一个公开密钥和一个秘密密钥。这对密钥用于对计费记录进行签名和签名验证。客户的公开密钥存储在账单处理服务器中，秘密密钥则存储在终端设备中。在主实施例中，仅有客户知道该秘密密钥。也可以为客户定义一个信息文件(profile)。

在建立了这些长期契约之后，可以开始使用业务。

客户选择业务之后，但是在开始计费之前，客户和系统之间需要签订一个(短期)在线契约。该契约仅覆盖客户刚选择的业务，例如观看一场电影，或进行一次购物。下面的解释请参看图3a，该图说明了在线契约的生成。在该途中，连接到账单处理服务器的数据库是业务，账单处理和租用者数据库。

客户终端CT包括一个业务浏览器(它可以是例如一个Web浏览器)，客户通过它从因特网上发现适当的业务。在发现适当的业务，本例中是业务提供者SP1的视频点播业务之后，客户通过例如点击选项选择业务(例如一场电影)。业务选择阶段由箭头A指示。此时，客户终端和业务提供者的服务器进行通信。

如果客户已作出了选择，则业务提供者的服务器向账单处理服务器WD发送(箭头B)表示该电影的业务标识“Sid”，以及该客户的用户标识“Cid”。Cid可以例如从该客户的浏览器根据接收消息的源地址(例如TCP连接的套接字地址)得到。因此，浏览器总要至少提供客户标识和地址给账单处理业务提供者，但最好也提供给业务提供者。也可以例如从数据库中基于租用者给出的口令检索得到该租用者标识符。这种方式中，若干不同的客户可以使用来自同一地址的业务。也可以在网络中设置一个单独的服务器，它对业务提供者隐藏了客户标识，但将该信息提供给账单处理业务提供者。但是，这类方案较为复杂。

此后，账单处理服务器WD启动一个进程，处理该业务的使用。首先，账单处理服务器从业务数据库中检索对应于该业务的参数，并发送(箭头C)特定类型的计费记录(CDR)给客户终端。计费记录包含该会话期间需要使用的账单处理参数，以及契约编号。在接收到初始计费记录之后，客户终端程序在客户终端上打开一个窗口，此后称之为契约窗口。图4说明了使用虚构服务器名的契约窗口的一个例子。该窗口根据从账单处理业务接收的信息，显示不同方和该业务的数据。此外，该窗口显示了契约编号，它标识了该特定业务会话。该契约和前述长期契约的不同在于，该契约是短期的；它仅涉及当前的业务会话。因此，该契约仅覆盖，例如观看选择的电影。客户点击接受按键，接受该业务和对该业务的计费。客户可以点击取消按键，取消该业务。客户也可以将终端设置成，例如在总价格或每个时间单元的价格少于预定值的情况下自动接受该业务。

客户接受之后，客户终端向账单处理服务器返回它所接收的计费记录。但是，需要返回的计费记录包括一个数字签名(图3a，箭头D)。数字签名是指一种基于密钥对的已知加密算法。使用秘密密钥进行加密，而任何人可以使用公开密钥解密该消息。这种方式下消息的保密性丢失，但是它能确保消息来自正确的源点。因此发送者事后无法否认他/她发送过消息。如果采用数字签名，通常不加密整个消息，而仅加密根据该消息的摘要。摘要是一种校验和。从加密角度看，这种摘要非常强，局外人无法生成具有相同摘要的消息。摘要和时间标签通过发送者的秘密密钥加密，这些构成了数字签名。这种签名的实现已有若干不同方式，但因为本发明并不涉及消息的签名，所以此处不再详细描述签名的实现。对这方面感兴趣的读者可以在描述该领域的多种书籍中找到更详细的信息。(例如，参见Schneier，AppliedCryptography，ISBN 0-471-11709-9，Wiley & Sons，1996。)

此后，账单处理服务器WD通过已知方法验证签名，以认证CDR。为此，账单处理服务器从其租用者数据库中检索出该客户的公开密钥(箭头E)。账单处理服务器将接受的计费记录存储到它的账单处理数据库(箭头F)中，并保持一段时间，以防客户以后收回业务。此后，账单处理服务器要求业务提供者开始向该客户发送信息(箭头G)。

可以改变以上过程，例如使得服务器SP1在客户选择了业务之后，直接向客户终端发送业务标识符和其它可能需要的信息，客户终端再将业务标识符发送给账单处理服务器。为了防止客户改变业务标识符，服务器必须在消息中加入数字签名，由账单处理服务器辨别，或者账单处理服务器必须在从客户终端接收业务标识符之后，单独通过服务器SP1验证该标识符。另一种变化是让服务器SP1生成初始的计费记录，该记录包含该业务会话期间需要使用的账单处理参数。在这种情况下，账单处理服务器仅验证该消息，并将它发送到客户终端，或者账单处理服务器可以在消息中加入契约编号。

网络中账单处理服务器和业务提供者的服务器之间也可以使用单独的网关计算机。在这种情况下，网关计算机具有一组可用业务，服务器SP仅包含实际业务信息(例如视频数据)。图3b说明了采用这种方案时在线契约的生成。在这种情况下，网关计算机GW处理的操作与图3a所示方案中的服务器相同。在网关计算机从账单处理服务器接收到发送信息请求时(箭头G)，它向该服务器发送启动请求(箭头H)，该请求包含客户终端地址和业务标识符。在这种实施例中，可以进行附加的检查，使得网关计算机单独通过该服务器检查所请求的业务是否可以交付给该客户。进行这种附加检查可以有若干原因，该附加检查由图3b点线表示，可以是例如检查服务器负载。账单处理服务器和网关计算机不需要在物理上分离；它们可以集成在一台计算机中。

下面描述在通过上述实现方法之一签订了在线契约之后的该方法操作。

在开始业务之后(例如开始播放电影)，客户终端例如定期发送计费记录，该记录具有数字签名并包含需要计费的数量的信息。因此，需要发送的每个CDR代表了特定时间段的计费，将具有相同契约编号的所有计费记录的计费数量累加，可得到总计费。两个连续CDR之间的时间(因此一个CDR的计费)可以取决于业务提供者。

账单处理服务器利用客户的公开密钥，验证每个计费记录的来源，并将接受的计费记录存储到账单处理数据库。

计费记录从账单处理数据库中定期传送到账单处理系统BS(图2)，BS通过已知方法利用它们生成账单。账单被发送给客户。一个账单包含一张清单和客户在计费周期(例如一个月)期间使用的所有业务的计费。该账单可以作为打印的副本通过邮件交付，或者以电子形式交付到客户终端。因为账单处理系统的操作众所周知，所以此处不再详细描述。

系统中可以有例如以下9种不同类型(0-8)的计费记录(计费消息)：

0.契约：这是初始的计费记录(箭头C，图3)，账单处理服务器将其发送(未签名)给客户，如果客户接受该契约，则客户终端将签名的计费记录返回到账单处理系统。

1.支付：这类计费记录和签名一起在业务会话期间从客户终端发送到账单处理服务器，后者对其进行验证。

2.最后：这类CDR在其它方面对应于类型1，但它以附加信息形式声明它是客户终端在当前业务会话期间所要发送的最后一个CDR。这类记录例如在客户中断业务时发送。它还可以用于一次性计费。

3.脉冲(pulse)：这类CDR从账单处理服务器发送到客户终端。其目的是告诉客户终端，如果业务需要继续的话，它应当发送一个新的CDR。如果客户终端没有在指定周期内发送一个合法的CDR，则账单处理服务器向业务提供者发送一个中断消息。

4.丢失序列号：这类CDR从账单处理服务器发送到客户终端(在连续账单处理契约期间)，告知具有特定序列号的CDR尚未到达该账单处理服务器或该CDR不合法。在这种情况下，客户终端可以再次发送CDR以纠正这种情况。但是，双方都不一定具有这类功能。如果客户终端没有响应这类CDR，最佳的选择是该账单系统无权对丢失CDR的部分计费。

5.修改的契约：这类CDR从账单处理服务器发送到客户终端，它在其它方面对应于类型0计费记录，但它没有新的契约编号。它的契约编号与该时刻正在使用的短期契约编号相同。计费记录在业务会话期间发送，用以通知账单处理参数已经改变。如果价格下降，客户终端可以例如自动接受新的契约；相反情况则需要客户指定接受。

6.中止：这类CDR可以在任一方向上发送，以表明契约被终止。发送者签名该CDR。

7.数字现金：还可以以下面的方式使用账单处理系统：连接到特定支付的CDR(类型1或2)包含数字现金形式的支付。但是，账单处理服务器并不将数字现金传送到账单处理系统。账单处理服务器将其直接传送到例如银行的服务器(总是在它收集到相对较少的特定数量的数字现金的情况下)，或者发送到某个其它组织所维护的网络服务器(图2中的服务器BS’)，该服务器直接对客户的账户计费。除了集中式账单处理系统BS之外，数字现金可以用于通常的电子交易，或者作为取代集中式账单处理系统的一种可选实现。

8.计费同步：这类CDR从账单处理服务器发送到客户终端(在连续账单处理契约期间)，告知支付CDR发送得过于频繁。在这种情况下，客户终端可以跳过支付CDR的发送。

图5a说明了客户终端和账单处理服务器之间的消息传递的一个例子。每一个消息的类型在代表该消息的箭头上给出。具有数字签名的消息以连续线形式示出，没有数字签名的消息(仅存在一条这样的消息，它也可以被签名)以点线形式示出。该图说明了账单处理服务器在业务期间通知一次特定计费记录丢失的情况。

根据客户终端上同时执行的进程的数量，两个连续类型1CDR之间的时间(T)可以有所变化。如果客户终端的负载增加许多，CDR的生成滞后于标称值，则CDR中包括的计费相应变大。

实际上，连续计费包含了客户终端时钟漂移所引起的同步问题。因此，可能会发生客户终端没有以正确速率发送信息的情况。这种问题可以例如通过让账单处理服务器接受收集计费总数中特定比例的“差错”(例如百分之三)来解决。通过客户终端中较少的精确计算/舍入，可以增加这种“差错”。如果在计费会话期间“差错”增加，使得它大于账单处理服务器能接受的范围，则账单处理服务器发送带有序列号的类型4计费记录，该序列号是最新计费记录的序列号加1。此后，客户终端可以有多种方式返回该计费记录。客户终端可以例如编程成自动接受所有数量小于特定的预定限度的这类计费记录。

图5b说明了上述情况，以参考标记WDTF指示了账单处理服务器的连续时间帧，并在客户终端时间帧下给出了参考标记CTTF。客户终端在每个时间帧开始时发送支付CDR(类型1)。如果账单处理服务器中有一个时间帧没有支付，则该服务器发送一个类型4 CDR。在这种情况下，客户终端发送支付CDR来自动应答，之后在下一客户终端时间帧开始时发送后一个支付CDR。

如果客户终端时钟过快，客户终端在一个账单处理服务器时间帧中的某一点发送两个支付CDR。这类情况可以通过例如以下方式纠正：账单处理服务器向客户终端发送一个附加消息。该附加消息是类型4 CDR的逻辑反。接收到附加CDR之后，客户终端跳过一个支付CDR。为此，需要一个单独的CDR类型(类型8)。

系统所需的所有计费信息在协议消息(计费记录)的连续域中传送。图6说明了计费记录中使用的域：

类型：说明CDR的类型，即8种上述计费记录中的哪一种。

长度：该域说明CDR的字节总长度，包括类型和长度域。

契约编号：该域包括账单处理服务器给出的一个整数。该整数对属于同一计费会话的所有CDR都相同。

序列号：一个整数，说明同一计费会话中CDR的生成次序。客户终端将编号0给了它所返回的契约CDR(类型0)。之后，对每个CDR编号加1。该域在CDR类型3，5，6和7中没有定义，在类型4中表明丢失的CDR的序列号。

业务标识：该域的内容说明用户被计费的业务。作为账单处理业务提供者和(多媒体)业务提供者之间的契约的结果，该域的参数包含了它的值。

业务类型：该域的参数将业务划分成不同的类以用于统计目的。例如，Web页，视频点播，文件传送等等。

开始时间：该域的参数示出了CDR类型0和5以及3，4和6的当前时间，和类型1和2的计费周期的开始时间。

结束时间：该域的参数定义了类型1和2 CDR的计费会话的结束。对类型0和5的CDR而言，开始和结束时间差是可接受的最大计费周期。其它类型的CDR中该参数没有定义。

标识符：该域的参数说明了客户，账单处理服务器和服务器标识符。这些标识符可以是整数或网络地址，但它们在账单处理系统中必须是唯一的。

支付方法：类型0，5，1和2定义了该域的参数。支付方法可以例如如下分类：免费，一次性计费(一个CDR)，周期性或外部触发，即客户终端的另一进程可以触发它。例如，如果在最近的一分钟内接收到可接受的视频信号，客户终端的视频播放器可以一分钟触发一次CDR的生成。

金额：该域表明客户的欠款(整个会话或两个CDR之间的时间周期)。

业务量数据：该域包含了从客户终端的外部应用向客户终端，并进而向网络发送的信息。

签名：该域包含了客户的数字签名，该签名用于CDR的认证。

在本申请的附录1中，使用抽象文法表示法1(ASN.1)详细描述了CDR结构，ASN.1是电信领域中用于描述数据结构的一种通用的描述语言。抽象文法描述语言和相应的传送文法在ISO 8824标准中定义，传送文法是一组指令，用以将描述语言所描述的数据结构表示成比特流。

计费记录可以例如在IP包的数据域中发送，该IP包可以包含一个或多个计费记录。

图7a以功能框图的形式说明了客户终端(CT)的操作。在本发明中，设备的核心是CDR生成器(CG)，它生成计费记录。连接到CDR生成器的是安全库(SL)。它的存储器包含了客户的秘密加密密钥，它处理计费记录的签名。CDR生成器生成CDR并将其发送到安全库，后者使用客户的秘密加密密钥对这些CDR签名。安全库将签名后的CDR返回给CDR生成器，后者将其发送到账单处理计费器(WD)。

如果应用和环境要求必须在客户终端和账单处理服务器之间传送加密消息，则安全库处理加密，签名和签名验证。

安全库可以基于硬件或软件实现。但是，基于硬件的方案更快。安全库，或其一部分可以例如采用智能卡实现，该智能卡包含例如客户的秘密加密密钥。

此外，客户终端包含接受该业务的元件。这些元件可以包括，例如业务播放器VP，它可以是一个视频播放器，显示从网络接受的视频信号，还可以指令CDR生成器生成计费记录。业务浏览器SB，业务播放器VP和CDR生成器通过终端的通信库CL连接到网络。CL生成了协议栈，客户终端按照该协议栈工作。协议栈可以是，例如一个TCP/IP栈，例如一个微软的Winsock。

客户终端还可以包含账单计数器BC，客户可以使用它来检查业务提供者所发送的账单的准确性。此外，客户终端可以具有不同的部件来监控接收信息的业务质量(Qos)。例如，视频播放器可以在业务质量下降至特定值以下时，命令源停止传送信息。

图7b更详细地说明了CDR生成器的功能框图。契约逻辑单元CLU1根据配置数据库CDB中存储的信息处理计费记录的生成。它包含将接受的契约信息传送到图形用户接口GUI，并生成上述类型的计费记录的逻辑。该逻辑包括定时部件，它定义两个连续CDR之间的时间。契约逻辑单元CLU1通过外部控制接口ECI连接到通信库，通过内部控制接口ICI连接到业务播放器。外部控制接口负责转换内部和外部CDR格式。内部控制接口处理业务播放器和契约逻辑单元之间的消息传递，进行业务播放器所用消息格式和设备内部消息格式之间必要的转换。内部控制接口和业务播放器之间的连接(接口A30可以例如通过通信库(TCP套接字)来实现。配置数据库CDB用于存储用户的设置(用户的选择)，它可以用于存储不同业务(例如电影)的信息，并根据接受的业务标识符发送给客户。该数据库可以例如采用Microsoft Access和Borland Paradox实现。配置数据库由管理单元MM控制。管理单元，配置数据库和契约逻辑单元都连接到设备的图形用户接口(GUI)。GUI可以采用例如Java applets或MicrosoftVisual Basic编程工具实现。(Java applets是较小的程序包，在用户打开一个含有applets的Web页时传送到客户的计算机。)注意配置数据库部分可以位于网络中。

如果例如为视频点播设计了业务播放器，则可以使用个人计算机和为视频点播业务设计的程序来实现。一种这样的程序是StreamWorks，由美国的Xing Technology公司出品。

管理单元和契约逻辑单元通过A1接口连接到安全库。安全库和A1接口可以例如采用Setec Oy出品的SETCOS 3.1智能卡，或者采用基于智能卡国际标准的某种相当的产品实现。

该方法实现中使用的数据传送方法随网络类型和用于将客户终端连接到网络的方法而变化。如果客户终端例如通过路由器(IP信道)连接到网络，则计费记录可以在TCP帧中发送。如果客户具有例如ISDN连接(2B+D)，则CDR可以在D信道的ISDN信令分组(用户到用户消息)中发送，或者可以在一个B信道上实现TCP连接。计费数据也可以例如在SS7网络的TCAP消息中发送。对数据传送重要的部分仅仅是客户终端，账单处理服务器和服务器之间存在所需连接，该连接使得传送上述消息成为可能。

上面并没有定义从业务提供者传送信息给客户的方法，因为它与本发明没有直接关系。信息可以在包中传送(如目前因特网那样)，或者专用连接(固定连接或虚连接)可以用于传送。有些业务-例如视频点播-可能需要客户和服务器之间的专用连接。网络运营者可以单独对这些连接计费，但如果使用这些连接的特定计费需要包含在按照本发明的系统的账单中，则必须收集网络交换机生成的CDR。在这种情况下，这些CDR包含在契约编号中较为有利，因为这样连接的价格能够与导致形成连接的业务相关联。因此，主叫方将契约编号发送给交换机是有利的。这可以通过与生成和中断连接(业务通过该连接实现)相关的控制消息来完成。也可以在CDR中使用时间标签来将连接和业务使用关联在一起。

图8以一般性的框图说明了账单处理服务器WD的结构。设备的核心是契约逻辑单元CLU2，它能够接入业务数据库SED，租用者数据库SUD和账单处理数据库BD。业务数据库包含不同业务提供者的信息，以及业务使用的计费参数。账单处理服务器还可以例如根据一天中的时刻独立改变计费参数。租用者数据库包含管理账单处理服务器的运营者的客户数据(包括每个客户的公开密钥)。从客户终端接收的计费记录存储在账单处理数据库中。加密部件(CM)与该契约逻辑单元相关联。CM处理计费记录签名的验证。该部件对应于客户终端的SL部件。契约逻辑单元从客户终端接收客户终端签名后的计费记录，将其发送到加密部件进行验证。契约逻辑单元将接受的计费记录存储到账单处理数据库。契约逻辑单元通过通信库(CL’)连接到网络，该通信库生成的协议栈定义了连接的实现方式。

实际上，上述契约逻辑单元可以通过例如基于国际系统描述语言(SDL)标准的工具，例如Telelogic AB的SDT工具实现。

账单处理服务器的数据库可以在上述存储器MS(图2)中，可以位于账单处理服务器中。此外，计费记录可以存储在单独的大容量存储器MS1(图2)中，MS1位于网络的账单处理服务器和账单处理系统之间，使得账单处理系统可以容易地处理存储在MS1中的信息。利用这类单独的数据库，业务提供者可以使用数据库进行不同类型的查询，从而改进其业务。业务提供者，或者客户可以例如在计费周期内(例如通过电子邮件)询问特定服务的计费。

租用者和业务数据库可以同时位于账单处理服务器和业务提供者的服务器(后者利用它们例如进行数据认证)。这些数据库可以由不同组织维护，而不必是同一个组织。例如，免费业务不需要存储在账单处理服务器数据库中。此外，数据库中的租用者和业务记录不需要相同。只有提供业务的服务器发送给账单处理服务器的那些租用者和业务标识符才必须相同。

账单处理服务器可以包括多个并行的服务器单元，并可以对它们使用已知的负载分配原则，例如为它们配备一个共用的负载共享单元，后者以特定方式在并行单元之间分配业务请求。

因为一个账单处理服务器处理位于受限地理区域内的一组特定客户，从这个角度讲，利用本发明提供的业务是本地的。图9a说明了两个不同账单处理服务器WD1和WD2所管理的区域SA和SA’。特定账单处理服务器的一个客户自然可以使用以下服务器的业务，该服务器位于不同账单处理业务提供者(因而是不同的账单处理服务器)所管理的区域中，例如在另一城市或国家。图9a说明了这种情况，其中位于账单处理服务器WD1所管理的区域中的客户C1联系服务器S3，而服务器S3与管理账单处理服务器WD2的账单处理业务提供者达成协议。图9b说明了消息传递。

账单处理服务器WD2从服务器S3接收客户标识符(Cid)(或地址)和业务标识符Sid，意识到该客户并不是它自己的客户。在这种情况下，该账单处理业务提供者必须签订一个双方契约，使得账单处理服务器WD2可以在从服务器S3接收到客户和业务标识符之后，发送初始CDR(契约CDR)给账单处理服务器WD1。后者(即WD1)将账单处理服务器的特定信息(账单处理服务器标识符和契约编号)转换成相应的它自己的信息，之后，发送初始CDR给该客户。在账单处理服务器WD1中存储一个“空”CDR，使从账单处理服务器WD2接收的初始CDR与发送给该客户的契约CDR相关联，前述“空”CDR与从账单处理服务器WD2接收的签名契约CDR相同，但是业务标识符被替换成契约编号，账单处理服务器WD1利用该契约编号来识别该业务。通过这种方式，账单处理服务器WD1知道该业务来自与另一账单处理业务提供者签订契约的某个业务提供者。

此后，账单处理服务器WD1可以收集使用该业务所生成的CDR。其情形类似于客户发出一次国际呼叫的情况。

本地收集的CDR可以在本地账单处理系统中进行处理，它们也可以发送到拥有账单处理服务器WD2的账单处理业务提供者。在电话网中，CDR的处理和账单处理通常在本地系统中进行。属于另一运营者的账单处理部分将在以后返回给他们。

以上的例子示出了将在线契约的制定委任给本地账单处理服务器，并使用与公用电话网相同的管理方法，可以在全球范围内扩展按照本发明的方法。

在系统中加入类似于移动通信网络中的归属和访问寄存器，可以实现与移动通信网相同的漫游特性。在这种情况下，必须保证客户的公开密钥安全地传送到接近该租用者的账单处理服务器，使该账单处理服务器能够验证计费记录。(如果传送无法安全进行，则第三方可能会在传送期间修改密钥，通过这种方式造成原租用者的损失。)租用者的公开密钥可以传送到例如接近该账单处理服务器的一个数据库(VLR，访问位置寄存器)，该账单处理服务器能够访问该数据库。最接近漫游租用者的账单处理服务器可以利用该租用者自己的账单处理服务器的标识符进行账单处理。在业务会话结束之后，收集的CDR被发送给该租用者自己的账单处理服务器。

客户终端可以是，例如已加入本发明所需特性的一个普通移动台，本发明可以用于移动电话网或移动通信网。

如果客户终端位于有线电视网中，则例如播放视频点播的业务可以如下实现。因为有线电视网是一种广播网络，其中所有客户接收相同信号，服务器利用密钥加密它所发送的视频信号，该密钥频繁改变，例如每隔5-10分钟改变一次。每次服务器改变密钥，它将该密钥告知账单处理服务器，账单处理服务器在从客户终端接收到相应支付之后，将新密钥交给客户终端。

图10说明了客户终端是有线电视网终端情况下计费的支付。签订契约之后，账单处理服务器将它从提供该业务的服务器接收的第一密钥交给客户终端。该账单处理服务器定期发送类型3计费记录(脉冲)给客户终端；通过这种方式，它要求新的支付。账单处理服务器响应于支付，发送一个新密钥，该密钥来自提供该业务的服务器。该密钥可以例如在单独定义类型(类型9)CDR中发送，其中可以采用该用户的公开密钥加密，然后安置到签名域。如果存在局外人复制密钥的风险，则可以进行加密。密钥仅发送给已从其接收了支付CDR的那些客户终端。业务提供者不需要一次发送一个密钥给账单处理服务器；全部密钥可以一起发送。此外，不需要使用类型0 CDR与客户签订单独的契约。而是将第一密钥的发送作为系统侧的在线契约提议，第一支付CDR充当客户侧对该契约的接受。之后，可以给该业务会话一个契约编号。

有线电视应用也可以不采用类型3计费记录来实现。这种情况下，作为终端发送支付CDR的响应，向每个客户终端发送密钥。

尽管以上结合附图所示例子描述了本发明，但显然本发明并不局限于这些例子，它可以在所附专利权利要求书所设定的范围内以若干方式加以变化。下面简要描述一些可能的变化。

例如，客户终端可以不发送实际的计费记录给账单处理服务器，而是发送某个其它消息，账单处理服务器可以利用该消息作为生成计费记录的基础。例如，只要业务仍在继续，客户终端就发送所谓的激励消息，之后，账单处理服务器生成一个计费记录，其中将最后一个激励消息和接受契约时刻之间的时间作为业务的持续时间。也可以在客户终端告知以确定方式接受了选择的业务之后，账单处理服务器生成计费记录。

在上述系统中，业务提供者所提供的业务包括发送信息。原则上，业务也可以包括向客户交付物理货物(例如通过邮寄业务)。这种情况下，账单处理系统生成计费记录(因为客户终端无法测量业务质量)。

如果客户和账单处理服务器之间的连接足够安全，则计费记录中不需要包括数字签名。此外，也不需要向账单处理服务器发送单独的在线业务接受消息，因为第一支付CDR可以充当客户侧的在线业务的接受消息。因此，唯一重要的因素是某个消息通知账单处理服务器客户已接受了契约。

也可以是首先在账单处理服务器和客户之间签订在线契约，然后才联系业务提供者的服务器。

也可以以业务会话的形式实现业务，其中除了客户终端之外，还有多于一个服务器参与。一个服务器可向客户终端发送例如视频信号，而另一个服务器同时发送与视频信号相关的附加信息，例如文本或图。

如果上述服务器具有不同的拥有者，则支付可以在这些拥有者之间以若干方式进行划分。例如，账单处理系统可以在逐月生成账单时计算这些业务提供者的份额。另一种方案是，账单处理服务器按以下方式分配支付：在从客户终端接收到第一支付CDR时，账单处理服务器生成例如两个新CDR，它对其进行签名并存储到大容量存储器中。这些计费记录中的一个包含了视频业务的支付，另一个是数据业务的支付。这些支付之和是从客户终端接收的计费记录中的金额。在业务提供者之间划分该金额的方法是存储在业务数据库中的组合业务的一个参数。如果多个服务器参与同一业务会话，账单处理服务器可以相应地将从客户那里接受的金额划分成多个计费记录。除了能够在业务提供者之间通过生成新CDR来划分支付之外，账单处理服务器还可以直接取走它的份额。因此，如果同时存在N个业务提供者，则账单处理服务器可以将每个接收到的支付CDR划分成N+1部分，用于新的计费记录，使每个业务提供者和账单处理业务提供者能够得到其份额。

--CDR结构

-＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

-在初始版本中，编码是面向字节的，没有标记和

-长度域.如果没有指定什么，则ENUMERATED

-被编码成一个八位字节，INTEGER被编码成

-一个MSB第一格式的八位字节字符串

-(长度为2，4或8，取决于最大长度).

CDR_cdrType::＝ENUMERATED{

contract (0)，--初始CDR，WD-＞客户机

payment (1)，--正常支付CDR

final (2)，--同上，客户机停止

pulse (3)，--指示新支付

missing_seq (4)，--序列号丢失的CDR

mod_contract(5)，-contr.重新协商

abort (6)，--终止连接，不加钱

E_cash (7)--电子现金承载者CDR，类型B

}

-类型0..6在CDRtypeA中重载，类型7使用

-CDRtypeB

CDR_network::＝ENUMERATED{

unknown (0)，

TCP/IP (1)，

ISDN (2)}

CDR_serviceTypeType::＝ENUMERATED{

unknown (0)，

…

}

CDR_timeType::＝

hundrethOfSec OCTET STRING(SIZE(1))，

seconds OCTET STRING(SIZE(1))，

minutes OCTET STRING(SIZE(1))，

hours OCTET STRING(SIZE(1))，

days OCTET STRING(SIZE(1))，

year_lo OCTET STRING(SIZE(1))，

year_hi OCTET STRING(SIZE(1))}

CDR_identifierType::＝SEQUENCE{

type ENUMERATED{system_assigned(0)，E164_addr(1)，...}

data OCTET STRING(SIZE(16))

}

CDR_paymentMethodType::＝ENUMERATED{

free (0)，--不计费

one_time(1)，--约定一次支付有效

periodic(2)，--基于时间

wd_req(3)，--由WD消息触发支付

ext_trig(4) --由一个外部客户机应用触发支付

}

CDR_currencyType::＝ENUMERATED{

majorType ENUMERATED{bill(0)，E_cash(1)}，

currency ENUMERATED {FiM(0)，USD(1)，...}

}

--编码到一个八位字节，使得主类型占据

最高有效位，现金比特0-6

CDR_moneyAmountType::＝SEQUENCE{

currency CDR_currencyType，

value INTEGER(0..MAX_WORD)

--如果使用电子现金，则该值定义了

-电子现金承载者CDR的序列号

CDR_signatureType::＝SEQUENCE{

present ENUMERATED{absent(0)，present(1)}，

type ENUMERATED{RSA-with-MD5(0)，DES-with-MD5(1)}，

signature OCTET STRING SIZE(64)

CDRformatA::＝SEQUENCE{

type CDR_cdrType，

Iength INTEGER(0..MAX_S_WORD)，

contractNr INTEGER(0..MAX_D_WORD)，

sequenceNr INTEGER(0..MAX_WORD)，

serviceld INTEGER(0..MAX_D_WORD)，

serviceType CDR_serviceTypeType，

startTime CDR_timeType，

endTime CDR_timeType，

clientld CDR_identifierType，

watchdogld CDR_identifierType，

serverld CDR_identifferType，

payMethod CDR_paymentMethodType，

moneyAm CDR_moneyAmountType，

trafficData OCTET STRING(SIZE(8))

signature CDR_signatureType

}

CDRformatB::＝SEQUENCE{

type CDR_cdrType，

length INTEGER(0..MAX_S_WORD)，

contractNr INTEGER(0..MAX_WORD)，

sequenceNr INTEGER(0..MAX_WORD)，

e_cash OCTET_STRING(SIZE(0..200))

}

Claims

1.一种处理服务使用的方法，所述方法包括：

-向设备提供用于加密服务的密钥；

-在设备中从终端接收一个消息，该消息通知关于定义的条款接受选定的服务；以及

-从所述设备向所述终端发送用于选定服务的密钥。

2.如权利要求1所述的方法，包括在从所述终端发送所述通知接受的消息前，将建议关于服务的合同的消息发送给终端。

3.如权利要求2所述的方法，其中所述建议合同的消息是从设备发送的。

4.如权利要求2所述的方法，其中所述建议合同的消息是从服务器发送的。

5.如前述任一权利要求所述的方法，包括在设备和终端之间协商选定服务的条款。

6.如权利要求5所述的方法，其中所述通知接受的消息是与所述协商相关的消息。

7.如前述任一权利要求所述的方法，包括根据从所述终端接收的消息，从所述设备向记帐系统发送与选定服务相关联的至少一个计费消息。

8.如前述任一权利要求所述的方法，包括在接收所述通知接受的消息后，生成与选定服务相关联的至少一个计费记录。

9.如权利要求8所述的方法，其中与选定服务相关联的计费消息包括计费记录。

10.如前述任一权利要求所述的方法，其中所述通知接受的消息包括计费记录。

11.一种处理服务使用的设备，所述设备包括：

-接收加密服务的密钥的装置；

-从终端接收消息的装置，所述消息通知关于定义的条款接受选定的服务；以及

-向所述终端发送用于选定服务的密钥的装置。

12.如权利要求11所述的设备，被配置为与终端协商选定服务的条款。

13.如权利要求11或12所述的设备，包括向终端发送建议合同的消息的装置。

14.如权利要求11-13中任一项所述的设备，包括向记帐系统发送与选定服务相关联的至少一个计费消息的装置。

15.如权利要求11-14中任一项所述的设备，包括在针对相应服务接收所述通知接受的消息后，生成与选定服务相关联的至少一个计费记录的装置。

16.如权利要求11-15中任一项所述的设备，其中所述设备被配置为处理计费记录。

17.如权利要求11-16中任一项所述的设备，其中所述设备是计费服务器。

18.一种使用服务的终端，包括；

-选择服务的装置；

-向设备发送关于定义的条款接受选定的服务的消息的装置；以及

-从设备接收选定服务的密钥的装置。

19.如权利要求18所述的终端，被配置为与设备协商选定服务的条款。

20.如权利要求18或19所述的终端，包括接收建议服务的合同的消息的装置。

21.包括如权利要求11-17中任一项所述的至少一个设备和如权利要求18-20中任一项所述的至少一个终端的系统。

22.一种连接到网络的客户终端，所述终端包括：

从由多个服务器提供的多个服务中选择服务的装置；

响应于提供的服务，生成计费记录的计费记录生成装置，所述计费记录生成装置被配置为使得生成的计费记录被发送到服务器。

23.如权利要求22所述的终端，其中所述客户终端(CT)包括将数字签名添加到生成的计费记录的装置(SL)。

24.如权利要求22或23所述的终端，其中所述终端被配置为响应于来自所述生成的计费记录将被发送到的所述服务器的命令打开合同窗口，所述窗口呈现有关服务的信息和接受服务的合同的接受按钮。

25.如权利要求24所述的终端，其中所述客户终端被配置为响应于按下所述接受按钮，向所述生成的计费记录将被发送到的所述服务器发送合同信息和签名。

26.如权利要求22-25中任一项所述的终端，其中客户终端包括服务播放器，其与生成计费记录的装置相连，用于在由服务播放器接收的信号质量下降时停止生成计费记录。

27.如权利要求22-26中任一项所述的终端，其中所述计费记录生成装置被配置为使得生成的计费记录被发送到预定服务器。

28.如权利要求22-27中任一项所述的终端，其中所述生成的计费记录将被发送到的所述服务器包括计费服务器。

29.一种计算机程序，包括：

至少一个计算机可执行组件，其在运行时：

允许从由多个服务器提供的多个服务中选择服务；

响应于提供的服务生成计费记录；以及

使得生成的计费记录被发送到服务器。

30.如权利要求29所述的计算机程序，其中所述至少一个计算机可执行组件在运行时将数字签名添加到生成的计费记录。

31.如权利要求29或30所述的计算机程序，其中所述至少一个计算机可执行组件在运行时打开合同窗口，所述窗口呈现有关服务的信息和接受服务的合同的接受按钮。

32.如权利要求31所述的计算机程序，其中所述至少一个计算机可执行组件在运行时，响应于按下所述接受按钮，使得合同信息和签名被发送到所述服务器。

33.如权利要求29-32中任一项所述的计算机程序，其中所述至少一个计算机可执行组件在运行时，用于在接收的信号质量下降时停止生成计费记录。