CN102546970A - 一种发布呈现信息的方法和装置 - Google Patents
一种发布呈现信息的方法和装置 Download PDFInfo
- Publication number
- CN102546970A CN102546970A CN2010106122856A CN201010612285A CN102546970A CN 102546970 A CN102546970 A CN 102546970A CN 2010106122856 A CN2010106122856 A CN 2010106122856A CN 201010612285 A CN201010612285 A CN 201010612285A CN 102546970 A CN102546970 A CN 102546970A
- Authority
- CN
- China
- Prior art keywords
- information
- issue
- tabulation
- issue tabulation
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本发明提出了一种在SIP网络中用于发布呈现信息的方法，发布者向呈现服务器发送包含呈现信息的发布消息，其中，所述发布消息里包括至少一个发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布；当呈现服务器接收到来自发布者的发布消息时，判断其中是否包含发布列表；当判断结果为包含时，对于每个发布列表，呈现服务器确定该发布列表指定的订阅者；呈现服务器依次向每个发布列表指定的所有订阅者发送包含该发布列表指定信息的通知消息。采用该方法，发布者可以主动决定对哪些订阅者发布呈现信息以及发布什么样的呈现信息，因而对于发布者来说，其可以对不同的订阅者提供差异化的呈现信息。
Description
技术领域
本发明涉及通信网络，尤其涉及发布呈现信息的方法和装置。
背景技术
Presence业务也被称为呈现业务，是以某种通信方式，按照一定的接入准则，实时获取呈现信息(如用户状态、通信能力、个人喜好等信息)并展现给其他用户的一种业务，在即时通信中扮演着非常重要的角色。依靠Presence技术，即时通信业务用户可以把用户状态设置为“打电话中”、“会议进行中”等多种状态，同时设定在哪种状态下自己有哪些通信能力以及希望采取哪种通信方式，也可以订阅他人的通信状态信息，以便主被叫双方在特定的场合选择最适合的通信方式，从而提高通信效率和通信质量。
Presence业务的业务模型如图1所示。发布者101是呈现业务的信息源，可以是用户代理或网络代理，用户代理能主动发布呈现信息，例如设置状态为“离开”、“会议中”等。订阅者102是呈现信息的订阅者和接收者，能够接收包含呈现信息的通知消息。呈现服务器103，实现和执行呈现业务逻辑，包括处理订阅请求、处理发布请求、发送通知和操作授权规则等。在呈现业务中，目前通常采用SIP(Session Initial Protocol，会话初始协议)协议。在IMS(IPMultimedia Subsytem，IP多媒体子系统)中，呈现业务通常被分解为几个步骤：订阅、发布和通知。以图1为例，订阅者102向呈现服务器103订阅发布者101的呈现信息，当发布者101接收到该订阅请求后，每当其状态发生改变时，其将向呈现服务器103发布其当前的状态，呈现服务器103随后将通知订阅者102。
目前研究Presence业务的国际组织有IETF、3GPP、3GPP2、OMA等。其中，关于呈现信息的发布，涉及到的标准主要有IETF的RFC3903、3GPP的TS 24.141V9.1.0等。在上述的标准中，发布者只能将呈现信息发布给呈现服务器，然后由呈现服务器发布给所有订阅此信息的订阅者。其缺陷在于发布者不能主动决定对哪些订阅者提供该呈现信息，即对不同的订阅者提供差异化的呈现信息。对于发布者来说，可能存在一些情形，其需要对于不同的用户(订阅者)提供不同的呈现信息。比如，对于某些亲密的朋友，发布者可能想呈现一些特别的用语，而对于其他人则呈现一般用语，或者对于一些特定的人，发布者可能想呈现某些日程信息或联系信息。这些信息都是比较私人的，不可能对所有的订阅者都提供，而根据现行的标准，无法满足这些需求。
发明内容
本发明为了解决现有技术中的上述缺陷，提出了一种发布呈现信息的方法和装置。
根据本发明的第一方面，提供了一种在终端中用于发布呈现信息的方法，该方法包括向呈现服务器发送包含呈现信息的发布消息，其中，所述发布消息里包括至少一个发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布。
优选地，所述发布列表所指定的信息为整个呈现信息、一个或多个子信息、一个或多个信息项。
根据本发明的第二方面，提供了一种在呈现服务器中用于发布呈现信息的方法，该方法包括：接收步骤：接收来自发布者的包含呈现信息的发布消息；判断步骤：判断所述发布消息中是否包含发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布；如果判断为包含，对于每个发布列表执行以下步骤：确定步骤：确定该发布列表指定的订阅者；发布步骤：依次向该发布列表指定的所有订阅者发送包含该发布列表指定信息的通知消息。
优选地，所述发布列表所指定的信息为整个呈现信息、一个或多个子信息、一个或多个信息项。
根据本发明的第三方面，提供了一种在呈现服务器中用于发布呈现信息的方法，包括：接收步骤：接收来自发布者的包含呈现信息的发布消息；判断步骤：判断所述发布消息中是否包含发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布；确定步骤：如果判断为包含时确定所有发布列表指定的订阅者；合并步骤：对于每个所述的指定的订阅者，合并其在不同发布列表中对应的指定信息；发布步骤：依次向所有指定的订阅者，发送包含上述合并后的指定信息的通知消息。
优选地，所述发布列表所指定的信息为整个呈现信息、一个或多个子信息、一个或多个信息项。
根据本发明的第四方面，提供了一种在终端中用于发布呈现信息的装置，包括：发送装置，用于向呈现服务器发送包含呈现信息的发布消息，其中，所述发布消息里包括至少一个发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布。
优选地，其特征在于，所述发布列表所指定的信息为整个呈现信息、一个或多个子信息、一个或多个信息项。
根据本发明的第五方面，提供了一种在呈现服务器中用于发布呈现信息的装置，包括：第一接收装置，用于接收来自发布者的包含呈现信息的发布消息；第一判断装置，用于判断所述发布消息中是否包含发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布；第一确定装置，用于当判断装置的结果为包含时，对于每个发布列表确定该发布列表指定的订阅者；第一发布装置：依次向每个发布列表指定的所有订阅者发送包含该发布列表指定信息的通知消息。
优选地，所述发布列表所指定的信息为整个呈现信息、一个或多个子信息、一个或多个信息项。
根据本发明的第六方面，提供了一种在呈现服务器中用于发布呈现信息的装置，包括：第二接收装置，用于接收来自发布者的包含呈现信息的发布消息；第二判断装置，用于判断所述发布消息中是否包含发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布；第二确定装置，用于确定所有发布列表指定的订阅者；合并装置，用于对于每个所述的指定的订阅者，合并其在不同发布列表中对应的指定信息；第二发布装置，用于依次向所有指定的订阅者，发送包含上述合并后的指定信息的通知消息。
优选地，所述发布列表所指定的信息为整个呈现信息、一个或多个子信息、一个或多个信息项。
通过使用本发明的方法和装置，发布者可以主动决定对哪些用户发布信息以及发布何种信息，实现对不同的订阅者提供差异化的呈现信息。发布者可以向某些订阅者屏蔽特定的信息即使这些订阅者已订阅该特定的信息，也可以向不同的订阅者发布不同的信息，从而克服现有技术中的缺陷。
附图说明
通过阅读以下参照附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显。
图1为呈现业务的业务模型示意图；
图2为根据本发明的一个具体实施方式的在终端中用于发布呈现信息的方法的流程图；
图3为根据本发明的一个具体实施方式的在呈现服务器中用于发布呈现信息的方法的流程图；
图4为根据本发明的一个具体实施方式的在呈现服务器中用于发布呈现信息的方法的流程图；
图5为根据本发明的一个具体实施方式的在终端中用于发布呈现信息的装置的结构框图；
图6为根据本发明的一个具体实施方式的在呈现服务器中用于发布呈现信息的装置的结构框图；
图7为根据本发明的一个具体实施方式的在呈现服务器中用于发布呈现信息的装置的结构框图。
具体实施方式
为了能够实现呈现信息的发布者能主动决定哪些订阅者可以接收其发布的呈现信息以及接收何种呈现信息，本发明提出了一种新的发布呈现信息的方法，其基本思想是在发布者发布呈现信息的同时，指定一个发布列表，该发布列表指定了可以接收的用户，同时也指定了呈现的内容，即发布者希望发布列表指定的信息只向发布列表指定的用户发布，其他观察者即使订阅了该信息也无法看到该信息。
在现有的呈现系统中，一般采用SIP协议做为通信协议。发布者向呈现服务器发布的呈现信息通常位于SIP消息的消息体中，IETFRFC 3863定义了描述呈现信息的格式PIDF(Presence InformationData Format)。PIDF用于表示用户在线性、通信意愿、终端信息等数据，其包含的元素如下：
Presence：根节点，包含0到多个<Tuple>和<Note>元素，并支持其他扩展元素。具有一个必需的属性<Entity>，用于表示发布此呈现信息的用户URI(Uniform Resource Identifier，统一资源标识符)。如无特别说明，本文所称的呈现信息指的是Presence元素所包含的信息。
Tuple：表示一个信息组。包含1个<status>，0或1个<contact>，0到多个<note>以及0到1个<timestamp>，并支持其他扩展元素。Tuple提供了分割呈现信息的方法。发布者可能由于各种原因希望发布多组信息，比如，完整的呈现信息来自不同的设备或者来自同一设备的不同应用或者产生于不同的时段。通过采用不同的Tuple，可以描述多组信息，因此，每个Tuple都有一个ID属性做为唯一标识。如无特别说明，本文所称的呈现信息的子信息指的是Tuple元素所包含的信息。
Status：表示在服务中的状态，包含0到1个<basic>，支持其他扩展属性。
Basic：可取值”open”或”closed”，表示可用或不可用的状态。
Contact：作为联系地址的URI。具有一个可选的属性priority。
Note：注释。
Timestamp：时间戳，表示Tuple状态发生变化的时间。
如无特别说明，本文所称的信息项指的是Tuple元素中的<Status>、<Basic>、<Contact>、<Note>、<Timestamp>等子元素。
表1示例性列出了根据PIDF描述的一个PUBLISH消息。
下面参照图1的业务模型，并结合图2和图3详细说明本发明的发布信息的方法。
需要指出的是，发布者101和呈现服务器103之间，呈现服务器103和观察者102之间可能会有多个网络设备，比如IMS网络中的P-CSCF(Proxy Call Session Control Function，代理呼叫会话控制功能)和S-CSCF(Serving Call Session Control Function，服务呼叫会话控制功能)，为描述的简便，图中未示出。
图2示例性示出了根据本发明的一个具体实施方式在终端101中发布呈现信息的方法的过程图。
该方法始于步骤S201。发布者101向呈现服务器103发送包含呈现信息的发布消息，比如PUBLISH消息，其中，所述发布消息里包括至少一个发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布。
以上述的表1中所示的PUBLISH消息为例，其中包含的呈现信息为Presence元素所涵盖的信息，其中包括2个Tuple。与现有技术不同的是，在步骤S201中的PUBLISH消息中还包含了至少一个发
布列表，假设其中一个为D1，D1表明发布者101希望只向D1中的用户发布其指定的信息，而不向其他用户发布其指定的信息，其中，其指定的信息可以为整个呈现信息、一个或多个子信息、一个或多个信息项。
由于编码方式的灵活性，D1可以采取多种方式来表示其指定的用户和指定的信息。下文列出了其中几种，应该指出，表示方法不应仅限于下述的几种方式。
如果D1包含了整个Presence信息，则表明发布者101希望只向D1中指定的用户发布整个呈现信息。表2示例性示出了D1包含整个Presence信息的PUBLISH消息。D1指定的用户即<receiver>元素后记载的用户，而D1指定的信息即为其包含的信息。因而，D1表明发布者101希望只向这些用户(即joeexample.com；markexample.com；grouplexample.com对应的用户)发布整个呈现信息(即Presence元素涵盖的信息，也即两个Tuple所包含的信息)，而不向其他用户发布整个呈现信息，即使其他用户已订阅这些信息。
如果D1包含了一个或多个Tuple信息，则表明发布者101希望只向D1中指定的用户发布这些Tuple的信息，即呈现信息的子信息。表3示例性示出了D1包含第一个Tuple的PUBLISH消息。D1指定的用户即<receiver>元素后记载的用户，而D1指定的信息即为其包含的信息。因而，D1表明发布者101希望只向这些用户(即joeexample.com；markexample.com；group1example.com对应的用户)发布该Tuple的信息，而不向其他用户发布该Tuple的信息，即使其他用户已订阅这些信息。
如果D1包含了某个Tuple的一个或多个信息项，则表明发布者101希望只向D 1中指定的用户发布这些信息项的信息。表4示例性示出了D1包含第一个Tuple的<status>元素的PUBLISH消息。D1指定的用户即<receiver>元素后记载的用户，而D1指定的信息即为其包含的信息。因而，D1表明发布者101希望只向这些用户(即joeexample.com；markexample.com；group1example.com对应的用户)发布第一个Tuple的<status>元素的信息，而不向其他用户发布该<status>元素的信息，即使其他用户已订阅这些信息。
不难理解，PUBLISH消息中可以包含1个或多个发布列表，参照上述的描述，不同的发布列表包含不同的呈现信息，比如第一个发布列表D1包含第一个Tuple，而第二个发布列表D2包含第二个Tuple，表明发布者101希望只向D1中指定的用户发布第一个Tuple包含的信息，而且只向D2中指定的用户发布第二个Tuple包含的信息。
图3示例性示出了根据本发明的一个具体实施方式在呈现服务器103中发布呈现信息的方法的过程图。
该方法始于步骤S301。呈现服务器103接收来自发布者101的包含呈现信息的发布消息，比如PUBLISH消息。
接着进入到步骤S302，即判断所述发布消息中是否包含发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布。比如对于表2至表4的PUBLISH消息，呈现服务器103可以通过在PUBLISH消息中查找<distribution list>元素来判断。
如前所述，发布列表可以采用多种方式来表示其指定的用户和指定的信息。关于如何确定发布列表指定的用户和指定的信息在前文已有详细叙述，此处不再赘诉。
优选地，发布列表指定的信息可以是整个呈现信息，比如Presence元素涵盖的信息；可以是一个或多个子信息，比如一个或多个Tuple元素涵盖的信息，也可以是一个或多个信息项，比如一个或多个Tuple的子元素，比如一个或多个<Status>、<Basic>、<Contact>、<Note>、<Timestamp>等子元素。
如果判断结果为包含，则对于每个发布列表，呈现服务器103将执行下面的步骤。
首先执行步骤S303，确定该发布列表指定的订阅者。呈现服务器103逐个读取该发布列表指定的用户，根据已有的订阅信息，查看该用户是否已订阅了该发布列表指定的信息，如果已订阅，则该用户为该发布列表指定的订阅者，如果该用户没有订阅该指定的信息，则其不是该发布列表指定的订阅者。
然后执行步骤S304，即依次向该发布列表指定的所有订阅者发送包含该发布列表指定信息的通知消息，比如NOTIFY消息。呈现服务器103对在步骤S303中确定的订阅者均会发送通知消息，该通知消息包含了该发布列表指定的信息。而且，呈现服务器103只对步骤S303中确定的订阅者发送通知消息，对于其他已订阅该指定信息的订阅者不会发送通知消息。需要指出的是，发送的NOTIFY消息中不包含<distribution list>元素。
例如，当呈现服务器103接收到表3所示的PUBLISH消息后，经判断其中含有<distribution list>元素，则对于该发布列表，确定其指定的信息为第一个Tuple的信息，指定的用户为joeexample.com；markexample.com；group1example.com对应的用户。经判断，这三个用户均为该指定信息的订阅者，即这三个用户均为指定的订阅者。那么，呈现服务器103会分别向这三个用户发送包含第一个Tuple信息的NOTIFY消息，该NOTIFY消息中不包含<distribution list>元素。而且，呈现服务器103仅向这三个用户发送NOTIFY消息，不向其他用户发送NOTIFY消息，即使其他用户也订阅了该指定信息。
如果呈现服务器103接收到的发布消息里包含多个发布列表，则对于每个发布列表，呈现服务器103均会执行步骤S303和步骤S304。
图4示例性示出了根据本发明的一个具体实施方式在呈现服务器103中发布呈现信息的方法的过程图。
该方法始于步骤S401。呈现服务器103接收来自发布者101的包含呈现信息的发布消息，比如PUBLISH消息。
接着进入到步骤S402，即判断所述发布消息中是否包含发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布。比如对于表2至表4的PUBLISH消息，呈现服务器103可以通过在PUBLISH消息中查找<distribution list>元素来判断。
如前所述，发布列表可以采用多种方式来表示其指定的用户和指定的信息。关于如何确定发布列表指定的用户和指定的信息在前文已有详细叙述，此处不再赘诉。
优选地，发布列表指定的信息可以是整个呈现信息，比如Presence元素涵盖的信息；可以是一个或多个子信息，比如一个或多个Tuple元素涵盖的信息，也可以是一个或多个信息项，比如一个或多个Tuple的子元素，比如一个或多个<Status>、<Basic>、<Contact>、<Note>、<Timestamp>等子元素。
如果判断结果为包含，则执行步骤S403，确定所有发布列表指定的订阅者。呈现服务器103逐个确定每个发布列表制定的订阅者。对于某个发布列表，如何确定其指定的订阅者已在图3中的步骤S303中做了描述。
接着，执行步骤S404，对于每个所述的指定的订阅者，合并其在不同发布列表中对应的指定信息得到合并后的指定信息。假设呈现服务器103接收到的NOTIFY消息中包含两个发布列表，分别为D1和D2，其中，D1指定的信息为第一个Tuple的信息，D2指定的信息为第二个Tuple的信息。在执行了上述的步骤S403后，确定D1指定的订阅者为U1、U2、U3，而D2指定的订阅者为U2，U4。对于用户U1，其仅出现在D1中，因此，合并后的指定信息仍为D1指定的信息。对于用户U2，其同时出现在D1和D2中，因此，合并后的指定信息为D1指定的信息和D2指定的信息。对于用户U3，其仅出现在D1中，因此，合并后的指定信息仍为D1指定的信息。对于用户U4，其仅出现在D2中，因此，合并后的指定信息仍为D2指定的信息。
最后，执行步骤S405，即依次向所有指定的订阅者，发送包含上述合并后的指定信息的通知消息，比如NOTIFY消息。在执行完步骤S404后，呈现服务器103可以确定所有指定的订阅者，比如上述的用户U1、U2、U3、U4，以及对应于每个指定订阅者的合并后的指定信息。那么在步骤S405中，呈现服务器103依次向每个指定的订阅者，发送包含其对应的合并后的指定信息的NOTIFY消息，比如，向用户U1，发送包含D1指定信息的NOTIFY消息；向用户U2，发送包含D1指定信息和D2指定信息的NOTIFY消息；向用户U3，发送包含D1指定信息的NOTIFY消息；向用户U4，发送包含D2指定信息的NOTIFY消息。需要指出的是，这些NOTIFY消息中不包含<distribution list>元素。
图5示例性示出了根据本发明的一个具体实施方式的在终端中用于发布呈现信息的装置的结构框图。该装置500包括发送装置501。以下结合图1所示的业务模型示意图，对位于终端101中的装置500的工作过程进行详细说明。
发送装置501向呈现服务器103发送包含呈现信息的发布消息，比如PUBLISH消息，其中，所述发布消息里包括至少一个发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布。
如前所述，发布列表可以采用多种方式来表示其指定的用户和指定的信息。关于如何确定发布列表指定的用户和指定的信息在前文已有详细叙述，此处不再赘诉。
优选地，发布列表指定的信息可以是整个呈现信息，比如Presence元素涵盖的信息；可以是一个或多个子信息，比如一个或多个Tuple元素涵盖的信息，也可以是一个或多个信息项，比如一个或多个Tuple的子元素，比如一个或多个<Status>、<Basic>、<Contact>、<Note>、<Timestamp>等子元素。
不难理解，PUBLISH消息中可以包含1个或多个发布列表，参照上述的描述，不同的发布列表包含不同的呈现信息，比如第一个发布列表D1包含第一个Tuple，而第二个发布列表D2包含第二个Tuple，表明发布者101希望只向D1中指定的用户发布第一个Tuple包含的信息，而且只向D2中指定的用户发布第二个Tuple包含的信息。
图6示例性示出了根据本发明的一个具体实施方式的在呈现服务器中用于发布呈现信息的装置的结构框图。该装置600包括第一接收装置601、第一判断装置602、第一确定装置603、第一发布装置604。以下结合图1所示的业务模型示意图，对位于呈现服务器103中的装置600的工作过程进行详细说明。
首先第一接收装置601接收来自发布者101的包含呈现信息的发布消息，比如PUBLISH消息。
接着第一判断装置602判断所述发布消息中是否包含发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布。比如对于表2至表4的PUBLISH消息，第一判断装置602可以通过在PUBLISH消息中查找<distribution list>元素来判断。
如前所述，发布列表可以采用多种方式来表示其指定的用户和指定的信息。关于如何确定发布列表指定的用户和指定的信息在前文已有详细叙述，此处不再赘诉。
优选地，发布列表指定的信息可以是整个呈现信息，比如Presence元素涵盖的信息；可以是一个或多个子信息，比如一个或多个Tuple元素涵盖的信息，也可以是一个或多个信息项，比如一个或多个Tuple的子元素，比如一个或多个<Status>、<Basic>、<Contact>、<Note>、<Timestamp>等子元素。
如果判断结果为包含，则对于每个发布列表，呈现服务器103将执行下面的步骤。
首先第一确定装置603确定该发布列表指定的订阅者。第一确定装置603逐个读取该发布列表指定的用户，根据已有的订阅信息，查看该用户是否已订阅了该发布列表指定的信息，如果已订阅，则该用户为该发布列表指定的订阅者，如果该用户没有订阅该指定的信息，则其不是该发布列表指定的订阅者。
然后第一发布装置604依次向该发布列表指定的所有订阅者发送包含该发布列表指定信息的通知消息，比如NOTIFY消息。第一发布装置604对由第一确定装置603确定的订阅者均会发送通知消息，该通知消息包含了该发布列表指定的信息。而且，第一发布装置604只向由第一确定装置603确定的订阅者发送通知消息，对于其他已订阅该指定信息的订阅者不会发送通知消息。需要指出的是，发送的NOTIFY消息中不包含<distribution list>元素。
图7示例性示出了根据本发明的一个具体实施方式的在呈现服务器中用于发布呈现信息的装置的结构框图。该装置700包括第二接收装置701、第二判断装置702、第二确定装置703、合并装置704、第二发布装置705。以下结合图1所示的业务模型示意图，对位于呈现服务器103中的装置700的工作过程进行详细说明。
首先，第二接收装置701接收来自发布者101的包含呈现信息的发布消息，比如PUBLISH消息。
接着，第二判断装置702判断所述发布消息中是否包含发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布。比如对于表2至表4的PUBLISH消息，第二判断装置702可以通过在PUBLISH消息中查找<distribution list>元素来判断。
如前所述，发布列表可以采用多种方式来表示其指定的用户和指定的信息。关于如何确定发布列表指定的用户和指定的信息在前文已有详细叙述，此处不再赘诉。
优选地，发布列表指定的信息可以是整个呈现信息，比如Presence元素涵盖的信息；可以是一个或多个子信息，比如一个或多个Tuple元素涵盖的信息，也可以是一个或多个信息项，比如一个或多个Tuple的子元素，比如一个或多个<Status>、<Basic>、<Contact>、<Note>、<Timestamp>等子元素。
如果判断结果为包含，则第二确定装置703确定所有发布列表指定的订阅者。第二确定装置703逐个确定每个发布列表制定的订阅者。对于某个发布列表，如何确定其指定的订阅者已在图3中的步骤S303中做了描述。
接着，合并装置704对于每个所述的指定的订阅者，合并其在不同发布列表中对应的指定信息得到合并后的指定信息。假设第二接收装置701接收到的NOTIFY消息中包含两个发布列表，分别为D1和D2，其中，D1指定的信息为第一个Tuple的信息，D2指定的信息为第二个Tuple的信息。第二确定装置703确定D1指定的订阅者为U1、U2、U3，而D2指定的订阅者为U2，U4。对于用户U1，其仅出现在D1中，因此，合并装置704得到的合并后的指定信息仍为D1指定的信息。对于用户U2，其同时出现在D1和D2中，因此，合并装置704得到的合并后的指定信息为D1指定的信息和D2指定的信息。对于用户U3，其仅出现在D1中，因此，合并装置704得到的合并后的指定信息仍为D1指定的信息。对于用户U4，其仅出现在D2中，因此，合并装置704得到的合并后的指定信息仍为D2指定的信息。
最后，第二发布装置705依次向所有指定的订阅者，发送包含上述合并后的指定信息的通知消息，比如NOTIFY消息。需要指出的是，这些NOTIFY消息中不包含<distribution list>元素。例如上述的例子中，第二确定装置703确定了所有指定的订阅者，即用户U1、U2、U3、U4，合并装置704得到了对应于每个指定订阅者的合并后的指定信息。那么，第二发布装置705依次向每个指定的订阅者，发送包含其对应的合并后的指定信息的NOTIFY消息，比如，向用户U1，发送包含D1指定信息的NOTIFY消息；向用户U2，发送包含D1指定信息和D2指定信息的NOTIFY消息；向用户U3，发送包含D1指定信息的NOTIFY消息；向用户U4，发送包含D2指定信息的NOTIFY消息。需要指出的是，这些NOTIFY消息中不包含<distribution list>元素。
对于本领域技术人员而言，显然本发明不限于上述示范性实施方式的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施方式看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。
Claims (12)
1.一种在终端中用于发布呈现信息的方法，包括：向呈现服务器发送包含呈现信息的发布消息，其中，所述发布消息里包括至少一个发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布。
2.根据权利要求1所述的方法，其特征在于，所述发布列表所指定的信息为整个呈现信息、一个或多个子信息、一个或多个信息项。
3.一种在呈现服务器中用于发布呈现信息的方法，包括：
接收步骤：接收来自发布者的包含呈现信息的发布消息；
判断步骤：判断所述发布消息中是否包含发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布；
如果判断为包含，对于每个发布列表执行以下步骤：
确定步骤：确定该发布列表指定的订阅者；
发布步骤：依次向该发布列表指定的所有订阅者发送包含该发布列表指定信息的通知消息。
4.根据权利要求3所述的方法，其特征在于，所述发布列表所指定的信息为整个呈现信息、一个或多个子信息、一个或多个信息项。
5.一种在呈现服务器中用于发布呈现信息的方法，包括：
接收步骤：接收来自发布者的包含呈现信息的发布消息；
判断步骤：判断所述发布消息中是否包含发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布；
确定步骤：如果判断为包含，确定所有发布列表指定的订阅者；
合并步骤：对于每个所述的指定的订阅者，合并其在不同发布列表中对应的指定信息；
发布步骤：依次向所有指定的订阅者，发送包含上述合并后的指定信息的通知消息。
6.根据权利要求5所述的方法，其特征在于，所述发布列表所指定的信息为整个呈现信息、一个或多个子信息、一个或多个信息项。
7.一种在终端中用于发布呈现信息的装置，包括：
发送装置，用于向呈现服务器发送包含呈现信息的发布消息，其中，所述发布消息里包括至少一个发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布。
8.根据权利要求7所述的装置，其特征在于，所述发布列表所指定的信息为整个呈现信息、一个或多个子信息、一个或多个信息项。
9.一种在呈现服务器中用于发布呈现信息的装置，包括：
第一接收装置，用于接收来自发布者的包含呈现信息的发布消息；
第一判断装置，用于判断所述发布消息中是否包含发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布；
第一确定装置，用于当判断装置的结果为包含时，对于每个发布列表确定该发布列表指定的订阅者；
第一发布装置：依次向每个发布列表指定的所有订阅者发送包含该发布列表指定信息的通知消息。
10.根据权利要求9所述的装置，其特征在于，所述发布列表所指定的信息为整个呈现信息、一个或多个子信息、一个或多个信息项。
11.一种在呈现服务器中用于发布呈现信息的装置，包括：
第二接收装置，用于接收来自发布者的包含呈现信息的发布消息；
第二判断装置，用于判断所述发布消息中是否包含发布列表，所述发布列表用于表明发布列表所指定的信息只向发布列表所指定的用户发布而不向其他用户发布；
第二确定装置，用于当判断装置的结果为包含时，确定所有发布列表指定的订阅者；
合并装置，用于对于每个所述的指定的订阅者，合并其在不同发布列表中对应的指定信息；
第二发布装置，用于依次向所有指定的订阅者，发送包含上述合并后的指定信息的通知消息。
12.根据权利要求11所述的方法，其特征在于，所述发布列表所指定的信息为整个呈现信息、一个或多个子信息、一个或多个信息项。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201010612285.6A CN102546970B (zh) | 2010-12-20 | 2010-12-20 | 一种发布呈现信息的方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201010612285.6A CN102546970B (zh) | 2010-12-20 | 2010-12-20 | 一种发布呈现信息的方法和装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102546970A true CN102546970A (zh) | 2012-07-04 |
| CN102546970B CN102546970B (zh) | 2015-04-22 |
Family
ID=46352897
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201010612285.6A Expired - Fee Related CN102546970B (zh) | 2010-12-20 | 2010-12-20 | 一种发布呈现信息的方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102546970B (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018019281A1 (zh) * | 2016-07-29 | 2018-02-01 | 京东方科技集团股份有限公司 | 进行通知的方法、装置和系统 |
| US11677850B2 (en) | 2016-07-29 | 2023-06-13 | Boe Technology Group Co., Ltd. | Method, apparatus and system for notification |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002093959A1 (en) * | 2001-05-11 | 2002-11-21 | Nokia Corporation | Mobile instant messaging and presence service |
| CN1794706A (zh) * | 2005-07-22 | 2006-06-28 | 华为技术有限公司 | 存在信息的提供方法 |
-
2010
- 2010-12-20 CN CN201010612285.6A patent/CN102546970B/zh not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002093959A1 (en) * | 2001-05-11 | 2002-11-21 | Nokia Corporation | Mobile instant messaging and presence service |
| CN1794706A (zh) * | 2005-07-22 | 2006-06-28 | 华为技术有限公司 | 存在信息的提供方法 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018019281A1 (zh) * | 2016-07-29 | 2018-02-01 | 京东方科技集团股份有限公司 | 进行通知的方法、装置和系统 |
| US11677850B2 (en) | 2016-07-29 | 2023-06-13 | Boe Technology Group Co., Ltd. | Method, apparatus and system for notification |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102546970B (zh) | 2015-04-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8332468B2 (en) | Method and system for processing an address book | |
| US8213346B2 (en) | Group communication for a variety of media types and devices | |
| CN102227927B (zh) | 用于提供通信历史的方法和装置 | |
| US9942281B2 (en) | Group communication in communication system | |
| US20090043847A1 (en) | Group Communication in a Communication System | |
| CN102299810B (zh) | 群组变更事件的通知方法和系统 | |
| US20080226050A1 (en) | System and method for establishing conference events | |
| CN102594718A (zh) | 一种处理呈现信息的方法和装置 | |
| EP2876591A1 (en) | Method and apparatus for establishing a social relationship in a social service providing system | |
| CN109314947A (zh) | 设备和/或线路事件感知和智能同步 | |
| CN101175075A (zh) | 对业务信息进行关联处理的方法 | |
| CN101159910B (zh) | 同步呈现状态的方法及实现该方法的群组服务器和终端 | |
| US9571563B2 (en) | Handling a shared data object in a communication network | |
| CN102209313A (zh) | 订阅呈现信息的方法、系统、资源列表服务器及呈现服务器 | |
| CN102546970A (zh) | 一种发布呈现信息的方法和装置 | |
| US8458265B1 (en) | Method and computer-readable medium for social network audio exchange with push-to-talk | |
| Bachmann et al. | Requirements for an extendible IMS client framework | |
| EP2187584A1 (en) | A message association method, user terminal and server | |
| CN102025697B (zh) | 用于cab的邀请订阅、订阅和订阅更新通知方法及装置 | |
| KR100784225B1 (ko) | 프리즌스 시스템에서의 폰북 어드레스(ｐｂａ) 기반의서비스 제공 방법 및 그 시스템 | |
| CN101873542A (zh) | 基于条件的统一资源标识的选择方法、服务器及通信系统 | |
| TW201021490A (en) | System and method for re-publication of information in a network-based communication system | |
| KR20130132204A (ko) | 통신 시스템에서 컨텍스트를 기반으로 소셜 관계를 설정하는 방법 | |
| Ahonen | Implementing a Multi-access Push to Talk System and Analysing User Experience | |
| KR20130132201A (ko) | 통신 시스템에서 사용자 참여형 미디어 서비스를 제공하는 방법 및 장치 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20150422 Termination date: 20161220 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |