A power internet of things card data cross-system security synchronization method

Abstract

The application belongs to the technical field of power internet of things data synchronization, and discloses a kind of power internet of things card data cross-system safe synchronization method, obtains the card identification of target power internet of things card, to be synchronized change data and synchronization initiation side current synchronization state, according to synchronization constraint record determines target synchronization state and front processing result, and according to the processing state in confirmation record and input data change identification determines to be verified result;To the card processing system that generates corresponding front processing result obtains current confirmation record, forms initiation side front confirmation data, and to-be-synchronized change data and target synchronization state are authenticated together with message.The synchronization receiving side verifies synchronization authentication information, and independently determines to be verified result according to its current synchronization state, and is compared with initiation side front confirmation data;When comparison is consistent and write-in front data state recheck passes, to-be-synchronized change data is written and synchronization state is updated.

Description

Technical Field

[0001] This invention belongs to the field of power Internet of Things (IoT) data synchronization technology, specifically a method for secure cross-system data synchronization of power IoT cards. Background Technology

[0002] As the scale of power IoT SIM cards expands, SIM card services typically require processing such as service configuration, SIM card binding, card writing, activation, core network registration, and Internet Protocol address resource allocation between the SIM card management platform, card issuance system, and core network-related systems. Existing systems generally complete data configuration or status updates in the previous processing stage and then return the processing results to the SIM card management platform through an interface. The SIM card management platform then continues to perform subsequent data synchronization or status advancement based on the returned completion status.

[0003] In this processing method, the input data on which the processing result is based and the processing completion status are usually stored separately. When the access point name, data network name, Internet Protocol address resource, or SIM card binding relationship changes again after a certain processing result is formed, the existing processing result may still remain in the completion status, but its corresponding input data is no longer the current data. If the subsequent system continues to use the completion status as the synchronization basis, even if the synchronization message source is legitimate and the transmitted content has not been tampered with, it cannot be determined that the previous processing result is still consistent with the current data status. Different systems have different times for saving, transmitting back, and updating processing results, which may also cause the two sides of the synchronization to hold valid records but the actual data status on which they are based to be different. This may lead to situations where the SIM card data has been updated but the processing status still uses the historical result, or the status has been advanced but the relevant business data has not yet reached the corresponding status, making it difficult to maintain the consistency between the data status and the processing status of cross-system synchronization results. Summary of the Invention

[0004] The purpose of this invention is to provide a method for secure cross-system data synchronization of power IoT cards, in order to solve the problem that when upstream input data is updated during cross-system processing of power IoT cards, such as card configuration, card production, activation, and core network registration, the already formed processing results remain in a completed state, but the data used when the processing results were formed may be inconsistent with the current data, making it difficult to determine whether the existing processing results can continue to serve as a condition for advancing the target synchronization state during cross-system synchronization.

[0005] To achieve the above objectives, the present invention provides a method for secure cross-system data synchronization of power IoT cards, which is applied between a card management platform and a card processing system. The card processing system is a system that participates in the configuration, card production, activation, or core network registration of power IoT cards, including at least one of a card production system and a core network unified data management network element. The card management platform and the card processing system participating in a cross-system data synchronization respectively constitute the synchronization initiator and the synchronization receiver.

[0006] The SIM card management platform receives user identification module card data from the card issuance system and saves SIM card status change data and Internet Protocol address resource allocation data for power IoT cards. Based on the target power IoT card's card identifier, the platform establishes a correlation between the data used in different card processing stages and the data processing results generated in the corresponding stages, providing a data foundation for subsequently determining the target synchronization status.

[0007] The SIM card management platform establishes a synchronization constraint record for data processing results with sequential dependencies in the cross-system processing of power IoT SIM cards. The synchronization constraint record includes the current synchronization status identifier, the trigger data item identifier, the target synchronization status identifier, the identifier of the pre-processing results required to enter the target synchronization status, and the identifier of the input data item read when forming the corresponding pre-processing results. Among them, the data processing results that need to be completed before entering the target synchronization status are determined as the pre-processing results.

[0008] The preprocessing results include data processing results formed by at least two of the following: access point name configuration processing, data network name configuration processing, Internet protocol address configuration processing, SIM card binding processing, card writing processing, activation processing, and core network unified data management network element registration processing. According to the generation order of each data processing result in the above processing process, a correspondence between different synchronization states and corresponding preprocessing results is established.

[0009] The SIM card management platform establishes data change records for the input data items involved in the synchronization constraint record. Each data change record includes at least the card identifier of the target power IoT card, the input data item identifier, and the data change identifier. When an input data item is first written to the SIM card management platform, a corresponding data change identifier is generated. When the content of the input data item is updated, a new data change identifier, different from the data change identifier before the update, is generated, and the new data change identifier is used as the current data change identifier for that input data item.

[0010] When the SIM card management platform sends a data processing request to the SIM card processing system, it sends the input data items required for this data processing, as well as the current data change identifier of each input data item. After the SIM card processing system completes the corresponding data processing, it generates the corresponding pre-processing result and establishes a confirmation record for the pre-processing result.

[0011] The confirmation record includes the card identifier of the target power IoT card, the pre-processing result identifier, the processing status, and the data item identifier and data change identifier of each input data item read when the pre-processing result is formed. The card management platform saves the confirmation record according to the card identifier and the pre-processing result identifier. When the input data item is subsequently updated, the confirmation record formed before the update is retained, so that the data change identifier used when the pre-processing result is formed can be compared with the updated current data change identifier.

[0012] When cross-system data synchronization of power IoT cards occurs, the card identifier of the target power IoT card, the data to be synchronized, the data item identifier and data change identifier of the data to be synchronized, and the synchronization status currently recorded on the synchronization initiator side are obtained.

[0013] Based on the current synchronization status of the synchronization initiator and the data item identifier of the data to be synchronized, the synchronization constraint record is queried to determine the target synchronization status corresponding to this data synchronization, and the pre-processing results required to enter the target synchronization status are obtained.

[0014] Read the confirmation record corresponding to each preprocessing result, and obtain the current data change identifier of the corresponding input data item according to the input data item identifier in the confirmation record. For preprocessing results for which no confirmation record is found, determine them as results to be verified on the initiating side. For preprocessing results for which a confirmation record is found, if the processing status in the confirmation record is not the completed status, or if the data change identifier of at least one input data item in the confirmation record is different from the current data change identifier of that input data item, the corresponding preprocessing result is also determined as a result to be verified on the initiating side.

[0015] For pre-processing results whose processing status in the confirmation record is "completed" and whose data change identifiers for each input data item are consistent with the current data change identifier of the corresponding input data item, their confirmation records will be retained, but the pre-processing results will not be included in the results to be verified on the initiating side.

[0016] For the verification result pending on the initiating side, the SIM card management platform sends a result query request to the SIM card processing system that generated the pre-processing result based on the card identifier and the pre-processing result identifier of the target power IoT card. The SIM card processing system reads the currently saved confirmation record according to the card identifier and the pre-processing result identifier, and returns the obtained current confirmation record to the SIM card management platform.

