A TF / NM card data injection method adaptive to multi-scene applications

Abstract

This invention relates to a data injection method for TF / NM cards adapted to multiple application scenarios. The method includes deploying multiple data servers in a high-security environment. Each data server includes multiple application systems. The data servers generate multiple resource IDs and corresponding basic data for each application system in batches, storing them in a resource pool corresponding to each application system. Based on the different application systems selected for each TF / NM card, the data servers retrieve the resource IDs and corresponding basic data of the selected application systems from the resource pools, encrypt the resource IDs and basic data, and inject or re-inject them into the logical slots of the TF / NM card. Based on the resource IDs of the application systems requested by the user for withdrawal, the data servers query the resource status of the resource IDs in the logical slots of the TF / NM card, perform the withdrawal operation, and mark the resource status of the resource IDs. All injection, re-injection, and withdrawal operations are performed based on a multi-scenario application resource interaction protocol.

Description

Technical Field

[0001] This invention relates to the field of data security management technology, and in particular to a TF / NM card data injection method adaptable to multiple application scenarios. Background Technology

[0002] Data injection into a TF (TransFlash Memory Card) / NM (Nano Memory Card) card refers to injecting data into the TF / NM card using an injection device (a device or tool for injecting data into the TF / NM card). Depending on the system, the injected data includes the TF / NM card program, card information, user information, configuration, resources, etc. In traditional usage, a TF / NM card is used within an application system, and generally does not require re-injection of data throughout the card's lifespan. The data on the card is added to the TF / NM card at the factory or before it enters the system; therefore, the data is fixed, and the added data will overwrite the original data.

[0003] For industries with high security requirements, users build and deploy multiple application systems based on their needs, such as business type, organizational structure, user scale, and coverage area. Each application system is independently built and deployed, including complete access, authorization, and auditing functions, to support customized use cases based on application business and security levels. This poses a challenge to data injection into TF / NM cards on terminals. Using a single-system, single-scenario injection method is inconvenient for users to carry and access multiple systems: each system needs an independent TF / NM card, and complete business functions are achieved through the independent TF / NM card in conjunction with the mobile phone and backend management system; multiple TF / NM cards are inconvenient for users to carry. Due to high security management requirements, TF / NM card data injection can only be performed in fixed-location scenarios. When switching application systems, the TF / NM card needs to be re-injected with data from the new application system, and when switching back to the original application system, the original application system's data needs to be re-injected. This re-injection method cannot meet the flexible needs of using multiple application systems. Summary of the Invention

[0004] Based on the above analysis, the embodiments of the present invention aim to provide a TF / NM card data injection method that is adaptable to multiple application scenarios, in order to solve the technical problem that the traditional TF / NM card data injection method does not support flexible adaptation to the usage needs of multiple application systems, causing users to need to repeatedly re-inject permission data when switching between different application systems, and is inconvenient for users to carry multiple TF / NM cards, thus affecting the convenience and efficiency of permission data injection.

[0005] The objective of this invention is mainly achieved through the following technical solutions:

[0006] This invention provides a TF / NM card data injection method adaptable to multiple application scenarios, comprising the following steps:

[0007] Step S1: Deploy multiple data servers in a high-security environment. Each data server includes multiple application systems. Each data server generates multiple resource IDs and corresponding basic data for each of its application systems in batches and stores them in the resource pool corresponding to each application system.

[0008] Step S2: Based on the different application systems selected for each TF / NM card, obtain the resource ID and corresponding basic data of the selected application system from the resource pool, and use the resource ID and corresponding basic data to calculate encrypted resource data using a block encryption algorithm and inject or re-inject it into the logical slot of the TF / NM card.

[0009] Step S3: Based on the resource ID of the application system requested by the user for withdrawal, the data server queries the resource status of the resource ID in the logical slot of the TF / NM card, performs the withdrawal operation, and marks the resource status of the resource ID.

[0010] All injection, re-injection, and withdrawal operations are executed based on the multi-scenario application resource interaction protocol.

[0011] Further, step S1 includes:

[0012] For each application system, the data server generates a resource ID by concatenating its own data server ID, application system ID, resource sequence number, and injection count, and allocates basic data. The resource status of the resource ID is set to non-injected, and the injection count is set to 0.

[0013] Multiple resource IDs in the application system are distinguished by the resource sequence number;

[0014] Store multiple resource IDs, corresponding basic data, and resource status of each resource ID in the corresponding resource pool for each application system.

[0015] Each application system corresponds to an independent resource pool, and the resource pools of multiple application systems are logically independent and different databases.

[0016] Further, step S2 includes:

[0017] Multiple TF / NM cards can be used to request the injection of resource IDs into one or more application systems;

