CN111984994A - 一种账号下角色与私密信息流关联的方法 - Google Patents

Abstract

本发明涉及一种基于多角色账号系统下的账号下角色与私密信息流关联的方法，该方法在服务器接收某一账号下的某一角色作为发起角色所发送的私密信息流创建请求，针对所述申请创建请求，在私密信息流索引数据库中根据发起角色提交的请求信息创建私密信息流索引，在角色数据库中写入所述私密信息流索引，将所述私密信息流索引与其对应的角色相关联；并在所述私密信息流索引数据库中写入提交创建请求的角色索引，将所述角色索引与其对应的私密信息流索引进行关联。本发明的账号体系可以容纳多个不同的角色，当使用者在私密信息流中发表信息时，可以选择账号下的任意角色与任意信息流关联，而不是传统账号体系中的账号与信息流关联。

Description

一种账号下角色与私密信息流关联的方法

技术领域

本发明涉及网络信息技术领域，具体涉及一种基于多角色账号系统下的账号下角色与私密信息流关联的方法。

背景技术

现有的账号体系，无论是类似QQ、微信那样为代表的即时通信软件，还是类似百度贴吧、论坛那样为代表的非即时通信软件，所使用的账号体系都一样，每个账号体系即代表账号使用者本人，账号的头像、名称等数据固定不变，无论是在私密信息流还是非私密信息流中发消息，消息的发送者都是该账号本体——即，使用者想要在信息流中扮演不同的角色，必须注册多个名称、头像等各不相同的账号，通过切换账号轮流发言，才能实现。

如，现有账号体系下，张三注册了一个QQ号，头像名字都是张三，那么张三无论是在QQ群里聊天，还是在QQ空间中发表动态，这些消息的发送者看起来得都是本体——张三。如果他想要自己一个人营造出一种“张三与李四在一起讨论话题”的氛围，他就必须再注册一个QQ号，将头像名字写成李四，通过在QQ群中或QQ空间中，不停切换“张三”、“李四”QQ号轮流发言，才能实现。而不停切换账号、重复输入账号密码、等待登录的过程显然是十分繁琐而且枯燥的步骤；而且，切换一个QQ号，另一个QQ号必然下线，QQ号在下线的时候无法及时收到他人发送的消息。

技术名词解释：

角色：一种虚拟的形象，是使用者参与网络中社交或游戏等活动中的虚拟的、匿名的化身，使用者们在网络中以各种各样的角色作为身份，来与其他各种各样的角色进行聊天、交流或游戏。角色可以分为有形角色和无形角色，有形角色往往指代那些拥有图片、3D图形或声音等看得见、听得到的视觉、听觉形象；无形角色往往指代那些只有简单的名称、简介的文字形象。

账号：使用者进行网络中社交或游戏等活动的电子凭证，账号下可以容纳多个角色，若要在某个应用程序中进行社交或游戏等活动，使用者必须先登录账号，才能进而使用账号下的角色进行社交或游戏等活动。

数据信息流：简称信息流，分为私密信息流和非私密信息流。当一个或多个账号以某种形式关联在一起，分享一条或多条聊天、图片、音频等消息，这些账号与这些消息就形成了一种私密的或非私密的信息流。

私密信息流：类似QQ、微信等即时聊天软件中的“会话”，当一个或多个账号之间进行交流时，会通过创建一个“会话”作为私密信息流的入口，在这个信息流中消息是私密的，任何一方发送的任何一条消息，都会瞬间送达到任何已经关联至该私密信息流的账号中，未与该私密信息流关联的账号不会收到该消息。

角色索引：角色索引即为服务器端的角色数据库中，创建一个新角色的详细数据时，数据库自动分配的唯一id。服务端可以通过这个唯一id查询数据库，快速取出该角色的详细数据。

私密信息流索引：同角色索引，为服务器端的私密信息流数据库中，创建一个私密信息流的详细数据时，数据库自动分配的唯一id。

