Topping up a subscriber's account for a multimedia service on a communications network while the service is being provided

FIELD OF INVENTION

[0003] The present disclosure relates generally to the field of communications networks and more specifically to notifying a subscriber of a communications network that a threshold amount of a multimedia service provided on the network has been consumed while the service is being provided and enabling the subscriber an opportunity to add value to an account balance for the multimedia service (i.e., “top-up”) while the service is being provided, thereby extending the duration that the service is provided.

DESCRIPTION OF THE RELATED ART

[0004] For typical communications service providers, it is desirable to be able to measure and price communication services, including audio (e.g., voice) services, data services, video services, and multimedia services, and present bills for such services. As used herein, an “audio service” is a service that includes an exchange voice content between two or more nodes of a communications network, a “data service” is a service that includes an exchange of data content between two or more nodes of a communications network, a “video service” is a service that includes an exchange of video content (i.e., one or more sequential images) between two or more nodes of a communications network, and a “multimedia service” is a service that includes an exchange of data content or video content, or any combination of video content, audio (e.g., voice) content and data content, between two or more nodes of a communications network. A service that exchanges only voice content is not a “multimedia service” as defined herein.

[0005] It should be understood that although a service or communication includes the exchange of one or more types of content, such service and communication also may include the exchange of other information in addition to content, including signaling, control and formatting information, in accordance with one or more protocols.

Billing Systems for Voice Services

[0006]
FIG. 1 illustrates an example of a traditional telecommunications system 100 for providing voice services that utilizes a postpaid billing method. As used herein, a “voice service” is a service providing the exchange of voice content between nodes of a communications network. System 100 may be a mobile or landline telecommunications network.

[0007] For example, a session may be initiated by calling party 102 with called party 114 across originating central office 104, long distance network 116 and terminating central office 113. At the beginning of the session, the system 100 authenticates a subscriber (i.e., subscriber) 102 of a particular service, authorizes that the subscriber is entitled to access the service, and in some cases validates the subscriber has sufficient creditworthiness or prepaid amounts to at least begin using the service. The service can then be rendered and sufficient information recorded in a data record often referred to as a Call Detail Record (CDR). Information embodied in fields in the CDR such as duration of a session or volume of bytes consumed during a session, is monitored by network elements, such as at the Originating Central Office 14, and entered into the CDR. Once the session is finished, a completed CDR is sent to a Billing Collector 106. In some cases, the Billing Collector periodically forwards a batch of the CDRs to a Billing Mediator 108, which converts the specific CDR formats from a plurality of network elements to a common format understood by a Billing System 110. The billing system typically determines the underlying price for a provided service by applying a rate for the service to the CDR to produce a final price for the service. The billing system then may merge the final price for the service onto the subscriber's bill 112.

[0008] As technology has changed, adding more powerful processing capabilities, it has become possible to perform some of the steps of billing for a voice service in real-time or quasi-real-time. For example, rating a service, which was described above as being performed after the voice service was performed, may occur simultaneously with the authorization step at the beginning of a session for the service. With such rate information, it is possible to determine a specific time quantity (for time-based metering) or a specific volume quantity (for volume based metering of volumes of data) for which a voice service can be provided before such provisioning should be stopped (i.e., the call should be disconnected). For example, before providing a voice service, the balance present in a prepaid account may be divided by the rate per unit of time or volume for the service to produce a service value. This voice service value could then be used to preset a time or volume threshold. The voice service can then be metered until the threshold is reached, at which time higher level processing can be notified that the threshold has been reached. This type of prepaid processing is present in several voice telecommunications systems worldwide. As used herein, a “prepaid account” is a subscriber's account for a service for which the subscriber has subscribed for prepaid charging.

[0009] Typically, in such voice telecommunications systems, in response to a threshold being reached, the system will interrupt the voice call in progress and, using a Voice Response Unit (VRU), warn the calling party about the impending disconnection that will occur. More extensive processing can also occur at this point. The VRU prompt may offer the caller an opportunity for adding value to an account (i.e., “topping-up” an account) by entering a new unique code printed on a pre-paid phone card (i.e., “top-up card”), for example, by touch tone entry. In places that provide the ability to top-up (e.g., several European countries), top-up cards are typically sold through retail locations like supermarkets, convenience stores or gas stations.

[0010]
FIG. 2 illustrates an example of a typical system 101 for implementing real-time prepaid charging for voice calls. System 101 may be a mobile or landline telecommunications network.

[0011] Calls are routed from a network 116 to a Prepaid Adjunct Processor 118, which is responsible for metering the call, identifying when a prepaid threshold has been reached, introducing a Voice Response Unit to alert the Calling Party of the impending call disconnect and offering a top-up opportunity. In the embodiment of system 101, the rating and account balance information is stored in a separate computer 120 and the functions performed by the Prepaid Adjunct Processor are initialized by computer 120.

[0012] In another embodiment of system 101, the Prepaid Adjunct Processor 118 may be embedded directly into a Central Office (e.g., Central Office 104) and may be implemented using Intelligent Network Services, which are described in more detail below.

[0013] In an embodiment of system 101, the calling party 102 makes a prepayment into an electronic account, which is stored in a database on the network. Prepayments can be made in a number of fashions, where the most prevalent is to go to a retail point of sale such as a supermarket or convenience store and pay a sum of money to acquire a prepaid card. The prepaid card has a unique code that represents a link to the electronic account. To access the value stored in the electronic account, the calling party or party to be billed enters an access code that routes the call to the Prepaid Adjunct Processor 118. In an alternative embodiment, the calling party terminal (i.e., subscriber terminal) may be uniquely identified as a prepaid account holder and be automatically routed to the Prepaid Adjunct Processor. For example, a unique calling party identification (e.g., an International Mobile Subscriber Identity (IMSI) for a mobile telecommunications system) may be used as the key to the electronic account, as opposed to the unique code on a prepaid card.

[0014] In response to the Prepaid Adjunct Processor 118 receiving the call, the calling party 42 is asked for the unique code to allow the adjunct processor to identify the electronic account in which the prepaid amount is resident. The caller is then requested to enter the identification of the called party 114 (i.e., the phone number) to which the call should be sent. These two pieces of information are communicated to a computer (e.g., computer 120) that maintains the electronic account and has the ability to “rate” the cost of making a call to the called party 114. Based on the monetary balance remaining in the electronic account and the cost of the service to be rendered (e.g., dollars per unit of time or volume), a rating and accounting subsystem can calculate the number of minutes or volume of information united (e.g., bytes) left to reach a prepaid threshold or spending threshold. The rating/accounting computer 120 communicates a message to the Prepaid Adjunct Processor 118 that allows the Prepaid Adjunct Processor to initialize an internal meter which measures the duration for which the call is in progress (starting when the called party 114 answers) or the volume of information units that flow through the transport path during the call, starting from when a voice session for the call is established.

[0015] When the Prepaid Adjunct Processor 118 determines that the prepaid threshold for the call is reached, a low balance warning is sent to the calling party by either placing the called party on hold and inserting a VRU or by bridging the VRU directly into the call. It is sometimes preferred that the call is suspended during this period so the warning cannot be heard by the called party, and it is sometimes preferable for both parties to hear the warning. Additional processing can also be performed at this time to allow extension of the current call by topping up the prepaid account.

[0016] In this scenario, the called party 114 is typically placed on hold. The Prepaid Adjunct Processor 118 is conditioned to receive touch tone input, and the calling party 42 is offered the opportunity via a VRU message to enter a new unique code from a prepaid card purchased in a retail location. Once the unique code has been received and verified, and the meter of the Prepaid Adjunct Processor 118 has been re-initialized with the new values, the suspended call is allowed to continue. Most often, the existing electronic account and the initial unique code of the calling party survive the call when it is completed, and the unique code and associated electronic account of the prepaid card used to add value to the existing account are marked as depleted once the value from the account has been transferred to the existing account.

Mobile Communications Networks

[0017] The need to meter, price and bill communications services is recognized on mobile (i.e., wireless) communications networks (MCNs), as MCNs (mobile telecommunications networks, mobile data communications networks and combinations thereof) are having a growing impact on the communications industry. In addition to enabling communication services to be provided by service providers, operators of MCNs often provide Intelligent Network Services (INSs), for example, prepaid charging, for their subscribers as well.

[0018] There are several types of MCNs, as well as several types of MCN network elements, technologies and configurations. For a better understanding of the problems and solutions set forth below, these several types of MCNs, network elements, technologies and configurations will now be described.

[0019] As used herein, a “mobile communications network” or “MCN” is a communications network including a plurality of network resources that enable wireless communications between two or more of the plurality of network resources. As used herein, “plurality” means two or more. MCNs are often referred to as Public Land Mobile Networks (PLMNs). Several types of MCNs are known, and some are in use today, including Global System for Mobile communications (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), a plurality of types of Code-Division Multiple Access-based communications networks (e.g., cdmaOne, cdma2000, etc.), Wireless Personal Area Networks (PANs), for example, Bluetooth or a wireless PAN in accordance with IEEE 802.15, and Wireless Local Area Networks (WLANs), for example, HiperLan 2 or a WLAN in accordance with IEEE 802.11 (e.g., 802.11b (Wi-Fi), 802.11a and 802.11g).

[0020] GPRS originally was developed and is often implemented as an add-on to existing GSM networks. Thus, a GSM network and a GPRS network are often part of an MCN referred to herein as a GSM/GPRS network. GSM, often referred to as a 2nd Generation or 2G network, is described in more detail in: 3rd Generation Partnership Project Technical Specification Group Services and System Aspects, Digital cellular telecommunications system (Phase 2+), GSM Release 1999 Specifications (3GPP TS 01.01), the entire contents of which are hereby incorporated by reference.

[0021] The 3rd Generation Partnership Project (3GPP) specifies European-centric mobile communication standards such as GPRS and UMTS. The 3rd Generation Partnership Project II (3GPP2) is an organization that specifies more US-centric mobile communications standards such as CDMA 2000 standards.

[0022] GPRS, often referred to as a 2.5G network, is described in more detail in: 3rd Generation Partnership Project, Technical Specification Group Services and System Aspects, Digital cellular telecommunications system (Phase 2+), General Packet Radio Service (GPRS), Service description, Stage 2, Release 1998 (3GPP TS 03.60), the entire contents of which are hereby incorporated by reference.

[0023] UMTS, often referred to as a 3rd Generation or 3G network, is described in technical specifications published by the 3rd Generation Partnership Project, including 3GPP TS 23.101, whereas packet-switched services of UMTS are described in 3GPP TS 23.060. The entire contents of 3GPP TS 23.101 and 3GPP TS 23.060 are each being hereby incorporated by reference.

[0024] CdmaOne, often referred to as a 2.5G network, is described in more detail in: ANSI/Telecommunications Industry Association (TIA)/EIA-95-A and 95-B Standard, Mobile terminal-Base Station Compatibility Standard for Wideband Spread Spectrum Cellular Systems, ANSI/TIA/EIA-41-C and 41-D Standard, Cellular Radiotelecommunications Intersystem Operations, the entire contents of which are hereby incorporated by reference.

[0025] Cdma2000 is described in more detail in technical specifications published by the 3rd Generation Partnership Project II, including A.S0001-A 3GPP2, Access Network Interfaces Interoperability Specification—Release A, the entire contents of which is hereby incorporated by reference.

[0026] Some MCNs only are capable of implementing circuit-switched voice services. As used herein, a “circuit-switched voice service” is a voice service, for example, plain old telephone service (POTS), implemented using circuit-switched communications (analog or digital). As used herein, a “circuit-switched voice communication” is a communication including voice content that is transmitted along a network path (i.e., a connection or circuit) established between two endpoints for which a portion of bandwidth (e.g., a time slot) of each link along the path is exclusively reserved for a duration of the connection. All communications transmitted from one endpoint to the other endpoint travel the same path across the network defined for the connection, which is established before communications begin. For example, for a telephone call, a connection is established between at least two parties and reserved for a duration of the call. Typically, after a connection has been established, circuit-switched voice communications include a connection identifier and a destination identifier (e.g., telephone number) from which network nodes determine where to route (i.e., switch) the communication. A Public Switched Telephone Network (PSTN) is an example of a communications network that provides circuit-switched voice services. A GSM network is an example of an MCN that provides circuit-switched voice services.

[0027] Other MCNs are capable of implementing packet-switched services in addition to or as an alternative to circuit-switched voice services. As used herein, a “packet-switched service” is a service implemented using packet-switched communications, for example, an Internet access service provided by an Internet Service Provider (ISP).

[0028] As used herein, a “packet-switched communication” is a communication transmitted between two nodes of a communications network using packet-switching, where the communication comprises one or more packets. As used herein, a “session” is a logical relationship established between at least two network entities for a period of time. As used herein, a “packet” is a unit of information exchanged between modules of a communications network, where such modules may reside on a same or different node of the communications network. As used herein, to “exchange” means to transmit to transmit and/or receive. Packets are often referred to as “frames” in the network communications industry. Using packet-switching, each packet exchanged between the two nodes may travel a different path across the network and may encapsulate any of a variety of media content, including audio (e.g., voice), video, and data, or combinations thereof. Using packet-switching, each packet of a packet-switched communication may include a source identifier (e.g., IP address) and a destination identifier (e.g., IP address) from which network nodes determine where to route or switch each packet of the communication. A Local Area Network (LAN) is an example of a communications network that can provide packet-switched services. A GPRS network is an example of an MCN that can provide packet-switched services.

[0029] As used herein, a “user terminal” is a communication device that serves as an endpoint in a communications network and at which communications may terminate and/or originate. Some examples of user terminals include work stations, PCs, laptops, telephones, pagers, Blackberry™ brand devices, PCS devices, personal digital assistants (PDAs), etc.

[0030] As used herein, a “mobile terminal” or “MT” is a user terminal capable of communicating (i.e., receiving and/or transmitting communications) with other network resources through an air interface (i.e., using a carrier wave).

[0031] As used herein, a “mobile subscriber” or “subscriber” is a user of an MT who subscribes to one or more services provided by an operator of an MCN.

[0032]
FIG. 3 is a block diagram illustrating a communications network 1 that includes at least MCNs 2 and 4, one or more packet data networks (PDNs) 6, a public switched telephone network (PSTN) 8 and one or more other communications networks 10, which each can be any of a variety of types of communications networks. A PDN may be any communications network capable of communicating information encapsulated in packets, for example, an Internet Protocol-based (IP-based) network, an X.25-based network, or an Asynchronous Transfer Mode (ATM) network.

[0033] The MCN 2 may include one or more MTs 18 configured to communicate with a wireless access sub-network (WAS), for example, a Base Station Subsystem (BSS) of a GSM, GPRS or UMTS network or a Radio Access Network (RAN) of a CDMA-based network. The MCN 2 may include one or more WASs 12 that are each interfaced to a network services sub-network (NSS) 10 of the MCN 2.

