CN100527678C - 发布和获取关系型呈现信息的方法 - Google Patents

Abstract

本发明公开了一种发布和获取关系型呈现信息的方法及关系型呈现业务系统。该方法包括：第一关系型呈现客户端向关系型呈现服务器发布呈现信息的全局授权规则；关系型呈现服务器接收全局授权规则并保存起来；第一关系型呈现客户端将会话关系信息发布到关系型呈现服务器；用户通过第二关系型呈现客户端设定过滤条件；第二关系型呈现客户端向关系型呈现服务器发送订阅第一关系型呈现客户端的关系信息的请求；关系型呈现服务器将第一关系型呈现客户端的关系呈现信息通知给第二关系型呈现客户端；第二关系型呈现客户端接收并处理关于第一关系型呈现客户端的会话关系信息通知；该系统包括：关系型呈现服务器，多个关系型客户端。

Description

发布和获取关系型呈现信息的方法

技术领域

本发明涉及计算机通讯系统中呈现(Presence)业务技术，具体的说涉及一种发布和获取关系型呈现信息的方法及关系型呈现(relational presence)业务系统。

背景技术

Presence业务是一种新兴的通讯业务，可称为呈现业务，现有的presence业务能满足用户两个方面的通讯需求：其一，用户可以向亲朋好友或其它用户实时表达自己的状态，如空闲状态，所处位置，行动计划，情绪状态，终端能力等；其二，用户可以获取亲朋好友或其它用户的实时状态。

现在的通讯系统中，实时通讯占据了越来越大的比例。在这种情况下，presence作为一种业务，也可作为中间件、子系统，其重要性也越来越突出，比如文献1：“Instant Messaging and Presence Technology for College Campuses，IEEENetwork·May/June 2005”中公开的presence业务技术。但是，在通讯系统中，现有的presence服务只提供针对用户的在线信息，支持用户的各种动态信息的扩展，但是，这种扩展范围有限，无论怎样扩展，这种presence信息也只是支持单个用户的信息扩展。因此，现有技术的不足主要表现在两个方面，一个是发布信息较少，另一个是不能支持多个用户/终端之间关系的发布。

实际上，人们一直希望呈现业务能为应用提供更强大的服务能力，比如通过对用户/终端之间各种关系的不同程度的共享，人们可以更好的满足以下需求(并不限于这些)：父母希望监督孩子，需要知道他/她与谁聊天，看什么电视/电影/节目；统计收视率；用户可随时知道自己的好友栏里谁跟谁正在聊天或玩游戏并申请加入；用户可把自己正在某个媒体服务器上看某部电影的信息作为推荐下推给所有其它用户；用户可随时查询其他用户的订阅信息或好友关系等。

因此，就需要一种支持多个用户/终端之间关系的发布的呈现业务系统及发布和获取关系型呈现信息的方法。

发明内容

本发明的目的是提供一种发布和获取关系型呈现信息的方法。

本发明的另一个目的是提供一种关系型呈现业务系统。

本发明的目的是通过下述技术方案来实现的。

一种发布和获取关系型呈现信息的方法，包括：

步骤1：第一关系型呈现客户端向关系型呈现服务器发布用户的关系型呈现信息的全局授权规则；

步骤2：关系型呈现服务器接收全局授权规则并保存起来；

步骤3：第一关系型呈现客户端所对应的用户通讯终端成功的建立了一个会话后，该呈现客户端将该会话关系信息发布到关系型呈现服务器；所述会话关系信息包括会话参与者或会话形式；

步骤4：关系型呈现服务器接收上一步骤3的会话关系信息，进行相应检查认证；

步骤5：用户通过第二关系型呈现客户端设定过滤条件；

步骤6：第二关系型呈现客户端向关系型呈现服务器发送订阅第一关系型呈现客户端的会话关系信息的请求；

步骤7：关系型呈现服务器接收上一步骤6的订阅请求，进行相应检查认证；

步骤8：第二关系型呈现客户端接收并处理关系型呈现服务器发送的关于第一关系型呈现客户端的会话关系信息通知；

步骤9：第一关系型呈现客户端所对应的用户通讯终端结束该会话后，发消息通知关系型呈现服务器；

步骤10：关系型呈现服务器把此消息通知给第二关系型呈现客户端。

