Software deployment management method and device, computer device, and storage medium

Abstract

Embodiments of the present application provide a software deployment management method and device, computer equipment and a storage medium, wherein the method comprises: sending a management authorization request to a second device to request the second device to authorize a first device to use a management service to manage distributed deployment of a software tool package; wherein the management authorization request is generated according to hardware information of the first device; receiving authorization credential information returned by the second device, the authorization credential information being generated by the second device after verifying that the first device has the qualification to use the management service according to the management authorization request; initializing the management service based on the authorization credential information, and after successfully initializing the management service, in response to a registration request sent by any node device that intends to use the software tool package, calling the management service to manage deployment of the software tool package for the corresponding node device; the efficiency of deployment management for the software tool package can be improved, and the delivery cost can be reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a software deployment management method, apparatus, computer equipment, and storage medium. Background Technology

[0002] Software licensing management refers to protective measures taken to prevent software from being used by devices without the software provider's permission. Currently, software products in the form of Software Development Kits (SDKs) are often integrated into multiple customer business services, and these different services can be deployed on different devices. Therefore, a single SDK needs to be deployed on multiple devices. In this scenario, current SDK deployment management solutions often require the software provider to collect hardware information from all devices beforehand to achieve distributed SDK deployment management. This approach is inefficient and costly. Summary of the Invention

[0003] This application provides a software deployment management method, apparatus, computer equipment, and storage medium, which can improve the efficiency of deployment management for software toolkits and reduce delivery costs.

[0004] On one hand, embodiments of this application provide a software deployment management method, wherein the method is executed by a first device, which refers to a device that has a built-in management service for a software toolkit and intends to use the management service to manage the distributed deployment of the software toolkit; wherein, the device used by the software provider of the software toolkit is a second device; the method includes:

[0005] A management authorization request is sent to the second device to request the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit; wherein the management authorization request is generated based on the hardware information of the first device;

[0006] The system receives authorization credential information returned by the second device, which is generated after the second device verifies that the first device is qualified to use the management service based on the management authorization request.

[0007] The management service is initialized based on the authorization credential information. After successful initialization of the management service, in response to a registration request sent by any node device that wishes to use the software toolkit, the management service is invoked to deploy and manage the software toolkit on the corresponding node device.

[0008] On one hand, embodiments of this application provide a software deployment management method, wherein the method is executed by a second device, the second device referring to a device used by the software provider of a software toolkit; the method includes:

[0009] The system receives a management authorization request from a first device, which is a device that has a built-in management service for the software toolkit and wants to use the management service to manage the distributed deployment of the software toolkit. The management authorization request is generated based on the hardware information of the first device. The management authorization request requests the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit.

[0010] Based on the management authorization request, verify the first device's eligibility to use the management service; and after verifying that the first device is qualified to use the management service, generate authorization credential information;

[0011] The authorization credential information is returned to the first device, enabling the first device to initialize the management service based on the authorization credential information. After successfully initializing the management service, in response to a registration request sent by any node device that wishes to use the software toolkit, the first device invokes the management service to deploy and manage the software toolkit on the corresponding node device.

[0012] On one hand, embodiments of this application provide a software deployment management device, which operates in a first device. The first device refers to a device with a built-in management service for a software toolkit, and which intends to use the management service to manage the distributed deployment of the software toolkit. The device used by the software provider of the software toolkit is a second device. The device includes:

[0013] A sending unit is configured to send a management authorization request to the second device, requesting the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit; wherein the management authorization request is generated based on the hardware information of the first device;

[0014] The receiving unit is configured to receive authorization credential information returned by the second device, wherein the authorization credential information is generated after the second device verifies that the first device is qualified to use the management service according to the management authorization request;

[0015] The management unit is used to initialize the management service based on the authorization credential information, and after successfully initializing the management service, in response to a registration request sent by any node device that wants to use the software toolkit, call the management service to perform deployment management of the software toolkit on the corresponding node device.

[0016] On one hand, embodiments of this application provide a software deployment management device, which operates in a second device, wherein the second device refers to a device used by the software provider of a software toolkit; the device includes:

[0017] A receiving unit is configured to receive a management authorization request sent by a first device, wherein the first device refers to a device that has a built-in management service for the software toolkit and intends to use the management service to manage the distributed deployment of the software toolkit; wherein the management authorization request is generated based on the hardware information of the first device; the management authorization request is used to request that the second device authorize the first device to use the management service to manage the distributed deployment of the software toolkit;

[0018] The generation unit is configured to verify the first device's eligibility to use the management service based on the management authorization request; and generate authorization credential information after verifying that the first device is qualified to use the management service.

[0019] The return unit is used to return the authorization credential information to the first device, so that the first device initializes the management service based on the authorization credential information, and after successfully initializing the management service, responds to the registration request sent by any node device that wants to use the software toolkit, and calls the management service to perform deployment management of the software toolkit on the corresponding node device.

[0020] On one hand, embodiments of this application provide a computer device, the computer device including an input interface and an output interface, and the computer device further includes:

[0021] A processor, adapted to implement one or more instructions; and,

[0022] A computer storage medium storing one or more instructions adapted for loading by the processor and executing the following steps on the first device side:

[0023] A management authorization request is sent to the second device to request the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit; wherein the management authorization request is generated based on the hardware information of the first device;

[0024] The system receives authorization credential information returned by the second device, which is generated after the second device verifies that the first device is qualified to use the management service based on the management authorization request.

[0025] The management service is initialized based on the authorization credential information. After successful initialization of the management service, in response to a registration request sent by any node device that wishes to use the software toolkit, the management service is invoked to deploy and manage the software toolkit on the corresponding node device.

[0026] The one or more instructions are also adapted to be loaded by the processor and executed on the second device side as follows:

[0027] The system receives a management authorization request from a first device, which is a device that has a built-in management service for the software toolkit and wants to use the management service to manage the distributed deployment of the software toolkit. The management authorization request is generated based on the hardware information of the first device. The management authorization request requests the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit.

[0028] Based on the management authorization request, verify the first device's eligibility to use the management service; and after verifying that the first device is qualified to use the management service, generate authorization credential information;

[0029] The authorization credential information is returned to the first device, enabling the first device to initialize the management service based on the authorization credential information. After successfully initializing the management service, in response to a registration request sent by any node device that wishes to use the software toolkit, the first device invokes the management service to deploy and manage the software toolkit on the corresponding node device.

[0030] On one hand, embodiments of this application provide a computer storage medium storing one or more instructions, which are adapted to be loaded and executed by the processor using the software deployment management method on the first device side or the software deployment management method on the second device side.

[0031] On one hand, embodiments of this application provide a computer storage medium storing one or more first instructions, which are adapted to be loaded and executed by a processor using the software deployment management method on the first device side or the software deployment management method on the second device side.

[0032] On one hand, embodiments of this application provide a computer program product, which includes one or more instructions stored in a computer storage medium, and the processor of the computer device executes the software deployment management method on the first device side or the software deployment management method on the second device side by calling the one or more instructions.

[0033] In this embodiment, the computer device can send a management authorization request to the second device to request the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit; wherein, the management authorization request is generated based on the hardware information of the first device; it can also receive authorization credential information returned by the second device, which is generated after the second device verifies that the first device is qualified to use the management service according to the management authorization request; furthermore, it can initialize the management service based on the authorization credential information, and after successfully initializing the management service, it can respond to the registration request sent by any node device that wants to use the software toolkit and call the management service to manage the deployment of the software toolkit on the corresponding node device. By employing the above method, only the hardware information of the devices running the management service needs to be collected, without needing to collect the hardware information of all node devices where the software toolkit needs to be deployed. This enables distributed deployment management of the software toolkit, allowing dynamic authorization for deployment across multiple node devices. Furthermore, after the software provider authorizes a device with the management service deployed, real-time dynamic authorization of the node device using the software toolkit can be achieved through interaction and collaboration between the authorized management service device and the node device that wants to use the software toolkit. This effectively overcomes the inefficiency and high delivery cost of collecting hardware information from all node devices, thereby significantly improving the efficiency of software toolkit deployment management, increasing node device authorization efficiency, and reducing delivery costs associated with hardware information. Attached Figure Description

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

[0035] Figure 1a This is a schematic diagram of the architecture of a software deployment and management system provided in an embodiment of this application;

[0036] Figure 1b This is a schematic diagram of the architecture of a software deployment and management system provided in an embodiment of this application;

[0037] Figure 2 This is a flowchart illustrating a software deployment management method provided in an embodiment of this application;

[0038] Figure 3 This is a flowchart illustrating a software deployment management method provided in an embodiment of this application;

[0039] Figure 4aThis is a schematic diagram of a process for generating an administrative authorization request, provided in an embodiment of this application;

[0040] Figure 4b This is a schematic diagram of a process for generating an authorization string provided in an embodiment of this application;

[0041] Figure 4c This is a schematic diagram of a process for initializing and verifying a management service, provided in an embodiment of this application.

[0042] Figure 4d This is a schematic diagram of a process for authorizing a node device according to an embodiment of this application;

[0043] Figure 5 This is a schematic diagram of the structure of a software deployment management device provided in an embodiment of this application;

[0044] Figure 6 This is a schematic diagram of the structure of a software deployment management device provided in an embodiment of this application;

[0045] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0046] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0047] In the embodiments of this application, the software toolkit mentioned below can be any software development kit (SDK). For example, it can be an SDK with cryptographic capabilities (such as encryption, decryption, and signature verification capabilities), an SDK with reconciliation capabilities, or an SDK with message sending and receiving functions. Furthermore, a software toolkit can be understood as the underlying technical capabilities upon which business services rely. A software toolkit can be integrated by one or more business services. For example, a software toolkit with cryptographic capabilities can be integrated by business services such as payment services, login services, and messaging services; similarly, a software toolkit with reconciliation capabilities can be integrated by business services such as payment services.

[0048] When a software toolkit needs to be integrated into multiple business services, and these business services are distributed across multiple devices, the software toolkit needs to be deployed in a distributed manner across the various devices where these business services reside. For example, when a software toolkit with cryptographic capabilities needs to be integrated into three business services—payment service, login service, and messaging service—if these three business services are distributed across different devices, then this software toolkit with cryptographic capabilities needs to be deployed in a distributed manner across all three devices.

[0049] To better manage the distributed deployment of software toolkits, this application proposes a software deployment management system, see [link to relevant documentation]. Figure 1a As shown, the software deployment management system may include at least a first device (or management device) and one or more node devices (or software SDK nodes). The first device here refers to a device with a built-in management service for the software toolkit, which is intended to manage the distributed deployment of the software toolkit. This management service is provided by the software provider to the target object, which then deploys it on the first device. The target object can be any enterprise or individual that obtains the software toolkit from the software provider using electronic resources. Any node device refers to a device that has a need to use the software toolkit; specifically, it can be a device that already has the qualification to use the software toolkit or a device that does not, without limitation.

[0050] In specific application scenarios, both the primary device and each node device can be deployed in a private environment; that is, each node device can be a privately distributed deployment. The private environment can refer to the network environment specified by the object (such as the target object in this application). This specified network environment can be a data center maintained by the object itself, host and network resources obtained by the object using electronic resources on a public cloud, or a private cloud environment. A public cloud typically refers to a cloud provided by a third-party provider that the object can use; a private cloud creates cloud infrastructure and hardware / software resources within a firewall, allowing various departments within an organization or enterprise to share resources within the data center. Simply put, a private environment is an isolated and dedicated network environment that cannot normally access public networks (also known as the public network, external network, or the Internet).

[0051] In another specific application scenario, the first device and each node device can also be deployed in a public environment, which can refer to an open network environment, that is, a network environment that can be accessed by any object.

[0052] Furthermore, the software deployment management system may also include a second device, which refers to the device used by the software provider of the software toolkit; in this case, the system architecture of the software management deployment system can participate in... Figure 1b As shown. In one embodiment, the first device can request authorization from the second device to use the management service to manage the distributed deployment of the software toolkit. After successful management authorization, the first device can receive a registration request from any node device that wants to use the software toolkit, and can respond to the registration request to call the management service to manage the deployment of the software toolkit on the node device, thereby enabling the node device to be qualified to use the software toolkit.

[0053] The devices mentioned above (such as the first device, the second device, and the node device) can be servers. These servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, etc.

