WO2013090949A1 - Système et procédé d'envoi d'un message multimédia - Google Patents

Système et procédé d'envoi d'un message multimédia Download PDF

Info

Publication number
WO2013090949A1
WO2013090949A1 PCT/ZA2012/000094 ZA2012000094W WO2013090949A1 WO 2013090949 A1 WO2013090949 A1 WO 2013090949A1 ZA 2012000094 W ZA2012000094 W ZA 2012000094W WO 2013090949 A1 WO2013090949 A1 WO 2013090949A1
Authority
WO
WIPO (PCT)
Prior art keywords
messaging
content
sending
centre
notification message
Prior art date
Application number
PCT/ZA2012/000094
Other languages
English (en)
Inventor
Johan VAN DEN BERG
Johan Albertus LIVERSAGE
Michael Levinsohn
Original Assignee
Lenco Technology Group Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Lenco Technology Group Limited filed Critical Lenco Technology Group Limited
Publication of WO2013090949A1 publication Critical patent/WO2013090949A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements

Definitions

  • THIS INVENTION relates, broadly, to a system and method of sending a multimedia message ("MM").
  • MM multimedia messaging service message
  • mms multimedia messaging service message
  • 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.
  • MMs The sending of MMs to devices is well-known.
  • 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.
  • 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.
  • MMSC multimedia service centre
  • SMS Short Message Service
  • SMSC Short Message Service Centre
  • MSDISN Mobile Subscriber International Subscriber Directory Number
  • URL designates a Uniform Resource Locator (essentially: an internet web site address).
  • 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;
  • each of the mms messages is generated and packaged individually, duplicating shared resources, such as background pictures and common textual information, many times over;
  • 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.
  • transcoding is the direct digital-to-digital data conversion of one encoding to another, such as for movie data files or audio files.
  • transcoding is required since the target device does not support the format of the desired file.
  • 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.
  • a method for sending a MM to a device comprising the steps of:
  • the MM notification message takes the form of a SMS, and the messaging centre is a SMSC.
  • the MM notification message includes:
  • 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.
  • the step of authenticating detail may involve using the user agent to identify uniquely the device.
  • the step of authenticating detail may comprise searching a database comprising device characteristics to identify uniquely the device.
  • 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:
  • the step of submitting a MM notification message may further comprise the steps of:
  • 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.
  • URI uniform resource identifier
  • the method includes the further step of accessing the URI by sending a wireless session protocol ("WSP") request to the messaging gateway.
  • WSP wireless session protocol
  • all messages between the messaging gateway and any message centre are sent over the MM1 over HTTP over TCP/IP (TCP over IP) protocol.
  • HTTPS may be used instead of HTTP.
  • the method may further include the step of reporting successful retrieval of the MM on the device.
  • a system for sending a MM to a device comprising:
  • the MM notification message takes the form of a SMS
  • 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.
  • Figure 1 is a schematic flowchart representation of the A2P process of the prior art.
  • FIG. 2 is a schematic flowchart representation of the process claimed in the present 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.
  • 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.
  • 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.
  • MM notification messages 70 are generated.
  • the MM notification messages 70 are sent to the devices 30 using the SMPP protocol via an SMSC 100.
  • 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.
  • data is extracted, transformed and loaded (“ETL") 120 from the MM file and a MSISDN list is 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • APN Access Point Name
  • the APN configured on the device 30 will point to a MMSC URI/IP address.
  • 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.
  • 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.
  • 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.
  • DDR device description repository
  • 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.
  • MM content generation component (not depicted) builds the content of MM at the MMSC 1 10, based on the credentials passed to it.
  • 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.
  • 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.
  • 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.
  • the system further comprises a DDR database, as described above, in order to achieve aspects of authentication described.
  • 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.
  • 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.
  • any of the messages between the messaging gateway and any message centre may be sent over the set of any of the following protocols: HTTP over TCP/IP, and HTTPS over TCP/IP.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Cette invention porte sur un procédé d'envoi d'un message multimédia (« MM ») à un dispositif, comprenant les étapes consistant à : générer un fichier MM, contenant un paquet de données concernant l'utilisateur du dispositif; relayer le fichier MM vers un centre de messagerie; envoyer un message de notification de MM du centre de messagerie au dispositif; envoyer une requête du dispositif à un MMSC, demandant la récupération du MM; authentifier un détail du dispositif au niveau du MMSC, afin d'évaluer le format approprié du contenu pour le MM demandé; générer le contenu du MM au niveau du MMSC; et récupérer le contenu du MM sur le dispositif. L'invention concerne également un système complémentaire pour envoyer un tel MM à un dispositif.
PCT/ZA2012/000094 2011-12-15 2012-12-07 Système et procédé d'envoi d'un message multimédia WO2013090949A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ZA2011/09236 2011-12-15
ZA201109236 2011-12-15

Publications (1)

Publication Number Publication Date
WO2013090949A1 true WO2013090949A1 (fr) 2013-06-20

Family

ID=47521194

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ZA2012/000094 WO2013090949A1 (fr) 2011-12-15 2012-12-07 Système et procédé d'envoi d'un message multimédia

Country Status (1)

Country Link
WO (1) WO2013090949A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070239737A1 (en) * 2006-03-31 2007-10-11 Dudley William H System and method for providing feedback to wireless device users
US20100029308A1 (en) * 2008-08-01 2010-02-04 Cellco Partnership D/B/A Verizon Wireless Direct mobile station-to-mobile station communication of multimedia message service (mms) messages
US20100151888A1 (en) * 2008-12-11 2010-06-17 Samsung Electronics Co., Ltd. Method and system for transmitting and receiving multimedia message

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070239737A1 (en) * 2006-03-31 2007-10-11 Dudley William H System and method for providing feedback to wireless device users
US20100029308A1 (en) * 2008-08-01 2010-02-04 Cellco Partnership D/B/A Verizon Wireless Direct mobile station-to-mobile station communication of multimedia message service (mms) messages
US20100151888A1 (en) * 2008-12-11 2010-06-17 Samsung Electronics Co., Ltd. Method and system for transmitting and receiving multimedia message

Similar Documents

Publication Publication Date Title
US8798241B2 (en) Secure visual voicemail
KR101274366B1 (ko) 주소록 연락처 관리 방법 및 장치
US20070198731A1 (en) System and method for processing multimedia messages
KR20140066765A (ko) 문자 메시지들에 대한 보관 제어
US20080294729A1 (en) Email object for open mobile alliance data synchronization usage
US10419371B2 (en) Methods and systems for delayed notifications in communications networks
KR20100089096A (ko) 미디어 파일의 인텔리전트 캐싱
US8200259B2 (en) Network-specific transcoding of MMS content
MX2007001440A (es) Metodo para transmitir datos de alta o de baja especificos de la aplicacion y sistema, servidor, y terminal de comunicacion para el mismo.____________________________________________________.
KR20110005896A (ko) 데이터 타입 및/또는 데이터 포맷의 변환에 의한 ｍｍｓ 메시지 전송
US9742829B1 (en) Managing multimedia messages being transmitted to recipient devices of foreign networks
WO2009087566A1 (fr) Systèmes et procédés pour ajouter un contenu multimédia à des messages électroniques
US8249560B2 (en) Sending method, receiving method, and system for email transfer by short message
AU2004324519B2 (en) Informing recipient device of message content properties
WO2012155474A1 (fr) Procédé, appareil pour envoyer un service de messagerie multimédia (mms) et terminal
US8271008B1 (en) Preventing spam messages
WO2013090949A1 (fr) Système et procédé d'envoi d'un message multimédia
KR100932484B1 (ko) 이동통신 단말기의 이미지에 단문메시지 삽입방법
US20090031323A1 (en) Communication system and method
ZA200901923B (en) Method for sending mobile statements
Wang et al. MMSEmail: Delivering Emails to Mobile Phone Through MMS
KR20090006234A (ko) 수신자 장치에 대한 메시지 콘텐츠 속성들의 통보

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12812809

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12812809

Country of ref document: EP

Kind code of ref document: A1