A new method of software authorization based on dynamic context awareness

Abstract

The application discloses a new software authorization method based on dynamic context perception, aiming at solving the defects of the existing static authorization system, such as easy cracking, poor flexibility, insufficient privacy protection and the like. After the software is started, the user behavior, environment and anonymized device data are continuously collected through a lightweight client agent, a risk score is generated through logical regression model feature extraction and risk analysis, is mapped into an authorization decision and a short-term valid token is dynamically generated, and the valid period thereof is adaptively adjusted according to the risk level. Through a distributed verification mechanism, local verification and server synchronization are realized, and in combination with offline adaptation, degradation mode and grace period design, a continuous authorization closed loop is formed. The application converts authorization into a dynamic and continuous process, significantly improves the cracking prevention capability and scene adaptability, strengthens privacy protection, optimizes resource consumption and user experience, and is suitable for various software authorization scenes.

Description

Technical Field

[0001] This invention relates to the field of software licensing technology, and specifically to a novel software licensing method based on dynamic context awareness. Background Technology

[0002] In the field of computer software, software licensing is a core technical means to protect software intellectual property rights and prevent illegal copying and abuse. It is widely used in commercial software, professional tool software, and various paid applications. Currently, the most mainstream and closest existing technology to this invention is a static software licensing system based on hardware fingerprints. Its core design idea is to use the uniqueness of hardware information to bind the license to the device.

[0003] Specifically, the implementation scheme of this type of static authorization system is as follows: Hardware characteristic information of the user's device is collected, including but not limited to MAC address, CPU serial number, and hard drive serial number. This information is then integrated to generate a unique device fingerprint. During software installation or initial runtime, this device fingerprint is sent to the authorization server. The server verifies whether the device fingerprint has been legally authorized by querying the authorization database. If the verification is successful, the server returns a permanent or long-term valid license file (usually an encryption key or encrypted file) to the client. Upon subsequent software startup, the client only needs to verify the validity of the license file locally to complete the authorization verification. Some advanced versions of the system additionally support online periodic verification to handle authorization revocation or update requirements. This type of technology is common in various software license management systems and is currently the mainstream implementation method for commercial software protection.

[0004] However, the aforementioned static software licensing system based on hardware fingerprints has many insurmountable technical flaws, as follows: 1. Vulnerable to deception and cracking: The generation of hardware fingerprints relies on the static characteristics of device hardware information, which can be forged by software modification tools (such as applications that modify MAC addresses) or hardware simulation environments (such as virtual machines), allowing attackers to easily bypass device binding mechanisms. At the same time, long-term valid license files are at risk of being reverse engineered and cracked. Attackers can analyze the license generation logic to forge illegal authorizations, seriously damaging the intellectual property rights of software developers.

[0005] 2. Insufficient authorization flexibility: The authorization logic of this type of system is based on a static model of "one-time grant, long-term validity". Once the authorization status is determined, it cannot be dynamically adjusted according to changes in the usage scenario. For example, when the software is running in a high-risk environment such as a public network, the system cannot automatically upgrade the security level of authorization verification; when abnormal user behavior is detected (such as frequent calls to sensitive functions in a short period of time), it cannot restrict the user's access rights in a timely manner, making it difficult to adapt to diverse usage scenario requirements.

[0006] 3. Conflict between network dependency and offline compatibility: For systems that support periodic online verification, the normal use of the software depends on a stable network connection. In offline environments with no network or an unstable network, the software may experience verification failures, limited functionality, or even failure to run. Even for versions that support offline licensing, the licensing period is fixed and cannot be flexibly adjusted according to users' short-term offline needs, which reduces the usability of the software.

[0007] 4. Privacy risks: Such systems require the collection of raw hardware information from devices, which constitutes sensitive user privacy data. The collection and use of this information may violate data protection regulations such as GDPR. In addition, some existing systems transmit or store hardware information in plaintext, further increasing the risk of privacy data leakage.

[0008] 5. Uneven resource consumption: The verification process of static licensing is concentrated in the software startup phase. A large number of hardware information verification and license verification operations will cause software startup delays and affect user experience. On the other hand, long-term valid licenses do not require subsequent dynamic optimization, and their continuous verification logic will cause unnecessary waste of system resources.

[0009] The core root of these shortcomings lies in the "one-time licensing" design philosophy of existing technologies, which ignores the dynamic changes in contextual information such as user behavior, operating environment, and device status during software use. This results in the licensing system failing to achieve a comprehensive balance between security, usability, and privacy protection. Therefore, there is an urgent need for a new software licensing method that can adapt to dynamic usage scenarios and balance security and flexibility to address the deficiencies of existing technologies. Summary of the Invention

[0010] The core objective of this invention is to overcome the technical shortcomings of existing static software licensing systems based on hardware fingerprints, such as susceptibility to cracking, insufficient licensing flexibility, strong network dependence, privacy risks, and uneven resource consumption. It provides a novel software licensing method based on dynamic context awareness. By constructing a real-time context acquisition mechanism, a machine learning-driven risk assessment system, and a risk-adaptive dynamic token generation and verification process, it achieves real-time synchronization between the licensing status and the software usage scenario. This not only improves the anti-cracking capability and privacy protection level of software licensing but also adapts to diverse usage scenarios such as offline and high-risk environments. Simultaneously, it optimizes system resource consumption and user experience, achieving a comprehensive balance between security, flexibility, and usability.

