Method, apparatus and system for processing multimedia messages
Claim Score by NHIP
Abstract
The present invention provides a method, apparatus and system for processing a multimedia message wherein a multimedia message is received (<bold>1202</highlight>) and it is determined whether the multimedia message should be processed using a customized process (<bold>1204</highlight>). If the multimedia message should be processed with the customized process, the present invention retrieves one or more customized processing instructions from a database (<bold>1208</highlight>) and processes the multimedia message using the one or more customized processing instructions (<bold>1210</highlight>). If, however, the multimedia message should not be processed using the customized process, the present invention processes the multimedia message using a standard process (<bold>1206</highlight>). This method can be implemented using hardware or a computer program embodied on a computer readable medium wherein each block represents a code segment.

Term
Term ended
Projected expiry passed 13 December 2022, 3.8 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
78 claims: 3 independent, 75 dependent
- 1A method for processing a multimedia message comprising the steps of:receiving a multimedia message;determining whether the multimedia message should be processed using a customized process;retrieving one or more customized processing instructions from a database and processing the multimedia message using the one or more customized processing instructions whenever the multimedia message should be processed with the customized process;and processing the multimedia message using a standard process whenever the multimedia message should not be processed using the customized process.
- 23A computer program embodied on a computer readable medium for processing a multimedia message comprising:a code segment for receiving a multimedia message;a code segment for determining whether the multimedia message should be processed using a customized process;a code segment for retrieving one or more customized processing instructions from a database and processing the multimedia message using the one or more customized processing instructions whenever the multimedia message should be processed with the customized process;and a code segment for processing the multimedia message using a standard process whenever the multimedia message should not be processed using the customized process.
- 45Broadest claimClaim Score 83, broad(NHIP)A system for processing a multimedia message comprising:a multimedia service relay;a multimedia service server communicably coupled to the multimedia service relay;a message storage device communicably coupled to the multimedia service server;and a database communicably coupled to the multimedia service relay, the database containing one or more customized processing instructions.
Independent claims3
135 paragraphs in 5 sections, as filed
[0001] This patent application claims priority of U.S. Provisional Application No. 60/345956, filed on Dec. 31, 2001.
TECHNICAL FIELD OF THE INVENTION
[0002] The present invention relates generally to the field of communications and, more particularly, to a method, apparatus and system for processing multimedia messages.
BACKGROUND OF THE INVENTION
[0003] Short messaging service (“SMS”) has been very successful in the Global System for Mobile Communications (“GSM”) second generation system (“2G”). The success of SMS is due, in part, to the fact that all GSM capable devices support the SMS application level so that there is no need to check each device to determine whether or not its supports SMS applications. This easy to use service for non-real time text transmission between GSM users will be succeeded to in third generation (“3G”) mobile systems by a non-real time multimedia message service (“MMS”). The MMS will provide multimedia message capability instead of the text only capability of SMS.
[0004] Multimedia consists of one or more media elements, such as text, voice, image and video, and it is the combination of these media elements in an ordered synchronized manner that creates a multimedia presentation, which is also referred to as multimedia content. A non-real time multimedia message as observed by the user is a combination of one or more different media elements in a multimedia presentation that can be transferred between users without having to be transferred in real time.
[0005] With the popularity of the Internet and increased capability of personal computers, multimedia technology has and continues to rapidly develop to allow new capabilities, such as multimedia messages, games, presentations and services that are now considered to be a part of every day life. Moreover, the reduced size and increased capabilities of handheld devices, such as personal data assistants (“PDAs”), mobile phones and combinations thereof, have made the delivery of multimedia content to such devices more of a possibility. Efficient and effective delivery of multimedia content to such devices is not, however, a practical reality.
[0006] There is, therefore, a need for a method, apparatus and system that processes multimedia messages and is capable of supporting current and future multimedia messaging services, and exploit the advances being made in the world multimedia community, with additional mobile requirements.
SUMMARY OF THE INVENTION
[0007] The present invention provides a method, apparatus and system that processes multimedia messages and is capable of supporting current and future multimedia messaging services, and exploit the advances being made in the world multimedia community, with additional mobile requirements. The present invention does not standardize new services themselves, but instead provides a standardized set of service capabilities and features on which the new services will be built. The present invention allows users to send and receive messages exploiting the whole array of media types available today, e.g. text, voice, images, audio, video and combinations thereof, while also making it possible to support new media types as they become available. The present invention provides, among other things, multiple media elements per single message, individual handling of message elements, different delivery methods for each message element, negotiation of different terminal and network multimedia message capabilities, notification and acknowledgment of multimedia message related events (e.g. delivery, deletion), handling of undeliverable multimedia messages, personalized multimedia message service configurations and flexible charging. The present invention provides a unified application that integrates the composition, storage, access and delivery of different media types in combination with additional mobile requirements.
[0008] The present invention provides a method for processing a multimedia message wherein the multimedia message is received and it is determined whether the multimedia message should be processed using a customized process or a standard process. If the multimedia message should be processed with the customized process, the present invention retrieves one or more customized processing instructions from a database and processes the multimedia message using the one or more customized processing instructions. If, however, the multimedia message should be processed using the standard process, the present invention processes the multimedia message using the standard process. This method can be implemented using a computer program embodied on a computer readable medium wherein each function is executed using a code segment.
[0009] The present invention also provides a system for processing a multimedia message that includes a multimedia service relay, a multimedia service server communicably coupled to the multimedia service relay, a message storage device communicably coupled to the multimedia service server and a database communicably coupled to the multimedia service relay. The database contains one or more customized processing instructions.
[0010] Other features and advantages of the present invention will be apparent to those of ordinary skill in the art upon reference to the following detailed description taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] For a better understanding of the invention, and to show by way of example how the same may be carried into effect, reference is now made to the detailed description of the invention along with the accompanying figures in which corresponding numerals in the different figures refer to corresponding parts and in which:
[0012]FIG. 1 is an architectural overview of a Multimedia Messaging Service in accordance with one embodiment of the present invention;
[0013]FIG. 2 is an overview of a Multimedia Messaging Service in accordance with another embodiment of the present invention;
[0014]FIG. 3 is a block diagram of a logical Multimedia Messaging Service platform in accordance with one embodiment of the present invention;
[0015]FIG. 4 is a block diagram of a Multimedia Messaging Center in accordance with one embodiment of the present invention;
[0016]FIG. 5 is a block diagram showing the components of a Multimedia Messaging Center in accordance with one embodiment of the present invention;
[0017]FIG. 6 is a block diagram showing the network connectivity of a Multimedia Messaging Center in accordance with one embodiment of the present invention;
[0018]FIG. 7 is a block diagram showing a protocol framework of the Multimedia Messaging Service User Agent, Multimedia Messaging Center and External Servers in accordance with one embodiment of the present invention;
[0019]FIG. 8 is a block diagram showing a protocol framework of the Multimedia Messaging Service User Agent, Wireless Application Protocol Gateway and Multimedia Messaging Center in accordance with one embodiment of the present invention;
[0020]FIG. 9 is a block diagram showing a protocol framework of the Multimedia Messaging Service User Agent, Internet Protocol Based Gateway and Multimedia Messaging Center in accordance with one embodiment of the present invention;
[0021]FIG. 10 is a block diagram showing the communication between two Multimedia Messaging Service Environments in accordance with one embodiment of the present invention;
[0022]FIG. 11 is a message flow diagram showing the communication between two Multimedia Messaging Service Environments in accordance with one embodiment of the present invention; and
[0023]FIG. 12 is a flow chart of the Multimedia Messaging Center multimedia message processing.
DETAILED DESCRIPTION OF THE INVENTION
[0024] While the making and using of various embodiments of the present invention are discussed in detail below, it should be appreciated that the present invention provides many applicable inventive concepts, which can be embodied in a wide variety of specific contexts. For example, in addition to telecommunications systems, the present invention may be applicable to other forms of communications or general data processing. Other forms of communications may include communications between networks, communications via satellite, or any form of communications not yet known to man as of the date of the present invention. The specific embodiments discussed herein are merely illustrative of specific ways to make and use the invention and do not limit the scope of the invention.
[0025] The present invention provides a flexible architecture that supports present and future multimedia messaging technologies and handles all message types and formats, such as fax, SMS, Multimedia, voice-mail and e-mail, in a consistent manner regardless of message type or format. The present invention also provides consistent access to the system regardless of the access point within the capabilities of networks and terminals. For example, the user can access his or her multimedia messages through a number of different access points, which may include 3G and 2G networks, fixed networks and the Internet. The present invention supports a minimum set of functionality and message media types and message content formats to ensure interoperability between different terminals and networks from the very beginning of service provisioning.
[0026]FIG. 1 is an architectural overview of a Multimedia Messaging Service (“MMS”) <b>100</b> in accordance with one embodiment of the present invention that combines different networks and network types and integrates messaging systems already existent within these networks. MMS User Agents <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> interact with the Multimedia Messaging Service Environment (“MMSE”) <b>114</b>, which may comprise fixed networks <b>116</b>, mobile networks <b>118</b>, 2G mobile networks <b>120</b>, 3G mobile networks <b>122</b> and Internet/IP networks <b>124</b>. The MMS User Agents <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> reside on a UE, an MS or on an external device connected to a UE/MS. Each MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> is an application layer function that provides the users with the ability to view, compose and handle multimedia messages (e.g., submitting, receiving, deleting of multimedia messages). The MMSE <b>114</b> provides all the necessary service elements, e.g. delivery, storage and notification functionality. These service elements may be located within one network or distributed across several networks or network types. The connectivity between these different networks <b>116</b>, <b>118</b>, <b>120</b>, <b>122</b> and <b>124</b> is provided by the Internet Protocol (“IP”) and its associated set of messaging protocols. This approach enables messaging in 2G and 3G wireless networks <b>120</b> and <b>122</b> to be compatible with messaging systems found on the Internet/IP Network <b>124</b>. The MMSE <b>114</b> can be implemented either within or on the periphery of a network operator's core network. In addition, network operators can support a limited set of MMS functionality, while others may require extensive and elaborate MMS support according to their business models.
[0027] The MMSE <b>114</b> encompasses all the various elements that provide a complete MMS <b>100</b> to a user. One or more Multimedia Messaging Centers (“MMC”) <b>126</b> form the core of the MMSE <b>114</b>. The MMC <b>126</b> includes a multimedia service relay (“MMS Relay”) <b>128</b>, a multimedia service server (“MMS Server”) <b>130</b> communicably coupled to the MMS Relay <b>128</b>, a message storage device <b>132</b> communicably coupled to the MMS Server <b>130</b> and one or more databases <b>134</b> communicably coupled to the MMS Relay <b>128</b>. The one or more databases <b>134</b>, which may also be referred to as a customer or subscriber directory and/or an operator directory, contain one or more customized processing instructions. The MMC <b>126</b> is responsible for storage and handling of incoming and outgoing messages and for the transfer of messages between different messaging systems.
[0028] More specifically, the MMS Relay <b>128</b> and MMS Server <b>130</b> receive and send multimedia messages, enable/disable MMS functions, personalize MMS based on user profile information, delete multimedia messages based on user profile or filtering information, perform media type and format conversions, convert messages arriving at the MMSE <b>114</b> from legacy messaging systems to multimedia format (e.g. facsimile to MM), convert multimedia messages leaving the MMSE <b>114</b> to legacy messaging systems to the appropriate message format (e.g. multimedia to internet e-mail), retrieve message content, forward multimedia messages, screen multimedia messages, negotiate MMS User Agent <b>102</b>-<b>112</b> terminal capabilities, check MMS User Agent <b>102</b>-<b>112</b> terminal availability, provide multimedia message notification to the MMS User Agents <b>102</b>-<b>112</b>, generate call data records (“CDR”), provide address translation, hide addresses, manage the message properties on servers (e.g. voice-mail or e-mail server) integrated in the MMSE <b>114</b>, provide temporary and/or persistent storage of messages, ensure that messages are not lost until successfully delivered to another MMSE element, control the reply-charging feature of MMS, and other functions or services.
[0029] The MMS Relay <b>128</b> and MMS Server <b>130</b> can be separate logical elements as shown, or they can be combined into a single MMS Relay/Server element. Moreover, the MMS Relay <b>128</b> and MMS Server <b>130</b> can be distributed across different domains. If the MMS Relay <b>128</b> and MMS Server <b>130</b> are separate physical entities, the message transfer between the MMS Relay <b>128</b> and MMS Server <b>130</b> may use SMTP and POP3/IMAP or HTTP protocols. If the SMTP protocol is used to upload and download multimedia messages to the MMS Server <b>130</b>, then that same protocol can be used to transfer multimedia messages between different MMSEs <b>114</b>.
[0030] The MMS Relay <b>128</b> and MMS Server <b>130</b> also provide convergence functionality between external servers <b>138</b> and MMS User Agents <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> to enable the integration of different server types across different networks. The external servers <b>138</b> are communicably coupled to the MMS Relay <b>128</b> via the Internet/IP Network <b>124</b>. The external servers <b>138</b> may include e-mails servers, SMS servers, fax servers, prepaid servers and multimedia content servers, which may be included within or connected to the MMSE <b>114</b>.
[0031] The MMC <b>126</b> also interfaces with MMS value added service applications (“MMS VAS Applications”) <b>136</b> through the MMS Relay <b>128</b>. The MMS VAS Applications <b>136</b> provide value added services to the MMS users. For example, the MMS VAS Applications <b>136</b> may provide some additional features like multimedia message recall between MMS VAS Applications <b>136</b> and the MMC <b>126</b> that are not available for MMS User Agents <b>102</b>-<b>112</b>. MMS VAS Applications <b>136</b> can generate CDRs when receiving multimedia messages from MMC <b>126</b> and when submitting multimedia messages to MMC <b>126</b>.
[0032] The one or more databases <b>134</b> may comprise one or more entities that contain user related information such as subscription and configuration (e.g. user profile, subscription, operator services, Home Location Register (“HLR”), etc.) and provide customized processing instructions. The one or more databases <b>134</b> may provide MMS user subscription information, information for the control of access to the MMS, information for the control of the extent of available service capability (e.g. server storage space), a set of rules how to handle incoming messages and their delivery, and information of the current capabilities of the user's terminal.
[0033] MMS supports the use of e-mail addresses (RFC 822) or MSISDN (E.164) or both to address the recipient of a multimedia message. MMS may support the use of service provider specific addresses to address the recipient of a multimedia message. In the case of e-mail addresses standard Internet message routing should be used. MSISDN can be used for addressing a recipient in a different MMS service provider's domain via MSISDN translation to a routable address. Service provider specific addresses may be used to deliver messages to MMS VAS Applications <b>136</b> within one MMSE <b>114</b>. MMS connectivity across different networks (MMSEs) can be provided using Internet protocols. In such a case, each MMSE <b>114</b> should be assigned a unique domain name (e.g. mms.operatora.net).
[0034] MMS recipient addresses provided by a MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> may be in a format of an RFC 822 routable address, such as an e-mail address, or other formats, such as E.164 or service provider specific addresses. In those cases where a non-routable address is used to specify a recipient and the recipient belongs to another MMSE <b>114</b> or the recipient is outside of any MMSE <b>114</b>, the address needs to be translated to an RFC 822 routable address format. The sender's MMSE will make this mapping before routing or forwarding the message to the recipient's MMSE. The MMS service providers or network operators may use solutions for their particular needs that may include static tables or other look-up methods to map to the correct recipient's MMS Relay <b>128</b>. An Electronic Numbering (“ENUM”) database can be used as the mechanism to map MSISDN numbers to RFC 822 routable addresses.
[0035] The MMS <b>100</b> can support address hiding, which allows the sender to send anonymous messages where the sender's address is not shown to the recipient MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b>. If the peer entity is not known to be a MMSE, the originator MMSE will not provide the originator address. If the peer entity is known to be a MMSE, both the originator address and request of address hiding will be forwarded to the recipient MMSE. The recipient MMSE is responsible for not showing the originator address to the recipient MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b>.
[0036] The MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> can provide the following application layer functionalities: the multimedia message presentation; the presentation of notifications to the user; and the retrieval of multimedia messages (initiate multimedia message delivery to the MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b>). The MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> may provide additional application layer functionalities such as: multimedia message composition; multimedia message submission; signing of a multimedia message on an end-user to end-user basis; decryption and encryption of a multimedia message on an end-user to end-user basis; all aspects of storing multimedia messages on the terminal and/or USIM; handling external devices; and user profile management.
[0037] The MMS <b>100</b> will support the ability to create, update, store, transfer, interrogate, manage and retrieve a user's multimedia messaging profiles. The multimedia messaging profiles will allow a user to configure and personalize his or her multimedia messaging environment (e.g., which media types and notifications that will be delivered to the recipient, such as voice only or text only). The multimedia messaging profiles will form part of the user's virtual home environment.
[0038] The user will be able to use and access multimedia messages in a secure manner. The contents of multimedia messages can be read only by the intended recipient(s). A recipient will be informed of the reliability of the identity of the sender in case the sender has authorized his identity to be transmitted. The integrity of multimedia messages during transit will be assured to extent of the network capabilities. In addition, the MMS <b>100</b> will be intrinsically resistant to attempts of malicious or fraudulent use.
[0039] The MMS <b>100</b> will also support various charging mechanisms. The following characteristics can be used as charging mechanisms: message type, length, storage time in the network, etc.; delivering time, upload/download method; multimedia message sender/recipient; number of messages sent; number of messages received; roaming conditions; location conditions; pre-charging notification; and prepaid subscriptions. The pre-charging notification indicates to the recipient prior to the recipient downloading a multimedia message whether the sender has paid for the message or the recipient is expected to pay for the message.
[0040] Multiple media elements can combine into a composite single multimedia message using MIME multipart format as defined in RFC 2046. The media type of a single multimedia message element can be identified by its appropriate MIME type whereas the media format can be indicated by its appropriate MIME subtype. The MMS User Agents <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> can support media formats or codecs for supporting media types, such as Text (plain text; character encoding (charset) containing a subset of the logical characters in Unicode (e.g. US-ASCII, ISO-8859-1, UTF-8, Shift_JIS, etc.)), Audio (AMR; organized in the Bitstream Syntax as proposed by the IETF; MP3; MIDI; WAV), Image (Baseline JPEG; MP4; GIF 89a), and Video (MPEG 4 (Visual Simple Profile, Level 1); ITU-T H.263; Quicktime). Other formats or standards can be used.
[0041] The present invention also offers many services. For example, when a user intends to send a multimedia message to one or several destinations, the multimedia message is submitted to the originator MMS Relay <b>128</b>/MMS Server <b>130</b>. Note that submission of multimedia messages is optional for MMS User Agents <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b>. If a MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> supports submission of multimedia messages, the MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> should: indicate the address of the multimedia message recipient; and identify the MIME content type of the message. The MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> may also: request a delivery report for the message; request a read-reply report for the message; provide a time stamp for the time of submission of the message; set the earliest desired expiration time or period for the message; set the desired expiration time or period for the message; indicate the address of the multimedia message originator; set further message qualifications (e.g. priority, message class, subject); and request that the multimedia message originator's address be hidden from the recipient MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b>. Upon reception of a multimedia message from an originator MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b>, the originator MMSE: will assign a Message Identification to the multimedia message and provide the originator MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> with this Message Identification; is responsible for retaining the multimedia message until the earliest desired time of delivery, if the optional feature of earliest time of delivery is supported by the originator MMSE (if this feature is not supported, then the multimedia message is immediately routed forward); may provide a time stamp, i.e. it may also override the MMS User Agent's time stamp; will insert the originator's address into the multimedia message if not yet provided by the originator MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b>; will pass the originator's address to the peer entity if the peer entity is known to be a MMSE; will route forward the request for address hiding unaltered to the recipient MMSE if the peer entity is known to be an MMSE; will pass the originator's address to the peer entity if the peer entity is not known to be an MMSE and address hiding has not been requested by the originator MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b>; will not pass the originator's address to the peer entity and should override the address provided by the originator MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> in the multimedia message to an “anonymous” address if the peer entity is not known to be an MMSE and address hiding has been requested by the originator MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b>; may override the address provided by the originator MMS User Agent in the multimedia message (subject to MMS service provider's preferences); is responsible for resolving the multimedia message recipient's address(es); is responsible to route the multimedia message towards the multimedia message recipients; should pass the indication whether or not a delivery report is requested unaltered when routing the multimedia message towards the multimedia message recipient(s); will pass the indication whether or not a read-reply report is requested unaltered when routing the multimedia message towards the multimedia message recipient(s); will pass the indication about MIME content type of the message and message qualifications (e.g. priority, message class, subject) unaltered when routing the multimedia message towards the multimedia message recipient(s); and will generate a delivery report indicating “indeterminate” status of the multimedia message's delivery if a delivery report was requested by the originator MMS User Agent <b>102</b>, <b>104</b>, <b>106</b>, <b>108</b>, <b>110</b> and <b>112</b> and if the peer entity the multimedia message is routed forward to is not known by the originator MMC. A special case is where the recipient MMSE is also the originator MMSE. In this case the multimedia message does not have to be routed forward.
[0042] Now turning to FIG. 2, an architectural overview of a MMS <b>200</b> in accordance with another embodiment of the present invention is shown. MMC <b>202</b>, MMC <b>204</b> and MMC <b>206</b> are all communicably coupled to each other. MMC <b>202</b>, MMC <b>204</b> and MMC <b>206</b> may be operated by the same network operator or by different network operators. MMC <b>202</b> comprises a MMS Relay <b>208</b>, MMS Server <b>210</b>, message storage <b>212</b>, subscriber database <b>214</b>, operator services database <b>216</b>, ENUM/Domain Name System (“DNS”) database <b>218</b> and a MMC O&M <b>220</b>. MMS Relay <b>208</b> is communicably coupled to a MMS Server <b>210</b>, a subscriber database <b>214</b> and the ENUM/DNS database <b>218</b>. The MMS Server <b>210</b> is communicably coupled to the message storage <b>212</b>, and the subscriber database <b>214</b> is communicably coupled to the operator services database <b>216</b>. Note that the subscriber database <b>214</b> and operator services database <b>216</b>, which were collectively referred to as the one or more databases <b>124</b> in FIG. 1, can both be directly coupled to the MMS Relay <b>208</b>.
[0043] MMS User Agents <b>222</b> and <b>224</b> are communicably coupled to the MMS Relay <b>208</b> via an access network <b>226</b> and a WAP/Push Proxy Gateway <b>228</b>. The WAP/Push Proxy Gateway <b>228</b> can be separated into two separate logical entities. A SMS-C Server <b>230</b> is also communicably coupled to the MMS Relay <b>208</b>. Prepaid Server <b>232</b>, Unified Messaging System (“UMS”) Server <b>234</b>, E-mail Server <b>236</b> and Multimedia Content Server <b>238</b> are communicably coupled to the MMS Relay <b>208</b> via Internet/IP Network <b>240</b>.
[0044] Depending on the SMS-C Server <b>230</b> manufacturer, the MMS Relay <b>208</b> either can be directly connected to the SMS-C Server <b>230</b> or an additional SMS-Gateway (not shown) can be added. In the latter case, the SMS-Gateway (not shown) is located between the MMS Relay <b>208</b> and the SMS-C Server <b>230</b> and provides the mapping of one or several SMSC access protocol (mapping between MMS Relay <b>208</b> SMSC access protocol and operator's existing SMSC access protocol).
[0045] The Prepaid Server <b>232</b> supports the prepaid concept within the MMSE. A prepaid customer may be charged for submitting or retrieving multimedia/abstract messages. In the submission case, the originator MMC <b>202</b> will first ascertain that the originator of the multimedia/abstract message is a prepaid customer. The MMC <b>202</b> then initiates a credit check and further processing of the multimedia/abstract message is put on hold. In the case where the customer's credit is insufficient to submit this particular multimedia/abstract message, the originator MMC <b>202</b> may reject it. The credit check may be based on several criteria like: size of the multimedia message; content type; settings of information elements; and type of the abstract message. In the case where multimedia/abstract message cannot be accepted, the originator MMC <b>202</b> will respond with an appropriate status value to the submitted request. The MMS User Agent <b>222</b> and <b>224</b> should bring this information to the user's attention. In the case where multimedia/abstract message is accepted, the message is further processed by the MMC <b>202</b>.
[0046] In the retrieving case, the recipient MMC <b>202</b> will first ascertain that the recipient of the multimedia/abstract message is a prepaid customer. The MMC <b>202</b> then initiates a credit check for the particular customer. The credit check can be performed at the time the multimedia/abstract message arrives at the recipient MMC <b>202</b>. Based on the results of the credit check, the MMC <b>202</b> will reject or accept the multimedia/abstract message. If the multimedia/abstract message is accepted (with or without the previous credit check), the MMC <b>202</b> may perform a credit check at the time the MMS User Agent <b>222</b> and <b>224</b> sends a retrieve request. The credit check may be based on several criteria as in the sending case previously described. In the case where a multimedia/abstract message can not be retrieved because the customer's account balance is too low, the recipient MMC <b>202</b> may respond with an appropriate status value to the retrieve request. The MMS User Agent <b>222</b> and <b>224</b> should bring this information to the user's attention. Otherwise the multimedia/abstract message will be delivered to the MMS User Agent <b>222</b> and <b>224</b>.
[0047] Many carriers are operating or planning to operate UMS platforms, as well as conform to 3GPP specifications. As a result, newly deployed UMS platforms will use MMS <b>200</b> as their wireless access User Agents. However, newly deployed MMS systems will likely co-exist and integrate with UMS, voice mail systems (“VMS”), and e-mail systems. In addition, UMS will likely involve other access methods, such as PC mail access, Web browser access, PSTN, voice phone access, etc.
[0048] Some operators may choose to integrate their MMS and UMS services. Even with a complete migration strategy, large e-mail systems and VMS systems will likely require lengthy migration periods during which an integrated operation between the 3GPP and legacy systems must occur. Also, some installations will require permanent integrations, where 3GPP systems continuously interoperate with a legacy UMS or a legacy VMS. As shown, the MMC <b>202</b> interoperates with a UMS Server <b>234</b> that connects to VMS, SMS, fax, and e-mail. The MMC <b>202</b> can, therefore, obtain e-mail, voice, and/or fax messages from the UMS Server <b>234</b>. PC clients may also be accessed through the UMS Servers <b>234</b>, which may be integrated with the MMS Servers <b>234</b> by some operators. In this case a unified mailbox will be presented to both MMS users and others who access the system via other devices.
[0049] In addition, the UMS Server <b>234</b> can stream compressed voice from the VMS, assuming that streaming support is available in the servers as well as the clients. It could also establish a CS connection (using for example WTA methods to the wireless terminal). Voice mail and faxes can also originate from a voice/fax gateway server, which exists in both the legacy VMS as well as a UMS. Faxes can be sent out to remote fax numbers via the fax gateway. In that case, the gateway would convert the voice mail or Fax to Voice Profile for Internet Mail (“VPIM”) based e-mail messages. Access to the VMS and UMS should occur via open standard protocols, such as Post Office Protocol Version 3 (“POP3”), Internet Message Access Protocol (“IMAP4”, WebDAV, T.30, H.323, etc.).
[0050] With respect to the transfer of facsimile data via store-and-forward mechanisms, the MMC <b>202</b> will interface with a T.37 Fax Gateway (not shown) using the appropriate SMTP protocol. The Fax Gateway (not shown) will terminate the T.30 protocol towards a Public Switched Telephone Network (“PSTN”). Mobile terminated fax data will be converted into TIFF image format and forwarded to the MMC <b>202</b> as an attachment in an Internet Engineering Task Force (“IETF”) internet e-mail. In the case of mobile originated fax messages, the Fax Gateway (not shown) receives a written e-mail provided with the receiver's fax number from the MMC <b>202</b>. Depending on the functions of the Fax Gateway (not shown), this e-mail may contain plain text only or additional attachments. Although T.37 requires only TIFF format support, the Fax Gateways (not shown) may permit many different formats.
[0051] MMS <b>200</b> interaction with voice mailbox systems should be performed on a non-real time basis. The Voice Profile for Internet Mail Version 2, VPIMv2, provides format extensions for MIME supporting the transmission of voice messages over standard Internet e-mail systems. The VPIM concept was developed by the Electronic Messaging Association (“EMA”). After VPIMv2 had been reviewed by the IETF it became RFC 2421. The VPIM specification allows voice records to be MIME encapsulated and sent as Internet mail attachments via Simple Mail Transfer Protocol (“SMTP”) or retrieved as Internet mail attachments via POP3 or IMAP4. The MIME type used for voice messages is “audio/*”. For the interaction of MMS <b>200</b> with voice mailboxes, the voice mailbox may forward received voice records as VPIM messages via SMTP to the MMC <b>202</b>. In this case, the protocol to be used on the interface between MMC <b>202</b> and the voice mailbox is SMTP and is, therefore, identical to the one used between different MMCs. Alternatively, the MMC <b>202</b> may poll the voice mailbox via POP3 or IMAP4 for newly received messages. Messages that the user wants to retrieve via the MMS service can then be downloaded via POP3/IMAP4 from the voice mailbox to the MMC <b>202</b> from where they are delivered to the MMS User Agent <b>222</b> or <b>224</b>. This enables the user to do both, retrieve voice messages via today's real time voice mail services or as a multimedia message. In any case, it is expected that the voice mailbox is still the owner of the message and as a consequence is responsible for the storage. As an alternative, the MMS <b>200</b> interworking with a 2G/3G Voice Mailbox System could be envisaged via an Hypertext Transfer Protocol (“HTTP”) interface.
[0052] The E-Mail Server <b>236</b> provides post office services that are accessible via POP3 or IMAP for Internet e-mail retrieval in the MMS <b>200</b> or are accessible to the MMC <b>202</b> using SMTP. The MMC <b>202</b> sends messages that are to be transmitted as Internet e-mail via SMTP. The retrieval and sending of multimedia messages from and to the Internet e-mail service is done via SMTP. The protocol used on the interface between MMC <b>202</b> and the Mail Transfer Agent, MTA/E-mail Server is identical to the one used between different MMS Relays <b>210</b>.
[0053] WAP provides significant support for MMS <b>200</b>, both in direct service specification and in the underlying technologies. WAP support for MMS <b>200</b> is based upon the services of its supporting technology. The first communication link, between the wireless MMS User Agent <b>222</b> and <b>224</b> and the WAP Gateway <b>228</b>, is where the “WAP Stack” is used to provide a common set of services over a variety of wireless bearers. For application-oriented services, like MMS <b>200</b>, the interest is primarily in services offered by WAP Session Protocol (“WSP”). The second communication link connects the WAP Gateway <b>228</b> and the MMS Relay <b>208</b>. In the WAP architecture, the MMS Relay <b>208</b> is considered an Origin Server. These entities are connected over an IP network such as the Internet or a local Intranet. HTTP is used for data transfer and data can be originated from either entity. End-to-end connectivity, for the MMS application, between the wireless MMS User Agent <b>222</b> and <b>224</b> and the MMS Relay <b>208</b> is accomplished by sending data over WSP and HTTP. This is accomplished using the WSP/HTTP POST method for data originating at the wireless MMS User Agent <b>222</b> and <b>224</b> and by using the WAP Push Access Protocol in the other direction. The WAP Gateway <b>228</b>, which enables the needed interworking, should not modify the data transfer via these transactions. The WAP view of MMS <b>200</b> is constrained to the interactions between the MMS User Agent <b>222</b> and <b>224</b> and the MMC <b>202</b>.
[0054] Referring now to FIG. 3, a block diagram of a logical MMS platform in accordance with one embodiment of the present invention is shown. MMS Relay <b>300</b> is communicably coupled to MMS Server <b>302</b>, which has a safe storage <b>304</b>. MMS Relay <b>300</b> and MMS Server <b>302</b> are communicably coupled to a CFG Manager <b>306</b> using XML, an event manager <b>308</b> using SNMP, and a Stats/Logs <b>310</b> using XML. The CFG Manager <b>306</b> is communicably coupled to one or more user terminals <b>312</b> via an Intranet <b>314</b> using XML. The event manager <b>308</b> is communicably coupled to a NMS <b>316</b> using SNMP. The Stats/Logs <b>310</b> is communicably coupled to a statistical analysis program <b>318</b> using File Transfer Protocol (“FTP”). The MMS Server <b>302</b> is also communicably coupled to a charging function <b>320</b> using Radius-MMS, which is in turn communicably coupled to a charge control node <b>322</b> using FTP for off-line processing and Radius-MMS for hot billing.
[0055] The MMS Relay <b>300</b> is communicably coupled to a subscriber directory <b>324</b> using LDAP, which is in turn communicably coupled to a subscriber self provisioning function <b>326</b> and customer care function <b>328</b> using CAI, Java/CORBA, or XML APIs. The MMS Relay <b>300</b> is also communicably coupled to a prepaid server <b>330</b> using DIAMETER/CSI, an external messaging system <b>332</b> using SMTP and a content provider server <b>334</b> using SMTP/HTTP. In addition, the MMS Relay <b>300</b> is communicably coupled to a ENUM/DNS database <b>336</b> using DNS, a FNR <b>338</b> using MAP, a WAP Gateway/PPG <b>340</b> using HTTP, an ERH <b>342</b> using LDAP, other MMS Relays <b>344</b> using SMTP and a SMS-C Server <b>346</b> using SMPP, SMTP or UCP. The ENUM/DNS database <b>336</b> is communicably coupled to a global ENUM/DNS database <b>348</b>. The FNR <b>338</b> and ERH <b>342</b> are communicably coupled using MAP. The WAP Gateway/PPG <b>340</b> is communicably coupled to a mobile network <b>348</b> using WSP. The SMS-C Server <b>346</b> is communicably coupled to the mobile network <b>348</b> using IS41/MAP. One or more mobile terminals <b>350</b> are communicably coupled to the mobile network <b>348</b>.
[0056] Turning now to FIG. 4, a block diagram of a MMC in accordance with one embodiment of the present invention is shown. The physical server representing the MMS Relay <b>400</b> provides a MMC Relay function <b>402</b>, a subscriber directory function <b>404</b> and configuration function <b>406</b>. The physical server representing the MMS Server <b>408</b> provides a MMC Server function <b>410</b>, a safe storage function <b>412</b> and a configuration function <b>414</b>. The physical server representing the MMS O&M <b>416</b> provides a charging function <b>418</b>, a statistics function <b>420</b>, a licensing function <b>422</b> and an alarm events function <b>424</b>. TCP/IP data traffic is passed between the MMC Relay <b>402</b> function and the MMC Server function <b>410</b>.
[0057] Message traffic is passed between the MMC Relay function <b>402</b> and MARS <b>426</b> via SMTP, Content Providers E-mail Server <b>428</b> via SMTP, WFP/PPG <b>430</b> via HTTP and E-mail Server <b>432</b> via SMTP. O&M traffic is passed between the MMC Relay function <b>402</b> and the MMC Server function <b>410</b> via SNMP Poll/SNMP Trap and XML, the statistics function <b>420</b> via XML, the alarm events <b>424</b> via SNMP Poll/SNMP Trap, the prepaid server <b>434</b>, and the subscriber directory <b>404</b> via LDAP. In addition, O&M traffic is passed between the subscriber directory <b>404</b> and the customer care <b>436</b>. Message traffic is passed between the configuration function <b>406</b> and the administration workstation <b>438</b> via XML.
[0058] Within the MMS Server <b>408</b>, message traffic is passed between the MMC Server function <b>410</b> and the safe storage <b>412</b>. O&M traffic is passed between the MMC Server function <b>410</b> and the MMC Relay function <b>402</b> via SNMP Poll/SNMP Trap and XML, the statistics function <b>420</b> via XML, the charging function <b>418</b> via RADIUS-MMS and the alarm events <b>424</b> via SNMP Poll/SNMP Trap. Message traffic is passed between the configuration function <b>414</b> and the administration workstation <b>438</b> via XML. Within the MMS O&M <b>416</b>, O&M traffic is passed between the statistics function <b>420</b> and the customer care <b>436</b>; the charging function <b>418</b> and the CCN <b>440</b> via FTP/RADIUS; and the alarm events <b>424</b> and the NMS <b>442</b> via SNMP Poll/SNMP Trap.
[0059] Now referring to FIG. 5, a block diagram showing the components of a MMC in accordance with one embodiment of the present invention is shown. The physical server representing the MMS Relay <b>400</b> provides a MMC Relay function <b>402</b>, a SOS <b>500</b> and an operating environment <b>502</b>. The physical server representing the MMS Server <b>408</b> provides a MMC Server function <b>410</b> and an operating environment <b>504</b>. The physical server representing the MMS O&M <b>416</b> provides a LER <b>506</b>, BEER <b>508</b>, OAM <b>510</b>, SvcBrok <b>512</b>, MLM <b>514</b> and an operating environment <b>516</b>. TCP/IP data traffic is passed between the MMC Relay <b>402</b> and the MMC Server <b>410</b>.
[0060] Message traffic is passed between the MMC Relay function <b>402</b> and MARS <b>426</b> via SMTP, Content Providers E-mail Server <b>428</b> via SMTP, WFP/PPG <b>430</b> via HTTP and E-mail Server <b>432</b> via SMTP. O&M traffic is passed between the MMC Relay function <b>402</b> and the MMC Server function <b>410</b> via SNMP Poll/SNMP Trap and XML, the LER <b>506</b> via XML, and the OAM <b>510</b> via SNMP Poll/SNMP Trap. In addition, O&M traffic is passed between the SOS <b>500</b> and the customer care <b>436</b> and operating system <b>502</b>. Message traffic is passed between the operating environment <b>502</b> and the administration workstation <b>438</b> via XML.
[0061] Within the MMS Server <b>408</b>, O&M traffic is passed between the MMC Sever function <b>410</b> and the MMC Relay function <b>402</b> via SNMP Poll/SNMP Trap and XML, the LER <b>506</b>, the BEER <b>508</b> via RADIUS-MMS and OAM <b>510</b> via SNMP Poll/SNMP Trap. Message traffic is passed between the operating environment <b>504</b> and the administration workstation <b>438</b> via XML. Within the MMS O&M <b>416</b>, O&M traffic is passed between the LER <b>506</b> and the customer care <b>436</b>; the BEER <b>508</b> and the CCN <b>440</b> via FTP/RADIUS; and the OAM <b>510</b> and the NMS <b>442</b> via SNMP Poll/SNMP Trap.
[0062]FIG. 6 is a block diagram showing the network connectivity of a MMC in accordance with one embodiment of the present invention. The MMC has an external traffic LAN <b>602</b>, an internal traffic LAN <b>604</b>, a primary O&M LAN <b>606</b>, an internal O&M LAN <b>608</b>, an external maintenance LAN <b>610</b> and console port RS232 connections <b>612</b>. A WAP Gateway <b>614</b> is communicably coupled to the external traffic LAN <b>602</b> via a WAN/LAN router <b>616</b>. An administration workstation <b>618</b> is communicably coupled to the primary O&M LAN <b>606</b> via a WAN/LAN router <b>620</b>. A network operation center <b>622</b> is communicably coupled to the primary O&M LAN <b>606</b> via a WAN/LAN router <b>624</b>. A maintenance center <b>626</b> is communicably coupled to the external maintenance LAN <b>610</b> via a WAN/LAN router <b>628</b>.
[0063] The MMS Relay <b>630</b> is connected to the external traffic LAN <b>602</b> and to a database <b>632</b>. The MMS Directory Server <b>634</b> is connected to the internal traffic LAN <b>604</b>, the console port RS232 connections <b>612</b> and the subscriber directory <b>636</b>. The MMS Server <b>638</b> is connected to the internal traffic LAN <b>604</b>, the console port RS232 connections <b>612</b> and the message storage <b>640</b>. The message storage <b>640</b> is connected to the MMS Server <b>638</b> and the internal traffic LAN <b>604</b>. The MMS O&M <b>642</b> is connected to the MMS Relay <b>630</b>/MMS Directory Server <b>634</b> via primary O&M LAN <b>606</b> and internal O&M LAN <b>608</b>. The MMS O&M <b>642</b> is also connected to a database <b>644</b>. Moreover, MMS O&M <b>642</b> is connected to the MMS Server <b>638</b> via internal O&M LAN <b>608</b> and console port RS232 connections <b>612</b>; and to MMS Relay <b>630</b>/MMS Directory Server <b>634</b> via console port RS232 connections <b>612</b>; and to MMS Console Terminal Server <b>646</b> and MMS Rack Monitor System <b>648</b> via console port RS232 connections <b>612</b>. MMS Console Terminal Server <b>646</b> is communicably coupled to a dialup connection <b>650</b> via modem <b>652</b>.
[0064] Now referring to FIG. 7, a block diagram showing a protocol framework of the MMS User Agent, MMC and External Servers in accordance with one embodiment of the present invention is shown. Similarly, FIG. 8 depicts a block diagram showing a protocol framework of the MMS User Agent, WAP Gateway and MMC in accordance with one embodiment of the present invention. FIG. 9 is a block diagram showing a protocol framework of the MMS User Agent, IP Based Gateway and MMC in accordance with one embodiment of the present invention.
[0065] Referring now to FIG. 10, a block diagram showing the communication between two MMSEs <b>1002</b> and <b>1012</b> in accordance with one embodiment of the present invention is shown. MMSE <b>1002</b> is operated by service provider A and contains MMC <b>1004</b> and radio network <b>1006</b>, which are communicably coupled together. MMS User Agent <b>1008</b> is communicably coupled to radio network <b>1006</b>. MMSE <b>1012</b> is operated by service provider B and contains MMC <b>1014</b> and radio network <b>1016</b>, which are communicably coupled together. MMS User Agent <b>1018</b> is communicably coupled to radio network <b>1016</b>. MMC <b>1004</b> and MMC <b>1014</b> are communicably coupled together.
[0066] Now referring to FIG. 11, a message flow diagram showing the communication between two MMSEs <b>1002</b> and <b>1012</b> in accordance with one embodiment of the present invention is depicted. The MMS abstract messages used in this example follow the these conventions: the transactions between the MMS User Agent <b>1008</b> and <b>1018</b> and MMS Relay/Server <b>1004</b> and <b>1014</b> are prefixed with “MM1”; the transactions between the MMS Relay/Servers <b>1004</b> and <b>1014</b> are prefixed with “MM4”; requests are identified with “.REQ” as a suffix; and responses are identified with the “.RES” suffix. Each abstract message carries with it certain information elements, which may vary according to the specific message. All messages will carry, as information elements, a protocol version and message type, in order that the MMSE components may be able to properly identify and manage the message contents. Specific information regarding the message encapsulation, including order, possible values, and encoding are not described because they will vary according the MMSE protocol environment. Depending on the MMS Implementation (WAP etc.), one or more abstract messages may be mapped to a single lower layer PDU, and a single abstract message may be mapped to multiple lower layer PDUs, if the information carried in the PDU(s) serve the purpose of required information in the subjected abstract message(s). In MM1 responses that provide a status information, the status information returned has no correspondence to the status information returned in MM4 responses; they are independent of each other. The MM1 response status, which are limited by design to as small a set of values as possible, may correlate to status and errors occurring within the communications protocols underlying the implementation of the MM4 abstract messages. Similarly, the MM4 status may correlate to those occurring within the communications protocols underlying the implementation of the MM1 abstract messages. The MMS application protocol will provide means to uniquely identify the version number and message type in each abstract message defined here. The order, possible values and encoding of the information elements for each abstract message will be dictated by the protocol environment. Note that delivery reports are sent by the recipient MMS Relay/Server <b>1014</b> and read-reply reports are sent by the recipient MMS User Agent <b>1018</b>.
[0067] Submission of Multimedia Message MM1—This part of MMS service covers the submission of a multimedia message. For sending purposes, a terminal-originated multimedia message will always be submitted from the originator MMS User Agent <b>1008</b> to the corresponding MMS Relay/Server <b>1004</b>. Involved abstract messages are outlined in Table 1 from type and direction points of view. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 1</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Abstract messages for submission of multimedia message in MMS</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="77PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="105PT" align="left" /><tbody valign="top"><row><entry>Abstract messages</entry><entry>Type</entry><entry>Direction</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>MM1_submit.REQ 1102</entry><entry>Request</entry><entry>MMS UA 1008 −> MMS</entry></row><row><entry /><entry /><entry>Relay/Server 1004</entry></row><row><entry>MM1_submit.RES 1104</entry><entry>Response</entry><entry>MMS Relay/Server 1004 −> MMS</entry></row><row><entry /><entry /><entry>UA 1008</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0068] During normal operation, the originator MMS User Agent <b>1008</b> will submit a terminal-originated multimedia message to the originator MMS Relay/Server <b>1004</b> using the MM1_submit.REQ <b>1102</b>, which contains MMS control information and the multimedia message content. The MMS Relay/Server <b>1004</b> will respond with a MM1_submit.RES <b>1104</b>, which provides the status of the request. The MM1_submit.RES <b>1104</b> will unambiguously refer to the corresponding MM1_submit.REQ <b>1102</b>. Support for MM1_submit.REQ <b>1102</b> is optional for the MMS UA <b>1008</b>, support for MM1_submit.RES <b>1104</b> is mandatory for the MMS Relay/Server <b>1004</b>. Such a process may be implemented with, for example, reference to 3GPP standard 23.140 and WAP standard WAP-209.
[0069] During abnormal operation, the originator MMS Relay/Server <b>1008</b> will respond with a MM1_submit.RES <b>1104</b> encapsulating a status, which indicates the reason the multimedia message was not accepted, e.g. no subscription, corrupt message structure, service not available. If the MMS Relay/Server <b>1008</b> does not provide the MM1_submit.RES <b>1104</b>, the MMS User Agent <b>1008</b> should be able to recover.
[0070] One or several multimedia message recipients of a submitted multimedia message will be indicated in the addressing-relevant information field(s) of the MM1_submit.REQ <b>1102</b>. The originator of a submitted multimedia message may be indicated in addressing-relevant information field(s) of the MM1_submit.REQ <b>1102</b>. The originator MMS User Agent <b>1008</b> may request to hide its identity from the multimedia message recipient. The originator MMS User Agent <b>1008</b> may time stamp the multimedia message. The originator MMS User Agent <b>1008</b> may also request an earliest desired time of delivery of the multimedia message. The originator MMS User Agent <b>1008</b> may request an expiration period or time for the multimedia message. In the case of reply-charging, the originator MMS User Agent <b>1008</b> may also request a deadline for the latest time of submission of multimedia message reply granted to the recipient(s). The originator MMS User Agent <b>1008</b> may indicate that the sender wants to pay for a multimedia message reply in the MM1_submit.REQ <b>1102</b>. The multimedia message may be qualified further by adding a message class, priority and/or subject to the multimedia message in the MM1_submit.REQ <b>1102</b>. Additional qualifiers may also be added. The originator MMS User Agent <b>1008</b> may request a delivery report for the multimedia message. In addition, the originator MMS User Agent <b>1008</b> may request a read-reply report when the user has viewed the multimedia message. The originator MMS Relay/Server <b>1004</b> will always provide a message identification for a multimedia message, which it has accepted for submission in the MM1_submit.RES <b>1104</b>. In the case of reply-charging, the MMS User Agent <b>1018</b>, which submits a multimedia message reply (i.e. the MMS User Agent that received the original multimedia message), will provide the message-ID of the original multimedia message, which it replies to in the MM1_submit.REQ <b>1102</b>. The MIME type of the multimedia content will always be identified in the MM1_submit.REQ <b>1102</b>. The originator MMS User Agent <b>1008</b> may add content in the MM1_submit.REQ <b>1102</b>. The originator MMS Relay/Server <b>1004</b> will indicate the status of the MM1_submit.REQ <b>1102</b> in the associated MM1_submit.RES <b>1104</b>. The reason code given in the status information element of the MM1_submit.RES <b>1102</b> may be supported with an explanatory text further qualifying the status. If this text is available in the status text information element the MMS User Agent <b>1008</b> should bring it to the user's attention. The choice of the language used in the status text information element is at the discretion of the MMS service provider. <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 2</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM1_submit.REQ. 1102,</entry></row><row><entry>as defined in WAP-209 and 3GPP 23.140</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="147PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Recipient address</entry><entry>Mandatory</entry><entry>The address of the recipient MMS User Agent</entry></row><row><entry /><entry /><entry>1018. Multiple addresses are possible.</entry></row><row><entry>Content type</entry><entry>Mandatory</entry><entry>The content type of the multimedia message's</entry></row><row><entry /><entry /><entry>content.</entry></row><row><entry>Sender address</entry><entry>Optional</entry><entry>The address of the multimedia message</entry></row><row><entry /><entry /><entry>originator.</entry></row><row><entry>Message class</entry><entry>Optional</entry><entry>The class of the multimedia message(e.g.,</entry></row><row><entry /><entry /><entry>personal, advertisement, information service)</entry></row><row><entry>Date and time</entry><entry>Optional</entry><entry>The time and date of the submission of the</entry></row><row><entry /><entry /><entry>multimedia message(time stamp).</entry></row><row><entry>Time of Expiry</entry><entry>Optional</entry><entry>The desired time of expiry for the multimedia</entry></row><row><entry /><entry /><entry>message or multimedia message reply.</entry></row><row><entry>Earliest delivery time</entry><entry>Optional</entry><entry>The earliest desired time of delivery of the</entry></row><row><entry /><entry /><entry>multimedia message to the recipient.</entry></row><row><entry>Delivery report</entry><entry>Optional</entry><entry>A request for delivery report.</entry></row><row><entry>Reply-Charging</entry><entry>Optional</entry><entry>A request for reply-charging.</entry></row><row><entry>Reply-Deadline</entry><entry>Optional</entry><entry>In case of reply-charging the latest time of</entry></row><row><entry /><entry /><entry>submission of replies granted to the recipient(s).</entry></row><row><entry>Priority</entry><entry>Optional</entry><entry>The priority (importance) of the message.</entry></row><row><entry>Sender visibility</entry><entry>Optional</entry><entry>A request to show or hide the sender's identity</entry></row><row><entry /><entry /><entry>when the message is delivered to the recipient.</entry></row><row><entry>Read reply</entry><entry>Optional</entry><entry>A request for read reply report.</entry></row><row><entry>Subject</entry><entry>Optional</entry><entry>The title of the whole multimedia message.</entry></row><row><entry>Reply-Charging-ID</entry><entry>Optional</entry><entry>In case of reply-charging when the multimedia</entry></row><row><entry /><entry /><entry>message reply is submitted within the</entry></row><row><entry /><entry /><entry>MM1_submit.REQ 1102 this is the identification</entry></row><row><entry /><entry /><entry>of the original multimedia message that is replied</entry></row><row><entry /><entry /><entry>to.</entry></row><row><entry>Content</entry><entry>Optional</entry><entry>The content of the multimedia message</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0071]<tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 3</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM1_submit.RES. 1104</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="119PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Request Status</entry><entry>Mandatory</entry><entry>The status of the multimedia message</entry></row><row><entry /><entry /><entry>submit request.</entry></row><row><entry>Request Status Text</entry><entry>Optional</entry><entry>Description which qualifies the status of</entry></row><row><entry /><entry /><entry>the multimedia message submit request.</entry></row><row><entry>Message ID</entry><entry>Mandatory</entry><entry>The identification of the multimedia</entry></row><row><entry /><entry /><entry>message given to an accepted</entry></row><row><entry /><entry /><entry>multimedia message.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0072] Multimedia Message Notification—This part of the MMS service covers the notification about multimedia message from the recipient MMS Relay/Server <b>1014</b> to the corresponding recipient MMS User Agent <b>1018</b> and involving abstract messages are outlined in Table 4 from type, and direction points of view. <tables id="TABLE-US-00004" num="4"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 4</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Abstract messages for notification of multimedia message in MMS</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="133PT" align="left" /><tbody valign="top"><row><entry>Abstract message</entry><entry>Type</entry><entry>Direction</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>MM1_notification.REQ 1110</entry><entry>Request</entry><entry>MMS Relay/Server 1014 −> MMS UA 1018</entry></row><row><entry>MM1_notification.RES 1112</entry><entry>Response</entry><entry>MMS UA 1018 −> MMS Relay/Server 1014</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0073] During normal operation and upon receiving the MM1_notification.REQ <b>1110</b>, the recipient MMS User Agent <b>1018</b> will respond with the MM1_notification.RES <b>1112</b> to the recipient MMS Relay/Server <b>1014</b> to acknowledge the successful reception of the MM1_notification.REQ <b>1110</b>. The MM1_notification.RES <b>1112</b> will unambiguously refer to the corresponding MM1_notification.REQ <b>1110</b>.
[0074] During abnormal operation, the recipient MMS UA <b>1018</b> will respond with a MM1_notification.RES <b>1112</b> encapsulating a status which indicates the reason the notification could not be processed. If the recipient MMS UA <b>1018</b> does not provide the MM1_notification.RES <b>1112</b>, the recipient MMS Relay/Server <b>1014</b> should be able to retransmit the notification at a later state.
[0075] The multimedia message originator address may be provided to recipient MMS User Agent <b>1018</b> in the MM1_notification.REQ <b>1110</b>. The recipient MMS User Agent <b>1018</b> will be provided an expiration period or time for the multimedia message. In case of reply-charging, the deadline for the latest time of submission of a multimedia message reply should be conveyed within the MM1_notification.REQ <b>1110</b>. In case of reply-charging, the recipient MMS Relay/Server <b>1014</b> may indicate in the MM1_notification.REQ <b>1110</b> that a reply to the notified original multimedia message is free of charge. The multimedia message will be qualified further by adding a message class and an approximate size to the multimedia message in the MM1_notification.REQ <b>1110</b>. The multimedia message may be qualified further by adding a subject to the multimedia message. Additional qualifiers may also be added. If the originator MMS User Agent <b>1008</b> has requested to have a delivery report, the recipient MMS Relay/Server <b>1014</b> may convey this information to the recipient MMS User Agent <b>1018</b> in the MM1_notification.REQ <b>1110</b>. The recipient MMS User Agent <b>1018</b> may indicate in the MM1_notification.RES <b>1112</b> that it does not want a delivery report to be created. In the case of reply-charging when a multimedia message reply is notified within the MM1_notification.REQ <b>1110</b> the recipient MMS Relay/Server <b>1014</b> should convey the identification of the original multimedia message replied to within the same MM1_notification.REQ <b>1110</b>. The recipient MMS Relay/Server <b>1014</b> will always provide a reference, e.g., URI, for the multimedia message in the MM1_notification.REQ <b>1110</b>. The recipient MMS User Agent/<b>1018</b> may indicate in the MM1_notification.RES <b>1112</b> how it intends the multimedia message to be handled, e.g. the immediate rejection of the multimedia message. <tables id="TABLE-US-00005" num="5"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 5</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM1_notification.REQ 1110,</entry></row><row><entry>as defined in WAP-209 and 3GPP 23.140.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="154PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Message class</entry><entry>Mandatory</entry><entry>The class of the multimedia message(e.g.,</entry></row><row><entry /><entry /><entry>personal, advertisement, information service;</entry></row><row><entry /><entry /><entry>default = personal)</entry></row><row><entry>Message size</entry><entry>Mandatory</entry><entry>The approximate size of the multimedia message.</entry></row><row><entry>Time of expiry</entry><entry>Mandatory</entry><entry>The time of expiry for the multimedia message.</entry></row><row><entry>Message Reference</entry><entry>Mandatory</entry><entry>A reference, e.g., URI, for the multimedia</entry></row><row><entry /><entry /><entry>message.</entry></row><row><entry>Subject</entry><entry>Optional</entry><entry>The title of the whole multimedia message.</entry></row><row><entry>Sender address</entry><entry>Optional</entry><entry>The address of the multimedia message originator.</entry></row><row><entry>Delivery report</entry><entry>Optional</entry><entry>Request for delivery report.</entry></row><row><entry>Reply-Charging</entry><entry>Optional</entry><entry>Information that a reply to this particular original</entry></row><row><entry /><entry /><entry>multimedia message is free of charge.</entry></row><row><entry>Reply-Deadline</entry><entry>Optional</entry><entry>In case of reply-charging the latest time of</entry></row><row><entry /><entry /><entry>submission of a reply granted to the recipient.</entry></row><row><entry>Reply-Charging-ID</entry><entry>Optional</entry><entry>The identification of the original multimedia</entry></row><row><entry /><entry /><entry>message replied to if this notification indicates a</entry></row><row><entry /><entry /><entry>multimedia message reply.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0076]<tables id="TABLE-US-00006" num="6"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 6</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM1_notification.RES 1112.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="119PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Multimedia</entry><entry>Optional</entry><entry>The status of the multimedia message's</entry></row><row><entry>Message Status</entry><entry /><entry>retrieval.</entry></row><row><entry>Report allowed</entry><entry>Optional</entry><entry>Request to allow or disallow the</entry></row><row><entry /><entry /><entry>sending of a delivery report to the</entry></row><row><entry /><entry /><entry>multimedia message originator.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0077] Retrieval of Multimedia Message—This part of MMS service covers the retrieval of a multimedia message. For retrieval purposes, a multimedia message will always be retrieved by the recipient MMS User Agent <b>1018</b> from the recipient MMS Relay/Server <b>1014</b>. Involved abstract messages are outlined in Table 7 from type and direction points of view. <tables id="TABLE-US-00007" num="7"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="280PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 7</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Abstract messages for retrieval of multimedia message in MMS</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="133PT" align="left" /><tbody valign="top"><row><entry>Abstract messages</entry><entry>Type</entry><entry>Direction</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>MM1_retrieve.REQ 1114</entry><entry>Request</entry><entry>MMS UA 1018 −> MMS Relay/Server 1014</entry></row><row><entry>MM1_retrieve.RES 1116</entry><entry>Response</entry><entry>MMS Relay/Server 1014 −> MMS UA 1018</entry></row><row><entry>MM1_acknowledgement.REQ 1118</entry><entry>Request</entry><entry>MMS UA 1018 −> MMS Relay/Server 1014</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0078] During normal operation, the recipient MMS User Agent <b>1018</b> will issue an MM1_retrieve.REQ <b>1114</b> to the recipient MMS Relay/Server <b>1014</b> to initiate the retrieval process. The recipient MMS Relay/Server <b>1014</b> will respond with an MM1_retrieve.RES <b>1116</b>, which contains multimedia messages control information and the multimedia message content. After receiving the MM1_retrieve.RES <b>1116</b>, the recipient MMS User Agent <b>1018</b> will send an MM1_acknowledgement.REQ <b>1118</b> to the corresponding MMS Relay/Server <b>1014</b>, if requested by the MMS Relay/Server <b>1014</b>. The MM1_acknowledgement.REQ <b>1118</b> will unambiguously refer to the corresponding MM1_retrieve.RES <b>1116</b>.
[0079] During abnormal operation, if the recipient MMS Relay/Server <b>1014</b> can not process the MM1_retrieve.REQ <b>1114</b>, for example due to invalid content location or expiration of the message, the recipient MMS Relay/Server <b>1014</b> will respond with either an MM1_retrieve.RES <b>1116</b> or a lower protocol layer error message encapsulating a status which indicates the reason to the recipient MMS User Agent <b>1018</b> the multimedia message was not delivered. If the recipient MMS Relay/Server <b>1014</b> does not provide the MM1_retrieve.RES <b>1116</b> or the lower protocol layer error message the recipient MMS User Agent <b>1018</b> should be able to recover.
[0080] The recipient MMS User Agent <b>1018</b> will always provide a reference, e.g., URI, for the multimedia message in the MM1_retrieve.REQ <b>1114</b>. The multimedia message originator address may be provided to the recipient MMS User Agent <b>1018</b> in the addressing-relevant information field of MM1_retrieve.RES <b>1116</b>. The multimedia message originator address will not be provided to the recipient MMS User Agent <b>1018</b> if the multimedia message originator has requested his or her address to be hidden from the multimedia message recipient. One or several address(es) of the multimedia message recipient(s) may be provided to the recipient MMS User Agent <b>1018</b> in the addressing-relevant information field(s) of the MM1_retrieve.RES <b>1116</b>. The MM1_retrieve.RES <b>1116</b> will carry the time and date of submission of the multimedia message or the time and date of the forwarding of the multimedia message. In the case of reply-charging, the deadline for the latest time of submission of a multimedia message reply will be conveyed within the MM1_retrieve.RES <b>1116</b>. Information about class, priority, subject of the multimedia message will be included in the MM1_retrieve.RES <b>1116</b> according to their presence and value received at the recipient MMS Relay/Server <b>1014</b>. Information about additional end-to-end qualifiers of the multimedia message should be included in the MM1_retrieve.RES <b>1116</b> according to their presence and value received at the recipient MMS Relay/Server <b>1014</b>. If the originator MMS User Agent <b>1008</b> requested a read-reply report, the recipient MMS Relay/Server <b>1014</b> will convey this information in the MM1_retrieve.RES <b>1116</b>. If the originator MMS User Agent <b>1008</b> requested a delivery report, the recipient MMS Relay/Server <b>1014</b> may convey this information to the recipient MMS User Agent <b>1018</b> in the MM1_retrieve.RES <b>1116</b>. If a request for a delivery report is included in the MM1_retrieve.RES <b>1116</b>, the recipient MMS User Agent <b>1018</b> will convey the information whether it accepts or denies the sending of a delivery report to the multimedia message originator in MM1_acknowledgement.REQ <b>1118</b>. If a delivery report is not requested, it is up to the recipient MMS User Agent <b>1018</b> to include this information in MM1_acknowledgement.REQ <b>1118</b> or not. In the case of reply-charging, the recipient MMS Relay/Server <b>1014</b> should indicate in the MM1_retrieve.RES <b>1116</b> that a reply to this particular original multimedia message is free of charge. The recipient MMS Relay/Server <b>1014</b> will provide a message identification for a message, which it has accepted for delivery in the MM1_retrieve.RES <b>1116</b>. In the case of reply-charging, the recipient MMS Relay/Server <b>1014</b> will provide the message-ID of the original multimedia message which is replied to in the MM1_retrieve.RES <b>1116</b>. The type of the multimedia message content will always be identified in the MM1_retrieve.RES <b>1116</b>. The content of the multimedia message, if added by the originator MMS User Agent <b>1008</b> may be conveyed in the MM1_retrieve.RES <b>1116</b>. In case of normal operation, the recipient MMS Relay/Server <b>1014</b> may indicate in the MM1_retrieve.RES <b>1116</b> that the retrieval of the multimedia message was processed correctly. In case of abnormal operation, the recipient MMS Relay/Server <b>1014</b> will indicate in the MM1_retrieve.RES <b>1116</b> the reason why the multimedia message could not be retrieved. The corresponding reason codes should cover application level errors (e.g. ‘the media format could not be converted’, ‘insufficient credit for retrieval’). Lower layer errors may be handled by corresponding protocols. A Counter indicating the number of times the particular multimedia message was forwarded may also be included. The address of the forwarding MMS User Agent and multiple addresses are possible. In the multiple address case, this is a sequential list of the address(es) of the forwarding MMS User Agents who forwarded the same multimedia message. <tables id="TABLE-US-00008" num="8"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 8</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM1_retrieve.REQ 1114.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="119PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Message Reference</entry><entry>Mandatory</entry><entry>Location of the content of the</entry></row><row><entry /><entry /><entry>multimedia message to be retrieved.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0081]<tables id="TABLE-US-00009" num="9"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 9</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM1_retrieve.RES 1116,</entry></row><row><entry>as defined in WAP-209 and 3GPP 23.140.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="154PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Message ID</entry><entry>Mandatory</entry><entry>The message ID of the multimedia message.</entry></row><row><entry>Sender address</entry><entry>Conditional</entry><entry>The address of the originator of multimedia</entry></row><row><entry /><entry /><entry>message unless the originator MMS User Agent</entry></row><row><entry /><entry /><entry>1008 has requested her address to be hidden from</entry></row><row><entry /><entry /><entry>the multimedia message recipient.</entry></row><row><entry>Content type</entry><entry>Mandatory</entry><entry>The content type of the multimedia message's</entry></row><row><entry /><entry /><entry>content.</entry></row><row><entry>Recipient address</entry><entry>Optional</entry><entry>The address of the multimedia message recipient.</entry></row><row><entry /><entry /><entry>Multiple addresses are possible.</entry></row><row><entry>Message class</entry><entry>Optional</entry><entry>The class of the message (e.g., personal,</entry></row><row><entry /><entry /><entry>advertisement, information service).</entry></row><row><entry>Date and time</entry><entry>Mandatory</entry><entry>The time and date of the submission of the</entry></row><row><entry /><entry /><entry>multimedia message or the time and date of the</entry></row><row><entry /><entry /><entry>forwarding of the multimedia mess age (time</entry></row><row><entry /><entry /><entry>stamp).</entry></row><row><entry>Delivery report</entry><entry>Optional</entry><entry>A request for delivery report.</entry></row><row><entry>Priority</entry><entry>Conditional</entry><entry>The priority (importance) of the message if</entry></row><row><entry /><entry /><entry>specified by the originator MMS User Agent 1008.</entry></row><row><entry>Read reply</entry><entry>Conditional</entry><entry>A request for read-reply report if the originator</entry></row><row><entry /><entry /><entry>MMS User Agent 1008 of the multimedia message</entry></row><row><entry /><entry /><entry>has requested a read-reply report.</entry></row><row><entry>Subject</entry><entry>Conditional</entry><entry>The title of the whole multimedia message if</entry></row><row><entry /><entry /><entry>specified by the originator MMS User Agent 1008</entry></row><row><entry /><entry /><entry>of the multimedia message.</entry></row><row><entry>Status</entry><entry>Optional</entry><entry>The status of the multimedia message retrieve</entry></row><row><entry /><entry /><entry>request.</entry></row><row><entry>Status Text</entry><entry>Optional</entry><entry>Description which qualifies the status of the</entry></row><row><entry /><entry /><entry>multimedia message retrieve request.</entry></row><row><entry>Reply-Charging</entry><entry>Optional</entry><entry>Information that a reply to this particular original</entry></row><row><entry /><entry /><entry>multimedia message is free of charge.</entry></row><row><entry>Reply-Charging-ID</entry><entry>Optional</entry><entry>In case of reply-charging this is the identification</entry></row><row><entry /><entry /><entry>of the original multimedia message replied to.</entry></row><row><entry>Reply-Deadline</entry><entry>Optional</entry><entry>In case of reply-charging the latest time of</entry></row><row><entry /><entry /><entry>submission of a reply granted to the recipient.</entry></row><row><entry>Forward_counter</entry><entry>Conditional</entry><entry>A Counter indicating the number of times the</entry></row><row><entry /><entry /><entry>particular multimedia message was forwarded.</entry></row><row><entry>Forwarded_by</entry><entry>Conditional</entry><entry>The address of the forwarding MMS User Agent.</entry></row><row><entry /><entry /><entry>Multiple addresses are possible. In the multiple</entry></row><row><entry /><entry /><entry>address case this is a Sequential list of the</entry></row><row><entry /><entry /><entry>address(es) of the forwarding MMS User Agents</entry></row><row><entry /><entry /><entry>who forwarded the same multimedia message.</entry></row><row><entry>Content</entry><entry>Conditional</entry><entry>The content of the multimedia message if specified</entry></row><row><entry /><entry /><entry>by the originator MMS User Agent 1008 of the</entry></row><row><entry /><entry /><entry>multimedia message.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0082]<tables id="TABLE-US-00010" num="10"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 10</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM1_acknowledgement.REQ 1118.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="112PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Report allowed</entry><entry>Optional</entry><entry>Request to allow or disallow the</entry></row><row><entry /><entry /><entry>sending of a delivery report to the</entry></row><row><entry /><entry /><entry>multimedia message originator.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0083] Forwarding of Multimedia Messages—This part of the MMS service describes the mechanism by which a forwarding MMS User Agent can request from the corresponding MMS Relay/Server, that a multimedia message for which the MMS User Agent is the intended recipient (and is notified of the multimedia message) be forwarded to other specified recipient(s) MMS User Agent(s) whose address(es) will be specified by the forwarding MMS User Agent, without having to first retrieve the multimedia message. For forwarding purposes a multimedia message forward request will always be requested by the forwarding MMS User Agent from the forwarding MMS Relay/Server. Involved abstract messages are outlined in Table 11 from type and direction points of view. <tables id="TABLE-US-00011" num="11"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 11</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Abstract messages for forwarding of multimedia</entry></row><row><entry>message without prior retrieval</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="105PT" align="left" /><tbody valign="top"><row><entry>Abstract messages</entry><entry>Type</entry><entry>Direction</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>MM1_forward.REQ</entry><entry>Request</entry><entry>MMS UA −> MMS Relay/Server</entry></row><row><entry>MM1_forward.RES</entry><entry>Response</entry><entry>MMS Relay/Server −> MMS UA</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0084] During normal operation, the forwarding MMS User Agent will issue an MM1_forward.REQ to the forwarding MMS Relay/Server, which contains MMS control information. The MMS Relay/Server will respond with an MM1_forward.RES, which provides the status of the request. The MM1_forward.RES will unambiguously refer to the corresponding MM1_forward.REQ. Support for MM1_forward.REQ is optional for the MMS User Agent. Support for MM1_forward.RES is optional for the MMS Relay/Server.
[0085] During abnormal operation, the MMS Relay/Server will respond with an MM1_forward.RES encapsulating a status which indicates the reason the request for forwarding was not accepted, e.g. no subscription, service not available, invalid content location, message expired. If the MMS Relay/Server does not provide the MM1_forward.RES the MMS User Agent should be able to recover.
[0086] One or several recipients of a multimedia message forward request will be indicated in the addressing-relevant information field(s) of the MM1_forward.REQ. The forwarding MMS User Agent may be indicated in addressing-relevant information field(s) of the MM1_forward.REQ. The forwarding MMS User Agent may time stamp the multimedia message. The forwarding MMS User Agent may request an earliest desired time of delivery of the multimedia message. The forwarding MMS User Agent may request an expiration period or time for the multimedia message. The forwarding MMS User Agent may request a delivery report for the multimedia message. In addition, the forwarding MMS User Agent may request a read-reply report when the user has viewed the multimedia message. The MMS Relay/Server of the forwarding MMS User Agent will always provide a message identification for a multimedia message forward request, which it has accepted for being forwarded in the MM1_forward.RES. The forwarding MMS User Agent will always provide the reference, e.g., URI, for the multimedia message in the MM1<sub>13</sub>forward.REQ which was provided in MM1_notification.REQ. The MMS Relay/Server of the forwarding MMS User Agent will indicate the status of the MM1_forward.REQ in the MM1_forward.RES. The reason code given in the status information element of the MM1forward.RES may be supported with an explanatory text further qualifying the status. If this text is available in the status text information element the MMS User Agent should bring it to the user's attention. The choice of the language used in the status text information element is at the discretion of the MMS service provider. <tables id="TABLE-US-00012" num="12"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 12</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM1_forward.REQ.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="112PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Recipient address</entry><entry>Mandatory</entry><entry>The address of the recipient of the</entry></row><row><entry /><entry /><entry>forwarded multimedia message.</entry></row><row><entry /><entry /><entry>Multiple addresses are possible.</entry></row><row><entry>Forwarding address</entry><entry>Optional</entry><entry>The address of the forwarding MMS</entry></row><row><entry /><entry /><entry>User Agent.</entry></row><row><entry>Date and time</entry><entry>Optional</entry><entry>The time and date of the forwarding</entry></row><row><entry /><entry /><entry>of the multimedia message.</entry></row><row><entry>Time of Expiry</entry><entry>Optional</entry><entry>The desired time of expiry for the</entry></row><row><entry /><entry /><entry>forwarded multimedia message.</entry></row><row><entry>Earliest delivery time</entry><entry>Optional</entry><entry>The earliest desired time of delivery</entry></row><row><entry /><entry /><entry>of the multimedia message to the</entry></row><row><entry /><entry /><entry>recipient.</entry></row><row><entry>Delivery report</entry><entry>Optional</entry><entry>A request for delivery report for</entry></row><row><entry /><entry /><entry>the forwarded multimedia message.</entry></row><row><entry>Read reply</entry><entry>Optional</entry><entry>A request for read reply report.</entry></row><row><entry>Message Reference</entry><entry>Mandatory</entry><entry>A reference, e.g., URI, for the</entry></row><row><entry /><entry /><entry>multimedia message,</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0087]<tables id="TABLE-US-00013" num="13"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 13</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM1_forward.RES.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="119PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Status</entry><entry>Mandatory</entry><entry>The status of the multimedia message</entry></row><row><entry /><entry /><entry>Forward request.</entry></row><row><entry>Status Text</entry><entry>Optional</entry><entry>Description which qualifies the status of</entry></row><row><entry /><entry /><entry>the multimedia message Forward</entry></row><row><entry /><entry /><entry>request.</entry></row><row><entry>Message ID</entry><entry>Mandatory</entry><entry>The identification of the multimedia</entry></row><row><entry /><entry /><entry>message given to an accepted</entry></row><row><entry /><entry /><entry>multimedia message.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0088] Delivery Report—This part of MMS service covers the sending of delivery report from originator MMS Relay/Server <b>1004</b> to the originator MMS User Agent <b>1008</b>. The involved abstract message is outlined in Table 14 from type and direction points of view. <tables id="TABLE-US-00014" num="14"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="273PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 14</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Abstract message for sending delivery reports in MMS.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="105PT" align="left" /><colspec colname="2" colwidth="28PT" align="left" /><colspec colname="3" colwidth="140PT" align="left" /><tbody valign="top"><row><entry>Abstract Message</entry><entry>Type</entry><entry>Direction</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>MM1_delivery_report.REQ 1124</entry><entry>Request</entry><entry>MMS Relay/Server 1004 −> MMS UA 1008.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0089] During normal operation, the originator MMS Relay/Server <b>1004</b> will (subject to user, MMS service provider and/or operator preferences) create the MM1_delivery_report.REQ <b>1124</b> and send it to the originator MMS User Agent <b>1008</b> when the appropriate information for the creation of a delivery report is available. Support for MM1_delivery_report.REQ <b>112</b>K is optional for the origination <b>1008</b> MMS User Agent but mandatory for the origination MMS Relay/Server <b>1004</b>.
[0090] During abnormal operation, the MMS protocol framework does not provide mechanisms to cover and handle the unsuccessful delivery of MM1_delivery report.REQ <b>1124</b>. The underlying protocols will provide reliable transport of MM1_delivery_report.REQ <b>1124</b>.
[0091] In the MM1_delivery_report.REQ <b>1124</b>, the originator MMS Relay/Server <b>1004</b> will always provide the original message identification of the multimedia message that the delivery report corresponds to. The multimedia message recipient address will be provided to the originator MMS User Agent <b>1008</b> in the addressing-relevant information field of MM1_delivery_report.REQ <b>1124</b>. The MM1_delivery report.REQ <b>1124</b> will carry the time and date of handling of the multimedia message (e.g. retrieval, expiration, rejection). The MM1_delivery_report.REQ <b>1124</b> will carry the status of the multimedia message delivery, e.g. retrieved, forwarded, rejected, expired or indeterminate. <tables id="TABLE-US-00015" num="15"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 15</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM1_delivery_report.REQ 1124.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="161PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Message ID</entry><entry>Mandatory</entry><entry>The identification of the original multimedia</entry></row><row><entry /><entry /><entry>message.</entry></row><row><entry>Recipient address</entry><entry>Mandatory</entry><entry>The address of the multimedia message recipient</entry></row><row><entry /><entry /><entry>of the original multimedia message.</entry></row><row><entry>Event Date</entry><entry>Mandatory</entry><entry>Date and time the multimedia message was</entry></row><row><entry /><entry /><entry>handled (retrieved, expired, rejected, etc.) (time stamp)</entry></row><row><entry>Multimedia</entry><entry>Mandatory</entry><entry>Status of the multimedia message, e.g. retrieved,</entry></row><row><entry>Message Status</entry><entry /><entry>forwarded, expired, rejected</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0092] Read-Reply Report—This part of MMS service covers the sending of read-reply report from the recipient MMS User Agent <b>1018</b> to the recipient MMS Relay/Server <b>1014</b> and the sending of read-reply report from the originator MMS Relay/Server <b>1004</b> to the originator MMS User Agent <b>1008</b>. The involved abstract messages are outlined in Table 16 from type and direction points of view. <tables id="TABLE-US-00016" num="16"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="280PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 16</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Abstract messages for sending and receiving read-reply report in MMS.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="119PT" align="left" /><colspec colname="2" colwidth="28PT" align="left" /><colspec colname="3" colwidth="133PT" align="left" /><tbody valign="top"><row><entry>Abstract messages</entry><entry>Type</entry><entry>Direction</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>MM1_read reply recipient.REQ 1126</entry><entry>Request</entry><entry>MMS UA 1018 −> MMS Relay/Server 1014</entry></row><row><entry>MM1_read reply originator.REQ 1132</entry><entry>Request</entry><entry>MMS Relay/Server 1004 −> MMS UA 1008</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0093] During normal operation, if a read-reply report is requested for an multimedia message, the recipient MMS User Agent <b>1018</b> may create the MM1_read_reply_recipient.REQ <b>1126</b> and send it to the recipient MMS Relay/Server <b>1014</b>. The originator MMS Relay/Server <b>1004</b> will (subject to user, MMS service provider and/or operator preferences) create the MM1_read_reply_originator.REQ <b>1132</b> and send it to the originator MMS User Agent <b>1008</b> when the appropriate information for the creation of a read-reply report is available. Support for MM1_read_reply_recipient.REQ <b>1126</b> and MM1_read_reply_originator.REQ <b>1132</b> is optional for the MMS User Agent <b>1008</b> and <b>1018</b> but mandatory for the MMS Relay/Server <b>1004</b> and <b>1014</b>.
[0094] During abnormal operation, the MMS protocol framework does not provide mechanisms to cover and handle the unsuccessful delivery of MM1_read_reply_recipient.REQ <b>1126</b> and MM1_read_reply_originator.REQ <b>1132</b>.
[0095] In the MM1_read_reply_recipient.REQ <b>1126</b>, the recipient MMS User Agent <b>1018</b> will provide the original message identification of the multimedia message that the read-reply report corresponds to. In the MM1_read_reply_originator.REQ <b>1132</b>, the originator MMS Relay/Server <b>1004</b> will provide the original message identification of the multimedia message that the read-reply report corresponds to. The multimedia message originator address will be provided in the addressing-relevant information field(s) of MM1_read_reply_recipient.REQ <b>1126</b>. The multimedia message recipient address will be provided in the addressing-relevant information field(s) of MM1_read_reply recipient.REQ <b>1126</b>. Both, the multimedia message recipient and multimedia message originator addresses will be provided in the addressing-relevant information field(s) of the MM1_read_reply_originator.REQ <b>1132</b>. If the multimedia message recipient address is not yet provided in the MM1_read_reply recipient.REQ <b>1126</b>, the MM1_read_reply_originator.REQ <b>1132</b> will carry the multimedia message recipient address set by the recipient MMS Relay/Server <b>1014</b>. The MM1_read_reply_recipient.REQ <b>1126</b> may carry the time and date of user handling the multimedia message depending on the status of the multimedia message. The MM1_read_reply_originator.REQ <b>1132</b> will carry the time-stamp from the corresponding MM1_read_reply_recipient.REQ <b>1126</b> if provided. If this time-stamp is not yet provided, the MM1_read_reply_originator.REQ <b>1132</b> will carry the time-stamp set by the recipient MMS Relay/Server <b>1014</b> multimedia message. Both the MM1_read_reply_recipient.REQ <b>1126</b> and MM1_read_reply_originator.REQ <b>1132</b> will carry the status of the multimedia message retrieval, e.g. read or without being read. <tables id="TABLE-US-00017" num="17"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 17</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM1_read_reply recipient.REQ 1126.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="154PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Recipient address</entry><entry>Mandatory</entry><entry>The address of the multimedia message recipient of</entry></row><row><entry /><entry /><entry>the original multimedia message, i,e, the originator</entry></row><row><entry /><entry /><entry>of the read-reply report.</entry></row><row><entry>Originator address</entry><entry>Mandatory</entry><entry>The address of the multimedia message originator</entry></row><row><entry /><entry /><entry>of the original multimedia message, i,e, the</entry></row><row><entry /><entry /><entry>recipient of the read-reply report.</entry></row><row><entry>Message-ID</entry><entry>Mandatory</entry><entry>The message ID of the original multimedia</entry></row><row><entry /><entry /><entry>message.</entry></row><row><entry>Date and Time</entry><entry>Optional</entry><entry>Date and time the multimedia message was handled</entry></row><row><entry /><entry /><entry>(read, deleted without being read, etc.) (time stamp)</entry></row><row><entry>Status</entry><entry>Mandatory</entry><entry>Status of the multimedia message, e.g. Read,</entry></row><row><entry /><entry /><entry>Deleted without being read</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0096]<tables id="TABLE-US-00018" num="18"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 18</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM1_read_reply originator.REQ 1132.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="154PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Recipient address</entry><entry>Mandatory</entry><entry>The address of the multimedia message recipient of</entry></row><row><entry /><entry /><entry>the original multimedia message, i,e, the originator</entry></row><row><entry /><entry /><entry>of the read-reply report.</entry></row><row><entry>Originator address</entry><entry>Mandatory</entry><entry>The address of the multimedia message originator</entry></row><row><entry /><entry /><entry>of the original multimedia message, i,e, the</entry></row><row><entry /><entry /><entry>recipient of the read-reply report.</entry></row><row><entry>Message-ID</entry><entry>Mandatory</entry><entry>The message ID of the original multimedia</entry></row><row><entry /><entry /><entry>message.</entry></row><row><entry>Date and Time</entry><entry>Mandatory</entry><entry>Date and time the multimedia message was handled</entry></row><row><entry /><entry /><entry>(read, deleted without being read, etc.) (time stamp)</entry></row><row><entry>Multimedia Message</entry><entry>Mandatory</entry><entry>Status of the multimedia message, e.g. Read,</entry></row><row><entry>Status</entry><entry /><entry>Deleted without being read</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0097] The interworking between MMS Relay/Servers and External Servers may be based on the Internet Protocol, IP. Messages between MMS Relay/Servers and External Servers, also referred to as MM3 messages, should be based upon existing standards e.g. HTTP, SMTP. In addition, MMS service providers or network operators may develop solutions for their particular needs.
[0098] Sending of multimedia messages—For the purpose of sending a multimedia message to an external messaging system, the originator MMS Relay/Server should convert the multimedia message into a format appropriate for the external messaging system. The originator MMS Relay/Server should use the information elements associated with the multimedia message to define the control information needed for the transfer protocol in use. The originator MMS Relay/Server may use the information elements associated with the multimedia message to convey these as part of the converted message. For example, the originator MMS Relay/Server should use the recipient's address(es) as indicated in the corresponding multimedia message to route the converted message towards its recipient(s). In addition, the originator MMS Relay/Server may convey message class, priority and subject of the associated multimedia message as part of the converted message.
[0099] Receiving of messages—For the purpose of receiving a message from an external messaging system, the recipient MMS Relay/Server should convert incoming messages to the multimedia message format in use by the recipient(s) that form part of the recipient MMS Service Provider's domain. The recipient MMS Relay/Server may convert control information received from the External Server into appropriate information elements of an multimedia message. For example, the recipient MMS Relay/Server should use the MSISDNs associated with an SMS-Short Message to define the sender's and recipient's addresses of the multimedia message. In addition the MMS Relay/Server may map a priority assigned to an incoming SMS-Short Message to the multimedia message's priority.
[0100] Discovery of new messages on External Servers—Different mechanisms may be used for the discovery of incoming messages from external messaging systems. For example, forwarding of messages from the External Server to the MMS Relay/Server, based on criteria defined by the user or application; notification of messages from an External Server, followed by retrieval by the MMS User Agent via the MMS Relay/Server; periodic polling for messages on External Server, followed by retrieval by the MMS User Agent via the MMS Relay/Server.
[0101] Routing Forward of a Multimedia Message—This part of MMS service covers the routing forward of an multimedia message from an originator MMS Relay/Server <b>1004</b> to a recipient MMS Relay/Server <b>1014</b> of different MMSEs. Involved abstract messages are outlined in Table 19 from type and direction points of view. <tables id="TABLE-US-00019" num="19"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 19</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Abstract messages for forwarding of multimedia message in MMS.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="147PT" align="left" /><tbody valign="top"><row><entry>Abstract messages</entry><entry>Type</entry><entry>Direction</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>MM4_forward.REQ 1106</entry><entry>Request</entry><entry>Originator MMS Relay/Server 1004 −> recipient</entry></row><row><entry /><entry /><entry>MMS Relay/Server 1014.</entry></row><row><entry>MM4_forward.RES 1108</entry><entry>Response</entry><entry>Recipient MMS Relay/Server 1014 −> originator</entry></row><row><entry /><entry /><entry>MMS Relay/Server 1004.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0102] During normal operation and after successfull discovery of its peer entity, the originator MMS Relay/Server <b>1104</b> will route a multimedia message forward to the recipient MMS Relay/Server <b>1014</b> using the MM4_forward.REQ <b>1106</b>, which contains MMS control information and the multimedia message content. The recipient MMS Relay/Server <b>1014</b> will respond with a MM4_forward.RES <b>1108</b>, which provides the status of the request if an MM4_forward.RES <b>1108</b> was requested. Support for MM4_forward.REQ <b>1106</b> and MM4_forward.RES <b>1108</b> is mandatory for the MMS Relay/Servers <b>1004</b> and <b>1014</b>.
[0103] During abnormal operation, the recipient MMS Relay/Server <b>1014</b> will respond with a MM4_forward.RES <b>1108</b>, which includes a status that indicates the reason the multimedia message was not accepted, e.g. no subscription, bad address, network not reachable, etc., if an MM4_forward.RES <b>1108</b> was requested.
[0104] The recipient(s) of a routed forward multimedia message will be indicated in the addressing-relevant information field(s) of the MM4_forward.REQ <b>1106</b>. If the addresses of several multimedia message recipients of the multimedia message are associated with a single MMSE then more than one multimedia message recipient may be indicated in the addressing-relevant information field(s) of the MM4_forward.REQ <b>1106</b>. Addresses of all multimedia message recipients of the multimedia message (including those that are not associated with the MMSE the multimedia message is forwarded to) will be conveyed in the MM4_forward.REQ <b>1106</b> for the multimedia message recipient's informational purposes. The multimedia message originator of a routed forward multimedia message shall be indicated in addressing-relevant information field(s) of the MM4_forward.REQ <b>1106</b>. If the originator MMS User Agent <b>1008</b> requested to hide its identity from the multimedia message recipient then the information about this request will also be conveyed in the MM4_forward.REQ <b>1106</b>. The MM4_forward.REQ <b>1106</b> will carry the time-stamp associated with the multimedia message. If the originator MMS User Agent <b>1008</b> requested an expiration period or time for the multimedia message, then this information will be conveyed in the MM4_forward.REQ <b>1106</b>. If the multimedia message is qualified further by message class, priority, subject and/or additional qualifiers then this information will be conveyed in the MM4_forward.REQ <b>1106</b>. If the originator MMS User Agent <b>1008</b> requested a delivery report for the multimedia message, then the information about this request will be conveyed in the MM4_forward.REQ <b>1106</b>. If, in addition, the originator MMS User Agent <b>1008</b> requested a read-reply report then the information about this request will be conveyed in the MM4_forward.REQ <b>1106</b>. The originator MMS Relay/Server <b>1008</b> will always provide a unique message identification for a multimedia message, which it routed forward to a peer MMS Relay/Server in the MM4_forward.REQ <b>1106</b>. The type of the multimedia content will always be identified in the MM4_forward.REQ <b>1106</b>. The originator MMS Relay/Server <b>1004</b> may request a MM4_forward.RES <b>1108</b> from the recipient MMS Relay/Server <b>1014</b> acknowledging the successful reception of the multimedia message. The recipient MMS Relay/Server <b>1014</b> will indicate the status of the MM4_forward.REQ <b>1106</b> in the associated MM4_forward.RES <b>1108</b> if requested. The type of message used on reference point MM4 will also be indicated in the MM4_forward.REQ <b>1106</b> and MM4_forward.RES <b>1108</b>. If the originator MMS Relay/Server <b>1004</b> requests an MM4_forward.RES <b>1108</b> from the recipient MMS Relay/Server <b>1014</b>, it will provide a transaction identification within an MM4_forward.REQ <b>1106</b>. The MM4_forward.RES <b>1108</b> will unambiguously refer to the corresponding MM4_forward.REQ <b>1106</b> using the same transaction identification. A Counter indicating the number of times the particular multimedia message was forwarded may also be involved. The address of the forwarding MMS User Agent and multiple addresses are possible. In the multiple address case, this is a Sequential list of the address(es) of the forwarding MMS User Agents who forwarded the same multimedia message. The MMS protocol will provide unique means to identify the current version in the particular protocol environment. <tables id="TABLE-US-00020" num="20"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 20</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM4_forward.REQ 1106,</entry></row><row><entry>as defined in WAP-209 and 3GPP 23.149.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="154PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>3GPP MMS Version</entry><entry>Mandatory</entry><entry>The MMS version of the originator MMS</entry></row><row><entry /><entry /><entry>Relay/Server 1004 as defined by this</entry></row><row><entry /><entry /><entry>specification.</entry></row><row><entry>Message Type</entry><entry>Mandatory</entry><entry>The type of message used on reference point</entry></row><row><entry /><entry /><entry>MM4: “MM4_forward.REQ”.</entry></row><row><entry>Transaction ID</entry><entry>Mandatory</entry><entry>The identification of the MM4_forward.REQ/</entry></row><row><entry /><entry /><entry>MM4_forward.RES pair.</entry></row><row><entry>Message ID</entry><entry>Mandatory</entry><entry>The identification of the multimedia message.</entry></row><row><entry>Recipient(s) address</entry><entry>Mandatory</entry><entry>The address(es) of the multimedia message</entry></row><row><entry /><entry /><entry>recipient(s). Multiple addresses are possible.</entry></row><row><entry>Sender address</entry><entry>Mandatory</entry><entry>The address of the multimedia message</entry></row><row><entry /><entry /><entry>originator.</entry></row><row><entry>Content type</entry><entry>Mandatory</entry><entry>The content type of the multimedia message's</entry></row><row><entry /><entry /><entry>content.</entry></row><row><entry>Message class</entry><entry>Conditional</entry><entry>The class of the multimedia message (e.g.,</entry></row><row><entry /><entry /><entry>personal, advertisement, information service) if</entry></row><row><entry /><entry /><entry>specified by the originator MMS User Agent 1008.</entry></row><row><entry>Date and time</entry><entry>Mandatory</entry><entry>The time and date of the submission of the</entry></row><row><entry /><entry /><entry>multimedia message(time stamp) or the time and</entry></row><row><entry /><entry /><entry>date of the forwarding of the multimedia</entry></row><row><entry /><entry /><entry>message.</entry></row><row><entry>Time of Expiry</entry><entry>Conditional</entry><entry>The desired time of expiry for the multimedia</entry></row><row><entry /><entry /><entry>message if specified by the originator MMS User</entry></row><row><entry /><entry /><entry>Agent 1008.</entry></row><row><entry>Delivery report</entry><entry>Conditional</entry><entry>A request for delivery report if the originator</entry></row><row><entry /><entry /><entry>MMS User Agent 1008 has requested a delivery</entry></row><row><entry /><entry /><entry>report for the multimedia message.</entry></row><row><entry>Priority</entry><entry>Conditional</entry><entry>The priority (importance) of the message if</entry></row><row><entry /><entry /><entry>specified by the originator MMS User Agent</entry></row><row><entry /><entry /><entry>1008.</entry></row><row><entry>Sender visibility</entry><entry>Conditional</entry><entry>A request to show or hide the sender's identity</entry></row><row><entry /><entry /><entry>when the message is delivered to the multimedia</entry></row><row><entry /><entry /><entry>message recipient if the originator MMS User</entry></row><row><entry /><entry /><entry>Agent 1008 has requested her address to be</entry></row><row><entry /><entry /><entry>hidden from the recipient.</entry></row><row><entry>Read reply</entry><entry>Conditional</entry><entry>A request for read reply report if the originator</entry></row><row><entry /><entry /><entry>MMS User Agent 1008 has requested a read-</entry></row><row><entry /><entry /><entry>reply report for the multimedia message.</entry></row><row><entry>Subject</entry><entry>Conditional</entry><entry>The title of the whole multimedia message if</entry></row><row><entry /><entry /><entry>specified by the originator MMS User Agent 1008.</entry></row><row><entry>Acknowledgement</entry><entry>Optional</entry><entry>Request for MM4_forward.RES</entry></row><row><entry>Request</entry></row><row><entry>Forward_counter</entry><entry>Conditional</entry><entry>A counter indicating the number of times the</entry></row><row><entry /><entry /><entry>particular multimedia message was forwarded.</entry></row><row><entry>Forwarded_by</entry><entry>Conditional</entry><entry>The address of the forwarding MMS User Agent.</entry></row><row><entry /><entry /><entry>Multiple addresses are possible. In the multiple</entry></row><row><entry /><entry /><entry>address case this is a Sequential list of the</entry></row><row><entry /><entry /><entry>address(es) of the forwarding MMS User Agents</entry></row><row><entry /><entry /><entry>who forwarded the same multimedia message.</entry></row><row><entry>Content</entry><entry>Conditional</entry><entry>The unaltered content of the multimedia message</entry></row><row><entry /><entry /><entry>if specified by the originator MMS User Agent</entry></row><row><entry /><entry /><entry>1008.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0105]<tables id="TABLE-US-00021" num="21"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 21</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM4_forward.RES 1108.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="119PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>3GPP MMS Version</entry><entry>Mandatory</entry><entry>The MMS version of the recipient MMS</entry></row><row><entry /><entry /><entry>Relay/Server 1014 as defined by this</entry></row><row><entry /><entry /><entry>specification.</entry></row><row><entry>Message Type</entry><entry>Mandatory</entry><entry>The type of message used on reference</entry></row><row><entry /><entry /><entry>point MM4: “MM4_forward.RES”.</entry></row><row><entry>Transaction ID</entry><entry>Mandatory</entry><entry>The identification of the</entry></row><row><entry /><entry /><entry>MM4_forward.REQ/</entry></row><row><entry /><entry /><entry>MM4_forward.RES pair.</entry></row><row><entry>Message ID</entry><entry>Mandatory</entry><entry>The Message ID of the multimedia</entry></row><row><entry /><entry /><entry>message which has been forwarded</entry></row><row><entry /><entry /><entry>within the corresponding</entry></row><row><entry /><entry /><entry>MM4_forward.REQ</entry></row><row><entry>Request Status Code</entry><entry>Mandatory</entry><entry>The status of the request to route</entry></row><row><entry /><entry /><entry>forward the multimedia message.</entry></row><row><entry>Status text</entry><entry>Optional</entry><entry>Status text corresponding to the code</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0106] Routing Forward of a Delivery Report—This part of MMS service covers the routing forward of a delivery report from recipient MMS Relay/Server <b>1014</b> to originator MMS Relay/Server <b>1004</b>. The involved abstract messages are outlined in Table 22 from type and direction points of view. <tables id="TABLE-US-00022" num="22"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="287PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 22</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Abstract messages for routing delivery reports forward in MMS.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="105PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="147PT" align="left" /><tbody valign="top"><row><entry>Abstract Message</entry><entry>Type</entry><entry>Direction</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>MM4_delivery report.REQ 1120</entry><entry>Request</entry><entry>Recipient MMS Relay/Server 1014 −> originator</entry></row><row><entry /><entry /><entry>MMS Relay/Server 1004</entry></row><row><entry>MM4_delivery report.RES 1122</entry><entry>Response</entry><entry>Originator MMS Relay/Server 1004 −> recipient</entry></row><row><entry /><entry /><entry>MMS Relay/Server 1014</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0107] During normal operation and after successful discovery of its peer entity, the recipient MMS Relay/Server <b>1014</b> will route a previously created delivery report forward to the originator MMS Relay/Server <b>1004</b> using the MM4_delivery_report.REQ <b>1120</b>, which contains MMS control information only. The originator MMS Relay/Server <b>1004</b> will respond with a MM4_delivery report.RES <b>1122</b>, which provides the status of the MM4_delivery_report.REQ <b>1120</b> if an MM4_delivery_report.RES <b>1122</b> was requested. Support for MM4_delivery_report.REQ <b>1120</b> and MM4_delivery_report.RES <b>1122</b> is mandatory for the MMS Relay/Servers <b>1004</b> and <b>1014</b>.
[0108] During abnormal operation, the originator MMS Relay/Server <b>1004</b> will respond with a MM4_delivery_report.RES <b>1122</b> encapsulating a status which indicates the reason the delivery report was not accepted, if an MM4_delivery_report.RES <b>1122</b> was requested.
[0109] Both the address of the recipient (which is the multimedia message originator) and the address of the originator (which is the multimedia message recipient) of a routed forward delivery report will be provided to the originator MMS Relay/Server <b>1004</b> in the addressing-relevant information field of MM4_delivery_report.REQ <b>1120</b>. In the MM4_delivery_report.REQ <b>1120</b> the recipient MMS Relay/Server <b>1014</b> will always provide the original message identification of the multimedia message that the delivery report corresponds to as obtained from the associated MM4_forward.REQ <b>1106</b> multimedia message. The MM4_delivery_report.REQ <b>1120</b> will carry the time and date of handling of the multimedia message (e.g. retrieval, expiry, rejection). The MM4_delivery_report.REQ <b>1120</b> will carry the status of the multimedia message delivery, e.g. retrieved, rejected, expired or indeterminate. The recipient MMS Relay/Server <b>1014</b> may request a MM4_delivery_report.RES <b>1122</b> from the originator MMS Relay/Server <b>1004</b> acknowledging the successful reception of the delivery report. The originator MMS Relay/Server <b>1004</b> will indicate the status of the MM4_delivery_report.REQ <b>1120</b> in the associated MM4_delivery report.RES <b>1122</b> if requested. The MMS protocol will provide unique means to identify the current version in the particular protocol environment. The type of message used will be indicated in MM4_delivery_report.REQ <b>1120</b> and MM4_delivery report.RES <b>1122</b>. If the originator MMS Relay/Server <b>1004</b> requests an MM4_delivery_report.RES <b>1122</b> from the recipient MMS Relay/Server <b>1014</b>, it will provide a transaction identification within a MM4_delivery_report.REQ <b>1120</b>. The MM4_delivery_report.RES <b>1122</b> will unambiguously refer to the corresponding MM4_delivery_report.REQ <b>1120</b> using the same transaction identification. <tables id="TABLE-US-00023" num="23"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 23</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM4_delivery_report.REQ 1120,</entry></row><row><entry>as defined in 3GPP 23.140.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="154PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>3GPP MMS Version</entry><entry>Mandatory</entry><entry>The MMS version of the recipient MMS</entry></row><row><entry /><entry /><entry>Relay/Server 1014 as defined by this</entry></row><row><entry /><entry /><entry>specification.</entry></row><row><entry>Message Type</entry><entry>Mandatory</entry><entry>The type of message used on reference point MM4:</entry></row><row><entry /><entry /><entry>“MM4_delivery_report.REQ”.</entry></row><row><entry>Transaction ID</entry><entry>Mandatory</entry><entry>The identification of the</entry></row><row><entry /><entry /><entry>MM4_delivery_report.REQ/</entry></row><row><entry /><entry /><entry>MM4_delivery_report.RES pair.</entry></row><row><entry>MM Message ID</entry><entry>Mandatory</entry><entry>The identification of the original multimedia</entry></row><row><entry /><entry /><entry>message.</entry></row><row><entry>Recipient address</entry><entry>Mandatory</entry><entry>The address of the multimedia message</entry></row><row><entry /><entry /><entry>recipient of the original multimedia message.</entry></row><row><entry>Sender address</entry><entry>Mandatory</entry><entry>The address of the multimedia message</entry></row><row><entry /><entry /><entry>originator of the original multimedia message.</entry></row><row><entry>MM Date and time</entry><entry>Mandatory</entry><entry>Date and time the multimedia message was</entry></row><row><entry /><entry /><entry>handled (retrieved, expired, rejected, etc.)</entry></row><row><entry>Acknowledgement</entry><entry>Optional</entry><entry>Request for MM4_delivery_report.RES.</entry></row><row><entry>Request</entry></row><row><entry>MM Status Code</entry><entry>Mandatory</entry><entry>Status of the multimedia message, e.g.</entry></row><row><entry /><entry /><entry>retrieved, expired, rejected.</entry></row><row><entry>Status text</entry><entry>Optional</entry><entry>Status text corresponding to the Status code.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0110]<tables id="TABLE-US-00024" num="24"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 24</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the</entry></row><row><entry>MM4_delivery_report.RES 1122.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="133PT" align="left" /><tbody valign="top"><row><entry>Information</entry><entry /><entry /></row><row><entry>element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>3GPP MMS</entry><entry>Mandatory</entry><entry>The MMS version of the recipient MMS</entry></row><row><entry>Version</entry><entry /><entry>Relay/Server as defined by this specification.</entry></row><row><entry>Message Type</entry><entry>Mandatory</entry><entry>The type of message used on reference point</entry></row><row><entry /><entry /><entry>MM4: “MM4_delivery_reportRES”.</entry></row><row><entry>Transaction ID</entry><entry>Mandatory</entry><entry>The identification of the</entry></row><row><entry /><entry /><entry>MM4_delivery_report.REQ/</entry></row><row><entry /><entry /><entry>MM4_delivery_report.RES pair.</entry></row><row><entry>Message ID</entry><entry>Mandatory</entry><entry>The Message ID of the multimedia message</entry></row><row><entry /><entry /><entry>which caused the delivery report.</entry></row><row><entry>Request Status</entry><entry>Mandatory</entry><entry>The status of the associated</entry></row><row><entry>Code</entry><entry /><entry>MM4_delivery_report.REQ.</entry></row><row><entry>Status text</entry><entry>Optional</entry><entry>The text explanation corresponding to the</entry></row><row><entry /><entry /><entry>Status code.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0111] Routing Forward of a Read-Reply Report—This part of MMS service covers the routing forward of a read-reply report from the recipient MMS Relay/Server <b>1014</b> to the originator MMS Relay/Server <b>1004</b>. The involved abstract messages are outlined in Table 25 from type and direction points of view. <tables id="TABLE-US-00025" num="25"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="273PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 25</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Abstract messages for sending and receiving read-reply reports in MMS.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="147PT" align="left" /><tbody valign="top"><row><entry>Abstract messages</entry><entry>Type</entry><entry>Direction</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>MM4_read_reply.REQ 1128</entry><entry>Request</entry><entry>Recipient MMS Relay/Server 1014 −> originator</entry></row><row><entry /><entry /><entry>MMS Relay/Server 1004.</entry></row><row><entry>MM4_read_reply.RES 1130</entry><entry>Response</entry><entry>Originator MMS Relay/Server 1004 −> recipient</entry></row><row><entry /><entry /><entry>MMS Relay/Server 1014.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0112] During normal operation and after successful discovery of its peer entity, the recipient MMS Relay/Server <b>1014</b> will route a read-reply report forward that has been previously submitted by the recipient MMS User Agent <b>1018</b>, to the originator MMS Relay/Server <b>1004</b> using the MM4_read_reply_report.REQ <b>1128</b>, which contains MMS control information only. The recipient MMS Relay/Server <b>1014</b> will respond with a MM4_read_reply_report.RES <b>1130</b>, which provides the status of the MM4_read_reply_report.REQ <b>1128</b> if an MM4_read_reply_report.RES <b>1130</b> was requested. Support for MM4_read_reply_report.REQ <b>1128</b> and MM4_read_reply_report.RES <b>1130</b> is mandatory for the MMS Relay/Server <b>1004</b> and <b>1014</b>.
[0113] During abnormal operation, the originator MMS Relay/Server <b>1004</b> will respond with a MM4_read_reply_report.RES <b>1128</b> encapsulating a status which indicates the reason the read-reply report was not accepted, if an MM4_read_reply_report.RES <b>1128</b> was requested.
[0114] Both the address of the recipient (which is the multimedia message originator) and the address of the originator (which is the multimedia message recipient) of a routed forward read-reply report will be provided to the originator MMS Relay/Server <b>1004</b> in the addressing-relevant information field of MM4_read_reply_report.REQ <b>1128</b>. In the MM4_read_reply_report.REQ <b>1128</b>, the recipient MMS Relay/Server <b>1014</b> will always provide the original message identification of the multimedia message that the read-reply report corresponds to as obtained from the associated MM4_forward.REQ <b>1128</b> multimedia message. The MM4_read_reply_report.REQ <b>1128</b> will carry the time-stamp associated with the read-reply report. The MM4_read_reply_report.REQ <b>1128</b> will carry the status of the multimedia message retrieval, e.g. read or without being read. The recipient MMS Relay/Server <b>1014</b> may request a MM4_read_reply_report.RES <b>1130</b> from the originator MMS Relay/Server <b>1004</b> acknowledging the successful reception of the read-reply report. The originator MMS Relay/Server <b>1004</b> will indicate the status of the MM4_read_reply.REQ <b>1128</b> in the associated MM4_read_reply.RES <b>1130</b> if requested. The MMS protocol will provide unique means to identify the current version in the particular protocol environment. The type of message used will be indicated in MM4_read_reply.REQ <b>1128</b> and MM4_read_reply.RES <b>1130</b>. If the recipient MMS Relay/Server <b>1014</b> requests an MM4_read_reply_report.RES <b>1130</b> from the originator MMS Relay/Server <b>1004</b>, it will provide a transaction identification within an MM4_read_reply_report.REQ <b>1128</b>. The MM4_read_reply_report._RES <b>1130</b> will unambiguously refer to the corresponding MM4_read_reply_report.REQ <b>1128</b> using the same transaction identification. <tables id="TABLE-US-00026" num="26"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 26</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM4_read_reply_report.REQ, as defined in 3GPP 23.140.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="168PT" align="left" /><tbody valign="top"><row><entry>Information element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>3GPP MMS Version</entry><entry>Mandatory</entry><entry>The MMS version of the recipient MMS</entry></row><row><entry /><entry /><entry>Relay/Server as defined by this specification.</entry></row><row><entry>Message Type</entry><entry>Mandatory</entry><entry>The type of message used on reference point</entry></row><row><entry /><entry /><entry>MM4: “MM4_read_reply_report.REQ”.</entry></row><row><entry>Transaction ID</entry><entry>Mandatory</entry><entry>The identification of the</entry></row><row><entry /><entry /><entry>MM4_read_reply_report.REQ/</entry></row><row><entry /><entry /><entry>MM4_read_reply_report.RES pair.</entry></row><row><entry>Recipient address</entry><entry>Mandatory</entry><entry>The address of the multimedia message</entry></row><row><entry /><entry /><entry>recipient of the original MM, i.e. the originator</entry></row><row><entry /><entry /><entry>of the read-reply report.</entry></row><row><entry>Sender address</entry><entry>Mandatory</entry><entry>The address of the multimedia message</entry></row><row><entry /><entry /><entry>originator of the original MM, i.e. the recipient</entry></row><row><entry /><entry /><entry>of the read-reply report.</entry></row><row><entry>Message-ID</entry><entry>Mandatory</entry><entry>The message ID of the original multimedia</entry></row><row><entry /><entry /><entry>message.</entry></row><row><entry>Date and time</entry><entry>Mandatory</entry><entry>Date and time the multimedia message was</entry></row><row><entry /><entry /><entry>handled (read, deleted without being read, etc.)</entry></row><row><entry /><entry /><entry>(time stamp)</entry></row><row><entry>Acknowledgement</entry><entry>Optional</entry><entry>Request for MM4_delivery_report.RES</entry></row><row><entry>Request</entry></row><row><entry>MM Status Code</entry><entry>Mandatory</entry><entry>Status of the MM, e.g. Read, Deleted without being read</entry></row><row><entry>Status text</entry><entry>Optional</entry><entry>The text explanation corresponding to the</entry></row><row><entry /><entry /><entry>Status code</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0115]<tables id="TABLE-US-00027" num="27"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 27</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Information elements in the MM4_read_reply_report.RES.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="133PT" align="left" /><tbody valign="top"><row><entry>Information</entry><entry /><entry /></row><row><entry>element</entry><entry>Presence</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>3GPP MMS</entry><entry>Mandatory</entry><entry>The MMS version of the recipient MMS</entry></row><row><entry>Version</entry><entry /><entry>Relay/Server as defined by this specification.</entry></row><row><entry>MM Message</entry><entry>Mandatory</entry><entry>The type of message used on reference point</entry></row><row><entry>Type</entry><entry /><entry>MM4: “MM4_read_reply_report.RES”.</entry></row><row><entry>Transaction ID</entry><entry>Mandatory</entry><entry>The identification of the</entry></row><row><entry /><entry /><entry>MM4_read_reply_report.REQ/</entry></row><row><entry /><entry /><entry>MM4_read_reply_report.RES pair.</entry></row><row><entry>Request Status</entry><entry>Mandatory</entry><entry>The status of the associated</entry></row><row><entry>Code</entry><entry /><entry>MM4_read_reply_report.REQ.</entry></row><row><entry>Status text</entry><entry>Optional</entry><entry>The textual explanation for the Status code</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0116] Message format on MM4—All elements of a multimedia message will be included within a single SMTP “mail” message which will be organized as MIME type application/multipart. All multimedia message elements will be of standard MIME content types. In addition to the multimedia message elements this SMTP “mail” message should reflect all relevant MMS information elements. All other MMS-related messages, such as delivery reports, read-reply reports, transfer acknowledgements will each be transferred as a single SMTP “mail” message which will be organised as MIME type text/plain. This SMTP “mail” message should reflect all MMS information elements as defined above.
[0117] Message header fields—MMS information elements should be reflected as “header fields” according to STD 11 in the SMTP “mail” message. Some of the mappings are context dependent. For those information elements that cannot be mapped to standard STD 11 “header fields” the “X-” extensions mechanism will be used with an “X-MMS-” prefix. The mapping of information elements to commonly used (RFC 1327) or standard STD 11 “header fields” is shown in following tables.
[0118] MM4_forward.REQ Header Mappings—The MM4 Forward request header mappings are detailed below. <tables id="TABLE-US-00028" num="28"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 28</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>MM4_forward.REQ 1106 Information Elements to STD 11 Header</entry></row><row><entry>Mappings, as defined in 3GPP 23.140</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><tbody valign="top"><row><entry /><entry>Information element</entry><entry>STD 11 Headers</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>3GPP MMS Version</entry><entry>X-Mms-3GPP-MMS-</entry></row><row><entry /><entry /><entry>Version:</entry></row><row><entry /><entry>Message Type</entry><entry>X-Mms-Message-Type:</entry></row><row><entry /><entry>Transaction ID</entry><entry>X-Mms-Transaction-ID:</entry></row><row><entry /><entry>Message ID</entry><entry>X-Mms-Message-ID:</entry></row><row><entry /><entry>Recipient(s) address</entry><entry>To:, CC:</entry></row><row><entry /><entry>Sender address</entry><entry>From:</entry></row><row><entry /><entry>Content type</entry><entry>Content-Type:</entry></row><row><entry /><entry>Message class</entry><entry>X-Mms-Message-Class:</entry></row><row><entry /><entry>Date and time</entry><entry>Date:</entry></row><row><entry /><entry>Time of Expiry</entry><entry>X-Mms-Expiry:</entry></row><row><entry /><entry>Delivery report</entry><entry>X-Mms-Delivery-Report:</entry></row><row><entry /><entry>Priority</entry><entry>X-Mms-Priority:</entry></row><row><entry /><entry>Sender visibility</entry><entry>X-Mms-Sender-Visibility:</entry></row><row><entry /><entry>Read reply</entry><entry>X-Mms-Read-Reply:</entry></row><row><entry /><entry>Subject</entry><entry>Subject:</entry></row><row><entry /><entry>Acknowledgement</entry><entry>X-Mms-Ack-Request:</entry></row><row><entry /><entry>Request</entry></row><row><entry /><entry>Content</entry><entry><message body></entry></row><row><entry /><entry>—</entry><entry>Sender:</entry></row><row><entry /><entry>—</entry><entry>Message-ID:</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0119] The table above indicates the mappings from MM4_forward.REQ <b>1106</b> information elements to the corresponding STD 11 headers. The multimedia message Message-ID is not directly mapped to a corresponding STD 11 “Message-ID:” header. Each STD 11 message must have a unique message id, which is carried in the “Message-ID:” header. Content-type maps directly since both are defined as being MIME content types as specified in RFC 2046. The STD 11 “From:” header is determined by the mail user agent, or, in this case, the MMS User Agent. This corresponds to the multimedia message “Sender address”, as set by the MMS User Agent or MMS Relay/Server. STD 11 messages are required to have a Sender: header that indicates the originator address (as determined by the SMTP “MAIL From” command).
[0120] MM4_forward.RES Header Mappings—The MM4 Forward response information element mappings are detailed in the table below. The transmission of the Forward Response from the recipient MMS Relay/Server <b>1014</b> requires a properly addressed STD 11 message. While the addressing of the MM4_forward.REQ <b>1106</b> is clearly that of the intended recipients and originator, the MM4_forward.RES <b>1108</b> addressing is related to neither the recipients nor the originator of the original multimedia message. Instead, the MM4_forward.RES <b>1108</b> addressing is based on special systems addresses. MMS Service Provider should configure appropriate system addresses which will be used as both the recipient and originator of these administrative messages. It is suggested that the administrative addressing be based on the pattern:
[0121] system-user@mms-relay-host.mmse-domain. <tables id="TABLE-US-00029" num="29"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 29</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>MM4_forward.RES 1108 Information</entry></row><row><entry>Elements to STD 11 Header Mappings</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><tbody valign="top"><row><entry /><entry>Information element</entry><entry>STD Header</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>3GPP MMS Version</entry><entry>X-Mms-3GPP-MMS-</entry></row><row><entry /><entry /><entry>Version:</entry></row><row><entry /><entry>Message Type</entry><entry>X-Mms-Message-Type:</entry></row><row><entry /><entry>Transaction ID</entry><entry>X-Mms-Trans action-ID:</entry></row><row><entry /><entry>Message ID</entry><entry>X-Mms-Message-ID:</entry></row><row><entry /><entry>Request Status Code</entry><entry>X-Mms-Request-Status-</entry></row><row><entry /><entry /><entry>Code:</entry></row><row><entry /><entry>Status text</entry><entry>X-Mms-Status-Text:</entry></row><row><entry /><entry>—</entry><entry>Sender:</entry></row><row><entry /><entry>—</entry><entry>To:</entry></row><row><entry /><entry>—</entry><entry>Message-ID:</entry></row><row><entry /><entry>—</entry><entry>Date:</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0122] The Sender: and To: headers contain system addresses as described above, and do not map to MM4_forward.RES <b>1108</b> information elements. The STD 11 message requires a Date: header, but there currently is no corresponding MM4_forward.RES <b>1108</b> information element.
[0123] MM4_delivery_report.REQ <b>1120</b> Header Mappings—The mappings of the MM4_delivery_report.REQ <b>1120</b> information elements to STD 11 headers is detailed in the table below. <tables id="TABLE-US-00030" num="30"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 30</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>MM4_delivery_report.REQ 1120</entry></row><row><entry>Information Elements to STD 11 Header Mappings</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="112PT" align="left" /><tbody valign="top"><row><entry /><entry>Information element</entry><entry>STD 11 Header</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>3GPP MMS Version</entry><entry>X-Mms-3GPP-MMS-Version:</entry></row><row><entry /><entry>Message Type</entry><entry>X-Mms-Message-Type:</entry></row><row><entry /><entry>Transaction ID</entry><entry>X-Mms-Transaction-ID:</entry></row><row><entry /><entry>MM Message ID</entry><entry>X-Mms-Message-ID:</entry></row><row><entry /><entry>Recipient address</entry><entry>From:</entry></row><row><entry /><entry>Sender address</entry><entry>To:</entry></row><row><entry /><entry>MM Date and time</entry><entry>Date:</entry></row><row><entry /><entry>Acknowledgement</entry><entry>X-Mms-Ack-Request:</entry></row><row><entry /><entry>Request</entry></row><row><entry /><entry>MM Status Code</entry><entry>X-Mms-MM-Status-Code:</entry></row><row><entry /><entry>Status Text</entry><entry>X-Mms-Status-text:</entry></row><row><entry /><entry>—</entry><entry>Sender:</entry></row><row><entry /><entry>—</entry><entry>Message-ID:</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0124] The meaning of Recipient address is that of the original multimedia message, from whose MMS User Agent this Delivery-report is being generated. The meaning of Sender address is that of the original multimedia message, to whom the Delivery-report is being sent. The value of the STD 11 Sender: header is a system administration address, to which the corresponding response will be sent. The Sender: header value is automatically set to the system address of the MMS Relay/Server. The Message-ID: value is automatically generated by the MMS Relay/Server, in conformance to STD 11. The other header mappings from information elements are similar to those already described above.
[0125] MM4_delivery_report.RES <b>1122</b> Header Mappings—The mappings of the M4_delivery_report.RES <b>1122</b> information elements to STD 11 headers is detailed in the table below. <tables id="TABLE-US-00031" num="31"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 31</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>MM4_Delivery_report.RES Information Elements</entry></row><row><entry>to STD 11 Header Mappings</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="112PT" align="left" /><tbody valign="top"><row><entry /><entry>Information element</entry><entry>STD 11 Header</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>3GPP MMS Version</entry><entry>X-Mms-3GPP-MMS-Version:</entry></row><row><entry /><entry>MM Message Type</entry><entry>X-Mms-Message-Type:</entry></row><row><entry /><entry>Transaction ID</entry><entry>X-Mms-Transaction-ID:</entry></row><row><entry /><entry>Message ID</entry><entry>X-Mms-Message-ID:</entry></row><row><entry /><entry>Request Status Code</entry><entry>X-Mms-Request-Status-Code:</entry></row><row><entry /><entry>Status text</entry><entry>X-Mms-Status-Text:</entry></row><row><entry /><entry>—</entry><entry>Sender:</entry></row><row><entry /><entry>—</entry><entry>To:</entry></row><row><entry /><entry>—</entry><entry>Message-ID:</entry></row><row><entry /><entry>—</entry><entry>Date:</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0126] The Sender: header value is automatically set to the system address of the MMS Relay/Server that is replying to the MM4_delivery_report.REQ <b>1120</b>. The To: header value of the MM4_delivery_report.RES <b>1122</b> abstract message is obtained from the Sender: header value of the corresponding MM4_delivery_report.REQ <b>1120</b>. The Date and Message-ID headers, which have no corresponding MM4_forward.RES <b>1108</b> information attributes, are automatically provided values by the MMS Relay/Server.
[0127] MM4_read_reply_report.REQ <b>1128</b> Header Mappings—The mappings of the MM4_read_reply_report.REQ <b>1128</b> information elements to STD 11 headers is detailed in the table below. <tables id="TABLE-US-00032" num="32"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 32</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>MM4_read_reply_report.REQ 1126 Information</entry></row><row><entry>Elements to STD 11 Header Mappings.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="98PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><tbody valign="top"><row><entry /><entry>Information element</entry><entry>STD 11 Header</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>3GPP MMS Version</entry><entry>X-Mms-3GPP-MMS-Version:</entry></row><row><entry /><entry>Message Type</entry><entry>X-Mms-Message-Type:</entry></row><row><entry /><entry>Transaction ID</entry><entry>X-Mms-Transaction-ID:</entry></row><row><entry /><entry>Recipient address</entry><entry>From:</entry></row><row><entry /><entry>Sender address</entry><entry>To:</entry></row><row><entry /><entry>Message-ID</entry><entry>X-Mms-Message-ID:</entry></row><row><entry /><entry>Date and time</entry><entry>Date:</entry></row><row><entry /><entry>Acknowledgement Request</entry><entry>X-Mms-Ack-Request:</entry></row><row><entry /><entry>MM Status Code</entry><entry>X-Mms-MM-Status-Code:</entry></row><row><entry /><entry>Status text</entry><entry>X-Mms-Status-Text:</entry></row><row><entry /><entry>—</entry><entry>Sender:</entry></row><row><entry /><entry>—</entry><entry>Message-ID:</entry></row><row><entry /><entry>—</entry><entry>Date:</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0128] The meaning of Recipient address is that of the original multimedia message, from whose MMS User Agent this Read-reply-report is being generated. The meaning of Sender address is that of the original multimedia message, to whom the Read-reply-report is being sent. The value of the Sender: header is a system address, to which the corresponding MM4_read_reply_report.RES <b>1130</b> will be sent. The Message-ID:, and Date: headers, which have no corresponding information attribute in the MM4_read_reply_report.REQ <b>1128</b>, are automatically provided appropriate values by the MMS Relay/Server.
[0129] MM4_read_reply_report.RES <b>1130</b> Header Mappings—The mappings of the MM4_read_reply_report.RES <b>1130</b> information elements to STD 11 headers is detailed in the table below. <tables id="TABLE-US-00033" num="33"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 33</entry></row></thead><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>MM4_read_reply_report.RES 1130 Information</entry></row><row><entry>Elements to STD 11 Header Mappings.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="112PT" align="left" /><tbody valign="top"><row><entry /><entry>Information element</entry><entry>STD 11 Header</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>3GPP MMS Version</entry><entry>X-Mms-3GPP-MMS-Version:</entry></row><row><entry /><entry>MM Message Type</entry><entry>X-Mms-Message-Type:</entry></row><row><entry /><entry>Transaction ID</entry><entry>X-Mms-Trans action-ID:</entry></row><row><entry /><entry>Request Status Code</entry><entry>X-Mms-Request-Status-Code:</entry></row><row><entry /><entry>Status text</entry><entry>X-Mms-Status-Text:</entry></row><row><entry /><entry>—</entry><entry>Sender:</entry></row><row><entry /><entry>—</entry><entry>To:</entry></row><row><entry /><entry>—</entry><entry>Message-ID:</entry></row><row><entry /><entry>—</entry><entry>Date:</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0130] The Sender: header value will be the system address of the MMS Relay/Server that is replying to the MM4_delivery_report.REQ <b>1128</b>. The To: header value of the MM4_delivery_report.RES <b>1130</b> abstract message will be obtained from the corresponding MM4_delivery_report.REQ <b>1128</b> Sender: header value. The Date: and Message-ID: headers, which do not have corresponding information elements, will be provided appropriate values automatically by the MMS Server/Relay.
[0131] Now referring to FIG. 12 a flow chart of the MMC multimedia message processing is shown. Whenever a MMC receives a multimedia message from any source as shown in block <b>1202</b>, the present invention determines whether the multimedia message should be processed using a customized process in decision block <b>1202</b>. If the multimedia message should not be processed using a customized process, as determined in decision block <b>1204</b>, the present invention processes the multimedia message by executing standard processing instructions corresponding to a standard process in block <b>1206</b>. Thereafter, the present invention will go to block <b>1202</b> and receive the next multimedia message. If, however, the multimedia message should be processed using a customized process, as determined in decision block <b>1204</b>, the present invention retrieves one or more customized processing instructions from a database in block <b>1208</b> and processes the multimedia message using the one or more customized processing instructions in block <b>1210</b>. Thereafter, the present invention will go to block <b>1202</b> and receive the next multimedia message. This method can be implemented using a computer program embodied on a computer readable medium wherein each block represents a code segment.
[0132] The standard process and standardized processing instructions are the basic or minimum instructions required by a particular MMS to process a multimedia message. The multimedia message may include any of the messages described above in reference to FIGS. 10 and 11. As a result, some of the information elements will be dictated by standard processing instructions and others will be dictated by customized processing instructions.
[0133] The customized processing instructions may include all or part of the standard process or implement one or more subscriber preferences. The one or more subscriber preferences can be set by an originating subscriber of the multimedia message or set by a destination subscriber of the multimedia message. In addition, the customized processing instructions may include a delivery priority for the multimedia message, an instruction to forward the multimedia message to one or more other destinations, an instruction to copy and store the multimedia message on server, an instruction to send the multimedia message to an alternate destination if a destination device is not capable of receiving the multimedia message, or an instruction to store the multimedia message and not deliver the multimedia message to a destination device whenever the destination device is roaming.
[0134] Moreover, the customized processing instructions may implement one or more operator services, such as a prepay service plan, maintain a contracted quality of service, or a corporate service plan. The customized processing instructions may also comprise determining one or more multimedia capabilities of a destination device and modifying the multimedia message to be compatible with the destination device based on the one or more multimedia capabilities, or determining one or more multimedia capabilities of a destination device and reformatting the multimedia message to be compatible with the destination device based on the one or more multimedia capabilities. The customized processing instructions may also implement one or more licensing functions, such as verifying that a source device is authorized to send the multimedia message, verifying that a destination device is authorized to receive the multimedia message, restricting unauthorized copying of the multimedia message, limiting a transmission rate for the multimedia message, or delaying delivery of the multimedia message when a message throughput limit has been exceeded.
[0135] The embodiments and examples set forth herein are presented to best explain the present invention and its practical application and to thereby enable those skilled in the art to make and utilize the invention. However, those skilled in the art will recognize that the foregoing description and examples have been presented for the purpose of illustration and example only. The description as set forth is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching without departing from the spirit and scope of the following claims.
Contents5
10 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US9935922B2 | Cited by | United States of America | Applicant |
| WO2006023302A2 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US2008107251A1 | Cited by | United States of America | Pre-grant |
| US8732239B2 | Cited by | United States of America | Search report |
| US11445072B2 | Cited by | United States of America | Applicant |
| US8374639B2 | Cited by | United States of America | Applicant |
| US2006280157A1 | Cited by | United States of America | Pre-grant |
| US9647986B2 | Cited by | United States of America | Applicant |
| US2008172469A1 | Cited by | United States of America | Pre-grant |
| US9215217B2 | Cited by | United States of America | Applicant |
| US8195205B2 | Cited by | United States of America | Search report |
| US9277092B2 | Cited by | United States of America | Applicant |
| US2009150400A1 | Cited by | United States of America | Pre-grant |
| US7577150B2 | Cited by | United States of America | Applicant |
| US2010161672A1 | Cited by | United States of America | Pre-grant |
| US7366530B2 | Cited by | United States of America | Applicant |
| US2009054040A1 | Cited by | United States of America | Pre-grant |
| US2008137151A1 | Cited by | United States of America | Pre-grant |
| US2010222029A1 | Cited by | United States of America | Pre-grant |
| US8619561B2 | Cited by | United States of America | Search report |
| US8850061B2 | Cited by | United States of America | Search report |
| US2005003838A1 | Cited by | United States of America | Pre-grant |
| US10887474B2 | Cited by | United States of America | Applicant |
| US2007237318A1 | Cited by | United States of America | Pre-grant |
| US2008155113A1 | Cited by | United States of America | Pre-grant |
| US7653185B2 | Cited by | United States of America | Search report |
| US2005186979A1 | Cited by | United States of America | Pre-grant |
| US8737583B2 | Cited by | United States of America | Applicant |
| US2007130365A1 | Cited by | United States of America | Pre-grant |
| US2020204641A1 | Cited by | United States of America | Search report |
| US7430284B2 | Cited by | United States of America | Applicant |
| EP2483792A1 | Cited by | European Patent Office (EPO) | Search report |
| US9369306B2 | Cited by | United States of America | Search report |
| US2009054039A1 | Cited by | United States of America | Pre-grant |
| US2004218736A1 | Cited by | United States of America | Pre-grant |
| US9439052B2 | Cited by | United States of America | Search report |
| US11290416B2 | Cited by | United States of America | Search report |
| WO2005125099A2 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US2005136915A1 | Cited by | United States of America | Pre-grant |
| US2007177195A1 | Cited by | United States of America | Pre-grant |
| US2006023646A1 | Cited by | United States of America | Pre-grant |
| US2005075093A1 | Cited by | United States of America | Pre-grant |
| US8542660B2 | Cited by | United States of America | Applicant |
| US2009116471A1 | Cited by | United States of America | Pre-grant |
| US8385953B2 | Cited by | United States of America | Search report |
| US7949719B2 | Cited by | United States of America | Applicant |
| US9635199B2 | Cited by | United States of America | Applicant |
| US2004242202A1 | Cited by | United States of America | Pre-grant |
| US2007211630A1 | Cited by | United States of America | Pre-grant |
| WO2006023302A3 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US7876766B1 | Cited by | United States of America | Search report |
| US8923264B2 | Cited by | United States of America | Applicant |
| WO2005125242A2 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| EP2483792A4 | Cited by | European Patent Office (EPO) | Search report |
| US9392426B2 | Cited by | United States of America | Applicant |
| US10701038B2 | Cited by | United States of America | Search report |
| US2005259652A1 | Cited by | United States of America | Pre-grant |
| US8051057B2 | Cited by | United States of America | Search report |
| US8238951B2 | Cited by | United States of America | Applicant |
| US2012079048A1 | Cited by | United States of America | Pre-grant |
| US2010182651A1 | Cited by | United States of America | Pre-grant |
| US8032593B2 | Cited by | United States of America | Search report |
| US2015244662A1 | Cited by | United States of America | Pre-grant |
| US2005113083A1 | Cited by | United States of America | Pre-grant |
| US9736209B2 | Cited by | United States of America | Applicant |
| US2006251000A1 | Cited by | United States of America | Pre-grant |
| US10652423B2 | Cited by | United States of America | Applicant |
| US8200262B2 | Cited by | United States of America | Applicant |
| US2007123280A1 | Cited by | United States of America | Pre-grant |
| US8284784B2 | Cited by | United States of America | Applicant |
| EP1949251A2 | Cited by | European Patent Office (EPO) | Search report |
| US2007211713A1 | Cited by | United States of America | Pre-grant |
| US2015018022A1 | Cited by | United States of America | Pre-grant |
| US2009052647A1 | Cited by | United States of America | Pre-grant |
| US2017004327A1 | Cited by | United States of America | Pre-grant |
| US9647872B2 | Cited by | United States of America | Applicant |
| US7779087B2 | Cited by | United States of America | Applicant |
| US7925243B2 | Cited by | United States of America | Search report |
| US2005033847A1 | Cited by | United States of America | Pre-grant |
| US2009182819A1 | Cited by | United States of America | Pre-grant |
| EP1998519A3 | Cited by | European Patent Office (EPO) | Search report |
| US8965964B1 | Cited by | United States of America | Search report |
| US2009111492A1 | Cited by | United States of America | Pre-grant |
| US2007118621A1 | Cited by | United States of America | Pre-grant |
| US2006023727A1 | Cited by | United States of America | Pre-grant |
| WO2007053717A2 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| WO2006105773A2 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US8069261B2 | Cited by | United States of America | Search report |
| US8774780B2 | Cited by | United States of America | Applicant |
| US2009052644A1 | Cited by | United States of America | Pre-grant |
| US2010136981A1 | Cited by | United States of America | Pre-grant |
| US2006176902A1 | Cited by | United States of America | Pre-grant |
| US8185148B2 | Cited by | United States of America | Applicant |
| US2005289029A1 | Cited by | United States of America | Pre-grant |
| US8068861B1 | Cited by | United States of America | Search report |
| US8260334B2 | Cited by | United States of America | Search report |
| US8799383B2 | Cited by | United States of America | Search report |
| US8447335B2 | Cited by | United States of America | Applicant |
| US8189543B2 | Cited by | United States of America | Search report |
| US2007088848A1 | Cited by | United States of America | Pre-grant |
6 members in 3 offices
Priority claims6
| Document | Office | Kind | Date |
|---|---|---|---|
| 34595601 | United States of America | P | |
| 34595601 | United States of America | P | |
| 31929902 | United States of America | A | |
| 60345956 | – | – | – |
| US20010345956P | – | – | – |
| US20020319299 | – | – | – |
Members6
| Document | Office | Kind | |
|---|---|---|---|
| WO03058991A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU2002364043A1 | Australia | A1 | |
| AU2002364043A8 | Australia | A8 | |
| US2003193951A1 | United States of America | A1 | |
| US2003193967A1 | United States of America | A1 | |
| WO03058991A3 | World Intellectual Property Organization (WIPO) | A3 |
34 transactions on the USPTO file
Abandoned after 1 non-final rejection and 1 final rejection.
- Non-final rejections
- 1
- Final rejections
- 1
- RCEs
- 0
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | |
|---|---|
| Mail Abandonment for Failure to Respond to Office ActionAbandoned | |
| Aband. for Failure to Respond to O. A. | |
| Mail Final Rejection (PTOL - 326)Final rejection | |
| Final RejectionFinal rejection | |
| Date Forwarded to Examiner | |
| New or Additional Drawing Filed | |
| Response after Non-Final Action | |
| Request for Extension of Time - Granted | |
| New or Additional Drawing Filed | |
| Mail Non-Final RejectionNon-final rejection | |
| Non-Final RejectionNon-final rejection | |
| Case Docketed to Examiner in GAU | |
| IFW TSS Processing by Tech Center Complete | |
| Reference capture on IDS | |
| Information Disclosure Statement (IDS) Filed | |
| Information Disclosure Statement (IDS) Filed | |
| Case Docketed to Examiner in GAU | |
| Information Disclosure Statement (IDS) Filed | |
| Information Disclosure Statement (IDS) Filed | |
| Transfer Inquiry to GAU | |
| Information Disclosure Statement (IDS) Filed | |
| Information Disclosure Statement (IDS) Filed | |
| Correspondence Address Change | |
| Application Dispatched from OIPE | |
| Application Is Now Complete | |
| Additional Application Filing Fees | |
| Applicant has submitted new drawings to correct Corrected Papers problems | |
| Request for Foreign Priority (Priority Papers May Be Included) | |
| Information Disclosure Statement (IDS) Filed | |
| Information Disclosure Statement (IDS) Filed | |
| Corrected Paper | |
| Cleared by L&R (LARS) | |
| IFW Scan & PACR Auto Security Review | |
| Initial Exam Team nn |
2 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Information on status: application discontinuationABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTIONSTCB | STCB | |
| AssignmentAS | AS |
Numbers
- Publication, DOCDB
- 2003193967
- Publication, EPODOC
- US2003193967
- Application
- 10319299
- Application, DOCDB
- 31929902
- Application, EPODOC
- US20020319299
Titles
- English
- Method, apparatus and system for processing multimedia messages
Classification
- CPC, 25
- H04L51/10
- H04L29/06
- H04W4/12
- H04L51/14
- H04W8/18
- H04L51/26
- H04W80/00
- H04L51/38
- H04W88/184
- H04L67/04
- H04L67/303
- H04L67/2819
- H04L67/306
- H04L67/2823
- H04L67/2842
- H04L69/329
- H04L51/226
- H04L51/214
- H04L69/08
- H04L51/58
- H04L67/564
- H04L67/565
- H04L67/568
- H04L69/18
- H04L9/40
- IPC, 7
- H04L12 58
- H04L29 06
- H04L29 08
- H04W4 12
- H04W8 18
- H04W80 00
- H04W88 18
- USPC, 2
- 370490000
- 370469000