一种树型架构用户跨节点自组织系统及其使用方法与流程

文档序号:11864732阅读:144来源:国知局

本发明涉及一种树型架构用户跨节点自组织系统及其使用方法。

发明背景

传统CRM、ERP类管理系统中,由于采用管理员统一分配用户ID以及业务数据割裂式管理方法,用户关系圈封闭,关系去向单一,不能自由配置整个行业价值链上各种类型用户之间错综复杂关系,不利于跨边界用户自主合作以实现行业价值链节点间的纵/横协同,也不利于获得用户真实评价数据从而阻碍众多对数据个性化要求不高的中小企业用户经营发展。

在采用用户申请注册制的电商网站中,由于用户组织关系已被固定设置(仅有买卖关系),不涉及跨边界用户之间复杂关系的配置。

在采用用户申请注册制的社交网站中,由于申请注册仅强调用户个体行为,虽然用户关系高度对称、开放,高可配性,但缺乏层级管理属性,其间关系仅“平面化”而非“扁平化”,体现出松散、非结构化、信任度不够(即使实名注册)等特征;因此,这类用户组织机制仅适合于传播个体间、娱乐化、追溯性不强信息,不适合面向效率经营的企业用户之间跨区域、跨行业组织管理需要。

另一方面,用户申请注册机制也增加了运营商对海量用户的管理难度,进而影响到用户对网站内容的信任度。



技术实现要素:

本发明针对现有技术的不足,而提供一种树型架构用户跨节点自组织系统及其使用方法。

本发明的一种树型架构用户跨节点自组织系统,其特征在于,所述系统基于云端服务器和用户浏览器环境,通过众多树型架构中的节点用户间自主分配识别账号,使跨节点用户之间可以动态构建关系用户圈及关系用户链。

每个所述树型架构由“一个根节点及其旗下n个干节点、n个枝节点、n个叶节点”共四级垂直节点组成。

所述系统设定1个后台管理员角色,同时定义其他四种身份的树型架构用户,所述树型架构用户包括根节点用户、干节点用户、枝节点用户、叶节点用户;所述根节点用户兼具干节点用户身份,干节点用户兼具枝节点用户身份;每个所述树型架构中包含两种或两种以上身份的节点用户;同一或不同的所述树型架构中,节点用户的产生规则为:根节点用户扩展干节点用户、干节点用户扩展枝节点用户、枝节点用户扩展叶节点用户,其中,所述规则中的节点用户彼此互为上层(级)节点用户和下层(级)节点用户。

所述关系用户圈由每个树型架构的节点用户组成;每个所述树型架构中一个根节点用户加上n个干节点用户组成一个1级关系圈,一个干节点用户加上n个枝节点用户组成一个2级关系圈,一个枝节点用户加上n个叶节点用户组成一个3级关系圈;所述树型架构关联的圈主指1级关系圈、2级关系圈、3级关系圈中处于上一层级的单个用户,即单个根节点用户、干节点用户或枝节点用户。

一种树型架构用户跨节点自组织系统的使用方法,所述使用方法包括如下步骤:

步骤一、新增根节点用户;

后台管理员创建根节点用户,创建时,管理员在输入用于证明用户唯一存在的实物材料字段后,系统按照时间戳附加2位随机数的规则,为根节点用户生成一个唯一性识别账号,保存入用户表中;根节点用户登录系统后,自主定义所主导的1级关系圈名称,并以兼任干节点用户身份定义所主导的2级关系圈名称,系统则自动将根节点所处关系圈、以及根节点用户定义的关系圈名称字段等一并存入用户关系圈表中;

步骤二、新增干节点用户;

干节点用户由根节点用户自主创建,首先,根节点用户基于1级关系圈,在输入用于证明干节点用户唯一存在的实物材料字段后,系统按照时间戳附加2位随机数的规则,为干节点用户生成一个唯一性识别账号,保存入用户表中,并同步将干节点用户所处关系圈属性写入用户关系圈表;系统还将根节点用户账号和其自主创建的干节点用户账号自动建立起关联关系,并将这种关联关系写入好友关系表中;在干节点用户提交资质审材料给创建自己的根节点用户进行审核并经其审核通过后,系统正式完成对用户表中的干节点用户账号、用户关系圈表中干节点用户的关系圈属性、以及好友关系表中根节点用户与干节点用户之间关联关系数据的保存写入;干节点用户登录系统后,可以自主定义所主导的2级关系圈名称,系统则自动将其定义的关系圈名称字段存入用户关系圈表中;所述干节点用户可被系统内其他用户所检索;

步骤三、新增枝节点用户;

