BRPI0209592B1 - mobile messaging, mobile client device, server, presence system, presence client program, physical device, and data structure - Google Patents

Abstract

"mobile messaging, mobile client device, server, presence system, presence client program, physical device, and data structure". The invention relates to mobile messaging and presence services. According to one aspect of the invention, the mobile messaging client device adds the qualifier to the presence attribute, the qualifier comprising one or more parameters specifying the use of the attribute. When the client device receives the presence attribute, it processes the received presence attribute according to the qualifier parameters in the received attribute. Another aspect of the invention is the presentation of how to assemble and store presence items with names, attributes and values in a single presence group within a role having an associated authorization member group, which has the right to sign all or a part of the presence group of the same role.

Description

“MOBILE MESSAGE SYSTEM, MOBILE CUSTOMER DEVICE, SERVER, PRESENCE SYSTEM, PRESENCE CUSTOMER PROGRAM, PHYSICAL DEVICE, AND DATA STRUCTURE”.

Field of the Invention The present invention relates to message transmission in mobile telecommunications systems and more particularly to presence attributes in mobile instant messaging and messaging.

Background Art Instant messaging provides end users with a means for fast, interactive, mostly text-based communication. The usefulness of instant messaging is greatly enhanced by the addition of a service that will keep track of online status and the availability of your chat partners or “friends”; as well as notifying you of exchanges for their status or availability. This type of service is called “presence service”. In general, presence can be considered to contain various dynamic information on the user or client connected to the instant messaging service across multiple devices. Examples of this information are user reachability, availability, and location for communication. The combination of instant messaging and presence services is called instant messaging and presence service (IMPS). This type of service has been available to fixed Internet users, but the interconnectivity between fixed users and mobile users has been lost. The Wíreless Village initiative has been established to set the specifications for mobile instant messaging and presence service. Wireless Village Presence and Instant Messaging (IMPS) includes the first four features: presence, instant messaging, groups, and shared content. Shared content allows users and operators to set up their own storage area where they can post images, music and other multimedia content while enabling sharing with other individuals and groups in a chat or IM session. The Wireless Village initiative enables both operators and end users to create and manage groups. Presence is the key enabling technology for the Wireless Village initiative. In the existing Intemet based instant messaging service, presence values are usually very simple, such as the user is active, absent, unwilling to communicate, and so on. These values are selected from the predefined value groups. The white paper has been published in the IMPS Wireless Village mobile solution: “Wireless Village, The IMPS Mobile Initiative: White Paper” dated April 26, 2001. The existing mobile terminal can be considered a personal tool that reflects personal status. more exactly than the desktop computer. Considering the wide range of information that can be obtained from the user and the mobile terminal, anticipating the presence information domain is very difficult. Thus, a mechanism should be developed to easily enable the use and addition of new types of presence information.

Summary of the Invention An object of the invention is to provide a solution for the creation of new presence attributes in addition to the already determined presence attributes.

Another object of the invention is to present how to organize and store presence attributes for use by clients.

According to the first aspect of the invention, the mobile messaging client device adds a qualifier for the presence attribute, the qualifier comprising one or more parameters specifying the use of the attribute. The client device that receives the presence attribute processes the received presence attribute according to the qualifier parameters in the received attribute. The presence attribute is a collection of data that describes the presence information on a certain user and / or client device, the intended presence information for other users. The presence attribute may also contain the information for machine-to-machine communication between client devices.

Also in accordance with the first aspect of the present invention, the mobile messaging system comprises at least one client device and a server, wherein the client device comprises a device for transmitting presence information as presence attributes to the server and a device for receiving presence attributes from the server, the information being categorized by a plurality of presence attribute types identified by the name attribute, and the server comprising a device for maintaining presence information based on the received presence attributes, the system is characterized by that the client device comprises a device for adding a qualifier for the presence attribute, the qualifier comprising one or more parameters specifying the use of the attribute, and the client device comprises a device for processing the presence attribute received according to qualifier parameters in the assign I'm received.

According to the second aspect of the invention, the client device comprises the presence information attributes that are identified by the combination of an authorizer, the attribute name and a qualifier, where the authorizer specifies the body responsible for maintaining the attribute and the qualifier. specifies the use of the attribute. Upon receiving the presence attribute, the server and client device look for the attributes already stored containing the same identifiers as the received attribute. The already stored attribute is replaced with the received attribute if the combination of the received attribute identifiers is identical to the already stored attribute. Otherwise, the received attribute is added without replacing any previous attributes.

Also in accordance with the second aspect of the present invention, the mobile messaging system comprises at least one client device and a server, wherein the client device comprises a device for transmitting presence information as presence attributes to the server and a device for receiving presence attributes from the server, the presence information being categorized by a plurality of presence attribute types identified by the attribute name, and the server comprises a device for maintaining presence information based on the received presence attributes, the system is characterized by the fact that the client device comprises a device for composing the presence information attribute identified by a combination of the authorizer, attribute name and qualifier, the authorizer specifying the body responsible for maintaining the attribute and the qualifier specifying the use of the attribute, the server understands a device for searching for an already stored attribute containing the same identifiers as the received attribute and a device for replacing the already stored attribute with the received attribute if the combination of the received attribute identifiers is identical to that of the already stored attribute or otherwise adds the attribute received, and the client device comprises a device for searching for an already stored attribute containing the same identifiers as the received attribute and a device for replacing the attribute already stored with the received attribute if the combination of the received attribute identifiers is identical to that of the attribute already received. stored or otherwise adds the received attribute.

Also according to the first and second aspect of the present invention, the system is characterized in that the client device comprises a device for specifying attribute display configurations in the qualifier, and the client device comprises a device for presenting attribute received based on the qualifier.

Still according to the first and second aspect of the present invention, the system is characterized in that the client device comprises a device for specifying in the qualifier the application to which the attribute should be addressed, and the client device comprises a device. to address the attribute received for the application indicated by the qualifier.

Still according to the first and second aspects of the present invention, the system is characterized in that the server comprises a device for determining based on the qualifier whether to send the attribute to one or more client devices.

Also according to the first and second aspects of the present invention, the system is characterized by the fact that the presence attributes received from the client device by the server are stored in the database according to the editor user in association with the user group. presence.

In accordance with the first and second aspects of the present invention, the system is characterized by the fact that each presence attribute is part of an item including the attribute name element and the attribute value. The name element can include an authority string indicative of an authority responsible for keeping the name element and attribute value unique.

In accordance with the first and second aspects of the present invention, the system is characterized by the fact that the presence group comprises one or more presence attributes belonging to a single editor function of an editor user in association with a single group. of presence.

Still according to the first and second aspects of the present invention, the mobile messaging system is characterized by the fact that the client device user as an editor is able to use the client device or more than one client device on more than one editor function.

According to the third aspect of the present invention, the mobile client device for the mobile messaging system comprises a device for transmitting the presence information as presence attributes to the server, the presence information being categorized by a plurality of attribute types. presence devices identified by the attribute name, the client device is characterized by the fact that it also comprises a device for adding a qualifier to the presence attribute, the qualifier comprising one or more parameters specifying the use of the attribute.

According to the fourth aspect of the present invention, the mobile client device for the mobile messaging system comprises a device for receiving the server presence attributes, the presence information being categorized by a plurality of presence attribute types identified by the name. of the attribute, and the device is characterized in that it also comprises a device for adding a qualifier to the presence attribute, the qualifier comprising one or more parameters specifying the use of the attribute, and a device for processing the presence attribute received accordingly. with the qualifier parameters in the received attribute.

According to the fifth aspect of the present invention, the mobile client device for the mobile messaging system comprises a device for transmitting presence information as presence attributes to the server, and a device for receiving presence attributes from the server. presence information being categorized by a plurality of presence attribute types identified by the attribute name, the client device is characterized by the fact that it also comprises a device for composing the presence information attribute identified by a combination of the authorizer, the name of the attribute and qualifier, the authorizer specifying the body responsible for maintaining the attribute and the qualifier specifying the use of the attribute, a device for searching for an already stored attribute containing the same identifiers as the received attribute, and a device for replacing the attribute already stored with the received attribute if the combination Nation of the received attribute identifiers is identical to the attribute already stored or otherwise adds the received attribute.

According to the third, fourth and fifth aspects of the present invention, the mobile client device is characterized in that each presence attribute is part of an item including the attribute name element and the attribute value. The name element can include an authority string indicative of an authority responsible for keeping the name element and attribute value unique.

In accordance with the third, fourth and fifth aspects of the present invention, the mobile client device is characterized by the fact that the presence group comprises one or more presence attributes belonging to a single editor function of a user editor. association with a single presence group.

According to the third, fourth and fifth aspects of the present invention, the mobile client device is characterized by the fact that the client device user as an editor is able to use the client device or more than one client device on more than one client. of an editor function.

According to the sixth aspect of the present invention, the mobile messaging server comprises a device for maintaining presence information based on the received presence attributes, the presence information being categorized by a plurality of presence attribute types identified by the attribute name, the server is characterized by the fact that it also comprises a device for searching for an already stored attribute containing the same identifiers as the received attribute, and a device for replacing the attribute already stored with the received attribute if the combination of the identifiers of the received attribute is identical to the attribute already stored or otherwise adds the received attribute.

According to still the sixth aspect of the present invention, the server is characterized in that the presence attributes received from the client device by the server are stored in the database according to the publisher user in association with the presence group.

In accordance with the sixth aspect of the present invention, the server is characterized by the fact that each presence attribute is part of an item including the attribute name element and the attribute value. The name element can include an authority string indicative of an authority responsible for keeping the name element and attribute value unique.

In accordance with the sixth aspect of the present invention, the server is characterized by the fact that the presence group comprises one or more presence attributes belonging to a single editor function of an editor user in association with a single presence group. The client device user communicating with the server acting as an editor is able to use the client device or more than one client device in more than one editor role.

According to still the seventh aspect of the present invention, the presence system comprises at least one physical device having at least one presence client to enable the presence user to interact with the system as a publisher or a subscriber, and a server for maintain valid presence group values for an editor's attributes for subscribers to access according to their associated presence groups.

Also in accordance with the seventh aspect of the present invention, the presence system is characterized by the fact that each presence attribute is part of an item including the attribute name element and the attribute value. The name element may include a qualifier having information related to the use of the attribute. The name element can include an authority string indicative of an authority responsible for keeping the name element and attribute value unique.

In accordance with the seventh aspect of the present invention, the presence system is characterized by the fact that the presence group comprises one or more presence attributes belonging to a single editor function of an editor user in association with a single presence group. presence. The user who interacts with the system as a publisher is able to use the presence client or more than one presence client in more than one publisher role. Each attribute can be part of an item including the attribute name element and the attribute value.

Still according to the seventh aspect of the present invention, at least one physical device is a mobile physical device.

In accordance with the eighth aspect of the present invention, the computer program embedded in a computer readable medium for storage on the physical device is characterized by the fact that the program is the presence client program to enable the presence user to interact with the presence system as a publisher of at least one attribute presence group for access by one or more subscribers according to at least one associated presence group.

Still according to the eighth aspect of the present invention, the presence client program is characterized by the fact that the program enables the presence user to interact with the presence system as a subscriber for at least one group of attributes associated with the presence. presence group in which the subscriber is a member.

In still according to the eighth aspect of the present invention, the presence client program is characterized by the fact that each presence attribute is part of an item including the attribute name element and the attribute value. The name element may include a qualifier having information related to the use of the attribute.

In still according to the eighth aspect of the present invention, the presence client program is characterized by the fact that the name element includes an authority string indicative of an authority responsible for keeping the name element and attribute value unique. .

In accordance with the eighth aspect of the present invention, the presence client program is characterized in that the presence group comprises one or more presence attributes belonging to a single publisher function in association with a single presence group. The user who interacts with the system as an editor is able to use the presence client program or more than one presence client program in more than one editor role. Each attribute is part of an item including the attribute name element and the attribute value.

