Software authentication and licensing processing methods, systems and electronic devices

Abstract

This application provides a software authentication and licensing processing method, system, and electronic device. The method includes receiving a software authentication and licensing request sent by a client, wherein the software authentication and licensing request is generated by the client in response to an input operation on an authentication and licensing selection interface; generating a smart contract based on the software authentication and licensing request; determining a target virtual asset corresponding to the client in the blockchain through the smart contract; and allocating the target virtual asset to the client so that the client can authorize and activate the software through the target virtual asset. This application improves the flexibility of the software authentication and licensing service, reduces the risk of data leakage, and enhances the security of the software authentication and licensing service.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a software authentication and licensing processing method, system, and electronic device. Background Technology

[0002] As the number of software programs increases, software management becomes more professional. For example, software authorization can be managed through licenses (software certification licenses).

[0003] In existing technologies, when authorizing software using a license, the user needs to activate the license first, and then access the corresponding software based on the activated license. During the license activation process, different users' clients need to send activation requests to the same central server, and the activation of the corresponding software is completed through this central server.

[0004] However, if the central server malfunctions due to network failures or hacker attacks, the entire license service system may be unable to operate normally, affecting the stability of the license service and increasing the risk of data leakage, thus reducing the security of the application license service. Summary of the Invention

[0005] This application provides a software authentication and licensing processing method, system, and electronic device to improve the security of application license services.

[0006] In a first aspect, embodiments of this application provide a software authentication and licensing processing method applied to blockchain, comprising:

[0007] Receive a software authentication license request sent by a client, wherein the software authentication license request is generated by the client in response to an input operation performed on the authentication license selection interface;

[0008] Generate a smart contract based on the software authentication license request;

[0009] The smart contract determines the target virtual asset corresponding to the client in the blockchain and allocates the target virtual asset to the client so that the client can authorize and activate the software through the target virtual asset.

[0010] Optionally, determining the target virtual asset corresponding to the client in the blockchain through the smart contract includes:

[0011] The target virtual asset corresponding to the client is determined in the blockchain by the software type, purchase quantity, and usage duration contained in the smart contract.

[0012] Optionally, the type of software to be activated is one, and the step of enabling the client to authorize and activate the software through the target virtual asset includes:

[0013] Receive a software activation request sent by the client, wherein the software activation request contains a first number of software to be activated;

[0014] The first virtual asset to be used is determined based on the first quantity and the virtual assets corresponding to a single pre-stored software to be activated.

[0015] If the target virtual asset is no less than the first virtual asset to be used, then the first number of software will be activated for the client.

[0016] Optionally, after activating the first number of software applications for the client, the process further includes:

[0017] Update the target virtual asset based on the first virtual asset to be used;

[0018] If the updated target virtual assets are less than the preset virtual asset threshold, a virtual asset shortage warning will be sent to the client.

[0019] Optionally, after sending the virtual asset shortage warning to the client, the method further includes:

[0020] Receive a recharge request sent by the client, wherein the recharge request contains virtual assets to be recharged;

[0021] The virtual assets to be recharged are allocated to the client according to the recharge request.

[0022] Optionally, the type of software to be activated can be various, and the step of enabling the client to authorize and activate the software through the target virtual asset includes:

[0023] The system receives a software activation request sent by the client, wherein the software activation request includes the type of software to be activated and a second quantity of each type of software to be activated;

[0024] Based on the client's permission information, determine whether different types of software to be activated can simultaneously authorize the client;

[0025] If the different types of software to be activated can authorize the client at the same time, then the second virtual asset to be used is determined according to the number of each type of software to be activated in the software activation request and the virtual assets corresponding to each type of software to be activated that are stored in advance.

[0026] If the target virtual asset is no less than the second virtual asset to be used, then activate a second number of software of different types for the client.

[0027] Optionally, if the software authentication license request includes a client public key, then generating a smart contract based on the software authentication license request includes:

[0028] Determine whether the client's public key corresponds to the blockchain's private key;

[0029] If the client's public key corresponds to the blockchain's private key, a smart contract is generated based on the software authentication license request.

[0030] Optionally, after enabling the client to authorize and activate the software through the target virtual asset, the method further includes:

[0031] Receive the query request sent by the client;

[0032] The software status information corresponding to the client is determined through the query request, wherein the software status information includes the virtual assets currently owned by the client, as well as the usage duration and expiration time of the activated software;

[0033] The software status information is sent to the client.

[0034] Secondly, embodiments of this application provide a software authentication and licensing processing method, applied to a client, including:

[0035] Respond to input operations performed on the authentication and licensing selection interface to determine the software authentication and licensing request;

[0036] The software authentication license request is uploaded to the blockchain, so that the blockchain generates a smart contract based on the software authentication license request, and through the smart contract, the target virtual asset corresponding to the client is determined in the blockchain, and the target virtual asset is allocated to the client.

[0037] The software is authorized and activated based on the target virtual asset.

[0038] Optionally, the response acts on the input operation of the authentication and license selection interface to determine the software authentication and license request, including:

[0039] In response to an input operation applied to the target parameters in the authentication and licensing selection interface, a software authentication and licensing request is determined, wherein the target parameters include at least one of the following: number of software programs, software type, and usage duration.

[0040] Optionally, after the software is licensed and activated based on the target virtual asset, the method further includes:

[0041] In response to a touch operation applied to the query control, a query request is generated and sent to the blockchain, so that the blockchain can determine the software status information corresponding to the client through the query request. The software status information includes the virtual assets currently owned by the client, as well as the usage time and expiration time of the activated software.

[0042] Receive and display the software status information sent by the blockchain.

[0043] Thirdly, embodiments of this application provide a software authentication and licensing processing system, including a client and a blockchain.

[0044] The client is configured to respond to input operations on the authentication and license selection interface, determine the software authentication and license request, and send the software authentication and license request to the blockchain;

[0045] The blockchain is used to receive software authentication and license requests sent by the client, generate smart contracts based on the software authentication and license requests, determine the target virtual asset corresponding to the client in the blockchain through the smart contracts, and allocate the target virtual asset to the client.