枝节点用户由干节点用户自主创建,首先,干节点用户基于自身主导的2级关系圈,在输入用于证明枝节点用户唯一存在的实物材料字段后,系统即按照时间戳附加2位随机数的规则规则,为枝节点用户生成一个唯一性识别账号,保存入用户表中,并同步将枝节点用户所处关系圈属性写入用户关系圈表,同时,系统还将干节点用户账号和其自主创建的枝节点用户账号自动建立起关联关系,并将这种关联关系写入好友关系表中;其次,在枝节点用户提交资质审材料给创建自己的干节点用户进行审核并经其审核通过后,系统正式完成对用户表中的枝节点用户账号、用户关系圈表中枝节点用户的关系圈属性、以及好友关系表中干节点用户与枝节点用户之间关联关系等数据的保存写入;后台管理员及枝节点用户所在树型结构中的根节点用户均可对枝节点用户提交的资质材料进行抽审,抽审不通过指令下达时,系统自动修改枝节点用户在用户表的有效字段以及枝节点用户在好友关系表中的相关关联关系字段;第三,枝节点用户登录系统后,可以自主定义所主导的3级关系圈名称,系统则自动将其所定义的关系圈名称字段存入用户关系圈表中;

步骤四、新增叶节点用户;

叶节点用户由枝节点用户自主创建;首先,枝节点用户基于自身主导的3级关系圈,在输入用于证明叶节点用户唯一存在的实物材料字段后,系统按照时间戳附加2位随机数的规则,为叶节点用户生成一个唯一性识别账号,保存入用户表中,并同步将叶节点用户所处关系圈属性写入用户关系圈表;同时,系统还将枝节点用户账号和其自主创建的叶节点用户账号自动建立起关联关系,并将这种关联关系写入好友关系表;其次,在叶节点用户提交资质审材料给创建自己的枝节点用户进行审核并经其审核通过后,系统正式完成对用户表中的叶节点用户账号、用户关系圈表中叶节点用户的关系圈属性、以及好友关系表中枝节点用户与叶节点用户之间关联关系等数据的保存写入;后台管理员及叶节点用户所在树型结构中的根节点用户均可对叶节点用户提交的资质材料进行抽审;抽审不通过指令下达时,系统自动修改叶节点用户在上述相关数据表中所有关联字段;

步骤五、同一关系圈内用户互为好友;

同一关系圈内,上节点用户与下节点用户之间默认互为好友;基于用户均可被所检索属性,同级节点用户之间可以通过触发关注事件互加为好友,所述关注事件的类型由系统自动判断;

节点用户点击关注时,系统在数据库中首先生成一条互加好友的请求记录,所述请求记录包含发起方、接受方、接受方是否同意的字段,同时生成好友对应关系记录,关系记录包含发起方、接受方、好友关系的字段,随后发送一条征询对方是否同意成为好友的消息给接受方;如果接受方触发消息中的同意按钮,将对应的请求记录更新为接受方已同意,同时更新好友关系表,好友关系由待审核更新为互为好友;如果接受方触发不同意按钮,将对应的请求记录更新为接受方不同意,同时删除好友关系表中对应的好友关系记录;

步骤六、不同关系圈内的上节点用户向非本圈下节点用户邀请合作并结为好友;

基于系统内用户均可被所检索属性,在不同关系圈之间,当上节点用户选择向非本圈下节点用户发起合作申请时,在上节点用户点击加为好友类按钮后,系统首先生成一条互加好友的请求记录,请求记录包含发起方、接受方、交友路径为上层对下层、接受方是否同意的字段,同时生成好友对应关系记录,关系记录包含发起方、接受方、好友关系的字段,随后发送一条征询对方是否同意成为好友的消息给接受方;

如果接受方触发消息中的同意按钮,接受方加入发起方所在的关系圈,并将对应的请求记录更新接受方已同意,同时更新好友关系表及用户关系圈表,好友关系由待审核更新为互为好友;如果接受方不同意,将对应的请求记录更新为接受方不同意,同时删除好友关系表中对应的好友关系记录;

步骤七、不同关系圈内的下节点用户向非本圈上节点用户申请合作并结为好友;

基于系统内用户均可被所检索属性,在不同关系圈之间,当下节点用户选择向非本圈上节点用户发起合作申请时,在下节点用户点击加为好友类按钮之后,系统首先生成一条互加好友的请求记录,所述请求记录包含发起方、接受方、交友路径为下层对上层、接受方是否同意的字段,同时生成好友对应关系记录,所述关系记录包含发起方、接受方、好友关系等字段,随后发送一条征询对方是否同意成为好友的消息给接受方;