In still according to the eighth aspect of the present invention, the presence client program is characterized by the fact that the physical device is a mobile physical device.

According to the ninth aspect of the present invention, the physical device having a computer program embedded in the computer readable medium stored therein, the device is characterized by the fact that the program is the presence client program according to the eighth aspect. of the present invention.

According to the tenth aspect of the present invention, the data structure incorporated in the computer readable medium for storage on the physical device is characterized by the fact that the data structure is a presence database for storing valid group values. presence of the attributes of one or more publishers for access by subscribers according to the presence groups associated with the presence groups.

According to the tenth aspect of the present invention, the data structure is characterized by the fact that each attribute is part of an item including the attribute name element and the attribute value. The name element may include a qualifier having information related to the use of the attribute. The name element can include an authority string indicative of an authority responsible for keeping the name element and attribute value unique.

According to the tenth aspect of the present invention, the data structure is characterized by the fact that the presence group comprises one or more attributes belonging to a single editor function in association with a single presence group.

According to the tenth aspect of the present invention, the data structure is characterized by the fact that the user who interacts with the physical device as an editor is able to use the data structure to edit more than one editor function, each function having distinct presence groups in association with different presence groups.

According to the tenth aspect of the present invention, the data structure is characterized by the fact that the physical device is a mobile device.

According to the eleventh aspect of the present invention, the physical device having a data structure embedded in the computer readable medium stored therein, the device is characterized by the fact that the data structure is a presence database according to the tenth aspect of the present invention.

The advantages of the invention are obtained by being able to adjust the default presence attributes by adding the qualifier. The qualifier can be used to add a new attribute (such as an attribute with a qualifier that can be uniquely identified, ie the separate functionality of an attribute with the same name as the attribute but without the qualifier). Thus, for example, users or application developers can easily determine new presence attributes that best fit their needs or describe their current current status without being limited to predetermined types. The use of the qualifier brings another advantage in that it enables the presence information transmitter (the owner) to also specify how the presence information is to be used on the receiving client device.

In one embodiment of the invention the application to which the attribute should be addressed is specified in the qualifier. The received attribute is addressed to the application indicated in the qualifier. Another advantage of this embodiment is that the transmitting client device can define the application used and thereby use the qualifier to direct certain presence information to a certain application.

Another advantage of the invention is the presentation of how to assemble presence items with names, attributes and values into a single presence group within a role having an authorization group associated with members that has the right to subscribe all or part of the group. presence of the same function.

BRIEF DESCRIPTION OF THE DRAWINGS In the following, the invention will be described in more detail by means of preferred embodiments and with reference to the accompanying drawings, in which: Figure 1 is a block diagram illustrating the mobile IMPS system;

Figure 2 is a signaling diagram illustrating the transmission of presence attributes; and Figure 3 is a signaling diagram illustrating the use of the qualifier;

Figure 4 shows an embodiment of a mobile messaging system comprising at least one client device and one server in accordance with the present invention;

Figure 5 shows another embodiment of the mobile messaging system comprising at least one client device and one server according to the present invention;

Figure 6 shows a presence structure according to the present invention;

Figure 7 shows a presence database according to the present invention;

Figure 8 shows the ftuxogram of the canceled signature presence according to the present invention;

Figure 9 shows the signed delivery of presence information in accordance with the present invention;

Figure 10 shows the management of user groups and presence groups according to the present invention.

Detailed Description of the Invention Figure 1 illustrates an IMPS mobile system. Multiple mobile clients (CM) can be connected via one RM mobile network and possibly one or more ONW intermediate networks to one IMPS S server. Typically the Internet is used as an intermediate network, and also non-mobile C clients can be used. served by the IMPS system. The IMPS S server can be, as with respect to presence services, functionally divided into server elements: An SE publisher server that is the resident service element for a publishing client that has presence information and an SA subscriber server which is the home of the subscriber or applicant. Thus the CM client is served by both servers; CM updates its presence information to the SE and acts as a publisher client and in turn requests and receives presence information from other clients as presence attributes of the subscriber server SA. The SE server maintains presence data and manages its distribution based on user publishing preferences for presence information. SA and SE functions may be performed on a physical server device or may be distributed to a plurality of server devices.

It should be noted that the present description emphasizes the presence related to service capabilities. Other important mobile IMPS service capabilities are messaging capabilities, user group management capabilities, content management capabilities, subscriber management capabilities, and client capabilities. Mobile IMPS services are created by using these service capabilities. For example, the CM client may belong to multiple user groups, and the S server manages group members, controls instant messaging, and delivers presence information between group members. An important function of the server is also to control the flow of information; The server may have filters based on user preferences that define, for example, that presence or other information may be delivered to members of the 'Friends' group, to members of the 'Coworkers' group or publicly to any client. Various transport layer protocols can be used and the IP protocol is typically used to provide network layer service. Different lower layer transmission protocols can be used. The RM mobile network can be any wireless network, such as a cellular network that supports GSM service, a network that also supports GPRS (General Packet Radio Service) service, the third generation mobile communication network such as the Universal Mobile Telecommunications System (UMTS) network, the WLAN wireless local area network, or a private network. In addition, short-range infrared connections or radio connections, such as Bluetooth ™ communication, can be used as a part of the communication paths between the CM and the S server. The CM mobile client device can be For example, a mobile station, a PDA device, or a laptop computer including or being connected to a wireless modem. Mobile IMPS messages may be transferred using a circuit-switched data call, packet-switched data transmission context, messaging services such as, for example, SMS or MMS (Multimedia Messaging Service). Figure 2 illustrates the use of presence attributes. Because the CM mobile client has determined 201 one or more presence attributes to be published, it updates 202 presence attributes to the SE editor server, that is, publishes one or more presence attributes. Presence 201 determination can be done when the client is establishing a logical mobile IMPS session with the mobile IMPS server or automatically or at the user's initiative when some of the presence information has changed. For example, phase 201 may be initiated automatically at a predetermined time, data, or by a user profile change in the CM mobile client. When CM client (A) accesses the mobile IMPS services of an SA server, it may request 203 presence information about the other client (B). Subscriber server SA requests this information from publisher server SE (from client A) 204. The SE sends 205 one or more presence attributes to the SA, if allowed by publishing (client B) preferences. It is possible that the publishing preferences set by client B prevent any part of the requested information from being sent (to client A or in general). The SA can also automatically request presence information based on user (A) preferences when the client establishes a logical connection to the SA service. SA directs 206 presence attributes to the receiving CM client (A). The SA subscriber server (and the SE publisher server) typically sends presence attributes originating from the client to the unchanged client. However, there may be a content adaptation mechanism implemented on the SE server. Content adaptation addresses the issue of modifying a presence attribute so that it matches the client capabilities of the receiving client. In addition, for transmitting presence information in response to a customer request, it is also possible to push presence information to available CM clients (who are logically connected to the service) according to publishing preferences. Push-type presence notification can be enabled through three mechanisms: when the publisher server receives an update from the publisher client, when the publisher server detects a change in the attribute value, or by implementation-specific internal triggers that update the value. The CM client is then configured to update one or more of the presence attributes to the SE, to receive and control the presence attributes received from the SA, and to present the presence information obtained from at least one presence attribute to the user. CM preferably stores presence information (presence attribute values) until new presence attribute values are received in an update message used to load presence attributes (or client terminates mobile IMPS session). Additionally, as will be illustrated later in more detail, the client device can automatically use the presence information received to adjust its function accordingly. In addition to the flags shown in Figure 2, an authorization may be requested from the presence information publisher before sending the presence attributes to the requesting client. Figure 2 does not display any status messages and the server can respond, for example, after message 202. The presence attribute originating from the client is one that has its value field filled in by the client publisher. The presence attribute originated from the server is one that has its value field filled in by the publisher server. The presence attribute originates from the client-server when part of the value field is populated by the client and the rest by the publisher server. According to a preferred embodiment of the invention, users or organizations may define new presence attributes in addition to the predetermined attribute group. Presence attributes can be divided into the following classes: - Client Status: Presence attributes describe the availability of the client device for communication, eg network reachability, GPRS coupled, on / off status, operator . Thus, the attributes in the mobile IMPS service are very different from the IMPS used for non-mobile client devices. - User Status: Presence attributes describe the user's availability for communication, for example, ready, meeting, busy, out of area, on the phone, talking, do not disturb. - Local Information: Presence attributes describe the user's local environment, for example, local time, noise / quiet environment, internal, external, user location, in terms of, geographic location, RMTP visited, city / street, premises . For example, the exact location of the mobile client can be obtained directly from the local information attribute and the availability status (in a meeting, a summer cabin, etc.) can be readily available through the user profile settings of the mobile client. CM mobile client. - Personal Status: Several personal attributes describe the user's personal status, for example, mood, personal interests, and intentions. - Client Capabilities: Presence attributes describe the capabilities of the client device to support different communication devices, different media types, and different characteristics. - User Attributes: Presence attributes allow the client device or user to define their own textual presence values and references to external values. - Extended Presence Information: Specific vendor or service provider dynamically defined in non-default presence attributes, which however need to be passed through standard presence servers.

Thus there may be different presence attributes for mobile client devices and current users. For example, the user may be defined as unavailable to receive messages, but the user's client device is defined as being online. The user may also be set to be able to receive the messages and not being online if SMS is used as a bearer.

General Structure and Identification of Presence Attributes Table 1 describes the general structure of presence attributes. The presence attribute generally comprises an identifying part and a plurality of value fields. The Ped field determines whether the element is required M, optional O, or conditional C. Attribute information is in Extensible Markup Language (XML) format.

Table 1: Presence Attribute Structure.

The subelements of the SpecName element are described in Table 2.

Table 2: The SpecNameName element. The attribute name is a string determined by the information element 'Name'. The information element Name is defined for all presence attributes in the format defined in Table 3.

Table 3: The Name Element The format of the Qualifier element is illustrated in Table 4.

Table 4: The Qualifier element. The Qualifier element is used to specify the scope of attribute use. The qualifier can especially be used for two purposes: adding a new attribute or enabling the presence information transmitter (the publisher) to specify how the presence information will be used on the receiving client device. Thus, the qualifier string can be used as a parameter for one or more applications on the receiving client device.

For example, if the publisher wants to limit their exact location knowledge (eg street address) to just a few of the users (call this group A) and provide a closer location (eg city name only) to others (call this group B), he can publish the location attribute with the city name for group B. For group A he attaches a Qualifier (says 'My best friends') to the location attribute. This effectively creates a new attribute with the 'My Best Friends' Qualifier. It then adds the street address to this new attribute and publishes it to group A. Because these attributes are different, the SE server is able to keep their values separate. In addition, if a person belongs to both groups A and B, that person's client device can be configured to distinguish between these two attributes. The client device can be configured to display (and possibly use) the attribute according to the group the user has enabled. Possible Qualifier values may be pre-assigned by the customer and service provider or they may be dynamically assigned by the user (publisher). The service provider may also limit the number of dynamically assigned Qualifier values. The authority element determines the body that is responsible for maintaining the attribute and its unique content. This relates to the attribute extension mechanism.

Table 5: The Authority Element.

When the default presence attributes are used unchanged, the authority string may be omitted. Using a Qualifier string is not a modification to the attribute that requires the use of the Authority element. This should be used when entering a new attribute (a new Name) or adding a new value field to an already specified attribute. In both of these cases, the attribute is considered to be new and the Authority is responsible for keeping this attribute new.

Usually the value field name must be unique within an attribute.