[0018] The data server queries the resource information of all logical slots in each TF / NM card of the application system.

[0019] The data server parses the resource information of all logical slots of each TF / NM card, generates configuration information based on the selected application system, and sends the configuration information of the requested application system to the TF / NM card; the TF / NM card returns response information.

[0020] The data server uses a single thread to traverse each TF / NM card that has applied for an application system, and assigns the resource ID of the application system to each card according to the resource sequence number.

[0021] Based on the response information, the data server performs concurrent multi-threaded injection or re-injection operations;

[0022] The configuration information includes the application system ID, the application system creation time, and a description of the resource information.

[0023] Furthermore, the memory of the TF / NM card is divided into multiple logical slots; the response information of the TF / NM card includes the slot status of all logical slots in the card, and if the value of the slot status is yes, the response information also includes a resource ID; wherein, the value of the slot status is yes indicates that a resource ID exists in the logical slot;

[0024] If the response information shows that the logical slot in the memory of the TF / NM card does not contain the resource ID of the application system applied for in this application, and the TF / NM card currently has an empty logical slot;

[0025] Inject the encrypted resource data into the current idle logical slot of the TF / NM card, set the resource status of the resource ID to used, and increment the injection count by 1;

[0026] The TF / NM card returns the response information to the data server via an injection device and a switch.

[0027] Furthermore, if the response information shows that the resource ID of the application system applied for in this application already exists in the logical slot of the memory of the TF / NM card;

[0028] Regenerate the resource ID, use the block encryption algorithm to calculate the encrypted resource data using the regenerated resource ID and the corresponding basic data, and re-inject it into the logical slot occupied by the resource ID to be re-injected in the current TF / NM card. Set the resource status of the resource ID to the used state and increment the injection count by 1.

[0029] Further, step S3 includes:

[0030] The data server receives a user's request to withdraw one or more application systems from the TF / NM card;

[0031] Based on the data server query described in the application, the TF / NM card returns the resource information of all logical slots in its memory.

[0032] If a resource ID for which withdrawal is requested exists in a logical slot and the resource status is "injected", the data server sends a withdrawal instruction to the TF / NM card. The TF / NM card destroys the application system data in the corresponding logical slot, retains only the resource ID, and updates the resource status of the resource ID to "withdrawn". The logical slot then remains in an occupied state.

[0033] If the resource status is either not injected or has been withdrawn, no withdrawal operation is required.

[0034] Furthermore, if the TF / NM card returns a successful injection or re-injection, then the resource status of the resource ID is set to the injected status;

[0035] If the injection fails, the resource status of the resource ID is set to uninjected; if the re-injection fails, the resource status of the resource ID remains unchanged as used.

[0036] If the TF / NM card does not respond, the resource status of the resource ID remains unchanged as used.

[0037] Furthermore, the regeneration of the resource ID includes:

[0038] The data server parses the data server ID, application system ID, resource sequence number, and injection count included in the resource ID from the response information of the TF / NM card, increments the injection count by 1, and concatenates the current data server ID, the parsed application system ID, resource sequence number, and injection count into a new resource ID, which is then updated to the resource pool corresponding to the application system of the data server.

[0039] Furthermore, the multi-scenario resource information interaction protocol includes card information and resource information of the corresponding logical slot;

[0040] The card information includes multi-slot identifiers, the number of multi-slots, and production number;

[0041] The resource information of the logical slot includes slot status, application system ID, resource ID, module type, application system creation time, and resource information description.

[0042] The resource ID includes the data server ID, application system ID, resource sequence number, and number of injections.

[0043] Furthermore, the data server is connected to multiple injection devices via a switch and communicates via the TCP / IP protocol;

[0044] The injection device includes multiple independent slots, each slot for inserting a TF / NM card;

[0045] Each TF / NM card's memory is divided into multiple independent logical slots, and each logical slot is used to inject a resource ID.

[0046] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects:

[0047] 1. This invention allows TF / NM cards to switch flexibly between multiple application systems without the need for a separate TF / NM card for each system, simplifying the user's need to carry and access multiple application systems and improving flexibility; the TF / NM card in this invention supports data injection and withdrawal mechanisms for multiple application systems, enabling one TF / NM card to connect to application systems deployed in multiple scenarios, avoiding repeated re-injection of resource IDs when switching application systems, and meeting the needs of TF / NM cards to use multiple application systems in scenarios with high security requirements;

[0048] 2. This invention enhances data security and ensures the security and reliability of data injection by deploying multiple data servers in a high-security environment and generating independent resource IDs and basic data for each application system; at the same time, the deployment of multiple data servers allows TF / NM cards to apply for resource IDs and basic data from the nearest available location.

