WO2013090949A1

WO2013090949A1 - System and method of sending a multimedia message

Info

Publication number: WO2013090949A1
Application number: PCT/ZA2012/000094
Authority: WO
Inventors: Johan VAN DEN BERG; Johan Albertus LIVERSAGE; Michael Levinsohn
Original assignee: Lenco Technology Group Ltd
Current assignee: Lenco Technology Group Ltd
Priority date: 2011-12-15
Filing date: 2012-12-07
Publication date: 2013-06-20
Anticipated expiration: 2014-06-15

Abstract

This invention relates to a method for sending a multimedia message ("MM") to a device, comprising the steps of: generating a MM file, containing a data packet relating to the user of the device; relaying the MM file to a messaging centre; sending a MM notification message from the messaging centre to the device; sending a request from the device to a MMSC, requesting retrieval of the MM; authenticating detail of the device at the MMSC, to assess the appropriate format of the content for the requested MM; generating the content of the MM at the MMSC; and retrieving the content of the MM on the device. The invention also relates to a complimentary system for sending such a MM to a device.

Description

System And Method Of Sending A Multimedia Message

Field Of The Invention

THIS INVENTION relates, broadly, to a system and method of sending a multimedia message ("MM").

Background To The Invention

For purposes of this patent specification, the term "device" is understood to embrace all manner of mobile, handheld communication devices that have the capacity to communicate over a telecommunications network. These include, but are not limited to: cellular phones and tablet computers. The most common form of MM is the multimedia messaging service message, or "mms". Typically, these encompass all manner and combination of pictures, text messages and/or sound clips. In this specification, "MM" is used in a broader context, and also embraces documents and files of the following video, image and audio formats, amongst others: .jpeg, .jpg, .gif, .amv, .aac, .mp4, .sml.

Increasingly, businesses prefer to send financial information as part of a MM, rather than via the more conventional methods of email and postage.

The sending of MMs to devices is well-known. However, the current state of the art suffers from a number of shortcomings. For example: it cannot be assumed that every mobile handset can support any given format of a MM - for example: the Apple® iPhone® handset v 3.0 was unable to support the sending or receiving of MMS, of any format, at all. Similarly, many makes of device still cannot accommodate (each of the) files of .sml, .xhtml and/or .mp4 formats. This is regarded as disadvantageous since, even if a MM is sent to a mobile device, a sender cannot be guaranteed that the recipient's device can support the MM or, separately, that it permits the recipient to access its contents.

Furthermore, many devices permit the operator to disable the delivery status function - essentially, if this function is disabled, it would mean that no confirmation of receipt of the MM would be sent from the recipient's handset, even if the sender had requested this status check. For many business operators, it is imperative to be able to confirm that a customer has, in fact, received a financial document - accordingly, it will be appreciated that, when the user of a device disables this function, the delivery status reporting process becomes inconsistent and unreliable, at best, which necessarily frustrates this imperative.

In addition, it is understood that conventional technology, typically, has the capacity to deliver, on average, between 5 - 50 MMs per second. Accordingly, campaigns involving the sending of bulk MMs of more than 100,000 messages are either refused (by the networks) or, if permitted, require at least one day to complete - and this only at the theoretical maximum rate of distribution. This is extremely undesirable, especially in those circumstances in which time is of the essence, and exemplifies the inadequacies of the multimedia service centres that characterise the current state of technology. Further, still, there is a likelihood that such campaigns will cause bottlenecks within a carrier's organisation and/or latency in networks - again, an undesirable result.

In order to appreciate the invention fully, it is instructive to stress that the conventional state of the art technology in sending MMs involves what is known as the Application To Phone ("A2P") mms process. Central to this process is reliance on a multimedia service centre (MMSC), which generates and dispatches the MMs.

In this specification, the following acronyms are used:

• "SMS" designates a Short Message Service message,

· "SMSC" designates a Short Message Service Centre;

• "MSDISN" designates a Mobile Subscriber International Subscriber Directory Number; and

• "URL" designates a Uniform Resource Locator (essentially: an internet web site address).

Each of these terms is well understood in the art.

