A fool-proof optimization method and system for concurrent floating authorization

Abstract

The present application relates to the technical field of floating authorization management, and particularly relates to a foolproof optimization method for concurrent floating authorization. The method comprises the following steps: S1, a probe deployed on a client is used to listen to underlying input events of an operating system, and idle time length without mouse movement and keyboard tapping is counted; S2, when the idle time length reaches a first threshold, comprehensive state determination is performed in combination with heartbeat signals reported by the client, and if the heartbeat signals are lost or the heartbeat signals are normal but the idle time length reaches a second threshold, it is determined that the current authorization meets foolproof recovery conditions; S3, a warning prompt with a cancel control is sent to a user terminal, and if a cancel instruction based on the cancel control is not received within a preset time, a TCP reset packet is sent to the client to release the floating authorization; and S4, when the probe captures input events again, a reconnection request is automatically sent to an authorization server to recover the authorization, and the reconnection request carries a context identifier saved when the previous authorization is released.

Description

Technical Field

[0001] This invention relates to the field of floating authorization management technology, and specifically to a foolproof optimization method for concurrent floating authorization. Background Technology

[0002] Floating licensing is a server-verified software licensing mechanism. After purchasing a certain number of license slots, these slots form a shared license pool on the network, managed centrally by a licensing server. When a user needs to use a particular software, the client requests an available slot from the licensing server; after use, the slot is released back into the pool for other users. This model allows companies to purchase fewer licenses than actually installed to meet the software needs of all employees, and it is widely used in scenarios such as computer-aided design software, computer-aided engineering simulation software, and architectural design software in manufacturing enterprises.

[0003] However, existing floating license management systems have several problems that cannot be ignored in actual operation. The first problem is that licenses are held inactively for a long time without being automatically reclaimed. Users may open the software and leave their workstations for meetings, lunch breaks, or other tasks, but the software process does not close, and the license remains held by that process. Even worse, users may run simulation calculations and then leave work immediately; the simulation task may be completed long ago, but the software has not exited, and the license is still held. Some license service programs themselves do not have an automatic idle license reclamation function; once a license is held, it remains in a occupied state unless the user manually closes the software or an IT professional logs into the server to forcibly remove it. The second problem is that the existing timeout reclamation mechanism is too crude. Although some license servers support setting timeout periods through configuration files to reclaim inactive licenses, their judgment is based solely on whether the client periodically sends heartbeat packets. Heartbeat packets only prove that the client process is still running, but cannot determine whether the user is actually operating the software. Under this mechanism, either the threshold setting is too short, frequently resulting in the false termination of users who are currently using the software, or the threshold setting is too long, preventing idle licenses from being released for a long time. The third problem is the lack of foolproof design. Existing systems often directly interrupt user sessions when revoking licenses. Users return to find their licenses revoked without any warning or buffer, requiring them to reapply. If the license pool is full, users are forced to wait in a queue, completely disrupting their workflow. The fourth problem is the lack of priority handling when multiple licenses simultaneously meet the revoke criteria. When multiple licenses are idle, existing systems typically revoke them in random or first-come-first-served order, without considering the varying revoke sensitivities of different users, software, or time periods. The fifth problem is the lack of effective handling for orphaned licenses caused by abnormal disconnections. When clients crash, networks suddenly stop, or users shut down their devices, license sessions are not released promptly, leaving these licenses in a dormant state until administrator intervention. The cumulative effect of these problems is that while enterprises purchase sufficient floating licenses, the actual number of usable licenses is far lower than the purchased amount, leading to user queues during peak hours and a large number of idle licenses during off-peak hours. Currently, there is a lack of a systematic error-proofing optimization solution to address these issues. Summary of the Invention

[0004] The technical problem solved by this invention is to provide a foolproof optimization method for concurrent floating authorization. Under the premise of ensuring that normal user use is not affected, it can accurately identify the idle state of authorization by fusing input events and heartbeat signals. Combined with a hierarchical recycling strategy, a dynamic threshold adjustment mechanism and a non-intrusive authorization release method, it can achieve efficient automatic recycling of floating authorization, seamless reconnection and recovery after abnormal disconnection and fine-grained scheduling of authorization resources.

[0005] The basic solution provided by this invention is a foolproof optimization method for concurrent floating authorization, comprising the following steps: S1. Monitor the underlying input events of the operating system by deploying probes on the client side, and count the idle time when there is no mouse movement or keyboard input. S2. When the idle time reaches the first threshold, a comprehensive status determination is made in combination with the heartbeat signal reported by the client. If the heartbeat signal is lost or the heartbeat signal is normal but the idle time reaches the second threshold, it is determined that the current authorization meets the conditions for foolproof recycling. S3. In response to meeting the error prevention and recycling conditions, a warning prompt with a cancellation control is sent to the user terminal. If a cancellation instruction based on the cancellation control is not received within a preset time, a TCP reset message is sent to the client to release the floating authorization. S4. When the probe captures an input event again, it automatically sends a reconnection request to the authorization server to restore authorization. The reconnection request carries the context identifier saved when the previous authorization was released.

[0006] Furthermore, the comprehensive status determination in S2, combining the heartbeat signal reported by the client, includes the following steps: S21. Establish a four-quadrant state model based on the fusion of heartbeat signals and input events. According to the heartbeat signal and the normal or abnormal state and the active or idle state of the input event, the client authorization state is divided into four judgment results: S211. Perform a comprehensive status determination based on the heartbeat signal reported by the client; S212. When the heartbeat signal is normal but the idle time of the input event reaches the second threshold, it is determined to be a false dead idle state and the foolproof recycling process is triggered. S213. When the heartbeat signal is abnormal and the input event is active, it is determined to be a network fluctuation state, the authorization is maintained and the heartbeat is waited for to recover; S214. When the heartbeat signal is abnormal and the input event is idle or unavailable, it is determined that the terminal is offline or the process is in a crash state, and the forced recycling process is triggered immediately.

[0007] Furthermore, in step S3, sending the warning prompt with a cancellation control to the user terminal includes the following steps: S311. Push a warning notification to the user terminal. The content of the warning notification includes at least the countdown of the remaining time before the current authorization is revoked, the name of the currently occupied software, and the operation instructions for canceling the revocation. The cancellation control includes a clickable cancellation button and / or a triggerable cancellation interaction area set in the warning notification interface. S312. When the user clicks the cancel button or the cancel interaction area with the mouse, the probe captures the cancellation command and reports it to the authorization server. The authorization server terminates the recycling process and resets the idle timer. S313. Furthermore, when the probe captures any mouse movement or keyboard input event within the preset time, it is automatically regarded as equivalent to receiving the cancellation instruction, terminating the recycling process and resetting the idle timer.

