Cost accounting during data transmission in a mobile radio telephone network

Data transmission fee settlement in mobile wireless network

The present invention relates to a method for settlement of data transmission costs in a mobile wireless network as described in the preamble of claim 1, a mobile telecommunication device as claimed in claim 21 and a method as claimed in claim 25 A computer program product.

Today's mobile wireless networks, such as those operating in compliance with the GSM standard, reveal quite limited possibilities to transmit non-voice messages, such as text data. Therefore, short messages with a maximum of 160 characters can be transmitted in the form of text. This application is called SMS (Short Message Service). The cost of sending such text messages is borne by the sender of the data.

In the future, it may be necessary to transmit multimedia data, especially still or moving images with or without sound. It is necessary to consider the rapid expansion of the data transmission volume and the sharp increase in the number of transmitted messages in this transmission, which brings an increase in costs as a whole.

The problem underlying the present invention is to simplify the cost control and cost interference for users of the mobile wireless network.

The present invention is implemented by a method having the characteristics of claim 1, a mobile telecommunication device having the characteristics of claim 22, and a computer program product having the characteristics of claim 26. See claims 2-20, 23-25 and 27 for preferred improvements.

The method of the present invention creates the following possibility, that is, it is possible to respond to the data obtained by the data receiver free of charge. This reveals, for example, the possibility of executing a query to the data sender-this has always been a request for the responder to take over the cost of the response message, thus leading to fewer reverse responses. According to the present invention, the recipient is undoubtedly provided with free of charge for its response, thereby simplifying the cost control for the response.

If the sender can set the fee signal, the sender can also choose whether to take over the fee of one of the multiple possible response messages according to individual circumstances.

In an improved solution of the present invention, the service provider informs the sender of which fees he wishes to take over the response fees, such as the smallest or the largest fees. This value can be calculated at the service provider and depends on how many recipients the data is transmitted to.

It is particularly preferred that the data sender determines a time delay for which a response must be made in order to also take over the charge. As a result, the data sender can purposely limit the possible costs without generating a corresponding response for each recipient, and the insecurity of being free of charge should not be taken over by the data sender. You can also use the same purpose to limit the number of responses from each receiver.

If the data sender divides the possible receivers into groups, and then assigns correspondingly determined response cost takeover parameters to these groups, then a very effective cost control possibility can be obtained. Thus, for example, old customers can be assigned other charge-over conditions as new customers, such as extending the free response time for old customers.

In short, this can achieve appropriate cost takeover for the receivers response that is accurately controlled by the sender, so it can also be used for batch transmission, such as TED queries or sales through telemarketing.

Other advantages and features of the present invention can be derived from the embodiments of the present invention shown in the drawings and described below.

In the drawings: Figure 1 is a simplified diagram of data transmission between the sender and provider level and the provider and receiver level according to the WAP (Wireless Application Protocol) standard. Figure 2 shows a diagram similar to Figure 1 In addition, after the data transmission, the original receivers response is followed. Figure 3 shows the M-send.req sent according to the WAP protocol, and Figure 4 shows the M-send.req ( The background color is gray), Figure 5 shows the sending of M-send.conf according to the WAP protocol, and Figure 6 shows the sending of M-send.conf supplemented with a fee signal according to the present invention (the background color is gray), and Figure 7 shows The M-Notification.ind is sent according to the WAP protocol. Figure 8 shows that the M-Notification.ind is sent according to the present invention supplemented with a fee signal (the background color is gray). Figure 9 shows the M-Retrieve sent according to the WAP protocol. .conf, Figure 10 shows the sending of M-Retrieve.conf (gray background) according to the present invention supplemented with a fee signal, Figure 11 shows the field occupation (encoding) of the fee signal in the above figure, Figure 12 Shows the addressing of the additional header fields according to the present invention, and FIG. 13 shows a schematic diagram of the principle of data transmission using the mobile telecommunication device of the present invention.