[0054] Based on the aforementioned software deployment management system, this application provides a software deployment management scheme. In specific implementation, this software deployment management scheme can be executed by a first device. The general principle of the software deployment management scheme is as follows: The software deployment management scheme can be divided into two stages: the first stage is the offline authorization stage of the management service by the software provider, and the second stage is the real-time authorization stage of the management service for node devices that want to use the software toolkit. In the first stage, the second device used by the software provider collects the hardware information corresponding to the first device that needs to deploy the management service, and issues authorization credentials based on the collected hardware information. The first device can initialize the management service based on the authorization credentials. After successfully initializing the management service, the first device can call the management service to deploy and manage the software toolkit on the node devices. In the second stage, the node devices that want to use the software toolkit can initiate a real-time registration request to the first device, thereby enabling the first device to call the management service to deploy and manage the software toolkit on the node devices.

[0055] Therefore, in the software deployment management scheme proposed in this application embodiment, the software provider only needs to authorize one device to use the management service to manage the distributed deployment of the software toolkit. This single device can then dynamically authorize various node devices that wish to use the software toolkit. It is evident that the software provider only needs to collect the hardware information of the device running the management service—that is, only the hardware information of one device—without collecting the hardware information of all node devices where the software toolkit needs to be deployed. This enables distributed deployment management of the software toolkit, allowing dynamic authorization for deployment of the software toolkit across multiple node devices. Furthermore, after the software provider authorizes one device with the management service, real-time dynamic authorization of the node devices using the software toolkit can be achieved through interaction and collaboration between the authorized management service device and the node devices that wish to use the software toolkit. This effectively overcomes the inefficiency and high delivery cost of collecting hardware information from all node devices, thereby significantly improving the efficiency of software toolkit deployment management, increasing node device authorization efficiency, and reducing delivery costs associated with hardware information.

[0056] As mentioned earlier, the first device authorized with management services and each node device using the software toolkit can be deployed in a private environment. Since the authorization of the privately distributed node devices is achieved through the first device authorized with management services, there is no need to initiate an authorization request to the second device used by the software provider of the software toolkit. Therefore, the software deployment management solution can be applied to the authorization management of software toolkits in privately distributed deployment scenarios. That is, the software deployment management solution can also overcome the technical difficulties of online authorization caused by the inability to access the public network in a private environment. For example, when the target is an enterprise, the enterprise often requires the software toolkit to be deployed privately. The business services corresponding to the privately deployed software toolkit are often located in a dedicated network that cannot be connected to the public network. Because the public network cannot be accessed, it is impossible to initiate an authorization request to the second device used by the software provider of the software toolkit, thus making online authorization impossible. The software deployment management solution proposed in this application can effectively solve this problem.

[0057] Based on the above descriptions of the software deployment management system and software deployment management scheme, this application proposes a software deployment management method. Please refer to... Figure 2 The software deployment and management method may include the following steps S201-S205:

[0058] S201, the first device sends a management authorization request to the second device.

[0059] In this context, the first device can refer to a device with a built-in management service for the software toolkit, which intends to use the management service to manage the distributed deployment of the software toolkit. Therefore, when the first device sends a management authorization request to the second device, it is requesting authorization from the second device to use the management service to manage the distributed deployment of the software toolkit. In a specific implementation, when a target object has a need to use the management service to manage the distributed deployment of the software toolkit, the target object can send a management authorization request from the first device to the second device, requesting the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit.

[0060] The management authorization request may carry an authorization request string for the management service; the authorization request string may be generated based on the hardware information of the first device, which may include a device identifier for uniquely identifying the first device, for example, the device identifier may be a universally unique identifier (UUID).

[0061] In one embodiment, the authorization request string may include, in addition to the hardware information of the first device, data information negotiated between the software provider and the target object. This data information may include at least one of the following: the object identifier of the target object, and the deployment quantity of the software development kit (SDK). This deployment quantity can be used to indicate that the target object plans to deploy the SSDK on K node devices, where K is a positive integer. For example, the deployment quantity can be 15, meaning the target object plans to deploy the SSDK on 15 node devices.

[0062] It should be noted that in this application, the relevant description is based on the example of data information including the object identifier of the target object and the number of software development kits deployed.

[0063] S202, the second device verifies the first device's eligibility to use the management service based on the management authorization request; and after verifying that the first device is qualified to use the management service, it generates authorization credential information.

[0064] Understandably, the second device can receive the management authorization request sent by the first device, and once the second device receives the management authorization request, it can execute step S202.

[0065] In a specific implementation, since the authorization request string carried by the management authorization request contains data information and the hardware information of the first device, the second device can parse the authorization request string to obtain the data information and match the parsed data information with the data information negotiated between the software provider and the target object to determine whether the first device is qualified to use the management service. In one embodiment, if the parsed data information matches the data information negotiated between the software provider and the target object, it can be determined that the first device is qualified to use the management service; if the parsed data information does not match the data information negotiated between the software provider and the target object, it can be determined that the first device is not qualified to use the management service.

[0066] Specifically, the parsed data information is matched with the data information agreed upon between the software provider and the target object. In other words, it is determined whether the parsed data information is the same as the data information agreed upon between the software provider and the target object. If they are the same, it can be determined that the parsed data information matches the data information agreed upon between the software provider and the target object. If they are different, it can be determined that the parsed data information does not match the data information agreed upon between the software provider and the target object.

[0067] In a specific implementation, after the second device verifies that the first device is qualified to use the management service, it can generate authorization credential information so that the first device can subsequently initialize the management service of the software toolkit based on the authorization credential information. This authorization credential information can also be understood as an authorization certificate. The second device can issue the authorization credential information based on the data information contained in the authorization request string and the hardware information of the first device. This authorization credential information can be obtained by signing the data information and the hardware information of the first device.

[0068] S203, the second device returns the authorization credential information to the first device.

[0069] S204, The first device initializes the management service based on the authorization credential information.

[0070] In a specific implementation, the first device can initialize the management service based on the authorization credential information to complete the authorization verification of the management service. Specifically, when the first device needs to initialize the management service based on the authorization credential information, it can import the authorization credential information into the management service so that the management service can perform runtime environment initialization verification on the first device. If the first device passes the runtime environment initialization verification, it can be determined that the initialization of the management service is successful; otherwise, if the first device fails the runtime environment initialization verification, it can be determined that the initialization of the management service has failed.

[0071] As mentioned earlier, since the authorization credential information is obtained through signature processing, signature verification can be performed on this authorization credential information to verify its legitimacy. If the authorization credential information passes signature verification, the runtime environment of the management service can be further initialized and verified. Only when both the authorization credential information and the first device pass the runtime environment initialization verification are the initialization of the management service considered successful.

[0072] As mentioned above, the authorization certificate information carries the hardware information of the first device. For ease of description, the hardware information of the first device carried in the authorization certificate information can be used as the reference hardware information of the first device. Furthermore, the current hardware information of the first device can be obtained to perform initialization verification of the management service's operating environment based on the reference hardware information and the current hardware information of the first device. Specifically, initializing the management service's operating environment involves determining whether the reference hardware information and the current hardware information of the first device are consistent. If they are consistent, the first device passes the initialization verification of the operating environment; if they are inconsistent, the first device fails the initialization verification.

[0073] S205, after successfully initializing the management service, the first device responds to the registration request sent by any node device that wants to use the software toolkit, and calls the management service to deploy and manage the software toolkit for the corresponding node device.

[0074] In a specific implementation, after successfully initializing the management service, the real-time authorization process for node devices wishing to use the software toolkit can be executed. During this process, any node device wishing to use the software toolkit can deploy the toolkit and complete real-time authorization registration, thereby granting the node device permission to use the software toolkit. To complete the real-time authorization registration, firstly, any node device wishing to use the software toolkit can send a registration request to a first device. The first device can respond to the registration request sent by any node device wishing to use the software toolkit and invoke the management service to manage the deployment of the software toolkit for the node device wishing to use it, thereby achieving real-time authorization.

[0075] In this embodiment, the software provider of the software toolkit only needs to authorize one device to use the management service to manage the distributed deployment of the software toolkit. This single device can then dynamically authorize various node devices that wish to use the software toolkit. Therefore, the software provider only needs to collect the hardware information of the device running the management service—that is, only the hardware information of one device—and does not need to collect the hardware information of all node devices where the software toolkit needs to be deployed. This allows for dynamic authorization of software toolkit deployment on multiple node devices. Furthermore, after the software provider authorizes one device with the management service, real-time dynamic authorization of the node devices using the software toolkit can be achieved through the interaction and collaboration between the authorized management service device and the node devices that wish to use the software toolkit. This effectively overcomes the inefficiency and high delivery cost of collecting hardware information from all node devices, thereby significantly improving the authorization efficiency of node devices and reducing the delivery cost of hardware information.

[0076] Based on the description of the above method embodiments, this application also proposes a software deployment management method. Please refer to... Figure 3 The software deployment and management method may include the following steps S301-S309:

[0077] S301, the first device sends a management authorization request to the second device.

[0078] The management authorization request may include an authorization request string for the management service.

[0079] In a specific implementation, the management authorization request can be generated by a target tool provided by the software provider. This target tool is a tool capable of generating an authorization request string for the management service; it can be a command-line tool, a graphical interface tool, or other types of tools, without limitation. After generating the authorization request string using the target tool, a management authorization request can be further generated based on this string.

[0080] Based on this, it can be seen that in the specific implementation, the target tool provided by the software provider can be deployed on the first device. After the target tool is successfully deployed on the first device, the first device can call the target tool to collect the hardware information of the first device, and call the target tool to generate a string based on the collected hardware information as the authorization request string for the management service. Furthermore, the first device can generate a management authorization request carrying the authorization request string, that is, the management authorization request carries the authorization request string.

[0081] The hardware information of the first device can be obtained by the target tool through calling the system interface used to acquire hardware information. The hardware information mentioned in this application can be either raw hardware information directly collected by the system interface or processed hardware information (such as ciphertext or hash value of the hardware information). For example, the hardware information of the first device can be a UUID, which can be generated based on the MAC (Media Access Control) address of the first device. Therefore, the target tool can collect the MAC address of the first device by calling the system interface used to collect the MAC address, and after collecting the MAC address, it can determine the UUID based on the MAC address. For example, the MAC address can be directly used as the UUID, or the MAC address can be calculated, and the result can be used as the UUID. This calculation can refer to hash calculation, encryption calculation, or other calculations. For example, in the case of hash calculation, the MAC address can be hashed, and the result can be used as the UUID. It should be noted that there is no limit to the number of hash calculations performed on a MAC address; for example, a hash calculation can be performed once or multiple times. The hash algorithm used is also not limited. The number of hash calculations and the hash algorithm can be set in the target tool.

[0082] Specifically, the target tool may specify the information required to generate the authorization request string and the method for generating the authorization request string based on the collected information. For example, the target tool may specify that the information to be collected includes data information (such as the object identifier of the target object, the number of software development kits deployed) and hardware information of the device deploying the target tool (such as the first device in this application). The method for generating the authorization request string based on the collected information may be by concatenating the collected information, or by encrypting it, etc.

[0083] For example, the target tool is a graphical user interface (GUI) tool, meaning it provides a user interface for relevant personnel to perform operations, thereby generating an authorization request string. See, for example... Figure 4aAs shown: The terminal used by the relevant personnel can display the operation interface corresponding to the target tool on the terminal screen. This operation interface can include at least an information setting area marked by 401 and a confirmation control marked by 402. If the relevant personnel want to have the authority to manage the distributed deployment of the software toolkit on the first device with the built-in management service, the relevant personnel can input relevant data information (such as the object identifier being ID1, the deployment quantity of the software development kit being 15) in the information setting area 401, and then perform a trigger operation (such as a click operation, a press operation, etc.) on the confirmation control 402, thereby triggering the target tool to generate an authorization request string. After the target tool detects that the confirmation control 402 has been triggered, the target tool can further collect the hardware information of the first device to generate an authorization request string based on the collected hardware information and data information. After the target tool generates the authorization request string, it can send the authorization request string to the first device so that the first device can obtain the authorization request string and further generate a management authorization request carrying the authorization request string. The specific implementation method for collecting the hardware information of the first device can be referred to the above description, and will not be repeated here.

[0084] It should be noted that the operation interface corresponding to the target tool described above is merely an example. Another operation interface may include an information setting area that includes settings for data information (such as object identifiers and deployment quantities) and hardware information. In this case, the hardware information of the first device can also be input by relevant personnel, and the method by which relevant personnel obtain the hardware information of the first device is similar to the principle described above. Yet another operation interface may include an information setting area that includes hardware information. In this case, the hardware information of the first device can be input by relevant personnel, while the data information (such as object identifiers and deployment quantities) can be built into the target tool. This data information is the information negotiated between the software provider and the target object. A third operation interface may not include an information setting area, but only a confirmation control for triggering the generation of an authorization request string. In this case, the data information (such as object identifiers and deployment quantities) can be built into the target tool. Relevant personnel can trigger the confirmation control so that the target tool can obtain the built-in data information and collect the hardware information of the first device in real time, thereby generating an authorization request string based on the built-in data information and the collected hardware information.