[0046] The client is also used to authorize and activate the software through the target virtual asset.

[0047] Fourthly, embodiments of this application provide a software authentication and licensing processing apparatus applied to blockchain, comprising:

[0048] A receiving module is used to receive a software authentication license request sent by a client, wherein the software authentication license request is generated by the client in response to an input operation performed on the authentication license selection interface;

[0049] The first processing module is used to generate a smart contract based on the software authentication and licensing request.

[0050] The first processing module is further configured to determine, through the smart contract, a target virtual asset corresponding to the client in the blockchain, and allocate the target virtual asset to the client so that the client can authorize and activate the software through the target virtual asset.

[0051] Fifthly, embodiments of this application provide a software authentication and licensing processing apparatus, applied to a client, comprising:

[0052] The response module is used to respond to input operations performed on the authentication and licensing selection interface and to determine the software authentication and licensing request;

[0053] The second processing module is used to upload the software authentication license request to the blockchain, so that the blockchain generates a smart contract according to the software authentication license request, and through the smart contract, determines the target virtual asset corresponding to the client in the blockchain, and allocates the target virtual asset to the client.

[0054] The second processing module is used to authorize and activate the software based on the target virtual asset.

[0055] Sixthly, embodiments of this application provide an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0056] The memory stores computer-executed instructions;

[0057] The processor executes computer execution instructions stored in the memory to implement the software authentication and licensing processing method described in the first aspect and various possible designs of the first aspect.

[0058] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the software authentication and licensing processing method described in the first aspect and various possible designs of the first aspect.

[0059] Eighthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the software authentication and licensing processing method described in the first aspect and various possible designs of the first aspect.

[0060] This application provides a software authentication and licensing processing method, system, and electronic device. Using this solution, the blockchain can first receive a software authentication and licensing request from a client, then generate a smart contract based on the request, and then determine the target virtual asset corresponding to the client from the blockchain according to the smart contract. The target virtual asset is then allocated to the client, enabling the client to authorize and activate the software through it. By implementing the software authentication and licensing service based on a decentralized blockchain, the system avoids the situation where the entire service fails due to a central server malfunction, thus improving the stability of the service. Furthermore, the method of allocating virtual assets to the client through smart contracts, allowing the client to authorize and activate the software through the allocated virtual assets, enhances the flexibility of the software authentication and licensing service, reduces the risk of data leakage, and improves the security of the service. Attached Figure Description

[0061] To more clearly illustrate the technical solutions in the embodiments of this application 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0062] Figure 1 This is a schematic diagram of the architecture of the software activation process in the prior art;

[0063] Figure 2 This is a schematic diagram of the architecture of the software authentication and licensing processing system provided in the embodiments of this application;

[0064] Figure 3 A flowchart illustrating the software authentication and licensing processing method provided in this application embodiment;

[0065] Figure 4 A flowchart illustrating a software authentication and licensing processing method provided in another embodiment of this application;

[0066] Figure 5 A flowchart illustrating a software authentication and licensing processing method provided in another embodiment of this application;

[0067] Figure 6 This is an application illustration of the authentication and licensing selection interface provided in an embodiment of this application;

[0068] Figure 7 A schematic diagram of the structure of the software authentication and licensing processing device provided in the embodiments of this application;

[0069] Figure 8 A schematic diagram of the structure of a software authentication and licensing processing apparatus provided in another embodiment of this application;

[0070] Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0071] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0072] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can also include other sequential examples besides those illustrated or described. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0073] First, let me explain the terms used in this application:

[0074] Software certification license: also known as a license, is required to protect the legitimate rights and interests of software development companies. Software needs to be authorized and activated before it can be used normally. Correspondingly, software can be authorized and activated through a license.

[0075] Blockchain: A decentralized database is a chain of data blocks linked together using cryptographic methods. It features unforgeability, full traceability, transparency, and collective maintenance.

[0076] Smart contracts are essentially computer-executable programs, automatically executed computer contracts based on defined triggering rules, and can be seen as digital versions of traditional contracts. Because blockchain technology uses a block-chain ledger, the data generated cannot be tampered with or deleted, and the ledger is constantly updated, ensuring the traceability of historical data. At the same time, the decentralized operating mechanism avoids the influence of centralized factors. Smart contracts based on blockchain technology not only leverage the advantages of smart contracts in terms of cost and efficiency but also prevent malicious interference with the normal execution of contracts. By writing smart contracts digitally into the blockchain, the characteristics of blockchain technology ensure that the entire process of storage, retrieval, and execution is transparent, traceable, and tamper-proof.

[0077] Virtual assets: also known as tokens, can represent different forms of digital assets and can be understood as tradable digital proof of rights.

[0078] The application scenarios and inventive concepts of this application will be explained below.

[0079] With the development of network technology, various types of software (such as video software, office software, etc.) are becoming increasingly common. To protect the rights and interests of software development companies, licenses can be used to manage software authorization, that is, to restrict whether clients have the right to access related software. When authorizing software through a license, the client can first send a software authentication license request to the server. The server can activate the license based on the software authentication license request, and then the client can access the corresponding software based on the activated license. Figure 1 This is a schematic diagram of the architecture of the software activation process in the prior art, such as... Figure 1 As shown, in existing technologies, during the license activation process, different users' clients all need to send activation requests to the same central server, which then completes the activation of the corresponding software. If this central server malfunctions due to network failures or hacker attacks, the entire license service system may be unable to operate normally, affecting the stability of the license service. Furthermore, it is prone to data leakage (such as private key leakage), leading to the development of cracked software and reducing the security of the application license service.

[0080] To address the aforementioned technical challenges, this application implements a software authentication and licensing service based on a decentralized blockchain. This avoids the situation where the entire software authentication and licensing service cannot function properly due to a failure of the central server, thus improving the stability of the software authentication and licensing service. Furthermore, by using smart contracts to allocate virtual assets to clients, allowing them to authorize and activate software through these virtual assets, the application enhances the flexibility of the software authentication and licensing service, reduces the risk of data leakage, and improves the security of the software authentication and licensing service.