[0034]
FIG. 4 illustrates a WAS 12 of an MCN 2 in more detail. A WAS 12 provides the radio link between an MT and an NSS. A WAS 12 may include any of one or more wireless access portals (WAPs) 30, for example, a Base Transceiver Station (BTS) and radio tower of a BSS or a RAN. A WAP 30 may include one or more radio transceivers. In a typical MCN, a range of a transceiver defines a cell. A WAP 30 handles the radio-link protocols for communication with an MT.

[0035] Each of the one or more WAPs 30 may be connected to a wireless access sub-network controller (WASC), for example, a Base Station Controller (BSC) of a BSS or a Radio Network Controller (RNC) of a RAN. The WASC 32 manages the radio resources for one or more WAPs 30. For example, the WASC may handle radio-channel set up, frequency hopping, and handoffs between WAPs. The WASC serves as a logical interface between an MT and one or more switching modules of the NSS 10.

[0036] The WASC 32 may be configured to discriminate between packet-switched communications and circuit-switched communications. The WASC 32 may include a packet control unit (PCU) 33 that enables the WASC 32 to handle packet-switched communications and route them to packet-switching module (PSM) 36 of NSS 10, whereas circuit-switched voice communications are routed to circuit-switching module (CSM) 34.

Network Services Sub-network of a Mobile Communications Network

[0037]
FIG. 5 illustrates the NSS 10 of MCN 2 in more detail. A typical NSS 10 performs the switching of communications between subscribers of the MCN 2 and between a subscriber of the MCN 2 and a network resource on another network (e.g., another MCN 4, a PDN 6, a PSTN 8 or another communications network 10). The NSS 10 also may handle the mobility management operations for the MCN 2 and provide a variety of other services. The NSS 10 may include any of one or more CSMs 34A, one or more PSMs 36A, one or more PDN Interface Modules (PIMs) 44A and 46B, one or more Service Control Function (SCF) modules 48, one or more subscriber information registers (SIRs) 50, one or more charging gateways 45 and one or more billing systems 47.

[0038] An NSS (e.g., NSS 10) that includes both a CSM and a PSM enables subscribers to have access to both circuit-switched voice services and packet-switched services. For example, if the NSS 10 is part of a GSM/GPRS network, one or more of the CSMs may be a Mobile Switching Center (MSC) that may include a Visitor Location Register (VLR), and the PSM may be a Serving GPRS Support Function (SGSF) module. The SGSF module may be implemented on a Serving GPRS Support Node (SGSN) of the GPRS network, or may be implemented on a GPRS Support Node (GSN) that also may include a Gateway GPRS Support Function (GGSF) module.

[0039] Alternatively, if the NSS 10 is part of a GSM network that implements only circuit-switched voice services, the NSS 10 may not include any PSMs, but may include one or more MSCs that each may include a (Visitor Location Register) VLR.

[0040] The switching modules (CSMs and PSMs) may provide a variety of services for the NSS, including registration of subscribers, authentication, ciphering, location updating (of subscribers), handoffs between WASCs and switching. For example, the switching nodes may switch communications, originating from an MT and received from a WASC, to an appropriate destination, for example, another WASC, another module or node of the NSS 10, a node of another MCN 4, a PIM (e.g., 44A, 44B) for interfacing to a PDN (e.g., 6A, 6B), a node of the PSTN 8 or a node of another communication network. The switching modules may provide other services.

[0041] A PIM (e.g., 44A and 44B) serves as a logical interface between an MCN 2 and a PDN (e.g., 6A, 6B) external to the MCN 2. PDNs 6A and 6B may be any type of packet data network, including the Internet or a corporate LAN. To serve as such logical interface, a PIM may be configured to implement protocols specific to the MCN 2 and protocols specific to a PDN 6. For example, for a GPRS network, a GGSF module may serve as a PIM and be configured to implement one or more packet data protocols, for example, the User Datagram Protocol (UDP) or the Transport Control Protocol (TCP) and IP or X.25 protocols. The GGSF module further may be configured to implement one or more GPRS protocols such as the GPRS Tunneling Protocol (GTP).

[0042] A PIM (e.g., PIM 44A or 44B) may be configured to exchange communications (e.g., a Data Call Detail Record (DCDR)) with a charging gateway 45, which may in turn aggregate such DCDRs from one or more PIMs and forward them to a billing system 47 for further processing.

[0043] PDN 6B may include a PDN node 66. PDN node 66 may be configured with one or more applications that provide one or more services to subscribers. As such, PDN node 66 may be an application server.

[0044] To implement a session between an MT 18A of the MCN 2 and a node 66 of the PDN 6A, the PSM 36A may switch communication packets received from the WASC 32A to PIM 44A, which exchanges communication packets (using the appropriate protocols) with the appropriate nodes of the PDN 6A to communicate with node 66.

[0045] Different types of MCNs may have different implementations of a PIM. For a CDMA-based network, a PIM may be a Packet Data Serving Node (PDSN).

[0046] For a GPRS network, a PIM may be a GGSF module, which is configured to implement GPRS-defined interfaces: a Gi interface to a PDN, a Gn interface to an SGSF module of the MCN and a Gp interface to an SGSF module from another MCN. On some GPRS networks, an SGSN and a GGSN are combined on the same network node, sometimes referred to as a GPRS Support Node (GSN). Even on such GSNs, however, the GGSF module and the SGSF module typically are configured as separate, logically-interconnected modules.

[0047] The Subscriber Information Register (SIR) 50 may include an entry for each subscriber of the MCN 2, the entry representing a subscriber profile of information about the subscriber, including administrative information about the subscriber, the location of the MT currently being used by the subscriber and information about services to which the subscriber is registered. On a GSM/GPRS network, the SIR may be a Home Location Register (HLR), and an MSC, a GGSF module and a SGSF module may communicate with the HLR in accordance with the Mobile Applications Part (MAP) protocol, GPRS Release 1998 or 1999, on top of an SS7 protocol. Other protocols may be used. GPRS Release 1998 is described in more detail in: 3rd Generation Partnership Project; Technical Specification Group Core Network; Digital cellular telecommunications system (Phase 2+); Organization of subscriber data; Release 1998 (3GPP TS 03.08), and 3rd Generation Partnership Project; Technical Specification Group Core Network; Subscriber data management; Stage 2 Release 1998 (3GPP TS 03.16), the entire contents of which are hereby incorporated by reference.

[0048] GPRS Release 1999 is described in more detail in: 3rd Generation Partnership Project; Technical Specification Group Core Network; Organization of subscriber data; Release 4 (3GPP TS 23.008), and 3rd Generation Partnership Project; Technical Specification Group Core Network; Subscriber data management; Stage 2; Release 4 (3GPP TS 23.016), the entire contents of which are hereby incorporated by reference.

Intelligent Network Services

[0049] The MCN 2 may include one or more SCF modules 48 to provide and control execution of one or more INSs to subscribers. An INS is an advanced communication service beyond traditional services such as setting up, maintaining and terminating a call or session and other traditional telephony services such as call waiting and call forwarding. Several existing technologies today implement INSs by having switching modules (e.g., a PSM or CSM) consult (i.e., exchange communications with) an SCF module to implement the service. For example, on some existing networks, to implement an INS for a circuit-switched telephone call, in response to receiving all of the digits for a telephone number, a CSM initiates communications with an SCF module before contacting other network nodes to establish the connection for the telephone call. Conversely, if no INS is to be implemented for the circuit-switched telephone call, the CSM will not initiate communications with an SCF module before proceeding with establishing the connection.

[0050] For a circuit-switched telephone call for which an INS is not to be implemented, a CSM may merely access its routing table to determine where to route the telephone call based on the digits received from the subscriber. If a subscriber has subscribed to an INS, then the routing table may be configured (e.g., programmed with “hooks”) to cause the CSM to initiate communications with an SCF module in response to receiving telephone number digits from the subscriber or in response to receiving a specific sequence of digits from the subscriber, or in response to values of any of a number of other parameters.

[0051] As will be described in more detail below, an SCF module may be configured with the “intelligence” for implementing the INS. The SCF module may instruct the CSM to switch a telephone call based on any of a number of parameters, for example, time of day, location from which the call is originated, the destination for which the call is bound, etc.

[0052] Types of known INSs include Toll-free, Virtual Private Network (VPN), Personal Number, Premium Rate, Calling Card, Toll-Shared, Number Portability and Prepaid Charging. As used herein, “prepaid charging” refers to a type of charging for a service where a subscriber pays for an amount of the service before the service is provided.

[0053] Currently, and over the last few years, INSs are being developed and integrated into existing MCNs with each new release of a particular technology. For example, the International Telecommunication Union Telecom Standardization (ITU-T) body specifies INSs in Capability Set 1 (CS-1) and CS-2 of the Q.1200 recommendation series. The European Telecommunications Standards Institute (ETSI) specifies INSs in its Core Intelligent Network Application Part (INAP). The 3GPP specifies INSs for its Customized Applications for Mobile Network Enhanced Logic (CAMEL) technology, Phases 1, 2, 3 as defined in the GSM Technical specification versions 02.78, 03.78 and 09.78 and in the Third Generation (3G) technical specification versions 22.078, 23.078 and 29.078. The American National Standards Institute (ANSI) specifies INSs in its Advanced Intelligent Network (AIN) specifications versions 0.1 and 0.2. The 3GPP2 specifies INSs in its Wireless Intelligent Network (WIN) Phase 2 version N.S004 technical specification. All of the above versions and specifications for INS technologies are hereby incorporated by reference in their entireties.

[0054] For illustrative purposes, INSs, particularly prepaid charging, will be described below primarily in the context of the traditional implementation in which an SCM module is consulted, and more specifically will be described primarily in relation to CAMEL technology and in relation to GSM, GPRS, and GSM/GPRS networks.

Intelligent Network Services for Circuit-switched Voice Services

[0055]
FIG. 6 is an example of a an NSS 110 of an MCN that is capable of providing package-switched services, circuit-switched voice services and one or more INSs for circuit-switched voice services. As used herein, a “circuit-switched INS” is an INS configured for circuit-switched voice services.

[0056] The NSS 110 may include an SIR 150, one or more SCF modules 148, one or more CSMs (134a, 134b), one or more PSMs, including PSM 136a, and one or more PIMs, including PIM 144a. Each of these network elements may be configured with functionality that is at least similar to functionality of network elements of the same name described above in relation to NSS 10 of FIG. 5, and also may be configured with additional functionality as follows. The CSM 134a may be configured to exchange call packets 157 with a WASC of a WAS, and exchange call packets 159 with nodes of other communications networks, for example a PSTN. CSM 134a may be configured to communicate packets with such external networks directly or may be configured to use another CSM 134b to communicate with such external networks. As used herein, a “call packet” is a communication unit exchanged between modules of an MCN as part of a circuit-switched voice service (e.g., a telephone call).

[0057] To implement one or more INSs on the NSS 110, the SCF module 148 may be configured with circuit-switched INS functionality 149 that defines and controls one or more INSs, for example, prepaid charging. Further, the CSM 134a may include a Service Switching Function (SSF) module 151 configured to exchange communications (e.g., packets) with the SCF module 148 to implement the one or more INSs. As used herein, an “SSF module” is a module (e.g., software, hardware, firmware or any combination thereof) residing on a node of an MCN that is configured to at least assist in implementing one or more INSs by exchanging communications (e.g., packets) with one or more SCF modules that define and control the one or more INSs.

[0058] To implement one or more INSs, the SSF module 151 and the SCF module 148 may be configured to exchange one or more circuit-switched-INS packets 147. As used herein, a “circuit-switched-INS packet” is a packet exchanged between network elements to implement a circuit-switched INS. Specifically, the SSF module 151 may be configured to communicate with the SCF module 148 in response to one or more triggering events, such as the initiation of a telephone call, the answering of a telephone call, or the termination of a telephone call (i.e., hanging up).

[0059] The SIR 150 may include administration, location and non-INS information 152 for a subscriber, as described above in relation to FIG. 5. In addition, the SIR 150 may include subscriber circuit-switched-INS information 154. For each subscriber, this information 154 may include information about one or more circuit-switched INSs to which the subscriber is registered. For each such circuit-switched INS to which the subscriber is registered, the information 154 may include an identity of the SCF module to be used to implement the INS and the triggering events in response to which an SSF should contact the appropriate SCF module.

[0060] Accordingly, when a subscriber attaches to the MCN to which the NSS 110 belongs, the CSM 134a may download from the SIR 150 the subscriber information 155 which includes the subscriber circuit-switched INS information 154. Subsequently, in response to a triggering event, the SSF module 151 may initiate communications with the SCF module 148, and request and receive instructions and information relating to the triggering event.

[0061] For example, SSF module 151 may be configured to communicate with the SCF module 148 to implement prepaid charging for a circuit-switched voice service such as the maintenance of a telephone call connection. In response to the CSM 134A detecting the answering of the telephone call by a subscriber, the SSF module 151 may send a circuit-switched INS packet 147 to SCF module 148 to request INS instructions and information for the telephone call. The circuit-switched INS functionality 149 may determine the instructions and information, and the SCF module 148 may send a circuit-switched INS packet 147 including such instructions and information to the SSF module 151.

[0062] If the INS is prepaid charging, a packet 147 sent by the SCF module 148 may include information for implementing prepaid charging. The SSF module 151 may be configured to receive such information and to implement prepaid charging accordingly. Further, the SSF module 151 may be configured to communicate with the SCF module 148 throughout the call in response to one or more other triggering events.

[0063] Depending on the type of MCN, the NSS 110 may be configured to implement one or more INSs in accordance with one or more of the INS technologies discussed above. For example, if the MCN is a GSM, the SIR 150 is an HLR and the CSM 134A is an MSC, then the SIR 150, the CSM 134A and the SCF module 148 may be configured to implement one or more INSs in accordance with CAMEL, for example, in accordance with CAMEL Phase 1 or 2. Further, the SSF module 151 may communicate with the SCF module 148 in accordance with the CAMEL Application Part (CAP) protocol on top of the signaling system 7 (SS7 protocol) in accordance with CAMEL Phase 1 or 2.

[0064] The PSM 136A may be configured to exchange session packets 158 with a WASC of a WAS and exchange session packets 160 with a PIM 144A, which exchanges session packets 162 with one or more nodes of one or more PDNs. As used herein, a “session packet” is a communication unit exchanged between modules of an MCN as part of a session.

[0065] Although PSM 136A may be configured to download subscriber information 156, for example, in response to a subscriber attaching to the MCN to which the NSS 110 belongs, and to switch session packets 158 and 160, PSM 136 is not configured to communicate with SCF module 148 to implement one or more packet-switched INSs. As used herein, a “packet-switched INS” is an INS configured for packet-switched services.

[0066] Further, SIR 150 does not include subscriber packet-switched INS information, and SCF module 148 does not include any packet-switched INS functionality. Accordingly, NSS 110 is not configured to provide one or more packet-switched INSs.

Intelligent Network Services for Packet-Switched Services

