Multi-platform data collaborative governance authority dynamic control method and system

Abstract

Multiple embodiments of this specification relate to the field of information technology, and specifically to a method and system for dynamic control of multi-platform data collaborative governance permissions. The method includes: marking a static permission description for each field; obtaining a request data result set when receiving an event work order or collaboration application sent by a user; identifying the current scenario, the requester's department, the requester's role, and the requester's permission level; comparing the static permission description with the requester's department, the requester's role, and the requester's permission level to obtain a static permission data set; comparing the static permission description with the current scenario to obtain a dynamic permission data set and validity period; performing conflict check on the static permission data set and the dynamic permission data set to obtain a permission set, and generating a permission token based on the permission set and the validity period; recording logs while the platform feedback data, and using blockchain to store the logs; and reclaiming the permission token based on triggering.

Description

Technical Field

[0001] Multiple embodiments of this specification relate to the field of information technology, and specifically to a method and system for dynamic control of multi-platform data collaborative governance permissions. Background Art

[0002] In grassroots community management, data collaboration and permission management are crucial for information flow and security. Currently, role-based access control (RBAC) mechanisms are widely used, but they present significant shortcomings when addressing multi-platform collaboration scenarios. Traditional methods rely on static permission configuration and pre-defined "role-permission" mappings, ignoring the detailed division of data confidentiality and operational scenarios, leading to excessive data openness. Temporary collaboration needs require manual permission adjustments, a time-consuming process that can easily lead to temporary accounts that are not promptly deregistered, increasing security risks. Each department's system permission system is independent, requiring repeated interface development for data sharing, increasing maintenance costs and the complexity of integrating new systems. These issues lead to delayed permission allocation responses, extensive permission management, high rates of residual permissions, and difficulties in compliance audits. Therefore, a new management system that can adapt to changing scenarios, implement fine-grained permission control, and support automatic permission recovery is urgently needed. Summary of the Invention

[0003] Multiple embodiments of this specification describe a method and system for dynamic control of multi-platform data collaborative governance permissions.

[0004] In a first aspect, the embodiments of this specification provide a method for dynamically controlling multi-platform data collaborative governance permissions, including the following steps:

[0005] Each platform marks each field of the data with a static permission description, which includes department, user role, confidentiality level, usage scenario description, validity period description, and operation description;

[0006] When any platform receives an event ticket or collaboration request sent by a user, it obtains the requested data result set based on the search formula carried by the event ticket or collaboration request;

[0007] Identify the current scenario, requester department, requester role, and requester authority level based on the event work order or collaboration request;

[0008] Traversing the fields included in the request data result set, comparing the static permission description of the field with the requester's department, requester's role, and requester's permission level to obtain a static permission data set;

[0009] Compare the static permission description of the field with the current scenario to obtain a dynamic permission data set and validity period;

[0010] Performing conflict check on the static permission data set and the dynamic permission data set to obtain a permission set, and generating a permission token based on the permission set and the validity period;

[0011] The user uses the permission token and data search formula to obtain data from the platform, and the platform records the feedback data in a log, and uses the blockchain to store the log at a preset period;

[0012] The platform reclaims the permission token based on the expiration of the validity period, the triggering of the current scenario completion event, or the triggering of abnormal query behavior of the user.

[0013] In a second aspect, the embodiments of this specification provide a multi-platform data collaborative governance authority dynamic control system, including:

[0014] The annotation module, each platform annotates each field of the data with a static permission description, which includes the department, user role, confidentiality level, usage scenario description, validity period description and operation description;

[0015] The search module, when any platform receives an event ticket or collaboration request sent by a user, obtains the requested data result set according to the search formula carried by the event ticket or collaboration request;

[0016] An identification module identifies the current scenario, the requester's department, the requester's role, and the requester's authority level based on the event work order or collaboration request;

[0017] A first comparison module traverses the fields included in the request data result set, compares the static permission description of the field with the requester's department, requester's role, and requester's permission level, and obtains a static permission data set;

[0018] A second comparison module compares the static permission description of the field with the current scenario to obtain a dynamic permission data set and validity period;

[0019] a verification module, performing conflict verification on the static permission data set and the dynamic permission data set to obtain a permission set, and generating a permission token based on the permission set and the validity period;

[0020] In the execution module, the user uses the permission token and data search formula to obtain data from the platform, and the platform records the feedback data in a log, and stores the log in a blockchain according to a preset period;

[0021] The monitoring module is used for the platform to reclaim the permission token based on the expiration of the validity period, the triggering of the current scenario completion event, or the triggering of abnormal query behavior of the user.

[0022] In a third aspect, embodiments of this specification provide an electronic device, including a processor and a memory;

[0023] The processor is connected to the memory;

[0024] The memory is used to store executable program code;

[0025] The processor reads the executable program code stored in the memory to run a program corresponding to the executable program code, so as to execute the method described in any one of the above aspects.