[0017] After receiving the current confirmation record, the SIM card management platform reads its processing status and compares the data change identifier of each input data item in the current confirmation record with the current data change identifier of the corresponding input data item stored in the SIM card management platform. When the processing status in the current confirmation record is "complete" and the data change identifiers of each input data item are consistent, the corresponding pre-processing result identifier, processing status, input data item identifier, and data change identifier are combined to form the initiating side pre-confirmation data. If any current confirmation record with an initiating side pending verification result does not meet the above conditions, the synchronization message corresponding to this data synchronization will not be generated.

[0018] After verifying the preprocessing results on the initiating side, the synchronous initiating side and the synchronous receiving side establish an authentication session and obtain the session key corresponding to this authentication session.

[0019] The initiating side sequentially combines the card identifier of the target power IoT card, the data item identifier of the data to be synchronized, the data change identifier of the data to be synchronized, the summary of the data to be synchronized, the target synchronization status, and the initiating side's pre-confirmation data to form synchronization authentication data. Then, it uses the session key to perform message authentication operation on the synchronization authentication data to generate synchronization authentication information.

[0020] The initiating side sends a synchronization message to the receiving side. The synchronization message includes at least the card identifier of the target power IoT card, the data to be synchronized, the data item identifier and data change identifier of the data to be synchronized, the target synchronization status, the initiating side's pre-confirmation data, and the synchronization authentication information. Thus, the receiving side can reconstruct synchronization authentication data consistent with the initiating side based on the corresponding fields in the synchronization message.

[0021] After receiving the synchronization message, the receiving side reconstructs the synchronization authentication data based on the card identifier, the data item identifier and data change identifier of the data to be synchronized, the summary of the data to be synchronized, the target synchronization status, and the initiating side's pre-confirmation data, and verifies the synchronization authentication information using the verification information corresponding to the authentication session.

[0022] After the synchronization authentication information is verified, before the synchronization receiving side determines the verification object using the pre-processing result identifier in the pre-confirmation data of the initiating side, it first queries the synchronization constraint record based on the current synchronization status, the target synchronization status in the synchronization message, and the data item identifier of the data to be synchronized, which are stored by the synchronization receiving side itself, to determine the pre-processing result that needs to be completed to enter the target synchronization status from the current synchronization status of the synchronization receiving side.

[0023] The receiving side reads the confirmation records corresponding to each determined pre-processing result and obtains the current data change identifier of the corresponding input data item from the SIM card management platform based on the input data item identifier in the confirmation record. For pre-processing results for which no confirmation record is found, they are determined as results to be verified by the receiving side. For pre-processing results for which a confirmation record has been found, if the processing status in the confirmation record is not complete, or if the data change identifier of at least one input data item is different from the current data change identifier of the corresponding input data item, the corresponding pre-processing result is determined as a result to be verified by the receiving side.

[0024] After the receiving side generates the verification result to be received, it uses the pre-confirmation data from the initiating side to compare the verification results on both sides. First, it compares the pre-processing result identifiers in the verification results on both sides. For the same pre-processing result identifier contained on both sides, it further compares the processing status and data change identifiers of each input data item in the corresponding current confirmation record.

[0025] When the initiating side's verification result and the receiving side's verification result contain the same pre-processing result identifier, and the processing status in the current confirmation record corresponding to each identical pre-processing result identifier is complete, and the data change identifiers of each input data item are consistent, the pre-processing status corresponding to this synchronization is determined to have passed the consistency check.

[0026] When only one side contains a certain pre-processing result, the pre-processing result is determined as the first difference result; when both sides contain the same pre-processing result, but the processing status in the corresponding current confirmation record or the data change identifier of at least one input data item is different, the pre-processing result is determined as the second difference result.

[0027] For the first and second difference results, based on the card identifier and pre-processing result identifier of the target power IoT card, a result query request is resent to the card processing system that generated the corresponding pre-processing result, and the corresponding difference results are compared again using the newly obtained current confirmation record. For pre-processing results that are not determined to be the first or second difference result, the confirmation record corresponding to the previous comparison is used, and the result query is not re-executed.

[0028] After the consistency check is passed in the preprocessing state and before the data to be synchronized is written to the synchronization receiving side, the current data change identifier corresponding to the data item identifier of the data to be synchronized is read again, and the current data change identifier of each input data item is obtained again according to the input data item identifier in the preconfirmation data of the initiating side.

[0029] The current data change identifier of the data to be synchronized is reread and compared with the corresponding data change identifier recorded in the synchronization authentication data. At the same time, the current data change identifier of each input data item is re-obtained and compared with the data change identifier of the corresponding input data item in the initiating side's pre-confirmation data.

[0030] When all the above data change identifiers are consistent, the data to be synchronized is written to the synchronization receiving side, and the current synchronization status of the synchronization receiving side is updated to the target synchronization status; when at least one data change identifier is inconsistent, the writing of the data to be synchronized and the synchronization status update are not performed, and the verification result to be initiated is re-determined based on the updated current data change identifier.

[0031] The above technical solution simultaneously stores the input data items used when the preprocessing result was formed and their data change identifiers in the confirmation record of the preprocessing result. This allows the completed data processing result to establish a definite association with the data state corresponding to its formation. When the input data item is updated, the preprocessing result that still corresponds to the input data before the update can be identified by comparing the data change identifier in the confirmation record with the current data change identifier, instead of using a single processing completion state as the basis for continuing to advance the target synchronization state.

[0032] For pre-processing results that require re-verification, the current confirmation record is obtained from the card processing system that actually generated the result based on the pre-processing result identifier. For pre-processing results whose data status has not changed, the existing confirmation record is used. This limits the re-verification to processing results whose status has changed, avoiding repeated cross-system queries for all pre-processing results.

[0033] At the same time, the target synchronization status and the initiating side's pre-confirmation data corresponding to this data synchronization are included in the synchronization authentication data. The synchronization receiving side re-determines the verification result based on its current synchronization status and then compares it with the pre-confirmation data formed by the synchronization initiating side. This establishes a connection between the authentication result of the synchronization message and the pre-processing status on which this status advancement is based, avoiding the situation where only the synchronization message itself is verified without verifying the pre-processing status on both sides.

[0034] Before the final data is written, the system reads the current data change flags of the data to be synchronized and related input data items again. It can also identify the data updates that occur after the verification of the preprocessing results is completed and before the data is written, thus avoiding the use of data states that have been confirmed when the verification is completed but have changed when the data is actually written to continue to perform the target synchronization status update.

[0035] The beneficial effects of this invention are as follows:

