CN100525361C - 在电信网中提供充值付费业务的系统和方法 - Google Patents

Abstract

本发明公开了一种在电信网中提供充值付费业务的系统，包括业务控制点(SCP)、账务平台和充值付费平台，并进一步包括一个用于提供统一充值付费业务的统一充值付费中心(VC)、用于对VC进行管理的充值付费业务管理点(VMP)、用于接入充值付费业务请求的充值付费业务管理接入点(VMAP)以及用于转发充值付费业务消息的通用通讯前置机(GFEP)，其中VC通过VMP连接到VMAP，并且通过GFEP连接到账务平台和充值付费平台，同时VC和SCP相连接。本发明同时还公开了一种在电信网中提供充值付费业务的方法。通过本发明可以提供统一的充值付费业务，给用户和业务提供者带来便利，并降低成本。

Description

在电信网中提供充值付费业务的系统和方法

技术领域

本发明涉及电信网中的充值付费业务，更具体地说，涉及一种在电信网中提供充值付费业务的系统和方法。

背景技术

近年来，充值和付费业务在电信网中得到了迅速的发展，例如，用户可以购买200充值卡，然后通过拨打200充值电话将购买的充值卡的金额充值到自己的200账户上，从而可以继续使用电信网提供的200电话业务；又例如，用户可以拨打电话银行的接入号码，通过自己的银行账户缴纳固定电话费或者移动电话费等等，甚至还可以缴纳电费和水费等等。提供充值付费业务给电信网的用户带来了极大的方便，使得用户可以不去电信公司、电力公司或者水力公司的柜台就可以继续使用这些公司提供的服务，也正是因为如此，充值和付费业务在如今得到了非常快速的发展。

如今的充值和付费业务都是通过如图1所示的基于电信网的智能网提供的，从图1可以看出，业务管理点(SCP)通过通讯前置机(FEP)连接到账务平台和充值付费平台，具体地说，SCP和FEP相连，FEP同时连接到账务平台和充值付费平台。而SCP还可以通过七号信令网连接到远端的智能网系统，也就是连接到远端的SCP和信令转接点(SSP)。另外，SCP还通过业务管理点(SMP)连接到业务管理接入点(SMAP)。在这种系统中，所有的充值付费业务都是由SCP来处理的，账务平台也称为账务中心，在其上保存了用户的账户信息，而充值付费平台也称为第三方信息平台，例如银行平台等，用于负责充值付费操作。

当用户需要进行充值付费时，拨打相应的接入号码，然后输入账户信息等必要信息，SCP通过和账户方以及充值付费平台的消息交互，完成用户所需的充值付费操作。但是在现有技术中，不同的充值付费业务虽然都是由SCP来执行的，但是每一种充值付费业务都具有一种单独的业务逻辑，而且每一种充值付费业务都需要建立一个单独的数据库，同时拨打接入号码后所播放的语音提示可能也不尽相同。正是因为不同的充值付费业务的前台管理界面、后台数据库的不同，造成各种充值付费业务各自为政、自成一体。这样用户使用不同的充值付费操作时，可能需要购买不同的充值卡或者银行卡，并且不同的语音提示也会给用户造成困惑。而对业务提供者来说，需要建立不同的充值充值付费平台，从而也增加了建设、运营和维护的不便。

另外，用户在使用不同的充值付费业务时购买不同的充值付费卡增加了用户的使用成本。同时，业务提供者建立不同的充值充值付费平台也造成了运营成本的提高，并且造成资金的浪费。

发明内容

有鉴于此，本发明的主要目的在于提出一种在电信网中提供充值付费业务的系统，使各种充值付费可以在相同的业务平台上实现，从而给用户和业务提供者同时提供极大的便利，并降低成本。

本发明的另一个目的是提供一种在电信网中提供充值付费业务的方法，以提供统一的充值付费业务，从而给用户和业务提供者同时提供极大的便利，并降低成本。

本发明的上述目的是通过如下的技术方案予以实现的：

一种在电信网中提供充值付费业务的系统，包括SCP、账务平台和充值付费平台，并进一步包括一个用于提供统一充值付费业务的统一充值付费中心(VC)、用于对VC进行管理的充值付费业务管理点(VMP)、用于接入充值付费业务请求的充值付费业务管理接入点(VMAP)以及用于转发充值付费业务消息的通用通讯前置机(GFEP)，其中VC通过VMP连接到VMAP，并且通过GFEP连接到账务平台和充值付费平台，同时VC和SCP相连接。

其中VC、账务平台和充值付费平台可以同时连接到GFEP。或者，系统进一步包括一个支付接口FEP，此时VC连接到GFEP，GFEP、账务平台和充值付费平台同时连接到支付接口FEP。在系统进一步包括支付接口FEP的情况下，支付接口FEP和账务平台可以集成在同一个物理设备中。

并且，系统可以进一步包括处理除充值付费业务之外的智能业务的业务管理点SMP、业务管理接入点SMAP和通讯前置机FEP，VMP、VMAP以及GFEP分别和SMP、SMAP以及FEP集成在同一个物理设备中。VC和充值付费平台也可以集成在同一个物理设备中。

