U.S. patent application number 13/608657 was filed with the patent office on 2013-02-07 for short message distribution center.
The applicant listed for this patent is Michael Dewey, Richard A. Smith. Invention is credited to Michael Dewey, Richard A. Smith.
Application Number | 20130035123 13/608657 |
Document ID | / |
Family ID | 43606171 |
Filed Date | 2013-02-07 |
United States Patent
Application |
20130035123 |
Kind Code |
A1 |
Smith; Richard A. ; et
al. |
February 7, 2013 |
Short Message Distribution Center
Abstract
A message distribution center (MDC) interposed between content
providers and a wireless carrier to examine and direct messages via
SMTP based on desired rules (e.g., non-peak hours, etc.) using
standard SMTP Gateway and other well-known protocols. The MDC
includes a queue for each subscriber, and the provider is informed
through conventional SMTP protocol messages when a short message is
accepted. If the carrier disallows service for an MIN, the content
provider is informed the recipient is invalid through an SMTP
interchange. An MDC provides a single mechanism for interacting
with subscribers of multiple carriers, regardless of underlying
infrastructure. An MDC can protect a carrier's SS7 network by
throttling messages and configuring message delivery parameters to
be more network friendly. An MDC can receive outside a relevant
wireless network recipient. A content provider communicates with
the MDC using SMTP protocol messages, and the MDC communicates with
wireless carriers using RMI/SMPP techniques.
Inventors: |
Smith; Richard A.;
(Annapolis, MD) ; Dewey; Michael; (Arnold,
MD) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Smith; Richard A.
Dewey; Michael |
Annapolis
Arnold |
MD
MD |
US
US |
|
|
Family ID: |
43606171 |
Appl. No.: |
13/608657 |
Filed: |
September 10, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13373840 |
Dec 2, 2011 |
8265673 |
|
|
13608657 |
|
|
|
|
12805700 |
Aug 16, 2010 |
8073477 |
|
|
13373840 |
|
|
|
|
09832010 |
Apr 11, 2001 |
7809382 |
|
|
12805700 |
|
|
|
|
Current U.S.
Class: |
455/466 |
Current CPC
Class: |
H04L 49/90 20130101;
H04M 3/42382 20130101; H04W 88/184 20130101; H04L 51/26 20130101;
H04M 2207/18 20130101; H04M 2203/2016 20130101; H04M 2203/205
20130101; H04L 51/38 20130101; H04M 3/4872 20130101 |
Class at
Publication: |
455/466 |
International
Class: |
H04W 4/14 20090101
H04W004/14 |
Claims
1. A message distribution center interposed between a source of a
short message and a wireless network including an intended
recipient of said short message, said message distribution center
comprising: an SMTP protocol communication channel to receive said
short message from said source of said short message; a plurality
of subscriber queues each corresponding to a different subscriber
in said wireless network, said short message being placed in at
least one of said plurality of subscriber queues before delivery to
said wireless network; and a communication channel to communicate
said short message to said wireless network.
2-16. (canceled)
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] This invention relates generally to wireless carriers,
Internet service providers (ISPs), and information content delivery
services/providers. More particularly, it relates to Wireless
Telecommunication, ANSI-41D Wireless Intelligent Network (WIN)
applications, and SMTP protocol to manage information content for a
wireless carrier.
[0003] 2. Background of Related Art
[0004] There are many "wireless" information content providers in
the industry who have some information or service that is
considered of value to the mobile phone user. Wireless Carriers are
typically in favor of these content providers as they add value to
Short Messaging Systems (SMS) and can drive up SMS and voice
usage.
[0005] Unfortunately, content providers may not fully understand a
particular wireless network and/or may not be fully sensitized to
particular needs of carriers. This is because the carrier is often
seen simply as a `pipe` through which wireless messages are sent
using SMTP protocol. Content providers maintain their own
subscriber lists, and typically communicate with carriers merely as
e-mail hosts.
[0006] All traffic is typically sent through an SMTP gateway, and
thus information content, ads, etc., cannot be differentiated from
higher priority `personal` content. Problems arising from this
include: [0007] Bulk information content can slow down and even
jeopardize the carrier's SMTP Gateway performance; [0008] Personal
messages cannot be given a higher priority than bulk messages;
[0009] Bulk info content receives the same messaging parameters as
personal messages, e.g., delivery receipts enabled, expiration date
of 3-5 days, etc.; [0010] The carrier cannot differentiate between
bulk messages among various providers and personal mail for billing
purposes; [0011] Bulk senders deliver their content regardless of
whether the device is on, and thus the carrier must handle message
storage and retry attempts; and [0012] Bulk senders will typically
continue to deliver content to churned wireless subscribers,
wasting network resources and interfering with reuse of mobile
numbers.
[0013] There is a need for a technique using SMTP and/or other
conventional protocols to enable an easy way for content providers
to distribute and/or differentiate their information without
requiring them to change technologies.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] Features and advantages of the present invention will become
apparent to those skilled in the art from the following description
with reference to the drawings, in which:
[0015] FIG. 1 shows a high level sequence diagram including a
Message Distribution Center (MDC) enabling a Content Provider to
direct messages via SMTP to the Message Distribution Center (MDC),
in accordance with the principles of the present invention.
[0016] FIG. 2 illustrates exemplary software components and their
relationships in an embodiment of a message distribution center
(MDC), in accordance with one embodiment of the present
invention.
[0017] FIG. 3 is an exemplary class diagram which shows further
details of an embodiment of a Message Distribution Center, in
accordance with the principles of the present invention.
SUMMARY OF THE INVENTION
[0018] In accordance with the principles of the present invention,
a message distribution center is interposed between a source of a
short message and a wireless network including an intended
recipient of the short message. The message distribution center
comprises an SMTP protocol communication channel to receive the
short message from the source of the short message. A plurality of
subscriber queues are included, each corresponding to a different
subscriber in the wireless network. The short message is placed in
at least one of the plurality of subscriber queues before delivery
to the wireless network. A communication channel communicates the
short message to the wireless network.
[0019] In accordance with another aspect of the present invention,
a method of throttling short messages to subscribers in a wireless
network comprises forwarding a short message to a wireless network
only when a receiving wireless device in said wireless network is
known outside said wireless network to be online.
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
[0020] The present invention enables a Content Provider to direct
messages via SMTP to an intermediatary Message Distribution Center
(MDC) using standard SMTP Gateway and other well-known
protocols.
[0021] In accordance with the principles of the present invention,
short messages are inserted in the MDC into individual queues for
each subscriber, and the provider is informed through conventional
SMTP protocol messages that the short message has been
accepted.
[0022] If the carrier has specifically disallowed service for a MIN
(e.g., in the case of churning), then the content provider is
informed through an SMTP interchange that the recipient is invalid.
This encourages providers to discontinue service to terminated
MINs, thereby reducing traffic to the MDC.
[0023] A Message Distribution Center (MDC) provides value to both
wireless developers and wireless carriers. For instance, for the
Wireless Developer, an MDC provides a single mechanism for
interacting with subscribers of multiple carriers, regardless of
each carrier's underlying infrastructure. For the carrier, an MDC
can protect their SS7 network by intelligently throttling messages
and configuring message delivery parameters to be more network
friendly.
[0024] An MDC acts as a broker between carriers and developers.
Different levels of relationships can be established with both
carriers and developers, resulting in different levels of services
that are available. The MDC interacts with a carrier's Short
Message Service Center(s) (SMSCs) and/or SS7 network, allowing
developers to guarantee message delivery, to interact with users
via Mobile Terminated (MT) and Mobile Originated (MO) SMS, and
possibly even to receive handset presence information.
[0025] Although the disclosed embodiments relate primarily to
wireless services from the perspective of a Short Message Service
(SMS), the disclosed MDC and related management middleware may
support many types of wireless devices using the same API. For
instance, suitable supported devices may include, e.g., 2-way Email
pagers, the Palm VII.TM., and wireless application protocol (WAP)
devices.
[0026] The disclosed MDC utilizes a Wireless Internet Gateway
(WIG), which is a middleware messaging platform designed to
facilitate communication between Internet devices and various
wireless networks. A suitable WIG is disclosed in U.S. application
Ser. No. 09/630,762 to SMITH, entitled "Wireless Internet Gateway",
filed Aug. 2, 2000, the entirety of which is expressly incorporated
herein by reference.
[0027] FIG. 1 shows a high level sequence diagram including a
Message Distribution Center (MDC) enabling a Content Provider to
direct messages via SMTP to the Message Distribution Center (MDC),
in accordance with the principles of the present invention.
[0028] In particular, as shown in FIG. 1, an MDC 100 is placed
intermediary between a content provider 120 and a wireless carrier
130, to allow management of message delivery for each of a
plurality of subscribers. As shown in FIG. 1, the content provider
120 communicates with the MDC 100 using SMTP protocol messages, and
the MDC communicates with the wireless carrier 130 preferably using
RMI/SMPP techniques.
[0029] Importantly, the MDC 100 includes a plurality of subscriber
queues 150, preferably one for each subscriber having MDC support.
The subscriber queues 150 may be integrated within the gateway of
the MDC 100, or may be external to the gateway of the MDC 100 but
nevertheless in direct communication with the gateway of the MDC
100.
[0030] The subscriber queue 150 preferably follows a First In First
Out (FIFO) model, where the oldest messages are delivered
first.
[0031] In accordance with the principles of the present invention,
a particular wireless carrier 130 assigns a value for the maximum
number of outstanding messages for a particular subscriber. This
maximum number of outstanding messages can be used to establish a
queue threshold. Thus, if one or more new messages cause the queue
threshold to be exceeded, then the oldest messages may be deleted
first from the particular subscriber queue 150 to make room for the
new message(s). Of course, the subscriber queue 150 may be expanded
in size as desired.
[0032] To provide protection from constantly growing subscriber
queues 150, other rules may be established by the wireless carrier
130 to allow automatic deletion of particular messages from the
subscriber queue 150.
[0033] For instance, an expiration period may be established
whereby all messages more than x days old are removed. The
expiration period may be established, e.g., on an individual
subscriber basis (e.g., different subscription plans allowing
larger queues and/or longer storage times), or on a global basis
(e.g., all subscribers in a particular wireless network have a
similar expiration time).
[0034] The use of automatic deletion of short messages from
subscriber queues 150 is important, e.g., in the case of churned
MINs, so that a new subscriber does not receive lingering messages
from a previous subscriber with the same MIN.
[0035] Short messages to subscriber queues 150 may be delivered
independently from one another and/or message delivery times spaced
apart, thereby distributing message load over time and minimizing
the negative effects of batch messaging on the wireless
network.
[0036] The MDC 100 can also or alternatively be configured to avoid
sending batch messages during the carrier's busy hour(s), thereby
minimizing load pressures on the wireless network.
[0037] The use of an MDC 150 can aid the wireless carrier's network
significantly, e.g., by forwarding short messages only when the
relative handsets are turned on. Under this scenario, subscriber
queues are not processed when the handset is powered off. This can
reduce network storage requirements, delivery retry attempts, and
overall SS7 usage. The MDC 100 can do this either by interacting
with appropriate applications, e.g., with a mobile chat location
register (MCLR), or generally by intelligent use of SMS delivery
receipt data from the SMSC and Web Gateway. A suitable mobile chat
location register (MCLR) is shown and described in U.S. application
Ser. No. 09/814,363, entitled "Wireless Chat Automatic Status
Tracking", filed Mar. 23, 2001 by Ung et al., the entirety of which
is expressly incorporated herein by reference.
[0038] The MDC 100 can further be configured to send content from
various providers to certain SMPP ports on a short message service
center (SMSC). The receipt of such content allows distinct billing
records to be generated for each type of service, e.g., ads,
general content, premium content, etc.
[0039] FIG. 2 illustrates exemplary software components and their
relationships in an embodiment of a message distribution center
(MDC), in accordance with one embodiment of the present
invention.
[0040] In the disclosed embodiments, a Wireless Internet Gateway
(WIG) was modified to include another `dev/null` destination, which
acknowledges short messages from a queueMonitor, but does not
actually process them. The short messages remain in the Messages
table of the database, where they are retrieved by a software
component referred to herein as an "Intelligent Delivery Agent"
(IDA). The IDA retrieves messages from the Messages table in the
database for subscribers, e.g., when they power on their handsets,
subject to any desired rules. The IDA can become aware of
subscriber power-ups through any appropriate trigger, e.g., via an
SMPP Delivery Receipt mechanism, through Mobile Chat Location
Register (MCLR) software, etc. Preferably, the IDA throttles short
message traffic to any or all subscribers, e.g., optionally waiting
until the busy hour is over before beginning the transmission.
[0041] The MDC Gateway 100 may be, e.g., a standard WIG to which
the provider sends messages through SMTP, RMI, HTTP, or suitable
middleware software. As shown in FIG. 2, the MDC 100 includes a new
DummyDestination, which simply acknowledges receipt from a
particular subscriber queue 150, but does not attempt delivery.
Delivery may be accomplished through an Intelligent Delivery Agent
process, which polls a messages table that is populated when the
MDC Gateway 100 receives relevant short messages.
[0042] To most efficiently use the MDC gateway 100, the SMTP
session preferably assigns the msgType property based on the
sender's Email address and using InfoProviders information from the
database. This allows the MDC Gateway 100 to determine that SMTP
messages from an Information Provider (e.g., INFO.COPYRGT.NEWS.COM)
should use the Dummy Destination and be queried by the IDA. If the
short message is submitted via an RMI mechanism, then the sender
will explicitly define the msgType.
[0043] When the MDC 100 inserts a short message record, an
Oracle.TM. trigger may be used to create a subscriber record in the
Subscribers table in the database if such a record does not already
exist for the recipient.
[0044] The Subscribers table may contain, preferably at a minimum,
a MIN, status (e.g., `Online`, `Offline`, `Unknown`), and the time
of the last status update. When first created, the status may
default to `Unknown`.
[0045] The IDA may be a separate program that delivers messages
from the database to appropriate recipients via a RemoteSMPP RMI
Interface of the carrier's gateway. The IDA preferably determines
subscriber availability via, e.g., an MCLR or via Delivery
Receipts. The former approach is likely more efficient, but the
latter approach is more likely to work with most carrier
environments.
[0046] The Delivery Receipt method is considered to be more
complicated. The Delivery Receipt method attempts to find the
status of a subscriber's handset by examining delivery receipts
from messages sent to the subscriber.
[0047] As shown in FIG. 2, a SubscriberPoller agent 202 starts the
process by gathering a list of subscribers from a Subscribers table
214 at some time interval (z). If a particular subscriber is
online, then the DeliveryAgent object 210 is notified.
[0048] The DeliveryAgent 210 then gathers some pre-configured
number of messages in time order for the subscriber from the
Messages table 228 in the database, and sends them to the Carrier
gateway 238 for delivery to the subscriber. There is no delivery
receipt associated with these messages, so if the subscriber's
handset is turned off the short messages are not delivered and not
resent. This is why it is preferred that only a pre-configured
number of short messages be sent before the subscriber's status is
checked again by SubscriberPoller 202.
[0049] If a subscriber's status is unknown, then a DRDeliverAgent
234 is notified to send one message via the Carrier gateway 238 to
the subscriber with a delivery receipt requested. When it sends the
message, it sets the subscriber status as offline so that the
SubscriberPoller 202 will ignore that subscriber.
[0050] The delivery receipt will arrive at DR Listener 208. If the
delivery receipt indicates failure, then the subscriber status is
set as `unknown`, otherwise the subscriber status is set as
`online`. The SubscriberPoller 202 wakes up shortly thereafter to
take advantage of the user going online.
[0051] Because there is no direct feedback from the handset, there
is no conventional information received when a handset is turned
off or on. DBSubStatusResetter 204 makes assumptions about how long
a handset typically stays on or goes off. If a handset has been
marked as online for a period of time (x), then DRSubStatusResetter
204 sets the corresponding subscriber status to `unknown`, which
will restart the delivery receipt cycle again. If a subscriber has
been marked as `offline` for a different period of time (y), then
the subscriber is marked as unknown, again restarting the delivery
receipt cycle.
[0052] To summarize, there are three time periods involved in the
Delivery Receipt method. Time x is the average time that a handset
is online. Time y is the average time that a handset is offline.
Time z is how often the Subscribers table 214 is polled for a list
of subscribers.
[0053] The three periods mentioned (x, y, and z) must have a
certain relationship to one another. Time z must be smaller than
time x and time y. Time x and time y's relationship to one another
doesn't matter. Time z must be smaller than time x so that when a
subscriber goes online, messages are sent to it before time x
expires and online subscribers are set to `unknown`. Time z should
be smaller than time y, otherwise the subscriber will be sent
another message before DR Listener 208 has had a chance to receive
the delivery receipt. This implies that time z will also be longer
than the expected time for a delivery receipt.
[0054] A SubscriberCleanUp agent may be implemented to clean out
subscribers that haven't had messages sent to them for a
pre-defined period of time. This will ensure that the subscriber
database doesn't grow without bound. Subscribers may have taken
their name from the information provider's subscriber list.
[0055] Another technique mentioned above is to use an MCLR
facility. In this situation, the MCLR will know explicitly when a
handset is turned off or on. The MCLR Listener 218 then updates the
Subscribers table 214 accordingly. The SubscriberPoller 202 always
sees only online subscribers. It then uses the DeliveryAgent 210 to
send the messages without a delivery receipt requested.
[0056] When the MCLR Listener 218 is active, then the
DRDeliverAgent 234, DR Listener 208, and DBSubStatusResetter 204
are all inactive. When the three delivery receipt entities are
active, then the MCLR Listener 218 is inactive.
[0057] The IDA Main 232 activates appropriate facilities based on a
configuration file.
[0058] In an MCLR implementation, the DRDeliveryAgent 234, DR
Listener 208, and DRSubStatusResetter 204 may not be used.
[0059] FIG. 3 is an exemplary class diagram which shows further
details of an embodiment of a Message Distribution Center, in
accordance with the principles of the present invention. In
particular, FIG. 3 shows exemplary classes that may be activated
and used to determine subscriber status and to actually deliver
messages.
[0060] As shown in FIG. 3, an IDA main class 318 is responsible for
deciding which subscriber status determination strategy to use. The
IDA class 318 may receive this information from a configuration
file. The IDA class 318 instantiates and activates an MCLRListener
class 314 if that facility is to be used to retrieve a handset's
online/offline status. If the strategy is to use delivery receipts,
then the IDA class 318 instead instantiates and activates the
DRListener 322 and DRSubStatusResetter 316 classes.
[0061] A SubscriberPoller 306 class gets a list of subscribers
whose status is `unknown` or `online` from the database. If a
subscriber's status is `unknown`, the SubscriberPoller 306 invokes
a method in a DeliveryAgent class 302 to send a message requesting
a delivery receipt. If the subscriber's status is `online`, then
the DeliveryAgent 302 sends messages without a delivery receipt to
the subscriber.
[0062] The DeliveryAgent 302 is responsible for averaging out the
load on the carrier's system. It may do this by spreading out the
messages over time, allowing normal traffic to be sent more
quickly. The DeliveryAgent 302 may also hold off sending batch
messages during the carrier's busy time. This information may be
maintained in a configuration file and retrieved through a
DeliverySetupInfo class.
[0063] The DeliveryAgent 302 can also be configured to send
messages over certain SMPP ports to the carrier gateway 238 for
tracking the amount of traffic that an information provider is
sending. The DeliveryAgent 302 may accomplish this by tagging the
message with a message type indicating that it is an MDC message.
The configuration file may be set up so that messages of an MDC
type will be sent to certain SMPP ports by the carrier gateway
238.
[0064] Both the Subscribers 300 and Messages 304 classes may be
wrappers around their respective database tables, to isolate JDBC
calls to these classes only and/or to place the data in a useful
format.
[0065] The IDA 318 may send messages and/or decide blackout periods
on a global basis, i.e., regardless of the destination of any
particular message. One enhancement to this is to apply these on a
per-carrier basis since carriers can be in different time zones or
have more or less capable hardware.
[0066] One advantage provided by the present invention is that SMTP
is a well-known protocol and an easy way for content providers to
distribute their information.
[0067] A Message Distribution Center (MDC) in accordance with the
principles of the present invention provides an ideal solution. It
addresses the problems faced by the carrier without requiring the
information providers to change technologies.
[0068] The principles of the present invention have applicability
for usage with wireless intelligent network (WIN) and SMTP
applications, e.g., those already otherwise containing a Internet
gateway application for routing information through an SMTP
gateway. Moreover, the MDC allows content providers to continue
with their current mode of operation without placing the carrier's
network at risk. The MDC can receive messages using a variety of
protocols, including SMTP. It automatically routes messages to the
appropriate carrier based on MIN range. Instead of delivering SMTP
content directly to the carrier, it is delivered to the MDC. The
MDC then ensures that the content is delivered in a
`carrier-friendly` manner.
[0069] MDC can provide the Info Provider with delivery statistics,
e.g., what percentage of messages are being delivered.
[0070] The MDC helps prevent the carrier from being overwhelmed by
bulk messaging content and provides the following benefits: [0071]
bulk message traffic is distributed across time [0072] messages are
delivered over more efficient protocols than SMTP through the
carrier's Wireless Internet Gateway [0073] messages are only
delivered when handsets are on, thereby eliminating network storage
and retries [0074] messages are delivered with appropriate urgency,
delivery receipt, expiration times, and billing identifiers [0075]
individual bulk message queues allow the carrier to limit the
number of messages that can be queued per subscriber [0076] bulk
messaging can be disabled for individual accounts when subscribers
churn [0077] bulk message delivery statistics are available to the
carrier via a web interface.
[0078] While the invention has been described with reference to the
exemplary embodiments thereof, those skilled in the art will be
able to make various modifications to the described embodiments of
the invention without departing from the true spirit and scope of
the invention.
* * * * *