A license authorization scheduling method, system, storage medium and electronic device

Abstract

This application provides a license scheduling method, system, storage medium, and electronic device, relating to the field of cloud service technology. The technical solution provided in this application determines the degree of license stability required by the current license request and allocates it to a static license pool or a dynamic license pool. The first license sequence in the static license pool has a lower license switching frequency, providing users with long-term stable license guarantees and avoiding frequent license opening and closing operations that disrupt user workflows. The second license sequence in the dynamic license pool allows for a higher license switching frequency to improve the utilization efficiency of license resources. Through this dual-pool separation and differentiated scheduling mechanism, the system ensures both the continuity of licenses and work stability for users with high stability requirements, while also enabling flexible scheduling and efficient resource utilization for users with low stability requirements. It can adopt targeted scheduling methods based on users' stability needs, thereby improving user experience.

Description

Technical Field

[0001] This application relates to the field of cloud service technology, specifically to a licensing and scheduling method, system, storage medium, and electronic device. Background Technology

[0002] With the rapid development of cloud computing technology, design simulation cloud computing platforms have become a crucial infrastructure for enterprises to conduct product research and development and engineering analysis. These platforms provide users with cloud services for professional software such as computer-aided design, finite element analysis, and computational fluid dynamics. These professional software programs employ a licensing mechanism to control access, requiring each user to consume corresponding licensed resources when using software functions. Due to the high cost of purchasing professional software licenses, enterprises often purchase far fewer licenses than the actual number of users, leading to insufficient licensed resources during peak concurrent access periods. Therefore, achieving reasonable license scheduling among multiple users under the constraint of limited licensed resources has become a key technical problem that design simulation cloud computing platforms urgently need to solve.

[0003] Existing authorization scheduling methods mostly employ dynamic adjustment strategies, where the system automatically reclaims idle authorizations and reallocates them based on monitoring user activity. However, in practice, this approach leads to frequent reactivation and deactivation of authorizations by multiple users, resulting in a high switching frequency. When authorization resources are scarce, the system quickly reclaims authorizations from temporarily inactive users to fulfill new authorization requests. When these users resume operation shortly afterward, they need to reapply for authorization, causing repeated activation and deactivation of authorizations. This frequent switching in practical applications causes the software startup and initialization processes to be executed repeatedly, resulting in a poor user experience. Summary of the Invention

[0004] This application provides a licensing scheduling method, system, storage medium, and electronic device that can adopt targeted scheduling methods according to the user's stability requirements, thereby improving the user experience.

[0005] Firstly, this application provides a licensing and authorization scheduling method, the method comprising: In response to the user's current license request, extract the task attributes of the current license request; The stability requirement index of the current license request is calculated based on the task attributes, and the current license request is allocated to the corresponding license pool according to the stability requirement index. When the stability requirement index is greater than the preset pooling threshold, the current license request is allocated to the static license pool; and a first authorization sequence is generated according to the first scheduling strategy corresponding to the static license pool. When the stability requirement index is less than or equal to the preset pooling threshold, the current license request is allocated to the dynamic license pool, and a second authorization sequence is generated according to the second scheduling strategy corresponding to the dynamic license pool. The current license request is authorized according to either the first authorization sequence or the second authorization sequence, with the license switching frequency of the first authorization sequence being less than that of the second authorization sequence.

[0006] By employing the aforementioned technical solution, a stability requirement index is calculated based on task attributes to accurately identify and classify different license requests. Simultaneously, by comparing the stability requirement index with a preset pooling threshold, the system automatically determines the degree of authorization stability required by the current license request and allocates it to either a static or dynamic license pool. For license requests with a stability requirement index greater than the preset pooling threshold, the first authorization sequence has a lower license switching frequency, providing users with long-term stable authorization guarantees and avoiding frequent authorization opening and closing operations that disrupt user workflows. For license requests with a stability requirement index less than or equal to the preset pooling threshold, the second authorization sequence allows for a higher license switching frequency to improve the utilization efficiency of authorization resources. Through this dual-pool separation and differentiated scheduling mechanism, the system ensures both authorization continuity and work stability for users with high stability requirements, while also enabling flexible scheduling and efficient resource utilization for users with low stability requirements. It can adopt targeted scheduling methods based on users' stability needs, thereby improving user experience.

[0007] Secondly, this application provides a licensing and authorization scheduling system, the system comprising: The request module is used to respond to the current license request submitted by the user and extract the task attributes of the current license request; The stability calculation module is used to calculate the stability requirement index of the current license request based on the task attributes, and allocate the current license request to the corresponding license pool according to the stability requirement index. The first scheduling module is used to allocate the current license request to the static license pool when the stability requirement index is greater than the preset pooling threshold; and to generate a first authorization sequence according to the first scheduling strategy corresponding to the static license pool. The second scheduling module is used to allocate the current license request to the dynamic license pool when the stability requirement index is less than or equal to the preset pooling threshold, and to generate a second authorization sequence according to the second scheduling strategy corresponding to the dynamic license pool. The execution module is used to authorize the current license request according to the first authorization sequence or the second authorization sequence, wherein the license switching frequency of the first authorization sequence is less than the license switching frequency of the second authorization sequence.

[0008] Thirdly, this application provides a computer storage medium that stores multiple instructions adapted for loading by a processor and executing any of the methods described above.

[0009] Fourthly, this application provides an electronic device including a processor, a memory, and a transceiver. The memory is used to store instructions, the transceiver is used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform any of the methods described above.

[0010] In summary, the beneficial effects of the technical solution of this application include: By employing the aforementioned technical solution, a stability requirement index is calculated based on task attributes to accurately identify and classify different license requests. Simultaneously, by comparing the stability requirement index with a preset pooling threshold, the system automatically determines the degree of authorization stability required by the current license request and allocates it to either a static or dynamic license pool. The first authorization sequence in the static license pool has a lower license switching frequency, providing users with long-term stable authorization guarantees and avoiding disruptions to user workflows caused by frequent authorization opening and closing operations. The second authorization sequence in the dynamic license pool allows for a higher license switching frequency to improve the utilization efficiency of authorization resources. Through this dual-pool separation and differentiated scheduling mechanism, the system ensures both authorization continuity and work stability for users with high stability requirements, while also enabling flexible scheduling and efficient resource utilization for users with low stability requirements. It can adopt targeted scheduling methods based on users' stability needs, thereby improving user experience. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating a licensing and scheduling method according to an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a licensing and scheduling system according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0012] Explanation of reference numerals in the attached drawings: 300, electronic device; 301, processor; 302, communication bus; 303, user interface; 304, network interface; 305, memory. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0014] In the description of the embodiments of this application, words such as "illustrative," "for example," or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "illustrative," "for example," or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Rather, the use of words such as "illustrative," "for example," or "for example" is intended to present the relevant concepts in a specific manner.

[0015] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0016] Please see Figure 1 This is a flowchart illustrating a licensing and authorization scheduling method provided in an embodiment of this application. This method can be implemented using a computer program, a microcontroller, or run on a licensing and authorization scheduling system based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application. The specific steps of the licensing and authorization scheduling method are described in detail below.

[0017] S101: In response to the current license request submitted by the user, extract the task attributes of the current license request; The current license request refers to a user's application to access software license resources submitted to the license management system at a specific time. For example, it may be a license acquisition request automatically generated by the system when the user starts CAD software, or a user's manual application to use a simulation software license.

[0018] Task attributes refer to the set of task characteristic information associated with the current license request, which describes the specific scenario and requirements of the license usage. For example, task duration indicates the length of time the user expects to use the license (such as a 2-hour modeling task or an 8-hour rendering task), operation frequency indicates the intensity of the user's interaction with the software during the license usage period (such as frequent interaction of 10 operations per minute or low-frequency use of only 1 operation per hour), and session type indicates the business scenario classification of the license usage (such as interactive design, background batch processing, real-time collaboration, etc.).

[0019] Specifically, when the license management server receives a license request message from a user client, it first parses the message to identify basic information such as user identity, requested software type, and license version. Then, it collects task attribute information from multiple data sources: on the one hand, it directly reads explicit attributes such as the user-declared task duration and priority identifier from the parameter fields of the request message; on the other hand, it analyzes implicit attributes such as the average session duration, typical operation frequency, and commonly used functional modules when the user uses the same software in the past, combined with the user's historical behavior database; in addition, it can infer the session type based on contextual information such as the time the request was initiated, the user's department, and the project type. For example, a request initiated by the R&D department on a weekday morning may be an interactive design type, while a request initiated by the operations and maintenance department at night may be a background batch processing type.

[0020] In some embodiments, the task attribute extraction process can be implemented in various ways. Optionally, a direct extraction method based on request message parsing can be adopted: First, a standardized permission request protocol format is defined, reserving parameter bits for task attribute fields such as task duration, operation frequency, and session type in the protocol; when the client initiates a request, the application fills these fields according to the current task characteristics. For example, when video rendering software starts, it automatically calculates the estimated processing time based on the frame rate and resolution of the video to be rendered and fills in the corresponding fields; after the server receives the request, it uses a protocol parser to extract the attribute values ​​according to the predefined field mapping rules and performs validity checks on the extraction results, such as checking whether the duration is positive and whether the operation frequency is within a reasonable range. After the verification is passed, the attribute values ​​are stored in the request context object for subsequent use.

[0021] S102: Calculate the stability requirement index of the current license request based on the task attributes, and allocate the current license request to the corresponding license pool according to the stability requirement index; Among them, the stability demand index is a numerical indicator that quantifies the intensity of the current license request's continuous and stable demand for licensed resources. This index comprehensively reflects the task's tolerance for license switching. For example, the stability demand index of long-duration rendering tasks is high and not suitable for frequent license switching, while the index of temporary query tasks is low and can accept flexible scheduling of licenses.

