Description MOBILE E-MAIL MANAGEMENT OBJECTS

Technical Field

[1] The present invention relates to mobile e-mail management objects.

Background Art

[2] Management objects refer to information related to radio access technologies, terminal capabilities, user preferences, applications and/or services provided on the terminal, and the like. Such information needs to be managed and handled effectively and efficiently. However, the background art technologies do not sufficiently address such issues, and thus do not offer appropriate solutions. Disclosure of Invention

Technical Solution

[3] The present inventor recognized some drawbacks of the background art. Based upon such recognition, the various features described hereafter have been conceived such that effective management of mobile e-mail applications can be performed.

[4] Various aspects of mobile e-mail applications are specifically defined and managed in the form of mobile e-mail management objects using appropriate protocol support, such as a device management (DM) protocol. Brief Description of the Drawings

[5] Figure 1 shows an exemplary structure of a terminal cooperating with network elements to implement an exemplary method of using mobile e-mail management objects (MO).

[6] Figure 2 shows a signal flow diagram for an exemplary method of managing contextual information for mobile e-mail.

[7] Figure 3 shows a signal flow diagram for another exemplary method of managing contextual information for mobile e-mail.

[8] Figure 4 shows an example of mobile e-mail management objects (MO) in the form of nodes in a logical hierarchy (tree) structure. Mode for the Invention

[9] The present disclosure claims priority benefit to U.S. Provisional Application No.

60/947,858 (filed July 3, 2007), which contents are all incorporated by reference herein.

[10] The inventive concepts and features herein related to managing contextual information for wireless communications are explained in terms of mobile e-mail management object techniques. However, such details are not meant to limit the various features described herein, which are applicable to other types of information

management techniques.

[11] Hereafter, the term "terminal" will be used to refer to various types of user devices, such as mobile communication terminals, user equipment (UE), mobile equipment (ME), and other devices that support various types of wireless communication technologies.

[12] Certain concepts described herein are related to the so-called E2R (End-to-End Re- configurability) project that addresses the core strategic objective of "Mobile and wireless systems and platforms beyond 3G" to provide a true seamless experience to the user based on end-to-end connectivity.

[13] The present invention relates to contextual information related to mobile e-mail applications that need to be managed and handled effectively and efficiently.

[14] Contextual information may be managed in terms of management objects (MO or

MOs) using device management (DM) protocol support. Some examples of contextual information may be provided in so-called "profiles" (i.e., types or categories of information) that present a definition of capabilities, which allow accurate provisioning of various types of wireless communication services, such as reconfiguration services.

[15] For example, contextual information may include the surrounding radio access technologies (RAT), terminal capabilities, user preferences, applications/services provided on the terminal, and the like.

[16] Such contextual information may be represented as a logical hierarchical structure, such as a device management (DM) tree, a management object (MO) tree, a mobile e- mail (MEM) tree, etc., using extendible mark-up language (XML).

[17] It can be said that a management object (MO) is used for continuous provisioning, which allows the service provider to update any parameter defined in a management object (MO) tree for service configuration (or reconfiguration) during service deployment.

[18] Reconfiguration may refer to a process of optimizing various parameters (or other factors) related to wireless communications. Such parameters may be initially configured (or set) and then later configured again (i.e., reconfigured) as necessary.

[19] Additionally, reconfiguration may refer to the process of changing the behavior of a system. It is carried out by the addition or the exchange of executable code, which defines the logic of the system, and/or by the modification of operational parameters of the system. Reconfiguration can cover the switch from one predefined configuration to another one, as well as the installation of new functionality that was not available in the device before.

[20] An exemplary method of managing a messaging service, performed by the terminal, may comprise the steps of: (1) configuring, as a tree format, a management object (MO) related to a messaging service; (2) receiving a request, from a DM server, to

provide the MO related to the messaging service; and (3) providing, to the DM server, the tree of the MO.

[21] Another exemplary method of managing a messaging service, performed by the terminal, may comprise the steps of: (1) providing as a tree format, to a DM server, an MO related to a messaging service; (2) receiving a request, from the DM server, for updates related to parameters in the MO; and (3) updating the parameters in the MO according to the request.

[22] This invention proposes a list of Mobile E-Mail (MEM) Client parameters and to expose this list so that an external entity (such as a network server) would be able to manage them remotely and solve problems if needed. Namely, anything from provisioning to regular maintenance can be provided to the MEM Client from the network server.