[0049] 3. This invention achieves precise control over resources in the memory of TF / NM cards through the management of resource IDs and resource status, including resource injection, re-injection, and withdrawal, which improves the efficiency and accuracy of resource management. At the same time, by withdrawing resource IDs, the waste of resource IDs is avoided, the original resource IDs are reactivated, and they are re-injected into the logical slots previously occupied by the original resource IDs.

[0050] 4. This invention allows users to select application systems and inject or withdraw resource IDs through a simple user interface, simplifying operations, improving user experience, and enhancing user convenience.

[0051] 5. The method in this invention is adaptable to large-scale multi-threaded concurrent injection. Before resource ID injection or re-injection, the TF / NM cards requesting resource IDs are traversed by a single thread, the resource status is set, and the requested resource IDs are serially allocated to each TF / NM card by a single thread, avoiding the possibility of resource IDs being repeatedly injected into different TF / NM cards. Multi-threaded concurrent injection or re-injection of resource IDs and basic data into TF / NM cards is suitable for the injection and management of large-scale TF / NM card data, improving data processing efficiency, adapting to the large-scale deployment needs in high-security environments, and supporting large-scale application deployment.

[0052] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0053] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0054] Figure 1 This is a flowchart of a TF / NM card data injection method adapted to multiple application scenarios in an embodiment of the present invention;

[0055] Figure 2 This is a schematic diagram of the data injection system framework in an embodiment of the present invention;

[0056] Figure 3 This is a schematic diagram of the multi-scenario resource information interaction data format in an embodiment of the present invention;

[0057] Figure 4 This is a flowchart illustrating the multi-scenario data injection process in an embodiment of the present invention. Detailed Implementation

[0058] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0059] A specific embodiment of the present invention, such as Figure 1 As shown, a data injection method for TF / NM cards adapted to multiple application scenarios is disclosed, including the following steps:

[0060] Step S1: Deploy multiple data servers in a high-security environment. Each data server includes multiple application systems. Each data server generates multiple resource IDs and corresponding basic data for each of its application systems in batches and stores them in the resource pool corresponding to each application system.

[0061] Step S2: Based on the different application systems selected for each TF / NM card, obtain the resource ID and corresponding basic data of the selected application system from the resource pool, and use the resource ID and corresponding basic data to calculate encrypted resource data using a block encryption algorithm and inject or re-inject it into the logical slot of the TF / NM card.

[0062] Step S3: Based on the resource ID of the application system requested by the user for withdrawal, the data server queries the resource status of the resource ID in the logical slot of the TF / NM card, performs the withdrawal operation, and marks the resource status of the resource ID.

[0063] All injection, re-injection, and withdrawal operations are executed based on the multi-scenario application resource interaction protocol.

[0064] The basic data is a random number, which, for example, is generated based on a hash function.

[0065] For injection operations, encrypted resource data is injected into an idle logical slot of the TF / NM card; for re-injection operations, encrypted resource data is injected into a logical slot previously occupied by the original resource ID.

[0066] like Figure 2 As shown, the data injection system architecture in a high-security environment mainly includes four types of devices: data server, switch, injection device, and TF / NM card.

[0067] The data server supports multi-node deployment, with multiple physically independent data servers deployed in different locations to ensure that TF / NM cards can apply for resource IDs from the nearest available location.

[0068] Step S1 includes:

[0069] For each application system, the data server generates a resource ID by concatenating its own data server ID, application system ID, resource sequence number, and injection count, and allocates basic data. The resource status of the resource ID is set to non-injected, and the injection count is set to 0.

[0070] Multiple resource IDs of an application system are distinguished by the resource sequence number;

[0071] Store multiple resource IDs, corresponding basic data, and resource status of each resource ID in the corresponding resource pool for each application system.

[0072] Each application system corresponds to an independent resource pool, and the resource pools of multiple application systems are logically independent and different databases.

[0073] Take a physically independent data server as an example. Multiple application systems are deployed on each data server. Multiple application systems are built to reflect the multiple application scenarios in this invention. System #1, System #2, ..., System #n are the application system IDs of the multiple application systems corresponding to one data server. The data server communicates with multiple injection devices simultaneously connected to the switch on a local area network or private network in a high-security environment.

[0074] The data server generates a sufficient number of resource IDs (at least greater than the number of TF / NM cards inserted into the injection device) for each application system deployed on it, and saves the resource IDs and corresponding basic data to the resource pool of the data server's database.

[0075] The data server is connected to multiple injection devices via a switch and communicates via the TCP / IP protocol.