[0022] Specifically, the system first reads three key fields from the task attribute object: task duration, operation frequency, and session type. Then, it performs quantitative scoring calculations on each of these three fields: For task duration, a piecewise or logarithmic function is used to map the duration to a standardized score range. For example, a non-linear mapping function is used to achieve the effect of lower scores for short-duration tasks and higher scores for long-duration tasks. For operation frequency, since high-frequency operations mean that users need continuous interaction and should not be interrupted, a reverse mapping is used to give high-frequency operation tasks higher interaction stability scores and low-frequency operation tasks lower scores. For session type, the score is directly obtained by querying a pre-established type stability mapping table. For example, real-time collaboration corresponds to higher scores, interactive design corresponds to medium scores, background batch processing corresponds to low to medium scores, and one-time queries correspond to lower scores. After obtaining the three scores, the system performs a weighted sum according to preset weights to calculate a comprehensive stability requirement index, and the resulting index is within the standardized range. Finally, the system compares the calculated stability requirement index with the preset pooling threshold. If the stability requirement index is greater than the threshold, it determines that the task requires stable license ownership and should be allocated to the static license pool. Otherwise, it determines that the task can be flexibly scheduled and should be allocated to the dynamic license pool, thus completing the initial diversion of the current license request.

[0023] Based on the above embodiments, as an optional implementation method, the method of calculating the stability requirement index of the current license request based on task attributes in S102 can be specifically implemented through the following steps S1021-S1023.

[0024] S1021: Extract task duration, operation frequency, and session type from task attributes; The task duration refers to the total time a user expects to use licensed resources to complete a specific task. This time parameter directly reflects the period during which the task occupies licensed resources. The longer the time, the longer the task requires license support, while the shorter the time, the faster the task is completed.

[0025] Operation frequency refers to the intensity of user interaction with the software during the license period. This parameter is quantified by counting the number of operations per unit time. High operation frequency indicates that the user needs to interact with the software frequently and is not suitable for interruption, while low operation frequency indicates that the user may be in a waiting or observation state for a long time, allowing for a certain degree of flexible scheduling of the license.

[0026] Session type refers to the classification identifier of the business scenario for which permission is granted. Different types represent different usage patterns and stability requirements. Common types include interactive design, background batch processing, real-time collaboration, data analysis, and one-time query.

[0027] Specifically, the system first accesses the data structure of the task attribute object, which typically organizes various task characteristic information in the form of key-value pairs or object attributes. The system locates the task duration field according to predefined field names or attribute identifiers, reads the value stored in this field (usually in minutes or hours), converts the value to a unified time unit, and stores it in a dedicated variable for later use. Next, the system locates the operation frequency field, which may directly store the user-declared operation frequency or the average operation frequency derived from user historical behavior analysis. The system reads this value and verifies its validity to ensure it is within a reasonable range. Then, the system locates the session type field, which typically stores a predefined type identifier or type code. The system reads this identifier and maps it to an internal session type enumeration value or type object. During the extraction process, the system performs a completeness check on each field. If any required fields are found to be missing in the task attributes, the system handles the situation according to a preset default value filling strategy or infers a reasonable value for the missing field from the user's historical behavior data, ensuring that the extraction operation obtains all three key parameters to support subsequent stability score calculations.

[0028] S1022: Calculate the duration stability score corresponding to task duration, the interaction stability score corresponding to operation frequency, and the type stability score corresponding to session type. The duration stability score is positively correlated with the task duration, and the interaction stability score is negatively correlated with the operation frequency. Among them, the duration stability score is a quantitative score calculated based on the task duration to assess the task's need for license time stability. This score reflects the contribution of the task duration to the overall stability requirement. The longer the task duration, the higher the score, indicating that the task needs long-term stable license support.

[0029] The interaction stability score is a quantitative score calculated based on the operation frequency to assess the degree of task requirements for permissioned interaction continuity. This score reflects the impact of user operation intensity on stability requirements. The higher the operation frequency, the higher the score, indicating that the task is less tolerant of permission interruptions.

[0030] The type stability score is a quantitative score that is pre-set or calculated based on the session type to assess the degree of inherent requirements for permission stability in a specific business scenario. Different session types have different requirements for stability due to differences in their business characteristics, and this score reflects the characteristics of this type of stability requirement.

[0031] Specifically, the system first processes the conversion of task duration, using a piecewise or continuous mapping function to map the time length to a standardized scoring interval. The system defines multiple time thresholds to divide the time range into several segments, assigning a corresponding base score to each segment. When the task duration falls within a segment, the base score for that segment becomes the main component of the duration stability score. Simultaneously, linear interpolation is performed based on the specific position of the time within the segment to obtain an accurate score, ensuring a smooth mapping process and conforming to a positive correlation.

[0032] The system also considers the non-linear characteristics of time duration. For ultra-long-duration tasks, logarithmic transformation or saturation functions are used to prevent scores from growing indefinitely, while a minimum score threshold is set for extremely short-duration tasks. Next, the system processes the conversion of operation frequency. First, the operation frequency is standardized to a uniform unit of measurement. Then, a positive mapping function is used to convert the operation frequency into an interaction stability score. The higher the operation frequency, the higher the score obtained, reflecting the high requirements for permission stability in high-frequency interaction tasks.

[0033] During the mapping process, the system also considers non-linear factors, using an upper limit for ultra-high frequency operations and a lower limit for low frequency operations to ensure that the scores are within a reasonable range and can effectively distinguish different frequency levels. The system then processes session type conversion by querying a pre-established session type-stability score mapping table. This table sets different stability benchmark scores based on the business characteristics and historical experience of various session types. Real-time collaboration types, requiring continuous online access, have higher scores; one-time query types, with short usage times, have lower scores; interactive design and data analysis types have medium to high scores based on their typical usage patterns; and background batch processing types, although potentially longer in duration, have low interaction requirements and are set at a low to medium level.

[0034] S1023: The duration stability score, interaction stability score, and type stability score are weighted and summed according to preset weights to obtain the stability requirement index of the current license request.

[0035] Specifically, the system first reads three preset weight coefficients from the configuration management module. These weight coefficients are typically determined based on business experience and historical data analysis. System administrators can adjust the weight configurations according to actual operational conditions to optimize license allocation. The system obtains three parameters: duration stability weight, interaction stability weight, and type stability weight. Verifying the validity of these weight parameters includes checking whether the weight values ​​are non-negative and whether the sum of the weights meets normalization requirements. Next, the system performs a weighted multiplication operation, multiplying the duration stability score by the duration stability weight to obtain the weighted contribution value for the duration dimension, multiplying the interaction stability score by the interaction stability weight to obtain the weighted contribution value for the interaction dimension, and multiplying the type stability score by the type stability weight to obtain the weighted contribution value for the type dimension. Finally, the system performs a summation operation, adding the three weighted contribution values ​​together. The accumulated result is the stability requirement index for the current license request.

[0036] S103: When the stability requirement index is greater than the preset pooling threshold, the current license request is allocated to the static license pool; and a first authorization sequence is generated according to the first scheduling strategy corresponding to the static license pool. The preset pooling threshold is a critical value used to determine whether a license request should be allocated to the static license pool or the dynamic license pool. This threshold is usually set based on a balance between system resource capacity and business needs. When resources are sufficient, the threshold can be appropriately lowered to expand the service scope of the static pool, while when resources are scarce, the threshold can be increased to ensure that only tasks with high stability requirements can enter the static license pool.

[0037] A static license pool is a license resource management container that adopts a relatively fixed allocation strategy. Once a license is allocated to a task, it will not be forcibly revoked within the expected time window. It is suitable for handling long-running tasks that require continuous and stable license support.

[0038] The first scheduling strategy refers to the intelligent allocation algorithm adopted by the static license pool based on historical data prediction and time window planning. This strategy predicts the license availability in future time periods by analyzing historical license usage patterns, thereby planning continuous and stable license usage periods in advance for new requests.

[0039] The first authorization sequence represents a time-ordered license allocation scheme generated according to the first scheduling strategy. This sequence specifies in detail which specific license number should be used for each time segment in the future time window for the current request. Its characteristics are fewer license switching times and strong continuity.

[0040] Specifically, the system first registers the current license request in the pending queue of the static license pool and assigns a unique request identifier for subsequent tracking. Next, the system initiates the execution flow of the first scheduling strategy. This flow first determines the future time window of the current request, typically based on the duration of the task in the request. Then, the system queries the current occupancy status of all licenses in the static license pool, identifying a list of licenses already occupied by other tasks. For these occupied licenses, the system needs to determine whether they will actually be continuously used within the future time window or may be idle. To make an accurate judgment, the system extracts the usage records of each occupied license over a past period from the historical license database. These records include the start and end times of the license being occupied, the sequence of user operation timestamps during the occupation, session activity scores, and other information.

[0041] Based on this historical data, the system extracts usage characteristics and performs pattern analysis: It identifies historical time periods with the same time characteristics as future time windows as reference samples; then, it counts the frequency of actual operational activities generated by licenses during these reference time periods to calculate the usage frequency of each time period; simultaneously, it analyzes the distribution of session activity in historical time periods. Low activity indicates that users occupy licenses but do not use them frequently, and an idle correction coefficient is calculated to adjust the usage frequency of each time period accordingly; finally, it obtains the usage probability of each occupied license in each time segment within the future time window. After obtaining the usage probability, the system identifies candidate licenses whose usage probability is below a preset threshold. These licenses, although occupied, are expected to be idle and can be considered for allocation to the current request.

[0042] The system further calculates the continuous available time span that each candidate license can provide for the current request and the average idle level within that span. After comprehensive evaluation, it selects the optimal license allocation scheme and generates a detailed first authorization sequence. This sequence clearly specifies which license the current request should use in each time segment, ensuring that the number of license switching times is minimized and the continuity is maximized throughout the entire usage process, thereby meeting the requirements of high stability tasks.

[0043] In some embodiments, the scheduling of the static license pool and the generation of the first license sequence can be implemented in various ways. Optionally, a usage probability calculation method based on a time series prediction model can be adopted: First, an independent time series prediction model is constructed for each license in the static license pool, such as using a long short-term memory network or an autoregressive moving average model; the usage status of the license over a past period is used as the time series input, where the usage status can be quantified as a continuous value representing different degrees of use from completely idle to continuously active use; after training the model, the time characteristics of the current moment and future time windows (such as day of the week, time, whether it is a holiday, etc.) are input, and the model outputs the expected usage status value of each future time segment, which is the usage probability; then the system identifies candidate licenses with low usage probabilities for most of the time periods in the future time window based on these usage probabilities.

[0044] S104: When the stability requirement index is less than or equal to the preset pooling threshold, the current license request is allocated to the dynamic license pool, and a second authorization sequence is generated according to the second scheduling strategy corresponding to the dynamic license pool. Among them, the dynamic license pool refers to a license resource management container that adopts a flexible and real-time scheduling strategy. The licenses in the pool can be quickly reclaimed and redistributed according to real-time usage, making it suitable for handling short-term, high-priority tasks or tasks with low requirements for license stability.