[0036] 1. This invention stores the actual input data items and their data change identifiers used when the processing result was formed in the confirmation record corresponding to the pre-processing result. Before initiating cross-system synchronization, the data change identifier in the confirmation record is compared with the current data change identifier of the corresponding input data item. This allows the completion status of the pre-processing result to be synchronously verified with the data status on which it is based. Thus, when upstream data such as access point name, data network name, Internet Protocol address resources, and SIM card binding relationship changes, it can identify that the pre-processing result is still based on the data before the update, avoiding the need to continue to advance the subsequent synchronization status based solely on the historical completion status, thereby improving the consistency between the SIM card data status and the processing status.

[0037] 2. This invention determines the target synchronization state and corresponding pre-processing results based on the current synchronization state, the data item identifier of the data to be synchronized, and the synchronization constraint record. Only pre-processing results with missing confirmation records, incomplete processing, or whose data has changed are identified as results to be verified. The current confirmation record is obtained from the SIM card processing system that actually generated the corresponding processing result. Thus, cross-system re-verification can be limited to the processing results that are actually related to the current data change, avoiding repeated queries on all pre-processing results. At the same time, the target synchronization state and the initiating side's pre-confirmation data are included in the synchronization authentication data, establishing a correspondence between the integrity verification of the synchronization message and the pre-processing state on which the current state advancement is based, reducing the risk that legitimate messages may be carried with invalid processing evidence and continue to be executed.

[0038] 3. This invention enables the receiving side to independently determine the verification result based on its current synchronization status and synchronization constraint records after successful synchronization authentication. This result is then compared with the pre-confirmation data from the initiating side, and the query is only performed on the pre-processing results that differ. After the verification results from both sides are consistent, the current data change identifiers of the data to be synchronized and related input data items are reread before actual writing. This not only identifies situations where both sides of the synchronization hold valid records but have different data states, but also detects data changes that occur again after pre-verification and before actual writing. This ensures that the writing of the data to be synchronized and the update of the target synchronization status are based on consistent and current data states, reducing the possibility of data and status deviations during cross-system synchronization. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the system application architecture of the power IoT card data cross-system secure synchronization method of the present invention;

[0040] Figure 2 This is an overall flowchart of the method for secure cross-system data synchronization of power IoT cards according to the present invention;

[0041] Figure 3This is a schematic diagram illustrating the data association relationship of the synchronization constraint records in this invention;

[0042] Figure 4 This is a schematic diagram illustrating the formation process of the data change record and pre-processing result confirmation record of the present invention;

[0043] Figure 5 This is a flowchart of the process by which the initiating side of the present invention determines the result to be verified and obtains the current confirmation record.

[0044] Figure 6 This is a schematic diagram illustrating the composition of the synchronous authentication data and synchronous messages of the present invention;

[0045] Figure 7 This is a flowchart illustrating how the synchronous receiving side independently determines the verification result and handles discrepancies in this invention.

[0046] Figure 8 This is a flowchart illustrating the data status verification and synchronization status update process before writing the data to be synchronized in this invention. Detailed Implementation

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

[0048] This implementation method takes the following scenario as an example: after a power IoT card has completed some card processing, the business configuration data, card status data, Internet Protocol address resource allocation data, or card production data in the card management platform change again, requiring the changed data to be synchronized to the corresponding card processing system. In this scenario, the previously formed card binding, card writing, activation, or core network registration results may still be recorded as completed, but the input data used when they were formed is no longer the current data. If only the processing status or only the integrity verification of the synchronization message is performed, it cannot be determined whether these historical processing results can still be used as the basis for subsequent synchronization status advancement.

[0049] The SIM card management platform uniformly manages service activation data, SIM card detail data, SIM card status change data, and Internet Protocol address resource allocation data. It also interacts with SIM card processing systems such as the card issuance system and the core network unified data management network element through interfaces. The service activation process involves access point name configuration, data network name configuration, and Internet Protocol address resource configuration. The SIM card activation process involves access point name binding, service configuration, SIM card binding, card writing, activation, core network registration, and activation result processing. The above actual processing steps are used as the business basis for cross-system synchronization.

[0050] In this embodiment, the SIM card management platform acts as the synchronization initiator, and the SIM card processing system that receives the data to be synchronized as the synchronization receiver. The synchronization receiver can be the card manufacturing system, the core network unified data management network element, or other systems that participate in SIM card processing and establish a synchronization interface with the SIM card management platform.

[0051] The SIM card management platform uses backend application services, data acquisition services, data storage services, and authentication services to collaboratively achieve the above synchronization process. The data acquisition service is responsible for interface interaction with the SIM card processing system, such as the card production system and the core network unified data management network element. The data storage service saves SIM card data, synchronization status, synchronization constraint records, data change records, and confirmation records. The authentication service is responsible for participating in the system's identity authentication, authentication session establishment, and session key management. Each service accesses the same business data through the data service within the SIM card management platform, enabling the synchronization status, data change identifiers, and confirmation records to establish a consistent association according to the card identifier.

[0052] This implementation method is mainly applicable to situations where the SIM card management platform uniformly records changes in business data, and the SIM card management platform or its connected interface unit initiates and records SIM card processing requests. When an external SIM card processing system independently performs a business operation that affects the SIM card processing result, the result of the operation is returned to the SIM card management platform through the existing interface or data acquisition service and a new confirmation record is formed before participating in subsequent synchronization judgment. Therefore, the changes in business data and the SIM card processing result, which serve as the basis for synchronization judgment, both have traceable record sources.

[0053] like Figures 1 to 8 As shown, this embodiment of the invention provides a method for secure cross-system data synchronization of power IoT cards;

[0054] I. Data organization and identification relationship of SIM cards

[0055] The SIM card management platform organizes the data corresponding to the same card according to the card identifier of the target power IoT card. The card identifier is a unique identifier field that can be jointly identified by the SIM card management platform and the corresponding SIM card processing system and can uniquely associate the same card record. When different systems use different primary keys, the SIM card management platform saves the mapping relationship between the primary key and the card identifier. When two systems use the same unique card identifier, they are directly associated according to the identifier. The specific encoding form of the card identifier is determined by the existing SIM card data fields. This implementation is not limited to a certain fixed encoding.

[0056] The SIM card management platform sets data item identifiers for data participating in synchronization judgment. Each data item identifier corresponds to a data object that can independently undergo content changes and participate in synchronization constraint judgment. Access point name configuration data, data network name configuration data, Internet protocol address resource allocation relationship, SIM card binding relationship, and user identity recognition module card data can each have their own data item identifiers set. When multiple business fields must be processed as a whole for the same SIM card, these fields are combined into a data item according to a fixed field name and a fixed field order.

[0057] Before writing and comparing, the same data item is normalized using a consistent data format. For character fields, a unified character encoding and null value representation are used. For combined fields with fixed order requirements, they are arranged according to a preset field order. If the normalized data content does not change, the data item is not considered to have a new data state.

[0058] II. Data Change Records and Data Change Identifiers

[0059] The SIM card management platform establishes a data change record for each data item determined by the card identifier and the data item identifier. The data change record includes at least the card identifier, the data item identifier, the data change identifier, and the data content corresponding to the data change identifier, and saves the update time of the record.

