专利名称：利用多种支付模式的网络通信服务的制作方法
技术领域：
本发明涉及一种通信系统，更具体的是一种远程通信系统，其中用于网络通信服务的支付可以由多个支付模式中的任何模式实现。
2.
背景技术：
远程通信服务的客户大致可以分为两类。一类是预付用户，这类用户为其随后要使用的服务事先付款。另一类是后付用户，其中账户持有人(订户)会收到一张发票，详细列明所使用服务的费用，账户持有人将支付所欠的全部应付款。在传统的计费系统中，如果订户希望改变他们的支付模式，从预付改为后付(或反之亦然)，就必须执行一个复杂的工作流程，中止预付系统中对该用户的服务，并在后付系统中重新提供或开启这些同样的服务。即使是可同时用于预付和后付订户的单一计费/ 客户维护系统，订户仍然必须被区分为预付的或后付的。希望会有一种用于远程通信服务的订户系统。更进一步希望有一种订户系统，订户可自由选择以预付和后付模式中的其中一种或二种来付款，而无需被分类和/或限制于一种模式或另一种模式。
发明内容
本发明提供了一种方法，其包括(i)接收与网络通信服务有关的事件通知；(ii) 查询数据库，以响应该通知，获得该服务的支付模式，支付模式可从(a)预支付型及(b)后支付型模式中选择；(iii)依照该支付模式，判定用来支付服务的订户余额是否符合余额准则，以及(iv)根据用来支付服务的订户余额是否符合余额准则，向设备发起通信，影响服务的提供。本发明还提供了一种使用该方法的系统，以及一种存储介质，该存储介质包含用于控制处理器执行该方法的指令。
图1是本发明的混合型订户系统的实施例的方框图。图2A是本发明的混合型订户系统的另一实施例的方框图。图2B是图2A方框图的后续部分。图3是系统的方框图，该系统实现了以多种支付模式中的任意模式完成支付的网络通信服务。本发明的详细说明下列是此处所用的缩写词“API”代表应用程序接口 ；“CSR”代表客户服务代表；
“ CSP ”代表通信服务提供商；“⑶I”代表图形用户接口 ；“MVN0”代表移动虚拟网络运营商；“NRC”代表一次性费用；“RC”代表经常性收费；以及“URE”代表统一计费引擎。下面是对本文所用术语的概括描述。“账户”是代表运营商的客户实体。账户可以是计费的(例如，有应收款的责任方) 或非计费的。账户包含订户的详细资料，以及相关的订户和报价。账户具有一个或多个子账户(以层级组织)，以及一个或多个的订户和报价。账户可具有实时余额和累加器。“累加器”是一个用于计算或量度包括呼叫、充值、数据传输及SMS的业务活动的寄存器。累加器实质上是循环的，其周期性地被重置归零。重置周期可按所支持的周期，如每天、每周、每月、每季、每年、账单周期或无周期地进行设置。系统初始的活动，如一些经常性收费，是不累加的。单个累加器被用于计算一种类型的收费活动(例如，语音呼叫时长或 SMS信息数量)。累加器可计算数量(例如，呼叫次数)或总量(例如，充值总额)。累加器常常用于激活实时促销优惠。“奖励”是一种将货币金额或非货币单位量应用至余额的规则。奖励包括购物券、 充值、循环充值以及积分计划。在奖励被兑现后，通过对其的使用，奖励能够被实时消耗。“余额”是一个类似单位类型的资金的集合。余额可以是(1)(实时授权的)流动余额或O)(应收款)财务余额。余额是货币或非货币(基于单位)数量的表示。余额可以是后付的或预付的。后付余额能标识单位量、货币信用，开销限额或应付总额；所有这些都基于用户消耗活动而增加。当用户消费服务时，实时预付余额能够表示预留的、可用的现有资金或单位。“余额顺序”是在与订户及账户相关的余额中收取使用收费、经常性收费和非经常性收费的顺序。“计费和财务引擎”计费并生成发票和/或清单，该发票和/或清单用于使用收费、 经常性收费、非经常性收费及任何其他收费，适用于预付余额、后付余额或两者。“积分”是基于特定订户级别或达到一定级别的使用量，以折扣或奖励方式奖赏用户的促销手段。“收费”是根据对经常性收费项目、非经常性收费项目及使用量计算出来的金额， 来修改余额的过程。“信用限额”是由运营商确定的、用于限定后付余额可用量的循环性余额限额。在周期性基础上，余额可被重设为其限额。如果在一个周期内，余额达到其最小值(通常为零)，则余额不能被用于授权事件，直至在下一个周期开始时其被重设为限额值。示范性的周期包括但不限于每日、每周、每月、每季度、每年、账单周期及空周期或无周期。“客户维护接口”是一个图形用户接口，用于创建和管理账户、订户及层级。客户维护接口管理客户(也就是账户和订户)的活动周期，即从客户的维护和定制，直到服务实施、计费和支付。该接口可对一个或多个用户进行访问。该接口能够接收并认可来自一个或多个订户的一个或多个的报价，也可接收指令，该指令是关于对一个或多个报价的支付模式是否为预付、后付或它们两者。该接口也能够显示一个或多个用户使用量、经常性和非经常性收费，这些收费是对应于预付或后付支付方式的一个或多个报价。“发票”是周期性产生的或应要求详细列明的收费、税费、和相对账户未付余额、相关折扣或信用、以及调整的清单。发票也可能包括发票号、发票日期、或总数量等。发票可以生成并格式化，用于派送给客户。“报价”是向账户或订户发送的用于服务消费的最小销售体。报价可以是可重复使用模块的集合，其将它们的业务使用类型、服务、价格、合资格度，以及与其他报价的依赖度、相关资源、服务支付模式以及消费信用模型化。报价的普通类型有初级报价、补充报价和账户报价。初级报价可由一个或多个订户购买。每个订户仅有一个初级报价。初级报价是强制性的报价。优选地，初级报价包含基础报价，该基础报价由CSP在市场上设立。补充报价也可以由一个或多个订户购买。订户可以具有一个或多个补充报价。补充报价不是强制性的。补充报价是用于提供增值服务。账户报价可以被一些账户购买或与这些账户相关联(这些账户不是订户)。账户报价也是可选的。这些报价是用于向账户，例如家庭账户或公司账户，提供优惠。“支付”是将一笔钱从一方(如个人或公司)转帐至另一方。付款通常在提供商品、服务或它们两者时，通过交换而发生。实例是将一笔钱从订户转账至通信服务提供商， 以交换其所提供的服务和商品。“支付模式”指的是订户向通信服务提供商付款的方式。支付可以以预付模式或后付模式完成。“后付余额”是单位金额、货币信用、开销限额或应付总金额，所有这些都基于用户消费活动而增加。“后付型支付模式”指的是在使用后才支付的服务，即先使用，后付款。“预付余额”表示当使用者消费服务时，可提取的预留资金或单位数量。“预付型支付模式”指的是事先支付的服务，也就是，先付款，后使用。“产品目录”是系统提供的数据存储，用于对市场报价进行理顺和集中管理。产品目录支持在其配置内对多个虚拟运营商的产品限定，并为市场细分和产品定价提供各种范例。产品目录是设计和创造所有CSP报价的单一接口。产品目录支持并允许经营范围内对订户的所有支付类型(即预付、后付和预后付混合型)的混合。术语“实时”描述在计费和/或收费过程中发生的活动或交易，它与需等至周期结束(出账单时间)才知道的情形完全相反。在绝大多数情况下，“实时”计费和/或收费过程发生在使用事件的实际周期内，而该使用事件是需计费和/或收费的。“经常性/非经常性收费服务器”是一个产生经常性和非经常性收费，并从订户余额中扣除这些收费的实体。该经常性和非经常性收费服务器可以从预付余额、后付余额或两者中扣除经常性和非经常性收费，这些扣费与订户已接受的报价相对应。“个人维护接口 ”以客户服务代表的形式，创建并管理账户、订户及层级。该接口管理客户(即账户和订户)的活动周期，即从客户的维护和定制，直到服务实施、计费和支付。 该接口通过电话或计算机，可对一个或多个用户进行访问。该接口能够接收并认可来自一个或多个订户的一个或多个的报价，并接收指令，该指令是关于对一个或多个报价的支付模式是否为预付、后付或它们两者。
“消费限额”是显示在余额中的用户限定(账户限定)的循环限额，并实现主动控制余额上的消费。消费限额用于限制后付余额上的可使用金额。消费限额周期性地重设并不受付款的影响。“清单”是周期性产生或应要求详细列明使用者费用、税费和相对账户剩余的余额，相关的折扣或信用的列表。清单包括清单编号，清单日期，清单金额。如有需要，清单可生成并统一格式，派送至客户。清单可以以任何已知的方式传送，例如，电子形式的，通过传真、通过硬件拷贝、或通过因特网或万维网在线查看。“订户”指的是(a)使用产品或服务的个人(b)用于产品或服务的特定服务投递点，例如电话线、在线服务的登陆账户、专用线网络中的端点。“统一计费引擎”能使运营商对实时或非实时的所有电信服务收费，完成对预付、 后付及预后付混合型客户的实时余额管理。统一计费引擎可从预付余额、后付余额或它们两者中扣除使用收费，这种扣费与订户已接受的报价相对应。统一计费引擎具有灵活的收费模型，该收费模型可适用于发展客户模型，能够限制所有客户责任，以减少财务风险。其可以通过交叉产品折扣，进行实时和延迟促销，产生创新的市场报价，用以渗透新的客户群并减少动荡。其支持多种计费形式，以满足来自固定电话通信、移动电话通信、光缆通信和因特网宽带行业的大范围的要求。在本发明中，混合型订户可以同时使用预付型支付模式、后付型支付模式或两者。 预付型支付模式和后付型支付模式都可以用于支付同一服务，且订户随时可以在支付模式之间进行转换，无需在一个或多个计费系统中建立新账户。本发明提供了许多优势。优势之一是向康维公司、我们客户和/或终端用户提供了本发明的价值的概述。操作方便而有效。复杂的预付/后付转换工作流程，及随之附带的失败风险及操作花费将被消除。另一个优势是实时客户管理和灵活性。订户不需要在一个单一点及时从一种支付模式转换至另一种支付模式。在其他支付模式被激活之后，订户可以继续使用现有的支付模式。而另一个优势是一致的客户体验。账户持有者仅需要使用一组账户/登陆详情接入单一个人维护系统，该系统就可提供流畅的客户体验。还有另一个优势是360度客户观察。CSR可以查看用于客户的预付和后付活动的单一账户。因此，客户维护活动将会更快速和更加精确。本发明的系统的一个实施方式大致参照图1中标号10所示。方框图中的部件被指定为对混合型订户的报价[20]；对混合型订户的客户维护[30]；对混合型订户的收费 [40]；以及对混合型订户开出发票/清单[50]。[20]对混合型订户的报价通过产品目录接口，单一组市场报价可以被定义为以实质相同的方式操作，而不需考虑支付模式。所定义报价可以被一个或多个从属于CSP的订户所预订。如果用户预订一个或多个具有不同支付模式的报价，则该用户将被归为混合型订户一类，而不是预付型订户(用预付型支付模式支付所有预订报价的订户)或后付型订户 (用后付型支付模式支付所有预订报价的订户)。[30]混合型订户的客户维护通过客户维护接口，CSR可以查看混合型订户的报价及其相应的支付模式、预付和后付余额的当前状态、和交易历史，并使用单一用户接口执行操作。在客户维护接口之内，混合型订户可以选择个人维护接口或客户维护接口。通过个人维护接口，混合型订户可以查看用户报价及其相应的支付模式、预付和后付的当前状态、及使用单一用户接口的近期交易历史。混合型订户可以通过客户维护接口(通过呼叫CSR)或通过个人维护接口，改变相应于一个或多个预订报价的支付模式，而无需改变为不同的市场报价。W0]对混合型订户的收费对混合型订户的使用收费可以以实时模式或以离线模式，通过统一计费引擎，从一个或多个预付和/或后付余额中扣费。对混合型订户来说，预付和后付余额可用于一个或多个预订报价。基于后付型报价，混合型订户可以在预付型报价上得到优惠，反之亦然。通过经常性收费(RC)服务器和非经常性收费(NRC)服务器，从混合型订户的预付和后付余额中扣除相对应预订报价的经常性收费和非经常性收费。对混合型用户的使用时间收费、调整、信用、借款和使用时间优惠，可通过计费和财务引擎应用至后付余额中。使用时间优惠也可以改为应用至混合型订户的预付余额中。[50]对混合型用户发出发票/清单混合型用户可以接收单一文件(发票/清单)，该文件详细列明了通过计费和财务引擎以预付和后付两种方式支付的所有交易。因而，其可以提供一张汇总账单，其中详细列明了所有的远程通信活动，不论业务种类(例如移动电话、固话、因特网和电缆通信)以及支付模式(预付或后付)。本发明的一个实施方式大致参照如图2A和2B中标记90所示。方框图中的部件被指定为对混合型订户的报价[100]；对混合型订户的客户维护[200]；对混合型订户的收费[300]；以及对混合型用户发出发票/清单W00]。[100]对混合型订户的报价对混合型订户的报价图示了具有不同支付模式的市场报价，这些不同支付模式可以由产品目录接口定义。所定义的报价可用于一个或多个订户的订购。混合型订户在不同的支付模式下可以有一个或多个报价。对混合型订户的报价按照[110]报价的形式，并按照下列支付模式[121] “预付” 支付模式及相应的余额，[122] “后付”支付模式及相应的余额，[123] “混合”支付模式及相应的余额，以及[124] “任一”支付模式及相应的余额。[110]报价报价是可销售的实体，其可用于混合型用户的订购。如语音呼叫、短信息服务 (SMS)、多媒体信息服务(MMS)、数据、语音邮件、呼叫转移、DSL(数字订户专线)、电缆及它们的组合等服务，可以通过报价送至混合型订户。报价也可包括一个或多个余额。余额则用于支付相应的、混合型订户所订购的服务。每个报价具有一种支付模式，该支付模式决定了混合型订户如何为由报价传达的服务付款。下列支付模式都被报价所支持。报价的支付模式决定了余额的类型，即包含在报价中的余额是预付的抑或是后付的。[121] “预付”支付模式及相应的余额对报价的支付模式在产品目录中可以被设置为“预付”。如果对报价的支付模式被设置为“预付”，则混合型订户应事先计划为包括在相应报价中的服务付款，也就是先付款后使用。包括在相应报价中的所有余额被自动归类为预付余额。预付余额代表预留持有的资金或单位数量，其可用于混合型订户对包含在相应报价中的服务的消费。[122] “后付”支付模式及相应的余额对报价的支付模式在产品目录中可以被设置为“后付”。如果对报价的支付模式被设置为“后付”，则混合型订户应在使用后为包括在相应报价中的服务付款，也就是先使用后付款。包括在相应报价中的所有余额被自动归类为后付余额。后付余额代表单位金额、 货币信用、开销限额、或应付总额，所有这些都基于用户消费活动而增加。[123] “混合”支付模式及其相应的余额对报价的支付模式在产品目录中可以被设置为“混合”。如果对报价的支付模式被设置为“混合”，则混合型订户可以预付支付模式为一些服务付款，而以后付支付模式为另一些服务付款。CSP/MVN0的市场用户可以做出选择，个别指定包含在报价中的每个余额的余额类型，即为预付型或后付型。这使得可向混合型订户以预付模式收取一些服务的费用，同时又以后付模式收取另外一些服务的费用。[124] “任一”支付模式及相应的余额对报价的支付模式在产品目录中可以被设置为“任一”。如果对报价的支付模式被设置为“任一”，则混合型订户可以做出选择，决定是否以预付支付模式或后付支付模式， 为包含在报价中的所有服务付款。当产品目录中的支付模式是“任一”时，混合支付订户不能选择以预付模式为包含在报价中的一些服务付款，而同时又以后付模式为另一些服务付
mKo如果混合型订户决定以预付型支付模式为包含在报价中的所有服务付款，则包括在相应预订报价中的所有余额的余额类型将被设为预付。如果混合型订户决定以后付型支付模式为包含在报价中的所有服务付款，则包括在相应预订报价中的所有余额的余额类型将被设为后付。[200]对混合型用户的客户维护[200]对混合型用户的客户维护图示了具有多个报价的混合型订户，每个报价具有不同的支付模式。在一段时间后，混合型订户可改变所预订报价的其中之一的支付模式， 而无需先中止现有的、已预订的报价，再重新建立不同支付模式下的同一报价。通过客户维护接口(经由CSR)和个人维护接口(直接地)，混合型订户能够获得每个已预订报价及相应的支付模式的所有详情，该支付模式可用于任何时间点，混合型订户还能够查看最近的交易历史，并获得预付和后付余额的当前状态。[210]在改变已预订报价的其中之一的支付模式之前的混合型订户混合型订户通过客户维护接口(经由CSR)或个人服务接口预订多个报价。如图 2A所示，混合型用户预订了三个报价，每个报价具有不同的支付模式。报价A为预付型支付模式，报价B为后付型支付模式，以及报价C为混合型支付模式。包含在已预订报价中的余额，可用于混合型订户对包含在已预订报价中的服务的收费和/或消费。在图2B中，混合型订户接收来自报价A和C的预付余额，以及来自报价
10B和C的后付余额。[220]混合型订户改变已预订报价的其中之一的支付模式混合型订户可以随时改变一个或多个已预订报价的支付模式，可从预付改为后付 (反之亦然)，而无需先中止现有报价，再重新建立不同支付模式下的新报价。当报价的支付模式改变时，包含在相应报价中的余额的余额类型也自动进行相应的改变。在图2B中，混合型订户将报价A的支付模式(其最初为预付方式)改变为后付方式。包含在报价A中的所有余额的余额类型都自动从预付型改变为后付型。在传统的计费系统中，如果订户希望改变他们的支付模式，从预付方式改为后付方式(或反之)，则必须执行一个复杂的工作流程，先中止预付系统中订户的服务，然后再在后付系统中重新提供那些同样的服务。即使单一计费/客户维护系统是用于预付和后付两种类型订户，订户也必须被定义为预付型或后付型，并将账户从预付型变换为后付型，这是个复杂的操作。在本发明的混合型计费系统中，后付型和预付型之间的变换不是必须的。客户维护接口和个人维护接口对预付和后付支付模式是不可知的。例如一个普通的、维护客户的情形是之前的收费需要调整。当客户被收取一笔错误的费用或当客户没有得到已付费的服务时(例如由于网络不可用)，就会发生这种情况。对于预付和后付支付方式，本发明的系统都以同样的方式处理这些情形。CSR无需知道一笔指定费用是以何种方式支付。对一笔收费所进行的调整，将自动归入余额中，而该余额被用于偿付这笔收费。[300]对混合型订户的收费[300]对混合型订户的收费图示了在混合型订户的预付和后付余额中扣费的步骤。当所预订报价的其中之一的支付模式发生变化时，可用作支付的预付余额和后付余额也会因此而发生变化。在对[310]和[320]两者的图2B中，混合型订户具有多个预付和后付余额，这些余额可用于支付包含在已预订报价中的使用服务和其他费用(例如月租金及设备费用)。[310]和[320]之间的区别是可用的预付余额相对于后付余额的数量不同。混合型订户改变已预订报价其中之一的支付模式。报价A的支付模式原来是预付[在310中]， 但改为后付[在320中]。包含在报价A中所有余额的余额类型都从预付型改为后付型。在对[310]和[320]两者的图2B中，从预付和后付余额中扣费的过程仍旧如下所述。通过统一计费引擎、RC/NRC服务器、充值服务器以及计费和财务引擎，从预付和后付余额中扣除费用。当用户通过购买并使用预付凭单或通过使用信用卡或借记卡购买信用额度为其账户充值(“充满”)时，预付余额就会增加。当用户使用服务，预付余额会减少，费用将会被征收，且这笔费用会从余额中扣除。当余额达到零时，就不能再从余额中扣除费用(除非特殊情况，例如信用额度延长)，直至该余额被重新充值。后付余额的运作方式，与预付余额的相似，即当使用服务时，余额将减少。但是，余额不以相同的方式被重新充值。后付余额用于限制在一定时期内订户可用的后付信用总额。通常，在每月月初，余额将被重设为给定值(例如，50美元)，当50美元被消费完毕时 (即余额减到零)，就不能再从余额中扣除费用(除非特殊情况，例如信用被延长)直至在下月月初余额被重新设置。从后付余额中扣除的任何费用将被记录在系统中并开发票给客户。
余额顺序是对应于包含在报价中的每个余额而确立。如果混合型订户仅有一个报价，对于相应报价中的余额，其所确立的余额顺序就是用于收费。系统也提供了选择，可为一个或多个报价确立优先顺序。当混合型订户具有来自一个或多个预订报价的余额时，可使用该报价优先顺序。当使用服务时，将按照确立的顺序从余额中扣款。款项将从第一余额中扣除，直至达到该余额的限额，然后从第二余额扣除，直至达到该余额的限额，如此进行下去，直至付清所有费用为止。以这种方式，服务可能导致在预付余额、后付余额、或它们两者中扣除费用，这取决于余额顺序、余额当前值、以及报价的支付模式。在[310]中，预付余额仅可用于支付由报价引起的收费，其支付模式是预付，也就是报价A和报价C。后付余额仅可用于支付由报价引起的收费，其支付模式是后付，也就是报价B和报价C。预付费用和后付费用的支付顺序，是基于在报价A、报价B和报价C中指定的余额顺序，以及上述三种报价，即报价A、报价B和报价C，的报价优先顺序。在[320]中，后付余额仅可用于支付由报价引起的收费，其支付模式是后付，也就是仅报价C。后付余额仅可能够用于支付由报价引起的收费，其支付模式是后付，也就是报价A、B和C。预付费用和后付费用的支付顺序，是基于在报价A、报价B和报价C中指定的余额顺序，以及上述三种报价，即报价A、报价B和报价C，的报价优先顺序。[400]对混合型订户开出发票/清单图2B中[400]对混合型订户开出发票/清单图示了对混合型订户的预付收费和
后付收费的单一发票/清单。在图2B中的[405]和WlO]，混合型订户收到了单一文件(发票/清单)，其反映了对应于已预订报价的预付收费和后付收费。在本发明的系统中，每个订户有一个账户，该账户是可计费的实体，并且对应于混合型订户的账户能够收到单一文件(发票/清单)，该文件详细列明包括预付和后付两种方式的所有交易。该文件包括了预付开销和预付充值，以及后付新收费和到期余额的明细。 该文件是真实的汇总性账单，其上详细列明所有远程通信活动，而不管其服务类型或支付模式。由于仅需准备并寄出一份文件，CSP将从降低成本中受益。本发明公开的系统的各种部件都是本领域已知的硬件部件。例如，客户维护接口可以采用具有计算机终端协助的CSR的形式。订户可以通过电话或因特网接入CSR。例如， 个人维护接口可以采用订户的计算机的形式，其通过电话或因特网与CSP的管理服务器通信。例如产品目录可以采用计算机服务器的形式，其通过因特网接入CSP用户。例如，统一计费系统可以采用计算机服务器的形式。经常性收费/非经常性收费服务器可以采用服务器的形式。通过电话或因特网，订户凭借计算机接入系统成为一个整体。图3是实现网络通信服务的系统500的方框图，其中支付可由多个支付模式的任何方式实现。系统500包括交换机505、处理系统520、用户接口 M0、以及数据库555。交换机505是用于通过网络(图未示出)实现网络通信服务，例如语音呼叫或数据服务的装置。交换机505依照通信515进行运作，该通信一定程度上影响服务的提供。 例如，作为对通信515的回应，交换机505可能允许提供服务、拒绝服务、或以某些其他方式修改服务的提供。数据库555是可检索的存储系统。也就是说，存储在其中的数据能够以检索查询的方式被找到。数据库555包括表示支付模式560、余额565和余额准则570的数据。为了简单起见，所示出的数据库555仅有一个支付模式560、余额565和余额准则570。实际上， 数据库555将包含多个这些数据项。数据库555也可能被设置为多个存储装置，每个支付模式560、余额565和余额准则570都分别在多个存储装置的一个不同的存储装置中开始运作。处理系统520包括处理器525和内存530。处理器525是由可响应并执行指令的逻辑电路配置而成。内存530包含在支付模式处理器模块535中的指令，这些指令可通过处理器525读取，并控制处理器525的运作。此处所用术语“模块”表示一个功能性操作， 具体表现为一个独立部件或多个附属部件的集成结构。处理器525接收关于网络通信服务事件的通知510。为了响应通知510，处理器 525查询数据库555，以获得用于服务的支付模式560。支付模式560是可选的，也就是，其可以是以下一组支付模式中的任何一个，包括(a)预支付型、(b)后支付型、以及(c)预支付型和后支付型的混合型。处理器525会根据支付模式560，确定余额是否足够为该服务付款，也就是说，余额565是否符合余额准则570。根据余额565是否符合余额准则570这个条件，处理器525会向交换机505发出通信515，以影响服务的提供。要确定余额565是否满足余额准则570，这取决于支付模式560的状态。如果支付模式560是“预支付”，则处理器525会判定预付余额是否符合预付余额准则。如果支付模式560是“后支付”，则处理器525会判定信用余额是否符合信用余额准则。如果支付模式 560是“预支付和后支付的混合型”，则处理器525(a)会判定预付余额是否符合预付余额准贝U，以及(b)会判定信用余额是否同时也符合信用余额准则。用户接口 540是一个装置，通过该装置用户可与处理系统520通信。通过用户接口 M0，用户能提供指令M5，以改变支付模式560，从一种模式变为另一种模式，例如从预支付改为后支付。处理器525接收指令M5，并依照指令545更新数据库555中的支付模式 560。在此之后，如果处理器525接收到关于新事件的通知510，处理器525将执行查询，并 (基于更新的支付模式560)为新事件作出判定并发起通信。尽管此处所述的处理系统520具有嵌入至内存530中的支付模式处理器模块535， 但支付模式处理器模块535可安装在外围计算机可读的存储介质550中，这存储介质550 是用于随后将数据装载至内存530中。存储介质550可以是任何传统的存储介质，包括但不仅限于软盘、光盘、磁带、只读存储器或光学存储介质。指令也可以包含在位于远程存储系统并连接至内存530的随机存取内存(图未示出)或其他类型的电子存储器(图中未示出)中。在此所示的处理系统520带有单一处理器525和单一内存530。然而，处理系统 520可以作为分布式系统运行，配置多个处理器和多个内存。再者，尽管此处所述的处理系统520的部件被嵌入内存530中，并因此在软件中运行，但它们仍然可以在任何硬件、固件、 软件或其组合中执行运行。需要理解的是，前面的描述仅仅是本发明的举例。各种替换和修改方案，可以由那些本领域技术人员在不脱离本发明的基础上作出。相应地，本发明意图包括所有此类替换、 修改以及变化方案，其都落入所附权利要求保护范围之内。
1权利要求
1.一种方法，包括接收关于网络通信服务的事件的通知；查询数据库，以响应所述通知，获得用于所述服务的支付模式，其特征在于所述支付模式可从一组支付模式中选择，该组支付模式包括(a)预支付型和(b)后支付型；判定，即依照所述支付模式，判定用于支付所述服务的余额是否符合余额准则；以及依照用于支付所述服务的所述余额是否符合所述余额准则这个条件，向装置发起通信，以影响所述服务的提供。
2.如权利要求1所述的方法，其特征在于，如果所述支付模式是预支付型，则所述判定包括判定预付余额是否符合预付余额准则；以及如果所述支付模式是后支付型，则所述判定包括判定信用余额是否符合信用余额准则。
3.如权利要求1所述的方法，其特征在于，该组支付模式进一步包括(c)预支付型和后支付型的混合型。
4.如权利要求3所述的方法，其特征在于，如果所述支付模式是所述预支付型和后支付型的混合型，则所述判定包括判定预付余额是否符合预付余额准则；以及判定信用余额是否符合信用余额准则。
5.如权利要求1所述的方法，其特征在于， 所述事件是第一事件，以及所述方法进一步包括 接收指令，改变所述支付模式； 依照所述指令，更新所述数据库中的所述支付模式； 接收关于网络通信服务的第二事件的通知；以及执行所述查询，为所述第二事件作出判定并发起通信。
6.一种系统，包括 处理器；以及内存，所述内存包含指令，所述指令可由所述处理器读取，并引起所述处理器执行以下动作接收关于网络通信服务的事件的通知；查询数据库，以响应所述通知，获得用于所述服务的支付模式，其特征在于所述支付模式可从一组支付模式中选择，该组支付模式包括(a)预支付型和(b)后支付型；判定，即依照所述支付模式，判定用于支付所述服务的余额是否符合余额准则；以及依照用于支付所述服务的所述余额是否符合所述余额准则这个条件，向装置发起通信，以影响所述服务的提供。
7.如权利要求6所述的系统，其特征在于如果所述支付模式是预支付型，则所述判定包括判定预付余额是否符合预付余额准则；以及如果所述支付模式是后支付型，则所述判定包括判定信用余额是否符合信用余额准则。
8.如权利要求6所述的系统，其特征在于，该组支付模式进一步包括(c)预支付型和后支付型的混合型。
9.如权利要求8所述的系统，其特征在于，如果所述支付模式是所述预支付型和后支付型的混合型，则所述判定包括判定预付余额是否符合预付余额准则；以及判定信用余额是否符合信用余额准则。
10.如权利要求6所述的系统，其特征在于， 所述事件是第一事件，以及所述动作进一步包括 接收指令，改变所述支付模式； 依照所述指令，更新所述数据库中的所述支付模式； 接收关于网络通信服务的第二事件的通知；以及执行所述查询，为所述第二事件作出判定并发起通信。
11.一种存储介质，包括指令，所述指令可被处理器读取，并使所述处理器执行以下动作接收关于网络通信服务的事件的通知；查询数据库，以响应所述通知，获得用于所述服务的支付模式，其特征在于所述支付模式可从一组支付模式中选择，该组支付模式包括(a)预支付型和(b)后支付型；判定，即依照所述支付模式，判定用于支付所述服务的余额是否符合余额准则；以及依照用于支付所述服务的所述余额是否符合所述余额准则这个条件，向装置发起通信，以影响所述服务的提供。
12.如权利要求11所述的存储介质，其特征在于，如果所述支付模式是预支付型，则所述判定包括判定预付余额是否符合预付余额准则；以及如果所述支付模式是后支付型，则所述判定包括判定信用余额是否符合信用余额准则。
13.如权利要求11所述的存储介质，其特征在于，该组支付模式进一步包括(c)预支付型和后支付型的混合型。
14.如权利要求13所述的存储介质，其特征在于，如果所述支付模式是所述预支付型和后支付型的混合型，则所述判定包括 判定预付余额是否符合预付余额准则；以及判定信用余额是否符合信用余额准则。
15.如权利要求11所述的存储介质，其特征在于， 所述事件是第一事件，以及所述动作进一步包括 接收指令，改变所述支付模式；以及依照所述指令，更新所述数据库中的所述支付模式； 接收关于网络通信服务的第二事件的通知；以及执行所述查询，为所述第二事件作出判定并发起通信。
全文摘要
本发明提供了一种方法，其包括(i)接收关于网络通信服务的事件的通知；(ii)查询数据库，以响应该通知，获得用于该服务的支付模式，其中支付模式可从一组支付模式中选择，该组支付模式包括(a)预支付型及(b)后支付型；(iii)依照该支付模式，判定用于支付服务的余额是否符合余额准则，以及(iv)依照用于支付服务的余额是否符合余额准则这个条件，向设备发起通信，以影响服务的提供。本发明还提供了一种使用该方法的系统，以及一种存储介质，该存储介质包含用于控制处理器执行该方法的指令。
文档编号H04M15/00GK102461145SQ200980159941
公开日2012年5月16日 申请日期2009年4月30日 优先权日2009年4月30日
发明者克里斯多夫·艾伦·多勒, 利奥·奥斯兰德, 加布里埃尔·马斯赖兹, 大卫·M·塞尔, 布鲁斯·弗兰克尔, 杰弗里·本戈·科尔曼, 潘卡吉·特里维迪, 赫拉塔·S·凯迪亚 申请人:康维公司