Dual-check based hierarchical license management method, system and platform device

Abstract

The application relates to the technical field of license management, and proposes a hierarchical license management method, system and platform device based on double verification. The method comprises the following steps: when a first-level platform device receives a license issuance request sent by a second-level platform device, performing global constraint verification on the license issuance request; when the global constraint verification is successful, the first-level platform device sends global verification success information to the second-level platform device; the second-level platform device performs local constraint verification on the license issuance request, and responds to the license issuance request when the global verification success information is received and the local constraint verification is successful. The method constructs a hierarchical license management system comprising the first-level platform device and the second-level platform device, and introduces a cross-platform double verification mechanism when processing the license issuance request, so that the upstream platform can control the license issuance behavior of the downstream platform in real time, thereby reducing the problem of illegal license issuance of the downstream platform.

Description

Technical Field

[0001] This application relates to the field of license management technology, and in particular to a hierarchical license management method, system and platform device based on dual verification. Background Technology

[0002] Traditional centralized software license management systems typically employ a single, centralized license server responsible for the generation, issuance, and verification of all licenses. This means that all license verification requests from terminal devices converge on this license server. If the license server fails, the entire system's license verification service will be paralyzed, clearly presenting a single point of failure.

[0003] Currently, existing technologies have proposed distributed software license management systems, where an upstream platform distributes license issuance authority to various downstream platforms. This allows each downstream platform to independently handle a portion of license verification requests, thus resolving the aforementioned single point of failure issue. However, the upstream platform lacks the technical means to control the license issuance behavior of downstream platforms, potentially leading to issues such as some downstream platforms issuing licenses illegally. Summary of the Invention

[0004] In view of this, embodiments of this application provide a hierarchical license management method, system, and platform device based on dual verification. By constructing a hierarchical license management system that includes a first-level platform device and a second-level platform device, and introducing a cross-platform dual verification mechanism when processing license issuance requests, the upstream platform can monitor the license issuance behavior of the downstream platform in real time, thereby reducing the problem of the downstream platform issuing licenses illegally.

[0005] The first aspect of this application provides a hierarchical license management method based on dual verification. This method is applied to a primary platform device connected to a secondary platform device. The method includes:

[0006] Upon receiving a license issuance request from a secondary platform device, perform a global constraint check on the license issuance request;

[0007] When the global constraint verification is successful, a global verification success message is sent to the secondary platform device to instruct the secondary platform device to respond to the license issuance request after receiving the global verification success message and the local constraint verification performed on the license issuance request is successful.

[0008] The technical solution of this application embodiment constructs a hierarchical license management system comprising a primary platform device and a secondary platform device, where the primary platform device acts as the upstream platform and the secondary platform device acts as the downstream platform. Before issuing a license, the secondary platform device needs to send a license issuance request to the primary platform device. The primary platform device performs global constraint verification on the license issuance request and sends a global verification success message to the secondary platform device upon successful global constraint verification. Furthermore, the secondary platform device itself also needs to perform local constraint verification on the license issuance request. Only when it receives both the global verification success message and the local constraint verification is successful—that is, when both the primary platform device's global constraint verification and the secondary platform device's local constraint verification are successful—will the secondary platform device respond to the license issuance request. This process introduces a cross-platform dual verification mechanism when processing license issuance requests. The upstream platform can monitor the license issuance behavior of the downstream platform in real time through global constraint verification, thereby reducing the problem of downstream platforms issuing licenses illegally.

[0009] In one implementation of this application, the license issuance request carries the target number of licenses to be issued; upon receiving the license issuance request sent by the secondary platform device, a global constraint check is performed on the license issuance request, including:

[0010] Upon receiving a license issuance request, obtain the maximum number of licenses that can be issued to the secondary platform device and the historical number of licenses that have been issued to the secondary platform device.

[0011] The remaining number of licenses that can be issued for secondary platform equipment is determined based on the upper limit of the number of licenses and the number of historical licenses.

[0012] If the number of target licenses exceeds the number of remaining licenses that can be issued, then the global constraint verification is considered to have failed.

[0013] In one implementation of this application, the primary platform device is provided with a first issuance service component and a first verification service component, and the secondary platform device is provided with a second issuance service component. The secondary platform device processes the license issuance request through the second issuance service component. Before the secondary platform device sends the license issuance request, the method further includes:

[0014] The first issuance service component issues an activation license to the secondary platform device to start the second issuance service component and carries the upper limit of the number of licenses that the secondary platform device can issue, so as to instruct the secondary platform device to send a first online verification request for the activation license to the primary platform device after successfully performing local verification of the activation license.

[0015] Upon receiving the first online verification request, the system performs online verification of the startup license through the first verification service component. After successful online verification, it sends an online verification success message to the secondary platform device, instructing the secondary platform device to start the second issuance service component upon receiving the online verification success message.

[0016] In one implementation of this application embodiment, after starting the second issuance service component, the method further includes:

[0017] When a specified violation is found in a secondary platform device, the startup license is revoked through the first issuance service component, and the revocation status of the startup license is updated to revoked through the first verification service component.

[0018] Upon receiving a second online verification request for the launch license sent periodically by the secondary platform device, the first verification service component sends an online verification failure message to the secondary platform device based on the revocation status, instructing the secondary platform device to close the second issuance service component upon receiving the online verification failure message.

[0019] A second aspect of this application provides a hierarchical license management method based on dual verification, which is applied to a secondary platform device connected to a primary platform device. The method includes:

[0020] Send a license issuance request to the primary platform device to instruct the primary platform device to perform global constraint verification on the license issuance request upon receiving it, and send a global verification success message to the secondary platform device when the global constraint verification is successful.

[0021] If a global verification success message is received and the local constraint verification performed on the license grant request is successful, the license grant request will be responded to.

[0022] In one implementation of this application, the license issuance request carries the type of license to be issued; the process of performing local constraint verification on the license issuance request includes:

[0023] If the license type is a startup license used to launch the issuance service component, then the local constraint verification is determined to have failed.