如果接受方触发消息中同意按钮,发起方加入接受方所在关系圈,并将对应的请求记录更新接受方已同意,同时更新好友关系表,好友关系由待审核更新为互为好友;如果接受方不同意,将对应的请求记录更新为接受方不同意,同时删除好友关系表中对应的好友关系记录;

步骤八、不同关系圈的用户发起方向非本圈的同级节点用户申请合作并结为好友;

在不同关系圈之间,当发起方用户选择向本圈外同级节点用户发起合作申请时,在发起方点击加为好友类按钮之后,系统首先生成一条互加好友型请求记录,请求记录包含发起方、接受方、发起方的上节点用户、交友路径为平级、接受方是否同意、圈主是否同意的字段,同时生成好友对应关系记录,关系记录包含发起方、接受方、好友关系的字段,并发送一条发起方邀请接受方加入圈主所在的关系圈,并结为好友类消息给圈主;

圈主(发起方的上级节点用户)收到消息后,确定是否同意接受方加入自己所在的关系圈;

圈主如果触发所收消息中的同意按钮,接受方加入圈主所在的关系圈,系统的数据库随之更新对应的请求记录圈主已同意加好友请求表,同时,发送一条是否同意与发起方成为好友类消息给接受方;

接受方收到消息后,如果触发消息中的同意按钮,系统的数据库随之更新对应的请求接受方已同意,同时更新好友关系表及用户关系表,好友关系由待审核更新为互为好友;如果接受方不同意,将对应的请求记录更新为接受方不同意加好友请求表,同时删除好友关系表中对应的好友关系记录;

圈主如果触发消息中的不同意按钮,系统的数据库随之更新对应的请求圈主不同意加好友请求表,并删除好友关系表中对应的好友关系记录,同时自动回复一条圈主不同意接受方加入圈主所在的关系圈的消息给发起方消息表。

本发明的有益效果是:

(1)本发明在高度开放型和高度封闭型用户组织方法之间找到一种兼具两者优势的企业用户关系组织方法和系统;用户之间既可保持层级管理属性又具备双向自组关系功能;

(2)既可保持用户原有关系圈的稳定性和相对封闭性,也使得既有关系圈具备可控开放性,可以向圈中动态增加相关社会用户;

(3)用户可基于所在关系圈动态配置与其他圈内用户之间的关系链,使得用户在保持独立自主及竞争运作基础上,又可满足集体协调合作需要;

(4)本发明可应用于众多行业,服务于其中跨组织、跨体制、跨区域用户之间组建扁平化、矩阵式合作体系,以实现行业价值链节点之间的业务纵/横协同。

附图说明

图1为本发明的运作流程图。

具体实施方式

下面通过具体实施例,对本发明的技术方案作进一步具体的说明,但是本发明并不限于实施例。

本发明的一种树型架构用户跨节点自组织系统,所述系统基于云端服务器和用户浏览器环境,通过众多树型架构中的节点用户间自主分配识别账号,使跨节点用户之间可以动态构建关系用户圈及关系用户链。

每个所述树型架构由“一个根节点及其旗下n个干节点、n个枝节点、n个叶节点”共四级垂直节点组成。

所述系统设定1个后台管理员角色,同时定义其他四种身份的树型架构用户,所述树型架构用户包括根节点用户、干节点用户、枝节点用户、叶节点用户;所述根节点用户兼具干节点用户身份,干节点用户兼具枝节点用户身份;每个所述树型架构中包含两种或两种以上身份的节点用户;同一或不同的所述树型架构中,节点用户的产生规则为:根节点用户扩展干节点用户、干节点用户扩展枝节点用户、枝节点用户扩展叶节点用户,其中,所述规则中的节点用户彼此互为上层(级)节点用户和下层(级)节点用户。

所述关系用户圈由每个树型架构的节点用户组成;每个所述树型架构中一个根节点用户加上n个干节点用户组成一个1级关系圈,一个干节点用户加上n个枝节点用户组成一个2级关系圈,一个枝节点用户加上n个叶节点用户组成一个3级关系圈;所述树型架构关联的圈主1级关系圈、2级关系圈、3级关系圈中处于上一层级的单个用户,即单个根节点用户、干节点用户或枝节点用户。

一种树型架构用户跨节点自组织系统的使用方法,所述使用方法包括如下步骤:

步骤一、新增根节点用户;

首先,通过后台管理员创建根节点用户。创建时,管理员在输入用于证明用户唯一存在的实物材料字段(如营业执照公司名称、组织机构代码或身份证号码等)后,系统即按“时间戳+2位随机数”规则,为根节点用户生成一个唯一性识别ID(账号),保存入用户表(附表1)中。