[0067] To implement one or more packet-switched INSs on an NSS, it is known to configure an NSS 210 as illustrated in FIG. 7. NSS 210 may include an SIR 250, one or more SCF modules 248, a PSM 236A and a PIM 144A. NSS 210 also may include CSMs 134A and 134B (not shown).

[0068] Each of these network elements may be configured with functionality that is at least similar to functionality of network elements of the same name described above in relation to NSS 110 of FIG. 6, and also may be configured with additional functionality as follows. The PSM 236A may be configured to exchange session packets 158 with a WASC of a WAS, and exchange session packets 160 with PIM 144A, which may be configured to communicate session packets 162 with external networks such as a PDN. Further, the PSM 236A may include an SSF module 262 configured to exchange communications (e.g., packets) with the SCF module 248 to implement the one or more INSs.

[0069] The SCF module 248 may be configured with functionality at least similar to functionality of SCF module 148, described above in relation to FIG. 6, and in addition may include packet-switched INS functionality 249 that defines and controls one or more INSs, for example, prepaid charging for packet-switched services.

[0070] To implement one or more INSs, the SSF module 262 and the SCF module 248 may be configured to exchange one or more packet-switched INS packets 260. As used herein, a “packet-switched-INS packet” is a packet exchanged between network elements to implement a packet-switched INS. Specifically, the SSF module 262 may be configured to communicate with the SCF module 248 in response to one or more triggering events, including the initiation of a session, and the termination of a session.

[0071] The SIR 250 may be configured with at least similar information to the information of SIR 150, described above in relation to FIG. 6, and in addition, may include subscriber packet-switched-INS information 254. For each subscriber, this information 254 may include information about one or more packet-switched INSs to which the subscriber is registered. For each such packet-switched INS to which the subscriber is registered, the information 254 may include an identity of the SCF module to be used to implement the INS and the triggering events in response to which an SSF should initiate communications with the appropriate SCF module.

[0072] Accordingly, when a subscriber attaches to the MCN to which the NSS 210 belongs, the PSM 236A may download from the SIR 250 the subscriber information 256 which includes the subscriber packet-switched INS information 254. Subsequently, in response to a triggering event, the SSF module 262 may initiate communications with the SCF module 248, and request and receive instructions and information relating to the triggering event.

[0073] For example, SSF module 262 may be configured to communicate with the SCF module 248 to implement prepaid charging for a packet-switched service such as the maintenance of a session. In response to the PSM 236A detecting a response by a subscriber to a request to establish a session, the SSF module 262 may send a packet-switched-INS packet 260 to SCF module 248 to request INS instructions and information for the session. The packet-switched INS functionality 249 may determine the instructions and information, and the SCF module 248 may send a packet-switched-INS packet 260 including such instructions and information to the SSF module 262.

[0074] If the INS is prepaid charging, the packet 260 sent by the SCF module 248 may include information for implementing prepaid charging. The SSF module 262 may be configured to receive such information and to implement prepaid charging accordingly. Further, the SSF module 262 may be configured to communicate with the SCF module 248 throughout the session in response to one or more other triggering events.

[0075] Depending on the type of MCN, the NSS 210 may be configured to implement one or more INSs in accordance with one or more of the INS technologies discussed above. For example, if the MCN is a GSM, the SIR 250 is an HLR and the PSM 236A is a SGSF module, then the SIR 250, the PSM 236A and the SCF module 248 may be configured to implement one or more INSs in accordance with CAMEL, for example, in accordance with CAMEL Phase 3. Further, the SSF module 262 may communicate with the SCF module 248 in accordance with the CAMEL Application Part (CAP) protocol on top of the SS7 protocol in accordance with CAMEL Phase 3.

Establishing a Session For a Roaming Subscriber of an MCN

[0076] A typical methodology for establishing a session between a roaming subscriber and a node of a PDN will now be described with reference to FIG. 5. As used herein, a “roaming subscriber” is a subscriber who is accessing network services from outside of his home MCN (i.e., from a visited MCN). A subscriber's home MCN is the MCN from which the subscriber obtains a mobile service subscription. For example, a subscriber may obtain a mobile service subscription from a MCN operator in New England. As the subscriber travels on business in California, the subscriber may access network services provided by an MCN in California (the visited MCN), which may have a roaming arrangement (i.e., agreement) with his home MCN in New England. Such a roaming agreement may specify, among other things, what type of network services the subscriber is allowed and not allowed to access, and how the subscriber will be billed for the network services the subscriber accesses while roaming in the California MCN. For example, the subscriber may be barred from making international calls while roaming in the California MCN.

[0077] If a subscriber whose home MCN is MCN 2 (i.e., the home MCN) roams into another MCN 4 (i.e., the visited MCN), the subscriber's MT may communicate with the visited MCN 4 to make telephone calls or establish sessions. The subscriber's MT may initiate an attach (e.g., when the MT is powered on) by sending an attach request to visited MCN 4. In response to receiving the attach request, a PSM 54 of visited MCN 4 may determine the location of the SIR 50 that stores information about the roaming subscriber. For example, the attach request may include the international mobile subscriber identity (IMSI) of the subscriber by which the PSM 54 may determine the location of the SIR 50. The PSM 54 then may communicate with the SIR 50 to retrieve information about the subscriber.

[0078] If the roaming subscriber wants to access a node 66 on PDN 6A, the subscriber initiates establishment of a data session with the node 66 through visited MCN 4, e.g., through the PSM 54. For example, the MT of the roaming subscriber may initiate the establishment of a PDP context on a PIM that provides an interface to PDN 6A.

[0079] As illustrated in FIG. 5, the home MCN 2 of the roaming subscriber may include PIM 44A (the home PIM) that interfaces to PDN 6A, and visited MCN 4 also may include a PIM 52 (the visited PIM) interfacing to PDN 6A. Thus, to establish a session between the MT of the roaming subscriber and node 66, it should be determined which PIM, home PIM 44A or visited PIM 52, is to be used to establish the session.

[0080] Accordingly, in SIR 50 (i.e., the home SIR), an entry for the roaming subscriber may include a field specifying whether to use home PIM 44A or a visited PIM to establish a session to a node of PDN 6A when the subscriber is roaming in MCN 4. Thus, during the attach process as the subscriber is roaming in the MCN 4, the PSM 54 may request profile information for the roaming subscriber from SIR 50. In response, the SIR 50 may send PSM 54 information including a value stored in such a field, and the PSM 54 may determine from such value which PIM to use to establish a session with node 66 of PDN 6A—home PIM 44A or visiting PIM 52. PSM 54 then may use the determined PIM to establish a session with node 66.

SUMMARY

[0081] A problem with existing communications networks, including MCNs, is that a subscriber does not have the ability to add value to an account for a multimedia service while the service is being provided so that the duration that the services is provided is extended.

[0082] Another problem with communications networks is that communications networks that are capable of enabling a subscriber to top-up an account for a voice service while the voice service is being provided are typically limited to the following technique: playing a voice prompt (e.g., a VRU), possibly putting the non-calling or non-billed party on hold, and allowing the calling or billed party to use DTMF tones to enter a new top-up account number or enter a credit card charge for the top-up amount. Such technique is referred to herein as “the known voice service top-up technique”.

[0083] Another problem with communications networks is that, although some communications networks are capable of notifying a subscriber that a threshold amount of a voice service has been reached during provisioning of the voice service and enabling a subscriber to top-up an account for the voice service during the provisioning such capabilities are not available for multimedia services. In an illustrative embodiment of the invention, a session is provided between a user terminal used by a subscriber and a server of a communications network providing a service to the subscriber, where the session involves the exchange of at least one of data content and video content, and the subscriber has a account balance for the service. A threshold for the service is maintained during the session, the threshold corresponding to the account balance. An amount of the service used during the session is metered, and it is determined that the threshold has been reached. The subscriber is notified through the user terminal that the threshold has been reached, and the subscriber is enabled an opportunity to add to the account balance using the user terminal.

[0084] This embodiment may be implemented as a computer program product that includes a computer-readable medium and computer-readable signals stored on the computer-readable medium, which signals define appropriate instructions. These instructions, as a result of being executed by a computer, instruct the computer to perform the acts described above for this illustrative embodiment.

[0085] In another illustrative embodiment, a system for providing a session between a user terminal used by a subscriber and a server of a communications network providing a service to the subscriber is provided, where the session involves the exchange of at least one of data content and video content, and the subscriber has a account balance for the service. The system comprises a session support module to maintaining a threshold for the service during the session, the threshold corresponding to the account balance, to meter an amount of the service used during the session, and to determine that the threshold has been reached. The system also comprises means for notifying the subscriber through the user terminal that the threshold has been reached and means for enabling the subscriber an opportunity to add to the account balance using the user terminal.

[0086] In another illustrative embodiment, the subscriber is enabled an opportunity to add to a balance for a service provided during a session between a user terminal used by a subscriber and a server of a communications network providing the service to the subscriber. Session content transmitted by the server to the user terminal as part of the session is buffered while enabling the subscriber the opportunity to add to the account balance.

[0087] In an aspect of this embodiment, after the subscriber has added to the account balance, the buffered session content is transmitted to the user terminal.

[0088] In another aspect of this embodiment, values for one or more session states for the session from a time at which the threshold was reached are maintained, while enabling the subscriber the opportunity to add to the account balance.

[0089] In yet another aspect of this embodiment, after the buffered content has been transmitted to the user terminal, the session is restored using the values suspended from when the threshold was reached.

[0090] This embodiment may be implemented as a computer program product that includes a computer-readable medium and computer-readable signals stored on the computer-readable medium, which signals define appropriate instructions. These instructions, as a result of being executed by a computer, instruct the computer to perform the acts described above for this illustrative embodiment.

[0091] In another embodiment, a system for enabling the subscriber an opportunity to add to a balance for a service provided during a session between a user terminal used by a subscriber and a server of a communications network providing the service to the subscriber is provided. The system comprises means for buffering session content transmitted by the server to the user terminal as part of the session while enabling the subscriber the opportunity to add to the account balance.

[0092] In another embodiment, a subscriber is notified that a threshold amount of service corresponding to an account balance for a service has been reached during a session between a user terminal used by a subscriber and a server of a communications network providing the service to the subscriber. The session involves the exchange in a first format of at least one of video content and audio content. The subscriber is notified that the threshold has been reached as part of the session using the at least one of video content and audio content formatted in the first format.

[0093] This embodiment may be implemented as a computer program product that includes a computer-readable medium and computer-readable signals stored on the computer-readable medium, which signals define appropriate instructions. These instructions, as a result of being executed by a computer, instruct the computer to perform the acts described above for this illustrative embodiment.

[0094] In another embodiment, a system for notifying a subscriber that a threshold amount of service corresponding to an account balance for a service has been reached during a session between a user terminal used by a subscriber and a server of a communications network providing the service to the subscriber is provided. The session involves the exchange in a first format of at least one of video content and audio content, and the system comprises means for notifying the subscriber that the threshold has been reached as part of the session using the at least one of video content and audio content formatted in the first format.

[0095] Other advantages, novel features, and objects of the invention will become apparent from the following detailed description of the invention when considered in conjunction with the accompanying drawings, which are schematic and which are not intended to be drawn to scale. In the figures, each identical or nearly identical component that is illustrated in various figures is represented by a single numeral. For purposes of clarity, not every component is labeled in every figure, nor is every component of each embodiment of the invention shown where illustration is not necessary to allow those of ordinary skill in the art to understand the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0096]
FIG. 1 is a block diagram illustrating an example a typical billing system for providing postpaid voice services;

[0097]
FIG. 2 is a block diagram illustrating a typical billing system for providing prepaid voice services;

[0098]
FIG. 3 is a block diagram illustrating an example of a typical communications network including a mobile communications network;

[0099]
FIG. 4 is a block diagram illustrating an example of a typical wireless access sub-network of a mobile communications network;

[0100]
FIG. 5 is a block diagram illustrating an example of a typical network services sub-network of a mobile communications network;

[0101]
FIG. 6 is a block and data flow diagram illustrating an example of a typical network services sub-network configured to implement Intelligent Network Services for circuit-switched voice services;

[0102]
FIG. 7 is a block and data flow diagram illustrating an example of a typical network services sub-network configured to implement Intelligent Network Services for packet-switched services;

[0103]
FIG. 8 is a block diagram illustrating an example of a mobile communications network configured to implement Intelligent Network Services and top-up/Pop-up for packet-switched services;

[0104]
FIG. 9 is a block diagram illustrating an example of a PDP context profile data structure;

[0105]
FIG. 10 is a block diagram illustrating an example of an APN profile data structure;

[0106]
FIG. 11 is a flow chart illustrating an example of a method of implementing an Intelligent Network Service and Top-up/Pop-up for a packet-switched service on a module of a mobile communications network;

[0107] FIGS. 12A-12B are a flow chart illustrating an example of a method of implementing prepaid charging and top-up/Pop-up for a packet-switched service on a module of a mobile communications network;

[0108]
FIG. 13 is a block diagram illustrating an example of PDP context access information for accessing a PDP context profile;

[0109]
FIG. 14 is a block diagram illustrating an example of an initializing packet for initializing an INS;

[0110]
FIG. 15 is a block diagram illustrating an example of prepaid charging information for a service;

[0111]
FIG. 16 is a block diagram illustrating an example of a prepaid charging report for a service;

[0112]
FIG. 17 is a block diagram illustrating an example of a system to enable a subscriber to top-up an account while the service is being provided; and

[0113]
FIG. 18 is a flow chart illustrating an example of a method for enabling a subscriber to top-up an account while the service is being provided.

DETAILED DESCRIPTION

[0114] Although some embodiments of the invention described below are described primarily in relation to mobile communications networks (MCNs), the systems and methods described herein are not limited thereto, but may be applied to other types of communications networks, including landline communications networks.

[0115] It is to be appreciated that any of the methods, techniques, systems and operating structures of the present disclosure may be embodied in a wide variety of forms and modes, some of which may be quite different than those disclosed. For example, although several embodiments are described primarily in the context of providing services for mobile terminals, these embodiments are not limited as such, as such embodiments may apply to prepaid charging for audio, video and multimedia services delivered via any access method (including fixed wireless, dial up, optical, et al). The specific structural and functional details disclosed herein are merely representative.

[0116] Although several embodiments of the invention described below are described primarily in relation to implementing prepaid charging, the systems and methods described herein are not limited thereto, but may be applied to other Intelligent Network Services (INSs), for example, the INSs described above. Further, as described above, although INSs are primarily described below as being implemented by exchanging communications with an SCF module, an INS is not limited to such implementations, as a network element such as a CSM or PIM may be configured to implement one or more INSs without consulting an SCF module or any other network elements, or by consulting one or more other network elements in addition to or as an alternative to consulting an SCF module. Such network elements may reside internal to the NSS of an MCN, or external to the NSS, for example, on a corporate LAN or the Internet.

[0117] Further, although several embodiments of the invention described below are described in relation to packet-switched services, it should be appreciated that such embodiments may be implemented for circuit-switched services as well.

