Locking card data processing method, device, system and storage medium

Abstract

The application provides a lock card data processing method, device and system and a storage medium, and relates to the technical field of terminals. The method comprises the following steps: acquiring at least two lock card demand configuration information of target software, the lock card types of the at least two lock card demand configuration information being different, the lock card types comprising a network lock, a sub-network lock, a service provider lock, a group lock and a user lock; the at least two lock card demand configuration information being used for jointly indicating a service range after lock card verification; and writing the target software and the at least two lock card demand configuration information into a specified position of a terminal. The scheme can be compatible with at least two lock card demand configuration information of different lock card types, can be used for indicating a service range after lock card verification, and can improve the flexibility and scalability of lock card limitation.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a method, apparatus, system and storage medium for processing card lock data. Background Technology

[0002] In the course of advancements in terminal technology, to ensure the interests of operators are protected, terminal devices are pre-loaded with SIM card locking data at the factory to impose restrictions on the device or its software at the national, network, and other levels.

[0003] However, existing technologies often employ a one-to-one deployment approach when deploying SIM card locking data, meaning each project requiring SIM card locking corresponds to only one type of SIM card locking information. In this case, when multiple SIM card locking requirements need to be met, the flexibility and scalability of existing solutions become insufficient, making it difficult to adapt to rapidly changing market demands. In an increasingly competitive market, existing SIM card locking technologies struggle to fully protect the interests of operators.

[0004] Therefore, improving the flexibility and scalability of lock card configuration has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a method, apparatus, system, and storage medium for processing card lock data, which can improve the efficiency and flexibility of card lock usage and simplify the software development and system integration process.

[0006] Firstly, a method for processing card lock data is provided. The method includes: obtaining at least two types of card lock requirement configuration information of the target software, wherein the card lock types of the at least two types of card lock requirement configuration information are different, and the card lock types include: network lock, sub-network lock, service provider lock, group lock and user lock, and the at least two types of card lock requirement configuration information are used to jointly indicate the service scope after card lock verification; and writing the target software and the at least two types of card lock requirement configuration information into a specified location of the terminal.

[0007] The technical solution of this application firstly stores SIM card locking requirements in the form of configuration information, enabling these requirements to be configured individually and avoiding potentially repetitive custom development work. Secondly, this technical solution can achieve compatibility with at least two SIM card locking requirements for a single target software, broadening the software's scope of limitations at multiple levels, thereby meeting operators' urgent needs for flexibility and scalability in SIM card locking software.

[0008] In some possible implementations, the lock card type for at least two types of lock card requirement configuration information is determined by network code information.

[0009] In some examples, network code information includes at least one of: mobile country code, mobile network code, home location register information, and extended information, wherein the mobile country code is used to identify the country range used; the mobile network code is used to identify the mobile network used; the home location register information is used to identify location information; and the extended information is used to identify service information, group information, or mobile subscriber identification number.

[0010] The above implementation methods allow for specific limitations on card lock type information. By combining these different network code information, fine-grained control over the card lock range can be achieved, meeting complex and ever-changing market demands and effectively improving the flexibility and security of the card lock solution.

[0011] In some possible implementations, at least two types of card lock requirement configuration information include first card lock type requirement configuration information and second card lock type requirement configuration information. The first card lock type requirement configuration information includes first network code information, and the second card lock type requirement configuration information includes second network code information. The first network code information and the second network code information are used to jointly indicate the service range after card lock verification.

[0012] Through the above implementation method, after card verification, the scope of device usage can be more flexibly indicated based on information from at least two card types. This solution enhances the flexibility and accuracy of the card locking function, enabling card verification to meet diverse market demands and provide more detailed service restrictions.

[0013] In some examples, the second network code information includes the first network code information. When the terminal satisfies the second network code information, the second network code information is used to indicate all communication services of the open target software. When the terminal satisfies the first network code information but does not satisfy the second network code information, the first network code information and the second network code information are used to indicate some communication services of the open target software. When the terminal does not satisfy the first network code information, the first network code information is used to indicate communication services of the target software that are not open.

[0014] In these example scenarios, the second network code information includes the first network code information; that is, the second network code information further defines the first network code information. In these example scenarios, by comparing the terminal situation during SIM card verification and the scope defined by the two SIM card types, different service ranges can be provided, making the service provision of SIM cards more flexible.