Thus, the introduction of a new value field for the existing attribute must be controlled by the rules set by the body that defined the attribute. Adding the new value field turns the old attribute into a new one. This must be flagged by the presence of the Authority field to allow both the new and old attributes to coexist. It is also possible for an actor to release the attribute for public maintenance. This type of attribute is registered by an authority itself, such as the Internet Designated Numbers Authority (IANA), and also flagged in the Authority field. In this case any stakeholder can register additional value fields for the attribute without having to change the Authority field. The server (SE, SA) does not remove the value field from the attribute although it does not understand the semantics of the value field. The CM client ignores all value fields in the attribute it does not understand. The attribute is identified and made unique by the SpecName element. Figure 3 presents an example of using the SpecName element and the qualifier. The qualifier is determined 301 for the attribute on client device CM1. It is possible for the user to determine the qualifier or the CM client device to determine it. The qualifier can be set to specify the desired user group by determining how to present presence information on the receiving client device (CM2), or otherwise specifying how the receiving client device CM2 should use the attribute. You can use CM mobile client user profiles when determining the qualifier. For example, CM1 composes the presence attribute based on the current profile (eg, in a meeting), calendar entries (12.00 meeting end), and local time. By using the qualifier, the presence attribute can easily be modified to include much useful information for the receiving client CM2. The attribute is sent 302 to the SE server. The SE compares the 303 Specename element of the received attribute to the attributes already stored. The SE first compares the Authority string to each other. The attribute that does not contain the Authority string is different from any attribute that has an Authority string. The following attribute names are compared. Finally, the Qualifier strings are compared. The attribute that does not contain the Qualifier string is different from any attribute that has the Qualifier string. Two attributes are the same only when all three of these comparisons give the same result. Thus it is possible to functionally separate the attribute received with the qualifier from the attributes with the same attribute name but with a different qualifier. The SE publishing server makes this comparison to determine if the received attribute value fields should overwrite any existing presence information or if the attribute is new to be added when storing CM2 presence information. Based on the comparison, the SE stores 303 the information in the received attribute. The SE replaces the previously stored attribute presence information with the received attribute presence information if all received attribute identifiers are the same as the already stored attribute. Otherwise, the SE adds the presence information of the received attribute without overwriting any previous information. The SE sends 304 the attribute to at least one CM2 client device (or automatically pushes this or as a response to the CM2 request). According to embedding, the qualifier determines the group to which the attribute is directed. In addition, the qualifier can be used to present presence information in different ways to private contacts and public contacts in the phone book, for example. Thus, the SE can determine the receiving client devices based on the qualifier. Service capabilities for a dynamic phone book service will be described later, after first describing customer status attributes, user status attributes, and personal status attributes in full below.

In addition, the receiving client CM2 decides, after a similar comparison 305 as in the SE, whether and how to store the received presence attribute information. This kind of thematic identification of presence attributes greatly enables flexible use, management and creation of presence attributes.

There are several ways in which the qualifier can be used to specify the use of the attribute on the CM2 client device. Typically, the CM client device is capable of supporting a plurality of applications. According to the first embodiment, the CM1 client device adds a qualifier that specifies the application to be used. The application generally refers to any application entity that can be identified, for example, by a port number. The application may be the same as the one used to process attribute presence information on the CM1 client device or other application. The receiving client device CM2 305 sends the received attribute to the application indicated by the qualifier. For example, when using the qualifier, the same presence information can be sent to a phonebook application and a game application. These applications may use presence information differently and thus it is also possible to tailor attributes exactly to the needs of the application.

According to the second embodiment, the CM1 client device adds the qualifier that specifies the presentation of the attribute. The receiving client device CM2 has 305 the attribute received based on the qualifier. The qualifier can determine, for example, whether or not the information is presented to the user or which parts of the information are presented. The qualifier can also determine various user interface settings such as colors, fonts, etc. Thus, the CM2 UI is configured 305 based on the qualifier settings.

Client Status Attribute According to the preferred embodiment, CM mobile clients use the presence attribute that describes the current transmission capabilities of a CM mobile client. The structure for this attribute type is illustrated in Table 6. This attribute, referred to as the Modem attribute, provides the presence information on these parts of the user terminal or on functions that are agreed with mobile carriers.

Table 6: Modem Attribute Structure.

Table 7: Modem attribute value fields. The Status value field as illustrated in Table 8 indicates the status of the mobile modem.

Table 8: Field Value Modem Status. The Status value field indicates whether the modem is on or off. According to the preferred embodiment, the presence attribute includes the DIS indication preferably in the Attribute Required Status value field. When DIS is set on an attribute, all values given in the attribute are invalid. The receiving CM mobile client is then able to ignore the attribute value fields. In addition, the previous values of the presence attribute are removed (and overridden). Thus, it is practical to send an attribute with the indication DIS, but no other value fields. This type of attribute requires very small space and thus the critical bandwidth under the radio interface can be saved. This is very useful especially in attributes that describe user attributes.

Referring back to Table 7, the Modem Attribute EndCom value field includes the Modem Communication Address (CM). It contains two parts: the communication device and the contact address. The part of the device carries information about the supported communication methods, especially if the modem supports packet-switched data (CP), circuit-switched data (CC) or voice, SMS or MMS. The Contact part includes the address (for example, MSISDN Mobile Station Integrated Service Digital Network number). The Status_CC value field indicates the circuit-switched status of the modem (registered or unregistered). The Status_CP value field indicates the packet-switched status of the modem (coupled or unbound). The StatusMobility value field indicates the RMTP (Public Land Mobile Network) resident and possibly RMTP on which the modem is currently mobile. The DC Call Status value field determines the incoming call status of the CC bearer (data or voice; active or not active). The modem attribute may have a list of these incoming call statuses if multi-call capability is supported by the modem. The StatusContext_PDP value field includes PDP (Data Packet Protocol) context information, such as QoS (Quality of Service) information.

In addition to the above examples, the modem value field can be used to load other information related to mobile client transmission capabilities. In a first example, the maximum mobile client bit rate is delivered in the Mode attribute. The receiving client device can then set its baud rate so that the maximum bit rate is not exceeded. In a second example, the client device determines that only packet-switched transmission mode is to be used when sending data files to the client device. A third example is that the mobility device orders only a certain type of communication to be enabled (for example, only voice calls are allowed and data files will not be sent).

User Status Attributes According to a preferred embodiment, the attribute is defined by the user's willingness to engage in an activity. The activity is specified by the value fields that belong to this Availability attribute. Table 9 illustrates the structure for the Availability attribute.

Table 9: Availability Attribute Structure. Table 10 describes the Availability attribute value fields.

Table 10: Availability attribute values. The Status value field as illustrated in Table 11 indicates the status of the availability information.

Table 11: Status field. The Status value field indicates whether or not availability information publishing is enabled. The DIS statement can be used as already described to invalidate the values of the Availability attribute. For example, the SE server may send the availability attribute with the indication DIS after the CM mobile client has terminated the mobile IMPS session. This type of message may also be sent when the connection to the client is suddenly lost. Thus, the receiving mobile client can remove all availability information related to the user and client device that is no longer present in the mobile IMPS system. The DispCom value field in Table 10 indicates whether the user is willing to enter any form of remote communication. The DispFone value field indicates whether the user is willing to make a phone call. The DispSMS value field indicates whether the user is willing to enter an SMS exchange. The DispMMS value field indicates whether the user is willing to enter an MMS (Multimedia Messaging Service) exchange. The DispIM value field indicates whether the user is willing to enter an IM (Instant Messaging) exchange. The DispEmail value field indicates whether the user is willing to enter an EMAIL exchange. The structure for the Image value field is illustrated in Table 12.

Table 12: Picture.

This value field associates an image with any of the value fields in the Availability attribute except the Status, Text, or Image field. The Contained Image value field includes the image, size, or format of the image that may however be restricted. The ReferredImage value field includes the URL for the resource having the associated image. The ValueField field defines the value field to which the image is associated. For example, the editor may associate the image with the DispFone value field that currently has the value 'DISC' (meaning that, for example, the user is limited to telephony) so as to load graphical semantic information about the meaning of DISC. The Image value field can have multiple instances in this attribute. When this value field is included in the attribute, its target value field must also be included in the same attribute. The association is valid only as long as the target value field is valid. When the target value field is updated or invalidated, only the old association with this attribute should be dropped by the receiving client. The structure for the Text value field is illustrated in Table 13.

Table 13: Text. The text value field associates a text string with any of the value fields in the Availability attribute except for the Status, Image, or Text fields. The Text value field includes the text string in the ContentText and the associated value field name in the ValueField. Text size may be limited in the ContainedText element. For example, the editor may associate text with the DispFone value field that currently has the value 'NAVL' (for example, 'in meeting until 2:00 pm') to load additional semantic information about the NAVL meeting. . The Text value field can have multiple instances in this attribute, that is, the same text can be associated with multiple value fields. When this value field is included in the attribute, its target value field must also be included in the same attribute. The association is valid only as long as the target value field is valid. When the target value field is updated or invalidated only the old associations with this value field should be discarded by the receiving client. Images and Text can also be automatically added to the presence attribute.

Personal Status Attributes The PersonalStatus attribute indicates the personal status of the publisher. Options and details are specified by the value of the fields that belong to this attribute. Table 14 illustrates the attribute structure for StatusPersonal.

Table 14: StatusPersonal Attribute Structure. Table 15 illustrates the value fields of the StatusPersonal attribute.

Table 15: Values of the PersonalStatus attribute. The Status value field as illustrated in Table 16 indicates the status of the StatusPersonal information.

Table 16: Status of the PersonalStatus attribute.

This field indicates whether publishing this information is enabled or not. DIS can also be used with the StatusPersonal attribute. The value of the Text field indicates the status of the editor in free text form. The Humor value field indicates the mood of the editor. The Time value field provides the publisher's local time.

According to a preferred embodiment, the image may also be used in the StatusPersonal attribute. As already illustrated in Table 12, the Image value field associates an image with any of the value fields in this attribute, except in the Status or Image field. For example, the editor might associate the image with the Humor value field that currently has the value 'INLOVE' in order to load the semantic graphical information about the meaning of IN LOVE. The Image value field can be used similarly to the one already illustrated with the Availability attribute. The present invention may be implemented on the client device and on existing servers. They all have processors and memory with which the inventive functionality described above can be implemented. The computer program may be loaded from internal or external memory to the client device server processor, providing, when executed on the processor, means for implementing inventive functionality. In addition, hardware implementation or a combination of software and hardware implementation may be used. Figure 4 shows the client device 402 in communication with server 404 according to the present invention. The client device may be similar to one or more mobile clients or non-mobile clients of Figure 1 or any of the other mobile clients shown in Figures 2 and 3. Similarly, server 404 may be similar to the server shown in Figure 1. or any of the other servers shown in Figures 2 and 3. Client device 402 includes device 406 for transmitting or requesting presence information as presence attributes to the server on signal line 408. By transmitting the presence information would correspond, for example, step 302 of Figure 3, in which presence attributes are sent from CM1 to SE or step 202 of Figure 2, in which presence attribute (s) is updated by CM and sent to CM1. SE When requesting the presence information on line 408 would be compared to that requested in step 203 of Figure 2, where the CM requests the presence attribute of the SA. Transmission on line 408 from client device 402 to server 404 could be similar to the transmission path shown in Figure 1 of the mobile client (CM) through the mobile network (RM) through an intermediate ONW network to the server (s). s) IMPS. Or, this could be similar to the path of nonmobile client C through the ONW intermediate network to server S. Of course other possible paths are contemplated as well, and the invention does not depend on the medium path or the combination of the physical medium used . Client device 402 also includes device 410 for receiving presence attributes from server 404 at signal line 412. Such presence information is categorized by a plurality of presence attribute types identified by the attribute name. Server 404 includes device 414 for receiving / transmitting attributes and for maintaining presence information based on received presence attributes.

According to the invention, client device 402 additionally includes device 416 for adding the qualifier to a presence attribute, wherein the qualifier comprises one or more parameters specifying the use of the attribute. The added qualifier is provided at signal line 418 for transmission by device 406 on line 408 to server 404. This can be done via device 420 to determine presence attributes according to instructions received on line 422 from an application 424 The application may also use device 420 to request presence attributes. In any event, the signal may be provided on line 426 from device 420 to device 406 to transmit or request presence attributes on line 408. In case device 416 has added a qualifier, for example, by updating the presence attribute As in step 202 of Figure 2, the signal on line 408 will include the presence attribute with the qualifier having one or more parameters that specify the use of the attribute.