进一步地，所述步骤1中的全局授权规则是指与用户相关的，除非用户自行修改设置而固定不变的，作用于此用户的所有关系型呈现信息的授权规则。例如用户可设定任何时候他/她的家庭成员组别都可以访问他/她的任何关系型呈现信息。

进一步地，所述的步骤3具体包括：

步骤31 检查用户设置是否允许本条会话关系信息发布；

步骤32 检查对本条会话关系信息是否配有用户临时设定的局部授权规则，有则把此规则并入消息体一并发送；

步骤33 检查用户是否希望把此条会话关系信息作为下推信息，若是则把下推列表并入消息体一并发送。

所述的步骤32中的局部授权规则，是指与某个会话关系信息相关的，只作用于此会话关系信息的授权规则；局部授权规则是临时性的。例如用户可设定当前正在进行的一次项目组内部视频会议，仅对同事可见。

所述的步骤33中的下推列表，可以是用户的所有好友，也可以是系统中的所有用户。

进一步地，所述的步骤4具体包括：

步骤41 将此会话关系信息保存起来；

步骤42 检查此会话关系信息中涉及到的所有参与者是否也向关系型呈现服务器发布了此会话关系信息，若是，则把所述会话关系信息设为可见，继续执行步骤43，若否，则设为不可见，不执行后面的步骤；

步骤43 对每个会话的参与者，检查其关系型呈现信息是否被订阅，若是，则执行步骤44，若否则执行步骤47；

步骤44 检查此参与者是否对此会话关系信息设定了局部授权规则，若是，则执行步骤45，若否则执行步骤46；

步骤45 对每个订阅者检查是否符合此局部授权规则，若是，则执行步骤46；若否，则执行步骤47；

步骤46 向此订阅者发送关于此会话关系信息的通知；

步骤47 检查此参与者是否加入了一个下推列表，若是，则执行步骤48，若否，则不执行后面的步骤；

步骤48 向下推列表中的用户发送关于此会话关系信息的通知。

所述步骤42替换为：参与此会话关系的用户/终端之间在会话建立阶段进行协商，若参与者都同意发布，则由此会话的发起者向关系型呈现服务器发布此会话关系信息，其它参与者不发布，关系型服务器也不做检查；若其中有参与者反对发布，则不向关系型呈现服务器发布任何消息。

所述的步骤6中，第二关系型呈现客户端对第一关系型呈现客户端的关系型呈现信息的访问除了订阅以外还可以是一次性查询，即服务器只需要向它返回当前第一关系型呈现客户端的关系型呈现信息则可，将来当其发生变化时则不需继续通知第二关系型呈现客户端；

所述的步骤6中，除了会话关系信息可以被作为关系型呈现信息发布以外，还包括订阅本身作为一种关系型呈现信息被外界所访问。因此，当第二关系型呈现客户端订阅第一关系型呈现客户端的关系信息时，它应把关于这次订阅关系是否可以发布的授权规则一并发给服务器。

进一步，所述的步骤7具体包括：

步骤71 检查被订阅者是否设定了全局授权规则，若是，则执行步骤72，若否，则执行步骤73；

步骤72 检查订阅者是否符合此授权规则，若是，则执行步骤73，若否则向订阅者返回订阅失败消息，不执行后面的步骤；

步骤73 把此订阅关系保存起来；

步骤74 向订阅者返回订阅成功消息，并返回一个订阅号；

步骤75 检查被订阅者当前的关系型呈现信息，检查其中的局部授权规则是否允许该订阅者访问此信息，若是，则执行步骤76，若否则不执行后面的步骤；

步骤76 向订阅者发送被订阅者当前的关系型呈现信息。

进一步，所述的步骤8具体包括：

步骤81 检查此关系信息是否带有订阅号，若是，则执行步骤82，若否，则执行步骤83；

步骤82 转交给用户终端显示此信息；

步骤83 检查用户是否设置屏蔽“下推消息”，若是，则丢弃此信息，若否，则执行步骤82。

本发明通过上述技术方案，在原有presence服务的基础上，拓展了呈现信息的提供源(由原来单一用户相关的呈现信息扩展为多用户相关的关系型呈现信息)以及提供方式(由原来的订阅/通知模式扩展为下推模式)，为应用提供更强大的服务能力。通过对用户终端之间各种关系的不同程度的共享，用户可随时知道自己的好友栏里谁跟谁正在聊天或玩游戏并申请加入，可把自己正在某个媒体服务器上看某部电影的信息作为推荐下推给所有其它用户，可随时查询其他用户的订阅信息或好友关系等等。通过以下结合附图对本发明具体实施方式的描述，本发明的特点、目的和效果将变得更加清楚和易于理解。

附图说明

图1关系型呈现业务系统结构框图；

图2关系型呈现服务器的内部结构框图；

图3关系型呈现客户端的内部结构框图；

图4发布和订阅关系型呈现信息的交互图；

图5关系型呈现服务器处理发布的会话关系信息的流程图；

图6关系型呈现服务器处理订阅请求的流程图。

具体实施方式

为了便于本技术领域一般技术人员理解和实现本发明，现结合附图，具体描述本发明在采用sip协议环境下的实施方式。

如图1所示，实现关系型呈现业务系统，包括：

关系型呈现服务器15，用于接收、保存客户端发布的关系型呈现信息，并在接到希望获取关系型呈现信息的请求后，检查授权信息，对其做出回应：返回所请求的关系型呈现信息，或拒绝此访问；

多个关系型客户端，图1中仅示出了三个关系型客户端11、12、13，用于收集用户与其它用户或应用服务器的关系型呈现信息，根据用户的设置，选择性地把这些信息发布到所述关系型呈现服务器上，并过滤其收到的关系型呈现信息。

如图2所示，关系型呈现服务器包括订阅处理装置21，发布处理装置22，认证装置23，用户数据装置27，通知装置26，查询处理装置24以及下推处理装置25，且所述订阅处理装置21分别接受认证装置23、查询处理装置24和用户数据装置27调用，所述发布处理装置22分别接受用户数据装置27、通知装置26和下推处理装置25调用，所述查询处理装置24和认证装置23接受用户数据装置27调用，所述查询处理装置24和下推处理装置25接受所述通知装置26调用。其中带箭头的连线表示的是各装置间的调用关系。服务器收到的订阅请求消息由订阅处理装置处理，订阅处理装置首先把此消息转给认证装置，认证装置再去查询用户数据装置的有关授权规则，检查发送请求的用户是否有权订阅，把结果返回给订阅处理装置，若通过认证，订阅处理装置需把此条订阅关系存放到用户数据装置中，并把此消息转给查询处理装置，查询处理装置访问用户数据装置中的有关信息，并把返回的数据送给通知装置，由它来通知发送订阅请求的用户。服务器收到的会话关系发布消息由发布处理装置处理，它首先把此会话关系存储到用户数据装置中，并查询订阅了此会话关系的相关用户，若此消息含有下推列表，则发布处理装置将其转给下推处理装置，否则直接转给通知装置，下推处理装置抽取出下推列表中的用户后，再转交给通知装置，由通知装置发送通知消息给相关用户。

如图3所示，所述的关系型客户端包括发布过滤器32，接收过滤器31以及观察体33，所述观察体分别与所述发布过滤器和接收过滤器相互调用。

该系统还包括应用服务器14。

下面对关系型呈现服务器的各部分进行详细说明：

所述的订阅处理装置21，当收到希望获取关系型呈现信息的请求(包括订阅和一次性查询)时，首先把此请求转给认证装置，若认证装置认证通过，则把此订阅关系保存到用户数据装置，并把此请求转交给查询处理装置，否则返回给客户端告知此请求失败。

所述的认证装置23，当收到订阅处理装置转交的订阅请求时，向用户数据装置查询相关用户的授权信息，判断是否允许其订阅所请求的内容，把判断结果返回给订阅处理装置。

所述的查询处理装置24，当收到查询请求时，向用户数据装置请求此关系信息，并把用户数据装置返回的内容转交给通知装置。

所述的发布处理装置22，当收到客户端发布到服务器上的关系信息时，把它保存到用户数据装置，并检查此关系信息涉及到的用户是否被订阅以及这些相关用户的授权信息，若通过则转交给通知装置。然后检查其是否包含下推列表，若是也把此关系信息转交给下推处理装置。若没有通过授权则不作任何动作。