[0045] The second scheduling strategy refers to the agile allocation algorithm based on real-time monitoring and proactive reclamation adopted by the dynamic license pool. This strategy continuously monitors the actual usage status of occupied licenses and proactively reclaims licenses and allocates them to waiting high-priority requests when it detects that a user has not operated for a long time.

[0046] The second authorization sequence represents the license allocation and reclamation scheme generated according to the second scheduling strategy. This sequence includes not only which license is allocated to the current request, but also information such as which existing task the license was reclaimed from and the time point when the reclamation was triggered. Its characteristics are fast response speed, high resource utilization, but relatively high license switching frequency.

[0047] Specifically, the system first registers the current license request in the pending queue of the dynamic license pool, and extracts two key fields from the request's task attributes: request priority identifier and business type. The request priority identifier is usually a priority level pre-set by the request initiator or business system, while the business type reflects the business scenario to which the request belongs. Based on a pre-established priority weight mapping table and business type urgency mapping table, the system converts these qualitative identifiers into quantitative numerical scores. Then, the system calculates a comprehensive urgency index by weighting the priority weights and business type urgency or taking the maximum value. Simultaneously, the system counts the number of currently allocated and occupied licenses in the dynamic license pool, divides it by the pool's total capacity to obtain the current load rate. This load rate reflects the scarcity of resources in the dynamic pool; a higher load rate indicates fewer available licenses and a need for more proactive reclamation of idle licenses. Based on the calculated urgency index and current load rate, the system determines a dynamic operation gap threshold using a specific formula. This threshold is designed according to two principles: first, the higher the urgency, the lower the threshold, meaning that to meet urgent requests, a shorter idle time is acceptable for license reclamation; second, the higher the load rate, the lower the threshold, meaning that when resources are scarce, idle licenses need to be reclaimed more quickly to improve utilization. After determining the threshold, the system initiates a real-time monitoring mechanism, continuously tracking the user operation timestamps corresponding to all occupied licenses in the dynamic license pool, and calculating the time interval since the last operation for each license. When the system detects that the operation time interval of a license exceeds the dynamic operation gap threshold, it immediately marks the license as reclaimable and triggers the reclamation process. The reclamation process includes sending a notification to the original license holder that the license is about to be reclaimed, saving the user's current work status, formally releasing the license, and allocating it to a waiting current request. The system generates a second authorization sequence containing information such as the reclaimable license identifier, the estimated reclamation time, and the target request for allocation. This sequence reflects the rapid response and flexible scheduling characteristics of the dynamic pool.

[0048] In some embodiments, the scheduling of the dynamic license pool and the generation of the second authorization sequence can be implemented in various ways. Optionally, a priority recycling method based on real-time activity scores can be adopted: First, a real-time activity score is maintained for each occupied license in the dynamic license pool. This score comprehensively considers multiple dimensions such as operation frequency, operation type complexity, and data exchange volume in a recent period. The system continuously monitors the operation behavior of the user corresponding to each license, and updates the activity score of the license whenever an operation occurs. The more frequent and complex the operation, the higher the score. When a new request arrives in the dynamic pool, the system calculates a recycling urgency parameter based on the urgency index of the request and the current load rate. Then, licenses with activity scores lower than the recycling urgency parameter are selected from all occupied licenses as recycling candidates. These candidate licenses indicate that the user has not been active recently and can be recycled first. Next, the candidate licenses are sorted from low to high according to their activity scores, and the license with the lowest score is recycled first and assigned to the new request. During the recycling process, the system records the original holder information and the recycling time point, generates a second authorization sequence containing information such as the recycled license number, the new request identifier, and the expected usage duration, and continuously monitors the actual usage of the new request so as to reschedule when necessary.

[0049] S105: Authorize the current license request according to the first authorization sequence or the second authorization sequence, wherein the license switching frequency of the first authorization sequence is less than the license switching frequency of the second authorization sequence.

[0050] Among them, license switching frequency refers to how frequently the system changes the license resources allocated to the same task during the license usage process. A high switching frequency means that the task needs to change licenses multiple times during use, which may lead to service interruption or performance fluctuations. A low switching frequency means that the task can continuously use the same license resources to maintain stability. The license switching frequency of the first authorization sequence is less than that of the second authorization sequence, which means that the authorization scheme provided by the static license pool for tasks with high stability requirements has fewer license changes, while the authorization scheme provided by the dynamic license pool for flexible tasks may involve more license changes in order to improve resource utilization.

[0051] Specifically, the system first determines whether the current request is assigned to a static or dynamic license pool. If it's a static license pool, the authorization process follows the first authorization sequence; if it's a dynamic license pool, the authorization process follows the second authorization sequence. For authorizations following the first authorization sequence, the system reads the license number corresponding to the first time segment from the sequence, checks if the license is currently available, and if so, immediately assigns the license to the current request and notifies the user to start using it. If the license is temporarily unavailable, it waits according to the expected idle time indicated in the sequence. During this waiting period, the system continuously monitors the actual status of the license, and once the license becomes available, the allocation is completed immediately. After authorization, the system establishes a binding relationship between the request and the license, records the authorization start time and the expected usage duration, and simultaneously starts a usage monitoring mechanism to continuously track the actual usage of the license. When the first time segment is about to end, the system checks in advance whether the next time segment in the first authorization sequence requires a license switch. If a switch is needed, preparations are made in advance, including notifying the user of the upcoming switch, saving the current working state, and applying for the next license, ensuring a smooth switch process. Because the first authorization sequence is carefully planned to ensure continuity, the number of license switches during the entire usage process is very small, and in most cases, the same license may be used from beginning to end without switching.

[0052] For authorizations following the second authorization sequence, the system also reads the first allocation scheme from the sequence. However, unlike the static pool, the second authorization sequence may include situations where licenses need to be reclaimed from existing tasks. In this case, the system first executes the reclamation process, sending a reclamation notification to the original license holder, waiting for the user to save their work, officially releasing the license, and then immediately allocating the reclaimed license to the current request. Because the dynamic pool emphasizes flexibility and resource utilization, the system continuously monitors the usage status of licenses in the pool during the execution of the second authorization sequence. When a better option than the currently allocated license is found, a license switch may be triggered. For example, when an idle license becomes available, or when the current license is needed by a higher-priority request, the system will complete the license switch according to the alternative schemes in the sequence or calculate a new allocation scheme in real time. Therefore, the license switch frequency for the second authorization sequence is relatively high.

[0053] In some embodiments, the licensing process according to the licensing sequence can be implemented in various ways. Optionally, an event-driven asynchronous licensing method can be adopted: First, the system converts each allocation action in the licensing sequence into a predetermined event, including license allocation events, license switching events, license revocation events, etc., each event carrying information such as trigger time, target license, and operation parameters; then, these events are registered in the system's event scheduler, and the scheduler automatically triggers the corresponding licensing operation according to the predetermined time of the event; when the license allocation event is triggered, the system asynchronously executes steps such as license checking, resource locking, and binding relationship establishment, and notifies the requester of successful authorization through a callback mechanism after completion; when the license switching event is triggered, the system simultaneously coordinates the handover of the old and new licenses, including saving the current state to the old license, loading the state to the new license, and updating the binding relationship, ensuring the atomicity and consistency of the switching process; this event-driven method makes the licensing process highly automated, reducing manual intervention and waiting time, and the system can also dynamically adjust the trigger time of the event according to the actual execution situation, for example, triggering the allocation event in advance when it is detected that the license becomes available in advance, and delaying the triggering of the switching event when it is found that the switching conditions are not met.

[0054] Based on the above embodiments, as an optional implementation method, the method of generating the first authorization sequence according to the first scheduling strategy corresponding to the static license pool in S103 can be specifically implemented through the following steps S201-S203.

[0055] S201: Retrieve historical license data for all occupied licenses in the static license pool; Among them, occupied licenses refer to license resources that are currently occupied by users or application instances. These licenses have been allocated to specific users or tasks but have not yet been released and returned to the license pool.

[0056] Historical license data refers to a collection of data that records past usage behavior and status changes of occupied licenses. This dataset contains multi-dimensional information such as license application time, usage duration, release time, usage pattern, user identifier, and task type. These historical records provide a data foundation for analyzing license usage patterns and predicting future behavior.

[0057] Specifically, the system first accesses the static license pool management module and retrieves a list of all license resources marked as occupied by querying the license pool status table. The system then iterates through this list, performing a data retrieval operation for each occupied license, and reading the complete historical record associated with that license from the license usage history database. During the retrieval process, the system uses the license identifier as the primary key to query the database and locate the historical record set for that license. The system sets the time range for historical data, typically extracting records from the most recent period. The time span is determined based on business needs, ensuring sufficient data volume to support effective pattern recognition while avoiding data from too long ago from affecting the accuracy of current predictions. The system extracts complete field information for each historical record from the database, including the start timestamp of license occupancy, the end timestamp of license release, the actual usage duration during occupancy, the user ID of the license user, the task type identifier executed using the license, the operation behavior record during task execution, and the release method identifier (whether the license was actively released or reclaimed after timeout). The system performs preliminary processing on the retrieved raw historical data, including data format standardization, timestamp conversion to a unified time zone, identification and handling of missing fields, and filtering and cleaning of abnormal data.

[0058] S202: Extract usage characteristic data for each occupied license from historical license data, and predict the probability of use of each occupied license within a future time window based on the usage characteristic data; Among them, usage characteristic data refers to the set of characteristic parameters extracted from historical license data that can characterize the license usage patterns and behavioral regularities. These characteristics include usage time period distribution characteristics reflecting the differences in the frequency of license usage at different times of the day or different days of the week; usage duration statistics characteristics reflecting the typical duration of each license occupancy and its range of variation; release time regularity characteristics reflecting the time pattern of how long after occupancy a license is usually released; usage periodicity characteristics reflecting whether there is a periodic pattern of license usage repeating on a daily or weekly basis; and task relevance characteristics reflecting which types of tasks the license is mainly used to perform.

[0059] A future time window refers to a time span extending forward from the current moment. This time window defines the predicted time span, and the system needs to predict whether and when the occupied license will be released within this time window.