发明内容

本发明针对现有技术中存在的技术问题，提供一种基于多角色账号系统下的账号下角色与私密信息流关联的方法。

本发明解决上述技术问题的技术方案如下：

一种账号下角色与私密信息流关联的方法，包括以下步骤：

服务器接收某一账号下的某一角色作为发起角色所发送的私密信息流创建请求，根据创建请求类型，创建私密信息流索引并进行账号下角色与私密信息流的关联操作；其中服务器中设置有私密信息流索引数据库、角色数据库、私密信息流内容数据库；所述的创建请求类型包括：申请创建请求；

针对所述申请创建请求，在私密信息流索引数据库中根据发起角色提交的请求信息创建私密信息流索引，并进行第一关联操作；

所述的第一关联操作包括：在角色数据库中写入所述私密信息流索引，将所述私密信息流索引与其对应的角色相关联；并在所述私密信息流索引数据库中写入提交创建请求的角色索引，将所述角色索引与其对应的私密信息流索引进行关联。

本发明的有益效果是：本发明的账号体系可以容纳多个不同的角色，当使用者在私密信息流中发表信息时，可以选择账号下的任意角色与任意信息流关联，而不是传统账号体系中的账号与信息流关联。

进一步的，在所述的创建私密信息流索引并进行账号下角色与私密信息流的关联操作之前，还包括：

服务器进行针对发起角色的角色-账号联合封禁判断，若发起角色及其账号均非“封禁”状态，则创建私密信息流索引并进行账号下角色与私密信息流的关联操作，否则服务器拒绝创建请求；

所述的角色-账号联合封禁判断，指：先进行角色封禁判断然后对角色关联的账号进行账号封禁判断；

所述的封禁判断，指：查看角色或账号是否被系统标记为“封禁”，若角色被标记“封禁”则封禁角色不能在任何信息流中发表内容，若账号封禁则封禁账号下的所有角色均不能在任何信息流中发表内容。

进一步的，所述的创建请求类型还包括：邀请创建请求；所述邀请创建请求中包括除发起角色外的其他一个或多个角色的索引，所述的发起角色外的其他一个或多个角色定义为目标角色；

针对所述邀请创建请求

1)遍历邀请创建请求中每一个目标角色，从角色数据库中根据目标角色的索引取出目标角色的详细数据，其中包括但不限于角色名称、头像、编号、等级、好友列表等；

2)判断发起角色与目标角色是否处于同一账号，若是则跳转至步骤5)，否则跳转至步骤3)；

3)判断发起角色是否为目标角色的好友，若是则跳转至步骤5)，否则执行下一步操作；

4)判断目标角色是否拒接陌生人消息；若是则终止创建；否则跳转至步骤5)；

5)在私密信息流索引数据库中根据发起角色提交的请求信息创建私密信息流索引，并进行第二关联操作；

所述的第二关联操作包括：在角色数据库中写入所述私密信息流索引，将所述私密信息流索引与其相对应的发起角色和目标角色关联；在私密信息流索引数据库中写入发起角色索引和目标角色索引，将所述发起角色索引和目标角色索引与两者相对应的私密信息流索引关联。

进一步的，针对所述邀请创建请求，若发起角色与目标角色是否处于同一账号的判断结果为否，则对目标角色及其所属账号进行角色-账号封禁判断；若目标角色及其所属账号均非“封禁”状态，则创建私密信息流索引并进行账号下角色与私密信息流的关联操作，否则服务器拒绝创建请求。

进一步的，该方法还包括：

服务器接收私密信息流关联的某一账号发送的角色添加请求或删除请求；

服务器对该私密信息流进行封禁判断，若私密信息流非“封禁”状态，则响应所述角色添加请求或删除请求：

针对角色添加请求，服务器首先判断私密信息流中是否已存在待添加的角色；若存在则终止操作，否则将角色添加请求发送给私密信息流的创建者角色；服务器接收到私密信息流的创建者角色反馈的“允许添加”消息通知后，将待添加角色的索引添加入所述私密信息流索引中并以此更新私密信息流索引数据库；

