Mobile instant messaging and presence service

DESCRIPTION

MOBILE INSTANT EXCHANGE SERVICE AND

PRESENCE

Background of the invention

The present invention relates to messaging systems in mobile telecommunications systems and more particularly to presence attributes in a mobile instant messaging and presence service.

An instant messaging service provides end users with primarily fast, interactive text-based media. The usefulness of instant messaging is greatly enhanced by the addition of a service that will keep track of Online status and availability of your chat partners or friends, as well as notify you of changes in your status or availability. This type of service is called presence service. In general, presence may be considered to contain various dynamic information about a user or client connected to the instant messaging service via various means. Examples of this information are contactability, availability and user location for communication. The combination of instant messaging and presence services is called presence and instant messaging (IMPS). This type of service has been available to wired Internet users, but the interconnectivity between wired users and mobile users has been lacking.

The Village Wireless initiative was established to define specifications for presence and instant messaging service. Wireless Village Instant Messaging and Presence Service (IMPS) includes four key features: presence, instant messaging, groups, and shared content. 0 Shared content allows users and operators to establish their own storage area where they can place photos, 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 users and operators to create and manage groups. Presence is the key technology that enables the Wireless Village initiative. In the existing Internet-based instant messaging service, presence values ​​are usually very simple, such as the user is active, absent, does not want to communicate, etc. These values ​​are selected from predefined value sets. A White Paper on the Mobile Village Wireless IMPS Solution: Wireless Village, The Mobile IMPS Initiative: White Paper, April 26, 2001. The existing mobile terminal can be considered a personal tool that reflects personal state more accurately than a personal computer. Given 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 enable easy use and addition of new types of presence information.

WO 00/70807 discloses a client server architecture that allows a user to edit notes associated with internet locations, such as while viewing web pages. When another user is searching a web page, the URL is extracted and can be transmitted to the requesting user notes associated with the URL. Notes can be classified as relevant to particular user interest groups, and a filter can be applied to deliver only notes that match the preferences of a requesting user. You can also edit private notes for specific recipients who may have access to the notes.

WO 00/51391 discloses a system in which information and supplementary information about the state of a second mobile station, such as the location state and the telephone state, can be stored in a network and delivered to a first mobile station which is looking for the second mobile station.

Disclosure of the Invention

An object of the invention is to provide improved organization of use and selective editing of presence attributes to customers. The invention is characterized by what is defined in the characterizing parts of the independent claims.

Brief Description of the Drawings

The invention will be described in more detail below by preferred embodiments and with reference to the accompanying drawings, in which:

Figure 1 is a block diagram illustrating an IMPS mobile system;

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

Figure 3 is a signaling diagram illustrating the use of a qualifier;

Fig. 4 shows an embodiment of a mobile messaging system comprising at least one client device and a server according to the present invention;

Fig. 5 shows another embodiment of a mobile messaging system comprising at least one client device and a 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 unsigned presence flow diagrams according to the present invention;

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

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

Best Mode for Carrying Out the Invention

Figure 1 illustrates a mobile IMPS system. A number of mobile clients (MC) may be connected via an MNW mobile network and possibly one or more ONW intermediate networks to an IMPS S server. The Internet is typically used as the intermediate network, and also non-mobile C clients may be served by the IMPS system. For presence services the IMPS S server can be functionally divided into server elements: A PS publisher server that is the base service element for a publisher client that has presence information and an SS subscriber server that is the basis for a subscriber or ordering customer. Thus, the MC client is served by both servers: MC updates its presence information to the PS and acts as a publisher client and, on the other hand, requests and receives presence information related to other clients, such as client attributes. presence of SS subscriber server. The PS server maintains presence data and manages its distribution based on users' editing preferences related to presence information. The SS and PS functions may be performed on a physical server device or may be distributed across a plurality of server devices.

It should be noted that the present description focuses on the capabilities related to presence service. Other important capabilities of the IMPS mobile service are message exchange capabilities, user group management capabilities, content management capabilities, subscriber management capabilities, and customer capabilities. Mobile IMPS services are created using these service capabilities. For example, an MC client may belong to several user groups and server S manages group members, handles immediate messaging, and distributes presence information among 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 distributed to members of a Friends group, members of a Coworkers group, or publicly to any client.

Various transport layer protocols may be used and the IP protocol is typically used to provide a network layer service. Different lower layer transmission protocols may be used. The MNW mobile network can be any wireless network such as a cellular network that supports GSM service, a network that also supports General Packet Radio Service (GPRS), a third generation, such as a Universal Mobile Telecommunications Service (UMTS) network, a WLAN wireless local area network, or a private network. Infrared or short-range radio connections such as Bluetooth communication can also be used.^MR, as a part of the communications path between the MC and the S server. The MC mobile client device can be, for example, a mobile station, a BDA device or a portable computer.

<td>comprising or</td><td>what</td><td>it's on</td><td>to a modem</td><td>wireless .</td><td>At</td>

<td>mobile messaging</td><td>IMPS</td><td>can be</td><td>transferred</td><td>using</td><td>an</td>

<td>data call</td><td>in</td><td colspan="2">switched circuit one</td><td>context</td><td>in</td>

<td colspan="2">data transmission</td><td>in circuit</td><td>switched,</td><td>services</td><td>in</td>

message exchange such as SMS or Multimedia Messaging Service (MMS)

Multimedia), for example. Figure 2 illustrates the use of presence attributes. When mobile client MC has determined 201 one or more presence attributes to be edited, it updates 202 presence attributes to the publisher server PS, that is, edits one or more presence attributes. Presence 201 determination can be made when the client is establishing a mobile IMPS logical session with the mobile IMPS server or automatically or on the initiative of a server when some presence information has changed. For example, phase 201 may be initiated automatically at a predetermined time, by data, or by a user profile change in mobile client MC. When an MC client (A) accesses IMPS mobile services from an SS server, it may request presence information from another client (B). Subscriber server SS requests this information from publisher server PS (client A) 204. The PS sends 205 one or more presence attributes to SS, if this is allowed by (client B) editing preferences. Client B's editing preference set may prevent some of the requested information from being sent (to client A or in general). The SS can also automatically request 204 presence information on the basis of (A) user preferences when the client establishes a logical connection with SS services. SS sends 206 presence attributes to receiving client MC (A).

The SS subscriber server (and the PS edition server) typically sends the client originated, unmodified presence attributes to the client. However, there may be a content adaptation mechanism implemented on the PS server. Content adaptation addresses the issue of modifying a presence attribute in a way that matches the client potential of the receiving client. In addition to transmitting presence information as a response to a customer request, it is also possible to push presence information to available MC clients (who are logically connected to the service) according to editing preferences. Push type presence notification can be triggered by 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 specific implementation internal triggers that update the value.

Client MC is thus configured to update one or more presence attributes to the PS, to receive and handle presence attributes received from the SS and to present presence information obtained from at least one presence attribute to the server. Preferably, the MC stores presence information (presence attribute values) until new presence attribute values ​​are received in an update message used to carry presence attributes (or the client terminates the IMPS mobile session). In addition, as will be illustrated in more detail below, the client device may automatically use received presence information to adjust its function accordingly. In addition to the flags shown in figure 2, authorization may be requested by the presence information editor before sending presence attributes to a requesting customer. Figure 2 does not show any status messages through which the server can respond, for example after message 202.

A presence attribute originating from a customer is one that has its value field filled in by the customer you are editing. A presence attribute that originates from a server is one that has its value field populated by the publisher server. A presence attribute originates on a 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 set of attributes. Presence attributes can be divided into the following classes:

- Client Status: Presence attributes that describe the availability of the client device for communication; network access, GPRS coupled, on / off status, operator, for example. Thus, the attributes in IMPS mobile service are very different from those of IMPS used for non-mobile client devices.

- User Status: Presence attributes that describe the user's availability for communication; ready, in meeting, busy, away, on the phone, in conversation, don't disturb, for example.

- Local information: Presence attributes that describe the user's local environment: local time, noise / quiet environment, inside, outside, user location, in terms of, for example, geographic location, visited MIPN, street / city , facilities, for example. For example, the exact location of the mobile client can be obtained directly for the local information attribute and the availability status (in a meeting, summer cottage, etc.) may be readily available via the mobile client user profile setup. MC

- Personal Status: Various personal attributes that describe the personal user's status; disposition, interests and personal intentions, for example.

Client Capabilities: Presence attributes that describe the capabilities of the client device to support different media, different media types, and different characteristics.

User Attributes: Presence attributes that allow the client device or user to define their own textual presence references and references to external values.

- Extended Presence Information: The vendor or specific service provider dynamically defines non-standard presence attributes, which, however, must be passed through standard presence servers.

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

GENERAL STRUCTURE AND IDENTIFICATION OF PRESENCE ATTRIBUTES

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

<td>Information Element</td><td>Req</td><td>Type</td><td>description</td>

<td>NameSpec</td><td>M</td><td>XML</td><td>Attribute Identity Information</td>

<td>Value</td><td>M</td><td>XML</td><td>Value for attribute</td>

Table 1. Presence Attribute Structure

The subelements of the NameSpec element (Specify Name) are described in Table 2.

<td>NameSpec</td><td>Req</td><td>Type</td><td>description</td>

<td>Name</td><td>M</td><td>Chain of characters</td><td>Attribute Name</td>

<td>Quali file</td><td> 0</td><td>Chain of characters</td><td>Information related to attribute scope usage</td>

<td>Authority</td><td>Ç</td><td>Chain of characters</td><td>The authority responsible for the NameSpec attribute and Walloon field names being unique.</td>

Table 2. The NameSpec element attribute name is a string given by the information element 'Name'. 0 information element

Name is defined for all presence attributes in the format defined in Table 3.

<td>Information Element</td><td>Name</td>

<td>Data Type</td><td>String</td>

<td>Format</td><td>Free text format</td>

<td>description</td><td>Name of an attribute of presence</td>

Table 3. The format element name of the Qualifier element is illustrated in Table 4.