在上述系统中，GFEP和账务平台以及充值付费平台之间的连接采用数字数据网络(DDN)专线，VC和GFEP、SCP、VMP之间以及VMP和VMAP之间的连接采用局域网，它们之间的消息格式采用TCP/IP协议。另外，VC可以进一步通过七号信令网连接到异地SCP，所述连接采用七号信令连接方式。

一种在电信网中提供充值付费业务的方法，包括：

a.建立一个用于集中处理充值付费业务的VC，并将所有充值付费业务信息存储在一个统一格式的数据库中；

b.为VC分配一个单独的接入电话号码，并且提供一个和用户之间的适用于所有充值付费业务的交互处理流程；

c.设置VC、账务平台和充值付费平台之间的消息格式包括目的节点、源节点、消息类型和充值付费类型；

d.当VC接收到用户通过拨打VC的接入电话号码发起充值付费业务后，播放语音提示要求用户提供充值付费业务所需信息，并根据用户提供的信息生成包括目的节点、源节点、消息类型和充值付费类型的充值付费业务请求消息，然后通过VC、充值付费平台和账务平台之间的消息交互完成充值付费操作；

当充值付费业务由充值付费平台发起时，充值付费平台生成包括目的节点、源节点、消息类型和充值付费类型信息的充值付费业务请求消息，然后通过VC、充值付费平台和账务平台之间的消息交互完成充值付费操作。

上述步骤b中VC和用户之间的交互处理流程包括：

提示用户选择充值业务还是付费业务；

如果用户选择充值业务，提示用户选择被充值业务类型，然后提示用户输入被充值账号和密码，然后提示用户选择充值卡充值还是银行划款充值，并相应地提示用户输入充值卡卡号和密码或者输入银行账号和密码；

如果用户选择付费业务，提示用户选择被付费业务类型，然后提示用户输入被付费账号和密码，然后提示用户选择充值卡付费还是银行划款付费，并相应地提示用户输入充值卡卡号和密码或者输入银行账号和密码。

并且，在用户输入被充值账号或者被付费账号之后可以进一步包括提示用户选择是否进行余额查询。

上述步骤d中当VC接收到用户通过拨打VC的接入电话号码发起充值业务后，所述通过VC、充值付费平台和账务平台之间的消息交互完成充值操作包括：

VC向账务平台发送一个查询余额申请消息包，账务平台进行余额查询操作，然后向VC返回带有查询的余额值的查询余额确认消息包；

VC向充值付费平台发送扣款申请消息包，充值付费平台在进行扣款操作之后向VC返回扣款确认消息包；

VC向账务平台发送充值申请消息包，账务平台进行充值操作，然后向VC返回充值确认消息包。

上述步骤d中当充值业务由充值付费平台发起时，所述通过VC、充值付费平台和账务平台之间的消息交互完成充值操作包括：

充值付费平台向VC发送一个划款申请消息包，VC在接收到该消息包后，向账务平台发送一个充值申请消息包；

账务平台进行充值操作，然后向VC返回一个充值确认消息包，VC在接收到该消息包后，向充值付费平台返回一个划款确认消息包。

上述步骤d中当VC接收到用户通过拨打VC的接入电话号码发起付费业务后，所述通过VC、充值付费平台和账务平台之间的消息交互完成付费操作包括：

VC向账务平台发送账单申请消息包，账务平台在确定该被付费账号可付费的情况下，向VC返回账单资料消息包；

VC向充值付费平台发送扣款申请消息包，充值付费平台在进行扣款操作后向VC返回扣款确认消息包；

VC向账务平台发送销账申请消息包，账务平台进行销账操作，然后向VC返回销账确认消息包。

这里的充值付费平台是银行平台或者付费卡号平台。

在进行根据本发明的充值操作时，VC、充值付费平台和账务平台之间的消息交互采用TCP/IP消息或者七号信令消息。

从本发明的上述技术方案可以看出，本发明在现有的通信网中独立于原有的SCP建立了一个用于集中处理充值付费业务的VC，并相应建立了和VC共同使用的VMP和VMAP。这样所有的充值付费业务可以单独出来集中在VC上进行处理，而其它智能业务都由原来的SCP执行，从而为统一充值付费提供了硬件的基础。

除了建立了统一的VC平台之外，对于所有的充值付费业务的相关信息存放在一个统一格式的数据库中，并且对于所有的充值付费业务提供了统一的和用户交互的处理流程，同时对于同一种类的充值付费操作无论具体的充值付费平台和账务平台都采用同样的处理流程，从而通过上述步骤对于不同的充值付费业务统一了数据库、前台管理界面和业务处理流程。

