Data security sharing method and system responding to privacy protection needs of interest community

Abstract

This invention belongs to the field of data security sharing technology and discloses a data security sharing method and system that responds to the privacy protection needs of interest-based communities. It includes: parsing multi-source social data in interest-based communities to construct a privacy sharing relationship graph composed of privacy objects, sharing participants, and their relationships; determining privacy protection needs based on privacy sensitivity and sharing constraints, and generating protection tendency parameters by combining historical sharing records; mapping the sharing actions to be executed to the privacy sharing relationship graph to perform relationship response deduction and obtain action response information; determining the exposure state increment of privacy objects based on the action response information, and determining exposure mismatch parameters by combining the protection tendency parameters; generating a secure sharing scheme based on the exposure mismatch parameters and secure sharing rules, and updating the privacy sharing relationship graph and secure sharing rules according to the sharing execution results. This invention can improve the security, adaptability, and controllability of data sharing in interest-based community scenarios.

Description

Technical Field

[0001] This invention belongs to the field of data security sharing technology, and in particular relates to a data security sharing method and system that responds to the privacy protection needs of interest communities. Background Technology

[0002] With the continuous development of social networks and online interest communities, users have formed relatively stable data interaction relationships within platforms around common topics, hobbies, or activities. User posts, interaction records, access behaviors, and sharing operations within interest communities continuously accumulate into multi-source heterogeneous data, which is frequently accessed and shared in scenarios such as community collaboration, content dissemination, and resource exchange. Simultaneously, the expansion of social network users and the surge in user-generated content have made the leakage of sensitive information, misuse of identity profiles, and privacy breach risk assessment important issues in data governance. Several technical approaches have been developed to address social network data security and privacy protection. For example, some technologies focus on identifying private entities in user profiles and text content and further conducting privacy breach risk assessments; others focus on quantifying risks by combining user privacy preferences and the degree of privacy breach; still others focus on perturbing, anonymizing, or differentially privacy-enhancing social network graph data to reduce the risk of direct exploitation of node relationships, edge relationships, and edge weight information. Related research indicates that privacy risks in social networks come not only from explicit content itself, but also from relationship structure, edge weight information, and the strength of relationships, frequency of interactions, and social patterns reflected in association paths.

[0003] Furthermore, in the context of social media and cross-platform information dissemination, existing research has begun to analyze the information dissemination process from multiple elements such as subjects, content, and events. It also uses methods such as relationship networks, path analysis, node identification, and situational assessment to understand the diffusion and evolution patterns of information in complex social environments. This indicates that in actual community environments, data sharing behavior often does not occur in isolation, but is jointly influenced by the relationships between participants, historical interaction patterns, access paths, and subsequent dissemination processes.

[0004] However, existing technologies still have certain limitations when applied to data security sharing scenarios within interest-based communities. Some technologies focus more on static privacy entity identification or outcome-based risk assessment, with less emphasis on linking analysis of participant relationships and potential exposure paths in conjunction with specific sharing requests; while some technologies consider graph structure or edge protection, they lean more towards data publishing or anonymization, making it difficult to directly adapt to fine-grained control over specific sharing actions within the community; still others primarily use preset permissions or fixed rules for sharing management, failing to adequately consider changes in relationships before and after sharing, changes in inferred risks, and dynamic adjustments to rules. Therefore, in interest-based community scenarios, how to conduct more refined analysis and control of privacy objects, sharing participants, and their relationships while balancing data sharing needs still requires further research. Summary of the Invention

[0005] To address the shortcomings of existing technologies in the dynamic control of privacy risk identification and sharing in interest-based community data sharing scenarios, this invention provides a data security sharing method and system that responds to the privacy protection needs of interest-based communities, thereby improving the targeting, dynamism, and security of privacy protection while taking into account the data sharing needs within interest-based communities.

[0006] To achieve the above objectives, this invention provides a data security sharing method in response to the privacy protection needs of interest-based communities, comprising: parsing social multi-source data in the interest-based community, identifying the privacy object corresponding to the sharing request and the sharing participants as graph nodes, and the relationships between the graph nodes as relation edges, and constructing a privacy sharing relation graph; determining the privacy protection needs corresponding to the sharing request based on the privacy sensitivity of the privacy object and the sharing constraint requirements; determining the protection tendency parameter characterizing the protection strength of the target of the sharing request based on the privacy protection needs and historical sharing records; mapping the sharing action to be executed to the privacy sharing relation graph, performing relation response deduction on the affected graph nodes and relation edges, and generating action response information characterizing the changes in reachable states between nodes and the inferred states of privacy objects; determining the exposure state increment of privacy objects in the privacy sharing relation graph before and after the sharing action mapping based on the action response information; determining the exposure mismatch parameter based on the degree of mismatch between the exposure state increment and the protection tendency parameter; generating a secure sharing scheme based on the exposure mismatch parameter and in combination with secure sharing rules, and executing data sharing control according to the secure sharing scheme; and updating the privacy sharing relation graph and secure sharing rules according to the sharing execution results.

[0007] As a further improvement to the above scheme, the construction of the privacy-sharing relationship graph includes: performing privacy entity identification and sharing participant parsing on social multi-source data to obtain privacy objects and sharing participants; extracting the attribution relationship, interaction relationship, sharing relationship and access relationship between privacy objects and sharing participants; and constructing the privacy-sharing relationship graph using privacy objects and sharing participants as graph nodes and attribution relationship, interaction relationship, sharing relationship and access relationship as relationship edges.

[0008] As a further improvement to the above scheme, the relationship edges in the privacy sharing relationship graph have corresponding association strengths. The association strength is determined based on the historical interaction records, historical sharing records, access records, and co-occurrence results of privacy entities between privacy objects and sharing participants, and the association strength is marked on the corresponding relationship edge.

[0009] As a further improvement to the above scheme, the process of determining the protection tendency parameter includes: determining the corresponding privacy sensitivity level based on the privacy object category involved in the sharing request; determining the sharing constraint requirements based on the receiving scope, sharing conditions, and sharing method of the sharing participants; combining and mapping the privacy sensitivity level and sharing constraint requirements according to the preset requirement mapping rules to generate privacy protection requirements; extracting the historical sharing control results corresponding to the current sharing request from the historical sharing records; and determining the protection tendency parameter based on the privacy protection requirements and the historical sharing control results.

[0010] As a further improvement to the above scheme, the process of generating the action response information includes: determining the source graph node, target graph node, and relation edges connecting the source graph node and the target graph node in the privacy sharing relationship graph; identifying the graph nodes and relation edges affected by the shared action to be executed based on the association strength of the relation edges, and constructing the corresponding affected relation subgraph; performing reachability deduction on the graph node connectivity before and after the shared action to be executed in the affected relation subgraph, determining the changes in the set of reachable nodes and the set of reachable paths, and obtaining the reachability state change information between nodes; and deducing the privacy object association inference relationship before and after the shared action to be executed based on the changes in the set of reachable nodes and the set of reachable paths, determining the changes in the set of privacy objects that can be inferred and the privacy object inference path, and obtaining the privacy object inference state change information.

[0011] As a further improvement to the above scheme, the process of determining the exposure state increment includes: determining the increment of shared participants and the increment of reachable paths before and after the shared action mapping based on the reachability state change information between nodes; determining the number of newly inferred privacy objects and the increment of inference paths before and after the shared action mapping based on the privacy object inference state change information; and summarizing the increment of shared participants, the increment of reachable paths, the number of newly inferred privacy objects, and the increment of inference paths to obtain the exposure state increment of the privacy object.

[0012] As a further improvement to the above scheme, the process of determining the exposure mismatch parameter includes: normalizing the exposure state increment and protection tendency parameter to obtain the exposure intensity value and the target protection intensity value, respectively; determining the degree of matching deviation based on the difference between the exposure intensity value and the target protection intensity value; and mapping the degree of matching deviation to the corresponding exposure mismatch parameter according to the interval in which the degree of matching deviation is located, based on the preset mismatch classification rules.

[0013] As a further improvement to the above scheme, the generation process of the secure sharing scheme includes: determining the corresponding mismatch level based on the exposure mismatch parameters; matching the secure sharing rules corresponding to the mismatch level from a preset secure sharing rule set; determining at least one control item among the shared content form, the scope of shared participants, the access validity conditions, and the sharing verification method based on the matched secure sharing rules; and generating a secure sharing scheme based on the determined control items.

[0014] As a further improvement to the above scheme, the update process of the privacy sharing relationship graph and the security sharing rules includes: collecting access logs, verification results, sharing scope change records, and anomaly handling records generated after the execution of data sharing control, and identifying the sharing participants, the privacy objects actually exposed, and the relationship edges that actually take effect based on these records; updating the graph nodes, relationship edges, and association strength in the privacy sharing relationship graph based on the identification results; and correcting the correspondence between the mismatch level and control items in the security sharing rules based on the deviation between the sharing execution results and the security sharing scheme.

[0015] Accordingly, the present invention also provides a data security sharing system that responds to the privacy protection needs of interest communities, comprising: a graph construction module, used to parse social multi-source data in interest communities, determine the privacy object corresponding to the sharing request and the sharing participants as graph nodes, and the relationship between the graph nodes as relationship edges, to construct a privacy sharing relationship graph; a requirement determination module, used to determine the privacy protection requirements corresponding to the sharing request based on the degree of privacy sensitivity and sharing constraints; a tendency determination module, used to determine the protection tendency parameter characterizing the protection strength of the target of the sharing request based on the privacy protection requirements and historical sharing records; and a response inference module, used to map the sharing action to be executed to the privacy... The system comprises four modules: a shared relationship graph, a privacy sharing relationship graph, and an update module. The shared relationship graph performs relationship response deduction on affected graph nodes and relationship edges, generating action response information representing changes in reachable states between nodes and inferred states of privacy objects. A mismatch determination module determines the exposure state increment of privacy objects in the privacy sharing relationship graph before and after the shared action mapping based on the action response information, and determines the exposure mismatch parameter based on the degree of deviation between the exposure state increment and the protection tendency parameter. A control module generates a secure sharing scheme based on the exposure mismatch parameter and combined with secure sharing rules, and executes data sharing control according to the secure sharing scheme. An update module updates the privacy sharing relationship graph and secure sharing rules based on the sharing execution results.