所述的下推处理装置25，当收到发布处理装置转交过来的用户主动发布的关系信息时，分析其中的下推列表，此列表很可能包含已经订阅该用户关系信息的用户，因此要把其中已经订阅该用户关系信息的用户去掉，以免重复发送，然后把此信息转交给通知装置。下推处理装置的存在，使得会话关系信息不需要经过对方订阅的步骤，也可给其他用户发送。

所述的通知装置26，当接收到查询处理装置，发布处理装置或下推处理装置转交过来的信息后，把它们发送给目标用户。

所述的用户数据装置27，包括存储用户/终端相关信息的子装置和存储会话关系信息、订阅关系信息子装置两部分。

所述的接收过滤器31，设有让用户配置的选项，过滤掉用户不需要的关系型呈现信息，通常是下推信息。

所述的发布过滤器32，按照用户的设定而生成包含授权信息的需发布的关系型呈现信息，并把它发布到关系型呈现服务器。

所述的观察体33，向关系型呈现服务器发送订阅或一次性查询请求，并接收维护服务器返回的信息。

所述的授权信息，包括哪些用户，在哪些时间段，可以或禁止获取哪类关系型呈现信息。

参照图4，结合上述关系型呈现业务系统实施例，具体的关系型呈现信息订阅和发布方法如下：

步骤1：关系型呈现客户端A的发布过滤器向呈现服务器发送包含全局授权规则的publish消息；

步骤2：关系型呈现服务器接收此授权规则并把它保存到用户数据装置中；并向客户端返回“200 OK”消息；

步骤3：关系型呈现客户端A所对应的用户通讯终端成功的建立了一个会话后，呈现客户端将此会话关系信息(会话参与者，会话形式等)用publish消息发布到呈现服务器；

步骤4：关系型呈现服务器接收上一步骤3的会话关系信息，进行相应检查认证；

步骤5：用户通过关系型呈现客户端B的接收过滤器设定过滤条件；

步骤6：关系型呈现客户端B向呈现服务器发送subscribe消息以订阅关系型呈现客户端A的关系信息；

步骤7：关系型呈现服务器接收上一步骤6的订阅请求，进行相应检查认证；

步骤8：关系型呈现客户端B接收并处理呈现服务器发送的关于客户端A的会话关系信息通知；

步骤9：关系型呈现客户端A所对应的用户通讯终端结束该会话后，发publish消息通知服务器；

步骤10：关系型呈现服务器向客户端B发送notify消息通知其客户端A的会话结束。

其中全局授权规则可保存在用户相关的表格中，例如：

 

user	location	status	Rules
				Eliza	home	on	allow；family；all

局部授权规则则可保存在会话相关的表格中，例如：

 

participants	event	Rules
			Eliza，Darcy	conference	Allow；colleagues

以上的全局授权规则中用户Eliza设定了其家庭成员组别可以访问她的所有关系型呈现信息，但是当她向服务器发布与Darcy正在进行会议的消息时，只希望公司内其它同事看见，所以加上了局部授权规则，这样，这条关系型呈现信息对她的家人也是不可见的。

其中步骤3可细化为：

步骤31 发布过滤器检查用户设置是否允许本条会话关系信息发布；

步骤32 发布过滤器检查对本条会话关系信息是否配有用户临时设定的局部授权规则，有则在publish消息体中增加rule标题头，以存放此规则；

步骤33 发布过滤器检查用户是否希望把此条会话信息作为下推信息，若是则在publish消息体中增加push标题头，存放下推列表。

参照图5，关系型呈现服务器接收publish消息后的处理流程如下：

步骤41 将此会话关系信息保存到用户数据装置中；

步骤42 检查此会话关系信息中涉及到的所有参与者是否也向服务器发布了此会话信息，若是，则把它设为可见，继续执行步骤43，若否则设为不可见，不执行后面的步骤；

步骤43 对每个会话的参与者，检查其关系型呈现信息是否被订阅，若是，则执行步骤44，若否则执行步骤47；

步骤44 检查此参与者是否对此会话关系信息设定了局部授权规则，若是，则执行步骤45，若否则执行步骤46；

步骤45 对每个订阅者检查是否符合此局部授权规则，若是，则执行步骤46；若否，则执行步骤47；

步骤46 向此订阅者发送关于此会话关系信息的notify消息；

步骤47 检查此消息中是否有push标题头，若是，则执行步骤48，若否，则不执行后面的步骤；

