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

Abstract

本发明涉及一种基于多角色账号系统下的账号下角色与非私密信息流关联的方法，服务器接收某一角色所发送的非私密信息流内容；根据所述非私密信息流内容创建非私密信息流，并将所述非私密信息流内容存储至相应的数据库；在该数据库中记录发送非私密信息流内容的角色的索引，并将其与存储的非私密信息流内容进行关联；根据服务器所创建的非私密信息流创建非私密信息流索引，并将所述非私密信息流索引存储至相应的数据库；在该数据库中记录发送非私密信息流内容的角色的索引，并将其与存储的非私密信息流索引进行关联。本发明的账号体系可以容纳多个不同的角色，当使用者在非私密信息流中发表信息时，可以选择账号下的任意角色与任意信息流关联。

Description

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

技术领域

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

背景技术

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

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

技术名词解释：

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

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

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

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

非私密信息流：类似QQ空间、百度贴吧或论坛中的“帖子”，不同于私密信息流只能将信息发送给关联的账号，非私密信息流的接收方是不固定的、公开的的；当非私密信息流中任何一方发送任何一条消息时，已经与该非私密信息流关联的账号仍然会收到该消息，但未关联的账号仍然可以自行搜索查阅这个信息流中的所有历史消息。

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

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

发明内容

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

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

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

S1，服务器接收某一账号下的某一角色所发送的非私密信息流内容；

S2，根据所述非私密信息流内容创建非私密信息流，并将所述非私密信息流内容存储至相应的数据库；在该数据库中记录发送非私密信息流内容的角色的索引，并将其与存储的非私密信息流内容进行关联；

S3，根据服务器所创建的非私密信息流创建非私密信息流索引，并将所述非私密信息流索引存储至相应的数据库；在该数据库中记录发送非私密信息流内容的角色的索引，并将其与存储的非私密信息流索引进行关联。

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

服务器接收某一账号下的某一角色所发送的非私密信息流内容后，对该角色及其所属账号进行角色-账号联合封禁判断；

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

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

进一步的，该方法还包括：非私密信息流的消息发送；

S301，服务器接收内容发送者发表的一条非私密信息流的内容即回复内容，所述回复内容中包含内容发送者指定的回复目标；所述内容发送者为某一账号下的某一角色；所述回复目标包括非私密信息流的索引或非私密信息流中已存在的某条消息的内容；

S302，服务器在接收内容发送者发表的回复内容后，对所述内容发送者进行角色-账号封禁判断；

S303，服务器判断内容发送者指定的回复目标的类型，若所述回复目标的类型为非私密信息流的索引，则服务器判定内容发送者的回复目标，是整个非私密信息流中的第一条的内容；若所述回复目标的类型为非私密信息流中已存在的某条消息的内容，则服务器判定内容发送者的回复目标，是该条消息的内容；根据判断结果提取非私密信息流索引或者非私密信息流内容所关联的角色索引；

S304，服务器根据回复目标，将内容发送者发表的回复内容添加至目标非私密信息流内容队列的尾部，并写入相应的数据库中。

进一步的，在步骤304之后，还包括以下步骤：

步骤305，服务器根据提取的非私密信息流索引或者非私密信息流内容所关联的角色索引从账号数据库中提取角色所属的账号详细信息；

步骤306，服务器生成通知数据，并通过网络推送将所述通知数据发送给步骤305所提取的账号；所述通知数据包括步骤S303所提取的角色索引、内容发送者以及回复内容。

进一步的，在步骤305之后还包括，对角色、账号进行判断；具体包括：

步骤3051，判断所述角色索引中所包含的角色是否为内容发送者，若是则终止后续步骤，否则对所述角色索引中所包含的角色及其所述账号进行角色-账号联合封禁判断；若所述联合封禁判断结果非“被封禁”则跳转至步骤3052，否则终止后续步骤；

步骤3052，判断非“被封禁”状态的角色是否屏蔽目标非私密信息流的消息，若已屏蔽则终止后续步骤，否则跳转至步骤306。

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

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

若判断结果为角色、账号以及非私密信息流均非“被封禁”，则将请求查看的非私密信息流中的所有消息内容依次返回给所述发送内容查看请求的角色。

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