[0026] In a fourth aspect, an embodiment of this specification provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the method described in any one of the above aspects is implemented.

[0027] In a fifth aspect, embodiments of this specification provide a computer program product, including a computer program, which implements the method described in any of the above aspects when executed by a processor.

[0028] The beneficial effects of the technical solutions provided by some embodiments of this specification include at least:

[0029] In multiple embodiments of this specification, a dynamic permission control method and system are provided, which performs fine-grained permission control through a six-tuple static permission description combined with factors such as specific scenarios, validity periods, and operation types, ensuring that data is used correctly in appropriate scenarios, and avoiding the risk of data leakage due to long-term residual permissions through validity period settings and permission automatic recovery mechanisms. It overcomes the problem that traditional RBAC methods are difficult to meet the needs of modern grassroots governance, especially in the detailed division of data confidentiality, operation scenarios, etc., making cross-departmental collaboration more efficient and secure, and reducing the complexity caused by the independence of the permission system. Through the precise matching of required data fields in different scenarios, and the reasonable configuration of user roles and permission levels, effective use of resources is achieved, which not only ensures the safe flow of information, but also improves the accuracy of decision-making and service provision.

[0030] Other features and advantages of the various embodiments of this specification will be further disclosed in the following detailed description and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the technical solutions in the embodiments of this specification, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0032] Figure 1 Schematic diagram of the application scenario of the dynamic permission control method provided in the embodiments of this specification.

[0033] Figure 2 This is a schematic diagram of generating an authorization token provided in an embodiment of this specification.

[0034] Figure 3 This is a flow chart of the dynamic permission control method provided in the embodiments of this specification.

[0035] Figure 4 Schematic diagram of the dynamic permission control system provided in the embodiments of this specification.

[0036] Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of this specification. DETAILED DESCRIPTION

[0037] The following is an explanation and description of the technical solutions of the embodiments of this specification in conjunction with the drawings of the embodiments of this specification. However, the following embodiments are only preferred embodiments of this specification and are not exhaustive. Based on the embodiments in the implementation mode, other embodiments obtained by those skilled in the art without making any creative work are all within the scope of protection of this specification.

[0038] Throughout this specification, the claims, and the accompanying drawings, the terms "first," "second," "third," and the like are used to distinguish between different items, not to describe a particular order. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements but may optionally include steps or elements not listed, or may include other steps or elements inherent to the process, method, product, or apparatus.

[0039] In the following description, terms such as "inside", "outside", "up", "down", "left", "right", etc. that indicate directions or positional relationships are only used to facilitate the description of the embodiments and simplify the description. They do not indicate or imply that the devices or elements referred to must have a specific direction, be constructed and operate in a specific direction. Therefore, they should not be understood as limitations on this specification.

[0040] The data involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data comply with the relevant laws, regulations and standards of relevant countries and regions.

[0041] Before introducing the technical solution recorded in this specification, the application scenarios of the technical solution and related technologies are introduced.

[0042] In grassroots management, the rational configuration and dynamic adjustment of data permissions are key to ensuring smooth and secure information flow. Traditional role-based access control (RBAC) methods assign access rights through predefined role-permission mappings. For example, community directors are granted read and write permissions to all data within their jurisdiction by default. However, this approach fails to meet the needs of modern grassroots governance because it ignores the detailed division of data confidentiality (e.g., personal privacy versus public data) and operational scenarios (e.g., emergency response versus daily statistics). Furthermore, it relies on manual adjustment and revocation of temporary permissions, which is not only time-consuming but also prone to residual permissions.

[0043] For example, in a typical application scenario of grassroots community management, such as responding to a public health emergency, rapid cross-departmental collaboration is required to effectively control the spread of the epidemic. Different functional departments, such as health, public security, and community grid workers, need to share and access relevant data in real time to ensure accurate information transmission and rapid response. As the demand for multi-departmental collaboration grows, the independent permission systems of each departmental system make data sharing complex and costly.

[0044] To this end, this manual provides a dynamic permission level control and automatic recovery solution. Figure 1 The data 11 permission dynamic allocation scheme described in this specification adopts a six-tuple static permission description 12, which combines factors such as specific scenarios, validity periods and operation types to perform fine-grained permission control, and realizes automatic generation and timely recovery of permissions, effectively improving response speed and reducing the risk of data 11 leakage. In the technical solution provided in this specification, each platform 10 with data 11 associates a static permission description 12 with each field of the data 11. The static permission description 12 includes department, usage role, confidentiality level, usage scenario description, validity period description and operation description. The static permission description 12 defines the boundaries and conditions of a permission. For example, the department specifies the management agency to which the data 11 belongs; the usage role clarifies which job function can access the data 11; the confidentiality level is divided into different levels according to the sensitivity of the data 11; the usage scenario description defines under what specific circumstances the data 11 can be accessed; the validity period description sets the time range of the permission; and the operation description specifies the specific operation types that the user 20 can perform, such as reading, writing, downloading, etc.