[0081] Figure 2 This is a schematic diagram of the architecture of the software authentication and licensing processing system provided in the embodiments of this application, such as... Figure 2 As shown, this system may include a blockchain and a client.

[0082] The client is configured to respond to input operations performed on the authentication and licensing selection interface, determine the software authentication and licensing request, and send the software authentication and licensing request to the blockchain.

[0083] The blockchain is used to receive software authentication and license requests sent by the client, generate smart contracts based on the software authentication and license requests, determine the target virtual asset corresponding to the client in the blockchain through the smart contracts, and allocate the target virtual asset to the client.

[0084] The client is also used to authorize and activate the software through the target virtual asset.

[0085] In this embodiment, the client can receive touch operations from the user on the authentication and licensing selection interface, generate a software authentication and licensing request, and then upload this request to any node in the blockchain. After receiving the client's software authentication and licensing request, the blockchain can generate a smart contract based on the request and determine the target virtual asset corresponding to the client from the blockchain according to the smart contract. The blockchain can then allocate the corresponding target virtual asset to the client. After receiving the target virtual asset, the client can use it to authorize and activate the software.

[0086] Furthermore, there can be multiple clients, each of which can upload a software authentication license request to the blockchain. The blockchain can generate a smart contract corresponding to the client based on the software authentication license request uploaded by the client. That is, different clients can correspond to different smart contracts, and the software authorization methods in different smart contracts are different. Therefore, different clients can obtain software authentication licenses with different authorization methods, which improves the flexibility of the software authentication license process.

[0087] Furthermore, the authentication and licensing selection interface can include at least one target parameter. The client can respond to touch operations applied to the target parameter to generate a software authentication and licensing request. The target parameter can be at least one of the following: number of software programs, software type, and usage duration. By generating a software authentication and licensing request corresponding to the user's selection based on the user's touch operation, and then generating different software licensing methods based on this request, the flexibility of software licensing methods is improved.

[0088] The client can be a smartphone, personal computer, tablet, or smart wearable device that can install software and request software certification and license.

[0089] The technical solutions of this application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0090] Figure 3 This is a flowchart illustrating a software authentication and licensing method provided in an embodiment of this application. The method in this embodiment can be executed by a blockchain. Figure 3 As shown, the method in this embodiment may include:

[0091] S301: Receive software authentication license request sent by the client.

[0092] The software authentication license request is generated by the client's response to the input operation applied to the authentication license selection interface.

[0093] In this embodiment, when a client needs to obtain software authorization, it can generate a software authentication license request and upload the software authentication license request to the blockchain.

[0094] Furthermore, there are multiple ways to generate software authentication license requests. In one implementation, the software authentication license request can be customized by responding to the user's touch operation on the authentication license selection interface. The user can customize the parameters related to the software to be authorized through touch operations, and the blockchain can then generate different authorization methods for the software authentication license based on the selected parameters. For example, the parameters related to the software to be authorized can be the number of software programs, the software type, or the usage duration.

[0095] In another implementation, the client can directly generate a software authentication license request in a default format. This default format can include commonly used parameters (such as the number of software programs, usage duration, etc.) or required parameters (such as the software type) predetermined based on the actual application scenario.

[0096] S302: Generate a smart contract based on a software certification license request.

[0097] In this embodiment, after receiving a software authentication and licensing request, the blockchain can generate a smart contract based on the relevant parameters contained in the request. Each smart contract is only available to the client, which improves the security of the software authentication and licensing process.

[0098] Furthermore, each software certification license request contains different parameters, and the smart contract generated for each client is also different, which increases the flexibility of smart contract generation and thus improves the user's application experience.

[0099] For example, the software certification license request uploaded by client A includes parameters such as software type, number of each software, and usage duration. The software type is A1, there are 3 software programs, and each has a usage duration of one month. Therefore, a smart contract 'a' corresponding to client A can be generated based on this information. The content of smart contract 'a' is that client A has applied for certification licenses for software A1, applying for three licenses, with each software having a usage duration of one month. Similarly, client B can also upload a software certification license request to the blockchain. This request can also include parameters such as software type, number of each software, and usage duration. The software types are B1, B2, and B3, with two B1 software programs, one B2 and one B3 software program, and each having a usage duration of two months. Therefore, a smart contract 'b' corresponding to client B can be generated based on this information. In this case, smart contract b can apply for certification licenses for software B1, B2 and B3 for client B. There are 2 applications for software B1 and 1 application for software B2 and B3. The usage period for software B1, B2 and B3 is two months.

[0100] S303: Through smart contracts, a target virtual asset corresponding to the client is determined in the blockchain, and the target virtual asset is allocated to the client so that the client can authorize and activate the software through the target virtual asset.

[0101] In this embodiment, after the smart contract is generated, the target virtual asset corresponding to the client can be determined in the blockchain based on the relevant information contained in the smart contract. The relevant information contained in the smart contract can be extracted from the software authentication license request submitted by the client; for example, it can be parameters related to software authentication licenses (such as software type, number of software programs, etc.) extracted from the software authentication license request submitted by the client.

[0102] Furthermore, the step of determining the target virtual asset corresponding to the client in the blockchain through the smart contract may specifically include:

[0103] The target virtual asset corresponding to the client is determined in the blockchain by the software type, purchase quantity, and usage duration contained in the smart contract.

[0104] Specifically, different software can have different values, which can be represented by virtual assets; that is, different software can correspond to different virtual assets. Similarly, different usage durations can also correspond to different virtual assets. Therefore, the software type and usage duration contained in the smart contract can be used to first determine the corresponding virtual assets in the blockchain, and then the target virtual asset corresponding to the client can be finally determined based on the purchase quantity.