进一步，由于不同的充值付费操作所涉及的目的节点和源节点不同，也就是所涉及的账务平台和充值付费平台不同，因此在处理具体的充值付费操作时需要识别不同的节点信息，为此本发明对于VC、账务平台和充值付费平台之间的消息格式进行了重新设置，使其至少包括充值付费类型、消息类型、源节点信息和目的节点信息，这样对于不同的具体充值付费请求分配不同的信息即可实现它们的区别，从而在一个平台上可以提供各种各样的充值付费业务。

另外，本发明的系统不仅支持通过TCP/IP方式的本地充值，也支持通过七号信令方式的异地充值，不仅支持充值操作，而且支持付费操作，从而使本发明的使用更加灵活方便。

通过在电信网中提供统一的充值付费，用户只需要拨打统一的电话接入号码即可完成各种充值付费操作，因此给用户带来了很大便利。同时业务提供者也可以将多种业务整合在一起而不需要为每一个业务单独建立一个系统，从而减少了建设、运营和维护的操作，并因此给业务提供者带来了便利。

同时，用户可以利用一张卡就可以实现不同的充值付费操作，减少了用户购买卡的成本和业务提供者发行卡的成本。并且，通过统一的充值付费提供系统，业务提供者不需要为了不同的充值付费业务建立不同的充值充值付费平台，从而减少了运营成本，节约了资金。

除此之外，通过提供统一的充值付费业务，可以实现业务的本地化和资金的集中化。并且有利于充值付费业务的品牌知名度，从而促进充值付费业务的进一步推广。

附图说明

图1是根据现有技术的提供充值付费业务的系统组网图。

图2是根据本发明一个实施例的提供充值付费业务的系统组网图。

图3是根据本发明另一个实施例的提供充值付费业务的系统组网图。

图4是根据本发明的方法的总体流程图。

图5是和用户之间的交互处理流程的一个示例。

图6是和用户之间的交互处理流程的另一个示例。

图7是和用户之间的交互处理流程的又一个示例。

图8是和用户之间的交互处理流程的再一个示例。

图9是实现本发明的方法的消息结构示意图。

图10是由用户发起通过银行划款进行充值的消息交互图。

图11是由银行发起通过银行划款进行充值的消息交互图。

图12是用户通过拨打业务接入电话缴纳电话费的消息交互图。

具体实施方式

下面结合附图和具体实施例对本发明进行详细说明。

为了解决现有技术中各种充值付费业务使用独立的数据库、独立的业务逻辑和独立的前台管理界面从而造成各种充值付费业务各自为政、自成一体的情况，本发明对数据库结构、业务逻辑和前台管理界面进行了统一，并且修改了进行充值付费业务的中间传送消息的格式，使中间传送消息可以识别不同的业务类型、不同的节点等信息，从而实现本发明的实现统一充值付费的发明目的。

在图2所示的提供充值付费业务的系统的基础上，本发明进一步建立一个VC，用于将各种充值付费业务集中在该业务处理平台上，在VC上能进行以前在SCP上进行的处理，但和SCP不同，VC只提供充值付费业务，而不提供其他智能业务。和VC相对应，本发明进一步建立了用于对VC进行管理的VMP和专门用于接入充值付费业务请求的VMAP。这里VC通过VMP和VMAP相连接。

在现有技术中，SCP连接到FEP，并且通过FEP连接到账务平台和充值付费平台。而在如图2所示的本发明的一个实施例中，由本发明建立的VC连接到一个GFEP，并且通过GFEP连接到账务平台和充值付费平台。具体地说，VC连接到GFEP，GFEP再同时连接到账务平台和充值付费平台，而账务平台和充值付费平台之间没有直接的连接。这样本发明就可以通过提供统一的充值付费业务的VC来对所有的充值付费业务进行集中处理。

在本发明中，VC同时和SCP相连接，而SCP也和所有的智能网系统一样通过SMP连接到SMAP。除了GFEP和账务平台以及充值付费平台的连接采用DDN专线之外，上述所有的连接都是通过局域网。无论是DDN专线连接还是局域网连接，所使用的传输协议都是TCP/IP。图中局域网连接和DDN专线连接都采用实线表示。

除了本地网络之外，VC还通过七号信令的方式连接到七号信令网，并通过七号信令网连接到远端的SCP和SSP，这样VC不仅可以对本地用户提供充值付费业务，而且还可以对异地的用户提供充值付费业务。图中，七号信令连接采用虚线表示。

另外，VC还可以和SMP连接，这里采用点划线表示它们之间可能的连接。

上述GFEP的作用和现有技术中的FEP的作用相同，这里称为GFEP是为了和现有技术的FEP相区别，因为这里的GFEP仅仅处理充值付费业务，而不处理其他智能业务。当然本领域技术人员可以理解，GFEP也可以和FEP集成在同一个设备中，但是较佳地，GFEP还是在网络中单独设置。

同样，VMP可以和SMP集成在同一个设备中，VMAP和SMAP也可以集成在一起，但是较佳地，为了和其他智能业务的管理不相互影响，VMP和VMAP都在网络中单独设置。

在这一实施例中，VC是整个提供统一充值付费的系统的中心，它既是用户呼叫的接入平台，又是连接账务平台和充值付费平台的中间接口。账务平台和充值付费平台之间没有直接连接，所有的充值付费操作都是由VC平台发到账务平台或充值付费平台。

