Account permission intelligent collaborative management method and system for AIGC platform

Abstract

The application provides an account permission intelligent collaborative management and control method and system for an AIGC platform, relates to the technical field of account management, and comprises the following steps: taking generated content as a new node, recording the generator and the cited upstream content as parent nodes, and writing the content blood relationship graph; calculating the intersection of access constraints as an initial access constraint; checking whether each parent node meets the access constraint of the sub-account one by one, and refusing access if any parent node fails the check; reading the content blood relationship graph, calculating the comprehensive contribution score, and dynamically adjusting the permission seed state of the sub-account. The technical problems of the prior art, such as the broken content permission management and control link of the AIGC platform and the rigid inability of the sub-account permission to dynamically adapt to the actual contribution, are solved. The content blood relationship graph is constructed to trace and check the whole-link permission, the contribution degree is dynamically matched to adjust the sub-account permission, and the technical effects of platform content whole-life-cycle safety management and control and account permission intelligent collaboration are achieved.

Description

Technical Field

[0001] This invention relates to the field of account management technology, specifically to a method and system for intelligent collaborative management of account permissions for AIGC platforms. Background Technology

[0002] In current AIGC (Artificial Intelligence Generated Content) platforms, collaborative creation by multiple sub-accounts has become the mainstream working model. However, existing permission control solutions generally adopt role-based access control or static access control lists, directly binding permissions to user roles or preset policies. Their control granularity is limited to a single piece of content or a fixed directory level. Under such mechanisms, when newly generated content references multiple upstream sources, such as images, text, and parameter configurations, the platform cannot automatically identify and inherit the permission requirements of all sources. This causes the permission policy to gradually break down as the content derivative chain extends, making subsequent content accessible only based on the creator's or the directory's permissions, leading to a serious risk of cross-level content leakage.

[0003] Meanwhile, the permission levels of existing accounts are usually statically granted upon joining or manually adjusted by administrators, which are completely disconnected from the actual value generated in collaborative creation. This rigid permission allocation model results in high-contribution users not being able to obtain corresponding increases in creative freedom, while low-contribution or risky accounts cannot be subject to timely additional control, which seriously restricts the platform's security governance efficiency and the healthy operation of the creator ecosystem.

[0004] In summary, existing technologies suffer from technical problems such as broken content permission control links on AIGC platforms, sub-account permissions failing to dynamically adapt to actual contributions, leading to cross-level content leakage and rigid permission allocation. Summary of the Invention

[0005] The purpose of this application is to provide a method and system for intelligent collaborative management of account permissions for AIGC platforms, in order to solve the technical problems of broken content permission management links in AIGC platforms, the inability of sub-account permissions to dynamically adapt to actual contributions, resulting in cross-level content leakage and rigid permission allocation.

[0006] In view of the above problems, this application provides a method and system for intelligent collaborative management of account permissions for the AIGC platform.

[0007] The first aspect of this application provides a method for intelligent collaborative management of account permissions for AIGC platforms. This method includes: responding to a content generation task initiated by a sub-account, using the generated content as a new node, recording the generator and the referenced upstream content as parent nodes, and writing this into a content lineage graph; reading the access constraints of the parent nodes, calculating the intersection of the access constraints, and using the intersection as the initial access constraints of the new node and binding and storing it; responding to any sub-account's access request to the new node, tracing all parent nodes upwards along the content lineage graph and verifying whether each sub-account meets the access constraints of each parent node; if any parent node fails verification, access is denied; reading the content lineage graph at a preset period, calculating a comprehensive contribution score based on the frequency of the content generated by each sub-account being referenced by subsequent nodes, the retention rate in the final product, and the degree of cross-role group propagation; dynamically adjusting the permission seed state of the sub-account based on the comprehensive contribution score; and when the sub-account initiates content generation again, using the sub-account carrying the permission seed state as the generator to execute access constraints.

[0008] Optionally, the sub-account initiates a content generation request through the AIGC platform's creation interface. The request includes the prompt text used in this generation, the selected AI model identifier, and one or more upstream content IDs referenced. When the content generation request is completed, a node data structure is constructed, using the generated content entity as a new node, the generator sub-account ID and generation timestamp as node attributes, and the upstream content ID as the parent node pointer. The node data structure is written into a content lineage graph, where each node contains a unique node identifier, a generator identifier, a generation timestamp, and a content storage address. Each edge records the reference relationship between child nodes and parent nodes, as well as the reference time. After successful writing, a node writing completion event is sent to the permission self-organizing propagation module, with the event payload containing the unique identifier of the new node and all parent node IDs.

[0009] Optionally, the content lineage graph adopts a directed acyclic graph structure. When writing a new node, a cycle detection is performed: starting from the new node, traverse along the directed edge towards the root node. If the ID of the new node itself is encountered during the traversal, it is determined that there is a closed loop reference, the writing is rejected and an error message is returned.

[0010] Optionally, the system receives an access request from the first sub-account to the new node and obtains the node identifier of the new node; starting from the new node, it obtains the parent node by moving upwards along the directed edges of the content lineage graph and adds the parent node to the verification queue; it retrieves a node from the verification queue, reads the pre-stored access constraint set of the node, and verifies whether the first sub-account meets all the conditions of the access constraint set; if the verification passes, it determines whether the verification queue is empty; if it is not empty, it returns to continue verifying the next node; if the verification fails, it terminates the verification and rejects the access request; when the verification queue is empty and all verified nodes have passed, the first sub-account is allowed to access the new node.

[0011] Optionally, starting from the new node, the content lineage graph is recursively traversed upwards along a path until the root node is reached. After verifying all nodes on the path, the process backtracks to the nearest fork point and continues traversing the next path until the content lineage graph is recursively traversed to obtain the queue to be verified. The recursion depth of a single access request does not exceed a preset maximum depth.