[0105] For example, the software type can be A1, and the corresponding virtual asset is 2 virtual coins per day. If client A purchases 3 A1s, and each A1 is used for one month, then the target virtual asset to be allocated to client A is 3 * 2 * 30 = 180 virtual coins. Alternatively, the virtual asset for the software can be defined in monthly or yearly units. For example, the virtual asset for software type A1 can be defined as 50 virtual coins per month.

[0106] Furthermore, the smart contract may only include the purchase quantity and usage duration, without including the software type. In this implementation, the software defaults to only one type. Therefore, the target virtual asset corresponding to the client can be determined by the purchase quantity and usage duration, and the target virtual asset is determined by multiplying the virtual asset corresponding to the default software per day by the purchase quantity and usage duration.

[0107] By adopting the above scheme, the blockchain can first receive software authentication and licensing requests sent by clients, then generate smart contracts based on the requests, and then determine the target virtual asset corresponding to the client from the blockchain according to the smart contract. The blockchain then allocates the target virtual asset to the client, enabling the client to authorize and activate the software through the target virtual asset. By implementing the software authentication and licensing service based on a decentralized blockchain, the system avoids the situation where the entire service fails due to a central server malfunction, thus improving the stability of the service. Furthermore, the method of allocating virtual assets to clients through smart contracts, allowing them to authorize and activate the software, enhances the flexibility of the software authentication and licensing service, reduces the risk of data leakage, and improves its security.

[0108] based on Figure 3 In addition to the method described herein, this specification also provides some specific implementation schemes of the method, which will be described below.

[0109] In another embodiment, the type of software to be activated is one, and the step of enabling the client to authorize and activate the software through the target virtual asset may specifically include:

[0110] Receive a software activation request sent by the client, wherein the software activation request contains a first number of software to be activated.

[0111] The first virtual asset to be used is determined based on the first quantity and the virtual assets corresponding to a single pre-stored software to be activated.

[0112] If the target virtual asset is no less than the first virtual asset to be used, then the first number of software will be activated for the client.

[0113] In this embodiment, after allocating target virtual assets to the client, the client can activate the software based on the allocated target virtual assets. Furthermore, when making a software authentication and licensing request, the client can request activation of one type of software or multiple types of software. If the client requests only one type of software, only that type of software can be activated. Therefore, when there is only one type of software to be activated, the software type does not need to be included in the software activation request sent by the client; only the quantity of software to be activated needs to be included. After receiving the software activation request sent by the client, the blockchain determines the first virtual asset to be used based on the first quantity included in the software activation request and the virtual assets corresponding to the software to be activated pre-requested by the client. After determining the first virtual asset to be used, the target virtual assets pre-allocated to the client can be compared with the first virtual asset to be used. If the target virtual asset is greater than or equal to the first virtual asset to be used, the first quantity of software is activated for the client.

[0114] Furthermore, after activating the first number of software applications for the client, the process may also include:

[0115] The target virtual asset is updated based on the first virtual asset to be used.

[0116] If the updated target virtual assets are less than the preset virtual asset threshold, a virtual asset shortage warning will be sent to the client.

[0117] Specifically, after activating the first number of software applications for the client, the target virtual assets can be updated based on the first set of virtual assets to be used. Then, it can be determined whether the updated target virtual assets are less than a preset virtual asset threshold. If it is determined that the updated target virtual assets are less than the preset virtual asset threshold, a virtual asset shortage warning is sent to the client. The virtual asset threshold can be customized according to the actual application scenario. For example, it can be 0, or any value between 1 and 5 virtual coins. By setting the virtual asset threshold, the client can be promptly reminded when their virtual assets are low, improving the user experience.

[0118] For example, client A purchases 3 A1s, each with a one-month usage period. Therefore, the target virtual asset allocated to client A is 3 * 2 * 30 = 180 virtual coins. Upon initial activation, client A activates one A1, meaning the first virtual asset to be used is 60 virtual coins. Since 60 virtual assets are less than the target virtual asset of 180, one A1 can be activated for the client. After activating another A1, to ensure data accuracy, the client's corresponding target virtual asset needs to be updated. This is done by subtracting the first virtual asset of 60 from the original target virtual asset of 180, resulting in 120 virtual coins. The updated target virtual asset is 120 virtual coins. The next time the client activates the software, the virtual assets to be used must be compared with the updated target virtual asset. Only after confirming that the updated target virtual asset is not less than the virtual assets to be used will the corresponding number of software units be activated for the client.

[0119] In summary, by promptly updating the virtual assets corresponding to the client after activating the software, the accuracy of the virtual assets corresponding to the client is improved.

[0120] Furthermore, after sending the virtual asset shortage warning to the client, the process may also include:

[0121] Receive a recharge request sent by the client, wherein the recharge request contains virtual assets to be recharged.

[0122] The virtual assets to be recharged are allocated to the client according to the recharge request.

[0123] Specifically, after sending a virtual asset shortage warning to the client, if the client wants to continue using the software, they can directly recharge by sending a recharge request containing the virtual assets to be recharged to the blockchain. The blockchain can then allocate the virtual assets to the client based on this recharge request. In this allocation, the virtual assets can be distributed using the client's public key address.

[0124] For example, if the recharge request includes 200 virtual coins, the blockchain can directly allocate 200 virtual coins to the client after receiving the recharge request. If the client previously had 30 virtual coins remaining, then the client now has 30 + 200 virtual coins.

[0125] In summary, existing technologies for authorizing and activating software for clients do not involve the reuse of public key addresses. They simply provide the client with image data containing the usage duration, which expires after the duration is reached. Subsequent user requests to use the software require re-verification and activation, a cumbersome and inflexible process. In contrast, the client in this application can directly top up the public key address upon realizing insufficient virtual assets. This public key address can then be used for subsequent software authentication and licensing applications. The process is simple, highly flexible, and significantly improves the user experience.

[0126] In another embodiment, the type of software to be activated is multifaceted, and the step of enabling the client to authorize and activate the software through the target virtual asset may specifically include:

[0127] The system receives a software activation request sent by the client, wherein the software activation request includes the type of software to be activated and a second quantity of each type of software to be activated.