针对角色删除请求，服务器首先判断私密信息流中是否存在待删除的角色，若存在，则将待删除的角色的索引从所述私密信息流索引中删除，并以此更新私密信息流索引数据库。

进一步的，该方法还包括：

服务器接收私密信息流关联的某一角色的数据发送请求；

服务器进行角色-账号联合封禁判断及信息流封禁判断，封禁判断通过后则响应所述数据发送请求，并将待发送数据转发至所述私密信息流所关联的其他角色；

所述的将待发送数据转发至所述私密信息流所关联的其他角色，包括：

对所述私密信息流所关联的其他角色进行筛选并建立临时账号-角色索引记录，筛选条件包括角色-账号联合封禁判断结果以及是否屏蔽所述私密信息流消息，若角色及其所属账号均非“封禁”且未屏蔽所述私密信息流消息，则将该角色存入临时账号-角色索引记录中；

服务器将所述待发送数据转发至所述临时账号-角色索引记录中的每一角色。

进一步的，所述的服务将所述待发送数据转发至所述临时账号-角色索引记录中的每一个角色，包括：

S701，服务器从临时账号-角色索引记录中，分别取出已记录的账号及其下属的、位于所述私密信息流的角色索引；

S702，服务器将待发送数据存入私密信息流内容数据库中；

S703，服务器记录所述待发送数据的发送者，以便根据发送者角色的索引，查询获取发送者角色所发表过的内容；记录待发送数据所属的私密信息流索引，以便根据私密信息流索引查询获得在该私密信息流中所发表过的内容；

S704，服务器通过私密信息流将待发送数据发送给步骤S701中所取出的角色索引中的各个角色；

S705，服务器生成一条通知，根据步骤S701中所取出的角色索引，在所述通知中加入角色信息，并通过网络推送将加入角色信息的通知发送给相应的账号。

进一步的，该方法还包括：服务器响应角色发送的内容查看请求，具体包括：

服务器接收某一账号下的某一角色发送的某一私密信息流的内容查看请求；

对发送请求的角色及其所属账号进行角色-账号联合封禁判断，同时对其请求查看的私密信息流进行封禁判断；

若判断结果为角色、账号以及私密信息流均非“封禁”，则判断发送请求的角色是否已添加入请求查看的私密信息流的角色列表中；

若已添加，则将请求查看的私密信息流中所有的消息内容依次返回给目标角色；否则忽略此次请求。

具体实施方式

以下结合实施例对本发明的原理和特征进行描述，所举实例只用于解释本发明，并非用于限定本发明的范围。

本发明实施例提供一种基于多角色账号系统下的账号下角色与私密信息流关联的方法。这里所谓的多角色账号系统是指，用户通过多角色账号系统注册的一个账户时，在该账户下可以创建多个角色。在该系统下信息的传递一般为角色与角色之间的信息传递，而某一角色接收到消息时，系统会将该消息推送给该该角色所属的账号。

为了方便解释说明本发明实施例，首先对多角色账号系统的账号与角色的创建与关联关系进行说明。

用户在进行账号注册时，需提供手机号、密码验证码等信息；服务器收到账号注册申请后，会检测账号数据库中是否存在相同的手机号；如果有则拒绝注册，如果无则在账号数据库中根据用户提交的申请信息，创建一个账号。

账号注册(创建)成功后，用户需要提交名称、头像图片、简介、设定、编号等信息以创建角色信息。服务器收到申请后，会检查角色数据库中是否有名称、头像、简介、设定、编号等重复信息。如果有，则拒绝创建；如果无，在角色数据库中根据用户提交的申请信息，创建一个角色，并进行如下关联操作：

1.在角色数据库中该角色数据中记录该账号索引，使得服务器能够根据该角色获得其所属账号的信息；

