ARCHIVE CONTROL FOR TEXT MESSAGES
Field of the Invention
The invention is related to the field of communications and, in particular, to text
messaging, such as Short Message Service (SMS).
Background
Text messaging has become a popular mode of communication in many mobile (or
wireless) networks. One example of text messaging is Short Message Sendee (SMS),
which is a set of communication protocols allowing the exchange of short text messages
(i.e., 160 characters or less) between devices. While the term "text message" traditionally
referred to text-only messages sent using SMS, it has been extended to include multimedia
messages, such as images, video, sound content, etc. The multimedia messages may be sent
using Multimedia Message Service (MMS) protocol. Many mobile users more frequently
use text messaging for communication than voice calls.
One service offered for SMS messaging is an archive sendee or backup sendee. An
archive sendee allows end users to store a record of SMS messages that are sent or received
through a particular mobile device. For example, an application may be loaded onto a
mobile device that is programmed to send a copy of SMS messages that are sent or received
to a secure online server for long-term storage. The end user may then access the SMS
record at a later time. In another example, service providers may implement an archive
server that stores text messages for end users that subscribe to an archive sendee.
Summary
Embodiments described herein provide control over archiving of text messages.
Present archive/backup sendees store all text messages associated with an end user or a
mobile device. The present archive/backup sendees do not provide protection on how or
which text messages are stored. Some of the text messages may be private in nature, such
as messages that include financial or medical content. Thus, it is desirable to implement
controls on how/which text messages are archived. In the embodiments described herein,
protection information is inserted in a text message to indicate whether the text message is
authorized to be archived. The devices and systems that handle the text message may then
process the protection information before archiving the text message. Thus, there is a
determination made on a message-by-message basis as to whether a text message is
archived.
One embodiment comprises a system that inserts protection information in a text
message. Some examples of a system in this embodiment are end user devices (e.g., a
mobile phone) and automated message centers (e.g., ESME). The system includes a
controller operable to identify a text message for delivery over a mobile network, and to
identify protection information for controlling archiving of the text message. The controller
is further operable to insert the protection information in the text message, such as in user
data (i.e., payload) of the text message. The system further includes a network interface
operable to transmit the text message with the protection information towards a destination
over the mobile network.
In another embodiment, the controller is further operable to insert the protection
information in user data of the text message, such as in an Information Element (IE) of a
User Data Header (UDH) in the user data.
In another embodiment, the system further includes a user interface operable to
query an end user for the protection information applicable to the text message, and to
receive input from the end user indicating the protection information.
In another embodiment, the protection information includes a protection class which
is a category of text messages that share a similar type of content, and a protection level
indicating a degree of protection desired for text messages in the protection class.
Another embodiment comprises a method of inserting protection information in a
text message. The method includes identifying a text message for delivery over a mobile
network, and identifying protection information for controlling archiving of the text
message. The method further includes inserting the protection information in the text
message, and transmitting the text message with the protection information towards a
destination over the mobile network.
Another embodiment comprises a system that controls archiving of text messages.
Some examples of a system in this embodiment are message centers (e.g., an SMSC) and
archive servers. The system includes a network interface operable to receive a text
message. The system further includes a controller operable to identify protection
information inserted in the text message, such as in the user data. The controller is further
operable to identify an end user associated with the text message (e.g., sender or recipient),
and to identify privacy policies provisioned for the end user. The controller is further
operable to process the privacy policies and the protection information to determine if the
text message is authorized to be archived. If authorized, then the controller is further
operable to initiate archiving of the text message. If not, then the controller is further
operable to block the text message from being archived.
Another embodiment is a method of controlling how text messages are archived.
The method includes receiving a text message, and identifying protection information
inserted in the text message. The method further includes identifying an end user associated
with the text message, and identifying privacy policies provisioned for the end user. The
method further includes processing the privacy policies and the protection information to
determine if the text message is authorized to be archived. If authorized, then the method
includes initiating archiving of the text message. If not, then the method includes blocking
the text message from being archived.
Other embodiments include control for forwarding or copying text messages.
Description of the Drawings
Some embodiments of the present invention are now described, by way of example
only, and with reference to the accompanying drawings. The same reference number
represents the same element or the same type of element on all drawings.
FIG. 1 illustrates a communication system in an exemplary embodiment.
FIG. 2 illustrates a text-enabled device in an exemplary embodiment.
FIG. 3 is a flow chart illustrating a method of inserting protection information in a
text message in an exemplary embodiment.
FIG. 4 illustrates a text message in an exemplary embodiment.
FIG. 5 illustrates a message center in an exemplary embodiment.
FIG. 6 is a flow chart illustrating a method of controlling how text messages are
archived in an exemplary embodiment.
FIG. 7 illustrates a communication system in another exemplary embodiment.
Description of Embodiments
The figures and the following description illustrate specific exemplary embodiments
of the invention. It will thus be appreciated that those skilled in the art will be able to
devise various arrangements that, although not explicitly described or shown herein,
embody the principles of the invention and are included within the scope of the invention.
Furthermore, any examples described herein are intended to aid in understanding the
principles of the invention, and are to be constmed as being without limitation to such
specifically recited examples and conditions. As a result, the invention is not limited to the
specific embodiments or examples described below, but by the claims and their equivalents.
FIG. 1 illustrates a communication system 100 in an exemplary embodiment.
Communication system 0 includes a text-enabled device 0 connected to a mobile
network 120. Device 0 comprises any system, server, or end user device operable to send
or receive text messages, such as SMS or MMS messages. Device 10 may comprise an
end user device (or User Equipment (UE)), such as a mobile phone. Device 1 0 may
alternatively comprise an automated message center that generates text messages, such as an
External Short Messaging Entity (ESME). Typical examples of ESMEs are systems that
send automated marketing messages to mobile users, voting systems that process text
message votes, etc.
Mobile network 120 provides services to device 0 and other devices not shown.
The services offered and provided by mobile network 120 may vary, but at a minimum,
device 110 has subscriptions for text messaging with mobile network 120. Mobile network
20 may comprise a circuit-switched mobile network, such as a cdma2000 network, a GSM
network, etc. Mobile network 120 may also comprise a packet-switched network, such as
an IP Multimedia Subsystem (IMS) network or a Long Term Evolution (LTE) network.
Because mobile network 120 may represent different types of networks, device 0 may
likewise represent different types of devices, such as mobile or cellular devices, wireline
devices, SIP phones, dual mode devices, etc.
In this embodiment, mobile network 120 includes a message center 122. Message
center 122 comprises any system, server, or device that facilitates delivery of text messages.
For example, message center 22 may comprise a Short Message Se ice Center (SMSC), a
Multimedia Message Service Center (MMSC), an IP Short Message Gateway (IP-SM-GW),
etc. Because message center 122 may be implemented in multiple locations within network
120, it is merely shown as being included wdthin network 20 and not tied to any specific
network node. Although not shown in FIG. , those skilled in the art understand that other
servers or nodes are connected between device 10 and message center 122, such as base
stations, wireless access points, switching systems (e.g., MSC or S-CSCF), gateways, etc.
Mobile network 0 further includes an archive server 124. Archive server 124
comprises any system, server, or device that archives or otherwise saves text messages for
long-term storage. Mobile network 120 may offer a service that allows end users to backup
their text messages to a server instead of having to save the text messages on their phones.
An archive sendee such as this may be provided by archive serv er 124 so that text messages
sent or received by end users will be backed-up to server 124. Archive server 124 may be
provided by a third party that is not affiliated with the service provider of mobile network
120.
FIG. 2 illustrates text-enabled device 0 in an exemplary embodiment. Device 0
includes a network interface 202, a controller 204, and a user interface 206. Network
interface 202 comprises any components, devices, or functions operable to exchange
communications with other elements (e.g., message center 122) over network 120.
Controller 204 comprises any components or devices operable to control the operations of
device 1 0 . User interface 206 comprises any components, devices, or functions operable
to receive input from an end user, such as a keypad, a pointing device, etc, and/or convey
content to the end user, such as a display, a speaker, etc.
In the embodiment described below, when device 0 sends a text message,
protection information is inserted in the text message to control whether or not the text
message is allowed to be archived. The protection information advantageously provides a
layer of privacy for end users so that selected text messages are archived and selected text
messages are blocked from being archived; especially the text messages that contain
sensitive content, such as financial or medical content.
FIG. 3 is a flow chart illustrating a method 300 of inserting protection information in
a text message in an exemplary embodiment. The steps of method 300 will be described
with reference to device 10 in FIGS. 1-2, but those skilled in the art will appreciate that
method 300 may be performed in other devices or systems. The steps of the flow charts
described herein are not all inclusive and may include other steps not shown. The steps may
also be performed in an alternative order.
In step 302, controller 204 (see FIG. 2) identifies a text message for delivery over
mobile network 120. Controller 204 may identify the text message when an end user
creates a new text message. Controller 204 may identify the text message when an end user
selects an existing text message for reply, forward, or a similar function. Still further,
controller 204 may identify the text message when an automated application creates a text
message.
In step 304, controller 204 identifies protection information for the text message.
Protection information comprises any data that controls archiving of the text message in a
network. The protection information may include a protection class that applies to the text
message. A protection class is a category of text messages that share a similar type of
content. For example, a protection class may be financial, medical, health, parental control,
business, social, etc. Thus, text messages that include financial content may be grouped
into a common protection class. Text messages that include medical content may be
grouped into a common protection class. The protection class may be indicated by a string
or value, such as A, B, C, etc.
The protection information may alternatively or additionally include a protection
level. A protection level is a degree or amount of protection desired for text messages, such
as in a protection class. The protection level may be indicated by a range of integers, such
as from 1 to 5. If the protection level is "5" for instance, then a high level of protection is
desired for archiving the text message (e.g., no archiving is allowed). This protection level
may be desired for financial or medical classes of text messages. If the protection level is
"1" for instance, then a lower level of protection is desired for archiving the text message
(e.g., archiving is always allowed). This protection level may be desired for social classes
of text messages.
Controller 204 may identify the protection information by querying an end user
through user interface 206 (assuming that device 0 is an end user device). When the end
user composes a new text message or attempts to copy or forward an existing text message,
controller 204 may ask the end user for the privacy information via user interface 206. The
query may be for a protection class for the text message (e.g., financial, medical, etc),
and/or for a protection level (e.g., 1, 2, 3, or high, medium, low). User interface 206 then
receives input from the end user indicating the desired protection information, and the user
interface 206 provides the end user input to controller 204.
Controller 204 may alternatively identify the protection information by locating
predefined or pre-provisioned information stored in device 0 . This may be the case if
device 110 is an automatic message server, such as an ESME. Those skilled in the art will
appreciate that user interface 206 of device 0 may not be needed if device 10 comprises
an ESME instead of an end user device.
In step 306, controller 204 inserts the identified protection information in the text
message. Controller 204 may insert the protection information in a header of the text
message (or a signaling message encapsulating the text message), or in the payload or body
of the text message. Text messages are encoded as a header and a payload in a Protocol
Description Unit (PDU). FIG. 4 illustrates a text message 400 in an exemplary
embodiment. Text message 400 includes header 410 and payload 420. Header 410
includes metadata for transporting the text message, such as an originating address for the
text message, a destination address for the text message, etc. Payload 420 includes the
actual content for the text message.
Controller 204 may insert the protection information in the user data of payload 420.
For example, controller 204 may insert the protection information in a User Data Header
(UDH) 422 of payload 420 (Short Message Transport Layer (SM-TL) of the 3GPP
specifications) as shown in FIG. 4. More particularly, UDH 422 includes a User Data
Header Length (UDHL) parameter 430 and one or more Information Elements (IE) 432-
433. Each Information Element (IE) 432 includes the following sub-parameters (typically
in octets): Information Element Identifier (IEI) 442, Information Element Data Length
(IEDL) 444, and Information Element Data (IED) 446. Controller 204 may insert the
protection information in an IE or IEI.
In another example, controller 204 may insert the protection information in a User
Data parameter of payload 420 (based on 3GPP2 specifications). The User Data parameter
is part of the Teleservice Layer in the 3GPP2 protocol stack. The protection information
may be inserted in the "reserved parameter" of the User Data.
In step 308, network interface 202 transmits the text message with the inserted
protection information towards a destination over mobile network 120. In FIG. 1, network
interface 202 may transmit the text message (in the appropriate signaling message) to
message center 122 in mobile network 120. In response to the text message, message center
22 may perform store-and-forward processing to attempt delivery of the text message to a
destination (not shown).
The description above applies to a text message sent from device 0 to mobile
network 120. However, method 300 may also be performed in message center 122 or in
another element of mobile network 120. FIG. 5 illustrates message center 122 in an
exemplar}' embodiment. Message center 122 includes a network interface 502 and a
controller 504. If message center 22 receives a text message, such as a text message
destined for device 1 0 (see FIG. 1), then message center 122 may perform method 300 as
follows. Controller 504 (see FIG. 5) identifies the text message for delivery over mobile
network 20 in step 302 (which is the received text message).
Controller 504 then identifies protection information for the text message (step 304).
When method 300 is performed in a network element such as message center 122, the
protection information may be predefined or pre-provisioned in a subscriber profile. Thus,
when the text message is identified for a particular end user, controller 504 identifies the
proper profile and identifies the protection information predefined in the profile. Controller
504 may then insert the identified protection information in the text message (step 306).
The protection information inserted in the text message may be new, or may modify (or
delete) protection information already inserted in the text message. Network interface 502
then transmits the text message with the inserted protection information towards a
destination (step 308) as part of store-and-forward processing.
One assumption when handling a text message in message center 122 is that either
the sender or recipient of the text message has subscribed to an archive service (or backup
service) for storing copies of the text messages for later use. Thus, message center 122 may
communicate with archive server 124 to store a copy of the text message. Before the text
message can be archived, message center 122 may operate as described in FIG. 6 to control
whether the text message is archived.
FIG. 6 is a flow chart illustrating a method 600 of controlling how text messages are
archived in an exemplary embodiment. The steps of method 600 will be described with
reference to message center 122 in FIG. 1 and FIG. 5, but those skilled in the art will
appreciate that method 600 may be performed in other devices or systems.
After the text message is received, controller 504 identifies the protection
information inserted in the text message in step 602. To do so, controller 504 may parse the
header or the user data (i.e., payload) of the text message to identify the protection
information. Controller 504 then identifies an end user associated with the text message in
step 604. For example, controller 504 may parse the header of the text message to identify a
director}' number, a network address, a public identifier (PUID), or some other information
that identifies an end user that sent or will receive the text message.
In step 606, controller 504 identifies privacy policies defined or provisioned for the
end user. The privacy policies may be stored in a subscriber profile for the end user that is
stored locally on message center 22 or stored on a remote system. The privacy policies
comprise any rales that control archiving (and/or forwarding/copying) of text messages
involving the end riser. The privacy policies may be defined by the end user or the service
provider operating mobile network 120. The privacy policies may take the following
conditions into account:
- Protection class
- Protection level
Copying/Fonvard/Archiving destinations
Source address
- Destination address
- Time of Day, Day of Week, etc.
- Message types
- Network domain
- Protocols
- Languages
- Routing methods
Charging methods
Usage control rales
In step 608, controller 504 processes the protection information and the privacy policies
(and possibly other information, such as the destination address) to detennine if the text
message is authorized to be archived. For example, if the protection information indicates a
protection class of "financial" and a protection level of "1", then the privacy policies may
indicate that the text message is authorized to be archived. If the protection information
indicates a protection class of "financial" and a protection level of "3", then the privacy
policies may indicate that the text message is not authorized to be archived. The privacy
policies may take other information into account such as the source of the text message, the
destination of the text message, the time of day, etc.
If the text message is authorized, then controller 504 initiates archiving of the text
message in archive server 124 (in step 610). For example, controller 504 may send the text
message to archive server 124 for storage. If the text message is not authorized, then
controller 504 blocks the text message from being archived in archive server 24 (in step
612). For example, controller 504 may refrain from sending the text message to archive
server 124 for storage.
Although method 600 has been described in terms of archiving text messages, a
similar method may be used for forwarding text messages, copying text messages, etc.
If message center 122 sends the text message to archive server 124 without
performing archiving control as described in method 600, then archive server 124 may
operate similar to method 600. Archive server 4 may have a similar structure as shown in
FIG. 5 with a network interface and a controller. When archive server 124 receives the text
message from message center 122 for archiving, archive server 124 operates as in method
600 before storing the text message. In particular, the controller in archive server 24
identifies the protection information inserted in the text message (step 602), and identifies
an end user associated with the text message (step 604). The controller then identifies the
privacy policies defined for the end user (step 606). The controller processes the protection
information and the privacy policies to determine if the text message is authorized to be
archived (step 608). If the text message is authorized, then the controller initiates archiving
of the text message (in step 610). For example, the controller may store the text message in
a local memory. If the text message is not authorized, then the controller blocks the text
message from being archived (in step 612). For example, the controller may refrain from
storing the text message in the local memory.
By controlling how individual text messages are archived in the above
embodiments, end users advantageously have more privacy with sensitive text messages.
Instead of archiving all text messages, end users can specify which text messages are
archived through the protection information and the privacy policies. And, there is a
determination made on a message-by-message basis as to whether the message is allowed to
be achieved. Thus, private text messages, such as those being financial and medical in
nature, will not be archived and at risk of being viewed by unauthorized individuals.
Example
FIG. 7 illustrates a communication system 700 in another exemplary embodiment.
Communication system 700 includes a mobile network 720 that provides sendee to a
mobile device 730. Mobile network 720 is also connected to an ESME 710 of a bank 712.
ESME 7 0 is configured to send credit card transaction confirmations to mobile device 730
via SMS messages. Thus, when an end user of mobile device 730 uses his/her credit card,
ESME 7 0 composes an SMS message with the credit card transaction confirmation.
ESME 710 is also configured to provide archiving protection as discussed above.
Therefore, ESME 710 identifies the SMS message that was composed for mobile device
730, and identifies protection information for the SMS message. The SMS message in this
example is financial in nature. Therefore, ESME 7 0 identifies the protection information
as having a protection class "B" (financial) and a protection level "5" (high) for the SMS
message. ESME 710 then inserts the protection information in the user data of the SMS
message, and transmits the SMS message to SMSC 722. In response to the SMS message,
SMSC 722 may perform store-and-forward processing to attempt delivery of the SMS
message to mobile device 730.
In this example, the end user has subscribed to a service that archives SMS
messages. Before archiving the SMS message in this instance, SMSC 722 identifies the end
user associated with the SMS message, and identifies a subscriber profile for the end user.
The subscriber profile includes privacy policies defined for archiving SMS messages.
SMSC 722 processes the protection information inserted in the SMS message, and the
privacy policies to determine whether this SMS message is allowed to be archived. In this
example, the privacy policies disallow archiving of the SMS message to archive server 724
based on a protection class "B" and a protection level "5". Therefore, SMSC 722 blocks the
SMS message from being sent to archive server 724 for long-term storage.
The end user also subscribes to a service that forwards a copy of SMS messages to
an email account for the end user. Before forwarding the SMS message in this instance,
SMSC 722 processes the protection information inserted in the SMS message, and the
privacy policies to determine whether this SMS message is allowed to be forwarded. In this
example, the privacy policies allow forwarding of the SMS message to an email server 740
(which is hosting the email account of the end user) based on a protection class "B" and a
protection level "5". Therefore, SMSC 722 forwards the SMS message to email server 740.
As is evident in this example, the end user of mobile device 730 is able to control
whether a sensitive SMS message (i.e., an SMS message containing information on a credit
card transaction) is archived or forwarded. A similar process is performed for each
individual SMS message that involves this end user. Thus, only authorized SMS messages
are archived/fonvarded instead of every SMS message.
Any of the various elements shown in the figures or described herein may be
implemented as hardware, software, firmware, or some combination of these. For example,
an element may be implemented as dedicated hardware. Dedicated hardware elements may
be referred to as "processors", "controllers", or some similar terminology. When provided
by a processor, the functions may be provided by a single dedicated processor, by a single
shared processor, or by a plurality of individual processors, some of which may be shared.
Moreover, explicit use of the term "processor" or "controller" should not be construed to
refer exclusively to hardware capable of executing software, and may implicitly include,
without limitation, digital signal processor (DSP) hardware, a network processor,
application specific integrated circuit (ASIC) or other circuitry, field programmable gate
array (FPGA), read only memory (ROM) for storing software, random access memory
(RAM), non volatile storage, logic, or some other physical hardware component or module.
Also, an element may be implemented as instructions executable by a processor or a
computer to perform the functions of the element. Some examples of instructions are
software, program code, and firmware. The instructions are operational when executed by
the processor to direct the processor to perform the functions of the element. The
instructions may be stored on storage devices that are readable by the processor. Some
examples of the storage devices are digital or solid-state memories, magnetic storage media
such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data
storage media.
Although specific embodiments were described herein, the scope of the invention is
not limited to those specific embodiments. The scope of the invention is defined by the
following claims and any equivalents thereof.
We claim:
. A system comprising:
a controller operable to identify a text message for delivery over a mobile network,
to identify protection information for controlling archiving of the text message, and to insert
the protection information in the text message; and
a network interface operable to transmit the text message with the protection
information towards a destination.
2. The system of claim 1 wherein:
the controller is further operable to insert the protection information in user data of
the text message.
3. The system of claim 2 wherein:
the controller is further operable to insert the protection information in an
Information Element (IE) of a User Data Header (UDH) in the user data.
4. The system of claim 1 further comprising:
a user interface operable to query an end user for the protection information
applicable to the text message, and to receive input from the end user indicating the
protection information.
5 . The system of claim 1wherein:
the protection information includes:
a protection class which is a category of text messages that share a similar
type of content; and
a protection level indicating a degree of protection desired for text messages
in the protection class.
6 . A method comprising:
identifying a text message for delivery over a mobile network;
identifying protection information for controlling archiving of the text message;
inserting the protection information in the text message; and
transmitting the text message with the protection information towards a destination.
7 . The method of claim 6 wherein inserting the protection information in the text message
comprises:
inserting the protection information in user data of the text message.
8. The method of claim 7 wherein inserting the protection information in user data of the
text message comprises:
inserting the protection information in an Information Element (IE) of a User Data
Header (UDH) in the user data.
9 . The method of claim 6 further comprising:
querying an end user for the protection information applicable to the text message.
The method of claim 6 wherein:
the protection information includes:
a protection class which is a category of text messages that share a similar
type of content; and
a protection level indicating a degree of protection desired for text messages
in the protection class.