[0016] The beneficial effects of the above solutions provided by this invention are as follows: By constructing a privacy-sharing relationship graph, the sharing actions to be executed are mapped to the graph for relationship response deduction, thereby identifying the node reachability changes and privacy object inference changes caused by the sharing action before the sharing is executed; further, protection tendency parameters are formed by combining privacy protection needs, and the exposure state increment is matched with the protection tendency parameters to form exposure mismatch parameters. The exposure mismatch parameters are used as the basis for generating secure sharing schemes, so that sharing control can simultaneously respond to the community's privacy protection needs and actual sharing risks. In addition, the present invention updates the privacy sharing relationship graph and security sharing rules based on the shared execution results, enabling the data security sharing process to have continuous optimization capabilities, which is conducive to improving the security, adaptability and controllability of data sharing in interest community scenarios. Attached Figure Description

[0017] Figure 1 This is a schematic diagram illustrating the operation of a data security sharing method in one embodiment of the present invention; Figure 2 This is a structural diagram of a data security sharing system according to one embodiment of the present invention. Detailed Implementation

[0018] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments of the present invention.

[0019] To address the issues of privacy object exposure, relationship chain leakage, and inference risks arising from multi-source information association during data sharing within interest-based communities, this embodiment provides a data security sharing processing solution that responds to the privacy protection needs of interest-based communities. By analyzing changes in relationships and privacy object exposure before and after the sharing action, secure sharing control adapted to the current sharing request is achieved.

[0020] In this embodiment, the data security sharing method provided by the present invention in response to the privacy protection needs of interest-based communities, such as... Figure 1 As shown, the method includes: parsing social multi-source data in interest communities, identifying the privacy objects and sharing participants corresponding to the sharing request as graph nodes, and the relationships between the graph nodes as relationship edges, to construct a privacy sharing relationship graph; determining the privacy protection requirements corresponding to the sharing request based on the privacy sensitivity of the privacy objects and the sharing constraint requirements; determining the protection tendency parameter characterizing the protection strength of the sharing request target based on the privacy protection requirements and historical sharing records; mapping the sharing action to be executed to the privacy sharing relationship graph, performing relationship response deduction on the affected graph nodes and relationship edges, and generating action response information characterizing the changes in reachable states between nodes and the inferred states of privacy objects; determining the exposure state increment of privacy objects in the privacy sharing relationship graph before and after the sharing action mapping based on the action response information; determining the exposure mismatch parameter based on the degree of mismatch between the exposure state increment and the protection tendency parameter; generating a secure sharing scheme based on the exposure mismatch parameter and combined with secure sharing rules, and executing data sharing control according to the secure sharing scheme; and updating the privacy sharing relationship graph and secure sharing rules based on the sharing execution results.

[0021] In the above process, social multi-source data can include user profile data, user-generated content data, interaction behavior data, and sharing request data from interest communities. User profile data can include user nicknames, avatars, personal tags, public introductions, and interests; user-generated content data can include post text, comment text, private message snippets, resource description text, and image description information; interaction behavior data can include records of actions such as liking, commenting, forwarding, quoting, saving, accessing, and authorizing; and sharing request data can include the sharing initiator, recipient, sharing object, sharing scope, sharing method, and sharing conditions. When parsing the above data, methods such as text parsing, named entity recognition, attribute field extraction, and object relationship merging can be used to identify privacy objects and sharing participants related to the current sharing request from unstructured or semi-structured data.

[0022] The privacy object can be a sensitive information object involved in the current sharing request, such as identity objects, location objects, relationship objects, experience objects, behavior objects, or data objects that can characterize user privacy features. The sharing participants can be entities involved in the sharing process, such as the sharing initiator, the sharing recipient, the sharing reviewer, and the sharing manager. Further, the privacy object and the sharing participants are treated as graph nodes, and the attribution, interaction, sharing, access, or inference relationships between these nodes are treated as relationship edges, constructing a privacy sharing relationship graph. To enable relationship edges to participate in subsequent response deduction, association strength can be added to the relationship edges during graph construction. This association strength can be determined based on historical interaction frequency, historical sharing records, access records, and the co-occurrence of privacy entities. Weighted social network research shows that edge weights can characterize relationship strength and interaction frequency, and that edge weight information is closely related to relationship exposure risk. Therefore, in this embodiment, the privacy sharing relationship graph is not merely used for static display, but serves as the computational basis for subsequent sharing action mapping and relationship response deduction.

[0023] When determining privacy protection requirements, the level of privacy sensitivity can be determined first based on the category, attribute sensitivity level, identifiability, and inferability of the privacy object. Then, the sharing constraints can be determined by combining the receiving scope, sharing method, sharing conditions, and access timeliness requirements corresponding to the current sharing request. Finally, the privacy sensitivity level and sharing constraints can be combined and mapped to the privacy protection requirements corresponding to the current sharing request according to a preset requirement mapping rule. Here, privacy protection requirements can be understood as the protection level requirements, sharing boundary requirements, and control requirements that the current sharing request should meet in the context of an interest-based community.

[0024] In determining the protection bias parameter, this embodiment does not simply rely on a single risk value, but rather combines current privacy protection needs with historical sharing records to determine the target protection strength for the current sharing request. Specifically, it extracts historical sharing control results corresponding to the current sharing request from historical sharing records, such as the sharing methods used, actual execution scope, control strength, and post-execution deviations of similar historical requests. The protection bias parameter is then determined based on the current privacy protection needs and historical sharing control results. This protection bias parameter characterizes the target protection strength that the system should adopt for the current sharing request.

[0025] In the shared action mapping and relationship response deduction phase, the shared action to be executed is mapped to the privacy-sharing relationship graph. This shared action can be granting access to a specific participating object, distributing content to multiple participating objects, or allowing an object to view or use data under certain timeframes and conditions. During mapping, the source graph node, target graph node, and the relationship edges between them corresponding to the shared action are first located in the graph. Then, based on the association strength of the relationship edges, the graph nodes and relationship edges affected by the shared action are identified, and an affected relationship subgraph is constructed. Subsequently, relationship response deduction is performed in this affected relationship subgraph. Relationship response deduction refers to calculating the possible changes in graph node connectivity and privacy object inferred relationships after mapping before the shared action is executed. Specifically, connectivity analysis or path search can be used to determine the changes in the set of reachable nodes and the set of reachable paths before and after mapping, obtaining information on changes in the reachability status between nodes. Then, based on the changes in the set of reachable nodes and the set of reachable paths, the inferred relationship between privacy objects and other objects is deduced, determining the set of privacy objects that can be inferred and the changes in inferred paths, obtaining information on changes in the privacy object inferred state.

[0026] After obtaining the action response information, the exposure state increment of the privacy object is further determined. In this embodiment, the exposure state increment does not simply refer to the sensitivity of the original content, but rather to the change in the exposure-related state of the privacy object in the privacy sharing relationship graph before and after the shared action mapping. Specifically, the increase in the number of shared participants and the increase in the reachable path to the privacy object before and after the shared action mapping can be determined based on the reachable state change information between nodes; the number of newly inferred privacy objects and the increase in the inference path can be determined based on the inferred state change information of the privacy object before and after the shared action mapping; and the exposure state increment of the privacy object is obtained by summarizing the increase in the number of shared participants, the increase in the reachable path, the number of newly inferred privacy objects, and the increase in the inference path. In this way, the exposure state increment reflects the degree of increase in relationship exposure and inferred exposure brought about by the shared action, rather than making a judgment based solely on a certain text field or a certain static attribute.

[0027] When determining the exposure mismatch parameters, the exposure state increment and protection tendency parameters are normalized to obtain the exposure intensity value and the target protection intensity value. The degree of mismatch deviation is determined based on the difference between the two. Then, according to the preset mismatch classification rules, the degree of mismatch deviation is mapped to the corresponding exposure mismatch parameter according to the interval in which the degree of mismatch deviation falls. Specifically, when the exposure intensity value is higher than the target protection intensity value, it indicates that the exposure risk caused by the shared action under the current relationship structure is higher than the target protection requirement of the current shared request; when the deviation is small or the exposure intensity value is lower than the target protection intensity value, it indicates that the current shared action is relatively well-matched with the current protection requirements.

[0028] When generating a secure sharing scheme, the corresponding mismatch level is first determined based on the exposure mismatch parameter. Then, a secure sharing rule corresponding to the mismatch level is matched from a preset secure sharing rule set. Based on the matched secure sharing rule, at least one control item is determined from among the shared content format, the scope of sharing participants, access validity conditions, and sharing verification methods, ultimately generating the secure sharing scheme. For example, when the exposure mismatch parameter is low, it can be determined that original content sharing is allowed within a limited scope; when the exposure mismatch parameter is high, it can be determined that only digested sharing, anonymized sharing, time-limited access, or enhanced verification methods are allowed. These secure sharing rules can be pre-stored in a rule base, which records the combination of control items corresponding to different mismatch levels. Therefore, the secure sharing scheme is no longer a fixed strategy, but is generated jointly driven by the graph response result caused by the current sharing action, the exposure state increment, and the target protection strength.

[0029] When implementing data sharing controls, the system actually controls sharing behavior according to the secure sharing scheme, such as limiting the scope of sharing, limiting access duration, switching the form of shared content, or adding access verification conditions. After sharing is completed, the privacy sharing relationship graph and secure sharing rules are updated based on the sharing execution results. Specifically, access logs, verification results, sharing scope change records, and anomaly handling records can be collected to identify the sharing participants, the privacy objects actually exposed, and the relationship edges that are actually effective. Based on the identification results, the graph nodes, relationship edges, and association strength in the graph are updated. At the same time, based on the deviation between the sharing execution results and the previously generated secure sharing scheme, the correspondence between mismatch levels and control items in the secure sharing rules is corrected.