[0015] In other examples, the first network code information and the second network code information include a first part and a second part, the first part being the mobile country code and the mobile network code, and the second part of the first network code information is different from the second network code information. When the terminal satisfies the first network code information and the second network code information, the first network code information and the second network code information are used to indicate all communication services of the open target software.

[0016] In these examples, the first network code information and the second network code information are different except for the mobile country code and mobile network code; that is, there are no further limitations on the first network code information and the second network code information. In these examples, the target software's full communication services can only be opened when both network code information conditions are met simultaneously. In this way, a more stringent range of restrictions on card locking conditions can be provided, offering more secure services in scenarios with high security levels.

[0017] In some possible implementations, writing the target software and at least two types of SIM card lock requirement configuration information into a designated location on the terminal includes: generating at least two types of target information corresponding to the at least two types of SIM card lock requirement configuration information, wherein the SIM card lock requirement configuration information is in XML format and the target information is in binary data bin format; and writing the target software and at least two types of target information into a designated location on the terminal.

[0018] Through the above implementation method, the card lock requirement configuration information is converted into binary data format and then written to the specified location on the terminal. The binary data bin format can provide a higher level of security than the XML format, preventing malicious software or unauthorized visitors from tampering with or forging the card lock rules, thereby protecting the reliability and stability of the entire card lock system.

[0019] In some possible implementations, the target software and at least two types of lock card requirement configuration information are written to a designated location on the terminal, including: encrypting the at least two types of lock card requirement configuration information using an encryption algorithm to obtain encrypted information; and writing the encrypted information to the designated location on the terminal.

[0020] By encrypting the card lock configuration information through the above implementation method, the security of the card lock configuration information is improved, thereby enhancing the confidentiality of the card lock data during storage and use, preventing the risk of unauthorized access and data leakage, and thus providing operators and users with a more secure and reliable card lock management environment.

[0021] In some examples, the encryption algorithm is the RSA algorithm, and the method also includes writing the RSA algorithm public key to a specified location on the terminal.

[0022] Through the above implementation method, the RSA algorithm public key and the lock card requirement configuration information can be associated. During the unlocking verification process, the system will use the RSA algorithm private key to decrypt, thus protecting the security of the lock card requirement configuration information.

[0023] In some possible implementations, a designated location on the terminal includes the non-volatile storage area of ​​the terminal modem.

[0024] The above implementation method ensures that the data remains valid after the device is restarted or shut down, enabling the card locking function to work normally in various device usage scenarios.

[0025] In a second aspect, a device for processing card lock data is provided, comprising: a processor configured to invoke program instructions to execute the method as described in the first aspect; and a storage device for storing a computer program, the computer program including program instructions.

[0026] Thirdly, a card locking requirement processing system is provided, comprising: a card locking device and a terminal; wherein the card locking device is used to perform the method as described in the first aspect to configure the terminal to lock the card.

[0027] Fourthly, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in the first aspect. Attached Figure Description

[0028] Figure 1 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application;

[0029] Figure 2 This is a flowchart of a card lock data processing method provided in an embodiment of this application;

[0030] Figure 3 This is a flowchart of a card lock data processing method provided in an embodiment of this application;

[0031] Figure 4 This is a schematic diagram of a device provided in an embodiment of this application. Detailed Implementation

[0032] The terminology used in the following embodiments is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to also include expressions such as “one or more” unless the context clearly indicates otherwise.

[0033] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0034] This application provides a method, apparatus, system, and storage medium for processing card lock data. The method can be used in the process of processing card lock data.

[0035] The technical solutions in this application will now be described with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for explaining this application and are not intended to limit this application.

[0036] SIM lock is a restriction mechanism, typically set by mobile phone manufacturers or operators, that restricts a target device / software to using communication services only under the SIM lock conditions set by the manufacturer or operator. This restriction is implemented through software in the phone's baseband firmware, ensuring that users can only connect to the bound communication services during the contract period, thus aligning with the operator's interests.

[0037] In related technologies, SIM card locking solutions are typically designed for a single project or specific software, requiring separate development and customization of the corresponding SIM card locking functionality for each project or software. With continuous technological advancements and rapid changes in market demands, operators' requirements for SIM card locking functionality are becoming increasingly diverse and complex. When multiple SIM card locking needs must be met simultaneously, existing solutions often lack the flexibility to adapt, making them ill-suited to the current dynamic market environment and evolving technological requirements.