In this embodiment, the application of the present invention in the data transmission scheme 1 of the WAP standard will be described. For example, it can be especially used to transmit special image data and formatted text data in accordance with the UMTS standard (Universal Mobile Telecommunications System Standard). . It should be understood that the present invention can also be transferred to other standards.

In the UMTS standard, it is stipulated that in addition to the SMS (Short Message Service) so far, a so-called MMS (Multimedia Messaging Service) is also set up for the transmission of non-voice messages. Therefore, it is also possible to transfer formatted text and images. Removed the 160-character restriction on message length in SMS. It is possible to transmit audio and video messages.

MMS can be realized by using WAP. Here, for the wireless transmission of data, such as multimedia messages (MMS), the protocol scheme shown in FIG. 1 for unilateral data transmission and in FIG. 2 through additional transmission response (WAP WSP: Wireless Session protocol). The protocol includes level 2 of the data sender (MMS user agent A), level 3 of the provider (MMS relay), and level 4 of the receiver (MMS user agent B). Level 2 of the data sender includes at least one telecommunication device 5, and similarly, level 4 of the receiver includes one telecommunication device 6. The telecommunication devices 5, 6 can be implemented as ordinary mobile phones or devices with other input or display functions, such as laptop computers, for example.

The data group 7 compiled in the senders telecommunication equipment 5 or transmitted through the telecommunication equipment is first used as the sending 9 (the sending carries the name M-Send.req according to the WAP protocol, and there is no figure in the present invention in its composition. The extension shown in 3) is sent to the provider (level 3).

From there, a return 10 (called M-Send.conf in the WAP standard, as shown in Figure 5 in the structure so far) sent to the sender (level 2) is used to sign for the incoming transmission.

After this time, the provider 3 sends the message 11 (M-Notification.ind, Fig. 7) to the receiver (level 4), and uses the information to inform the receiver that there is already at provider 3 for it Download the message.

To this end, the provider 3 automatically receives, for example, a sign-off feedback message 12 (M-NotifyResp.req) from the telecommunication device 6 of the receiver (level 4).

Only according to the request given by the receiver using the send 13 (WSPGET.req), can the provider 3 use the send 14 (M-Retrieve.conf, Fig. 9) to transmit the data group 7 to the receiver (level 4).

In order to manage the transmissions 9, 10, 11, 12, and 14, so-called header fields are used, that is, the fields placed before the original data group 7, which include information about the source, transmission time, file size, and other details .

According to the present invention, the number of header fields is increased so that at least one other field can be used as an information and control field, and a fee signal can be accommodated in it to prepare to take over the data sent from the receiver 4 back to the original data sender 2. Reply to the return fee (Figure 2).

In this embodiment, the header fields 0×1B to 0×1E represented by reference symbols 17, 18, 19, and 20 are occupied for this purpose (FIG. 12). Here, the fields 0×1C~0×1E contain information about different fee takeovers that match the recipient groups respectively (see below), and the field 0×1B contains identification signals for response, so that the The response is assigned to the data group 7 obtained in advance. The field 0x1A denoted by 22 contains information about the expected fee (see below).

The sender (level 2) can operate a switch or similar input device 16 on its telecommunication equipment 5, which can be operated in terms of hardware or in particular in software and through the keyboard which is also present anyway, in order to therefore target a Or multiple responses set up the charge to take over. Optionally, it can also be set by the service provider 3 through an agreement with the service provider 3, and the agreement can be updated, for example, before the data is sent.