[0076] The injection device includes multiple independent slots, each slot for inserting a TF / NM card;

[0077] Each TF / NM card's memory is divided into multiple independent logical slots, and each logical slot is used to inject a resource ID.

[0078] For example, the data server is a desktop computer or industrial control computer, which is a network offline device, not connected to the public network, and independently deployed in an environment with high security requirements.

[0079] The injection device supports multiple TF / NM cards; for example, such as Figure 2 The injection device shown has 32 notches on its upper part, and each notch can hold a physical TF / NM card, meaning that one injection device has 32 card slots.

[0080] A TF / NM card divides its internal memory into multiple independent logical slots, such as Figure 2 As shown, a TF / NM card has multiple independent logical areas, namely card slot 1, card slot 2, ..., card slot k, with k logical slots;

[0081] For example, k is 4; it can be divided into multiple logical slots according to specific needs.

[0082] The data server is connected to multiple injection devices via a switch and communicates via TCP / IP (Transmission Control Protocol / Internet Protocol).

[0083] The injection device includes multiple independent slots, each slot for inserting a TF / NM card;

[0084] Each TF / NM card's memory is divided into multiple independent logical slots, and each logical slot is injected with a resource ID.

[0085] The data server communicates with the injection device based on the TCP / IP protocol. This communication method facilitates the expansion of the injection device; multiple injection devices can be added as long as the switch port allows.

[0086] The data server injects, re-injects, and retracts permission data for multiple application systems for each TF / NM card. The permission data of the application systems is the resource ID and corresponding basic data in this invention.

[0087] The method in this invention can flexibly and configurably manage resource IDs in multiple application scenarios, satisfying the requirements of TF / NM card storage to support injection, re-injection, and withdrawal of multiple application systems. It enables a single TF / NM card to have permissions for multiple application systems deployed in high-security scenarios, avoiding repeated re-injection of permission data when switching application systems, and meeting the business needs of multiple application systems.

[0088] The user-friendly interface allows for easy creation, re-application, and revocation of permission data on TF / NM cards. It is particularly useful when injecting permission data from multiple application systems into a TF / NM card, offering a convenient one-click application process. This invention is adaptable to large-scale concurrent multi-threaded injection, re-application, and revocation of TF / NM card data under high-security environments.

[0089] To increase the diversity of scenario resources generated by the data server, each data server is configured with multiple application systems, each application system is configured with a separate resource pool, the resource pool is configured in the database of the data server, and the database corresponding to the resource pool of each application system runs independently.

[0090] Based on the application system selected by the user, the data server uses an injection device to inject unused resource IDs and basic data from the resource pool corresponding to the application system into the idle logical slots of the TF / NM card using a block encryption algorithm.

[0091] In this invention, all injection, re-injection, and withdrawal operations are executed based on a multi-scenario application resource interaction protocol.

[0092] like Figure 3 As shown, the multi-scenario resource information interaction protocol includes card information and resource information of the corresponding logical slot;

[0093] The card information includes multi-slot identifiers, the number of multi-slots, and production number;

[0094] The resource information of the logical slot includes slot status, application system ID, resource ID, module type, application system creation time, and resource information description.

[0095] The resource ID includes the data server ID, application system ID, resource sequence number, and number of injections.

[0096] When a TF / NM card needs to use a certain application system, it requires the corresponding application system's permission data. In this invention, the application system's permission data is the resource ID and its corresponding basic data. The resource ID used by each TF / NM card cannot be repeated.

[0097] Unlike traditional single-scenario application resource IDs, the resource IDs in this invention, used across multiple application scenarios, need to distinguish between application systems. Furthermore, since the data servers that inject data into TF / NM cards exist across multiple application systems and are distributed across various locations, the resource IDs need to be able to identify the data server to which they belong for ease of traceability.

[0098] Design a multi-scenario resource ID format, where the resource ID includes the data server ID, application system ID, resource sequence number, and injection count. For example... Figure 2 The resource ID field is shown in the table, and the resource ID field is described in Table 1.

[0099] Table 1: Description of Resource ID Field

[0100]

[0101] When a resource ID is generated for the first time, the data server obtains the data server ID, application system ID, resource sequence number, and injection count (initially 0), and concatenates them into the resource ID. Simultaneously, the data server assigns basic data (a random number) to this resource ID. This basic data is a random number generated using a hash function. The data server stores the resource ID and its corresponding basic data in the database's resource pool.

[0102] For resource serial numbers, for example, for an application system, the data server generates 100,000 resource IDs. When generated for the first time, the data server ID, application system ID, and injection count are all the same in each resource ID. The resource serial number can be 00000-99999.

