GB2436183A

GB2436183A - Monitoring selection of an embedded link in a message

Info

Publication number: GB2436183A
Application number: GB0610519A
Authority: GB
Inventors: Ian Daly; Alexey Gabsatarov
Original assignee: Empower Interactive Group Ltd
Current assignee: Empower Interactive Group Ltd
Priority date: 2006-03-17
Filing date: 2006-05-26
Publication date: 2007-09-19
Anticipated expiration: 2026-05-26
Also published as: GB0610519D0; GB2436183B; GB2436184B; GB2436184A; GB0610520D0

Abstract

A method is described for handling messages in a network. The method comprises: transmitting a message to at least one destination entity, wherein the message includes first content and a selectable link to further content associated with the message and wherein selection of the link triggers supply of the further content; monitoring selection of the link; in response to selection of the link, updating feedback data associated with the message; communicating feedback data to an entity associated with the originator of the message. The messages may be multi media messages with links to further contents, and the system provides feedback in response to selection of the link. Monitoring selection of the link comprises recording each request for access to the link. The link may be an embedded link and may be applied to a message sent to a plurality of destinations.

Description

Message Monitoring System and Method The present application relates to

the field of mobile telecommunications and, in particular, to the sending of messages, for example multimedia messaging service (MMS) messages, between elements in a mobile telecommunications network.

Messaging applications, such as content providers or marketing applications, send out batches of messages to selected destination entities. Once a message has been distributed to its destinations, however, the originating messaging application receives very little feedback in relation to the message and it is difficult for the originator to determine the effect of the message on its recipients.

According to one aspect, there is provided a method of handling messages in a network, the method comprising: 1 5 transmitting a message to at least one destination entity, wherein the message includes first content and a selectable link to further content associated with the message and wherein selection of the link triggers supply of the further content; monitoring selection of the link; in response to selection of the link, updating feedback data associated with the message; communicating feedback data to an entity associated with the originator of the message.

Hence the present method may enable the handling and monitoring of a message by determining whether a user selects an embedded link. This may provide an indication of how interested the user is in a particular message or its subject matter. The method may be applied to a message sent to a plurality of destinations and the feedback data may then provide an indication of the proportion of destination users interested in the message content.

Preferably, monitoring selection of the link comprises recording each request for access to the link. Hence the request may be counted, rather than counting the selection on provision of the data.

In one embodiment, the selection of the link is monitored at a component storing the further content associated with the message. For example, a web server that stores the further content may also be implemented with a monitoring agent for monitorin requests to access the further content.

In an alternative embodiment, the selection of the link is monitored at a message transmission component in the network. For example, in one embodiment, the request to access the content may pass from the destination entity back into the network before being transmitted to the component storing the content. A component in the network may then record the request. Such a component may be implemented as a separate physical entity but, preferably, is implemented as an agent or application running on one or more existing components in the network.

In a preferred embodiment, the feedback data comprises a measure of the selection of the link to the further content resulting from the transmission of the message. In the case of just one message, this may simply comprise a binary "Message Selected?" Yes/No indication. For a situation wherein a plurality of messages containing the same link has been set to a plurality of destinations, the feedback data may include an indication of the proportion of destination entities that selected the link.

The feedback data may further comprise an indication of the time between the transmission of the messag to the at least one destination entity and the selection of the link.

In a preferred embodiment, the further content is external to the message.

Alternatively, the further content may comprise a further portion of the message.

In a highly preferred embodiment, the selectable link comprises a URL.

Preferably, the further content comprises Internet-based content. However, the content may be accessed from the Internet via a mobile telecommunications network.

In one embodiment, the feedback data includes an identifier of the selecting destination entity. Hence the data may include details of each user who selected the link. For example, the details may comprise the MSISDN number of the destination entities that select the link. This may enable the message originator to direct further messages to users who are likely to be interested in the message content.

In one embodiment, the entity associated with the originator of the message comprises a message-originating application. Hence the feedback data may be communicated back to the source of the original message.

In an alternative embodiment, the entity associated with the originator of the message comprises a central feedback system. The feedback system may receive data relating to a plurality of different messages originating from a plurality of different sources. Once the feedback has been gathered, this data may be transmitted to the message originators.

Apparatus aspects corresponding to the method aspect set out above may also be provided and computer program, computer program product and computer readable medium aspects for carrying out the method aspect may also be provided. Features of one aspect may be applied to other aspects and features set out in the following description may also be implemented in conjunction with the aspects set out above.

Embodiments of the system will now be described in more detail with reference to the drawings in which: Fig. I illustrates components of a message transmission network according to one embodiment; Fig. 2 is a schematic diagram of a portion of a message transmission network according to one embodiment; Fig. 3 illustrates one embodiment of a message transmission network including

components of a prior art system;

Fig. 4 illustrates a further embodiment of a message transmission system; Fig. 5 illustrates one embodiment of components of the MDSA system; Fig. 6 illustrates a system for monitoring access to enbedded links according to one embodiment.