[0045] The platforms 10 agree on the formats of event tickets 21 and collaboration requests. Figure 2When platform 10 receives an event ticket 21 or collaboration request submitted by a user 20 on another platform 10, it extracts the current scenario, requester department, requester role, and requester permission level of the event ticket 21 or collaboration request. It compares the extracted current scenario, requester department, requester role, and requester permission level with the static permission description 12 to ultimately obtain a permission token and its validity period. Within the validity period, the permission token can be used to perform operations on data 11, such as querying, forwarding, modifying, and downloading.

[0046] This manual first provides a method for dynamically controlling multi-platform data collaborative governance permissions. Figure 3 , including the steps of:

[0047] Step S1) Each platform 10 marks each field of the data 11 with a static permission description 12 , wherein the static permission description 12 includes a department, a user role, a confidentiality level, a usage scenario description, a validity period description, and an operation description.

[0048] Grassroots departments generate a wide variety of data11. Using this data, when appropriate, can effectively support decision-making, service delivery, and emergency management. For example, community health centers store resident health records, vaccination records, and chronic disease management information. These data are used for annual health checkups, emergency medical services, or responding to public health events (such as epidemic outbreaks). This is crucial for improving the efficiency of resident health management, rapidly responding to public health crises, and optimizing the allocation of medical resources.

[0049] Police stations store crime reports, security surveillance footage, and population movement information. These data are used during public safety incidents, criminal investigations, and security for large-scale events. This data can enhance public safety capabilities, speed up case detection, and ensure social stability and harmony. Civil affairs departments store records of social assistance applications, marriage registrations, and service needs for the elderly and disabled. These data are used to review social welfare eligibility, organize community activities, and provide customized services for specialized groups. This improves the accuracy of social welfare disbursements, strengthens community cohesion, and enhances the quality of life for vulnerable groups.

[0050] In order to enable the data 11 to be used in appropriate scenarios and to prevent the data 11 from being leaked, appropriate rights management is required. By managing the rights of the data 11, the data 11 can be shared with users 20 who need to use it, while ensuring the privacy and security of the data 11.

[0051] In this embodiment, on the platform 10 corresponding to each grassroots department that generates data 11, a static permission description 12 is associated with each field of the data 11 to implement field-level permission management. For example, the static permission description 12 of the community resident health record is: Department: Community Health Service Center, User Role: Community Doctor, Community Nurse, Grid Member, Confidentiality Level: Privacy Level, Usage Scenario Description: Accessible only when conducting annual health check-ups, emergency medical treatment, and medical subsidy registration, Validity Period Description: Estimated business duration + 2 hours buffer, Operation Description: Reading and updating are allowed, downloading or forwarding is prohibited. It indicates that the community resident health record belongs to the privacy level, and the usage scenario limits the data 11 to be used only in this scenario. And the role of the user 20 who can apply to use the data 11 is limited by the use of roles. As another example, the static permission description 12 of the community neighborhood dispute mediation record is: Department: Police Station, User Role: Grid Worker, Police Officer, Confidentiality Level: Internal, Usage Scenario Description: Used when handling neighborhood dispute incidents, Validity Period Description: Estimated business duration + 2 hours buffer, Operation Description: Reading and adding are allowed, modification, downloading or forwarding is prohibited. The confidentiality levels include privacy level, internal level and public level, and the level relationship is privacy level> internal level> public level. For example, the community director has a privacy-level requester permission level, and he can match more usage scenario descriptions, so he can view almost all the data 11. The community doctor also has a privacy-level requester permission level, but the usage scenario descriptions he can match are concentrated on medical matters, so it can be controlled that the community doctor only has the highest level of viewing permission for the scenario matched in scenarios involving health management and medical assistance.

[0052] Step S2) When any platform 10 receives an event ticket 21 or a collaboration application sent by a user 20, it obtains a request data result set according to the search formula carried in the event ticket 21 or the collaboration application.

[0053] The event ticket 21 or collaboration request submitted by user 20 must include clear search criteria, describing the specific characteristics of the required data 11. These criteria include the community involved, the personnel involved, the specific usage scenario (e.g., fire safety control), the desired validity period, and the specific operation type (e.g., read). The scenario recognition engine within platform 10 parses event ticket 21 or collaboration request, extracting its core elements using natural language processing (NLP) technology and converting them into executable query instructions. For example, if event ticket 21 mentions "Fire safety hazard inspection for shared rental housing in XX community," platform 10 will recognize this as a scenario related to "fire safety control." It will also retrieve registration information for all shared rental housing in that community, including property location, landlord registration information, tenant registration information, and historical fire hazard inspection records.

[0054] Step S3) Identify the current scenario, the requester's department, the requester's role, and the requester's authority level based on the event work order 21 or the collaboration application.

[0055] The method for identifying the current scenario, the requester's department, the requester's role, and the requester's authority level based on the event work order 21 or the collaboration application includes:

[0056] Parsing the meta-information contained in the event work order 21 or the collaboration application to obtain the scenario label, applicant identifier, and organizational structure path;

[0057] Query the user database accessed based on the applicant ID to obtain the applicant's department, job level, and job role;

[0058] Obtaining the role of the requester based on the job hierarchy, and obtaining the permission level of the requester based on a pre-stored job role-permission level mapping;

[0059] An attempt is made to identify the business type, process stage, and task description carried in the event work order 21 or collaboration application, and the current scenario is identified based on the preset scenario classification.

[0060] First, the metadata contained in Incident Ticket 21 or the collaboration request must be parsed to extract essential information, such as the scenario label, applicant ID, and organizational structure path. Text analysis techniques (such as the TextCNN model) are used to parse the content of Incident Ticket 21 or the collaboration request, extracting key information, such as "the keyword 'flood prevention' matches the 'emergency rescue' scenario," and identifying the applicant ID and organizational structure path.

[0061] Then, the database of the query platform 10 is searched in the connected user database based on the extracted applicant ID to obtain detailed information of the applicant, including their department, job level and job role. The extracted applicant ID is used as a query condition to find the corresponding information in the user database.

[0062] The roles and permission levels are then determined. The requester's role is determined based on the obtained job hierarchy, and the requester's permission level is determined using a pre-stored job-role-permission-level mapping table. The job hierarchy directly derives the requester's role within the organization, such as "grid worker" or "community director." Using the pre-set job-role-permission-level mapping, each role is assigned a corresponding permission level. For example, the permission level of "community director" may allow access to more sensitive information.

[0063] Finally, we implement business type and scenario identification, attempting to identify the business type, process stage, and task description carried in Event Ticket 21 or Collaboration Application. Based on the preset scenario classification rules, we ultimately identify the current specific scenario. We further analyze the business type, process stage, and task description in Event Ticket 21 or Collaboration Application, and use the preset scenario classification rules to identify the current work scenario. If the application involves a query for "vaccination records," it can be classified as a public health management scenario; if it is about "checking for safety hazards in shared rental housing," it falls under a public safety management scenario.

[0064] Step S4) traverses the fields included in the request data result set, compares the static permission description 12 of the field with the requester's department, requester's role and requester's permission level, and obtains a static permission data set.

[0065] The method of comparing the static permission description 12 of the field with the requester's department, the requester's role, and the requester's permission level to obtain a static permission data set includes:

[0066] The department, user role, and confidentiality level in the static permission description 12 of each field are compared with the requester's department, requester role, and requester permission level to obtain matching fields;

[0067] According to the matched fields, a static permission data set is obtained from the request data result set.

[0068] The system traverses the entire request data result set and checks the static permission description 12 for each field. The static permission description 12 for each field (including department, user role, and confidentiality level) is compared with the requester's department, role, and permission level. For each field, the system compares the "department," "user role," and "confidentiality level" in its static permission description 12 with the requester's "requester department," "requester role," and "requester permission level," respectively.

[0069] For example, if the static permission description 12 of a field is: "Department - Community Health Service Center; User Role - Medical Consultant; Confidentiality Level - Privacy Level", and the requester happens to be a "Medical Consultant" of the "Community Health Service Center" and has the permission level of "Privacy Level", then the field is considered to be matched successfully.

[0070] Through comparison, the fields that meet the requester's permission conditions are identified, that is, the data fields that the requester can access. According to the successfully matched fields, the corresponding data 11 is extracted from the request data result set to form a static permission data set. The static permission data set contains the specific data fields that all requesters have permission to access in the current scenario, ensuring the security and compliance of data 11. Achieving precise control over access to data 11 not only ensures the security of data 11, but also improves the efficiency of data 11 use. The fine-grained permission management mechanism provided in this embodiment is particularly suitable for grassroots multi-platform 10 data collaborative governance environments, which helps to improve the overall social governance level and service quality.

[0071] Step S5) Compare the static permission description 12 of the field with the current scenario to obtain a dynamic permission data set and validity period.

[0072] The method of comparing the static permission description 12 of the field with the current scenario to obtain a dynamic permission data set and validity period includes:

[0073] Read the pre-established scene permission mapping table;

[0074] Compare the current scene with the scene permission mapping table to obtain a dynamic permission field set;

[0075] Obtaining a dynamic permission data set from the request data result set according to the dynamic permission field set;

[0076] Obtain the validity period according to the current scenario and the validity period description.

[0077] The system has a built-in scenario permission mapping table that records the permission relationships between different business scenarios and accessible fields. Table 1 shows a scenario permission mapping table in this embodiment. The scenario permission mapping table is preset by the administrator based on actual business needs and is an important basis for dynamic permission determination.

[0078] Table 1 A scene permission mapping table in this embodiment