[23] Figure 1 shows an exemplary structure of a terminal cooperating with network elements to implement an exemplary method of using mobile e-mail management objects (MO).

[24] For example, a terminal 100 for managing contextual information for wireless communications with a network 120, may comprise a memory 112 to store management objects related to contextual information for wireless communications in the form of a management object tree structure; an interface 110 to receive from a network server (160, 180), a request for providing management objects related to the contextual information; and a processor 104 to provide the management object tree structure to the network server (160, 180) via the interface 110.

[25] In such terminal, the processor 104, in cooperation with the memory 112 and the interface 110, can make a decision to attach to the network 120.

[26] The memory 112 may comprise profiles containing information related to user preferences, the terminal, the network, and applications/services supported by the terminal 100 and the network 120.

[27] The profiles may comprise: a user profile that at least specifies privacy settings and preferences; a terminal profile that at least specifies memory allocation, allows a service provider to gain access, and that allows the management object tree structure to be extended for each new service provider; an application/service profile that at least specifies quality of service parameters; and a network profile that at least specifies bearer service parameters.

[28] The profiles may further comprise a security profile that at least specifies security parameters.

[29] Such terminal 100 may further comprise: a non- volatile memory, that is accessed by the processor 104, to store information related to at least one of an operating system, application software, firmware, and a device management client to allow management

of the contextual information for wireless communications.

[30] Namely, the concepts described above may be implemented in an E2R system architecture that supports the features of the present invention may be defined in the entity called a Reconfiguration Management Plane, and more specifically in the Selfware Reconfiguration Plane (SRP).

[31] An exemplary use case may be for a heterogeneous radio environment (for example,

GSM, UMTS and Wi-Fi), wherein the terminal is able to reconfigure itself to access the best suited access technology, depending on criteria such as: user preferences, device capabilities, quality of the network, application in use, and other additional policy rules defined by the network.

[32] The main entities in the MEM environment are the MEM Client 102, the MEM

Server 160 and the E-mail Server 180. A device management (DM) entity 106 within the terminal 100 may also be used to facilitate in various device management operations.

[33] The E-mail Server 180 is not specified within the MEM specifications. It is a component that provides the user with data storage, access and means of email submission. In practice, the E-mail Server 180 can be a POP server or an IMAP Server.

[34] The MEM Server 160 acts as a relay between the E-mail Server 180 and the MEM

Client 102 in order to provide an optimized over-the-air interface. The interface between the MEM Server 160 and the E-mail Server 180 is outside the scope of the MEM specifications.

[35] The MEM Client 102 is implemented on the user's wireless device (such as a terminal 100). This MEM Client 102 is the component that interacts with the user.

[36] The goal of the MEM Enabler 108 is to provide quasi-instantaneous and secure updates of the MEM Client 102 with new emails and server changes, optimized online and off-line usage and capability to securely send email from the appropriate server. E- mail may be personal e-mail provided by an e-mail service provider or corporate e- mail.

[37] Within the MEM application, several parameters have to be configured. First, the connectivity settings are essential to enable the device connection to the network. Also, the MEM user's account(s) has to be configures (login/password). Then, the MEM Client 102 presents several adjustable parameters to allow several configuration schemes. For example, a MEM Client 102 can be configured to request delivery reports when sending e-mail. Another example would be to configure the notification filter in order to specify which events on the E-mail server 180 have to be notified to the user.

[38] Within the MEM existing specifications, there is no dedicated MEM Management

Object (MO) defined. Knowing this, it is not possible to configure and manage the

MEM Client settings remotely.

[39] The MEM specifications do not clearly define the list of user's settings that are configurable through the MEM Client. In addition to that, no MEM MO has been specified so far. Therefore, there is currently no standardized way for a MEM Client to use DM Tree to present a server the different parameters for the MEM configuration.

[40] This invention provides a solution that solves some possible scenarios that are not possible in the existing standards.

[41] First, it provides a standardized solution for a MEM Client to present the configuration of the client to an external server, thus allowing an external server to collect this information and modify it, if needed.

[42] Secondly, it allows a management authority to modify only certain parameters of the

MEM Client. Also, the inclusion of new parameters allows deeper management of the client configuration.

[43] This invention explains how a device should organize the information of the MEM

Application in a way that an external server would be able to understand.

[44] As explained before, the first concept is the creation of a MEM Management Object

(MO) to allow the presentation and modification of the MEM Client settings by a server using OMA DM protocol.