[0008] Furthermore, the step S3, which involves sending a TCP reset message to the client to release the floating grant, includes the following steps: S321. The process identifier and its corresponding socket information that hold the authorized connection in the client; S322. Construct a TCP reset message, wherein the source address of the TCP reset message is filled with the address of the authoritative server, the destination address is filled with the address of the client, the source port is filled with the port of the authoritative server, the destination port is filled with the target port of the socket, and the sequence number is filled with the next sequence number that the socket currently expects to receive. S323. The constructed TCP reset message is sent to the client's socket port, triggering the process holding the authorized connection to disconnect the network connection with the authorized server; S324. In response to the network connection disconnection event, the authorization server releases the corresponding floating authorization token according to the standard authorization protocol, and the process holding the authorization connection maintains its running state after the network connection is disconnected.

[0009] Furthermore, prior to performing step S323, an authorization state persistence step is included, which comprises the following steps: S3201. Obtain the process context information of the target application associated with the current authorization. The process context information includes at least the path of the currently opened working file, the bookmark of the current editing or operation position, and the identifier of the unsaved temporary data cache. S3202. Generate the context identifier in step S4 based on the process context information and the unique identifier of the current authorized session, and associate the process context information with the context identifier and store it in a local cache or authorized server; S3203. When the process holding the authorized connection is triggered to disconnect the network connection in step S323, the process of the target application is kept from terminating, and the cached state of the process context information is marked as "to be restored". In step S4, when the probe captures an input event again, the reconnection request automatically sent to the authorization server carries the context identifier. The authorization server locates the process context information based on the context identifier and fills the process context information back into the target application through the probe to restore the target application to its working state before the authorization was released.

[0010] Furthermore, S3 also includes the following steps: S33. When multiple authorizations simultaneously meet the conditions for foolproof recycling, a tiered recycling strategy is implemented, specifically including the following steps: S331. Construct a three-dimensional hierarchical decision matrix. The first dimension of the three-dimensional hierarchical decision matrix is ​​the software type dimension, which is used to set the basic recycling priority for different software. The second dimension is the user role dimension, which is used to set the tolerance coefficient according to the user's role. The third dimension is the time period dimension, which is used to set the time period adjustment coefficient according to the current time period. S332. Calculate the comprehensive recycling priority for each recycling authorization based on the three-dimensional hierarchical decision matrix:

[0011] in, The basic recycling priority corresponding to the software type. The tolerance level corresponding to the user role. This is the time period adjustment factor corresponding to the current time period; The higher the value, the higher the priority for the authorization to be revoked; S333. Calculate the quantified recovery cost value for each authorization to be recovered. The quantified recovery cost value is obtained by weighting the following factors: current document save status factor, software startup time factor, current operation stage factor, session duration factor, and user history recovery response factor. Among them, the value of this factor is lower when the document is saved than when the document is not saved; the shorter the software startup time, the smaller the value of this factor; the value of this factor is lower when the operation stage is browsing state than when it is deep editing state; the shorter the session duration, the smaller the value of this factor; and the more times the user has actively canceled recovery in the user's history, the smaller the value of this factor. S334. According to the sorting rules of comprehensive recycling priority from high to low and recycling cost quantification value from low to high, determine the recycling order of multiple recycling authorizations, and give priority to recycling authorizations with high comprehensive recycling priority and low recycling cost.

[0012] Furthermore, in step S2, the first threshold and the second threshold are updated according to a dynamic adjustment mechanism, which includes predictive adjustment, specifically periodic idle behavior prediction adjustment. Obtain the authorized usage history of the target user, which includes at least the active status of input events and the corresponding start and end times of idle time for each time period of each day within seven consecutive days; Based on the authorized usage history, the historical frequency of the target user entering the idle state within each preset time window of each day is counted. When the historical frequency exceeds the preset frequency threshold, the corresponding time window is marked as the periodic idle window of the target user. When entering the periodic idle window at the current moment, the first threshold of the current session is automatically shortened to a predetermined percentage of the default first threshold, and the second threshold is shortened to the same predetermined percentage of the default second threshold. Furthermore, when the target user does not actually engage in any idle activity within the periodic idle window, the shortening is canceled, and the default first threshold and default second threshold are restored.

[0013] Furthermore, the predictive adjustment also includes operational interval trend prediction adjustment: During the authorization period of the target user, the operation interval time sequence of the target user within a preset sliding time window is continuously collected, and the operation interval time is the time interval between two adjacent input events. Calculate the monotonic trend value of the operation interval time series. When the monotonic trend value shows an upward trend and the current operation interval exceeds a preset multiple of the historical average operation interval, it is determined that the target user is about to enter an idle state. In response to the determination, the first threshold of the current session is shortened to a second predetermined percentage of the default first threshold, the second predetermined percentage being less than or equal to the predetermined percentage in the periodic idle behavior prediction adjustment, and the second threshold is shortened to the second predetermined percentage of the default second threshold; When the subsequently collected operation interval time returns to below the historical average operation interval, the shortening is canceled, and the default first threshold and default second threshold are restored.

[0014] Furthermore, the dynamic adjustment mechanism also includes feedback adaptive adjustment, which updates the personalized first threshold of the target user using the following formula:

[0015] in, This is the current first threshold for personalization. For feedback adjustment coefficients; The feedback adjustment coefficient The recovery behavior type is determined based on the target user's recovery behavior type after the authorization is revoked. The recovery behavior type includes: The first recovery action involves proactively initiating a reconnection request within a first preset time after the authorization is revoked. This action indicates that the revocation was premature, and the corresponding feedback adjustment coefficient is [missing value]. ,and ; The second recovery action, in which no reconnection request is initiated within the second preset time after authorization revocation, indicates that the revocation was justified, and the corresponding feedback adjustment coefficient is [value missing]. ,and ; The third recovery action involves actively canceling the recycling process via the cancellation control before authorization begins. This action indicates user resistance to the current recycling timing, and the corresponding feedback adjustment coefficient is [value missing]. ,and ; The fourth recovery action, which involves successfully reconnecting after authorization revocation and performing the actions of saving the document and closing the application within a third preset time after reconnection, indicates that the user has actively ended their work. The corresponding feedback adjustment coefficient is [value missing]. ,and ; The range of values ​​for the feedback adjustment coefficient is [ [0.3, 0.5], the second threshold is adjusted in conjunction with the first threshold at the same ratio:

[0016] in, This is the current second threshold for personalization. This is the updated personalized second threshold.

