Abstract:
The invention relates to a method and system for inserting at least one multimedia message multiple element into a multimedia message. The method comprises the following steps transmitting at least one multimedia message multiple from a network element to a mobile station, transmitting one first multimedia message from the network element to the mobile station, and inserting the multimedia message multiple element into the first multimedia message. Preferably, insertion occurs in the mobile station, and the multimedia message multiple element is only transmitted once by the network element to the mobile station and is inserted into a plurality of multimedia messages.

Description:
CLAIM FOR PRIORITY  
       [0001]     This application claims the benefit of priority to German Application No. 103 03 958.9 which was filed in the German language on Jan. 31, 2003, the contents of which are hereby incorporated by reference.  
       TECHNICAL FIELD OF THE INVENTION  
       [0002]     The present invention relates to a method and a system for inserting at least one multimedia message multiple element into a multimedia message.  
       BACKGROUND OF THE INVENTION  
       [0003]     In addition to voice telephony, the GSM (Global System for Mobile Communications) mobile radiocommunication system offers the possibility of sending or receiving, as applicable, short text messages of up to 160 characters in length. This message service is known as SMS (Short Message Service). For the next generation of mobile radiocommunication systems (2.5G and 3G), such as for example UMTS (Universal Mobile Telecommunications System), a variant of a mobile messaging service is provided with multimedia capability, the so-called MMS (Multimedia Messaging Service). This MMS service is described in the technical specifications TS 22.140 Version 4.1.0, Release 4, and TS 23.140 Version 4.5.0, Release 4, from the 3 rd  Generation Partnership Project (3GPP).  
         [0004]     To delimit them more clearly from the SMS text messages, messages with multimedia content are referred to in what follows as multimedia messages, MMs. By contrast with SMS, there is no restriction to a purely text content for these. With MMs, it is possible to format texts in accordance with the individual&#39;s taste, and to embed audio and video content in a message. Accordingly, an MM can consist of several MM elements with different file types (e.g. audio or still image) or file formats (e.g. for a still image the Graphic Interchange Format GIF, or Joint Photographic Experts Group JPEG). Each MM has a header (MM header) and each MM element has in addition yet another header of its own (MM element header).  
         [0005]      FIG. 1  shows a known MMS network architecture with two networks A and B, from the point of view of the 3GPP. MMS UA stands for a so-called MMS User Agent, i.e. a software program, for example on a mobile radio device or on a device connected to a mobile radio device (e.g. a laptop or similar), which realizes the functionalities for a MMS. Such functionalities can be, for example, generate, view or receive an MM, or send an MM, as applicable. MMS RS is a so-called MMS Relay/Server, i.e. a network element which is within the MMSE (Multimedia Messaging Service Environment) of the MMS service provider, i.e. service environment of the MMS service provider, MMSE SP, which makes the MMS functionality available to the MMS UAs. MM1 and MM4 are interfaces.  
         [0006]     Mobile telecommunication systems, such as for example GSM or UTMS, use defined cards, so-called smart cards, which must be plugged into a mobile radio device in order to be able to make use of the services of a network operator with which one is registered. Also stored on this card are user settings and personal data (telephone book, SMS etc.). In the case of GSM, this card is called a SIM (Subscriber Identity Module) card. In the case of UMTS, a distinction is made between the physical UICC card (Universal Integrated Circuit Card) and its logical functionality, the USIM (UMTS Subscriber Identity Module).  
         [0007]     SAT (SIM Application Toolkit) or USAT (USIM Application Toolkit), for GSM or UMTS respectively, is a toolkit which provides network operators with interfaces, so-called APIs (Application Programming Interfaces) for the purpose of programming applications. USIM Application Toolkits are, for example, described in the technical specification TS 31.111 Version 4.2.1, Release 4 from the 3GPP. With these APIs, network operators can implement their own applications on the SIM or UICC, as applicable, and with the help of USAT these can access the functionality of the mobile radio device—independently of the manufacturer of the mobile radio device and the manufacturer of the card. The SIM or the UICC card respectively is the physical basis for this toolkit, because it is provided by the network operators, and thus can be adapted as they wish.  
         [0008]     Today, network operators already have the ability to transmit MMs together with advertising messages. However, a problem in doing so is that any transmission of advertising messages must take place over the air interface, so that system resources are consumed by the advertising.  
         [0009]     In addition, it can happen that an MM element (e.g. a text file, video file or music file as advertising) is to be inserted into several MMs, all of which are sent to the same MMS UA. Such an MM element, which can be inserted repeatedly into MMs, is referred to below as a multimedia message multiple element. In a case like this, there is also the disadvantage that valuable system resources are used at the interface (which is part of the interface MM1 in  FIG. 1 ), in order to communicate again the same data, i.e. the same MM element, to the same MMS UA.  
       SUMMARY OF THE INVENTION  
       [0010]     The present invention provides a method and a system for inserting at least one multimedia message multiple element into a multimedia message, which does not unnecessarily load the system resources of a mobile radio system.  
         [0011]     In one embodiment of the invention, there is a method for inserting at least one multimedia message multiple element into a multimedia message including transmitting at least one multimedia message multiple element from a network element to a mobile station; transmitting a first multimedia message from the network element to the mobile station; and inserting the multimedia message multiple element into the first multimedia message.  
         [0012]     The system for inserting at least one multimedia message multiple element into a multimedia message has facilities for transmitting at least one multimedia message multiple element from a network element to a mobile station, facilities for transmitting a first multimedia message from the network element to the mobile station, and facilities for inserting the multimedia message multiple element into the first multimedia message.  
         [0013]     The multimedia message multiple element can in principle be any type of information data, in particular advertising data such as for example texts, tones or video films. The network element will preferably be a connecting unit MMS RS, such as has already been described, or a so-called VASP (Value Added Service Provider). The mobile station can in principle be any type of mobile terminal device, preferably however a UMTS mobile station.  
         [0014]     In a preferred embodiment of the present invention, the insertion takes place in the mobile station. This has the advantage that multimedia message multiple elements can be stored in a storage facility in the mobile station and can in each case, when required, be appended to one or more multimedia messages.  
         [0015]     In a further embodiment of the present invention, the multimedia message multiple element is transmitted once from the network element to the mobile station, and is inserted into numerous multimedia messages. This approach saves system resources in the mobile radio system, because multimedia message multiple elements need only be transmitted once over the air interface and then, possibly after storage of the information data in a memory in the mobile station, they can be appended to numerous further multimedia messages so that the user of the mobile station gets each of the original multimedia messages with the relevant multimedia message multiple elements.  
         [0016]     It is further preferred that the multimedia message multiple element is included in the first multimedia message which is sent. In this form of embodiment, the multimedia message multiple element which is transmitted with the first multimedia message which is sent can be inserted as an addition into further multimedia messages, i.e. which are communicated later.  
         [0017]     In another form of embodiment of the present invention, the multimedia message multiple element is included in a second multimedia message which is transmitted. In this case, a special multimedia message which includes this special multimedia message multiple element is transmitted via the air interface. “Second multimedia message” is here not a restriction in terms of the sequence in which the multimedia messages are transmitted. Instead, “second multimedia message” refers in the present case to a further multimedia message, to distinguish it from the first multimedia message.  
         [0018]     In another preferred form of embodiment of the present invention, numerous multimedia message multiple elements are transmitted in one multimedia message from the network element to the mobile station. This has the advantage that system resources are again saved, and numerous multimedia message multiple elements can be transmitted at once to a mobile station.  
         [0019]     It is further preferred that a multimedia message has a first data field which enables various multimedia message multiple elements to be distinguished. This first data field serves to enable different multimedia message multiple elements to be distinguished. It is conceivable that a multimedia message includes a new multimedia message element header, which is given an identifying number issued, for example, by the network element MMS RS.  
         [0020]     It is further preferred that a multimedia message has a second data field, by which a multimedia message multiple element can be assigned to a message group. To enable multimedia message multiple elements to be distinguished from normal multimedia message elements, the multimedia message multiple elements can be specially identified by the network element. It is conceivable for the multimedia message multiple elements to be given an additional multimedia message element header with an appropriate value. For example, it is possible to imagine advertising or special message groups being distinguished. Preferably, the data in the multimedia message&#39;s data field will be appended in the network element, preferably the MMS RS.  
         [0021]     In another embodiment of the present invention, the multimedia message has a third data field, including data about whether the multimedia message should be presented to the user of the mobile station. To allow for the situation in which a separate multimedia message is transmitted to communicate multimedia message multiple elements from the MMS RS to the MMS UA, the presentation of this multimedia message to the user by the MMS UA should be avoided. This can be achieved by an additional multimedia message header which is preferably inserted by the MMS RS and which requests the MMS UA not to present this multimedia message to the user. After a multimedia message multiple element has been communicated to the MMS UA, it is stored, for example on a smart card ((U)SIM or multimedia card) or in the mobile station.  
         [0022]     In a further embodiment of the present invention, a user facility undertakes the storage of a multimedia message multiple element in the mobile station. Preferably, this user facility will be an MMS UA. This user facility will undertake the storage autonomously. From the fact that a multimedia message multiple element includes a new multimedia message element header, the user facility knows that it should store this multimedia message multiple element under an appropriate reference on an available storage medium.  
         [0023]     In another embodiment, storage of a multimedia message multiple element in the mobile station is organized and/or carried out by an application facility. This application facility will preferably be a USAT. In this form of embodiment, the application facility knows nothing about the multimedia message multiple elements, but the application facility organizes the storage, in doing which the memory itself can be further initiated by the application facility. Two possibilities are conceivable here.  
         [0024]     The first possibility is that the USAT makes a one-time request to the MMS UA to forward copies of the headers, i.e. both the multimedia message header and also all the multimedia message element headers in the incoming multimedia messages to it, that is to the USAT. At this point USAT analyzes the multimedia message element headers, in doing so determines the multimedia message multiple elements by reference to the new multimedia message element header and then requests the MMS UA to save the corresponding multimedia message multiple element on an available storage medium under the appropriate reference.  
         [0025]     A second possibility is that the MMS UA forwards to USAT copies of the headers, i.e. both the multimedia message header and also the multimedia message element headers, if an appropriate header, inserted by the MMS RS, is specified in the multimedia message header. The analysis of the header by USAT, and the request to the MMS UA to effect the storage, then proceed as for the first possibility.  
         [0026]     It is further conceivable that USAT undertakes not only the organization but also the actual storage activities. In this case too, both of the possibilities explained above are usable, with the difference that not only copies of the headers but the entire multimedia message is passed over to the USAT. The USAT then not only analyzes the header, but also stores on the UICC (or on the smart card which includes the USAT, as applicable) the multimedia message multiple elements as well, with the appropriate reference.  
         [0027]     With the three possibilities explained above, the following overwrite rule can be applied: if a multimedia message multiple element is to be stored with a reference which already exists, then the old multimedia message multiple element should be overwritten. Using this rule it is also possible, for example, to update multimedia message multiple elements.  
         [0028]     For the purpose of avoiding the transmission and storing away of multimedia message multiple elements it is, however, also conceivable that, even at the time of dispatch of the mobile station product, the MMS UA, the UICC, or some other storage medium which the MMS UA can access, multimedia message multiple elements are stored away on it with appropriate referencing.  
         [0029]     In another embodiment of the present invention, if a multimedia message multiple element is already stored in a mobile station a reference to the multimedia message multiple element is inserted into a multimedia message which is to be transmitted to the mobile station. If, for example, a multimedia message is transmitted, from the MMS RS to the MMS UA, which is to include a particular multimedia message multiple element (which is stored in the associated mobile station with an appropriate reference), then this multimedia message multiple element will not be inserted in the MMS RS but instead an additional multimedia message header with the appropriate reference to it. This multimedia message is then communicated from the MMS RS to the mobile station.  
         [0030]     Preferably, the insertion of a multimedia message multiple element will be undertaken in the mobile station by a user facility. The user facility concerned will preferably be an MMS UA. From the fact that the multimedia message contains a new multimedia message header, the MMS UA knows that it can read the appropriate multimedia message multiple element out from the appropriate storage medium under the corresponding reference, in order to then insert it into the multimedia message.  
         [0031]     In a further embodiment, the insertion of a multimedia message multiple element is organized and/or carried out in the mobile station by an application facility. The application facility will preferably be a USAT. In this case it is not the user facility (MMS UA) but the application facility (USAT) which organizes the insertion of a multimedia message multiple element into a multimedia message. The insertion itself is, as before, carried out by the user facility. For this purpose, there are two conceivable possibilities: with the first possibility, the application facility makes a one-time request to the user facility to send copies of the headers for incoming multimedia messages to it—that is to the application facility. The application facility then analyzes the multimedia message header and in doing so finds an appropriate multimedia message header. There may even be several multimedia message headers of this type. At this point, the application facility requests the user facility to insert the corresponding referencable multimedia message multiple element into the multimedia message.  
         [0032]     With the second possibility, the situation is that the user facility sends copies of the headers to the application facility if an appropriate header is specified in the multimedia message header. The analysis of the headers by the application facility, and the request to the user facility to insert the appropriate multimedia message multiple element, then proceed as for the possibility explained above.  
         [0033]     The application facility (USAT) can undertake not only the organization but also the actual insertion of a multimedia message multiple element. In this case too, both of the possibilities explained above are usable, with the difference that not only copies of the headers but the multimedia message is forwarded to the application facility. The application facility would thus not only analyze the headers but would in addition also load from the UICC (or the smart card on which is the USAT, as applicable) multimedia message multiple elements corresponding to the references, insert them into the multimedia message and then pass the modified multimedia message back to the user facility.  
         [0034]     If the main part of the multimedia message which is to be transmitted includes a programming-language-based presentation, for example an SMIL presentation, a network element (e.g. MMS RS) could also, as an alternative to introducing an additional multimedia message header, directly embed in the SMIL presentation the reference to the multimedia message multiple element stored in the terminal device. SMIL (Synchronize Multimedia Integration Language) is a programming language for specifying interactive audio-visual presentations. In such a case, the multimedia message multiple element would be called up from within the SMIL presentation when the multimedia message is opened or viewed, as applicable. In doing this, the additional multimedia message header is not inserted, and hence also the multimedia message multiple element is not physically inserted into the multimedia message. Instead, the reference is embedded in the SMIL presentation. An advantage of this is that when a multimedia message is presented the current multimedia message multiple element is displayed (e.g. if a multimedia message multiple element, for example an advertising message, is updated by overwriting between the receipt and the presentation of the multimedia message).  
         [0035]     It is also conceivable for a reference to a multimedia message multiple element stored in the mobile station to be directly embedded in a multimedia message.  
         [0036]     It is further possible that the additional functionalities of the network element (MMS RS) are undertaken by a server which is operated by a so-called MMS VASP (MMS Value Added Service Provider). In such a case, the multimedia message is initially transmitted from the network element (MMS RS) to the MMS VASP, which applies the necessary functionalities to the multimedia message. After this, the MMS VASP transmits the multimedia message back to the network element, the multimedia message possibly modified by the appending of headers. The network element (MMS RS) then communicates the multimedia message to the user facility (MMS UA).  
         [0037]     The following rule could, furthermore, be advantageously applied: if a multimedia message multiple element is not present with its reference in the memory, then no insertion is made. In addition, it is conceivable for the user facility (e.g. MMS UA) to transmit to the network element (e.g. MMS RS) an error message which indicates that the multimedia message multiple element which was referenced is missing. One possibility would then be that, as a result of the error message, the network element either makes no further reference to this multimedia message multiple element, or that the network element effects a communication of the missing multimedia message multiple element, to avoid this error for any further multimedia messages.  
         [0038]     The network element&#39;s choice as to whether and which multimedia message multiple element to reference with the additional multimedia message header, or which multimedia message multiple element should be inserted into a multimedia message, can be made dependent on certain conditions.  
         [0039]     This procedure should preferably be applied when the multi-media message multiple elements concerned are advertising messages, because in such a case advertisements should be sent selectively. The choice can be made dependent, for example, on the transmit address. For example, if the sender is a particular network supplier, then an advertising message for this network supplier should also be inserted. However, the choice can also be made dependent on the receiver&#39;s whereabouts. For example, if the receiver is near to a particular supermarket, then an advertising message for this particular supermarket should also be inserted.  
         [0040]     The present invention relates further to a mobile station for use with a method in accordance with the invention and a mobile station for use in a system in accordance with the invention.  
         [0041]     One advantage of the present invention is that multimedia message multiple elements which need to be communicated repeatedly from the network element (e.g. MMS RS) to the same user facility (e.g. MMS UA) need only be transmitted once over the air interface. This achieves the effect of avoiding the repeated transportation of the same data, i.e. the same multimedia message multiple elements, and hence valuable resources on the air interface are saved. Particularly in the case of resource-intensive multimedia message multiple elements in multimedia form, this effects a clear reduction in the data to be transmitted for a multimedia message.  
         [0042]     With the present invention, the network operator has the possibility of inserting a particular multimedia message multiple element into several multimedia messages as an advertising message before the multimedia message is presented to the user of the mobile station. This avoids burdening the air interface time and again with the same advertising message. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0043]     The invention is explained in more detail below with reference to the attached drawings and exemplary embodiments. The drawings show:  
         [0044]      FIG. 1  an MMs network architecture in accordance with 3GPP.  
         [0045]      FIG. 2  an exemplary embodiment of the transmission of a multimedia message.  
         [0046]      FIG. 3  an exemplary embodiment of the transmission of a multimedia message with a multimedia message element header.  
         [0047]      FIG. 4  an exemplary embodiment of the transmission of a multimedia message with an additional multimedia message element header.  
         [0048]      FIG. 5  an exemplary embodiment of the transmission of a multimedia message with an additional multimedia message multiple element.  
         [0049]      FIG. 6  an exemplary embodiment of the transmission of a multimedia message with an additional multimedia message header.  
         [0050]      FIG. 7  an exemplary embodiment of the transmission of a multimedia message with the insertion of an additional multimedia message multiple element.  
         [0051]      FIG. 8  an exemplary embodiment of the transmission of a multimedia message with the insertion of an additional multimedia message header.  
         [0052]      FIG. 9  an exemplary embodiment of the insertion of a multimedia message multiple element into a multimedia message. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0053]      FIG. 1  has already been explained in the introduction to the description.  
         [0054]     In a first exemplary embodiment, the insertion of multimedia message multiple elements into a multimedia message can be subdivided into four steps:  
         [0055]     In a first step, a multimedia message is to be sent to a user. For this purpose, the multimedia message initially arrives at the MMS RS which is responsible for it. Before the MMS RS forwards this multimedia message to this user&#39;s MMS UA, it inserts an advertising message into this multimedia message as a multimedia message multiple element. In doing so, the multimedia message element header is given the entry “C-P: ad/1”, for example. Following this, the MMS RS communicates this multimedia message to the MMS UA by means of a message “MMS_retrieve.RES”, 2. This operation is shown in  FIG. 2 .  
         [0056]     In a second step the MMS UA, after it has received the multimedia message, analyzes the multimedia message element headers and in doing so finds the multimedia message element header “C-P: ad/1” which belongs to the multimedia message multiple element with the advertising message. At this point, the MMS UA saves this multimedia message multiple element under the appropriate reference (here, for example, “ad/1”) on an available storage medium. The operation of the second step is shown, for example, in  FIG. 3 . After this, the MMS UA can further process the multimedia message.  
         [0057]     In a third step, the MMS RS wishes once again to insert the first multimedia message multiple element with the reference “ad/1” into a multimedia message. However, instead of once again inserting the multimedia message multiple element (as under step one), the MMS RS now inserts an additional multimedia message header “X-MMS-Insert-MM_Element: ad/1”, and then sends this multimedia message on to the MMS UA.  
         [0058]     In a fourth step, after it has received the multimedia message the MMS UA analyzes the multimedia message element headers, in doing which is finds the multimedia message header “X-MMS-Insert-MM_Element: ad/1”. Thereupon, the MMS UA reads this multimedia message multiple element from the storage medium under the appropriate reference (here for example “ad/1”), and inserts this multimedia message multiple element into the multimedia message. The operation of the fourth step is shown in  FIG. 4 . After this, the MMS UA can further process the multimedia message.  
         [0059]     In a second exemplary embodiment of the present invention, the USAT makes a one-time request to the MMS UA to forward copies of the headers (both of the multimedia message header and also of all the multimedia message element headers) in all the incoming multimedia messages to it—that is to the USAT.  
         [0060]     The first step is identical with the first step of the first exemplary embodiment.  
         [0061]     In the second step the MMS UA, after it has received the multimedia message, gives copies of the headers to the USAT (because it was previously asked to do so by the USAT, see the introduction to the second exemplary embodiment). The USAT analyzes the multimedia message element headers, and in doing so determines all the multimedia message multiple elements which are present by reference to the new multimedia message element header (e.g. “C-P:ad/1”) and then requests the MMS UA to save the corresponding MM multiple elements on an available storage medium under the appropriate reference (here for example “ad/1”). The operation of the second step is shown in  FIG. 5 . After this, the MMS UA can further process the multimedia message.  
         [0062]     The third step which follows is identical to method step three of the first exemplary embodiment.  
         [0063]     In the fourth step, the MMS UA passes copies of the headers on to the USAT. The USAT then analyzes the multimedia message header and in doing so finds the multimedia message header “X-MMS-Insert-MM_Element: ad/1”. Thereupon, the USAT requests the MMS UA to insert the correspondingly referenced multimedia message multiple element “ad/1” into the multimedia message. Hence, the MMS UA reads this multimedia message multiple element from the storage medium under the corresponding reference “ad/1”, and inserts this multimedia message multiple element into the multimedia message. This operation is shown in  FIG. 6 . After this, the MMS UA can further process the multimedia message.  
         [0064]     In a third exemplary embodiment of the present invention, the USAT makes a one-time request to the MMS UA to pass on copies of the headers (both of the multimedia message header and also of the multimedia message element headers) in all the incoming multimedia messages to it—that is to the USAT—if an appropriate header (e.g. “X-MMS-Intended_for_USAT:YES”) is specified in the multimedia message header.  
         [0065]     In a first step, a multimedia message is to be sent to a user. For this purpose, the multimedia message initially arrives at the MMS RS which is responsible for it. Before the MMS RS forwards this multimedia message to this user&#39;s MMS UA, it inserts an advertising message into this multimedia message as a multimedia message multiple element. In doing so, the multimedia message element header is given the entry “C-P: ad/1”, for example, and the multimedia message header the entry “X-MMS-Intended_for_USAT: YES”, for example. Following this, the MMS RS communicates this multimedia message to the MMS UA by means of a message “MM1_retrieve.RES”, 2.  
         [0066]     In the second step, the MMS UA passes on copies of the headers to the USAT, because the condition is satisfied, that the header “X-MMS-Intended_for_USAT: YES” is inserted in the multimedia message. This second step thus corresponds to the second step in the second exemplary embodiment.  
         [0067]     In a third step, the MMS RS wishes once again to insert the first multimedia message multiple element with the reference “ad/1” into a multimedia message. However, instead of once again inserting the multimedia message multiple element (as under step one), the MMS RS now inserts an additional multimedia message header “X-MMS-Insert-MM_Element: ad/1”, and the additional multimedia message header “X-MMS-Intended_for_USAT: YES”, and then sends this multimedia message on to the MMS UA. In the fourth step, the MMS UA forwards copies of the headers to the USAT because the condition is satisfied, that the header “X-MMS-Intended_for_USAT: YES” is inserted in the multimedia message. This fourth step thus corresponds to the fourth step in the previous exemplary embodiment.  
         [0068]     A fourth exemplary embodiment is a variant of the second or third exemplary embodiments respectively.  
         [0069]     Compared with exemplary embodiments two and three, the second step changes in such a way that the MMS UA passes on to the USAT not only copies of the headers but a copy of the complete multimedia message (with the variant of exemplary embodiment two as a result of the preceding one-time request by the USAT, and with the variant of exemplary embodiment three as a result of the header “X-MMS-Intended_for_USAT: YES”). The USAT analyzes the multimedia message element headers, and in doing so determines the multimedia message multiple elements which are present by reference to the new multimedia message element header (e.g. “C-P:ad/1”) and then saves the corresponding MM multiple elements on an available storage medium, e.g. UICC (or the smart card which includes the USAT, as applicable) under the appropriate reference (here for example “ad/1”). The operation of the second step is shown in  FIG. 7 . After this, the MMS UA can further process the multimedia message.  
         [0070]     Compared with exemplary embodiments two and three, the fourth step changes in such a way that the MMS UA passes on to the USAT not only copies of the headers but the complete multimedia message (with the variant of exemplary embodiment two as a result of the preceding one-time request by the USAT, and with the variant of exemplary embodiment three as a result of the header “X-MMS-Intended_for_USAT: YES”). The USAT then analyzes the multimedia message element header, and in doing so finds the multimedia message header “X-MMS-Insert-MM_Element: ad/1”. Hence, the USAT reads this multimedia message multiple element from the storage medium under the corresponding reference “ad/1”, and inserts this multimedia message multiple element into the multimedia message. After this the USAT returns the multimedia message, modified in this way, to the MMS UA. This operation is shown in  FIG. 8 . After this, the MMS UA can further process the multimedia message.  
         [0071]     In a fifth exemplary embodiment, consideration is now given to the case that the MMS RS does not send a multimedia message to the MMS UA but the reverse, the MMS UA sends a multimedia message to the MMS RS. Here, it is conceivable that the MMS UA or USAT, as applicable, inserts a multimedia message multiple element into a multimedia message before the multimedia message is forwarded to the MMS RS. The user can then, for example, insert a file with his visiting card into a particular multimedia message which he sends off, or into all of them. This is shown in  FIG. 9 .  
         [0000]     List 1:  
         [0000]     X-Mms-Message-Type: m-send-req  
         [0000]     . . .  
         [0000]     X-Mms-Delivery-Report: Yes  
         [0000]     From: markus.trauberg@sal.siemens.de  
         [0000]     To: andreas.schmidt@sal.siemens. de  
         [0000]     Date: Fri, 7 Jul 2000 20:59:30 +0100  
         [0000]     Subject: A multimedia message  
         [0000]     nEntries=2  
         [0000]     HeaderLen=13  
         [0000]     DataLen=31  
         [0000]     Content-Type: text/plain;  
         [0000]     name=“datei.txt” 
         [0000]     “Hallo Andreas, how are you?” 
         [0000]     HeaderLen=11  
         [0000]     DataLen=2736  
         [0000]     Content-Type: video;  
         [0000]     name=“film.vid” 
         [0000]     “ . . . Video-Data . . . ” 
         [0000]     List 2:  
         [0000]     X-Mms-Message-Type: m-send-re q  
         [0000]     . . .  
         [0000]     X-Mms-Delivery-Report: Yes  
         [0000]     From: markus.trauberg@sal.siemens.de  
         [0000]     To: andreas.schmidt@sal.siemens.de  
         [0000]     Date: Fri, 7 Jul. 2000 20:59:30 +0100  
         [0000]     Subject: A multimedia message  
         [0000]     nEntries=3  
         [0000]     HeaderLen=13  
         [0000]     DataLen=31  
         [0000]     Content-Type: text/plain;  
         [0000]     name=“datei.txt” 
         [0000]     “Hallo Andreas, how are you?” 
         [0000]     HeaderLen=11  
         [0000]     DataLen=2736  
         [0000]     Content-Type: video;  
         [0000]     name=“film.vid” 
         [0000]     “ . . . Video-Data . . . ” 
         [0000]     HeaderLen=13  
         [0000]     DataLen=56  
         [0000]     Content-Type: text/plain;  
         [0000]     C-P: ad/1;  
         [0000]     name=“siemens.txt” 
         [0000]     “This MM is sponsored by: Siemens mobile—be inspired” 
         [0072]     List 1 shows a multimedia message in accordance with the state of the art. The upper part is a so-called multimedia message header. “nEntris” specifies how many multimedia message elements are inserted into the multimedia message. After this comes the multimedia message elements, each with its own multimedia message element header and content. Both the MMS RS and the MMS UA have, in accordance with the state of the art, the functionality for inserting a multimedia message element into an existing multimedia message, and/or to extend and/or change the multimedia message header and/or a multimedia message element header. An example of a change compared to List 1 is shown in List 2 in boldface type. Here, the multimedia message element which is inserted has the file format “Text”, but other file formats are also conceivable.  
         [0000]     List 3:  
         [0000]     X-Mms-Message-Type: m-send-req  
         [0000]     X-Mms-Delivery-Report: Yes  
         [0000]     From: markus.trauberg@sal.siemens.de  
         [0000]     To: andreas.schmidt@sal.siemens.de  
         [0000]     Date: Fri, 7 Jul 2000 20:59:30 +0100  
         [0000]     Subject: A multimedia message  
         [0000]     nEntries=3  
         [0000]     HeaderLen=13  
         [0000]     DataLen=31  
         [0000]     Content-Type: text/plain;  
         [0000]     name=“datei.txt” 
         [0000]     “Hallo Andreas, how are you?” 
         [0000]     HeaderLen=11  
         [0000]     DataLen=2736  
         [0000]     Content-Type: video;  
         [0000]     name=“film.vid” 
         [0000]     “ . . . . Video-Data . . . ” 
         [0000]     HeaderLen=13  
         [0000]     DataLen=56  
         [0000]     Content-Type: text/plain;  
         [0000]     C-P: ad/1;  
         [0000]     name=“siemens.txt” 
         [0000]     “This MM is sponsored by: Siemens mobile—be inspired” 
         [0000]     List 4:  
         [0000]     X-Mms-Message-Type: m-send-req  
         [0000]     X-Mms-Delivery-Report: Yes  
         [0000]     X-MMS-Empfänger-Sichtbarkeit: Nein  
         [0000]     To: andreas.schmidt@sal.siemens.de  
         [0000]     Date: Fri, 7 Jul 2000 20:59:30 +0100  
         [0000]     nEntries=1  
         [0000]     HeaderLen=13  
         [0000]     DataLen=58  
         [0000]     Content-Type: text/plain;  
         [0000]     C-P: ad/2;  
         [0000]     name=“siemens2.txt” 
         [0000]     “This MM is sponsored by: Siemens Hausgeräte” 
         [0000]     List 5:  
         [0000]     X-Mms-Message-Type: m-send-req  
         [0000]     . . .  
         [0000]     X-Mms-Delivery-Report: Yes  
         [0000]     X-MMS-Empfänger-Sichtbarkeit: Nein  
         [0000]     To: andreas.schmidt@sal.siemens.de  
         [0000]     Date: Fri, 7 Jul 2000 20:59:30 +0100  
         [0000]     nEntries=2  
         [0000]     HeaderLen=13  
         [0000]     DataLen=56  
         [0000]     Content-Type: text/plain;  
         [0000]     C-P: ad/1;  
         [0000]     name=“siemens.txt” 
         [0000]     “This MM is sponsored by: Siemens mobile—be inspired” 
         [0000]     HeaderLen=13  
         [0000]     DataLen=58  
         [0000]     Content-Type: text/plain;  
         [0000]     C-P: ad/2;  
         [0000]     name=“siemens2.txt” 
         [0000]     “This MM is sponsored by: Siemens Hausgeräte” 
         [0073]     Lists 3, 4 and 5 show examples of three multimedia messages with the help of which multimedia message multiple elements can be communicated from the MMS RS to the MMS UA. List 3 shows a first multimedia message which is to include the multimedia message multiple element with the name “Siemens.txt”. This is given the multimedia message multiple element with the additional multimedia message element header “C-P: ad/1” inserted. List 4 shows an example in which an extra multimedia message is sent off in order to communicate this multimedia message multiple element with the additional multimedia message element header “C-P”. The additional multimedia message header “X-MMS-Empfänger-Sichtbarkeit: Nein” [X-MMS-Receiver-Visibility: No] ensures that this multimedia message is later not subject to further processing as a “normal” multimedia message by the MMS UA. In the example as shown in List 5 it is also possible to communicate several multimedia message multiple elements simultaneously using one multimedia message.  
         [0074]     In the examples as shown in lists 3, 4 and 5, the additional multimedia message element header “C-P: ad/1” indicates that it is a multimedia message multiple element, and also specifies a unique identification number so that it can later be referenced unambiguously.  
         [0000]     List 6:  
         [0000]     X-Mms-Message-Type: m-send-req  
         [0000]     X-Mms-Transaction-ID: 543210  
         [0000]     X-Mms-Version: 1.0  
         [0000]     X-Mms-Message-Class: Personal  
         [0000]     X-Mms-Expiry: 36000  
         [0000]     X-Mms-Priority: Normal  
         [0000]     X-Mms-Sender-Visibility: Show  
         [0000]     X-Mms-Delivery-Report: Yes  
         [0000]     From: markus.trauberg@sal.siemens.de  
         [0000]     To: andreas.schmidt@sal.siemens.de  
         [0000]     Date:Fri, 7 Jul 2000 20:59:30 +0100  
         [0000]     Subject: A multimedia message  
         [0000]     nEntries=2  
         [0000]     HeaderLen=13  
         [0000]     DataLen=31  
         [0000]     Content-Type: text/plain;  
         [0000]     name=“datei.txt” 
         [0000]     “Hallo Andreas, how are you?” 
         [0000]     HeaderLen=11  
         [0000]     DataLen=2736  
         [0000]     Content-Type: video;  
         [0000]     name=“film.vid” 
         [0000]     “ . . . Video-Data . . . ” 
         [0000]     List 7:  
         [0000]     X-Mms-Message-Type: m-send-req  
         [0000]     X-Mms-Transaction-ID: 543210  
         [0000]     X-Mms-Version: 1.0  
         [0000]     X-Mms-Message-Class: Personal  
         [0000]     X-Mms-Expiry: 36000  
         [0000]     X-Mms-Priority: Normal  
         [0000]     X-Mms-Sender-Visibility: Show  
         [0000]     X-Mms-Delivery-Report: Yes  
         [0000]     X-MMS-insert-MM_Element: ad/1  
         [0000]     From: markus.trauberg@sal.siemens.de  
         [0000]     To: andreas.schmidt@sal.siemens.de  
         [0000]     Date:Fri, 7 Jul 2000 20:59:30 +0100  
         [0000]     Subject: A multimedia message  
         [0000]     nEntries=2  
         [0000]     HeaderLen=13  
         [0000]     DataLen=31  
         [0000]     Content-Type: text/plain;  
         [0000]     name=“datei.txt” 
         [0000]     “Hallo Andreas, how are you?” 
         [0000]     HeaderLen=11  
         [0000]     DataLen=2736  
         [0000]     Content-Type: video;  
         [0000]     name=“film.vid” 
         [0000]     “ . . . Video-Data . . . ” 
         [0000]     List 8:  
         [0000]     X-Mms-Message-Type: m-send-req  
         [0000]     X-Mms-Transaction-ID: 543210  
         [0000]     X-Mms-Version: 1.0  
         [0000]     X-Mms-Message-Class: Personal  
         [0000]     X-Mms-Expiry: 36000  
         [0000]     X-Mms-Priority: Normal  
         [0000]     X-Mms-Sender-Visibility: Show  
         [0000]     X-Mms-Delivery-Report: Yes  
         [0000]     X-MMS-insert-MM_Element: ad/1  
         [0000]     From: markus.trauberg@sal.siemens.de  
         [0000]     To: andreas.schmidt@sal.siemens.de  
         [0000]     Date:Fri, 7 Jul 2000 20:59:30 +0100  
         [0000]     Subject: A multimedia message  
         [0000]     nEntries=3  
         [0000]     HeaderLen=13  
         [0000]     DataLen=31  
         [0000]     Content-Type: text/plain;  
         [0000]     name=“datei.txt” 
         [0000]     “Hallo Andreas, how are you?” 
         [0000]     HeaderLen=11  
         [0000]     DataLen=2736  
         [0000]     Content-Type: video;  
         [0000]     name=“film.vid” 
         [0000]     “ . . . Video-Data . . . ” 
         [0000]     HeaderLen=13  
         [0000]     DataLen=56  
         [0000]     Content-Type: text/plain;  
         [0000]     name=“siemens.txt” 
         [0000]     “This MM is sponsored by: Siemens mobile—be inspired” 
         [0075]     List 6 shows once again a known multimedia message.  
         [0076]     List 7 shows how, instead of again inserting a multimedia message multiple element, which is stored in the mobile radio device, into the multimedia message, the MMS RS inserts an additional multimedia message header “X-MMS-Insert-MM_Element: ad/1”.  
         [0077]     From List 8 it can be seen that the MMS UA then knows that it must insert the multimedia message multiple element with the reference “ad/1” into the multimedia message before it can process the latter any further.  
         [0078]     FIGS.  2  to  9  are explained in more detail below. In the explanations which follow, labels which are the same have the same meaning.  
         [0079]      FIG. 2  shows a multimedia message MM with a header H, the two MM elements T (text) and V (video file). The MMS RS receives  1  the MM and inserts into the MM an additional MM multiple element W with the MM element header “C-P:ad/1” as an advertising message. This modified MM is forwarded  2  to the MMS UA in the mobile station MS.  
         [0080]      FIG. 3  shows that, after the MMS RS has inserted an additional MM multiple element W with the MM element header “C-P:ad/1” into the MM as an advertising message, the modified MM is then forwarded  3  to the MMS UA in the mobile station MS. Because of the new MM element header “C-P:ad/1”, the MMS UA then stores  4  the MM multiple element with the advertising message in a storage medium SM in the mobile station MS, with the reference “ad/1”.  
         [0081]      FIG. 4  shows that, after the MMS RS has inserted an additional MM header “I-E:ad/1”, the modified MM is then forwarded  5  to the MMS UA in the mobile station MS. Because of this new MM header, the MMS UA then reads out  6  from the storage medium SM the MM multiple element with the reference “ad/1”, and inserts it into the MM.  
         [0082]      FIG. 5  shows how the MMS RS inserts an additional MM multiple element W with the MM element header “C-P:ad/1” into the MM. The MMS passes copies  8  of the headers to the (U)SAT, which thereupon finds the MM element header “C-P:ad/1”. The (U)SAT then requests  9  the MMS UA to store away  10  the corresponding MM multiple element on an available storage medium SM in the mobile station MS with the reference “ad/1”.  
         [0083]      FIG. 6  shows how the MMS RS inserts an additional MM header “I-E:ad/1” into the MM. The MMS UA passes copies  12  of all the headers to the (U)SAT. This then finds the MM header “I-E:ad/1”. As a result, the (U)SAT requests  13  the MMS UA to read the appropriate MM multiple element “ad/1” from the storage medium SM and to insert  14  the appropriate MM multiple element into the MM.  
         [0084]      FIG. 7  shows the insertion by the MMS RS of an additional MM multiple element W with the MM element header “C-P:ad/1” into the MM. The MMS UA passes  16  a copy of the complete MM to the (U)SAT. The (U)SAT then finds the MM element header “C-P:ad/1”. As a result the USAT stores away  17  the corresponding MM multiple element on the UICC with the reference “ad/1”. The MMS UA can then further process the MM.  
         [0085]      FIG. 8  shows the insertion of an additional MM header “I-E:ad/1” by the MMS RS. The MMS UA passes  19  the complete MM across to the USAT. This then finds the MM header “I-E:ad/1”. As a result, the USAT reads the corresponding MM multiple element “ad/1” from the UICC (cf. 20), inserts the corresponding MM multiple element into the MM and returns  21  the modified MM to the MMS UA. The MMS UA can then further process the MM.  
         [0086]     Finally,  FIG. 9  shows how the MMS UA inserts  40  an MM multiple element VIS, e.g. a visiting card, into the MM. After this, the MMS UA communicates the modified MM* to the MMS RS with the help of the message  41 .