EP1378134A1

EP1378134A1 - Message distribution system

Info

Publication number: EP1378134A1
Application number: EP01951446A
Authority: EP
Inventors: Lars Bo Jensen; Vilhelm Kruse; Thomas Hüttel LARSEN; Dent-de-Lion c/o Niclas V. Werdt DU MIDI
Original assignee: Hellodies AS
Current assignee: Hellodies AS
Priority date: 2001-04-06
Filing date: 2001-07-09
Publication date: 2004-01-07
Also published as: WO2002082837A1

Abstract

The invention relates to a method of distributing multimedia messages from a sender (S; WEU, MU) to a mobile recipient (MR) via at least one mobile communication network (TNET) and via at least one central multimedia distribution platform (CMDP) said method comprising the steps of establishing the message content (MC) identifying a mobile recipient (MR) said at least one central multimedia distribution platform (CMDP) transmitting the message content (MC) to the identified mobile recipient (MR ). A central multimedia distribution platform (CMDP) according to the invention facilitates advantageous features such as central billing, central administration of the message flow to the mobile recipients, establishment of agreements e.g. with music providers covering the entire music traffic of the system. Moreover, statistics may be established with the purpose of analyzing the behavior of the sender and the mobile recipients.

Description

MESSAGE DISTRIBUTION SYSTEM

Field of the invention The present invention relates to a method of distributing multimedia messages from a sender to a mobile recipient according to claim 1.

Background of the invention

The invention addresses distribution of different types of customized multimedia messages to mobile subscribers.

Several systems are known within the art.

One of these systems is known from US patent 6,094,587.

The patent discloses a method for programming a ringing tone of a telephone. The ringing tone is modified into characters which may be transmitted with a ringing tone identifier to a receiver adapted to receipt of such a ringing tone. The characters may be reproduced as a ringing tone at the recipient.

A problem with the above-described customized message system and other systems of this type is that such customization can only be obtained by an attachment to normal "manual" communication.

A further problem with the above-mentioned message system is that it requires specified system components, i.e. mobile phones of a specific brand, due to the fact that mobile phones are generally not able to convert incoming characters into tones which may be reproduced by means of the transducers.

Summary of the invention The invention relates to a method of distributing multimedia messages from a sender (S) to a mobile recipient (MR) via at least one mobile communication network (TNET) and via at least one central multimedia distribution platform (CMDP) according to claim 1,

said method comprising the steps of

establishing the message content (MC)

identifying a mobile recipient (MR)

said at least one central multimedia distribution platform (CMDP) transmitting the message content (MC) to the identified mobile recipient (MR).

A central multimedia distribution platform (CMDP) according to the invention facilitates advantageous features such as central billing, central administration of the message flow to the mobile recipients, management of agreements e.g. with music/media providers covering the entire music/media traffic of the system. Moreover, statistics may be established with the purpose of analyzing the behavior of the sender and the mobile recipients.

It should be noted that the billing may be applied in several different variants within the scope of the invention, e.g. as a central billing performed by a telecommunication network provider based upon billing information provided by the central multimedia distribution platform.

According to the invention, it should nevertheless be noted that the distribution platform advantageously facilitates handling of incoming message distribution orders from the users of the systems. These may be more or less buffered in order to even out the message distributions per time unit in order to fit both the performance of the central multimedia distribution platform and the available transmission capacity from the central distribution platform to the mobile recipients, i.e. the bandwidth offered by the mobile telecommunication providers.

A central multimedia distribution platform according to the invention offers several advantages such as user-friendliness and can be used by a person with minimal knowledge of SMS and mobile phones.

Moreover, the system may be established in a secure way, thereby preventing hacking and misuse.

Moreover, the invention facilitates a reliable distribution system which may be ideally operated 24 hours a day for several months and with minimal down-time.

According to a preferred embodiment of the invention, all data should be redundant in the system. Loss of data may not occur just because one part (i.e. server) in the central distribution platform goes down.

When, as stated in claim 2, the message content is established by communication of message-defining codes (MDC) from the sender to the at least one central multimedia distribution platform (CMDP), a further advantageous embodiment of the invention has been obtained.

By establishment of message-defining codes, communication between the sender and the central multimedia platform may be adapted to addressing the available communication protocol between the sender and the platform in a suitable way. Moreover, the necessary transmission bandwidth may be reduced.

Hence, an example of simple message-defining codes is a traditional GSM telecommunication network in which an SMS message defines the necessary parameters forwarded to the central distribution platform. The message-defining codes may be transmitted as simple text to the distribution platform via a traditional SMS service center and the commands may be transformed at the distribution platform into a multimedia message defined by the sender and by the multimedia "bricks" available at the distribution platform and may subsequently be transmitted to the identified mobile recipient according to transmission conditions. The transmission conditions may typically be managed by administration routines operating in the distribution platform. Moreover, the transmission conditions may be partly defined by the sender, e.g. by means of the message-defining commands or by the conditions of subscription associated with the sender and/or the mobile recipient.

The message-defining codes are not limited to transmission by SMS, but will also cover GSM evaluation of SMS such as EMS and MMS. The same situation will apply with the introduction of new generation networks, such as GPRS and UMTS, by means of which extra bandwidth will be made available and packet-based switching will be introduced and allow for more sophisticated transmission of data.

When, as stated in claim 3, the message-defining codes address the multimedia content (MULC) stored at said at least one central multimedia distribution platform (CMDP), a further advantageous embodiment of the invention has been obtained.

According to a preferred embodiment of the invention, the main body of a multimedia message should be composed by bricks stored in the at least one central multimedia distribution platform (CMDP).

When, as stated in claim 4, the message-defining codes comprise a command structure (CS), a further advantageous embodiment of the invention has been obtained.

According to the invention, simple commands from the sender to the at least one central multimedia distribution platform may define the establishment of a message to the identified user by means of little communication between the sender and the distribution platform. Evidently, such command structure should preferably be of a format which may be handled advantageously by e.g. existing data transmission systems, e.g. the SMS data handling system of a traditional GSM system. When, as stated in claim 5, the message-defining codes comprise a command structure (CS) supported by an interactive user interface (IUI), a further advantageous embodiment of the invention has been obtained.

According to a further preferred embodiment of the invention, the command structure should be supported by an easily accessible user interface providing intuitive access to the system without detailed knowledge of a lot of specialized codes, etc. The interface may e.g. support the user, i.e. the sender, of the above- mentioned traditional data transmission system by returning menus or command descriptions when suitable or required. Moreover, the system should preferably also facilitate a graphical interface which may easily be operated by a user. Such interface may e.g. be web-based communication facilitating graphical interaction between the user, i.e. the sender, and the distribution platform.

When, as stated in claim 6, the interactive user interface (IUI) comprises a message builder (MSGB), a further advantageous embodiment of the invention has been obtained.

According to a preferred embodiment of the invention, the user should be provided with an interface by means of which he may compose a message according to certain predefined message composition rules.

The builder should preferably provide the user with an easy way of preparing and identifying a recipient and a message to be transmitted to that recipient.

When, as stated in claim 7, the message is transmitted to the identified mobile recipient (MR) according to the transmission conditions (TRC), a further advantageous embodiment of the invention has been obtained.

The transmission conditions may typically be laid down by administration routines operating in the distribution platform. Moreover, the transmission conditions may be partly defined by the sender, e.g. by means of message-defining commands or by the conditions of subscription associated with the sender and/or the mobile recipient.

When, as stated in claim 8, the central multimedia distribution platform (CMDP) is associated with a user area domain (USAD) holding individual information (II) related to users () and when at least some of the individual information associated with the individual user may be accessed by the user, a further advantageous embodiment of the invention has been obtained.

According to a preferred embodiment of the invention, a user - typically a subscriber - may have access to a user area domain, typically web-based, in which he may define different customizing parameters, e.g. his personal variation of a command setup, such as a certain code being provided with a certain meaning and executed in a special way when transmitted from the user to the distribution platform. Typically, this way of customizing the available command set should be carried out in such a manner that the user is more or less bound by a fundamental set of commands having a certain meaning. However, he may be provided with an additional set of commands which may be customized.

Moreover, the user may e.g. compose his own hit lists, e.g. a TOP 10, from time to time in such a way that the content of the hit list can be addressed by a simple command such as "H7" or any other short key determined by the user.

When, as stated in claim 9, said user area domain comprises a message builder (MSGB), a further advantageous embodiment of the invention has been obtained.

According to the invention, a message builder comprises a user interface which may be applied for a easy configuration of the user-defining parameters and the messages to be transmitted.

Typically, a message builder may be web-based, but other types of message builders may also be applied within the scope of the invention as long as the message builder can be established as an easily conceivable graphical user interface and preferably be supported by audio reproduction.

It should be noted that a message builder according to the invention preferably deals with the maintenance of the user area domain, i.e. with data relevant to a subscriber of the system, whether he is the recipient or the sender, and especially with the construction (establishment) of the multimedia message to a specified recipient on the basis of different available message components such as song sequences, pictures, text-to-speech audio sequences, etc.

When, as stated in claim 10, the message content is established by means of a multimedia message database (AMD) stored in multimedia message storage means (AMS), a further advantageous embodiment of the invention has been obtained.

According to a preferred embodiment of the invention, the multimedia message may preferably be searched and selected from a predefined audio database available to the user.

The multimedia message may e.g. comprise an audio message. The message may preferably be pre or post processed in order to optimize the message content with respect to transmission and reproduction at the recipient prior to transmission to the identified mobile recipient. Moreover, this pre or post processing should preferably compensate for the compression associated with the network transmission and the mobile devices of the recipient.

When, as stated in claim 11, a speech message is added to the message content (MC), said speech message being established by means of a text-to-speech generator associated with the central multimedia distribution platform (CMDP), a further advantageous embodiment of the invention has been obtained. According to the invention, the sender may simply forward text to the central multimedia distribution platform (CMDP) where it may be converted into a speech audio signal which may be included in the message content.

The conversion into speech signals may e.g. be performed according to different available conversion routines, e.g. text-to-Donald Duck speech, man, women, etc.

The speech message added to the message content (MC) may also be established by means of audio recording means which means that a sender may establish his own audio-file, e.g. a WAN-file instead of e.g. applying text-to-speech. Hence, by means of e.g. his own hardware/software or by applying a "sample-service" provided by the distribution platform in order to record his/her own voice, the sender may create speech or song and attach this speech or song message to the message content.

When, as stated in claim 12, said central multimedia distribution platform (CMDP) comprises a message transmission monitoring system and when the message transmission monitoring system involves at least one measuring step (205, 209, 213, 217), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 13, said measuring step measures transmission faults, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 14, said central message distribution platform comprises filters determining different multimedia transmission conditions, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 15 said filters determine certain predefined conditions which terminate or block certain predefined multimedia transmissions when fulfilled, a further advantageous embodiment of the invention has been obtained When, as stated in claim 16, said filters are established by the central multimedia distribution platform, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 17, said filters are established by subscribers of the central multimedia distribution platform, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 18, said filters are established by subscribers of the telecommunication network provider (NP), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 19, said filters are adapted to preventing misuse of the central multimedia platform, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 20, the establishment of a multimedia message (MSG) is associated with identification of the sender, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 21, the established multimedia message (MSG) is associated with an advertising multimedia message such as a audio message, picture message, text-message or movie message, a further advantageous embodiment of the mvention has been obtained.