In the absence of a special (long-term) agreement with the service provider 3, the following information needs to be transmitted from the sender 2 to the service provider in the query 9 (M-send.req) for searching for data transmission 7 Quotient 3: The sender 2 takes over and, if necessary, within what range the response fee of the sent data is taken over. In this regard, the header fields 17, 18, 19, and 20 are re-included in the query 9 (Figure 4), thereby expanding the number of header fields compared to the prior art (Figure 3). For example, use 0×1B, 0×1C and 0×1D (decimal 28, 29, 30) to address and obtain the field names "X-Mms-RFF-To-Amount", "X-Mms-RFF-Cc- In the fields 17, 18, and 19 of "Amount" and "X-Mms-RFF-Bcc-Amount", integer variables are stored respectively (Figure 11). These variables are respectively given to three recipient groups-namely the "To" group (direct recipient), the "Cc" group ("copy": control reception when the other recipients are known) and the "Bcc" group (" "Blind copy": control reception without knowing other recipients)-Defines the number of response messages of the recipient 4 in each such group that the original sender 2 takes over the cost. The value can be different for different groups, which will bring the above-mentioned advantages. It is also possible to set only one response to take over the cost. If the integer variable consists of an 8-bit byte, for example, there may be up to 256 free responses. Other or more detailed divisions can also be made to replace the grouping shown here.

In addition, the following supplement is made to the existing field 21 (X-Mms-Expiry), namely: at this time, the maximum storage time of the message entered in the server of the provider 3 is defined as the maximum delay of the fee takeover (final time limit) ), that is, those responses sent after the time delay are no longer paid by the sender 2 of the original data.

Field 20 gives an identification signal for re-identifying the response, so that the response can be assigned to the correct data group 7, and not all messages that arrive at the original sender 2 within this continuous time can be Obtained with the title "Response Free", so the sender should pay.

It should be understood that in addition to the field selection described here, other fields can also be adopted, such as those fields that enter a part of the cost when the response cost should not be borne by the sender 2 of the original data. It can also be input for example: before the time delay stored in the field 21 elapses, all the expenses mentioned are taken over, and then only a part of the expenses are taken over or no more than a maximum limit value is taken over. Similarly, you can also choose the response type that takes over the cost, such as only for text messages and not for image or audio data.

The service provider 3 may in its sign-for message 10 (M-Send.conf: Fig. 5, with the expansion of the present invention: Fig. 6) prepare to be fully or partly taken over by the sender 2 and pay for the corresponding group. In the case of complete acceptance, the fields 17, 18, and 19 included in the message 10 are set to the value suggested by the sender 2, or set to a smaller value in the case of partial acceptance. In addition, the sign-for message 10 may also include a field 22 (not shown) addressed by, for example, 0×1A (decimal: 26), in which information about the expected data from the service provider is stored. (Level 3) Information on the size of the established fee. This information depends on the number of allowed responses and the delay set. It can also depend on the type of data allowed in the response.

In the case that the sender 2 takes over the charge as required by the coordination, the service provider 3 keeps the fields 17, 18, and 19 in the sending 11 (M-notification.ind: Fig. 8) to the receiver 4 as the sender 2 and notify one or more recipients 4 of the value according to the group in which the recipient 4 is addressed. Therefore, the recipient receives the following information, that is, provides the recipient with a data group 7 for download. For this data group, the recipient can free a predetermined number of responses in a certain way or within a certain period of time Send back to the original sender 2. The information may be notified to the recipient in a light (through a display device 15, such as a display) or sound.

In the field 20 addressed by 0×1B (decimal: 27) and named X-Mms-Reply-ID, the identification signal is only included in a response, so that a single-valued identification signal ID2 can be returned to the original Distribution of data groups. The original information 7 has been uniquely identified with its ID1 through another header field according to the prior art, so the additional field 20 is not required.

After using the sending 11 notification to provide the download data group 7, the recipient 4 can determine whether it wants to download the data group 7 of the service provider's level 3 in its receiving level 4, that is, in the memory 6 of its telecommunication equipment. If he makes this judgment, he sends message 13 (WSP GET.req) back to the provider.

As a result, the data transmission 14 (M-Retrieve.conf) to the recipient 4 is initiated at the service provider 3. Otherwise, the download of the data group 7 is not released (the transmission 14 is transmitted to the receiver 4). It is also possible for the recipient 4 to receive the transmission of the message at a later point in time. Transmission 14 can include newly added fields 17, 18, 19, like message 11 (Figure 10). Therefore, the charge information about the free response is not only transmitted together in the notification by the prepared transmission, but also transmitted together in the "delivery" of the data group 7, so that the charge information can also be stored or represented, for example.