[0012] Optionally, the full data of the content lineage graph is read at a preset period, all nodes and edge relationships are traversed, and for each sub-account, the total number of times each node in the generated node set is set as a parent node by other nodes within the preset period is counted and recorded as the direct reuse contribution value; the set of nodes marked as final products in the content lineage graph is identified, and all parent node sets are obtained for each finished product node, and the retention contribution value of each sub-account in all finished product nodes is calculated; the number of times the content generated by each sub-account is accessed and regenerated by members of role groups other than its own account is counted and recorded as the cross-domain propagation contribution value; the direct reuse contribution value, the retention contribution value, and the cross-domain propagation contribution value are weighted and calculated to generate a comprehensive contribution score corresponding to each sub-account.

[0013] Optionally, the expression for calculating the retention contribution value of each sub-account across all finished product nodes is as follows: ;in, The retention contribution value for sub-account X; The set of nodes that are marked as the final product; To be included in Finished product nodes in the process; For finished product nodes The set of all parent nodes; To generate a set of nodes; This indicates the number of elements in the set.

[0014] Optionally, starting from the finished node p, recursively traverse along the reverse direction of the directed edges in the content lineage graph until the root node, and denote the set of all nodes on the traversal path as A(p).

[0015] Optionally, the permission seed state includes at least a permission exemption enabled state and a secondary approval required state; wherein, when the comprehensive contribution score is higher than the first preset threshold for M consecutive periods, permission exemption is enabled for the corresponding sub-account; when the comprehensive contribution score is lower than the second preset threshold for M consecutive periods, a secondary approval required flag is added for the corresponding sub-account, wherein the first preset threshold is greater than the second preset threshold.

[0016] A second aspect of this application provides an intelligent collaborative management system for account permissions on an AIGC platform. This system includes: a graph writing module, used to respond to a content generation task initiated by a sub-account, using the generated content as a new node, recording the generator and the referenced upstream content as parent nodes, and writing it into a content lineage graph; a constraint determination module, used to read the access constraints of the parent nodes, calculate the intersection of the access constraints, and use the intersection as the initial access constraint for the new node and bind and store it; and a constraint verification module, used to respond to any sub-account's access request to the new node. The system requests that the following steps be taken: tracing upwards along the content lineage graph to identify all parent nodes and verifying whether each sub-account meets the access constraints of its parent node; if any parent node fails verification, access is denied; a contribution calculation module is used to read the content lineage graph at preset intervals and calculate a comprehensive contribution score based on the frequency of the content generated by each sub-account being referenced by subsequent nodes, the retention rate in the final product, and the degree of cross-role group propagation; an account adjustment module is used to dynamically adjust the permission seed status of sub-accounts based on the comprehensive contribution score. When a sub-account initiates content generation again, the sub-account carrying the permission seed status is used as the generator to enforce access constraints.

[0017] One or more technical solutions provided in this application have at least the following technical effects or advantages: The method provided in this application embodiment responds to a content generation task initiated by a sub-account, using the generated content as a new node, recording the generator and the referenced upstream content as parent nodes, and writing them into a content lineage graph; reading the access constraints of the parent nodes, calculating the intersection of the access constraints, and using the intersection as the initial access constraints of the new node and binding and storing them; responding to any sub-account's access request to the new node, tracing all parent nodes upwards along the content lineage graph and verifying whether each sub-account meets the access constraints of each parent node; if any parent node fails verification, access is denied; reading the content lineage graph at a preset period, calculating a comprehensive contribution score based on the frequency of the content generated by each sub-account being referenced by subsequent nodes, the retention rate in the final product, and the degree of cross-role group propagation; dynamically adjusting the permission seed state of the sub-account based on the comprehensive contribution score, and when the sub-account initiates content generation again, using the sub-account carrying the permission seed state as the generator to execute access constraints. It achieves the technical effect of tracing and verifying full-link permissions by constructing a content lineage graph, dynamically matching contribution to adjust sub-account permissions, and realizing full lifecycle security management and intelligent collaboration of account permissions on the AIGC platform.

[0018] The above description is merely an overview of the technical solution of this application. To better understand the technical means of this application and to facilitate its implementation according to the description, and to make the above and other objects, features, and advantages of this application more apparent, specific embodiments of this application are described below. It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent through the following description. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the intelligent collaborative management method for account permissions on the AIGC platform provided in this application.

[0021] Figure 2 This is a structural diagram of the intelligent collaborative management system for account permissions on the AIGC platform provided in this application.

[0022] Figure labeling: Graph writing module 11, constraint determination module 12, constraint verification module 13, contribution calculation module 14, account adjustment module 15. Detailed Implementation

[0023] This application provides a method and system for intelligent collaborative management of account permissions on AIGC platforms. It addresses the technical problems of existing technologies, such as broken content permission management chains on AIGC platforms, the inability of sub-account permissions to dynamically adapt to actual contributions, leading to cross-level content leakage and rigid permission allocation. The system achieves the technical effect of constructing a content lineage graph to trace and verify permissions across the entire chain, dynamically matching sub-account permissions based on contribution, and realizing secure management of the entire content lifecycle and intelligent collaborative management of account permissions on AIGC platforms.

[0024] The technical solutions of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. It should be understood that the present invention is not limited to the exemplary embodiments described herein. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention. It should also be noted that, for ease of description, only the parts related to the present invention are shown in the accompanying drawings, not all of them.

[0025] Example 1, as Figure 1 As shown, this application provides a method for intelligent collaborative management of account permissions for AIGC platforms. The method includes: In response to content generation tasks initiated by sub-accounts, the generated content is used as a new node, and the generator and the upstream content it references are recorded as parent nodes and written into the content lineage graph.

