Permission data management method for conference terminal

Abstract

The invention relates to the technical field of data management, in particular to a permission data management method for a conference terminal, which comprises the following steps of: performing identity recognition and permission initialization operation on participants in the conference terminal; after identity recognition and authority initialization operation are carried out, multi-modal behavior information and conference dynamic context information of participants are collected in real time; constructing a behavior vector according to the multi-modal behavior information and the conference dynamic context information, and constructing an input pair in combination with the behavior vector and the conference context block; identifying whether the current user has a potential permission request intention or not according to the input pair, and outputting a structured permission request vector; performing decision-making auditing on the permission request vector, and outputting an auditing result vector; inputting the audit result vector into a conference terminal interface, and outputting an interface control action set and a permission state copy through the conference terminal interface; and constructing a structured authority auditing entry based on the interface control action set and the authority state copy, and writing the authority auditing entry into a system auditing database.

Description

Technical Field

[0001] This invention relates to the field of data management technology, and more particularly to a method for managing access data in a conference terminal. Background Technology

[0002] With the increasing prevalence of government office work, enterprise collaboration, and remote video conferencing systems, conference terminals, as the core carriers of information display and interactive control, undertake key functions such as data access, document distribution, identity authentication, and interface management. In practical use, conference terminals often need to serve a group of participants with multiple roles and multiple permission levels, such as hosts, ordinary participants, and external guests. How to achieve effective, flexible, and secure access control for different roles has become crucial to improving meeting efficiency and information security.

[0003] Existing conference terminal systems generally employ a role-based static permission management model. Typically, during the meeting initialization phase, user identity is confirmed via NFC identification or account login, and fixed permissions are granted based on their preset roles, such as permission to view the meeting agenda, access documents, and control screen projection. However, this approach has significant shortcomings. First, permission allocation lacks dynamic responsiveness. During actual meetings, as the agenda progresses, speaking order changes, or roles are temporarily adjusted, participants often have periodic permission change requests. Current systems cannot automatically identify such requests, requiring manual intervention, resulting in a sluggish and inefficient process. Second, the permission adjustment process usually lacks a reliable and auditable recording mechanism. In the event of misallocation of permissions, information leakage, or unauthorized access, the system struggles to provide effective log traceability or accountability, severely impacting system security and compliance. Third, traditional permission management models are disconnected from meeting behavior. The system cannot dynamically determine permissions based on user speech content and interactive behavior during the meeting, leading to a severe mismatch between permission configuration and actual tasks, affecting user experience and meeting smoothness.

[0004] Therefore, current access control methods mainly suffer from three key problems: (1) static and rigid access configuration, lacking the ability to dynamically adjust in stages and driven by behavior; (2) poor transparency of access control processes, making it impossible to achieve auditable and traceable security records; and (3) disconnect between access allocation and real-time user behavior, failing to meet the needs for personalized and intelligent access control in complex meeting scenarios. These problems are particularly prominent in meeting scenarios with high requirements for information confidentiality, decision-making accuracy, and user agility, becoming the main obstacles to the intelligent and secure development of meeting terminal systems. Summary of the Invention

[0005] To address the aforementioned problems, this invention provides a permission data management method for conference terminals, which solves the problems described in the background section.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] Methods for managing access control data for conference terminals include:

[0008] S1: Perform identity verification and permission initialization operations on the participants in the conference terminal;

[0009] S2: After performing identity verification and permission initialization operations, collect multimodal behavioral information of participants and dynamic contextual information of the meeting in real time;

[0010] S3: Construct behavior vectors based on multimodal behavior information and dynamic contextual information of the meeting, and construct input pairs by combining behavior vectors and meeting context blocks;

[0011] S4: Based on the input, identify whether the current user has a potential intent to request permissions, and output a structured permission request vector;

[0012] S5: Review and approve the permission request vector and output the review result vector;

[0013] S6: Input the audit result vector into the conference terminal interface, and output the interface control action set and permission status copy through the conference terminal interface;

[0014] S7: Construct structured permission audit entries based on the interface control action set and permission status copy, and write the permission audit entries into the system audit database.

[0015] Preferably, S1 includes:

[0016] S1.1: Read the card using the NFC card reader integrated into the conference terminal and identify the user's unique identification code on the card;

[0017] S1.2: The conference terminal queries the conference role bound to the identification code through the built-in conference organization information interface;

[0018] S1.3: Perform permission initialization operations based on the meeting roles.

[0019] Preferably, the S2 comprises:

[0020] S2.1: The conference terminal collects user speech information and interaction actions through the voice channel and the interface interaction channel respectively, and encodes the interaction actions in a unified manner;

[0021] S2.1: Input the user's speech information into the ASR engine, and output a phrase fragment with a timestamp through the ASR engine.

[0022] Preferably, S3 includes:

[0023] S3.1: Obtain multimodal behavioral information and dynamic contextual information of the participants;