[0079] Scene Name Allow access to a list of fields Operational restrictions Emergency rescue Resident contact information, residential address, emergency contact Read only Epidemic prevention and control Health code status, vaccination status, travel history Readable and writable Allocation of educational resources Number of students, class distribution, and teacher allocation View statistics only

[0080] The current scenario identified in step S3 (e.g., "epidemic prevention and control") is matched with the entries in the scenario permission mapping table to extract the set of data fields permitted for access under that scenario, known as the "dynamic permission field set." For example, if the current scenario is "epidemic prevention and control," the dynamic permission field set includes "health code status, vaccination status, and travel history." From the obtained complete request data result set, the field data 11 belonging to the aforementioned "dynamic permission field set" is filtered out to form the "dynamic permission data set."

[0081] Each scenario typically corresponds to a preset validity period policy. For example, the estimated service duration for the emergency rescue scenario is 72 hours, the estimated service duration for the epidemic prevention and control scenario is the same day, and the estimated service duration for the education resource allocation scenario is daily from June to August. The validity period of the access permission is determined based on the rules defined in the scenario permission mapping table and the estimated service duration of the field itself, and a time-limited permission token is generated.

[0082] For example, in a case involving incident work order 21 involving "Community Flood Prevention Emergency Response," platform 10 identifies the current scenario as "Emergency Rescue." By comparing the scenario permission mapping table, the system determines that accessible fields in this scenario include "Resident Contact Information, Residential Address, and Building Structure Grade." These fields are extracted from the request data result set to form a dynamic permission dataset. Based on the pre-set rules for the "Emergency Rescue" scenario, the validity period of this access permission is set to 72 hours + 2 hours.

[0083] The scenario-driven dynamic permission control mechanism not only improves the security of data access, but also enhances the system's adaptability to complex grassroots governance scenarios. By combining static permissions with dynamic scenarios, it ensures the compliance of data use while avoiding abuse of permissions and long-term residual problems, providing solid support for building an efficient, secure, and intelligent grassroots governance system.

[0084] Step S6) performing conflict check on the static permission data set and the dynamic permission data set to obtain a permission set, and generating a permission token according to the permission set and the validity period.

[0085] The method of performing conflict check on the static permission data set and the dynamic permission data set to obtain a permission set, and generating a permission token according to the permission set and the validity period includes:

[0086] When a field in the dynamic permission dataset does not exist in the static permission dataset, the permission of the field is set to read-only permission;

[0087] Obtaining a permission set according to the dynamic permission data set after resetting the permissions;

[0088] Generate an authorization token based on the authorization set and the validity period.

[0089] Comparing fields in static and dynamic permission datasets, if a field exists in the dynamic permission dataset but not in the static permission dataset, this indicates that while the field meets the current scenario requirements, access to it is not authorized in the basic permission configuration. For such fields, the default permission is set to read-only, allowing viewing but not modification or downloading, to meet business needs while controlling risks.

[0090] For example, a field called "Resident Health Code Status" is readable and writable under dynamic permissions but fails static permission review. If the requester's role permissions are insufficient, its permissions are automatically adjusted to read-only and an expiration date is set. Viewing is no longer permitted after the expiration date. A permission set is obtained based on the dynamic permission data set after the permissions have been reset. After conflict resolution, the system merges all fields, including the original static matching fields and the adjusted dynamic fields, to form a permission set. The permission set includes each field's access type (e.g., read, write), operation restrictions (e.g., prohibit export), applicable scenarios, and expiration date. Based on this permission set and the expiration date determined in step S5, the system generates a structured permission token. For example, the permission token uses an encrypted format (e.g., JWT) to store the following information: the requester's identity, a list of fields allowed to be accessed and their operation permissions, scenario tags, validity start and end times, and signature information for tamper-proof verification.

[0091] For example, the generated authorization token may contain the following information fragments:

[0092] json

[0093] {

[0094] "user_id": "U20250521",

[0095] "allowed_fields": [

[0096] {"field_name": "Resident contact information", "operation": "read"},

[0097] {"field_name": "Housing Structure Grade", "operation": "read"}

[0098] ],

[0099] "scene": "Flood emergency response",

[0100] "valid_from": "2025-05-21T17:00:00Z",

[0101] "valid_to": "2025-05-24T17:00:00Z",

[0102] "signature": "xxx"

[0103] }

[0104] The conflict verification mechanism ensures the consistency of permission logic and avoids unauthorized access due to dynamic expansion. The permission token has the characteristics of standardization, structuring, and auditability. It can be transferred and used across platforms10. The fine-grained control based on scenarios and time makes data sharing in grassroots governance more flexible, secure, and controllable. The permission token is combined with technologies such as blockchain to achieve full-process traceability and post-audit to meet regulatory compliance requirements.

[0105] Step S7) User 20 uses the authorization token and data search formula to retrieve data from platform 10. Platform 10 responds with data and logs it, storing the logs on a blockchain at a predetermined interval. Logs are batch processed at predetermined intervals, such as daily or weekly, and stored immutably using blockchain technology.

