专利名称：移动即时消息收发和存在服务的制作方法
背景技术：
本发明涉及在移动电信系统中进行消息收发，更具体地来说，涉及移动即时消息和存在服务中的存在属性。
即时消息服务向最终用户提供一种快速交互式且主要基于文本的通信方式。由于增添了可跟踪您的聊天对象或“朋友”的存在状态和可用性并可将他们的状态或可用性通知您的服务，这就大大增强了即时消息的实用性。此类型的服务被称为“存在服务”。一般来说，存在可以视为包含与通过各种方式连接到即时消息服务的用户或客户有关的各种动态信息。此类信息的实例是关于通信的用户的可达到性、可用性以及位置。即时消息和存在服务的组合称为即时消息和存在服务(IMPS)。有线因特网用户已经可使用这种服务，但是一直缺少有线用户和移动用户之间的互连。
为了定义移动即时消息和存在服务的规范，已成立了无线村动议(Wireless Village initiative)。无线村即时消息和存在服务(IMPS)包括四个基本特征存在信息(presence)、即时消息收发、组和共享内容。共享内容允许用户和操作员建立他们自己的存储区，他们可以在其中粘贴图片、音乐和其它多媒体，同时可让IM或聊天对话中的其它人和组共享这些内容。无线村动议使操作员和最终用户均可创建和管理组。对于无线村动议，存在信息是关键的使能技术。在现有基于因特网的即时消息服务中，存在信息的值通常都是非常简单的，如用户处于活动状态、离开、不想通信等。这些值从预定义的值集合中选取。2001年4月26日发布了关于无线村移动IMPS解决方案的白皮书“无线村、移动IMPS动议白皮书”。现有移动终端可以视为较桌面计算机更准确反映个人状态的个人工具。考虑到可以从用户和移动终端得到的信息范围很广，预设存在信息域非常困难。因此，应该开发一种机制，能够容易地使用和添加新类型的存在信息。
发明的公开本发明的目的在于提出一种创建除已确定的存在属性以外的新存在属性的解决方案。
本发明的另一个目的在于显示如何组织和存储供客户使用的存在属性。
根据本发明的第一个方面，移动消息收发系统的客户装置将限定符添加到存在属性中，该限定符包含一个或多个说明该属性的用途的参数。接收到存在属性的客户装置根据所接收的属性中的限定符参数处理接收到的存在属性。存在属性是一个描述有关某个用户和/或客户装置的存在信息的数据集合，所述存在信息旨在供其它用户使用。存在属性还可以包含客户装置之间机器对机器的通信信息。
再根据本发明的第一个方面，移动消息收发系统包括至少一个客户装置和一个服务器，其中客户装置包括用于将存在信息作为存在属性发送到服务器的部件和用于从服务器接收存在属性的部件，存在信息按照以属性名来标识的存在属性类型来分类；以及服务器包括用于根据所接收到的存在属性来维护存在信息的部件，其特征在于客户装置包括用于将限定符添加到存在属性中的部件，所述限定符包括一个或多个说明所述属性的用途的参数，以及客户装置包括用于根据接收到的属性中的限定符参数来处理接收到的存在属性的部件。
根据本发明的第二个方面，客户装置编辑以授权者、属性名和限定符的组合来标识的存在信息属性，其中授权者指定负责维护属性的人，而限定符说明属性的用途。当接收到存在属性时，服务器和客户装置搜索已存储且与接收到的属性含有完全相同的标识符的属性。如果所接收到的属性的标识符的组合与已存储的属性的标识符组合完全相同的，则以接收到的属性替换已存储的属性。否则添加所接收到的属性，而不替换任何现有的属性。
再根据本发明的第二个方面，移动消息收发系统包括服务器和至少一个客户装置，其中客户装置包括用于将存在信息作为存在属性发送到服务器的部件和用于从服务器接收存在属性的部件，存在信息按照以属性名来标识的多个存在属性类型来分类；而服务器包括用于根据所接收到的存在属性来维护存在信息的部件，其特征在于，客户装置包括用于编辑以授权者、属性名和限定符的组合来标识的存在信息属性的部件，授权者指定负责维护属性的人而限定符说明属性的用途；服务器包括用于搜索已存储且与接收到的属性含有完全相同的标识符的属性的部件和用于在所接收到的属性的标识符的组合与已存储的属性的标识符的组合完全相同时以接收到的属性替换已存储的属性、否则就添加所接收到的属性的部件；以及，所述客户装置包括用于搜索已存储且与接收到的属性含有完全相同的标识符的属性的部件和用于在所接收到的属性的标识符的组合与已存储的属性的标识符组合完全相同时以接收到的属性替换已存储的属性、否则就添加所接收到的属性的部件。
再根据本发明的第一和第二个方面，所述系统具有如下特征所述客户装置包括用于在限定符中指定属性的显示设置的部件；以及所述客户装置包括用于根据所述限定符来显示所接收到的属性的部件。
再根据本发明的第一和第二个方面，所述系统具有如下特征所述客户装置包括用于在限定符中指定属性所应定址到的应用程序的部件；以及所述客户装置包括用于将所接收到的属性寻址到所述限定符指示的应用程序的部件。
再根据本发明的第一和第二个方面，所述系统具有如下特征所述服务器包括用于根据所述限定符来判断要将属性发送到一个还是多个客户装置的部件。
再根据本发明的第一和第二个方面，所述系统具有如下特征根据与存在组相关联的发布人用户将所述服务器从客户装置接收到的所述存在属性存储在数据库中。
再根据本发明的第一和第二个方面，所述系统具有如下特征每个存在属性作为包括属性名元素和属性值的项的一部分。属性名元素可以包含表示负责保持属性名元素和属性值唯一性的授权机构的授权机构字符串。
再根据本发明的第一和第二个方面，所述系统具有如下特征存在集合包括属于与单个存在组相关联的发布人用户的单个发布人角色的一个或多个存在属性。
再根据本发明的第一和第二个方面，移动消息收发系统具有如下特征作为发布人的客户装置用户可以使用所述客户装置或者可以以多个发布人角色来使用多个客户装置。
根据本发明的第三个方面，一种用于移动消息收发系统的移动客户装置，所述客户装置包括用于将存在信息作为存在属性发送到服务器的部件，所述存在信息按照以属性名来标识的多个存在属性类型来分类，其特征在于所述客户装置包括用于将限定符添加到存在属性中的部件，所述限定符包括一个或多个说明属性用途的参数。
根据本发明的第四个方面，一种用于移动消息收发系统的移动客户装置，所述客户装置包括用于从服务器接收存在属性的部件，存在信息按照以属性名来标识的存在属性类型来分类，其特征在于所述客户装置还包括用于将限定符添加到存在属性中的部件，所述限定符包括一个或多个说明所述属性的用途的参数，以及还包括用于根据接收到的属性中的限定符参数来处理接收到的存在属性的部件。
根据本发明的第五个方面，移动消息收发系统的移动客户装置，所述客户装置包括用于将存在信息作为存在属性发送到服务器的部件，以及从服务器接收存在属性的部件，所述存在信息按照以属性名来标识的多个存在属性类型来分类，其特征在于，所述客户装置还包括用于编辑以授权者、属性名和限定符的组合来标识的存在信息属性的部件，所述授权者指定负责维护属性的机构而所述限定符说明属性的用途；用于在搜索已存储且与接收到的属性含有完全相同的标识符的属性的部件以及用于在所接收到的属性的标识符的组合与已存储的属性的标识符组合完全相同时以接收到的属性替换已存储的属性、否则就添加所接收到的属性的部件。
再根据本发明的第三、第四和第五个方面，移动客户装置具有如下特征每个存在属性作为包括属性名元素和属性值的项的一部分。属性名元素可以包含表示负责保持属性名元素和属性值唯一性的授权机构的授权机构字符串。
再根据本发明的第三、第四和第五个方面，所述移动客户装置具有如下特征存在集合包括属于与单个存在组相关联的发布人用户的单个发布人角色的一个或多个存在属性。
再根据本发明的第三、第四和第五个方面，所述移动客户装置具有如下特征作为发布人的客户装置用户可以使用所述客户装置或者可以以多个发布人角色来使用多个客户装置。
根据本发明的第六个方面，一种用于移动消息收发系统的服务器，所述服务器包括用于根据接收到的存在属性来维护存在信息的部件，存在信息按照以属性名来标识的多个存在属性类型来分类，其特征在于，所述服务器还包括用于搜索已存储且与接收到的属性含有完全相同的标识符的属性的部件和用于在所接收到的属性的标识符的组合与已存储的属性的标识符组合完全相同时以接收到的属性替换已存储的属性、否则就添加所接收到的属性的部件。
再根据本发明的第六个方面，所述服务器具有如下特征根据与存在组相关联的发布人用户将所述服务器从客户装置接收到的存在属性存储在数据库中。
再根据本发明的第六个方面，所述服务器具有如下特征每个存在属性作为包括属性名元素和属性值的项的一部分。属性名元素可以包含表示负责保持属性名元素和属性值唯一性的授权机构的授权机构字符串。
再根据本发明的第六个方面，所述服务器具有如下特征存在集合包括属于与单个存在组相关联的发布人用户的单个发布人角色的一个或多个存在属性。作为发布人与服务器通信的客户装置用户可以使用所述客户装置或者可以以多个发布人角色来使用多个客户装置。
根据本发明的第七个方面，一种存在系统，包括至少一个物理装置，该至少一个物理装置至少具有一个使存在用户可以作为发布人或订阅户与系统交互的存在客户；以及用于维护供订阅户按照相关存在组来访问的发布人的存在属性集的有效值的服务器。
再根据本发明的第七个方面，所述存在系统具有如下特征每个属性作为包括属性名元素和属性值的项的一部分。所述属性名元素可以包含具有与属性用途有关的信息的限定符。属性名元素可以包含表示负责保持属性名元素和属性值唯一性的授权机构的授权机构字符串。
再根据本发明的第七个方面，所述存在系统具有如下特征存在集合包括属于与单个存在组相关联的单个发布人角色的一个或多个存在属性。作为发布人与系统交互的用户可使用所述存在客户或者可以以多个发布人角色来使用多个存在客户。每个属性可以是包含属性名元素和属性值的项的一部分。
再根据本发明的第七个方面，所述至少一个物理装置是移动物理装置。
根据本发明的第八个方面，一种包含在可存储于物理装置中的计算机可读媒体中的计算机程序，其特征在于，所述程序是存在客户程序，它使存在用户可以作为至少一个存在属性集的发布人与存在系统交互，其中所述至少一个存在属性集可供一个或多个订阅户按照相关的至少一个存在组来访问。
再根据本发明的第八个方面，所述存在客户程序具有如下特征所述程序可使存在用户作为与所属存在组相关的至少一个属性集的订阅户与所述存在系统交互。
再根据本发明的第八个方面，所述存在客户程序具有如下特征每个属性作为包括属性名元素和属性值的项的一部分。所述属性名元素可以包含具有与属性用途有关的信息的限定符。
再根据本发明第八个方面，所述存在客户程序具有如下特征，所述属性名元素包含表示负责保持属性名元素和属性值唯一性的授权机构的授权机构字符串。
再根据本发明的第八个方面，所述存在客户程序具有如下特征存在集合包括属于与单个存在组相关联的单个发布人角色的一个或多个存在属性。作为发布人与系统交互的用户可以使用所述存在客户或者可以以多个发布人角色来使用多个存在客户。每个属性可以是包含属性名元素和属性值的项的一部分。
再根据本发明的第八个方面，所述存在客户程序具有如下特征，所述物理装置是移动物理装置。
根据本发明的第九个方面，具有包含在存储于其中的计算机可读媒体中的计算机程序的物理装置，其特征在于所述程序是根据本发明第八个方面的存在客户程序。
根据本发明的第十个方面，包含在可存储于物理装置中的计算机可读媒体中的数据结构，其特征在于所述数据结构是存在数据库，用于存储供订阅户按照与所述存在集合相关联的存在组来访问的一个或多个发布人的存在属性集合的有效值。
再根据本发明的第十个方面，一种具有如下特征的数据结构每个属性作为包括属性名元素和属性值的项的一部分。所述属性名元素可以包含具有与属性用途有关的信息的限定符。属性名元素可以包含表示负责保持属性名元素和属性值唯一性的授权机构的授权机构字符串。
再根据本发明的第十个方面，存在集合包括属于与单个存在组相关联的单个发布人角色的一个或多个存在属性。
再根据本发明的第十个方面，所述数据结构具有如下特征作为发布人与所述物理装置交互的用户可以使用所述数据结构来发布多个的发布人角色，每个角色具有与不同存在组相关联的不同存在集合。
再根据本发明的第十个方面，所述数据结构具有如下特征，所述物理装置是移动装置。
根据本发明的第十一个方面，一种将数据结构包含在存储于其中的计算机可读媒体中的物理装置，其特征在于所述数据结构是根据本发明第十个方面的存在数据库。
本发明的优点在于可以通过添加限定符来调整预定的存在属性。限定符可以用于添加新属性(因为具有限定符的属性可以被唯一地标识，即功能上与属性名完全相同但不具有限定符的属性区分开来)。因此，例如用户或应用开发商可以容易地确定最适合他们的需求的或描述他们当前状态的新存在属性，而不致局限于预定的类型。限定符的使用带来了另一个优点，即它可以使存在信息的发送者(拥有者)进一步指定在接收客户装置中如何使用该存在信息。
在本发明的一个实施例中，属性所应定址到的应用程序是在限定符中指定的。接收到的属性被寻址到限定符中所指示的应用程序。本实施例的再一个优点是，发送客户装置可以定义所使用的应用程序，从而使用限定符将某个存在信息导向某个应用程序。
本发明的再一个优点是，说明如何在角色范围内单个存在集合中汇编(assemble)具有名称、属性和值的存在项，所述角色具有相关联的权限组，其中的成员有权订阅同一个角色的整个存在集合或其中一部分。
附图简介下文中，将通过优选实施例并参考附图来更详细地描述本发明，附图中
图1是说明移动IMPS系统的方框图；图2是说明存在属性的传送的信令示意图；图3是说明限定符用途的信令示意图；图4显示根据本发明的，包括服务器和至少一个客户装置的移动消息收发系统的一个实施例。
图5显示根据本发明的，包括服务器和至少一个客户装置的移动消息收发系统的另一个实施例。
图6显示根据本发明的存在框架；图7显示根据本发明的存在数据；图8显示根据本发明的取消订阅存在信息的流程图；图9说明根据本发明的存在信息的订阅交付；图10说明根据本发明对用户组和存在集合的管理。
发明的优选实施方式图1说明移动IMPS系统。许多移动客户(MC)可以通过移动网络MNW以及可能的一个或多个中间网络ONW连接到IMPS服务器S。通常将因特网用作中间网络，从而IMPS系统还为非移动客户C提供服务。就存在服务而言，IMPS服务器S可以在功能上划分成多个服务器组成部分作为拥有存在信息的发布客户的归属服务单元的发布服务器PS和作为订阅或请求客户的归属的订阅户服务器SS。因此，客户MC由两个服务器来提供服务；MC将它的存在信息更新到PS，充当发布客户；而另一方面，从订阅户服务器SS请求和接收作为存在属性的与其它客户有关的存在信息。服务器PS维护存在数据并根据用户有关存在信息的发布偏好来管理它的分发。SS和PS的功能可以在一个物理服务器设备上实现，也可以分布到多个服务器设备上。
应该注意的是，本说明书侧重于与存在相关的服务能力。移动IMPS服务的其它重要能力为消息收发能力、用户组管理能力、内容管理能力、订阅户管理能力以及客户能力。移动IMPS服务是利用这些服务能力来创建的。例如，客户MC可能属于几个用户组，服务器S管理组成员，处理即时消息收发和在组的成员之间的传递存在信息。服务器的另一个重要作用是控制信息流；服务器可以根据用户的偏好设有过滤器，例如可以将什么存在信息或其它信息传递给“朋友”组成员、“同事”组成员或向任何客户公开。
各种传输层协议均可采用，而IP协议通常用于提供网络层服务。可以采用不同的低层传输协议。移动网络MNW可以是任何无线网络，如支持GSM服务的蜂窝网络，还支持GPRS(通用分组无线业务)的网络，第三代移动通信网络如UMTS网络(通用移动电信系统)，无线局域网WLAN或专用网。还可以将短距离红外线或无线电连接如BluetoothTM通信用作MC和服务器S之间的部分通信路径。移动客户装置MC可以是例如移动台、PDA设备或包括或连接到无线调制解调器的膝上型计算机。移动IMPS消息可以利用例如电路交换数据呼叫、分组交换数据传输场境、诸如SMS或MMS(多媒体消息业务)的消息收发服务来传送。图2说明存在属性的使用。当移动客户MC已确定201要发布的一个或多个存在属性时，它将存在属性更新202到发布服务器PS中，即发布一个或多个存在属性。存在属性的确定201可以如下方式进行在客户与移动IMPS服务器建立逻辑移动IMPS会话时进行、自动进行或者在一些存在信息改变时由客户主动进行。例如，阶段201可以在预定时间、数据条件下，或因移动客户MC上用户简要信息变更时自动开始。当客户MC(A)访问服务器SS的移动IMPS服务时，它可以请求203有关另一个客户(B)的存在信息。订阅户服务器SS从(客户A的)发布服务器PS请求204此信息。如果(客户B)的发布优选设置允许的话，PS就将一个或多个存在属性发送205到SS。客户B的发布优选设置有可能阻止发送所请求信息的某些部分(到客户A或所有客户)。当客户(A)与SS的服务建立逻辑连接时，SS还可以自动根据(客户A)的用户优选设置请求204存在信息。SS将这些存在属性转发206到接收客户MC(A)。
订阅户服务器SS(和发布服务器PS)通常将源自客户的存在属性不加修改地朝客户发送。但是，在服务器PS中也可以存在一种内容适配机制。内容适配通过与接收客户的客户能力相匹配的方式来解决修改存在属性的问题。除响应客户请求传送存在信息外，还可以根据发布优选设置将存在信息推送给可达到的客户MC(逻辑上连接到服务的客户)。推送型存在通知可以通过三种机制来触发当发布服务器从发布人客户接收到更新内容时，当发布服务器检测到属性值变更时或通过特定于实现的更新属性值的内部触发器来触发。
因此将客户MC配置为将一个或多个存在属性更新到PS中，以便接收和处理207从SS接收到的存在属性，以及将从至少一个存在属性获得的当前存在信息传送给用户。MC最好一直保存存在信息(存在属性值)，直到在用于携带存在属性的更新消息中接收到新的存在属性值(或客户结束移动IMPS会话)时为止。此外，如稍后的更为详细的所述，客户装置可以自动利用接收到的存在信息来相应地调整它的功能。除图2所示的信令外，还可以在将存在属性发送到请求客户之前向存在信息的发布人请求授权。图2未在例如消息202之后显示任何服务器可以响应的状态消息。
源自客户的存在属性是其值字段由发布客户填写的存在属性。源自服务器的存在属性是其值字段由发布服务器填写的存在属性。
源自客户-服务器的存在属性是其值字段的一部分由客户填写，而另一部分由发布服务器填写的存在属性。根据本发明的优选实施例，用户或组织可以除预定属性集之外的新属性。这些存在属性可以划分为如下类别●客户状态描述关于通信的客户的可用性的存在属性；例如网络可达性、GPRS已连接、打开/关闭状态、操作员。因此移动IMPS服务中的属性与用于非移动客户装置的IMPS中的属性有非常大的差异。
●用户状态描述关于通信的用户的可用性的存在属性；例如就绪、开会中、繁忙、离开、接听电话、正在聊天、免打扰。
●本地信息描述用户端的本地环境的存在属性；例如本地时间、嘈杂/安静的环境、室内、户外、(例如基于地理位置的)用户位置、受访的PLMN、城市/街道、场所。例如，可以直接获取移动客户的确切位置作为本地信息属性，可以通过移动客户MC的用户简要信息设置来获得可用性状态(开会中、在避暑别墅等)。
●个人状态描述个人用户状态的各种个人属性；例如情绪、个人兴趣和意图。
●客户能力描述客户装置支持不同通信方式、不同媒体类型以及不同功能的能力的存在属性。
●用户属性允许客户装置或用户定义他们自己的文本存在值和对外部值的引用的存在属性。
●扩展的存在信息供应商专用的或服务供应商以动态方式定义的非标准存在属性，这种属性需要通过标准存在服务器来传送。
因此，对移动客户装置和实际用户可存在不同的存在属性。例如，可以将用户定义为无法接收消息而可以将该用户的客户装置定义为在线。如果采用SMS作为服务承载，还可以将用户定义为可接收消息但不在线。
存在属性的通用结构和标识表1说明存在属性的通用结构。存在属性一般包括标识符部分和多个值字段。Req(要求)字段确定该部分是M必备的、O可选的还是C有条件的。属性信息为XML格式(扩展标记语言)。
表1.存在属性的结构表2中描述了NameSpec元素的子元素。
表2.NameSpec元素属性的名称是信息元素“名称”给定的字符串。表3中定义所有存在属性的名称信息元素。
表3.名称元素表4中说明限定符元素的格式。
表4.限定符元素限定符元素用于指定属性使用范围。可以将限定符特别用于如下两个目的添加新属性或允许存在信息的发送方(发布人)来指定在接收客户装置中如何使用该存在信息。因此，限定符字符串可以用作接收客户装置中的一个或多个应用程序的参数。
例如，如发布人希望将知道他的确切位置(例如街道地址)的人限定为某些用户(称为组A)，而将其近似位置(例如仅仅城市名)提供给其它人(称为组B)，他可以向组B发布含有城市名的位置属性。对于组A，他将限定符(如“我最好的朋友”)附加到位置属性中。这就有效地创建了一个具有以“我最好的朋友”作为限定符的新属性。然后他将街道地址包含在此新属性中并将其发布给组A。因为这些属性是不同的，所以服务器PS可以将它们的值分开。而且，如果某个人同时属于组A和组B，则此人的客户装置可以配置为对这两种属性进行区分。客户装置可以配置为根据该用户所激活的组来提供(以及可能使用)属性。可能的限定符值可以由客户和服务提供者预先指定，或由用户(发布人)动态地进行指配。服务提供者还可以限制动态指配的限定符值的数量。
授权机构元素确定负责保持属性和内容唯一性的机构。这涉及到属性扩展机制。
表5.授权机构元素当不加修改地使用预定存在属性时，可以省略授权机构字符串。使用限定符字符串不是对需要使用授权机构元素的属性进行修改。当引入新的属性(新的名称)或将新的值字段添加到已指定属性中时必须使用它。在这两种情况中，属性均被视为新的，由授权机构负责维护该新属性。
一般来说，值字段名必须在属性内是唯一的。因此，引入新的值字段到现有属性中必须按照定义该属性的机构所设置的规则来处理。添加新的值字段使旧属性转换为新属性。这必须通过授权机构字段的存在来反映这一点，以便使新属性和旧属性共存。属性所有者(stakeholder)有可能释放属性，以便由公众进行维护。此类属性由合适的机构如IANA(因特网地址分配机构)来进行登记，这同样是通过授权机构(authrority)字段来反映的。在此情况下，任何属性所有者无需改变授权机构字段就可以登记附加的值字段。即使服务器(PS、SS)有可能不理解该值字段的语义，也不会从属性中删除值字段。客户MC会忽略掉属性中它不理解的值字段。
元素NameSpec标识属性并使其唯一。图3显示NameSpec元素和限定符的使用实例。确定301客户装置MC1中属性的限定符。有可能由用户来确定限定符或由客户装置MC来确定限定符。可以定义限定符，以便指定期望的用户组，确定在接收客户装置(MC2)中如何显示该存在信息，或说明接收客户装置MC2应该如何使用该属性。在确定限定符时有可能利用移动客户MC的用户简要信息。例如，MC1根据当前的简要信息(例如，开会中)、日程安排项(12:00结束会议)和本地时间来编辑存在属性。利用限定符，可以容易地修改存在属性，以包含许多对接收客户MC2有用的信息。将属性发送302到服务器PS。
PS将接收到的属性与已存储的属性就NameSpec元素进行比较303。PS首先将彼此的授权机构字符串进行比较。不含授权机构字符串的属性与含授权机构字符串的属性是不同的。接下来比较属性名。最后比较限定符字符串。不含限定符字符串的属性不同于任何含限定符字符串的属性。两个属性仅当所有这三项比较得出相同结果才是相同的。因此，可以在功能上将含有限定符的所接收属性与含相同属性名但限定符不同的接收属性区分开来。
发布服务器PS进行这种比较，以确定应该用所接收属性的值字段是替换一些现有的存在信息，还是确认该属性是新属性而应将其添加到MC2的存在信息存储器中。根据比较结果，PS将该信息存储303在所接收的属性中。如果所接收属性的所有标识符与已存储的某个属性的所有标识符完全相同，则PS以所述接收的属性的存在信息替换所述已存储属性的现有信息。否则，PS添加所述接收的属性的存在信息，而不替换任何先有信息。PS将属性发送304到至少一个客户装置MC2(自动推送它或响应来自MC2的请求而发送)。根据一个实施例，限定符确定要将属性导向哪一个组。此外，相应于电话簿中的私人联系方式和办公联系方式，限定符可用于例如以不同方式显示存在信息。因此，PS可以根据限定符来确定接收客户装置。如下在先更为全面地说明客户状态属性、用户状态属性和个人状态属性之后，随后将说明动态电话簿服务的服务能力。
在进行与PS中类似的比较305之后，接收客户MC2同样要确定是否要以及要如何存储所接收到的存在属性的信息。存在属性的这种三重标识使存在属性的使用、管理和创建非常灵活。
限定符可采用许多方式来说明属性在客户装置MC2中的用途。通常客户装置MC可以支持许多应用。根据第一实施例，客户装置MC1添加指定要使用的应用的限定符。应用通常指可以被例如端口号标识的任何应用实体。应用可以是用于在客户装置MC1中处理属性的存在信息的应用程序或其它应用程序。接收客户装置MC2将所接收到的属性寻址305到限定符所标识的应用程序。例如，通过使用限定符，可以将完全相同的存在信息发送到电话簿应用程序和游戏应用程序。这些应用程序可以不同方式利用存在信息，因此还有可能针对应用需求来准确地定制属性。
根据第二实施例，客户装置MC1添加指定属性显示方式的限定符。接收客户装置MC2根据该限定符来显示305所接收到的属性。该限定符可以确定例如将信息全部显示给用户还是只显示部分信息。限定符还可以确定各种用户界面设置，如颜色、字体等。根据限定符中的设置值来配置305 MC2的UI。
客户状态属性根据优选实施例，移动客户MC可利用描述移动客户MC的当前传输能力的存在属性。这种属性的结构如表6所示。称为Modem(调制解调器)属性的这一属性提供有关正在与移动承载交互的用户终端部分或功能的存在信息。
表6.Modem属性结构1.
表7.Modem属性的值字段表8中所示的状态值字段指示移动Modem的状态。
表8.Modem的状态值字段状态值字段指示Modem处于打开或关闭状态。根据优选实施例，存在属性最好在属性的必备状态值字段中包括DIS指示。当属性中设置了DIS时，属性中给出的所有值都是无效的。接收移动客户MC因此可以忽略该属性的值字段。并且将该存在属性的先前值删除(并使之为空)。因此，发送含DIS而不含任何其它值字段的属性是可行的。这种属性需要的空间非常小，因此可以节省无线电接口的临界带宽。这尤其对描述用户属性的属性非常有用。
再参考表7，Modem属性的CommAddr值字段包含调制解调器(MC)的通信地址。它包括两个部分通信方法和联络地址。方法部分携带有关所支持的通信方法的信息，尤其是Modem是否支持分组交换(PS)数据、电路交换(CS)数据或语音、SMS或MMS。联络部分包括地址如MSISDN号。
CS_Status值字段指示Modem的电路交换状态(已登记或未登记)。PS_Status值字段指示Modem的分组交换状态(已连接或未连接)。RoamingStatus值字段指示归属PLMN(公用陆地移动网)，也可能指示Modem当前漫游所在的PLMN。CS_CallStatus值字段给出CS承载(数据或语音；有效或无效)的呼入状态。如果Modem支持多种呼叫功能，则modem属性可能会有这些呼入状态的列表。PDP_Context状态值字段包含有关PDP(分组数据协议)场景的信息，例如QoS(服务质量)信息。
除上述实例外，modem值字段还可用于携带有关移动客户的传输能力的其它信息。在第一实例中，在模式属性中传递移动客户的最大比特率。然后接收客户装置可以配置其传输率，以便不超过最大比特率。在第二实例中，客户装置确定在向客户装置发送数据文件时只使用分组交换传输方式。第三实例是，漫游装置命令仅仅启用某种类型的通信方式(例如只允许语音呼叫，而不发送数据文件)。
用户状态属性根据本发明的一个优选实施例，定义用户参与活动的意愿的属性。活动是由属于此可用性属性的值字段来指定的。表9说明可用性属性的结构。
表9.可用性属性结构表10描述可用性属性的值字段。
表10.可用性属性值表11中所示的状态值字段指示可用性信息的状态。
表11.状态字段状态值字段指示是否允许发布可用性信息。DIS指示可如前所述用于使可用性属性的值无效。例如，服务器PS可以在移动客户MC已关闭移动IMPS会话之后发送含DIS指示的可用性属性。这种信息还可以在与客户的连接突然丢失时发送。因此，接收移动客户可以删除所有与已不在移动IMPS系统中的用户和客户装置有关的可用性信息。
表10中的CommAvail值字段指示用户是否愿意参与任何形式的远程通信。PhoneAvail值字段指示用户是否愿意参与电话呼叫。SMSAvail值字段指示用户是否愿意参与SMS交换。MMSAvail值字段指示用户是否愿意参与MMS(多媒体消息业务)交换。IMAvail值字段指示用户是否愿意参与IM(即时消息)交换。EmailAvail值字段指示用户是否愿意参与电子邮件交换。
表12中说明图像值字段的结构。
表12.图像字段此值字段将图像与可用性属性中除状态、文本或图像字段之外的任何值字段相关联。ContainedImage值字段包含图像，不过图像大小或格式可以加以限制。ReferredImage值字段包含指向具有相关联图像的资源的URL。ValueField值字段定义与图像相关联的值字段。例如，发布人可以将图像与当前具有值“DISC”(意味着例如用户打电话不是很方便)，以便传递与DISC含意有关的图像语义信息。图像值字段在此属性中可以具有多个实例。只要属性中包含此值字段，则同一属性中也就必须包含其目标值字段。当且仅当目标值字段有效时此关联才有效。当使目标值字段更新或失效时，接收客户必须废弃与该属性的任何原有关联。
表13中说明文本值字段的结构。
表13.文本字段文本值字段将一个文本字符串与可用性属性中除状态、文本或图像字段之外的任何值字段相关联。文本值字段在ContainedText中包含文本字符串，在ValueField中包含相关联值字段的名称。ContainedText元素中可以限制文本的大小。例如，发布人可以将文本与当前具有值“NAVL”(例如会议进行到14:00)的值字段PhoneAvail相关联，以传递与NAVL含意有关的附加语义信息。在此属性中，文本值字段可具有多个实例，即同一个文本可以与多个值字段相关联。只要该属性中包含此值字段，同一个属性也就必须包含其目标值字段。当且仅当目标值字段有效时此关联才有效。当使目标值字段更新或失效时，接收客户必须废弃与该值字段的任何原有关联。还可以将图像和文本自动添加到存在属性中。
个人状态属性PersonalStatus(个人状态)属性指示发布人的个人状态。其选项和详细信息由属于此属性的值字段指定。表14说明PersonalStatus的属性结构。
表14.PersonalStatus属性结构表15说明PersonalStatus属性的值字段。
表15.PersonalStatus属性值表16中所示的状态值字段指示PersonalStatus信息的状态。
表16.PersonalStatus属性的状态此字段指示是否允许发布此信息。DIS指示还可以用于PersonalStatus属性。
文本值字段指示自由文本格式的发布状态。情绪值字段指示发布人的情绪。时间值字段指示发布人的本地时间。
根据优选实施例，还可以在PersonalStatus属性中利用图像。如表12所示，图像值字段将图像与该属性中除状态或图像字段之外的任何值字段相关联。例如，发布人可以将图像与当前值为“IN_LOVE”的情绪值字段相关联，以传递与IN_LOVE含意有关的图示语义信息。图像值字段可以与可用性属性中所述相似的方式使用。
本发明可以在现有客户装置和服务器中实现。它们均具有可以利用来实现所述创新功能的处理器和存储器。可以从内部或外部存储器将计算机程序装入到服务器或客户装置的处理器中，当在处理器中执行时，实现所述创新功能。还可以采用硬件方式或软件硬件组合方式来实现。
图4显示根据本发明的与服务器404通信的客户装置402。客户装置可以类似于图1中所示的一个或多个移动客户或非移动客户，或图2和3中所示的任何其它移动客户。同样地，服务器404可以类似于图1所示的服务器或图2和3所示的任何其它服务器。客户装置402包括用于将存在信息作为存在属性在信号线408上发送到服务器或向服务器请求它的部件。发送存在信息对应于例如图3中的步骤302，其中存在属性从MC1被发送到PS；或对应于图2中的步骤202，其中MC更新存在属性并将其发送到PS。在信号线408上进行的请求存在信息的操作对应于图2中的请求步骤203，其中MC从SS请求存在属性。信号线408上从客户装置402到服务器404的传输可类似于图1所示从移动客户(MC)经中间网络ONW通过移动网络(MNW)到IMPS服务器的传输路径。或者，它还可以类似于从非移动客户C通过中间网络ONW到服务器S的路径。当然，也可设想其它可能的路径，本发明并不取决于物理媒介路径或所用物理媒介的组合路径。客户装置402还包括用于在信号线412上接收来自服务器404的存在属性的部件410。这种存在信息按照属性名所标识的多个存在属性类型来分类。
服务器404包括用于接收/发送属性和根据所接收的存在属性维护存在信息的部件414。
根据本发明，客户装置402另外还包括用于将限定符添加到存在属性中的部件416，其中所述限定符包含一个或多个说明属性用途的参数。将所添加的限定符送到信号线418上，以便由部件406通过线408将其传送到服务器404。这可以通过部件420来实现，部件420根据从信号线442上接收到的来自应用程序424的指令来确定存在属性。该应用程序也可以利用部件420来请求存在属性。在任何一种情况中，可以由部件420经信号线426向部件406提供信号，以便通过信号线408传送或请求存在属性。如果部件416已经添加了限定符，例如在根据图2的步骤202更新存在属性时，则信号线408上的信号将包含具有一个或多个说明属性用途的参数的限定符的存在属性。
为了处理经信号线412输入的来自服务器404的存在属性，客户装置402还将包括用于根据所接收到的属性中的限定符参数来处理从信号线412上接收到的来自服务器404的存在属性的部件428。从信号线412上接收到的存在属性可由部件410接收，并经信号线430提供给部件428，由其对所接收到的属性进行处理。处理之后，部件428可以通过信号线432将信号提供给应用程序424，以供该应用程序后续使用。
添加限定符416的部件可以包括部件434，用于在限定符中指定属性的显示设置，以便从服务器404接收该属性的客户可以根据该显示设置来显示属性。因此，客户装置(如图4所示的客户装置402)将包括部件436，此部件436根据由另一个客户装置指定的以及通过信号线412接收到的来自服务器404的此类限定符来显示所接收到的属性。
同样地，部件416可以包括部件438，用于在要发送到服务器404的限定符中指定属性在接收客户中所应寻址到的应用程序。对于接收指定属性所应寻址到的应用程序的限定符的这种客户装置402，还要有部件440，用于解释从信号线430上接收到的此类属性，以便将接收到的属性寻址到限定符所指示的应用程序。
现在对服务器404作更详细的说明，服务器404还可以包括部件444，用于根据限定符判断是否要将属性发送到一个或多个客户装置，如服务器的存在数据库中的存在组所指定的客户装置。此类判断还可以根据授权来进行，所述授权是由提供此类授权的部件448经信号线446来提供的。如果限定符和授权指示该属性应该发送到一个或多个客户装置，则服务器404就会这样做，例如发送到客户装置402以及适当的类似部件。
可能的情况是，根据服务器已知的信息，针对某个特定客户的存在属性可能不匹配该客户的能力。这种信息可以由例如部件444经信号线450提供给部件452，由部件452对存在属性进行修改以便匹配该客户的能力。经过修改的属性会经信号线450返回到部件444。另一方面，如果存在属性是根据“推送”技术来提供的，则通过信号线454将经过修改的存在属性提供给部件456，它可以采取相应的步骤将该经过修改的存在属性推送到该客户或多个适当的客户。可以通过例如信号线458以信号方式将这一点通知给部件444。
本专业的技术人员显然应该认识到，图4所示的功能块可以利用分离硬件、专用集成电路、微控制器、软件、固件等来实现。而且，附图中不同功能块所提供的功能不必是分离的，而是可以通过在/从其它功能块中随意增加/减少一些功能而结合到其它块中。同样地，可以按各功能块的顺序和它们的相互关系对它们之间的配合关系加以修改，而同时仍然取得与上述完全相同的最终结果。还应该认识到的是，根据本发明，图4所示的客户装置和服务器装置的细节可以采用与所示的那些类似的其它形式。本发明的其它方面可以以相似但绝不是完全相同的方式来加以说明。
例如，图5显示客户装置502用与图4所示部件420类似的部件506与服务器装置504通信，部件506用于通过信号线508将存在信息作为存在属性传送到与图4中服务器404内的部件414类似的部件510，以便由部件510在服务器504内接收和维护存在属性，。同样地，客户装置502可包括部件512，用于经信号线514从服务器504的部件510接收表示存在信息的存在属性。类似于图4中客户装置402的部件420和416，图5的客户装置502可包括部件516，用于编辑以授权人、属性名和限定符的组合来标识的存在信息属性；所述授权人指定负责维护属性的机构而限定符说明属性的用途。如此编辑的属性可通过信号线518提供给部件506，以便通过信号线508传送到服务器504，如图所示。服务器504可以包括部件520，它响应通过信号线522从部件510接收到的编辑属性，搜索含有相同的授权人、属性名和限定符组合的已存储属性。如果所接收的属性的标识符组合与已存储的属性(例如存储在存储装置524中的属性)的标识符组合完全相同，则通过信号线526用接收到的属性来替代所述已存储的属性。这样，如果属性参数已经改变，则在存储装置524中存储更新的参数。否则，将所接收到的属性作为新属性添加到存储装置中。此功能可以如上所述在部件520中执行，或在完全不同的部件528中执行，部件528通过信号线530从部件520接收所接收到的属性，它包括如下功能如果标识符组合相同，则以接收到的属性替换已存储的属性，否则通过它与存储装置524之间的连接线532添加所接收到的属性。
客户装置502包括与刚才所述类似的功能，例如如部件540和部件542所示，部件540通过信号线542从部件512接收输入属性并搜索包含与所接收属性含有相同标识符的已存储属性，而部件542用于在所接收属性的标识符组合与已存储属性的标识符组合完全相同时以接收的属性替换已存储的属性、否则就将所接收到的属性添加到存储装置544中。用于搜索的部件540中可以包括部件542，或者也可如图所示将它们分开。在后一种情况中，信号线546将与接收属性相关的属性信息从部件540提供给部件542。存储装置544可以通过信号线548与部件542双向通信以便替换或添加属性，以及通过信号线550与部件540双向通信以便搜索已存储的属性。
根据上文所述，下文将描述本发明的动态电话簿服务实施例的服务能力。动态电话簿服务可以视为多功能呼叫服务(rich callservice)。它“在呼叫前”很有用，用于使显示给A方的B方存在信息多样化。在此情况下，B方为一个或多个用户电话簿条目。可以如上所述那样将存在信息划分成相同的类别，即(1)客户可用性；(2)用户可用性；(3)本地情况；(4)个人状态；(5)客户能力；(6)用户属性；以及(7)扩展的存在服务。
从概念上来说，存在系统由如下单元构成存在客户602、604、606；存在用户608、610、612；存在用户角色614、616、618、620、622、624；存在代理626和存在服务器628、630，如图6所示。存在客户是可使用户与存在系统进行交互的软件或程序。用户是利用存在客户与存在系统进行交互的人。物理装置632、634如移动手机或PC可具有一个存在客户606，或者在特殊的情况下可具有多个存在客户602、604。存在客户为单个用户所拥有。用户可具有多个客户，但这些客户通常位于不同装置中。
概念上将用户608、610、612划分为发布人和订阅人。发布人是存在信息的创建者。订阅人是存在信息的接收者。用户可以既是他自己的存在信息的发布人，同时又可以是一些其它发布人的存在信息的订阅人。用户可具有一个或多个角色。发布人角色与称为存在集合的一组存在值相关联。同一个用户的两个不同存在集合的存在值彼此不相关，且与不同的角色相关联。订阅人角色是同一发布人角色(即同一个存在集合)的存在信息的逻辑接收者。
存在代理626是可选的网络单元，它用于提高存在服务的可扩展性。代理临时存储从发布人上行传送到服务器或从服务器下行传送到订阅人的不同存在集合的存在值。当客户联机时，代理可以用当前存在信息更新客户。而且当发布人将新的存在值发送到服务器时，代理会更新所有已在该代理上登记的订阅客户。代理可以仅仅临时性地高速缓存存在值。甚至当存在信息来自发布人时，代理不能假设对此存在信息的所有更新正在通过同一个代理进行。如果代理不知道与存在集合相关联的订阅人组，则该代理会向服务器请求此信息。
存在服务器628、630是维护与各存在集合关联的组有关的有效存在值和信息的网络单元。服务器直接或通过代理与存在客户通信。服务器通知代理有关代理所高速缓存的存在值的有效期。当有效期满时，代理必须废弃这些值或从服务器对它们进行刷新。服务器通过监视存在值变更的频繁程度，按存在项为各项指定有效期。有效期是动态的，即它可在存在项的生存期间发生变化。
存在服务器还与其它存在服务器交换存在信息，如图6所示。例如，如果发布人和订阅人在管理上属于不同存在服务器，则存在信息必须通过这两个服务器。如果服务器是不兼容的，则需要在其中一个或两个服务器上设置网关功能。
图7显示根据本发明的存在数据库702的结构。一个存在项704具有三个属性名称708、属性710和值712。存在集合714由一个或多个存在项构成。存在集合714属于用户的单个角色716。对于一个角色，不能有多于一个的存在集合。除此之外，存在属于单个角色716的单个权限组718。权限组由有权订阅同一个角色的全部或部分存在集合的成员构成。
存在集合中的项704、720、...、722是唯一的，即可以将它们彼此区分开来。这些项彼此主要是通过它们的名称来区分。如果存在集合包含两个或多个名称相同的项，则各项中必须有携带这些项的ID的属性。组718的成员724、726、...、728是唯一的。同一个发布人734的不同角色716、730、...、732中的不同存在集合可以包含具有相同名称或相同ID的项。不同的组同样可包含相同的成员。
角色716可以由角色ID、组ID或存在集合ID来标识。例如，组ID可以由服务提供者来分配，它在服务提供者域内是唯一的。因此，存在数据库中将会需要如下ID来对个体元素进行寻址GroupID(组标识符)，ItemName(项名)如果存在集合包含相同名称ItemName的多个项，则必须指定ItemID属性。
注意，不需要UserID、DeviceID和ClientID等ID。
A.示范存在协议A.1.0取消订阅存在信息(图8)可以通过向存在服务器发出查询而个别地从消息服务获取用户的存在信息，例如如图2中步骤203、204、205和206中的消息流所示，或者可以如图9所示通过订阅和接收存在项或者可以如图8所示通过获取存在项而个别地从消息服务获取用户的存在信息。
存在服务的用户可以在任何合适的时间通过发送图8所示的更新存在信息的消息来更新他的存在信息。如上所述，用户可以发出获取存在信息消息来请求某个其它用户的存在信息，如图8所示。存在信息被传递回到请求用户。
发布人可以仅部分地更新他的存在信息。同样地，用户可以仅请求部分存在信息。
如果用户对所请求的存在信息未获得所需的授权，则向该用户发送空内容。
通过将给定的用户包括在存在集合所对应的组中，可将该存在信息授权指给定用户。对此，将在以下题为“存在数据库的管理”的部分中加以说明。
A.1.1 UpdatePresence(更新存在信息)方向存在客户->存在服务器内容模型(TransactionID，GroupID，Presence)属性无用途此原语更新存在服务器上的一个或多个存在项的值。所要更新的存在项在信息元素Presence(存在信息)中携带。如果Presence中有对应于给定的GroupID(组标识符)的项而服务器中不存在该项，则服务器为这些新项分配存储空间，并从消息中复制其内容。否则，服务器以新的值替换旧的值。
该内容中无需有UserID(用户标识符)或PublisherID(发布人标识符)。发布人和含UpdatePresence原语的XML文档之间的关联是在鉴权协议中设定的。
A.1.2 TransactionID(事务标识符)内容模型(#PCDATA)属性无用途它是将从客户到服务器的请求与从服务器到客户的对应响应相关联的唯一标识符。客户在获得第一个响应之前可向服务器发送多个请求。第一个响应并不一定对应于第一个请求。因此需要一种将请求与响应关联起来的机制。通常TransactionID是序列号。它由客户在请求中指定而由服务器在响应中使用。
A.1.3GroupID内容模型(#PCDATA)属性无用途此ID在服务提供者域内唯一地标识包含权限组和存在集合的发布人角色。它由存在服务提供者指定。
A.1.4 UpdateStatus(更新状态)方向存在服务器->存在客户内容模型(TransactionID，StatusCode)属性无用途此原语是存在服务器对客户UpdatePresence请求的响应。StatusCode(状态码)可取如下值不支持、新分配、成功、失败。
A.1.5 GetPresence(获取存在信息)方向存在客户->存在服务器内容模型(TransactionID，((GroupID，PresenceNames？)*)|PresenceNames？)属性无用途此原语用于向存在服务器请求存在信息。可能有零个或多个GroupID。每个组可以加上可选的PresenceNames(存在项名称)。当未使用GroupID时，请求的范围是该用户所属的所有组。服务器按照鉴权协议将请求用户的标识与请求相关联。稍后在本文档定义PresenceNames。它按照名称列出要从中请求值的存在项。它是可选的。它或者可与GroupID联合使用，或者在未列出任何GroupID时单独使用。当与GroupID联合时，服务器将存在项的搜索限制为给定组。当不存在时，则请求所有存在项的值。
A.1.6 PresenceItems方向存在服务器->存在客户内容模型(TransactionID，StatusCode，(GroupID，Presence)*)属性无用途此原语提供所请求的存在项的列表以及请求的结果状态。元素Presence是对应于给定GroupID的存在集合，稍后在本文档中定义。StatusCode可取如下值未授权、项目不可用、成功、失败。
A.2.0 Subscribed Presence(订阅存在信息)(图9)交付存在信息的另一种机制是订阅某人的存在信息。此消息流如图9所示。
请求用户向存在服务器发送订阅存在消息A.2.1来订阅某人的存在信息。
当订阅存在信息完成时，请求用户最初将接收到新的存在信息A.2.2，而当对方更新其存在信息时总会接收到新的存在信息。
当请求用户不再想要接收该存在信息时，他可以取消订阅A.2该存在信息。或者，可以订阅该存在信息到一段时间，从而不需要取消订阅。
请求用户可以只订阅存在信息中他有权获得的那部分存在信息。
A.2.1 SubsPresence方向存在客户->存在服务器内容模型(TransactionID，SubsPeriod？，((Group，PresenceNames？)*)|PresenceNames？)属性无用途此原语用于订阅订阅人有权订阅的发布人角色的存在信息。可选项GroupID指定所订阅的发布人角色。当没有GroupID时，订阅订阅人有权限的所有角色。各GroupID可以与PresenceNames相关联，以将组内的订阅项限定为PresenceNames中所列出的那些。可选项SubsPeriod(订阅期限)指定订阅的时间长度。当没有它时，订阅会持续到调用对应的UnsubsPresence原语或服务提供者终止订阅为止。PresenceNames指定从获得授权的集合订阅的存在项。当没有它时，订阅存在集合(GroupID)内所有用户获授权的存在项。当不联合Group而单独使用时，则订阅所有获授权的组中指定的项。稍后在本文档定义PresenceNames。
订阅人的标识可在鉴权协议中找到。
A.2.2 SubsPeriod(订阅期限)内容模型(#PCDATA)属性无用途它定义订阅期间的长度。时间单位是TBD。或者其内容也可以指示订阅结束的日期。
A.2.3 PushPresence(推送存在信息)方向存在服务器->存在客户内容模型(GroupID，Presence)+属性无用途此原语将发布人修改过的已订阅存在项推送给用户。GroupID标识角色。
A.2.4 UnsubsPresence(取消订阅存在信息)方向存在客户->存在服务器内容模型(TransactionID，((GroupID，PresenceNames？)*)PresenceNames？)属性无用途此原语用于取消存在信息的订阅。可以将订阅终止限定于指定组，还可以限定于指定的存在项。当没有给出GroupID时，可能将订阅终止限定于所有组中指定的项。当没有GroupID和PresenceNames时，终止该用户的全部订阅。
A.2.5 SubsStatus(订阅状态)方向存在服务器->存在客户内容模型(TransactionID，StatusCode，(Group，PresenceNames)*)属性无用途此原语返回取消订阅操作的StatusCode，并列出仍在订阅的存在项和组。StatusCode可以有如下的值不支持、非订阅项、成功、失败。
A.3.0.存在数据库的管理存在用户可以在存在服务器上管理他的用户组和存在集合。
利用CreatePresGroup(创建组)消息A3.1创建包含用户组和存在集合的角色。存在服务器将以PreGroupStatus(存在组状态)消息A.3.6作为应答，它指示所请求的操作的状态和所创建的组的ID。PresenceInfo(存在信息)消息A.3.7发送到组的各成员，表示他们有权获取或订阅的存在项。
存在用户可以利用GetPresGroupStatus(获取存在组状态)消息A.3.8来请求组信息。组信息请求限于组的拥有者。
拥有用户组的存在用户可以添加和删除组的成员或存在集合的存在项。
发布人可以通过发送消息DeletePresGroup(删除组)来删除组。
A.3.1 CreatePresGroup方向存在客户->存在服务器内容模型(TransactionID，MemberList，Presence)属性无用途此原语请求存在服务器在该服务器中创建角色。权限组包含memberlist(成员列表)中的成员，Presence中包含存在集合。
A.3.2 MemberList内容模型(MemberDescription)+属性无用途成员列表。由用户创建描述内容。
A.33 MemberDescription(成员描述)内容模型(UserOriginatedMD？，ServerOriginatedMD？)属性无用途用户创建部分是用户所看到的成员描述。服务器创建部分是存储在服务器数据库中的成员描述。
A.3.4 UserOriginatedMD内容模型(#PCDATA)属性无用途这是用户创建的标识某个人的方式。它可以是名称、目标人的电话之一的MSISDN、电子邮件地址、SIP地址等。或者它还可以为它们的组合。描述的数据格式不属于本文档的范围，但应该是采用已知的格式如vCard。
A.3.5 ServerOriginatedMD内容模型(#PCDATA)属性无用途这是服务器创建的标识某个人的方式。它可以是名称、目标人的电话之一的MSISDN、电子邮件地址、SIP地址等。或者它还可以是服务器数据库中所存储的那些方式的组合。描述的数据格式不属于本文档的范围，但应该是采用已知的格式如vCard。
A3.6 PresGroupStatus方向存在服务器->存在客户内容模型(TransactionID，StatusCode，(Group，MemberList，PresenceNames)*)属性无用途此原语返回当前存在的发布人角色的GroupID以及该角色的组成员和存在项的名称。如果操作成功，服务器就为新角色分配了一个新的GroupID。服务器已经填写了memberlist的服务器创建部分。这允许发布人验证组是否包含正确的成员。服务器不应该在memberlist中提供超出用户创建部分中现有的层次或唯一地标识一个人所要求的层次的任何保密或个人信息。这是TBD。StatusCode可以取如下值不支持、未知成员、未知存在项、成功、失败。
A.3.7 PresenceInfo方向存在服务器->存在客户内容模型(Group，Presence？)+属性无用途此原语向权限组通告新的存在项。该消息包含指定权限组的所有存在项-包括订阅的和取消订阅的。如果组成员发生变化，则将此消息发送给组中的新成员，或者，如果已添加了新的存在项，则将此消息发送到组中的所有成员。发送此消息以删除组成员，以便不存在与GroupID相关联的存在集合(Presence)。
A.3.8 GetPresGroupStatus方向存在客户->存在服务器内容模型(TransactionID，Group*)属性无用途此原语向服务器请求PresGroupStatus消息。用户只可以从其所属组请求信息。GroupID将该信息限定于给定的组。当不存在GroupID时，从请求者所拥有的所有组返回状态。
A.3.9 AddMembers(增加成员)方向存在客户->存在服务器内容模型(TransactionID，(GroupID，MemberList)+)属性无用途此原语请求服务器将指定的成员添加到给定的组中。
A.3.10 RemoveMembers(删除成员)方向存在客户->存在服务器内容模型(TransactionID，(GroupID，MemberList)+)属性无用途此原语请求服务器将指定的成员从给定的组中删除。用服务器创建的信息填写MemberList。
A.3.11 DeletePresGroup(删除存在组)方向存在客户->存在服务器内容模型(TransactionID，GroupID*)属性无用途此原语请求服务器删除一个或多个发布人角色。GroupID标识要删除的角色。当没有给出GroupID时，则删除所有发布人角色。
A.3.12 AddPresence(增加存在项)方向存在客户->存在服务器内容模型(TransactionID，(GroupID，Presence)+)属性无用途此原语请求服务器将指定的存在项添加到指定角色中。
A.3.13 RemovePresence(删除存在项)方向存在客户->存在服务器内容模型(TransactionID，(GroupID，Presence？)+)属性无用途此原语请求服务器从指定角色中删除指定存在项。当没有与GroupID相关联的存在项时，就从该角色删除所有存在项。
A.3.14代替客户变更发布人或订阅人可以随时变更他的客户。通常客户装置也会发生改变。在很少的情况中，用户仅改变同一装置中的客户实例。新装置可能是TE和旧的MT，反之亦然。切换到新的MT也是可能的。客户变更需要用户将他的存在数据从旧的客户复制或同步到新的客户中。就发布人而言，可能会有一些特定于客户的存在数据，这些数据对于给定的客户是静态的，因而不被包含在同步集合中。同步可以在本地进行，也可以通过网络来进行。在任何情况下，都应该采用现有的同步协议。这不属于存在协议的范围。
订阅客户变更所带来的另一个问题是，将新客户登记为接收存在相关的推送消息的活动客户。登记可以自动方式(无需用户确认)、半自动方式(需要用户确认)或手动方式(用户必须发起登记)进行，具体视如下情况而定-用户在同一个装置中激活新客户(自动)；-用户SIM切换到新装置中(自动)；-用户在新装置中使用不同的SIM，但只有该新装置开机(半自动)；或-用户在新装置中使用不同的SIM，而新装置和旧装置同时开机(手动)。
在任何一种情况下，登记都可以由低层协议来处理。例如如果SIP协议是选中的传输协议，则该协议也可用于登记。
A.4.0存在协议的DTD
<pre listing-type="program-listing"><![CDATA[＜！--Root element--＞＜！ELEMENT PresProtocol(UpdatePresence|UpdateStatus|GetPresence)PresenceItems)SubsPresence|PushPresence|UnsubsPrecence|SubsStatus|CreatePresGroup|PresGroup Status|PresenceInfo|GetPreGroupStatus|AddMembers|RemoveMembers|DeletePresGroup|AddPresence|RemovePresence)>＜！ATTLIST PresProtocol Version NMTOKENS#REQUIRED＞＜！ELEMENT UpdatePresence(TransactionID，GroupID，Presence)>＜！ELEMENT TransactionID(#PCDATA)＞＜！ELEMENT GroupID(#PCDATA)＞ ＜！ELEMENT Presence(#PCDATA)＞＜！ELEMENT UpdateStatus(TransactionID，StatusCode)>＜！ELEMENT StatusCode(#PCDATA)＞＜！ELEMENT GetPresence(TransactionID，((GroupID，PresenceNames？)*)|PresenceNames？)>＜！ELEMENT PresenceNames(#PCDATA)＞＜！ELEMENT PresenceItems (TransactionID，StatusCode，(GroupID，Presence)*)>＜！ELEMENT SubsPresence(TransactionID，SubsPeriod？，((GroupID，PresenceNames？)*)|PresenceNames？)>＜！ELEMENT SubsPeriod(#PCDATA)＞＜！ELEMENT PushPresence((GroupID，Presence)+)>＜！ELEMENT UnsubsPresence(TransactionID，((GroupID，PresenceNames？)*)|PresenceNames？)>＜！ELEMENT SubsStatus(TransactionID，StatusCode，(GroupID，PresenceNames)*)>＜！ELEMENT CreatePresGroup (TransactionID，MemberList，Presence)>＜！ELEMENT MemberList((MemberDescription)+)＞＜！ELEMENT MemberDescription(UserOriginatedMD？，ServerOriginatedMD？)＞＜！ELEMENT UserOriginatedMD(#PCDATA)＞＜！ELEMENT ServerOriginatedMD(#PCDATA)＞＜！ELEMENT PresGroupStatus(TransactionID，StatusCode，(GroupID，MemberList，PresenceNames)*)＞＜！ELEMENT PresenceInfo((GroupID，Presence？)+)>＜！ELEMENT GetPresGroupStatus(TransactionID，GroupID*)>＜！ELEMENT AddMembers(TransactionID，(GroupID，MemberList)+)＞＜！ELEMENT RemoveMembers(TransactionID，(GroupID，MemberList)+)>＜！ELEMENT DeletePresGroup(TransactionID，GroupID*)＞＜！ELEMENT AddPresence(TransactionID，(GroupID，Presence)+)＞＜！ELEMENT RemovePresence(TransactionID，(GroupID，Presence？)+)>＜！--End of DTD--＞]]></pre>B.示范存在内容格式如上所述，存在内容可以划分为如下类别客户可用性存在属性，用于描述客户关于通信的可用性，例如，网络可达到性、已连接GPRS、开机/关机状态。
用户可用性存在属性，用于描述用户关于通信的可用性的存在属性，例如，准备就绪、会议中、繁忙、离开、接听电话中、聊天、免打扰等。
本地情况描述用户所在本地环境的存在属性，例如本地时间、嘈杂/安静的环境、室内、户外、(例如基于地理位置的)用户位置、受访的PLMN、城市/街道、场所。
个人状态描述个人用户状态的各种个人属性，例如情绪、个人兴趣和意图。
客户能力描述客户能力的存在属性，例如是否支持不同的通信方式、不同的多媒体类型以及不同功能。
用户属性允许客户或用户定义它们自己的文本存在值和对外部值的引用的存在属性。
扩展的存在服务服务供应商以动态方式定义非标准存在属性，不过它们需要标准存在服务器和代理来传送。
B.1.设计目标目前有大量的存在通信将存在项的值部分变化传送给订阅人。通常只有一个值发生变化。为了将传输数据量降至最小，设计目标是使存在项的层次化结构表示尽可能扁平。为此，将存在项的范围归于上述存在类别下。另外，这些类别可以在存在项中作为可选属性给出。
D.2通用属性存在项包含各种各样的属性，其中大多数可用于任何存在项中。
D.2.1版本内容语法NMTOKENS必备性是用途它提供存在内容格式的版本D.2.2类别内容语法NMTOKEN必备性否用途它指示属性所属的类。
可能的值为CLIENT_AVAILABILITY、USER_AVAILABILITY、LOCAL_CONDITIONS、PERSONAL_STATUS、CLIENT_CAPABILITIES、USER_ATTRIBUTES、EXT_PRES_SERVICE。
D.2.3ID内容语法PUBIDLITERAL必备性否用途这是指定存在项的唯一ID。它由客户来分配。
D.2.4 Cacheability(可高速缓存性)内容语法NMTOKEN必备性否用途它指示存在项是否可以由代理加以高速缓存。可能的值有YES和NO。它由客户赋值。如果没有此属性，则取值为NO。
D.2.5 ValidityPeriod内容语法NMTOKEN必备性否用途它是高速缓存的存在项的有效期。它的值是以秒计算的时间。它由存在服务器指定。
D.2.6 DeviceName(装置名称)内容语法NMTOKEN必备性否用途它是客户装置的名称。它由客户指定。
D.2.7 Accuracy(精度)内容语法NMTOKEN必备性否用途它是定位装置的精度。它以米计。
D.2.8 ImageType(图像类型)
内容语法NMTOKEN必备性否用途它是图像的内容编码。一些可能的值为JPEG、GIF、BMP。
D.2.9 SoundType(声音类型)内容语法NMTOKEN必备性否用途它是用于对声音进行编码的声音编解码器的类型。一些可能的值为AMR、EFR、MP3、AAC、MIDI。
D.2.10 ExtRef内容语法PUBIDLITERAL必备性否用途它是给出外部引用的URL。
D.2.11 ExtRefChange内容语法NMTOKEN必备性否用途它指示外部引用的内容已发生变化。可能的值为YES、NO。
D.2.12 ContentChange内容语法NMTOKEN必备性否用途它是从0到255的计数器，表示内容值的变化。服务器或代理可以存储最近32个值的内容(但并不要求)。
最近32个值中两个内容的相同值应该对应于相同的内容。
D.3客户可用性
D.3.1 DeiceOn内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod、DeviceName用途它给出用户终端的开机/关机状态。发布人利用组管理消息将此项添加到服务器的角色中。随后，由网络来维护其值部分。用户在其存在信息中可拥有多个终端。在此情况下，使用ID属性是必需的。其内容可取值“ON”或“OFF”。当用户终端开机，但位于网络覆盖范围之外时，网络将此项指定为“OFF”。
D.3.2 DeviceRoaming内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod、DeviceName用途它向订阅人指示发布人正在受访网络中漫游。用户在他的存在信息中可能拥有多个终端。在此情况下，使用ID属性是必需的。其内容可取值“YES”或“NO”。
D.3.3 NetworkType(网络类型)内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod、DeviceName用途它指示发布人当前所连接的移动网的类型。其内容可取值“2G”、“3G-99”、“3G-R4”或“3G-R5”。用户在他的存在信息中可具有多个终端。在此情况下，使用ID属性是必需的。
D.4用户可用性D.4.1 UserStatus(用户状态)内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod
用途它指示发布人根据所愿意接受的被打扰程度而设定的当前状态。定义了如下值“可用”、“安静”、“车内”、“繁忙”。
D.4.2 PreferredContact(优选联络方法)内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod用途它表示发布人的当前优选联络方式。定义了如下值“PHONE(电话)”、“VOICE_MESSAGE(语音消息)”、“MESSAGE(消息)”、“MAIL(电子邮件)”、“NO_CONTACT(不联络)”。
D.4.3 PreferredDefaults(优选缺省)内容模型((TimePeriod，PrefCont)*)属性类、ID、Cacheability、ValidityPeriod用途它是发布人可以发送到存在服务器的元存在信息。该信息像其它存在信息一样与角色相关联，但是此项不可为订阅人获得。相反它控制元素“PreferredContact”的值。它指定给定时限内缺省的优选联络方式。用户指定的时限可以重叠，或者一个时限甚至可以完全包含另一个时限。服务器在给定时限到期时根据PreferredDefaults来改变PreferredContact元素的值。但是这样不会妨碍用户直接改变PreferredContact值。同样，直接改变PreferredContact值的用户在时限到期时也不会妨碍服务器改变它。用户可以将含空内容的这一元素发送到服务器，从而删除此缺省机制。
D.4.4 TimePeriod(时限)内容模型(PeriodStart，PeriodEnd，RepetitionPeriod？，PeriodPrecedence)
属性无用途它描述期间的开始，例如起始时间；期间的结束，例如结束时间；重复期间，例如“DAY”以及期间的优先级。
D.4.5 PeriodStart内容模型(#PCDATA)属性无用途它是期间起始时间。它可以是时间、Time-DayofWeek(以某星期几来计的时间)、Time-DayofMonth(以几月几号来计的时间)或完整的日期。
D.4.6 PeriodEnd内容模型(#PCDATA)属性无用途它是期间结束时间。它可以是Time、Time-DayofWeek、Time-DayofMonth或完整的日期。分解度必须与PeriodStart中设定的分解度相同。
D.4.7 Repetition Period内容模型(#PCDATA)属性无用途它指定重复期间。它必须是如下值的中的一个“DAY”、“WEEK”、“MONTH”。当期间描述中未包含此元素时，就假定不采用重复。
D.4.8 PeriodPrecedence内容模型(#PCDATA)属性无用途此元素解决重叠期间之间的冲突。它可以是0至9之间的数字。数字0具有最高优先级。当两个或多个期间重叠时，服务器采用与最高优先级值相关联的优选联络方式。
D.4.9 PrefCont内容模型(#PCDATA)属性无用途它指示发布人的与期间相关联的缺省优选联络方式。它可以具有与元素“PreferredContact”相同的值。
D.5本地情况D.5.1 LocalTime(本地时间)内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod用途它提供发布人的本地时间。
D.5.2 MeasuredLocation(测定的位置)内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod、Accuracy用途它提供客户装置的测量位置。该测量基于传感器(例如GPS)或网络，抑或基于这两者的组合。属性Accuracy表示所述方法所取得的平均定位精度。其内容至少包括横向位置(x和y坐标)，但是也可以包括纵向位置。如果服务提供者支持如下所述的“ConvertedLocation(位置转换)”，则MeasuredLocation可以是服务提供者转换处理如地图匹配的输入信息。
D.5.3 ConvertedLocation内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod
用途此信息通常源自服务提供者，但是也可以源自发布人。它以人可理解的文本格式如街道名来给出用户位置。该信息是通过(如利用地图匹配)将测量位置通过地图匹配方法转换成此形式而获得的。
D.5.4 StatedLocation(申明位置)内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod用途它是发布人自己所宣称的发布人位置。其内容是简短的文本字符串。
D.5.5 UserEnvironment(用户环境)内容模型(EnvAttributes+)属性类、ID、Cacheability、ValidityPeriod用途它提供有关用户的一些环境属性。
D.5.6 EnvAttributes(环境属性)内容模型(#PCDATA)属性无用途这些属性定义为“INDOOR(室内)”、“OUTDOOR(室外)”、“QUIET(安静)”、“NOISY(吵闹)”、“ALONE(单独)”、“IN_GROUP(在组内)”.
D.6个人状态D.6.1 StatusText(状态文本)内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod用途它是用户可以编写的简短文本(约30个字符)。
D.6.2 Statusimage(状态图像)内容模型(#CDATA)属性类、ID、Cacheability、ValidityPeriod、ImageType用途它是用户可以附加到其状态信息上的图像。它以传输编码的格式(如base64)由XML内容携带。ImageType(图像类型)属性描述该图像的内容编码方式，例如为jpeg。
D.6.3 StatusSound(状态声音)内容模型(#CDATA)属性类、ID、Cacheability、ValidityPeriod、SoundType用途它是用户可与其状态信息附在一起的短时(约5至30秒)声音片段。它以传输编码的格式(例如base64)由XML内容携带。SoundType属性描述该声音的内容编码方式，例如AMR、MP3、AAC、MIDI等。
D.7客户能力存在场景中的客户能力指的是，包含客户的装置的用于进行各种人与人之间通信的能力。这与让应用软件最大限度地利用客户装置的现有硬件和软件能量的情形有很大的不同，且相对简单。
人与人通信的方式有消息收发、电子邮件、语音呼叫和多媒体呼叫。具体来说，通信方式不包括存在信息服务。存在信息服务的目的在于，使其它人知道通信方式以及其它用户的属性，而非双向通信方式本身。因此，使用术语“客户能力”来对存在信息分类可能有点误导。
客户能力的范围是连同网络能力一起来界定的。这意味着例如，仅当发布人的客户装置具有视频呼叫功能并且他正在漫游的网络支持这种能力时，发布人才拥有这种功能。这使客户能力信息不断变化。
D.7.1 MessagingCapabilities(消息能力)内容模型(MessType*)属性类、ID、Cacheability、ValidityPeriod用途它给出客户装置的动态消息收发能力列表。空列表表示当前没有消息收发能力。
D.7.2 MessType(消息类型)内容模型(#PCDATA)属性无用途它给出客户装置的消息收发能力类型。其内容可以取如下类型之一“SMS”、“MMS”或“X-message applicationname(X-消息应用名称)”。字段message application name(消息应用名称)是特定于装置的消息收发方法，例如智能消息收发。
D.7.3 EmailClient(电子邮件客户)内容模型(EmailClientType*)属性类、ID、Cacheability、ValidityPeriod用途它提供客户装置的动态电子邮件能力。空列表表示当前没有电子邮件能力。
D.7.4 EmailClientType(电子邮件客户类型)内容模型(#PCDATA)属性无用途它给出客户装置的电子邮件客户类型。其内容可取如下类型之一“SMTP”、“POP3”、“IMAP4”或“X-mailapplication name(X-邮件应用名称)”。客户软件不应该向用户显示这些邮件协议名。相反，客户软件应该理解用户装置电子邮件环境，并在此电子邮件环境范围内这些名称作出解释。显示给用户的信息还应该是对用户有意义的。
D.7.5 VoiceCallCapability(语音呼叫能力)内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod用途它给出客户装置的动态语音呼叫能力。其内容可取如下值之一“NONE(无)”、“VOICE_CALL(语音呼叫)”、“RICH_VOICE_CALL(多功能呼叫)”。
D.7.6 MultimediaCallCapabilities(多媒体呼叫能力)内容模型(MMCap*)属性类、ID、Cacheability、ValidityPeriod用途它给出用户的动态单向和双向多媒体通信能力。空列表表示当前不存在任何能力。
D.7.7 MMCap内容模型(#PCDATA)属性无用途它给出多媒体呼叫能力的类型。它可以取如下值之一“UPLINK_VIDEO_STREAMING(上行视频流)”、“DOWNLINK_VIDEO_STREAMING(下行视频流)”、“VIDEO_CALL(视频呼叫)”、“RICH_VIDEO_CALL(多功能视频呼叫)”。
D.8用户属性此类包含用户定义的存在数据和特定于客户的存在数据。
D.8.1 UserPresenceItem(用户存在项)
内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod、ExtRef、ExtRefChange用途它给出用户定义他们自己的存在项的方法。如果定义了对应相同角色的多个用户定义存在项，则必需使用ID属性，其内容可以是简短文本。可选属性ExtRef是此存在项所引用的外部对象的URL。该URL可以引用携带存在项的XML文档的多部分MIME(多用途的网际邮件扩充协议)的另一个部分，或者它可以是对外部对象的引用。可选属性ExtRefChange可用于指示其外部对象已变更的订阅人。
D.8.2 ClientTypeRequest(客户类型请求)内容模型(EMPTY)属性类、ID、Cacheability、ValidityPeriod用途它是发布人用于请求其订阅人的客户类型的特殊元素。当发布人将此元素包含在他的给定角色的存在数据中时，服务器用PushPresence(推送存在信息)消息将其发送给该存在信息的所有订阅人。可选的是，它还可以包含在非订阅人所用的用于请求特殊存在项的PresenceItems消息中。此元素不用PresenceInfo消息来通告。它不是可以订阅的存在元素。在首次将此项发送给订阅人之后存在服务器可以周期性地将此项包含在后续的PushPresence消息中，以确保所有的订阅客户都有此项。
当客户接收到此项时，就将它们的客户类型发送到存在服务器。此外，每当此项是存储在客户中的存在信息而激活客户时，客户应该将其类型发送到服务器。
发布人了解其订阅人的客户类型的另一种方式是，发布人订阅他们的客户类型。当然，这是一种不同的商业模式。发布人可能不总是希望成为其自己的订阅人的订阅人。此元素允许发布人在发布人与存在服务提供者之间的现有合约框架内获取客户类型。此外，该方法强制要求订阅客户将其类型发送到服务器。如果发布人采用订阅模式获取客户类型，则由订阅人自行决定是否将此信息授权给该发布人。
D.8.3 ClientType内容模型(ClientName，ClientManufacturer，ClientVersion)属性类、ID、Cacheability、ValidityPeriod用途发布人利用有关订阅客户类型的知识，使得能够对存在集合作特定于客户的扩展。对于来说，如果发布人的订阅客户无法对这些存在项进行解码，则发布人使用这些扩展项没有意义。
订阅客户利用UpdatePresence消息将客户类型信息发送到存在服务器。该消息中所用的GroupID属于发布人的角色，但不属于订阅人的角色。这是只允许用户更新其自身角色的存在信息这一通用规则的例外。存在服务器利用PushPresence消息将此元素的信息发送给发布人。所用的GroupID属于发布人角色。从发布人的观点来看，那么他正在从其自身的存在集合中获取存在信息。
发布人可以将其自身的客户类型包含在其存在集合中。然后，对该信息的处理与其它任何存在信息类似，意味着存在服务器或订阅客户中不会有任何特殊的行为。
D.8.4 ClientName内容模型(#PCDATA)属性无用途此元素给出存在客户应用程序的名称。
D.8.5 ClientManutacture内容模型(#PCDATA)属性无用途此元素给出存在客户制造商的名称。
D.8.6 ClientVersion内容模型(#PCDATA)属性无用途此元素给出客户应用程序的版本。
D.8.7 ClientPresenceItem内容模型(ClientType，CliPresItem)属性类、ID、Cacheability、ValidityPeriod、ContentChange用途此元素是特定于发布人客户应用的存在项。其ClientType是发布人存在客户的客户类型。当ClientType用作此元素的一部分时，在ClientType项中不使用任何属性。如果发布人定义了特定于客户的多个存在项，则必需使用ID属性。可选属性ContentChange是从0到255的计数器。当使用此属性时，每次存在项的内容变化时此接收器就会加1。它为存在服务器提供了检测非标准存在项的内容变化的备选方式。另一种可供选择的方式是，每当以相同ID属性将该项发送到服务器时，存在服务器就认为该项内容改变。当客户不使用ContentChange属性时，服务器就以这种方式操作。当具有相同ID属性的两项在ContentChange中具有相同计数器值时，则这两项的内容相同。
D.8.8 CliPresitem内容模型(#PCDATA)属性无用途此元素是特定于客户的存在扩展项。假定客户而非网元知道它的语法和结构。
D.9扩展的存在服务扩展的存在服务类用于为存在服务提供特定于服务提供商的扩展。与特定于客户应用的扩展一样，只需要服务端点(即发布人和订阅客户)能够对这些扩展项进行解码。可能的情况是，存在服务器也理解这些扩展项，但是本文档不强制要求这一点。特定于客户的扩展方法与本方法的差异在于，服务提供者控制的客户不必实现标准存在项。假定存在项完全由服务提供者定义并且存在用新特征来更新驻留在用户装置中的客户的方法。一种可能的更新方法是空中软件下载。如果服务提供者创建了新类型的存在项，那么他需要更新现有的客户以支持这些新类型。服务提供者控制的客户直接与存在服务器通信，而不通过标准存在客户。标准存在客户忽略此类的所有元素。
扩展的存在服务主要使用此类的元素。也允许使用标准的存在元素定义。它使用标准存在协议。
D.9.1 ExtPresence内容模型(#PCDATA)属性类、ID、Cacheability、ValidityPeriod、ContentChange用途如果通过此机制定义了多个存在项，则必需使用ID属性。
可选的ContentChange属性也可用于此元素。其内容的语法和表示不属于本文档的范围。存在服务器和代理应该允许内容引用与包含此元素的XML文档相同的多部分MIME中携带的对象。
D.10存在内容格式的DTD<pre listing-type="program-listing"><![CDATA[＜！--Root element--＞＜！ELEMENT Presence(DeviceOn)DeviceRoaming)NetworkType)UserStatus|PreferredContact|PreferredDefaults|LocalTime|MeasuredLocation|ConvertedLocation|StatedLocation|UserEnvironment|StatusText|StatusImage|StatusSound|MessagingCapabilities|EmailClient|VoiceCallCapability|MultimediaCallCapabilities|UserPresenceItem|ClientTypeRequest|ClientType|ClientPresenceItem|ExtPresence)>＜！ATTLIST Presence Version NMTOKENS #REQUIRED＞＜！ELEMENT DeviceOn(#PCDATA)>＜！ATTLIST DeviceOnClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDDeviceName NMTOKEN #IMPLIED＞＜！ELEMENT DeviceRoaming(#PCDATA＞＜！ATTLIST DeviceRoamingClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDDeviceName NMTOKEN #IMPLIED＞＜！ELEMENT NetworkType(#PCDATA)＞＜！ATTLIST NetworkTypeClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDDeviceName NMTOKEN #IMPLIED＞＜！ELEMENT UserStatus(#PCDATA)＞＜！ATTLIST UserStatusClass NMTOKEN# IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT PreferredContact(#PCDATA)＞＜！ATTLIST PreferredContactClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT PreferredDefaults((TimePeriod，PrefCont)*)>＜！ATTLIST PreferredDefaultsClass NMTOKEN #IMPLIEDID PUBIDLITEKAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT TimePeriod(PeriodStart，PeriodEnd，RepetitionPeriod？，PeriodPrecedence)＞＜！ELEMENT PeriodStart(#PCDATA)＞＜！ELEMENT PeriodEnd(#PCDATA)＞＜！ELEMENT RepetitionPeriod(#PCDATA)>＜！ELEMENT PeriodPrecedence(#PCDATA)＞＜！ELEMENT PrefCont(#PCDATA)＞＜！ELEMENT LocalTime(#PCDATA)＞＜！ATTLIST LocalTimeClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT MeasuredLocation(#PCDATA)＞＜！ATTLIST MeasuredLocationClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IPLIEDAccuracy NMTOKEN #IMPLIED＞＜！ELEMENT ConvertedLocation(#PCDATA)＞＜！ATTLIST ConvertedLocationClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT StatedLocation(#PCDATA)>＜！ATTLIST StatedLocationClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT UserEnvironment(EnvAttributes+)＞＜！ATTLIST UserEnvironmentClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN# IMPLIED＞＜！ELEMENT EnvAttributes(#PCDATA)>＜！ELEMENT StatusText(#PCDATA)＞＜！ATTLIST StatusTextClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT StatusImage(#CDATA)>＜！ATTLIST StatusImageClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDImageType NMTOKEN #IMPLIED＞＜！ELEMENT StatusSound(#CDATA)＞＜！ATTLIST StatusSoundClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDSoundType NMTOKEN #IMPLIED＞＜！ELEMENT MessagingCapabilities(MessType*)>＜！ATTLIST MessagingCapabilitiesClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLDEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT MessType(#PCDATA)>＜！ELEMENT EmailClient(EmailClientType*)>＜！ATTLIST EmailClientTypeClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT EmailClientType(#PCDATA)＞＜！ELEMENT VoiceCallCapability(#PCDATA)＞＜！ATTLIST VoiceCallCapabilityClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT MultimediaCallCapabilities(MMCap*)>＜！ATTLIST MultimediaCallCapabilitiesClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT MMCap(#PCDATA)＞＜！ELEMENT UserPresenceItem(#PCDATA)＞＜！ATTLIST UserPresenceItemClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDExtRef PUBIDLITERAL #IMPLIEDExtRefChange NMTOKEN #IMPLIED＞＜！ELEMENT ClientTypeRequest(EMPTY)＞＜！ATTLIST ClientTypeRequestClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT ClientType(ClientName，ClientManufacturer，ClientVersion)＞＜！ATTLIST ClientTypeClass NMIOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT ClientName(#PCDATA)>＜！ELEMENT ClientManufacture(#PCDATA)>＜！ELEMENT ClientVersion(#PCDATA)＞＜！ELEMENT ClientPresenceItem(ClientType，CliPresitem)＞＜！ATTLIST ClientPresenceItemClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDContentChange NMTOKEN #IMPLIED＞＜！ELEMENT CliPresitem(#PCDATA)＞＜！ELEMENT ExtPresence(#PCDATA)＞＜！ATTLIST ExtPresenceClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDContentChange NMTOKEN #IMPLIED＞＜！-End of DTD--＞]]></pre>D.11 PresenceNames的DTDPresenceNames的DTD与Presence的DTD基本相同，不同之处在于其中只包含存在项的名称和属性。不使用任何存在值。
<pre listing-type="program-listing"><![CDATA[＜！--Root element--＞＜！ELEMENT PresenceNames(DeviceOn|DeviceRoaming|NetworkType|UserStatus|PreferredContact|PreferredDefaults|LocalTime|MeasuredLocation|ConvertedLocation|StatedLocation|UserEnvironment|StatusText|StatusImage|StatusSound|MessagingCapabilities|EmailClient|VoiceCallCapability|MultimediaCallCapabilities|UserPresenceItem|ClienTypeRequest|ClientType|ClientPresenceItem|ExtPresence)＞＜！ATTLIST PresenceNames Version NMTOKENS #REQUIRED＞＜！ELEMENT DeviceOn(EMPTY)>＜！ATTLIST DeviceOnClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDDeviceName NMTOKEN #IMPLIED＞＜！ELEMENT DeviceRoaming(EMPTY)>＜！ATTLIST DeviceRoamingClass NMIOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDDeviceName NMTOKEN #IMPLIED＞＜！ELEMENT NetworkType(EMPTY＞＜！ATTLIST NetworkTypeClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDDeviceName NMTOKEN #IMPLIED＞＜！ELEMENT UserStatus(EMPTY)>＜！ATTLIST UserStatusClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT PreferredContact(EMPTY)>＜！ATTLIST PreferredContactClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDility NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT PreferredDefaults(EMPTY)>＜！ATTLIST PreferredDefaultsClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT LocalTime(EMPTY)＞＜！ATTLIST LocalTimeClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT MeasuredLocation(EMPTY)＞＜！ATTLIST MeasuredLocationClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDAccuracy NMTOKEN #IMPLIED＞＜！ELEMENT ConvertedLocation(EMPTY)＞＜！ATTLIST ConvertedLoationClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT StatedLocation(EMPTY)＞＜！ATTLIST StatedLocationClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT UserEnvironment(EMPTY)>＜！ATTLIST UserEnvironmentClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT StatusText(EMPTY)>＜！ATTLIST StatusTextClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT StatusImage(EMPTY)＞＜！ATTLIST StatusImageClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDImageType NMTOKEN #IMPLIED＞＜！ELEMENT StatusSound(EMPTY)>＜！ATTLIST StatusSoundClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDSoundType NMTOKEN #IMPLIED＞＜！ELEMENT MessagingCapabilities(EMPTY)＞＜！ATTLIST MessagingCapabilitiesClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT EmailClient(EMPTY)＞＜！ATTLIST EmailClientTypeClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IPLIED＞＜！ELEMENT VoiceCallCapability(EMPTY)＞＜！ATTLIST VoiceCallCapabilityClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT MultimediaCallCapabilities(EMPTY)>＜！ATTLIST MultimediaCallCapabilitiesClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT UserPresenceItem(EMPTY)＞＜！ATTLIST UserPresenceItemClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDExtRef PUBIDLITERAL #IMPLIED ExtRefChange NMTOKEN #IMPLIED＞＜！ELEMENT ClientType(EMPTY)＞＜！ATTLIST ClientTypeClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIED＞＜！ELEMENT ClientPresenceItem(EMPTY)>＜！ATTLIST ClientPresenceItemClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDContentChange NMTOKEN #IMPLIED＞＜！ELEMENT ExtPresence(EMPTY)＞＜！ATTLIST ExtPresenceClass NMTOKEN #IMPLIEDID PUBIDLITERAL #IMPLIEDCacheability NMTOKEN #IMPLIEDValidityPeriod NMTOKEN #IMPLIEDContentChange NMTOKEN#IMPLIED＞＜！--End of DTD--＞]]></pre>对本专业技术人员而言，随着技术的进步，本发明的概念显然可以许多不同的方式来实现。因此，本发明及其实施例并不局限于上述实施例，而是可以在不脱离所附权利要求书的范围和精神的前提下加以变化。
权利要求
1.一种移动消息收发系统，包括服务器和至少一个客户装置，其中所述客户装置包括用于将存在信息作为存在属性发送到服务器的部件和用于从所述服务器接收存在属性的部件，所述存在信息按照以属性名来标识的多个存在属性类型来分类；以及所述服务器包括用于根据所接收到的存在属性来维护存在信息的部件；其特征在于，所述客户装置包括用于将限定符添加到存在属性中的部件，所述限定符包括一个或多个说明所述属性用途的参数；以及所述客户装置包括用于根据所述接收到的属性中的限定符参数来处理所接收到的存在属性的部件。
2.如权利要求1所述的系统，其特征在于，所述客户装置包括用于在所述限定符中指定所述属性的显示设置的部件，以及所述客户装置包括用于根据所述限定符来显示所述接收到的属性的部件。
3.如权利要求1所述的系统，其特征在于，所述客户装置包括用于在所述限定符中指定所述属性所应定址到的应用程序的部件；以及所述客户装置包括用于将所接收到的属性寻址到所述限定符所指示的应用程序的部件。
4.如前述权利要求中任意一项所述的系统，其特征在于，所述服务器包括用于根据所述限定符来判断要将所述属性发送到一个还是多个客户装置的部件。
5.一种包括服务器和至少一个客户装置的移动消息收发系统，其中，所述客户装置包括用于将存在信息作为存在属性发送到所述服务器的部件和用于从所述服务器接收所述存在属性的部件，所述存在信息按照以属性名来标识的多个存在属性类型来分类，以及所述服务器包括用于根据所接收到的存在属性来维护存在信息的部件，其特征在于，所述客户装置包括用于编辑以授权者、属性名和限定符的组合来标识的存在信息属性的部件，所述授权者指定负责维护所述属性的机构而所述限定符说明属性的用途；所述服务器包括用于搜索已存储并且与所接收到的属性含有完全相同的标识符的属性的部件，以及用于在所接收到的属性的标识符的组合与所述已存储的属性的标识符的组合完全相同时以所述接收到的属性替换所述已存储的属性，否则就添加所述接收到的属性的部件；以及所述客户装置包括用于搜索已存储并且与所接收到的属性含有完全相同的标识符的属性的部件，以及用于在所接收到的属性的标识符的组合与所述已存储的属性的标识符的组合完全相同时以所述接收到的属性替换所述已存储的属性，否则就添加所述接收到的属性的部件。
6.如前述权利要求中任意一项所述的移动消息收发系统，其特征在于，根据与存在组相关联的发布人用户将所述服务器从所述客户装置接收到的所述存在属性存储在数据库中。
7.如前述权利要求中任意一项所述的移动消息收发系统，其特征在于，每个存在属性是包括属性名元素和属性值的项的一部分。
8.如权利要求7所述的移动消息收发系统，其特征在于，所述属性名元素包含表示负责保持所述属性名元素和属性值唯一性的授权机构的授权机构字符串。
9.如前述权利要求中任意一项所述的移动消息收发系统，其特征在于，存在集合包括属于与单个存在组相关联的发布人用户的单个发布人角色的一个或多个存在属性。
10.如权利要求9所述的移动消息收发系统，其特征在于，作为发布人的所述客户装置的用户可以使用所述客户装置或者可以以多个发布人角色来使用多个客户装置。
11.一种移动消息收发系统的移动客户装置，所述客户装置包括用于将存在信息作为存在属性发送到服务器的部件，所述存在信息按照以属性名来标识的存在属性类型来分类，其特征在于，所述客户装置还包括用于将限定符添加到存在属性中的部件，所述限定符包括一个或多个说明属性用途的参数。
12.一种移动消息收发系统的移动客户装置，所述客户装置包括用于从服务器接收存在属性的部件，所述存在信息按照以属性名来标识的存在属性类型来分类，其特征在于所述客户装置还包括用于将限定符添加到存在属性中的部件，所述限定符包括一个或多个说明所述属性的用途的参数；以及用于根据接收到的存在属性中的限定符参数来处理所述接收到的属性的部件。
13.一种移动消息收发系统的移动客户装置，所述客户装置包括用于将存在信息作为存在属性发送到服务器的部件和用于从所述服务器接收所述存在属性的部件，所述存在信息按照以属性名来标识的存在属性类型来分类，其特征在于所述客户装置还包括用于编辑以授权者、属性名和限定符的组合来标识的存在信息属性的部件，所述授权者指定负责维护所述属性的机构而所述限定符说明所述属性的用途；用于搜索已存储且与所接收到的属性含有完全相同的标识符的属性的部件，以及用于在所述接收到的属性的标识符的组合与所述已存储的属性的标识符组合完全相同时以所述接收到的属性替换所述已存储的属性，否则就添加所述接收到的属性的部件。
14.如权利要求11-13中任意一项所述的移动客户装置，其特征在于，每个存在属性是包含属性名元素和属性值的项的一部分。
15.如权利要求14所述的移动客户装置，其特征在于，所述属性名元素包含表示负责保持所述属性名元素和属性值唯一性的授权机构的授权机构字符串。
16.如权利要求11-15中任意一项所述的移动客户装置，其特征在于，存在集合包括属于与单个存在组相关联的发布人用户的单个发布人角色的一个或多个存在属性。
17.如权利要求16所述的移动客户装置，其特征在于，作为发布人的所述移动客户装置用户可以使用所述客户装置或者可以以多个发布人角色来使用多个客户装置。
18.一种用于移动消息收发系统的服务器，所述服务器包括用于根据接收到的存在属性来维护存在信息的部件，所述存在信息按照以属性名来标识的多个存在属性类型来分类，其特征在于所述服务器还包括用于搜索已存储且与接收到的属性含有完全相同的标识符的属性的部件，以及用于在所述接收到的属性的标识符的组合与所述已存储的属性的标识符组合完全相同时，以所述接收到的属性替换所述已存储的属性，否则就添加所述接收到的属性的部件。
19.如权利要求18所述的服务器，其特征在于。根据与存在组相关联的发布人用户将所述服务器从客户装置接收到的存在属性存储在数据库中。
20.如权利要求18或19所述的服务器，其特征在于，每个存在属性是包含属性名元素和属性值的项的一部分。
21.如权利要求20所述的服务器，其特征在于，所述属性名元素包含表示负责保持所述属性名元素和属性值唯一性的授权机构的授权机构字符串。
22.如权利要求18-21中任意一项所述的服务器，其特征在于，存在集合包括属于与单个存在组相关联的发布人用户的单个发布人角色的一个或多个存在属性。
23.如权利要求22所述的服务器，其特征在于，作为发布人与所述服务器通信的客户装置用户可以使用所述客户装置或者可以以多个发布人角色来使用多个客户装置。
24.一种存在系统，包括至少一个至少具有一个存在客户的物理装置，所述存在客户用于使存在用户能够作为发布人或订阅户与所述系统交互；以及用于维护发布人的存在属性集的有效值，以供订阅户按照相关存在组来访问的服务器。
25.如权利要求24所述的存在系统，其特征在于，每个属性是包含属性名元素和属性值的项的一部分。
26.如权利要求25所述的存在系统，其特征在于，所述属性名元素包含具有与属性用途有关的信息的限定符。
27.如权利要求26所述的存在系统，其特征在于，所述属性名元素包含表示负责保持所述属性名元素和属性值唯一性的授权机构的授权机构字符串。
28.如权利要求24-27中任意一项所述的存在系统，其特征在于，存在集合包括属于与单个存在组相关联的单个发布人角色的一个或多个属性。
29.如权利要求28所述的存在系统，其特征在于，作为发布人与所述系统交互的所述用户可以使用所述存在客户或者可以以多个发布人角色来使用多个存在客户。
30.如权利要求28所述的存在系统，其特征在于，每个属性是包含属性名元素和属性值的项的一部分。
31.如权利要求24-30中任意一项所述的存在系统，其特征在于，所述至少一个物理装置是移动物理装置。
32.一种包含在计算机可读媒体中以便存储在物理装置中的计算机程序，其特征在于，所述程序是存在客户程序，用于使存在用户能够作为至少一个存在属性集的发布人与存在系统交互，其中所述至少一个存在属性集供一个或多个订阅户按照相关的至少一个存在组来访问。
33.如权利要求32所述的存在客户程序，其特征在于，所述程序可使存在用户作为与所属存在组相关的至少一个属性集的订阅户与所述存在系统交互。
34.如权利要求32或33所述的存在客户程序，其特征在于，每个属性是包含属性名元素和属性值的项的一部分。
35.如权利要求34所述的存在客户程序，其特征在于，所述属性名元素包含具有与属性用途相关的信息的限定符。
36.如权利要求35所述的存在客户程序，其特征在于，所述属性名元素包含表示负责保持所述属性名元素和属性值唯一性的授权机构的授权机构字符串。
37.如权利要求32-36中任意一项所述的存在客户程序，其特征在于，存在集合包括属于与单个存在组相关联的单个发布人角色的一个或多个属性。
38.如权利要求37所述的存在客户程序，其特征在于，作为发布人与所述系统交互的所述用户可以使用所述存在客户程序或者可以以多个发布人角色来使用多个存在客户程序。
39.如权利要求37所述的存在客户程序，其特征在于，每个属性是包含属性名元素和属性值的项的一部分。
40.如权利要求32-39中任意一项所述的存在客户程序，其特征在于，所述物理装置是移动物理装置。
41.一种具有计算机程序的物理装置，所述计算机程序包含在存储于物理装置中的计算机可读媒体中，其特征在于，所述程序是如权利要求32-40中任意一项所述的存在客户程序。
42.一种包含在计算机可读媒体中以便存储在物理装置中的数据结构，其特征在于，所述数据结构是用于存储一个或多个发布人的存在属性集合的有效值的存在数据库，所述存在属性集合的有效值可供订阅户按照与所述存在集合相关的存在组来访问。
43.如权利要求42所述的数据结构，其特征在于，每个属性是包含属性名元素和属性值的项的一部分。
44.如权利要求43所述的数据结构，其特征在于，所述属性名元素包含具有与属性用途有关的信息的限定符。
45.如权利要求44所述的数据结构，其特征在于，所述属性名元素包含表示负责保持所述属性名元素和属性值唯一性的授权机构的授权机构字符串。
46.如权利要求42-45中任意一项所述的数据结构，其特征在于，存在集合包括属于与单个存在组相关联的单个发布人角色的一个或多个属性。
47.如权利要求42-46中任意一项所述的数据结构，其特征在于，作为发布人与所述系统交互的用户可以使用所述数据结构来发布多个发布人角色，各角色具有与不同存在组相关联的不同存在集合。
48.如权利要求42-47中任意一项所述的数据结构，其特征在于所述物理装置是移动装置。
49.一种具有数据结构的物理装置，所述数据结构包含在存储于物理装置中的计算机可读媒体中，其特征在于，所述数据结构是如权利要求42-48中任意一项所述的存在数据结构。
全文摘要
本发明涉及移动消息收发和存在服务。根据本发明的一个方面，移动消息收发系统的客户装置将限定符添加到存在属性中，所述限定符包括一个或多个说明属性用途的参数。接收到存在属性的客户装置根据所接收的属性中的限定符参数来处理所接收的存在属性。本发明的另一个方面说明如何在角色范围内单个存在集合中汇编并存储具有名称、属性和值的存在项，所述角色具有相关联的权限组，其中的成员有权订阅同一角色的整个存在集合或其中一部分。
文档编号H04L12/58GK1526246SQ02813759
公开日2004年9月1日 申请日期2002年5月10日 优先权日2001年5月11日
发明者A·萨洛梅基, A 萨洛梅基 申请人:诺基亚有限公司