[0128] Based on the client's permission information, determine whether different types of software to be activated can simultaneously authorize the client.

[0129] If the different types of software to be activated can simultaneously authorize the client, then the second virtual asset to be used is determined based on the number of each type of software to be activated in the software activation request and the virtual assets corresponding to each type of software to be activated that are pre-stored.

[0130] If the target virtual asset is no less than the second virtual asset to be used, then activate a second number of software of different types for the client.

[0131] In this embodiment, when there are multiple types of software to be activated on the client, the software activation request can include the types of software to be activated, as well as a second quantity corresponding to each type of software to be activated. However, each client has different permission information. This permission information restricts the client's role (for example, a regular employee's client cannot install software with administrator privileges), and also avoids situations where software that cannot be installed on one client is installed on the same client (for example, software A and B are different versions of the same software and cannot be installed on the same client, or software A and B are mutually exclusive types of software and cannot be installed on the same client). The specific content of the permission information can be customized according to the actual application scenario, and will not be detailed here.

[0132] Furthermore, after determining that different types of software to be activated can simultaneously authorize clients, the second set of virtual assets to be used can be determined based on the number of each type of software to be activated in the software activation request and the pre-stored virtual assets corresponding to each type of software to be activated. The relationship between the target virtual asset and the second set of virtual assets to be used is then determined. If the target virtual asset is no less than the second set of virtual assets to be used, then the second number of software of different types will be activated for the client.

[0133] Furthermore, after determining that different types of software to be activated cannot be authorized to the client simultaneously, a prompt indicating that simultaneous authorization is not possible can be sent to the client to remind them to modify the type of software to be activated. For example, one type of software that cannot be authorized simultaneously can be deleted, or one type of software that cannot be authorized simultaneously can be replaced with another type of software. After the client has modified the type of software to be activated, a second software activation request containing the type of software to be activated and the second number of software activation requests corresponding to each type of software can be resent to the blockchain.

[0134] In summary, by performing permission checks on various types of software to be activated, conflicting or unauthorized software is prevented from being installed on the client, thus improving the accuracy and security of software installation.

[0135] In addition, the target virtual asset can be updated based on the second virtual asset to be used.

[0136] If the updated target virtual assets are less than the preset virtual asset threshold, a virtual asset shortage warning will be sent to the client.

[0137] Additionally, after sending the virtual asset shortage warning to the client, the process may further include:

[0138] Receive a recharge request sent by the client, wherein the recharge request contains virtual assets to be recharged.

[0139] The virtual assets to be recharged are allocated to the client according to the recharge request.

[0140] In addition, after receiving a software activation request from a new client containing multiple types of software to be activated, a new second virtual asset to be used can be determined, and the new second virtual asset to be used can be compared with the updated target virtual asset. If the updated target virtual asset is no less than the new second virtual asset to be used, and the different types of software to be activated are all software that can be installed on the client at the same time, then the different types of software will be activated for the client.

[0141] In another embodiment, if the software authentication license request includes a client public key, then generating a smart contract based on the software authentication license request may specifically include:

[0142] Determine whether the client's public key corresponds to the blockchain's private key.

[0143] If the client's public key corresponds to the blockchain's private key, a smart contract is generated based on the software authentication license request.

[0144] In this embodiment, after the blockchain is created, a public key can be sent to each client communicating with it. When a client sends a software authentication license request to the blockchain, it can encrypt the software authentication license request using the received public key. After receiving the software authentication license request, the blockchain can decrypt it using its private key. If the decryption is successful, it indicates that the client's public key corresponds to the blockchain's private key, meaning that the client can be a trusted client of the blockchain, and a smart contract can be generated based on the software authentication license request.

[0145] In summary, by determining whether the client's public key corresponds to the blockchain's private key, and only generating a smart contract based on the software authentication and licensing request when the client's public key corresponds to the blockchain's private key, the security of the smart contract generation process is improved, thereby ensuring the security of the software authentication and licensing process.

[0146] In another embodiment, after enabling the client to authorize and activate the software through the target virtual asset, the process may further include:

[0147] Receive the query request sent by the client.

[0148] The query request determines the software status information corresponding to the client, wherein the software status information includes the virtual assets currently owned by the client, as well as the usage duration and expiration time of the activated software.

[0149] The software status information is sent to the client.

[0150] In this embodiment, when the client authorizes and activates the software via blockchain, query permissions can be granted to facilitate real-time monitoring of software usage. This allows the client to directly query software status information. The software status information may include the client's currently owned virtual assets, the duration of activated software usage, and the expiration date. The client's currently owned virtual assets can be the updated target virtual assets, which can be obtained by subtracting the target virtual assets allocated to the client from the virtual assets currently in use.

[0151] In summary, granting query permissions to clients not only improves their user experience but also provides a basis for their subsequent operations by allowing them to query information such as the usage duration and expiration date of activated software. This prevents the software from becoming unusable without their knowledge due to expiration.

[0152] Figure 4 A flowchart illustrating a software authentication and licensing method provided in another embodiment of this application is shown below. Figure 4 As shown, the method in this embodiment may include: a software authentication and licensing server can first create a Turing-complete smart contract blockchain, ensuring that blocks are continuously generated and that the blockchain's private key is never exposed to the internet. After setting parameters in the authentication and licensing selection interface (also known as the authentication and licensing purchase interface), the client can generate a software authentication and licensing request and upload it to the blockchain. Upon receiving the software authentication and licensing request, the blockchain can first determine whether the request is valid. If valid, a smart contract can be generated on the blockchain based on the request, and this smart contract is only available to the client. If invalid, a new software authentication and licensing request is received, and its validity is determined. After generating the smart contract, the target virtual asset corresponding to the client can be determined based on the smart contract, and the target virtual asset can be allocated to the client. After receiving the allocated target virtual assets, the client can send an activation request to the blockchain. The activation request may include the number of software to be activated. The blockchain can determine the virtual assets to be used based on the number of software to be activated and check whether the target virtual assets are not less than the virtual assets to be used. If they are not less than the target virtual assets, the software can be authorized and activated. If they are less than the target virtual assets, a virtual asset shortage prompt will be generated.