[0017] The present invention also discloses a mistake-proofing optimization system for concurrent floating authorization, which uses the above-mentioned mistake-proofing optimization method for concurrent floating authorization.

[0018] The principles and advantages of this invention are as follows: The technical problem solved by this invention is to provide a foolproof optimization method and system for concurrent floating authorization. Its core principle is to deploy a lightweight probe on the client side to monitor input events such as mouse movements and keyboard keystrokes at the operating system level in real time, and to count the idle time when the user is not operating. When the idle time reaches a first threshold, the system does not immediately revoke the authorization, but instead combines this with the heartbeat signals periodically reported by the client for a comprehensive status determination. This two-dimensional detection mechanism can distinguish four different states: authorization is maintained when the user is using the device normally; when the heartbeat is normal but no input events reach a second threshold, it is determined to be a "fake idle" state and the authorization is revoked; when the heartbeat is abnormal but input events are active, it is determined to be a network fluctuation and the authorization is maintained; when the heartbeat is abnormal and no input events occur, it is determined to be an offline state and the authorization is forcibly revoked. Through this fusion determination, the system can accurately identify whether the authorization is truly idle, avoiding misjudging users who are performing background calculations or have unstable networks as idle. Once the authorization conditions are met, the system will first send a warning notification to the user's terminal. This notification includes a countdown to the imminent authorization revocation, the name of the currently used software, and instructions on how to cancel the revocation. Upon receiving the notification, the user can terminate the revocation process by clicking the cancel button or by moving the mouse or typing on the keyboard. The system will only execute the revocation action if no cancellation instruction is received within a preset time. During revocation, the system does not terminate the user's application process or modify any license files. Instead, it obtains the process information and socket parameters of the process holding the authorization connection, constructs a TCP reset message, and sends it to the client, simulating a network connection loss. Upon detecting the connection loss, the authorization server automatically releases the corresponding authorization token according to the standard authorization protocol. The user's application continues to run, but it has lost its connection to the authorization server. When the user returns to their workstation and uses the mouse or keyboard, the probe captures the input event again and automatically sends a reconnection request to the authorization server. The request carries the context identifier saved during the previous authorization release. The authorization server uses this identifier to locate the previously saved working state information and populates it back into the application, restoring the user's working state before the authorization release. When multiple authorizations simultaneously meet the eviction criteria, the system executes a tiered eviction strategy. It calculates the overall eviction priority for each authorization by constructing a tiered decision matrix based on three dimensions: software type, user role, and current time period. Simultaneously, it calculates the quantified eviction cost for each authorization, taking into account factors such as whether the document has been saved, software startup time, whether the current state is browsing or deep editing, session duration, and whether the user has frequently canceled evictions in the past. The eviction order is determined according to a dual rule: from highest to lowest overall eviction priority and from lowest to highest eviction cost. Authorities with high eviction priority and low eviction cost are revoked first, thus minimizing the impact on business operations. The system also features a dynamic threshold adjustment mechanism, which includes both predictive adjustment and feedback-based adaptive adjustment.Predictive adjustments analyze users' authorized usage history to identify patterns in when users enter idle states at different times of the day. When a user enters a periodic idle window, the threshold is automatically shortened. Simultaneously, the system monitors the changing trend of user operation intervals in real time; when the operation interval shows a monotonically increasing trend and the current interval significantly exceeds the historical average, the threshold is shortened in advance. Feedback-based adaptive adjustments record the user's recovery behavior after each authorization revocation. If the user actively reconnects shortly after revocation, it indicates premature revocation, and the system will extend the user's personalized threshold. If the user does not reconnect for a long time, it indicates reasonable revocation, and the threshold remains unchanged. If the user actively cancels before revocation, it indicates resistance to the current revocation timing, and the system extends the threshold more significantly. If the user saves and closes the software immediately after reconnecting, it indicates the user actively ended their work, and the system appropriately shortens the threshold. All these adjustments only affect the personalized threshold of the individual user and will not interfere with the settings of other users.

[0019] The main advantages of this invention compared to the prior art are as follows.

[0020] First, existing technologies typically rely solely on heartbeat signals or simple timeout mechanisms to determine whether an authorization is idle. Heartbeat signals can only detect whether a process is alive but cannot determine whether a user is operating the system. Fixed timeouts can easily lead to situations where a user is using the system but it is mistakenly reclaimed. This application uses a four-quadrant determination model that integrates input event detection and heartbeat signals to accurately distinguish between four states: the user has actually left, the terminal has crashed, network fluctuations, and normal use, significantly reducing the probability of mistaken reclaiming.

[0021] Second, existing technologies often use methods such as killing processes, modifying license files, or directly closing applications when revoking licenses. These operations can lead to the loss of unsaved work, application crashes, or the need to restart the software. This application uses the method of sending TCP reset messages to simulate network disconnection, without performing any intrusive operations on the application. When the user returns, they will be faced with the same operating interface as before they left, thus ensuring work continuity.

[0022] Third, the timeout threshold of existing technologies uses the same fixed value for all users and all software, which cannot adapt to the usage habits of different users and the operating characteristics of different software. This application introduces user role tolerance coefficient and time period adjustment coefficient into the hierarchical recycling strategy, so that the same software has different recycling leniency in the hands of different users. It is more lenient to core roles during peak hours and more strict to non-core roles during off-peak hours, thus realizing the fine allocation of resources.

[0023] Fourth, existing technologies lack priority judgment when revoking multiple licenses, often revoking them randomly or sequentially. This may result in low-cost licenses not being revoked while high-cost licenses are revoked first. This application prioritizes revoking licenses that have been saved, are lightweight, are currently being browsed, have been recently launched, and whose users do not mind being revoked, thus minimizing disruption to users who are engaged in in-depth work.

[0024] Fifth, the threshold settings in existing technologies rely entirely on manual configuration by administrators. Once set, they remain fixed for a long time and cannot be automatically optimized based on actual usage. This application, through predictive adjustment, identifies users' periodic idle patterns and changes in their operating rhythm in advance, and proactively shortens the threshold before users are actually idle, realizing a shift from passive waiting to proactive prediction. At the same time, through feedback-based adaptive adjustment, the system learns from user behavior after each recycling, automatically finding the most suitable personalized threshold for each user's usage habits, and can continuously optimize without manual intervention. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of an embodiment of the present invention. Detailed Implementation