The field 20 for allocation is also only included in one response, because the data group 7 has been uniquely identified (ID1).

Therefore, according to the present invention, for example, a customer who needs to place an order does not have to bear the cost. For example, parents can also send a message to their children, without the children having to pay for the requested response. This is very meaningful when the transmission must be paid directly, such as through a card with a small price. Or when the card has a small remaining value, the data 7 can also be responded to with the "response free" method.

Therefore, in the response message (Figure 2), as described above, a field 20 is also included. This field is addressed with 0×1B (decimal: 27) and the field name is X-Mms-Reply-ID. When it comes to a response that belongs to a fee takeover, the identity information ID2 stored here can correspond to the identification signal ID1 of the transmitted data 7. In this way, the transmitted data 7 and the response sent back will get the same identification signal, which can be It can be seen that it is determining the mutual distribution relationship. The response can be characterized in the same way, and it is related to whether the message 11 (M-notify.ind) and/or message 14 (M-retrieve.conf) already contains fee takeover information for one or more responses Irrelevant.

The methods described can be integrated in software to run corresponding communication standards, such as UMTS. Therefore, corresponding software is provided for the telecommunication equipment 5 and 6.

Therefore, in order to realize the settlement model "response free", MMS relay 3 must be able to undertake the following processing steps: a) It must respond to WAP messages 11 (M-Notification.ind) and 14 (M-Retrieve.conf) from WAP messages 9 (M-Send.req) header field-which encodes the number of free response MMs for each receiver group-read the required field values of different receiver groups, and according to the service provider 3 Pre-given for modification and confirmation.

b) If the identity signals of the transmitted data 7 (ID1) and response (ID2) are different from each other, the MMS relay 3 must be able to map them to each other uniquely, and monitor or modify the field 20 (X- MMS-Reply-ID).

c) After sending the response from the recipient 4 (MMS user agent B) to the MMS relay 3 by means of the WAP message 23 (M-send.req), the MMS relay must use the special identification signal to verify the Whether the response-Multimedia-Message (MMB) is actually a response to the transmitted data 7 (MMA), and whether to comply with the set time delay.

The following will describe in detail the header fields used in the WAP message. For example, assume the following scheme: MMS user agent A (sender 2) transmits MMA 7 with text and JPEG images to three receivers 4 (one "To" receiver and two "Cc" receivers). In the case of the recipient group "To", the sender 2 will take over the costs of three, and in the case of the recipient group "Cc", it will take over the costs of two response MMs (multimedia messages). But MMS service provider 3 only allows "Cc-receiver" to answer MM free of charge. One hour (=3600 seconds) is set as the time limit for taking over the fee: Nachricht 9: M-Send.req (MMS User Agent AMMS Relay 3): X-Mms-Message-Type: m-send-reqX-Mms- Transaction-ID: 10X-Mms-Version: 1.0 Date: Wed, 13 Sep 2000 12:12:19 +0100From: andreas.schmidt@sal.siemens.deTo: josef.laumen@sal.siemens.deCc: gunnar.schmidt@ sal.siemens.deBcc: Empf_nger3 @sal.siemens.de; Emp-f_nger4@sal.siemens.deX-Mms-RFF-To-Amount: 3X-Mms-RFF-Cc-Amount: 2X-Mms-RFF-Bcc-Amount: 1X-Mms-Expiry : 3600Subject: multimedia message iContent-Type: multipart/related; boundary="------_=_NextPart_ 000_"------_=_NextPart_000_Content-Type: text/plain; name="meeting.txt" Content-Transfer-Encoding: quoted-DrintableHallo Kollegen, für morgen früh um 8 Uhr ist kurzfristig ein Meeting an-gesetzt worden.

Anbei die Agenda. Antwort bitte asap.