[0011] To achieve the above objectives, the technical solution adopted by this invention is: a new software licensing method based on dynamic context awareness, comprising the following steps: (1) After the software starts, the context collection module continuously collects context data related to software authorization through the lightweight client agent integrated into the software. The context data includes user behavior data, environmental data and device data. (2) The collected context data is transmitted to the risk assessment engine, and the context data is used to perform feature extraction and risk analysis using a preset machine learning model to calculate the risk score. The risk score is then mapped to the corresponding authorization decision according to a preset threshold. (3) Generate a short-term valid dynamic authorization token based on the risk score, wherein the validity period of the dynamic authorization token is negatively correlated with the risk score and dynamically adapted. (4) Perform local token verification on the client through a distributed verification mechanism, and determine the software authorization status based on the verification result: if the token is valid, the software is allowed to run normally; if the token is invalid, security measures are initiated. (5) The dynamic authorization token is updated periodically each time the software is started or at a preset time interval, and steps (1)-(4) are executed in a loop to realize the real-time synchronization of the authorization status and the software usage scenario, forming a continuous authorization closed loop.

[0012] Furthermore, the user behavior data is collected by capturing user input events using hook technology, and includes at least software usage frequency, operation sequence, function usage preferences, and session duration; the environmental data includes network status, geographical location, time information, and system load. Network status includes IP address and connection type, geographical location is obtained through GPS or IP positioning, and system load includes CPU and memory usage; the device data is anonymized device identifiers, which are generated through a combination of multiple hash operations and XOR operations, with the specific formula as follows: ; in, For hash functions, This indicates the XOR operation. For the equipment address, For the equipment Serial number, This is the hard drive serial number of the device.

[0013] Furthermore, step (2) "using a preset machine learning model to extract features and perform risk analysis on the context data, and calculate the risk score" specifically includes: (2.1) Perform feature engineering on the collected raw context data to construct authorization-related feature vectors. The feature vector includes three core features: user behavior anomaly degree, environmental risk index, and device credibility. (2.2) Normalize each feature in the feature vector to the interval [0,1] to obtain the normalized feature vector; (2.3) Input the normalized feature vector into the preset machine learning model, and calculate the risk score R using the formula: ; in, For the feature weight vector, Here, e is the bias term, and e is the natural constant. The preset machine learning model is a logistic regression model; the user behavior anomaly degree is obtained by calculating the deviation value based on the user's historical operation baseline; the environmental risk index is calculated based on the login location change rate and network type risk level; and the device trustworthiness is evaluated based on the historical usage records of the device identifier.

[0014] Furthermore, step (2) also includes an online model update and adaptation step: periodically collect authorization verification data, which includes normal software usage data and attack case data, and use the authorization verification data to update the parameter feature weight vector w, bias term b, and decision threshold of the machine learning model online; The phrase "mapping the risk score to a corresponding authorization decision based on a preset threshold" specifically refers to: When R < α, the risk is considered low, and full functionality permissions for the software are granted. When α≤R<β, it is judged as medium risk, triggering secondary verification or restricting some sensitive functions; When R ≥ β, it is judged as high risk, authorization is immediately suspended and a security audit is initiated; Where α and β are preset risk thresholds, and 0 < α < β < 1, α = 0.3, β = 0.7.

[0015] Furthermore, step (3) "generating a short-term valid dynamic authorization token based on the risk score" specifically includes: the token adopts a hash-based message authentication code structure, using the master key K stored in the server's secure area, the current Unix timestamp t accurate to the second, and the risk score R as inputs, and generating a dynamic authorization token T through the SHA-256 hash function, with the generation formula as follows: ; in, This indicates a connection operation, ensuring the integrity and freshness of the token.

[0016] Furthermore, the validity period Δt of the dynamic authorization token satisfies: ; in, To preset the maximum validity period, The preset scaling constant, The risk score is used to determine the validity period of the token. When the risk score is high, the token validity period is short, and frequent verification is forced. When the risk score is low, the token validity period is long, and the verification frequency is reduced. The dynamic authorization token can be cached on the client during its validity period and needs to be regenerated after it expires. The authorization system supports offline verification. When an offline environment is detected, the validity period of the dynamic authorization token is flexibly extended by reducing the weight of the risk score R in the validity period calculation, ensuring that the software runs normally in an offline environment.

[0017] Furthermore, elliptic curve digital signature algorithms can be introduced to enhance security when generating dynamic authorization tokens, specifically including: (a) Generate a random number k and calculate the point ,in It is the base point of the elliptic curve; (b) Generate a signature (r,s) based on the server's private key d, random number k, current timestamp t, and risk score R, where , Let be the order of the elliptic curve. ; (c) The dynamic authorization token T=(r,s) is used by the client to verify the validity of the dynamic authorization token through the corresponding public key, which is suitable for high security requirements.

[0018] Furthermore, the "distributed verification mechanism" in step (4) specifically includes: (4.1) The client periodically checks whether the locally cached dynamic authorization token has expired; (4.2) When the network is available, the client sends a heartbeat packet to the authorization server. The heartbeat packet contains the current dynamic authorization token and the corresponding risk score. After verification, the authorization server returns a token update instruction to synchronize the token status. (4.3) The authorization server may proactively push a token revocation command to the client based on security requirements, triggering an authorization status adjustment.