[0024] In one implementation of this application embodiment, the secondary platform device is provided with a second verification service component; the method further includes:

[0025] Upon receiving an online verification request for an issued license from a secondary terminal device, the second verification service component queries the validity period and revocation status of the issued license. If the license has not expired at the current time and the revocation status is not revoked, the online verification request is responded to.

[0026] A third aspect of this application provides a tiered license management device based on dual verification. This device is applied to a primary platform device connected to a secondary platform device. The device includes:

[0027] The global constraint verification module is used to perform global constraint verification on the license issuance request when it receives a license issuance request sent by a secondary platform device.

[0028] The global verification information sending module is used to send global verification success information to the secondary platform device when the global constraint verification is successful, so as to instruct the secondary platform device to respond to the license issuance request after receiving the global verification success information and the local constraint verification performed on the license issuance request is successful.

[0029] A fourth aspect of this application provides another hierarchical license management device based on dual verification. This device is applied to a secondary platform device connected to a primary platform device. The device includes:

[0030] The license issuance request sending module is used to send a license issuance request to the first-level platform device, instructing the first-level platform device to perform a global constraint verification on the license issuance request upon receiving it, and to send a global verification success message to the second-level platform device when the global constraint verification is successful.

[0031] The license issuance request response module is used to respond to the license issuance request when a global verification success message is received and the local constraint verification executed on the license issuance request is successful.

[0032] A fifth aspect of this application provides a platform device including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the dual-verification-based hierarchical license management method provided in the first aspect of this application.

[0033] A sixth aspect of this application provides another platform device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the dual-verification-based hierarchical license management method provided in the second aspect of this application.

[0034] The seventh aspect of this application provides a hierarchical license management system based on dual verification, the system including the platform device provided in the fifth aspect of this application and at least one platform device provided in the sixth aspect of this application.

[0035] The eighth aspect of this application provides a computer program product that, when run on a platform device, causes the platform device to execute the dual-verification-based hierarchical license management method provided in the first aspect of this application, or to execute the dual-verification-based hierarchical license management method provided in the second aspect of this application.

[0036] A ninth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the dual-verification-based hierarchical license management method provided in the first aspect of this application, or implements the dual-verification-based hierarchical license management method provided in the second aspect of this application.

[0037] It is understood that the beneficial effects of aspects two through nine above can be found in the relevant descriptions in aspect one above, and will not be repeated here. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the architecture of a hierarchical license management system based on dual verification provided in an embodiment of this application;

[0039] Figure 2 This is a flowchart of a hierarchical license management method based on dual verification provided in an embodiment of this application;

[0040] Figure 3 This is a schematic diagram of the core authorization and verification process across levels in a hierarchical license management system provided in this application embodiment;

[0041] Figure 4 This is a schematic diagram of a hierarchical license management device based on dual verification provided in an embodiment of this application;

[0042] Figure 5 This is a schematic diagram of another hierarchical license management device based on dual verification provided in this application embodiment;

[0043] Figure 6 This is a schematic diagram of a platform device provided in an embodiment of this application. Detailed Implementation

[0044] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail. Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0045] Traditional centralized software license management systems use a single license server to manage all license generation, issuance, and verification operations, which obviously suffers from a serious single point of failure. Even though existing technologies have proposed distributed software license management systems, in which an upstream platform distributes license issuance authority to various downstream platforms, the upstream platform lacks the technical means to control the license issuance behavior of the downstream platforms, making it easy for downstream platforms to issue licenses illegally.

[0046] To address the aforementioned technical problems, this application proposes a hierarchical license management method, system, and platform device based on dual verification. By constructing a hierarchical license management system comprising primary and secondary platform devices, and introducing a cross-platform dual verification mechanism when processing license issuance requests, the upstream platform can monitor the license issuance behavior of the downstream platform in real time, thereby reducing the problem of unauthorized license issuance by the downstream platform. For more specific technical implementation details of this application's embodiments, please refer to the various embodiments described below.

[0047] like Figure 1 The diagram illustrates the architecture of a tiered license management system based on dual verification, as provided in this application. The system includes a primary platform device (L1) and at least one secondary platform device (L2A, L2B…L2N). Each secondary platform device can interact with the primary platform device via a network or other means, while the secondary platform devices operate independently without interaction. The primary platform device, as the upstream platform, is the overall authorizer and supervisor of the system, possessing the authority to authorize license issuance, allocate license quotas, and conduct global supervision of each secondary platform device. The secondary platform devices, as downstream platforms, are the authorized and distributing entities of the system, and can obtain limited license issuance authority through the primary platform device.

[0048] Each Tier 1 platform device and each Tier 2 platform device can independently deploy one Issuer service component and one Verifier service component. The Issuer service component is primarily responsible for handling the entire lifecycle management of licenses, including creation, renewal, and revocation, and is responsible for initiating data push and dual verification. The Verifier service component is primarily responsible for verifying the validity of licenses and is also the executor of global quota constraints and verification initiation. Specifically, the Issuer service component deployed on the Tier 1 platform device is denoted as the first Issuer service component (L1 Issuer), and the Verifier service component deployed is denoted as the first Verifier service component (L1 Verifier). The Issuer service component deployed on the Tier 2 platform device is denoted as the second Issuer service component (L2 Issuer), and the Verifier service component deployed is denoted as the second Verifier service component (L2 Verifier). It can be understood that each Tier 2 platform device has its own second Issuer service component and second Verifier service component. The core functions of the first Issuer service component (L1 Issuer), the first Verifier service component (L1 Verifier), the second Issuer service component (L2 Issuer), and the second Verifier service component (L2 Verifier) ​​will be described in turn.