[0103] The resource ID generated in step S1 is the first generation, and the resource ID will also be regenerated when the resource IDs in the resource pool are exhausted.

[0104] TF / NM cards support storing resource data from multiple scenarios (i.e., multiple application systems). To ensure clear identification of resource information in each logical slot within the card during interaction with the data server, this invention designs a multi-scenario application resource interaction protocol data that supports multiple application scenarios. The format is as follows: Figure 3 As shown.

[0105] All injection, re-injection, and withdrawal operations in this invention are executed based on a multi-scenario application resource interaction protocol.

[0106] The multi-scenario application resource interaction protocol data includes card information and resource information of the logical slots of the TF / NM card. The card information of the TF / NM card is 14 bytes long, and the resource information of each logical slot in the card is 48 bytes long.

[0107] The card information includes multi-slot identifiers, the number of multi-slots, and production number information. The length and meaning of these information are shown in Table 2.

[0108] Table 2: Description of Fields Included in Card Information

[0109]

[0110] Each logical slot contains 48 bytes of resource information, including slot status, application system ID, resource ID, module type, system creation time, and resource description. Its length and meaning are shown in Table 3.

[0111] Table 3: Resource Information Description of Logical Slots for TF / NM Cards

[0112]

[0113] During the data injection phase, the data server generates resource data for the user's selected application system based on the resource information returned by the TF / NM card.

[0114] During the injection process, resource status is set in the resource pool of the database on the data server to achieve concurrent TF / NM card data injection or re-injection, thus avoiding the injection of the same resource ID into different cards.

[0115] As shown in Table 4, before resource ID injection, the resource status of a newly generated resource ID is uninjected, with a value of 0; for re-injection operations, the resource status of the re-injected resource ID is still in the used state.

[0116] (1) Before the injection process begins, the data server sets the resource status of the corresponding resource ID in the resource pool of the database to the used status, with a value of 1.

[0117] (2) Perform resource ID injection operation. If the injection is successful, jump to (3) Set resource status. If the injection fails, jump to (4) Set resource status. If an error occurs during injection, such as a sudden power failure, and the success or failure result cannot be obtained, set resource status according to (5).

[0118] (3) After the resource ID is successfully injected, the data server will change the resource status of the resource ID in the resource pool in the database to the injected status, with a value of 2.

[0119] (4) When resource injection fails and the resource ID is a newly generated resource ID, the data server resets the resource status of the resource ID in the resource pool in the database to the uninjected state, with a value of 0; if it is a re-injection operation, the resource status remains in the used state, with a value of 1.

[0120] (5) If the TF / NM card does not respond during the injection process, it is not clear whether the resource ID has been successfully injected. Keep the resource ID in the resource pool in the used state and set the value to 1.

[0121] Table 4: Explanation of Resource Status for Resource IDs

[0122] Card injection process Resource status Value Before injection No injection 0 Injection process begins Used 1 Injection process failed No injection 0 No response during injection Used 1 Injection successful Injected 2

[0123] Step S1 serves to generate a unique resource ID and its corresponding basic data (random number) for each application system it contains in a high-security environment, and store these data in the respective resource pools of the application systems so as to provide data injection services for multi-scenario applications for the TF / NM card in the future.

[0124] Step S2 includes:

[0125] Multiple TF / NM cards can be used to request the injection of resource IDs into one or more application systems;

[0126] The data server queries the resource information of all logical slots in each TF / NM card of the application system.

[0127] The data server parses the resource information of all logical slots of each TF / NM card, generates configuration information based on the selected application system, and sends the configuration information of the requested application system to the TF / NM card; the TF / NM card returns response information.

[0128] The data server uses a single thread to traverse each TF / NM card that has applied for an application system, and assigns the resource ID of the application system to each card according to the resource sequence number.

[0129] Based on the response information, the data server performs concurrent multi-threaded injection or re-injection operations;

[0130] The configuration information includes the application system ID, the application system creation time, and a description of the resource information.

[0131] This invention relates to a multi-scenario resource ID injection method, the data injection method being as follows: Figure 4 As shown:

[0132] The security administrator starts the data server and the resource ID management system; for example, the security administrator is a system administrator in a high-security environment.

[0133] Log in to the Resource ID Management System interface. This system is used to manage application systems in a high-security environment.

[0134] Users can select one or more application systems on the operation interface of the resource ID management system and click the "Inject Data" button.

[0135] The data server sends query commands to the TF / NM cards that apply for resource IDs through switches and injection devices, and queries the resource information of all logical slots in each TF / NM card that applies for resource IDs;

[0136] After receiving the query command, the TF / NM card returns a response message.