When, as stated in claim 22, said message builder comprises a search tool facilitating search of the multimedia message data bank by the user (WEU, MU) by means of a predetermined search syntax, a further advantageous embodiment of the invention has been obtained. When, as stated in claim 23, the time within which said message (MSG) must be transmitted to said mobile recipient (MR) is established by the user (WEU, MU), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 24, said speech message added to the message content (MC) is established by means of audio recording means, a sender may establish his own audio-file, e.g. a WAN-file instead of applying text-to-speech. Hence, by means of e.g. his own hardware/software or by applying a "sample-service" provided by the distribution platform in order to record his/her own voice, the sender may create e.g. speech or song and attach this speech or song message to the message content.

When, as stated in claim 25, a multimedia message is added to the message content (MC), said multimedia message may be established by means of multimedia message generating programs.

According to the invention, the message content may be supplemented by the already mentioned text-attachment established by means of sound recording means, by personal picture or video sequences established by cameras or camcorders or by drawings created in a CAD-system.

The multi-media attachment may e.g. be established in standard multi-media formats which may be reproduced at the mobile recipient directly or subsequent to a conversion of the added attachment at the central multimedia distribution platform.

The multi-media attachment may also be established by means of suitable software/hardware provided by the central multimedia platform in order to obtain a certain degree of uniformity with respect to the distributed message content.

An example of such suitable hardware/software may e.g. be a user calling a facility of the central multimedia distribution platform, identifying himself to the platform and "leaving a message" to a sound recorder which may subsequently attach the recorded sequence to a multimedia message or at least transmit the recorded sequence to the user so that he may actually choose whether to attach the recorded sequence to a message or not.

When, as stated in claim 26, the telecommunication network (TNET) comprises a GSM network, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 27, the telecommunication network (TNET) comprises a UMTS network, a further advantageous embodiment of the invention has been obtained.

Evidently, several different mobile communication systems may be applied within the scope of the invention.

When, as stated in claim 28, the message content comprises trigger codes which may be executed at the mobile recipient (MR) if associated with signal processing routines and/or data stored at said mobile recipient (MR), a further advantageous embodiment of the invention has been obtained.

Trigger codes may e.g. include applet-like codes which may be forwarded by the central distribution platform to the mobile recipient MR.

When the mobile recipient receives the trigger (e.g. an applet), a user-installed program (e.g. a virtual machine) will execute the program requested by the trigger or if it is an applet, execute the applet at the mobile recipient MR.

Evidently, transmission of such triggers (e.g. applets) may be initiated by a variety of other message defining codes than the SMS suggested above.

It should be noted that the above-mentioned suggested set of commands may be modified significantly within the scope of the invention. Hence, further functions may be added and the illustrated command set may evidently be simplified to fit the desired system structure. Hence, according to the invention, the multimedia content may e.g. comprise different codes which involve reproduction of sound, pictures, movie sequences, etc., at the mobile recipient when most of the resulting audio or image components are stored at the mobile recipient.

Evidently, signal processing routines and/or data stored at the mobile recipient may advantageously be updated from time to time if suitable.

Moreover, the invention relates to a method of managing delivery of messages () from a sender to a mobile recipient of a telecommunication network according to claim 29, said method of comprising the steps of

establishing a message (MSG) to an identified mobile recipient (MR)

performing a delivery check (DCHK) determining whether the established message (MSG) can be delivered to the identified recipient or not,

determining whether the message () is delivered to the identified mobile recipient (MR).

When, as stated in claim 30, said established message (MSG) is transmitted to the identified mobile recipient (MR) via at least one central multimedia distribution platform (CMDP), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 31, said delivery check (DCHK) is performed by establishing transmission to the identified mobile recipient (MR) and subsequently determining whether the transmission is received by the mobile recipient (MR) or not, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 32, said delivery check (DCHK) is performed as an initial test determining whether the identified mobile recipient is available or not prior to transmission to the identified mobile recipient (MR), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 33, the availability of the mobile recipient is determined by checking the relevant registers associated with the identified recipient of the mobile telecommunication network, a further advantageous embodiment of the invention has been obtained. When, as stated in claim 34, said relevant registers comprise the home location register (HLR) of a mobile telecommunication network, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 35, said delivery check (DCHK) moreover comprises an acceptance check (ACHK) determining whether the identified recipient accepts receipt of the established message (MSG) or not, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 36, said transmission of the established message comprises a call to the identified mobile recipient (MR), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 37, said transmission of the established message comprises transmission of the message (MSG) defined by packet-based data (PBD) to the identified mobile recipient (MR), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 38, said packet-based data (PBD) are executed as a multi- media message (MMSG) at the mobile recipient (MR), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 39, said multi-media message (MMSG) executed at the mobile recipient (MR) comprises audio signals, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 40, said multi-media message (MMSG) executed at the mobile recipient (MR) comprises image signals, a further advantageous embodiment of the invention has been obtained.

Image signals may both be video and single pictures eventually supported by text or audio signals. When, as stated in claim 41, said established message (MSG) is stored in message storing means (MSM) if the message is not delivered to the identified recipient, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 42, said identified mobile recipient (MR) is notified if a message (MSG) is not delivered and the message (MSG) may subsequently be retrieved by the mobile recipient (MR) by accessing said message storing means (MSG), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 43, said message (MSG) stored in said message storing means (MSM) is erased from said message storing means (MSM) if certain predefined storing conditions (STCO) are fulfilled, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 44, a predefined storing condition (STCO) may be that of the message not having been retrieved by the mobile recipient within a certain time limit, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 45, the sender is notified if the message is not delivered to the identified mobile recipient (MR), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 46, the sender is notified if the message is delivered to the identified mobile recipient (MR), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 47, the sender's billing record (BR) is charged if the message is delivered to the identified mobile recipient (MR), a further advantageous embodiment of the invention has been obtained. When, as stated in claim 48, said central multimedia distribution platform CMDP comprises at least one central controller (CC) and at least one local controller (LC), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 49, the sender is charged according to the method of claims 51 to 60, a further advantageous embodiment of the invention has been obtained.

Moreover, the invention relates to a method of distributing audio/multimedia messages from a sender to a mobile recipient (MR) via at least one mobile communication network according to claim 51 ,

said method comprising the steps of

establishing the message content (MC)

identifying a mobile recipient (MR)

transmitting the message content (MC) to the identified mobile recipient (MR)

charging the sender's billing record (BR).

Moreover, the invention relates to a method of distributing multimedia messages from a sender to a mobile recipient (MR) via at least one mobile communication network according claim 52,

said method comprising the steps of

establishing the message content (MC)

identifying a mobile recipient (MR)

transmitting the message content (MC) to the identified mobile recipient (MR) charging the sender's billing record (BR) if the message is delivered to the identified mobile recipient (MR).

According to a preferred embodiment of the invention, the sender should only be charged if the identified mobile recipient (MR) receives the message, and even more preferably, if he accepts it.

Hence, the invention facilitates advantageous control of the message flow from the distribution platform to the involved mobile recipients in the sense that the message is not transmitted as a kind of message bombardment without consideration of whether it is actually delivered or accepted by the mobile recipient.

When, as stated in claim 53, said message content comprises multi-media elements such as audio messages, picture-defining data, scents, etc., a further advantageous embodiment of the invention has been obtained.

According to the invention, multi-media messages should preferably contain at least audio messages. Nevertheless, pictures, video, etc. may be applied if suitable.

When, as stated in claim 54, said message content comprises emotional message content, preferably in the form of a sequence of a song, a further advantageous embodiment of the invention has been obtained.

The invention addresses emotional message distribution in the sense that a recipient may be addressed by means of message content establishing a mutual understanding between the sender and the recipient. Evidently, this type of addressing relies heavily on pre-established social contact between the sender and the recipient.

When, as stated in claim 55, charging a billing record implies that the sender's billing record is updated according to a predefined billing schedule, a further advantageous embodiment of the invention has been obtained. According to the invention, different terms of billing may be applied.

When, as stated in claim 56, the predefined billing schedule defines an update of an account associated with the sender, a further advantageous embodiment of the invention has been obtained.

When associating an account with a user, it is possible to define customized billing schedules to different users and to invoke long-term conditions which need to be fulfilled if certain billing criteria are desired.

Within the scope of the invention, a billing schedule may e.g. be a traditional account associated with the user on a subscriber basis. A bill is paid or a money transfer is made by the user to the service provider on a regular basis.

The account may also be managed as an up-front payment account, i.e. requiring up- front payment by users applying for the service available.

Moreover, the user may be offered different bonuses or subscriber conditions, e.g. with respect to consumption.

Hence, the ways of managing an account within the scope of the invention are numerous.

When, as stated in claim 57, the predefined billing schedule defines each transmission being charged individually, a further advantageous embodiment of the invention has been obtained.

Further optional billing schedules may be applied within the scope of the invention. When, as stated in claim 58, the account associated with the sender is controlled and updated by the sender's network provider (NP), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 59, billing information (BI) is transferred from the central multimedia distribution platform provider to the relevant network provider (NP), a further advantageous embodiment of the invention has been obtained.

According to the invention, billing information may be distributed to the relevant network providers .

Thereby, different network providers may utilize the same external platform without any inconvenience to the subscriber since the only billing interface established is between the network provider and the subscriber.

The term "relevant subscriber " covers the network provider with which the sender is subscriber.

Billing information transferred from the service provider to the network provider facilitates advantageous and central billing since the billing system is typically already established at the network provider with the purpose of charging the subscribers.

When, as stated in claim 60, the account associated with the sender is controlled by the central multimedia distribution platform provider of the sender, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 61, a central multimedia distribution platform comprises signal processing means, said signal processing means operating according to any of claims 1 to 60, a further advantageous embodiment of the invention has been obtained. The figures

The invention will now be described in detail with reference to the drawings, in which

fig. 1 illustrates the basic functioning of a computer applied according to the invention,

fig. 2 illustrates the basic functioning of a mobile phone applied according to the invention,

fig. 3 illustrates an overview of a preferred embodiment,

figs. 4a to 4c illustrate preferred multimedia message transmission sequences according to the invention,

figs. 5a to 5c illustrate flowcharts of different sub-routines of a preferred message distribution platform according to the invention,

fig. 6 illustrates another preferred multimedia message transmission sequence according to the invention,

fig. 7 illustrates a flowchart of the basic steps of the delivery process according to an embodiment of the invention,

figs. 8a to 8c illustrate different variants of the location of the central multimedia distribution platform,

figs. 9a to 9e illustrate a possible groupings of preferred song fragments and song management control according to the invention,

fig. 10 illustrates another overview of a preferred embodiment, fig. 11 illustrates a preferred central controller according to the invention,

fig. 12 illustrates a preferred local controller according to the invention,

fig. 13 illustrates a preferred redundancy system according to the invention.

Detailed description

Fig. 1 shows a computer COM including a CPU (not shown), said computer COM comprising a data disk and an arithmetic logic circuit configured to prepare the data disk to magnetically or optically store selected data (not shown).

The computer moreover comprises a monitoring unit MON and a number of input devices such as keyboard KBD, mouse M etc.

The computer COM may comprise means for data communication with a telecommunication network (not shown) e.g. the Internet.

A user may e.g. use the illustrated computer COM when preparing a multimedia message to a mobile recipient.

Fig. 2 shows a mobile device MOB. The mobile phone MOB comprises an antenna ANT for transmitting and receiving calls and messages to and from a mobile telecommunication network.

The illustrated device MOB comprises a loudspeaker SPK for rendering audio signals to a user and a microphone MIC for establishing electrical representations of audio signals to be transmitted directly or indirectly to the telecommunication network.

Moreover, the device comprises a display DIS for monitoring call and message information and a keyboard MKBD e.g. for inputting phone numbers or sending

SMS messages.