这里的充值付费平台可以是银行等第三方信息平台，也可以是智能网中的卡号平台。当然，本领域技术人员可以理解，如果充值付费平台是智能网中的卡号平台，而且VC业务与充值付费平台的卡号业务位于同一个智能网中，那么VC平台和充值付费平台的连接可以省略，充值付费平台所进行的任何操作都直接在智能网内部完成。

另外，本发明的系统组网也可以采用如图3所示的结构。在如图3所示的第二实施例中，GFEP不直接和账务平台以及充值付费平台连接，而是连接到一个支付接口FEP，并通过该支付接口FEP连接到账务平台和充值付费平台。在这种系统结构中，VC、账务平台和充值付费平台处于平等的地位，而支付接口FEP则是连接它们的中心。其中，VC负责接入、接收用户的操作信息，将该信息发送到支付接口FEP，并接收来自支付接口FEP的响应消息并向用户播放相应的语音，换句话说，VC是整个充值付费系统的用户接口。账务平台负责提供用户的账单数据，根据支付接口FEP转发的请求消息向支付接口FEP提供查询结果，或者在销账后向支付接口FEP发送销账操作的操作结果。充值付费平台负责进行付费操作，根据支付接口FEP转发过来的扣费请求，在相应账号中扣除所请求的费用，并向支付接口FEP返回扣费的操作结果。

在这一实施例中，支付接口FEP可以单独设置，也可以根据需要由账务平台来完成，也就是和账务平台集成在一起。并且，账务平台和充值付费平台可以具有直接连接，其连接可以采用DDN专线。

上面通过两个实施例说明了本发明的系统结构，可以看出，通过建立单独的VC，将原本在同一SCP或者不同SCP上实现的所有充值付费业务可以集中在一起，并且不和其他智能业务产生相互影响，这样为本发明的统一充值付费业务提供了硬件的基础，再结合下面将要详细说明的实现统一充值付费的方法，即可完整地达到本发明的目的。

图4示出了根据本发明的实现统一充值付费的流程图。如图4所示，本发明的方法流程至少包括如下处理过程。

在步骤401，首先建立一个用于集中处理充值付费业务的VC，由VC连接账务平台和充值付费平台，并将所有的充值付费业务的相关信息存储在一个统一格式的数据库中。

在步骤402，为所有的充值付费业务分配一个单独的接入电话号码，并且提供一个适用于所有充值付费业务的语音提示。

在步骤403，设置VC、账务平台和充值付费平台之间的消息格式，使其至少包括目的节点、源节点、消息类型和充值付费类型等信息。

上述的步骤401至403都是需要预先进行的，通过上述步骤即可处理每个具体的充值付费业务。在本发明中，具体的充值付费业务既可以由用户通过拨打VC的接入电话号码发起，也可以由充值付费平台来主动发起。

在步骤404，在具体的充值付费业务由用户通过拨打VC的接入电话号码发起的情况下，当VC接收到用户通过拨打VC的接入电话号码发起充值付费业务后，向用户播放统一的语音提示，要求用户输入相关信息，并根据用户信息生成充值付费业务请求消息，这里的业务请求消息至少包括目的节点、源节点、消息类型和充值付费类型等信息。然后通过VC、充值付费平台和账务平台之间的消息交互完成整个充值付费操作。在具体的充值付费业务由充值付费平台发起的情况下，充值付费平台生成包括目的节点、源节点、消息类型和充值付费类型信息的充值付费业务请求消息，然后通过VC、充值付费平台和账务平台之间的消息交互完成整个充值付费操作。

在上述步骤401，可以理解VC是通过GFEP连接到账务平台和充值付费平台，或者是通过GFEP和支付接口FEP连接到账务平台和充值付费平台。建立统一格式的数据库意味着对所有的充值付费业务的相关信息而言，所包含的具体信息是相同的。

在上述步骤402，由于建立了用于集中处理充值付费业务的VC，因此所有的用户无论需要使用哪一种充值付费业务，都可以拨打该VC的接入电话号码。而VC给所有的充值付费业务都提供了统一的电话语音提示，也就是提供了相同的前台管理界面，这样用户使用不同充值付费业务时听到的是相同的语音提示，而只需要选择不同的选择项即可，从而给用户带来了极大的便利。

图5示出了一个VC和用户之间的交互处理流程的示例。在接收到用户拨打的目的号码为该接入电话号码的电话呼叫请求后，首先在步骤501至503由VC向用户播放欢迎词，然后提示用户选择语音类别，例如中文还是英文，然后提示用户进行菜单1选择，也就是充值请按1、付费请按2。在用户进行了菜单1选择之后，VC在步骤504判断用户的选择。如果用户按1，也就是选择了充值，则进入步骤505及其后续步骤；如果用户按2，也就是选择了付费，则进入步骤511及其后续步骤。