如，使用本发明，张三就可以申请一个本发明体系的账号，然后在账号下创建两个角色，一个叫“张三”，另一个叫“李四”，那么在本发明体系中的非私密信息流(类似于QQ空间)，不论是想扮演“张三”还是“李四”，只需要极少量的触控点击操作，即可快捷更换角色，无需再切换账号；而且，因为无需切换账号，不存在下线的问题，无论是正在扮演“张三”还是“李四”，其他人发给“李四”或者“张三”的消息都能及时收到。

具体实施方式

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

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

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

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

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

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

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

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

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

a)角色封禁判断

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

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

b)账号封禁判断

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

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

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

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

d)信息流封禁判断

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

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

基于多角色账号系统，本发明实施例所提供的一种账号下角色与非私密信息流关联的方法，本发明实施例中使用不同的数据库分别存储非私密信息流的索引、实际信息内容。

具体的该方法包括以下步骤：

S1，使用者可以使用一个账号下的一个角色，通过本发明的应用程序，向服务器直接发表一条非私密信息流的内容(诸如文本、图片、语音、视频等)；

S2，服务器在收到使用者提交的内容后，会对该角色与其所属账号进行角色-账号联合封禁判断；

S3，服务器根据使用者提交的内容，创建一个非私密信息流，储存至非私密信息流内容数据库；并在其数据中记录使用者的角色索引，使得服务器能够根据角色的索引，查询获取其所有发表过的非私密信息内容；

S4，服务器根据上一个步骤中创建的非私密信息流，创建一个对应的非私密信息流索引，储存至非私密信息流索引数据库；并在其数据中记录使用者的角色索引，使得服务器能够根据角色的索引，查询获取其所有创建的非私密信息流。

进一步的，该方法还包括：非私密信息流的消息发送；

a)使用者可以使用一个账号下的一个角色(作为发送者)，向服务器直接发表一条非私密信息流的内容(作为回复内容)，并指定一个目标非私密信息流的索引，或其中某一条信息的内容(作为回复目标)

b)服务器在收到使用者提交的内容后，会对发送者角色与其所属账号进行角色-账号联合封禁判断

c)服务器判断发送者指定的回复目标的类型

i.若目标的类型是信息流的索引，则服务器判定发送者回复的目标，是整个信息流中的第一条的内容；

ii.若目标的类型是信息流的内容，则服务器判定发送者回复的目标，就是该信息流的内容；

d)服务器取出上一步骤中判定的、内容数据中的角色索引(作为目标角色)

如，有一个非私密信息流，其中有三条消息内容，分别是角色A、B、C先后发表的，此时D也想要在该信息流中发表内容

因为该信息流是A第一个发表内容而被服务器创建的，所以若D指定的目标是信息流索引，或者指定的是信息流中第一个内容，则目标角色都是A；

若指定的目标是信息流中的第二个内容，则目标角色是B，以此类推。

e)服务器将使用者提交的内容，添加至该信息流内容队列的尾部，写入非私密信息流内容数据库中

f)服务器根据步骤d)中获取的目标角色，使用其记录的账号索引，从账号数据库中取出账号详细数据，进行判断

i.判断该目标角色是否为发送者角色，若是则中止后续所有步骤；否则继续进行下一判断步骤

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

iii.判断该角色是否屏蔽了该目标信息流的消息，若已经屏蔽，则中止后续所有步骤；否则继续进行下一判断步骤

g)服务器生成一条通知数据，通知的渠道为该非私密信息流，接收者为步骤c)中取出的角色的索引，发送者，以及通知的内容为实际消息数据；

h)服务器通过网络推送将该通知发送给经过步骤f)判断后取出的账号，完成发送。

进一步的，该方法还包括：非私密信息流的角色添加、删除。

不同于私密信息流，向非私密信息流添加角色不需要获得信息流创建者的授权。使用者在使用非私密信息流的消息发送方法发表内容的时候，只要角色通过了该非私密信息流的黑白名单判断，即可在信息流中发表内容，不需要添加和删除。

在进行角色切换时，使用者可以选择其账号下任意一个角色，重复进行非私密信息流的消息发送方法的操作，无需切换账号即可实现切换角色的效果。

进一步的，该方法还包括：非私密信息流中的消息接收