<td>Information Element</td><td>Qualifier</td>

<td>Data Type</td><td>String</td>

<td>Format</td><td>Free text format</td>

<td>description</td><td>Modify Attribute Scope</td>

Table 4. The Qualifier element Qualifier element is used to specify the scope of attribute use. The qualifier can be used especially for two purposes: to add a new attribute or to allow the sender of the presence information (publisher) to specify how the presence information should 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 knowledge of their exact location (eg street address) to only a few users (call it group A) and give it a closer location (eg just a city name) ) to others (call it group Β), you can edit a location attribute with the city name in group B. For group A you attach a Qualifier (say My Best Friends) to the location attribute. This effectively creates a new attribute with the My Best Friends Qualifier. Then add the street address to this new attribute and edit it for group A. Because these attributes are different, the PS server can keep their values ​​separate. Also if a person belongs to both groups A and Β, that person's client device can be configured to distinguish between these two attributes. 0 Client device can be configured to display (and possibly use) the attribute according to the group that the user has enabled. Possible Qualifier values ​​can be pre-assigned by the customer and service provider or can be dynamically assigned by the user (publisher). A service provider may also limit the number of dynamically assigned Qualifier values.

authority element determines the entity that is responsible for keeping the attribute and its content unique. This concerns the attribute extension mechanism.

<td>Information Element</td><td>Authority</td>

<td>Data Type</td><td>String</td>

<td>Format</td><td>URL</td>

<td>description</td><td>Identifies the entity responsible for the unique character of the attribute.</td>

Table 5. 0 authority element

When using unmodified default presence attributes, the Authority string may be omitted. Using a Qualifier string is not a modification of the attribute that requires the use of the Authority element. It must be used when entering a new attribute (a new Name) or when 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 maintaining this new attribute.

Usually a Value field name must be unique in an attribute. Thus, the introduction of a new value field for an existing attribute must be handled by the rules by the entity that defined the attribute. Adding a new value field makes the old attribute a new one. This must be signaled by the presence of the Authority field to allow the old and new attributes to coexist. It is also possible for an interested party to release an attribute for public maintenance. This type of attribute is registered by an appropriate authority, such as the Internet Assigned 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 (PS, SS) does not remove a value field from an attribute even if it does not understand the semantics of the value field. Client MC ignores all value fields in the attribute it does not understand.

An attribute is identified and made unique by the NameSpec element. Figure 3 shows an example of using the NameSpec element and qualifier. A qualifier is given 301 for an attribute on the MCI client device. It is possible for the user to determine the qualifier or the MC client device to determine it. The qualifier can be defined to specify the desired user group, to determine how to present the presence information on a client receiving device (MC2), or to specify otherwise how the receiving client device MC2 should use the attribute. . You can use MC mobile client user profiles when determining the qualifier. For example, MCI composes the presence attribute on the basis of the current profile (for example, in a meeting), calendar entries (the meeting ends at 12.00), and local time. Using the qualifier, the presence attribute can easily be modified to include a large amount of useful information for the MC2 receiving client. The attribute is sent 302 to the PS server.

PS compares 303 the NameSpec element of the received attribute with the attributes already stored. PS first compares the Authority strings with each other. An attribute that does not contain an Authority string is unlike any other attribute that has an Authority string. The following attribute names are compared. Finally the Qualifier strings are compared. An attribute that does not contain a Qualifier string is different from any attribute that has a 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 PS edit server performs this comparison to determine if the received attribute value fields should overwrite any existing presence information, or if the attribute is a new attribute to be added to the MC2 presence information store. On the basis of the comparison, the PS stores 303 information in the received attribute. The PS replaces the previous presence information of an already stored attribute with the presence information of said received attribute in case all identifiers of said received attribute are the same as those of the already stored attribute. Otherwise PS adds the presence information of said received attribute without overwriting any preceding information. 0 PS sends 304 the attribute at least to an MC2 client device (either pushes it automatically, or as a response to an MC2 request). According to one embodiment, the qualifier determines a group to which the attribute is directed. In addition, the qualifier may be used to present presence information in different ways to private contacts and public contacts in a telephone directory, for example. Thus the PS can determine the receiving client devices on the qualifier basis. The potentials of the service for a dynamic telephone directory service will be described later, after first describing more fully the following, customer state attributes, user state attributes, and personal state attributes.

Also the receiving client MC2 decides, after a similar comparison 305, as in PS, whether and how to store received presence attribute information. This type of ternary presence attribute identification allows for very flexible use, administration and creation of presence attributes.

There are many ways to use the qualifier to specify attribute usage on the MC2 client device. Typically the client device MC is capable of supporting a plurality of applications. According to a first embodiment, the MCI client device adds a qualifier that specifies an application to use. 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 that used to process attribute presence information on the MCI client device or in another application. The receiving client device MC2 addresses 305 the attribute received to the application indicated by the qualifier. For example, 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 conform the attributes exactly to the needs of the application.

According to a second embodiment, the MCI client device adds a qualifier that specifies the presentation of the attribute. The receiving client device MC2 has 305 the attribute received on the qualifier basis. The qualifier can determine, for example, whether or not the information is shown to the server, or what parts of the information are shown. The qualifier can also determine various user interface settings, such as colors, fonts, etc. Thus, the MC2 UI is configured 305 on the basis of qualifier settings.

CUSTOMER STATUS ATTRIBUTES

According to a preferred embodiment, MC mobile clients use a presence attribute that describes the current transmission capabilities of an MC mobile client. A structure for this type of attribute is illustrated in Table 6. This attribute, designated as a Modem attribute, gives presence information on user terminal parts or functions that are handling mobile device carriers.

<td>Information Element</td><td>Req</td><td>Type</td><td>Value</td><td>description</td>

<td>NameSpec.Name</td><td>M</td><td>Chain of characters</td><td>Modem</td><td>Name of attribute</td>

<td>Value</td><td>M</td><td>XML</td><td>See table 7 below</td><td>Value for the attribute. 0 type is the structure</td>

Table 6. Modem Attribute Structure

<td>Value.Modem</td><td>Req</td><td>Simple/ Multiple</td><td>description</td>

<td>state</td><td>M</td><td>s</td><td>Value Field Name</td>

<td>CommAddr</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>CS_Status</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>PS_Status</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>Roaming Status</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>CS_CallStatus</td><td> 0</td><td>M</td><td>Value Field Name</td>

<td>PDP ContexStat US</td><td> 0</td><td>M</td><td>Value Field Name</td>

Table 7. Modem Attribute Value Fields State value field, as illustrated in table 8, indicates the state of the mobile modem.

<td>Information Element</td><td>state</td>

<td>Data Type</td><td>Enumerated string</td>

<td>Format</td><td>Following values: ON - The modem portion of the terminal is on. OFF - Modem part of terminal is off or out of coverage DIS - Value fields (if any) given by this attribute are invalid. All value fields obtained from previous updates are invalid.</td>

<td>description</td><td>Modem Attribute Status Field</td>

<td>gamma</td><td>ON | OFF | DIS</td>

Table 8. Modem Status Value Field Status value field indicates whether the modem is on or off. According to a preferred embodiment, a presence attribute includes a DIS indication, preferably in the mandatory attribute state value field. When DIS is defined in an attribute, all values ​​given in the attribute are invalid. The receiving mobile client MC can thus ignore the attribute value fields. The previous values ​​of the presence attribute are also removed (and overridden). Thus it is practical to send an attribute with DIS indication but no other value fields. This type of attribute requires very little space and thus the critical bandwidth over the radio interface can be saved. This is very useful especially with attributes that describe user attributes.

Referring back to Table 7, the Modem Attribute CommAddr value field includes the Modem Communication Address (MC). It has two parts: the media and the contact address. The media portion carries information about the supported communication methods, especially if the modem supports packet-switched data (PS), circuit-switched data (CS), data or voice, SMS or MMS. The contact part includes the address, for example an MSISDN number.

CS_Status value field indicates the state of the modem circuit switched (registered or unregistered). The PS_Status value field indicates the state of the modem's switched packet (connected or not connected). The RoamingStatus value field indicates the domestic PLMN (Public Land Mobile Network) and possibly the PLMN where the modem is currently roaming (roaming). 0 CS_CallStatus value field gives the current call status of a CS bearer (data or voice; active or not active). The modem attribute may have a list of these call states in progress if the muting capability is supported by the modem. The PDP Context Status value field includes Packet Data Protocol (PDP) context information, such as Quality of Service (QoS) information.

In addition to the above examples, the modem value field may be used to carry other information related to mobile client transmission capabilities. In a first example a maximum mobile client bit rate is delivered in the Mode attribute. The receiving client device may then set its transmission rate so as not to exceed the maximum bit rate. In a second example the client device determines that only switched packet transmission mode should be used when sending data files to the client device. A third example is that a roaming device states that only certain communication is allowed (for example, only voice calls are allowed and data files will not be sent).

USER STATUS ATTRIBUTES

According to a preferred embodiment, an attribute is defined for the user's desire to perform an activity. Activity is specified by the value fields that belong to this Availability attribute. Table 9 illustrates the structure for the Availability attribute.

<td>Information Element</td><td>Req</td><td>Type</td><td>Value</td><td>description</td>

<td>NameSpec.Name</td><td>M</td><td>Chain of characters</td><td>Availability</td><td>Name of attribute</td>

<td>Value</td><td>M</td><td>XML</td><td>See table 10 below.</td><td>Value for the attribute.</td>

Table 9. Availability attribute structure

Table 10 describes the Availability Attribute value fields.

<td>Value Availability / E tension</td><td>Req</td><td>Simple/ Multiple</td><td>description</td>

<td>Status</td><td>M</td><td>s</td><td>Value Field Name</td>

<td>CommAvail</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>PhoneAvail</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>SMSAvail</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>MMSAavil</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>IMAvail</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>EmailAvail</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>Image</td><td> 0</td><td>M</td><td>Value Field Name</td>

<td>Text</td><td> 0</td><td>M</td><td>Value Field Name</td>