[0026] Furthermore, in response to a content generation task initiated by a sub-account, the generated content is used as a new node, and the generator and the referenced upstream content are recorded as parent nodes, and written into the content lineage graph. This includes: the sub-account initiating a content generation request through the AIGC platform's creation interface, the request including the prompt text used in this generation, the selected AI model identifier, and one or more referenced upstream content IDs; when the content generation request is completed, the generated content entity is used as a new node, the generator sub-account ID and generation timestamp are used as node attributes, and the upstream content ID is used as the parent node pointer, constructing a node data structure; the node data structure is written into the content lineage graph, where each node contains a unique node identifier, a generator identifier, a generation timestamp, and a content storage address, and each edge records the reference relationship between child nodes and parent nodes and the reference time; after successful writing, a node writing completion event is sent to the permission self-organizing propagation module, the event payload containing the unique identifier of the new node and all parent node IDs.

[0027] Furthermore, the content lineage graph adopts a directed acyclic graph structure. When writing a new node, a cycle detection is performed: starting from the new node, traverse along the directed edge towards the root node. If the ID of the new node itself is encountered during the traversal, it is determined that a closed loop reference exists, the write is rejected, and an error message is returned.

[0028] Specifically, when a sub-account—a secondary account under the main account with independent login credentials and operating permissions, such as accounts of different designers or copywriters within a team—initiates a content generation task through the creation interfaces provided by the AIGC platform, such as RESTful APIs or GraphQL endpoints, the AIGC platform receives the content generation task initiated by the sub-account. This content generation task includes at least a prompt text, a selected AI model identifier, and one or more upstream content IDs. The prompt text is a natural language instruction input by the user to guide the AI ​​model in generating content, such as "Generate a summer landscape painting containing snow-capped mountains and lakes." The selected AI model identifier is a unique ID assigned within the AIGC platform to different versions or types of generation models, such as Stable-Diffusion-v3.0 or GPT-5-Text. The one or more upstream content IDs referenced are unique identifiers of existing content used as a source of reference, adaptation, or direct inheritance during this generation process. Upstream content includes digital assets of any format, such as images, text, and audio, already stored within the AIGC platform.

[0029] Upon receiving a content generation request, the AIGC platform performs a validity check on the request parameters. This includes verifying whether the sub-account has permission to use the selected AI model, whether the prompt text contains prohibited words, and whether the referenced upstream content ID exists and whether the current sub-account has at least read-only access to it. If any check fails, an error response is returned and the process terminates. After successful verification, the AIGC platform calls the backend AI model inference service, loads the corresponding model based on the prompt text and model identifier, and performs content generation, outputting the generated content entity, such as a PNG image. After the content generation request response is completed, a new unique node identifier is created using the generated content entity as a new node. For example, a 64-bit globally unique ID is generated using the Snowflake algorithm. The generator sub-account ID and generation timestamp are written as node attributes. Simultaneously, the list of upstream content IDs carried in this request is directly used as the parent node pointer record, constructing the node data structure. Each parent node pointer is represented by a directed edge containing the child node ID, parent node ID, and reference timestamp. The node data structure is a set of key-value pairs or a relational tuple.

[0030] The node data structure is written into a content lineage graph, which uses a directed acyclic graph (DAG) storage model. Each node represents a piece of generated content and includes a unique node identifier, a generator identifier, a generation timestamp, and a content storage address. Each directed edge points from a child node to its directly referenced parent node and the reference time; the direction represents the reference relationship. The content lineage graph can be implemented using a graph database, such as Neo4j, or an edge table structure in a relational database. Cycle detection is performed when writing a new node: starting from the new node, recursively traversing all reachable parent nodes along the reverse direction of the directed edges (i.e., tracing back from the parent node to the grandparent node). If any node ID encountered during the traversal is equal to the new node's own ID, a closed cycle reference is determined, and the write is rejected with an error message returned. If no cycle exists, an atomic write is performed, committing the new node record and all edge records together. After a successful write, the AIGC platform sends a node write completion event to the permission self-organizing propagation module. The event payload contains the unique identifier of the new node and the IDs of all parent nodes. The permission self-organizing propagation module is a functional unit responsible for automatically calculating and binding access constraints of the new node based on the parent node information of the newly written node. The event payload refers to the specific data content carried in the node write completion event.

[0031] By explicitly solidifying the content generation process into a directed acyclic graph structure, complete tracing of the content derivative chain is achieved, ensuring that subsequent permission verification can obtain all parent nodes along the lineage path. At the same time, it provides clear parent node pointers for permission self-organization and propagation, so that the access constraints of new nodes can be automatically inherited and calculated from the upstream.

[0032] Read the access constraints of the parent node, calculate the intersection of the access constraints, and use the intersection as the initial access constraints of the new node and bind and store it.

[0033] Specifically, the permission self-organizing propagation module reads the pre-stored access constraints of each parent node from the content lineage graph. Access constraints refer to a set of access conditions defined on a node, expressed as: subject attribute ∈ allowed set. For example, "role: [designer, photographer], department: creative" means that only sub-accounts whose role attribute belongs to designer or photographer and whose department attribute belongs to creative department have the right to access the node. Access constraints are stored in the attribute fields of the graph database or in the associated key-value store along with the node records in JSON or structured document format.