It is important to note that A2P mms process requires a significant amount of overhead, since all the mms that are submitted as part of a campaign must be pre-generated and then submitted to the MMSC. This submission is achieved, most commonly, using MM7 and HTTP over TCP/IP protocols. An example of how expensive this process can be is to consider a campaign of 1 million messages at an average size of 100kb/message. In this scenario, which is provided for illustrative purposes only: i. approximately 5 - 6.5 GB of data is transferred to the MMSC before distribution can take place from the MMSC. This takes a significant amount of time, depending on the speed of communication. Only upon receipt of an MMS and its content will the MMSC send a notification SMS for that MMS via the SMSC;

ii. each of the mms messages is generated and packaged individually, duplicating shared resources, such as background pictures and common textual information, many times over;

iii. the rate of distribution of messages, typically, cannot exceed 200 MM messages per second (maximum rate of output); and

iv. mms messages will be created and submitted for all intended recipients, including those who will not be able to download the MMS content on their device (for any number of reasons).

Part iv (above) is significant: it will be appreciated that the sending of batch MM messages in accordance with the current state of the art is often an unreliable hit-and-miss affair, in that there is no guarantee either that the MM sent from an MMSC will be received on the intended recipient's device, or that the MM will, in fact, be rendered on device, even if it is, in fact, received. This is problematic from another perspective, too: irrespective of whether the MM is received successfully, the data is still sent - this results, necessarily, in an appreciable amount of unnecessary data transfer.

A further shortcoming of the current state of technology relates to the process of "transcoding", which relates to the storage and processing of images. Loosely speaking, this is the process that converts portrait content for display on a device that can accommodate only landscape content.

More technically: transcoding is the direct digital-to-digital data conversion of one encoding to another, such as for movie data files or audio files. In this context, transcoding is required since the target device does not support the format of the desired file. Typically, the transcoding process is inefficient, and warps images. A further drawback of transcoding formats is decreased quality, and transcoding has been known to cause progressive, cumulative loss of quality with each successive generation, known as digital generation loss.

Accordingly, for all of these reasons, the process forming part of the current state of the art may be seen to be (relatively) inefficient, unreliable and costly.

Object Of The Invention

It is an object of the present invention to provide a system and method that will overcome, at least partially, the disadvantages described.

Summary Of The Invention

According to a first aspect of the invention, there is provided a method for sending a MM to a device, the method comprising the steps of:

• generating a MM file, containing a data packet relating to the user of the device;

• relaying the MM file to a messaging centre;

• sending a MM notification message from the messaging centre to the device; • sending a request from the device to a MMSC, requesting retrieval of the MM;

• authenticating detail of the device at the MMSC, to assess the appropriate format of the content for the requested MM;

• generating the content of the MM at the MMSC; and

• retrieving the content of the MM on the device.

Preferably, the MM notification message takes the form of a SMS, and the messaging centre is a SMSC.

Most preferably, the MM notification message includes:

a subject; and

a URL indicating from where the associated MM content may be retrieved.

The method may further comprise the step of receiving a verification response at the server, to verify that the MM notification message has been received at the device.

The step of authenticating detail may involve comparing a requested IP address against an MSISDN, both the requested IP address and the MSISDN being included as part of the retrieval request.

The data packet may include detail of a user agent.

In addition, or in an alternative embodiment of the invention, the step of authenticating detail may involve using the user agent to identify uniquely the device. In a further alternative embodiment of the invention, the step of authenticating detail may comprise searching a database comprising device characteristics to identify uniquely the device.

Preferably, the content of the MM is retrieved via HTTP over TCP/IP.

The method may further comprise the step of conducting an authentication check at the MMSC, to authenticate whether the user is authorised to retrieve the MM.

The step of submitting the MM notification may further comprise the steps of submitting the data packet:

• from the messaging server to a messaging gateway; and then

• from the messaging gateway to the messaging centre.

The step of submitting a MM notification message may further comprise the steps of:

• extracting data from the MM file; and

• loading a MSISDN list, which list comprises a set of properties selected from the group consisting of: a set of mobile network operators, a set of device capabilities, an indication of WAP capabilities, the user's personal information, and a combination of these properties. The MM notification message may comprise a uniform resource identifier ("URI"), in order to identify uniquely the device, alternatively the SIM card associated with the device, with the MM resource on the messaging gateway.