其次,根节点用户登录系统后,可以自主定义所主导的1级关系圈名称,并以兼任干节点用户身份定义所主导的2级关系圈名称,系统则自动将根节点所处关系圈、以及根节点用户定义的关系圈名称字段等一并存入用户关系圈表(附表2)中。

步骤二、新增干节点用户;

干节点用户由根节点用户自主创建。

首先,根节点用户基于1级关系圈,在输入用于证明干节点用户唯一存在的实物材料字段(如营业执照公司名称、组织机构代码或身份证号码等)后,系统即按“时间戳+2位随机数”规则,为干节点用户生成一个唯一性识别ID(账号),保存入用户表(附表1)中,并同步将干节点用户所处关系圈属性写入用户关系圈(附表2)表。

同时,系统还将根节点用户ID和其自主创建的干节点用户ID自动建立起关联关系(好友关系),并将这种关联关系写入好友关系表(附表3)中。

其次,在干节点用户提交资质审材料给创建自己的根节点用户进行审核并经其审核通过后,系统正式完成对用户表中的干节点用户ID、用户关系圈表中干节点用户的关系圈属性、以及好友关系表中根节点用户与干节点用户之间关联关系等数据的保存写入。

第三,干节点用户登录系统后,可以自主定义所主导的2级关系圈名称,系统则自动将其定义的关系圈名称字段存入用户关系圈表(附表2)中。

干节点用户可被系统内其他用户所检索。

步骤三、新增枝节点用户;

枝节点用户由干节点用户自主创建。

首先,干节点用户基于自身主导的2级关系圈,在输入用于证明枝节点用户唯一存在的实物材料字段(如营业执照公司名称、组织机构代码或身份证号码等)后,系统即按“时间戳+2位随机数”规则,为枝节点用户生成一个唯一性识别ID,保存入用户表(附表1)中,并同步将枝节点用户所处关系圈属性写入用户关系圈(附表2)表。

同时,系统还将干节点用户ID和其自主创建的枝节点用户ID自动建立起关联关系(好友关系),并将这种关联关系写入好友关系表(附表3)中。

其次,在枝节点用户提交资质审材料给创建自己的干节点用户进行审核并经其审核通过后,系统正式完成对用户表中的枝节点用户ID、用户关系圈表中枝节点用户的关系圈属性、以及好友关系表中干节点用户与枝节点用户之间关联关系等数据的保存写入。

为保障枝节点用户的合法性,后台管理员及枝节点用户所在树型结构中的根节点用户均可对枝节点用户提交的资质材料进行抽审。抽审不通过指令下达时,系统自动修改枝节点用户在用户表的有效字段以及枝节点用户在好友关系表中的相关关联关系字段。

第三,枝节点用户登录系统后,可以自主定义所主导的3级关系圈名称,系统则自动将其所定义的关系圈名称字段存入用户关系圈表(附表2)中。

步骤四、新增叶节点用户;

叶节点用户由枝节点用户自主创建。

首先,枝节点用户基于自身主导的3级关系圈,在输入用于证明叶节点用户唯一存在的实物材料字段(如营业执照公司名称、组织机构代码或身份证号码等)后,系统即按“时间戳+2位随机数”规则,为叶节点用户生成一个唯一性识别ID(账号),保存入用户表(附表1)中,并同步将叶节点用户所处关系圈属性写入用户关系圈(附表2)表。

同时,系统还将枝节点用户ID和其自主创建的叶节点用户ID自动建立起关联关系(好友关系),并将这种关联关系写入好友关系表(附表3)。

其次,在叶节点用户提交资质审材料给创建自己的枝节点用户进行审核并经其审核通过后,系统正式完成对用户表中的叶节点用户ID、用户关系圈表中叶节点用户的关系圈属性、以及好友关系表中枝节点用户与叶节点用户之间关联关系等数据的保存写入。

为保障叶节点用户的合法性,后台管理员及叶节点用户所在树型结构中的根节点用户均可对叶节点用户提交的资质材料进行抽审。抽审不通过指令下达时,系统自动修改叶节点用户在上述相关数据表中所有关联字段。

步骤五、同一关系圈内用户互为好友(图1)

同一关系圈内,上节点用户与下节点用户之间默认互为好友;基于用户均可被所检索属性,同级节点用户之间可以通过触发“关注”事件互加为好友【注:系统自动判断事件类型】。

点击“关注”时,系统(数据库中)首先生成一条互加好友的请求记录(包含发起方、接受方、接受方是否同意等字段)(附表4),同时生成好友对应关系记录(包含发起方、接受方、好友关系(待审核)等字段)(附表3),随后发送一条“征询对方是否同意成为好友”的消息给接受方(附表5)。