[0034] After reading the access constraints, an intersection calculation is performed, merging the access constraint sets of all parent nodes using a logical AND operation. This means the new node's access constraints must simultaneously satisfy every condition of all parent nodes. For example, the intersection operation merges constraints one by one according to their dimensions. For enumerated values ​​of the same dimension, such as a role list, the intersection is the intersection of the allowed values ​​for that dimension from each parent node. For range-type conditions, such as IP ranges or time periods, the intersection is the overlapping portion of each condition's interval. For dimensions with no intersection, such as parent node A restricting access only to the design group and parent node B restricting access only to the copywriting group, the intersection of this dimension is empty, indicating that no sub-account can simultaneously satisfy all conditions of that dimension. If the intersection of a dimension is empty, the overall access constraints of the new node are set to "deny," i.e., empty constraints. Any subsequent access requests will be directly rejected unless the administrator manually overrides them or a dynamic adjustment mechanism intervenes. After the calculation is completed, the intersection obtained is used as the initial access constraint for the new node. After being serialized in the same structured format as the parent node, it is bound to the attribute field of the new node through the update operation of the graph database, such as the SET statement of Neo4j, to ensure that the constraint is persistently associated with the node record.

[0035] The initial access constraints of a new node are obtained by calculating the access constraints of the parent node. This means that the access permissions of new content do not need to be manually set by the administrator. Instead, they are derived from all directly upstream content through intersection operations. This ensures the bottom line of security that the permissions of the content cannot be more lenient than any of its sources, avoiding the risk of permission bloat or leakage caused by layer-by-layer generation. This provides an accurate and computable initial constraint benchmark.

[0036] In response to any sub-account's access request to the new node, trace all parent nodes upwards along the content lineage graph and verify whether the sub-account meets the access constraints of each parent node. If any parent node fails the verification, access is denied.

[0037] Furthermore, in response to any sub-account's access request to the new node, all parent nodes are traced upwards along the content lineage graph, and the sub-account is verified one by one to see if it meets the access constraints of each parent node. If any parent node fails verification, access is denied. This includes: receiving the first sub-account's access request to the new node and obtaining the node identifier of the new node; taking the new node as the starting node, obtaining parent nodes upwards along the directed edges of the content lineage graph and adding the parent nodes to the verification queue; retrieving a node from the verification queue, reading the pre-stored set of access constraints for the node, and verifying whether the first sub-account meets all the conditions of the set of access constraints; if the verification passes, determining whether the verification queue is empty; if not empty, returning to continue verifying the next node; if the verification fails, terminating the verification and denying the access request; when the verification queue is empty and all verified nodes have passed, the first sub-account is allowed to access the new node.

[0038] Furthermore, starting from the new node, the parent node is obtained by moving upward along the directed edges of the content lineage graph and added to the verification queue. This includes: starting from the new node, recursively moving upward along a path in the content lineage graph until the root node is reached. After verifying all nodes on the path, the process backtracks to the nearest branch point and continues traversing the next path until the content lineage graph is recursively traversed to obtain the verification queue. The recursion depth of a single access request does not exceed a preset maximum depth.

[0039] Specifically, when the AIGC platform receives an access request for a new node from any sub-account, such as the first sub-account, it obtains the node identifier of the new node. The node identifier is a unique ID of the node. The first sub-account is a secondary account under the main account with independent login credentials and operation permissions. After obtaining the target node identifier, the AIGC platform takes the new node as the starting node and traces upwards along the directed edges of the content lineage graph to all its parent nodes, including direct parent nodes, grandparent nodes, and higher-level nodes up to the root node.

[0040] The tracing process employs a depth-first traversal strategy. Starting from the initial node, it recursively ascends along a path until the root node is reached. After verifying all nodes along that path, it backtracks to the nearest branch point (the node with multiple parent nodes) and continues traversing the next unprocessed path. This process recursively traverses the entire content lineage graph, adding all traversed parent nodes to the verification queue in sequence. To prevent resource exhaustion due to excessive graph depth, the recursion depth of a single access request does not exceed a preset maximum depth, such as 20 levels. This preset maximum depth threshold is defined in the platform configuration file; exceeding this threshold terminates the traversal and returns an error.

[0041] After traversal, a node is retrieved from the queue in the order it was enqueued. The pre-stored set of access constraints for that node is read from the graph database. The identity attribute information of the first sub-account, such as role, department, credit score, and tags, is compared item by item with each permission rule in the pre-stored set of access constraints for the current node. For enumerated conditions, such as role and department, it is checked whether the corresponding attribute value of the first sub-account belongs to the set of allowed values. For numerical conditions, such as credit score, it is checked whether the sub-account attribute value satisfies the comparison operator. For logical combination conditions, such as "role=administrator OR department=core group", Boolean evaluation is performed using the expression engine. The first node is considered to have passed the verification only if the first sub-account meets the requirements in all constraint dimensions. If the current node passes the verification, it is checked whether the queue is empty. If it is not empty, the next node is retrieved for verification. If any dimension does not meet the permission rules in the access constraint set, the verification fails, the entire verification process is terminated, and the access request is rejected. Once all nodes in the queue have been retrieved and all have passed the verification, the first sub-account is allowed to access the new node.

[0042] By verifying each node of the entire lineage, it is ensured that when any sub-account accesses content from a new node, it must simultaneously meet the permission requirements of all the content's creators. This avoids illegal access paths that circumvent upstream permission constraints through multi-level nesting, achieving security and reliability from single-point permission checks to complete creation chain permission verification.

[0043] The content lineage graph is read at a preset period, and the comprehensive contribution score is calculated based on the frequency of the content generated by each sub-account being referenced by subsequent nodes, the retention rate in the final product, and the degree of cross-role group propagation.

