Patent Publication Number: US-2010130162-A1

Title: Routing system that enables charging for application-to-application routing of messages formatted in a mobile phone messaging standard

Description:
BACKGROUND 
     By some measures, Short Message Service (SMS) text messaging is one of the most widely used data applications on the planet. Despite limitations such as message size, SMS messaging has become the standard to allow a user of a mobile device to send a short text message to another user of a mobile device. More recently, Multimedia Message Service (MMS) messaging has been adopted to enable users to send messages containing multimedia objects. When an SMS or an MMS message is sent between users, a telecommunications carrier associated with the sender&#39;s mobile device will typically charge for the message to be sent, and a telecommunications carrier associated with the recipient&#39;s mobile device will typically charge for the message to be received. Such charges help pay for the telecommunications network infrastructure that is necessary to allow the message to be delivered. 
     As the use of SMS and MMS messaging has grown, so have the variety of wired and wireless devices that are adapted to send and receive SMS and MMS messages, as well as the variety of applications that provide services via SMS or MMS messaging. For example, personal computers having a network connection can send and receive SMS and MMS messages to/from mobile phones, other personal computers, and other devices. As another example, satellite phones can send and receive text messages with other devices. Although the number and variety of devices that can send and receive messages has evolved beyond strictly mobile devices, the ability to charge for messages to and from such devices has not kept pace. That is, systems do not presently exist to track and bill for certain types of SMS and MMS message traffic. The inability to charge for certain types of messaging has hindered the development and expansion of commercial services that might otherwise take advantage of messaging in a mobile phone messaging standard. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of a representative environment in which a message routing system operates. 
         FIG. 2  is a block diagram of the components of a message routing system that enables charging for messages routed between applications. 
         FIG. 3  is a flow chart of a screening, routing, and charging process implemented by the message routing system. 
         FIG. 4  is a flow chart of a screening process implemented by the message routing system. 
     
    
    
     DETAILED DESCRIPTION 
     A message routing system that enables charging for messages that are formatted in a mobile phone messaging standard and routed between software applications is disclosed. The mobile phone messaging standard may be, for example, the Short Message Service (SMS) standard or the Multimedia Messaging Service (MMS) standard. The routing system receives a message from a mobile device or from an application server. The routing system screens the message to determine whether the message should be delivered to a recipient. If the message passes the screening check, the routing system routes the message for delivery to a recipient mobile device or application server. The system may receive and route the message over any type of network, whether wired or wireless (using licensed or unlicensed spectrum). In accordance with configurable business rules, the routing system generates a charging data record (CDR), or any similar billing log or record, associated with the message to allow the message sender and/or message recipient to be billed for the message. The routing system thereby enables messages formatted in a mobile phone messaging standard to be delivered between any combination of devices or applications that communicate via wired or wireless networks. In particular, the system enables messages to be routed from one software application to another software application and charges to be levied for such routing in accordance with business rules. Charging for application-to-application routing is accomplished using existing mechanisms typically used to charge for mobile device-to-mobile device routing. 
     In some embodiments, the screening check performed by the system involves determining whether the message sender and/or the message recipient should be barred from sending/receiving messages via blacklist, white-list or similar mechanism. The system may also perform one or more routing checks to determine whether the message can be delivered to the recipient within an acceptable service level. If either the sender or the recipient utilizes a prepaid billing plan, the system may also determine whether a sufficient balance exists in the prepaid account to cover any charges associated with the message delivery. The system may also perform other screening checks to determine whether to route messages, such as routing or not routing messages based on operator preferences, based on messaging allowances (e.g., terminating messaging if the number of routed messages exceeds a threshold), based on temporal restrictions (e.g., no messages may be routed during certain hours), etc. 
     Various embodiments of the invention will now be described. The following description provides specific details for a thorough understanding and an enabling description of these embodiments. One skilled in the art will understand, however, that the invention may be practiced without many of these details. Additionally, some well-known structures or functions may not be shown or described in detail, so as to avoid unnecessarily obscuring the relevant description of the various embodiments. The terminology used in the description presented below is intended to be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific embodiments of the invention. 
       FIG. 1  is a block diagram of a representative environment in which a message routing system  100  operates. The routing system  100  routes a message that is formatted in a mobile phone messaging standard from a sending device or application server to a recipient device or application server, and generates a charging data record (CDR) or similar billing log or record to bill for the message routing. The mobile phone messaging standard may be, for example, the Short Message Service (SMS) standard or the Multimedia Messaging Service (MMS) standard. Those skilled in the art will appreciate that the messaging standard may rely upon one or more underlying standards, including but not limited to SMPP, GSM, GPRS, SMTP, WAP Push, SIP, etc. Messages may be translated between different standards at different parts of the network as messages are routed through the network. 
     A message may be received by the system along one of three paths. A first path, identified as a Mobile Licensed Originated (MLO) path  105 , originates from a mobile phone  110  or similar mobile device. A user of the mobile device generates a message and transmits the message to a switch  120  (e.g., a mobile switching center) via a cellular network  115  or other wireless access point using a licensed frequency spectrum (e.g., a picocell). The switch  120  forwards the message to the routing system  100  via an SS7 (PSTN) signaling network  125  or other similar network. A second path, identified as a Mobile Unlicensed Originated (MUO) path  130 , originates from a mobile phone  135 , portable computer  140 , or other mobile device. A user of the mobile device generates a message and transmits the message to an application gateway  155  via an access point  145  (e.g., a WiFi router, WiMax router or other femtocell access point) and network  150 . The access point may use an unlicensed wireless spectrum, and connectivity may be based on the Unlicensed Mobile Access (UMA)/General Access Network (GAN) standard. The access point may also allow a wired connection, such as via an RJ-11 or comparable jack. Communication between the mobile device and access point  145  is conducted in accordance with any appropriate wired or wireless protocols such as WiFi, WiMax, HTTP/TCP/IP, etc. Communication between the access point and the application gateway  155  is conducted in accordance with the Session Initiation Protocol (SIP) or other appropriate communication protocol. The application gateway  155  therefore converts messages of the selected protocol, such as SIP, to messages formatted in a mobile phone messaging standard before transmitting the resulting messages to the routing system  100 . A third path, identified as an Application Originated (AO) path  160 , originates from an application operating on a server  165  or other computing device. Application messages are generated by the application server in an automated fashion, rather than involving manual input by a user to generate each message. Applications, such as external short message entities (ESME), that may generate or receive messages include Enterprise applications (e-Mail, voicemail, CRM, ERP and workflow engines) or custom-built applications operated by a telecommunications carrier or by a third party. Originating applications may provide many types of services, such as news or alert services, stock quote services, email notification services, etc. Receiving applications may offer services such as vote counting services (to count votes cast by users), etc. Some applications may only send messages (“origination-only applications”), some applications may only receive messages (“termination-only applications”), and some applications may both send and receive messages. The application sends communication messages through a network  170  to an application gateway  175 , using a standard protocol such as a short message peer-to-peer (SMPP) protocol. The application gateway translates messages formatted in the received protocol into messages formatted in accordance with a mobile phone messaging standard before transmitting the resulting messages to the routing system  100 . In this fashion, the application gateway allows, for example, messages to be submitted in bulk by the application operating on the server  165 . Whether received via the MLO path  105 , MUO path  130 , or AO path  160 , the routing system  100  processes received messages for distribution to recipients. 
     Those skilled in the art will appreciate that  FIG. 1  represents only one of many potential network realizations of a messaging service infrastructure. Other appropriate realizations of a messaging service infrastructure may introduce additional reception paths to the message routing system  100  in addition to the MLO path  105 , MUO path  130 , or AO path  160 , or may remove one or more of the indicated message paths. Moreover, those skilled in the art will appreciate that applications may send messages to the message routing system  100  either directly using any appropriate standards or indirectly via gateways using any appropriate standards. 
     As will be described in additional detail herein, the routing system  100  processes received messages by performing a screening check on each message, determining a routing of each message, routing each message, and generating a charging data record (CDR) or similar billing log or record to enable billing for the message routing. Only those messages that pass the screening check by the routing system are routed to the intended recipient. The screening check on each message may require communication with a prepaid server  180 , to determine whether the sender and/or recipient have sufficient account resources to allow the routing to occur. A CDR is generated by the system in accordance with configurable business rules. On an immediate, periodic or random basis, CDRs that are generated by the routing system  100  are transmitted to a billing server  185 . The billing server reconciles all CDRs against service plans and levies appropriate charges to the sender and/or recipient. 
     For a message that the routing system  100  routes to a recipient, the message formatted in a mobile phone messaging standard may be transmitted by the system along one of three paths. The three transmission paths utilized by the system are analogous to the three reception paths. A first path, identified as a Mobile Licensed Termination (MLT) path  190 , terminates at a mobile phone  210  or other mobile device. The system sends messages through an SS7 (PSTN) signaling network  195  or other similar network to a switch  200  (e.g., a mobile switching center), and then to the mobile phone  210  through a cellular network  205  or other wireless access point using a licensed frequency spectrum (e.g., a picocell). A second path, identified as a Mobile Unlicensed Termination (MUT) path  215 , terminates at a mobile phone  235 , portable computer  240 , or similar mobile device. The system  100  transmits the message to an application gateway  220 , and then to the mobile phone  235 , portable computer  240 , or other mobile device via network  225  and access point  230  (e.g., a WiFi router, a WiMax router, or other femtocell access point). The access point may use an unlicensed wireless spectrum, and connectivity may be based on the Unlicensed Mobile Access (UMA)/General Access Network (GAN) standard. The access point may also allow a wired connection, such as via an RJ-11 or comparable jack. Communication between the application gateway  220  and the access point  230  is conducted in accordance with the Session Initiation Protocol (SIP) or other appropriate communication protocol. Communication between the access point  230  and the terminating mobile device is conducted in accordance with any appropriate wired or wireless protocols such as WiFi, WiMax, HTTP/TCP/IP. etc. The application gateway  220  therefore converts messages into the selected protocol, such as SIP, before transmitting the resulting communication to the access point. The access point converts messages to the appropriate protocol for transmission to the terminating mobile phone, portable computer, or mobile device. A third path, identified as an Application Termination (AT) path  245 , terminates with an application operating on a server  260  or other computing device. Application messages are received by the application server in an automated fashion, without requiring manual acceptance by a user of each message. The system transmits messages formatted in a mobile phone messaging standard to an application gateway  250 , such as a short message peer-to-peer (SMPP) gateway. The application gateway translates the messages into standard protocols, such as SMPP, and transmits the contents of the messages via communication messages to the server  260  through a network  255 . Whether transmitted via the MLT path  190 , MUT path  215 , or AT path  245 , the routing system  100  distributes received messages that pass the screening check to recipients. 
     Those skilled in the art will appreciate that other appropriate realizations of a messaging service infrastructure may introduce additional termination paths to the message routing system  100  in addition to the MLT path  190 , MUT path  215 , or AT path  245 , or may remove one or more of the indicated termination paths. Moreover, those skilled in the art will appreciate that applications may receive message from the message routing system  100  either directly using any appropriate standards or indirectly via gateways using any appropriate standards. 
     As depicted in  FIG. 1 , the routing system  100  allows a wide variety of routing paths, including MLO-MLT, MLO-MUT, MLO-AT, MUO-MLT, MUO-MUT, MUO-AT, AO-MLT, AO-MUT, and AO-AT. The variety of routing paths provides a significant amount of flexibility to users and application designers who use the system for the delivery of messages formatted in accordance with a mobile phone messaging standard. It will be appreciated that the depiction of separate origination and termination paths in  FIG. 1  is merely for clarity, and that the origination and termination paths may in some circumstances be the same physical path. For example, if mobile devices  110  and  210  are in close proximity, the cellular network  115 , switch  120 , and SS7 network  125  may be the same physical elements as cellular network  205 , switch  200 , and SS7 network  195 . In other circumstances, however, the origination paths and termination paths may be different physical paths, such as when the sending device or application and the recipient device or application are operating on different telecommunication networks. It will be appreciated that in the environment depicted in  FIG. 1 , certain message protocol translations are performed within gateways. In some embodiments, the protocol translation functions may instead be implemented and performed by the routing system  100 , or by one or more other components (not shown). 
     Those skilled in the art will also appreciate that the environment depicted in  FIG. 1  is merely representative, and that various changes may be made depending on the particular architecture that is implemented by the carrier. For example, all depicted networks may be public networks, private networks, or a combination of public and private networks. As another example, the components depicted in  FIG. 1  are referred to using terminology common to GSM networks. Equivalent or similar components may replace those when the system is utilized in a CDMA or Digital AMPS networks. The routing system  100  may be utilized in any environment in which messages formatted in accordance with a mobile phone messaging standard are exchanged between devices and applications. 
       FIG. 2  is a block diagram of the components of the routing system  100  that enables charging for messages routed between applications. In some embodiments, the routing system  100  is implemented in conjunction with a system that sends messages formatted in accordance with a mobile phone messaging standard directly to recipients without passing the messages through a carrier&#39;s traditional store/forward center. Such a system is referred to as a “first delivery attempt” (FDA) or “direct messaging” solution. Representative FDA systems are manufactured by mcTEL of Monaco, TeleCommunication Systems, Inc. of Annapolis, Md., and Tekelec of Morrisville, N.C. For example, TeleCommunication Systems offers a FDA solution for text messages under the tradename smsExpress™ that eliminates traditional store and forward delivery of SMS messages. Instead, approximately 80%-90% of SMS text messages are transmitted directly to addressees without routing the messages to the Short Message Service Center (SMSC) for traditional store/forward delivery. Only text messages that fail a first delivery attempt are routed to the carrier&#39;s SMSC. 
     As shown in  FIG. 2 , the routing system  100  includes a number of modules to implement the functionality described herein. A screening module  270  is used to screen an incoming message and assess whether the message should be routed to the intended recipient. A routing module  275  assesses the network location of a message recipient and determines a routing method to forward the message to the recipient. If a message is routed to a recipient, a CDR generation module  280  generates a charging data record to allow charges to be levied for the routed message. The operation of each of these modules will be described in greater detail with respect to the flow charts of  FIG. 3  and  FIG. 4 . 
     Those skilled in the art will appreciate that the system  100  may include other appropriate modules (not shown) to implement additional desired functionality, depending on the operator&#39;s requirements for the messaging system. The system  100  may be implemented on any computing system or device. Suitable computing systems or devices include server computers, multiprocessor systems, microprocessor-based systems, network devices, minicomputers, mainframe computers, distributed computing environments that include any of the foregoing, and the like. Such computing systems or devices may include one or more processors that execute software to perform the functions described herein. Processors include programmable general-purpose or special-purpose microprocessors, programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices. Software may be stored in memory, such as random access memory (RAM), read-only memory (ROM), flash memory, or the like, or a combination of such components. Software may also be stored in one or more storage devices, such as magnetic or optical based disks, flash memory devices, or any other type of non-volatile storage medium for storing data. Software may include one or more program modules which include routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or distributed as desired in various embodiments. 
       FIG. 3  is a flow chart of a screening, routing, and charging process  300  implemented by the message routing system  100 . At a block  305 , the system receives a message formatted in accordance with a mobile phone message standard that is to be routed to a recipient. As previously discussed, the message may be received via the MLO, MUO, or AO origination paths. At a decision block  310 , the system performs a screening check to determine whether the message should be accepted for routing or rejected. A variety of different screening checks may be performed by the system depending on the identity of the sender, the identity of the recipient, and other factors. For example,  FIG. 4  is a flow chart of a representative screening process  400  that may be implemented by the message routing system  100 . At a decision block  405 , the system compares the identity of the sender and the identity of the recipient with a blacklist representing identities of senders and/or recipients that should not be allowed to send/receive messages. Senders or recipients may be added to the blacklist for a variety of reasons, such as if they are a known fraud risk, if they committed prior acts that violated carrier policies, if they maintain an unacceptable outstanding account balance, or for any other act or omission. If the sender or recipient of the message is identified on the blacklist, processing continues at a block  430  where the system sets a “reject message” flag to indicate that the message should be rejected. If the system does not find the sender or recipient on a blacklist at decision block  405 , processing continues at a decision block  410 . 
     At decision block  410 , the system assesses whether the message is capable of being routed to the intended recipient. In order to assess whether the message is capable of being routed, the system may query a configuration entity such as a carrier&#39;s central user database (in GSM embodiments, a Home Location Register), in order to assess the location of the recipient and the ability of the recipient to receive messages. The system  100  may also check a routing configuration and application profile for the recipient in order to assess whether the recipient is configured to receive messages. For example, if the recipient is an application, the application may be an origination-only application that is not configured to receive messages. The system  100  may also check profiles associated with the sender and the recipient to determine whether the sender and/or the recipient have opted to temporarily or permanently disable messaging services based on rules/options offered by the carrier. For example, a carrier may allow a user to decline to receive any SMS or emails on a mobile device, or the carrier may allow a user to disable the sending or receipt of any messages after midnight local time but before 7 AM local time. As part of the determination of whether the message is capable of being routed, the system may also assess whether the message is likely to reach the recipient in a manner that would meet a desired quality of service (e.g., within a certain time period, having an acceptably low error rate, etc.). If the message can&#39;t be routed to the intended recipient, processing continues at block  430  where the system sets a “reject message” flag. If the system is able to route the message to a recipient at decision block  410 , processing continues at a decision block  415 . 
     At decision block  415 , the system may perform a check to determine whether the sender and/or the recipient are on a prepaid service plan. If the sender and/or recipient are on a prepaid service plan, the system determines whether the current balance on the plan is sufficient to pay the charges associated with routing the message. In order to make such a determination, the system may send an inquiry to the prepaid server  180  to request an account balance or to receive confirmation that a sufficient balance exists in the applicable account to pay the associated routing charges. If the sender or recipient has insufficient funds to pay the associated charges, processing continues at block  430  where the system sets a “reject message” flag. If the sender or recipient has sufficient funds to pay the associated charges, processing continues at a decision block  420 . 
     At decision block  420 , the system may apply one or more additional screening rules to determine whether the message should be routed to the recipient. For example, the system may route or not route messages based on operator preferences, based on messaging allowances (e.g. terminating messaging if the number of routed messages exceeds a threshold), based on temporal restrictions (e.g. no messages may be sent during certain hours), etc. If the message fails one or more of the screening rules, processing continues at block  430  where the system sets a “reject message” flag. If, however, the message passes the one or more screening rules, processing continues to a block  425 . 
     At block  425 , the routing system sets an “accept message” flag. The “accept message” flag indicates that the message has passed the screening check and should be routed by the system to the recipient. Once the screening check is completed, processing returns to the screening, routing, and charging process  300 . 
     Returning to  FIG. 3 , at decision block  310  the message is determined to have failed the screening check if the “reject message” flag is detected by the system as being set. Under this condition, processing continues to a block  315  where the message is rejected by the system for delivery. In some circumstances, the system may send an indication to the sending device or application that the message will not be routed to the recipient. Once the message fails the screening check, further processing of the message by the system is halted. If, however, at decision block  310  the message is determined to have passed the screening check by the system detecting that the “accept message” flag has been set, processing continues to a block  320 . At block  320 , the system accepts the message for delivery to the recipient. When the message is accepted for delivery, the system may acknowledge the sending device or application and may send a message to the sending device or application to indicate to the device or application that message delivery will be attempted. 
     At a block  325 , the system determines the routing necessary to route the message to its intended recipient. In some circumstances, routing rules may be provided by the configuration entity (e.g., a central user database such as a HLR) in order to allow the system to correctly forward the message to the intended recipient. The system may route the message to a recipient on one of three paths, namely the MLT, MUT, or AT termination paths. In particular, the system allows messages received from an application on the AO origination path to be routed to a different application on the AT termination path, based on a set of business rules that are associated with the particular sender, recipient, type of message, or other factor (e.g., time of day, etc.). For example, a message service reseller or portal may be allowed to send messages to and receive messages from another message service reseller or portal. Such a routing option was not commercially viable in prior routing systems due to an inability to charge for such routing. Once the routing path is determined, the system sends the message on the determined routing path to the recipient. 
     At a block  330 , the system creates a charging data record (CDR), or any similar billing log or record that allows charging or refunding, in accordance with a set of business rules that may be associated with the particular sender, recipient, type of message, or other factor (e.g., time of day, length of message, etc.). A CDR may contain information identifying the sender, receiver, type of message, time of delivery, etc. The CDR allows a charge to be levied for any message that the system routes, regardless of the source or destination of the message. The CDRs are reconciled by billing servers to charge senders and/or recipients for the routing of the message. The billing servers may charge or not charge for message deliveries based on billing rules implemented by the billing servers. For example, a billing server may not charge for voice mail notification delivery messages. In particular, CDRs that pertain to AO-to-AT messaging may be reconciled in a similar a fashion to CDRs that pertain to the more typical MLO-to-MLT messaging. 
     At a block  335 , the CDR associated with the message is transmitted via push or pull processes to one or more billing servers  185  for purposes of charging for the message routing. Those skilled in the art will appreciate that the system may transmit each CDR as it is generated, or the system may aggregate CDRs over a period of time and transmit groups of CDRs to the billing servers. The billing servers charge the appropriate party (whether sender, recipient, or application provider) based on the received CDRs. 
     From the foregoing, it will be appreciated that specific embodiments of the invention have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. For example, the CDR for a message may be generated after the screening checks have been completed at decision block  310 , but before the message is routed to the recipient at block  325 . In general, the steps shown in  FIGS. 3 and 4  may be altered in a variety of ways. The order of the steps may be rearranged, substeps may be performed in parallel, steps may be omitted, or other steps may be included. Accordingly, the invention is not limited except as by the appended claims.