[0085] Based on the above description, in order to generate an authorization request string using the target tool, in one embodiment, the target tool deployed in the first device may include: data information negotiated between the software provider and the target object, and a first key generated by the software provider using the second device. The first key refers to the key used to generate the authorization request string based on the information collected by the target tool; that is, the first key is the key used to encrypt the hardware information and data information of the first device collected by the target tool. This first key can be generated by the software provider and is not disclosed to the target object. The cryptographic algorithm used by the first key is not limited; for example, it can be a symmetric cryptographic algorithm or an asymmetric cryptographic algorithm. For example, the cryptographic algorithm used by the first key can be the SM4-GCM algorithm, where SM4-GCM refers to a block symmetric cryptographic algorithm in GCM mode, and GCM mode refers to authentication mode.

[0086] In summary, before the first device sends a management authorization request to the second device, the target tool can be invoked to generate an authorization request string, thereby generating a management authorization request carrying this authorization request string. Specifically, the aforementioned invocation of the target tool to generate a string based on the collected hardware information as the authorization request string for the management service, or in other words, invocation of the target tool to generate an authorization request string based on the collected hardware information can include either of the following two methods:

[0087] Generation Method 1: First, the first device can call the target tool to concatenate the collected hardware information and data information according to the first concatenation method to obtain the first string; then, the first string can be used as the authorization request string for the management service.

[0088] The first concatenation method indicates the method of concatenating hardware information and data information, or in other words, the order in which they are concatenated. For example, this first concatenation method indicates concatenation according to the order in which hardware information and data information are concatenated; or, for example, it indicates concatenation according to the order in which data information and hardware information are concatenated. As mentioned earlier, the data information may include one or more of object identifiers and deployment quantities. When the data information includes object identifiers and deployment quantities, the first concatenation method indicates the method of concatenating hardware information, object identifiers, and deployment quantities. For example, this first concatenation method indicates concatenation according to the order in which hardware information, object identifiers, and deployment quantities are concatenated; or, for example, it indicates concatenation according to the order in which object identifiers, hardware information, and deployment quantities are concatenated.

[0089] For example, hardware information is represented by UUID, object identification by ID (Identity document), and deployment quantity by K; then the first string obtained by concatenating these three pieces of information can be UUID|ID|K, or K|UUID|ID, or K|ID|UUID; in summary, the first device can combine these three pieces of information in any form to obtain the first string. The symbol "|" in this application can be interpreted as concatenation.

[0090] Generation Method Two: Considering that in Generation Method One, the first string is directly used as the authorization request string for the management service, there is a risk of information leakage during the transmission of the management authorization request between the first and second devices. Therefore, the first string can be encrypted to improve information security. Based on this, the specific implementation of generating the authorization request string for the management service can be as follows: First, the first device can call the target tool to concatenate the collected hardware information and data information according to the first concatenation method to obtain the first string; then, it can call the first key built into the target tool to encrypt the first string to obtain the authorization request string for the management service, which is the result of encrypting the first string.

[0091] For example, if hardware information is represented by UUID, object identifier by ID, deployment quantity by K, and the first key is the encryption key in the SM4-GCM algorithm, then the authorization request string can be represented as SM4-GCM(ID|UUID|K), where SM4-GCM represents encrypting the information within the brackets (i.e., the first string) using the SM4-GCM algorithm.

[0092] S302, the second device verifies the first device's eligibility to use the management service based on the management authorization request; and after verifying that the first device is qualified to use the management service, it generates authorization credential information.

[0093] As mentioned earlier, the management authorization request carries an authorization request string. When the second device verifies the first device's eligibility to use the management service based on the management authorization request, the second device can use this authorization request string to verify the first device's eligibility to use the management service. The verification method for the first device's eligibility to use the management service will vary depending on how the authorization request string is generated.

[0094] In one embodiment, when the authorization request string is generated using the above-described generation method one, the specific implementation of the second device verifying the first device's eligibility to use the management service based on the management authorization request in step S302 can be as described in verification method one below:

[0095] First, the second device can parse the data information from the authorization request string carried in the management authorization request. Then, the second device can match the parsed data information with the data information negotiated between the software provider and the target object. If the parsed data information is the data information negotiated between the software provider and the target object, the second device can determine that the first device is qualified to use the management service. If the parsed data information is not the data information negotiated between the software provider and the target object, the second device can determine that the first device is not qualified to use the management service.

[0096] In another embodiment, when the authorization request string is generated using the above-described generation method two, the specific implementation of the second device verifying the first device's eligibility to use the management service based on the management authorization request in step S302 can be the verification method two described below:

[0097] First, the second device can decrypt the authorization request string carried in the management authorization request to obtain a first string. Then, the second device can parse the data information from the first string. Further, the second device can match the parsed data information with the data information negotiated between the software provider and the target object. If the parsed data information is the data information negotiated between the software provider and the target object, the second device can determine that the first device is qualified to use the management service. However, if the parsed data information is not the data information negotiated between the software provider and the target object, the second device can determine that the first device is not qualified to use the management service.

[0098] In a specific implementation, after the second device verifies that the first device is qualified to use the management service, the second device can generate authorization credential information so that the first device can use the authorization credential information to initialize the management service.

[0099] The authorization credential information can be an authorization string obtained by the second device signing the target string with its private key; the private key can be a private key held only by the software provider, and the target string can be generated by the second device based on the hardware information of the first device and the data information negotiated between the software provider and the target object.

[0100] The following section first explains the process by which the second device generates the target string, and then explains the process by which the second device uses its private key to sign the target string to obtain the authorization string.

[0101] In one embodiment, the process by which the second device generates the target string may include any of the following methods:

[0102] Target string generation method one: The second device can concatenate the hardware information of the first device and the data information negotiated between the software provider and the target object according to the second concatenation method to obtain a second string, which can be used as the target string. The second concatenation method here can be the same as or different from the first concatenation method described above; there is no limitation on this.

[0103] Based on the above method one for generating the target string, it is clear that the hardware and data information in the target string is not protected by any security measures. Considering the potential risk of leakage during the transmission of the authorization credential information and the target string back to the first device by the second device, encryption can be performed on the hardware and data information to improve the confidentiality of the target string. Therefore, the second device can generate the target string using either method two or method three:

[0104] Method Two for Generating the Target String: First, the second device can concatenate the hardware information of the first device and the data information negotiated between the software provider and the target object according to the second concatenation method to obtain the second string. After obtaining the second string, the second device can further encrypt the second string using a second key to obtain the target string, which is the result of encrypting the second string. The second key can be the same as or different from the first key; there is no limitation on this.

[0105] Target string generation method three: As mentioned earlier, the authorization request string is generated based on the hardware and data information of the first device and is generated through encryption. Therefore, the second device can directly use the authorization request string generated by the first device as the target string. For example, if the authorization request string in the example above is SM4-GCM(ID|UUID|K), then the target string can be SM4-GCM(ID|UUID|K).

[0106] In one embodiment, the process by which the second device signs the target string using its private key to obtain the authorization string may include any of the following methods:

[0107] Authorization string generation method 1: The second device can directly use its private key to sign the target string and use the signed result as the authorization string.

[0108] Authorization string generation method two: First, the second device can perform a hash operation on the target string to obtain the corresponding hash result, which can be called the first hash result; then, the second device can use its private key to sign the first hash result to obtain the authorization string, which is the result of signing the first hash result.

[0109] This application does not limit the private key used for signing. For example, the private key can be the private key corresponding to the SM2-SING algorithm (a signature algorithm for public-key cryptography based on elliptic curve cryptography). For instance, assuming the target string can be represented as SM4-GCM(ID|UUID|K), the authorization string can be represented as SM2-SING(SM4-GCM(ID|UUID|N)), where SM2-SING indicates that the information within the parentheses is signed using the SM2 algorithm.

[0110] As mentioned earlier, the authorization credential information can be an authorization string obtained by the second device signing the target string using its private key. It's important to understand that the second device returns the authorization credential information to the first device so that the first device can use it to initialize the management service. To complete the initialization of the management service, the second device also needs to return the original data related to the authorization credential information, which is the aforementioned target string. Therefore, the second device returns both the authorization credential information and the target string to the first device so that the first device can initialize the management service based on these two sets of data.

[0111] In a specific implementation, after the second device receives the management authorization request sent by the first device, the second device can further determine whether it needs to respond to the management authorization request, or in other words, whether it needs to execute step S302. The process by which the second device determines whether to execute step S302 can be described as follows:

[0112] First, the second device can determine the amount of electronic resources actually received by the software provider from the target object. The second device can also determine the number of software toolkits deployed, and the electronic resources required to deploy one software toolkit. The deployment number indicates the target object's plan to deploy the software development kit across K node devices. The electronic resources required to deploy one software toolkit can be understood as the amount of electronic resources the target object must actually transfer to the software provider when deploying the software toolkit on one node device. The amount of electronic resources actually received can be understood as the amount of electronic resources the target object must actually transfer to the software provider when deploying the software development kit across K node devices.

[0113] Then, the second device can determine the total amount of electronic resources that the target object needs to transfer to the software provider based on the deployment quantity and the electronic resources required to deploy a software toolkit. The total amount of electronic resources that the target object needs to transfer to the software provider can be understood as: when the target object deploys a software development kit on K node devices, the amount of electronic resources that the target object theoretically needs to transfer to the software provider. In one embodiment, the product of the deployment quantity and the electronic resources required to deploy a software toolkit can be used as the total amount of electronic resources that the target object needs to transfer to the software provider.

[0114] Finally, it can be determined whether step S302 can be executed based on the actually received amount of electronic resources and the total amount of electronic resources. For example, the actually received amount of electronic resources and the total amount of electronic resources can be compared in size, and whether step S302 can be executed can be determined based on the comparison result. Specifically, if the actually received amount of electronic resources is greater than or equal to the total amount of electronic resources, it indicates that the target object has successfully transferred the amount of electronic resources required to deploy the software development kit on K node devices to the software provider, and thus the step of triggering the execution of step S302 (that is, verifying the qualification of the first device to use the management service according to the management authorization request) can be triggered; if the actually received amount of electronic resources is less than the total amount of electronic resources, it indicates that the target object has not successfully transferred the amount of electronic resources required to deploy the software development kit on K node devices to the software provider, and thus the management authorization request can be refused to respond.

[0115] For example, assume that the deployment quantity is N, the electronic resources required to deploy a software toolkit is P, then the total amount of electronic resources Q1 that the target object needs to transfer to the software provider = P * K; and assume that the actually received amount of electronic resources from the target object by the software provider is Q2; then, if Q2 >= Q1, the execution of step S302 can be triggered; if Q2 < Q1, the management authorization request can be refused to respond.

[0116] To better understand the process of generating an authorization string proposed in this application, the following is further elaborated in combination with Figure 4b the process shown below. This process can be understood as the offline authorization link of the software provider for the management service, specifically the link of authorization issuance. For example, as shown in Figure 4b shown below, this link can include the following steps 1 - step 6:

[0117] Step 1: The first device generates an authorization request string based on the target tool provided by the software provider.

[0118] For example, the authorization request string can be expressed as SM4 - GCM(ID|UUID|K), where SM4 - GCM represents encrypting the information in the parentheses.

[0119] Step 2: The first device sends an authorization request string to the second device to request the second device to issue an authorization.

[0120] Specifically, requesting the second device to issue an authorization can refer to requesting the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit.

[0121] Step 3: The second device decrypts the authorization request string.

[0122] If decryption fails, it indicates that authorization issuance failed, meaning the first device is not qualified to use the management service. If decryption succeeds, step 4 can be executed. It should be noted that if a symmetric cryptographic algorithm (such as the SM4-GCM algorithm) was used to encrypt the data and hardware information to generate the authorization request string in step 1, then the key used for decryption here is the same as the key used for encryption when generating the authorization request string.

[0123] Step 4: The second device verifies the validity of the decrypted object identifier and the number of deployments.

[0124] This step verifies whether the authorized data information (object identifier and deployment quantity) in the authorization string is consistent with the data information actually negotiated between the software provider and the target object. If the decrypted object identifier and deployment quantity match the negotiated information, the validity verification is successful, and the first device is deemed qualified to use the management service, allowing the execution of step 5 below. If the decrypted object identifier and deployment quantity do not match the negotiated information, the validity verification fails, the authorization issuance fails, and the first device is deemed unqualified to use the management service.

[0125] Step 5: The second device signs the authorization request string to obtain the authorization string.