2.同时在账号数据库中该账号数据中记录该角色索引，使得服务器能够根据该账号获得其下属所有角色的信。

多角色账号系统中为了便于管理以及保护用户的隐私，可以设置各种权限。其主要表现为“封禁”状态、黑白名单等等。本文中仅以“封禁”状态作为权限判断。

当某项检查判断遭遇“封禁”状态时，会立刻中止该检查及其后续所有步骤，视为操作失败；否则会继续进行下一个步骤。其中根据对象不同包括以下几种封禁判断：

a)角色封禁判断

服务器会根据指定角色的索引信息，从角色数据库中取出对应角色的详细数据，如果数据中已经标记为“封禁”，则视为该角色已经被封禁。

被封禁的角色不能在任何信息流中发表内容。

b)账号封禁判断

服务器会根据指定账号的索引信息，从账号数据库中取出对应账号的详细数据，如果数据中已经标记为“封禁”，则视为该账号已经被封禁。

被封禁的账号下的所有角色，均不能在任何信息流中发表内容。

c)角色-账号联合封禁判断

类似于a)和b)，服务器会先进行角色封禁判断，然后从角色数据中关联的账号索引，进行账号封禁判断。

d)信息流封禁判断

服务器会根据指定信息流的索引信息，从私密或非私密信息流索引数据库中取出对应信息流的详细数据，如果数据中已经标记为“封禁”，则视为该信息流已经被封禁。

被封禁的信息流，任何角色都不能再往其中发表内容。

基于多角色账号系统，本发明实施例所提供的一种账号下角色与私密信息流关联的方法，具体包括以下步骤：

服务器接收某一账号下的某一角色作为发起角色所发送的私密信息流创建请求，根据创建请求类型，创建私密信息流索引并进行账号下角色与私密信息流的关联操作；

其中服务器中设置有私密信息流索引数据库、角色数据库、私密信息流内容数据库；

所述的创建请求类型包括：申请创建请求和邀请创建请求；

针对所述申请创建请求，在私密信息流索引数据库中根据发起角色提交的请求信息创建私密信息流索引，并进行第一关联操作。

申请信息包括信息流名称、图标、简介、编号等。

服务器收到申请后，会进行角色-账号联合封禁判断；之后会检查私密信息流索引数据库中是否有名称、图标、简介、编号等重复信息；如果有，则拒绝创建，并终止创建步骤，如果无，在私密信息流索引数据库中根据用户提交的申请信息，创建一个私密信息流索引，并进行第一关联操作。

所述的第一关联操作包括：在角色数据库中写入所述私密信息流索引，将所述私密信息流索引与其对应的角色相关联；并在所述私密信息流索引数据库中写入提交创建请求的角色索引，将所述角色索引与其对应的私密信息流索引进行关联。

所述邀请创建请求中包括除发起角色外的其他一个或多个角色的索引，所述的发起角色外的其他一个或多个角色定义为目标角色。

针对邀请创建请求，服务器在收到该请求后，首先会进行角色-账号联合封禁判断。之后会遍历邀请创建请求中的每一个目标角色进行如下检查：

1)遍历邀请创建请求中每一个目标角色，从角色数据库中根据目标角色的索引取出目标角色的详细数据；所述详细数据包括但不限于角色名称、头像、编号、等级、好友列表等。

2)判断发起角色与目标角色是否处于同一账号，若是则跳转至步骤5)，否则跳转至步骤3)；

3)判断发起角色是否为目标角色的好友，若是则跳转至步骤5)，否则执行下一步操作；

4)判断目标角色是否拒接陌生人消息；若是则终止创建；否则跳转至步骤5)；

5)在私密信息流索引数据库中根据发起角色提交的请求信息创建私密信息流索引，并进行第二关联操作；

所述的第二关联操作包括：在角色数据库中写入所述私密信息流索引，将所述私密信息流索引与其相对应的发起角色和目标角色关联；在私密信息流索引数据库中写入发起角色索引和目标角色索引，将所述发起角色索引和目标角色索引与两者相对应的私密信息流索引关联。