In a preferred embodiment of the invention, the method includes the further step of accessing the URI by sending a wireless session protocol ("WSP") request to the messaging gateway. In a preferred embodiment of the invention, all messages between the messaging gateway and any message centre are sent over the MM1 over HTTP over TCP/IP (TCP over IP) protocol. Alternatively, for security purposes, HTTPS may be used instead of HTTP.

The method may further include the step of reporting successful retrieval of the MM on the device.

According to a second aspect of the invention, there is provided a system for sending a MM to a device, the system comprising:

• a messaging server for generating a MM file;

• a messaging centre, for transmitting a MM notification message;

• a MM service centre at which the content of the MM is generated; and.

• a messaging gateway over which the content of the MM is transmitted to the device.

Preferably, the MM notification message takes the form of a SMS, and the messaging centre is a SMSC. The system may further comprise a database comprising data relating to the set consisting of: device characteristics, in order to identify uniquely the device, the user's identity, in order to authenticate whether the user is authorised to retrieve the MM, and a combination of these.

Brief Description Of The Drawings

In order to describe the invention, embodiments thereof are described hereunder, purely as examples, without limiting the scope of the invention, wherein:

Figure 1 is a schematic flowchart representation of the A2P process of the prior art; and

Figure 2 is a schematic flowchart representation of the process claimed in the present invention.

Detailed Description Of The Drawings

Referring to the figures, which depict a preferred embodiment of the invention, a method of sending a MM in accordance with the invention is provided, and is referred to generally by numeral 10. A system for sending a MM to a device, in accordance with a second aspect of the invention, is not designated by any given numeral, since this is impractical - however, the system is defined in greater detail below.

The method 10 includes a number of steps. In the first step 20, a MM file, containing a data packet (not depicted) relating to the user (also not depicted) of the device 30, is created at a messaging server 40. Typically, the messaging server 40 is housed at the premises of, and/or maintained by an operator (not depicted) wishing to send bulk MMs to its clients.

From the MM Data packet, content and data relating to the MM notification message 70 that will be sent is stored. Thus, MM notification messages 70 are generated. As is described in more detail below, in a preferred embodiment of the invention, the MM notification messages 70 are sent to the devices 30 using the SMPP protocol via an SMSC 100. Specifically, in the step 60 in the method 10, a MM notification message 70 is sent using SMPP over TCP/IP to a SMS Gateway 80 and, in this fashion, is sent from the messaging centre 50 to the device 30. The notification message 70 notifies the user that a MM is available for retrieval. In more specific detail: data is extracted, transformed and loaded ("ETL") 120 from the MM file and a MSISDN list is loaded. Once loaded, each MSISDN is attributed with a set of properties, and is then submitted for MM notification. The MM Notification message 70 is a type of WAP Push message that, in a preferred embodiment of the invention, is sent using SMS. Applicable MM notification sms 60 are then compiled, and consist of a subject and a URL (from where the associated MM content may be retrieved), in the form of a WAP Push Message. While a subject is not compulsory in order to achieve the advantages of the invention, preferably, it will be present. Similarly SIM- capabilities are nor strictly required in devices in order to achieve the advantages of the invention - this aspect pertains purely to the workings of the network to which the device 30 is connected, and on many networks a SIM will not be present (notably CDMA as opposed to GSM networks). The SMSC 100 now sends the MMS notification sms 60 to the device 30, tied to the unique MSISDN associated with that device 30.

In a preferred embodiment of the invention, in a further, non- compulsory, step 170, a verification response is sent from the device 30 and received at the messaging server 40, to verify that the MM notification message 60 has been received at the device. The verification response is part of the MMS specifications. While this step 170 is not strictly compulsory for purposes of achieving the advantages of the invention, it is useful, for example, in helping to establish definitely that a particular user has, in fact, received a particular notification 60. It is particularly useful for verifying such detail in cases in which a user disables the delivery function status on a device 30.