[0126] This step involves signing the ciphertext (i.e., the authorization request string) generated in step 1 using a private key held only by the software provider, thereby obtaining the authorization string; alternatively, a different key than the one used to generate the authorization request string can be used to re-encrypt the data and hardware information obtained in step 3, and sign the ciphertext to obtain the authorization string.

[0127] Step 6: The second device sends the authorization string and authorization request string to the first device so that the target object can complete the deployment of the management service.

[0128] In this process, the second device sends the authorization string and the authorization request string to the first device, which indicates that the authorization has been successfully issued.

[0129] It should be noted that the specific implementation of each step in this process can be found in the relevant descriptions above, and will not be repeated here.

[0130] As described above, the software provider only needs to collect the corresponding hardware information of the environment in which the management service runs (i.e., the device on which the management service runs, such as the first device here) in advance, and issue an authorization string based on the collected hardware information. This authorization string can be used for the subsequent initialization verification of the management service. After successful initialization verification, the first device can call the management service to perform distributed deployment management of the software toolkit. In other words, it can authorize multiple node devices under the target object to deploy the software toolkit. It can be seen that, in order to authorize multiple node devices under the target object, this application only needs to collect the hardware information of the device on which the management service runs, that is, only the hardware information of one device needs to be collected, without collecting the hardware information of all node devices, to authorize multiple node devices under the target object; thus, it can effectively reduce the delivery cost incurred for hardware information and improve authorization efficiency.

[0131] S303, the second device returns the authorization credential information to the first device.

[0132] S304, The first device initializes the management service based on the authorization credential information.

[0133] As described in step S302 above, the second device returns the authorization credential information and the target string to the first device. The first device can then receive the authorization credential information and the target string. After receiving these, the first device can initialize the management service based on the authorization credential information and the target string to complete the authorization verification of the management service. Only after the management service authorization verification is successful is the management service allowed to manage the distributed deployment of the software toolkit, or in other words, the management service has the function of authorizing node devices that wish to use the software toolkit. In a specific implementation, step S304 may include the following steps S1-S2:

[0134] S1, the first device transmits the authorization credential information and the target string to the management service, so that the management service performs initialization verification of the operating environment of the first device based on the target string and the authorization credential information.

[0135] The process of initializing and verifying the operating environment of the first device based on the target string and authorization credential information in step S1 may include the following steps s11-s13:

[0136] s11, the management service verifies the signature of the authorization credential information based on the public key of the second device and the target string.

[0137] As mentioned earlier, the authorization credential information can be an authorization string obtained by the second device signing the target string using its private key. The public key of the second device can be the public key corresponding to the private key used for signing when generating the authorization credential information. This public key can be built into the management service so that it can be directly obtained from the management service when it is needed to sign and verify the authorization credential information. It should be noted that the management service can be represented as an application. This means that an application has a corresponding configuration file, and the public key, authorization credential information, and target string involved here can be configured in this configuration file so that they can be directly obtained from the configuration file when relevant information is needed later.

[0138] It should be noted that the method of signature verification of the authorization credential information (i.e., the authorization string) differs depending on the method used to generate the authorization credential information from the target string. As mentioned earlier, the methods for generating the authorization credential information can include authorization string generation method one and authorization string generation method two in step S302 above.

[0139] In one embodiment, if the authorization credential information is generated using authorization string generation method one, then step s11 can be implemented as follows: First, the authorization credential information can be designed using the public key of the second device to obtain the designing result; then, the designing result and the target string are checked for consistency. If the designing result and the target string pass the consistency check, it can be determined that the authorization credential information has passed signature verification; if the designing result and the target string fail the consistency check, it can be determined that the authorization credential information has failed signature verification.

[0140] The consistency check between the designing result and the target string is to determine whether the designing result and the target string are consistent. If the designing result and the target string are consistent, it can be determined that the designing result and the target string have passed the consistency check. If the designing result and the target string are inconsistent, it can be determined that the designing result and the target string have failed the consistency check.

[0141] In another embodiment, if the authorization credential information is generated using authorization string generation method two, then the implementation process of step s11 can be as follows: First, the authorization credential information can be de-signed using the public key of the second device to obtain a de-signing result; and second, a hash operation can be performed on the target string to obtain a second hash result. This second hash result is the result of the hash operation on the target string, and the hash calculation here uses the same hash algorithm as the hash calculation used during signing. Then, a consistency check can be performed on the de-signing result and the second hash result; if the de-signing result and the second hash result pass the consistency check, it can be determined that the authorization credential information has passed signature verification; if the de-signing result and the second hash result fail the consistency check, it can be determined that the authorization credential information has failed signature verification.

[0142] The principle behind verifying the consistency between the designing result and the second hash result is the same as that for verifying the consistency between the designing result and the target string. In other words, verifying the consistency between the designing result and the second hash result determines whether they are identical. If the designing result and the second hash result are identical, the consistency check is successful; if they are inconsistent, the consistency check fails.

[0143] s12, If the authorization credential information passes the signature verification, the management service determines that the first device has passed the initialization verification of the operating environment.

[0144] In one embodiment, if the authorization credential information passes signature verification, the system interface can first be called to obtain the current hardware information of the first device. The current hardware information of the first device refers to the hardware information obtained at the current moment, which can be the moment the system interface is called to obtain the hardware information. As mentioned earlier, the hardware information can refer to a UUID, which can be generated based on the device's MAC address. Therefore, the system interface can be called to obtain the MAC address of the first device, and the current hardware information of the first device can be determined based on the obtained MAC address. The specific implementation principle of determining the current hardware information of the first device based on the MAC address is the same as the specific implementation principle described above; that is, the MAC address can be used as the current hardware information of the first device, or the result of hashing the MAC address can be used as the current hardware information of the first device. For the specific implementation, please refer to the relevant description of the specific implementation of determining the hardware information of the first device based on the MAC address above, which will not be repeated here.

[0145] Then, the target string can be parsed, and the hardware information obtained from the parsing process can be used as reference hardware information.

[0146] It should be noted that, as described in step S303 regarding the generation of the target string, the second device can generate the target string in three ways (such as target string generation method one, target string generation method two, and target string generation method three mentioned above). The parsing and processing of the target strings generated using different methods also differs. The following section elaborates on the parsing and processing of target strings under different generation methods.

[0147] (1) When the target string is generated by the first method, considering that the target string is obtained by directly using the second concatenation method to concatenate the hardware information and data information of the first device, the specific process of parsing the target string can be: split the target string to obtain the hardware information and data information of the first device included in the target string.

[0148] (2) When the target string is generated by the second method, considering that the target string is obtained by encrypting the second string using the second key, and the second string is obtained by concatenating the hardware information and data information of the first device; the specific process of parsing the target string can be: decrypting the target string using the decryption key corresponding to the second key to decrypt the hardware information and data information of the first device included in the target string; specifically, the target string can be decrypted first using the decryption key corresponding to the second key to obtain the second string, and then the second string can be split to obtain the hardware information and data information of the first device included in the second string.

[0149] (3) When the target string is generated by the third method, considering that the target string is the authorization request string generated by the first device, and the authorization request string is obtained by encrypting the first string with the first key, and the first string is obtained by concatenating the hardware information and data information of the first device; the specific process of parsing the target string can be: decrypting the target string with the decryption key corresponding to the first key to decrypt the hardware information and data information of the first device included in the target string; specifically, the target string can be decrypted with the decryption key corresponding to the first key to obtain the first string, and then the first string can be split to obtain the hardware information and data information of the first device included in the first string.

[0150] In the parsing process involved in (1), (2) and (3) above, if the parsing fails (such as decryption failure), an initialization verification failure prompt can be output so that relevant personnel can understand the initialization verification status in a timely and intuitive manner.

[0151] Finally, based on the current hardware information and reference hardware information, it can be determined whether the first device has passed the runtime environment initialization verification. Specifically, the current hardware information can be matched with the reference hardware information. If the current hardware information and the reference hardware information match, it can be determined that the first device has passed the runtime environment initialization verification; if the current hardware information and the reference hardware information do not match, it can be determined that the first device has failed the runtime environment initialization verification. If it is determined that the first device has failed the runtime environment initialization verification, an initialization verification failure message can also be output so that relevant personnel can understand the initialization verification status in a timely and intuitive manner.

[0152] Matching the current hardware information with the reference hardware information means determining whether the current hardware information and the reference hardware information are the same. If the current hardware information and the reference hardware information are the same, then the current hardware information and the reference hardware information are matched. If the current hardware information and the reference hardware information are different, then the current hardware information and the reference hardware information are not matched.

[0153] s13, If the authorization credential information fails the signature verification, the management service determines that the first device has failed the initialization verification of the operating environment.

[0154] In a specific implementation, if the authorization credential information fails signature verification, the first device can also output an initialization verification failure prompt, so that relevant personnel can easily understand the initialization verification status and make timely adjustments to the initialization verification failure issue.

[0155] S2, if the first device passes the initialization verification of the operating environment, the management service initialization is determined to be successful; if the first device fails the initialization verification of the operating environment, the management service initialization is determined to be unsuccessful.

[0156] In one embodiment, if the first device passes the runtime environment initialization verification, the management service initialization is considered successful, and a success message can be output. If the first device fails the runtime environment initialization verification, the management service initialization is considered failed. Similarly, a failure message can be output if the management service initialization fails. These messages allow relevant personnel to clearly and directly understand the result of the management service initialization. Furthermore, if a failure message is output, relevant personnel can quickly resolve the issue. For example, if the failure is due to the management service running on a device not authorized by the second device, the management service can be redeployed.

[0157] To better understand the process of initializing the management service based on authorization credential information proposed in this application, the following is combined with... Figure 4c The illustrated process further elaborates on the initialization of the management service. This process can also be understood as the authorization verification step of the management service, for example, see [link to relevant documentation]. Figure 4c As shown, this step may include the following steps 1-10:

[0158] Step 1: The management service uses the built-in public key and the authorization request string to sign and verify the authorization string.

[0159] It should be noted that this process uses the authorization request string as an example to illustrate the signature verification of the authorization string.

[0160] Step 2: Determine if the signature verification was successful.

[0161] If the signature verification is successful, step 3 below can be executed; if the signature verification fails, the initialization verification of the management service has failed.

[0162] Step 3: Decrypt the authorization request string to obtain the object identifier, deployment quantity, and hardware information.

[0163] The decrypted hardware information can be used as the reference hardware information mentioned above.

[0164] Step 4: Determine if the decryption was successful.

[0165] If decryption fails, the initialization verification of the management service has failed. If decryption succeeds, proceed to step 5 below.

[0166] Step 5: The management service calls the system interface to obtain or calculate the current hardware information of the first device.

[0167] The current hardware information can refer to the hardware information at the current moment, which can refer to the moment when the system interface is called to obtain the hardware information. As mentioned above, the hardware information can be represented using a UUID, so the current hardware information can refer to a REAL-UUID (real-time UUID).

[0168] Step 6: The management service compares the current hardware information with the hardware information in the authorization request string to see if they match.

[0169] In a specific implementation, if the results are consistent, the verification is successful, indicating that the first device has passed the initialization verification of the operating environment; if the results are inconsistent, the verification fails, indicating that the first device has failed the initialization verification of the operating environment. Here, the hardware information in the authorization request string may refer to the aforementioned reference hardware information.

[0170] As can be seen, the information in the authorization string can include at least the hardware information of the device where the management service is deployed, the number of software development kits deployed, the object identifier of the target object, and the signature of the software provider. After the first device obtains the authorization string, it can perform initial verification of the management service based on the authorization string to ensure that the management service is successfully deployed on the device authorized by the software provider.

[0171] It should be noted that the specific implementation of each step in this process can be found in the descriptions above, and will not be repeated here. It should also be noted that some steps in the above process can be interchanged without affecting the actual effect. For example, the specific execution order of signature verification and decryption is not limited; that is, signature verification can be performed before decryption, or vice versa.

[0172] S305, the node device sends a registration request.

[0173] The node device can refer to any node device that is intended to use the software toolkit.

[0174] In a specific implementation, the registration request can be generated by the node device based on its hardware information, such as the device identifier of the corresponding node device. For example, the device identifier of the corresponding node device can refer to a UUID. The principle of obtaining the hardware information of the node device is the same as that of obtaining the hardware information of the first device. For example, the node device can obtain the hardware information by calling the system interface. The specific implementation can be found in the relevant description above, and will not be repeated here. The method of generating the registration request can include any of the following methods.

[0175] Registration request generation method 1: The node device can obtain the device identifier corresponding to the node device and generate a registration request carrying the device identifier.