[0049] The first issuing service component, L1 Issuer, is the system's general licensor and the license quota allocator for each secondary platform device. Its core functions include: (1) Terminal business management: L1 Issuer can directly provide users of primary terminal devices (terminals that complete license-related business operations by accessing primary platform devices) with full lifecycle management operations such as the issuance, renewal, and revocation of ordinary licenses; (2) Local authorization information push: When performing license management operations, L1 Issuer can push key information containing anti-replay identifiers and digital signatures to the first verification service component, L1 Verifier, to ensure the consistency and integrity of license data. For example, if L1 Issuer is performing a license issuance operation, it can push the basic information of the license issuance to L1 Verifier, such as license ID, expiration time, revocation status, license type (ordinary license or startup license), as well as anti-replay identifiers and signatures on this information. If a startup license is issued, it also needs to push the upper limit of the number of licenses that can be issued by the corresponding secondary platform device to L1 Verifier; if L1 Issuer is performing a license renewal or revocation operation, it can push the information to L1 Verifier. Verifier pushes basic information of the corresponding license, such as license ID, new expiration time or new revocation status, as well as anti-replay identifier and signature of this information; anti-replay identifier is a security mechanism, which can be a Nonce value, incremental sequence number or timestamp embedded in the push information, to ensure the uniqueness and continuity of L1 Verifier or L2 Verifier check requests, so as to prevent malicious users or programs from reusing old signature push information; (3) hierarchical authorization management, can issue a special type of license for starting the second issuing service component L2 Issuer - startup license, the startup license carries the upper limit of the number of licenses that can be issued by the corresponding secondary platform device; for different secondary platform devices, L1 Issuer can issue startup licenses with different upper limits of the number of licenses, and the specific upper limit of the number of licenses can be negotiated and confirmed by the corresponding secondary platform and the primary platform.

[0050] The first verification service component, L1 Verifier, performs global quota constraints and startup verification of secondary platform devices. As the global verification, constraint center, and status maintainer of the system, its core functions include: (1) Receiving and securely processing authorization information of primary platform devices, receiving and verifying all license control information pushed by L1 Issuer. L1 Verifier has basic security capabilities for verifying the public key signature of L1 Issuer and checking the anti-replay identifier to ensure the legality and timeliness of the received data. For example, if L1 Issuer pushes information related to the issuance of licenses, it checks the validity of each license, such as whether the expiration time of the newly issued license is less than the current time, whether the license ID already exists, etc. If a special type of startup license is issued, it also needs to record the upper limit of the number of licenses that can be issued by the corresponding secondary platform device; if L1 Issuer pushes status update (renewal / revocation) information of issued licenses, it checks whether the issued license exists and whether the update information is reasonable (e.g., whether the renewal time is greater than the original expiration time, expired licenses cannot be revoked, etc.). In general, L1 (1) Any license-related operation performed by the Issuer (such as issuance, renewal or revocation) requires pushing relevant verification information to the L1 Verifier. The L1 Verifier will verify the relevant information of all licenses (including ordinary licenses and start-up licenses) issued or renewed by the L1 Issuer; (2) Centralized online verification service: The L1 Verifier provides online validity verification services for all licenses issued by the L1 Issuer, including providing validity and revocation status verification for ordinary licenses for end users of the Level 1 platform devices, and providing mandatory validity verification for start-up licenses of the L2 Issuer. This is the key technical means for Level 1 platform devices to remotely control the life cycle of the L2 Issuer service; (3) License issuance quota management and global constraints for Level 2 platform devices: The L1 Verifier is responsible for receiving and processing terminal license issuance requests from the L2 Issuer. The L1 Verifier maintains the global status of the license quota limit and the number of licenses currently issued for all Level 2 platform devices, and has the ability to perform quota comparison verification, thereby realizing mandatory global constraints on the total number of licenses issued for each Level 2 platform device.

[0051] The second issuing service component, L2 Issuer, has the right to issue licenses subject to the constraints of the primary platform device. As the system's distribution executor and the initiator of dual verification, its core functions include: (1) starting service control, having the ability to read the starting license and send online verification requests to start its core services; (2) terminal license lifecycle management, which can provide terminal users of the secondary platform device with management services such as license issuance, renewal and revocation; (3) authorization information push and synchronization, including the initiation of dual verification: before performing the license issuance operation, a license issuance request containing an anti-replay identifier and a signature must be constructed and pushed to both L1 Verifier and L2 Verifier as a mandatory prerequisite; local status synchronization: after performing the license renewal or revocation operation, the latest license status information must be pushed to L2 Verifier to ensure the consistency of local verification data. It should be noted that L2 Issuer does not need to push the latest license status information to L1 Verifier. In terms of functional implementation, L1 The Verifier only needs to limit the maximum number of licenses issued for each secondary platform device, without needing to know the specific status of each license already issued for each secondary platform device (these license statuses are maintained by the L2 Verifier of the corresponding secondary platform device). Only the license issuance operation will change the number of licenses issued for the secondary platform device, while the renewal and revocation operations will not affect the number of licenses already issued. This setting can effectively reduce the data traffic of the L1 Verifier; (4) The decision to issue licenses is executed based on the joint return result of the dual verification (including the global constraint verification result of the L1 Verifier and the local constraint verification result of the L2 Verifier), and the license creation, issuance or process termination operations are executed; Specifically, only when both verification results are successful can the L2 Issuer successfully respond to the license issuance request initiated by the end user, create and issue the corresponding ordinary license to the end user; if any part of the verification result fails, the L2 Issuer will directly terminate the license issuance operation.

[0052] The second verification service component, L2 Verifier, is responsible for performing license validity verification for secondary platform devices. As the local verification and validation center of the system and the maintainer of local license status, its core functions include: (1) Local authorization information management and security processing of secondary platform devices, receiving and verifying all license control information pushed by L2 Issuer. L2 Verifier has the ability to verify the public key signature of L2 Issuer and check the anti-replay identifier, and is responsible for updating and maintaining the validity period and revocation status of each license in the local database in real time to ensure the integrity and security of the verification data source. The validity verification method of L2 Verifier for ordinary license control information pushed by L2 Issuer is the same as the validity verification method of L1 Verifier for ordinary license control information pushed by L1 Issuer; (2) Online authorization verification of secondary platform devices, maintaining the validity of each terminal license issued by L2 Issuer, and responding to the online license verification request of the user terminal of the secondary platform device, thereby realizing the localization and distribution of verification traffic, avoiding the verification traffic flowing to L1 Verifier of the primary platform device. This can reduce network latency and improve the response speed and reliability of the system in geographically dispersed scenarios.