[0137] The memory of the TF / NM card is divided into multiple logical slots; the response information of the TF / NM card includes the slot status of all logical slots in the card, and if the value of the slot status is yes, the response information also includes a resource ID; wherein, the value of the slot status is yes indicates that a resource ID exists in the logical slot;

[0138] The data server uses a single thread to traverse the TF / NM cards and assigns a resource ID to each TF / NM card that requests a resource ID. The purpose of using a single thread is to ensure that the same resource ID is not injected into different TF / NM cards.

[0139] First, a single thread iterates through each TF / NM card to assign the resource ID corresponding to the application system it is applying for. Then, multiple threads concurrently inject the resource ID.

[0140] The response information returned by the TF / NM card includes resource information for all logical slots in the memory of the TF / FM card.

[0141] After receiving the response information, the data server presses... Figure 3 The information is parsed in order of field sequence to obtain the slot status, application system ID, and resource ID of each logical slot of the TF / NM card, and stored in the cache of the data server.

[0142] If the response information shows that the logical slot in the memory of the TF / NM card does not contain the resource ID of the application system applied for in this application, and the TF / NM card currently has an empty logical slot;

[0143] Inject the encrypted resource data into the current idle logical slot of the TF / NM card, set the resource status of the resource ID to used, and increment the injection count by 1;

[0144] The TF / NM card returns the response information to the data server via an injection device and a switch.

[0145] If the response information shows that the resource ID of the application system applied for in this application already exists in the logical slot of the memory of the TF / NM card;

[0146] Regenerate the resource ID, use the block encryption algorithm to calculate the encrypted resource data using the regenerated resource ID and the corresponding basic data, and re-inject it into the original logical slot occupied by the resource ID to be re-injected on the current TF / NM card. Set the resource status of the resource ID to used and increment the injection count by 1.

[0147] Regenerating the resource ID involves using the existing data server ID, application system ID, and resource sequence number, simply incrementing the injection count by 1. This effectively reuses the original resource ID, avoiding waste. Re-injection occurs into the logical slot previously occupied by the original resource ID, preventing it from occupying any free logical slots on the TF / NM card.

[0148] The resource status is used to ensure the uniqueness of the resource ID injected into the TF / NM card. Subsequent injections or re-injections will only select resource IDs whose resource status is unused and not injected.

[0149] The process of regenerating the resource ID includes:

[0150] The data server parses the data server ID, application system ID, resource sequence number, and injection count included in the resource ID from the response information of the TF / NM card, increments the injection count by 1, and concatenates the current data server ID, the parsed application system ID, resource sequence number, and injection count into a new resource ID, which is then updated to the resource pool corresponding to the application system of the data server.

[0151] If the TF / NM card returns a successful injection or re-injection, then the resource status of the resource ID is set to injected.

[0152] If the injection fails, the resource status of the resource ID is set to uninjected; if the re-injection fails, the resource status of the resource ID remains unchanged as used.

[0153] If the TF / NM card does not respond, the resource status of the resource ID remains unchanged as used.

[0154] The resource ID is obtained by concatenating the data server ID, application system ID, resource sequence number, and injection count. The basic data corresponding to the resource ID is then encrypted using a block cipher algorithm to obtain the encrypted resource data.

[0155] Before the injection operation, the data server sets the resource status of the resource ID to the used state and updates the resource status of the corresponding resource ID in the resource pool of the database in the data server.

[0156] Before the re-betting operation, the resource status was already in a used state.

[0157] The data server sends encrypted resource data, including the resource ID and basic data, to the logical slot in the TF / NM card via an injection device and a switch. Upon receiving the data, the TF / NM card stores it in the logical slot and returns a response indicating successful or failed reception.

[0158] If the data server does not receive a response from the TF / NM card within the specified time, it cannot determine whether the TF / NM card has received data, and the data server maintains the resource status as used.

[0159] The data server updates the resource status of the resource ID in the resource pool of the database and displays the result of the injection or re-injection request on the interface. The result includes successful injection, injection failure, successful re-injection, failed re-injection, and no response.

[0160] Based on the injection or re-injection results returned by the TF / NM card, the data server updates the resource status corresponding to the resource ID and stores it in the application system's resource pool in the database:

[0161] a) Injection or re-injection successful: Resource status updated to "Injected" status;

[0162] b) Injection or re-injection failure: If injection fails, the status of the newly allocated resource is updated to "not injected"; if re-injection fails, the resource ID's resource status remains "used".

[0163] c) Injection or re-injection not responding: The resource status remains "used".

[0164] Step S2 is used to manage and execute the resource ID injection or re-injection of the TF / NM card, ensuring that each applied TF / NM card correctly receives and stores the resource ID and basic data of the applied application system, which are encrypted using a cryptographic block algorithm, into the logical slot according to the status and resource information of its logical slot.