DRINGEND! ! ! GruB, Andreas------_=_NextPart_000_Con tent-Type: image/jpeg; name= "agenda. jpg" Content-Transfer-Encoding: base64Content-ID: <1725782>

...

------_=_NextPart_000_--Sender 2 (MMS User Agent A) with the address "andreas.schmidt@sal.siemens.de" sends a message MMA7 to the address "josef.laumen@sal.siemens. The recipient 4 (MMS User Agent B) of de", where the message is composed of a text (MIME content type "plain/text") and a JPEG image (MIME content type "image/jpeg"). This copy of MMA7 ("cc") arrives at another recipient 4, that is, a user with the address "gunnar.schmidt@sal.siemens.de". The other two blind copies should be transmitted to the MMS users listed in Bcc as other recipients4. WAP message 9 (M-Send.req) such as obtaining the transaction-ID 10. Assume that the sender is going to take over the costs of three response MMs from the user (MMS user agent B, "To" field) whose address is "josef.laumen@sal.siemens.de". In addition, he also wants to take over the cost of the two answering MMs of the user "gunnar.schmidt@sal.siemens.de" ("Cc" field) and the cost of one answering MM of the other two "Bcc" recipients. This information is contained in fields 17 (X-Mms-RFF-To-Amount), 18 (X-Mms-RFF-Cc-Amount), and 19 (X-Mms-RFF-Bcc-Amount) with a gray background. The time delay (3600 seconds) of the free response of MMA has been described in field 21 (X-Mms-Expiry).

The sender 2 then receives the modified message 10 (M-Send.conf) from the MMS relay 3 in the following way: Nachricht 10: M-Send.conf (MMS RelayMMS User Agent A): X-Mms-Message -Type: m-send-confX-Mms-Transaction-ID: 10X-Mms-Version: 1.0X-Mms-Response-Status: okMessage-ID: AAAA.1111@mms-relay.siemens.deX-Mms-RFF- To-Amount: 3X-Mms-RFF-Cc-Amount: 1X-Mms-RFF-Bcc-Amount: 0X-Mms-charging-Amount: "Dieser Dienst kostet DM 5,00." MMS relay 3 uses this message 10 To confirm: WAP message 9 has been transmitted to MMS relay 3 without error. Use the transaction-ID as an identification signal, so that the message 10 is uniquely assigned to the associated M-Send.req at the sender 2 9, and thus assigned to the MMA7 sent to. In this embodiment, the MMS relay 3 has allocated the identification signal AAAA.1111@mms-relay.siemens.de to MMA7. This has been described in field 20 and corresponds to ID 1 of the prior art.

As mentioned above, the message 10 contains fields 17 (X-Mms-RFF-To-Amount), 18 (X-Mms-RFF-Cc-Amount), and 19 (X-Mms-RFF-Bcc-Amount), And whether the service provider 3 supports the service and accepts the information of the sender 2s request. In the illustrated embodiment, this situation only applies to the number of MMs responded by the "To" recipient. In the case of the "Cc" receiver, it is hoped that the original sender 2 will take over the costs of the two responses, but the service provider 3 only allows one, for example, because the sender 2 is regarded as a customer with insufficient repayment ability. In the case of the two "Bcc recipients", it is desired to take over the cost of one response, but the service provider 3 does not allow either. In this embodiment, the field X-Mms-Charging-Amount indicates the cost that the sender of MMA7 may incur for the response MMs sent and returned. Nachricht 11: M-Notification.ind(MMS Relay 3MMS User A-gent B4): In this embodiment, there is one notification for each of the four recipients 4: one for "To-receiver" and one for "Cc-receiver" and two "Bcc- receiver". Each notification contains its own transaction-ID. In all notifications, the information about the time delay is located in the field 21 (X-Mms-Expiry), and the information about the storage location of the MMA7 is located in the field X-Mms-Content-Location. a) Nachricht 11: M-Notification.ind an den "To-Empf_nger": X-Mms-Message-Type: m-notification-indX-Mms-Transaction-ID: 11X-Mms-Version: 1.0 From: andreas.schmidt @sal.siemens.deX-Mms-Message-Class: PersonalX-Mms-Message-Size: 4545X-Mms-Expiry: 3600X-Mms-Content-Location: www.server.bosch.de/mms-inbox/BBBB.2222X-Mms-RFF-To-Amount: 3