[45] This desegregation would allow a DM Server to individually list and modify the relevant parameters of the MEM Application, thus improving usability and reducing operating costs in case a modification of the service is needed.

[46] This proposal would also indicate a MEM Client how to update the MEM Client in case any individual modification is made at the device MO.

[47] This can be understood from the use cases explained below.

[48] Figure 2 shows a signal flow diagram for an exemplary method of managing contextual information for mobile e-mail.

[49] The management of contextual information for mobile e-mail is performed between a network server (such as a DM server 200, MEM Server, etc.) and a device (such as a mobile terminal 220).

[50] First, the DM server 200 retrieves multimedia messaging service (MMS) parameters

(or mobile e-mail (MEM) parameters) from the mobile terminal 220 (S201). Then, the retrieved parameters are analyzed by the DM server 200 (S203). Based upon such analysis, the DM server 200 sends new parameters to the mobile terminal 220 (S205). This allows the mobile terminal 220 to use the new parameters for the MMS client (or for the MEM client) (S207).

[51] Here, the MMS parameters or MEM parameters may be represented as management objects (MOs) that are configured into a management object (MO) tree structure. The management objects (MOs) may be retrieved or modified by a server using device

management (DM) protocol support. The access technology may relate to at least one of 3GPP, OMA, IEEE, and ETSI standards.

[52] Figure 3 shows a signal flow diagram for another exemplary method of managing contextual information for mobile e-mail.

[53] The terminal may be comprised of a MEM Client 201 and a DM Client 202, while the network may be comprised of a DM Server (MEM Server) 203 and a management entity 204.

[54] The DM Server 303 sends a DM request to the DM Client 302 (S310). Upon receiving such DM request, the DM client 302 sends a MEM Tree to the DM Server 303 (S321). Then, the DM Server 303 and the Management entity 304 cooperate to check the management objects (MO) of the MEM Tree (S314). If any updating is found to be necessary upon checking, the DM Server 303 sends an update request to the DM Client 302 (S316). As such, the DM Client 302 may make changes to the MEM Tree (S318). Finally, the changed MEM Tree is informed to the MEM Client 301 (S320) and the MEM Tree is used for managing various characteristics of the mobile e-mail (MEM) service.

[55] Figure 4 shows some exemplary mobile e-mail (MEM) management objects (MO) in the form of nodes in a logical hierarchy (tree) structure.

[56] The logical hierarchy structure used in managing at least one mobile e-mail (MEM) management object (MO) between a network server and a terminal, may include the following:

[57] A first hierarchy including, at least one first node that contains contextual information that specify characteristics used for e-mail specific filters, and at least one second node that contains contextual information that specify characteristics used for e-mail notification. Also, there may be a second hierarchy including, sub-nodes under the first node related to event filters and notification filters, and sub-nodes under the second node related to preferred outband notification and multiple outband notification.

[58] The description of some exemplary parameters (MEM MO) that are shown in Figure

4 are as follows:

[59] /<x>:

[60] This interior node acts as a placeholder for one or more configuration set. One configuration set is bound to one Service Provider. The interior node is mandatory if the UE supports OMA MEM.

[61] Occurrence: OneOrMore Format: Node

[62] Access Types: Get Values: n/a

[63] /<X>/NAME

[64] This leaf node specifies the human readable name of the MEM Service.

[65] Occurrence: ZeroOrOne Format: chr

[66] Access Types: Get Values: <Human readable name>

[67] /<X>/MEM Release

[68] This leaf node specifies the MEM release of the client. This leaf node is mandatory and for this release should have the value 1.0.

[69] Occurrence: One Format: chr

[70] Access Types: Get Values: <1.0 for this release>

[71 ] /<X>/PRO VIDER-ID

[72] This leaf node specifies an identifier for the provider of the MEM service.

[73] Occurrence: ZeroOrOne Format: chr

[74] Access Types: Get Values: <Provider identifier

[75] /<X>/ToConfRef/

[76] The ToConfRef interior node is used to allow application to refer to a collection of connectivity definitions. Several connectivity parameters may be listed for a given application under this interior node.

[77] Occurrence: ZeroOrOne Format: Node

[78] Access Types: Get Values: N/A.

[79] /<X>/ToConfRef/<x>/

[80] This run-time node acts as a placeholder for each reference to connectivity parameters

[81] Occurrence: OneOrMore Format: Node

[82] Access Types: Get Values: N/A.

[83] /<X>/ToConfRef/<x>/ConRef