[0019] Furthermore, when the dynamic authorization token verification fails, the software does not exit immediately, but enters a downgrade mode and initiates a preset grace period. The downgrade mode includes restricting the use of some software functions. During the grace period, the user is allowed to re-complete the authorization verification. If the valid authorization is still not completed after the grace period ends, the software operation is suspended and relevant logs are recorded.

[0020] Compared to existing static software authorization systems based on hardware fingerprints, this invention achieves multi-dimensional optimizations in security, flexibility, privacy protection, resource utilization, and user experience through a dynamic context-aware mechanism, a machine learning-driven risk assessment system, and a risk-adaptive dynamic token generation and verification process. Specific benefits are as follows: This invention abandons the static license-hardware fingerprint binding model, achieving real-time risk perception through a logistic regression model. Combined with a dynamic authorization token generation mechanism, it generates short-term valid tokens whose validity period dynamically adjusts based on risk scores, ensuring real-time synchronization between authorization status and usage scenarios. Attackers find it difficult to forge dynamically changing context data and cannot crack the short-term valid tokens through reverse engineering. Even if the token is intercepted, it quickly expires due to the validity period limitation. Simultaneously, the online model update and adaptive mechanism can promptly adapt to new attack patterns, and the enhanced elliptic curve digital signature algorithm further improves token anti-counterfeiting capabilities, significantly increasing the security level of software authorization and effectively curbing illegal authorization and piracy.

[0021] This invention breaks through the limitations of existing technologies' "one-time authorization," allowing the authorization status to be dynamically adjusted based on contextual data. In offline environments, by reducing the weight of risk scores in token validity calculations, the token validity period is flexibly extended, solving the problem of poor offline adaptability of static authorization. In high-risk environments such as public networks and VPN usage, the system automatically shortens the token validity period and increases the verification frequency, enhancing security protection levels. For low-risk scenarios of normal user use, the token validity period is extended and the verification frequency is reduced, balancing security and ease of use. This fine-grained dynamic adjustment capability enables the software to adapt to diverse use cases such as commercial software, mobile applications, and IoT device software, significantly improving software usability.

[0022] This invention anonymizes device data by generating device identifiers through multiple hashing and XOR operations, avoiding the direct collection and transmission of raw hardware information and reducing the risk of privacy leaks at the source. Simultaneously, all context data is encrypted and de-identified on the client side, with only feature vectors transmitted to the server, complying with GDPR and other data protection regulations. This resolves the privacy compliance risks caused by the collection of raw hardware information in existing static licensing systems.

[0023] This invention employs a cyclical dynamic verification mechanism, distributing verification processes from the software startup phase to the runtime. Combined with a sliding window averaging method to reduce data acquisition noise and intelligently adjust sampling frequency, it avoids startup delays caused by static authorization, reducing system resource and network bandwidth consumption. Risk assessment is triggered only when context data changes significantly, further reducing unnecessary computational overhead. This enables the software to run efficiently even in resource-constrained scenarios such as mobile devices and IoT terminals, saving device battery life.

[0024] When verification fails, the software does not immediately exit but enters a downgrade mode and initiates a grace period, allowing users to re-authorize within the buffer time. This avoids the problem of complete lockout upon authorization failure in existing technologies, significantly improving reliability and user experience. Looping verification continues in the background without affecting normal user operations. Combined with dynamically adjusted verification frequency, this ensures security while minimizing interference with the user experience, achieving a harmonious balance between security and ease of use.

[0025] This invention constructs a closed-loop dynamic authorization system through the collaborative work of a context acquisition module, a risk assessment engine, a dynamic token generator, and a verification module. Context acquisition provides real-time data input, the risk assessment engine transforms this into intelligent decision-making criteria, the dynamic token generator adjusts the authorization strategy according to the risk intensity, and the verification module executes precise access control. These modules form a dynamically adjusted system that balances security, user experience, and privacy. This system-level optimization is not a simple patchwork of technologies, but rather a fundamental solution to the contradiction between security, flexibility, and privacy protection that existing technologies struggle to balance, through the organic integration of core technologies. It provides a more comprehensive and reliable solution for software authorization. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a flowchart of the new software licensing method of the present invention; Figure 2 This is the software licensing process for this invention. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0029] Example 1 like Figure 1 As shown, this embodiment provides a new software licensing method based on dynamic context awareness, including the following steps: (1) After the software starts, the context collection module continuously collects context data related to software authorization through the lightweight client agent integrated into the software. The context data includes user behavior data, environmental data and device data. (2) The collected context data is transmitted to the risk assessment engine, and the context data is used to perform feature extraction and risk analysis using a preset machine learning model to calculate the risk score. The risk score is then mapped to the corresponding authorization decision according to a preset threshold. (3) Generate a short-term valid dynamic authorization token based on the risk score, wherein the validity period of the dynamic authorization token is negatively correlated with the risk score and dynamically adapted. (4) Perform local token verification on the client through a distributed verification mechanism, and determine the software authorization status based on the verification result: if the token is valid, the software is allowed to run normally; if the token is invalid, security measures are initiated. (5) The dynamic authorization token is updated periodically each time the software is started or at a preset time interval, and steps (1) to (4) are executed in a loop to achieve real-time synchronization of the authorization status and the software usage scenario, forming a continuous authorization closed loop.