"To-Recipient" 4 knows through the entry in field 17 (X-Mms-RFF-To-Amount) that there are three answering MMs that are free of charge. b) Nachricht 11: M-Notification.ind an den "Cc-Empf_nger": X-Mms-Message-Type: m-notification-indX-Mms-Transaction-ID: 12X-Mms-Version: 1.0 From: andreas.schmidt @sal.siamens.deX-Mms-Message-Class: PersonalX-Mms-Message-Size: 4545X-Mms-Expiry: 3600X-Mms-Content-Location: www.server.bosch.de/inbox/mms/schmidt.gunnar /BBBB.2222X-Mms-RFF-Cc-Amount: 1 "Cc-Recipient" knows that there is a response MM to it free of charge through the entry in field 18 (X-Mms-RFF-Cc-Amount). c) Nachricht 11: M-Notification.ind an "Bcc-Empf_nger 2": X-Mms-Message-Type: m-notification-indX-Mms-Transaction-ID: 13X-Mms-Version: 1.0 From: andreas.schmidt@sal.siemens.deX-Mms-Message-Class: PersonalX- Mms-Message-Size: 4545X-Mms-Expiry: 3600X-Mms-Content-Location: www.server.bosch.de/mms-inbox/default-user/1234567ABCDEFG here, send to two "Bcc" recipients ( Here, for example, the M-Notification.ind for the second receiver in the group 4) is unchanged from the prior art, because the service provider 3 has rejected the sender 2s response to the "Bcc" receiver. Request for fees.

The download of MMA7 is initiated by the WSP GET command 13. Subsequently, the data 7 is sent to each recipient 4 by the MMS relay 3 in the message 14 M-Retrieve.conf.

Only the "To"-receiver will be considered below. Nachricht 14: M-Retrieve.conf (MMS Relay 3MMS User AgentB 4): X-Mms-Message-Type: m-retrieve-confX-Mms-Transaction-ID: 14 Message-ID: BBBB.2222@bosch-mms .deX-Mms-Version: 1.0 Date: Wed, 13 Sep 2000 12:12:19 +0100From: andreas.schmidt@sal.siemens.deX-Mms-Message-Class: PersonalX-Mms-Message-Size: 4545X-Mms -Expiry: 3600X-Mms-RFF-To-Amount: 3Subject: multimedia message iContent-Type: multipart/related; boundary="------_=_NextPart_000_"------_=_NextPart_000_Content-Type: text/plain; name="meeting.txt" Content-Transfer-Encoding: quoted-printableHallo Kollegen, für morgen früh um 8 Uhr ist kurzfristig ein Meeting an-gesetzt worden.

Anbei die Agenda.Antwort bitte asap.

DRINGEND! ! ! GruB, Andreas------_=_NextPart_000_Content-Type: image/jpeg; name="agenda.jpg" Content-Transfer-Encoding: base64Content-ID: <1725782>

...

------_=_NextPart_000_--If the recipient 4 of the data 7 "belongs to a second service provider, for example, the MMA 7 may have another message-ID at this time. In this example, this has been considered in the way that the value "BBBB.2222@bosch-mms.de" has been written in the field Message-ID.

As in message 11 (M-notification.ind), "To-Recipient" knows that there are three answering MMs free of charge through the entry in the field X-Mms-RFF-To-Amount.

According to the prior art, the presence of the message-ID field is optional in the WAP message 14. But in order to realize the functionality of "response free", this field is set in field 17 (X-Mms-RFF-To-Amount), 18 (X-Mms-RFF-Cc-Amount) or 19 (X-Mms-RFF-Bcc -Amount) must exist when one of them exists or is occupied.

