Method, apparatus and software program for extending the flow of information when transmitting a message

• US 7,808,899 B2
• Filed: 02/04/2009
• Issued: 10/05/2010
• Est. Priority Date: 08/10/2001
• Status: Expired due to Term

• Current Assignee: Siemens AG
• Original Assignee: Siemens AG
• Inventors: Van Niekerk, Sabine, Trauberg, Markus, Schmidt, Andreas, Laumen, Josef
• Primary Examiner(s): Kumar; Pankaj
• Assistant Examiner(s): Jones; Prenell P
• Application Number:
  US12/365,488
• Publication Number:
  US 20090227275A1
• Time in Patent Office: 608 Days
• Field of Search: 370/352, 370/252, 370/356, 370/390, 370/338, 370/401, 370/328, 370/524, 370/238, 370/256, 370/400, 370/432, 370/408, 370/392, 379/218, 379/201, 379/265, 379/88, 379/121, 379/114, 379/225, 379/219, 725/101, 725/105, 725/86, 455/503, 455/414, 455/466, 455/566, 455/411, 455/421, 709/203, 709/223, 709/231, 709/207, 709/232, 715/838
• US Class Current: 370/230
• CPC Class Codes: H04L 51/00 User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
• CPC Class Codes: H04L 51/10 Multimedia information
• CPC Class Codes: H04L 51/58 Message adaptation for wireless communication
• CPC Class Codes: H04M 15/00 Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
• CPC Class Codes: H04M 15/06 Recording class or number of calling , i.e. A-party or called party , i.e. B-party
• CPC Class Codes: H04M 15/08 Metering calls to called party , i.e. B-party charged for the communication
• CPC Class Codes: H04M 15/10 Metering calls from calling party , i.e. A-party charged for the communication
• CPC Class Codes: H04M 15/57 for integrated multimedia messaging subsystem [IMS]
• CPC Class Codes: H04M 15/745 Customizing according to wishes of subscriber, e.g. friends or family
• CPC Class Codes: H04M 15/8083 involving reduced rates or discounts, e.g. time-of-day reductions or volume discounts
• CPC Class Codes: H04M 2207/18 wireless networks
• CPC Class Codes: H04M 2215/0108 Customization according to wishes of subscriber, e.g. customer preferences, friends and family, selecting services or billing options, Personal Communication Systems [PCS]
• CPC Class Codes: H04M 2215/0184 involving reduced rates or discounts, e.g. time-of-day reductions, volume discounts, cell discounts, group billing, frequent calling destination(s) or user history list
• CPC Class Codes: H04M 2215/2026 Wireless network, e.g. GSM, PCS, TACS
• CPC Class Codes: H04M 2215/208 IMS, i.e. Integrated Multimedia messaging Subsystem
• CPC Class Codes: H04M 2215/32 Involving wireless systems
• CPC Class Codes: H04M 2215/62 Called party billing, e.g. reverse billing, freephone, collect call, 0800 or 0900
• CPC Class Codes: H04M 3/42382 Text-based messaging services in telephone networks such as PSTN/ISDN, e.g. User-to-User Signalling or Short Message Service for fixed networks
• CPC Class Codes: H04W 4/12 Messaging; Mailboxes; Announcements
• CPC Class Codes: H04W 4/24 Accounting or billing
• CPC Class Codes: H04W 92/02 : Inter-networking arrangements

Abstract

Methods, apparatuses and software programs which are used to facilitate the flow of information in terms of functionalities in the domain of at least one service provider, in particular of a multimedia message in the UMTS, this functionality having been requested by a subscriber (for example, reply charging or recall of the message), wherein the present invention proposes transmitting information which reveals whether implicated network units in the domain of service providers support the requested functionality and proposes limiting the maximum size of the reply messages for reply charging.

Claims

1. A method for transmitting a multimedia message via a network from a transmitting application to a receiving application during a data interchange, the method comprising the steps of:

using an originator network unit and a recipient network unit being identical or different than one another and situated in a domain of one or two service providers for the transmission;

using the multimedia message, which contains information regarding readiness of the originator to accept costs for a reply message from the recipient, to request a reply charging functionality in the domain of at least one service provider; and

transmitting information regarding support of the requested reply charging functionality by the at least one of the originator network unit and the recipient network unit from one of the originator network unit and the recipient network unit to at least one of the transmitting application, the receiving application, and the other one of the originator network unit and recipient network unit.

2. A method as claimed in claim 1, wherein the information regarding the support of the requested functionality by the network unit, which is at an originator end in respect of one of the multimedia message and a reply message is sent to the recipient network unit.

3. A method as claimed in claim 1, wherein, if the requested functionality is supported by both the originator network unit and the recipient network unit, and the originator network unit is different from the recipient network unit, corresponding information is transmitted to the receiving application.

4. A method as claimed in claim 1, wherein, if the requested functionality is supported by both the originator network unit and the recipient network unit, the information regarding support of the requested functionality by the originator network unit is deleted by the recipient network unit and is not transmitted to the receiving application.

5. A method as claimed in claim 1, wherein the information regarding support of the requested functionality is transmitted from originator network unit to the transmitting application.

6. A method as claimed in claim 5, wherein a new header field with hexadecimal coding of a field name is used in the WAP message M-Send.conf, field values of the field name including the octet <

octet 128>

if the requested functionality is supported and including the octet <

octet 129>

if it is not supported.

7. A method as claimed in claim 1, wherein the information regarding support of the requested functionality is concomitantly transmitted to the receiving application by the recipient network in messages selected from at least one of a first group including MMI notification.REQ and M-notification.ind and a second group including MMI retrieve.RES and M-retrieve.conf.

8. A method as claimed in claim 7, wherein a new header field with hexadecimal coding of a field name is used in at least one of the WAP messages M-notification.ind and M-retrieve.conf, field values of the field name including the octet <

octet 128>

if the requested functionality is supported and including the octet <

octet 129>

if it is not supported.

9. A method as claimed in claim 1, wherein the receiving application evaluates the presence or absence of the information regarding support of the requested functionality by at least one of the originator network unit and the recipient network unit and outputs or refrains from outputting corresponding information for the user.

12. A method as claimed in claim 1, wherein the network is a mobile radio network.

10. A network unit in a network in a domain of a service provider, the network unit associated with at least one of a transmitting application associated with an originator and a receiving application associated with a recipient, comprising:

a part embodied at least in hardware for transmitting multimedia messages being communicated from the transmitting application to the receiving application, the message being used to request a reply charging functionality, in the domain of a service provider, the message containing information regarding readiness of the originator to accept the costs for a reply message from the recipient; and

a part embodied at least in hardware for interchanging information regarding support by the network unit of the requested reply charging functionality with at least one of the transmitting application, the receiving application, and another network unit involved in the data interchange.

11. A subscriber unit for communication in a network, comprising:

at least one receiving application associated with a recipient embodied at least in hardware for receiving multimedia messages from at least one network unit in a domain of a service provider, at least one of the messages containing information regarding readiness of an originator of the message to accept the costs for a reply message from the recipient; and

a part embodied at least in hardware for receiving and evaluating reply charging information indicating whether the at least one network unit supports reply charging functionality allowing the originator to accept the costs for a reply message from the recipient.