One embodiment of a prior art system and network will now be described in relation to Fig. 3.

In the prior art system, when an application sends an MMS, the application transmits the data via a network to a recipient MMSC. Upon receipt of the MMS message, the MMSC communicates via a Push Proxy Gateway system to,a Short Message Service Centre (SMSC) which SMSC then sends an SMS (Short Message Service) message to the final destination message entity (for example a Short Message Entity (SME), such as a mobile telephone). This SMS notification message informs the destination entity that an MMS is available for download, it contains a Universal Resource Locator (URL) which directs the entity to the message Content on the MMSC.

In a conventional MMS delivery system, with reference to Fig. 3, once a message is received at the MMSC 310 and the destination entity 320 has been notified via SMS of an message awaiting download, to retrieve the MMS message from the MMSC, the destination entity 320 sets up a connection to the MMSC 310.

The connection may be implemented, for example across a GPRS system 314 via an SGSN 318, a GGSN 316 and a WAP G/W 312; the MMSC 310 then transmits the message to the destination 320 over the connection that has been opened, via the WAP G/W 312.

If an application sends a number of identical messages to different destination entities, the MMSC will receive these messages and process each one individually; currently, there is no mechanism to remove the redundancy associated with such an operation.

One embodiment of an improved system will now be described with reference to Fig. I. In this embodiment, a bulk A2P MMS message is sent by an application 110 via a network 112 to a Mobile Services Platform (MSP) 114 that stores the original content in a storage unit 113. By sending only a single bulk message to the MSP instead of a number of individual MMS messages, this invention reduces backhaul (the amount of data that needs to be transmitted from the application to the MSP).

The MSP is connected to a transformation engine 1 15 that transcodes the MMS message into a number of SME-specific formats according to a predefined list of possible message formats. This may include transcoding the audio and/or video content of a message.

The MSP 114 then transfers the MMS message in its various pretranscoded forms to one or more MMI proxy units 118. Each MMI proxy 118 unit has a memory facility 120 in which to store the preformatted and original MMS message data.

Contact is then established between relevant MM I proxy 11 8 and the destination entity 130, the formatting requirements of the destination entity are determined, and the appropriate pre-formatted MMS message is downloaded.

Contact may be established between the MMI proxy 118 and the destination entity 130 via an MMS notification from the MSP 114, or in the same way as for MMSCs, using an SMS notification message. In the latter case, the proxy may implement some of the functionality of the PPG and WAP gateway components.

If an SME requires a format that has not been catered for and pretranscoded by the MSP, the proxy may perform dynamic transcoding prior to downloading. Each MMI proxy may performs MSISDN resolution for the destination entities preferably using a RADIUS lookup system.

In one embodiment, the transformation engine may be implemented at he MM I proxy rather than the MSP, and transcoding may be carried oit there. Pretranscodedmessages may then be transmitted to other proxies via a separate connection between the proxies.

The MSP, MMI proxy or both may contain Digital Rights Management (RM) enforcement software, which may ensure that messages and their contents may be transmitted to their respective destinations. Similarly, the system, preferably the MSP, includes an interface to a charging component for ensuring that messages are billed correctly to the destination or originating entity. Further, the MSP, MMI proxy or both may contain virus scanning software, virus blocking software, or both. Further, either, or both the MSP and MM] proxies may contain network load balancing software, or load balancing between network components may be implemented at a separate component.

The systems described herein may provide support for: MMI, MM7 R5, MM7 R6 and web services Application Program Interface (API).

As described above, in one embodiment, the transformation engine may only transcode the original message according to the types of SME that will receive the message.

Knowledge of which types of SMEs will receive the message may be determined through user interaction, user interrogation, statistical analysis of previous A2P distributions, statistical analysis of previous responses, statistical analysis of the expected demographic or sociographic population of the target recipients, or the like.

The MSP, MMI proxy, or both may further monitor and record when a message has been successfully delivered, thus allowing analysis of the system performance and acknowledgement of message delivery.

The MMS notifier may be capable of sending multiple notifications in the event of failed delivery. The number of retries that the MMS notifier sends for each message may be stored at the MSP, thus allowing analysis of the system performance.

The MSP may further be capable of associating current demand upon or usage of the infrastructure with respect to current network and delivery costs to provide real-time and flexible rating and charging.

In a further embodiment, an overflow system may be included in the network. When there is an overload of the A2P infrastructure, said overflow system may be configured to feed A2P MMS messages to the P2P or other such infrastructure or to reject further message delivery requests.

If a new type of message destination entity is encountered, the transformation machine dynamically transcodes the MMS message for delivery and then either stores, or makes available for storage -by either the MSP or the MM I proxy-the transcoded message.

Further, details of the new transcoding requirements are preferably added to a system database.