[0060] The probability of use refers to the likelihood that an already occupied license will remain occupied within a future time window, predicted based on historical usage data. This probability value is between zero and one. The closer the value is to one, the greater the likelihood that the license will remain occupied and it is not suitable for allocation to new requests. The closer the value is to zero, the greater the likelihood that the license will be released soon and it can be given priority for allocation to new requests.

[0061] Specifically, the system first performs feature extraction on the historical license data for each occupied license. The system analyzes the timestamp information in the historical records, statistically analyzes the usage frequency of licenses in different time periods, divides a day into several time segments, and calculates the proportion of licenses occupied in each time segment to the total number of uses, forming a time-segment distribution feature vector. The system also performs statistics according to the day of the week, calculating the usage frequency distribution of licenses on each day of the week to identify any differences in usage patterns between weekdays and weekends. The system analyzes the duration of each license occupation, calculating statistics such as average usage duration, standard deviation of usage duration, longest usage duration, and shortest usage duration, and also calculates a histogram of usage duration distribution to identify typical usage duration patterns. Finally, the system analyzes the time interval from license occupation to release, extracting statistical characteristics and distribution patterns of release time to identify whether users tend to release licenses after a fixed duration or at specific times.

[0062] The system employs time-series analysis to detect the periodicity of usage patterns, identifying recurring usage patterns based on days, weeks, or other cycles through autocorrelation analysis or spectral analysis. The system also extracts task-related features, statistically analyzing the frequency distribution of licenses used to perform different types of tasks, identifying primary task types and their correlation with usage duration. After feature extraction, the system builds a usage probability prediction model for each occupied license. The system first determines the start and end times of the future time window, with the window starting at the current time and ending at the current time plus a preset prediction duration. The extracted usage feature data is input into the prediction model, which infers the license's status changes within the future time window based on historical usage patterns. During the prediction process, the system comprehensively considers multiple factors, including the matching degree between the current time's position within the day and historical time period distribution characteristics, the comparison between the current usage duration of occupied licenses and historical typical usage durations, and the correspondence between the current weekday / weekend and historical periodic characteristics. The system employs a probabilistic calculation method. For each time point within a time window, it calculates the probability that the license will still be occupied at that time point, comprehensively considering probability values ​​from multiple dimensions, including release probability based on duration, usage probability based on time period, and continuation probability based on periodicity. The system integrates the probability values ​​from multiple dimensions into a comprehensive usage probability for that time point through weighted fusion or probability multiplication rules. The system integrates or discretizes the usage probabilities of each time point within the entire future time window to obtain a single usage probability value representing the average likelihood of the license being occupied throughout the entire time window.

[0063] Based on the above embodiments, as an optional implementation method, the method of predicting the probability of use of each occupied license in a future time window based on the use of feature data in S202 can be specifically implemented through the following steps S2021-S2024.

[0064] S2021: Based on historical occupancy period records, identify a set of historical time periods that have the same time characteristics as future time windows. The time characteristics include weekday attributes, hour intervals, and date types. Among them, the historical occupancy period record refers to the data record of the occupancy status of the occupied license in various time periods in the past. This record identifies which historical periods the license was occupied in by time period, providing data support for identifying usage patterns in the time dimension.

[0065] Among them, time features refer to the set of feature parameters describing time attributes, used to characterize the attributes of time in different dimensions; weekday attribute refers to the day of the week to which the time belongs, including seven values ​​from Monday to Sunday. This attribute reflects the position of the time in the weekly cycle, and different weekday attributes correspond to different user work patterns and license usage habits; hour interval refers to the time period division identifier within a 24-hour period, usually dividing a day into several hour-level time intervals. This attribute reflects the position of the time in the daily cycle, and different hour intervals correspond to different business peak and off-peak periods; date type refers to the date classification identifier to which the time belongs, mainly distinguishing different types such as weekdays, weekends, and statutory holidays. This attribute reflects the nature of the time in the work calendar, and different date types correspond to significantly different license usage intensities.

[0066] The historical time period set refers to the set of historical time periods selected from historical time period records that have the same time characteristics as the future time window. This set includes all past time periods that match the predicted target time period in terms of time characteristics.

[0067] Specifically, the system first parses the time parameters of the future time window, extracting its start and end times. For each point in time or time period within the future time window, the system extracts time features, determining the corresponding weekday attribute, hourly interval, and date type through timestamp conversion and calendar calculation. The system determines the day of the week at the start of the future time window, obtaining the weekday attribute value; determines whether the time is a weekday, weekend, or public holiday, obtaining the date type value; and extracts the hour of the time and maps it to a predefined hourly interval category, obtaining the hourly interval value. The system uses the three extracted time feature parameters as query conditions to access the historical occupied time period record database and perform data filtering. The system iterates through all records in the historical occupied time period records, extracting the timestamp for each record and calculating the corresponding weekday attribute, hourly interval, and date type. The system compares the time features of each historical record with the time features of the future time window item by item, checking whether the weekday attribute is the same, the hourly interval matches, and the date type is consistent. When a historical record matches a future time window across all three time feature dimensions, the system marks the historical record as a qualified sample and adds the corresponding historical time period to the historical time period set. The system continues to iterate through subsequent historical records, repeating the feature comparison and filtering operations until all historical time period records have been processed.

[0068] S2022: Based on the operation interval statistics, calculate the ratio of the number of operation periods with occupied permits in the historical time period set to the total number of historical time periods to obtain the time period usage frequency; Among them, the operation interval statistics refer to the statistical information that records the time interval between each operation of a user during the license period. This data is obtained by analyzing user operation logs and reflects the intensity and activity of the user's operations during the license process.

[0069] An operation period refers to a time period in a historical period in which user actions occur. If there is at least one user action in a historical period, that period is marked as an operation period. This identifier distinguishes between active periods where the license is occupied but the user actually performs actions and idle periods where the license is occupied but the user does not perform any actions. The number of operation periods refers to the total number of periods marked as operation periods in the historical period set. This number reflects the frequency with which the license is actually actively used in the matched historical period. The number of historical periods refers to the total number of historical periods contained in the historical period set. This number represents the total sample size used for statistical calculations.

[0070] Specifically, the system first accesses the operation interval statistics storage module, which records the detailed operation history of each occupied license. The system then performs a time-period usage frequency calculation operation for each occupied license. The system reads the operation interval statistics for that license, which contains the timestamp sequence of each operation during the license's usage period. The system matches the operation timestamp sequence with the historical time period set. For each historical time period in the historical time period set, the system checks whether there is an operation record for that license within the time range of that time period. The system iterates through the operation timestamp sequence, determining whether each operation timestamp falls within the start and end time range of the currently checked historical time period. If at least one operation timestamp exists within the time range of a historical time period, the system marks that historical time period as an operation time period and increments the count by one. The system continues to check the next historical time period in the historical time period set, repeating the operation record matching and operation time period determination process until all time periods in the historical time period set have been traversed. The system counts the total number of time periods marked as operation time periods, obtaining the number of operation time periods. Simultaneously, the system obtains the total number of elements in the historical time period set, obtaining the number of historical time periods. The system performs a division operation, using the number of operation time periods as the dividend and the number of historical time periods as the divisor, and calculates the ratio between the two. The system repeats the above calculation process to calculate the usage frequency for each time period for each occupied license.

[0071] S2023: Extract the activity level corresponding to the historical time period set in the session activity time series data, and determine the idle correction coefficient corresponding to the activity level; Among them, session activity time series data refers to data that records the changes in the activity level of permitted sessions over time. This data records the session activity index values ​​at each time point or time period using time as an index. The activity index reflects the frequency of user operations, the density of interactions, or the active status of task execution in the session.

[0072] Among them, activity level refers to the activity level value extracted from the session activity time series data for each time period in the historical time period set. This value quantifies the activity level of the permitted session in the corresponding historical time period. High activity level indicates that the session is in a highly active state with frequent user operations during that time period, while low activity level indicates that the session is in a low-activity or idle state with sparse user operations during that time period.

[0073] The idle correction coefficient is a correction parameter determined based on the activity level value to adjust the frequency of use during a time period. This coefficient reflects the impact of session activity on the actual probability of permitted use, and there is a mapping relationship between activity level and idle correction coefficient.

[0074] Specifically, the system first accesses the session activity time-series data storage module, which maintains the historical activity records for each session corresponding to an occupied license. The system then performs activity extraction and correction coefficient determination operations for each occupied license. Next, the system reads the session activity time-series data associated with that license. This data is organized in time series format, with each point in time or time period corresponding to an activity value. Based on the time range of the historical time periods, the system locates the corresponding time segment in the session activity time-series data.

[0075] The system iterates through each historical time period in the historical time period set, extracts the start and end times of that time period, and searches for activity records within that time range in the session activity time series data. The system reads all activity values ​​within that time range. If the time range contains multiple activity sampling points, the system calculates the statistical values ​​of the activity of these sampling points, obtaining a representative activity value for that historical time period by calculating the average, median, or weighted average. The system stores the extracted activity values ​​for each historical time period in the corresponding time period record. The system aggregates the activity values ​​of all historical time periods, calculating the average activity, maximum activity, minimum activity, or other statistical measures to obtain a comprehensive activity level representing the overall activity level of the permission within the historical time period set. The system determines the representative activity value for the current session based on the comprehensive activity value or the activity of the most recent time period. The system queries or calculates the idle correction coefficient based on the representative activity value. The system maintains a mapping relationship between activity and idle correction coefficient, defined through a configuration table, mapping function, or piecewise function. The system uses the activity value as input parameter and calculates the corresponding idle correction coefficient by looking up a table or function.

[0076] The design principle of the mapping relationship is that when the activity value is low, the idle correction coefficient is small, reflecting that the session is currently in a low-activity state and the license is more likely to be released in the future. When the activity value is high, the idle correction coefficient is large, close to or equal to one, reflecting that the session is currently in a high-activity state and the license is more likely to be occupied.

[0077] S2024: Multiply the usage frequency of the time period by the idle correction coefficient to obtain the probability of each occupied license being used in the future time window.