[0026] The following detailed description illustrates the specific implementation methods: The basic implementation examples are as follows: Figure 1 As shown: A foolproof optimization method for concurrent floating authorization includes the following steps: S1. Monitor the underlying input events of the operating system by deploying probes on the client side, and count the idle time when there is no mouse movement or keyboard input. S2. When the idle time reaches the first threshold, a comprehensive status determination is made in combination with the heartbeat signal reported by the client. If the heartbeat signal is lost or the heartbeat signal is normal but the idle time reaches the second threshold, it is determined that the current authorization meets the conditions for foolproof recycling. S3. In response to meeting the error prevention and recycling conditions, a warning prompt with a cancellation control is sent to the user terminal. If a cancellation instruction based on the cancellation control is not received within a preset time, a TCP reset message is sent to the client to release the floating authorization. S4. When the probe captures an input event again, it automatically sends a reconnection request to the authorization server to restore authorization. The reconnection request carries the context identifier saved when the previous authorization was released.

[0027] S2 performs a comprehensive status determination based on the heartbeat signal reported by the client, including the following steps: S21. Establish a four-quadrant state model based on the fusion of heartbeat signals and input events. According to the heartbeat signal and the normal or abnormal state and the active or idle state of the input event, the client authorization state is divided into four judgment results: S211. Perform a comprehensive status determination based on the heartbeat signal reported by the client; S212. When the heartbeat signal is normal but the idle time of the input event reaches the second threshold, it is determined to be a false dead idle state and the foolproof recycling process is triggered. S213. When the heartbeat signal is abnormal and the input event is active, it is determined to be a network fluctuation state, the authorization is maintained and the heartbeat is waited for to recover; S214. When the heartbeat signal is abnormal and the input event is idle or unavailable, it is determined that the terminal is offline or the process is in a crash state, and the forced recycling process is triggered immediately.

[0028] Specifically, in actual enterprise deployments, the probe sends a heartbeat signal to the authorization server every 5 minutes. This heartbeat signal includes the current client's process liveness and network connectivity status. The authorization server maintains two status variables: a heartbeat status variable (normal or abnormal) and an input event status variable (active or idle). An active input event is defined as a mouse movement or keyboard key press within the past 2 minutes; an idle input event is defined as a period of no input events reaching a second threshold. The second threshold is set to 20 minutes. When the server determines the heartbeat is normal and the input event is active, it confirms the user is operating normally and maintains the authorization. When the server determines the heartbeat is normal but the input event idle time reaches 20 minutes, it confirms the user is in a suspended state, triggering the fail-safe recycling process and entering the warning and recycling phase. When the server determines the heartbeat is abnormal but the input event is active, it indicates a possible temporary network interruption for the client, but the user is still using the software. In this case, the server maintains the authorization without any recycling operation, waiting for the next heartbeat to restore normal operation. When the server determines that the heartbeat is abnormal and the input event is idle or the input event status cannot be obtained, it confirms that the client is offline or the process has crashed. At this time, the server immediately forcibly revokes the authorization and does not execute the warning prompt step.

[0029] In step S3, sending a warning notification with a cancellation control to the user terminal includes the following steps: S311. Push a warning notification to the user terminal. The content of the warning notification includes at least the countdown of the remaining time before the current authorization is revoked, the name of the currently occupied software, and the operation instructions for canceling the revocation. The cancellation control includes a clickable cancellation button and / or a triggerable cancellation interaction area set in the warning notification interface. S312. When the user clicks the cancel button or the cancel interaction area with the mouse, the probe captures the cancellation command and reports it to the authorization server. The authorization server terminates the recycling process and resets the idle timer. S313. Furthermore, when the probe captures any mouse movement or keyboard input event within the preset time, it is automatically regarded as equivalent to receiving the cancellation instruction, terminating the recycling process and resetting the idle timer.

[0030] Specifically, when the authorization server determines that the current authorization meets the conditions for foolproof revocation, the server sends a warning command to the client probe. Upon receiving the warning command, the probe displays a warning notification window on the user's computer screen. This window is located in the lower right corner of the screen, with a width of 400 pixels and a height of 200 pixels, and is always on top of all windows. The window displays a countdown timer for the remaining time before the current authorization is revoked, decreasing from 60 seconds; it also displays the name of the currently used software, such as CATIA or ANSYS; and it includes instructions on how to cancel the revocation. At the bottom of the window is a clickable cancel button, 100 pixels wide and 36 pixels high, displaying the words "Cancel Revocation." When the user clicks the cancel button, the probe immediately captures the cancellation command and packages it for transmission to the authorization server. Upon receiving the cancellation command, the authorization server immediately terminates the current revocation process, resets the idle timer to zero, and restarts the counting of idle time. Furthermore, during the preset 60-second countdown, if the user moves the cursor with the mouse or presses any key on the keyboard, the probe will also capture these input events, automatically treating this input as equivalent to the user clicking the cancel button. It will then report a cancellation command to the authorization server, terminate the recycling process, and reset the idle timer. If, after the 60-second countdown ends, the probe neither receives a cancel button click command nor captures any mouse or keyboard input events, it will continue with the subsequent authorization release steps.

[0031] Sending a TCP reset message to the client in step S3 to release the floating grant includes the following steps: S321. The process identifier and its corresponding socket information that hold the authorized connection in the client; S322. Construct a TCP reset message, wherein the source address of the TCP reset message is filled with the address of the authoritative server, the destination address is filled with the address of the client, the source port is filled with the port of the authoritative server, the destination port is filled with the target port of the socket, and the sequence number is filled with the next sequence number that the socket currently expects to receive. S323. The constructed TCP reset message is sent to the client's socket port, triggering the process holding the authorized connection to disconnect the network connection with the authorized server; S324. In response to the network connection disconnection event, the authorization server releases the corresponding floating authorization token according to the standard authorization protocol, and the process holding the authorization connection maintains its running state after the network connection is disconnected.

[0032] Specifically, once the warning countdown ends and the user has not cancelled the authorization, the authorization server begins the authorization release operation. The server first queries the authorization session management module for the process identifier of the currently holding authorized connection. This process identifier is a unique numerical number assigned to each running process by the operating system. Simultaneously, the server also queries the socket information corresponding to this process, including the client's IP address and port number. The authorization server's IP address is 192.168.1.100, and the authorization service port is 27000. The client's IP address is 192.168.1.50, and the client process's socket port is 49152. The server constructs a TCP reset message. The source address is filled with the IP address of the authorization server (192.168.1.100), the source port with 27000, the destination address with the client's IP address (192.168.1.50), the destination port with the client process's socket port (49152), and the sequence number with the next expected sequence number for that socket (e.g., 1024). The server sends this constructed TCP reset message through the network card, and the message travels through the enterprise's intranet switch to reach the client computer. Upon receiving this reset message, the client computer's operating system recognizes it as a connection reset command for port 49152. The operating system kernel immediately marks the TCP connection corresponding to that port as disconnected. Application processes running on the client, such as the CATIA software, will detect that the network connection between them and the authorization server has been lost. However, because the operating system only closes the network connection and does not terminate the process, the CATIA software process continues to run in the background, only displaying the status that the authorization connection has been lost. At the same time, the authorization server detects that the network connection with the client has been lost. In accordance with the standard behavior of the FlexNet authorization protocol, the server automatically releases the corresponding floating authorization token back into the authorization pool for other users to apply for.