[0030] This embodiment can perform relationship response deduction based on the privacy sharing relationship graph before executing data sharing in an interest community. This deduction yields the possible changes in reachability states between nodes and inferred state changes of privacy objects caused by the sharing action. Then, by matching the exposure state increment with protection tendency parameters, it determines the exposure mismatch parameters and generates a secure sharing scheme adapted to current privacy protection needs. Furthermore, through continuous write-back updates of the sharing execution results, this embodiment can gradually optimize the privacy sharing relationship graph and secure sharing rules, thereby enabling dynamic adaptation and continuous optimization capabilities for data sharing processing in interest communities.

[0031] In one embodiment of this invention, applicable to a data security processing environment deployed on an interest-based community platform server, the processing objective is to construct a privacy-sharing relationship graph from multi-source social data that can be used for subsequent sharing control. Specifically, constructing the privacy-sharing relationship graph includes: performing privacy entity identification and sharing participant parsing on multi-source social data to obtain privacy objects and sharing participants; extracting the attribution, interaction, sharing, and access relationships between privacy objects and sharing participants; and constructing the privacy-sharing relationship graph using privacy objects and sharing participants as graph nodes and attribution, interaction, sharing, and access relationships as relationship edges.

[0032] In a specific implementation scenario, social multi-source data can originate from the user center, content center, behavior log center, and sharing control center of an interest-based community platform. Input data may include user profile data, post text, comment text, private message fragments, resource description information, like records, comment records, forwarding records, access records, and sharing request records. This data can be stored and transmitted using JSON, XML, CSV, database table records, or structured message formats in a message queue. User profiles and sharing requests can be directly read from database table records, text content can be obtained from a content database or object storage, and behavior logs can be obtained from a logging system or streaming system.

[0033] The runtime environment can be deployed as a local server or a cloud server environment, typically employing a combined architecture of application server, relational database, graph database, and model inference service. For example, the application server is responsible for receiving sharing requests and scheduling the graph construction process; the relational database stores user information, sharing requests, and behavior logs; the graph database stores graph nodes and relation edges; and the natural language processing service performs privacy entity identification and object parsing. The graph construction process can be executed periodically by the background data processing module or triggered incrementally when a new sharing request is detected.

[0034] First, privacy entity identification and sharing participant parsing are performed on multi-source social data to obtain privacy objects and sharing participants. Specifically, for text data such as post text, comment text, private message fragments, and resource description information, privacy objects can be identified using a combination of word segmentation, part-of-speech tagging, named entity recognition, keyword extraction, and rule matching. Privacy entity identification models can employ common solutions such as Transformer, BERT, BiLSTM-CRF, or rule engines. BERT or other pre-trained language models can be used to extract objects such as names, locations, organizations, times, interest tags, and community identity identifiers. For structured data fields, such as nicknames, regions, contact information tags, interest tags, and group membership records, privacy objects can be directly identified using field parsing and rule mapping. After the above processing, a set of privacy objects can be output, which can be described using fields such as object identifier, object type, source data location, and user identifier. Simultaneously, the system parses the initiator, receiver, reviewer, administrator, and content-related objects in the sharing request to obtain a set of sharing participants. Shared participants can also be described using fields such as object identifier, object role, affiliated circle, and account identifier. This step is typically performed by the entity recognition module and the object parsing module, with the output serving as input for the subsequent relationship extraction module.

[0035] Secondly, the attribution, interaction, sharing, and access relationships between privacy objects and sharing participants are extracted. Specifically, attribution relationships can be extracted based on user profiles, circle joining records, and content publishing attribution records. For example, a privacy object may originate from a user, and a content object may belong to a publisher. Interaction relationships can be extracted based on behavior logs such as likes, comments, replies, private messages, and citations. For example, a sharing participant may have a comment or reply relationship with the content to which a privacy object belongs. Sharing relationships can be extracted based on historical sharing requests, sharing configuration records, and sharing result records. For example, a sharing participant may have received or forwarded data related to a privacy object. Access relationships can be extracted based on access logs, call records, and verification results. For example, a sharing participant may have browsed, downloaded, called, or queried a content object or privacy object. During relationship extraction, primary key associations can be completed first based on object identifiers. Then, multi-source records can be merged based on timestamps, session identifiers, request identifiers, and resource identifiers to ultimately form relationship triples or edge records. Relationship records can be expressed in the form of starting object—relationship type—target object, with attributes such as time, frequency, source table, and confidence level.

[0036] Then, using privacy objects and shared participants as graph nodes, and belonging relationships, interaction relationships, sharing relationships, and access relationships as relationship edges, a privacy-sharing relationship graph is constructed. In specific implementations, a node record can be created for each privacy object and shared participant in a graph database, with node attributes such as object number, object type, object role, affiliated circle, source data table, and creation time written into it. Then, edge records are created based on the relationship records obtained in the previous step, with attributes such as relationship type, establishment time, occurrence frequency, and most recent occurrence time written into them. If a non-graph database is used, an adjacency list, relationship matrix, or key-value pair index structure can also be used to express the graph in a relational database or in-memory computing framework. After the graph is constructed, the output is a privacy-sharing relationship graph data structure. This graph can represent the privacy objects, shared participants, and their relationship links involved in the sharing request, providing basic input for subsequent privacy protection requirement determination, relationship response deduction, and sharing control. At this point, the privacy object set, shared participant set, and relationship records from the previous step have been transformed into a unified graph-based result, which can be used by subsequent processing modules.

[0037] In one example, if a user in an interest-based community requests to share content containing activity photos, descriptions, member nicknames, and location tags with several group members, the system can first identify the nickname, location, and activity objects as privacy objects from the content. It then parses the initiator and recipient from the sharing request as sharing participants. Next, combining historical interaction data, it extracts the attribution relationship between the initiator and the content object, the access relationship between the recipient and the content object, and the interaction relationship between the initiator and the recipient. These objects and relationships are then written into a graph database to form a corresponding privacy sharing relationship graph. Subsequent modules can then perform privacy protection requirement identification and sharing control processing based on this graph.

[0038] Text-based social multi-source data can be input in the form of TXT, JSON, HTML fragments, or long text fields from a database; image description data can come from the attached text information of image files such as JPG, PNG, and BMP, or OCR extraction results; behavior logs can be in the form of CSV, database table records, or streaming log messages; entity recognition models can use Transformer, BiLSTM-CRF, rule engines, or dictionary matching schemes; relationship extraction can use rule matching, primary key association, log merging, and graph database writing mechanisms; the deployment environment can be a local server, a cloud server, or a containerized microservice environment.

[0039] In interest-based community platforms, after the initial construction of the privacy-sharing relationship graph, it is necessary to further characterize the differences in the strength of the relationship edges between graph nodes to reflect the degree of association between different sharing participants and privacy objects in the historical interaction, sharing, and access processes. Based on this, in one embodiment of the present invention, applicable to the graph enhancement processing stage deployed on the interest-based community platform server, the processing objective is to calculate and label the association strength of the relationship edges based on the existing privacy-sharing relationship graph, so as to provide a more refined calculation basis for subsequent sharing action mapping and relationship response deduction. Specifically, the relationship edges in the privacy-sharing relationship graph have corresponding association strengths, which are determined based on the historical interaction records, historical sharing records, access records, and privacy entity co-occurrence results between privacy objects and sharing participants, and the association strength is labeled to the corresponding relationship edge.

[0040] In a specific implementation scenario, after the aforementioned privacy-sharing relationship graph is constructed, further relationship edge enhancement processing can be performed. The input data at this stage mainly includes four categories: first, historical interaction records, such as logs of behaviors like comments, replies, likes, quoting, and private messages; second, historical sharing records, such as historical sharing requests, sharing scope, sharing results, and sharing completion status; third, access records, such as browsing, querying, downloading, calling, and verification success results; and fourth, privacy entity co-occurrence results, such as privacy objects and sharing participants appearing simultaneously in the same post, the same comment chain, the same resource description, or the same session window. The above data can be stored in JSON, CSV, database table records, or log files, and is processed jointly by the log processing module, the relationship calculation module, and the graph maintenance module.

[0041] First, the relationship calculation module reads the start and end nodes corresponding to the relationship edges from the constructed privacy-sharing relationship graph, and then extracts historical data related to the relationship edge from the behavior log library, sharing record library, and access record library. During this process, multi-source records can be merged according to object identifier, request identifier, session identifier, content identifier, and timestamp to obtain the historical interaction subset, historical sharing subset, and access subset corresponding to each relationship edge. Simultaneously, the privacy entity co-occurrence results related to the relationship edge are extracted from the privacy entity identification result table or co-occurrence analysis result table. The output of this step is the original feature set corresponding to the relationship edge, which includes at least interaction frequency, sharing frequency, access frequency, and co-occurrence frequency.

[0042] Next, the association strength is calculated for the original feature set. Specifically, a weighted scoring mechanism, a rule-based scoring mechanism, or a normalized statistical mechanism can be used. For example, interaction frequency, sharing frequency, access frequency, and co-occurrence frequency can be counted separately, and then the statistical results can be standardized to obtain interaction strength sub-values, sharing strength sub-values, access strength sub-values, and co-occurrence strength sub-values. Then, each sub-value is weighted and summarized according to preset weights to generate the association strength value of the current relationship edge. These preset weights can be configured by the rule engine or predetermined based on historical sample statistical results. If the platform wants to prioritize reflecting historical sharing behavior, the weight of the sharing strength sub-value can be increased; if it wants to highlight long-term interaction relationships, the weight of the interaction strength sub-value can be increased. This step is executed by the relationship calculation module, and the output is the association strength value corresponding to each relationship edge.

[0043] Subsequently, the graph maintenance module writes the association strength value into the attribute field of the corresponding relation edge, completing the association strength annotation. If a graph database is used, the association strength can be directly written as an edge attribute; if a relational database or adjacency list is used, an association strength field can be added to the relation record table and updated. After annotation, the privacy-sharing relation graph transforms from the initial node-relation structure into an enhanced graph with association strength attributes. This enhanced graph can continue to flow to subsequent shared action mapping and relation response inference stages to identify which relation edges are more easily activated or amplified under the action of shared actions.