[0078] Specifically, the system performs a usage probability calculation operation for each occupied license. The system reads two numerical parameters from the license attribute object: the usage frequency during the specified time period and the idle correction coefficient. The system performs a multiplication operation, using the usage frequency as the multiplicand and the idle correction coefficient as the multiplier, and calculates the product. The physical meaning of this multiplication operation is that the usage frequency obtained based on historical time period statistics is used as a baseline probability, and then adjusted according to the idle level reflected by the current session activity. An idle correction coefficient less than one reduces the usage frequency, resulting in a lower usage probability. This indicates that although the license was historically frequently used during this time period, the current session activity is low, and the license may be released. An idle correction coefficient equal to or close to one maintains the original usage frequency, indicating that the probability of the license continuing to be occupied is consistent with the historical frequency, given the current high session activity. The system processes the result of the multiplication operation, retaining an appropriate number of decimal places, to obtain a numerical value representing the usage probability.

[0079] The system repeats the above calculation process, calculating the probability of each occupied license in the static license pool being used within a future time window. After the calculation is complete, the system stores the usage probability of each license in a license status object. These probability values ​​fully reflect the likelihood that each license will continue to be occupied within the future time window based on historical usage patterns and current active status.

[0080] S203: Based on the probability of use, determine the first authorization sequence for the current license request within a future time window.

[0081] Specifically, the system first analyzes the resource requirements of the current license request to determine the number of licenses needed and the expected usage time range. The system sorts all occupied licenses according to their usage probability from low to high, placing the licenses with the lowest usage probability at the beginning of the sequence, as these licenses are most likely to be released and reallocated in the near future. The system sets the time granularity of the licensing sequence, dividing the future time window into several time segments, each time segment serving as a time node in the licensing sequence. The system then evaluates the authorizability of each license within each time segment, starting with the license with the lowest usage probability.

[0082] For each time segment, the system calculates the probability of each occupied license being released within that segment. It determines whether a license is likely to be released during that time segment by comparing its usage probability with a preset release threshold. When the usage probability of a license during a time segment is lower than the threshold, the system marks that license as available for granting during that time segment and records the license identifier, the expected start and end times of the available grantable time segment, and the confidence level of the grant in the authorization sequence. The system constructs the authorization sequence in chronological order. The first element of the sequence corresponds to the earliest possible time point for obtaining authorization and the corresponding license resource, with subsequent elements arranged in chronological order. When constructing the authorization sequence, the system considers the urgency of the license request and the resource requirements. If a request requires multiple licenses, the system schedules authorization plans for multiple license resources in the sequence, ensuring that licenses with lower usage probabilities are prioritized while meeting the demand.

[0083] Based on the above embodiments, as an optional implementation method, the method of determining the first authorization sequence of the current license request within a future time window based on the usage probability in S203 can be specifically implemented through the following steps S2031-S2035.

[0084] S2031: Divide the future time window into multiple consecutive time segments and identify candidate licenses in each time segment whose probability of use is lower than a preset probability threshold; A time segment refers to a time unit obtained by equally dividing a future time window according to a predefined time granularity. Each time segment has a fixed time length and a clear start and end time boundary. The granularity of the time segment division is determined according to the precision requirements of the license scheduling. A finer granularity provides more precise license allocation control but increases computational complexity, while a coarser granularity reduces computational overhead but sacrifices scheduling flexibility.

[0085] Among them, candidate licenses refer to occupied licenses whose probability of use is lower than a preset probability threshold within a certain time segment. Although the license is currently occupied, it is predicted based on the probability of use that there is a high probability that it will be released within that time segment, and therefore it is included in the candidate license set as a potential allocable resource.

[0086] Specifically, the system first determines the start and end times of the future time window and calculates the total duration of the future time window. The system determines the duration of a single time segment based on a preset time segment granularity; this duration is specified through configuration parameters or dynamically calculated according to business needs. The system performs the time window segmentation operation, starting from the start time of the future time window and iteratively increasing the time segment duration as the step size, generating a new time segment with each iteration. The system records the sequence number, start time, and end time of each time segment to ensure that adjacent time segments are sequentially continuous without gaps. The system continues the segmentation operation until the end time of the future time window is reached or exceeded. If the end time of the last time segment exceeds the end time of the future time window, the system adjusts the end time of that time segment to match the end time of the future time window to maintain boundary consistency.

[0087] The system stores all generated time segments in a time segment sequence data structure, which organizes all time segments chronologically. The system performs a candidate license identification operation for each time segment. It iterates through all occupied licenses in the static license pool, reading the usage probability value calculated for each license in the preceding steps. The system compares the usage probability of a license with a preset probability threshold to determine if the probability is less than the threshold. If a license's usage probability is less than the threshold, the system marks it as a candidate license for the current time segment and adds its identifier to the candidate license list for that time segment.

[0088] The system continues to check the next occupied license, repeating the probability comparison and candidate license marking process until all occupied licenses have been traversed. The system generates a candidate license set for the current time segment, containing all eligible candidate licenses. The system repeats the above identification process, constructing a candidate license set for each time segment in the time segment sequence.

[0089] S2032: Starting from the initial time segment, calculate the maximum time span that each candidate license can continuously cover, and the average usage probability within the maximum time span; The starting time segment refers to the first time segment in the time sequence after the future time window is divided. The starting time of this time segment is the same as the starting time of the future time window. The continuous coverage capability assessment of candidate licenses starts from this time segment to ensure that the authorization sequence can provide effective license allocation from the beginning of the future time window.

[0090] The maximum time span refers to the total time length corresponding to the number of time segments that a candidate license can continuously cover. This span is determined by identifying how many consecutive time segments a candidate license continuously appears in the candidate license set starting from the initial time segment. The calculation of the maximum time span terminates when the continuity is interrupted in a certain time segment. The maximum time span reflects the continuous availability of the candidate license in the time dimension.

[0091] The average usage probability refers to the arithmetic mean of the usage probabilities of a candidate license across all time segments covered by its maximum time span. This average value comprehensively reflects the overall occupancy risk level of the candidate license within the continuous coverage area. The lower the average usage probability, the smaller the overall risk of the candidate license being occupied throughout the coverage area, making it more suitable as an allocation target.

[0092] Specifically, the system first locates the starting time segment in the time segment sequence and reads the candidate license set for that time segment. For each candidate license in the starting time segment's candidate license set, the system performs calculations on the maximum time span and average usage probability. The system then traverses the time segment sequence backward from the starting time segment, initializing a counter to record the number of consecutively covered time segments and an accumulator to accumulate the total usage probability within consecutively covered intervals.

[0093] The system checks whether the current candidate license appears in the candidate license set of the currently traversed time segment. If the current candidate license exists in the candidate license set of the current time segment, the system increments a counter to indicate that the time segment is covered by the candidate license, and simultaneously reads the usage probability value corresponding to the candidate license in the current time segment and adds it to the accumulator. The system continues to move to the next time segment in the time segment sequence and repeats the candidate license existence check and counter accumulation operation. If the current candidate license no longer appears in the candidate license set of a certain time segment, it means that the continuous coverage of the candidate license is interrupted at this point, and the system stops traversing subsequent time segments for that candidate license.

[0094] The system reads the current value of the counter, which represents the number of consecutive time segments covered by the candidate license. The system multiplies the number of consecutively covered time segments by the duration of a single time segment to calculate the maximum time span of the candidate license. The system reads the cumulative sum of usage probabilities from the accumulator, divides this sum by the number of consecutively covered time segments, and calculates the average usage probability of the candidate license within the maximum time span. The system records the calculation results, storing the candidate license identifier, maximum time span, and average usage probability as an evaluation record in the candidate license evaluation list. The system repeats the above calculation process, calculating the maximum time span and average usage probability for each candidate license in the candidate license set for the starting time segment.

[0095] S2033: Calculate the continuity score based on the maximum time span and average usage probability, and determine the candidate license with the highest continuity score as the first allocation license; Among them, the continuity score is a comprehensive evaluation index calculated by combining the two dimensions of the maximum time span of the candidate license and the average usage probability. This score is used to quantify the quality of the candidate license as an allocation target. When calculating the score, the maximum time span contributes a positive weight because a longer continuous coverage time means that the license can provide more durable service for the request and reduce the number of subsequent switching. The average usage probability contributes a negative weight because a lower average usage probability means that the license is less likely to be actually occupied within the coverage period and the allocation security is higher. The continuity score integrates the two factors of time coverage capability and allocation risk into a single comparable value.

[0096] The first allocation license refers to the candidate license with the highest continuity score among all candidate licenses in the initial time segment. This license is selected as the primary allocation target for the authorization sequence at the beginning of the future time window.

[0097] Specifically, the system first reads the candidate license evaluation list generated in the previous step, which contains evaluation records for all candidate licenses in the starting time segment. The system then performs a continuity score calculation for each candidate license evaluation record in the evaluation list. The system reads two values ​​from the evaluation record: the maximum time span and the average usage probability. The system performs a continuity score calculation, using the maximum time span as a positive contribution factor and the inverse or reciprocal of the average usage probability as a negative contribution factor. The system normalizes the maximum time span by dividing it by the theoretical maximum time span or applying other normalization methods to map the time span to a standard numerical range. The system converts the average usage probability by subtracting it from the calculated value to obtain the inverse probability value; a higher inverse probability value indicates a lower usage risk.

[0098] The system multiplies the normalized maximum time span by a weighting coefficient to obtain the time span score, and multiplies the converted average usage probability by another weighting coefficient to obtain the probability score. The system then adds the time span score to the probability score or calculates the continuity score for the candidate permit through other combinations. The weighting coefficients reflect the relative importance of time coverage and usage risk in permit selection decisions; adjusting these coefficients controls the emphasis placed on these two factors in the scoring calculation. The system performs numerical verification on the calculated continuity score to ensure that the score value is within the expected range and that there are no calculation anomalies. The system records the continuity score in the corresponding candidate permit evaluation record.

[0099] The system repeats the scoring process, calculating a continuity score for each candidate license evaluation record in the evaluation list. The system sorts all candidate licenses by their continuity scores, arranging the evaluation records in descending order of continuity score. The system selects the candidate license evaluation record that appears first in the sorted list; this record corresponds to the candidate license with the highest continuity score. The system reads the candidate license identifier from this evaluation record and designates this license as the first allocation license.

[0100] S2034: Starting from the time segment after the maximum time span, determine the second allocation permission for the remaining time segments within the future time window; The remaining time segment refers to the set of time segments remaining in the time segment sequence of the future time window after deducting the time segments already covered by the first allocation license. This set includes all time segments from the first time segment after the end of the first allocation license coverage until the end of the future time window. The remaining time segment represents the time area where license allocation has not yet been completed.