To control the presence attributes in line 412 of server 404, client device 402 will also include device 428 for processing the presence attribute received in line 412 of server 404, according to the qualifier parameters in the received attribute. The presence attribute received on line 412 may be received by device 410 and provided on line 430 to device 428 to process the received attribute. After processing, device 428 may provide a signal on line 432 to application 424 for use by the application as well. Device for adding qualifier 416 may include device 434 for specifying in attribute qualifier display configurations, so that the client receiving the attribute from server 404 is able to display the attribute based on the display configurations. Accordingly, the client device such as the client device of Figure 4 will include device 436 for displaying the attributes received based on such qualifier specified by another client device and received from server 404 at line 412.

Moreover, device 416 may include a device 438 for specifying in the qualifier to be sent to server 404 an application to which the attribute should be addressed at the receiving client. For such client device 402, which receives an application-specific qualifier to which the attribute should be addressed, it will have device 440 to interpret such an attribute received on line 430, to address the attribute received for the application indicated by the qualifier.

Referring now to server 404 in more detail, it may also include device 444 for determining based on the qualifier whether to send an attribute to one or more client devices as specified by the presence group in the server presence database. Such determination may also depend on the authorization provided on line 446 of device 448 to provide such authorization. If the qualifier and authorization indicate that the attribute should be sent on one or more client devices, then server 404 will do so, for example, for the client device as well as similar devices, if appropriate.

It may be that the presence attribute intended by a particular client may not associate with the client's capabilities, according to information known to the server. Such information may be provided, for example, by device 444 on line 450 to device 452 to modify the presence attribute to match client capabilities. The modified attribute can be provided back to device 444 on line 450. On the other hand, in cases where presence attributes are provided according to push technology, the modified presence attribute can be provided on line 454 to device 456, which is capable of taking appropriate steps to push the modified presence attribute to the customer or to more than one customer as appropriate. This can be signaled, for example, on line 458 for device 444.

It should be realized that the function blocks shown in Figure 4 may be executed using discrete hardware, specialized in integrated circuits, microcontrollers, program, unalterable software (firmware), etc., as will be apparent to the person skilled in the art. In addition, the functions assigned to distinguish the function blocks in the figure need not be separated, but may be incorporated into other blocks by the free addition or subtraction of the functions in or other function blocks. Similarly, the cooperative relationships between function blocks can be modified in their order and interrelationships, while at the same time performing the same end results mentioned above. It should also be realized that the details of the client device and the server device shown in Figure 4 may have other forms which are similar to those shown according to the invention. Other aspects of the invention may be illustrated similarly, but by no means identically.

For example, Figure 5 shows client device 502 communicating with server device 504 and device 506 similar to device 420 of Figure 4, for transmitting presence information as presence attributes on line 508 to device 510 for receiving and maintaining presence attributes within server 504, similar to device 414 within server 404 of Figure 4. Likewise, client device 502 may include device 512 to receive presence attributes indicative of presence information on line 514 504 of server device 510. Similar to client device 420 and 416 of FIG. 4, client device 502 of FIG. 5 may include device 516 for composing the presence information attribute identified by a combination of the authorizer, user name, attribute and qualifier, the authorizer specifies the body responsible for maintaining the attribute and the qualifier specifies the use of at Ributo. The then-composite attribute may be provided on line 518 for device 506 for transmission on line 508 for server 504, as shown. Server 504 may include device 520 which is responsible for the then-composite attribute received on line 522 of device 510 to search for already stored attributes containing the same authorization, attribute name, and qualifier combination. If the combination of the identifiers of the received attribute is identical to that of the attribute already stored, for example, stored in storage device 524, the received attribute is used to replace the attribute already stored on signal line 526. Thus, if the parameters If the attribute values are changed, the updated parameters will be stored on the storage device 524. Otherwise, the received attribute is added to the storage device as a new attribute. This function may be performed on device 520 as described above, or may be performed on a completely separate device 528, which receives the attribute received on line 530 of device 520 and includes functions to replace attributes already stored with attributes received if the combination of the identifiers is the same and otherwise adds the attribute received on the connecting line 532 between itself and the storage device 524. The client device 502 will include similar functionality as described above as shown, for example, by the receiving device 540. the incoming attributes on line 542 of device 512 and searching for already stored attributes containing the same identifiers as the received attribute, and device 542 replaces the attribute already stored with the received attribute if the combination of the received attribute identifiers is identical to the attribute already stored. Otherwise, the received attribute is added to the storage device 544. The search device 540 may include the device 542 within or they may be separated as shown in the figure. In the latter case, signal line 546 provides attribute information concerning the attribute received from device 540 to device 542. Storage device 544 may be in two-way communication over line 548 with device 542 to override or add attributes and line 550 with the attribute search device 540 already stored.

As mentioned above, the service capabilities for the dynamic phone book service model of the present invention will now be described. The dynamic phone book service can be viewed as a valuable call service. This is useful “before the call” to enrich cases where part B presence information is presented to part A. In this case, part B is one or more of the user's phonebook entries. Presence information can be divided into the same categories as mentioned above, ie (1) customer availability, (2) user availability, (3) local conditions, (4) personal status, (5) customer capabilities, (6) user attributes, and (7) extended presence service.

Conceptually, the Presence System consists of 602, 604, 606 Presence Clients, 608, 610, 612 Presence Users, 614, 616, 618, 620, 622, 624 Presence User Roles, 626 Presence Proxies, and Presence Servers 628, 630, as shown in Figure 6. The Presence Client is the software or program that enables the user to interact with the Presence System. You are a person who interacts with the Presence System using the Presence Client. Physical device 632, 634, for example, the mobile cellular device or PC, may have a 606, or in special cases, multiple presence client instances 602, 604. The presence client is owned by a single user. The user may own more than one customer, but then these customers are typically on different devices.

Users 608, 610, 612 are conceptually ranked in Publishers and Subscribers. The editor is the originator of the presence information. The subscriber is the receiver of the presence information. You can both be both the publisher of your own presence information and the subscriber of some other publisher presence information. The user can have one or more Roles. The role of the editor is associated with the presence value group called the Presence Group. Presence values of two different presence groups of the same user are independent of each other and are associated with different roles. The subscriber function is the logical receiver of the presence information of the identical function of the editor, that is, of the same presence group. Presence Proxy 626 is an optional network element that enhances the scalability of Presence Service. The proxy temporarily stores the presence values of different presence groups traveling upward from the publisher to the server or downward from the server to the subscriber. When the client is online the proxy can update the client with the current presence information. In addition, when the publisher sends the new presence value to the server, the proxy can update all subscribing clients that are registered with the proxy. The proxy can store presence values only temporarily. Even when presence information is coming from the publisher, the proxy cannot assume that all updates of this presence information are occurring through the same proxy. If the proxy is not aware of the subscriber group associated with the presence group, then the proxy may ask for this information from the server. Presence Server 628, 630 is the network element that holds the valid presence values and information in the groups that are associated with each presence group. The server communicates with presence clients directly or through the proxy. The server informs the proxy about the validity period of the presence values stored by the proxy. When the validity period expires the proxy must discard the values or restore them from the server. The server assigns the presence of item-by-item validity periods based on monitoring how often the presence values change. The validity period is dynamic, that is, it may change during the lifetime of the presence item. The presence server also exchanges presence information with other presence servers, as shown in Figure 6. For example, if the publisher and subscriber belong administratively to different presence servers, then the presence information must follow through both of them. servers. In case the servers are incompatible, there is a need to have a communication port function on one or both servers. Figure 7 shows the structure of presence database 702 according to the invention. Unique presence item 704 has three properties: name 708, attributes 710, and value 712. Presence group 714 consists of a single or more presence items. Presence group 714 belongs to a single user role 716. There can be more than one presence group for a single role. In addition, there is a single authorization group 718 that belongs to a single role 716. The authorization group consists of members who have the right to sign all or part of the same role's presence group.

Items 704, 720, ..., 722 in a presence group are unique, that is, they can be distinguished from each other. Items are first distinguished from each other by their name. If the presence group contains two or more items with the same name then there must be an attribute in each item that carries the ids of these items. Members 724, 726, ..., 728 of group 718 are unique. Different presence groups in different functions 716, 730, ..., 732 of the same editor 734 may contain items with the same name or id. Different groups may also contain the same members. Role 716 can be identified by Role ID, Group ID, or Presence Group ID. For example, the Group ID may be assigned by the service provider and is unique within the domain of the service providers. In addition, the following IDs would be required to address the individual elements in the presence database: GroupID, Nomeltem.

If the presence group contains more than one item with the same name, the Nomeltem must have the IDItem attribute assigned.

Note that IDs such as UserID, DeviceID, and CustomerID are not required. A. Example of Presence Protocol A. 1.0 Signature Presence Canceled (Figure 8). User presence information may be obtained separately from messaging services by issuing a query to the presence server, as indicated, for example, in the message flows shown in steps 203, 204, 205, 206 of Figure 2, or by signing and receive presence items as in Figure 9, or by obtaining presence items as shown in Figure 8. The presence service user can, at any appropriate time, update their presence information on the presence server by sending the update the presence message as shown in Figure 8. As mentioned, the user can issue the get presence message to request the presence information of some other user as also shown in Figure 8. The presence information is delivered back to the requesting user . The editor may update his presence information only partially.

Similarly, the user may request only partial presence information.

If the user is not authorized for the requested presence information empty content is sent to the user. Authorization of presence information for a given user is done by the device by including the user in the group corresponding to the presence group. This is described below in the so-called 'presence database management' part. A. 1.1 UpdatePresence Direction: Presence Client -> Presence Server.

Content Model: (TransactionID, GroupID, Presence) Attributes: None.

Usage: This primitive updates the values of one or more of the presence items on the presence server. Presence items to be updated are loaded into the Presence information element. If there are items in Presence that do not exist on the server for a particular GroupID then the server allocates storage for these new items and copies the contents of this message. Otherwise, the server replaces the old value with the new value.