[0053] Figure 1 Each platform device shown can be a mobile phone, tablet, wearable device, augmented reality (AR) / virtual reality (VR) device, laptop, desktop computer, ultra-mobile personal computer (UMPC), netbook, and personal digital assistant (PDA), etc., and various other types of electronic devices. The embodiments of this application... Figure 1 There are no restrictions on the specific type of each platform device shown. Regarding... Figure 1 For the specific working principle of the system shown, please refer to the method embodiment described below.

[0054] Please see Figure 2 This application illustrates a tiered license management method based on dual verification, comprising:

[0055] 201. The secondary platform device sends a license issuance request to the primary platform device;

[0056] When a secondary terminal device (a user terminal connected to a secondary platform device) initiates a license issuance request to the secondary platform device, the secondary platform device receives the license issuance request through the L2 Issuer and simultaneously pushes it to the L1 Verifier of the primary platform device and the locally deployed L2 Verifier. The license issuance request pushed to the L1 Verifier carries information such as the license ID, anti-replay identifier, digital signature, and the number of licenses requested, to trigger the L1 Verifier's global constraint verification (also known as global quota comparison verification). The purpose of global constraint verification is mainly to prevent the secondary platform device from issuing too many licenses. The license issuance request pushed to the L2 Verifier carries information such as the license ID, validity period, anti-replay identifier, and digital signature, to trigger the L2 Verifier's local constraint verification. The purpose of local constraint verification is mainly to verify the validity of the license's related information.

[0057] Referring to the core functionalities of L1 Issuer, L1 Verifier, L2 Issuer, and L2 Verifier described above, it can be seen that the license issuance authority of L2 Issuer is constrained by the primary platform device. The primary platform device can issue a startup license to L2 Issuer through L1 Issuer to start the license issuance service function of L2 Issuer, and can also revoke a startup license already issued to L2 Issuer through L1 Issuer to shut down the license issuance service function of L2 Issuer. Moreover, L2 Issuer is forced to continuously accept online verification from L1 Verifier during startup and operation. This can forcibly bind the license issuance authority of secondary platform device to the authorization status of primary platform device, reflecting a life cycle control mechanism. The technical implementation details of this life cycle control mechanism are described below.

[0058] In one implementation of this application, the primary platform device is provided with a first issuance service component and a first verification service component, and the secondary platform device is provided with a second issuance service component. The secondary platform device processes the license issuance request through the second issuance service component. Before the secondary platform device sends the license issuance request, the method further includes:

[0059] (1) The Level 1 platform device issues a startup license to the Level 2 platform device through the first issuance service component, which is used to start the second issuance service component and carries the maximum number of licenses that the Level 2 platform device can issue;

[0060] (2) After successfully performing local verification of the startup license, the secondary platform device sends the first online verification request for the startup license to the primary platform device;

[0061] (3) After receiving the first online verification request, the first-level platform device performs online verification of the startup license through the first verification service component, and sends online verification success information to the second-level platform device after successful online verification;

[0062] (4) After receiving the online verification success information, the secondary platform device starts the second issuance service component.

[0063] The prerequisite for a secondary platform device to provide license issuance services to secondary terminal devices is that the deployed second issuance service component, L2 Issuer, has been started. The first step in starting L2 Issuer is for the primary platform device to issue a startup license to the secondary platform device through the first issuance service component, L1 Issuer. This license carries the maximum number of licenses that the secondary platform device can issue. Upon receiving the startup license, the secondary platform device's L2 Issuer performs local verification. Specifically, it checks the existence of the startup license file locally, parses the file, and verifies the signature based on the file content. If the local verification is successful, the secondary platform device sends an online verification request for the startup license to the primary platform device's L1 Verifier through L2Issuer, denoted as the first online verification request. Upon receiving the first online verification request, the primary platform device performs online verification of the startup license through L1 Verifier. L1 Verifier verifies the validity period and revocation status of the startup license to determine its validity and records the maximum number of licenses that the corresponding secondary platform device can issue. If L1 Verifier verifies the startup license is valid online, it sends an online verification success message to the secondary platform device to authorize the start of L2. After receiving a successful online verification message, the secondary platform device can initiate the L2 Issuer, which then provides license issuance services to various secondary terminal devices. If the L1 Verifier's online verification of the license is invalid, it will refuse to send a successful online verification message to the secondary platform device, or it will send an online verification failure message. In this case, the secondary platform device cannot initiate the L2 Issuer and will be unable to provide license issuance services to the secondary terminal devices.

[0064] In one implementation of this application embodiment, after the secondary platform device starts the second issuance service component, the method further includes:

[0065] (1) When it is determined that a secondary platform device has committed a specified violation, the primary platform device revokes the startup license through the first issuing service component and updates the revocation status of the startup license to revoked through the first verification service component;

[0066] (2) After receiving the second online verification request for the start license sent periodically by the second-level platform device, the first-level platform device sends an online verification failure message to the second-level platform device based on the revocation status through the first verification service component;

[0067] (3) After receiving the online verification failure information, the secondary platform device shuts down the second issuance service component.