[0101] The second allocation license refers to the allocation license determined for the remaining time segment. This license is determined by repeatedly performing candidate license screening, continuous coverage capability assessment and continuity score calculation for the remaining time segment. The second allocation license may be a single license or a collection of multiple licenses. When the remaining time segment is long, it is necessary to determine multiple second allocation licenses to fully cover the entire remaining time range.

[0102] Specifically, the system first reads the time segment range covered by the first allocation license and determines the end time segment of that range. The system locates the position of this end time segment in the time segment sequence and uses the first time segment after that position as the starting time segment of the remaining time segments. The system checks if the remaining time segments are empty. If the coverage of the first allocation license extends to the end time segment of the future time window, it means the future time window is fully covered and there is no need to determine the second allocation license. The system terminates the current step and directly proceeds to the authorization sequence generation step. If the remaining time segments are not empty, the system reads the candidate license set of the starting time segment of the remaining time segments. The system performs a continuous coverage capability assessment for each candidate license in this candidate license set, traversing the time segment sequence backward from the starting time segment of the remaining time segments, checking the occurrence of candidate licenses in consecutive time segments. The system calculates the maximum time span that each candidate license can continuously cover within the remaining time segment range. The calculation process is the same as the calculation method for the first allocation license, traversing the time segments and checking the existence of candidate licenses until continuity is interrupted or the future time window ends.

[0103] The system simultaneously calculates the average usage probability of each candidate license within its maximum time span, sums the usage probabilities of each time segment within the coverage interval, and divides by the number of covered time segments. Based on the maximum time span and average usage probability, the system calculates a continuity score for each candidate license using the same method as the score calculation for the first allocation license, comprehensively considering time coverage capability and usage risk. The system sorts all candidate licenses by their continuity scores and selects the candidate license with the highest continuity score as the allocation license for the current remaining time segment.

[0104] The system adds the allocated license to the second allocated license set and records the time segment range covered by the allocated license. The system updates the remaining time segments, removing time segments already covered by the current allocated license from the remaining time segments, and calculates the new range of remaining time segments. The system checks whether the updated remaining time segments are empty. If there are still uncovered time segments, the system repeats the above candidate license screening, evaluation, and selection process to determine the next allocated license and add it to the second allocated license set.

[0105] S2035: Combine the first allocation license and the second allocation license in chronological order to generate the first authorization sequence.

[0106] Specifically, the system first creates an empty authorization sequence data structure, which organizes authorization information in the form of an ordered list or a time-indexed map. The system reads the complete information of the first allocated license, including the license identifier and the time segment range covered by the license. The system converts the information of the first allocated license into authorization sequence elements, each containing three key attributes: license identifier, start time, and end time. The system calculates the start time of the first allocated license's coverage area, which is equal to the start time of the first allocated license's start time segment, i.e., the start time of the future time window. The system calculates the end time of the first allocated license's coverage area, which is equal to the end time of the first allocated license's end time segment. The system inserts the constructed authorization sequence element into the authorization sequence data structure; since this is the first element and is arranged chronologically, it is at the beginning of the sequence. The system reads the second set of allocated licenses, which contains information for zero or more allocated licenses. The system sorts the second set of allocated licenses according to the chronological order of the time segment ranges covered by the second allocated licenses, ensuring the correct chronological order is maintained when subsequent authorization sequences are inserted. The system iterates through the sorted second set of allocated licenses, performing authorization sequence element construction and insertion operations for each allocated license. The system reads the license identifier and the time segment range covered by the currently allocated license, and calculates the start and end times of the coverage. The system creates a new license sequence element, populating it with the license identifier, start and end time attributes. The system inserts the new license sequence element into the license sequence data structure in chronological order, immediately following the previous license sequence element.

[0107] The system continues processing the next allocation license in the second allocation license set, repeating the element construction and insertion process until all second allocation licenses have been processed. The system performs integrity verification on the constructed license sequence, checking for continuous and uninterrupted temporal connections between elements and verifying that the start time of each element is equal to or greater than the end time of the previous element. The system calculates the total time range covered by the license sequence, obtaining the effective coverage interval of the license sequence by reading the start time of the first element and the end time of the last element.

[0108] The system compares the coverage of the licensed sequence with future time windows to identify whether the licensed sequence completely covers the future time window or has uncovered time gaps. The system adds metadata information to the licensed sequence, recording statistical information such as the creation time, the number of licenses included, the total coverage duration, and the average continuity score. The system stores the first generated licensed sequence in the licensed sequence library and assigns it a unique identifier for subsequent reference and management.

[0109] Based on the above embodiments, as an optional implementation method, the method of generating the second authorization sequence according to the second scheduling strategy corresponding to the dynamic license pool in S104 can be specifically implemented through the following steps S301-S304.

[0110] S301: Extract the request priority identifier and business type from the task attributes of the current license request, and calculate the urgency index of the current license request based on the preset priority weight mapping table and business type urgency mapping table. Among them, the request priority identifier is a tag value that identifies the importance level of the current license request. This identifier is graded through a predefined priority classification system, and different priority identifiers correspond to different service guarantee levels and resource allocation priorities; the business type refers to the business category to which the current license request belongs. This category is divided according to dimensions such as business domain, application scenario, and service nature. Different business types have different timeliness requirements and urgent processing needs.

[0111] The priority weight mapping table is a data table that stores the mapping relationship between request priority identifiers and corresponding weight values. Each priority identifier is configured with a weight value, and the larger the weight value, the higher the priority.

[0112] The business type urgency mapping table is a data table that stores the mapping relationship between business types and their corresponding urgency coefficients. This table is configured with an urgency coefficient for each business type, and the urgency coefficient reflects the sensitivity of this type of business to response time.

[0113] The urgency index is a numerical indicator calculated by combining the priority of the request and the urgency of the business type. This index quantifies the degree of urgency of the current license request for system resources. The higher the urgency index, the faster the request needs to obtain license allocation.

[0114] Specifically, the system first reads the complete data structure of the current permission request and locates the task attribute field from the request data. The system parses the task attribute field and extracts two key attribute values: request priority identifier and business type. The system performs format validation on the extracted request priority identifier to confirm that it conforms to the predefined priority identifier specification. The system performs format validation on the extracted business type to confirm that the type identifier exists in the system's supported business type set. The system accesses the priority weight mapping table, which uses the request priority identifier as the query key and the corresponding weight value as the query result. The system uses the extracted request priority identifier to perform a query operation in the priority weight mapping table to retrieve the weight value corresponding to that priority identifier. The system reads the weight value returned by the query, which represents the weight contribution of the current request in the priority dimension. The system accesses the business type urgency mapping table, which uses the business type identifier as the query key and the corresponding urgency coefficient as the query result. The system uses the extracted business type to perform a query operation in the business type urgency mapping table to retrieve the urgency coefficient corresponding to that business type. The system reads the urgency coefficient returned by the query, which represents the urgency of the current request's business type in the timeliness dimension. The system calculates the urgency index by combining the priority weight value with the urgency coefficient. The system then multiplies the priority weight value by a preset priority influence factor to obtain the priority contribution component. Next, the system multiplies the urgency coefficient by a preset business type influence factor to obtain the business type contribution component. Finally, the system adds the priority contribution component and the business type contribution component, or combines them using a weighted summation method, to calculate the overall urgency index.

[0115] S302: Calculate the ratio of the number of allocated licenses to the total capacity of the dynamic license pool to obtain the current load factor of the dynamic license pool; The number of allocated licenses refers to the total number of licenses currently in an occupied state in the dynamic license pool. This number is obtained by counting all license entries marked as occupied in the dynamic license pool. The number of allocated licenses changes dynamically with the allocation and revocation of licenses.

[0116] The total capacity of the dynamic license pool refers to the upper limit of the total number of licenses that the dynamic license pool can accommodate. This capacity is configured during system initialization or dynamically adjusted according to the total system resources. The total capacity represents the maximum number of concurrent licenses that the system can support at the same time.

[0117] The current load factor refers to the proportion of the number of allocated licenses to the total capacity of the dynamic license pool. This proportion reflects the resource utilization and remaining available capacity of the dynamic license pool. The higher the current load factor, the more strained the license pool resources are and the fewer licenses are available for allocation.

[0118] Specifically, the system first accesses the data structure of the dynamic license pool, which maintains the status information and allocation records of all dynamic licenses. The system iterates through all license entries in the dynamic license pool, reading the status flag field of each entry. The system checks the status flag of each license entry to determine if it is in an occupied state. The system initializes a counter to accumulate the number of licenses in an occupied state. The system increments the counter for each occupied license entry, adding one to the current value. The system continues to iterate through the next license entry, repeating the status check and count accumulation process until all license entries in the dynamic license pool have been traversed. The system reads the final value of the counter, which represents the number of licenses allocated in the dynamic license pool. The system then reads the total capacity configuration parameter of the dynamic license pool, which is stored in the system configuration database or the license pool's metadata. Finally, a ratio calculation is performed to obtain the current load factor of the dynamic license pool.

[0119] S303: Calculate the dynamic operation gap threshold based on the urgency index and the current overall load. The dynamic operation gap threshold is negatively correlated with the urgency index and negatively correlated with the current load rate. The dynamic operation gap threshold is a critical value for the user operation interval used to determine whether an occupied license is idle and thus trigger a revocation operation. This threshold is dynamically calculated based on the urgency of the current license request and the system load. The smaller the dynamic operation gap threshold, the lower the system's tolerance for license idleness and the more actively it will reclaim idle licenses to meet urgent requests.

[0120] Specifically, the system first reads the urgency index calculated in the preceding steps, which reflects the urgency of the current license request's demand for resources. The system then reads the current load rate calculated in the preceding steps, which reflects the resource scarcity of the dynamic license pool. Next, the system reads a preset baseline operation gap threshold, which represents the standard time interval for determining license idleness under normal load and priority conditions. The system then performs a dynamic operation gap threshold calculation, based on the baseline threshold and adjusted according to the urgency index and the current load rate. Finally, the system calculates the impact of the urgency index adjustment on the threshold, performs numerical normalization on the urgency index, and maps the index to a standard numerical range by dividing it by the theoretical maximum value of the urgency index or applying other normalization methods.