Next, the To receiver 4 of MMA7 sends back a response MM, namely MMB, to the original sender 2. For this, use a simple modified M-Send.req 23 (Figure 2). In this embodiment, the first of three possible/prepaid responses (as described above) should be sent. Nachricht 23: M-Send.req (MMS User Agent BMMS Relay): X-Mms-Message-Type: m-send-reqX-Mms-Transaction-ID: 20X-Mms-Version: 1.0 Date: Wed, 13 Sep 2000 12:45:00 +0100From: josef.laumen@sal.siemens.deTo: andreas.schmidt@sal.siemens.deX-Mms-Reply-ID: BBBB.2222@bosch-mms.deSubject: multimedia message iiContent- Type: multipart/related; boundary="------_=_NextPart_111_"------_=_NextPart_111_Content-Type: text/plain; name="answer.txt"Content-Transfer-Encoding: quoted-printableHallo Andreas, der Termin morgen früh um 8 Uhr ist für mich ok.

GruB, Josef------_=_NextPart_111_--The original receiver 4 (MMS user agent B) informs through the existing new field 20 (X-Mms-Reply-ID) that this MMB represents a response to another MM . Which MM the response involves will be specified in the field entry "BBBB.2222@bosch-mms.de" in field 20. The entry is the message-ID of the MMA, and the MMS user agent B has used the message 14 to learn about the MMA when downloading the MMA7.

The sending request 23 (M-Send.req) of the MMS user agent B is signed by the MMS relay 3 using the message 24 (M-Send.conf). The message 24 is modified as follows: Nachricht 24: M-Send.conf (MMS RelayMMS User Agent B): X-Mms-Message-Type: m-send-confX-Mms-Transaction-ID: 20X-Mms-Version : 1.0X-Mms-Response-Status: okMessage-ID: CCCC. 3333@bosch-mms.deX-Mms-RFF-To-Amount: 2 Use the entry "X-Mms-RFF-To-Amount: 2", The MMS relay 3 can notify the MMS user agent B that he can also send two other free responses for the same MMA7.

At this time, MMS relay 3 uses WAP message 25 (M-Notification.ind) to notify the recipient of MMB, that is, the original sender of MMA7 2: Nachricht 25: M-Notification.ind (MMS Relay 3MMS User A- gent A 2): X-Mms-Message-Type: m-notification-indX-Mms-Transaction-ID: 21X-Mms-Version: 1.0 From: josef.laumen@sal.siemens.deX-Mms-Message-Class: PersonalX-Mms-Message-Size: 4800X-Mms-Content-Location: www.server.siemens.de/ in-box/mms/xyz987654321X-Mms-Reply-ID: AAAA.1111@mms-relay.siemens.de M-Notification.ind 25 can also be modified to inform the MMS user agent A that the current MM represents a response MM and which MMA7 the response refers to.

To this end, field 20 (X-Mms-Reply-ID) is inserted into M-Notification.ind 25 in the response. The field entry should be the MMA7 message-ID 1 involved in the response MMB, here: "AAAA.1111@mms-relay.siemens.de". The important thing here is that if ID 2 and ID 1 are different from each other, service provider 3 (MMS relay) is responsible for mapping ID 2 to ID 1, because MMS user agent A only knows ID 1, and MMS user agent B only recognizes ID 2. The content of field 20 (X-MMS-Reply-ID) may be different in sending 23 (M-Send.req) and 25 (M-notification.ind)-this is also the case in this example, despite the same MMB Be recognized twice.

The correct reception of the notification is then confirmed by the WAP message M-NotifyResp.req by sending the corresponding Transaction-ID of M-notification.ind together with the status message back to the MMS relay 3.