[0068] After the secondary platform device starts the second issuing service component L2 Issuer, if the secondary platform device exhibits specified violations, such as continuing to push license issuance requests to the primary platform device's L1 Verifier after reaching the maximum number of issued licenses (i.e., the L2 Issuer should stop issuing licenses but does not, instead continuously pushing unnecessary traffic pressure to the L1 Verifier), the primary platform device can revoke the startup licenses already issued to the L2 Issuer through the first issuing service component L1 Issuer and push the corresponding startup license revocation information to the L1 Verifier. The L1 Verifier updates the revocation status of the startup license to "revoked" in its local database. The secondary platform device's L2 Issuer continuously accepts online verification from the L1 Verifier during startup and runtime. Specifically, the secondary platform device periodically sends online verification requests for received startup licenses to the L1 Verifier through the L2 Issuer; these are referred to as the second online verification requests. Upon receiving the second online verification request, the Level 1 platform device queries its local database through L1Verifier and learns that the startup license has been revoked. Therefore, it sends an online verification failure message to the Level 2 platform device. Upon receiving this message, the Level 2 platform device triggers the L2 Issuer's forced shutdown mechanism, automatically suspending its license issuance service. This effectively disables the Level 2 platform device's license issuance capability. It's important to note that revoking the startup license only shuts down the L2 Issuer's license issuance service; the L2 Verifier's license verification function remains unaffected. The L2 Verifier can still continue to provide online verification services for already issued ordinary licenses, ensuring that the online license verification service of existing Level 2 terminal devices is not affected by the termination of the Level 2 platform device's authorization capability.

[0069] It can be seen that by introducing the above-mentioned life cycle control mechanism, the running status of the downstream platform's authorized service program can be forcibly bound to the validity of its upstream authorization. In this way, the upstream platform can quickly and remotely terminate the downstream platform's illegal authorization service, which greatly enhances the upstream platform's regulatory enforcement over the downstream platform.

[0070] 202. When a Level 1 platform device receives a license issuance request, it performs a global constraint check on the license issuance request;

[0071] The secondary platform device pushes the license issuance request to both the primary platform device's L1Verifier and the locally deployed L2 Verifier via the L2 Issuer. When the primary platform device receives the license issuance request, it performs global constraint verification on the license issuance request through the L1Verifier. Please refer to the following text for the specific global constraint verification process.

[0072] In one implementation of this application, the license issuance request carries the target number of licenses to be issued; when the primary platform device receives the license issuance request sent by the secondary platform device, it performs a global constraint check on the license issuance request, including:

[0073] (1) Upon receiving a license issuance request, obtain the maximum number of licenses that can be issued to the secondary platform device and the number of historical licenses that have been issued to the secondary platform device;

[0074] (2) Determine the remaining number of licenses that can be issued for the secondary platform equipment based on the upper limit of the number of licenses and the number of historical licenses;

[0075] (3) If the number of target licenses exceeds the number of remaining licenses that can be issued, then the global constraint verification is determined to have failed.

[0076] When a Level 1 platform device receives a license issuance request from a Level 2 platform device, it parses and retrieves the number of licenses currently required to be issued, denoted as the target license quantity (S0), carried in the request. It also retrieves the upper limit of the number of licenses that the Level 2 platform device can issue, maintained by the L1 Verifier, and the historical number of licenses it has already issued. Then, based on the upper limit and historical license quantities, the remaining number of licenses that the Level 2 platform device can issue is determined. For example, assuming the upper limit is S1 and the historical number of licenses issued is S2, the remaining number of licenses that can be issued is S3 = S1 - S2. Finally, the target license quantity S0 is compared with the remaining number of licenses that can be issued S3. If the target license quantity S0 exceeds the remaining number of licenses that can be issued S3, the current license issuance request will result in over-issuance, and the global constraint verification fails. Conversely, if the target license quantity S0 does not exceed the remaining number of licenses that can be issued S3, the current license issuance request will not result in over-issuance, and the global constraint verification succeeds. It can be seen that by introducing global constraint verification of L1 Verifier, the phenomenon of over-issuance of licenses for secondary platform devices can be effectively prevented, and the risk of over-issuance of licenses for secondary platform devices can be fundamentally eliminated.

[0077] In addition to the global constraint verification mentioned above, the Level 1 platform device can also adopt the pre-allocated quota pool mode. That is, the L1 Verifier pre-generates and allocates a set of limited quota codes to the L2 Issuer of the Level 2 platform device. When the L2 Issuer issues a license, it will consume the quota in the quota code pool. When the quota is completely consumed, no more licenses can be issued. This can also prevent the Level 2 platform device from issuing licenses beyond the quota.

[0078] 203. When the global constraint verification is successful, the first-level platform device sends a global verification success message to the second-level platform device;

[0079] If the global constraint verification is successful, the first-level platform device will send a global verification success message to the second-level platform device; if the global constraint verification fails, the first-level platform device will send a global verification failure message to the second-level platform device.

[0080] 204. When the Level 2 platform device receives the global verification success message and the local constraint verification executed on the license issuance request is successful, it responds to the license issuance request.

[0081] After receiving a license issuance request through the L2 Issuer, the secondary platform device pushes it to the L1 Verifier of the primary platform device for global constraint verification, and also to the locally deployed L2 Verifier for local constraint verification. The license issuance request pushed to the L2 Verifier carries information such as the license ID, validity period, anti-replay identifier, and digital signature. When local constraint verification begins, the L2 Verifier first checks the anti-replay identifier and verifies the digital signature. If both the anti-replay identifier check and signature verification pass, it checks the validity of the specific information of the license to be issued, such as whether the license expiration time exceeds the current time, whether the license type is a regular license (L2 Issuer is not allowed to issue startup licenses), and whether the license ID is duplicated, etc. If all these checks pass, the L2 Verifier determines that the local constraint verification is successful and stores this license information in its local database to meet the needs of subsequent online verification. Conversely, if the anti-replay identifier check or signature verification fails, or if some information of the license to be issued is invalid (e.g., the current time has exceeded the license expiration time, the license ID is duplicated, etc.), the L2 Verifier determines that the local constraint verification has failed.

[0082] In one implementation of this application, the license issuance request carries the type of license to be issued; the process of the secondary platform device performing local constraint verification on the license issuance request includes:

[0083] If the license type is a startup license used to launch the issuance service component, the secondary platform device determines that the local constraint verification failed.

[0084] In the technical solution of this application embodiment, only the L1 Issuer of the primary platform device has the authority to issue startup licenses; the L2 Issuer of the secondary platform device is not allowed to issue startup licenses to any other device. Therefore, during the local constraint verification process performed by the secondary platform device on the license issuance request, if the L2 Verifier detects that the type of the license to be issued is a startup license, it determines that the local constraint verification has failed. This configuration centralizes the licensing authority to the primary platform device, thereby preventing the proliferation and loss of control over license issuance permissions.