The system described may further offload A2P traffic from the present P2P infrastructure in a seamless manner and without requiring service disruptions. In addition, the efficiencies provided may reduce the cost-per-message of MMS delivery.

The system described above may further be provided with a system management, logging, statistics and alarm interface.

As described above, the MMS content may be saved locally to the proxies and therefore may be staged closer to the edge of the network than when stored at the MM SC. This has the effect of distributing the WAP G/W demands across the proxies. Both this, and also the MMS message pre-formatting (which pre-formatting reduces the number of operations required for an individual message), may increase the efficiency of the system, which may be particularly pertinent for time-sensitive MMS content. In addition, only one MMS message is required for distribution to mOre than one SME; this reduces the load and/or storage requirements on certain parts of the network.

A further embodiment will now be described with reference to figure 2. This may provide a direct delivery system for the sending of A2P messages from an application 210, via a network 212 to an MSP gateway 214. The message is transcoded according to the recipient destination entity and then transmited via an MMI proxy 216, which may have a memory facility 218, to an SME 220.

With reference to Fig. 3, once a message has been delivered to the MSP 322, the MSP 322 transmits the message to the various MM I proxies 324,332. A destination entity 330 that has be'en notified of an awaiting message will then contact the relevant MMI proxy; the MMI proxy 324 then transmits the message directly to the destination entity 330.

The present invention will now be described with reference to figure 4. In this invention, applications 414 that communicate to the MSP 420 using MM7 or Mobile Marketing Tools (MMT) 410 that communicate with the MSP 420 using a web service, send an A2P message to the MSP 420. An MMT 410 may be connected to a sub-database 412 that may itself be connected to the MSP 420.

The MSP 420 may be connected to a transformation engine 418 to which transformation engine 418 the MSP 420sends the A2P message. The transformation engine 418 transcodes the A2P message into one or more formats and then sends these transcoded messages either directly, or via the MSP 420, to a storage facility 422. The MSP 420 then notifies the destination entity 432 to which the message will be sent via either an SMSC 436 or an MDP 436 using SM PP. An SMS notification may then be sent to the destination entity 432. The MSP 420 also pushes the contents of the store 422 to the MM I Proxy 428. The MM I proxy 428 performs MSISDN resolution using RADIUS 426 before transmitting the appropriately transcoded messages to the destination entities 432.

The MMS message delivery system described above may be implemented in conjunction with a Mobile Data Services Architecture system, one embodiment of which is illustrated schematically in Fig. 5 and elements of one embodiment of which are described in more detail below.

In the embodiment illustrated in Fig. 5, the architecture is divided into three core layers as described below.

The infrastructure layer 5 14 represents the core communication 516 and management 518 services common across all applications. Communication services 516 describe how components in the framework send and receive messages. Management services 518 describe the common components for system and application configuration and reporting.

The component layer 5 12 contains a collection of common components that represent the capabilities of the system. This is further broken down into resource adaptors 524 (connections to external systems), business rules 522 (how to process events from external systems), and business storage 520 (how transaction information is persisted).

The packaging layer represents common deployment topologies for the capabilities supported in the lower layers. However, it will be appreciated from the following description that the components in the packaging illustrated in Fig. 5 are only one example of how the underlying functionality may be packaged and component functionalities may be merged, increased or decreased as required for any particular deployment.

Example components of each layer and their responsibilities will now be described in more detail.

The infrastructure layer 514 represents "plumbing" used across all applications. This layer may be designed to maximise the use of existing technology (e.g. VMX) as well as various "commercial off the shelf" (COTS) products (e.g. JDMK, Tomcat, Log4J).

The communication services 516 aspect is responsible for hosting the communication backbone between business services, management services, and external resources.

Components of one embodiment of the communication services 516 aspect are set out in more detail below by way of example.

Agents: A container for fine-grained application business logic. Agents send and receive messages between other agents within the application in order to execute a specific portion of business logic. The VMX may pool agents in order to increase the throughput of a particular business workflow. Agents are fully decoupled from the other business components of the application. However, agents have access to Management Services 1 5 such as provisioning, logging, and statistics.

Resource Adaptors: A container for managing connections to external systems (e.g. SMSCs, content applications, prepay systems). The Resource Adaptor contract specifies the lifecycle of a connection, management information, and how events are published into the application's service agents. Specific Resource Adaptor Types may be defined to support integration with specific system types (e.g. messaging, payment). Each Resource Adaptor Type defines a set of events that it can publish and a synchronous provider interface from which applications can fire events on the adaptor.

Transport: Information that can be managed by a store. This can represent events being passed between agents as well as simple provisioning or configuration data.

Stores: Represents a buffering mechanism for events passed between Agents (effectively a queueing mechanism). The VMX supports store types for FIFO, Array Index, or Hash.

Spaces: A container that represents a collection of Stores on a physical node (e.g. a server).

Wiring: The mechanism for associating agents with stores which effectively acts as a form of event routing. The application logic within each agent is unaware of the wiring, and thus, the event routing.