A user may e.g. use the illustrated device MOB when preparing a multimedia message to a recipient. In addition, the illustrated mobile device comprises software for management of transmission and receipt of data. This software may e.g. comprise programs that can be downloaded such as a virtual machine for Java applets suitable for management of multimedia messages.

Messages sent from the cenfral distribution platform CMDP to a mobile device MOB may then be transmitted as triggers (e.g. applets) from the cenfral distribution platform CMDP to the mobile recipient MR. The triggers or e.g. applets execute specific commands in the virtual machine on the mobile recipient's phone.

Hence, according to the invention, the necessary transmission bandwidth may be reduced significantly if the mobile device offers such facility.

Evidently, other devices than the above-mentioned more or less traditional telecommunication devices may be applied within the scope of the invention, such as PDAs (PDA: Personal Digital Assistant), Fixed Telephones, etc.

Fig. 3 shows an embodiment according to the invention. The system comprises a number of computers COM and a number of mobile telecommunication devices MOB.

The computers COM and the mobile telecommunication devices MOB may be applied for establishment of multimedia messages to be transmitted from a web- based user WEU or a mobile user MU to a mobile recipient MR communicating with the illustrated telecommunication network TNET.

The sender may also be referred to as the initiating part.

The illustrated telecommunication network comprises a base station BS, a mobile telecommunication network TNET and a number of mobile recipients MR. According to the invention, a user may connect with a central multimedia distribution platform CMDP via the Internet I by means of a computer COM or he may connect with the cenfral multimedia disfribution platform CMDP by means of a mobile telecommunication device MOB via a mobile telecommunication network (not shown).

Evidently, communication from a user to the cenfral multimedia distribution platform CMDP may be established from other types of communication devices than the above-illustrated and via other types of communication media.

The cenfral multimedia distribution platform CMDP is communicating with a mobile recipient MR via the above-mentioned telecommunication network TNET.

The telecommunication network may e.g. comprise a traditional GSM network or e.g. a UMTS network.

When a user WEU of one of the computers COM or a user MU of one of the mobile telecommunication devices MOB initiates fransmission of a multimedia message to preferably one or several mobile recipients MR, he may connect with the central multimedia distribution platform CMDP and perform a number of actions defining the message content MC and identifying a mobile recipient MR to whom the message content MC should be delivered.

According to the illusfrated embodiment of the invention, a user - the initiating part - uses the central multimedia distribution platform CMDP to establish the multimedia content MC to be transmitted to a mobile recipient MR identified by a mobile recipient ID MRID.

Details of the establishment of such message content and the mobile recipient will be described below. Basically, it should be noted that the central multimedia distribution platform CMDP controls the distribution of multimedia messages, partly on the basis of a control strategy associated with the multimedia disfribution platform and partly on the basis of the transmission conditions laid down by the initiating part, i.e. the sender.

A control strategy may e.g. comprise a strategy according to which the message content is delivered to a mobile recipient MR and another strategy according to which a message is handled if the message is not immediately delivered to the recipient. One of several applicable message delivery strategies is described below with reference to figs. 5 A to 5C.

It should be noted that the control strategy is extremely important, according to a preferred embodiment of the invention. Different kinds of strategies will be described below.

Transmission conditions may be conditions determined by the sender such as the ID or telephone number of the mobile recipient MR or e.g. the text content or the manner in which the text content is franslated into speech. Different kinds of transmission conditions will be described below.

It should be noted that the above-stated definitions should be understood very broadly since a clear-cut differentiation between the strategies defined in/by the platform and the transmission conditions laid down by the user is not intended according to a preferred embodiment of the invention as several definitions may be applied within the scope of the invention.

Typically, a user must sign up before being able to send an audio message to e.g. a friend via the platform. After the sign-up phase, the user now has access to the distribution platform audio message data base AMD, see e.g. fig. 9a, on the Central multimedia distribution platform CMDP in which he may search for and select songs and identify recipients. When a client has prepared the message content, e.g. a song sequence selected from the audio message database AMD combined with a text-to-speech message, and identified a mobile recipient to the Cenfral multimedia disfribution platform CMDP, a transmission sequence TSEQ is transmitted via the base station BS of a mobile network to the mobile device MOB of a mobile recipient MR. The receiver is now able to hear the audio message string AM.

The transmission sequence TSEQ may e.g. be established according to the fransmission sequence described in fig. 6.

A telecommunication network according to the invention may evidently comprise several base stations BS of different traditional configurations.

Message formats

The message format, i.e. the available commands for communication between a user and a multimedia message disfribution platform according to the invention, may vary significantly from application to application depending on the hardware environment and setup.

Evidently, communication between the user and the platform may be quite sophisticated if made via the web.

In other systems, e.g. when the user, who is mobile himself, wants to prepare a multimedia message to another mobile recipient, the communication may e.g. be performed in a traditional and quite simple manner by the data message system being supported by the user's own hardware, i.e. the mobile device, and the system being supported by his telecommunication network provider. One of several options within the scope of the invention will be described below.

The below-described message format is applied for fransmission in a traditional GSM network by means of SMS messages. Note that a message format according to the illustrated embodiment is only applied for communication between the user, i.e. the sender, and the disfribution platform. Another format is applied for communication between the distribution platform and the mobile recipient.

According to one embodiment of the invention, a format may be:

HELLO [Receiver no.] [Song ID] [Text message]

The maximum length of the SMS is a standard of 160 characters.

It should be noted that other message services may be applied within the scope of the invention. Such message services may e.g. include new SMS standards such as EMS and MMS covered by the GSM network. The same will apply to the introduction of new generation networks, such as GPRS and UMTS, where extra bandwidth will be made available and packet-based switching will be introduced and allow for more sophisticated transmission of data.

The SMS is e.g. sent to the distribution platform access number, e.g. 555, where the message is handed over to the disfribution platform and the received SMS message may be translated into a series of executable commands depending on the content of the SMS message.

The available commands may e.g. be the set of message defining commands MDC suggested below.

Table 1: Set of SMS commands

It should be noted that the above-described communication format available for communication between the sender and the distribution platform if the sender is mobile may of course be supplemented by other communication formats which may be accessed in a somewhat more user-friendly nature, e.g. via a web-site.

It should, however, be noted that the above-described communication format facilitates sought interaction between the user and the distribution interface, e.g. the command string HELLO SONG X, which will return a list of five songs starting with e.g. A. Several interactive menu-structures may be applied within the scope of the invention with the purpose of easing communication between the user and the distribution platform. After receiving the SMS request, the distribution platform will generate the message as an audio file and the requested text message may be converted into speech by a text-to-speech module. It would also be possible to select the voice of the text-to- speech module (Donald Duck, Man, Woman, etc.) to be used by adding /[No] to the beginning of the text message.

The distribution platform will then initiate a voice call to the requested phone number and, if accepted, play the audio message.

A further applicable manner in which a multimedia message MSG may be executed at the mobile recipient MR would be by sending SMS messages to the cenfral disfribution platform CMDP from sender S. These SMS messages are then converted into triggers or e.g. applets and forwarded by the cenfral disfribution platform to the mobile recipient MR. When the mobile recipient receives the frigger or e.g. applet, the user-installed program, e.g. a virtual machine, will execute the program requested by the trigger or if it is an applet, execute the applet on the mobile recipients MR.

Evidently, transmission of such triggers (e.g. applets) may be initiated by many other message defining codes than the SMS suggested above.

It should be noted that the above-mentioned suggested set of commands may be modified significantly within the scope of the invention. Hence, further functions may be added and the illusfrated command set may evidently be simplified to fit the desired system structure.

Figs. 4A to 4C illustrate a preferred multimedia message format to be used for transmission of multimedia messages MSG according to a preferred embodiment of the invention. Evidently, other multimedia message formats may be applied within the scope of the invention. The described multimedia message format is intended for transmission from the multimedia disfribution platform to an identified mobile recipient MR as a regular call via a speech channel of e.g. a traditional GSM telecommunication network.

The establishment of the transmission is e.g. performed by an initiating part, a web- based user WEU, by means of the computer as described in fig. 1 or by a mobile user MU by means of a mobile telecommunication device MOB as described in fig. 2.

After receiving an SMS via an SMS-C from a mobile user MU or a message from a web-based user WEU requesting transmission of a message, the central multimedia distribution platform CMDP (e.g. the local controller LC described in figs. 10, 12A and 12B) will create two audio-files audio file 1 and audio file 2 as described in fig. 4 A and fig. 4B, respectively, and initiate a voice call to the requested phone number and, if accepted, play the audio-files illustrated in fig. 4B.

Audio file 1 comprises an h-id and audio file 2 comprises an h-clip + h-text + h-tag.

After playing the audio file 1, i.e. the h-id, to an identified mobile recipient, interpretation of e.g. the DTMF tone may be requested by the recipient by pushing a button if he/she wants to hear the second audio file 2. This acceptance step will be described in detail below.

The audio-files 1 and 2, which last approx. 20 - 60 seconds in total, should conform to the platform message format which consists of the elements outlined in figs 4A to 4B described below.

The different parts of the audio-files are made up of: h-id: The audio logo (jingle) followed by the introduction message: "You have a message from [Nickname] and [phone number]. Press 1 to hear the message." h-clip: The media clip consists of a specially edited piece of the requested song. h-text: The personal (text) message from one user to another franslated from text-to-speech. h-tag: The audio logo (jingle). Possibly followed by the message: "Press 1 to learn more about the person who sent you this message."

Example:

• [message audio logo] "You have a message from 40252010. Press 1 to hear the message. "

• The mobile recipient presses 1 on his/her mobile phone.

• [Song: I just called to say I love you] "Hz^" Sweetheart. Miss you more than you will ever know " [message audio logo] "Press 1 to learn more about the person who sent you this message. " • The mobile recipient presses 1 on his/her mobile telecommunication device.

An SMS is sent to the mobile recipient containing the phone number of the sender, e.g. web-based user WEU or mobile user MU, together with information about www.noname.com.

If a received SMS platform command from a mobile user contains the keyword "PLAY" (see the already described table 1 above), the audio-file format looks different. In this situation, there is no need for the recipient to acknowledge receipt since the sender of the multimedia message MSG is now the mobile recipient.

The relevant audio file 3 is then illusfrated in fig. 4C.

The different parts of audio-file 3 are made up of:

P-id: The audio logo Gή gle) followed by the introduction message: "You have requested to hear song [Song-ID]." p-clip: The media clip consists of a specially edited piece of the requested song. p-tag: The audio logo Gingle).

The above-described multimedia message is a pure audio message delivered to the identified recipient.

Similar solutions may be made available to other users, such as WAP-users or web- based users WEU.

According to further embodiments of the invention, pictures, video or other emotional effects may be transmitted to the user.

It should be emphasized that the above-mentioned message format may be delivered to the mobile recipient as data packet, e.g. in GPRS variants of the GSM or e.g. UMTS. Data packet-based transmission may e.g. imply that the telephone number is exchanged by a unique ID associated with each user of a mobile telecommunication network.

Figs. 5A to 5C illustrate different sub-routines which may be applied within the scope of the invention. It should be noted that the processes are only illustrative and should in no way restrict the inventive aspects of the present invention.

In particular, it should be emphasized that many of the below-mentioned process steps may be omitted, repeated or moved to other sub-routines than the illustrated flows as long as the overall purposes of the invention is obtained.

Fig. 5A illustrates one of several ways within the scope of the invention in which a multimedia message according to the invention may be established.

The interface for establishment of multimedia messages for distribution on a central multimedia delivery platform illustrated in fig. 5A may also be referred to as a builder, i.e. an interface adapted to converting a number of inputs into a multimedia message which may be distributed according to the invention.

Message builder