[0044] In one example, if a sharing participant frequently comments on, replies to, and accesses content belonging to a privacy object, and appears repeatedly in multiple sharing records, while also exhibiting a high co-occurrence probability with the privacy object within the same content fragment, the system can assign a high association strength to the relationship edge between the sharing participant and the privacy object. Conversely, if there is only a single, short-lived access with no subsequent interaction or co-occurrence, the association strength of the corresponding relationship edge can be set to a lower value. In this way, the differentiated strength of relationship edges can be explicitly expressed in the graph.

[0045] Historical interaction records, historical sharing records, and access records can be saved in the form of JSON, XML, CSV, database table records, or log files; co-occurrence results of privacy entities can be obtained through co-occurrence statistics, sliding window analysis, rule matching, or graph-based co-occurrence analysis mechanisms; association strength calculation can use common solutions such as weighted scoring, normalized statistics, rule engines, XGBoost, and random forests; relation edge attribute updates can be completed by graph database write services, relation table update services, or graph synchronization services; the deployment environment can be consistent with the aforementioned graph construction and processing environment, and can be implemented using backend processing services on local servers or cloud servers.

[0046] In one embodiment of this invention, the preprocessing stage of the sharing decision-making process applicable to the interest community platform server aims to generate a protection tendency parameter that characterizes the protection strength of the current sharing request's target based on the privacy object category involved in the sharing request, the sharing constraints of the participating objects, and historical sharing control results. After the interest community platform completes the construction of the privacy sharing relationship graph and the labeling of the relationship edge association strength, it is also necessary to quantify the target protection strength corresponding to this sharing based on the sensitivity and constraints of the current sharing request itself, so as to provide a prerequisite input for subsequent relationship response deduction and sharing control. In this embodiment, the process of determining the protection tendency parameter includes: determining the corresponding privacy sensitivity based on the privacy object category involved in the sharing request; determining the sharing constraints based on the receiving scope, sharing conditions, and sharing methods of the participating objects; combining and mapping the privacy sensitivity and sharing constraints according to a preset requirement mapping rule to generate privacy protection requirements; extracting historical sharing control results corresponding to the current sharing request from historical sharing records; and determining the protection tendency parameter based on the privacy protection requirements and historical sharing control results.

[0047] In a specific implementation scenario, after the aforementioned privacy-sharing relationship graph is constructed and the association strength of the relationship edges is labeled, the protection tendency parameter calculation can be further performed. The input data at this point mainly includes: current sharing request data, privacy object data identified in the graph, sharing participant data, and historical sharing record data. Specifically, the current sharing request data may include fields such as sharing object identifier, sharing initiator identifier, sharing recipient identifier, sharing scope, sharing method, sharing duration, and access conditions; privacy object data may include fields such as object identifier, object category, source content identifier, and user identifier; sharing participant data may include fields such as object identifier, object role, affiliated circle, and receiving permission identifier; and historical sharing record data may include fields such as historical sharing request identifier, historical control method, historical sharing scope, historical verification conditions, and historical execution results. The above data can be input in the form of JSON, CSV, database table records, or cached objects, and processed by the requirement identification module and parameter calculation module.

[0048] First, the privacy sensitivity level is determined based on the categories of privacy objects involved in the sharing request. Specifically, the demand identification module extracts the target content identifier or resource identifier from the current sharing request, and then associates it with the privacy object set obtained during the aforementioned graph construction process to identify the categories of privacy objects involved in this sharing, such as identity objects, location objects, relationship objects, behavior objects, or content preference objects. Then, according to a pre-established sensitivity classification table or hierarchical rules, different categories of privacy objects are mapped to corresponding privacy sensitivity levels. For example, identity identifiers and precise location objects can be mapped to high sensitivity, general interest tags to medium sensitivity, and public activity tags to low sensitivity. The output of this step is a privacy sensitivity result set. Each record in the result set can be saved in the form of privacy object identifier—object category—sensitivity value, and used as an input reference for the next step of sharing constraint identification.

[0049] Secondly, the sharing constraints are determined based on the scope of participation, sharing conditions, and sharing methods. Specifically, the requirement identification module reads the scope of participation, sharing conditions, and sharing methods fields from the current sharing request. The scope of participation can be a single object, a specified group, a set of members within a circle, or a set of objects with limited roles. Sharing conditions can be time limits, frequency limits, authentication conditions, or approval conditions. Sharing methods can be full-text sharing, fragment sharing, read-only sharing, download sharing, or forwarding sharing. After parsing these fields, the system generates corresponding sharing constraint results, such as restrictions on receiving within a circle, requiring authentication for access, time-limited access, and prohibiting secondary forwarding. The output of this step is a set of sharing constraint results, which is then passed to the requirement mapping processing stage.

[0050] Then, based on preset requirement mapping rules, the privacy sensitivity level and sharing constraint requirements are combined and mapped to generate privacy protection requirements. Specifically, a requirement mapping rule table can be pre-configured in the rule engine, recording the correspondence between privacy sensitivity level, sharing constraint requirements, and privacy protection requirements. For example, when the privacy sensitivity level is high and the sharing method is forwarding sharing, it can be mapped to a high-level protection requirement; when the privacy sensitivity level is medium and the receiving range is limited to within the trusted circle, it can be mapped to a medium-level protection requirement. During execution, the requirement identification module inputs the privacy sensitivity result set and the sharing constraint requirement result set obtained in the first two steps into the rule engine, and obtains the privacy protection requirements corresponding to this sharing request by matching the rule table. The output of this step can be expressed using fields such as requirement identifier, requirement level, and requirement description, and flows to the subsequent historical sharing record matching step.

[0051] Next, the historical sharing control results corresponding to the current sharing request are extracted from the historical sharing records. Specifically, the parameter calculation module can search for identical or similar historical sharing records in the historical sharing record database based on key attributes such as the privacy object category, sharing method, reception scope, and sharing conditions of the current sharing request. During matching, rule matching, field similarity matching, or tag-based nearest neighbor retrieval methods can be used to filter historical samples corresponding to the current sharing request from the historical records. Subsequently, the historical sharing control results are extracted from these historical samples, such as the historical sharing content format, historical reception scope restrictions, historical access validity conditions, historical verification methods, and final execution deviations. The output of this step is a set of historical sharing control results, which can be stored in a structured record format and used in conjunction with the current privacy protection requirements as input for the next step of parameter determination processing.

[0052] Finally, a protection tendency parameter is determined based on privacy protection requirements and historical sharing control results. Specifically, the parameter calculation module maps the current privacy protection requirements to a base value for the target protection level, and then modifies this value by incorporating control strength information reflected in historical sharing control results, thus forming the protection tendency parameter for the current sharing request. For example, when the current privacy protection requirement is high-level, and similar historical requests generally employ strict access control and enhanced verification methods, a higher protection tendency parameter can be generated; when the current privacy protection requirement is medium-level, and similar historical requests mostly employ limited sharing, a medium protection tendency parameter can be generated. This parameter can be expressed as a numerical parameter, a hierarchical parameter, or a range parameter, and serves as input for subsequent sharing action mapping and exposure state incremental analysis. Thus, the aforementioned privacy protection requirements obtained from privacy object categories and sharing constraints, as well as the historical sharing control results extracted from historical sharing records, are ultimately transformed into a unified target protection strength representation result.

[0053] In one example, if the current sharing request involves user nicknames, member relationship tags, and location tags, and is intended to be shared to multiple objects within a certain interest group for a limited time, the system can first identify identity-based objects, relationship-based objects, and location-based objects, and map their corresponding sensitivity levels. Then, it can form sharing constraints based on request conditions such as multiple object reception, limited-time access, and viewing only without downloading. The system can then generate corresponding privacy protection requirements through requirement mapping rules. Afterward, it can retrieve the control results of similar objects under similar sharing methods in the past. If the historical records generally show that stricter reception scope restrictions and authentication conditions are used, the system will output a higher protection tendency parameter for subsequent processing.

[0054] The current shared request data, privacy object data, shared participant data, and historical shared record data can be organized in the form of JSON, XML, CSV, database table records, or cached objects; the demand mapping rules can be implemented using rule tables, rule engines, decision trees, or configurable mapping files; historical shared record matching can be achieved using field similarity matching, tag matching, nearest neighbor retrieval, or rule retrieval mechanisms; protection tendency parameters can be represented using numerical parameters, discrete level parameters, or interval parameters; and related processing modules can be deployed in the existing backend processing environment of the aforementioned platform server and executed as a pre-parameter generation unit in the shared decision-making process.

[0055] Once the interest-based community platform has completed the construction of its privacy-sharing relationship graph and the edges of the relationships have been assigned association strengths, the system can pre-determine what changes the execution of a specific sharing request will cause in the relationship network. The purpose of this is to advance the sharing judgment from the static object level to the level of changes in graph node connectivity and inferable changes in privacy objects, thus providing direct input for subsequent incremental analysis of exposure states. At this point, the platform is no longer processing just a piece of text or a resource file itself, but rather the possible propagation and inference links that resource may form within the current community relationship structure. Therefore, in one embodiment of the present invention, the process of generating the action response information includes: determining the source graph node, target graph node, and relation edges connecting the source graph node and the target graph node in the privacy sharing relationship graph; identifying the graph nodes and relation edges affected by the shared action to be executed based on the association strength of the relation edges, and constructing the corresponding affected relation subgraph; performing reachability deduction on the graph node connectivity before and after the shared action to be executed in the affected relation subgraph, determining the changes in the set of reachable nodes and the set of reachable paths, and obtaining information on the change in reachability status between nodes; and performing deduction on the privacy object association inference relationship before and after the shared action to be executed based on the changes in the set of reachable nodes and the set of reachable paths, determining the changes in the set of privacy objects that can be inferred and the privacy object inference path, and obtaining information on the change in privacy object inference status.