[0176] Method 2 for generating registration requests: To avoid the risk of device identifier leakage during the transmission of the registration request, the device identifier can be encrypted, and the encrypted data can be used as the data to be carried in the registration request. In this case, the node device can first obtain the device identifier corresponding to the node device, then encrypt the device identifier to obtain the encrypted device identifier; then, a registration request carrying the encrypted device identifier is generated. The encryption key can be the same as or different from the keys mentioned above (such as the first key and the second key), and there is no limitation on this.

[0177] Registration request generation method three: After obtaining the device identifier, the node device can also sign the device identifier and include the signed device identifier in the registration request. Specifically, first, the node device can obtain the device identifier corresponding to the node device; then, the node device can directly sign the device identifier to obtain the signature of the device identifier. For ease of description, this signature can be referred to as the first identifier signature. After the node device generates the first identifier signature, it can generate a registration request carrying the first identifier signature and the device identifier.

[0178] Registration request generation method four: After obtaining the device identifier, the node device can encrypt and sign the device identifier, and include the encrypted and signed device identifier in the registration request. Specifically, first, the node device can obtain the device identifier corresponding to the node device; then, it can encrypt the device identifier to obtain the encrypted device identifier; further, it can sign the encrypted device identifier to obtain a signature result, which can be referred to as the second identifier signature. After the node device generates the encrypted device identifier and the second identifier signature, it can generate a registration request carrying the second identifier signature and the encrypted device identifier.

[0179] It should be noted that in addition to carrying an identifier signature (such as a first identifier signature or a second identifier signature) in the registration request, the original data corresponding to that identifier signature must also be included. This is so that signature verification can be performed based on the original data corresponding to the identifier signature. For example, if the identifier signature is a first identifier signature, the original data is the device identifier; if the identifier signature is a second identifier signature, the original data is the encrypted device identifier.

[0180] S306 After successfully initializing the management service, the first device responds to the registration request sent by the node device by calling the management service to obtain the device identifier of the corresponding node device.

[0181] In a specific implementation, after successfully initializing the management service, the first device can respond to registration requests sent by any node device that wishes to use the software toolkit. To respond to a registration request sent by a node device, the management service can be invoked to obtain the device identifier of the corresponding node device. For example, the device identifier of the node device can be obtained from the registration request. However, the method for obtaining the device identifier of the node device from the registration request differs depending on the type of registration request generated.

[0182] Method 1: When the registration request is generated using Method 1, since the registration request directly carries the device identifier of the node device, the first device can call the management service to directly obtain the device identifier of the corresponding node device from the registration request.

[0183] Method 2: When the registration request is generated using Method 2, since the registration request directly carries the encrypted node identifier, the first device can call the management service to decrypt the encrypted node identifier. If decryption is successful, the decrypted data can be used as the device identifier of the corresponding node device. If decryption fails, a registration failure message can be sent to the corresponding node device, indicating that decryption failed.

[0184] Method 3: When the registration request is generated using Method 3, since the registration request directly carries the signed node identifier (i.e., the first identifier signature) and the node identifier, the first device can call the management service to verify the first identifier signature. If the first identifier signature passes the signature verification, it indicates that the device identifier carried in the registration request has not been tampered with, and the device identifier carried in the registration request can be obtained as the device identifier of the corresponding node device. If the first identifier signature fails the signature verification, it indicates that the device identifier carried in the registration request is at risk of being tampered with, and a registration failure message can be sent to the corresponding node device. This registration failure message can be a message indicating that the signature verification failed.

[0185] Method 4: When the registration request is generated using Method 4, since the registration request directly carries the second identifier signature and the encrypted node identifier, the first device can call the management service to verify the first identifier signature. If the first identifier signature fails the signature verification, it indicates that the device identifier carried in the registration request is at risk of being tampered with, and a registration failure message can be sent to the corresponding node device. This registration failure message can be a message indicating that the signature verification failed. If the first identifier signature passes the signature verification, it indicates that the device identifier carried in the registration request has not been tampered with, and the encrypted data can be further decrypted to obtain the device identifier of the corresponding node device. If the encrypted data is successfully decrypted, the device identifier of the corresponding node device can be obtained; if the encrypted data fails to decrypt, it indicates that the device identifier of the responding node device is at risk of being leaked, and a registration failure message can be sent to the corresponding node device. This registration failure message can be a message indicating that the decryption failed.

[0186] It should be noted that the specific execution order of signature verification and decryption is not limited here. That is to say, signature verification can be performed first and then decryption can be performed first and then signature verification can be performed.

[0187] S307, the first device calls the management service to find the registration record of the corresponding node device based on the obtained device identifier.

[0188] In a specific implementation, when the first device responds to a registration request sent by a node device that wants to use the software toolkit and authorizes the node device to have the permission to use the software toolkit, it can store the registration record corresponding to the node device so that it can determine whether to authorize subsequent node devices based on the registration record.

[0189] In one embodiment, the registration record can be the device identifier corresponding to the node device. That is, when a node device has permission to use the software toolkit, the first device records the device identifier of the node device. For example, the first device can record a set of device identifiers for node devices with permission to use the software toolkit, which includes the device identifiers of each node device with permission to use the software toolkit. For example, the set of device identifiers is: [Device Identifier 1 Device Identifier 2 Device Identifier 3 Device Identifier 4].

[0190] S308 If no registration record is found, the first device will register the corresponding node device and, after the corresponding node device is successfully registered, will authorize the corresponding node device to have the permission to use the software toolkit.

[0191] As mentioned above, if the first device records a set of device identifiers for node devices that have permission to use the software toolkit, then if the first device finds the device identifier of the corresponding node device in the set of device identifiers, it can be determined that the first device has not found the registration record.

[0192] Understandably, if the first device does not find a registration record, it indicates that the corresponding node device has not yet been registered. In order to enable the corresponding node device to use the software toolkit, the corresponding node device can be registered. The result of the registration process can be registration success or registration failure. If the registration process is successful, the corresponding node device can be authorized to use the software toolkit.

[0193] In a specific implementation, the process of registering the corresponding node device in step S307 can be as follows:

[0194] First, you can query the number of successfully registered node devices and determine the number of software development kits deployed.

[0195] Then, after determining the number of devices and the number of deployments, the corresponding node devices can be registered based on these numbers. In one embodiment, registration can be based on a comparison between the number of devices and the number of deployments. Specifically, if the number of devices is less than the number of deployments, the device identifier of the corresponding node device can be stored to complete the registration, thus confirming successful registration. Conversely, if the number of devices equals the number of deployments, registration is considered unsuccessful.

[0196] Understandably, if the number of devices is less than the deployment quantity, meaning the number of currently registered node devices has not yet exceeded the planned deployment quantity of the software development kit (SDK) for the target object, then registration of the corresponding node device can be allowed; to complete the registration of the corresponding node device, the device identifier of the corresponding node device can be stored. However, if the number of devices equals the deployment quantity, meaning the number of currently registered node devices has reached the planned deployment quantity of the SSD for the target object, then registration of the corresponding node device is not allowed, and it can be determined that the registration of the corresponding node device has failed.

[0197] For example, if the deployment quantity is 15 and the number of devices is 13, the device identifier of the corresponding node device can be stored to complete the registration of the corresponding node device. If the number of devices is 15, it can be determined that the registration of the corresponding node device has failed.

[0198] In one embodiment, to complete the registration of the corresponding node devices, the first device may store the device identifier of the corresponding node device and send a registration success notification to the corresponding node device; conversely, if the first device determines that the registration of the corresponding node device has failed, it may also send a registration failure notification to the corresponding node device. By sending these notifications, relevant personnel can understand the registration status of the corresponding node devices based on these notifications, and when they see a registration failure notification, they can promptly resolve the registration failure issue.

[0199] In one embodiment, before registering the corresponding node device in step S308, it can be determined whether to trigger the registration process for the corresponding node device based on relevant characteristics. For example, the relevant characteristics may refer to the node device's hardware information, the service it belongs to, etc.

[0200] In one possible implementation, the first device can determine whether to register the corresponding node device based on the node device's hardware information. Specifically, the first device can obtain the hardware information of the corresponding node device and detect its ability to run a software toolkit based on that information. If the device is found to have the ability to run the software toolkit, the registration process can be initiated. If the device is found to lack the ability to run the software toolkit, a registration failure message can be sent to the node device.

[0201] For example, the hardware information here may include one or more of the following: the IP address (Internet Protocol Address) of the node device, the CPU (Central Processing Unit) type, and memory.

[0202] The following section describes the specific implementation of the ability to detect the running software toolkit of the corresponding node device based on the hardware information mentioned above.

[0203] In one implementation, when the hardware information of a node device is a CPU type, the target object can pre-set the CPU type of the node device that is allowed to deploy the software toolkit. In this case, the first device can determine whether the CPU type of the corresponding node device is the CPU type of the node device that is allowed to deploy the software toolkit. If the CPU type of the corresponding node device is the CPU type of the node device that is allowed to deploy the software toolkit, it can be determined that the corresponding node device has the ability to run the software toolkit. If the CPU type of the corresponding node device is not the CPU type of the node device that is allowed to deploy the software toolkit, it can be determined that the corresponding node device does not have the ability to run the software toolkit.

[0204] For example, a CPU type with better performance can be selected as the CPU type for node devices that are allowed to deploy software toolkits. CPU performance can be defined based on CPU performance parameters, such as clock speed and cache. For instance, defining CPU performance by clock speed means that a higher clock speed results in faster CPU computation and processing speed. Therefore, to ensure the running speed of the integrated software toolkit's business services, node devices with the best possible CPU performance should be selected. Based on this, CPUs with clock speeds exceeding a certain threshold can be identified as the CPU types for node devices allowed to deploy software toolkits. This clock speed threshold can be set based on requirements, and its specific value is not limited.

[0205] In another implementation, where the node device's hardware information is memory, the target object can pre-set a memory threshold. It's understood that the larger the node device's memory, the faster its operating speed. Therefore, to ensure the running speed of the integrated software toolkit's business services, the first device can select a node device with larger memory. Based on this, the first device can determine whether the memory of the corresponding node device exceeds the memory threshold. If the memory of the corresponding node device exceeds the memory threshold, it can be determined that the corresponding node device has the capability to run the software toolkit; if the memory of the corresponding node device does not exceed the memory threshold, it can be determined that the corresponding node device does not have the capability to run the software toolkit.

[0206] In another possible implementation, the target object can be pre-configured with business services that allow the deployment of software toolkits. In this case, the first device can determine whether to register the corresponding node device based on the business service to which the node device belongs. Specifically, the first device can obtain the business service to which the corresponding node device belongs and detect the capability of the corresponding node device to run the software toolkit based on the business service. If the corresponding node device is detected to have the capability to run the software toolkit, the registration process for the corresponding node device can be triggered. If the corresponding node device is detected to lack the capability to run the software toolkit, a registration failure message can be sent to the corresponding node device.

[0207] Specifically, the method of detecting the ability of a node device to run a software toolkit based on the business service to which the corresponding node device belongs can be implemented as follows: determine whether the business service to which the corresponding node device belongs is a business service that allows the deployment of software toolkits; if the business service to which the corresponding node device belongs is a business service that allows the deployment of software toolkits, then it can be determined that the corresponding node device has the ability to run software toolkits; if the business service to which the corresponding node device belongs is not a business service that allows the deployment of software toolkits, then it can be determined that the corresponding node device does not have the ability to run software toolkits.

[0208] For example, the target object pre-configures the business services that allow the deployment of software toolkits as business service 1, business service 2, and business service 3; if the business service to which the node device belongs is business service 3, it indicates that the node device has the ability to run the software toolkit; if the business service to which the node device belongs is business service 4, it indicates that the node device does not have the ability to run the software toolkit.

[0209] S309, if a registration record is found, the first device will authorize the corresponding node device to enable the corresponding node device to use the software toolkit.

[0210] As mentioned above, if the first device records a set of device identifiers for node devices that have permission to use the software toolkit, then the first device can determine that it has found the registration record by finding the device identifier of the corresponding node device in the set of device identifiers.

[0211] In the specific implementation, if the first device finds a registration record, it indicates that the corresponding node device has completed registration and the registration has been successful. Then, the corresponding node device can be authorized to use the software toolkit.

[0212] To better understand the authorization process for the corresponding node device by the first device invocation management service proposed in this application, the following is combined with Figure 4dThe process illustrated is further explained. For example, see [link to example]. Figure 4d As shown, this step may include the following steps 1-10:

[0213] Step 1: The node device obtains the device identifier of the node device in real time and generates a registration request based on the device identifier.

[0214] The device identifier can be understood as the hardware information of the local operating environment of the node device. For example, the device identifier can refer to the UUID of the node device.

[0215] Step 2: The node device sends a registration request to the first device.