Turning now to the establishment of multimedia messages and the preparation of transmission of the messages to the intended mobile recipient, the invention offers several ways of obtaining the desired result.

According to one embodiment of the invention, a multimedia message to a mobile recipient is established by means of a suitable tool created for this particular purpose. This tool may be referred to as a message builder.

The message builder is established as an interface by means of which a user may compose the message to be distributed by the multimedia message distribution platform.

When applying the above-mentioned SMS-based command structure, the message builder simply becomes an command translator associated with e.g. a NASP, a Value Added Service Platform.

Other message builders may be much more sophisticated and complex with respect to both user-friendliness and available options.

A more advanced message builder may e.g. comprise a web-based interface which may be accessed by the user via the Internet in the traditional manner and offer a great deal of multimedia support to the user with respect to the message building.

Thus, a web-based message builder may feature complete monitoring of selectable message contents such as song sequences, pictures, etc. due to the fact that the web- protocols facilitate interactive multi-media communication and due to the fact that many of today's users own computer equipment capable of supporting such communication.

Evidently, such a message builder relies on suitable data fransmission between the user and the disfribution platform and on the user having suitable data processing telecommunication units.

The message builder may be interfaced e.g. by user hardware as described in fig. 1 or 2.

In process step 401, the builder is accessed by the user.

Access may e.g. be obtained by means of a suitable interactive web-based interface or simply by transmitting and potentially receiving a number commands at the central platform, e.g. in the form of SMS messages.

In process step 402, it is checked whether the sender has predetermined certain delivery conditions e.g. established in a user profile.

If delivery conditions are not determined, the process continues with step 403 by determination of delivery conditions. The delivery conditions may e.g. simply be determined by extracting a part of an SMS command containing delivery conditions or simply by applying general conditions if no specifically determined parameters have been established by the user.

If delivery conditions are determined, e.g. specified in the sender subscription profile - also called user profile -, the process continues with step 404 by determining whether an interactive interface is used with the present message establishment.

This may be determined more or less indirectly. If no such interface is desired, the process simply proceeds to step 406. If such interface is desired, this may be established with step 405.

The established interface may be applied to the rest of the message building process.

With step 406, the sender identifies the intended mobile recipient, e.g. by inputting a telephone number or a certain recipient ID number.

The process proceeds with step 407 in which the determination of the message content is initiated.

This determination of message content is continued with step 408 in which the sender may access a message bank associated with the cenfral message delivery platform.

If the sender decides to choose a multimedia message available from the multimedia message bank, he may attach the selected multimedia message to the message he intends to build.

Such multimedia message may e.g. comprise one or several sequences of a song stored in the message bank.

With step 410, the sender may choose to attach speech content to the message content, e.g. by inputting text characters in the message. If this is done, the text message may be transformed into audio speech message with step 411.

Evidently, the inputted text may simply be transmitted as a readable text message to the user in other system within the scope of the invention if the systems facilitates such readable text attachment.

With step 412, message fransmission is initiated. The next step 413, which is delivery, represents a jump to the next sub-routine, delivery management. This delivery management is described in fig. 5B.

Turning now to fig. 5B, one of several advantageous embodiments of a delivery strategy within the scope of the invention will be described.

The flow chart illustrates a delivery method implemented by a central multimedia distribution platform CMDP.

The flow chart illustrates one embodiment of a delivery strategy according to the invention. Evidently, several other variants may be applied, both by omission of certain process steps and by adding further process steps.

The illustrated flow chart may be applied to deliver multimedia messages both by regular calls, i.e. applying speech channels of a mobile telecommunication network, or it may be applied to deliver multimedia message by transmission of data packets to the relevant mobile recipient and subsequently be rendered by rendering means associated with the mobile recipient.

According to a preferred embodiment of the invention, the message comprises an audio message to the recipient by means of a regular call established in a traditional telecommunication network, e.g. a GSM network.

The central multimedia disfribution platform CMDP controls the distribution of multimedia messages, here represented by audio messages to selected recipients via a telecommunication network TNET.

According to the invention, the below-described routine is initiated once a sender has composed a multimedia message and identified the intended recipient of the message according to e.g. the previously described builder flow chart in fig. 5A. Hence, a multimedia message has been established by means of a suitable interface offered to the user, i.e. the sender. The established multimedia message has moreover been associated with an ID by which the sender has identified the intended mobile recipient of the established message.

Different precautionary registrations for billing and statistical purposes may also be established at this point.

Step 200 represents the process illusfrated by the previously described builder flow chart.

With step 201, a message delivery is established by checking a user profile, i.e. the profile of the sender, in order to determine how or whether the multimedia message should be delivered according to certain conditions laid down in the user profile.

Such a condition may e.g. be a condition in the sender's user profile determining that the sender always requests a multimedia message delivery notification when the message has been delivered. Another condition may e.g. be that the sender only requires notification from the platform if the message has not been delivered within a certain time limit.

Evidently, the above-described routine step 201 may be performed at other stages of the message establishment and delivery process within the scope of the invention.

With step 202, a check is performed to determine whether a user profile is established on the mobile recipient.

With step 203, a check is performed to determine whether the two user profiles, i.e. the sender profile and the profile of the intended recipient in combination or individually, constrain the intended message fransmission. Such restriction may e.g. be a check of whether the intended recipient has established a condition, i.e. a filter, in his profile determining that the recipient refuses receipt of multimedia messages from the current sender.

Moreover, such check may e.g. include information as to the format in which the recipient is able to receive the established multimedia message, e.g. under consideration of specific hardware and software opportunities and their format.

If such constraints are present, the delivery process is terminated with step 204.

If no constraint on the intended message delivery is determined, the process proceeds with step 205.

With step 205, reachability is determined.

According to preferred embodiment of the invention, reachability means whether the recipient may actually be reached by the available hardware.

A non-reachable identified mobile recipient may e.g. be when the Receiver Phone is OFF or if the mobile is not covered by the radio link of the telecommunication network.

A notification will be returned to the distribution message platform CMDP. According to the illustrated embodiment of the invention, the platform will then retry three times at 30-minute intervals to deliver the message to the identified recipient.

Evidently, another number of attempts may be applied at other intervals within the scope of the invention.

After the illusfrated third unsuccessful attempt, an SMS will be sent to the Receiver with information that the message can either be retrieved by sending an SMS to a predefined phone number (555 or xxxx xxxx) with a specified code or be collected at e.g. www.noname.com or another suitable web-site.

If the third reachability check is negative, delivery failure is registered in a platform monitor update step 205. The platform monitor update step 205 is performed in order to obtain both general traffic information for e.g. statistical purposes or it may be applied for monitoring specific critical events which may cause a part of the message traffic on the platform to be suppressed or cancelled under certain conditions.

The events and related conditions causing cenfral manipulation, e.g. interruption of traffic from one specific sender, several senders or all senders to all available mobile recipients MR, may be defined in a filter.

The filter may be set up partly by the sender (subscriber) or the disfribution platform provider.

The update step also comprises a check of the relevant filter determining whether the sender has required feed-back if the message is undelivered.

If feed-back is required, an SMS is submitted to the sender with step 206 and the delivery process is terminated with step 207.

If no feed-back is required, delivery is terminated directly with step 207 with no notification to the sender.

If, however, the recipient is reachable with step 204, the next process step 208 involves an availability check, i.e. a check of whether an identified reachable recipient is available or not.

This step may be performed in several different ways within the scope of the invention, e.g. by checking registers or the mobile network associated with the mobile recipient or the hard way by establishment of a call to the recipient to determine whether the recipient answers his phone or not.

If the identified recipient is available with step 208, the process continues with an accept check step 212, i.e. a determination of whether the reachable and available recipient actually accepts receipt of the message.

If the recipient accepts, delivery of the message is initiated with step 216.

If the message is successfully delivered to the identified mobile recipient with step 216, confirmation of delivery is fed back to the sender with step 220.

Finally, a billing procedure is initiated with step 221.

The billing procedure initiated with step 221 is described in detail in fig. 5C.

If the availability check with step 204 turns out negative, i.e. the recipient is reachable but the call is not answered by the recipient, notification will be returned to the distribution message platform CMDP. According to the illusfrated embodiment of the invention, the platform will then retry three times at 30-minute intervals to proceed with the delivery process to the identified recipient.

After the illustrated third unsuccessful availability check, an SMS will be sent to the Receiver with information that the message can either be retrieved by sending an SMS to a predefined phone number (555 or xxxx xxxx) with a specified code or be collected at e.g. www.noname.com or another suitable web-site.

If the message is undeliverable after the predefined last attempt, delivery failure is registered in a platform monitor update step 209. The platform monitor update step 209 is performed in order to obtain both general traffic information for e.g. statistical purposes or it may be applied for monitoring specific critical events which may cause a part of the message traffic on the platform to be suppressed or cancelled under certain conditions.

Again, the events and related conditions causing cenfral manipulation, e.g. interruption of traffic from one specific sender, several senders or all senders to all available mobile recipients MR, may be defined in a filter.

If feed-back is required, an SMS is submitted to the sender with step 210 and the delivery process is terminated with step 211.

If no feed-back is required, delivery is terminated directly with step 211 with no notification to the sender.

If the acceptance check with step 212 turns out negative, i.e. the recipient is reachable and available but refuses receipt of the multimedia message, notification will be returned to the distribution message platform CMDP.

Not further delivery attempts will be made if the recipient refuses receipt of the message unless the recipient refuses receipt under certain conditions, i.e. with a certain delay, at a certain time of the day, etc.

If the message is found undeliverable due to non-acceptance, delivery failure is registered in a platform monitor update step 213. The platform monitor update step 213 is performed in order to obtain both general traffic information for e.g. statistical purposes or it may be applied for monitoring specific critical events which may cause a part of the message traffic on the platform to be suppressed or cancelled under certain conditions.

At this step, the delivery management system of the delivery platform should effectively monitor whether recipients are fed with messages they do not want. Moreover, misuse should be effectively suppressed, e.g. by setting up filters excluding certain senders' access to the platform.

Again, the events and related conditions causing central manipulation, e.g. interruption of traffic from one specific sender, several senders or all senders to all available mobile recipients MR, may be defined in a filter.

The filter may be set up partly by the sender (subscriber) or the distribution platform provider.

If feed-back is required, an SMS is submitted to the sender with step 214 and the delivery process is terminated with step 215.

If no feed-back is required, delivery is terminated directly with step 215 with no notification to the sender.

If the delivery attempt with step 216 fails, i.e. intended transmission to the recipient is not completed, notification will be returned to the disfribution message platform CMDP. According to the illusfrated embodiment of the invention, the platform will then retry three times at 30-minute intervals to proceed with the delivery process to the identified recipient. Evidently, another number of attempts may be applied at other intervals within the scope of the invention.

After the illusfrated third unsuccessful delivery attempts, an SMS will be sent to the Receiver with information that the message can either be refrieved by sending an SMS to a predefined phone number (555 or xxxx xxxx) with a specified code or be collected at e.g. www.noname.com or another suitable web-site.

If the message is found undeliverable after the predefined last attempt, delivery failure is registered in a platform monitor update step 217. The platform monitor update step 217 is performed in order to obtain both general traffic information for e.g. statistical purposes or it may be applied for monitoring specific critical events which may cause a part of the message traffic on the platform to be suppressed or cancelled under certain conditions.

If feed-back is required, an SMS is submitted to the sender with step 218 and the delivery process is terminated with step 219.

If no feed-back is required, delivery is terminated directly with step 219 with no notification to the sender. As mentioned above, if the message is successfully delivered to the recipient, a billing procedure is initiated with step 413 representing the transition to the next subroutine described in fig. 5C.

In fig. 5C, step 300 represents the transition to the aforementioned sub-routine.