Table 10. Availability attribute structure

The state value field as illustrated in Table

11, indicates the status of the availability information.

<td>Information Element</td><td>state</td>

<td>Kind of Dice</td><td>An enumerated string</td>

<td>Format</td><td>One of the following values: ENA - The value fields included in this attribute contain updated information. Previously updated value fields not included in this attribute are still updated DIS - The value fields (if any) included in this attribute contain invalid information. Previously updated value fields are invalid.</td>

<td>description</td><td>Defines the edit state of the attribute. availability</td>

<td>gamma</td><td>ENA | DIS</td>

Table 11. State field State value field indicates whether or not availability information editing is enabled. DIS can be used as described above to invalidate Availability attribute values. For example, the PS server may send an availability attribute with indication DIS after the mobile client MC has closed the IMPS mobile session. This type of message can also be sent when a client connection is suddenly lost. Thus, the receiving client mobile can remove all availability information related to the user and client device that is no longer present in the IMPS mobile system.

CommAvail value field in Table 10 indicates whether the user is wanting to access some form of remote communication. The PhoneAvail value field indicates whether the user wants to access a phone call. The SMSAvail value field indicates whether the user wants to access an SMS exchange. The MMSAvail value field indicates whether the user wants to access a multimedia messaging service (MMS) exchange. The IMAvail value field indicates whether the user wants to access an instant messaging (IM) exchange. The EmailAvail value field indicates whether the user wants to access an EMAIL exchange.

The structure for the Image value field is illustrated in Table 12.

<td>Image</td><td>Req</td><td>description</td>

<td>Containedlmage</td><td>Ç</td><td>An image included in the attribute in coded transfer form</td>

<td>Referredlmage</td><td>Ç</td><td>A URL to the image.</td>

<td>Value field</td><td>M</td><td>0 name of any Value Field in this attribute except Status, Image, or Text</td>

Table 12. Image value field associates an image with any of the value fields in the Availability attribute except the Status, Text, or Image field. The Containedlmage value field includes the image, however the image size or format may be limited. The Referredlmage value field includes a resource URL that has the associated image. The ValueField value field defines the value field of the image to which it is associated. For example, the publisher may associate an image with the PhoneAvail value field that currently has the value 'DISC' (meaning that the user is limited to telephony, for example) to carry graphic semantic information about the meaning of DISC. The image value field can have multiple instances in this attribute. Whenever 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 value field is updated or invalidated, any old association with this attribute must be discarded by the receiving client.

The structure of the Text value field is illustrated in Table 13.

<td>Text</td><td>Req</td><td>description</td>

<td>ContainedText</td><td>M</td><td>A text string</td>

<td>ValueField</td><td>M</td><td>0 name of any Value Field in this attribute except Status, Image, or Text</td>

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

PERSONAL STATE ATTRIBUTES

The PersonalStatus attribute indicates the personal state of the editor. The options and details are specified by the value fields belonging to this attribute. Table 14 illustrates the attribute structure for PersonalStatus.

<td>Element of Information</td><td>Req</td><td>Value</td><td>description</td>

<td>NameSpec.Name</td><td>String</td><td>state Folks</td><td>Attribute Name</td>

<td>Value</td><td>M</td><td>XML</td><td>Attribute Value</td>

Table 14.PersonalStatus attribute structure

Table 15 illustrates the value fields of the PersonalStatus attribute.

<td>PersonalStatus .Value</td><td>Req</td><td>Simple/ Multiple</td><td>description</td>

<td>state</td><td>M</td><td>s</td><td>Value Field Name</td>

<td>Text</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>disposition</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>Time</td><td> 0</td><td>s</td><td>Value Field Name</td>

<td>Image</td><td> 0</td><td>M</td><td>Value Field Name</td>

Table 15. PersonalStatus attribute values ​​state value field, as illustrated in Table 16, indicates the state of the PersonalStatus information.

<td>Information Element</td><td>state</td>

<td>Data Type</td><td>An enumerated string</td>

<td>Format</td><td>One of the following values: ENA - The value fields included in this attribute contain updated information. Previously updated value fields not included in this attribute are still updated DIS - The value fields (if any) included in this attribute contain invalid information. Previously updated value fields are invalid.</td>

<td>description</td><td>Sets edit state of location attribute</td>

<td>gamma</td><td>ENA | DIS</td>

Table 16. PersonalStatus attribute state

This field indicates whether editing of this information is enabled or not. DIS can also be used with the PersonalStatus attribute.

Text value field indicates the state of the free-text editor. The Array value field indicates the arrangement of the editor. The Time value field gives the publisher's local time.

According to a preferred embodiment, an image in the PersonalStatus attribute may also be used. As already illustrated in Table 12, the Image value field associates an image with any of the value fields of this attribute, except in the State or Image field. For example, the editor may associate an image with the Array value field which currently has the value ΊΝ LOVE 'to carry graphic semantic information about the meaning of IN_LOVE. 0 Image value field can be used in a similar way to that already illustrated with the Availability attribute.

The present invention may be implemented on existing client devices and servers. They all have processors and memory with which the functionally described invention can be implemented. A computer program may be loaded from internal or external memory to the client device server processor, providing, when executed on the processor, the means for implementing inventive functionality. A hardmre implementation or a combination of software and hardware can also be used.

Fig. 4 shows a client device 402 in communication with a server 404 according to the present invention. The client device may be similar to one or more of the mobile clients or non-mobile clients of FIG. 1 or any other mobile clients shown in FIGS. 2 and 3. Similarly, server 404 may be similar to the server shown in FIG. 1 or any of the other servers shown in figures 2 and 3. Client device 402 includes means 406 for transmitting or requesting presence information, such as presence attributes, to the server on a signal line 408. Transmitting presence information would correspond, for example, to step 302 of Fig. 3, in which presence attributes are sent from MCI to PS, or to step 202 of Fig. 2, where presence attributes are updated by the MC and sent to the PS. Requesting presence information on line 408 would be comparable to requesting step 233 of FIG. 2 where the MC requests a presence attribute from the SS. The transmission on line 408 from client device 402 to server 404 could be similar to the transmission path shown in Figure 1 from a mobile client (MC) through a mobile network (MNW) via an ONW intermediate network to ) IMPS server (s). Or, it could be similar to the non-mobile client C path through the ONW intermediate network to the S server. Of course other possible paths are contemplated, just as the invention does not depend on the physical media path or combination of physical media used. . Client device 402 also includes means 410 for receiving presence attributes from server 402 on a signal line 412. This presence information is categorized by a plurality of presence attribute types identified by the attribute name.

Server 404 includes means 414 for receiving / transmitting attributes and for maintaining presence information based on the received presence attributes.

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

To handle presence attributes on line 412 coming from server 404, client device 402 will also include means 428 for processing a presence attribute received on line 412 from server 404, according to qualifier parameters on the server. attribute received. The presence attribute received on line 412 may be received by means 410 and provided on a line 430 to means 428 for processing the received attribute. After processing, means 428 may provide a signal on a line 432 for application 424 for further use by the application.

Means for adding a qualifier 416 may include means 434 for specifying presentation definitions in the qualifier. such as displaying the attribute, so that the client receiving the attribute from server 404 may also display the attribute on the basis of the

Accordingly, a client device, client device 402 of Fig. 4, will include means 436 for displaying attributes received on the basis of such a qualifier specified by another client device and received from server 404 on line 412.

Likewise, means 416 may include means 438 for specifying in the qualifier to be sent to server 404 an application to which the attribute is to be addressed at the receiving client. For such a client device 402, which receives a qualifier specifying the application to which the attribute is to be addressed, will have means 440 for interpreting that attribute received on line 430 to address an attribute received to the application indicated by the qualifier.

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

It may be that a presence attribute intended for a particular client may not match the client's capabilities according to the known information of the server. Such information may be provided, for example, by means 444 on a line 450, means 452 for modifying the presence attribute to match the capabilities of the client. The modified attribute may be provided back to means 444 at line 450. On the other hand, where presence attributes are provided according to a push technology, the modified presence attribute may be provided on line 454 for means 456, which are able to take the necessary measures to push the presence attribute. presence modified for the customer or for more than one customer, if appropriate. This can be signaled, for example, at line 458 for means 444.

It will be appreciated that the function blocks shown in Figure 4 may be made using different types of hardware, specialized integrated circuits, microcontrollers, software, microprograms, etc., as will be apparent to those skilled in the art. Primarily, the functions assigned to distinct function blocks in the figure do not have to be separated, but can be incorporated into other blocks by freely adding or subtracting functions in or from the function blocks. Likewise, the cooperative relationship between the functional blocks can be modified in their order and interrelationship while at the same time achieving the same end results mentioned above. It will also be appreciated that the details of the client device and server device shown in figure 4 may take other forms which are similar to those shown in accordance with the invention. Other aspects of the invention may be illustrated in a similar manner, but never in an identical manner.

For example, Figure 5 shows a client device 502 communicating with a server device 504 with means 506 similar to the means 420 of Figure 4, for transmitting presence information, such as presence attributes on line 508, to means 510 for receiving and maintain presence attributes on server 504, similar to means 414 on server 404 of FIG. 4. Likewise, client device 502 may include means 512 for receiving presence attributes indicating presence information on a line 514 from server means 510 of server 504. As with means 420 and 416 of client device 402 of FIG. 4, client device 502 of FIG. 5 may include means 516 for composing a presence information attribute identified by a composition of an authorizer, an attribute name and a qualifier, where the authorizer specifies an entity responsible for maintaining the attribute and the qualifier that specifies the use of the attribute. The attribute thus composed may be provided on a line 518 for means 506 for transmission on line 508 to server 504, as shown. Server 504 may include means 520 responsive to the received attribute thus composed on a line 522 from means 510 to look for already stored attributes containing the same combination of authorization, attribute name and qualifier. If the combination of identifiers of the received attribute is identical to that of the attribute already stored, for example stored on storage media 524, the received attribute is used to replace the attribute already stored on a signal line 526. Thus, if the parameters of attribute have changed, the updated parameters will be stored on storage media 524. Otherwise, the received attribute is added to the storage media as a new attribute. This function may be performed on means 520 as described above or may be carried out on completely separate media 528 which receive the attribute received on a line 530 from means 520 and includes functions for replacing the attributes already provided. stored with the received attributes, if the combination of identifiers is the same and, if not, add the received attribute on a connection line 532 between itself and the storage media 524.