[0038] Therefore, it is particularly important to propose a card locking method that can be compatible with various requirements to address these limitations.

[0039] Figure 1 This is a schematic diagram of a card lock data processing system provided in an embodiment of this application.

[0040] The system 100 includes, but is not limited to, a security module 110, a processing module 120, a writing module 130, and a terminal 140, and may also include other electronic devices.

[0041] Among them, the security module 110, the processing module 120, and the writing module 130 can be regarded as a card locking device.

[0042] In some implementations, the security module 110 is used to obtain the card lock requirement information and encrypt the card lock requirement information to prevent the card lock requirement information from being maliciously attacked and leaked.

[0043] In some examples, security module 110 may use encryption algorithms, such as the RSA algorithm.

[0044] In some implementations, the processing module 120 acquires encrypted information processed by the security module 110, as well as at least two types of lock card requirement configuration information.

[0045] In some examples, the SIM card lock requirement configuration information is a whitelist of all SIM card lock requirements. The whitelist records a list of allowed access and specific SIM card lock conditions. Unlocking is only possible when the relevant conditions are met to use the relevant SIM card or software.

[0046] In some examples, to improve the security of whitelist information, it is converted into a more secure file format.

[0047] In some examples, the whitelist information is in XML format. The processing module 120 can convert the XML whitelist information into binary format for further processing. For example, the binary format data is in bin format.

[0048] In other examples, the processing module 120 may also perform other encryption or signature processing on the card lock requirement information.

[0049] In some implementations, the writing module 130 combines the target software and card lock requirement configuration information into card lock data, and then writes it to the terminal 140.

[0050] In some examples, the lock card requirement configuration information written to terminal 140 can be lock card requirement configuration information that has not been converted and encrypted, lock card requirement configuration information that has been converted but not encrypted, or lock card requirement configuration information that has been converted and encrypted.

[0051] In some examples, terminal 140 is, but is not limited to, a smart terminal, such as a mobile phone, computer, wearable device, etc.

[0052] To explain more clearly Figure 1 The process in the middle scene, now combined with Figures 2-3 Please provide an explanation.

[0053] Figure 2 This is a flowchart illustrating a method for processing card lock data according to an embodiment of this application. Figure 2As shown, method 200 can be applied to including Figure 1 In the application scenario shown, the method may include at least steps 210 to 220.

[0054] 210. Obtain the lock card requirement configuration information for at least two different lock card types of the target software.

[0055] 220. Write the target software and the lock card requirement configuration information of at least two different lock card types to the specified location on the terminal.

[0056] The steps of method 200 are explained in detail below.

[0057] 210. Obtain the lock card requirement configuration information for at least two different lock card types of the target software.

[0058] In some implementations, the at least two types of lock card requirement configuration information obtained include first information and second information.

[0059] In some examples, the first and second pieces of information are SIM card locking requirement configuration information, also known as whitelist information. A whitelist refers to a set of conditions or identifiers that allow access to or use of a device through a SIM card locking mechanism, typically including permitted networks, carriers, devices, or other relevant licensing information.

[0060] In some examples, the first and second information exist in the form of configuration files for the software / device that needs to lock the card. That is, the first and second information are separate files and are not in the same code system as the software that needs to lock the card.

[0061] In this scenario, the card locking requirement information can be decoupled from the software itself, thereby avoiding the need to rewrite the code for the card locking requirement information for each piece of software and reducing the workload for operators.

[0062] In some implementations, the card lock requirement may include several key elements, such as specifying the card type, device identifier, validity period, or contract period.

[0063] In some implementations, the lock type can be a network lock, networksubset lock, service provider lock, corporate lock, or IMSI lock, which restricts the use of devices / software under specific lock rules, such as specific countries, registered networks, subnets, or corporate networks.

[0064] In some implementations, the restrictions on the above-mentioned card lock types are implemented through network code information.

[0065] In some examples, network code information may include: mobile country code (MCC), which identifies the country of origin of the mobile user; mobile network code (MNC), which identifies the mobile network to which the mobile user belongs; home location register (HLR) information, which identifies the operator and related location information; and extended information, which stores other information that needs to be restricted besides the network codes mentioned above, such as mobile subscriber identification number (MSIN), service information, group information, etc.