[0024] S3.2: The terminal system aggregates multimodal behavioral information and dynamic contextual information of the meeting according to a fixed sliding window, constructs a behavioral vector under the time window, and introduces a permission conflict penalty term into the behavioral vector;

[0025] S3.3: Combine the behavior vector and the meeting context block to construct the input pair.

[0026] Preferably, the behavior vector expression in S3.2 is:

[0027] B(t) = concat(encode) s (S t-T:t )+λ1·ψ(L s ),encode a (A t-T:t )+λ2·φ(P0,A t-T:t ));

[0028] Where B(t) is the action vector; encode s (S t-T:t The text is embedded using 32-dimensional word vectors within a T-second timeframe, and then average pooled; ψ(L s () is a sensitive word activation counting function, representing the frequency of triggering unauthorized keywords within this time window;

[0029] λ1 is a sensitive behavior incentive factor used to amplify overstepping semantics; encode a (A t-T:t ) represents the multi-hot encoding aggregation of interactive behaviors; φ(P0,A) t-T:t ) is the permission conflict function; λ2 is the behavior permission conflict penalty factor.

[0030] Preferably, S4 includes:

[0031] S4.1: Input the behavior vectors from the input pairs into a three-layer bidirectional GRU sequence modeler and extract the behavior time series feature vectors;

[0032] S4.2: Simultaneously embed the structured context variables in the meeting context block into a context vector;

[0033] S4.3: Construct a comprehensive vector from the behavioral time series feature vector and the context vector through a gating fusion module;

[0034] S4.4: Input the comprehensive vector into a projection function with a special regularization term, and output the request confidence level of each permission through the projection function;

[0035] S4.5: Construct a permission request vector based on the requested confidence level.

[0036] Preferably, the permission request vector expression in S4.5 is:

[0037] P req =σ(W·Z(t)+α·Γ(Z(t),P0));

[0038] Z(t)=GRU(B(t))||Embed(C(t));

[0039] Where P req Z(t) is the permission request vector; Z(t) is the concatenation and fusion function of behavior and context; W is the projection weight matrix; σ(·) is the Sigmoid function, which outputs the request confidence of each permission; Γ(Z(t),P0) is the regularization function; α is the weight factor, which controls the incentive degree of Γ terms; C(t) is the meeting block.

[0040] Preferably, S7 includes:

[0041] S7.1: Assemble the set of interface control actions and permission status copies into structured permission audit entries using structured functions;

[0042] S7.2: Calculate the offset of the permission audit entry, write the permission audit entry and offset into the local permission audit database, and push it to the cloud security log center.

[0043] Preferably, the behavior vector in S3 includes the behavior context vectors of voice text, interactive behavior, and overriding signals.

[0044] Preferably, the meeting context block in S3 includes the current meeting stage, speaker identity, shared resource status, and permission tags.

[0045] The beneficial effects of this invention are as follows:

[0046] 1. This invention proposes a permission data management method for conference terminal scenarios that supports dynamic adjustment and multi-level response mechanisms. Based on identity recognition, this method combines the time sequence information and user behavior data during the conference process to achieve real-time perception, intelligent judgment and hierarchical adjustment of permissions, ensuring that permission configuration can accurately reflect the real task needs and behavioral intentions of the participants at specific stages.

[0047] 2. By constructing a permission decision-making chain, this invention introduces a verifiable permission adjustment process while ensuring the rationality of the basic permission division. This process not only supports participants to make permission change requests based on actual behavior, but also automatically determines permissions based on meeting context, role information, and policy rules, and securely records all permission operation processes. Thus, while maintaining operational efficiency, it provides comprehensive auditing capabilities and post-event traceability. Attached Figure Description

[0048] Figure 1 This is a flowchart of the permission data management method in a specific embodiment of the present invention;

[0049] Figure 2 This is a flowchart of the identity recognition and permission initialization operation in a specific embodiment of the present invention;

[0050] Figure 3 A flowchart for constructing input pairs in a specific embodiment of the present invention;

[0051] Figure 4 This is a flowchart illustrating the generation of permission request vectors in a specific embodiment of the present invention;

[0052] Figure 5 This is a block diagram illustrating the composition of behavior vectors in a specific embodiment of the present invention;

[0053] Figure 6 This is a block diagram showing the composition of the meeting context block in a specific embodiment of the present invention. Detailed Implementation

[0054] Please see Figures 1-6 As shown, the present invention relates to a method for managing access data for a conference terminal, which specifically includes the following:

[0055] Step 1: Identity Verification and Permission Initialization

[0056] Step Overview: This step is responsible for identifying participants and initializing their permissions in the conference terminal, serving as the starting point for the entire permission management system. Its main task is to generate a structured initial permission state P0 at the start of the conference, based on each participant's unique identifier (UID), combined with the conference's preset permission template and user role configuration. This permission vector will serve as the baseline input for subsequent behavior recognition and permission auditing modules, ensuring that dynamic adjustments to permissions are based on a unified and reliable starting point. This step emphasizes structured data processing and reusable design between systems, avoiding the use of runtime decision-making or unstable inference models.

[0057] enter:

[0058] Since this step is the starting point of the process, its input is the basic data source rather than the output of the previous step, and mainly includes:

[0059] UID: Read by the NFC card reader integrated into the conference terminal to identify the user's unique identifier code on the card. Before the conference, each participant's NFC card is bound to a unique user identifier in the backend system, and the bound data is stored in the enterprise management database. The identification process is completed within 1 second when the NFC card is brought close to the terminal, and a 16-byte hexadecimal encoded UID is returned.

[0060] Role: After reading the UID, the system queries the meeting role bound to the UID through the built-in meeting organization information interface, such as "host", "internal member", "external guest" etc. The query process is completed through the RESTful API and the personnel permission database, and the returned result is the role field in the JSON object.

[0061] T conf The meeting permission template, selected or customized by the meeting creator during schedule creation, is a structured data object that specifies the permission configuration items for various roles in this meeting. This template includes permission item fields (such as view agenda, view participants, view files, download files, control sharing) and corresponding role-level enabled boolean values.

[0062] For example, template T conf It contains the following structural segments:

[0063] "Host": {"view_agenda":1,"control_share":1,"access_files":1}

[0064] "Internal members": {"view_agenda":1,"control_share":0,"access_files":1}

[0065] "External Guests": {"view_agenda":1,"control_share":0,"access_files":0}

[0066] Step details:

[0067] After identity verification, the system obtains the UID and calls the internal interface get_role(UID) to return its Role. Then, based on this Role, it retrieves the value from T. conf Extract the corresponding field values ​​to form the user's permission vector P0 in this meeting. This process does not involve any judgment or reasoning, but only performs a fixed template table lookup operation to ensure consistency and transparency.

[0068] P0 = f map (Role,T conf );

[0069] Where: f map This represents a lookup-type mapping operation, which uses the string "Role" as an index to extract the value of "T". conf The corresponding set of permission fields;

[0070] Role is a role identifier string returned from the user permissions database, such as "host" or "internal member".

[0071] T conf It is a structured configuration template, specified when the meeting is created;

[0072] The output P0 is a fixed-length vector representing the user's permissions in the meeting, for example:

[0073] P0 = [1,1,0];

[0074] This indicates that the user has permission to view the agenda and files, but no permission to control sharing.

[0075] To facilitate a unified interface between system modules, all permission items in the system adopt a structure of "sequential field + binary bitmap", for example:

[0076] The first option is "View Agenda Permission" (v1);

[0077] The second option is "View participant permissions" (v2);

[0078] The third position is "Access File Permissions" (v3);

[0079] The fourth position is "Download File Permissions" (v4);

[0080] The fifth position is "Control sharing permissions" (v5);

[0081] ...Expandable terms are reserved up to the nth position (v) n ).