Client device 502 will include similar functionality as just described above, for example by means 540 that receives input attributes on line 542 from means 512, and looks for already stored attributes that contain identifiers that received attribute, and means 542 to replace the already stored attribute with the received attribute if the received attribute identifier combination is identical to the already stored attribute. Otherwise, the received attribute is added to storage means 544. Search means 540 may itself include means 542, or may be separated as illustrated in the figure. In the latter case, a signal line 546 provides attribute information regarding the attribute received from means 540 to means 542. The storage means 544 may be in two-way communication over line 548 with means 542 for replacing or adding attributes and line 550 with means 540 for searching already stored attributes.

As mentioned above, service capabilities for a dynamic phone book service embodiment of the present invention will now be described. A dynamic phone book service can be viewed as a rich calling service. It is useful before the call to enrich cases where part B presence information is shown 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 above, ie (1) client availability, (2) user availability, (3) local conditions, (4) personal status, (5) client capabilities , (6) user attributes, and (7) extended presence service.

Conceptually, the Presence System consists of 602, 604, 606 Presence Clients, 608 Presence Users, 610, 612, Presence User Functions 614, 616, 618, 620, 622, 624, 626 Presence Proxies, and Servers

<td>Presence</td><td>628, 630, such</td><td>as shown</td><td>at</td><td>figure 6.</td><td>a</td>

<td>Customer of</td><td>Presence is the</td><td>software or</td><td>O</td><td>program</td><td>what</td>

<td>enables</td><td>an interaction</td><td>of the user</td><td>with</td><td>the system</td><td>in</td>

Presence. You are a person who interacts with the Presence System using the Presence Client. A physical device 632, 634, for example a mobile portable device or a PC, may have a 606, or in special cases, multiple presence client instances 602, 604. A presence client belongs to a single user. A user may have more than one customer, but then these customers are typically different devices.

The users 608, 610, 612 are conceptually classified into Publishers and Subscribers. An editor is what originates the presence information. A subscriber is the recipient of presence information. A user may be both publisher of their own presence information and subscriber of some other publisher presence information. A user can have one or more Roles. An editor function is associated with a set of presence values ​​called a Presence Set. The presence values ​​of two different presence sets of the same user are independent of each other and are associated with different functions. A subscriber function is the logical presence information receiver of an identical editor function, that is, of the same presence set.

A 626 Presence Proy is an optimal network element that improves Presence Service scalability. A proxy temporarily stores presence values ​​from different presence sets that travel upward from the publisher to the server, or downward from the server to a subscriber. When a client arrives online the proxy can update the client with current presence information. Similarly, when a publisher sends a new presence value to the server, the proxy can update all subscriber clients that are registered with the proxy. A proxy can cache 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 taking place via the same proxy. If the proxy is unaware of the subscriber group associated with the presence set, then the proxy may request this information from the server.

A presence server 628, 630 is a network element that holds valid presence information and values ​​in groups that are associated with each presence set. The server communicates with presence clients either directly or through a proxy. The server informs the proxy about the validity period of the presence values ​​cached by the proxy. When the validity period expires, the proxy must discard the values ​​or update them from the server. The server assigns the presence of validity periods, item by item, monitoring how often the presence values ​​change. The validity period is dynamic, that is, it may change during the lifetime of the presence item.

A presence server also exchanges presence information with other presence servers, as illustrated in Figure 6. For example, if publisher and subscriber belong administratively to different presence servers, then the presence information must pass through both servers. . In case the servers are incompatible, there must be a gateway function (gateway) on both servers.

Figure 7 shows the structure of presence database 702 according to the invention. A single presence item 704 has three properties: name 708, attributes 710, and value 712. A presence set 714 consists of one or more presence items. The presence set 714 belongs to a unique user function 716. There can be no more than one presence set for a single role. Additionally, there is a single authorization group 718, which belongs to a single role 716. The authorization group consists of members who have the right to sign all or part of the presence set for the same role.

Items 704, 720, ..., 722 in a presence set are unique, that is, they can be distinguished from each other. Items are mainly distinguished from each other by their name. If the presence set contains two or more items with the same name, then there must be an attribute on each item that carries the identities of these items. Members 724, 726, ..., 728 of a group 718 are unique. Different presence sets in different functions 716, 730, ..., 732, from the same editor 734, can contain items with the same name or the same identity. Different groups may also contain the same members.

A 716 role can be identified by a Role Identity, Group Identity, or Presence Set Identity. For example, Group Identity may be assigned by the service provider and is required to address the individual elements in the presence database:

GroupID, ItemName (GroupID, Nomeltem)

If the presence set contains more than one item with the same name, the ItemName must have the ItemlD (IDItem) attribute assigned.

Note that Identities such as UserID (UserID), DevicelD (DeviceID) and ClientID (CustomerID) are not required.

A. EXAMPLE OF PRESENCE PROTOCOL

A.1.0 Unsigned Presence (Figure 8)

A user's presence information may be obtained separately from the 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, either by signing and reviewing presence items as in Figure 9, or obtaining presence items as shown in Figure 8.

The user of a presence service can, at any appropriate time, update their presence information on the presence server by sending a presence update message as shown in figure 8. As mentioned, a user can issue a presence message. obtaining presence to request the presence information of another user, as also shown in figure 8. The presence information is distributed back to the requesting user.

The publisher may update their presence information only partially. Similarly, the user may request only partial presence information.

If the user is not authorized for the presence information requested, empty content is sent to the user.

Authorization of presence information for a particular user is done by including the user in the group that corresponds to the presence set. This is described below in the part entitled 'Presence Database Management'.

A. 1.1 UpdatePresence

Direction: Presence Client -> Server Presence

Presence Server Presence)

Content Model: (TransactionlD, GroupID, Presence) (TransactionID, GroupID, Presence)

Attributes: None

Usage: This primitive updates the values ​​of one or more presence items on the presence server. Presence items to be updated are carried in the Presence information element. If these are Presence items that do not exist on the server for the given 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.

Content does not require either UserID (UserID) or PublisherID (IDEditor). The association between the editor and the XML document containing the UpdatePresence primitive is done in the authentication protocol.

A.1.2 TransactionlD (TransactionID)

Content Model: (#PCDATA)

Attributes: None

Usage: This is a unique identifier that associates the client request with the server with the corresponding server response to the client. The client may have sent more than one request to the server before getting the first response. The first answer does not necessarily refer to the first request. Consequently, there has to be a mechanism that links requests and responses together. Typically, a TransactionlD is a sequence number. It is assigned by the client in the request and used by the server in the response.

A.1.3 GroupID

Content Model

Attributes: None Usage: This (#PCDATA)

ID uniquely identifies service provider domain; the publisher role includes the authorization group and presence set assigned by the presence service provider.

in what . IS

A.1.4 UpdateStatus

Direction: Presence Server -> Presence Client

Attendance Customer Attendance)

Content Model: TransactionlD, StatusCode (TransactionID, StateCode)

Attributes: None

Usage: This primitive is the presence server response to the client's UpdateRequest request. The StatusCode can have the following values: unsupported, reassignment, success, failure.

A. 1.5 GetPresence

Direction: Presence Client -> Presence Server

Presence Server Presence)

Content Model: (TransactionlD, ((GroupID,

PresenceNames?) *) | PresenceNames?) (TransactionID, ((GroupID, PresenceName?) *) PresenceName?)

Attributes: None

Use: This primitive is used to request presence information from the presence server. There may be zero or more GroupIDs. Each GroupID can be coupled with an optional PresenceNames. When GroupID is not used, then the request scope is all groups of which the user is a member. The server associates the request with the identity of the user making the request through the authentication protocol. PresenceNames is defined later in this document. It lists the presence items by the name from which the value is requested. It is optional. Either it is attached to Grouplds or it can be isolated when no GroupIDs are listed. When coupled with 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 Presenceltem (Presence Items)

Direction: Presence Server -> Presence Client

Content Model: (TransactionlD, StatusCode, ((GroupID, Presence) *) (TransactionID, StateCode ((GroupID, Presence *))

Attributes: None

Use: This primitive provides the list of ordered presence items and the order result state. The Presence element is the presence set corresponding to a particular GroupID and is defined later in this document. StausCode can have the following values: unauthorized, item unavailable, success, failure.

A.2.0 Subscribed Presence

Another mechanism for distributing presence information is to sign information about someone's presence. The message flow is shown in figure 9.

The requesting user sends an A.2.1 presence signature message to the presence server to sign someone's presence information.

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

When the ordering user no longer wants to receive presence information, you can unsubscribe from A.2 presence information. Alternatively, presence information may be subscribed to for a period of time, and the unsubscribe message is not required.

The requesting user may subscribe only to part of the presence information that they are authorized to obtain.

A.2.1 SubsPresence

Direction: Presence Client -> Presence Server

Content Model: (TransactionlD, SubsPeriod ?, ((GroupID, PresenceNames?) *) | PresenceNames?) (TransactionID, Subscription Period ?, ((GroupID, PresenceName?) *) \ PresenceName?) Attributes: None

Use: This primitive is used to subscribe to presence information for publisher functions for which the subscriber is authorized. The optional GroupID specifies the editor role that is subscribed. When GroupID is missing, then all functions for which the subscriber is authorized are subscribed. Each GroupID may be associated with PresenceNames that limit items signed within the group to those listed on PresenceNames. 0 Optional SubsPeriod specifies the time duration for the subscription. When missing, the subscription lasts until a primitive UnsubsPresence is invoked or until the service provider terminates the subscription. PresenceNames specifies the presence items that are subscribed to from an authorized set. When missing, then all presence items that the user is authorized in the presence set (GroupID) are signed. When used in isolation without a GroupID, then designated items from all authorized groups are signed. PresenceNames is defined later in this document.

The subscriber's identity is discovered in the authentication protocol.

A.2.2 SubsPeriod (Subscription Period)

Content Model: (#PCDATA)

Attributes: None

Usage: Defines the duration of the subscription period. The unit of time is TBD. Alternatively, the content may indicate the date the subscription ends.

A.2.3 PushPresence

Direction: Presence Server -> Presence Client

Attendance Customer Attendance)

Content Model: (GroupID, Presence) + ((GroupID, Presence)

Presence) +)

Attributes: None

Use: This primitive pushes signed presence items that have been modified by the publisher to users. GroupID identifies the role.

A.2.4 UnsubsPresence

Direction: Presence Client -> Presence Server

Presence Server Presence)