[0066] In some examples, the network code information for a network lock is MCC and MNC; the network code information for a sub-network lock is MCC, MNC, and HLR information; the network code information for a service provider lock is MCC, MNC, and service information; the network code information for a group lock is MCC, MNC, service information, and group information; and the network code information for a user lock is MCC, MNC, and MSIN.

[0067] In some specific implementations, a network lock can restrict the device or software that locks the card to access the network of a specific operator in a specific country through MCC and MNC; a sub-network lock further includes HLR information on top of the network lock, thereby further limiting the geographical range of the network that can be accessed; a service provider lock further includes service information on top of the network lock, thereby further limiting the use of a specific service; a group lock, on top of the service provider lock, also includes specific group information, limiting its use to within a specific group; and a user lock, on top of the network lock, also locks the MSIN information, thereby limiting the device / software to be used only by that user.

[0068] As can be seen from the above implementation methods, there is a progressive relationship in the restrictions on network code information between different types of locks. For example, a sub-network lock includes MCC, MNC, and HLR information, while a network lock includes MCC and MNC. That is, the network code information of a sub-network lock includes all the network code information of the network lock, and on top of that, it also includes HLR information. As another example, a service provider lock includes all the network code information of the network lock, and on top of that, it also includes specific service information.

[0069] For convenience, the network code information of the first lock card type of the first information shall be referred to as the first network code information, and the network code information of the second lock card type of the second information shall be referred to as the second network code information.

[0070] In some specific implementations, the first network code information and the second network code information have the aforementioned progressive relationship in terms of their scope, that is, the second network code information includes the first network code information.

[0071] In some examples, when the second network code information includes the first network code information, the service range after card lock verification can be indicated based on the first network code information and the second network code information.

[0072] In some specific implementations, when the terminal satisfies the second network code information, the second network code information is used to indicate all communication services of the target software; when the terminal satisfies the first network code information but not the second network code information, the first network code information and the second network code information are used to indicate some communication services of the target software; when the terminal does not satisfy the first network code information, the first network code information is used to indicate communication services of the target software that are not open.

[0073] In some examples, all communication services may include network services, while some communication services may only include mobile calling functionality.

[0074] In other examples, all communication services may encompass multiple functions such as data services, Wi-Fi services, and Bluetooth services, while some communication services may be limited to Wi-Fi services.

[0075] It is understandable that the above examples are merely illustrations and do not represent all possibilities.

[0076] This multi-level card locking rule design allows for more granular control over device usage permissions. Operators can set different levels of restrictions based on different users, contract types, or market strategies, providing them with greater flexibility to adjust market strategies and meet diverse business needs.

[0077] It is understandable that, further, at least two types of lock card requirement configuration information means that the obtainable lock card requirement information can be more than just the first and second information, but includes multiple information, each containing different lock card requirement configuration information.

[0078] This scalable design allows the card locking mechanism to adapt to more complex rule configuration requirements, further improving the flexibility of the card locking mechanism.

[0079] In some implementations, the first network code information and the second network code information include a first part and a second part. The first part is a mobile country code and a mobile network code. The second part of the first network code information is different from the second part of the second network code information. When the terminal satisfies the first network code information and the second network code information, the first network code information and the second network code information are used to indicate all communication services of the open target software.

[0080] As can be seen from the above implementation method, in this case, the card lock types of the first information and the second information do not have a progressive relationship in terms of network code information. That is, the network code information of the first card lock type corresponding to the first information and the network code information of the second card lock type corresponding to the second information are different from the network code information other than the mobile country code and the mobile network code.

[0081] For example, the first lock type is a sub-network lock, and the corresponding first network code information includes MCC, MNC, and HLR information. The second lock type is a service provider lock, and the corresponding second network code information includes MCC, MNC, and service-related information from the extended information. In this case, the second part of the first network code information is HLR information, and the second part of the second network code information is extended information. There is no hierarchical relationship between the first and second network code information.

[0082] In some examples, during the card locking verification phase in this case, the card locking requirements of both the first and second information must be met simultaneously for the card to be used normally.

[0083] As in the example above, the first lock card type is a sub-network lock, and the second lock card type is a service provider lock. The first lock card type limits the geographical sub-network to which it can be used, and the second lock card type limits the specific services to which it can be used. In this case, the full range of services of the project can only be used when the services limited by the second lock card type are used within the geographical area limited by the first lock card.