[0085] The secondary platform device will only respond to the license issuance request from the secondary terminal device if it receives a global verification success message from the primary platform device and its own local constraint verification of the license issuance request is successful (i.e., both verifications pass). In this case, the L2 Issuer creates and issues the corresponding ordinary license to the secondary terminal device. Conversely, if the secondary platform device does not receive a global verification success message from the primary platform device, or if its own local constraint verification of the license issuance request fails, it will refuse to respond to the license issuance request from the secondary terminal device, and the license issuance process will terminate immediately. It can be seen that the primary platform device can control the license issuance behavior of the secondary platform device in real time through global constraint verification, thereby eliminating the risk of the secondary platform device over-issuing licenses.

[0086] The technical solution of this application embodiment utilizes secondary platform devices distributed in various locations to achieve localized distribution of license verification traffic. That is, the license verification traffic of different user terminals is directed to the L2 Verifier of the nearest secondary platform device, avoiding the flow of all user terminal license verification traffic to the L1 Verifier of the primary platform device. This can reduce network latency and effectively improve the response speed and reliability of the system in geographically dispersed scenarios.

[0087] In one implementation of this application embodiment, the secondary platform device is provided with a second verification service component; the method further includes:

[0088] Upon receiving an online verification request for an issued license from a secondary terminal device, the secondary platform device queries the validity period and revocation status of the issued license through the second verification service component. If the validity period has not expired at the current time and the revocation status is not revoked, the device responds to the online verification request.

[0089] When a secondary platform device receives an online verification request for an issued license from a secondary terminal device, it queries the L2 Verifier for the license's validity period and revocation status. If the license has not expired at the current time and its revocation status is not revoked, the platform device responds to the online verification request and returns the verification result to the secondary terminal device. Clearly, by directing the user terminal's license verification traffic to the L2 Verifier, the license verification load is locally distributed.

[0090] The technical solution of this application embodiment constructs a hierarchical license management system comprising a primary platform device and a secondary platform device, where the primary platform device acts as the upstream platform and the secondary platform device acts as the downstream platform. Before issuing a license, the secondary platform device needs to send a license issuance request to the primary platform device. The primary platform device performs global constraint verification on the license issuance request and sends a global verification success message to the secondary platform device upon successful global constraint verification. Furthermore, the secondary platform device itself also needs to perform local constraint verification on the license issuance request. Only when it receives both the global verification success message and the local constraint verification is successful—that is, when both the primary platform device's global constraint verification and the secondary platform device's local constraint verification are successful—will the secondary platform device respond to the license issuance request. This process introduces a cross-platform dual verification mechanism when processing license issuance requests. The upstream platform can monitor the license issuance behavior of the downstream platform in real time through global constraint verification, thereby reducing the problem of downstream platforms issuing licenses illegally.

[0091] As an example, Figure 3 This is a schematic diagram of the core authorization and verification process across levels in a hierarchical license management system provided in this application embodiment. Figure 3 This includes five interactive processes: processes 1.1-1.4 describe the terminal service process for Level 1 platform device L1; processes 2.1-2.2 describe the online terminal verification process for Level 1 platform device L1; processes 3.1-3.3 describe the lifecycle control process for Level 2 platform device L2; processes 4.1-4.4 describe the cross-platform dual verification process; and processes 5.1-5.2 describe the localized verification process for Level 2 platform device L2. The following sections will provide a detailed explanation of each of these five interactive processes.

[0092] Processes 1.1-1.4 and 2.1-2.2 are the basic business processes executed by the Level 1 platform device L1 as the general licensor. For L1 terminal business processes, the L1 Issuer receives terminal business requests related to the license (such as license issuance, renewal, or revocation requests) initiated by the L1 user terminal, pushes the corresponding license authorization information to the L1 Verifier, and synchronizes the status of the corresponding license to the L1 Verifier. The L1 Verifier receives and processes the information. After the L1 Verifier successfully processes the information, the L1 Issuer responds to the L1 user terminal to complete the terminal business, such as issuing a license to the L1 user terminal or revoking a license already issued to the L1 user terminal, etc. For the L1 terminal online verification process, the L1 user terminal initiates an online verification request to the L1 Verifier. The L1 Verifier checks the validity of the corresponding license and returns the corresponding online verification result to the L1 user terminal. Specifically, after receiving the terminal online verification request, the L1 Verifier first checks the validity of the request signature and the anti-replay identifier. Then, it queries the local database for the validity period and revocation status of the license pointed to by the online verification request. Only if the check is passed and the license is valid will the verification be passed and the corresponding online verification result be returned to the L1 user terminal.

[0093] For the lifecycle control process of L2 platform devices, the L1 Issuer first issues an activation license to the L2 Issuer, carrying the maximum number of licenses that L2 can issue. When the L2 Issuer service program starts, it must perform two-stage verification: local verification by the L2 Issuer and online verification by the L1 Verifier. The L2 Issuer will send an online verification request for the L2 activation license to the L1 Verifier. The L1 Verifier performs online verification of the activation license and returns the corresponding online verification result (including online verification success and online verification failure) to the L2 Issuer. Only when both the local verification of the L2 Issuer and the online verification of the L1 Verifier are successful will the L2 Issuer service be authorized to start. This mechanism is the basis for the L1 platform device's ability to remotely shut down the L2 platform device's license issuance capability. Specifically, if Level 1 platform device L1 discovers a specified violation by Level 2 platform device L2, Level 1 platform device L1 can revoke the startup license already issued to L2 through L1 Issuer. L1 Verifier will update the revocation status of the startup license to revoked. In this way, L2 Issuer will receive an online verification failure result returned by L1 Verifier in the subsequent scheduled startup license verification process, which will immediately trigger the forced shutdown of L2 Issuer, thus terminating the license issuance capability of Level 2 platform device L2.