The management services aspect 518 is comprised of common services used to provide configuration and reporting services to the system (i.e. the engine) and service (i.e. external applications) level components. Components of one embodiment of the management services aspect 5 18 are set out in more detail below by way of example.

Management: This service provides a common framework for managing the lifecycle of business components (e.g. start, stop, restart, status) as well as updating the dynamic state of a component.

Configuration: This service provides a single point of access for adding, modifying, and propagating data related to the system as a whole (e.g. nodes, connections, stores).

Provisioning: This service provides a single point of access for adding, modifying, and propagating data related to 3rd party services (e.g. accounts, users, and delivery and service profiles).

Logging: This service provides a common framework for providing centralised operational, trace, and financial logging.

Alarms: This service provides a central collection point for operational alarms (i.e. traps).

This information is normally made available via SNMP.

Statistics: The service provides a central collection point for event counters that can be used to calculate statistics. This information is normally made available via SNMP.

Licensing: This service enforces the licensing agreements between the MDSA operator and network and/or application operators. This service has the capability to audit and enforce licensing constraints based on nodes, features, connections, and traffic volumes.

The component layer 512 contains the business components. Many of these components may be reused by various applications. For example, CDR generation and subscriber profiling information may be used by either the MSP or MCP.

Resource adaptors 524 represent an integration point between MDSA applications and external systems. Each resource adaptor 524 may be used to translate protocol specific business events into generic platform events (e.g. SMPP "submit_sm" into a "SubmitMessage" event) or a generic platform event ipto a protocol specific event (e.g. "AuthorisePayment" into a SIACC "check_balance" call). Each resource adaptor 524 may be associated with a resource adaptor type which defines the events that may be sent and received from a class of resource.

Resource adaptor types may include: -Messaging: sends and receives message delivery events from 3rd party applications and network operator message service centres. Typical events are Submit, Deliver, Deliver Report, Enquire, Cancel, and Replace. This is a generic abstraction of SMS and MMS message events. Example implementations are SMPP, CIMD, MM7, and EAIF.

-Payment: accepts payment events to network operator prepay or mediation platform. Typical events are Check Status, Check Credit, Reserve, Charge, Release, and Refund. Example implementations are SIACC, RADIUS, DIAMETER, and CAMEL.

-CDR: generated Call Data Records based on a combination of message delivery and payment events. Example implementations are Nokia SMS and ASN.I. 1-, I-,

The business services or business rules 522 contain components or rules for managing the message lifecycle. These may include one or more of the following.

Authentication: This service identifies the applications and service attempting to use the network. This can be simply validating large-account login credentials or identifying an application service based on short code, keywords, and billing identifiers.