[0033] Before performing step S323, an authorization state persistence step is included, which includes the following steps: S3201. Obtain the process context information of the target application associated with the current authorization. The process context information includes at least the path of the currently opened working file, the bookmark of the current editing or operation position, and the identifier of the unsaved temporary data cache. S3202. Generate the context identifier in step S4 based on the process context information and the unique identifier of the current authorized session, and associate the process context information with the context identifier and store it in a local cache or authorized server; S3203. When the process holding the authorized connection is triggered to disconnect the network connection in step S323, the process of the target application is kept from terminating, and the cached state of the process context information is marked as "to be restored". In step S4, when the probe captures an input event again, the reconnection request automatically sent to the authorization server carries the context identifier. The authorization server locates the process context information based on the context identifier and fills the process context information back into the target application through the probe to restore the target application to its working state before the authorization was released.

[0034] Specifically, before the authorization server sends a TCP reset message to the client, the client probe performs an authorization state persistence operation. The probe first obtains the process context information of the target application associated with the current authorization. For CATIA software, the probe sends a request to the CATIA process through the inter-process communication interface provided by the Windows operating system to obtain the path of the currently opened workfile, such as the "Car Door Welding Scheme.CATPart" file under the Projects directory on drive D. The probe also obtains the bookmark of the current editing or operation position, i.e., the specific coordinates and viewpoint direction of the position the user is currently observing in the 3D model, such as a position with coordinates X = 100 mm, Y = 50 mm, and Z = 30 mm. The probe also obtains the identifier of unsaved temporary data cache, i.e., the cache number of data that the user has modified in the current session but has not yet saved to disk. After obtaining the above process context information, the probe combines it with the unique identifier of the current authorization session, which is a string of numbers generated by the authorization server when allocating the authorization, such as the number 2026072001. The probe combines process context information and a unique session identifier to generate a context identifier, which is a string of numbers and letters, such as CTX2026072001. The probe stores this context identifier along with the process context information in its local cache folder, and simultaneously reports a copy to the authorization server for backup storage via an encrypted channel. When the authorization server sends a TCP reset message, the client operating system closes the network connection, but the CATIA software process continues to run. The probe marks the process context information in its local cache as pending recovery. When the user returns to their workstation and moves the mouse or presses a key, the probe captures the input event and automatically sends a reconnection request to the authorization server. This reconnection request carries the previously generated context identifier string CTX2026072001. Upon receiving the reconnection request, the authorization server locates the corresponding process context information in its server backup storage based on this context identifier and sends this information back to the client probe via an encrypted channel. After receiving the process context information, the probe fills this information back into the CATIA software process through the operating system's inter-process communication interface. The CATIA software automatically opens the previous work file, switches the viewing perspective of the 3D model to the coordinate position recorded by the bookmark, and restores the unsaved temporary data cache. Users can continue working in the state before the network connection was closed.

[0035] S3 further includes the following steps: S33. When multiple authorizations simultaneously meet the conditions for foolproof recycling, a tiered recycling strategy is implemented, specifically including the following steps: S331. Construct a three-dimensional hierarchical decision matrix. The first dimension of the three-dimensional hierarchical decision matrix is ​​the software type dimension, which is used to set the basic recycling priority for different software. The second dimension is the user role dimension, which is used to set the tolerance coefficient according to the user's role. The third dimension is the time period dimension, which is used to set the time period adjustment coefficient according to the current time period. S332. Calculate the comprehensive recycling priority for each recycling authorization based on the three-dimensional hierarchical decision matrix:

[0036] in, The basic recycling priority corresponding to the software type. The tolerance level corresponding to the user role. This is the time period adjustment factor corresponding to the current time period; The higher the value, the higher the priority for the authorization to be revoked; S333. Calculate the quantified recovery cost value for each authorization to be recovered. The quantified recovery cost value is obtained by weighting the following factors: current document save status factor, software startup time factor, current operation stage factor, session duration factor, and user history recovery response factor. Among them, the value of this factor is lower when the document is saved than when the document is not saved; the shorter the software startup time, the smaller the value of this factor; the value of this factor is lower when the operation stage is browsing state than when it is deep editing state; the shorter the session duration, the smaller the value of this factor; and the more times the user has actively canceled recovery in the user's history, the smaller the value of this factor. S334. According to the sorting rules of comprehensive recycling priority from high to low and recycling cost quantification value from low to high, determine the recycling order of multiple recycling authorizations, and give priority to recycling authorizations with high comprehensive recycling priority and low recycling cost.

[0037] Specifically, in an enterprise-wide floating authorization management scenario, assuming multiple users leave their workstations simultaneously after the 2 PM lunch break without closing their software, the system detects that multiple authorizations simultaneously meet the error-proofing eviction criteria. At this point, the system executes a tiered eviction strategy. The system first constructs a three-dimensional tiered decision matrix. The first dimension is the software type dimension, where the system sets a basic eviction priority for different software. For example, the basic eviction priority for CATIA software is 5, for ANSYS software it's 4, for SolidWorks software it's 3, and for Word software it's 8. The second dimension is the user role dimension, where the system sets a tolerance coefficient for different roles. For example, the tolerance coefficient for core designers is 0.5, for ordinary engineers it's 1.0, for interns it's 1.5, and for managers it's 1.2. The third dimension is the time period dimension, where the system sets a time period adjustment coefficient based on the current time period. For example, the time period adjustment coefficient for the prime time period from 9 AM to 12 PM on weekdays is 0.6, for the lunch break from 12 PM to 2 PM it's 1.5, and for the normal working period from 2 PM to 6 PM it's 1.0. The system calculates the overall recycling priority of each pending authorization based on a three-dimensional hierarchical decision matrix. Assume the current time is 2:30 PM, within normal working hours, with a time adjustment factor of 1.0. A regular engineer using CATIA software has an overall recycling priority equal to CATIA's base recycling priority (5) × the engineer's tolerance factor (1.0) × the time adjustment factor (1.0), resulting in a priority of 5. Another intern using Word software has an overall recycling priority equal to Word's base recycling priority (8) × the intern's tolerance factor (1.5) × the time adjustment factor (1.0), resulting in a priority of 12. After calculating the overall recycling priority for all pending authorizations, a higher value indicates a higher priority for recycling. The system then calculates a quantified recycling cost for each authorization. This quantified cost is calculated by weighting five factors, each ranging from 0 to 1, for a total score of 5. The first factor is the current document save status factor, with a value of 0.2 when the document is saved and 0.9 when the document is not saved. The second factor is the software startup time factor: 0.1 for startup time under 30 seconds, 0.4 for startup time between 30 seconds and 2 minutes, and 0.7 for startup time over 2 minutes. The third factor is the current operation stage factor: 0.2 for browsing, 0.5 for light editing, and 0.9 for deep editing. The fourth factor is the session duration factor: 0.1 for session duration under 10 minutes, 0.4 for session duration between 10 minutes and 1 hour, and 0.7 for session duration over 1 hour. The fifth factor is the user's historical recycling response factor: 0.2 for users who have actively canceled recycling more than 5 times, 0.5 for those who have actively canceled recycling 1 to 5 times, and 0.8 for those who have never actively canceled recycling.The system sums the values ​​of these five factors to obtain a quantified recovery cost for each authorization. A higher value indicates a greater impact on the business from recovering the authorization. The system sorts authorizations by overall recovery priority from highest to lowest, and simultaneously by recovery cost quantified value from lowest to highest, prioritizing the recovery of authorizations with higher overall recovery priority and lower recovery cost. If two authorizations have the same overall recovery priority, the one with the lower recovery cost quantified value is prioritized. If two authorizations also have the same recovery cost quantified value, they are recovered in the order they entered the idle state, with the one that entered the idle state first being recovered first.