[0084] In some examples, if only one type of lock card restriction is met, such as only meeting the geographical restrictions of a sub-network lock or only meeting the service restrictions of a service provider lock, the device will not be able to fully enjoy all the services of the project.

[0085] This design enables stricter card locking requirements on the same device, making it suitable for high-security scenarios and allowing for effective control over device security.

[0086] 220. Write the target software and at least two types of lock card requirement configuration information to a specified location on the terminal.

[0087] In some implementations, first information and second information are written simultaneously, and the specific card type of the information to be written is as described in step 210.

[0088] In this way, different types of lock card requirements can be combined, the scope of equipment use can be flexibly controlled, and more complex market demands can be met.

[0089] In some implementations, encryption or signature methods can be used to protect the card lock configuration information before it is written to a specified location on the terminal, thus preventing the card lock information from being easily cracked and thus harming the interests of operators and mobile phone manufacturers.

[0090] In some examples, encryption algorithms can be used to encrypt the lock card requirement configuration information, such as the RSA algorithm.

[0091] In some implementations, the terminal-specified location includes a non-volatile storage area of ​​the terminal modem.

[0092] The above implementation method ensures that the configuration information remains valid after the device is powered off, further improving the system's reliability and adaptability.

[0093] Figure 3 This is a flowchart illustrating a method for processing card lock data according to an embodiment of this application. Figure 3 As shown, the method 300 can be applied to including Figure 1 In the application scenarios shown.

[0094] Method 300 includes steps 310 and 320, and optionally, method 300 includes steps 301, 302, and 311.

[0095] 301. The security module generates encrypted information and sends it to the processing module.

[0096] 302. The processing module pre-sets the encrypted information generated by the security module in a specified location in the software.

[0097] 310. The processing module obtains configuration information for lock card requirements of at least two different lock card types.

[0098] 311. The processing module generates at least two types of target information based on the lock card requirement configuration information of at least two different lock card types.

[0099] 320. Write the target software and the lock card requirement configuration information of at least two different lock card types to the specified location on the terminal.

[0100] The steps of method 300 are explained in detail below.

[0101] 301. The security module generates encrypted information and sends it to the processing module.

[0102] In some implementations, the encrypted information is generated using an encryption algorithm to ensure the security of the card data during transmission and storage.

[0103] In some examples, the encryption algorithm used is RSA encryption, meaning that the processing module 120 uses the RSA key system to generate a unique set of key pairs for each lock card requirement configuration information. Each key pair includes a public key and a private key.

[0104] In some examples, a database file (such as a .db file) needs to be generated before encryption to ensure that the information is structured and easily accessible.

[0105] For example, a first database file corresponding to the first piece of information and a second database file corresponding to the second piece of information are generated. Here, "corresponding" means that the production line needs to set database files with matching names and information so that when writing lock card requirements, the key information can be matched with the whitelist information, thereby protecting the corresponding lock card requirement configuration information.

[0106] In some examples, the security module 110 sends the generated encrypted information to the processing module 120 for later use.

[0107] 302. The processing module pre-sets the encrypted information generated by the security module in a specified location in the software.

[0108] In some examples, the RSA algorithm generates a key pair where the public key can be deployed to the software that needs to lock the card for runtime verification, while the corresponding private key is reserved for subsequent decryption to ensure that the information can only be accessed by authorized parties.

[0109] In this way, when the device, software or related system needs to verify the lock card information, it can be decrypted and verified using a preset public key to ensure the security and integrity of the information.

[0110] In some implementations, the specified location is a specific directory or file path of the software that needs to be locked. This preset operation enables the processing module 120 to automatically invoke a preset public key during software runtime, ensuring that the target software can interact correctly with the processing module 120.

[0111] By pre-setting the public key to a designated location, the system can efficiently perform encryption operations, while also facilitating subsequent verification and decryption processes, thus providing stable assurance for the operation of the card lock system. This approach not only simplifies the operation process but also improves the system's security and reliability.

[0112] 310. The processing module obtains configuration information for lock card requirements of at least two different lock card types.

[0113] For a detailed implementation of step 310, please refer to step 210 in method 200.

[0114] 311. The processing module generates at least two types of target information based on the lock card requirement configuration information of at least two different lock card types.

[0115] In some examples, at least two types of card lock requirement configuration information include first information and second information. Then, at least two types of target information are generated based on the two types of card lock requirement configuration information, that is, first target information is generated based on the first information and second target information is generated based on the second information.

