Abstract:
Embodiments of the present invention relate to a messaging system for managing communications resources and are particularly suitable for providing a means for subscribers of a telecommunications network to continue participating in a communications service that would otherwise be ended due to the calling party having a low or zero balance. Embodiments of the invention are generally applicable to users of a mobile network. 
     Embodiments of the invention provide a messaging system for use by the telecommunications network to transmit a message to a remote party, where the remote party is identified by means of a telephone calling identifier associated with a call setup request for a telecommunications session received from a user of the telecommunications network. The messaging system comprises a storage system for storing data providing a predetermined definition of message content to be sent to the remote party. In response to trigger event such as determining that the account balance available for said user participating in the requested communications session is below a predetermined threshold, the messaging system is arranged to initiate the transmission of a message to said remote party. The transmitted message contains message content that is defined at least in part by said definition of message content and can comprise a “call me message”. This thereby ensures that a “call me” message reaches the remote party.

Description:
FIELD OF THE INVENTION 
     The present invention relates to a messaging system for managing communications resources and is particularly, but not exclusively, suitable for providing a means for subscribers of a communications network to continue participating in a communications service that would otherwise be ended due to the calling party having a low or zero balance. Embodiments of the invention are generally applicable to users of a mobile network. 
     BACKGROUND OF THE INVENTION 
     Broadly speaking there are two types of users of network resources in the mobile domain. The first type of user is a so-called “contract” subscriber, for whom usage of network resources is paid for after the resources have used; typically the payment period is monthly. Such post paid systems might include a credit limit service where a user or other party such as parent and/or operator sets a limit of money to be allocated to services. The allocation can be also periodic and can for example specify an amount of services per month. 
     The second type of user is a so-called “pay as you go” subscriber, for whom usage of network resources is paid for prior to the provisioning of a given service. These services might include also credit limit type of functionality so as to prevent usage of all the credits in less than a predetermined time period. 
     Usage of network resources by either type of user can be sponsored by third parties by means of information content such as advertisements and the like. In this scenario all or part of the usage is offset by the third party, either directly or indirectly and, depending on the type of user, either before or after a given service has been provided. 
     One problem commonly experienced by the pay as you go user and by a post paid user when a predetermined credit limit is reached is the refusal or termination of a service when the pre-paid quota (or credit limit or advertisement sponsoring of related services) is lower than a predetermined threshold. As is commonly known, in such situations the network alerts the user of the imminent ending of the communications session by means of a message such as beep sound or voice message. This message is typically delivered to the user about 3 minutes before the quota or credit has expired; once the credit has expired the user is typically unable to make phone calls or use messaging or other services. 
     Several workers have proposed a solution to this problem, generally referred to as the “call me” service, whereby the user with no or a low amount of credit sends a message to the remote party with whom they wish to communicate, asking the remote party to call them. Such messages can be transmitted using the Unstructured Supplementary Services Data (USSD) or via the Short Messaging Service (SMS), as described in US patent application having publication number US2004/0192359. However, a problem with these methods is that the user needs to have some credit for the “call me” message to be transmitted through the network. 
     SUMMARY OF THE INVENTION 
     In accordance with an aspect of the present invention, there is provided a messaging system and method as set out in the appended claims. 
     In comparison to conventional methods, with embodiments of the invention the network initiates transmission of a “call me” message in response to a trigger event such as the user&#39;s balance or available credit falling below a predetermined level. Since transmission of this message is under the control of the network, the network can ensure that there are sufficient resources to support transmission of the message, be this on the basis of communications resources allocated to a third party such as an advertiser, or on the basis of a reserve amount specified by the network operator. 
     The “call me” message is composed on the basis of predetermined definition of message content to be sent to a remote device. The message content can be specified by third parties, for example whom subsidise the transmission of such “call me” messages and/or any calls that are subsequently made by the remote device to the user. In addition or alternatively the message content can be specified by the user, for example via an interactive voice recognition (IVR) unit, which can be configured to check that the speech input received from the user does not exceed an available size of the predetermined message content. 
     Preferably the storage system is further arranged to store data providing a predetermined definition of message-associated information to be provided to the user, and the messaging system is arranged to transmit message-associated information to a device associated with the user. The message-associated information can include notification of the remote device to which the message is to be transmitted—in response to said trigger event—and can instruct the user to provide some sort of response. Once received, the messaging system can combine this response with the predetermined definition of message content so as to generate the “call me” message. 
     Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram showing an example of a communications environment within which embodiments of the invention can operate; 
         FIG. 2  is a block diagram showing components of a Service Control Platform shown in  FIG. 1 ; 
         FIG. 3  is a flow diagram showing steps associated with call set up according to an embodiment of the invention; 
         FIG. 4  is a flow diagram showing steps associated with ongoing management of a communications session according to an embodiment of the invention; and 
         FIG. 5  is a timing diagram showing steps associated with providing messaging actions according to an embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     As described above, embodiments of the invention are generally concerned with providing a means for subscribers of a communications network to continue participating in a communications service that would otherwise be ended due to the calling party having a low or zero balance or amount of available credit. Typically embodiments of the invention would be applicable to subscribers of a mobile communications network  10  shown in  FIG. 1 . The mobile network  10  can be any cellular, broadcast, wide area network. Examples of cellular network technologies include but are not limited to GSM (Global System for Mobile communication), WCDMA (Wideband CDMA), CDMA (Code Division Multiple Access), GPRS (General Packet Radio Service), UTRAN (UMTS Radio Access Network), UMTS (Universal Mobile Telecommunications System), MBMS (Multicast Broadcast Multimedia System). Examples of other network technologies include but are not limited to local area networks, such as Wireless Local area networks (WLAN), BlueTooth (BT), and other technologies, such as WiMax (Worldwide Interoperability for Microwave Access), Broadcasting over cellular, Broadcasting over DVB-H (Digital Video Broadcasting—Handhelds), ISDB-T (Terrestrial Integrated Services Digital Broadcasting), DMB (Digital Multimedia Broadcasting). The communication network  10  may also be connected to a public switched telephone network (PSTN  9 ) and can provide generic Internet access using any transport methods. The communications network can be also a combination of different communication network technologies  9 ,  10 ,  11 . 
     The exemplary GSM communications network  10  of  FIG. 1  comprises a mobile switching centre (MSC)  2 , which is connected via communications links to a number of base station controllers (BSCs)  4 . Each BSC  4  controls one or more base transceiver stations (not shown) located remote from, and connected by further communications links to, the BSC. Each base transceiver transmits radio signals to, and receives radio signals from, mobile stations  8   a ,  8   b  which are in an area served by that transceiver. The mobile network  10  is provided with a home location register (HLR)  12  which is a database storing subscriber authentication data, and the MSC  2  is provided with a visitor location register (VLR)  14  which is a database temporarily storing subscriber authentication data for mobile stations active in its area. The MSC  2  is capable of handling service provision for both contract subscribers and prepaid subscribers of the network in the area it serves. Subscribers may originate or receive multimedia, video, voice, data or fax calls or sessions, short messages using the Short Message Service (SMS) via SMSC 6 , and email messages, enhanced or multimedia messages (MMS) via MMSC  5 . Furthermore the user may access data and multimedia resources over private or public data networks such as the Internet  11 . Signalling and data in respect of services provided to mobile stations  8   a ,  8   b  is routed via MSC  2 . The communications network  10  also includes a billing system  15 , which receives charging data from the MSC  2  and generates Call Detail Records (CDR) for post paid customers, and is accessible by Intelligent Network platforms supporting prepaid customers in order to identify discounts applicable to network services provisioned to prepaid customers. 
     The mobile terminals  8   a ,  8   b  may be a mobile phone, a personal digital assistant (PDA), a multimedia computer, a personal computer, a lap top, etc., or generally any terminal capable of accessing services, such as content download, web browsing, streaming, Wireless Application Protocol (WAP) browsing, voice and messaging. In the case of the mobile network  10  being embodied as a GSM or WCDMA network, the terminal is a mobile phone with GSM or WCDMA functionalities.  FIG. 1  shows two terminals:  8   a , referred to herein as the terminal associated with subscriber A; and  8   b , referred to as the terminal associated with subscriber B. 
     In respect of service provision to prepaid subscribers using a GSM mobile station  8   a  the MSC  2  functions as a Service Switching Point (SSP) and is connected to and controlled by Service Control Point (SCP)  16  with which it can communicate using the Intelligent Network Application Protocol (INAP). The specification of INAP is provided in European Telecommunications Standards Institute (ETSI) standard ETS  300   374 - 1  and specifies sets of standard instructions that can pass between components of a given mobile network so as to provision and control calls and data messages. As can be seen from  FIG. 2 , SCP  16  comprises a Prepaid Control Function (PCF)  18  connected to a Service Data Function (SDF)  20 . PCF  18  is connected to MSC  2  with which it communicates using INAP messages as described above and is responsible for performing the data processing steps required to control the operation of MSC  2 . The SDF  20  is responsible for storing data relating to prepaid subscribers, such as prepaid account balance data for a subscriber, instance data relating to services currently being provided to a prepaid subscriber, and, according to the present invention, messaging information and instructions on behalf of a subscriber (to be described in detail below). The SDF  20  is connected to user terminal  22  for user entry and amendment of data stored in respect of a prepaid subscriber. 
       FIG. 3  is a flow diagram showing, in detail, the data processing steps performed by SCP  16  when determining how to handle a call request (e.g. by invoking the Get Call Action INAP method), and to determine actions to be taken in the event that the subscriber has an insufficient amount of credit in his account. When providing a user with access to communications services, MSC  2  typically passes an INAP request message to PCF  18  requesting instruction in respect of a new or ongoing provision of a service to a prepaid subscriber (step  301 ). The request message normally provides information concerning the service and the identity of the subscriber. The PCF  18  determines how to handle the request on the basis of the service information provided by MSC  2 , on the basis of generally applicable information concerning service provision and characteristics or information concerning the prepaid subscriber, which are obtained by invoking a method of SDF  20 . 
     In order to identify a charge for the call, and thus evaluate whether or not the subscriber has sufficient credit for the call, a rate for the call is determined by consulting a generally applicable rating table maintained in SDF  20  using the chargeable destination and call type provided by MSC  2  (step  303 ). Typically prepaid network services are provisioned in blocks of time periods, and at the end of any given time period the account balance is evaluated in order to establish whether or not the call can continue. This evaluation is provided by the PCF  18  performing an INAP Apply-Charging-Report (ACR) method, and the duration for any block of time is calculated during provision of a metered service so as to determine the frequency at which charging for the service is to be performed. The process is generally dependent on the applicable rate for provision of the service, and upon the current account balance of the prepaid subscriber. Thus, the ACR method may be performed relatively infrequently when there are ample prepaid funds in the subscriber&#39;s account balance and relatively frequently when the subscriber&#39;s prepaid balance approaches zero or some other specified level. 
     Accordingly, at step  305  the PCF  18  identifies an interval of time before the first Apply-Charging-Report (ACR) method is to be performed. The process then continues to step  307  at which the method identifies a charge for the time period between the start of the call and the first invocation of the ACR method. The SCP  16  compares this charge with the account balance (step  309 ); in the event that the account balance is less than is required to cover the charge for this period, the SCP  16  performs the messaging action according to embodiments of the invention ( FIG. 5 , described in detail below) and generates an INAP Release Call response message for sending to MSC  2  in order to terminate the call. Assuming the account balance to be sufficient to support the charge, the SCP  16  passes an INAP ACR response message to MSC  2 , instructing it to connect the call as a chargeable call and to generate an INAP ACR request message after the calculated period has expired (unless the call is terminated early, for example by the subscriber ending the call, in which case an ACR request message may be generated earlier and will include the unexpired charging period remaining). 
     The steps associated with servicing an ACR request message after the calculated period has expired are shown in  FIG. 4 , which is a flow diagram showing the data processing steps performed by SCP  16  when performing ACR processing for ongoing chargeable calls. MSC  2  passes to PCF  18  an INAP ACR request message after the calculated charging period has expired or earlier (step  401 ). This results in SCP  16  applying rated charges for the call, and determining whether or not the prepaid subscriber has sufficient prepaid balance to continue the call. At step  403 , the prepaid subscriber&#39;s account balance and the rating information for the call are identified from the instance data for the ongoing call. The airtime used since the ACR processing was performed is then calculated (or since the start of the call if this is the first such processing: step  405 ) and the call charges are calculated on the basis of the used airtime, the start of call time and rate class; this is then subtracted from the account balance, and the SCP  16  determines whether the prepaid subscriber&#39;s currently available account balance is greater than a predetermined threshold, Th (step  409 ). If not, i.e. if the subscriber&#39;s currently available balance is less than or equal to zero, the process invokes a messaging action according to embodiments of the invention ( FIG. 5 ) and the Call Action parameter is set to ‘release call’. This causes SCP  16  to generate a Release Call instruction for sending to MSC  2 , resulting in the call being terminated due to lack of available prepaid funds. If the account balance is greater than zero, the PCF  14  cycles back to step  401 , waiting for receipt of a next ACR message from the MSC  2 . Typically the threshold is an amount that will cover the transmission of the various messages. 
     As will be appreciated from the foregoing, the messaging action process is triggered whenever the SCP  16  determines that the user&#39;s prepaid balance cannot support provision or continuation of a call/service. The messaging action is defined, per subscriber, in the SDF  20 , which can store records identifying message content, type, format, in addition to actions; assuming the subscriber initiating the call to be associated with terminal A and the called party to be terminal B, these can include any of the following: 
                                     Message Content M1   Message Content M2           for terminal A   for terminal B   Message Actions                   “You do not have any   “Call me on [MSISDN   Send SMS to       credit left, please wait   A]!”   disconnected       for a while and we will       subscriber A and to       ask the party you are       called party B       calling to call you”       “You do not have any   “Call me on [MSISDN   Send SMS to       credit left, please press 1   A]! This message has   disconnected       if you wish to inform the   been automatically   subscriber A and to       party you are calling to   generated on behalf of   called party B upon       call you”   subscriber A”   receipt of key input               1 from subscriber A       “You do not have any   “Call me on [MSISDN   Send SMS to       credit left, please wait   A]! This message has   disconnected       for a while and will ask   been automatically   subscriber A and to       the party you are calling   generated on behalf of   called party B       to call you”   subscriber A by           SuperFoods ™ Ltd.”       “You do not have any   “Call me on [MSISDN   Send SMS to       credit left, please wait   A]! This call will be   disconnected       for a while and we will   subsidized by   subscriber A and SMS       ask the party you are   SuperFoods ™ Ltd.”   to called party B       calling to call you; the       call will be subsidized by       SuperFoods ™”       “You do not have any   Message composed by   Send SMS to       credit left, please reply to   subscriber A   disconnected       this message with a       subscriber A and to       message for transmission       called party B       to [MSISDN B]”                    