进一步的，该方法还包括：服务器接收私密信息流关联的某一账号发送的角色添加请求或删除请求；

服务器对该私密信息流进行封禁判断，若私密信息流非“封禁”状态，则响应所述角色添加请求或删除请求：

针对角色添加请求，服务器首先判断私密信息流中是否已存在待添加的角色；若存在则终止操作，否则将角色添加请求发送给私密信息流的创建者角色；服务器接收到私密信息流的创建者角色反馈的“允许添加”消息通知后，将待添加角色的索引添加入所述私密信息流索引中并以此更新私密信息流索引数据库；若服务器接收到私密信息流的创建者角色反馈的消息通知为“不允许”，则服务器拒绝本次角色添加请求。

针对角色删除请求，服务器首先判断私密信息流中是否存在待删除的角色，若存在，则将待删除的角色的索引从所述私密信息流索引中删除，并以此更新私密信息流索引数据库。

当使用者账号的多个角色，都存在于某一私密信息流中时，在该私密信息流发表内容前，可以选择任意一个角色进行发言，无需切换账号即可实现切换角色的效果。

进一步的，该方法还包括私密信息流中的消息发送方法，包括以下内容：

当服务器接收私密信息流关联的某一角色的数据发送请求时，服务器进行角色-账号联合封禁判断及信息流封禁判断，封禁判断通过后则响应所述数据发送请求，并将待发送数据转发至所述私密信息流所关联的其他角色。

所述的将待发送数据转发至所述私密信息流所关联的其他角色，包括：

对所述私密信息流所关联的其他角色进行筛选并建立临时账号-角色索引记录，筛选条件包括角色-账号联合封禁判断结果以及是否屏蔽所述私密信息流消息，若角色及其所属账号均非“封禁”且未屏蔽所述私密信息流消息，则将该角色存入临时账号-角色索引记录中；

服务器将所述待发送数据转发至所述临时账号-角色索引记录中的每一角色。

具体的，上述的筛选方法如下：

i.判断该角色是否为发送者角色，若是则略过该角色筛选流程，继续筛选下一个角色；否则继续进行下一筛选步骤；

ii.对该角色及其所属账号进行角色-账号联合封禁判断；

iii.判断该角色是否屏蔽了该目标信息流的消息，若已经屏蔽，则略过该角色筛选流程，继续筛选下一个角色；否则继续进行下一个筛选步骤；

iv.将该角色关联的账号索引，以及该角色的索引，存入另一个临时的账号-角色索引记录，记录该账号下属的角色当中，只处于该信息流中的角色索引；

v.判断是否已遍历完所有角色，如果是，则完成筛选步骤，否则继续跳转至i遍历检查下一个角色。

优选的，所述的服务将所述待发送数据转发至所述临时账号-角色索引记录中的每一个角色，包括：

S701，服务器从临时账号-角色索引记录中，分别取出已记录的账号及其下属的、位于所述私密信息流的角色索引；

S702，服务器将待发送数据存入私密信息流内容数据库中；

S703，服务器记录所述待发送数据的发送者，以便根据发送者角色的索引，查询获取发送者角色所发表过的内容；记录待发送数据所属的私密信息流索引，以便根据私密信息流索引查询获得在该私密信息流中所发表过的内容；

S704，服务器通过私密信息流将待发送数据发送给步骤S701中所取出的角色索引中的各个角色；

S705，服务器生成一条通知，根据步骤S701中所取出的角色索引，在所述通知中加入角色信息，并通过网络推送将加入角色信息的通知发送给相应的账号。

举例说明：

假设有两个账号A和B，账号A下有A1、A2、A3三个角色，账号B下有B1、B2两个角色；有一个私密信息流Z，Z中存在角色A1、A2、B1三个角色。

则经过上述筛选步骤，服务器将生成一个临时的账号-角色索引记录A-(A1、A2)，B-(B1)。