[0118] In an embodiment of the invention, a subscriber of a communications network is enabled (e.g., by a node of the network) to top-up an account for a multimedia service provided on the communications network while the service is being provided. As described above, a “multimedia service” as used herein is a service that includes an exchange of data content and/or video content between two or more nodes of a communications network, and may include the exchange of any combination of video content, audio (e.g., voice) content and data content. Thus, a service that exchanges only voice content is not a “multimedia service” as used herein.

[0119] It should be appreciated that multimedia services may involve the exchange of different types of data content, video content, audio content and combinations thereof, including bulk data transfers such a file transfer using the File Transfer Protocol (FTP), transactional data transfers, persistent streaming data, multi-player gaming content, digitized video, and multimedia conferencing content. Thus, in another aspect of the invention, the unique characteristics of different types of media, such as those described immediately above, may be taken into account when considering the notification process and top-up process to be invoked when a threshold is reached.

[0120] The subscriber's account for a service may be any of a variety of types of accounts, for example, a prepaid account where a subscriber has a prepaid balance for a service and a postpaid account where a subscriber may have a spending limit (i.e., a credit limit) for a service. Such spending limit may be imposed by a provider of a service or operator of a communications network or may be defined and possibly changed by the subscriber. Thus a subscriber may be able to control the amount the subscriber is billed for a service. Although several embodiments are described below in terms of enabling a subscriber to top-up a prepaid balance, such description may be applied analogously to enabling a subscriber to change a spending limit, which is intended to fall within the scope of the invention.

[0121] As will be discussed in more detail below, an account balance may be converted into a threshold amount of service. As used herein, a “prepaid threshold” is a threshold converted from a prepaid balance and a “spending threshold” is a threshold converted from a spending limit.

[0122] In another embodiment of the invention, real-time prepaid charging is applied to a multimedia service being provided to a subscriber of a communications network. As used herein, “real-time” prepaid charging for a service means prepaid charging for the service where, during initiation of a session for the service, a subscriber's prepaid balance for the service is converted into a threshold amount of service, and the amount of service consumed by the subscriber is metered and compared to the threshold (or an amount of service derived therefrom) while the service is being provided. Such threshold amount may be a period of time and the amount of service compared to the period may be a duration of the service, or the threshold amount may be a count and the amount of service compared to the count may be a number (i.e., volume) of information units exchanged during the service.

[0123] In an aspect of real-time prepaid charging, both a count and a time period may be determined from the prepaid balance, and the number of information units exchanged during the service and the duration of the service may be compared against the count and time period, respectively. In such aspect, further processing may be defined to be performed if either and/or both thresholds are reached.

[0124] In another embodiment, a subscriber of a communications network may be notified of a threshold amount of service being reached while the service is being provided using the same session as is being used to provide the service (in-band) or using a different session (out-of-band). In an aspect of being notified out-of-band, the out-of-band notification may be sent along some or different transport path than the path on which service packets are exchanged with the user terminal to provide the service. Further, a subscriber may be notified of a threshold being reached using a Short Message Service (SMS) by sending an SMS message to the subscriber.

[0125] In another embodiment, a subscriber of a communications network may be enabled to top-up a service account while the service is being provided using the same session as is being used to provide the service (in-band) or using a different session (out-of-band).

[0126] In an aspect of enabling to top-up a service, top-up packets may be sent along a same or different transport path than the path on which service packets are exchanged with the user terminal to provide the service.

[0127] In an embodiment, to notify the client that a threshold for a service has been reached and/or to enable the client to top-up, either in-band or out-of-band sessions may be used based on any of a number of factors, including a characteristic of the session in progress implementing the service, the capabilities of the user terminal, the capabilities of the application and application server providing the service, or any combination thereof.

[0128] In an embodiment, a session for providing a multimedia service is implemented using a multimedia control protocol capable of controlling (e.g., initiating, maintaining and terminating) a session that includes the exchange of multimedia content, including audio, video, data or any combination thereof. For example, such protocol may be the Session Initiation Protocol (SIP). The SIP protocol is defined in RFC 2543, SIP: Session Initiation Protocol by Internet Engineering Task Force (IETF) as of Oct. 26, 1999. Other such multimedia control protocols may be used, including Telephony Application Programming Interface (TAPI), Telephony Server Application Programming Interface (TSAPI), H.323, Media Gateway Control Protocol (MGCP), MEGACO, Open Services Architecture (OSA), PARLAY, Java Advanced Intelligent Network (JAIN), and ad hoc IP-based protocols. In an aspect of this embodiment, the subscriber is notified in-band that a threshold amount of service has been reached and/or enabled to top-up in-band using a multimedia control protocol

[0129] In an embodiment of the invention, a subscriber of a communications network is enabled (e.g., by a node of the network) to top-up an account for a service provided on the communications network while the service is being provided using a technique other than the known voice service top-up technique described above. In one embodiment, a service on a user terminal is suspended while the top-up opportunity is provided. For example, a module of a communications network (e.g., a PIM and/or a service support module described below) may maintain session states during the session and may maintain the values of the session states at the time at which the threshold is reached. Such module may serve as a proxy for the user terminal and/or a server and be responsive to asynchronous in/band or out of band control messages, for example, in accordance with a multimedia control protocol. Implementation of such maintenance, proxying and receiving of asynchronous messages may vary based on the media content exchanged as part of the session, protocol types used to exchange the media content and techniques being utilized to suspend the session. Thus, such module may be capable of receiving a control message that causes it to begin acting as a proxy towards a user terminal and/or a server. In another embodiment, the user terminal itself may be configured with intelligence (e.g., an agent) to maintain state information for a service and exchange communications with network modules until an account for the service is topped-up. Other techniques may be used.

[0130] Such suspension of service allows a top-up opportunity to be afforded without affecting the service application or applications that are transmitting data at the point in time that a threshold amount of service is reached. This capability is useful in any number of circumstances, for example, in multi-player gaming contexts where a player may be interested in continuing a current session without having to restart the session as a result of a top-up being performed, or if a large file is being transferred to a subscriber as part of an application when a threshold is reached.

[0131] In another example of this embodiment, service content transmitted from the service provider to the subscriber on the subscriber's user terminal may be buffered (e.g., cached) in a buffer while the subscriber is provided the opportunity to top-up the account. After the subscriber tops-up or after the opportunity to top-up has elapsed, the buffered content then may be transmitted to the user terminal. While such buffered content is being transmitted from the buffer to the user terminal, any additional service content transmitted from the service provider to the end station may continue to be cached until the buffer is empty, at which point any additional transmitted service content may be transmitted (i.e., forwarded) directly to the user terminal without being buffered. In this example, the application providing the service may remain unaware that the subscriber has reached a threshold for this service, and thus continually transmit content while the subscriber is enabled the opportunity to top-up. Such technique is useful in a situation where it is not desirable to terminate a session when large volumes of content (e.g., a large data, video or multimedia file) are being downloaded such that the large content is lost and would have to be re-transmitted after another session is established (perhaps after paying a bill or adding more value to a prepaid account).

[0132] In another example of this embodiment, while the subscriber is being enabled to top-up a prepaid account for a service, a different billing method, for example, postpaid charging, is applied for the service until the subscriber tops-up or until the opportunity to top-up has elapsed.

[0133] In another example of this embodiment, as a subscriber is being enabled an opportunity to top-up, another service (e.g., a “free” Internet service) is provided for the subscriber.

[0134] In another embodiment of the invention, when a threshold amount for a prepaid service is reached, a different billing method, for example, postpaid charging, is applied for the service. As used herein, a “prepaid service” is a service for which a subscriber has subscribed for prepaid charging, or a service for which prepaid charging is applied.

[0135] One embodiment of this disclosure uses a unique addressing scheme that allows one ore more combinations of a subscriber, a session and a service to be individually identified. For example, an address of a user terminal can underpin a prepaid threshold notification and top-up process, and allow coordination between application and network layers through an Application Programming Interface. This embodiment is beneficial to effect the ability to control a session asynchronously, by providing an agreed-upon mechanism that allows a service module that initiates the top up request (e.g., the server providing the service, an SCP module, and SCF module, a service support module) to uniquely identify the subscriber, session(s) and service(s) that may be affected by this top up action.