[0044] Furthermore, the content lineage graph is read at a preset period, and a comprehensive contribution score is calculated based on the frequency of the content generated by each sub-account being referenced by subsequent nodes, the retention rate in the final product, and the degree of cross-role group propagation. This includes: reading the full data of the content lineage graph at a preset period, traversing all nodes and edge relationships, and for each sub-account, counting the total number of times each node in the generated node set is set as a parent node by other nodes within the preset period, which is recorded as the direct reuse contribution value; identifying the set of nodes marked as the final product in the content lineage graph, obtaining the complete set of parent nodes for each finished product node, and calculating the retention contribution value of each sub-account in all finished product nodes; counting the number of times the content generated by each sub-account is accessed and regenerated by members of role groups other than its own account, which is recorded as the cross-domain propagation contribution value; and weighting the direct reuse contribution value, the retention contribution value, and the cross-domain propagation contribution value to generate a comprehensive contribution score for each sub-account.

[0045] Furthermore, the expression for calculating the retention contribution value of each sub-account across all finished product nodes is as follows: ;in, The retention contribution value for sub-account X; The set of nodes that are marked as the final product; To be included in Finished product nodes in the process; For finished product nodes The set of all parent nodes; To generate a set of nodes; This indicates the number of elements in the set.

[0046] Furthermore, starting from the finished node p, recursively traverse along the reverse direction of the directed edges in the content lineage graph until the root node, and denote the set of all nodes on the traversal path as A(p).

[0047] Specifically, the entire content lineage graph data is read at a preset period. This preset period can be configured according to the AIGC platform's operational strategy, such as performing a full calculation every 24 hours or every 7 days. The entire data, including all node records and all directed edge records, is read from the node and edge tables of the content lineage graph storage system, such as Neo4j graph database or a relational database. Based on the entire data, all nodes and edge relationships are traversed, and a three-dimensional contribution value is calculated for each sub-account within the AIGC platform: For each sub-account X, the set of all nodes generated by that sub-account is selected from the entire data, denoted as V. X This refers to the set of nodes that generate sub-account X. Then, iterate through V. X For each node in the table, count the total number of times that node is referenced by other nodes as parent nodes within the preset period, such as the last 24 hours. This can be obtained by querying the number of records in the edge table where the target node ID is equal to the current node ID and the reference timestamp falls within the preset period. Sum the reference counts of all nodes to obtain the direct reuse contribution value R of sub-account X. X The direct reuse contribution value reflects the frequency with which content generated by sub-accounts is used by subsequent creators; the higher the value, the greater the basic reuse value of the content.

[0048] The set P of nodes marked as final products in the content lineage graph is identified. Final products refer to content nodes on the AIGC platform that have reached the published, delivered, or archived state, typically marked by manual review or automatically triggered by project process status. For each finished node p in the node set P, a recursive traversal is performed from that finished node along the reverse direction of the directed edges in the content lineage graph, i.e., from child nodes to parent nodes, until the root node. The set of all nodes traversed along the traversal path is denoted as A(p), which is the set of all ancestor nodes of that finished node, including the direct parent node, grandparent node, and all nodes above that level. For each sub-account X, its retention contribution value among all finished nodes is calculated using the following formula: ,in, The retention contribution value for sub-account X. The set of nodes marked as the final product. To be included in Finished product nodes in the process, For finished product nodes The set of all parent nodes To generate a set of nodes, The numerator represents the number of elements in the set. This represents the number of content nodes generated by sub-account X among all ancestor nodes of finished product node p, i.e., the number of elements in the set. The ratio of the numerator to the denominator reflects the content proportion of sub-account X in a certain finished product. The retention contribution value of the sub-account is obtained by summing the proportions of all finished product nodes. The higher the retention contribution value, the greater the retention ratio of the content of the sub-account in the final output, indicating that its contribution plays a more decisive role in the final result.

[0049] At the same time, for each sub-account X, the content it generates is counted, i.e., V. X The number of times a node in the dataset is accessed and regenerated by members of a role group other than its own account within the preset period. First, the role group affiliation of sub-account X is obtained, such as photography group, copywriting group, design group, etc., and then V is traversed. X For each node, the edge table records are used to filter out all downstream child nodes that reference that node and whose reference time is within a preset period. For each downstream child node, the role group of its generator is queried. If it is different from the role group of X, it is counted as one cross-role group propagation. All nodes and all downstream references are summed to obtain the cross-domain propagation contribution value C of sub-account X. X Cross-domain dissemination contribution value reflects the account's ability to break through its own team boundaries, be adopted and recreated by members of other professional fields, and demonstrate the cross-team influence and integration value of the content.

[0050] After completing the statistics across the three dimensions, the contribution value R to direct reuse was determined. X Retention contribution value L X And cross-domain propagation contribution value CX After performing max-min normalization, a weighted calculation is performed to generate the comprehensive contribution score S for each sub-account. X S X α·R X +β·L X +γ·C X α, β, and γ are preset weighting coefficients, such as 0.3, 0.4, and 0.3 respectively. They can be dynamically adjusted according to business needs and can be set by the platform administrator in the configuration center.

[0051] By quantifying the creative behavior of sub-accounts into three calculable indicators and weighting and integrating them, an objective and dynamic assessment of the actual value of each account in the collaborative creation ecosystem can be achieved. This provides a data-driven decision-making basis for the automated adjustment of subsequent permission seed status, so that the permission system no longer relies on static roles or manual ratings, but rather on adaptive rewards and punishments based on users' real contributions, thereby improving the fairness and accuracy of permission allocation.

[0052] The permission seed status of the sub-account is dynamically adjusted based on the comprehensive contribution score. When the sub-account initiates content generation again, the sub-account carrying the permission seed status is used as the generator to enforce access constraints.