[0060] When a data item is first written to the SIM card management platform, an initial data change identifier is generated. When updated data for the same data item is received subsequently, the normalized updated data is compared with the current data. If they are the same, the original data change identifier is retained. If they are different, a new data change identifier is generated that is different from the data change identifier before the update. The new data change identifier and the updated data content are written in the same database transaction to ensure that the current data content corresponds to the current data change identifier.

[0061] One approach is to set incremental serial numbers for the same card identifier and the same data item identifier, and generate a new data change identifier from the database sequence. Alternatively, other identifier forms that can distinguish the data status before and after the update within the scope of the data item can be used. Subsequent verification only judges whether the data change identifiers are consistent, and does not judge the validity of the processing result based on the size of the identifier value.

[0062] When the SIM card status changes, the SIM card binding relationship changes, Internet Protocol address resources are reallocated, or network configuration data is modified, only the data items that have actually changed and their data change identifiers are updated. When an update involves multiple independent data items at the same time, new data change identifiers are generated for each data item. When multiple fields are inseparable in terms of business, they are updated as a combined data item.

[0063] III. Synchronization Status and Synchronization Constraint Records

[0064] The SIM card management platform records the synchronization status of the target power IoT SIM card on both the synchronization initiator and synchronization receiver sides. The synchronization status indicates the cross-system SIM card processing stage and can be set to states such as network configuration completed, SIM card binding completed, card writing completed, activation completed, core network registration completed, and activation result synchronized, depending on the specific business process. The same processing stage does not necessarily mean that the data it depends on is still the current data. Therefore, the synchronization status and the data status of the previous processing results are judged separately.

[0065] The SIM card management platform establishes synchronization constraint records according to the SIM card processing flow and the actual input relationship of the interface. Each synchronization constraint record includes at least the current synchronization status identifier, the trigger data item identifier, the target synchronization status identifier, the identifier of the pre-processing result that needs to be checked to enter the target synchronization status, and the identifier of the input data item read when generating the corresponding pre-processing result. In order to locate the pre-processing result to the actual SIM card processing system, the synchronization constraint record can also save the identifier of the SIM card processing system that generated the pre-processing result and the processing type.

[0066] Based on the actual processing order of the SIM card, the pre-processing results may include two or more of the following: access point name configuration processing results, data network name configuration processing results, Internet protocol address configuration processing results, SIM card binding processing results, card writing processing results, activation processing results, and core network registration processing results. The SIM card management platform establishes a correspondence between the target synchronization state and the pre-processing results that need to be met before entering the target synchronization state, according to the order in which these processing results are generated in the corresponding business processes.

[0067] The input data items in the synchronization constraint record are determined according to the input fields actually used in the corresponding card processing request. When the card writing process actually uses the user identification module card data, the corresponding data item is identified and registered as the input data item of the card writing process result. When the core network registration process actually uses a certain network configuration data, the network configuration data item is registered as the input data item of the core network registration process result. No dependency relationship is established between the data item and the previous processing result if the data item has not entered the corresponding processing request.

[0068] For the same synchronization receiving side, under the same current synchronization state and the same trigger data item identifier, a unique target synchronization state is configured. When entering the target synchronization state requires multiple preprocessing results, the multiple preprocessing results and their respective input data items are recorded separately. When configuring synchronization constraint records, if the same query condition corresponds to different target synchronization states, the conflict record is not made effective to avoid the inability to determine the target synchronization state during the synchronization process.

[0069] Once a cross-system synchronization begins, both the initiating and receiving sides obtain the basis for this judgment from the same set of synchronization constraint records maintained by the SIM card management platform. If the synchronization being processed has not yet ended, the constraint relationships already used in this synchronization will not be replaced midway. When the business process or interface input relationship is adjusted, the adjusted constraint relationship will be used for subsequent newly initiated synchronizations.

[0070] IV. Data Processing Requests and Confirmation Records

[0071] When the SIM card management platform sends a data processing request corresponding to the pre-processing result to the SIM card processing system, it carries the card identifier, processing type, actual input data items, and current data change identifier for each input data item in the request. The data change identifier serves as the data status metadata for this processing and corresponds one-to-one with the corresponding input data item. The SIM card processing system executes the original SIM card processing according to the business fields. The data status metadata is used to subsequently confirm the data status used in this processing.

[0072] Before generating a data processing request, the SIM card management platform reads the standardized data content required for this processing and its current data change identifier in one go according to the card identifier and the input data item identifier. The data processing request is then constructed based on the results of this read. During the request construction process, the same input data item is not read again to avoid the business data content and data change identifier being taken from different data states. For input data items stored in the same relational database, the above data snapshot can be obtained by using the same database transaction or consistent reading.

[0073] To facilitate integration with existing SIM card processing systems, these systems can be configured with a docking unit that connects to their business processing services. In this implementation, the docking unit, as part of the SIM card processing system's external synchronization interface, receives data processing requests from the SIM card management platform and stores the card identifier, processing type, actual input data item identifier, and corresponding data change identifier. When the existing business processing interface can receive extended metadata, the docking unit transmits the data change identifier along with the business fields. When the existing business processing interface does not parse extended metadata, the docking unit stores the data change identifier and establishes a one-to-one correspondence with the current business request, and the business processing service still performs corresponding processing according to the original business fields.

[0074] After the SIM card processing is completed, the SIM card processing system establishes a confirmation record corresponding to the previous processing result based on the actual returned result. When using an interface unit, the interface unit binds the input data item identifier and data change identifier saved at the time of the request to the processing result returned by the business processing service according to the one-to-one correspondence of this business request. This binding is used as a unified confirmation record output by the SIM card processing system. Different SIM card processing systems can continue to use their original business result formats. The interface unit only completes the processing type mapping, status mapping, and confirmation record field organization.

[0075] The confirmation record includes at least the card identifier, the pre-processing result identifier, the processing status, and the data item identifiers and data change identifiers of each input data item used to form the pre-processing result. The processing status should at least distinguish between completed and incomplete states. When the original return status of the card processing system has multiple representations, the docking unit maps it to a completed or incomplete state according to whether the corresponding business operation has been successfully completed. The confirmation record can also save the processing request sequence number, result generation time, and source system identifier.

[0076] When the same card identifier and the same pre-processing result identifier are processed multiple times, each confirmation record is retained. Each new processing request generates a new processing request sequence number, which is then bound to the confirmation record. When querying the current confirmation record, the record set is first determined according to the card identifier and the pre-processing result identifier, and then the confirmation record corresponding to the latest processing request sequence number is selected. If the processing has not yet been completed, the current confirmation record remains in an incomplete state and is not replaced by a previously completed historical confirmation record. When the same processing request has multiple status feedbacks, its confirmation record is updated with the most recent feedback status of the processing request.

[0077] The SIM card management platform receives and saves the confirmation record. When the input data item is updated again after the confirmation record is generated, the original confirmation record still saves the data change identifier used when the previous processing result was formed, and does not modify it along with the current data change identifier. In this way, the data status on which the historical processing was based can be directly compared with the current data status during subsequent synchronization.