[0030] As one implementation method, the user behavior data in this embodiment is collected by capturing user input events using hook technology, including at least software usage frequency, operation sequence, function usage preferences, and session duration. Hook technology can accurately capture user operation details without intruding into the core software code, avoiding interference with the original software operation logic. It can also quickly distinguish between normal operations of authorized users and abnormal behavior of attackers (such as frequent clicks on activation buttons, disordered function calls, etc.), providing accurate behavioral evidence for subsequent risk assessment. The environmental data includes network status, geographical location, time information, and system load. Network status includes IP address and connection type; geographical location is obtained through GPS or IP positioning; and system load includes CPU and memory usage. Comprehensive collection of environmental data can completely reconstruct the software operation scenario. For example, IP address can be used to identify high-risk environments such as public networks and VPNs, and system load can be used to determine whether malicious programs are consuming resources, providing multi-dimensional support for risk level determination. The device data is an anonymized device identifier, which is generated through multiple hash operations and XOR operations. The specific formula is: ; in, For hash functions, This indicates the XOR operation. For the equipment address, For the equipment Serial number, This is the device's hard drive serial number. Through a combination of multiple hash and XOR operations, it can both retain the device's unique identification capability and completely shield the original hardware information. Even if the data is intercepted during transmission or storage, attackers cannot reverse-engineer the device's true hardware information, thus protecting user privacy and security from the source, while also complying with the requirements of GDPR and other data protection regulations regarding the processing of sensitive data.

[0031] As one implementation method, in this embodiment, step (2) "using a preset machine learning model to extract features and perform risk analysis on the context data, and calculate the risk score" specifically includes: (2.1) Perform feature engineering on the collected raw context data to construct authorization-related feature vectors. The feature vector includes three core features: user behavior anomaly degree, environmental risk index, and device trustworthiness. Focusing on these three core features can accurately locate key points of authorization risk, avoid the waste of computing resources and risk assessment bias caused by redundant features, and ensure the pertinence and efficiency of risk analysis.

[0032] (2.2) Normalize each feature in the feature vector to the [0,1] interval to obtain the normalized feature vector; normalization can eliminate the difference in dimensions between different features. For example, the numerical range of user behavior anomaly degree may be different from the numerical range of environmental risk index. After normalization, each feature can have equal weight in risk calculation, ensuring the objectivity and accuracy of risk score calculation.

[0033] (2.3) Input the normalized feature vector into the preset machine learning model, and calculate the risk score R using the formula: ; in, For the feature weight vector, Here, e is the bias term, and e is the natural constant. The preset machine learning model is a logistic regression model. Logistic regression models have the advantages of low computational cost and fast running speed, adapting to the running requirements of lightweight client agents without adding extra performance burden to the software. Furthermore, its output risk score is within the range of [0,1], facilitating the setting of clear risk thresholds and authorization decision rules. The user behavior anomaly degree is calculated based on the deviation value of the user's historical operation baseline. The environmental risk index is calculated based on the login location change rate and network type risk level. The device trustworthiness is evaluated based on the historical usage records of the device identifier. By constructing an evaluation benchmark using historical data, risky behaviors that "deviate from the normal pattern" can be accurately identified. For example, situations such as a user suddenly logging in from an unfamiliar geographical location or a device operating for the first time in a public network environment can be quickly identified through the deviation values ​​of the corresponding features, improving the sensitivity of risk perception.

[0034] As one implementation method, step (2) in this embodiment also includes an online model update and adaptation step: periodically collecting authorization verification data, which includes normal software usage data and attack case data, and using the authorization verification data to update the parameter feature weight vector w, bias term b, and decision threshold of the machine learning model online; the online update mechanism enables the model to continuously adapt to the dynamic changes in the software authorization environment. For example, when new attack methods cause the original risk features to become invalid, the model can adjust its parameters by learning new attack case data, always maintaining the ability to accurately identify risks, and avoiding security vulnerabilities caused by model solidification.

[0035] The phrase "mapping the risk score to a corresponding authorization decision based on a preset threshold" specifically refers to: When R < α, the risk is considered low, and full functionality permissions for the software are granted. When α≤R<β, it is judged as medium risk, triggering secondary verification or restricting some sensitive functions; When R ≥ β, it is judged as high risk, authorization is immediately suspended and a security audit is initiated; Where α and β are preset risk thresholds, and 0 < α < β < 1, α = 0.3, β = 0.7. Setting three levels of risk thresholds enables fine-grained authorization control, which avoids the user experience degradation caused by a "one-size-fits-all" authorization model, and can take precise protective measures for different risk levels. For example, in medium-risk scenarios, only sensitive functions are restricted instead of authorization is completely suspended, so as to ensure security while minimizing the impact on normal use by users.

[0036] As one implementation method, step (3) of this embodiment, "generating a short-term valid dynamic authorization token based on the risk score", specifically includes: the token adopts a hash-based message authentication code structure, using the master key K stored in the server's secure area, the current Unix timestamp t accurate to the second, and the risk score R as inputs, and generating a dynamic authorization token T through the SHA-256 hash function, with the generation formula as follows: ; in, This indicates a connection operation, ensuring the integrity and freshness of the token. The hash message authentication code structure, combined with the cryptographic protection of the master key K, effectively prevents the token from being tampered with or forged. The introduction of the timestamp t gives the token a natural "timeliness," meaning that even if an attacker intercepts the token, it will fail verification due to timestamp mismatch, further enhancing the token's security level. The SHA-256 hash function is characterized by strong collision resistance and high computational efficiency, ensuring the security of token generation without affecting the smoothness of software operation due to complex calculations.