[0106] Step S8) The platform 10 revokes the permission token based on the expiration of the validity period, the completion of the current scenario, or abnormal query behavior by user 20. To avoid security risks caused by prolonged retention of permissions, the platform supports a multi-dimensional permission revocation mechanism to ensure that permissions expire promptly at the appropriate time. The system has a built-in scheduled task or event listener to continuously monitor all issued permission tokens. When the "validity expiration date" of a permission token is detected, the system automatically marks it as "expired" and removes it from the available permission pool. The relevant log status is also updated to record the reason for the revocation. During the collaborative process, if an event ticket 21 or collaboration request is marked as "completed," "canceled," or "timed out," the scenario is considered complete, and the associated permission token is immediately revoked. The platform 10 integrates a behavioral analysis module to monitor user 20's access behavior patterns in real time. If abnormal behavior is detected by user 20, such as frequent queries, access to unauthorized fields, or attempts to export large amounts of sensitive data, the system will initiate the permission revocation process. AI models can be combined with behavioral modeling and anomaly detection to improve recognition accuracy.

[0107] In another aspect, the method further includes dynamically and proactively allocating an authority token, and the method for dynamically and proactively allocating an authority token includes:

[0108] Monitor the status of collaborative application processes between platforms 10 and the triggering of preset external events;

[0109] Obtain sample data by manually annotating the collaborative application process status and the associated required data sets and potential requesters when a preset external event is triggered;

[0110] Establish and use the sample data to train a machine learning model to obtain an active allocation model;

[0111] Obtain the required data set and potential requesters based on the status of the collaborative application process between the platforms 10 and the triggering of preset external events as monitored by the active allocation model;

[0112] Generate an authorization token corresponding to the required data set for the potential requester and notify the potential requester.

[0113] Continuously track the status changes of data sharing requests and collaboration applications across the 10 platforms, as well as specific external events such as emergencies and scheduled tasks, to trigger the dynamic and proactive allocation of permission tokens. For example, when faced with sudden floods or heavy rain warnings, local governments need to quickly organize a multi-departmental coordinated response, including data sharing and collaboration among water conservancy, meteorology, public security, civil affairs, and other departments. Traditional permission management methods often delay the optimal response due to cumbersome approval processes. Monitor the status of the collaboration application process across the 10 platforms and the triggering of preset external events, monitor heavy rain warning information (external events) issued by the weather forecast system in real time, and track the status of the collaboration application process between departments. For example, when an orange heavy rain warning is issued in a certain area, the system automatically identifies this as a "flood prevention emergency" scenario and begins preparing for relevant permission adjustments.

[0114] In previous flood prevention efforts, administrators would record which departments, such as the Water Resources Bureau and the Public Security Bureau, needed access to specific types of data, such as river water levels and evacuation route maps, as well as the roles of those accessing this data, such as flood control commanders and on-site rescue personnel. This constituted sample data for training machine learning models. Using this sample data, a machine learning model was trained to predict which datasets would be needed and who would be potential data requesters, based on the characteristics of the current flood event, such as the warning level and impact area. The model was optimized through multiple iterations to ensure it accurately predicted needs in different scenarios. When a new heavy rain warning was triggered, the system utilized the trained proactive allocation model for analysis. Suppose the proactive allocation model predicted that technicians from the Water Resources Bureau might need access to the latest river level monitoring data to develop an emergency drainage plan, while staff from the Public Security Bureau might need to obtain community floor plans to plan evacuation routes. Platform 10 automatically generated permission tokens for the Water Resources Bureau technicians and Public Security Bureau staff, granting them access to the required datasets for a limited time. The relevant personnel were notified via SMS or internal messaging that access had been granted and provided with instructions on how to quickly locate and use the data. By assigning permissions in advance, relevant departments and technical personnel can immediately access key data without waiting for formal approval, thereby speeding up decision-making.

[0115] On the other hand, this manual provides a multi-platform data collaborative governance authority dynamic control system, please refer to the attached Figure 4 ,include:

[0116] The marking module 100, each platform 10 marks each field of the data with a static permission description 12, wherein the static permission description 12 includes a department, a user role, a confidentiality level, a usage scenario description, a validity period description, and an operation description;

[0117] Retrieval module 200, when any platform 10 receives an event ticket 21 or a collaboration request sent by a user 20, obtains a request data result set according to the search formula carried by the event ticket 21 or the collaboration request;

[0118] The identification module 300 identifies the current scenario, the requester's department, the requester's role, and the requester's authority level based on the event work order 21 or the collaboration request;

[0119] The first comparison module 400 traverses the fields included in the request data result set, compares the static permission description 12 of the field with the requester's department, requester's role, and requester's permission level, and obtains a static permission data set;

[0120] The second comparison module 500 compares the static permission description 12 of the field with the current scenario to obtain a dynamic permission data set and validity period;