Authorisation: This service determines if a given application service is allowed to deliver the message. This can be a combination of throughput controls (e.g. maximum connections or volume), message and PDU type (e.g.' transmitter or receiver), as well as subscriber whitelisting, blacklisting, and SPAM controls.

Manipulation: This service determines if any modifications to the message are required prior to transport (e.g. address aliasing, default values).

Charging: This service determines if any real-time or post-processing charging activity is required (e.g. check balance, reduce funds, or generate CDR).

Routing: This service determines how a message is routed to either the network or applications. Policies are based off a combination of destination (e.g. channels and groups), priority, and percentage based routing strategies.

Delivery: This service is responsible for determining how a message is delivered between the application and the network and back. This can be one of transparent mode or store & forward mode.

The business storage services 520 represent different mechanisms for persisting request data during the message delivery lifecycle. Storage system types may include those set out below and are described in more detail in the following description.

Message Header: This type of store maintains the message control information (e.g. addresses, priority) associated with a specific delivery request.

Message Content: This type of store maintains the message content (ie. tlie paylbad) such as a text message, ringtone, or picture. Different types of message content require different types of storage. For example, the sheer size of an MMS message requires a different storage strategy from smaller SMS messages.

Delivery Information: This type of store maintains the information required to query the status of a message in delivery. This might contain information such as application and network correlation ticket information, and session or connection mapping information.

The packaging layer 510 represents how the applicationand infrastructure components are deployed, for example as products in a suite. Products may include those set out below and described in more detail in the following description.

MSP: The Mobile Service Platform (MSP) 526 is the gateway between the network operator infrastructure and 3rd party applications which wish to invoke services on that infrastructure. One role of the MSP may be to provide a store & forward delivery service which includes but is not limited to routing, filtering, and protocol translation.

MDP: The Mobile Delivery Platform (MDP) 528 is an intelligent message router that provides a bridge between the IP and SS7 transport protocols. The MDP may support various services including First Delivery Attempt (FDA) and SMS firewall capabilities.

The MDP 528 may be provided as a separate platform in its own right, without being integrated with the rest of the MDSA framework.

MCP: The Mobile Charging Platform (MCP) 530 is responsible for providing access to the BSS systems of the network operator's infrastructure. This includes but is not limited to real-time payment systems, postpay systems (e.g.. CDR file stores), and subscriber profile databases. The MCP may support a series of protocol adaptors in order to connect to various backend systems as well as a configurable workflow engine that enables network operators to provision different charging profiles for various service and subscriber types.

MMP: The Mobile Management Platform (MMP) 532 is responsible for providing a common interface for coordinating management, configuration, and provisioning functions across the system. The MMP 532 is comprised of a series of adaptors that integrate the management functionality of the various components (e.g., MSP, MCP) into a single consistent view that provides a view of a single unified environment. The MMP also supports a number of interfaces for supplying or obtaining management information including a standard web console as well as interfaces via RMI, web services, and SNMP.

As will be clear to one skilled in the art, throughout the description, the term message' may be used to refer to any type of message or transaction data sent between components in the system. For example, a message may be a Multimedia Service (MMS) message or may be an Instant Messenger (IM) or email, facsimile or voicemail message. Further, the message may be a message relating to a transaction between users in the system or between a user and a service connected to the system.

Although the mobile telecommunications network described herein is an MM7 protocol based network, it will be clear to one skilled in the art that the systems and methods described herein may be implemented in any type of telecommunications network. For example, any GSM or TDMA, CDMA, GPRS, EV-DO or UMTS network, such as a 3G network, or an IP based networks.

One embodiment of the present system will now be described in more detail with reference to Fig. 6.

A message originating entity 610. such as an application, which may bea mobile marketing or content provider application, generates a message that includes an embedded link 622 in the message. The message may form part of a campaign, for example a marketing campaign or a campaign to raise awareness of a particular service.

The message may be transmitted to a plurality of destination entities 614 via a delivery system 612, such as the MMS Direct Delivery (DD) sysem described herein. On receipt of the message, the user opens the message and the embedded link is presented to the user. The user may then select the link in the message 616, for example if the user is interested in obtaining further information from the link.

In the present system, the request for access to the link 616 passes back through the MMS system 612, since the destination user 614 is connected to this system. The MMS DD system 612 generates an indication that the link has been accessed. This may comprise an indication in an internal database 620 or a notificationmessage that may be transmitted back to the originating application 610 or to a central monitoring system. In this way, every recipient that "clicks through" the message is noted.

In alternative embodiments, the request for access to the link may pass via a portal 618 through a network separate to the mobile telecommunications network, for example via an IP network. In this embodiment, the request may be noted at the portal 618 or at the component where the link information is held. An identifier of the requesting user may also be stored with the note that the request was made.

Such a system may enable the system to determine the level of interest generated by a particular message and hence may provide an indication of the success of a messaging campaign. This information 620 may be transmitted back to the messaging application 610. Further, if an identifier of the requesting user is retained, the information may enable the provider to target further messages to users who are likely to be interested in the message content.

Further features of a system that may be implemented in conjunction with the systems and methods described above are set out below by way of example.

One embodiment may also provide a method of processing a message in a message transmission network, the network comprising at least one message handling component for receiving a message from at least one message originating entity and a plurality of message delivery components for transmitting the message to at least one destination entity in the message transmission network, the method comprising: receiving a message at the message handling component for transmission to at least one destination entity; retrieving a predefined list of message formats for the message; formatting at least a portion of the message in accordance with at least one message format from the predefined list of message formats; storing the portion of the message as a preformatted portion for subsequent delivery.

Advantageously, the method may allow the message, or a portion of the message, to be preformatted or pretranscoded into one or more message formats on receipt. Different message destination entities (for example different types of mobile telephone handsets) require different message formats to enable a message to be accessed on the handset.

Since the preformatted message or message portion is stored for later delivery, the delivery process for the message to handsets that require the preformatted message type may be provided more efficiently.

This contrasts with prior art systems in which messages are transcoded or formatted for delivery only on receipt of a request for delivery from the destination entity. This enables the previous systems to transcode the message only into the format(s) required by the destination entities to which the message is being sent. However, the message delivery process for each recipient may slow, since the message must be formatted before being sent and particular delays may be encountered at peak message sending times. Also, the original message must be reformatted for each destination entity, even if a number of destination entities receiving the same message require identical formatting.

It has been found that, particularly for bulk messages that are sent to a plurality of destination entities, it is more efficient to preformat at least a portion of the message on receipt and store the preformatted message for later delivery. This may reçluce the amount of message formatting that needs to be undertaken, ven if the message portion is transcoded into one or more formats that are not eventually used in the message delivery process.

Formatting some parts of the message may provide greater efficiency in the message delivery process than others, hence only selected portions of the message may be preform atted Alternatively, however, the message may be completely preformatted so that the message is ready to send as soon as a message delivery request is received.

Preferably, formatting the message comprises pretranscoding at least a portion of the message.

In a preferred embodiment, the method further comprises formatting the at least a portion of the message in accordance with a plurality of message formats from the predefined list of message formats. Preformatting the message in a plurality of different formats may prepare the message for sending to a plurality of different types of message destination entities.

In one embodiment, the at least one message format or the plurality of message formats is selected from the predefined list of message formats based on at least one criterion.

Preferably, the at least one criterion comprises at least one of: at least one identifier associated with a destination entity for the message at least one identifier of the type of the destination entity for the message an attribute associated with the message an identifier associated with the originating message entity at least one message format used for transmission of a previous message Hence the message format or formats selected for pretranscoding may depend on characteristics of the originating message entity or the destination message entities. For example, the network may have access to data indicating which destination message entities require which message formats and the list of destination identifiers associated with the message may then govern the formats into which the message is pretranscoded.

As a further example, the network may determine the geographical location of the originating or destination message entities and may select the message formats for preformatting that are most prevalent in those geographical areas.

In a still further example, the formats into which the message is preformatted may depend on statistical data collected in the network. For example, the network may determine which message formats were required for the delivery of previous messages (in the whole network or, for example fbr previous messages sent by a particular message originator) and may select the message formats to used based on these statistics.

In one embodiment, a combination of criteria may be used to determine the message format.

In an alternative embodiment, the method may comprise formatting the at least a portion of the message in accordance with each message format in the predefined list of message formats. Hence the message may be pretranscoded into every format in the list, which may comprise every possible message format known to the network. Alternatively, the list of message formats may include selected formats, for example the most common message formats required by message delivery entities.

In a further, preferred embodiment, the method further comprises receiving a request for delivery of the message from a destination entity; determining a format for the message based on at least one attribute of the destination entity reviewing the predefined list of message formats to determine whether the message format determined is included in the predefined list of message formats.

Hence the system can determine whether it was previously aware of the message format that the destination entity is requesting.

Preferably, if the message format determined is included in the predefined list of message formats, the method further comprises: determining whether the message has been preformatted according to the message format determined; and, if the message has been preformatted: delivering the message including the preformatted portion of the message to the destination entity.

Preferably, if the message format determined is not included in the predefined list of message formats, the method further comprises: formatting the message according to the message format determined and forwarding the message to the destination entity; storing the message format determined in the list of message formats.

Hence, if a request is received for a message in a previously unknown message format, the message may be formatted on demand, or on the fly, and forwarded to the destination entity. Details of the previously unknown message format may then be stored in the list of message formats for use in association with further messages.

In a preferred embodiment, storing the message comprises staging the message at a plurality of distributed message delivery components in the message transmission network. As described in more detail below, this may enable the system to stage the preformatted messages closer to the network edge. This may distribute the message delivery process over a larger number of components in the network and speed up the message delivery process, since the destination entity can retrieve the message from a component closer in the message delivery network.

Preferably, the method further comprises delivering the message, including the preformatted portion of the message or a selected preformatted portion of the message to a destination entity via the message transmission network.

Preferably, the method further comprises forwarding the preformatted portion of the message to at least one message delivery component in the message transmission network. This may allow the message to be staged closer to the network edge, and so closer to its destination. The message may be forwarded to one or more selected message delivery components depending on factors such as the location of the or each destination entity for the message.

In a preferred embodiment, the method further comprises forwarding the preformatted portion of the message to a plurality of distributed message delivery components in the message transmission network. Hence the message may be staged at a plurality of components in the message transmission network closer to the network edge.

Preferably, formatting at least a portion of the message comprises formatting the audio or video content of the message.

Further preferably, formatting at least a portion of the message comprises converting the portion of the message to a JPEG format. Hence an image may be preformatted as a JPEG image.

Alternatively, formatting at least a portion of the message comprises converting the portion of the message to a GIF format. Hence an image may be preformatted as a GIF image.

In a preferred embodiment, the message transmission network comprises a mobile telecommunications network. The network may be implemented using any suitable protocol and portions of the network may be implemented using different protocols, for example MM7, SS7, IP, 3G, GPRS.

In a preferred embodiment, the message comprises a Multimedia Messaging Service (MMS) message.

Preferably, the portion of the message comprises MMS message content. For example the content may comprise an image, sound clip or moving image.

Alternatively, the message comprises an email, facsimile, voicemail or instant messenger message. The portion of the message may also comprise an image, sound clip or moving image in this embodiment.

On embodiment of the system may also provide a method of transmitting a message to at least one destination entity via a message transmission network, the network comprising at least one message handling component and a plurality of message delivery components, the network having a network edge for interfacing with message originating and destination entities using a user device protocol, wherein the message delivery components are arranged between the message handling component and the network edge, the method comprising: receiving a message at a message handling component for transmission to at least one destination entity; forwarding at least a portion of the message to a plurality of message delivery components; staging the at least a portion of the message at the plurality of message delivery components; receiving a request from the destination entity at at least one message delivery component to retrieve the at least a portion of the message.

As described herein, in previous systems, each message would be stored at a central message handling component and a request from the destination entity for the message would be transmitted back through the network to the message handling component. A communication path may then be set up between the message handling component and the destination entity to enable delivery of the message.

Advantageously, according to the present aspect, the message may be forwarded and staged at one or more message delivery components on receipt, before delivery of the message is requested from the destination entity. This may allow the message to be retrieved by the destination entity from a component closer to it in the network than the message handling component. This may increase the speed and efficiency of the message delivery process.

Further, staging the message for subsequent delivery at a plurality of message delivery components may enable the message delivery process to be distributed across a number of components. This may reduce the load on each message delivery component and reduce the load on the message handling component. Further, the distributed system may provide redundancy in the network, since the destination entity may be able to retrieve the message from one of a plurality of message delivery components. If one component fails, the request from the message delivery component may be directed to an alternative message delivery component in the network.

In a preferred embodiment, the at least a portion of the message is forwarded to the destination entity using the user device protocol. Enabling the message delivery components to communicate with the destination entity using the user device protocol may mean that no gateway component is required between the two components. This may reduce the number of components required in the network and may remove a potential bottleneck in the message delivery process.

Preferably, the message delivery components comprise a plurality of proxies connected to the message handling component.

Preferably, the message delivery components are connected to each other and to the message handling component over a network separate to the mobile telecommunications network, for example over an IP based network or an lnfiniband network.

In a preferred embodiment, the message delivery component communicates directly with the destination entity.

Preferably, the message delivery component communicates with the destination entity without passing through,a gateway component.

Preferably, the at least a portion of the message is preformatted in one of a plurality of message formats from a predefined list of message formats. Further preferred features of the first aspect set out above may also be provided in conjunction with the present aspect.

In one embodiment, receiving a request from the destination entity comprises receiving the request at a load balancing component associated with the message delivery components, wherein the load balancing component selects a message delivery component to which to direct the request. 1-lence requests from destination entities may be directed to selected message delivery components based on factors such as the real-time or expected load on those components, the geographical or network location of the components or performance measures associated with the components.

In a highly preferred embodiment, the plurality of message delivery components are positioned closer to the network edge than the message handling component.

In one embodiment, the user device protocol comprises a wireless application protocol (WAP). However, the protocol may comprise any protocol in which the user device communicates with the network. In one embodiment, the message delivery component may be configured to communicate in different protocols with different message destination entities. Hence a plurality of different types of message gateways may be replaced by the message delivery components.

One embodiment may also provide a message delivery component in a message transmission network, the network comprising at least one message handling component and a plurality of message delivery components, the network having a network edge for interfacing with message originating and destination entities using a user device protocol, the method comprising: means for receiving at least a portion of a message in a first message format from a message handling component; means for staging the at least a portion of a message; means for receiving a request for the at least a portion of a message from a message destination entity; means for communicating with the message destination entity in the user device protocol to transmit the at least a portion of the message using a first communication pathway to the message destination entity.

Hence at least a portion of the message may be staged, or stored at the message delivery component even before the request from the message destination entity is received in the network. As described in more detail below, in prior art systems, messages are stored for transmission at the message handling component (or an equivalent component in the prior art network, such as an MMSC). Destination entities may then retrieve messages by requesting and setting up a connection back through the network to the message handling component.

Advantageously, in embodiments of the present aspect, messages may be stored at message delivery components closer in the network to the destination entity, hence the connection set up by the destination entity to retrieve the message may pass through a shorter network distance.

In one embodiment, the network further comprises at least one gateway component using a gateway device protocol and the message delivery component further comprises means for communicating with the gateway component in the gateway device protocol to transmit the at least a portion of the message using a second communication pathway via the gateway component to the message destination entity., Hence the message delivery component may be installed with respect to the destination entities either behind or in front of the gateway component, for example a WAP gateway.

The destination entities may therefore either connect directly to the message delivery component or via the WAP gateway.

In one embodiment, the component further comprises means for selecting a communication pathway using which to transmit the at least a portion of the message. For example, the message may be transmitted to its destination either directly or via a gateway component. The selection may be based, for example, on the protocol used by the destination entity.

In a preferred embodiment, the at least a portion of the message is received in a plurality of message formats and the message delivery component further comprises means for selecting a message having a particular message format to transmit to the message destination entity. Advantages discussed above in relation to the preformatting aspect may be provided and further features of the preformatting aspect may also be provided in conj unction with the presenz aspect.

In one embodiment, the message delivery component further comprises means for analysing the request received from the message destination entity to determine the message format in which to transmit the portion of the message.

In one embodiment the user device protocol comprises a WAP protocol.

One embodiment of the system may also provide a message transmission network comprising at least one message handling component and a plurality of message delivery components, the network having a network edge for interfacing with message originating and destination entities using a user device protocol; wherein the at least one message handling component comprises: means for receiving at least one message from a message originating entity for transmission to at least one message destination entity; means for forwarding at least a portion of the message to at least one message delivery component wherein the plurality of message delivery components each comprise means for receiving the least a portion of a message from the message handling component; means for staging the at least a portion of a message; means for receiving a request for the at least a portion of a message from a message destination entity; and means for communicating with the message destination entity in the user device protocol to transmit the at least a portion of the message using a first communication pathway to the message destination entity.

In addition to the advantages described above, staging messages at a plurality of components close to the network edge in one embodiment may reduce the load on the message handling component. For example, if an application sends a bulk MMS message, such as a marketing message, to a plurality of recipients, different recipients may obtain the message from different message delivery components in the network, setting up connections to separate message delivery components to obtain the data. This may be more efficient than every message recipient attempting to connect to one central component to obtain the message.

in a preferred embodiment, the network further comprises at least one gateway component using a gateway device protocol and wherein at least one message delivery component further comprises means for receiving a request for the at least a portion of a message from a message destination entity via the gateway component; and means for communicating with the gateway component using the gateway device protocol to transmit the at least a portion of the message using a second communication pathway via the gateway component to the message destiiiation entity.

Preferably, the at least one message delivery component further comprises means for selecting a communication pathway from the first and second communication pathway via which to transmit the at least a portion of the message.

Preferably, the at least a portion of the message is received in a plurality of message formats and the or each message delivery component further comprises means for selecting a message having a particular message foimat to transmit to the message destination entity.

Preferably, the or each message delivery component further comprises means for analysing the request received from the message destination entity to determine the message format in which to transmit the portion of the message.

In one embodiment, the user device protocol comprises a WAP protocol.

It will be clear to one skilled in the art that the message transmission systems, methods and strategies described above may be implemented separately or in combination.

Further, systems may be implemented in conjunction with other system components described herein. Modifications may be provided to the systems and methods described herein, for example to apply the methods described to other types of messages or networks.

Claims

Claims: I. A method of handling messages in a network, the method

comprising: transmitting a message to at least one destination entity, wherein the message includes first content and a selectable link to further content associated with the message and wherein selection of the link triggers supply of the further content; monitoring selection of the link; in response to selection of the link, updating feedback data associated with the message; communicating feedback data to an entity associated with the originator of the message.

2. A method according to Claim I wherein monitoring selection of the link comprises recording each request for access to the link.

3. A method according to Claim 1 or 2 wherein the selection of the link is monitored at a component storing the further content associated with the message.

4. A method according to Claim I or 2 wherein the selection of the link is monitored at a message transmission component in the network.

5. A method according to any preceding claim wherein the feedback data comprises a measure of the selection of the link to the further content resulting from the transmission of the message.

6. A method according to any preceding claim wherein the feedback data comprises an indication of the time between the transmission of the message to the at least one destination entity and the selection of the link.

7. A method according to any preceding claim wherein the further content is external to the message.

8. A method according to any preceding claim wherein the further content comprises a further portion of the message.

9. A method according to any preceding claim wherin the selectable link comprises a URL.

10. A method according to any preceding claim wherein the further content comprises internet-based content.

I I. A method according to any preceding claim wherein the feedback data includes an identifier of the selecting destination entity.

12. A method according to any preceding claim wherein the entity associated with the originator of the message comprises a message-originating application.

13. A method according to any of Claims I to II wherein the entity associated with the originator of the message comprises a central feedback system.

14. Apparatus for handling messages in a network, the apparatus comprising: means for transmitting a message to at least one destination entity, wherein the message includes first content and a selectable link to further content associated with the message and wherein selection of the link triggers supply of the further content; means for monitoring selection of the link; means for updating feedback data associated with the message in response to selection of the link; means for communicating feedback data to an entity associated with the originator of the message.

15. Apparatus according to Claim 14 wherein the means for monitoring selection of the link comprises means for recording each request for access to the link.

16. Apparatus according to Claim 14 or 15 wherein the means for monitoring S selection of the link comprises a component storing the further content associated with the message.

17. Apparatus according to Claim 14 or 15 wherein the means for monitoring selection of the link comprises a message transmission component in the network.

18. Apparatus according to any of Claims 14 to 17 wherein the further content is external to the message.

19. Apparatus according to any of Claims 14 to 17 wherein the further content comprises a further portion of the message.

20. Apparatus according to any of Claims 14 to 19 wherein the selectable link comprises a URL.

21. Apparatus according to any of Claims 14 to 20 wherein the further content comprises Internet-based content.

22. Apparatus according to any of Claims 14 to 21 wherein the entity associated with the originator of the message comprises a message-originating application.

23. Apparatus according to any of Claims 14 to 21 wherein the entity associated with the originator of the message comprises a central feedback system.

24. A method substantially as any one described herein with particular reference to Fig. 6.

25. Apparatus substantially as any one described herein with particular reference to Fig. 6.

26. A computer program or computer program product comprising instructions for carrying out a method according to any ofClaims1 to 13.