[0037] As one implementation method, the validity period Δt of the dynamic authorization token in this embodiment satisfies: ; in, To preset the maximum validity period, The preset scaling constant, The token is assigned a risk score. When the risk score is high, the token validity period is short, and frequent verification is enforced. When the risk score is low, the token validity period is long, reducing the verification frequency. The dynamic authorization token can be cached on the client during its validity period and needs to be regenerated after expiration. The dynamic binding between the validity period and the risk score realizes the intelligent protection logic of "the higher the risk, the more frequent the verification". In high-risk scenarios, shortening the validity period can quickly block the continuous use of unauthorized authorization, while in low-risk scenarios, extending the validity period reduces the number of verifications, thus balancing security and ease of use.

[0038] The authorization system supports offline verification. When an offline environment is detected, the system flexibly extends the validity period of the dynamic authorization token by reducing the weight of the risk score R in the validity period calculation, ensuring that the software runs normally in offline environments. The offline adaptation mechanism solves the pain point of existing static authorization systems, which are "strongly dependent on online use and difficult to use offline." For example, when users use the software in outdoor scenarios without network access, the system can automatically extend the token validity period, avoiding functional limitations caused by the inability to verify online, and greatly improving the software's scenario adaptability.

[0039] As one implementation method, this embodiment may also incorporate an elliptic curve digital signature algorithm for security enhancement when generating the dynamic authorization token, specifically including: (a) Generate a random number k and calculate the point ,in It is the base point of the elliptic curve; (b) Generate a signature (r,s) based on the server's private key d, random number k, current timestamp t, and risk score R, where , Let be the order of the elliptic curve. ; (c) The dynamic authorization token T=(r,s) is used by the client to verify its validity using the corresponding public key, making it suitable for high-security scenarios. The elliptic curve digital signature algorithm features "private key signing and public key verification," meaning that even if an attacker obtains the public key, they cannot forge the signature. Compared to single hash encryption, its anti-counterfeiting capabilities are stronger, meeting the needs of scenarios with extremely high authorization security requirements, such as financial software and confidential tools. Furthermore, the algorithm has a short key length and low computational overhead, without significantly increasing the system's operational burden.

[0040] As one implementation method, the "distributed verification mechanism" in step (4) of this embodiment specifically includes: (4.1) The client periodically checks whether the locally cached dynamic authorization token has expired; local periodic checks can reduce the dependence on network connection and ensure the continuity of authorization verification even in unstable network scenarios, avoiding software operation interruption due to network fluctuations.

[0041] (4.2) When the network is available, the client sends a heartbeat packet to the authorization server. The heartbeat packet contains the current dynamic authorization token and the corresponding risk score. After verification, the authorization server returns a token update instruction to synchronize the token status. The heartbeat packet synchronization mechanism realizes the consistency of the authorization status between the client and the server. The server can grasp the client's operating scenario and risk status in real time through the heartbeat packet, and push token update or revocation instructions in a timely manner to improve the real-time performance and accuracy of authorization management.

[0042] (4.3) The authorization server can proactively push a token revocation command to the client based on security requirements, triggering an adjustment of the authorization status. The proactive revocation function enables software developers to quickly respond to sudden security events such as authorization leaks and device loss. For example, when a user reports that the software authorization has been illegally misused, the server can immediately push a revocation command to terminate the use of the unauthorized authorization and minimize losses.

[0043] As one implementation method, in this embodiment, when the dynamic authorization token verification fails, the software does not immediately exit but enters a downgrade mode and initiates a preset grace period. The downgrade mode includes restricting the use of some software functions. During the grace period, the user is allowed to re-complete the authorization verification. If valid authorization is still not completed after the grace period ends, the software operation is suspended and relevant logs are recorded. The design of the downgrade mode and grace period avoids the rigid "lockdown upon verification failure" approach of existing technologies. For example, if a user's token cannot be updated due to a temporary network interruption, they can re-complete the authorization by switching networks during the grace period. This ensures security and avoids the forced interruption of the user's ongoing operations, significantly improving the user experience and software reliability.

[0044] Example 2 This embodiment proposes a novel software licensing method based on dynamic context awareness. The core innovation lies in transforming software licensing from a static event into a continuous process. By monitoring user behavior, environmental factors, and device status in real time, a machine learning model is used for risk assessment, generating short-term valid dynamic tokens. This method not only improves security but also enhances flexibility and privacy protection. The overall solution consists of four modules: a context acquisition module, a risk assessment engine, a dynamic token generator, and a verification module. The design of each component is described in detail below: This method operates continuously throughout the software runtime, rather than just at startup. The software integrates a lightweight client agent responsible for executing the authorization process. The authorization server deploys a machine learning model and a token management service. The process is cyclical: after software startup, the client agent periodically (e.g., every minute) collects contextual data, calculates a risk score, and generates or updates tokens; if the risk is too high, the authorization is automatically revoked. This approach ensures that the authorization status is synchronized with the usage scenario in real time.

[0045] Module 1: Context Acquisition Module This module is responsible for collecting authorization-related contextual data in real time. The data is divided into three categories: User behavior data includes software usage frequency, operation sequences (such as click patterns), feature usage preferences, and session duration. For example, user input events can be captured using hooking techniques. This step is primarily used to characterize user behavior because the actions of attackers (crackers) and authorized users often differ significantly. Attackers will frequently interact with activation buttons and inputs, rather than engaging in normal software functions.

