CN102902455A - 一种社交***的加关注方法 - Google Patents
一种社交***的加关注方法 Download PDFInfo
- Publication number
- CN102902455A CN102902455A CN2012103588529A CN201210358852A CN102902455A CN 102902455 A CN102902455 A CN 102902455A CN 2012103588529 A CN2012103588529 A CN 2012103588529A CN 201210358852 A CN201210358852 A CN 201210358852A CN 102902455 A CN102902455 A CN 102902455A
- Authority
- CN
- China
- Prior art keywords
- user
- concern
- add
- territory
- close attention
- 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.)
- Pending
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本发明公布了一种社交***的加关注方法,由主动定额加关注、被动定额加关注、导出其它用户关注、加关注托管四个分支方法构成,用来解决用户信息场封闭、社交链难打开、大批添加关注时对于选择所加用户属性的确定性问题。帮助用户快速构建信息场,注册即有丰富互动内容、迅速提升人气和参予兴趣,使***活性强烈,有坚强的用户黏性,利于社交***用户基数规模的稳步扩大,它能作为补充模块***市面的社交***原有加关注体系内,适用于包括微博、博客、论坛、图片社交、浏览器社交等在内的全方位领域的凡存在加关注行为的社交***。另外,通过用户加关注托管的链式聚合,能迅速构成庞大圈群效应,对科技、经济、教育和商业等诸多领域都有积极意义。
Description
技术领域
本发明属于互联网领域,涉及社交***领域,特别涉及加关注。
背景技术
现在许多社交***都存在加关注和被关注现象。比如微博,用户在微博里把其它用户加为关注,然后可以看到加关注用户所发的贴子,而自已叫做对方的粉丝;用户也可以被关注,被其它用户关注后,其它用户可以看到自已的贴子,这时其它用户被称为自已的粉丝。再有,比如博客,比如图片交友***,都存在加关注行为,存在加关注行为的社交***不仅种类众多,而且遍布各种领域范围。加关注是种单向行为,典型代表是微博里的加关注行为,它无需对方同意(被对方拉黑例外)。它有别于加好友,因为加好友是双向行为。需要用户双方的同意,典型代表是QQ里加好友。在有加关注行为的社交***内,服务器都会在用户的个人帐号域下构建一个独立的域,这个域用于用户将所添加的需要关注的其它用户代码进行写入和删除,一般情况下,这个域叫做【关注】域,但也有叫其它名字的,性质是一样的。不管叫什么名称,所述的加关注,是指一种公知行为,即用户将社交***内感兴趣的其它用户代码单向添加到自已的帐号域下的一个特定子域,以便服务器让用户对这些被添加的用户进行持续的关注行为。加关注行为在互联网社交领域是一种普遍行为。但是目前市面的加关注功能都需要用户一个一个把对象添加到自已的关注,特别麻烦,制约了社交活力。特别是在未来社交领域集群加关注将成为越来越重要的行为趋势,因为需要这种方式来迅速改变新老用户的信息场以增加用户的热度和黏性。目前也存在一次加多位用户为自已关注的现象,例如某网页浏览页面出现一排比如说六个名人微博图标,用户点击后全选可以一次加到自已关注里,但这种加关注并无实际意义,它不具备大批量加关注的实质意义,因为无法满足用户兴趣针对性的需要。制约用户大批添加关注的最关键因素是,用户在大批加关注时需要选择所加关注用户的定向属性,也就是说当用户大批加关注时需要的是这些被加关注要符合自已的兴趣指向,而这种定向属性的选择对用户来说是难确定的,当面临众多用户时,用户无法确定哪些用户能够满足自已的兴趣指向从而批量加到自已的关注中。特别是,在社交***中,新用户的信息场封闭,社交链没展开,无互动信息内容,用户体验较差,这种状况直接制约了市面上众多社交***的活性和用户黏性,甚至许多互联网公司倾力推出的社交***产品所以失败,常常跟用户初期在社交***里的信息场过于封闭,社交链无法充分展开以至用户与用户间难以进行互动有着较大联系,这种情况直接损害了用户体验和持续参予的积极性,使之难以形成适当规模的用户基数。大批集群性的加关注方法,能够迅速帮助用户扩拓社交链,获得丰富的信息场,提升用户参予热度,同时稳定而快速地帮助社交平台扩大用户基数。
综上所述,目前市面上已有的传统加关注方式效果并不完美,还需要更多加关注方式的补充。
本发明所依托的技术支持:有加关注行为的社交***以及该社交***原有的加关注模块技术,毕竟没有这些社交***的存在,加关注行为根本没有依附存在的基础;
发明内容
本发明的目的是,为了帮助用户解决在社交***里所处的信息场封闭、社交链不能充分打开、以及用户大批添加关注时对于选择所加用户属性的确定性问题,为用户和社交***提供更多的加关注手段,以让用户快速构建自已的信息场,它可以作为一种补充技术,能融合于市面上的社交***里原有的加关注方法体系内,与社交平台本身原有的那些加关注方法相补充,为用户加关注提供更便利的方式和获得更丰富的用户体验。本发明所述的社交***,是一种广义范畴,是指一切拥有加关注行为的社交***;所述加关注行为,是指用户的单向行为,即用户把社交***内的其它用户添加为自已的关注用户。
一种社交***的加关注方法,是由四个加关注的分支方法构成的一个方法体系:即主动定额加关注、被动定额加关注、导出其它用户关注、加关注托管所构成;另外,在阐述这个方法体系的过程中还涉及到加关注输入框的构成内容,加关注输入框负责操作用户加关注的输入界面。这四个加关注的分支方法既能互相配合形成信息场叠加组合效果,也能独立使用;社交***可根据自已的需要,在社交***内全部或部分使用这四个加关注分支方法模块。
这四个加关注分支方法模块构成的方法体系实施有两项前期处置:(1)当原有社交***没有在用户个人帐号域下建立标签子域体系用来在社交***中让用户写入、删改个人标签和其它标签的,必须建立这些标签子域体系;例如,可以用【标签】、【个人标签】、或者【其它标签】等子域来命名这些子域;所述的个人标签是指,用户在自已的【个人标签】子域里输入的用来定义自已兴趣或话题等个性的特征标签,【个人标签】子域是一种公知域。【个人标签】既可以是用户帐号域下的独立子域,也可以把【个人标签】域放在【标签】子域里作为【标签】子域的孙域。个人标签由用户自已填写,有时也由服务器根据用户的行为特征来主动配属,例如将用户的IP地址、年龄、性别等属性自动标配补充为该用户的个人标签;所述的其它标签子域是指除个人标签以外服务器认为有提取标签取样价值而设立的其它标签域;(2)可选的,社交***提示和引导用户添加个人标签和其它标签,并将用户输入的标签写入到特定子域里,告诉用户添加标签的重要意义,只有在阐述清楚后,让用户意识到添加标签对它们自已的社交行为具有实质性的好处,并亲身感觉到这种好处它们才会有参予的冲动。
1.所述主动定额加关注,俗称为一次性满血加关注,这种加关注方法的内容特征是,服务器会依据用户输入的标签指令请求,按用户提出的数量标配额度,一次性加满用户要求的关注额度和同步检索适配好所加关注用户的标签属性,违背了传统社交***加关注(让用户逐步一个一个地添加关注做加法)的历史做法,采取的是做减法方式,即在一个相对精确的范围内让用户从大批关注用户里逐步清除不感兴趣的用户;该方法进一步包括以下内容或步骤:
(1)用户在加关注输入框里输入标签,或者勾选社交平台“推荐的标签”或“标签组合”,或者勾选社交平台推荐的“其它特定域标签的取样标签”选项来确定即将定额加关注的用户属性,输入的标签为一或多个标签,并同步输入用户自已想要待加关注的总数量,当标签和数字都填好后点击【确定】向服务器发送,服务器即依据用户输入的标签和要求的加关注数量为该用户匹配加满含有相同标签属性的关注用户,此时用户在自已的【关注】栏里,能够看到这些已加满的被关注用户;
(2)当用户点击【确定】按钮后,过程中***可把实际搜索匹配到的结果向用户显示(如图3里的“结果显示”框),例如用户输入“专利”标签,同时将要求加关注数目设置为定额1000,但实际上服务器只搜索到200个拥有“专利”标签的用户代码。服务器可将这个结果向用户显示。既可只做到这一步,还可持续下一步,也就是询问用户是否允许服务器将未来新出现的具有相同标签的其它用户陆续添加到用户【关注】域内直到加满此前的定额,如果用户选择是,则服务器会达到这个过程;
(3)在用户【关注】子域下,社交***可以自已命名构建一个特定的孙域,来专门负责主动定额加关注导致的用户代码结果的写入和删除;本发明将其拟名为【主动定额加关注】孙域来示例(如图2【关注】孙域里的【主动定额加关注】);所以这样做,是为了与用户的其它加关注行为的结果分开;
(4)用户可以反复地进行定额加关注行为;
(5)对于是否控制用户加关注的总量,或者是否限制用户每次加关注的总量,或者是否对集群加关注的用户行为收费,或者当社交平台认为用户关注量过于庞大时可以按照一定权数削减部分信息单元的信息推送量,这些由社交平台自行决定;
(6)社交平台可以抽取某个特定域的标签取样结果后建立勾选项来让用户勾选,将其作为用户在加关注输入框里输入的加关注标签结果,来实施自已的加关注行为。社交***将抽取出来的特定域的标签取样结果,建立枚列勾选项展开菜单让用户进行选择性勾选。所述的特定域,是指社交***自主决定择取的某个自拟定域,这个域的确定由社交平台自主决定。比如说,服务器设置“发明”标签及其近缘标签词团作为特定的标签域,通过计算后得出取样结果,以让用户勾选;再比如,服务器可以将某30个用户的【个人标签】域全部汇总后作为一个特定的自拟定域。当然,这只是两个示例,事实上特定域的范畴是可以***的,社交平台想怎么择取自拟定域,那是它们自已的事情。所述的标签取样,其标签取样的域位置和范围由社交平台自行决定,其取样方法根据统计学理论或者社交平台自拟定的取样方法来操作(这些取样方法属于统计学领域的公知技术和社交平台的行为,跟本发明无关,本发明要的只是这个勾选项创新点,以让社交平台楔入自已的特定域标签取样勾选项,让用户通过特定域的标签取样来实施加关注行为);
(7)社交***可以把加关注的输入框在用户个人页面的多个不同位置设置,具体在什么位置设置加关注输入框,以及设置多少处加关注输入框,由社交平台自行决定,例如:
a.用户既可以点击打开自已的【关注】按钮后出现加关注输入框;
b.用户也可以在浏览到某个其它用户时,在该其它用户的个人标签栏上点击,发现该其它用户的个人标签群里有自已感兴趣的某个标签,光标移动到该标签上,服务器设置在这里浮显出【主动定额加关注】按钮,让用户来实施跟这个标签相关的加关注行为;
c.也可以采取在用户首页构建一个加关注输入框。
主动定额加关注的具体实施方式示例:
(1)没有构建标签子域体系的社交***,必须为每位用户构建标签子域体系,其中特别包括【个人标签】子域,用于用户在这些标签子域体系里面添写和删改标签;
(2)用户点击自已的【关注】图标按钮,在【关注】按钮的子菜单里选择点击【主动定额加关注】,此时会显出定额加关注的输入框的细选项(如图2里【主动定额加关注】单元展开后的内容),该输入框包括四个单元,一个单元是数字单元,用以让用户输入确定待加关注的总量,社交***可以推荐一排数字,用户点选其中的一个数字或自已输入数字来确定一次性加关注的数量;一个单元是标签单元,用以让用户输入标签或者勾选社交平台推荐的标签或者勾选社交平台推荐的“其它特定域标签的取样标签”选项;一个单元是确定单元,用以让用户点击【确定】按钮,来向服务器发送,最后一个单元是复原单元(按钮),如果用户事后对这次的一次性满血加关注效果不满意,可以重新点击【主动定额加关注】按钮打开子菜单,然后点击【复原】按钮,回复以前的状态;另外,在【关注】孙域里的【主动定额加关注】域里的加关注结果,也允许用户用点击【复原】或【删除】按钮方式来复原前一步的结果或直接删除(如图2【关注】孙域里的展开项);
(3)当服务器收到用户发送的主动定额加关注指令后,服务器将依据用户在主动定额加关注输入框里输入的标签来分别检索或联合检索用户数据库,匹配到那些具有一个或多个相同标签的其它用户,依据用户输入的加关注要求数量,将相同数量的已匹配检索出的那些其它用户,添加到用户的关注群里;换种描述,就是把检索出来的那些其它用户的用户代码写入到该用户的【关注】孙域里,或者更细化地说是写入【关注】孙域下的【主动定额加关注】孙域里。所述分别检索,是指将用户输入的标签一个一个依次地检索,在用户数据库里检索时发现用户代码自身所附带的标签词团里只要有一个相同标签即属于拥有共同标签,通常用户具有多个的个人标签和其它标签。服务器会根据用户输入的多个标签的数量取平均数或以不同权数分配后再匹配给每个标签的关注总量,比如用五个标签来加1000关注,如按平均数则每个标签匹配200个关注;如按不同权数分配,则由***平台提醒用户用勾选每个标签所占权重按钮的方式来自行分配或***平台自行拟定分配权数,比如第一个标签配500,后面均分;所述的联合检索,是指服务器在检索用户数据库里的用户代码自身所附带的标签时,必须是与用户输入的全部标签相匹配的用户代码,才能视为拥有共同标签;
(4)社交平台抽取某个特定域的标签取样结果将其作为用户在加关注输入框里输入的加关注标签结果来实施自已的加关注行为的方式是,社交***将抽取出来的特定域的标签取样结果,建立枚列勾选项展开菜单让用户进行选择性勾选;它有两种方式,一种是在用户输入标签时出现的***平台向用户推荐的推荐标签里出现这种推荐勾选项,一种是在被动定额加关注时的勾选项里让用户勾选(参见图3加关注输入框里的标签推荐或者【其它加关注】框里的【根据特定域的标签取样来实施定额加关注】)。
2.所述的被动定额加关注,俗称为“一次满血被动加关注”,这种加关注方法的内容特征为:服务器主动根据用户【标签】域里面的个人标签或者其它特定域的取样标签,匹配具有相同标签属性的其它用户代码,为用户加满定额的关注用户,它无需用户输入标签。对用户来说,有被动接受推荐结果的含义。所述定额,是社交平台服务器自已设置的加关注总额数字,由社交***的技术人员自行拟定,例如社交***自行构建加关注策略,在得到用户授权或不经过用户授权情况下,为刚注册用户标配一定额度比如100、500、2000的关注数量。是否采用被动定额加关注、以及被动定额加关注的总数量,由社交平台自行决定。
被动定额加关注具体实施方式示例:
(1)用户注册后,填好个人标签,服务器读取该用户的个人标签,然后依次根据该用户全部个人标签里的每个标签,在社交平台的用户数据库里,检索匹配到具有相同标签的用户代码,将这些用户代码按照平台自设置的额定数量,写入用户的【关注】域里;
(2)服务器也可读取特定域的取样标签,作为用户输入标签的替代结果,在用户数据库里匹配具有相同标签属性的其它用户代码,为用户加满定额的关注用户;这种用特定域抽取的取样标签结果来检索匹配加满定额关注的方式,既可采用获得用户授权的协议方式(跟主动定额加关注里的抽取某个特定域的标签取样结果实施加关注是同一个东西),也可采用***主动的不经用户同意的方式;
(3)服务器在用户个人帐号的【关注】域里,把这种被动定额加关注所加的关注结果,用一个单独的单元来写入和删改(如图2里的【关注】孙域中的【被动定额加关注】单元);
(4)被动定额加关注方式比较适用于用户刚注册时的初期阶段,或者用户主动通过勾选方式提出了这种需要;
(5)社交平台***可征得用户同意,也可不经用户同意采取被动定额加关注方式;
(6)这种被动定额加关注行为结果可以复原,也就是当用户点击【被动定额加关注】里的【复原】按钮后,这种被动定额加关注的结果是可复原(包括删除)前一步的结果的;当用户发现误按了【复原】按钮,也可以再次复原前一步的状态或者重新勾选【由***主动定额加关注】按钮,让***重新再次匹配结果。
3.所述导出其它用户的关注,用于用户在经过对方授权同意的情况下,将某个其它用户的关注全部或部分导出到自已的关注里。当服务器收到用户发出导出某个其它用户关注的请求并得到对方同意确认的指令时,服务器会读取这个其它用户帐号域下的【关注】域里被用户全选或勾选的用户代码或者含用户代码集合的文件夹,把这些用户代码或已勾选文件夹里的用户代码写入用户自已的【关注】域里。
导出其它用户的关注具体实施方式(示例):
(1)用户可以对自身的【关注】域进行允许导出设置。用户打开自已的【关注】栏,在【关注】栏里选择点击【允许导出设置】按钮打开子菜单,在【开放】、【限制】、【付费】、【禁止】四个分选项里进行唯一勾选(如图2里的【允许导出设置】);
(2)用户如果没有对自身关注导出功能进行设置,***可以自主设置用户的允许导出关注的默认状态,比如开放或限制;
(3)用户可以把自已的【关注】群里的子文件夹,设置为【可以导出】和【隐私】两种分类,被设置为隐私的文件夹或者关注用户被拖入到隐私文件夹里以后,不会在其它用户浏览时被显示出来(如图2里的【关注】孙域中的多个分类关注子单元下面的展开项);
(4)用户点击对象用户界面上的【关注】栏(按钮),打开即可浏览该用户的关注群,在点击打开浏览对方关注群的页面里还有涉及『导出为自已关注』性质的子级按钮(具体显示在用户页面里的是名称不确定的按钮,它的名称要根据后面将描述的几种实际的不同情况来分别确定),用户全选或勾选对方的关注或关注群里的子文件夹后,点击『导出为自已关注』性质的子级按钮即可以将对方的关注或关注子文件夹里的关注,全部或部分在授权能够通过的情况下导出到自已的【关注】域里;
(5)用户点击对象用户页面里的涉及『导出为自已关注』性质的按钮时可分四种情况,这四种情况是唯一的排它型状况,即有其一则无其它:
a.在其它用户将允许导出设置为【开放】的状态下,用户可以直接点击【导出到自已关注】按钮,将该用户的关注导出到它自已的关注里;
b.在其它用户将允许导出设置为【限制】的状态下,用户可以点击【请求导出到自已关注】按钮,发送请求信息经对方同意才能导出其它用户的关注;
c.在其它用户将允许导出设置为【付费】的状态下,用户需要点击【付费】按钮,查看付费额,无异议支付费用后才能导出;所述付费导出,是指在有些社交***设置了这种有偿导出的模式下才会出现这个功能;
d.在其它用户将允许导出设置为【禁止】状态下,则不能导出;
e.当用户成功发出导出指令后,服务器将用户在其它用户【关注】域里已全选或已勾选的用户代码写到用户自已帐号域下的【关注】域里;
(6)【导出其它用户关注】域里的加关注结果,允许用户用点击【复原】或【删除】按钮的方式来复原前一步的状态或删除该加关注结果(如图2【关注】孙域里的展开项)。
4.所述加关注托管,用于在授权模式下用户采用加关注托管,即一位用户发现某位用户与自已兴趣相同,可以发出加关注托管请求,经对方通过,把自已的加关注行为托管到对方用户,对方怎样加关注,自已也会自动加同样的关注。服务器将已达成托管协议的受方用户新添加的关注在写入受方【关注】子域的同时,同步写入委方用户的【关注】子域里。当然这种托管不影响用户自已的添加关注行为;这种加关注方式的意义是,所委托的其它用户在加关注时具有兴趣指定性,即当用户采用托管到另一位用户的方式来加关注,意味着该用户判断对方的行为符合自已的兴趣指向性。
加关注托管的具体实施方式示例:
(1)服务器在每位用户帐号域下的【关注】子域里再构建一个【加关注托管】孙域,该孙域的构成包括两个必要信息单元,即委方和受方,委方是请求方(即托管发起请求方),受方是接受方;
(2)服务器在每一位用户的【关注】子域下构建一个【委方用户显示】孙域和【受方用户显示】孙域(如图2里的【加关注托管】域下的内容);
(3)服务器在每位用户帐号里的个人页面里构建【委方用户显示】图标和【受方用户显示】图标,【委方用户显示】用于在个人页面里显示该用户所有的委方用户,【受方用户显示】用于在个人页面里显示该用户所有的受方用户;
(4)当用户之间达成授权协议形成加关注托管状态时,服务器将进行以下步骤:
a.服务器在委方用户的【加关注托管】孙域的【受方】单元里和【受方用户显示】单元里写入所委托对象的用户代码;服务器同步在委方用户所委托的受方用户的【关注】子域下的【加关注托管】孙域的【委方】单元和【委方用户显示】单元里,写入该用户(即托管行为提出方)的用户代码;
b.服务器将用户的所有受托方的用户代码通过【受方用户显示】在用户自已的个人页面里显示;多位受托者会以子群方式存在。也就是说让浏览者看到它委托了几个用户;
c.服务器将用户的所有委方的用户代码通过【委方用户显示】在用户自已的个人页面里显示;多位委方用户会以一个子群方式存在;也就是说让浏览者看到有几个用户委托了它;
d.可选的,在委托加关注框里,用户还可以选择或取消【加关注托管掰断】功能选项,也就是这种加关注托管,用户只接收受方用户自已的手动加关注行为,也就是它不接收受方用户自已也在进行的加关注托管行为。更确切的说,就是当用户采用这种加关注托管的掰断功能后,用户在将受方的新加关注写入到自已的【关注】里时,当受方用户自已也存在加关注托管状况时,服务器会把受方用户也在进行的这种加关注托管行为的后果予以忽略;
e. 服务器在每一位用户帐号域下的【关注】子域里再次构建【关注】孙域,该孙域与子域同名,但它是孙域,它的用途是写入用户的关注,所以这样设置,是为了让【关注】子域下容纳更多的功能孙域,比如容纳【主动定额加关注】、【加关注托管】、【导出其它用户关注】等孙域,以及【关注】孙域下的分类关注单元群(参见图2)。在【关注】子域下的【关注】孙域里建立两个子域,一个子域叫【自添加关注】子域,服务器将用户自已手工添加关注的用户代码写入该子域;一个子域叫【委托添加关注】子域,服务器将用户加关注托管行为由受托方带来的关注用户代码写入该子域(如图2里【关注】孙域下展开的分类关注单元里的内容)。之所以这样划分,是为了便于实施加关注托管掰断功能或者便于用户清除加关注托管产生的结果;
f.如果委方用户选择了“加关注托管掰断功能”,那么服务器将只读取受方用户【关注】子域里的同名【关注】孙域下的【自添加关注】域里的用户代码,将其写入委方用户的【关注】子域里的同名【关注】孙域下【委托添加关注】域;
g.如果委方用户没有选择【加关注托管掰断】功能,那么服务器不仅要将受方用户帐号域下【自添加关注】域里的新增的用户代码添加到委方用户的【关注】域里的【委托添加关注】子域里;还要把受方用户帐号域下【委托添加关注】域里的新增加的用户代码也要添加到委方用户的【委托添加关注】域里;
(5)允许用户对自身帐号的加关注托管功能进行设置。用户选择点击【加关注托管】按钮打开其子菜单,在子菜单里选择【允许托管设置】再点击打开下一级子菜单,在【开放】、【限制】、【付费】、【禁止】四个分选项里进行唯一勾选(如图2里的【加关注托管】下的【允许托管设置】所展开的内容);
(6)服务器收到用户点击对象用户页面里的【加关注托管】按钮的指令时,将立刻检索读取该对象用户【加关注托管】下的【允许托管设置】四个子单元,即【开放】、【限制】、【付费】、【禁止】四个单元的状况,来判断对象用户对【加关注托管】的允许设置属性,向该用户展示,分以下几种情况:
a.在对象用户设置为【开放】状态下,用户可以直接点击【加关注托管】按钮,实行托管;
b.在对象用户设置为【限制】状态下,用户可以点击【请求加关注托管】按钮,发送请求经对方同意才能托管;
c.在对象用户设置为【付费】状态下,用户需要点击【加关注付费托管】按钮,支付费用后才能托管;通常这种情况是在该社交***允许和支持付费模式的情况下才会出现;
d.在对象用户设置为【禁止】状态下,则不能实行加关注托管;
e.以上四个按钮都具有排它性,即出现一则不现其余;
f.用户解除加关注托管行为,找到想要解除托管协议的另一方用户名或图标,点击该用户名或图标所带的【解除托管】按钮。如果服务器收到用户发出解除托管的信息,则服务器会:
①在用户帐号域下的【加关注托管】孙域里的受方单元里标记无效或直接删除对方用户的代码,同时在对方用户帐号域下的【加关注托管】域里的委方单元里标记无效或直接删除该用户的代码信息;
②相关用户的【委方用户显示】、【受方用户显示】里的用户代码不变,但服务器会在已解除托管关系的用户名上标注一个已解除托管标志。服务器保留这种托管痕迹和历史托管痕迹,是便于让其它浏览者留意;
③用户可以保留删除和隐藏历史托管痕迹的权利,方法是,在自已的【关注】栏里,选择【受方用户显示】或者【委方用户显示】,在上面选择点击【删除】或【隐藏】按钮;也可以只在某个已解除托管关系的用户名上点击【删除】或【隐藏】按钮;
(7)当每一位用户自已手工添加新加关注时,服务器会把新加关注用户代码写入用户自已的【关注】子域里的同名【关注】孙域里的【自添加关注】域内,并同时检索用户的【加关注托管】域的委方单元,如里面的用户代码为空(或者用户代码标记无效),则无需处理;如委方单元存在一或多个用户代码,意味着这些用户代码都是委托方;此时服务器的处理分为两种情况:
a.在用户勾选了【加关注托管掰断功能】状况下,服务器则把用户【自添加关注】域里的新增用户代码同时写入这些委方用户帐号域的【关注】子域下面与其同名的【关注】孙域里的【委托添加关注】子域;
b.在用户没有勾选【加关注托管掰断功能】状况下,如果用户自已也采用了加关注托管功能,那么服务器不仅要将用户自已帐号域下【自添加关注】域里的新增的用户代码添加到委方用户的【关注】域里的【委托添加关注】子域里;还要把用户自已帐号域下【委托添加关注】域的新增加的用户代码也要添加到委方用户的【委托添加关注】域里;
(8)【委托添加关注】域里的加关注结果,允许用户用点击【复原】或【删除】按钮方式来复原前一步的状态或直接删除该加关注结果(如图2【关注】孙域里的展开项);
(9)当社交平台认为由于加关注托管行为的链式反应,即托管中有托管,而且是成链式的,形成信息流量暴增过度时,可以采取限制的方式来削减总信息流。例如,限制每位用户的加关注数量总额或者消减每位被关注用户的信息流量总量(即只推送它的部分信息)。
综上所述:几种加关注方式,能产生强大组合效应,有助于帮用户快速地构建自已的信息场。本发明从架构层面阐述了一种社交***加关注的方法体系,可用于对现有社交***的传统加关注方法的补充,对技术人员来说,能根据这种构架原理简单地加以实施(编程),具体的实施细节是可以依据主体精神原则下的个性化需要来进行调整的。本发明具体实施例和附图都只是用来说明本发明,而不是用来限制本发明。社交领域的技术人员应该清楚的是,在不脱离本发明的精神或本质特征的情况下,本发明可以以其它形式、结构、界面布置、以及用其它组件来实现,不是换个名称、调个位置、局部简化(比如四个加关注分支方法体系只用三个而故意省掉一个)就可以判定为差异的,凡在本发明的精神和原则之内所作的修改、等同替换和改进(例如说不设【关注】子域下的【关注】孙域,而直接在【关注】子域下构建【自添加关注】子域和【委托添加关注】子域,这种变没有实质性的质变意义),均应包含在本发明的保护范围之内。
图1为社交***选择合成加关注补充方法模块的流程图
图2为加关注方法体系的子域结构大略示意图
图3为四种加关注分支方法的加关注集成式输入框示意图
这些图只是大略示意,是为了更好地阐述原理,实际应用过程中是可以在本发明的精神原则下调整变化的。
有益效果:
社交***因为用户刚注册时对同兴趣用户的关注极少,用户获得的感兴趣的内容极度缺乏,用户所处信息场非常封闭,社交链无法被迅速打开,初期用户与用户较难互动起来,需要一个相当长的缓慢积累参予过程,才能达到较好的互动状态。许多社交***刚向市面推出时等不到用户充分互动起来,就因为缺乏活性而失败了,因为用户都没有兴趣坚持下去,用户基数规模无法维持和扩大。但本发明里社交***因为能通过一次性满血主动加关注(主动定额加关注)、一次性满血被动加关注(被动定额加关注)、导出其它用户关注、加关注托管等一批加关注新功能,使得***具有极为强烈的活性,让用户一开始即获得丰富的信息场、迅速提升自身的人气和拥有极大的参予兴趣,极易产生坚强的用户黏性和互动欲望。刚注册时的用户,因为一下(短期)就可以拥有大量关注,开始即拥有丰富互动内容,围绕内容展开的交流极易铺开。有利于社交***用户基数的稳步扩大。特别对于刚向市面推出的社交***平台有极大的帮助。本发明能用于包括微博、博客、论坛、图片社交、浏览器社交等在内的全方位领域的凡存在加关注行为的社交***。
另外,集群加关注功能可以迅速帮助打开用户或者用户圈的社交链,而加关注托管等功能,能通过用户加关注行为间的层层拓扩发生链式放大效应,因为托管中有托管,即一位用户托管另一位用户,但另一位用户也有托管行为,通过用户群的层层交叉托管重叠效应,加关注速度和关注增长数量是极快增值的,能迅速构成庞大的圈群,伴随而来的圈群效应和圈群经济,对科技、经济、教育和商业等诸多领域都有重大意义。
Claims (10)
1.一种社交***的加关注方法,其特征为,包括以下内容,它由四个加关注的分支方法构成的一个方法体系,即主动定额加关注、被动定额加关注、导出其它用户关注、加关注托管所构成,这四个加关注的分支方法既能互相配合形成信息场叠加组合效果,也能独立使用,社交***可根据自已的需要,在社交***内全部或部分使用这四个加关注分支方法模块:
所述主动定额加关注,是指服务器会依据用户输入的标签指令请求,按用户提出的数量标配额度,一次性加满用户要求的关注额度和同步检索适配好所加关注用户的标签属性;
所述的被动定额加关注,是指服务器主动根据用户【标签】域里面的个人标签或者其它特定域的取样标签,匹配具有相同标签属性的其它用户代码,为用户加满定额的关注用户,它无需用户输入标签;对用户来说,有被动接受推荐结果的含义;所述定额,是社交平台服务器自已设置的加关注总额数字,由社交***的技术人员自行拟定;是否采用被动定额加关注、以及被动定额加关注的总数量由社交平台自已决定;
所述导出其它用户的关注,是指用户在经过对方授权同意的情况下,将某个其它用户的关注全部或部分导出到自已的关注里;当服务器收到用户发出导出某个其它用户关注的请求并得到对方同意确认的指令时,服务器会读取这个其它用户帐号域下的【关注】域里被用户全选或勾选的用户代码或者含用户代码集合的文件夹,把这些用户代码或已勾选文件夹里的用户代码写入用户自已的【关注】域里;
所述加关注托管,是指在授权模式下用户采用加关注托管,即一位用户发现某位用户与自已兴趣相同,可以发出加关注托管请求,经对方通过,把自已的加关注行为托管到对方用户,对方怎样加关注,自已也会自动加同样的关注;服务器将已达成托管协议的受方用户新添加的关注在写入受方【关注】子域的同时,同步写入委方用户的【关注】子域里;当然这种托管不影响用户自已的添加关注行为。
2.根据权利要求1所述的主动定额加关注,其特征为,包括以下内容:服务器会依据用户输入的标签指令请求,按用户提出的数量标配额度,一次性加满用户要求的关注额度和同步检索适配好所加关注用户的标签属性。
3.根据权利要求1或2所述的主动定额加关注,其特征为,还包括以下内容或步骤:
(1)用户在加关注输入框里输入标签,或者勾选社交平台“推荐的标签”或“标签组合”,或者勾选社交平台推荐的“其它特定域标签的取样标签”选项,来确定即将定额加关注的用户属性,输入的标签为一或多个标签,并同步输入用户自已想要待加关注的总数量,当标签和数字都填好后点击【确定】向服务器发送,服务器即依据用户输入的标签和要求的加关注数量为该用户匹配加满含有相同标签属性的关注用户,此时用户在自已的【关注】栏里,能够看到这些已加满的被关注用户;
(2)当用户点击【确定】按钮后,过程中***可把实际搜索匹配到的结果向用户显示,既可只做到这一步,还可持续下一步,也就是询问用户是否允许服务器将未来新出现的具有相同标签的其它用户陆续添加到用户【关注】域内直到加满此前的定额,如果用户选择是,则服务器会达到这个过程;
(3)在用户【关注】域下,社交***可以自已命名构建一个特定的孙域,来专门负责主动定额加关注导致的用户代码结果的写入和删除;
(4)对于是否控制用户加关注的总量,或者是否限制用户每次加关注的总量,或者是否对集群加关注的用户行为收费,或者当社交平台认为用户关注量过于庞大时可以按照一定权数削减部分信息单元的信息推送量,这些由社交平台自行决定。
4.根据权利要求1或2所述的主动定额加关注,其特征为,还包括以下内容或步骤:
(1)没有构建标签子域体系的社交***,必须为每位用户构建标签子域体系,其中特别包括【个人标签】子域,用于用户在这些标签子域体系里面添写和删改标签;
(2)用户点击自已的【关注】图标按钮,在【关注】按钮的子菜单里选择点击【主动定额加关注】,此时会显出定额加关注的输入框的细选项,该输入框包括四个单元,一个单元是数字单元,用以让用户输入确定待加关注的总量,社交***可以推荐一排数字,用户点选其中的一个数字或自已输入数字来确定一次性加关注的数量;一个单元是标签单元,用以让用户输入标签或者勾选社交平台推荐的标签或者勾选社交平台推荐的“其它特定域标签的取样标签”选项;一个单元是确定单元,用以让用户点击【确定】按钮,来向服务器发送,最后一个单元是复原单元(按钮),如果用户事后对这次的一次性满血加关注效果不满意,可以重新点击【主动定额加关注】按钮打开子菜单,然后点击【复原】按钮,回复以前的状态;另外,在【关注】孙域里的【主动定额加关注】域里的加关注结果,也允许用户用点击【复原】或【删除】按钮方式来复原前一步的结果或直接删除;
(3)当服务器收到用户发送的主动定额加关注指令后,服务器将依据用户在主动定额加关注输入框里输入的标签来分别检索或联合检索用户数据库,匹配到那些具有一个或多个相同标签的其它用户,依据用户输入的加关注要求数量,将相同数量的已匹配检索出的那些其它用户,添加到用户的关注群里;换种描述,就是把检索出来的那些其它用户的用户代码写入到该用户的【关注】孙域里,或者更细化地说是写入【关注】孙域下的【主动定额加关注】孙域里;所述分别检索,是指将用户输入的标签一个一个依次地检索,在用户数据库里检索时发现用户代码自身所附带的标签词团里只要有一个相同标签即属于拥有共同标签;如按平均数匹配,服务器会根据用户输入的多个标签的数量取平均数或以不同权数分配后再匹配给每个标签的关注总量;如按不同权数分配,则由***平台提醒用户用勾选每个标签所占权重按钮的方式来自行分配或***平台自行拟定分配权数;所述的联合检索,是指服务器在检索用户数据库里的用户代码自身所附带的标签时,必须是与用户输入的全部标签相匹配的用户代码,才能视为拥有共同标签;
(4)社交平台可以抽取某个特定域的标签取样结果建立勾选项来让用户勾选,将其作为用户在加关注输入框里输入的加关注标签结果,来实施自已的加关注行为;社交***将抽取出来的特定域的标签取样结果,建立枚列勾选项展开菜单让用户进行选择性勾选;所述的特定域,是指社交***自主决定择取的某个自拟定域,这个域的确定由社交平台自主决定;
(5)社交***可以把加关注的输入框在用户个人页面的多个不同位置设置,包括:
a.用户既可以点击打开自已的【关注】按钮后出现加关注输入框;
b.用户也可以在浏览到某个其它用户时,在该其它用户的个人标签栏上点击,发现该其它用户的个人标签群里有自已感兴趣的某个标签,光标移动到该标签上,服务器设置在这里浮显出【主动定额加关注】按钮,让用户来实施跟这个标签相关的加关注行为;
c.也可以采取在用户首页构建一个加关注输入框。
5.根据权利要求1所述的被动定额加关注,其特征为,包括以下内容:
所述的被动定额加关注,是指服务器主动根据用户【标签】域里面的个人标签或者其它特定域的取样标签,匹配具有相同标签属性的其它用户代码,为用户加满定额的关注用户,它无需用户输入标签;对用户来说,有被动接受推荐结果的含义;所述定额,是社交平台服务器自已设置的加关注总额数字,由社交***的技术人员自行拟定;是否采用被动定额加关注、以及被动定额加关注的总数量由社交平台自已决定。
6.根据权利要求1或5所述的被动定额加关注,其特征为,还包括以下内容或步骤:
(1)服务器读取该用户的个人标签,然后依次根据该用户全部个人标签里的每个标签,在社交平台的用户数据库里,检索匹配到具有相同标签的用户代码,将这些用户代码按照平台自设置的额定数量,写入用户的【关注】域里;
(2)服务器也可读取特定域的取样标签,作为用户输入标签的替代结果,在社交***的用户数据库里匹配具有相同标签属性的其它用户代码,为用户加满定额的关注用户;这种用特定域抽取的取样标签结果来检索匹配加满定额关注的方式,既可采用获得用户授权的协议方式,也可采用***主动的不经用户同意的方式;
(3)服务器在用户个人帐号的【关注】域里,把这种被动定额加关注所加的关注结果,用一个单独的单元来写入和删改;
(4)社交平台***可征得用户同意,也可不经用户同意采取被动定额加关注方式;
(5)这种被动定额加关注行为结果可以复原,也就是当用户点击【被动定额加关注】里的【复原】按钮后,这种被动定额加关注的结果是可复原(包括删除)前一步的结果的;当用户发现误按了【复原】按钮,也可以再次复原前一步的状态或者重新勾选【由***主动定额加关注】按钮,让***重新再次匹配结果。
7.根据权利要求1所述的导出其它用户的关注,其特征为,包括以下内容:用户在经过对方授权同意的情况下,将某个其它用户的关注全部或部分导出到自已的关注里;当服务器收到用户发出导出某个其它用户关注的请求并得到对方同意确认的指令时,服务器会读取这个其它用户帐号域下的【关注】域里被用户全选或勾选的用户代码或者含用户代码集合的文件夹,把这些用户代码或已勾选文件夹里的用户代码写入用户自已的【关注】域里。
8.根据权利要求1或7所述的导出其它用户的关注,其特征为,还包括以下内容或步骤:
(1)用户可以对自身的【关注】域进行允许导出设置;用户打开自已的【关注】栏,在【关注】栏里选择点击【允许导出设置】按钮打开子菜单,在【开放】、【限制】、【付费】、【禁止】四个分选项里进行唯一勾选;
(2)用户如果没有对自身关注导出功能进行设置,***可以自主设置用户的允许导出关注的默认状态,比如开放或限制;
(3)用户可以把自已的【关注】群里的子文件夹,设置为【可以导出】和【隐私】两种分类,被设置为隐私的文件夹或者关注用户被拖入到隐私文件夹里以后,不会在其它用户浏览时被显示出来;
(4)用户点击对象用户界面上的【关注】栏(按钮),打开即可浏览该用户的关注群,在点击打开浏览对方关注群的页面里还有涉及『导出为自已关注』性质的子级按钮,用户全选或勾选对方的关注或关注群里的子文件夹后,点击『导出为自已关注』性质的子级按钮即可以将对方的关注或关注子文件夹里的关注,全部或部分在授权能够通过的情况下导出到自已的【关注】域里;
(5)用户点击对象用户页面里的涉及『导出为自已关注』性质的按钮时可分四种情况,这四种情况是唯一的排它型状况,即有其一则无其它:
a.在其它用户将允许导出设置为【开放】的状态下,用户可以直接点击【导出到自已关注】按钮,将该用户的关注导出到它自已的关注里;
b.在其它用户将允许导出设置为【限制】的状态下,用户可以点击【请求导出到自已关注】按钮,发送请求信息经对方同意才能导出其它用户的关注;
c.在其它用户将允许导出设置为【付费】的状态下,用户需要点击【付费】按钮,查看付费额,无异议支付费用后才能导出;所述付费导出,是指在有些社交***设置了这种有偿导出的模式下才会出现这个功能;
d.在其它用户将允许导出设置为【禁止】状态下,则不能导出;
e.当用户成功发出导出指令后,服务器将用户在其它用户【关注】域里已全选或已勾选的用户代码写到用户自已帐号域下的【关注】域里;
(6)【导出其它用户关注】域里的加关注结果,允许用户用点击【复原】或【删除】按钮的方式来复原前一步的状态或删除该加关注结果。
9.根据权利要求1所述的加关注托管,其特征为,包括以下内容:在授权模式下用户发出加关注托管请求,经对方用户通过,把自已的加关注行为托管到对方用户,服务器将已达成托管协议的受方用户新添加的关注在写入受方【关注】域的同时,同步写入委方用户的【关注】域里;当然这种托管不影响用户自已的添加关注行为。
10.根据权利要求1或9所述的加关注托管,其特征为,进一步包括以下内容或步骤:
(1)服务器在每位用户帐号域下的【关注】子域里再构建一个【加关注托管】孙域,该孙域的构成包括两个必要信息单元,即委方和受方,委方是请求方(即托管发起请求方),受方是接受方;
(2)服务器在每一位用户的【关注】子域下构建一个【委方用户显示】孙域和【受方用户显示】孙域(如图2里的【加关注托管】域下的内容);
(3)服务器在每位用户帐号里的个人页面里构建【委方用户显示】图标和【受方用户显示】图标,【委方用户显示】用于在个人页面里显示该用户所有的委方用户,【受方用户显示】用于在个人页面里显示该用户所有的受方用户;
(4)当用户之间达成授权协议形成加关注托管状态时,服务器将进行以下步骤:
a.服务器在委方用户的【加关注托管】孙域的【受方】单元里和【受方用户显示】单元里写入所委托对象的用户代码;服务器同步在委方用户所委托的受方用户的【关注】子域下的【加关注托管】孙域的【委方】单元和【委方用户显示】单元里,写入该用户(即托管行为提出方)的用户代码;
b.服务器将用户的所有受托方的用户代码通过【受方用户显示】在用户自已的个人页面里显示;多位受托者会以子群方式存在;
c.服务器将用户的所有委方的用户代码通过【委方用户显示】在用户自已的个人页面里显示;多位委方用户会以一个子群方式存在;
d.可选的,在委托加关注框里,用户还可以选择或取消【加关注托管掰断】功能选项,也就是这种加关注托管,用户只接收受方用户自已的手动加关注行为,它不接收受方用户自已也在进行的加关注托管行为;更确切的说,就是当用户采用这种加关注托管的掰断功能后,用户在将受方的新加关注写入到自已的【关注】里时,当受方用户自已也存在加关注托管状况时,服务器会把受方用户也在进行的这种加关注托管行为的后果予以忽略;
e. 服务器在每一位用户帐号域下的构建【关注】孙域,它的用途是写入用户的关注;在【关注】孙域里建立两个子域,一个子域叫【自添加关注】子域,服务器将用户自已手工添加关注的用户代码写入该子域;一个子域叫【委托添加关注】子域,服务器将用户加关注托管行为由受托方带来的关注用户代码写入该子域;
f.如果委方用户选择了“加关注托管掰断功能”,那么服务器将只读取受方用户【关注】子域里的同名【关注】孙域下的【自添加关注】域里的用户代码,将其写入委方用户的【关注】子域里的同名【关注】孙域下【委托添加关注】域;
g.如果委方用户没有选择【加关注托管掰断】功能,那么服务器不仅要将受方用户帐号域下【自添加关注】域里的新增的用户代码添加到委方用户的【关注】域里的【委托添加关注】子域里;还要把受方用户帐号域下【委托添加关注】域里的新增加的用户代码也要添加到委方用户的【委托添加关注】域里;
(5)构建【允许托管设置】功能按钮;让用户选择点击打开下一级子菜单,在【开放】、【限制】、【付费】、【禁止】四个分选项里进行唯一勾选;
(6)服务器收到用户点击对象用户页面里的【加关注托管】按钮的指令时,将立刻检索读取该对象用户【加关注托管】下的【允许托管设置】四个子单元,即【开放】、【限制】、【付费】、【禁止】四个单元的状况,来判断对象用户对【加关注托管】的允许设置属性,向该用户展示,分以下几种情况:
a.在对象用户设置为【开放】状态下,允许用户直接点击【加关注托管】按钮,实行托管;
b.在对象用户设置为【限制】状态下,允许用户点击【请求加关注托管】按钮,发送请求经对方同意才能托管;
c.在对象用户设置为【付费】状态下,允许用户点击【加关注付费托管】按钮,支付费用后才能托管;通常这种情况是在该社交***允许和支持付费模式的情况下才会出现;
d.在对象用户设置为【禁止】状态下,则不能实行加关注托管;
e.以上四个按钮都具有排它性,即出现一则不现其余;
(7)用户解除加关注托管行为,找到想要解除托管协议的另一方用户名或图标,点击该用户名或图标所带的【解除托管】按钮;如果服务器收到用户发出解除托管的信息,则服务器会:
①在用户帐号域下的【加关注托管】孙域里的受方单元里标记无效或直接删除对方用户的代码,同时在对方用户帐号域下的【加关注托管】域里的委方单元里标记无效或直接删除该用户的代码信息;
②相关用户的【委方用户显示】、【受方用户显示】里的用户代码不变,但服务器会在已解除托管关系的用户名上标注一个已解除托管标志;服务器将这种托管痕迹和历史托管痕迹向用户个人页面显示;
③服务器构建【删除】和【隐藏】历史托管痕迹的按钮,让用户能删除和隐藏历史托管痕迹,用户操作流程是,在自已的【关注】栏里,选择【受方用户显示】或者【委方用户显示】,在上面选择点击【删除】或【隐藏】按钮;也可以只在某个已解除托管关系的用户名上点击【删除】或【隐藏】按钮;
(8)当每一位用户自已手工添加新加关注时,服务器会把新加关注用户代码写入用户自已的【关注】孙域里的【自添加关注】域内,并同时检索用户的【加关注托管】域的委方单元,如里面的用户代码为空(或者用户代码标记无效),则无需处理;如委方单元存在一或多个用户代码,意味着这些用户代码都是委托方;此时服务器的处理分为两种情况:
a.在用户勾选了【加关注托管掰断功能】状况下,服务器则把用户【自添加关注】域里的新增用户代码同时写入这些委方用户帐号域的【关注】孙域里的【委托添加关注】子域;
b.在用户没有勾选【加关注托管掰断功能】状况下,如果用户自已也采用了加关注托管功能,那么服务器不仅要将用户自已帐号域下【自添加关注】域里的新增的用户代码添加到委方用户的【关注】域里的【委托添加关注】子域里;还要把用户自已帐号域下【委托添加关注】域的新增加的用户代码也要添加到委方用户的【委托添加关注】域里;
(9)【委托添加关注】域里的加关注结果,允许用户用点击【复原】或【删除】按钮方式来复原前一步的状态或直接删除该加关注结果;
(10)当社交平台认为由于加关注托管行为的链式反应,即托管中有托管,而且是成链式的,形成信息流量暴增过度时,可以采取限制的方式来削减总信息流;包括,限制每位用户的加关注数量总额或者消减每位被关注用户的信息流量总量(即只推送它的部分信息)[审查员同志,我们以为这种撰写方式不存在权利重叠,如果您觉得权利要求重叠,既可以采取删除后面的重叠部分,还有另一种方法,即看能否删除权利1里面的重叠部分,具体情况您看法律后果状态怎么好就怎么选择]。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2012103588529A CN102902455A (zh) | 2012-09-25 | 2012-09-25 | 一种社交***的加关注方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2012103588529A CN102902455A (zh) | 2012-09-25 | 2012-09-25 | 一种社交***的加关注方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102902455A true CN102902455A (zh) | 2013-01-30 |
Family
ID=47574709
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2012103588529A Pending CN102902455A (zh) | 2012-09-25 | 2012-09-25 | 一种社交***的加关注方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102902455A (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103473297A (zh) * | 2013-09-05 | 2013-12-25 | 北京邮电大学 | 一种基于智能移动终端的多媒体问答***和方法 |
CN104767672A (zh) * | 2014-01-08 | 2015-07-08 | 北大方正集团有限公司 | 一种账户关系建立方法及设备 |
CN104966217A (zh) * | 2015-07-09 | 2015-10-07 | 威海迈拓思网络科技有限公司 | 一种通过页面关注发放商品的方法及其终端 |
CN105139259A (zh) * | 2015-08-25 | 2015-12-09 | 百度在线网络技术(北京)有限公司 | 用户操作行为的处理方法及装置 |
CN105843465A (zh) * | 2016-02-19 | 2016-08-10 | 乐视移动智能信息技术(北京)有限公司 | 一种作者关注方法、终端、服务器和*** |
CN108875023A (zh) * | 2018-06-20 | 2018-11-23 | 郑州村村联网络技术有限公司 | 动态属性的生成方法及装置 |
WO2020173284A1 (zh) * | 2019-02-26 | 2020-09-03 | 北京达佳互联信息技术有限公司 | 互动内容展示方法、装置、电子设备及存储介质 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101324879A (zh) * | 2008-07-31 | 2008-12-17 | 崔高 | 一种实现人脉关系或人际关系共享的网站***和方法 |
CN101521590A (zh) * | 2009-04-10 | 2009-09-02 | 腾讯科技(深圳)有限公司 | 展示好友动态的方法和装置 |
US20100205179A1 (en) * | 2006-10-26 | 2010-08-12 | Carson Anthony R | Social networking system and method |
CN102045273A (zh) * | 2010-12-28 | 2011-05-04 | 位涛 | 一种通过页面关注将互联网信息订阅到社交网络的方法 |
CN102169561A (zh) * | 2011-04-07 | 2011-08-31 | 姜华 | 一种根据用户间的关联性展示信息的方法 |
WO2011130034A2 (en) * | 2010-04-16 | 2011-10-20 | Intel Corporation | Methods and systems for relationship characterization and utilization from a users social networks |
-
2012
- 2012-09-25 CN CN2012103588529A patent/CN102902455A/zh active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100205179A1 (en) * | 2006-10-26 | 2010-08-12 | Carson Anthony R | Social networking system and method |
CN101324879A (zh) * | 2008-07-31 | 2008-12-17 | 崔高 | 一种实现人脉关系或人际关系共享的网站***和方法 |
CN101521590A (zh) * | 2009-04-10 | 2009-09-02 | 腾讯科技(深圳)有限公司 | 展示好友动态的方法和装置 |
WO2011130034A2 (en) * | 2010-04-16 | 2011-10-20 | Intel Corporation | Methods and systems for relationship characterization and utilization from a users social networks |
CN102045273A (zh) * | 2010-12-28 | 2011-05-04 | 位涛 | 一种通过页面关注将互联网信息订阅到社交网络的方法 |
CN102169561A (zh) * | 2011-04-07 | 2011-08-31 | 姜华 | 一种根据用户间的关联性展示信息的方法 |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103473297A (zh) * | 2013-09-05 | 2013-12-25 | 北京邮电大学 | 一种基于智能移动终端的多媒体问答***和方法 |
CN104767672A (zh) * | 2014-01-08 | 2015-07-08 | 北大方正集团有限公司 | 一种账户关系建立方法及设备 |
CN104966217A (zh) * | 2015-07-09 | 2015-10-07 | 威海迈拓思网络科技有限公司 | 一种通过页面关注发放商品的方法及其终端 |
CN105139259A (zh) * | 2015-08-25 | 2015-12-09 | 百度在线网络技术(北京)有限公司 | 用户操作行为的处理方法及装置 |
CN105843465A (zh) * | 2016-02-19 | 2016-08-10 | 乐视移动智能信息技术(北京)有限公司 | 一种作者关注方法、终端、服务器和*** |
WO2017140098A1 (zh) * | 2016-02-19 | 2017-08-24 | 乐视控股(北京)有限公司 | 一种作者关注方法、终端、服务器和*** |
CN108875023A (zh) * | 2018-06-20 | 2018-11-23 | 郑州村村联网络技术有限公司 | 动态属性的生成方法及装置 |
WO2020173284A1 (zh) * | 2019-02-26 | 2020-09-03 | 北京达佳互联信息技术有限公司 | 互动内容展示方法、装置、电子设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102902455A (zh) | 一种社交***的加关注方法 | |
CN104395871B (zh) | 用于赞同推荐内容的用户界面 | |
CA2948922C (en) | Method and system for conducting ecommerce transactions in messaging via search, discussion and agent prediction | |
US20170364599A1 (en) | Application for enhancing metadata tag uses for social interaction | |
US9177294B2 (en) | Social network site including invitation functionality | |
CN103282937B (zh) | 用于在社交网络中共享内容的内容共享接口 | |
CN114945906A (zh) | 可自定义的通信平台 | |
US9799082B1 (en) | System and method for conversation discovery | |
CN103975361B (zh) | 用于呈现社交内容的方法和*** | |
CN110383772A (zh) | 用于消息收发机器人丰富通信的技术 | |
CN104954234B (zh) | 一种微博数据获取方法、装置及舆情分析方法 | |
CN101217640B (zh) | 一种p2p视频点播中实现节目收藏的方法和设备 | |
CN103930920A (zh) | 在社交网络服务中将内容共享到发现的内容流 | |
CN104981792A (zh) | 针对内容项汇总交互 | |
CN101551892A (zh) | 一种城市生活信息平台及实现方法 | |
CN103052926A (zh) | 利用社交联网进行媒体共享 | |
WO2015149321A1 (en) | Personal digital engine for user empowerment and method to operate the same | |
CN106330668A (zh) | 一种微信投票实现方法及*** | |
CN106339918A (zh) | 一种订单生成方法及装置 | |
CN103873945A (zh) | 与视频节目中对象进行社交的***、方法 | |
CN101416185A (zh) | 动态交互式娱乐 | |
CN102882940A (zh) | 一种互联网领域的信息***中用户之间的浏览托管方法 | |
Zhang et al. | A novel social situation analytics-based recommendation algorithm for multimedia social networks | |
WO2021031941A1 (zh) | 会话数据处理方法、装置、用户终端以及存储介质 | |
CN105681155B (zh) | 即时通讯中的用户信息处理方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C05 | Deemed withdrawal (patent law before 1993) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20130130 |