[84] The ConRef specifies a specific linkage to connectivity parameters. This parameter points to the right connectivity identity.

[85] Occurrence: One Format: chr

[86] Access Types: Get Values: N/A.

[87] /<X>/ADDR

[88] This leaf node specifies the URL of the MEM Server.

[89] Occurrence: One Format: chr

[90] Access Types: Get Values: <URL of the MEM Server>

[91] /<X>/Account/

[92] This node is used to specify multiple MEM accounts provided by the same Service

Provider.

[93] Occurrence: One Format: Node

[94] Access Types: Get Values: N/A

[95] /<X>/Account/<x>/

[96] This interior node acts as a placeholder for separating one or more MEM accounts

[97] Occurrence: OneOrMore Format: Node

[98] Access Types: Get Values: N/A

[99] /<X>/Account/<x>/User Name

[100] The leaf node specifies the user login associated to this MEM account. In many cases, the user login is the user's email address without "©domain"

[101] Occurrence: One Format: chr

[102] Access Types: Get Values: <User login>

[103] /<X>/Account/<x>/Password

[104] The leaf node specifies the password associated to this MEM account.

[105] Occurrence: One Format: chr

[106] Access Types: Get Values: <password>

[107] /<X>/Account/<x>/ToEventFilters

[108] This node is used to specify multiple Event Filters. The Event Filters are the filtering rules that determine which email events may trigger notification (e.g. new e-mail received, read, deleted).

[109] Occurrence: ZeroOrOne Format: Node

[110] Access Types: Get Values: N/A

[111] /<X>/Account/<x>/ToEventFilters/<x>/

[112] This interior node acts as a placeholder for separating one or more Event Filters.

[113] Occurrence: OneOrMore Format: Node

[114] Access Types: Get Values: N/A

[115] /<X>/Account/<x>/ToEventFilters/<x>/EventF ilters

[116] This leaf node specifies an event that triggers a notification. Possible values are: new email received, email deleted on the server, email moved from one folder to another, email status modified, email expired, new folder created, folder modified, folder deleted.

[117] Occurrence: One Format: Node

[118] Access Types: Get Values: <nature of the event>

[119] /<X>/Account/<x>/ToNotificationFilters

[120] This node is used to specify multiple Notification Filters. The Event Filters are the filtering rules that determine for a particular email message whether or not a notification is sent to the MEM Client (e.g. only email from John to be notified).

[121] Occurrence: ZeroOrOne Format: Node

[122] Access Types: Get Values: N/A

[123] /<X>/Account/<x>/ToNotificationFilters/<x> /

[124] This interior node acts as a placeholder for separating one or more Notification Filters.

[125] Occurrence: OneOrMore Format: Node

[126] Access Types: Get Values: N/A

[121] /<X>/Account/<x>/ToNotif icationFilters/<x>/Notif icationFilters

[128] This leaf node specifies a condition on the email object that triggers a notification.

An example of such condition could be: "From Header field = John@domain.com" [129] Occurrence: One Format: Node [130] Access Types: Get Values: <condition on email> [131] /<X>/Account/<x>/PrefOutbandNotification [132] This node is used to specify the preferred Outband Notification mechanism to use.

The outband notification is used in case the MEM Client is not directly connected to the MEM Server (offline mode). Examples of mechanism are SMS, MMS, Wap Push, etc.

[133] Occurrence: One Format: char

[134] Access Types: Get Values: <outband notification mechanism> [135] /<X>/Account/<x>/ToOutbandNotification [136] This node is used to specify multiple Outband Notification mechanisms. The outband notification is used in case the MEM Client is not directly connected to the MEM

Server (offline mode). [137] Occurrence: One Format: Node [138] Access Types: Get Values: N/A [ 139] ^X^Accounϋkx^ToOutbandNotification^x^

[140] This interior node acts as a placeholder for separating one or more Outband Notification mechanisms.

[141] Occurrence: OneOrMore Format: Node [142] Access Types: Get Values: N/A

[143] /<X>/Account/<x>/ToOutbandNotif ication/<x>/Mechanism [144] This leaf node specifies the identifier for the Outband Notification mechanism.

Possible values are: SMS, MMS, Wap Push, etc. [145] Occurrence: One Format: chr

[146] Access Types: Get Values: <outband notification mechanism> [147] /<X>/Account/<x>/ToOutbandNotification/<x> /Client Addr [148] This leaf node specifies the address of the client used to receive the notification. For instance, in case SMS is used to transport outband notifications, the address would be an E.164 number.