[0078] V. Simultaneously determine the verification result from the initiating side.

[0079] When a target power IoT card experiences data changes that require cross-system synchronization, the card management platform establishes a synchronization context. The synchronization context includes at least the card identifier, the data to be synchronized, the data item identifier of the data to be synchronized, the current data change identifier, and the current synchronization status recorded by the synchronization initiator.

[0080] The synchronization initiator queries the synchronization constraint record using the current synchronization state and the data item identifier of the data to be synchronized. It obtains the target synchronization state for this synchronization and the pre-processing results that need to be checked to enter the target synchronization state. If no valid synchronization constraint record corresponding to the current synchronization state and data item identifier is found, the current state advancement is not executed.

[0081] For each pre-processing result, the initiating side synchronously reads its saved confirmation record. If no confirmation record is found, the corresponding pre-processing result is determined as a result to be verified by the initiating side. If a confirmation record is found but the processing status is not complete, it is also determined as a result to be verified by the initiating side.

[0082] When the processing status in the confirmation record is "completed", the current data change identifier of each input data item is read from the SIM card management platform according to the input data item identifier saved in the confirmation record. The current data change identifier of each input data item is compared item by item. If at least one data change identifier in the confirmation record is inconsistent with the current data change identifier, the corresponding pre-processing result is determined as the result to be verified on the initiating side. If all are consistent, the confirmation record is used, and the corresponding pre-processing result is not included in the result to be verified on the initiating side.

[0083] Therefore, the preprocessing results that need to be re-queried under the same target synchronization state are determined by the changes in the current data and the data state on which each historical processing result is based. Preprocessing results that have not changed and whose processing has been completed will not be queried repeatedly.

[0084] Table 1 Verification and Judgment Relationship of Preprocessing Results

[0085] Confirmation of record status Processing status Data change identifier comparison results This processing No confirmation record found — — The result is confirmed as pending verification. Confirmation records have been found. Incomplete status No further comparisons or only records. The result is confirmed as pending verification. Confirmation records have been found. Completed status All input data change identifiers are consistent Retain the confirmation record and do not include it in the pending verification results. Confirmation records have been found. Completed status At least one input data change identifier is inconsistent. The result is confirmed as pending verification.

[0086] VI. Current Confirmation of Pending Verification Results from the Initiating Side

[0087] For each initiating side pending verification result, the SIM card management platform generates a result query request. The result query request includes at least the card identifier and the pre-processing result identifier. Based on the interface mapping relationship between the pre-processing result identifier and the processing type of the SIM card processing system, the SIM card management platform sends the result query request to the SIM card processing system that actually generated the pre-processing result.

[0088] The SIM card processing system reads the result of the most recent processing according to the card identifier and processing type, forms a current confirmation record through the docking unit, and returns it to the SIM card management platform. If the processing status of the current confirmation record is not complete, the synchronization will not continue to enter the synchronization authentication. If the processing status of the current confirmation record is complete, the SIM card management platform further compares the change identifiers of each input data with the current data change identifiers of the corresponding input data items.

[0089] When the processing status in the current confirmation record is completed, and the change identifier of each input data item is consistent with the current data change identifier of the corresponding input data item, the current confirmation record is used as the valid current confirmation record for this synchronization. After all the results to be verified on the initiating side meet this condition, the pre-processing result identifier, processing status, input data item identifier and data change identifier corresponding to each result to be verified are combined to form the initiating side pre-confirmation data.

[0090] If the current confirmation record returned by the SIM card processing system still corresponds to the data before the update, or if the processing has not yet been completed, the current synchronization will be terminated at this stage. If business processing needs to continue, the SIM card management platform will resubmit a data processing request using the current input data according to the existing SIM card processing process. After the corresponding SIM card processing system generates a new processing result and confirmation record, the data synchronization will be re-initiated.

[0091] When there is no pending verification result on the initiating side, the pre-confirmation data on the initiating side is represented by an empty set. An empty set only indicates that the initiating side has not found any pre-processing result that needs to be queried again. The pre-processing result on which the target synchronization state depends is still determined by the synchronization constraint record.

[0092] VII. Synchronizing Authentication Data and Synchronization Messages

[0093] After the initiating side completes the verification of the preprocessing result, the synchronous initiating side and the synchronous receiving side complete the identity authentication of both parties through the authentication service and establish an authentication session. After the authentication session is established, the session key used for the authentication of the message in this session is obtained. Identity authentication and session key establishment can adopt mature authentication mechanisms in the relevant communication security field. This implementation method does not limit the specific certificate system or key negotiation algorithm.

[0094] One feasible method for establishing an authentication session is as follows: the synchronization initiator and the synchronization receiver submit their system identity credentials to the authentication service. After verifying the validity of the system identifiers and identity credentials of both parties, the authentication service establishes an authentication session for this synchronization and generates a session identifier. The session key is generated by the authentication service or negotiated by both parties on an already authenticated connection and is associated only with this authentication session. The synchronization receiver obtains the corresponding session key based on the authentication session identifier in the synchronization message and uses it to verify the synchronization authentication information.

[0095] The initiating side calculates the summary of the data to be synchronized according to a fixed data format, and encodes the card identifier, the data item identifier of the data to be synchronized, the data change identifier of the data to be synchronized, the summary of the data to be synchronized, the target synchronization status, and the initiating side's pre-confirmation data in a determined order to form synchronization authentication data.

[0096] When the initiating side's pre-confirmation data includes multiple pre-processing results, they are sorted according to the pre-processing result identifier; when the same pre-processing result includes multiple input data items, they are sorted according to the input data item identifier. Each field uses a deterministic encoding method that can distinguish field boundaries, such as encoding the field identifier, field length, and field value sequentially, so that the same business content receives the same byte sequence to be authenticated on both the synchronous initiating side and the synchronous receiving side.

[0097] The initiating side uses the session key corresponding to the authentication session to perform message authentication operation on the synchronization authentication data to obtain synchronization authentication information. The message authentication operation can adopt a message authentication code mechanism based on a secure hash function. The synchronization message carries at least the card identifier, the data to be synchronized, the data item identifier and data change identifier of the data to be synchronized, the target synchronization status, the initiating side's pre-confirmation data, the authentication session identifier, and the synchronization authentication information.

[0098] Both the initiating side's pre-confirmation data and the target's synchronization status are part of the synchronization authentication data. Therefore, the synchronization receiving side verifies not only the data to be synchronized but also the initiating side's pre-confirmation data on which this status advancement is based.

[0099] 8. The receiving side determines the result to be verified.

[0100] After receiving the synchronization message, the synchronization receiving side recalculates the data digest based on the data to be synchronized, and reconstructs the synchronization authentication data using the same field order and encoding method as the synchronization initiating side. Then, it uses the session key corresponding to the current authentication session to verify the synchronization authentication information. If the verification fails, it does not write the data to be synchronized, nor does it update the current synchronization status of the synchronization receiving side.