[0056] In actual processing, action description data can be read from the current sharing request first. This action description data is usually stored in the form of structured records, such as JSON messages, database table records, or cached objects, and includes at least fields such as action identifier, action type, sharing initiator identifier, sharing receiver identifier, sharing resource identifier, execution conditions, and timestamp. This is accompanied by a privacy-sharing relationship graph generated from the preceding process. This graph can be stored in a graph database or temporarily stored in the computing service as an adjacency list or in-memory graph object. Each relationship edge in the graph has an associated strength attribute, facilitating subsequent filtering of the scope of influence.

[0057] Upon receiving a sharing action to be executed, the system does not immediately perform the sharing. Instead, the sharing action mapping processing unit locates the corresponding nodes and edges in the graph. If the action involves the initiating object granting viewing access to a resource to the receiving object, the initiating object node can be considered the source graph node, and the receiving object node can be considered the target graph node. Edges related to these two nodes in resource ownership, sharing, access, or interaction relationships can be considered candidate relationship edges. Location can be performed using index retrieval based on object and resource identifiers, or by querying node attributes and edge relationships in the graph database. The output includes a set of source graph nodes, a set of target graph nodes, and a set of candidate relationship edges.

[0058] After obtaining candidate relation edges, instead of including the entire graph in subsequent calculations, the correlation strength of the relation edges is used to identify the local structures truly affected by the current shared action. Specifically, a combination of threshold filtering and neighborhood expansion can be used: first, relation edges directly connected to source and target graph nodes with correlation strength meeting preset conditions are selected as the first layer of affected edges. Then, these edges are expanded to adjacent nodes to identify the second layer of affected edges that satisfy path extension rules. This yields a set of affected graph nodes and a set of relation edges, and an affected relation subgraph is constructed using these nodes and edges. This affected relation subgraph can be understood as a local computational view of the current shared action, preserving the relational structure highly related to the action while avoiding invalid calculations caused by performing inferences on the entire large graph.

[0059] After the affected subgraph is established, the system begins reachability inference. The "before and after" mapping here does not mean the base graph has been actually rewritten, but rather that the original affected subgraph is used as the pre-mapping state, and the shared actions to be performed are injected into this subgraph via virtual connections to form the post-mapping response subgraph. Subsequently, the relationship inference unit can perform connectivity analysis on both the pre-mapping and post-mapping response subgraphs. This analysis can be implemented using common graph algorithms such as breadth-first search, depth-first search, shortest path search, or constrained path expansion. The calculation results include the set of nodes reachable from the source graph nodes, the corresponding path set, and changes in path length. By comparing the results before and after mapping, the system obtains changes such as newly added reachable nodes, failed reachable nodes, new paths, and path shortening. These results are organized into reachability state change information between nodes and output to subsequent inference and analysis stages.

[0060] After obtaining information on changes in reachability between nodes, the system further focuses on the changes in privacy object association inference caused by these reachability changes. The processing logic here is as follows: if a shared action causes a participating object to newly access multiple previously scattered privacy objects in the response state subgraph, or creates new combinations of reachable paths from a participating object to several privacy objects, these path combinations may constitute new association inference conditions. Therefore, the inference analysis unit can combine and judge changes in the set of reachable nodes and the set of reachable paths based on preset inference rules, a graph rule engine, or an association rule analysis mechanism. For example, when a participating object can simultaneously reach a nickname object, a location object, and a relationship tag object after mapping, the system can determine that the object has the conditions for further association inference of specific identity information; or, for example, when two previously disconnected paths are connected after a shared action injection, the system can identify a new inference path. After the above processing, the system can output the set of privacy objects that can be inferred and the corresponding privacy object inference path change results, which constitute the privacy object inference state change information.

[0061] To facilitate understanding, a simple scenario can be used as an example. Suppose a community member wants to share content containing activity location descriptions, member titles, and community tags with several recipients. Upon receiving this request, the system first locates the initiating node, recipient nodes, content object nodes, and the sharing and access relationship edges connected to them in the graph. Then, based on the strength of these edge connections, it filters out highly correlated recipients and adjacent objects, constructing an affected relationship subgraph. Next, it performs path searches before and after mapping, discovering that several recipients have added reachable paths to the location object and relationship object after mapping. Finally, it performs inference rule analysis based on the new path combinations, concluding that some recipients possess the conditions to infer specific privacy objects. In this way, the action response information is concretized into two parts: one part is the reachability state change information between nodes, and the other part is the privacy object inference state change information. Both can be directly used as input for the next stage of exposure state incremental analysis.

[0062] In practical applications, the description data of the shared actions to be executed can originate from either the sharing request submitted by the front end or the policy queue on the server side; the affected relationship subgraph can be temporarily generated in the graph database or reconstructed in memory using an adjacency list; reachability inference can employ graph traversal algorithms such as BFS and DFS, or a constrained path search strategy; the inferred relationship analysis can be completed through a rule engine, or through knowledge graph reasoning, association rule mining, or path combination analysis mechanisms. If the shared resources also contain image description text, attachment description information, or tag content extracted from image recognition results, the corresponding inputs can still be uniformly converted into structured object records according to the previous process before entering the action response analysis process of this embodiment.

[0063] In the data sharing process within interest communities, the system has already completed the mapping of sharing actions and the deduction of relationship responses in the preliminary stage. At this point, it is usually possible to obtain the results of changes in the connectivity of graph nodes and the results of inferred relationship changes of privacy objects. The next issue to address is no longer whether there have been changes, but rather how much exposure these changes have increased for the target privacy object. This allows the relationship analysis results obtained earlier to be compressed into a quantitative result that can directly participate in subsequent sharing control decisions. Therefore, in one embodiment of this invention, the focus is on the exposure quantification processing stage before sharing decisions, which is used to uniformly convert accessibility changes and inferred changes into the exposure state increment of privacy objects.

[0064] In this embodiment, the process of determining the exposure state increment includes: determining the increment of shared participating objects and the increment of reachable paths before and after the shared action mapping based on the reachability state change information between nodes; determining the number of newly inferred privacy objects and the increment of inference paths before and after the shared action mapping based on the privacy object inference state change information; and summarizing the increment of shared participating objects, the increment of reachable paths, the number of newly inferred privacy objects, and the increment of inference paths to obtain the exposure state increment of the privacy object.

[0065] In actual processing, the input data entering this stage is generally no longer the original text, original images, or original logs, but rather the action response information output from the previous stage. This action response information is usually passed into the current processing flow in the form of JSON results, database intermediate table records, or in-memory objects, and includes at least two parts: one part is the reachability state change information between nodes, and the other part is the privacy object inference state change information. The former usually records the set of reachable nodes and the set of reachable paths before and after mapping, while the latter usually records the set of privacy objects that can be inferred before and after mapping and the set of inference paths. In other words, the object processed in this embodiment is already a structured graph response result, rather than the initial social data itself.

[0066] For clarity, let's start with the change in reachability. The system first reads the set of shared participants that can reach a specific privacy object before and after mapping, and then uses set difference operations to find the objects newly added to the set after mapping. The number of new objects is the increment of shared participants. Simultaneously, the system also reads the set of reachable paths pointing to the privacy object before and after mapping. These paths can be stored as node sequences, edge sequences, or path identifier strings, as long as they can be distinguished. By deduplicating and comparing the path sets before and after mapping, the system obtains the set of newly added paths, the number of which is the increment of reachable paths. Thus, based on the information about changes in reachability between nodes, the system obtains two intermediate results: one reflecting which newly added shared participants can reach the privacy object, and the other reflecting how many new reachable paths have been added.

[0067] Next, the system shifts its focus to inferring changes. Unlike the previous step, the focus here is not on direct arrival, but on whether new inferable privacy objects and new inference paths emerge after mapping. Specifically, this can be achieved by identifying new members from the sets of inferable privacy objects before and after mapping; the number of these new members represents the number of newly inferable privacy objects. Then, the sets of inference paths before and after mapping are compared to obtain the set of newly added inference paths, the number of which represents the inference path increment. These inference paths can be output from the rule engine of the previous stage or from the knowledge graph reasoning results, as long as they ultimately lead to a structured result where a shared participating object can further infer a certain privacy object through certain path combinations. At this step, the system obtains two more intermediate quantities: the number of newly inferable privacy objects and the inference path increment.

[0068] Only after all four components are prepared does the system perform the aggregation process. In other words, this embodiment does not directly give a general score to the graph, but first breaks down the exposure changes into four types of increments: newly added participating objects, newly reached paths, newly inferable privacy objects, and newly inferable paths, and then combines them into a unified exposure state increment result. Common mechanisms such as rule tables, weighted statistics, or interval mapping can be used for aggregation. For example, in one implementation, the system first unifies the dimensions of the four components, and then performs a weighted aggregation according to preset weights to output a numerical exposure state increment; in another implementation, the rule engine can directly give the corresponding exposure level result based on the interval where the four components are located. Regardless of the implementation method used, the final output should be a unified result that can be directly called by the subsequent exposure mismatch parameter calculation process.

[0069] A concrete example would make this clearer. Suppose that before a shared action is executed, only two participating objects can reach a location-based privacy object through existing relationship chains, and there is only one valid reachable path. After action response deduction, this number increases to five objects and four paths. The system then obtains an increment of three participating objects and three reachable paths. Further suppose that before mapping, only one privacy object can be further inferred, and after mapping, two more privacy objects can be inferred, while the number of inferred paths increases from one to four. The number of newly inferred privacy objects is now two, and the inferred path increment is three. At this point, the system inputs these four results (3, 3, 2, 3) into the aggregation rule to form the exposure state increment corresponding to the current target privacy object. In this way, the changes that were originally scattered across different graph analysis steps are compressed into a unified incremental representation result.

[0070] From a practical implementation perspective, the set difference operation and path difference comparison here do not rely on special equipment; the previously established server-side graph processing environment can be used. If the action response information is stored in a relational database table, the incremental results mentioned above can be obtained through SQL queries, group statistics, and set difference filtering. If the action response information already exists in JSON or in-memory object form, it can also be processed directly using set operation libraries, graph analysis libraries, or path comparison programs. For path set comparison, a common practice is to first encode the path into a standardized node sequence or hash identifier, and then perform difference judgment. This avoids the same path being counted repeatedly due to different expression forms. If the shared resource contains image tags, attachment descriptions, or video frame attached text, this content has usually been converted into privacy objects and inferred path results by the preceding process before entering this embodiment. Therefore, this stage does not need to return to the original image data or original text data; incremental quantization can be performed only around the structured response results.