[149] Occurrence: ZeroOrOne Format: Node [150] Access Types: Get Values: <outband client address> [151] /<X>/Account/<x>/ToOutbandNotification/<x> /ConRef [152] This node specifies a specific linkage to connectivity parameters used to access the outband notification service (e.g. MMS). This parameter points to the right con-

nectivity identity.

[153] Occurrence: One Format: Node

[154] Access Types: Get Values: N/A

[155] /<X>/Expiry Time/

[156] This interior node acts as a placeholder for the information regarding the expiry time time of the sent email.

[157] Occurrence: ZeroOrOne Format: Node

[158] Access Types: Get Values: N/A

[ 159] /<X>/Expiry Time/Time value

[160] This leaf node specifies the length of time a message sent by the MEM Client will be stored in the network or the time to delete the message.

[161] Occurrence: One Format: integer

[162] Acces s Types : Get

[163] Values: <date in seconds from 1970-01-01, 00:00:00 GMT>

[ 164] or <length of time in seconds>.

[165] /<X>/Expiry Time/Time Format

[166] This leaf node specifies the format of the expiry time value.

[167] Occurrence: One Format: chr

[168] Access Types: Get Values: "absolute" or "relative".

[169] /<X>/Delivery Report

[170] This leaf node specifies whether a delivery report is sent to the originator of the

Email.

[171] Occurrence: ZeroOrOne Format: binary

[172] Access Types: Get Values: "yes" or "no".

[173] /<X>/Read Report

[174] This leaf node specifies whether a read report is sent to the originator of the Email.

[175] Occurrence: ZeroOrOne Format: binary

[176] Access Types: Get Values: "yes" or "no".

[177] /<X>/Auto Reply

[178] This leaf node specifies whether the Auto Reply function is activated or not.

[179] Occurrence: ZeroOrOne Format: binary

[180] Access Types: Get Values: "yes" or "no".

[181] /<X>/ Adaptation Authorization

[182] This leaf node indicates whether the MEM Client authorizes an Email to be adapted or not.

[183] Occurrence: ZeroOrOne Format: binary

[184] Access Types: Get Values: "yes" or "no".

[185] /<X>/Ext:

[186] The Ext is an interior node for where the vendor specific information is being placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include un-standardized sub-tree.

[187] Occurrence: ZeroOrOne Format: Node

[188] Access Types: Get Values: N/A

[189] In summary, the features of this invention is related to the possibility for the MEM

Client to present its configuration and application settings to an external server, and the possibility for an external server to modify individual parameters of the MEM client. By doing so, mobile e-mail (MEM) applications can be managed in a more effective and efficient manner.

[190] Thus, the present invention provides a method of provisioning for a mobile e-mail (MEM) service between a MEM client and a MEM server, the method comprising: providing parameters to allow configuration of e-mail specific filters; and providing parameters to allow configuration of e-mail notification.

[191] The e-mail specific filters are comprised of event filters that specify filtering rules to determine which e-mail events may trigger notification, and notification filters that specify filtering rules to determine for a particular e-mail message as to whether a notification is sent to the MEM client. The e-mail notification is related to preferred outband notification that specifies a preferred outband notification mechanism to be used, and multiple outband notification that specifies a plurality of outband notification mechanisms to be used if the MEM client is not directly connected to the MEM server.

[192] Also, the present invention provides a method of managing parameters for a mobile e-mail service, the method performed by a terminal and comprising: receiving a request from a server to provide a configuration status of the terminal; providing the configuration status to the server; and performing the mobile e-mail service based upon the configuration status.

[193] The method may further comprise: receiving a request for updating a configuration status of the server; and updating any changes in configuration within the terminal. The configuration status relates to parameters in a management tree. The parameters in the management tree are related to e-mail specific filters and/or e-mail notification. The e- mail specific filters are comprised of event filters that specify filtering rules to determine which e-mail events may trigger notification, and notification filters that specify filtering rules to determine for a particular e-mail message as to whether a notification is sent to the terminal. The e-mail notification is related to preferred outband notification that specifies a preferred outband notification mechanism to be used, and multiple outband notification that specifies a plurality of outband notification mechanisms to be used if the terminal is not directly connected to the server.