[0121] The system calculates the impact of the current load rate on threshold adjustments, directly using the current load rate value or transforming it to obtain a load adjustment coefficient, which is negatively correlated with the current load rate. The system combines the urgency adjustment coefficient and the load adjustment coefficient, calculating a comprehensive adjustment coefficient through multiplication, weighted averaging, or other combinations. Finally, the system multiplies the baseline operating gap threshold by the comprehensive adjustment coefficient to obtain the dynamically adjusted operating gap threshold.

[0122] Based on the above embodiments, as an optional implementation, the method of calculating the dynamic operation gap threshold according to the urgency index and the current overall load in S303 can be implemented through the following steps: Calculate the comprehensive scheduling factor based on the urgency index and the current load rate; determine the dynamic operation gap threshold corresponding to the interval classification level based on the interval classification level of the comprehensive scheduling factor.

[0123] Among them, the comprehensive scheduling factor refers to a comprehensive evaluation index calculated by combining the urgency index of the current license request and the current load rate of the dynamic license pool. This factor quantifies the strength of the basis for the system to make license scheduling decisions in the current state, and the value of the comprehensive scheduling factor comprehensively reflects the urgency of the request and the tension of system resources.

[0124] Interval-based grading refers to dividing the range of values ​​of the comprehensive scheduling factor into segments according to a preset numerical interval. Each numerical interval corresponds to a grade, and different grades represent different degrees of scheduling urgency. Interval-based grading discretizes continuous comprehensive scheduling factor values ​​into a finite number of grades, making it easier for the system to adopt differentiated recycling strategies.

[0125] Specifically, the system first reads the urgency index calculated in the preceding steps, which reflects the urgency of the current license request's demand for resources. The system then reads the current load rate calculated in the preceding steps, which reflects the resource scarcity of the dynamic license pool. The system performs a comprehensive scheduling factor calculation, which combines the urgency index and the current load rate. The system normalizes the urgency index by reading its theoretical maximum value and dividing it by this maximum value to obtain the normalized urgency index. The normalization formula is U_norm = U / U_max, where U is the urgency index, U_max is the maximum value of the urgency index, and the normalized U_norm ranges from zero to one. The system verifies the current load rate, confirming that it is either a value between zero and one or a percentage value between zero and one hundred. If the current load rate is a percentage, the system divides it by one hundred to convert it to a value between zero and one, ensuring consistency with the normalized urgency index's range. The system reads the weight parameters from the comprehensive scheduling factor calculation formula. These weight parameters include an urgency weight α and a load rate weight β. The two weights satisfy the constraint α + β = 1. These weight parameters determine the relative contribution ratios of the urgency index and the current load rate to the comprehensive scheduling factor. The system performs a weighted summation calculation. The comprehensive scheduling factor calculation formula is S = α × U_norm + β × L, where S is the comprehensive scheduling factor, α is the urgency weight, U_norm is the normalized urgency index, β is the load rate weight, and L is the current load rate. The system multiplies the normalized urgency index by the urgency weight to obtain the urgency contribution component, and multiplies the current load rate by the load rate weight to obtain the load rate contribution component. The two contribution components are then added together to obtain the value of the comprehensive scheduling factor.

[0126] As illustrated in one example, assume the system is configured with a maximum urgency index U_max of 100, an urgency weight α of 0.6, and a load factor weight β of 0.4. The current urgency index U of the license request is 70, and the current load factor L of the dynamic license pool is 0.8. The system first calculates the normalized urgency index U_norm = 70 / 100 = 0.7. The system then calculates the comprehensive scheduling factor S = 0.6 × 0.7 + 0.4 × 0.8 = 0.4² + 0.3² = 0.74.

[0127] The system verifies the calculated comprehensive scheduling factor within its numerical range, confirming that the value is between zero and one. Outliers outside this range trigger an error handling process. The system reads a preset interval division configuration table, which defines the segmented intervals of the comprehensive scheduling factor's value range and their corresponding level identifiers. The interval division determination rule is as follows: when S is in the interval [0, T1), level G=1; when S is in the interval [T1, T2), level G=2; when S is in the interval [T2, T3), level G=3, and so on, until S is in the interval [T(n-1), 1], where Ti is the upper bound threshold of the i-th interval. The system iterates through each interval definition in the interval division configuration table. Each interval definition includes a lower bound, an upper bound, and a corresponding level identifier. The system determines whether the calculated comprehensive scheduling factor falls within the currently checked interval range by comparing whether the comprehensive scheduling factor is greater than or equal to the lower bound and less than the upper bound.

[0128] Continuing with the previous embodiment, assume that the interval partitioning configuration table defines five levels: Level 1 corresponds to the interval [0, 0.2), Level 2 corresponds to the interval [0.2, 0.4), Level 3 corresponds to the interval [0.4, 0.6), Level 4 corresponds to the interval [0.6, 0.8), and Level 5 corresponds to the interval [0.8, 1]. Since the calculated comprehensive scheduling factor S=0.74 falls within the interval [0.6, 0.8), the system determines the interval partitioning level G=4.

[0129] After locating the interval containing the comprehensive scheduling factor, the system reads the corresponding interval classification level identifier, which is represented by a numerical number or text label. The system records the determined interval classification level and stores the level information in the processing context of the current permission request. The system reads a preset level threshold mapping table, which stores the mapping relationship between each interval classification level and the corresponding dynamic operation gap threshold. The formula for determining the dynamic operation gap threshold is Δt=f(G), where Δt is the dynamic operation gap threshold, and f(G) is the mapping function from level to threshold, implemented through a table lookup. The system uses the determined interval classification level as the query key to perform a query operation in the level threshold mapping table, retrieving the dynamic operation gap threshold value corresponding to that level. The system reads the dynamic operation gap threshold value returned by the query, which represents the critical time interval for determining permission idleness at the current level.

[0130] Continuing with the previous embodiment, assume that the level threshold mapping table defines the following mapping relationship: Level 1 corresponds to a threshold of 60 seconds, Level 2 corresponds to a threshold of 45 seconds, Level 3 corresponds to a threshold of 30 seconds, Level 4 corresponds to a threshold of 15 seconds, and Level 5 corresponds to a threshold of 5 seconds. Since the determined interval is divided into four levels, the system looks up the table to obtain the dynamic operation interval threshold Δt = f(4) = 15 seconds.

[0131] S304: Monitor the user operation time interval corresponding to each occupied license in the dynamic license pool in real time. When the user operation time interval is detected to exceed the dynamic operation interval threshold, mark the occupied license as a reclaimable license and generate a second authorization sequence containing the reclaimable license identifier. The second authorization sequence is used to reclaim the occupied license and authorize the current license request.

[0132] The user operation time interval refers to the time difference between the time when the user last performed an operation corresponding to the occupied license and the current time. This time interval reflects the active usage status of the license at the current moment. The longer the time interval, the longer the license is idle and the less active the user is in using the license.

[0133] Among them, reclaimable licenses refer to licenses that have been occupied when the user operation interval exceeds the dynamic operation interval threshold. These licenses are determined to be in an idle state and meet the conditions for reclamation. As reclaimable licenses are candidates for reclamation, the resources they occupy are released and redistributed to waiting license requests.

[0134] Specifically, the system first initiates a real-time monitoring process for the dynamic license pool. This process runs continuously and periodically checks the operation interval of occupied licenses. The system accesses the data structure of the dynamic license pool, traversing all license entries in the pool that are in an occupied state. For each occupied license, the system reads its associated user operation record, which contains the timestamp information of the user's most recent operation. The system obtains the current system time as a reference time point for calculating the time interval. The system calculates the user operation time interval by subtracting the timestamp of the user's most recent operation from the current system time to obtain the time difference value. The system performs unit conversion on the calculated time interval, uniformly converting the time difference to the same time unit as the dynamic operation interval threshold to ensure the consistency of values ​​in subsequent comparison operations.

[0135] The system compares the calculated user operation time interval with the dynamic operation gap threshold determined in the preceding steps. The system determines if the user operation time interval is greater than the dynamic operation gap threshold. If the user operation time interval is greater than the threshold, the license meets the recycling conditions; if the user operation time interval is less than or equal to the threshold, the license is still in active use and does not meet the recycling conditions. The system marks occupied licenses that meet the recycling conditions, updating their status from occupied to recyclable. The system adds the identifier of the recyclable license to the recyclable license list, which collects all licenses that meet the recycling conditions.

[0136] The system continues to check the next occupied license, repeating the operation interval calculation, threshold comparison, and status marking process until all occupied licenses have been traversed. The system checks the list of recyclable licenses to determine if it contains at least one recyclable license. If the list is empty, it means there are currently no licenses that meet the recycling conditions. The system records the monitoring results and continues with subsequent monitoring cycles or adopts other license allocation strategies. If the list is not empty, the system selects one or more recyclable licenses from the list as recycling targets. The system determines the number of licenses to recycle based on the number of recyclable licenses and the current license request requirements. If the request requires only one license, one recyclable license is selected; if the request requires multiple licenses, the corresponding number of recyclable licenses are selected. When selecting recyclable licenses, the system applies a priority ranking rule, prioritizing the license with the longest operation interval or applying other optimization strategies to ensure the selection of the most suitable recycling target.

[0137] The system creates a data structure for a second authorization sequence, which contains revocation operation instructions and target license information. The system populates the second authorization sequence with identifiers of the selected revocable licenses, recording the list of licenses to be revoked. The system adds a revocation operation type flag to the second authorization sequence, specifying that the sequence is used to perform license revocation and reallocation operations. The system records the identifier of the current license request in the second authorization sequence, indicating that the revoked license will be allocated to that request. The system records the timestamp and triggering conditions of the revocation operation in the second authorization sequence, including information such as the dynamic operation gap threshold and the operation time interval for revocable licenses.

[0138] In one specific embodiment of this application, the system implements proactive release management for licensed resources in the dynamic license pool. This management mechanism includes three core parts: license service parameter configuration, license application time-series queue management, and proactive license release rules.

[0139] The system configures three core parameters for each licensed service type: minimum retention time, maximum reservation quantity, and corresponding processing module identifier. The minimum retention time defines the shortest duration during which licensed resources must be retained after allocation; during this period, the system does not actively reclaim them to ensure the continuity of user operations. The maximum reservation quantity defines the maximum number of licensed resources the system allows to be reserved; exceeding this threshold triggers an active release process. The processing module identifier points to the specific functional module responsible for that licensed service type, enabling differentiated management strategies. The system sets different parameter values ​​for different licensed services based on business priority; higher-priority services are configured with longer minimum retention times and larger maximum reservation quantities.