Depending on how both the network and the device 30 are configured to operate, the device 30 will either download the content of the MM automatically, or it will offer a manual download of the content, in the fashion that is described below. In the case of manual download: the user will be prompted to elect to download the content of the MM. This is done via the sending of a MM Retrieval request 90, to the MMSC (invention) via the Access Gateway. More specifically, the device 30 retrieves the MM once the user opens the MM notification sms 70. This is the case for manual retrieval. Automatic retrieval works in the same fashion, except that the user isn't required to trigger the retrieval by opening the MM notification sms 70 first. This request 90 is made by the device 30 connecting to the internet to the MMSC via the access gateway 130. The device 30 uses an APN (Access Point Name) configurable network identifier to determine which access gateway it should connect to. In the case of MM retrieval, as is illustrated in the accompanying Figures, the APN configured on the device 30 will point to a MMSC URI/IP address. As was alluded to above, the MM notification sms 70 contains an identifier in the URI to identify the MM message to be retrieved. This URI is accessed by the device 30 by sending a WSP/HTTP request 90 to the MMSC 100 via the access gateway 30.

The notification message 70 and retrieval request 90 are part of the MM1 protocol. The notification message 70 is a Wap Push Message, that typically is sent over SMS. The retrieval request 90, while also being part of MM , is typically made using WSP over HTTP over TCP/IP via the access gateway 130. The access gateway 130 routes the request to the MMSC. The identifier included is not necessarily unique (although, typically and in preferred embodiments of the invention, it will be - for example: when combined with the MSISDN). The identifier is also not necessarily hashed.

In one of the preferred embodiments of the invention, included with the retrieval request 90 is a User-Agent (also known as a User-Agent String). The User- Agent Profile is a separate document that details the capabilities of a device identified by the User-Agent, and it is not included in the retrieval request 90. For the sake of absolute clarity: the device 30 itself is not uniquely identified by the User- Agent String, but rather the type and/or make and/or model of the device 30. Once the MM retrieval request 90 is received at the MMSC 1 10, the next step in the method 10 concerns the authentication 140 of detail of the device 30, in order to assess the appropriate format of the content for the requested MM. Three preferred methods of such authentication are envisaged in the present invention, namely:

i. comparing the requesting MSISDN with the MSISDN associated with the MM message identified in the URL, the MSISDN being included as part of the MM retrieval request 70; and/or

ii. using the user agent string to identify uniquely the type or model of the device 30; and/or

iii. searching a database comprising device characteristics to determine device capabilities for a given user agent. Such a database, preferably, is a device description repository ("DDR"), which is well-defined in the art, and which is supported by a standard interface and an initial core vocabulary of device properties. Such repositories enable vendors to adapt content to best suit particular requesting devices. Information in such repositories includes information such as the screen dimensions, input mechanisms, supported colors, known limitations, special capabilities, and the like.

It will be appreciated by those skilled in the art how any one or combination of these authentication techniques may be applied to authenticate both the user and/or the device 30, for both security / user identification and data format purposes. Once authentication 140 has been completed successfully, a MM content generation component (not depicted) builds the content of MM at the MMSC 1 10, based on the credentials passed to it. Thus, the MMSC 1 10 transforms the data into a MM, which is sent to and retrieved 160 on the device 30 over the same TCP/IP connection that is established in earlier step 90.

In a preferred embodiment of the invention, in a further, non- compulsory, step 170, a verification response is sent from the device 30 and received at the messaging server 40, to verify that the MM notification message 60 has been received at the device. The verification response is part of the MMS specifications. While this step 170 is not strictly compulsory for purposes of achieving the advantages of the invention, it is useful, for example, in helping to establish definitely that a particular user has, in fact, received a particular MM. It is particularly useful for verifying such detail in cases in which a user disables the delivery function status on a device 30.

From the description of the method 10 presented above, it also emerges how a system for sending a MM to a device 30 in accordance with the invention is provided. While it is not designated by any particular numeral, the system comprises: the messaging server 40 for generating the MM file described, the messaging centre 50 for transmitting MM notification messages 60, the MMSC 10 at which the content of the MM is generated, and the messaging gateway 130 over which the content of the MM is transmitted to the device 30. Preferably, the system further comprises a DDR database, as described above, in order to achieve aspects of authentication described.