在用户选择了充值之后，首先在步骤505提示用户进行菜单2选择，也就是选择被充值业务类型，例如是给用户的200卡充值。需要说明的是，这里无论是选择哪一种被充值业务类型，后续的语音提示以及VC的后续处理都是相同的。然后在步骤506提示用户输入被充值账号和密码。在用户输入账号和密码之后，在步骤507提示用户进行菜单4选择，也就是选择充值卡充值请按1、查询余额请按2、银行划款请按3。在用户进行了菜单4选择之后，VC在步骤508判断用户的选择。如果用户选择了充值卡充值，则进一步在步骤509提示用户输入充值卡卡号和密码。如果用户选择了银行划款，则进一步在步骤510提示用户输入银行账号和密码。而如果用户选择了查询余额，则VC直接进行处理，不需要在处理之前再提示用户，只需要在处理之后告知用户即可。

如果在步骤504判断用户选择的是付费，首先在步骤511提示用户进行菜单3选择，也就是选择付费业务类型，例如是支付电话费等。同样，无论用户选择的是哪一种付费业务类型，后续的语音提示以及VC的后续处理都是相同的。其后在步骤512提示用户输入被付费账号、密码。在对用户输入的被付费账号和密码进行本地鉴权或者账务平台鉴权后，在步骤513提示用户进行菜单5选择，也就是选择充值卡付费请按1、账单查询请按2、银行划款请按3。VC在步骤514判断用户的选择。如果用户选择了充值卡付费，则在步骤515进一步提示用户输入充值卡卡号和密码。如果用户选择了银行划款，则在步骤516进一步提示用户输入银行账号和密码。而如果用户选择了账单查询，同样VC直接进行处理，不需要在处理之前再提示用户，只需要在处理之后告知用户即可。

在上述例子中，无论是充值业务还是付费业务，无论是给200卡充值还是给300卡充值，无论是通过充值卡充值还是通过银行划款充值，无论是支付电话费还是支付水电煤气费，无论是通过充值卡付费还是通过银行划款付费，都可以使用同一个处理流程，从而大大简化了对充值付费业务的处理。当然可以理解，对于不同的实际应用可以对上述处理流程进行适当变更，例如可以在用户选择充值后如图6所示按照菜单2的不同选择播放不同的提示音，然后进入菜单4进行同样的选择。或者如图7所示，要求用户先输入充值卡卡号和密码，然后进行菜单2的选择。又例如，在用户选择付费后如图8所示要求用户选择按电话号码付费还是按照分账序号付费，并且如果用户选择了按照分账序号付费，进一步可以根据用户输入的电话号码向用户提示分账序号，最后统一进入菜单6的选择。菜单6的选择可以包括付费、止付、查询、付费卡余额转移等等。

上述所有的菜单均可进行灵活的配置，包括实现菜单的有无、调整菜单提示功能以及屏蔽部分菜单功能。例如只开通付费的账单付费、账单查询两个功能，则可以按照如下配置：菜单1处设置默认功能为“付费”，这样用户就听不到菜单1的提示音了。而菜单3可以保留付费和查询功能，其它可以通过配置而屏蔽。这样提示给用户的语音为“账单付费请按1，账单查询请按2”。同时，播放欢迎词和提示用户选择语言种类等步骤也可以取消。

总之，业务提供商可以根据不同的业务需求和使用环境进行灵活的配置，这里不再一一详细说明。

下面再通过一个具体的充值过程说明本发明的VC和用户的交互过程。这里假定用户的主叫号码为01087654321，VC的统一电话接入号码为225，充值卡卡号为123412345678，被充值卡卡号为888812345678，充值卡和被充值卡的密码都是1234。

当用户希望进行充值时，首先拨打VC的统一电话接入号码225，VC在检测到用户的电话呼叫请求后，首先提示用户输入充值卡卡号，在用户输入123412345678后，系统提示用户输入充值卡密码，用户输入1234。然后系统提示用户“充值卡充值请按1，查询余额请按2，银行划款请按3”。此时用户输入1，系统接着提示用户输入被充值卡卡号，在用户输入888812345678后，提示用户输入被充值卡密码，此时用户输入1234。在接收到所有这些信息后，系统进行充值处理，例如增加余额、延长有效期和保留期等，并记录相应日志。至此用户即可实现其对被充值卡的充值。

除了统一了前台维护管理界面之外，也就是统一了VC和用户的交互过程，为了实现统一的充值付费业务处理，还必须在VC和充值付费平台、账务平台之间的消息交互中识别不同的消息类型、识别充值付费类型、识别充值付费业务的目的节点和源节点，为此新定义了一种消息格式来达到上述识别目的。

根据本发明新定义的消息格式如图9所示，一个消息包括消息头和消息体，而消息头由8个字段组成，字段1表示消息长度，字段2表示加密算法编号，字段3表示消息流水号，字段4表示消息类别，字段5表示源节点类别，字段6表示目的节点类别，字段7表示消息发送时间，字段8表示充值付费类型。消息体由字段9等其他字段组成，这些字段中至少包括表示响应码的字段。在消息头中，消息类别、源节点类别、目的节点类别和充值付费类型都是为了实现统一充值付费所必不可少的。