步骤48 向下推列表中的用户发送关于此会话关系信息的通知。

所述的步骤42当中，关于发布的会话关系信息是否可见的问题，采用的是服务器检查此会话关系的所有参与者是否都发布了此消息的方法。另外，还允许采取另一种方法，即参与此会话关系的用户/终端之间在会话建立阶段进行协商，若均同意发布，则由此会话的发起者向服务器发布此会话信息，其它参与者不用发布，服务器也不用做检查；若其中有参与者反对发布，则不向服务器发布任何消息。在采取第一种方法的情况下，对于应用服务器，还允许事先向服务器发布一条全局授权规则，表明与它相关的关系信息均同意其可见，则以后不需要每次建立会话后均向服务器发布。

所述的步骤6中，客户端B对客户端A的关系型呈现信息的访问除了订阅以外还可以是一次性查询fetch，即服务器只需要向它返回当前客户端A的关系型呈现信息则可，将来当其发生变化时则不需继续通知客户端B。要发送一次性查询，使用的也是subscribe消息，不同的是要把里面的expire标题头置为0。

所述的步骤6中，除了会话信息可以被作为关系型呈现信息发布以外，订阅本身也是一种关系(订阅者与被订阅者的关系)，所以也可作为一种关系型呈现信息被外界所访问。因此，当客户端B订阅客户端A的关系信息时，它应把授权规则(关于这次订阅关系是否可以发布)一并发给服务器，即在subscribe消息中增加标题头rule。

参考图6，关系型呈现服务器接收subscribe消息后的处理流程如下：

步骤71 检查被订阅者是否设定了全局授权规则，若是，则执行步骤72，若否，则执行步骤73

步骤72 检查订阅者是否符合此授权规则，若是，则执行步骤73，若否则向订阅者返回订阅失败消息401unauthorized，不执行后面的步骤；

步骤73 把此订阅关系保存至用户数据装置中；

步骤74 向订阅者返回订阅成功消息“200ok”，并插入标题头sn存放订阅号；

步骤75 检查被订阅者当前的关系型呈现信息，检查其中的局部授权规则是否允许该订阅者访问此信息，若是，则执行步骤76，若否则不执行后面的步骤；

步骤76 向订阅者发送notify消息告知被订阅者当前的关系型呈现信息。

所述的步骤74中的订阅号是唯一识别一条订阅关系的编号。当用户对一个关系进行第一次订阅时，服务器将为它产生一个订阅号，并发还给终端。这样，当用户想修改或取消此次订阅时，只需要把此订阅号一并发给服务器则可。当用户的订阅事件发生以后，服务器在通知用户的同时，也要附上订阅号，这样客户端可通过订阅号立刻就知道是什么事件或关系发生了。采用订阅号还有一个好处就是“下推消息”是不会有订阅号的，希望屏蔽下推消息的用户可设置关系型呈现客户端，令其丢弃所有没有订阅号的通知。

其中步骤8还可细化为：

步骤81 接收过滤器检查此关系信息是否带有标题头sn，若是，则执行步骤82，若否，则执行步骤83；

步骤82 转交给用户终端显示此信息；

步骤83 检查用户是否设置屏蔽“下推消息”，若是，则丢弃此信息，若否，则执行步骤82。

最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制。尽管参照实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，对本发明的技术方案进行修改或者等同替换，都不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。

Claims (6)

1、一种发布和获取关系型呈现信息的方法，包括：

步骤1：第一关系型呈现客户端向关系型呈现服务器发布用户的关系型呈现信息的全局授权规则；所述全局授权规则是指与用户相关的，除非用户自行修改设置而固定不变的，作用于此用户的所有关系型呈现信息的授权规则；

步骤2：关系型呈现服务器接收全局授权规则并保存起来；

步骤3：第一关系型呈现客户端所对应的用户通讯终端成功的建立了一个会话后，该呈现客户端将该会话关系信息发布到关系型呈现服务器；所述会话关系信息包括会话参与者或会话形式；

步骤4：关系型呈现服务器接收上一步骤3的会话关系信息，进行相应检查认证；

步骤5：用户通过第二关系型呈现客户端设定过滤条件；

步骤6：第二关系型呈现客户端向关系型呈现服务器发送订阅第一关系型呈现客户端的会话关系信息的请求；