Content Model: (TransactionlD, ((GroupID,

PresenceNames?) *) | PresenceNames?) (TransactionID, ((GroupID, PresenceName?) *) PresenceName?)

Attributes: None

Use: This primitive is used to terminate the presence information subscription. Subscription termination may be limited to certain groups and may also be limited to certain presence items. When no GroupID is given, you can limit subscription termination to designated presence items in all groups. When no GroupID is given or

PresenceNames all user subscription is terminated.

A.2.5 SubsStatus (SubscriptionStatus)

Direction: Presence Server -> Presence Client

Attendance Customer Attendance)

Content Model: (TransactionlD, StatusCode, ((GroupID, PresenceNames) *) (Transaction ID, Status Code ((GroupID, PresenceName) *)

Attributes: None

Use: This primitive returns StatusCode to the unsubscribe operation and lists the items and presence groups that are still subscribed. 0 StatusCode can have the following values: unsupported, item not existing , unsigned item, success, failure.

A.3.0 Presence Database Management

The presence user can manage their presence sets and user groups on the presence server.

A role containing a presence set and user group is created using the message CreatePresGroup A.3.1. The presence server will respond with the message PresGroupStatus (PresenceGroupStatus) A.3.6 indicating the status of the requested operation and an ID for the created group. A Presencelnfo (Presence Info) A.3.7 message is sent to group members indicating the presence items they are allowed to obtain or sign.

The presence user can request group information with the message GetPresGroupStatus A.3.8. The request for group information is limited to the group owner.

The presence user who owns the user group can add and delete group members or presence items from the presence set.

The editor can have a group deleted via the message DeletePresGroup.

A.3.1 CreatePresGroup

Direction: Presence Client -> Presence Server

Presence Server Presence)

Content Model: (TransactionlD, MemberList, Presence (TransactionID, Member List, Presence)

Attributes: None

<td>Use:</td><td colspan="2">This primitive</td><td>ask the server</td><td>for</td>

<td>create a function</td><td>in the server</td><td>in</td><td colspan="2">presence. 0 group of</td>

<td>authorization contains</td><td>the members</td><td>at</td><td>member list</td><td>it's the</td>

Presence set is contained in Presence.

A.3.2 MemberList (ListMembers)

Content Model: (MemberDescription) + (DescriptionMember) +

Attributes: None

Usage: The list of members. The description originates from the user.

A.3.3 MemberDescription (DescriptionMember)

Content Model: (UserOriginatedMD ?, ServerOriginatedMD? (UserOriginatedMD ?, ServerOriginatedMd?)

Attributes: None

Usage: The user sourced part is a description of a member as viewed by the user. The server originated part is a description of a member as stored in the server database.

A.3.4 UserOriginatedMDUserUser

Content Model: (#PCDATA)

Attributes: None

Use: These are user-sourced means of identifying a person. This could be a name, an MSISDN from one of the target person's phones, an email address, a SIP address, etc. It can also be a combination of these. The dataformat of the description is not within the scope of this document but known formats such as vCard should be used.

A.3.5 ServerOriginatedMD

Content Model: (#PCDATA)

Attributes: None

Usage: These are server-sourced means of identifying a person. This could be a name, an MSISDN from one of the target person's phones, an email address, a SIP address, etc. It can also be a combination of these as stored in the server database. The description dataformat is not within the scope of this document but known formats such as vCard should be used.

A. 3.6 PresGroupStatus (PresenceGroupStatus)

Direction: Presence Server -> Presence Client

Attendance Customer Attendance)

Content Model: (TransactionlD, StatusCode, (GroupID, MemberList, PresenceNames) *) (TransactionID, StateCode, (GroupID, ListMembers, PresenceName) *)

Attributes: None

Usage: This primitive returns the GroupIDs of the currently existing editor roles along with the presence item names and role group members. The server has assigned a new GroupID to the new role in case the operation is successful. The server has populated the server-originated part of the member list. 0 The server should not give any personal or confidential information in the member list beyond the level already existing in the originating part of the user, or of a level that is required to uniquely identify a person. This is TBD. 0 StatusCode can get the following values:

not supported, unknown member, unknown presence item, success, failure.

A.3.7 Presencelnfo (InformationPresence)

Direction: Presence Server -> Presence Client

Attendance Customer Attendance)

Content Model: (GroupID, Presence?) + ((GroupID,

Presence?) +)

Attributes: None

Use: This primitive announces the new presence items to the authorization group. The message contains all authorization group presence items given to both subscribers and non-subscribers. This message is sent to new group members if group members have changed, or to all group members if new presence items have been added. The message is sent to removed group members so that there is no Presence associated with GroupID.

A.3.8 GetPresGroupStatus Address: Presence Client -> Presence Server

Presence Server Presence)

Content Model: (TransactionlD, GroupID *) (TransactionID, GroupID *)

Attributes: None

Usage: This primitive asks for the message

PresGroupStatus to the server. The user can only request information from his own group. GroupID limits the information to the given groups. When there is no GroupID then the status is returned to all groups that are owned by the orderer.

A.3.9 AddMembers

Direction: Presence Client -> Presence Server

Presence Server Presence)

Content Model: (TransactionlD, (GroupID, MemberList) +) (TransactionID, (GroupID, Member List) +)

Attributes: None

Usage: This primitive asks the server to add designated group members to certain groups.

A. 3.10 RemoveMembers

Direction: Presence Client -> Presence Server

Presence Server Presence)

Content Model: (TransactionlD, (GroupID, MemberList) *) (Transaction ID, ((GroupID, Member List) *))

Attributes: None

Usage: This primitive asks the server to remove designated group members from the given groups. The MemberList (MemberList) is populated with new information sourced from the server.

A. 3.11 DeletePresGroup

Direction: Presence Client -> Presence Server

Presence Server Presence)

Content Model: (TransactionlD, (GroupID *) (TransactionID, (GroupID)

Attributes: None

Usage: This primitive asks the server to remove one more of the editor functions. GroupID identifies the role that should be removed. When no GroupID is given then all editor data is removed.

A.3.12 AddPresence

Direction: Presence Client -> Presence Server

Presence Server Presence)

Content Model: (TransactionlD, (GroupID, Presence) *) (Transaction ID, ((GroupID, Presence) *))

Attributes: None

Usage: This primitive asks the server to add certain presence items to the given roles.

A. 3.13 RemovePresence

Direction: Presence Client Presence Server

Presence Server Presence)

Content Model: (TransactionlD, (GroupID,

Presence?) *) (Transaction ID, (GroupID, Presence?) *))

Attributes: None

Usage: This primitive asks the server to remove certain presence items from the given roles. When there is no Presence element associated with GroupID then all presence items are removed from the function.

A. 3.14 Dynamic Customer Change

A publisher or subscriber can change their client at any time. Typically the client device also changes. In a rare case the user can change only the client instance on the same device. A change to a new MT is also possible. Client switching requires the user to copy or synchronize their presence data from the old customer to the new customer. In the case of an editor there could be some specific presence data that is static for a particular client and is not included in the synchronized set. Synchronization can take place locally or can be network assisted. In any case, existing synchronization protocols should be used. This is not within the scope of the presence protocol.

Another aspect brought about by the change of subscriber customer is the registration of the new customer to be the active customer who receives the presence related push messages. Registration can take place automatically (no user information is required), semi-automatically (user confirmation is required) or manually (user must start registration) depending on:

- The user activates a new client on the same device (automatic);

The user SIM changes to a new device (automatic);

- User has a different SIM on the new device but only the new device is switched on (semi-automatic); or

- The user has a different SIM on the new device and both new and old devices are switched on (manual).

In any case the registration can be handled by lower level protocols. For example, if SIP is the transport protocol of choice for presence documents, then this protocol can also be used for registration.

A. 4.0 Document Type Definition (DTD) for Presence Protocol <1- Root element -> <! ELEMENT PresProtocol (UpdatePresence | UpdateStatus | GetPresence | Presenceltems | SubsPresence | UnsubsPrecence | SubsStatus | CreatePresGroup | PresGroupStatus | Presencelnfo | GetPresGroupStatus | AddMembers | RemoveMembers | DeletePresGroup | AddPresence | RemovePresence)>

<! ATTLIST PresProtocol Version NMTOKENS #REQUIRED>

&lt;! ELEMENT UpdatePresence (TransactionlD, GroupID,

Presence)>