[0136] Another embodiment provides the ability to top-up an electronic account for a service while preserving the security of access to the electronic account by accessing the account indirectly by mapping a subscriber ID (e.g., IMSI), session ID (e.g., PDP context ID) and a service ID (e.g., an APN). Such an addressing schema does not betray the identity of the subscriber or the electronic account, while allowing the electronic account to be topped up. Thus, the true identities of a subscriber (the subscriber's IMSI for example) may be hidden from the module (e.g., server) that initiated the top up action, by avoiding the need to advertise the subscriber, session or service information while preserving the ability for the top up action to be performed. Although such addressing scheme serves as a security measure, it also may protect vital identity information from being displayed to the outside world.

[0137] In another embodiment of this invention, a network operator (or another entity that provides the ability to implement topping-up for services) and a service provider may contract an agreement (“service agreement”) that defines a service to be provided to subscribers. Such agreement may specify the type of charging to be used for the service (postpaid, flat fee, real-time prepaid, hot billing, etc.) and various notification and top-up parameters for the service. One or more data structures (e.g., APN profiles, described below) stored on a tangible medium may persist the agreements and may be indexed by a service ID (e.g., APN).

[0138] In another embodiment, a subscriber may contract an agreement (“subscriber agreement”) with a network operator and/or a service provider that defines a service to be provided to the subscriber. Such agreement may specify the type of charging to be used for the service (postpaid, flat fee, real-time prepaid, hot billing prepaid, etc.) and various notification and top-up parameters for the service. One or more data structures (e.g., PDP context profiles, described below) stored on a tangible medium may persist the agreements and may be indexed by a combination of a subscriber ID (e.g., and an IMSI) and a service ID (e.g., APN) or by using a PDP Context ID.

[0139] In an embodiment, when a session is initiated for a subscriber for a service, values from a service agreement and a subscriber agreement for the service are combined. For parameters (e.g., type of prepaid charging, top-up method) for which each agreement has a value defined, one value may be defined to take precedence over the other or the values may be combined in some fashion.

[0140] In another embodiment, if a network operator already provides a prepaid charging account for voice services, the same prepaid account may be used for providing prepaid charging for multimedia services, whether circuit-switched or packet-switched. Thus, extensive investments that already have been made in systems for implementing voice services, for example, those systems used to create and distribute prepaid cards and/or top-up cards, can also be used for multimedia services.

[0141] It is to be appreciated that the ability to allow subscribers to top-up and thus continue a multimedia service is a value-added service that encourages higher spending for services by subscribers. Thus, it may be desirable for a network operator to enable the ability to top-up for multimedia services for its subscribers, so that additional revenues may be realized. For example, the network operators may charge subscribers or service providers for the added functionality, contract with service providers to share revenues derived from the added functionality, or do any combination thereof.

[0142] Further, it should be appreciated that the ability to allow subscribers to top-up and thus continue a service, including multimedia services or voice services using a technique other than the known voice service top-up technique described above adds value to any service provided on a communications network and thus encourages higher spending for such services by subscribers. Thus, it may be desirable for a network operator to enable the ability to top-up for services using any of the several new techniques described herein so that additional revenues may be realized.

EXAMPLES

[0143] Although implementing prepaid charging and Pop-up/Top-up is described below in relation to FIGS. 8-17 primarily in the context of packet-switched services, such illustrative embodiment is not meant to limit the scope of the invention, as prepaid charging and Pop-up/Top-up may be performed for other types of services as well, for example, services implemented using a virtual circuit technology such as Asynchronous Transfer Mode (ATM) technology.

[0144] Although implementing Pop-up/Top-up is described below in relation to FIGS. 8-17 primarily in the context of prepaid charging, such illustrative embodiment is not meant to limit the scope of the invention, as Pop-up/Top-up may be performed for other types of charging, for example, postpaid charging as well. For postpaid charging, a subscriber's account may have a spending limit (as opposed to a prepaid balance). This spending threshold may be converted to a spending threshold (as opposed to a prepaid threshold) that may be compared against a metered duration of a service or a metered count of information units exchanged during the session.

[0145]
FIG. 8 illustrates an example of an NSS 310 including a PIM 344A (e.g., a GGSF module) for implementing one or more packet-switched INSs. NSS 310 may include any of an SIR 150, an SCF module 148, a PSM 136A, PIM 344A and a subscriber services register (SSR) 370. NSS 310 also may include one or more CSMs, for example, CSM 34A or 134A (not shown) as well as other network elements. Each of the network elements of NSS 310 may be interconnected with other network elements by any of a variety of types of transmission media, including cables, wires, optical fibers, air, and combinations thereof. Other network elements may include switching elements, for example, transceivers, repeaters, switches, routers, bridges, and combinations thereof.

[0146] NSS 310 may be part of any of a variety of types of MCNs described above, for example, a GPRS network, a GSM/GPRS network, a UMTS network, any type of CDMA networks (e.g., cdmaOne, cdma2000, etc.), a Wireless PAN, for example, Bluetooth or a wireless PAN in accordance with IEEE 802.15, a WLAN, for example, HiperLan 2 or a WLAN in accordance with IEEE 802.11 (e.g., 802.11b (Wi-Fi), 802.11a and 802.11g), or any other type of MCN.

[0147] SIR 150, SCF Module 148 and PSM 136A may be configured similar to, and possibly the same, as described above in relation to NSS 110 of FIG. 6. The PSM 136A may be configured to exchange session packets 158 with a WASC of a WAS, and exchange session packets 160 with PIM 344A, which may be configured to communicate session packets 162 with external networks such as PDN 6A. In an embodiment, PIM 344A is a WN 1200 Intelligent Support Node available from WaterCove Networks, Inc. of Chelmsford, Mass.

[0148] SSF module 362 may be configured to exchange packets with SIR 150 in accordance with any of one or more signaling transport technologies, which may incorporate combinations of one or more protocols, for example, SS7 signaling transport technologies (e.g., MAP over Transaction Capabilities Application Part (TCAP) over Signaling Connection Control Part (SCCP) over Message Transfer Part (MTP)), SS7 over IP signaling transport technologies (e.g., as described in IEFT Request For Comments (RFC) 2719 Framework Architecture for Signaling Transport, IP signaling transport technologies (e.g., GTP over User Datagram Protocol (UDP) over IP, or Radius over TCP over IP), or other signaling transport technologies.

[0149] The SCF module 148 may include circuit-switched INS functionality 149 that defines and controls execution of one or more INSs, for example, prepaid charging, for circuit-switched voice services. For prepaid charging, the circuit-switched INS functionality 149 may include subscriber prepaid charging information such as an amount of service currently prepaid for by a subscriber. For example, a subscriber may have prepaid $4.00 for 20 minutes of service.

[0150] To implement one or more INSs, the SSF module 362 and the SCF module 148 may be configured to exchange one or more circuit-switched INS packets 147. Specifically, the SSF module 362 may be configured to exchange communications with the SCF module 148 in response to one or more triggering events, such as the initiation of a session, or the termination of a session.

[0151] SSF module 362 may be configured to exchange packets with SCF module 148 in accordance with any of one or more signaling transport technologies, which may incorporate combinations of one or more protocols, for example, SS7 signaling transport technologies (e.g., CAP over TCAP over SCCP over MTP), SS7 over IP signaling transport technologies (e.g., CAP over TCAP over S3UA over IP), IP signaling transport technologies (e.g., GTP over UDP over IP, or Radius over TCP over IP), or other signaling transport technologies.

[0152] As will be described in more detail below, a circuit-switched INS packet 147 transmitted from the SCF module 148 or the SSF module 362 may include circuit-based parameters. Accordingly, the SSF module 362 may include a packet-switched adapter 364 configured to implement an INS for packet-switched services using circuit-based parameters. Such implementation may include exchanging packets with the SCF module 148 using circuit-based parameters.

[0153] The packet-switched adapter 364 may include a conversion module 366 configured to convert circuit-based parameters to packet-based parameters and vice versa. For example, if the INS is prepaid charging, the conversion module 366 may be configured to convert a call period that specifies an amount of time prepaid for by a subscriber into a count threshold or a time threshold for a session. The count threshold may serve as a threshold for a number of information units (e.g., bytes, kilobytes, packets) transmitted during a session, as will be described below. The time threshold may serve as a threshold amount of time of a session. The conversion module 366 also may be configured to convert the count threshold or time threshold back into a call period. Such conversions are described below in more detail.

[0154] In an embodiment, the PDN interface module 344A may be logically and/or physically divided into two modules, a service support module 361 and a session support module 363. Service support module 361 may be configured to manage coordination between session layers and service layers of a service and to assist in implementing INSs, and thus module 361 may include SSF module 362. Service support module 361 may include additional logic to assist implementing services using PDP context profiles and APN profiles including handling requests to operate PDP contexts, discussed below in more detail in relation to FIGS. 9 and 10.

[0155] In an embodiment of NSS 310, one or more service support modules 361 and session support modules 363 may reside on separate nodes of NSS 310.

[0156] The session support module 363 may include flow control functionality, session control functionality and functionality for metering a session between a subscriber and a node of a PDN.

[0157] The session support module 363 may include a metering module 365, which may be configured to meter a session between a subscriber and a node of a PDN. Metering a session may include determining a number of information units (e.g., transactions, packets, kilobytes, bytes) exchanged between the subscriber and the PDN node during the session, metering a duration of the session or any combination thereof. The SSF module 362 may be configured to control such metering and to report the results of such metering to the SCF module 148.

[0158] PIM 344A (e.g., service support module 361) may be further configured to exchange communications with application servers located external to NSS 310, for example, on PDN node 66, to establish an initial time or count (i.e., volume) threshold for a service. For example, PIM 344A may be configured with one or more application programming interfaces (APIs) that enable such configuration. Accordingly, PIM 344A may be configured to notify an application residing on an application server when a threshold amount has been consumed by a session. This ability to associate a service with a session and a subscriber may be accomplished by defining one or more elements of NSS 310, as will be discussed in more detail below.

[0159] Further, PIM 344A (e.g., service support module 361) may be configured with one more APIs that interface that exchange communications with servers located external to the NSS 310 to provide the pop-up/top-up capability described in more detail below. Thus, to provide a pop-up notification, enable a top-up opportunity and to implement interim operations while the top-up opportunity is being enabled (as described below in more detail in relation to acts 819-824 of method 800 and FIGS. 17 and 18), PIM 344A may exchange communications with one or more application servers. Further, PIM 344A may be configured to exchange communications with any applications that may be affected by a threshold amount corresponding to a subscriber account balance or spending limit being reached. Thus, when such a threshold is reached, PIM 344A may send notications to such applications.

[0160] Configuring the SSF module 362 with packet-switched adapter 364 as described above may obviate a need to configure the SCF module 148 with packet-switched INS functionality (e.g., functionality 249 described above in relation to FIG. 7) in order to implement an INS. For example, if an SCF module 148 is configured to implement prepaid charging in accordance with CAMEL Phase 2 for circuit-switched voice services, the SCF module 148 does not need to be upgraded or replaced in order to implement prepaid charging in accordance with CAMEL Phase 3 for packet-switched services. The packet-switched adapter 364 may be configured to implement the prepaid charging in accordance with CAMEL Phase 3 using the CAMEL Phase 2 parameters included in the prepaid charging packets transmitted from the SCF module 148. For example, the conversion module 366 may be configured to convert the CAMEL Phase 1 or 2 prepaid charging parameters (e.g., call period) to CAMEL Phase 3 prepaid charging parameters (e.g., count or time thresholds), and vice versa. The capability of the conversion module 366 to convert CAMEL Phase 3 prepaid charging parameters into CAMEL Phase 2 prepaid charging parameters, and vice versa, enables the SSF module 362 to exchange prepaid charging packets with the SCF module 148 in accordance with CAMEL Phase 2.

[0161] The SSF module 362 also may be configured to exchange packet-switched-INS packets with SCF module 148 if SCF module 148 is configured with packet-switched INS functionality. Further, the SSF module 362 may be configured to selectively exchange circuit-switched or packet-switched INS packets with SCF module 148, for example, in accordance with CAMEL Phase 1, 2 or 3, respectively, depending upon the capabilities of the SCF module 148.

[0162] Although SSF module 362 has been illustrated in relation to FIG. 8 as being part of PIM 344A, alternatively, SSF module 362, including packet switched adapter 364 and conversion module 366, may be configured as part of PSM 136A or another network element. Further, SSF module 362 may be distributed across a plurality of network elements. Communications exchanged between SSF module 362 and SCF module 148 are described in more detail below.

[0163] SSR 370 may include subscriber services information 371. For each subscriber, information 372 may include information about one or more services, including subscriber packet-switched-INS information 372 for packet-switched INSs to which the subscriber is registered. For each such packet-switched INS to which the subscriber is registered, information 372 may include an identity of the SCF module (e.g., SCF module 148) to be used to implement the INS, triggering events in response to which an SSF should initiate communications with the appropriate SCF module, and other information. At least some of this other information may be used by the SSF module 362 to implement an INS for a packet-switched service using circuit-switched INS packets 147 exchanged with SCF module 148.

[0164] Subscriber services information 371 also may include information about one or more services provided by service providers from servers located external to NSS 310, for example, on PDN node 66. For example, information 371 may include at least one of a subscriber agreement (e.g., a PDP profile data structure 1000) and a service agreement (e.g., an APN profile data structure 1100), each of which is described in more detail below.

[0165]
FIG. 9 is a block diagram illustrating an example of a PDP context profile data structure 1000 that includes one or more PDP context profiles 1001, each profile 1001 including one or more information elements (IEs). Each profile 1001 may define a subscriber's subscription to a specific service, and thus may serve as a link between the subscriber's subscription to the MCN and the subscriber's subscription to a service offered by the service provider. An APN profile 1101, described below in relation to FIG. 10, defines a service agreement between the MCN of NSS 310 and a service provider, values for which may be overridden or combined with values specified by a PDP context profile 1001 defined for a specific subscriber. Thus, each profile 1001 includes subscription information for a particular subscriber for an APN, from which a PDP context session may be generated. Data structure 1000 may be any of a variety of types of data structures, including an object, a table, or a plurality of records separated by delimiters. Other types of data structures may be used also.

[0166] The PDP context profile 1000 may include any of: subscriber ID IE 1002, MT ID IE 1004, PDP context ID IE 1006, PDP type IE 1008, APN IE 1010, QoS profile IE 1012, INS subscription information TE 1013, charging type 1014, calling party number IE 1015, called party number IE 1016, charging rate modifier IE 1018, and possibly other IEs.

[0167] The subscriber ID IE 1002 uniquely identifies the subscriber, and may serve as a key or index for the PDP context profile 1001 along with APN IE 1010. Depending on the type of MCN, the IE 1002 may specify an IMSI or another type of unique identifier of a subscriber.

[0168] The MT ID IE 1004 identifies the MT (moibile terminal) for which this PDP context profile applies. Depending on the type of MCN, the IE 1004 may specify an MSISDN or another type of unique identifier of an MT. IE 1006 is a unique identifier for the PDP context profile and may serve as a key or index for the PDP context profile 1001. IE 1008 identifies the type of PDP, for example, IP or Point-to-Point Protocol (PPP).

[0169] IE 1010 specifies an APN for which the profile 1001 is defined. IE 1010 may serve as an index to an APN profile 1101. IE 1012 specifies the quality of service subscribed to by the subscriber for this PDP context.

[0170] IE 1013 specifies information about one or more INSs subscribed to by the subscriber for this PDP context. For example, E 1013 may include information about prepaid charging, including the location of the SCF module to be used to implement prepaid charging, for example, an IP address or other type of location identifier of SCF module 148.

[0171] IE 1014 specifies the type of charging subscribed to by the subscriber for this PDP context. Types of charging may include, but not be limited to, postpaid charging, flat-rate charging, hot billing or real-time prepaid charging. Postpaid charging is a type of charging for which a subscriber receives the service first, and then pays for the service periodically, for example, monthly. For each session or telephone call across an MCN for postpaid charging, an operator generates a Call Detail Report (CDR), and consolidates these CDRs to generate the periodic bill. Thus, if a subscriber makes five telephone calls during a month, an operator may generate five CDRs from which a monthly bill is generated.

[0172] As described above, prepaid charging means that an amount of service is paid for in advance of the service being provided. Real-time prepaid charging also is defined above.

[0173] Another type of prepaid charging is “hot billing”, which some MCN operators provide to attempt to emulate some of the capabilities of real-time prepaid charging. Hot billing is implemented by generating CDRs at periodic intervals throughout a session or telephone call. The smaller such an interval is configured, the less amount of time a subscriber is able to exceed a threshold amount of service, and the closer hot billing emulates the ability of real-time prepaid charging to prevent a subscriber from exceeding a threshold amount of service. Each time a CDR is generated, the CDR may be reported to a billing module (e.g., charging gateway 45 of FIG. 5), which typically resides on a network node separate from the node on which the metering occurs, and further instructions may be awaited from the billing module. For example, a PSM may generate a CDR every five minutes for a session on an MCN, and report the CDR to a billing module presiding on another node of the MCN. The billing module then may determine if the subscriber has enough credit or a plan that enabled the subscriber to continue the session. The billing module then may send the PSM instructions regarding whether to terminate the session or continue.

[0174] A problem with hot billing is that a subscriber may be able to use a service beyond that for which the subscriber has paid or contracted. For example, if the subscriber has 55 minutes and 1 second of credit remaining in their account, and CDRs are being generated every five minutes, then after the eleventh CDR, the billing module will allow the subscriber to continue a session or telephone call for an additional five minutes, thereby allowing the subscriber four minutes and 59 seconds of extra use.

[0175] Further, although the ability to obtain such extra use may be reduced by reducing the CDR-generation interval, such reduction results in more CDRs being generated, thereby increasing the traffic load of the MCN.

[0176] IE 1014 further may specify different types of prepaid charging. For example, IE 1014 may specify a typical type of packet-switched pre-paid charging such as CAMEL Phase 3 on a GPRS, GMS/GPRS or UMTS network. Alternatively, IE 1014 may specify a type of prepaid charging where the SSF module communicates with the SCF module in accordance with circuit-switched voice prepaid charging, but the SSF module implements prepaid charging in accordance with packet-switched prepaid charging. This type of prepaid charging may be referred to herein as packet/circuit-switched prepaid charging. For example, IE 1014 may specify that the SSF module communicates with the SCF module in accordance with CAMEL Phase 2, and that the SSF module implements prepaid charging in accordance with CAMEL Phase 3. Further, for such CAMEL Phase 2/Phase 3-type prepaid charging, IE 1014 may specify whether this type of prepaid charging meters the duration of the PDP context session or meters a number of information units transmitted during the PDP context session.

[0177] PIM 344A may be configured to implement one or more types of charging for a packet-based service, including postpaid charging, flat-rate charging, hot billing, one or more types of prepaid charging and other types of charging, IE 1015 specifies a calling party number for the PDP context. IE 1015 may map a telephone number to a PDP context session, and can be useful for packet/circuit-switched prepaid charging. For example, for a given subscriber, circuit-switched INS functionality 149 may include a phone number associated with the subscriber, but may not have the capability of associating a PDP context session with the subscriber Consequently, if the SSF module 362 attempts to access the circuit-switched INS functionality 149 using a PDP context ID, the SCF module 148 will not understand the PDP context ID.

[0178] Associating a calling party number with a PDP context session enables the SSF module 362 to specify a telephone number to the SCF module 148 when attempting to initiate use of an INS. The SCF module 148 then can recognize the telephone number and be able to control implementation of the INS. Thus, by mapping a telephone number to a PDP context session, the SCF module 148 does not need to be configured (e.g., updated or replaced) to recognize a PDP context ID.

[0179] In some cases, the calling party number may be a telephone number already associated with a subscriber. For example, if the MCN is a GSM/GPRS network, the calling party number may be the telephone number assigned to the subscriber and stored in an MSC of the GSM network.

[0180] IE 1016 specifies a called party number for the PDP context. As will be described below in relation to IE 1104 of an APN profile 1101, IE 1104 may specify a called party number that defines a default charging plan for an APN to be used for any PDP context session that uses the service defined by the APN. Such a called party number may enable an SCF module configured to implement prepaid charging for circuit-switched voice services to associate a charging plan with a PDP context session. IE 1016 specifies a called party number that may be associated with a specific subscriber that overrides the called party number associated with the APN specified by IE 1010. The ability to associate a called party number with a specific subscriber enables a charging plan to be associated with particular subscriber when the subscriber establishes a PDP context session with a node of a PDN.

[0181] IE 1018 specifies a charging rate modifier for a PDP context. This charging rate modifier enables customizations for a particular subscriber of a generic charging plan associated with an APN.

[0182] PDP context profile data structure 1000 may include additional information elements that store values corresponding to the values stored in IEs 1116 and 1118 of APN profile data structure 1100 described below in relation to FIG. 10. The value of these IEs of data structure 1000 may override, be combined with or be overridden by the corresponding values stored in IEs 1116 and 1118.

[0183]
FIG. 10 is a block diagram illustrating an example of an APN profile data structure 1100 for an APN configured for prepaid charging. Data structure 1100 may include one or more APN profiles 1101, each profile 1101 including one or more IEs. Data structure 1100 may be any of a variety of types of data structures, including an object, a table, or a plurality of records separated by delimiters. Other types of data structures also may be used.

[0184] An APN profile 1101 may define an access agreement between the MCN of NSS 310 and a PDN (e.g., PDN 6B). Profile 1101 may define access points (e.g., port addresses of a PIM) that serve as interfaces between NSS 310 and one or more PDNs, and also may define, for an APN, one or more access methods (e.g., open IP, tunneled, encrypted, etc.) that may be used by the interfaces.

[0185] One or more of the information elements of an APN profile 1101 may define values of service parameters for a service provided to subscribers of the MCN of NSS 310. Some of these values may be defined to be overridable by values of the service parameters specified for a specific subscriber as defined in corresponding PDP context profile 1001. Other values may be defined so that they cannot be overridden by values specified for a subscriber, and other values may be defined to be combined (e.g., aggregated) in some fashion with values defined for a subscriber.

[0186] Each entry 1101 may include an APN IE 1102, a called party number IE 1104, a tariff switch time E 1106, a time-to-count conversion ratio IE 1107, a count metering unit IE 1108, a time-based reporting IE 1110, a count metering downlink/uplink ratio E 1112, a port address list IE 1113, a charging-type IE 1115, an APN profile distribution IE 1114 a top-up opportunity IE 1116, pop-up/top-up information IE 1118 and one or more other IEs.

[0187] IE 1102 specifies an APN, and may be used as a key for an APN profile 1101.

[0188] IE 1104 specifies a called party number associated with the APN. An SCF module 148 may not be configured to associate an INS with an APN; however, an SCF module 148 may have the ability to associate a telephone number with an INS. For example, circuit-switched INS functionality 149 may recognize a telephone number for a subscriber associated with an INS. Accordingly, called party number 1104 may be used to map a telephone number to the APN specified in IE 1102. Thus, when SSF module 362 attempts to initiate an INS with SCF module 148 for a packet-switched service using the APN, SSF module 362 may specify the telephone number defined by IE 1104. Accordingly, the SCF module 148 can control implementation of the INS using a telephone number, and the SSF module can map this telephone number to the APN specified by IE 1102.

[0189] IE 1106 specifies a tariff switch time associated with prepaid charging for this APN. A tariff switch time is used for circuit-switched voice prepaid charging to specify a time at which a charging rate changes for an APN. For example, a charging plan associated with the APN may specify that before 8:00 p.m. a first rate applies, but after 8:00 p.m. a second rate applies.

[0190] If the type of prepaid charging specified by IE 1014 is time-based prepaid charging, then IE 1106 may be used to determine when a report is to be transmitted from an SSF module to an SCF module so that the SCF module may determine a new time threshold based on the prepaid amount and new charging rate. If the type of prepaid charging is count-based prepaid charging, the tariff switch times specified by IE 1106 may be used by an SSF module to recalculate a count threshold based upon a prepaid amount and new charging rate, as will be described below in more detail in relation to FIGS. 12A and 12B.

[0191] IE 1107 may specify a time-to-count conversion ratio to be applied to convert a call period to a count and vice versa for the APN specified by IE 1102. For example, IE 1107 may specify a ratio for converting minutes or seconds to a count corresponding to a number of information units, e.g., packets, kilobytes or bytes. Other conversion ratios and units may be used.

[0192] Count metering unit 1108 specifies the information unit to be used to meter the number of information units exchanged of a PDP context session, for example, byte, kilobyte, packet, transaction, or other information unit.

[0193] IE 1110 may specify whether time-based reporting is to be used between an SSF module and an SCF module for a PDP context session of the APN for which count-based prepaid charging has been defined. In other words, although the number of exchanged information units may be metered for a PDP context session, as opposed to metering the duration of the PDP context session, an SSF module may still report usage to an SCF module at predetermined time intervals, so that the SCF module can receive up-to-date usage information. Such up-to-date usage information may be desirable for long PDP context sessions with relatively low data traffic. For example, the tariff switch time specified by IE 1106 may be used as an interval at which to report to the SCF module the amount of time used (where this amount of time has been converted from the number of information units exchanged). It may be desirable to use the tariff switch time for the reporting interval because the charging rate may change after the tariff switch time has elapsed, and the SCF module may be configured to provide updated information to the SSF module in accordance with the change of charging rate.

[0194] IE 1112 specifies a count metering downlink/uplink ratio to be applied to a count threshold. The term “uplink” as used herein refers to a direction of transmission of a packet exchanged as part of a PDP context session, where the packet originated from the MT of the subscriber for which the PDP context session is being implemented. As used herein, the term “downlink” refers to a direction of transmission of a packet exchanged as part of a PDP context session, where the packet is to be terminated at the MT of the subscriber for which the PDP context session is implemented. Thus, the count metering downlink/uplink ratio specifies the ratio of downlink packets of the PDP context session to uplink packets of the PDP context session. The SSF module 362 may be configured to apply this ratio in allocating downlink and uplink information units to a downlink count threshold and an uplink count threshold, respectively, and then separately meter the number of downlink information units and the number of uplink information units and compare each number to the appropriate count threshold. In response to the downlink count threshold or the uplink count threshold being reached, the SSF module may be configured to re-allocate the remaining information units between a new downlink count threshold and a new uplink count threshold.

[0195] IE 1113 may list one or more port addresses (i.e., IP addresses) that have been provisioned to support the APN specified in IE 1101. Each port address may correspond to a port of a PIM (e.g., PIM 344A) of NSS 310.

[0196] IE 1115 specifies a charging-type to be used for the APN specified by IE 1101. in some cases, the value for the charging type may be overridden by the charging-type specified in IE 1014 for a specific subscriber. The value stored in IE 1115 may determine whether or not the value itself can be overridden by IE 1014. For example, IE 1115 may specify an all-prepaid charging type (e.g., real-time prepaid or hot billing) that defines that any PDP context session for the APN will have prepaid charging applied, regardless of the value specified in IE 1014 for a subscriber. IE 1115 also may specify an all-postpaid charging type that specifies that any PDP context session established for this APN will have postpaid charging applied, regardless of the value specified by IE 1014 for a specific subscriber. IE 1115 also may specify a combined charging type that indicates that the charging type will be determined by IE 1014 for each subscriber that uses the service represented by the APN defined by IE 1101. IE 1115 may specify other charging types as well.

[0197] IE 1114 specifies an APN profile distribution for the APN profile 1101. For example, although a particular network element of the NSS 310, for example, SSR 370, may be the primary location at which the APN profile 1101 is stored persistently, the APN profile 1101 may be distributed or provisioned to one or more other network elements of NSS 310. For example, APN profile 1101 may be provisioned to SSF module 362. Further, the complete APN profile data structure 1100 may be provisioned to one or more other network elements such as SSF module 362. Further, the PDP context profile data structure 1000, and/or one or more PDP context profiles 1001 thereof, also may be provisioned to one or more networked elements of NSS 310, for example, SSF module 362. In a case where a PDP context profile 1001 and/or an APN profile 1101 are stored on the SSF module, then, in response to a request to establish a PDP context session for the PDP context profile, the SSF module may not have to exchange communications with the SSR 370 to obtain the PDP context profile and/or a corresponding APN profile to establish the PDP context session. Storing a PDP context profile and/or an APN profile on the SSF module 362 prior to reception of a PDP context request may be referred to herein as “static provisioning.” Provisioning a PDP context profile or an APN profile to an SSF module in response to a request to establish a PDP context session may be referred to herein as “dynamic provisioning.” IE 1114 may specify whether static provisioning or dynamic provisions is to be used for the APN of APN profile 1100.

[0198] IE 1116 stores a value that indicates whether a top-up opportunity is to be provided for this service for subscribers. If the value stored in E 1116 indicates that a top-up opportunity is not to be provided for this service, then when a threshold amount of service is reached while the service is being provided, the service may either be terminated or continued without the subscriber having an opportunity to add value to an account balance for the service. If IE 1116 indicates that a top-up opportunity is to be enabled for a subscriber while the service is being provided, then the subscriber may be enabled an opportunity to top-up an account (e.g., postpaid or prepaid) for the service and thereby continue the service. A PDP context profile 1001 may have an information element corresponding to IE 1116 that enables a subscriber to define whether a top-up opportunity will be afforded (e.g., as part of the subscribers' subscription for the service). The value of this information element may override, be combined with or be overridden by the value defined for IE 1116.

[0199] IE 1118 may store values defining pop-up/top-up information for notifying subscribers that a service threshold has been reached and enabling subscribers an opportunity to top-up an account if IE 1116 indicates a such opportunity should be afforded. IE 1118 may store several values for parameters (or APN Profile 1100 may include several information elements) that control how a pop-up notification will be performed and how a top-up opportunity will be enabled for a service. For example, IE 1118 may include parameters for any of the following: one or more multimedia control protocols to be used for a pop-up notification; one or more multimedia control protocols to be used for a top-up opportunity; whether in-band or out-of band session is to be used for a pop-up notification; whether in-band or out-of band session is to be used for a top-up opportunity; whether a same or different transport path is to be used for a pop-up notification; whether a same or different transport path is to be used for a top-up opportunity; the duration for which a top-op opportunity is enabled; the type of interim processing to be performed during a top-up opportunity; interim processing information; and other parameters. The uses of these parameters for pop-up notifications and/or enabling top-up opportunities are described below in more detail in relation to Act 826 of method 800.

[0200] Returning to FIG. 8, it should be noted that SSR 370 may be included in its entirety as part of PIM 344A. Further, at least a portion of SSR 370 may be included in SIR 150. For example, at least a portion of subscriber services information 371, which may include one or more PDP context profiles 1001 and/or one or more APN profiles 1101, may be included as part of SIR 150.

[0201] In response to a subscriber attempting to initiate a session for a service, service support module 361 of PIM 344A may download (if not already stored on PIM 344A), from the SSR 370, service information 374, which may include the subscriber packet-switched INS information 372 along with other subscriber services information 371. Subsequently, in response to a triggering event for a service (e.g., a time or volume threshold being reached, a tariff switch time, or a termination of the session), the SSF module 362 may initiate communications with the SCF module 148 in accordance with information 374 to request and receive instructions and information relating to the triggering event.

[0202] SSF module 362 may be configured to communicate with the SCF module 148 to implement prepaid charging for a packet-switched service provided by a node of a PDN. For example, in response to PIM 344A receiving a request to establish a PDP context session from a subscriber, the SSF module 362 may send a circuit-switched-INS packet 147 to SCF module 148 to request INS instructions and information for the session. The circuit-switched INS functionality 149 may determine the instructions and information, and the SCF module 148 may send a circuit-switched-INS packet 147 including such instructions and information to the SSF module 362.

[0203] If the INS is prepaid charging, the packet 147 sent by the SCF module 148 may include information for implementing prepaid charging. The SSF module 362 may be configured to receive such information and to implement prepaid charging accordingly. Further, the SSF module 362 may be configured to communicate with the SCF module 148 throughout the session in response to one or more other triggering events and/or at predetermined intervals.

[0204] SSF module 362, SCF module 148 and SSR 370 may be configured to exchange communications and implement an INS as described below in relation to FIGS. 11, 12A and 12B, including exchanging information described in relation to FIGS. 13-16.

[0205] In an embodiment, NSS 310 includes a server-based application that includes the service intelligence and logic to enable network operators to develop, deploy, manage, and provision INSs while containing operational costs. Such server-based application, and portions thereof, may reside on one or more of the modules (e.g., 362, 148, 150 and 370) of NSS 310. In an embodiment, such server-based application is the Senteon Service Core available from WaterCove Networks, Inc. One or more nodes of the MCN illustrated in FIG. 8, including one or more MTs such as 18A, may be configured with a client side of such server application.

[0206] NSS 310, and components thereof such as registers 150 and 370 and modules 136A and 344A, may be implemented using software (e.g., C, C++, Java, or a combination thereof, hardware (e.g., one or more application-specific integrated circuits), firmware (e.g., electrically-programmed memory) or any combination thereof. One or more of the components of NSN 310 may reside on a single machine (e.g., a node of NSN 310), or each component may reside on a different machine. Further, each component may be distributed across multiple machines, and one or more of the machines may be interconnected.

[0207] Further, on each of the one or more machines that include one or more components of NSN 310, each of the components may reside in one or more locations on the machine. For example, different portions of the components 136A, 150, 344A and 370 may reside in different areas of memory (e.g., RAM, ROM, disk, etc.) on the machine. Each of such one or more machines may include, among other components, a plurality of known components such as one or more processors, a memory system, a disk storage system, one or more network interfaces, and one or more busses or other internal communication links interconnecting the various components.

[0208] In an embodiment, NSS 310 may be implemented in accordance with the Mobile Data Service System and/or the FlowCore System Architecture developed by Watercove Networks, Inc of Chelmsford, Mass., as described in more detail at http://www.watercove.com. The Mobile Data Service System and Flowcore are described in more detail in Purpose-Built Architecure Required for Mass-Market Deployment of Personalized Data Services and Exploiting the Opportunities for Personalized Mobile Data Services, whitepapers available from WaterCove Networks, Inc. of Chelmsford, Mass. at: http://www.watercove.com/pdf/Purpose.pdf and http://www.watercove.com/pdf/Opportunities.pdf, respectively, the entire contents of both of which are hereby incorporated by reference.

[0209] NSS 310 is an illustrative embodiment of an NSS for implementing a packet-switched INS and Pop-up/Top-up for packet-switched services on an MCN. Such an illustrative embodiment is not meant to limit the scope of the invention and is provided for illustrative purposes, as any of a variety of other NSSs for implementing INSs and Top-up/Pop for packet-switched services on an MCN, for example, variations of NSS 310, may fall within the scope of the invention.

[0210] 2. Implementing Prepaid Charging and Pop-Up/Top-Up for Packet-Switched Services FIG. 11 is a flowchart illustrating an example of a method 700 for implementing an INS for packet-switched services on a module of an MCN. Such a module may be a PIM such as PIM 344A or a PSM.

[0211] In Act 702, the execution of an INS for a packet-switched service is initiated. For example, a request may be received to create a PDP context session for a packet-switched service between a subscriber of the MCN and a node of a PDN.

[0212] In response to receiving the request, a SSR, for example, SSR 370, may be accessed to determine if the subscriber subscribes to one or more INSs. For example, SSF module 362 may receive a session packet 160, and, in response, service support module 361 may access SSR 370, which may access subscriber packet-switched-INS information 372 to determine INSs, if any, to which a subscriber is subscribed. The subscriber packet-switched-INS information 372 also may indicate the identity and location of an SCF module to exchange communication with to implement an INS. The SSR 370 may specify this information in service information 374 sent to the SSF module 362.

[0213] If the subscriber is subscribed to an INS, an initiating packet may be sent to an SCF module corresponding to the INS to initiate the INS for the requested PDP context session.

[0214] Next, in Act 704, information for the INS may be received from the SCF module.

[0215] In a following Act 706, the INS may be implemented using the received information. Further, additional packets may be exchanged between the PIM and SCF module throughout the implementation of the INS, for example, in response to a triggering event. Optionally, these packets may be exchanged in accordance with a protocol for implementing the INS with circuit-switched voice parameters, and the PIM may be configured to convert the circuit-based parameters to packet-based parameters and vice versa.

[0216] In a following act 708, the INS may be terminated. For example, the INS may be terminated in response to an action by the subscriber or another party to the session or may be terminated in accordance with the INS.

[0217] Method 700 is an illustrative embodiment of a method of implementing an INS for packet-switched services on a PIM of an MCN. Such an illustrative embodiment is not meant to limit the scope of the invention and is provided for illustrative purposes, as any of a variety of other methods of implementing an INS for packet-switched services on a PIM of an MCN, for example, variations of method 700, may fall within the scope of the invention.

[0218] FIGS. 12A-12B are a flow chart illustrating an example of a method 800 of implementing prepaid charging and Top-up/Pop-up for packet-switched services on module of an MCN. Such module may be a PIM such as PIM 344A or a PSM such as PSM 136A. Although method 800 is described below primarily in relation to implementing prepaid charging, other INSs may be implemented using such a method or a variation thereof.

[0219] In Act 802, a request to create a PDP context session for a packet-switched service between a subscriber and a node of a PDN may be received. For example, referring to FIG. 8, a subscriber 17A using an MT 18A may transmit a PDP context request to PSM 136A, which forwards the request to PIM 344A. The PDP context request may include PDP context access information 900 illustrated in FIG. 13.

[0220] Such information 900 may include one or more information elements (IEs) including subscriber ID IE 902, APN IE 904 and PDP Type IE 906. The subscriber ID IE 902 may specify the IMSI or another unique identifier of the subscriber that originated the request. APN IE 904 may specify the APN for the requested PDP context session. Such APN may be a label in accordance with known DNS naming conventions. The PDP Type IE 906 may specify the type of packet data protocol for the requested PDP context session, for example, IP or PPP.

[0221] The combination of subscriber ID IE 902 and APN IE 904 may be used to index the appropriate PDP Context Profile 1001 from PDP context profile data structure 1000, described above in relation to FIG. 9.

[0222] In Act 804, it may be determined whether a subscriber subscribes to prepaid charging for the packet-switched service for which a PDP context session is requested. For example, service support module 361 may send a packet to SSR 370 that includes at least IEs 902 and 904 of PDP context access information 900 to determine whether the subscriber subscribes to prepaid charging for the APN specified in the PDP context request. The SSR 370 may access subscriber service information 371 to determine whether the information 371 includes an entry (e.g., a PDP Context Profile 1001) for the specified subscriber and APN. If the information 371 does not include an entry for the specified APN, the SSR 370 may send service information 374 to the service support module 361 indicating that it does not include any information pertaining to prepaid charging. Further, information 374 may indicate that the subscriber is not registered for the requested packet-switched service at all.

[0223] If the subscriber service information 371 does include an entry for the specified APN for the subscriber (e.g., a PDP context profile 1001), the service information 374 may include information pertaining to prepaid charging. For example, service information 374 may include one or more (e.g., all) of the IEs of a PDP context profile 1001 corresponding to the subscriber ID and APN specified in PDP context access information 900 transmitted from SSF module 362 to SSR 370. Further, the INS information 374 also may include any of the IEs included in an APN profile 1101 corresponding to the APN specified in information 900.

[0224] As discussed above in relation to IE 1114, an APN may be defined such that the APN is dynamically distributed to one or more elements, for example PIM 344A, of NSS 310. Accordingly, service support module 361 may perform Act 804 without accessing SSR 370 if the specified PDP context profile and/or APN profile have been dynamically distributed to service support module 361 before the request is received in Act 802.

[0225] In Act 804, if it is determined that the subscriber does not subscribe to prepaid charging for the packet-switched service, then prepaid charging may not be implemented for the packet-switched service.

[0226] In Act 804, if it is determined that the subscriber subscribes to prepaid charging for the packet-switched service, then, in Act 806, an initializing packet may be sent to an appropriate SCF module (e.g., SCF module 148) to initiate prepaid charging for the PDP context session.

[0227] For example, SSF module 362 may send initializing packet 1200, illustrated in FIG. 14, to SCF module 148. Initializing packet 1200 may include any of the following IEs: INS ID IE 1202; called party number IE 1204; calling party number IE 1206; subscriber ID IE 1208; and one or more other IEs.

[0228] IE 1202 specifies an ID for a set of one or more INSs, which may include prepaid charging, for which the SSF module is requesting implementation. The SCF module may be configured to implement a plurality of INSs, and IE 1202 enables the SCF module to select one or more of the plurality of INSs to implement for the SSF module.

[0229] IE 1204 specifies a called party number to used by the SCF module to access the INS subscription information specific to the subscriber for the INS. As discussed above in relation to IEs 1016 and 1104, the called party number may specify a telephone number for the subscriber which is mapped to an APN corresponding to the PDP context session. IE 1206 specifies a calling party number that specifies the subscriber to the SCF module 148. As described above in relation to IE 1015 of a PDP context profile 1001, if an SCF module such as SCF module 148 is not capable of recognizing a PDP context identifier, then the calling party number may specify a telephone number associated with the subscriber initiating implementation of the INS. IE 1015 maps this telephone number to a PDP context 10 profile 1001 corresponding to a subscriber. If the NSS 310 is an NSS on which both package-switched services and circuit-switched voice services can be implemented (e.g., a GSM/GPRS network), the telephone number specified by the calling party number 1206 may be a telephone number already assigned to the subscriber for circuit-switched voice services.

[0230] IE 1208 specifies an ID for a subscriber, for example, an IMSI. Returning to method 800, in Act 808, prepaid charging information may be received from the SCF module.

[0231]
FIG. 15 is a block diagram illustrating an example of prepaid charging information 1300 that may be transmitted from an SCF module to an SSF module as part of implementing an INS for a PDP context session. The prepaid charging information 1300 may include one or more of the following IEs: call period duration IE 1302; release IE 1304; notify subscriber IE 1306; party to charge IE 1308; tariff switch interval IE 1310; top-up opportunity IE 1312; pop-up/top-up information IE 1314; and one or more other IEs.

[0232] IE 1302 may specify a call period duration for the PDP context session in accordance with the amount of service prepaid for by the subscriber. IE 1304 is a flag that may specify whether to terminate (i.e., release) the PDP context session if the call period (i.e., the number of information units or elapsed time converted from the call period) has expired. The value stored in IE 1302 may be related or depend on one or more values stored in IEs 1312 and 1314, as will be described below in more detail.

[0233] IE 1306 specifies whether to notify the subscriber that the threshold has been reached before terminating the PDP context session. IE 1306 may be used if IE 1304 indicates to terminate the PDP context session in the event that the call period has expired. If IE 1306 indicates to notify the subscriber, then the service support module 361 may be configured to notify the MT of the subscriber using video content, audio content, data content or a combination thereof, and the MT may be operative to play a sound, play an audio or video message, display a visual message or in some other fashion notify the subscriber that the threshold has been reached. Further, the SSF module and the MT may be operative to allow a subscriber a certain amount of time during which to top-up before terminating the PDP context session, as described in more detail below.

[0234] The SSF module may send such notification at a predetermined amount of time before the actual PDP context session is terminated, for example, 30 seconds before a PDP context session is terminated. Thus, the SSF module may be configured to recognize when the number of information units or amount of time remaining for the PDP context session is equivalent to an amount of time (e.g., 30 seconds) before the call period would expire, and to notify the subscriber of the imminent termination in response to such recognition. The value stored in IE 1306 may be related or depend on one or more values stored in IEs 1312 and 1314, as will be described below in more detail.

[0235] IE 1308 may specify a party to charge for the PDP context session. For example, IE 1308 may specify the subscriber's IMSI or another identifier of the subscriber. Further, IE 1308 may specify another party associated with the subscriber for which to charge. The value specified by IE 1308 should match the value specified by IE 1406 discussed in more detail below in relation to FIG. 16.

[0236] IEs 1310, 1312 and 1314 may contain information defined in IEs 1106, 116 and 1118, respectively, of an APN profile 1100 for the service being provided, and may be combined with or overridden by information defined in corresponding IEs of a PDP context profile 1000 for the subscriber and service.

[0237] In Act 810, it may be determined whether the subscriber has a sufficient prepaid balance for the requested packet-switched service. For example, the prepaid charging information received in Act 808 may indicate that the subscriber does not have a required minimum balance in the subscriber's prepaid account for the service associated with the PDP context session.

[0238] Returning to method 800, in Act 810, if it is determined that the PDP context session is not to be terminated, then in Act 812 the call period may be converted to a count threshold or elapsed time threshold for the PDP context session. The SSF module may use a variety of techniques for converting the call period. If the charging type for the PDP context session, specified by IE 1014, is time-based (e.g., time-based prepaid charging), the SSF module may merely use the call period as the elapsed time threshold or may apply a function, possibly as simple as multiplying by a factor, to convert the call period to an elapsed time threshold.

[0239] If the charging type for the PDP context session specified by IE 1014 is count-based prepaid charging, then Act 812 may include applying the time-to-count conversion ratio specified by IE 1107 of the APN profile 1101 corresponding to the PDP context session. For example, the time-to-count conversion ratio may specify that 1 second of call period translates to 56 kilobytes. Accordingly, if a subscriber has prepaid for 10 minutes of the PDP context session, then the count threshold count for the PDP context session will be 33.6 megabytes.

[0240] If the specified charging type for the PDP context session is count-based prepaid charging, then Act 812 also may include allocating the count threshold between an uplink count threshold and a downlink count threshold, for example, in accordance with IE 1112 of the APN profile 1101 corresponding to the PDP context session.

[0241] For example, referring to FIG. 8, for a PDP context session between a subscriber 17A using an MT 18A and PDN node 66, after receiving a count threshold from SSF module 662, PIM 344A may meter the number of information units exchanged by incrementing the accumulative number of information units received as part of forwarding uplink session packets 160 and compare the accumulative number to the uplink threshold count, and may separately meter the number of information units received as part of forwarding downlink session packets in the same manner. If either the uplink or the downlink threshold count is reached, the PIM 344A may report both uplink and downlink usage to the SSF module 362, and if the combined usage is still smaller than the original total count threshold converted from the call period received from the SCF module 148, the SSF module may be configured to re-allocate the remaining information units between a new uplink threshold count and a new downlink threshold count.

[0242] In Act 814, the duration of the PDP context session and/or a number of information units exchanged between the subscriber and the PDN node during the PDP context session may be metered. Act 814 may include applying the count metering unit specified by IE 1108 to determine what unit to use for metering. Thus, the SSF module may meter the number of information units exchanged (e.g., bytes, kilobytes, packets or transactions) during a PDP context session.

[0243] It should be appreciated that although metering a number of information units exchanged in a duration of a session are described throughout here, an event that takes place during a service may have a value associated with it that correlates to an amount of service that must be metered as part of the session metering process. For example, a service provider may charge a flat fee for a subscriber to download a particular file. Although not described above, an APN profile 1101 or a PDP context profile 1001 may have one or more information elements that define values corresponding to a particular service event (e.g., downloading a particular file). These information elements may be used during the metering process, for example, by a service support module such as module 361, to meter the amount of service associated with the event when the event occurs during the providing of the service.

[0244] Although not illustrated in method 800, a prepaid charging report (e.g. prepaid charging report 1400) may be generated by a session support module (e.g., session support module 363) at predefined periods (e.g., based on IEs 1302 and/or 1310 described above) or in response to a triggering event. Such report may transmitted to a service support module (e.g., service support module 361) and may be transmitted by an SSF module (e.g. SSF module 362) to an SCF module (e.g., SCF module 148) The metered number of information units exchanged or time elapsed may be converted to a call period. For example, the inverse function of the function applied in Act 812 may be applied to produce the call period. Such a conversion may be made by applying the reverse ratio of the ratio specified by IE 1107 of the APN profile 1101.

[0245]
FIG. 16 is a block diagram illustrating an example of a prepaid charging report 1400. Prepaid charging report 1400 may include one or more of the following IEs: time elapsed if no tariff switch IE 1402; time elapsed if tariff switch IE 1404; party to charge IE 1406; session active IE 1408; and one or more other IEs.

[0246] Depending on the type of prepaid charging and whether a tariff switch has occurred, either IE 1402 or 1404 may specify how much time has elapsed since the last prepaid charging report, or since the beginning of the PDP context session, or since the last tariff switch. If the type of prepaid charging for the PDP context session is time-based prepaid charging and a tariff switch has occurred since the last prepaid charging report 1400 was sent (which may be the reason why the prepaid charging report is being sent), then IE 1404 may specify the elapsed time since the last tariff switch.

[0247] If the type of prepaid charging for the PDP context session is time-based prepaid charging, but no tariff switch has occurred since the last prepaid charging report was transmitted, or if the type of prepaid charging is count-based prepaid charging, then IE 1402 will specify the time elapsed since the last prepaid charging report, or since the beginning of the PDP context session, or since the last tariff switch. The time elapsed may be the result of a conversion from a time or count threshold as described above.

[0248] The SSF module may be configured to send a prepaid charging report 1400 (e.g., to a service support module and/or an SCF module) for other reasons besides the reaching of a threshold or the occurrence of a tariff switch. For example, the session support module 363 and/or the SSF module may be configured to generate a prepaid charging report 1400 at periodic intervals during the metering of the number of information units exchanged for a PDP context session.

[0249] For example, the session support module and/or SSF module may be configured to generate a prepaid charging report 1400 at periodic intervals equal to the interval of a tariff switch if: a) the type of charging for the PDP context session as specified by IE 1014 is count-based prepaid charging; b) IE 1106 for the APN of the PDP context session specifies a tariff switch time for the APN; and c) IE 1110 for the APN specifies that time-based reporting is to be utilized. Accordingly, at the occurrence of a tariff switch during the PDP context session, the session support module and/or the SSF module will report the amount of time elapsed since a last prepaid charging report was transmitted using IE 1402 of a prepaid charging report 1400.

[0250] IE 1406 specifies a party to charge for the PDP context session. As described above IE 1406 should match IE 1308 of prepaid charging information 1300 corresponding to the PDP context session.

[0251] IE 1408 specifies whether the PDP context session is still active or the report 1400 was generated and transmitted as a result of the PDP context being terminated.

[0252] Returning to method 800, in Act 816, it may be determined whether an instruction to terminate the PDP context session has been received. For example, the SSF module may receive an instruction to terminate the PDP context session from the MT of the subscriber.

[0253] In Act 816, if it is determined that an instruction to terminate the PDP context session has been received, then the method proceeds to Act 819, described below. Although Act 816 illustrates determining whether such instruction has been received at a particular point during performance of method 800, it should be understood that at any point during the method 800, such an instruction may be received and the method may proceed to Act 819.

[0254] If it is determined in Act 816 that an instruction to terminate the PDP context session has not been received, then in Act 818, it may be determined whether a threshold has been reached, or, alternatively, whether a threshold is close to being reached. For example, it may be determined whether a time threshold for the duration of the PDP context session has been reached and/or a count threshold (i.e., a total of a combination of an uplink count threshold and a downlink count threshold) has been reached. Although Act 818 is illustrated as occurring at a particular point during performance of method 800, it should be understood that the threshold being reached is an event that may occur at any point during performance of method 800.

[0255] If it is determined that a threshold has not been reached, then method 800 may return to Act 814. If it is determined in Act 818 that a threshold has been reached (or is close to being reached) then processing may continue to Act 819.

[0256] In Act 819 the subscriber may be notified that the prepaid balance is insufficient for the service. The manner in which such notification is performed may be determined based on several factors, including information received in IE 1314. It should be noted that such notification may be performed regardless of whether an opportunity to top-up is afforded.

[0257]
FIG. 17 is a block diagram illustrating some aspects of providing pop-up notifications and top-up opportunities for services provided on a communications network. Such network may include a user terminal 318, which may be an MT, a Wireless Access Sub-network (WAS) 12 and an NSS 310. NSS 310 may include a PIM 344A and a storage medium 384 that may include a cache 384. NSS 310 also may include other network elements, for example, any of the network elements described above in relation to FIGS. 3-8.

[0258] A subscriber may be notified of a threshold amount of service being reached using the same session as is being used to provide the service (in-band) or using a different session (out-of-band). For example, PDN node 66 may be providing a service to user 317 of user device 318 along transport path 382. Accordingly, subscriber 317 may be notified of a threshold amount of service being reached as part of the same session along the transport path 382.

[0259] An out-of-band notification may be sent along a same or different transport path than the path on which service packets are exchanged with the user terminal to provide the service. For example, for a session along transport path 382, an out-of-band notification may be sent along transport path 382 as part of a different session or along a different transport path 380. An out-of-band notification may result from an application sending the notification other than the application providing the service. For example, PDN node 66 may be exchanging session packets 162 with PIM 344A to provide a service along transport path 380, but PDN node 67 may include an application that exchanges session packets 163 with PIM 344A to send the notification along a different transport path 382.

[0260] In an embodiment, a subscriber may be notified of a threshold being reached using a Short Message Service (SMS) by sending an SMS message to the subscriber.

[0261] An example of an in-band technique may be a dialogue box which can be presented in a windowing environment. This dialogue box may “pop-up” on the subscriber's screen of the user terminal (e.g., user terminal 318), and alert the subscriber 317 that the threshold has been reached. The pop-up could also prompt the subscriber for input from a keyboard, stylus, mouse or other input device to “top-up” or add value to the prepaid account.

[0262] In a following Act 820, it may be determined whether to terminate the PDP context session because of the insufficient balance. Such determination may be made in accordance with IE 1304 and 1312 (and possibly 1314) described above in relation to FIG. 15. For example, if IE 1312 specifies that no Top-up/Pop-Up opportunity is to be afforded the subscriber, and IE 1304 indicates to terminate the PDP context session, then the PDP context session may be terminated. Alternatively, even though IE 1312 may specify that no Top-up/Pop-Up opportunity is to be afforded the subscriber, IE 1304 may indicate to continue the PDP context session anyway, and then the PDP context session may be continued, and perhaps postpaid charging applied.

[0263] If it is determined in Act 820 to terminate the PDP context session, then processing continues to Act 830.

[0264] In Act 830, it may be determined whether any additional information units have been exchanged or time has elapsed since the last report was transmitted to the SCF module. As will be described in more detail below, at periodic intervals during the duration of the PDP context session and/or in response to an event, an SSF module (e.g., SSF module 362) may report usage information (e.g., information units exchanged or time elapsed) to the SCF module. During the interim in which the SSF module is waiting for a response from the SCF module, time has elapsed and more information units may have been exchanged or more time may have elapsed. The time elapsed and/or number of information units exchanged may be metered by metering module 365. Accordingly, the metering module 365 may meter the amount of information units exchanged or the time elapsed since the last report was transmitted. The metering module 365 may periodically record the time elapsed or information units exchanged to the SSF module 362. The frequency and timing of such reports may be synchronized with the usage reported by the SSF module 362 to the SCF module 148, or may be different.

[0265] If the service support module 361 already established the PDP context session and/or the session support module 363 already began exchanging packets for the session, then, in Act 831, the conversion module 366 may convert the additional number of information units exchanged or time elapsed to an excess call period. Converting from information units or time elapsed to a call period is described below in more detail in relation to Act 826.

[0266] In a following Act 832, as part of sending a prepaid charging report (e.g., prepaid charging report 1400), the session support module 363 and/or the SSF module 362 may report that an instruction to terminate has been received or that a threshold has been reached, and report the excess call period to the SCF module.

[0267] If in Act 830 it is determined that no additional information units were exchanged or time elapsed, for example, because the service support module 361 did not yet establish that PDP context session, then method 800 ends.

[0268] Returning to Act 820, if it is determined in Act 820 that the PDP context session is not to be terminated, then in Act 822 the subscriber may be enabled a top-up opportunity to add value to the prepaid account for the service. The manner in which such opportunity may be enabled may depend on several factors, including information received in IE 1314.

[0269] Similarly, as described above with respect to FIG. 17 for pop-up notifications, a subscriber of a communications network may be enabled to top-up a service account while the service is being provided using the same session as is being used to provide the service (in-band) or using a different session (out-of-band). Further, top-up packets may be sent along a same or different transport path than the path on which service packets are exchanged with the user terminal to provide the service.

[0270] To notify the client that a threshold for a service has been reached and/or to enable the client to top-up, either in-band or out-of-band sessions may be used based on any of a number of factors, including characteristics of the session implementing the service (e.g., the multimedia control protocol being used and the type and format of media content being exchange as part of the session), the capabilities of the user terminal (e.g., whether the user terminal can play audio content, play video content or process data content, or any combination thereof), the capabilities of the application and application server providing the service, or any combination thereof.

[0271] A session for providing a multimedia service may be implemented using a multimedia control protocol capable of controlling (e.g., initiating, maintaining and terminating) a session that includes the exchange of multimedia content, including audio, video, data or any combination thereof. For example, such protocol may be the Session Initiation Protocol (SIP). The SIP protocol is defined in RFC 2543, SIP: Session Initiation Protocol by Internet Engineering Task Force (IETF) as of Oct. 26, 1999. Other such multimedia control protocols may be used, including Telephony Application Programming Interface (TAPI), Telephony Server Application Programming Interface (TSAPI), H.323, Media Gateway Control Protocol (MGCP), MEGACO, Open Services Architecture (OSA), PARLAY, Java Advanced Intelligent Network (JAIN), and ad hoc IP-based protocols. In an aspect of this embodiment, the subscriber is notified in-band that a threshold amount of service has been reached and/or enabled to top-up in-band using a multimedia control protocol.

[0272] In a next Act 824, interim operations may be performed while the subscriber is provided the opportunity to add value to the prepaid account. Several different types of interim operations may be performed. The interim operations, and the manner in which the interim operations are performed may depend on several factors, including information received in IE 1314.

[0273] A subscriber may be enabled to top-up an account for a service using any of a variety of techniques. For example, a service may be suspended during the top-up process. Such suspension may allow a top-up to occur without affecting the service application or applications that are transmitting data at the point in time that a threshold amount of service is reached. This capability is useful in any number of circumstances, for example, in multi-player gaming contexts where a player may be interested in continuing a current session without having to restart the session as a result of a top-up being performed, or if a large file is being transferred to a subscriber as part of an application when a threshold is reached.

[0274] While the service is suspended, service content transmitted from the service provider to the subscriber on the subscriber's terminal may be buffered (e.g., cached) in a buffer (e.g., cache 386) while the subscriber is provided the opportunity to top-up the account. After the subscriber tops-up or after the opportunity to top-up has elapsed, the buffered content then may be transmitted to the user terminal. While such buffered content is being transmitted from the buffer to the user terminal, any additional service content transmitted from the service provider to the end station may continue to be cached until the buffer is empty, at which point any additional transmitted service content may be transmitted (i.e., forwarded) directly to the user terminal without being buffered. In this example, the application providing the service may remain unaware that the subscriber has reached a threshold for this service, and thus continually transmit content while the subscriber is enabled the opportunity to top-up. Such technique is useful in a situation where it is not desirable to terminate a session when large volumes of content (e.g., a large data, video or multimedia file) are being downloaded such that the large content is lost and would have to be re-transmitted after another session is established (perhaps after paying a bill or adding more value to a prepaid account).

[0275] In another example of this embodiment, while the subscriber is being enabled to top-up a prepaid account for a service, a different billing method, for example, postpaid charging, is applied for the service until the subscriber tops-up or until the opportunity to top-up has elapsed.

[0276]
FIG. 18 is a flow chart 1800 illustrating an example of a method of suspending a session while a top-up opportunity is enabled.

[0277] In Act 1802, the session may be suspended. For example PIM 344A may serve as a proxy for a user terminal such that all communications from the server application to the terminal are not forwarded by the PIM as they would be if the session was active. The PIM also may serve as a proxy for the server by capturing all communications transmitted from the user terminal to the application server.

[0278] In Act 1804, the PIM may maintain values for session states from the time at which the threshold was reached. In Act 1806, the PIM 344A may capture all session content transmitted from a server (e.g., from PDN node 66) and buffer such session content in cache 386 of storage medium 384.

[0279] Such buffering of session content may continue until it is determined in Act 808 that the account has been topped-up or alternatively that the top-up opportunity has lapsed. If the top-up opportunity has lapsed, then the session may be terminated.

[0280] If the account has been topped-up, then in Act 1810 the content of the buffer may be transmitted to user terminal 318. While the buffered content is being transmitted in Act 810, any new content being received from the application server will also be buffered in cache 386 until the buffer is empty. When the buffer is empty, then, in Act 1812, the session may be restored using the session values maintained from the time at which the threshold was reached, and the buffered session content may be forwarded to the user terminal in Act 1814.

[0281] Method 1800 may include additional acts. Further, the order of the acts performed as part of method 1800 is not limited to the order illustrated in FIG. 18 as the acts may be performed in other orders, and one or more of the acts of method 1800 may be performed in series or in parallel to one or more other acts. For example, Acts 1802 and 1804 may be performed in parallel.

[0282] Method 1800 is an illustrative embodiment of a method of suspending a session while a top-up opportunity is enabled. Such an illustrative embodiment is not meant to limit the scope of the invention and is provided for illustrative purposes, as any of a variety of other methods for suspending a session while a top-up opportunity is enabled, for example, variations of method 1800, may fall within the scope of the invention.

[0283] The ability to suspend a session, for example, as described above with respect to FIG. 18, may be programmed through the API for a service (e.g., using information elements of an APN profile 1101) and on a session-by-session basis (e.g., using information elements of a PDP context profile 1001).

[0284] In another interim operation, as a subscriber is being enabled an opportunity to top-up, another service (e.g., a “free” Internet service) is provided for the subscriber.

[0285] In another embodiment of the invention, when a threshold amount for a prepaid service is reached, a different billing method, for example, postpaid charging, is applied for the service. As used herein, a “prepaid service” is a service for which a subscriber has subscribed for prepaid charging, or a service for which prepaid charging is applied.

[0286] Returning to method 800, in Act 826, it may be determined whether the subscriber has added value to the prepaid balance for the service. If the subscriber has added value, then processing continues to Act 808, described above.

[0287] If it is determined that the subscriber has not added value to the prepaid account, then, in Act 828, it is determined whether the opportunity to add value has elapsed. The duration for which the subscriber has an opportunity to top-up the prepaid account may be based on the pop-up/top-up information defined by IE 1314.

[0288] If it is determined that the opportunity to add value has elapsed, then processing may proceed to Act 830 described above. If it is determined that the opportunity to top-up has not elapsed, then processing may proceed to Act 824.

[0289] It should be noted that although Acts 822, 824, 826 and 828 are illustrated as occurring sequentially, any combination of these Acts may occur concurrently, as the processing described by these Acts may be event-based processing which may occur in response to events. For example, a pop-up message may be played or displayed on a display screen of the MT of the subscriber offering the subscriber an opportunity to add value to the prepaid account while interim operations are being performed. Any time during which this opportunity is being offered to the subscriber and the interim operations are being performed, a notification may be received that the subscriber has added value to the prepaid balance or the opportunity to add value has elapsed.

[0290] Returning to act 810, if it is determined in Act 810 that the subscriber does not have a sufficient prepaid balance for the requested service, then processing may continue to Act 819, described above

[0291] Method 800 may include additional acts. Further, the order of the acts performed as part of method 800 is not limited to the order illustrated in FIGS. 12A-12B as the acts may be performed in other orders, and one or more of the acts of method 800 may be performed in series or in parallel to one or more other acts. For example, as described above, Acts 816 and 818 may be performed at any point during performance of method 800.

[0292] Method 800 is an illustrative embodiment of a method of implementing prepaid charging for packet-switched services on a module of an MCN. Such an illustrative embodiment is not meant to limit the scope of the invention and is provided for illustrative purposes, as any of a variety of other methods of implementing an INS for packet-switched services on a PIM of an MCN, for example, variations of method 800, may fall within the scope of the invention.

[0293] Methods 700 and 800, described above in relation to FIGS. 11, 12A and 12B, other methods described above, and acts thereof, respectively, and various embodiments and variations of these methods and acts, individually or in combination may be implemented as a computer program product tangibly embodied as computer-readable signals on a computer-readable medium, for example, a non-volatile recording medium, an integrated circuit memory element, or a combination thereof. Such a computer program product may comprise computer-readable signals tangibly embodied on the computer-readable medium, where such signals define instructions, for example, as part of one or more programs, that, as a result of being executed by a computer, instruct the computer to perform one or more of the methods or acts described herein, and/or various embodiments, variations and combinations thereof. Such instructions may be written in any of a plurality of programming languages, for example, Java, Visual Basic, C, or C++, or any of a variety of combinations thereof. The computer-readable medium on which such instructions are stored may reside on one or more of the network elements of NSS 310 described above, and may be distributed across one or more of such network elements.

[0294] Having now described some illustrative embodiments of the invention claimed below, it should be apparent to those skilled in the art that the foregoing is illustrative and not limiting, having been presented by way of example only. Numerous modification and other illustrative embodiments are within the scope of one of ordinary skill in the art and are contemplated as falling within the scope of the claims set forth below. In particular, although many of the examples presented herein involve specific combinations of method acts or system elements, it should be understood that those acts and those elements may be combined in other ways to accomplish the same objectives. Acts, elements and features discussed only in connection with one embodiment of a system or method are not intended to be excluded from a similar role in other embodiments. Further, for the one or more means-plus-function limitations recited in the following claims, the means are not intended to be limited to the means disclosed herein for performing the recited function, but are intended to cover in scope any equivalent means, known now or later developed, for performing the recited function.

[0295] In the claims, all transitional phrases such as “comprising”, “including”, “carrying”, “having”, “containing”, “involving”, and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases “consisting of” and “consisting essentially of”, respectively, shall be closed or semi-closed transitional phrases as set forth in the United States Patent Office Manual of Patent Examining Procedures, section 2111.03.

[0296] What is claims is:

Number	Date	Country
60295453	Jun 2001	US
60344538	Oct 2001	US
60357940	Feb 2002	US

Topping up a subscriber's account for a multimedia service on a communications network while the service is being provided

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

US Classifications

International Classifications

Abstract

Description

Claims

RELATED APPLICATIONS

Provisional Applications (3)