其中，字段4所表示的主要消息类别可以定义为：账单申请包，0007；账单资料包，0008；扣款申请包，0009；扣款确认包，0010；账务发起付费申请包，0011；账务发起付费确认包，0012；销账申请包，0013；销账确认包，0014；划款申请包，0023；划款确认包，0024；查询余额申请包，0035；查询余额确认包，0036；充值申请包，0037；充值确认包，0038；等等。

字段5和字段6所表示的主要源节点和目的节点可以定义为：中国银行，0100；中国工商银行，0200；中国建设银行，0600；200卡，1001；300卡，1003；IC卡，1004；中国电信，2100；中国联通，2200；自来水公司，2300；电力公司，2400；等等。

字段8表示充值付费类别，充值可以定义为3000，而主要付费类别可以定义为：国内市话费，0001；国内长途费，0002；移动通信费，0004；上网费，0006；水费，1001；电费，1002；有线电视收视费，1004；等等。

下面结合几个具体示例介绍利用上述统一充值付费系统进行统一充值付费的方法。

在第一个示例中，由用户通过拨打VC的统一电话接入号码发起充值流程，并且通过银行划款来对被充值卡进行充值。图10示出了这一示例的消息交互流程。

首先，通过VC和用户的前述交互流程，VC得到进行充值业务所必需的一些信息，例如用户希望通过中国银行的账号给自己的200卡号进行充值。然后VC通过和账务平台以及充值付费平台的消息交互共同完成充值操作。

具体地说，VC首先向账务平台，也就是200卡平台，发送查询余额申请包。在该消息包的消息头中，包含了目的节点、源节点、消息类型和充值付费类型等信息，其中目的节点是200卡的编号1001，源节点是中国银行的编号0100，消息类型是查询余额申请包的编号0035，而充值付费类型则是表示充值的3000。也就是说，字段4为0035，字段5为0100，字段6为1001，字段8为3000。在该消息包的消息体中包含了200卡的卡号和密码以及中国银行的账号和密码等信息。

账务平台在接收该消息包之后，根据该消息头中的信息确定该消息的类型、目的节点、源节点和充值付费类型，然后对消息体中的用户输入的200卡的卡号进行判断，如果被充值账号能够被充值，则向VC返回一个查询余额确认包，其中消息头中的消息类型修改为查询余额确认包的编号0036，而字段5、字段6和字段8则和查询余额申请包相同，同时将消息体中的响应码设置为成功。如果被充值账号不能充值，则将消息体中的响应码设置为不成功，结束充值过程。

VC在接收到查询余额确认消息后，向充值付费平台，也就是银行平台，发送一个扣款申请包(字段4＝0009，字段5＝0100，字段6＝1001，字段8＝3000)，充值付费平台在相应的账号中进行扣款，在扣款后向VC返回扣款确认包(字段4＝0010，字段5＝0100，字段6＝1001，字段8＝3000)。然后VC向账务平台发送充值申请包(字段4＝0037，字段5＝0100，字段6＝1001，字段8＝3000)，账务平台将资金注入到被充值账号中后给VC平台返回充值确认包(字段4＝0038，字段5＝0100，字段6＝1001，字段8＝3000)。至此用户完成了拨打电话通过银行划款实现充值的业务。

当然可以理解，如果200卡业务也同样由VC提供，那么VC和账务平台之间的消息交互过程实际上是在VC内部进行处理，也就是说不需要发送相应的消息，而是由VC直接进行处理。

在第二个示例中，由作为充值付费平台的银行主动发起充值流程，并且通过银行划款来对被充值卡进行充值。图11示出了这一示例的消息交互流程。

在实际情况中，用户也可以不通过拨打电话来进行充值，而是预先在银行方办理银行定期划款的手续，这样到一个所约定的时间，例如每月第一天，银行会主动发起充值过程，从而给用户带来更大的方便。

这里以用户通过中国工商银行的账户定期向IC卡充值为例，在这种情况下，当到达约定的时间后，银行根据用户签约该业务时提供的基本信息，例如被充值账号和密码，银行账号和密码等，生成一个划款申请包，其消息头中的消息类型为表示划款申请包的0023，源节点为表示中国工商银行的0200，目的节点为表示IC卡业务的1004，而充值付费类型为表示充值的3000，消息体中包括被充值账号和密码等信息。充值付费平台在生成该消息包后，将该消息包发送给VC，VC接收到该消息包后解析消息头中的信息，并据此生成一个充值申请包(字段4＝0037，字段5＝0200，字段6＝1004，字段8＝3000)，然后将其发送到账务平台。账务平台在对其相应的账号上注入资金后，向VC返回充值确认包(字段4＝0038，字段5＝0200，字段6＝1004，字段8＝3000)，VC平台然后向充值付费平台返回划款确认包(字段4＝0024，字段5＝0200，字段6＝1004，字段8＝3000)。至此即由银行主动发起完成了一次充值操作。