[0121] A verification module 600 performs conflict verification on the static permission data set and the dynamic permission data set to obtain a permission set, and generates a permission token based on the permission set and the validity period;

[0122] Execution module 700: User 20 uses the permission token and data search formula to obtain data from platform 10. Platform 10 records the data feedback and logs it, and stores the logs on blockchain according to a preset period.

[0123] The monitoring module 800, the platform 10 reclaims the permission token based on the expiration of the validity period, the triggering of the current scenario completion event, or the triggering of abnormal query behavior of the user 20.

[0124] See also Figure 5 A schematic structural diagram of an electronic device provided in an embodiment of this specification is shown.

[0125] like Figure 5As shown, the electronic device 1100 may include: at least one processor 1101, at least one network interface 1104, a user interface 1103, a memory 1105, and at least one communication bus 1102. The communication bus 1102 may be used to implement communication between the aforementioned components. The user interface 1103 may include buttons, and optionally may also include a standard wired interface or a wireless interface. The network interface 1104 may include, but is not limited to, a Bluetooth module, an NFC module, a Wi-Fi module, etc. The processor 1101 may include one or more processing cores. The processor 1101 utilizes various interfaces and circuits to connect the various components within the entire electronic device 1100. By running or executing instructions, programs, code sets, or instruction sets stored in the memory 1105 and accessing data stored in the memory 1105, it performs various functions of the routing device 1100 and processes data. Optionally, the processor 1101 may be implemented in hardware using at least one of a DSP, an FPGA, and a PLA. The processor 1101 may integrate one or a combination of a CPU, a GPU, and a modem. The CPU primarily processes the operating system, user interface, and applications; the GPU is responsible for rendering and drawing content displayed on the display; and the modem handles wireless communications.

[0126] It is understandable that the above-mentioned modem may not be integrated into the processor 1101, but may be implemented by a separate chip.

[0127] Memory 1105 may include either RAM or ROM. Optionally, memory 1105 may include non-transitory computer-readable media. Memory 1105 may be used to store instructions, programs, codes, code sets, or instruction sets. Memory 1105 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, sound playback function, image playback function, etc.), instructions for implementing the aforementioned method embodiments, etc.; the data storage area may store data related to the aforementioned method embodiments, etc. Memory 1105 may also optionally be at least one storage device located remotely from the aforementioned processor 1101. Memory 1105, as a computer storage medium, may include an operating system, a network communication module, a user interface module, and application programs. Processor 1101 may be configured to invoke the application programs stored in memory 1105 and execute the methods described in the aforementioned embodiments.

[0128] The embodiments of this specification also provide a computer-readable storage medium having instructions stored therein that, when executed on a computer or processor, cause the computer or processor to perform the steps of the aforementioned embodiments. If the components of the aforementioned electronic device are implemented as software functional units and sold or used as independent products, they may be stored in the computer-readable storage medium.

[0129] The embodiments of this specification also provide a computer program product, including a computer program, which implements multiple steps in the above embodiments when executed by a processor.

[0130] In the absence of conflict, the technical features in this embodiment and implementation scheme can be combined arbitrarily.

[0131] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product comprises multiple computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium accessible by a computer or a data storage device such as a server or data center that integrates multiple available media. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state drive (SSD)).

[0132] When implemented via hardware or firmware, the aforementioned method flow is programmed into the hardware circuit to obtain the corresponding hardware circuit structure and realize the corresponding function. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit, whose logical function is determined by the user's device programming. Designers can integrate a digital system into a PLD by programming themselves, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, today, instead of manually manufacturing integrated circuit chips, this programming is mostly performed using logic compiler software. This is similar to the software compiler used in program development. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There are not just one HDL, but many types. Those skilled in the art will also understand that by simply programming the method flow in one of the aforementioned hardware description languages ​​and programming it into the integrated circuit, a hardware circuit that implements the logical method flow can be easily obtained.

[0133] The embodiments described above are merely preferred embodiments of this specification and are not intended to limit the scope of this specification. Without departing from the design spirit of this specification, various modifications and improvements made to the technical solutions of this specification by ordinary technicians in this field should fall within the scope of protection determined by the claims of this specification.

Claims