[0165] Step S3 includes:

[0166] The data server receives a user's request to withdraw one or more application systems from the TF / NM card;

[0167] Based on the data server query described in the application, the TF / NM card returns the resource information of all logical slots in its memory.

[0168] If a resource ID for which withdrawal is requested exists in a logical slot and the resource status is "injected", the data server sends a withdrawal instruction to the TF / NM card. The TF / NM card destroys the application system data in the corresponding logical slot, retains only the resource ID, and updates the resource status of the resource ID to "withdrawn". The logical slot then remains in an occupied state.

[0169] If the resource status is "not injected" or "reclaimed", no reclamation operation is required.

[0170] From the withdrawal interface of the resource ID management system on the data server, select one or more application systems to be withdrawn.

[0171] The data server queries the resource information of the logical slots in the TF / NM card, and the TF / NM card returns the resource data information of all logical slots in memory.

[0172] The data server cyclically withdraws resource ID data according to the selected application system:

[0173] If the resource status of the resource ID of the corresponding application system in the card is "injected", the data server sends a withdrawal command to the TF / NM card. The TF / NM card destroys the resource data of the corresponding application system, retains only the resource ID information, and updates the resource status to "withdrawn".

[0174] If the resource status is "not injected" or "reclaimed", there is no need to perform a reclamation operation.

[0175] The slot status of the logical slots of the TF / NM card after withdrawal and the withdrawal result are written into the resource pool of the database on the data server.

[0176] Step S3 is to perform a withdrawal operation on the resource ID of one or more application systems in the specified TF / NM card according to the user's application, destroy the injected resource data, update the resource status to withdrawn, not release the logical slot, destroy the resource data in the logical slot, and retain only the resource ID so that the logical slot can be used again when re-injecting.

[0177] In summary, the TF / NM card data injection method adapted to multiple application scenarios according to the embodiments of the present invention has the following beneficial effects:

[0178] 1. This invention allows TF / NM cards to switch flexibly between multiple application systems without the need for a separate TF / NM card for each system, simplifying the user's need to carry and access multiple application systems and improving flexibility; the TF / NM card in this invention supports data injection and withdrawal mechanisms for multiple application systems, enabling one TF / NM card to connect to application systems deployed in multiple scenarios, avoiding repeated re-injection of resource IDs when switching application systems, and meeting the needs of TF / NM cards to use multiple application systems in scenarios with high security requirements;

[0179] 2. This invention enhances data security and ensures the security and reliability of data injection by deploying multiple data servers in a high-security environment and generating independent resource IDs and basic data for each application system; at the same time, the deployment of multiple data servers allows TF / NM cards to apply for resource IDs and basic data from the nearest available location.

[0180] 3. This invention achieves precise control over resources in the memory of TF / NM cards through the management of resource IDs and resource status, including resource injection, re-injection, and withdrawal, which improves the efficiency and accuracy of resource management. At the same time, by withdrawing resource IDs, the waste of resource IDs is avoided, the original resource IDs are reactivated, and they are re-injected into the logical slots previously occupied by the original resource IDs.

[0181] 4. This invention allows users to select application systems and inject or withdraw resource IDs through a simple user interface, simplifying operations, improving user experience, and enhancing user convenience.

[0182] 5. The method in this invention is adaptable to large-scale multi-threaded concurrent injection. Before resource ID injection or re-injection, the TF / NM cards requesting resource IDs are traversed by a single thread, the resource status is set, and the requested resource IDs are serially allocated to each TF / NM card by a single thread, avoiding the possibility of resource IDs being repeatedly injected into different TF / NM cards. Multi-threaded concurrent injection or re-injection of resource IDs and basic data into TF / NM cards is suitable for the injection and management of large-scale TF / NM card data, improving data processing efficiency, adapting to the large-scale deployment needs in high-security environments, and supporting large-scale application deployment.

[0183] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A data injection method for TF / NM cards adaptable to multiple application scenarios, characterized in that, Includes the following steps: Step S1: Deploy multiple data servers in a high-security environment. Each data server includes multiple application systems. Each data server generates multiple resource IDs and corresponding basic data for each of its application systems in batches and stores them in the resource pool corresponding to each application system. Step S2: Based on the different application systems selected for each TF / NM card, obtain the resource ID and corresponding basic data of the selected application system from the resource pool, and use the resource ID and corresponding basic data to calculate encrypted resource data using a block encryption algorithm and inject or re-inject it into the logical slot of the TF / NM card. Step S3: Based on the resource ID of the application system requested by the user for withdrawal, the data server queries the resource status of the resource ID in the logical slot of the TF / NM card, performs the withdrawal operation, and marks the resource status of the resource ID. All injection, re-injection, and withdrawal operations are executed based on the multi-scenario application resource interaction protocol.