在第三个示例中，由用户通过拨打VC的统一接入电话号码对电话号码进行付费。图12示出了这一示例的消息交互流程。

首先，通过VC和用户的前述交互流程，VC得到进行付费所必需的一些信息，例如用户的付费账号和密码、所要进行付费的电话号码和付费密码等。然后VC通过和账务平台以及充值付费平台的消息交互共同完成充值操作。

具体地说，VC首先向账务平台发送账单申请包。在该消息包的消息头中，包含了目的节点、源节点、消息类型和充值付费类型等信息。这里假定所要进行付费的电话业务是国内市话费，提供商是中国电信，而充值付费平台是中国建设银行，那么该消息头中的字段4为0007，字段5为0600，字段6为2100，字段8为0001。在该消息包的消息体中包含了付费账号和密码以及中国建设银行的账号和密码等信息。

账务平台在接收该消息包之后，根据该消息头中的信息确定该消息的类型、目的节点、源节点和充值付费类型，然后对消息体中的用户输入的被付费账号进行判断，如果被付费账号尚未被付费，则向VC返回一个账单资料包，其中消息头中的消息类型修改为账单资料包的编号0008，而字段5、字段6和字段8则和账单申请包相同。

VC在接收到账单资料信息后，向充值付费平台，也就是银行平台，发送一个扣款申请包(字段4＝0009，字段5＝0600，字段6＝2100，字段8＝0001)，充值付费平台在相应的账号中进行扣款，在扣款后向VC返回扣款确认包(字段4＝0010，字段5＝0600，字段6＝2100，字段8＝0001)。然后VC向账务平台发送销账申请包(字段4＝0013，字段5＝0600，字段6＝2100，字段8＝0001)，账务平台进行销账后，给VC平台返回销账确认包(字段4＝0014，字段5＝0600，字段6＝2100，字段8＝0001)。至此用户完成了拨打电话通过银行划款实现充值的业务。

和第三个实例类似，在第四个示例中，如果用户希望通过例如200卡的付费卡来进行付费而不是通过银行划款来进行付费，那么所有的源节点编号，也就是字段5修改为1001即可。当然，如果200卡号业务由VC提供，那么VC和账务平台之间的消息交互过程实际上是在VC内部进行处理，也就是说不需要发送相应的消息，而是由VC直接进行处理。

至于用户是希望通过付费卡来付费还是通过银行划款来付费，用户可以在拨打VC的统一接入电话号码后听到的语音提示中进行选择，然后相应输入付费卡号和密码或者银行账号和密码即可，因此，本发明通过提供统一的充值付费业务，给用户提供了非常大的方便。

在本发明中，对于充值来讲支持本地充值和异地充值，如果是本地充值，也就是在账务平台和充值付费平台之间的物理距离比较近时通过TCP/IP方式进行充值，如果是异地充值，也就是在账务平台和充值付费平台之间的物理距离比较远时通过七号信令网的方式进行充值。无论是通过TCP/IP方式还是通过七号信令网的方式，对于用户来说都是透明的。

除了基本的充值付费操作之外，根据本发明的实现统一充值付费的系统还可以完成账单查询、账单止付、密码修改、设置交费周期、付费卡余额转移、对账等操作，由于这些操作对于现有的单独充值付费的操作流程基本相同，这里不再一一详细说明。

因此可以理解，具体实施例只是对本发明的进一步描述，并不能用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、替换和改进等，均应包含在本发明的保护范围之内。

Claims (18)

1.一种在电信网中提供充值付费业务的系统，包括业务控制点SCP、账务平台和充值付费平台，其特征是，进一步包括一个用于提供统一充值付费业务的统一充值付费中心VC、用于对VC进行管理的充值付费业务管理点VMP、用于接入充值付费业务请求的充值付费业务管理接入点VMAP以及用于转发充值付费业务消息的通用通讯前置机GFEP，其中VC通过VMP连接到VMAP，并且通过GFEP连接到账务平台和充值付费平台，同时VC和SCP相连接。

2.根据权利要求1所述的在电信网中提供充值付费业务的系统，其特征是，所述VC通过GFEP连接到账务平台和充值付费平台是VC、账务平台和充值付费平台同时连接到GFEP。

3.根据权利要求1所述的在电信网中提供充值付费业务的系统，其特征是，进一步包括一个支付接口FEP，所述VC通过GFEP连接到账务平台和充值付费平台是VC连接到GFEP，GFEP、账务平台和充值付费平台同时连接到支付接口FEP。

4.根据权利要求3所述的在电信网中提供充值付费业务的系统，其特征是，所述支付接口FEP和账务平台集成在同一个物理设备中。

5.根据权利要求1所述的在电信网中提供充值付费业务的系统，其特征是，所述系统进一步包括处理除充值付费业务之外的智能业务的业务管理点SMP、业务管理接入点SMAP和通讯前置机FEP，所述VMP、VMAP以及GFEP分别和SMP、SMAP以及FEP集成在同一个物理设备中。