[0216] The registration request may include encrypted data obtained by encrypting the device identifier of the node device, and signature data (such as the second identifier signature mentioned above) that is signed by signing the encrypted data. It should be noted that the registration request may carry other information (such as the relevant description in step S306). The process here is illustrated by taking an example where the registration request carries encrypted data of the device identifier of the node device and the second identifier signature.

[0217] Step 3: The first device performs signature verification and decryption on the registration request.

[0218] In a specific implementation, the first device can verify the signature of the second identifier and decrypt the encrypted data.

[0219] Step 4: The first device determines whether the signature verification and decryption were successful.

[0220] If both signature verification and decryption are successful, step 5 can be executed. If either signature verification or decryption fails, the node device's authorization is deemed to have failed, meaning the node device does not have permission to use the software toolkit.

[0221] Step 5: The first device obtains the device identifier of the decrypted node device.

[0222] Step 6: The first device queries whether the device identifier of the node device has been registered.

[0223] If the device identifier of the node device is not registered, then step 7 can be executed. If the hardware information of the node device is registered, then it can be determined that the node device has been successfully authorized, that is, the node device has the permission to use the software toolkit.

[0224] Step 7: The first device queries the number of successfully registered node devices.

[0225] Step 8: The first device determines whether the number of devices is less than the number of deployments.

[0226] If the number of devices is not less than the deployment quantity (for example, if the number of devices equals the deployment quantity), then the authorization limit for the node device is exceeded, and the node device registration fails, meaning the authorization for that node device fails. If the number of devices is less than the deployment quantity, then the node device can be authorized, and step 9 below can be executed.

[0227] Step 9: Device identifier of the first device storage node.

[0228] Step 10: The first device sends a registration success message to the node device.

[0229] The successful registration response can be a notification indicating that the node device has been successfully registered or authorized, so that relevant personnel can understand the authorization status of the node device.

[0230] As described above, real-time dynamic authorization of the software toolkit can be achieved through the interaction and collaboration between authorized management service devices and node devices that wish to use the software toolkit. Furthermore, since the license string issued by the software provider specifies the number of software development kits to be deployed, this application can also manage the number of authorized devices running the software toolkit. Moreover, in the scenario of private distributed deployment of large-scale projects, authorization of node devices and management of the number of authorized node devices can be achieved through the interaction and collaboration between the first device deployed in the same private environment and the node devices. For environments with dynamically scaling node devices (such as environments where the hardware information of node devices is unstable and changes frequently), this is also beneficial for the dynamic scaling of business services under the target object, meaning the target object can adjust the authorization status of node devices in real time.

[0231] It should be noted that the specific implementation of each step in this process can be found in the descriptions above, and will not be repeated here. It should also be noted that some steps in the flowchart above can be interchanged without affecting the actual effect. For example, the execution order of steps 9 and 10 can be switched; the specific execution order of signature verification and decryption in step 4 is not limited, meaning that signature verification can be performed before decryption, or vice versa.

[0232] It should be noted that the cryptographic algorithms mentioned in this application embodiment, such as SM2 and SM4, can be replaced with other similar cryptographic algorithms, such as RSA (an algorithm for public-key cryptography), ECDSA (Elliptic Curve Digital Signature Algorithm), AES (Advanced Encryption Standard), etc. That is, this application embodiment does not specifically limit the cryptographic algorithms. For security reasons, the encryption and signing keys involved in the node device registration process may be different from the keys used in the generation of the aforementioned authorization credential information and the initialization verification process of the management service.

[0233] In this embodiment, the software provider of the software toolkit only needs to authorize one device to use the management service to manage the distributed deployment of the software toolkit. This single device can then dynamically authorize various node devices that wish to use the software toolkit. Therefore, the software provider only needs to collect the hardware information of the device running the management service—that is, only the hardware information of one device—without collecting the hardware information of all node devices where the software toolkit needs to be deployed. This enables distributed deployment management of the software toolkit, allowing dynamic authorization for deployment across multiple node devices. Furthermore, after the software provider authorizes one device with the management service, real-time dynamic authorization of the node devices using the software toolkit can be achieved through interaction and collaboration between the authorized device and the node devices using the software toolkit. This also allows for management of the number of authorized devices running the software toolkit. This effectively overcomes the inefficiency and high delivery costs of collecting hardware information from all node devices, thereby significantly improving the efficiency of software toolkit deployment management, increasing node device authorization efficiency, and reducing delivery costs associated with hardware information.

[0234] Based on the description of the above software deployment management method embodiments, this application provides a software deployment management device. The software deployment management device may be a computer program (including program code) running on a first device, and the software deployment management device can execute... Figures 2-3 The method steps are shown in the diagram. The first device refers to a device with a built-in management service for the software toolkit, and which is intended to use the management service to manage the distributed deployment of the software toolkit; the device used by the software provider of the software toolkit is the second device. Please refer to [link to relevant documentation]. Figure 5 The software deployment management device can operate the following units:

[0235] Sending unit 501 is configured to send a management authorization request to the second device, requesting the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit; wherein, the management authorization request is generated based on the hardware information of the first device;

[0236] The receiving unit 502 is configured to receive authorization credential information returned by the second device, wherein the authorization credential information is generated after the second device verifies that the first device is qualified to use the management service according to the management authorization request;

[0237] The management unit 503 is used to initialize the management service based on the authorization credential information, and after successfully initializing the management service, in response to a registration request sent by any node device that wants to use the software toolkit, call the management service to perform deployment management of the software toolkit on the corresponding node device.

[0238] In one embodiment, the apparatus further includes a generation unit 504, which, before sending a management authorization request to the second device, is specifically used to:

[0239] Deploy the target tool provided by the software provider in the first device; the target tool is a tool for generating authorization request strings for the management service.

[0240] The target tool is invoked to collect the hardware information of the first device, and the target tool is invoked to generate a string based on the collected hardware information as the authorization request string for the management service;

[0241] Generate a management authorization request carrying the authorization request string.

[0242] In one implementation, the target tool deployed in the first device includes: data information negotiated between the software provider and the target object, and a first key generated by the software provider using the second device; wherein, the target object refers to an object that obtains the software toolkit from the software provider using electronic resources, and the data information includes at least one of the following: the object identifier of the target object, and the deployment quantity of the software development kit, the deployment quantity being used to indicate that the target object plans to deploy the software development kit in K node devices, where K is a positive integer; the generation unit 504, when used to call the target tool to generate a string based on the collected hardware information as the authorization request string of the management service, can be specifically used for:

[0243] The target tool is invoked to concatenate the collected hardware information and the data information according to the first concatenation method to obtain the first string;

[0244] The first key built into the target tool is invoked to encrypt the first string, thereby obtaining the authorization request string for the management service.

[0245] In one implementation, the authorization credential information is an authorization string obtained by the second device signing the target string using its private key, and the second device returns the authorization credential information and the target string together to the first device; wherein, the target string is generated based on the hardware information of the first device and the data information negotiated between the software provider and the target object; when the management unit 503 initializes the management service based on the authorization credential information, it can specifically be used for:

[0246] The authorization credential information and the target string are passed to the management service, so that the management service performs initialization verification of the operating environment of the first device based on the target string and the authorization credential information;

[0247] If the first device passes the initialization verification of the runtime environment, the management service initialization is determined to be successful; if the first device fails the initialization verification of the runtime environment, the management service initialization is determined to be unsuccessful.

[0248] In one embodiment, the process by which the second device signs the target string using a private key to obtain an authorization string includes: performing a hash operation on the target string to obtain a first hash result, and signing the first hash result using a private key to obtain an authorization string;

[0249] The management unit 503, when used to perform initialization verification of the operating environment of the first device based on the target string and the authorization credential information by the management service, can specifically be used for:

[0250] The authorization credential information is signed and verified based on the public key of the second device and the target string;

[0251] If the authorization credential information passes signature verification, then it is determined that the first device has passed the initialization verification of the operating environment;

[0252] If the authorization credential information fails signature verification, it is determined that the first device has failed the initialization verification of the operating environment.

[0253] In one implementation, when the management unit 503 performs signature verification on the authorization credential information based on the public key of the second device and the target string, it may specifically be used for:

[0254] The authorization credential information is designed using the public key of the second device to obtain a designing result; and the target string is hashed to obtain a second hash result.

[0255] Perform a consistency check on the designing result and the second hash result;

[0256] If the designing result and the second hash result pass the consistency check, then the authorization credential information is determined to have passed signature verification.

[0257] If the designing result and the second hash result fail the consistency check, then the authorization credential information is determined to have failed the signature verification.

[0258] In one implementation, if the authorization credential information passes signature verification, then when the management unit 503 determines that the first device has passed the initialization verification of the operating environment, it may specifically be used to:

[0259] If the authorization credential information passes signature verification, the system interface is called to obtain the current hardware information of the first device;

[0260] The target string is parsed, and the hardware information obtained from the parsing process is used as reference hardware information.

[0261] If the current hardware information matches the reference hardware information, then the first device is determined to have passed the initialization verification of the operating environment.

[0262] If the current hardware information and the reference hardware information do not match, it is determined that the first device has failed the initialization verification of the operating environment.

[0263] In one implementation, when the management unit 503 invokes the management service to manage the deployment of the software toolkit on the corresponding node device in response to a registration request sent by any node device that wishes to use the software toolkit, it may specifically be used for:

[0264] In response to a registration request sent by any node device that wishes to use the software toolkit, the management service is invoked to obtain the device identifier of the corresponding node device;

[0265] The management service is invoked to search for the registration record of the corresponding node device based on the obtained device identifier;

[0266] If no registration record is found, the corresponding node device is registered, and after the corresponding node device is successfully registered, the corresponding node device is authorized to use the software toolkit.

[0267] If a registration record is found, the corresponding node device is authorized to use the software toolkit.

[0268] In one embodiment, when the management unit 503 is used to perform registration processing on the corresponding node device, it may specifically be used for:

[0269] Query the number of successfully registered node devices and determine the deployment quantity of the software development kit. The deployment quantity is used to indicate that the target object plans to deploy the software development kit on K node devices, where K is a positive integer.

[0270] If the number of devices is less than the number of deployments, the device identifier of the corresponding node device is stored to complete the registration of the corresponding node device;

[0271] If the number of devices equals the number of deployments, then the registration of the corresponding node device is determined to have failed.

[0272] In one implementation, before registering the corresponding node device, the management unit 503 can also be used for:

[0273] Obtain the hardware information of the corresponding node device, and detect the ability of the corresponding node device to run the software toolkit based on the hardware information of the corresponding node device;

[0274] If it is detected that the corresponding node device has the ability to run the software toolkit, then the step of registering the corresponding node device is triggered.

[0275] If it is detected that the corresponding node device does not have the ability to run the software toolkit, a registration failure message is sent to the corresponding node device.

[0276] According to one embodiment of this application, Figures 2-3 The steps involved in the method shown can be derived from... Figure 5 This is executed by the various units within the software deployment management device shown. For example, Figure 2 Step S201 shown can be performed by Figure 5 The sending unit 501 shown is used to execute the steps, and steps S204-S205 can all be performed by... Figure 5 The management unit 503 shown is used to execute this; for example, Figure 3 Step S301 shown can be performed by Figure 5 The sending unit 501 shown is used to execute the steps, and steps S304 and S306-S309 can be performed by... Figure 5 The management unit 503 shown is used to execute this.

[0277] According to another embodiment of this application, Figure 5 The various units in the software deployment management device shown can be individually or entirely merged into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the software deployment management device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0278] According to another embodiment of this application, the following can be achieved by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), a device capable of performing operations such as... Figures 2-3 The computer program (including program code) involved in some steps of the corresponding method shown, to construct such as Figure 5 The software deployment management apparatus shown herein, and the related steps for implementing the software deployment management method of the embodiments of this application, are described. The computer program may be recorded on, for example, a computer-readable recording medium, loaded onto the aforementioned computing device via the computer-readable recording medium, and run therein.

[0279] Based on the description of the above software deployment management method embodiments, this application also provides a software deployment management device. The software deployment management device may be a computer program (including program code) running on a second device, and the software deployment management device can execute... Figures 2-3 The method steps are shown in the diagram. The second device refers to the device used by the software provider of the software toolkit. Please refer to [link to relevant documentation]. Figure 6 The software deployment management device can operate the following units:

[0280] The receiving unit 601 is configured to receive a management authorization request sent by a first device, wherein the first device refers to a device that has a built-in management service for the software toolkit and intends to use the management service to manage the distributed deployment of the software toolkit; wherein the management authorization request is generated based on the hardware information of the first device; the management authorization request is used to request that the second device authorize the first device to use the management service to manage the distributed deployment of the software toolkit;

[0281] The generation unit 602 is used to verify the first device's eligibility to use the management service based on the management authorization request; and after verifying that the first device is qualified to use the management service, generate authorization credential information.