With step 301, the relevant account is loaded.

According to a preferred embodiment of the invention, the account should preferably be the account of the sender.

Different types of billing conditions may be contained in the sender's billing record, depending on the nature of the subscription.

With step 302, the billing conditions are determined and, with step 303, the account is updated. It should be noted that the sender is only charged if the message has actually been delivered to the recipient.

Finally, the process is terminated with step 304.

When the message is refrieved from www.noname.com, an SMS is sent to the Sender with information of successful delivery. If the message has not been accessed after a pre-determined period of time depending upon technical feasibility, the message can also be delivered to the voice mail of the receiver. If all delivery attempts fail, the message will be deleted and the Sender be informed by SMS.

Another issue to be considered is the time period within which the message can be delivered. The cenfral multimedia distribution Platform CMDP should preferably have the functionality of delaying messages. The billing of the messages is based on mobile-originating or mobile-terminating SMS depending on operator billing capabilities. The service charges the sender and is typically free of charge for the receiver.

The preferred solution entails premium rated charging of MT SMS. As an alternative, billing records can be generated by the cenfral multimedia distribution platform CMDP and exported to the existing operator billing system.

Fig. 6 shows a preferred transmission sequence TSEQ of a multimedia message MSG according to a further embodiment of the invention. The call sequence comprises a connection test CT, an availability test AT, an introduction sequence INT, an audio message AM, an optional advertisement ADV and finally a switch sequence SW which is also optional. According to the illustration, a presentation phase PP starts when the first two tests, i.e. the connection test CT and the availability test AT, have been performed.

The preferred transmission sequence TSEQ starts with a connection test CT in order to establish whether the recipient's mobile phone may be reached or not. Subsequently, the cenfral multimedia distribution platform CMDP performs an availability test AT to make sure the recipient is actually answering the call and that the answer is not an answering machine.

After the cenfral multimedia distribution platform CMDP has established that the connection test CT and the availability test turned out positive, the call server initiates the presentation phase PP.

According to a preferred embodiment of the invention, the presentation phase PP starts with an introduction sequence INT, e.g. a jingle and an audio message informing the recipient of the sender's identity.

Hence, the introduction sequence INT may ask whether a recipient wants to hear the message PP, according to a embodiment of the invention. If the mobile recipient MR accepts, the presentation phase PP begins with an audio message AM. The audio message AM may e.g. comprise an emotional phrase of a well-known song.

Moreover, the audio message may also comprise a speech-message to the recipient. The speech message may e.g. established by well-known text-to-speech conversion tools.

When the audio message AM is finished, an advertisement ADV may optionally follow.

It should be noted that several other processes are applicable within the scope of the invention.

Fig. 7 illustrates the basic steps of the delivery process according to an embodiment of the invention.

As described above, the system is described as a call-based distribution system. It should, of course, be noted that the system may also be in the form of regular data packet transmission via a suitable transmission system.

Initially, a user may access a cenfral multimedia distribution Platform CMDP according to the invention. During access, he may select a desired audio message from a message bank provided by the system - see figs. 9A to 9E for further details of a possible multimedia bank setup - and identify an intended mobile recipient MR. A dial-up step may then establish the call to the identified mobile recipient MR. Subsequently, the connection to the recipient may be validated, i.e. it is determined whether a call has been (or may be) established to the recipient.

Subsequently, the system may validate whether the recipient is actually available, i.e. whether he actually answers the call. It should be noted that the above-described crash-test-like determination of whether a call may established or not e.g. may be performed more elegantly within the mobile network by the network provider checking the relevant registers of the mobile network covering the identified mobile recipient MR. Such registers may e.g. be the HLR: Home Location Registers of a GSM network. Evidently, such check implies that the registers are available to the network provider.

Figs. 8a, 8b and 8c illustrate different variants of the location of a cenfral multimedia distribution Platform CMDP within the scope of the invention.

Fig. 8a illustrates an embodiment of the invention.

A central multimedia distribution Platform CMDP is owned and operated by a wireless operator. The platform provider delivers functionality and content updates on a regular basis, either on-line or as upgrade patches.

The illusfrated cenfral multimedia distribution Platform CMDP may be accessed by mobile users MU.

Moreover, a web interface can be accessed either through the operator or message portals with potential full service transparency (not shown). Evidently, the illusfrated platform may be accessed by the users by means of other suitable telecommunication devices, e.g. PDA's, etc.

An advantage of the illusfrated system is that the reachability tests may be performed within the telecommunication network TNET in a simple and easy way.

Hence, mobile users MU may be serviced completely both as senders S and mobile recipients MR by a network provider since the central distribution platform is integrated in the operator network. Evidently, such interaction requires a suitable interface between networks TNET of different network providers if billing etc. is to be a part of the implementation business idea.

Fig. 8b illustrates a further embodiment of the invention.

The central multimedia disfribution platform CMDP is owned and operated by an external platform provider.

The illustrated cenfral multimedia distribution Platform CMDP may be accessed by mobile users MU.

Moreover, a web interface can be accessed either through the operator or message portals with potential full service transparency (not shown). Evidently, the illustrated platform may be accessed by the users by means of other suitable telecommunication devices, e.g. PDA's, etc.

Moreover, the above-described system offers the advantage of several mobile network providers being serviced by the same platform.

Hence, the administrative part of the operation of the message disfribution may be carried out by one cenfral platform. Hence, it will appear to the mobile users MU that they are serviced completely both as senders S and mobile recipients MR by their network TNET provider despite the fact that the cenfral disfribution platform is external to the operator network TNET.

Evidently, such external operation of the cenfral multimedia distribution platform CMDP requires two-way communication between the cenfral multimedia distribution platform CMDP and the telecommunication TNET provider in order to establish both the services required by the mobile users MU / web-based users WEU (not shown) and the billing and/or control information established by the cenfral multimedia distribution platform CMDP. Fig. 8c illustrates a further embodiment of the invention.

The further embodiment comprises a multiple access solution which provides customers associated with different network providers NP and operating in different telecommunication networks TNET with access to the message service of one cenfral multimedia disfribution platform CMDP through one common user interface. This feature makes it possible for all mobile customers of a market, independent of choice of carrier, to access the service.

Evidently, the user interface may be divided into a plurality of access numbers or web-sites if so desired.

The solution primarily targets marketers and content providers with the need for specialized, customized and independent brands used by the platform providers. In this case, the platform provider will deliver access and functionality but not the brand.

Hence, mobile users MU, i.e. senders S and mobile recipients MR, may be serviced completely by one cenfral multimedia distribution platform CMDP with respect to management of message delivery, billing and security.

Figs. 9a to 9e illustrate a preferred manner in which to find and select songs from an web server-based WS cenfral multimedia disfribution Platform CMDP. A user may sign up and his user profile be registered in a user profile database UPDB in user profile storage means UPS and access the audio message database AMD in which all the available songs are stored in an audio message storage means AMS.

All songs (typically: fragments of songs) are made available by means of incoming data codes e.g. in the form of SMS commands and corresponding codes in a table, see fig. 9b, or directly via the above-mentioned web-server WS. Furthermore, the member may also select the same songs from different banks TOP 10, ROCK and POP etc. when the member is able to find shortcuts to the songs he wants to send. The member may also select often used songs and build a user-defined bank called customized songs CUSTOM. This bank is particularly advantageous when dealing with users applying SMS-invoked message fransmissions since the user may use a personal and dedicated web-area in which his own banks may be designed (or at least one bank). Hence, the user may prepare the sometimes less user- friendly interface constituted by the SMS commands in such a way that a high degree of customization is obtained. Hence, the user may design his own table in such a way that the table may be intuitively accessed by the user, e.g. by applying memo- technical advantageous codes suiting the user well.

It should be noted that many other banks may be applied according to the invention.

The illustrated bank in fig. 9b represents a static bank in which each song is represented by a unique code ACl-Acxx. This code may be used to select a desired song of if the user is able to remember the selection code.

The three other illusfrated available banks, TOP, ROCK and CUSTOM may be dynamically changing banks comprising groupings of songs from the audio message data bank AMD. These songs may be also accessed by short-codes Tx, Rx, Cx.

The configuration of these banks may be controlled by the platform provider as well as by the user within the scope of the invention.

The configuration of the banks may vary over time.

The above-mentioned types of banks enable the user to apply codes (e.g. SMS) which are easy to remember when selecting a song.

Hence, the basic structure of the audio message database AMD is defined as a part of the distribution platform CDMP. Figs. 9c to 9e illustrate the previously described codes, where e.g. the TOP 10 list comprises some titles S5, S3, S18, Sx2, etc. from the audio message data bank AMD and where e.g. song S5 may be selected by means of e.g. an SMS code comprising the code AC5 or the code Tl referring to the message data bank AMS or the message bank TOP 10, respectively.

It should be noted that the same song (or fragment of song) may be selected by different codes according to the illustrated embodiment.

Fig. 10 illustrates a further embodiment of the invention.

The illusfrated embodiment is an even more detailed description of the embodiment disclosed in fig. 8C, i.e. a cenfral multimedia disfribution platform servicing a number of network providers .

According to the illusfrated embodiment, some of the functions of the cenfral multimedia disfribution platform have been decentralized.

Still, the main functions of the disfribution platform remain centralized.

The illusfrated multimedia disfribution platform comprises a cenfral controller CC.

The cenfral controller CC communicates with a number of local controllers LC via a virtual private network VPN.

Moreover, the cenfral controller CC comprises a web-interface operated by means of a web-server WS. The web-server may be accessed by a number of web-based users WEU via the Internet I.

The illusfrated local controllers communicate with mobile telecommunication networks TNETS via SMS-C's (SMS-C: SMS center). The virtual private secure network VPN connecting the central controller CC and the local controllers LC applies standard TCP/IP. Evidently, other types of communication networks may be applied within the scope of the invention.

According to the illustrated preferred embodiment of the invention, the central controller comprises one server. Evidently, several servers may be utilized with the purpose of establishing one cenfral controller CC within the scope of the invention.

The underlying network support for the above-described information flow is based on the Internet architecture with a centrally located content management service at a central controller CC, the Web-server WS and one or more local controllers LC located at an exchange office. The local controllers LC serve as a relay point for the cenfral controller CC, but run autonomously once enabled and configured. This architecture provides a good decenfralized operating environment, while maintaining the centralized benefits of network management and control. Evidently, the local controllers LC may be updated on a real-time basis.

The architecture requires an inexpensive secure Internet connection, i.e. secure VPN between the cenfral controller CC and the controllers LC, whereas the bulk of the multimedia information moving from the local controllers LC to the mobile recipients, e.g. audio info, moves along a normal ISDN telephone line.

Evidently, other architectures may be implemented within the scope of the invention.

The principal operation of the above- described system may basically be divided into inbound information flowing from web-based users WEU and the mobile users MOB and outbound information flowing from the cenfral distribution platform towards mobile recipients MR. The inbound information may thus be regarded as web-based multimedia message transmission initiated by mobile users WEU and MOB to mobile recipients MR. The outbound information may be regarded as multimedia messages initiated by the inbound information data and being distributed to mobile recipients MR.

The system components necessary for the above-described information traffic will be described in detail below.

Central controller

Fig. 11 illustrates a cenfral controller according to a preferred embodiment of the invention.

The cenfral controller CC is the part of the multimedia disfribution platform in which original database information will be stored. Information may be replicated from the cenfral controller CC to copies located on the local controllers LC. In addition, the cenfral controller CC will be replicating database information to the web-server WS. According to a preferred embodiment, one single cenfral controller CC should be able to serve several local controllers LC and a web-server WS via a virtual private network interface VPNI and a web server interface WSI as illustrated in fig.11.