[0082] The entire P0 structure is arranged in [v1, v2, ..., v n The expression is represented by a Boolean value (0 or 1) for each bit, indicating whether the corresponding permission item is enabled or disabled.

[0083] To improve system versatility, all permission template items use a fixed length and do not dynamically change fields based on roles; role differences are only reflected in changes to field values. This approach allows for flexible configuration of permission templates across different meetings while ensuring consistency of permission fields across different terminals, facilitating deployment.

[0084] The final output of this step is two variables:

[0085] UID: Participant identification, used for annotation in the subsequent behavior collection phase;

[0086] P0: Structured permission vector, which is used directly by the subsequent permission intent judgment and permission review modules as a baseline state.

[0087] The core innovation of this step lies in using a three-dimensional binding model of "meeting scenario-role-permission template" to initialize user permissions: each meeting can use a different template, and even if the same user's role remains unchanged in different meetings, their permissions can adapt adaptively, providing high flexibility. At the same time, it avoids using dynamic models, making system behavior completely predictable and permission configuration controllable. Furthermore, the design of the structured permission vector P0 provides a basic interface standard for unified reference by subsequent modules, truly achieving automation, standardization, and reproducibility of permission initialization. This step strictly corresponds to the first link in the meeting terminal permission data management task, providing a reliable initial value and a unique identity foundation for the entire dynamic permission control system.

[0088] Step 2: Behavior Collection and Context Construction

[0089] The core task of this step is to collect multimodal behavioral information of participants in real time within the conference terminal environment and construct a structured contextual representation by combining it with dynamic conference context information. Unlike traditional systems that only record discrete user event logs, this solution, based on the core requirement of this patent, "dynamic management of conference terminal permission data," designs a multi-source synchronous acquisition mechanism and a context aggregation modeling method. This comprehensively captures the coupling relationship between user behavior and the conference environment and provides input to the permission intent recognition module in a structurally unified manner. In particular, when constructing behavior vectors, the solution introduces a specialized term for the "permission awareness" objective to strengthen the modeling of the behavior-permission correlation, reflecting the unique service capability of this step for the objectives of this patent.

[0090] The conference terminal runs a multi-threaded acquisition framework in real time, which is responsible for the audio channel and the interface interaction channel respectively:

[0091] The voice channel captures user speech via the terminal microphone array and inputs it to the local ASR engine. This engine employs a streaming bidirectional GRU-based speech recognition model, specifically a 6-layer model with 256 units per layer and a temporal attention mechanism. The output is a timestamped phrase segment, represented as (UID, t...). start ,t end The system transcribes the text into a vector L, where S is the transcribed text. After transcription, the system further performs "sensitive word annotation," annotating S based on the keyword list in the unauthorized items in P0, generating a word tag vector L. s It is used to help determine whether the current user is attempting to exceed their privileges.

[0092] The interface interaction channel is handled by the terminal UI event dispatcher, which collects interactive actions such as clicks, swipes, and document requests. The system uniformly encodes these actions; for example, "open meeting minutes" corresponds to code A1, and "click to share screen" is encoded as A2. The record structure is (UID, t...). event A k For actions involving permission boundaries (such as "downloading materials"), the system queries the corresponding bit in P0 in real time. If it is 0 (unauthorized), it automatically marks the action as "permission violation" for subsequent risk warnings.

[0093] After data collection, the system aggregates behaviors according to a fixed sliding window T (e.g., 30 seconds) to construct a behavioral context representation B(t) within the time window. To further enhance the ability to identify the intent of permission requests, the solution introduces an innovative mechanism: adding a "permission conflict penalty" to the context modeling, causing the model to pay more attention to suspected unauthorized operations. This mechanism is expressed as follows:

[0094] B(t) = concat(encode) s (S t-T:t )+λ1·ψ(L s ),encode a (A t-T:t )+λ2·φ(P0,A t-T:t ));