如果接受方触发消息中的“同意”按钮,将对应的请求记录更新为接受方“已同意”,同时更新好友关系表(附表3),好友关系由“待审核”更新为“互为好友”;如果接受方触发“不同意”按钮,将对应的请求记录更新为接受方“不同意”(附表4),同时删除好友关系表(附表3)中对应的好友关系记录

步骤六、不同关系圈内的上节点用户向非本圈下节点用户邀请合作并结为好友(图1);

基于用户均可被所检索属性,在不同关系圈之间,当上节点用户选择向非本圈下节点用户发起合作申请时,在上节点用户点击“加为好友”类按钮后【注:系统自动判断事件类型】,系统(数据库)首先生成一条互加好友的请求记录(包含发起方、接受方、交友路径(上对下)、接受方是否同意等字段)(附表4),同时生成好友对应关系记录(包含发起方、接受方、好友关系(待审核)等字段)(附表3),随后发送一条“征询对方是否同意成为好友”的消息给接受方(附表5)。

如果接受方触发消息中的“同意”按钮,接受方加入发起方所在的关系圈,并将对应的请求记录更新接受方“已同意”(附表4),同时更新好友关系表(附表3)及用户关系圈表(附表2),好友关系由“待审核”更新为“互为好友”;如果接受方不同意,将对应的请求记录更新为接受“不同意”(附表4),同时删除好友关系表(附表3)中对应的好友关系记录。

步骤七、不同关系圈内的下节点用户向非本圈上节点用户申请合作并结为好友(图1)

基于用户均可被所检索属性,在不同关系圈之间,当下节点用户选择向非本圈上节点用户发起合作申请时,在下节点用户点击“加为好友”类按钮之后【注:系统自动判断事件类型】,系统(数据库中)首先生成一条互加好友的请求记录(包含发起方、接受方、交友路径(下对上)、接受方是否同意等字段)(附表4),同时生成好友对应关系记录(包含发起方、接受方、好友关系(待审核)等字段)(附表3),随后发送一条“征询对方是否同意成为好友”的消息给接受方并更新消息表(附表5)。

如果接受方触发消息中“同意”按钮,发起方加入接受方所在关系圈,并将对应的请求记录更新接受方“已同意”(附表4),同时更新好友关系表(附表3),好友关系由“待审核”更新为“互为好友”;如果接受方不同意,将对应的请求记录更新为接受“不同意”(附表4),同时删除好友关系表(附表3)中对应的好友关系记录。

步骤八、不同关系圈的用户(发起方)向非本圈的同级节点用户申请合作并结为好友(图1)

基于用户均可被所检索属性,在不同关系圈之间,当发起方(用户)选择向本圈外同级节点用户发起合作申请时,在发起方点击“加为好友”类按钮之后【注:系统自动判断事件类型】,系统(数据库)首先生成一条互加好友型请求记录(包含发起方、接受方、发起方的上节点用户(即圈主)、交友路径(平级)、接受方是否同意、圈主是否同意等字段)(附表4),同时生成好友对应关系记录(包含发起方、接受方、好友关系(待审核)等字段)(附表3),并发送一条“发起方邀请接受方加入圈主所在的关系圈,并结为好友”类消息给圈主(附表5)。

圈主(发起方的上级节点用户)收到消息后,确定是否同意接受方加入自己所在的关系圈。

圈主如果触发所收消息中的“同意”按钮,接受方加入圈主所在的关系圈,系统(数据库)随之更新对应的请求记录“圈主已同意”(附表4),同时,发送一条“是否同意与发起方成为好友”类消息给接受方并更新消息表(附表5)。

接受方收到消息后,如果触发消息中的“同意”按钮,系统(数据库)随之更新对应的请求“接受方已同意”,同时更新好友关系表(附表3)及用户关系圈(附表2)表,好友关系由“待审核”更新为“互为好友”;如果接受方不同意,将对应的请求记录更新为接受“不同意”(附表4),同时删除好友关系表(附表3)中对应的好友关系记录。

圈主如果触发消息中的“不同意”按钮,系统(数据库)随之更新对应的请求“圈主不同意”(附表4),并删除好友关系表(附表3)中对应的好友关系记录,同时自动回复一条“圈主不同意接受方加入圈主所在的关系圈”类消息给发起方(附表5)。

附表1:用户表

附表2:用户关系表

附表3:好友关系表

附表4:加好友请求表

附表5:消息表

以上所述仅为本发明的实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1