2. The method according to claim 1, characterized in that, Step S1 includes: For each application system, the data server generates a resource ID by concatenating its own data server ID, application system ID, resource sequence number, and injection count, and allocates basic data. The resource status of the resource ID is set to non-injected, and the injection count is set to 0. Multiple resource IDs in the application system are distinguished by the resource sequence number; Store multiple resource IDs, corresponding basic data, and resource status of each resource ID in the corresponding resource pool for each application system. Each application system corresponds to an independent resource pool, and the resource pools of multiple application systems are logically independent and different databases.

3. The method according to claim 1, characterized in that, Step S2 includes: Multiple TF / NM cards can be used to request the injection of resource IDs into one or more application systems; The data server queries the resource information of all logical slots in each TF / NM card of the application system. The data server parses the resource information of all logical slots of each TF / NM card, generates configuration information based on the selected application system, and sends the configuration information of the requested application system to the TF / NM card; the TF / NM card returns response information. The data server uses a single thread to traverse each TF / NM card that has applied for an application system, and assigns the resource ID of the application system to each card according to the resource sequence number. Based on the response information, the data server performs concurrent multi-threaded injection or re-injection operations; The configuration information includes the application system ID, the application system creation time, and a description of the resource information.

4. The method according to claim 3, characterized in that, The memory of the TF / NM card is divided into multiple logical slots; the response information of the TF / NM card includes the slot status of all logical slots in the card, and if the value of the slot status is yes, the response information also includes a resource ID; wherein, the value of the slot status is yes indicates that a resource ID exists in the logical slot; If the response information shows that the logical slot in the memory of the TF / NM card does not contain the resource ID of the application system applied for in this application; Inject the encrypted resource data into the current idle logical slot of the TF / NM card, set the resource status of the resource ID to the used state, and increment the injection count by 1; The TF / NM card returns the response information to the data server via an injection device and a switch.

5. The method according to claim 3, characterized in that, If the response information shows that the resource ID of the application system applied for in this application already exists in the logical slot of the memory of the TF / NM card; Regenerate the resource ID, use the block encryption algorithm to calculate the encrypted resource data using the regenerated resource ID and the corresponding basic data, and re-inject it into the original logical slot occupied by the resource ID to be re-injected on the current TF / NM card. Set the resource status of the resource ID to the used state and increment the injection count by 1.

6. The method according to claim 1, characterized in that, Step S3 includes: The data server receives a user's request to withdraw one or more application systems from the TF / NM card; Based on the data server query described in the application, the TF / NM card returns the resource information of all logical slots in its memory. If a resource ID for which withdrawal is requested exists in a logical slot and the resource status is "injected", the data server sends a withdrawal instruction to the TF / NM card. The TF / NM card destroys the application system data in the corresponding logical slot, retains only the resource ID, updates the resource status of the resource ID to "withdrawn", and the logical slot remains in an occupied state. If the resource status is either not injected or has been withdrawn, no withdrawal operation is required.

7. The method according to claim 3, characterized in that, If the TF / NM card returns a successful injection or re-injection, then the resource status of the resource ID is set to the injected status. If the injection fails, the resource status of the resource ID is set to uninjected; if the re-injection fails, the resource status of the resource ID remains unchanged as used. If the TF / NM card does not respond, the resource status of the resource ID remains unchanged as used.

8. The method according to claim 5, characterized in that, The process of regenerating the resource ID includes: The data server parses the data server ID, application system ID, resource sequence number, and injection count included in the resource ID from the response information of the TF / NM card, increments the injection count by 1, and concatenates the current data server ID, the parsed application system ID, resource sequence number, and injection count into a new resource ID, which is then updated to the resource pool corresponding to the application system of the data server.

9. The method according to claim 1, characterized in that, The multi-scenario resource information interaction protocol includes card information and resource information of the corresponding logical slot; The card information includes multi-slot identifiers, the number of multi-slots, and production number; The resource information of the logical slot includes slot status, application system ID, resource ID, module type, application system creation time, and resource information description. The resource ID includes the data server ID, application system ID, resource sequence number, and number of injections.

10. The method according to any one of claims 1-9, characterized in that, The data server is connected to multiple injection devices via a switch and communicates via the TCP / IP protocol. The injection device includes multiple independent slots, each slot for inserting a TF / NM card; Each TF / NM card's memory is divided into multiple independent logical slots, and each logical slot is used to inject a resource ID.

Images