[0116] In some examples, the process of generating the first target information and the second target information involves converting them into a file type with a higher security level to further protect the data security of the first and second information.

[0117] For example, the first and second information are XML format files that record the lock card configuration and specific lock card rules. After conversion and encryption, the data of the first and second target information is usually saved in binary format (such as bin file), thereby effectively preventing malicious tampering or illegal reading.

[0118] This encryption process ensures the integrity and confidentiality of the card locking rules and configurations. Only systems or users with the correct decryption permissions can access and use this information. It is more difficult to crack than XML files, preventing malicious software or unauthorized visitors from tampering with or forging the card locking rules, thereby protecting the reliability and stability of the entire card locking system.

[0119] 320. Write the target software and the lock card requirement configuration information of at least two different lock card types to the specified location on the terminal.

[0120] In some implementations, when the method is executed, including step 311, the first target information and the second target information are written to a specified location on the terminal after conversion.

[0121] In this case, the security of the written lock card configuration information is higher.

[0122] In some examples, a writing module 130 (such as simba) is used to write the target software and first information, second information (or the first target information and second target information after step 311) together to a specified location in terminal 140.

[0123] In some examples, the designated location of terminal 140 refers to the non-volatile storage area of ​​the terminal modem (modem side).

[0124] By writing encrypted information into the non-volatile storage area on the modem side, the security and stability of the card-related data can be guaranteed, preventing tampering or loss, and ensuring that the configuration information remains valid even after the device is powered off.

[0125] It is understandable that the above process involves matching the software configuration file to configure the card lock requirements. In practical applications, specific card lock requirements can be selected and used according to specific needs, and the relevant processes of execution methods 200 and 300 can be configured for the information corresponding to the requirements. This avoids the repetitive process of writing card lock information into the code every time, reducing the workload of technical personnel.

[0126] Figure 4 This is a schematic diagram of a device provided in an embodiment of this application.

[0127] The data processing device 400 may include a processor 410 and a memory 420.

[0128] The processor 410 is used to acquire configuration information for at least two types and / or priorities of lock card requirements.

[0129] In some examples, the processor 410 may optionally be used to generate at least two types of target information based on lock card requirement configuration information for at least two different lock card types.

[0130] In some examples, the processor 410 may optionally use an encryption algorithm to encrypt the lock card requirement configuration information for at least two different lock card types to obtain encrypted information.

[0131] This process ensures that the card lock configuration information is protected in multiple layers to prevent data leakage or tampering, thereby improving system security.

[0132] The memory 420 is used to write the target software and the lock card requirement configuration information processed by the processor 410 into the non-volatile memory of the device.

[0133] In some examples, the lock card requirement configuration information stored is lock card requirement configuration information that has been processed by an encryption algorithm and / or processed to generate target information.

[0134] The writing process of memory 420 not only preserves the integrity of encrypted data but also ensures that the data remains valid after the device is restarted or shut down, enabling the card locking function to work normally in various device usage scenarios. This design further enhances the stability and security of the system, effectively preventing the risk of loss or malicious alteration of card locking information.

[0135] This application also provides a computer-readable storage medium. The provided computer-readable storage medium stores a computer program, which includes program instructions. When the program instructions are executed by a processor, they can perform the above-described... Figure 2-3 The data processing method shown, and the steps performed in the related implementation methods.

[0136] The aforementioned computer-readable storage medium can be an internal storage unit of the security module, processing module, or writing module provided in any of the foregoing embodiments, such as a hard disk or memory of the device. The provided computer-readable storage medium can also be an external storage device of the provided terminal device, deployment module, or security server, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the provided device. Further, the provided computer-readable storage medium can include both internal storage units of the provided security module, processing module, and writing module, and external storage devices. The provided computer-readable storage medium is used to store the provided computer program and other programs and data required by the provided security module, processing module, and writing module. The provided computer-readable storage medium can also be used to temporarily store data that has been output or will be output. The provided computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The provided available media can be magnetic media (e.g., floppy disk, hard disk, magnetic tape), optical media (e.g., high-density digital video disc (DVD)), or semiconductor media. Semiconductor media can be solid-state drives (SSDs).

[0137] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer program are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means.

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