[0053] Furthermore, the permission seed status of the sub-account is dynamically adjusted based on the comprehensive contribution score. When the sub-account initiates content generation again, the sub-account carrying the permission seed status is used as the generator to enforce access constraints, including: the permission seed status includes at least a permission exemption enabled state and a secondary approval required flag state; wherein, when the comprehensive contribution score is higher than the first preset threshold for M consecutive periods, permission exemption is enabled for the corresponding sub-account; when the comprehensive contribution score is lower than the second preset threshold for M consecutive periods, a secondary approval required flag is added for the corresponding sub-account, and the first preset threshold is greater than the second preset threshold.

[0054] Specifically, the system reads the overall contribution score of all sub-accounts and extracts the historical overall contribution score sequence for each sub-account from the historical contribution record table. Based on the current overall contribution scores and historical overall contribution score sequences of all sub-accounts, the permission seed status of the sub-accounts is dynamically adjusted. The permission seed status includes at least two states: permission exemption enabled and secondary approval required. Permission exemption enabled means that when the sub-account generates new content, it is authorized to ignore one or more specified dimensions in the intersection of parent node constraints when calculating the initial access constraints of the new node, thus relaxing the permission restrictions of the new node compared to a strict intersection. Secondary approval required means that when the sub-account attempts to access content nodes with a value exceeding a second preset threshold, an approval task needs to be generated and can only continue execution after manual approval by the administrator. The system determines whether the overall contribution score is consistently higher than a first preset threshold for M consecutive periods. M is a stability parameter preset by the AIGC platform; for example, M=3 indicates that 3 statistical periods need to be observed. The first preset threshold is set by the platform administrator in the configuration center based on business expectations and represents the quantitative standard for high contribution, such as 0.8. If the overall contribution score is higher than the first preset threshold for M consecutive periods, the permission exemption permission for the corresponding sub-account is set to enabled, and the secondary approval requirement mark for that account is automatically cleared. If the overall contribution score is lower than the second preset threshold for M consecutive periods, the secondary approval requirement mark for the corresponding sub-account is set to enabled, and its permission exemption permission is automatically cleared. The second preset threshold is also configured by the administrator and represents the quantitative standard for low contribution, such as 0.3. The first preset threshold is greater than the second preset threshold. If the overall contribution score fluctuates between the first and second preset thresholds or within the overall contribution score sequence, the current permission seed state remains unchanged, and no adjustments are made.

[0055] When a sub-account initiates a new content generation task, the AIGC platform first loads the sub-account's current permission seed status and determines whether it includes a permission exemption enabled state or a secondary approval required state. If the permission exemption enabled state is included, the sub-account is allowed to specify the exemption dimension through request parameters when generating a new node. The restrictions on the exempted dimension are ignored in the intersection calculation of access constraints, making the initial access constraints of the new node more open than a strict intersection. If the secondary approval required state is included, when the sub-account requests access to a node whose value assessment value exceeds the second preset threshold, a secondary approval by the administrator is triggered. Only after approval can the request be released. Regardless of which permission status logic is triggered, the newly generated content node is written into the content lineage graph according to the aforementioned steps and the access constraints are re-executed, forming a closed-loop iteration. This ensures that the permission seed status continues to affect subsequent creation behaviors and dynamically evolves with changes in contribution.

[0056] By dynamically converting comprehensive contribution scores into permission seed states such as permission exemption rights or secondary approval markers, and applying them to the subsequent content generation and access of sub-accounts, intelligent collaboration between account permissions and actual user contributions is achieved. This allows high-contribution accounts to have greater freedom and efficiency in creation, while low-contribution accounts receive additional supervision and reduced security risks when accessing sensitive content. Furthermore, permission status is periodically and adaptively adjusted according to contribution, so account permissions are no longer statically fixed but are linked in real time with the user's behavior in the collaborative ecosystem. This achieves adaptive collaborative management of account permissions, ensuring that the secure inheritance relationship of the entire content lifecycle of the AIGC platform is not disrupted, and also realizing dynamic matching of permission allocation with user value.

[0057] Example 2, based on the same inventive concept as the intelligent collaborative management method for account permissions on the AIGC platform in the previous examples, such as... Figure 2 As shown, this application provides an intelligent collaborative management system for account permissions on an AIGC platform, wherein the intelligent collaborative management system for account permissions on an AIGC platform includes: The content lineage graph writing module 11 is used to respond to the content generation task initiated by the sub-account, using the generated content as a new node, recording the generator and the referenced upstream content as parent nodes, and writing it into the content lineage graph; the constraint determination module 12 is used to read the access constraints of the parent nodes, calculate the intersection of the access constraints, use the intersection as the initial access constraints of the new node, and bind and store it; the constraint verification module 13 is used to respond to any sub-account's access request to the new node, trace all parent nodes upwards along the content lineage graph and verify whether the sub-account meets the access constraints of each parent node one by one, and refuse access if any parent node fails the verification; the contribution calculation module 14 is used to read the content lineage graph at a preset period, calculate the comprehensive contribution score based on the frequency of the content generated by each sub-account being referenced by subsequent nodes, the retention ratio in the final product, and the degree of cross-role group propagation; the account adjustment module 15 is used to dynamically adjust the permission seed state of the sub-account according to the comprehensive contribution score, and when the sub-account initiates content generation again, the sub-account carrying the permission seed state is used as the generator to execute the access constraints.

[0058] Furthermore, the graph writing module 11 is also used for: the sub-account initiating a content generation request through the AIGC platform's creation interface, the request including the prompt text used in this generation, the selected AI model identifier, and one or more upstream content IDs referenced; when the content generation request is completed, the generated content entity is used as a new node, the generator sub-account ID and generation timestamp are used as node attributes, and the upstream content ID is used as the parent node pointer to construct a node data structure; the node data structure is written into the content lineage graph, each node in the content lineage graph includes a unique node identifier, a generator identifier, a generation timestamp, and a content storage address, and each edge records the reference relationship between the child node and the parent node and the reference time; after successful writing, a node writing completion event is sent to the permission self-organizing propagation module, the event payload including the unique identifier of the new node and all parent node IDs.