Evidently, other structures of a central controller CC may be applied within the scope of the invention.

The illusfrated cenfral controller CC comprises

a graphical user interface GUI, network connections to the local controllers LC (VPN), network connection to the web server WS, a management system MAS and different relevant databases CDB, UDB, LDB, etc.

Evidently, other functions and databases may be associated with the central controller if so desired. It should also be noted that parts of the cenfral controller hardware and software may be distributed to local controllers or to a clustered cenfral controller while maintaining overall cenfral control of the central multimedia disfribution platform or at least a part of it.

Graphical user interface GUI of the central controller CC

The graphical user-interface GUI in the cenfral controller CC in fig. 11 will provide an operator with access to the management system as well as to all the data in the different databases. It is the intention of the design of the disfribution platform that all user interactions with the cenfral controller CC should be performed through the management system. However, since the cenfral controller CC is running a standard Windows operating system according to the illusfrated embodiment, there are no restrictions regarding user-interaction with all other parts of the cenfral controller CC as well.

Network connections to the local controllers LC

The central controller comprises interface means established for communication with the local controllers LC via a virtual private network VPN, i.e. a virtual private network interface VPNI.

Basically, the virtual private network interface VPNI should rely on some kind of firewall in order to protect the central controller CC against any intrusion.

A TCP/IP-based virtual private network VPN will be used to physically connect the different servers in the cenfral multimedia distribution platform together. Requirements to this virtual private network VPN are e.g.:

• The VPN should be fast enough to accommodate total database replication from the cenfral controller CC to the local controllers LC within a reasonable amount of time, e.g. less than one hour. • The VPN must be secure. In addition to firewalls, it is expected that all servers on the VPN use "end-to-end" cryptography to protect the information against "tapping" and tampering. A software tool such as PGP (PGP: Pretty good privacy) should be considered. • The VPN should be flexible enough to allow addition of new LC servers at any given geographical position.

• The operator providing the VPN service should guarantee a minimum of availability and data transmission speed. Loss of VPN performance may substantially degrade the performance of the cenfral multimedia distribution platform.

The virtual private network interface VPNI in the cenfral controller CC shall perform the following basic tasks:

• Regularly poll, for example ping, all connected local controllers LC to verify the network connection. If a local controller LC does not respond, an alarm should be sent to the management system MAS.

• When the management system initiates communication with a local controller LC, the virtual private network interface VPNI should encrypt the information and send data to the local controllers LC. • When the Web-server interface WSI requests communication with a local controller LC, the virtual private network interface VPNI should encrypt the information and send data to one of the local controllers LC.

• Data received via the virtual private network VPN should be decrypted and the clear-text message forwarded to the management system MAS or the Web-server.

Network connection to the web server WS

The cenfral controller comprises interface means established for communication with the web-server WS, i.e. a web-server interface WSI. Some basic functionalities of the web-server interface WSI will be outlined below:

It is anticipated that the web-server WS will contain its own databases to store content (i.e. song-ID) and "individualized" user information, for example the user's own hit-list, etc. (see e.g. figs. 9a to 9e). Preferably, none of this information will be stored on the Web-server WS itself, but will be requested by the web-server WS from the databases located in the central controller CC. Apart from this, the Webserver WS only needs to communicate with the cenfral controller CC when an end- user has requested fransmission of a multimedia message. Thus, the primary requirement to the communication between the web-server and the cenfral controller CC is security. One possible implementation could be to use the same virtual private network VPN as the communication with the local controllers LC. An obvious advantage to this solution would be that the Web-server could grant direct access to the local controllers LC in the system. Evidently, if such direct coupling between the web-server and the local controllers LC is established, effective firewalls should be applied in order to prevent any intrusion from the web into the central controller CC or the virtual private network VPN

As stated above, the main purpose of the Web-server interface WSI is to ensure that any communication between the Web-server and the cenfral controller CC is properly secured. Further details regarding the manner in which the CC can exchange secure information with the Web-server will be given in the design specification.

Moreover, firewalls may be supplemented by realtime monitoring of the data packet traffic within the network or some network components.

Management system MAS of the central controller The management system of the cenfral controller in fig. 11 is e.g. adapted to controlling the interaction between the different local controllers LC and the webservers) WS. Moreover, the management system of the cenfral controller CC should control the replication of database content to the local controllers LC. Preferably, the management system of the cenfral controller must be able to handle all associated local controllers LC and web-based servers WS.

The purpose of the management system is to provide easy access to standard tasks such as changing the content databases CDBs or creating new local controllers LC in the distribution platform. Preferably, the management system is specially designed software running on the central controller CC. The software should allow for an operator to perform the following tasks on the central multimedia disfribution platform: • Create or delete a local controller LC.

• Control the local controllers LC in the cenfral multimedia disfribution platform.

• Change the replication settings.

• Change the content of a content database CDB. • Extract statistical information regarding the use of the central multimedia distribution platform.

• Monitor the performance of the local controllers LC.

• Monitor the performance of the Web-server WS.

• Monitor the performance of the VAN.

It should be noted that creation and deletion of databases both on the cenfral controller CC and the local controllers LC require dedicated ERP software which may reside on both the cenfral controller and the local controllers LC.

The management system consists of a common user interface GUI built on top of e.g. three databases:

• A set of content databases CDB 1.. CDBN

• A set of user databases UDB 1.. UDBN • A set of log databases LDB 1.. LDBN

Evidently, other databases may be included in the set of applied databases.

This architecture has been selected in order to keep the underlying structure of the central controller CC and local controllers LC as flexible as possible. Thus, since one single cenfral controller CC may control several national LC servers, it is necessary to create a "database of databases" to keep track of general information such as IP- numbers, languages used, replication settings and transaction-data, etc. As indicated in fig. 11, one philosophy may e.g. be to keep one set of databases, e.g. CDB1, UDB 1 and LDB 1 for each country.

The network management forming part of the management system is responsible for keeping a database of all local controllers LC used in the multimedia distribution platform. If the concept of redundancy and clustering is fully used, this database should keep frack of all clustered local controllers LC and the redundant servers RLC at each site (see details about clustering and redundancy of local controllers in fig. 13). It should be noted that this database is dynamic and can change content while the cenfral multimedia distribution platform is running. Thus, the following data is to be stored for each LC according to one of several applicable embodiments within the scope of the invention:

• Site location name (free-text).

• Site-ID (unique number for each site).

• Telephone operator name {text).

• IP-number (unique number for each local controller LC). • Content database used on this local controller LC.

• Language (on SMS, WAP and speech) used on this local controller LC (this can be a database-name)

• IP-number of redundant local controller LC. List of IP-numbers for local controllers LC clustered together with this local controller LC.

Is the local controller LC operational (i.e. running)?

Replication settings (which database should be replicated and when).

Reboot-schedule (if applicable).

Contact info.

Service agreements.

Service level.

Local service organization.

Software revision.

Software configuration.

Any additional comments (free text).

The operator may easily see and change the contents of the network management database by using the GUI which allows the operator of the management system MAS to list all sites and all local controllers LC etc. By clicking on a local controller LC, the relevant data will be displayed and the user can edit any field. After editing, the management system MAS will verify that the data are consistent and then ask the user to verify the changes.

The management system MAS is also adapted to maintaining and keeping track of one or several content databases CDB. It should be noted that the content databases may vary slightly e.g. from country to country when dealing with hit lists etc. Thus, the management system is necessary in order to frack the use of several content databases CDBs at different local controllers LC. However, it is assumed that most content databases are quite similar with only a few local variations. Thus, the purpose of the content management database is to provide the operator with a simple and user-friendly way of managing the information stored in several content databases. According to a preferred embodiment of the invention, the main tasks may be defined as:

• Creating new content (i.e. song).

• Deleting an existing song. • Editing the information about a song.

In the content database, the following information should be stored about each song:

• Song-ID

• Full artist name

• Artist name used in SMS and WAP • Full name of song

• Name of song used in SMS and WAP

• Date recorded

• Record company

• Author of lyrics and music • Length

• Audio-file (long version)

• Short audio-file (15 second short version) Moreover, the management system MAS may provide the operator with information regarding system status and usage. It is based on top of the log databases created by each local controller LC. Thus, the central controller CC holds a replica of the log database from each local controller LC and the log databases make it possible for the operator to extract statistical data by means of a simple and user-friendly GUI. Examples of data to be presented by the log databases:

• Performance alarms

• Min/max number of transactions per hour during the last day/week/month, sorted per site. • Most popular song-ID during the last day/week/month, sorted per site.

• etc.

Other applicable log parameters and ways of obtaining log-parameters have been indicated with reference to figs. 5A, 5B and 5C.

Local controller

According to the illustrated embodiment of the invention, the local controllers LC are distributed so that each associated telecommunication provider operates one or many local controllers. According to the illustrated embodiment of the invention, each provider operates one local controller LC.

Basically, the local controllers LC deal with both inbound and outbound information in the sense that the local controllers LC may both receive inbound information from system users, mobile users MOB and web-based users WEU, and they may directly initiate a multimedia message fransmission on the basis of the aforementioned inbound information (inbound information may be regarded as a message order from a user to the platform).

Evidently, the local controllers LC may be established more or less centrally with respect to the involved network providers and the multimedia disfribution platform provider. Turning now to the functioning of the illusfrated local controllers LC, the basic idea is that the local controllers LC should deal with receipt of the message orders from the SMS-C or e.g. from the web interface cenfral controller CC.

In order to keep the down-time as low as possible, upgrades of database content and detection of any errors in the information flow should be handled simultaneously with the execution of "normal" central controller CC software. This general statement holds for all servers in the multimedia distribution platform but is particularly important for the local controllers LC. Thus, the implementation of the local controller LC software must take into consideration minimization of down-time and performance of database replication as well as backup to be performed by a server which is actively processing data.

The local controllers are dealt with in detail below with reference to fig. 12A and fig. 12B.

Databases

The databases associated with the cenfral controller may e.g. comprise a content database CDB, a user database UDB and a log database LDB.

The content database CDB may store all relevant information regarding the music- clips available in the distribution platform. This information could for example amount to: • Song-ID

• Artist name

• Title of song

• Duration

• Music and lyrics by • Recording date • Copyright holder (record company)

• Priority level

• Number of hellodies sent with this song during the last day/week/month/year

• Audio-file (long version) • Audio-file (short version for web-users who want to listen to a 15 second clip).

• Category list (i.e. which categories does this song belong to).

• etc.

The content database may be implemented as a fraditional reference relational database. The management system should facilitate further customized relations on top of the reference relational database to users in order to build up customized hitlists etc. as described with reference to fig. 9a to fig. 9e.

A user database UDB may e.g. comprise some of the following information about each user who has used the system. The more information provided by the users, the more information will be stored.

• Phone number

• Name • Address

• E-mail

• Alias-name (to be used in the audio-message)

• Nickname (to be used on the web)

• Hit-list (10 songs) • Multimedia messages received (inbox)

• Multimedia messages sent (outbox)

• etc. Moreover, the user database of the cenfral controller should keep a database containing phone numbers of users not allowed to use the system. This includes both phone numbers of those who may not be "sender" of a multimedia message and numbers of those who cannot be "receiver". The sources of this information could for example be:

• Users who are banned from the cenfral multimedia disfribution platform. This can be requested by a telephone operator due to e.g. misuse of the system or it may be established automatically if certain fransmission conditions are detected.

• End-users who want their phones to be excluded from this service.

Moreover, the central controller comprises a log database LDB. The log database may be applied for monitoring multimedia message traffic on the platform e.g. for billing purposes and to prevent misuse.