No UserID or IDEditor is required in the content. The association between the editor and the XML document containing the UpdatePresence primitive is done in the authentication protocol. A. 1.2 Transaction ID Content Model: (#PCDADOS) Attributes: None Usage: This is a unique identifier that associates the client request to the server with the corresponding server-to-client response. The client may have to send more than one request to the server before getting the first response back. The first answer does not necessarily refer to the first request. So there is a need to have a mechanism that associates requests and responses together. Typically, the TransactionID is a sequential number. This is designated by the client in the request and used by the server in the response. A. 1.3 GroupID Content Model: (#PCDADOS) Attributes: None Usage: This id uniquely identifies within the service provider domain, the publisher role including the authorization group and the presence group. This is designated by the presence service provider. A. 1.4 UpdateStatus Direction: Presence Server - »Presence Client Content Model: (Transaction ID, CodeStatus) Attributes: None Usage: This primitive is the response from the presence server to the UpdatePresence client request. CodeStatus can have the following values: unsupported, reassignment, success, failure. A. 1.5 GetPresence Address: Presence Client - »Presence Server Content Model: (IDTransaction, GroupID, PresenceName?) *) J PresenceName?) Attributes: None Usage: This primitive is used to request presence information from the Presence server. presence. There may be zero or more GroupIDs. For each GroupID the optional PresenceName may be coupled. When GroupID is not used then the order covers all groups that the user is a member of. The server associates the identity of the requesting user with the request through the authentication protocol. PresenceName is defined later in this document. This lists these presence items by the name from which the value is requested. This is optional. This is coupled with the GroupIDs or may be alone when none of the GroupIDs are listed. When coupled with the GroupIDs the server limits the search for presence items to the given group. When not present the values of all presence items are requested. A. 1.6 ItemsPresence Address: Presence Server -> · Presence Client.

Content Model: (IDTransaction, CodeStatus, (GroupID, Presence) *).

Attributes: None Usage: This primitive provides the list of requested presence items and the order result status. The Presence element is the presence group corresponding to a particular GroupID and is defined later in this document. CodeStatus can have the following values: unauthorized, item unavailable, success, failure. A.2.0 Signed Presence (Figure 9) Another mechanism for delivering presence information is to sign someone's presence information. The message flow is shown in Figure 9. The requesting user sends the presence message signature A.2.1 to the presence server to sign someone's presence information.

When the presence information signature is complete, the requesting user will initially receive the new presence information A.2.2 and whenever the other party updates their presence information.

When the requesting user no longer wishes to receive the presence information, they may unsubscribe from the presence information A.2. Alternatively, presence information can be signed for a period of time and the unsubscribe message is not required. The requesting user may only subscribe to the part of the presence information he is authorized to obtain. A.2.1 SubscribePresence Direction: Presence Client -> Presence Server.

Content Model: (Transaction ID, Subscription Period ?, ((GroupID, PresenceName?) *) | PresenceName?) Attributes: None Usage: This primitive is used to sign the presence information of the publisher functions for which the subscriber is authorized. The optional GroupID specifies the editor role that is subscribed. When the GroupID is lost then all functions for which the subscriber is authorized are signed. Each GroupID can be associated with PresenceName which limits the signed items within the group to those listed in PresenceName. The Subscription Period option specifies the length of time for the subscription. When the subscription is lost, it lasts until the corresponding CancelSubscriptionPresitive primitive is invoked or until the service provider terminates the subscription. PresenceName specifies the presence items that are signed from the authorized group. When this is lost then all presence items that the user is authorized into within the presence group (groupID) are signed. When used alone without the GroupID then the named items of all authorized groups are signed. PresenceName is defined later in this document. The subscriber's identity is discovered in the authentication protocol. A. 2.2 Subscription Period Content Model: (#PCDADOS) Attributes: None.

Usage: This defines the length of the subscription period. The unit of time is TBD. Alternatively, the content may indicate the end date of the subscription. A.2.3 PushPresence Direction: Presence Server -> Presence Client.

Content Model: (GroupID, Presence) + Attributes: None.

Use: This primitive pushes signed presence items that have been modified by the publisher to users. The GroupID identifies the function. A.2.4 CancelSubscriptionPresence Direction: Presence Client -> Presence Server.

Content Model: (TransactionID, ((GroupID, PresenceName?) *) | PresenceName?) Attributes: None.

Usage: This primitive is used to unsubscribe from presence information. Subscription termination may be limited for certain groups and may also be limited for certain presence items. When no GroupID is determined it is possible to limit subscription termination for named presence items in all groups. When no GroupID and no PresenceName are determined then all user signature is terminated. A.2.5 Subscription Status Address: Presence Server -> Presence Client.

Content Model: (TransactionID, StatusCode, (GroupID, PresenceName) *) Attributes: None.

Usage: This primitive resumes CodigoStatus for the unsubscribe operation and lists the items present and the groups that are then subscribed. CodeStatus can have the following values: unsupported, non-existent item, unsigned item, success, failure. A.3.0 Presence Database Management The presence user can manage their user groups and presence groups on the presence server. The role containing the user group and presence group is created using the message CreatePresenceGroup A.3.1. The presence server will respond with the message PresenceGroup Status A.3.6 indicating the status of the requested operation and the id for the created group. The Presence Info A.3.7 message is sent to group members indicating the presence items they are allowed to obtain or subscribe to. The presence user can request group information with the message GetStatusGroupPres A.3.8. The request for group information is limited to the group owner. The presence user who owns the user's group can add or delete group members or presence items to the presence group. The editor can send the deletion of the group via the message DeleteGroupPresence. A.3.1 CreatePresenceGroup Direction: Presence Client— »Presence Server.

Content Model: (Transaction ID, Member List, Presence).

Attributes: None.

Usage: This primitive prompts the server to create a role on the presence server. The authorization group contains the members in the Member List and the presence group is contained in the Presence. A. 3.2 Member List Content Model: (DescriptionMember) + Attributes: None.

Usage: The member list. The description originates from the user. A.3.3 DescriptionMember Content Model: (DMOriginatingUsu ?, DMOriginatingServer?) Attributes: None.

Usage: The originating part of the user is the member description as seen by the user. The originated part of the server is the member description as stored in the server database. A.3.4 DMOriginatedUsu Content Model: (#PCDADOS) Attributes: None Usage: This is a user-sourced device for identifying the person. This can be the name, an MSISDN of one of the target person's phones, the email address, the SIP address, etc. This can also be a combination of these. The description data format is not within the scope of this document, but the known format such as vCard should be used. A.3.5 DMOriginedServer Content Template: (#PCDADOS).

Attributes: None.

Usage: This is a server-originated device to identify the person. This could be the name, MSISDN of one of the target person's phones, email address, SIP address, etc. This can also be a combination of these as stored in the server database. The description data format is not within the scope of this document, but the known format such as vCard should be used. A.3.6 PresenceGroup Status Direction: Presence Server -> Presence Client.

Content Model: (Transaction ID, StatusCode, (GroupID, MemberList, PresenceName) *).

Attributes: None.

Use: This primitive takes over the currently existing Publisher Roles Group IDs along with the group members and presence item names for the role. The server has assigned the new GroupID to the new role if the operation was successful. The server has populated the originating part of the MemberList server. This allows the editor to verify that the group contains the correct members. The server should not provide any confidential or personal information in the Member List in excess of the level already existing in the originating part of the user or the level that is required to identify the person only. This is TBD. CodeStatus can get the following values: unsupported, unknown member, unknown presence item, success, failure. A.3.7 Presence Info Direction: Presence Server—> Presence Client Content Model: (GroupID, Presence?) + - Attributes: None.

Use: This primitive warns new presence items for the authorization group. The message contains all presence items from the given authorization group - both signed and unsubscribed. This message is sent to new members in the group if the group member has changed or to all group members if new presence items have been added. The message is sent to the removed group members so that there is no presence group (Presence) associated with the GroupID. A. 3.8 GetStatusPresGroup Direction: Presence Client —ϊ Presence Server.

Content Model: (TransactionID, GroupID *).

Attributes: None Usage: This primitive requests the message StatusGroupPresence from server. The user can only request information from their own group. GroupID limits information to the given groups. When no GroupID exists then the status is resumed from all groups owned by the requester. A.3.9 AddMembers Direction: Presence Client -> Presence Server Content Model: (TransactionID, (GroupID, MemberList) +) Attributes: None.

Usage: This primitive asks the server to add named members to the given groups. A.3.10 Remove Member Address: Presence Client -> Presence Server Content Model: (TransactionID, (GroupID, MemberList) +) Attributes: None.

Usage: This primitive asks the server to remove named members in the given groups. The MemberList is populated with information originating from the server. A. 3.11 DeletePresenceGroup Direction: Presence Client -> Presence Server Content Model: (TransactionID, GroupID *) Attributes: None.

Usage: This primitive prompts the server to remove one or more of the editor functions. The GroupID identifies the role that is to be removed. When no GroupID is provided then all editor functions will be removed. A.3.12 AddPresence Address: Presence Client - »Presence Server Content Model: (Transaction ID, (GroupID, Presence) +) Attributes: None.

Usage: This primitive prompts the server to add the given presence items to the given roles. A. 3.13 RemovePresence Address: Presence Client -> Presence Server Content Model: (Transaction ID, (GroupID, Presence?) +) Attributes: None.

Usage: This primitive prompts the server to remove certain presence items from certain roles. When there is no Presence element associated with the GroupID then all presence items are removed from the function. A.3.14 Dynamic Client Switching The publisher or subscriber may change his client at any time. Typically, it also changes the client device. In a rare case the user can only swap the client instance on the same device. The new device can be a TE and the old one MT or vice versa. Switching to the new MT is also possible. Client switching requires the user to copy or synchronize his or her presence data from the old customer to the new customer. In the case of the publisher there may be some client-specific presence data that is static for a particular client and is not included in the sync group. Synchronization can occur locally or it can be an assisted network. In any case, existing synchronization protocols should be used. This is not within the scope of the presence protocol.

Another issue brought about by the subscriber switching is the registration of the new customer to be the active customer who receives the presence related to push messages. Registration can occur automatically (no user confirmation is required), semi-automatically (user confirmation requested) or manually (user must start registration) depending on whether: - User activates new customer on same device (automatic ); - SIM user switches to new device (automatic); - User has a different SIM on the new device, but only the new device is turned on (semi-automatic); or - The user has a different SIM on the new device and both the new device and the old device are switched on (manual).

In all these cases registration can be controlled by lower level protocols. For example, if SIP-protocol is the transport protocol chosen for presence documents then this protocol can also be used for registration. A.4.0 DTD for Presence Protocol <! - -Root Element- -> <! ELEMENT ProtocolPresence (UpdatePresence | UpdateStatus) GetPresence | ItemsPresence | SubscribePresence | PushPresence | CancelSignaturePresence | Subscription Status | CreatePresenceGroup | StatusGroupPresence | InfoPresence | GetStatusGroupPres | AddMembers | RemoveMembers | DeleteGroupPresence | AddPresence | RemovePresence)> <! ATTLIST Protocol VersionPres NMTOKENS # REQUESTED> <! ELEMENT UpdatePresence (Transaction ID, GroupID, Presence)> <! Transaction ID ELEMENT (#PCDADOS)> <! GROUP ID ELEMENT (#PCDADOS)> <! Presence ELEMENT (#PCDADOS )> <! ELEMENT UpdateStatus (Transaction ID, CodeStatus> <! ELEMENT CodeStatus (#PCDADOS)> <! ELEMENT GetPresence (TransactionID, ((GroupID, PresenceNames?) *) | PresenceNames?> <! ! ELEMENTPresence Items (Transaction ID, StatusStatus, (GroupID, Presence) *)> <! SubscribePresence Element (Transaction ID, Subscription Period?) ((Group ID, Presence Names?) *) | Presence Names?)> <! Subscription Element (#PCDADOS)> ! ELEMENT PUSHPresence ((GroupID, Presence) +)> <! ELEMENT CancelSignaturePresence (IDTransaction, ((GroupID, NamesPresence?) *) | NamesPresence (IDTransaction, CodeStatus, (IDGroup, Names> *)) <! ELEMENT CreatePresenceGroup (TransactionID, Lis Members, Presence)> <! ELEMENT Member List ((DescriptionMember) +)> <! ELEMENT DescriptionMember (DMOriginatingUsu ?, DMOriginatingServer?)> <! DM ELEMENTOriginatedUsu (#PCDADOS)> <! DM ELEMENTOriginedServer (#PCDADOS)> <! ELEMENT StatusPresenceGroup (TransactionID, CodeStatus, (GroupID, MemberList, PresenceName) *)> <! ELEMENTPresence Info ((GroupID, Presence?) +)> <! ELEMENT GetStatusPresGroup (TransactionID, GroupID *)> <! Add Member (Transaction ID, (GroupID, MemberList) +)> <! Remove Member (ID, Transaction, (GroupID, MemberList) +)> <! DeletePreparencyGroup (Transaction ID, GroupID *)> <! Presence Add (TransactionID, (PresenceID) ) +)> <! ELEMENT RemovePresence (Transaction ID, (GroupID, Presence?) +)> <! - - DTD END - -> B. Presence Content Format Example.

As indicated above, presence content can be divided into the following classes: - Client Availability: Presence attributes that describe client availability for communication, eg network reachability, GPRS coupled, status on / off. - User Availability: Presence attributes that describe the user's availability for communication, for example, ready, meeting, busy, out of area, calling, chatting, do not disturb, etc. - Location Conditions: Presence attributes that describe the user's local environment, for example, local time, noise / quiet environment, internal, external, user location, in terms of eg geographic location, RMTP visited, city / street, premises. - Personal Status: Various personal attributes that describe the user's personal status, for example, mood, personal interest and intentions. - Client Capabilities: Presence attributes that describe client capabilities, for example, to support different communication devices, different media types, and different characteristics. - User Attributes: Presence attributes allowing the customer or user to define their own textual presence values and references to external values. - Extended Presence Service: Service provider dynamically defined on non-standard presence attributes that, however, need to be passed through standard presence servers and proxies. B.l Design Goals The volume of presence reporting is to send changes in the value portion of presence items to subscribers. Often only the single value has changed. In order to minimize the amount of data transferred, the design goal is to keep the hierarchical representation of presence items as simple as possible. For this reason the presence items are extended over the presence classes described above. Instead, classes can be determined in presence items as an optional attribute. D.2 Common Attributes.

Presence elements contain a variety of attributes, much of which can be used on any presence item. D.2.1 Version.

Content Syntax: NMTOKENS.

Required: Yes.

Usage: This provides the format version of the presence content. D.2.2 Class Content Syntax: NMTOKEN

Required: No Usage: This indicates the class to which the attribute belongs.

Possible values are: CUSTOMER AVAILABILITY, USER AVAILABILITY, LOCAL CONDITIONS, PERSONAL STATUS, CUSTOMER CAPABILITIES, JJSUARY ATTRIBUTES, PRES EST SERVICE.

D.2.3 ID

Content Syntax: PUBIDLITERAL

Required: No Use: This is a unique ID for the named presence item. This is designated by the customer. D.2.4 Memory Capacity.

Content Syntax: NMTOKEN.

Required: No Use: This indicates whether the presence item can be stored by proxies or not. Possible values are: YES, NO. This is designated by the customer. If this attribute is lost, the value is NOT assumed. D.2.5 Validity Period Content Syntax: NMTOKEN

Required: No.

Usage: This is the validity period for the stored presence item. The value is the time in seconds. This is designated by the presence server. D.2.6 DeviceName Content Syntax: NMTOKEN

Required: No Usage: This is the name of the client device. This is designated by the customer. D.2.7 Accuracy Content Syntax: NMTOKEN

Required: No Usage: This is the accuracy of the positioning device. This is determined in meters. D. 2.8 Typolmage Content Syntax: NMTOKEN

Required: No Usage: This is the encoding of the content of an image.

Some possible values are: JPEG, GIF, BMP. D.2.9 SoundType Content Syntax: NMTOKEN

Required: No Use: This is the type of sound codec used to encode sound. Some possible values are: AMR, EFR, MP3, AAC, MIDI. D.2.10 RefExt Content Syntax: PUBIDLITERAL

Required: No Usage: This is the URL that provides an external reference. D.2.11 ChangeRefExt Content Syntax: NMTOKEN

Required: No Usage: This indicates that the content of the external reference has changed. Possible values are: YES, NO. D.2.12 Swap Content Content Syntax: NMTOKEN

Required: No Usage: This is a counter from 0 to 255, which indicates the change in content value. The server or proxy can store the contents (but is not required) of the last 32 values. Some values for the two contents within the last 32 values should match the same content. D.3 Customer Availability D.3.1 Connected Device Content Model: (#PCDADOS) Attributes: Class, ID, Memory Capacity, Validity Period, DeviceName.

Usage: This provides the on / off status of the user terminal. The editor adds this item to the server role when using group management messages. Then the value part is maintained by the network. The user may have more than one terminal in their presence information. In this case the use of the ID attribute is required. Content can be set to “ON” or “OFF”. When the user terminal is on but outside the network coverage area, the network assigns the value “OFF” to this item. D.3.2 MobilityDevice Content Model: (#PCDADOS) Attributes: Class, ID, Memory Capacity, PeriodValidity, DeviceName Usage: This indicates to the subscriber that the publisher is mobile on the visited network. The user may have more than one terminal in their presence information. In this case, use of the ID attribute is required. Content can have the values “YES” or “NO”. D.3.3 ContentType: Content Model: (#PCDADOS) Attributes: Class, ID, Memory Capacity, Validity Period, DeviceName Usage: This indicates the type of mobile network to which the publisher is currently attached. Content can have the values “2G”, “3G-99”, “3G-R4” or “3G-R5”. The user may have more than one terminal in their presence information. In this case, use of the ID attribute is required. D.4 User Availability. D.4.1 User Status Content Template: (#PCDADOS) Attributes: Class, ID, Memory Capacity, PeriodValidation Usage: This indicates the current status of the publisher in terms of the amount of distraction they are intending to accept. The following values are defined: “availability”, “silence”, “in-car”, “busy”. D.4.2 Preferred Contact Content Model: (#PCDADOS) Attributes: Class, ID, Memory Capacity, PeriodValidation Usage: This indicates that this is the current preferred contact method for the publisher. The following values are defined: “PHONE”, “VOICE MESSAGE”, “MESSAGE”, “MAIL”, “NO_CONTACT”. D. 4.3 Preferred Defaults Content Template: (#PCDADOS) Attributes: Class, ID, Memory Capacity, PeriodValidation Usage: This is the goal of presence information that the publisher can send to the presence server. The information is associated with a function like other presence information, but this item is not available to subscribers. Instead, it controls the values of the 'PreferredContact' element. This specifies the preferred default contact for certain time periods. The user specific time periods may overlap or the time period may even completely include the other. The server exchanges the value of the PreferredContact element according to the Preferred Defaults upon expiration of the specified periods. This, however, does not block the user who directly exchanges the PreferredContact value. In addition, the user who directly changes the PreferredContact value does not block the server that changes it again when the period expires. The user can remove the default mechanism by sending this element with empty contents to the server. D.4.4 Time Period Content Model: (StartPeriod, EndPeriod, Repetition Period ?, PrecedencePeriod) Attributes: None.

Usage: This describes the beginning of a period, for example, the start time, the end of the period, for example, end time, the repeating period, for example, 'DAY' and the period precedence. D.4.5 HomePeriod Content Model: (#PCDADOS) Attributes: None.

Use: This is the beginning of the period. This can be Time, Time of Day of Week, Time of Day of Month or Full Date .... D.4.6 EndPeriod Content Template: (#PCDADOS) Attributes: None Usage: This is the beginning of the period. This can be Time, Time of day of week, Time of day of month or full date. The resolution must be the same as the StartPeriod. D.4.7 Repetition Period Content Model: (#PCDADOS) Attributes: None Usage: This provides the repeating period for the beginning- end. This should have one of the following values: “DAY”, “WEEK”, “MONTH”. When this element is not included in the period description then it is assumed that no repetition is applied. D.4.8 PrecedencePeriod Content Model: (#PCDADOS) Attributes: None Usage: This element resolves the conflict between overlapping periods. This can have a numeric value between 0 and 9. The number 0 is the highest precedence. When two or more periods overlap then the server gets the contact preference associated with the highest precedence value. D.4.9 ContPref Content Template: (#PCDADOS) Attributes: None Usage: This indicates that it is the default preferred contact method associated with the period for the publisher. This can have the same values as the 'Preferred Contact' element. D.5 Location Conditions D. 5.1 LocalTime Content Template: (#PCDADOS) Attributes: Class, ID, Memory Capacity, PeriodValidation Usage: This provides the publisher's local time. D.5.2 LocationMeasurement Content Model: (#PCDADOS) Attributes: Class, ID, Memory Capacity, PeriodValidity, Accuracy.

Usage: This provides the measured position of the client device. Measurements can be either sensor based (eg GPS) or network based or a combination of both. The Accuracy attribute provides an indication of the common positioning accuracy achieved by the method. Content includes at least the lateral position (x and y coordinates), but may also include the vertical position. If the service provider supports 'Converted Location' described below then MeasuredLocation may be the input information for the service provider's conversion process, for example, cartographic correlation. D.5.3 Converted Location Content Model: (#PCDADOS) Attributes: Class, ID, Memory Capacity, Period Validity Use: This information is typically sourced from the service provider, but may also originate from the publisher. This determines the user's location determined in the text form understood by the human being, such as the street name. Information is derived by converting the measured position into this form, for example, cartographic correlation. D.5.4 Required Location Content Model: (#PCDADOS) Attributes: Class, ID, Memory Capacity, Period Validity Use: This provides the publisher's location as directed by the publisher himself. Content is a short text string. D.5.5 EnvironmentUser Content Model: (Environment + Attributes) Attributes: Class, ID, Memory Capacity, PeriodValidation Usage: This determines some environmental attributes about the user. D.5.6 AttributesEnvironment Content Model: (#PCDADOS) Attributes: None Usage: The attributes defined are: “INTERNAL”, “EXTERNAL”, “QUIET”, “NOISE”, “ALONE”, “GROUP”. D.6 Personal Status D. 6.1 StatusText Content Template: (#PCDADOS) Attributes: Class, ID, Memory Capacity, PeriodValidation Usage: This is a short text (approximately 30 characters) that the user can type. D. 6.2 ContentTable Status Content Template: (#CDADOS) Attributes: Class, ID, Memory Capacity, Validity Period, Typolmage Use: This is an image that the user can attach to their status information. It is loaded into XML content as an encoded transfer, for example, base64. The Typolmage attribute describes the encoding of image content, for example, JPEG. D.6.3 SoundStyle Content Model: (#CDADOS) Attributes: Class, ID, Memory Capacity, Validity Period, SoundType.

Usage: This is a short sound clip (approximately 5 to 30 seconds) that the user can attach to their status information. This is loaded into XML content as an encoded transfer, for example, base64. The SoundType attribute describes the encoding of sound content, for example AMR, MP3, AAC, MIDI, etc. D.7 Client Capabilities Client capabilities in the context of the presence device, the capability of the device hosting the client for various types of human-to-human communication. This is very different and simpler to issue than allowing an application program to take full advantage of the client device's existing hardware and software capabilities.

Human-to-human communication classes are: messaging, email, voice calling, and multimedia calling. In particular presence is excluded from communication classes. The purpose of presence is to alert others about the media and other attributes of the user, but not to have the dual mode communication device itself. For this reason, the use of the term 'Customer Capabilities' to classify presence information is lost.

Client capabilities are expanded with network capabilities. This means, for example, that the publisher has video calling capability only when their client device has this capability AND the network to which they are currently mobile supports this capability. This dynamically takes customer capability information. D.7.1 CapabilitiesMessage Content Model: (MessageType *) Attributes: Class, ID, MemoryPaper, PeriodValidation Usage: This provides a list of the client device's dynamic message capability. Empty list means no message capacity currently exists. D. 7.2 MessageType Content Template: (#PCDADOS) Attributes: None.

Usage: This provides the type of message capability of the client device. The content can be one of the following: “SMS”, “MMS”, or “X - Message Application Name” The message application name field is a device-specific message method, for example, smart messaging. D.7.3 CustomerEmail Content Model: (CustomerEmailType) Attributes: Class, ID, MemoryEmail, LifeValidation Usage: This provides the dynamic email capabilities of the client device. Empty list means no email capabilities currently exist. D.7.4 CustomerEmailType Content Model: (#PCDADOS) Attributes: None Usage: This provides the client device's email client type. The content can be one of the following: “SMTP”, “POP3”, “IMAP4” or “X - Mail Application Name”. The client program should not render the mail protocol names, as for the user. Instead the user program should understand the client device's email template and interpret these names within the scope of this email template. The information presented to the user should also be meaningful to the user. D. 7.5CallCall Capacity Content Model: (#PCDADOS) Attributes: Class, ID, Memory Capacity, PeriodValidation Usage: This provides the dynamic voice calling capabilities of the client device. The content is one of the following: “NONE”, “CALL”, CALL_VOZ_RICA ”. D. 7.6 CapacityMultimedia Call Content Model: (CapMM *) Attributes: Class, ID, Memory Capacity, PeriodValidation Usage: This provides the user's single-mode and dual-mode dynamic multimedia communication capabilities. The empty list indicates that no capacity currently exists.

D.7.7 CapMM

Content Model: (#PCDADOS) Attributes: None Usage: This provides the type of multimedia calling capability. This can be one of the following: “STREAMING_VIDEO_ UP”, “STREAMING_VIDEO_END”, “CALL”, “RICH VIDEO CALL”. D.8 User Attributes This class contains both user-defined and customer-specific presence data. D. 8.1 ItemPresenceUser Content Model: (#PCDADOS) Attributes: Class, ID, Memory Capacity, Validity Period, RefExt, ChangeRefExt.

Use: This provides a means for the user to make their own presence items. If more than one user-specific presence item is defined for the same role then use of the ID attribute is required. The content may be short text. The optional RefExt attribute is a URL of an external object referenced by this presence item. The URL can reference another part of the multipart MIME that loads the presence item XML document, or this can be a reference to an external object. The optional ChangeRefExt attribute can be used to indicate subscribers that the external object has changed. D.8.2 CustomerType Request Content Model: (EMPTY) Attributes: Class, ID, Memory Capacity, PeriodValidation Usage: This is a special element used by the publisher to request client types from their subscribers. When the publisher adds this element to their presence data for a given function, then the server sends it to all subscribers of the presence information with the message PushPresence. Optionally this can also be included in the Presence Items message used by non-subscribers to request specific presence items. This element is not warned in the Presence Info message. This is not a subscribable presence element. The presence server after first sending this item to subscribers may periodically include this item also to other PushPresence messages to make sure that all subscribing clients have this item. Clients after receiving this item send their client types to the presence server. In addition, the client should send this type to the server each time the client is activated, when this item is presence information stored on the client. An alternative way of getting the publisher to know his client's subscriber types would have been for the publisher to subscribe to his client types. This, however, is a different business model. The publisher may not always be a subscriber to his own subscribers. This element allows the publisher to obtain client types within the contractual framework between the publisher and the presence service provider. In addition, this method delegates to the subscriber client to send their types to the server. If the publisher had used the subscription model to obtain the client types, then authorization of this information for the publisher would have been made at the subscriber's discretion. D.8.3 CustomerType Content Model: (CustomerName, CustomerManager, CustomerVersion) Attributes: Class, ID, Memory Capacity, PeriodValidation Usage: Knowledge of subscriber client types is used by publishers to enable customer-specific extensions for the presence group. This makes no sense for the publisher to use these extension items if their subscribing clients are unable to encode them. The subscriber client sends client type information to the presence server using the UpdatePresence message. The GroupID used in the message belongs to the editor function and not the editor function itself. This is an exception to the general rule, where the user is allowed to update presence information only from his own function. The presence server sends the information for this element to the editor using the PushPresence message. The GroupID used belongs to the editor function. From the publisher's point of view, he then obtains presence information from his own presence group. The publisher can include his own client type in his presence group. Therefore, this information is controlled like any other presence information and does not imply any special procedure on the presence servers or subscriber clients. D. 8.4 CustomerName Content Template: (#PCDADOS) Attributes: None Usage: This element provides the name of the presence client application. D.8.5 ManufacturerCustomer Content Model: (#PCDADOS) Attributes: None Usage: This element provides the name of the presence client manufacturer. D. 8.6 Customer Version Content Model: (#PCDADOS) Attributes: None Usage: This element determines the version of the client application. D. 8.7 ItemPresenceCustomer Content Model: (ClientCustomer, ItemPresCli) Attributes: Class, ID, Memory Capacity, Validity Period, ChangeContent.

Usage: This element is the specific presence item of the editor client application. CustomerType is the client type of the publisher's presence client. None of the attributes are used on the CustomerType item when used as part of this element. If the publisher defines more than one customer-specific presence item, then use of the ID attribute is required. The optional ChangeContent attribute is a counter from 0 to 255. When used, it is increased each time it changes the content of the presence item. This provides an alternative means for the presence server to detect the change in non-standard presence item content. The other alternative would have been for the presence server to assume that content changes every time this item is sent to the server with the same attribute ID. The server behaves this way when the ContentChange attribute is not used by the client. When two items with the same attribute ID have the same counter value in SwapContent, then the content of these two items is the same. D. 8.8 ItemPresCli Content Template: (#PCDADOS) Attributes: None Usage: This element is the extent of customer-specific presence. This syntax and structure is assumed to be known to the client, but not to the network elements. D.9 Extended Presence Service The extended presence service class is significant in providing the service provider specific extension for the presence service. Because the client application-specific extension only service endpoints (that is, the publisher and subscribing clients) need to be able to decode the extensions. The presence server may also understand extensions, but it is not delegated by this document. The difference between the customer-specific extension method and this method is that the customer-controlled service provider does not need to implement the default presence items. Presence items are assumed to be completely defined by the service provider and there is a means to update clients hosted on the user's device with the new features. One possible upgrade method is to download the program through the air interface. If the service provider creates new types of presence items then it needs to update existing customers to support these new types. The client controlled by the service provider communicates with the presence server directly and not through the default presence client. The default presence client ignores all elements of this class. Extended Presence Service primarily uses the elements of this class. This is allowed for use with default presence element definitions as well. It uses the default presence protocol. D.9.1ExtendPresence Content Model: (#PCDADOS) Attributes: Class, ID, Memory Capacity, Validity Period, ChangeContent.

Usage: Use of attribute ID is required if more than one presence item is defined by this mechanism. The optional ContentChange attribute is also available for this element. The syntax and representation of the contents are not within the scope of this document. Presence servers and proxies should allow content to reference objects loaded in the same multipart MIME as the XML documents containing this element. D. 10 DTD for Presence Content Format <! - - Root Element - -> <! ELEMENT Presence (DeviceLink | MobilityDevice | NetworkType | StatusUser | ContactPreferred Defaults | LocationMeasurement | LocationConverted | LocationDisplay | StatusText | | StatusSound | CapabilitiesMessage | EmailClient | CapabilityCallVozing | CapabilityCallMultimedia | ItemPresenceUser | OrderCustomer Type | ItemPresenceCustomer | PresenceExt)> <! ATTLIST Version Presence NMTOKENS # REQUESTED> <! ELEMENT Connected Device (#PCDADOS)> <! ATTLIST Connected Device NMTOKEN Class # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED Validity Period NMTOKEN # IMPLIED Device Name NMTOKEN # EVlPLICITE> <! ELEMENT MobilityDevice (#PCDADOS)> <! ATTLIST MobilityDevice Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED PeriodValidity NMTOKEN # IMPLIEDDevice Name <IMPLIED #! IMPLIED Type! PUBIDLITERAL # Implied Capacity NMTOKEN # Implied PeriodValidity NMTOKEN # IMPLIED Device Name NMTOKEN # IMPLIED> <! ELEMENT StatusUser Status (#PCDADOS) Preferred Contact (#PCDADOS)> <! ATTLIST Preferred Contact NMTOKEN Class # IMPLIED PUBIDLITERAL ID # IMPLIED Capacity NMTOKEN Memory # IMPLIED PeriodVALITY NMTOKEN # IMPLICIT> <! ELEMENT DefautsPreferred ((<PeriodTime)) ATTLIST DefaultsPreferred Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED Memory Capacity NMTOKEN # IMPLIED Period Validity NMTOKEN # IMPLIED> <! ELEMENT Time Period (StartPeriod, EndPeriod,> Repetition !, Repetition!) ELEMENT HomePeriod (#PCDADOS)> <! ELEMENT EndPeriod (#PCDADOS)> <! REPEAT PERIOD (#PCDADOS)> <! ELEMENT PrecedencePeriod (#PCDADOS)> <! ContPref ELEMENT (#PCDADOS)> <! ELEMENT TimeLocal (#PCDADOS)> <! ATTLIST TimeLocal Class NMTOKEN # IMPLIED 1D PUBIDLITERAL // IMPLIED CapacityMemory NMTOKEN # IMPLIED! MeasuredLocation (#PCDADOS)> <! ATTLIST MeasuredLocation NMTOKEN Class // IMPLIED PUBIDLITERAL ID // IMPLIED Memory Capacity NMTOKEN // IMPLIED Accuracy NMTOKEN # IMPLIED> Accuracy NMTOKEN #LOCKED = CONSTRUCTION LOCATED! // IMPLIED PUBIDLITERAL ID // IMPLIED Memory Capacity NMTOKEN // IMPLIED PeriodValidity NMTOKEN # IMPLIED> <! ELEMENT Required Location (#PCDADOS)> <! ATTLIST Required Location NMTOKEN Class // IMPLIED PUBIDLITERAL ID // IMPLIED Capacity NMTOKEN Memory // IMPLIED PeriodVality NMTOKEN # IMPLIED> <! IMPLIED CapacityMemory NMTOKEN # IMPLIED Period Validity NMTOKEN # IMPLIED> <! ELEMENT AttributesEnvironment (#PCDADOS)> <! ELEMENT StatusText (#PCDADOS)> <! ATTLIST StatusText Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED Period Validity NMTOKEN # IMPLIED> <! ELEMENT StatusFilter (#PCDADOS)> <! ATTLIST StatusFilm Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED PeriodVality NMTOKEN # IMPLICIT Typolmage NMTOKEN # IMPLIED> <! STATUS ELEMENT (#PCDADOS)> <! ATTLIST StatusSom Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLICIT Capacity NMTOKEN # IMPLICIT Period Validity NMTOKEN # IMPLICIT> <! PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED PeriodValidity NMTOKEN # IMPLIED> <! ELEMENTTypeMessages (#PCDADOS)> <! ELEMENT EmailClient (TipoEmailClient *)> <! ATTLIST EmailClient Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED Period Validity NMTOKEN # IMPLIED> <! ELEMENT TypeEmailCustomer (#PCDADOS)> <! ELEMENT CallCall Capacity (#PCDADOS)> <! ATTLIST CapacityCallVoz Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED Period Validity NMTOKEN # IMPLIED> <! ELEMENT CapacityCallMultimidia (CapMM *)> <! ATTLI ST CapacityCallMultimidia Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED

NMTOKEN Period # Implied> <! CapMM ELEMENT (#PCDADOS)> <! ELEMENT ItemPresenceUser (#PCDADOS)> <! ATTLIST ItemPresentUser NMPUBITLITERAL # IMPLIED CapacityMemory IMPLIED IMPLITIBLE #Implete MPPLIED Modem # IMPLIED> <! ELEMENT RequestTypeClient (EMPTY)> <! ATTLIST OrderTypeClientClass NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLICIT CapacityNMTOKEN Memory # IMPLICIT PeriodValidity NMTOKEN # IMPLICIT> <! ATTLIST TypeClient Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED PeriodVality NMTOKEN # IMPLIED> <! ELEMENT CustomerName (#PCDADOS)> <! ELEMENT ManufacturerClient (#PCDADOS)> <! CUSTOMER VERSION (#PCDADOS)> «CUSTOMER ItemPresenceCustomer (TypeCustomer, ItemPresCli)> <! ATTLIST ItemPresenceCustomer Class NMTOKEN # IMPLICIT IDENTITY CapacityNMTOKEN # Implicit Period ! ETC Presence ELEMENT (#PCDADOS)> <! ATTLIST ETC PresenceExt Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED Capacity NMTOKEN Memory # IMPLIED Validity Period NMTOKEN # IMPLICIT ExchangeContent NMTOKEN # IMPLIED> DT> --DD - - End DTD for Presence Names is the same as Presence except that only the presence item names and attributes are completed. Presence values are not used. <! - - Root Element - -> <! ELEMENT NamesPresence (DeviceConnected | MobilityDevice | TypeUser | StatusUser | ContactPreferred | DefaultsPreferred | TimeLocal | LocationMedical | LocationConverted | LocationUser Status | StatusText | StatusSound | CapacityMessageCustomerPresentCustomerClassCustomerPage | <! ATTLIST Version NamesPresence NMTOKENS # REQUESTED <! ELEMENT Connected Device (EMPTY)> <! ATTLIST Device Connected NMTOKEN Class # IMPLIED ID PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED ELEMENT MobilityDevice (EMPTY)> <! ATTLIST MobilityDevice Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED Validity Period NMTOKEN # IMPLIEDID <KNOWLED Type <! IMPLIEDID! #INPLICIT CapacityMemory NMTOKEN #INPLICIT

Period Validity NMTOKEN # IMPLIED Device Name NMTOKEN # IMPLIED> <! ELEMENT USER Status (EMPTY)> <! ATTLIST StatusUser Class NMTOKEN # IMPLIED ID CapacityMemory NMTOKEN # IMPLIED #Implied Valve! ELEMENT ContactPreferred (EMPTY)> <! ATTLIST ContactPreferred Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED Validity Period NMTOKEN # IMPLIED> <! Defauts ELEMENTPreferred (EMPTY)> <! ATTLIST DefaultsPreferred Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED Period Validity NMTOKEN # IMPLIED> <! ELEMENT TimeLocal (EMPTY)> <! ATTLIST TimeLocal Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLICIT Capacity NMTOKEN # IMPLICITValidity NMTOKEN # IMPLICIT> <! ELEMENT LocationMeasurement (EMPTY) #! ATTLIUM IMPLIED #MENTISTYLE IMPLICIT NMTOKEN Period # IMPLICIT Accuracy NMTOKEN # IMPLIED> <! ELEMENT Converted Location (EMPTY)> <! ATTLIST LocalizationConverted NMTOKEN Class # IMPLIED CapacityMemory NMTOKEN # IMPLIED! Localizationrequired NMTOKEN Class # IMPLIED PUBIDLITERAL ID # IMPLIED Capacity NMTOKEN # IMPLICIT PeriodValidity NMTOKEN # IMPLIED> <! ELEMENT EnvironmentUser (EMPTY)> <! ATTLIST EnvironmentUser Class NMTOKEN # IMPLITIBLE IDENTIFIED Peripheral NMTOKEN # IMPLIED> <! ELEMENT StatusText (EMPTY)> <! ATTLIST StatusText Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED Capacity NMTOKEN # IMPLICIT Validity Period NMTOKEN # <! # Implicit Period Validity NMTOKEN # Implicit Typolmage NMTOKEN # IMPLICIT> <! ELEMENT StatusSom (EMPTY)> <! ATTLIST StatusSom Class NMTOKEN # IMPLICIT ID # IMPLIEDIUM IMPLIED CapacityMemory NMTOKEN # Implicit! EMPTY)> <! ATTLIST CapabilitiesMessage NMTOKEN Class # IMPLIED PUBIDLITERAL ID # IMPLIED Memory Capacity NMTOKEN # IMPLIED Validity Period NMTOKEN # IMPLIED> <! EMAIL EMPLOYEE (EMPTY) IDPLIENT # IMPLIED IMPLIED KNOWLEDGE NMTOKEN Validity # IMPLIED> <! ELEMENT CapacityCallVoice (EMPTY)> <! ATTLIST CapacityCallVoice Class NMTOKEN # IMPLICIT PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # Implied Validity IDCOMMEDIUMCOMEVOLIDED! # IMPLIED CapacityMemory NMTOKEN # IMPLIED Period Validity NMTOKEN # IMPLIED> <! ELEMENT ItemPresenceUser (EMPTY)> <! ATTLIST ItemPresenceUser Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED PeriodVALITY NMTOKEN # IMPLIED RefExt PUBIDLITERAL # IMPLIED Change <IMPLIED! ATTLIST ClientType Class NMTOKEN # IMPLIED ID PUBIDLITERAL # IMPLIED CapacidadeMemória NMTOKEN # IMPLIED Validity period NMTOKEN # IMPLIED> <! ItemPresençaCliente member (EMPTY)> <! ATTLIST ItemPresençaCliente Class NMTOKEN # IMPLIED PUBIDLITERAL ID ^ IMPLIED CapacidadeMemória NMTOKEN # IMPLIED PeriodoValidade NMTOKEN # IMPLIED TrocarConteúdo NMTOKEN # IMPLIED> <! ELEMENT PresenceExt (EMPTY)> <! ATTLIST PresenceExt Class NMTOKEN # IMPLIED PUBIDLITERAL ID # IMPLIED CapacityMemory NMTOKEN # IMPLIED PeriodVality NMTOKEN # IMPLIED ChangeContent NMTOKEN # IMPLIED> <! - - End of DTD - ->

It will be apparent to the technician that as technology advances, the inventive concept can be implemented in a number of different ways. Therefore, the invention and its embodiments are not limited to the above examples, but may vary within the scope and inventive concept of the appended claims.

Claims (31)

1. Mobile messaging system comprising at least one client device (402) and a server (404), wherein: the client device comprises a device (406) for transmitting presence information as presence attributes to the server and a device ( 410) for receiving presence attributes from the server, the information being categorized by a plurality of presence attribute types identified by the attribute name, and - the server comprises a device (414) for maintaining presence information based on the attributes of the attribute. features, the system is characterized by the fact that: - the client device comprises a device (416) for adding a qualifier to the presence attribute, the qualifier comprising one or more parameters specifying the use of the attribute, and - the client device comprises a device (428) for processing the received presence attribute according to the qualifier parameters in the received attribute. The system of claim 1, wherein: - the client device comprises a device for specifying in the qualifier the attribute display settings, and - the client device comprises a device for displaying the received attribute based on in the qualifier. The system of claim 1, wherein: - the client device comprises a device for specifying in the qualifier the application to which the attribute should be addressed, and - the client device comprises a device for addressing the attribute received for the application indicated by the qualifier. A system according to any one of claims 1 to 3, characterized in that: - the server comprises a device for determining based on the qualifier whether to send the attribute to one or more client devices. Mobile messaging system comprising at least one client device (502) and one server (504), wherein: - the client device comprises a device (506) for transmitting presence information as presence attributes to the server and a device (512) for receiving the presence attributes of the server, the presence information being categorized by a plurality of presence attribute types identified by the attribute name, and - the server comprises a device (510) for maintaining presence information based on in the presence attributes received, the system is CHARACTERIZED by the fact that: - the client device comprises a device (516) for composing the presence information attribute identified by a combination of the authorizer, the attribute name and the qualifier, the authorizer specifying the body responsible for maintaining the attribute and the qualifier specifying the use of the attribute, - the server comprises a device ( 520) to search for an already stored attribute containing the same received attribute identifiers and a device (528) to replace the already stored attribute with the received attribute if the combination of the received attribute identifiers is identical to that of the already stored attribute or otherwise adding the received attribute, and - the client device comprises a device (540) for searching for an already stored attribute containing the same identifiers as the received attribute and a device (542) for replacing the attribute already stored with the received attribute if the combination of the identifiers of the received attribute is identical to that of the attribute already stored or otherwise add the received attribute. Mobile messaging system according to any one of claims 1 to 5, characterized in that: - the presence attributes received from the client device by the server are stored in the database according to the editor user in association with the group. of presence. Mobile messaging system according to any one of claims 1 to 6, characterized in that: - each presence attribute is part of an item including an attribute name element and an attribute value. Mobile messaging according to claim 7, characterized in that: - the name element includes an authority string indicative of an authority responsible for maintaining the name element and attribute value unique. Mobile messaging system according to any one of claims 5 to 8, characterized in that: - the presence group comprises one or more presence attributes belonging to a single editor function of an editor user in association with a single presence group. Mobile messaging system according to claim 9, characterized in that: - the client device user as a publisher is able to use the client device or more than one client device in more than one editor role. Mobile client device 402 for the mobile messaging system comprising: a device 406 for transmitting presence information as presence attributes to the server, the information being categorized by a plurality of identified presence attribute types By the name of the attribute, the client device is characterized by the fact that it also comprises: - a device (416) for adding a qualifier to the presence attribute, the qualifier comprising one or more parameters specifying the use of the attribute. Mobile client device 402 for the mobile messaging system, the client device comprising a device 410 for receiving the server presence attributes, the information being categorized by a plurality of presence attribute types identified by the name of the server. attribute, the device is CHARACTERIZED by the fact that it also comprises: - a device (416) for adding a qualifier to the presence attribute, the qualifier comprising one or more parameters specifying the use of the attribute, and - a device (428) for processing the presence attribute received according to the qualifier parameters in the received attribute. Mobile client device (502) for the mobile messaging system, comprising a device (506) for transmitting presence information as presence attributes to the server, and - a device (512) for receiving the presence attributes from the server. , the presence information being categorized by a plurality of presence attribute types identified by the attribute name, the client device is characterized by the fact that it also comprises: - a device (516) for composing the presence information attribute identified by a combination of the authorizer, the attribute name and qualifier, the authorizer specifying the body responsible for maintaining the attribute and the qualifier specifying the use of the attribute, a device (540) to search for an already stored attribute containing the same attribute identifiers - a device (542) for replacing the attribute already stored with the attribute received if the combination that of the received attribute identifiers is identical to that of the attribute already stored or otherwise adding the received attribute. Mobile client device according to any one of claims 11 to 13, characterized in that: - each presence attribute is part of an item including an attribute name element and an attribute value. Mobile client device according to claim 14, characterized in that: - the name element includes an authority string indicative of an authority responsible for keeping the name element and attribute value unique. Mobile client device according to any one of claims 11 to 15, characterized in that: - the presence group comprises one or more presence attributes belonging to a single editor function of an editor user in association with a single presence group. Mobile client device according to claim 16, is characterized in that: - the client device user as a publisher is able to use the client device or more than one client device in more than one editor role. 18. Server (504) for the mobile messaging system comprising a device (510) for maintaining presence information based on received presence attributes, the presence information being categorized by a plurality of presence attribute types identified by the name of the user. The server is characterized by the fact that it also comprises: - a device (520) to search for an already stored attribute containing the same identifiers as the received attribute, and - a device (528) to replace the attribute already stored with the attribute. received if the combination of the received attribute identifiers is identical to that of the attribute already stored or otherwise adds the received attribute. Server according to claim 18, characterized in that: - Presence attributes received from the client device by the server are stored in the database according to the publisher user in association with the presence group. Server according to claim 18 or 19, characterized in that: - each presence attribute is part of an item including an element of the attribute name and an attribute value. A server according to claim 20, wherein: - the name element includes an authority string indicative of an authority responsible for maintaining the name element and attribute value unique. Server according to any one of claims 18 to 21, characterized in that: - the presence group comprises one or more presence attributes belonging to a single editor function of an editor user in association with a single group of presence. Server according to claim 22, characterized in that: - the client device user in communication with the server acting as an editor is capable of using the client device or more than one client device in more than one role of the client. editor. 24. Presence system, characterized in that it comprises: - at least one physical device (632, 634) having at least one presence client (602, 604, 606) to enable the presence user (608, 610, 612 ) interacting with the system as a publisher or subscriber; and - a server (628, 630) for maintaining the valid presence group values (714) of an editor's attributes (734) for access by subscribers according to the associated presence groups (718). Presence system according to claim 24, characterized in that: - each presence attribute is part of an item including an attribute name element and an attribute value. Presence system according to claim 25, characterized in that: - the name element includes a qualifier having information related to the use of the attribute. Presence system according to claim 26, characterized in that: - the name element includes an authority string indicative of an authority responsible for keeping the name element and attribute value unique. Presence system according to any one of claims 24 to 27, characterized in that: - the presence group comprises one or more presence attributes belonging to a single editor function of an editor user in association with a single presence. presence group. Presence system according to claim 28, characterized in that: - the user who interacts with the system as a publisher is able to use the presence client or more than one client device in more than one editor role. . Presence system according to claim 28, characterized in that: - each presence attribute is part of an item including an element of the attribute name and an attribute value. Presence system according to claims 24 to 30, characterized in that at least one physical device is a mobile physical device.