6.根据权利要求1所述的在电信网中提供充值付费业务的系统，其特征是，所述VC和充值付费平台集成在同一个物理设备中。

7.根据权利要求1所述的在电信网中提供充值付费业务的系统，其特征是，GFEP和账务平台以及充值付费平台之间的连接采用数字数据网络DDN专线，VC和GFEP、SCP、VMP之间以及VMP和VMAP之间的连接采用局域网。

8.根据权利要求7所述的在电信网中提供充值付费业务的系统，其特征是，所述连接采用TCP/IP协议。

9.根据权利要求1所述的在电信网中提供充值付费业务的系统，其特征是，VC进一步通过七号信令网连接到异地SCP，所述连接采用七号信令连接方式。

10.一种在电信网中提供充值付费业务的方法，包括：

a.建立一个用于集中处理充值付费业务的统一充值付费中心VC，并将所有充值付费业务信息存储在一个统一格式的数据库中；

b.为VC分配一个单独的接入电话号码，并且提供一个和用户之间的适用于所有充值付费业务的交互处理流程；

c.设置VC、账务平台和充值付费平台之间的消息格式包括目的节点、源节点、消息类型和充值付费类型；

d.当VC接收到用户通过拨打VC的接入电话号码发起充值付费业务后，播放语音提示要求用户提供充值付费业务所需信息，并根据用户提供的信息生成包括目的节点、源节点、消息类型和充值付费类型的充值付费业务请求消息，然后通过VC、充值付费平台和账务平台之间的消息交互完成充值付费操作；

当充值付费业务由充值付费平台发起时，充值付费平台生成包括目的节点、源节点、消息类型和充值付费类型信息的充值付费业务请求消息，然后通过VC、充值付费平台和账务平台之间的消息交互完成充值付费操作。

11.根据权利要求10所述的在电信网中提供充值付费业务的方法，其特征是，步骤b中VC和用户之间的交互处理流程包括：

提示用户选择充值业务还是付费业务；

如果用户选择充值业务，提示用户选择被充值业务类型，然后提示用户输入被充值账号和密码，然后提示用户选择充值卡充值还是银行划款充值，并相应地提示用户输入充值卡卡号和密码或者输入银行账号和密码；

如果用户选择付费业务，提示用户选择被付费业务类型，然后提示用户输入被付费账号和密码，然后提示用户选择充值卡付费还是银行划款付费，并相应地提示用户输入充值卡卡号和密码或者输入银行账号和密码。

12.根据权利要求11所述的在电信网中提供充值付费业务的方法，其特征是，在用户输入被充值账号或者被付费账号之后进一步包括提示用户选择是否进行余额查询。

13.根据权利要求10所述的在电信网中提供充值付费业务的方法，其特征是，步骤d中当VC接收到用户通过拨打VC的接入电话号码发起充值业务后，所述通过VC、充值付费平台和账务平台之间的消息交互完成充值操作包括：

VC向账务平台发送一个查询余额申请消息包，账务平台进行余额查询操作，然后向VC返回带有查询的余额值的查询余额确认消息包；

VC向充值付费平台发送扣款申请消息包，充值付费平台在进行扣款操作之后向VC返回扣款确认消息包；

VC向账务平台发送充值申请消息包，账务平台进行充值操作，然后向VC返回充值确认消息包。

14.根据权利要求10所述的在电信网中提供充值付费业务的方法，其特征是，步骤d中当充值业务由充值付费平台发起时，所述通过VC、充值付费平台和账务平台之间的消息交互完成充值操作包括：

充值付费平台向VC发送一个划款申请消息包，VC在接收到该消息包后，向账务平台发送一个充值申请消息包；

账务平台进行充值操作，然后向VC返回一个充值确认消息包，VC在接收到该消息包后，向充值付费平台返回一个划款确认消息包。

15.根据权利要求10所述的在电信网中提供充值付费业务的方法，其特征是，步骤d中当VC接收到用户通过拨打VC的接入电话号码发起付费业务后，所述通过VC、充值付费平台和账务平台之间的消息交互完成付费操作包括：

VC向账务平台发送账单申请消息包，账务平台在确定该被付费账号可付费的情况下，向VC返回账单资料消息包；

VC向充值付费平台发送扣款申请消息包，充值付费平台在进行扣款操作后向VC返回扣款确认消息包；

VC向账务平台发送销账申请消息包，账务平台进行销账操作，然后向VC返回销账确认消息包。

16.根据权利要求15所述的在电信网中提供充值付费业务的方法，其特征是，所述充值付费平台是银行平台或者付费卡号平台。

17.根据权利要求10所述的在电信网中提供充值付费业务的方法，其特征是，在所述充值付费操作是充值操作时，所述VC、充值付费平台和账务平台之间的消息交互采用TCP/IP消息。

18.根据权利要求10所述的在电信网中提供充值付费业务的方法，其特征是，在所述充值付费操作是充值操作时，所述VC、充值付费平台和账务平台之间的消息交互采用七号信令消息。

Images