1. A method for dynamic control of multi-platform data collaborative governance authority, characterized in that: Including steps: Each platform marks each field of the data with a static permission description, which includes department, user role, confidentiality level, usage scenario description, validity period description, and operation description; When any platform receives an event ticket or collaboration request sent by a user, it obtains the requested data result set based on the search formula carried by the event ticket or collaboration request; Identify the current scenario, requester department, requester role, and requester authority level based on the event work order or collaboration request; Traversing the fields included in the request data result set, comparing the static permission description of the field with the requester's department, requester's role, and requester's permission level to obtain a static permission data set; Compare the static permission description of the field with the current scenario to obtain a dynamic permission data set and validity period; Performing conflict check on the static permission data set and the dynamic permission data set to obtain a permission set, and generating a permission token based on the permission set and the validity period; The user uses the permission token and data search formula to obtain data from the platform, and the platform records the feedback data in a log, and uses the blockchain to store the log at a preset period; The platform reclaims the permission token based on the expiration of the validity period, the triggering of the current scenario completion event, or the triggering of abnormal query behavior of the user; The method of obtaining a static permission data set by comparing the static permission description of the field with the requester's department, the requester's role, and the requester's permission level includes: For each field, the department, user role, and confidentiality level in the static permission description are compared with the requester's department, requester role, and requester permission level to obtain matching fields. Obtaining a static permission data set from the request data result set according to the matched fields; The method of comparing the static permission description of the field with the current scenario to obtain a dynamic permission dataset includes: Read the pre-established scene permission mapping table; Compare the current scene with the scene permission mapping table to obtain a dynamic permission field set; The method of performing conflict check on the static permission data set and the dynamic permission data set to obtain the permission set includes: When a field in the dynamic permission data set does not exist in the static permission data set, the permission of the field is set to read-only permission.

2. The multi-platform data collaborative governance authority dynamic control method according to claim 1 is characterized in that: The method for identifying the current scenario, the requester's department, the requester's role, and the requester's authority level based on the event work order or collaboration application includes: Parsing the meta-information contained in the event work order or collaboration application to obtain the scenario label, applicant identifier, and organizational structure path; Query the user database accessed based on the applicant ID to obtain the applicant's department, job level, and job role; Obtaining the role of the requester according to the job level, and obtaining the permission level of the requester according to the pre-stored position role permission level mapping; Try to identify the business type, process stage, and task description carried in the event work order or collaboration application, and identify the current scenario based on the preset scenario classification.

3. The multi-platform data collaborative governance authority dynamic control method according to claim 1 is characterized in that: Methods for obtaining validity periods include: Obtaining a dynamic permission data set from the request data result set according to the dynamic permission field set; Obtain the validity period according to the current scenario and the validity period description.

4. The multi-platform data collaborative governance authority dynamic control method according to claim 1 or 2 is characterized in that: The method for generating a permission token according to the permission set and the validity period includes: Obtaining a permission set according to the dynamic permission data set after resetting the permissions; Generate an authorization token based on the authorization set and the validity period.

5. The multi-platform data collaborative governance authority dynamic control method according to claim 1 is characterized in that: The method further includes dynamically and proactively allocating a permission token, and the method for dynamically and proactively allocating a permission token includes: Monitor the status of collaborative application processes between platforms and the triggering of preset external events; Obtain sample data by manually annotating the collaborative application process status and the associated required data sets and potential requesters when a preset external event is triggered; Establish and use the sample data to train a machine learning model to obtain an active allocation model; Obtain the required data set and potential requesters based on the active allocation model based on the status of the collaborative application process between platforms and the triggering of preset external events; Generate an authorization token corresponding to the required data set for the potential requester and notify the potential requester.

6. A multi-platform data collaborative governance authority dynamic control system, characterized by: include: The annotation module, each platform annotates each field of the data with a static permission description, which includes the department, user role, confidentiality level, usage scenario description, validity period description and operation description; The search module, when any platform receives an event ticket or collaboration request sent by a user, obtains the requested data result set according to the search formula carried by the event ticket or collaboration request; An identification module identifies the current scenario, the requester's department, the requester's role, and the requester's authority level based on the event work order or collaboration request; A first comparison module traverses the fields included in the request data result set, compares the static permission description of the field with the requester's department, requester's role, and requester's permission level, and obtains a static permission data set; A second comparison module compares the static permission description of the field with the current scenario to obtain a dynamic permission data set and validity period; a verification module, performing conflict verification on the static permission data set and the dynamic permission data set to obtain a permission set, and generating a permission token based on the permission set and the validity period; In the execution module, the user uses the permission token and data search formula to obtain data from the platform, and the platform records the feedback data in a log, and stores the log in a blockchain according to a preset period; A monitoring module, wherein the platform reclaims the permission token based on the expiration of the validity period, the completion of the current scenario, or abnormal query behavior of the user; The method of obtaining a static permission data set by comparing the static permission description of the field with the requester's department, the requester's role, and the requester's permission level includes: For each field, the department, user role, and confidentiality level in the static permission description are compared with the requester's department, requester role, and requester permission level to obtain matching fields. Obtaining a static permission data set from the request data result set according to the matched fields; The method of comparing the static permission description of the field with the current scenario to obtain a dynamic permission dataset includes: Read the pre-established scene permission mapping table; Compare the current scene with the scene permission mapping table to obtain a dynamic permission field set; The method of performing conflict check on the static permission data set and the dynamic permission data set to obtain the permission set includes: When a field in the dynamic permission data set does not exist in the static permission data set, the permission of the field is set to read-only permission.

7. An electronic device, characterized in that: including a processor and a memory; The processor is connected to the memory; The memory is used to store executable program code; The processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, so as to execute the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

9. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

Images