1. Field of the Invention
The present invention relates to a mechanism for transmitting multimedia data via a communication network. In particular, the present invention relates to a system, a sender terminal device, a receiver terminal device, a multimedia message server control element, a multimedia service system for transmitting multimedia messages via a communication network, corresponding methods and computer program products.
For the purpose of the present invention to be described herein below, it should be noted that
2. Related Prior Art
In the recent years, an increasing expansion of communication networks, e.g. of wire based communication networks, such as the Integrated Services Digital Network (ISDN), or wireless communication networks, such as the cdma2000 (code division multiple access) system, cellular 3rd generation communication networks like the Universal Mobile. Telecommunications System (UMTS), the General Packet Radio System (GPRS), or other wireless communication system, such as the Wireless Local Area Network (WLAN), took place all over the world. Various organizations, such as the 3rd Generation Partnership Project (3GPP), the International Telecommunication Union (ITU), 3rd Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), and the like are working on standards for telecommunication networks and multiple access environments.
In general, the system structure of a communication network is such that one party, e.g. a subscriber's terminal equipment, such as a mobile station, a mobile phone, a fixed phone, a personal computer (PC), a laptop, a personal digital assistant (PDA) or the like, is connected via transceivers and interfaces, such as an air interface or the like, to an access network subsystem. The access network subsystem controls the communication connection to and from the user equipment and is connected via an interface to at least one corresponding core or backbone network subsystem. The core (or backbone) network subsystem switches the data transmitted via the communication connection to a destination party, such as another user equipment, a service provider (server/proxy), or another communication network. It is to be noted that the core network subsystem may be connected to a plurality of access network subsystems. Depending on the used communication network, the actual network structure may vary, as known for those skilled in the art and defined in respective specifications, for example, for UMTS, GPRS, GSM and the like.
Generally, for properly establishing and handling a communication connection between network elements such as the user equipment and another user terminal, a database, a server, etc., one or more intermediate network elements such as control network elements, support nodes or service nodes are involved.
While the transmission of voice communication represents one important service provided by communication networks, there are several developments of improved services providing advanced functions and capabilities for the users. Such improved services comprises, for example, massaging, e-mail transfer, Internet browsing, access to a plurality of applications and services provided by service providers and the like. One example for such an improved service is the multimedia message service (MMS) which is also applicable in connection with wireless communication networks.
MMS represents a successor to the short message service (SMS) and is a service for terminals, in particular wireless terminals like mobile phones or the like, which enables the user to send multimedia content such as images, sounds, together with text messages, data and the like. Since current mobile phones provide also a digital camera function, it is more and more attractive to take photos and send to other subscribers.
When a multimedia message is to be transmitted, for example, from a sender terminal 1010 to a receiver terminal 1020 in the system according to
In other words, the MM is sent from the sender terminal 1010 by using standard Internet protocols. When the sending of the message is initiated by the user, the sender terminal 1010 communicates with the WAP gateway 1060 via the BSS 31 and GPRS CN/BB 40. The WAP gateway may translate WAP POST into a HTTP POST towards the MMSC 1070. The MMSC is the interface and router in the system and stores MM in its database (memory) and can access them. Then it decodes the message to find its destination address. The destination can be an email address or a phone number. Then the MMC transmits a notification to the receiver terminal 1020 with the help of the WAP gateway 1060. This can be done in two ways, i.e. over SMS or over IP, wherein the common way to do it is over SMS. The WAP gateway 1060 now transmits an SMS telling the receiver terminal 1020 that it has an MM to get. The receiver terminal 1020 downloads it from the MMSC using WAP GET which is translated, for example, to a regular HTTP GET by the WAP GW before it reaches the MMSC.
A different development for enhancing services of communication networks is a so-called multimedia content delivery service concept, also called media charger service concept. Media charger service builds on an efficient delivery of large content files to mobile phones based on subscriptions. The media charger concept utilizes network resources efficiently and provides the consumers with a pleasant user experience. In the media charger service, content is organized into content channels, to which the consumers are able to subscribe based on their personal interests. To make the service as fluent as possible from the end-user perspective, the content delivery process is highly automated: files are automatically delivered to the client application in the consumers' handsets as new content is published in the server. The service can also be configured to focus the file downloads on a certain time window, for example, to enable a service model, in which file transfers take place only during off-peak hours of the underlying network. After receiving a piece of content, a consumer can consume it wherever and whenever he wants to. The media charger service operates over cellular packet networks. The system is basically content type independent. Based on the service configuration, charging can be performed in two different ways (i.e. based on CDRs (Charging Data Record) or using SMS (Short Message Service)).
As shown in
A HTTP access interface enables the HTTP-based communication between the media charger server 500 and clients. This interface is used for delivery of content and related control messages. Clients poll periodically updates to channel hierarchy/item information via this interface. As a reply, the download server instructs the client to download the correct content files (on the subscribed channels) and to remove the old content files from the terminal if necessary. Content downloading is performed using a pull mechanism: the client requests content downloading from the server. The download server 500 includes support for recovering from interrupted download sessions. To ensure only legal clients have access to the service, a subscriber is authenticated whenever his client communicates with the server. The communication may be performed with XML-based protocol over HTTP (or HTTPS depending on the configuration).
In
In U.S. patent application Ser. No. 10/803,684 a media and recovery system is disclosed which is similar to the media charger system described above.
As mentioned above, the MMS is used to transmit multimedia messages between sender and receiver. However, in the currently existing MMS systems, it is only possible to send files in range of few hundred kilobytes, and the size is not going up to mega bytes fast, or over 10 MB. Since the size of MMS messages to be transmitted will increase, for example due to the increased quality and thus size of pictures to be transmitted, such a limitation of the data size may affect service quality adversely.
It is an object of the invention to provide an improved system, a sender terminal device, a receiver terminal device, a multimedia message server control element, a multimedia service system for transmitting multimedia messages via a communication network, as well as corresponding methods and computer program products by means of which the transmission of large multimedia messages, i.e. of messages having a larger data size, is possible.
This object is achieved by the measures defined in the attached claims.
In particular, according to one aspect of the proposed solution, there is provided, for example, a method of transmitting a multimedia message, comprising the steps of processing a multimedia message to be transmitted by dividing the multimedia message into at least a first message portion and a second message portion, transmitting the first message portion to a multimedia message service control element, transmitting the second message portion to a media charger server element, notifying a receiver terminal about the transmission of the multimedia message, requesting the transmission of the first message portion from the multimedia message service control element to the receiver terminal and requesting the transmission of the second message portion from the media charger server element to the receiver terminal.
Furthermore, according to one aspect of the proposed solution, there is provided, for example, a system for transmitting a multimedia message, the system comprising sender terminal comprising a media charger proxy functional means which is configured to process a multimedia message to be transmitted by dividing the multimedia message into at least a first message portion and a second message portion, a multimedia message service control element configured to receive the first message portion, a media charger server element configured to receive the second message portion, a message transmission system configured to notify a receiver terminal about the transmission of the multimedia message, wherein the receiver terminal comprises a media charger proxy functional means which is configured to perform at least one of requesting the transmission of the first message portion from the multimedia message service control element to the receiver terminal and requesting the transmission of the second message portion from the media charger server element to the receiver terminal.
According to further refinements, the proposed solution may comprise one or more of the following features:
Moreover, according to one aspect of the proposed solution, there is provided, for example, a method of transmitting a multimedia message, comprising the steps of processing a multimedia message to be transmitted, generating and providing a unique identifier for the multimedia message, transmitting the multimedia message to a media charger server element, transmitting the multimedia message to a multimedia message service control element, notifying a receiver terminal about the transmission of the multimedia message when the multimedia message is received by the multimedia message service control element, requesting the transmission of the multimedia message from the media charger server element to the receiver terminal obtaining the multimedia message from the multimedia message service control element at the media charger server element, and transmitting the multimedia message from the media charger server element to the receiver terminal. There is also provided a corresponding system for transmitting a multimedia message.
According to further refinements of this aspect of the invention, the proposed solution may comprise one or more of the following features:
Furthermore, according to one aspect of the proposed solution, there is provided, for example, a terminal device configured to send a multimedia message in a communication system, the communication system comprising a multimedia message service control element and a media charger server element, wherein the terminal device comprises a media charger proxy functional means which is configured to process the multimedia message to be transmitted by dividing the multimedia message into at least a first message portion and a second message portion, to transmit the first message portion to the multimedia message service control element, and to transmit the second message portion to the media charger server element. There are also provided a corresponding method and a corresponding computer program product.
According to further refinements of this aspect, the proposed solution may comprise one or more of the following features:
In addition, according to one aspect of the proposed solution, there is provided, for example, a terminal device configured to receive a multimedia message in a communication system, the communication system comprising a multimedia message service control element, a media charger server element, and a message transmission system, wherein the terminal device comprises a media charger proxy functional means which is configured to receive a notification of the message transmission system about the transmission of a multimedia message, to request the transmission of a first message portion from the multimedia message service control element, to request the transmission of a second message portion from the media charger server element to the receiver terminal, and to combine the first message portion and the second message portion for obtaining the multimedia message transmitted (for example on the basis of a unique identifier included in each of the first message portion and the second message portion). Furthermore, there are also provided a corresponding method and a corresponding computer program product.
According to further refinements of this aspect, the proposed solution may comprise one or more of the following features:
Moreover, according to one aspect of the proposed solution, there is provided, for example, a multimedia message service control element of a communication system for transmitting a multimedia message, the communication system comprising a sender terminal comprising a media charger proxy functional means, a receiver terminal comprising a media charger proxy functional means, a media charger server element, and a message transmission element, wherein the multimedia message service control element is configured to receive from the sender terminal a first message portion related to the multimedia message, to notify, via the message transmission system, the receiver terminal about the transmission of the multimedia message, to receive a request from the receiver terminal for transmitting the first message portion, and to transmit the first message portion related to the multimedia message to the receiver terminal. There are also provided a corresponding method and a corresponding computer program product.
According to further refinements of this aspect, the proposed solution may comprise one or more of the following features:
In addition, according to one aspect of the proposed solution, there is provided, for example, a multimedia service system for transmitting a multimedia message in a communication system, the communication system comprising a sender terminal comprising a media charger proxy functional means and a receiver terminal comprising a media charger proxy functional means, wherein the multimedia service system comprises a media charger server element, a multimedia message service control element and a message transmission element, wherein the multimedia service system is configured to receive from the sender terminal a first message portion at the multimedia message service control element and a second message portion at the media charger server element, the first and second message portions being related to the multimedia message, to notify, via the message transmission system, the receiver terminal about the transmission of the multimedia message, to receive, at the multimedia message service control element, a request from the receiver terminal for transmitting the first message portion, to transmit the first message portion related to the multimedia message and comprising the unique identifier to the receiver terminal, to receive, at the media charger server element, a request from the receiver terminal for transmitting the second message portion, and to transmit the second message portion related to the multimedia message to the receiver terminal. There are also provided a corresponding method and a corresponding computer program product.
According to further refinements of this aspect, the proposed solution may comprise one or more of the following features:
By virtue of the proposed solutions, the following advantages can be achieved, for example:
The above and still further objects, features and advantages of the invention will become more apparent upon referring to the description and the accompanying drawings.
In the following, embodiments of the present invention are described with reference to the drawings.
The general idea of the present invention is to implement media charger system in an multimedia message system in order to allow a reliable and rigid delivery of large files attached, for example, on the MMS messages. For this purpose, a proxy, i.e. a so-called media charger MMS proxy application, is implemented in a terminal devices (and optionally in network elements). The media charger MMS proxy application is used to process messages, such as multimedia messages, by scanning them and by modifying them (i.e. the content or structure thereof) when the MMS message is transmitted and received. Thus, it is possible to separate and reroute content (i.e. attached files of the MMS message) to the media charger server, wherein at the receiving side the content is received and combined, for example, with user written message and the like. Preferably, a WAP GET operation is used for this purpose.
In other words, a media charger system is implemented between terminals and MMSC, and content transmission and recovery systems from the media charger system are implemented to a messaging system such as a MMS system. Preferably, the whole transmission process according to the present invention is transparent for a user, i.e. terminal users see the system as a normal MMS system.
A first embodiment will be explained with reference to
Referring to
According to
Furthermore, a multimedia content control server/element which is referred to hereinafter as media charger (MC) server 50 as a media charger server element is provided. It is to be noted that the term “media charger” is used only as an explanatory expression and comprises all network elements or servers which may act as a multimedia content control server. The MC server 50 is connected with the network, for example, via the WAP gateway 60.
Terminal devices 10 and 20 located in the communication network act as a sender terminal 10, which transmits the multimedia message, and as a receiver terminal 20 to which the multimedia message is to be transmitted. Both terminal devices are provided respectively with a media charger multimedia message service (MC) proxy functionality or functional means 11, 21. The MC proxy functionality is used for processing the multimedia message at the sending side and for processing messages received at the receiving side, respectively.
In
On the other hand,
The MMSC 70 comprises a processor/control means 71, such as a CPU or the like, which is connected to a transceiver unit 72, such as a interface to an IP based network or the like. The transceiver unit 72 connects the MMSC 70 for example to the WAP gateway 60. Also other connections, such as to external networks, other MMSCs, an e-mail application and the like can be provided by the transceiver unit 72. Furthermore, a memory 73, such as a RAM, a ROM, a hard disk and the like is provided which is connected to the processor 71. The memory 73 stores control programs and the like, serves as a working area of the processor 71, is used for storing messages or message portions received via the transceiver 71, and the like.
The MC server 50 comprises a processor/control means 52, such as a CPU or the like, which is connected to a transceiver unit 53, such as a interface to an IP based network or the like. The transceiver unit 53 connects the MC server 50 for example to the WAP gateway 60. Furthermore, a memory 54, such as a RAM, a ROM, a hard disk and the like is provided which is connected to the processor 52. The memory 54 stores control programs and the like, serves as a working area of the processor 52, is used for storing messages or message portions received via the transceiver 53, and the like.
As an option, the processor 52 is provided with a MC proxy functionality or application 51. This will be described below in greater detail. The MC proxy functionality 51 may provide a connection to the MMSC 70, i.e. to the processor 71 thereof, in order to transmit instructions and data. The connection between the MC proxy functionality 51 and the processor 71 can be directly via a corresponding network part, e.g. an IP based network, or via the transceivers 53 and 72, i.e. via the WAP gateway 60.
Even though the MMSC 70 and the MC server 50 are shown in
Referring to
If it is decided in step S120 that the predetermined condition is not fulfilled, the multimedia message is not intercepted by the MC proxy functionality 11 and normally transferred (step S125), as shown for example in
On the other hand, if the decision in step S120 is YES, the multimedia message is intercepted and further processed by the MC proxy functionality 11 in step S130.
In step S130, the multimedia message is divided by the MC proxy functionality 11. This means that the MC proxy functionality 11 divides the message into a first message portion and a second message portion. The first message portion comprises, for example, a header indicating communication information which are obtained from the original multimedia message. The communication information may comprise at least one of a written message part, a media charger tag, a network address of the media charger server element, a unique ID (described later) and the like. The second message portion includes in particular the content data of the multimedia message, and/or in addition also text, e.g. a text message, and/or a unique ID (described later). It is to be noted that the MC proxy functionality 11 may divide the multimedia message into more than two message portions, in particular when the multimedia message includes more than one content file. The content data can be also divided in one or more parts, especially if the content data or file is large. However, the parts are handled further in the same way and like the single second message portion mentioned above. Furthermore, the MC proxy functionality 11 generates (step S140) a unique identification element (ID) which is attached to the multimedia message to be transmitted and thus to the first and second message portions. The unique ID is included in the first and the second (or more) message portions, respectively, for binding the content data and the header together.
After the processing of the MC proxy functionality 11 in step S130 is completed, the first message portion (i.e. the header) is transmitted (step S150) from the sender terminal device 10 (i.e. by the MC proxy functionality 11) to the MMSC 70. For example, the transmission can be effected by means of a WAP POST operation via BSS 31, the GPRS CN/BB 40 and the WAP gateway 60. On the other hand, the one (or more) of the second message portions is transmitted to the MC server 50, for example by means of a HTTP PUT operation via BSS 31, the GPRS CN/BB 40 and the WAP gateway 60. It is to be noted that both the first and the one or more of the second message portions include the unique ID.
When the MMSC 70 receives the first message portion, it retrieves communication information to obtain the destination and transmits a notification to the destination (step S160), i.e. to the receiver terminal device 20, in order to notify the transmission of a multimedia message. The notification can be transmitted as a WAP notification over SMS to the receiver terminal device, for example, via the WAP gateway 60 to the SMSC 35, where a preset short message indicating the MMS receipt is prepared and sent to the terminal device 20 via the MSC 30 and the BSS 32. Alternatively, the MMSC 70 can also notify the receiver terminal device 20 by means of another signaling mechanism, such as an IP based signaling. As a further alternative, a notification to the destination (compare step S160), i.e. to the receiver terminal device 20 in order to notify the transmission of a multimedia message is transmitted after the MC server 50 has received the (one or more) second message portion. This will be further described below in connection with
In any case, if it is determined by the receiver terminal device side, e.g. by the MC proxy functionality 21, that the message is transmitted by the sender terminal device 10 by using the mechanism according to the present invention, a request for transmitting the first portion is sent, for example, by the MC proxy functionality 21 to the MMSC 70 (step S170). This request is for example a WAP GET request transmitted via the WAP gateway 60. Furthermore, a request for transmitting the second portion is sent, for example, by the MC proxy functionality 21 to the MC server 50. The second request is normally transmitted when the first portion is received at the MC proxy functionality 21 since from this portion the address of the MC server 50 is retrieved. The second request for transmitting the second message portion is transmitted by means of a HTTP GET request, for example, either directly to the MC server 50 through an IP network, or via the WAP gateway 60.
In step S180, both the first and the second message portion are received at the MC proxy functionality 21. Then the MC proxy functionality 21 is able to combine the first and the second portion by means of the unique ID in order to obtain the complete multimedia message comprising all the header information and content data (step S190), and the multimedia message can be displayed to the user.
It is to be noted that the MC server 50, after receiving the request from the MC proxy functionality 21, may postpone the transmission of the second message portion until an off-peak time, or the MC proxy functionality 21 sends the request for transmitting the first and/or the second message portion postponed. The postponement of the transmission of the multimedia message can also be initiated by the MC Proxy functionality 11 of the sender terminal equipment, based, for example, on settings for the terminal device 10. In addition, when the transmission of in particular the second message portion is interrupted, the transmission can be reassumed at the interruption position when the interruption cause is not present anymore.
In
First, when the transmission of the multimedia message is initiated by a WAP POST operation including the MSISDN and the message (message M1), the MC proxy functionality checks the message to be transmitted, as described above. For example, if the size of the MMS message is bigger than a threshold size, the message is divided to a content (second message portion), such as a file attachment, and to a header (first message portion), such as a message header (i.e. written message). Furthermore, unique message identifiers are created and added for the content and the header wherein that identifiers bind the content and header together. Then, the content with the identifiers is transmitted to the MC server by means of a HTTP PUT operation (message M3), while the header with the identifiers is transmitted by WAP POST operation via the WAP GW to the MMSC (messages M2 and M5). The MC server can send one or more notifications to the MC proxy functionality in order a acknowledge the receipt of the content, for example.
When the MMSC receives the message M5 (i.e. the header with the identifiers), it determines the destination (i.e. subscriber B), it transmits the notification with said message identifiers about the MMS message to a subscriber B terminal. This is performed by a WAP POST message to the WAP GW (message M6), which in turn transmits a message M7 indicating a WAP notification over SMS to the SMSC, and the SMSC sends a short message or the like including the WAP notification the MC proxy functionality of the receiver side (message M8).
When the MC proxy B receives the message M8, it informs the user via the terminal device about the WAP notification (message M9) and receives an instruction to retrieve the message by means of an WAP GET operation initiated by the subscriber B terminal (message M10). Then, the MC proxy B sends a request in form of the WAP GET request with the message identifiers via the WAP GW to the MMSC (messages M11 and M12) whereupon the MMSC transmits back the header the header of the MMS message including the message identifiers (messages M13, M14). Then, the MC proxy B sends a request to transmit the content to the MC server by means of a HTTP GET message including the message identifiers (message M15). The MC server transmits from the MC server the content of the MMS message including the message identifiers to the MC proxy B (message M16), and the MC proxy B confirms the (complete) receipt with message M18. Furthermore, after combining the header and the content, the WAP GET operation with the subscriber B terminal is completed by means of message M17 where the message is provided to the terminal.
In the following, a further modification of the first embodiment is described with reference to
The signaling diagram according to
In the example according to
Therefore, a new message M55 is introduced in the system which informs the MMSC that the whole content is now received at the MC server and is available for download. This means that the MC charger is configured to recognize that the full content is received (by means of message path M3), and then to send the message M55 to the MMSC.
On the other hand, it is preferable that the MMSC is configured to await the message M55 from the MC server before the notification message flow (messages M6 to M8) is started. In other words, only after this message M55 is received by the MMSC, the notification signal M6 is sent to WAP GW which further initiates notification M8 as described above.
Additionally, the signal M55 may include information when the content at the MC server is available for an off-peak downloading. By means of such an information there are several options available for the further processing:
1) alternatively, the notification message flow (messages M6 to M8) is sent when the off-peak time begins
2) the notification message M8 to the MC proxy B (receiver terminal device or subscriber B) includes information about the off-peak time, that is presented to the user, so that user may wait for that specific time for downloading (i.e. message M10). Alternatively, the user may ignore this and initiate downloading immediately after receiving the notification M8. Furthermore, as another alternative, the MC proxy B may be configured to automatically initiate the downloading at off-peak time or immediately, depending on the settings in the MC proxy B (subscriber B).
In
The general architecture of the communication system of the second embodiment is similar to that according to that of the first embodiment shown in
One major difference of the second embodiment to the first embodiment is that the MMS message is not divided by the MC proxy functionality 211 in the sender terminal device 210. This means that the content, such as a file attachment, of a message is also transmitted to the MMCS 270, whereas in the first embodiment the MMS message is divided to the header and the content and the content is only and directly transmitted to the MC server.
The transmission of a message from the sender terminal device 210 to the receiver terminal device 220 according to the second embodiment is described in the following.
When the transmission of the MMS message is initiated in the sender terminal device 210, the MC proxy functionality 211 checks whether the message is to be intercepted, i.e. whether the message is to be send in a normal way or by means of the operation involving the media charger system. The interception is executed, for example, in one of the following situations: always (e.g. according to a pre-setting by the user or the network operator); when the MMS is above a certain size threshold value (e.g. >500 kB); never (e.g. according to a pre-setting by the user or the network operator).
In case the MC proxy functionality 211 decides that there is no reason for an interception of the message, it is followed the normal MMS message transmission procedure (indicated by the message flow M201B).
On the other hand, when the message is to be intercepted and thus to be processed by means of the media charger portion of the network, MC proxy functionality 211 adds one or more tags or identifiers to one or more of the existing fields in the message. Then, the MC proxy functionality 211 sends/uploads the message (including the tags or identifiers) to the MC server 250 via the BSS 31, the GPRS CN/BB 40 (see message M201A). This sending/uploading can happen immediately or delayed (e.g. night time), depending on the settings.
Alternatively to the above, the MC proxy functionality 211 does not add one or more tags or identifiers but is only responsible for sending/uploading the message to the MC server 250. In this case, either the MC server 250 or the MMSC 270 creates and adds one or more tags or identifiers to one or more of the existing fields in the message when the message is received.
When MC server 250 receives the MMS message it forwards it to the MMSC 270. The MMSC 270 receives the MMS massage like any normal MMS message sent. The transmission from the MC server 250 to the MMSC 270 can be performed either through the WAP gateway 60 by means of a WAP POST operation (message M202), or directly to MMSC 60 by means of a HTTP POST operation (message M203).
The MMSC 270 processes the MMS message received from the MC server 250 in a normal way, i.e. the MMSC 270 sends out a notification message to the receiver terminal device 220, for example by means of a short message via the SMSC 35 (message M204).
When a terminal with MC proxy capabilities, i.e. the receiver terminal device 220 having the MC proxy functionality 221, receives a MMS notification, e.g. via the SMSC 35, the MC proxy functionality 221 intercepts it. The interception may be based on one of the following settings or situations: always (e.g. according to a pre-setting by the user or the network operator); when the MMS is above certain size threshold value (e.g. >500 kB); the MMS is “tagged” by the MC proxy functionality (i.e. MC tag or identifiers) in the sending end (MC proxy functionality 211); the MMS is ‘tagged’ by the MC server 250 or by the MMCS 270 (in case the MC proxy functionality 211 has not included such tags or identifiers); never (e.g. according to a pre-setting by the user or the network operator).
When the MC proxy functionality 221 intercepts the MMS message transmission, it sends, for example, a WAP GET message to the MC server 250 (message M205). Upon reception of the WAP GET message, the MC server requests the MMS message from MMSC 270, either via the WAP gateway 60 by using a WAP GET request (message M206) or directly from the MMSC 270 by using a HTTP GET request (message M207).
After receiving the MMS message at the MC server 250, the MMS message can be delivered to the terminal by means of media charger methods described above. Preferably, the MC proxy functionality 221 of the receiver terminal device 220 is configured to put the MMS message received from the MC server 250 to a correct folder for a “normal” MMS reception so that the user does not feel any differences to the normal MMS transmission.
In the following, third to seventh embodiments according to the present invention are described in connection with signaling diagrams shown in
In
When the transmission of the message is initiated (message M301) at the sender terminal device (subscriber A), the following steps are equivalent to those described in
In message M308, the notification from the MMSC (WAP notification over SMS) is sent to the receiver terminal device (subscriber B), wherein the notification includes also information necessary for finding the MC server and for identifying the MMS message (i.e. in particular the second message portion).
When the MC proxy functionality B informs the user (message M309) and receives the instruction to get the MMS message (message M310, WAP GET), the MC proxy functionality B sends a HTTP GET message (message M311) directly to the MC server at the same time when the WAP GET request (messages M312 and M313) is sent to the MMSC. As mentioned above, in this case it is necessary that the WAP notification includes all the information needed for the direct HTTP GET. The MC proxy functionality B receives the first message portion (header, messages M314 and M315) via the WAP GET operation from the MMSC and the second message portion (content, message M316) via HTTP GET operation from the MC server similar to the first embodiment. The further processing of notifying the MC server (message M318) and combining and displaying the MMS message (message M317) are also similar to the first embodiment.
In
When the transmission of the message is initiated (message M401) at the sender terminal device (subscriber A), the following steps are equivalent to those described in
In message M408, the notification from the MMSC (WAP notification over SMS) is sent to the receiver terminal device (subscriber B), wherein the notification includes also information necessary for finding the MC server, for identifying the MMS message (i.e. in particular the second message portion) and information about the MMSC (address information, identifier or the like).
When the MC proxy functionality B informs the user (message M409) and receives the instruction to get the MMS message (message M410, WAP GET), the MC proxy functionality B sends a HTTP GET message (message M411) directly to the MC server. As mentioned above, in this case it is necessary that the WAP notification includes all the information needed for the direct HTTP GET.
The MC server sends a WAP GET message to the MMSC (message M412) at the same time when transmitting HTTP GET to the MC proxy functionality B of the receiver terminal device (subscriber B) (message M415). Therefore, the MC server needs to know via which MMSC the MMS message is routed. This information is received by the HTTP GET message from the MC proxy functionality B, for example. The MMSC transmits the first message portion to the receiver terminal side (messages M413, M414) upon receipt of the WAP GET message from the MC server (message M412).
The MC proxy functionality B receives the first message portion (header, message M414) via the WAP GET operation from the MMSC and the second message portion (content, message M415) via HTTP GET operation from the MC server similar to the first embodiment. The further processing of notifying the MC server (message M417) and combining and displaying the MMS message (message M416) are also similar to the first embodiment.
In
When the transmission of the message is initiated (message M501) at the sender terminal device (subscriber A), the following steps are equivalent to those described in
In message M508, the notification from the MMSC (WAP notification over SMS) is sent to the receiver terminal device (subscriber B), wherein the notification includes also information necessary for finding the MC server, and for identifying the MMS message (i.e. in particular the second message portion).
When the MC proxy functionality B informs the user (message M509) and receives the instruction to get the MMS message (message M510, WAP GET), the MC proxy functionality B sends a WAP GET request to the MMSC via the WAP GW (messages M511 and M512). When the MMSC receives the WAP GET message, it sends a HTTP GET message (message M513) to the MC server. Therefore, the MC server needs to know via which MMSC the MMS message is routed. This information is received by the WAP GET message from the MC proxy functionality B, for example.
The MC server sends a HTTP GET to the MC proxy functionality B of the receiver terminal device (subscriber B) (message M516) while the MMSC transmits the first message portion to the receiver terminal side (messages M514, M515) upon receipt of the WAP GET message from the MC proxy functionality.
The MC proxy functionality B receives the first message portion (header, message M515) via the WAP GET operation from the MMSC and the second message portion (content, message M516) via HTTP GET operation from the MC server similar to the first embodiment. The further processing of notifying the MC server (message M518) and combining and displaying the MMS message (message M517) are also similar to the first embodiment.
In
When the transmission of the message is initiated (message M601) at the sender terminal device (subscriber A), the MC proxy functionality A in the sender terminal device sends the HTTP PUT directly to the MC server (message M602). The MC server sends, when the HTTP PUT message is received, one or more notifications to the MC proxy functionality A for acknowledgement and the like, and transmits the first message portion (header, unique ID and the like) by means of a WAP POST operation to the WAP gateway (message M604). For this purpose, the MC server is provided with a own MC proxy functionality, which is shown in
From the WAP GW, the WAP POST, i.e. the second message portion, is forwarded to the MMSC (message M605) which then performs the steps defined in the first embodiment for notifying the receiver terminal device side about the message (messages M606 to M608).
The following steps may be equivalent to those described in
In
When the transmission of the message is initiated (message M701) at the sender terminal device (subscriber A), the MC proxy functionality A in the sender terminal device sends the HTTP PUT directly to the MC server (message M702). The MC server sends, when the HTTP PUT message is received, one or more notifications to the MC proxy functionality A for acknowledgement and the like, and transmits the first message portion (header, unique ID and the like) by means of a WAP POST operation to the MMSC (message M704). For this purpose, the MC server is provided with a own MC proxy functionality, which is shown in
The MMSC sends the WAP POST to the WAP gateway (message M705) which then further performs the steps defined in the first embodiment for notifying the receiver terminal device side about the message (messages M706 and M707).
The following steps may be equivalent to those described in
It is to be noted that the embodiments described above can also be combined. In particular the measures defined by the first embodiment or the modified example of the first embodiment and the third to seventh embodiments can be suitably combined as it is apparent to those skilled in the art.
Additionally, also the measured defined in connection with the second embodiment can be suitably combined with those of the other embodiments. As a corresponding explanatory example, in the following, a case is described on the basis of
As mentioned above, in
The general architecture of the communication system of the this embodiment is similar to that according to that of the first embodiment shown in
One major difference of the this embodiment, that relates to the first embodiment, to the second embodiment to which
When the transmission of the MMS message is initiated in the sender terminal device 210, the MC proxy functionality 211 checks whether the message is to be intercepted, i.e. whether the message is to be send in a normal way or by means of the operation involving the media charger system. The interception is executed, for example, in one of the following situations: always (e.g. according to a pre-setting by the user or the network operator); when the MMS is above a certain size threshold value (e.g. >500 kB); never (e.g. according to a pre-setting by the user or the network operator).
In case the MC proxy functionality 211 decides that there is no reason for an interception of the message, it is followed the normal MMS message transmission procedure (indicated by the message flow M201B).
On the other hand, when the message is to be intercepted and thus to be processed by means of the media charger portion of the network, MC proxy functionality 211 divide the MS message to the header part and one or more content parts and adds one or more tags or identifiers to one or more of the parts in the message. Then, the MC proxy functionality 211 sends/uploads the header part (including the tags or identifiers) to the MMSC server 270 via the BSS 31, the GPRS CN/BB 40 (see also message M201B). Then, the MC proxy functionality 211 sends/uploads the content (including the tags or identifiers) to the MC server 250 via the BSS 31, the GPRS CN/BB 40 (see message M201A). This sending/uploading can happen immediately or delayed (e.g. night time), depending on the settings.
Alternatively to the above, the MC proxy functionality 211 does not add one or more tags or identifiers but is only responsible for sending/uploading the message to the MC server 250. In this case, either the MC server 250 or the MMSC 270 or both creates and adds one or more tags or identifiers to one or more of the existing parts in the message when the message is received.
The MMSC 270 processes the MMS message header part received from the MC proxy 211 in a normal way, i.e. the MMSC 270 sends out a notification message to the receiver terminal device 220, for example by means of a short message via the SMSC 35 (message M204).
When a terminal with MC proxy capabilities, i.e. the receiver terminal device 220 having the MC proxy functionality 221, receives a MMS notification, e.g. via the SMSC 35, the MC proxy functionality 221 intercepts it. The interception may be based on one of the following settings or situations: always (e.g. according to a pre-setting by the user or the network operator); when the MMS is above certain size threshold value (e.g. >500 kB); the MMS is “tagged” by the MC proxy functionality (i.e. MC tag or identifiers) in the sending end (MC proxy functionality 211); the MMS is ‘tagged’ by the MC server 250 and/or by the MMCS 270 (in case the MC proxy functionality 211 has not included such tags or identifiers); never (e.g. according to a pre-setting by the user or the network operator).
When the MC proxy functionality 221 intercepts the MMS message transmission, it sends, for example, a WAP GET message to the MMSC server 270 (message M208). Upon reception of the WAP GET message, the MMSC server 270 transmits the MMS message header part to the MC proxy functionality 221, via the WAP gateway 60 by using a WAP GET request (message M209).
After receiving the MMS message header part the MC proxy 211 may request the MMS message content from MC server 250 by using HTTP GET via link M205. This is similar to that described in the second embodiment, for example, so that a further detailed description thereof is omitted here.
In
In
It is to be noted that even though not shown in
In the present embodiment, the general idea is to make message exchange to be more comfortable, for example dating to be more comfortable, and to increase the information received from the respective opponent. This is achieved by allowing both sides to create personal information and personal media files, where are both own features as well as what kind of features a party is looking for from the possible opponent. When additional information is set there, it is possible to get solutions, which are matching (matching can be presented, for example, as procent figures).
A possible use of a media charger system is to use a Dating solution to record videogreetings etc. and to send those to the server. Then, it is possible to “subscribe” the persons information as a channel or sub-channel and every time there will be more content, then automatically this information is sent to the terminal device.
By using the measures defined in the present invention, it is possible that during the registration process, a personal ID is available. So, the greetings can be set to be visible to a) all subscribers (terminal devices 200 and 900), b) set of subscribers based on ID (e.g. only left and right terminal device 900) or c) just one dedicated subscriber (e.g. only leftmost terminal device 900). This means that in the messaging network, there are a plurality of generic and personal introductions and greetings.
The concept of the present embodiment is to use the media charger server 300 as a two direction communication channel with grant/deny permission basis. Furthermore, the media charger server 300 is used to handle automatically the distribution list, for example after subscription or inventing based on handling (both user or host can start the discussion/communication chain). At the same time, the whole system can be managed, measured, handled with secure manners and be extreme personal to create highest possible user experience without loosing anything from usability. In addition, a manual acceptance or auto acceptance can be used, for example, based on a set of rules to decide who can subscribe the personal videogreetings. Thus, it is possible to make the system more “personal”, while additionally a more flexible and more usable massaging performance than in a conventional MMS-service providing a real communication solution for two- or multidirectional communication.
The personal information and personal media files may be transmitted preferably as MMS messages via MMS and media charger systems. This means, that transmitting and also receiving devices requires special media charger proxy functionalities, like those described above. If the personal media files (content part) are large (larger than, for example, a predetermined threshold value), they may be routed via the media charger system, while a header part of the MMS message is routed via the MMS system (MMSC).
There are several benefits, which are affecting the whole system. First, the whole system can be managed, measured, handled with secure manners and be extreme personal to create highest possible user experience without loosing anything from usability, at the same time. Furthermore, it is possible to use a manual acceptance or an automatic acceptance based on a set of rules to decide who can subscribe the personal videogreetings. The system is more personal, for flexible and more usable than a conventional MMS-service providing real communication solution for two- or multidirectional communication. From the other systems, who would the host know, it is possible to receive information about how many other subscribers/terminals has check his/her greeting or announcement. It is to be noted that the system according to this embodiment is able to get information in real-time.
It is to be noted that, even though the foregoing embodiments are mainly directed to the transmission of a multimedia message, the measures defined in the present invention are also applicable to other types of messages to be transmitted via a communication network, in particular to those messages having a larger file attachment or a large size. The actual size of the message or attachment for which the present invention is preferably to be executed may vary, for example, in dependence of the communication network concerned. Furthermore, the described network elements, such as the MC server or the MMSC, may be different to those used in another application of the present invention as long as the basic functions like message forwarding and processing are similar.
Moreover, it is obvious that the transmission paths defined in the preceding embodiments, such as the WAP, SMS, HTTP or IP based transmission paths, can be replaced by other present or future types of transmission paths.
It is to be further noted that the measures defined in the preceding embodiments are implementable by means of a computer program product, such as a software program or the like, which can be directly loaded into the internal memory of a computer which in turn executes the processing steps and functions defined above. Thus, the computer program product causes the computer or parts of the computer to act, for example, as the MMSC, the MC server, the terminal device, the MC proxy functionality and the like described above. Furthermore, the computer program product may comprise a computer-readable medium on which corresponding software code portions are stored.
As described above there are provided a method and system for transmitting a multimedia message, wherein a multimedia message to be transmitted is processed by dividing the multimedia message into at least a first message portion and a second message portion. The first message portion is transmitted to a multimedia message service control element, and the second message portion is transmitted to a media charger server element. A receiver terminal is notified about the transmission of the multimedia message The transmission of the first message portion from the multimedia message service control element to the receiver terminal is requested, and the transmission of the second message portion from the media charger server element to the receiver terminal is requested. At the receiver terminal the first message portion and the second message portion are combined for obtaining the multimedia message transmitted.
It should be understood that the above description and accompanying figures are merely intended to illustrate the present invention by way of example only. The preferred embodiments of the present invention may thus vary within the scope of the attached claims.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/IB2005/001798 | 6/24/2005 | WO | 00 | 2/29/2008 |