[0094] For the cross-platform dual verification process, the L2 user terminal first initiates a terminal service request related to the license (such as a license issuance, renewal, or revocation request) to the L2 Issuer. After receiving the terminal service request, the L2 Issuer pushes information such as the license ID, anti-replay identifier, digital signature, and the number of licenses requested to the L1 Verifier to trigger the global constraint verification of the L1 Verifier. On the other hand, it pushes information such as the license ID, anti-replay identifier, digital signature, and license validity period to the L2 Verifier to trigger the local constraint verification of the L2 Verifier. Only when both the global constraint verification of the L1 Verifier and the local constraint verification of the L2 Verifier are successful can the L2 Issuer finally create and issue the corresponding license, thereby completing the response to the terminal service request, such as issuing the corresponding license to the L2 user terminal. If the global constraint verification of the L1 Verifier fails or the local constraint verification of the L2 Verifier fails, the L2 Issuer will immediately terminate the service response process.

[0095] For the localized verification process of L2 platform devices, it integrates continuous verification and traffic distribution mechanisms for terminal authorization. First, there is periodic verification of user terminal authorization. When an L2 user terminal runs, it initiates a periodic verification mechanism, accessing the L2 Verifier at a preset frequency to perform online verification of the license's validity status, ensuring the continued validity of the authorization. Specifically, when using a license, the L2 user terminal needs to call a license verification program. This program can be uniformly set to check the license's validity status every hour (e.g., checking if the license file exists, whether the signature verification passed, etc.), and then checking the time since the last successful online verification. If this time is less than 24 hours, no online verification request is needed; if it exceeds 24 hours, an online verification request must be initiated. If five consecutive online verifications fail, the L2 user terminal is forcibly terminated from the license-based software service. For the traffic offloading mechanism, the L2 user terminal initiates an online verification request to the L2 Verifier. The L2 Verifier checks the validity of the corresponding license and returns the online verification result to the L2 user terminal. The specific operations performed by the L2 Verifier for online verification are consistent with those performed by the L1 Verifier, both involving checking the license's validity period and revocation status, which will not be elaborated further here. It can be seen that by directing terminal verification traffic to the L2 Verifier, the verification pressure is locally distributed.

[0096] In summary, this application proposes a reliable and transparent dual verification mechanism that enables real-time, unavoidable, and mandatory technical control over the total authorization quota of downstream platforms by the upstream platform, preventing downstream platforms from issuing licenses beyond their quota. Furthermore, the upstream platform can quickly and remotely shut down non-compliant downstream authorization services by revoking their activation licenses, demonstrating strong regulatory enforcement capabilities. Additionally, by distributing the license verification service across secondary platform devices, localized traffic routing for verification is achieved, completely eliminating the single point of failure risk of traditional centralized architectures and significantly improving the system's horizontal scalability and high-concurrency processing capabilities.

[0097] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0098] The above mainly describes a hierarchical license management method based on dual verification. The following will describe a hierarchical license management device based on dual verification.

[0099] Please see Figure 4This application illustrates a tiered license management device based on dual verification, which is applied to a primary platform device connected to a secondary platform device. The device includes:

[0100] The global constraint verification module 401 is used to perform global constraint verification on the license issuance request when it receives a license issuance request sent by the secondary platform device;

[0101] The global verification information sending module 402 is used to send global verification success information to the secondary platform device when the global constraint verification is successful, so as to instruct the secondary platform device to respond to the license issuance request after receiving the global verification success information and the local constraint verification performed on the license issuance request is successful.

[0102] In one implementation of this application, the license issuance request carries the target number of licenses to be issued; the global constraint verification module includes:

[0103] The license quantity acquisition unit is used to obtain the upper limit of the number of licenses that can be issued to the secondary platform device and the number of historical licenses that have been issued to the secondary platform device when a license issuance request is received.

[0104] The license quantity determination unit is used to determine the remaining number of licenses that can be issued for secondary platform devices based on the upper limit of the license quantity and the historical number of licenses.

[0105] The global constraint verification unit is used to determine that the global constraint verification has failed if the number of target licenses exceeds the number of remaining licenses that can be issued.

[0106] In one implementation of this application, the primary platform device is provided with a first issuance service component and a first verification service component, and the secondary platform device is provided with a second issuance service component. The secondary platform device processes license issuance requests through the second issuance service component; the apparatus further includes:

[0107] The startup license issuance module is used to issue a startup license to the secondary platform device through the first issuance service component. This license is used to start the second issuance service component and carries the upper limit of the number of licenses that the secondary platform device can issue. This is to instruct the secondary platform device to send a first online verification request for the startup license to the primary platform device after successfully performing local verification of the startup license.

[0108] The startup license verification module is used to perform online verification of the startup license through the first verification service component after receiving the first online verification request, and send online verification success information to the secondary platform device after successful online verification, so as to instruct the secondary platform device to start the second issuance service component after receiving the online verification success information.

[0109] In one implementation of this application, the apparatus further includes:

[0110] The startup license revocation module is used to revoke the startup license through the first issuance service component and update the revocation status of the startup license to "revoked" through the first verification service component when it is determined that a secondary platform device has committed a specified violation.

[0111] The verification failure information sending module is used to send online verification failure information to the secondary platform device based on the revocation status through the first verification service component after receiving the second online verification request for the start license sent periodically by the secondary platform device, so as to instruct the secondary platform device to close the second issuance service component after receiving the online verification failure information.

[0112] See Figure 5 This application illustrates another tiered license management device based on dual verification, which is applied to a secondary platform device connected to a primary platform device. The device includes:

[0113] The license issuance request sending module 501 is used to send a license issuance request to the first-level platform device, instructing the first-level platform device to perform global constraint verification on the license issuance request upon receiving it, and to send global verification success information to the second-level platform device when the global constraint verification is successful.

[0114] The license issuance request response module 502 is used to respond to the license issuance request when it receives a global verification success message and the local constraint verification performed on the license issuance request is successful.

[0115] In one implementation of this application, the license issuance request carries the type of license to be issued; the device further includes:

[0116] The local constraint verification module determines that local constraint verification fails if the license type is a startup license used to launch the issuance service component.