[0046] Environmental data includes network status (IP address, connection type), geographical location (via GPS or IP address), time information (such as the time period of use), and system load (CPU / memory usage). This data is used to further determine user information.

[0047] Device data: Anonymized and does not directly use hardware fingerprints. Instead, a device identifier based on multi-hash is generated to ensure privacy. For example, the device identifier D is calculated as: ; Where H is the SHA-256 hash function, and ⊕ represents the XOR operation. This avoids the leakage of raw hardware information.

[0048] Data acquisition frequency is configurable, with a default sampling frequency of once per minute, but a sliding window averaging method is used to reduce noise. All data undergoes initial encryption and anonymization on the client side, with only feature vectors transmitted to the server.

[0049] Module 2: Risk Assessment Engine This engine is responsible for transforming the collected contextual data into authorization decision-making criteria, achieving intelligent risk assessment through multi-step processing. The specific implementation steps are as follows: Step 2.1 Feature Engineering and Vector Construction The collected raw context data is transformed into authorization-related feature vectors.

[0050] Step 2.2 For software licensing scenarios, construct the feature: user behavior anomaly degree (the deviation is calculated based on the historical operation baseline).

[0051] Step 2.3 For software licensing scenarios, construct features: environmental risk index (such as login location change rate, network type risk level).

[0052] Step 2.4 For software licensing scenarios, construct the feature: device trustworthiness (based on the historical usage records of the device identifier).

[0053] Step 2.5 Normalize each feature to the [0,1] interval to form a feature vector. For example, when a user is detected using sensitive functions frequently in an unfamiliar network environment, the corresponding feature value will increase significantly.

[0054] Step 2.6 Risk Score Calculation and Authorization Mapping The risk score R is calculated using a logistic regression model.

[0055] ; After Step 2.7 outputs R, the system will make authorization decisions based on preset thresholds: when R < 0.3, it is considered low risk and full functional permissions are granted; when 0.3 ≤ R < 0.7, it is considered medium risk and secondary verification is triggered or some sensitive functions are restricted; when R ≥ 0.7, it is considered high risk, authorization is immediately suspended and security audit is initiated. The risk score also participates in the calculation of the dynamic token's validity period, realizing intelligent control of "the higher the risk, the more frequent the verification."

[0056] Step 3: Online Model Update and Adaptation 3.1 The system periodically collects new authorization verification data (including normal usage and attack cases). 3.2 Online updates to risk assessment model parameters. When new attack patterns are detected or significant changes in user behavior occur, feature weights and decision thresholds are automatically adjusted to ensure the model continuously adapts to changes in the software licensing environment. This adaptive mechanism enables the system to cope with evolving security threats and enhances its long-term ability to curb product piracy.