[0038] In step S2, the first threshold and the second threshold are updated according to a dynamic adjustment mechanism, which includes predictive adjustment, specifically periodic idle behavior prediction adjustment. Obtain the authorized usage history of the target user, which includes at least the active status of input events and the corresponding start and end times of idle time for each time period of each day within seven consecutive days; Based on the authorized usage history, the historical frequency of the target user entering the idle state within each preset time window of each day is counted. When the historical frequency exceeds the preset frequency threshold, the corresponding time window is marked as the periodic idle window of the target user. When entering the periodic idle window at the current moment, the first threshold of the current session is automatically shortened to a predetermined percentage of the default first threshold, and the second threshold is shortened to the same predetermined percentage of the default second threshold. Furthermore, when the target user does not actually engage in any idle activity within the periodic idle window, the shortening is canceled, and the default first threshold and default second threshold are restored.

[0039] Specifically, the system maintains an independent authorized usage history for each user. This history includes the active status of input events and the corresponding start and end times of idle periods for each time slot of each day for at least seven consecutive days. The system divides a 24-hour day into 96 time windows, each 15 minutes long. The system counts the number of times a target user enters an idle state within each 15-minute time window over the past seven days. Assuming a frequency threshold of 70%, meaning that an user enters an idle state within the same time window for five or more out of seven days, the system marks that time window as the user's periodic idle window. For example, if the system finds that user Zhang San entered an idle state every day from 12:00 PM to 12:15 PM for the past seven days, exceeding the 70% frequency threshold, the system marks the period from 12:00 PM to 12:15 PM as Zhang San's periodic idle window. When the current time reaches 12:00 PM, the system recognizes that Zhang San has entered his periodic idle window and automatically shortens the first threshold for the current session from the default 15 minutes to 50% of the default value, i.e., 7.5 minutes. At the same time, the second threshold is shortened from the default 20 minutes to 50% of the default value, i.e., shortened to 10 minutes. If Zhang San does not actually engage in any idle activity during the periodic idle window from 12:00 to 12:15, that is, if the system detects that Zhang San has continuous mouse movement or keyboard input events during these 15 minutes, then the system determines that the previous prediction was inaccurate, immediately cancels the shortening operation, restores the first threshold to the default 15 minutes, and restores the second threshold to the default 20 minutes.

[0040] The predictive adjustment also includes operational interval trend prediction adjustment: During the authorization period of the target user, the operation interval time sequence of the target user within a preset sliding time window is continuously collected, and the operation interval time is the time interval between two adjacent input events. Calculate the monotonic trend value of the operation interval time series. When the monotonic trend value shows an upward trend and the current operation interval exceeds a preset multiple of the historical average operation interval, it is determined that the target user is about to enter an idle state. In response to the determination, the first threshold of the current session is shortened to a second predetermined percentage of the default first threshold, the second predetermined percentage being less than or equal to the predetermined percentage in the periodic idle behavior prediction adjustment, and the second threshold is shortened to the second predetermined percentage of the default second threshold; When the subsequently collected operation interval time returns to below the historical average operation interval, the shortening is canceled, and the default first threshold and default second threshold are restored.

[0041] Specifically, during the user's authorized usage period, the system continuously collects the user's operation interval time series within a preset sliding time window. The sliding time window is 10 minutes long, and the system records the time interval between two adjacent input events within these 10 minutes. Assume the historical average operation interval is 30 seconds. The system calculates the monotonic trend value of the current operation interval time series in real time. When the system detects that the monotonic trend value of the operation interval is continuously rising, meaning the interval between two user operations is getting longer, and the current operation interval has exceeded four times the historical average operation interval (i.e., the current operation interval exceeds 120 seconds), the system determines that the user is about to enter an idle state. In response to this determination, the system shortens the first threshold of the current session from the default 15 minutes to 70% of the default value, i.e., to 10.5 minutes. Simultaneously, it shortens the second threshold from the default 20 minutes to 70% of the default value, i.e., to 14 minutes. This second predetermined percentage of 70% is less than the predetermined percentage of 50% in the periodic idle behavior prediction adjustment because the operation interval trend prediction is based on short-term behavioral signals, and its confidence level is lower than that of periodic predictions based on long-term historical patterns; therefore, the shortening is more conservative. When the subsequent collected operation interval time returns to below 30 seconds of the historical average operation interval, the system determines that the user has resumed active operation, cancels the shortening operation, restores the first threshold to the default 15 minutes, and restores the second threshold to the default 20 minutes.

[0042] The dynamic adjustment mechanism also includes feedback adaptive adjustment, which updates the personalized first threshold of the target user using the following formula:

[0043] in, This is the current first threshold for personalization. For feedback adjustment coefficients; The feedback adjustment coefficient The recovery behavior type is determined based on the target user's recovery behavior type after the authorization is revoked. The recovery behavior type includes: The first recovery action involves proactively initiating a reconnection request within a first preset time after the authorization is revoked. This action indicates that the revocation was premature, and the corresponding feedback adjustment coefficient is [missing value]. ,and ; The second recovery action, in which no reconnection request is initiated within the second preset time after authorization revocation, indicates that the revocation was justified, and the corresponding feedback adjustment coefficient is [value missing]. ,and ; The third recovery action involves actively canceling the recycling process via the cancellation control before authorization begins. This action indicates user resistance to the current recycling timing, and the corresponding feedback adjustment coefficient is [value missing]. ,and ; The fourth recovery action, which involves successfully reconnecting after authorization revocation and performing the actions of saving the document and closing the application within a third preset time after reconnection, indicates that the user has actively ended their work. The corresponding feedback adjustment coefficient is [value missing]. ,and ; The range of values ​​for the feedback adjustment coefficient is [ [0.3, 0.5], the second threshold is adjusted in conjunction with the first threshold at the same ratio:

[0044] in, This is the current second threshold for personalization. This is the updated personalized second threshold.

[0045] Specifically, the system records the target user's recovery behavior after each authorization revocation and updates the user's personalized threshold based on the type of recovery behavior. The system independently maintains a first personalized threshold variable and a second personalized threshold variable for each user, with initial values ​​of 15 minutes and 20 minutes respectively. When a user exhibits the first recovery behavior—that is, within 3 minutes of authorization revocation, the user actively initiates a reconnection request and successfully restores authorization—the system determines that this revocation was premature and constitutes a case of mistakenly affecting the user. In this case, the feedback adjustment coefficient is set to 0.1. Assuming the user's current first personalized threshold is 15 minutes, the updated first threshold equals 15 × 1.1, resulting in 16.5 minutes. When a user exhibits the second recovery behavior—that is, within 30 minutes of authorization revocation, the user does not initiate a reconnection request—the system determines that this revocation is reasonable and the user is indeed in an abandoned state. In this case, the feedback adjustment coefficient is set to 0, and the user's first personalized threshold remains unchanged. When a user performs a third recovery action—that is, cancels the recycling by clicking the cancel button or moving the mouse and keyboard during the 60-second countdown warning phase—the system determines that the user is resisting the current recycling timing, indicating that the threshold setting is too aggressive. In this case, the feedback adjustment coefficient is set to 0.3, which is greater than the 0.1 feedback adjustment coefficient for the first recovery action. This is because actively canceling recycling demonstrates a stronger degree of resistance to the recycling timing than reconnecting after recycling. The user's personalized first threshold is equal to the current value × 1.3, a larger adjustment range. When a user performs a fourth recovery action—that is, after authorizing recycling, the user initiates a reconnection request, successfully restores authorization, and then saves the document and closes the application within 5 minutes—the system determines that the user actively ended their work and left, rather than being mistakenly recycled by the system. This indicates that the threshold can be appropriately shortened to improve recycling efficiency. In this case, the feedback adjustment coefficient is set to -0.1. The user's personalized first threshold is equal to the current value × 0.9, a reduction of 10%. In all cases, the feedback adjustment coefficient is limited to between -0.3 and 0.5 to prevent sudden threshold changes caused by a single feedback. The second threshold is adjusted in conjunction with the first threshold at the same ratio. Assuming the current personalized second threshold is 20 minutes, when the feedback adjustment coefficient is 0.1, the updated second threshold equals 20 × 1.1, resulting in 22 minutes. When the feedback adjustment coefficient is -0.1, the updated second threshold equals 20 × 0.9, resulting in 18 minutes.

[0046] The present invention also discloses a mistake-proofing optimization system for concurrent floating authorization, which uses the above-mentioned mistake-proofing optimization method for concurrent floating authorization.

[0047] The above are merely embodiments of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A foolproof optimization method for concurrent floating authorization, characterized in that: Includes the following steps: S1. Listen to the underlying input events of the operating system by deploying probes on the client side, and count the idle time when there is no mouse movement or keyboard input. S2. When the idle time reaches the first threshold, a comprehensive status determination is made in combination with the heartbeat signal reported by the client. If the heartbeat signal is lost or the heartbeat signal is normal but the idle time reaches the second threshold, it is determined that the current authorization meets the conditions for foolproof recycling. S3. In response to meeting the error prevention and recycling conditions, send a warning prompt with a cancellation control to the user terminal. If no cancellation instruction based on the cancellation control is received within a preset time, send a TCP reset message to the client to release the floating authorization. S4. When the probe captures an input event again, it automatically sends a reconnection request to the authorization server to restore authorization. The reconnection request carries the context identifier saved when the previous authorization was released.

2. The error-proofing optimization method for concurrent floating authorization according to claim 1, characterized in that: S2 performs a comprehensive status determination based on the heartbeat signal reported by the client, including the following steps: S21. Establish a four-quadrant state model based on the fusion of heartbeat signals and input events. According to the heartbeat signal and the normal or abnormal state and the active or idle state of the input event, the client authorization state is divided into four judgment results: S211. Perform a comprehensive status determination based on the heartbeat signal reported by the client; S212. When the heartbeat signal is normal but the idle time of the input event reaches the second threshold, it is determined to be a false dead idle state and the foolproof recycling process is triggered. S213. When the heartbeat signal is abnormal and the input event is active, it is determined to be a network fluctuation state, the authorization is maintained and the heartbeat is waited for to recover; S214. When the heartbeat signal is abnormal and the input event is idle or unavailable, it is determined that the terminal is offline or the process is in a crash state, and the forced recycling process is triggered immediately.

3. The error-proofing optimization method for concurrent floating authorization according to claim 1, characterized in that: In step S3, sending a warning notification with a cancellation control to the user terminal includes the following steps: S311. Push a warning notification to the user terminal. The content of the warning notification includes at least the countdown of the remaining time before the current authorization is revoked, the name of the currently occupied software, and the operation instructions for canceling the revocation. The cancellation control includes a clickable cancellation button and / or a triggerable cancellation interaction area set in the warning notification interface. S312. When the user clicks the cancel button or the cancel interaction area with the mouse, the probe captures the cancellation command and reports it to the authorization server. The authorization server terminates the recycling process and resets the idle timer. S313. Furthermore, when the probe captures any mouse movement or keyboard input event within the preset time, it is automatically regarded as equivalent to receiving the cancellation instruction, terminating the recycling process and resetting the idle timer.