[0071] Through the above processing, this embodiment does not simply count changes, but transforms the complex graph structure changes obtained from the previous relational response deduction into a unified exposure quantity that can be directly used for subsequent decision-making. This allows the shared control flow to retain the fine-grained foundation of the previous graph analysis while also possessing quantifiable results that are computationally calculable, transferable, and comparable in engineering.

[0072] In the aforementioned processing, the system has already obtained the exposure state increment of the privacy object and the protection tendency parameter characterizing the target protection strength of the current sharing request. At this point, it is necessary to further determine whether the actual exposure level caused by the current sharing action is consistent with the target protection strength corresponding to the sharing request itself, and to what extent they deviate. Based on this, this embodiment mainly focuses on the parameter determination stage in the sharing decision-making process. By unifying and hierarchically mapping the exposure state increment and protection tendency parameter, an exposure mismatch parameter that can directly participate in the generation of subsequent secure sharing schemes is formed.

[0073] In this embodiment, the process of determining the exposure mismatch parameter includes: normalizing the exposure state increment and protection tendency parameter to obtain the exposure intensity value and the target protection intensity value, respectively; determining the degree of matching deviation based on the difference between the exposure intensity value and the target protection intensity value; and mapping the degree of matching deviation to the corresponding exposure mismatch parameter according to the interval in which the degree of matching deviation is located, based on the preset mismatch grading rules.

[0074] In actual processing, the input data at this stage mainly comes from the output results of the preceding processing steps, including the exposure state increment and the protection tendency parameter. These can be transmitted via database fields, JSON intermediate results, cached objects, or structured messages in a message queue. Since both quantities characterize the current sharing request's state, their sources and value ranges differ. Therefore, before entering the matching analysis, the system first performs a unified dimensionality process on both. Specifically, the parameter determination unit reads the exposure state increment and protection tendency parameter corresponding to the current sharing request and performs normalization processing according to preset normalization rules. Common implementation methods include min-max normalization, interval scaling, or standardized mapping based on historical sample ranges. For example, the system can map the exposure state increment to the 0-1 interval to obtain the exposure intensity value; then map the protection tendency parameter to the same interval to obtain the target protection intensity value. After this processing, the two original quantities are converted into directly comparable unified intensity values.

[0075] After normalization, the system begins calculating the degree of mismatch. Specifically, the parameter determination unit performs a difference calculation between the exposure intensity value and the target protection intensity value to obtain the difference result for the current sharing request. This difference result retains both magnitude and direction information: when the exposure intensity value is higher than the target protection intensity value, it indicates that the exposure level caused by the current sharing action is higher than the target protection requirement; when the exposure intensity value is lower than the target protection intensity value, it indicates that the exposure level corresponding to the current sharing action does not exceed the protection intensity required by the current request. To facilitate subsequent rule processing, the system uses this difference result as the degree of mismatch and writes it into the intermediate parameter table or runtime context object corresponding to the current sharing request for subsequent mismatch classification.

[0076] Next, the system maps the degree of matching deviation to corresponding exposure mismatch parameters based on preset mismatch grading rules. These mismatch grading rules can be pre-stored in a rule table, rule engine, or configuration file. A common approach is to divide the system into multiple intervals based on the degree of matching deviation and set corresponding mismatch levels or parameter values ​​for different intervals. For example, when the degree of matching deviation falls into the first preset interval, it can be mapped to a low mismatch parameter; when it falls into the second preset interval, it can be mapped to a medium mismatch parameter; and when it falls into the third preset interval, it can be mapped to a high mismatch parameter. During execution, the system only needs to compare the current degree of matching deviation with the boundaries of each interval to output the corresponding exposure mismatch parameter. This parameter can be represented in numerical form or in a graded identifier form, ultimately serving as direct input for the next stage of generating a secure sharing scheme.

[0077] To illustrate with a specific scenario, suppose a shared request received an exposure increment of 0.78 and a protection tendency parameter of 0.42 in the previous stage. After the system unifies these two values, it obtains an exposure strength value of 0.78 and a target protection strength value of 0.42, with a difference of 0.36. If the rule table specifies that a difference between 0 and 0.15 corresponds to low mismatch, between 0.15 and 0.30 to medium mismatch, and above 0.30 to high mismatch, then the current request can be mapped to a high mismatch parameter. In this way, exposure results and protection requirements from different sources are unified into a single decision parameter, which subsequent modules can use to select more stringent shared control items.

[0078] From a practical implementation perspective, this embodiment does not rely on specific hardware and can be completed using the aforementioned server-side processing environment. If the exposure status increment and protection tendency parameters are stored in a relational database, the parameter determination service can directly read them by querying the fields and perform normalization, difference calculation, and interval matching. If they are temporarily stored in the form of JSON or cached objects from previous processes, the same processing can also be completed in memory. The preset mismatch classification rules can be configured using rule tables or implemented using rule engines, decision trees, or simple piecewise functions. In this way, the system can further compress the previously obtained structured exposure results and target protection results into unified exposure mismatch parameters, making them both interpretable and easy to participate in the subsequent security sharing scheme generation process.

[0079] After obtaining the exposure mismatch parameters in the previous processing stage, the system needs to further convert these parameters into directly executable data sharing control results. In other words, the focus of processing at this point has shifted from risk identification and quantification to control scheme generation. That is, based on the degree of mismatch corresponding to the current sharing request, a suitable control rule is selected, and a secure sharing scheme that can be directly invoked by subsequent sharing control processes is formed. In one embodiment provided by the present invention, the secure sharing scheme generation process includes: determining the corresponding mismatch level based on the exposure mismatch parameters; matching the secure sharing rule corresponding to the mismatch level from a preset secure sharing rule set; determining at least one control item among the shared content form, the scope of shared participants, access validity conditions, and sharing verification method based on the matched secure sharing rule; and generating a secure sharing scheme based on the determined control item.

[0080] In a specific processing flow, the input data in this stage mainly includes two categories: one is the exposure mismatch parameters output from the previous stage, and the other is the basic description information of the current sharing request. Exposure mismatch parameters can be stored as numerical fields, level fields, or intermediate result objects, and are typically stored in database records, cached objects, or transmitted between services via JSON messages along with the sharing request. The basic description information of the sharing request includes at least the sharing object identifier, sharing initiator identifier, sharing receiver identifier, sharing resource identifier, request time, and the context conditions corresponding to the current request. Since the overall server-side processing environment has been described in the previous embodiments, the same processing chain can be continued in this embodiment, with the sharing decision unit and rule matching unit completing the subsequent scheme generation.

[0081] First, the system determines the corresponding mismatch level based on the exposed mismatch parameters. In practice, the shared decision unit can read the exposed mismatch parameters and call pre-configured level classification rules for judgment. If the exposed mismatch parameters are already discrete level results, they can be directly used as the mismatch level; if the exposed mismatch parameters are continuous values, they can be mapped to discrete levels such as low mismatch, medium mismatch, and high mismatch through interval partitioning rules, piecewise functions, or rule table lookup. The output of this step is the mismatch level corresponding to the current shared request, which is written into the intermediate state object of this request for use in the next step of rule matching.

[0082] After obtaining the mismatch level, the system does not directly generate a control result, but instead proceeds to the security sharing rule matching stage. Specifically, the rule matching unit retrieves rule items corresponding to the current mismatch level from a preset security sharing rule set. The security sharing rule set can be stored in the form of a database rule table, configuration file, rule engine rule library, or policy template library. Each rule record includes at least the applicable mismatch level, a set of optional control items, and the combination constraints between the control items. During the retrieval, precise level matching can be used, or secondary matching can be performed by combining the shared object type, resource type, or layer attributes. After the matching is completed, the system obtains the security sharing rule corresponding to the current mismatch level. This result can typically be represented as structured information such as rule number, rule description, control item template, and control item value set.

[0083] Subsequently, the system determines at least one control item from the following categories based on the matched security sharing rules: the form of the shared content, the scope of participants, the access validity conditions, and the sharing verification method. These control items can be understood as the specific configuration results that make up the final sharing scheme. For example, regarding the form of the shared content, the system can determine whether to use original content sharing, sharing after field masking, summary sharing, fragmented sharing, or tagged sharing, according to the rules. Regarding the scope of participants, the system can determine whether to limit sharing to specific objects, members of specific circles, specific role objects, or a limited set of trusted objects. Regarding the access validity conditions, the system can determine the access duration, number of accesses, validity period for a single view, or access only within a specific time window. Regarding the sharing verification method, the system can determine one or more combinations of password verification, identity authentication, device verification, or multi-factor authentication. During execution, the rule matching unit can read the candidate values ​​corresponding to each control item from the rule set through a rule engine, template filling program, or policy parsing program, and then combine them with the context conditions of the current sharing request to determine the final value. The output of this step is a set of control items, which can be expressed in the form of structured records, such as content format = summary, reception range = specified circle, valid conditions = 30 minutes, and verification method = two-factor authentication.

[0084] After the set of control items is generated, the system forms the final secure sharing scheme based on these control items. Specifically, the scheme generation unit encapsulates the set of control items into a unified scheme object. This scheme object can be stored in JSON, XML, database table records, or in-memory configuration objects, and must include at least fields such as scheme identifier, applicable request identifier, set of control items, execution priority, and effective time. In this way, the secure sharing scheme is no longer just an abstract judgment result, but a structured scheme that can be directly passed to the subsequent data sharing control execution process. Subsequent modules can read this scheme object and execute actual controls according to the shared content format, scope of shared participants, access validity conditions, and sharing verification methods recorded within it.