[194] Additionally, the present invention provides a method of managing parameters for a mobile e-mail service for a terminal, the method performed by a server and comprising: sending a request to the terminal to provide a configuration status of the terminal; receiving the configuration status of the terminal; and allowing the terminal to perform the mobile e-mail service based upon the configuration status.

[195] The method may further comprise: sending a request to the terminal for updating the configuration status; and updating any changes in configuration in the server. The configuration status relates to parameters in a management tree. The parameters allow configuration of e-mail specific filters and/or configuration of e-mail notification. The e-mail specific filters are comprised of event filters to determine which e-mail events may trigger notification, and notification filters to determine for a particular e-mail message as to whether a notification is sent to the terminal. The e-mail notification specifies a preferred outband notification mechanism to be used, and specifies a plurality of outband notification mechanisms to be used if the terminal is not directly connected to the server.

[196] Furthermore, the present invention provides a device that supports a method of managing parameters for a mobile e-mail service, the device comprising: a memory to store management objects related to contextual information for the mobile e-mail service in the form of a management object tree structure; an interface to receive from a network server, a request for providing management objects related to the contextual information; and a processor to provide the management object tree structure to the network server via the interface.

[197] The processor further comprises: a first module to receive a request from a server to provide configuration status of the terminal; a second module to provide the configuration status to the server; and a third module to perform the mobile e-mail service based upon the configuration status. The first module, the second module, and the third module cooperate to receive a request for updating a configuration status of the server, and update any changes in configuration on the terminal. The management object tree provided by the processor comprises one or more nodes related to e-mail specific filters and/or e-mail notification. The e-mail specific filters comprise event filters that specify filtering rules to determine which e-mail events may trigger notification, and notification filters that specify filtering rules to determine for a particular e-mail message as to whether a notification is sent to the device. The e-mail notification is related to preferred outband notification that specifies a preferred outband notification mechanism to be used, and multiple outband notification that specifies a plurality of outband notification mechanisms to be used if the device is not directly connected to the network server.

[198] Moreover, the present invention provides a logical hierarchy structure used in

managing at least one mobile e-mail (MEM) management object (MO) between a network server and a terminal, the logical hierarchy structure comprising: a first hierarchy including, at least one first node that contains contextual information that specify characteristics used for e-mail specific filters, and at least one second node that contains contextual information that specify characteristics used for e-mail notification; and a second hierarchy including, sub-nodes under the first node related to event filters and notification filters, and sub-nodes under the second node related to preferred outband notification and multiple outband notification.

[199] The event filters specify filtering rules to determine which e-mail events may trigger notification, and the notification filters specify filtering rules to determine for a particular e-mail message as to whether a notification is sent to the terminal. The preferred outband notification specifies a preferred outband notification mechanism to be used, and the multiple outband notification specifies a plurality of outband notification mechanisms to be used if the terminal is not directly connected to the network server.

[200] The various features and concepts described herein may be implemented in software, hardware, or a combination thereof. For example, a computer program (that is executed in a computer, a terminal or a network device) for managing contextual information may comprise a program code section for performing the various tasks. Similarly, a software tool (that is executed in a computer, a terminal or a network device) for managing contextual information may comprise program code portions for performing various tasks.

[201] It should be noted that the parameters (i.e., mobile e-mail management objects

(MOs)) related to mobile e-mail are compatible with various types of technologies and standards.

[202] Also, certain concepts described herein are related to various types of standards, such as ISO/IEC, ETSI, OMA, 3GPP, GSM, IEEE and the like. For example, the reconfiguration concepts described herein relate to the so-called self -organizing network (SON) technologies of the 3GPP (LTE/SAE) standard, as well as the so-called device management (DM) technologies of the OMA standard.

[203] It can be understood that the above exemplary standards are not intended to be limited, as other related standards and technologies would also be applicable to the various features and concepts described herein. Industrial Applicability

[204] The features and concepts herein related to mobile e-mail management objects are applicable to and can be implemented in various types of user devices (e.g., mobile terminals, handsets, wireless communication devices, etc.) and/or network entities that

can be configured or reconfigured to support different types of air interfaces, protocols, and applications used in radio communications, such as, cellular, fixed, wireless local area and broadcast systems. As the various concepts and features described herein may be embodied in several forms without departing from the characteristics thereof, it should also be understood that the above-described embodiments are not limited by any of the details of the foregoing description, unless otherwise specified, but rather should be construed broadly within its scope as defined in the appended claims. Therefore, all changes and modifications that fall within such scope or equivalents thereof are therefore intended to be embraced by the appended claims.