The MMS user agent A again initiates the download of MMB through the WSP GET instruction 26. Accordingly, the MMB is sent to MMS User Agent A by MMS Relay 3 in M-Retrieve.conf message 27: Nachricht 27: M-Retrieve.conf (MMS RelayMMS User Agent A): X-Mms-Message- Type: m-retrieve-confX-Mms-Transaction-ID: 24Message-ID: DDDD.4444@mms-relay.siemens.deX-Mms-Version: 1.0 Date: Wed, 13Sep 2000 12:45:00 +0100From: josef .laumen@sal.siemens.deTo: andreas.schmidt@sal.siemens.deX-Mms-Message-Class: PersonalX-Mms-Message-Size: 4800X-Mms-Reply-ID: AAAA.1111@mms-relay.siemens .deSubject: multimedia message iiContent-Type: multipart/related; boundary="------_="_NextPart_111_"------_=_NextPart_111_Content-Type: text/plain; name="answer.txt"Content-Transfer-Encoding: quoted-printableHallo Andreas , Der Termin morgen früh um 8 Uhr ist für mich ok.

GruB, Josef------_=_NextPart_111_--M-retrieve.conf 27 is also modified to inform the MMS user agent A that the current MMB represents a response MM and which MM the response refers to. To this end, field 20 (X-Mms-Reply-ID) is inserted into M-notification.ind. The entry in this field should be the message-ID 1 of the MMA involved in the response MMB.

An improved solution relates to a method for settlement of data transmission costs in a mobile wireless network, wherein at least one identification signal for transmission costs is allocated to the data, and the identification signal is transmitted to the receiver and/or the data sender . Here, in order to transmit the deadline determined by the sender on a data identification signal (such as a WAP message) predetermined for the sender and/or each recipient of the message, no new header field is provided in the data identification signal . Instead, according to the present application, the existing header field X-MMS-Expiry is preferably used in order to transmit such a time limit-within which, for example, the recipient can reply to multimedia messages sent to him free of charge. The header field has been included in WAP-209-MMSEncapsulation, Release 2000, Radio Application Protocol; WAP Multimedia Messaging Service; Message Encapsulation; MMS Proposed SCD It is specified in 1.0. According to the present application, the time limit for response or reaction determined by the sender is especially included in the WAP messages M-Send.req, M-Notification.ind and M-Retrieve.conf. Accordingly, the effective time delay of the multimedia message encoded in each implemented header field also means a time limit during which the receiver of the multimedia message can respond to the message free of charge. It is very effective and beneficial to use the existing header fields allocated to each data identification signal. However, when the existing header field is pre-occupied by other data groups, it will cause problems during the transmission of the time limit predetermined by the sender.

This problem can preferably be solved by adding at least one header field to each identification signal, and setting a time limit for responding to the identification signal in the header field.

In this way, it is possible to reliably and sufficiently ensure the simple transmission of the respective response periods set on the transmitted data identification signal in many practical situations.

As an alternative, it is also possible to insert a new header field in each data identification signal to transmit the time limit determined by the sender. In particular, at least another header field is added to the WAP messages M-send.req, M-Notification.ind and M-Retrieve.conf respectively. This can have the name X-Mms-Reply-deadline, for example. The hexadecimal code 0×1F (decimal: 127) is preferably assigned to it. The field value of the header field is preferably based on WAP-209-MMSEncapsulation, Release 2000; wireless application protocol; WAP multimedia messaging service; message encapsulation; MMS proposed SCD 1.0 and WAP-203-WSP, version on May 4, 2000; wireless Application protocol, wireless session protocol protocol; Chapter 8.4: "Header Encoding" for encoding. Using this method, a definite date or a definite time delay can be specified for the stated time limit. Preferably, this additional header field has the following division: X-Mms-Reply-Deadline(0×1F): Reply Deadline Value=Value length(Absolute-token Date-value/Relative-token Delta-seconds-value) absolute-token=<octet 128> relative-token=<octet 129>

In addition, the sender of the response multimedia message can also use the response to identify its response to the pre-obtained multimedia message regardless of the selected settlement model (for example, replay charging). In this regard, it can also be beneficial to introduce at least one other header field similar to the header field "X-MMS-Reply-ID", in which the message ID of the original multimedia message to which the response is made can be written.