[0085] To illustrate this more clearly, consider a scenario. Suppose that the exposure mismatch parameters of a sharing request, after processing in the previous stage, are determined to have a high mismatch level. Based on this, the system retrieves a set of secure sharing rules corresponding to the high mismatch level from the rule set. These rules require: the shared content to be in summary form; the scope of participants to be shared is limited to trusted members within the initiator's social circle; access is valid only once and for 30 minutes; and two-factor authentication is used for verification. The system generates a corresponding set of control items based on these rules and further encapsulates this into a secure sharing scheme for the current request. Thus, when the current sharing request is executed subsequently, it will no longer be opened directly as the original request, but will be processed in a controlled manner according to this secure sharing scheme.

[0086] The secure sharing rule set can be stored in a relational table structure or configured in the rule engine. The mapping from mismatch levels to rule items can be accomplished through simple table lookups, decision trees, rule engines, or policy template matching mechanisms. If the current shared resource itself contains text, image descriptions, or tag content extracted from video frames, this content is no longer re-analyzed as raw input at this stage, but rather participates in rule matching using the pre-processed resource object description results. Therefore, the focus of this embodiment is not on re-identifying resource content, but on further transforming the quantified exposure mismatch parameters into an executable sharing control scheme, enabling a smooth transition from parameter determination to control execution in the sharing decision-making process.

[0087] In another embodiment of the present invention, the focus is on the feedback correction stage after sharing execution. This stage involves writing back and updating the privacy sharing relationship graph based on the actual execution results, and adjusting the secure sharing rules so that subsequent similar sharing requests can continue to execute based on a more realistic operational scenario. Specifically, the update process of the privacy sharing relationship graph and secure sharing rules includes: collecting access logs, verification results, sharing scope change records, and anomaly handling records generated after the execution of data sharing control, and identifying the actual sharing participants, the actual exposed privacy objects, and the actual effective relationship edges; updating the graph nodes, relationship edges, and association strength in the privacy sharing relationship graph based on the identification results; and correcting the correspondence between mismatch levels and control items in the secure sharing rules based on the deviation between the sharing execution results and the secure sharing scheme.

[0088] In a specific implementation scenario, the current sharing request has already been controlled and executed according to the secure sharing scheme generated in the previous embodiment. For example, the system has shared a certain text resource in a digest form with several objects within a specified circle, and limited the access duration and verification method. Subsequently, the platform will generate various types of post-execution data. Among them, the access log can record fields such as access time, access object, resource identifier, access action, and client identifier; the verification result can record whether the authentication was successful, the number of authentication attempts, the reason for failure, and the verification method identifier; the sharing scope change record can record content such as adding receiving objects, removing receiving objects, and extending or shortening the time limit; the exception handling record can record content such as unauthorized access alarms, abnormal forwarding, abnormal downloads, manual interception, and automatic blocking results. This data is usually stored in the form of database table records, JSON log messages, CSV exported files, or structured messages in message queues, and is read by the execution feedback processing unit.

[0089] At the start of processing, the system does not immediately update the graph; instead, it first merges the data after execution. Specifically, it associates access logs, verification results, sharing scope change records, and exception handling records by sharing request identifier, resource identifier, session identifier, and timestamp to form an execution feedback data packet corresponding to the current sharing request. If the platform uses streaming log processing, the log consumer program can aggregate the data packet by request identifier; if the platform uses a relational database, the data packet can be generated through multi-table join queries. The purpose of this is to unify the execution traces scattered across different tables or different log sources into a single request context, facilitating subsequent identification of the actual objects participating in the sharing and the truly effective relationship edges.

[0090] After receiving the execution feedback data packet, the system begins to identify the actual participants in the sharing process. The actual participation is not simply based on the set of receiving objects in the original sharing request, but rather on a re-verification based on the actual execution records. For example, some objects, although within the original receiving range, may not have actually participated in the sharing due to failed verification, access timeout, or removal by subsequent range adjustments; conversely, some objects may have been added to the actual sharing process due to range changes. The execution feedback processing unit can form the set of actual participants in the current sharing request based on successful access records in the access log, passed records in the verification results, and newly added records in the sharing range change records, and pass this set as an intermediate result to the subsequent exposed object identification step.

[0091] Subsequently, the system identifies the actually exposed privacy objects based on this post-execution data. Specifically, the system first extracts the accessed resource objects from the access logs, and then, combined with the content format actually used in the sharing control, determines which privacy objects were indeed presented during this execution. For example, if the system uses summary sharing, not all privacy objects in the original resource will be exposed; only those preserved by the summary result will be exposed. If the system uses field-masked sharing, the masked privacy objects should not be included in the actual exposed object set. The execution feedback processing unit can parse the actually presented resource version based on the content format identifier, resource version identifier, and access records in the sharing execution result, further mapping the set of truly exposed privacy objects. If the shared resource is text content, a reverse lookup can be performed directly based on the text version record and the preceding privacy object index. If the shared resource contains image descriptions, attachment descriptions, or video frame tags, the actual exposed objects can also be determined based on these structured and saved resource description versions, without having to return to the original file for frame-by-frame processing.

[0092] After identifying the actual participants in the sharing process and the actual exposed privacy objects, the system further identifies the actually effective relationship edges. These relationship edges are no longer processed according to the theoretical candidate edge set, but are confirmed based on actual execution behavior. Specifically, if a participant successfully accesses a resource, the corresponding access relationship edge is confirmed to be effective; if an object is dynamically added to the sharing scope and completes access, both the newly added sharing relationship edge and the access relationship edge are considered to be effective; if an object exhibits abnormal downloads, abnormal forwarding, or unauthorized access, its corresponding abnormal relationship edge can be identified by combining the abnormal handling record. During relationship edge identification, the graph update unit can generate a set of actually effective relationship edges in the form of "participant in the sharing process—relationship type—privacy object / resource object," along with attribute information such as access count, last effective time, and whether it is abnormal. At this point, the system has obtained three key intermediate results: the set of actual participants in the sharing process, the set of actually exposed privacy objects, and the set of actually effective relationship edges.

[0093] Based on these identification results, the system begins updating the privacy-sharing relationship graph. The update process typically doesn't reconstruct the entire graph, but rather incrementally writes back the local nodes and relationships related to the current sharing request. If new actual participants are identified, corresponding graph nodes are added, or the participation status attributes of existing nodes are supplemented. If new active relationship edges are identified, these edges are added, or the access frequency, sharing frequency, and most recent occurrence time of existing relationship edges are updated. If certain relationship edges are frequently activated or repeatedly trigger anomalies during execution, the graph update unit can further adjust the association strength of these edges. For example, the association strength can be incrementally updated based on the current access frequency and anomaly records, making the association strength closer to the actual activity and risk levels of relationships in operation. This write-back process can either directly update edge attributes in the graph database or update the frequency and strength fields in the edge table maintained in the relational database, and then synchronize it to the graph service.

[0094] After the map update is complete, the system also needs to revise the secure sharing rules. This revision is not based solely on whether the execution was successful, but rather on the deviation between the execution result and the original secure sharing scheme. Specifically, the system can compare each control item in the original secure sharing scheme with the actual execution result. For example, the scheme might specify that the receiving range should be limited to a designated layer, but the logs show additional access; the scheme might specify an access validity period of 30 minutes, but the actual duration is longer due to manual relaxation; the scheme might specify two-factor authentication, but in actual execution, it degenerates into single-factor authentication due to device limitations. The execution feedback processing unit compiles these differences into a deviation result table and submits it to the rule revision unit for processing. The rule revision unit can adjust the correspondence between "mismatch level - control item" according to preset revision rules. For example, if the actual control strength is frequently lower than the scheme's control strength under a certain mismatch level, the default strength of the corresponding control item for that mismatch level can be increased in the rule set; if overly strict controls frequently occur under a certain mismatch level, leading to a large number of legitimate access failures, the corresponding control item can be appropriately relaxed. In this way, the secure sharing rule set is no longer a static rule table, but can be gradually modified as execution feedback is received.

[0095] To aid understanding, consider this scenario. Suppose a sharing request originally only allowed 5 objects within a certain circle to view the digested content via two-factor authentication within 30 minutes. However, logs show that only 3 objects actually completed the access, and one of these objects was added to the access set through a scope change, and an abnormal forwarding attempt occurred and was blocked by the system. The system first identifies the 4 objects actually participating in the sharing based on the access logs and authentication results. Then, it identifies the actual set of privacy objects exposed based on the digested resource version. Next, it confirms that the sharing and access relationship edges corresponding to the newly added objects are actually effective, and increases the association strength of relationship edges with abnormal records. Then, the system compares the original secure sharing scheme with the actual execution, finding a discrepancy between the receiving scope control and authentication control under the current mismatch level. Therefore, it corrects the control item combination corresponding to this mismatch level in the rule set so that subsequent similar requests can more accurately match the applicable control strength.

[0096] In another embodiment of the present invention, the data security sharing system responding to the privacy protection needs of interest-based communities can be deployed in the server-side processing environment of the interest-based community platform. The front end can be a mobile terminal, a web terminal, or a management terminal, and the back end can be composed of a business server, graph computing nodes, relational database servers, graph database servers, cache nodes, and log storage nodes. The nodes interact with each other via a local area network or Ethernet. Sharing requests initiated by the front end terminal can be sent to the business server through the business gateway. Subsequently, the various processing modules collaboratively complete graph construction, parameter determination, response deduction, sharing control, and feedback updates.

[0097] In this embodiment, the data security sharing system that responds to the privacy protection needs of interest communities, such as Figure 2 As shown, the system includes: a graph construction module, used to parse social multi-source data in interest communities, determine the privacy objects and sharing participants corresponding to the sharing request as graph nodes, and the relationships between the graph nodes as relationship edges, to construct a privacy sharing relationship graph; a demand determination module, used to determine the privacy protection requirements corresponding to the sharing request based on the degree of privacy sensitivity and sharing constraints; a tendency determination module, used to determine the protection tendency parameter characterizing the protection strength of the target of the sharing request based on the privacy protection requirements and historical sharing records; a response inference module, used to map the sharing action to be executed to the privacy sharing relationship graph, perform relationship response inference on the affected graph nodes and relationship edges, and generate action response information characterizing the changes in reachable states between nodes and the inferred states of privacy objects; a mismatch determination module, used to determine the exposure state increment of privacy objects in the privacy sharing relationship graph before and after the sharing action mapping based on the action response information, and determine the exposure mismatch parameter based on the degree of matching deviation between the exposure state increment and the protection tendency parameter; a control module, used to generate a secure sharing scheme based on the exposure mismatch parameter and combined with secure sharing rules, and execute data sharing control according to the secure sharing scheme; and an update module, used to update the privacy sharing relationship graph and secure sharing rules according to the sharing execution results.