[0059] Furthermore, the graph writing module 11 is also used to: the content lineage graph adopts a directed acyclic graph structure, and when writing a new node, perform cycle detection: starting from the new node, traverse along the directed edge towards the root node. If the ID of the new node itself is encountered during the traversal, it is determined that there is a closed loop reference, the writing is rejected and an error message is returned.

[0060] Furthermore, the constraint verification module 13 is also used to: receive an access request from the first sub-account to the new node, and obtain the node identifier of the new node; starting from the new node, obtain the parent node along the directed edge of the content lineage graph, and add the parent node to the verification queue; take a node from the verification queue, read the pre-stored access constraint set of the node, and verify whether the first sub-account meets all the conditions of the access constraint set; if the verification passes, determine whether the verification queue is empty, and if it is not empty, return to continue verifying the next node; if the verification fails, terminate the verification and reject the access request; when the verification queue is empty and all verified nodes have passed, allow the first sub-account to access the new node.

[0061] Furthermore, the constraint verification module 13 is also used to: start from the new node, recursively traverse the content lineage graph upwards along a path until the root node is reached, and after verifying all nodes on the path, backtrack to the nearest fork point to continue traversing the next path until the content lineage graph is recursively traversed to obtain the queue to be verified; wherein, the recursion depth of a single access request does not exceed the preset maximum depth.

[0062] Furthermore, the contribution calculation module 14 is also used to: read the full data of the content lineage graph at a preset period, traverse all nodes and edge relationships, and for each sub-account, count the total number of times each node in the generated node set is set as a parent node by other nodes within the preset period, and record it as the direct reuse contribution value; identify the set of nodes marked as final products in the content lineage graph, obtain the full set of parent nodes for each finished product node, and calculate the retention contribution value of each sub-account in all finished product nodes; count the number of times the content generated by each sub-account is accessed and regenerated by members of role groups other than its own account, and record it as the cross-domain propagation contribution value; and perform weighted calculation on the direct reuse contribution value, the retention contribution value, and the cross-domain propagation contribution value to generate a comprehensive contribution score corresponding to each sub-account.

[0063] Furthermore, the contribution calculation module 14 is also used to: calculate the retention contribution value of each sub-account in all finished product nodes using the following expression: ;in, The retention contribution value for sub-account X; The set of nodes that are marked as the final product; To be included in Finished product nodes in the process; For finished product nodes The set of all parent nodes; To generate a set of nodes; This indicates the number of elements in the set.

[0064] Furthermore, the contribution calculation module 14 is also used to: start from the finished product node p, recursively traverse along the reverse direction of the directed edge in the content lineage graph until the root node, and denote the set of all nodes on the traversal path as A(p).

[0065] Furthermore, the account adjustment module 15 is also used for: the permission seed state includes at least the permission exemption enabled state and the secondary approval required mark state; wherein, when the comprehensive contribution score is higher than the first preset threshold for M consecutive periods, permission exemption is enabled for the corresponding sub-account; when the comprehensive contribution score is lower than the second preset threshold for M consecutive periods, a secondary approval required mark is added for the corresponding sub-account, and the first preset threshold is greater than the second preset threshold.

[0066] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The intelligent collaborative management method and specific examples of account permissions for the AIGC platform in the aforementioned embodiment one are also applicable to the intelligent collaborative management system of account permissions for the AIGC platform in this embodiment. Through the foregoing detailed description of the intelligent collaborative management method of account permissions for the AIGC platform, those skilled in the art can clearly understand the intelligent collaborative management system of account permissions for the AIGC platform in this embodiment. Therefore, for the sake of brevity, it will not be described in detail here.

[0067] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0068] Obviously, those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for intelligent collaborative management of account permissions for AIGC platforms, characterized in that, include: In response to content generation tasks initiated by sub-accounts, the generated content is used as a new node, and the generator and the upstream content it references are recorded as parent nodes and written into the content lineage graph. Read the access constraints of the parent node, calculate the intersection of the access constraints, and use the intersection as the initial access constraints of the new node and bind and store it. In response to any sub-account's access request to the new node, trace all parent nodes upwards along the content lineage graph and verify whether the sub-account meets the access constraints of each parent node. If any parent node fails the verification, access is denied. The content lineage graph is read at a preset period, and the comprehensive contribution score is calculated based on the frequency of the content generated by each sub-account being referenced by subsequent nodes, the retention rate in the final product, and the degree of cross-role group propagation. The permission seed status of the sub-account is dynamically adjusted based on the comprehensive contribution score. When the sub-account initiates content generation again, the sub-account carrying the permission seed status is used as the generator to enforce access constraints.

2. The intelligent collaborative management method for account permissions on an AIGC platform as described in claim 1, characterized in that, In response to content generation tasks initiated by sub-accounts, the generated content is used as a new node, and the generator and its referenced upstream content are recorded as parent nodes, which are then written into the content lineage graph, including: Sub-accounts initiate content generation requests through the AIGC platform's creation interface. The requests include the prompt text used in this generation, the selected AI model identifier, and one or more upstream content IDs referenced. Once the content generation request response is completed, the generated content entity is used as a new node, the generator sub-account ID and generation timestamp are used as node attributes, and the upstream content ID is used as the parent node pointer to construct the node data structure. The node data structure is written into the content lineage graph. Each node in the content lineage graph contains a unique node identifier, a generator identifier, a generation timestamp, and a content storage address. Each edge records the reference relationship between the child node and the parent node and the reference time. After successful writing, a node write completion event is sent to the permission self-organizing propagation module. The event payload contains the unique identifier of the new node and the IDs of all parent nodes.