[0140] The system maintains a license application queue, storing pending license requests in chronological order. Each application record contains five fields: current application quantity, license user ID, license module ID, license acquisition time, and corresponding processing module ID. The system defines rules for setting the license user ID and module ID for each application type. For example, CAD design applications use a combination of user account and workstation ID, while simulation analysis applications use a combination of project number and user account.

[0141] The system handles multiple applications with the same license user ID and module ID specially. When a new application with the same ID is received, the system does not add up the application count, but only updates the application timestamp to avoid duplicate counting. When available licenses, the system sends requests to the license service based on the application sequence, prioritizing the earliest application at the head of the queue. The system increases the processing priority of near-expiration applications and sends urgent requests, while quickly removing expired applications from the time-series queue to free up queue space.

[0142] The system initiates proactive license release based on two triggering conditions: first, the current reserved number is greater than the maximum reserved number; second, the license holding time is greater than the minimum retention time. The system continuously monitors allocated license records, calculates the license holding time and compares it with the minimum retention time, and calculates the total reserved number and compares it with the maximum reserved number. When the conditions are met, the release process is initiated.

[0143] The system calls the corresponding processing module to execute the license release method based on the application type, implementing different release strategies for different application types. CAD design applications check for unsaved data before release, simulation analysis applications check for running tasks, and document editing applications determine the user's operation interval based on the previously calculated dynamic operation interval threshold. Among applications that meet the minimum retention time, the system comprehensively considers application characteristics and releases licenses based on application sequence as much as possible, prioritizing the release of licenses acquired earlier and currently idle. Simultaneously, it checks the license application sequence queue and immediately allocates the released licenses to waiting applications, achieving rapid flow of license resources and timely fulfillment of new applications.

[0144] When releasing licenses for users with the same license identifier and module identifier, the system maintains a non-decreasing application quantity. When releasing a license held by a user, the system checks if that user has any pending application records. If so, the released license is directly allocated to that application without reducing its application quantity, ensuring that users' license needs are continuously met. Through this mechanism, the system achieves dynamic balancing and efficient utilization of license resources.

[0145] The following are system embodiments of this application, which can be used to execute the method embodiments of this application. For details not disclosed in the system embodiments of this application, please refer to the method embodiments of the application.

[0146] Please see Figure 2 This illustration shows a schematic diagram of a licensing and authorization scheduling system provided in an exemplary embodiment of this application. The system can be implemented as all or part of a system through software, hardware, or a combination of both. The licensing and authorization scheduling system includes: The request module is used to respond to the current license request submitted by the user and extract the task attributes of the current license request; The stability calculation module is used to calculate the stability requirement index of the current license request based on the task attributes, and allocate the current license request to the corresponding license pool according to the stability requirement index. The first scheduling module is used to allocate the current license request to the static license pool when the stability requirement index is greater than the preset pooling threshold; and to generate a first authorization sequence according to the first scheduling strategy corresponding to the static license pool. The second scheduling module is used to allocate the current license request to the dynamic license pool when the stability requirement index is less than or equal to the preset pooling threshold, and to generate a second authorization sequence according to the second scheduling strategy corresponding to the dynamic license pool. The execution module is used to authorize the current license request according to the first authorization sequence or the second authorization sequence, wherein the license switching frequency of the first authorization sequence is less than the license switching frequency of the second authorization sequence.

[0147] This application also provides a computer storage medium that can store multiple instructions. The instructions are adapted to be loaded by a processor and executed as described in the above embodiments. For details of the execution process, please refer to the specific description of the embodiments, which will not be repeated here.

[0148] Please see Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device 300 may include: at least one processor 301, at least one network interface 304, user interface 303, memory 305, and at least one communication bus 302.

[0149] The communication bus 302 is used to enable communication between these components.

[0150] The user interface 303 may include a display screen and a camera.

[0151] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0152] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 305, and by calling data stored in the memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of digital signal processing, field-programmable gate array, or programmable logic array. The processor 301 may integrate one or more of the following: a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0153] The memory 305 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 305 may include a non-transitory computer-readable medium. The memory 305 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data involved in the various method embodiments described above, etc. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. Figure 3 As shown, the memory 305, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for a licensing and scheduling method.

[0154] exist Figure 3 In the electronic device 300 shown, the user interface 303 is mainly used to provide an interface for users to input data and obtain user input data; while the processor 301 can be used to call an application program stored in the memory 305 that provides a license scheduling method. When executed by one or more processors, the electronic device executes one or more methods as described in the above embodiments.

[0155] An electronic device readable storage medium stores instructions that, when executed by one or more processors, cause the electronic device to perform one or more methods as described in the above embodiments.

[0156] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0157] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0158] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.

[0159] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0160] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0161] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0162] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and practical application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure.

Claims

1. A licensing and authorization scheduling method, characterized in that, The method includes: In response to the current license request submitted by the user, extract the task attributes of the current license request; The stability requirement index of the current license request is calculated based on the task attributes, and the current license request is allocated to the corresponding license pool according to the stability requirement index. When the stability requirement index is greater than the preset pooling threshold, the current license request is allocated to the static license pool; and a first authorization sequence is generated according to the first scheduling strategy corresponding to the static license pool. When the stability requirement index is less than or equal to the preset pooling threshold, the current license request is allocated to the dynamic license pool, and a second authorization sequence is generated according to the second scheduling strategy corresponding to the dynamic license pool. The current license request is authorized according to the first authorization sequence or the second authorization sequence, wherein the license switching frequency of the first authorization sequence is less than the license switching frequency of the second authorization sequence.

2. The method according to claim 1, characterized in that, The step of generating the first authorization sequence according to the first scheduling policy corresponding to the static license pool includes: Obtain historical license data for all occupied licenses in the static license pool; The usage characteristic data of each occupied license is extracted from the historical license data, and the usage probability of each occupied license in a future time window is predicted based on the usage characteristic data; Based on the usage probability, determine the first authorization sequence of the current license request within the future time window.

3. The method according to claim 2, characterized in that, The usage characteristic data includes historical occupancy period records, session activity time-series data, and operation interval statistics. Predicting the probability of use of each occupied license within a future time window based on the usage characteristic data includes: Based on the historical occupancy period records, identify a set of historical time periods that have the same time characteristics as the future time window, including weekday attribute, hour interval and date type; Based on the operation interval statistics, the ratio of the number of occupied licensed operation periods in the historical time period set to the total number of historical time periods is calculated to obtain the time period usage frequency; Extract the activity level corresponding to the historical time period set from the session activity time series data, and determine the idle correction coefficient corresponding to the activity level; Multiply the usage frequency of the time period by the idle correction coefficient to obtain the usage probability of each occupied permit within the future time window.

4. The method according to claim 2, characterized in that, Determining the first authorization sequence of the current license request within the future time window based on the usage probability includes: The future time window is divided into multiple consecutive time segments, and candidate licenses with a usage probability lower than a preset probability threshold are identified in each time segment. Starting from the initial time segment, calculate the maximum time span that each candidate license can continuously cover, and the average usage probability within the maximum time span; A continuity score is calculated based on the maximum time span and the average usage probability, and the candidate license with the highest continuity score is determined as the first allocation license; Starting from the time segment following the maximum time span, determine the second allocation permission for the remaining time segments within the future time window; The first allocation license and the second allocation license are combined in chronological order to generate a first authorization sequence.

5. The method according to claim 1, characterized in that, The step of generating the second authorization sequence according to the second scheduling policy corresponding to the dynamic license pool includes: Extract the request priority identifier and business type from the task attributes of the current permission request, and calculate the urgency index of the current permission request based on the preset priority weight mapping table and business type urgency mapping table; Calculate the ratio of the number of allocated licenses to the total capacity of the dynamic license pool to obtain the current load rate of the dynamic license pool; Based on the urgency index and the current overall load, a dynamic operation gap threshold is calculated. The dynamic operation gap threshold is negatively correlated with the urgency index and negatively correlated with the current load rate. The system monitors the user operation time intervals corresponding to each occupied license in the dynamic license pool in real time. When the user operation time interval exceeds the dynamic operation gap threshold, the occupied license is marked as a reclaimable license, and a second authorization sequence containing the reclaimable license identifier is generated. The second authorization sequence is used to reclaim the occupied license and authorize the current license request.

6. The method according to claim 5, characterized in that, The step of calculating the dynamic operation gap threshold based on the urgency index and the current overall load includes: Calculate the comprehensive scheduling factor based on the urgency index and the current load rate; Based on the interval classification level where the comprehensive scheduling factor is located, determine the dynamic operation gap threshold corresponding to the interval classification level.

7. The method according to claim 1, characterized in that, The calculation of the stability requirement index for the current license request based on the task attributes includes: Extract the task duration, operation frequency, and session type from the task attributes; Calculate the duration stability score corresponding to the task duration, the interaction stability score corresponding to the operation frequency, and the type stability score corresponding to the session type, respectively. The duration stability score is positively correlated with the task duration, and the interaction stability score is negatively correlated with the operation frequency. The stability index of the current license request is obtained by weighting and summing the duration stability score, the interaction stability score, and the type stability score according to preset weights.

8. A licensing and authorization scheduling system, characterized in that, The system includes: The request module is used to extract the task attributes of the current license request in response to the current license request submitted by the user. The stability calculation module is used to calculate the stability requirement index of the current license request based on the task attributes, and allocate the current license request to the corresponding license pool according to the stability requirement index. The first scheduling module is used to allocate the current license request to the static license pool when the stability requirement index is greater than the preset pooling threshold; and to generate a first authorization sequence according to the first scheduling strategy corresponding to the static license pool. The second scheduling module is used to allocate the current license request to the dynamic license pool when the stability requirement index is less than or equal to the preset pooling threshold, and generate a second authorization sequence according to the second scheduling strategy corresponding to the dynamic license pool. An execution module is configured to authorize the current license request according to the first authorization sequence or the second authorization sequence, wherein the license switching frequency of the first authorization sequence is less than the license switching frequency of the second authorization sequence.

9. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions, which are adapted to be loaded by a processor and executed as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, The device includes a processor, a memory, and a transceiver, wherein the memory is used to store instructions, the transceiver is used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1 to 7.

Images