The message could alternatively be transmitted as an Instant message, as an MMS or as an e-mail message, and the message type could be specified in the records stored by the SDF  20  per party called by terminal A (so that for example an SMS is sent to called party B, an e-mail is sent to called party C etc.).
 
     The SDF  20  can also include records indicating third parties that are willing to subsidise the call back from terminal B to terminal A and/or the transmission of the messages intended to invoke call back between terminal B and terminal A; the table above gives “SuperFoods™” as an example. Referring back to  FIG. 1 , the public network  11  has a service server  13  connected thereto, and this can be accessed by third parties wishing to subsidise such a call back service. The service server  13  would be in association with SCP  16  and the subscriber A would have to have signed up to the service associated with server  13  so that the records in the SDF  20  can identify the subsidizing party and thus enable messages to be populated as indicated above. In one arrangement the service server  13  can specify an amount of network resources it is willing to subsidise and optionally a time period during which calls back are to be subsidised, and this can be used by the billing system  13  to offset call back calls made by terminal B (and indeed any other called party that calls terminal A back in response to receipt of a call back message). 
     In addition the content of the message sent to the called party can be specified by the user of terminal A via a Web or WAP interface, either via terminal A or via another device, when the user signs up to the service via the service server  13  (or indeed at any time after signing up). Alternatively the service server  13  could be arranged to accept speech input, for example in the event that the service server  13  cooperates with an Interactive Voice Recognition (IVR) system (not shown) connected to the mobile network  10 . In the latter arrangement the IVR system would analyse the message dictated by the user of terminal A as the message is being composed to ensure that the content can be accommodated within the message constraints of the Short Messaging Service; in the event that the message exceeds the available number of characters, the IVR can interrupt the user and invite him to recompose or modify the message. 
     Turning to  FIG. 5 , responsive to the PCF  14  identifying that the account balance is zero (or insufficient to support commencement of a call), the PCF  14  sends a request to the SDF  20  in order to determine and then trigger the messaging action (step  501 ). The request includes an identifier associated with the called party, for example the MSISDN of terminal B, causing the SDF  20  to look up records corresponding to the calling (and now terminated) party A; in the event that there is a prestored SMS message and transmission instruction stored for party A in relation to the called party (terminal B), the SDF  20  passes the messages M 1 , M 2  to the PCF  14  (step  503 ) for transmission via the SMSC  6  and thence to terminals A and B respectively (steps  505 ,  513 ,  515 ). In addition to requesting a messaging action from the SDF  20 , the PCF  14  sends an INAP message to the MSC  2  to trigger termination of the call placed by terminal A (step  502 ).  FIG. 5  relates to the case in which the sending of message M 2  is dependent on a response from terminal A in respect of message M 1 , and shows that the PCF  14  delays transmission of message M 2  until the response has been received (steps  509 ,  511 ). However, it will be appreciated that message M 2  can be transmitted by the PCF  14  together with message M 1 . 
     ADDITIONAL DETAILS AND MODIFICATIONS 
     The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. For example, the method could be used in relation to Voice over IP calls. 
     Whilst the above embodiment is illustrative of call handling in relation to GSM Intelligent Network procedures and platforms, the skilled person will appreciate that the messaging actions could be coordinated in other ways, such as for example involving devices in the public network portion  11 . 
     It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.