A transaction log established for billing purposes should be detailed enough to ensure that the billing information can be verified, should the telecommunication operator request a thorough investigation. Thus, each SMS-message received and sent by each local controller LC should at least be documented by the following data: date, time, phone No., received/sent and content/text.

In addition, each multimedia message sent should be documented by the following data: date and time.

It should moreover be noted that a billing record associated with each user of the cenfral multimedia distribution platform should be kept and maintained by the management system MAS according to a preferred embodiment of the invention. Evidently, billing should advantageously be decentralized in such a way that the users of the system may be billed by their own telecommunication provider and/or Internet provider.

It should, of course, be noted that several other methods of handling the billing records may be applied within the scope of the invention.

Evidently, other data may be applied within the scope of the invention.

Moreover, the system should preferably comprise statistics reflecting user-behavior in a more or less detailed manner. Such statistics may both be applied for business and e.g. security purposes.

Turning now to fig. 12, a further detailed description of the preferred local controller LC according to the invention is shown.

It should be emphasized that the described local controller LC represents only one of several applicable local controllers within the scope of the invention.

As stated above, the local controllers LC are responsible for the conversion of SMS information into audio. Evidently, when applying e.g. GPRS and other types of transmission system, the local controller should act as a local switch converting an inbound message order for transmission of a multimedia message to the identified mobile recipient by means of the applicable transmission system, e.g. in the form of data packets which may be executed as multimedia files at the mobile recipient.

According to the illusfrated preferred embodiment, fransmission of the multimedia message is established by means of a simple audio message from the local controller via a fraditional speech channel. The illusfrated local controller LC comprises a number of interfaces connected to a local controller main program LCMP by buffers Ql to Q8.

The buffers Ql, Q2, Q3, Q4, Q5, Q6, Q7 and Q8 are utilized for distributing the data streams between the local controller LC interfaces and the local controller main program LCMP.

Basically, the illusfrated local controller comprises an SMS-interface SMSI adapted to handling inbound SMS message disfribution orders and outbound SMS.

The SMS interface SMSI is responsible for the communication to and from the SMS- C. The SMS-driver should have one part receiving SMS-messages, Rx, and another part transmitting SMS-messages, Tx. The basic functionality of these processes according to one embodiment of the invention is outlined below:

The following list outlines the basic functionality of the Rx-process in the driver of the SMS-interface SMSI:

1. Poll the "SMS-port" for any incoming messages. If a new SMS-message has been received, continue with steps 2 -7 below. If not, sleep 100 ms and repeat this step.

2. Acknowledge receipt of the SMS to the SMS-C.

3. Check if the phone number of the sender can be extracted. If so, continue with step 4 below. If not, continue with error-handling.

4. Convert the SMS-message into a format understood by the main-program, e.g. the message format described in figs. 4A-4C.

5. Write the SMS-message in a buffer "Ql". The use of buffers between the different tasks is important in order to ensure that the local controller LC can handle short bursts, e.g. bursts of 10 seconds, of large network traffic. If the SMS-driver cannot write to the buffer "Ql", then continue with error- handling. 6. Check if any "lost" SMS-messages are to be dealt with. "Lost SMS- messages" mean messages received, but placed somewhere else in the system than in buffer "Ql" due to error-handling. If any such "lost" messages are found, then process the first according to step 5 above. 7. Go to step 1.

The following list outlines the basic functionality of the Tx-process in the driver of the SMS-interface SMSI:

1. Poll the buffer "Q2" for any incoming messages. If a new SMS-message to be sent is found in buffer "Q2", then continue with steps 2 -6 below. If not, sleep 100 ms and repeat this step.

2. Check if the phone number of the receiver can be extracted. If so, continue with item 3 below. If not, continue with error-handling.

3. Convert the information from the main-program into an "SMS-format". 4. Send the SMS-message to SMS-C. If the SMS-C does not answer, i.e. acknowledge receipt of the SMS, then continue with error-handling.

5. Check if any "pending" SMS-messages are to be dealt with. "Pending SMS- messages" mean messages to be sent but not received by the SMS-C. If any such "pending" messages are found, then process the first according to step 4 above.

6. Go to step 1.

Moreover, the illusfrated local controller comprises a WAP-interface WAPI adapted to handling inbound message disfribution orders established according to the WAP protocol.

Moreover, the illusfrated local controller comprises a local controller web interface LCWT adapted to handling inbound message distribution orders established by a web-user WEU and pipelined to the local controller LC via the central controller CC and the associated firewalls. Evidently, other interfaces may be applied within the scope of the invention, such as direct web interfaces (not shown) insofar efficient firewalls are applied.

The SMS information or WAP information is handed over to the local controllers' main program LCMP from the SMS-interface SMSI and the WAP-interface WAPI.

Moreover, the local controller LC comprises an interface to one or several telecommunication networks TNET, here an ISDN interface, ISDNI. Typically, the local controller LC should address one telecommunication network.

The phone line driver ISDNI is responsible for making the actual phone call and for delivering the multimedia message MSG to the end-user, the mobile recipient. In the following, a few conditions must be fulfilled:

• The LC is equipped with hardware capable of handling several parallel on- going phone calls. Preferably, each LC is equipped with "30 x ISDN" access and has an El (i.e. 2 Mbit/s) connection to the telephone exchange (not shown). This would bring the total number of parallel phone calls up to 30.

• The ISDN-driver software can have as many parallel instances active as there are phone line connections. If these conditions are fulfilled, the following functional requirements apply to each of the (max. 30) parallel processes in the ISDN-driver. However, prior to going into the details for the ISDN-driver functionality, let us first consider the information to be stored in the buffers used by the ISDN-driver.

The input-buffers used by the ISDN-driver should store the following information:

• Multimedia message-ID generated by the main-program.

• The time when the item should be processed.

• Phone number to be dialed.

• Audio-file 1 (optional) • Audio-file 2 (optional)

• Audio file 3 (optional)

• Number of performed re-transmissions (should be set to zero when the item is placed in buffer "Q5").

The output-buffer "Q6" should contain the following information:

• Multimedia message-ID.

• Status (success or failure).

Evidently, several other configurations of a telecommunication transmission interface ISDNI may be applied within the scope of the invention.

A more detailed illustration of the message delivery may be found in figs. 5A to fig. 5C.

Finally, the illusfrated local controller LC comprises a number of databases, here: a content database CDB, a user database UDB and a log database LDB.

It should be noted that other databases may be applied within the scope of the invention.

The databases typically represent an instance of a master database stored at the central controller CC. The instance may e.g. represent a set of three databases used in a specific country N supported by the current local controller LC.

The update of the databases CDB, UDB and LDB is performed under the confrol of the cenfral controller CC, i.e. managed by the management system MAS of the cenfral controller as previously described. A performance monitoring process should take place regularly, for example every minute, and check the network connection and hardware status of the local controller LC. If any malfunction is detected, it should report the error to the central controller CC via the TCP/IP ,i.e. the VPN connection. Furthermore, the execution status of the various software modules in the local controller LC should also be scanned at regular intervals. Examples of errors that can be detected by the performance monitoring process in this respect are:

• Loss of connection to SMS-C.

• Loss of phone line connection. • Malfunction of one or more phone lines.

• Loss of connection to WAP or the web-based user interface WEU.

• Hardware error in any network connection.

• Hardware error in hard disk or other PC devices.

• Software problems in any of the local controller LC function modules. • etc.

It should be noted that malfunctions in the TCP/IP network connection will prohibit the error from reaching the central controller CC. However, alternative ways of informing the central controller CC about a malfunction in the local controller LC may be considered. For example by means of a phone line and a modem.

A performance monitoring process should also take place regularly, for example every 10 seconds, and monitor the number of pending items in the input buffers "Ql" - "Q8" on the local controller in fig. 12. If the number of pending items in any of the queues exceeds some predefined limit, an error should be logged and reported to the cenfral controller CC. This error should clarify which queue has been "overloaded" and the date and time for detecting the error. Clustering and redundancy

Fig. 13 illustrates a further embodiment of the invention according to which a number of local controllers LC has been clustered. To improve the system capacity, it is possible to cluster several local controllers LC together. For example, if the system capacity is to be increased to handle in excess of 3000 messages/per hour, the local controller LC is placed in "clustermode" with two or more co-located local controllers LC, each providing an estimated maximum of 3000 messages per hour. Redundancy can be used as a means of improving the access time of the multimedia distribution platform. By redundancy is meant a network configuration in which one operating local controller LC is doubled with a complete spare server. The switching between two local controllers LC can be made either manually or controlled by the central controller CC. When an error is detected in an operating local controller LC, the data flow is directed towards the redundant local controller LC which is configured just as the operating local controller LC.

The concept of clustering and redundancy is illusfrated in fig. 13. Here, two local controllers LCI and LC2 are running in clustermode. That is, the incoming SMS- messages are distributed to one of the local controllers LC by means of a load distributor LOADD to even the work-load for each local controller LC. In its simplest configuration, the load distributor LOADD takes turns distributing one SMS-message to each of the local controllers LC at a time. However, a more intelligent approach may be adopted by means of which the "load distributor" is aware of the approximate processing time for each type of SMS-message and can thus distribute the load even better between the two local controllers LCI and LC2. Assuming that the number of incoming SMS-messages is substantially higher than the performance of one single local controller LC, the system would stop to function if either LCI or LC2 experienced malfunction due to e.g. software or hardware errors. Thus, to secure the system against "single point of failure", one or several redundant servers RLC can be installed. When a malfunction occurs, the load distributor LOADD is notified from the central controller CC and it immediately stops sending SMS-messages to the faulty local controller LC. Instead, these messages are sent to the redundant local controller RLC which has a true copy of the configuration of the active local controller LC. Thus, it can start processing the SMS- messages directly as soon as it receives them. The end-user, i.e. the sender of the SMS-messages, will never notice the change of server hardware and the multimedia distribution platform system will continue to function without any noticeable performance degradation while the error is repaired.

Basically, according to a further embodiment of the invention, other system components may be clustered or applied with redundancy, even the central controller CC.

Clustering and redundancy may also be applied with respect to outbound fransmission capacity from e.g. the local controllers, e.g. due to a limited number of speech channels.

According to the invention it should nevertheless be noted that the disfribution platform advantageously facilitates handling of incoming message distribution orders from the users of the systems. They may be more or less buffered in order to even out the message distributions per time unit in order to fit both the performance of the central multimedia disfribution platform and the available fransmission capacity from the cenfral distribution platform to the mobile recipients, i.e. the bandwidth offered by the mobile telecommunication providers. Technical specification

The central multimedia disfribution platform may be implemented on several different technical hardware setups within the scope of the invention, depending on system requirements and the available hardware elements and interfaces.

All hardware in the preferred system is based on standard PC architecture. Scalability is achieved through clustering of devices as opposed to other architectures where scaling is achieved by utilizing larger devices. Some technical hardware and software specifications for one of several embodiments within the scope of the invention are outlined below:

Cenfral controller (CC):

CPU 1.1 GHz Pentium 4

Memory 1 GB

Storage 80 GB RAID-5

Mount 19" rack

Power Dual PS 220V/350W

Network 3COM 10/100 RJ-45

OS Win2000/AS

Database AM 3.1/EE

(SQL 2000 version)

Local controller (LC):

CPU 900 MHz Pentium III

Memory 1 GB

Storage 80 GB RAID-5

Mount 19" rack

Power Dual PS 220V/350W

Telecom: Dialogic ISDN 30

(or El -interface)

Network 3COM 10/100 RJ-45 OS Win2000/Pro

Database AM 3.1

(SQL 2000 version)

Web-server