最后结果为，服务器将给账号A发送消息，告知A下属的角色A1、A2在信息流Z中收到了消息，以及给账号B发送消息，告知B下属的角色B1在信息流Z中收到了消息，账号A的角色A3、账号B的角色B2，因为不在信息流Z中，所以没有收到消息。

此发明点与其他技术的区别在于，其他账号体系会直接通知某个账号收到了消息，消息的接收者是账号本身；

而本发明是通知某个账号下属的某个或某几个角色收到了消息，消息的接收者不是账号本身，而是账号下属的角色，账号的作用仅仅是中转和提醒“zzz角色收到了消息”；以及，本发明通过上述筛选和过滤流程，将原本需要直接给多个角色发送的消息，优化为只需要给这些角色的账号发送消息，减少了消息发送量，也减少了系统在发送消息过程中需要消耗的时间和资源，提升了消息发送效率。

进一步的，本方法还包括：服务器响应角色发送的内容查看请求，具体包括：

服务器接收某一账号下的某一角色发送的某一私密信息流的内容查看请求；

对发送请求的角色及其所属账号进行角色-账号联合封禁判断，同时对其请求查看的私密信息流进行封禁判断；

若判断结果为角色、账号以及私密信息流均非“封禁”，则判断发送请求的角色是否已添加入请求查看的私密信息流的角色列表中；

若已添加，则将请求查看的私密信息流中所有的消息内容依次返回给目标角色；否则忽略此次请求。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种账号下角色与私密信息流关联的方法，其特征在于，包括以下步骤：

服务器接收某一账号下的某一角色作为发起角色所发送的私密信息流创建请求，根据创建请求类型，创建私密信息流索引并进行账号下角色与私密信息流的关联操作；其中服务器中设置有私密信息流索引数据库、角色数据库、私密信息流内容数据库；所述的创建请求类型包括：申请创建请求；

针对所述申请创建请求，在私密信息流索引数据库中根据发起角色提交的请求信息创建私密信息流索引，并进行第一关联操作；

所述的第一关联操作包括：在角色数据库中写入所述私密信息流索引，将所述私密信息流索引与其对应的角色相关联；并在所述私密信息流索引数据库中写入提交创建请求的角色索引，将所述角色索引与其对应的私密信息流索引进行关联。

2.根据权利要求1所述的方法，其特征在于，在所述的创建私密信息流索引并进行账号下角色与私密信息流的关联操作之前，还包括：

服务器进行针对发起角色的角色-账号联合封禁判断，若发起角色及其账号均非“封禁”状态，则创建私密信息流索引并进行账号下角色与私密信息流的关联操作，否则服务器拒绝创建请求；

所述的角色-账号联合封禁判断，指：先进行角色封禁判断然后对角色关联的账号进行账号封禁判断；

所述的封禁判断，指：查看角色或账号是否被系统标记为“封禁”，若角色被标记“封禁”则封禁角色不能在任何信息流中发表内容，若账号封禁则封禁账号下的所有角色均不能在任何信息流中发表内容。

3.根据权利要求1或2所述的方法，其特征在于，所述的创建请求类型还包括：邀请创建请求；所述邀请创建请求中包括除发起角色外的其他一个或多个角色的索引，所述的发起角色外的其他一个或多个角色定义为目标角色；

针对所述邀请创建请求

1)遍历邀请创建请求中每一个目标角色，从角色数据库中根据目标角色的索引取出目标角色的详细数据，所述详细数据包括角色名称、头像、编号、等级、好友列表；

2)判断发起角色与目标角色是否处于同一账号，若是则跳转至步骤5)，否则跳转至步骤3)；

3)判断发起角色是否为目标角色的好友，若是则跳转至步骤5)，否则执行下一步操作；

4)判断目标角色是否拒接陌生人消息；若是则终止创建；否则跳转至步骤5)；