[0139] In the several embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, and systems can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and other division methods may exist in actual implementation; for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0140] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0141] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can be physically comprised separately, or two or more units can be integrated into one unit. The integrated unit described above can be implemented in hardware or in the form of hardware plus software functional units.

[0142] The integrated unit implemented as a software functional unit described above can be stored in a computer-readable storage medium. This software functional unit, stored in a storage medium, includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute some steps of the methods described in the various embodiments of the present invention.

[0143] It should be understood that the specific examples in this document are only intended to help those skilled in the art better understand the embodiments of this application, and are not intended to limit the scope of the embodiments of this application.

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

[0145] It should also be understood that the various implementation methods described in this specification can be implemented individually or in combination, and the embodiments of this application are not limited in this respect.

[0146] Unless otherwise stated, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this application is for the purpose of describing specific embodiments only and is not intended to limit the scope of this application. In the description of this application, it should be noted that, unless otherwise stated, "a plurality of" means two or more; the terms "upper," "lower," "left," "right," "inner," "outer," etc., indicating orientation or positional relationships, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. The term "and / or" as used in this application includes any and all combinations of one or more of the related listed items. Furthermore, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0147] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for processing card lock data, characterized in that, The method includes: Obtain at least two types of lock card requirement configuration information for the target software. The lock card types of the at least two types of lock card requirement configuration information are different. The lock card types include: network lock, sub-network lock, service provider lock, group lock and user lock. The at least two types of lock card requirement configuration information are used to jointly indicate the service scope after lock card verification. Write the target software and the configuration information for the at least two card lock requirements into a specified location on the terminal; The lock card type of the at least two lock card requirement configuration information is determined by the network code information; The network code information includes at least one of the following: mobile country code, mobile network code, home location register information, and extended information, wherein the mobile country code is used to identify the country range used; the mobile network code is used to identify the mobile network used; the home location register information is used to identify location information; and the extended information is used to identify service information, group information, or mobile subscriber identification number.

2. The method according to claim 1, characterized in that, The at least two types of card lock requirement configuration information include first card lock type requirement configuration information and second card lock type requirement configuration information. The first card lock type requirement configuration information includes first network code information, and the second card lock type requirement configuration information includes second network code information. The first network code information and the second network code information are used to jointly indicate the service range after card lock verification.

3. The method according to claim 2, characterized in that, The second network code information includes the first network code information. When the terminal satisfies the second network code information, the second network code information is used to instruct the opening of all communication services of the target software; When the terminal satisfies the first network code information but does not satisfy the second network code information, the first network code information and the second network code information are used to indicate the opening of some communication services of the target software; If the terminal does not meet the first network code information, the first network code information is used to indicate that the communication services of the target software are not enabled.

4. The method according to claim 2, characterized in that, The first network code information and the second network code information both include a first part and a second part. The first part consists of the mobile country code and the mobile network code. The second part of the first network code information differs from the second network code information. When the terminal satisfies the first network code information and the second network code information, the first network code information and the second network code information are used to indicate that all communication services of the target software are enabled.

5. The method according to any one of claims 1 to 4, characterized in that, Write the target software and the configuration information for at least two card locking requirements into a specified location on the terminal, including: Based on the at least two types of lock card requirement configuration information, generate at least two types of corresponding target information, wherein the lock card requirement configuration information is in XML format and the target information is in binary data bin format; The target software and the at least two types of target information are written to a designated location on the terminal.

6. The method according to any one of claims 1 to 4, characterized in that, The step of writing the target software and the configuration information for at least two card locking requirements into a designated location on the terminal includes: The at least two types of lock card requirement configuration information are encrypted using an encryption algorithm to obtain encrypted information; The encrypted information is written to a designated location on the terminal.

7. The method according to claim 6, characterized in that, The encryption algorithm includes the RSA algorithm, and the method further includes: Write the RSA algorithm public key to a specified location on the terminal.

8. The method according to any one of claims 1 to 4, characterized in that, The designated location of the terminal includes the non-volatile storage area of ​​the terminal modem.

9. A card lock data processing device, characterized in that, include: A processor configured to invoke program instructions to perform the method as described in any one of claims 1 to 8; A storage device for storing a computer program, the computer program including the program instructions.

10. A card lock request processing system, characterized in that, include: Card locking device and terminal; The card locking device is used to perform the method as described in any one of claims 1 to 8 to configure the terminal to lock the card.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 8.

Images