[0117] In one implementation of this application embodiment, the secondary platform device is provided with a second verification service component; the device further includes:

[0118] The local online verification module is used to query the validity period and revocation status of the issued license through the second verification service component when it receives an online verification request for the issued license sent by the secondary terminal device. If the validity period has not expired and the revocation status is not revoked, it responds to the online verification request.

[0119] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the dual-verification-based hierarchical license management method described in any of the above embodiments.

[0120] This application also provides a computer program product that, when run on a platform device, causes the platform device to execute the dual-verification-based hierarchical license management method as described in any of the above embodiments.

[0121] Figure 6 This is a schematic diagram of a platform device provided in one embodiment of this application. For example... Figure 6 As shown, the platform device 6 in this embodiment includes: a processor 60, a memory 61, and a computer program 62 stored in the memory 61 and executable on the processor 60. When the processor 60 executes the computer program 62, it implements the steps in the embodiments of the dual-verification-based hierarchical license control method described above. Alternatively, when the processor 60 executes the computer program 62, it implements the functions of each module / unit in the above-described device embodiments, for example, implementing... Figure 4 The functions of modules 401-402 of the device shown, or their implementation Figure 5 The functions of modules 501-502 of the device shown.

[0122] The computer program 62 can be divided into one or more modules / units, which are stored in the memory 61 and executed by the processor 60 to complete this application. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 62 in the platform device 6.

[0123] The processor 60 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0124] The memory 61 can be an internal storage unit of the platform device 6, such as a hard disk or memory of the platform device 6. The memory 61 can also be an external storage device of the platform device 6, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the platform device 6. Furthermore, the memory 61 can include both internal and external storage units of the platform device 6. The memory 61 is used to store the computer program and other programs and data required by the platform device. The memory 61 can also be used to temporarily store data that has been output or will be output.

[0125] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0126] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

[0128] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0129] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules or 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 coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0130] 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 the embodiments of this application, depending on actual needs.

[0131] 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.

[0132] 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 medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0133] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A hierarchical license management method based on dual verification, characterized in that, The method, applied to a primary platform device connected to a secondary platform device, includes: Upon receiving a license issuance request from the secondary platform device, a global constraint check is performed on the target number of licenses to be issued carried in the license issuance request; if the target number of licenses does not exceed the remaining number of licenses that the secondary platform device can issue, then the global constraint check is determined to be successful. When the global constraint verification is successful, a global verification success message is sent to the secondary platform device to instruct the secondary platform device to respond to the license issuance request if it receives the global verification success message and performs local constraint verification on the anti-replay identifier, digital signature and license information carried in the license issuance request. If the anti-replay identifier check passes, the digital signature verification passes, and the license information is valid, then the local constraint verification is determined to be successful.

2. The method as described in claim 1, characterized in that, The remaining number of licenses that can be issued is determined by the following: Upon receiving the license issuance request, obtain the maximum number of licenses that the secondary platform device can issue and the historical number of licenses that the secondary platform device has issued; The remaining number of licenses that can be issued is determined based on the upper limit of the number of licenses and the historical number of licenses.

3. The method as described in claim 1 or 2, characterized in that, The primary platform device is equipped with a first issuance service component and a first verification service component, and the secondary platform device is equipped with a second issuance service component. The secondary platform device processes the license issuance request through the second issuance service component. Before the secondary platform device sends the license issuance request, the method further includes: The first issuance service component issues an activation license to the secondary platform device for starting the second issuance service component and carries the upper limit of the number of licenses that the secondary platform device can issue, so as to instruct the secondary platform device to send a first online verification request for the activation license to the primary platform device after successfully performing local verification of the activation license. Upon receiving the first online verification request, the system performs online verification of the startup license through the first verification service component, and sends an online verification success message to the secondary platform device after the online verification of the startup license is successful, so as to instruct the secondary platform device to start the second issuance service component after receiving the online verification success message.

4. The method as described in claim 3, characterized in that, After activating the second issuance service component, the method further includes: When it is determined that the secondary platform device has committed a specified violation, the startup license is revoked through the first issuing service component, and the revocation status of the startup license is updated to revoked through the first verification service component. Upon receiving the second online verification request for the launch license sent periodically by the secondary platform device, the first verification service component sends an online verification failure message to the secondary platform device based on the revocation status, instructing the secondary platform device to close the second issuance service component upon receiving the online verification failure message.

5. A hierarchical license management method based on dual verification, characterized in that, The method, applied to a secondary platform device connected to a primary platform device, includes: A license issuance request is sent to the primary platform device to instruct the primary platform device to perform a global constraint check on the target number of licenses to be issued carried in the license issuance request when it receives the license issuance request, and to send a global check success message to the secondary platform device when the global constraint check is successful; if the target number of licenses does not exceed the remaining number of licenses that the secondary platform device can issue, then the global constraint check is determined to be successful. Upon receiving the global verification success message and successfully performing local constraint verification on the anti-replay identifier, digital signature, and license information carried in the license issuance request, the system responds to the license issuance request; if the anti-replay identifier check passes, the digital signature verification passes, and the license information is valid, then the local constraint verification is determined to be successful.

6. The method as described in claim 5, characterized in that, The license issuance request carries the type of license to be issued; The local constraint verification process also includes: If the license type is a startup license used to launch the issuance service component, then the local constraint verification is determined to have failed.

7. The method as described in claim 5 or 6, characterized in that, The secondary platform device is equipped with a second verification service component; the method further includes: Upon receiving an online verification request for an issued license from a secondary terminal device, the second verification service component queries the validity period and revocation status of the issued license. If the validity period has not expired and the revocation status is not revoked, the online verification request is responded to.

8. A platform device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the hierarchical license management method based on dual verification as described in any one of claims 1 to 4.

9. A platform device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the hierarchical license management method based on dual verification as described in any one of claims 5 to 7.

10. A hierarchical license management system based on dual verification, characterized in that, It includes the platform device as described in claim 8 and at least one platform device as described in claim 9.

Images