Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
  • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
  • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
  • H04W4/185—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals by embedding added-value information into content, e.g. geo-tagging

Definitions

• the present invention relates to a method of distributing multimedia messages from a sender to a mobile recipient according to claim 1.
• the invention addresses distribution of different types of customized multimedia messages to mobile subscribers.
• 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 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.
• 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,
• CMDP central multimedia distribution platform
• 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.
• 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.
• 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 offers several advantages such as user-friendliness and can be used by a person with minimal knowledge of SMS and mobile phones.
• the system may be established in a secure way, thereby preventing hacking and misuse.
• the invention facilitates a reliable distribution system which may be ideally operated 24 hours a day for several months and with minimal down-time.
• 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.
• 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.
• MDC message-defining codes
• CMDP central multimedia distribution platform
• 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.
• 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.
• 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.
• GSM evaluation of SMS such as EMS and MMS.
• EMS and MMS GSM evaluation of SMS
• 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.
• 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.
• the main body of a multimedia message should be composed by bricks stored in the at least one central multimedia distribution platform (CMDP).
• CMDP central multimedia distribution platform
• the message-defining codes comprise a command structure (CS), a further advantageous embodiment of the invention has been obtained.
• 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.
• 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.
• 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.
• 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.
• 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.
• the interactive user interface comprises a message builder (MSGB), a further advantageous embodiment of the invention has been obtained.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• he may be provided with an additional set of commands which may be customized.
• 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.
• his own hit lists e.g. a TOP 10
• H7 any other short key determined by the user.
• said user area domain comprises a message builder (MSGB), a further advantageous embodiment of the invention has been obtained.
• MSGB message builder
• 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.
• 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.
• a message builder 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.
• 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.
• AMD multimedia message database
• AMS multimedia message storage means
• 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.
• CMDP central multimedia distribution platform
• 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.
• a sender may establish his own audio-file, e.g. a WAN-file instead of e.g. applying text-to-speech.
• 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.
• said central multimedia distribution platform 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.
• said central message distribution platform comprises filters determining different multimedia transmission conditions, a further advantageous embodiment of the invention has been obtained.
• 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.
• 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.
• 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.
• a sender may establish his own audio-file, e.g. a WAN-file instead of applying text-to-speech.
• his own audio-file e.g. a WAN-file instead of applying text-to-speech.
• the sender may create e.g. speech or song and attach this speech or song message to the message content.
• a multimedia message is added to the message content (MC), said multimedia message may be established by means of multimedia message generating programs.
• 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.
• the telecommunication network comprises a GSM network
• a further advantageous embodiment of the invention has been obtained.
• the telecommunication network comprises a UMTS network
• TNET telecommunication network
• 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.
• a user-installed program e.g. a virtual machine
• the program requested by the trigger or if it is an applet, execute the applet at the mobile recipient MR.
• triggers e.g. applets
• transmission of such triggers may be initiated by a variety of other message defining codes than the SMS suggested above.
• 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.
• signal processing routines and/or data stored at the mobile recipient may advantageously be updated from time to time if suitable.
• 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
• DCHK delivery check
• DCHK delivery check
• DCHK delivery check
• 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.
• said relevant registers comprise the home location register (HLR) of a mobile telecommunication network, a further advantageous embodiment of the invention has been obtained.
• said delivery check moreover comprises an acceptance check (ACHK) determining whether the identified recipient accepts receipt of the established message (MSG) or not.
• said transmission of the established message comprises a call to the identified mobile recipient (MR)
• MR mobile recipient
• 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.
• said multi-media message (MMSG) executed at the mobile recipient (MR) comprises audio signals
• MMSG multi-media message executed at the mobile recipient (MR)
• said multi-media message (MMSG) executed at the mobile recipient (MR) comprises image signals
• MMSG multi-media message executed at the mobile recipient (MR)
• Image signals may both be video and single pictures eventually supported by text or audio signals.
• said established message MSG
• MSM message storing means
• 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.
• a predefined storing condition STCO
• STCO predefined storing condition
• 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.
• 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 ,
• 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,
• the sender should only be charged if the identified mobile recipient (MR) receives the message, and even more preferably, if he accepts it.
• 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.
• said message content comprises multi-media elements such as audio messages, picture-defining data, scents, etc.
• multi-media elements such as audio messages, picture-defining data, scents, etc.
• multi-media messages should preferably contain at least audio messages. Nevertheless, pictures, video, etc. may be applied if suitable.
• 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.
• this type of addressing relies heavily on pre-established social contact between the sender and the recipient.
• 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.
• the predefined billing schedule defines an update of an account associated with the sender
• 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.
• the user may be offered different bonuses or subscriber conditions, e.g. with respect to consumption.
• 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.
• billing information may be distributed to the relevant network providers .
• 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.
• 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.
• 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.
• 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.
• the device comprises a display DIS for monitoring call and message information and a keyboard MKBD e.g. for inputting phone numbers or sending
• a user may e.g. use the illustrated device MOB when preparing a multimedia message to a recipient.
• 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.
• the necessary transmission bandwidth may be reduced significantly if the mobile device offers such facility.
• 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.
• 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).
• CMDP cenfral multimedia distribution platform
• 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.
• 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.
• 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.
• 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.
• 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.
• a user must sign up before being able to send an audio message to e.g. a friend via the platform.
• the user 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.
• CMDP Central multimedia distribution platform
• 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.
• 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.
• 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.
• 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.
• the below-described message format is applied for fransmission in a traditional GSM network by means of SMS messages.
• 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.
• a format may be:
• the maximum length of the SMS is a standard of 160 characters.
• Such message services may e.g. include new SMS standards such as EMS and MMS covered by the GSM network.
• new SMS standards such as EMS and MMS covered by the GSM network.
• 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 distribution platform access number e.g. 555
• the available commands may e.g. be the set of message defining commands MDC suggested below.
• 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.
• 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, Man, 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.”
• 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.
• the relevant audio file 3 is then illusfrated in fig. 4C.
• audio-file 3 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.
• pictures, video or other emotional effects may be transmitted to the user.
• 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.
• 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.
• the invention offers several ways of obtaining the desired result.
• 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.
• the message builder 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.
• 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.
• 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.
• the message builder may be interfaced e.g. by user hardware as described in fig. 1 or 2.
• 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.
• process step 402 it is checked whether the sender has predetermined certain delivery conditions e.g. established in a user profile.
• 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.
• step 404 the process continues with step 404 by determining whether an interactive interface is used with the present message establishment.
• 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.
• the sender identifies the intended mobile recipient, e.g. by inputting a telephone number or a certain recipient ID number.
• step 407 in which the determination of the message content is initiated.
• step 408 the sender may access a message bank associated with the cenfral message delivery platform.
• 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.
• 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.
• 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.
• step 412 message fransmission is initiated.
• step 413 which is delivery, represents a jump to the next sub-routine, delivery management. This delivery management is described in fig. 5B.
• 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.
• 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.
• 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.
• 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.
• 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.
• Step 200 represents the process illusfrated by the previously described builder flow chart.
• 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.
• routine step 201 may be performed at other stages of the message establishment and delivery process within the scope of the invention.
• step 202 a check is performed to determine whether a user profile is established on the mobile recipient.
• 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.
• 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.
• step 204 the delivery process is terminated with step 204.
• step 205 If no constraint on the intended message delivery is determined, the process proceeds with step 205.
• step 205 reachability is determined.
• 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.
• the platform will then retry three times at 30-minute intervals to deliver the message to the identified recipient.
• 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.
• 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.
• an SMS is submitted to the sender with step 206 and the delivery process is terminated with step 207.
• step 207 delivery is terminated directly with step 207 with no notification to the sender.
• 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.
• step 208 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.
• step 216 delivery of the message is initiated with step 216.
• step 221 The billing procedure initiated with step 221 is described in detail in fig. 5C.
• step 204 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.
• 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.
• 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.
• 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.
• an SMS is submitted to the sender with step 210 and the delivery process is terminated with step 211.
• step 211 delivery is terminated directly with step 211 with no notification to the sender.
• step 212 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.
• 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.
• 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.
• 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.
• the update step also comprises a check of the relevant filter determining whether the sender has required feed-back if the message is undelivered.
• step 215 delivery is terminated directly with step 215 with no notification to the sender.
• step 216 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.
• 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.
• 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.
• 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 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.
• step 219 delivery is terminated directly with step 219 with no notification to the sender.
• a billing procedure is initiated with step 413 representing the transition to the next subroutine described in fig. 5C.
• step 300 represents the transition to the aforementioned sub-routine.
• step 301 the relevant account is loaded.
• 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.
• 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.
• step 304 the process is terminated with step 304.
• 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.
• 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.
• 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.
• 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.
• the call server 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.
• 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.
• introduction sequence INT e.g. a jingle
• audio message informing the recipient of the sender's identity.
• 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.
• 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.
• an advertisement ADV may optionally follow.
• Fig. 7 illustrates the basic steps of the delivery process according to an embodiment of the invention.
• 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.
• a user may access a cenfral multimedia distribution Platform CMDP according to the invention.
• CMDP cenfral multimedia distribution Platform
• 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.
• 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.
• 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.
• a web interface can be accessed either through the operator or message portals with potential full service transparency (not shown).
• 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.
• 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.
• the central distribution platform is integrated in the operator network.
• 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.
• a web interface can be accessed either through the operator or message portals with potential full service transparency (not shown).
• the illustrated platform may be accessed by the users by means of other suitable telecommunication devices, e.g. PDA's, etc.
• the above-described system offers the advantage of several mobile network providers being serviced by the same platform.
• the administrative part of the operation of the message disfribution may be carried out by one cenfral platform.
• 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.
• 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.
• 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.
• mobile users MU i.e. senders S and mobile recipients MR
• 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 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.
• 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).
• 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.
• 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.
• 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 the banks may vary over time.
• 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.
• the TOP 10 list comprises some titles S5, S3, S18, Sx2, etc. from the audio message data bank AMD
• 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.
• 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 .
• cenfral multimedia disfribution platform According to the illusfrated embodiment, some of the functions of the cenfral multimedia disfribution platform have been decentralized.
• 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.
• 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).
• SMS-C SMS center
• the virtual private secure network VPN connecting the central controller CC and the local controllers LC applies standard TCP/IP.
• other types of communication networks may be applied within the scope of the invention.
• the central controller comprises one server.
• 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.
• 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.
• 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.
• 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.
• the illusfrated cenfral controller CC comprises
• a graphical user interface GUI 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.
• 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.
• 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.
• 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.
• a virtual private network VPN i.e. a virtual private network interface VPNI.
• VPNI virtual private network interface
• 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:
• the virtual private network interface VPNI should encrypt the information and send data to the local controllers LC.
• the virtual private network interface VPNI should encrypt the information and send data to one of the local controllers LC.
• 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:
• 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).
• content i.e. song-ID
• individualized user information for example the user's own hit-list, etc.
• 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.
• the Webserver WS only needs to communicate with the cenfral controller CC when an end- user has requested fransmission of a multimedia message.
• 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.
• 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
• 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.
• 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.
• 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.
• the management system consists of a common user interface GUI built on top of e.g. three 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.
• 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.
• 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-ID unique number for each site.
• IP-number (unique number for each local controller LC). • Content database used on this local controller LC.
• IP-number of redundant local controller LC • IP-number of redundant local controller LC. List of IP-numbers for local controllers LC clustered together with this local controller LC.
• 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.
• the content databases may vary slightly e.g. from country to country when dealing with hit lists etc.
• the management system is necessary in order to frack the use of several content databases CDBs at different local controllers LC.
• 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.
• the main tasks may be defined as:
• 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.
• 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:
• 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.
• 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).
• the local controllers LC may be established more or less centrally with respect to the involved network providers and the multimedia disfribution platform provider.
• 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.
• the local controllers are dealt with in detail below with reference to fig. 12A and fig. 12B.
• 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
• Audio-file Long version
• Audio-file short version for web-users who want to listen to a 15 second clip
• 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.
• 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:
• 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.
• 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.
• each multimedia message sent should be documented by the following data: date and time.
• 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.
• 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.
• 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.
• the local controllers LC are responsible for the conversion of SMS information into audio.
• 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.
• 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.
• 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.
• Rx receiving SMS-messages
• Tx transmitting SMS-messages
• step 4 Check if the phone number of the sender can be extracted. If so, continue with step 4 below. If not, continue with error-handling.
• SMS-message into a format understood by the main-program, e.g. the message format described in figs. 4A-4C.
• 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.
• "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.
• SMS-message to SMS-C. If the SMS-C does not answer, i.e. acknowledge receipt of the SMS, then continue with error-handling.
• the illusfrated local controller comprises a WAP-interface WAPI adapted to handling inbound message disfribution orders established according to the WAP protocol.
• 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.
• LCWT local controller web interface
• 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.
• the local controller LC comprises an interface to one or several telecommunication networks TNET, here an ISDN interface, ISDNI.
• TNET here an ISDN interface
• ISDNI ISDN interface
• 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.
• 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:
• Audio-file 1 (optional) • Audio-file 2 (optional)
• the output-buffer "Q6" should contain the following information:
• the illusfrated local controller LC comprises a number of databases, here: a content database CDB, a user database UDB and a log database LDB.
• 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.
• 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:
• 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.
• 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.
• 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.
• the load distributor LOADD takes turns distributing one SMS-message to each of the local controllers LC at a time.
• 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.
• the system would stop to function if either LCI or LC2 experienced malfunction due to e.g. software or hardware errors.
• one or several redundant servers RLC can be installed.
• 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.
• the redundant local controller RLC which has a true copy of the configuration of the active local controller LC.
• 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.
• 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.
• 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Multimedia (AREA)
• Mobile Radio Communication Systems (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=8160424

Family Applications (1)

Country Status (2)

Families Citing this family (5)

Citations (1)

Family Cites Families (3)

• 2001
  • 2001-07-09 EP EP01951446A patent/EP1378134A1/de not_active Withdrawn
  • 2001-07-09 WO PCT/DK2001/000478 patent/WO2002082837A1/en not_active Application Discontinuation

Patent Citations (1)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events