步骤7：关系型呈现服务器接收上一步骤6的订阅请求，进行相应检查认证；

步骤8：第二关系型呈现客户端接收并处理关系型呈现服务器发送的关于第一关系型呈现客户端的会话关系信息通知；

步骤9：第一关系型呈现客户端所对应的用户通讯终端结束该会话后，发消息通知关系型呈现服务器；

步骤10：关系型呈现服务器把此消息通知给第二关系型呈现客户端。

2、根据权利要求1所述发布和获取关系型呈现信息的方法，其特征在于，所述步骤3具体包括：

步骤31：检查用户设置是否允许本条会话关系信息发布；

步骤32：检查对本条会话关系信息是否配有用户临时设定的局部授权规则，有则把此局部授权规则并入消息体一并发送；

步骤33：检查用户是否希望把此条会话关系信息作为下推信息，若是则把下推列表并入消息体一并发送；

所述步骤32中的局部授权规则，是指与某个会话关系信息相关的，只作用于此会话关系信息的授权规则。

3、根据权利要求1所述发布和获取关系型呈现信息的方法，其特征在于，所述步骤4具体包括：

步骤41：将此会话关系信息保存起来；

步骤42：检查此会话关系信息中涉及到的所有参与者是否也向关系型呈现服务器发布了此会话关系信息，若是，则把所述会话关系信息设为可见，继续执行步骤43，若否，则设为不可见，不执行后面的步骤；

步骤43：对每个会话的参与者，检查其关系型呈现信息是否被订阅，若是，则执行步骤44，若否则执行步骤47；

步骤44：检查此参与者是否对此会话关系信息设定了局部授权规则，若是，则执行步骤45，若否则执行步骤46；

步骤45：对每个订阅者检查是否符合此局部授权规则，若是，则执行步骤46；若否，则执行步骤47；

步骤46：向此订阅者发送关于此会话关系信息的通知；

步骤47：检查此参与者是否加入了一个下推列表，若是，则执行步骤48，若否，则不执行后面的步骤；

步骤48：向下推列表中的用户发送关于此会话关系信息的通知。

4、根据权利要求3所述发布和获取关系型呈现信息的方法，其特征在于，所述步骤42替换为：参与此会话关系的用户/终端之间在会话建立阶段进行协商，若参与者都同意发布，则由此会话的发起者向关系型呈现服务器发布此会话关系信息，其它参与者不发布，关系型呈现服务器也不做检查；若其中有参与者反对发布，则不向关系型呈现服务器发布任何消息。

5、根据权利要求1所述发布和获取关系型呈现信息的方法，其特征在于，所述步骤6中，除了会话关系信息被作为关系型呈现信息发布以外，还包括订阅本身作为一种关系型呈现信息被外界所访问；第二关系型呈现客户端对第一关系型呈现客户端的关系型呈现信息的访问除了订阅以外还包括一次性查询；其中，所述的一次性查询是指关系型呈现服务器只需要向第二关系型呈现客户端返回当前第一关系型呈现客户端的信息，将来当第一关系型呈现客户端的关系型呈现信息发生变化时不需要继续通知第二关系型呈现客户端。

6、根据权利要求1所述发布和获取关系型呈现信息的方法，其特征在于，所述的步骤7具体包括：

步骤71：检查被订阅者是否设定了全局授权规则，若是，则执行步骤72，若否，则执行步骤73；

步骤72：检查订阅者是否符合步骤71所述的全局授权规则，若是，则执行步骤73，若否则向订阅者返回订阅失败消息，不执行后面的步骤；

步骤73：把此订阅关系保存起来；

步骤74：向订阅者返回订阅成功消息，并返回一个订阅号；

步骤75：检查被订阅者当前的关系型呈现信息，检查其中的局部授权规则是否允许该订阅者访问此关系型呈现信息，若是，则执行步骤76，若否则不执行后面的步骤；

步骤76：向订阅者发送被订阅者当前的关系型呈现信息；

所述步骤8具体包括：

步骤81：检查此会话关系信息是否带有订阅号，若是，则执行步骤82，若否，则执行步骤83；

步骤82：转交给用户终端显示此关系型呈现信息；

步骤83：检查用户是否设置屏蔽“下推消息”，若是，则丢弃此关系型呈现信息，若否，则执行步骤82。

Images