[0153] In summary, using blockchain to implement the entire software licensing and authentication process achieves decentralization. As long as any node exists, the software licensing and authentication process will not be in an abnormal state. Furthermore, the authentication service provider only needs to deposit the corresponding amount of virtual assets into the user's public key address after the user's smart contract is first generated, which simplifies the software licensing and authentication process.

[0154] Figure 5 This is a flowchart illustrating a software authentication and licensing method according to another embodiment of this application. The method in this embodiment can be executed by a client. Figure 5 As shown, the method in this embodiment may include:

[0155] S501: In response to an input operation performed on the authentication and licensing selection interface, determine the software authentication and licensing request.

[0156] S502: Upload the software authentication license request to the blockchain so that the blockchain generates a smart contract based on the software authentication license request, and through the smart contract, determine the target virtual asset corresponding to the client in the blockchain, and allocate the target virtual asset to the client.

[0157] S503: Authorize and activate the software based on the target virtual asset.

[0158] In this embodiment, the client can respond to the input operation on the authentication license selection interface, determine the software authentication license request, and upload the software authentication license request to any block in the blockchain.

[0159] Furthermore, the response acting on the input operation of the authentication and licensing selection interface to determine the software authentication and licensing request may include:

[0160] In response to an input operation applied to the target parameters in the authentication and licensing selection interface, a software authentication and licensing request is determined, wherein the target parameters include at least one of the following: number of software programs, software type, and usage duration.

[0161] Specifically, the authentication and licensing selection interface can include multiple target parameters related to software authentication and licensing. Users can select the desired target parameters through input operations and generate a software authentication and licensing request based on the selected parameters. Subsequently, the generated software authentication and licensing request is uploaded to the blockchain. The blockchain can generate a smart contract corresponding to the client based on the parameters contained in the software authentication and licensing request. Among them, the target parameters can include at least one of the following: number of software programs, software type, and usage duration.

[0162] For example, Figure 6 This is an application illustration of the authentication and licensing selection interface provided in the embodiments of this application, such as... Figure 6 As shown, this embodiment may include the number of software programs, software types, and usage duration. The number of software programs can be one, two, or more, depending on actual needs. Software types can also be multiple, representing different types of software. For example, software types can be A, B, and C, representing software A, software B, and software C, respectively. Usage duration can also be varied and can be set in different units, such as days or months. For example, usage duration can be 10 days, one month, or two months, etc.

[0163] In summary, the method of generating different software authentication license requests by allowing users to customize parameters, and then generating different smart contracts based on these requests, not only improves the flexibility of smart contract generation but also better meets users' actual needs, thus enhancing the user experience.

[0164] Furthermore, in another embodiment, the type of software to be activated is one, and the authorization activation of the software based on the target virtual asset may include:

[0165] Send a software activation request to the blockchain, wherein the software activation request contains a first number of software to be activated.

[0166] The blockchain determines a first virtual asset to be used based on the first quantity and the virtual assets corresponding to a single pre-stored software to be activated. If the target virtual asset is not less than the first virtual asset to be used, the first quantity of software is activated for the client.

[0167] Furthermore, after activating the first number of software applications for the client, the process may also include:

[0168] The system receives a virtual asset shortage warning from the blockchain, wherein the virtual asset shortage warning is generated by the blockchain when the target virtual asset is updated based on the first virtual asset to be used and the updated target virtual asset is less than a preset virtual asset threshold.

[0169] In addition, after receiving a notification from the blockchain indicating insufficient virtual assets, the following may also be included:

[0170] A recharge request is sent to the blockchain, wherein the recharge request contains virtual assets to be recharged, so that the blockchain allocates the virtual assets to be recharged to the client according to the recharge request.

[0171] In another embodiment, the type of software to be activated can be multiple, and the client can authorize and activate the software through the target virtual asset, which may include:

[0172] A software activation request is sent to the blockchain, wherein the software activation request includes the type of software to be activated and a second quantity corresponding to each type of software to be activated, so that the blockchain can determine whether different types of software to be activated can authorize the client simultaneously based on the client's permission information. If the different types of software to be activated can authorize the client simultaneously, then a second virtual asset to be used is determined based on the quantity of each type of software to be activated in the software activation request and the pre-stored virtual assets corresponding to each type of software to be activated. If the target virtual asset is not less than the second virtual asset to be used, then the second quantity of software of different types is activated for the client.

[0173] In another embodiment, after the software authorization activation via the target virtual asset, the process may further include:

[0174] In response to a touch operation applied to the query control, a query request is generated and sent to the blockchain, so that the blockchain can determine the software status information corresponding to the client through the query request. The software status information includes the virtual assets currently owned by the client, as well as the usage duration and expiration time of the activated software.

[0175] Receive and display the software status information sent by the blockchain.

[0176] In summary, using blockchain to implement the entire software licensing and authentication process achieves decentralization. As long as any node exists, the software licensing and authentication process will not be in an abnormal state. Furthermore, the authentication service provider only needs to deposit the corresponding amount of virtual assets into the user's corresponding public key address after the user's smart contract is initially generated, simplifying the software licensing and authentication process. In addition, using touch-sensitive controls to query software status information allows users to intuitively understand the software's usage, improving the user experience.

[0177] Based on the same idea, this specification also provides an apparatus corresponding to the above method. Figure 7 This is a schematic diagram of the structure of a software authentication and licensing processing device provided in an embodiment of this application, applied to blockchain, such as... Figure 7 As shown, the apparatus provided in this embodiment may include:

[0178] The receiving module 701 is used to receive a software authentication license request sent by the client, wherein the software authentication license request is generated by the client in response to an input operation performed on the authentication license selection interface.

[0179] The first processing module 702 is used to generate a smart contract based on the software authentication license request.

[0180] The first processing module 702 is further configured to determine, through the smart contract, a target virtual asset corresponding to the client in the blockchain, and allocate the target virtual asset to the client so that the client can authorize and activate the software through the target virtual asset.