[0282] The return unit 603 is used to return the authorization credential information to the first device, so that the first device initializes the management service based on the authorization credential information, and after successfully initializing the management service, responds to the registration request sent by any node device that wants to use the software toolkit, and calls the management service to perform deployment management of the software toolkit on the corresponding node device.

[0283] In one implementation, the management authorization request carries an authorization request string; the generation unit 602, when verifying the eligibility of the first device to use the management service based on the management authorization request, may specifically be used for:

[0284] The authorization request string carried by the management authorization request is decrypted to obtain a first string; and data information is parsed from the first string.

[0285] If the parsed data is data agreed upon between the software provider and the target object, then the first device is determined to be qualified to use the management service; wherein, the target object refers to an object that obtains the software toolkit from the software provider using electronic resources;

[0286] If the parsed data is not the data agreed upon between the software provider and the target object, then it is determined that the first device is not qualified to use the management service.

[0287] In one embodiment, the generation unit 602, when used to generate authorization credential information, may specifically be used for:

[0288] Obtain the target string, which is generated based on the hardware information of the first device and the data information negotiated between the software provider and the target object;

[0289] The target string is signed using the private key to obtain authorization credential information.

[0290] In one embodiment, the generation unit 602, when used to obtain the target string, can specifically be used for:

[0291] Use the authorization request string generated by the first device as the target string;

[0292] Alternatively, the hardware information of the first device and the data information negotiated between the software provider and the target object are concatenated according to the second concatenation method to obtain a second string; the second string is then encrypted using a second key to obtain the target string.

[0293] In one implementation, after receiving the management authorization request sent by the first device, the receiving unit 601 can further be used to:

[0294] Determine the amount of electronic resources actually received by the software provider from the target object, where the target object refers to the object that uses electronic resources to obtain the software toolkit from the software provider;

[0295] Determine the deployment quantity of the software toolkit and the electronic resources required to deploy one of the software toolkits; wherein, the deployment quantity is used to indicate that the target object plans to deploy the software development kit on K node devices, where K is a positive integer;

[0296] Based on the number of deployments and the electronic resources required to deploy one of the software toolkits, determine the total amount of electronic resources that the target object needs to transfer to the software provider;

[0297] If the actual amount of electronic resources received is greater than or equal to the total amount of electronic resources, then the step of verifying the first device's eligibility to use the management service based on the management authorization request is triggered.

[0298] If the actual amount of electronic resources received is less than the total amount of electronic resources, then the management authorization request will be rejected.

[0299] According to one embodiment of this application, Figures 2-3 The steps involved in the method shown can be derived from... Figure 6 This is executed by the various units within the software deployment management device shown. For example, Figure 2 Step S202 shown can be performed by Figure 6 The generation unit 602 shown is used to execute this step, and step S203 can be performed by... Figure 6 The return unit 603 shown is used for execution; for example, Figure 3 Step S302 shown can be performed by Figure 6 The generation unit 602 shown is used to execute step S303, which can be performed by... Figure 6 The return unit 603 shown is used to execute this.

[0300] According to another embodiment of this application, Figure 6The various units in the software deployment management device shown can be individually or entirely merged into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the software deployment management device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0301] According to another embodiment of this application, the following can be achieved by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), a device capable of performing operations such as... Figures 2-3 The computer program (including program code) involved in some steps of the corresponding method shown, to construct such as Figure 6 The software deployment management apparatus shown herein, and the related steps for implementing the software deployment management method of the embodiments of this application, are described. The computer program may be recorded on, for example, a computer-readable recording medium, loaded onto the aforementioned computing device via the computer-readable recording medium, and run therein.

[0302] Based on the description of the above software deployment management method embodiments, this application also provides a computer device, which may be either the first device mentioned above or the second device mentioned above. Please refer to... Figure 7 The computer device may include at least a processor 701, an input interface 702, an output interface 703, and a computer storage medium 704. The processor 701, input interface 702, output interface 703, and computer storage medium 704 within the computer device may be connected via a bus or other means.

[0303] The computer storage medium 704 is a memory device in a computer device used to store programs and data. It is understood that the computer storage medium 704 can include the computer device's built-in storage medium, or it can include extended storage media supported by the computer device. The computer storage medium 704 provides storage space that stores the computer device's operating system. Furthermore, this storage space also stores one or more instructions suitable for loading and execution by the processor 701. These instructions can be one or more computer programs (including program code). It should be noted that the computer storage medium can be a high-speed RAM memory; optionally, it can also be at least one computer storage medium located remotely from the aforementioned processor. The processor can be called a central processing unit (CPU), which is the core and control center of the computer device, suitable for implementing one or more instructions, specifically loading and executing one or more instructions to achieve corresponding method flows or functions.

[0304] In one feasible embodiment, the processor 701 may load and execute one or more instructions stored in the computer storage medium to implement the corresponding steps of the method in the above-described embodiments of the software deployment management method.

[0305] In a specific implementation, when the computer device is the aforementioned first device, one or more instructions in the computer storage medium are loaded by the processor 701 and executed as follows:

[0306] A management authorization request is sent to the second device to request the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit; wherein the management authorization request is generated based on the hardware information of the first device;

[0307] The system receives authorization credential information returned by the second device, which is generated after the second device verifies that the first device is qualified to use the management service based on the management authorization request.

[0308] The management service is initialized based on the authorization credential information. After successful initialization of the management service, in response to a registration request sent by any node device that wishes to use the software toolkit, the management service is invoked to deploy and manage the software toolkit on the corresponding node device.

[0309] In one implementation, before sending the management authorization request to the second device, the one or more instructions are loaded and executed by the processor 701:

[0310] Deploy the target tool provided by the software provider in the first device; the target tool is a tool for generating authorization request strings for the management service.

[0311] The target tool is invoked to collect the hardware information of the first device, and the target tool is invoked to generate a string based on the collected hardware information as the authorization request string for the management service;

[0312] Generate a management authorization request carrying the authorization request string.

[0313] In one implementation, the target tool deployed in the first device includes: data information negotiated between the software provider and the target object, and a first key generated by the software provider using the second device; wherein, the target object refers to an object that obtains the software toolkit from the software provider using electronic resources, and the data information includes at least one of the following: the object identifier of the target object, and the deployment quantity of the software development kit, the deployment quantity being used to indicate that the target object plans to deploy the software development kit in K node devices, where K is a positive integer; when the target tool is invoked to generate a string based on the collected hardware information as an authorization request string for the management service, the one or more instructions are loaded and specifically executed by the processor 701:

[0314] The target tool is invoked to concatenate the collected hardware information and the data information according to the first concatenation method to obtain the first string;

[0315] The first key built into the target tool is invoked to encrypt the first string, thereby obtaining the authorization request string for the management service.

[0316] In one implementation, the authorization credential information is an authorization string obtained by the second device signing the target string using its private key, and the second device returns the authorization credential information and the target string together to the first device; wherein, the target string is generated based on the hardware information of the first device and the data information negotiated between the software provider and the target object; when initializing the management service based on the authorization credential information, one or more instructions are loaded and executed by the processor 701:

[0317] The authorization credential information and the target string are passed to the management service, so that the management service performs initialization verification of the operating environment of the first device based on the target string and the authorization credential information;

[0318] If the first device passes the initialization verification of the runtime environment, the management service initialization is determined to be successful; if the first device fails the initialization verification of the runtime environment, the management service initialization is determined to be unsuccessful.

[0319] In one embodiment, the process by which the second device signs the target string using a private key to obtain an authorization string includes: performing a hash operation on the target string to obtain a first hash result, and signing the first hash result using a private key to obtain an authorization string;

[0320] When the management service performs runtime environment initialization verification on the first device based on the target string and the authorization credential information, the one or more instructions are loaded and executed by the processor 701:

[0321] The authorization credential information is signed and verified based on the public key of the second device and the target string;

[0322] If the authorization credential information passes signature verification, then it is determined that the first device has passed the initialization verification of the operating environment;

[0323] If the authorization credential information fails signature verification, it is determined that the first device has failed the initialization verification of the operating environment.

[0324] In one implementation, when the authorization credential information is signed and verified based on the public key of the second device and the target string, one or more instructions are loaded and executed by the processor 701:

[0325] The authorization credential information is designed using the public key of the second device to obtain a designing result; and the target string is hashed to obtain a second hash result.

[0326] Perform a consistency check on the designing result and the second hash result;

[0327] If the designing result and the second hash result pass the consistency check, then the authorization credential information is determined to have passed signature verification.

[0328] If the designing result and the second hash result fail the consistency check, then the authorization credential information is determined to have failed the signature verification.

[0329] In one implementation, if the authorization credential information passes signature verification, then when it is determined that the first device has passed the initialization verification of the operating environment, the one or more instructions are loaded and executed by the processor 701:

[0330] If the authorization credential information passes signature verification, the system interface is called to obtain the current hardware information of the first device;

[0331] The target string is parsed, and the hardware information obtained from the parsing process is used as reference hardware information.

[0332] If the current hardware information matches the reference hardware information, then the first device is determined to have passed the initialization verification of the operating environment.

[0333] If the current hardware information and the reference hardware information do not match, it is determined that the first device has failed the initialization verification of the operating environment.

[0334] In one implementation, when the management service is invoked to deploy and manage the software toolkit on the corresponding node device in response to a registration request sent by any node device that wishes to use the software toolkit, the one or more instructions are loaded and executed by the processor 701:

[0335] In response to a registration request sent by any node device that wishes to use the software toolkit, the management service is invoked to obtain the device identifier of the corresponding node device;

[0336] The management service is invoked to search for the registration record of the corresponding node device based on the obtained device identifier;

[0337] If no registration record is found, the corresponding node device is registered, and after the corresponding node device is successfully registered, the corresponding node device is authorized to use the software toolkit.

[0338] If a registration record is found, the corresponding node device is authorized to use the software toolkit.

[0339] In one implementation, during the registration process for the corresponding node device, the one or more instructions are loaded and executed by the processor 701:

[0340] Query the number of successfully registered node devices and determine the deployment quantity of the software development kit. The deployment quantity is used to indicate that the target object plans to deploy the software development kit on K node devices, where K is a positive integer.

[0341] If the number of devices is less than the number of deployments, the device identifier of the corresponding node device is stored to complete the registration of the corresponding node device;

[0342] If the number of devices equals the number of deployments, then the registration of the corresponding node device is determined to have failed.

[0343] In one implementation, before the registration process is performed on the corresponding node device, the one or more instructions are loaded and executed by the processor 701:

[0344] Obtain the hardware information of the corresponding node device, and detect the ability of the corresponding node device to run the software toolkit based on the hardware information of the corresponding node device;

[0345] If it is detected that the corresponding node device has the ability to run the software toolkit, then the step of registering the corresponding node device is triggered.

[0346] If it is detected that the corresponding node device does not have the ability to run the software toolkit, a registration failure message is sent to the corresponding node device.

[0347] In a specific implementation, when the computer device is the aforementioned second device, one or more instructions in the computer storage medium are loaded by the processor 701 and executed as follows:

[0348] The system receives a management authorization request from a first device, which is a device that has a built-in management service for the software toolkit and wants to use the management service to manage the distributed deployment of the software toolkit. The management authorization request is generated based on the hardware information of the first device. The management authorization request requests the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit.

[0349] Based on the management authorization request, verify the first device's eligibility to use the management service; and after verifying that the first device is qualified to use the management service, generate authorization credential information;

[0350] The authorization credential information is returned to the first device, enabling the first device to initialize the management service based on the authorization credential information. After successfully initializing the management service, in response to a registration request sent by any node device that wishes to use the software toolkit, the first device invokes the management service to deploy and manage the software toolkit on the corresponding node device.

[0351] In one implementation, the management authorization request carries an authorization request string; when verifying the eligibility of the first device to use the management service based on the management authorization request, the one or more instructions are loaded and executed by the processor 701:

[0352] The authorization request string carried by the management authorization request is decrypted to obtain a first string; and data information is parsed from the first string.

[0353] If the parsed data is data agreed upon between the software provider and the target object, then the first device is determined to be qualified to use the management service; wherein, the target object refers to an object that obtains the software toolkit from the software provider using electronic resources;

[0354] If the parsed data is not the data agreed upon between the software provider and the target object, then it is determined that the first device is not qualified to use the management service.

[0355] In one implementation, when generating authorization credential information, the one or more instructions are loaded and executed by processor 701:

[0356] Obtain the target string, which is generated based on the hardware information of the first device and the data information negotiated between the software provider and the target object;

[0357] The target string is signed using the private key to obtain authorization credential information.