[0095] Where: encode s (S t-T:t This indicates that the speech text within T seconds is embedded using 32-dimensional word vectors and then averaged.

[0096] ψ(L s () is the "sensitive word activation counting function", which represents the frequency of triggering unauthorized keywords within this time window;

[0097] λ1 is a sensitive behavior incentive factor used to amplify the semantics of overstepping authority;

[0098] encode a (A t-T:t This represents the aggregation of multi-hot encodings for interactive behaviors;

[0099] φ(P0,A t-T:t ) is a "permission conflict function", which is used when a certain action A k If the corresponding P0 permission bit is 0, output 1; otherwise, output 0.

[0100] λ2 is the penalty factor for conflict of behavior permissions.

[0101] This structure enables the behavior vector B(t) to not only reflect the user's natural behavior pattern, but also to structurally enhance potential permission overreach behaviors, providing more discriminative feature inputs for the next step of intent recognition.

[0102] In addition, the system synchronously maintains the current meeting context block C(t), which includes the following fields: the current stage of the meeting (such as "open discussion" or "document presentation"), and the speaker's UID. m (Obtained through terminal voice energy ranking), the current shared document ID and its permission tag (simultaneously broadcast by the conference management module). This information, together with B(t), constitutes a complete behavior-context input pair.

[0103] This step outputs two variables:

[0104] B(t): A behavior context vector that integrates voice text, interactive behavior, and unauthorized signals. It has a fixed-length structure and is used to input the permission intent recognition module to the next step.

[0105] C(t): Meeting context state block, which records the meeting stage, speaker and resource status in a structured manner, providing contextual reference for intent judgment.

[0106] This step, taking into account the multimodal interaction characteristics of the conference terminal environment, designs a permission-aware behavior modeling mechanism that preserves the integrity of behavioral information while introducing sensitive modeling capabilities for unauthorized behaviors. In particular, the inclusion of ψ and φ function terms in the behavior vector construction represents a structural response to the security requirements of conference permissions, distinguishing it from the behavior modeling methods of general log systems. This design not only makes it easier for subsequent identification models to differentiate between ordinary operations and permission requests but also enhances the risk warning capability for unauthorized behaviors.

[0107] Step 3: Behavior-based authorization intent recognition

[0108] This step aims to identify whether the current user has a potential permission request intent based on the behavior vector B(t) constructed in the previous step and the meeting context C(t), and output a structured permission request vector P. req Unlike traditional systems that determine permission requests based on fixed interactive behaviors, this solution introduces a dynamic modeling mechanism that integrates behavioral semantics, role permission status, and meeting context, addressing key challenges such as "implicit expression of permission intent, ambiguous behavioral semantics, and complex contextual dependencies." This step is the most proactive step in this patented system, forming a crucial bridge from "behavior recognition" to "permission response." Its judgment result directly determines whether the system proceeds to the next step of permission review and interface adjustment.

[0109] This step uses all the outputs from step 2 as input:

[0110] B(t): represents the fusion vector of the user's speech semantics and interaction behavior sequence within a fixed window period in the past. The structure already includes semantic embedding, overweight feature encoding, etc.

[0111] C(t): Represents the current meeting context, including the current meeting stage and the speaker's identity (UID). m Contextual elements such as shared resource status;

[0112] In addition, this step also requires the user identity UID (from step 1) to bind the current intent vector to a specific user, ensuring the uniqueness of the data structure in a multi-user conference environment.

[0113] This step's design fully integrates the three key characteristics of meeting terminal permission management: the implicit nature of permission request behavior, the strong correlation between request intent and context, and the tension between request content and role permissions. Traditional permission judgment mechanisms based on clicks or keywords suffer from high false positive rates, response delays, and difficulty in covering unclear schematics in meeting scenarios. Therefore, this solution employs a structured, low-complexity, context-sensitive neural network model, combined with multiple specialized components, to achieve fine-grained modeling of permission intent.

[0114] The overall structure is as follows:

[0115] First, B(t) is input into a three-layer bidirectional GRU sequence modeler to extract behavioral time series features;

[0116] Simultaneously, the structured context variables (such as the current stage, speaker, shared state, etc.) in C(t) are embedded into the context vector E. c The embedding method uses multi-field embedding and splicing + one layer of fully connected network compression;

[0117] Then, the behavior encoding and context vector are combined through a gating fusion module to construct a comprehensive vector Z(t) to model the behavior-context joint signal;

[0118] Finally, the vector Z(t) is fed into a projection function with a special regularization term, and the output of the request confidence score for each permission constitutes P. req .

[0119] The key formula is:

[0120]

[0121] The explanation is as follows:

[0122] Z(t) = GRU(B(t)) ||Embed(C(t)) represents the splicing and fusion of behavior and context;

[0123] W is the projection weight matrix, which maps the comprehensive features to a space with the same dimension as the permission item.

[0124] σ(·) is the Sigmoid function, which outputs the confidence level of each permission request;

[0125] It is an innovative regularization function designed to simulate "authority tension". Its mechanism is to detect whether the current behavioral feature Z(t) frequently contains behavioral signals that are strongly correlated with unauthorized items in P0, and output a set of modulation terms to strengthen the output response of these "unauthorized tendencies".

[0126] α is a weighting factor that controls the degree of incentive of the Γ term, and is optimized using the conference dataset before deployment.

[0127] For example, if the user's current role does not have file download permissions (P0) [i] =0), but behavior B(t) frequently contains semantic or interactive codes related to document browsing and clicking the download button, then This will output a positive offset value, pushing that dimension in P. req The higher the level, the better, to support the model in discovering "request trends" in advance.

[0128] To control the total number of variables, The function internally relies only on the permission bit state (0 / 1) and behavior relevance scoring (e.g., based on cosine distance), without introducing independent models or parameter blocks, keeping the overall architecture concise and feasible.

[0129] This mechanism does not rely on explicit request actions, but rather captures the implicit but unspoken intentions expressed in behavior through the inherent relationship of "permission tension," achieving a more forward-looking, sensitive, and human-centered permission management system. This is particularly important for scenarios in meeting systems where "guest users express the intention to share their screens but do not click the button."

[0130] Output:

[0131] This step outputs two variables:

[0132] P req : Permission request vector, each dimension is a confidence value between 0 and 1, corresponding to whether each permission operation has a request intent;

[0133] UID: A unique user identity used for comparison and approval with the original user permission status P0 during subsequent permission review stages.

[0134] This step involves constructing a fusion representation Z(t) of semantic behavior and meeting context, and combining it with an innovatively designed "permission tension" regularization term. This approach effectively improves the sensitivity and accuracy of permission intent recognition, overcoming the limitations of traditional rules or explicit interaction triggering mechanisms, and is particularly well-suited to the dynamic permission control needs of conference terminals targeted by this patent. Through this structural modeling method, this step achieves a natural transition between behavior and permission intent, providing quantifiable and reliable semantic judgment basis for subsequent multi-level permission review mechanisms.

[0135] Step 4: Multi-level permission decision-making and approval

[0136] The main task of this step is to analyze the user permission request intent P identified in the previous step. req After reviewing the decision, the system combines the user's UID, initial permission state P0, and role to output the final permission grant result P. new This step, essentially the system adjudication layer for permission intent, sits between model recognition and interface response, directly determining the security boundaries and flexibility of permission management. Therefore, it is essential to ensure the stability and reliability of the audit logic through institutionalized and interpretable policy functions, while also adapting to dynamic user requests. To serve the highly scenario-dependent system of the conference terminal, this step designs an executable permission audit mechanism "based on a combination of policy thresholds and permission status adjustment factors," making the audit process both reproducible and possessing sufficient behavioral response flexibility.

[0137] This step takes the output from step 3 as input:

[0138] P req : User permission request intent vector, which is the confidence vector output by the model in the previous step;

[0139] UID: User identification identifier, used to locate the basic permission status in the permission table and user records;

[0140] Additionally, the output variable from step 1 is used (this variable has been continuously referenced by steps 2 / 3, and is therefore considered a "long-lived variable" in the current permission chain):

[0141] P0: The user's initial permission status based on identity and template configuration in this meeting;

[0142] Role: User role information, set by the meeting system organizer, such as "host", "guest", "internal participant", etc., used to match the permission approval policy table.

[0143] The entire permission review process consists of two layers: the first layer is policy matching, which determines whether the user is qualified to request the permission; the second layer is request confidence verification, which is based on P... reqDetermine whether the permission is sufficiently reasonable to grant. To improve the flexibility of the system's review process, this step designs a second-order weighted judgment mechanism based on "initial permission state interference adjustment." This ensures that requests exceeding the scope of basic permissions are not directly rejected, but rather the review result is jointly determined by permission role policy, behavioral intent strength, and security sensitivity.

[0144] First, load the policy rule table S, which was defined when the meeting was created, from within the system. rule This table uses "role-permission item" as the key-value pair and returns the approval threshold value. This indicates the default threshold for different roles to request different permissions. For example, for "screen sharing," the threshold for the host can be set to 0.3, while for external guests it is 0.8.

[0145] Based on this, a permission granting correction function η is introduced. i Used to dynamically adjust request confidence level The adjustment logic considers two factors: first, whether the permission was originally granted (determined by P0); and second, the sensitivity of the permission in the meeting (determined by the fixed weight R set by the administrator). i (Control). The final judgment function is as follows:

[0146]

[0147] in:

[0148] It is the probability of requesting the i-th permission;

[0149] P0 [i] It indicates whether the i-th permission has been granted (1 for existing, 0 for non-existent);

[0150] R i This is the system sensitivity weight of the permission item, which is predefined by the system administrator. For example, file download is 1.4, control sharing is 1.6, and viewing the agenda is 1.0.

[0151] λ is the risk adjustment coefficient, which is generally set in the range of 0.3 to 0.5;

[0152] This is a Boolean decision function, and the result is... 0 indicates rejection, 1 indicates approval;

[0153] This sets the approval threshold for the user's current role regarding this permission.

[0154] This formula embodies the following key creative design:

[0155] 1. Using P0 as the review adjustment reference, a review intensity change mechanism "based on the initial state deviation" is constructed;

[0156] 2. Introduce R i As a security-sensitive control, it enables organizationally customized flexibility in authorization decisions;

[0157] 3. By only locally weighting the request components without changing the output structure of the permission intent model, we ensure decoupling from the structure in the previous step and ease of deployment.

[0158] Specific example: User UID_07 is "Guest", with initial permissions P0. [file_download] =0, the policy threshold for this permission. System settings R file_download =1.4;

[0159] At this point, the user's request intent is output as: The adjusted result is calculated to be 0.6·(1+0.5·1·1.4)=1.02>0.75, therefore the request is approved and the value is assigned as follows:

[0160] After all dimensions have been calculated, P new The output is then sent to the subsequent interface execution module.

[0161] This step outputs two variables:

[0162] P new : Access control result vector, relative to P0, P req The structure is consistent, with each dimension indicating whether the permission item has been approved;

[0163] UID: Original user identity identifier, used to locate the current user status at the terminal interface layer.

[0164] This step focuses on the system's adjudication process for permission requests, clearly defining the input boundaries and behavioral patterns of the review logic. By introducing a risk adjustment function with P0 as the weighting factor, interpretability and behavioral flexibility are added to the traditional "role-threshold" strategy, enhancing the ability to handle "weak requests but reasonable overreach." Simultaneously, this mechanism maintains structural consistency with the model output P. req This decoupling avoids mistakenly treating review as "identification and reprocessing," ensures the system's control over review behavior, and truly meets industry needs such as hierarchical meeting permissions, role-based power distribution, and adjustable risks. It is the core node in the entire permission chain that transitions to "result implementation."

[0165] Step 5: Terminal interface rendering and control execution based on permission status

[0166] The task of this step is to process the final permission result P output by the multi-level permission review module in the previous stage.new This step is applied to the conference terminal interface to complete permission-driven interface rendering control and function execution. It is a system behavior execution step whose main purpose is to ensure that permission results truly affect the user-visible interface and actual function control, forming a closed loop "from permission data to actual execution effect." This step is responsible for "implementing permission control results," and its focus is on the terminal system layer, ensuring that system behavior, visual feedback, and user-accessible modules are strictly consistent with the permission status.

[0167] This step strictly uses the output of step 4 as input:

[0168] P new : The permission decision vector output by the permission audit module. Each bit represents whether the permission item is granted (value is 0 or 1), which is used to drive the opening or disabling of various functional modules of the terminal interface.

[0169] UID: The identity identifier of the current user, serving as an index identifier for the user's permission context, ensuring that the terminal component's reading of the permission status applies to the correct user instance.

[0170] The conference terminal interface consists of a set of Permission-Controlled Widgets (PCWs), with each control corresponding to a permission control field. To improve system response efficiency and enhance module maintainability, this step designs a control state-driven method based on "permission mask and dynamic binding". Each control W... k (Such as "File Entry", "Shared Control Button", "Meeting Participant List") are bound to the corresponding permission bits via configuration file during initialization. It automatically refreshes the status after each permission change.

[0171] The control's activation state is calculated using the following function:

[0172]

[0173] in:

[0174] V k For control W k The visibility status flag, with a value of 1 (displayed and interactive) or 0 (hidden or grayed out);

[0175] This indicates whether the k-th permission in the permission review results has been granted.

[0176] It is a Boolean function;

[0177] χ k The control can be configured with display parameters, defining whether it can be grayed out when permissions are not granted (χ).k =1) or directly hide (χ) k =0).

[0178] To optimize system efficiency, this solution designs a "difference-aware local rendering mechanism," which records the last effective permission copy P of the terminal. curr Compare the current permission status P new Only render the collection of controls whose permission status has changed:

[0179]

[0180] The set Δ v `is` represents the set of indexes of controls in the interface that need to be re-rendered. The terminal controller initiates the corresponding control's show / hide / enable / disable update process based on this set. The system will synchronously update `P` after completing the control refresh. curr =P new This will ensure that the next rendering is more accurate.

[0181] For example, if user UID_07's original permission status Currently granted permissions 1, then Δ vis Includes a "Share Button" module. The system activates the corresponding control from a grayed-out state to a clickable state and binds it to the conference control service port, allowing it to perform screen sharing initialization actions.

[0182] Another typical scenario is: The "Data Entry" control will then be hidden or grayed out, and clicking it will have no effect or will display a "Permission denied" message.

[0183] This mechanism ensures that interface behavior responds in real time to changes in permission status, while avoiding a full redraw, thus preventing system lag or interaction delays caused by frequent dynamic permission changes.

[0184] This step outputs two variables:

[0185] R inst : A set of interface control actions, which includes all rendering actions executed within the current period based on the permission status, such as showing / hiding / enabling controls, binding interfaces, triggering initialization actions, etc.

[0186] P curr : A copy of the currently effective permission status on the local terminal, used for subsequent permission change detection and response.

[0187] This step focuses entirely on the authorization review result P. newThis interface-driven application ensures that the judgment results of the model or rule layer can accurately drive changes in the end-user interaction layer. Through a Boolean mask function and a difference-aware refresh mechanism, this solution guarantees strong consistency between permission behavior and interface rendering, while also achieving high execution efficiency and a good user experience. The entire mechanism uses UID as an index, P... new To control the source, W k To visualize the target, completing the real-time mapping of "permissions → controls" is the key to achieving fine-grained linkage between the personalized interface of the conference terminal and the permission status.

[0188] Step 6: Auditing and Tracking Access Control Records

[0189] The goal of this step is to construct a structured permission audit entry based on the data generated in the preceding stages after the permission control behavior is completed, and to formally write this entry into the system audit database as the final filing behavior of permission operation, thereby realizing a closed loop of the entire permission chain.

[0190] The input for this step is the output of step 5:

[0191] R inst : A set of interface control actions, which includes all rendering actions executed within the current period based on the permission status, such as showing / hiding / enabling controls, binding interfaces, triggering initialization actions, etc.

[0192] P curr : A copy of the currently effective permission status on the local terminal, used for subsequent permission change detection and response.

[0193] In addition, the key fields generated in steps 1-4 and used for subsequent modeling are also referenced:

[0194] UID: The identifier of the user currently initiating the operation;

[0195] P0: The user's initial permission status;

[0196] P req The permission intent request value output by the behavior recognition module;

[0197] P new The final authorization decision output by the permission review module;

[0198] C(t): Meeting context information at the time the user's action occurred, including meeting stage, speaker, shared resources, etc.

[0199] This step uses the structured function F audit The above variables are assembled into a structured log entry L. i Its fields are as follows:

[0200] L i =Faudit (UID,P0,P req ,P new ,P curr ,R inst ,C(t));

[0201] After the system is constructed, this step further calculates the permission offset index ΔP to measure the impact of permission state changes on the system:

[0202]

[0203] This metric represents the number of new unauthorized permissions granted in this round of permission operations, and is a core quantitative parameter for measuring the sensitivity of users to changes in permissions.

[0204] The audit module will L i Along with ΔP, it is written to the local permission audit database and pushed to the cloud security log center, serving as the original data source for subsequent risk control systems and behavior analysis modules. After the system performs the write operation, it returns the write status and log ID as confirmation feedback for the system's behavior loop.

[0205] For example, the system will return the following result:

[0206] write_status:"success"

[0207] log_id:"audit_20250519_000871"

[0208] ΔP:1.

[0209] Log entry L i Instead of being passed on as output, it is permanently stored in the system background as a final permission status change record.

[0210] This step ultimately outputs two variables:

[0211] write_status: The result of the audit log being written (such as "success"), indicating that the access control behavior has been persistently recorded by the system;

[0212] ΔP: Permission offset indicator, used by the risk control system to dynamically assess the risk of unauthorized behavior.

[0213] This step directly performs data writing and audit archiving. It uses the structure function F. audit Combined with the offset indicator ΔP, the system not only records the results of permission operations but also quantifies their risk potential, ultimately using the write confirmation result as the marker for the completion of the system action.

[0214] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

[0215] Furthermore, the above embodiments are merely descriptions of preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Without departing from the spirit of the present invention, all modifications and improvements made by those skilled in the art to the technical solutions of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for managing access control data in a conference terminal, characterized in that, include: S1: Perform identity verification and permission initialization operations on the participants in the conference terminal; S2: After performing identity verification and permission initialization operations, collect multimodal behavioral information of participants and dynamic contextual information of the meeting in real time; S3: Construct behavior vectors based on multimodal behavior information and dynamic contextual information of the meeting, and construct input pairs by combining behavior vectors and meeting context blocks; S4: Based on the input, identify whether the current user has a potential intent to request permissions, and output a structured permission request vector; S5: Review and approve the permission request vector and output the review result vector; S6: Input the audit result vector into the conference terminal interface, and output the interface control action set and permission status copy through the conference terminal interface; S7: Construct structured permission audit entries based on the interface control action set and permission status copy, and write the permission audit entries into the system audit database.

2. The method for managing access data in a conference terminal according to claim 1, characterized in that, S1 includes: S1.1: Read the card using the NFC card reader integrated into the conference terminal and identify the user's unique identification code on the card; S1.2: The conference terminal queries the conference role bound to the identification code through the built-in conference organization information interface; S1.3: Perform permission initialization operations based on the meeting roles.

3. The method for managing access data in a conference terminal according to claim 1, characterized in that, S2 includes: S2.1: The conference terminal collects user speech information and interaction actions through the voice channel and the interface interaction channel respectively, and encodes the interaction actions in a unified manner; S2.1: Input the user's speech information into the ASR engine, and output a phrase fragment with a timestamp through the ASR engine.

4. The method for managing access data in a conference terminal according to claim 1, characterized in that, S3 includes: S3.1: Obtain multimodal behavioral information and dynamic contextual information of the participants; S3.2: The terminal system aggregates multimodal behavioral information and dynamic contextual information of the meeting according to a fixed sliding window, constructs a behavioral vector under the time window, and introduces a permission conflict penalty term into the behavioral vector; S3.3: Combine the behavior vector and the meeting context block to construct the input pair.

5. The method for managing access data in a conference terminal according to claim 4, characterized in that, The expression for the behavior vector in S3.2 is: B(t)=concat(encode s (S t-T:t )+λ1·ψ(L s ),encode a (A t-T:t )+λ2·φ(P0,A t-T:t )); Where B(t) is the action vector; encode s (S t-T:t The text is embedded using 32-dimensional word vectors within a T-second timeframe, and then average pooled; ψ(L s () is a sensitive word activation counting function, representing the frequency of triggering unauthorized keywords within this time window; λ1 is a sensitive behavior incentive factor used to amplify overstepping semantics; encode a (A t-T:t () represents the aggregation of multi-hot encodings for interactive behaviors; φ(P0,A t-T:t ) represents the permission conflict function; λ2 is the penalty factor for conflict of behavior permissions.

6. The method for managing access data in a conference terminal according to claim 1, characterized in that, S4 includes: S4.1: Input the behavior vectors from the input pairs into a three-layer bidirectional GRU sequence modeler and extract the behavior time series feature vectors; S4.2: Simultaneously embed the structured context variables in the meeting context block into a context vector; S4.3: Construct a comprehensive vector from the behavioral time series feature vector and the context vector through a gating fusion module; S4.4: Input the comprehensive vector into a projection function with a special regularization term, and output the request confidence level of each permission through the projection function; S4.5: Construct a permission request vector based on the requested confidence level.

7. The method for managing access data in a conference terminal according to claim 6, characterized in that, The permission request vector expression in S4.5 is as follows: P req =σ(W·Z(t)+α·Γ(Z(t),P0)); Z(t)=GRU(B(t))||Embed(C(t)); Where P req Z(t) is the permission request vector; Z(t) is the concatenation and fusion function of behavior and context; W is the projection weight matrix; σ(·) is the Sigmoid function, which outputs the request confidence of each permission; Γ(Z(t),P0) is the regularization function; α is the weight factor, which controls the incentive degree of Γ terms; C(t) is the meeting block.

8. The method for managing access data in a conference terminal according to claim 1, characterized in that, S7 includes: S7.1: Assemble the set of interface control actions and permission status copies into structured permission audit entries using structured functions; S7.2: Calculate the offset of the permission audit entry, write the permission audit entry and offset into the local permission audit database, and push it to the cloud security log center.

9. The method for managing access data in a conference terminal according to claim 1, characterized in that, The behavior vectors in S3 include the behavior context vectors of speech text, interactive behavior, and overriding signals.

10. The method for managing access data in a conference terminal according to claim 1, characterized in that, The meeting context block in S3 includes the current meeting stage, speaker identity, shared resource status, and permission tags.

Images