5)在私密信息流索引数据库中根据发起角色提交的请求信息创建私密信息流索引，并进行第二关联操作；

所述的第二关联操作包括：在角色数据库中写入所述私密信息流索引，将所述私密信息流索引与其相对应的发起角色和目标角色关联；在私密信息流索引数据库中写入发起角色索引和目标角色索引，将所述发起角色索引和目标角色索引与两者相对应的私密信息流索引关联。

4.根据权利要求3所述的方法，其特征在于，针对所述邀请创建请求，若发起角色与目标角色是否处于同一账号的判断结果为否，则对目标角色及其所属账号进行角色-账号封禁判断；若目标角色及其所属账号均非“封禁”状态，则创建私密信息流索引并进行账号下角色与私密信息流的关联操作，否则服务器拒绝创建请求。

5.根据权利要求1所述的方法，其特征在于，该方法还包括：

服务器接收私密信息流关联的某一账号发送的角色添加请求或删除请求；

服务器对该私密信息流进行封禁判断，若私密信息流非“封禁”状态，则响应所述角色添加请求或删除请求：

针对角色添加请求，服务器首先判断私密信息流中是否已存在待添加的角色；若存在则终止操作，否则将角色添加请求发送给私密信息流的创建者角色；服务器接收到私密信息流的创建者角色反馈的“允许添加”消息通知后，将待添加角色的索引添加入所述私密信息流索引中并以此更新私密信息流索引数据库；

针对角色删除请求，服务器首先判断私密信息流中是否存在待删除的角色，若存在，则将待删除的角色的索引从所述私密信息流索引中删除，并以此更新私密信息流索引数据库。

6.根据权利要求1所述的方法，其特征在于，该方法还包括：

服务器接收私密信息流关联的某一角色的数据发送请求；

服务器进行角色-账号联合封禁判断及信息流封禁判断，封禁判断通过后则响应所述数据发送请求，并将待发送数据转发至所述私密信息流所关联的其他角色；

所述的将待发送数据转发至所述私密信息流所关联的其他角色，包括：

对所述私密信息流所关联的其他角色进行筛选并建立临时账号-角色索引记录，筛选条件包括角色-账号联合封禁判断结果以及是否屏蔽所述私密信息流消息，若角色及其所属账号均非“封禁”且未屏蔽所述私密信息流消息，则将该角色存入临时账号-角色索引记录中；

服务器将所述待发送数据转发至所述临时账号-角色索引记录中的每一角色。

7.根据权利要求6所述的方法，其特征在于，所述的服务将所述待发送数据转发至所述临时账号-角色索引记录中的每一个角色，包括：

S701，服务器从临时账号-角色索引记录中，分别取出已记录的账号及其下属的、位于所述私密信息流的角色索引；

S702，服务器将待发送数据存入私密信息流内容数据库中；

S703，服务器记录所述待发送数据的发送者，以便根据发送者角色的索引，查询获取发送者角色所发表过的内容；记录待发送数据所属的私密信息流索引，以便根据私密信息流索引查询获得在该私密信息流中所发表过的内容；

S704，服务器通过私密信息流将待发送数据发送给步骤S701中所取出的角色索引中的各个角色；

S705，服务器生成一条通知，根据步骤S701中所取出的角色索引，在所述通知中加入角色信息，并通过网络推送将加入角色信息的通知发送给相应的账号。

8.根据权利要求1所述的方法，其特征在于，该方法还包括：服务器响应角色发送的内容查看请求，具体包括：

服务器接收某一账号下的某一角色发送的某一私密信息流的内容查看请求；

对发送请求的角色及其所属账号进行角色-账号联合封禁判断，同时对其请求查看的私密信息流进行封禁判断；

若判断结果为角色、账号以及私密信息流均非“封禁”，则判断发送请求的角色是否已添加入请求查看的私密信息流的角色列表中；

若已添加，则将请求查看的私密信息流中所有的消息内容依次返回给目标角色；否则忽略此次请求。