It will be appreciated that a primary difference, and advantage, of the present invention over the prior art (illustrated in Figure 1 ) relates to the stage at which the MM content is generated. Specifically, in the case of the prior art, MM content is adapted and repeated in the introductory steps of sending the MM to any notional device 30 - certainly, before it is even apparent whether the format of the content will, in fact, be rendered acceptably on any notional device 30. This is wasteful, resource-intensive, and largely inefficient. Conversely, in accordance with the present invention, data is generated and rendered strictly and only after it has been established that it is suitable / appropriate for rendering on the given device 30.

It will be appreciated by the person skilled in the art that numerous embodiments of the invention could be performed without departing from the scope of the invention as defined in the consistory statements above. For example, it will be appreciated that any of the messages between the messaging gateway and any message centre (described above) may be sent over the set of any of the following protocols: HTTP over TCP/IP, and HTTPS over TCP/IP.

Claims

1. A method for sending a MM to a device, the method comprising the steps of: generating a MM file, containing a data packet relating to the user of the device; relaying the MM file to a messaging centre;

sending a MM notification message from the messaging centre to the device;

sending a request from the device to a MMSC, requesting retrieval of the MM;

authenticating detail of the device at the MMSC, to assess the appropriate format of the content for the requested MM;

generating the content of the MM at the MMSC; and

retrieving the content of the MM on the device.

2. The method according to claim 1 wherein the MM notification message takes the form of a SMS, and the messaging centre is a SMSC.

3. The method according to claim 1 wherein the MM notification message includes a subject; and a URL indicating from where the associated MM content may be retrieved.

4. The method according to claim 1 which further comprises the step of receiving a verification response at the server, to verify that the MM notification message has been received at the device.

5. The method according to claim 1 wherein the step of authenticating detail involves comparing a requested IP address against an MSISDN, where both the requested IP address and the MSISDN are included as part of the retrieval request.

6. The method according to claim 1 wherein the data packet includes detail of a user agent.

7. The method according to claim 1 wherein the step of authenticating detail involves using the user agent to identify uniquely the device.

8. The method according to claim 1 wherein the step of authenticating detail comprises searching a database comprising device characteristics to identify uniquely the device.

9. The method according to claim 1 wherein the content of the MM is retrieved via HTTP over TCP/IP.

10. The method according to claim 1 which further comprise the step of conducting an authentication check at the MMSC, to authenticate whether the user is authorised to retrieve the MM.

1 1. The method according to claim 1 wherein the step of submitting the MM notification further comprises the steps of submitting the data packet:

from the messaging server to a messaging gateway; and then

from the messaging gateway to the messaging centre.

12. The method according to claim 1 wherein the step of submitting a MM notification message further comprises the steps of: extracting data from the MM file; and

loading a MSlSDN list, which list comprises a set of properties selected from the group consisting of: a set of mobile network operators, a set of device capabilities, an indication of WAP capabilities, the user's personal information, and a combination of these properties.

13. The method according to claim 1 wherein the MM notification message comprises a uniform resource identifier ("URI"), in order to identify uniquely the device, alternatively the SIM card associated with the device, with the MM resource on the messaging gateway.

14. The method according to claim 1 which further includes step of accessing the URI by sending a wireless session protocol ("WSP") request to the messaging gateway.

15. The method according to any preceding claim wherein all messages between the messaging gateway and any message centre are sent over the MM1 over HTTP over TCP/IP (TCP over IP) protocol.

16. The method according to any preceding claim wherein all messages between the messaging gateway and any message centre are sent over the MM1 over

HTTPS over TCP/IP (TCP over IP) protocol.

17. The method according to any preceding claim which further includes the step of reporting successful retrieval of the MM on the device.

18. A system for sending a MM to a device, the system comprising:

a messaging server for generating a MM file;

a messaging centre, for transmitting a MM notification message;

a MM service centre at which the content of the MM is generated; and.

a messaging gateway over which the content of the MM is transmitted to the device.

19. The system according to claim 18 wherein the MM notification message takes the form of a SMS, and the messaging centre is a SMSC.

20. The system according to claim 18 which further comprises a database, comprising data relating to the set consisting of: device characteristics, in order to identify uniquely the device, the user's identity, in order to authenticate whether the user is authorised to retrieve the MM, and a combination of these.