4. The error-proofing optimization method for concurrent floating authorization according to claim 1, characterized in that: Sending a TCP reset message to the client in step S3 to release the floating grant includes the following steps: S321. The process identifier and its corresponding socket information that hold the authorized connection in the client; S322. Construct a TCP reset message, wherein the source address of the TCP reset message is filled with the address of the authoritative server, the destination address is filled with the address of the client, the source port is filled with the port of the authoritative server, the destination port is filled with the target port of the socket, and the sequence number is filled with the next sequence number that the socket currently expects to receive. S323. The constructed TCP reset message is sent to the client's socket port, triggering the process holding the authorized connection to disconnect the network connection with the authorized server; S324. In response to the network connection disconnection event, the authorization server releases the corresponding floating authorization token according to the standard authorization protocol, and the process holding the authorization connection maintains its running state after the network connection is disconnected.

5. The error-proofing optimization method for concurrent floating authorization according to claim 4, characterized in that: Before performing step S323, an authorization state persistence step is included, which includes the following steps: S3201. Obtain the process context information of the target application associated with the current authorization. The process context information includes at least the path of the currently opened working file, the bookmark of the current editing or operation position, and the identifier of the unsaved temporary data cache. S3202. Generate the context identifier in step S4 based on the process context information and the unique identifier of the current authorized session, and associate the process context information with the context identifier and store it in a local cache or authorized server; S3203. When the process holding the authorized connection is triggered to disconnect the network connection in step S323, the process of the target application is kept from terminating, and the cached state of the process context information is marked as "to be restored". In step S4, when the probe captures an input event again, the reconnection request automatically sent to the authorization server carries the context identifier. The authorization server locates the process context information based on the context identifier and fills the process context information back into the target application through the probe to restore the target application to its working state before the authorization was released.

6. The error-proofing optimization method for concurrent floating authorization according to claim 5, characterized in that: S3 further includes the following steps: S33. When multiple authorizations simultaneously meet the conditions for foolproof recycling, a tiered recycling strategy is implemented, specifically including the following steps: S331. Construct a three-dimensional hierarchical decision matrix. The first dimension of the three-dimensional hierarchical decision matrix is ​​the software type dimension, which is used to set the basic recycling priority for different software. The second dimension is the user role dimension, which is used to set the tolerance coefficient according to the user's role. The third dimension is the time period dimension, which is used to set the time period adjustment coefficient according to the current time period. S332. Calculate the comprehensive recycling priority for each recycling authorization based on the three-dimensional hierarchical decision matrix: in, The basic recycling priority corresponding to the software type. The tolerance level corresponding to the user role. This is the time period adjustment factor corresponding to the current time period; The higher the value, the higher the priority for the authorization to be revoked; S333. Calculate the quantified recovery cost value for each authorization to be recovered. The quantified recovery cost value is obtained by weighting the following factors: current document save status factor, software startup time factor, current operation stage factor, session duration factor, and user history recovery response factor. Among them, the value of this factor is lower when the document is saved than when the document is not saved; the shorter the software startup time, the smaller the value of this factor; the value of this factor is lower when the operation stage is browsing state than when it is deep editing state; the shorter the session duration, the smaller the value of this factor; and the more times the user has actively canceled recovery in the user's history, the smaller the value of this factor. S334. According to the sorting rules of comprehensive recycling priority from high to low and recycling cost quantification value from low to high, determine the recycling order of multiple recycling authorizations, and give priority to recycling authorizations with high comprehensive recycling priority and low recycling cost.

7. The error-proofing optimization method for concurrent floating authorization according to claim 6, characterized in that: In step S2, the first threshold and the second threshold are updated according to a dynamic adjustment mechanism, which includes predictive adjustment, specifically periodic idle behavior prediction adjustment. Obtain the authorized usage history of the target user, which includes at least the active status of input events and the corresponding start and end times of idle time for each time period of each day within seven consecutive days; Based on the authorized usage history, the historical frequency of the target user entering the idle state within each preset time window of each day is counted. When the historical frequency exceeds the preset frequency threshold, the corresponding time window is marked as the periodic idle window of the target user. When entering the periodic idle window at the current moment, the first threshold of the current session is automatically shortened to a predetermined percentage of the default first threshold, and the second threshold is shortened to the same predetermined percentage of the default second threshold. Furthermore, when the target user does not actually engage in any idle activity within the periodic idle window, the shortening is canceled, and the default first threshold and default second threshold are restored.

8. The error-proofing optimization method for concurrent floating authorization according to claim 7, characterized in that: The predictive adjustment also includes an operational interval trend prediction adjustment: During the authorization period of the target user, the operation interval time sequence of the target user within a preset sliding time window is continuously collected, and the operation interval time is the time interval between two adjacent input events. Calculate the monotonic trend value of the operation interval time series. When the monotonic trend value shows an upward trend and the current operation interval exceeds a preset multiple of the historical average operation interval, it is determined that the target user is about to enter an idle state. In response to the determination, the first threshold of the current session is shortened to a second predetermined percentage of the default first threshold, the second predetermined percentage being less than or equal to the predetermined percentage in the periodic idle behavior prediction adjustment, and the second threshold is shortened to the second predetermined percentage of the default second threshold; When the subsequently collected operation interval time returns to below the historical average operation interval, the shortening is canceled, and the default first threshold and default second threshold are restored.

9. A foolproof optimization method for concurrent floating authorization according to claim 8, characterized in that: The dynamic adjustment mechanism also includes feedback adaptive adjustment, which updates the personalized first threshold of the target user using the following formula: in, This is the current first threshold for personalization. For feedback adjustment coefficients; The feedback adjustment coefficient The recovery behavior type is determined based on the target user's recovery behavior type after authorization is revoked, and the recovery behavior type includes: The first recovery action involves proactively initiating a reconnection request within a pre-defined timeframe after the authorization is revoked. This action indicates premature revocation, and the corresponding feedback adjustment coefficient is [value missing]. ,and ; The second recovery action, where no reconnection request is initiated within the second preset time after authorization revocation, indicates that the revocation was justified, and the corresponding feedback adjustment coefficient is [value missing]. ,and ; The third recovery action involves actively canceling the recycling process via the cancellation control before authorization begins. This action indicates user resistance to the current recycling timing, and the corresponding feedback adjustment coefficient is [value missing]. ,and ; The fourth recovery action, which involves successfully reconnecting after authorization revocation and performing the actions of saving the document and closing the application within a third preset time after reconnection, indicates that the user has actively ended their work. The corresponding feedback adjustment coefficient is [value missing]. ,and ; The range of values ​​for the feedback adjustment coefficient is [ [0.3, 0.5], the second threshold is adjusted in conjunction with the first threshold at the same ratio: in, This is the current second threshold for personalization. This is the updated personalized second threshold.

10. A foolproof optimization system for concurrent floating authorization, characterized in that: The method for error prevention optimization of concurrent floating authorization as described in any one of claims 1-9 is used.

Images