CPU 900 MHz Pentium III

Memory 1 GB

Storage 80 GB RAID-5

Mount 19" rack

Power Dual PS 220V/350W

Network 3COM 10/100 RJ-45

OS Win2000/Pro

Again, it should be emphasized that the above-described hardware only represents one of several applicable hardware setups within the scope of the invention.

Claims

Patent Claims

1. Method of disfributing multimedia messages from a sender (S; MU, WEU) to a mobile recipient (MR) via at least one mobile communication network (TNET) and via at least one cenfral multimedia disfribution platform (CMDP; CC, LC)

said method comprising the steps of

establishing the message content (MC)

identifying a mobile recipient (MR)

said at least one central multimedia distribution platform (CMDP; CC, LC) transmitting the message content (MC) to the identified mobile recipient (MR).

2. Method of disfributing multimedia messages according to claim 1, whereby the message content is established by communication of message-defining codes (MDC) from the sender (MU, WEU) to the at least one central multimedia distribution platform (CMDP; LC, CC).

3. Method of distributing multimedia messages according to claim 1 or 2, whereby the message-defining codes address the multimedia message content (MC) stored at said at least one cenfral multimedia disfribution platform (CMDP; CC, LC).

4. Method of disfributing multimedia messages according to any of the claims 1 to 3, whereby the message-defining codes comprise a command structure.

5. Method of disfributing multimedia messages according to any of the claims 1 to 4, whereby the message-defining codes comprise a command structure supported by an interactive user interface (WS).

6. Method of disfributing multimedia messages according to any of the claims 1 to 5, whereby the interactive user interface (WS) comprises a message builder (Fig. 5A).

7. Method of distributing multimedia messages according to any of the claims 1 to 6, whereby the message is transmitted to the identified mobile recipient (MR) according to fransmission conditions (TRC).

8. Method of disfributing multimedia messages according to any of the claims 1 to 7, whereby the central multimedia disfribution platform (CMDP) is associated with a user area domain (US AD) holding individual information (II) related to users (MU, WEU) and whereby at least part of the individual information associated with the individual user may be accessed by the user.

9. Method of disfributing multimedia messages according to any of the claims 1 to 8, whereby said user area domain comprises a message builder (MSGB).

10. Method of disfributing multimedia messages according to any of the claims 1 to

9, whereby the message content is established by means of a multimedia message database (AMD) stored in multimedia message storage means (AMS).

11. Method of disfributing multimedia messages according to any of the claims 1 to 10, whereby a speech message is added to the message content (MC), said speech message being established by means of a text-to-speech generator associated with the cenfral multimedia disfribution platform (CMDP).

12. Method of disfributing multimedia messages according to any of the claims 1 to

11, whereby said cenfral multimedia distribution platform (CMDP) comprises a message transmission monitoring system and the message transmission monitoring system involves at least one measuring step (205, 209, 213, 217).

13. Method of disfributing multimedia messages according to any of the claims 1 to

12, whereby said measuring step measures fransmission faults.

14. Method of disfributing multimedia messages according to any of the claims 1 to 13, whereby said cenfral message disfribution platform comprises filters determining different multimedia transmission conditions.

15. Method of disfributing multimedia messages according to any of the claims 1 to 14, whereby said filters determine certain predefined conditions which terminate or block certain predefined multimedia transmissions when fulfilled.

16. Method of distributing multimedia messages according to any of the claims 1 to 15, whereby said filters are established by the central multimedia distribution platform.

17. Method of distributing multimedia messages according to any of the claims 1 to 16, whereby said filters are established by subscribers of the central multimedia distribution platform.

18. Method of disfributing multimedia messages according to any of the claims 1 to 17, whereby said filters are established by subscribers of the telecommunication network provider (NP).

19. Method of disfributing multimedia messages according to any of the claims 1 to 18, whereby said filters are adapted to preventing misuse of the central multimedia platform.

20. Method of disfributing multimedia messages according to any of the claims 1 to

19, whereby the establishment of a multimedia message (MSG) is associated with identification of the sender.

21. Method of disfributing multimedia messages according to any of the claims 1 to 20, whereby the established multimedia message (MSG) is associated with an advertising multimedia message, such as a audio message, picture message, text- message or movie message.

22. Method of disfributing multimedia messages according to any of the claims 9 to 21, whereby said message builder (MSGB) comprises a search tool facilitating a search of the multimedia message data bank by the user (WEU, MU) by means of a predetermined search syntax.

23. Method of disfributing multimedia messages according to any of the claims 1 to 22, whereby the time within which said message (MSG) must be transmitted to said mobile recipient (MR) is established by the user (WEU, MU).

24. Method of distributing multimedia messages according to any of the claims 1 to 23, whereby said speech message added to the message content (MC) is established by means of audio recording means.

25. Method of disfributing multimedia messages according to any of the claims 1 to 24, whereby a multimedia message is added to the message content (MC), said multimedia message being established by means of multimedia generating programs.

26. Method of disfributing multimedia messages according to any of the claims 1 to 25, whereby the telecommunication network (TNET) comprises a GSM network.

27. Method of disfributing multimedia messages according to any of the claims 1 to 25, whereby the telecommunication network (TNET) comprises a UMTS network.

28. Method of disfributing multimedia messages according to any of the claims 1 to 27, whereby the message content comprises frigger codes which may be executed at the mobile recipient (MR) if associated with signal processing routines and/or data stored at said mobile recipient (MR).

29. Method of managing delivery of messages (MSG) from a sender to a mobile recipient of a telecommunication network, said method of comprising the steps of

establishing a message (MSG) to an identified mobile recipient (MR)

performing a delivery check (216) determining whether the established message (MSG) can be delivered to the identified recipient or not,

determining whether the message (MSG) is delivered to the identified mobile recipient (MR).

30. Method of managing delivery of messages according to claim 29, whereby said established message (MSG) is transmitted to the identified mobile recipient (MR) via at least one cenfral multimedia distribution platform (CMDP).

31. Method of managing delivery of messages according to claim 29 or 30, whereby said delivery check (216) is performed by establishing transmission to the identified mobile recipient (MR) and subsequently determining whether the fransmission is received by the mobile recipient (MR) or not.

32. Method of managing delivery of messages according to any of the claims 29 to

31, whereby said delivery check (216) is performed as an initial test determining whether the identified mobile recipient is available or not prior to fransmission to the identified mobile recipient (MR).

33 Method of managing delivery of messages according to any of the claims 29 to

32, whereby the availability of the mobile recipient is determined by checking the relevant registers associated with the identified recipient of the mobile telecommunication network.

34. Method of managing delivery of messages according to any of the claims 29 to 33, whereby said relevant registers comprise the home location register (HLR) of a mobile telecommunication network.

35. Method of managing delivery of messages according to any of the claims 29 to 34, whereby said delivery check (216) moreover comprises an acceptance check (208) determining whether the identified recipient accepts receipt of the established message (MSG) or not.

36. Method of managing delivery of messages according to any of the claims 29 to 35, whereby said fransmission of the established message comprises a call to the identified mobile recipient (MR).

37. Method of managing delivery of messages according to any of the claims 29 to 36, whereby said transmission of the established message comprises fransmission of the message (MSG) defined by the packet-based data to the identified mobile recipient (MR).

38. Method of managing delivery of messages according to any of the claims 29 to 37, whereby said packet-based data are executed as a multi-media message (MMSG) at the mobile recipient (MR).

39. Method of managing delivery of messages according to any of the claims 29 to 38, whereby said multi-media message (MSG) executed at the mobile recipient (MR) comprises audio signals.

40. Method of managing delivery of messages according to any of the claims 29 to 39, whereby said multi-media message (MSG) executed at the mobile recipient (MR) comprises image signals.

41. Method of managing delivery of messages according to any of the claims 29 to 40, whereby said established message (MSG) is stored in message storing means if the message is not delivered to the identified recipient (MR).

42. Method of managing delivery of messages according to any of the claims 29 to 41, whereby said identified mobile recipient (MR) is notified if a message (MSG) is not delivered and whereby the message (MSG) may subsequently be retrieved by the mobile recipient (MR) by accessing said message storing means (MSG).

43. Method of managing delivery of messages according to any of the claims 29 to 42, whereby said message (MSG) stored in said message storing means (MSM) is erased from said message storing means (MSM) if certain predefined storing conditions are fulfilled.

44. Method of managing delivery of messages according to any of the claims 29 to 43, whereby a predefined storing condition may be that the message has not been retrieved by the mobile recipient within a certain time limit.

45. Method of managing delivery of messages according to any of the claims 29 to 44, whereby the sender is notified if the message is not delivered to the identified mobile recipient (MR).

46. Method of managing delivery of messages according to any of the claims 29 to 45, whereby the sender is notified if the message is delivered to the identified mobile recipient (MR).

47. Method of managing delivery of messages according to any of the claims 29 to 46, whereby the sender's billing record is charged if the message is delivered to the identified mobile recipient (MR).

48. Method of managing delivery of messages according to any of the claims 29 to

47, whereby said cenfral multimedia disfribution platform CMDP comprises at least one cenfral controller (CC) and at least one local controller (LC).

49. Method of managing delivery of messages according to any of the claims 29 to

48, whereby the multimedia message (MSG) is established as a multimedia rendering at the mobile recipient on the basis of trigger codes which may be executed at the mobile recipient (MR) if associated with signal processing routines and/or data stored at said mobile recipient (MR).

50. Method of managing delivery of messages according to any of the claims 29 to 49, whereby the sender is charged according to the method of claims 51 to 60.

51. Method of disfributing multimedia messages from a sender (MU, WEU; S) to a mobile recipient (MR) via at least one mobile telecommunication network (TNET)

said method comprising the steps of

establishing the message content (MC)

identifying a mobile recipient (MR)

transmitting the message content (MC) to the identified mobile recipient (MR)

charging the sender's billing record.

52. Method of disfributing multimedia messages from a sender (S; WEU, MU) to a mobile recipient (MR) via at least one mobile telecommunication network (TNET)

said method comprising the steps of

establishing the message content (MC)

identifying a mobile recipient (MR)

transmitting the message content (MC) to the identified mobile recipient (MR) charging the sender's billing record if the message is delivered to the identified mobile recipient (MR).

53. Method of disfributing multimedia messages according to claim 51 or 52, said message content comprising multi-media elements such as audio messages, picture- defining data, scents, etc.

54. Method of disfributing multimedia messages according to any of the claims 51 to 53, whereby said messages (MSG) comprise emotional message content, preferably in the form of a sequence of a song.

55. Method of disfributing multimedia messages according to any of the claims 51 to 54 whereby charging a billing record implies that the sender's billing record is updated according to a predefined billing schedule.

56. Method of disfributing multimedia messages according to any of the claims 51 to 55, whereby the predefined billing schedule defines an update of an account associated with the sender.

57. Method of disfributing multimedia messages according to any of the claims 51 to 56, whereby the predefined billing schedule defines each transmission being charged individually.

58. Method of disfributing multimedia messages according to any of the claims 51 to 57, whereby the account associated with the sender is controlled and updated by the sender's network provider (NP).

59. Method of disfributing multimedia messages according to any of the claims 51 to 58, whereby billing information is fransferred from the central multimedia distribution platform provider to the relevant network provider (NP).

60. Method of disfributing multimedia messages according to any of the claims 51 to 59, whereby the account associated with the sender is controlled by the cenfral multimedia distribution platform of the sender (S; WEU; MU).

61. Cenfral multimedia disfribution platform comprising signal processing means, said signal processing means operating according to any of the claims 1 to 60.

62. Data structure which performs the method according to any of the claims 1-61 when implemented on a hardware platform.