[0057] Module 3: Dynamic Token Generator This component generates a short-lived authorization token T based on a risk score and the current time. The token uses a hash-based message authentication code (HMAC) structure to ensure integrity and freshness. The token generation algorithm is as follows: Input: Master key K (stored in the server's secure zone), current timestamp t (Unix timestamp, accurate to the second), risk score R.

[0058] Output: Token , where H is the SHA-256 hash function, and || represents the concatenation operation.

[0059] The token's validity period Δt is not fixed (≥0), but dynamically adjusted: ; in R is the maximum validity period (e.g., 3600 seconds), and c is a scaling constant (e.g., 1800). Higher R values ​​shorten the validity period and force more frequent verification. Tokens can be cached on the client during their validity period, but must be regenerated after expiration.

[0060] Module 4: Verification Module A lightweight validator integrated into the software is responsible for checking token validity. Verification is distributed: clients periodically (e.g., hourly) check if their local tokens have expired; simultaneously, the server can proactively push revocation commands. The verification logic includes: The client calculates the hash of the current token and compares it with the token synchronized with the server.

[0061] If network availability is available, the client sends a heartbeat packet containing a token and the current risk score, and the server returns an update instruction.

[0062] When verification fails, the software does not exit immediately, but enters a downgrade mode (such as restricting functions) and gives the user a grace period (such as 3 minutes) to reauthorize.

[0063] like Figure 2 The authorization process for this method is shown below: 1. Start: The user starts the software.

[0064] 2. Initialization check: The client agent loads the locally cached token (if any). If the token is valid and has not expired, proceed to step 6; otherwise, continue.

[0065] 3. Context collection: The client collects user behavior, environment and device data to construct feature vector X.

[0066] 4. Risk assessment: The client sends X to the server (or calculates it using the local model), and the server returns a risk score R.

[0067] 5. Token Generation: If The server generates a token T and sends it to the client; otherwise, a security mechanism is triggered.

[0068] 6. Security Mechanism: If R > 0.7, authorization is suspended and the program exits. Otherwise, authorization is downgraded to accelerate the verification cycle.

[0069] 7. Software operation: The software runs normally using a valid token.

[0070] 8. Periodic cycle: The client re-executes steps 3-5 every Δt seconds (dynamic value) to update the token.

[0071] 9. Exception Handling: If multiple exceptions occur consecutively... The software pauses operation and logs information.

[0072] The entire process forms a closed loop, ensuring that the authorization status adapts to changes in real time.

[0073] To enhance security, elliptic curve digital signature algorithms (ECDSA) can be incorporated into token generation. For example, the server uses the private key d to sign the message M=t||R: 1. Generate a random number k and calculate the point. (where G is the base point of the elliptic curve).

[0074] 2. Signature ,in (n is the order of the curve) The token T = (r, s) is verified by the client using a public key. This increases anti-counterfeiting capabilities, but involves significant computational overhead, making it suitable for high-security scenarios.

[0075] Dynamic context-aware authorization loop mechanism: Software authorization is not a one-time event, but a continuous process based on real-time context data (user behavior, environment, device). Key technologies include the real-time nature of context acquisition and loop verification processes (such as...). Figure 1 (as shown), and the ability to dynamically adjust the authorization status. This is the basis of this solution, solving the static nature problem of existing technologies.

[0076] This embodiment has the following technical features: Machine learning-based risk assessment models: Risk scores R are calculated using lightweight machine learning algorithms (such as logistic regression) and integrated into token generation. Formula This embodies adaptability and intelligence, which is the core of achieving dynamic authorization.

[0077] A time-bound and risk-adaptive dynamic token generation algorithm: The token validity period Δt is dynamically related to the risk score R (formula). This is achieved by combining a hash function with the token to ensure security. This emphasizes the token's short lifespan and context-dependent nature, enhancing its resistance to hacking.

[0078] Anonymized device identifier generation method: Hardware information is processed through multiple hashing (formula D=H(H(MAC)⊕H(CPU_ID)⊕H(Disk_ID))), maintaining device uniqueness while protecting privacy. This is a key innovation in privacy protection.

[0079] Degradation mode and grace period design: When verification fails, the software does not immediately exit, but provides a buffer period. This improves user experience and reliability, and is a human-centered highlight of the solution.

[0080] Compared with the prior art, this embodiment has significant advantages and technical effects, which directly stem from the specific solution described above: This solution doesn't simply "transfer" existing authentication or risk control technologies to the authorization domain; instead, it achieves system-level optimization through a closed-loop architecture design. Specifically, the context acquisition module provides real-time data input, the risk assessment engine converts this into a dynamic risk score, the token generator adjusts the authorization strength based on the risk score (e.g., shortening the validity period of high-risk tokens), and the verification module executes corresponding access control based on the authorization strength. This closed-loop mechanism enables the system to automatically enhance security when anomalies are detected (e.g., shortening token lifespan), maintain a smooth user experience during normal use (e.g., extending the validity period of low-risk tokens), and protect user privacy through anonymized device identifiers. These modules work together to form a dynamically adjusted "security-experience-privacy" balance system—an effect that simple technology combinations cannot achieve.

[0081] By employing dynamic tokens and real-time risk assessment, this method avoids the weaknesses of static authorization. Attackers find it difficult to crack through reverse engineering because the tokens are short-lived and context-sensitive. For example, time binding and risk dependence in mathematical formulas ensure the token's freshness; even if intercepted, it quickly expires. Simultaneously, machine learning models can detect anomalous behavior (such as brute-force attempts) and adjust risk scores promptly to prevent authorization abuse. In contrast, while hardware fingerprints in existing technologies are easily forged, this method's anonymized device identifiers and dynamic verification increase the cost of deception.

[0082] This method supports dynamic authorization adjustments to adapt to diverse use cases. For example, in offline environments, token validity can be extended (by reducing the weight of R); in high-risk environments (such as when VPN use is detected), the system automatically shortens token lifespan. This flexibility stems from the cyclical process and parameterized design in the solution, which existing technologies cannot achieve with similar fine-grained control. The technical benefits manifest as improved software usability, making it particularly suitable for mobile and IoT environments.

[0083] Context collection employs anonymization and encryption, reducing the risk of privacy breaches; risk assessment is triggered only when changes occur, lowering computational overhead. In terms of effectiveness, this method saves more network bandwidth and battery life than existing technologies (through intelligent sampling), while also complying with data regulations. For example, the hash formula for device identifiers ensures irreversibility, protecting user privacy.

[0084] The downgrade mode and grace period design prevent abrupt software interruptions, improving the user experience. This technical effect is achieved through exception handling paths in the flowchart, whereas existing techniques often result in complete lockouts when authorization fails. Furthermore, loop verification reduces startup latency because most checks are performed in the background.

[0085] Overall, this patent upgrades software licensing from a static lock to a smart doorman through a dynamic context-aware mechanism, resulting in substantial improvements. These effects are not arbitrary but based on the modular design of the solution: the risk assessment engine provides the basis for intelligent decision-making, dynamic token generation ensures execution efficiency, and the overall closed-loop process guarantees reliability.

[0086] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A novel software licensing method based on dynamic context awareness, characterized in that: Includes the following steps: (1) After the software starts, the context collection module continuously collects context data related to software authorization through the lightweight client agent integrated into the software. The context data includes user behavior data, environmental data and device data. (2) The collected context data is transmitted to the risk assessment engine, and the context data is used to perform feature extraction and risk analysis using a preset machine learning model to calculate the risk score. The risk score is then mapped to the corresponding authorization decision according to a preset threshold. (3) Generate a short-term valid dynamic authorization token based on the risk score, wherein the validity period of the dynamic authorization token is negatively correlated with the risk score and dynamically adapted. (4) Perform local token verification on the client through a distributed verification mechanism, and determine the software authorization status based on the verification result: if the token is valid, the software is allowed to run normally; if the token is invalid, security measures are initiated. (5) The dynamic authorization token is updated periodically each time the software is started or at a preset time interval, and steps (1)-(4) are executed in a loop to realize the real-time synchronization of the authorization status and the software usage scenario, forming a continuous authorization closed loop.

2. The novel software licensing method based on dynamic context awareness according to claim 1, characterized in that: The user behavior data is collected by capturing user input events using hook technology, and includes at least software usage frequency, operation sequence, function usage preferences, and session duration. The environmental data includes network status, geographical location, time information, and system load. Network status includes IP address and connection type; geographical location is obtained through GPS or IP positioning; and system load includes CPU and memory usage. The device data consists of anonymized device identifiers, generated through a combination of multiple hash operations and XOR operations, using the following formula: ; in, For hash functions, This indicates the XOR operation. For the equipment address, For the equipment Serial number, This is the hard drive serial number of the device.

3. The novel software licensing method based on dynamic context awareness according to claim 1, characterized in that: Step (2) "using a preset machine learning model to extract features and perform risk analysis on the context data, and calculate the risk score" specifically includes: (2.1) Perform feature engineering on the collected raw context data to construct authorization-related feature vectors. The feature vector includes three core features: user behavior anomaly degree, environmental risk index, and device credibility. (2.2) Normalize each feature in the feature vector to the interval [0,1] to obtain the normalized feature vector; (2.3) Input the normalized feature vector into the preset machine learning model, and calculate the risk score R using the formula: ; in, For the feature weight vector, Here, e is the bias term, and e is the natural constant. The preset machine learning model is a logistic regression model; the user behavior anomaly degree is obtained by calculating the deviation value based on the user's historical operation baseline; the environmental risk index is calculated based on the login location change rate and network type risk level; and the device trustworthiness is evaluated based on the historical usage records of the device identifier.

4. The novel software licensing method based on dynamic context awareness according to claim 3, characterized in that: Step (2) also includes the online model update and adaptation steps: periodically collect authorization verification data, which includes normal software usage data and attack case data, and use the authorization verification data to update the parameter feature weight vector w, bias term b, and decision threshold of the machine learning model online; The phrase "mapping the risk score to a corresponding authorization decision based on a preset threshold" specifically means: When R < α, the risk is considered low, and full functionality permissions for the software are granted. When α≤R<β, it is judged as medium risk, triggering secondary verification or restricting some sensitive functions; When R ≥ β, it is judged as high risk, authorization is immediately suspended and a security audit is initiated; Where α and β are preset risk thresholds, and 0 < α < β < 1, α = 0.3, β = 0.

7.

5. The novel software licensing method based on dynamic context awareness according to claim 1, characterized in that: Step (3) "Generate a short-term valid dynamic authorization token based on the risk score" specifically includes: The token adopts a hash-based message authentication code structure, using the master key K stored in the server's secure area, the current Unix timestamp t accurate to the second, and the risk score R as inputs, and generating a dynamic authorization token T through the SHA-256 hash function. The generation formula is: ; in, This indicates a connection operation, ensuring the integrity and freshness of the token.

6. The novel software licensing method based on dynamic context awareness according to claim 5, characterized in that: The validity period Δt of the dynamic authorization token satisfies: ; in, To preset the maximum validity period, The preset scaling constant, The risk score is used to determine the validity period of the token. When the risk score is high, the token validity period is short, and frequent verification is forced. When the risk score is low, the token validity period is long, and the verification frequency is reduced. The dynamic authorization token can be cached on the client during its validity period and needs to be regenerated after it expires. The authorization system supports offline verification. When an offline environment is detected, the validity period of the dynamic authorization token is flexibly extended by reducing the weight of the risk score R in the validity period calculation, ensuring that the software runs normally in an offline environment.

7. The novel software licensing method based on dynamic context awareness according to claim 6, characterized in that: When generating dynamic authorization tokens, elliptic curve digital signature algorithms can also be introduced to enhance security, specifically including: (a) Generate a random number k and calculate the point ,in It is the base point of the elliptic curve; (b) Generate a signature (r,s) based on the server's private key d, random number k, current timestamp t, and risk score R, where , Let be the order of the elliptic curve. ; (c) The dynamic authorization token T=(r,s) is used by the client to verify the validity of the dynamic authorization token through the corresponding public key, which is suitable for high security requirements.

8. The novel software licensing method based on dynamic context awareness according to claim 1, characterized in that: The "distributed verification mechanism" in step (4) specifically includes: (4.1) The client periodically checks whether the locally cached dynamic authorization token has expired; (4.2) When the network is available, the client sends a heartbeat packet to the authorization server. The heartbeat packet contains the current dynamic authorization token and the corresponding risk score. After verification, the authorization server returns a token update instruction to synchronize the token status. (4.3) The authorization server may proactively push a token revocation command to the client based on security requirements, triggering an authorization status adjustment.

9. The novel software licensing method based on dynamic context awareness according to claim 8, characterized in that: When dynamic authorization token verification fails, the software does not exit immediately, but enters a downgrade mode and starts a preset grace period. The downgrade mode includes restricting the use of some software functions. During the grace period, the user is allowed to re-complete the authorization verification. If the valid authorization is still not completed after the grace period ends, the software operation is suspended and relevant logs are recorded.

Images