[0101] During the message authentication phase, the initiating side's pre-confirmation data is used as a complete field in the synchronization authentication data for authentication calculation. After the synchronization authentication information is verified, the synchronization receiving side does not use the pre-processing result identifier in the initiating side's pre-confirmation data to determine its own verification object. Instead, it reads the current synchronization status of the target power IoT card that it has saved.

[0102] The receiving side retrieves the pre-processing results required to enter the target synchronization state from the synchronization constraint record set maintained by the SIM card management platform based on its current synchronization state, the target synchronization state in the synchronization message, and the data item identifier of the data to be synchronized. If no valid synchronization constraint record matching the target synchronization state in the synchronization message is found, data writing and status update are not performed.

[0103] The receiving side saves the local confirmation record obtained after the previous synchronization. For each pre-processing result determined in this time, the receiving side reads the corresponding local confirmation record and obtains the current data change identifier of the corresponding input data item through the data status query interface provided by the card management platform based on the input data item identifier in the confirmation record. The data status query interface uses the card identifier and the input data item identifier as query conditions, and does not use the pending verification result of the initiating side or the pre-confirmation data of the initiating side as query conditions.

[0104] The receiving side uses the same conditions as the initiating side to determine the result to be verified on the receiving side: if no local confirmation record is found, the processing status in the confirmation record is not completed, or at least one input data change identifier is inconsistent with the current data change identifier of the corresponding input data item, the corresponding preprocessing result will be determined as the result to be verified on the receiving side.

[0105] For the verification results to be received on the receiving side, the synchronous receiving side obtains the current confirmation record of the corresponding card processing system according to the card identifier and the pre-processing result identifier. The result query can be forwarded through the data acquisition interface of the card management platform. The returned current confirmation record adopts the same field meaning as the query on the initiating side. After the verification results to be received on the receiving side and its current confirmation record are formed, the synchronous receiving side parses the pre-processing result identifier in the pre-confirmation data of the initiating side and performs a comparison between the two sides.

[0106] The initiating side's pre-confirmation data is organized according to the principle that one pre-processing result corresponds to one confirmation unit. After the synchronous receiving side completes the determination of its own pending verification result, it extracts the pre-processing result identifier from each confirmation unit of the initiating side's pre-confirmation data. These pre-processing result identifiers constitute the initiating side's pending verification result identifier set. When the initiating side's pre-confirmation data is an empty set, the initiating side's pending verification result identifier set is also an empty set.

[0107] IX. Comparison of Verification Results from Both Sides and Handling of Differences

[0108] The synchronous receiving side deduplicates and sorts the results to be verified on the initiating side and the results to be verified on the receiving side according to the identifier of the preprocessing result. Then, it compares the sets of preprocessing result identifiers on both sides. For the same preprocessing result identifier contained on both sides, it compares the processing status and input data change identifier in the corresponding current confirmation record item by item according to the input data item identifier.

[0109] If the sets of identifiers for the preprocessing results on both sides are consistent, and the processing status in the current confirmation record corresponding to each identical preprocessing result is complete, and the data change identifiers for the corresponding input data items are consistent, then the comparison of the preprocessing results is passed. If the sets of results to be verified on both sides are empty, the sets of identifiers for the preprocessing results are considered consistent, but the subsequent verification of the data status before writing is still performed.

[0110] Pre-processing results that exist only in one side of the verification results are determined as the first difference result. Pre-processing results that are included on both sides but have different processing statuses in the corresponding current confirmation records, or have different data change identifiers for the same input data item, are determined as the second difference result.

[0111] For the first and second difference results, only the current confirmation record of the corresponding preprocessing result is queried again. After obtaining the new current confirmation record, the conditions shown in Table 1 are used to re-determine whether the preprocessing result is still a result to be verified on the corresponding side. Based on this, the set of identifiers of the results to be verified on that side is updated and then compared again. The preprocessing results that are not determined to be difference results continue to use the current confirmation record that has been compared in the previous time, and are not queried repeatedly.

[0112] The first discrepancy result is caused only by the absence or expiration of the local acknowledgment record on the synchronous receiving side. If the current acknowledgment record obtained by the synchronous receiving side after re-querying is consistent with the pre-acknowledgment data of the initiating side that has passed message authentication, the synchronous receiving side can save the current acknowledgment record and regenerate the receiving side's verification result. If the re-query requires changes to the processing status, input data change identifier, or initiating side's verification result set in the pre-acknowledgment data, the current synchronization message will no longer be processed. The synchronous initiating side will regenerate the pre-acknowledgment data based on the latest acknowledgment record and regenerate the synchronization authentication information.

[0113] 10. Data status verification and synchronization status update before writing

[0114] After the verification results from both sides pass, before writing the data to be synchronized, the synchronization receiving side re-obtains the current data change identifier corresponding to the data item identifier of the data to be synchronized and compares it with the data change identifier of the data to be synchronized recorded in the synchronization authentication data.

[0115] When the initiating side's pre-confirmation data is not empty, the synchronization receiving side also obtains the current data change identifier of each input data item based on the input data item identifier, and compares it item by item with the corresponding data change identifier in the initiating side's pre-confirmation data. When the initiating side's pre-confirmation data is empty, the comparison of that group of input data items is not performed, but the data change identifier of the data to be synchronized is still verified.

[0116] When all the above data change identifiers are consistent, the synchronization receiving side writes the data to be synchronized to the local data storage and updates the current synchronization status of the synchronization receiving side to the target synchronization status. The writing of the data to be synchronized and the updating of the synchronization status are completed in the same local transaction on the synchronization receiving side; if any operation fails, the local transaction is rolled back.

[0117] If the pre-write verification finds that at least one data change identifier has changed, the current data write and status update will not be performed. The synchronization initiator will re-execute the synchronization constraint query, pending verification result determination, current confirmation record query and synchronization authentication with the latest data change identifier. The original synchronization message will no longer be used as the basis for the target synchronization status update.

[0118] Before writing, the data status verification and local writing are performed continuously. After the last data change identifier is read, the synchronous receiving side immediately performs local data writing and synchronization status update. During this period, no other card business processing is actively inserted. This measure is used to shorten the time interval between the final verification and writing. If the source data is updated again after this synchronization is completed, the update generates a new data change identifier and triggers subsequent synchronization according to the same process.

[0119] XI. Implementation process under specific working conditions

[0120] Example 1: Network configuration data is updated after existing processing results are generated.

[0121] After the service is activated, the SIM card management platform saves the access point name configuration data, data network name configuration data, and Internet protocol address resource allocation data corresponding to the target power IoT SIM card. It can also save the account opening information fed back from the service activation process. The SIM card will then enter the processing stages of access point name binding, service configuration, SIM card binding, card writing, activation and core network registration.

[0122] Taking the case where a core network registration process actually reads the data network name configuration data as an example, when the SIM card management platform sends a core network registration processing request, it also sends the current data change identifier of the data network name configuration data. After the core network registration processing is completed, the confirmation record saves the data network name configuration data and its data change identifier actually used in the processing.