3. The intelligent collaborative management method for account permissions on an AIGC platform as described in claim 2, characterized in that, The kinship graph described uses a directed acyclic graph structure, and cycle detection is performed when a new node is written. Starting from the new node, traverse along the directed edge towards the root node. If the ID of the new node itself is encountered during the traversal, it is determined that a closed reference exists, the write is refused, and an error message is returned.

4. The intelligent collaborative management method for account permissions on an AIGC platform as described in claim 1, characterized in that, In response to any sub-account's access request to the new node, trace all parent nodes upwards along the content lineage graph and verify whether the sub-account meets the access constraints of each parent node. If any parent node fails verification, access is denied, including: Receive the access request from the first sub-account to the new node, and obtain the node identifier of the new node; Starting from the new node, obtain the parent node by moving upward along the directed edge of the content lineage graph, and add the parent node to the queue to be verified. Take a node from the queue to be verified, read the pre-stored access constraint set of the node, and verify whether the first sub-account meets all the conditions of the access constraint set. If the verification passes, then determine whether the queue to be verified is empty. If it is not empty, return to continue verifying the next node. If the verification fails, the verification is terminated and the access request is rejected. When the queue to be verified is empty and all verified nodes have passed, the first sub-account is allowed to access the new node.

5. The intelligent collaborative management method for account permissions on an AIGC platform as described in claim 4, characterized in that, Starting from the new node, obtain the parent node by moving upwards along the directed edges of the content lineage graph, and add the parent node to the queue to be verified, including: Starting from the new node, the content lineage graph is recursively traversed upwards along a path until the root node is reached. After verifying all nodes on the path, the process backtracks to the nearest branch point and continues to traverse the next path until the content lineage graph is recursively traversed to obtain the queue to be verified. The recursion depth of a single access request shall not exceed the preset maximum depth.

6. The intelligent collaborative management method for account permissions on an AIGC platform as described in claim 1, characterized in that, The content lineage graph is read at preset intervals, and a comprehensive contribution score is calculated based on the frequency of references to subsequent nodes of content generated by each sub-account, the retention rate in the final product, and the degree of cross-role group propagation, including: Read the full data of the bloodline graph at a preset period, traverse all nodes and edge relationships, and for each sub-account, count the total number of times each node in the generated node set is set as the parent node by other nodes within the preset period, and record it as the direct reuse contribution value. Identify the set of nodes marked as final products in the content lineage graph, obtain the set of all parent nodes for each finished product node, and calculate the retention contribution value of each sub-account in all finished product nodes; The number of times that content generated by each sub-account is accessed and regenerated by members of roles other than the sub-account itself is counted and recorded as the cross-domain propagation contribution value. The direct reuse contribution value, the retention contribution value, and the cross-domain propagation contribution value are weighted and calculated to generate a comprehensive contribution score for each sub-account.

7. The intelligent collaborative management method for account permissions on an AIGC platform as described in claim 6, characterized in that, The expression for calculating the retention contribution value of each sub-account across all finished product nodes is as follows: ； in, The retention contribution value for sub-account X; The set of nodes that are marked as the final product; To be included in Finished product nodes in the process; For finished product nodes The set of all parent nodes; To generate a set of nodes; This indicates the number of elements in the set.

8. The intelligent collaborative management method for account permissions on an AIGC platform as described in claim 7, characterized in that, Starting from the finished node p, recursively traverse along the reverse direction of the directed edges in the bloodline graph until the root node, and denote the set of all nodes on the traversal path as A(p).

9. The intelligent collaborative management method for account permissions on an AIGC platform as described in claim 1, characterized in that, The permission seed status of sub-accounts is dynamically adjusted based on the comprehensive contribution score. When a sub-account initiates content generation again, access constraints are enforced using the sub-account carrying the aforementioned permission seed status as the generator, including: The permission seed status includes at least the permission exemption permission enabled status and the secondary approval required status; Specifically, when the comprehensive contribution score is higher than the first preset threshold for M consecutive periods, the permission exemption right is enabled for the corresponding sub-account; when the comprehensive contribution score is lower than the second preset threshold for M consecutive periods, a mark requiring secondary approval is added to the corresponding sub-account, and the first preset threshold is greater than the second preset threshold.

10. An intelligent collaborative management system for account permissions on an AIGC platform, characterized in that: The steps for implementing the intelligent collaborative management method for account permissions on an AIGC platform according to any one of claims 1 to 9, wherein the intelligent collaborative management system for account permissions on an AIGC platform comprises: The graph writing module is used to respond to content generation tasks initiated by sub-accounts. It uses the generated content as a new node, records the generator and the upstream content it references as the parent node, and writes it into the content lineage graph. The constraint determination module is used to read the access constraints of the parent node, calculate the intersection of the access constraints, and use the intersection as the initial access constraints of the new node and bind and store it. The constraint verification module is used to respond to any sub-account's access request to the new node by tracing all parent nodes upwards along the content lineage graph and verifying whether the sub-account meets the access constraints of each parent node. If the verification of any parent node fails, access is denied. The contribution calculation module is used to read the content lineage map at a preset period and calculate the comprehensive contribution score based on the frequency of the content generated by each sub-account being referenced by subsequent nodes, the retention ratio in the final product, and the degree of cross-role group propagation. The account adjustment module is used to dynamically adjust the permission seed status of sub-accounts based on the comprehensive contribution score. When a sub-account initiates content generation again, the sub-account carrying the permission seed status is used as the generator to enforce access constraints.

Images