[0098] The graph construction module can be integrated into the graph processing service program on the business server and connected to the user database, content database, behavior log database, and sharing request database. It extracts privacy objects, sharing participants, and their relationship information from database records or cached data and writes them into the graph database to form a privacy sharing relationship graph. The requirement determination module and the preference determination module can be jointly deployed in the sharing decision service. The former reads the acceptance scope, sharing conditions, and sharing methods from the sharing request and generates privacy protection requirements based on the privacy object information in the graph. The latter connects to the historical sharing record storage node, reads historical control results, and generates protection preference parameters. These protection preference parameters can be written to a cache or intermediate result table for subsequent modules to use.

[0099] The response simulation module is preferably deployed in the graph computing node and maintains a high-speed data connection with the graph database. This module can consist of an action mapping unit, a subgraph construction unit, a connectivity analysis unit, and an inference analysis unit. It is used to locate the source graph node, target graph node, and relation edges corresponding to the shared action to be executed, construct the affected relation subgraph, and perform reachability analysis and inference analysis in the in-memory graph structure or a temporary view of the graph database to obtain action response information. The mismatch determination module can be set up within the shared decision host and consists of an incremental statistics unit, a normalization processing unit, and a mismatch mapping unit. It is used to statistically analyze the exposure state increment, unify the dimensions of the exposure state increment and the protection tendency parameter, and output the exposure mismatch parameters according to preset mismatch classification rules.

[0100] The control module can be deployed within the shared control service on the business server and connect to the resource server, authentication server, and access control gateway via a network interface. This module retrieves suitable secure sharing rules based on exposure mismatch parameters, generates a secure sharing scheme, and controls the form of shared content, the scope of participating objects, access validity conditions, and sharing verification methods accordingly. The update module can be deployed in the background maintenance service, maintaining data connections with access log storage nodes, verification result recording nodes, shared scope change recording nodes, and exception handling recording nodes. It is used to identify the actual objects participating in the sharing, the actual exposed privacy objects, and the actual effective relationship edges after the shared control is executed, and writes the relevant results back to the graph database and rule base, incrementally correcting the correspondence between graph nodes, relationship edges, association strength, mismatch levels, and control items.

[0101] Thus, the front-end terminal, business server, graph computing node, graph database, rule base, cache node, log node and authentication interface form a complete data security sharing and processing link, so that each software module has a clear hardware support relationship, installation location and interaction path, thereby enabling the system to be directly deployed and implemented in an engineering manner in the interest community platform.

[0102] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. For those skilled in the art, various equivalent substitutions, modifications, improvements, or combinations can be made without departing from the concept and essence of the present invention, and these equivalent substitutions, modifications, improvements, or combinations should also be considered to fall within the scope of protection of the present invention.

Claims

1. A data security sharing method that responds to the privacy protection needs of interest-based communities, characterized in that, include: Analyze multi-source social data in interest communities, identify the privacy objects and sharing participants corresponding to the sharing requests as graph nodes, and use the relationships between the graph nodes as relationship edges to construct a privacy sharing relationship graph. Determine the privacy protection requirements corresponding to the sharing request based on the privacy sensitivity of the privacy object and the sharing constraints. Based on privacy protection needs and historical sharing records, determine the protection tendency parameters that characterize the strength of protection for the target of the sharing request; The shared actions to be executed are mapped to the privacy-sharing relationship graph. The relationship response is deduced for the affected graph nodes and relationship edges, and action response information representing the reachable state changes between nodes and the inferred state changes of privacy objects is generated. The exposure status increment of privacy objects in the privacy sharing relationship graph before and after the shared action mapping is determined based on the action response information; The exposure mismatch parameter is determined based on the degree of deviation between the exposure status increment and the protection tendency parameter; A secure sharing scheme is generated based on the exposed mismatch parameters and combined with secure sharing rules, and data sharing control is executed according to the secure sharing scheme. Update the privacy sharing relationship graph and security sharing rules based on the shared execution results.

2. The data security sharing method for responding to the privacy protection needs of interest-based communities according to claim 1, characterized in that, The construction of the privacy-sharing relationship graph includes: performing privacy entity identification and sharing participant parsing on social multi-source data to obtain privacy objects and sharing participants; extracting the attribution relationship, interaction relationship, sharing relationship, and access relationship between privacy objects and sharing participants; and constructing the privacy-sharing relationship graph using privacy objects and sharing participants as graph nodes and attribution relationship, interaction relationship, sharing relationship, and access relationship as relationship edges.

3. The data security sharing method for responding to the privacy protection needs of interest-based communities according to claim 1 or 2, characterized in that, The relation edges in the privacy sharing relation graph have corresponding association strengths. The association strength is determined based on the historical interaction records, historical sharing records, access records, and co-occurrence results of privacy entities between privacy objects and sharing participants, and the association strength is marked on the corresponding relation edge.

4. The data security sharing method for responding to the privacy protection needs of interest-based communities according to claim 3, characterized in that, The process of determining the protection tendency parameter includes: determining the corresponding privacy sensitivity level based on the privacy object category involved in the sharing request; determining the sharing constraint requirements based on the receiving scope, sharing conditions, and sharing method of the sharing participants; combining and mapping the privacy sensitivity level and sharing constraint requirements according to the preset requirement mapping rules to generate privacy protection requirements; extracting the historical sharing control results corresponding to the current sharing request from the historical sharing records; and determining the protection tendency parameter based on the privacy protection requirements and the historical sharing control results.

5. The data security sharing method for responding to the privacy protection needs of interest-based communities according to claim 4, characterized in that, The process of generating the action response information includes: determining the source graph node, target graph node, and relation edges connecting the source graph node and the target graph node in the privacy sharing relationship graph; identifying the graph nodes and relation edges affected by the shared action to be executed based on the association strength of the relation edges, and constructing the corresponding affected relation subgraph; performing reachability deduction on the graph node connectivity before and after the shared action to be executed in the affected relation subgraph, determining the changes in the set of reachable nodes and the set of reachable paths, and obtaining the reachability state change information between nodes; and deducing the privacy object association inference relationship before and after the shared action to be executed based on the changes in the set of reachable nodes and the set of reachable paths, determining the changes in the set of privacy objects that can be inferred and the privacy object inference path, and obtaining the privacy object inference state change information.

6. The data security sharing method for responding to the privacy protection needs of interest-based communities according to claim 5, characterized in that, The process of determining the exposure state increment includes: determining the increment of shared participants and the increment of reachable paths before and after the shared action mapping based on the reachability state change information between nodes; determining the number of newly inferred privacy objects and the increment of inference paths before and after the shared action mapping based on the privacy object inference state change information; and summarizing the increment of shared participants, the increment of reachable paths, the number of newly inferred privacy objects, and the increment of inference paths to obtain the exposure state increment of the privacy object.

7. The data security sharing method for responding to the privacy protection needs of interest-based communities according to claim 6, characterized in that, The process of determining the exposure mismatch parameter includes: normalizing the exposure state increment and protection tendency parameter to obtain the exposure intensity value and the target protection intensity value, respectively; determining the degree of matching deviation based on the difference between the exposure intensity value and the target protection intensity value; and mapping the degree of matching deviation to the corresponding exposure mismatch parameter according to the interval in which the degree of matching deviation is located, based on the preset mismatch classification rules.

8. The data security sharing method for responding to the privacy protection needs of interest-based communities according to claim 7, characterized in that, The process of generating the secure sharing scheme includes: determining the corresponding mismatch level based on the exposed mismatch parameters; matching the secure sharing rules corresponding to the mismatch level from a preset secure sharing rule set; determining at least one control item among the shared content form, the scope of shared participants, the access validity conditions, and the sharing verification method based on the matched secure sharing rules; and generating the secure sharing scheme based on the determined control items.

9. The data security sharing method for responding to the privacy protection needs of interest-based communities according to claim 8, characterized in that, The update process of the privacy sharing relationship graph and security sharing rules includes: collecting access logs, verification results, sharing scope change records, and anomaly handling records generated after the execution of data sharing control, and identifying the sharing participants, the privacy objects actually exposed, and the relationship edges that actually take effect based on these records; updating the graph nodes, relationship edges, and association strength in the privacy sharing relationship graph based on the identification results; and correcting the correspondence between the mismatch level and control items in the security sharing rules based on the deviation between the sharing execution results and the security sharing scheme.

10. A data security sharing system that responds to the privacy protection needs of interest-based communities, characterized in that, include: The graph construction module is used to parse social multi-source data in interest communities, determine the privacy objects and sharing participants corresponding to the sharing requests as graph nodes, and the relationships between the graph nodes as relationship edges to construct a privacy sharing relationship graph. The requirement determination module is used to determine the privacy protection requirements corresponding to the sharing request based on the degree of privacy sensitivity and sharing constraints. The bias determination module is used to determine the protection bias parameter, which characterizes the protection strength of the target of the sharing request, based on privacy protection requirements and historical sharing records. The response inference module is used to map the shared actions to be executed to the privacy sharing relationship graph, perform relationship response inference on the affected graph nodes and relationship edges, and generate action response information that represents the reachable state changes between nodes and the inferred state changes of privacy objects. The mismatch determination module is used to determine the exposure state increment of privacy objects in the privacy sharing relationship graph before and after the shared action mapping based on the action response information, and to determine the exposure mismatch parameter based on the degree of matching deviation between the exposure state increment and the protection tendency parameter. The control module is used to generate a secure sharing scheme based on the exposed mismatch parameters and in combination with secure sharing rules, and to execute data sharing control according to the secure sharing scheme; The update module is used to update the privacy sharing relationship graph and security sharing rules based on the shared execution results.

Images