当使用者已经登录某一个账号后，若通过网络推送，接受到了来自本发明的服务器推送过来的通知后，会进行解析

a)通过诸如响铃、震动等方式告知使用者收到新消息；

b)从通知数据中取出渠道、回复者、接收者和内容数据；

c)在设备屏幕上生成一个文本框，告知用户，自身收到了来自非私密信息流vvv中的回复消息xxx，回复者是yyy，并且自己的账号在这个私密信息流中扮演的角色是zzz。

假设有两个账号A和B，账号A下有A1、A2、A3三个角色，账号B下有B1、B2两个角色；有一个非私密信息流Z，账号A已经使用角色A1，在Z中发表了一条内容。

当账号A的角色A2回复了同账号下角色A1发表的内容后，账号A不会收到提醒；但若另一个账号B，无论使用角色B1还是B2，在信息流Z中回复了角色A1或A2发表的内容，账号A会收到来自账号B的消息提醒。

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

而本发明是通知某个账号下属的某个或某几个角色收到了消息，消息的接收者不是账号本身，而是账号下属的角色，账号的作用仅仅是中转和提醒“zzz角色收到了消息。

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

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

若判断结果为角色、账号以及非私密信息流均非“被封禁”，则将请求查看的非私密信息流中的所有消息内容依次返回给所述发送内容查看请求的角色。

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

如，使用本发明，张三就可以申请一个本发明体系的账号，然后在账号下创建两个角色，一个叫“张三”，另一个叫“李四”，那么在本发明体系中的非私密信息流(类似于QQ空间)，不论是想扮演“张三”还是“李四”，只需要极少量的触控点击操作，即可快捷更换角色，无需再切换账号；而且，因为无需切换账号，不存在下线的问题，无论是正在扮演“张三”还是“李四”，其他人发给“李四”或者“张三”的消息都能及时收到。

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

Claims (3)

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

S1，服务器接收某一账号下的某一角色所发送的非私密信息流内容；

S2，根据所述非私密信息流内容创建非私密信息流，并将所述非私密信息流内容存储至相应的数据库；在该数据库中记录发送非私密信息流内容的角色的索引，并将其与存储的非私密信息流内容进行关联；

S3，根据服务器所创建的非私密信息流创建非私密信息流索引，并将所述非私密信息流索引存储至相应的数据库；在该数据库中记录发送非私密信息流内容的角色的索引，并将其与存储的非私密信息流索引进行关联；

所述步骤S1包括：

S301，服务器接收内容发送者发表的一条非私密信息流的内容即回复内容，所述回复内容中包含内容发送者指定的回复目标；所述内容发送者为某一账号下的某一角色；所述回复目标包括非私密信息流的索引或非私密信息流中已存在的某条消息的内容；

S302，服务器在接收内容发送者发表的回复内容后，对所述内容发送者进行角色-账号联合封禁判断；

S303，服务器判断内容发送者指定的回复目标的类型；根据判断结果提取非私密信息流索引或者非私密信息流内容所关联的角色索引；

S304，服务器根据回复目标，将内容发送者发表的回复内容添加至目标非私密信息流内容队列的尾部，并写入相应的数据库中；

步骤305，服务器根据提取的非私密信息流索引或者非私密信息流内容所关联的角色索引从账号数据库中提取角色所属的账号详细信息；

步骤306，服务器生成通知数据，并通过网络推送将所述通知数据发送给步骤305所提取的账号；所述通知数据包括步骤S303所提取的角色索引、内容发送者以及回复内容；

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

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

2.根据权利要求1所述的方法，其特征在于，在步骤305之后还包括，对角色、账号进行判断；具体包括：

步骤3051，判断所述角色索引中所包含的角色是否为内容发送者，若是则终止后续步骤，否则对所述角色索引中所包含的角色及其所述账号进行角色-账号联合封禁判断；若所述联合封禁判断结果非“被封禁”则跳转至步骤3052，否则终止后续步骤；

步骤3052，判断非“被封禁”状态的角色是否屏蔽目标非私密信息流的消息，若已屏蔽则终止后续步骤，否则跳转至步骤306。

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

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

若判断结果为角色、账号以及非私密信息流均非“被封禁”，则将请求查看的非私密信息流中的所有消息内容依次返回给所述发送内容查看请求的角色。