[0358] In one implementation, when acquiring the target string, the one or more instructions are loaded and executed by the processor 701:

[0359] Use the authorization request string generated by the first device as the target string;

[0360] Alternatively, the hardware information of the first device and the data information negotiated between the software provider and the target object are concatenated according to the second concatenation method to obtain a second string; the second string is then encrypted using a second key to obtain the target string.

[0361] In one implementation, after receiving the management authorization request sent by the first device, the one or more instructions are loaded and executed by the processor 701:

[0362] Determine the amount of electronic resources actually received by the software provider from the target object, where the target object refers to the object that uses electronic resources to obtain the software toolkit from the software provider;

[0363] Determine the deployment quantity of the software toolkit and the electronic resources required to deploy one of the software toolkits; wherein, the deployment quantity is used to indicate that the target object plans to deploy the software development kit on K node devices, where K is a positive integer;

[0364] Based on the number of deployments and the electronic resources required to deploy one of the software toolkits, determine the total amount of electronic resources that the target object needs to transfer to the software provider;

[0365] If the actual amount of electronic resources received is greater than or equal to the total amount of electronic resources, then the step of verifying the first device's eligibility to use the management service based on the management authorization request is triggered.

[0366] If the actual amount of electronic resources received is less than the total amount of electronic resources, then the management authorization request will be rejected.

[0367] It should be noted that this application provides a computer program product, which includes one or more instructions stored in a computer storage medium. The processor of a computer device executes the above-described software deployment management method embodiment by invoking these one or more instructions. Figure 2 or Figure 3 The steps performed in the process.

[0368] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Those skilled in the art will understand that implementing all or part of the processes of the above embodiments and making equivalent changes in accordance with the claims of this application are still within the scope of the invention.

Claims

1. A software deployment management method, characterized in that, The method is executed by a first device, which is a device that has a built-in management service for a software toolkit and intends to use the management service to manage the distributed deployment of the software toolkit; wherein, the device used by the software provider of the software toolkit is a second device; the method includes: A management authorization request is sent to the second device to request the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit; wherein, the management authorization request carries an authorization request string, which is a string generated by calling the target tool provided by the software provider based on the hardware information of the first device; The system receives authorization credential information returned by the second device. This authorization credential information is generated after the second device verifies that the first device is qualified to use the management service according to the management authorization request. The authorization credential information is an authorization string obtained by the second device signing a target string using its private key. The target string is generated based on the hardware information of the first device and the data information negotiated between the software provider and the target object. The management service is initialized based on the authorization credential information. After successful initialization of the management service, in response to a registration request sent by any node device that wishes to use the software toolkit, the management service is invoked to deploy and manage the software toolkit on the corresponding node device.

2. The method as described in claim 1, characterized in that, Before sending the management authorization request to the second device, the method further includes: Deploy the target tool provided by the software provider in the first device; the target tool is a tool for generating authorization request strings for the management service. The target tool is invoked to collect the hardware information of the first device, and the target tool is invoked to generate a string based on the collected hardware information as the authorization request string for the management service; Generate a management authorization request carrying the authorization request string.

3. The method as described in claim 2, characterized in that, The target tool deployed in the first device includes: data information negotiated between the software provider and the target object, and a first key generated by the software provider using the second device; The target object refers to the object that obtains the software toolkit from the software provider using electronic resources. The data information includes at least one of the following: the object identifier of the target object, and the deployment quantity of the software toolkit, wherein the deployment quantity is used to indicate that the target object plans to deploy the software toolkit in K node devices, where K is a positive integer. The process of invoking the target tool to generate a string based on the collected hardware information, which serves as the authorization request string for the management service, includes: The target tool is invoked to concatenate the collected hardware information and the data information according to the first concatenation method to obtain the first string; The first key built into the target tool is invoked to encrypt the first string, thereby obtaining the authorization request string for the management service.

4. The method according to any one of claims 1-3, characterized in that, The second device returns the authorization credential information and the target string together to the first device; The initialization of the management service based on the authorization credential information includes: The authorization credential information and the target string are passed to the management service, so that the management service performs initialization verification of the operating environment of the first device based on the target string and the authorization credential information; If the first device passes the initialization verification of the runtime environment, the management service initialization is determined to be successful; if the first device fails the initialization verification of the runtime environment, the management service initialization is determined to be unsuccessful.

5. The method as described in claim 4, characterized in that, The process by which the second device signs the target string using a private key to obtain an authorization string includes: performing a hash operation on the target string to obtain a first hash result, and signing the first hash result using a private key to obtain an authorization string; The management service performs initialization verification of the operating environment of the first device based on the target string and the authorization credential information in the following ways: The authorization credential information is signed and verified based on the public key of the second device and the target string; If the authorization credential information passes signature verification, then it is determined that the first device has passed the initialization verification of the operating environment; If the authorization credential information fails signature verification, it is determined that the first device has failed the initialization verification of the operating environment.

6. The method as described in claim 5, characterized in that, The step of signing and verifying the authorization credential information based on the public key of the second device and the target string includes: The authorization credential information is designed using the public key of the second device to obtain a designing result; and the target string is hashed to obtain a second hash result. Perform a consistency check on the designing result and the second hash result; If the designing result and the second hash result pass the consistency check, then the authorization credential information is determined to have passed signature verification. If the designing result and the second hash result fail the consistency check, then the authorization credential information is determined to have failed the signature verification.

7. The method as described in claim 5, characterized in that, If the authorization credential information passes signature verification, then determining that the first device has passed the initialization verification of the operating environment includes: If the authorization credential information passes signature verification, the system interface is called to obtain the current hardware information of the first device; The target string is parsed, and the hardware information obtained from the parsing process is used as reference hardware information. If the current hardware information matches the reference hardware information, then the first device is determined to have passed the initialization verification of the operating environment. If the current hardware information and the reference hardware information do not match, it is determined that the first device has failed the initialization verification of the operating environment.

8. The method as described in claim 1, characterized in that, The step of responding to a registration request sent by any node device that wishes to use the software toolkit, and invoking the management service to deploy and manage the software toolkit on the corresponding node device, includes: In response to a registration request sent by any node device that wishes to use the software toolkit, the management service is invoked to obtain the device identifier of the corresponding node device; The management service is invoked to search for the registration record of the corresponding node device based on the obtained device identifier; If no registration record is found, the corresponding node device is registered, and after the corresponding node device is successfully registered, the corresponding node device is authorized to use the software toolkit. If a registration record is found, the corresponding node device is authorized to use the software toolkit.

9. The method as described in claim 8, characterized in that, The registration process for the corresponding node devices includes: Query the number of successfully registered node devices and determine the deployment quantity of the software toolkit. The deployment quantity is used to indicate that the target object plans to deploy the software toolkit on K node devices, where K is a positive integer. If the number of devices is less than the number of deployments, the device identifier of the corresponding node device is stored to complete the registration of the corresponding node device; If the number of devices equals the number of deployments, then the registration of the corresponding node device is determined to have failed.

10. The method as described in claim 8, characterized in that, Before registering the corresponding node device, the method further includes: Obtain the hardware information of the corresponding node device, and detect the ability of the corresponding node device to run the software toolkit based on the hardware information of the corresponding node device; If it is detected that the corresponding node device has the ability to run the software toolkit, then the step of registering the corresponding node device is triggered. If it is detected that the corresponding node device does not have the ability to run the software toolkit, a registration failure message is sent to the corresponding node device.

11. A software deployment management method, characterized in that, The method is performed by a second device, which is a device used by the software provider of the software toolkit; the method includes: The system receives a management authorization request from a first device, which is a device that has a built-in management service for the software toolkit and wishes to use the management service to manage the distributed deployment of the software toolkit. The management authorization request carries an authorization request string, which is a string generated by calling a target tool provided by the software provider based on the hardware information of the first device. The management authorization request requests that the second device authorize the first device to use the management service to manage the distributed deployment of the software toolkit. Based on the management authorization request, the first device's eligibility to use the management service is verified; and after verifying that the first device is qualified to use the management service, a target string is obtained, which is generated based on the hardware information of the first device and the data information negotiated between the software provider and the target object; the target string is signed using a private key to obtain authorization credential information; The authorization credential information is returned to the first device, enabling the first device to initialize the management service based on the authorization credential information. After successfully initializing the management service, in response to a registration request sent by any node device that wishes to use the software toolkit, the first device invokes the management service to deploy and manage the software toolkit on the corresponding node device.

12. The method as described in claim 11, characterized in that, The management authorization request carries an authorization request string; the step of verifying the eligibility of the first device to use the management service based on the management authorization request includes: The authorization request string carried by the management authorization request is decrypted to obtain a first string; and data information is parsed from the first string. If the parsed data is data agreed upon between the software provider and the target object, then the first device is determined to be qualified to use the management service; wherein, the target object refers to an object that obtains the software toolkit from the software provider using electronic resources; If the parsed data is not the data agreed upon between the software provider and the target object, then it is determined that the first device is not qualified to use the management service.

13. The method as described in claim 11, characterized in that, The process of obtaining the target string includes: Use the authorization request string generated by the first device as the target string; Alternatively, the hardware information of the first device and the data information negotiated between the software provider and the target object are concatenated according to the second concatenation method to obtain a second string; the second string is then encrypted using a second key to obtain the target string.

14. The method as described in claim 11, characterized in that, After receiving the management authorization request sent by the first device, the method further includes: Determine the amount of electronic resources actually received by the software provider from the target object, where the target object refers to the object that uses electronic resources to obtain the software toolkit from the software provider; Determine the deployment quantity of the software toolkit and the electronic resources required to deploy one of the software toolkits; wherein, the deployment quantity is used to indicate that the target object plans to deploy the software toolkit on K node devices, where K is a positive integer; Based on the number of deployments and the electronic resources required to deploy one of the software toolkits, determine the total amount of electronic resources that the target object needs to transfer to the software provider; If the actual amount of electronic resources received is greater than or equal to the total amount of electronic resources, then the step of verifying the first device's eligibility to use the management service based on the management authorization request is triggered. If the actual amount of electronic resources received is less than the total amount of electronic resources, then the management authorization request will be rejected.

15. A software deployment management device, characterized in that, The device operates in a first device, which is a device that has a built-in management service for a software toolkit and intends to use the management service to manage the distributed deployment of the software toolkit; wherein, the device used by the software provider of the software toolkit is a second device; the device includes: The sending unit is configured to send a management authorization request to the second device to request the second device to authorize the first device to use the management service to manage the distributed deployment of the software toolkit; wherein, the management authorization request carries an authorization request string, which is a string generated by calling the target tool provided by the software provider based on the hardware information of the first device; The receiving unit is configured to receive authorization credential information returned by the second device. The authorization credential information is generated after the second device verifies that the first device is qualified to use the management service according to the management authorization request. The authorization credential information is an authorization string obtained by the second device signing a target string with its private key. The target string is generated based on the hardware information of the first device and the data information negotiated between the software provider and the target object. The management unit is used to initialize the management service based on the authorization credential information, and after successfully initializing the management service, in response to a registration request sent by any node device that wants to use the software toolkit, call the management service to perform deployment management of the software toolkit on the corresponding node device.

16. A software deployment management device, characterized in that, The device operates within a second device, which refers to a device used by the software provider of the software toolkit; the device includes: A receiving unit is configured to receive a management authorization request sent by a first device, wherein the first device refers to a device that has a built-in management service for the software toolkit and intends to use the management service to manage the distributed deployment of the software toolkit; wherein the management authorization request carries an authorization request string, the authorization request string being a string generated by calling the target tool provided by the software provider based on the hardware information of the first device; the management authorization request is used to request that the second device authorize the first device to use the management service to manage the distributed deployment of the software toolkit; The generation unit is configured to verify the first device's eligibility to use the management service based on the management authorization request; and after verifying that the first device is qualified to use the management service, obtain a target string, which is generated based on the hardware information of the first device and the data information negotiated between the software provider and the target object; and sign the target string using a private key to obtain authorization credential information. The return unit is used to return the authorization credential information to the first device, so that the first device initializes the management service based on the authorization credential information, and after successfully initializing the management service, responds to the registration request sent by any node device that wants to use the software toolkit, and calls the management service to perform deployment management of the software toolkit on the corresponding node device.

17. A computer device, the computer device including an input interface and an output interface, the computer device further including a processor and a storage medium, the processor being configured to acquire one or more instructions stored in the computer storage medium to perform the method as described in any one of claims 1-10 or 11-14.

18. A computer storage medium storing one or more instructions, which, when executed, perform the method as described in any one of claims 1-10 or 11-14.

19. A computer program product, characterized in that, The computer program product includes one or more instructions that, when executed by a processor, implement the method as described in any one of claims 1-10 or 11-14.

Images