[0123] After the core network registration processing result is generated, if the data network name configuration data is modified again, the SIM card management platform generates a new data change identifier for the modified data. When it is necessary to synchronize the activation result or other data that depends on the core network registration result, the initiating side reads the original core network registration confirmation record. If it finds that the data change identifier in the confirmation record is different from the current data change identifier, even if the processing status in the confirmation record is still not completed, the core network registration processing result will be determined as the result to be verified by the initiating side.

[0124] The SIM card management platform queries the corresponding SIM card processing system for the current confirmation record. If the current confirmation record still corresponds to the data network name configuration data before the modification, the synchronization will stop at the pre-processing result verification stage. Only after the SIM card processing system re-completes the corresponding processing according to the modified data network name configuration data and forms a new confirmation record will the subsequent synchronization continue.

[0125] If the core network registration process in a specific deployment does not read the data network name configuration data, the synchronization constraint record will not register the dependency relationship between this data item and the core network registration process result, and changes to the data network name configuration data will not trigger a re-verification of the core network registration process result. Dependencies are always based on the data item actually used in the corresponding processing request.

[0126] Example 2: Card manufacturing data is updated after the card writing process is completed.

[0127] The card-making system transmits user identification module card data to the card management platform. The card management platform saves and associates the corresponding card data according to the card identifier. The actual user identification module card data used in the card writing request and its current data change identifier are sent with the request and saved in the confirmation record corresponding to the card writing result.

[0128] After the card writing process is completed, if the card data of the user identification module involved in the card writing process is substantially modified, the card management platform will generate a new data change identifier for the modified data. When the subsequent synchronization status requires the card writing process result as the preliminary processing result, the data change identifier in the original card writing confirmation record will be different from the current data change identifier, and the original card writing process result will enter the scope of pending verification.

[0129] If the card writing system has not yet completed the new card writing process according to the modified card data, the current confirmation record cannot be judged by the consistency of the data change identifier, and the target synchronization state will not be advanced. After the card writing is completed and a confirmation record corresponding to the current card data state is formed, cross-system synchronization will be performed again.

[0130] Example 3: The local acknowledgment record on the receiving side is different from the status on the initiating side.

[0131] During a certain synchronization, the card binding processing result and card writing processing result saved by the synchronization initiator were both in a completed state, and the input data change identifier in the corresponding confirmation record was consistent with the current data change identifier. Therefore, the synchronization initiator did not include the above results in the results to be verified by the initiator.

[0132] The synchronous receiving side independently determines the SIM card binding processing result and SIM card writing processing result to enter the target synchronization state based on its current synchronization status and synchronization constraint record. The synchronous receiving side has a local confirmation record of the SIM card binding processing result, but lacks a local confirmation record of the SIM card writing processing result. Therefore, the SIM card writing processing result is determined as the result to be verified by the receiving side. At this time, the SIM card writing processing result constitutes the first difference result.

[0133] The synchronous receiving side re-queries the current confirmation record of the card writing process. If the query result shows that the card writing process has been completed and the input data change identifier in the current confirmation record is consistent with the corresponding current data change identifier, the synchronous receiving side saves the record and re-determines the result to be verified on the receiving side. If the result to be verified on both sides is an empty set after re-determination, the data status re-verification before writing continues. If the query result still does not meet the conditions, the data to be synchronized is not written.

[0134] Example 4: Data changes again after comparison of preprocessing results

[0135] The synchronization initiator has already generated synchronization authentication information, and the synchronization receiver has also completed the verification of synchronization authentication information and the comparison of the preprocessing results of both sides. However, the data to be synchronized has not yet been written. At this time, the data to be synchronized in the SIM card management platform is modified again and a new data change identifier is generated.

[0136] Before actually writing the data, the receiving side retrieves the current data change identifier of the data item and finds that it is different from the data change identifier recorded in the synchronization authentication data. Therefore, it does not write the data to be synchronized in the original synchronization message, nor does it update the target synchronization status. The initiating side re-executes the synchronization process with the modified current data.

[0137] 12. Storage and Interface Implementation

[0138] The SIM card management platform can use a relational database to store SIM card data, synchronization status, synchronization constraint records, data change records, and confirmation records. It also uses a cache to store frequently accessed data. Data change identifiers, synchronization status, and confirmation records are based on persistent data. If the cached content is inconsistent with the persistent data, the cache is refreshed before performing the synchronization check.

[0139] Both the result query interface and the data status query interface identify the target power IoT card according to the card identifier. The result query interface further uses the pre-processing result identifier or its corresponding processing type to determine the card processing result to be queried. The data status query interface uses the data item identifier to determine the current data change identifier to be read. The data fields returned by the interface have the same meaning as the corresponding fields in the synchronization constraint record and confirmation record.

[0140] Synchronization message transmission is carried out through a communication connection that has completed identity authentication. Synchronization authentication information is used to verify the integrity of the data to be synchronized, the target synchronization status, and the initiating side's pre-confirmation data in this session. Data change identifier comparison is used to determine whether the data status when the pre-processing result is formed is still consistent with the current data status. Message authentication and data status verification are applied to the integrity of communication data and the validity of the pre-processing result, respectively.

[0141] The SIM card management platform keeps a record of the synchronization process. The record includes at least the card identifier, the data item identifier of the data to be synchronized, the current synchronization status of the synchronization initiator, the target synchronization status, the synchronization processing result, and the processing time. Existing SIM card status change records, SIM card application logs, and SIM card activation logs can continue to be used to record the relevant business operation facts. The synchronization processing log is used to associate the current cross-system synchronization process, but the log time does not replace the validity judgment of the data change identifier and confirmation record.

[0142] In this embodiment, the card identifier, synchronization status identifier, data item identifier, data change identifier, and pre-processing result identifier are all used to uniquely identify the corresponding technical object within their scope of function. The specific encoding length and character format can be set according to the existing data structure of the deployment system, as long as the card management platform, the synchronization initiator, and the synchronization receiver maintain a consistent mapping for the same identifier.

[0143] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0144] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for secure cross-system data synchronization of power IoT cards, applied between a card management platform and a card processing system, characterized in that, include: S1. Obtain the card identifier, the data to be synchronized and its data item identifier, the data change identifier, and the current synchronization status of the synchronization initiator; S2. Based on the current synchronization status and data item identifier, query the synchronization constraint record to determine the target synchronization status and the preprocessing result; The preceding processing results that confirm missing records, incomplete processing status, or inconsistent input data change identifiers when the results are generated with the current data change identifiers of the corresponding input data items are determined as the results to be verified on the initiating side. S3. Query the current confirmation record from the card processing system that generated the corresponding pre-processing result, and form the initiating side pre-confirmation data with the record whose processing status is completed and whose input data change identifier is consistent with the corresponding current data change identifier. S4. Establish an authentication session, perform message authentication on the card identifier, data change identifier, target synchronization status and initiating side pre-confirmation data, generate authentication information and send synchronization message; S5. After the receiving side verifies the authentication information, without determining the verification object based on the initiating side's pre-confirmation data, it independently determines the verification result to be verified on the receiving side based on its own current synchronization status and synchronization constraint record; when the sets of verification result identifiers on both sides are consistent and the corresponding current confirmation records are consistent, the data to be synchronized is written and updated to the target synchronization status.