[0181] In this embodiment, the first processing module 702 is further configured to:

[0182] The target virtual asset corresponding to the client is determined in the blockchain by the software type, purchase quantity, and usage duration contained in the smart contract.

[0183] In another embodiment, the type of software to be activated is one, and the first processing module 702 is further configured to:

[0184] Receive a software activation request sent by the client, wherein the software activation request contains a first number of software to be activated.

[0185] The first virtual asset to be used is determined based on the first quantity and the virtual assets corresponding to a single pre-stored software to be activated.

[0186] If the target virtual asset is no less than the first virtual asset to be used, then the first number of software will be activated for the client.

[0187] In addition, the first processing module 702 is also used for:

[0188] The target virtual asset is updated based on the first virtual asset to be used.

[0189] If the updated target virtual assets are less than the preset virtual asset threshold, a virtual asset shortage warning will be sent to the client.

[0190] In addition, the first processing module 702 is also used for:

[0191] Receive a recharge request sent by the client, wherein the recharge request contains virtual assets to be recharged.

[0192] The virtual assets to be recharged are allocated to the client according to the recharge request.

[0193] In another embodiment, the type of software to be activated can be multiple, and the first processing module 702 is further configured to:

[0194] The system receives a software activation request sent by the client, wherein the software activation request includes the type of software to be activated and a second quantity of each type of software to be activated.

[0195] Based on the client's permission information, determine whether different types of software to be activated can simultaneously authorize the client.

[0196] If the different types of software to be activated can simultaneously authorize the client, then the second virtual asset to be used is determined based on the number of each type of software to be activated in the software activation request and the virtual assets corresponding to each type of software to be activated that are pre-stored.

[0197] If the target virtual asset is no less than the second virtual asset to be used, then activate a second number of software of different types for the client.

[0198] In another embodiment, the software authentication license request includes a client public key, and the first processing module 702 is further configured to:

[0199] Determine whether the client's public key corresponds to the blockchain's private key.

[0200] If the client's public key corresponds to the private key of the blockchain, a smart contract is generated based on the software authentication license request.

[0201] In another embodiment, the first processing module 702 is further configured to:

[0202] Receive the query request sent by the client.

[0203] The query request determines the software status information corresponding to the client, wherein the software status information includes the virtual assets currently owned by the client, as well as the usage duration and expiration time of the activated software.

[0204] The software status information is sent to the client.

[0205] Figure 8 This is a schematic diagram of the structure of a software authentication and licensing processing device provided in another embodiment of this application, applied to a client, such as... Figure 8 As shown, the apparatus provided in this embodiment may include:

[0206] The response module 801 is used to respond to input operations performed on the authentication and license selection interface and to determine the software authentication and license request.

[0207] In this embodiment, the response module 801 is further configured to:

[0208] In response to an input operation applied to the target parameters in the authentication and licensing selection interface, a software authentication and licensing request is determined, wherein the target parameters include at least one of the following: number of software programs, software type, and usage duration.

[0209] The second processing module 802 is used to upload the software authentication license request to the blockchain, so that the blockchain generates a smart contract according to the software authentication license request, and through the smart contract, determines the target virtual asset corresponding to the client in the blockchain, and allocates the target virtual asset to the client.

[0210] The second processing module 802 is also used to authorize and activate the software based on the target virtual asset.

[0211] Furthermore, in another embodiment, the type of software to be activated is one, and the second processing module 802 is further configured to:

[0212] Send a software activation request to the blockchain, wherein the software activation request contains a first number of software to be activated.

[0213] The blockchain determines a first virtual asset to be used based on the first quantity and the virtual assets corresponding to a single pre-stored software to be activated. If the target virtual asset is not less than the first virtual asset to be used, the first quantity of software is activated for the client.

[0214] In addition, the second processing module 802 is also used for:

[0215] The system receives a virtual asset shortage warning from the blockchain, wherein the virtual asset shortage warning is generated by the blockchain when the target virtual asset is updated based on the first virtual asset to be used and the updated target virtual asset is less than a preset virtual asset threshold.

[0216] In addition, the second processing module 802 is also used for:

[0217] A recharge request is sent to the blockchain, wherein the recharge request contains virtual assets to be recharged, so that the blockchain allocates the virtual assets to be recharged to the client according to the recharge request.

[0218] In another embodiment, the type of software to be activated is multiple, and the second processing module 802 is further configured to:

[0219] A software activation request is sent to the blockchain, wherein the software activation request includes the type of software to be activated and a second quantity corresponding to each type of software to be activated, so that the blockchain can determine whether different types of software to be activated can authorize the client simultaneously based on the client's permission information. If the different types of software to be activated can authorize the client simultaneously, then a second virtual asset to be used is determined based on the quantity of each type of software to be activated in the software activation request and the pre-stored virtual assets corresponding to each type of software to be activated. If the target virtual asset is not less than the second virtual asset to be used, then the second quantity of software of different types is activated for the client.

[0220] In another embodiment, the second processing module 802 is further configured to:

[0221] In response to a touch operation applied to the query control, a query request is generated and sent to the blockchain, so that the blockchain can determine the software status information corresponding to the client through the query request. The software status information includes the virtual assets currently owned by the client, as well as the usage duration and expiration time of the activated software.

[0222] Receive and display the software status information sent by the blockchain.

[0223] In summary, using blockchain to implement the entire software licensing and authentication process achieves decentralization. As long as any node exists, the software licensing and authentication process will not be in an abnormal state. Furthermore, the authentication service provider only needs to deposit the corresponding amount of virtual assets into the user's public key address after the user's smart contract is first generated, which simplifies the software licensing and authentication process.

[0224] The apparatus provided in this application embodiment can achieve the above-mentioned... Figure 3 The methods in the embodiments shown are similar in principle and technical effect, and will not be described again here.

[0225] Figure 9 A schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application, such as... Figure 9 As shown, the device 900 provided in this embodiment includes a processor 901 and a memory communicatively connected to the processor. The processor 901 and the memory 902 are connected via a bus 903.