<(ELEMENT TransactionlD (#PCDATA)>

<! ELEMENT GroupID (#PCDATA)>

<! ELEMENT Presence (#PCDATA)>

<! ELEMENT UpdateStatus (TransactionlD, StatusCode)>

<! ELEMENT StatusCode (#PCDATA)>

<(ELEMENT GetPresence (TransactionlD, ((GroupID, Presence Names?) *) | PresenceNames?)>

<! ELEMENT PresenceNames (#PCDATA)>

<(ELEMENT Presenceltems (TransactionlD, StatusCode, (GroupID, Presence) *)>

<! ELEMENT SubsPresence (TransactionlD, SubsPeriod ?, ((GroupID, PresenceNames?) *) | PresenceNames?)>

<! ELEMENT SubsPeriod (#PCDATA)>

<! ELEMENT PushPresence ((GroupID, Presence) +)>

<! ELEMENT UnsubsPresence (TransactionlD, ((GroupID, PresenceNames?) *) | PresenceNames?)>

<! ELEMENT SubsStatus (TransactionlD, StatusCode, (GroupID, PresenceNames) *)>

<! ELEMENT CreatePresGroup (TransactionlD, MemberList, Presence)>

<! ELEMENT MemberList ((MemberDescription) +)>

&lt;! ELEMENT MemberDescription (UserOriginatedMD ?,

ServerOriginatedMD?)>

<! ELEMENT UserOriginatedMD (#PCDATA)>

<! ELEMENT ServerOriginatedMD (#PCDATA)>

<! ELEMENT PresGroupStatus (TransactionlD, StatusCode, (GroupID, MemberList, PresenceNames) *)>

<! ELEMENT Presencelnfo ((GroupID, Presence?) +)>

<! ELEMENT GetPresGroupStatus (TransactionlD, GroupID *)>

&lt;! ELEMENT AddMembers (TransactionlD, (GroupID,

MemberList) +) &lt;! ELEMENT RemoveMembers (TransactionlD, (GroupID,

MemberList) +)>

<! ELEMENT DeletePresGroup (TransactionlD, GroupID *)>

<! ELEMENT AddPresence (TransactionlD, (GroupID, Presence) +)>

&lt;! ELEMENT RemovePresence (TransactionlD, (GroupID,

Presence?) +)>

<! - End of DTD -> (DTD End)

Document))

B. EXAMPLE OF PRESENT CONTENT FORMAT

As indicated above, presence content can be divided into the following classes:

Client Availability: Presence attributes that describe client availability for communication, for example, network accessibility, GPRS coupled, on / off state.

User Availability: Presence attributes that describe the customer's availability for communication, for example, ready, meeting, busy, away, on call, chatting, not disturbing, etc.

Local Conditions: Presence attributes that describe the user's local environment, for example, local time, quiet / noise environment, indoor, outdoor, user location, in terms of, for example, geographic location, visited PLMN, street / city , installations.

Personal Status: Various personal attributes that describe the user's status, for example, personal mood, interests, and intentions.

Client Capabilities: Presence attributes that describe client capabilities, for example, to support different media, different media types, and different characteristics.

User Attributes: Presence attributes that allow the customer or the user to define their own textual values ​​and references to external values.

Extended Presence Service: Dynamically defined non-standard service provider presence attributes that, however, must be passed through standard presence servers and proxies.

BL DESIGN GOALS A large amount of presence communication is to send changes in the value portion of presence items to subscribers. Often just changed a single value. To minimize the amount of data transferred the design goal is to keep the hierarchical representation of presence items as flat as possible. For this reason presence items are classified under the presence classes described above. Instead, classes may be given in the presence of items with an optional attribute.

D 2 COMMON ATTRIBUTES

Presence elements contain a variety of attributes, most of which can be used on any presence item.

D. 2.1 Version

Content Syntax: NMTOKENS Required: Yes

Usage: Gives the version of the presence content format.

D.2.2 Class

Content Syntax: NMTOKEN

Required: No

Usage: Indicates to which class the attribute belongs.

Possible values ​​are:

CLIENT_AVAILABILITY, USER_AVAILABILITY, LOCAL_CONDITIONS, PERSONAL_STATUS, CLIENT_CAPABILITIES, USER_ATTRIBUTES, EXT_PRES_SERVICE.

(CUSTOMER_AVAILABILITY, USER_AVAILABILITY, LOCAL_CONDITIONS, STAFF_Customer_ABILITIES, USER ATTRIBUTES, PRICE_EXT SERVICE).

D.2.3 ID

Content Syntax: PUBIDLITERAL Required: No

Use: This is a unique ID for a designated presence item. It is assigned by the customer.

D. 2.4 Cacheability (Caching Susceptibility)

Content Syntax: NMTOKEN

Required: No

Usage: Indicates whether or not the presence item can be cached by proxies. Possible values ​​are: YES, NO. It is assigned by the customer. If this attribute is missing, a value of NO is assumed.

D.2.5 ValidityPeriod

Content Syntax: NMTOKEN

Required: No

Use: This is a validity period for the cached presence item. 0 value is time in seconds. It is assigned by the presence server.

D.2.6 DeviceName (DeviceName)

Content Syntax: NMTOKEN

Required: No

Usage: This is the name of the client device. It is assigned by the customer.

D.2.7 Accuracy

Content Syntax: NMTOKEN

Required: No

Use: It is the accuracy of a positioning device. It is given in meters.

D.2.8 ImageType (Typeface)

Content Syntax: NMTOKEN

Required: No

Usage: It is the encoding of content of an image. Some possible values ​​are: JPEG, GIF, BMP.

D.2.9 SoundType (SoundType)

Content Syntax: NMTOKEN

Required: No

Usage: This is the type of sound codec (encoder / decoder) used to encode sound. Some possible values ​​are: AMR, EFR, MP3, AAC, MIDI.

D. 2.10 ExtRef (ExternalExternal)

Content Syntax: PUBIDLITERAL

Required: No

Usage: It is a URL that gives an external reference.

D. 2.11 ExtRefChange (ExternalReference Change)

Content Syntax: NMTOKEN

Required: No

Usage: Indicates that the content of an external reference has changed. Possible values ​​are: YES, NO.

D. 2.12 ContentChange (ContentChange)

Content Syntax: NMTOKEN

Required: No

Usage: This is a 0 to 255 counter that indicates a change in content value. The server or proxy can store the content (but is not required) of the last 32 values. The same values ​​for two contents within the last 32 values ​​must match the same content.

D.3 Client Availability

D.3.1 DeviceOn

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod,

DeviceName (Class, ID, Caching Susceptibility, Validity Period, DeviceName)

Usage: Gives the on / off status of the user terminal. The editor adds this item to the role on the server using group management messages. After that, 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 an ID attribute is required. Content can have values ​​ON or OFF. When the user terminal is on but out of network coverage, the network assigns the value OFF to this item.

D.3.2 DeviceRoaming

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod, DeviceName (Class, ID, Caching Susceptibility, Validity Period, DeviceName)

Usage: Indicates to the subscriber that the publisher is roaming (roaming) in a visited 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 have YES or NO values.

D.3.3 NetworkType (NetworkType)

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod, DeviceName (Class, ID, Caching Susceptibility, Validity Period, DeviceName)

Usage: Indicates the type of mobile network to which the publisher is currently connected. Content may be 2G, 3G-99, 3G-R4, or 3G-R5. The user may have more than one terminal in their presence information. In this case the use of the ID attribute is required.

D.4 User Availability

D.4.1 UserStatus (UserState)

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod (Class, ID, Caching Susceptibility, LifeValid)

Usage: Indicates the current state of the publisher in terms of the amount of distraction it is willing to accept. The following values ​​are set: available, silent, in car, busy.

D.4.2 PreferredContact (PreferredContact)

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod (Class, ID, Caching Susceptibility, LifeValid)

Usage: Indicates the current preferred contact method for the publisher. The following values ​​are set: PHONE, VOICE_MESSAGE, MESSAGE, MAIL, NO CONTACT (PHONE, VOICE MESSAGE, MAIL, NO CONTACT).

D.4.3 PreferredDefaults

Content Template: ((TimePeriod, PrefCont) *) (Time Period, Preferred Contact) *)

Attributes: Class, ID, Cacheability, ValidityPeriod (Class, ID, Caching Susceptibility, LifeValid)

Usage: This is the presence metadata that the publisher can send to the presence server. The information is associated with the function as other presence information, but this item is not available to subscribers. Instead it controls the values ​​of the PreferredContact element. Specifies a preferred default contact for certain time periods. User-specified time periods may overlap, or one time period may even span another completely. The server changes the value of the PreferredContact element according to PreferredDefaults until certain periods expire. However, it does not block a user by directly changing the PreferredContact value. Similarly, the fact that the user directly changes the PreferredContact value does not prevent the server from changing it again when a period expires. The user can remove the default mechanism by sending this element with empty contents to the server.

D.4.4 TimePeriod

Content Model: (PeriodStart, PeriodEnd,

RepetitionPeriod ?, PeriodPrecedence (HomePeriod,

EndPeriod, Repetition Period ?, PrecedencePeriod) Attributes: None

Usage: Describes the beginning of a period, for example, the start time, the end of the period, for example, the end time, the repeating period, for example, DAY, and the period precedence.

D.4.5 PeriodStart (BeginningPeriod)

Content Model: (#PCDATA)

Attributes: None

Usage: This is the start period. It can be Time, TimeDayofWeek, TimeDayofMonth or a full date.

D.4.6 PeriodEnd (EndPeriod)

Content Model: (#PCDATA)

Attributes: None

Usage: This is the start period. It can be Time, TimeDayofWeek, TimeDayofMonth or a full date. The resolution may be the same as in PeriodStart.

D.4.7 RepetitionPeriod

Content Model: (#PCDATA)

Attributes: None

Usage: Gives the repeating period for the start-end. Must be one of the following values: DAY, WEEK MONTH (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 PeriodPrecedence

Content Model: (#PCDATA)

Attributes: None

Use: This element resolves the conflict between overlapping periods. It 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 takes the contact preference associated with the highest precedence value.

D.4.9 PrefContact (PreferredContact)

Content Model: (#PCDATA)

Attributes: None

Usage: Indicates to the publisher which contact method is preferred by default for the associated period. It can have the same values ​​as the PreferredContact element.

D.5

Local Conditions

D.5.1 LocalTime

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod (Class, ID, Caching Susceptibility, Validity Period)

Usage: Gives the publisher local time

D.5.2 Measuredloction (Measured Location)

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod,

Accuracy (Class, ID, Caching Susceptibility, Validity Period, Accuracy)

Usage: Gives the measured position of the client device. These measurements can be either sensor based (eg GPS), network based or a combination of both. The Accuracy attribute gives an indication of the average positioning accuracy achieved by the method. The content includes at least the lateral position (x- and y- coordinates), but may also include the vertical position. If the service provider supports 'Convertedlocation' as described below, then Measuredlocation may be input to the service provider's conversion process, for example, consistent with a map.

D.5.3 Convertedloction (ConvertedLocation)

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod (Class, ID, Caching Susceptibility, Validity Period,)

Usage: This information typically originates from the service provider, but may also originate from the publisher. Gives the user's location, given in a form that people can understand, such as a street name. Information is derived by converting a measured position into this form, for example, consistent with a map.

D.5.4 StatedLoction

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod (Class, ID, Caching Susceptibility, ValidityPeriod,)

Usage: This is the location of the editor as indicated by the publisher himself. 0 content is a short text string.

D.5.5 UserEnvironement (User Environment)

Content Model: (EnvAttributes +) (Ambienti Attributes) Attributes: Class, ID, Cacheability, ValidityPeriod (Class, ID, Caching Susceptibility, Validity Period,)

Usage: Gives some environment attributes about the user.

D.5.6 EnvAttributes

Content Model: (#PCDATA)

Attributes: None

Use: The attributes defined are: INDOOR,

OUTDOOR, QUIET, NOISY, ALONE, IN_GROUP (INDOOR, OUTDOOR, SILENCE, NOISE, ONLY, IN_GROUP)

D. 6 Personal Status

D.6.1 StatusText (StateText)

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod (Class, ID, Caching Susceptibility, Validity Period,)

Usage: Short text (about 30 characters) that the user can type.

D.6.2 Statuslmage (State Image)

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod, ImageType (Class, ID, Caching Susceptibility, Validity Period, Typolmage)

Usage: This is an image that the user can attach to their status information. It is carried on XLM content in an encoded transfer form, for example, base64. The IamgeType attribute describes the encoding of image content, for example jpeg.

D.6.3 StatusSound

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod, SoundType (Class, ID, Caching Susceptibility, Validity Period, SoundType)

Usage: It is a short sound clip (about 5 to 30 seconds) that the user can attach to their status information. It is carried on XLM content in an encoded transfer form, for example, base64. The SoundType attribute describes the encoding of sound content, for example AMR, MP3, AAC, MIDI, etc.

D.7 ClientCapabilities

Client capabilities in the presence context means the ability of the client host device for various types of human-to-human communication. This is a very different matter and much simpler than allowing a software application to take full advantage of the client device's hw and sw capabilities.

Human-to-human communication classes are: messaging, email, voice calling, and multimedia calling. The purpose of presence is to make known to others the means of communication and other user attributes, but not to be the means of two-way communication itself. For this reason, using the term 'Customer Capabilities' to classify presence information is misleading.

Client capabilities are detected by network capabilities. This means, for example, that the publisher has video calling capability only when your client device has its capability AND the network where it is currently roaming (supports roaming) supports this capability. This makes customer capability information dynamic.

D.7.1 MessagingCapabilities (Messaging Capabilities)

Content Template: (MessType *) (TypeMessage *)

Attributes: Class, ID, Cacheability, ValidityPeriod, (Class, ID, Caching Susceptibility, Validity Period)

Usage: Gives the list of dynamic messaging capability of the client device. An empty list means that there is currently no message exchange capability.

D.7.2 MessType (Message Type)

Content Model: (#PCDATA)

Attributes: None

Usage: Gives the type of messaging capability of the client device. The content can be one of the following: SMS, MMS or X-message application nane. The message application name field is a device specific message exchange method, for example, smart message exchange.

D.7.3 EmailClient

Content Model: (EmailClientType *) (EmailClient * Type) Attributes: Class, ID, Cacheability, ValidityPeriod (Class, ID, Caching Susceptibility, PeriodValidity)

Usage: Gives the dynamic email capabilities of the client device. An empty list means that there is currently no email capability.

D.7.4 EmailClientType (EmailClientType)

Content Model: (#PCDATA)

Attributes: None

Usage: Gives the email client type of the client device. The content can be one of the following: SMTP, POP3 IMAP4 or X-mail application name ”. The software should not give the mail protocol names as such to the user. Instead, the client software understands the email environment of the client device and interprets these names within the environment of this email. The information presented to the user must also have meaning to the user.

D.7.5 VoiceCallCapability

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod (Class, ID, Caching Susceptibility, Validity Period)

Usage: Gives the dynamic voice calling capabilities of the client device. The content can be one of the following: ΝΟΝΕ, VOICE_CALL, RICH_VOICE_CALL (NONE,

CALL_VOZ, CALL_VOZ_RICA).

D. 7.6 MultimediaCallCapability

Content Model: (MMCap *)

Attributes: Class, ID, Cacheability,

ValidityPeriod (Class, ID, Caching Susceptibility, Validity Period)

Use: Gives the user one-way or two-way dynamic multimedia communication capabilities. An empty list means that there are currently no capabilities.

D.7.7 MMCap (CapacityMM)

Content Model: (#PCDATA)

Attributes: None

Usage: Gives the type of multimedia call capability. Can be one of the following: UP_LINK_VIDEO_STREAMING,

DOWN_LINK_VIDEO_STREAMING, VIDEO_CALL,

RICH_VIDEO_CALL (VIDEO_FLUX_ASCENDANT,

VIDEO_FLOW_FLOW, CALL_ VIDEO,

CALL_VIDEO_RICA).

D. 8 User Attributes

This class contains both user-specific and user-defined presence data.

D.8.1 UserPresenceltem (ItemPresenceUtilizer)

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod, ExtRef, ExtRefChange (Class, ID, Caching Susceptibility, Validity Period, External Reference, ChangeExternal Reference)

Use: Provides a means for the user to define their own presence items. If more than one user-specified presence item is defined for the same role, then use of the ID attribute is required. The content may be short text. The optional attribute ExtRef (External Reference) is a URL of an external object referenced by this presence item. 0 URL may refer to another part of the multipart MIME that contains the presence item XML document, or it may be a reference to an external object. The optional ExtRefChange attribute can be used to indicate to subscribers that the external object has changed.

D.8.2 ClientTypeRequest (RequestTypeClient)

Content Model: (#PCDATA)

Attributes: Class, ID, Cacheability, ValidityPeriod (Class, ID, Caching Susceptibility, Validity Period)

Usage: This is a special element used by the publisher to request the type of customer from their subscribers. When an editor includes this element in their presence data for a particular function, then the server sends it to all subscribers of the presence information with the message PushPresence. It may optionally also be included in the Presenceltems message used by non-subscribers to request specific presence items. This element is not announced in the Presencelnfo message. It is not a presence element that can be signed. The presence server, after first sending your item to subscribers, may periodically include this item also for further PushPresence messages to make sure all subscribing clients have this item.

Clients receiving this item send their client types to the presence server. In addition, a client must send its type to the server each time the client is activated when this item is its presence information stored on the client.

An alternative way for the publisher to know the customer types of their subscribers would have been for the publisher to subscribe to their customer types. This, however, is a different business model. A publisher may not always want to be a subscriber to their own subscribers. This element allows the publisher to obtain customer types from the existing contractual structure between the publisher and the presence service provider. Additionally, this method mandates the subscriber client to send their types to the server. If the publisher had used the subscription model to obtain client types, then authorization of this information for the publisher would have been at the subscriber's discretion.

D.8.3 ClientType (CustomerType)

Content Model: (ClientName, ClientManufacturer, ClientVersion - (CustomerName, Customer Manufacturer, Customer Version)

Attributes: Class, ID, Cacheability, ValidityPeriod (Class, ID, Caching Susceptibility, LifeValid)

Usage: Knowledge of subscriber client types is used by publishers to enable client-specific extensions to the presence set. It makes no sense for a publisher to use these extension items if subscribing customers are unable to decode them.

A subscriber client sends client type information to the presence server using the UpdatePresence message. The groupID used in the message belongs to the editor role and not to the subscriber's own role. This is an exception to the general rule that a user is allowed to update presence information only for his own role. The presence server sends information from this element to the editor using the PushPresence message. The GroupID used belongs to the editor role. From the publisher's point of view, he is then getting presence information from his own presence set.

A publisher can include their own client type in the presence set. So this information is treated like any other presence information and does not imply any special conduct on the presence servers or subscriber clients.

D.8.4 ClientName (CustomerName)

Content Model: (#PCDATA)

Attributes: None

Usage: This element gives the name of the presence client application.

D.8.5 ClientManufacture

Content Model: (#PCDATA)

Attributes: None

Usage: This element gives the name of the client's presence manufacture.

D.8.6 ClientVersion (Customer Version)

Content Model: (#PCDATA)

Attributes: None

Usage: This element gives the version of the client application.

D.8.7 ClientPresenceltem (CustomerPresence Item)

Content Model: (ClientType, CliPresItem - CustomerType, ItemPresenceClient)

Attributes: Class, ID, Cacheability, ValidityPeriod, ContentChange (Class, ID, Caching Susceptibility, Validity Period, ChangeContent)

Use: This element is the application-specific presence item of the publisher client. 0 ClientType is the publisher presence client client type. No attributes are used in the ClientType item when used as part of this element. If the publisher defines more than one specific presence item, then use of the ID attribute is required. The optional ContentChange attribute is a counter from 0 to 255. When used it is increased one at a time which changes the content of the presence item. This provides an alternative means for the presence server to detect changes in the content of a non-default presence item. The other alternative would have been for the server to take over content changes each time this item is sent to the server with the same ID attribute. The server behaves this way when the ContentChange attribute is not used by the client. When two items with the same ID attribute have the same counter value in ContentChange, then the content of these two items is the same.

D.8.8

CliPresItem (ItemPresenceCustomer)

Content Model: (#PCDATA)

Attributes: None

Use: This element is the customer-specific presence extension. Its syntax and structure are assumed to be known to the client, but not to the network elements.

D9. Extended Presence Service

The extended presence class of service is intended to provide a service provider-specific extension to the presence service. Like the client application-specific extension, only service endpoints (for example, publisher and subscriber clients) must be able to decode extensions. The presence server may also understand extensions but this is not mandated in this document. The difference between customer-specific extension method and this method is that service provider-controlled customers do not need to implement the default presence items. Presence items are presumed to be completely defined by the service provider and there are means to update the clients hosted by the user device with new features. One possible upgrade method is air downloadd. If a service provider creates new types of presence items, then it must upgrade existing customers to support these new types. The service provider controlled client communicates directly with the presence server and not via a standard presence client. A default presence client ignores all elements of this class.

An extended presence service primarily uses the elements of this class. You are also allowed to use the default presence element definitions. Uses the default presence protocol.

D.9.1 ExtPresence (Extended Presence)

Content Model Attributes: Class, (#PCDATA)

ID, Cacheability, ValidityPeriod, ContentChange (Class, ID, Caching Susceptibility, Validity Period, ChangeContent)

Usage: Use of the ID attribute is required if more than one presence item is defined by this mechanism. The optional ContentChange attribute is for this element. The syntax and contents are not within the scope of this document. Presence servers and proxies must allow content to refer to objects carried on the same multipart MIME, such as XML documents containing this element.

representation of

D. 10 Document Type Definition (DTD) for Presence Content Format <1- Root element -> (! Root element) <! ELEMENT Presence (DeviveOn | DeviceRoaming | NetworkType | UserStatus | PreferredContact | PreferredDefaults | LocalTime | MeasuredLocation | ConvertedLocation | StatedLocation | UserEnvironment | StatusText | Statuslmage | StatusSound | MessagingCapabilities | EmailClient | VoiceCallCapability | MultimediaCallCapabilities | UserPresenceltem | ClientTypeRequest | ClientType | ClientPresenceltem | ExtPresence)>

<! ATTLIST Presence Version NMTOKENS #REQUIRED>

<! ELEMENT DeviceOn (#PCDATA)>

&lt;! ATTLIST DeviceOn

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED

DeviceName NMTOKEN #IMPLIED>

<! ELEMENT DeviceRoaming (#PCDATA)>

&lt;! ATTLIST DeviceRoaming

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED

DeviceName NMTOKEN #IMPLIED>

<! ELEMENT NetworkType (#PCDATA)>

&lt;! ATTLIST NetworkType

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED DeviceName NMTOKEN #IMPLIED>

<! ELEMENT UserStatus (#PCDATA)>

&lt;! ATTLIST UserStatus

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT PreferredContact (#PCDATA)>

&lt;! ATTLIST Preferred Contact

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

&lt;! ELEMENT Preferred Defaults ((TimePeriod,

PrefCont) *)>

&lt;! ATTLIST Preferred Defaults

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT TimePeriod (PeriodStart, PeriodEnd, RepetitionPeriod ?, Period Precedence)>

<! ELEMENT PeriodStart (#PCDATA)>

<! ELEMENT PeriodEnd (#PCDATA)>

<! ELEMENT RepetitionPeriod (#PCDATA)>

<! ELEMENT PeriodPrecedence (#PCDATA)>

<! ELEMENT PrefCont (#PCDATA)>

CELEMENT LocalTime (#PCDATA)>

&lt;! ATTLIST LocalTime

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

CELEMENT MeasuredLocation (#PCDATA)>

&lt;! ATTLIST MeasuredLocation

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED Accuracy NMTOKEN #IMPLIED>

<! ELEMENT ConvertedLocation (#PCDATA)>

&lt;! ATTLIST ConvertedLocation

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT Stated Location (#PCDATA)>

&lt;! ATTLIST Stated Location

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT UserEnvironment (EnvAttributes +)>

&lt;! ATTLIST UserEnvironment

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN # IMPL1ED>

<! ELEMENT EnvAttributes (#PCDATA)>

<! ELEMENT StatusText (#PCDATA)>

&lt;! ATTLIST StatusText

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT Statuslmage (#CDATA)>

&lt;! ATTLIST Statuslmage

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED

ImageType NMTOKEN #IMPLIED>

<! ELEMENT StatusSound (#CDATA)>

CATTLIST StatusSound

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED

SoundType NMTOKEN #IMPLIED>

<! ELEMENT MessagingCapabilities (MessType *)>

&lt;! ATTLIST MessagingCapabilities

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT MessType (#PCDATA)>

<! ELEMENT EmailClient (EmailClientType *)>

&lt;! ATTLIST EmailClientType

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT EmailClientType (#PCDATA)>

CELEMENT VoiceCallCapability (#PCDATA)>

&lt;! ATTLIST VoiceCallCapability

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT MultimediaCallCapabilities (MMCap *)>

&lt;! ATTLIST MultimediaCallCapabilities

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT MMCap (#PCDATA)>

<(ELEMENT UserPresenceltem (#PCDATA)>

&lt;(ATTLIST UserPresenceltem

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED ExtRef PUBIDLITERAL #IMPLIED ExtRefChange NMTOKEN #IMPLIED>

<! ELEMENT ClientTypeRequest (EMPTY)>

&lt;! ATTLIST ClientTypeRequest

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<(ELEMENT ClientType (ClientName, ClientManufacturer, ClientVersion)>

CATTLIST ClientType

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT ClientName (#PCDATA)>

<! ELEMENT ClientManufacture (#PCDATA)>

<! ELEMENT ClientVersion (#PCDATA)>

&lt;! ELEMENT ClientPresenceltem (ClientType, &lt;! ATTLIST ClientPresenceltem

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED

ContentChange NMTOKEN #IMPLIED>

<! ELEMENT CliPresItem (#PCDATA)>

<! ELEMENT ExtPresence (#PCDATA)>

&lt;! ATTLIST ExtPresence

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED

ContentChange NMTOKEN #IMPLIED>

<! - End of DTD -> (End of DTD (Document Definition))

CliPresItem)>

of Type of

D. 11

Document Type Definition (DTD) for

PresenceNames (PresenceName)

DTD for PresenceNames is the same as for Presence except that only attributes and names of presence items are included. No presence values ​​are used.

<! - Root element -> <! ELEMENT PresenceNames (DeviceOn | DeviceRoaming | NetworkType | UserStatus

PreferredDefaults

ConvertedLocation StatusText | | PreferredContact | LocalTime | MeasuredLocation | StatedLocation | UserEnvironment Statuslmage | statusSound

MessagingCapabilities | EmailClient | VoiceCallCapability MultimediaCallCapabilities | UserPresenceltem | ClientTypeRequest | ClientType | ClientPresenceltem | ExtPresence)>

&lt;! ATTLIST &lt;! ELEMENT &lt;! ATTLIST

Presence Names Version NMTOKENS #REQUIRED>

DeviceOn (EMPTY)>

DeviceOn

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED DeviceName NMTOKEN #IMPLIED>

<! ELEMENT DeviceRoaming (EMPTY)>

&lt;! ATTLIST DeviceRoaming

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED DeviceName NMTOKEN #IMPLIED>

<! ELEMENT NetworkType (EMPTY)>

&lt;IATTLIST NetworkType

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED DeviceName NMTOKEN #IMPLIED>

<! ELEMENT UserStatus (EMPTY)>

CATTLIST UserStatus

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED> CELEMENT Preferred Contact (EMPTY)>

&lt;! ATTLIST PreferredContact

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT PreferredDefaults (EMPTY)>

&lt;! ATTLIST PreferredDefaults

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT LocalTime (EMPTY)>

&lt;! ATTLIST LocalTime

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT MeasuredLocation (EMPTY)>

&lt;! ATTLIST MeasuredLocation

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED Accuracy NMTOKEN #IMPLIED>

<! ELEMENT ConvertedLocation (EMPTY)>

&lt;! ATTLIST ConvertedLocation

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT StatedLocation (EMPTY)>

&lt;! ATTLIST Stated Location

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT UserEnvironment (EMPTY)>

&lt;! ATTLIST UserEnvironment

Class NMTOKEN #IMPLIED

IDPUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT StatusText (EMPTY)>

CATTLIST StatusText

Class NMTOKEN #IMPLIED

PUBIDLITERAL #IMPLIED

Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT Statuslmage (EMPTY)>

&lt;! ATTLIST Statuslmage

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED ImageType NMTOKEN #IMPLIED>

<! ELEMENT StatusSound (EMPTY)>

&lt;! ATTLIST StatusSound

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED SoundType NMTOKEN #IMPLIED>

&lt;! ELEMENT MessagingCapabilities &lt;! ATTLIST MessagingCapabilities

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED

CELEMENT EmailClient (EMPTY)>

(EMPTY)>

&lt;! ATTLIST EmailClientType

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT VoiceCallCapability (EMPTY)>

&lt;! ATTLIST VoiceCallCapability

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED>

CELEMENT MultimediaCallCapabilities (EMPTY)>

&lt;! ATTLIST MultimediaCallCapabilities

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED> <! ELEMENT UserPresenceltem (EMPTY)>

&lt;! ATTLIST UserPresenceltem

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED ValidityPeriod NMTOKEN #IMPLIED ExtRef PUBIDLITERAL #IMPLIED ExtRefChange NMTOKEN #IMPLIED>

&lt;! ELEMENT ClientType (EMPTY) &lt;! ATTLIST ClientType

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED>

<! ELEMENT ClientPresenceltem (EMPTY)>

&lt;! ATTLIST ClientPresenceltem

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED ContentChange NMTOKEN #IMPLIED>

<! ELEMENT ExtPresence (EMPTY)>

&lt;! ATTLIST ExtPresence

Class NMTOKEN #IMPLIED

PUBIDLITERAL ID #IMPLIED

Cacheability NMTOKEN #IMPLIED

ValidityPeriod NMTOKEN #IMPLIED ContentChange NMTOKEN #IMPLIED>

<1- End of DTD -> (End of DTD (Document Type Definition))

It will be apparent to those skilled in the art that as a technology advancement, the inventive concept can be implemented in many different ways. Accordingly, the invention and its embodiments are not limited to the above examples, but may vary according to the appended claims.