2. The method for secure cross-system data synchronization of a power IoT card according to claim 1, characterized in that: The SIM card processing system includes one of a card production system and a core network unified data management network element. The card management platform receives user identification module card data transmitted by the card production system, and saves the card status change data and Internet Protocol address resource allocation data of the target power IoT card; The card identifier is used to associate the same power IoT card between the card management platform and the card processing system, and to associate the card data of the user identification module, the card status change data, and the Internet Protocol address resource allocation data with the pre-processing results formed in the corresponding card processing process.

3. The method for secure cross-system data synchronization of a power IoT card according to claim 2, characterized in that: The synchronization constraint record includes the current synchronization state identifier, the trigger data item identifier, the target synchronization state identifier, the identifier of the pre-processing result that needs to be checked to enter the target synchronization state, and the input data item identifier corresponding to each pre-processing result. The preprocessing results include two categories: access point name and data network name configuration processing results, Internet Protocol address configuration processing results, SIM card binding processing results, SIM card writing processing results, activation processing results, and core network unified data management network element registration processing results. The identifier of the input data item corresponding to each preprocessing result is determined based on the data item actually read from the data processing request that generated the preprocessing result.

4. The method for secure cross-system data synchronization of a power IoT card according to claim 3, characterized in that: The SIM card management platform establishes a data change record for data items determined by the card identifier and the input data item identifier. The data change record includes the card identifier, the input data item identifier, the data content, and the data change identifier. When an input data item is written for the first time, an initial data change identifier is generated. When it is written again, the data to be written and the current data are compared in a normalized manner. If the data content has not changed, the original data change identifier is retained. If the data content has changed, a new data change identifier is generated. When a data processing request is generated, the data content of the corresponding input data item and the current data change identifier are obtained during the same consistency reading process, and the two are provided to the SIM card processing system or the docking unit connected to the SIM card processing system.

5. The method for secure cross-system data synchronization of a power IoT card according to claim 4, characterized in that: The confirmation record includes card identifier, pre-processing result identifier, processing request sequence number, processing status, and the input data item identifier and data change identifier used when generating the corresponding pre-processing result; When receiving a data processing request through the docking unit, the docking unit binds the card identifier, pre-processing result identifier, processing request sequence number, input data item identifier, and data change identifier in this data processing request with the processing status returned by the card processing system to form a confirmation record; Once the record is confirmed, the input data change identifier remains the same as the data change identifier used when the corresponding preprocessing result was generated, and does not change with subsequent updates to the corresponding input data item.

6. The method for secure cross-system data synchronization of a power IoT card according to claim 5, characterized in that: The SIM card management platform sends the result query request to the SIM card processing system that generated the corresponding pre-processing result based on the mapping relationship between the pre-processing result identifier and the processing type in the SIM card processing system. For multiple confirmation records with the same card identifier and pre-processing result identifier, the confirmation record corresponding to the most recent data processing request is determined as the current confirmation record according to the processing request sequence number. If the most recent processing is in an incomplete state, it will not replace the confirmation record corresponding to the previous completed processing. If no current confirmation record is obtained that can form the initiating side's pre-confirmation data, the current synchronization is terminated; if there is no initiating side's pending verification result, the initiating side's pre-confirmation data is set to an empty set.

7. The method for secure cross-system data synchronization of a power IoT card according to claim 1, characterized in that: When establishing the authentication session, the system identities of the synchronization initiator and the synchronization receiver are authenticated, and a session identifier and a session key are established for the authentication session; The synchronous authentication data also includes the data item identifier and the summary of the data to be synchronized. The initiating side pre-confirmation data is sorted according to the pre-processing result identifier. The input data items corresponding to the same pre-processing result are sorted according to the input data item identifier. Each field forms synchronous authentication data according to the preset field order and the encoding rules that can determine the field boundaries. The session key is used to perform message authentication operations on the synchronization authentication data, and the obtained authentication information and authentication session identifier are written into the synchronization message.

8. A method for secure cross-system data synchronization of power IoT cards according to claim 1, characterized in that: After the authentication information is verified, the receiving side reads its own current synchronization status and queries the synchronization constraint record based on its own current synchronization status, the target synchronization status, and the data item identifier of the data to be synchronized, in order to obtain the pre-processing results that need to be checked before entering the target synchronization status. The receiving side reads the local confirmation record corresponding to each preprocessing result and obtains the current data change identifier of each input data item. The preprocessing result with missing local confirmation record, incomplete processing status, or an input data change identifier that is inconsistent with the corresponding current data change identifier is determined as the result to be verified by the receiving side. After the receiving side has determined the result to be verified, the pre-processing result identifier in the initiating side's pre-confirmation data is parsed to form a set of initiating side's result to be verified identifiers and then compared between the two sides.

9. A method for secure cross-system data synchronization of a power IoT card according to claim 8, characterized in that: Pre-processing results that exist only in the set of pending verification results on the initiating side or in the pending verification results on the receiving side, as well as pre-processing results that exist on both sides but have different processing statuses or data change identifiers for the same input data item in the current confirmation record, are identified as differential pre-processing results. Only for the difference preprocessing results, the current confirmation record is requeried; the preprocessing results that are not determined to be difference preprocessing results continue to use the current confirmation record that has already been compared in the previous comparison. If the updated current confirmation record is consistent with the pre-confirmation data of the initiating side that has passed message authentication after the query is repeated, the receiving side to be verified result is re-determined and the two sides are compared. If a re-query necessitates changes to the initiating side's pre-confirmation data, the current synchronization will be terminated, and the initiating side will regenerate the initiating side's pre-confirmation data based on the latest confirmation record and generate new authentication information.

10. A method for secure cross-system data synchronization of a power IoT card according to claim 8, characterized in that: Before writing the data to be synchronized, the synchronization receiving side rereads the current data change identifier of the data to be synchronized; when the initiating side's pre-confirmation data is not empty, it also rereads the current data change identifier of each input data item according to the input data item identifier therein. Compare the data change identifier of the reread data to be synchronized with the corresponding data change identifier in the synchronization authentication data, and compare the reread input data change identifier with the corresponding data change identifier in the initiating side pre-confirmation data. When all data change identifiers are consistent, the writing of the data to be synchronized and the update of the current synchronization status of the receiving side are completed in the same local transaction; when there is a discrepancy in one data change identifier, the current writing and status update are terminated, and a resynchronization instruction is returned to the synchronization initiator, which then re-executes the pending verification and message authentication based on the current data change identifier.

Images