[0226] In the specific implementation process, the processor 901 executes the computer execution instructions stored in the memory 902, causing the processor 901 to execute the method in the above method embodiment.

[0227] The specific implementation process of processor 901 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0228] In the above Figure 9 In the illustrated embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0229] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage.

[0230] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0231] This application also provides a computer-readable storage medium storing computer-executable instructions. When a processor executes the computer-executable instructions, it implements the software authentication and licensing processing method described in the above method embodiments.

[0232] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements the software authentication and licensing processing method described above.

[0233] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0234] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0235] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0236] Finally, it should be noted that the above 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 or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A software authentication and licensing processing method, characterized in that, Applications in blockchain, including: The system receives a software authentication license request sent by a client, wherein the software authentication license request is generated by the client in response to an input operation on the authentication license selection interface, the authentication license selection interface provides a combination of software type, purchase quantity and usage duration selection, and the software authentication license request contains the client's public key; Determine whether the client's public key corresponds to the blockchain's private key. If they correspond, generate a smart contract based on the software authentication license request. The smart contract contains authorization rules determined based on the combined selection, and the smart contract is generated only for the client and is uniquely corresponding to it. Based on the software type, purchase quantity, and usage duration contained in the smart contract, a target virtual asset corresponding to the client is determined in the blockchain, and the target virtual asset is allocated to the client through the client's public key address, so that the client can authorize and activate the software through the target virtual asset.

2. The method according to claim 1, characterized in that, The type of software to be activated is one, and the step of enabling the client to authorize and activate the software through the target virtual asset includes: Receive a software activation request sent by the client, wherein the software activation request contains a first number of software to be activated; The first virtual asset to be used is determined based on the first quantity and the virtual assets corresponding to a single pre-stored software to be activated. If the target virtual asset is no less than the first virtual asset to be used, then the first number of software will be activated for the client.

3. The method according to claim 2, characterized in that, After activating the first number of software applications for the client, the process further includes: Update the target virtual asset based on the first virtual asset to be used; If the updated target virtual assets are less than the preset virtual asset threshold, a virtual asset shortage warning will be sent to the client.

4. The method according to claim 3, characterized in that, After sending the virtual asset shortage warning to the client, the method further includes: Receive a recharge request sent by the client, wherein the recharge request contains virtual assets to be recharged; The virtual assets to be recharged are allocated to the client according to the recharge request.

5. The method according to claim 1, characterized in that, The types of software to be activated are varied, and the process of enabling the client to authorize and activate the software through the target virtual asset includes: Receive a software activation request sent by the client, wherein the software activation request includes the type of software to be activated and a second quantity of each type of software to be activated; Based on the client's permission information, determine whether different types of software to be activated can simultaneously authorize the client; If the different types of software to be activated can authorize the client at the same time, then the second virtual asset to be used is determined according to the number of each type of software to be activated in the software activation request and the virtual assets corresponding to each type of software to be activated that are stored in advance. If the target virtual asset is no less than the second virtual asset to be used, then activate a second number of software of different types for the client.

6. The method according to any one of claims 1-5, characterized in that, After enabling the client to authorize and activate the software through the target virtual asset, the method further includes: Receive the query request sent by the client; The software status information corresponding to the client is determined through the query request, wherein the software status information includes the virtual assets currently owned by the client, as well as the usage duration and expiration time of the activated software; The software status information is sent to the client.

7. A software authentication and licensing processing method, characterized in that, Applied to the client side, including: In response to an input operation applied to the authentication and license selection interface, a software authentication and license request is determined. The authentication and license selection interface provides a combination of software type, quantity purchased, and usage duration selection. The software authentication and license request includes the client's public key. The software authentication license request is uploaded to the blockchain so that the blockchain can determine whether the client's public key corresponds to the blockchain's private key. If they correspond, a smart contract is generated based on the software authentication license request. The target virtual asset corresponding to the client is determined in the blockchain using the software type, purchase quantity, and usage duration contained in the smart contract. The target virtual asset is then allocated to the client using the client's public key address. The smart contract contains authorization rules determined based on the combined selection, and the smart contract is generated only for the client and is uniquely corresponding to it. The software is authorized and activated based on the target virtual asset.

8. The method according to claim 7, characterized in that, The response is applied to the input operation of the authentication and license selection interface to determine the software authentication and license request, including: In response to an input operation applied to the target parameters in the authentication and licensing selection interface, a software authentication and licensing request is determined, wherein the target parameters include at least one of the following: number of software programs, software type, and usage duration.

9. The method according to claim 7 or 8, characterized in that, After the software is licensed and activated based on the target virtual asset, the method further includes: In response to a touch operation applied to the query control, a query request is generated and sent to the blockchain, so that the blockchain can determine the software status information corresponding to the client through the query request. The software status information includes the virtual assets currently owned by the client, as well as the usage time and expiration time of the activated software. Receive and display the software status information sent by the blockchain.

10. A software authentication and licensing processing system, characterized in that, Including clients and blockchain, The client is used to respond to input operations on the authentication and license selection interface, determine the software authentication and license request, and send the software authentication and license request to the blockchain. The authentication and license selection interface provides a combination of software type, purchase quantity, and usage duration selection. The software authentication and license request contains the client's public key. The blockchain is used to receive software authentication and license requests sent by the client, and to determine whether the client's public key corresponds to the blockchain's private key. If they correspond, a smart contract is generated based on the software authentication and license request. Then, based on the software type, purchase quantity, and usage duration contained in the smart contract, a target virtual asset corresponding to the client is determined in the blockchain, and the target virtual asset is allocated to the client using the client's public key address. The smart contract contains authorization rules determined based on the combined selection, and the smart contract is generated only for the client and is uniquely corresponding to it. The client is also used to authorize and activate the software through the target virtual asset.

11. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the software authentication and licensing processing method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, implement the software authentication and licensing processing method as described in any one of claims 1 to 9.

Images